On Tue, Mar 28, 2000 at 11:54:53AM +0300, Fabrizio Polacco wrote:
> On Fri, Mar 24, 2000 at 06:34:39PM +0100, Gregor Hoffleit wrote:
> > Package: man-db
> > Version: 2.3.15
> > Severity: normal
> >
> > I'm not sure about this, but if FHS uses /usr/share/man
FYI: Alexander Reelsen filed bug#41113 against debian-policy, which
is of interest for debian-java, debian-python as well as debian-perl:
On Sun, Jul 11, 1999 at 11:10:22PM +0200, Alexander Reelsen wrote:
> The following is a proposal to add some rules to the debian policy concerning
> the naming
A question regarding the /usr/doc policy:
Python builds several packages from a single source. Until now, I kept
all documentation in /usr/doc/python. The package's doc directories
had only the copyright file (as requested by the policy) and a
README.Debian that pointed the user to /usr/doc/pytho
Following up on my recent inquiry about the JPython license, here is
an update. Depending on the results of these issues, I will put the
package into main, contrib or non-free.
(1) License issues
Judging from the repsonses, most of the license seems to be acceptable
according to the terms of the
>
> On Thu, Jun 04, 1998 at 11:16:29PM +0200, Gregor Hoffleit wrote:
> > How do I handle version numbers if there are two concurrent branches
> > of a package, one in frozen and one in unstable ? Say I have
> > package_1-2 in frozen and package_1-3 in unstable. Now if
How do I handle version numbers if there are two concurrent branches
of a package, one in frozen and one in unstable ? Say I have
package_1-2 in frozen and package_1-3 in unstable. Now if I have to
release a small bug fix for frozen, how do I call that ? I have seen
Debian revisions like 2hamm1, is
Vincent Renardias <[EMAIL PROTECTED]> wrote:
> On Sat, 21 Feb 1998, Christian Schwarz wrote:
> > So why are all these `desktop environments' designed so that they
> > _need_ to have everything in a single directory hierarchy? This looks
> > to me as they see themselves as `pure add-ons' to other op
You wrote:
Hello,
I'm currently packaging the GNUstep developement environment
(primarily for my own use by now, but I may release it in
experimental if some people are interested. However, the email I
sent to the person listed as working on it in the WNPP bounced, so
I
perl5 installs its modules that are AFAIK architecture-independent
into /usr/lib/perl5. Shouldn't this be /usr/share/perl5 according to
FSSTND? I'm asking since the same kind of situation is with python.
Gregor
James Troup <[EMAIL PROTECTED]> wrote:
Gregor Hoffleit <[EMAIL PROTECTED]> writes:
> Guy wrote:
> > * If the nmu fixes many bugs, close the bugs, but reopen a new
> > one with the diffs
>
> This is a diff [ ... ]
Please watch your c
Guy wrote:
> * If the nmu fixes many bugs, close the bugs, but reopen a new one
> with the diffs
This is a diff between the last maintainer release and this nmu ? What about
nmu releases of new upstream versions ? I guess a diff between the last
maintained release and the nmu would make not mu
the policy could enforce the use of upstream source
archives whereever this is possible, maybe an explicit note in the
developer docs would help, too. Is it allowed to file bugs against
packages that without need use non-upstream orig archives ?
Gregor
---
| Gregor Hoffleit admi
I see no easy way to map this to the traditional FSSTND, still I'm not decided
on which points this really contradicts the FSSTND. Could somebody comment here
?
Gregor
---
| Gregor Hoffleit admin MATHInet / contact HeidelNeXT |
| MAIL: Mathematisches Institut PHONE: (49)62
13 matches
Mail list logo
