RFC: debian-games?
As the maintainer of FreeCiv, and as someone who would like to take over a few not-yet-packaged games if I had time, and prompted by the new QA stuff, I'd like to propose the creation of a new mailing list, debian-games or perhaps just to make things VERY clear, debian-devel-games, for maintainers of game packages and anyone interested in helping, developing games, etc. I see this, uh, market growing continually, with even sites like LinuxGames, and companies porting and even writing stuff. That's cool, so perhaps if we have a forum to talk on we can make even cooler stuff. Just a thought. I would like to hear from other game maintainers on it. (Figured I'd better ask before requesting the list...) Oh please, in private mail, not devel-announce :-) []s, |alo + -- I am Lalo of deB-org. You will be freed. Resistance is futile. http://www.webcom.com/lalo mailto:[EMAIL PROTECTED] pgp key in the web page Debian GNU/Linux --http://www.debian.org
Quality Charter for Debian Maintainers
[ ObPrivate: I want to reach ALL developers, please don't respond to -private but on -devel or by private mail ] [ Reply to set to debian-devel ] Hi everybody, you can find on http://qa.debian.org/maintainer.html what I called a Quality Charter for the maintainers. It is a short concrete list of what a *good* maintainer is expected to do. :-) I think that it is mainly common sense but you can disagree. You can even discuss about completing or modifying this text, it doesn't matter because the goal of my mail is not discussing this text ... I simply want to remind you (you the Debian maintainers) of your job and responsibilities, if you can't assume your packages completely (and this is perfectly comprehensible since many of us are very busy) then please orphan the packages that you can't manage. Other developers with more time will take them over, there is absolutely no point keeping your package if you don't respond to bug reports and/or if you don't fix them. So consider this mail as a « call to orphan packages ». If you don't know how to orphan a package, read the web page mentionned above. If you have problem keeping up with one of your package but you don't want to orphan it, then please consider asking help. Someone may help you to maintain the package. How to ask for help is explained in the web page mentionned above (even if this looks a bit silly, it's good to be able to check in a single place what work can be done for Debian and who needs help). Consider this as the beginning of the work for Debian's quality. This is very important since when people adopt packages, they tend to fix many bugs (look at Ben's work with shadow !) that wouldn't have been fixed if they couldn't adopt it. Cheers, -- Raphaël Hertzog -=- http://tux.u-strasbg.fr/~raphael/ pub CDs Debian : http://tux.u-strasbg.fr/~raphael/debian/#cd /pub
Release-critical Bugreport for September 17, 1999
Bug stamp-out list for Sep 17 00:04 (CST) Total number of release-critical bugs: 271 -- Package: abiword (main) Maintainer: Darren Benham [EMAIL PROTECTED] [REMOVE] This package can be removed if it is not fixed. 41980 abiword_0.7.3-1(unstable): m68k configuration missing [STRATEGY] abiword and abi-fonts can be removed when abisuite is packaged 42778 abiword_0.7.4-1(unstable): build uses non-free unzip Package: acroread (non-free) Maintainer: Klee Dienes [EMAIL PROTECTED] [REMOVE] This package can be removed if it is not fixed. 42888 acroread: needs rw /usr with free disk space Package: adduser (main) Maintainer: Guy Maor [EMAIL PROTECTED] 45249 pidentd: can't install on slink-potato upgrade Package: apache-ssl (non-US) Maintainer: Christoph Martin [EMAIL PROTECTED] 44046 apache-ssl: Broken Package 44806 apache-ssl: can't install apache ssl Package: apt (main) Maintainer: APT Development Team [EMAIL PROTECTED] 44436 apt-get dumps core 44996 dselect upgrade fails using apt Package: base-passwd (main) Maintainer: Galen Hazelwood [EMAIL PROTECTED] 36007 update-passwd did many stupid things Package: bash (main) Maintainer: Guy Maor [EMAIL PROTECTED] 43050 reinstallation of bash fails due to preinst shell script [STRATEGY] Anthony Towns provided a patch. 43096 BASH: upgrade from 2.01.1-3 to 2.02.1-1.5 removes bash from system [STRATEGY] Anthony Towns provided a patch. 45161 bug: Test Package: bison (main) Maintainer: Vincent Renardias [EMAIL PROTECTED] 43966 bison: postinst still refers to /usr/info/bison.info.gz 43969 bison: Refuses to upgrade Package: blackbox (main) Maintainer: Brent A. Fulgham [EMAIL PROTECTED] 44696 blackbox Japanese language support patch Package: boot-floppies (main) Maintainer: Enrique Zanardi debian-boot@lists.debian.org 35729 rootdisk: Installation from 5.25 floppies seems to require resc1440.bin [STRATEGY] 5.25 floppy support will probably be dropped in potato. 36947 boot-floppies: base.tgz not found - no error message [HELP] There is not enough sanity checking during the phase where base.tgz is unpacked. Should be fixed for slink, too. 41866 [potato only and fixed in CVS] please recompile against libpopt0 44800 boot-floppies: apt can't install the boot-floppies package Package: bootdisk (pseudo) Maintainer: Maintainer Group [EMAIL PROTECTED] 43057 bootdisk: rawrite uses 8.3 names 43058 bootdisk: root.bin gzipped on CDs. 43799 2.1r1 Install kills bsd- and other partitions Package: bplay (main) Maintainer: Peter Makholm [EMAIL PROTECTED] [REMOVE] This package can be removed if it is not fixed. 21623 [FIXED(?)] brec: sometimes doesn't record anything [HELP] Need someone to verify that this is fixed. (Torsten Landschoff is able to reproduce it) Package: bsdmainutils (main) Maintainer: Charles Briscoe-Smith [EMAIL PROTECTED] 43413 gettext: While installing, got error on configure phase: sh: tsort: command not found Package: bug (main) Maintainer: Nicolás Lichtmaier [EMAIL PROTECTED] 45162 bug: bug script crashes on a read -er on Debian/PowerPC Package: bzip2 (main) Maintainer: Anthony Fok [EMAIL PROTECTED] 43656 bzip2: bad shlibs file for libbz2 Package: cecilia (non-free) Maintainer: Marco Budde [EMAIL PROTECTED] 44747 cecilia: `Error: couldn't execute /usr/lib/cecilia/files/csound_linux2.0.x' Package: communicator-smotif-461 (non-free) Maintainer: Adam Heath [EMAIL PROTECTED] [REMOVE] This package can be removed if it is not fixed. 42259 [TBF] If you open a menu and a cookie pops up, the browser hangs 43794 communicator-smotif-461: Oops. netscape dumped core with libnsfix. 43849 communicator-smotif: Floating point exception error 45154 communicator-smotif-461: dead keys no longer work with libc5 version Package: console-data (main) Maintainer: Yann Dirson [EMAIL PROTECTED] 42086 console-tools-data: Doesn't gracefully upgrade configuration Package: crossfire-server (main) Maintainer: Darren Benham [EMAIL PROTECTED] 43614 crossfire-server: Creates logfile in / Package: cvsup (main) Maintainer: Mike Goldman [EMAIL PROTECTED] 44520 cvsup: Unsatisfied dependency Package: debian-keyring (contrib) Maintainer: James Troup [EMAIL PROTECTED] 43536 debian-keyring: Non self-signed keys Package: debian-policy (main) Maintainer: Debian Policy List debian-policy@lists.debian.org 43529 debian-policy: mail locking in Debian is _not_ NFS safe Package: dhcp (main) Maintainer: Eloy A. Paris [EMAIL PROTECTED] 41974 dhcp: dhcp requires kernel 2.2?? Package: dhelp (main) Maintainer: Marco Budde [EMAIL PROTECTED] 41426 dhelp: Does not support /usr/doc anymore. Package: diald (main) Maintainer: Philippe Troin [EMAIL PROTECTED] 32592 diald: Problems with dynamic addressing and 2.2.1 kernel [STRATEGY] There is a new upstream version that fixes this. Package: disc-cover (main)
Re: New Debian Quality Assurance !
Le Thu, Sep 16, 1999 at 08:36:00PM +0200, Matej Vela écrivait: Perl runtime error (interpreter rc=255) Oops, forgot to add the www-data as a valid user for PostgreSQL. Jason just added it, it's corrected. Nice work, BTW. I hope it will be useful (ie people will use this tool to do real work for Debian). Cheers, -- Raphaël Hertzog -=- http://tux.u-strasbg.fr/~raphael/ pub CDs Debian : http://tux.u-strasbg.fr/~raphael/debian/#cd /pub
Re: Metapackages (was Re: Debian Weekly News - September 14th, 1999)
Germano Leichsenring [EMAIL PROTECTED] writes: By the way, am I the only one grepping the available file?? No, and (for those of you who don't already know), there are two nice packages that make doing so even easier and more useful: *grep-dctrl* allows you to extract entire package chunks with a grep-like syntax. *sgrep* allows you to do arbitrarily complicated extracts (also from other structured text files). HTH
Re: Metapackages (was Re: Debian Weekly News - September 14th, 1999)
On Thu, Sep 16, 1999 at 10:52:31PM +, David Coe wrote: Germano Leichsenring [EMAIL PROTECTED] writes: By the way, am I the only one grepping the available file?? No, and (for those of you who don't already know), there are two nice packages that make doing so even easier and more useful: *grep-dctrl* allows you to extract entire package chunks with a grep-like syntax. *sgrep* allows you to do arbitrarily complicated extracts (also from other structured text files). I also find apt 0.3.11's apt-cache search to be quite useful (and fast). Adam -- a jolly daemon kin
Re: Looking for help with ftp archive
Le Wed, Sep 15, 1999 at 08:28:25PM -0700, Guy Maor écrivait: Hi, we're looking for somebody to help us with ftp maintainance by Hey guys, where are you ? Where are the people who criticized the ftpmaster about beeing too slow ? It's time to show that you can do better ... I /REALLY/ hope that someone will step up ! Even if the job is not always funny this is a really useful job for Debian. Cheers, -- Raphaël Hertzog -=- http://tux.u-strasbg.fr/~raphael/ pub CDs Debian : http://tux.u-strasbg.fr/~raphael/debian/#cd /pub
Re: (g)mc-4.5.38-2 still broken
Marek Habersack [EMAIL PROTECTED] writes: [1 text/plain; us-ascii (quoted-printable)] * 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) Eh ? It doesn't matter how you provide the directory name to the cd, because wherever you cd to only persists to the end of the wrapper script, so it's not going to do you any good anyway. Please try to pay attention. To demonstrate: palm:~$ echo -e '#!/bin/bash\ncd /' /tmp/cd_to_root palm:~$ chmod +x /tmp/cd_to_root palm:~$ pwd /home/phil palm:~$ /tmp/cd_to_root palm:~$ pwd /home/phil See? Cheers, Phil.
Re: Looking for help with ftp archive
At 01:30 +0200 1999-09-17, Raphael Hertzog wrote: where are you ? Where are the people who criticized the ftpmaster about beeing too slow ? It's time to show that you can do better ... I /REALLY/ hope that someone will step up ! Even if the job is not always funny this is a really useful job for Debian. I replied privately because I didn't think answering on -devel was appropriate. -- Joel Klecker (aka Espy)Debian GNU/Linux Developer URL:mailto:[EMAIL PROTECTED] URL:mailto:[EMAIL PROTECTED] URL:http://web.espy.org/ URL:http://www.debian.org/
Re: fds_bits
On Thu, Sep 16, 1999 at 09:06:09PM -0400, Raul Miller wrote:
On Fri, Sep 17, 1999 at 04:34:44AM +0800, Paul Harris wrote:
compiler error:
vrweb-1.5/src/common/Dispatch/fdmask.C:99: `fds_bits' undeclared (first
use this function)
problem code:
if (fds_bits[i]) {
declaration in sys/types.h:
/usr/include/bits/types.h: __fd_mask fds_bits[__FD_SETSIZE / __NFDBITS];
(there are a few other references, but i think this is the key one)
does anyone know what i'm supposed to do with this fds_bits thing?
The excerpt from bits/types.h is part of the typedef struct __fd_set.
The code from your fdmask.C looks like an actual variable reference.
I'm not sure why you have a reference to an undefined variable. I just
know that types.h isn't going to be declaring that variable for you.
The way I have overcome this with glibc 2.1 is to use __fds_bits or add
#define __USE_XOPEN 1 to your source at the top.
Ben
Re: Hosed system during package build
On 16-Sep-99, 13:21 (CDT), Ben Gertzfield [EMAIL PROTECTED] wrote: Dale == Dale Scheetz [EMAIL PROTECTED] writes: Dale I'm going to take my time recovering from this, as there Dale are things still on hda1 that I am likely to want saved. Any Dale helpful hints about how to keep such things from happening Dale in the future would be greatfully appreciated. Fakeroot, fakeroot, fakeroot. What I tell you three times is true. :) I saw much talk about fakeroot not working with the new glibc, much talk about it being difficult to fix, and no talk about it being fixed. So, it is working again? Steve -- Steve Greenland [EMAIL PROTECTED] (Please do not CC me on mail sent to this list; I subscribe to and read every list I post to.)
Re: Crazy Idea: debian developer conference
Michael Alan Dorman [EMAIL PROTECTED] writes: Christian Meder [EMAIL PROTECTED] writes: Cool idea. But would it help Debian except of being a big social developer event ? Sometimes social functions can lead to increased cooperation. Plus there's the opportunity to discuss technical issues in a perhaps more interactive medium. Given some of the recent threads, the interactive discussions might need to be conducted on canvas, in the presence of a referee, while wearing padded gloves. ;-) Cheers, Phil.
Re: Crazy Idea: debian developer conference
On Thu, Sep 16, 1999 at 09:35:50AM -0700, Jakob 'sparky' Kaivo wrote: Is this idea worth pursuing? It's a neat idea, and I'd sure like to meet my fellow Debianers, but I doubt you'll get anybody to pay for it. What about Corel? They're getting a /lot/ from Debian (basing their dist on it), and while I'm sure they're contributing back to Debian, sponsoring such an event would be a wonderful gesture on their part. If it costs quite as much as it sounds like it's going to, it would probably be unreasonable to ask any one source to sponsor the whole thing. It might be interesting if they wanted to help sponsor it---and perhaps send a couple of their linux people to the thing as well.. -- Joseph Carter [EMAIL PROTECTED] Debian GNU/Linux developer GnuPG: 2048g/3F9C2A43 - 20F6 2261 F185 7A3E 79FC 44F9 8FF7 D7A3 DCF9 DAB3 PGP 2.6: 2048R/50BDA0ED - E8 D6 84 81 E3 A8 BB 77 8E E2 29 96 C9 44 5F BE -- !netgod:*! time flies when youre using linux !doogie:*! yeah, infinite loops in 5 seconds. !Teknix:*! has anyone re-tested that with 2.2.x ? !netgod:*! yeah, 4 seconds now pgpo6B1YzUtHO.pgp Description: PGP signature
Re: Hosed system during package build
On Thu, Sep 16, 1999 at 08:26:15PM -0500, Steve Greenland wrote: On 16-Sep-99, 13:21 (CDT), Ben Gertzfield [EMAIL PROTECTED] wrote: Dale == Dale Scheetz [EMAIL PROTECTED] writes: Dale I'm going to take my time recovering from this, as there Dale are things still on hda1 that I am likely to want saved. Any Dale helpful hints about how to keep such things from happening Dale in the future would be greatfully appreciated. Fakeroot, fakeroot, fakeroot. What I tell you three times is true. :) I saw much talk about fakeroot not working with the new glibc, much talk about it being difficult to fix, and no talk about it being fixed. So, it is working again? The sparc build uses fakeroot completely for builds, with no problems. Ben
Re: Crazy Idea: debian developer conference
Philip Hands [EMAIL PROTECTED] writes: Given some of the recent threads, the interactive discussions might need to be conducted on canvas, in the presence of a referee, while wearing padded gloves. ;-) Possibly. I would _hope_, however, that being face to face might have the opposite effect. Mike.
Re: fds_bits
At 17:23 -0400 1999-09-16, Ben Collins wrote: The way I have overcome this with glibc 2.1 is to use __fds_bits or add #define __USE_XOPEN 1 to your source at the top. NO, NO, NO! *Never* use the __USE macros, those are internal, for each __USE_FOO there is a corresponding _FOO_SOURCE which should be used instead. See /usr/share/doc/libc6/NOTES.gz or info libc Feature Test Macros. -- Joel Klecker (aka Espy)Debian GNU/Linux Developer URL:mailto:[EMAIL PROTECTED] URL:mailto:[EMAIL PROTECTED] URL:http://web.espy.org/ URL:http://www.debian.org/
gdm MIT-COOKIE problem
I have been trying to get gdm to work again, as it broke a little while ago. I thought it was gdm, but I found an old .deb (which worked at the time for me, 1.0.0-5) but it didn't fix the problem. (I'm using unstable, and gdm 1.0.0-9). Symptoms, gdm starts up X, and then hangs there. :0.log says that xlib is denying access, the MIT-COOKIE isn't valid. I think the message even implies that it is malformed (I'll send the log entry from home, later). Recompiling does *not* help. It seems to be a problem with the fact that (according to the change log in xlib) the new stricter MIT-COOKIE checking in xlib keeps gdm from checking in. I've tried all kinds of things, but nothing works. The most spectacular failure is when I log in as root and do an 'xauth merge /var/state/gdm/authdir/:0.auth'. That causes the X server to die and restart. Can someone point me at something to explain what is going on so I can fix this? I'm not an official developer, just someone who wants it to work! Ciao! -- Boarding this vessel is an act of war. Ergo we surrender. --Rimmer (Red Dwarf episode: Gunmen of the Apocalypse) The Doctor What: fill in the blank http://docwhat.gerf.org/ [EMAIL PROTECTED](finger [EMAIL PROTECTED] for PGP key) KF6VNC
Re: building kernel 2.0.x under potato
On Fri, 17 Sep 1999, Herbert Xu wrote: herberOn Thu, Sep 16, 1999 at 10:57:54AM -0700, John Lapeyre wrote: herberTry herber herbermake CC=gcc272 -D__KERNEL__ -I`pwd`/include zImage I love this man ! Well, I had tried messing around with the /include files, but didn't get it right. This line you gave builds 2.0.x kernels. I had finally gotten a working system, by compiling 2.0.36 patched for egcs with egcs-2.91.66 , and taking the ethernet driver rtl8139.c from 2.0.37 and compiling it with the 2.0.36 source. This finally produces both a stable network and filesystem. The 2.0.37 and 2.2.x kernels keep hanging on my AMD K6-2. Now that I can build with gcc272, I have more parameters to play with ! That line should perhaps be added to /usr/doc/gcc272/README.Debian. I cc'd this to the gcc maintainer group. John John Lapeyre [EMAIL PROTECTED] Tucson,AZ http://www.physics.arizona.edu/~lapeyre
Unofficial emacs 20.4 available...
Having recently found out that emacs 20.4 was available, combined with a bit of time while waiting for the hurricane to pass through, I decided to cook up some emacs 20.4 packages. Those interested in getting them can download them from http://master.debian.org/~mdorman/ I have made no attempt to do anything but upgrade to 20.4, fixing any breakage that happens because of the new version. Mike.
ITP: Rael's Binary Grabber
I've received an OK from the author of Rael's Binary Grabber to redistribute modified versions for Debian (disallowed by the original license). He seemed enamoured with being able to say that his package was part of Debian; it was almost difficult to tell him that it won't be an official part, since it would be in non-free. Oh well.
Re: Hosed system during package build
On Thu, Sep 16, 1999 at 08:26:15PM -0500, Steve Greenland wrote: On 16-Sep-99, 13:21 (CDT), Ben Gertzfield [EMAIL PROTECTED] wrote: Dale == Dale Scheetz [EMAIL PROTECTED] writes: Dale I'm going to take my time recovering from this, as there Dale are things still on hda1 that I am likely to want saved. Any Dale helpful hints about how to keep such things from happening Dale in the future would be greatfully appreciated. Fakeroot, fakeroot, fakeroot. What I tell you three times is true. :) I saw much talk about fakeroot not working with the new glibc, much talk about it being difficult to fix, and no talk about it being fixed. So, it is working again? I didn't know it was broken. I use it with glibc 2.1.2 on PowerPC every day to manually build packages. -- Matt Porter [EMAIL PROTECTED] This is Linux Country. On a quiet night, you can hear Windows reboot.
Move proftpd to contrib
This package has been a major source of serious security bugs and indicatiosn are that it will remain as such. Our Policy states that packages that are not sufficiently free of bugs to meet our standards should not be in main and should be moved to contrib. I therefore encourage that people involved taked whatever steps necessary to do that. We absolutely cannot release a distribution with such a bubbling security hole as this. -- John
Re: Move proftpd to contrib
John == John Goerzen [EMAIL PROTECTED] writes: John whatever steps necessary to do that. We absolutely cannot John release a distribution with such a bubbling security hole as John this. True, but I suggest waiting until freeze time before deciding its worthiness. netgod * SynrG notes that the number of configuration questions to answer in sendmail is NON-TRIVIAL -- Seen on #Debian
Pablo News
Hola, hacia tiempo que no les mandaba mis Pablo News. . .me extrañaban ehh? Bueno, en este mail, les informo que arregle la parte de musica con MTV (ahora los vinculos estan bien), despues tambien argegue algunas utilidades de programacion (C++), y por ultimo adherí una gran seccion en la parte de Download con utilidades para Windows 95/98. Asi que los veo en el proximo Pablo News, hasta luego y gracias. Ya saben las paginas. . . Pablo´s Home Page http://members.tripod.com/pablohp Redireccionador http://www.pablo.zzn.com Pablo Mail http://pablo.zzn.com
Re: Crazy Idea: debian developer conference
On Thu, 16 Sep 1999, Joseph Carter wrote: On Thu, Sep 16, 1999 at 09:35:50AM -0700, Jakob 'sparky' Kaivo wrote: Is this idea worth pursuing? It's a neat idea, and I'd sure like to meet my fellow Debianers, but I doubt you'll get anybody to pay for it. What about Corel? They're getting a /lot/ from Debian (basing their dist on it), and while I'm sure they're contributing back to Debian, sponsoring such an event would be a wonderful gesture on their part. If it costs quite as much as it sounds like it's going to, it would probably be unreasonable to ask any one source to sponsor the whole thing. It might be interesting if they wanted to help sponsor it---and perhaps send a couple of their linux people to the thing as well.. Yes, perhaps it would be a bit unreasonable to ask Corel to send *every* Debian developer somewhere and pay for room and board, etc., I would think that they would be willing to foot at least part of the bill. -- Jakob 'sparky' Kaivo - [EMAIL PROTECTED] - http://www.ndn.net/ As time goes on, my signature gets shorter and shorter... - me
Re: Question on grep 2.3-5 for potato
On Thu, 16 Sep 1999, Wichert Akkerman wrote: Indeed. The GNU coding style dictates this (a program should not rely on argv[0] to decide its behaviour). Are there any security risks or other reasons. I was advised several times in the past to do so also over the list. The simplest example is the XTeddy package. Kind regards Andreas.
name2()
hi
the current problem is involving a function called name2() eg:
from tifs.h
Fieldsdeclare(name2(TIOINETFactoriesBase,Base),TIOINETFactoryPtr)
from fields.h
class name2(TIOINETFactoriesBase,Base) {
see how its used in #defs and is used as the name for a class? what is
that all about? what could this function be? i searched all my header
files on my entire system and could not find a declaration for it... it
looks like something from the package (vrweb), but i could only find it
used, not declared.
its causing problems like:
vrweb-1.5/src/common/Dispatch/tifs.h:57: parse error before `,'
where line 57 is that from tifs.h line above (i unrolled the #defines).
any ideas? i have no idea what to do about this one (i'm more of a C guy).
thanks
Paul
Re: Release-critical Bugreport for September 17, 1999
In article [EMAIL PROTECTED] you wrote: Package: dump (main) Maintainer: Bdale Garbee [EMAIL PROTECTED] 44061 dump: Appears to be unable to dump rev 1 ext2fses with sparse super I'm not an expert on ext2 filesystem internals. If someone who is wants to have a look at this and give me some advice, that would be appreciated. There is no upstream activity evident on dump. Package: inn (main) Maintainer: Bdale Garbee [EMAIL PROTECTED] 44656 INN 1.7.2-4.1 overwrites local access control files I have not investigated this in any detail, yet. I'm working hard on 2.X inn packages, and I intend to review the access control file handling before the initial 2.X upload happens. Bdale
Re: Crazy Idea: debian developer conference
Scavenging the mail folder uncovered Joseph Carter's letter:
On Thu, Sep 16, 1999 at 09:35:50AM -0700, Jakob 'sparky' Kaivo wrote:
Is this idea worth pursuing?
It's a neat idea, and I'd sure like to meet my fellow Debianers, but
I doubt you'll get anybody to pay for it.
What about Corel? They're getting a /lot/ from Debian (basing their dist
on it), and while I'm sure they're contributing back to Debian, sponsoring
such an event would be a wonderful gesture on their part.
If it costs quite as much as it sounds like it's going to, it would
probably be unreasonable to ask any one source to sponsor the whole thing.
It might be interesting if they wanted to help sponsor it---and perhaps
send a couple of their linux people to the thing as well..
Having a big convention would be really awfull, but it's difficult to
get sponsors and much more difficult to gather developers from all
over the world. What about a series of smaller conferences? We can have
Debian Europe, Debian America (North and South?), Debian Australasia, etc...
My 0.02e,
Federico
--
Federico Di Gregorio [http://www.bolinando.com/fog] {Friend of
Penguins} Debian GNU/Linux Developer Italian Press Contact
[EMAIL PROTECTED]
I stick my neck out for nobody. -- Humphrey Bogart, Casablanca
Re: Metapackages (was Re: Debian Weekly News - September 14th, 1999)
On Thu, Sep 16, 1999 at 12:51:16PM +0200, Laurent Martelli wrote: SB == Stephane Bortzmeyer [EMAIL PROTECTED] writes: SB On Thursday 16 September 1999, at 2 h 3, the keyboard of Laurent SB Martelli [EMAIL PROTECTED] wrote: very nice, but how will uninstallation be handled ? Will you be able to uninstall all the packages of a metapackage in one step ? SB Certainly not: SB - a package can be a member of several meta-packages, We could state that the default is not to remove a package as long as it belongs to a metapackage. SB - a package could have been installed before (and independently SB of) a metapackage which includes it). That could be tracked during the installation of the metapackage. It would know what packages were already installed before. Then when you want to remove the metapackage, you could say only remove packages that were installed by the metapackage or remove all packages, regardless of when they were installed. -- Laurent Martelli [EMAIL PROTECTED] What should be good is a new state saying that a package has been install by the dependencies check rather than by user direct selection. So, the package will stay as long as it resolved a dependency, but be remove when no more package who depends on it is install, on a dpkg --remove --pending. How sould we implement it? That's the big discussion: IMHO, this should be add to dpkg along with hold, installed, upgrade, purge, etc. Other think that dpkg is not the right tool for such a feature and this should be handle by apt. Just my 2 pennies. -- Fabien NinolesChevalier servant de la Dame Catherine des Rosiers aka Corbeau aka le Veneur Gris Debian GNU/Linux maintainer E-mail:[EMAIL PROTECTED] WebPage:http://www.tzone.org/~fabien RSA PGP KEY [E3723845]: 1C C1 4F A6 EE E5 4D 99 4F 80 2D 2D 1F 85 C1 70
Linux Journal Reader's Choice Awards
There's a survey for the Linux Journal Reader's choice awards at http://www.linuxjournal.com Go vote for yur favorite dist and software! Nils.
Re: ITP: Rael's Binary Grabber
On Thu 16 Sep 1999, Joe Drew wrote: I've received an OK from the author of Rael's Binary Grabber to redistribute Perhaps you could shed some light on what `Rael's Binary Grabber' is? Paul Slootman -- home: [EMAIL PROTECTED] http://www.wurtel.demon.nl/ work: [EMAIL PROTECTED] http://www.murphy.nl/ debian: [EMAIL PROTECTED] http://www.debian.org/ isdn4linux: [EMAIL PROTECTED] http://www.isdn4linux.de/
Re: Crazy Idea: debian developer conference
On Wed, Sep 15, 1999 at 10:05:52PM -0700, Joey Hess wrote: The two big questions: Where? Preferably somewhere with a high density of debian developers. The California Bay Area (20 some developers with many more nearby) and the Netherlands come to mind. We'd need a map of where people live to make an informed choice. How much $$ would it take, and where's that come from? I'm figuring around $700 per developer, for plane fare and lodging. If 250 attend that's $175k. Plus some unkown amount to rent out a convention center. Asking briefly at a travel agent, it's about $AUS 2000 for return air fares from Australia to either LA or .nl. That's not including any bulk, student, whatever discounts we might be able to scrounge together. That's about $US 1300, I guess. So assuming we can get free/very cheap accomodation, and find somewhere where half the developers don't have to pay anything to get to, that looks vaguely plausible. I wonder if 100 people might be a more realistic size. Splitting it on a continental basis might be interesting too, although doesn't seem like it'd be as exotic and fun... Cheers, aj -- Anthony Towns [EMAIL PROTECTED] http://azure.humbug.org.au/~aj/ I don't speak for anyone save myself. PGP encrypted mail preferred. ``The thing is: trying to be too generic is EVIL. It's stupid, it results in slower code, and it results in more bugs.'' -- Linus Torvalds pgp8MfJCjH9UY.pgp Description: PGP signature
Re: Move proftpd to contrib
On Thu, Sep 16, 1999 at 10:42:36PM -0500, John Goerzen wrote: This package has been a major source of serious security bugs and indicatiosn are that it will remain as such. Our Policy states that packages that are not sufficiently free of bugs to meet our standards should not be in main and should be moved to contrib. I therefore I don't think policy says that contrib is a dumping ground for crap packages. Can you point out which part to me please? Hamish -- Hamish Moffatt VK3SB (ex-VK3TYD). CCs of replies from mailing lists are welcome.
Re: Move proftpd to contrib
Hamish Moffatt [EMAIL PROTECTED] writes: On Thu, Sep 16, 1999 at 10:42:36PM -0500, John Goerzen wrote: This package has been a major source of serious security bugs and indicatiosn are that it will remain as such. Our Policy states that packages that are not sufficiently free of bugs to meet our standards should not be in main and should be moved to contrib. I therefore I don't think policy says that contrib is a dumping ground for crap packages. Can you point out which part to me please? 2.1.3. The contrib section -- Every package in contrib must comply with the DFSG. Examples of packages which would be included in contrib are * free packages which require contrib, non-free, or non-US packages or packages which are not in our archive at all for compilation or execution, * wrapper packages or other sorts of free accessories for non-free programs, ---* packages which we don't want to support because they are too --- buggy, and * packages which fail to meet some other policy requirements in a serious way. - Ruud de Rooij. -- ruud de rooij | [EMAIL PROTECTED] | http://ruud.org
Re: Increasing regularity of build systems
David Welton wrote: Xemacs21 - runs *autoconf* to generate other makefiles, which are then run. [...] Do you seem what I mean? Each of these is doing something slightly different, and it is a bit frustrating not to see a bit more cohesiveness. Not that any of these things are *bad*, per se, just that there seem to be a lot of packages that do stuff like this. Well, for this particular case (xemacs21), I think that running autoconf in the debian/rules file is bad per se, and should be discouraged at least, if not forbidden by policy (I guess it is already forbidden by the GNU standards). Antti-Juhani wrote: I see broken debian/rules files that should be fixed. I see the same. I also see deficiencies in the packaging system (for example, packages which apply different patches in the build process). This is a nice feature of SRPMs which we might want to implement some day in the standard tools. Thanks. -- 52910554fa610624ad65ccc69e6e2765 (a truly random sig)
Re: Debian's problems
On Mon, Sep 13, 1999 at 06:39:42PM -0500, David Welton wrote: I think what is being suggested is that we need a Linus figure, who can step in and say yes or no. I think that that would be preferable and quicker than the current conglomeration of commitees, policies, etc etc. It's very clear to me that there are many who agree and disagree. How about an informal vote just to see if more people think there's a problem than not, then go from there. -- SJ Botha [EMAIL PROTECTED]
Re: Matt Welsh on Debian
On Mon, Sep 13, 1999 at 01:51:39PM -0500, David Welton wrote: between the distributions because I think that they are all good. I was checking out Debian.org the other day and I was pretty amazed at how organized it was. It was a far cry from its earlier days. if he only knew... -- SJ Botha [EMAIL PROTECTED]
Re: Hosed system during package build
On Thu, Sep 16, 1999 at 20:26:15 -0500, Steve Greenland wrote: I saw much talk about fakeroot not working with the new glibc, much talk about it being difficult to fix, and no talk about it being fixed. Actually, AFAIK most of this talk was about /libtricks/ which was a new approach to doing what fakeroot does (it provided a fakeroot binary as well); that approach did turn out not to be usable for glibc2.1. The current fakeroot in potato is based on the old approach, and works fine. Ray -- Obsig: developing a new sig
Re: Binary Deb 'Diffs'
On Thu, 16 Sep 1999, Jordan Mendelson wrote: Just a quick idea, instead of having to download an entire package where 95% of the files don't change, what about downloading a type of binary diff? I can think of two ways to do it: I've wanted something like this for a while -- I was also wondering whether it would solve the PINE problem: the package could be distributed as what appears to be a standard .deb file, but inside there would be not only an original archive, but a binary patch that dpkg-deb would automatically apply when unpacking -- neat? If that solution did indeed get round UWashington's silly licence, it would be a nice way of making it transparent to the user, and sticking two fingers in UW's face at the same time. 1) Package everything in a type of 'pdeb' (patch deb). It should contain reconfiguration information, and files which have changed since version locally installed Well, without getting so elaborate, most people have the old .deb files sitting around, if not on CD-ROM on in their home directories, in /var/cache/apt/archives. It would be feasible just to distribute a plain binary patch. Notice that a plain binary diff between two .deb won't be much use, due to `randomisation' by compression. I think you'd need to distribute an actual `diff -uRN' between the two unpacked source trees, along with the new configuration files. 2) Package everything in a 'pdeb' w/ real binary diff. Instead of packaging entire files which have changed, package patches. This would require a system which logged changes in order to work correctly, similar to CVS. Um, this is complicated (incremental package-by-CVS), and I doubt it'll ever see the light of day, nice as it would be. I think it would be simpler for master to just `dpkg -x' on every upload, and diff against the existing file. Both of these would need to include a checksum per file. Optimally it would require that the storage of deb's on HTTP and FTP servers change as well, requiring the files to be unpacked so apt can grab a single file from a .deb. Well, I think the best way of doing it would just be to store all the patch files in the same current places as the .debs are stored, with descriptive filenames that identify from which to which versions they convert. Of course, people won't want the main tree being cluttered up with all this, so perhaps all the patch files could be stored on a separate server. I don't know, I figured it might be a way to save bandwidth disk space. I don't think this is going to save anyone any disk space. What I think it will save is bandwidth to the `end-user' -- those using apt-get. Remember that `rsync' has difference functions in it already. -- Chris [EMAIL PROTECTED] ( http://www.fluff.org/chris )
Re: Move proftpd to contrib
On Thu, Sep 16, 1999 at 22:42:36 -0500, John Goerzen wrote: This package has been a major source of serious security bugs and indicatiosn are that it will remain as such. SuSE have indicated they're dropping it: http://linuxtoday.com/story.php3?sn=10124 . Our Policy states that packages that are not sufficiently free of bugs to meet our standards should not be in main and should be moved to contrib. Note that there is currently a proposal on -policy to remove that part of contrib's description, making licensing terms and dependency on non-free software the only criteria in deciding main/non-free/contrib. Ray -- Obsig: developing a new sig
Re: Looking for help with ftp archive
On Thu, Sep 16, 1999 at 05:12:30PM -0700, Joel Klecker wrote: At 01:30 +0200 1999-09-17, Raphael Hertzog wrote: where are you ? Where are the people who criticized the ftpmaster about beeing too slow ? It's time to show that you can do better ... I /REALLY/ hope that someone will step up ! Even if the job is not always funny this is a really useful job for Debian. I replied privately because I didn't think answering on -devel was appropriate. Me too. Greetings, Christian -- Christian Meder, email: [EMAIL PROTECTED] What's the railroad to me ? I never go to see Where it ends. It fills a few hollows, And makes banks for the swallows, It sets the sand a-blowing, And the blackberries a-growing. (Henry David Thoreau)
Re: Crazy Idea: debian developer conference
On 16 Sep 1999, Michael Alan Dorman wrote: I would _hope_, however, that being face to face might have the opposite effect. Yes, I agree, and in all likelihood I think that's what'll happen. :) -- Chris [EMAIL PROTECTED] ( http://www.fluff.org/chris )
Re: Crazy Idea: debian developer conference
On Fri, 17 Sep 1999, Federico Di Gregorio wrote: Having a big convention would be really awfull, but it's difficult to get sponsors and much more difficult to gather developers from all over the world. What about a series of smaller conferences? We can have Debian Europe, Debian America (North and South?), Debian Australasia, etc... True, but I think that sort of defeats the point. I would *like* to see people from other parts of the globe (and the other side of the pond), and localising it wouldn't do anything for that. What I propose, perhaps, is that a notice be put that that anyone *not* interested *at all* in attending a conference *wheresoever* it may be, mail in to whomever coordinates this. Then, pick a few locations, post them out, and ask people (or at least one from each region) to figure out roughly how much (if they were doing this on the cheap) it would cost to get them there, stay, and back. Perhaps it could even be nicely automated, in some way. It might give a feel for the true cost, depending on location. I think, re: sponsorship, that probably the way to do it is to ask no developer to pay more than, say, $200 or $300, and make the rest up from there. Anyone short (and there will be plenty) can take more; people not travelling far could do less. What d'ya think? -- Chris [EMAIL PROTECTED] ( http://www.fluff.org/chris )
Re: Looking for help with ftp archive
On Fri, 17 Sep 1999, Christian Meder wrote: On Thu, Sep 16, 1999 at 05:12:30PM -0700, Joel Klecker wrote: At 01:30 +0200 1999-09-17, Raphael Hertzog wrote: where are you ? Where are the people who criticized the ftpmaster about beeing too slow ? It's time to show that you can do better ... I /REALLY/ hope that someone will step up ! Even if the job is not always funny this is a really useful job for Debian. I replied privately because I didn't think answering on -devel was appropriate. Me too. aol Matthew -- Elen sila lumenn' omentielvo Steward of the Cambridge Tolkien Society Selwyn College Computer Support http://www.cam.ac.uk/CambUniv/Societies/tolkien/ http://www.pick.ucam.org/
Re: debian-devel-digest Digest V99 #1154
How do I unsubscribe? - Original Message - From: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Friday, September 17, 1999 11:05 AM Subject: debian-devel-digest Digest V99 #1154
Re: Bug o' the week
On Wed, 15 Sep 1999, Michael Stone wrote: How much trouble would it be to add another category--unreproduced or somesuch? Yes, or `observational', `possible', that sort of thing. I agree. -- Chris [EMAIL PROTECTED] ( http://www.fluff.org/chris )
Re: history (Was Re: Corel/Debian Linux Installer)
On Thu, 16 Sep 1999, David Bristel wrote: With this in mind, I think that having a configuration variable for apt that would allow the downloaded .deb files to be put in a user defined place. This way, if your /var is close to being full, you could, for example, drop it into a temporary directory on /home for the upgrade. This isn't the best place, but on many systems, /home is one of the largest partitions on a system, and tends to have a good ammount of free space on it because users may use a large ammount of space. Yes, either this or a FIFO expiration policy on /var/cache/apt/packages which gets automatically applied when space runs out. Or possibly the option of using /tmp/.apt, with a warning message that the packages are in there and need to be moved into the cache. I *don't* think that `apt' (or any other package) should use any undefined directories (such as /home) for temporary storage. If people want that, they'll symlink /tmp - /home/.tmp or something. Alternatively, is there any other, er, `in bits' way that the upgrade can be done? -- Chris [EMAIL PROTECTED] ( http://www.fluff.org/chris )
Re: building kernel 2.0.x under potato
On Thu, 16 Sep 1999, John Lapeyre wrote: The 2.0.37 and 2.2.x kernels keep hanging on my AMD K6-2. This sounds *bad*, BTW; have you checked around to see if anyone else has had these kinds of freezing problems? Is your machine unstable in any other way? You may find all you need to do is tweak a CPU register or two, or apply some patch to the kernel to make the machine stable on any kernel you like -- it's worth checking, because the kernel *shouldn't* have become randomly unstable in 2.0.37. -- Chris [EMAIL PROTECTED] ( http://www.fluff.org/chris )
Re: ProFTPd being lame
Re: all the bug-finding in ProFTPd (I just read the SuSE notice about it being dropped for lameness reasons, including it *still* being vulnerable to remote exploit) -- if it is, indeed, *that* bad (and the common consensus among admins I know is that it is), perhaps the netkit ftpd shouldn't come with this message..: This is the netkit ftp server. It is recommended for you to use one of its alternatives, such as wu-ftpd or proftpd. Most people I know prefer using the OpenBSD-derived server, because it seems to be more stable and less buggy than the rest -- why is it being deprecated by Debian (or Herbert, I don't know) in this way? -- Chris [EMAIL PROTECTED] ( http://www.fluff.org/chris )
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
* 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: ProFTPd being lame
On Fri, Sep 17, 1999 at 11:46:52 +0100, Chris Rutter wrote: Most people I know prefer using the OpenBSD-derived server, because it seems to be more stable and less buggy than the rest -- why is it being deprecated by Debian (or Herbert, I don't know) in this way? Speaking of FTP servers, has anyone taken a good look at troll-ftpd (ftp://ftp.troll.no/freebies/ftpd)? Ray -- POPULATION EXPLOSION Unique in human experience, an event which happened yesterday but which everyone swears won't happen until tomorrow. - The Hipcrime Vocab by Chad C. Mulligan
Re: fds_bits
Ben Collins [EMAIL PROTECTED] wrote:
problem code:
if (fds_bits[i]) {
declaration in sys/types.h:
/usr/include/bits/types.h: __fd_mask fds_bits[__FD_SETSIZE / __NFDBITS];
(there are a few other references, but i think this is the key one)
does anyone know what i'm supposed to do with this fds_bits thing?
You're supposed to inspect these things with the FD_* macros, try
man select
--
Debian GNU/Linux 2.1 is out! ( http://www.debian.org/ )
Email: Herbert Xu ~{PmVHI~} [EMAIL PROTECTED]
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: history (Was Re: Corel/Debian Linux Installer)
On Fri, Sep 17, 1999 at 11:38:29AM +0100, Chris Rutter wrote: On Thu, 16 Sep 1999, David Bristel wrote: With this in mind, I think that having a configuration variable for apt that would allow the downloaded .deb files to be put in a user defined place. This way, if your /var is close to being full, you could, for example, drop it into a temporary directory on /home for the upgrade. This isn't the best place, but on many systems, /home is one of the largest partitions on a system, and tends to have a good ammount of free space on it because users may use a large ammount of space. Yes, either this or a FIFO expiration policy on /var/cache/apt/packages which gets automatically applied when space runs out. Or possibly the option of using /tmp/.apt, with a warning message that the packages are in there and need to be moved into the cache. Neither of these will help most people. Space running out can happen on one apt-run - nothing in the cache, slink - potato. /tmp is usually on the / partition, which probably has less space than anything (and on many installs ends up on the / partition - at least that's how I was show to do it.) I *don't* think that `apt' (or any other package) should use any undefined directories (such as /home) for temporary storage. If people want that, they'll symlink /tmp - /home/.tmp or something. Not on a general basis. But it would be nice to be able to tell it to use /home or whereever for it. (/home is a bad idea - just for saftey's sake, I'd give it a directory where it has complete control of the contents.) Alternatively, is there any other, er, `in bits' way that the upgrade can be done? Check available space, download one bunch of files, install, delete the .debs, interate. David Starner - [EMAIL PROTECTED]
Re: ITP: Rael's Binary Grabber
*- On 17 Sep, Paul Slootman wrote about Re: ITP: Rael's Binary Grabber On Thu 16 Sep 1999, Joe Drew wrote: I've received an OK from the author of Rael's Binary Grabber to redistribute Perhaps you could shed some light on what `Rael's Binary Grabber' is? From http://thelamb.dhs.org/~rael/bgrab/ This is a small program that I wrote for Linux (which could theoretically compile on pretty much any other UNIX) that automates the extraction of binary attachments from UseNet newsgroups. The COPYING file in the source: COPYING Rael's Binary Grabber may be freely copied, you can redistribute it all you like, but please do not *alter* any existing part of it if you're redistributing. I'd like the distribution to stay consistant. If you use Binary Grabber as part of something bigger, please give credit where credit is due. -- Brian - Mechanical Engineering [EMAIL PROTECTED] Purdue University http://www.ecn.purdue.edu/~servis -
Re: Bug#45307: [PROPOSAL] virtual package ident-server
The proliferation of ident daemons (midentd, oidentd, pidentd) in Debian necessitates the introduction of a virtual package that these packages can provide and conflict with (since you can only [reasonably] run one ident daemon at once). While ident-daemon seems more intuitive, the name ident-server is more consistent with existing conventions for daemons. Per the virtual package policy, this is CC'd to debian-devel. While this is fine to satisfy dependencies, the packages would be more useful if they provided a standard interface via the alternatives mechanism.
Re: history (Was Re: Corel/Debian Linux Installer)
On Fri, Sep 17, 1999 at 07:30:37AM -0500, David Starner wrote: one apt-run - nothing in the cache, slink - potato. /tmp is usually on the / partition, which probably has less space than anything (and on many installs ends up on the / partition - at least that's how I was ^ show to do it.) On many installs /var ends up on the / partition - sorry. David Starner - [EMAIL PROTECTED]
Re: Metapackages (was Re: Debian Weekly News - September 14th, 1999)
On Fri, 17 Sep 1999, Fabien Ninoles wrote: What should be good is a new state saying that a package has been install by the dependencies check rather than by user direct selection. So, the package will stay as long as it resolved a dependency, but be remove when no more package who depends on it is install, on a dpkg --remove --pending. How sould we implement it? That's the big discussion: IMHO, this should be add to dpkg along with hold, installed, upgrade, purge, etc. Other think that dpkg is not the right tool for such a feature and this should be handle by apt. I havn't the faintest idea how to implement this but this would be a feature which I would really like and which I missed several times. It would be great if this could be implemented in any case. Kind regards Andreas.
Re: (g)mc-4.5.38-2 still broken
Marek Habersack [EMAIL PROTECTED] writes: [1 text/plain; us-ascii (quoted-printable)] * 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. 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). 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. More important IMO is the fact that it cannot work as a script, so there is little point including it as a script. Cheers, Phil.
Re: (g)mc-4.5.38-2 still broken
Marek Habersack [EMAIL PROTECTED] writes: 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. This is against policy (3.8) for very good reasons. The users' environment is not to be touched by packages. If the maintainer want to document the example so that sysadmins can easily put it into their /etc/profiles themselves, fair enough. Personally, I would be quite upset to find that someone had put this into my environment, because I have a very strong expectation that when I exit a program, I'll be in the directory I started from. Cheers, Phil.
Re: FreeBSD-like approach for Debian? [was: Re: Deficiencies in Debian]
On Thu, Sep 16, 1999 at 12:48:43PM -0700, Jakob 'sparky' Kaivo wrote: On Thu, 16 Sep 1999, Raul Miller wrote: Thursday, September 16, 1999, 10:50:57 AM, Raul wrote: Um.. you're just not lazy enough... # cd /usr/local/bin # ln -s /usr/bin/perl On Thu, Sep 16, 1999 at 11:42:21AM -0700, Steve Lamb wrote: ln -s `which perl` /usr/local/bin/perl You're confusing keystroke time with character count. Hmm cd /uTABloTABbTABENTERln -s /uTABbTABperlENTER 28 keystrokes ln -s `which perl` /uTABloTABbTABENTER 28 keystrokes Of course, these assume a fairly clean /, /usr, and /usr/local. Someone may want to double-check my counting. The answer of course, is that the first is better, as you don't have to reach for the backtick. ;) BTW, I know you can also TABcomplete the which command, but you first have to type whic to get past matching while, so just typing h is simpler. -- Jakob 'sparky' Kaivo - [EMAIL PROTECTED] - http://www.ndn.net/ As time goes on, my signature gets shorter and shorter... - me What about: zsh# ln -s =perl /usr/local/bin 27 keystrokes without assuming anything or even: zsh# ln -s =perl ~lbin 18 keystrokes if you have ~lbin variable correctly set Just picking ;) -- Fabien NinolesChevalier servant de la Dame Catherine des Rosiers aka Corbeau aka le Veneur Gris Debian GNU/Linux maintainer E-mail:[EMAIL PROTECTED] WebPage:http://www.tzone.org/~fabien RSA PGP KEY [E3723845]: 1C C1 4F A6 EE E5 4D 99 4F 80 2D 2D 1F 85 C1 70
Too many kernels in unstable
Once 2.2.12 makes it out of Incoming, we will have 8 kernel versions in the unstable distribution? Do we REALLY need to provide that many versions of the kernel?? I hate to complain, but every time a new version of the PCMCIA modules is released, I have to build a set of packages for EACH of these kernels. It's starting to become a real pain in the ass. Can't we keep the number down to something more manageable, say 4 at most? Brian
Re: (g)mc-4.5.38-2 still broken
On Thu, Sep 16, 1999 at 07:54:11PM +0200, Piotr Roszatycki wrote: On 16 Sep 1999, Philip Hands wrote: Wait a second. So this mc script is an attempt to leave you in the directory you were in when you left mc ? 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. 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. All you are right. I make a new upload (or you make a NMU) and remove all the last changes. Grisu -- Michael Bramer -- a Debian Linux Developer http://www.debian.org PGP: finger [EMAIL PROTECTED] -- Linux Sysadmin -- Use Debian Linux Linux - the choice of a GNU generation pgpyAyLfzr6Kt.pgp Description: PGP signature
Re: Crazy Idea: debian developer conference
I love it.. Last time, I went to Paris, it cost me about $450 US for a round trip from Atlanta. I think the fares are cheaper in Winter. Regards, Vaidhy PS: It would be a good idea if we can find out if a trip to Paris and then a train or flight would be cheaper than a direct flight to nl. On Wed, Sep 15, 1999 at 10:05:52PM -0700, Joey Hess wrote: How much $$ would it take, and where's that come from? I'm figuring around $700 per developer, for plane fare and lodging. If 250 attend that's $175k. Plus some unkown amount to rent out a convention center. We always seem to have money we don't need to spend on hardware or bandwidth, but I don't think it's on this scale. Corporate donations? I don't really know.
Re: Crazy Idea: debian developer conference
Where? Preferably somewhere with a high density of debian developers. The California Bay Area (20 some developers with many more nearby) and the Netherlands come to mind. We'd need a map of where people live to make an informed choice. How much $$ would it take, and where's that come from? I'm figuring around $700 per developer, for plane fare and lodging. If 250 attend that's $175k. Plus some unkown amount to rent out a convention center. Asking briefly at a travel agent, it's about $AUS 2000 for return air fares from Australia to either LA or .nl. That's not including any bulk, student, whatever discounts we might be able to scrounge together. That's about $US 1300, I guess. You can get cheaper than that. Last year I got a trip from Melb - LA - London - Melb for less than that. -- I'm in Utrecht. I'd like to meet any Linux users in the area, or any other part of the Netherlands.
Re: Crazy Idea: debian developer conference
Steve Greenland wrote: If 250 attend that's $175k. Plus some unkown amount to rent out a convention center. Something you might consider is that colleges and universities often rent out dorm rooms in the summer. It wouldn't be plush, of course, but you'd probably be able to get a decent choice of facilities, and high bandwidth net connections for free or cheap. Speaking for myself, I'd gladly stay in a dorm room if that made the event feasible, or made it possible more more people to attend. Uhm, don't forget that in .nl there is only one campus university like the ones widespread in the USA. And moreover (I currently live on that campus) there ain't that many free dorm rooms during summer (people tend to stay on campus during summer)... But of course that doesn't mean that I really really like the idea of a developers conference :) bye, -Remco
Re: (g)mc-4.5.38-2 still broken
* Philip == Philip Hands [EMAIL PROTECTED] wrote: Philip Personally, I would be quite upset to find that someone had put this Philip into my environment, because I have a very strong expectation that Philip when I exit a program, I'll be in the directory I started from. Personally, I found it very confusing and annoying not to stay in the last directory I was in, when exiting mc (as opposed to nc in dos). It really depends on the background you come from. Looks like Michael had the later case in mind. Anyway, this has no relevance as it can't work in this case anyway. Ciao, Martin
Re: Crazy Idea: debian developer conference
On Fri, 17 Sep 1999, Remco van de Meent wrote: Uhm, don't forget that in .nl there is only one campus university like the ones widespread in the USA. And moreover (I currently live on that campus) there ain't that many free dorm rooms during summer (people tend to stay on campus during summer)... For that, try the UK. There are plenty of 'em. Hm, other than that, I remember a university-affiliated conference centre sort-of thing I once stayed at in .dk... I wonder where it was. This is what comes of attending 10 years' worth of singing festivals around the world. ;-) -- Chris [EMAIL PROTECTED] ( http://www.fluff.org/chris )
Re: Move proftpd to contrib
On Thu, Sep 16, 1999 at 10:42:36PM -0500, John Goerzen wrote: This package has been a major source of serious security bugs and indicatiosn are that it will remain as such. Our Policy states that packages that are not sufficiently free of bugs to meet our standards should not be in main and should be moved to contrib. The contrib section should not be a dumpyard for buggy packages. project/experimenal seems to be the right place for those. The Policy should be changed. -- enJoy -*/\*- don't even try to pronounce my first name
Re: Debian 2.1r3
On Fri, Sep 17, 1999 at 03:44:36PM +0100, Chris Rutter wrote: The current `sub-release' (whatever) of Debian 2.1 is r3, right? I was just wondering, as all references on the web site are to r2, but I thought I received a message from the security team about r3 last week somtime. Just wanted to check before I filed a boring bug report, or something. /pedant Nope, r2 is still official, apparently there have been some problems with syncing packages on some architectures. -- enJoy -*/\*- don't even try to pronounce my first name
Re: Move proftpd to contrib
Or a new section for packages removed from main due to bugs, but possibly still desired by some people? It's safer to have a clear message that Debian considers these packages to contain too many bugs for inclusion in the main distribution, but we are aware that there are some who want to use these packages anyway. Something like this would eliminate any blame if people use those buggy packages, and then have their systems crash or go unstable, or get hacked. Any opinions? Dave Bristel On Fri, 17 Sep 1999, Josip Rodin wrote: Date: Fri, 17 Sep 1999 16:44:46 +0200 From: Josip Rodin [EMAIL PROTECTED] To: John Goerzen [EMAIL PROTECTED] Cc: debian-devel@lists.debian.org Subject: Re: Move proftpd to contrib Resent-Date: 17 Sep 1999 14:45:46 - Resent-From: debian-devel@lists.debian.org Resent-cc: recipient list not shown: ; On Thu, Sep 16, 1999 at 10:42:36PM -0500, John Goerzen wrote: This package has been a major source of serious security bugs and indicatiosn are that it will remain as such. Our Policy states that packages that are not sufficiently free of bugs to meet our standards should not be in main and should be moved to contrib. The contrib section should not be a dumpyard for buggy packages. project/experimenal seems to be the right place for those. The Policy should be changed. -- enJoy -*/\*- don't even try to pronounce my first name -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Debian 2.1r3
That's strange, since r3 can be found on a number of mirrors. Dave Bristel On Fri, 17 Sep 1999, Josip Rodin wrote: Date: Fri, 17 Sep 1999 16:51:03 +0200 From: Josip Rodin [EMAIL PROTECTED] To: Chris Rutter [EMAIL PROTECTED] Cc: Debian developers list debian-devel@lists.debian.org Subject: Re: Debian 2.1r3 Resent-Date: 17 Sep 1999 14:55:08 - Resent-From: debian-devel@lists.debian.org Resent-cc: recipient list not shown: ; On Fri, Sep 17, 1999 at 03:44:36PM +0100, Chris Rutter wrote: The current `sub-release' (whatever) of Debian 2.1 is r3, right? I was just wondering, as all references on the web site are to r2, but I thought I received a message from the security team about r3 last week somtime. Just wanted to check before I filed a boring bug report, or something. /pedant Nope, r2 is still official, apparently there have been some problems with syncing packages on some architectures. -- enJoy -*/\*- don't even try to pronounce my first name -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
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: Move proftpd to contrib
* Hamish == Hamish Moffatt [EMAIL PROTECTED] wrote: Hamish I don't think policy says that contrib is a dumping ground for Hamish crap packages. Can you point out which part to me please? If you call proftpd crap, how do you call dpkg? Please, I am in no part convinced that anything has to be done about proftpd. Bugs found and fixed means there are people working with the code. This will just improve its quality. Ciao, Martin
Re: Move proftpd to contrib
PLEASE reply below the old text, cut unneeded quote, and wrap your lines at 76 characters! On Fri, Sep 17, 1999 at 07:52:24AM -0700, David Bristel wrote: This package has been a major source of serious security bugs and indicatiosn are that it will remain as such. Our Policy states that packages that are not sufficiently free of bugs to meet our standards should not be in main and should be moved to contrib. The contrib section should not be a dumpyard for buggy packages. project/experimenal seems to be the right place for those. The Policy should be changed. BTW there is already a proposal for this, see bug #45318. Or a new section for packages removed from main due to bugs, but possibly still desired by some people? It's safer to have a clear message that Debian considers these packages to contain too many bugs for inclusion in the main distribution, but we are aware that there are some who want to use these packages anyway. Something like this would eliminate any blame if people use those buggy packages, and then have their systems crash or go unstable, or get hacked. Any opinions? project/experimental is exactly what you described. -- enJoy -*/\*- don't even try to pronounce my first name
Re: Debian 2.1r3
On Fri, Sep 17, 1999 at 07:53:06AM -0700, David Bristel wrote: The current `sub-release' (whatever) of Debian 2.1 is r3, right? I was just wondering, as all references on the web site are to r2, but I thought I received a message from the security team about r3 last week somtime. Just wanted to check before I filed a boring bug report, or something. /pedant Nope, r2 is still official, apparently there have been some problems with syncing packages on some architectures. That's strange, since r3 can be found on a number of mirrors. Depends on what you think 2.1r3 really is. When an announcement on debian-announce gets sent, then it should be official. -- enJoy -*/\*- don't even try to pronounce my first name
Re: Move proftpd to contrib
At 16:53 +0200 1999-09-17, Martin Bialasinski wrote: * Hamish == Hamish Moffatt [EMAIL PROTECTED] wrote: Hamish I don't think policy says that contrib is a dumping ground for Hamish crap packages. Can you point out which part to me please? If you call proftpd crap, how do you call dpkg? No bug in dpkg has ever resulted in a a remote root exploit. -- Joel Klecker (aka Espy)Debian GNU/Linux Developer URL:mailto:[EMAIL PROTECTED] URL:mailto:[EMAIL PROTECTED] URL:http://web.espy.org/ URL:http://www.debian.org/
Re: Too many kernels in unstable
[EMAIL PROTECTED] (Brian Mays) writes: Once 2.2.12 makes it out of Incoming, we will have 8 kernel versions in the unstable distribution? Do we REALLY need to provide that many versions of the kernel?? What about just keeping the last 2.0.x and the last 2.2.x ? It's also a lot of space on the ftp site. Guy
Re: Too many kernels in unstable
[EMAIL PROTECTED] (Brian Mays) writes: Once 2.2.12 makes it out of Incoming, we will have 8 kernel versions in the unstable distribution? Do we REALLY need to provide that many versions of the kernel?? Guy == Guy Maor [EMAIL PROTECTED] writes: What about just keeping the last 2.0.x and the last 2.2.x ? That would be fine by me; however, some people might object because kernel improvements sometimes break things -- even in stable kernel branches. It is not so rare for someone to avoid upgrading to the next kernel version, because it breaks some obscure feature that he needs. Perhaps we should keep the last two versions of each branch? In this case, 2.0.35, 2.0.36, 2.2.10, and 2.2.12 (which is in Incoming). I don't know. Let's see whether anyone objects to just keeping two versions around. It's also a lot of space on the ftp site. It's a lot of space on my laptop too... (93M to be precise) Brian
Re: (g)mc-4.5.38-2 still broken
* Michael == Michael Bramer [EMAIL PROTECTED] wrote: Michael I make a new upload (or you make a NMU) and remove all the last changes. I just got blessings from Michael to do the NMU. Just to inform you, so there are no duplicate effords. Ciao, Martin
Re: ProFTPd being lame
On Sep 17, Chris Rutter [EMAIL PROTECTED] wrote: Most people I know prefer using the OpenBSD-derived server, because it seems to be more stable and less buggy than the rest -- why is it being deprecated by Debian (or Herbert, I don't know) in this way? It lacks a lot of features needed by non-small servers. -- ciao, Marco
Re: Too many kernels in unstable
Once 2.2.12 makes it out of Incoming, we will have 8 kernel versions in the unstable distribution? Do we REALLY need to provide that many versions of the kernel?? What about just keeping the last 2.0.x and the last 2.2.x ? It's also a lot of space on the ftp site. And maybe one from the unstable tree 2.3.18 to test compatibility for 2.4 ? This are then only three kernel versions. Thanks, Hartmut
Re: Too many kernels in unstable
Guy Maor wrote: What about just keeping the last 2.0.x and the last 2.2.x ? I agree. One 2.0.x, one 2.2.x, eventually one 2.[34].x version. This has been discussed before, people agreed that there's too much of the kernel packages in there. You're the FTP admin, please act. Brian Mays wrote: That would be fine by me; however, some people might object because kernel improvements sometimes break things -- even in stable kernel branches. It is not so rare for someone to avoid upgrading to the next kernel version, because it breaks some obscure feature that he needs. That's not a reason enough for keeping 20MB stuff for every version of kernel, IMNSHO. If there is a problem, you can still downgrade to your old kernel image. Which you did preserve, didn't you[1]? Plus, all of those versions are kept on ftp.kernel.org for indefinite time. And you can file a bug to the BTS, too. [1] you doesn't refer to you personally, Brian. -- enJoy -*/\*- don't even try to pronounce my first name
Re: Too many kernels in unstable
Brian Mays [EMAIL PROTECTED] wrote:
Once 2.2.12 makes it out of Incoming, we will have 8 kernel versions in
the unstable distribution? Do we REALLY need to provide that many
versions of the kernel??
I hate to complain, but every time a new version of the PCMCIA modules
is released, I have to build a set of packages for EACH of these
kernels. It's starting to become a real pain in the ass.
Can't we keep the number down to something more manageable, say 4 at
most?
We now have:
kernel-{doc,headers,image,source}-2.0.35
kernel-{doc,headers,image,source}-2.0.36
kernel-{doc,headers,image,source}-2.2.1
kernel-{doc,headers,image,source}-2.2.5
kernel-{doc,headers,image,source}-2.2.7
kernel-{doc,headers,image,source}-2.2.9
kernel-{doc,headers,image,source}-2.2.10
kernel-{doc,headers,image,source}-2.2.12
My suggestion would be:
kernel-{doc,headers,image,source}-2.0.38
kernel-{doc,headers,image,source}-2.2.12
Can anybody provide arguements against just having two kernels?
--
I consume, therefore I am
pgpVWJfDIg4Z1.pgp
Description: PGP signature
Re: Too many kernels in unstable
Edward Betts wrote:
My suggestion would be:
kernel-{doc,headers,image,source}-2.0.38
kernel-{doc,headers,image,source}-2.2.12
Can anybody provide arguements against just having two kernels?
1- Sometimes a new `stable' kernel introduces new bugs or
problems. (Didn't Debian recommend 2.0.35 over 2.036 or
something similar).
2- Sometimes a new `stable' kernel breaks on another arch
(As I recall, there were some alpha-related problems in recent
2.2.X kernels).
Perhaps the last two kernels of the stable tree(s) is good.
We have more kernels now because 2.0.X didn't die after 2.2.X was
released. Doesn't that argue that 2.2.X wasn't ready?
Two cents. I don't have strong feelings about this really.
Peter
Announcing debconf, configuration management for debian
This is a bit long, so I'll summarize: Debconf is a tool that packages can use to ask questions when they are installed. It allows various frontends, from dialog, to gtk to web pages to be used, and it also allows for non-interactive package installs, and allows packages to ask questions all at once, before any of them are even installed. I'm been working on debconf for about 3 months and it's finally ready to show to people. If you would like to try out debconf, simply add this line to /etc/apt/sources.list: deb http://va.debian.org/~joeyh/ debconf/ There are a few packages in there modified to use debconf. Good examples include slrn, slrnpull, and sash. When you install these packages, they will use dialog (by default) to ask the questions they need to ask. Now, the long story. Currently, if a package needs to prompt the user for input, it just does, using standard input and standard output to communicate with them. A few packages use things like dialog for a user interface, while most use bare-bones textual interfaces. There is little consistency between these interfaces, since they are each written from scratch. They use different methods to indicate default values, different ways to present lists of choices, and even prompt in different ways when the user just needs to hit enter after being shown a message. Many packages ask the user a series of questions with no way to go back to a previous question, or to start over. Most packages that prompt do so in the postinst, and so the user has to baby-sit an install, answering questions as they come up, and then waiting for some more packages to be installed and some more questions to arrive. There is no way to answer all the questions first and then let dpkg install everything unattended, and so installs are a long, drawn out process. Upgrades often take a long time as well, because many packages ask the same questions over and over each time they are installed. Those that don't have to store the user's last response somewhere, and they do this in a variety of different, inconsistent, ways. Moreover, there is no way to simply use default answers for all the questions asked, if you're in a hurry or don't want to be bothered with them, which has historically made the debian install a barrier to new users. The traditional way of asking questions has made some specialized uses of debian harder as well. Many experienced debian users would like to put apt-get update; apt-get upgrade in a cron job, and have their system upgraded periodically to unstable. People working on clusters or other large-scale debian installations can't afford to answer the same questions over and over again on each machine, and have hacked together various ways around this. Finally, several distributions have appeared recently, based on debian but catering to inexperienced users. None of them want the user to see any questions at all when they install, and they have used various hacks to suppress the questions. It seems clear that we need something better to replace the traditional method of querying the user from a maintainer script. It needs to present a consistent user interface to the user. It needs to be able to prioritize questions so non-interactive installs are possible, as well as installs with all questions asked, or only the most important ones. It needs to be able to ask questions only once. And it would be nice if the questions could be stored in a database on a central machine and sent out to other machines in a cluster, so they need only be asked once for a whole cluster. In fall of 1998, Wichert Akkerman came up with a specification for a configuration management system that would address these needs. It was refined on the debian lists over the next several months, and the final specification is at http://www.debian.org/~wakkerma/config6/ . The specification is very flexible, allowing for multiple different back-end databases (using arbitrary database formats from SQL to plain text), that can be layered together and accessed over the network or locally. It also allows for a variety of user interfaces to be presented to the user. The maintainer scripts communicate with the back-end and front-end using a simple language. Debconf is an implementation of this specification. At this point it consists of a variety of front-end user interfaces (plain text similar to the traditional method, dialog based, web, and GTK). It doesn't yet include the flexible back-end database system from the specification. It is already fully usable as a consistent way to configure packages. As it stands now, debconf is usable along-side traditional packages, and packages that use debconf will behave just like normal packages except they use a consistent UI. Debconf also hooks into apt so if you use apt to install several debconf-aware packages at once, the packages will prompt for configuration information _before_ they are installed. An example is in order
Re: Announcing debconf, configuration management for debian
This is great, Joey! Can you show an example of how to use apt-get to *skip* configuration questions altogether? Ben -- Brought to you by the letters W and O and the number 14. It should be illegal to yell 'Y2K' in a crowded economy. Debian GNU/Linux maintainer of Gimp and GTK+ -- http://www.debian.org/
An extended proposal concerning Metapackages
While discussing Free-BSD style base system installation I'd come up with the
following suggestion:
\begin{quote}
Another issue is the division of Debian archives and development into
logical sections such that development gets a speed-up. In that respect, a
minimal change to the current organization is necessary. Otherwise, the
delays could even get longer. A good place to start is the profiles one
can choose for dselect at install time. It looks like the tasks you can
choose from are some arbitrary collections of packages. My proposal is throwing
out an is-a/part-of hierarchy into those tasks. That way, the class
diagram could account for the logical organization. The original system
that assigns each package a maintainer need not be changed. Suppose that
we allow the smallest leaf task to consist of 16 packages at most. Then
what is required will be to assign each task a release-maintainer. I am
aware that it is pretty rough at the time I write (and think).
Nevertheless it might be a good start. (By leaf task, I mean those tasks
which don't contain instances of others) Those tasks which have others as
their parts or inherit from others may build a categorization that is both
sensible and manageable.
It seems to me that both part-of and is-a hierarchies (allowing multiple
inheritance) is necessary to break down Debian into comprehensible units.
In addition to this, such a categorization would be vertical to
main/contrib/non-free separation
\end{quote}
Now, what I speak of sounds pretty nice, but it is too theoretical to improve
upon. As I understand, the latest thread on metapackages have somewhat
approximated to what I'd suggested.
There are a number of facts to sort:
1) dpkg provides an is-a hierarchy: package x is a contrib, devel, required
package. That is a straightforward classification, but it is beginning to
become insufficient as the archive size grows.
2) Installation profiles/tasks/metapackages: these provide us with some
elementary part-of organization. However, the current approach does not scale
perfectly and it's likely that there's room for improvement.
3) A revision of package organization is quite beneficial: it can help users
(installation/menus/documentation) and developers (better co-ordination for
release work, better comprehension of the software in Debian).
4) The implementation must not require a major rewrite of related components.
(The new categorization must be vertical to the existing ones)
So, how do you achieve such functionality? I think that, while keywords are a
good aid for searching packages, they don't constitute a sufficently formal
categorization. We should aspire at constructing a rigorous OO model for
defining: what type a package/task is, and what the structure of a package/task
is.
Once categories/classes for the Debian archive are developed, it will be
possible to keep them up-to-date with little effort. What's more, all packages
in Debian that list the packages can make use of the tools/libs that have
been written. Defining the organization using OO methods will also help us
analyze the system in better detail. When the subsystems are designated
precisely, the system can be made more modular: the relationships between
modules can be properly determined, and improved upon.
How this should be implemented, I believe, is a question that isn't trivial. I
suspect it would be easier to use a language which already has support for OO
programming. ;) But also I think making it some kind of library would work
best. I'm afraid changes at both apt/dpkg level and
metapackages/dinstall/whatever level is necessary for ramping up to such
functionality.
Hope you don't flame me for not being a Debian developer and referring to
Debian developers as us. However, I'd like to make all the thought
contribution possible if not as source code. I'm not blindly advocating an OO
design/implementation, but I suggest such a thing because it is the only right
way to go. Sometimes I feel a push for the design part of things, that's it.
__
Eray 'exa' Ozkural
CS, Bilkent Univ., Ankara
-
This message was sent using Bilkent University
WEBMAIL Services http://mail.bilkent.edu.tr
demo vs. real package: FYI (was Re: Announcing debconf, configuration management for debian)
On Fri, Sep 17, 1999 at 11:23:36AM -0700, Joey Hess wrote: show to people. If you would like to try out debconf, simply add this line to /etc/apt/sources.list: deb http://va.debian.org/~joeyh/ debconf/ There are a few packages in there modified to use debconf. Good examples include slrn, slrnpull, and sash. When you install these packages, they will use dialog (by default) to ask the questions they need to ask. FYI, sash_3.3-5 (which has been sitting in Incoming for the last couple weeks) no longer prompts at postinst time, as the postinst/prerm scripts have been completely redesigned. This simplifies a variety of installation issues. And, given sash's niche as a brute-force-simple program that's supposed to work under very degraded conditions, I think that simple installation (and removal) is important. However, I'm very glad to see debconf, and hope to take a look at it soon. -- Raul
Re: Move proftpd to contrib
* Joel == Joel Klecker [EMAIL PROTECTED] wrote: Joel At 16:53 +0200 1999-09-17, Martin Bialasinski wrote: If you call proftpd crap, how do you call dpkg? Joel No bug in dpkg has ever resulted in a a remote root exploit. OK, a bug in cron has recently produced a root exploit. What a crappy software, it should be moved to contrib. No, I still did not hear anything that would justify any action on proftpd. Ciao, Martin
Re: Announcing debconf, configuration management for debian
Ben Gertzfield wrote:
This is great, Joey!
Can you show an example of how to use apt-get to *skip* configuration
questions altogether?
Assumming you have debconf installed, edit /etc/apt/apt.conf, make it look
like this:
// Pre-configure all packages before they are installed.
DPkg::Pre-Install-Pkgs {dpkg-preconfig --apt --frontend=Base;};
This uses the base frontend, which is a null frontend -- the defaults are
provided for all questions.
An alternative (that may be a better idea) is:
DPkg::Pre-Install-Pkgs {dpkg-preconfig --apt --priority=critical;};
Which lets you see only the most important questions.
--
see shy jo
Re: demo vs. real package: FYI (was Re: Announcing debconf, configuration management for debian)
Raul Miller wrote: FYI, sash_3.3-5 (which has been sitting in Incoming for the last couple weeks) no longer prompts at postinst time, as the postinst/prerm scripts have been completely redesigned. That's great. The one in the apt repository is of course only a sample. -- see shy jo
Re: Move proftpd to contrib
On 17 Sep 1999, Martin Bialasinski wrote: OK, a bug in cron has recently produced a root exploit. What a crappy software, it should be moved to contrib. Yes, but there aren't *hundreds* of bugs in cron, all giving security problems; it has been subject (presumably) to security review; bugs don't keep on appearing one after another, like cockroaches, as they do in ProFTPD. Read what SuSE said about ProFTPD, and then see how much of it applies to cron. Not much. And, also, arguably cron is a more important part of a Unix system than a specific FTP daemon. -- Chris [EMAIL PROTECTED] ( http://www.fluff.org/chris )
Re: Move proftpd to contrib
Chris == Chris Rutter [EMAIL PROTECTED] writes: Chris And, also, arguably cron is a more important part of a Unix Chris system than a specific FTP daemon. And I agree that proftpd should be moved to contrib in slink, if not removed entirely -- no one has time to backport the security-fix-of-the-day to a jurassic year-old codebase. However there are no known holes in the potato version, only a questionable coding style. netgod Culus Hello? Hi baybee Are you Johnie Ingram? For you I'll be anyone Ermm.. Do you sell slink CD's? I love slinkies
Re: Announcing debconf, configuration management for debian
I have some suggestions. Does anyone care to comment? 1) Separate interactive and non-interactive installation scripts. I suggest that the current debian install scripts should contain *only* non-interative functionality, such as running ldconfig, update-rc.d, etc. *All* interactive functionality should be moved into a separate config script. Perhaps a new control field can be added to the debian packaging system. For example: ConfigScript: /usr/sbin/sendmailconfig When dpkg installs a package, it runs the various (non-interactive) scripts as it does now, then if a ConfigScript is defined, it can run that. Or, running the config script can be deferred to a later time, or done before the package is unpacked (of course, the config script would need to be unpacked even if unpacking the rest of the package was deferred). This way, debconf can still be utilized by the ConfigScript, and an extra benefit is that users will have a config program they can easily look up and run to reconfigure any package. In fact, we could have an option like --reconfigure for dpkg so a user could even skip looking up the name of the ConfigScript 2) Add one more level of configuration to debconf: configure new parameters. This would help immensely when upgrading clusters of workstations. An administrator can be notified of all configuration changes when upgrading a package on one workstation, but once the values of those parameters have been set on that workstation, other workstations can inherit them during their upgrades without prompting. 3) Since no database back-end is yet implemented, perhaps we need nothing more than a config file called: /etc/debconf/package In a .deb package, a default configuration could be provided in this file. After debconf runs, all options in this file could be updated based on the user's input. The administrator could then do a dpkg-repack on the package, and use the modified package on the rest of the cluster. While not as convenient as some kind of network-distributed database, this approach would at least allow debconf to be deployed sooner rather than later as part of the base Debian system. The config file mentioned above would probably have to be handled differently than the current definition of config file within a debian package, such that new options can be merged into an existing configuration. Also, it would be nice to be able to embed a bit of perl into the config file, so you could do things like: $lynx_home_page = www.`dnsdomainname`; -- Scott Barker [EMAIL PROTECTED] Linux Consultant http://www.mostlylinux.ab.ca/scott Looking for a husband? Know anyone looking for a husband? Well, I'm looking for a wife. See http://www.mostlylinux.ab.ca/scott/wife.shtml Want a good deal on a personal computer in Calgary, Alberta, Canada? Visit http://www.mostlylinux.ab.ca/scott/computers.shtml [ Unsolicited commercial and junk e-mail will be proof-read for US$100 ] Silent gratitude isn't very much use to anyone. - G.B. Stein
Re: building kernel 2.0.x under potato
On Fri, 17 Sep 1999, Chris Rutter wrote: chrisOn Thu, 16 Sep 1999, John Lapeyre wrote: chris chris The 2.0.37 and 2.2.x kernels keep hanging on my AMD K6-2. chris chrisThis sounds *bad*, BTW; have you checked around to see if anyone chriselse has had these kinds of freezing problems? Is your machine chrisunstable in any other way? chris chrisYou may find all you need to do is tweak a CPU register or two, chrisor apply some patch to the kernel to make the machine stable on chrisany kernel you like -- it's worth checking, because the kernel chris*shouldn't* have become randomly unstable in 2.0.37. I found a few reports on the kernel mailing list. But, somehow, the search engine did not pick up references to AMD that I remembered. It is difficult to get controled information on bugs. Some people find problems and eventually admit that it was a hardware problem. Tweaking a register would be fine. I really don't know how to look into that, however. It really seems that something changed. I built the 200 MB tar file about 30 times under 2.0.36, and it was fine. Under 2.0.34, the file was built every night for over a year, w/o crashing. With 2.0.37 and 2.2.x, it is not totally predictible, but the machine hangs on roughly half the attempts to make the 200 MB file. As I said, I don't know enough to say to what extent hardware and the compiler are playing a part. It is, of course, quite time consuming to run these tests. I will post something to the kernel list. John Lapeyre [EMAIL PROTECTED] Tucson,AZ http://www.physics.arizona.edu/~lapeyre
Re: Too many kernels in unstable
On Fri, 17 Sep 1999, Brian Mays wrote: brian brian [EMAIL PROTECTED] (Brian Mays) writes: brian brian Once 2.2.12 makes it out of Incoming, we will have 8 kernel brian versions in the unstable distribution? Do we REALLY need to brian provide that many versions of the kernel?? brian brian Guy == Guy Maor [EMAIL PROTECTED] writes: brian brian What about just keeping the last 2.0.x and the last 2.2.x ? brian brianThat would be fine by me; however, some people might object because briankernel improvements sometimes break things -- even in stable kernel brianbranches. It is not so rare for someone to avoid upgrading to the next briankernel version, because it breaks some obscure feature that he needs. brian brianPerhaps we should keep the last two versions of each branch? In this briancase, 2.0.35, 2.0.36, 2.2.10, and 2.2.12 (which is in Incoming). I briandon't know. Let's see whether anyone objects to just keeping two brianversions around. In another thread, I am dealing with exactly this problem. My machine hangs with 2.0.37 and 2.2.x, but is OK with 2.0.36. But had to take a piece of driver code from 2.0.37. There are quite a few new issues arising from two gcc branches and two stable kernel branches. Having a few kernels around gives some flexibility in trying to put together a working system. 11 kernels is probably too much, but a couple of each might be OK. We (someone !) could also package the patches, which is a bit more of a pain for the user, but we could get all 12 new kernels without adding so much bulk to the archive. John Lapeyre [EMAIL PROTECTED] Tucson,AZ http://www.physics.arizona.edu/~lapeyre
Re: Announcing debconf, configuration management for debian
On Fri, Sep 17, 1999 at 11:57:44AM -0700, Joey Hess was heard to say:
Ben Gertzfield wrote:
This is great, Joey!
Can you show an example of how to use apt-get to *skip* configuration
questions altogether?
Assumming you have debconf installed, edit /etc/apt/apt.conf, make it look
like this:
// Pre-configure all packages before they are installed.
DPkg::Pre-Install-Pkgs {dpkg-preconfig --apt --frontend=Base;};
This uses the base frontend, which is a null frontend -- the defaults are
provided for all questions.
An alternative (that may be a better idea) is:
DPkg::Pre-Install-Pkgs {dpkg-preconfig --apt --priority=critical;};
Which lets you see only the most important questions.
I've got a question about this. If you use the --frontend=Base approach, is
there any way to mark which packages were installed in this way? I'd
personally like to be able to do this but also to go back later and fix up
configuration for packages which had configure options. Also, are the APIs
designed in a way that guarantees this to work, or will the config options only
be effective if set before the package is installed, or does it depend on the
package maintainer Doing the Right Thing? (I'm still working through Wichert's
proposal, so apologies if it's covered in there..)
Daniel
--
Imagine if every Thursday your shoes exploded if you tied them the usual
way. This happens to us all the time with computers, and nobody thinks of
complaining.
-- Jeff Raskin
Re: Move proftpd to contrib
At 20:45 +0200 1999-09-17, Martin Bialasinski wrote: OK, a bug in cron has recently produced a root exploit. What a crappy software, it should be moved to contrib. There's no evidence that cron has another one just waiting to happen. People on linux-security-audit *have* said that about proftpd, and that was said before the most recent security hole was discovered. Rather proving them right, wouldn't you say? -- Joel Klecker (aka Espy)Debian GNU/Linux Developer URL:mailto:[EMAIL PROTECTED] URL:mailto:[EMAIL PROTECTED] URL:http://web.espy.org/ URL:http://www.debian.org/
