On Sun, 6 May 2001, Chris Waters wrote:
This is supposed to happen once enough packages make the transition.
Now, if we're really down to 253 packages that use /usr/doc (with no
symlink), then maybe it's time. But, unfortunately, that number, 253,
measures *claimed* compliance, not actual
On Sun, 6 May 2001, Joey Hess wrote:
Chris Waters wrote:
- A change in the policy to remove the obsolete /usr/doc symlinks.
This is supposed to happen once enough packages make the transition.
No, it is supposed to happen one release _after_ a release in which all
the packages have
* Adam Heath
| Um, when was it decided that woody+1=sarge? When was this flamewar?
It wasn't yet. aj needed a name for woody+1 and picked sarge as an
interim name.
--
Tollef Fog Heen
Unix _IS_ user friendly... It's just selective about who its friends are.
On Sun, 6 May 2001, Chris Waters wrote:
Didn't we already have this discussion? The Standards-Version field
is not a reliable indication of much of anything. I strongly object
Policy says:
Policy says doesn't make the packages comply. And you can file all
the bugs reports you want,
Hi Adam!
You wrote:
Actually, I already did a mass bug filing, on the usr/doc issue(did a grep on
Contents-i386, which wasn't fully accurate(other archs, stale data(up to a
week or so))). I have seen several of the bugs closed, probably more than
half now. I need to do another scan, to see
On Mon, May 07, 2001 at 10:57:37AM +0200, Adrian Bunk wrote:
Standards-Version 3 :
a not FHS compliant package is at most a normal bug
Standards-Version = 3:
a not FHS compliant package is at most a serious bug
This is not correct. You can't change the severity of a bug by twiddling
a field
On Sun, May 06, 2001 at 07:31:43PM +0200, Adrian Bunk wrote:
List of packages with Standards-Version 3.0
-- snip --
[...]
Torsten Landschoff ([EMAIL PROTECTED]) gsfonts-other
Torsten Landschoff ([EMAIL PROTECTED]) gsfonts
Guess I should really upload my local
On Mon, 7 May 2001, Anthony Towns wrote:
...
Standards-Versions aren't release critical. You can put it as
Standards-Version: 526.7.8.9.13-Foo.6 if you want. And no matter what
I will practice your suggestion and upload my packages with
Standards-Version: 526.7.8.9.13-Foo.6.
On Mon, May 07, 2001 at 12:53:50AM +0100, Martin Michlmayr wrote:
Package: gsfonts
Maintainer: Torsten Landschoff [EMAIL PROTECTED]
91489 Package gsfonts still has at least one file in /usr/doc
Package is ready so far and installed locally. But I can't build a
new package since
On Mon, May 07, 2001 at 11:19:57AM +0200, Adrian Bunk wrote:
Standards-Version you have, you still have to follow the FHS, you have
to use /usr/share/doc, and if you specify build-dependencies they have
to be correct.
That means you can file RC bugs on all packages that don't follow the
On Mon, 7 May 2001, Torsten Landschoff wrote:
On Mon, May 07, 2001 at 12:53:50AM +0100, Martin Michlmayr wrote:
Package: gsfonts
Maintainer: Torsten Landschoff [EMAIL PROTECTED]
91489 Package gsfonts still has at least one file in /usr/doc
Package is ready so far and installed
* Torsten Landschoff
| On Mon, May 07, 2001 at 12:53:50AM +0100, Martin Michlmayr wrote:
|
| Package: gsfonts
| Maintainer: Torsten Landschoff [EMAIL PROTECTED]
|91489 Package gsfonts still has at least one file in /usr/doc
|
| Package is ready so far and installed locally. But I can't
On Sun, May 06, 2001 at 03:52:57PM -0500, Steve Greenland wrote:
Uhh, when did that become a must? In 3.5.2 the first paragraph
says
Probably during the policy/packaging merger. I intend at some point
to go through policy and fix all of these confusions. Furthermore, it
makes no sense
Adrian == Adrian Bunk [EMAIL PROTECTED] writes:
Adrian In the source package's `Standards-Version' control
Adrian field, you must specify the most recent version number
Adrian of this policy document with which your package
Adrian complies. The current version number is
On Mon, May 07, 2001 at 10:57:37AM +0200, Adrian Bunk wrote:
but you can't file 1060 RC bugs at the beginning of a freeze.
Why would you want to? File 1060 normal bugs before the freeze! (If
you must file 1060 bugs at all -- I hope that's not a habit of yours.)
If we want, we can adjust the
Hi,
I want to suggest to finish the FHS transition. This includes the
following steps:
- Packages with Standards-Version = 3.0 must follow the FHS.
Policy version 3.0.0.0 was released 30 Jun 1999 and I consider this
enough time for every maintainer to switch to at least this
Adrian Bunk wrote:
...
Oliver Elphick ([EMAIL PROTECTED]) libpgsql
This package is obsolete and should not be included in any release.
--
Oliver Elphick[EMAIL PROTECTED]
Isle of Wight http://www.lfix.co.uk/oliver
PGP:
On Sun, 6 May 2001, Oliver Elphick wrote:
Adrian Bunk wrote:
...
Oliver Elphick ([EMAIL PROTECTED]) libpgsql
This package is obsolete and should not be included in any release.
Please ask the ftp admins to remove the package from unstable (file a bug
against ftp.debian.org).
On Sun, May 06, 2001 at 07:31:43PM +0200, Adrian Bunk wrote:
I want to suggest to finish the FHS transition. This includes the
following steps:
- Packages with Standards-Version = 3.0 must follow the FHS.
Didn't we already have this discussion? The Standards-Version field
is not a reliable
Chris Waters schrieb:
(Plus, as a side issue, by a strict reading of the FHS, we should be
using /usr/share/menu rather than /usr/lib/menu, which means RC bugs
against nearly every package in the system!) :-)
/usr/lib/menu is not shareable, since it would be most confusing
to have a menu item
On Sun, 6 May 2001, Chris Waters wrote:
I want to suggest to finish the FHS transition. This includes the
following steps:
- Packages with Standards-Version = 3.0 must follow the FHS.
Didn't we already have this discussion? The Standards-Version field
is not a reliable indication of
On Sun, May 06, 2001 at 09:13:26PM +0200, Arthur Korn wrote:
/usr/lib/menu is not shareable
Yes, it is. There's a reason why each entry starts:
?package(name)
Anyway, that's not really relevent -- /usr/share is for
architecture-independent static files. The FHS doesn't grant
exceptions
On Sun, May 06, 2001 at 07:31:43PM +0200, Adrian Bunk wrote:
If noone has a good argument against this I'll send
RC bugs in one week to force the upgrade of the Standards-Version.
The packages inetutils, gnumach, hurd and mig are only applicable to the Hurd,
and we have not determined yet
On Sun, May 06, 2001 at 09:27:59PM +0200, Adrian Bunk wrote:
Policy says:
-- snip --
In the source package's `Standards-Version' control field, you must
specify the most recent version number of this policy document with
which your package complies. The current version
On 06-May-01, 14:27 (CDT), Adrian Bunk [EMAIL PROTECTED] wrote:
Policy says:
-- snip --
In the source package's `Standards-Version' control field, you must
specify the most recent version number of this policy document with
which your package complies. The current version
Chris Waters wrote:
- A change in the policy to remove the obsolete /usr/doc symlinks.
This is supposed to happen once enough packages make the transition.
No, it is supposed to happen one release _after_ a release in which all
the packages have made the transition. So sarge at the earliest,
* Adrian Bunk [EMAIL PROTECTED] [20010506 21:27]:
See above: I want to file a RC bug either because
a) the package follows a too old policy or
For the /usr/doc problem, bugs with severity: normal have already been
filed by doogie and joeyh. For these packages, you simply have to
change the
On Sun, May 06, 2001 at 09:27:59PM +0200, Adrian Bunk wrote:
On Sun, 6 May 2001, Chris Waters wrote:
Didn't we already have this discussion? The Standards-Version field
is not a reliable indication of much of anything. I strongly object
Policy says:
Policy says doesn't make the packages
On Sun, May 06, 2001 at 06:29:05PM -0400, Joey Hess wrote:
Chris Waters wrote:
- A change in the policy to remove the obsolete /usr/doc symlinks.
This is supposed to happen once enough packages make the transition.
No, it is supposed to happen one release _after_ a release in which
all
29 matches
Mail list logo
