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 hel
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
>
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 fro
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 ne
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 forge
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
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
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 unst
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
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 t
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 t
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
> >
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 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 ch
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 shoul
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, e
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
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
* 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]
* 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 happ
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.
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
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 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
On Wed, Aug 09, 2006 at 09:43:06AM -0700, Thomas Bushnell BSG wrote:
> Anthony Towns 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
Anthony Towns 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 been frozen.
I'm co
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 th
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 craptacu
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 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 *impossi
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 ca
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
Anyone with a cdrw/dvdrw drive up for some crazy experiments? Ever
noticed how the color c
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 da
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
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
35 matches
Mail list logo
