On Thu, 23 Dec 2010 01:31:18 +0100
Henrik Nordström wrote:
> tis 2010-12-21 klockan 09:50 -0700 skrev Kevin Fenzi:
>
> > Basically it's changing spec files BuildRequires to suit our build
> > setup and not for 'the version this package needs to build'.
>
> True. And it's use should be limited
tis 2010-12-21 klockan 09:50 -0700 skrev Kevin Fenzi:
> Basically it's changing spec files BuildRequires to suit our build
> setup and not for 'the version this package needs to build'.
True. And it's use should be limited to the release branches of a
package, not master/rawhide.
Imho it adds
tis 2010-12-21 klockan 13:02 -0500 skrev Matt McCutchen:
> updates-testing explicitly. Either variant of the approach has the
> danger though that because a build needs one thing from updates-testing,
> it will end up getting something else from updates-testing that the
> maintainer didn't expect
On 12/17/2010 07:34 PM, Matt McCutchen wrote:
> On Fri, 2010-12-17 at 18:32 +0100, Ralf Corsepius wrote:
>> * we are building packages against the known-to-be-broken package
>
> The old package is already in stable. We're not doing additional harm
> by building against it unless the "breakage" is
On Mon, 2010-12-20 at 16:01 -0500, Tom Callaway wrote:
> I think a simpler idea is a minimal webapp (and perhaps a CLI interface)
> that lets you login with your FAS account and request an override on a
> built package that you have permissions for (and at the same time,
> choose how long the overr
On Tue, 2010-12-21 at 16:45 +, Adam Williamson wrote:
> On Tue, 2010-12-21 at 11:24 -0500, Matt McCutchen wrote:
> > On Tue, 2010-12-21 at 16:15 +, Adam Williamson wrote:
> > > it would seem to make more sense, to me, to configure bodhi to re-try
> > > the build, with updates-testing repo e
On Mon, 20 Dec 2010 21:55:47 +0100
Henrik Nordström wrote:
> fre 2010-12-17 klockan 11:22 +0100 skrev Michael Schwendt:
>
> > +1 to some way of automating koji buildroot overrides (perhaps based
> > on FAS group membership such as provenpackagers) in order to remove
> > the releng bottleneck.
>
On Tue, 2010-12-21 at 11:24 -0500, Matt McCutchen wrote:
> On Tue, 2010-12-21 at 16:15 +, Adam Williamson wrote:
> > On Mon, 2010-12-20 at 22:57 +0100, Henrik Nordström wrote:
> >
> > > * implemented by "only" a change in yum dependency resolution to use
> > > fallback repositories (i.e. updat
On Tue, 2010-12-21 at 16:15 +, Adam Williamson wrote:
> On Mon, 2010-12-20 at 22:57 +0100, Henrik Nordström wrote:
>
> > * implemented by "only" a change in yum dependency resolution to use
> > fallback repositories (i.e. updates-testing).
>
> I don't think that would be a good change, as it'
On Mon, 2010-12-20 at 22:57 +0100, Henrik Nordström wrote:
> * implemented by "only" a change in yum dependency resolution to use
> fallback repositories (i.e. updates-testing).
I don't think that would be a good change, as it's changing the generic
functionality of a tool for one specific use ca
On Tue, 2010-12-21 at 01:29 +0100, Henrik Nordström wrote:
> mån 2010-12-20 klockan 18:12 -0500 skrev Matt McCutchen:
>
> > That will work, assuming the user has permission to do the tagging; it
> > is essentially a buildroot override in reverse. So the question is just
> > what we want to optimi
On Mon, 2010-12-20 at 21:55 +0100, Henrik Nordström wrote:
> Suggestion on how to express this in the packaging process:
> BuildRequires with a version requirement pulling in from updates-testing
> if the required version can not be satisfied from the stable repository.
I don't like this. I would
On Tue, 2010-12-21 at 00:52 +0100, Henrik Nordström wrote:
> mån 2010-12-20 klockan 16:15 -0500 skrev seth vidal:
>
> > So you want to give updates-testing preferential value over updates
> > despite their being no e-v-r difference between the pkgs? If so - you
> > can do that now with yum's cost
mån 2010-12-20 klockan 18:12 -0500 skrev Matt McCutchen:
> That will work, assuming the user has permission to do the tagging; it
> is essentially a buildroot override in reverse. So the question is just
> what we want to optimize for: more testing of packages while they are in
> testing, or less
mån 2010-12-20 klockan 14:42 -0800 skrev Jesse Keating:
> Perhaps you don't understand how the buildsystem works. The build
> system does not use our external "Updates" or "updates-testing"
> repositories. It doesn't use multiple repositories either. It uses an
> internal repository that is the
mån 2010-12-20 klockan 16:15 -0500 skrev seth vidal:
> So you want to give updates-testing preferential value over updates
> despite their being no e-v-r difference between the pkgs? If so - you
> can do that now with yum's cost value.
No. The stable repositories (updates / dist) always have prio
On Fri, 2010-12-17 at 18:38 -0500, Orcan Ogetbil wrote:
> On Fri, Dec 17, 2010 at 1:36 PM, Matt McCutchen wrote:
> > On Fri, 2010-12-17 at 13:20 -0500, Orcan Ogetbil wrote:
> >> On Thu, Dec 16, 2010 at 11:03 AM, Chris Adams wrote:
> >> > That makes the push process much more fragile/difficult. If
On 12/20/10 1:57 PM, Henrik Nordström wrote:
> mån 2010-12-20 klockan 16:01 -0500 skrev Tom Callaway:
>
>> I think a simpler idea is a minimal webapp (and perhaps a CLI interface)
>> that lets you login with your FAS account and request an override on a
>> built package that you have permissions f
mån 2010-12-20 klockan 16:01 -0500 skrev Tom Callaway:
> I think a simpler idea is a minimal webapp (and perhaps a CLI interface)
> that lets you login with your FAS account and request an override on a
> built package that you have permissions for (and at the same time,
> choose how long the over
On Mon, 2010-12-20 at 22:07 +0100, Henrik Nordström wrote:
> mån 2010-12-20 klockan 15:58 -0500 skrev seth vidal:
>
> > So you want contingency fall-through deps?
>
> > ie: BuildRequires: foo = 1.1.1 (but if that's not available foo =
> > 1.0.0)?
>
> No, not quite.
>
> pull in foo-1.1.1 from u
mån 2010-12-20 klockan 15:58 -0500 skrev seth vidal:
> So you want contingency fall-through deps?
> ie: BuildRequires: foo = 1.1.1 (but if that's not available foo =
> 1.0.0)?
No, not quite.
pull in foo-1.1.1 from updates-testing if the requirement can not be
satisfied from updates. Applied re
On Mon, 2010-12-20 at 22:01 +0100, Henrik Nordström wrote:
> fre 2010-12-17 klockan 11:08 -0700 skrev Kevin Fenzi:
>
> > For the second point, I'm not sure what the delay time people are
> > seeing is. Currently Rex is doing almost all of these overrides.
> > Perhaps we could get some more folks t
On Mon, 2010-12-20 at 15:58 -0500, seth vidal wrote:
> On Mon, 2010-12-20 at 21:55 +0100, Henrik Nordström wrote:
> > fre 2010-12-17 klockan 11:22 +0100 skrev Michael Schwendt:
> >
> > > +1 to some way of automating koji buildroot overrides (perhaps based
> > > on FAS group membership such as prov
fre 2010-12-17 klockan 11:08 -0700 skrev Kevin Fenzi:
> For the second point, I'm not sure what the delay time people are
> seeing is. Currently Rex is doing almost all of these overrides.
> Perhaps we could get some more folks to step up to process them? Or
> open them up to provenpackagers or so
On 12/20/2010 03:55 PM, Henrik Nordström wrote:
> Suggestion on how to express this in the packaging process:
> BuildRequires with a version requirement pulling in from updates-testing
> if the required version can not be satisfied from the stable repository.
I think a simpler idea is a minimal we
On Mon, 2010-12-20 at 21:55 +0100, Henrik Nordström wrote:
> fre 2010-12-17 klockan 11:22 +0100 skrev Michael Schwendt:
>
> > +1 to some way of automating koji buildroot overrides (perhaps based
> > on FAS group membership such as provenpackagers) in order to remove
> > the releng bottleneck.
>
>
fre 2010-12-17 klockan 11:22 +0100 skrev Michael Schwendt:
> +1 to some way of automating koji buildroot overrides (perhaps based
> on FAS group membership such as provenpackagers) in order to remove
> the releng bottleneck.
Suggestion on how to express this in the packaging process:
BuildRequire
On 12/19/10 10:10 AM, Kevin Fenzi wrote:
> On Sat, 18 Dec 2010 12:05:09 +0100
> Michael Schwendt wrote:
>
>> Nonsense. The current releng procedure is bureaucracy and a
>> bottle-neck. (How often does releng reject koji buildroot override
>> requests?)
>
> Not sure. I haven't been subscribed to
On Sat, 18 Dec 2010 12:05:09 +0100
Michael Schwendt wrote:
> Nonsense. The current releng procedure is bureaucracy and a
> bottle-neck. (How often does releng reject koji buildroot override
> requests?)
Not sure. I haven't been subscribed to the list too long...
> I'm in favour of permitting p
On Fri, 17 Dec 2010 18:32:15 +0100, Ralf wrote:
> > +1 to some way of automating koji buildroot overrides (perhaps based
> > on FAS group membership such as provenpackagers) in order to remove
> > the releng bottleneck.
>
> I am learning you are keen on more bureaucracy ;)
Nonsense. The current
> Emphasis on "stable". Koji buildroot production is not just about
s/production/protection/
--
The original reply is elsewhere in this thread. ;-)
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
On Fri, 17 Dec 2010 13:34:15 -0500, Matt wrote:
> On Fri, 2010-12-17 at 18:32 +0100, Ralf Corsepius wrote:
> > * we are building packages against the known-to-be-broken package
>
> The old package is already in stable. We're not doing additional harm
> by building against it unless the "breakage
On Fri, Dec 17, 2010 at 1:36 PM, Matt McCutchen wrote:
> On Fri, 2010-12-17 at 13:20 -0500, Orcan Ogetbil wrote:
>> On Thu, Dec 16, 2010 at 11:03 AM, Chris Adams wrote:
>> > That makes the push process much more fragile/difficult. If you use a
>> > updates-testing build of package A, and package
Matt McCutchen wrote:
> I think the best solution would be to use custom tags routinely and let
> all packagers create their own tags, assuming the infrastructure issues
> can be solved to make that practical.
Currently custom tags do have a non-trivial impact on the buildsystem, so
this is not
On Fri, 2010-12-17 at 13:20 -0500, Orcan Ogetbil wrote:
> On Thu, Dec 16, 2010 at 11:03 AM, Chris Adams wrote:
> > Once upon a time, Stanislav Ochotnicky said:
> >> Note that I am not saying things should go into buildroot as soon as
> >> they are built, but as soon as they are in updates-testing.
On Fri, 2010-12-17 at 13:20 -0500, Orcan Ogetbil wrote:
> On Thu, Dec 16, 2010 at 11:03 AM, Chris Adams wrote:
> > That makes the push process much more fragile/difficult. If you use a
> > updates-testing build of package A, and package B (that depends on
> > package A) gets rebuilt, then you may
On Fri, 2010-12-17 at 18:32 +0100, Ralf Corsepius wrote:
> * we are building packages against the known-to-be-broken package
The old package is already in stable. We're not doing additional harm
by building against it unless the "breakage" is a regression that
affects the building of dependent pa
On Fri, 2010-12-17 at 11:08 -0700, Kevin Fenzi wrote:
> Lets step back a bit here as I think this thread is drifting.
>
> What issue(s) is this proposed change trying to solve?
>
> * The OP talked about that we are not 'testing' the update entirely
> because it's not in the buildroot, so we a
On Thu, Dec 16, 2010 at 11:03 AM, Chris Adams wrote:
> Once upon a time, Stanislav Ochotnicky said:
>> Note that I am not saying things should go into buildroot as soon as
>> they are built, but as soon as they are in updates-testing. There is a
>> difference. There will still be reasons to use ta
Lets step back a bit here as I think this thread is drifting.
What issue(s) is this proposed change trying to solve?
* The OP talked about that we are not 'testing' the update entirely
because it's not in the buildroot, so we aren't confirming that it
works to build against.
* Other folks
On 12/17/2010 11:22 AM, Michael Schwendt wrote:
> On Thu, 16 Dec 2010 17:21:27 +0100, Ralf wrote:
>
>> On 12/16/2010 03:35 PM, Stanislav Ochotnicky wrote:
>>> Hi,
>>>
>>> I'd like to propose a small(ish) change to how updates to Fx and Fx-1 work.
>>>
>>> Currently we have to wait until package gets
On Thu, 16 Dec 2010 17:21:27 +0100, Ralf wrote:
> On 12/16/2010 03:35 PM, Stanislav Ochotnicky wrote:
> > Hi,
> >
> > I'd like to propose a small(ish) change to how updates to Fx and Fx-1 work.
> >
> > Currently we have to wait until package gets to stable for it to appear
> > in buildroot. IMO th
On 12/16/10 1:20 PM, Matt McCutchen wrote:
> On Thu, 2010-12-16 at 12:28 -0800, Jesse Keating wrote:
>> On 12/16/10 12:22 PM, Matt McCutchen wrote:
>>> An alternative approach would be to mirror the semantics of tag
>>> inheritance by having builds use multiple yum repositories, possibly
>>> with p
On Thu, 2010-12-16 at 12:28 -0800, Jesse Keating wrote:
> On 12/16/10 12:22 PM, Matt McCutchen wrote:
> > An alternative approach would be to mirror the semantics of tag
> > inheritance by having builds use multiple yum repositories, possibly
> > with priorities, instead of explicitly computing the
On 12/16/10 12:22 PM, Matt McCutchen wrote:
> On Thu, 2010-12-16 at 12:14 -0800, Jesse Keating wrote:
>> On 12/16/10 10:29 AM, Matt McCutchen wrote:
>>> (BTW, it seems that a custom tag would generally be better than a
>>> buildroot override for the reasons we are discussing even if there's
>>> onl
On Thu, 2010-12-16 at 12:14 -0800, Jesse Keating wrote:
> On 12/16/10 10:29 AM, Matt McCutchen wrote:
> > (BTW, it seems that a custom tag would generally be better than a
> > buildroot override for the reasons we are discussing even if there's
> > only one dependent package, unless that would put
On 12/16/10 10:29 AM, Matt McCutchen wrote:
> (BTW, it seems that a custom tag would generally be better than a
> buildroot override for the reasons we are discussing even if there's
> only one dependent package, unless that would put some kind of strain on
> the infrastructure. Is a request for a
On Thu, 2010-12-16 at 18:11 +0100, Ralf Corsepius wrote:
> On 12/16/2010 06:00 PM, Matt McCutchen wrote:
> > On Thu, 2010-12-16 at 17:49 +0100, Ralf Corsepius wrote:
> >> On 12/16/2010 05:28 PM, Kevin Fenzi wrote:
> >>> On Thu, 16 Dec 2010 10:03:30 -0600
> >>> Chris Adams wrote:
> >>>
> Once
On 12/16/2010 06:00 PM, Matt McCutchen wrote:
> On Thu, 2010-12-16 at 17:49 +0100, Ralf Corsepius wrote:
>> On 12/16/2010 05:28 PM, Kevin Fenzi wrote:
>>> On Thu, 16 Dec 2010 10:03:30 -0600
>>> Chris Adams wrote:
>>>
Once upon a time, Stanislav Ochotnicky said:
> Note that I am not say
On Thu, 2010-12-16 at 17:49 +0100, Ralf Corsepius wrote:
> On 12/16/2010 05:28 PM, Kevin Fenzi wrote:
> > On Thu, 16 Dec 2010 10:03:30 -0600
> > Chris Adams wrote:
> >
> >> Once upon a time, Stanislav Ochotnicky said:
> >>> Note that I am not saying things should go into buildroot as soon as
> >>
On Thu, 2010-12-16 at 09:28 -0700, Kevin Fenzi wrote:
> On Thu, 16 Dec 2010 10:03:30 -0600
> Chris Adams wrote:
>
> > Once upon a time, Stanislav Ochotnicky said:
> > > Note that I am not saying things should go into buildroot as soon as
> > > they are built, but as soon as they are in updates-t
On 12/16/2010 05:28 PM, Kevin Fenzi wrote:
> On Thu, 16 Dec 2010 10:03:30 -0600
> Chris Adams wrote:
>
>> Once upon a time, Stanislav Ochotnicky said:
>>> Note that I am not saying things should go into buildroot as soon as
>>> they are built, but as soon as they are in updates-testing. There
>>>
On Thu, 16 Dec 2010 10:03:30 -0600
Chris Adams wrote:
> Once upon a time, Stanislav Ochotnicky said:
> > Note that I am not saying things should go into buildroot as soon as
> > they are built, but as soon as they are in updates-testing. There
> > is a difference. There will still be reasons to
On 12/16/2010 03:35 PM, Stanislav Ochotnicky wrote:
> Hi,
>
> I'd like to propose a small(ish) change to how updates to Fx and Fx-1 work.
>
> Currently we have to wait until package gets to stable for it to appear
> in buildroot. IMO this goes against the whole "testing" part of
> updates-testing.
Once upon a time, Stanislav Ochotnicky said:
> Note that I am not saying things should go into buildroot as soon as
> they are built, but as soon as they are in updates-testing. There is a
> difference. There will still be reasons to use tags/overrides.
That makes the push process much more fragi
On 12/16/2010 04:42 PM, Adam Williamson wrote:
> On Thu, 2010-12-16 at 09:26 -0600, Rex Dieter wrote:
>
>>> Any opinions on this?
>>
>> While I see some value in this, poisoning the buildroot is a grave danger
>> here. I'd be hesitant to endorse it.
>>
>> Is this proposal based on any real exampl
On Thu, 2010-12-16 at 09:26 -0600, Rex Dieter wrote:
> > Any opinions on this?
>
> While I see some value in this, poisoning the buildroot is a grave danger
> here. I'd be hesitant to endorse it.
>
> Is this proposal based on any real examples of updates-testing pkgs breaking
> builds? Perhap
Stanislav Ochotnicky wrote:
> I'd like to propose a small(ish) change to how updates to Fx and Fx-1
> work.
>
> Currently we have to wait until package gets to stable for it to appear
> in buildroot. IMO this goes against the whole "testing" part of
> updates-testing. I'd like for packages to app
Hi,
I'd like to propose a small(ish) change to how updates to Fx and Fx-1 work.
Currently we have to wait until package gets to stable for it to appear
in buildroot. IMO this goes against the whole "testing" part of
updates-testing. I'd like for packages to appear in buildroot as soon as
they are
59 matches
Mail list logo
