Re: (g)mc-4.5.38-2 still broken

[Philip Hands]

Marek Habersack <[EMAIL PROTECTED]> writes:

> [1  ]
> * 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

[Joel Klecker]

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
mailto:[EMAIL PROTECTED]> mailto:[EMAIL PROTECTED]>
http://web.espy.org/>   http://www.debian.org/>

Re: fds_bits

[Raul Miller]

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.

-- 
Raul

Re: fds_bits

[Ben Collins]

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

[Steve Greenland]

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

[Philip Hands]

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

[Joseph Carter]

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

[Ben Collins]

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

[Michael Alan Dorman]

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

[Joel Klecker]

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
mailto:[EMAIL PROTECTED]> mailto:[EMAIL PROTECTED]>
http://web.espy.org/>   http://www.debian.org/>

gdm MIT-COOKIE problem

[The Doctor What]

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:  http://docwhat.gerf.org/
[EMAIL PROTECTED](finger [EMAIL PROTECTED] for PGP key)
KF6VNC

Re: building kernel 2.0.x under potato

[John Lapeyre]

On Fri, 17 Sep 1999, Herbert Xu wrote:

herber>On Thu, Sep 16, 1999 at 10:57:54AM -0700, John Lapeyre wrote:
herber>Try
herber>
herber>make "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...

[Michael Alan Dorman]

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

[Joe Drew]

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

[Matt Porter]

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

[John Goerzen]

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

[Johnie Ingram]

"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

[Pablo´s Home Page]

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

[Jakob 'sparky' Kaivo]

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

[Andreas Tille]

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()

[Paul Harris]

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

[Bdale Garbee]

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

[Federico Di Gregorio]

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)

[Fabien Ninoles]

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

[Nils Lohner]

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

[Paul Slootman]

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

[Anthony Towns]

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]> 
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

[Hamish Moffatt]

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

[Ruud de Rooij]

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

[Santiago Vila]

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

[Sarel J. Botha]

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

[Sarel J. Botha]

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

[J.H.M. Dassen \(Ray\)]

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'

[Chris Rutter]

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

[J.H.M. Dassen \(Ray\)]

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

[Christian Meder]

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

[Chris Rutter]

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

[Chris Rutter]

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

[M.C. Vernon]

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.



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

[Oliver Rother]

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

[Chris Rutter]

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)

[Chris Rutter]

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

[Chris Rutter]

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

[Chris Rutter]

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

[Marek Habersack]

* 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

[Marek Habersack]

* 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

[J.H.M. Dassen \(Ray\)]

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

[Herbert Xu]

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 ~{PmV>HI~} <[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)

[David Starner]

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

[Brian Servis]

*- 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

[Clint Adams]

> 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)

[David Starner]

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)

[Andreas Tille]

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

[Philip Hands]

Marek Habersack <[EMAIL PROTECTED]> writes:

> [1  ]
> * 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

[Philip Hands]

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]

[Fabien Ninoles]

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 /ulobln -s /ubperl
> 28 keystrokes
> 
> ln -s `which perl` /ulob
> 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 complete 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

[Brian Mays]

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

[Michael Bramer]

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

[Vaidhyanathan G Mayilrangam]

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

[Russell Coker]

>>  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

[Remco van de Meent]

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

[Martin Bialasinski]

* "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

[Chris Rutter]

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 )

Debian 2.1r3

[Chris Rutter]

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. 

-- 
Chris <[EMAIL PROTECTED]> ( http://www.fluff.org/chris )

Re: Move proftpd to contrib

[Josip Rodin]

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

[Josip Rodin]

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. 

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

[David Bristel]

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

[David Bristel]

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 
> 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. 
> 
> 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

[Marek Habersack]

* 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

[Martin Bialasinski]

* "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

[Josip Rodin]

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

[Josip Rodin]

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. 
> > 
> > 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

[Joel Klecker]

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
mailto:[EMAIL PROTECTED]> mailto:[EMAIL PROTECTED]>
http://web.espy.org/>   http://www.debian.org/>

Re: Too many kernels in unstable

[Guy Maor]

[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

[Brian Mays]

> [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

[Martin Bialasinski]

* "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

[Marco d'Itri]

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

[Hartmut Koptein]

> > 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

[Josip Rodin]

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

[Edward Betts]

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

[Peter S Galbraith]

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

[Joey Hess]

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

[Ben Gertzfield]

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

[ozkural]

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)

[Raul Miller]

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

[Martin Bialasinski]

* "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

[Joey Hess]

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)

[Joey Hess]

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

[Chris Rutter]

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

[Johnie Ingram]

"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




 "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

[Scott Barker]

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/

   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

[John Lapeyre]

On Fri, 17 Sep 1999, Chris Rutter wrote:

chris>On 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>
chris>This sounds *bad*, BTW; have you checked around to see if anyone
chris>else has had these kinds of freezing problems?  Is your machine
chris>unstable in any other way?
chris>
chris>You may find all you need to do is tweak a CPU register or two,
chris>or apply some patch to the kernel to make the machine stable on
chris>any 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

[John Lapeyre]

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>
brian>That would be fine by me; however, some people might object because
brian>kernel "improvements" sometimes break things -- even in stable kernel
brian>branches.  It is not so rare for someone to avoid upgrading to the next
brian>kernel version, because it breaks some obscure feature that he needs.
brian>
brian>Perhaps we should keep the last two versions of each branch?  In this
brian>case, 2.0.35, 2.0.36, 2.2.10, and 2.2.12 (which is in Incoming).  I
brian>don't know.  Let's see whether anyone objects to just keeping two
brian>versions 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

[Daniel Burrows]

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

[Joel Klecker]

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
mailto:[EMAIL PROTECTED]> mailto:[EMAIL PROTECTED]>
http://web.espy.org/>   http://www.debian.org/>

libwxx-gtk 2.1

[Christian Surchi]

Does a package of these libs exists?

---
Christian Surchi|  Debian GNU/Linux User
[EMAIL PROTECTED]   |  http://www.debian.org
www.firenze.linux.it/~csurchi   |  Linux, the choice of a GNU generation

Green light in A.M. for new projects.  Red light in P.M. for traffic tickets.

Re: Too many kernels in unstable

[Brian Mays]

John Lapeyre <[EMAIL PROTECTED]> wrote:

> 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.

I understand.  I tried installing 2.2.12 on my laptop and noticed that I
was having trouble with the APM support.  Therefore, I returned to the
2.2.10 version.

>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.

I could definitely live with this.  I wouldn't need to build PCMCIA 
modules for patches.

On a side note, years ago (when I had a smaller laptop), I used to use 
patches quite frequently to get the PCMCIA modules built for the various 
kernels provided by Debian.  This worked, for the most part, but I 
eventually abandoned this technique when I started to have problems 
building modules that were truly compatible with the kernels.  Building 
kernel modules is a tricky business; extra care taken from the beginning 
saves much time later rebuilding.

Brian

Re: aterm packages ?

[Alexander Koch]

On Wed, 15 September 1999 22:30:03 -0700, Joseph Carter wrote:
> > > Didn't somebody ITP aterm?  What's the status on that?
> > 
> > Samuel Hocevar <[EMAIL PROTECTED]> did package aterm (after sending an 
> > ITP). He
> > asked me to upload his package since he is not a maintainer yet.
> > 
> > However, there were a couple of problems so I did not upload the first
> > version. A new version should be soon available.

What about these packages in Incoming?

-->
master ~/incoming $ ls -l aterm*
-rw-r--r--   1 plundis  Debian   3272 Aug 23 09:03 aterm_0.3.6-3.diff.gz
-rw-r--r--   1 plundis  Debian611 Aug 23 09:03 aterm_0.3.6-3.dsc
-rw-r--r--   1 plundis  Debian990 Aug 23 09:03 
aterm_0.3.6-3_i386.changes
-rw-r--r--   1 plundis  Debian 149092 Aug 23 09:03 aterm_0.3.6-3_i386.deb
-rw-r--r--   1 plundis  Debian 288682 Aug 24 13:54 aterm_0.3.6.orig.tar.gz
<--

If it's out-dated or broken, it should be deleted?

Alexander

-- 
Who wants to live forever if true love has to die?
 -- Freddy Mercury & Brian May
Alexander Koch - <>< - WWJD - aka Efraim - PGP 0xE7694969 - ARGH-RIPE

Re: Announcing debconf, configuration management for debian

[Joey Hess]

Have you looked at debconf at all? Because..

Scott Barker wrote:
> 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.

This is what debconf does.

> 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.

This is in the spec, although not yet implemented.

-- 
see shy jo

Re: Announcing debconf, configuration management for debian

[Joey Hess]

Daniel Burrows wrote:
>   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?

No. Though I can see adding it.

> 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.

One thing debconf lets you do is reconfigure packages after install. Just
run "dpkg-reconfigure package", and it's as if you're installing it again.

> 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..)

Basically, dpkg-reconfigure has to call the postinst again to make sure any
changes you make in your answers to the questions are seen and acted on. The
postinst is idempotent, so running it again is really no problem.

-- 
see shy jo