Bug#391678: ITP: asio -- a cross-platform C++ networking library
Package: wnpp Severity: wishlist Owner: Marek Habersack <[EMAIL PROTECTED]> * Package name: asio Version : 0.3.7 Upstream Author : Christopher M. Kohlhoff <[EMAIL PROTECTED]> * URL : http://asio.sf.net/ * License : The Boost License (http://www.boost.org/LICENSE_1_0.txt) Programming Lang: C++ Description : a cross-platform C++ networking library ASIO is a cross-platform C++ library for network programming that provides developers with a consistent asynchronous I/O model using a modern C++ approach. -- System Information: Debian Release: testing/unstable APT prefers edgy-updates APT policy: (500, 'edgy-updates'), (500, 'edgy-backports'), (500, 'edgy') Architecture: amd64 (x86_64) Shell: /bin/sh linked to /bin/dash Kernel: Linux 2.6.18-mm3 Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#342031: ITP: public.network.pcap -- Pike interface module for the pcap library
On Mon, Dec 05, 2005 at 08:53:16AM +1100, Hamish Moffatt scribbled: > On Sun, Dec 04, 2005 at 10:33:59PM +0100, Marek Habersack wrote: > > Package: wnpp > > Severity: wishlist > > Owner: Marek Habersack <[EMAIL PROTECTED]> > > > > * Package name: public.network.pcap > > Will these packages all have a pikeN-* naming scheme when uploaded? yes, all of them will produce several names using this format: pike-MODULENAME - a meta package depending upon the default pike version (a'la python-PACKAGE depending upon python2.4-package) pikeX.Y-MODULENAME - package for the specific Pike version regards, marek signature.asc Description: Digital signature
Bug#342031: ITP: public.network.pcap -- Pike interface module for the pcap library
Package: wnpp Severity: wishlist Owner: Marek Habersack <[EMAIL PROTECTED]> * Package name: public.network.pcap Version : 1.2 Upstream Author : Bill Welliver <[EMAIL PROTECTED]> * URL : http://modules.gotpike.org/module_info.html?module_id=9 * License : (GPL, LGPL, MPL) Description : Pike interface module for the pcap library This module provides an interface to the pcap packet capture library. -- System Information: Debian Release: testing/unstable APT prefers dapper-updates APT policy: (500, 'dapper-updates'), (500, 'dapper-security'), (500, 'dapper') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.15-6-k7 Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#342018: ITP: public.protocols.syslog -- Pike module implementing the Syslog protocol
Package: wnpp Severity: wishlist Owner: Marek Habersack <[EMAIL PROTECTED]> * Package name: public.protocols.syslog Version : 1.1 Upstream Author : Bill Welliver <[EMAIL PROTECTED]> * URL : http://modules.gotpike.org/module_info.html?module_id=7 * License : (GPL, LGPL, MPL) Description : Pike module implementing the Syslog protocol A Pike module containing functions for decoding and encoding Syslog messages. -- System Information: Debian Release: testing/unstable APT prefers dapper-updates APT policy: (500, 'dapper-updates'), (500, 'dapper-security'), (500, 'dapper') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.15-6-k7 Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#341999: ITP: public.tools.configfiles -- Pike module for accessing ini-style configurations
Package: wnpp Severity: wishlist Owner: Marek Habersack <[EMAIL PROTECTED]> * Package name: public.tools.configfiles Version : 1.0 Upstream Author : Bill Welliver <[EMAIL PROTECTED]> * URL : http://modules.gotpike.org/module_info.html?module_id=25 * License : (GPL) Description : Pike module for accessing ini-style configurations A simple module for reading and writing ini-style configurations from within Pike programs. -- System Information: Debian Release: testing/unstable APT prefers dapper-updates APT policy: (500, 'dapper-updates'), (500, 'dapper-security'), (500, 'dapper') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.15-6-k7 Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#341996: ITP: public.parser.xml2 -- libxml2-based XML parser module for Pike
Package: wnpp Severity: wishlist Owner: Marek Habersack <[EMAIL PROTECTED]> * Package name: public.parser.xml2 Version : 1.36 Upstream Author : Bill Welliver <[EMAIL PROTECTED]> * URL : http://modules.gotpike.org/module_info.html?module_id=20 * License : (GPL, LGPL, MPL) Description : libxml2-based XML parser module for Pike The software is a Pike module that wraps the libxml2 and libxslt1 libraries to provide access to their functionality from Pike programs. -- System Information: Debian Release: testing/unstable APT prefers dapper-updates APT policy: (500, 'dapper-updates'), (500, 'dapper-security'), (500, 'dapper') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.15-6-k7 Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
php5 + apache2 + FastCgiExternalServer, anyone?
Hey folks, Has anyone gotten the setup mentioned in the subject to work as advertised? The config I'm using is: Options ExecCGI SetHandler fastcgi-script FastCGIExternalServer /fcgi-bin/php5-cgi -host 127.0.0.1: AddType application/x-httpd-fastphp5 .php Action application/x-httpd-fastphp5 /fcgi-bin/php5-cgi And yet apache2 doesn't want to connect to the -host host, instead it launches the binary mentioned in Action and uses it to handle the requests. Maybe I'm reading the docs incorrectly (http://www.fastcgi.com/mod_fastcgi/docs/mod_fastcgi.html#FastCgiExternalServer) but apache fails to serve the PHP requests if /fcgi-bin/ is not found in the docroot and if the php5-cgi binary doesn't exist in it. Am I doing something wrong or is it, perhaps, a bug in the mod_fastcgi module (or documentation thereof)? I would appreciate any help/hints/doc pointers regarding the issue, tia, marek signature.asc Description: Digital signature
debian-devel-changes question/request
Hey folks, It's just a simple question/request. Would it be possible to include custom headers in the messages sent to debian-devel-changes that would contain the package name, version and distribution, like so: X-Debian-Package: foo X-Debian-PackageVersion: 1.2.3-1 X-Debian-PackageDist: unstable Parts of the information can be parsed from the subject line, provided that the subject isn't munged by some anti-spam software, but I think it would be easier to automate processing of such mails wherever needed (yes, I need it for a small project of mine, that's why I'm asking :) - but I think it could be useful in general). Thoughts? thanks, marek signature.asc Description: Digital signature
Re: Bug#218832: ITP: libnettle -- a low-level cryptographic library
On Sat, Nov 08, 2003 at 08:57:36PM -0500, John Belmonte scribbled: > Marek Habersack wrote: > >In fact, I'm considering adding a > >list of files in the library and their associated licenses to the > >README.Debian in the package once it hits Sid (I've uploaded it already). I > >grew aware of problems with licensing while working on Caudium. We, as the > >Caudium Group, don't own the copyrights to all the code, but we do own a > >huge part of it. I usually license my code under LGPL/MPL (considering IPL > >now) but Caudium as a whole is still GPL. In such a crazy situation, it is > >crucial that users/developers have detailed information about what parts of > >a package are licensed under which licenses and, first of all, that there > >exist various licenses to begin with. It really saves one a lot of trouble > >later on. > > To be complete, consider that you'd have to list interdependencies too. > Take the example once more of an application that can't use GPL'd > software. You said it might still use libnettle by linking statically > and only using parts not under the GPL. But what if one of those parts > uses another that is GPL'd? The application author may not even realize That's not direct linking then. If it was to force your application to be GPL, then spawning /bin/bash from your non-GPL application would also mean you'd have to GPL the app (since bash uses libreadline which is GPL). Or, following that example - your shell scripts would have to be GPL. Furthermore, calling down to the kernel code would mean both libc and your app would have to be GPL (that is, if the linux kernel copyright didn't contain the exemption notice for that case). You can always override the GPL by using an LGPL "proxy code" which your application links to. It might be as dumb as a set of function wrappers. And in such instance the knowledge which particular parts of code are under GPL is also valuable - since you can limit the wrappers only to those parts of code while calling the rest directly. > it. Even if he was careful and looked at which object files where > linked into his app, it still doesn't account for the possibility of a > non-GPL'd part using macros, inline code, etc. from a GPL'd part. Inlined code doesn't count IIRC. In any case, if you are concerned with such issues then the proxy idea above is your way to go. regards, marek signature.asc Description: Digital signature
Re: Bug#218832: ITP: libnettle -- a low-level cryptographic library
On Sat, Nov 08, 2003 at 08:11:53PM -0500, John Belmonte scribbled: [snip] > I'm interested in the notion of license metadata for file packages (in > the general sense)-- what the semantics would be, whether or how it > could be useful, etc. As someone pointed out, there is no such thing > for Debian packages. But ITP's do have the "License" field, so I was > asking about the semantics of an entry like "GPL, LGPL, public domain". > Here it means that parts of the package are covered by one license, > parts by another, etc. It doesn't always mean this. See [snip] My point was to show the prospective reviewers of the ITP that the package is heterogenous license-wise. Since putting only GPL in the license would be presenting a false image of the status quo, I chose to list the licenses enumerated by the author of the library as the ones present in the package as a whole. As I stated in one mail (I think) I trust that the precision of information is crucial in cases like this. In fact, I'm considering adding a list of files in the library and their associated licenses to the README.Debian in the package once it hits Sid (I've uploaded it already). I grew aware of problems with licensing while working on Caudium. We, as the Caudium Group, don't own the copyrights to all the code, but we do own a huge part of it. I usually license my code under LGPL/MPL (considering IPL now) but Caudium as a whole is still GPL. In such a crazy situation, it is crucial that users/developers have detailed information about what parts of a package are licensed under which licenses and, first of all, that there exist various licenses to begin with. It really saves one a lot of trouble later on. regards, marek signature.asc Description: Digital signature
Re: Bug#218832: ITP: libnettle -- a low-level cryptographic library
On Thu, Nov 06, 2003 at 05:21:59PM -0500, John Belmonte scribbled: > Marek Habersack wrote: > >Quoting from the nettle manual: > > > > Nettle is distributed under the GNU General Public License (GPL) (see the > > file COPYING for details). However, most of the individual files are dual > > licensed under less restrictive licenses like the GNU Lesser General > > Public > > License (LGPL), or are in the public domain. This means that if you don't > > use the parts of nettle that are GPL-only, you have the option to use the > > Nettle library just as if it were licensed under the LGPL. To find the > > current status of particular files, you have to read the copyright notices > > at the top of the files. > > The upstream author can make this statement because people compiling the > library can go into the makefile and disable various (say GPL) source > files and prevent them from being included in the library, thus > producing a library file that is (for example) under the LGPL. > > However in your package, assuming it is compiling GPL'd modules and > including them in the library, is producing an object file governed by > the terms of the GPL. Therefore your license field should read only "GPL". Users still have a choice of using only the non-GPL parts of the library by linking with the static version of the lib and pulling only the non-GPL objects from there. marek signature.asc Description: Digital signature
Re: Bug#218832: ITP: libnettle -- a low-level cryptographic library
On Thu, Nov 06, 2003 at 02:50:52PM -0500, John Belmonte scribbled: > Chad Walstrom wrote: > >>My guess is that it means some parts of the library are under GPL, some > >>under LGPL, and some in the public domain. If that's the case, the > >>library as a whole must be considered to be under the GPL, correct? > > > >Not necessarily. If work is done on the Public Domain portion of code, > >and the author wants to continue releasing changes to that portion under > >the same license, he or she may do so without "poisoning" it with GPL. > >The same is true for the LGPL portions of the library. GPL doesn't > >conflict with LGPL or Public Domain in any way. > > That's fine, but if I'm developing an application that may not use GPL'd > libraries and only those under LGPL, BSD, etc., the proposed license > field of libnettle is useless, and perhaps misleading. It is not. It forces you to do some more research, which is what you should do anyway with libraries like nettle where individual files may carry different licenses. That way you are warned about the situation. If I say "GPL" you will have the false impression you cannot use it at all, etc. marek signature.asc Description: Digital signature
Re: Bug#218832: ITP: libnettle -- a low-level cryptographic library
On Thu, Nov 06, 2003 at 02:22:31PM -0500, John Belmonte scribbled: > Marek Habersack wrote: > >>My guess is that it means some parts of the library are under GPL, some > >>under LGPL, and some in the public domain. If that's the case, the > >>library as a whole must be considered to be under the GPL, correct? > > > >Yes, that's the case. I just wanted to highlight the fact that parts of it > >have different licenses. > > If the library as a whole must be under GPL license, how is it > significant that parts of it were once under LGPL or on the public > domain? The purpose of the License field is to tell the user what > license the software in the package is under, not to give a history of > previous or constituent licensing. Quoting from the nettle manual: Nettle is distributed under the GNU General Public License (GPL) (see the file COPYING for details). However, most of the individual files are dual licensed under less restrictive licenses like the GNU Lesser General Public License (LGPL), or are in the public domain. This means that if you don't use the parts of nettle that are GPL-only, you have the option to use the Nettle library just as if it were licensed under the LGPL. To find the current status of particular files, you have to read the copyright notices at the top of the files. That should answer your question - they weren't "once", they still are licensed under the listed licenses and I believe that good information is very important thanks, marek signature.asc Description: Digital signature
Re: Bug#218832: ITP: libnettle -- a low-level cryptographic library
On Thu, Nov 06, 2003 at 11:53:38AM -0500, John Belmonte scribbled: > Marek Habersack wrote: > >* License : GPL, LGPL, Public Domain > > What does this mean exactly? It's a mix of licenses of the source files composing the library. > My guess is that it means some parts of the library are under GPL, some > under LGPL, and some in the public domain. If that's the case, the > library as a whole must be considered to be under the GPL, correct? Yes, that's the case. I just wanted to highlight the fact that parts of it have different licenses. marek signature.asc Description: Digital signature
Re: [coreutils,hppa] - touch broken on hppa
On Thu, Nov 06, 2003 at 10:55:50AM +0100, Santiago Vila scribbled: > On Thu, 6 Nov 2003, Marek Habersack wrote: > > > It seems that touch(1) is broken on hppa: > > > > [...] > > > > The above is on the same machine but not inside the chroot. In the first > > case the version of coreutils is 5.0, in the latter 5.0.91. > > Seems like a bug in coreutils 5.0 which has been fixed in 5.0.91. > I suggest that you ask the buildd maintainer to upgrade the sid chroot > with the most recent coreutils. My mistake above. It's the other way around - the chroot has 5.0.91, and that's what breaks. 5.0 works correctly (5.0.91-2 is the latest in debian). 5.0.1 (IIRC) introduced a new function, utimens, which is a wraper around the system utime and utimes calls. The latter is used only when it is known to work (detected by autoconf) which seems to be the case on hppa, only it seems to fail on hppa... tia, marek signature.asc Description: Digital signature
[coreutils,hppa] - touch broken on hppa
Hello, It seems that touch(1) is broken on hppa: [EMAIL PROTECTED]:~/tmp/pike7.2-7.2.546$ ls -l build/linux-2.4.20-64-parisc64/precompile.sh -rwxr-xr-x1 grendel Debian 3475 Nov 5 22:47 build/linux-2.4.20-64-parisc64/precompile.sh [EMAIL PROTECTED]:~/tmp/pike7.2-7.2.546$ touch 010370 build/linux-2.4.20-64-parisc64/precompile.sh touch: warning: touch 010370' is obsolete; use touch -t 19700103.00' [EMAIL PROTECTED]:~/tmp/pike7.2-7.2.546$ ls -l build/linux-2.4.20-64-parisc64/precompile.sh -rwxr-xr-x1 grendel Debian 3475 Nov 5 22:47 build/linux-2.4.20-64-parisc64/precompile.sh [EMAIL PROTECTED]:~/tmp/pike7.2-7.2.546$ touch -t 19700103.00 build/linux-2.4.20-64-parisc64/precompile.sh [EMAIL PROTECTED]:~/tmp/pike7.2-7.2.546$ ls -l build/linux-2.4.20-64-parisc64/precompile.sh -rwxr-xr-x1 grendel Debian 3475 Nov 5 22:47 build/linux-2.4.20-64-parisc64/precompile.sh [EMAIL PROTECTED]:~/tmp/pike7.2-7.2.546$ touch 010380 build/linux-2.4.20-64-parisc64/precompile.sh touch: warning: touch 010380' is obsolete; use touch -t 19800103.00' [EMAIL PROTECTED]:~/tmp/pike7.2-7.2.546$ ls -l build/linux-2.4.20-64-parisc64/precompile.sh -rwxr-xr-x1 grendel Debian 3475 Nov 5 22:47 build/linux-2.4.20-64-parisc64/precompile.sh [EMAIL PROTECTED]:~/tmp/pike7.2-7.2.546$ uname -a Linux paer 2.4.20-64 #1 Fri Aug 1 23:40:10 UTC 2003 parisc64 GNU/Linux The above is inside the sid chroot and is consistent with the autobuild error at http://buildd.debian.org/fetch.php?&pkg=pike7.2&ver=7.2.546-1&arch=hppa&stamp=1067951372&file=log&as=raw [EMAIL PROTECTED]:~/tmp/pike7.2-7.2.546$ touch 010380 build/linux-2.4.20-64-parisc64/precompile.sh touch: warning: touch 010380' is obsolete; use touch -t 19800103.00' [EMAIL PROTECTED]:~/tmp/pike7.2-7.2.546$ ls -l build/linux-2.4.20-64-parisc64/precompile.sh -rwxr-xr-x1 grendel Debian 3475 Jan 3 1980 build/linux-2.4.20-64-parisc64/precompile.sh The above is on the same machine but not inside the chroot. In the first case the version of coreutils is 5.0, in the latter 5.0.91. Looking at the changelog, the strace output and the source code it seem that what's changed between the versions in touch.c is that the later version uses utimes instead of utime the 5.0 version calls. Strangely, the problem occurs only on hppa. Does anybody have access to any other hppa machines except for those which are accessible for the DDs to confirm the above problem? thanks, marek signature.asc Description: Digital signature
Re: kernel 2.5.73+, fakeroot, debuild - a small problem
On Wed, Jun 25, 2003 at 09:30:32PM +1000, Herbert Xu scribbled: > Marek Habersack <[EMAIL PROTECTED]> wrote: > > > > Running debuild as normal user under the 2.5.73+ kernel results in fakeroot > > actually setting the file ownership to root (or any other uid/gid for that > > matter). The result is that the parts which don't run under fakeroot - > > Why is fakeroot calling the real chown(2)? No idea. Anyhow, I posted to lkml and it seems that the default value for the sysctl was a mistake. It will be corrected in the next Linus' release. But the sysctl itself won't go away. marek pgpviSF0cuA9H.pgp Description: PGP signature
Re: Bug#198665: ITP: pmk -- The pmk project aims to be an alternative to GNU/autoconf (configure scripts).
On Wed, Jun 25, 2003 at 04:03:26AM -0500, Luca - De Whiskey's - De Vitis scribbled: > On Wed, Jun 25, 2003 at 03:18:28AM -0500, Branden Robinson wrote: > > * lose the article > > Why? > > > * do not capitalize the beginning of the description unless a proper > > noun, proper adjective, abbreviation, or acronym requires it > > Why? How about just dropping that autoconf reference from the short description? After all it's not an advertisement but a description of functionality. The full description may refer to autoconf and somewhat compare the two in one or two sentences. So, how about: a tool to configure software sources That would actually sound better than the current autoconf description: automatic configure script builder That assumes the reader knows what the configure scripts are used for. regards, marek pgpcqpeY0tJA0.pgp Description: PGP signature
Re: kernel 2.5.73+, fakeroot, debuild - a small problem
On Wed, Jun 25, 2003 at 08:42:03AM +0200, Andreas Metzler scribbled:
> Marek Habersack <[EMAIL PROTECTED]> wrote:
> > Running debuild as normal user under the 2.5.73+ kernel results in fakeroot
> > actually setting the file ownership to root (or any other uid/gid for that
> > matter).
> [...]
>
> Either there is a big misunderstanding or a big bug in 2.5.73+.
> Are you saying that using fakeroot I can actually do this?
I haven't tested it as I don't use quotas, but look at the relevant XFS
code:
if (restricted_chown &&
(iuid != uid || (igid != gid &&
!in_group_p((gid_t)gid))) &&
!capable(CAP_CHOWN)) {
code = XFS_ERROR(EPERM);
goto error_return;
}
/*
* Do a quota reservation only if uid or gid is actually
* going to change.
*/
if ((XFS_IS_UQUOTA_ON(mp) && iuid != uid) ||
(XFS_IS_GQUOTA_ON(mp) && igid != gid)) {
ASSERT(tp);
code = XFS_QM_DQVOPCHOWNRESV(mp, tp, ip, udqp, gdqp,
capable(CAP_FOWNER) ?
XFS_QMOPT_FORCE_RES : 0);
if (code) /* out of quota */
goto error_return;
}
So if restricted_chown is not in effect and the uid/gid change, the quota
ownership will be shifted to the new uid/gid.
> touch /tmp/breaking.alice.quota
> chmod 666 /tmp/breaking.alice.quota
> fakeroot chown alice /tmp/breaking.alice.quota
> cat < /dev/zero > /tmp/breaking.alice.quota
it would seem it really is possible. Just as is:
$ whoami
grendel
$ ls -ld .
drwxr-xr-x2 grendel grendel 6 2003-06-25 11:28 .
$ mkdir test
$ ls -ld test
drwxr-xr-x2 grendel grendel 6 2003-06-25 11:29 test
$ chown root:root test
$ ls -ld test
drwxr-xr-x2 root root6 2003-06-25 11:29 test
$ rm -r test
rm: remove write-protected directory test'? y
$ ls -ld test
ls: test: No such file or directory
regards,
marek
pgpZkGbNAiA9c.pgp
Description: PGP signature
Re: kernel 2.5.73+, fakeroot, debuild - a small problem
On Tue, Jun 24, 2003 at 10:57:36PM -0400, Aaron M. Ucko scribbled: > Marek Habersack <[EMAIL PROTECTED]> writes: > > > 2. Modify fakeroot to check the kernel version, the type of fs on which it > > is currently working and have it issue a sysctl to enable > > restricted_chown. It looks better than #1 but it might incurr > > Er, is this even possible as an ordinary user? Of course not. fakeroot would have to actually be suid root - as I said, none of the solutions were perfect. > > 5. Influence the XFS/kernel maintainers to change the default value of > > restrict_chown to enabled. > > I agree that this is the best solution. I'm beginning to think than it really is. marek pgphQaH7vxrVE.pgp Description: PGP signature
Re: kernel 2.5.73+, fakeroot, debuild - a small problem
On Tue, Jun 24, 2003 at 09:17:36PM -0400, Colin Walters scribbled: > On Tue, 2003-06-24 at 18:34, Marek Habersack wrote: > > > 5. Influence the XFS/kernel maintainers to change the default value of > > restrict_chown to enabled. > > I think they really should do this. Having people be able to give away > files is something that you usually *don't* want by default. Indeed. I'm wondering what's the reason for that option. > If they give away a file in XFS, does it still count against their > quota? Not from what I see. It seems that the quota is updated. Now that can be a nice way to hog somebody else's quota... marek pgpeHX9WdOdY2.pgp Description: PGP signature
Re: Bug#198665: ITP: pmk -- The pmk project aims to be an alternative to GNU/autoconf (configure scripts).
On Tue, Jun 24, 2003 at 06:21:18PM -0400, Jim Penny scribbled: [snip] > > > > > Description field is inappropriate, use something like: > > > > > > > > > Description: A GNU/autoconf alternative. > > > > > > Try "an alternative to GNU autoconf" or "a substitute for GNU > > > > autoconf", to avoid confusion with Debian's alternatives system. > > > It's not quite a substitute, as it won't reuse autoconf's configs > > > etc. How about "A tool for configuring software source similar to > > > GNU Autoconf"? > > > > No, actually, that is ambiguous. Read literally, it means that only > software source similar to GNU Autoconf can be configured with this True > tool. You really mean: > > A tool, similar to GNU Autoconf, for configuring software > > Admittedly this is ugly. It may also be really inaccurate. I have no > idea of how similar to GNU Autoconf the tool is. I hope that it is not > very similar at all. Not in the way it works, but similar in the function it performs. > > Perhaps: > > A tool to configure software (GNU Autoconf also has this purpose) It lacks 'source' which would be a misinformation, maybe: A tool to configure software source, functional equivalent to GNU Autoconf Exactly 75 chars and quite to the point, IMHO. marek pgp5de9q69GdB.pgp Description: PGP signature
Re: Bug#198665: ITP: pmk -- The pmk project aims to be an alternative to GNU/autoconf (configure scripts).
On Tue, Jun 24, 2003 at 05:14:56PM -0500, Luca - De Whiskey's - De Vitis scribbled: > On Tue, Jun 24, 2003 at 10:59:19PM +0200, Marek Habersack wrote: > > It's not quite a substitute, as it won't reuse autoconf's configs etc. How > > about "A tool for configuring software source similar to GNU Autoconf"? > > Sorry for my previous reply to this message, your suggestion is definitely > good. OK, so if there are no more objections, I will proceed with uploading the tool to Debian RSN :) marek pgp4pJwGjpJeA.pgp Description: PGP signature
kernel 2.5.73+, fakeroot, debuild - a small problem
Hey list, Running debuild as normal user under the 2.5.73+ kernel results in fakeroot actually setting the file ownership to root (or any other uid/gid for that matter). The result is that the parts which don't run under fakeroot - e.g. debian/rules won't be able to write to the debian/packagename/ subdirs sometimes. It happens only when the filesystem on which the build is taking place is XFS. This is due to the restrict_chown sysctl which was present in XFS before but never actually implemented. Starting with 2.5.73 XFS does use the setting which works in the way that allows the owner of the directory to give away its subdirectories/files to other users. If restrict_chown is enabled then the old behavior is back, however it defaults to disabled. The problem will affect any situation which involves using fakeroot or other similar packages. I see several solutions to that problem, but none of them seem perfect: 1. Warn the users about the above issue and have them always use fakeroot explicitly in situations like building a deb. This is the worst solution, I think, as it would require all of the debian source packages to be modified. 2. Modify fakeroot to check the kernel version, the type of fs on which it is currently working and have it issue a sysctl to enable restricted_chown. It looks better than #1 but it might incurr performance penalty. OTOH, this solution would be the most painless for the users and the most seamless. 3. Modify debuild or even dpkg-buildpackage to do what fakeroot would do in #2. It would be a partial solution since it would affect only the deb build process. 4. Add code to /etc/init.d/ (mountfs.sh or mountall.sh) to perform the checks from #2 and enable the restricted chown. This would be the most global solution effectively setting a policy for Debian systems. It would have the additional effect of maintaining consistency with the old behavior and other filesystems. 5. Influence the XFS/kernel maintainers to change the default value of restrict_chown to enabled. Comments? marek pgpLJr1EiKlFD.pgp Description: PGP signature
Re: Bug#198665: ITP: pmk -- The pmk project aims to be an alternative to GNU/autoconf (configure scripts).
On Tue, Jun 24, 2003 at 02:52:20PM -0500, Steve Langasek scribbled: > On Tue, Jun 24, 2003 at 02:44:17PM -0500, Luca - De Whiskey's - De Vitis > wrote: > > On Tue, Jun 24, 2003 at 09:30:31PM +0200, Marek Habersack wrote: > > [...] > > > Description : The pmk project aims to be an alternative to > > > GNU/autoconf (configure scripts). > > > > Description field is inappropriate, use something like: > > > Description: A GNU/autoconf alternative. > > Try "an alternative to GNU autoconf" or "a substitute for GNU autoconf", > to avoid confusion with Debian's alternatives system. It's not quite a substitute, as it won't reuse autoconf's configs etc. How about "A tool for configuring software source similar to GNU Autoconf"? marek pgpfTbKKcA2ES.pgp Description: PGP signature
Re: Bug#198665: ITP: pmk -- The pmk project aims to be an alternative to GNU/autoconf (configure scripts).
On Tue, Jun 24, 2003 at 02:44:17PM -0500, Luca - De Whiskey's - De Vitis scribbled: > On Tue, Jun 24, 2003 at 09:30:31PM +0200, Marek Habersack wrote: > [...] > > Description : The pmk project aims to be an alternative to > > GNU/autoconf (configure scripts). > > Description field is inappropriate, use something like: > > Description: A GNU/autoconf alternative. Good point. I just cut and pasted it from their about page out of laziness :) thanks, marek pgpEEQwotSBt8.pgp Description: PGP signature
Bug#198665: ITP: pmk -- The pmk project aims to be an alternative to GNU/autoconf (configure scripts).
Package: wnpp Version: unavailable; reported 2003-06-24 Severity: wishlist * Package name: pmk Version : 0.4.5 Upstream Author : Damien Couderc & Xavier Santolaria * URL : http://premk.sf.net/ * License : BSD Description : The pmk project aims to be an alternative to GNU/autoconf (configure scripts). First a quote from the about page for the project: Our primary goals are : * Avoid the use of scripts in packages that can hide trojans. * Try to keep the needed dependancies near from zero (actually we're at zero). * Make it easy to use for users and developpers. * Provide the package in a free and usable license for everybody (BSD). Their goals seem to be met so far. The whole thing is written in C, doesn't depend on perl/m4/shell etc., it's rather easy to use featuring a simple config file format, autoconf compatibility (output-wise), is supported on quite a few software platforms (including Debian). The system defaults are configured in a global config file which makes the usage pretty consistent accross all the installations. -- System Information: Debian Release: testing/unstable Architecture: i386 Kernel: Linux beowulf 2.5.73-mm1 #1 Tue Jun 24 15:31:14 CEST 2003 i686 Locale: LANG=pl_PL, LC_CTYPE=pl_PL
Re: Can a polish speaker please translate this?
On Sat, Jun 21, 2003 at 05:07:36PM -0400, Jaldhar H. Vyas scribbled: > I got a bug report in what seems to be Polish. Unfortunately, babelfish > can't handle it. Although I have a good idea of what it might be saying, > just to make sure can someone translate it for me? Very thoughtful user, indeed Oh well, below is the translation > Jaldhar H. Vyas <[EMAIL PROTECTED]> > La Salle Debain - http://www.braincells.com/debian/ > > -- Forwarded message -- > From: [EMAIL PROTECTED] > Resent-From: [EMAIL PROTECTED] > To: [EMAIL PROTECTED] > Resent-cc: [EMAIL PROTECTED] (Jaldhar H. Vyas) > Date: Sat, 21 Jun 2003 10:58:40 +0200 > Resent-Date: Sat, 21 Jun 2003 09:03:05 UTC > Subject: Bug#198276: Blad przy instalacji pakietu webmin_094woody1 > > Package: webmin > Version: 0.94-7woody1 > > Wystepuje blad przy instalacji pakietu. Pakiet nie jest instalowany w calosci There has been an error installing the package. The package isn't entirely installed. > Powoduje to ze zaden pakiet dodatkowy nie jest instalowany It will cause that none of the additional (probably meant - depending upon this package) packages will be installed. > Brakuje plikow webmin.acl, update.conf i innych The webmin.acl, update.conf and other files are missing > Zapis sesji : Session transcript: > [EMAIL PROTECTED]:~/webmin# dpkg -i webmin_0.94-7woody1_all.deb > Zaznaczenie poprzednio nieznaznaczonego pakietu webmin. > (Odczytywanie bazy danych ... 60487 plików i katalogów obecnie > zainstalowanych.) > Rozpakowanie webmin (z webmin_0.94-7woody1_all.deb) ... > Konfigurowanie webmin (0.94-7woody1) ... the usual dpkg blurb > [EMAIL PROTECTED]:~/webmin# dpkg -i webmin-core_0.94-7woody1_all.deb > Zaznaczenie poprzednio nieznaznaczonego pakietu webmin-core. > (Odczytywanie bazy danych ... 61146 plików i katalogów obecnie > zainstalowanych.) > Rozpakowanie webmin-core (z webmin-core_0.94-7woody1_all.deb) ... > Konfigurowanie webmin-core (0.94-7woody1) ... the same blurb > /etc/webmin/webmin.acl: Nie ma takiego pliku ani katalogu File or directory not found > dpkg: b³±d przetwarzania webmin-core (--install): > podproces post-installation script zwróci³ kod b³êdu 2 > Wyst±pi³y b³êdy podczas przetwarzania: > webmin-core and blurb again > U¿ywam Debiana GNU/Linux 3.0, j±dra 2.4.20 (wlasna kompilacja) I'm using , kernel (own compilation) take care, marek pgpB3yHt5BbNM.pgp Description: PGP signature
Re: perl 5.8 breaks autoconf 2.5
On Thu, Aug 29, 2002 at 11:16:53AM +0100, Colin Watson scribbled: > On Thu, Aug 29, 2002 at 12:10:41PM +0200, Marek Habersack wrote: > > perl-base contains Data/Dumper.pm, that in turn wants to use bytes.pm > > which used to be in perl-modules for perl 5.6 - it doesn't exists in > > perl-modules for 5.8. > > $ dlocate bytes.pm > perl-modules: /usr/share/perl/5.8.0/bytes.pm > $ dpkg -l perl-modules | grep ^ii > ii perl-modules 5.8.0-8Core Perl modules. [EMAIL PROTECTED]:~$ dpkg -l perl-modules | grep ^ii ii perl-modules 5.8.0-9 Core Perl modules. [EMAIL PROTECTED]:~$ dpkg -L perl-modules | grep bytes.pm [EMAIL PROTECTED]:~$ > > Dumper is used by autom4te in autoconf 2.53 - can anybody _please_ fix > > it? > > Works for me, even when forcing it to encounter the piece of code that > does 'use bytes;': Doesn't work for me, sorry... marek pgpHbRBxzR1ji.pgp Description: PGP signature
perl 5.8 breaks autoconf 2.5
Hello *, perl-base contains Data/Dumper.pm, that in turn wants to use bytes.pm which used to be in perl-modules for perl 5.6 - it doesn't exists in perl-modules for 5.8. Dumper is used by autom4te in autoconf 2.53 - can anybody _please_ fix it? TIA, marek pgpZqS5XXntrp.pgp Description: PGP signature
Re: Spidermonkey library name
On Sun, Aug 18, 2002 at 04:57:56PM +0200, Federico Mennite scribbled: > Hi, > I'm actually partecipating in the development of an IRC bot formely know > as eggdrop. > In the development branch the support for javascript, as funtionality > extension, has been added. > Recently we noticed that our configure script failed to correctly detect > spidermonkey on debian systems because of the renaming from libjs to > libsmjs. > By reading the package's changelog I learned that the renaming is dued > to another javascript implementation named njs. > > Wouldn't it have been better to have have the njs and the spidermonkey > package conflicting instead of the renaming? > I understand that njs and spidermonkey don't have any other reason to > conflict besides the library name. > I also understand the they have totally different APIs. Yes, and it's yet another reason not to conflict. I see no reason at all not to allow applications using either spidermonkey or njs to coexist on a single system. In fact, it would be a broken approach to create such kind of a conflict. Since njs existed earlier, I have renamed the spidermonkey to that name. The alternative was to invent a soname scheme for spidermonkey - which can be even less desirable than merely changing its name. > Is the renaming somewhat official or known to the upstream authors? I No, there's no reason to bother them with it, I guess. > mean, what if every vendor starts renaming libraries? ;) Well, what is your suggestion in this case (short of conflicting with njs)? > Initially someone suggested me to add smjs to the list of serached > javascript libraries. The solution is quite straight forward, but > thinking about the future I was a bit concerned. How come? In the development version of Caudium I have chosen to let the person compiling the webserver to choose a prefix to the js library (Caudium in the CVS contains spidermonkey support) - and that's what the Debian package for Caudium uses. I can assure you that the name will not change on the Debian system (unless there's a different way to not cause the name clash with njs, of course) so there are no worries about the future. FYI, Caudium contains two glues - one for njs and the other for spidermonkey... > It might become difficult to detect the correct headers matching a > certain library especially if you think about different versions of the > same library. Hmm, I see no reason to keep different versions of the development files for the same library on the system. If you are concerned about the binary compatibility, I guess that the way to go (unless the upstream decide to start using sonames) will be to add a "version" number to the library name on Debian (i.e. *smjs1, *smjs2 etc.) > If you ever tried to detect matching tcl libraries and headers of older > tcl versions with autoconf it might be clearer of what i'm talking about. AC_ARG_WITH(smlib, AC_HELP_STRING([--with-smlib],[Compile with the specified SpiderMonkey library name (without the 'lib' prefix, defaults to 'js')]), caudium_cv_smlib=$withval, caudium_cv_smlib=js) AC_CHECK_PROGS(perl, perl perl5, x) if test x$perl != xx ; then PERL_LDFLAGS=$perl -MExtUtils::Embed -e ldopts else PERL_LDFLAGS="" fi AC_CHECK_LIB(m, cos) AC_CHECK_LIB(crypt, crypt) AC_CHECK_LIB(dl, dlopen) dnl this is required if SpiderMonkey is compiled in the thread safe mode AC_CHECK_LIB(nspr4, PR_Malloc) dnl SpiderMonkey _may_ be compiled with Perl support AC_CHECK_LIB(perl, PL_gid) OLD_LIBS="$LIBS" LIBS="$PERL_LDFLAGS $LIBS" SM_LIBS="" AC_CHECK_LIB($caudium_cv_smlib, JS_NewContext, AC_DEFINE(HAVE_LIB_SMJS, 1, [Define if you have the SpiderMonkey library installed]) SM_LIBS="$SM_LIBS -l$caudium_cv_smlib $PERL_LDFLAGS" ) LIBS="$OLD_LIBS" dnl try to find the jsapi.h file SM_CFLAGS="-DXP_UNIX" AC_MSG_CHECKING([the SpiderMonkey CFLAGS]) for d in $prefix/include/$caudium_cv_smlib $prefix/include ; do if test -f $d/jsapi.h ; then SM_CFLAGS="$SM_CFLAGS -I$d" break fi done AC_MSG_RESULT([$SM_CFLAGS]) AC_SUBST(SM_CFLAGS) AC_SUBST(SM_LIBS) The above is cut-n-pasted straight from the caudium configure.ac file. As you can see, it's pretty straightforward. > These may seem weak points given that autoconf gives enough flexibily to > test everything. I just want to know your point of view and eventually > avoid a tcl-like configure hell :) There will be no hell. The current situation is, IMO, the cleanest possible solution for now. If I started using own soname scheme, then in the future there might be a clash with the upstream should they start using it. Right now, the difference is minimal. regards, marek pgpaoeja8q9pq.pgp Description: PGP signature
Re: XFree 4.2.0 - again
** On Apr 16, Andreas Metzler scribbled: > Marc Wilson <[EMAIL PROTECTED]> wrote: > > On Tue, Apr 16, 2002 at 12:23:27AM -0400, Sean Middleditch wrote: > >> If you have one of the 3 chipsets only supported in 4.2, there is > >> nothing stopping you from installing that. > [...] > > > One of them is Matrox's G550, one of them is one or another of the > > Radeon's, but what's the third? > > Probably Geforce4 (usable with the nonfree Nvidia-driver on 4.1.*) or > some Laptop-Chipset (Savage-something?) Trident-something (CyberBlade, I think) as used in Toshiba Satellite PRO 5600 (IIRC) - works well with the VESA on 4.1, though :) marek pgpCxRRWNzCIs.pgp Description: PGP signature
Re: XFree 4.2.0 - again
** On Apr 16, Manoj Srivastava scribbled: > >>"Lasse" == Lasse Karkkainen <[EMAIL PROTECTED]> writes: > Lasse> Time to throw some gasoline on the flames ... Branden apparently is > Lasse> incapable of releasing it. So, I suggest that anyone, with enough > Lasse> knowledge and TIME, reading this, would volunteer as XFree package > Lasse> maintainer. Branden's comments suggest that he just doesn't have > Lasse> enough time for that. > > This demonstrates you have no clue what it takes to package > and test something the size and complexity of X. It also shows you do > not have the commitment to quality that characterizes debian. To give the guy a clue, Red Hat (please, don't start another flamewar anyone :)) hires a full-time employee to _mostly_ work on the XFree packages. That should even convice Lasse The Troll that there must be something hard in packaging such a beast (I hope it will make it into his nut sized brain... :>) marek p.s. and I found the poster on Branden's XFree page very amusing :P pgpNtzaMvpZtt.pgp Description: PGP signature
Re: step by step HOWTO switch debian installation into utf-8
** On Sep 06, Radovan Garabik scribbled: [snip] > > I noticed that it also fails to process fome TTF fonts (check out > > http://curiosity.de/downloads/fonts/curefonts.zip - most of them get > > ignored when generating fonts.dir) > > they are not complete - ttmkfdir generates lines only for > encodings the font contains all the chars of (obviously, > very few - if any - ucs fonts pass this test) > Use -c option with such fonts. OK, thanks. Will use just that :) > > > > > > I have however other problems with ttf fonts - they are > > > EXTREMELY slow. When I use arialuni.ttf (25MB font with the best > > > unicode coverage) as main font in konqueror, just drawing a page > > > in ASCII takes 2 minutes (PIII 600 MHz). During those 2 > > Are you using the freetype backend? > > > > freetype backend, xfs font server and xfs-ttf font server all > seem to take the same long time. > I tried xtt backend but I was not succesful in setting it up. I must say that I don't have speed/stability problems on my Sid machine with the Bitstream Cyberbit font (http://www.ccss.de/slovo/unifonts.htm) which is also quite large (13MB). Nevertheless, fact is that the fixed font works the best :)). I just wish I could make GNOME display the wide fonts correctly in the GUI elements... marek -- Visit: http://caudium.net - the Caudium WebServer /* A completely unrelated fortune */ They spell it "da Vinci" and pronounce it "da Vinchy". Foreigners always spell better than they pronounce. -- Mark Twain pgpLNea3LFHAR.pgp Description: PGP signature
Re: step by step HOWTO switch debian installation into utf-8
** On Sep 05, Radovan Garabik scribbled: > On Wed, Sep 05, 2001 at 02:47:26PM +0200, Marek Habersack wrote: > > are set to the fixed-misc USC version and it seems to work fine. The only > > problem I have found is with the Unicode TTF fonts - mkttfdir doesn't > > generate correct fonts.dir file for those AFAICT - all entries have their > > charset set to ISO-8859-1 in the generated file. > > use ttmkfdir instead. It still does not generate 10646 encoding in output, > but at least it will put there all the encodings that the font covers, > and you can add 10646 entry by hand. I noticed that it also fails to process fome TTF fonts (check out http://curiosity.de/downloads/fonts/curefonts.zip - most of them get ignored when generating fonts.dir) > I have however other problems with ttf fonts - they are > EXTREMELY slow. When I use arialuni.ttf (25MB font with the best > unicode coverage) as main font in konqueror, just drawing a page > in ASCII takes 2 minutes (PIII 600 MHz). During those 2 Are you using the freetype backend? marek -- Visit: http://caudium.net - the Caudium WebServer /* A completely unrelated fortune */ Men will always be men -- no matter where they are. -- Harry Mudd, "Mudd's Women", stardate 1329.8 pgp2UohulSyp4.pgp Description: PGP signature
Re: step by step HOWTO switch debian installation into utf-8
** On Sep 05, Brian May scribbled: > >>>>> "Marek" == Marek Habersack <[EMAIL PROTECTED]> writes: > > Marek> Or just put LANG=en_GB in /etc/environment > > Hmmm. Might be worth trying. However, either this is going to override > the language chosen by gdm, or gdm is going to override this. Not an > ideal solution. I use this on my machine and have the locale set correctly to this value when starting GDM. From what I could see, gnome-session reads the LANG= variable and uses its value. I have set GNOME up so that all system fonts are set to the fixed-misc USC version and it seems to work fine. The only problem I have found is with the Unicode TTF fonts - mkttfdir doesn't generate correct fonts.dir file for those AFAICT - all entries have their charset set to ISO-8859-1 in the generated file. marek -- Visit: http://caudium.net - the Caudium WebServer /* A completely unrelated fortune */ Gnagloot, n.: A person who leaves all his ski passes on his jacket just to impress people. -- Rich Hall, "Sniglets" pgp8Lqa5l14zh.pgp Description: PGP signature
Re: step by step HOWTO switch debian installation into utf-8
** On Sep 04, Daniel Burrows scribbled: [snip] > > - in the configuration screen manually type "en_GB", but this doesn't > > seem to do anything. > > This may not be the answer you want, but what about adding: > export LC_ALL=en_GB > > or something similar at the front of ~/.xsession? Or just put LANG=en_GB in /etc/environment marek -- Visit: http://caudium.net - the Caudium WebServer /* A completely unrelated fortune */ We are all worms. But I do believe I am a glowworm. -- Winston Churchill pgpqcjGulaNoG.pgp Description: PGP signature
Re: ITP: tdb (Trivial DataBase)
** On May 08, Wichert Akkerman scribbled: > Previously Marek Habersack wrote: > > Put that way it makes perfect sense. But why use libtool then? > > last time I checked they didn't use libtool, although that might > have changed since then. 1.0.3 most definitely uses it :) > > > It might seem that they are planning/thinking of making it a bit larger > > project. > > That's not what I hear from its authors :) OK :) - that was just an assumption based on the presence of libtool :) > > Would it be feasible if only a tdb-dev package existed with an .a > > archive and a set of manpages/includes - at least it would be > > integrated with debian that way? > > That's not a bad plan. The packages are ready - tdb-dev, tdb-tools and tdb1 total 45k, the sources including diffs total 140k, so the package isn't dramatically large. Maybe it would make sense to upload it all? Or should I just make that single package as written above? marek -- Visit: http://caudium.net - the Caudium WebServer /* A completely unrelated fortune */ I think that I shall never see A billboard lovely as a tree. Indeed, unless the billboards fall I'll never see a tree at all. -- Ogden Nash pgp5C9WNomtLH.pgp Description: PGP signature
Re: ITP: tdb (Trivial DataBase)
** On May 08, Wichert Akkerman scribbled: > Previously Marek Habersack wrote: > > I plan to write an extension to Pike that uses tdb - it should be used as a > > shared library in that case. The upstream sources generate a well working > > .so, so I thought it might be nice to have it in Debian. Also, there might > > be some code in Caudium that will also use tdb. I'm sure more people would > > use it as well. > > My point is that that's not how tdb is meant to be used: instead of > a shared library the idea is to directly copy the tdb source in your > program. That's why tridge and rusty worked very hard to keep it > under 1000 lines (it's actually slightly larger now unfortunately). Put that way it makes perfect sense. But why use libtool then? It might seem that they are planning/thinking of making it a bit larger project. Would it be feasible if only a tdb-dev package existed with an .a archive and a set of manpages/includes - at least it would be integrated with debian that way? If anybody would like to use tdb it would be a snap to install the package and simply include libtdb.a in their project. I mean, it would give a feeling of completeness as far as Debian is concerned - no need to download anything and install from tarballs, just get the deb. marek -- Visit: http://caudium.net - the Caudium WebServer /* A completely unrelated fortune */ When man calls an animal "vicious", he usually means that it will attempt to defend itself when he tries to kill it. pgpabveRHdcPr.pgp Description: PGP signature
Re: ITP: tdb (Trivial DataBase)
** On May 08, Wichert Akkerman scribbled: > Previously Marek Habersack wrote: > > I intent to package tdb (the Trivial Database) which is a GDBM work-alike. > > The tdb, unlike GDBM, has support for multiple simultaneous writers and > > internal locking to protect from overlapped writes. From the upstream > > readme: > > tdb is definitely an excellent little tool. However how it was written > to be directly included in a programs source instead of being used as > a shared library, so I'm not quite sure what use a package of it would > be? I plan to write an extension to Pike that uses tdb - it should be used as a shared library in that case. The upstream sources generate a well working .so, so I thought it might be nice to have it in Debian. Also, there might be some code in Caudium that will also use tdb. I'm sure more people would use it as well. marek -- Visit: http://caudium.net - the Caudium WebServer /* A completely unrelated fortune */ "Go to Heaven for the climate, Hell for the company." -- Mark Twain pgpGr9R9m1vBN.pgp Description: PGP signature
ITP: tdb (Trivial DataBase)
Hello, I intent to package tdb (the Trivial Database) which is a GDBM work-alike. The tdb, unlike GDBM, has support for multiple simultaneous writers and internal locking to protect from overlapped writes. From the upstream readme: This is a simple database API. It was inspired by the realisation that in Samba we have several ad-hoc bits of code that essentially implement small databases for sharing structures between parts of Samba. As I was about to add another I realised that a generic database module was called for to replace all the ad-hoc bits. I based the interface on gdbm. I couldn't use gdbm as we need to be able to have multiple writers to the databases at one time. The packages are ready and waiting for upload if I'm OK-ed to package it :) TIA, marek -- Visit: http://caudium.net - the Caudium WebServer /* A completely unrelated fortune */ Necessity has no law. -- St. Augustine pgpWTuyh5UMWT.pgp Description: PGP signature
Re: Developer Behavior
** On Jan 09, Marcin Owsiany scribbled: > On Tue, Jan 09, 2001 at 08:03:40PM +1100, Hamish Moffatt wrote: > > > How can you be on the keyring while not having an account on auric? > > > Either you are a developer and you have both, or you are not a developer > > > and you have neither. > > > > Probably you can't. I don't know the NM process well enough to be sure. > > > > A couple of people mentioned that they do not have an account, > > not that they have not been approved. > > People tend to put a '==' between the above two... I just wonder how is the NM queue term defined. Is it a FIFO queue? Or rather a random access array? I'm asking because looking at the people that became new maintainers I see folks who applied 5 months after me and already are maintainers. It's OK with me - I suppose there are some problems with my application, but it would be nice if somebody contacted me (and probably others that are in the same situation - I didn't browse the entire database :)). I will wait patiently, I'm just wondering about all that stuff. marek -- Visit: http://caudium.net - the Caudium WebServer /* A completely unrelated fortune */ If you want me to be a good little bunny just dangle some carats in front of my nose. -- Lauren Bacall pgpUXVVZJ1YBd.pgp Description: PGP signature
Re: Developer Behavior [new maintainer waiting period]
** On Jan 08, Adam Heath scribbled: [snip] > > Hmm... http://debian.vip.net.pl/caudium, > > http://debian.vip.net.pl/caudium-unstable - does that prove _anything_ about > > me? I guess not and the NM process is what there's needed to confirm whether > > the applicant can do anything good for the project or not and the person to > > judge that is the person assigned to the applicant. Having said that, I want > > to ask what did you mean by writing the above statement? > > Note that I did not flaunt my deeds to the new maintainer team. My nightly neither do I do that... It's just that I _really_ want to work and contribute to Debian and being a de-facto developer but not _Debian_ developer my contributions are very limited. I have maintained the above packages for quite some time and posted to this list only _once_ - it was an ITP which passed without echo. One would expect some kind of reaction - "go away", "ok, you can do that", "no, don't do that" etc. etc. OK, I'm going off topic :-))) Anyhow, my problem is that I have something (and possibly more) to contribute, I have a will to contribute, I have the skills to contribute but have no way to contribute. And this is the _only_ problem I have wrt Debian. > emails would have been a part of a normal developer updating his fellow > maintainers. I was perfectly content to keep all those debs in a staging > area, while I waited for an account, as I knew the work would eventually be > placed in debian. Well, I've been waiting for so long and I'll wait more, but that's not the problem we should discuss. The problem is why does it take so long? Wouldn't it be good to add additional "sorting" measure to applicants that have been accepted? Just take a look at how many packages they created/maintain (outside of debian, of course) install those packages, take a look at their quality etc. and then, based on those _technical_ criteria, file a vote with DAM on that maintainer? Even in a democratic system there are priorities and the Debian priority wrt NMs should be the technical skills of the person being investigated. The other things like attitude, communication capability, philosophy will come up when the person is in Debian whether we like it or not... > To restate, I did the work, not because I wanted to get in to debian, but > because the work had to be done, and no one else was working on those packages > at the time.~ I can only say I did the same with the above (and more) packages. But since I've applied to become a Debian developer I would expect and wish them to get into Debian... marek -- Visit: http://caudium.net - the Caudium WebServer /* A completely unrelated fortune */ Man is the best computer we can put aboard a spacecraft ... and the only one that can be mass produced with unskilled labor. -- Wernher von Braun pgptnujVZB2hj.pgp Description: PGP signature
Re: Developer Behavior [new maintainer waiting period]
** On Jan 08, Adam Heath scribbled: > On Mon, 8 Jan 2001, Vince Mulhollon wrote: > > > Yes, it took me about a year's wait also. > > I created my pgp key on Dec. 27, 1997. 2 weeks later, I was a > developer. Granted, this was before the closing, and the reorganization, but > even for that time frame, that was fast. > > What I'm trying to say is that if you prove beyond a shadow of a doubt that > you would benefit the project, you will be accepted. Hmm... http://debian.vip.net.pl/caudium, http://debian.vip.net.pl/caudium-unstable - does that prove _anything_ about me? I guess not and the NM process is what there's needed to confirm whether the applicant can do anything good for the project or not and the person to judge that is the person assigned to the applicant. Having said that, I want to ask what did you mean by writing the above statement? marek -- Visit: http://caudium.net - the Caudium WebServer /* A completely unrelated fortune */ Die, v.: To stop sinning suddenly. -- Elbert Hubbard pgpNyTDUpDVpO.pgp Description: PGP signature
Re: Developer Behavior
** On Jan 08, Aaron Lehmann scribbled: > On Mon, Jan 08, 2001 at 10:35:51AM -0600, Vince Mulhollon wrote: > > Now that you and Eray have publically complained about the team's slowness, > > that means that after you complete the NM process, you both be joining the > > NM team to help your fellow developers get processed quicker, right? > > > > I'm not being sarcastic, my initial account manager who did the interviews > > and stuff had just completed the process a few months ago, so I assume > > you'll be joining the new maintainer team just like he did. > > The problem I'm facing is that my account has not been created. If once Same for me... My application was accepted in September, I applied in June - the only thing missing is the account. I have 8 packages waiting to be uploaded, one more to overtake from the current maintainer (he could/would sponsor it, but I prefer to wait till I'm "legally" in Debian) - all of them are actively maintained, used etc. but aren't in Debian per se. Before somebody steps forward and claims that I'm whining, I'm not - it's just a bit discouraging. We read many speeches here about taking part in the community life, contributing to Debian instead of talking, whining etc. - but it's rather hard to contribute anything when the doors are closed. It's not that I think the DAM or whoever in the NM team is not suited for this task, no, I'm just wondering whether they might need some help/encouragement? [snip] > The DAM is quite busy, and I sympathize with him. However, once > allowed to I would voulenteer to aid him with his duties to expedite > the processes. Lamentably, I have no time to process NMs but if there's any other thing I could do, I'd be more than glad to. marek -- Visit: http://caudium.net - the Caudium WebServer /* A completely unrelated fortune */ "Laugh while you can, monkey-boy." -- Dr. Emilio Lizardo pgpiHCKrXv4oZ.pgp Description: PGP signature
Re: in.telnetd and virtual hosting
* Mikolaj J. Habryn said: > >>>>> "MH" == Marek Habersack <[EMAIL PROTECTED]> writes: > > MH> Both proc and devpts are mounted. Doesn't matter whether I > MH> mount them beforehand or whether a wrapper script does it > MH> after chrooting - the same message appears. I suspected that > MH> the devpts fs just isn't suited to work in multiple instances, > MH> but after reverting the Debian patch it still doesn't work. > > Do you have /dev/ptmx? You need that device to actually open the pty > pair, which is then accessed via the devpts file system. What does > strace say? I do have the device - the devfs works perfectly, failing only on the occasion of execing this daemon. The multiplexer device is both in the /dev and in /virtual/chrootjail/dev. But this is not a problem - the old method of finding the available pty also fails. marek pgptIeyABOljq.pgp Description: PGP signature
Re: in.telnetd and virtual hosting
* Ryan Murray said: > > > Have you tried actually mounting them in the chroot jail and then having > > yes. > > > > > symbolic links to them from the real root? That way there is only one > > > proc,pts directory ever mounted... > > You cannot symlink over a pseudo-root. It must all be below it. > > You are symlinking from the real root to the pseudo root. All the > "real" files are below the pseudo-root. The real root has symlinks > pointing into the pseudo, not the other way around (which is not > possible, as you mention). I see - I didn't read it carefully enough. So you say that I should mount proc and devfs in the chroot jail and then link the real one to them. But this solution seems to be quite limited - what if I need to create another chroot jail (and I'll certainly need to do it) - then I'd have to link the filesystems upwards to the root, which won't work... marek pgpBRm6BVmTMb.pgp Description: PGP signature
Re: in.telnetd and virtual hosting
* Ryan Murray said: > > > to work, although I have no idea how Linux would react to having to having > > > multiple devpts filesystems mounted at once. Probably best to try and > > > see :) > > Both proc and devpts are mounted. Doesn't matter whether I mount them > > Have you tried actually mounting them in the chroot jail and then having yes. > symbolic links to them from the real root? That way there is only one > proc,pts directory ever mounted... You cannot symlink over a pseudo-root. It must all be below it. marek pgpdlQ7tZ8y0j.pgp Description: PGP signature
Re: in.telnetd and virtual hosting
* Daniel Burrows said: > On Mon, Oct 04, 1999 at 10:18:51PM +0200, Marek Habersack was heard to say: > > I'm trying to virtualize in.telnetd to access a chrooted virtual server > > (using tcp_wrappers' twist option and Wietse's chrootuid utility). > > Everything works just fine until the in.telnetd from chrooted location is > > execed. It tries to allocate a pty (via openpty() call), but receives an > > ENOENT error meaning that there are no more free pty pairs available, which > > is not true, of course. If I use the 'spawn' option in hotst.allow I'm > > presented with a login of the normal, non-virtual, server instead of the > > new, chrooted, one. Does anyone know what might be the cause of such > > behavior and perhaps knows a way to virtualize telnetd? > > I don't know a whole lot about telnetd and the intricacies of setting up > chrooted environments -- but that said, what's in /dev in the chroot jail? I > suspect you need to mount a devpts filesystem on /dev/pts for > this > to work, although I have no idea how Linux would react to having to having > multiple devpts filesystems mounted at once. Probably best to try and see :) Both proc and devpts are mounted. Doesn't matter whether I mount them beforehand or whether a wrapper script does it after chrooting - the same message appears. I suspected that the devpts fs just isn't suited to work in multiple instances, but after reverting the Debian patch it still doesn't work. marek pgpx74267Cwas.pgp Description: PGP signature
in.telnetd and virtual hosting
Hi, I'm trying to virtualize in.telnetd to access a chrooted virtual server (using tcp_wrappers' twist option and Wietse's chrootuid utility). Everything works just fine until the in.telnetd from chrooted location is execed. It tries to allocate a pty (via openpty() call), but receives an ENOENT error meaning that there are no more free pty pairs available, which is not true, of course. If I use the 'spawn' option in hotst.allow I'm presented with a login of the normal, non-virtual, server instead of the new, chrooted, one. Does anyone know what might be the cause of such behavior and perhaps knows a way to virtualize telnetd? marek p.s. the virtual server is on another IP, on the aliased interface. pgpPJKiKobgJn.pgp Description: PGP signature
Re: How not to be a nice person (Was: Re: Packages should not Conflict on the basis of duplicate functionality)
* Anthony Towns said: > On Fri, Oct 01, 1999 at 11:53:19PM -0500, The Doctor What wrote: > > The idea was not to say that "since I work for *a company* I'm an > > authority". My point was that I work in the "real world" and have a > > counter example. > > And of course, everyone else on the list doesn't work in the "real world", > and just plays in their own little pointless sandpit. Feh. > > That *is* offensive. Come on! Better stop it now. You know damned well this is not the case. Everyone has their experiences in the real work and world - and everyone has the right to support their speech using the examples and poits from his own life. EVERYONE. And if you take it personal, then I'm sorry. I don't feel offended by what TDW said. marek pgpZayTm40LwI.pgp Description: PGP signature
Re: How not to be a nice person (Was: Re: Packages should not Conflict on the basis of duplicate functionality)
* Craig Sanders said: > > and > > > > > now what is so fucking difficult to understand about that? > > > > the word "deliberate" isn't the first that occurs to me. > > if you can't comprehend that someone might deliberately choose those > words, then that is your problem not mine. such paucity of imagination > is truly sad. No - your attitude is sad. Perhaps you are not educated enough to state your position in a civilized way using strong but NOT insulting words. It's even more said when we realize that you use the Shakespeare's language which has more than enough words and expressions to express anything without using bold language. And before you say that - I use these and worse words myself, but one has to know when and where to use them. This is not one of these places. marek pgprXnNirx9I8.pgp Description: PGP signature
Re: How not to be a nice person (Was: Re: Packages should not Conflict on the basis of duplicate functionality)
* Craig Sanders said: > On Fri, Oct 01, 1999 at 09:06:39PM -0500, The Doctor What wrote: > > I took care in my message above to remove anything offensive towards > > Craig. Unfortunately Craig didn't do the same. > > garbage. you went out of your way to be offensive. to quote the opening > line of your message: > > "Excuse me. I work for TurboLinux." > > the implication here is that you know what you are talking about because > you work for a "real" (i.e. commercial) linux distribution. No, you get it plain wrong. I guess it's just a way of thinking, but how I understand what The Doctor What said about TurboLinux is that he just states that he knows the chores of a Unix administrator. Point. Don't attribute to anyone what he didn't say. > that way here, it's not who you work for that's important, it's what > you've done. Exactly what he said. He's DONE work for TurboLinux. He did it well. He has every right to be proud of it and to draw it in discussion like this. marek pgp5G54mQ8CFD.pgp Description: PGP signature
Problem with the latest potato update
Hi, Latest potato update contains a package, aleph-dev, with a wrong Priority: line which prevents (until manually fixed) the apt update operation, which aborts with: E: Malformed Priority line E: Error occured while processing aleph-dev (NewVersion1) The Priority: line is Priority: optionnal instead of Priority: optional greetings, marek pgpXseTsJbeKt.pgp Description: PGP signature
Re: sash
* Raul Miller said: > On Sat, Sep 25, 1999 at 01:27:51PM +0200, Marek Habersack wrote: > > The proposal, as I can see it, is to write a PAM module that could > > be added to /etc/pam.d/passwd to ask whether the just-changed root > > password should be cloned into the sashroot account. And that's a > > really elegant and clean solution, IMHO. > > If someone wants to write such a module, I'd be more than happy > to include it in the sash package. I would be willing to do so if nobody has volunteered yet. marek pgp4qaCoCHHAU.pgp Description: PGP signature
Re: sash
* Michael Neuffer said: > * Raul Miller ([EMAIL PROTECTED]) [990923 16:15]: > > On Thu, Sep 23, 1999 at 07:32:50AM -0500, Ashley Clark wrote: > > > Couldn't sash include a PAM module that would change the password to > > > match root's password whenever it was changed? Or am I oversimplifying > > > things? > > > > I don't have enough confidence in Debian's pam, yet, to insist that > > everyone that wants to use sash must implement pam support before > > using sash. > > > Depending on PAM would be a fatal mistake. > sash is for situations when your system is FUBARed, > therefore you can not assume that you will still have > a working PAM subsystem either. sash won't ever be linked with dynamic PAM libs since it's static by definition. The proposal, as I can see it, is to write a PAM module that could be added to /etc/pam.d/passwd to ask whether the just-changed root password should be cloned into the sashroot account. And that's a really elegant and clean solution, IMHO. marek pgpB0czxG4I45.pgp Description: PGP signature
Re: (g)mc-4.5.38-2 still broken
* Philip Hands said: > > > No no, it isn't mc script but only function in your ~/.bash_profile or > > > global /etc/profile. > > Exactly that was the point. The function executes in the context of the > > current shell, not in the child shell which is created when a #!/bin/bash > > script is invoked. > > Fair enough, then it's something to mention in the package's > documentation, since packages are forbidden from playing with users' > environments by policy (for very good reasons). Well, after giving it a little thought it seems right - the only one entitled to mess with the private startup scripts is the user himself. > > > BTW, > > > /usr/bin/mcedit is a symlink to /etc/bin/mc which is an only wrapper. > > I'd vote for removal of the wrapper script for three reasons: 1) it's a > > bashism, 2) it's a waste of memory, 3) it can be done more elegantly. > > More important IMO is the fact that it cannot work as a script, so > there is little point including it as a script. That too. Besides if someone really wants to stay in the last selected directory, he should read the manpage. But, to let the people know that there exists such possibility, perhaps it would be good to announce it during MC installation phase? It seems that people are used to this behavior - from the good'n'old NC :)) marek pgpeFUr7DGIVU.pgp Description: PGP signature
Re: (g)mc-4.5.38-2 still broken
* Eric Weigel said: > >I'm afraid many people have some kind of function or aliases related > >to _real_ mc binary and current mc wrapper can broke it. > > > >BTW, > >/usr/bin/mcedit is a symlink to /etc/bin/mc which is an only wrapper. > >This is the reason that mcedit doesn't work already. > > Quite. > > And this has nothing to do with how much resources a bash takes up. > When the bash exits, control is returned to the original directory; no > matter what the bash script did. Yes it does, but it's not the matter. Do you think that firing up an unnecessary copy of bash just for the sake of the exit directory preservation is a good thing? Especially when it can be completely avoided. > And, the idea of editing /etc/profile or whatever is to my mind really > bad. > > The upstream source for mc has sample scripts which users can call from > their own .bash_profile, .profile, etc, both for Bourne and C shells. > They should be made available (they are also listed on the man page for > mc) Well then, they should be provided to the Debian user. They, AFAIR, install a similar function to the one presented in the other mail. The standard /etc/profile and similar scripts for other shells could be modified to source all scripts in, eg, /etc/shell-ext (just an idea - don't take the name seriously :)) so that they can install appropriate functions, aliases etc. > ps: the reason for not doing > > cd `mc -P "$@"` > > is given in the man page. Something to do with control-Z to suspend > doesn't work unless you use the temporary file method. I proposed cd $(cat tempfile) which should work excellent. marek pgpLEDPi7Rkyi.pgp Description: PGP signature
Re: (g)mc-4.5.38-2 still broken
* Piotr Roszatycki said: > > Well that won't work will it? > > > > Try running this: > > > > cd /tmp; ( cd /etc; pwd ); pwd > > No no, it isn't mc script but only function in your ~/.bash_profile or > global /etc/profile. Exactly that was the point. The function executes in the context of the current shell, not in the child shell which is created when a #!/bin/bash script is invoked. > I'm afraid many people have some kind of function or aliases related > to _real_ mc binary and current mc wrapper can broke it. Yes, I was one of them. > BTW, > /usr/bin/mcedit is a symlink to /etc/bin/mc which is an only wrapper. I'd vote for removal of the wrapper script for three reasons: 1) it's a bashism, 2) it's a waste of memory, 3) it can be done more elegantly. marek pgpELtGJGraS6.pgp Description: PGP signature
Re: (g)mc-4.5.38-2 still broken
* Piotr Roszatycki said:
> On Thu, 16 Sep 1999, Marek Habersack wrote:
> >
> > mc() {
> > if [ -x /usr/bin/mc ]; then
> > MC=$(/bin/mktemp /tmp/mc.XX)
> > /usr/bin/mc -P "$@" $MC > $MC
> > cd $(cat $MC)
> > rm -f $MC
> > fi
> > }
>
> I think the more simple is:
>
> mc=()
> {
> cd $(/usr/bin/mc -P "$@")
> }
>
> ... and doesn't use temporary files.
But it's the same what using a script file - it uses a subshell, and the
point is to save on resources.
marek
pgpiUQR649oIF.pgp
Description: PGP signature
Re: (g)mc-4.5.38-2 still broken
* Philip Hands said: > Wait a second. > > So this mc script is an attempt to leave you in the directory you were > in when you left mc ? [snip] > /etc > /tmp > > the ``cd /etc'' only applies in the shell executed in the brackets. > The same goes for the mc script. Any effect of the cd in the script is > lost when the script exits. Correct. My typo - it should be: cd $(cat thetmpfile) marek pgpJZEWHxM066.pgp Description: PGP signature
Re: More pam_limits trouble
* Ben Collins said: > > > Hmmm...looking at the source, it wont accept a line with less than 4 > > > arguments, > > > yet you are correct that the documentation say otherwise. Let me work on > > > this. > > > I'll have it fixed in the next upload. > > I have attached a quick (and untested - I didn't have time to compile :((() > > fix. From looking at it, it should do. > > > > marek > > This will work except that it should return PAM_IGNORE so that no limits get > set. Correct. I didn't RTFS enough :))) - but it was first time I looked at the PAM source :) marek pgplxAHwNCbm8.pgp Description: PGP signature
Re: (g)mc-4.5.38-2 still broken
* Martin Bialasinski said:
> Marek> /etc/csh.cshrc (and possibly other global shell startup
> Marek> scripts) an alias definition, or a function to call mc in a way
> Marek> which would preserve the exit path of mc?
>
> No, directly changing files part of other packages is not allowed by
> policy.
Hmm... couldn't it be done in a similar way like with inetd.conf? That a
program, in this case MC, would register an alias with the shell startup
scripts?
> Marek> a command from within mc or just does Ctrl-O another subshell
> Marek> is invoked by MC - that's three copies of bash for one run of
> Marek> MC.
>
> No, ^o doesn't open a new shell. If you just start mc, you get
>
> 6832 ttyp8S 0:00 | \_ bash /usr/bin/mc
> 6833 ttyp8S 0:00 | \_ /usr/bin/mc.real -P
> 6835 ttyp5S 0:00 | \_ bash -rcfile
> .bashrc
>
> ^o doesn't change a thing.
>
> Starting a program (wether in the for- or background) just adds this
> programm like in
That's right, I was wrong. But still, using a shell script to invoke MC just
for the sake of the exit path preservation is a waste of memory. If the
alias/function cannot be added to the shell startup scripts for the policy
reasons,
then maybe it could be included in the skeleton files? Something like this
(for POSIX-compliant shells):
mc() {
if [ -x /usr/bin/mc ]; then
MC=$(/bin/mktemp /tmp/mc.XX)
/usr/bin/mc -P "$@" $MC > $MC
cd $(cat $MC)
rm -f $MC
fi
}
This function put in skeleton would be present for all new users, however a
better place would be in the global startup scripts.
marek
pgpEGs7pNlOuX.pgp
Description: PGP signature
Re: More pam_limits trouble
* Ben Collins said:
> > It accepts only, e.g.:
> >
> > grendel - cpu [digit]
> >
> > Which is of no use, because setting the limit to 0 doesn't mean disabling
> > it... Any advice? :)
>
> Hmmm...looking at the source, it wont accept a line with less than 4
> arguments,
> yet you are correct that the documentation say otherwise. Let me work on this.
> I'll have it fixed in the next upload.
I have attached a quick (and untested - I didn't have time to compile :((()
fix. From looking at it, it should do.
marek
--- pam_limits.c.orig Thu Jul 8 07:01:58 1999
+++ pam_limits.cThu Sep 16 16:46:06 1999
@@ -466,7 +466,14 @@
process_limit(LIMITS_DEF_GROUP, ltype, item, value, ctrl);
} else if (strcmp(domain, "*") == 0)
process_limit(LIMITS_DEF_DEFAULT, ltype, item, value, ctrl);
-} else
+} else if ( i == 2 ) { /* Probably a no-limit line */
+ if ( (strcmp(uname, domain) != 0) && (ltype[0] == '-') ) {
+ _pam_log(LOG_DEBUG, "no limits for '%s'", uname);
+ fclose(fil)
+ return PAM_SUCCESS;
+ } else
+ _pam_log(LOG_DEBUG,"invalid line '%s'", buf);
+ } else
_pam_log(LOG_DEBUG,"invalid line '%s'", buf);
}
fclose(fil);
pgpRYtYgo2SUW.pgp
Description: PGP signature
More pam_limits trouble
Hi, The pam_limits module refuses to disable limits as described in the docs. It refuses to parse lines like: grendel - (where dash is separated with one or more spaces/tabs) - it reports 'invalid line' for such entries. It accepts only, e.g.: grendel - cpu [digit] Which is of no use, because setting the limit to 0 doesn't mean disabling it... Any advice? :) marek pgpsIhopTwssb.pgp Description: PGP signature
(g)mc-4.5.38-2 still broken
Hi, I've just upgraded the gmc to the latest potato version, but it still has the broken /usr/bin/mc script which calls itself recursively. Also, wouln't it be cleaner if the postinst for this package added an appropriate alias to the /etc/profile and/or /etc/csh.cshrc (and possibly other global shell startup scripts) an alias definition, or a function to call mc in a way which would preserve the exit path of mc? As it is currently done (with the #!/bin/bash script) it should be considered a bug and a waste of resources. The former because the script explicitly requires bash (and all bashisms are supposed to be removed, AFAIR) and the latter because every invocation of mc leaves bash in memory util the user exits. And now every time user executes a command from within mc or just does Ctrl-O another subshell is invoked by MC - that's three copies of bash for one run of MC. When my users fire up 4/5 mc it uses, quite unnecessarily, some memory which doesn't have to be wasted that way. marek pgpMF2czVIUQp.pgp Description: PGP signature
Re: /opt/ again (was Re: FreeBSD-like approach for Debian? [was: ...])
* Steve Lamb said: > > or /usr/opt, you are implicitly violating the license, since computer Baz > > has the same /usr tree as Bar. But, when opt is at /opt, it is not shared > > and such hassles can be avoided (of course, it can be even more easily > > avoided by staying away from non-free software, but then that would > > eliminate any need for /opt). > > Thank you for finally providing a very good reason for a new top level > domain. About the only thing missing, IMHO, is a specific cite from the FHS > (section number would be good) but I'll take your word for it. Well, you finally admitted you haven't read the standard. Then go and do it. IT seems to be your habit to rant and flame without having any *TECHNICAL* (your another favorite expression) bacground on the subject. RTFM, kid. marek pgpvy0giidCZm.pgp Description: PGP signature
Re: /opt/ again (was Re: FreeBSD-like approach for Debian? [was: ...])
* Sven LUTHER said: > > > taken over by most linux distribs these days. on my sun, i have a /opt > > > but no > > > /usr/local for example. > > Correct. Linux distros are generally a mixture of SystemV and BSD standards > > - see the bootup init methods, for one. /opt is a good thing from the SV > > world, /usr/local is a good thing from BSD. Why not to use both? > > cause they are there for the same thing, so only one is needed ? Not quite so. /usr/local is for *local* stuff - that is one fully under control by the local admin. /opt is for optional stuff (yes, it's a confusing term) which I understand as something that's not in the given distribution of either commercial or free OS, but isn't also in the realm of the local admin - for example commercial software packages. marek pgpiPbVIbJPfd.pgp Description: PGP signature
Re: /opt/ again (was Re: FreeBSD-like approach for Debian? [was: ...])
* Steve Lamb said: > Wednesday, September 15, 1999, 12:29:30 PM, Anders wrote: > > Then can you tell me how your three steps are easyer and faster them our > > one step? > > How are you going to get the data on to the drive without a minimum > installation on it in the first place? Geez (that's your favorite expression, ain't it?) - you really don't know what backups are for. They are there to BACK UP everything, make a snapshot of your critical system so that you can restore it within at most TWO hours. Backing up data only is good on non-critical sites, the other category requires fast restoration of the entire system. In that light reinstallation and reconfiguration is not an option. marek pgpUpXCyLHazC.pgp Description: PGP signature
Re: latest login,passwd + PAM upgrade
* Ben Collins said: > > Sep 15 16:41:38 jester login[30897]: PAM unable to resolve symbol: > > pam_sm_open_session > > Sep 15 16:41:38 jester login[30897]: PAM unable to resolve symbol: > > pam_sm_close_session > > > > Any cure for that? > > Update to the latest PAM 0.69-6 in incoming. Some one else also reported > this and it has been fixed. Ok, thanks. And, btw, where's the documentation for the pam_unix_* modules? It's not in the standard libpam docs... marek pgpJgJACfTrfY.pgp Description: PGP signature
latest login,passwd + PAM upgrade
Hi, After the today's upgrade of the login and passwd with PAM support I have found one problem. It seems that there's something wrong with the pam_limits module. After enabling it for login I get the 'Module unknown' message and the syslog records what follows: Sep 15 16:41:38 jester login[30897]: PAM unable to resolve symbol: pam_sm_open_session Sep 15 16:41:38 jester login[30897]: PAM unable to resolve symbol: pam_sm_close_session Any cure for that? thanks, marek pgpGuSOumw9QE.pgp Description: PGP signature
Re: /opt/ again (was Re: FreeBSD-like approach for Debian? [was: ...])
* Steve Lamb said: > > > >> None of this describes one bit why it has to be a top level > > > >> directory. > > > > Because it fits the Unix tradition of lazy typists. Im a lazy typist. > > > > Hear my carpal tunnel fingers cry out as they type the extra 4 > > > > characters in /usr/opt > > > > Then why /home/ftp instead of /ftp? Why /var/htdocs instead of /www? > > Because ftp is a USER and user's home belongs in /home. /var/www (NOT > > /var/htdocs, btw) because the home page is varying data, not a static one. > > Makes sense to you? Probably not, but it does for me. > > Oh, I get it now. So if it is a *user* then we clearly place it in home. > > So... Where's /home/qmail? /home/games anyone? /home/news? /home/uucp? > Wait, wait, according to you, all the man pages clearly belong in /usr/man! > Oh, rats, what happened to /home/www-data? /home/majordomo? /home/msql? > /home/irc? /home/gnats? /home/root? /home/mail! /home/list! > Wow, Marek, Debian sure placed all of those USER's home in /home. I'm so glad > you cleared that up. For another time you show your ignorance. ftp is a user which CAN LOG into the system and which does log into the system. majordomo, msql, man etc. are all created just to make the server more secure. Are you capable of understanding that? All users that can log into the system from outside are put in /home and below. /root is on the / partition because it must be able to log in if nothing but / mounts. Usually /home is on a different file system. Your sarcasm is unnecessary, unprofessional, childish. Get real - you know squat about Unix. Learn. RTFM. Think. Then come back and talk with sense. Until then just be quiet and stop making fuss. > What does varying data have to do with anything about the placement of > top-level directories based on a whim? I mean, already /var/www is wrong > because it is a *USER* and should be placed in /home with the other varying > data, like /home/ftp is. No. www is not a user. And even if it was, then it doesn't log into the system. There's a www-data user because there's no reason to run the httpd with root privs. marek pgphvqzVLkzqw.pgp Description: PGP signature
Re: /opt/ again (was Re: FreeBSD-like approach for Debian? [was: ...])
* Sven LUTHER said: > > > > How do you know I don't do just that, via symlinks? I bet you'd never > > > > have > > > > guessed I have /usr/src/linux symlinked to /sys > > > > > > OK, now argue it as a standard for everyone as /opt is. > > /opt is a de-facto standard. By usage. By tradition. By habit. By convence. > > If i remember well, /opt is a Systeme 5 stuff, will /usr/local is a BSD stuff, > taken over by most linux distribs these days. on my sun, i have a /opt but no > /usr/local for example. Correct. Linux distros are generally a mixture of SystemV and BSD standards - see the bootup init methods, for one. /opt is a good thing from the SV world, /usr/local is a good thing from BSD. Why not to use both? marek pgp9beHLROpYa.pgp Description: PGP signature
Re: /opt/ again (was Re: FreeBSD-like approach for Debian? [was: ...])
* Steve Lamb said: > Considering one can install a fairly robust system (FreeBSD, Debian) over > FTP/NFS in under an hour and it takes 2-3 to go through a gig of data I would > much rather reinstall the programs and retrieve the relatively small data > (/etc, btw, is data). I can't believe what I'm reading. So you say, you are able to a) reinstal an OS, b) configure EVERYTHING as it was before, c) restore all the data within an hour? Bravo. You're the best. I wish I was the same. marek pgpg6yexlj2Ll.pgp Description: PGP signature
Re: /opt/ again (was Re: FreeBSD-like approach for Debian? [was: ...])
* Steve Lamb said: > Tuesday, September 14, 1999, 3:53:40 PM, Raul wrote: > > Actually, the biggest problem with Windows is that it's not a standard. > > But it is. Oh? Show me an RFC or anything of the kind that makes WIndows standard? The fact that it is installed on almost every OEM equipment doesn't make it a STANDARD. Standard is everybody else in the industry follows or implements. It is not the case with Windows. > > DOS was, and the MS Office is to some degree, but Windows hasn't been > > very standard. That's right. WIndows is actually in a permament state of flux. How can it make a standard this way? marek pgpZ9kc5Q80dH.pgp Description: PGP signature
Re: /opt/ again (was Re: FreeBSD-like approach for Debian? [was: ...])
* Steve Lamb said: > > On Tue, Sep 14, 1999 at 01:49:41PM -0700, Steve Lamb wrote: > >> So why /opt and not /usr/opt with the possibility of /usr/local/opt? > > > Because unlike opt and local, there really isn't a difference between > > /opt and /usr/opt -- except that one's a standard. Why not replace /home > > with /users or make clocks run counterclockwise or redefine the meter? > > Same reason -- we need a standard, arbitrary or not. > > That is my point! Huh? /opt IS a standard, and yet you opt (sic!) against it? So what IS your point anyway? > Windows is the standard in business computing. So let's all jump on the > standard, who's with me? That's irrelevant. Chose better example. > Well, so much for standards *just* for standards sake. Standards need a > decent reason and I don't feel a new top level directory "just because" is a > good enough reason. New? Is 20 years *new* in your book? marek pgpK96g1UQrMn.pgp Description: PGP signature
Re: /opt/ again (was Re: FreeBSD-like approach for Debian? [was: ...])
* Steve Lamb said: > Again, please do not reply above. It is rude. No, it might be inconvenient for YOU, but it's not rude. You are rude, all the time. > Tuesday, September 14, 1999, 3:34:05 PM, Jonathan wrote: > > On Tue, 14 Sep 1999, Steve Lamb wrote: > >> Then why /home/ftp instead of /ftp? Why /var/htdocs instead of /www? > > How do you know I don't do just that, via symlinks? I bet you'd never have > > guessed I have /usr/src/linux symlinked to /sys > > OK, now argue it as a standard for everyone as /opt is. /opt is a de-facto standard. By usage. By tradition. By habit. By convence. marek pgp0Rrnd7LyF3.pgp Description: PGP signature
Re: /opt/ again (was Re: FreeBSD-like approach for Debian? [was: ...])
* Steve Lamb said: > Tuesday, September 14, 1999, 2:39:46 PM, Jonathan wrote: > >> Tuesday, September 14, 1999, 3:14:37 PM, Federico wrote: > >> > IMHO, /usr is what we (Debian) control, /usr/local is what I (the > >> > sysadmin) control, /opt is where third-party package builders (e.g., > >> > Corel, KDE, Cygnus, etc...) control. > >> None of this describes one bit why it has to be a top level directory. > > Because it fits the Unix tradition of lazy typists. Im a lazy typist. Hear > > my carpal tunnel fingers cry out as they type the extra 4 characters in > > /usr/opt > > Then why /home/ftp instead of /ftp? Why /var/htdocs instead of /www? Because ftp is a USER and user's home belongs in /home. /var/www (NOT /var/htdocs, btw) because the home page is varying data, not a static one. Makes sense to you? Probably not, but it does for me. marek pgp1YayPHqGtk.pgp Description: PGP signature
Re: /opt/ again (was Re: FreeBSD-like approach for Debian? [was: ...])
* Branden Robinson said: > On Tue, Sep 14, 1999 at 05:59:33PM -0700, Steve Lamb wrote: > > Tuesday, September 14, 1999, 5:40:28 PM, Raul wrote: > > > As it happens, I already pointed you at the answer to that question, > > > you were just too lazy to take the hint. So [me being a fool], here's > > > a quote (the rationale) from http://www.pathname.com/fhs/2.0/fhs-3.8.html: > > > > No, I knew what the rationale was and I don't agree with it one bit. In > > short, their rationale is wrong and we're repeating the mistake. > > Well, I'm glad we have you around to give us the unambiguous, > unquestionable Word of God on the subject. Steve has become annoyingly authoritative not only on this subject, but on several other ones. It seems that a group of professionals who created FHS and other standards was not very smart, while Steve is. Well, anyway I think we'd better follow the fools, than Steve (although HE knows better). As said before, /opt is a part of VERY reputable standards, a well established one and undisputably useful one. I've seen several commercial packages which rely upon the existence of /opt - therefore I see no reason NOT to provide the directory. But Steve knows better. I guess it's just the way he tries to get noticed by people. Oh well... marek pgpIpTgtkk6pr.pgp Description: PGP signature
Re: /opt/ again (was Re: FreeBSD-like approach for Debian? [was:
* Steve Lamb said: > > Why is placing third-party bianary packages in /opt a bad thing? > > Because /opt is a duplication of an existing file structure which can > serve the purpose more than adequately. What people are asking me is "what is > wrong with /opt" when I am pointing out is that there is nothing wrong with > /usr/local, or /usr/opt with a /usr/local/opt counterpart. I do not see the > need of a whole new top-level directory. As usually, you weren't listening. Somebody in this thread has said why it is good to use /opt for third-party (usually commercial) packages: /usr - controlled by Debian /usr/local - controlled by *me* - a local admin /opt - controlled by *them* - the commercial vendors Can't you really see the difference between *local* packages and those you cannot control (the commercial ones)? If a commercial package was compiled with /opt in mind (it was a case with older SO, AFAIR) and you don't have access to sources nor any way to reconfigure it to use a different tree, then you HAVE to put it in /opt. And doing the symlink messing is pointless. marek pgpCkjYhubdgA.pgp Description: PGP signature
Re: Apologies (2)
* Marcus Brinkmann said: > > ideas (whether they worth anything or nothing at all). I seems that I am > > simply not capable of taking part in public discussions or I lack fluency in > > English to express myself in a clear way. > > Someone on IRC told me that there can't be a calm discussion about language > preferences, I was just the one to bite this one :) Yeah, he was right, but I REALLY don't have anything against C++ ;))) - as I said, I use both of them :)) > >Anyway, I'm sorry for any flames I have caused and hope I won't be > > removed from the list of subscribers to debian-devel : > > Others have tried this very much harder and failed (anyone remember Dave > Cinege, I'm sure) Ah.., yes ;... Well, I wasn't too bad I guess, then : marek pgpqxXrSn0LQV.pgp Description: PGP signature
Apologies (2)
Hi all, Well, I wan't to apologize to all who feel offended with my views and ideas (whether they worth anything or nothing at all). I seems that I am simply not capable of taking part in public discussions or I lack fluency in English to express myself in a clear way. Either way, I just wanted to share my views and not even for a moment thought about flames and such. If any of you cares, please go back and read my postings again - maybe it will be more clear once you read it again... Anyway, I'm sorry for any flames I have caused and hope I won't be removed from the list of subscribers to debian-devel : regards, marek pgpZ52EWMOXa8.pgp Description: PGP signature
Re: time to rewrite dpkg
* Branden Robinson said: > > several lines? If so, then please go back AND READ IT. Only then you have a > > right to jump upon me like that. Before you joined the discussion, we were > > DISCUSSING matters, now we're FIGHTING and flaming each other. Thank you. > > What is there to discuss with you? Your entire position can be boiled down Probably nothing... > to a paraphrase of Henry Ford: > > "You can rewrite dpkg in any language you want, as long as it's C." Oh no I never said it... You're the next person to accuse me of it. I think I really have nothing to say then... I'm sorry, I wasted your time. > I'm sorry it offends your aesthetic that Aaron plans to reimplement dpkg in NO IT DOESN'T! Have I made myself clear THIS TIME? It doesn't as I myself program in BOTH languages - I just try to forsee what MIGHT be better. That's what discussion is for. And if Aarond didn't want to discuss his idea why would he send this posting? Wasn't it better to write the code and then show it?? I think I'm getting wrong all of it here, maybe I'm just stupid... > C++. But it is not your decision to make. Gosh... > The best support you can provide for your arguments is to redesign and > reimplement the Debian packaging system yourself (or with people you > recruit to the task). So get to work. I'm sorry, why are you attacking me? I wasn't the one who said he wants to redesign the package. I responded to a posting posted to a PUBLIC mailing list, that's it. Not even once I said here that I want to redesign it. I just had my doubts and wanted to share them with you all - if that's a crime, then I'm sorry - I'm guilty. It seems that one can express his ideas and doubts as long as they are the same as of the original poster... sorry for wasting your time, just ignore postings with my name on them regards, marek pgpYeHFrG6pMM.pgp Description: PGP signature
Re: Time to rewrite dpkg IN IDL! :)
* Marcus Brinkmann said: > > dpkg is already far too slow on old hardware...hell, it's too slow on > > a P200 with 200MB of RAM, now that the status and available files have > > over 3300 packages detailed in them. > > Yeah, it's slow, and it's written in C. Linux is slow. It's written in C. Yeah... > And you want to cinvince me by your un-emotional argumentation that it will > be even slower in C++? [snip] > ignoring things like maintenability and development of code looks > simple-minded to me. The difference in speed will be unnoticable if the same > algorithms are used. Now you've proven it. You're a fanatic. And you offend people. Thanks. marek pgpHDpoQLf95Z.pgp Description: PGP signature
Re: time to rewrite dpkg
* Marcus Brinkmann said: > > > Of course, you are entitled to your opinion. But the decisions are made by > > > people who to do the work. > > Not in this case. This is not their graduate project, nor an experiment. > > It's a package which the entire Debian distribution relies on > > You're wrong, reread what Aaron said. The CURRENT dpkg is what the entire > distribution relies on. The CURRENT dpkg is written in C. You should be > happy. > > If you believe it would be better to rewrite dpkg in C, go for it. More > power to you! I have just one question to you - have you read the ENTIRE thread??? Or just several lines? If so, then please go back AND READ IT. Only then you have a right to jump upon me like that. Before you joined the discussion, we were DISCUSSING matters, now we're FIGHTING and flaming each other. Thank you. > > > The size of the language or the size of the binaries? > > binaries, of course. Who cares about the language? > > Interesting. So you prefer bloated program code instead of bloated binaries? > The time a human needs to understand and maintain a program is less > valuaable to you than a few kilobytes of source code? People read program > code, but they almost never read binaries directly. Yeah, yeah. Go back to one of your previous postings and read what you said: "language doesn't guarantee anything. You have to code it." These are your words and right now you are contradicting yourself. IF you design the code well and implement it well, then it doesn't matter what language you use. You seem to me a little bit fanatic, because what you suggest in the statement above is that C cannot be used to write clear programs. That's a bag of moonshine. C, C++, Python, Lisp, Scheme, Smalltalk - you name it, all can be used to write awfully complicated code which nobody understands. The design is what matters when you talk about readibility of the code. Look at the linux sources, they are in C and theay readable and clear. Point taken? > > > The language was carefully designed to avoid bloat of the binaries. C++ > > > does > > Dream. C++ does bloat programs. > > Some compiler bloat. The language does not. Yes, but you use a compiler to produce a binary, not the language... > And bloat is put a bit too simple. I don't care about a few kilobytes if it > has direct and noticeable positive effect in the source code. You don't care, good. I do care. > > You would be surprised what problems people have with all the try/catch > > blocks. > > You would be surprised what problems people have with all this pointer > arithmetic. > You would be surprised what problems people have with all these regular > expressions. > You would be surprised what problems people have with all these parentheses. > You would be surprised what problems people have with all these gotos. > You would be surprised what problems people have with all these mnemonics. > Did I get my point across? yes, now I know you understand it well. But I don't know why are you trying to pick up a flamewar? What are you so angry about? Why can't you discuss instead of flaming? > > You are talking about things like STL or other template-based libraries? > > Then they will increase the binary size, and they will do it significantly. > > How scary. What exactly is the problem with a bigger binary? Hmm... what exactly? If we have 10 programs written in C that have to fit on one diskette and each of them adds extra 30KB, plus several dozens of kilobytes for the libraries, then what has to fit on one diskette is at the very least 300KB, and that's the problem I see. > > > Your knowledge of the C++ language is a few years behind of current > > > standards and implementation. > > C++ isn't in state of flux anymore, true, but egcs (and it's the only > > compiler around on the GNU platform which can be used to do serious C++ > > programming) is. > > See, I am the maintainer of libgtkmm. This is a huge wrapper library around > Gtk, which uses a lot of templates, classes, derivation, whatever. The > maintainer (currently about three people are actively working on the code) > were able to maintain compatibility even with g++ 2.7.2.3 (which is > horribly broken in every respect) until recently. I don't see them rewriting > their code everytime with another egcs release. I never said every time. Once again, please, read the entire thread. marek pgp07ybzJmR4r.pgp Description: PGP signature
Re: Time to rewrite dpkg
* Marcus Brinkmann said: > On Thu, May 20, 1999 at 08:50:26PM +0200, Marek Habersack wrote: > > > And note that development will just start. By the time this project > > > enters a > > > critical stage, egcs will be improved again. > > No, the development shouldn't start yet. A project should be presented to > > the iterested people and a discussion should take place. Only THEN the > > actual development should start. By that time many things can change, yes. > > But if you start to write your code and base it on some feature which will > > change in the egcs, then what? Simple - you will have to rewrite all your > > code. > > It's hardly to respond anything reasonable to that. This is such a gross > exaggeration, and such a demanding and arrogant attitude, that I can simply > stop just as well. I'm sorry, but you seem to be arrogant here. You cut the DISCUSSION with statements like this instead of saying anything reasonable. So you think that design and project don't matter right? That what developers and people who are to use dpkg thing doesn't matter, right? Well, I think you have worked for Micro$oft then. marek pgphafRDfTGfa.pgp Description: PGP signature
Re: Time to rewrite dpkg
* Marcus Brinkmann said: > > Again, that's not an argument. People come and people go, and more of them > > know C than C++. Besides, ech..., how can you draw an argument like this??? > > I can because I see what's happening to dpkg and it worries me. > > We all are blinded by dpkg. It works, yes. How long? The current sources > don't even build properly out of the box. Problems are cropping up without > people knowing how to fix them (see the bug list). Even very simple patches > and changes need months to get into yet another non-maintainer release. I aggree. I have looked into dpkg code and it scared me, yes... > Your argument is that there would be a lot of more hypothetical programmers > for a C version. This is irrelevant as long as the real number of C > programmers willing to do this is 0 == NULL and the number of C++ > programmers is at least 2, if not more. You can count me in both groups - I have NO personal preference as to the language used, none at all. The tool doesn't matter that much, the effect does - and the more commonly acceptable, the better in that case. > > Is that a reason to write dpkg in Heskell, because the current maintainer > > fancies that? > > You're exaggerating. What if someone would propose doing it in ZX 80 > assembler and running it on an emulator? Yeah. Bad idea. > > But there seem to be enough C++ deevelopers around here, and more and more > will follow (if you haven't noticed, on universities they teach Scheme, Java > , Perl and C++, depends on which faculty you are looking, AI, linguistics or > math/computer science). Don't talk about universities. I've seen too many university graduates that know nothing about "real-world programming"... > > And what about > > compatibility? Extensibility? Interoperability? They don't matter at all, > > right? > > In my book, yes. But compatibility which what? Extensible to where? Compatibility with everything used to program - meaning, easy interfacing with other programming languages. Extensible to other environments, or simply put - creating frontends and utilities to easily manage the packages - vide gnomeapt for apt. > Your arguments are not really good ones, you can write good and bad code in > any language. But even if they were, they are hypothetical anyway. My proof: > The current dpkg is written in C. Is it compatible? No. I needed to fix a > lot of stuff to make it work on the Hurd, and it was a pain to find out how > to fix things. Is it exensible? Not easily, because the code is difficult to > follow. Is it interoperable? With what? Once again: I DON'T CARE WHAT LANGUAGE IS USED HERE. I just see that blind faith in any language can lead to a product which can be extended only in that language. And why to do that when you can a) DESIGN good procjec b) CODE it in C c) EXTEND it with virtually every other programming language Can't you see that C is simply a BASIS on wich you can build everything you imagine. Someone said C is "primitive" - true, but that's why it's so powerful. There are better designed languages out there, which have better theory behind them, true, but no language is so common as C, and as such (!!) it should be chose to create tools which are to be extended, either now or in the future. Look, how many years dpkg has been virtually in the center of the Debian dist??? And that's why you have to THINK ABOUT THE FUTURE and not discuss about what language is better for THEORETICAL reasons. We deal with practice, not with theory here. > I don't want to make dpkg bad here. But you tell me how wonderful C code can > be, and how bad C++ code alwas can be, but I see dpkg, which is in C, and I > see apt, which is in C++, and I don't understand how you can be so sure > about that. I'm starting to lose my nerve... I NEVER said that C is better or C++ is better IN GENERAL. I just think that C is better for THIS task and so far nobody convinced me that it cannot be done in C. It's all a matter of design, when we speak about the program/library itself, and not of the language chosen. But from the point of view of the final product, the language choice appears to be important since it will affect what tools can be used to FURTHER extend dpkg. > Using C does not grant you immediate success. It does not give you > compatibility for free. It does not give you extensibilty and operability. I never said it. > > > (apt), and perl (install methods). > > Yes, yes. But you won't be able to use perl with C++ libraries. > > Big deal. The current perl code does usually not use C libraries. They call Big deal you say? ^^^you said it. If the library is written well in C, then code in perl, tcl, scheme, elisp, java, whatever will use it because it will be EASIER this well. It all comes down to GOOD DESIGN. marek pgp93xNXekGoa.pgp Description: PGP signature
Re: Time to rewrite dpkg
* Marcus Brinkmann said: > On Thu, May 20, 1999 at 12:47:59AM +0200, Marek Habersack wrote: > > But the problem is that templates, nor exceptions or rtti (which are all > > elements of MODERN C++ programming) don't work well enough on the GNU > > platform... > > It would be silly to try to use all features of such a complex language as Templates, exceptions, polymorphism, encapsulation, multiple inheritance, method and operator overloading - they all should be used in ANY modern C++ program. And at the very least, templates and exceptions still don't work well enough in egcc. > And note that development will just start. By the time this project enters a > critical stage, egcs will be improved again. No, the development shouldn't start yet. A project should be presented to the iterested people and a discussion should take place. Only THEN the actual development should start. By that time many things can change, yes. But if you start to write your code and base it on some feature which will change in the egcs, then what? Simple - you will have to rewrite all your code. marek pgpQPPTsW3lkG.pgp Description: PGP signature
Re: Time to rewrite dpkg
* Marcus Brinkmann said: > On Thu, May 20, 1999 at 01:03:46AM +0200, Marek Habersack wrote: > > > 3. Most programmers would write code in C > > Yeah, uh. But that's the point isn't it? No, that's the reality. > The current dpkg is written in C. How many programmers are working on it? Again, that's not an argument. People come and people go, and more of them know C than C++. Besides, ech..., how can you draw an argument like this??? Is that a reason to write dpkg in Heskell, because the current maintainer fancies that? And what if he gets tired maintainig it? And what about compatibility? Extensibility? Interoperability? They don't matter at all, right? > The only contributions to our packaging systems today are done with C++ > (apt), and perl (install methods). Yes, yes. But you won't be able to use perl with C++ libraries. marek pgphVH7alp65y.pgp Description: PGP signature
Re: time to rewrite dpkg
* Marcus Brinkmann said: > [...] > > but it should have not. Please ignore my last mail on this topic. I just > noticed that the general discussions was vastly ahead of your contribution. Too late :))) I just responded :) marek pgpHQENkp6Wkz.pgp Description: PGP signature
Re: time to rewrite dpkg
* Marcus Brinkmann said: > This mail is ignoring Aaron's request for peace over this topic, but I am I just can't resist writing it: there was NO war on this subject, so why do you and Aaron want to make peace? > > become the new standard, then the language you decide to use is very > > important. > > Think of egcs. We really should be happy that someone is actually deciding egcs is a compiler which is not finished yet, it is (at least in respect with C++) incompatible with gcc... > to work on our package managment. Even if Aarons dpkg will not be the one > used in future Debian releases, it will have affect on the current dpkg. Of course, and nobody denies it. > > > extremely friendly towards C++ implementations, and much more powerful > > > than > > > common interop mechanisms with conventional languages such as RPC. > > > > IMHO. What the best thing to do is write your libdpkg in C. Remember > > C is still the standard language for Unix. > > dpkg is not Unix. Do I have to say more? Dpkg is a package manager, and any > language can be chosen. If Aaron had said he would write it in Scheme, I > would have applauded it. If you tell me you want to write one, too, but in > Pascal, more power to you. Wrong. You're getting it all wrong. dpkg is a vital component of the Debian distribution and, as such, it should be written with future in mind! And future can bring a dozen of programmers who can extend dpkg in some way and using a dozen differend languages. Then CAN interface with a C library without any problems, then CANNOT interface a C++ library. Point. So, if you want dpkg to be interoperable, extensible and following the rule "everyone uses what language s/he likes", keep small size - you have to do it in C (all disscusions about which language is better put aside, ok?). > Of course, I am exagerrating. There are pros and contras for any language, > but it is silly to rule out anything beside C for historical reasons. You get it wrong again. It is not for HISTORICAL reasons, it's for the current status quo and the FACTS that speak in C's favor. > > And it will also allow a > > larger number of languages to possibily use those library calls. > > Who will write all these programs? Will you? The current libdpkg is written > in C, how many programs use it? If you say, that YOU are going to write > something in a language you need support for, you would have a point. Now, now! Those arguments are pretty inadequate, I'd say. Tell me, how many programs use libcap? Is that a reason why libcap should be dumped? And, I'm sure, there will be someone who will want to write the programs IF the library is well-designed, well-written and INTEROPERABLE. And the hypothaetical person will be free to chose the preferred language for his work - but it will not be possible when the library is in C++. > > It's your > > project and you can do what you like, but I believe that libdpkg > > should definately be written in C. > > Of course, you are entitled to your opinion. But the decisions are made by > people who to do the work. Not in this case. This is not their graduate project, nor an experiment. It's a package which the entire Debian distribution relies on - and that makes it a COMMON EFFORT no matter who writes the program. The decisions how to design and write the program should come from the developer community - a common sense is what we need. > > wrappers around libdpkg for that. > > C++ has problems, its size is one > > of them. > > The size of the language or the size of the binaries? binaries, of course. Who cares about the language? > The language was carefully designed to avoid bloat of the binaries. C++ does Dream. C++ does bloat programs. > not enforce any language feature on the programmer. The biggest size concern > are exceptions. But exceptions will make error handling oh so much simpler Not only. The IO library is really HUGE and you have to use it to be 100% C++. > and cleaner. About 50 percent of code is error handling. Use of exception > can reduce the amount of actual program code tremendously, which does > decrease the size of the program code (hence the binary). AND it is easier > to understand. You would be surprised what problems people have with all the try/catch blocks. > Use of the standard library is another point. The standard library makes the > program code easier, and really does not increase the overall code, because > if you don't use it, you have to replace it with your own code, which is a > source of errors, too. You are talking about things like STL or other template-based libraries? Then they will increase the binary size, and they will do it significantly. > > The other is, C++ is in a constant state of flux. > > This is plain wrong. > > Your knowledge of the C++ language is a few years behind of current > standards and implementation. C++ isn't in state of flux anymore, true, but egcs (and it's the only compiler around on the GNU platform which can be use
Re: time to rewrite dpkg
* Brandon Mitchell said: > Hi Aaron, > > I would be interested in seeing your design. It may clear up some > concerns as to why you are picking your language (which seems to have I would like to see it as well. So far, not even a single argument has been presented to justify the selection of C++ - and namely, what advantages it gives here. > guess I'm just a big fan of getting the design right since the resulting > code of a bad design is much more difficult to fix than bad code with a > good design. Holy words! The design in such an important project is the primary objective - the more thought over, the better will be the code. marek pgpgEZ2HkN2BQ.pgp Description: PGP signature
Re: Time to rewrite dpkg
* Aaron Van Couwenberghe said: > > The answer is - you can't... All the languages you mentioned have clean C > > interacing methods, but no C++ ones. The reason is that C++ is not > > interoperable. > > No, no, no! one word for everyone. CORBA! I'm sorry to say that, but dream on... marek pgpEM6prF0cPa.pgp Description: PGP signature
Re: Time to rewrite dpkg
* Hamish Moffatt said: > > mention templates. And I remember how did the C++ interface, in binary > > This was certainly true in g++ 2.7.x, but egcs seems much better. Much better, yes, but it's still not finished. > (Exceptions and templates anyway; I don't know what rtti is.) RTTI stands for RunTime Type Identification marek pgpduorjGLesk.pgp Description: PGP signature
Re: Time to rewrite dpkg
* Sven LUTHER said: > > > Is that true, I have heard this agrument often, but is it true, and is it > > > still > > > so today ? Is there effort made to fix this ? how far are they ? > > > > I haven't used RTTI, but in my experience templates work without problems > > I also heard that templates bloat the code, not just that they don't > work, what about it, what size are your executable compared to > equivalent C stuff, what speed do you loose by using C++ templates. I don't know about the overhead on GNU, but from what I remember Borland added about 30KB to every C++ executable whether it used exceptions or not (it was mostly the startup and stack unwinding code). As to the speed, it shouldn't affect it - as long as you don't use the try/catch blocks in your code. marek pgpvC4oHpSIea.pgp Description: PGP signature
Re: Time to rewrite dpkg
* Antti-Juhani Kaijanaho said: > > Is that true, I have heard this agrument often, but is it true, and is it > > still > > so today ? Is there effort made to fix this ? how far are they ? > > I haven't used RTTI, but in my experience templates work without problems > and exceptions work most of the time (the problems I have may well be Yes, most of the time..., but you can't rely on them working all the time. > my bugs, not egcs'). Namespaces need work: for example, there is no > clear separation between global namespace and the std namespace. The namespace concept, as documented in the standards, is not implemented even in half on the GNU platform, IMO. > EGCS has contributed much to the progress. A year ago I didn't feel > like C++ was ready for my use on the GNU platform. That's true, but it will take some more time before it is fully working. marek pgpjjD7Pdpr2p.pgp Description: PGP signature
Re: Time to rewrite dpkg
* Sven LUTHER said: > On Thu, May 20, 1999 at 12:44:02AM +0200, Marek Habersack wrote: > > > > 1. you create a C library with all the dpkg functionality inside > > 2. you compile and link it as a shared library > > 3. you write several simple drivers to interface the user to that library > > 4. the .so is loaded only ONCE - that's what shared libraries are for > > > > But you still have to parse the database, because you load the library only > once don't mean that you will keep the database as is between two invocation > of > the front-end that uses the library. Sure it can be done, but it is not That's true. But it can be overcome by either using a database access daemon (wasteful) that all programs communicate with in order to access the database - it has the advantage that all the consistency checks are performed on one level - by the daemon and it's the daemon who serializes the database access. Second, the database itself could be optimized by using a different format (perhaps, as RPM does, a DB database?) to speed up searching it. regards, marek pgpa0696Ld8bo.pgp Description: PGP signature
Re: Time to rewrite dpkg
* Sven LUTHER said: > > > Agreed. Too bad C++ does not support parametric polymorphism too well. > > > Templates come close, so the hope is not lost. > > But the problem is that templates, nor exceptions or rtti (which are all > > elements of MODERN C++ programming) don't work well enough on the GNU > > platform... > > Is that true, I have heard this agrument often, but is it true, and is it > still > so today ? Is there effort made to fix this ? how far are they ? Yes, it is true. Moreover, AFAIK the g++ 2.7.2.x and egcs differ substantialy in that matter - and that's another problem. > I just want to be sure this is true before people start using this as argument > without even checking if things still are like that. For what it's worth, egcs is still in active development - thus you shouldn't rely upon it too strongly (yes, potato uses egcs as a standard compiler, but it still has problems) and g++ 2.7.2.x doesn't support the advanced features of C++ very well... marek pgpLDWHFytWal.pgp Description: PGP signature
Re: Time to rewrite dpkg
* Sven LUTHER said: > > > Polymorphism is such an obvious pillar of structured programming that I > > > can't understand how anybody could live without it. > > Is it? AFAICS none of the traditional languages like Pascal or C has > > polimorphism at its base... > > What you call polymorphism is just function name overloading, isn't it ? or Yes, function and operator overloading. > does C++ implement true polymorphism this days, like what ML does ? No, to my knowledge it doesn;t :)) regards, marek pgpguwIYUQLjs.pgp Description: PGP signature
Re: Time to rewrite dpkg
* Ossama Othman said: > > mean, you can buy a small car - a "shopping bag on wheels" and then buy a > > new engine just to be able to tow a trailer :)) - it is possible, but not > > cost-effective and sensible - you can buy a larger and stronger car at once > > :)). Maybe the example isn't perfect, but it shows what I have in mind :)). > > Oh boy, here we go again. :-) The fact of the matter is that we can go > on debating endlessly about C/C++ virtues. There are many reasons why Of course we can :)) I, personally, like both languages and just use them as a tool - I have nothing against C++ and I'm not a sworn C fan :)) - I'm just trying to find a proper way in this case :)) > rewriting dpkg in C++ instead of C would be good, and there are many > reasons to stick with C. It just so happens that I believe that the > advantages of implementing a dpkg rewrite in C++ outweigh the > disadvantages, IMHO. Well, if we are talking from the purely conceptual point of view, then you have my vote for C++, but when we are talking about environment and conditions where dpkg is used, C has it all. You have to admit that the *nix wold is rather conservative about programming languages : - C wins :) > For an excellent and huge example of a C++ wrapper library in use > take a look at ACE. Doug Schmidt's web site (papers, etc.) also I remember seeing it on some CD, it's an Asynchronous Communications Environment, or does my memory fail? :))) > provides many advantages of using C++ libraries, in addition to why C++ > wrapper libraries have advantages. The ACE web site is: > > http://www.cs.wustl.edu/~schmidt/ACE.html Thanks for the pointer, I will surely read the pages!! Thanks again. > > the second one - Ockham's Rule says "chose the simpler approach, the > simpler > > the better" > > Thanks! :-) Anytime :))) marek pgpucs146aogJ.pgp Description: PGP signature
