* David Kalnischkies [2010-08-28 16:23 +0200]:
> 2010/8/26 Carsten Hey :
> > * David Kalnischkies [2010-08-26 17:43 +0200]:
> >> Long story short:
> >> If you want to get updates from an archive only if you pushed a version
> >> previously from it: 100 => pin > 500.
> >
> > Wouldn't adding a new fi
2010/8/26 Carsten Hey :
> * David Kalnischkies [2010-08-26 17:43 +0200]:
>> Long story short:
>> If you want to get updates from an archive only if you pushed a version
>> previously from it: 100 => pin > 500.
>
> Wouldn't adding a new field to Release files similar to 'Not-Automatic'
> but pin to
Quoting Otavio Salvador (ota...@ossystems.com.br):
> Hello,
>
> On Wed, Aug 25, 2010 at 7:38 AM, Christian PERRIER wrote:
> > I wonder whether we (in D-I) could add t-p-u to the list of proposed
> > repositories when users install testing. We already propose security
> > and volatile (defaulting
Hello,
On Wed, Aug 25, 2010 at 7:38 AM, Christian PERRIER wrote:
> I wonder whether we (in D-I) could add t-p-u to the list of proposed
> repositories when users install testing. We already propose security
> and volatile (defaulting to both added): the same mechanism could be
> made for t-p-u wh
* David Kalnischkies [2010-08-26 17:43 +0200]:
> Long story short:
> If you want to get updates from an archive only if you pushed a version
> previously from it: 100 => pin > 500.
Wouldn't adding a new field to Release files similar to 'Not-Automatic'
but pin to 101 instead of 1 if this new field
2010/8/26 Paul Wise :
> AFAIK to achieve that you need pinning priorities > 500 and < 1000.
A pin-value >= 100 is enough in this scenario.
> 500 would have maybe even the wrong effect, as repositories
which are not from the default-release - if set at all - get 500 per default
(expect if the Relea
On Wed, Aug 25, 2010 at 6:38 PM, Christian PERRIER wrote:
> Quoting Russ Allbery (r...@debian.org):
>
>> > Hmhm, out of curiosity, why is t-p-u “way riskier”.
>>
>> Mostly because there isn't any large pool of systems using t-p-u the way
>> there is for unstable, so the aging process where we get
Chris writes:
> I admit, I am still very new to this process.
> If I can, I would be glad to help out during the Freeze process
> if any kind soul would be willing to discuss this off list with me.
For the benefit of readers of debian-devel who don't read
debian-mentors:
I already replied to Ch
On Wed, 25 Aug 2010 02:09:03 +0100
Ben Hutchings wrote:
> Please stop filing ITPs and concentrate on packages that should be
> included in squeeze. The sooner squeeze is out, the sooner you can
> add stuff to the next release.
>
> Ben.
>
Greetings everyone,
I admit, I am still very new to th
Mike Hommey writes ("Re: For those who care about their packages in Debian"):
> On Wed, Aug 25, 2010 at 01:42:34PM +0100, Ian Jackson wrote:
> > Even better would be an option to write something in your .dsc which
> > would cause automatic transfer of your package into uns
On Wed, 25 Aug 2010 13:42:34 +0100, Ian Jackson
wrote:
>Perhaps the right answer is to simply ask people to upload
>non-release-related stuff to experimental rather than unstable. That
>way one can do the itch-scratching right away;
... if apt would finally support wildcards in preferences file'
On Wed, Aug 25, 2010 at 01:42:34PM +0100, Ian Jackson wrote:
> Russ Allbery writes ("Re: For those who care about their packages in Debian"):
> > Ben Hutchings writes:
> >
> > > Please stop filing ITPs and concentrate on packages that should be
> > >
Russ Allbery writes ("Re: For those who care about their packages in Debian"):
> Ben Hutchings writes:
>
> > Please stop filing ITPs and concentrate on packages that should be
> > included in squeeze. The sooner squeeze is out, the sooner you can add
> > st
On Wed, 2010-08-25 at 00:45 -0700, Russ Allbery wrote:
[...]
> That last bucket of time is simply not available to work on the squeeze
> release, period. If I weren't spending it on packaging new things for
> Debian, I would not be spending it on Debian *at all*. I don't think you
> actually woul
Quoting Russ Allbery (r...@debian.org):
> > Hmhm, out of curiosity, why is t-p-u “way riskier”.
>
> Mostly because there isn't any large pool of systems using t-p-u the way
> there is for unstable, so the aging process where we get testing in
> unstable before migrating the package never happens.
On 25/08/10 at 11:43 +0200, Yves-Alexis Perez wrote:
> On 25/08/2010 10:13, Russ Allbery wrote:
> > Yves-Alexis Perez writes:
> >> Hmhm, out of curiosity, why is t-p-u “way riskier”.
> >
> > Mostly because there isn't any large pool of systems using t-p-u the way
> > there is for unstable,
>
> Y
On 25/08/2010 10:13, Russ Allbery wrote:
> Yves-Alexis Perez writes:
>> Hmhm, out of curiosity, why is t-p-u “way riskier”.
>
> Mostly because there isn't any large pool of systems using t-p-u the way
> there is for unstable,
Yeah, good point.
>
>> Would it be possible (at one point) to “fix”
Yves-Alexis Perez writes:
> On 25/08/2010 10:02, Russ Allbery wrote:
>> Uploading new versions of leaf software isn't *as* big of a disaster,
>> but it does mean that updates to that software that should go into
>> testing can't go through the normal testing process and have to go
>> through test
On 25/08/2010 10:02, Russ Allbery wrote:
> Uploading new versions of leaf software isn't *as* big of a disaster, but
> it does mean that updates to that software that should go into testing
> can't go through the normal testing process and have to go through
> testing-proposed-updates, which is way
Ben Finney writes:
> But the solution would best entail allowing ‘unstable’ to continue to be
> used for the same purpose regardless of whether a freeze is currently
> active, no?
This, *in general*, doesn't work because of the way library transitions
work. If you upload a new upstream version
Russ Allbery writes:
> I, and I suspect many other people who are working on packaging new
> software for their own reasons, am quite aware of the release and are
> trying to stay out of the way.
+1
Though I'm not currently packaging any new software during this freeze,
I've worked with people
Ben Hutchings writes:
> Please stop filing ITPs and concentrate on packages that should be
> included in squeeze. The sooner squeeze is out, the sooner you can add
> stuff to the next release.
This comes up with every release, so I guess I'll reiterate what I end up
saying during every release.
Le mercredi 25 août 2010 à 02:09 +0100, Ben Hutchings a écrit :
> Please stop filing ITPs and concentrate on packages that should be
> included in squeeze. The sooner squeeze is out, the sooner you can add
> stuff to the next release.
I second that, and would also suggest to extend this to the ti
Ben Hutchings wrote:
Hi,
> Please stop filing ITPs and concentrate on packages that should be
> included in squeeze. The sooner squeeze is out, the sooner you can add
> stuff to the next release.
I'd add: stop uploading new upstream versions to unstable, or actually
any revision that isn't nee
24 matches
Mail list logo
