scitech December 2019

scitech@lists.fedoraproject.org

7 participants
9 discussions

OpenMPI stack in danger (Re: Orphaned packages looking for new maintainers)
by Dominik 'Rathann' Mierzejewski 18 Nov '20

18 Nov '20

Hi! On Monday, 25 November 2019 at 10:52, Miro Hrončok wrote: > The following packages are orphaned and will be retired when they > are orphaned for six weeks, unless someone adopts them. If you know for sure > that the package should be retired, please do so now with a proper reason: > https://fedoraproject.org/wiki/How_to_remove_a_package_at_end_of_life > > Note: If you received this mail directly you (co)maintain one of the affected > packages or a package that depends on one. Please adopt the affected package or > retire your depending package to avoid broken dependencies, otherwise your > package will be retired when the affected package gets retired. > > Request package ownership via releng issues: > https://pagure.io/releng/issues > > Full report available at: > https://churchyard.fedorapeople.org/orphans-2019-11-25.txt > grep it for your FAS username and follow the dependency chain. To save time looking this up, I want to direct the attention of pmix and openmpi maintainers (Cc'd) to this chain: munge (orphaned) -> pmix -> openmpi In short, anything that depends on openmpi is at risk of being retired. > Package (co)maintainers Status Change > ================================================================================ [...] > munge orphan 1 weeks ago [...] Regards, Dominik -- Fedora https://getfedora.org | RPM Fusion http://rpmfusion.org There should be a science of discontent. People need hard times and oppression to develop psychic muscles. -- from "Collected Sayings of Muad'Dib" by the Princess Irulan

3 8

Science and Technology Lab?
by Benson Muite 04 Feb '20

04 Feb '20

Hi, Would it be worth having a Fedora Science and Technology lab or putting some of the packages used in CAE linux (https://www.caelinux.com/CMS3/) in the Robotics lab? Benson

5 9

Synergies when doing ports from Python2 to Python3
by Andreas Tille 19 Dec '19

19 Dec '19

Hi, in the Debian Med team (and also Debian Science) we are quite busy to port software from Python2 to Python3 to save it from Python2 end of life. Usually we forward our patches upstream or work together with upstream to do the port. However, in case of unresponsive or known to be dead upstream we are on our own. I'd love to coordinate the porting work a bit. All packages of the Debian Med team can be found at https://salsa.debian.org/med-team/ and the patches dealing with Python3 ports in most cases are named 2to3.patch. Since Debian packages are using quilt patches you can usually find a patch in https://salsa.debian.org/med-team/ __PACKAGENAME__ /blob/master/debian/patches/2to3.patch Please feel free to cherry pick from there. We would be really interested if you find issues in those patches - so please let us know. As usual you can find a human readable list of Debian Med packages here: https://blends.debian.org/med/tasks/bio (Biology) https://blends.debian.org/med/tasks/bio-dev (Biology development) In this field are the most packages we are talking about. If you might know further interested parties to coordinate, we would be happy to know. If you could explain where to find possible patches you might have developed for Fedora this would also be interesting to know. Kind regards Andreas. -- http://fam-tille.de

3 3

Announcing the SciTech packager group
by Ankur Sinha 16 Dec '19

16 Dec '19

Hello, To better co-ordinate the maintenance of Science and Technology related packages, we've created the scitech_sig group on FAS for package maintainers[1]. If you are a package maintainer and maintain or are interested in maintaining general packages related to Science and Technology, please: - apply for membership to the FAS group, - give commit privileges to the scitech_sig group on src.fp.o to add them to the team's packages (you will have to wait till your FAS group membership has been approved, then log out and back in to src.fp.o for your profile to sync) - subscribe to the notification mailing list: scitech-bugs(a)lists.fedoraproject.org[2]. Community discussion around Science and Technology in Fedora will continue on the SciTech mailing list: scitech(a)lists.fedoraproject.org[3]. We also have the IRC channel at #fedora-science on Freenode. We encourage you to join the team and help Fedora promote Free/Open Science and Technology! Please feel free to e-mail the discussion mailing list for any comments at all. Please note that for security, the bug notification mailing list is limited to package maintainers only, and the archives will be kept private. [1] https://admin.fedoraproject.org/accounts/group/view/scitech_sig [2] https://lists.fedoraproject.org/admin/lists/scitech-bugs.lists.fedoraprojec… [2] https://lists.fedoraproject.org/admin/lists/scitech.lists.fedoraproject.org/ -- Thanks, Regards, Ankur Sinha "FranciscoD" (He / Him / His) | https://fedoraproject.org/wiki/User:Ankursinha Time zone: Europe/London

1 0

Re: Heads up: rdma-core dropped support for 32-bit arm
by Dominik 'Rathann' Mierzejewski 10 Dec '19

10 Dec '19

On Tuesday, 10 December 2019 at 11:14, Honggang LI wrote: > On Mon, Dec 09, 2019 at 02:40:29PM +0100, Dominik 'Rathann' > Mierzejewski wrote: [...] > > Thanks for the background. I'm not questioning your decision to stop > > building rdma for armv7hl, but it needs to be coordinated with the > > dependent packages. Please re-enable it, work with the respective > > It seems not a good choice for me to re-enable and disable it again. I hope you can fix the dependency issues quickly. Otherwise you'll be leaving a number of packages in a state where they're not installable and the packages depending on them are not rebuildable for an extended period of time. > I'm trying to get an arm32 machine in our lab. And then I will narrow > down all packages impacted by this. Will open bug for all impacted > packages. You can use one of the ARM VMs available to Fedora packagers: https://fedoraproject.org/wiki/Test_Machine_Resources_For_Package_Maintaine… Thanks for trying to do the right thing after all, I appreciate it. Regards, Dominik -- Fedora https://getfedora.org | RPM Fusion http://rpmfusion.org There should be a science of discontent. People need hard times and oppression to develop psychic muscles. -- from "Collected Sayings of Muad'Dib" by the Princess Irulan

1 0

Re: Heads up: rdma-core dropped support for 32-bit arm
by Dominik 'Rathann' Mierzejewski 10 Dec '19

10 Dec '19

On Tuesday, 10 December 2019 at 10:47, Honggang LI wrote: [...] > I will work with Mellanox to fix this dependency issue. Thank you! Regards, Dominik -- Fedora https://getfedora.org | RPM Fusion http://rpmfusion.org There should be a science of discontent. People need hard times and oppression to develop psychic muscles. -- from "Collected Sayings of Muad'Dib" by the Princess Irulan

1 0

Re: Heads up: rdma-core dropped support for 32-bit arm
by Dominik 'Rathann' Mierzejewski 09 Dec '19

09 Dec '19

On Monday, 09 December 2019 at 14:15, Honggang LI wrote: > On Mon, Dec 09, 2019 at 12:17:43PM +0100, Dominik 'Rathann' Mierzejewski wrote: [...] > > The change to rdma-core.spec in commit b631ce466538bdee6e19be3286fb8cbeb5c73de6: > > ... > > +# 32-bit arm is missing required arch-specific memory barriers, > > +ExcludeArch: %{arm} > > ... > > > > should have been communicated to all depdent package maintainers in > > advance, as this is effectively removing the package for armv7hl from > > rawhide. Cc'ing the committer. > > > > Why was this built on arm32 before if RDMA is not supported on arm32? > > We did not intentionally built rdma stack package for arm32. You did not intentially disable building on arm32. All Fedora packages are built on all arches unless explicitly disabled: https://docs.fedoraproject.org/en-US/packaging-guidelines/#_architecture_su… > https://bugzilla.redhat.com/show_bug.cgi?id=1484155 > > Please see this bug for details. The first version of rdma-core-12 > did not built on arm32. Unfortunately, rdma-core-16.2-1.fc28 had been > built on arm32. It seems enabled by the fedora package building system > by default. I do not mean to blame fedora package building system. It is > our fault did not fix this time, when rdma-core-16.2-1.fc28 built on > arm32. Thanks for the background. I'm not questioning your decision to stop building rdma for armv7hl, but it needs to be coordinated with the dependent packages. Please re-enable it, work with the respective maintainers to disable rdma support on armv7hl and then put ExcludeArch for armv7hl back in. Regards, Dominik -- Fedora https://getfedora.org | RPM Fusion http://rpmfusion.org There should be a science of discontent. People need hard times and oppression to develop psychic muscles. -- from "Collected Sayings of Muad'Dib" by the Princess Irulan

1 0

Re: Heads up: rdma-core dropped support for 32-bit arm
by Dominik 'Rathann' Mierzejewski 09 Dec '19

09 Dec '19

On Sunday, 08 December 2019 at 04:36, Doug Ledford wrote: > > On Dec 7, 2019, at 1:04 AM, Orion Poplawski <orion(a)nwra.com> wrote: > > > > FYI: > > > > rdma-core 26.1-1.fc32 dropped support for %arm: > > > > # 32-bit arm is missing required arch-specific memory barriers, > > ExcludeArch: %{arm} > > > > This broke dependecies for the arm package of openmpi > > (https://bugzilla.redhat.com/show_bug.cgi?id=1780584) > > > > This may have affected other users of rdma-core, depending of if > > they use rdma on arm. Using my x86_64 machine: > > > > $ dnf repoquery --whatrequires libibverbs.so.1'()(64bit)' --source > > Last metadata expiration check: 0:14:21 ago on Fri 06 Dec 2019 10:35:11 PM MST. > > ceph-14.2.4-3.fc32.src.rpm > > dapl-2.1.9-10.fc31.src.rpm > > fio-3.16-2.fc32.src.rpm > > ga-5.6.5-6.fc31.src.rpm > > glusterfs-7.0-1.fc32.src.rpm > > libfabric-1.9.0-1.fc32.src.rpm > > libiscsi-1.18.0-9.fc32.src.rpm > > libocrdma-1.0.8-6.fc27.src.rpm > > nwchem-6.8.2-1.fc32.src.rpm > > openmpi-3.1.5-1.module_f32+7117+998651d7.src.rpm > > orangefs-2.9.7-6.fc31.src.rpm > > perftest-4.2-5.fc31.src.rpm > > qemu-4.2.0-0.3.rc2.fc32.src.rpm > > qperf-0.4.9-16.fc31.src.rpm > > rdma-core-26.1-1.fc32.src.rpm > > scsi-target-utils-1.0.70-9.fc31.src.rpm > > ucx-1.6.1-1.fc32.src.rpm > > > > This has also broken hwloc-devel on arm: > > > > https://bugzilla.redhat.com/show_bug.cgi?id=1780813 > > > > Is this a definite hard requirement, or can we have at least a > > minimal rdma-core for arm to avoid having to propagate a bunch of > > arm conditionals down the stack? > > The arm32 platform literally does not support the memory primitives > needed to safely to RDMA. If we enable the support, and someone uses > it, there is nothing we can do to prevent them running the risk of > memory corruption. So we probably need to exclude arm32 from all > these packages, or conditionally make the packages exclude RDMA > support on arm32. The change to rdma-core.spec in commit b631ce466538bdee6e19be3286fb8cbeb5c73de6: ... +# 32-bit arm is missing required arch-specific memory barriers, +ExcludeArch: %{arm} ... should have been communicated to all depdent package maintainers in advance, as this is effectively removing the package for armv7hl from rawhide. Cc'ing the committer. Why was this built on arm32 before if RDMA is not support arm32? Regards, Dominik -- Fedora https://getfedora.org | RPM Fusion http://rpmfusion.org There should be a science of discontent. People need hard times and oppression to develop psychic muscles. -- from "Collected Sayings of Muad'Dib" by the Princess Irulan

1 0

Heads up: rdma-core dropped support for 32-bit arm
by Orion Poplawski 07 Dec '19

07 Dec '19

FYI: rdma-core 26.1-1.fc32 dropped support for %arm: # 32-bit arm is missing required arch-specific memory barriers, ExcludeArch: %{arm} This broke dependecies for the arm package of openmpi (https://bugzilla.redhat.com/show_bug.cgi?id=1780584) This may have affected other users of rdma-core, depending of if they use rdma on arm. Using my x86_64 machine: $ dnf repoquery --whatrequires libibverbs.so.1'()(64bit)' --source Last metadata expiration check: 0:14:21 ago on Fri 06 Dec 2019 10:35:11 PM MST. ceph-14.2.4-3.fc32.src.rpm dapl-2.1.9-10.fc31.src.rpm fio-3.16-2.fc32.src.rpm ga-5.6.5-6.fc31.src.rpm glusterfs-7.0-1.fc32.src.rpm libfabric-1.9.0-1.fc32.src.rpm libiscsi-1.18.0-9.fc32.src.rpm libocrdma-1.0.8-6.fc27.src.rpm nwchem-6.8.2-1.fc32.src.rpm openmpi-3.1.5-1.module_f32+7117+998651d7.src.rpm orangefs-2.9.7-6.fc31.src.rpm perftest-4.2-5.fc31.src.rpm qemu-4.2.0-0.3.rc2.fc32.src.rpm qperf-0.4.9-16.fc31.src.rpm rdma-core-26.1-1.fc32.src.rpm scsi-target-utils-1.0.70-9.fc31.src.rpm ucx-1.6.1-1.fc32.src.rpm This has also broken hwloc-devel on arm: https://bugzilla.redhat.com/show_bug.cgi?id=1780813 Is this a definite hard requirement, or can we have at least a minimal rdma-core for arm to avoid having to propagate a bunch of arm conditionals down the stack? -- Orion Poplawski Manager of NWRA Technical Systems 720-772-5637 NWRA, Boulder/CoRA Office FAX: 303-415-9702 3380 Mitchell Lane orion(a)nwra.com Boulder, CO 80301 https://www.nwra.com/

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

scitech December 2019