Re: ALPHA-TEST permissions

[Bruce Perens]

From: Bill Mitchell <[EMAIL PROTECTED]>
> Am I that confused.  I thoght that the release presently reachable
> through ftp.debian.org:/debian/development was the development
> release.

Yes. He means making it reachable to mirror programs that aren't
explicitly looking for it.

Bruce
--
Bruce Perens <[EMAIL PROTECTED]> Pixar Animation Studios

Q: How many Microsoft engineers does it take to screw in a light bulb?
A: None.  They just define darkness as an industry standard.

Re: ALPHA-TEST permissions

[Harald Schueler]

On Sun, 17 Dec 1995, Bruce Perens wrote:

> From: Bill Mitchell <[EMAIL PROTECTED]>
> > Am I that confused.  I thoght that the release presently reachable
> > through ftp.debian.org:/debian/development was the development
> > release.
> 
> Yes. He means making it reachable to mirror programs that aren't
> explicitly looking for it.

I tried to mirror it, but I had no success with mirroring 
ALPHA-TEST/debian-1.0. It seems that mirror needs read permission on 
ALPHA-TEST to do this. What works is to mirror 
ALPHA-TEST/debian-1.0/binary etc.

But this doesn't help too much, since ftp.debian.org is about the 
worst-connected site from here, that I have seen since our connection to 
the internet 3 years ago. I don't know where exactly the bottleneck is, 
but most of the transfers are aborted or give "file shrunk from ... bytes".

I would really like to see the development version back on the mirror sites.

Harald Schueler
Universitaet EssenTel +49-201-1832456
Fachbereich 7 Fax +49-201-1832120
45117 Essen  Email [EMAIL PROTECTED]

Bug#2043: genksyms

[Richard Kettlewell]

Robert Leslie writes:
>Package: modules
>Version: 1.2.8-1
>
>I'm experimenting with the newer 1.3 kernels, so I'm not sure this is
>really a bug (yet), although it could be.
>
>The `genksyms' executable is installed in /usr/bin, despite its
>manual page belonging to section 8. The 1.3.47 kernel module support
>at least expects to find it in /sbin. I made a symlink to pacify my
>system, but perhaps it should really be moved there?

No, genksysm should be in /usr/bin (and the man page should probably
not be in section 8).  It is not the case that only the system
administrator is likely to want to use it - ordinary users might well
want to compile up a kernel and modules, for example.

This has been reported as various bugs before...

--
Richard Kettlewell  [EMAIL PROTECTED]  http://www.elmail.co.uk/staff/richard/

Bug#2043: genksyms

[Robert Leslie]

>> The `genksyms' executable is installed in /usr/bin, despite its
>> manual page belonging to section 8. The 1.3.47 kernel module support
>> at least expects to find it in /sbin. I made a symlink to pacify my
>> system, but perhaps it should really be moved there?
>
> No, genksysm should be in /usr/bin (and the man page should probably
> not be in section 8).  It is not the case that only the system
> administrator is likely to want to use it - ordinary users might well
> want to compile up a kernel and modules, for example.

Okay, but the kernel makefile calls /sbin/genksyms explicitly, which is why I
think *something* ought to be there.

Actually I see now it is a kernel version issue: 1.2.13 calls
/usr/bin/genksyms, while 1.3.47 calls /sbin/genksyms. What to do?

--
Robert Leslie
[EMAIL PROTECTED]

Bug#2043: genksyms

[Richard Kettlewell]

>Okay, but the kernel makefile calls /sbin/genksyms explicitly, which
>is why I think *something* ought to be there.
>
>Actually I see now it is a kernel version issue: 1.2.13 calls
>/usr/bin/genksyms, while 1.3.47 calls /sbin/genksyms. What to do?

The makefile ought to call `genksyms'.  The PATH environment variable
was invented for a good reason...

--
Richard Kettlewell  [EMAIL PROTECTED]  http://www.elmail.co.uk/staff/richard/

Re: Debian+umsdos (fwd)

[Juhana K Kouhia]

umsdos with windows '95 filesystem might be a problem...
With linux's msdos-fs I were not able to delete a directory;
only got 'directory is not empty'-message even the directory
were empty.

Juhana

Bug#2042: less-290-5

[Dale Scheetz]

Sorry about the first message on this bug, I was trying to figure out how
to submit one and accidently submitted the gaff instead.

This report should have said:

Running kernel 1.3.43 in a 1.0 ELF system;
  less-290-5 has been patched for the /proc filesystem, except that when
  you less a proc file, less eats the first character of the report.

Thanks,

Dwarf aka Dale Scheetz

Re: dip/CSLIP trouble (again)

[Jeff Noxon]

> See if it works OK in non-compressed mode. I think the compression module
> is buggy at the moment. That will probably go away once Simon, our new
> kernel maintainer, is up to speed.

It's a little less dain-bramaged, but it still doesn't work.  It's just
not executing ifconfig or route for some reason.

Jeff

Re: dip/CSLIP trouble (again)

[Karl Ferguson]

> > See if it works OK in non-compressed mode. I think the compression module
> > is buggy at the moment. That will probably go away once Simon, our new
> > kernel maintainer, is up to speed.
> 
> It's a little less dain-bramaged, but it still doesn't work.  It's just
> not executing ifconfig or route for some reason.

When R6 first came out I found exactly the same problem.  If you compile
SLIP/CSLIP into the kernel but *dont* load the modules for it, it will be
fine.  When image/source etc are updated (perhaps along with the boot
disks) it'll be ok...  Until the SLIP will work, just not CSLIP.

Regards

...Karl

--
 
 | PO Box 828   Office: (09)316-3036 Fax: (09)381-3909
 |OWER INTERNET SERVICES   Canning Bridge   After Hours:  015-779-828
   WA, 6153 Sales Support: [EMAIL PROTECTED]
Internet Service Providers   
 and Networking Solutions   

Re: ncurses build options...

[Ian Jackson]

Bill Mitchell writes ("Re: ncurses build options..."):
> Should all packages which use common unix commands provided
> by essential digest packages such as cat (textutls), echo
> (shellutls), mkfs (miscutls) declare explicit dependencies on
> the digest packages they need,

No.

>   or is the fact that the digest
> packages are essential sufficient to omit explicit declaration
> of dependencies on them?

Yes.

> If essential packages depend on shared libs, should those
> essential packages declare dependencies on nonessential shared
> libs?

Yes.

>   Should essential packages be dependent on nonessential
> shared libs?

There is no problem with this.

Ian.

Bug#2032: 2036. Printer stuck #3.

[Eddie Maddox]

Bug: 2032 & 2036. Printer stuck #3.
_

"the problem reports system" sent me THIS:

Your message didn't have a Package: line at the start (in the
pseudo-header following the real mail header), or didn't have a
psuedo-header at all.

This makes it much harder for us to categorise and deal with your
problem report; please ensure that you say which package(s) and
version(s) the problem is with next time.  Some time in the future the
problem reports system may start rejecting such messages.

Ian Jackson
(maintainer, debian-bugs)

-
My reply:

Package: 0, NULL, N/A, EMPTY SET, NONE

So what would make some dumb "problem reports system" think I don't have a
bunch of problems here? Don't it believe that there are bugs with MORE than
just the Packages? You can TELL it hasn't had to endure booting and installing
a system without a FUNCTIONAL "PRINT SCREEN" BUTTON, for example numero uno.

Perhaps you are implying you may set up 2 reporting systems:
1. Package problems.
2. Non-package problems.

and that the above scary message would apply only to system #1. True???
_

Bruce Perens <[EMAIL PROTECTED]> Pixar Animation Studios
sent me THIS:

You must have the "lp" module in your /etc/modules file.
Try "insmod lp" and see if the printer wakes up.
I know my printer doesn't move until that module gets loaded, so I'd guess
that's what is wrong with your system.

If that's the problem, please tell us so that we can close out the bug.

We don't have all of the drivers in the kernel when it starts because they
don't fit.

-
My reply:

"Try "insmod lp"": I WAS wondering how to figure out how to do that! Thanks.

---

"my printer doesn't move until that module gets loaded": eh?

With OR WITHOUT "that module":

Does it print the screen when you press the PRINT SCREEN button during
booting, installation and forever afterwards? Mine (HP Deskjet 500) doesn't.

Does it RESET when you press its RESET button? Mine (HP Deskjet 500) doesn't.

Does it RESET when you cycle its POWER? Mine (HP Deskjet 500) doesn't.

Does it RESET and print when you boot MS-DOS with CTRL-ALT-DEL after running
Debian? Mine (HP Deskjet 500) doesn't.

Does it RESET and print ONLY when you press the COMPUTER'S RESET button and
then boot MS-DOS after running Debian? Mine (HP Deskjet 500) DOES.


Plus, I've booted and installed Debian at least 3 times, now, both with and
without "line printer support" selected. No difference.

And, in my post #2 I showed how I did the "insmod" thing.

So, no, it does NOT appear that "that's the problem".

---

"We don't have all of the drivers in the kernel when it starts":

Could THIS be, or be a part of, "the problem"?
_

Mike sent me:

On Fri, 15 Dec 1995, Eddie Maddox wrote:
> After booting Debian GNU/Linux the printer will not print,
> the printer's own RESET button does nothing,
> and the Power On Reset doesn't happen when cycling the printer power
> switch.

My guess would be that you don't have printer support loaded.  Does your
/etc/modules file have a line for 'lp' and/or have you
compiled lp support into a custom kernel?

It is also helpful if,
before posting things to debian-bugs,
you try debian-user---
every message to debian-bugs has to be disposed of by someone,
meaning extra hassle
if it's something likely to be a simple misconfiguration like this.

-
My reply:

"My guess ...": See below.

---

"compiled ... into a custom kernel?": This is not for me.

---

"try debian-user---":

I subscribed for 2 days.
I had to unsubscribe to slow the flow.

---

"every message to debian-bugs has to be disposed of by someone":

Precisely.

---

"meaning extra hassle":

like what I'm having, too?

---

"likely to be a simple misconfiguration":

That would be nice.

_

Susan Kleinmann, [EMAIL PROTECTED], sent me:

What kind of printer do you have?  Have you tried /dev/lp1 ?

-
My reply:

HP Deskjet 500.  Yes.  And ...2, also.
_

Bruce Perens <[EMAIL PROTECTED]> Pixar Animation Studios
sent me:

Try /dev/lp0, /dev/lp1, and /dev/lp2 .

I don't think the print screen button works,

but you can print any of the virtual screens
(the ones that you access by pressing Alt-F1 through Alt-F12)
with the command (as root) "cat /dev/vcs0 >/dev/lp0" .
Change the vcs and lp numbers as appropriate.

-
My reply:

"but you can print ...":

A VERY useful tip. I use it below. I wouldn't have thought it up all by
myself for quite a while. Putting "2 & 2" together is as easy as putting a
thousand piece puzzle together all alone, 2 pieces at a time.
Very time conSUMing. Doing it together, on line like this, helps.

It does NOT replace the P

Re: coming soon

[Ian Jackson]

Bruce Perens writes ("Re: coming soon"):
> From: Ian Jackson <[EMAIL PROTECTED]>
> >[Bruce wrote:]
> >>4. The /etc/init.d/functions file will no longer be used.
> > Please make it exist and be empty so that existing programs don't
> > break.
> 
> How about having it exist and have its _current contents_ and a warning
> not to use it?

No, because many scripts source it already when they don't need to,
and therefore break when invoked from the command prompt (it does
something nasty to $*, I believe).

Last time I checked there were no scripts that actually used any of
the facilities in /etc/init.d/functions, so there's no need to keep
its contents.

If we distribute it as an empty file all of these broken scripts will
magically start working, and we can then work on getting them fixed.

I second Ian M.'s comment about removing it from the `skeleton'
example file.

Ian.

Re: New ftp method for dselect

[Ian Jackson]

Bruce Perens writes ("Re:  New ftp method for dselect"):
> I used Andy Guy's FTP method for dselect to upgrade a bunch of ELF
> packages automaticaly this evening. It worked very well, and even
> detected corrupt and partially-downloaded packages when I used a kernel
> with networking problems.

Good !

> I could make the bootstrap floppies support an FTP installation if you
> would do the work necessary to integrate this method into dselect.
> To do this you need a package naming standard - perhaps a deviation from
> your plan, but easy enough to do and it would be of great benefit to us
> in the short term. Of course we could handle it differently in the long
> term.

Right.  In order to avoid having to rename lots of packages or change
their version numbers I propose the following naming scheme for files
on the FTP site in the `binary' directory:

  --[-].deb

Note the two hyphens.

Andy, can you make a version of your method that knows about this ?
We can then go through the 1.0 tree renaming the files.
(Unfortunately this will mess up mirror sites, so we should do it
slowly, perhaps one directory at a time.)

If this turns out to be good we can do it to the 0.93 tree too.

Ian.

Re: ncurses-1.9.8a ELF release

[Ian Jackson]

David Engel writes ("Re: ncurses-1.9.8a ELF release"):
> Let's say I have a package named foo-n with a shared library in it
> named libfoo.so.x.y that, at least for the time being, must always be
> available by that name, even while dpkg is moving things around.  Now,
> at some point in the future, I know that libfoo.so.x.y whill no longer
> be needed for any number of reasons.  What I'd like to be able to do
> after dpkg is done upgrading foo-n with foo-m, removing foo-n
> completely or replacing foo-n with bar-p, is have libfoo.x.y deleted,
> if and only if, no remaining package claims to own libfoo.x.y.  Can
> this be done, and if so, how?

"Claims to own"?  Do you mean "claims to need" ?

And is "foo-n" the package name, or is "foo" the package name and "n"
the version ?

Sorry, I'm still confused.

What I meant was that, supposing you upgrade libc5 from 5.0.9-1 to
5.2.7-1, you find that the old package contains libc.so.5.0.9 and the
new libc.so.5.2.7.  The link needs to be changed to point at 5.2.9
when *both* files are available, surely, as otherwise it will point
into nowhere for a bit ?

Ian.

Re: dip/CSLIP trouble (again)

[Jeff Noxon]

> When R6 first came out I found exactly the same problem.  If you compile
> SLIP/CSLIP into the kernel but *dont* load the modules for it, it will be
> fine.  When image/source etc are updated (perhaps along with the boot
> disks) it'll be ok...  Until the SLIP will work, just not CSLIP.

Bzzt.  He is using a custom-compiled, non-debian 1.2.13 with no
modules.  It has SLIP and CSLIP in the kernel, and both work, but dip
does not execute `route' or `ifconfig' after making the connection
as best as I can tell.  About all I haven't tried is `strace'.

In any case, I can't get SLIP or CSLIP to work with DIP.

On *my* machine, it works fine.  I'm not sure why; our kernels are
almost identical.

Thanks,

Jeff

Copyright notices - mailing authors

[Ian Jackson]

It's been a while since this subject has been raised here.

It is sometimes useful to mail authors of programs with "non-free"
copyrights to ask them to relax the copyright.  This is generally
especially fruitful when the original copyright is very unclear or
badly-phrased, as this usually means the author hasn't thought about
the problem very much.

Below you'll find a couple of example messages I've sent to some
upstream authors on this subject.

Amongst them is a tabular summary of the "features" of a few
commonly-used copyright notices.

I think I was going to upload this message to ftp.debian.org.  If I
haven't done so already will someone shout and I'll do so.

I've edited them a little - especially the latter, which was
originally addressed to the Debian package maintainer and is now
addressed to the author of an original program we may wish to include.

If you want to ask someone to clarify or change their copyright the
first letter is probably a reasonable one - CC it to debian-devel or
to Ian M.  If they seem to be floundering and ask your advice or
something similar you could send them the second message, which is a
summary of the effects of various `standard' licences.

Ian.

--
Subject:  copyright and Debian GNU/Linux

I'm writing to ask your permission to include  in the Debian
GNU/Linux distribution.

As you may be aware, Linux is the free Unix-clone kernel written by
Linus Torvalds, which he releases under the GNU GPL.  Systems running
Linux include GPL'd, BSD-copyright and other (usually free) software.
For more information see the newsgroup comp.os.linux.announce, FTP to
sunsite.unc.edu and look in /pub/Linux/docs, or email me.

Debian Linux is a distribution of the Linux kernel and libraries and
associated software which is up to date, well put together and
reasonably complete.  It is the brainchild of Ian Murdock
<[EMAIL PROTECTED]>: please contact him if you have any questions;
alternatively I can email you a copy of the Debian Manifesto.

Debian Linux is of course be available for anonymous FTP from the
usual Linux sites and their mirrors.  It is organised as a base system
with a large number (around 300 at the moment) of optional packages.
We made our public beta release of version 0.93R6 in November, and are
now working on our 1.0 distribution.

I had hoped to build an  package for Debian.  However the
copyright notice leaves me in some doubt as to whether we may include
it, because we wish to ensure that the Debian Linux distribution as a
whole can be copied and redistributed freely - for example, there are
several companies which sell CD-ROM and floppy disk distributions of
Linux and related software.

The filename file in software-version says:
> notice###

It's not entirely clear to me whether this would allow (for example)
the kind of CD-ROM distribution I mentioned above.  It would be a
shame to make 's functionality available only to that portion of
the Linux community who have the time, resources and inclination to
configure, compile and install their own copy.

I'd therefore be very grateful if you could confirm optionally (on
your own behalf and on behalf of institution, who is also
listed in the copyright notice) that we may go ahead, and that by
extension it will be OK for people to distribute the  binary-only
kit I will create and the corresponding pre-configured source tree as
part of Debian Linux - potentially for profit on the part of some of
the distributors.

If you do give the go-ahead you may wish to send me a clarification,
addendum or modification to add to the source and binary packages'
copyright notices - I'd be most happy to include it.

If you have any more questions please don't hesitate to contact me.

Regards,
#debian-person

--

Subject: Copyright explanations

Here is a small summary of the effects of the GPL (or LGPL), the UCB
BSD notice, Larry Wall's Artistic Licence and of place works in the
public domain, as I interpret them.  I may be wrong - I have no legal
training, so I'd be grateful if people would like to comment on,
correct or clarify what I've said.

It's worth pointing out (especially considering the flamewars there
have occasionally been on this subject in the Linux community) that
putting the GPL on something is not the same as assigning the
copyright to the FSF (which I'd strongly advise against doing).

* The GPL strongly requires people to distribute source as well as
binaries, and not to impose further restrictions on distribution (this
ensures that the original author can use any extensions, but they may
have to release the combined work under the GPL).  It also ensures
credit is given and denies warranty liability.  Parts of GPL'd source
code may be used in other programs, provided they too are GPL'd.

* The BSD licence merely ensures due credit is given and denies
warranty liability.  It doesn't prevent people who get s

Re: Bug#2035: dpkg-deb and dpkg share the '-i' flag

[Ian Jackson]

Susan G. Kleinmann writes ("Bug#2035: dpkg-deb and dpkg share the '-i' flag"):
> I had been under the impression that dpkg-deb was invoked when dpkg itself
> was called with certain flags.  If this is the plan, then the '-i' option
> to dpkg doesn't follow the plan.  Here are the ambiguities:
> 
> dpkg -i  installs a debian archive
> dpkg -I  prints out an info file.
> dpkg --info  prints out an info file.
> 
> BUT:
> 
> dpkg-deb -i  prints out an info file.
> dpkg-deb -I  prints out an info file.
> dpkg-deb --info  prints out an info file.

That was put in for backward compatibility with very old versions of
dpkg-deb.  I'l withdraw it in the next version (1.0.9).

> The current man page for dpkg-deb says that one can get info output by
> using '-i' or '--info'.  The Usage statement for dpkg-deb says that one
> can get info output by using '-I' or '--info'.  Apparently, they are both
> right (at present).

The manpage is wrong, I've fixed it.

Thanks,
Ian.

Re: coming soon

[Ian Jackson]

Bruce Perens writes ("Re: coming soon"):
> I was talking about moving initrunlvl to /etc, not /var/log .

Ah, sorry, I misunderstood you too.

Ian.

Re: Where are the bugs?

[Ian Jackson]

Martin Schulze writes ("Where are the bugs?"):
> I'm missing bugs. In fact on ftp.debian.org /debian/debian-bugs/text
> only bugreports up to #1810 do exist. Where are newer ones?

We're working on it.  The US bugs mirror is broken atm - use the UK
site instead.

Ian.

Re: coming soon

[Ian Jackson]

Ian Murdock writes ("Re: coming soon "):
> I also agree that compatibility between distributions is paramount, but
> I'd rather convince Caldera, Red Hat, etc. to be compatible with System V
> than change Debian to be incompatible with it.  We should make talking to
> them the first step in resolving this incompatibility problem.  If they
> don't want to change, we can decide what to do from there.

I agree.  Bruce, would it be too much to ask you to hold off making
this change until we've got the issue settled ?

Thanks,
Ian.

Re: 0.93 -> 1.1 upgrade procedure?

[Ian Jackson]

Bill Mitchell writes ("0.93 -> 1.1 upgrade procedure?"):
> I had been running a hybrid system with the variously-revisioned
> elf development packages announced on 11 Nov.  Those packages
> are now lost from my system, and I've now dropped back to a
> 0.93R6 system.  What's the current recommended procedure for
> installing elf and ncurses development upgrades to a 0.93R6
> system?

I'd recommend installing only the packages from 1.0 that you need by
using dpkg manually.

Hopefully these problems will be sorted out soon and then we can use
(more or less) the standard procedure.

Ian.

Re: ALPHA-TEST permissions

[Ian Jackson]

Ian Murdock writes ("Re: ALPHA-TEST permissions"):
> I'll give people another day or so to comment on this.  If there are no
> serious objections during this time, I'm going to move the release back
> into /debian.

I agree - modulo telling people about it.  Could you announce the time
at which you're going to do it at least 48 hours in advance, so that
mirror people can read their email and then do the rename between
mirror runs ?

> I think using a code name for the release is the best idea; I'll leave
> thinking of one to the creative element of the Debian Project. :)

I propose "Diaspar" (as mentioned by Richard K. a little while ago).
We can name the next release "Trantor" or perhaps "Lys".

Bill Mitchell writes ("Re: ALPHA-TEST permissions"):
> I just want to reiterate my [unoriginal] suggestion that the
> actual directory trees be given neutral names, and be accessed
> through symlinks with meaningful names, to prevent re-mirroring
> as names change (e.g. from development to stable after the elf
> release becomes official, or from debian-1.0 to debian-1.1 as
> we find it necessary to change the release numbering).

This is exactly what we're doing with the codenames, as RJK has
pointed out.

Ian.

Re: ALPHA release of apache-1.0.0-1 now available

[Chris Fearnley]

'Michael Alan Dorman wrote:'
>
>On Sun, 17 Dec 1995, Chris Fearnley wrote:
>> This is a preliminary release.  It seems to work, but I'm disatisfied
>> with my handling of httpd configuration (basically there is none - you
>> have to edit /etc/httpd/* by hand).
>
>Hmm.  That's what kept me from releasing mine.
>
>Maybe we can decide what constitutes a resonable set of things to do at
>install time?

I like the idea of asking a set of questions in the postinst
(similarly to cern-httpd).  There are too many options to simply
impose on the user some default configuration.  Now, that I've got it
compiled, I'm reading the User Guide!  I plan to design some
specifications for the /usr/sbin/httpdconfig script (when I can code
it is another story, indeed).

>Like:
>
>* Should we create a new user and/or group to control access to the 
>hierarchy of html files?  If so, why don't we make it "official" and get 
>Bruce to include in the base /etc/group and /etc/passwd files.

User nobody and group nogroup is either already in there or is it set
up by some other package?  I suppose user wwwadmin might be better?

>* Where should we put the html hierarchy?  I mean, they could exist on 
>/usr, since it doesn't per se matter if they're read-only or not, but it 
>that "right"?  A lot of places use /home/html or some such---I personally 
>don't think this is appropriate, but someone please tell me I'm wrong.

/usr/lib/apache is my choice for serverroot.  Where the documents go
is site-specific.  I'd like to also include an option to chroot httpd
to /usr/local/http or somesuch.  Can dpkg install a package under some
arbitrary directory?  If so then the preinst script might be able to get
everything into /usr/local/http and run httpd under chroot (for the
security paranoid).

>There are others, obviously.
>
>We might also want to coordinate with Ted Hajek who maintains the cern httpd.

I looked at his work and stole many ideas from it.  Thanks Ted.

>Also, you might want to rename the package to apache-httpd and the 
>related directories and files, or you need to conflict with cern-httpd.

apache-httpd provides httpd (as does cern-httpd) so dpkg won't install
one until the other is removed.

-- 
Christopher J. Fearnley|UNIX SIG Leader at PACS
[EMAIL PROTECTED] (finger me!)|(Philadelphia Area Computer Society)
[EMAIL PROTECTED] |Design Science Revolutionary
http://www.netaxs.com/~cjf |Explorer in Universe
"Dare to be Naive" -- Bucky Fuller |Linux Advocate

Re: New ftp method for dselect

[Dirk . Eddelbuettel]

  Ian Jackson writes:
  Ian>  Right.  In order to avoid having to rename lots of packages or change
  Ian> their version numbers I propose the following naming scheme for files
  Ian> on the FTP site in the `binary' directory:
  Ian> 
  Ian>   --[-].deb
  Ian> 
  Ian> Note the two hyphens.

Could such a measure be announced 24 to 48 hours in advance, and ideally be
complemented by a script that can be used for renaming the files on the local
tree?

Otherwise folks like me will have to refetch about 110 Megabytes of */binary/*
stuff. Not that much fun over a phone line. Some people even have to pay for
every bytes they get through their phone.

--
Dirk Eddelb|ttelhttp://qed.econ.queensu.ca/~edd

Re: ALPHA release of apache-1.0.0-1 now available

[Michael Alan Dorman]

On Mon, 18 Dec 1995, Chris Fearnley wrote:
> >* Should we create a new user and/or group to control access to the 
> >hierarchy of html files?  If so, why don't we make it "official" and get 
> >Bruce to include in the base /etc/group and /etc/passwd files.
> User nobody and group nogroup is either already in there or is it set
> up by some other package?  I suppose user wwwadmin might be better?

Well, I was actually thinking of group ownership of the files themselves, 
that way you could restrict w access to those in, say, group html.  The 
files would of course have to be world readable so the server running as 
nobody/nogroup would still be able to get to them.

> /usr/lib/apache is my choice for serverroot.  Where the documents go
> is site-specific.  I'd like to also include an option to chroot httpd
> to /usr/local/http or somesuch.  Can dpkg install a package under some
> arbitrary directory?  If so then the preinst script might be able to get
> everything into /usr/local/http and run httpd under chroot (for the
> security paranoid).

Uh, why would you want to chroot the httpd?  Wouldn't that cause mondo 
problems, especially if we try and get it to do stuff like dynaloading 
modules, etc.?

> apache-httpd provides httpd (as does cern-httpd) so dpkg won't install
> one until the other is removed.

Ah.

Mike.
--
"I'm a dinosaur.  Somebody's digging my bones."

Re: More ncurses...

[Michael Alan Dorman]

On Fri, 15 Dec 1995, roro wrote:
> My bash is now (and should be in the future, maybe even with shared 
> readline):
> 
> [EMAIL PROTECTED]:tty1:/lib# ldd /bin/bash
> libncurses.so.3.0 => /lib/libncurses.so.3.0
> libc.so.5 => /lib/libc.so.5.2.18
> 
> and don't like to be invoked without libncurses.so.3.0 handy.  Is it
> really ok to move libncurses.so.3.0 to libncurses.so.3.0.new in pre

I thought of an obvious solution to this problem, and I'd like it shot 
down if possible:

simply write the scripts for doing these moves in something that's 
guaranteed to never depend on the library.  In this case, perl is the 
obvious answer.

Am I missing something?

Mike.
--
"I'm a dinosaur.  Somebody's digging my bones."

Re: ncurses-1.9.8a ELF release

[David Engel]

> > Let's say I have a package named foo-n with a shared library in it
> > named libfoo.so.x.y that, at least for the time being, must always be
> > available by that name, even while dpkg is moving things around.  Now,
> > at some point in the future, I know that libfoo.so.x.y whill no longer
> > be needed for any number of reasons.  What I'd like to be able to do
> > after dpkg is done upgrading foo-n with foo-m, removing foo-n
> > completely or replacing foo-n with bar-p, is have libfoo.x.y deleted,
> > if and only if, no remaining package claims to own libfoo.x.y.  Can
> > this be done, and if so, how?
> 
> "Claims to own"?  Do you mean "claims to need" ?

No!  By "own", I mean that the file belongs to a package and shows
up when running "dpkg -L" on that package.  I'm assuming that dpkg's
normal dependency checking won't allow the package to be removed while
others still depend on/need it.

> And is "foo-n" the package name, or is "foo" the package name and "n"
> the version ?

Foo and bar are package names.  N, m and p are different versions
and/or revisions.

> Sorry, I'm still confused.
> 
> What I meant was that, supposing you upgrade libc5 from 5.0.9-1 to
> 5.2.7-1, you find that the old package contains libc.so.5.0.9 and the
> new libc.so.5.2.7.  The link needs to be changed to point at 5.2.9
> when *both* files are available, surely, as otherwise it will point
> into nowhere for a bit ?

Now I'm confused.  That part of my message was in reference to your
comment on category 1 packages where you contradicted yourself.  Did
you mean category 2 instead?  Here is the relevant section from your
earlier message:

> As far as I can see we have three kinds of shared library:
> 
> 1. Packages like X or mkfs or what have you, where it doesn't matter
> if the library link is missing momentarily, or even if it's absent
> while the package is in a "broken" state according to dpkg.
> 
> 2. Packages like the libc or ncurses, where we can't leave it broken
> even for an instant without risking an unrecoverable system.
> 
> 3. The shared library is part of the same package as the executables
> and is version-specific - it's just there to save disk space and
> memory, and furthermore this is a critical package which we can't
> leave broken.
> 
> AFAIK only dpkg falls into category 3.  Lots of things fall into
> category 1, but they can do without special handling.
> 
> Category 1 needs the link to be updated *with both libraries present*,
> am I right ?

David
-- 
David EngelOptical Data Systems, Inc.
[EMAIL PROTECTED]  1101 E. Arapaho Road
(214) 234-6400 Richardson, TX  75081

Re: More ncurses...

[David Engel]

> > and don't like to be invoked without libncurses.so.3.0 handy.  Is it
> > really ok to move libncurses.so.3.0 to libncurses.so.3.0.new in pre
> 
> I thought of an obvious solution to this problem, and I'd like it shot 
> down if possible:
> 
> simply write the scripts for doing these moves in something that's 
> guaranteed to never depend on the library.  In this case, perl is the 
> obvious answer.
> 
> Am I missing something?

Yes, other packages may be being operated on during the same dpkg run
and they may need bash.

David
-- 
David EngelOptical Data Systems, Inc.
[EMAIL PROTECTED]  1101 E. Arapaho Road
(214) 234-6400 Richardson, TX  75081

Re: More ncurses...

[Richard Kettlewell]

>>>and don't like to be invoked without libncurses.so.3.0 handy.  Is it
>>>really ok to move libncurses.so.3.0 to libncurses.so.3.0.new in pre
>>
>>I thought of an obvious solution to this problem, and I'd like it shot 
>>down if possible:
>>
>>simply write the scripts for doing these moves in something that's 
>>guaranteed to never depend on the library.  In this case, perl is the 
>>obvious answer.
>>
>>Am I missing something?
>
>Yes, other packages may be being operated on during the same dpkg run
>and they may need bash.

...and can I just mention the Curses extension to perl here?

I believe under ELF it would actually be dynamically loaded are
therefore not drag libncurses into perl unless you actually used it,
but it's so wonderful I think it deserves a mention l-)

-- 
Richard Kettlewell  [EMAIL PROTECTED]  http://www.elmail.co.uk/staff/richard/

Re: More ncurses...

[Michael Alan Dorman]

On Mon, 18 Dec 1995, Richard Kettlewell wrote:
> I believe under ELF it would actually be dynamically loaded are
> therefore not drag libncurses into perl unless you actually used it,
> but it's so wonderful I think it deserves a mention l-)

You know, you'd think I'd remember that, considering I wrote our menu 
system here using the perlmenu stuff that uses Curses.

I wonder if it's ever going to get out of Alpha?

Mike.
--
"I'm a dinosaur.  Somebody's digging my bones."

m4 rebuilt as ELF

[Dale Scheetz]

I have rebuilt the m4 package as ELF (per Ian J.'s request) and placed 
the binary package into ftp.debian.org//debian/private/project/Incoming.

I haven't figured out how to create a .changes file yet (any pointers 
would be appreciated) but it should look something like this:

Package: m4
Priority: standard
Section: devel
Maintainer: Ian Jackson <[EMAIL PROTECTED]>
Version: 1.4
Revision: 2
Description: GNU m4 - a macro processing language

YHS,

Dwarf

Re: New ftp method for dselect

[David Engel]

> > I could make the bootstrap floppies support an FTP installation if you
> > would do the work necessary to integrate this method into dselect.
> > To do this you need a package naming standard - perhaps a deviation from
> > your plan, but easy enough to do and it would be of great benefit to us
> > in the short term. Of course we could handle it differently in the long
> > term.
> 
> Right.  In order to avoid having to rename lots of packages or change
> their version numbers I propose the following naming scheme for files
> on the FTP site in the `binary' directory:
> 
>   --[-].deb
> 
> Note the two hyphens.

I missed the first part of this thread.  Sorry.  What is the resoning
for this drastic change?  

David
-- 
David EngelOptical Data Systems, Inc.
[EMAIL PROTECTED]  1101 E. Arapaho Road
(214) 234-6400 Richardson, TX  75081

Bug#1995: run-parts on laptops

[Raul Miller]

   What does AC power have to do with run-parts ??

   run-parts is just a utility to run all the scripts in a directory.

   I think you should think where else this problem should be solved -
   possible the answer is to modify your /etc/crontab.

Yes.  On second thought I shouldn't be running cron on this particular
laptop at all.  The default configuration for cron does bad things to
the laptop.

However, savelog is a part of the cron package.  And, I very much need
savelog on this machine.

What I've done for the moment is:

(1) edit /var/lib/dpkg/info/cron.list to remove the entry referring to
savelog.

(2) dpkg --purge cron

(3) put a named /etc/rc.boot/savelog on the system which runs savelog
on all /var/log/* files that don't have numbers in their names, then
deletes all emtpy files with numbers in their names.

Which brings me back to your question: "What does AC power have to do
with run-parts ??"

I think there's a good answer to this question, but I doubt the above
workaround to the current package implementation of cron will occur to
very many people.

--
Raul

Re: m4 rebuilt as ELF

[Bill Mitchell]

> I haven't figured out how to create a .changes file yet (any pointers 
> would be appreciated) but it should look something like this:

You need the dchanges package.  Ian Murdock has been holding off
moving it into the distribution.  The last time I looked, it
was in ftp.debian.org:/debian/project/experimental.

Re: ALPHA release of apache-1.0.0-1 now available

[Chris Fearnley]

'Michael Alan Dorman wrote:'
>
>> /usr/lib/apache is my choice for serverroot.  Where the documents go
>> is site-specific.  I'd like to also include an option to chroot httpd
>> to /usr/local/http or somesuch.  Can dpkg install a package under some
>> arbitrary directory?  If so then the preinst script might be able to get
>> everything into /usr/local/http and run httpd under chroot (for the
>> security paranoid).
>
>Uh, why would you want to chroot the httpd?  Wouldn't that cause mondo 
>problems, especially if we try and get it to do stuff like dynaloading 
>modules, etc.?
>
For extra security.  Like any chroot environment, you need to copy all
the shared libs into $chroot.  But if a complete list were determined,
it could be done in the postinst.  Net Access is currently running
apache in a chroot environment for extra security.  I think it would
be nice to add this feature (My only problem is I'm not sure dpkg can
handle it - Ian?).

-- 
Christopher J. Fearnley|UNIX SIG Leader at PACS
[EMAIL PROTECTED] (finger me!)|(Philadelphia Area Computer Society)
[EMAIL PROTECTED] |Design Science Revolutionary
http://www.netaxs.com/~cjf |Explorer in Universe
"Dare to be Naive" -- Bucky Fuller |Linux Advocate

Re: Packages/Contents under 0.93

[Ian Jackson]

Karl Ferguson writes ("Packages/Contents under 0.93"):
> I'm just wondering - does the Packages* and Contents* files really need
> to be updated every day?  There are no new packages being put in the
> 0.93 area, and therefor I'm no so sure we have to...  Just saves the
> mirrors downloading the same files over and over and over again etc.

Bruce Perens writes ("Re:  Packages/Contents under 0.93"):
> I suppose it would be trivial for the script to "cmp" the old file and the
> new and not replace the old file if they match.

Since this was easy, I've implemented it.

(The Packages file in development/, and the Packages-Master file, will
still not be updated until the FTP site organisation has been sorted
out - atm I don't have write access to the relevant bits of the
archive.)

Ian.

Re: Debian+umsdos (fwd)

[Bruce Perens]

From: Juhana K Kouhia <[EMAIL PROTECTED]>
> umsdos with windows '95 filesystem might be a problem...

Good point.

What is necessary is for umssync to synchronize a Windows 95
filesystem, and umsdos to write long file names back where MS can find
them and hash short names the same way MS does.  Umsdos still has
user-id, group-id, permission, and special file information that are
not part of the extended FAT filesystem.

I am barely able to follow _Debian_ mail, and have not been reading about
umsdos developments. Does anyone know if anything is happening in this
direction?

Thanks

Bruce
--
Bruce Perens <[EMAIL PROTECTED]> Pixar Animation Studios

Re: Debian+umsdos (fwd)

[Raul Miller]

Juhana K Kouhia:
   umsdos with windows '95 filesystem might be a problem...  With
   linux's msdos-fs I were not able to delete a directory; only got
   'directory is not empty'-message even the directory were empty.

Are you sure this is because of w95?

You can also get a directory into this state using a vanilla dos file
system.  Umsdos has some race conditions in it that can fail to remove
some of the guts of links -- these will prevent the directory from
being removed until the directory has been cleaned up (e.g. mount it
as an msdos file system, then use rm -rf).

-- 
Raul

Re: ALPHA release of apache-1.0.0-1 now available

[Raul Miller]

   apache-httpd provides httpd (as does cern-httpd) so dpkg won't
   install one until the other is removed.

This isn't completely optimal (for the people who want to use apache
but also need a proxy server).  Ideally, someone should write up a
mini-howto on how to work around this simplicity feature.

-- 
Raul

Re: coming soon

[Bruce Perens]

Ian Jackson:
> I agree.  Bruce, would it be too much to ask you to hold off making
> this change until we've got the issue settled ?

I'm waiting for Miquel van Smoorenberg, the author of sysvinit, to get
back to me regarding whether he will take over the sysvinit package. If
he leads, the users of his package will probably follow. Otherwise, we
can discuss this with Eric Troan at Redhat and see if we can put a
recommendation in the FSSTD.

Thanks

Bruce
--
Bruce Perens <[EMAIL PROTECTED]> Pixar Animation Studios

Re: Package Verification

[brian (b.c.) white]

>> I'd like to suggest another field to be automatically added to the
>> "Packages" files that exist at the top of each hierarchy in the
>> distribution.  I'd like to see a "Checksum:" field that can be used to
>> verify the correct download of these packages.  I think including both
>> an 'md5sum' and a (filesize) would be best as the file size would
>> allow a reasonable check on non-Debian systems and the 'md5sum' would
>> allow absolute verification before installation.
>> 
>> Example:
>> checksum: d14d384e0895986bc9f2b09f0a8b84fc (295393)
>> 
>> The reason for this is so programs like 'dftp' can verify that they
>> retrieved the packages correctly before attempting to install them.
>
>Eventually dpkg will have its own support for package verification.
>Also, the format you propose can't be used as input to `md5sum -c'.

This is fine, but it doesn't help with verifying packages on
non-Debian systems as is required by people who must do an actual FTP
from another machine.  As for the format, feel free to alter it.  I
figured I would be parsing this line out of the Packages file, anyway.
As long as it has file size, there is at least some sort of
verification that can be done regardless of the machine being used.

Brian
 ( [EMAIL PROTECTED] )

---
In theory, theory and practice are the same.  In practice, they're not.

/etc/rc.d and RedHat compatibility

[Bruce Perens]

For the short term, I will provide a redhat compatibility package that
provides the symbolic links, etc., so that redhat packages will work
on Debian systems. Thus, the ugly symbolic links will only be there if
you ask for redhat compatibility. This is preparatory to arriving at some
sort of way of merging our binary package formats, or at least installing
both kinds of package on one system.

Thanks

Bruce

--
Bruce Perens <[EMAIL PROTECTED]> Pixar Animation Studios

Re: New ftp method for dselect

[Bruce Perens]

Ian Jackson:
> Right.  In order to avoid having to rename lots of packages or change
> their version numbers I propose the following naming scheme for files
> on the FTP site in the `binary' directory:
> 
>   --[-].deb
> 
> Note the two hyphens.

From: [EMAIL PROTECTED] (David Engel)
> I missed the first part of this thread.  Sorry.  What is the resoning
> for this drastic change?  

Distribution file names don't parse at the moment because you can't
disambiguate the package name from the version number. I had suggested
that we standardize package names so that FTP scripts would work better
and would not have to carry around a package-to-filename cross-reference.
It's a bit more ugly, I agree.

Thanks

Bruce

--
Bruce Perens <[EMAIL PROTECTED]> Pixar Animation Studios

Bug#2033: efax installation problems

[Carl Streeter]

> No! It is a conffile because /usr/bin/fax, a bash script, was the
> only place to set your local fax settings as serial port, modem capabilities,
> INIT strings, phone number, prinyer what have you.

If this is still the case, then /usr/bin/fax should be a symlink into
/etc, and the script should reside there.  /usr should be considered
read-only...


Carl Streeter |  "I'll forgive even GNU emacs as long
[EMAIL PROTECTED]  | as gcc is available" --Linus Torvalds
Just another Perl hacker  |  "You've got a body in the garage, minus
Ask me about Debian/GNU Linux.| a head.  Take me to it."  --The Wolf

Bug#2032: Printer stuck until the COMPUTER'S Reset button is pushed!

[Simon Shapiro]

Does anything at all print or does everything, unider Linux fail?
How is the printer hooked up?  Serial/Parallel/Ethernet?

I know not much about the Deskjet, but should you not process the
document through some fileter?

On the Laserjet, if you try to just dump raw text into the pronter it
will do something strange.

Call on me if you need more help...



Simon

P.S.  Please ignore the below address and flame [EMAIL PROTECTED]
  He receives and answers mail :-)


Simon Shapiro   Bullet Technologies, Inc.
[EMAIL PROTECTED]  13130 SW Haystack St.
(503) 524-6631  Beaverton, OR 97005

Re: /etc/rc.d and RedHat compatibility

[Bjoern Stabell]

Bruce wrote:
] For the short term, I will provide a redhat compatibility package that
] provides the symbolic links, etc., so that redhat packages will work
] on Debian systems. Thus, the ugly symbolic links will only be there if
] you ask for redhat compatibility. This is preparatory to arriving at some
] sort of way of merging our binary package formats, or at least installing
] both kinds of package on one system.

a common package format would be great, high priority for me at least :)

btw, what problems can i expect the other way, i.e., installing Debian
packages on RedHat systems?  do the Debian dpkg at least check to see
if it is overwriting existing files?

i was thinking of installing Debian packages on a RedHat system just now,
actually.


bye,
-- 
Bjørn Stabell 
  
  

Re: ALPHA release of apache-1.0.0-1 now available

[Chris Fearnley]

'Raul Miller wrote:'
>
>   apache-httpd provides httpd (as does cern-httpd) so dpkg won't
>   install one until the other is removed.
>
>This isn't completely optimal (for the people who want to use apache
>but also need a proxy server).  Ideally, someone should write up a
>mini-howto on how to work around this simplicity feature.

Ideally, a package should have no conflicts.  But the develment effort
can be hard.  I'm not familiar with the issues involved in installing
a proxy server.  Could you inform me?  Maybe there is a way to make
cern, apache, spinner, etc. all independent packages that will be
congnizant and considerate of the other web servers installed.  I'd
like to set that as a goal.  But for expediency, I think we will have
to use conflicts.

-- 
Christopher J. Fearnley|UNIX SIG Leader at PACS
[EMAIL PROTECTED] (finger me!)|(Philadelphia Area Computer Society)
[EMAIL PROTECTED] |Design Science Revolutionary
http://www.netaxs.com/~cjf |Explorer in Universe
"Dare to be Naive" -- Bucky Fuller |Linux Advocate

Re: /etc/rc.d and RedHat compatibility

[Bruce Perens]

From: Bjoern Stabell <[EMAIL PROTECTED]>
> a common package format would be great, high priority for me at least :)

Thanks. I think going with a "redhat compatibility package" is the right
way for now, as it allows me to sidestep the esthetic objections for the
short term - the objectors need not install the package.
In the long term, the esthetic problems will be resolved.

What is really necessary to make package interchange work is some sort
of join of the databases created by both package systems - however,
a common package format would be nice to have.

> btw, what problems can i expect the other way, i.e., installing Debian
> packages on RedHat systems?  do the Debian dpkg at least check to see
> if it is overwriting existing files?

It depends on what package you install. If it's a self-contained program
like "gnuchess", probably no problem. If it's a system utility, you could
mess up the system in a big way.
Right now, you can't expect it to be trouble-free, because there is no
package conflict mechanism on redhat. Debian would not register a conflict
if you installed a redhat package, either.

> i was thinking of installing Debian packages on a RedHat system just now,
> actually.

Make a backup first.

Bruce
--
Bruce Perens <[EMAIL PROTECTED]> Pixar Animation Studios

Bug#2045: smb[u]mount not suid root

[Robert Leslie]

Package: ksmbfs
Version: 0.2.4-2

The `smbmount' and `smbumount' commands are supposed to be suid-safe so that
normal users can mount and unmount SMB filesystems.

Could the package please install these suid root, or perhaps at least query
the user to see if they should be?

If they are installed suid root, they should also probably go in /bin or
/usr/bin rather than /sbin? I'd prefer /usr/bin, but either would be fine.

Thanks.

--
Robert Leslie
[EMAIL PROTECTED]

Re: coming soon

[Simon Shapiro]

> Isn't it just as likely that /var/log will be on a mounted filesystem?
> (In fact /var is a separate filesystem on mine.)

Ditto here ( and /var/spool is separate too).  To be sane/safe, assume
that /sbin, /lib, and /etc are all that / has at boot time.  Anything
else can be mounted on some mut's system.


Simon

P.S.  Please ignore the below address and flame [EMAIL PROTECTED]
  He receives and answers mail :-)


Simon Shapiro   Bullet Technologies, Inc.
[EMAIL PROTECTED]  13130 SW Haystack St.
(503) 524-6631  Beaverton, OR 97005

Re: Debian+umsdos (fwd)

[Richard Kettlewell]

I've heard other reports of UMSDOS interacting badly with W95's long
filename stuff.  I'd put it down as a `backup first' thing for now -
though I don't use either of them.

>   umsdos with windows '95 filesystem might be a problem...  With
>   linux's msdos-fs I were not able to delete a directory; only got
>   'directory is not empty'-message even the directory were empty.
>
>Are you sure this is because of w95?
>
>You can also get a directory into this state using a vanilla dos file
>system.  Umsdos has some race conditions in it that can fail to
>remove some of the guts of links -- these will prevent the directory
>from being removed until the directory has been cleaned up
>(e.g. mount it as an msdos file system, then use rm -rf).

-- 
Richard Kettlewell [EMAIL PROTECTED] http://www.elmail.co.uk/staff/richard/

Re: Bug#2043: genksyms

[Simon Shapiro]

>> The 1.3.47 kernel module support
>>at least expects to find it in /sbin. I ran into thesame problem before.  

> No, genksysm should be in /usr/bin (and the man page should probably
> not be in section 8)

Another  way of looking at this is to check if the executable in
question is statically linked.  If not, put it in /usr/  /sbin
things should not depend on shared libraries in /usr/lib.  Some do.



Simon

P.S.  Please ignore the below address and flame [EMAIL PROTECTED]
  He receives and answers mail :-)


Simon Shapiro   Bullet Technologies, Inc.
[EMAIL PROTECTED]  13130 SW Haystack St.
(503) 524-6631  Beaverton, OR 97005

Re: Debian+umsdos (fwd)

[Simon Shapiro]

And why do we want this brain dead file system (which even M$ does not
use for its own 1980 eras OS's) to boot a Unix O/S with?


Simon

P.S.  Please ignore the below address and flame [EMAIL PROTECTED]
  He receives and answers mail :-)


Simon Shapiro   Bullet Technologies, Inc.
[EMAIL PROTECTED]  13130 SW Haystack St.
(503) 524-6631  Beaverton, OR 97005

Re: Bug#2032: 2036. Printer stuck #3.

[Simon Shapiro]

My grandma used to say that you catch many more flies with honey than vinegar.

> ...some dumb "problem reports system" 

This is really an attitude/frustration problem.  I know you must be
frustrated as hack by now but;

I sent you a detailed list of suggestions.  Free of charge.  I can see
that several others did the same.  We do not get paid for this effort,
nor do you.  Without friendly cooperation we will not get anywhere.

Looks to me that your system problems get boiled down to a stubborn
printer relationships (we are over the ``line printer'' issue.  Right?).
 I repeat my offer to save you the time and patience reading a Unix
introduction and explain to you the mechanics of what we are trying to
accomplish here, but you have to be interested in that explanation first.

I could try and guess what is wron with your system, why the printer
gets stuck, etc.  But you have to be willing to be helped.

If your purpose is to bitch Linux/Debian out, then my time is better
served elsewhere.  
Let my just point out to you that:
A.  The Debian project is underfunded about 1Billion:1 compared with M$.
B.  We produce upgrades and updates at the rate of 2-5 packages per day.
 About 100-200 times better than M$ could ever do.
C.  New O/S kernels are produced about 1-2/month, about 25 times faster
than M$ could ever do.
D.  The response time to your problem was measured in minutes.  You 
received help that is worth about $300 when purchsed from M$, over
$1,000 in value.
E.  Unlike M$, no one owes you anything.  just a friendly obligation of
honor to help a fellow man in time of need.

So, A glass of ice-water, a deep breath and call me at home tonight. 
I'll get you going.  If I can.

Simon (503).524.6631 or 579-4119




Simon

P.S.  Please ignore the below address and flame [EMAIL PROTECTED]
  He receives and answers mail :-)


Simon Shapiro   Bullet Technologies, Inc.
[EMAIL PROTECTED]  13130 SW Haystack St.
(503) 524-6631  Beaverton, OR 97005

Incoming file permissions

[Dale Miller]

I noticed that some but not all of the new packages
that get uploaded to the Incoming directory don't have
read permissions. Is there a reason for this? Are they
uploaded that way? I like to install the latest and
greatest as quick as possible. I know, that could be asking
for trouble but that's me. I am particularily interested
in the dmalloc package that just came out but couldn't
get it for the past couple of days. If there is a reason
why it is like that then no problem. I was jsut curious
why only part of the packages were uploaded that way.

Thanks 
Dale

Re: New ftp method for dselect

[Bill Mitchell]

On Mon, 18 Dec 1995, Bruce Perens wrote:

> Distribution file names don't parse at the moment because you can't
> disambiguate the package name from the version number. I had suggested
> that we standardize package names so that FTP scripts would work better
> and would not have to carry around a package-to-filename cross-reference.
> It's a bit more ugly, I agree.

dchanges(1) seems to parse distribution filenames OK, though the
parsing code is pretty ugly.  If it's broken, please let me know.

Bug#2036: Printer stuck #2.

[Simon Shapiro]

Please, do not be offended but an introductory book to Unix may help you
here (to a degree).

> 1. I didn't have lp installed since the installation parameter screen
> for this said "line printer", not just "printer".

``Line printer'' is as valid in Linux as a ``tty'' device name.  We do
not have line printers, nor teletype machines for quite a while.  We
call any directly connected printer a line printer and any character
oriented terminal a ``tty''.  Just a name,  you see.
Enable your line printer.  It's OK.

> 2. I ran: insmod lp
> the result:

> Module:#pages:  Used by:
> lp 2

This is good.  The kernel accepted the ``line printer'' module and
allocated 8K of memory to it.  Once this is successful, do NOT run any
other mod utilities, mentioning the  lp name again.  I have it done at
boot time and forget it from then.  The only time it may be useful is if
you want another device (not a printer) hooked up to the parallel port
(this is where your printer is connected.  Right?).

> 3. lsmod >/dev/lp0
> returns: "bash: /dev/lp0: No such device"
> and I was logged in as root, too.

What you are trying to do here is to list all kernel loadable modules
and send the output of this listing to the printer.  Why?  The printer
does not work properly yet.
Also, run ls -l /dev/lp*.  See what it tells you.  It should look
something like:

crw-rw   1 root daemon 6,   0 Apr 27  1995 /dev/lp0
crw-rw   1 root daemon 6,   1 Apr 27  1995 /dev/lp1
crw-rw   1 root daemon 6,   2 Apr 27  1995 /dev/lp2

If it does not, this means that you do not have `device entries'' for
the line printer.
Do this:
cd /dev
sh ./MAKEDEV lp

if this barks, you can do
/bin/mknod /dev/lp0 c 6 0
/bin/mknod /dev/lp1 c 6 1
/bin/mknod /dev/lp2 c 6 2
/bin/chown root.daemon /dev/lp*
/bin/chmod 660 /dev/lp*

Which is really the same thing.

> 4. Additionally, I had forgotten to mention that the Print Screen
button on this
>key board works with MS-DOS, but NEVER with Debian yet. (A real pain for a
> Linux novice trying to work around this bug by copying various help and data
> screens down by HAND! Especially during installation.)

You are right in your observation that this button does not work in
Linux line M$-DOS does but wrong in your conclusions.   There is a
package (Debian or not) called gpm.  You can get it from sunsite
someplace, or tsx-11 or many others.  What it does is enable the mouse
to cut and paste on your ``tty'' screen.  If you then use, say vi, for
editing or any mail program, you can cut the text you want, start your
editor, in insert mode, and paste the text you cut.
You can even have the editor on one virtual console and the program on
another.  (You switch consoles by doing ctl-alt-f[1-7].  So 1st cosole
is ctl-alt-F1, 2nd in ctl-alt-F2, etc.
Try this in DOS :-).  This allows you to not just print the screen to a
(not yet functional printer :-) but even mail it to bozos like me.
Directly.

Linux in general, and Debian as well do not pretend to reduce a computer
to a toaster level.  Even toasters come with instructions and warnings.
Did you try recently to program a VCR?

What frustrates you is the unfamiliar teritory.  Linux is really a Unix
operating system, not a DOS extentions.  As such it is geared towards
multi-user, multi devices, great flexibility in configuration, etc.  Not
towards compatability with DOS.

Rest assured that Linux (and Debian as a distribution/packaging method)
is capable of printing on your printer.  Just be patient and count your
blessings you do not have to work/use an NT system.  Try to get a M$
engineer to give you as much time as others and myself give you. (They
charge you, ahead of time $150/hour and will NOT give you this level of
service, either).

If you need more help, please call on me. Even voice.  I'll try to help.




Simon

P.S.  Please ignore the below address and flame [EMAIL PROTECTED]
  He receives and answers mail :-)


Simon Shapiro   Bullet Technologies, Inc.
[EMAIL PROTECTED]  13130 SW Haystack St.
(503) 524-6631  Beaverton, OR 97005

Bug#2046: Missing x11perf (& xieperf)?

[Kevin Carson]

Package: xbase?
Version: 3.1.2-4

x11perf is not present in the current Debian distribution.  The prescence of
manual pages and Xmark (a script relying on the output of x11perf) suggest that
it should be.  A similiar situation exists for x11perfcomp and possibly xieperf.

Note that Xmark is present in xbase; suprising as it really is neccessary for
the X11 server.  Perhaps there should be a xperformance package?

I am using Debian 0.93R6.

--
Kevin Carson
[EMAIL PROTECTED]
Cabala Systems Corp
Burnaby, BC
Canada
(604) 294-1721

Bug#2045: smb[u]mount not suid root

[Robert Leslie]

> Where does it say they are suid safe?

>From the smbmount(8) man page:

  If  the  real  uid  of the caller is not root, smbmount
  checks whether the user is allowed to mount a  filesys-
  tem  on  the  mount-point. So it should be safe to make
  smbmount setuid root. In the filesystem, the  real  uid
  of  the  caller  is stored, so that smbumount can check
  whether the caller is allowed to unmount  the  filesys-
  tem.

Also, from the smbumount(8) man page:

   With   this   program,   normal  users  can  unmount  smb-
   filesystems, provided that it is suid root.

   smbumount has been written to give normal linux-users more
   control  over  their resources. It is safe to install this
   program suid root, because only the user who has mounted a
   filesystem is allowed to unmount it again.

   For  root it is not necessary to use smbumount. The normal
   umount program works perfectly well,  but  it  would  cer-
   tainly be problematic to make umount setuid root.

(Actually, the Debian umount is suid-safe, but won't unmount user-mounted SMB
filesystems unless run as root.)

> What is different between a user mounting a NFS and a smbfs, why should
> normal users be able to do this?

There isn't much difference; users can be allowed to mount NFS filesystems
with proper /etc/fstab entries.

An important difference, though, is that smbfs treats ownership of all files
and directories to be the same as the user who mounted the filesystem. So, it
doesn't work well to require root to mount an SMB filesystem for a user (say,
the user's home directory on an SMB server) because all the files will
effectively be owned by root.

--
Robert Leslie
[EMAIL PROTECTED]

Bug#2045: smb[u]mount not suid root

[~hiTomPrice . Andrew . Howell . at]

Where does it say they are suid safe? What is different between a user mounting
a NFS and a smbfs, why should normal users be able to do this?

My reply address is quite likely corrupt. Please mail to [EMAIL PROTECTED]
or [EMAIL PROTECTED]

Andrew


__ Reply Separator _
Subject: Bug#2045: smb[u]mount not suid root
Author:  "rob"@[EMAIL PROTECTED]@MAILGW at DECPostmaster
Date:19/12/95 9:39 AM


Package: ksmbfs
Version: 0.2.4-2

The `smbmount' and `smbumount' commands are supposed to be suid-safe so that
normal users can mount and unmount SMB filesystems.

Could the package please install these suid root, or perhaps at least query
the user to see if they should be?

If they are installed suid root, they should also probably go in /bin or
/usr/bin rather than /sbin? I'd prefer /usr/bin, but either would be fine.

Thanks.

--
Robert Leslie
[EMAIL PROTECTED]

Re: New ftp method for dselect

[David Engel]

> > I missed the first part of this thread.  Sorry.  What is the resoning
> > for this drastic change?  
> 
> Distribution file names don't parse at the moment because you can't
> disambiguate the package name from the version number. I had suggested
> that we standardize package names so that FTP scripts would work better
> and would not have to carry around a package-to-filename cross-reference.
> It's a bit more ugly, I agree.

OK, so package file names don't parse easily.  Why couldn't the cross
reference be included in the Packages file?  It's needed by dselect
anyway.  Also, what about packages like ld.so where the file name
doesn't match the package name (ldso)?  What am I missing?

David
-- 
David EngelOptical Data Systems, Inc.
[EMAIL PROTECTED]  1101 E. Arapaho Road
(214) 234-6400 Richardson, TX  75081

Re: Debian+umsdos (fwd)

[Bruce Perens]

From: Simon Shapiro <[EMAIL PROTECTED]>
> And why do we want this brain dead file system (which even M$ does not
> use for its own 1980 eras OS's) to boot a Unix O/S with?

Because it is the lowest common denominator, and it would let people
alter the bootstrap floppy from a non-Linux system before they booted it.
This is sometimes convenient. Since it's just the bootstrap floppy, we
don't have to worry about supporting it as much as we would if we
supported having the entire system on a umsdos disk. Some people are
going to try that, I guess.

Thanks

Bruce
--
Bruce Perens <[EMAIL PROTECTED]> Pixar Animation Studios

Re: New ftp method for dselect

[Bruce Perens]

From: [EMAIL PROTECTED] (David Engel)
> OK, so package file names don't parse easily.  Why couldn't the cross
> reference be included in the Packages file?  It's needed by dselect
> anyway.  Also, what about packages like ld.so where the file name
> doesn't match the package name (ldso)?  What am I missing?

The cross-reference is sufficient. It would be easier to run naive scripts
on debian packages if there were a naming standard. Under the proposed
standard, ldso would be named ld.so--1.7.11-1.deb .

Thanks

Bruce
--
Bruce Perens <[EMAIL PROTECTED]> Pixar Animation Studios

Re: New ftp method for dselect

[Jeffrey Ebert]

David Engel wrote:
> OK, so package file names don't parse easily.  Why couldn't the cross
> reference be included in the Packages file?  It's needed by dselect
> anyway.  Also, what about packages like ld.so where the file name
> doesn't match the package name (ldso)?  What am I missing?

Working towards consistent naming schemes is an excellent goal, but
there will always be the defiant package that breaks something (ldso is
a perfect example). So, an _optional_ cross-reference entry in the
Packages file would be a fine way of fixing the problem names.

I believe that several people posted regexps that covered (nearly) all
cases. Quite beyond me, really.

Here's a package that is begging to come out and break dselect:
Package: g--
priority: optional
section: devel
maintainer: S.T. Box <[EMAIL PROTECTED]>
version: 1.0.2
revision: 1
filename: debian-0.93/binary/devel/g1.0.1-1.deb
description: The GNU C++ compiler for inexpensive, set-top box designs.

Sorry, but it just came to me.

The point is that there will always be something that messes with our
naming convention.

-- 
Jeffrey Ebert  
[EMAIL PROTECTED]