What's wrong with all that broken deps? Is this just a missing rebuild
against opencv and other libs or what's the reason for all this "mess". I
mean the release of F16 is not that far away and the amount of broken deps
is quite big imho.
I would be glad helping out if this is due to some orphaned
On 09/20/2011 12:53 PM, Johannes Lips wrote:
> What's wrong with all that broken deps? Is this just a missing rebuild
> against opencv and other libs or what's the reason for all this "mess".
> I mean the release of F16 is not that far away and the amount of broken
> deps is quite big imho.
> I wou
On 09/20/2011 01:12 PM, Branched Report wrote:
> Compose started at Tue Sep 20 08:15:41 UTC 2011
>
> Broken deps for x86_64
> --
This breakage is weird:
> hosts3d-1.13-2.fc15.x86_64 requires libglfw.so.2.6()(64bit)
In Fedora < 16, lib
On 09/22/2011 12:05 PM, Ralf Corsepius wrote:
> On 09/20/2011 01:12 PM, Branched Report wrote:
>> Compose started at Tue Sep 20 08:15:41 UTC 2011
>>
>> Broken deps for x86_64
>> --
>
> This breakage is weird:
>
>> hosts3d-1.13-2.fc15.x8
On 09/22/2011 11:31 AM, Kalev Lember wrote:
> On 09/22/2011 12:05 PM, Ralf Corsepius wrote:
>> On 09/20/2011 01:12 PM, Branched Report wrote:
>>> Compose started at Tue Sep 20 08:15:41 UTC 2011
>>>
>>> Broken deps for x86_64
>>> --
>>
>> This
On 09/22/2011 11:31 AM, Kalev Lember wrote:
> On 09/22/2011 12:05 PM, Ralf Corsepius wrote:
>> On 09/20/2011 01:12 PM, Branched Report wrote:
>>> Compose started at Tue Sep 20 08:15:41 UTC 2011
>>>
>>> Broken deps for x86_64
>>> --
>>
>> This
On 09/22/2011 12:52 PM, Ralf Corsepius wrote:
> On 09/22/2011 11:31 AM, Kalev Lember wrote:
>> Depends on how you want to resolve this. If you are going for
>> resurrecting the packages, then fix them up to build again and submit
>> new package review requests.
>
> I have a version of libglfw whic
On 09/22/2011 01:11 PM, Kalev Lember wrote:
> On 09/22/2011 12:52 PM, Ralf Corsepius wrote:
>> On 09/22/2011 11:31 AM, Kalev Lember wrote:
>>> Depends on how you want to resolve this. If you are going for
>>> resurrecting the packages, then fix them up to build again and submit
>>> new package revi
On Tue, 2011-09-20 at 13:53 +0200, Johannes Lips wrote:
> What's wrong with all that broken deps? Is this just a missing rebuild
> against opencv and other libs or what's the reason for all this
> "mess". I mean the release of F16 is not that far away and the amount
> of broken deps is quite big im
On 09/20/2011 03:01 PM, Nils Philippsen wrote:
> On Tue, 2011-09-20 at 13:53 +0200, Johannes Lips wrote:
>> What's wrong with all that broken deps? Is this just a missing rebuild
>> against opencv and other libs or what's the reason for all this
>> "mess". I mean the release of F16 is not that far
On Tue, Sep 20, 2011 at 03:19:17PM +0200, Ralf Corsepius wrote:
> When you have a closer look, you'll notice that such "mass rebuilts"
> were being delayed by QA's "delay queue" and now are stuck.
Yeah. I rebuilt maatkit on the 1st of September and it still hasn't made
it to the -stable reposito
On Tue, Sep 20, 2011 at 15:01:06 +0200,
Nils Philippsen wrote:
>
> I'd like to see a discussion about how we can ensure -- within
> reasonable limits -- that e.g. bumping a library's SONAME is followed by
> dependent components being rebuilt and included with the providing
> component in one up
On 9/20/11 9:19 AM, Ralf Corsepius wrote:
>> Currently
>> I only see mails of maintainers who plan updating the library, but the
>> rest of it pretty much depends on the maintainers of the depending
>> components rebuilding them quickly enough, and the original maintainer
>> to include them in the
2011/9/20 Nils Philippsen :
> On Tue, 2011-09-20 at 13:53 +0200, Johannes Lips wrote:
>> What's wrong with all that broken deps? Is this just a missing rebuild
>> against opencv and other libs or what's the reason for all this
>> "mess". I mean the release of F16 is not that far away and the amount
On 09/20/2011 03:47 PM, Bruno Wolff III wrote:
> On Tue, Sep 20, 2011 at 15:01:06 +0200,
>Nils Philippsen wrote:
>>
>> I'd like to see a discussion about how we can ensure -- within
>> reasonable limits -- that e.g. bumping a library's SONAME is followed by
>> dependent components being rebuil
On 09/20/2011 04:03 PM, Adam Jackson wrote:
> On 9/20/11 9:19 AM, Ralf Corsepius wrote:
>
>>> Currently
>>> I only see mails of maintainers who plan updating the library, but the
>>> rest of it pretty much depends on the maintainers of the depending
>>> components rebuilding them quickly enough, an
On Tue, Sep 20, 2011 at 04:13:27PM +0200, Ralf Corsepius wrote:
> On 09/20/2011 04:03 PM, Adam Jackson wrote:
> > I'd like to see a rationale for jamming a soname-changing update into
> > the OS so close to a release.
> Maintainers on vacation, non-trivial changes?
>
> In my case, a major change w
On Tue, 2011-09-20 at 10:03 -0400, Adam Jackson wrote:
> I'd like to see a rationale for jamming a soname-changing update into
> the OS so close to a release. In the absence of a very good motivation,
> that's not good engineering practice, and it's not consistent with the
> feature process.
>
On 9/20/11 10:13 AM, Ralf Corsepius wrote:
> On 09/20/2011 04:03 PM, Adam Jackson wrote:
>> I'd like to see a rationale for jamming a soname-changing update into
>> the OS so close to a release.
> Maintainers on vacation, non-trivial changes?
>
> In my case, a major change was introduced into rawhi
On 09/20/2011 04:16 PM, Matthew Garrett wrote:
> On Tue, Sep 20, 2011 at 04:13:27PM +0200, Ralf Corsepius wrote:
>> On 09/20/2011 04:03 PM, Adam Jackson wrote:
>>> I'd like to see a rationale for jamming a soname-changing update into
>>> the OS so close to a release.
>> Maintainers on vacation, non
On Tue, Sep 20, 2011 at 10:21:52AM -0400, Matthias Clasen wrote:
> We've set our freezes as if we expect all major development to be done
> at that point, but we've aligned our schedules in a way that guarantees
> that (at least for GNOME) major development is still happening at the
> time of bran
On Tue, Sep 20, 2011 at 04:35:16PM +0200, Ralf Corsepius wrote:
> That said, a reasonable QA would cherry-pick such "solution
> candidates" from *-testing and integrate them. Simply flooding
> maintainers "with complaint mails" about broken deps, maintainers
> believe to already have fixed doesn't
On 09/20/2011 04:37 PM, Matthew Garrett wrote:
> On Tue, Sep 20, 2011 at 04:35:16PM +0200, Ralf Corsepius wrote:
>
>> That said, a reasonable QA would cherry-pick such "solution
>> candidates" from *-testing and integrate them. Simply flooding
>> maintainers "with complaint mails" about broken deps
On Tue, Sep 20, 2011 at 04:52:28PM +0200, Ralf Corsepius wrote:
> On 09/20/2011 04:37 PM, Matthew Garrett wrote:
> >What the maintainers could have done is not upload a package that breaks
> >binary compatibility into a distribution that's attempting to stabalise
> >for release.
>
> That's a way t
On Tue, Sep 20, 2011 at 4:57 PM, Matthew Garrett wrote:
> On Tue, Sep 20, 2011 at 04:52:28PM +0200, Ralf Corsepius wrote:
>> On 09/20/2011 04:37 PM, Matthew Garrett wrote:
>> >What the maintainers could have done is not upload a package that breaks
>> >binary compatibility into a distribution that
On Tue, 2011-09-20 at 16:06 +0200, Nicolas Chauvet wrote:
> 2011/9/20 Nils Philippsen :
> > On Tue, 2011-09-20 at 13:53 +0200, Johannes Lips wrote:
> >> What's wrong with all that broken deps? Is this just a missing rebuild
> >> against opencv and other libs or what's the reason for all this
> >> "
2011/9/20 Miloslav Trmač :
> On Tue, Sep 20, 2011 at 4:57 PM, Matthew Garrett wrote:
>> On Tue, Sep 20, 2011 at 04:52:28PM +0200, Ralf Corsepius wrote:
>>> On 09/20/2011 04:37 PM, Matthew Garrett wrote:
>>> >What the maintainers could have done is not upload a package that breaks
>>> >binary compa
- Original Message -
> I'd like to see a rationale for jamming a soname-changing update into
> the OS so close to a release. In the absence of a very good
> motivation,
> that's not good engineering practice, and it's not consistent with
> the
> feature process.
>
> Perhaps you're not cle
On 9/20/11 11:10 AM, Miloslav Trmač wrote:
> * It's not 14 days + 3 (4?) weeks before beta freeze - even if the
> library gets out of updates-testing in time, its users may not be
> rebuilt because the maintainer is on vacation.
You could have an earthquake, too.
If you're having problems rebuil
On Tue, 2011-09-20 at 16:07 +0200, Ralf Corsepius wrote:
> On 09/20/2011 03:47 PM, Bruno Wolff III wrote:
> > On Tue, Sep 20, 2011 at 15:01:06 +0200,
> >Nils Philippsen wrote:
> >>
> >> I'd like to see a discussion about how we can ensure -- within
> >> reasonable limits -- that e.g. bumping a
On Tue, 2011-09-20 at 11:33 -0400, Adam Jackson wrote:
> Of course, the accounts system _still_ doesn't have groups, five years
> later, so provenpackager is the big hammer we have. We could get groups
> any day now, that'd be just fine.
Do you mean "groups of groups", like in "provenpackager-k
- Original Message -
> So when _is_ a good time to do binary-incompatible changes to
> libraries?
>
> * It's not after beta freeze, because they are unwanted at that time
>
> * It's not 14 days before beta freeze, because they won't get out of
> updates-testing in time
>
> * It's not 14
On Tue, 2011-09-20 at 15:19 +0200, Ralf Corsepius wrote:
> On 09/20/2011 03:01 PM, Nils Philippsen wrote:
> > On Tue, 2011-09-20 at 13:53 +0200, Johannes Lips wrote:
> >> What's wrong with all that broken deps? Is this just a missing rebuild
> >> against opencv and other libs or what's the reason f
On Tue, 2011-09-20 at 11:45 -0400, Doug Ledford wrote:
> - Original Message -
> > So when _is_ a good time to do binary-incompatible changes to
> > libraries?
> >
> > * It's not after beta freeze, because they are unwanted at that time
> >
> > * It's not 14 days before beta freeze, becaus
On 9/20/11 11:43 AM, Nils Philippsen wrote:
> On Tue, 2011-09-20 at 11:33 -0400, Adam Jackson wrote:
>> Of course, the accounts system _still_ doesn't have groups, five years
>> later, so provenpackager is the big hammer we have. We could get groups
>> any day now, that'd be just fine.
>
> Do you
- Original Message -
> I'd like to mention that an upstream source getting bumped doesn't
> mean
> anything per se, so we should rather have criteria agnostic of
> arbitrary
> parameters like this. For instance, it shouldn't make a shred of
> difference whether I apply a patch in the spec f
Le mardi 20 septembre 2011 à 17:10 +0200, Miloslav Trmač a écrit :
> So when _is_ a good time to do binary-incompatible changes to libraries?
The answer is obvious - in rawhide, before branching point. Anything
after branching will interact with various groups schedules and crash
into the barrier
>> * What if there are two layers of users that need to be rebuilt?
>>
>> The delays just pile one upon another...
>
> You can update rawhide at any time and accomplish that work without
> delays. Then it shows up in the next Fedora version.
>
Yes, but then we have align the schedules, so have a
Am Dienstag, den 20.09.2011, 15:39 +0200 schrieb Sven Lankes:
> Didn't we have the time an update had to stay in -testing changed to
> three days during the F15 stabilization phase? Could we implement this
> again for F16 to mitigate the issue?
I think we should. Please file a bug against bodhi b
Am Dienstag, den 20.09.2011, 16:06 +0200 schrieb Nicolas Chauvet:
> I'm the maintainer of opencv here.
>
> quick answear: I have no right to submit a bodhi update for packages I
> do not own. Given that I'm no in the provenpackager group.
> So as I cannot expect every single maintainers to respond
On 09/20/2011 08:19 PM, Nicolas Mailhot wrote:
> Le mardi 20 septembre 2011 à 17:10 +0200, Miloslav Trmač a écrit :
>
>> So when _is_ a good time to do binary-incompatible changes to libraries?
>
> The answer is obvious - in rawhide, before branching point. Anything
> after branching will interact
On Sep 20, 2011, at 8:45 AM, Doug Ledford wrote:
>
> Instead, I think we ought to revamp the process like this:
>
> Maintainer A builds new package B
> Maintainer A files a bodhi ticket for package B
> In that ticket, the maintainer is responsible for list each item of change
> from the previous
On Sep 20, 2011, at 11:11 AM, Panu Matilainen wrote:
>
> My personal pet-peeve with the current branching policy is that the
> mass-branching happens way way too early for packages where there are no
> significant new development to be introduced in rawhide during branched
> state. So for every
On 09/20/2011 09:18 PM, Jesse Keating wrote:
> On Sep 20, 2011, at 11:11 AM, Panu Matilainen wrote:
>>
>> My personal pet-peeve with the current branching policy is that the
>> mass-branching happens way way too early for packages where there are no
>> significant new development to be introduced i
- Original Message -
> This is essentially what we had a while ago, only with trac tickets
> instead of bodhi requests.
Bodhi is definitely a better place to track this stuff, regardless of how
decisions are made.
> There were a couple of problems with
> this.
>
> 1) Nowhere near enoug
2011/9/20 Christoph Wickert :
> Am Dienstag, den 20.09.2011, 16:06 +0200 schrieb Nicolas Chauvet:
>> I'm the maintainer of opencv here.
>>
>> quick answear: I have no right to submit a bodhi update for packages I
>> do not own. Given that I'm no in the provenpackager group.
>> So as I cannot expect
On 09/20/2011 05:52 PM, Nils Philippsen wrote:
> On Tue, 2011-09-20 at 15:19 +0200, Ralf Corsepius wrote:
>> When you have a closer look, you'll notice that such "mass rebuilts"
>> were being delayed by QA's "delay queue" and now are stuck.
>
> I didn't want to (re)start that particular discussion
On 09/20/2011 05:30 PM, Doug Ledford wrote:
> - Original Message -
>> I'd like to see a rationale for jamming a soname-changing update into
>> the OS so close to a release. In the absence of a very good
>> motivation,
>> that's not good engineering practice, and it's not consistent with
>>
On 09/20/2011 04:33 PM, Adam Jackson wrote:
> Of course, you had the option of not pulling the new OpenSceneGraph back
> to F16, or simply not doing so yet.
Correct. I could have opted to ship the "distro which embraces novelty"
with outdated, upstream unmaintained and upstream dead packages, no
On Tue, 20 Sep 2011 15:19:29 -0400 (EDT)
Doug Ledford wrote:
...snip...
>
> > 2) 9 times out of 10 there was very little data put into the ticket.
>
> Multiple options here. Kick back incomplete tickets, or the better
> option IMNSHO, run rpmdiff runs between the package currently in the
> co
On Sep 20, 2011, at 12:19 PM, Doug Ledford wrote:
> - Original Message -
>> This is essentially what we had a while ago, only with trac tickets
>> instead of bodhi requests.
>
> Bodhi is definitely a better place to track this stuff, regardless of how
> decisions are made.
>
>> There wer
On Sep 20, 2011, at 1:35 PM, Ralf Corsepius wrote:
> On 09/20/2011 05:30 PM, Doug Ledford wrote:
>> - Original Message -
>>> I'd like to see a rationale for jamming a soname-changing update into
>>> the OS so close to a release. In the absence of a very good
>>> motivation,
>>> that's not
On Tue, Sep 20, 2011 at 11:18:18 -0700,
Jesse Keating wrote:
> One change to make this better might be to move the inheritance point to
> updates-testing so that things built from the fresh branch are immediately
> inherited into rawhide.
I think this would be a change for the better. I've no
Am Dienstag, den 20.09.2011, 22:25 +0200 schrieb Ralf Corsepius:
> In a nutshell: Fedora's QA process is cause of many of these "broken
> deps" complaints.
Please make a proposal to improve the situation and submit it to FESCo.
TIA,
Christoph
--
devel mailing list
devel@lists.fedoraproject.o
2011/9/20 Jesse Keating :
...
>>> thus we have bodhi
>>> and updates-testing as a gateway to get into the release.
>>
>> It's a gateway, I just don't think it serves as useful a purpose as it was
>> intended to.
>
>
> The question though really is whether or not it is more useful than a few
> (li
On Sep 20, 2011, at 3:56 PM, Nicolas Chauvet wrote:
>
> I think the situation improved with bodhi buildroot overrides over trac
> tickets.
> But I've hit several issues with the opencv case:
You make some valid points, however I was more concerned with the freeze break
requests in trac, not nec
On Tue, 2011-09-20 at 12:21 -0400, Adam Jackson wrote:
> On 9/20/11 11:43 AM, Nils Philippsen wrote:
> > On Tue, 2011-09-20 at 11:33 -0400, Adam Jackson wrote:
> >> Of course, the accounts system _still_ doesn't have groups, five years
> >> later, so provenpackager is the big hammer we have. We co
On Tue, 2011-09-20 at 22:25 +0200, Ralf Corsepius wrote:
> On 09/20/2011 05:52 PM, Nils Philippsen wrote:
> > On Tue, 2011-09-20 at 15:19 +0200, Ralf Corsepius wrote:
>
> >> When you have a closer look, you'll notice that such "mass rebuilts"
> >> were being delayed by QA's "delay queue" and now a
On 09/21/2011 01:25 PM, Nils Philippsen wrote:
> On Tue, 2011-09-20 at 22:25 +0200, Ralf Corsepius wrote:
>> On 09/20/2011 05:52 PM, Nils Philippsen wrote:
>>> On Tue, 2011-09-20 at 15:19 +0200, Ralf Corsepius wrote:
>>
When you have a closer look, you'll notice that such "mass rebuilts"
On Wed, 2011-09-21 at 15:51 +0200, Ralf Corsepius wrote:
> On 09/21/2011 01:25 PM, Nils Philippsen wrote:
> > On Tue, 2011-09-20 at 22:25 +0200, Ralf Corsepius wrote:
> >> On 09/20/2011 05:52 PM, Nils Philippsen wrote:
> >>> On Tue, 2011-09-20 at 15:19 +0200, Ralf Corsepius wrote:
> >>
> When
On Wed, Sep 21, 2011 at 04:43:38PM +0200, Nils Philippsen wrote:
> And that's always fine and dandy if these issues are resolved in a
> reasonable amount of time. Right now Rawhide has packages with
> dependencies broken since pre-F15. This isn't acceptable.
If you notice this, ask FESCo to ask F
On 09/21/2011 04:43 PM, Nils Philippsen wrote:
> On Wed, 2011-09-21 at 15:51 +0200, Ralf Corsepius wrote:
>> On 09/21/2011 01:25 PM, Nils Philippsen wrote:
>>> On Tue, 2011-09-20 at 22:25 +0200, Ralf Corsepius wrote:
On 09/20/2011 05:52 PM, Nils Philippsen wrote:
> On Tue, 2011-09-20 at 15
On 09/21/2011 05:33 PM, Till Maas wrote:
> On Wed, Sep 21, 2011 at 04:43:38PM +0200, Nils Philippsen wrote:
>
>> And that's always fine and dandy if these issues are resolved in a
>> reasonable amount of time. Right now Rawhide has packages with
>> dependencies broken since pre-F15. This isn't acce
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 22/09/11 09:15, Marcela Mašláňová wrote:
> On 09/21/2011 05:33 PM, Till Maas wrote:
>> On Wed, Sep 21, 2011 at 04:43:38PM +0200, Nils Philippsen wrote:
>>
>>> And that's always fine and dandy if these issues are resolved
>>> in a reasonable amount
On Thu, Sep 22, 2011 at 09:15:38AM +0200, Marcela Mašláňová wrote:
> I hope you don't suggest for every rebuild of few dependent packages one
> FESCo ticket.
This is what is currently required to ask FES for help. It is certainly
a lot better and more efficient to open one FESCo and one FES tick
On 09/22/2011 05:58 PM, Till Maas wrote:
> On Thu, Sep 22, 2011 at 09:15:38AM +0200, Marcela Mašláňová wrote:
>
>> I hope you don't suggest for every rebuild of few dependent packages one
>> FESCo ticket.
>
> This is what is currently required to ask FES for help. It is certainly
> a lot better and
- Original Message -
> On Tue, 20 Sep 2011 15:19:29 -0400 (EDT)
> Doug Ledford wrote:
>
> ...snip...
>
>
> Which rpmdiff are we talking about here?
> The free/included in fedora one is not that great... it gives you
> files
> and deps that changed, but that doesn't help you see what cha
> I think that's largely because we don't have a community of
> engineers. We have a community of /packagers/ who are able to cause
> packages to be built, and are able to do some measure of QA to see
> if those builds work, but do not have the skill set to look at a
> code diff and give a honest
On Sep 22, 2011, at 11:27 AM, Doug Ledford wrote:
> - Original Message -
>> On Tue, 20 Sep 2011 15:19:29 -0400 (EDT)
>> Doug Ledford wrote:
>>
>> ...snip...
>>
>>
>> Which rpmdiff are we talking about here?
>> The free/included in fedora one is not that great... it gives you
>> files
>>
- Original Message -
> The setup inside Red Hat cannot be (directly) copied outside at this
> time. Instead the autoQA project was started to re-create it as an
> open source project. That's where effort should continue.
Am I right in saying that AutoQA is basically mired in the muck and
On Fri, Sep 23, 2011 at 14:31, Doug Ledford wrote:
> - Original Message -
>> The setup inside Red Hat cannot be (directly) copied outside at this
>> time. Instead the autoQA project was started to re-create it as an
>> open source project. That's where effort should continue.
>
> Am I ri
> Am I right in saying that AutoQA is basically mired in the muck and
> going nowhere at the moment?
>
> --
> Doug Ledford
Our progress is very slow at the moment, correct. We will happily welcome some
help. We don't have many tasks that you could do in a free afternoon, however.
A free week o
- Original Message -
> Doug,
>
> = If Autoqa is currently slow it is mainly because what developers
> who
> are working on it are also tasked with doing other things.
I made no reference or allusion to it being slow because people were slacking.
I myself have more to do than I have time
On Fri, 2011-09-23 at 16:31 -0400, Doug Ledford wrote:
> - Original Message -
> > The setup inside Red Hat cannot be (directly) copied outside at this
> > time. Instead the autoQA project was started to re-create it as an
> > open source project. That's where effort should continue.
>
>
On Tue, 2011-10-04 at 09:07 -0700, Adam Williamson wrote:
> On Fri, 2011-09-23 at 16:31 -0400, Doug Ledford wrote:
> > - Original Message -
> > > The setup inside Red Hat cannot be (directly) copied outside at this
> > > time. Instead the autoQA project was started to re-create it as an
>
75 matches
Mail list logo
