Re: Fedora 25 Koji buildroots broken…

[Jan Pokorný]

On 30/01/17 14:44 +0100, Jan Pokorný wrote:
> On 30/01/17 00:53 +0100, Kevin Kofler wrote:
>> This is the result of 4 very poor decisions, by different people/groups:
>> 
>> 1. the decision to enable libglvnd in an update to a stable release. IMHO,
>>such a change is totally unsuitable for a stable release update and
>>should have been done in Rawhide only.
> 
> Big +1 as you can see in my posts:
> https://bodhi.fedoraproject.org/updates/libglvnd-0.2.999-7.gitdc16f8c.fc25#comment-552926
> https://bugzilla.redhat.com/show_bug.cgi?id=1413579#c14
> and on.
> 
> TL;DR:
> Another Fedora package (sway and possibly more) gets broken in return.

No longer the case for sway, thanks to Hans' fix of wlc, merged upstream:
https://github.com/Cloudef/wlc/pull/233
and coming to Fedora along the same update.

-- 
Jan (Poki)


pgpUrmoxXzOZp.pgp
Description: PGP signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Fedora 25 Koji buildroots broken…

[Igor Gnatenko]

On Tue, 2017-01-31 at 09:42 +0100, Hans de Goede wrote:
> Hi,
> 
> On 30-01-17 20:41, Rex Dieter wrote:
> > Kevin Kofler wrote:
> > 
> > > That is not true. Mesa is composed of multiple subpackages. The
> > > updater I
> > > used (plasma-pk-updates) happily updated mesa-dri-drivers to the
> > > new build
> > > and kept the old builds of mesa-libGL and mesa-libGLES that
> > > provide the
> > > libGL libraries. Though to be fair that does not seem to have
> > > actually
> > > broken anything.
> > 
> > This issue could be fixed in mesa packaging (that would enforce
> > that all
> > subpkg components be updated together).  I can help implement that,
> > if there
> > is a consensus that would be a "good thing(tm)"
> 
> Igor Gnatenko co-maintains mesa now a days, I'm pretty sure he will
> happily accept a patch tightening up the inter-pkg dependencies.
> 
> Igor, can you confirm (or deny) this please ?
Sure, just send a patch and if it looks good -- I will happily apply
it! :)
> 
> Regards,
> 
> Hans
-- 
-Igor Gnatenko

signature.asc
Description: This is a digitally signed message part
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Fedora 25 Koji buildroots broken…

[Hans de Goede]

Hi,

On 30-01-17 20:41, Rex Dieter wrote:

Kevin Kofler wrote:


That is not true. Mesa is composed of multiple subpackages. The updater I
used (plasma-pk-updates) happily updated mesa-dri-drivers to the new build
and kept the old builds of mesa-libGL and mesa-libGLES that provide the
libGL libraries. Though to be fair that does not seem to have actually
broken anything.


This issue could be fixed in mesa packaging (that would enforce that all
subpkg components be updated together).  I can help implement that, if there
is a consensus that would be a "good thing(tm)"


Igor Gnatenko co-maintains mesa now a days, I'm pretty sure he will
happily accept a patch tightening up the inter-pkg dependencies.

Igor, can you confirm (or deny) this please ?

Regards,

Hans
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Fedora 25 Koji buildroots broken…

[Rex Dieter]

Kevin Kofler wrote:

> That is not true. Mesa is composed of multiple subpackages. The updater I
> used (plasma-pk-updates) happily updated mesa-dri-drivers to the new build
> and kept the old builds of mesa-libGL and mesa-libGLES that provide the
> libGL libraries. Though to be fair that does not seem to have actually
> broken anything.

This issue could be fixed in mesa packaging (that would enforce that all 
subpkg components be updated together).  I can help implement that, if there 
is a consensus that would be a "good thing(tm)"

-- rex
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Fedora 25 Koji buildroots broken…

[Kevin Kofler]

Kevin Fenzi wrote:
> I disagree again. Right now, mesa in stable updates has a broken dep.
> dnf and gnome-software will not update it because of that. So, right
> now, no stable updates users are broken, they just see an unsightly
> broken dep on trying to update.

That is not true. Mesa is composed of multiple subpackages. The updater I 
used (plasma-pk-updates) happily updated mesa-dri-drivers to the new build 
and kept the old builds of mesa-libGL and mesa-libGLES that provide the 
libGL libraries. Though to be fair that does not seem to have actually 
broken anything.

It does create a problem for the people using my patched builds from the 
QtWebEngine Copr (with the Nouveau locking patches that were rejected 
upstream and in Fedora, which make QtWebEngine usable with Nouveau), because 
mesa-dri-drivers gets replaced by the newer version from stock F25 updates 
and I cannot build my patched version due to no libglvnd-devel available.

Kevin Kofler
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Fedora 25 Koji buildroots broken…

[Jan Pokorný]

On 30/01/17 00:53 +0100, Kevin Kofler wrote:
> This is the result of 4 very poor decisions, by different people/groups:
> 
> 1. the decision to enable libglvnd in an update to a stable release. IMHO,
>such a change is totally unsuitable for a stable release update and
>should have been done in Rawhide only.

Big +1 as you can see in my posts:
https://bodhi.fedoraproject.org/updates/libglvnd-0.2.999-7.gitdc16f8c.fc25#comment-552926
https://bugzilla.redhat.com/show_bug.cgi?id=1413579#c14
and on.

TL;DR:
Another Fedora package (sway and possibly more) gets broken in return.

-- 
Jan (Poki)


pgpCemr1c0_HP.pgp
Description: PGP signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Fedora 25 Koji buildroots broken…

[Kevin Fenzi]

On Mon, 30 Jan 2017 00:53:05 +0100
Kevin Kofler  wrote:

> Hans de Goede wrote:
> > Well, that is a fix, but the real problem is that either the new
> > libglvnd enabled mesa should not be in updates-stable and thus not
> > in the buildroot; or both the new libglvnd enabled mesa and the new
> > libglvnd should be in updates-stable.  
> 
> This is the result of 4 very poor decisions, by different
> people/groups:
> 
> 1. the decision to enable libglvnd in an update to a stable release.
> IMHO, such a change is totally unsuitable for a stable release update
> and should have been done in Rawhide only.

Perhaps so. I agree it definitely shouldn't have been pushed without
fixing all the packages that are broken by the update. 
> 
> 2. the decision to block Bodhi pushes on ostree failures. Without
> that, Bodhi would not have been stuck for days with all updates
> locked and this fiasco might possibly have been avoided. If the
> ostree compose fails, the Bodhi push should just proceed with an
> empty or old ostree directory (whatever is easier to implement).
> Rarely used experimental delivery methods should not hold the entire
> distribution hostage.

I disagree with you here. I think ostree is important and people are
using it. However, there's two (IMHO better) ways forward here. 
First we could (and should) just back out
rpm-ostree/ostree/bublewrap/whatever updates breaks composing and debug
it on the side. Second, the atomic sig is looking at changing how the
updates stream is made and only push it every 2 weeks. That would
remove it from being done by bodhi. 

> 3. the decision to use autokarma. This is just yet another broken
> update that went stable due to autokarma. Autokarma is an absolutely
>unacceptable practice and should not be allowed. All push requests
> should be issued by a human after reviewing the status.

I disagree. If autokarma wasn't used then the update could well have
been pushed again after the maintainer saw that it was able to be
pushed. Also, it would result it a bunch of updates stalling in
updates-testing as maintainers forget to push things stable. Also, it
would result in maintainers spending a bunch more time looking at
things and seeing... that they are all ready to go to stable.
 
> 4. the decision to disallow direct stable pushes. The right way to
> fix the issue quickly, limiting the damage once done, would have been
> to push libglvnd directly to stable. But Bodhi won't allow that.
> Direct stable pushes are an essential mechanism to fix regressions
> and to limit the number of affected users by minimizing the exposure
> time to the regression.

I disagree again. Right now, mesa in stable updates has a broken dep.
dnf and gnome-software will not update it because of that. So, right
now, no stable updates users are broken, they just see an unsightly
broken dep on trying to update. 

If we push libglvnd to stable right now, everyone will be able to
update mesa and it, and all users of sway will get a black screen and
be broken. So, we should _not_ push libglvnd until sway is fixed. 

kevin




pgpoxAxvbHHtk.pgp
Description: OpenPGP digital signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Fedora 25 Koji buildroots broken…

[Kevin Kofler]

Hans de Goede wrote:
> Well, that is a fix, but the real problem is that either the new libglvnd
> enabled mesa should not be in updates-stable and thus not in the
> buildroot; or both the new libglvnd enabled mesa and the new libglvnd
> should be in updates-stable.

This is the result of 4 very poor decisions, by different people/groups:

1. the decision to enable libglvnd in an update to a stable release. IMHO,
   such a change is totally unsuitable for a stable release update and
   should have been done in Rawhide only.

2. the decision to block Bodhi pushes on ostree failures. Without that,
   Bodhi would not have been stuck for days with all updates locked and this
   fiasco might possibly have been avoided. If the ostree compose fails, the
   Bodhi push should just proceed with an empty or old ostree directory
   (whatever is easier to implement). Rarely used experimental delivery
   methods should not hold the entire distribution hostage.

3. the decision to use autokarma. This is just yet another broken update
   that went stable due to autokarma. Autokarma is an absolutely
   unacceptable practice and should not be allowed. All push requests should
   be issued by a human after reviewing the status.

4. the decision to disallow direct stable pushes. The right way to fix the
   issue quickly, limiting the damage once done, would have been to push
   libglvnd directly to stable. But Bodhi won't allow that. Direct stable
   pushes are an essential mechanism to fix regressions and to limit the
   number of affected users by minimizing the exposure time to the
   regression.

Kevin Kofler
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Fedora 25 Koji buildroots broken…

[Hans de Goede]

Hi,

On 01/29/2017 08:00 PM, Kevin Fenzi wrote:

On Sun, 29 Jan 2017 18:12:59 +0100
Hans de Goede  wrote:


Hi,

On 01/29/2017 05:23 PM, Björn 'besser82' Esser wrote:

Allrighty…  Looks like the override for libglvnd somehow got
untagged…  Just re-tagged in f25-build…  Should be fixed now.


Well, that is a fix, but the real problem is that either the new
libglvnd enabled mesa should not be in updates-stable and thus not in
the buildroot; or both the new libglvnd enabled mesa and the new
libglvnd should be in updates-stable.

What happened is I created an update in bodhi for
libglvnd-0.2.999-7.gitdc16f8c.fc25 and mesa-13.0.3-3.fc25.

Then airlied did an unrelated bug-fix to mesa and created an update
in bodhi for mesa-13.0.3-4.fc25. This update did not obsolete my
previous update, did not inherit it bugs and did not inherit the
libglvnd package which was only in my update.


Yeah, currently bodhi doesn't obsolete if the other update is locked or
if the other update has a different packageset.


When I noticed things both updates were in perpetual locked state,
when they were finally unlocked airlied's update got auto-pushed to
stable because of karma (I had auto-karma disabled on mine), so now
we have a mesa depending on the latest libglvnd in updates-stable,
without the latest libglvnd.


:(


Yeah, this is quite unfortunate :(



When I tried to also push my update to stable, I could not as bodhi
complained there was a newer mesa already in stable, so I had to
remove mesa from my update (why does it detect conflicts like this on
push and not when someone creates a conflicting update?), loosing all
karma??? and now it is pending for testing.

Frankly I blame this whole mess on bodhi, it should not allow creating
updates which partly obsolete other updates, there likely is a good
reason the partly obsoleted update bundled multiple packages in one
update; or it should allow it and then simply add all non obsoleted
packages from the obsoleted update to the new update and obsolete the
old one.

I've had trouble with bodhi not doing proper obsoleting more often
lately, as well as having trouble with updates which involve
obsoleting getting in a perpetual locked state. Again frankly I've
the feeling that bodhi has regressed and that the old bodhi was more
stable. We really need to do better here, both with obsoleting and
with the locked state thing.


I'll leave the above for bodhi developers to comment on.
This has always been a complicated area, but I agree we could do
better.


I've filed:

https://github.com/fedora-infra/bodhi/issues/1254

To track this.

Regaards,

Hans




Why does the admin side of bodhi not run a check to see everything is
unlocked again once the push is complete ? That should at least catch
the lock issue ?


It does. The "lock issue" was just because we couldn't get a
f25-updates-testing push to complete due to rpm-ostree issues. So, IMHO
it was completely right to lock those until the push finished.

I guess of your suggestions it might indeed be best to reject a new
update when there's already one in existance that it cannot obsolete
(because it's locked or has a different packageset). I'm sure that will
annoy some people, but seems cleanest to me and then allows people to
discuss and modify the in-flight update or whatever.

kevin



___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org


___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Fedora 25 Koji buildroots broken…

[Kevin Fenzi]

On Sun, 29 Jan 2017 18:12:59 +0100
Hans de Goede  wrote:

> Hi,
> 
> On 01/29/2017 05:23 PM, Björn 'besser82' Esser wrote:
> > Allrighty…  Looks like the override for libglvnd somehow got
> > untagged…  Just re-tagged in f25-build…  Should be fixed now.  
> 
> Well, that is a fix, but the real problem is that either the new
> libglvnd enabled mesa should not be in updates-stable and thus not in
> the buildroot; or both the new libglvnd enabled mesa and the new
> libglvnd should be in updates-stable.
> 
> What happened is I created an update in bodhi for
> libglvnd-0.2.999-7.gitdc16f8c.fc25 and mesa-13.0.3-3.fc25.
> 
> Then airlied did an unrelated bug-fix to mesa and created an update
> in bodhi for mesa-13.0.3-4.fc25. This update did not obsolete my
> previous update, did not inherit it bugs and did not inherit the
> libglvnd package which was only in my update.

Yeah, currently bodhi doesn't obsolete if the other update is locked or
if the other update has a different packageset. 

> When I noticed things both updates were in perpetual locked state,
> when they were finally unlocked airlied's update got auto-pushed to
> stable because of karma (I had auto-karma disabled on mine), so now
> we have a mesa depending on the latest libglvnd in updates-stable,
> without the latest libglvnd.

:( 

> When I tried to also push my update to stable, I could not as bodhi
> complained there was a newer mesa already in stable, so I had to
> remove mesa from my update (why does it detect conflicts like this on
> push and not when someone creates a conflicting update?), loosing all
> karma??? and now it is pending for testing.
> 
> Frankly I blame this whole mess on bodhi, it should not allow creating
> updates which partly obsolete other updates, there likely is a good
> reason the partly obsoleted update bundled multiple packages in one
> update; or it should allow it and then simply add all non obsoleted
> packages from the obsoleted update to the new update and obsolete the
> old one.
> 
> I've had trouble with bodhi not doing proper obsoleting more often
> lately, as well as having trouble with updates which involve
> obsoleting getting in a perpetual locked state. Again frankly I've
> the feeling that bodhi has regressed and that the old bodhi was more
> stable. We really need to do better here, both with obsoleting and
> with the locked state thing.

I'll leave the above for bodhi developers to comment on.
This has always been a complicated area, but I agree we could do
better. 
> 
> Why does the admin side of bodhi not run a check to see everything is
> unlocked again once the push is complete ? That should at least catch
> the lock issue ?

It does. The "lock issue" was just because we couldn't get a
f25-updates-testing push to complete due to rpm-ostree issues. So, IMHO
it was completely right to lock those until the push finished. 

I guess of your suggestions it might indeed be best to reject a new
update when there's already one in existance that it cannot obsolete
(because it's locked or has a different packageset). I'm sure that will
annoy some people, but seems cleanest to me and then allows people to
discuss and modify the in-flight update or whatever. 

kevin


pgpPRGBMT7D3c.pgp
Description: OpenPGP digital signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Fedora 25 Koji buildroots broken…

[Hans de Goede]

Hi,

On 01/29/2017 05:23 PM, Björn 'besser82' Esser wrote:

Allrighty…  Looks like the override for libglvnd somehow got untagged…  Just 
re-tagged in f25-build…  Should be fixed now.


Well, that is a fix, but the real problem is that either the new libglvnd 
enabled
mesa should not be in updates-stable and thus not in the buildroot; or
both the new libglvnd enabled mesa and the new libglvnd should be in 
updates-stable.

What happened is I created an update in bodhi for 
libglvnd-0.2.999-7.gitdc16f8c.fc25
and mesa-13.0.3-3.fc25.

Then airlied did an unrelated bug-fix to mesa and created an update in bodhi for
mesa-13.0.3-4.fc25. This update did not obsolete my previous update, did not
inherit it bugs and did not inherit the libglvnd package which was only in my
update.

When I noticed things both updates were in perpetual locked state, when they
were finally unlocked airlied's update got auto-pushed to stable because of
karma (I had auto-karma disabled on mine), so now we have a mesa depending on
the latest libglvnd in updates-stable, without the latest libglvnd.

When I tried to also push my update to stable, I could not as bodhi complained
there was a newer mesa already in stable, so I had to remove mesa from my
update (why does it detect conflicts like this on push and not when someone
creates a conflicting update?), loosing all karma??? and now it is pending for
testing.

Frankly I blame this whole mess on bodhi, it should not allow creating
updates which partly obsolete other updates, there likely is a good reason
the partly obsoleted update bundled multiple packages in one update; or
it should allow it and then simply add all non obsoleted packages from
the obsoleted update to the new update and obsolete the old one.

I've had trouble with bodhi not doing proper obsoleting more often
lately, as well as having trouble with updates which involve obsoleting
getting in a perpetual locked state. Again frankly I've the feeling that
bodhi has regressed and that the old bodhi was more stable. We really need
to do better here, both with obsoleting and with the locked state thing.

Why does the admin side of bodhi not run a check to see everything is
unlocked again once the push is complete ? That should at least catch the
lock issue ?

For the 2 updates in question see:

https://bodhi.fedoraproject.org/updates/FEDORA-2017-9f6383547e
https://bodhi.fedoraproject.org/updates/FEDORA-2017-9c9c0899f9

Regards,

Hans



Am 29.01.2017 um 17:19 schrieb Björn 'besser82' Esser:


Hi there!

The Fedora 25 buildroot on Koji is b0rk3n…  :(

DEBUG util.py:435:  Error: nothing provides libGL.so.1()(64bit) needed by 
muffin-devel-3.2.1-1.fc25.x86_64.
DEBUG util.py:435:  nothing provides libEGL.so.1()(64bit) needed by 
clutter-1.26.0-1.fc25.x86_64.
DEBUG util.py:435:  nothing provides libGL.so.1()(64bit) needed by 
cairo-gobject-1.14.8-1.fc25.x86_64.
DEBUG util.py:435:  nothing provides libGL.so.1()(64bit) needed by 
cairo-1.14.8-1.fc25.x86_64.
DEBUG util.py:435:  nothing provides libGL.so.1()(64bit) needed by 
cairo-gobject-1.14.8-1.fc25.x86_64.
DEBUG util.py:435:  nothing provides libGL.so.1()(64bit) needed by 
cairo-1.14.8-1.fc25.x86_64.
DEBUG util.py:435:  nothing provides libGL.so.1()(64bit) needed by 
cairo-1.14.8-1.fc25.x86_64.
DEBUG util.py:435:  nothing provides libglvnd-glx(x86-64) needed by 
mesa-libGL-13.0.3-4.fc25.x86_64

Can the one who broke fix it, please?

Cheers
  Björn




___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org


___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Fedora 25 Koji buildroots broken…

[Björn 'besser82' Esser]

Allrighty…  Looks like the override for libglvnd somehow got untagged…  
Just re-tagged in f25-build…  Should be fixed now.



Am 29.01.2017 um 17:19 schrieb Björn 'besser82' Esser:


Hi there!

The Fedora 25 buildroot on Koji is b0rk3n…  :(

DEBUG util.py:435:  Error: nothing provides libGL.so.1()(64bit) needed by 
muffin-devel-3.2.1-1.fc25.x86_64.
DEBUG util.py:435:  nothing provides libEGL.so.1()(64bit) needed by 
clutter-1.26.0-1.fc25.x86_64.
DEBUG util.py:435:  nothing provides libGL.so.1()(64bit) needed by 
cairo-gobject-1.14.8-1.fc25.x86_64.
DEBUG util.py:435:  nothing provides libGL.so.1()(64bit) needed by 
cairo-1.14.8-1.fc25.x86_64.
DEBUG util.py:435:  nothing provides libGL.so.1()(64bit) needed by 
cairo-gobject-1.14.8-1.fc25.x86_64.
DEBUG util.py:435:  nothing provides libGL.so.1()(64bit) needed by 
cairo-1.14.8-1.fc25.x86_64.
DEBUG util.py:435:  nothing provides libGL.so.1()(64bit) needed by 
cairo-1.14.8-1.fc25.x86_64.
DEBUG util.py:435:  nothing provides libglvnd-glx(x86-64) needed by 
mesa-libGL-13.0.3-4.fc25.x86_64

Can the one who broke fix it, please?

Cheers
   Björn


___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Fedora 25 Koji buildroots broken…

[Björn 'besser82' Esser]

Hi there!

The Fedora 25 buildroot on Koji is b0rk3n…  :(

DEBUG util.py:435:  Error: nothing provides libGL.so.1()(64bit) needed by 
muffin-devel-3.2.1-1.fc25.x86_64.
DEBUG util.py:435:  nothing provides libEGL.so.1()(64bit) needed by 
clutter-1.26.0-1.fc25.x86_64.
DEBUG util.py:435:  nothing provides libGL.so.1()(64bit) needed by 
cairo-gobject-1.14.8-1.fc25.x86_64.
DEBUG util.py:435:  nothing provides libGL.so.1()(64bit) needed by 
cairo-1.14.8-1.fc25.x86_64.
DEBUG util.py:435:  nothing provides libGL.so.1()(64bit) needed by 
cairo-gobject-1.14.8-1.fc25.x86_64.
DEBUG util.py:435:  nothing provides libGL.so.1()(64bit) needed by 
cairo-1.14.8-1.fc25.x86_64.
DEBUG util.py:435:  nothing provides libGL.so.1()(64bit) needed by 
cairo-1.14.8-1.fc25.x86_64.
DEBUG util.py:435:  nothing provides libglvnd-glx(x86-64) needed by 
mesa-libGL-13.0.3-4.fc25.x86_64

Can the one who broke fix it, please?

Cheers
  Björn

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: koji is broken

[Christopher Meng]

On Tuesday, March 3, 2015, Kevin Fenzi ke...@scrye.com wrote:

 I think this is some kind of connectivity issue.

 Next time this happens can you run the koji command again with
 '--debug' and see if anything stands out? Also make sure you can ping
 and reach the koji web page.

 There's also a '--debug-xmlrpc' but I think that will show your cert
 and other info that shouldn't be public, so you can run it, but don't
 share that output in a bug ticket or anything.



Sure.


-- 

Yours sincerely,
Christopher Meng

http://cicku.me
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: koji is broken

[Kevin Fenzi]

On Sat, 28 Feb 2015 12:49:39 +0800
Christopher Meng cicku...@gmail.com wrote:

 I still met
 
 Could not execute build: [('SSL routines', 'SSL3_WRITE_BYTES', 'ssl
 handshake failure')]
 
 this morning (2 hrs ago).

I think this is some kind of connectivity issue. 

Next time this happens can you run the koji command again with
'--debug' and see if anything stands out? Also make sure you can ping
and reach the koji web page. 

There's also a '--debug-xmlrpc' but I think that will show your cert
and other info that shouldn't be public, so you can run it, but don't
share that output in a bug ticket or anything. 

kevin


pgpXgRGOVE9UV.pgp
Description: OpenPGP digital signature
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: koji is broken

[Christopher Meng]

I still met

Could not execute build: [('SSL routines', 'SSL3_WRITE_BYTES', 'ssl
handshake failure')]

this morning (2 hrs ago).

-- 

Yours sincerely,
Christopher Meng

http://cicku.me
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: koji is broken

[Ralf Corsepius]

On 02/27/2015 11:15 AM, Michael J Gruber wrote:

Ralf Corsepius venit, vidit, dixit 26.02.2015 19:09:



Yes Ralf, fedora-cert is the better way to deal with the certs (rather
than re-running setup).

We used to be able to download a new cert from FAS. That page seems to
be MIA now without any reference to the cli tools. Doesn't help either.

Have you tried getting a new cert (even though yours is supposed to be
valid)?

No. Things appear to be fully operational again now.

It likely was my fault to have rebooted the machine I was using or to 
try on a different machine to furtherly investigate - but I didn't :(


I have absolutely no clue about what might have been going on. Saying 
more about it would be speculation.


Ralf





--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: koji is broken

[Michael J Gruber]

Ralf Corsepius venit, vidit, dixit 26.02.2015 19:09:
 On 02/26/2015 06:44 PM, Matěj Cepl wrote:
 On 2015-02-26, 16:22 GMT, Ralf Corsepius wrote:
 That should be completely unrelated to the kojipkgs issue, as that is
 talking to the koji hub directly.

 And would you have the kindness to tell me what I can to about it?

 This is usually very clear and obvious way how Koji tells me
 that my certificates have expired.

Haha. Great sense of humor, Matěj.

 Running fedora-packager-setup
 should take care of it.
 
 The koji message is far from being clear.
 
 My certificate definitely had not expired.
 
  From ~/.fedora.cert
 ...
Validity
  Not Before: Feb  3 03:23:15 2015 GMT
  Not After : Aug  2 03:23:15 2015 GMT
 ...
 
 # fedora-cert -v
 Verifying Certificate
 cert expires: 2015-08-02
 
 Ralf

Yes Ralf, fedora-cert is the better way to deal with the certs (rather
than re-running setup).

We used to be able to download a new cert from FAS. That page seems to
be MIA now without any reference to the cli tools. Doesn't help either.

Have you tried getting a new cert (even though yours is supposed to be
valid)?

Michael
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: koji is broken

[Ralf Corsepius]

On 02/26/2015 04:40 PM, Kevin Fenzi wrote:

On Thu, 26 Feb 2015 15:26:32 +0100
Dan Horák d...@danny.cz wrote:


On Thu, 26 Feb 2015 15:11:33 +0100
Ralf Corsepius rc040...@freenet.de wrote:


Hi,

seems to me as if koji has seized operation:

https://kojipkgs.fedoraproject.org//work/tasks/1304/9081304/root.log
https://kojipkgs.fedoraproject.org//work/tasks/1319/9081319/root.log


I guess this is the known squid doesn't respond issue. nirik will
restart it.


Rather it's the known 'squid starts being very slow and failing some
builds' so that was me restarting it.

Just resubmit for now.


# fedpkg build
...
Could not execute build: [('SSL routines', 'SSL3_WRITE_BYTES', 'ssl 
handshake failure')]

...


I am working on tracking down the problem, but it's proving quite
elusive. ;(


BTW: Here's another variant of a break down:
https://kojipkgs.fedoraproject.org//work/tasks/1835/9081835/root.log

This time, yum/dnf (whatever currently is being used, I presume it's 
yum) is demonstrating one of the yum/dnf issues we discussed yesterday:


Yum retries to download packages from a mirror it could have know to be 
broken, because it failed to connect to it before.



Ralf

--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: koji is broken

[Kevin Fenzi]

On Thu, 26 Feb 2015 17:06:03 +0100
Ralf Corsepius rc040...@freenet.de wrote:

 On 02/26/2015 04:40 PM, Kevin Fenzi wrote:
  On Thu, 26 Feb 2015 15:26:32 +0100
  Dan Horák d...@danny.cz wrote:
 
  On Thu, 26 Feb 2015 15:11:33 +0100
  Ralf Corsepius rc040...@freenet.de wrote:
 
  Hi,
 
  seems to me as if koji has seized operation:
 
  https://kojipkgs.fedoraproject.org//work/tasks/1304/9081304/root.log
  https://kojipkgs.fedoraproject.org//work/tasks/1319/9081319/root.log
 
  I guess this is the known squid doesn't respond issue. nirik will
  restart it.
 
  Rather it's the known 'squid starts being very slow and failing some
  builds' so that was me restarting it.
 
  Just resubmit for now.
 
 # fedpkg build
 ...
 Could not execute build: [('SSL routines', 'SSL3_WRITE_BYTES', 'ssl 
 handshake failure')]
 ...

That should be completely unrelated to the kojipkgs issue, as that is
talking to the koji hub directly. 

Can you do a:

koji list-tasks --mine

  I am working on tracking down the problem, but it's proving quite
  elusive. ;(
 
 BTW: Here's another variant of a break down:
 https://kojipkgs.fedoraproject.org//work/tasks/1835/9081835/root.log
 
 This time, yum/dnf (whatever currently is being used, I presume it's 
 yum) is demonstrating one of the yum/dnf issues we discussed
 yesterday:
 
 Yum retries to download packages from a mirror it could have know to
 be broken, because it failed to connect to it before.

Sure, but then it would have just failed faster as thats the only
mirror thats defined internally for builders. 

This was caused by my restarting squid. 

kevin




pgpCtE440p51r.pgp
Description: OpenPGP digital signature
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: koji is broken

[Ralf Corsepius]

On 02/26/2015 05:12 PM, Kevin Fenzi wrote:

On Thu, 26 Feb 2015 17:06:03 +0100
Ralf Corsepius rc040...@freenet.de wrote:


On 02/26/2015 04:40 PM, Kevin Fenzi wrote:

On Thu, 26 Feb 2015 15:26:32 +0100
Dan Horák d...@danny.cz wrote:


On Thu, 26 Feb 2015 15:11:33 +0100
Ralf Corsepius rc040...@freenet.de wrote:


Hi,

seems to me as if koji has seized operation:

https://kojipkgs.fedoraproject.org//work/tasks/1304/9081304/root.log
https://kojipkgs.fedoraproject.org//work/tasks/1319/9081319/root.log


I guess this is the known squid doesn't respond issue. nirik will
restart it.


Rather it's the known 'squid starts being very slow and failing some
builds' so that was me restarting it.

Just resubmit for now.


# fedpkg build
...
Could not execute build: [('SSL routines', 'SSL3_WRITE_BYTES', 'ssl
handshake failure')]
...


That should be completely unrelated to the kojipkgs issue, as that is
talking to the koji hub directly.


And would you have the kindness to tell me what I can to about it?


Can you do a:

koji list-tasks --mine


# koji list-tasks --mine
Error: [('SSL routines', 'SSL3_READ_BYTES', 'ssl handshake failure')]




I am working on tracking down the problem, but it's proving quite
elusive. ;(


BTW: Here's another variant of a break down:
https://kojipkgs.fedoraproject.org//work/tasks/1835/9081835/root.log

This time, yum/dnf (whatever currently is being used, I presume it's
yum) is demonstrating one of the yum/dnf issues we discussed
yesterday:

Yum retries to download packages from a mirror it could have know to
be broken, because it failed to connect to it before.


Sure, but then it would have just failed faster as thats the only
mirror thats defined internally for builders.


yum could have tried a different mirror instead of retrying the already 
broken one again.


--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: koji is broken

[Kevin Fenzi]

On Thu, 26 Feb 2015 15:26:32 +0100
Dan Horák d...@danny.cz wrote:

 On Thu, 26 Feb 2015 15:11:33 +0100
 Ralf Corsepius rc040...@freenet.de wrote:
 
  Hi,
  
  seems to me as if koji has seized operation:
  
  https://kojipkgs.fedoraproject.org//work/tasks/1304/9081304/root.log
  https://kojipkgs.fedoraproject.org//work/tasks/1319/9081319/root.log
 
 I guess this is the known squid doesn't respond issue. nirik will
 restart it.

Rather it's the known 'squid starts being very slow and failing some
builds' so that was me restarting it. 

Just resubmit for now. 

I am working on tracking down the problem, but it's proving quite
elusive. ;( 

kevin


pgpJS9kq3tI3_.pgp
Description: OpenPGP digital signature
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

koji is broken

[Ralf Corsepius]

Hi,

seems to me as if koji has seized operation:

https://kojipkgs.fedoraproject.org//work/tasks/1304/9081304/root.log
https://kojipkgs.fedoraproject.org//work/tasks/1319/9081319/root.log

Ralf
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: koji is broken

[Dan Horák]

On Thu, 26 Feb 2015 15:11:33 +0100
Ralf Corsepius rc040...@freenet.de wrote:

 Hi,
 
 seems to me as if koji has seized operation:
 
 https://kojipkgs.fedoraproject.org//work/tasks/1304/9081304/root.log
 https://kojipkgs.fedoraproject.org//work/tasks/1319/9081319/root.log

I guess this is the known squid doesn't respond issue. nirik will
restart it.


Dan
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: koji is broken

[Matěj Cepl]

On 2015-02-26, 16:22 GMT, Ralf Corsepius wrote:
 That should be completely unrelated to the kojipkgs issue, as that is
 talking to the koji hub directly.

 And would you have the kindness to tell me what I can to about it?

This is usually very clear and obvious way how Koji tells me 
that my certificates have expired. Running fedora-packager-setup 
should take care of it.

Matěj

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: koji is broken

[Kushal Das]

On Thu, Feb 26, 2015 at 10:44 PM, Kevin Fenzi ke...@scrye.com wrote:
 On Thu, 26 Feb 2015 17:22:01 +0100
 Ralf Corsepius rc040...@freenet.de wrote:

 And would you have the kindness to tell me what I can to about it?

 I'm not sure. It's some issue with your communication to the koji
 hub...

  Can you do a:
 
  koji list-tasks --mine

 # koji list-tasks --mine
 Error: [('SSL routines', 'SSL3_READ_BYTES', 'ssl handshake failure')]

 Is your fedora koji cert up to date?

 Do:

 fedora-cert -v

 and if it's expired it should offer to issue you a new one.
 Usually however, it would say expired, not handshake failure.

 Can you ping koji.fedoraproject.org? browse to it?
 Is the time correct on your machine?

I also get the same error. I have update cert. I can ping and browse koji.
Time is correct in the system.

Kushal
-- 
Fedora Cloud Engineer
CPython Core Developer
Director Python Software Foundation
http://kushaldas.in
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: koji is broken

[Ralf Corsepius]

On 02/26/2015 06:44 PM, Matěj Cepl wrote:

On 2015-02-26, 16:22 GMT, Ralf Corsepius wrote:

That should be completely unrelated to the kojipkgs issue, as that is
talking to the koji hub directly.


And would you have the kindness to tell me what I can to about it?


This is usually very clear and obvious way how Koji tells me
that my certificates have expired. Running fedora-packager-setup
should take care of it.


The koji message is far from being clear.

My certificate definitely had not expired.

From ~/.fedora.cert
...
  Validity
Not Before: Feb  3 03:23:15 2015 GMT
Not After : Aug  2 03:23:15 2015 GMT
...

# fedora-cert -v
Verifying Certificate
cert expires: 2015-08-02

Ralf

--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: koji is broken

[Kevin Fenzi]

On Thu, 26 Feb 2015 17:22:01 +0100
Ralf Corsepius rc040...@freenet.de wrote:

 And would you have the kindness to tell me what I can to about it?

I'm not sure. It's some issue with your communication to the koji
hub... 

  Can you do a:
 
  koji list-tasks --mine
 
 # koji list-tasks --mine
 Error: [('SSL routines', 'SSL3_READ_BYTES', 'ssl handshake failure')]

Is your fedora koji cert up to date? 

Do: 

fedora-cert -v

and if it's expired it should offer to issue you a new one. 
Usually however, it would say expired, not handshake failure. 

Can you ping koji.fedoraproject.org? browse to it? 
Is the time correct on your machine?

  I am working on tracking down the problem, but it's proving quite
  elusive. ;(
 
  BTW: Here's another variant of a break down:
  https://kojipkgs.fedoraproject.org//work/tasks/1835/9081835/root.log
 
  This time, yum/dnf (whatever currently is being used, I presume
  it's yum) is demonstrating one of the yum/dnf issues we discussed
  yesterday:
 
  Yum retries to download packages from a mirror it could have know
  to be broken, because it failed to connect to it before.
 
  Sure, but then it would have just failed faster as thats the only
  mirror thats defined internally for builders.
 
 yum could have tried a different mirror instead of retrying the
 already broken one again.

There's no other mirrors for internal builds. It's a baseurl to the
kojipkgs server. 

I am considering making another kojipkgs server and making them round
robin in dns. At least with this restarting squid won't break a bunch
of builds. 

kevin


pgpYlLr3ukA_X.pgp
Description: OpenPGP digital signature
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: koji is broken

[Ralf Corsepius]

On 02/26/2015 06:14 PM, Kevin Fenzi wrote:

On Thu, 26 Feb 2015 17:22:01 +0100
Ralf Corsepius rc040...@freenet.de wrote:


And would you have the kindness to tell me what I can to about it?


I'm not sure. It's some issue with your communication to the koji
hub...


Meanwhile I rebooted (for unrelated reasons), now the ssl-errors are 
gone. So, it have been could be your or my end - No idea.



Can you do a:

koji list-tasks --mine


# koji list-tasks --mine
Error: [('SSL routines', 'SSL3_READ_BYTES', 'ssl handshake failure')]


Is your fedora koji cert up to date?


Yes it is.


Do:

fedora-cert -v

and if it's expired it should offer to issue you a new one.
Usually however, it would say expired, not handshake failure.

Can you ping koji.fedoraproject.org? browse to it?
Is the time correct on your machine?


Yes, yes and yes ... BTW: koji/fedpkg now seems to work again.


I am working on tracking down the problem, but it's proving quite
elusive. ;(


BTW: Here's another variant of a break down:
https://kojipkgs.fedoraproject.org//work/tasks/1835/9081835/root.log

This time, yum/dnf (whatever currently is being used, I presume
it's yum) is demonstrating one of the yum/dnf issues we discussed
yesterday:

Yum retries to download packages from a mirror it could have know
to be broken, because it failed to connect to it before.


Sure, but then it would have just failed faster as thats the only
mirror thats defined internally for builders.


yum could have tried a different mirror instead of retrying the
already broken one again.


There's no other mirrors for internal builds. It's a baseurl to the
kojipkgs server.


Yes, my point is it is X times trying in vain to access a host to 
download X packages. Not sure what happens when this happens with a real 
mirrorlist/metalink-list, whose top 5 are unreachable/flakey/dead or broken.


I am sure I've seen, yum iterating X times over the same list of broken 
mirrors.


Ralf



--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

[EPEL-devel] [EPEL] #27: EPEL 5 Koji buildroot broken

[EPEL]

#27: EPEL 5 Koji buildroot broken
-+
 Reporter:  ellert   |  Owner:  epel-wranglers
 Type:  defect   | Status:  new
 Priority:  critical |  Milestone:  EPEL-5
Component:  Package request  |Version:
 Keywords:   |
-+
 Maybe this is a better place to file this:

 Original: https://fedorahosted.org/rel-eng/ticket/6065

 Trying to build an EPEL 5 package fails during buildSRPMFromSCM.

 root.log says:
 {{{
 DEBUG util.py:283:  Error: Package: fedpkg-0.5.9.2-1.el5.noarch (build)
 DEBUG util.py:283: Requires: GitPython = 0.2.0
 }}}
 See ​https://koji.fedoraproject.org/koji/taskinfo?taskID=8422077 for the
 complete logs.

 GitPython seems to have been untagged from EPEL 5?

-- 
Ticket URL: https://fedorahosted.org/epel/ticket/27
EPEL https://fedoraproject.org/wiki/EPEL
Extra Packages for Enterprise Linux
___
epel-devel mailing list
epel-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/epel-devel

Re: [EPEL-devel] [EPEL] #27: EPEL 5 Koji buildroot broken

[EPEL]

#27: EPEL 5 Koji buildroot broken
--+
  Reporter:  ellert   |  Owner:  epel-wranglers
  Type:  defect   | Status:  closed
  Priority:  critical |  Milestone:  EPEL-5
 Component:  Package request  |Version:
Resolution:  fixed|   Keywords:
--+
Changes (by till):

 * status:  new = closed
 * resolution:   = fixed


Comment:

 It was orphaned for too long and therefore retired. Kevin sacrifised
 himself as new maintainer. Therefore building should work again in less
 than an hour.

-- 
Ticket URL: https://fedorahosted.org/epel/ticket/27#comment:1
EPEL https://fedoraproject.org/wiki/EPEL
Extra Packages for Enterprise Linux
___
epel-devel mailing list
epel-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/epel-devel

koji rawhide broken: ImportError: cannot import name ProtocolError

[Richard W.M. Jones]

https://kojipkgs.fedoraproject.org//work/tasks/7943/8047943/mock_output.log

Something is broken.  fedpkg maybe?

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-top is 'top' for virtual machines.  Tiny program with many
powerful monitoring features, net stats, disk stats, logging, etc.
http://people.redhat.com/~rjones/virt-top
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: koji rawhide broken: ImportError: cannot import name ProtocolError

[Ken Dreyer]

Was wondering the same thing on my rubygem-thinking-sphinx build just now.

https://kojipkgs.fedoraproject.org//work/tasks/7979/8047979/root.log

- Ken

On Wed, Nov 5, 2014 at 11:35 AM, Richard W.M. Jones rjo...@redhat.com wrote:

 https://kojipkgs.fedoraproject.org//work/tasks/7943/8047943/mock_output.log

 Something is broken.  fedpkg maybe?

 Rich.

 --
 Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
 Read my programming and virtualization blog: http://rwmj.wordpress.com
 virt-top is 'top' for virtual machines.  Tiny program with many
 powerful monitoring features, net stats, disk stats, logging, etc.
 http://people.redhat.com/~rjones/virt-top
 --
 devel mailing list
 devel@lists.fedoraproject.org
 https://admin.fedoraproject.org/mailman/listinfo/devel
 Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: koji rawhide broken: ImportError: cannot import name ProtocolError

[Orion Poplawski]

On 11/05/2014 11:35 AM, Richard W.M. Jones wrote:
 
 https://kojipkgs.fedoraproject.org//work/tasks/7943/8047943/mock_output.log
 
 Something is broken.  fedpkg maybe?
 
 Rich.
 

missing/incompatible dep for python-requests?  It was just updated to
python-requests-2.4.3-1.fc22


-- 
Orion Poplawski
Technical Manager 303-415-9701 x222
NWRA, Boulder/CoRA Office FAX: 303-415-9702
3380 Mitchell Lane   or...@nwra.com
Boulder, CO 80301   http://www.nwra.com
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: koji rawhide broken: ImportError: cannot import name ProtocolError

[Peter MacKinnon]

On 11/05/2014 01:37 PM, Ken Dreyer wrote:

Was wondering the same thing on my rubygem-thinking-sphinx build just now.

https://kojipkgs.fedoraproject.org//work/tasks/7979/8047979/root.log

- Ken

On Wed, Nov 5, 2014 at 11:35 AM, Richard W.M. Jones rjo...@redhat.com wrote:

https://kojipkgs.fedoraproject.org//work/tasks/7943/8047943/mock_output.log

Something is broken.  fedpkg maybe?

Rich.

--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-top is 'top' for virtual machines.  Tiny program with many
powerful monitoring features, net stats, disk stats, logging, etc.
http://people.redhat.com/~rjones/virt-top
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct


Yeah, blocked on this also.

https://kojipkgs.fedoraproject.org//work/tasks/8759/8048759/mock_output.log

--
Peter MacKinnon
Emerging Technologies
Red Hat Inc.
Raleigh, NC

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: koji rawhide broken: ImportError: cannot import name ProtocolError

[Ralph Bean]

On Wed, Nov 05, 2014 at 11:44:18AM -0700, Orion Poplawski wrote:
 On 11/05/2014 11:35 AM, Richard W.M. Jones wrote:
  
  https://kojipkgs.fedoraproject.org//work/tasks/7943/8047943/mock_output.log
  
  Something is broken.  fedpkg maybe?
  
  Rich.
  
 
 missing/incompatible dep for python-requests?  It was just updated to
 python-requests-2.4.3-1.fc22

Yes, lpython-requests was the problem (it needs a newer python-urllib3).

It is untagged from f22 for now while I get python-urllib3 in.  Sorry
for the mess.


pgpWCTxgEw5zN.pgp
Description: PGP signature
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: f15 koji buildroots broken?

[Elio Maldonado]

On 01/11/2012 07:40 AM, Kevin Fenzi wrote: 

On Wed, 11 Jan 2012 15:45:05 +0100
Michael J Gruber michaeljgruber+gm...@fastmail.fm wrote: 
blockquote
Infrastructure ticket anyone? 

Well, rel-eng. ;) https://fedorahosted.org/rel-eng/ticket/5023 This issue was 
due to a nss-util buildroot override expiring. 
I've re-enabled the override for now, but it would be nice if we could
get the update into stable updates soon. 
https://admin.fedoraproject.org/updates/FEDORA-2011-17399/ 
/blockquote
That update could use some karmic points, especially from proven tests. 
I must refrain from doing so being the maintainer of some of the packages :-) 

-elio 

blockquote
Things should be back building soon.

kevin 


/blockquote

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: f15 koji buildroots broken?

[Nikola Pajkovsky]

Ralf Corsepius rc040...@freenet.de writes:

 Hi,

 I am observing weird build failures for f15:
 http://koji.fedoraproject.org/koji/taskinfo?taskID=3638192

 The corresponding root.log
 (http://koji.fedoraproject.org/koji/getfile?taskID=3638193name=root.log)

 tells this:
 ,,,
 DEBUG backend.py:862:  ['/usr/bin/yum', '--installroot',
 /var/lib/mock/dist-f15-build-1215765-195489/root/', 'groupinstall',
 srpm-build']
 DEBUG util.py:307:  Executing command: ['/usr/bin/yum',
 --installroot', '/var/lib/mock/dist-f15-build-1215765-195489/root/',
 groupinstall', 'srpm-build']
 DEBUG util.py:257:  Error: Package: nss-softokn-3.13.1-14.fc15.i686 (build)
 DEBUG util.py:257: Requires: nss-util = 3.13.1
 DEBUG util.py:257: Installing:
 nss-util-3.12.10-1.fc15.i686 (build)
 DEBUG util.py:257: nss-util = 3.12.10-1.fc15
 DEBUG util.py:257:   You could try using --skip-broken to work around
 the problem
 DEBUG util.py:257:   You could try running: rpm -Va --nofiles --nodigest
 DEBUG util.py:257:  Error: Package: nss-3.13.1-9.fc15.i686 (build)
 DEBUG util.py:257: Requires: libnssutil3.so(NSSUTIL_3.13)
 DEBUG util.py:257:  Error: Package: nss-3.13.1-9.fc15.i686 (build)
 DEBUG util.py:257: Requires: nspr = 4.8.9
 DEBUG util.py:257: Installing: nspr-4.8.8-1.fc15.i686 (build)
 DEBUG util.py:257: nspr = 4.8.8-1.fc15
 DEBUG util.py:257:  Error: Package: nss-softokn-3.13.1-14.fc15.i686 (build)
 DEBUG util.py:257: Requires: nspr = 4.8.9
 DEBUG util.py:257: Installing: nspr-4.8.8-1.fc15.i686 (build)
 DEBUG util.py:257: nspr = 4.8.8-1.fc15
 DEBUG util.py:257:  Error: Package: nss-3.13.1-9.fc15.i686 (build)
 DEBUG util.py:257: Requires: nss-util = 3.13.1
 DEBUG util.py:257: Installing:
 nss-util-3.12.10-1.fc15.i686 (build)
 DEBUG util.py:257: nss-util = 3.12.10-1.fc15
 DEBUG util.py:347:  Child returncode was: 1
 

 Seems to me as if f15 has been infected by package conflicts, which
 seem to have made it into koji's buildroots

 Ralf

and still is valid

-- 
Nikola
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: f15 koji buildroots broken?

[Michael J Gruber]

Nikola Pajkovsky venit, vidit, dixit 11.01.2012 12:14:
 Ralf Corsepius rc040...@freenet.de writes:
 
 Hi,

 I am observing weird build failures for f15:
 http://koji.fedoraproject.org/koji/taskinfo?taskID=3638192

 The corresponding root.log
 (http://koji.fedoraproject.org/koji/getfile?taskID=3638193name=root.log)

 tells this:
 ,,,
 DEBUG backend.py:862:  ['/usr/bin/yum', '--installroot',
 /var/lib/mock/dist-f15-build-1215765-195489/root/', 'groupinstall',
 srpm-build']
 DEBUG util.py:307:  Executing command: ['/usr/bin/yum',
 --installroot', '/var/lib/mock/dist-f15-build-1215765-195489/root/',
 groupinstall', 'srpm-build']
 DEBUG util.py:257:  Error: Package: nss-softokn-3.13.1-14.fc15.i686 (build)
 DEBUG util.py:257: Requires: nss-util = 3.13.1
 DEBUG util.py:257: Installing:
 nss-util-3.12.10-1.fc15.i686 (build)
 DEBUG util.py:257: nss-util = 3.12.10-1.fc15
 DEBUG util.py:257:   You could try using --skip-broken to work around
 the problem
 DEBUG util.py:257:   You could try running: rpm -Va --nofiles --nodigest
 DEBUG util.py:257:  Error: Package: nss-3.13.1-9.fc15.i686 (build)
 DEBUG util.py:257: Requires: libnssutil3.so(NSSUTIL_3.13)
 DEBUG util.py:257:  Error: Package: nss-3.13.1-9.fc15.i686 (build)
 DEBUG util.py:257: Requires: nspr = 4.8.9
 DEBUG util.py:257: Installing: nspr-4.8.8-1.fc15.i686 (build)
 DEBUG util.py:257: nspr = 4.8.8-1.fc15
 DEBUG util.py:257:  Error: Package: nss-softokn-3.13.1-14.fc15.i686 (build)
 DEBUG util.py:257: Requires: nspr = 4.8.9
 DEBUG util.py:257: Installing: nspr-4.8.8-1.fc15.i686 (build)
 DEBUG util.py:257: nspr = 4.8.8-1.fc15
 DEBUG util.py:257:  Error: Package: nss-3.13.1-9.fc15.i686 (build)
 DEBUG util.py:257: Requires: nss-util = 3.13.1
 DEBUG util.py:257: Installing:
 nss-util-3.12.10-1.fc15.i686 (build)
 DEBUG util.py:257: nss-util = 3.12.10-1.fc15
 DEBUG util.py:347:  Child returncode was: 1
 

 Seems to me as if f15 has been infected by package conflicts, which
 seem to have made it into koji's buildroots

 Ralf
 
 and still is valid
 

Infrastructure ticket anyone?

Michael

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: f15 koji buildroots broken?

[Kevin Fenzi]

On Wed, 11 Jan 2012 15:45:05 +0100
Michael J Gruber michaeljgruber+gm...@fastmail.fm wrote:

 Infrastructure ticket anyone?

Well, rel-eng. ;) 

https://fedorahosted.org/rel-eng/ticket/5023

This issue was due to a nss-util buildroot override expiring. 
I've re-enabled the override for now, but it would be nice if we could
get the update into stable updates soon. 

https://admin.fedoraproject.org/updates/FEDORA-2011-17399/

Things should be back building soon.

kevin


signature.asc
Description: PGP signature
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

f15 koji buildroots broken?

[Ralf Corsepius]

Hi,

I am observing weird build failures for f15:
http://koji.fedoraproject.org/koji/taskinfo?taskID=3638192

The corresponding root.log 
(http://koji.fedoraproject.org/koji/getfile?taskID=3638193name=root.log)


tells this:
,,,
DEBUG backend.py:862:  ['/usr/bin/yum', '--installroot', 
'/var/lib/mock/dist-f15-build-1215765-195489/root/', 'groupinstall', 
'srpm-build']
DEBUG util.py:307:  Executing command: ['/usr/bin/yum', '--installroot', 
'/var/lib/mock/dist-f15-build-1215765-195489/root/', 'groupinstall', 
'srpm-build']

DEBUG util.py:257:  Error: Package: nss-softokn-3.13.1-14.fc15.i686 (build)
DEBUG util.py:257: Requires: nss-util = 3.13.1
DEBUG util.py:257: Installing: nss-util-3.12.10-1.fc15.i686 
(build)

DEBUG util.py:257: nss-util = 3.12.10-1.fc15
DEBUG util.py:257:   You could try using --skip-broken to work around 
the problem

DEBUG util.py:257:   You could try running: rpm -Va --nofiles --nodigest
DEBUG util.py:257:  Error: Package: nss-3.13.1-9.fc15.i686 (build)
DEBUG util.py:257: Requires: libnssutil3.so(NSSUTIL_3.13)
DEBUG util.py:257:  Error: Package: nss-3.13.1-9.fc15.i686 (build)
DEBUG util.py:257: Requires: nspr = 4.8.9
DEBUG util.py:257: Installing: nspr-4.8.8-1.fc15.i686 (build)
DEBUG util.py:257: nspr = 4.8.8-1.fc15
DEBUG util.py:257:  Error: Package: nss-softokn-3.13.1-14.fc15.i686 (build)
DEBUG util.py:257: Requires: nspr = 4.8.9
DEBUG util.py:257: Installing: nspr-4.8.8-1.fc15.i686 (build)
DEBUG util.py:257: nspr = 4.8.8-1.fc15
DEBUG util.py:257:  Error: Package: nss-3.13.1-9.fc15.i686 (build)
DEBUG util.py:257: Requires: nss-util = 3.13.1
DEBUG util.py:257: Installing: nss-util-3.12.10-1.fc15.i686 
(build)

DEBUG util.py:257: nss-util = 3.12.10-1.fc15
DEBUG util.py:347:  Child returncode was: 1


Seems to me as if f15 has been infected by package conflicts, which seem 
to have made it into koji's buildroots


Ralf
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

koji rawhide broken

[Iain Arnell]

Is anyone able to fix koji rawhide buildroot?

DEBUG util.py:247:  Error: Package: kernel-3.1.0-0.rc10.git1.1.fc17.i686 (build)
DEBUG util.py:247: Requires: grubby = 8.3-1
DEBUG util.py:247: Installing: grubby-8.2-1.fc17.i686 (build)
DEBUG util.py:247: grubby = 8.2-1.fc17
DEBUG util.py:247:   You could try using --skip-broken to work around
the problem
DEBUG util.py:247:   You could try running: rpm -Va --nofiles --nodigest
DEBUG util.py:247:  Error: Package: kernel-3.1.0-0.rc10.git1.1.fc17.i686 (build)
DEBUG util.py:247: Requires: grubby = 8.3-1
DEBUG util.py:247: Available: grubby-8.2-1.fc17.i686 (build)
DEBUG util.py:247: grubby = 8.2-1.fc17

It looks like kernel-3.1.0-0.rc10.git1.1.fc17 needs to be untagged
until grubby-8.3-1.fc17 is built and available.

-- 
Iain.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: koji rawhide broken

[darrell pfeifer]

On Sat, Oct 22, 2011 at 05:30, Iain Arnell iarn...@gmail.com wrote:

 Is anyone able to fix koji rawhide buildroot?

 DEBUG util.py:247:  Error: Package: kernel-3.1.0-0.rc10.git1.1.fc17.i686
 (build)
 DEBUG util.py:247: Requires: grubby = 8.3-1
 DEBUG util.py:247: Installing: grubby-8.2-1.fc17.i686 (build)
 DEBUG util.py:247: grubby = 8.2-1.fc17
 DEBUG util.py:247:   You could try using --skip-broken to work around
 the problem
 DEBUG util.py:247:   You could try running: rpm -Va --nofiles --nodigest
 DEBUG util.py:247:  Error: Package: kernel-3.1.0-0.rc10.git1.1.fc17.i686
 (build)
 DEBUG util.py:247: Requires: grubby = 8.3-1
 DEBUG util.py:247: Available: grubby-8.2-1.fc17.i686 (build)
 DEBUG util.py:247: grubby = 8.2-1.fc17

 It looks like kernel-3.1.0-0.rc10.git1.1.fc17 needs to be untagged
 until grubby-8.3-1.fc17 is built and available.


Looks like the fc17 version didn't get built but you can grab the fc16
version from koji.

darrell
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: koji rawhide broken

[TASAKA Mamoru]

Iain Arnell wrote, at 10/22/2011 09:30 PM +9:00:
 Is anyone able to fix koji rawhide buildroot?

 DEBUG util.py:247:  Error: Package: kernel-3.1.0-0.rc10.git1.1.fc17.i686 
 (build)
 DEBUG util.py:247: Requires: grubby= 8.3-1
 DEBUG util.py:247: Installing: grubby-8.2-1.fc17.i686 (build)
 DEBUG util.py:247: grubby = 8.2-1.fc17
 DEBUG util.py:247:   You could try using --skip-broken to work around
 the problem
 DEBUG util.py:247:   You could try running: rpm -Va --nofiles --nodigest
 DEBUG util.py:247:  Error: Package: kernel-3.1.0-0.rc10.git1.1.fc17.i686 
 (build)
 DEBUG util.py:247: Requires: grubby= 8.3-1
 DEBUG util.py:247: Available: grubby-8.2-1.fc17.i686 (build)
 DEBUG util.py:247: grubby = 8.2-1.fc17

 It looks like kernel-3.1.0-0.rc10.git1.1.fc17 needs to be untagged
 until grubby-8.3-1.fc17 is built and available.


Untagged.

Regards,
Mamoru


-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Koji buildroots broken by deltarpm at the moment?

[Richard W.M. Jones]

DEBUG util.py:247:  ERROR with rpm_check_debug vs depsolve:
DEBUG util.py:247:  librpm.so.1()(64bit) is needed by 
deltarpm-3.6-0.4.20100708git.fc15.x86_64
DEBUG util.py:247:  librpmio.so.1()(64bit) is needed by 
deltarpm-3.6-0.4.20100708git.fc15.x86_64

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming blog: http://rwmj.wordpress.com
Fedora now supports 80 OCaml packages (the OPEN alternative to F#)
http://cocan.org/getting_started_with_ocaml_on_red_hat_and_fedora
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Koji buildroots broken by deltarpm at the moment?

[Richard W.M. Jones]

On Tue, Jan 18, 2011 at 01:53:01PM +, Richard W.M. Jones wrote:
 
 DEBUG util.py:247:  ERROR with rpm_check_debug vs depsolve:
 DEBUG util.py:247:  librpm.so.1()(64bit) is needed by 
 deltarpm-3.6-0.4.20100708git.fc15.x86_64
 DEBUG util.py:247:  librpmio.so.1()(64bit) is needed by 
 deltarpm-3.6-0.4.20100708git.fc15.x86_64

Oh I see, it's just that deltarpm is broken because of the RPM
update.  It's not a general buildroot issue.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
virt-df lists disk usage of guests without needing to install any
software inside the virtual machine.  Supports Linux and Windows.
http://et.redhat.com/~rjones/virt-df/
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Koji buildroots broken by deltarpm at the moment?

[Jonathan Dieter]

On Tue, 2011-01-18 at 16:10 +0200, Panu Matilainen wrote:
 On Tue, 18 Jan 2011, Richard W.M. Jones wrote:
  DEBUG util.py:247:  ERROR with rpm_check_debug vs depsolve:
  DEBUG util.py:247:  librpm.so.1()(64bit) is needed by 
  deltarpm-3.6-0.4.20100708git.fc15.x86_64
  DEBUG util.py:247:  librpmio.so.1()(64bit) is needed by 
  deltarpm-3.6-0.4.20100708git.fc15.x86_64
 
 This only affects packages build-requiring (directly or through dependency 
 chains) on deltarpm or other packages that link to librpm, which haven't 
 been rebuilt yet (see yesterdays' heads-up:
 http://lists.fedoraproject.org/pipermail/devel/2011-January/147881.html)
 
 Deltarpm FTBS at the moment due to Python 3 changes. I dunno if Jonathan 
 is available to handle it but a provenpackager can fix it up easily by 
 temporarily disabling the python3 package (which is broken at anyway, see 
 http://lists.fedoraproject.org/pipermail/devel/2011-January/147920.html) 
 and then bump release + rebuild.

I am available and on it.  Didn't realize that it was affecting the
buildroot.  Will get it fixed ASAP.

Jonathan


signature.asc
Description: This is a digitally signed message part
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Koji buildroots broken by deltarpm at the moment?

[Richard W.M. Jones]

On Tue, Jan 18, 2011 at 04:50:17PM +0200, Jonathan Dieter wrote:
 On Tue, 2011-01-18 at 16:10 +0200, Panu Matilainen wrote:
  On Tue, 18 Jan 2011, Richard W.M. Jones wrote:
   DEBUG util.py:247:  ERROR with rpm_check_debug vs depsolve:
   DEBUG util.py:247:  librpm.so.1()(64bit) is needed by 
   deltarpm-3.6-0.4.20100708git.fc15.x86_64
   DEBUG util.py:247:  librpmio.so.1()(64bit) is needed by 
   deltarpm-3.6-0.4.20100708git.fc15.x86_64
  
  This only affects packages build-requiring (directly or through dependency 
  chains) on deltarpm or other packages that link to librpm, which haven't 
  been rebuilt yet (see yesterdays' heads-up:
  http://lists.fedoraproject.org/pipermail/devel/2011-January/147881.html)
  
  Deltarpm FTBS at the moment due to Python 3 changes. I dunno if Jonathan 
  is available to handle it but a provenpackager can fix it up easily by 
  temporarily disabling the python3 package (which is broken at anyway, see 
  http://lists.fedoraproject.org/pipermail/devel/2011-January/147920.html) 
  and then bump release + rebuild.
 
 I am available and on it.  Didn't realize that it was affecting the
 buildroot.  Will get it fixed ASAP.

Ah, I've just pushed this build which simply disables the Python 3
subpackage:

http://koji.fedoraproject.org/koji/taskinfo?taskID=2728751

It's a very minimal change to the spec file:

http://pkgs.fedoraproject.org/gitweb/?p=deltarpm.git;a=commitdiff;h=ed9a7fa440aa7caa3ef21cc37393e91304e3fd79

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming blog: http://rwmj.wordpress.com
Fedora now supports 80 OCaml packages (the OPEN alternative to F#)
http://cocan.org/getting_started_with_ocaml_on_red_hat_and_fedora
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Koji buildroots broken by deltarpm at the moment?

[Jonathan Dieter]

On Tue, 2011-01-18 at 14:53 +, Richard W.M. Jones wrote:
 On Tue, Jan 18, 2011 at 04:50:17PM +0200, Jonathan Dieter wrote:
  I am available and on it.  Didn't realize that it was affecting the
  buildroot.  Will get it fixed ASAP.
 
 Ah, I've just pushed this build which simply disables the Python 3
 subpackage:
 
 http://koji.fedoraproject.org/koji/taskinfo?taskID=2728751
 
 It's a very minimal change to the spec file:
 
 http://pkgs.fedoraproject.org/gitweb/?p=deltarpm.git;a=commitdiff;h=ed9a7fa440aa7caa3ef21cc37393e91304e3fd79
 
 Rich.

No problem.  Thanks much.

Jonathan


signature.asc
Description: This is a digitally signed message part
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Koji buildroots broken by deltarpm at the moment?

[Jonathan Dieter]

On Tue, 2011-01-18 at 14:53 +, Richard W.M. Jones wrote:
 Ah, I've just pushed this build which simply disables the Python 3
 subpackage:
 
 http://koji.fedoraproject.org/koji/taskinfo?taskID=2728751
 
 It's a very minimal change to the spec file:
 
 http://pkgs.fedoraproject.org/gitweb/?p=deltarpm.git;a=commitdiff;h=ed9a7fa440aa7caa3ef21cc37393e91304e3fd79
 
 Rich.

Ok, I've gone ahead and committed a build fix for python3-deltarpm based
on Toshio's advice at
http://lists.fedoraproject.org/pipermail/devel/2011-January/147542.html

Note that the python3-deltarpm module still doesn't actually work at the
moment, re
http://lists.fedoraproject.org/pipermail/devel/2011-January/147920.html

Panu, I will happily take you up on your offer to look at that whenever
you have time.

Jonathan


signature.asc
Description: This is a digitally signed message part
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel