ITP: screem

[Kevin Bullock]

I've packaged up a nice HTML editor for GNOME (similar in interface to
Allaire's HomeSite) called SCREEM (see http://www.screem.org/). It will
take me a little longer before it's fully baked (I deleted the debianized
source directory before I'd re-run dpkg-source -b on it, so I need to
rewrite the control file, rules script, etc.) but it'll be ready for
primetime (well, unstable at least) very soon.

I'll apply for Debian membership soon. I'm wondering -- I'd heard
something about it being a long, drawn-out process to apply for
membership -- how long will it take me? If it'll take too long, is
there someone who wants to 'proxy' for me and get in into the distro
sooner? I appreciate your help. Thanks.

--Kevin R. Bullock

[EMAIL PROTECTED] | [EMAIL PROTECTED]
[EMAIL PROTECTED]   | [EMAIL PROTECTED]

"One World, one Web, one Program" - Microsoft promotional ad 
"Ein Volk, ein Reich, ein Fuhrer" - Adolf Hitler 

Re: ITW/P: freecati

[Chris Lawrence]

On Oct 03, Craig Sanders wrote:
> On Fri, Oct 01, 1999 at 11:22:11PM -0500, Chris Lawrence wrote:
> 
> > For the unfamiliar, CATI programs are used to to conduct surveys over
> > the telephone (although they can also be used in other contexts).
> > Think of an "installation wizard" with a modem dialer and database
> > backend, and you've got the idea.  The concept here is basically to
> > make it possible to turn mothballed 486es (or eMachines ;-) into
> > interviewing stations running Linux for the cost of a network card, a
> > good USR modem and a noise-cancelling headset (i.e. well under $200).
> 
> IMO, this is morally akin to writing free software specifically to make
> spamming cheaper and easier.

No, it isn't.  Survey research is an important part of the social
sciences.  By your logic, I shouldn't write an MTA because that makes
it possible to transmit spam, or a fax program because it makes it
easier for people to spam fax machines.

> if you must write such obnoxious and evil software then please make
> sure that it maintains a list of phone numbers NOT to call, so that
> those who are sick and tired of market research jerks calling them
> just as they get home from work or sit down to dinner can say "PUT
> ME ON YOUR DO-NOT-CALL LIST IMMEDIATELY!". write the software so
> that it is trivially easy for the telemarketer to add numbers to
> that list.

1. Market research is only one use of computer assisted interviewing.
   The purpose of this project is to make it possible for a survey lab
   to be established cheaply by a university; existing solutions are
   overpriced, especially considering the fact that taxpayers tend to
   get hit with the startup costs for these things.

2. Ethical researchers do not call back people who, having been
   informed of the nature of a survey, choose not to participate.  The
   software will include this "refusal" marking capability.

3. Telemarketers and market researchers participate in a joint
   do-not-call list; they screen the number pool against that list.
   Note that non-profit concerns (educational institutions, for one)
   do not follow that list, for a variety of reasons I won't spam the
   list with.

4. Software is a tool, it is neither evil nor good.  Like any other
   technology, it is a matter of responsible use.

5. I could discriminate against certain fields of endevour in the
   license (telemarketing? what else?), but I think it's fairer (and
   DFSG-compliant) to ask that people behave responsibly and
   ethically.  In any event, I have no plans to "market" Debian as a
   "telemarketing solution"; the only thing I'd like to do is make it
   financially feasible for me to start a survey research business so
   I can raise money to pay for a survey or two in support of my
   eventual dissertation.  I have no plans to sell anything over the
   telephone, internet, or any other medium (beyond the Debian CDs I
   sell at a miniscule profit now... and all I have for them is a web
   page).

I'd be happy to discuss some of the positive aspects (or even the
negative ones) of ethical survey research with you via private mail.


Chris, who guesses he should have kept his mouth shut, made the
software proprietary, and saved everyone a world of grief.
-- 
=
| Chris Lawrence  |   Visit my home page!   |
|<[EMAIL PROTECTED]> | http://www.lordsutch.com/chris/ |
| | |
|  Political Scientist Wanna-be   |   Join the party that opposed the CDA   |
|University of Mississippi|http://www.lp.org/   |
=

Re: ITW/P: freecati

[Chris Lawrence]

On Oct 02, Chris Lawrence wrote:
> On Oct 03, Craig Sanders wrote:
> > On Fri, Oct 01, 1999 at 11:22:11PM -0500, Chris Lawrence wrote:
> > 
> > > For the unfamiliar, CATI programs are used to to conduct surveys over
> > > the telephone (although they can also be used in other contexts).
> > > Think of an "installation wizard" with a modem dialer and database
> > > backend, and you've got the idea.  The concept here is basically to
> > > make it possible to turn mothballed 486es (or eMachines ;-) into
> > > interviewing stations running Linux for the cost of a network card, a
> > > good USR modem and a noise-cancelling headset (i.e. well under $200).
> > 
> > IMO, this is morally akin to writing free software specifically to make
> > spamming cheaper and easier.

One more thing: in fairness to Craig, I didn't make my intended use of
the software all that clear in my original message.  The possibility
of its use by telemarketers wasn't exactly at the forefront of my mind
at the time I posted originally.  However, I suspect "off-the-shelf"
products would be much more suited to their use; my intended package
will probably require at least enough knowledge to install and
administer a Debian (or other Un*x)-based LAN, which is more than most
"make money fast" types are willing to pay for.

I will now shut up and code.


Chris
-- 
=
|  Chris Lawrence |   Get your Debian 2.1 CD-ROMs   |
| <[EMAIL PROTECTED]>|http://www.lordsutch.com/|
| | |
| Grad Student, Pol. Sci. |  Visit the Amiga Web Directory  |
|University of Mississippi| http://www.cucug.org/amiga.html |
=

Debian membership (with a twist)

[Yves Arrouye]

Hi,

I know this has been a topic recently, but I really wonder how long it
takes to get a membership. Is it something that can be estimated at
least? I didn't receive any reply to the email I sent to the new
maintainers alias, not even one automatic one giving an idea of the
timeframe.

Now, what is funny is that I was a member of Debian until 1997, when I
left France. If you look at the list of packages that are orphaned and
that Debian QA wants an owner for, there are two I authored, and would
get back (psptools and ppd-gs). But when? Can the fact that I was a
Debian developer once help me to make the process faster? That would be
really nice...

Thanks,
Yves.

Re: SSH never free

[Nicolás Lichtmaier]

> > > [ RSA is no longer included. ]
> > > [ IDEA is no longer included. ]
> > IDEA was the only part of ssh that made it non-free, prohibiting
> > commercial use.
> Wrong, RSA makes it non-free, and so does their license.

 Wrong, RSA makes it non-us. I can freely use RSA here.

Re: daemon configuration

[Rick]

On Sat, 2 Oct 1999, Colin Walters wrote:

> On Sat, Oct 02, 1999 at 10:49:58AM -0700, David Bristel wrote:
> > 
> > > Did you consider his point, though? Why would you install a service
> > > if you don't want it to run?

> > ones you want.  A possible solution would be a "daemon" flag to go on a 
> > package,
> > and after the install, the installed daemons are listed.  This is just an 
> > idea,
> > but that's another subject.
> 
> This is basically what Red Hat does upon installation; it prompts you for 
> which
> services to enable out of a list of installed daemons.  Perhaps upon 
> installation
> or a dist-upgrade, apt could list everything that had a "daemon" flag and 
> prompt
> you to start it.  That way we would avoid asking every time.

I'm uncertain whether this is a good idea or not.  I have helped many
people install redhat linux and, frankly, the daemon enable screen
confuses them.  They don't know what all these things are or which ones
they may need.  If this gets implemented at least have an obvious "enable
default daemons" button.

I also agree that it would be useful to allow installing daemons without
starting them.  I am fond of Roxen Challenger, but I may also want Apache
installed (on an alternate port) in case I decide to play around with it.
It would be a waste of resources to run two http daemons on my machine
when I only want to play with the second one occasionally.  Installing,
configuring, and then removing Apache every time is not satisfactory. 
Other than that I have not yet decided on the best solution for this.
Personally, I just remove the symlink from my rc directory for each daemon
I don't want started.  However, I don't know how this is affected by
package upgrades, etc, because I've just recently started using debian
(unstable).

Laters,

Rick ([EMAIL PROTECTED])
http://rick.chillin.org

"As long as you want to live, everywhere will become heaven.
Isn't that right?  Because you are still alive.
The chance to achieve happiness, you can find it anywhere."
Yui Ikari
Neon Genesis Evangelion, "The End Of Evangelion"

xplanet project - volunteers sought

[Randolph Chung]

Have you all seen the nice developers' map at
http://www.debian.org/devel/developers.loc ?

Here's your chance to help make it better!

The map is generated by xplanet. However, we have a few slight problems

1) xplanet doesn't build well on slink (well, xplanet does, but it depends
on things that are only in potato). This can be circumvented with a bit of
effort

2) more importantly though, xplanet uses imlib, which requires a X display
to run. This means that we can't generate the map easily from a
non-interactive script (like a crontab or something)

Would someone be interested/willing to look at the xplanet code and patch
together something that uses, say, libjpeg instead of imlib? Please email me
if you are willing to take this one. Thanks!

randolph
-- 
Debian Developer <[EMAIL PROTECTED]>
http://www.TauSq.org/

Re: SSH never free

[Joseph Carter]

On Sun, Oct 03, 1999 at 08:54:48AM +1000, Craig Sanders wrote:
> PS: the RSA patent expires in 2001 (or is it 2002?), anyway.

20 September 2000.

-- 
Joseph Carter <[EMAIL PROTECTED]> Debian GNU/Linux developer
GnuPG: 2048g/3F9C2A43 - 20F6 2261 F185 7A3E 79FC  44F9 8FF7 D7A3 DCF9 DAB3
PGP 2.6: 2048R/50BDA0ED - E8 D6 84 81 E3 A8 BB 77  8E E2 29 96 C9 44 5F BE
--
* Simunye is so happy she has her mothers gene's
 you better give them back before she misses them!



pgpzW2HSCz1gM.pgp
Description: PGP signature

security related mutt release

[Marco d'Itri]

There is a mutt release in incoming which should go in potato ASAP
but has been rejected because my DSA key is not in the keyring (I don't
know why, I sent it...).
Please someone add the key (www.linux.it/~md/md-gpg.asc) and move back
the .changes or either do a NMU with the source and the diff in incoming.
In the next days I will have no mail and no net access.

-- 
ciao,
Marco

Re: ITP: screem

[Frederic CELLA]

already package by Mickael Dorman and it's in INCOMING.


bst regards.
Frederic.

Re: Debian membership (with a twist)

[Raphael Hertzog]

Le Sun, Oct 03, 1999 at 04:46:25AM +, Yves Arrouye écrivait:
> Now, what is funny is that I was a member of Debian until 1997, when I
> left France. If you look at the list of packages that are orphaned and
> that Debian QA wants an owner for, there are two I authored, and would
> get back (psptools and ppd-gs). But when? Can the fact that I was a
> Debian developer once help me to make the process faster? That would be
> really nice...

Did you explain this to new-maintainer ? Do you still have your old PGP
key ?

With the way new maintainer is handled currently, you will have to wait
many monthes before getting approved. :-(

BTW, do you really think that psptools is still of any use with today's
tools ?

Cheers,
-- 
Raphaël Hertzog -=- http://tux.u-strasbg.fr/~raphael/
 CDs Debian : http://tux.u-strasbg.fr/~raphael/debian/#cd 

RE: Packages should not Conflict on the basis of duplicate functionality

[Terry Katz]

Why not implement a system similar to that in Irix ( and a few other sysv
style systems ), and use a 'chkconfig' type setup..

Irix implements it with a config directory (/etc/config), which contains
files with the same name as the init script or app, and contains a single
word .. 'on' or 'off' ..

so, you can issue:

chkconfig postgresql on
/etc/init.d/postgresql start
chkconfig postgresql off

The modifications to add this to the distribution shouldn't be that
difficult .. the chkconfig (or whatever you want to call it) script can be
used to both test for and set the options..

chkconfig [ [on/off]] .. leave off the last parameter to check for the
status inside an init.d script and start based on that .. (leave off second
parameter to see a complete list of whats on/off)

The initial change to add this to the init scripts could take a while
(although its simple to just add it to the beginning of the init scripts,
and just exit if the config is off), but once its implemented it would be a
nice tool.. no?  (every now and again it would be nice to be able to
chkconfig gdm off, and/or chkconfig network off, etc...)

this is a li'l longer implementation (to get started) than changing
start->go, and if you change it just locally then whenever a package is
upgraded you'll have to add the check line to the beginning of the init
scripts .. but long term, this may be a nice feature for debian in general
.. no?

my 2c

-Terry Katz

> -Original Message-
> From: Craig Sanders [mailto:[EMAIL PROTECTED]
> Sent: Saturday, October 02, 1999 6:31 PM
> To: Piotr Roszatycki
> Cc: Debian Development Mailing List
> Subject: Re: Packages should not Conflict on the basis of duplicate
> functionality
>
>
> On Sat, Oct 02, 1999 at 04:36:04PM +0200, Piotr Roszatycki wrote:
>
> > I've install postgresql on my home computer. I need this daemon only
> > sometimes. I don't want to start it every time I reboot system.
>
> you need to do something non-standard, so you should do a little bit of
> work to accommodate your own needs.
>
> if i needed to do the above then i would edit /etc/init.d/postgresql and
> (in the case statement) change "start)" to "go)". this way, it would
> not get started at boot time, but i could easily start it by running
> "/etc/init.d/postgresql go".
>
>
> pros:
>
> simple. takes <20 seconds with vi. minimal change, so follows principle
> of least surprise. easy to remember. init.d scripts are conffiles so it
> won't be automatically replaced at the next upgrade.
>
> cons:
>
> you have to re-do the change if you ever upgrade and answer "Y" to
> dpkg's question about replacing /etc/init.d/postgresql.
>
> craig
>
> --
> craig sanders
>
>
> --
> To UNSUBSCRIBE, email to [EMAIL PROTECTED]
> with a subject of "unsubscribe". Trouble? Contact
> [EMAIL PROTECTED]
>

Re: daemon configuration

[Michael Stone]

On Sun, Oct 03, 1999 at 02:59:38AM -0400, Rick wrote:
> I'm uncertain whether this is a good idea or not.  I have helped many
> people install redhat linux and, frankly, the daemon enable screen
> confuses them.  They don't know what all these things are or which ones
> they may need.  If this gets implemented at least have an obvious "enable
> default daemons" button.

Think about this for a second. Why do we want to make it easy for people
to enable remote access to their system if they're unaware of what that
means?

Mike Stone


pgpAfcJg1rOZr.pgp
Description: PGP signature

Re: Packages should not Conflict on the basis of duplicate functionality

[Martin Bialasinski]

* "Terry" == Terry Katz <[EMAIL PROTECTED]> wrote:

Terry> so, you can issue:

Terry> chkconfig postgresql on
Terry> /etc/init.d/postgresql start
Terry> chkconfig postgresql off

I don't know if I understand you correctly, but does this mean, that
the question whether a init.d script would start the daemon is
dependent on the status of this chkconfig thing?

This is a way bad idea.

This means, that during startup, not only the rcX.d links (or the
filerc equivalent) determines what gets started, but also another
config. 

This also means, that when I explicitly call "/etc/init.d/postgresql
start" to start the daemon, the result still depends on another config 
setting.

The result is a unnecessary "AND" style switch.

If this is how Irix handles this, then I am glad I don't have to use
it.

Ciao,
Martin

Re: BTS: How are the bug reports organized?

[Raul Miller]

On Fri, Oct 01, 1999 at 07:36:28PM -0600, Jason Gunthorpe wrote:
> Consider if we have bugs 0->199 and you take the first digit. You end up
> with 10 bugs in each bucket except bucket '1' which has 110. Put that on a
> broader scale and account for expired bugs and you see the trouble.

Why not base the BTS directory structure on the perl phrase:

(join "/", map {() unless $_} split /(...)/}).".html"

?

Or, if you just want directory names:

join "/", /(...)/g

Or maybe use (..) instead (since 200 directory entries allows for finer
grained cache management than 2000).

-- 
Raul

Re: Debian recommended software

[Alexander Koch]

On Sat, 2 October 1999 15:13:12 +0200, Martin Bialasinski wrote:
> exim has its own filter facility, that is easier to understand and use 
> by new users.

Yep.
And what is needed by procmail is the following:

Transport-wise:

|local_delivery:
|  driver = pipe
|  command="/usr/bin/procmail"
|  umask=0022

(This can be enhanced with a "required_files = ~/:~/.procmailrc" or
 any such things (needing the procmail binary itself, the other
 transport (the old local_delivery) can still be in there)

And the localuser director should be enhanced (take two of
them, one running for procmail, the other after that running
for normal delivery).

-- Mark, do you think it is possible to add "procmail support"
to exim? Should not be much of a problem.

> Edward> list server: smartlist
> Edward> Needs modifications to exim.conf found on the www.exim.org homepage to
> Edward> function well.
> 
> I use smartlist myself, but I heard others (like mailman) are
> better. The Exim list uses mailman IIRC.

Yep. There is a nice mail from Nigel on setting up mailman,
should be available in the exim-users lists archive.

Alexander

-- 
Alexander Koch - <>< - WWJD - aka Efraim - PGP 0xE7694969 - ARGH-RIPE

Debian recommended software

[Matthias Klose]

Edward Betts writes:
 > It is the same for other things like list server. I used berolist to start
 > with, and it is terrible. Then I tried smartlist, and it was great. The
 > problem is there are so many to look at.

don't know the two, mailman is another (for the user easy to use) alternative.

 > software we all recommend, because we are all individuals and would
 > disagree, but here is my list:

 > MUA: mutt
 > This is not the default, the only two mail clients with standard priority are
 > mailx and elm++, do we recommend people run them?

mailx is the smallest MUA, so it does not hurd if it's standard
together with another MUA.

 > MDA: procmail
 > This is standard priority, but exim is not configured to use it, people have
 > to mess with .forward files.

procmail is used by many users, because they can install it on their
own and do not have to rely on a specific MTA and the documentation is 
far better for procmail than for exim's MDA features.

 > web server: apache

apache is somewhat standard; an alternative to recommend could be roxen:
- well documented administration interface
- integrated optional ftp server module
- integrated optional proxy server module (no need for squid anymore)

Re: bash package removing /bin/sh on upgrade

[Raul Miller]

On Fri, Oct 01, 1999 at 08:36:01AM -0400, Ivan E. Moore II wrote:
> > > yea...I just did an update today and something decided to remove
> > > /bin/sh during the upgrade...and didn't put it back before it
> > > was needed... so if something hoses for you just recreate it by
> > > linking it to like bash...

> On Fri, Oct 01, 1999 at 03:00:51PM +0200, Torsten Landschoff wrote:
> > If somebody could come up with a better method of handling this it
> > would be most welcome.

On Sat, Oct 02, 1999 at 12:30:04PM +1000, Anthony Towns wrote:
> Just having /bin/sh included in the .deb is Good Enough -- diversions
> work as designed.

Good Enough is not good enough (TM).

> There's a different preinst in one of the bug reports, ummm, #34717 I
> think, that does the diversion stuff itself, too.

That uses --rename, which is A Very Bad Thing in this case.

A wonderfuly horrible hack has occurred to me, by the way:  A cron job
which runs every minute: /bin/sh -c exit || /sbin/rebuild-bin-sh

rebuild-bin-sh would take a configuration file in /etc to determine
preference order for building the link (and fall back to some arbitrary
order if all those fail), test each to find one that works then recreate
the /bin/sh link.

I'm tempted to say that rebuild-bin-sh should be statically linked (and
use _exit() and not use anything related to printf()) to deal with cases
where /bin/sh has died because of a library upgrade and there happens
to be a suitable shell hanging around that uses a different library.

[I'm willing to write such a thing if it seems like a good idea for
longer than a few hours.]

[Of course rebuild-bin-sh should be run manually after the config file
is changed, for a smooth upgrade of the link.  You don't really need
the cron job -- it's a remedy for a situation that should never happen.
and it's a remedy that may not have any use should that situation arise.]

If such a thing is written, and deployed, it would be nice to integrate
support for it into all posix shell.  [Not for potato -- this is too
critical of an app, in my opinion.]

-- 
Raul

Re: bash package removing /bin/sh on upgrade

[Anthony Towns]

On Sun, Oct 03, 1999 at 09:44:25AM -0400, Raul Miller wrote:
> On Sat, Oct 02, 1999 at 12:30:04PM +1000, Anthony Towns wrote:
> > Just having /bin/sh included in the .deb is Good Enough -- diversions
> > work as designed.
> Good Enough is not good enough (TM).

*shrug* Name a case where it fails.

> > There's a different preinst in one of the bug reports, ummm, #34717 I
> > think, that does the diversion stuff itself, too.
> That uses --rename, which is A Very Bad Thing in this case.

Whyso?

Cheers,
aj

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

 ``The thing is: trying to be too generic is EVIL. It's stupid, it 
results in slower code, and it results in more bugs.''
-- Linus Torvalds


pgpLotLOHsqXR.pgp
Description: PGP signature

Re: slink -> potato

[Raul Miller]

On Sun, Oct 03, 1999 at 08:56:23AM +1000, Herbert Xu wrote:
> The idea is that when you upgrade the package like telnetd, there
> may be new shlib dependencies, etc. which means that you should stop
> spawning new daemons until it is configured. Of course, this may
> not happen for every release, but the prerm file comes from the old
> version, so it can't tell whether this is necessary, but it is the
> only one that knows exactly how to stop the daemon from spawning, so
> it just has to stop it every time.

Note that there can be an extended period between unpack and configure.
Especially if there's a package that needs a prompt answered that hits
in this interval.  [Imagine that you're running dpkg under screen and
a network outage drops your connection.]

As far as I know, leaving inetd accepting connections would, worst case,
fail -- which is no different from having the service disabled.  In other
words, I don't see that disabling the daemon solves anything useful.

[Aside: I never become root over a non-encrypted session, except in very
unusual circumstances -- and even there I try to minimize the number
unencrypted ip hops, but that's a different issue.]

-- 
Raul

Re: Debian recommended software

[Edward Betts]

Alexander Koch <[EMAIL PROTECTED]> wrote:
> Transport-wise:
> 
> |local_delivery:
> |  driver = pipe
> |  command="/usr/bin/procmail"
> |  umask=0022
> 
> (This can be enhanced with a "required_files = ~/:~/.procmailrc" or
>  any such things (needing the procmail binary itself, the other
>  transport (the old local_delivery) can still be in there)

Does this check whether the procmail executable exists on every mail delivery?
is that going to slow the whole thing down a bit. Otherwise I think this is a
good idea.

Another possiblity would be to stick the check in the exim config script,

Would you like to use procmail are your MTA [n/Y]?

You could check if it the procmail executable is installed, but exim might be
configured before procmail is installed.

-- 
I consume, therefore I am

Suggestion: binfmt_misc handling

[Daniel Burrows]

  Hello,

  I was just poking around on my system and found a script I wrote back when
kernel 2.2 was released.  It was an experiment to see if I could easily handle
registration and deregistration of binary formats (with binfmt_misc) -- it
just occured to me that Debian might be interested in it, so here it is.

  Basically what you can do is create a directory called /etc/binfmt_misc and
put a bunch of files in it; each file should be a series of lines where each
line is a directive for the binfmt_misc registration file in /proc.  So the
incantation for Java is:
:Java:M::\xca\xfe\xba\xbe::/usr/bin/javawrapper:
  (assuming that /usr/bin/javawrapper does something sensible), and for JPEG
(yes, this is a really dumb usage of binfmt_misc, but it's the only other
 magic number I could come up with offhand):

:JPEG:M::0xffd8::/usr/X11R6/bin/display:
:JPEG-JFIF:M::JFIF::/usr/X11R6/bin/display:
:JPEG-HSI:M::hsi1::/usr/X11R6/bin/display:

  Comments are also supported (by beginning a line with '#')

  Packages such as Wine, Kaffe, dosemu, and perhaps Frotz would drop a file
into this directory announcing their support of a binary format.  The files
wouldn't actually be interpreted unless this init.d script is installed; I
assume that someone is going to claim this is a security hazard, so I thought
I'd point that out :P

[ as I understand it, a security 'breach' could only occur with this system if a
 user had execute permissions but *not* read permissions on a file that wasn't
 of a normal executable format; in other words:
rwx--x--x /usr/bin/haha-you-cant-run-me.exe
  or if the user normally didn't have permissions to run the interpreter but had
 enough permissions to execute files of that type.  Both of these seem to me to
 be unusual cases, but who knows? :) ]

  The config file format could probably be made more sensible, but on the other
hand not many packages really need this and this format isn't *too* obscure..

  The init file is attached; it would be cool if a Real Developer[tm] could
stick it in a package.  I think this is a fairly useful bit of infrastructure.

  Daniel

-- 
  "Cogito, ergo sum."

  -- Descartes
#!/bin/sh
# Register various binary types

test -e /proc/sys/fs/binfmt_misc || exit 0

register_format() {
while read -r FORMAT
do
  echo "$FORMAT" > /proc/sys/fs/binfmt_misc/register
done
}

case "$1" in
start)  echo -n "Registering binary formats: "
for i in `find /etc/binfmt_misc/ -mindepth 1 -maxdepth 1 -not -name \*~`
do
  echo -n `basename $i`
  sed '/#.*/d' $i | register_format
  echo -n ". "
done
echo ""
;;
stop)   echo -n "Disabling binary format recognition: "
echo -1 > /proc/sys/fs/binfmt_misc/status
echo "."
;;
restart) $0 stop
 $0 start
;;
*)  echo "Usage: /etc/init.d/binfmt_misc start|stop|restart"; exit 1 
;;
esac
exit 0

Re: bash package removing /bin/sh on upgrade

[Daniel Burrows]

On Sun, Oct 03, 1999 at 09:44:25AM -0400, Raul Miller was heard to say:
> A wonderfuly horrible hack has occurred to me, by the way:  A cron job
> which runs every minute: /bin/sh -c exit || /sbin/rebuild-bin-sh

  Hmm.  There's a bit of a problem here: aren't cronjobs executed
with /bin/sh? :)

  (although a general way to regenerate a broken shell is nice..)

  Daniel

-- 
  "I've struggled with reality for thirty-five years, but I'm glad to say that
   I finally won."
 -- _Harvey_

Re: Suggestion: binfmt_misc handling

[Daniel Burrows]

  Oops.

On Sun, Oct 03, 1999 at 10:06:02AM -0400, Daniel Burrows was heard to say:
> test -e /proc/sys/fs/binfmt_misc || exit 0

  That maybe should be test -d ...  (although the above works even on ash)

  Daniel

-- 
  Genius may have its limitations, but stupidity is not thus handicapped.

  -- Elbart Hubbard

Re: daemon configuration

[Raul Miller]

On Sun, Oct 03, 1999 at 02:59:38AM -0400, Rick wrote:
> I'm uncertain whether this is a good idea or not.  I have helped many
> people install redhat linux and, frankly, the daemon enable screen
> confuses them.  They don't know what all these things are or which ones
> they may need.  If this gets implemented at least have an obvious "enable
> default daemons" button.

Agreed, this is a problem with Red Hat's implementation.

We should ask the user what kind of policy they want to have for network
services.  We should inform them that there's a small risk that remote
users may compromise their machine if they enable network services,
but that in some situations the machine would be worthless without such
services.  We should present a couple examples (http, remote login),
present the basic options (no network services on by default, most
network services on by default, choose on a service by service basis),
and we should give them a command to use after the install is complete
that lets them see what network services are in use and what package
is responsible for them, and a reference to how to find documentation
in the variety of formats a package could supply it in (man, info,
/usr/{,share}/doc, --help or -h, documentation embedded in configuration
files, or for the really desperate: documentation embedded in programs)

I'm not sure whether is such a reference about documentation.

I'm sure there's no such reference about associating packages with
network sockets.  It would be possible to write such a thing, based on
lsof -F -i -n, but maybe it's better to teach everyone how to use lsof
(run lsof as root, teach about the +M option, egrep for '(UDP).*(LISTEN|\*)'),
use dpkg -S to find package associated with a program.

-- 
Raul

Re: bash package removing /bin/sh on upgrade

[Raul Miller]

On Sun, Oct 03, 1999 at 10:07:03AM -0400, Daniel Burrows wrote:
> On Sun, Oct 03, 1999 at 09:44:25AM -0400, Raul Miller was heard to say:
> > A wonderfuly horrible hack has occurred to me, by the way:  A cron job
> > which runs every minute: /bin/sh -c exit || /sbin/rebuild-bin-sh
> 
>   Hmm.  There's a bit of a problem here: aren't cronjobs executed
> with /bin/sh? :)

Ok, so that part is completely bogus :)

-- 
Raul

Re: How not to be a nice person (Was: Re: Packages should not Conflict on the basis of duplicate functionality)

[Raul Miller]

On Sat, Oct 02, 1999 at 08:06:10PM +1000, Craig Sanders wrote:
> i show no regard for those who demonstrate they are fools. i show
> contempt for those who demonstrate that they are annoying fools. guess
> which category you fall into.

Ok, try this on for size:

How many network services do you get if you are doing if you decide to
install cfs?

How many if you decide to install crossfire-sounds?

[Aside: obviously there's a difference between not accepting a connection
and accepting a connection then dropping it.  Very occasionally this
makes a difference from a security standpoint.]

[Aside: I know that if you install packages one at a time, using apt,
and if you read each package description, and sit back and read the
package docs after installing it, that you'll not have any problems with
unwanted network services cropping up.  But: is this how you use debian?]

-- 
Raul

Re: How not to be a nice person (Was: Re: Packages should not Conflict on the basis of duplicate functionality)

[Raul Miller]

On Sat, Oct 02, 1999 at 03:53:43PM +1000, Anthony Towns wrote:
> In any case, I fail to see how pressing `_' in dselect before any
> unnecessary daemons are installed could possibly be less secure than
> saying "No, I don't want services activated by default" and then
> installing them anyway.

How long are you suggesting a person study their initial configuration
in deselect before installing any packages?

--
Raul

Re: bash package removing /bin/sh on upgrade

[Raul Miller]

On Sun, Oct 03, 1999 at 09:44:25AM -0400, Raul Miller wrote:
> > On Sat, Oct 02, 1999 at 12:30:04PM +1000, Anthony Towns wrote:
> > > Just having /bin/sh included in the .deb is Good Enough -- diversions
> > > work as designed.
> > Good Enough is not good enough (TM).

On Sun, Oct 03, 1999 at 11:55:54PM +1000, Anthony Towns wrote:
> *shrug* Name a case where it fails.

You don't remember the problems when libreadline broke?



Or, to address your implicit question rather than your explicit question:

Bash is an order of magnitude more complex than what's needed for
/bin/sh -- this results in efficiency problems and results in a number
of potential reliability problems.

-- 
Raul

Re: Suggestion: binfmt_misc handling

[Raul Miller]

On Sun, Oct 03, 1999 at 10:06:02AM -0400, Daniel Burrows wrote:
> [ as I understand it, a security 'breach' could only occur with this
> system if a user had execute permissions but *not* read permissions
> on a file that wasn't of a normal executable format; in other words:
> rwx--x--x /usr/bin/haha-you-cant-run-me.exe or if the user normally
> didn't have permissions to run the interpreter but had enough
> permissions to execute files of that type. Both of these seem to me to
> be unusual cases, but who knows? :) ]

Or if the interpreter was setuid or setgid.

-- 
Raul

Re: Debian recommended software

[Hamish Moffatt]

On Sun, Oct 03, 1999 at 01:00:44PM +0200, Matthias Klose wrote:
> procmail is used by many users, because they can install it on their
> own and do not have to rely on a specific MTA and the documentation is 
> far better for procmail than for exim's MDA features.

Really? I find the exim filter specification to be very good.
My one-word assessment of procmail is "hideous". The exim spec
is written in plain text.


Hamish
-- 
Hamish Moffatt VK3SB (ex-VK3TYD). 
CCs of replies from mailing lists are welcome.

Re: bash package removing /bin/sh on upgrade

[Anthony Towns]

On Sun, Oct 03, 1999 at 11:28:31AM -0400, Raul Miller wrote:
> On Sun, Oct 03, 1999 at 11:55:54PM +1000, Anthony Towns wrote:
> > *shrug* Name a case where it fails.
> You don't remember the problems when libreadline broke?

Yes, I do. That's not related to bash, it's related to having bash
implicitly pre-depending on itself (its preinst was a /bin/sh script),
and apt uninstalling it on upgrade.

(That's what the C preinsts I posted were all about in the first place)

(What is the problem with --rename, btw? I'm curious, and dpkg-divert is
horribly underdocumented)

> Or, to address your implicit question rather than your explicit question:
> Bash is an order of magnitude more complex than what's needed for
> /bin/sh -- this results in efficiency problems and results in a number
> of potential reliability problems.

Indeed. Against these risks (which we and just about every other Linux
distribution have lived with reasonably happily for how long?) you'd
need to balance changing to something which we've barely tested at all.

Cheers,
aj

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

 ``The thing is: trying to be too generic is EVIL. It's stupid, it 
results in slower code, and it results in more bugs.''
-- Linus Torvalds


pgpbqlwK4K4xR.pgp
Description: PGP signature

Re: Debian membership (with a twist)

[Yves Arrouye]

> Did you explain this to new-maintainer ? Do you still have your old PGP
> key ?

I did explain that. Since nobody answered, I have no idea if it's been
received (except for my mail not bouncing, that is). I don't have my old
PGP key. In fact, if you look at the keyservers, you'll see that I've
not been good at that (can you say inexperience on the subject?). I now
have a GNU PG key and a physical copy of it, so I shouldn't have to
change keys again I hope...

> With the way new maintainer is handled currently, you will have to wait
> many monthes before getting approved. :-(

So what can I do? Until a few months ago, I could see an
[EMAIL PROTECTED] and had hopes to at least be able to upload to
master. But it's gone.

Can one of the maintainers approvers reply privately to this email and
tell me how I can speedup the process (it took a few days in 1996 :-))?
I will call him/her, that's no problem. Thanks!

Debian has some big advantages over any other distribution I know of
that make me want to contribute to Debian rather than another one. But
months for getting a membership, isn't that risking that new volunteers
will turn to Mandrake or Stampede for example, and work to put the nice
things that Debian has (best package management, all the tools to manage
alternatives / rc / cron / MIME / etc.) in them? I would even think that
to some extent, one can say that any Debian member should be able to
approve another candidate. After all, if you passed the test, you should
have a good understanding of what it means to be a Debian member. If so,
you should be able to approve another one. If not, then whoever approved
you shouldn't have. No? [This is why debian-policy is CC:ed now.] If any
member can approve a new member, then processing new maintainers should
be really fast, and Debian won't loose great people that want to
volunteer. You can even track who approved whom and prevent people w/
bad judgment to approve other ones, etc... I am sure there are ways to
move the approval time from months to days.

> BTW, do you really think that psptools is still of any use with today's
> tools ?

It provides the only way I know to simply take advantage of printer's
capacities like stapling, binding etc. PPD files are really good for
that. I would definitely consider writing a printing panel for KDE or
Gnome that handle PPD files just for this.

Yves.

Re: Suggestion: binfmt_misc handling

[Daniel Burrows]

On Sun, Oct 03, 1999 at 11:30:04AM -0400, Raul Miller was heard to say:
> On Sun, Oct 03, 1999 at 10:06:02AM -0400, Daniel Burrows wrote:
> > [ as I understand it, a security 'breach' could only occur with this
> > system if a user had execute permissions but *not* read permissions
> > on a file that wasn't of a normal executable format; in other words:
> > rwx--x--x /usr/bin/haha-you-cant-run-me.exe or if the user normally
> > didn't have permissions to run the interpreter but had enough
> > permissions to execute files of that type. Both of these seem to me to
> > be unusual cases, but who knows? :) ]
> 
> Or if the interpreter was setuid or setgid.

  Unless I'm entirely confused, this is only an issue if the user can't run
the interpreter without going through binfmt_misc (ie, they have no execute
priviliges on it) -- otherwise they could just type
'/usr/bin/setuid_interpreter evil-nasty-program'

  Daniel

-- 
Whoever fights monsters should see to it that in the process he does not
become a monster.  And when you look into an abyss, the abyss also looks
into you.
-- Friedrich Nietzsche

Re: SSH never free

[Bob Nielsen]

On Sat, Oct 02, 1999 at 11:57:07PM -0700, Joseph Carter wrote:
> On Sun, Oct 03, 1999 at 08:54:48AM +1000, Craig Sanders wrote:
> > PS: the RSA patent expires in 2001 (or is it 2002?), anyway.
> 
> 20 September 2000.

Does anyone know when the LZW patent expires?


-- 
Bob Nielsen Internet: [EMAIL PROTECTED]
Tucson, AZ  AMPRnet:  [EMAIL PROTECTED]
DM42nh  http://www.primenet.com/~nielsen

Re: Debian membership (with a twist)

[Stephen R. Gore]

Yves Arrouye wrote:

> be really fast, and Debian won't loose great people that want to
> volunteer. You can even track who approved whom and prevent people w/
> bad judgment to approve other ones, etc... I am sure there are ways to
> move the approval time from months to days.

---end quoted text---

AFAICT from hints dropped on the list, and corresponding with current
maintainers, slowing down the approval time is the point.  Seems the
feeling is 'Debian has too many maintainers and too many packages'.

This may be correct.  I can't judge.  But it seems to me that if some-
one volunteers time and effort to the project, common courtesy demands
/at least/ an autoreply acknowledging the the application.  An explana-
tion of the current situation would be nice also.

Just my 2 cents.

-- 
Regards,
Steve

Debian GNU/Linux Because software support is free, timely,
 useful, technically accurate, and friendly.
 Reboots are for kernel and hardware upgrades.

Re: ITP: screem

[Kevin Bullock]

On Sun, 3 Oct 1999, Frederic CELLA wrote:
> already package by Mickael Dorman and it's in INCOMING
So it is. Thanks. I did contact the author, but hadn't received a reply
yet.

Perhaps the New Maintainers' Guide Sec. 2.1 should be changed to read
"check in Incoming and maybe ask in #debian before you put in all the work
to package it up" ;)

screem hasn't yet shown up on WNPP.

I'd still like to become a Debian member though -- is there someone near
Minneapolis/St. Paul that could verify my key etc.?

Note: please send all replies to the list. I am subscribed.

--Kevin R. Bullock

[EMAIL PROTECTED] | [EMAIL PROTECTED]
[EMAIL PROTECTED]   | [EMAIL PROTECTED]

"One World, one Web, one Program" - Microsoft promotional ad 
"Ein Volk, ein Reich, ein Fuhrer" - Adolf Hitler 

Re: daemon configuration

[Rick]

On Sun, 3 Oct 1999, Michael Stone wrote:

> On Sun, Oct 03, 1999 at 02:59:38AM -0400, Rick wrote:
> > I'm uncertain whether this is a good idea or not.  I have helped many
> > people install redhat linux and, frankly, the daemon enable screen
> > confuses them.  They don't know what all these things are or which ones
> > they may need.  If this gets implemented at least have an obvious "enable
> > default daemons" button.
> 
> Think about this for a second. Why do we want to make it easy for people
> to enable remote access to their system if they're unaware of what that
> means?

I agree with you, that was just an example.  It could just as easily be a
"disable all daemons" or perhaps "disable all network daemons".

Laters,

Rick ([EMAIL PROTECTED])
http://rick.chillin.org

Re: corel linux demo

[Anderson MacKay]

Ech, I'm a bit behind on my -devel reading.  I hope this question hasn't
been answered down in another thread. :)

On Thu, Sep 30, 1999 at 06:49:15AM -0700, Kenneth Scharf wrote:
> I understood wine as being a library that intercepted
> win32 calls and redirected those calls into the
> correct X or linux libraries for handling.  Corel
> intends (as I understand it) to ship the actual
> windows binaries (.exes) and maybe even .dll's with
> whatever wrappers are required to run them under Wine.

Wine is two things: it's a library for linking Win32-source programs
under most *nixes, and it's a call interceptor for ABI compatibility
under x86-based *nixes.  The plan (as outlined by Corel on the Wine
mailing list so long ago :) was to use Winelib to ease porting the Win32
sources of Draw, WordPerfect, Quattro, and Paradox (maybe others...).
The guy in charge of it all on the Corel end is Gavriel State, who is the
same fellow who headed up the port of CorelDraw! to the Mac ... they
apparently did something similar to Wine and wrote a source-translation
library for that port as well.  Anyway, I'm pretty sure the shipped
applications will be native Linux applications, although they'll be
dynamically linked to Winelib ... very little difference from how gtk+
applications link to libgtk, etc.

>  There will probably even be a Wine based program
> launcher that will trigger of an icon for the
> installed program on the desktop or 'K bar'.  Wine's
> ultimate result is to make the win32 API become a
> linux api as well.  It would stand beside gtk++ and QT
> in that regard.  Also means that the "setup.exe"

Exactly ... but I think you're confusing the issue a bit by bringing
native Windows .exe files into the equation.  Were I Corel (and I'm not,
obviously :), I would ship native Linux binaries ... the issues involved
are so much less complicated in that case.  It's pretty difficult to do
QA in a binary-emulation environment, if you ask me.  Consider that few
effective debugging tools are going to work at all, as an example.  Wine
includes a debugger, yes, but the purpose of that debugger is to debug
Wine ... and it doesn't do convenient things like talk to Emacs, talk to
ddd, etc.  Source-compatibility will be much less of a hassle.

Just as a status report -- I don't know the current status, but I do know
that back in mid-spring of this year, Corel (well, Gav State, actually)
claimed to have Quattro Pro running with very few glitches when compiled
against Winelib.  I'm sure they've come a long way since then, so expect
to see good things.

-- 
Anderson MacKay <[EMAIL PROTECTED]>

Re: Debian membership (with a twist)

[Steve Willer]

On Sun, 3 Oct 1999, Yves Arrouye wrote:

> Debian has some big advantages over any other distribution I know of
> that make me want to contribute to Debian rather than another one. But
> months for getting a membership, isn't that risking that new volunteers
> will turn to Mandrake or Stampede for example, and work to put the nice
> things that Debian has (best package management, all the tools to manage
> alternatives / rc / cron / MIME / etc.) in them?

Yes, this is exactly the problem, and it's a big reason why I installed
FreeBSD over Debian last night. I had hoped that the new school year would
bring some energy to this project, but it's still the same old bickering,
the same lack of forward movement, and new-maintainers still hasn't
bothered to respond to my application (sent about 6 months ago).

FreeBSD looks pretty good so far. Too bad it messes up /usr/local, but I
can probably get used to that and put my own binaries somewhere else.

RE: Packages should not Conflict on the basis of duplicate functionality

[Rick]

On Sun, 3 Oct 1999, Terry Katz wrote:

> Why not implement a system similar to that in Irix ( and a few other sysv
> style systems ), and use a 'chkconfig' type setup..
> 
> Irix implements it with a config directory (/etc/config), which contains
> files with the same name as the init script or app, and contains a single
> word .. 'on' or 'off' ..
> 
> so, you can issue:
> 
> chkconfig postgresql on
> /etc/init.d/postgresql start
> chkconfig postgresql off

This is possibly a good idea.  However, if you're gonna be doing this, why
not just remove the symlink from /etc/rc2.d?  When you want the daemon
back recreate the symlink.  I'm under the impression that package updates
would recreate this link, so maybe that wouldn't work very well.

> The modifications to add this to the distribution shouldn't be that
> difficult .. the chkconfig (or whatever you want to call it) script can be
> used to both test for and set the options..
> 
> chkconfig [ [on/off]] .. leave off the last parameter to check for the
> status inside an init.d script and start based on that .. (leave off second
> parameter to see a complete list of whats on/off)
> 
> The initial change to add this to the init scripts could take a while
> (although its simple to just add it to the beginning of the init scripts,
> and just exit if the config is off), but once its implemented it would be a
> nice tool.. no?  (every now and again it would be nice to be able to
> chkconfig gdm off, and/or chkconfig network off, etc...)

How is "chkconfig network off" any better/easier than "/etc/init.d/network
stop" (aside from the fact it won't get restarted when you reboot)?  I 
thought that's what different runlevels were for, having different daemons
started when you boot.  Maybe I'm just thinking that mucking with
/etc/rcS.d/ as easy enough, but I suppose a chkconfig would be easier for
those less familiar with the init system.

I don't like the idea of adding this check to each init script.  Wouldn't
it be better to add this check to /etc/init.d/rcS when it goes through the
/etc/rcS.d/S??* scripts (since the chkconfig parameter has the same name
as the init script minus the S??)?

Laters,

Rick ([EMAIL PROTECTED])
http://rick.chillin.org

"As long as you want to live, everywhere will become heaven.
Isn't that right?  Because you are still alive.
The chance to achieve happiness, you can find it anywhere."
Yui Ikari
Neon Genesis Evangelion, "The End Of Evangelion"

RE: Packages should not Conflict on the basis of duplicate functionality

[Terry Katz]

Looking back on it .. I guess the chkconfig idea wasn't as good as I was
originally thinking .. Irix has been the main OS at my company until
recently when I started moving the apps over to high end Linux boxes, and
have gotten used to the chkconfig setup .. (which serves more purposes than
just preventing daemons from starting .. its also used for tracing and
debugging .. ie, you can have a trace/debug log created whenever you boot,
and also use it to prevent the scripts from display a lot of info (ie, make
them quiet) .. I got used to the idea of 'chkconfig trace on' rebooting, and
using that to debug startup failures, etc... 'checkconfig autoconfig on' to
tell it to use dhcp, etc.. it just made it a bit easier than editing the
config scripts and placing exit's in them, and then removing them later ..
or removing links, and then recreating, etc...)

So, I withdraw my suggestion ;-)

-Terry

> On Sun, 3 Oct 1999, Terry Katz wrote:
>
> > Why not implement a system similar to that in Irix ( and a few
> other sysv
> > style systems ), and use a 'chkconfig' type setup..
> >
> > Irix implements it with a config directory (/etc/config), which contains
> > files with the same name as the init script or app, and
> contains a single
> > word .. 'on' or 'off' ..
> >
> > so, you can issue:
> >
> > chkconfig postgresql on
> > /etc/init.d/postgresql start
> > chkconfig postgresql off
>
> This is possibly a good idea.  However, if you're gonna be doing this, why
> not just remove the symlink from /etc/rc2.d?  When you want the daemon
> back recreate the symlink.  I'm under the impression that package updates
> would recreate this link, so maybe that wouldn't work very well.
>
> > The modifications to add this to the distribution shouldn't be that
> > difficult .. the chkconfig (or whatever you want to call it)
> script can be
> > used to both test for and set the options..
> >
> > chkconfig [ [on/off]] .. leave off the last parameter to
> check for the
> > status inside an init.d script and start based on that ..
> (leave off second
> > parameter to see a complete list of whats on/off)
> >
> > The initial change to add this to the init scripts could take a while
> > (although its simple to just add it to the beginning of the
> init scripts,
> > and just exit if the config is off), but once its implemented
> it would be a
> > nice tool.. no?  (every now and again it would be nice to be able to
> > chkconfig gdm off, and/or chkconfig network off, etc...)
>
> How is "chkconfig network off" any better/easier than "/etc/init.d/network
> stop" (aside from the fact it won't get restarted when you reboot)?  I
> thought that's what different runlevels were for, having different daemons
> started when you boot.  Maybe I'm just thinking that mucking with
> /etc/rcS.d/ as easy enough, but I suppose a chkconfig would be easier for
> those less familiar with the init system.
>
> I don't like the idea of adding this check to each init script.  Wouldn't
> it be better to add this check to /etc/init.d/rcS when it goes through the
> /etc/rcS.d/S??* scripts (since the chkconfig parameter has the same name
> as the init script minus the S??)?
>
> Laters,
>
> Rick ([EMAIL PROTECTED])
> http://rick.chillin.org
>
> "As long as you want to live, everywhere will become heaven.
> Isn't that right?  Because you are still alive.
> The chance to achieve happiness, you can find it anywhere."
> Yui Ikari
> Neon Genesis Evangelion, "The End Of Evangelion"
>
>
> --
> To UNSUBSCRIBE, email to [EMAIL PROTECTED]
> with a subject of "unsubscribe". Trouble? Contact
> [EMAIL PROTECTED]
>

Re: Debian membership (with a twist)

[Decklin Foster]

Steve Willer writes:

> Yes, this is exactly the problem, and it's a big reason why I
> installed FreeBSD over Debian last night. I had hoped that the new
> school year would bring some energy to this project, but it's still
> the same old bickering, the same lack of forward movement, and
> new-maintainers still hasn't bothered to respond to my application
> (sent about 6 months ago).
>
> FreeBSD looks pretty good so far. Too bad it messes up /usr/local,
> but I can probably get used to that and put my own binaries
> somewhere else.

Me Too!

I think this point really needs to be stated. Over and over if
necessary perhaps. Count me in as another disillusioned applicant.

On a good note, my spare ancient IDE disk seems to be back up, so I
think i'll try FreeBSD this week. Oh well.

If I may suggest a few tactics --

a) create debian-discuss and keep -devel strictly technical (for
   example, this message would not be allowed.)
b) give the Project Leader the ability to stop stupid things like the
   /usr/doc -> /usr/share/doc debate, and just pick an option.
c) Accept all new-maintainer applications, now. Accept future
   applications immediately. Allow bad developers to be voted out of
   the project. We've revived the QA group, let's use it.
d) Do, and encourage, more NMUs. People who bitch about a package
   being "theirs" whilst not fixing bugs should be shot on sight.
e) Fix existing bugs *before* undergoing projects like HPML, Debconf,
   FHS compliance, etc.

All I can really say here is that if I *were* a developer, everyone
out there would have the right to tell me to shut up, stop wasting
time, and get back to hacking. But I'm not.

-- 
Decklin
Written with Debian GNU/Linux - http://www.debian.org/

doom source GPL'd

[Joey Hess]

It looks like the doom source is now under the GPL.
(http://www.doomworld.com/). This clears up the previous licencing problems
that were keeping it out of debian. It will still be fit only for contrib
for now, since it needs non-free WAD files.

Who's going to mackage it?

-- 
see shy jo

runlevel solution

[Colin Walters]

Why don't we have, by default, all daemons which grab ports run in
runlevel 3?  We could keep runlevel 2 as the default, which would
become the "workstation" (i.e. no services) runlevel, and 3 would
be the "all installed daemons start" runlevel.  That way, the
default configuration upon installation would be for a 
secure "workstation".  

-- 
Colin Walters <[EMAIL PROTECTED]>
http://web.verbum.org/levanti
PGP Fingerprint: A580 5AA1 0887 2032 7EFB  19F4 9776 6282 C207 843A

Re: doom source GPL'd

[Joseph Carter]

On Sun, Oct 03, 1999 at 12:41:51PM -0700, Joey Hess wrote:
> It looks like the doom source is now under the GPL.
> (http://www.doomworld.com/). This clears up the previous licencing problems
> that were keeping it out of debian. It will still be fit only for contrib
> for now, since it needs non-free WAD files.
> 
> Who's going to mackage it?

Joe Drew has lxdoom and I have agreed to sponsor his packages as soon as
I'm caught up with school again.  I (will) have dosdoom as soon as Andrew
Apted gets the dosdoom team off their tails to release the new version!
=p  Nobody has offered yet to take xdoom, but I suppose we don't NEED
linuxdoom really except for comparison's sake, so it's not exactly a big
deal.

Because the IWAD is non-free, before DOOM can go into main I have to get a
WAD editor packaged.  I'm looking at yadex now, which is based on DEU.
There was some discussion of an effort to build a completely free WAD for
people who just want to play it and not play with it.  I think Joe Drew or
I will probably package the shareware WAD too for people wanting it, but
that'd have to go into non-free.

-- 
Joseph Carter <[EMAIL PROTECTED]> Debian GNU/Linux developer
GnuPG: 2048g/3F9C2A43 - 20F6 2261 F185 7A3E 79FC  44F9 8FF7 D7A3 DCF9 DAB3
PGP 2.6: 2048R/50BDA0ED - E8 D6 84 81 E3 A8 BB 77  8E E2 29 96 C9 44 5F BE
--
 you people are all insane.
 knight: sure, that's why we work on Debian.
 Knghtbrd: get in touch with your inner nutcase.



pgpAVCxYQXJSN.pgp
Description: PGP signature

Re: corel linux demo

[Kenneth Scharf]

Actually I hadn't thought of the fact that you could
link a windows program agains winelib to create a
native linux executable, but it makes perfect sense. 
Corel might still need a few ifdef's to work around
known problems in wine's implementation of the win32
api, but it would be quite do-able.

--- Anderson MacKay <[EMAIL PROTECTED]> wrote:
> Ech, I'm a bit behind on my -devel reading.  I hope
> this question hasn't
> been answered down in another thread. :)
> 
> On Thu, Sep 30, 1999 at 06:49:15AM -0700, Kenneth
> Scharf wrote:
> > I understood wine as being a library that
> intercepted
> > win32 calls and redirected those calls into the
> > correct X or linux libraries for handling.  Corel
> > intends (as I understand it) to ship the actual
> > windows binaries (.exes) and maybe even .dll's
> with
> > whatever wrappers are required to run them under
> Wine.
> 
> Wine is two things: it's a library for linking
> Win32-source programs
> under most *nixes, and it's a call interceptor for
> ABI compatibility
> under x86-based *nixes.  The plan (as outlined by
> Corel on the Wine
> mailing list so long ago :) was to use Winelib to
> ease porting the Win32
> sources of Draw, WordPerfect, Quattro, and Paradox
> (maybe others...).
> The guy in charge of it all on the Corel end is
> Gavriel State, who is the
> same fellow who headed up the port of CorelDraw! to
> the Mac ... they
> apparently did something similar to Wine and wrote a
> source-translation
> library for that port as well.  Anyway, I'm pretty
> sure the shipped
> applications will be native Linux applications,
> although they'll be
> dynamically linked to Winelib ... very little
> difference from how gtk+
> applications link to libgtk, etc.
> 
> >  There will probably even be a Wine based program
> > launcher that will trigger of an icon for the
> > installed program on the desktop or 'K bar'. 
> Wine's
> > ultimate result is to make the win32 API become a
> > linux api as well.  It would stand beside gtk++
> and QT
> > in that regard.  Also means that the "setup.exe"
> 
> Exactly ... but I think you're confusing the issue a
> bit by bringing
> native Windows .exe files into the equation.  Were I
> Corel (and I'm not,
> obviously :), I would ship native Linux binaries ...
> the issues involved
> are so much less complicated in that case.  It's
> pretty difficult to do
> QA in a binary-emulation environment, if you ask me.
>  Consider that few
> effective debugging tools are going to work at all,
> as an example.  Wine
> includes a debugger, yes, but the purpose of that
> debugger is to debug
> Wine ... and it doesn't do convenient things like
> talk to Emacs, talk to
> ddd, etc.  Source-compatibility will be much less of
> a hassle.
> 
> Just as a status report -- I don't know the current
> status, but I do know
> that back in mid-spring of this year, Corel (well,
> Gav State, actually)
> claimed to have Quattro Pro running with very few
> glitches when compiled
> against Winelib.  I'm sure they've come a long way
> since then, so expect
> to see good things.
> 
> -- 
> Anderson MacKay <[EMAIL PROTECTED]>
> 


=
Amateur Radio, when all else fails!

http://www.qsl.net/wa2mze

Debian Gnu Linux, Live Free or .


__
Do You Yahoo!?
Bid and sell for free at http://auctions.yahoo.com

Re: doom source GPL'd

[Daniel Burrows]

On Sun, Oct 03, 1999 at 12:41:51PM -0700, Joey Hess was heard to say:
> It looks like the doom source is now under the GPL.
> (http://www.doomworld.com/). This clears up the previous licencing problems
> that were keeping it out of debian. It will still be fit only for contrib
> for now, since it needs non-free WAD files.
> 
> Who's going to mackage it?

  Cool.  Does this mean Heretic can go in as well?  I've actually got a
Debianization diff against one of the beta versions of the Linux port that I
never did anything much with because of the licensing; if someone's interested
in packaging it, I can send them it (and even the orig.tar.gz I used).  I also
have a package of the shareware WAD files..I don't remember if I can distribute
it offhand, though.  It's certainly not free. :)

  Daniel

-- 
I haven't lost my mind, I know exactly where I left it.

Re: doom source GPL'd

[Joey Hess]

Joseph Carter wrote:
> Joe Drew has lxdoom and I have agreed to sponsor his packages as soon as
> I'm caught up with school again.

Ok, he might want to look at my old lxdoom package, which has several
patches in it. (ftp://kitenet.net/pub/code/debian/)

What about the music server?

-- 
see shy jo

Re: doom source GPL'd

[Joseph Carter]

On Sun, Oct 03, 1999 at 01:33:29PM -0700, Joey Hess wrote:
> > Joe Drew has lxdoom and I have agreed to sponsor his packages as soon as
> > I'm caught up with school again.
> 
> Ok, he might want to look at my old lxdoom package, which has several
> patches in it. (ftp://kitenet.net/pub/code/debian/)
> 
> What about the music server?

I'm hoping to convince the lxdoom and dosdoom people to throw it and the
sound server away.  They suck and are evil.  Would be better to write
sound support directly these days (and is now actually reasonable to do.
I even have soundfonts that make Timidity Not Suck---I'm going to
investigate packaging them later if I can contact their creators for info
regarding licenses..

Yeah, we'll package the evil music server in the meantime.  =>

-- 
Joseph Carter <[EMAIL PROTECTED]> Debian GNU/Linux developer
GnuPG: 2048g/3F9C2A43 - 20F6 2261 F185 7A3E 79FC  44F9 8FF7 D7A3 DCF9 DAB3
PGP 2.6: 2048R/50BDA0ED - E8 D6 84 81 E3 A8 BB 77  8E E2 29 96 C9 44 5F BE
--
... Where was Stac Electronics when Microsoft invented Doublespace? Where
were Xerox and Apple when Microsoft invented the GUI?  Where was Apple's
QuickTime when Microsoft invented Video for Windows?  Where was Spyglass
Inc.'s Mosaic when Microsoft invented Internet Explorer? Where was Sun
when Microsoft invented Java?



pgp39UbgTWPup.pgp
Description: PGP signature

Re: doom source GPL'd

[Joey Hess]

Joseph Carter wrote:
> I'm hoping to convince the lxdoom and dosdoom people to throw it and the
> sound server away.  They suck and are evil.  Would be better to write
> sound support directly these days (and is now actually reasonable to do.
> I even have soundfonts that make Timidity Not Suck---I'm going to
> investigate packaging them later if I can contact their creators for info
> regarding licenses..
> 
> Yeah, we'll package the evil music server in the meantime.  =>

I did a *lot* of hacking on the music server, making doom communicate with
it via a pipe and other things and got it working really well.

It is evil though, it has to re-parse all the wads..

I seem to have ditched that when I stopped using dosdoom and went to lxdoom
though. I forget what the story was there.

-- 
see shy jo

Re: xplanet project - volunteers sought

[James A. Treacy]

On Sat, Oct 02, 1999 at 11:55:10PM -0700, Randolph Chung wrote:
> Have you all seen the nice developers' map at
> http://www.debian.org/devel/developers.loc ?
> 
> Here's your chance to help make it better!
> 
> The map is generated by xplanet. However, we have a few slight problems
> 
> 1) xplanet doesn't build well on slink (well, xplanet does, but it depends
> on things that are only in potato). This can be circumvented with a bit of
> effort
> 
> 2) more importantly though, xplanet uses imlib, which requires a X display
> to run. This means that we can't generate the map easily from a
> non-interactive script (like a crontab or something)
> 
> Would someone be interested/willing to look at the xplanet code and patch
> together something that uses, say, libjpeg instead of imlib? Please email me
> if you are willing to take this one. Thanks!
> 
Please go through the upstream maintainer. He is open to feedback
and has been very responsive to problems I've brought to his
attention. He may be willing to implement this.

Jay Treacy

Re: doom source GPL'd

[Joseph Carter]

On Sun, Oct 03, 1999 at 01:48:35PM -0700, Joey Hess wrote:
> > Yeah, we'll package the evil music server in the meantime.  =>
> 
> I did a *lot* of hacking on the music server, making doom communicate with
> it via a pipe and other things and got it working really well.
> 
> It is evil though, it has to re-parse all the wads..
> 
> I seem to have ditched that when I stopped using dosdoom and went to lxdoom
> though. I forget what the story was there.

Well, Andrew Apted and I were talking about putting native sound code in
lindosdoom (which exists, works, and isn't going to be released until
they're ready to release their next version which means even I haven't
seen it yet---closed projects suck!) just because ... well, the servers
are evil as I said.  =>

We have good ideas on how to do it and the GPLing of the doom source makes
them all the more likely to happen.  My hope eventually is that the doom
ports can kinda consolidate a bit.  Things like code theft in the inital
open projects is making people wary of opening them again.  =<  The GPL on
the doom source will hopefully help prevent that happening again  but
we'll see...


You know, I think I need to fix postfix's rewrite of my address, it
doesn't seem to work quite right on this end I think.  Does this message
look right to you?  If it is, it must be my mutt config isn't quite
expecting the right things.

-- 
Joseph Carter <[EMAIL PROTECTED]> Debian GNU/Linux developer
GnuPG: 2048g/3F9C2A43 - 20F6 2261 F185 7A3E 79FC  44F9 8FF7 D7A3 DCF9 DAB3
PGP 2.6: 2048R/50BDA0ED - E8 D6 84 81 E3 A8 BB 77  8E E2 29 96 C9 44 5F BE
--
But modifying dpkg is infeasible, and we've agreed to, among other things,
keep the needs of our users at the forefront of our minds. And from a
user's perspective, something that keeps the system tidy in the normal
case, and works *now*, is much better than idealistic fantasies like a
working dpkg.
-- Manoj Srivastava



pgpsYzo0IuxFE.pgp
Description: PGP signature

Re: ITW/P: freecati

[Craig Sanders]

On Sat, Oct 02, 1999 at 10:50:06PM -0500, Chris Lawrence wrote:
> On Oct 03, Craig Sanders wrote:
> > IMO, this is morally akin to writing free software specifically to make
> > spamming cheaper and easier.
> 
> No, it isn't.  Survey research is an important part of the social
> sciences.  

it may be an important tool, but that doesn't give you or anyone else
the right to pester people in their own homes. it really does no good to
apologise or even to promise not to call back - by that time, the damage
has been done...the interruption/disturbance has been made, the invasion
of peace, solitude and privacy has already been perpetrated.

even opt-out lists are the wrong solution...because they don't work very
well (especially when usage of them is optional). telephone pests should
be limited to calling ONLY an opt-in list, people who are willing to
receive unsolicited calls.

 
> 1. Market research is only one use of computer assisted interviewing.
>The purpose of this project is to make it possible for a survey lab
>to be established cheaply by a university; existing solutions are
>overpriced, especially considering the fact that taxpayers tend to
>get hit with the startup costs for these things.

cold calls are annoying regardless of their purpose. sales calls are
especially annoying, but that doesn't excuse academic or market research
surveys.

i personally don't have a problem with existing solutions being
overpriced - this is one area where an artificially high barrier to
entry is unquestionably a Good Thing. the right to peace and quiet in
your own home is far more important than the desire of universities to
conduct surveys.


> 2. Ethical researchers do not call back people who, having been
>informed of the nature of a survey, choose not to participate.  The
>software will include this "refusal" marking capability.

good. that was the main reason i replied to your message. if you are
going to write software that makes it easier or cheaper to pester people
in their own homes then that software should make it trivially easy to
add new numbers to the do-not-call list, and it should be do-able by the
operator who makes the call at the time that the victim complains.


> 4. Software is a tool, it is neither evil nor good.  Like any other
>technology, it is a matter of responsible use.

some technologies have little or no 'good' usage. some technologies have
negative effects which greatly outweigh any positive ones.


> Chris, who guesses he should have kept his mouth shut, made the
> software proprietary, and saved everyone a world of grief.

look, it's your software, your project. nobody can stop you from
writing it, or packaging it for debian. the point of my message was
to inform you that your work will have certain negative consequences
and will end up being used to harass and pester people. little/startup
telemarketing companies WILL use your software whether you market it as
a "telemarketing solution" or not - this WILL increase the number of
annoyance sources in the world. like it or not, you have to accept some
of the moral responsibility for that.

craig

--
craig sanders

Re: Debian membership (with a twist)

[Hamish Moffatt]

On Sun, Oct 03, 1999 at 01:26:37PM -0400, Steve Willer wrote:
> Yes, this is exactly the problem, and it's a big reason why I installed
> FreeBSD over Debian last night. I had hoped that the new school year would

Just us on debian-bsd, then?

It's a bit dead presently but it was pretty lively a few weeks back.


Hamish
-- 
Hamish Moffatt VK3SB (ex-VK3TYD). 
CCs of replies from mailing lists are welcome.

Re: slink -> potato

[Herbert Xu]

On Sun, Oct 03, 1999 at 09:57:12AM -0400, Raul Miller wrote:
> 
> As far as I know, leaving inetd accepting connections would, worst case,
> fail -- which is no different from having the service disabled.  In other
> words, I don't see that disabling the daemon solves anything useful.

I think the worst case would be a telnetd linked with a broken shlib (or in
the case of telnetd, perhaps a missing or broken /usr/lib/telnetd/login) that
gives a security hole.  If you wish to minimise downtime, the proper way to
do it IMHO is to have certain packages flagged as daemons, and they should be
upgraded (by whatever program that is in charge) one by one.
-- 
Debian GNU/Linux 2.1 is out! ( http://www.debian.org/ )
Email:  Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

Re: ITW/P: freecati

[Marcus Brinkmann]

On Mon, Oct 04, 1999 at 08:13:02AM +1000, Craig Sanders wrote:
> even opt-out lists are the wrong solution...because they don't work very
> well (especially when usage of them is optional). telephone pests should
> be limited to calling ONLY an opt-in list, people who are willing to
> receive unsolicited calls.

opt-in lists will not lead to usable results, because the statistics will be
skewed, and you know that. Nevertheless, I agree that calling random people
is rude.

> cold calls are annoying regardless of their purpose. sales calls are
> especially annoying, but that doesn't excuse academic or market research
> surveys.

Yes. What I find acceptable are snail mail surveys. Those can be easily
ignored, and are paid by the sender. (Note that I find mail advertisement
highly offensive, but surveys are not at all comparable in mass).

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: doom source GPL'd

[Andre Majorel]

At 13:17 1999.10.03 -0700, Joseph Carter wrote:
>On Sun, Oct 03, 1999 at 12:41:51PM -0700, Joey Hess wrote:
>> It looks like the doom source is now under the GPL.
>> (http://www.doomworld.com/). This clears up the previous licencing problems
>> that were keeping it out of debian. It will still be fit only for contrib
>> for now, since it needs non-free WAD files.
>> 
>> Who's going to mackage it?
>
>Joe Drew has lxdoom and I have agreed to sponsor his packages as soon as
>I'm caught up with school again.  I (will) have dosdoom as soon as Andrew
>Apted gets the dosdoom team off their tails to release the new version!
>=p  Nobody has offered yet to take xdoom, but I suppose we don't NEED
>linuxdoom really except for comparison's sake, so it's not exactly a big
>deal.

Careful with that term "xdoom". There is a Doom hack really called
"XDoom" and that has nothing to do with linuxxdoom. It was AFAIK the
first working X port of Doom after linuxxdoom and it is certainly
worth packaging, even if it doesn't support high-res.

>Because the IWAD is non-free, before DOOM can go into main I have to get a
>WAD editor packaged.  I'm looking at yadex now, which is based on DEU.

Please by all means use the latest semi-public beta (no link from the
home page) http://www.teaser.fr/~amajorel/yadex/yadex-1.1.0.tar.gz.
Yadex 1.0.1 is severely obsolete. Now that I'm done with DeuTex, I hope
to resume work on Yadex and release v1.1.1 this month. Let me know how
it goes for you.

I would also love to see the following utilities packaged :

- xwadtools (ftp://ftp.cdrom.com/pub/idgames/source/xwadtools-*.tar.gz)
  A large collection of Doom hacking utilities, including an editor,
  tkwadcad. Definitely a must.

- DeuTex (http://www.teaser.fr/~amajorel/deutex/)

I'm unsure whether Doom hacking utils can go in the main section at
all because I seem to remember that id set some conditions on them.
They shouldn't work with the shareware iwad, the resulting wads
shouldn't be sold for profit, stuff like that. Would the GPLization
of Doom change that ?


André Majorel <[EMAIL PROTECTED]>
http://www.teaser.fr/~amajorel/

Re: slink -> potato

[Raul Miller]

On Sun, Oct 03, 1999 at 09:57:12AM -0400, Raul Miller wrote:
> > As far as I know, leaving inetd accepting connections would,
> > worst case, fail -- which is no different from having the service
> > disabled. In other words, I don't see that disabling the daemon
> > solves anything useful.

On Mon, Oct 04, 1999 at 08:15:54AM +1000, Herbert Xu wrote:
> I think the worst case would be a telnetd linked with a broken
> shlib (or in the case of telnetd, perhaps a missing or broken
> /usr/lib/telnetd/login) that gives a security hole. If you wish to
> minimise downtime, the proper way to do it IMHO is to have certain
> packages flagged as daemons, and they should be upgraded (by whatever
> program that is in charge) one by one.

Under what circumstances would this be in effect during an
upgrade but not otherwise?

-- 
Raul

Re: bash package removing /bin/sh on upgrade

[Raul Miller]

On Mon, Oct 04, 1999 at 02:10:45AM +1000, Anthony Towns wrote:
> (What is the problem with --rename, btw? I'm curious, and dpkg-divert is
> horribly underdocumented)

>From dpkg-divert --help:
--rename causes dpkg-divert to actually move the file aside (or back).


There's no reason to remove the /bin/sh link.  By default, dpkg-divert
will divert the effect of future installs without touching the target
file.

-- 
Raul

ITP: buglist?

[Thomas Schoepf]

Hi,


this is a perl script I've written, because I was fed up with manually
fetching bug reports and storing them into a directory structure so that
browsing still works. Now, when I type 'buglist -r -d ~/debian/Bugs less',
all reports regarding 'less' are saved into ~/debian/Bugs, structured as
they are on the BTS, so I can easily click through the reports. I'm also able
to download individual reports: 'buglist 42610'.

I'm posting this because I'd like to know whether there's popular interest
in this script or if I'm just so egocentric that I just think, everything I
use would be useful for everyone else ;)

Package: buglist
Priority: extra
Section: utils
Installed-Size: 18
Maintainer: Thomas Schoepf <[EMAIL PROTECTED]>
Version: 0.1
Depends: perl5, libwww-perl
Description: Download bug reports from the Debian BTS
 buglist can download individual bug reports from the Bug Tracking
 System based on package names or bug numbers. But it is also able to
 fetch all bug reports filed against packages and let's you store them
 on your local filesystem. Proxy servers are supported.


Thomas
-- 
GnuPG: ID=B0FA4F49, http://www.in.tum.de/~schoepf/gpgkey.txt
  Fingerprint: FA38 2D7E 408F 61E4 BF49  B48F 04BD F5BE B0FA 4F49
PGP 2: ID=2EA7BBBD, http://www.in.tum.de/~schoepf/pgpkey.txt
  Fingerprint: 08 96 1F CD AD 55 03 0F  95 92 B0 F2 04 32 4B 52


pgp3PdOHQmRQY.pgp
Description: PGP signature

Re: Debian membership (with a twist)

[Yves Arrouye]

> [This long approval times may be desired by Debian because there are
> already too many developers and packages.]
> This may be correct.  I can't judge.  But it seems to me that if some-
> one volunteers time and effort to the project, common courtesy demands
> /at least/ an autoreply acknowledging the the application.  An explana-
> tion of the current situation would be nice also.

Can one of the people allowed to process the new-maintainer alias speak
here? It would be really nice to get their point of view and
explanation. Not only on my particular situation (having contributed to
the 1.* Debian distributions and coming back today) but just the simple
one where someone emails new-maintainer and does not get any feedback in
6 months as Steve said.

Yves.

Re: ITW/P: freecati

[Raul Miller]

On Mon, Oct 04, 1999 at 08:13:02AM +1000, Craig Sanders wrote:
> it may be an important tool, but that doesn't give you or anyone else
> the right to pester people in their own homes. it really does no good
> to apologise or even to promise not to call back - by that time, the
> damage has been done...the interruption/disturbance has been made, the
> invasion of peace, solitude and privacy has already been perpetrated.

Huh?  I'd rate such (genuine survey) phone calls as more pleasant to
deal with than any of your recent emails.

I've gotten phone calls from telemarketers, and I've gotten phone calls
from survey folks.  The survey folks are incomparably more polite.

On the other hand, I've got a decent sized buffer (voice mail) on my
phone and don't feel compelled to answer it if I'm in the middle of
something else (which is most of the time).

-- 
Raul

Re: Suggestion: binfmt_misc handling

[Brian May]

In article <[EMAIL PROTECTED]> you write:
>  Basically what you can do is create a directory called /etc/binfmt_misc and
>put a bunch of files in it; each file should be a series of lines where each
>line is a directive for the binfmt_misc registration file in /proc.  So the
>incantation for Java is:
>:Java:M::\xca\xfe\xba\xbe::/usr/bin/javawrapper:
>  (assuming that /usr/bin/javawrapper does something sensible), and for JPEG
>(yes, this is a really dumb usage of binfmt_misc, but it's the only other
> magic number I could come up with offhand):
>
>:JPEG:M::0xffd8::/usr/X11R6/bin/display:
>:JPEG-JFIF:M::JFIF::/usr/X11R6/bin/display:
>:JPEG-HSI:M::hsi1::/usr/X11R6/bin/display:
>
>  Comments are also supported (by beginning a line with '#')
>
>  Packages such as Wine, Kaffe, dosemu, and perhaps Frotz would drop a file
>into this directory announcing their support of a binary format.  The files
>wouldn't actually be interpreted unless this init.d script is installed; I
>assume that someone is going to claim this is a security hazard, so I thought
>I'd point that out :P

I have two comments:

1. Where would you install the files into this directory?

Ideally, IMHO, it would be possible to directly embed the config file
into the deb file, with the full pathname under /etc/bin_fmt.

However, in this case, what would happen with duplicates? eg what will
happen when many packages that provide Java, all provide their own
(possibly different) entry under /etc/bin_fmt?



2. Suggestion: Would it be possible to somehow integrate this with
/etc/mailcap, which already has good support in packages? There are
different ways you could do this, eg have in the config file lines that
look like:

:Java:M::\xca\xfe\xba\xbe::application/x-java:
:JPEG:M::0xffd8::image/jpeg:
:JPEG-JFIF:M::JFIF::image/jpeg:
:JPEG-HSI:M::hsi1::image/jpeg:

Where the last field is replaced with the appropriate command line from
the /etc/mailcap file. Not that there currently is a mailcap entry (at
least on my slink system) for java...

This file could potentially be used for more applications then just the
kernel - any program that wants to map the file to a MIME type. (Apache
already does this - is this any better? I suspect Apache's is hardcoded,
but not sure).

I think that this could be done with similar structure as originally
proposed.
-- 
Brian May <[EMAIL PROTECTED]>

Re: ITW/P: freecati

[Craig Sanders]

On Mon, Oct 04, 1999 at 01:02:55AM +0200, Marcus Brinkmann wrote:
> On Mon, Oct 04, 1999 at 08:13:02AM +1000, Craig Sanders wrote:
> > even opt-out lists are the wrong solution...because they don't work very
> > well (especially when usage of them is optional). telephone pests should
> > be limited to calling ONLY an opt-in list, people who are willing to
> > receive unsolicited calls.
> 
> opt-in lists will not lead to usable results, because the statistics
> will be skewed, and you know that.

yep. there's an inherent conflict between those who want to run surveys
and those who don't want to be pestered. i happen to believe that an
individual's right to privacy, right to not be pestered supercedes a
researcher's desire to survey.

so, it's a shame that stats might be skewed but that doesn't justify
bothering people who don't want to be pestered.

btw, if the opt-in list were large enough then there wouldn't be any
skewing of results. most telesales, telemarketing, and tele-survey
people don't want to use opt-in lists because they KNOW that most people
don't want to be pestered by them...opt-in highlights the fact that what
they are doing IS rude, and most people resent it.

OTOH, many people don't mind being surveyed or called by salesdroids. i
find that bizarre, but i guess it's horses for courses.

> Nevertheless, I agree that calling random people is rude.

that's it precisely.


craig

PS: all this is getting even further from relevance to debian-devel, so
i guess we better stop here.

--
craig sanders

Re: doom source GPL'd

[Edward Betts]

Andre Majorel <[EMAIL PROTECTED]> wrote:
> Please by all means use the latest semi-public beta (no link from the
> home page) http://www.teaser.fr/~amajorel/yadex/yadex-1.1.0.tar.gz.
> Yadex 1.0.1 is severely obsolete. Now that I'm done with DeuTex, I hope
> to resume work on Yadex and release v1.1.1 this month. Let me know how
> it goes for you.
> 
> I would also love to see the following utilities packaged :
> 
> - xwadtools (ftp://ftp.cdrom.com/pub/idgames/source/xwadtools-*.tar.gz)
>   A large collection of Doom hacking utilities, including an editor,
>   tkwadcad. Definitely a must.
> 
> - DeuTex (http://www.teaser.fr/~amajorel/deutex/)

At this rate we are going to need a tasks-doom

> 
> I'm unsure whether Doom hacking utils can go in the main section at
> all because I seem to remember that id set some conditions on them.

They should have a clear licence in the .tar.gz files surely? If somebody
writes a wad editor from scratch then ID can have no affect on the licencing
surely?

> They shouldn't work with the shareware iwad, the resulting wads
> shouldn't be sold for profit, stuff like that. Would the GPLization
> of Doom change that ?

How can they put limitations on your piece off work, I do not understand, do
they have a patent on wad files (I do not think so).

-- 
I consume, therefore I am

Re: slink -> potato

[Herbert Xu]

On Sun, Oct 03, 1999 at 07:06:10PM -0400, Raul Miller wrote:
> 
> On Mon, Oct 04, 1999 at 08:15:54AM +1000, Herbert Xu wrote:
> > I think the worst case would be a telnetd linked with a broken
> > shlib (or in the case of telnetd, perhaps a missing or broken
> > /usr/lib/telnetd/login) that gives a security hole. If you wish to
> > minimise downtime, the proper way to do it IMHO is to have certain
> > packages flagged as daemons, and they should be upgraded (by whatever
> > program that is in charge) one by one.
> 
> Under what circumstances would this be in effect during an
> upgrade but not otherwise?

The fact that dpkg does not deconfigure a package which depends on another
deconfigured package is a bug in dpkg.  This should not be used as an excuse
to not deal with things correctly in maintainer scripts.
-- 
Debian GNU/Linux 2.1 is out! ( http://www.debian.org/ )
Email:  Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt