Re: X with wdm capable of selecting host at login

[Philippe Troin]

Brian May <[EMAIL PROTECTED]> writes:

> > "Brian" == Brian May <[EMAIL PROTECTED]> writes:
> 
> esoR> # /etc/init.d/wdm stop # X -indirect localhost
> 
> esoR> and I get an X background with a mouse cursor but no wdm
> esoR> panel. I, once again, assume that this is the correct
> esoR> behavior. So I am now thinking, do I pass these options to X
> esoR> via the /etc/X11/wdm/Xservers file? If so the syntax is
> esoR> beyond me at the moment. I would like to think that I am not
> esoR> as dumb as a bag of hammers but facts tend to implicate me
> esoR> as so being :-/
> 
> Oh, sorry, I must have read that too fast, I though you said that the
> above command worked. 
> 
> Oh, I see, you have stopped the wdm server... Of course X is not going
> to be able to talk to the display manager on localhost if you just
> killed the display manager...
> 
> I think you want to reconfigure wdm so it doesn't start the X server
> automatically (I use gdm, sorry I can't remember how to do it on wdm,
> except I know it is very simple), then the above X command will work
> if wdm is running at the time.
> 
> Another command you might find of some use is
> 
> X -query remotehost.com.au

Well, actually in addition to what I mentionned in the previous mail
(repeated here for convenience):

  Install also xdm, or get the "chooser" executable from xdm.

  In /etc/X11/wdm/wdm-config, add:

! Use our chooser
DisplayManager*chooser: 

You need to tell wdm to stop managing the local display (strip the "#0
local /usr/bin/X11" line from /etc/X11/wdm/Xservers).

Restart wdm.

Run "X -indirect localhost".

Eventually, use the mentionned script to do this via the inittab.

Phil.

Re: Potato now stable

[Joey Hess]

Jason Gunthorpe wrote:
> Tasks are bettered handled through some kind of non-package means. I've
> long said we need to determine some kind of meta-package scheme (a
> 'package' whose only purpose is to logically group other packages).

How is introducing some basterdized form of package (perhaps it's just
an entry in the Packages file or something), going to allow us to
address problems like aj was talking about, where one of the things it
depends on is removed from debian, and it needs to be updated?

The problem, as I see it, is that task packages declare a strong
dependency where often none really exists. After all, if it were a real
dependancy, we'd not be having this discussion, since aj/james/whoever's
course of action then would have been a lot more clear: remove both
packages, or fix one. Thus, it still seems to me that allowing that to
be weakened to a reccommends would be the ideal solution.

> Clearly the desired effect of all meta-packages is to provide the user
> with a single node to manipulate and view a group of packages. They should
> have special properties in any UI, you should be able to view and
> manipulate their grouped packages. Idillicly the grouping would have
> priorities of packages (ie -python doesn't need to install every freaking
> package, but some are definately critical) and the ability to track and
> optionally install new packages added to the group, remove the whole
> group, etc.

I don't disagree that all this would be nice, but it seems like icing on
a cake that's just hiding the nasty holes.

> Logically, the way to represent this is to have package declare their
> membership in a grouping.

You know, we had this discussion already. Please see the list archives
of this winter. We decided this was not the correct way to do it,
because metapackages should be maintained by one person. Allowing anyone
to add a reverse-dependency and get a package into a metapackage will
result in metapackages that are ill-thought-out collections of stuff,
without the guiding thought behind them that a real package, with a real
maintainer, has.

In other words, they would look something like the sections on our ftp
site do now, but probably even less organized. Is that game in games/, or
x/, or inexplicably, in networking/? :-P

Compare with task-games. I have put a *lot* of thought into what goes into
that package. If it did not have one single maintainer, with a coherent
vision, it would be a random set of games, probably eventually growing 
to include a large portion of the games in debian. Which would defeat
its purpose.

-- 
see shy jo

Re: linuxworld brain dump (2)

[Tom Lancaster]

I'm working for Red Hat, but I think they'll let me bring ice for the
poor debian folks :)
Only thing is I won't know till tomorrow which day I'm going down. It's
probably wednesday, though.
I've forgotten how to add new addresses to this list. Can you add me at
[EMAIL PROTECTED], if you're not already sleeping...

I promise I'll bring ice when I come!
And beer, if I can persuade the driver to stop.

Tom

Joey Hess wrote:
> 
> Hi all. A quick report on Linuxworld expo before I try to get Debian
> Weekly News done and go to bed.
> 
> The Booth
> 
> ... Is mostly set up. We still have a Sun box we need to get X on, and a
> PPC that needs Debian installed on it. We will be able to give out test
> cycle 3 cd's to the ravening hordes for at least 10 minutes ;-) before
> they're all gone. (We still need someone to bring ice for the drink
> cooler.)
> 
> The Award
> 
> ... Will be presented by Linus to Wichert Akkerman on behalf of Debian
> after the keynote, on Tuesday. The keynote starts at 10am, and the
> presentation at 11am. Might be wise to sit through the keynote
> (Micheal Dell?!) to get a good seat for the award.
> 
> The Press Conference
> 
> ... Is at, I believe, 1 pm in room J1, to announce the release of 2.2 to
> the press. Ian Murdock, Bruce Perens, and Wichert Akkerman will all be
> speaking there. We'd love for a lot of hyper people to come to the press
> conference, in addition to the press, to make it a busy, crouded,
> exciting event so the press gets hyped to write about Debian. I'll swing
> by the Debian booth just before 1 pm, as room J1 is a bit hard to find.
> 
> The Release Party
> 
> ... Is on Wednesday night. Drop by the booth to get an invite; it's
> invites-only.
> 
> --
> see shy jo
> 
> ___
> Bay Area Debian mailing list
> [EMAIL PROTECTED]
> http://kitenet.net/cgi-bin/mailman/listinfo/bad

Re: Potato now stable

[Drake Diedrich]

On Mon, Aug 14, 2000 at 10:55:59PM -0600, Jason Gunthorpe wrote:
> 
> Clearly the desired effect of all meta-packages is to provide the user
> with a single node to manipulate and view a group of packages. They should
> have special properties in any UI, you should be able to view and
> manipulate their grouped packages. Idillicly the grouping would have
> priorities of packages (ie -python doesn't need to install every freaking
> package, but some are definately critical) and the ability to track and
> optionally install new packages added to the group, remove the whole
> group, etc.
> 

   Under the Irix packaging system (quite nice UI except that it has to
handle Irix packages..) packages exist in a hierarchy, with lowest level
packages quite fine grained.  For example:

I  fw_bzip2 02/28/2000  bzip2-0.9.0c Compress/decompress files
I  fw_bzip2.man 02/28/2000  bzip2-0.9.0c man pages
I  fw_bzip2.man.bzip2   02/28/2000  bzip2-0.9.0c man pages
I  fw_bzip2.man.info02/28/2000  bzip2-0.9.0c info pages
I  fw_bzip2.man.relnotes  02/28/2000  bzip2-0.9.0c Release Notes
I  fw_bzip2.sw  02/28/2000  bzip2-0.9.0c execution only env
I  fw_bzip2.sw.bzip202/28/2000  bzip2-0.9.0c execution only env
I  fw_bzip2.sw.hdr  02/28/2000  bzip2-0.9.0c header files
I  fw_bzip2.sw.lib  02/28/2000  bzip2-0.9.0c shared libraries
I  fw_bzip2.sw6402/28/2000  bzip2-0.9.0c 64-bit execution only env
I  fw_bzip2.sw64.lib02/28/2000  bzip2-0.9.0c 64-bit shared libs

   Some of these are marked for default installation if the top level
(fw_bzip2) is selected.  Others are non-default.  Still others (the sw64's)
are only installed by default if the hardware they're being installed on is
capable of running them.  You can unfold the selection and mark components
(full fledged packages themselves) for install if you really want to, but
most times the defaults are fine.  You can use wildcards for instance to
delete all info page packages without going beyond the package system.
We could probably use something similar to handle localization and multiple
architectures.
   Many of our packages are already hierarchical ( x-dev, x-doc, libx, ...),
but not in a formal way that the user interface can use to shorten the list
a user sees.

-Drake

Re: please help on apt-move weirdness

[zw]

On Mon, Aug 14, 2000 at 03:39:52PM -0400, Peter S Galbraith wrote:
> 
> [EMAIL PROTECTED] wrote:
> 
> > [EMAIL PROTECTED]:1 ~ $ sudo apt-move localupdate
> > /usr/bin/apt-move: line 122: syntax error near unexpected token ('
> 
> See the following:
> 
> http://cgi.debian.org/cgi-bin/bugreport.cgi?bug=67519
> http://cgi.debian.org/cgi-bin/bugreport.cgi?bug=67522
> http://cgi.debian.org/cgi-bin/bugreport.cgi?bug=67563
> http://cgi.debian.org/cgi-bin/bugreport.cgi?bug=6

academia vs. industry

thanks anyway, .. :)

Re: Potato now stable

[Joey Hess]

Drake Diedrich wrote:
>Under the Irix packaging system (quite nice UI except that it has to
> handle Irix packages..) packages exist in a hierarchy, with lowest level
> packages quite fine grained.

Wow, I quite like this. How could we do it?

-- 
see shy jo

What happened to the alpha potato iso images ?

[Philippe Troin]

There used to be some alpha iso images on cdimage.debian.org (&
mirrors), but they disappeared later on...

How come ?

Phil.

Re: Potato now stable

[Anthony Towns]

On Mon, Aug 14, 2000 at 10:12:38PM -0700, Joey Hess wrote:
> The problem, as I see it, is that task packages declare a strong
> dependency where often none really exists. After all, if it were a real
> dependancy, we'd not be having this discussion, since aj/james/whoever's
> course of action then would have been a lot more clear: remove both
> packages, or fix one. Thus, it still seems to me that allowing that to
> be weakened to a reccommends would be the ideal solution.

What I'd like to happen is basically be able to remove the package,
and just have the task automatically act as though that package had
never existed. Not complain in dselect about it, not worry people when
Apt gives you a warning, not do anything.

One way of doing this would be to include the information in the package's
entry in the Packages file, a la:

Package: foo
Version: 2.71828
Depends: libc6
Task: metasyntactical-packages

If the package is removed from the distribution, it's implicitly no longer
in the task.

The problem with doing it this way, is you can't easily make a
"aj-favourites" task separate from the distribution that includes things
from the distribution. The only way around this I can think of is to
make a task-aj-favourites package that has a Task: aj-favourites field
and Depends: on the packages from the appropriate distribution. This may
be inelegant. It's not a problem within Debian, though (but the current
way of doing things is).

Another way of doing might be to generate task packages as we have now
as part of dinstall, and install them into the archive. Another way
would be to not do this as part of dinstall, but on an autobuilder. This
wouldn't be as effective if there's a security update that needs to get
out immediately though.

> Compare with task-games. I have put a *lot* of thought into what goes into
> that package. If it did not have one single maintainer, with a coherent
> vision, it would be a random set of games, probably eventually growing 
> to include a large portion of the games in debian. Which would defeat
> its purpose.

How we make this available to apt, or frontends doesn't have to influence
how we actually maintain it. Consider, for example:

#!/usr/bin/perl -w

my %pkgtasks = (); # $pkgtasks{"netbase"} = [ "networking" ]; eg
while() {
chomp;
next unless m/^(\S+)\s+(\S+)$/;   #  
push @{$pkgtasks{$2}}, $1;
}

while(<>) {
chomp;
if (m/^Package: (\S+)$/) {
my $cpkg = $1;
print "Package: $cpkg\n";
print "Task: " . join(", ", @{$pkgtasks{$cpkg}}) . "\n"
if (defined $pkgtasks{$cpkg});
} elsif (m/^Task:.*$/) {
# discard
} else {
print "$_\n";
}
}

Used to add Task: fields to a Packages file, something like:

$ cat tasks
networking netbase
metasyntactical-packages foo
$ ./add-task /var/lib/dpkg/available < tasks | less

Cheers,
aj

-- 
Anthony Towns <[EMAIL PROTECTED]> 
I don't speak for anyone save myself. GPG signed mail preferred.

  ``We reject: kings, presidents, and voting.
 We believe in: rough consensus and working code.''
  -- Dave Clark


pgpIkFGeB6zoQ.pgp
Description: PGP signature

Re: Intent To Split: netbase

[Joey Hess]

Branden Robinson wrote:
> Fine with me; either interpretation would get traceroute into (/usr)?/bin.

Same here, but ..

> On the other hand, fsck seems to be a good example of a program that can't
> do much for the unprivileged user.


Anyone can own a block device.


-- 
see shy jo

Re: Potato now stable

[Jason Gunthorpe]

On Mon, 14 Aug 2000, Joey Hess wrote:

> Jason Gunthorpe wrote:
> > Tasks are bettered handled through some kind of non-package means. I've
> > long said we need to determine some kind of meta-package scheme (a
> > 'package' whose only purpose is to logically group other packages).
> 
> How is introducing some basterdized form of package (perhaps it's just
> an entry in the Packages file or something), going to allow us to
> address problems like aj was talking about, where one of the things it
> depends on is removed from debian, and it needs to be updated?

You already have a bastadized form of packages, thats what a task package
is! The reason there are problems is specificly because task-packages
*aren't really packages* and we don't have enough expressiveness in our
packaging system to make them really work in a good way. [nor should we,
IMHO]

Trying to put hack upon hack into the package tools to support
magic-special packages in a limited fashion does not seem to be a good
solution because:
  1) They are not packages!
  2) You will never get everything you want because you are treating
 specialized data in a generic way

The exact problem AJ is talking about is easially handled when you no
longer have task packages because suddenly there are no more dependencies,
you have a grouping which can be as strong or weak as the user+packager
desires. 

Your suggestion would work to solve AJ's problem, but it suddenly makes
apt-get act really damn weird. You now have a black list of packages which
are hidden from recommends. This black list can't be updated if someone
uses dpkg because it doesn't know about it, and there is not really a
super-good way to edit it and it doesn't buy you anything in terms of ease
of use and organization. 

I suspect the model APT guis, and perhaps apt-get too, will use for
recommends will be a white list where specific packages have their
recommends and suggests promoted to depends under user control. That list
can be fully maintained safely within APT and matches the familiar model
that dselect uses. (pull stuff in, don't exclude stuff out) 

We also already have the concept of groups (priority/section), our users
are familiar with it - we even have automatic groups ala task-packages
(priority=important). So why not enhance that and create something
really spanky?

> > priorities of packages (ie -python doesn't need to install every freaking
> > package, but some are definately critical) and the ability to track and
> > optionally install new packages added to the group, remove the whole
> > group, etc.
> 
> I don't disagree that all this would be nice, but it seems like icing on
> a cake that's just hiding the nasty holes.

Eh? That's completely unreasonable - the entire point is that expressing
groupings using the dependency mechanism has severe drawbacks, you have to
get away from that - you can't consider anything else as full of holes and
expect to fix any of the drawbacks!

> > Logically, the way to represent this is to have package declare their
> > membership in a grouping.
> 
> You know, we had this discussion already. Please see the list archives
> of this winter. We decided this was not the correct way to do it,

I'm well aware of that - and that has zippo to do with delivery of the
data. We already have the ability to override sections and priority,
groups are not a big streatch. 

Inling group membership with each package is a good way to deliver this
data without making major changes to the delivery system, another option
is to throw another index file in the archive or somehow abuse the content
of the Package file. But the best option from a modeling viewpoint is to
have packages be members of groups, not have groups with packages in them.

Jason

Re: What happened to the alpha potato iso images ?

[Joey Hess]

Philippe Troin wrote:
> There used to be some alpha iso images on cdimage.debian.org (&
> mirrors), but they disappeared later on...
> 
> How come ?

Phil Hands on debian-cd:
> ALPHA Problems:
> 
> tools/boot/potato/post-boot-alpha was not executable, so I'm
> rebuilding that now.

-- 
see shy jo

Re: Potato now stable

[Jason Gunthorpe]

On Mon, 14 Aug 2000, Joey Hess wrote:

> Drake Diedrich wrote:
> >Under the Irix packaging system (quite nice UI except that it has to
> > handle Irix packages..) packages exist in a hierarchy, with lowest level
> > packages quite fine grained.
> 
> Wow, I quite like this. How could we do it?

This is the ultimate in micropackaging - doing something like that would
solve so many different requests in one big *splat*.

We could have sparc32/64 binaries, PIII optimized binaries, systems
without /usr/doc, etc.

Off hand, I would suspect you'd take an arbitary .deb and carve it into
sub packages internally - this is for effeciency.. Other debs can come
along and clealy install over the sub packages. Ex:

You have apt_1.1_i386.deb which contains
'doc'
'binary'

And an apt_1.1_i686_bin.deb which just have
'binary' 
Inside

Package tools would sort that out through some magic means..

Of course this is all just off hand... :>

Jason

Re: Potato now stable

[Joey Hess]

Anthony Towns wrote:
> Another way of doing might be to generate task packages as we have now
> as part of dinstall, and install them into the archive. Another way
> would be to not do this as part of dinstall, but on an autobuilder.

Well, if you're going to do that, what's stopping you from pulling the
task's source package and NMUing? I don't really see the difference.

> How we make this available to apt, or frontends doesn't have to influence
> how we actually maintain it.

Ok, _this_ I can accept.

-- 
see shy jo

Re: Potato now stable

[Joey Hess]

Jason Gunthorpe wrote:
> Off hand, I would suspect you'd take an arbitary .deb and carve it into
> sub packages internally - this is for effeciency.. Other debs can come
> along and clealy install over the sub packages. Ex:
> 
> You have apt_1.1_i386.deb which contains
> 'doc'
> 'binary'
> 
> And an apt_1.1_i686_bin.deb which just have
> 'binary' 
> Inside
> 
> Package tools would sort that out through some magic means..

Perhaps these sub-packages would be additional files in the ar file.
Perhaps those files themselves should be in .deb format? Then we have
sub package nesting and meta-data too

> Of course this is all just off hand... :>

Same.

-- 
see shy jo

Re: policy changes toward Non-Interactive installation

[Manoj Srivastava]

>>"Joey" == Joey Hess <[EMAIL PROTECTED]> writes:

 Joey> If you have some specific complaints with debconf's design, please post
 Joey> them, but I'm rather confused about what you're talking about right now,
 Joey> especially since your whole message was very non-specfic and I often 
 Joey> couldn't tell if you were talking about whatever Goswin was talking 
about,
 Joey> or about debconf.

I do apologize. I was not talkgin about debconf, since I am
 not very knowledgeable about it (I have not been keeping up with it,
 unfortunately). I do intend a flag day soon to convert all my
 packages over. 

Given my ignorance of things debconf, could you please
 elucidate a few points?

 >> How about this scenario: Package A needs to run a program from
 >> Package B, and let the user choose between alternatives in order to
 >> configure package A to be in a working state. Unfortunately, the
 >> alternatives are not known before the program is run. Package A is a
 >> daemon process, so we stop the daemon before unpacking, and we start
 >> it after configuring. We pre-depend on package B, so that our program
 >> is available to us.

 Joey> Yes, debconf can handle this, with no behavior changes *at all*
 Joey> from how it would have traditionally been done.

This is interesting. Since we do not know what the options
 are, or even whether to ask the question, before unpacking, how do
 you handle this?

Let me try a concrete example; the kernel image postinst, and
 see how far we get. These are the questions the kernel image
 postinstall asks, and I have tried to figure out if the question can
 be pre asked. 

==
 - Question depends on test on fie system
/  Question important (IMHO)
|/ --- Depends on previous answer 
||/ -- Needs run time test
|||/ __ can be pre asked
/
|
|   
X...Y1) Ask to remove /System.map files
.X  Y2) ask to prepare a boot floppy
XXX.Y3) ask which floppy drive to use
.XX.?4) do I need to format the floppy?
.XXXN5) Insert floppy, hit return
.XXXN6) failure, retry?
.XXXN7) failure, you have formatted floppy?
.XXXN8) you have floppy, hit return when ready
.XXXN9) Failure writing floppy, retry?
.XXXN   10) failure, hit return when youhave new floppy
XX..Y   11) if conf exists ask if we should run $loader with old config
XXX.Y   12)Or else ask if a new $loader config
.XX.Y   13) Or else ask if loader needed at all
.XX.N   14) Install boot vlock on partition detected at runtime
N   15) Install mbr root disk
.XXXN   16) Failure writing mbr, do this manually, hit return 
.XX.N   17) make that partition active?
==



Being told that this should not be done during installation of
 the kernel-image is not what I consider useful; installing kernel
 images (yes, multiple images, in succession), and having a sane and
 bootable system with the just installed image bootable is a good
 thing (people who do not like this behaviour can already turn this
 off). 

manoj

-- 
 You will gain money by a speculation or lottery.
Manoj Srivastava   <[EMAIL PROTECTED]>  
1024R/C7261095 print CB D9 F4 12 68 07 E4 05  CC 2D 27 12 1D F5 E8 6E
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C

Re: policy changes toward Non-Interactive installation

[Joey Hess]

Manoj Srivastava wrote:
>   I do apologize. I was not talkgin about debconf, since I am
>  not very knowledgeable about it (I have not been keeping up with it,
>  unfortunately). I do intend a flag day soon to convert all my
>  packages over. 

No problem.

>   Given my ignorance of things debconf, could you please
>  elucidate a few points?

Sure.

>  >> How about this scenario: Package A needs to run a program from
>  >> Package B, and let the user choose between alternatives in order to
>  >> configure package A to be in a working state. Unfortunately, the
>  >> alternatives are not known before the program is run. Package A is a
>  >> daemon process, so we stop the daemon before unpacking, and we start
>  >> it after configuring. We pre-depend on package B, so that our program
>  >> is available to us.
> 
>  Joey> Yes, debconf can handle this, with no behavior changes *at all*
>  Joey> from how it would have traditionally been done.
> 
>   This is interesting. Since we do not know what the options
>  are, or even whether to ask the question, before unpacking, how do
>  you handle this?

Quite simply: This type of thing can not be handled before unpacking, so
it isn't. Debconf allows package to ask questions in their postinst,
this is just *strongly* discouraged. See the realplayer installer for a
package that (rarely) has to use debconf interactively in its postinst.

>   Let me try a concrete example; the kernel image postinst, and
>  see how far we get. These are the questions the kernel image
>  postinstall asks, and I have tried to figure out if the question can
>  be pre asked. 
> 
> ==
>  - Question depends on test on fie system
> /  Question important (IMHO)
> |/ --- Depends on previous answer 
> ||/ -- Needs run time test
> |||/ __ can be pre asked
> /
> |
> |   
> X...Y1) Ask to remove /System.map files
> .X  Y2) ask to prepare a boot floppy
> XXX.Y3) ask which floppy drive to use
> .XX.?4) do I need to format the floppy?
> .XXXN5) Insert floppy, hit return
> .XXXN6) failure, retry?
> .XXXN7) failure, you have formatted floppy?
> .XXXN8) you have floppy, hit return when ready
> .XXXN9) Failure writing floppy, retry?
> .XXXN   10) failure, hit return when youhave new floppy
> XX..Y   11) if conf exists ask if we should run $loader with old 
> config
> XXX.Y   12)Or else ask if a new $loader config
> .XX.Y   13) Or else ask if loader needed at all
> .XX.N   14) Install boot vlock on partition detected at runtime
> N   15) Install mbr root disk
> .XXXN   16) Failure writing mbr, do this manually, hit return 
> .XX.N   17) make that partition active?
> ==

Right. This is obviously a rather important package, which *cannot*
fail, plus is is very dependant on the actual state of the system. As
such, the best you'll be able to do is allow a few questions to be
pre-asked, and defer the remainder to the appropriate maintainer script.

(BTW, I'm ccing this to Wichert and AJ as a sterling example of why
debconf has to continue to support this type of thing in maintainer
scripts. I think both of them don't want it to have this capability, but
it is, as you have noted, essential for some packages.

-- 
see shy jo

Re: Intent To Split: netbase

[Jacob Kuntz]

John Goerzen ([EMAIL PROTECTED]) wrote:
> There is no real reason that all must listen on port 25.
> 

while i can't imagine ever justifying having postfix AND exim installed on
the same machine, your argument holds true for other things. for instance,
it's not uncommon to see a machine that has apache running on 80 for
modperl pages, with thttpd or aolserver on 8080 for static content. not to
mention what will happen when we see TUX packaged.

i guess this argument will have to be decided seperatly for each service
that it comes up for. personally, i think the smtpd maintainers would be
waisting there time, since you can't specify a port number in an email
address.

-- 
Jacob Kuntz
underworld.net/~jake
[EMAIL PROTECTED]
[EMAIL PROTECTED]

Re: Intent To Split: netbase

[Jacob Kuntz]

Clint Adams ([EMAIL PROTECTED]) wrote:
> > No real reason? Only one package can listen in on port 25, and
> 
> Only one package can listen on port 25 of one IP.  It is possible to
> have multiple packages listening on different ports or different IPs.
> 

hadn't thought of that. but once again, is there any benefit to that at all?
will the efort required by the maintainers to get this working properly
(including reading bug reports) ever balance against the tiny number of
people that would use this feature? anyone that has a reason can certianly
set this up themselves.

-- 
Jacob Kuntz
underworld.net/~jake
[EMAIL PROTECTED]
[EMAIL PROTECTED]

Re: Potato now stable

[Marcelo E. Magallon]

>> Joey Hess <[EMAIL PROTECTED]> writes:

 > Jason Gunthorpe wrote:
 > > Tasks are bettered handled through some kind of non-package means. I've
 > > long said we need to determine some kind of meta-package scheme (a
 > > 'package' whose only purpose is to logically group other packages).
 > 
 > How is introducing some basterdized form of package (perhaps it's just
 > an entry in the Packages file or something), going to allow us to
 > address problems like aj was talking about, where one of the things it
 > depends on is removed from debian, and it needs to be updated?

 in the one bit you trimmed out, Jason said:

 > Logically, the way to represent this is to have package declare
 > their membership in a grouping. This could be done via the override
 > file so as to maintain a centralized authority like we have no with
 > the task packages. Groups and user preferences about them could be
 > stored seperate to the status file.

 This wouldn't be that difficult.  Just add a 'Task:' field to the
 packages.  Have the default be non-existant (empty).  In order to add
 information to the overrides file (and not put the load on the ftp
 people's shoulders) have a 'maintained overrides', that is, a bit of
 the overrides file maintianed just like a normal package (e.g.,
 task-games.overrides).  In this way you satisfy aj's concerns
 (changing this would be as short as editing a text file, signing and
 uploading) and provide the functionality of task-packages, provided
 UI tools support this field.

 One problem here is that sooner or later someone will start thinking
 of such sick things as 'local overrides'.


  Marcelo

Re: Intent To Split: netbase

[Jason Gunthorpe]

On Tue, 15 Aug 2000, Jacob Kuntz wrote:

> while i can't imagine ever justifying having postfix AND exim installed on
> the same machine, your argument holds true for other things. for instance,
> it's not uncommon to see a machine that has apache running on 80 for

I've done it - had to really.. Two reasons
   1) Exim provides a different command line interface than say qmail,
  some software simply will not work. Thus we need a mail agent to
  move messages outbound only.
   2) Migrating between mailers. Need to have both operational at once
  in order to flush queues, test and migrate.

> modperl pages, with thttpd or aolserver on 8080 for static content. not to
> mention what will happen when we see TUX packaged.

Yes, good examples too. 

Jason

Re: Potato now stable

[Joey Hess]

Marcelo E. Magallon wrote:
>  in the one bit you trimmed out, Jason said:

Er, no, I did not ignore that, nor did I trim all of it.

-- 
see shy jo

Re: Potato now stable

[Drake Diedrich]

On Mon, Aug 14, 2000 at 11:08:59PM -0700, Joey Hess wrote:
> 
> Perhaps these sub-packages would be additional files in the ar file.
> Perhaps those files themselves should be in .deb format? Then we have
> sub package nesting and meta-data too
> 
> > Of course this is all just off hand... :>
> 
> Same.

   Irix does that with it's packages: multiple micropackages in one file.
Actually, you can also get jumbo packages, just tarballs ("tardist") with
lots of packages inside them, each package with lots of micropackages.
   Beyond the modifications to the .deb format we'd also need to modify the
way dpkg stores package information.  ls /var/lib/dpkg/info just took 30
seconds on my machine.  Each package has several files in there.  At 4K
and 1 inode apiece, the dpkg overhead is even higher than the overhead for
microdebs all in separate files.
Tasks wouldn't be well served by jumbo packages - there'd still have to
be some support for a hierarchy beyond the .deb layer, so the hierarchy
support should probably not be related to the actual file handling at all.
Maybe .debs could simply contain other, simpler .debs.  That should be
fairly easy to unpack with existing dpkg functions (whatever extracts
streams from the ar format), and would allow an infinitely deep and
arbitrarily broken-into-separate-files division.  Signed .debs are probably
an issue.

-Drake

Re: Potato now stable

[Jason Gunthorpe]

On Tue, 15 Aug 2000, Anthony Towns wrote:

> What I'd like to happen is basically be able to remove the package,
> and just have the task automatically act as though that package had
> never existed. Not complain in dselect about it, not worry people when
> Apt gives you a warning, not do anything.

Well, this is what I was trying to say before - logically it makes alot of
sense if packages are members of groups, this is the reverse of what we
have now - a list of packages in a group.

Delivery and storage of this data has *lots* of options.. 

Let me outline more clearly how I think task packages should work from a
users POV:

The user should see a list of groups (I will call them this because I
think groupings can be more general than just tasks). The UI tool will
allow sorting and searching of the groups and when browsing individual
packages it will be possible to see what groups they are part of. 

The user can select that a group is of interest to them and mark it for
'installation'. Once done this means all packages currently in the group
will be installed and all new packages added to the group in future will
be installed. The UI tool will track when new packages are added to groups
and present that information in conjunction with the traditional new
packages display.

A tree-like display can be used to show what packages are part of a group
and allow individual selection. Since some groups are quite large it may
make sense to categorize the packages lists into finer subgroups
(primarily to help the user navitagate around, but they could be seperate
at the top level too) that can all be individually selected for install. 
[Example: task-python-critical, task-python-web, task-python-gui]

Since there is a tree like display the user can pick off individual
sub-packages of the group, which would now serve nicely as an
oganizational tool. Packages may belong to many groups and appear in
multiple places in this tree - again for organiation.

Important/standard/etc priorities would become mega-groups, most people
would run with important and standard set to install - [like dselect
does], but this becomes optional - and much more controlled.

I can see that blacklisting within a group may be useful on a limited
scale. The blacklist would be expressed as 'packages a1,a2.. in group b
are not to be installed, but the rest of b is' which allows undesired
components to be eliminated by the user. Most groups should be designed to
minimize this, hence this is primarily aimed at the mega-groups rather
than smaller ones. (This is a similar, but stronger statement than your
original proposal - not automatic either) 

So now we can bring organization in on a grand scale. I can envision task
package groups that are like we have now, small very focused things,
priority groups which reflect the standard UNIX view of a system, and new
kinds of purely organization groups (how about a gnome mega-group?). We
could bring some sanity to the section arrangement by having things be
part of multiple sections, and provide stronger guidelines and more
sections.

And if you recall what I said in my last message about recommends - take
this same concept and apply it to a 'micro-group' of a single package
(where recommends and suggests form sub groups) and you have a simple
understandable concept that can be applied and used for about 5 different
things! In my book that a good thing!

If we can work out the details I think an idea like this could help in 
*alot* of areas, and is not really super complicated for us to deploy!

Jason

Re: RFP: Quadra -- a multiplayer networked smooth tetris game

[Edward C. Lang]

Hi,

> "MEM" == Marcelo E Magallon <[EMAIL PROTECTED]> writes:

MEM> Package: wnpp Severity: wishlist

MEM> Hi,

MEM> It be nice if someone packages Quadra for Debian.  It's a
MEM> tetris clone with single and multiuser modes, playable over
MEM> tcp/ip, featuring smooth graphics, worldwide high score lists,
MEM> servers and what not. 

Is it significantly different to Tetrinet? I know that gtetrinet is
packaged; what's more, it is licenced under the GPL.

Regards,

Edward.

-- 

Edward C. Lang   woot on various channels on irc.openprojects.net
[EMAIL PROTECTED] - Normal mail. Most stuff ends up here anyway.
[EMAIL PROTECTED]  - Debian mail. Finger this address for keys.
[EMAIL PROTECTED] [EMAIL PROTECTED] - Other email addresses.TINC.

Re: ITP: Moscow ML - An implementation of standard ML.

[Torsten Landschoff]

On Tue, Aug 15, 2000 at 12:32:13AM -0300, Nicolás Lichtmaier wrote:
> > Don't do that. Moscow ML was my first package when I joined and I had 
> > to learn that there are license problems. To be precise it is based on 
> > Caml Light which is not GPLed (read: has further restrictions) therefore
> > you can't link GPL-code against it. 
> > 
> > We can't distribute binaries of that :((
> 
>  Have you contacted the authors?

I don't quite remember. I think I contacted inria (they hold the Caml
copyright) about changing that but to no extent. I am not sure if changing
the MoSML license would help - at least it has to go to non-free then. 
I did not want to maintain a non-free package at that time so I gave up on 
it.

cu
Torsten

-- 
Torsten Landschoff   [EMAIL PROTECTED]   <[EMAIL PROTECTED]>
   Debian Developer and Quality Assurance Committee Member


pgpwPDG7rVULI.pgp
Description: PGP signature

Re: policy changes toward Non-Interactive installation

[Brian May]

> "Joey" == Joey Hess <[EMAIL PROTECTED]> writes:

Joey> Quite simply: This type of thing can not be handled before
Joey> unpacking, so it isn't. Debconf allows package to ask
Joey> questions in their postinst, this is just *strongly*
Joey> discouraged. See the realplayer installer for a package that
Joey> (rarely) has to use debconf interactively in its postinst.

Just curious, why does realplayer have to do it in the postinst
script?

As another example though, look at heimdal-kdc, which needs to ask for
the password, which must be kept as secure as possible.
-- 
Brian May <[EMAIL PROTECTED]>

Re: Intent To Split: netbase

[Herbert Xu]

Branden Robinson <[EMAIL PROTECTED]> wrote:

> On Mon, Aug 14, 2000 at 09:54:28AM -0400, Chad Miller wrote:
>> Hear, hear!  It would be a flag day for a few poorly written programs
>> out there, but a reorg is worth it.

> Then they're VERY poorly written.  The proper way (in posix sh) to invoke a
> command that should be in the path (but look before you leap) is this:

But I thought one of the main complaints was that /usr/sbin wasn't in the
PATH.
-- 
Debian GNU/Linux 2.2 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: Intent To Split: netbase

[Torsten Landschoff]

On Tue, Aug 15, 2000 at 02:54:01AM -0400, Jacob Kuntz wrote:
 
> hadn't thought of that. but once again, is there any benefit to that at all?
> will the efort required by the maintainers to get this working properly
> (including reading bug reports) ever balance against the tiny number of
> people that would use this feature? anyone that has a reason can certianly
> set this up themselves.

I think as long as this feature is only needed for transition we should 
not put much effort into it. You can just compile your own package for 
this transition phase and remove it later. 

OTOH if this is needed for a longer time it becomes a major hassle to upgrade
the system because you always need to recompile the package :(

cu
Torsten

-- 
Torsten Landschoff   [EMAIL PROTECTED]   <[EMAIL PROTECTED]>
   Debian Developer and Quality Assurance Committee Member


pgpOZptuHi5FF.pgp
Description: PGP signature

Re: Potato now stable

[Bas Zoetekouw]

Thus spake Anthony Towns (aj@azure.humbug.org.au):

> Once we get to woody, though, there are probably two things that are
> particularly worthwhile doing. As per usual, we should probably have a few
> weeks discussing "release goals" for woody to see what sort of direction
> we want to head (and then going ahead and implementing whatever we feel
> like anyway).

I personally would like having hardware detection stuff in woody.
Wouldn't it be great to have to install procedure ask you something like
"hi dude, I've detected that you've got a ne2000 NIC in your computer.
Shall I load the appropriate module?"? (and the same for video, sound,
scsi, etc.)

-- 
Kind regards,
+---+
| Bas Zoetekouw  | Si l'on sait exactement ce   |
|| que l'on va faire, a quoi|
| [EMAIL PROTECTED] | bon le faire?|
| [EMAIL PROTECTED] |   Pablo Picasso  |
+---+ 

Re: Intent To Split: netbase

[Manoj Srivastava]

>>"Jason" == Jason Gunthorpe <[EMAIL PROTECTED]> writes:

 Jason> I've done it - had to really.. Two reasons
 Jason>1) Exim provides a different command line interface than say qmail,
 Jason>   some software simply will not work. Thus we need a mail agent to
 Jason>   move messages outbound only.
 Jason>2) Migrating between mailers. Need to have both operational at once
 Jason>   in order to flush queues, test and migrate.

I genrally have ifconfiged the machine off the network,
 switched, and reconnected. Unless you are talking about a _ver_
 heavily uised MTA, being off line for a few minutes does not create a
 perceptible effect (since MTA's retry messages anyway -- often for
 upto 4 days, so a few minutes while installing a new one are not
 significant in most cases)

 >> modperl pages, with thttpd or aolserver on 8080 for static content. not to
 >> mention what will happen when we see TUX packaged.

 Jason> Yes, good examples too. 

Is it really your contention that all MTA's should provide for
 this configurability, and cooperate with all other MTA packages out
 of the box? I am afraid that all this handshaking is going to entail
 a lot of effort, and the resultant gains seem fairly minimal (

manoj
 hesitantly pointing  out the bit about optimizing for the
 overwhelmingly common case
-- 
 Where's the man could ease a heart like a satin gown? Dorothy Parker,
 "The Satin Dress"
Manoj Srivastava   <[EMAIL PROTECTED]>  
1024R/C7261095 print CB D9 F4 12 68 07 E4 05  CC 2D 27 12 1D F5 E8 6E
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C

Re: RFP: Quadra -- a multiplayer networked smooth tetris game

[Marcelo E. Magallon]

Hi,

>> "Edward C. Lang" <[EMAIL PROTECTED]> writes:

 > MEM> It be nice if someone packages Quadra for Debian.  It's a
 > MEM> tetris clone with single and multiuser modes, playable over
 > MEM> tcp/ip, featuring smooth graphics, worldwide high score lists,
 > MEM> servers and what not. 
 > 
 > Is it significantly different to Tetrinet? I know that gtetrinet is
 > packaged; what's more, it is licenced under the GPL.

 tetrinet? /me looks... wow.  Some people certainly dig this game, don't
 they?
 
 Again, I'm not a tetris fan, but as far as I can see, the differences
 are pretty much a look and feel thing.  Quadra is fullscreen and as far
 as I looked at it it's not themable as gtetrinet.  I don't know if it
 supports tetrinet, but I doubt it.  I don't know if gtetrinet /really/
 requires GNOME (it says so on its readme and the package does require
 the GNOME libs), Quadra doesn't.  As said, it's pretty much a self
 contained package.

 It sounds like you like tetris, perhaps you could take a look at Quadra
 and point out if it's really worth the effort.  My naive non-tetris-fan
 experience suggests people who like tetris would like this game.  But
 my naive non-tetris-fan experience is turned into nothingness after
 seeing what tetrinet is.

 Cheers,


Marcelo

Re: ITP: noffle

[Paul Slootman]

FYI:

> On Wed 28 Jun 2000, Paul Slootman wrote:
> 
> > The README says:
> > 
> >   Noffle is a Usenet news server optimized for few users and low speed 
> > dial-up
> >   connections to the Internet. It acts as a server to news clients running 
> > on
> >   the local host, but gets its news feed by acting as a client to a remote
> >   server. Noffle is written for the GNU/Linux operating system and freely
> >   available under the terms of the GPL. See COPYING for details.

I've since packaged a version that installs itself into inetd.conf,
has init.d, cron and ip-up/ip-down scripts, etc. which works pretty
well for me. It's been sitting in incoming for a couple of weeks
now; as potato is now officially released, I hope the incoming
backlog will start to go down so that noffle is installed into woody.


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: isdnutils dilemma

[Paul Slootman]

On Mon 07 Aug 2000, Ruud de Rooij wrote:
> Paul Slootman <[EMAIL PROTECTED]> writes:
> 
> > I'm in the process for building the latest version of the isdnutils,
> > with the latest upstream sources. However, I've run into a glitch,
> > licence-wise.  The isdnlog people have decided to use CDB instead
> > of DBM for the areacode etc.  The problem is that CDB is written by
> > D.J. Bernstein (of qmail fame), and the licence of CDB is vague at
> > best.
> 
> Maybe you could use freecdb instead?

Success!  I've managed to convince the upstream people to drop
the CDB version they were using (from the current non-free CDB release)
and use freecdb instead; this was done in the CVS version last night.
Another triumph for free software.


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/

Bug tracking system and testing distribution Re: Potato now stable

[Christoph Martin]

Anthony Towns writes:
 > 
 >  * Working out which bugs are really release-critical and fixing
 >their severity so we know where we're at is overly time
 >consuming.

We have a problem with the bug tracking system as long as we can't
really find out to which versions of a package a bug really
applies. We only mosttimes have the version of the packages where a
problem showed up. But we don't know if the bug was introduced with
this version or also applies to older ones. And in the case of
different distributions, if the bug was reported eg. for frozen we
don't know if it also exists in newer versions which are allready in
unstable. This is also a problem if a bug which is in one distribution
(like frozen or stable) gets fixed in another (unstable). Another
issue is, that some bugs only appear in special architectures (like
hurd, or powerpc). We really need a way to specify exactly to which
version a version applies.

As long as we don't have this feature we can't really get the
"testing" distribution to work.

 >  * New "testing" distribution
 >  This is a (mostly finished) project that will allow us
 >  to test out distribution by making it "sludgey" rather
 >  than frozen: that is, a new distribution is added between
 >  stable and unstable, that is regularly and automatically
 >  updated with new packages from unstable when they've
 >  had a little testing and now new RC bugs.
 > 
 >  (Anthony Towns; debian-devel)

Some people who met a the Useenix Debian BOF were discussion this
issue. And because I was not aware of your work on "testing" I tried
to build my own solution as a proof of concept. I set up a server at
ftp://lucy.verwaltung.uni-mainz.de/pub/debian-local/ which has a
"stabilized" distribution. This is constructed out of potatos main
part (and can be easily enhanced by contrib etc.).

Only packages which are in potato longer than (the arbitrary value of)
14 days get into "stabalized". The packages must also have correct
dependencies and no important or more severe bugs in the bug tracking
older than 14 days. 

The scripts are working quite well, but only than I found out about
the problem with the bug tracking system.

Christoph

Re: Intent To Split: netbase

[Marcus Brinkmann]

On Mon, Aug 14, 2000 at 09:54:40PM -0500, Branden Robinson wrote:
> On the other hand, fsck seems to be a good example of a program that can't
> do much for the unprivileged user.

That's not true. You can have disk image files you might want to check for
correctness.

In the Hurd, any user can boot a subhurd (a self contained system with its
own critical server processes and root fs, much better than chroot) and
wreck it. With fsck you can controll afterwards if the bug you traced down
in the subhurd (with gdb from the parent hurd) was corrupting the
filesystem.

There are probably some emulators on Linux that will benefit from this as
well.

The distinction between sbin and bin is not a hard one. It is soft based on
experience and the common case. It's also basically nonsense, because of the
2176 binaries in my path, I use a couple of dozen regularly, and having 300
further, even useless, binaries wouldn't distract me in any way.

Thanks,
Marcus

-- 
`Rhubarb is no Egyptian god.' Debian http://www.debian.org Check Key server 
Marcus Brinkmann  GNUhttp://www.gnu.orgfor public PGP Key 
[EMAIL PROTECTED], [EMAIL PROTECTED]PGP Key ID 36E7CD09
http://homepage.ruhr-uni-bochum.de/Marcus.Brinkmann/   [EMAIL PROTECTED]

Re: policy changes toward Non-Interactive installation

[Decklin Foster]

Brian May writes:

> Just curious, why does realplayer have to do it in the postinst
> script?

Binaries need to be downloaded from Real and we can't redistribute
them. The user also has to fill out 'personal information' to be able
to access the required files.

-- 
There is no TRUTH. There is no REALITY. There is no CONSISTENCY. There
are no ABSOLUTE STATEMENTS. I'm very probably wrong. -- BSD fortune(6)

Re: Potato now stable

[Andreas Fuchs]

Today, Jason Gunthorpe <[EMAIL PROTECTED]> wrote:
> The user should see a list of groups (I will call them this because I
> think groupings can be more general than just tasks). The UI tool will
> allow sorting and searching of the groups and when browsing individual
> packages it will be possible to see what groups they are part of. 

> The user can select that a group is of interest to them and mark it for
> 'installation'. Once done this means all packages currently in the group
> will be installed and all new packages added to the group in future will
> be installed. The UI tool will track when new packages are added to groups
> and present that information in conjunction with the traditional new
> packages display.

> A tree-like display can be used to show what packages are part of a group
> and allow individual selection. Since some groups are quite large it may
> make sense to categorize the packages lists into finer subgroups
> (primarily to help the user navitagate around, but they could be seperate
> at the top level too) that can all be individually selected for install. 
> [Example: task-python-critical, task-python-web, task-python-gui]


Hmm. I wonder if something like Keywords would help with that. For
example, emacs fits into many a description, say "Editor"
(understatement), "Desktop" and "Development/IDE" (sounds right to
me). Now, returning to tasks, if the user chose to use his computer as
a development environment, he could choose Emacs as his IDE.

Also, this would speed up searching a lot. When, for example, I want
to install a Tetris-like game, I could just search for the keyword
"Games/Tetris" and get every tetris-like game in the distribution, and
not only a substring match of some part of the description.

This, of course, would require the maintainers to have some sort of
discipline with the chosing of keywords for their packages, I think
every part of the program should be mentioned to make grouping the
packages and judging the package's value easier.

I presume that with keywords, a tree-like display with groups and
sub-groups could be done, but only where one can say "this thing
belongs down there", as with "Development/IDE", or
"Games/Tetris". Tetris is a game, not a physics package, so it should
be in the "Games" group. I think that many a thought will have to go
into the right naming of the groups, and their sub-categories. Also,
keep in mind that a package could be in many groups and sub-groups at
once, and therefore should be mentioned more than once in the package
managing UI. If the user opens the category "expert editors", Emacs
will show up, just as it does when the user opens the category IDEs in
Development.



This does not, in itself, solve the problem that ajt
described. Therefore, I think that we should also assign a certain
weight to a sub-category, as well as to a package in that
category. This could then look like this:


Keywords: Desktop(0), Editors/Expert(20), Development/IDE(15)


Then, for every category and sub-category, there should be a package
(or something else, I can't think of anything else in the moment),
which has a control field "Category: " set, to make it a
group and to assign a certain weight to the
sub-category. Top-level-categories should have 0, I guess.

The top-level categories would then be what is a task now, while the
sub-categories would allow the user to refine his selection until he
reaches the package level.

> Jason


And we could let it have a telepathic user interface, and have it
speed up the internet by 2000%, and have it end world hunger, and ...

Anyway.

regards,
-- 
Andreas Stefan Fuchs in Real Life aka
[EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] in NNTP and 
SMTP,
antifuchsin IRCNet and
Relf Herbstfresser, Male 1/2 Elf Priest  in AD&D

[Possibly Clueless] Deb base ISO images

[Chris Ball]

Hi, to all, and congrats on the potato release.

I've been browsing cdimage. Do we release a base system as a 30/40-ish meg
ISO that can network to enable apt handling retrieval of anything else? One
would be really useful to me, and I'm sure to others too. The base packages
(for floppies etc) aren't always so easy or convienient, and I think an ISO
image would be a really good way to show the power of apt-get etc.

I'll stop here, in case I'm being totally redundant or Just Plain Wrong.
Please let me know either way. If there isn't such an image available, why
was it decided against?

Best regards,

Chris.
--

Re: [Possibly Clueless] Deb base ISO images

[Frederik Harwath]

On Tue, Aug 15, 2000 at 02:26:33PM +0100, Chris Ball wrote:

hey Chris,
> Hi, to all, and congrats on the potato release.
> 
> I've been browsing cdimage. Do we release a base system as a 30/40-ish meg
> ISO that can network to enable apt handling retrieval of anything else? One
> would be really useful to me, and I'm sure to others too. The base packages
> (for floppies etc) aren't always so easy or convienient, and I think an ISO
> image would be a really good way to show the power of apt-get etc.

I don't know of such an image either. 
Wasn't there an ISO for a slink base-system once? As I just 
installed debian using the boot-floppies (and not the full ISOs)  on 
one of my computers, I think there should be such an ISO for potato, too.
 
Frederik

Re: [Possibly Clueless] Deb base ISO images

[Andreas Tille]

On Tue, 15 Aug 2000, Chris Ball wrote:

> I've been browsing cdimage. Do we release a base system as a 30/40-ish meg
> ISO that can network to enable apt handling retrieval of anything else? One
> would be really useful to me, and I'm sure to others too. The base packages
> (for floppies etc) aren't always so easy or convienient, and I think an ISO
> image would be a really good way to show the power of apt-get etc.
May be yoiu have a look at

  http://www.siterock.com

Christoph Lameter has build such an image with their add-ons
and handed out credit-card shaped CDs on the Debian conference in
Bordeaux.

seems me to be a good idea to make small images available or build
a deb package to create ones for those who want to create their own
images.

Kind regards

  Andreas.

Re: policy changes toward Non-Interactive installation

[Paul Slootman]

On Tue 15 Aug 2000, Decklin Foster wrote:
> Brian May writes:
> 
> > Just curious, why does realplayer have to do it in the postinst
> > script?
> 
> Binaries need to be downloaded from Real and we can't redistribute
> them. The user also has to fill out 'personal information' to be able
> to access the required files.

This couldn't be handled by `expect' or similar?


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: Intent To Split: netbase

[Jason Gunthorpe]

On 15 Aug 2000, Manoj Srivastava wrote:

>   Is it really your contention that all MTA's should provide for
>  this configurability, and cooperate with all other MTA packages out
>  of the box? I am afraid that all this handshaking is going to entail
>  a lot of effort, and the resultant gains seem fairly minimal (

No, it is just not common enough to be worth while. The way you do it by
hand is to divert sendmail, install the alternate mailer, carefully work
around the TCP service problem then hack the status file to make things
sane again. It isn't undoly hard.

Jason

How many CDs in potato?

[Peter S Galbraith]

Can anyone tell me how many CDs the official ISOs have for:

 - i386 main + main/non-US ( + contrib ?)
 - sources
 
Is contrib included as a service on official CDs like it was for
slink?

The reason I ask is that it's time for me to buy some potato CDs,
and I'm having a difficult time deciphering know what vendors are
selling (from 2 to 4 CDs):

 www.lsl.com

   Debian 2.2 Binary CDR Intel (2 CD Set)  $3.78 US

   Debian GNU/Linux 2.2 CDR Intel (5 CD Set)   $7.99 US
   This set includes 2 binary cds and 3 source cds

 www.linux-cd.com

   Official Debian 2.2 potato i386 binary 3 disk set.  Includes
   non-us encryption packages. $29.95 US

   Official++ Debian 2.2 potato i386 binary disks 1, 2, 3 and
   disk 4 (non-free).  This is the full-monty, with main,
   contrib, non-US, and includes the non-free package disk. 
   $39.95 US

  www.greenbush.com

   Potato stable i386 binary 4-CD set  $14.00 US 
   Potato stable binary/source i386 8-CD set   $26.00 US 

I'm assuming that Linux-cd's first 2 CDs are identical to LSL's,
that their third is non-us and forth is non-free.  I don't know
whether the 2-CD set includes contrib.  I assume that the 4-CD
set is identical to greenbush's.

(Why is it that I can't find this information easily when Debian
goes table.  I had the same problem with slink, finding out if
contrib was included or not on the official CDs.  I think the
http://www.debian.org/distrib/vendors page should describe what
the official CD sets are.)

Thanks,
Peter

Re: How many CDs in potato?

[Eray Ozkural]

On Tue, 15 Aug 2000 19:16:16 Peter S Galbraith wrote:
> 
> Can anyone tell me how many CDs the official ISOs have for:
> 
>  - i386 main + main/non-US ( + contrib ?)
>  - sources
>  

I have a home made 4 CD set of binary i386 main + contrib + non-free

I don't know how many CDs sources take.

__
Eray Ozkural

Non-US Incoming

[Michael Sobolev]

Is it possible to access this for non-developers?

Thanks,

--
Misha

Re: How many CDs in potato?

[Ben Collins]

On Tue, Aug 15, 2000 at 07:19:27PM +0300, Eray Ozkural wrote:
> On Tue, 15 Aug 2000 19:16:16 Peter S Galbraith wrote:
> > 
> > Can anyone tell me how many CDs the official ISOs have for:
> > 
> >  - i386 main + main/non-US ( + contrib ?)
> >  - sources
> >  

Official sets are main+contrib, which is 3cd's. This can include non-US or
not (only CD1 is different in that case). Sometimes vendors provide a 4th
binary CD with non-free (may or may not include non-US/non-free). The
source CD's are also 3 images main+contrib. Not sure how they handle
non-US and non-free.

Ben

-- 
 ---===-=-==-=---==-=--
/  Ben Collins  --  ...on that fantastic voyage...  --  Debian GNU/Linux   \
`  [EMAIL PROTECTED]  --  [EMAIL PROTECTED]  --  [EMAIL PROTECTED]  '
 `---=--===-=-=-=-===-==---=--=---'

Re: How many CDs in potato?

[Eray Ozkural]

On Tue, 15 Aug 2000 19:36:26 Ben Collins wrote:
> Official sets are main+contrib, which is 3cd's. This can include non-US or
> not (only CD1 is different in that case). Sometimes vendors provide a 4th
> binary CD with non-free (may or may not include non-US/non-free). The
> source CD's are also 3 images main+contrib. Not sure how they handle
> non-US and non-free.
> 

That's a lot of CDs. Especially if you want the source, too. I wonder if it
is possible to burn a DVD for the complete Debian 2.2 distribution?

__
Eray

Re: How many CDs in potato?

[Peter S Galbraith]

I wrote:
 
> Can anyone tell me how many CDs the official ISOs have for:
> 
>  - i386 main + main/non-US ( + contrib ?)
>  - sources
>  
> Is contrib included as a service on official CDs like it was for
> slink?
> 
> I'm having a difficult time deciphering know what vendors are
> selling (from 2 to 4 CDs):
> 
>  www.lsl.comDebian 2.2 Binary CDR Intel (2 CD Set)  $3.78 US
>  www.linux-cd.com 
>Official Debian 2.2 potato i386 binary 3 disk set.  Includes
>non-us encryption packages. $29.95 US
> 
>Official++ Debian 2.2 potato i386 binary disks 1, 2, 3 and
>disk 4 (non-free).  This is the full-monty, with main,
>contrib, non-US, and includes the non-free package disk. $39.95 US
>   www.greenbush.com
>Potato stable i386 binary 4-CD set  $14.00 US 
>Potato stable binary/source i386 8-CD set   $26.00 US 

I downloaded the list files for the official CDs:

  87205  binary-i386-1.list
  91075  binary-i386-1_NONUS.list
 115181  binary-i386-2.list
  65944  binary-i386-3.list

So 3 official CDs, with the first one either including non-us or
not (60 packages).

The strange part is that _some_ contrib packages are scattered
across the 3 CDs, but not all of the packages.  For example, lyx
is _not_ there.  Only 83 packages are included:

  ibm-jdk1.1-installer netscape3 lxdoom-sndserv lxdoom-svga
  lxdoom-x11 lxdoom lxmusserv nestra quake-3dfx quake-ggi quake-gl
  quake-sdl quake-server quake-svga quake-x11 libft-perl pgp4pine
  setiathome tkseti realplayer apple2 atari800 pose uae-exotic
  uae-suid uae vice xapple2 xcopilot lookup xjdic qps jserv
  netscape-base-4 gpgp metro-motif-lib ale-clone-war2 ale-clone
  sarien qmtpssh iraf-common iraf-ibin iraf-noaobin iraf x11iraf
  c-nocem xtrs m-tx pmx netscape-base-4-libc5 plugger
  metro-motif-bin metro-motif-demosrc metro-motif-devel
  metro-motif-demobin lib-fop-java lib-xslp-java libpgjava
  debian-keyring bsh jde quake-lib-stub mailcrypt tkpgp tkirc abcde
  fttools debian-cd freetds-jdbc pike-crypto-build cocoon-doc
  lib-openxml-java-doc lib-xslp-java-doc ale-clone-cogliati
  libhonyaku-damashii-ruby lib-openxml-java musixlyr sdic-gene95
  sdic honyaku-el cocoon gnujsp metro-motif-man

So if your favorite app from contrib isn't listed, you've have to
fetch it from the net.

I suppose if one has some Internet connection, one could get the
very cheap 2-CD set from LSL and download rarely-used packages of
CD #3 from the net.

Peter

proper place for perl modules

[Simon Richter]

Hi,

as I'm going to install buildd on a large number of machines soon, I
thought I'd redo the build scripts to use automake. Right now I'm working
on the .pm files, and I'd like to know what would be a good place to put
them. My suggestion would be @libdir@/perl5/Debian/Buildd .

   Simon

-- 
PGP public key available from http://phobos.fs.tum.de/pgp/Simon.Richter.asc
 Fingerprint: 10 62 F6 F5 C0 5D 9E D8  47 05 1B 8A 22 E5 4E C1
Hi! I'm a .signature virus! Copy me into your ~/.signature to help me spread!

Re: policy changes toward Non-Interactive installation

[Steve Greenland]

On 15-Aug-00, 02:54 (CDT), Brian May <[EMAIL PROTECTED]> wrote: 
> As another example though, look at heimdal-kdc, which needs to ask for
> the password, which must be kept as secure as possible.

Which reminds me, what sort of security is enabled in debconf? Can any
user read the values from the database, or is it limited to root?

An attempt to use db_get as a regular user, but only because the current
backend tries to write a temporary file to var/lib/debconf (I think)
(line 229 in ConfigDb.pm, potato version).

Steve

Re: Intent To Split: netbase

[Branden Robinson]

On Tue, Aug 15, 2000 at 03:33:24AM -0500, Manoj Srivastava wrote:
>  hesitantly pointing  out the bit about optimizing for the
>  overwhelmingly common case

There's a difference between *optimizing* for the common case, and
preventing the use of other cases without resorting to unofficial packages.

-- 
G. Branden Robinson | Psychology is really biology.
Debian GNU/Linux| Biology is really chemistry.
[EMAIL PROTECTED]  | Chemistry is really physics.
http://www.debian.org/~branden/ | Physics is really math.


pgpbK4vuzFXPG.pgp
Description: PGP signature

Re: Intent To Split: netbase

[Branden Robinson]

On Mon, Aug 14, 2000 at 10:53:06PM -0700, Joey Hess wrote:
> > On the other hand, fsck seems to be a good example of a program that can't
> > do much for the unprivileged user.
> 
> 
> Anyone can own a block device.
> 

To be frank I'm not distressed by the thought of lots of programs moving
from sbin to bin, or even the elimination of sbin altogether.

-- 
G. Branden Robinson |America is at that awkward stage.  It's
Debian GNU/Linux|too late to work within the system, but
[EMAIL PROTECTED]  |too early to shoot the bastards.
http://www.debian.org/~branden/ |--Claire Wolfe


pgpVCCClXhxFt.pgp
Description: PGP signature

Re: Intent To Split: netbase

[Branden Robinson]

On Tue, Aug 15, 2000 at 05:55:38PM +1000, Herbert Xu wrote:
> Branden Robinson <[EMAIL PROTECTED]> wrote:
> 
> > On Mon, Aug 14, 2000 at 09:54:28AM -0400, Chad Miller wrote:
> >> Hear, hear!  It would be a flag day for a few poorly written programs
> >> out there, but a reorg is worth it.
> 
> > Then they're VERY poorly written.  The proper way (in posix sh) to invoke a
> > command that should be in the path (but look before you leap) is this:
> 
> But I thought one of the main complaints was that /usr/sbin wasn't in the
> PATH.

Generally, maintainer scripts, and programs meant to be run by root, run as
root.

If a program expects to use some tool that only root would use, it should
expect to be running as root.

-- 
G. Branden Robinson |America is at that awkward stage.  It's
Debian GNU/Linux|too late to work within the system, but
[EMAIL PROTECTED]  |too early to shoot the bastards.
http://www.debian.org/~branden/ |--Claire Wolfe


pgplrQiJV9Lmh.pgp
Description: PGP signature

Re: ITP: gkrellweather

[Sudhakar Chandra]

Alisdair McDiarmid proclaimed:
> I intend to package gkrellweather:

> I've already made a preliminary package and put it up at:
> http://wasters.org/debian/


You might want to work with the maintainer of gkrellm ([EMAIL PROTECTED]) on a
stratergy for interfacing gkrellweather with gkrellm.  Actually, you might
just work on a gkrellm-plugins package which contains gkrellweather and
other gkrellm plugins.

Thaths
-- 
Marge: Besides, it's not just his chiseled good looks.  "People" magazine
says he's a devoted father, goes to church every week, and likes to fix 
things around the Homer, let's make love.
Homer: Uh, okay. [The lights go out.  The lights come on] 
Homer: Uh, you're thinking about me, right?
Marge: Of course, Homey.  Aren't you thinking about me? 
Homer: I will now. [The lights go off again]
Sudhakar C13nhttp://www.aunet.org/thaths/Lead Indentured Slave

Re: Potato now stable

[Branden Robinson]

[Please followup to -devel, since I do not yet subscribe to -boot]

On Tue, Aug 15, 2000 at 10:06:10AM +0200, Bas Zoetekouw wrote:
> I personally would like having hardware detection stuff in woody.

This is something Progeny is attempting to accomplish for our version of
Debian later this year.  Ian Murdock has spent some time looking into it.

Of course, everything Progeny does will be made available to the community,
particularly the Debian community.

This seems like a good time to ask; how would the boot-floppies team feel
about creating a branch in CVS for Progeny?  There are probably some things
we (Progeny) will do that Debian doesn't want to fool with.

We can of course set up our own CVS repository if need be, but this seems a
good way to do development out in the open.

-- 
G. Branden Robinson |   I just wanted to see what it looked like
Debian GNU/Linux|   in a spotlight.
[EMAIL PROTECTED]  |   -- Jim Morrison
http://www.debian.org/~branden/ |


pgpDnnvGIZcyy.pgp
Description: PGP signature

Re: Potato release? (and Mashpotato)

[Sudhakar Chandra]

Chris Ball proclaimed:
> As I understand it, the CDs will start distribution tomorrow at the first
> day of the linux expo in San Jose. (As a nice touch, this coincides with
> India's independance day)


Debian 2.2 - "We are more secure than Kashmir on India's independance day"
;-)

Thaths
-- 
Marge: Besides, it's not just his chiseled good looks.  "People" magazine
says he's a devoted father, goes to church every week, and likes to fix 
things around the Homer, let's make love.
Homer: Uh, okay. [The lights go out.  The lights come on] 
Homer: Uh, you're thinking about me, right?
Marge: Of course, Homey.  Aren't you thinking about me? 
Homer: I will now. [The lights go off again]
Sudhakar C13nhttp://www.aunet.org/thaths/Lead Indentured Slave

Re: Intent To Split: netbase

[Manoj Srivastava]

>>"Branden" == Branden Robinson <[EMAIL PROTECTED]> writes:

 Branden> On Tue, Aug 15, 2000 at 03:33:24AM -0500, Manoj Srivastava wrote:
 >> hesitantly pointing  out the bit about optimizing for the
 >> overwhelmingly common case

 Branden> There's a difference between *optimizing* for the common
 Branden> case, and preventing the use of other cases without
 Branden> resorting to unofficial packages.

Make the common things easy, and make the arcane things
 possible, if I may paraphrase. Sure, if one can make the arcane
 things easier without affecting the common things, go for it, but the
 law of diminishing returns applies. I still think it is reasonable
 for the maintainers to punt on this and let the packages
 conflict. 

As jason mentioned, it is still doable -- diversions, 
 dpkg --force-conflict, ae /varlib/dpkg/status, and judicous use of
 /etc/init.d.blah --start/stop -- hard, but possible.

Anyway, I am sure if people come up with a policy/patches for
 all the MTA's the maintainers would be happy to consider them.

I am not convinced the effort is worth it, and I thus withdraw
 from this discussion.

manoj
-- 
 "Ignorance transcends architecture." James Gaskin
Manoj Srivastava   <[EMAIL PROTECTED]>  
1024R/C7261095 print CB D9 F4 12 68 07 E4 05  CC 2D 27 12 1D F5 E8 6E
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C

how to setup an apt-getable site

[Dr. Guenter Bechly]

Hi,

I just have some weird problems to make my uploaded inofficial deb-packages
apt-getable. The referring site is http://www.bechly.de/debian/. I had all
five Debian packages in a local directory called 'debian' and correctly run
dpkg-scanpackages on it. After adjusting my apt sources.list it was no problem 
at all to access the local directory with the Packages.gz file with apt-get or 
dselect. I then uploaded the complete directory to my website via ftp (binary 
mode). Now I can access the site with 'apt-get update' without errors, but as 
soon as I use 'apt-get install foo' the package foo is downloaded but the 
installation fails with the error 'Size mismatch'.
I checked the referring manpages and docs, and several Debian books, and
did not find the slightest clue (therefore PLEAAASE no RTFMs).
Any help would be greatly appreciated.

Guenter
-- 
Linux: Who needs GATES in a world without fences?

Re: policy changes toward Non-Interactive installation

[Manoj Srivastava]

>>"Decklin" == Decklin Foster <[EMAIL PROTECTED]> writes:

 Decklin> Brian May writes:
 >> Just curious, why does realplayer have to do it in the postinst
 >> script?

 Decklin> Binaries need to be downloaded from Real and we can't redistribute
 Decklin> them. The user also has to fill out 'personal information' to be able
 Decklin> to access the required files.

Actually, this is a particular irritant. Why does it have to
 be done in the postinst? Why can't I have /usr/sbin/inst-realplayer?
 So I can download and install at my leaisure, and I do not have to
 reinstall realplayer installer to get a new copy? Or have the stupid
 thing want to connect out every time there is a minor upgrade to the
 installer? 

I would much prefer a installer script rather than an
 installer package which does it in postinst. Actually, this itch may
 have gotten to the point I want to do something about it, if the
 maintainers of realplayer are averse to this change.

manoj
-- 
 You are number 6!  Who is number one?
Manoj Srivastava   <[EMAIL PROTECTED]>  
1024R/C7261095 print CB D9 F4 12 68 07 E4 05  CC 2D 27 12 1D F5 E8 6E
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C

Re: Intent To Split: netbase

[Manoj Srivastava]

Hi,

If all we are interested in hacving a miny contentous debate,
 please skip this message, because this pre-supposes a desire to
 actually compromise and come to a rough consensus.  Unfortunately,
 common sense and a desire to actually co-operate seem to have been
 sorely lacking of late.

>>"Joey" == Joey Hess <[EMAIL PROTECTED]> writes:

 Joey> Branden Robinson wrote:
 >> On the other hand, fsck seems to be a good example of a program that can't
 >> do much for the unprivileged user.

 >> advocate type="devil's">
 Joey> Anyone can own a block device.
 >> /advocate>

Hmm. Lets step back here, and take a deep breath. What we need
 to consider is whether the underlying principle is desirable -- does
 it make sense to have two separate path components? The rationale was
 that for the common user, there are programs that are not used very
 often, and may not even work when invoked, and thus tend to only
 confuse the uninitiated, and annoy enerally by messing up command
 comletion. 

The question that seems to want to be raised is whether this
 is true? Are people really confused more by having extra commands
 available, or are they confused by _not_ havingcertain commands
 present? 

The irony is, of course, that the people generally making such
 decisions (like this forum) are rarely a decent sampling of the user
 base, or the hypothetical Joe user. 

If the answer is yes, there is still merit in the idea of
 separate path components, one needs to find a way to draw the line on
 where the utility lies. And we need to determine the utility for the
 common case -- since this is merrely a default, individual users can
 add to path components, create symlinks in ~/bin. or whatever, to get
 around the differences. 

I am sure that the imaginative people on this forum can come
 up with obscure cases where a cmmon user can generally use _any_
 program out there, espescially with a judicious choice of
 permissions. Unless one draws the line somewhere, we shall be left
 with no choices for the sbin path component whatsoever. I am not so
 sure that is useful. 

To answer Joey's comment: Any one who owns a block device is
 probably competent enough to change their own path, and this case is
 definitely not enough to move fsck out of sbin.

As to mount telling us what is mounted, so does df, and cat
 /etc/mtab. again, not enough to move mount; unless one is being
 contrary. 

manoj
 who'l probably just get flamed by Overfiend now
-- 
 Every Horse has an Infinite Number of Legs (proof by intimidation):
 Horses have an even number of legs.  Behind they have two legs, and
 in front they have fore-legs.  This makes six legs, which is
 certainly an odd number of legs for a horse.  But the only number
 that is both even and odd is infinity.  Therefore, horses have an
 infinite number of legs.  Now to show this for the general case,
 suppose that somewhere, there is a horse that has a finite number of
 legs.  But that is a horse of another color, and by the lemma ["All
 horses are the same color"], that does not exist.
Manoj Srivastava   <[EMAIL PROTECTED]>  
1024R/C7261095 print CB D9 F4 12 68 07 E4 05  CC 2D 27 12 1D F5 E8 6E
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C

Re: Intent To Split: netbase

[Steve Bowman]

On Mon, Aug 14, 2000 at 10:53:06PM -0700, Joey Hess wrote:
> Branden Robinson wrote:
> > Fine with me; either interpretation would get traceroute into (/usr)?/bin.
> 
> Same here, but ..
> 
> > On the other hand, fsck seems to be a good example of a program that can't
> > do much for the unprivileged user.
> 
> 
> Anyone can own a block device.
> 
> 

OK, how about moving everything into /bin except what FHS specifically
says should be in /sbin?  Section 3.10[0] identifies the following
specifically to be located in /sbin:

hwclock, getty, init, update, mkswap, swapon, swapoff, fastboot, fasthalt,
halt, reboot, shutdown, fdisk, fsck, fsck.*, mkfs, mkfs.*, ifconfig,
and route

(*=one or more of ext, ext2, minix, msdos, xia, and perhaps others)

It's a concrete test, it'll satisfy what seems to be the majority opinion,
and we can claim FHS compliance for it.

For those few remaining executables, people can make a symlink, change
their PATH, create an alias, or type /sbin/ first.  Of these, probably
only ifconfig and route are used by many non-root users (although Joey's
got a point).

  [0] 

Steve

Re: Intent To Split: netbase

[paul]

Why is it considered "difficult" for individual users adding /sbin and 
/usr/sbin to their path if they wish to?

I'm sure that most users are competent enough to change their own path, 
and if they are not, they will be soon after they find that they need to.

As a user with no formal computer training, and little experience other 
than GNU/Linux, changing my path was among the earliest of tasks that I 
learned.

Is there some deeper principal of Unix or Linux philosophy being discussed 
here?

Is there something to be gained that is somehow greater than can be 
achieved by changing one's own path?

Is there something I am missing about this debate?



-- 
ptw
miscelaneous endeavors
([EMAIL PROTECTED])

Building Debian Packages by Example: Packaging libgnupg.pm

[Chris Fearnley]

The Philadelphia Area Debian Society (PADS)
 (http://www.CJFearnley.com/pads/)  
   

 Presents

  Building Debian Packages by Example:  Packaging libgnupg-perl

   When:
  Wednesday 16 August 2000, 8:00 PM - 9:30 PM

   Facilitator:
  Chris Fearnley, Chief Technology Officer, LinuxForce Inc.

   Where:
  IQ Group's Technology Lab
  The Constitution Building, 12th floor, Suite 1200
  325 Chestnut Street
  Philadelphia, PA

   Abstract

   We will demonstrate the building of a Debian package by preparing a
   .deb file and source packages for libgnupg-perl, a Perl Interface for
   Gnu Privacy Guard (GnuPG.pm). Since this is a perl library module a
   few extra considerations are applicable.  However, GnuPG.pm is still
   very simple so this session will be appropriate for those new to Debian
   development.

   Social Dinner

   Attendees are invited to gather for dinner prior to the meeting at
   6:30 PM at The Nile Restaurant, 120 Chestnut Street, Philadelphia,
   PA.  Please RSVP so we can get an appropriate sized table.

-- 
Christopher J. Fearnley |   LinuxForce Inc.
[EMAIL PROTECTED]  |   Chief Technology Officer
http://www.LinuxForce.net   |   Design Science Revolutionary
   "Dare to be Naïve" -- Bucky Fuller

Re: How many CDs in potato?

[Steve Bowman]

On Tue, Aug 15, 2000 at 01:01:49PM -0400, Peter S Galbraith wrote:
> 
> [snip]
> 
> The strange part is that _some_ contrib packages are scattered
> across the 3 CDs, but not all of the packages.  For example, lyx
> is _not_ there.  Only 83 packages are included:

I think you'll find that the ones that are missing depend on non-free.
Lyx for example depends on libforms0.89 .  Apt is used by debian-cd to
set up the build and apt doesn't like broken dependencies.

Steve

-- 
Steve Bowman  <[EMAIL PROTECTED]> (preferred)
Buckeye, AZ   <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
  

Powered by Debian GNU/Linux 

Re: How many CDs in potato?

[Buddha Buck]

At 01:52 PM 8/15/00 -0700, Steve Bowman wrote:
On Tue, Aug 15, 2000 at 01:01:49PM -0400, Peter S Galbraith wrote:
>
> [snip]
>
> The strange part is that _some_ contrib packages are scattered
> across the 3 CDs, but not all of the packages.  For example, lyx
> is _not_ there.  Only 83 packages are included:
I think you'll find that the ones that are missing depend on non-free.
Lyx for example depends on libforms0.89 .  Apt is used by debian-cd to
set up the build and apt doesn't like broken dependencies.
Why would a package be in contrib if it didn't depend on non-free?  I 
thought that that was the current definition of contrib: DFSG-free, but 
requires something from outside of main (e.g., contrib or non-free).


Steve
--
Steve Bowman  <[EMAIL PROTECTED]> (preferred)
Buckeye, AZ   <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
  
Powered by Debian GNU/Linux 
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Intent To Split: netbase

[Decklin Foster]

Steve Bowman writes:

> OK, how about moving everything into /bin except what FHS specifically
> says should be in /sbin?


I very much like this idea. Does anyone have objections?

-- 
There is no TRUTH. There is no REALITY. There is no CONSISTENCY. There
are no ABSOLUTE STATEMENTS. I'm very probably wrong. -- BSD fortune(6)

Re: policy changes toward Non-Interactive installation

[Decklin Foster]

Manoj Srivastava writes:

>   Actually, this is a particular irritant. Why does it have to
>  be done in the postinst? Why can't I have /usr/sbin/inst-realplayer?
>  So I can download and install at my leaisure, and I do not have to
>  reinstall realplayer installer to get a new copy?

That's not a bad idea. Could you file a bug?

-- 
There is no TRUTH. There is no REALITY. There is no CONSISTENCY. There
are no ABSOLUTE STATEMENTS. I'm very probably wrong. -- BSD fortune(6)

Re: Deb base ISO images

[Seth Cohn]

I've been browsing cdimage. Do we release a base system as a 30/40-ish meg
ISO that can network to enable apt handling retrieval of anything else? One
would be really useful to me, and I'm sure to others too. The base packages
(for floppies etc) aren't always so easy or convienient, and I think an ISO
image would be a really good way to show the power of apt-get etc.

Linuxcare's disc can install Slink that way, and one of my goals with 
Lubbock (http://lubbock.sourceforge.net) is to have it do the same for potato.

I don't see any reason why such a disc couldn't be made easily (strip it 
down from the full version, to just the base).

slightly offtopic, I've just started a sourceforge site dedicated to 
building CD based systems (many of which use Debian).  Mailing list 
starting soon.

I'll post more in the appropriate places when I've got a description 
ready.  Anyone looking at building a bootable CD will find the tools 
useful, and the contacts even more useful.

Re: Intent To Split: netbase

[Steve Greenland]

On 15-Aug-00, 14:35 (CDT), paul <[EMAIL PROTECTED]> wrote:
> Why is it considered "difficult" for individual users adding /sbin and
> /usr/sbin to their path if they wish to?

Because stating that it is difficult is seen as an valid argument by
those who wish sbin would go away. The fact that it is obviously trivial
is not valid.

> Is there some deeper principal of Unix or Linux philosophy being
> discussed here?

No.


> Is there something to be gained that is somehow greater than can be
> achieved by changing one's own path?

No.

> Is there something I am missing about this debate?

There are people who think that the way *they* want things set up is
de-facto the way everybody want things set up. All paths, program
options and defaults should be pre-configured to be exactly what they
want them. Modifying configuration files, adding symlinks, or whatever
is too much effort, but requiring package maintainers to greatly
complicate their (the maintainers) work to accomodate every possible use
of a given package is no big deal.

Of course, the fact that the "do it my way" people don't agree about
*what* the default configurations should be doesn't seem to clue them
in...

Steve, tired of these types of arguments.

Re: Intent To Split: netbase

[Herbert Xu]

Branden Robinson <[EMAIL PROTECTED]> wrote:

> On Tue, Aug 15, 2000 at 05:55:38PM +1000, Herbert Xu wrote:
>
>> But I thought one of the main complaints was that /usr/sbin wasn't in the
>> PATH.

> Generally, maintainer scripts, and programs meant to be run by root, run as
> root.

> If a program expects to use some tool that only root would use, it should
> expect to be running as root.

So you do agree with me that it is better to leave traceroute in /usr/sbin?
-- 
Debian GNU/Linux 2.2 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: Intent To Split: netbase

[Decklin Foster]

Herbert Xu writes:

> Branden Robinson <[EMAIL PROTECTED]> wrote:
> 
> > Generally, maintainer scripts, and programs meant to be run by
> > root, run as root.
> 
> > If a program expects to use some tool that only root would use, it
> > should expect to be running as root.
> 
> So you do agree with me that it is better to leave traceroute in
> /usr/sbin?

Where did he say that? 'some tool that only root would use' means
something that requires you to be the superuser to perform a useful
action; PATH and binary locations have nothing to do with it.

-- 
There is no TRUTH. There is no REALITY. There is no CONSISTENCY. There
are no ABSOLUTE STATEMENTS. I'm very probably wrong. -- BSD fortune(6)

Re: Intent To Split: netbase

[Eray Ozkural]

On Tue, 15 Aug 2000 21:43:31 Manoj Srivastava wrote:
>   The question that seems to want to be raised is whether this
>  is true? Are people really confused more by having extra commands
>  available, or are they confused by _not_ havingcertain commands
>  present? 

I was confused by not having ifconfig in my user path. On this machine,
there's only a dial-up net connection, and it has some small connectivity
problems. I need to check whether the line's really up. I found
myself going super-user to issue the command rather than running /sbin/ifconfig.

Which is in my opinion a stupid thing to do :), but of course it felt convenient
to run sudo ifconfig, and then hmmm let's see... we must come to the conclusion
that there are thousands of programs with non-sense names anyway, so it would
be beneficial for the user to have anything that he can run on his path.

If you want people to be able to navigate in the list of available executables
in a meaningful way, please author a program that does it. Bash's command
completion just doesn't scale. Menu system is a good start, but not the ultimate
way to find out about which programs you may run.

I'd recently written in another mail to this list:

---

Although ifconfig resides in /sbin, /sbin is not in the standard user path.
However, many users need to run ifconfig, such as checking the IP address,
or whether a dial-up link has really come up.

I think it would be beneficial to supply a symbolic link to /usr/bin for this
purpose. It seems that some other programs might require similar arrangements.

Rationale for this proposal: Users do not need to know the location of
programs that they can run, they must be able to run all the "user" programs
that they can. A "user" program in this context refers to programs which
are intended to be run by people, In this sense, ifconfig seems to be a "user"
program as well as a program that can be run automatically. 

--

Yes, and I got a wise reply claimining that "ifconfig" is a system program,
and a user should manually augment his path if he wishes to run it.

I request you to re-consider the proposal. Supplying a symbolic link would
be better than putting the /sbin in user's path, because we may then decide
which programs in /sbin are needed by normal users.

Thanks,

__
Eray Ozkural

Re: isdnutils dilemma

[Torsten Landschoff]

On Tue, Aug 15, 2000 at 01:35:15PM +0200, Paul Slootman wrote:
 
> Success!  I've managed to convince the upstream people to drop
> the CDB version they were using (from the current non-free CDB release)
> and use freecdb instead; this was done in the CVS version last night.
> Another triumph for free software.

Needless to say, but anyway: Well done, Paul :)

Thanks

Torsten

-- 
Torsten Landschoff   [EMAIL PROTECTED]   <[EMAIL PROTECTED]>
   Debian Developer and Quality Assurance Committee Member


pgpAmDi6eLMO7.pgp
Description: PGP signature

CD rom image for net install

[Kenneth Scharf]

Sometime ago someone here mentioned the existance of a bootable cd rom
image that contained only the contents of the boot floppies to allow
install over the network on a computer with NO os installed.  Anyone
know the URL where I can find this image for Potato?

Thanks!

Ken

sendmail fails to generate sendmail.cf

[Atsuhito Kohda]

Hi all,

I installed woody in a partition for experiment.  I first installed
exim and recently tried to change sendmail and encountered the problem,
that is, postinst of sendmail (8.11.0.NonTLS-1) failed to generate
sendmail.cf as follows;

   You may wish to customize your alias database; see the aliases(5) man page
   for information on the format and use of the /etc/aliases file.
   
   Updating sendmail databases ...
   Checking sendmail.cf and databases.
   egrep: /etc/mail/databases: No such file or directory
   egrep: /etc/mail/databases: No such file or directory
   egrep: /etc/mail/databases: No such file or directory
   egrep: /etc/mail/databases: No such file or directory
   egrep: /etc/mail/databases: No such file or directory
   egrep: /etc/mail/databases: No such file or directory
   egrep: /etc/mail/databases: No such file or directory
   egrep: /etc/mail/databases: No such file or directory
   egrep: /etc/mail/databases: No such file or directory
   egrep: /etc/mail/databases: No such file or directory
   egrep: /etc/mail/databases: No such file or directory
   egrep: /etc/mail/databases: No such file or directory
   egrep: /etc/mail/databases: No such file or directory
   Reload the running sendmail now with the new configuration? [Y] n

and in fact there was no /etc/mail/databases.

But with upgrading, that is, if one installed sendmail_8.9.3-23 of 
potato first and then installed sendmail_8.11.0.NonTLS-1, it worked
fine as follows;

   nsx:/home/kohda# dpkg -i sendmail_8.9.3-23.deb 
   dpkg - warning: downgrading sendmail from 8.11.0.NonTLS-1 to 8.9.3-23.
   (Reading database ... 73442 files and directories currently installed.)
   Preparing to replace sendmail 8.11.0.NonTLS-1 (using sendmail_8.9.3-23.deb)
   ...
   (snip)
   ...
   Automagically regenerate the sendmail.cf configuration file? (Y/n) 
   Checking sendmail.cf and databases.
   Scanning /etc/mail/sendmail.mc
   ...
   (snip)
   ...
   they will work with the newer sendmail.  You will have to do this
   yourself - before starting sendmail.
   
   nsx:/home/kohda# dpkg -i sendmail_8.11.0.NonTLS-1.deb 
   (Reading database ... 73423 files and directories currently installed.)
   Preparing to replace sendmail 8.9.3-23 (using sendmail_8.11.0.NonTLS-1.deb)
   ...
   (snip)
   ...
   Automagically regenerate the sendmail.cf configuration file? (Y/n) 
   Saving old /etc/mail/sendmail.cf as /etc/mail/sendmail.cf.old ...
   Checking sendmail.cf and databases.
   Generating /etc/mail/sendmail.cf...
   Informational: use_ct_file file empty: /etc/mail/trusted-users
   Informational: use_cw_file file empty: /etc/mail/local-host-names
   Informational: confCR_FILE source file not found: /etc/mail/relay-domains
   Informational: confUSERDB_SPEC source file not found: /etc/mail/users
   Moving /etc/aliases to /etc/mail/aliases 
   and linking /etc/aliases to /etc/mail/aliases
   This preserves current function/abilities
   Warning: Option: CACERTPath requires TLS support
   Warning: Option: CACERTFile requires TLS support
   Warning: Option: ServerCertFile requires TLS support
   Warning: Option: Serverkeyfile requires TLS support
   Warning: Option: ClientCertFile requires TLS support
   Warning: Option: Clientkeyfile requires TLS support
   /etc/mail/aliases: 31 aliases, longest 10 bytes, 306 bytes total
   ...
   (snip)
   ... 
   they will work with the newer sendmail.  You will have to do this
   yourself - before starting sendmail.

I can not find the reason of this problem and don't know this
really is the problem or only my failure.

Thanks in advance,   2000.8.16

--
 Debian JP Developer - much more I18N of Debian
 Atsuhito Kohda <[EMAIL PROTECTED]>
 Department of Math., Tokushima Univ.

kernel-image with the same version

[Atsuhito Kohda]

Hi all,

I installed recently potato from scratch.  Rescue disk installed 
kernel 2.2.17 and I rebuild kernel-image with kerne-source 2.2.17
so the version of kernel was same for both.

When I installed kernel-image-2.2.17*.deb which I rebuild then
/vmlinuz and /vmlinuz.old were created but both pointed to the same
/boot/vmlinuz-2.2.17.  This means no back-up of old kernel was retained.

In my case, new kernel seemed to work fine so there was no problem,
I guessed, but this might cause problems.

Is this inevitable or I am missing something?

Best Regards,  2000.8.16

--
 Debian JP Developer - much more I18N of Debian
 Atsuhito Kohda <[EMAIL PROTECTED]>
 Department of Math., Tokushima Univ.

Re: policy changes toward Non-Interactive installation

[Brian May]

> "Steve" == Steve Greenland <[EMAIL PROTECTED]> writes:

Steve> Which reminds me, what sort of security is enabled in
Steve> debconf? Can any user read the values from the database, or
Steve> is it limited to root?

Not sure about this (on my system only root can read /var/lib/debconf),
however:

Steve> An attempt to use db_get as a regular user, but only
Steve> because the current backend tries to write a temporary file
Steve> to var/lib/debconf (I think) (line 229 in ConfigDb.pm,
Steve> potato version).

not sure how well temp files are managed.

I was told though, for the purpose of Heimdal-kdc, to put it in the
postinst directory. This means it doesn't have to get stored in the
database.  ie the postinst script does a "db_get" followed by a
"db_set".
-- 
Brian May <[EMAIL PROTECTED]>

Re: kernel-image with the same version

[Ben Collins]

On Wed, Aug 16, 2000 at 07:43:14AM +0900, Atsuhito Kohda wrote:
> Hi all,
> 
> I installed recently potato from scratch.  Rescue disk installed 
> kernel 2.2.17 and I rebuild kernel-image with kerne-source 2.2.17
> so the version of kernel was same for both.
> 
> When I installed kernel-image-2.2.17*.deb which I rebuild then
> /vmlinuz and /vmlinuz.old were created but both pointed to the same
> /boot/vmlinuz-2.2.17.  This means no back-up of old kernel was retained.
> 
> In my case, new kernel seemed to work fine so there was no problem,
> I guessed, but this might cause problems.
> 
> Is this inevitable or I am missing something?

Edit /etc/kernel-img.conf and add this line:

reverse_symlink := yes

That will make /vmlinux the actual file, and the ones in /boot will be the
symlinks. That may solve your problem (try installing the kernel again to
test).

-- 
 ---===-=-==-=---==-=--
/  Ben Collins  --  ...on that fantastic voyage...  --  Debian GNU/Linux   \
`  [EMAIL PROTECTED]  --  [EMAIL PROTECTED]  --  [EMAIL PROTECTED]  '
 `---=--===-=-=-=-===-==---=--=---'

Re: [PADS] Building Debian Packages by Example: Packaging libgnupg.pm

[Michael Leone]

>Attendees are invited to gather for dinner prior
> to the meeting at 6:30 PM at The Nile Restaurant, 
>120 ChestnutStreet, Philadelphia,PA.  Please RSVP so 
>we can get an appropriate sized table.

I'm in.



=
¤º°`°º¤ø,¸¸,ø¤º°`°º¤øø¤º°`°º¤ø,¸¸,ø¤º°`°º¤øø¤º°`°º¤¤º°`°º¤
Aging means your nipple ring is one year closer to getting caught on your 
shoelaces.

Michael Leone
mailto: <[EMAIL PROTECTED]>
PGP Fingerprint: 0AA8 DC47 CB63 AE3F C739 6BF9 9AB4 1EF6 5AA5 BCDF

__
Do You Yahoo!?
Yahoo! Mail – Free email you can access from anywhere!
http://mail.yahoo.com/

Re: [PADS] Building Debian Packages by Example: Packaging libgnupg.pm

[Ethan Pierce]

This idea of User groups is great.  Does anyone know where I can find a list of 
such events?  I live in the upper valley of the VT/NH border in the states.  
Thanks for any info!  -Ethan

>>> Michael Leone <[EMAIL PROTECTED]> 08/15/00 07:40PM >>>
>Attendees are invited to gather for dinner prior
> to the meeting at 6:30 PM at The Nile Restaurant, 
>120 ChestnutStreet, Philadelphia,PA.  Please RSVP so 
>we can get an appropriate sized table.

I'm in.



=
ñ  `  ñ°,++,°ñ  `  ñ°°ñ  `  ñ°,++,°ñ  `  ñ°°ñ  `  ññ  `  ñ
Aging means your nipple ring is one year closer to getting caught on your 
shoelaces.

Michael Leone
mailto: <[EMAIL PROTECTED]>
PGP Fingerprint: 0AA8 DC47 CB63 AE3F C739 6BF9 9AB4 1EF6 5AA5 BCDF

__
Do You Yahoo!?
Yahoo! Mail û Free email you can access from anywhere!
http://mail.yahoo.com/ 


-- 
Unsubscribe?  mail -s unsubscribe [EMAIL PROTECTED] < /dev/null

Intel Assembly error

[Richard Hecker]

Hi;

I ran into a compiler error that I do not recognize.  Instead of
spinning my wheels further with this, I was hoping someone familiar
with Intel assembly language on this list could shed some light on
what is happening here.  As can be seen from the comments, it is
an ancient line that was lifted from the kernel.  For this reason
I am including the output from gcc -v.

gcc -o 6x86_reg 6x86_reg.c
6x86_reg.c: In function `delay':
6x86_reg.c:86: Invalid `asm' statement:
6x86_reg.c:86: fixed or forbidden register 0 (ax) was spilled for class
AREG.

--- routine in the C source file ---
/* the original bogomips code from the Linux kernel */
static __inline__ void delay(int loops)
{
  __asm__(".align 2,0x90\n1:\tdecl %0\n\tjns 1b": :"a" (loops):"ax");
}

--- output from my woody system ---
gcc -v
Reading specs from /usr/lib/gcc-lib/i386-linux/2.95.2/specs
gcc version 2.95.2 2220 (Debian GNU/Linux)


Thanks in advance.

-- 
Richard A. Hecker

"if it isn't source, it isn't software"
brought to you courtesy of NASA

new developper with new packages

[Christophe Prud'homme]

Hi

I am developper on two projects:
1- corelinux (LGPL):   http://corelinux.sourceforge.net OOA and OOD for Linux
2- freefem(GPL):   http://kfem.sourceforge.net Finite Element Code and


I have created rather involved debian packages for them and I would like to 
submit them to woody ( see on the respective web sites )
I read some stuff on the developper's corner, but the actions to do to become 
a debian developper are not clear to me.
I was one a long time ago but for a short time.

It seems that I am an applicant and some kind of applicant manager should
review my application if I am worthy enough .
so what is the process?

I have other packages in store:
1- vtk Visualisation ToolKit http://www.kitware.com
2- vtkqgl a Qt widget for vtk 

thx for any help,
Christophe

-- 
  Christophe Prud'homme |
  MIT, 77, Mass Ave, Rm 3-243   |  The first thing we do, let's kill
  Cambridge MA 02139|  all the lawyers.
  Tel (Office) : (00 1) (617) 253 0229  |  -- Wm. Shakespeare,
  Fax (Office) : (00 1) (617) 258 8559  |  "Henry VI", Part IV
  http://augustine.mit.edu/~prudhomm|
  Following the hacker spirit

Re: How many CDs in potato?

[Peter S Galbraith]

I wrote:

> I sent LSL email and they have corrected their web site to read:
> 
>  Debian GNU/Linux 2.2 CDR Intel (6 CD Set)   $8.99
>  Debian 2.2 Binary CDR Intel (3 CD Set)  $5.50
> 
> So it's consistent now (and pretty cheap too).
> 
> Next I'll email cheapbytes because they also advertise only two
> CDs.

Cheapbytes answered back.  They corrected their web page to also
read 3 CDs:

http://cart.cheapbytes.com/cgi-bin/cart/0070010546?VPrnjIrN;;28
CheapBytes Debian 2.2 Binary CD-R Intel (3 CD Set)$6.99

Peter

Re: How many CDs in potato?

[Peter S Galbraith]

Steve Bowman wrote:

> On Tue, Aug 15, 2000 at 01:01:49PM -0400, Peter S Galbraith wrote:
> > 
> > [snip]
> > 
> > The strange part is that _some_ contrib packages are scattered
> > across the 3 CDs, but not all of the packages.  For example, lyx
> > is _not_ there.  Only 83 packages are included:
> 
> I think you'll find that the ones that are missing depend on non-free.
> Lyx for example depends on libforms0.89 .  Apt is used by debian-cd to
> set up the build and apt doesn't like broken dependencies.
> 
> Steve

There will be some broken dependencies anyway if one uses the
main 1st CD instead of the main+non-US/main CD.

Without going into the debate of whether Debian should not
promote contrib software that depends on non-free, it might be
worse to pass off the striped-down contrib as the real one.  I
hope there's a very visible note somewhere telling users that the
contrib section included for their convenience is incomplete.

I guess I'll see when my CDs arrive (which I just ordered).

Peter

Re: policy changes toward Non-Interactive installation

[Anthony Towns]

On Mon, Aug 14, 2000 at 11:38:28PM -0700, Joey Hess wrote:
> > ==
> >  - Question depends on test on fie system
> > /  Question important (IMHO)
> > |/ --- Depends on previous answer 
> > ||/ -- Needs run time test
> > |||/ __ can be pre asked
> > /
> > |
> > |   
> > X...Y1) Ask to remove /System.map files
> > .X  Y2) ask to prepare a boot floppy
> > XXX.Y3) ask which floppy drive to use
> > .XX.?4) do I need to format the floppy?
> > .XXXN5) Insert floppy, hit return
> > .XXXN6) failure, retry?
> > .XXXN7) failure, you have formatted floppy?
> > .XXXN8) you have floppy, hit return when ready
> > .XXXN9) Failure writing floppy, retry?
> > .XXXN   10) failure, hit return when youhave new floppy
> > XX..Y   11) if conf exists ask if we should run $loader with old 
> > config
> > XXX.Y   12)Or else ask if a new $loader config
> > .XX.Y   13) Or else ask if loader needed at all
> > .XX.N   14) Install boot vlock on partition detected at runtime
> > N   15) Install mbr root disk
> > .XXXN   16) Failure writing mbr, do this manually, hit return 
> > .XX.N   17) make that partition active?
> > ==
> 
> Right. This is obviously a rather important package, which *cannot*
> fail, plus is is very dependant on the actual state of the system. As
> such, the best you'll be able to do is allow a few questions to be
> pre-asked, and defer the remainder to the appropriate maintainer script.
> 
> (BTW, I'm ccing this to Wichert and AJ as a sterling example of why
> debconf has to continue to support this type of thing in maintainer
> scripts. I think both of them don't want it to have this capability,[..]

You'd be at least half right.

To clarify a little: I want to be able to answer the questions up front,
do the install and have it work. If I've made a mistake (like not put a
file where I said I did maybe), I don't mind if it dies and leaves that
package to be configured later or something. I don't want it to pause
and leave the rest of the system unconfigured, though.

This is just for my system, I don't really care that much how it works
for other people.

If we go through the `N' questions above, we have:

> > .XXXN6) failure, retry?
> > .XXXN7) failure, you have formatted floppy?
> > .XXXN9) Failure writing floppy, retry?
> > .XXXN   10) failure, hit return when youhave new floppy
> > .XXXN   16) Failure writing mbr, do this manually, hit return 

...failure cases, which I want to address as late as possible, rather
than as soon as possible. (The realplayer question is mainly a failure
question too, iirc)

> > .XXXN5) Insert floppy, hit return
> > .XX.?4) do I need to format the floppy?
> > .XXXN8) you have floppy, hit return when ready

...questions needing a temporary change in hardware. I'd answer "no,
I don't want to have a floppy" initially, or perhaps want to run
/usr/lib/kernel-2.2.17/make-floppy or something after my install's
completed.

> > .XX.N   14) Install boot block on partition detected at runtime

You can detect stuff at runtime from within the .config too; you should
be able to this before the package is actually installed. At worst, you
can say "no, don't try to detect it and annoy me later: this is what it
should be. okay? trust me"

> > N   15) Install mbr root disk
> > .XX.N   17) make that partition active?

And hence you should be able to ask these beforehand too, I think.

Basically, I'd like to be able to insist that I'm *never* asked a question
as part of a postinst. I'd rather the postinst fail (and I'd rather Apt/Dpkg
just get on with installing everything else, although it probably won't at
the moment) than get asked a question.

One way of dealing with this might be to have a debconf question,
debconf/interactive-postinst. If this is answered "no", then attempts to
ask questions from the postinst (rather than the config) should simply
fail with an error return. In .config's, logic somewhat like:

db_input kernel-image-blah/make-a-boot-floppy
if kernel-image-blah/make-a-boot-floppy = yes; then 
if debconf/interactive-postinst = no; then
db_input kernel-image-blah/cant-make-a-boot-floppy
db_set kernel-image-blah/make-a-boot-floppy no
fi
fi

should be used, I suppose. Or perhaps:

if debconf/interactive-postinst = yes; then
db_input kernel-image-blah/make-a-boot-floppy
else
db_input kernel-image-blah/cant-make-a-bo

Re: Intent To Split: netbase

[Anthony Towns]

On Wed, Aug 16, 2000 at 01:12:58AM +0300, Eray Ozkural wrote:
> I was confused by not having ifconfig in my user path. On this machine,
> there's only a dial-up net connection, and it has some small connectivity
> problems. I need to check whether the line's really up. I found
> myself going super-user to issue the command rather than running 
> /sbin/ifconfig.

ifconfig is a required file for /sbin according the the FHS section 3.10
as distributed in the debian-policy package.

Cheers,
aj

-- 
Anthony Towns <[EMAIL PROTECTED]> 
I don't speak for anyone save myself. GPG signed mail preferred.

  ``We reject: kings, presidents, and voting.
 We believe in: rough consensus and working code.''
  -- Dave Clark


pgps6l6WNTk15.pgp
Description: PGP signature

Re: policy changes toward Non-Interactive installation

[Joey Hess]

Anthony Towns wrote:
> > > X...Y1) Ask to remove /System.map files
> > > .X  Y2) ask to prepare a boot floppy
> > > XXX.Y3) ask which floppy drive to use
> > > .XX.?4) do I need to format the floppy?
> > > .XXXN5) Insert floppy, hit return
> > > .XXXN6) failure, retry?
> > > .XXXN7) failure, you have formatted floppy?
> > > .XXXN8) you have floppy, hit return when ready
> > > .XXXN9) Failure writing floppy, retry?
> > > .XXXN   10) failure, hit return when youhave new floppy
> > > XX..Y   11) if conf exists ask if we should run $loader with old 
> > > config
> > > XXX.Y   12)Or else ask if a new $loader config
> > > .XX.Y   13) Or else ask if loader needed at all
> > > .XX.N   14) Install boot vlock on partition detected at runtime
> > > N   15) Install mbr root disk
> > > .XXXN   16) Failure writing mbr, do this manually, hit return 
> > > .XX.N   17) make that partition active?

> You'd be at least half right.
> 
> To clarify a little: I want to be able to answer the questions up front,
> do the install and have it work. If I've made a mistake (like not put a
> file where I said I did maybe), I don't mind if it dies and leaves that
> package to be configured later or something. I don't want it to pause
> and leave the rest of the system unconfigured, though.

Right, and I think that's what Manoj is illistrating above. His Y's and
N's seem to mostly make sense.

> ...failure cases, which I want to address as late as possible, rather
> than as soon as possible. (The realplayer question is mainly a failure
> question too, iirc)

Yes, iirc it was (it's gone now, I think I was able to move the failure
check robustly up to the config script).

> Basically, I'd like to be able to insist that I'm *never* asked a question
> as part of a postinst. I'd rather the postinst fail (and I'd rather Apt/Dpkg
> just get on with installing everything else, although it probably won't at
> the moment) than get asked a question.

That's do-able. Once debconf knows to run postinsts in full
noninteractive mode, critical questions that are thus not asked at all,
and which do not have their return code caught, will simply cause the
postinst to terminate with a nonzero return code. 

(I think this is better than making _all_ questions terminate it, which is
not doable anyway, and also because if a postinst asks a priority low
question, say, then that is by definition a question that the 
noninteractive mode can supply a reasonable answer to.)

I'll be happy to implement a debconf/non-interactive-foo (should apply
to all maintainer scripts save config, not just postinst, so I need a
better name), if people think it will be generally useful.

However, I presonally feel your specific case of the floppy prompting
would be better served by:

a) Making the question of low priority.
or
b) Making the question be asked only once, and this value used by all
   future kernel packges you install. Or adding a question, "do you ever
   want to make a boot floppy?"

Especially b.

-- 
see shy jo

Re: Potato now stable

[Colin Walters]

Bas Zoetekouw <[EMAIL PROTECTED]> writes:

> I personally would like having hardware detection stuff in woody.
> Wouldn't it be great to have to install procedure ask you something
> like "hi dude, I've detected that you've got a ne2000 NIC in your
> computer.  Shall I load the appropriate module?"? (and the same for
> video, sound, scsi, etc.)

I noticed the other day that recent versions of RedHat use something
called "Kudzu" (sp?) to do this.  When I took out the network card, it
warned me that some hardware was missing, and offered to change some
things to compensate.

Has anyone has looked into porting this to Debian?

Re: policy changes toward Non-Interactive installation

[Brian May]

> "Joey" == Joey Hess <[EMAIL PROTECTED]> writes:

Joey> I read your entire message and could not find any examples
Joey> of things that debconf cannot handle correctly, except of
Joey> course for conffile change prompting, which it was never
Joey> designed to do.

I think something needs to be done to address this issue.

Yes, you can force dpkg to always use the old file, but then
this will break applications which require the new file to
be installed.
-- 
Brian May <[EMAIL PROTECTED]>

Re: Intent To Split: netbase

[Manoj Srivastava]

>>"Anthony" == Anthony Towns  writes:


 Anthony> ifconfig is a required file for /sbin according the the FHS
 Anthony> section 3.10 as distributed in the debian-policy package.

I think that some people are espousing non-compliance with the
 standards. Is that what we want to do?


 Steve> OK, how about moving everything into /bin except what FHS
 Steve> specifically says should be in /sbin?  Section 3.10[0]
 Steve> identifies the following specifically to be located in /sbin:

Sounds like a cop out. We are acknowledging that we can no
 longer come to a consensus on this, and we are punting on
 this. Actually, it may be closer to saying we really don't like sbin,
 and we move everything out of there, except that we also want to be
 FHS compliant, and let just tose programs stay in. 

I think we should either
  a) categorize the programs, by extending the reasoning of the FHS,
 and I have not yet lost hope of our ability to reach a rough
 consensus, 
  b) decide that the sbin idea is silly, and that's that (we can
 symlink /sbin to /bin)

I think we may be truthfully accused of losing touch with the
 generic user out there. Most of the discusion here (and, I confess,
 my knee jerk reactions), have dealt with the issue with opinions on
 what works for us -- even though developers are rarely a decent
 sampling of the unwashed masses.  My experience has been that most
 users, even most linux users, are not what the industry terms ``power
 users'' (most of these folks just call the sys admin when things go
 wrong). The defaults should be designed around them, not us, since
 power users shall always tweak the system defaults anyway. 

manoj
 stepping off the soap box
-- 
 A good teacher has been defined as one who makes himself
 progressively unnecessary.  -- Thomas J. Carruthers
Manoj Srivastava   <[EMAIL PROTECTED]>  
1024R/C7261095 print CB D9 F4 12 68 07 E4 05  CC 2D 27 12 1D F5 E8 6E
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C

Re: policy changes toward Non-Interactive installation

[Anthony Towns]

On Tue, Aug 15, 2000 at 08:26:50PM -0700, Joey Hess wrote:
> Anthony Towns wrote:
> > Basically, I'd like to be able to insist that I'm *never* asked a question
> > as part of a postinst. I'd rather the postinst fail (and I'd rather Apt/Dpkg
> > just get on with installing everything else, although it probably won't at
> > the moment) than get asked a question.
> That's do-able. Once debconf knows to run postinsts in full
> noninteractive mode, critical questions that are thus not asked at all,
> and which do not have their return code caught, will simply cause the
> postinst to terminate with a nonzero return code. 
> 
> (I think this is better than making _all_ questions terminate it, which is
> not doable anyway, and also because if a postinst asks a priority low
> question, say, then that is by definition a question that the 
> noninteractive mode can supply a reasonable answer to.)

Well, no, that's not what I want either: I like seeing every question
that the postinst thinks I might need to know about. I just want to see
them in blocks, preferably beforehand, but at the end if that's the way
it has to be.

I don't think we've got any examples of non-critical questions that need
to be outside the .config though, do we? "Something bad happened", and
"You need to stick a floppy in" don't strike me as things that should just
be ignored.

> I'll be happy to implement a debconf/non-interactive-foo (should apply
> to all maintainer scripts save config, not just postinst, so I need a
> better name), if people think it will be generally useful.

non-interactive-install, perhaps? -maintainer-scripts?

> However, I presonally feel your specific case of the floppy prompting
> would be better served by:
> a) Making the question of low priority.
> or
> b) Making the question be asked only once, and this value used by all
>future kernel packges you install. Or adding a question, "do you ever
>want to make a boot floppy?"
> Especially b.

I'm curious about your opinion of an option (c): make a separate
mk-boot-floppy script that can be run outside of the postinst after
the install.

This is the same as what Manoj suggested for realplayer. A bad thing is
that, alone, it's not really automatic, you could install the kernel
and forget to make a boot-floppy, or you could install realplayer and
forget to do what's necessary to actually, well, install realplayer. I
think it's more `user-friendly' in general though: realplayer can be
annoying the way it is at the moment, and I might change my mind and
what a boot floppy later.

Ways of getting around the `not really automatic' problem might be:
* ask a question in the .config whether you want the program to
  be run in postinst
* always run the programs after dpkg's finished, like update-menus
* send a reminder email to root

Note that this means the program probably can't really use debconf to
do its stuff if it's separate, ie, we'd suddenly be back to boring text
prompts and such. Or maybe it's reasonable for some non-maintainer-scripts
to use debconf, I suspect it's actually possible at the moment.

Having it as a separate program run after dpkg has finished would let you
have non-interactive maintainer scripts for all the examples I've seen,
I think.

Yes, I realise this won't be implemented by the end of the week. :)

Oh.

Actually...

I imagine that if we ever get post-dpkg-run hooks, they'll be invoked
something like:

run-after-dpkg /usr/bin/update-menus

and be run through sort | uniq or something before being called. It might
be possible to just implement run-after-dpkg to just run immediately for
the moment. Or to re-enable interactive-postinsts, run it, and disable it.

Ripping out the logic from update-menus and implementing it as
run-after-dpkg could probably work pretty easily too, but wouldn't leave
us with anywhere for stdio to happen, afaict [0].

Cheers,
aj

[0] Although a Unix domain socket could help here ;)

-- 
Anthony Towns <[EMAIL PROTECTED]> 
I don't speak for anyone save myself. GPG signed mail preferred.

  ``We reject: kings, presidents, and voting.
 We believe in: rough consensus and working code.''
  -- Dave Clark


pgp4P3wsStd8j.pgp
Description: PGP signature

Re: policy changes toward Non-Interactive installation

[Manoj Srivastava]

>>"Anthony" == Anthony Towns  writes:

 Anthony> To clarify a little: I want to be able to answer the
 Anthony> questions up front, do the install and have it work. If I've

This is not somethign anyone can argue with. 

 Anthony> made a mistake (like not put a file where I said I did
 Anthony> maybe), I don't mind if it dies and leaves that package to
 Anthony> be configured later or something. I don't want it to pause
 Anthony> and leave the rest of the system unconfigured, though.

This is your system, and you should be able to set the
 defaults that way (/etc/kernel-img.conf -- set do_symlink=NO
 clobber_modules=YES, do_boot_enable=NO), and you shall never be asked
 anything by the postinst. Of course, you are then responsible for
 ensuring your new kernel is booted, but hey, you can't have
 everything. 

But other people may have other choices, and I'll fight tooth
 and nail against any policy changes that leave them out in the cold
 just cause some people like non-interactive installs. 

 Anthony> This is just for my system, I don't really care that much how it works
 Anthony> for other people.

Hmm. Not an attitude I can afford to take, I don't think, as
  package maintainer ;-)

 Anthony> If we go through the `N' questions above, we have:

 >> > .XXXN6) failure, retry?
 >> > .XXXN7) failure, you have formatted floppy?
 >> > .XXXN9) Failure writing floppy, retry?
 >> > .XXXN   10) failure, hit return when youhave new floppy
 >> > .XXXN   16) Failure writing mbr, do this manually, hit return 

 Anthony> ...failure cases, which I want to address as late as possible, rather
 Anthony> than as soon as possible. (The realplayer question is mainly a failure
 Anthony> question too, iirc)

Pardon me, I think I don't understand. So, writing the floppy
 failed, and you want me to just stop doing what I was doing, leaving
 you with an unbootable system? 

I am not happy with not offering the user a chance to change
 the floppy, or quit formatting and going woth a preformatted floppy,
 or going to lilo instead. 

If you arrive at these questions, you have asked stuff to be
 done, and I can't really defer the failure case handling. Sure, I can
 say that if you asked things to be done, and ignore error recovery,
 you are responsible for the consequences, but unless that point is
 driven home, the reputation for rock solid installs may suffer.


However, I have no objection in principle to allowing people
 the *option* of silent installs. My objection is to making silent
 install the *only* option. 

 >> > .XXXN5) Insert floppy, hit return
 >> > .XX.?4) do I need to format the floppy?
 >> > .XXXN8) you have floppy, hit return when ready

 Anthony> ...questions needing a temporary change in hardware. I'd answer "no,
 Anthony> I don't want to have a floppy" initially, or perhaps want to run
 Anthony> /usr/lib/kernel-2.2.17/make-floppy or something after my install's
 Anthony> completed.

Yup. But these questions will still be asked for people who
 have not set these defaults, and these ned be asked at run time. 

 >> > .XX.N   14) Install boot block on partition detected at runtime

 Anthony> You can detect stuff at runtime from within the .config too;
 Anthony> you should be able to this before the package is actually
 Anthony> installed. At worst, you can say "no, don't try to detect it
 Anthony> and annoy me later: this is what it should be. okay? trust
 Anthony> me"


Easy. Just set up an /etc/lilo.conf (SILO,MILO< whatever) and
 this questioh shan't be asked. But there are people who have not yet
 done it, and this section is for them. 

 >> > N   15) Install mbr root disk
 >> > .XX.N   17) make that partition active?

 Anthony> And hence you should be able to ask these beforehand too, I think.

Same here. 

 Anthony> Basically, I'd like to be able to insist that I'm *never*
 Anthony> asked a question as part of a postinst. I'd rather the
 Anthony> postinst fail (and I'd rather Apt/Dpkg just get on with
 Anthony> installing everything else, although it probably won't at
 Anthony> the moment) than get asked a question.

I wuld not object to having such a mode if explicitly asked
 for. But I refuse to support what happens if you do so. As long as
 turning this option on is an admittance of responsibility for install
 failures and their consequences, fine. 

 Anthony> would be tidier. For the moment, though, as long as I *can*
 Anthony> say "no, I don't want a floppy made" and end up with a
 Anthony> non-interactive postinst, I'm happy.

I would be happy to work towards this, as long as there is no
 attempt to outlaw any installation phase interaction.  And as long as
 it is understood that people who ask for a non-interactive install
 willy-nilly do it at their own risk. 

manoj
-- 
 panic:

Re: How many CDs in potato?

[Mike Markley]

On Tue, Aug 15, 2000 at 04:58:19PM -0400, Buddha Buck <[EMAIL PROTECTED]> spake 
forth:
> Why would a package be in contrib if it didn't depend on non-free?  I 
> thought that that was the current definition of contrib: DFSG-free, but 
> requires something from outside of main (e.g., contrib or non-free).

A dependency on non-us will also land a package in contrib.

-- 
Mike Markley <[EMAIL PROTECTED]>
PGP: 0xA9592D4D 62 A7 11 E2 23 AD 4F 57  27 05 1A 76 56 92 D5 F6
GPG: 0x3B047084 7FC7 0DC0 EF31 DF83 7313  FE2B 77A8 F36A 3B04 7084

The only solution is ... a balance of power.  We arm our side with exactly
that much more.  A balance of power -- the trickiest, most difficult,
dirtiest game of them all.  But the only one that preserves both sides.
- Kirk, "A Private Little War", stardate 4211.8