On 11/27/18 3:45 PM, me@xxxxxxxxxx wrote:
On Mon, 26 Nov 2018, Stephen John Smoogen wrote:
On Mon, 26 Nov 2018 at 11:00, Christopher
<ctubbsii@xxxxxxxxxxxxxxxxx> wrote:
On Mon, Nov 26, 2018 at 7:12 AM Stephen John Smoogen
<smooge@xxxxxxxxx> wrote:
On Mon, 26 Nov 2018 at 01:03, Christopher
<ctubbsii@xxxxxxxxxxxxxxxxx> wrote:
Anybody know what's going on with Centos 7.6-1810?
Some packages in EPEL depend on it, but it is apparently not yet
available.
This discrepancy is breaking yum updates for me.
This isn't a Fedora development issue. Please refer this to the CentOS
or EPEL lists.
EPEL is a Fedora project. My question wasn't really about CentOS, but
rather, about maintainer best practices for EPEL branches. To clarify,
my question is whether package maintainers are expected to ensure
their EPEL branch for their packages works against the latest CentOS
release (without enabling 'cr' repo) or whether it is expected that
packages will work as soon as the corresponding RHEL release is
available (which is usually available about 3-4 weeks earlier). What
do we use for the EPEL buildroot in koji?
Even though EPEL is a Fedora project, the main development and work is
done on the epel-devel@xxxxxxxxxxxxxxxxxxxxxxx mailing list.
EPEL is built from the 'current' state of Red Hat Enterprise Linux as
synced from 'rhn (or whatever they call it these days)' every 12
hours. This means that CentOS users must use CR during the
intermediate time.
Based on the above, can you tell me if the following yum errors are
caused by epel or the centos cr repo mising the proper deps?
(tigger pts9) # yum clean metadata ; yum update
Loaded plugins: changelog, fastestmirror, langpacks, priorities
Cleaning repos: base cr epel extras fasttrack google-chrome nux-dextop
updates
27 metadata files removed
9 sqlite files removed
0 metadata files removed
Loaded plugins: changelog, fastestmirror, langpacks, priorities
Loading mirror speeds from cached hostfile
base | 3.6 kB 00:00:00 cr | 3.4 kB 00:00:00 epel | 3.2 kB 00:00:00
extras | 3.4 kB 00:00:00 fasttrack | 3.3 kB 00:00:00 google-chrome |
1.3 kB 00:00:00 nux-dextop | 2.9 kB 00:00:00 updates | 3.4 kB
00:00:00 (1/14):
I notice that you did not enable the epel-testing repository. Can you
please retry after enabling it ?
wolfy
base/group_gz | 166 kB 00:00:00 (2/14): base/primary_db | 5.9 MB
00:00:00 (3/14): cr/primary_db | 3.2 MB 00:00:00 (4/14):
TNTechs/7/x86_64/primary_db | 12 kB 00:00:00 (5/14):
epel/7/x86_64/group_gz | 88 kB 00:00:00 (6/14):
adobe-linux-x86_64/primary_db | 2.7 kB 00:00:00 (7/14):
epel/7/x86_64/primary | 3.6 MB 00:00:00 (8/14):
epel/7/x86_64/updateinfo | 932 kB 00:00:00 (9/14):
fasttrack/primary_db | 1.1 kB 00:00:00 (10/14): extras/primary_db |
205 kB 00:00:00 (11/14): updates/primary_db | 6.0 MB 00:00:00
(12/14): google-chrome/primary | 1.9 kB 00:00:00 (13/14):
Xymon/7/x86_64/primary_db | 64 kB 00:00:00 (14/14):
nux-dextop/x86_64/primary_db | 1.8 MB 00:00:01 epel 12719/12719
google-chrome 3/3
518 packages excluded due to repository priority protections
Resolving Dependencies
--> Running transaction check
---> Package GeoIP.x86_64 0:1.5.0-11.el7 will be updated
---> Package GeoIP.x86_64 0:1.5.0-13.el7 will be an update
---> Package NetworkManager.x86_64 1:1.10.2-16.el7_5 will be updated
...
-> Finished Dependency Resolution
Error: Package: mate-system-monitor-1.16.0-1.el7.x86_64 (@epel)
Requires: libgtop-2.0.so.10()(64bit)
Removing: libgtop2-2.34.2-2.el7.x86_64 (@cr)
libgtop-2.0.so.10()(64bit)
Updated By: libgtop2-2.38.0-3.el7.x86_64 (cr)
~libgtop-2.0.so.11()(64bit)
Error: Package: mate-disk-usage-analyzer-1.16.1-1.el7.x86_64 (@epel)
Requires: libgtop-2.0.so.10()(64bit)
Removing: libgtop2-2.34.2-2.el7.x86_64 (@cr)
libgtop-2.0.so.10()(64bit)
Updated By: libgtop2-2.38.0-3.el7.x86_64 (cr)
~libgtop-2.0.so.11()(64bit)
Error: Package: marco-1.16.1-3.el7.x86_64 (@epel)
Requires: libgtop-2.0.so.10()(64bit)
Removing: libgtop2-2.34.2-2.el7.x86_64 (@cr)
libgtop-2.0.so.10()(64bit)
Updated By: libgtop2-2.38.0-3.el7.x86_64 (cr)
~libgtop-2.0.so.11()(64bit)
Error: Package: mate-applets-1.16.0-1.el7.x86_64 (@epel)
Requires: libgtop-2.0.so.10()(64bit)
Removing: libgtop2-2.34.2-2.el7.x86_64 (@cr)
libgtop-2.0.so.10()(64bit)
Updated By: libgtop2-2.38.0-3.el7.x86_64 (cr)
~libgtop-2.0.so.11()(64bit)
You could try using --skip-broken to work around the problem
You could try running: rpm -Va --nofiles --nodigest
(tigger pts9) # rpm -Va --nofiles --nodigest
(tigger pts9) #
I am not sure where to report this. Is this is a case of epel has not
caught
up to centos yet or is something else going on here?
Regards,
_______________________________________________
epel-devel mailing list -- epel-devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to epel-devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/epel-devel@xxxxxxxxxxxxxxxxxxxxxxx
