Debian GNU/Linux autoconf marked 2.13 is *not* 2.13--fix uploaded.

[Ben Pfaff]

Due to a small bug in either autoconf or my build scripts, depending
on how you look at it, the Debian GNU/Linux autoconf package version
2.13-1 is actually not autoconf 2.13, it is an older CVS version.  I
have now uploaded a new, fixed version 2.13-2.  It should be available
on all Debian mirrors within a day or two.

This message is directed to autoconf@gnu.org since I've seen a number
of bugs reported against 2.13 sent to this list, when in fact they are
probably applicable to only my Debian package, not to the upstream
sources.  Those who have reported bugs against upstream autoconf by
considering only the Debian package should check whether the bugs are
still exhibited in 2.13-2.

Now, for the bug: the distclean target in the Makefile for autoconf
doesn't delete the .m4f files, which means that blindly applying the
diffs made against an older version of autoconf to a newer version
won't necessarily rebuild the .m4f files, which means that an older
version of autoconf will essentially be installed.  This is what
happened to me.

Suggested fix:

--- autoconf-2.13/Makefile.in~  Tue Jan  5 08:27:16 1999
+++ autoconf-2.13/Makefile.in   Wed Jan 20 18:52:25 1999
@@ -206,7 +206,7 @@
rm -f *.ev *.evs *.ov *.ovs *.cv *.cvs *.ma *.mas
 
 distclean maintainer-clean::
-   rm -f Makefile config.status config.cache config.log
+   rm -f $(M4FROZEN) Makefile config.status config.cache config.log
 
 TAGS:
etags ${srcdir}/*.m4 ${srcdir}/*.sh ${srcdir}/[a-z]*.in ${srcdir}/*.texi

how rpm does it (Re: Dpkg Update Proposal)

[Joey Hess]

As I said before, rpm does have the capability to install 2 different
versions of a package simulantaneously. Here's how it works, to the best of
my knowledge.

User interface:

Rpm differentiates between installing a package and upgrading a package.

Installing a package (rpm -i) simply unpacks the rpm file, registers it in
the database of installed packages, etc. If an old version of the package is
present, it will not be removed.

Upgrading a package (rpm -u) means that the old version of the package that
was installed (if any) is removed at the same time the new one is installed.

So rpm's method of upgrading is the same as dpkg -i, whereas dpkg has nothing
equivilant to rpm's method of just installing a package. 

Oh and by the way, this user interface tends to confuse new users (at least
it did me) who accidentially install many versions of the same package
because they arn't aware they should be upgrading it instead.

I forget how rpm allows removing of one version of a package while leaving
another version of it installed.

Back end:

I don't know much about this. I can intuit some things.

Rpm can keep track of multiple versions of the same package that are all
installed. Presumably, this means its package database indexes the installed
packages by both package name and version, instead of just by package name
as dpkg does.

What happens if you try to install version bar of a package while version
foo of that same package, which contains files of the same name, is
installed? Rpm will happily overwrite version foo's files.

What happens if you then remove version foo? I'm not sure, it's been a while
;-). I can say that rpm doesn't deal with this very well. It either has to
leave version bar's files around, or delete them, either action leaves the
installed version foo in an inconsitent state.

Given the above, it's clear that rpm's method of doing this is really only
useful for library packages, in which 2 different versions contain files
with entirely different names. (You might ask, what about /usr/doc, wouldn't
it be the same in both versions of a library package. The answer is that rpm
packages use /usr/doc/package-version/ as the doc directory.) But it does
work tolerably well for those library packages. Of course, if redhat had
anything like update-alternatives, it could be more useful for other
packages too.

Applying this to dpkg:

User interface: 

If we wanted to make dpkg have this capability, we could add a new command
line flag, say "--keep-old-version" that makes "dpkg --keep-old-version -i"
behave like rpm -i does.

We would have to come up with some method to allow dpkg to remove one
version of a package while leaving another version of that package installed.

Back end:

Dpkg would have to change how it parses the status file, and presumably how
it stores the information about installed packages in memory, so it in
effect considers different versions of a package as different packages, if
--keep-old-version were passed to it.

Dpkg already doesn't allow 2 packages to be installed that contain the same
files (unless --force-overwrite is on), so it doesn't run into the problem
rpm runs into with installing multiple versions of a package that contain
the same files. (Or does it? The same issues seem to apply with
--force-overwrite. But I guess dpkg does the Right Thing, whatever that is.
;-)

Applying this to deb packages:

For library packages, which contain different files from version to version,
we really need do nothing special.

For packages like ncftp and ncftp2, update-alternatives can be used (as it
is now) to ensure that the 2 packages contain only differnet files.

However, both these cases do leave us with the problem of
/usr/doc/. We would have to either change that to
/usr/doc/package- for those packages, or come up with some other
solution.

Some things I haven't dealt with:

Apt would probably need to be made smart enough to figure out when it needs
to tell dpkg to --keep-old-version a package. The dselect user interface
would probably need modifications both so it can display multiple versions
of a package that are all installed, and so it can allow users to change
which versions are installed. The ftp site would probably need some major
changes made to it to allow mutliple packages with the same name to be on it.

-- 
see shy jo

Re: Debian goes big business?

[Adam Di Carlo]

On Wed, 20 Jan 1999 10:08:53 -0600 (CST), "Eric Gillespie, Jr." <[EMAIL 
PROTECTED]> said:
> I wouldn't mind it if everyone disagreed with what I'm saying. But
> it seems as if no one even understands what I'm saying.

Sorry about the plug for my own company in my last message.  However,
I think I do know what you want.  Personally, I'd rather use the
existing framework of SPI, and focus on increasing revenue so that
Debian can start funding developers (i.e., hardware for porters or
mirrors, then maybe growing to a small salary for core people like FTP
archive maintainers, the security team, release managers).

--
.Adam Di [EMAIL PROTECTED]http://www.onShore.com/>

Re: Debian goes big business?

[Adam Di Carlo]

On 19 Jan 1999 16:55:29 -0600, John Hasler <[EMAIL PROTECTED]> said:
> Shawn writes:
>> I am all for a for-profit business forming as a value-added seller
>> of Debian products. Such a business could focus on
>> pre-installations, packaging and marketing, and user support.

> Exactly!  This is just the sort of company I would love to
> participate in.

> I have cross-posted this to debian-devel.

onShore, Inc., my company, (not yet listed on the consultants page --
too busy with work and Slink right now) sells bundled GNU/Debian
systems, including hardware and support.  We are resellers for most
major manufacturers.  We're basically a consulting company (business
to business), not an ISP or box pusher.  We also do a lot of
open-source development and the like.  FWIW, I'm actually starting a
push right now to offer bundled Debian/Sparc boxes, since we're also
Sun resellers, and since the Sparc architecture has a lower TCO and
scales better than x86.

We operate out of Chicago and NYC (312 850-5200 and 212 254-0063).

--
.Adam Di [EMAIL PROTECTED]http://www.onShore.com/>

Re: possible debian cluster

[Mitch Blevins]

On debian-devel, Barak Pearlmutter wrote:
> It looks like a big Linux Beowulf cluster kind of thing is going to be
> built here at UNM.  Hundreds of CPUs, at least.  I'd like to convince
> them to use Debian and 21264s, but that's up in the air.  One big
> issue is finding someone good who could be in charge of systems
> software for the beast.
> 
> So, if some Debian developer is
>  - competent to handle the networking setup & benchmarking, PVM, etc
>  - potentially desirous of a job doing said
>  - in Albuquerque New Mexico
> please drop me a line, as it might result in (1) a job, and (2) a big
> cluster running Debian.
> 
> BTW, a cluster of 256 dual-CPU 21264s with a fast disk farm all
> connected to the national high-speed supercomputer networks could
> recompile a lot of packages quite quickly.

Hi Barak,

Although I don't have any experience setting up a large cluster, I'm
handy with setup and benchmarking, and could be willing to come help
out gratis.

I am a contract administrator and usually work 9-12 month contracts
(currently in Florida).  My contract will be ending Feb 18 and I was
planning on taking some time off for rest and relaxation.  It just happens
that I think I would find setting up a large Debian cluster both resting
and relaxing!

So, if you need some help for a few days to a couple of weeks, and you plan
on doing this late Feb or early March, I would love to come down and help
out whoever you get to lead this.

Mitch Blevins
[EMAIL PROTECTED]

Re: Debian goes big business?

[Andrew Martin Adrian Cater]

On Wed, Jan 20, 1999 at 12:47:52PM -0500, Harrison, Shawn wrote:
> So that's what I think we should focus on. -- What is the best way to get 
> Debian out to the world?
> 
> ==
> [EMAIL PROTECTED] 
> ==
> 
> 
> 
> -- 
> Unsubscribe?  mail -s unsubscribe [EMAIL PROTECTED] < /dev/null
> 
Install it at your workplace, tell people, support new users - every time
one of my colleagues wants a "Linux box" I build them a Debian disk.  If
you _really_ want to get Debian out into the world:

The floppy install takes eight 3.5" floppies: include a lowmem disk and a 
disk of instructions.  That makes 10: if every developer were to buy a 
box of disks, format them and copy the floppy images then send them to
someone - thats 300+ people with a minimal distribution at a couple of US$
cost.

Beg/borrow a CD copier: copy up to date CD's at a nominal cost: distribute
them. [Can we do this for one developer from each country to ease the
problem of net download costs ??]

Stress the security and upgradeability of Debian: install RedHat and
ask people to upgrade - then show them Debian with APT

Just my 0.02 Euro

Andy

Re: Debian goes big business?

[Ben Pfaff]

Laurent Martelli <[EMAIL PROTECTED]> writes:

   > "ChL" == Christian Lavoie <[EMAIL PROTECTED]> writes:

   ChL> Bottom line: Debian should remain developer controlled.

   What about non-developper users ? Shouldn't they have a word to say,
   even if they can't or do not have the time to contribute with code ? 

They should have `a word to say', and they do--they can subscribe to
Debian lists and give their feedback and advice, which developers are
free to follow or ignore.  But they do not, and should not, IMO, have
the privilege of voting or otherwise setting policy.  Users are not
developers and shouldn't presume to be.

Re: libpam, cracklib, and slink (was Re: Release-critical...)

[Joel Klecker]

At 4:53 PM -0500 1/20/99, Ben Collins wrote:
Ok, after looking at this, I've decided that the cracklib support for
PAM would be best handled by having it in a seperate package. I want to
propose a naming scheme for module packages for PAM similar to how
apache modules are named, libpam-mod-foo, where foo is the module name.
Using this scheme the cracklib PAM module package will be named
libpam-mod-cracklib, and this package will contain the Depends for
cracklib.
source I have to 0.66, which will be in my first upload pending
comments concerning this proposed naming scheme (i hope no one has any
objections :)
I object to the the 'mod', it amounts to saying "Pluggable 
AUthentication Module module"[1]. You are using apache as an example, 
apache's modules are usually named 'mod_foo', so `libapache-mod-foo' 
is logical as a package name. I don't think that holds for PAM.

NOTE: This naming scheme will reuire the ppp-pam package to be renamed,
any problems with this?
Uh why? `ppp-pam' is simply `ppp' with PAM support.
[1] Stamp out and eliminate redundancy! ;-)
--
Joel Klecker (aka Espy) http://web.espy.org/>
mailto:[EMAIL PROTECTED]>  mailto:[EMAIL PROTECTED]>
Debian GNU/Linux PowerPC -- http://www.debian.org/ports/powerpc/>

Re: Dpkg Update Proposal

[Joey Hess]

Manoj Srivastava wrote:
>   What exactly are you attempting to solve here that has not
>  already been solved?

He's trying to solve the fact that we have package names like "libgtk1.1.11"
and "slang0.99.38".

>   Why do CVS based packages need a special name? I am missing
>  something here. Do you mean we need a versioning scheme for daily
>  snapshots? That has already been discussed, and there was a consensus
>  about it, and that was to use versioning of the form MMDD as the
>  snapshot version.

I think the CVS stuff is a bit of a red herring. He probably meant snapshot
versions. Note that the version number isn't what he's talking about; he's
talking about the package name.

-- 
see shy jo

Re: Debian goes big business?

[Laurent Martelli]

> "ChL" == Christian Lavoie <[EMAIL PROTECTED]> writes:

ChL> Bottom line: Debian should remain developer controlled.

What about non-developper users ? Shouldn't they have a word to say,
even if they can't or do not have the time to contribute with code ? 

Laurent

Re: texinfo and texi2* in tetex-bin?

[Julian Gilbey]

> > >Oh boy! Cammon! Now I need to install 25M (tetex-bin~=10 +
> > >tetex-base~=15) just to compile texi files into html or info?
> > 
> > Uhh, not "now", makeinfo and texi2html in tetex-bin is not a new 
> > development, it's been that way since at least bo, IIRC.
> 
> I know. Doesn't make it any better. :-)
> 
> > >I really think we should continue to provide separate "texinfo"
> > >and "texi2html" packages at least.

How about having a texinfo package which provides the texi2html,
makeinfo etc. binaries, and have texinfo Conflict: tetex-bin,
and have tetex-bin Provide: texinfo.  Seems like it should work.

   Julian

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

Julian Gilbey Email: [EMAIL PROTECTED]
   Dept of Mathematical Sciences, Queen Mary & Westfield College,
  Mile End Road, London E1 4NS, ENGLAND
  -*- Finger [EMAIL PROTECTED] for my PGP public key. -*-

Re: Dpkg Update Proposal

[Manoj Srivastava]

Hi,

>>"fantumn" == fantumn \(Steven Baker\)  writes:

What is wrong with cvs-buildpackage? I maintain all my
 packages in CVS, and there is a well defined version based
 tagging scheme.

What exactly are you attempting to solve here that has not
 already been solved?

 fantumn>   CVS is becoming an increasingly important part of the
 fantumn> daily life for many free software projects (Gnome, Mozilla
 fantumn> and Berlin come to mind), yet there is no defined way to
 fantumn> name a CVS package.

Why do CVS based packages need a special name? I am missing
 something here. Do you mean we need a versioning scheme for daily
 snapshots? That has already been discussed, and there was a consensus
 about it, and that was to use versioning of the form MMDD as the
 snapshot version.

 fantumn> Perhaps we can take the easy way out, and not package
 fantumn> programs from CVS, but what would us Enlightenment users do
 fantumn> without CVS versions?  Enlightenment has not had a new
 fantumn> version since 0.14 which was way back this past summer, and
 fantumn> it is severely feature-deprived (no iconization, for
 fantumn> instance).  The current Enlightenment maintainer, Brian
 fantumn> Almeida, has come up with a wonderful solution for this.  He
 fantumn> calles all stable versions of Enlightenment simply
 fantumn> enlightenment, and CVS versions enlightenment-cvs.  He has
 fantumn> fixed it further, by making enlightenment-cvs conflict with
 fantumn> enlightenment.  Perhaps there are more examples.

 fantumn>   Personally, I think Brian's solution to the CVS problem is
 fantumn> the perfect fix, but perhaps there is room in the Debian
 fantumn> package format for a CVS version numbering.

I fail to see why we have to invent a bureaucratic scheme for
 something we have absolutely no need to regulate, if you are talking
 about renaming or renumbering a package just because it is in CVS. If
 you are talking about snapshot versions, please look at the archives
 of the -policy list.

manoj
-- 
 Fashions have done more harm than revolutions. Victor Hugo
Manoj Srivastava <[EMAIL PROTECTED]>
Key C7261095 fingerprint = CB D9 F4 12 68 07 E4 05  CC 2D 27 12 1D F5 E8 6E

Re: Bug#27050 (fdutils): A cause for security concern?

[Avery Pennarun]

On Tue, Jan 19, 1999 at 08:56:11PM -0600, John Hasler wrote:

> Avery Pennarun wrote:
> > When the docs for a setuid program warn you "not to trust its security"
> > then be afraid, be very afraid.  It shouldn't be automatically setuid in
> > Debian until _some_ security-conscious person has audited it carefully.
> 
> Would you say the same of daemons that run as root?

Coming from you, that sounds like a trick question.  Okay, I volunteer to be
tricked: yes, daemons should not run as root (especially network servers)
unless they've been looked over by some security-competent person, and only
if they actually NEED to run as root!

I don't know its current status, but I submitted a bug against socks4-server
a while ago because it was running as root for no reason at all -- it works
fine when running as "nobody."

Setuid programs are actually more dangerous than daemons, though -- the
non-root user has more complete control over their execution environment, so
there are more types of security holes.  For example, you can change the
PATH environment variable and shell strings (eg. IFS, HOME, etc) so using
the system() and execvp() system calls is generally dangerous in a setuid
program, but often not so bad in a daemon.

Have fun,

Avery

possible debian cluster

[Barak Pearlmutter]

It looks like a big Linux Beowulf cluster kind of thing is going to be
built here at UNM.  Hundreds of CPUs, at least.  I'd like to convince
them to use Debian and 21264s, but that's up in the air.  One big
issue is finding someone good who could be in charge of systems
software for the beast.

So, if some Debian developer is
 - competent to handle the networking setup & benchmarking, PVM, etc
 - potentially desirous of a job doing said
 - in Albuquerque New Mexico
please drop me a line, as it might result in (1) a job, and (2) a big
cluster running Debian.

BTW, a cluster of 256 dual-CPU 21264s with a fast disk farm all
connected to the national high-speed supercomputer networks could
recompile a lot of packages quite quickly.
--
Barak A. Pearlmutter <[EMAIL PROTECTED]>, http://www.cs.unm.edu/~bap/

Re: Debian v2.1 ("Slink") Deep Freeze

[Steve Dunham]

Brian White <[EMAIL PROTECTED]> writes:

> pilot-link31806  pilot-link: Can't build from source

This bug was filed against the 0.9.0 package and the 0.8.11 package is
installed in slink. 


Steve
[EMAIL PROTECTED]

Re: agreeing with the DFSG (was Re: non-free --> non-dfsg)

[David Welton]

On Thu, Jan 21, 1999 at 09:01:38AM +1100, Craig Sanders wrote:
> what this means is that less than a quarter of developers care enough
> about specific issues to argue it or vote about it. that's no surprise,
> most developers have time to work on one or two (or a dozen or more)
> packages but are not at all interested in the political bullshit.
   ^^^
That's me:->

Regarding this issue - look, it is the Debian FREE Software
guidelines, not the Debian DFSG Guidelines...  If someone is offended
by this, they are too thin skinned anyway.  There are a lot of things
Debian needs - another flamewar on another silly issue isn't one of
them.  Go write some code.

-- 
David Welton  http://www.efn.org/~davidw 

Debian GNU/Linux - www.debian.org

Re: agreeing with the DFSG (was Re: non-free --> non-dfsg)

[Craig Sanders]

On Wed, Jan 20, 1999 at 02:32:45AM -0600, Ossama Othman wrote:
> > > The fact that my opinions go against what is apparently the Debian
> > > mainstream way of thinking doesn't mean that I should leave.
> >
> > however, if (after you have had your say) the majority of developers
> > think you are wrong and the vote goes against you then you should
> > either a) shut up about it for a reasonable period of time - several
> > months at least, or b) voluntary leave if you can't do (a).
>
> I'd agree with you more about this if more developers were more vocal
> about how they feel.  Right now less then a quarter of the developers
> seem to express their opinion or even vote (someone correct me if I am
> wrong).

what this means is that less than a quarter of developers care enough
about specific issues to argue it or vote about it. that's no surprise,
most developers have time to work on one or two (or a dozen or more)
packages but are not at all interested in the political bullshit.


ignore the "silent majority" (and especially ignore anyone claiming to
represent them). this is as important in debian as it is in the real
world.

in debian, the silent majority have their opportunity to debate issues
just like anyone else. they have their opportunity to vote.

if they choose not to debate or vote, then they either don't care or
are just wishing people would stop crapping on and wasting everyone's
time. or something else.

but whatever it is they think is irrelevant - an abstain vote is neither
for or against...it is not counted at all.

craig

ps: debian-devel isn't a philosophy debating society.

--
craig sanders

Re: libpam, cracklib, and slink (was Re: Release-critical...)

[Ben Collins]

Ok, after looking at this, I've decided that the cracklib support for
PAM would be best handled by having it in a seperate package. I want to
propose a naming scheme for module packages for PAM similar to how
apache modules are named, libpam-mod-foo, where foo is the module name.
Using this scheme the cracklib PAM module package will be named
libpam-mod-cracklib, and this package will contain the Depends for
cracklib.

This scheme will also allow me to include other modules so we can get
PAM enabled in the best way possible for potato. I've also upgraded the
source I have to 0.66, which will be in my first upload pending
comments concerning this proposed naming scheme (i hope no one has any
objections :)

NOTE: This naming scheme will reuire the ppp-pam package to be renamed,
any problems with this?

--
--- -  -   ---  -  - - ---   
Ben Collins <[EMAIL PROTECTED]>  Debian GNU/Linux
UnixGroup Admin - Jordan Systems Inc. [EMAIL PROTECTED]
-- -- - - - ---   --- -- The Choice of the GNU Generation

Dpkg Update Proposal

[fantumn \(Steven Baker\)]

Okay, I posted to -devel a few weeks back with a proposal for an update to dpkg.
This message is being Cc'd to -devel, and sent to -dpkg.

  Basically, attached is my proposal (it's long, I'm trimming it down in another
rxvt, but, I wanted to get something out for the firing sqaud).  Please read it,
and reply with questions, complaints, comments, suggestions, etc.  Please don't
scorch me.  If I want to be flamed, I'll post "RedHat sucks, Slackware is cool
and btw: KDE rocks" to Slashdot.
  Any flames can be sent to /dev/null.  Please just constructive stuff here.
I'd like someone with superior authority on dpkg, (Ian Jackson?) to also take
extra look at this.

  In a nutshell, my proposal outlines the weirdness of package names
(libgtk1.1.13, svgalibg1, imlib, etc -- to name a few), and how to fix them, and
the possible problems it would cause.

Please, feel free to add to this.

  Also, note that there is no code done as of _yet_, I want to take everything
into consideration first, but I have done a bit of research on dpkg to make sure
that this will work, and have considerable experience developing package
management systems (a lot of the SLP-0.90 code is derieved from my own), and I
have written up to and more than 80% of three different package managers, all
of which I discontinued after switching to _the_ real distribution.

-fantumn


Package Naming Scheme
---
  The current naming scheme of many packages is a mess, to say the leasy.  This,
of course applies almost exclusively applies to libraries, but there are some
other packages that could use some help (Electric Eyes, and Easy Editor come to
mind).
  The problem is inconsistency.  Some package names, speaking about libraries
here, are prefixed with the word 'lib', as in libgtk, and some are not, as in
Imlib.  Now, I realize that this should be the case sometimes, as in libjpeg,
libtiff, etc (those are the proper names for those packages), and, libImlib
would sound funny.  Some packages contain a little g, such as zlib1g, to show
that the package is compiled for Glibc2.  However, not _all_ glibc2 packages
have this little g (imlib and fnlib come to mind).  Since libc5 exists for the
most part only in the hearts of the Slackware users, this 'g' thing can be
dropped.
  Another problem with this is that many packages comtain a number on the end,
so that different versions of the library can be installed (I assume), but that,
also is not consistent.  For instance, freetype has two packages, freetype1 and
freetype2, where do the 1 and 2 come from?  What significance do they have?
With a simple patch to dpkg (more details below), this could be fixed.
  The other inconsistency problem, is that even though many packages have a
number, and the letter 'g', that is still not consistent.  What order do they go
in?  SVGALib has svgalibg1, and zlib uses zlib1g.  Even more confusing is the
way gtk is named.  libgtk1.1.12 is the latest, at time of writing.  It was
always libgtk1, then libgtk1.1, then because the GTK developers break every
previous release with every new one, it had to start getting full version
numbers, as does the kernel package (kernel-image-2.0.36).

CVS
-
  CVS is becoming an increasingly important part of the daily life for many free
software projects (Gnome, Mozilla and Berlin come to mind), yet there is no
defined way to name a CVS package.  Perhaps we can take the easy way out, and
not package programs from CVS, but what would us Enlightenment users do without
CVS versions?  Enlightenment has not had a new version since 0.14 which was way
back this past summer, and it is severely feature-deprived (no iconization, for
instance).  The current Enlightenment maintainer, Brian Almeida, has come up
with a wonderful solution for this.  He calles all stable versions of
Enlightenment simply enlightenment, and CVS versions enlightenment-cvs.  He has
fixed it further, by making enlightenment-cvs conflict with enlightenment.
Perhaps there are more examples.
  Personally, I think Brian's solution to the CVS problem is the perfect fix,
but perhaps there is room in the Debian package format for a CVS version
numbering.

Fixing All of this...
---
  Of course, to save being scorched, I have to include some solutions to the
problems outlined above.  And, again to save being further scorched, I have to
provide _good_ solutions to these problems.
  My solution, after long thought and working out, is to simply modify the
Debian Package Management system to allow multiple versions of packages to be
installed.  (Keep reading, before anyone jumps to conclusions)  This simple fix
would not severly break the current package management system, and would require
only that people upgrade to the new version of dpkg (which would be simple, if
we just include the patched up version in potato...  everyone that upgrades to
potato gets the new dpkg).  

Re: Where does 'www-data' come from?

[Edward Betts]

On Wed, 20 Jan, 1999, Brian May wrote:
> Maybe the web files should be owned by "www-data" and the web
> process should be owned by "www" or "httpd"? This way the
> descriptive names continue to make sense. Practical
> speaking, it is probably just as good to make web files
> owned by root, however, then the name "www-data" won't
> be the owner of any data.

Would not work, the users on my machine who are aloud to edit the web pages
are members of the www-data group, do you suggest I make them members of root?

-- 
GNU does not eliminate all the world's problems, only some of them.
-- The GNU Manifesto

Re: Intent to package cygnus-stylesheets

[Adam Di Carlo]

On Tue, 19 Jan 1999 04:52:44 -0500, Adam Di Carlo <[EMAIL PROTECTED]> said:
> After comparing the sources closely, I don't think they have forked
> the sources.  All the diffs in the *actual* stylesheets are either
> CVS stuff changing, since they reimported norm's stuff, or
> side-effects based on the fact that they regenerate the
> documentation.

I lied, there's about 20 lines of difference in the Cygnus version.  I
basically just ignored this for the -1 verision.

> I'll try to upload my deb within 48 hours, ok?

Uploaded, and tested with some of my own docbook sgml stuff.  Someone
who requires db2html etc should test these though.  And yes, I'm still
morally offended by the db2* scripts.  Icky.

--
.Adam Di [EMAIL PROTECTED]http://www.onShore.com/>

Re: Dpkg Update Proposal

[Joey Hess]

fantumn Steven Baker" wrote:
> have this little g (imlib and fnlib come to mind).  Since libc5 exists for the
> most part only in the hearts of the Slackware users, this 'g' thing can be
> dropped.

No it can't. Please consider backwards compatability.

>   Another problem with this is that many packages comtain a number on the end,
> so that different versions of the library can be installed (I assume), but 
> that,
> also is not consistent.  For instance, freetype has two packages, freetype1 
> and
> freetype2, where do the 1 and 2 come from?  What significance do they have?

Library sonames.

>   My solution, after long thought and working out, is to simply modify the
> Debian Package Management system to allow multiple versions of packages to be
> installed.

This is actually a good idea. RPM manages to do this and it does make their
package names simpler and it actually seems to work (though I'm not sure how).

Can you provide some techincal details about how this will work?

-- 
see shy jo

Re: cracklib-runtime NMU

[James Troup]

Wichert Akkerman <[EMAIL PROTECTED]> writes:

> Previously Jean Pierre LeJacq wrote:
> > As I mentioned in an earlier posting, there's no reason for this bug
> > to be release-critical.
> 
> This is another bug. Not being able to compile a package at all *is*
> a release-critical problem and violates the GPL.

Except of course the package isn't under the GPL...

Not being compilable from source *is* a release critical bug because
there are 3 architectures other than i386 releasing, and if the
package can't be compiled from source, those other 3 architectures are
screwed.

I've been meaning to mark all problems with building source packages
(that I find on m68k) for frozen as release critical for a long time
actually, I just keep forgetting.

-- 
James

Re: Where does 'www-data' come from?

[Oliver Elphick]

Edward Betts wrote:
  >On Wed, 20 Jan, 1999, Brian May wrote:
  >> Maybe the web files should be owned by "www-data" and the web
  >> process should be owned by "www" or "httpd"? This way the
  >> descriptive names continue to make sense. Practical
  >> speaking, it is probably just as good to make web files
  >> owned by root, however, then the name "www-data" won't
  >> be the owner of any data.
  >
  >Would not work, the users on my machine who are aloud to edit the web pages
  >are members of the www-data group, do you suggest I make them members of roo
  >t?
Have PostgreSQL tables accessible by the *PostgreSQL* user `nobody', and have
the web server connect to PostgreSQL as `nobody'.  (PostgreSQL users are not
(necessarily) the same as Unix logins.)

More detailed documentation for this problem is available on the bug database
for the postgresql package.

-- 
Oliver Elphick[EMAIL PROTECTED]
Isle of Wight  http://www.lfix.co.uk/oliver
   PGP key from public servers; key ID 32B8FAA1
 
 "Neither is there salvation in any other; for there is 
  none other name under heaven given among men, whereby 
  we must be saved."   Acts 4:12 

Re: Unmet Deps revisted

[Edward Betts]

On Wed, 20 Jan, 1999, Steve McIntyre wrote:
> >When selecting all packages of a certain priority there should be no
> >conflicts.  If there are two MTA's, then one is optional, the other is
> >extra.  I'm sure this is written down in one of our many policy, develop.
> >ref, packaging manuals.
> 
> So how does this work if we get lots of (using the same example) different
> MTAs? We get one in optional, one in extra, then where do the others go?

exim in IMPORTANT, and sendmail, smail, vmailer, etc in EXTRA no MTAs in
OPTIONAL.

-- 
GNU does not eliminate all the world's problems, only some of them.
-- The GNU Manifesto

Follow-up

[fantumn \(Steven Baker\)]

  Further versions of this proposal will be posted on the WWW, and the address
of such revisions will be posted to both -devel and -dpkg.

Re: packages.debian.org

[Edward Betts]

On Wed, 20 Jan, 1999, [EMAIL PROTECTED] wrote:
> Given that from your description swish++ sounds like a general purpose
> indexer, which has been set up to index 'natural language' is it the best one
> for our purposes?

The main thing is it is free software, most search engines are not.

> 
> If the aim is simply to build an index of package names to web pages, I would
> have thought that a different tool would be more appropriate - indeed, with
> perl and the HTML parser module, it would be a short script.

ummm

-- 
GNU does not eliminate all the world's problems, only some of them.
-- The GNU Manifesto

Re: using TABS vs SPACES in E-Mail

[Edward Betts]

On Wed, 20 Jan, 1999, Brian May wrote:
> Just my 2 cents: I think using TABS is Ok (I personally do not
> know if any programs or OS that do not default to 8 characters),
> except it messes up the formatting when you quote the message
> in many mailers (eg pine, mh), using the Reply function.

\begin{Technical support}
Well it works on my machine (Mutt)
\end{Technical support}

> Personally, I think the best formating possible might be to MIME encode
> a text version *and* a HTML version (I think most mailers support MIME
> these days?), however, entering the message might be difficult with
> most mailers...
 _   _    
| \ | |/ __ \ 
|  \| | |  | |
| . ` | |  | |
| |\  | |__| |
|_| \_|\/ 
  
HTML in mails is bad, it is WRONG.

> Given that people won't change to HTML overnight (if at all), IMHO,
> any program that displays Mail using a proportional font is broken
> and should be fixed if tables are to work.
 
I recon that mailers should display in proportional but have AI that dectects
tables and ascii art and displays them in monospace. I believe compuserve once
worked like that in Windows.

-- 
GNU does not eliminate all the world's problems, only some of them.
-- The GNU Manifesto

Re: make mutt the `standard' mail reader

[Antti-Juhani Kaijanaho]

[RFC 822 says there's no net-wide standard HTAB size]

On Tue, Jan 19, 1999 at 04:09:01PM -0500, Avery Pennarun wrote:
> That's what makes it a "de-facto" standard.

No, that does not make it a standard of any kind - in fact, it
suggests that not even a de facto standard existed.  A de facto
standard is, by definition, a universally accepted convention which
does not have the weight of a de jure standard.  If a de facto,
network-wide definition for a tab size were available in the early
1980's, don't you thing the RFC 822 authors would have codified it in
RFC 822 as a part of the de jure standard?

The fact that they didn't, suggests that no de facto standard was
available.

> Unfortunately, no standards, even de-facto ones, are universally
> implemented because there are people who (often rightly) believe
> that they're junk.

Oh?  When there are true standards, either de facto or de jure,
usually /everyone/ who wants to interface with the universe implements
the standard.  However, if they think a standard is junk, they also
implement a better system, as an /alternative/ to the standard.

> Yay for ^H versus DEL :)

This is different.  ^H versus DEL has no relevance to the problem of
interfacing with the universe.  Tab size has, as this discussion
shows.



Antti-Juhani
-- 
%%% Antti-Juhani Kaijanaho % [EMAIL PROTECTED] % http://www.iki.fi/gaia/ %%%

EMACS, n.:   Emacs May Allow Customised Screwups
   (unknown origin)

Re: agreeing with the DFSG (was Re: non-free --> non-dfsg)

[Marcus Brinkmann]

On Wed, Jan 20, 1999 at 12:38:26PM -0600, Ossama Othman wrote:
> 
> It is amazing how people so are ready to snap at something that isn't as
> bad as they make it seem.  Please don't start quoting what I said.  I know
> what I said and I know what I meant.  You are taking what I said way out
> of context and taking it too literally.  Rather then ask me what exactly I
> meant you chose to lash out me.

You must have noted that I have not said anything about the current thread.
This was intentionally, I think all things have been said about it. It is
dead. What set me up was that you continue to talk about this issue without
making any new points, but rather stretching it in directions which have
nothing to do with the issue at hand anymore.

What you said was already out of context, which is the only point I wanted
to make. I understand what you meant, and I already wrote what I think about
it in prior mails.

Thanks,
Marcus


-- 
"Rhubarb is no Egyptian god."Debian GNU/Linuxfinger brinkmd@ 
Marcus Brinkmann   http://www.debian.orgmaster.debian.org
[EMAIL PROTECTED]for public  PGP Key
http://homepage.ruhr-uni-bochum.de/Marcus.Brinkmann/   PGP Key ID 36E7CD09

Re: register_frame_info troubles

[Michael Meskes]

On Tue, Jan 19, 1999 at 10:53:09AM -0600, Douglas Bates wrote:
> I have the same error message from lintian for the r-base package but
> am unable to find out why it occurs.  I tried checking for the name
> frameinfo in every library listed by ldd and I didn't find it.

Could it be you compiled your program with egcc? Then it is absolutely
normal to get these symbols. However, they are defined and lintian should
only check for undefined symbols.

Michael
-- 
Michael Meskes | Go SF 49ers!
Th.-Heuss-Str. 61, D-41812 Erkelenz| Go Rhein Fire!
Tel.: (+49) 2431/72651 | Use Debian GNU/Linux!
Email: [EMAIL PROTECTED]  | Use PostgreSQL!

Re: Where does 'www-data' come from?

[Johnie Ingram]

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

Steve> If you want to confuse operators and operands, you
Steve> deserve what you ask for, but no one would call this a bug in
Steve> bash (would they?).

I withdraw the --allow-badname suggestion then -- just wish this was
documented in README.Debian.  (I was granting to the group www-data
was also in, and so never came across the real problem.)

-  PGP  E4 70 6E 59 80 6A F5 78  63 32 BC FB 7A 08 53 4C
 
   __ _Debian GNU Johnie Ingram <[EMAIL PROTECTED]>  mm   mm
  / /(_)_ __  _   ___  __"netgod" irc.debian.org  mm mm
 / / | | '_ \| | | \ \/ / m m m
/ /__| | | | | |_| |>  <  Yes, I'm Linus, and I am your God. mm   mm
\/_|_| |_|\__,_/_/\_\   -- Linus, keynote address, Expo 98   GO BLUE

Re: Debian v2.1 ("Slink") Deep Freeze

[Santiago Vila]

On 19 Jan 1999, James Troup wrote:

> [...]
> We regularly do and have been clearing out
> release critical bugs against ftp.debian.org ever since the freeze.
>
> [The exceptions being certain ``release critical'' bugs filed by
> Santiago, [...]

Please do not confuse "release critical" with "severity: important" again.
It is up to the release manager to decide whether a certain bug
should delay the release or not.

When I file a "Severity: important" bug, I'm using the definition of
severity in the web bug pages: "bugs which makes the package unsuitable
for release". It is still my opinion that the great number of
package conflicts and wrong dependencies make the ftp.debian.org as a
whole unsuitable for release, but I will of course respect the opinion of
the ftp.debian.org maintainers on this.

> which I just ignored, and Richard finally demoted to normal,
> provoking the typical harassment from him.]

When Richard demoted some bugs to normal he said:

"It is much easier to fix them only in unstable."

At least, this is something to worry about.

Does this mean that the ftp.debian.org admins do not plan to fix any
other bug against ftp.debian.org (slink) before release unless it is
"severity: important" or higher?

I just hope that this is not the case.

-- 
 "e546319dc228b34135e7b0ee0ed73373" (a truly random sig)

Re: agreeing with the DFSG (was Re: non-free --> non-dfsg)

[Ossama Othman]

Hi Marcus,
 
> Hell, what are you TALKING about
>
> 
> Debian is a voluntary organization. If participation in the police state is
> voluntary, I don't care a penny if you can speak up or not, because I would
> not be there.
> 
> You are free to enter and to leave Debian. As long as you stay with Debian,
> you have to follow some rules and share some visions.
> 
> In all police states I know of, leaving is not as easy. Your "analogy" is
> not only inappropriate (as Debian is no "physical" thing like a country) but
> completely absurd and so far off topic, that I have to wonder if you had all
> your senses together writing this.

It is amazing how people so are ready to snap at something that isn't as
bad as they make it seem.  Please don't start quoting what I said.  I know
what I said and I know what I meant.  You are taking what I said way out
of context and taking it too literally.  Rather then ask me what exactly I
meant you chose to lash out me.

Come on guys, I may some things that seem way off base but I definitely
agree with the spirit of the DFSG, the Social Contract and the
Constitution.  I don't want to do a total rewrite of the DFSG or anything
close to that.  I started out with one suggestion that we change non-free
to some other name.  Good arguments were made against such a change.  I
suggested a compromise which seemed like a good one, or at least it wasn't
bad.  The fact of the matter is that I was convinced that changing
non-free may not be such a good thing to do.  Since then, I've been
arguing philosophical points since the thread went on.  However, they seem
to be taken too literally.  I didn't become a developer with my eyes
closed.  I was a debian user for some time prior to my becoming a
developer.  On top of that I followed most of the discussions on
debian-devel, so I was aware of what Debian was about.  Leaving Debian or
threatening to leave Debian are not at all things I was going to do.  In
general I am happy with Debian and its goals.

-Ossama

Re: non-free --> non-dfsg

[Dale Scheetz]

On Wed, 20 Jan 1999, Ossama Othman wrote:

> Hi Manoj,
> 
> >  Ossama> Looking at it from the author's point of view, the author may
> >  Ossama> feel that Debian's definition of "free" is wrong and his is
> >  Ossama> right.  So he may also think about Debian that "there is
> >  Ossama> indeed something wrong that they should know about."
> > 
> > This is all very interesting, and so on, but where is this
> >  leading? All kinds of people may have all kinds of opinion about
> >  Debian. The point is?
> 
> The point is that it easy to say "I am right and you are wrong."  Who
> makes us right and them wrong?
> 
Sorry to but in here, but there is something wrong with your argument.

This isn't a question of us being right, and them being wrong. The DFSG is
a definition of free software that Debian imposes upon itself, and only
itself. Validation of this definition can be infered from the fact that
the "Open Source" movement adopted it. Such validation doesn't imply that
all other points of view are wrong for those viewpoints, only for
Debian's POV.

The DFSG defines what Debian believes to be Free Software, and our most
recently approved Constitution defines how we have agreed to work together
as a group. These two documents (in association with the supporting Policy
documents) define the foundations of the development process and goals
within the Debian Organization.

It is hard for me to fathom how someone (with non-destructive goals) might
desire to contribute to a project with goals or principles that differ 
from their own. Debian has very specific, and sometimes unusual, goals.
It is not unreasonable that we make some effort to assure that new
developers understand, and agree with, those goals.

For Debian, the DFSG is "correct". There isn't an absolute correctness
anywhere in this belief. The fact that programs that don't satisfy those
Guidelines are excluded from the distribution is our right to exersize
that correctness. It imposes no larger "moral" judgement, although many
feel free to suggest that it does present a position so based.

>From the Debian point of view, I am free to distribute material that the
DFSG considers "non-free" without recrimination, and even with some praise
from my fellow developers. (referring to my book)

If I try to impose my version of sofware freedom by pushing for a change
in the DFSG, I find myself the first one to object! As a Debian developer
I fully support the DFSG and our social contract. As a free thinking
individual with my own expriences to draw from, I see points I would make
stronger and things that I might change because my personal goals are
broader that those of Debian. It is important that I distinguish between
what I do with Debian, from the other things that I do for Free Software,
and not try to impose tasks on Debian that I should perform elsewhere.

For these stated reasons, I am opposed to any fundamental changes in the
DFSG. If there are specific points that need to be clarified, then we need
to fix them. Just as with software, I'm not sure we squash the "bugs" in
the DFSG by trying to "re-write" it from the ground up. A discussion of
patches to the existing document seems more likely to "fix" anything that
is unclear, without giving up the ground already gained by the current
document.

Waiting is,

Dwarf
--
_-_-_-_-_-   Author of "The Debian Linux User's Guide"  _-_-_-_-_-_-

aka   Dale Scheetz   Phone:   1 (850) 656-9769
  Flexible Software  11000 McCrackin Road
  e-mail:  [EMAIL PROTECTED] Tallahassee, FL  32308

_-_-_-_-_-_- If you don't see what you want, just ask _-_-_-_-_-_-_-

Searching i386 binutils package 2.9.1.0.16-1 or earlier

[Matthias Klose]

I am looking for an i386 binutils package version 2.9.1.0.16-1 or
earlier. Please let me know if you still have such a package (binary
or source) or send me a location where I can find it. With the new
package I get warnings for every Objective-C program.

/usr/bin/ld: warning: type and size of dynamic symbol 
`__objc_class_name_NSString' are not defined
/usr/bin/ld: warning: type and size of dynamic symbol 
`__objc_class_name_NXConstantString' are not defined

Neither gobjc nor gstep-base-dev changed; so I assume it's binutils or 
libc6 which changed and caused these warnings.

Re: Bug#32156: anacron: It ran unnexpectedly!

[Shaleh]

No one ever picked up anacron.  I am doing so now.  I just purchased a laptop
and am going to use it as a mobile Debian development station.  once I get all
the bugs worked out in Debian I will work on anacron.  Hope to have a new
package up in the next week or two.

Christian, thank you for writing this program, I have been meaning to take it
up for the last 6 months.

Re: agreeing with the DFSG (was Re: non-free --> non-dfsg)

[Marcus Brinkmann]

On Wed, Jan 20, 1999 at 01:16:36AM -0600, Ossama Othman wrote:
> Let's assume that we live
> in a police state where speaking up against the law is unheard of and
> punishable.  Which would you prefer: living in a society where people
> follow the laws but speak up if the law isn't a fair one in their opinion,
> or would you prefer the police state?  I greatly prefer the society where
> one is allowed to speak up.  Do we want Debian to be a police state of
> sorts?  I admit that this is an extreme analogy but I think that it
> conveys what I am trying to say.

Hell, what are you TALKING about

Debian is a voluntary organization. If participation in the police state is
voluntary, I don't care a penny if you can speak up or not, because I would
not be there.

You are free to enter and to leave Debian. As long as you stay with Debian,
you have to follow some rules and share some visions.

In all police states I know of, leaving is not as easy. Your "analogy" is
not only inappropriate (as Debian is no "physical" thing like a country) but
completely absurd and so far off topic, that I have to wonder if you had all
your senses together writing this.

Marcus

-- 
"Rhubarb is no Egyptian god."Debian GNU/Linuxfinger brinkmd@ 
Marcus Brinkmann   http://www.debian.orgmaster.debian.org
[EMAIL PROTECTED]for public  PGP Key
http://homepage.ruhr-uni-bochum.de/Marcus.Brinkmann/   PGP Key ID 36E7CD09

Re: Revision 4 of DFSG

[Darren Benham]

On 20-Jan-99 Robert Woodcock wrote:
> Anthony Towns wrote:
>>* Is the Limitation of Liability really a restriction on use or
>>  distribution? This is just a layout thing, but it'd be nice to
>>  get it right.
> 
> Neither!
> 
> Also note that in all fields of endeavour you don't have to be able to sue
> the author to use the software (although there's a large amount of letter-
> recycling between the phrases ;)

That was pretty much what we were thinking and are not fishing for other
opinions.  I think we can expect that part of the draft to be gone in the next
version.


-- 
=
* http://benham.net/index.html <><  *
*  * -BEGIN GEEK CODE BLOCK- ---*
*Darren Benham * Version: 3.1   *
*  <[EMAIL PROTECTED]>  * GCS d+(-) s:+ a29 C++$ UL++> P+++$ L++>*
*   KC7YAQ * E? W+++$ N+(-) o? K- w+++$(--) O M-- V- PS--   *
*   Debian Developer   * PE++ Y++ PGP++ t+ 5 X R+ !tv b DI+++ D++   *
*  <[EMAIL PROTECTED]>  * G++>G+++ e h+ r* y+*
*  * --END GEEK CODE BLOCK-- ---*
=


pgpSspSIMAXBw.pgp
Description: PGP signature

Re: pseudo package for upgrades from hamm

[Martin Alonso Soto]

Robert Woodcock <[EMAIL PROTECTED]> writes:
> We need to add a new field - call it anything you want - I called it
> "Was-Part-Of:" in an earlier post, but I'm sure there's a better name than
> that - "Previously:" maybe.
> 
> Anyway, say slink contains a package 'foobar', version 1.2-3. The
> maintainer decides to split it into 'foo' and 'bar' for potato.
> 
> In the control files for the foo and bar packages, the maintainer slips in
> that aforementioned field:
> 
> Package: foo
> Version: 1.2-4
> Previously: foobar (<< 1.2-3)
> 
> ... and does the same thing for the bar package. dselect and apt check that
> field, check the current version of foobar, and based on that, automagically
> select the new packages.


Many, *many* people has proposed this idea before.  So many, that you
would be tempted to consider it a simple, natural, and straightforward
idea.  Nonetheless, it seems that this far, it has been impossible to
make it part of dpkg, or even to start working on the necessary
modifications for that purpose.

The list of bugs against dpkg grows almost daily, while the very few
people who are blessed to touch the source code continue to be too
buzzy to work on it.  Opening the development model for dpkg would be
a great way to overcome this sad situation, but it seems that us, poor
mortal Debian maintainers, are not considered good enough for taking
care of the central and most important tool in our project.


As a developer who have contributed to the project much less than I
would have wanted, but who appreciates it deeply, I would like to ask
the Debian leadership to seriously reconsider the dpkg development
model.  It is now clear that our lack of capacity as a project to
adequately manage the evolution of dpkg, is causing us serious
problems, and that if things continue to be like this, we will face
much more serious difficulties in the near future.

Hoping for the best,

M. S.

Martin A. Soto J.   Profesor
Departamento de Ingenieria de Sistemas y Computacion
Universidad de los Andes  [EMAIL PROTECTED]

Re: libpam, cracklib, and slink (was Re: Release-critical...)

[J.H.M. Dassen]

On Wed, Jan 20, 1999 at 11:22:05 -0500, Jean Pierre LeJacq wrote:
> On Wed, 20 Jan 1999, J.H.M. Dassen wrote:
> > Perhaps the best way for cracklib support in PAM is to redefine PAM's
> > packages into "base" and "non-base" ones. The "base" ones should be
> > intended for future (potato) inclusion in the base system (for use by
> > e.g. login); the "non-base" ones could require more libraries and
> > auxiliary programs. Such a change in packaging could also be used as an
> > opportunity to merge libpam0g and libpam0g-util (which have a mutual
> > dependency).
> 
> I'm not sure I understand.  Would the base and non-base conflict with one
> another?

Not really. (Though perhaps in a technical sense, to get dpkg to replace the
base with the non-base one).

> Or does pam use loadable modules

The individual pluggable authentication modules are .so files, yes.

> so the base can be compiled without cracklib but later load the cracklib
> library when non-base is installed?

This is something else. It may be possible to modify the individual PAMs to
use dlopen() and friends to dynamically load cracklib if available, but
(AFAIK) this is not in standard PAM.

Ray
-- 
UNFAIR  Term applied to advantages enjoyed by other people which we tried 
to cheat them out of and didn't manage. See also DISHONESTY, SNEAKY, 
UNDERHAND and JUST LUCKY I GUESS. 
- The Hipcrime Vocab by Chad C. Mulligan  

Intent to package: GramoFile

[Charles Briscoe-Smith]

I just rediscovered GramoFile, which was announced on c.o.l.a. a while
ago.  It's a program for filtering the sound from a gramophone record
to make it suitable for recording onto a CD.

I've packaged it, and will upload it shortly unless I hear otherwise.

-- 
Charles Briscoe-Smith
White pages entry, with PGP key: http://alethea.ukc.ac.uk/wp?95cpb4>
PGP public keyprint: 74 68 AB 2E 1C 60 22 94  B8 21 2D 01 DE 66 13 E2

Re: libpam, cracklib, and slink (was Re: Release-critical...)

[Jean Pierre LeJacq]

On Wed, 20 Jan 1999, J.H.M. Dassen wrote:

> On Wed, Jan 20, 1999 at 10:34:45 -0500, Jean Pierre LeJacq wrote:
> > Another Ack!  I'd like to see cracklib support enabled in PAM.  Can we
> > coordinate uploads here?  I plan on a new upload of cracklib this weekend
> > which will close all existing bug reports.
> 
> Perhaps the best way for cracklib support in PAM is to redefine PAM's
> packages into "base" and "non-base" ones. The "base" ones should be intended
> for future (potato) inclusion in the base system (for use by e.g. login);
> the "non-base" ones could require more libraries and auxiliary programs.
> Such a change in packaging could also be used as an opportunity to merge
> libpam0g and libpam0g-util (which have a mutual dependency).

I'm not sure I understand.  Would the base and non-base conflict with
one another?  Or does pam use loadable modules so the base can be
compiled without cracklib but later load the cracklib library when
non-base is installed?


> On Wed, Jan 20, 1999 at 10:31:57 -0500, Ben Collins wrote:
> > Since no one else has spoken up, I will take over pam. I will also look
> > into cracklib support being put back in,
> 
> You're misunderstanding things here: PAM so far has not supported cracklib.
> At one point, I was considering adding the support, and modified the build
> system to add -lcracklib for the pamutil .so's, but I never got around to
> really enabling the cracklib build.

I see.  This makes cracklib's bugs less critical.  Still, I plan on
uploading fixes this weekend.

-- 
Jean Pierre

Re: packages.debian.org

[jmlb2]

On 20-Jan-99 James A. Treacy wrote:
> If it was up to me there wouldn't be any two letter package names.
> I'll add two letter words when I recompile.

[..snip..]

> It appears that 'make' is in the list of ignored words. I'll recompile a
> new version. There isn't much I can do about the quality results reported
> (or the resulting order) without rewriting part of the program.

Given that from your description swish++ sounds like a general purpose indexer,
which has been set up to index 'natural language' is it the best one for our
purposes?

If the aim is simply to build an index of package names to web pages, I would
have thought that a different tool would be more appropriate - indeed, with
perl and the HTML parser module, it would be a short script.

Jules

/+---+-\
|  Jelibean aka  | [EMAIL PROTECTED] |  6 Evelyn Rd|
|  Jules aka |   |  Richmond, Surrey   |
|  Julian Bean   | [EMAIL PROTECTED]|  TW9 2TF *UK*   |
++---+-+
|  War doesn't demonstrate who's right... just who's left. |
|  When privacy is outlawed... only the outlaws have privacy.  |
\--/

Re: Debian goes big business?

[Eric Gillespie, Jr.]

On Wed, 20 Jan 1999, Christian Lavoie wrote:

> - Debian will lose its spirit if it goes itself for-profit.
> - A for-profit corporation based on Debian itself will eventually try 
> to influence/own it. (Consequences: See previous comment)
> 
> Bottom line: Debian should remain developer controlled.
> 

I wouldn't mind it if everyone disagreed with what I'm saying. But it
seems as if no one even understands what I'm saying. No one would be
taking home any profit in the system I'm talking about. The core
developers (the ones who currently control Debian) would be a kind of
board of directors. Developers would work for Debian instead of doing it
in their free time. Bottom line: Debian *will* remain developer
controlled.

> On a side note, if a user-based co-operative society forms, would a 
> developer-based society of the same kind be appreciated? It could for 
> an example provide acquisition of patents (basically, to GPLized them) 
> and work to allow developers for better recognition, allow to access 
> better resources (like an equivalent to a membership to W3C, or other 
> reserved to corporation bodies thingies.) and tries to augment 
> developer communication and tries to 'enforce' major headings of the 
> dist. (Like, say, we're switching to libc7)
> 

This sounds more like what I'm saying.

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

/--\
| pretzelgod | [EMAIL PROTECTED]|
| (Eric Gillespie, Jr.)  | [EMAIL PROTECTED]   |
|---<*>|
| "That's the problem with going from a soldier to a   |
|  politician: you actually have to sit down and listen to |
|  people who six months ago you would've just shot."  |
|  --President John Sheridan, Babylon 5|
\--/

Re: libpam, cracklib, and slink (was Re: Release-critical...)

[Ben Collins]

On Wed, Jan 20, 1999 at 04:50:53PM +0100, J.H.M. Dassen wrote:
> > Since no one else has spoken up, I will take over pam. I will also look
> > into cracklib support being put back in,
> 
> You're misunderstanding things here: PAM so far has not supported cracklib.
> At one point, I was considering adding the support, and modified the build
> system to add -lcracklib for the pamutil .so's, but I never got around to
> really enabling the cracklib build.

That's fine, I wasn't too sure what the relation was so I wasn't about to
make any definite plans. If you have some detailed suggestions on this I
would appreciate them greatly. As for now, I'm simply going to
re-familiarize myself with the source and diff.

thanks,
  Ben

-- 
--- -  -   ---  -  - - ---   
Ben Collins <[EMAIL PROTECTED]>  Debian GNU/Linux
UnixGroup Admin - Jordan Systems Inc. [EMAIL PROTECTED]
-- -- - - - ---   --- -- The Choice of the GNU Generation

Re: libpam, cracklib, and slink (was Re: Release-critical...)

[J.H.M. Dassen]

On Wed, Jan 20, 1999 at 06:39:12 -0500, Ben Collins wrote:
> On Wed, Jan 20, 1999 at 09:46:21AM +0100, J.H.M. Dassen wrote:
> > I'm now preparing an upload that'll mark PAM as orphaned.
> 
> Ack! We need pam to be maintained if we want to enable it's use in potato.

I agree; my time resources are fairly limited and do not allow for the kind
of commitment PAM maintenance would mean. (E.g., the modifications I made to
link the .so files against the libraries they depend on should really be
incorporated upstream, but I've not found time to forward&lobby)

> I'll take it, if no one intends on doing so themselves.

Great.

On Wed, Jan 20, 1999 at 10:34:45 -0500, Jean Pierre LeJacq wrote:
> Another Ack!  I'd like to see cracklib support enabled in PAM.  Can we
> coordinate uploads here?  I plan on a new upload of cracklib this weekend
> which will close all existing bug reports.

Perhaps the best way for cracklib support in PAM is to redefine PAM's
packages into "base" and "non-base" ones. The "base" ones should be intended
for future (potato) inclusion in the base system (for use by e.g. login);
the "non-base" ones could require more libraries and auxiliary programs.
Such a change in packaging could also be used as an opportunity to merge
libpam0g and libpam0g-util (which have a mutual dependency).

On Wed, Jan 20, 1999 at 10:31:57 -0500, Ben Collins wrote:
> Since no one else has spoken up, I will take over pam. I will also look
> into cracklib support being put back in,

You're misunderstanding things here: PAM so far has not supported cracklib.
At one point, I was considering adding the support, and modified the build
system to add -lcracklib for the pamutil .so's, but I never got around to
really enabling the cracklib build.

Greetings,
Ray
-- 
UNFAIR  Term applied to advantages enjoyed by other people which we tried 
to cheat them out of and didn't manage. See also DISHONESTY, SNEAKY, 
UNDERHAND and JUST LUCKY I GUESS. 
- The Hipcrime Vocab by Chad C. Mulligan  

Re: packages.debian.org

[James A. Treacy]

On Wed, Jan 20, 1999 at 02:45:16PM +0100, Josip Rodin wrote:
> 
> Yes, gdb works now. I followed the murphy's law, and tried
> packages.debian.org/ae. You know the story... :)
> Once again, it doesn't find 'ae' (or bc), but finds aegis{-doc}.
> It seems to be only the search error because ae's page exists at
> http://www.debian.org/Packages/unstable/base/ae.html.
> The only remaining question here is whether we have one-letter
> packages ;-D
> 
If it was up to me there wouldn't be any two letter package names.
I'll add two letter words when I recompile.

>  I think that it is not only about three letter
> one's. I tried 'make' and it gave me only make-doc, makepasswd, but
> not the 'make' itself :( Interestingly, it found 'gcc' when I searched
> for 'gcc', but it marked it last on the list, 16%. I tried apache too,
> since -common/doc packages also exists, and 'apache' was in the list,
> but also ranked too low.
> 
It appears that 'make' is in the list of ignored words. I'll recompile a
new version. There isn't much I can do about the quality results reported
(or the resulting order) without rewriting part of the program.

> Also, you realy should change some words in the output. The percentage
> column is named 'Quality' which is kind of confusing. I suggest you
> change that to 'Match:' or something else.
> It would be a good idea not to put the 'Release' column after the
> 'Quality' since this leads to output like this (at least in my lynx):
> 
>100%   unstable  make-doc 3.77-4   (3982 bytes)
>Documentation for the GNU version of the "make" utility.
> 
> Note the '100% unstable', which may lead to confusion.
> And if you do that, remove the file size after the description, it
> can only cause the confusion (and who really needs that file size?).
> 
Actually, file sizes is something many people demanded. What they probably
really want, but didn't specify, is the size of the package. They aren't
going to get it (hmmm, actually I just thought of a slick way to do that
which will only take 10 min to implement).

As for the layout, send in html markup for a different layout and if I
like it I'll implement it. Leave in the package sizes as it'll probably
be implemented tonight.

Jay Treacy

Re: libpam, cracklib, and slink (was Re: Release-critical...)

[Ben Collins]

On Wed, Jan 20, 1999 at 10:34:45AM -0500, Jean Pierre LeJacq wrote:
> > Ack! We need pam to be maintained if we want to enable it's use in
> > potato. I'll take it, if no one intends on doing so themselves.
> 
> Another Ack!  I'd like to see cracklib support enabled in PAM.  Can we
> coordinate uploads here?  I plan on a new upload of cracklib this
> weekend which will close all existing bug reports.

Since no one else has spoken up, I will take over pam. I will also look
into cracklib support being put back in, but for slink I think the
"Priority" conflict warrants the dependency being removed.

-- 
--- -  -   ---  -  - - ---   
Ben Collins <[EMAIL PROTECTED]>  Debian GNU/Linux
UnixGroup Admin - Jordan Systems Inc. [EMAIL PROTECTED]
-- -- - - - ---   --- -- The Choice of the GNU Generation

Re: libpam, cracklib, and slink (was Re: Release-critical...)

[Jean Pierre LeJacq]

On Wed, 20 Jan 1999, Ben Collins wrote:

> On Wed, Jan 20, 1999 at 09:46:21AM +0100, J.H.M. Dassen wrote:
> > > I think that there should be a release critical bug here, but I think it
> > > should be #30862:  libpam0g depends on cracklib2.
> >
> > Yup. I've looked at it again, and the dependency is superflous. (I modified
> > PAM to link it's .so's to all the libraries they need, and -lcracklib
> > slipped in there because I originally looked at enabling cracklib support).
> >
> > I'm now preparing an upload that'll mark PAM as orphaned.
> 
> Ack! We need pam to be maintained if we want to enable it's use in
> potato. I'll take it, if no one intends on doing so themselves.

Another Ack!  I'd like to see cracklib support enabled in PAM.  Can we
coordinate uploads here?  I plan on a new upload of cracklib this
weekend which will close all existing bug reports.

-- 
Jean Pierre

Re: Resolutions to comments on LSB-FHS-TS_SPEC_V1.0

[Erik Troan]

On 20 Jan 1999, Daniel Quinlan wrote:

>  1. totally revert, drop /var/mail, and specify /var/spool/mail
>  2. partially revert, /var/spool/mail is a directory and /var/mail
> must be a symbolic link to it
>  3. allow a /var/spool/mail directory, provided that /var/mail is
> a symbolic link to it
>  4. allow either /var/spool/mail or /var/mail to be a directory,
> provided that the other is a symbolic link to it.

Who will #1 affect? Does anyone use /var/mail?

Erik

---
|   "For the next two hours, VH1 will be filled with foul-mouthed,|
|  crossdressing Australians. Viewer discretion is advised."  |
| |
|   Linux Application Development  --  http://www.redhat.com/~johnsonm/lad|

Re: Release-critical Bugreport for January 19, 1999

[Jean Pierre LeJacq]

On Tue, 19 Jan 1999, Wichert Akkerman wrote:

> > That said, I plan on cleaning up all the bugs for this package next
> > week.
> 
> There appears to be another problem with cracklib: it is missing a
> script which means it can't be recompiled, which is clearly a
> release-critical bug.

Your correct here.  This is already fixed.  I'll be uploading new
version this weekend.

-- 
Jean Pierre

Re: Debian booth at LinuxTag '99?

[Thimo Neubauer]

On Mon, Jan 18, 1999 at 11:29:40PM +0100, Gregor Hoffleit wrote:
> Christian Weisgerber wrote:
> >   Because we, the organizers of LinuxTag '99, would like to invite the
> >   Debian project to set up a booth at this year's event. Several major
> >   Linux distributions will be there: SuSE, DLD, representatives for Red
> >   Hat, etc. Last year quite a few visitors expressed their disap-
> >   pointment about Debian's absence.
> 
> If time permits, I'd like to attend and help with a Debian booth. 
> Kaiserslautern is just a stone throw away, still I didn't manage to 
> attend last year.
> 
> Are there any other volunteers that would like to help setting up a booth 
> there ? 

Yes, but also only if time permits. I could also provide one to two
beds in Heidelberg (the city "a stone throw away") for fellow
developers. Hopefully I`ll get my parents car to get to Kaiserslautern
without problems.

Thimo

-- 
Thimo Neubauer <[EMAIL PROTECTED]>
Debian GNU/Linux 2.1 frozen! See http://www.debian.org/ for details


pgpWoDbwZTtae.pgp
Description: PGP signature

Re: Debian goes big business?

[Fabrizio Polacco]

David Welton wrote:
> 
> On Tue, Jan 19, 1999 at 04:55:29PM -0600, John Hasler wrote:
> > Shawn writes:
> 
> > > I am all for a for-profit business forming as a value-added seller
> > > of Debian products. Such a business could focus on
> > > pre-installations, packaging and marketing, and user support. I
> > > would think a very successful business could be built on such a
> > > model, and there would be no necessary control flowing either way
> > > between said business and the Debian organization. The Debian
> > > community would control the software, such a business (and there
> > > could be many of them) would control its own marketing, packaging,
> > > support program, etc.
> 
> > Exactly!  This is just the sort of company I would love to participate in.
> 
> This is what Prosa (www.prosa.it) is, for the record.

It is something more, for the record.
It's the only company (a ltd for the precision) that has carved into
stone (in its statute, I mean) the obligation to comply with the
open-source definition.
That means that if an employee installs Windows on a company PC it can
be fired.
No, "can" is not the right verb; "must" is. :-)

> Alessandro Rubini (who wrote Linux Device
> Drivers, as well as the Kernel Corner column for the Linux Journal) is
> one of their employees.

One of the founders, for the record, and beloved President.

fab
--

Re: Bug#32068: multicd can't reinstall removed package

[Martin Schulze]

A fixed version has just been uploaded to Incoming.

Regards,

Joey

-- 
Computers are not intelligent.  They only think they are.

Please always Cc to me when replying to me on the lists.

Re: texinfo and texi2* in tetex-bin?

[Lalo Martins]

On Jan 19, Joel Klecker decided to present us with:
> At 17:15 -0200 1999-01-19, Lalo Martins wrote:
> >Oh boy! Cammon! Now I need to install 25M (tetex-bin~=10 +
> >tetex-base~=15) just to compile texi files into html or info?
> 
> Uhh, not "now", makeinfo and texi2html in tetex-bin is not a new 
> development, it's been that way since at least bo, IIRC.

I know. Doesn't make it any better. :-)

> >I really think we should continue to provide separate "texinfo"
> >and "texi2html" packages at least.
> 
> Those were never separate binary packages. The texinfo source package 
> generates `info'.

It may generate "makeinfo" too. Yes, not "texinfo", "makeinfo".

[]s,
   |alo
   +
--
  I am Lalo of deB-org. You will be freed.
 Resistance is futile.

http://www.webcom.com/lalo  mailto:[EMAIL PROTECTED]
 pgp key in the web page

Debian GNU/Linux   --http://www.debian.org

Re: packages.debian.org

[Josip Rodin]

On Tue, Jan 19, 1999 at 09:36:18PM -0500, James A. Treacy wrote:
> Try again. The system installed version of the indexing program was being
> used instead of my custom job. This has been fixed so it should work correctly
> now.

Yes, gdb works now. I followed the murphy's law, and tried
packages.debian.org/ae. You know the story... :)
Once again, it doesn't find 'ae' (or bc), but finds aegis{-doc}.
It seems to be only the search error because ae's page exists at
http://www.debian.org/Packages/unstable/base/ae.html.
The only remaining question here is whether we have one-letter
packages ;-D

 I think that it is not only about three letter
one's. I tried 'make' and it gave me only make-doc, makepasswd, but
not the 'make' itself :( Interestingly, it found 'gcc' when I searched
for 'gcc', but it marked it last on the list, 16%. I tried apache too,
since -common/doc packages also exists, and 'apache' was in the list,
but also ranked too low.

Also, you realy should change some words in the output. The percentage
column is named 'Quality' which is kind of confusing. I suggest you
change that to 'Match:' or something else.
It would be a good idea not to put the 'Release' column after the
'Quality' since this leads to output like this (at least in my lynx):

   100%   unstable  make-doc 3.77-4   (3982 bytes)
   Documentation for the GNU version of the "make" utility.

Note the '100% unstable', which may lead to confusion.
And if you do that, remove the file size after the description, it
can only cause the confusion (and who really needs that file size?).

--
enJoy -*/\*- http://jagor.srce.hr/~jrodin/

Re: Debian Weekly News - 12 to 18 Jan 1999

[Brandon Mitchell]

On 20 Jan 1999, Achim Oppelt wrote:

> Just one minor criticism:
> 
> >  * For all those interested in XFree 3.3.3, Ben Gertzfield [15]posted
> >that the Debian JP group has made their own 3.3.3 packages. They
> >can be found at [16]ftp.debian.or.jp. Your mileage may vary, but
> >it may be something to try before pulling you hair out when the
> >binaries from the XFree group give you problems.
> 
> The name of the product is XFree86 (even though it is no longer i86
> specific). And the name of the group of people creating it is The Xfree86
> Project, Inc. While such points certainly don't matter in informal
> discussions on mailing lists, I think that it would be a good idea to get
> the terms right in a more or less official newsletter.

Woops, sorry, that was my bad.  And I was debating whether to call it X or
XFree.  I'll be more careful next time.

Thanks,
Brandon

+---  ---+
| Brandon Mitchell * [EMAIL PROTECTED] * http://bhmit1.home.ml.org/ |
| The above is a completely random sequence of bits, any relation to |
|   an actual message is purely accidental.  |

Re: France and Cryptography

[Sven LUTHER]

On Wed, Jan 20, 1999 at 03:30:43PM +0200, Fabrizio Polacco wrote:
> Sven LUTHER wrote:
> > 
> > > (This becomes slightly off-topic on debian-devel)
> > 
> > no it is not, this means i (living in france) can sign debia npackages 
> > without becoming
> > a dangerous terrorist or whatever,
> > 
> > hey in the past i could have been put in jail for that ...
> 
> Not at all.
> Restriction was only for encription of text, not for signing it.

with key les than 40bit, but you could also go to jail (and still could, unitl 
they sign the text)
for signing with bigger keys¸ ...

this is great news for all french debia ndeveloppers, ...

Friendly,

Sven LUTHER

Re: France and Cryptography

[Fabrizio Polacco]

Sven LUTHER wrote:
> 
> > (This becomes slightly off-topic on debian-devel)
> 
> no it is not, this means i (living in france) can sign debia npackages 
> without becoming
> a dangerous terrorist or whatever,
> 
> hey in the past i could have been put in jail for that ...

Not at all.
Restriction was only for encription of text, not for signing it.

fab

Re: No intend to package vbox

[Roland Rosenfeld]

Paul Slootman <[EMAIL PROTECTED]> wrote:

> I'm planning to split up isdnutils sometime into separate parts;
> there are many sites where for example vbox isn't used at all, so
> having it installed isn't useful.

Sound reasonable.

> isdnvbox vbox

Hmmm, maybe this should be split into two packages, the vboxgetty and
vboxd on the one hand and the vbox client on the other hand. What I
want to say is, that there should be some chance to install only the
vbox client on a machine without the need to install a complete isdn
subsystem.

Tscho

Roland

-- 
 * [EMAIL PROTECTED] * http://www.rhein.de/~roland/ *
 PGP: 1024/DD08DD6D   2D E7 CC DE D5 8D 78 BE  3C A0 A4 F1 4B 09 CE AF

Re: France and Cryptography

[Sven LUTHER]

On Wed, Jan 20, 1999 at 01:16:15PM +0100, Olivier Tharan wrote:
> > > On Tue, Jan 19, 1999 at 08:02:34PM +0100, Samuel Tardieu wrote:
> > > > FYI, the French Prime Minister just announced that cryptography will
> > > > become legal in France!
> 
> On Wed, Jan 20, 1999 at 01:10:42PM +0100, Sven LUTHER wrote:
> > it will become legal, but is not yet, isn't it ?
> > when will be the legalisation ?
> 
> There is an announcement on
> http://www.internet.gouv.fr/francais/textesref/cisi190199/decis1.htm (sorry,
> it's in French) ; for the moment, the maximum key size will go from 40 to 128
> bits and then they will try get to get a law approved/voted by the
> Parliament.
> 
> (This becomes slightly off-topic on debian-devel)

no it is not, this means i (living in france) can sign debia npackages without 
becoming
a dangerous terrorist or whatever, 

hey in the past i could have been put in jail for that ...

Friendly,

Sven LUTHER

Re: Unmet Deps revisted

[Santiago Vila]

On Wed, 20 Jan 1999, Wichert Akkerman wrote:

> Previously Martin Schulze wrote:
> > When selecting all packages of a certain priority there should be no
> > conflicts.
> 
> I think that if I try to install every package with priority extra
> some things will start complaining very loudly.

"extra" is the only priority in which packages are allowed to conflict at
each other freely, that's why the definition of extra says "you are
supposed to know what you are doing".

There is no such claim ("you are supposed to know what you are doing")
for required, important, standard or optional packages.

-- 
 "fcc06680272f29f0fd503c03c28cfd97" (a truly random sig)

Release-critical bugs

[Julian Gilbey]

The two bugs against lprng have suggestions by me in the bug reports
as to how to fix them.  If someone can check out my suggestion for
/etc/lprng.perms (Bug #23682) and do an NMU, that would be great.
Please correct #31889 in the process -- it's just the reversal of two
lines in the postinst.

I have uploaded a fixed netbase (NMU) to potato to close #32092 and
the slew of other bug reports against this version; it only applies to
potato so should not be on the release-critical list.

   Julian

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

Julian Gilbey Email: [EMAIL PROTECTED]
   Dept of Mathematical Sciences, Queen Mary & Westfield College,
  Mile End Road, London E1 4NS, ENGLAND
  -*- Finger [EMAIL PROTECTED] for my PGP public key. -*-

Re: non-free --> non-dfsg

[Ossama Othman]

Hi Craig,

> > The point is that it easy to say "I am right and you are wrong."  Who
> > makes us right and them wrong?
> 
> i think you're missing the point.
> 
> the point has nothing to do with who is right and who is wrong.

Somewhere along the way of this thread I unwittingly moved into the
philosophical realm and started speaking as so, and lost track of how it
initially got started.  The question I posed was purely philosophical and 
wasn't meant to be applied toward Debian although I used Debian in my
analogy/question/whatever.  Please excuse the philosophy. :)

> the point is that as far as Debian is concerned, the DFSG is THE test of
> whether a program is free or not.

I thought that we came to an understanding that I understood that? Before
you answer this please read on.
 
> if a program passes all of the criteria, it is free.
> if a program fails any one of the criteria, it is non-free.
> 
> debian's archives are run according to debian's policies. we'd be
> hypocrites, otherwise. 

Yes, I agree. I am not disputing that.
(let's not get into my interpretation of "free" again, please)

> neither software authors, nor users, nor the communities, nor anyone
> except debian developers get a vote when it comes to debian's policies.
> nor should they.

I also agree.  My intention was only to look at the situation from the
other side.  Please don't mistake my objectivity for a lack of support of 
Debian policy.

Thanks,
-Ossama
__
Ossama Othman <[EMAIL PROTECTED]>
58 60 1A E8 7A 66 F4 44  74 9F 3C D4 EF BF 35 88  1024/8A04D15D 1998/08/26

Re: Unmet Deps revisted

[Steve McIntyre]

On Wed, 20 Jan 1999, Martin Schulze wrote:

>> Am I missing something here? Where does it say that users should be able
>> to install _all_ optional packages?
>
>When selecting all packages of a certain priority there should be no
>conflicts.  If there are two MTA's, then one is optional, the other is
>extra.  I'm sure this is written down in one of our many policy, develop.
>ref, packaging manuals.

So how does this work if we get lots of (using the same example) different
MTAs? We get one in optional, one in extra, then where do the others go?

-- 
Steve McIntyre, Allstor Software [EMAIL PROTECTED]
Getting a SCSI chain working is perfectly simple if you remember that there
must be exactly three terminations: one on one end of the cable, one on the
far end, and the goat, terminated over the SCSI chain with a silver-handled
knife whilst burning *black* candles. --- Anthony DeBoer

Re: Unmet Deps revisted

[Martin Schulze]

Wichert Akkerman wrote:
> Previously Martin Schulze wrote:
> > When selecting all packages of a certain priority there should be no
> > conflicts.
> 
> I think that if I try to install every package with priority extra
> some things will start complaining very loudly..

Isn't that what Santiago pointed out?

Regards,

Joey

-- 
Computers are not intelligent.  They only think they are.

Please always Cc to me when replying to me on the lists.

Re: France and Cryptography

[Olivier Tharan]

> > On Tue, Jan 19, 1999 at 08:02:34PM +0100, Samuel Tardieu wrote:
> > > FYI, the French Prime Minister just announced that cryptography will
> > > become legal in France!

On Wed, Jan 20, 1999 at 01:10:42PM +0100, Sven LUTHER wrote:
> it will become legal, but is not yet, isn't it ?
> when will be the legalisation ?

There is an announcement on
http://www.internet.gouv.fr/francais/textesref/cisi190199/decis1.htm (sorry,
it's in French) ; for the moment, the maximum key size will go from 40 to 128
bits and then they will try get to get a law approved/voted by the
Parliament.

(This becomes slightly off-topic on debian-devel)

olive
-- 
Olivier Tharan, <[EMAIL PROTECTED]>

Multitasking:  Screwing up several things at once...

Re: non-free --> non-dfsg

[Craig Sanders]

On Wed, Jan 20, 1999 at 01:18:37AM -0600, Ossama Othman wrote:
> >  Ossama> Looking at it from the author's point of view, the author may
> >  Ossama> feel that Debian's definition of "free" is wrong and his is
> >  Ossama> right.  So he may also think about Debian that "there is
> >  Ossama> indeed something wrong that they should know about."
> > 
> > This is all very interesting, and so on, but where is this
> >  leading? All kinds of people may have all kinds of opinion about
> >  Debian. The point is?
> 
> The point is that it easy to say "I am right and you are wrong."  Who
> makes us right and them wrong?

i think you're missing the point.

the point has nothing to do with who is right and who is wrong.

the point is that as far as Debian is concerned, the DFSG is THE test of
whether a program is free or not.

if a program passes all of the criteria, it is free.
if a program fails any one of the criteria, it is non-free.

debian's archives are run according to debian's policies. we'd be
hypocrites, otherwise. 


craig

PS: while it is true that a large majority of the free software / linux
community tends to agree with debian about what makes software free or
non-free (witness the rapid and enthusiastic adoption of the Open Source
Definition, which is the DFSG with debian references stripped out), that is
also irrelevant...

neither software authors, nor users, nor the communities, nor anyone
except debian developers get a vote when it comes to debian's policies.
nor should they.

--
craig sanders

evil strace NMU

[Wichert Akkerman]

I just became aware that someone did a NMU for strace, apparently to fix
some ARM issues. I strongly urge people to not do that, for several
reasons:

* nobody notified me of this NMU, I had to learn about it by reading
  debian-devel-changes
* I really don't have to time to track NMUs down to see what people
  changed, which means that changes will not make it into my sources.
* strace is troublesome enough as it is, evil NMU's only complicate
  things further. I really want to verify *all* strace patches before I
  incorporate them.
* last but certainly not least important: we have rules about doing
  NMUs. They also hold for porters. Please honour them.

Wichert.
-- 
==
This combination of bytes forms a message written to you by Wichert Akkerman.
E-Mail: [EMAIL PROTECTED]
WWW: http://www.wi.leidenuniv.nl/~wichert/


pgpoerIngACXW.pgp
Description: PGP signature

Re: Unmet Deps revisted

[Wichert Akkerman]

Previously Martin Schulze wrote:
> When selecting all packages of a certain priority there should be no
> conflicts.

I think that if I try to install every package with priority extra
some things will start complaining very loudly..

Wichert.

-- 
==
This combination of bytes forms a message written to you by Wichert Akkerman.
E-Mail: [EMAIL PROTECTED]
WWW: http://www.wi.leidenuniv.nl/~wichert/


pgpNarewrX8vd.pgp
Description: PGP signature

Re: Processed: Change Important Severities

[Wichert Akkerman]

severity 31717 important
thanks

Previously Paul Slootman wrote:
> I think that this bug _should_ be important; it's just that it's not
> important for slink as the bug is only in the fileutils version in
> potato... So, if this is an effort to reduce the number of release-
> critical bugs (for _slink_), then IMHO it's the wrong way to go about
> it.

Bah I say: we have exclusion lists for bugs that have severity important
or higher but are not a problem for the current release candidate. If
you think a bugreport should be added to that list please inform Brian
White and me so we can add it to those lists.

This particular bug was already on my exclusion list and is now also on
Brians list.

Wichert.

-- 
==
This combination of bytes forms a message written to you by Wichert Akkerman.
E-Mail: [EMAIL PROTECTED]
WWW: http://www.wi.leidenuniv.nl/~wichert/

Re: France and Cryptography

[Sven LUTHER]

On Wed, Jan 20, 1999 at 03:51:03AM -0800, Joseph Carter wrote:
> On Tue, Jan 19, 1999 at 08:02:34PM +0100, Samuel Tardieu wrote:
> > FYI, the French Prime Minister just announced that cryptography will
> > become legal in France!

it will become legal, but is not yet, isn't it ?

when will be the legalisation ?

Friendly,

Sven LUTHER

Re: Debian booth at LinuxTag '99?

[Martin Bialasinski]

>> "FDG" == Federico Di Gregorio <[EMAIL PROTECTED]> writes:

FDG> That's fine. If we gather enough english-speaking-developers
FDG> german won't be a problem (just to know, how do you say "beer" in
FDG> german?)

It is "Bier", spoken nearly like the english word beer. But if you ask 
for a beer, you will be asked what kind of beer you want :-)

I have to check for the date of my exams, but if it is possible, I
will join as well.

Does it make sense to open a seperate mailinglist to coordinate and to 
 move the traffic away from -devel? I can host one.

Ciao,
Martin

Re: France and Cryptography

[Joseph Carter]

On Tue, Jan 19, 1999 at 08:02:34PM +0100, Samuel Tardieu wrote:
> FYI, the French Prime Minister just announced that cryptography will
> become legal in France!
> 
> In the meantime (until our representatives adopt the law), the
> authorized key sizes go from 40 bits to 128 bits.

Now if the idiot in the White House would get a clue and lose the crypto
regs in the US

-- 
"I'm working in the dark here."  "Yeah well rumor has it you do your best
work in the dark."
   -- Earth: Final Conflict

Re: libpam, cracklib, and slink (was Re: Release-critical...)

[Ben Collins]

On Wed, Jan 20, 1999 at 09:46:21AM +0100, J.H.M. Dassen wrote:
> > I think that there should be a release critical bug here, but I think it
> > should be #30862:  libpam0g depends on cracklib2.
>
> Yup. I've looked at it again, and the dependency is superflous. (I modified
> PAM to link it's .so's to all the libraries they need, and -lcracklib
> slipped in there because I originally looked at enabling cracklib support).
>
> I'm now preparing an upload that'll mark PAM as orphaned.

Ack! We need pam to be maintained if we want to enable it's use in
potato. I'll take it, if no one intends on doing so themselves.

--
--- -  -   ---  -  - - ---   
Ben Collins <[EMAIL PROTECTED]>  Debian GNU/Linux
UnixGroup Admin - Jordan Systems Inc. [EMAIL PROTECTED]
-- -- - - - ---   --- -- The Choice of the GNU Generation

Xfree 3.3.3.1 packages...

[Sven LUTHER]

Hello, ...

i have made some package of the latest version of Xfree86, 3.3.3.1.

i have only compiled the powerpc packages, but i did the last part by hand, so
i have no changes file yet, and they will be rejected, anyway i upload them to
incoming so other people can play with them ...

the files are :

-rw-r--r--   1 root root26772 Jan 20 09:30
rstart_3.3.3.1-0.2_powerpc.deb
-rw-r--r--   1 root root38168 Jan 20 09:30
rstartd_3.3.3.1-0.2_powerpc.deb
-rw-r--r--   1 root root   115968 Jan 20 09:30
twm_3.3.3.1-0.2_powerpc.deb
-rw-r--r--   1 root root   986868 Jan 20 09:30
xbase-clients_3.3.3.1-0.2_powerpc.deb
-rw-r--r--   1 root root   108900 Jan 20 09:30
xbase_3.3.3.1-0.2_all.deb
-rw-r--r--   1 root root98230 Jan 20 09:30
xdm_3.3.3.1-0.2_powerpc.deb
-rw-r--r--   1 root root   498268 Jan 20 09:30
xext_3.3.3.1-0.2_powerpc.deb
-rw-r--r--   1 root root44038 Jan 20 09:30
xf86setup_3.3.3.1-0.2_powerpc.deb
-rw-r--r--   1 root root  1306294 Jan 20 09:30
xfonts-100dpi_3.3.3.1-0.2_all.deb
-rw-r--r--   1 root root  1133794 Jan 20 09:30
xfonts-75dpi_3.3.3.1-0.2_all.deb
-rw-r--r--   1 root root   240822 Jan 20 09:30
xfonts-base_3.3.3.1-0.2_all.deb
-rw-r--r--   1 root root  2218720 Jan 20 09:30
xfonts-cjk_3.3.3.1-0.2_all.deb
-rw-r--r--   1 root root   333740 Jan 20 09:30
xfonts-cyrillic_3.3.3.1-0.2_all.deb
-rw-r--r--   1 root root33166 Jan 20 09:30
xfonts-pex_3.3.3.1-0.2_all.deb
-rw-r--r--   1 root root  1148452 Jan 20 09:30
xfonts-scalable_3.3.3.1-0.2_all.deb
-rw-r--r--   1 root root   181552 Jan 20 09:32
xfree86_3.3.3.1-0.2.diff.gz
-rw-r--r--   1 root root  818 Jan 20 09:37 xfree86_3.3.3.1-0.2.dsc
-rw---   1 root root  984 Jan 20 09:37
xfree86_3.3.3.1-0.2.dsc.asc
-rw---   1 root root  664 Jan 20 09:37
xfree86_3.3.3.1-0.2.dsc.pgp
-rw-r--r--   1 root root 43349250 Jan 20 09:34
xfree86_3.3.3.1.orig.tar.gz
-rw-r--r--   1 root root   200740 Jan 20 09:30
xfs_3.3.3.1-0.2_powerpc.deb
-rw-r--r--   1 root root23864 Jan 20 09:30
xlib6-static_3.3.3.1-0.2_powerpc.deb
-rw-r--r--   1 root root   674826 Jan 20 09:30
xlib6g-dev_3.3.3.1-0.2_powerpc.deb
-rw-r--r--   1 root root  1083832 Jan 20 09:30
xlib6g-static_3.3.3.1-0.2_powerpc.deb
-rw-r--r--   1 root root  1070418 Jan 20 09:30
xlib6g_3.3.3.1-0.2_powerpc.deb
-rw-r--r--   1 root root   906462 Jan 20 09:30
xmanpages_3.3.3.1-0.2_all.deb
-rw-r--r--   1 root root96028 Jan 20 09:30
xmh_3.3.3.1-0.2_powerpc.deb
-rw-r--r--   1 root root43596 Jan 20 09:30
xmodmap_3.3.3.1-0.2_powerpc.deb
-rw-r--r--   1 root root   980848 Jan 20 09:30
xnest_3.3.3.1-0.2_powerpc.deb
-rw-r--r--   1 root root   129290 Jan 20 09:30
xproxy_3.3.3.1-0.2_powerpc.deb
-rw-r--r--   1 root root  1239892 Jan 20 09:30
xprt_3.3.3.1-0.2_powerpc.deb
-rw-r--r--   1 root root   167282 Jan 20 09:30
xserver-common_3.3.3.1-0.2_powerpc.deb
-rw-r--r--   1 root root   992282 Jan 20 09:30
xserver-fbdev_3.3.3.1-0.2_powerpc.deb
-rw-r--r--   1 root root74886 Jan 20 09:30
xsm_3.3.3.1-0.2_powerpc.deb
-rw-r--r--   1 root root   132440 Jan 20 09:30
xterm_3.3.3.1-0.2_powerpc.deb
-rw-r--r--   1 root root  1222772 Jan 20 09:30
xvfb_3.3.3.1-0.2_powerpc.deb

Friendly,

Sven LUTHER

Re: Bug#32156: anacron: It ran unnexpectedly!

[Christian Schwarz]

On Wed, 20 Jan 1999, Jason Gunthorpe wrote:

> Package: anacron
> Version: 2.0.1-2
> 
> This I cannot explain, my system has been running for the past 43 days without
> interruption and just now anacron fired up and started running things, at
> 12:30 on the dot - for the first time!
> 
> What gives?

I'm not sure why, but I'm still received these bug reports!  I've left
over a half year ago and I've orphaned all my packages then.  Perhaps
there is a bug in the script which tells the bug reporting system about
maintainers?  (Or did someone reupload an older version of anacron which
still lists me as maintainer?)  Anyways, it would be good if someone would
check this out and fix it.  It's not that I'm offended by such mails, but
I don't have time to work on anacron anymore and this way, probably noone
else notices about these bug reports (there was another bug report on
anacron which was also sent to me a some time ago).


Thanks,

Chris

-- Christian Schwarz
Do you know [EMAIL PROTECTED], [EMAIL PROTECTED]
Debian GNU/Linux?[EMAIL PROTECTED]
  
Visit  PGP-fp: 8F 61 EB 6D CF 23 CA D7  34 05 14 5C C8 DC 22 BA
http://www.debian.org   http://fatman.mathematik.tu-muenchen.de/~schwarz/

Re: Unmet Deps revisted

[Enrique Zanardi]

On Wed, Jan 20, 1999 at 10:22:39AM +, Steve McIntyre wrote:
> 
> Santiago Vila writes:
> >>> smail is still optional, but conflicts with exim, so it should be extra.
> >>> hello-debhelper conflicts with hello, and has absolutely no extra
> >>> functionality over ordinary hello, so the binary should be removed, in
> >>> either case it should be extra.
> >>> gmc conflicts with mc, but both are optional.
> >>>
> >>> There are in total *ten* dselect Dependency/conflict resolution screens.
> >>> (using the PageForward key). Am I *really* required to report them *all*,
> >>> or may I ask our kind ftp.debian.org maintainers to do a *serious*
> >>> dependency/conflict check *before* the deep freeze?
> 
> Am I missing something here? Where does it say that users should be able
> to install _all_ optional packages?

The policy manual suggests that:

"2.2 Priorities
[...]
   optional
  (In a sense everything is optional that isn't required, but
  that's not what is meant here.) This is all the software that
  you might reasonably want to install if you didn't know what it
  was or don't have specialised requirements. This is a much
  larger system and includes X11, a full TeX distribution, and
  lots of applications.
  
   extra
  This contains packages that conflict with others with higher
  priorities, or are only likely to be useful if you already know
  what they are or have specialised requirements.
"

By the definition of optional, a user may install all optional packages
if she doesn't know what they are (!) or don't have specialised
requirements.

If there are optional packages that conflict with each other, we should
choose one to stay in optional and move the others to extra. (Or change/
clarify the definition on the policy manual).

--
Enrique Zanardi[EMAIL PROTECTED]

Re: No intend to package vbox

[Paul Slootman]

On Tue 19 Jan 1999, Roland Rosenfeld wrote:
> 
> As far as I can see isdnutils-3.0-8 includes vbox 2.0.0 beta 5, which
> is a little bit newer than vbox 2 beta 4 with the following changes:

I'm planning to split up isdnutils sometime into separate parts; there
are many sites where for example vbox isn't used at all, so having it
installed isn't useful.

I was thinking of the following packages:

isdnutilscontains the basic isdnctrl, ipppd stuff needed for networking
isdnmonitoring   isdnlog, imon, xisdnload, ... that sort of thing
isdndocs the faqs and other docs
isdnvbox vbox

If anyone has better suggestions (I haven't really thought hard about this
yet) I'd like to hear them (please include reasoning).


Paul Slootman
-- 
home: [EMAIL PROTECTED] | work: [EMAIL PROTECTED] | debian: [EMAIL PROTECTED]
http://www.wurtel.demon.nl | Murphy Software,   Enschede,   the Netherlands

Re: Unmet Deps revisted

[Martin Schulze]

Steve McIntyre wrote:
> 
> Santiago Vila writes:
> >>> smail is still optional, but conflicts with exim, so it should be extra.
> >>> hello-debhelper conflicts with hello, and has absolutely no extra
> >>> functionality over ordinary hello, so the binary should be removed, in
> >>> either case it should be extra.
> >>> gmc conflicts with mc, but both are optional.
> >>>
> >>> There are in total *ten* dselect Dependency/conflict resolution screens.
> >>> (using the PageForward key). Am I *really* required to report them *all*,
> >>> or may I ask our kind ftp.debian.org maintainers to do a *serious*
> >>> dependency/conflict check *before* the deep freeze?
> 
> Am I missing something here? Where does it say that users should be able
> to install _all_ optional packages?

When selecting all packages of a certain priority there should be no
conflicts.  If there are two MTA's, then one is optional, the other is
extra.  I'm sure this is written down in one of our many policy, develop.
ref, packaging manuals.

Regards,

Joey

-- 
Computers are not intelligent.  They only think they are.

Please always Cc to me when replying to me on the lists.

Re: Debian v2.1 ("Slink") Deep Freeze

[Paul Slootman]

On Tue 19 Jan 1999, Branden Robinson wrote:
> 
> XFree86 3.3.2.3a-8pre9v4 is available at
> http://master.debian.org/~branden/xfree86/ .

This doesn't seem to have the patches CRITICAL to the alpha port yet!
I sent you a note around 7th January about this, saying where you
could find the patches I needed to -8pre9v2. I'll say it again:

http://master.debian.org/~paul/alpha/xfree86/xfree86-alpha.diff

Without these, the X server crashes and burns. PLEASE add these patches
before uploading -9 !


Paul Slootman
-- 
home: [EMAIL PROTECTED] | work: [EMAIL PROTECTED] | debian: [EMAIL PROTECTED]
http://www.wurtel.demon.nl | Murphy Software,   Enschede,   the Netherlands

Re: Unmet Deps revisted

[Steve McIntyre]

Santiago Vila writes:
>>> smail is still optional, but conflicts with exim, so it should be extra.
>>> hello-debhelper conflicts with hello, and has absolutely no extra
>>> functionality over ordinary hello, so the binary should be removed, in
>>> either case it should be extra.
>>> gmc conflicts with mc, but both are optional.
>>>
>>> There are in total *ten* dselect Dependency/conflict resolution screens.
>>> (using the PageForward key). Am I *really* required to report them *all*,
>>> or may I ask our kind ftp.debian.org maintainers to do a *serious*
>>> dependency/conflict check *before* the deep freeze?

Am I missing something here? Where does it say that users should be able
to install _all_ optional packages?

-- 
Steve McIntyre, Allstor Software [EMAIL PROTECTED]
http://www.chiark.greenend.org.uk/~stevem/>My home page
"Can't keep my eyes from the circling sky, 
"Tongue-tied & twisted, Just an earth-bound misfit, I..."  

Intent to package mixal

[Antti-Juhani Kaijanaho]

For those of you who are Knuth devotees like me, MIXAL should ring a
bell.  For others, I have added a small description below [1].

I'm going to package a MIX/MIXAL implementation (unimaginatively
called mixal by its author), the one which was designed and written by
Darius Bacon, then ported to UNIX and debugged by Eric S. Raymond,
with corrections to multiplication and division by Larry Gately.  The
source is available at the Retrocomputing Museum with a DFSG
compatible license.

This MIXAL reads, compiles and executes MIXAL programs in one process;
AFAIK you cannot key in your hand-compiled MIX code.  This MIXAL does
not do floating-point (since its author had only Volume I avaliable),
but it should be good enough for working the exercises in TAOCP.

A problem is that I'm hesitating about where to put mixal: in
interpreters or in otherosfs.  It is a MIXAL interpreter but it is
also a MIX emulator.  Another problem is that the upstream executable
is called `mix', which will surely result in name clashes.  Perhaps
taocp-mix or knuth-mix will be a better name.  Comments?


Antti-Juhani

[1] MIXAL is the assembly language for Donald Knuth's imaginary
computer MIX.  MIXAL is the chosen language in Knuth's monumental (and
yet unfinished) book series "The Art of Computer Programming", and all
example programs and programming exercises in it use MIXAL.  The
computer MIX has (to my knowledge) never been implemented in hardware,
but several software emulators exist.  The MIX has a 1960's
architecture with no hardware stack support, and will be replaced by
the equally imaginary RISC chip called MMIX 2009 [2] in future
editions.

[2] MMIX has a home page at
http://www-cs-staff.Stanford.EDU/~knuth/mmix.html>.
-- 
%%% Antti-Juhani Kaijanaho % [EMAIL PROTECTED] % http://www.iki.fi/gaia/ %%%

EMACS, n.:   Emacs May Allow Customised Screwups
   (unknown origin)

Re: Debian appears to be ancient

[Hamish Moffatt]

On Tue, Jan 19, 1999 at 10:19:10PM -0600, John Hasler wrote:
> I wrote:
> >   hasler/~ ll /usr/doc/copyright/base
> >   total 2
> >   -rw-r--r--   1 root root 1197 Dec 31  1969 debian.README
> 
> Ben Pfaff writes:
> > So what package does it come from, then, and what version?
> 
> I don't know.  'dpkg -S' can't find it.  This machine was upgraded from
> 1.3: maybe it's a leftover.

I have three machines which are 1.1 -> 1.2 -> 1.3 -> 2.0 upgradees.
I checked two; one has it (Jan 1 1970), the other doesn't. Odd!


Hamish
-- 
Hamish Moffatt VK3TYD  [EMAIL PROTECTED], [EMAIL PROTECTED]
Latest Debian packages at ftp://ftp.rising.com.au/pub/hamish. PGP#EFA6B9D5
CCs of replies from mailing lists are welcome.   http://hamish.home.ml.org

Re: Resolutions to comments on LSB-FHS-TS_SPEC_V1.0

[Anthony Towns]

(on /var/mail vs /var/spool/mail)

On Wed, Jan 20, 1999 at 12:19:26AM -0800, H. Peter Anvin wrote:
> > Since this is "the objection that won't die", I'm currently
> > considering four "ways out" of the mess created by this change that
> > went into FHS 2.0.
> >  1. totally revert, drop /var/mail, and specify /var/spool/mail
> >  2. partially revert, /var/spool/mail is a directory and /var/mail
> > must be a symbolic link to it
> >  3. allow a /var/spool/mail directory, provided that /var/mail is
> > a symbolic link to it
> >  4. allow either /var/spool/mail or /var/mail to be a directory,
> > provided that the other is a symbolic link to it.
> I believe the FHS 2.0 change was right on target.  Just about every
> UNIX implementation today has moved away from /var/spool/mail to
> /var/mail, and it has technical advantages.

May I ask what these other technical advantages are? (it might be worth
adding them to the rationale section of the FHS HTML on Dan's site, too)

The debian-policy thread [0] in May/June last year basically said ``it's
a pain to convert, /var/spool isn't particularly inappropriate, especially
for POP and IMAP users'' and ``everyone else does it, therefore we must''.

Why not require /var/mail exist, but possibly be a symlink to a different
place if necessary? This will probably end up happening on a number of
user systems anyway and has the advantage that it's trivial to become FHS
compliant, code can still get #ifdef's removed, and everyone can be happy.

Cheers,
aj

[0] http://www.debian.org/Lists-Archives/debian-policy-9805/msg00174.html

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

``Like the ski resort of girls looking for husbands and husbands looking
  for girls, the situation is not as symmetrical as it might seem.''


pgpAko0DUzbZu.pgp
Description: PGP signature

Re: Processed: Change Important Severities

[Paul Slootman]

On Sun 17 Jan 1999, Debian Bug Tracking System wrote:
> 
> > severity 31717 normal
> Bug#31717: fileutils: 'mv regularfile symlink' problems
> Severity set to `normal'.

I think that this bug _should_ be important; it's just that it's not
important for slink as the bug is only in the fileutils version in
potato... So, if this is an effort to reduce the number of release-
critical bugs (for _slink_), then IMHO it's the wrong way to go about
it.


Paul Slootman
-- 
home: [EMAIL PROTECTED] | work: [EMAIL PROTECTED] | debian: [EMAIL PROTECTED]
http://www.wurtel.demon.nl | Murphy Software,   Enschede,   the Netherlands

Re: Debian booth at LinuxTag '99?

[Federico Di Gregorio]

On Wed, Jan 20, 1999 at 02:22:14AM +0100, Martin Schulze wrote:
> Federico Di Gregorio wrote:
> > On Tue, Jan 19, 1999 at 03:54:55PM +0100, Christian Weisgerber wrote:
> > > Wichert Akkerman <[EMAIL PROTECTED]> wrote:
> > > 
> > > > End of June.. sounds like I'll be able to be there. Does anyone know any
> > > > cheap places to stay for a couple of days in the neighborhood?
> > 
> > I am thinking about being there (I'll come from italy). If you
> > find something, Wichert, can you please let me know... I CAN'T
> > read german (hope conference language will be english, at least in
> > part).
> 
> Errr, you'd better wait for the German Linux Kongress then which is 
> a real conference, with talks held in english.  As far as I remember
> the Linuxtag is an exhibition with some talks for users (contrary to
> the conference which is meant for developers or both).

I know I will be free for the end of june (LinuxTag) but I am not
sure about the Linux Kongress... one goes where he can...
Ciao,
Federico
-- 

 Federico Di Gregorio   |  /  mailto:[EMAIL PROTECTED]  
  Debian developer! | / -1http://pcamb6.irfmn.mnegri.it/~fog 
*-=$< ;-P TeX Winzard?  |/http://www.debian.org  

Re: Debian booth at LinuxTag '99?

[Federico Di Gregorio]

On Wed, Jan 20, 1999 at 02:00:02AM +0100, Christian Weisgerber wrote:
> In article <[EMAIL PROTECTED]>,
> Federico Di Gregorio <[EMAIL PROTECTED]> wrote:
> 
> > I am thinking about being there (I'll come from italy). If you
> > find something, Wichert, can you please let me know... I CAN'T
> > read german (hope conference language will be english, at least in
> > part).
> 
> The conference language will be German. In particular, all presentations
> will be in German. Sorry. I'm not entirely happy with this, but the bulk
> of the target audience are unsophisticated users who would be
> discouraged by English (even if they wouldn't admit it). It's a
> trade-off; we would probably not be able to attract more people from
> throughout Europe than we would lose from the nearby 100km radius.
> Feedback to the contrary will be given due consideration for LinuxTag
> 2000. ;-)

OK.
 
> Of course you can talk to the various exhibitors in English, and the
> mentioned Debian BOF/developers meeting could be done in English, too.

That's fine. If we gather enough english-speaking-developers german
won't be a problem (just to know, how do you say "beer" in german?)
Let's see there...

Ciao,
Federico
-- 

 Federico Di Gregorio   |  /  mailto:[EMAIL PROTECTED]  
  Debian developer! | / -1http://pcamb6.irfmn.mnegri.it/~fog 
*-=$< ;-P TeX Winzard?  |/http://www.debian.org  

Re: libpam, cracklib, and slink (was Re: Release-critical...)

[J.H.M. Dassen]

On Tue, Jan 19, 1999 at 22:38:15 -0800, Chris Waters wrote:
> At the moment, everyone who installs ppp-pam (like me) will be forced to
> install cracklib, and suffer with daily emails to root.  We need to fix
> libpam0g.  Unfortunately, the maintainer seems to be inactive, and we're
> dependent on NMUs.  (Ray, that's you!)

*grumble, grumble* There's nothing special about me as a NM.

> I think that there should be a release critical bug here, but I think it
> should be #30862:  libpam0g depends on cracklib2.

Yup. I've looked at it again, and the dependency is superflous. (I modified
PAM to link it's .so's to all the libraries they need, and -lcracklib
slipped in there because I originally looked at enabling cracklib support).

I'm now preparing an upload that'll mark PAM as orphaned.

Ray
-- 
Obsig: developing a new sig

Re: Resolutions to comments on LSB-FHS-TS_SPEC_V1.0

[Theodore Y. Ts'o]

   From: "H. Peter Anvin" <[EMAIL PROTECTED]>
   Date: Wed, 20 Jan 1999 00:19:26 -0800 (PST)

   I believe the FHS 2.0 change was right on target.  Just about every
   UNIX implementation today has moved away from /var/spool/mail to
   /var/mail, and it has technical advantages.

   If anything, specify /var/spool/mail being a symlink to /var/mail.

I agree.  I also don't think it's a big deal.  What's important is that
all of the MUA's get compiled so that they look for the mail spool in
/var/mail.  If /var/mail is a symlink to /var/spool/mail, or /u3/mail,
or something else --- that's fine.

I don't think distributions are required to move the spool directory
around as part of an upgrade; just install a symlink!  And if the user
has established a symlink so that the mail spool is on some entirely
different partition (for example, /u3/mail), then it's just a matter of
establishing a new symlink in /var/mail to point to /u3/mail.

- Ted

Re: agreeing with the DFSG (was Re: non-free --> non-dfsg)

[Ossama Othman]

Hi Craig,

> > I get the impression that my objectivity is being misinterpreted again.
> 
> not sure what you mean by that.  i thought i was quite careful to state
> that i was using a generic "you" in my examples, and not referring to you
> personally.  if you got that impression, then i apologise because that was
> not what i intended.

There is no need to apologize Craig.  I understood that you were using the
generic "you."  I just thought that you misunderstood what I was trying to
say.  "My bad." :)

> i agree. i don't think developers have to 100% agree with every single
> one of debian's policies.  I do think, however, that developers
> should agree to abide by debian policies, and working within debian's
> constitution to effect any changes, and (more importantly) they should
> agree with the "spirit" of the social contract and DFSG.

I wholeheartedly agree!

> unfortunately, "spirit" is an ill-defined and nebulous thing, hard to
> pin down exactly.  The Social Contract and the DFSG are a good attempt
> to define debian's spirit.

Very true.  In general the DFSG and the Social Contract seem to do a good
job of attempting to define Debian's spirit.  I agree with you again!
 
> your comments about leaving when/if you can no longer agree with
> debian's policies is kind of what i meant. i don't think anyone should
> be kicked out (except perhaps for extreme cases, which i cant/dont want
> to imagine right now), but that their own priorities for what they feel
> worthy of donating the time/energy to, and perhaps their own sense of
> honour, will make the decision to leave.

It seems that we have had some misunderstandings.  I am very happy that
things are clearer now.

> similarly, i think that people who don't have a committment to debian's
> "spirit" shouldn't join up as developers in the first place. they should
> find somewhere more in tune with their own beliefs...they'd be happier
> and more productive, and so would we.

Ditto!

> BTW, people have left debian in the past for several reasons - including
> running out of time (i.e they graduated or got a new job), and also over
> major disagreements in direction.  some have gone on to do other, equally
> worthwhile and valuable work either by themselves or in another group.

Yep, I remember one notable one.

> > My concern is that Debian is becoming (almost) elitist.  
> 
> what's wrong with elitism :-)
> 
> there's too much mediocrity in the world. more elitist high quality
> stuff is needed.

Well, when you put it that way... :)

> > Some people are flat out saying "conform or get out," in a sense.  Is
> > this really a healthy attitude for Debian to have?
> 
> i think you are greatly exaggerating the strength of the comments that
> have been made.

Perhaps you are right.  I don't recall my state of mind when I made that
comment ...heh, "I have no recollection of that..."

> OTOH, if someone ever did something seriously damaging to debian i
> would hope that they did have the decency to voluntary get out without
> dragging us all into a huge fight over whether they should be kicked out
> or not.

One more agreement from me!

> > The fact that my opinions go against what is apparently the Debian
> > mainstream way of thinking doesn't mean that I should leave.
> 
> however, if (after you have had your say) the majority of developers
> think you are wrong and the vote goes against you then you should either
> a) shut up about it for a reasonable period of time - several months at
> least, or b) voluntary leave if you can't do (a).

I'd agree with you more about this if more developers were more vocal
about how they feel.  Right now less then a quarter of the developers seem
to express their opinion or even vote (someone correct me if I am wrong).

> > If used properly, diversity of opinion should only help Debian.  Those
> > with opinions that differ from the mainstream should not be branded
> > "heretics" or encouraged to leave.
> 
> you could have the debian chicken (in a slashed-circle) branded across
> your forehead.
> 
> we should put that in our constitution. heretics to be branded and
> marched out with a cattle-prod. maybe have different brands for the
> different heresies so that all can see at a glance what kind of
> perversion the branded one will try to lead them into.
> 
> btw, if you think that paragraph needed a smilie then you need to get
> out more and relax a bit.

LOL!  No, no, you didn't need a smilie face.  That was really funny!  Does
this mean I don't need to relax more? :)  You know, we should send some of
debian chicken t-shirts to a certain software company we all know.

Thanks for the discussion and clarification Craig!
-Ossama
__
Ossama Othman <[EMAIL PROTECTED]>
58 60 1A E8 7A 66 F4 44  74 9F 3C D4 EF BF 35 88  1024/8A04D15D 1998/08/26

Re: Resolutions to comments on LSB-FHS-TS_SPEC_V1.0

[H. Peter Anvin]

> > I would *much* prefer this, I just didn't think I'd be able to win
> > the argument.
> 
> Since this is "the objection that won't die", I'm currently
> considering four "ways out" of the mess created by this change that
> went into FHS 2.0.
> 
>  1. totally revert, drop /var/mail, and specify /var/spool/mail
>  2. partially revert, /var/spool/mail is a directory and /var/mail
> must be a symbolic link to it
>  3. allow a /var/spool/mail directory, provided that /var/mail is
> a symbolic link to it
>  4. allow either /var/spool/mail or /var/mail to be a directory,
> provided that the other is a symbolic link to it.
> 
> I'm personally most in favor of #2 or #3.  I think #1 is almost as bad
> as the original change in FHS 2.0 and #4 is potentially confusing.  No
> matter what, FHS 2.1 will specify at least #3, if not one of the other
> possibilities.
> 
> And for each possibility _PATH_MAILDIR is changed to reflect the
> actual directory, not the symbolic link.
> 
> - Dan

I believe the FHS 2.0 change was right on target.  Just about every
UNIX implementation today has moved away from /var/spool/mail to
/var/mail, and it has technical advantages.

If anything, specify /var/spool/mail being a symlink to /var/mail.

-hpa

Re: agreeing with the DFSG (was Re: non-free --> non-dfsg)

[Craig Sanders]

On Mon, Jan 18, 1999 at 06:19:46PM -0600, Ossama Othman wrote:
> Hi Craig,
> 
> I get the impression that my objectivity is being misinterpreted again.

not sure what you mean by that.  i thought i was quite careful to state
that i was using a generic "you" in my examples, and not referring to you
personally.  if you got that impression, then i apologise because that was
not what i intended.

> IMHO, the idea that developer's should agree with the DSFG and/or the
> social contract in their entirety is dangerous and will only hinder
> Debian. I don't agree with all of Debian's policies, nor should I have to.
> However, I became a Debian developer knowing full well what Debian's
> policies are and I will follow them.  

i agree. i don't think developers have to 100% agree with every single
one of debian's policies.  I do think, however, that developers
should agree to abide by debian policies, and working within debian's
constitution to effect any changes, and (more importantly) they should
agree with the "spirit" of the social contract and DFSG.

unfortunately, "spirit" is an ill-defined and nebulous thing, hard to
pin down exactly.  The Social Contract and the DFSG are a good attempt
to define debian's spirit.

> When I can longer do so, and that may never happen, I will leave.
> This isn't a threat or anything of the sort.

your comments about leaving when/if you can no longer agree with
debian's policies is kind of what i meant. i don't think anyone should
be kicked out (except perhaps for extreme cases, which i cant/dont want
to imagine right now), but that their own priorities for what they feel
worthy of donating the time/energy to, and perhaps their own sense of
honour, will make the decision to leave.

similarly, i think that people who don't have a committment to debian's
"spirit" shouldn't join up as developers in the first place. they should
find somewhere more in tune with their own beliefs...they'd be happier
and more productive, and so would we.


BTW, people have left debian in the past for several reasons - including
running out of time (i.e they graduated or got a new job), and also over
major disagreements in direction.  some have gone on to do other, equally
worthwhile and valuable work either by themselves or in another group.


> My concern is that Debian is becoming (almost) elitist.  

what's wrong with elitism :-)

there's too much mediocrity in the world. more elitist high quality
stuff is needed.


> Some people are flat out saying "conform or get out," in a sense.  Is
> this really a healthy attitude for Debian to have?

i think you are greatly exaggerating the strength of the comments that
have been made.

OTOH, if someone ever did something seriously damaging to debian i
would hope that they did have the decency to voluntary get out without
dragging us all into a huge fight over whether they should be kicked out
or not.


> I happen to admire Debian a great deal.  If I feel that Debian may be
> doing something that may hurt itself then I will speak up about it, just
> as any Debian user should.  

yes.  "should" is the right word here.

> The fact that my opinions go against what is apparently the Debian
> mainstream way of thinking doesn't mean that I should leave.

however, if (after you have had your say) the majority of developers
think you are wrong and the vote goes against you then you should either
a) shut up about it for a reasonable period of time - several months at
least, or b) voluntary leave if you can't do (a).


> If used properly, diversity of opinion should only help Debian.  Those
> with opinions that differ from the mainstream should not be branded
> "heretics" or encouraged to leave.

you could have the debian chicken (in a slashed-circle) branded across
your forehead.

we should put that in our constitution. heretics to be branded and
marched out with a cattle-prod. maybe have different brands for the
different heresies so that all can see at a glance what kind of
perversion the branded one will try to lead them into.

btw, if you think that paragraph needed a smilie then you need to get
out more and relax a bit.

craig

--
craig sanders

Re: Resolutions to comments on LSB-FHS-TS_SPEC_V1.0

[Daniel Quinlan]

[ I added the FHS and debian-devel mailing lists to the Cc list, so
  a huge number of people are now being Cc'ed -- sorry. ]

Florian La Roche <[EMAIL PROTECTED]> writes:

>> So if there are no other bigger standards that would make it very
>> convenient to move all Linux-distributions to /var/mail and
>> abandon /var/spool/mail, I'd hope that /var/spool/mail will be
>> listed as de-facto-standard of Linux systems.

Erik Troan <[EMAIL PROTECTED]> writes:

> I would *much* prefer this, I just didn't think I'd be able to win
> the argument.

Since this is "the objection that won't die", I'm currently
considering four "ways out" of the mess created by this change that
went into FHS 2.0.

 1. totally revert, drop /var/mail, and specify /var/spool/mail
 2. partially revert, /var/spool/mail is a directory and /var/mail
must be a symbolic link to it
 3. allow a /var/spool/mail directory, provided that /var/mail is
a symbolic link to it
 4. allow either /var/spool/mail or /var/mail to be a directory,
provided that the other is a symbolic link to it.

I'm personally most in favor of #2 or #3.  I think #1 is almost as bad
as the original change in FHS 2.0 and #4 is potentially confusing.  No
matter what, FHS 2.1 will specify at least #3, if not one of the other
possibilities.

And for each possibility _PATH_MAILDIR is changed to reflect the
actual directory, not the symbolic link.

- Dan

Re: LSB?

[Daniel Quinlan]

Joseph Carter <[EMAIL PROTECTED]> writes:

> Reasonable objection notwithstanding, I intend to write a letter to those
> responsible for the LSB to attempt to raise the issues we have with their
> current proposal.  I would appreciate discussion on these issues in other
> parts of this thread.  I encourage those who have a significant opinion
> not yet voiced in the LSB thread found on debian-devel to write them down
> either as part of the thread or directly to me to aid in the drafting of
> this letter.

I'm jumping in the discussion a little late (I just joined this list),
but please let me try to help explain things...

I'd like to fix the problems that Debian developers are finding in the
LSB.  I think most of the i386isms are due to problems in FHS (you can
blame me), which will be fixed in FHS 2.1.  Remember that the original
FHS dates back to when i386 was the only architecture included in
Linus' kernel. (Patches to the FHS source are welcome.)

I also imagine that some people have some concerns with the TOG FHS
test suite.  Basically, anyone is free to make a contribution to the
LSB test suite effort -- provided that:

  - It's free ("Open Source") and released under the license we say it
should use.  (Since we haven't chosen that license yet, Andrew Josey
is using the Artistic license for now, but he agreed to switch when
the LSB makes that decision.)
  - It must be in sync with the LSB written spec (which references the
FHS) and the LSB sample implemention should pass it.
  - It won't be incorporated into LSB 1.0 without passing muster of
the LSB test suite group (headed by Dale Scheetz).

The technical problems you note are due to deficiencies in the written
specification (in FHS 2.0), and are not mistakes on the part of Andrew
Josey of the Open Group.

Andrew has contributed more to the LSB effort than most people.  BUT,
the TOG is *not* defining LSB.  Linux people are defining it -- and if
a company passes every hurdle we insist that they pass, why shouldn't
we allow them to help?  (I haven't seen any marketing spin from TOG,
but if there is any, please point me to it.)

If anyone has interest in helping develop LSB test suites (or other
parts of the LSB), please email me and Dale Scheetz <[EMAIL PROTECTED]>.

- Dan

(By the way, before taking on other projects, I was heavily involved
in Debian, from the early days with Ian Murdock through Bruce Perens.)

Re: Debian Weekly News - 12 to 18 Jan 1999

[Achim Oppelt]

Hello Joey,

Thank you very much for your Debian Weekly News! I find them quite helpful
for keeping up-to-date with Debian development without having to read all
the mailing lists.

Just one minor criticism:

>  * For all those interested in XFree 3.3.3, Ben Gertzfield [15]posted
>that the Debian JP group has made their own 3.3.3 packages. They
>can be found at [16]ftp.debian.or.jp. Your mileage may vary, but
>it may be something to try before pulling you hair out when the
>binaries from the XFree group give you problems.

The name of the product is XFree86 (even though it is no longer i86
specific). And the name of the group of people creating it is The Xfree86
Project, Inc. While such points certainly don't matter in informal
discussions on mailing lists, I think that it would be a good idea to get
the terms right in a more or less official newsletter.

Achim

Re: non-free --> non-dfsg

[Ossama Othman]

Hi Manoj,

>  Ossama> Looking at it from the author's point of view, the author may
>  Ossama> feel that Debian's definition of "free" is wrong and his is
>  Ossama> right.  So he may also think about Debian that "there is
>  Ossama> indeed something wrong that they should know about."
> 
>   This is all very interesting, and so on, but where is this
>  leading? All kinds of people may have all kinds of opinion about
>  Debian. The point is?

The point is that it easy to say "I am right and you are wrong."  Who
makes us right and them wrong?

-Ossama

Re: Where does 'www-data' come from?

[Brian May]

In article <[EMAIL PROTECTED]> you write:
>
>"Bart" == Bart Schuller <[EMAIL PROTECTED]> writes:
>
>Bart> Is www-data the uid of the web server process or is it the owner
>Bart> of the served files?
>
>Hm, good point.  At the moment its both -- /var/www is installed as
>www-data.www-data, but other packages like MRTG make subdirs owned by
>root.  And CGI is off in /usr/lib/cgi-bin, root.root per Policy.
>
>Might be a good idea to change the default ownerships.

Maybe the web files should be owned by "www-data" and the web
process should be owned by "www" or "httpd"? This way the
descriptive names continue to make sense. Practical
speaking, it is probably just as good to make web files
owned by root, however, then the name "www-data" won't
be the owner of any data.

Re: agreeing with the DFSG (was Re: non-free --> non-dfsg)

[Ossama Othman]

Hi Manoj,

>  >> Those with opinions that differ from the mainstream should not be
>  >> branded "heretics" or encouraged to leave.
> 
>   Why not? 

Isn't that rather extreme? :)

>   When views of people differ in detail ,there is basis for a
>  dialogue. When even the fundamentals are contested, there is no
>  common ground to build anything out of. (An extreme example is the
>  white supremascist who went around trashing martin luther king, jr,
>  in an alabama group this last weekend -- his views on racsm are so
>  far from mine that there is no point even trying to interact with
>  him). 
> 
>   Admttedly, the situation we have here is not anywhere near as
>  extreme as all that, but in pinciple I see nothing inherently wrong
>  about the project insisting that there be some basis or commonality
>  of philosophy in the candidates that are approved for inclusion in
>  the group of developers, if only to prevent anarchy as the project is
>  torn apart by wildly differing factions.

Philosophy of the DFSG is fine but asking someone to agree word for word
with any declaration or statement is asking for a lot.  I am going to give
an extreme example too so please bear with me.  Let's assume that we live
in a police state where speaking up against the law is unheard of and
punishable.  Which would you prefer: living in a society where people
follow the laws but speak up if the law isn't a fair one in their opinion,
or would you prefer the police state?  I greatly prefer the society where
one is allowed to speak up.  Do we want Debian to be a police state of
sorts?  I admit that this is an extreme analogy but I think that it
conveys what I am trying to say.

>   The DFSG defines what Deban stands for. Asking developers to
>  agree with it is not uncalled for.

What do you mean by "agree?"  With its spirit or its contents?  Asking
them to agree with its spirit is fine.  Asking them to abide by the DFSG
is fine.  However asking them to agree with everything it says isn't fair
and reflects negatively on Debian as an organization that stands for
software freedom.

-Ossama

__
Ossama Othman <[EMAIL PROTECTED]>
58 60 1A E8 7A 66 F4 44  74 9F 3C D4 EF BF 35 88  1024/8A04D15D 1998/08/26

>   manoj
> -- 
>  "No job too big; no fee too big!" Dr. Peter Venkman, "Ghost-busters"
> Manoj Srivastava <[EMAIL PROTECTED]>
> Key C7261095 fingerprint = CB D9 F4 12 68 07 E4 05  CC 2D 27 12 1D F5 E8 6E
> 
> 
> -- 
> To UNSUBSCRIBE, email to [EMAIL PROTECTED]
> with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
> 
>