On Fri, Apr 27, 2012 at 09:14:51AM -0600, Kevin Fenzi wrote:
> On Fri, 27 Apr 2012 15:52:22 +0200
> Alan Pevec <apevec@gmail.com> wrote:
>
> > Hi all,
> >
> > this update shouldn't have been pushed b/c python-sphinx is in core
> > RHEL:
> > https://admin.fedoraproject.org/updates/FEDORA-EPEL-2011-5268/python-sphinx-1.0.8-1.el6
>
> Yeah. ;(
>
> Can you file a bug on it so the maintainer can end of life it?
>
> > Is there any check in place to prevent updates breaking the rule
> > https://fedoraproject.org/wiki/EPEL/GuidelinesAndPolicies#Policy_for_Conflicting_Packa ges
> > ?
>
> Nope. We have talked about setting something up, but it's not trivial
> to implement. ;( If you want to work on it, happy to help.
>
> > In the first place, I guess python-sphinx shouldn't have el6 branch
> > at all.
>
> Indeed. It should be dead.packaged.
>
dead.packaged and retired in the pkgdb
_______________________________________________
epel-devel-list mailing list
epel-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/epel-devel-list

yum-priorities


Sent from Xfinity Mobile App

-----Original Message-----
From: Alan Pevec
To: EPEL development disccusion
Sent: 2012-04-27 13:53:39 +0000
Subject: How to prevent accidental EPEL updates of RHEL-core packages?

Hi all,

this update shouldn't have been pushed b/c python-sphinx is in core RHEL:
https://admin.fedoraproject.org/updates/FEDORA-EPEL-2011-5268/python-sphinx-1.0.8-1.el6

Is there any check in place to prevent updates breaking the rule
https://fedoraproject.org/wiki/EPEL/GuidelinesAndPolicies#Policy_for_Conflicting_Packa ges
?

In the first place, I guess python-sphinx shouldn't have el6 branch at all.

Cheers,
Alan

_______________________________________________
epel-devel-list mailing list
epel-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/epel-devel-list
_______________________________________________
epel-devel-list mailing list
epel-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/epel-devel-list

On 04/27/2012 04:14 PM, Kevin Fenzi wrote:
>> Is there any check in place to prevent updates breaking the rule
>> https://fedoraproject.org/wiki/EPEL/GuidelinesAndPolicies#Policy_for_Conflicting_Packa ges
>> ?
>
> Nope. We have talked about setting something up, but it's not trivial
> to implement. ;( If you want to work on it, happy to help.

Wonder what the challenges are... it should be mostly just a case of a
white/black list matching on ${name}. We already do this against
CentOS/EPEL for both src.rpm content and binary content in i386/x86_64 (
and hopefully powerpc soon )

- KB

--
Karanbir Singh
+44-207-0999389 | http://www.karan.org/ | twitter.com/kbsingh
ICQ: 2522219 | Yahoo IM: z00dax | Gtalk: z00dax
GnuPG Key : http://www.karan.org/publickey.asc

_______________________________________________
epel-devel-list mailing list
epel-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/epel-devel-list

On Sat, Apr 28, 2012 at 12:28 AM, <ygor@comcast.net> wrote:
> yum-priorities

That doesn't help with Koji build roots which were carrying this wrong
Sphinx update and enabled few builds to succeed which should've failed
and are FTBFS now
e.g. https://bugzilla.redhat.com/show_bug.cgi?id=802153#c10

Cheers,
Alan

_______________________________________________
epel-devel-list mailing list
epel-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/epel-devel-list

On Fri, 27 Apr 2012 23:44:54 +0100
Karanbir Singh <mail-lists@karan.org> wrote:

> On 04/27/2012 04:14 PM, Kevin Fenzi wrote:
> >> Is there any check in place to prevent updates breaking the rule
> >> https://fedoraproject.org/wiki/EPEL/GuidelinesAndPolicies#Policy_for_Conflicting_Packa ges
> >> ?
> >
> > Nope. We have talked about setting something up, but it's not
> > trivial to implement. ;( If you want to work on it, happy to help.
>
> Wonder what the challenges are... it should be mostly just a case of a
> white/black list matching on ${name}. We already do this against
> CentOS/EPEL for both src.rpm content and binary content in
> i386/x86_64 ( and hopefully powerpc soon )

It likely will be easier with 6. On 5 it was unclear what of the many
channels to check against.

On 6 it's more clear what things we use and could check against.

If someone wants to write up such a script, or if CentOS folks are
willing to provide their script I could see about getting it
running here.

kevin
_______________________________________________
epel-devel-list mailing list
epel-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/epel-devel-list