Chris Waters <[EMAIL PROTECTED]> writes:
> This seems like *such* an obvious solution to so many problems that I
> find myself perplexed why this hasn't done before, by others.
Because it requires glibc 2.1 and kernel 2.2.
Guy
Joey Hess <[EMAIL PROTECTED]> writes:
> Manoj Srivastava wrote:
> > I think I tend to agree. Could some one please have a look at
> > the non-US licences, and determine which should be non-US/main and
> > which should be non-US/non-free?
>
> I understand that this is going to happen or
Marcus Brinkmann <[EMAIL PROTECTED]> writes:
> 1) Make "-e" the default.
No way! -e is a horrible argument that makes makefiles break for
mysterious reasons.
You should just arrange for the overrides to be set on the command
line.
Guy
Laurent Martelli <[EMAIL PROTECTED]> writes:
> I think it would be better to implement a keyword search in dselect
> because anyway, some packages would belong to several directories.
As archive maintainer, I agree with this. The section names are a
very coarse method of dividing packages.
Gu
Santiago Vila <[EMAIL PROTECTED]> writes:
> Good idea, but if we redefine standard, dselect will install a lot of new
> packages by default.
Good point. I guess we need a new priority after all.
Guy
This is a good idea, but rather than introduce a new priority, I
propose that we loosen the definitions of the higher priorities.
Currently we have
Essential (a de-facto priority composed of those packages with the
Essential flag on)
Required
Important
Standard
Optional
Extra
If our in
Julian Gilbey <[EMAIL PROTECTED]> writes:
> I would suggest actually having both in the .changes file, then
> dinstall could decide whether to close bugs or change their severity
> to fixed based on the content of the two fields. I have handwritten
> patches to dinstall and the dpkg-dev scripts t
Adrian Bridgett <[EMAIL PROTECTED]> writes:
> I've got a package with _loads_ of .html files, but I can't see if they
> should be compressed or not.
Practically every viewer and server can handle gzipped files. Where
things break down is in following links. Not all viewer/servers will
try foo.g
Many years ago, the override files didn't include all packages. Ian
and I changed it for a number of reasons:
A common override file allows some consistency in the archive because
a small group of people can set sections and priorities. It allows
new packages to be checked before they are placed
Wichert Akkerman <[EMAIL PROTECTED]> writes:
> I remember comments (I think from Richard Braakman) about this: at the
> moment the overrides-file lists info for all packages, not only
> overrides. He wanted to change this for potato so indeed only overrides
> are in there and the information in th
Marcus Brinkmann <[EMAIL PROTECTED]> writes:
> Can you estimate the time you need to prepare this? Can I start to work out
> the details for a policy proposal?
First estimate how many packages are involved. If it's only a
handful, it's not worth it (yet).
Guy
b looks like a reasonable solution, and would not be hard to
implement. Of course, as you said, if only a handful of packages are
affected, then it's less work to do c.
Guy
Richard Braakman <[EMAIL PROTECTED]> writes:
> I've written this script,
> but I don't know how much code is in use that assumes that there's
> only one version of each source package in the archive.
mkmaintainers and archivetool are two. And dinstall obviously.
> Mind you, I'm just out to prov
There's currently a package in Incoming, sympa, with a copyright file
written in French. This raises a host of potential problems, and may
require some policy changes.
Should an English translation be required? Currently a user need only
speak English to decide if a package is free enough for hi
[EMAIL PROTECTED] (Ian Jackson) writes:
> Does the policy list think it would be a good idea to add a piece to
> the policy manual asking maintainers who inherit a package and
> uploaders of NMU's not to change the layout, structure or style of the
> source code unless it is really necessary ?
No
Francesco Potorti` <[EMAIL PROTECTED]> writes:
> As you see, the file is sourced, which means that the values of the
> variables defined should be properly quoted.
Yes, it is a bug in login that it doesn't do this.
> Moreover, export instructions
> are needed inside /etc/environment, un
Zed Pobre <[EMAIL PROTECTED]> writes:
> Is this segment of the packaging manual accurate? I recall being told
Either is fine as far as the archive scripts are concerned.
Guy
Manoj Srivastava <[EMAIL PROTECTED]> writes:
> Marco> What about 960501? It's shorter.
> Marco> (This format has NO Y2K problems.)
>
> Really? When is 010501?
That version would be written as 20010501. Marco was just pointing
out that abbreviating 19xx as xx doesn't always cause y2k pr
Just put non-free and contrib as part of the section. bash is in the
base section. xv is in the non-free/graphics section.
Guy
Herbert Xu <[EMAIL PROTECTED]> writes:
> Well, maybe. But then people may start using /usr/local/lib and you
> will end up adding that to base-files and maybe even more. The real
> solution is the one people have been talking about and seem to be
> the current policy, i.e., to create /usr/local
Jason Gunthorpe <[EMAIL PROTECTED]> writes:
> I could stop fiddling with the GUI (again!) and work on those issues for a
> bit.. ??
I think that would be a good idea. apt can then be the default dpkg
method in 2.1. The GUI won't be ready for 2.1 either way.
Guy
Joel Klecker <[EMAIL PROTECTED]> writes:
> [6] I see a lot of packages using -debian-linux though
That's a violation of policy.
> [7] I don't understand why we use "i486" for some things and "i386" for
> others though
Because of the different outputs of `dpkg --print-architecture' and
`dpkg --p
Richard Braakman <[EMAIL PROTECTED]> writes:
> Oh... then this is a new thing :) I maintain several packages that
> install their html documentation uncompressed, because compressed
> html was useless.
I've got compressed html in the libtiff3g directory, and I just
confirmed Manoj's findings - n
Joseph Carter <[EMAIL PROTECTED]> writes:
> Because dwww requires essentially apache, though with effort it can work
> with other things.
It works with boa out of the box. boa is very light-weight.
Guy
Zed Pobre <[EMAIL PROTECTED]> writes:
> Compressed html changelogs:
dwww deals transparently with compressed html files. Why can't
html changelogs be compressed then?
> As a sidenote, if anyone has an idea for templates for proposals, or
> a format that would make proposals more readable or
reassign 26650 developers-reference
stop
Bill Mitchell <[EMAIL PROTECTED]> writes:
> I suggest that package upload procedures and maintainer
> procedures for creating, renaming, relocating, and removing packages
> be documented.
Agreed, but the more appropriate place for this is the developer's
Manoj Srivastava <[EMAIL PROTECTED]> writes:
> Now that this list is responsible for th abugs in
> debian-policy and the packaging manual, we should really be doing
> something about them.
Yes, who has the authority? Those people who have write access to the
CVS tree? Or the tech comitt
Brederlow <[EMAIL PROTECTED]> writes:
> What would a CD Image be called that contains all of main, some of
> contrib and non-us and some additional Packages and some non-Debian
> stuff (just 1 MB or so) for m68k. The CD would contain the complete
> Official Image and then some more.
You can't cal
Manoj Srivastava <[EMAIL PROTECTED]> writes:
> I see ftp://ftp.debian.org/debian/doc/package-developer also
> has: 7 programmer.html.tar.gz 55 programmer.ps.gz
>
> Now those definitely seem to be things that belong to core
> policy ;-).
No, that's the dpkg programmer's m
Manoj Srivastava <[EMAIL PROTECTED]> writes:
> This proposal also does not have an ewasy way of transitioning
> between releases of the X WIndow system (like, release 7, or version
> 12. In the current method, one may have multple copies of the X
> window system on the machine simultaneou
Looks good. The only changes I suggest are:
> +If the issue raised is especially contentous, or is deemed to be
> +suitable for review by the full set of developers, then four or more
> +developers can call for a hold on the proposal, and move to send the
> +proposal to the larger
Paul Slootman <[EMAIL PROTECTED]> writes:
> > Here's a top 10 of K/Day for 1998 if you're curious.
> >
> > debian-user 276253
>
> I hope you mean that this is 276253K/day for _all_ subscribers, e.g.
No, I just forgot to divide. It's 276K/day of email written. Sorry.
Guy
To sum up a bit as I see it: RMS's arguments about technical
documentation are sound, imo. Do the same arguments apply to
standards? If not, what is the difference between technical
documentation and a standard.
Guy
Wichert Akkerman <[EMAIL PROTECTED]> writes:
> Another thing I'ld like to see is moving the point of posting from (d)upload
> to dinstall.
Yes, I know I need to implement this.
I looked at the archives and debian-*-changes has generated 160K a day
on average this year. Even a stinkin' analog mod
[EMAIL PROTECTED] (Adam P. Harris) writes:
> I happen to find the "technical" vs "non-technical" distinction fuzzy
> and not particularly helpful.
The proposed constitution makes the distinction. In 4.1 "Together,
the Developers may ... issue *nontechnical* policy documents and
statements." Lat
Manoj Srivastava <[EMAIL PROTECTED]> writes:
> [Everybody following a different standard would make standards
> pointless.]
Yes, of course everybody will agree with you there.
But isn't innovation important? If I come up with a new modified
standard, and prominently plaster big warnings all ove
Manoj Srivastava <[EMAIL PROTECTED]> writes:
> Are you contending that policy be only changed via a general
> resolution?
Of course not.
> The 4 developer veto makes the policy amendment a formal General
> Resolution.
Yes, that's what I was alluding when I said it was unconstitutional.
It
Manoj Srivastava <[EMAIL PROTECTED]> writes:
> Umm, how does the tech committee figure in this? I meant to
> say that say, some one proposes an amendment. After discussion,
> people are strongly divided, and it shall take 4 people to send this
> to the general developer body. Where does t
Marcus Brinkmann <[EMAIL PROTECTED]> writes:
> ((NOTE: this does not mean that I can print a sgml book and sell it,
> as printing is a conversion [read: compilation], and must be granted
> in the license elsewhere to be allowed. But it means that I can
> print the sgml source in a book and sell i
Santiago Vila <[EMAIL PROTECTED]> writes:
> In the meantime, I think we should start thinking about the splitting of
> debian-devel-changes, creating lists for every architecture (we have
> already seven).
The only reason to do this is to quell bandwidth. The discarding of
uninteresting architec
Manoj Srivastava <[EMAIL PROTECTED]> writes:
> How about this: If four or more developers call for a hold on
> the proposal, and move to send the proposal to the larger developer
> body as a SRP, then, at the proposers discretion, the proposal shall
> be sent to the general developers bo
Jules Bean <[EMAIL PROTECTED]> writes:
> Yes. One will. Consensus means everyone. It's that simple. (It doesn't
> mean everyone agrees in their hearts, of course - it just means that they
> have been persuaded by the other camp to allow the motion forward).
Yes, but if consensus cannot be achi
Darren Benham <[EMAIL PROTECTED]> writes:
> On 08-Aug-98 Manoj Srivastava wrote:
> > I think that with the four volunteers that we have already,
> > all of whom are seasoned veterans, the situation seems to be under
> > control, and we can let the selection process be as informal as it is
>
Manoj Srivastava <[EMAIL PROTECTED]> writes:
> However, I do not think that standards documents (and
> possibly other categories [personal opinions come to mind]) benefit
> from being modifiable. In fact, making a modifiable document a
> standard undermines the validity and acceptance of
Manoj Srivastava <[EMAIL PROTECTED]> writes:
> Failing the super-majority, the issue should be
> shelved, if re-submitted as a a fresh proposal.
After some minimum time perhaps?
A good proposal.
Guy
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe".
Martin Mitchell <[EMAIL PROTECTED]> writes:
> Please provide a rationale. Do you think most developers are incapable of
> handling their own packages?
I'm sure most are. It's still better if we archive maintainers do it
as we understand the repercussions of changes and the limitations of
the scr
Yann Dirson <[EMAIL PROTECTED]> writes:
> * Developer controlled automatic archive maintenance (eg removal of
> one's own packages automatically after signed email with list of
> packages to delete)
>
> James Troup: probably useless; needs a lot of work for minimal
> gain. People helpi
Richard Braakman <[EMAIL PROTECTED]> writes:
> Is there a way to query make for the existence of a target?
make -n foo && echo foo is a valid target
Guy
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
"Oliver Elphick" writes:
> I interpreted the sentence `No attempt is made to unwind after errors during
> removal.' to mean that exit status is not checked. Is that the case?
? I wouldn't have thought that was the case, but now am not sure.
Guy
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED
"Oliver Elphick" writes:
> case answer in
> y|Y|YES|yes|Yes)
> rm -rf postgres/data
> ;;
Should you not add
*) echo "Purge aborted."; exit 1;;
?
Guy
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject o
Manoj Srivastava <[EMAIL PROTECTED]> writes:
> Hmm. I think I like the idea of the policy documents being the
> law, and the technical committee like the justices, who lay down
> interpretations (which are referred to latter as and adjunct to prior
> law).
The committee does more than in
Christian Schwarz <[EMAIL PROTECTED]> writes:
> I don't see how this conflicts with the proposed constitution. Please give
> me more info on that.
The constitution places no limitations on the developer's authority
with regard to their own work. Your version says that the maintainers
must follow
Bob Hilliard <[EMAIL PROTECTED]> writes:
> This sounds like a mistake to me.
I agree with Bob. The section 1 manpages should be in the appropriate
package.
Guy
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bob Hilliard <[EMAIL PROTECTED]> writes:
> However, lintian reports an error for the incorrect address,
> even when followed by the correct address. Therefore, I have removed
> the final paragraph of the original copyright notice, leaving in its
> place the two paragraphs quoted above. I be
Oops, I guess I'm from Crete.
Guy
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Christian Schwarz <[EMAIL PROTECTED]> writes:
> Every package in the distribution must have one or more maintainers
> at a time (see below).
That's not currently true. Orphaned packages are not typically
removed from the unstable distribution. Instead their maintainer is
set to (orphaned) or
Also, the meta policy should probably set some limitations on what the
policy can and cannot cover. I believe that a policy which restricts
the manner in which a package can be maintained is not only wrong. It
is outside the scope of policy.
Guy
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
w
Manoj Srivastava <[EMAIL PROTECTED]> writes:
> I submit that the project has changed since you first penned
> policy.
Yes. We're now quite large and have maintainers with very wide levels
of abilities. Unfortunately we can't always rely on maintainer's
making reasonable decisions.
I gue
Dale Scheetz <[EMAIL PROTECTED]> writes:
> The Policy Group was begun about the same time as the QA group, and
> testing, among others. Outside of Ian's original writing of the
> Programmer's guide et al, the current policy documents were created by
> this Policy Group.
Memory is failing you here
Manoj Srivastava <[EMAIL PROTECTED]> writes:
> I agree that there there well may be exceptions to the
> individual directives in the Policy; in which case I think the
> exceptions (when known) should be noted in the policy.
Absolutely. The policy manual should use the standard RFC defini
Perhaps James was unnecessarily caustic in his post. I do disagree,
however, with any policy which restricts in what manner a package can
be maintained by multiple people.
Guy
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
James Troup <[EMAIL PROTECTED]> writes:
> Personally I think this package could go into hamm
For what it's worth, I also think it's fine to go into hamm.
Guy
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Martin Schulze <[EMAIL PROTECTED]> writes:
> We will update the debian keyring with public servers on a
> regular basis and exchange keys - in both directions.
I assume that public servers and you only accept keys signed by
themselves? Otherwise the above could propagate a denial of
Manoj Srivastava <[EMAIL PROTECTED]> writes:
> My proposal is to stop micromanagement and leave some things
> for the maintainer to decide.
Hear, hear!
Guy
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
"Marcelo E. Magallon" <[EMAIL PROTECTED]> writes:
> > 2. The question I have is the exact file format of the `shlibs' control
> > files. Most packages install shlibs files like this:
> > libfoo 1foo (>= 1.2.3-1)
>
> from the wording on the packaging manual, I'd say that the first
> fiel
Jason Gunthorpe <[EMAIL PROTECTED]> writes:
> Source
> This specifies who is providing this archive. In the case of
> Debian the string will read 'Debian'. Other providers may use
> their own string
>
> Label
> This carries the encompassing name o
Manoj Srivastava <[EMAIL PROTECTED]> writes:
> dpkg and friends would not need to be modified to handle
> extrafiles anyway.
No, dpkg --search should know about them.
Guy
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Jason Gunthorpe <[EMAIL PROTECTED]> writes:
> I got a bug report effectively saying that dpkg permits this. Till then I
> had thought it was invalid. only xzip and sgml-tools make use of this.
According to packaging 4.1 it is invalid, "Except where otherwise
stated only a single line of data is a
Christian Schwarz <[EMAIL PROTECTED]> writes:
> Any package installing shared libraries in a directory that's listed
> in /etc/ld.so.conf has to call "ldconfig" in its postinst script, unless
> this script is called with a "failed-*" or "abort-*" argument (in which
> case ldconfig may _not
Juan Cespedes <[EMAIL PROTECTED]> writes:
> Would it be possible for `dinstall' to have an `arch: all'
> package and some arch-specific packages with the same name?
No, it can't handle that. I guess you call it it libc6-doc-sparc ?
Guy
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with
Kirk Hilliard <[EMAIL PROTECTED]> writes:
> For instance, the make-doc package (documentation for make, not a
> package for making documentation) is in section doc even though the
> make package itself is in section devel, but over three quarters of
> the other *-doc packages are in the same secti
I wrote this bit of policy, and Manoj's interpretation is correct.
It's nice, but not required, for scripts to use /bin/sh. Manoj is
being pretty reasonable here:
> The code is not done yet. When I deem it finished, and if it
> still does not use bashisms, I shall think about changing it.
> On Tue, Mar 03, 1998 at 05:15:18PM -0800, Jim wrote:
> > >Is there a way to check how much space a package is using? I looked
> > >for an option for the "dpkg -l", so that the size of each package
> > >would be shown, but found nothing.
`dpkg -s foo | grep Installed-Size' ?
Guy
Topi Miettinen <[EMAIL PROTECTED]> writes:
> Doesn't being in a prosess group also affect signals?
Yes, you can send signals to an entire process group.
> What if attacker
> forks until it gets pid==sid_of_target_which_forgot_setsid and calls
> setsid() and kill(pid_of_target)? I tried reading k
Topi Miettinen <[EMAIL PROTECTED]> writes:
> At least atd, tcplogd, icmplogd and xfs don't do setsid(). How about adding
> some coding advice in Policy, something like your sentence?
I don't think it's the policy document's job to teach people how to do
Unix system programming.
Lack of an setsid
Santiago Vila <[EMAIL PROTECTED]> writes:
> I said (IMHO) it was an error not to *ask* the user about creating a new
> file or leave the file in its inexisting state.
It does ask the user about it if the upstream file changes though.
Guy
Joey Hess <[EMAIL PROTECTED]> writes:
> I've noticed what seems to be a common problem lately: daemons that do not
> chdir / on startup. The problem is, if you mount a debina cd on /mnt, cd to
> /mnt, install some daemons, then /mnt is always busy after that and cannot
> be unmounted. The solution
Joey Hess <[EMAIL PROTECTED]> writes:
> Zed Pobre wrote:
> > Shar-utils.
Or perl doing uuencode.
> This leaves you with a huge postinst file (probably 2x the size of the
> actual file it generates), sitting in /var/lib/dpkg/info/. IMHO, worse than
> just installing a copy of the file into /u
Manoj Srivastava <[EMAIL PROTECTED]> writes:
> In my opinion, I would ask for conffiles to be exactly the set
> of configuration files, plus exceptions decided by consensus no the
> mailing lists
That's a bit much. I agree that conffiles are a proper subset of
configuration files, but ma
Manoj Srivastava <[EMAIL PROTECTED]> writes:
> Why is procps in the former list , and not in the latter?
Presumably because it's called by some other essential script?
One thing I forgot to mention - essential packages may only call other
essential packages in their maintainer scripts.
Manoj Srivastava <[EMAIL PROTECTED]> writes:
> [If this discussion is restricted to essential packages,
> please ignore this message. I am quite confused now]
Yes, we're just talking about essential packages. I agree with
Santiago that all essential packages should be using Pre-Depen
Nicolás Lichtmaier <[EMAIL PROTECTED]> writes:
> This "du" file is completely redundant. And it should be a bug in avery
> package that contains it.
Yes, it's redundant now, but the du's of all the packages might be
extracted and made available in some public place via http. That way
deity coul
[EMAIL PROTECTED] (Richard Braakman) writes:
> Should the installer check, before closing a bug, if that bug was
> reported to the source package (or one of its binary packages) that
> closes it?
The installer will CC the bug closes to the maintainer, so she can
confirm that the right ones were c
G John Lapeyre <[EMAIL PROTECTED]> writes:
> Where can I put a package that is not dangerous, and is
> functional, but is still in early stages of development? I imagine it
> might detract a bit from the rest of the stable distribution, and yet
> there are perhaps some who would like access
Ian Jackson <[EMAIL PROTECTED]> writes:
> There are two reasons I can think of at the moment for putting the
> parsing into dpkg-parsechangelog.
Since Mike is planning to release a new dpkg very soon anyway, someone
can just send him a patch and he'll include it.
Guy
Christian Schwarz <[EMAIL PROTECTED]> writes:
> `However, we might consider having a few packages in unstable which will
> not be included in the `frozen' distribution automatically, for example,
> if the upstream maintainers don't want us to include it in a stable Debian
> release.'
In fact, it
Ian Jackson <[EMAIL PROTECTED]> writes:
> - bugs fixed by nmus but not therefore not closed
> - bugs fixed in unstable but not in stable
> - bugs where related discussion is still ongoing and the bug logs
>would be a useful reference
I originally thought we would use it only for the first
Ian makes a good point that we shouldn't use different words to refer
to the same action. So I'd go for closes rather than fixes.
Regarding the re to use, I don't think we've relaxed it to such a
degree that people will close things by accident. The only difference
is that the original allows wh
James Troup <[EMAIL PROTECTED]> writes:
> IMHO this will lead to spurious Depends: being added to packages
> simply to satisfy 5.6.
That would the tail wagging the dog. Packages which already depend on
a sibling package don't need an additional copy of the copyright. I
don't think maintainers w
[EMAIL PROTECTED] (Kai Henningsen) writes:
> Uploads including a diff _are_ "source uploads", right?
Yes.
G John Lapeyre <[EMAIL PROTECTED]> writes:
>permission is granted to
>freely distribute verbatim copies of this document
>provided that no modifications outside of formatting be
>made, and that this notice remain intact.
>Soeller ([EMAIL PROTECTED]) 1997.
Christian Schwarz <[EMAIL PROTECTED]> writes:
> I fully agree to Manoj. Keeping bugs present in "bo" but fixed in "hamm"
> open, does not make much sense.
It really depends on the severity of the bug.
Guy
Marcelo E. Magallón <[EMAIL PROTECTED]> writes:
> Also, the approved policy states that a NM should not close bugs. But what
> if the bugs are only related to the NMR as in this case?
Seems like it would be ok, but dinstall won't be able to differentiate
it. It can differentiate NMU from MU and
Christian Schwarz <[EMAIL PROTECTED]> writes:
> On 15 Jan 1998, Guy Maor wrote:
> > For programs which can't reload, I assume it would be ok to just let *
> > handle it?
>
> Sorry, but I don't get your point. What is `*' ??
case "$1" in
start
Joey Hess <[EMAIL PROTECTED]> writes:
> I thought that it was common for daemons to cd / after they start up, to
> eliminate this problem?Won't that fix it? I think it's reasonable to expect
> daemons to have this behavior, and if syslogd or klogd doesn't, they are
> broken.
Of course it's a bug
[EMAIL PROTECTED] (Richard Braakman) writes:
> I think that any of these measures would be preferable to introducing
> a new class of "fixed but open" bugs. Such bugs would interfere with
> the attempts to use the bug system as an aid to release engineering,
I don't think that there are so many
Christian Schwarz <[EMAIL PROTECTED]> writes:
> The idea behind this is the following: Currently, the developer announces
> the upload after having the file uploaded to Incoming. Since dinstall only
> runs once a day there is a slight chance that a severe bug is detected and
> fixed before dinstal
Adrian Bridgett <[EMAIL PROTECTED]> writes:
> Packages that contain scripts that use #!/bin/bash should depend on
> bash in case bash becomes a non-essential package
bash will never become nonessential.
Guy
Gregor Hoffleit <[EMAIL PROTECTED]> writes:
> Regarding the notification about fixed bugs in nmu's: Is it really
> intentional that this way (what Christian and Guy propose) the fixed
> bugs won't be recorded anywhere in the package (since I can't list
> them in the changelog), but would onl
Brian White <[EMAIL PROTECTED]> writes:
> I thought they would only be dynamically linked with libc if the linking
> program or another library had linked against libc. Granted, this should
> be true in almost all cases, but I just wanted to get clarification.
Depends on what you mean by "be dyn
1 - 100 of 133 matches
Mail list logo
