bzip2 and multiarch transition

[santiago]

Hi,

(Please CC me when answering)

I've just uploaded a new bzip2 revision and I think I need to revert a
change. bzip2 used to build cross architecture lib{32,64}bz2* packages,
but multiarch has obsoleted them. To stop building those packages (and
close #736815), and to look for a smooth transition, I added
conflicts/replace/provides control fields in the -1.0 and -dev packages.
But I realized that those fields were wrong, at least useless (I also
found [1]). So, to be sure, should I just drop the old lib{32,64}bz2*,
without any transition mechanism? (no other package  depends on them
now.)

Regards,

Santiago

[1] https://lists.debian.org/debian-devel/2012/03/msg00762.html


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140728053514.GA12338@nomada

Re: bzip2 and multiarch transition

[santiago]

El 28/07/14 a las 21:10, Bastian Blank escribió:
> On Mon, Jul 28, 2014 at 08:59:26PM +0200, Philipp Kern wrote:
> > I guess you could offer lib32bz2 as a transitional package on the 32bit
> > arch, depending on libbz2 of its own arch and vice versa for lib64?
> 
> Since when does apt consider a:amd64 -> a:i386 a valid upgrade path?
> 
> The only reason to ship this in the future is to ease upgrades, but I
> don't see how this would work.

It wouldn't be an a:amd64 -> b:i386 dependecy (not a:i386)?

As Dimitri says, it only works when i386/amd64 is enabled. The cleanest
option seems to be to just drop the lib32bz* packages.
For the record, I run some tests:

Case 1: i386 multiarch is not enable: apt does not consider to upgrade
it automatically, however apt-get install lib32bz2-1.0 understands the
dependency, but since it cannot satisfy it, it exits with error.
aptitude automatically considers to upgrade lib32bz2-1.0, but given the
unmet dependency, it removes the package as first solution.

Case 2: i386 mulitarch enabled: both apt-get and aptitude automatically
consider the upgrade and solve the dependencies.

I've found more issues trying to downgrade.

Thanks for your comments,

Santiago


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140731145844.GA7155@nomada

Re: software updates file in /usr -- policy bug?

[Santiago Vila]

On Mon, 25 Oct 2004, martin f krafft wrote:

> Hi all,
> 
> apt-spy and pciutils (and possibly others) contain methods to update
> a database integral to their operation.
> 
>   - `apt-spy update` downloads the list of available Debian mirrors
> to /usr/share/apt-spy (see #277816).
> 
>   - `update-pciids` downloads a new /usr/share/misc/pci.ids
> 
> I think these are both in violation with the FHS, which states
> (Chapter 4, emphasis mine, using caps instead of asterisks for
> readability):
> 
>   "/usr is shareable, READ-ONLY DATA. That means that /usr should be
>   shareable between various FHS-compliant hosts and MUST NOT BE
>   WRITTEN TO."
> 
> The apt-apy maintainer thinks this is okay because (from the bug
> report):
> 
>   apt-spy does not "dynamically update".  It updates *if and ONLY
>   if* you ask it to.  I do not see this as a violation of the spirit
>   of the FHS.  I'm more than happy to have discussion about this.
> 
> If this holds, then why does `apt-get update` modify files in
> /var/lib/apt/lists, and why is /var/lib/dpkg/status not really
> /usr/lib/dpkg/status?
> 
> Well, two wrongs don't make a right, nor does APT/dpkg's choice for
> /var make using /usr for changeable resource data wrong for
> everyone, but I still think that apt-spy's mirror list and the PCI
> IDs should be kept in /var, since they are variable data.

Having a program asking the user "do you want to violate the FHS?"
does not make it not to be a violation. I would much prefer not to
have to answer such questions.

Some people might want to have /usr mounted read-only except when
using dpkg/apt to upgrade the system. The FHS says this should work,
so any program which fails because it tries to write to /usr could be
considered as a bug.

Even if the file is updated only by the postinst, it is useful to know
that you can recover a broken system from scratch by having:

* A backup copy of /etc, /var, /home, /usr/local, etc. (but not /usr).
* The list of installed packages.

I think this is a good property of the system that we should try to keep.

Would the user benefit from having the freedom to change apt-spy or pci.ids?
If yes, then those files would be much better placed in /etc. Just because
it is a "database" does not mean it may not be modified by the user.
Think about /etc/services for example.

Re: Is membership in staff supposed to imply root access?

[Santiago Vila]

On Mon, 1 Nov 2004, Rob Browning wrote:

> It looks like our installs set up /usr/local/bin to be group staff and
> writable by staff, and place /usr/local/(s)bin before /usr/(s)bin in
> root's PATH.
> 
> I was a little surprised because I thought we used to exclude the
> /usr/local directories from root's path by default, but perhaps we
> changed our policies or perhaps my memory is mistaken.

We have had /usr/local directories in the PATH for root at least since 1995
(by looking at the "base" package version 1.1.0-13).

> Also, I wonder if our handling of /usr/local isn't a bit inconsistent
> since it doesn't look like we include /usr/local/lib in the ld.so
> defaults.

Yes, I wonder the same.

Moving PATH from /root/.profile to /etc/profile

[Santiago Vila]

Hi.

By popular demand, I plan to move the PATH definition for root from
the default /root/.profile to the default /etc/profile. If anybody
knows a good reason why this should not be done before the release of
sarge, please say so. After an amount of time which is reasonale for a
"frozen" package like this (say, 20 days), I will ask the release
managers to let base-files enter sarge.

Thanks.

Re: sarge security (was: Re: Release update: please upload to unstable; toolchain; buildds; ...)

[Santiago Vila]

On Sat, 13 Nov 2004, Martin Schulze wrote:

> Adrian 'Dagurashibanipal' von Bidder wrote:
> > On Tuesday 09 November 2004 23.44, Colin Watson wrote:
> > 
> > >   N+0 days
> > >   Official security support for sarge begins
> > 
> > Will the start of official security support for sarge be announced widely, 
> > to get as much testing as possible? (Like: general debian-announce, press 
> > contacts, ...)
> 
> No.  Why should it?  The new release of Debian will be widely announce.
> 
> How do you want to test official security support?  Suddenly discover
> loads of vulnerabilities?

The day it is officially known that security support exist for sarge,
lots of people will migrate their servers to sarge, even if it is not
released as stable yet, so yes, it would be interesting that it is
announced, widely or not, so that sarge (not the security support)
get as much testing as possible before the release.

Bug#284114: ITP: mpegdemux -- a MPEG1/2 system stream demultiplexer

[Santiago Vila]

Package: wnpp
Severity: wishlist

Package name: mpegdemux
Version : 0.1.2
Upstream Author : Hampa Hug
URL : http://www.hampa.ch/mpegdemux/
License : GPL version 2

Description: a MPEG1/2 system stream demultiplexer
 Mpegdemux is an MPEG1/MPEG2 system stream demultiplexer. It can be
 used to list the contents of an MPEG system stream and to extract
 elementary streams.

A preliminary package may be found here:

http://people.debian.org/~sanvila/mpegdemux

Re: add Date: field to Packages files

[Santiago Vila]

On Sat, 11 Dec 2004, Dan Jacobson wrote:

> Say, perhaps a "Date:" field could be added to Packages files.
> I mean even dog food has the date stamped on it these days.
> Even my crumby message has a Date: field.
> Sure, as your eyes scan the MD5sum: field, the package's DNA is
> registered in your brain. But us old fashioned types would still like
> a Date: field.
> > Well Jacobson, the date can be clearly seen at http://.../pool/n/norbowitz
> But Mom said no more searching the web for dates, so now I'm offline.

Even offline, files have time stamps in most modern filesystems out there.
Just remember to keep it when you download the Packages files, as it's
usually as available as the file itself.

Re: amd64: ftp-masters questions

[Santiago Vila]

On Sat, 11 Dec 2004, Martin Michlmayr - Debian Project Leader wrote:

> My recollection is that all technical concerns were addressed and that
> the port would go in after the mirror issues will be sorted out (which
> will happen some point after sarge).

Why after sarge? Nobody knows when sarge will be released.

Re: strange (or unexplainable) permissions on /var/log/*

[Santiago Vila]

On Sun, 12 Dec 2004, martin f krafft wrote:

> I am trying to make sense of /var/log/*. I noticed the following
> peculiarities:
> 
>   - user.log is 0640. However, aren't "user" messages possibly
> relevant to users? If so, I suggest making the file 0644.

640 is not necessarily broken. There might be inter-user privacy issues.

>   - uucp.log, mail.* and news/* are 0644. I would say that these
> should be 0640.

My mail.* files are 640 and I don't remember having done anything
special for that to happen.

>   - why is dmesg 0644? This is not really a problem, but do users
> need access to the boot messages?

Since any user can run the dmesg command, it would not add any extra
privacy to such information.

/etc/profile not a conffile anymore

[Santiago Vila]

Hello.

I plan to make /etc/profile a "configuration file which is not a conffile
but it's created by postinst instead", so that dpkg never asks about it,
not even once every two years. The prototype is at 

http://people.debian.org/~sanvila/base-files

I've checked that upgrades work (they already worked for /etc/inputrc)
and more important, that it does not break debootstrap, but if you
know of any package that might break, please say so, or better fix it
to work regardless of /etc/profile being a conffile or not.  Nobody
but the system admin should modify /etc/profile anyway, so I'm not
going to feel responsible for making old bugs more visible.

Thanks.

Re: /var/log on Debian systems

[Santiago Vila]

On Tue, 14 Dec 2004, martin f krafft wrote:

>   - first suggest to make /var/log group adm and setgid, so that any
> new files automatically belong to group adm.

No, not again. Please google a little bit more before proposing things.
For example, read the complete logs for Bug #35504.

Re: murphy is listed on spamcop

[Santiago Vila]

On 2 Jan 2005, Thomas Bushnell BSG wrote:

> My point was that you cannot justify the bad things that happen as a
> result of your actions by saying that your goals cannot be reached
> without such bad things happening.

However, the same could be said about the result of our *inactions*.

When bad things happens *anyway*, it's often a matter of deciding about
the least of two evils, so yes, sometimes a bad thing justifies an
action if such action avoids another thing which is much worse.

For example, implementing greylisting in master would be bad for you,
because you demand that mail is transmitted without any delay at all.

However, as greylisting would reduce the level of spam to 1/10th, by
not implementing it we are suffering from a much worse thing than
delaying email a little bit.


BTW: I've heard that alioth uses greylisting, does somebody know what
would it take to implement it in master as well?

Re: murphy is listed on spamcop

[Santiago Vila]

On Sun, 2 Jan 2005, Thomas Bushnell BSG wrote:

> Santiago Vila <[EMAIL PROTECTED]> writes:
> 
> > For example, implementing greylisting in master would be bad for you,
> > because you demand that mail is transmitted without any delay at all.
> 
> When have I ever made such a demand?

I was just following your line of reasoning:

"You cannot justify the bad things that happen as a result of your
actions by saying that your goals cannot be reached without such bad
things happening", where:

action = greylisting
bad things that happen = delayed email

Try reducing the level of spam to a 1/10th without false positives
and without delaying any email.

Re: Bug#292759: shell script sniplets in /usr/bin?

[Santiago Vila]

On Mon, 31 Jan 2005, Martin Schulze wrote:

> Adrian von Bidder wrote:
> > > You wouldn't need to change "every" script - you just need to move
> > > gettext.sh to /usr/share/gettext/scripts and create /usr/bin/gettext.sh
> > > with the content Sean suggested.
> > 
> > Which buys us what?
> > 
> > This new gettext.sh would still be a non-executable script snippet
> > which is not intended to be called by the user directly, as far as
> > I can understand.
> 
> But it has the executable flag turned on which makes it
> executable by users - and we'll get bug reports about useless
> scripts polluting /usr/bin.
> 
> Err... Is that really an advantage over the current situation?

For the record: The next upload of gettext for unstable (whenever it will be)
will move gettext.sh to /usr/share/gettext and will have /usr/bin/gettext.sh
as a symlink to it.

Whether that's temporary or definitive, I don't know yet, but it would
not be wise to do more than that at this point.

The author usually fixes bugs in a portable and elegant way, so I hope
he and the people who maintain the FHS agree on the right location for
gettext.sh.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Package xxx has broken dep on yyy: normal?

[Santiago Vila]

On Wed, 16 Feb 2005, Dan Jacobson wrote:

> Well OK, but please be aware of the cases where a kid leaves his
> village for a trip to the big city and his single chance to do an
> apt-get dist-upgrade.  He can't just try again tomorrow if things
> don't work out.

Unstable is definitely not for people who "can't try again".
Try this if you don't understand:

awk 'NR >= 258 && NR <= 278' /usr/share/common-licenses/GPL


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

procmail and Large File Support

[Santiago Vila]

Hello.

I have several reports saying procmail does not support mbox folders
larger than 2GB. Questions:

* Am I right to think that adding -D_FILE_OFFSET_BITS=64 to CFLAGS
should be enough to fix this, as explained by this URL?:

http://www.suse.de/~aj/linux_lfs.html

The version in experimental has -D_FILE_OFFSET_BITS=64, and it works
on files larger than 2GB, but I have only tested it on the i386
architecture.

* Would the release managers approve this change for sarge?

Thanks.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: procmail and Large File Support

[Santiago Vila]

On Fri, 25 Feb 2005, Steve Langasek wrote:

> > The version in experimental has -D_FILE_OFFSET_BITS=64, and it works
> > on files larger than 2GB, but I have only tested it on the i386
> > architecture.
> 
> Please use the value of $(getconf LFS_CFLAGS) instead; it appears (based on
> past exim4 bug reports) that using -D_FILE_OFFSET_BITS=64 on natively 64-bit
> systems such as alpha causes surprising breakage of some glibc APIs.

Ok, will do that.

> > * Would the release managers approve this change for sarge?
> 
> If this is the only change, yes.

Hmm, while we are at it, I think it would be good to fix #295604 as well.
This is the (trivial) patch:

diff -ru procmail-3.22.orig/src/header.h procmail-3.22/src/header.h
--- procmail-3.22.orig/src/header.h 1999-07-06 08:12:22.0 +0200
+++ procmail-3.22/src/header.h  2005-02-17 00:34:47.0 +0100
@@ -168,3 +168,5 @@
 X(readreceiptto,   "Read-Receipt-To:")   /* miscellaneous extension */
 X(fakesender,  "Fake-Sender:")
 X(envelopeto,  "Envelope-To:")/* exim extension */
+X(useragent,   "User-Agent:")
+X(nntppostingdate, "NNTP-Posting-Date:")


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Bits (Nybbles?) from the Vancouver release team meeting

[Santiago Vila]

On Sun, 13 Mar 2005, Steve Langasek wrote:

> To be eligible for inclusion in the archive at all, even in the
> (unstable-only) SCC archive, ftpmasters have specified the following
> architecture requirements:
>
> [...]
>
> - the architecture must have successfully compiled 50% of the archive's
>   source (excluding architecture-specific packages)

I think this requirement by itself will kill the development of
non-Linux architectures via the following vicious circle:

(a) Lots of packages do not build because of Linuxisms in the source code.
(b) Because the architecture is not in the archive at all, people will
probably care very little about portability bugs.
(c) Because people do not care about removing Linuxisms, the architecture
will never reach 50% of the archive's source.
(d) Back to (a).


If we care about disk space in the mirrors, fine: Let's put the main
architectures in ftp.debian.org to be mirrored everywhere and leave
the others in someotherplace.debian.org, not to be mirrored everywhere,
but dropping architectures from the archive at all (i.e. not even
someotherplace.debian.org) when disk storage is so cheap these days
does not make much sense.

So I hope you will reconsider about the above rules.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

ITK: debmake

[Santiago Vila]

Greetings.

There are less than 80 packages in unstable still using it, and there
is an excellent package called debhelper which can do everything that
debmake does and probably much better, so it does not make much sense
to keep debmake alive forever.

Therefore, I hereby announce my Intention To Kill debmake.

The current plan is as follows:

Stage 1. "Please do not create new packages using debmake".

This started a year ago when deb-make was removed from the debmake
binary package, leaving just the debstd tool. However, there are a few
more things that could be done, and this is where help would be welcome,
for example:

*) If you are a sponsor, you are welcome to refuse to upload a package
that uses debmake.

*) If you are a ftp-master, you are more than welcome to reject a package
in the NEW queue if it's a completely new package and it uses debmake.

*) If you maintain documentation from the DDP, you are welcome to
remove any documentation or howto explaining how to use debmake to
create a debian package. This includes translations.


Stage 2. "Please switch away from debmake".

This is the stage that starts today. So, everybody please, switch away
from debmake. From past experience converting orphaned packages to
debhelper, I would say that debhelper is the logical choice, but every
person has his preferences regarding helper packages.

In addition to the items listed above, I suggest this:

*) If you are the maintainer of lintian or a similar tool, you are welcome
to add a check that gives a warning if a package uses debmake.

*) Please don't file any bugs yet.


Stage 3 will start when the number of packages using debmake is "low enough".
If the release managers agree, RC bugs would be filed against any
remaining packages. When the number is zero, I'll ask ftp-master to
remove debmake from the archive.

As a realistic goal, I estimate that etch will be the last release
containing debmake, but of course, I would be deligthed to see it
happen sooner.

Thanks.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: ITK: debmake

[Santiago Vila]

On Fri, 30 Dec 2005, Adrian von Bidder wrote:

> On Friday 30 December 2005 03.18, Anthony Towns wrote:
> > Santiago:
> > > As a realistic goal, I estimate that etch will be the last release
> > > containing debmake, but of course, I would be deligthed to see it
> > > happen sooner.
> >
> > It would be pretty lame if we couldn't do this in less than a year...
> 
> I suggest release goal: no package in etch to be shipped using debmake, but 
> I also suggest still shipping a 'final' version of debmake with etch, 
> containing a big fat warning in its description that its an obsolete 
> package.  Reason: some people may have been doing private packages with 
> debmake (is this realistic? no idea. If not, forget this.), and this would 
> probably be the best communication channel to those users.  (Yes, we can't 
> force them to look at the updated package description...)

The reason I've not suggested a release goal is that you would not
believe how long it takes sometimes to remove a package from a
build-depends, even if that's everything you have to do
(see Bug#288797 for example).

We already have a lot of things to worry about in etch, and getting
rid of debmake is not a super-important item, so there is no hurry.
In fact, I would like to see debmake 3.8.2 in a stable release before
removing it, as it fixes Bug #270900 (which was not trivial to fix).
This is the final release I would like to see in archive.debian.org.


Filing wishlist bugs now is an option, provided there is a consensus
that 78 wishlist bugs aren't too many bugs :-)


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: ITK: debmake

[Santiago Vila]

Ok, to make things gradual, this is what I plan to do:

* Announce this in -devel-announce to celebrate the new year.

* Wait a few weeks.

* Submit wishlist bugs against all packages affected (which I hope
they will not be as much as 78 by then).

* After the release of etch, debmake will be removed, and the bugs
will become RC.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Nags...

[Santiago Vila]

-BEGIN PGP SIGNED MESSAGE-

On Mon, 15 Dec 1997, Christopher C Chimelis wrote:

> FYI, I'm receiving all of the bug system nags for Christian Linhart for
> his abandoned packages (xarchie and bibindex).  I guess his account was
> eliminated from master and my master account username is the same as his
> old one, so the bug system is nagging me.

Please, tell Brian White about this. Current maintainer for bibindex in
hamm is "Debian-QA Group", so you should not receive any message about
that because of bibindex.

Thanks.

-BEGIN PGP SIGNATURE-
Version: 2.6.3ia
Charset: latin1

iQCVAgUBNJWaDyqK7IlOjMLFAQF5KgP7Bp46H6sizo4/lRSLHv4uU7ZthPHVl1SK
GZzCFkcekhf26umwtppaqr5eWfeVls9PvVBsNrHeq2et9WkyVSLxmksTs7n68m6Z
sLEgzGpAi4OijZpopz5pF7Sd2mg0JbsloCX0dkHhJtOlHcEPKXQUygEGWh1rvJMZ
ENyqB4ApBb8=
=EnF/
-END PGP SIGNATURE-


--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] . 
Trouble?  e-mail to [EMAIL PROTECTED] .

Re: What warrants a non-maintainer release number?

[Santiago Vila]

-BEGIN PGP SIGNED MESSAGE-

On 17 Dec 1997, James Troup wrote:

> Michael Alan Dorman <[EMAIL PROTECTED]> writes:
> 
> > This is part of an email exchange Sven and I had.  Simply put, I put
> > in a new alpha binary of dpkg-1.4.0.19 that represented nothing but
> > a recompile to pick up new libg++, ncurses, etc.  Sven suggested
> > that this warranted a non-maintainer-release number, whereas I had
> > gotten the idea that non-maintainer-releases suggested code changes.
> 
> I hope Guy will reject that.  If the binary changes, the version
> number should change.

This is that way because our package system does not allow several binary
packages for the same source package. But it should.

> Things break if you don't increase the version
> number (e.g. automatic upgrade and bug reporting) and you don't have
> to a source release to do a non-maintainer release, just add a new
> entry to the changelog before you recompile.

Again this is a limitation of our current source|binary packaging scheme.
Does not mean it has to be that way.

> What advantage do you see in *not* changing the version number?

Changing the *source* version number would be a gratuitous change.
Packages coming from the same source should be allowed to share that
common source, without changing it at all. That is the meaning of source.
But we currently include the changelog in the source and make it to refer
both to binary and source changes. This is not very elegant.

It would be really nice to have something like epochs for
binary packages coming from the same source.

i.e.

hello_1.3-0 (compilation 0) is older than hello_1.3-0 (compilation 1)
and dpkg will see the need to upgrade.

-BEGIN PGP SIGNATURE-
Version: 2.6.3ia
Charset: latin1

iQCVAgUBNJghtCqK7IlOjMLFAQEdYwQAqG2tfw5hgxDS8CFPnsriZNVTEKe3DokP
D8hZAfM2opG+hrPxkBajgsHh4rh/fqsPptEQEsZHIi71HqAN3qjhs7kTvs+PxCQf
3AVrIfToF96ROY29RQW5IS8uj88Aj9eCpElI7e5VoFfoFGXI3zcWf/lRkldbFJHo
QZqGK+wHjuw=
=9qvc
-END PGP SIGNATURE-


--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] . 
Trouble?  e-mail to [EMAIL PROTECTED] .

Re: What warrants a non-maintainer release number?

[Santiago Vila]

-BEGIN PGP SIGNED MESSAGE-

On 17 Dec 1997, James Troup wrote:

> you don't have to [do] a source release to do a non-maintainer release,
> just add a new entry to the changelog before you recompile.

Well, if this is so, this would be the best solution.

Just call it "dpkg-1.4.0.19.0" and do not upload a new diff.

This way, there will be no traces of 1.4.0.19.0 in 1.4.0.20's changelog.

-BEGIN PGP SIGNATURE-
Version: 2.6.3ia
Charset: latin1

iQCVAgUBNJkLJyqK7IlOjMLFAQGwJwP8CZTQE+WZHBnXAlBoFhFeUZFpDgdX8XIi
VzsoPcmskG98eISx5iEMi1AnEVyBWkXPKJCzyn8H7Lb0YsYsxY4JtG/ny/oHZoco
PG+ectPE7uXk8Z9ZJUdUEYnnMejZyrLZuS7mb4ZDj7JXrTULlO4zCPSDxPwnwPqu
Vlzr7H4fUqY=
=WPFs
-END PGP SIGNATURE-


--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] . 
Trouble?  e-mail to [EMAIL PROTECTED] .

Re: libc6 pine ?

[Santiago Vila]

-BEGIN PGP SIGNED MESSAGE-

Gergely Madarasz wrote:
> I was just informed (thanks, Che ;)) that there is a newer pine
> source-only package in non-free... does it compile and work with libc6 ? 

It compiles, but it does not "work" (it does, but not in a multi-user
environment, so installing it in a 30-user machine is highly discouraged).

If somebody here wants to take it and fix the huge bugs it has, go ahead.

Or else: If you want to fix it but do not want to maintain it, send me
the patches and they will be included in the next release with
appropriate credits in changelog.Debian.

Thanks.

-BEGIN PGP SIGNATURE-
Version: 2.6.3ia
Charset: latin1

iQCVAgUBNK5yHyqK7IlOjMLFAQFFBAP9EIlMm8ZLUeNzuaflNOCEz3GjwDWxMyXd
v7QngBngXcN4MS8Od0iJsuZyZNfbxJwiw6080utuUIcYVX6f+8gJVpOWo8bsmlfp
5KdzfY+8ia3jNX5rMuLstr2tPWZxQuntaJOlr/SYdDJ0BLnJxZj4PWttGMLr7ZHy
QE0ga1QvFsA=
=YDAq
-END PGP SIGNATURE-


--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] . 
Trouble?  e-mail to [EMAIL PROTECTED] .

Re: What warrants a non-maintainer release number?

[Santiago Vila]

-BEGIN PGP SIGNED MESSAGE-

On Mon, 5 Jan 1998, Dale Scheetz wrote:

> It was my understanding that the only time it is necessary to upload a new
> source package was when the upstream source changed.

Here, "source" means "Debian source", i.e. orig source + diff.
In fact, you upload a new "Debian source" each time you upload a new diff.

We are trying to clarify what happens when you just "recompile" a package.


BTW: After "the version number has to be incremented too (this is, the
source package has to be changed and uploaded again) to make sure
dpkg/dselect recognizes the changed package." I would add:

"You may want to use a point version number x.1 or x.5 and make it to
disappear from the changelog as if it were never existed, as long as it is
not released for stable".

-BEGIN PGP SIGNATURE-
Version: 2.6.3ia
Charset: latin1

iQCVAgUBNLEmFyqK7IlOjMLFAQGk1QQAkunssgl4fkpPCLl6uv5uoRFYsmsdK7PZ
48i9g9K71+jiyYkxbjPh/uwak4CBjjbObfZcWryBalQ85omrOvktPcpdssxUdMnu
4V0HoiAmFxSaYczaZZauCzgR8mGDgFtdh4EuUELKyr8xKRCfEDWpAk0DolYEU98k
7WdpgUD8XUQ=
=Qxo2
-END PGP SIGNATURE-


--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] . 
Trouble?  e-mail to [EMAIL PROTECTED] .

Re: What warrants a non-maintainer release number?

[Santiago Vila]

-BEGIN PGP SIGNED MESSAGE-

On Mon, 5 Jan 1998, Christian Schwarz wrote:

> On Mon, 5 Jan 1998, Santiago Vila wrote:
> 
> [snip]
> > BTW: After "the version number has to be incremented too (this is, the
> > source package has to be changed and uploaded again) to make sure
> > dpkg/dselect recognizes the changed package." I would add:
> > 
> > "You may want to use a point version number x.1 or x.5 and make it to
> > disappear from the changelog as if it were never existed, as long as it is
> > not released for stable".
> 
> I think removing entries from the changelog is usually a bad thing, even
> for dot releases. Sometimes, the changelog is very useful to get some
> "background" info about the version one has installed.

We want to release hamm as soon as possible. Therefore everybody should
use the latest release of each package. If you release x, recompile it and
call it x.1, and later release x+1, I don't see why x.1 should be kept
in the changelog, being it just a recompile.

I still think that changelog is *mainly* the history of *source* changes.
If we increment it just for a recompile is because dpkg needs it to see
that a package is "newer".

-BEGIN PGP SIGNATURE-
Version: 2.6.3ia
Charset: latin1

iQCVAgUBNLE7uSqK7IlOjMLFAQEsrQP7Bp1Q+ih4hUNY687sAIxBYv5ye7DBx777
nnKkccy77eyj7Riwt82y7xThp2wP0UK1iHyilaUjgIH5woDNePpPaSjAULAxsINm
eTAfASKNiTRlXIk5nE2YWDQC2xFX7+DA4pvkqFHlv8aiZG56BBzDb5BEAJxMVeo1
aiKesL9rQtE=
=F9jz
-END PGP SIGNATURE-


--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] . 
Trouble?  e-mail to [EMAIL PROTECTED] .

Re: What warrants a non-maintainer release number?

[Santiago Vila]

-BEGIN PGP SIGNED MESSAGE-

On Mon, 5 Jan 1998, Dale Scheetz wrote:

> On Mon, 5 Jan 1998, Santiago Vila wrote:
> 
> > On Mon, 5 Jan 1998, Dale Scheetz wrote:
> > 
> > > It was my understanding that the only time it is necessary to upload a new
> > > source package was when the upstream source changed.
> > 
> > Here, "source" means "Debian source", i.e. orig source + diff.
> > In fact, you upload a new "Debian source" each time you upload a new diff.
> > 
> > We are trying to clarify what happens when you just "recompile" a package.
> 
> Then we are still discussing "non-maintainer uploads/version numbering".
> In that case I find the paragraph to be ambiguous, confusing, and not to
> the point.

Maybe, but the official maintainer should also be able to do a recompile
of his own package :-) Why do you think we are still discussing
"non-maintainer" uploads?

-BEGIN PGP SIGNATURE-
Version: 2.6.3ia
Charset: latin1

iQCVAgUBNLE89yqK7IlOjMLFAQFDUgP/aQX5mNcI06vbVewU9PSY07/yRuKN3sMT
0BFawG1KmHCLYR0pq8aFn8pXSo6+8H+8uNQDhs4hDQwFJJFhotwxRIroTPp04ROd
8oIHz2NzrebL0RdrA0XSZQcnHxB5BA7MtLTIlfpJ2/5XrmIj9/DTXMuVMohe55I1
OJD8ErmfGV4=
=QRsk
-END PGP SIGNATURE-


--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] . 
Trouble?  e-mail to [EMAIL PROTECTED] .

Re: Ian Jackson back

[Santiago Vila]

-BEGIN PGP SIGNED MESSAGE-

On Mon, 5 Jan 1998, Ian Jackson wrote:
> I'm now properly back.  I'll try to catch up on the mailing lists in
> the next few days.

Great! Will you be so kind to:

a) Put bug web pages in normal order.

and

b) divert all those 300K reports from debian-bugs-dist to debian-bugs-reports.


as you said you were going to do?

-BEGIN PGP SIGNATURE-
Version: 2.6.3ia
Charset: latin1

iQCVAgUBNLNgiCqK7IlOjMLFAQHpVQQApu+ZQ1XVJItGgWhUocfiQ95P7LFEQcYQ
+aJzYS33wQNv21ZUNAd1/loFAOgdryMotDPqx3/e86fNLD/gTaDXGHdlVp5jmSfg
BbQdzpUQE8knr5LFMzZMRRt1qyzTcuMc+hm44M/qH5kEF0C7EAaxkPRiE4yMopnA
jdQsf27MV4g=
=VFEk
-END PGP SIGNATURE-


--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] . 
Trouble?  e-mail to [EMAIL PROTECTED] .

Re: Self Referencing depends

[Santiago Vila]

-BEGIN PGP SIGNED MESSAGE-

On Wed, 7 Jan 1998 [EMAIL PROTECTED] wrote:

> For instance, take "unzip". The "unzip" and "unzip-crypt" (on non-US)
> packages both provide the virtual package "unzip", so that other packages
> can have a "Depends: unzip" (the virtual one), without having to know which
> packages actually provide that functionality.

BTW: Now that I think of it... Does the fact that unzip-crypt provides
unzip make unzip to be a virtual package? If so, should I ask unzip and
zip to be added to the authoritative list of virtual packages?

Thanks.

-BEGIN PGP SIGNATURE-
Version: 2.6.3ia
Charset: latin1

iQCVAgUBNLOHGyqK7IlOjMLFAQEHlAP/Xd677zFh8LOYxaNTEyVgNDlqaYJ7s3vX
ZHeFfFJJs4J3ZUvaBhBTrsYc7kUu/sYh+CTWPF0oLVY/LD1YW3uxEWIOKHG4Y9hX
JOf7LwGR1xjQ3H9o33HlbSepnHA2m+9w4UGhsMFBy+d+F5vkZmWuPtRnVN9PcsuK
ES1iJ/JDxWQ=
=IP9y
-END PGP SIGNATURE-


--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] . 
Trouble?  e-mail to [EMAIL PROTECTED] .

Re: Debian 2.0 release requirements

[Santiago Vila]

-BEGIN PGP SIGNED MESSAGE-

On Wed, 7 Jan 1998, Alex Yukhimets wrote:

> it is nice property of "less" (as opposed to "more") that it filters
> out all non-ascii charachters (changes them to some ^... printable
> sequencies). As a result, it is not possible to trash the console by
> doing "less " or, more important - if something
> bad happened and you created a file(s) with some non-ascii charachters,
> "ls" will trash the console while "ls | less" will show you everything
> and let you delete it.

I think there is a misunderstanding here:

"non-ascii" is not the same as "non-printable".

At least in iso-8859-1, characters from 160 to 255 *are* printable, and
should *not* be "escaped" in any way, or else nobody will be able to see

\begin{TeX}
Espa\~na
\end{TeX}

properly (i.e. "España" in iso-8859-1).

These characters are also printable with the default font, but obviously
you will not see the letter (TeX \~n) or accented letters, but IBM-PC
graphics instead.

You may trash the console by printing characters from 128 to 159, but in
general these are *not* printable, so I don't think anything bad will
happen if we are 8-bit clean at least *for characters between 160 and 255*.

Thanks.

p.s. I don't remember ever having trashed the console by using less.

-BEGIN PGP SIGNATURE-
Version: 2.6.3ia
Charset: latin1

iQCVAgUBNLS++CqK7IlOjMLFAQFa7AQAkhicyTKplgnqR9bkF1UhciWQohzP7N4r
RwyZZAtoApAsmTjaEGZIkNKqfPAtd8hjaWjz4iiWt+oFizdVP8XMoE2TLAHjH99K
RNEeVQIBrcw1vACo/7UsLqd0vRqghUwZujx8OKSjmaYiqmo9OLObUolsxAkq877p
lV9iNgJTSfI=
=MPjr
-END PGP SIGNATURE-


--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] .
Trouble?  e-mail to [EMAIL PROTECTED] .

Re: procps

[Santiago Vila]

-BEGIN PGP SIGNED MESSAGE-

On Thu, 8 Jan 1998, Ulf Jaenicke-Roessler wrote:

>  where should 'ps' reside, according to the standard?
>  In the latest version it moved from /bin/ps to /usr/bin/ps.

According to the maintainer, it will be moved back to /bin.
This is bug #16705. Thanks.

-BEGIN PGP SIGNATURE-
Version: 2.6.3ia
Charset: latin1

iQCVAgUBNLTXryqK7IlOjMLFAQEsfwQAg/Q9yeZTsMwgZoB1mtGyA0sVVC/9ez5A
fUtBFy/jMZRIlYznZHCGS12q23zUvAJCa6vkXNYMjKMcbiCI6p9Pm/nXZjxGUNvw
4fLt+n8gXkpsAw9XbaHo4+j9n7od9mpixQOjzR18ht2HNKXkkpMaX7NJT8BEy48B
FVYC1E1PBh8=
=6PS5
-END PGP SIGNATURE-


--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] . 
Trouble?  e-mail to [EMAIL PROTECTED] .

Re: Uncompress /usr/doc/copyright/GPL.gz please

[Santiago Vila]

-BEGIN PGP SIGNED MESSAGE-

On 8 Jan 1998, John Goerzen wrote:
> Can /usr/doc/copyright/GPL.gz be uncompressed in the future?

It will be uncompressed in the future. See Bug #15025.

-BEGIN PGP SIGNATURE-
Version: 2.6.3ia
Charset: latin1

iQCVAgUBNLUoSCqK7IlOjMLFAQErLAQAmKQSIHqXKSujDuSTdvGiYtzRE3D5ieq7
EwxUNEUGXNvduLdqMmO1e2e8xVUQ1cHmUejrFMqk7ePvHbqKmut+2Ei+clkwvhgy
K6OkVyjxjg/huWHVt68ZfSYcJR/i++zLXV8OQ6E1/ghLmRe0OxSahR49ba3JFu7j
WObts7Sm498=
=of10
-END PGP SIGNATURE-


--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] . 
Trouble?  e-mail to [EMAIL PROTECTED] .

Re: Debian 2.0 release requirements

[Santiago Vila]

-BEGIN PGP SIGNED MESSAGE-

On Sat, 10 Jan 1998, Alex Yukhimets wrote:

> Yes, but if I sent you a message containing some russian leters you
> wouldn't see them the way I see anyway. The same thing for every other
> language. 8-bit clean e-mail message is not the one to send to
> international mailing list. But this is off-topic.

Alex, this is much simpler than you think.

I will give you a simple example: My keyboard has a key for the \~n letter
(using TeX notation) which is used in the Spanish language.

When I press that key, I *expect* to produce such character.
Not obtaining that letter but some other is completely annoying for me.
It is as if I pressed "t" and obtained "y". Completely unnaceptable.

Since you don't have such key in your keyboard, you have nothing to worry
about, but even if you would have that key in your keyboard, and you
don't want to produce such character, just don't press that key! Where
is the problem? I don't see any problem at all!

> Great. I am already persuaded that I was wrong about "less".

Ok. Please, tell me another example of a program that should not allow
8-bit input (and output) by default.

-BEGIN PGP SIGNATURE-
Version: 2.6.3ia
Charset: latin1

iQCVAgUBNLfNvCqK7IlOjMLFAQENUgQAs9yOZLYfL0ywHs8RhO8DeZyvOFE4d7dz
ffhFvUF/TLgLi3A8HkV5OmkuadLZrFLCHQgj1/42+rwlDCd6HBBnnaY78z1PWssp
8ppp5OYKkuJ0x+TqZHGdg/tihlYp1n3UrIeor6kuXQ6Fa+lO5uYaviDMg/KEhoYR
LfmaYORFtpk=
=oMaI
-END PGP SIGNATURE-


--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] . 
Trouble?  e-mail to [EMAIL PROTECTED] .

/usr/bin disappeared. Do we really follow FSSTND?

[Santiago Vila]

-BEGIN PGP SIGNED MESSAGE-

A friend of mine has a machine on the net whose /usr/bin directory has
disappeared. The machine has a Debian mirror, so any package is
available to be installed again, however:

`dpkg' was in /usr/bin, so currently there is no package manager.

`ftp' was also in /usr/bin, so if the machine would not have a Debian
mirror, no package could be downloaded (they may be "uploaded", however).

`ar' was in /usr/bin so if you want to uncompress a .deb package by hand,
you can't.

Question: Would not `dpkg', `ar' and `ftp' have to be in /bin
instead of /usr/bin?

[ FSSTND says /usr/bin are just "Binaries that are not needed in
single-user mode", ha, ha... ]

Thanks.

-BEGIN PGP SIGNATURE-
Version: 2.6.3ia
Charset: latin1

iQCUAgUBNLfTKyqK7IlOjMLFAQHdjAP0C+/m2L5EQHJkxr5nST87YkP4tdMcuBnn
m8KnGL5b/pdExbq5MOZYf1soNstZINjkzJib9DqIciSDSfPeDg4YrN4qoF2BnJgo
KS8RAV/xjx/5YH+3o0dvH6WdoVhv8r8qysbCZezq6ldQbjuOHbpbnefZiWhg/ZzM
n52rgb1FPw==
=Fhq+
-END PGP SIGNATURE-


--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] . 
Trouble?  e-mail to [EMAIL PROTECTED] .

Re: base-files 1.6 (source all) uploaded to master

[Santiago Vila]

-BEGIN PGP SIGNED MESSAGE-

On Wed, 8 Apr 1998, Raul Miller wrote:

> Riku Voipio <[EMAIL PROTECTED]> wrote:
> > The point is new users. 
> 
> Then we should be talking about /etc/skel/, rather than /etc/profile

Well, if we talk about /etc/skel, then we could ask:
Is there any other shell which reads .bash_profile?

-BEGIN PGP SIGNATURE-
Version: 2.6.3ia
Charset: latin1

iQCVAgUBNSunAyqK7IlOjMLFAQG0FQP/aTSFQtO6/8d5ucgEXZt9uMiE31DdMF55
+9474zPRsBmQgb4LTNSj480KqYfExh+ckOhwVkRvJnCoT8ikxu6aJw3iyHqkz6c6
uStppxRiEpTpU/XHtNJhn28XzDkuX5VUUsSK4fKf7vzKlP7iC02I8fG6thqVovP1
H6PT+vXwt3w=
=+E8L
-END PGP SIGNATURE-


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Is the `scsh' licence DFSG compliant? Please advise.

[Santiago Vila]

-BEGIN PGP SIGNED MESSAGE-

On 9 Apr 1998, Karl M. Hegbloom wrote:

>  Attached is the COPYING file from `scsh-0.5.1'.

   Use of this program for commercial purposes is also permitted, but
only if, in addition to the acknowledgement required for
non-commercial users, written notification of such use is provided by
the commercial user to the authors prior to the fabrication and
distribution of the resulting software.

> May this program go into "main"?

No. The requeriment of written notification of commercial use is a
restriction not allowed by the DFSG.

> I would like to package `guile-scsh' as well.  It bears the similar
> licence.

Put it in non-free also.

-BEGIN PGP SIGNATURE-
Version: 2.6.3ia
Charset: latin1

iQCVAgUBNSyYCCqK7IlOjMLFAQGOfQP8D/AA8HOcrnIrK4P1STpFyW2OIiUwuJax
MAKqng+gi4iJbWxTGbPk4wDIsmNAhsofHEU4uJgKMraaIYb4oM8zmxzG+PCNe6FM
PfVbD0hGO5yIV6kJFrJF6DB8XOU2YBKplr3XCcdX3Ka/zl9AjRr2/JcoHB9Xs7dt
UMavlKzCtdI=
=Hpx7
-END PGP SIGNATURE-


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Why isn't "/var/run" drwxrwxrwt ?

[Santiago Vila]

-BEGIN PGP SIGNED MESSAGE-

On 8 Apr 1998, Karl M. Hegbloom wrote:

>  Why isn't "/var/run" set like "/tmp"?  Shouldn't user-run programs be
>  able to write a pid file there?

I don't think so. According to the FSSTND:

5.10  /var/run : Run-time variable files

This directory contains system information files describing the system
since it was booted. [...]

I think that the word "system" here speaks for itself.

-BEGIN PGP SIGNATURE-
Version: 2.6.3ia
Charset: latin1

iQCVAgUBNSyY6yqK7IlOjMLFAQF3lgQArPnTPpvkNDLO3QU+Yw0whZUy7M/ViqGA
z5J7b3NLMtEKu8ftWlbxV94QPHGI+J0WnIaou4yQiE3rS4s/GrCa2aPPqzmpVQ5R
6yBTWfEUZUg9kaD6eNwJzL9+FXfHbq0EcLI/lLpCi70yZKk/cKR4Fc4BgdVg+7U+
H8+RzgAfQVk=
=/iQY
-END PGP SIGNATURE-


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Need help to fix some debmake bugs.

[Santiago Vila]

-BEGIN PGP SIGNED MESSAGE-

#12443: debmake: uupdate should support pristine sources

I have never used uupdate, so if anyone volunteers, I will accept patches.

Since most tarballs uncompress now into a single directory, it would
ok if uupdate is changed so that it support *only* pristine sources.
(This could be easier).

#16340: debmake: debstd does not recognize uids >64000

This should be trivial for a find wizard which knows a lot about escapes.
I tried it with no success.

If you have a solution for any of these bugs, please send it to the
[EMAIL PROTECTED] address (where n is 12433 or 16340).

Thanks.

-BEGIN PGP SIGNATURE-
Version: 2.6.3ia
Charset: latin1

iQCVAgUBNSzNFyqK7IlOjMLFAQEPjgQAqzBEtH2yd5D+LamESpS8E9/425GYh+kV
IfaD91kWU/T5VikFzFCm0KZT2iox62xACzRIBzvMECidvCRdgrfkBwkkEPrm9a6t
7a2Lu1tmICje9W0UNjKJMkSA473aSsCwica4yxeXV3GzvL1ZELN/5MMe7oRKRgWY
NqjPmnOkoR4=
=ZQTK
-END PGP SIGNATURE-


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Debian Bug#20445 disagree

[Santiago Vila]

-BEGIN PGP SIGNED MESSAGE-

On Sat, 11 Apr 1998, Marcus Brinkmann wrote:

> Why don't we include selected directories from there on the official
> CD (I think of gettext (ouch, don't beat me), 2.1.x software, ...)?

gettext is in experimental so that it will *not* be included in CDs...

If we start putting experimental things in CDs, then we should create
another distribution "really-experimental", since experimental
seems not to be "safe" enough...

-BEGIN PGP SIGNATURE-
Version: 2.6.3ia
Charset: latin1

iQCVAgUBNTHmlCqK7IlOjMLFAQG9zQP+KqXwYNNllAN1xdrrBG1cbrVCGciFRlkH
nfl/qZ/Vo4NUfQPQ/UA1DYN25aH1KCFqIiErFLjrVG9LCGm3FGCj/DBTxoLxRByX
JVW0IXuLqobmqXYqevskxVV4k1XbFUeCidSE8DCbT0TD2k7gNaB7goOTS1n9IcPv
/lpu1IBK9VY=
=cqxH
-END PGP SIGNATURE-


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Debian Bug#20445 disagree

[Santiago Vila]

-BEGIN PGP SIGNED MESSAGE-

Hi.

Marcus, I was just clarifying (once more) the status of gettext in Debian.

It is in experimental because the author asked me not to distribute it
"widely". This means that even if it is not accesable by dselect, we
should not put it on CDs yet.

If a package being in "experimental" does not implicitly mean "not to be
distributed in CDs", then we would need definitely another different
"experimental" for gettext.

-BEGIN PGP SIGNATURE-
Version: 2.6.3ia
Charset: latin1

iQCVAgUBNTImGSqK7IlOjMLFAQHqEwP/eg32O0AUSqHjdzV/JrwqUUd77W+aTZ1z
Sn39hTSwFIa4H7z3duFSRKDgtUBoVR5fMjeXtlZ3oAAGTXZAfv1jhaSC/DjcTNl4
2QFofLIEs8IVtHm2RapU1bdFjWEW0GTGHpKtw/hKUmHKw2imkJz8au/66TO0yFGD
8FQHkLj4Dm8=
=HInd
-END PGP SIGNATURE-


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Debian Bug#20445 disagree

[Santiago Vila]

-BEGIN PGP SIGNED MESSAGE-

Brian White:
> Project/experimental is not searched by dselect & friends

apt does search in experimental, as far as I know.

> > If a package being in "experimental" does not implicitly mean "not to be
> > distributed in CDs", then we would need definitely another different
> > "experimental" for gettext.
> 
> I'm not sure whether or not "experimental" is appropriate for gettext, then.

I'm sure experimental is appropriate for gettext, as long as we all are
sure that experimental is not appropriate to be put in CDs.

> Perhaps including project/experimental isn't such a good idea
> after all.

I agree.

-BEGIN PGP SIGNATURE-
Version: 2.6.3ia
Charset: latin1

iQCVAgUBNTZBySqK7IlOjMLFAQH5rgQAmjQP5oSm1ap5M4OGTscG7mceTdey4QyJ
yYmkOTZrRw+O6fMfrXsT1jLfIq8+1LTKpN5mt4ODePqRToYQb2p2hr3/lNhVGcQP
Z5fKWZtRb9v9vN0eC8VlKs1RYVUk/B9tEuK9ZbvLaTOReElEvY/PrH+1XRah562Y
77bJyj2XJOQ=
=5PU8
-END PGP SIGNATURE-


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Making the libc5-libc6 upgrade to be safe (was: netstd...)

[Santiago Vila]

-BEGIN PGP SIGNED MESSAGE-

[ This was: Bug#13849: netstd should predepend on libreadlineg2 ]

[ I would like to appeal to the technical comittee here. Unfortunately the
technical comittee does not exist yet and all we have so far is
debian-devel. Therefore we will have to discuss it here again ].

Summary: In a bo system, I managed to upgrade netstd without installing
libreadlineg2 first and the simple ftp client stopped working. This is a
really bad situation I really do not desire to anybody.

This should not have happened if netstd would have a Pre-Depends line on
libreadlineg2 (and libc6 & ncurses also, probably).

* On a system which is remotely administered, if for any reason the usual
installing method fails (dselect and libnet-perl and such), it is very
important to have an alternate method to fix the problem (as usual in
Unix, you may do things in several ways).

* The Murphy's law says that if dselect/libnet-perl is the *only*
method that is always guaranteed to work and because of that we decide
that no Pre-Depends is needed for netstd, then it is 100% sure that a lot
of users (it happened to me!) will find that dselect/libnet-perl fails and
will not find an alternate method to fix the problem. Probably the system
is also 100Km away from where you are.

* The total set of Pre-Depends targets is small (most Pre-Depends
are on libc6, ncurses3.4). bash already Pre-Depends on libreadlineg2.
Adding one more Pre-Depends on libreadlineg2 for netstd would not make
a great harm. Not adding a Pre-Depends on libreadlineg2 *could*
actually make a great harm.

* netstd is not essential, not even required, but for people that really
have netstd installed, netstd is *very* important.

In short I think that the addition of this simple Pre-Depends field
will make the libc5 to lib6 upgrade *much* more robust.

Perhaps people doing the upgrade by using the mini-howto or autoup.sh will
not notice it (no harm with these extra Pre-Depends), but people doing the
upgrade by using dselect will certainly notice it (possible harm, which we
can avoid, and therefore should avoid).


So I repeat the question I formulated one month ago:

Please, tell me how much harm does to add a Pre-Depends field on libc6,
ncurses3.4 and libreadlineg2 for netstd. I can tell you how much
inconvenience does *not* to add it and then we can make a comparison
between those two inconveniences.

Thanks.

-BEGIN PGP SIGNATURE-
Version: 2.6.3ia
Charset: latin1

iQCVAgUBNTZtvyqK7IlOjMLFAQH4owP+If+vI6TuUHt5q4mBG7gJWiHvVobl2zfi
ufW7W6Nrcdo8RdLfOXBt/l1SqhmlxbkiK3yn4pEkR5jU3YTtoEy7SLKAbdVg+f/Y
Mb2RBCwzzXhXV06wavi1HAjzo0OJkZ1KQRIKRTqqcD4grGMBPC9My0nRYoppIsST
3FP2cOx4624=
=lYLS
-END PGP SIGNATURE-


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Debian Bug#20445 disagree

[Santiago Vila]

-BEGIN PGP SIGNED MESSAGE-

On Thu, 16 Apr 1998, Joel Klecker wrote:

> I find it odd that the GNU ftp site and mirrors thereof are not considered
> "wide distribution" by gettext's author.
> 
> 

That is a very very old release (from december 1995) that currently nobody
will want to use. Everybody recommends using the current release, 0.10.32.

-BEGIN PGP SIGNATURE-
Version: 2.6.3ia
Charset: latin1

iQCVAgUBNTdtwyqK7IlOjMLFAQFe+wQAp3RxHGX5V7e/sk4EH/IUaT1zdKpdnLyv
W5ghWxa0Gsn1RRcmLtTdRsl54DpbmkX4MxM8ClXPEdMnziQA1Z9NtcJn7ojBcYz/
vuJnNKn2Vp7hdPVV9wmoqkga8mf+x4gd03XhgR7cw4LLPOz+B/QZuyZCRL4wTOXF
doWWZ4ltwtI=
=ZvGH
-END PGP SIGNATURE-


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Making the libc5-libc6 upgrade to be safe (was: netstd...)

[Santiago Vila]

-BEGIN PGP SIGNED MESSAGE-

On Fri, 17 Apr 1998, Peter Tobias wrote:

> On Apr 16, Santiago Vila wrote:
> > Summary: In a bo system, I managed to upgrade netstd without installing
> > libreadlineg2 first and the simple ftp client stopped working. This is a
> > really bad situation I really do not desire to anybody.
> > 
> > This should not have happened if netstd would have a Pre-Depends line on
> > libreadlineg2 (and libc6 & ncurses also, probably).
> 
> I think you got me wrong on this issue. About one month ago I asked
> on debian-devel what the other debian developers think about it. As a
> result I changed netstd to make sure that the ftp client will work.
> Due to an ext2fs problem I had to restore the netstd sources from tape
> and I forgot to re-apply this patch along with two other patches from
> Topi Miettinen to the netstd sources. This has been fixed with netstd
> 3.05.

Well, sorry, I didn't know you fixed it because you didn't close the bug.
Please, close the bug this time :-)

-BEGIN PGP SIGNATURE-
Version: 2.6.3ia
Charset: latin1

iQCVAgUBNTjBmyqK7IlOjMLFAQGPOAQAtTXjW0k5Y+uxYLtzgT2vF4DQivzPyRbf
szXAPh2B1XBDDmOqHgCtJp5M5zownvVwodOVjCujZXp/NTfsV/BEXAUlrEk7BNOz
5zdCYXHQtot+sm96ktje3BRT55nsSs8WI2AbAqePQ76lt74jlik2WzPPzH5AaSaa
IX7lvxozucM=
=kauN
-END PGP SIGNATURE-


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Maildir patches for procmail.

[Santiago Vila]

-BEGIN PGP SIGNED MESSAGE-

Hello.

A user has asked me to add maildir support for procmail. The patch:

http://www.qcc.sk.ca/~bguenter/distrib/procmail-maildir/procmail-maildir.patch

is extremely clean and simple, and since already existing .procmailrc
files do not use maildir folders (which are denoted by ".../directory/",
i.e. having a slash at the end) we would not break anything and there
would be complete backwards compatibility.

What I would like to ask you is: Would you allow a new procmail package
with these maildir patches to go into frozen (hamm)?

I'm Cc:ing debian-devel also to hear about possible objections.

-BEGIN PGP SIGNATURE-
Version: 2.6.3ia
Charset: latin1

iQCVAgUBNUBjlSqK7IlOjMLFAQEs7wP8CEDc9rBIxkrhDNML6q2kqa3YHyfZgGcG
Wiq7QSV9Kc6XlXQq3XBOOLLGOMIoN8alPpLNpE/1usrlb38DZFbgy3rhAdResLxa
NQeQMLLRFPbMdWIVKYQZ12qaA/ocMgmxauuOr4RUvJj+KXwxED5Nyo+hDg3v/Iaf
ddRjXdvZeZM=
=otdT
-END PGP SIGNATURE-


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Processed:

[Santiago Vila]

-BEGIN PGP SIGNED MESSAGE-

On Fri, 24 Apr 1998, Ian Jackson wrote:

> Processing commands for [EMAIL PROTECTED]:
> 
> [Bugs #10087 #11903 #13017 #15267 #17647 #18416 #9294 reassigned to general].

Clarification: All these bugs are already closed, just that I don't want
to see them in my web page as being "base-files" bugs.

-BEGIN PGP SIGNATURE-
Version: 2.6.3ia
Charset: latin1

iQCVAgUBNUDv/SqK7IlOjMLFAQHa+AP9E7nKclWQvhK75vvPnHo4cux3mbxdUg+a
yZmTESTFFWZ3cRoSdEoMkMhNcpVrPYf0Pw+UIARJuh7wyVm1PAdM2TS9iQNrWsgI
M1ZTAO7ivrwDyIiMdSuBRMtwkHb1dEBpCF/qYqOiu93BPBIbAsaKaJRWDRrKJ1lw
WHny2qu0rC4=
=eBYr
-END PGP SIGNATURE-


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

base-files etc.

[Santiago Vila]

-BEGIN PGP SIGNED MESSAGE-

Ok, trying to be "conservative", I have changed the default prompt for
root from '[EMAIL PROTECTED]:\w\$ ' to '\h:\w\$ ' in base-files_1.9.

I would really like to see something like '\h:\w\$ ' (or '\w\$ ' at
least) in /etc/skel/.bashrc. Would it be against policy?

Thanks.

-BEGIN PGP SIGNATURE-
Version: 2.6.3ia
Charset: latin1

iQCVAgUBNUMsnSqK7IlOjMLFAQHxHgP+NHTmzRnJPSCJ3sfPvNW82lbM6fpiQG3R
fPtbTcQ7BZOxLP2HomQp4/pMh7/+HQx0Eo8qYDShPRFwqIjIZC/0ihZzLfIbp2uF
XspAUHP0GJTjBSEkoTyMY7hXZg9hNJj0lllWfdzRCDHc14bTBJVRFC8v7+999WT0
WRPSQGRrMRI=
=ZcOH
-END PGP SIGNATURE-


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: What to do with /bin/perl symlink?

[Santiago Vila]

-BEGIN PGP SIGNED MESSAGE-

On Sun, 26 Apr 1998, Enrique Zanardi wrote:

> Currently the base system comes with that symlink, but I plan to remove
> it for the next boot-floppies release. Objections?

None. Just a question: Are there more files (still) in the
base system but not in any package?

-BEGIN PGP SIGNATURE-
Version: 2.6.3ia
Charset: latin1

iQCVAgUBNUMtoCqK7IlOjMLFAQFiGwP/Ur5GRtL0WiMf/rx3FnzBb9U2kvLqRfLU
G13aFzx4nWLBHSVQKpRU0ccqHtpPW/xfP2clD14S/dqhuKR8UY/TGRnO5zdq+kTo
LwhWbX0MBXvfq9G4NqWsP0WbgFMorP+2heZ//iXnWag9TQdUgyoAlD14tZB0i/21
iro6LvZMI0A=
=5LS5
-END PGP SIGNATURE-


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: base-files etc.

[Santiago Vila]

-BEGIN PGP SIGNED MESSAGE-

On Sun, 26 Apr 1998, Avery Pennarun wrote:
> On Sun, Apr 26, 1998 at 02:46:58PM +0200, Santiago Vila wrote:
> > Ok, trying to be "conservative", I have changed the default prompt for
> > root from '[EMAIL PROTECTED]:\w\$ ' to '\h:\w\$ ' in base-files_1.9.
> > 
> > I would really like to see something like '\h:\w\$ ' (or '\w\$ ' at
> > least) in /etc/skel/.bashrc. Would it be against policy?
> 
> Why not /etc/profile?  Or is that against policy?

/etc/profile is read by many different shells, almost any of which
understand bash escapes, while .bash_profile is only read by bash.

-BEGIN PGP SIGNATURE-
Version: 2.6.3ia
Charset: latin1

iQCVAgUBNUM3xCqK7IlOjMLFAQHMngP+I93if5NckBcvWOxRWs77VXd+ZHLRgO9R
4UCCcuxTO+IXaQ0LmZ+osquE0Wr9jq1TtmkoXTCHtABFXfq7SsQmgWcJoqU8vpZZ
4FWGSZ75Cd9QnBz8yExtxO23tPJXrEsMoHdYX3VFir3jewNK6CJAcxyuQqzPYOlz
lnWWtP88DSo=
=PkTA
-END PGP SIGNATURE-


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: base-files 1.9 (source all) uploaded to master

[Santiago Vila]

-BEGIN PGP SIGNED MESSAGE-

On Sun, 26 Apr 1998, Richard Braakman wrote:

> > Changes:
> >  base-files (1.9) frozen unstable; urgency=low
> 
> >* nsswitch.conf: Use "compat" instead of "db files" for passwd, group
> >  and shadow (Bug #10896).
> 
> I think this is a bad time to make changes to the default nsswitch.conf
> in hamm.  Historically the configuration of nsswitch has been quite tricky;
> its current contents are the result of much experimentation and bughunting.
> 
> I reviewed bug #10896, and it does not list any specific bad effects
> of having nsswitch the way it is now.

You have to change it for nis to work. Debian policy is to have good
default values. A good default value is one that has not to be changed.
Therefore, "compat" is better that "db files".

> I strongly recommend against this change, unless it can be shown to fix
> something that is broken.

compat is the default value used by glibc when you have no nsswitch.conf
file. If using "compat" is wrong, glibc would be wrong also.

-BEGIN PGP SIGNATURE-
Version: 2.6.3ia
Charset: latin1

iQCVAgUBNURw8yqK7IlOjMLFAQFgAAP/YBy1Gz7UHv/jRN7hudnuLX62CvRu2/iK
Pj3cfHtYgVm7Am6DBYPza9iRHdkNsEO1D8S+4VvFOjEXSJY0Jnl3XBQvTVhbdb3S
cs2MgAvXToTgPBULNneNGMOkmjZgG58lDAi7o8IP7Uz+ec9/tVM2x+6XoSPhe1BT
EWTamB4h3cw=
=QkL2
-END PGP SIGNATURE-


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: base-files etc.

[Santiago Vila]

-BEGIN PGP SIGNED MESSAGE-

On 27 Apr 1998, Kai Henningsen wrote:

> Santiago Vila wrote on 26.04.98:
> 
> > I would really like to see something like '\h:\w\$ ' (or '\w\$ ' at
> > least) in /etc/skel/.bashrc. Would it be against policy?
> 
> Policy 3.3.7 "'/etc/skel' should be as empty as we can make it."

Ok, "Only if the program doesn't support a site-wide default configuration
and the package maintainer doesn't have time to add it should a default
per-user file be placed in /etc/skel."

In this case, /etc/profile *may* be used (by checking whether $SHELL is
/bin/bash). Moreover, policy says:

   Ideally the sysadmin should not have to do any configuration other
   than that done (semi-)automatically by the postinst script.

Well, I'm sure than 99% of people dislike current default bash prompt in
/etc/profile. At least we could put the current dir, and maybe that 99%
would decrease a lot.

-BEGIN PGP SIGNATURE-
Version: 2.6.3ia
Charset: latin1

iQCVAgUBNUSaBiqK7IlOjMLFAQH+9QQAnWoSQMRCk0xaD9mr836Odj7FO+f8V4o2
0er8moXKSKPUSWr+W7D/442woj8U/bnqdBI0QG4Wa77tsR2mQvmCGb7qe84mPHNl
MBImtKu5l8BTZdS5U1QVG3yGxepg4MgOjx4xX7fR/Hrh0TEohTDaxJKkBOVx1475
qnMa33ZxRaE=
=l9/d
-END PGP SIGNATURE-


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Constitution - formal proposal (v0.7)

[Santiago Vila]

-BEGIN PGP SIGNED MESSAGE-

 5. No detailed design work.
Then Technical Committee does not engage in design of new

Should be "The", I think.

-BEGIN PGP SIGNATURE-
Version: 2.6.3ia
Charset: latin1

iQCVAgUBNUcduSqK7IlOjMLFAQGkhAP+LvASURChex4byQh9nbEvV44sZUkfL8Pr
cb46lY3Qs/3fb2sPJfiJgjjWLuFwYaRLSuRnyYwt5YKI3EA44TAEpy0TZktf9Dha
ZPJ3Y1ZZ2j58zn+HmabnqhfgxcsWN5XdPzO1y5hVoVRWOo/zRRXhWadSQUKrRS5a
7zM0GQnYoG4=
=Ev27
-END PGP SIGNATURE-


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: weird effect

[Santiago Vila]

-BEGIN PGP SIGNED MESSAGE-

On Thu, 30 Apr 1998, Hamish Moffatt wrote:

> Tonight I upgraded to current hamm; I was asked if I wanted to replace my
> issue and issue.net files; I replied N to both. issue was preserved,
> but issue.net is gone!
> 
> The preinst for base-files removes /etc/issue.net if it is a link (why?)

Because it is a conffile since base-files_1.3.5 (at least), and having a
conffile being a symlink is tricky. Default issue.net was a symlink
to issue in the first base-files (or maybe base?) releases.

> but it wasn't.

Mmm, really strange. Which was your previous base-files version?
Did you upgrade from rex or from bo?

I would like to reproduce the same error.

It is true that when issue.net is a symlink to issue, then it is simply
removed, because once it is removed, dpkg see it as an inexistant conffile
and do not ask. This dpkg behaviour is not the desired one in most cases
and I think it is already reported as a bug. Perhaps I should treat
issue.net in the same way I already treat /root/.bashrc?

-BEGIN PGP SIGNATURE-
Version: 2.6.3ia
Charset: latin1

iQCVAgUBNUc9hyqK7IlOjMLFAQEGVQQAjWHMO5yYssPiDGPbhAYsdYGl6t2rrAQP
W/2VZsPgnNgfERWTnGEnhXktHJ7c95EwVddD0zBBagxZqaMpsxEnFoDL7w3asMBl
kwwIlUatvhHg3EDGAz3SEFTNSlVs9G6OzaiYVWTKEbMaei9mhnQ9kuf4L1XqyBn9
5OXhHFC1n0c=
=7kij
-END PGP SIGNATURE-


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

intent to take mawk and gawk

[Santiago Vila]

-BEGIN PGP SIGNED MESSAGE-

If nobody objects, I intent to take mawk and gawk.

[ There have been no maintainer uploads since March 1997, is one year
  enough? ].

-BEGIN PGP SIGNATURE-
Version: 2.6.3ia
Charset: latin1

iQCVAgUBNUdt9yqK7IlOjMLFAQH0XgP/VDlUE4ye939QxpFJ401coph8+iw4fc5E
DHxXtzyCtdNCntOaEdqJ3NDlga3NJdU3Ip1P+eh/87De1UXBIFdIpsjjN9QDW8ov
anhLZtJZ/a1LfbOjLMhzz/TeZ7WsEO97NHVE5krBT/Qxag7Pw3QIrEMxUoxIAcT6
nUvlmLfuRJg=
=1DMX
-END PGP SIGNATURE-


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: intent to take mawk and gawk

[Santiago Vila]

-BEGIN PGP SIGNED MESSAGE-

On 29 Apr 1998, James Troup wrote:

> Santiago Vila <[EMAIL PROTECTED]> writes:
> 
> > If nobody objects, I intent to take mawk and gawk.
> 
> I object.  
> I've talked with Christopher and I'm taking the packages on
> a temporary basis (but as the real maintainer).

I object to taking a package in secret without announcing it here first,
as I did.

Do we have the rules for taking an orphaned package?

-BEGIN PGP SIGNATURE-
Version: 2.6.3ia
Charset: latin1

iQCVAgUBNUd9NiqK7IlOjMLFAQFPhwP+ObhuotrRmt4Dl//XwagsltPEHLNQNK4/
nfmnz2acvg9FbIj6XZyKgiNb7tDiVZYvNHbfaoeGeYREKwN454STLwfGGftQthiT
6QIcLGs7P/JpAuYkkP07kuBM/tk/tny3Ragq5mjrbjVQ+PhZluPUl8Khwr2G9zL1
NJ6qB8EXwE0=
=+WRv
-END PGP SIGNATURE-


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Intent to package: uedit

[Santiago Vila]

-BEGIN PGP SIGNED MESSAGE-

I thought you had "zero intention to maintain a non-free package".
Have you changed your mind?

> To get maximum speed uedit will disable the
> wasteful multi-tasking behaviour of Linux and make it do the Right
> thing, DOS-style single-tasking.  Obviously neither X nor networking
> survive, yay!  Network users should stop wasting bandwidth and use a
> local machine.

I hope you will give it a priority of "extra", then.

-BEGIN PGP SIGNATURE-
Version: 2.6.3ia
Charset: latin1

iQCVAgUBNUeAKiqK7IlOjMLFAQHYFAP/RYE+FbjZI7wqtFV6zvz8waGvCjlwMtNO
LLIbR/y4J7EQBlbOjZ99elPCCy72KxmK2/YsTcJhQAJXe5Ag21AebKT+bcdWa3/P
YSmzWKusUPe1lYuVBFF/6N3AcWYkkAZ22ROC8YmrlWfgkpQFq74N51+WQC91cnoK
rtW51ebw9DQ=
=sy3h
-END PGP SIGNATURE-


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: intent to take mawk and gawk

[Santiago Vila]

-BEGIN PGP SIGNED MESSAGE-

On 29 Apr 1998, James Troup wrote:

> Uh, first and foremost, mawk and gawk are *not* orphaned.

What do you mean by orphaned, then? Perhaps we should agree on a common
definition of "orphaned".

> And what's being done in secret?  I'm announced my intent in my previous
> message to debian-devel (which you quote here).  Talking of doing things
> in ``secret'', did you communicate with the current maintainer of mawk
> and gawk before announcing your intent to hijack them?

I did not say I was to hijack them. (BTW: My dictionary does not have the
"hijack" word. I have to buy better one).

Yes, I communicated with him, but he did not answered until just a minutes
ago.

-BEGIN PGP SIGNATURE-
Version: 2.6.3ia
Charset: latin1

iQCVAgUBNUeEwyqK7IlOjMLFAQFW9AP/V436id1PuXrhgWRsOOHl02zoqefaGpgW
sV7Z7XNpCqcSsdS1BpSOK0BfLVhPiD4B3a1tpuBN8mI1++HiCdR1lKChQ2Py1eGc
+mvviw5V6D0WP4bGlS5Zfx8sCST/egPKZpPxXnKX4FLWDGDd/KddcvZa2ffmPIXf
9lfFlgDqMPM=
=nDao
-END PGP SIGNATURE-


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: intent to take mawk and gawk

[Santiago Vila]

-BEGIN PGP SIGNED MESSAGE-

Hi.

Just to make things clearer: If Chris asked you to maintain mawk and gawk
for him, I have no objections.

I was just a little bit annoyed because I already asked Chris the
maintenance of gawk several months ago (at that time I agreed with him
to do a non-maintainer release).

So in my first post about this issue I was expecting an objection
from him, if from anybody.

-BEGIN PGP SIGNATURE-
Version: 2.6.3ia
Charset: latin1

iQCVAgUBNUg4nSqK7IlOjMLFAQEf2wQAq3P0mU0BmEFEdfy7kW4uf0nctsBQjixk
VRP9B1rWTl2xWlgnhAau7ZmKZZXGuekxbPqvT5Rh9eLkI7t/i/u7xy/q4iL8Qf9B
02fhIalmiSPdHIyBye8eIVFoXWXpC+/gKopgXu6TpGQb7oTdAkrNMJYRMEvhGyAd
XQBL1MViizQ=
=r7zU
-END PGP SIGNATURE-


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Intent to package pine-src

[Santiago Vila]

-BEGIN PGP SIGNED MESSAGE-

I have just read Bug #14355, in which Ian Jackson said about qmail-src:

  This package has no reason to exist and should be withdrawn.  We
  distribute source as .dsc/.diff.gz/.orig.tar.gz.

Well, this package exists for two reasons:

1) Because license does not allow to distribute a binary.
2) Because there is not an easy method for downloading a source package
by using dselect or existing tools.

To solve 1), we would have to change the license, but we can't because we
obviously do not own the copyright...

To solve 2), we can either:

a) Modify dselect/dpkg so that it allows retrieving and unpacking source
packages as well as binary packages.

b) Allow .deb "source" packages like qmail-src, as an exception for the
rule "we distribute source as .dsc/.diff.gz/.orig.tar.gz" for non-free
packages.

Since a) is clearly not going to be done for hamm, I don't see really a
reason why -src packages should be "forbidden".

Ian, why do you still think that qmail-src should not exist?
Are you the only one?

[ I intent to package pine-src ].

-BEGIN PGP SIGNATURE-
Version: 2.6.3ia
Charset: latin1

iQCVAgUBNUiWTyqK7IlOjMLFAQG6SwP6AjzuHQ6swwuztxD6FSE0AgdogfKNBUid
rnggu/JkP4YR9jOgb98dVHDlavVlx0wJT6KOvu6LfCSKXFClrK4+dvW19KkPv+3I
O8OoU1pBf+rtuzgDtIUP/NT0/TfDBtOk/Q2zFZNOyV4cdCt0n8HzLwHXFKsLxJ1Q
gT6EAybjvO8=
=Vo/j
-END PGP SIGNATURE-


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Intent to package pine-src

[Santiago Vila]

-BEGIN PGP SIGNED MESSAGE-

On Thu, 30 Apr 1998, Dale Scheetz wrote:

> I agree with Ian. The .deb file format is expressly for the distribution
> of configured executables (binaries for short). Using this format for
> source distribution is simply asking for trouble.

I don't see any trouble.

> Maybe we need a tarball that contains .dsc, .changes, .diff, and
> .orig.tar.gz all rolled up in one .src file, known to all the necessary
> programs, but to me this isn't necessary.

Well, for many people in debian-user, pine-src is a "must".
 
> For almost two years now we have distributed source packages as a
> collection of checksum authenticated files with a pgp signed changes file
> containing them. These four files: .dsc, .changes, .diff, and .orig.tar.gz
> comprise the Debian Source Format, as described in the significant
> documentation.

Yes, but remember that two years ago we had not read the license of pine
carefully, and qmail had not been released.
 
> We do it this way for both DFSG Free as well as for contrib and non-free
> software, so why make an exeption in this case?

Because we want to make easier the retrieving of *certain* source files.
As easy as it is currently to retrieve binary .deb files.

> Retrieval of source from archives is usually done "by hand" but any such
> bulk retrieval should be easy to manage with a script. I take the lack of
> a script to indicate the current relative lack of need. Anyone is welcome
> to prove me wrong by writing such a script ;-)

My point is that the functionality is already built-in in dpkg itself and
we would not have to reinvent the wheel just for this particular case.

> Although few agree with me, I still feel that packaging kernel source in
> .deb format was/is a mistake. The kernel-package-builder package doesn't
> benefit from this packaging style, as far as I can tell and it makes the
> kernel more perculiar than it need be.
> 
> Another benefit of this source format that the .deb does not provide is
> the one time only download of orig.tar.gz. Until the upstream version
> changes, one can keep up with the Debian package by only needing to
> download the .diff and .dsc files (typically many orders smaller) to
> create a source tree that will build the current version of the Debian
> package.

Ok, then I will make two packages. One for the .orig.tar.gz file and
another one for the .diff.gz and the .dsc files. This way only the second
one will have to be downloaded for each new release.

> Keep source in Source Format and use the .deb files for what they were
> intended, the distribution of "binary" components.

I *will* keep the source in source format.

I will just create another .deb binary containing the source.

The .deb files were intended to be the binary package format of a free
Unix-clone distribution, Debian. If binaries are not allowed, the .deb
binary format is certainly not suitable for its distribution and we
can perfectly live with an exception.


Moreover, non-free is not officially part of Debian. Why do we have to be
so strict here for the rule of "keeping the source just in the source
package" when there are already packages containing precompiled binaries
in the *source* package (debian/rulkes being just a bunch of cp's)?

Should we remove these from the archive for violating the rule that the
"source is the preferred form to do modifications"?
Please, think of it.

-BEGIN PGP SIGNATURE-
Version: 2.6.3ia
Charset: latin1

iQCVAgUBNUjBJyqK7IlOjMLFAQF1EwQArwzacKqKEtVMqV8DC41KD8vZLJ9XL0y0
/4H85Fa8gAEPuPww/gPAiwSF2tWfSt8CQLajSOkpf9e7e9sPpdJQUBpZC+Yy5k6w
/qL2t60NQBN63pFvfh1myyJL9gPjiPnrwwvdpccHIiCtzlZgpVQf1A6O8MCazCSK
lH2VM6o6SpU=
=KRY2
-END PGP SIGNATURE-


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Intent to package pine-src

[Santiago Vila]

-BEGIN PGP SIGNED MESSAGE-

On Thu, 30 Apr 1998, Stephen Carpenter wrote:

> hmm would it satisfy things to make a binary dist of the original files and of
> the debainized files...and litterally have it unpack the "real" pine and then 
> run
> patch on it with a diff made agains t the debianized binaries?
> (I dunno that patch will do binaries...but you get the idea
> anyway...)

I don't get the idea...

No. This package will be a simple one, like qmail-src.
No need to complicate things even more.

-BEGIN PGP SIGNATURE-
Version: 2.6.3ia
Charset: latin1

iQCVAgUBNUjCVSqK7IlOjMLFAQG1xAP/RHROm8iheKY8N2T1RoE0s7/wPBonFP8o
sux9e6R7KG6pQzxEwYqf4kyyyxvQDNlN2Qwm2o/pIqs3xIqNg08oLCvyf6x1rp+L
ClnYggQezw0PY9Hbh84P8OojlUtPyP0C4AYKEuOfJU23+WpEeWb9kGNIL7t38rxf
JsfW4B+qQ4k=
=ufO5
-END PGP SIGNATURE-


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Debian Source distributions (was Re: Intent to package pine-src)

[Santiago Vila]

-BEGIN PGP SIGNED MESSAGE-

On Thu, 30 Apr 1998, Jules Bean wrote:

> [ ... ]
> Any thoughts?

Very nice... but *not for hamm*, as I said in my first mail.
I was just talking about *hamm*, the distribution that
will not change anymore once it will be released soon.

-BEGIN PGP SIGNATURE-
Version: 2.6.3ia
Charset: latin1

iQCVAgUBNUjDKCqK7IlOjMLFAQEvBQQArRJQKjitoVBg681NcaxqwTptTRvo6MLt
CKxzHevv1XH4fawebKbLm7y7b5KVEW+NiJ93qoDv5Vafj93nE9aynVK97fixoLyS
JTboBexAbf/vZ2uhaVyhSikIqO/bwM8lCfvwq/g/+pjRrvhAEwJZYz4itIhw369k
obIW9280PT0=
=UpoZ
-END PGP SIGNATURE-


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: binary-CD exceeds 650 MB -- any solution?

[Santiago Vila]

-BEGIN PGP SIGNED MESSAGE-

On Mon, 20 Apr 1998, Heiko Schlittermann wrote:

> What are the plans for the official CD?

The official CD will not have non-free on it.
¿Should we care about non-official CDs?

-BEGIN PGP SIGNATURE-
Version: 2.6.3ia
Charset: latin1

iQCVAgUBNTu0yiqK7IlOjMLFAQGz0AP/ZINhRBafbgeZGvDWKKB3qFB/2zwCv/YS
FjRb3MDVaAjkrBByPZWRAFnisVWhtqPq/yAJX2+iNPnOExJW+f0Q8mShHa/fKqfZ
HYbwaMQLYQJLL8goDdk9gMryMWzecZi5zLcXrIWhHS6HF8GqReu/P4jQybZgZgB9
hp+mgZayJkw=
=s5tA
-END PGP SIGNATURE-


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Intent to package pine-src

[Santiago Vila]

-BEGIN PGP SIGNED MESSAGE-

On Thu, 30 Apr 1998, Rev. Joseph Carter wrote:

> The postinst for the .deb will compile the source, install the .deb, and
> clean up after itself if you so desire for a -src package...

Well, I don't plan to do that. I think it would be too much for a -src
package.

I will simply add a README saying how to unpack the source and build it.
The main point is to make it available from dselect. All other concerns
are secondary.

-BEGIN PGP SIGNATURE-
Version: 2.6.3ia
Charset: latin1

iQCVAgUBNUmksyqK7IlOjMLFAQGlxQP/fFPOvzTL5j8AdFh96pzLHJTiclTz81k3
8Ccly23c70WcDNGCwtGvrOiAx7GAx93m4xkUXSdlUI7iYhWXYF1KAHzzDbUq3JjM
CYvIR9mTX9WAVNTYZro+nAdHFIn/3G8In9SusWtbjOWHA9NfVCTAswHYvI1h127p
LK9jtXevoGo=
=1y1/
-END PGP SIGNATURE-


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Intent to package pine-src

[Santiago Vila]

-BEGIN PGP SIGNED MESSAGE-

On Thu, 30 Apr 1998, Dale Scheetz wrote:

> As to source dependency problems, it is my understanding that all the
> packages in the main distribution can be built using only packages from
> main. Given that that doesn't tell you which packages those are, and that
> a "standard" installation is supposed to give you "all the normal stuff"
> it should be sufficient to name non-standard dependencies in the source
> README file. There is no current declared method for this, and that makes
> implimentation difficult, specially when most developers have what they
> need for their packages and don't typically think about the problem any
> further than that.

There will not be source dependencies in pine-src. This will allow people
to install the source in one computer, export it via NFS, and build it
in another computer, for example.

I will simply tell the user in the README which packages are needed to
be installed to build the pine binary packages.

-BEGIN PGP SIGNATURE-
Version: 2.6.3ia
Charset: latin1

iQCVAgUBNUmlqiqK7IlOjMLFAQHv5AQAkmRoccG5OimOF3380aC9ZgtzoufXgHuB
PIWk0/M/oMkXXgPdJuCzbssa0yLsiV6v1E5PKV34YTlfStGlcQUjTP0BB7Gftx3t
biC9wyEh7o3VFq+KmFNBa2HkiersZiO4gZAX2B+BH/pKSftUtYHL5Sl4R1LqJXKw
dKwxouPjZmE=
=Q7eF
-END PGP SIGNATURE-


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Intent to package pine-src

[Santiago Vila]

-BEGIN PGP SIGNED MESSAGE-

On 1 May 1998, James Troup wrote:

> Please think very hard about the benefits of our current system before
> advocating a replacement for it.

The pine-src package will not replace the already existing pine source
in the "source" directory.

Moreover, there will be two packages, one for the .orig.tar.gz and
another one for the diff.gz and the .dsc. No pine user will have to
download twice the .orig source in .deb format with this scheme.

-BEGIN PGP SIGNATURE-
Version: 2.6.3ia
Charset: latin1

iQCVAgUBNUmm0yqK7IlOjMLFAQEOTQP/ViXyoFBmTsun0ZNj4/RePjEJiL2Ns3vL
IbZjFSSkkEWFS3IojNYsJg1DZJ8t3KgWZG7e4hkBIxsEdWa+oWuz6xe1nIc0+KjI
pSaXRp6/qvNegv4v/3zqpSKIYloMhw/HMhE4lLzNVMim5M990JaptugNz7/WHhqQ
OVEpz420E70=
=ZxDE
-END PGP SIGNATURE-


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

source packages and censorship

[Santiago Vila]

-BEGIN PGP SIGNED MESSAGE-

We must ask ourselves: Why do we make .deb packages?
Simple answer: Because our users find them useful.

Remember the discussion about the purity package? Well, it was agreed
(I think) that as long as the package had a license allowing to
distribute it, we can make a .deb package of it.

For example: Why do we package have a .deb emacs package? Because people
find useful to dpkg -i emacs.deb to find emacs in /usr/bin.

Why is there a kernel-package? Because people find it useful.

Why should I package pine-src? Because many people expressed in
debian-user they would find useful to do dpkg -i pine-src.deb and
have the pine source in some directory.

Agreed, this is not very "orthodox", but we can live with it, because pine
will be also distributed in the traditional way in the source directory.

Are we censoring this package for its contents, like we almost did with
the "purity" package or am I missing anything?

-BEGIN PGP SIGNATURE-
Version: 2.6.3ia
Charset: latin1

iQCVAgUBNUmuTSqK7IlOjMLFAQHZPQQAga47OmsyW1U3a6+x2fakD8vUb9lFONgj
p/SSwJICbG+L1DNQVoYpqeZu/tC9FmkpILI6pE97/fFvsj4M2SQ4Bvb4jrooRqZt
ZuuMnN9riW4jf87XIRcKCyqh0Lr62/3xEvIo16jGMXVxuGpFifC3SCH+3GZ64eDM
t7V5d2MUbDA=
=EqtU
-END PGP SIGNATURE-


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: source packages and censorship

[Santiago Vila]

-BEGIN PGP SIGNED MESSAGE-

On Fri, 1 May 1998, Daniel Martin at cush wrote:

> Let me lay out my opinion of the differences of the effects of the two
> methods:

Let me tell you that there is a workaround for all your objections :-)
 
> Method pine-src:
> ---
> - the user who hasn't discovered debian-user or ftp.debian.org, but
> just has an official CD (and barring some unexpected marketing,
> official Debian CDs will be much more numerous than CDs mixing in
> non-free stuff) will conclude that pine isn't available for Debian.

I don't think this will happen. People already know that pine is not free,
and that "non-free" does not come in official CDs. People already know 
since Debian 1.3.1 that that need FTP to get pine.

> - the user on a high-enough speed connection to be using dselect's ftp
> method will see "pine-src" in the menu and conclude that that's what
> they need to install pine.

pine396-src will Recommends: pine396-diffs.

> - the pine-src package will be a huge thing to download each time a
> new pine .diff.gz is released.  (the "three .debs" way seems
> incredibly convoluted, especially when a pine-installer can do the
> whole thing in a much cleaner fashion).

Only the pine396-diffs package will have to be downloaded for each time 
a new pine is released.

> - various people will get very upset about having the pine source
> twice on debian mirrors - a bit superfluous, no?

Since we already distribute the original pine source in the source
directory, I plan to keep the original tarball out of the
pine396-src source package and use md5sum to check that the original
tarball is really present.

pine396-src.deb will be quite big, but since we save some space by not
having the real binary .deb packages, I don't think we waste too much
space.


Summary: Go ahead, create an installer. Today I will upload
the first release of pine396-src and pine396-diffs. You can base
your installers on these packages if you like, but I don't want to
maintain an installer package.

Thanks.

-BEGIN PGP SIGNATURE-
Version: 2.6.3ia
Charset: latin1

iQCVAgUBNUoIeiqK7IlOjMLFAQGY4AQAq8PyRZXD2RxbUAO4pb069vSq5I5UW/x+
P5rkZmU1sest79MG+9wg7xHPo7+atTdEpBD2RV1QB+eATMnkRBor+EyJ6dVLxa6u
jkZtFaiavvXNvoj8UUw9MHPwMxJGKXDc7RvvvR8PiVM7r9R0wC/VwJF36XU2Odv0
Q14CeQSvoSU=
=Wfo2
-END PGP SIGNATURE-


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Copyright of fontinst.

[Santiago Vila]

-BEGIN PGP SIGNED MESSAGE-

On Mon, 4 May 1998, Federico Di Gregorio wrote:

> Hi,
>   some time ago I expressed the intent to package fontinst
> (a TeX/LaTeX package). I asked the author about the licence
> and here's what I got. It is not DFSG but we *do* have latex
> in tetex. So is it right for main? Thanx, federico.
> 
> - Forwarded message -
> 
> The fontinst package is distributed under the same
> restrictions as LaTeX, ie it should be distributed unchanged.

Not all of LaTeX in teTeX have this restrictive license.
That's why part of it have been moved to tetex-nonfree in non-free.

I think most of LaTeX is covered by the special DFSG condition
"The license may require derived works to carry a different name or
version number from the original software.".

If this applies to fontinst, then it would be ok for main. If it just
forbids derived works, not even under a different name, it surely would
not.

-BEGIN PGP SIGNATURE-
Version: 2.6.3ia
Charset: latin1

iQCVAgUBNU3fRiqK7IlOjMLFAQHJuAQAkVlzPlDeUJnEd9EU6L6YI0a+ALz0ZD9h
niepHR9xjbqOQjdmT0ILvHmOFxmqz2PEw0BRIcQlSbOKPu4ld0fJGObwhh23yRlZ
SIGJ3VsDZ7Ngvlfmrcfb9uDAVuNe2AZHSdZjlbltD3XtqOOBqoAu33AkHej0qpNE
eNvUc+gbwH4=
=7Qbr
-END PGP SIGNATURE-


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: /tmp permissions !

[Santiago Vila]

-BEGIN PGP SIGNED MESSAGE-

On Thu, 7 May 1998, Nuno Emanuel F. Carvalho wrote:

>$ chmod 777 tmp

Please do

chmod 1777 /tmp

instead.

If you are worried about security, the sticky bit is supposed to be
explained in every good general FAQ about Unix.

Thanks.

-BEGIN PGP SIGNATURE-
Version: 2.6.3ia
Charset: latin1

iQCVAgUBNVGd0CqK7IlOjMLFAQHDlwP+O1P92RlFH56/uhy2xKdU9Dk8VCp0oi2H
TUTgAeni3BC8F8jajF3n6+7raJ/yk/wfuHXCwLDhGKXvfd6KWl72uBOf8fsy1Cqg
oA7+XijpPqD9rzIRLMCOct4JTrvb3tA4eXoqkpbftHX/1uflJckSkN3yRL92G6oq
fBHoJTpj7qQ=
=+mqV
-END PGP SIGNATURE-


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#22206: Some package uses psmisc without a dependency

[Santiago Vila]

Package: general
Version: 1998-05-07

Today I have just tried the new APT on a libc5 machine to upgrade to hamm.
[ Looks promising! ].

Well, from the hundreds of messages I was able to see a "killall: command
not found" or something alike. I am quite surprised to see that psmisc is
just optional (is this priority ok?).

Anyway, since psmisc is not essential (and this is what really matters),
it would be interesting to know which package uses killall (if any) and
where, to add the appropriate Dependency.

Thanks.


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#22206: Some package uses psmisc without a dependency

[Santiago Vila]

-BEGIN PGP SIGNED MESSAGE-

On 7 May 1998, James Troup wrote:

> Santiago Vila <[EMAIL PROTECTED]> writes:
> 
> > Anyway, since psmisc is not essential (and this is what really
> > matters), it would be interesting to know which package uses killall
> > (if any) and where, to add the appropriate Dependency.
> 
> Maintainer scripts (and most everything else) should not use killall,
> killall is Evil[1].  Packages using killall should be fixed not to use
> it rather than depend on psmisc.
> 
> [1]  
> http://www.nl.debian.org/Lists-Archives/debian-devel-9801/msg01205.html>

Ok, nothing to object. I killall is really evil, perhaps it should be
documented in the policy. It is?

Thanks.

-BEGIN PGP SIGNATURE-
Version: 2.6.3ia
Charset: latin1

iQCVAgUBNVLLByqK7IlOjMLFAQEw+AP/XfOWTW0oAD/lx0nr17kG7/MHvdtPOPPT
DZlfOpkFqFtGorYHQMq1nLPV2H0l/9EWuUPICSKvrXe4j21U1g2gc/3L54PRyHrs
pjuGbmXsDgciohFA1ssSZphisriiwMHq9+AVDX9WxWWMzp3CHa4xt9bj748mAyTl
9GVHOMlPbrY=
=0AcA
-END PGP SIGNATURE-


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Intent to package doc-debian-es

[Santiago Vila]

-BEGIN PGP SIGNED MESSAGE-

The doc-debian-es package is already in alpha stage, and contains the
Debian FAQ. Please see:

http://master.debian.org/~sanvila

If you are interested in translation issues, please subscribe to
the debian-l10n-spanish mailing list.

BTW: I need people to read the *english* FAQ (doc-debian package) and
report *any* inaccuracies.

-BEGIN PGP SIGNATURE-
Version: 2.6.3ia
Charset: latin1

iQCVAgUBNVMfPSqK7IlOjMLFAQFlPAP7BfIeONMdCgpgVJFBbXj8JfJmD5Bs/l98
9ZaPBS5jYoLeGg9PYYHcxpCqdaeJhWGIQd5c3nAZTq1aOECRn/P3t0AX/DPFY1E1
sLjRNVKEEPYvAmHLv6xId+H/FE2JwIu7rM1aQkrnDEM2r+htcsIcQxmghqw6rtQA
9N9BUi0YAqY=
=sAdi
-END PGP SIGNATURE-


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Build-Depends: libmysqlclient-dev and buildds

[Santiago Vila]

The recent announce from Steve has reminded me of something I wanted
to ask about the package name change from libmysqlclient-dev to
libmysqlclient12-dev made in November:

Do packages still having "Build-Depends: libmysqlclient-dev" build
from source? Trying "apt-get build-dep" on them results on apt-get
being undecided about which libmysqlclient-dev to install.

Do buildds handle this gracefully?


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: shell script sniplets in /usr/bin?

[Santiago Vila]

On Sat, 29 Jan 2005, Jochen Voss wrote:

> [...]
> My question: does anybody have further references for the question
> whether it is ok or maybe even preferable to install non-programs in
> /usr/bin?

You forgot to quote last thing I said when closing the bug.

So I'll repeat: Please read the logs for non-bug Bug#292759, where the
author explains the rationale for putting gettext.sh in /usr/bin.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: shell script sniplets in /usr/bin?

[Santiago Vila]

On Sat, 29 Jan 2005, Jochen Voss wrote:

> On Sat, Jan 29, 2005 at 05:40:05PM +0100, Santiago Vila wrote:
> > You forgot to quote last thing I said when closing the bug.
> >
> > So I'll repeat: Please read the logs for non-bug Bug#292759, where the
> > author explains the rationale for putting gettext.sh in /usr/bin.
> Sorry, I did not find relevant information there.
> Does the bug report log explain somewhere whether it is actually ok to
> place this file in /usr/bin on a Debian system?

Sorry, I really meant non-bug #284637.

Debian does not have a designated directory for shell script function
libraries which is in the PATH by default, this is why /usr/bin should
be ok.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: shell script sniplets in /usr/bin?

[Santiago Vila]

On Sat, 29 Jan 2005, sean finney wrote:

> why not do something like this in
> any script that uses gettext:
> 
> #!/bin/sh
> 
> PATH=${PATH}:/usr/share/gettext/scripts
> . gettext.sh

Because we already have /usr/bin for that and there is no need to
change every script that uses gettext.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Bug#292759: shell script sniplets in /usr/bin?

[Santiago Vila]

On Sun, 30 Jan 2005, Matthew Palmer wrote:

> "Because I don't wanna play by the rules!" is not a rationale.

You are mistaken. I want to play by the rules, but the rules say
executables should go to /usr/bin, *not* that everything in /usr/bin
should be executable.

> So you have to specify a path -- so what?  The way things stand at
> the moment, if I were to drop a gettext.sh in my ~/bin (which is
> quite likely, except that I don't like to put a .sh on my helper
> scripts) your shell scripts would suddenly go tits-up in a most
> unpleasant fashion.  Personally, *that* would be enough to make me
> want to hardcode the path.

The same could be said for an executable called "ls". Exactly the same.
You do not hardcode /bin/ls in your shell scripts because we already
have the PATH for that. Similarly, there is no reason to hardcode
the location of gettext.sh because we already have the PATH.
The name "gettext.sh" should be distinctive enough to avoid namespace
pollution. OTOH, if you are really worried about namespace pollution,
then please press the tab key twice while running bash.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: shell script sniplets in /usr/bin?

[Santiago Vila]

On Sun, 30 Jan 2005, Jochen Voss wrote:

> Hello John,
> 
> On Sat, Jan 29, 2005 at 11:46:12AM -0600, John Hasler wrote:
> > Jochen Voss writes:
> > > Any references for this?  I was a little bit disappointed that the FHS
> > > was so unclear about /usr/bin and I do not know where else to look.
> > 
> > While the FHS is not as explicit as it might be, with the application of a
> > bit of common sense it is sufficiently clear.
> 
> One should think so, but the presence of /usr/bin/gettect.sh and
> the fact that my bug report was closed by the maintainer shed some
> doubt on it.  Any idea how I should proceed?

I suggest that you read the reply by the author. For the benefit of
those who don't have web browsers, I'll quote it here:

  gettext.sh is meant to be sourced from shell scripts, using the "."
  command. This command looks in $PATH, but none of the subdirectories
  of /usr/share/gettext is present in $PATH.

  You can also see it this way: POSIX /bin/sh supports the concept of
  functions. As in any programming language, functions can be grouped
  together in a file called "library". As in any programming language,
  such libraries can be loaded. In C it's via dlsym(), in sh it's via ".".

  Where does dlsym() look up the libraries? In /usr/lib. So Debian
  installs C libraries in /usr/lib/. Fine.

  Where does "." look up the libraries? Anywhere in $PATH. In particular in
  /usr/bin.

  If the Debian project designates a particular directory for shell script
  function libraries, and puts this directory in $PATH by default, GNU gettext
  will happily install its contents there.

  If it doesn't, then - by the analogy with /usr/lib above - there is nothing
  wrong with gettext.sh in /usr/lib/.


So, the common sense says /usr/bin is ok for gettext.sh, not the opposite.

If you want to make policy that /usr/bin should only contain executables,
go ahead, make a policy proposal, but none of you have answered to the
question made by Frank Küster:

  Do you think we should simply not make any use of the POSIX feature
  that . $name will look for $name in the $PATH? Or do you think we should
  add a directory to PATH that is then dedicated to such shell snippets?

Anyway, this is a policy issue, so please followup to debian-policy.

Re: mirror-2.9 released, and hopefully DFSG compliant

[Santiago Vila]

-BEGIN PGP SIGNED MESSAGE-

On Mon, 1 Jun 1998, Dirk Eddelbuettel wrote:

> A new mirror_2.9-1 is now on master. The copyright has changed (see below),
> and should be fine with us. Or is the 'changes must be distributed as
> patches' policy too restrictive for us?

It is allowed, as an "exception" (but this could change if we re-ratify
the DFSG, which will not happen very soon, anyway).

BTW: Will this new mirror be in hamm? [ Maybe it should ].

-BEGIN PGP SIGNATURE-
Version: 2.6.3ia
Charset: latin1

iQCVAgUBNXO95SqK7IlOjMLFAQG8bQP+OEHNXaw2t6rx8S2WI1tW4bkJnwBbmiFK
qmsyDFLr7fUTJgsMRt2d9pHw/zFOCnJR6e5pSF9HKpCEx2NI1rOlpYcX1KZ/iOFh
rNd8cqngZUGjDW6fqmOQEPHcZZpmlYw34v+wanPmjFAejZez0+ySjHRKlknsrju+
v3XhSr13gt0=
=dOuk
-END PGP SIGNATURE-


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: mirror-2.9 released, and hopefully DFSG compliant

[Santiago Vila]

-BEGIN PGP SIGNED MESSAGE-

On Mon, 1 Jun 1998, Dirk Eddelbuettel wrote:

>Permission to modify the software is granted, but not the right to
>distribute the modified code. Modifications are to be distributed as
>patches to released version.

Mmm, wait a moment...

Does this mean the modified-for-Debian "mirror" may not be distributed
inside the .deb binary package?

If so, then perhaps you will have to patch it in the postinst (!).

Opinions?

-BEGIN PGP SIGNATURE-
Version: 2.6.3ia
Charset: latin1

iQCVAgUBNXQL2CqK7IlOjMLFAQE1jgP7B4DJ7u8qw3t1wXGqSBqxUHOlHtvtG2Dc
F7EcBqXCleDdtVtI6GcFr6Qh7Y6Ds2IgUp+ctErtY1AVt5F2tSmFYwO0cwPDmUem
8IHAku98TjKcs4I+PSVDl/Z/LghvUgxtcUp9kNuRx3ZxA8j+QTFBtzMOe0b105+v
wHfuV0H+qwM=
=43tN
-END PGP SIGNATURE-


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: mirror-2.9 released, and hopefully DFSG compliant

[Santiago Vila]

-BEGIN PGP SIGNED MESSAGE-

On Tue, 2 Jun 1998, Dirk Eddelbuettel wrote:

>   Santiago> Does this mean the modified-for-Debian "mirror" may not be
>   Santiago> distributed inside the .deb binary package?
> 
> Well, in mirror_2.9-1, all files by Lee are unmodified.  No patches yet ...

Yes, but the point would not be whether you actually modify or not, but
whether license actually allows you to do so or not, even if you do not
modify it yet. Packages in main have to be DFSG-compliant, this is
independent from the fact that we actually modify it for Debian or not.

[ Otherwise, I could distribute my "unmodified" pine396-src package in
  main, which would be clearly against DFSG ].

-BEGIN PGP SIGNATURE-
Version: 2.6.3ia
Charset: latin1

iQCVAgUBNXULBCqK7IlOjMLFAQEhtgP+O4aMdI9czapOBsodyMbgy11v91IySufT
ECaJ3ZTUyIGR6XEa7XYMhSEOXsPaxy11LNIRWjMs7O/YU2Ms9iasYGE1NMht7d4X
ohWJZsLdsIPiF7/KL3FCPWE/omfEmxcfckzs5gluaurtEXFberJmp14zifzeePFG
PrP2ulwQXJI=
=iTQQ
-END PGP SIGNATURE-


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: mirror-2.9 released, and hopefully DFSG compliant

[Santiago Vila]

-BEGIN PGP SIGNED MESSAGE-

Clarification, I said:

> [ Otherwise, I could distribute my "unmodified" pine396-src package in
>   main, which would be clearly against DFSG ].

Really, this was not a good example, because pine copyright would
still say "No commercial use of these trademarks".

-BEGIN PGP SIGNATURE-
Version: 2.6.3ia
Charset: latin1

iQCVAgUBNXURYSqK7IlOjMLFAQHyZQQAhAmfk1ylPOtKT/Kc4RsLUahSmxYIp9iV
dXgDOsXZPQVcuZEXBESBkcwspkKNgUkbik2eGtKxLei8HjQT18Ie0ilaFgv4FzgB
BnPrMKgtrhmlSH2id+TtS9nI9uPNXTrSDIVrPosdkMkLcpMpZVMfqVT03OBoAAsr
jHBVw8aszHo=
=rg3I
-END PGP SIGNATURE-


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Bug#300996: ITP: clamassassin -- simple wrapper for clamav

[Santiago Vila]

On Mon, 21 Mar 2005, Nick Price wrote:

> Package: wnpp
> Severity: wishlist
> Owner: Nick Price <[EMAIL PROTECTED]>
> 
> 
> * Package name: clamassassin
>   Version : 1.2.2 
>   Upstream Author : James Lick <[EMAIL PROTECTED]> 
> * URL : http://drivel.com/clamassassin/
> * License : http://drivel.com/clamassassin/clamassassin-1.2.2/LICENSE
> Description : clamassassin is a simple virus filter wrapper for
> clamav for use in procmail filters and similar applications.
> 
> clamassassin is a simple virus filter wrapper for clamav for use
> inprocmail filters and similar applications.  Its interface is similar
> to that of spamassassin, making it easy to implement for those
> familiar with that tool.  clamassassin is designed with an emphasis on
> security, robustness, and simplicity.

I was going to package this but the source tarball does not include
configure.ac. Please ask the author to include it, so that the source
is really complete.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: debian.org email forwarding

[Santiago Vila]

On Sat, 7 May 2005, martin f krafft wrote:

> I am trying to switch to procmail on master, which involves putting
> a proper ~/.procmailrc in place and nothing else.
> 
> However, a major problem arises due to spam. My last rule forwards
> remaining mails to my normal email address, using the standard mail
> forwarding syntax:
> 
>   :0
>   ! [EMAIL PROTECTED]
> 
> Any message forwarded will then be sent with [EMAIL PROTECTED]
> overriding the original envelope sender.
> 
> The best way to deal with this is to set
> 
>   SENDMAIL="/usr/sbin/sendmail -f $SENDER"
> 
> in the .procmailrc file, and the db.debian.or email forwarding page
> [0] seems to suggest at the bottom, that $SENDER is in fact passed
> in the environment.
> 
> This does not seem to be the case. By the time that procmail is
> invoked, the environment is pretty much cleared of most everything,
> so I cannot get at the original sender address anymore, at least not
> with trivial/robust means.
> 
> Is this a problem in the mail configuration of exim? If yes, it
> would be great to get this fixed. If no, then the db.debian.org page
> [0] should be updated. Or am I just overlooking a trivial detail?
> 
> 0. http://db.debian.org/forward.html

Why are you so much worried about the envelope sender, when it is
usually forged? You are not trying to bounce messages that you didn't
want to receive back to the sender, are you? (that would be bounce-spam).

I'm more worried about "! [EMAIL PROTECTED]" rewriting the message body,
so I usually do something like "formail -R Sender: X-Master-Sender:"
in master and then "formail -I Sender: -R X-Master-Sender: Sender:" on
the machine where I actually receive the message.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: debian.org email forwarding

[Santiago Vila]

On Sat, 7 May 2005, martin f krafft wrote:

> also sprach Santiago Vila <[EMAIL PROTECTED]> [2005.05.07.1403 +0200]:
> > Why are you so much worried about the envelope sender, when it is
> > usually forged? You are not trying to bounce messages that you
> > didn't want to receive back to the sender, are you? (that would be
> > bounce-spam).
> 
> Well, sure. The point is that right now, my server rejects a lot of
> spam, so the bounces end up in my regular mailbox. I am effectively
> boune-spamming myself. So I'd rather have the bounce generated by
> master go elsewhere.

You should really accept messages from master before trying to reject
spam, i.e. use some kind of whitelist for master. If that's not possible,
don't forward email to such address.

What we would really need is some procedure in master to reduce the
level of spam we have to receive, in a way what it is either rejected
at SMTP time (using cbl.abuseat.org, for example), or simple vanished
because of lack of RFC 2821 compliance (greylisting).

I still hope that the Debian project (i.e. all of us) realize some day
about how stupid is to accept each and every message when we could
easily get rid of a large portion of spam with virtually no harm to
anybody.

> > I'm more worried about "! [EMAIL PROTECTED]" rewriting the message body,
> 
> You mean the payload? It rewrites the 822 header, but not the
> message body.

Oops, yes, I meant "message content", not message body.

> > so I usually do something like "formail -R Sender: X-Master-Sender:"
> > in master and then "formail -I Sender: -R X-Master-Sender: Sender:" on
> > the machine where I actually receive the message.
> 
> okay, that's also an interesting solution, but it won't solve my
> problem: if the final recipient server rejects the message which
> procmail forwarded, I get the bounce.

Don't forward your email to a server that might bounce it back to
master, then, that would be really rude.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: debian.org email forwarding

[Santiago Vila]

On Sat, 7 May 2005, martin f krafft wrote:

> also sprach Santiago Vila <[EMAIL PROTECTED]> [2005.05.07.1506 +0200]:
> > You should really accept messages from master before trying to
> > reject spam, i.e. use some kind of whitelist for master. If that's
> > not possible, don't forward email to such address.
> 
> The stuff my mail server rejects is 100% spam. master is whitelisted
> for most checks. The only checks that reject mail from master are
> those generated automatically with a Sober or whatever virus in the
> attachment, and among those only the ones that had such a huge hit
> that my virus scanners couldn't cope anymore, so I extracted
> a typical line from the Base64 string and use postfix's body_checks
> now.

Why bother to forward those messages to your mail server at all?
The same base64 string you are using in postfix's body_checks
will surely serve in your .procmailrc in master.

Thanks to base64, I never forward any windows virus to myself, they
are kept in my ~/mail directory. See my ~/pmrc/executables in master
for generic anti windows-executable recipes.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Dear Adrian Bunk, Please hold off a week or two

[Santiago Vila]

On Tue, 31 May 2005, Adrian Bunk wrote:

> On Mon, May 30, 2005 at 03:45:07PM -0400, Joey Hess wrote:
> > Adrian Bunk wrote:
> > > Or do you _really_ want to release sarge with many dozens of already 
> > > known and fixed bugs?
> > 
> > I'd worry about it more if we hadn't suffered from the same or similar
> > problems with ever previous Debian release, TBPH. Even back when we froze
> > unstable, this just pushed certian bugfixes out of the archive entirely.
> >...
> 
> How can this happen whenyou freeze unstable?

I guess you will not understand at each other if you use the term
"freezing unstable" with two different meanings. I see that the term
may have at least two meanings:

* "frozen" is created initially as a copy of unstable. After this,
frozen and unstable evolve separately, unless you upload some package
for "frozen unstable", as we did in the old days. I bet Adrian would
not call this a proper freeze of unstable, as it would be the "frozen"
distribution who would be really frozen, not unstable.

* "unstable" is actually frozen, which means uploads for unstable
are either discouraged, they remain in the limbo, or they are automatically
put in some other distribution above unstable, like new-unstable, until
testing or unstable becomes the new stable.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

automated updates of debian/changelog considered harmful

[Santiago Vila]

Ok, this is already the second time I have to report a bug like this,
so I will warn everybody before I find more of them.

There seems to be a bunch of packages who try to update the changelog
in this way:

   dch -a -p "GNU config automated update: config.sub\
 ($$OLDDATESUB to $$NEWDATESUB), config.guess\
 ($$OLDDATEGUESS to $$NEWDATEGUESS)" ;\

whenever they use new config.guess and config.sub files from the
autotools-dev package.

PLEASE DON'T DO THAT. Don't change the changelog in debian/rules.

Adding changes would be ok for an upload which includes source
(i.e., .dsc and .diff), but it's simply the *wrong* thing to do when
an upload does not include a new source (for example, the changelog
update will also happen on builds made by an autobuilder).

In fact, when an autobuilder builds the package, the .changes file is
wrong, as it is like this:

Maintainer: The usual maintainer <[EMAIL PROTECTED]>
Changed-By: root <[EMAIL PROTECTED]>

instead of this:

Maintainer: Build Daemon <[EMAIL PROTECTED]>
Changed-By: The usual maintainer <[EMAIL PROTECTED]>


[ If you do not believe this, visit buildd.debian.org and see the
  build logs for the lifelines package, for example ].


The fact that the package uses more recent config.* files is simply
*not* such a relevant change to be documented, as the package already
has autotools-dev in the build-depends and it's already known that the
package will always use the most recent config.* files.

Thanks.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: C++ ABI change -- freezing unstable for new C++ library packages

[Santiago Vila]

On Thu, 9 Jun 2005, Adam Majer wrote:

> Also, the testing seems to be now unfrozen except for base. Does the
> base freeze have anything to do with the new C++ ABI?

No, it's more a leftover of the freeze process. I asked Steve today
about this. He says base packages will be unfrozen again in a few days.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Greylisting for @debian.org email, please

[Santiago Vila]

Now that we have released sarge, I would like to ask debian-admin and
the Project Leader to consider seriously doing something to reduce the
level of spam we have to receive, store, and filter in our @debian.org
addresses.

For example, we could use greylisting. Or we could reject messages that
are known to come directly from trojanized windows machines acting as
open proxies. Or even better, we could do both things.

At this point of time, in the year 2005, doing absolutely nothing to
prevent spam reaching our inboxes is not reasonable anymore.

Thanks.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: setting umask globally

[Santiago Vila]

On Fri, 17 Jun 2005, martin f krafft wrote:

> If one is faced with the task to set the umask globally for all
> users and shells, this turns out to be a job of redundancy: every
> shell uses its own file in /etc, and you end up making changes to
> 5 files or more (depending on the number of installed shells).
> What's worse: change the umask and you'll possibly forget one shell
> or the other, which may cause delays in your user's work, or even
> break things (yeah, you should not rely on umask; yeah, don't tell
> me...)
>
> [ snipped gigantic hack ]
>
> So the plan is:
>
>   1. gather comments.
>   2. file a bug against base-files to have the files included.
>   3. once base-files hits unstable, mass-file bugs against all
>  compatible shells and ask them to use it.
>   4. rejoice.
>
> So, let's start at (1)...

This is Unix, and we are system integrators. Our job is to make things
simpler, not more complex. I wonder why people always consider
base-files as the package of choice to implement all sorts of ugly
global hacks.

There is already an umask setting in /etc/login.defs. If it makes people
happy, I will happily drop the umask setting from /etc/profile, so
that people do not have to decide between login.defs and profile
when trying to set an umask globally.

Then we could make policy (or just convince the shell maintainers) that
shells should not set umask in their default global initialization
scripts, so that they do not override the one in /etc/login.defs.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Greylisting for @debian.org email, please

[Santiago Vila]

On Fri, 17 Jun 2005, Jesus Climent wrote:

> On Thu, Jun 16, 2005 at 08:46:33PM -0700, Blars Blarson wrote:
>
> > I recomed using spamhaus SBL-XBL, or at least CBL (which is included in
> > SBL-XBL).
> 
> I dont: http://www.paulgraham.com/spamhausblacklist.html

Selected paragraph from the article:

   This case illustrates an important failing of blacklists. Unlike
   filters, they're run by humans. And humans are all too likely to abuse
   the kind of power that blacklists embody. Perhaps someone will start
   another blacklist that tries to avoid such abuses. But how long before
   that one becomes corrupt too?

This is pure FUD against DNSBLs (which is their proper name). The truth
is that some DNSBLs are run by humans, but not all of them are.

The CBL, in particular, is completely automated, it tries very hard
to not list "real" mail servers, and you can remove yourself trivially.

In fact, most of the effectiveness of SBL-XBL really comes from the CBL,
as shown by the widely known statistics:

http://www.sdsc.edu/~jeff/spam/Blacklists_Compared.html

We could use just the CBL, and we would already reduce spam by a half
without a lot of controversy. I will be more than happy to apply my
other filters (razor, pyzor, bogofilter) to the *remaining* email, but
at least I would know that we are doing *something* about it at the
SMTP level, which is where we can really avoid spam to reach our inboxes.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Greylisting for @debian.org email, please

[Santiago Vila]

On Fri, 17 Jun 2005, Andrew Suffield wrote:

> On Fri, Jun 17, 2005 at 05:53:25PM +0200, Santiago Vila wrote:
> > In fact, most of the effectiveness of SBL-XBL really comes from the CBL,
> > as shown by the widely known statistics:
> > 
> > http://www.sdsc.edu/~jeff/spam/Blacklists_Compared.html
> 
> Statistics which list only hits, and not false positives or false
> negatives, pretty much speak for themselves (and the people who cite
> them) as to their relevance.

This is from the statistics for "4 June 2005" from the URL above:

   13219 sbl-xbl.spamhaus.org (union of all results)
   10757 cbl.abuseat.org

Even if those are absolute numbers, and do not include false positives,
they allow us to say things like "most of the spam caught by SBL-XBL
comes from the fact that it includes the CBL". which is what I meant.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Greylisting for @debian.org email, please

[Santiago Vila]

On Mon, 20 Jun 2005, Steve Greenland wrote:

> On 18-Jun-05, 17:24 (CDT), Thomas Bushnell BSG <[EMAIL PROTECTED]> wrote:
> >
> > An email address with such blocking on it is therefore not suitable
> > for the Maintainer: field of a Debian package.
>
> Any spam filtering system is going to have *some* false positives.

Indeed.

> Are you claiming that if I do *any* spam filtering on the address
> listed in my packages, it is not suitable?

I wonder the same. Apparently, receiving tons of spam is not our only
duty as package maintainers, it seems we are also forced to *read* it
to be "good maintainers"...

Thomas: If you send me a message which is "spammy" in nature (for
whatever definition my bayesian filter has of "spammy") and it's
stored in my spam folder, it is very likely that I will not read it,
and you will never know that the message landed in my spam folder.

At least using a good DNSBL like the CBL would clearly tell the sender
(if it's a human) that the message will not be read, since the message
is rejected at SMTP stage.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Getting rid of circular dependencies

[Santiago Vila]

On Fri, 24 Jun 2005, Peter Samuelson wrote:

> Depends does not just mean "executables will crash or fail to load".
> It actually means "it is pointless to install this package without this
> other package".

I think we should not use such meaning for the Depends field.

Otherwise we could end up having control files like this:

Package: libfoo
Depends: complete-or'ed-list-of-all-packages-which-depend-on-libfoo

> [...] Perhaps there is need of a package flag that says "it is
> pointless to have this package installed by itself, so remove it if
> nothing depends on it".

We already have something for that. It's called "Section: libs"
and deborphan, and it works great.

Perhaps we should just move to section libs any package which is
useless by itself, and it's only useful in combination with others,
much like libraries, but without requiring them to be real libraries.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: OT: No unsubscribe signature?

[Santiago Vila]

On Wed, 29 Jun 2005, Pascal Hakim wrote:

> In my experience as a listmaster, the people who like to complain about
> the fact that we add a signature on the bottom of every email, will
> usually find a number of other things they dislike. [...]

That's funny. I don't like the high number of spam messages I receive
from the lists. Does that mean I am wrong by thinking that we should
not add a footer to every message?

> Placing a footer in list traffic is a compromise between modifying
> messages as little as possible and trying to help people find a way
> to get their questions answered.

A bad compromise, I would say. The footer is harmful for a number of
reasons (for example, it ends up being quoted over and over again
in some threads, and we already have RFC-compliant headers for that).
Those who know how to unsubscribe should not pay the price for those
who don't know.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: mail all bug reporters

[Santiago Vila]

On Tue, 28 Jun 2005, Nico Golde wrote:

> I think you misunderstood me. Example:
> An adopted package xxx has a lot of old bugs which are
> related to very old versions. Now the maintainer changes.
> Now he wants to send mails to all bug openors if the bug is
> still actual and can be reproduced.

That's not a reason good enough, IMHO, to send virtually identical email
to a lot of people.

Instead, try to reproduce the bug yourself, and ask the submitter to
reproduce it only if you can't.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]