[CentOS] dlopen RTD_LAZY and RTLD_GLOBAL
All, I use a code which has a python (I use python36) wrapper loading shared libraries. The code worked fine in RHEL 7 but as I was testing it on Centos 8, python cannot import the shared library (the import is done via dlopen with flags set as sys.setdlopenflags(os.RTLD_LAZY | os.RTLD_GLOBAL) python then does a bunch of imports and most results in a shared library with indefined symbols. Somthing like: from .w3dpy import * ImportError: /usr/local/lib64/python3.6/site-packages/warp/w3dpy.cpython-36m-x86_64-linux-gnu.so: undefined symbol: multigridxyf2_ The codes works fine on Scientific Linux 7 but had the same problem as above on fedora 31. I suspect something changed in the way dlopen is handled on newer linux version but cannot figure out how the code should be modified... Thank you for any help. All the best, -- Philippe. ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
[CentOS] DebugInfo repo broken on purpose
This line in /etc/yum.repos.d/CentOS-Debuginfo.repo baseurl=http://debuginfo.centos.org/$releasever/$basearch/ …causes commands like “yum search --enablerepo=* foo” to fail with the obscure error Error: Failed to synchronize cache for repo 'base-debuginfo' Apparently this is because the debug info RPMs aren’t hosted there any more, per the page at the top of the site. However, when I edit that file to point to the Facebook mirror linked from the top of the debuginfo.centos.org site, I get the same error, even after assorted remediations: dnf makecache, dnf update, etc. Any ideas on how to fix it, hopefully in a way that lands in a CentOS 8.next, so it doesn’t have to be fixed manually? And in the meantime, is there a short syntax for “search all repos other than the debuginfo ones”? I could list every repo in a comma-separated list, but ugh. ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS-virt] Xen Version update policy
On 2019-12-13 04:54, Kevin Stange wrote: I don't want to burden Steven Haigh any, but I wonder if there's a way we could combine some of our efforts to make both "Xen made easy!" and the Virt SIG Xen easier to manage. I've been thinking about this for a while. The problem has been the workflows between myself and the SIG are so far apart, its hard to look at how to merge them. I have full CI between my own git and packages to the mirrors - which is good, but has its down sides. I also don't have the restrictions of the CentOS build system to deal with - which is great for my workflow ;) I'm prepping packages for CentOS 8 now - but its exposing quite a number of problems around the main toolsets for Xen - and instead of just adding my own patch and moving on (ala Fedora's Xen packages), I'm trying to get fixes in upstream where possible. My todo list currently includes: 1) Replace all #! that include env python to a specific python version/binary. ie /usr/bin/python or /usr/bin/python3. The configure portions of this are complete, but the scripts need to be altered to have the detected python version populated. 2) There's no brctl in CentOS 8. The network scripts need to be re-written to use 'ip' instead. To maintain compatibility, the network scripts need to support both brctl and ip commands and use whichever is present on the system. 3) UEFI support needs to be tested. The preferred UEFI boot method for Dom0 is to use grub to then boot Xen - but this needs to be tested. So while me moving to try and get these fixed upstream is great - it should make everyone's job easier in the long term. Although I have the same problem as the SIG - there's just not enough people to test / patch stuff. The more we deep dive into 4.13, the further away I can see the release happening :( -- Steven Haigh ? net...@crc.id.au ? https://www.crc.id.au ___ CentOS-virt mailing list CentOS-virt@centos.org https://lists.centos.org/mailman/listinfo/centos-virt
[CentOS] log4j12 package in CentOS 8
According to the RHEL docs, package log4j was replaced with package log4j12 in RHEL 8.0. However, when I attempt to install the package in CentOS 8, dnf cannot find it. I have the Base, AppStream, Extras and PowerTools repos enabled. What am I doing wrong? Thanks! ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS-virt] Xen Version update policy
On 12/12/19 8:25 AM, George Dunlap wrote: > On Mon, Dec 2, 2019 at 5:08 PM Kevin Stange wrote: >> I don't really think we should drop a release before its security >> support ends, unless we have *really clear* communication to repo users >> as to the life cycles of these builds in advance. > > Indeed, the purpose of this email is in fact to make such a clear > communication. Citrix (i.e., Anthony & I) have committed to providing > up-to-date packages for one version at a time; this is meant to give > people input into which version that is. The Virt SIG cannot as a > whole commit to supporting releases until security support ends unless > others step up and make commitments to do so. We should probably provide a matrix of which Xen versions are offered by the SIG, who is maintaining them, and when they will last be supported (roughly if it's not 100% clear due to upstream scheduling). There's a bunch of legacy Xen4CentOS and other confusing Xen docs in the CentOS documentation that need to be cleaned up, removed, or unified. I'm happy to continue working on and testing releases for whichever branch I'm currently on (which is 4.8 right now, but I'm moving on since upstream is done with security support). However I can't make commitments to support or test versions I am not actively running in production, nor provide specific life cycle guarantees. I made that mistake with 4.4, though meltdown was an extenuating circumstance; I simply couldn't handle that kind of backport myself. That said, I *may* offer continued support and testing for 4.12 when 4.14's release pushes it out of maintenance by Virt SIG. That's something I'm going to have to play by ear, I guess. I don't want to burden Steven Haigh any, but I wonder if there's a way we could combine some of our efforts to make both "Xen made easy!" and the Virt SIG Xen easier to manage. -- Kevin Stange Chief Technology Officer Steadfast | Managed Infrastructure, Datacenter and Cloud Services 800 S Wells, Suite 190 | Chicago, IL 60607 312.602.2689 X203 | Fax: 312.602.2688 ke...@steadfast.net | www.steadfast.net ___ CentOS-virt mailing list CentOS-virt@centos.org https://lists.centos.org/mailman/listinfo/centos-virt
Re: [CentOS] CentOS 7 Plus Kernel Update Missing?
> -Original Message- > From: CentOS [mailto:centos-boun...@centos.org] On Behalf Of Akemi Yagi > Sent: Thursday, December 12, 2019 11:59 AM > To: CentOS mailing list > Subject: Re: [CentOS] CentOS 7 Plus Kernel Update Missing? > > > Along with the recent kernel update (3.10.0-1062.9.1.el7), the > CentOS 7 plus kernel was likewise updated. The plus kernel though hasn't > shown up in the mirrors yet, while the plain kernel has. Could someone > please push the release button for the plus kernel? > > > > That "someone" is Johnny Hughes. :) > > The release button pushed today. Thanks! Albert McCann -- Experience varies directly with equipment ruined. ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] CentOS 7 Plus Kernel Update Missing?
On Sun, Dec 8, 2019 at 8:34 AM Akemi Yagi wrote: > > On Sun, Dec 8, 2019 at 5:50 AM Albert McCann > wrote: > > > > Along with the recent kernel update (3.10.0-1062.9.1.el7), the CentOS 7 > > plus kernel was likewise updated. The plus kernel though hasn't shown up in > > the mirrors yet, while the plain kernel has. Could someone please push the > > release button for the plus kernel? > > That "someone" is Johnny Hughes. :) The release button pushed today. Akemi ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS-virt] Xen Version update policy
On Thu, Nov 28, 2019 at 6:12 PM George Dunlap wrote: > > Hey all, > > This mail has been a long time in coming, but with the upcoming > expiration of security support for Xen 4.8, it's time to start thinking > about what our update policy will be for the Xen packages in general. > > Citrix is committed to officially supporting one Xen version at a time > through the CentOS Virt SIG. (Others in the community are welcome to > support others.) But we'd like input as to which version the community > would like to be supported at any one time. > > Please express your opinion on each option by replying as follows: > -2: This is a bad idea, and I would argue against this > -1: I'm not happy with this, but I wouldn't argue against this. > 0: No opinion. > 1: I'm happy with this, but I wouldn't argue for it. > 2: This is a great idea, and I'd argue for it. > > There are several possible options: > > 1. Always support the newest option. This means we get all the newest > features from Xen in the Virt SIG by default; but also means we get all > the newest bugs. > > 1a. Always support the newest option once it has at least one point > release. This balances the newness with a bit of extra testing. > > 1b. Always support the second-to-newest version (e.g., when 4.13 comes > out, switch to 4.12.x) > > 2. Always support the oldest security-supported version. This means we > get the most stable version of Xen; but it does mean it is several years > behind as far as features go. It also means that further bugfixes do > not happen automatically, and further bugs found will need to be > > 3. Always support the oldest fully-supported version. Reasonably > stable, reasonably old, still gets bugfixes. > > 4. Support a version until it's out of security support, then jump to > the newest version. This minimizes the number of upgrades required > (although may make each upgrade more painful). > > 4a. Support a version until it's out of full support, then jump to the > newest version. So the voting results look sort of like this: 1: 0, -2 1a: 1, -1 1b: 1, 2 -> 1 or 1a or 1b: +2 2: 0, -2 3: 0, 2 4: 0, -1, -1 4a: 0, -2, -1 Meaning 1b, "Always support the second-to-newest version" seems to be the best fit. Since a 4.13 release is imminent, I think we'll probably switch to 4.12 as the default / main supported release once that's out, and then update every release. -George ___ CentOS-virt mailing list CentOS-virt@centos.org https://lists.centos.org/mailman/listinfo/centos-virt
Re: [CentOS-virt] Xen Version update policy
On Mon, Dec 2, 2019 at 5:08 PM Kevin Stange wrote: > By supporting only even numbered releases as is the case now, it has not > been possible to do hot migration based upgrades which means that we > have to do full reboots of our entire environment every so often. Right > now we're running on Xen 4.8 and transitioning to 4.12 directly. We > skipped 4.10 because we felt that 4.12 has been out and stable for long > enough. Ideally if every major build of Xen were provided we would > transition by hot migrations up to the next release periodically and > stay on a security supported release each time one is going toward EOL. > > Personally I would love to see at the very least transitional packages > for each Xen version available to allow for easier hot migrations to the > latest release, under the assumption that such migrations are considered > "supported" upstream. I believe you said this was to be expected in a > previous conversation we had on IRC. The original purpose of only doing every other release was to make sure that maintenance of the packages wouldn't take too much of our time; but I think at the current state of things, updating ever release should be fine. (Particularly now that we've spread out releases again.) > I don't really think we should drop a release before its security > support ends, unless we have *really clear* communication to repo users > as to the life cycles of these builds in advance. Indeed, the purpose of this email is in fact to make such a clear communication. Citrix (i.e., Anthony & I) have committed to providing up-to-date packages for one version at a time; this is meant to give people input into which version that is. The Virt SIG cannot as a whole commit to supporting releases until security support ends unless others step up and make commitments to do so. > I get why providing updates for 5 major releases concurrently is > prohibitive for the entire security support period, though if it were > more automated, maybe it would be easier to manage. Indeed; I think the main barrier to having the whole thing automated from xen.git/staging-VV to mirror.centos.org is testing. If we had at least a reasonable subset of automated testing between buildlogs and mirror, I'd feel comfortable with an automated push. Alternately, if people were comfortable with "the community has 1 week to test and object before an automated push happens", we could do that too. -George ___ CentOS-virt mailing list CentOS-virt@centos.org https://lists.centos.org/mailman/listinfo/centos-virt
[CentOS] [Infra] - Planned outage/migration : CentOS forums
Due to a hardware/DC relocate operation, we'll have to move the existing CentOS forums instance (hosted on https://www.centos.org/forums) to a new node. Migration is scheduled for Monday December 16th, 8:00 am UTC time. You can convert to local time with $(date -d '2019-12-16 8:00 UTC') The expected "downtime" is estimated to ~20 minutes , time needed to : - freeze forums instance - backup instance data (DB + files) - import data to new host and validate - enable the httpd redirection to the new host Worth knowing that during the migration process, the forums instance will not be available. Thanks for your comprehending and patience. -- Fabian Arrotin The CentOS Project | https://www.centos.org gpg key: 17F3B7A1 | twitter: @arrfab signature.asc Description: OpenPGP digital signature ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
[CentOS] CentOS-announce Digest, Vol 178, Issue 3
Send CentOS-announce mailing list submissions to
centos-annou...@centos.org
To subscribe or unsubscribe via the World Wide Web, visit
https://lists.centos.org/mailman/listinfo/centos-announce
or, via email, send a message with subject or body 'help' to
centos-announce-requ...@centos.org
You can reach the person managing the list at
centos-announce-ow...@centos.org
When replying, please edit your Subject line so it is more specific
than "Re: Contents of CentOS-announce digest..."
Today's Topics:
1. CESA-2019:4108 Critical CentOS 6 firefox Security Update
(Johnny Hughes)
2. CEEA-2019:4155 CentOS 6 microcode_ctl Enhancement Update
(Johnny Hughes)
3. CESA-2019:4152 Important CentOS 6 nss-softokn Security Update
(Johnny Hughes)
--
Message: 1
Date: Wed, 11 Dec 2019 17:42:55 +
From: Johnny Hughes
To: centos-annou...@centos.org
Subject: [CentOS-announce] CESA-2019:4108 Critical CentOS 6 firefox
SecurityUpdate
Message-ID: <20191211174255.ga21...@bstore1.rdu2.centos.org>
Content-Type: text/plain; charset=us-ascii
CentOS Errata and Security Advisory 2019:4108 Critical
Upstream details at : https://access.redhat.com/errata/RHSA-2019:4108
The following updated files have been uploaded and are currently
syncing to the mirrors: ( sha256sum Filename )
i386:
cc647561cb94e13461bfbf9cbb90871340968336c6733eab4177df671a570128
firefox-68.3.0-1.el6.centos.i686.rpm
x86_64:
cc647561cb94e13461bfbf9cbb90871340968336c6733eab4177df671a570128
firefox-68.3.0-1.el6.centos.i686.rpm
900468a1b0f04766d10f3a1d8382277622fcb916d27fc170966a399772d099fb
firefox-68.3.0-1.el6.centos.x86_64.rpm
Source:
6433f8ddd3c6bf0f7a344eee3cfe8e18e9171642c3f9c1407b72c5636c2bae56
firefox-68.3.0-1.el6.centos.src.rpm
--
Johnny Hughes
CentOS Project { http://www.centos.org/ }
irc: hughesjr, #cen...@irc.freenode.net
Twitter: @JohnnyCentOS
--
Message: 2
Date: Wed, 11 Dec 2019 17:43:41 +
From: Johnny Hughes
To: centos-annou...@centos.org
Subject: [CentOS-announce] CEEA-2019:4155 CentOS 6 microcode_ctl
Enhancement Update
Message-ID: <20191211174341.ga21...@bstore1.rdu2.centos.org>
Content-Type: text/plain; charset=us-ascii
CentOS Errata and Enhancement Advisory 2019:4155
Upstream details at : https://access.redhat.com/errata/RHEA-2019:4155
The following updated files have been uploaded and are currently
syncing to the mirrors: ( sha256sum Filename )
i386:
6f57605cc7ebeb3c3986253a11c4b78a6581a183bc024f91bad24824991f1fd3
microcode_ctl-1.17-33.23.el6_10.i686.rpm
x86_64:
c630919de457d9d99bfe57a7c845a22d662fedde58d17636015f0344e8238e4a
microcode_ctl-1.17-33.23.el6_10.x86_64.rpm
Source:
4b4e84be896225e4cb9ee17186c7f500fc4cc5990a23d297585e6d3b34eeb023
microcode_ctl-1.17-33.23.el6_10.src.rpm
--
Johnny Hughes
CentOS Project { http://www.centos.org/ }
irc: hughesjr, #cen...@irc.freenode.net
Twitter: @JohnnyCentOS
--
Message: 3
Date: Wed, 11 Dec 2019 17:44:29 +
From: Johnny Hughes
To: centos-annou...@centos.org
Subject: [CentOS-announce] CESA-2019:4152 Important CentOS 6
nss-softokn Security Update
Message-ID: <20191211174429.ga21...@bstore1.rdu2.centos.org>
Content-Type: text/plain; charset=us-ascii
CentOS Errata and Security Advisory 2019:4152 Important
Upstream details at : https://access.redhat.com/errata/RHSA-2019:4152
The following updated files have been uploaded and are currently
syncing to the mirrors: ( sha256sum Filename )
i386:
56ea7a0682790ca57f8f873900a875ea2421494ab58db88eb66083555fd41f5f
nss-softokn-3.44.0-6.el6_10.i686.rpm
0519c1d561f33af51703e88f99c0932f578ee98ab3dad479db1e0e58200dba4a
nss-softokn-devel-3.44.0-6.el6_10.i686.rpm
8012888f0d7a020dd57d66d39f99570091f72dbf3a05def8d4b1f5e385f06020
nss-softokn-freebl-3.44.0-6.el6_10.i686.rpm
efc3dd7833d993241ead23a2b56af867bc04340c9cbf4a72df243636474ccfae
nss-softokn-freebl-devel-3.44.0-6.el6_10.i686.rpm
x86_64:
56ea7a0682790ca57f8f873900a875ea2421494ab58db88eb66083555fd41f5f
nss-softokn-3.44.0-6.el6_10.i686.rpm
1673ecea1ea6c8b634e6cee93877db2af04f1345a19abc2b9757ef0a35df0cc8
nss-softokn-3.44.0-6.el6_10.x86_64.rpm
0519c1d561f33af51703e88f99c0932f578ee98ab3dad479db1e0e58200dba4a
nss-softokn-devel-3.44.0-6.el6_10.i686.rpm
45fa763e32d2855459c040aaf64416dc6fe482098455ef9e639fa7c8172a1a51
nss-softokn-devel-3.44.0-6.el6_10.x86_64.rpm
8012888f0d7a020dd57d66d39f99570091f72dbf3a05def8d4b1f5e385f06020
nss-softokn-freebl-3.44.0-6.el6_10.i686.rpm
eadb92ed42ba3883b76fc0252e3ff2b1750dfaa36cbbcc740f391d6698d1a0f0
nss-softokn-freebl-3.44.0-6.el6_10.x86_64.rpm
efc3dd7833d993241ead23a2b56af867bc04340c9cbf4a72df243636474ccfae
nss-softokn-freebl-devel-3.44.0-6.el6_10.i686.rpm
a73c930d774e830e8d9801c60cf6c5eebffdf38edb9043fa6005f2baf784e5bc
nss-softokn-freebl-devel-3.44.0-6.el6_10.x86_64.rpm
Source:
