Processing commands for [EMAIL PROTECTED]:
close 21969
Bug#21969: [ACCEPTED 1998/05/01] Policy clarification about Standards-Version
Bug closed, ack sent to submitter - they'd better know why !
close 28747
Bug#28747: [ACCEPTED 1999/04/05] Policy note that GPL moved to
Your message dated Tue, 26 Oct 1999 01:12:11 +0100 (BST)
with message-id [EMAIL PROTECTED]
and subject line Bug#41729: [PROPOSAL] Modify dpkg-buildpackage to handle FHS
move
has caused the attached Bug report to be marked as done.
This means that you claim that the problem has been dealt with.
On Mon, Oct 25, 1999 at 10:06:24PM +1000, Herbert Xu wrote:
Let me state once again, this has no bearing whatsoever over the proposed
change in policy and my question about whether escape codes/-e are to be
mentioned or not. It is for purely pendantic value.
On Mon, Oct 25, 1999 at
Processing commands for [EMAIL PROTECTED]:
retitle 46522 [PROPOSED] Simplified definition of Non-free
Bug#46522: [EMAIL PROTECTED]: Re: SSH never free]
Changed Bug title.
severity 46522 wishlist
Bug#46522: [PROPOSED] Simplified definition of Non-free
Severity set to `wishlist'.
retitle 48247
On Mon, Oct 25, 1999 at 10:12:03PM -0400, Raul Miller wrote:
On Tue, Oct 26, 1999 at 10:11:50AM +1000, Herbert Xu wrote:
But do you agree that with your current proposal, you still have to fix all
scripts that use -e/escape codes?
Like I said before, I don't think this issue is relevant
On Tue, Oct 26, 1999 at 12:14:19AM +0100, Julian Gilbey wrote:
Just a question which I haven't thoroughly investigated yet:
I'm about to add #41232 (source dependencies) to the next policy
version. But will this break existing tools? In particular, will the
dpkg* tools yet be able to build
At 00:14 +0100 1999-10-26, Julian Gilbey wrote:
Just a question which I haven't thoroughly investigated yet:
I'm about to add #41232 (source dependencies) to the next policy
version. But will this break existing tools? In particular, will the
dpkg* tools yet be able to build a package using a
On Mon, 25 Oct 1999, Julian Gilbey wrote:
I am about to include this amendment in policy. However, I am stuck
with the wording, as you say the following.
Questions: What version number should be used in footnote 2?
What do we do with the reference implementation?
Good question.
At 00:14 +0100 1999-10-26, Julian Gilbey wrote:
Just a question which I haven't thoroughly investigated yet:
I'm about to add #41232 (source dependencies) to the next policy
version. But will this break existing tools? In particular, will the
dpkg* tools yet be able to build a package
On Tue, Oct 26, 1999 at 12:15:52AM -0700, Joel Klecker wrote:
wtf? when did the proposal change to Source-Depends:? there's no
evidence of that in the logs.
*My* proposal has never changed that way (#41232). The fields are:
Build-Depends:
Build-Depends-Indep:
Build-Conflicts:
What's the current status of this bug report? How will we deal with
this problem?
Julian
MICO (www.mico.org) doesn't use so versions, but always puts the
full version into the library file name. An example result of ldd
is:
coolo:~ ldd /usr/bin/idl
libmico2.2.3.so =
Any progress on this bug report?
Summary of the bug report:
If mirror license is not Debian-specific, its license should explicitly
allow distribution of the program in modified form, by point #4 in
the DFSG.
The maintainer asked the author about being ok that *Debian*
distributes
I agree that update-alternatives shouldn't put an alternative into
manual mode because a _target_ disappeared unexpectedly. I'll look
into this eventually.
But, the problem doesn't happen if you call update-alternatives in the
prerm, which is where you should. So it would be good if the
I am currently sorting through the bugs in debian-policy, and came
across this one by Ian Jackson. Any thoughts?
Julian
I think most of us will agree that we need some kind of way of
distributing and automatically using regression test suites. We need
to do this in a way that allows
Your message dated Tue, 26 Oct 1999 11:05:49 +0100 (BST)
with message-id [EMAIL PROTECTED]
and subject line Bug#26995: fsstnd-1.2.dvi.gz is wrong
has caused the attached Bug report to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is
On Tue, Oct 26, 1999 at 09:52:09AM +0100, Julian Gilbey wrote:
At 00:14 +0100 1999-10-26, Julian Gilbey wrote:
Just a question which I haven't thoroughly investigated yet:
I'm about to add #41232 (source dependencies) to the next policy
version. But will this break existing tools? In
On Tue, 26 Oct 1999, Masato Taruishi wrote:
At Mon, 25 Oct 1999 23:11:18 +0200 (MET DST),
Gergely Madarasz [EMAIL PROTECTED] wrote:
alsadriver-unstable (0.5pre+cvs19991024+1855-1) unstable; urgency=low
.
* new upstream release.
* Changed section from main to contrib.
On Tue, 26 October 1999 11:39:06 +0100, Julian Gilbey wrote:
We spent a lot of time on this list thrashing out the /var/spool/mail
vs. /var/mail issue. It would be a shame if it came to nothing due to
a lack of seconds. Please check up this final proposal (included
below) and second it if
I hereby also second the proposal.
Alexander
--
- Real programmers don't comment their code. If it was hard to write, it
should be hard to understand.
Alexander Koch - - WWJD - aka Efraim - PGP 0xE7694969 - ARGH-RIPE
At 00:14 +0100 1999-10-26, Julian Gilbey wrote:
Just a question which I haven't thoroughly investigated yet:
I'm about to add #41232 (source dependencies) to the next policy
version. But will this break existing tools? In particular, will the
dpkg* tools yet be able to build a package using a
At 06:31 -0400 1999-10-26, Ben Collins wrote:
On Tue, Oct 26, 1999 at 09:52:09AM +0100, Julian Gilbey wrote:
Sorry, I was doing things from memory. The proposal says:
+ p
+This is done using the ttBuild-Depends/tt,
+ttBuild-Depends-Indep/tt, ttBuild-Conflicts/tt, and
+
Previously Julian Gilbey wrote:
I'm about to add #41232 (source dependencies) to the next policy
version. But will this break existing tools?
Yes. And I won't think I want to change dpkg and friends to accept
the fields until someone comes up with a complete implementation.
I'm annoyed
Previously Julian Gilbey wrote:
Do we need to then specify this in the policy manual, or will it be
sufficient to file bugs against packages which don't have the needed
update-alternatives in their prerm?
No need to put this in the policy manual. The policy manual is for
policies, not for
On Tue, Oct 26, 1999 at 01:54:58PM +0200, Wichert Akkerman wrote:
Yes. And I won't think I want to change dpkg and friends to accept
the fields until someone comes up with a complete implementation.
How do you define complete implementation? The build daemon folks
have had a working
On Tue, Oct 26, 1999 at 04:30:50AM -0700, Joel Klecker wrote:
I do have a problem with the text for policy; it does not explain the
difference between Build-Indep-{Depends,Conflicts} and
Build-{Depends,Conflicts}.
The difference is clearly defined by the amendment. The
It seems that this proposal was rejected due to dpkg -iGROEB being
superceded by apt-cdrom. Is this correct?
Julian
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Julian Gilbey, Dept of Maths, QMW, Univ. of London. [EMAIL PROTECTED]
Debian GNU/Linux
This should certainly be discussed with the libc maintainers before
making such a proposal. I am sure that they did not take the decision
lightly.
I wish to change Debian policy regarding libc and the kernel sources.
The document /usr/share/doc/libc6/FAQ.Debian.gz states:
Occasionally,
Proposed addition to 3.1.2:
Because '/usr/local' and its contents are for exclusive use of the
local administrator, a package must not rely on the presence or
absence of files or directories in '/usr/local' for normal
operation, although files present in there may modify or enhance
I'm annoyed though, that everyone is completely ignoring a *working*
implementation of source-dependencies simply because nobody is
willing to clean it up a little and package it. How can that
happen???
Aehm, what do you mean? For just getting src-deps working, it's only
necessary that the
Your message dated Tue, 26 Oct 1999 15:36:43 +0200
with message-id [EMAIL PROTECTED]
and subject line Bug#40742: Your policy proposal
has caused the attached Bug report to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your
Julian Gilbey [EMAIL PROTECTED] wrote:
What's the current status of this bug report? How will we deal with
this problem?
How is this a bug in the policy? If upstream insists on new sonames for each
release. We must release packages with new names for each release as well.
There is no other
On Tue, Oct 26, 1999 at 04:18:55AM -0700, Joel Klecker wrote:
At 06:31 -0400 1999-10-26, Ben Collins wrote:
Ok, this is what I have as recognized fields in the current dpkg CVS. The
wording in that new proposal for bug #41232 through me for a loop. Anyway,
all that is left to be done for dpkg
On Tue, Oct 26, 1999 at 12:45:20PM +0100, Julian Gilbey wrote:
This should certainly be discussed with the libc maintainers before
making such a proposal. I am sure that they did not take the decision
lightly.
I wish to change Debian policy regarding libc and the kernel sources.
The
Previously Julian Gilbey wrote:
It seems that this proposal was rejected due to dpkg -iGROEB being
superceded by apt-cdrom. Is this correct?
I don't think so.. this was that patch that added an option to dpkg
to use filenames instead of looking inside packages, right?
Wichert.
--
Given that there are now two sorts of depends, I am changing the
paragraph:
Packages may not depend on packages with lower priority values. If
this should happen, one of the priority values will have to be
adapted.
to read:
Binary packages may not depend on binary packages with
Reading bug #31645, it seems clear that the Packaging Manual was
accepted as policy, although Joey had reservations.
Should I go ahead and make the modifications Manoj proposed?
Julian
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Julian Gilbey, Dept of
On Tue, Oct 26, 1999 at 04:30:50AM -0700, Joel Klecker wrote:
I do have a problem with the text for policy; it does not explain the
difference between Build-Indep-{Depends,Conflicts} and
Build-{Depends,Conflicts}.
I think you mean the packaging manual, and the diff says quite
clearly (or
Santiago indicated a contradiction between APT's behaviour and the
packaging manual. Santiago: could you suggest a rewording of the
packaging manual which would resolve this issue?
Julian
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Julian Gilbey, Dept of
Previously Julian Gilbey wrote:
Do we need to then specify this in the policy manual, or will it be
sufficient to file bugs against packages which don't have the needed
update-alternatives in their prerm?
No need to put this in the policy manual. The policy manual is for
policies, not
In /usr/doc/debian-policy/policy.html/ch2.html it says:
Packages may not depend on packages with lower priority values. If this
should happen, one of the priority values will have to be adapted.
I think this is unclear. Especially the second sentence. Perhaps this
phraseology would
Has this proposal been effectively rejected?
Julian
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Julian Gilbey, Dept of Maths, QMW, Univ. of London. [EMAIL PROTECTED]
Debian GNU/Linux Developer, see http://www.debian.org/~jdg
Processing commands for [EMAIL PROTECTED]:
reassign 37254 dpkg
Bug#37254: dpkg: update-alternatives madness
Bug reassigned from package `debian-policy, dpkg' to `dpkg'.
thanks
Stopping processing here.
Please contact me if you need assistance.
Darren Benham
(administrator, Debian Bugs
Your message dated Tue, 26 Oct 1999 15:57:20 +0100 (BST)
with message-id [EMAIL PROTECTED]
and subject line Bug#29522: diversions
has caused the attached Bug report to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your
On Tue, Oct 26, 1999 at 14:46:03 +0100, Julian Gilbey wrote:
Are there any objections?
This is not an objection, but I wish there were slightly more accurate term
than binary package, because some binary packages don't contain binaries
(e.g. just data and/or scripts). binary package could be
On Tue Oct 26, 1999 at 10:21:21AM -0400, Ben Collins wrote:
Perhaps the real argument should be, to have something that allows the
users to specify their own headers without libc-dev overwriting them.
That was indeed the problem that caused my concern. When I am hacking
on the kernel
reopen 34223
severity 34223 normal
thanks
On Tue, 26 Oct 1999, Julian Gilbey wrote:
Santiago indicated a contradiction between APT's behaviour and the
packaging manual. Santiago: could you suggest a rewording of the
packaging manual which would resolve this issue?
Simple answer: No, this is
On Tue, Oct 26, 1999 at 09:40:57AM -0600, Erik Andersen wrote:
On Tue Oct 26, 1999 at 10:21:21AM -0400, Ben Collins wrote:
Perhaps the real argument should be, to have something that allows the
users to specify their own headers without libc-dev overwriting them.
That was indeed the
Processing commands for [EMAIL PROTECTED]:
reopen 34223
Bug#34223: apt and packaging manual are in contradiction
is already open, cannot reopen.
severity 34223 normal
Bug#34223: apt and packaging manual are in contradiction
Severity set to `normal'.
thanks
Stopping processing here.
Please
Processing commands for [EMAIL PROTECTED]:
reassign 37254 packaging-manual
Bug#37254: dpkg: update-alternatives madness
Bug reassigned from package `dpkg' to `packaging-manual'.
stop
Stopping processing here.
Please contact me if you need assistance.
Darren Benham
(administrator, Debian Bugs
On Tue, 26 Oct 1999, Julian Gilbey wrote:
Given that there are now two sorts of depends, I am changing the
paragraph:
Packages may not depend on packages with lower priority values. If
this should happen, one of the priority values will have to be
adapted.
to read:
Binary
On Tue, Oct 26, 1999 at 04:51:23PM +0200, Wichert Akkerman wrote:
Previously Antti-Juhani Kaijanaho wrote:
How do you define complete implementation?
A dpkg-source that:
a) supports build-dependencies
b) supports multiple patches
c) can setup a buildroot and start building everything that
OK, almost there. But one quickie:
The sentence:
A package may not modify a conffile of another package.
was replaced by something better, but I'm not sure what the conclusion
was. How about:
The maintainer scripts of a package may not modify a conffile of
_any_ package, including the one
Previously Julian Gilbey wrote:
It seems that this proposal was rejected due to dpkg -iGROEB being
superceded by apt-cdrom. Is this correct?
I don't think so.. this was that patch that added an option to dpkg
to use filenames instead of looking inside packages, right?
Wichert.
Well,
Previously sparc porters wrote:
Personally I don't think dpkg-source can enforce this.
The name dpkg-source here is a bit if a misnomer; it is in fact the name
of a package that includes new versions of dpkg-source,
dpkg-buildpackage, dpkg-genchangers, etc.
I have the tarball available for
On Tue, Oct 26, 1999 at 07:13:27PM +0200, Wichert Akkerman wrote:
Previously sparc porters wrote:
Personally I don't think dpkg-source can enforce this.
The name dpkg-source here is a bit if a misnomer; it is in fact the name
of a package that includes new versions of dpkg-source,
On Tue, Oct 26, 1999 at 07:13:27PM +0200, Wichert Akkerman wrote:
The name dpkg-source here is a bit if a misnomer; it is in fact the name
of a package that includes new versions of dpkg-source,
dpkg-buildpackage, dpkg-genchangers, etc.
I have the tarball available for anyone who wants to
Julian Gilbey [EMAIL PROTECTED] writes:
Given that there are now two sorts of depends, I am changing the
paragraph:
Packages may not depend on packages with lower priority values. If
this should happen, one of the priority values will have to be
adapted.
to read:
Binary
On Tue, Oct 26, 1999 at 09:02:59PM +0200, Wichert Akkerman wrote:
Previously sparc porters wrote:
I still think sbuild is the way to go.
I still think sbuild is not the way to go and would rather see sbuild
modified to handle the new source format.
Oh, in case someone hasn't noticed:
Julian Gilbey [EMAIL PROTECTED] writes:
+ However, because '/usr/local' and its contents are for
+ exclusive use of the local administrator, a package must
+ not rely on the presence or absence of files of
^
+
On Tue, 26 Oct 1999, Julian Gilbey wrote:
Given that there are now two sorts of depends, I am changing the
paragraph:
Packages may not depend on packages with lower priority values. If
this should happen, one of the priority values will have to be
adapted.
to read:
Goswin Brederlow wrote:
Why not pipe it through uncompress.sh as and if present in the
control.tar.gz?
Why not change to using the shar archive format for our packages?
Because it's overly complicated, and unnecessary.
--
see shy jo
I second this proposal.
[Joey, do you want to change the status of this proposal in the BTS?]
Julian
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Julian Gilbey, Dept of Maths, QMW, Univ. of London. [EMAIL PROTECTED]
Debian GNU/Linux Developer,
Why change?
Would it be OK for the source of mount to depend on ssh? (just a realy
extreme example)
No: ssh is not in main (it's in non-US/non-free at present, although
it may well end up in non-US/main very soon). See policy 2.1.2 for
the definition of the `main' section.
Source
Julian Gilbey [EMAIL PROTECTED] writes:
+ However, because '/usr/local' and its contents are for
+ exclusive use of the local administrator, a package must
+ not rely on the presence or absence of files of
^
+
On 21 Oct 1999, Goswin Brederlow wrote:
Of cause policy should encourage to use bzip2 (or gzip if smaller) and
base packages must use tar.gz (or tar.bz2 if bzip2 is in base) so
that one can update debian. Any package using a non default
compression must predepend on that compressor, but that
Julian Gilbey [EMAIL PROTECTED] writes:
On Tue, 26 Oct 1999, Julian Gilbey wrote:
Given that there are now two sorts of depends, I am changing the
paragraph:
Packages may not depend on packages with lower priority values. If
this should happen, one of the priority
Chris Pimlott [EMAIL PROTECTED] writes:
On 21 Oct 1999, Goswin Brederlow wrote:
Of cause policy should encourage to use bzip2 (or gzip if smaller) and
base packages must use tar.gz (or tar.bz2 if bzip2 is in base) so
that one can update debian. Any package using a non default
Joey Hess [EMAIL PROTECTED] writes:
Goswin Brederlow wrote:
Why not pipe it through uncompress.sh as and if present in the
control.tar.gz?
Why not change to using the shar archive format for our packages?
Because it's overly complicated, and unnecessary.
Whats complicated about using
On Tue, Oct 26, 1999 at 03:46:23PM -0400, Ben Collins wrote:
Sbuild calls dpkg-source to unpack, what does it have to do with the
source format?! All it has to do is call whatever executable is needed for
the unpacking. It _already_ handles _everything_ else, _and_ the Build
Dependencies. My
On Tue, Oct 26, 1999 at 07:28:31PM +0200, Goswin Brederlow wrote:
Source packages should also not depend on other packages with higher
priority, otherwise there could arise a situation where you can´t
build a package because you can´t build another.
This is not useful. Priority rating for
Goswin Brederlow wrote:
Whats complicated about using uncompress.sh instead of gzip and
fallback to gzip if not present?
Tons of things. What about programs called in uncompress.sh -- are
dependancies supposed to be fullfilled then? What happens when the script
fails? What if you don't trust
Julian Gilbey [EMAIL PROTECTED] writes:
Why change?
Would it be OK for the source of mount to depend on ssh? (just a realy
extreme example)
No: ssh is not in main (it's in non-US/non-free at present, although
it may well end up in non-US/main very soon). See policy 2.1.2 for
the
On Tue, Oct 26, 1999 at 10:21:21AM -0400, Ben Collins wrote:
is actually nothing wrong with this policy. Personally, I would hope that
it always stays this way.
Ditto.
For the non-i386 archs, it makes for much less
bug reports, and more stable/consistent builds.
FWIW, stability and
73 matches
Mail list logo
