Packages with same ENVR in stable and testing repos (Re: next testing -> stable move for EPEL4 and EPEL5 prepared, details inside)
Thorsten Leemhuis
fedora at leemhuis.info
Thu Feb 12 18:39:50 UTC 2009
On 08.02.2009 13:51, Thorsten Leemhuis wrote:
> I prepared the next testing -> stable move for EPEL4 and EPEL5. I plan
> to actually do the move on 20090212 at around 06:00 UTC.
Did the move earlier today. There were a lot of warnings like:
----
> python-ruledispatch
> python-ruledispatch-0.5a0-0.8.svnr2306.el5.ppc.rpm -> ppc
> WARNING: /srv/rpmbuild/epel/tree/epel/5/ppc/python-ruledispatch-0.5a0-0.8.svnr2306.el5.ppc.rpm already exists, ignoring new one
----
Here is the full list:
epel4: obby-0.4.4-2.el4.src.rpm
epel4: net6-1.3.5-1.el4.src.rpm
epel4: perl-Filesys-Df-0.92-3.el4.src.rpm
epel4: libmp4v2-1.5.0.1-6.el4.src.rpm
epel4: perl-Test-Pod-Coverage-1.08-1.el4.src.rpm
epel4: erlang-R11B-2.3.el4.src.rpm
epel4: perl-String-CRC32-1.4-1.el4.src.rpm
epel4: perl-Math-FFT-1.28-1.el4.src.rpm
epel4: perl-XML-Filter-BufferText-1.01-4.el4.src.rpm
epel5: python-ruledispatch-0.5a0-0.8.svnr2306.el5.src.rpm
epel5: perl-Heap-0.80-1.el5.src.rpm
epel5: perl-XML-Filter-BufferText-1.01-2.el5.src.rpm
epel5: mingw32-w32api-3.12-8.el5.src.rpm
epel5: python-dns-1.6.0-2.el5.src.rpm
epel5: perl-Class-Inspector-1.17-1.el5.src.rpm
epel5: python-configobj-4.4.0-2.el5.src.rpm
epel5: perl-Test-Perl-Critic-1.01-1.el5.src.rpm
epel5: python-libgmail-docs-0.3-6.el5.src.rpm
epel5: dtc-1.1.0-1.el5.src.rpm
epel5: net6-1.3.5-1.el5.src.rpm
epel5: R-car-1.2-2.el5.src.rpm
epel5: perl-Math-FFT-1.28-1.el5.src.rpm
epel5: docbook2X-0.8.8-1.el5.src.rpm
epel5: python-libgmail-0.1.8-2.el5.src.rpm
epel5: perl-Algorithm-Annotate-0.10-6.el5.src.rpm
epel5: python-turboflot-0.1.0-1.el5.src.rpm
epel5: unbound-1.0.2-5.el5.src.rpm
Does anybody mind if I delete those from testing? Or do we want to force
rebuild on those to make sure we know which packages users have
installed? And does anyone volunteer to tell packagers why doing
something that leads to above problems is bad?
CU
knurd
More information about the epel-devel-list
mailing list