[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Packages with same ENVR in stable and testing repos (Re: next testing -> stable move for EPEL4 and EPEL5 prepared, details inside)



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


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]