[EPEL-devel] Re: Packaging issue with nodejs and mongodb-server
MongoDB was retired from Fedora and epel7 a couple of years ago, due to the license issues. Thus there is no longer a mongodb-server in epel7.https://bugzilla.redhat.com/show_bug.cgi?id=1855725 Problem: nodejs had a major update in epel7, and mongodb relies on the v8 in nodejs. Why the major update? v8 Security issues. v8-3.14 (libv8.so.3) hasn't had any official security updates in 6 years. v8 is the javascript engine for a browser, and as such, needs to be updated constantly because it touches so many things. It was announced that it was being obsoleted by nodejs, but it was part of the nodejs announcement, so you might not have seen it. We apologize for this. But in the end, it was no longer safe to be using the old nodejs and the old v8. Solution: At this point, we recommend you update your mongodb server from mongodb the company. It is still free for a majority of use cases.https://docs.mongodb.com/manual/tutorial/install-mongodb-on-red-hat/ On Tue, Mar 15, 2022 at 7:36 AM Nick Howitt via epel-devel < epel-devel@lists.fedoraproject.org> wrote: > Hi, > With the major bump to nodejs, I believe a conflict has been created > between nodejs-libs and mongodb: > > [root@services26 ~]# yum install mongodb-server > Loaded plugins: clearcenter-marketplace, fastestmirror > ClearCenter Marketplace: fetching repositories... > Loading mirror speeds from cached hostfile > > Resolving Dependencies > --> Running transaction check > ---> Package mongodb-server.x86_64 0:2.6.12-6.el7 will be installed > --> Processing Dependency: v8 for package: > mongodb-server-2.6.12-6.el7.x86_64 > --> Processing Dependency: libyaml-cpp.so.0.5()(64bit) for package: > mongodb-server-2.6.12-6.el7.x86_64 > --> Processing Dependency: libv8.so.3()(64bit) for package: > mongodb-server-2.6.12-6.el7.x86_64 > Package v8 is obsoleted by nodejs-libs, but obsoleting package does not > provide for requirements > --> Processing Dependency: libtcmalloc.so.4()(64bit) for package: > mongodb-server-2.6.12-6.el7.x86_64 > --> Processing Dependency: libstemmer.so.0()(64bit) for package: > mongodb-server-2.6.12-6.el7.x86_64 > --> Processing Dependency: libboost_thread-mt.so.1.53.0()(64bit) for > package: mongodb-server-2.6.12-6.el7.x86_64 > --> Processing Dependency: libboost_system-mt.so.1.53.0()(64bit) for > package: mongodb-server-2.6.12-6.el7.x86_64 > --> Processing Dependency: > libboost_program_options-mt.so.1.53.0()(64bit) for package: > mongodb-server-2.6.12-6.el7.x86_64 > --> Processing Dependency: libboost_filesystem-mt.so.1.53.0()(64bit) for > package: mongodb-server-2.6.12-6.el7.x86_64 > --> Running transaction check > ---> Package boost-filesystem.x86_64 0:1.53.0-28.el7 will be installed > ---> Package boost-program-options.x86_64 0:1.53.0-28.el7 will be installed > ---> Package boost-system.x86_64 0:1.53.0-28.el7 will be installed > ---> Package boost-thread.x86_64 0:1.53.0-28.el7 will be installed > ---> Package gperftools-libs.x86_64 0:2.6.1-1.el7 will be installed > ---> Package libstemmer.x86_64 0:0-2.585svn.el7 will be installed > ---> Package mongodb-server.x86_64 0:2.6.12-6.el7 will be installed > --> Processing Dependency: libv8.so.3()(64bit) for package: > mongodb-server-2.6.12-6.el7.x86_64 > Package v8 is obsoleted by nodejs-libs, but obsoleting package does not > provide for requirements > ---> Package nodejs-libs.x86_64 1:16.14.0-2.el7 will be installed > --> Processing Dependency: libssl.so.1.1(OPENSSL_1_1_1)(64bit) for > package: 1:nodejs-libs-16.14.0-2.el7.x86_64 > --> Processing Dependency: libssl.so.1.1(OPENSSL_1_1_0)(64bit) for > package: 1:nodejs-libs-16.14.0-2.el7.x86_64 > --> Processing Dependency: libcrypto.so.1.1(OPENSSL_1_1_1e)(64bit) for > package: 1:nodejs-libs-16.14.0-2.el7.x86_64 > --> Processing Dependency: libcrypto.so.1.1(OPENSSL_1_1_1b)(64bit) for > package: 1:nodejs-libs-16.14.0-2.el7.x86_64 > --> Processing Dependency: libcrypto.so.1.1(OPENSSL_1_1_1)(64bit) for > package: 1:nodejs-libs-16.14.0-2.el7.x86_64 > --> Processing Dependency: libcrypto.so.1.1(OPENSSL_1_1_0g)(64bit) for > package: 1:nodejs-libs-16.14.0-2.el7.x86_64 > --> Processing Dependency: libcrypto.so.1.1(OPENSSL_1_1_0)(64bit) for > package: 1:nodejs-libs-16.14.0-2.el7.x86_64 > --> Processing Dependency: libuv.so.1()(64bit) for package: > 1:nodejs-libs-16.14.0-2.el7.x86_64 > --> Processing Dependency: libssl.so.1.1()(64bit) for package: > 1:nodejs-libs-16.14.0-2.el7.x86_64 > --> Processing Dependency: libcrypto.so.1.1()(64bit) for package: > 1:nodejs-libs-16.14.0-2.el7.x86_64 > --> Processing Dependency: libbrotlienc.so.1()(64bit) for package: > 1:nodejs-libs-16.14.0-2.el7.x86_64 > --> Processing Dependency: libbrotlidec.so.1()(64bit) for package: > 1:nodejs-libs-16.14.0-2.el7.x86_64 > ---> Package yaml-cpp.x86_64 1:0.5.1-2.el7 will be installed > --> Running transaction check > ---> Package brotli.x86_64 0:1.0.7-5.el7 will be installed > ---> Package libuv.x86_64 1:1.43.0-2.el7 will be installed > ---> Package mongodb-server.x86_64
[EPEL-devel] Packaging issue with nodejs and mongodb-server
Hi, With the major bump to nodejs, I believe a conflict has been created between nodejs-libs and mongodb: [root@services26 ~]# yum install mongodb-server Loaded plugins: clearcenter-marketplace, fastestmirror ClearCenter Marketplace: fetching repositories... Loading mirror speeds from cached hostfile Resolving Dependencies --> Running transaction check ---> Package mongodb-server.x86_64 0:2.6.12-6.el7 will be installed --> Processing Dependency: v8 for package: mongodb-server-2.6.12-6.el7.x86_64 --> Processing Dependency: libyaml-cpp.so.0.5()(64bit) for package: mongodb-server-2.6.12-6.el7.x86_64 --> Processing Dependency: libv8.so.3()(64bit) for package: mongodb-server-2.6.12-6.el7.x86_64 Package v8 is obsoleted by nodejs-libs, but obsoleting package does not provide for requirements --> Processing Dependency: libtcmalloc.so.4()(64bit) for package: mongodb-server-2.6.12-6.el7.x86_64 --> Processing Dependency: libstemmer.so.0()(64bit) for package: mongodb-server-2.6.12-6.el7.x86_64 --> Processing Dependency: libboost_thread-mt.so.1.53.0()(64bit) for package: mongodb-server-2.6.12-6.el7.x86_64 --> Processing Dependency: libboost_system-mt.so.1.53.0()(64bit) for package: mongodb-server-2.6.12-6.el7.x86_64 --> Processing Dependency: libboost_program_options-mt.so.1.53.0()(64bit) for package: mongodb-server-2.6.12-6.el7.x86_64 --> Processing Dependency: libboost_filesystem-mt.so.1.53.0()(64bit) for package: mongodb-server-2.6.12-6.el7.x86_64 --> Running transaction check ---> Package boost-filesystem.x86_64 0:1.53.0-28.el7 will be installed ---> Package boost-program-options.x86_64 0:1.53.0-28.el7 will be installed ---> Package boost-system.x86_64 0:1.53.0-28.el7 will be installed ---> Package boost-thread.x86_64 0:1.53.0-28.el7 will be installed ---> Package gperftools-libs.x86_64 0:2.6.1-1.el7 will be installed ---> Package libstemmer.x86_64 0:0-2.585svn.el7 will be installed ---> Package mongodb-server.x86_64 0:2.6.12-6.el7 will be installed --> Processing Dependency: libv8.so.3()(64bit) for package: mongodb-server-2.6.12-6.el7.x86_64 Package v8 is obsoleted by nodejs-libs, but obsoleting package does not provide for requirements ---> Package nodejs-libs.x86_64 1:16.14.0-2.el7 will be installed --> Processing Dependency: libssl.so.1.1(OPENSSL_1_1_1)(64bit) for package: 1:nodejs-libs-16.14.0-2.el7.x86_64 --> Processing Dependency: libssl.so.1.1(OPENSSL_1_1_0)(64bit) for package: 1:nodejs-libs-16.14.0-2.el7.x86_64 --> Processing Dependency: libcrypto.so.1.1(OPENSSL_1_1_1e)(64bit) for package: 1:nodejs-libs-16.14.0-2.el7.x86_64 --> Processing Dependency: libcrypto.so.1.1(OPENSSL_1_1_1b)(64bit) for package: 1:nodejs-libs-16.14.0-2.el7.x86_64 --> Processing Dependency: libcrypto.so.1.1(OPENSSL_1_1_1)(64bit) for package: 1:nodejs-libs-16.14.0-2.el7.x86_64 --> Processing Dependency: libcrypto.so.1.1(OPENSSL_1_1_0g)(64bit) for package: 1:nodejs-libs-16.14.0-2.el7.x86_64 --> Processing Dependency: libcrypto.so.1.1(OPENSSL_1_1_0)(64bit) for package: 1:nodejs-libs-16.14.0-2.el7.x86_64 --> Processing Dependency: libuv.so.1()(64bit) for package: 1:nodejs-libs-16.14.0-2.el7.x86_64 --> Processing Dependency: libssl.so.1.1()(64bit) for package: 1:nodejs-libs-16.14.0-2.el7.x86_64 --> Processing Dependency: libcrypto.so.1.1()(64bit) for package: 1:nodejs-libs-16.14.0-2.el7.x86_64 --> Processing Dependency: libbrotlienc.so.1()(64bit) for package: 1:nodejs-libs-16.14.0-2.el7.x86_64 --> Processing Dependency: libbrotlidec.so.1()(64bit) for package: 1:nodejs-libs-16.14.0-2.el7.x86_64 ---> Package yaml-cpp.x86_64 1:0.5.1-2.el7 will be installed --> Running transaction check ---> Package brotli.x86_64 0:1.0.7-5.el7 will be installed ---> Package libuv.x86_64 1:1.43.0-2.el7 will be installed ---> Package mongodb-server.x86_64 0:2.6.12-6.el7 will be installed --> Processing Dependency: libv8.so.3()(64bit) for package: mongodb-server-2.6.12-6.el7.x86_64 Package v8 is obsoleted by nodejs-libs, but obsoleting package does not provide for requirements ---> Package openssl11-libs.x86_64 1:1.1.1k-2.el7 will be installed --> Finished Dependency Resolution Error: Package: mongodb-server-2.6.12-6.el7.x86_64 (clearos-epel) Requires: libv8.so.3()(64bit) Available: 1:v8-3.14.5.10-25.el7.x86_64 (clearos-epel) libv8.so.3()(64bit) You could try using --skip-broken to work around the problem You could try running: rpm -Va --nofiles --nodigest [root@services26 ~]# Is there a missing "provides" in the updated nodejs-libs or something else? Thanks, Nick ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives:
[EPEL-devel] Re: RHEL moving to issues.redhat.com only long term
On Mon, Mar 14, 2022 at 2:59 PM Dan Čermák wrote: > > Hi Adam, > > Adam Williamson writes: > > > snip > > > That could obviously have pretty significant consequences for Fedora. > > Bugzilla isn't only an issue tracker for Fedora; we run some > > significant processes through it, notably the Change process, the > > blocker/FE bug process, and the prioritized bug process. In A World > > Without Bugzilla all of those would need adapting (and their > > documentation updating). There's fairly tight integration between Bodhi > > and Bugzilla, which would need to be redesigned. Those are just things > > I can think of off the top of my head. There are also a couple of > > decades worth of internet links to Fedora issues on RH Bugzilla, of > > course. > > > > I guess the two big choices for Fedora if RH said "we're not > > maintaining Bugzilla any more" would be 1) take over maintaining > > Bugzilla or 2) switch to something else. 1) would probably be the path > > of least resistance, I guess. > > Short term it is the path of the least resistance, but at least what > I've heard from $dayjob, maintaining a Bugzilla instance is no easy > task, as they are often customized (via non-upstream patches) and this > all needs to be maintained. I cannot speak for our infra team, but I > really don't know if they'd like yet another huge service, because this > effectively means they'd have to take over maintenance of > bugzilla.redhat.com... > > > > > This does also kinda lead to a larger question for me, trying to wear > > both Red Hat and Fedora hats at the same time[0]. I wonder if we're > > kind of lacking a...mechanism, for want of a better word, to handle the > > *generic* case here. Let's rewind to Ye Olde Days, when "the Fedora > > project" first started. At that point Fedora and Red Hat shared a lot > > of tooling and infrastructure, and this was useful to both sides in > > many ways; it saves on development costs and it makes it easy for > > people to work in both worlds. With my Red Hat on, I think I'm allowed > > to say that internally we often talk about this being desirable - > > having consistency between how X is done in Fedora and how it's done > > for RHEL - and it obviously has benefits to Fedora too (it means we > > don't have to find the resources to do that same work at Fedora level). > > > > However, situations like this make me wonder if we might have an issue > > with keeping shared infra/tooling where it's desirable. It seems like > > this is a decision/conversation that's been happening within RH, about > > what makes sense for RH in terms of RHEL development. AFAIK this is the > > first time it's been formally talked about in a Fedora context, and the > > messaging is "RH has already decided to stop using Bugzilla for RHEL > > after 9". In other words, RH has decided on its own to move away from > > something that is part of the shared RH/Fedora "heritage way of doing > > things". > > > > I'm not saying that's wrong, but as I said it does make me wonder > > whether, if both sides do find shared tooling/approaches beneficial, we > > might want to approach this kind of potential change differently in > > future. Otherwise it does seem like we could sort of gradually drift > > apart, with no explicit intention to do so, and lose the benefits of > > shared tooling and process. Unless the ultimate outcome of this is > > "Fedora adopts issues.redhat.com for bug tracking" - which would be a > > possibility, but doesn't seem like a certainty - the result will be > > that we go from having a shared bug tracker, with the benefits of > > shared maintenance and being able to easily clone or reference bugs > > between Fedora and RHEL, to each maintaining our own bug tracker and > > not having those benefits. > > > > Of course, there would be sensitivities in developing such a process - > > it could look a lot like Red Hat telling Fedora how to do stuff, which > > I think isn't exactly the relationship we want to have. But at the same > > time I'm not sure "Red Hat or Fedora just deciding unilaterally to stop > > using this thing they'd previously both used" is always the best choice > > either. > > No, certainly not. I think it would have been nice if the tooling > discussion happened before RH decided to drop Bugzilla so that we can > all use a common tooling. However, I also know that in a business RHEL is choosing not to use Bugzilla for future versions of RHEL. I need to be clear in wording there, because Red Hat is a company, RHEL is one of its products, and we're only talking about newer versions of that product. I am not aware of any plans for Red Hat to drop Bugzilla. I am aware of plans for newer versions of RHEL to no longer use Bugzilla. > sometimes reaching such a consensus is everything but easy. It would > have been nice if someone at least tried though. Tried what, to be precise? If you mean try to find common tooling between Fedora and RHEL, well we have off and on for years.
[EPEL-devel] Re: RHEL moving to issues.redhat.com only long term
On Mon, Mar 14, 2022 at 11:12 AM Adam Williamson wrote: > > On Mon, 2022-03-07 at 12:44 -0500, Josh Boyer wrote: > > Hi Fedora, CentOS, and EPEL Communities! > > > > As part of our continued 3 year major Red Hat Enterprise Linux release > > cadence, RHEL 9 development is starting to wrap up with the spring > > 2022 release coming soon. That means planning for the next release > > will start in earnest in the very near future. As some of you may > > know, Red Hat has been using both Bugzilla and Jira via > > issues.redhat.com for RHEL development for several years. Our > > intention is to move to using issues.redhat.com only for the major > > RHEL releases after RHEL 9. > > > > What does this mean for Fedora and CentOS? This discussion is in part > > to figure that out. Based on some very brief analysis, the following > > should hold: > > > > - RHEL customers should continue to file support cases through the Red > > Hat Customer portal, which will remain consistent regardless of the > > backend tooling used. > > > > - There is no imminent retirement of the Red Hat Bugzilla instance > > being planned at this time. RHEL 7, 8, and 9 will continue to use > > bugzilla in some form and RHEL 9 has a very long lifecycle. > > > > - Fedora Linux and EPEL have their own Bugzilla product families and > > are not directly impacted in their own workflows by the choice to use > > only issues.redhat.com for RHEL. > > - There will be impacts on existing documentation that provide > > guidance on requesting things from RHEL in various places like EPEL. > > We will be happy to help adjust these. > > > > - CentOS Stream contribution and bug reporting workflows will be > > adjusted to use issues.redhat.com instead of bugzilla in the relevant > > places. This should apply to all versions of CentOS Stream for a > > unified contributor workflow. This will happen gradually as we > > discover the best workflow to use. > > > > If there are other impacts that you can think of, please raise them on > > this thread. We’d like to ensure we’re covering as much as possible > > as this rolls out. > > So if I'm understanding this correctly, the ultimate consequence here > is "Red Hat Bugzilla might go away, or stop being maintained, at > whatever point it's no longer needed for RHEL 9", right? I have no idea, to be honest. There's a lot of assumption in that statement and it certainly could be an outcome, but I'm not aware of any plans towards that directly. > That could obviously have pretty significant consequences for Fedora. > Bugzilla isn't only an issue tracker for Fedora; we run some > significant processes through it, notably the Change process, the > blocker/FE bug process, and the prioritized bug process. In A World > Without Bugzilla all of those would need adapting (and their > documentation updating). There's fairly tight integration between Bodhi > and Bugzilla, which would need to be redesigned. Those are just things > I can think of off the top of my head. There are also a couple of > decades worth of internet links to Fedora issues on RH Bugzilla, of > course. Those all sound like the things I'm familiar with. > I guess the two big choices for Fedora if RH said "we're not > maintaining Bugzilla any more" would be 1) take over maintaining > Bugzilla or 2) switch to something else. 1) would probably be the path > of least resistance, I guess. > > This does also kinda lead to a larger question for me, trying to wear > both Red Hat and Fedora hats at the same time[0]. I wonder if we're > kind of lacking a...mechanism, for want of a better word, to handle the > *generic* case here. Let's rewind to Ye Olde Days, when "the Fedora > project" first started. At that point Fedora and Red Hat shared a lot > of tooling and infrastructure, and this was useful to both sides in > many ways; it saves on development costs and it makes it easy for > people to work in both worlds. With my Red Hat on, I think I'm allowed > to say that internally we often talk about this being desirable - > having consistency between how X is done in Fedora and how it's done > for RHEL - and it obviously has benefits to Fedora too (it means we > don't have to find the resources to do that same work at Fedora level). Fedora and RHEL process and tooling has deviated significantly over the years. So much so that by the time I joined the RHEL team, it was already very different. That was almost 5 years ago, which means the individual decisions that led to it were even earlier. I don't really want to revisit those decisions because I wasn't around and can't speak to why they were made, but the connection between Fedora and RHEL via bugzilla is minimal at best. The commonality that brings the most shared benefit is the activities of our communities, the quality and rigor they bring into Fedora, and the sources we share. Tooling and process are orthogonal to those. Important, because they certainly lend themselves to aiding that quality and
