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 se
>>"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
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 sen
* 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 ca
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 instal
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 t
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 /usr/bi
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".
> Standards
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
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
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
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 repo
* 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, 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 package
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, 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
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 p
* 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
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 earlie
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 curren
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 v
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:13:26PM +0200, Arthur Korn wrote:
> /usr/lib/menu is not shareable
Yes, it is. There's a reason why each entry starts:
?package()
Anyway, that's not really relevent -- /usr/share is for
architecture-independent static files. The FHS doesn't grant
exceptions for fi
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 indica
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 it
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 reliab
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
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: 102
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
Standards-Vers
29 matches
Mail list logo
