On Mon, 26 Nov 2018 at 11:00, Christopher ctubbsii@fedoraproject.org wrote:
On Mon, Nov 26, 2018 at 7:12 AM Stephen John Smoogen smooge@gmail.com wrote:
On Mon, 26 Nov 2018 at 01:03, Christopher ctubbsii@fedoraproject.org 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@lists.fedoraproject.org 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.
For example, xorgxrdp-0.2.8-3.el7 depends on xorg-x11-server-Xorg 1.20.1, which isn't yet available (rather, available on in the cr repo, not in CentOS updates yet).
-- Stephen J Smoogen.
devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org 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/devel@lists.fedoraproject.org
On Mon, 26 Nov 2018, Stephen John Smoogen wrote:
On Mon, 26 Nov 2018 at 11:00, Christopher ctubbsii@fedoraproject.org wrote:
On Mon, Nov 26, 2018 at 7:12 AM Stephen John Smoogen smooge@gmail.com wrote:
On Mon, 26 Nov 2018 at 01:03, Christopher ctubbsii@fedoraproject.org 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@lists.fedoraproject.org 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): 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,
On 11/27/18 3:45 PM, me@tdiehl.org wrote:
On Mon, 26 Nov 2018, Stephen John Smoogen wrote:
On Mon, 26 Nov 2018 at 11:00, Christopher ctubbsii@fedoraproject.org wrote:
On Mon, Nov 26, 2018 at 7:12 AM Stephen John Smoogen smooge@gmail.com wrote:
On Mon, 26 Nov 2018 at 01:03, Christopher ctubbsii@fedoraproject.org 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@lists.fedoraproject.org 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,
On Tue, 27 Nov 2018, Manuel Wolfshant wrote:
On 11/27/18 3:45 PM, me@tdiehl.org wrote:
On Mon, 26 Nov 2018, Stephen John Smoogen wrote:
On Mon, 26 Nov 2018 at 11:00, Christopher ctubbsii@fedoraproject.org wrote:
On Mon, Nov 26, 2018 at 7:12 AM Stephen John Smoogen smooge@gmail.com wrote:
On Mon, 26 Nov 2018 at 01:03, Christopher ctubbsii@fedoraproject.org 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@lists.fedoraproject.org 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 ?
AAH, that was it. I forgot about the testing repo. :-)
Thanks for the help.
Regards,
epel-devel@lists.fedoraproject.org
-
Manuel Wolfshant -
me＠tdiehl.org -
Stephen John Smoogen