Anthony Towns wrote:
Yesterday, glibc 2.3.999.2-10 was accidently uploaded to unstable
instead of experimental [...] Would anyone like to contribute their
thoughts, so we can do an air crash style failure analysis to work out
how we can avoid this class of problem in future, given the safety net
On Wed, Sep 06, 2006 at 10:34:31AM +0200, BALLABIO GERARDO wrote:
Is there any sensible reason for ever uploading a package in unstable
with a higher version than in experimental? If not, such uploads can
simply be forbidden altogether.
The documented and preferred way to remove packages from
From: Wouter Verhelst,,, [mailto:[EMAIL PROTECTED]
Is there any sensible reason for ever uploading a package in
unstable
with a higher version than in experimental? If not, such uploads can
simply be forbidden altogether.
The documented and preferred way to remove packages from
Hello,
BALLABIO GERARDO schrieb:
People remove packages from experimental only once in a while, thus
always asking for confirmation shouldn't be too much of a hassle, and
actually may be desirable. At least for those like me who redefine rm as
rm -i in their .bashrc.
Maybe it would help to
Gustavo Noronha Silva [EMAIL PROTECTED] writes:
That would be good to be add in cdbs. I think we might want to have it
more flexible to allow it to work for CDDs too but I liked it very
much :-D
It does not look right to me, though.. what about buildds? And what
about people forgetting an
Hello!
On Tue, 22 Aug 2006 20:51:56 +0200, David Nusinow wrote:
On Tue, Aug 22, 2006 at 03:30:07PM -0400, Joey Hess wrote:
Drew Parsons wrote:
Unfortunately it's happened against, this time with the upload of
xorg-server (xserver-xorg-core) 1:1.1.1-3, accidentally uploaded
to unstable
On Thu, 2006-08-24 at 16:51 +0200, Luca Capello wrote:
If it's not my fault, however, I think we need a new package in
experimental...
Already uploaded.
--
Earthling Michel Dänzer | http://tungstengraphics.com
Libre software enthusiast | Debian, X and
Em Tue, 22 Aug 2006 23:47:09 -0300
Otavio Salvador [EMAIL PROTECTED] escreveu:
Drew Parsons [EMAIL PROTECTED] writes:
e.g.
build: test_stable patch build-stamp
instead of
build: patch build-stamp
That would be good to be add in cdbs. I think we might want to have it
more flexible
The Dear Project Leader wrote:
Yesterday, glibc 2.3.999.2-10 was accidently uploaded to unstable instead
of experimental, and on the request of the release managers, I UNACCEPTed
it, given it was a major accidental change to a rather core library just
as that library should've been frozen.
* Drew Parsons ([EMAIL PROTECTED]) [060822 11:04]:
2) [technical] Remove the single point of failure by adding a
Distribution: field to debian/control, say. The package will be
rejected if the two fields in control and changelog do not match.
or just make dpkg-buildpackage fail if that
* Drew Parsons wrote:
3) [policy] Manual processing by ftp-masters when changing distro.
The distribution wasn't changed.
Norbert
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
We have stated:
3) [policy] Manual processing by ftp-masters when changing distro.
Their decision is automatic rejection by default unless there is a
changelog entry explicitly stating the distro change is occurs. This
need only apply for uploads to unstable (or stable), not for uploads to
On Tue, Aug 22, 2006 at 11:12:44AM +0200, Norbert Tretkowski wrote:
* Drew Parsons wrote:
3) [policy] Manual processing by ftp-masters when changing distro.
The distribution wasn't changed.
The version of the uploaded xorg-server package was higher than the
version in experimental, and it
Norbert wrote:
* Drew Parsons wrote:
3) [policy] Manual processing by ftp-masters when changing distro.
The distribution wasn't changed.
It was in the case of the xserver-xorg upload. 1:1.1.1-2 had been sent to
experimental, 1:1.1.1-3 was sent to unstable.
Drew
--
To UNSUBSCRIBE, email
Drew Parsons a écrit :
The Dear Project Leader wrote:
Yesterday, glibc 2.3.999.2-10 was accidently uploaded to unstable instead
of experimental, and on the request of the release managers, I UNACCEPTed
it, given it was a major accidental change to a rather core library just
as that library
On Tue, Aug 22, 2006 at 11:08:49AM +0200, Andreas Barth wrote:
* Drew Parsons ([EMAIL PROTECTED]) [060822 11:04]:
2) [technical] Remove the single point of failure by adding a
Distribution: field to debian/control, say. The package will be
rejected if the two fields in control and
Drew Parsons wrote:
Unfortunately it's happened against, this time with the upload of
xorg-server (xserver-xorg-core) 1:1.1.1-3, accidentally uploaded to
unstable instead of experimental. An easy enough mistake, it's only
one little field in a changelog file.
'2:' is not any worse than '1:',
On Tue, Aug 22, 2006 at 03:30:07PM -0400, Joey Hess wrote:
Drew Parsons wrote:
Unfortunately it's happened against, this time with the upload of
xorg-server (xserver-xorg-core) 1:1.1.1-3, accidentally uploaded to
unstable instead of experimental. An easy enough mistake, it's only
one
On Tue, Aug 22, 2006 at 06:42:46PM +1000, Drew Parsons wrote:
The Dear Project Leader wrote:
Yesterday, glibc 2.3.999.2-10 was accidently uploaded to unstable instead
of experimental, and on the request of the release managers, I UNACCEPTed
it, given it was a major accidental change to a
Denis Barbier wrote:
On Tue, Aug 22, 2006 at 11:08:49AM +0200, Andreas Barth wrote:
* Drew Parsons ([EMAIL PROTECTED]) [060822 11:04]:
2) [technical] Remove the single point of failure by adding a
Distribution: field to debian/control, say. The package will be
rejected if the two
Drew Parsons [EMAIL PROTECTED] writes:
e.g.
build: test_stable patch build-stamp
instead of
build: patch build-stamp
That would be good to be add in cdbs. I think we might want to have it
more flexible to allow it to work for CDDs too but I liked it very
much :-D
--
O T A V I O
Hi *,
Yesterday, glibc 2.3.999.2-10 was accidently uploaded to unstable instead
of experimental, and on the request of the release managers, I UNACCEPTed
it, given it was a major accidental change to a rather core library just
as that library should've been frozen.
It was lucky that was possible
Hi,
On Wed, Aug 09, 2006 at 08:14:56PM +1000, Anthony Towns wrote:
The 2.3.999.2-10 upload (with signatures removed) is available on
ftp-master.debian.org/~ajt/glibc/. Would anyone like to contribute their
thoughts, so we can do an air crash style failure analysis to work
out how we can avoid
On Wed, Aug 09, 2006 at 08:14:56PM +1000, Anthony Towns wrote:
The reason I'm pointing this out at length is to emphasise that as we
improve the archive software this will become not just awkward to do,
but *impossible*.
Is it really an improvement then? :-)
I don't know the internals of dak
On 10741 March 1977, Michael Banck wrote:
That would mean more work for the ftp-masters/ftp-assistants though, so
not sure.
Doesnt sound like much work from that, so should be ok.
--
bye Joerg
mrvn Anyone with a cdrw/dvdrw drive up for some crazy experiments? Ever
noticed how the
On Wed, 2006-08-09 at 12:46 +0200, Michael Banck wrote:
Hi,
On Wed, Aug 09, 2006 at 08:14:56PM +1000, Anthony Towns wrote:
The 2.3.999.2-10 upload (with signatures removed) is available on
ftp-master.debian.org/~ajt/glibc/. Would anyone like to contribute their
thoughts, so we can do an
On Wed, Aug 09, 2006 at 12:50:38PM +0200, Steinar H. Gunderson wrote:
On Wed, Aug 09, 2006 at 08:14:56PM +1000, Anthony Towns wrote:
The reason I'm pointing this out at length is to emphasise that as we
improve the archive software this will become not just awkward to do,
but *impossible*.
Hello,
Anthony Towns wrote:
It worked because I was awake at 4:20am localtime, on IRC to notice,
and willing to do something about it... While that's more common than is
probably good, it's not something I like to see the release depend on...
Well, if you hadn't been awake, the maintainers
On Wed, Aug 09, 2006 at 04:59:13PM +0200, Simon Richter wrote:
Well, if you hadn't been awake, the maintainers would have had to upload
a package with an ugly version number (or even an epoch), which would
not be the end of the world.
Not everyone agrees with that :)
Due to the craptacular
On Thu, 2006-08-10 at 01:15 +1000, Anthony Towns wrote:
On Wed, Aug 09, 2006 at 04:59:13PM +0200, Simon Richter wrote:
Well, if you hadn't been awake, the maintainers would have had to upload
a package with an ugly version number (or even an epoch), which would
not be the end of the
Anthony Towns aj@azure.humbug.org.au writes:
Yesterday, glibc 2.3.999.2-10 was accidently uploaded to unstable instead
of experimental, and on the request of the release managers, I UNACCEPTed
it, given it was a major accidental change to a rather core library just
as that library should've
On Wed, Aug 09, 2006 at 09:43:06AM -0700, Thomas Bushnell BSG wrote:
Anthony Towns aj@azure.humbug.org.au writes:
Yesterday, glibc 2.3.999.2-10 was accidently uploaded to unstable instead
of experimental, and on the request of the release managers, I UNACCEPTed
it, given it was a major
Anthony Towns wrote:
On Wed, Aug 09, 2006 at 04:59:13PM +0200, Simon Richter wrote:
Well, if you hadn't been awake, the maintainers would have had to upload
a package with an ugly version number (or even an epoch), which would
not be the end of the world.
Not everyone agrees with that :)
Simon Richter wrote:
I'm not sure it scales that well if you apply it to the entire archive,
due to the overhead of the mirror pulse. It might make sense to have
mini-pulses for parts of the archive, such as d-i.
That doesn't work very well unless it can be very targeted; the parts of
the
Anthony Towns writes (glibc and UNACCEPTs):
... how we can avoid this class of problem in future, given the safety
net that caught us this time is going away?
Ideally, there would be some automatic checks that could spot
`probably erroneous' uploads, and which you would mention in your
.changes
35 matches
Mail list logo
