Re: anarchism_7.7-1.deb

[Bjoern Brill]

On Thu, 23 Sep 1999, Tomasz Wegrzanowski wrote:

> I suggest renaming anarchist_7.7-1.deb to
> anarcho-communism_7.7-1.deb or throwing it out of distribution
> cause it have nothing to do with real anarchy
> and make mess in peoples' minds
> someone who doesnt really know what anarchy is after reading
> this doc will found anarchy stupid and anarchist morons
> I dont think anarchy is stupid nor anarchists are morons
> This FAQ is more propaganda document in fight between
> anarcho-communists against anarcho-capitalists than
> roasonable source of knowledge about what it claims to
> describe

???!
I didn't believe it, but yes: it's there.

Taking the risk to burn like hell: I think the "exhaustive exploration"
of ANY political theory and practice is VERY misplaced in ANY Linux
distribution. I would say the same thing about "The top 1000 FAQ on
home-made apple pie", but nobody has packaged that (yet).

To give a positive formulation: documentation and data packaged in ANY
Linux distribution should either directly relate to (at least) computing
in general or be the input to an also-packaged program (that does more
with it than a little bit of formatting so it reads nicer).


Bj"orn Brill <[EMAIL PROTECTED]>
Frankfurt am Main, Germany

Re: anarchism_7.7-1.deb

[Bjoern Brill]

On Thu, 23 Sep 1999, Peter S Galbraith wrote:

> I agree with you, and wish we'd toss all non-relevant packages
> out, or at least move them into the data section.
> (That said, I think stuff like coastline data that we could use
> to make maps would be okay for the data section; Where do I draw
> the line?  Well, can you at least compute the stuff?  Or simply
> read it?)
> 

Geographic data would be OK if there's a program packaged that could
draw maps (is this formatting?) or tell the shortest distance from some
point to the coast or read GPS data from a serial line and show you where
you are etc. Otherwise I'd say there are specialized research servers on
the net for astronomic, genetic, geographic, statistic and the like
data (although I'm personally very interested in some of these).

Formal requirements tend to produce a lot of borderline cases, but a
little bit of common sense is usually enough to solve them.
The difference between a real distribution and a 10 CD roast from
ftp.*.edu is that somebody has taken care of the configuration,
integration  and proper interaction of the components. Dumping 3 MB of 
do-with-it-what-you-want into the FHiloSophically right place of the file
system doesn't require that.


Yours,

Bj"orn Brill <[EMAIL PROTECTED]>
Frankfurt am Main, Germany

Re: problems with the perl5 packages

[Bjoern Brill]

On Fri, 24 Sep 1999, Josip Rodin wrote:

> On Fri, Sep 24, 1999 at 01:32:29PM +, Dale Scheetz wrote:
> > So, why are there packages with depends lines that include both perl5 and
> > a particular version, like perl-5.005?
> 
> When a package depends on a virtual package which is provided by multiple
> real packages, but none of these are already installed (hint: new
> installation of the whole system), APT and dselect will be confused and not
> know what to do, because they can't just make a guess and install a package
> when several equal (to them) options are present. [1]
[...]

I thought at least dselect does make a guess, but I may be wrong. Anyway,
a default is provided by lines like "Depends: perl-5.005 | perl5".
In contrast, "Depends: perl-5.005, perl5" should be equivalent to
"Depends: perl-5.005" (except perhaps for some trickeries involving
Conflicts: / Replaces: ).


Bj"orn Brill <[EMAIL PROTECTED]>
Frankfurt am Main, Germany

Re: Censoring :) (was: Re: anarchism_7.7-1.deb)

[Bjoern Brill]

On Tue, 28 Sep 1999, Jaldhar H. Vyas wrote:

> 
> Why even involve debhelper?  At least in the case of the Project Gutenberg
> files some of which I have, they are just long ascii files so the rules
> file could just stick them into (for example) /usr/share/doc/etexts call
> doc-base and be done with it.  AFAIK all the project Gutenberg files are
> public domain so one generic fill in the blanks copyright file would
> suffice.  Voila you almost instantly have 2000 works containing more than
> a gig of text.
> 
> I'd buy  such a CD if it were offered.  And I know plenty of people who
> would too.
> 

I would, too.

But I don't see the need to *package* large ascii files. What would be
the difference between Gutenberg Debian-packaged and Gutenberg gzipped on
CD or ftp?

There *is* a difference for documents that require some technical setup
to work (like the kjv-bible that needs a special viewer program) or are
processed by other programs (like verse).


Bj"orn Brill <[EMAIL PROTECTED]>
Frankfurt am Main, Germany

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

[Bjoern Brill]

On Tue, 28 Sep 1999, Clint Adams wrote:

> > Ok, let's bring this back to implementation.  How would you propose we 
> > handle
> > this?  Currently daemons install, set themselves up, and begin running.
> > 
> > a) we can prompt.
> > b) we leave everything off and let the admin turn it on (not an option for
> > obvious reasons)
> > c) first come first serve -- first daemon installed does its job, the rest
> > install unconfigured
> > 
> > any others?
> 
> d) have something that keeps track of installed services, perhaps with
>priorities akin to alternatives.  If there weren't an issue of
>services being run either in inetd or standalone, this could
>be accomplished with a souped-up update-inetd.
a) is possible, but I don't really like it. It may be not too bad if
'prompt' means 'ask debconf'.
d) is perhaps the right thing, but sounds like a lot of work and changes
to dozens of packages.
Until this is done, c) could be a possible  solution. It would also allow
to inhibit automatic start of services at all by providing packages
noop-httpd, noop-fingerd, ... (in extra and with appropriate warning in
the description) to be installed as 'first ones' by the knowing sysadmin.

The main problem I see with c) is how to determine if we are the first one
regarding the standalone/inetd mess without introducing parts of d).
c) should the be designed so that it makes later transition to d) easy (in
fact c) could be just one of the policies implemented by d)).
But then decisions on flexibility (how highly-customized and
possibly problematic setups are to be supported: multiple interfaces - 
some secure and some not, multiple IPs - virtual hosting etc., ...)
have to be made early or daemon package maintainers will become
badly-behaved daemons themselves.

Some basic ideas for c) -> d) :

/var/state/servicemgr/daemons:
#the supergeneric version, perhaps drop/ignore some fields
#package service interface ip port protocol inetd|standalone mtime
apache   www * *  80   tcp  standalone   28 Sep 1999 \
18:30:16 -

interface and ip would have to be * by default or things will badly suck on
machines without permanent network connection. interface  can be determined
by IP most of the time, but not for dial-up connections. fetchmail tries
to care for the right (secure) interface if asked to but is no real
example for the kind of daemon addressed here because it doesn't listen
ports but polls. Are there any?

A package providing a daemon would then have to supply a canonically-named
script or executable, e.g. .dmconf with canonical 
options/arguments (including service, because one excutable may provide
several at once) to de/configure and register all that stuff with the help
of some scripts supplied by 'servicemgr'. .dmconf should be
allowed to fail (gracefully) if the setup is more complex than it can
handle (which could include, for a start, interface != *,  ip != *,
moving services into/out of inetd.conf, using non-standard ports or
setting up coexistence with another package already providing the same
service so we're back to c)).

The nicest thing would be to make what I called .dmconf a new
kind of maintainer script or include it in one of the existing.

To make things even more complex, the default configuration for the first
or only daemon providing a service should be taken from debconf if one has
been chosen there. This could require that parts of the per-package
configuration are in a cononical format, too if settings of the kind
'whatever httpd I use, I want it on port 81!' should be supported.

Does this mean a) -> d) is the better way of migration?


Bj"orn Brill <[EMAIL PROTECTED]>
Frankfurt am Main, Germany

Re: mtools

[Bjoern Brill]

On Tue, 28 Sep 1999, David Weinehall wrote:

> On Tue, 28 Sep 1999, Dale Scheetz wrote:
> 
> [snip]
> 
> > Guys, guys, guys...  This is a discussion that was had quite a while ago,
> > and which lead to the creation of xlib6. The whole point was that it was
> > unnecessary glut to include a console version _and_ an X aware version of
> > packages like emacs (and others), when a small library could provide all
> > that was necessary to make a single program both console and X compatible.
> > xfree86-common is simply a recent way to remove the architectural
> > independent pieces from xlib6 and provide them in an independent fashion.
> 
> This is ok with me for stuff like emacs (eventhough I'd really become
> aggressive if someone removed the vim-tty package.), but when it comes to
> mtools, it's only one single file; a daemon (floppyd, if I'm not all
> wrong) that needs xlib6g. It'd be simple to extract this daemon from
> mtools and create an extra package with just this file, and make this file
> recommended by mtools, and make mtools required by the extra-package.
> 

I agree it seems unnatural that something as fundamental as mtools depends
on xlib6g, be it small or not.
*But* in this case, it seems hard to avoid. As I understand it, the
*whole* mtools package makes 'parasitic' use of the X protocol
(in fact of an existing X connection) to give authenticated access to
remote floppy drives. Floppyd is the server, and most or all of the other
commands can act as clients. So the whole package has to be compiled with
or without X.



Bj"orn Brill <[EMAIL PROTECTED]>
Frankfurt am Main, Germany

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

[Bjoern Brill]

On Wed, 29 Sep 1999, Clint Adams wrote:

> > debian's attitude is: if you want something different, DIY. and more
> > importantly, it lets you DIY.
> 
> Err.. what Unix DOESN'T let you DIY?

Every Unix lets you DIY, of course. The problem is the *'/(&%
configuration done by most all distributions and commercial Unices. It
says: "do it our way or DIY everything". Now DIY everything is an option
if you've had several years of experience as Unix sysadmin, but how do you
get there? And why do you need a distribution involving years of work of
several hundred people then? ftp; configure; make install; vi /etc/foo 
does it (maybe with some struggles in between).

What brought me to Debian is the "we provide a reasonably working setup 
for most users, and if you don't like it you can go and DIY without f*ing
up all the rest and fighting some AutoMagicallyMisConfigured(TM) utility"
approach. Try SuSE's yast if you can't see the difference.

Debian isn't RH, but it isn't Slackware either. It has some of the goodies
of both sides. In the case of daemon configuration, there is still some
work to be done, however. Set up (sensibly) and start the first one
providing a service and leave following ones for DIY could be a good
solution.


Bj"orn Brill <[EMAIL PROTECTED]>
Frankfurt am Main, Germany

Re: dpkg -l format

[Bjoern Brill]

On Tue, 5 Oct 1999, Colin Walters wrote:

> 
> The output format of dpkg -l is terrible.  Many package names exceed
> the measly 16 characters allotted.  Many, many times when trying to

Yes.

> what I really want to do is dpkg -l '*netscape*' | xargs dpkg --purge.

I recommend dpkg --get-selections '*netscape*' instead. But the whole
bunch of 'informative' dpkg options is rather weird:

* dpkg --list doesn't list all available packages, but just the ones that
  have been 'touched' by a selection. dpkg -- list '*' lists all available
  and some unavailble (old cruft) packages. (not documented)
* same with dpkg --get selections. (not documented)
* dpkg -l '*netscape*' lists (on my system, continuously upgraded
  since Debian 1.3) MORE packages than dpkg --get-selections '*netscape*'
  but the difference is again never-installed cruft. (not documented)
* there is no obvious reason (except that the dpkg developers may have
  more important things to fight with) why dpkg --status and
  dpkg --print-avail shouldn't accept wildcards, too, but they don't.
  (documented)


Bj"orn Brill <[EMAIL PROTECTED]>
Frankfurt am Main, Germany

Re: linking binfmt_misc with mime-types

[Bjoern Brill]

On Tue, 5 Oct 1999, Brian May wrote:

[...]
> 
> What I really would like is a filesystem that can store a mime-type for
> every file... That way no magic databases are required. In addition, the
> kernel could be configured to assign default mime-types for different
> file extensions, or something.
> 
> This would mean instead of having lots of different programs trying
> to determine file types (each with a very different method - some use
> extensions, others use magic databases or a combination of the two).
> Programs like Apache wouldn't have to work out the mime type from the
> extension, but could just look at the value given by the filesystem.
> Changing the mime-type for one file would automatically effect
> all programs.
> 
> [ runs for cover... ]
> 

Apples MacOS does nearly that (not really MIME types, but a proprietary
code with the same intention). First I liked the idea, but after some time
the whole thing started to suck deadly and when I work on a Mac now, one
of the most important utilities I use is named 'Set its type!'.

I think file(1) does quite a good job and I believe that specifying
what you want to do with a file is much better than 'click it and wait for
the magic'. There are far too many useful actions available for some file
types.

Now that doesn't mean you have to cover. My mailer still doesn't support
x-application/flamethrower :)~~



Bj"orn Brill <[EMAIL PROTECTED]>
Frankfurt am Main, Germany

Re: linking binfmt_misc with mime-types

[Bjoern Brill]

On Wed, 6 Oct 1999, Brian May wrote:

> >> What I really would like is a filesystem that can store a mime-type for
> >> every file... That way no magic databases are required. In addition, the
> >> kernel could be configured to assign default mime-types for different
> >> file extensions, or something.
> >> 
[...]
> >
> >Apples MacOS does nearly that (not really MIME types, but a proprietary
> >code with the same intention). First I liked the idea, but after some time
> >the whole thing started to suck deadly and when I work on a Mac now, one
> >of the most important utilities I use is named 'Set its type!'.
> 
> Where Macintosh fails, IMHO, is due to
> 
> - No easy way to change the file type. 
>
Yes. 

> - The information it proprietary, and not used anywhere else.
>
Part of the problem. Mapping works well with WWW downloads, but bad with
floppies from other OSes.
 
> - I am not very familar with the operating system, so there might
> be more points that I have missed. Perhaps there are difficulties
> loading a file for one application inside another application?
> 
Most programs are AppleThink and refuse to open files of types they don't
know. A few try to determine the type based on the contents. The rest
(development tools or very tiny programs mostly) bluntly ignores the type
and tries to open anything.

> - AFAIK, Macintosh doesn't really store "file type" but rather "which
> application is this file associated with". So if you have multiple
> programs that deal with the same file type, the file has to be
> associated with *exactly one* application. (not sure about this)
> 
It stores 'type' and 'creator'. Creator is the default application.

> - just curious: what other times do you need to change this file type?
>
Seldom, but the one problem is sufficiently ennerving.

[...]
> 
> I am not proposing any "click it and wait for the magic" type think
> here, that was more related to the binfmt_misc proposal, where executing
> a file would automatically open the file with the correct program.

Sorry, then. I understood it that way.

> However, this is already done with WWW, and I don't see any problems
> there (except misconfigured MIME types on some servers - something
> that would benifit from my proposal, at least for HTTP).
> 
The problem I see is that the same file can be a lot of different things
at the same time. Take a C header file. Sometimes you want it to be a
text file. Sometimes you want it to be a C header file (I know I can say
text/C-header which makes MIME better than MacOS, but read on). Sometimes
you want it to be a C++ header file. Perhaps it is also an icon saved by
a program that chose to save icons so that they can be easily included as
arrays into C programs. To make things even more amusing the file could be
gzipped.

So there may be moments the MIME type won't do the right things for you. I
admit it DOES very often. Just carry a MIME type with the file is, of
course, no problem.
If it is used to determine possible actions on a file, it may get in your
way. If Netscape or pine or something won't do the right thing, I can go
and save the file and do with it whatever I want. If my OS starts do do
the same strange stuff as Netscape, I have to start kinda hacking until it
doesn't.
If the type is never used, what's it good for? It makes life easier for
Apache, OK.


Yours,

Bj"orn Brill <[EMAIL PROTECTED]>
Frankfurt am Main, Germany


P.S.: I hope you did not feel offended by my previous posting, as that was
not my intention. I just wanted to report some non-Linux experience on
problems caused by the (too?) systematic use of a system similar to MIME.

Re: upgrade nightmare from slink to potato

[Bjoern Brill]

Marc Haber wrote:

>Hi!
>
>
>After having worked with potato at the office for a few weeks now,
>I decided to upgrade my slink box at home. I pulled the CD images made by
>Andreas Jellinghaus and started. I had apt-0.3.13 on my slink box, so I
>decided to use the apt-cdrom way.

[...]

>I now have a system that doesn't know its cursor keys, that complains
>about locale errors all the time and can't be logged in to via the
>network.
>
>Does anybody have any ideas to solve this situation?
>

I did (well, had to do - the latest slink apt segfaults on the machine) a
m68k slink2potato upgrade with dselects ftp method. It required a few
dpkg --force-depends, too (yes, glibc, perl, etc.), but completed
successfully after several passes of install, configure. This may also
work for you (you would want to use the multicd method, of course). If you
see the same dependency problem come up several times in a pass or stay
several passes, upgrade the required package (and its dependencies)
manually before starting the next pass.

I also had to forcibly reinstall with dpkg some "severly broken" packages,
but I think this was only because I ran out of disk space in
mid-upgrade (aaargh!).

My original opinion about apt segfaulting was "bad luck", but after
reading your mail I'm not so sure any more. However, I was impressed by
dpkg's abilities to get all that mess repaired with a little help from the
user.


Regards,

Bjoern Brill

--
Bj"orn Brill <[EMAIL PROTECTED]>
Frankfurt am Main, Germany

Re: Too many kernels in unstable

[Bjoern Brill]

On Fri, 17 Sep 1999, Brian Mays wrote:

> Perhaps we should keep the last two versions of each branch?  In this
> case, 2.0.35, 2.0.36, 2.2.10, and 2.2.12 (which is in Incoming).  I
> don't know.  Let's see whether anyone objects to just keeping two
> versions around.

That seems reasonable. Once the 2.0.x kernels finally are obsoleted, there
may be three 2.2.x kernels.

Bj"orn Brill <[EMAIL PROTECTED]>
Frankfurt am Main, Germany

Re: A few changes

[Bjoern Brill]

On Sat, 18 Sep 1999, Darren Benham wrote:

> Bugs are no longer deleted!!!  We don't have a way for you to access them
> directly but there's an "official" location in the database where they're
> being archived.  We're trying to decide how to serve them up... by
> requesting a bug number, obviously, but any other way?  Do we need them
> index by maintainer or package?  Remember, these are closed -- solved --
> bugs.

The "correct" and usual thing to do when finding a bug is to look into the
BTS to see if it has already been filed or even dealt with. Now remember a
lot of Debian users live off stable from CD. Considering the time between
to stable releases, chances are high someone "discovers" a bug long after
it has been closed (because he's installing a previously unused package).
The person will then be disappointed (because Debian doesnt't handle
rather obvious bugs) and/or file it again.

Conclusion: make closed bugs available by package. The original bug
report and the closing message should be sufficient.

Bj"orn Brill <[EMAIL PROTECTED]>
Frankfurt am Main, Germany

grep-ing available made easy

[Bjoern Brill]

Hello,

I have just finished the first 90% (that is, I have a decently working
beta version, but some things are still suboptimal) of something that
could be vaguely described as

Package: debcrawler
Section: admin
Priority: optional
Version: 0.19
Depends: boa | httpd, lynx | www-browser, dpkg (>= 1.4), dpkg (<< 1.5)
Description: browse your Debian binary packages via WWW
 debCrawler (completely unrelated to a well-known web indexing service)
 is a small tool to search the local database of installable Debian
 *.deb software packages for various criteria and display the
 results through a web browser. It does not attempt to cover package
 management. The output is formatted in a fashion that aims at readability
 on several different web browsers, including lynx.
 .
 debCrawler is a CGI application, so a http daemon with CGI support
 must be set up on the local machine. Note that dhttpd does *not* support
 CGIs (that means you have to use another httpd implementation).


It was inspired by hours of screen-staring in front of dselect,
some grep/sed/perl orgies with "available" and, of course,
.

I'd be glad if some of you would try it and send me comments and bugs.
I'd be even more glad if somebody could package it (I am no Debian
developer yet, there are some technical problems, and I don't have the
time to overcome any of these two obstacles at the moment).

You can get it at

 
 

Thanks
 

Bj"orn Brill <[EMAIL PROTECTED]>
Frankfurt am Main, Germany