devel February 2020

devel@lists.fedoraproject.org

236 participants
422 discussions

Fedora 32 compose report: 20200228.n.0 changes
by Fedora Branched Report 28 Feb '20

28 Feb '20

OLD: Fedora-32-20200227.n.0 NEW: Fedora-32-20200228.n.0 ===== SUMMARY ===== Added images: 3 Dropped images: 0 Added packages: 0 Dropped packages: 0 Upgraded packages: 1 Downgraded packages: 0 Size of added packages: 0 B Size of dropped packages: 0 B Size of upgraded packages: 618.73 KiB Size of downgraded packages: 0 B Size change of upgraded packages: 31.32 KiB Size change of downgraded packages: 0 B ===== ADDED IMAGES ===== Image: Server dvd s390x Path: Server/s390x/iso/Fedora-Server-dvd-s390x-32-20200228.n.0.iso Image: Server boot s390x Path: Server/s390x/iso/Fedora-Server-netinst-s390x-32-20200228.n.0.iso Image: Silverblue dvd-ostree x86_64 Path: Silverblue/x86_64/iso/Fedora-Silverblue-ostree-x86_64-32-20200228.n.0.iso ===== DROPPED IMAGES ===== ===== ADDED PACKAGES ===== ===== DROPPED PACKAGES ===== ===== UPGRADED PACKAGES ===== Package: efivar-37-6.fc32 Old package: efivar-37-5.fc32 Summary: Tools to manage UEFI variables RPMs: efivar efivar-devel efivar-libs Size: 618.73 KiB Size change: 31.32 KiB Changelog: * Mon Feb 24 2020 Peter Jones <pjones(a)redhat.com> - 37-6 - Pull in a bunch of patches from upstream. ===== DOWNGRADED PACKAGES =====

1 0

CPE Weekly: 2020-02-28
by Aoife Moloney 28 Feb '20

28 Feb '20

--- title: CPE Weekly status email tags: CPE Weekly, email --- # CPE Weekly: 2020-02-28 Background: The Community Platform Engineering group is the Red Hat team combining IT and release engineering from Fedora and CentOS. Our goal is to keep core servers and services running and maintained, build releases, and other strategic tasks that need more dedicated time than volunteers can give. For better communication, we will be giving weekly reports to the CentOS and Fedora communities about the general tasks and work being done. Also for better communication between our groups we have created #redhat-cpe on Freenode IRC! Please feel free to catch us there, a mail has landed on both the CentOS and Fedora devel lists with context here. ## Fedora Updates * F32 Beta Freeze now on ### Data Centre Move * Old OpenStack instance has now been switched off. * The team are planning the shipping logistics of the equipment across country with Red Hat - measurements, weights, insurance amounts - fun stuff! :) * No changes to our expected dates as per our last posting, but if there are we will make sure to let you know asap. ### AAA Replacement Current functionalities developed to date: * User functionality to join groups * Uhange email address and password * Disable account function * Database access function * We are also currently mapping solution on how best to have users move from the current FAS to the new FAS (potential name incoming!). * The team also came to the end of developing our wireframes and mapping our user experience flow. * Unit tests were carried out regarding password controller and the current codebase. Patrick Uiterijk and Christian Heimes still continue to be a huge help to the team in this project so thank you both sincerely! For our full blog post, check out Ben Cottons weekly For more information regarding outstanding issues, please see here. To view our current scrum board, please see here. ### CI/CD * The team have made good progress on getting monitor-gating to run in staging * This is running completely now and while it fails in some steps but not because of itself, means it is already providing us valuable information :) * The team have sent an email to the devel list presenting our ideas and potential proposal for the changelog and release fields proof of concept - check it out here: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org… ### Sustaining Team * Releng and Infra Freeze for Fedora 32 Beta is now, so if you need changes have them reviewed. * FMN is the main blocking point for the retirement of fedmsg, it is also running on an eol Fedora (28) and the team are working on replacing it. Check out their public thread here: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org… ## Docs ### Misc Updates * Some packaging work to get pagure's dependencies added and built in EPEL8 (remaining: pygit2 and celery) were done this week * boot.fedoraproject.org and keys.fpo to wiki page has been retired * koji is being set up to have rhscl and rhdevtools for EPEL-7 * infra 8664 - newer kernel on aarch64-test machines. * infra 8369 - people css and html broken so a patch has been applied from new contributor and pushed out * Investigations into why fedora 32 branched compose was stuck & it was ostree signing. https://pagure.io/robosignatory/issue/44 https://pagure.io/pungi/issue/1350 * Broken epel8-testing update push was fixed and is now resumed * Rawhide compose failure was investigated https://pagure.io/releng/failed-composes/issue/1023 Was ceph. Filed https://bugzilla.redhat.com/show_bug.cgi?id=1805422 untagged it and refired compose. * Vagrant environment for mbbox was worked on https://github.com/fedora-infra/mbbox/pull/1 * Mbbox was moved to fedora-infra https://github.com/fedora-infra/mbbox * Jms-messaging-plugin PRs merged https://github.com/jenkinsci/jms-messaging-plugin/pull/169 https://github.com/jenkinsci/jms-messaging-plugin/pull/168 * Alternative “holistic heuristic” algorithm for computing releases was implemented https://pagure.io/Fedora-Infra/generate_changelog/pull-request/3 Common Python package, modules and misc cleanup https://pagure.io/Fedora-Infra/generate_changelog/pull-request/4 * Update and complete README was worked on https://pagure.io/Fedora-Infra/generate_changelog/pull-request/5 ## CentOS Updates ### CentOS * 5 updates for el8 * 3 updates for el7 * EPEL7 container image on quay.io for python-tox * Exploring fedora-infra jobs that can be containerized ### CentOS Stream * Composes are now automated * CentOS QA are now consuming compose in the test suite and running against CentOS Linux and Stream! * Building the contributor workflow is still ongoing and we will keep you updated when we make some progress on this As always, feedback is welcome, and we will continue to look at ways to improve the delivery and readability of this weekly report. Have a great weekend! Aoife Source: https://hackmd.io/8iV7PilARSG68Tqv8CzKOQ -- Aoife Moloney Product Owner Community Platform Engineering Team Red Hat EMEA Communications House Cork Road Waterford

1 0

Fedora 32 Beta blocker status
by Ben Cotton 28 Feb '20

28 Feb '20

Action summary ==================== Accepted blockers ----------------- 1. dnf-plugins-extras — Cannot upgrade to Fedora 32: Modules blocking the upgrade path — NEW ACTION: QA to test dnf-plugins-extras-4.0.9-3.fc32 2. PackageKit — Cannot upgrade to Fedora 32: Modules blocking the upgrade path — NEW ACTION: PackageKit maintainers to work with dnf team to implement module reset workaround NEEDINFO: rhughes 3. python-blivet — blivet.errors.DeviceTreeError: failed to add slave root00p2 of device root00 — ASSIGNED ACTION: Maintainers to diagnose and fix crash 4. anaconda — pyanaconda.modules.common.errors.storage.UnknownDeviceError: home — VERIFIED ACTION: releng to include anaconda-32.24.2-1 in next compose 5. gnome-shell — [abrt] gnome-shell: js::gc::TenuredCell::writeBarrierPre(js::gc::TenuredCell*)(): gnome-shell killed by SIGSEGV — ASSIGNED ACTION: QA to test upstream fix in COPR. 6. python-blivet — anaconda unable to finish installation with software raid partition — NEW ACTION: Maintainers to diagnose and fix crash 7. distribution — Fedora 32 backgrounds not included — NEW ACTION: Design team to package backgrounds Proposed blockers ----------------- 1. virt-manager — NAT (Inactive) by default, cannot create a VM — NEW ACTION: Maintainers to diagnose and fix issue Bug-by-bug detail ============= Accepted blockers ----------------- 1. dnf-plugins-extras — https://bugzilla.redhat.com/show_bug.cgi?id=1767351 — ON_QA Cannot upgrade to Fedora 32: Modules blocking the upgrade path dnf-plugins-extras-4.0.9-3.fc32 has been submitted to fix this. 2. PackageKit — https://bugzilla.redhat.com/show_bug.cgi?id=1804564 — NEW Cannot upgrade to Fedora 32: Modules blocking the upgrade path See also BZ 1767351 from which it was cloned. This may require an additional API in libdnf 3. python-blivet — https://bugzilla.redhat.com/show_bug.cgi?id=1798792 — ASSIGNED blivet.errors.DeviceTreeError: failed to add slave root00p2 of device root00 Using SCSI, IDE, or SATA software RAID created by the installer in a virtualized environment crashes on the post-install boot. Behavior is not seen with virtio disk bus. May be related to open upstream PR https://github.com/storaged-project/blivet/pull/796 4. anaconda — https://bugzilla.redhat.com/show_bug.cgi?id=1806233 — VERIFIED pyanaconda.modules.common.errors.storage.UnknownDeviceError: home Deleting mount points from a previous custom-partitioned failed installation causes a crash in the installer. 5. 1. gnome-shell — https://bugzilla.redhat.com/show_bug.cgi?id=1801820 — ASSIGNED [abrt] gnome-shell: js::gc::TenuredCell::writeBarrierPre(js::gc::TenuredCell*)(): gnome-shell killed by SIGSEGV Original fix did not fix it. Another upstream fix (https://gitlab.gnome.org/GNOME/gjs/merge_requests/396) is available in COPR (https://copr.fedorainfracloud.org/coprs/frantisekz/gjs-mr396/) 6. python-blivet — https://bugzilla.redhat.com/show_bug.cgi?id=1804080 — NEW anaconda unable to finish installation with software raid partition We create the md array such that mdadm should auto-activate it after creation. Something a little weird happens with that, then blivet thinks the array is inactive right afterward, so it tries to activate it and mdadm complains that the devices are busy. 7. distribution — https://bugzilla.redhat.com/show_bug.cgi?id=1807342 — NEW Fedora 32 backgrounds not included It seems we don't have backgrounds for Fedora 32 yet. Fedora 32 KDE installs are currently using a generic upstream background, but Fedora 32 GNOME/Workstation installs are using the Fedora 31 background. Proposed blockers ----------------- 1. virt-manager — https://bugzilla.redhat.com/show_bug.cgi?id=1807768 — NEW NAT (Inactive) by default, cannot create a VM Default configuration of virtualization group on a clean install results in "dnsmasq: unknown user or group: dnsmasq" error when attempting to starting the network. -- Ben Cotton He / Him / His Senior Program Manager, Fedora & CentOS Stream Red Hat TZ=America/Indiana/Indianapolis

1 0

Fedora-Cloud-31-20200228.0 compose check report
by Fedora compose checker 28 Feb '20

28 Feb '20

No missing expected images. Passed openQA tests: 1/1 (x86_64) -- Mail generated by check-compose: https://pagure.io/fedora-qa/check-compose

1 0

Fedora-Cloud-30-20200228.0 compose check report
by Fedora compose checker 28 Feb '20

28 Feb '20

No missing expected images. Passed openQA tests: 1/1 (x86_64) -- Mail generated by check-compose: https://pagure.io/fedora-qa/check-compose

1 0

Memory exhaustion on armv7hl builders
by Orion Poplawski 28 Feb '20

28 Feb '20

I'm unable to build ParaView on armv7hl: [ 14%] Building CXX object VTK/Accelerators/Vtkm/CMakeFiles/AcceleratorsVTKm.dir/vtkmClip.cxx.o cd /builddir/build/BUILD/ParaView-v5.8.0/armv7hl-redhat-linux-gnueabi/VTK/Accelerators/Vtkm && /usr/bin/c++ -DAcceleratorsVTKm_EXPORTS -I/builddir/build/BUILD/ParaView-v5.8.0/armv7hl-redhat-linux-gnueabi/VTK/Accelerators/Vtkm -I/builddir/build/BUILD/ParaView-v5.8.0/VTK/Accelerators/Vtkm -I/builddir/build/BUILD/ParaView-v5.8.0/armv7hl-redhat-linux-gnueabi/VTK/Common/Core -I/builddir/build/BUILD/ParaView-v5.8.0/VTK/Common/Core -I/builddir/build/BUILD/ParaView-v5.8.0/armv7hl-redhat-linux-gnueabi/VTK/Common/DataModel -I/builddir/build/BUILD/ParaView-v5.8.0/VTK/Common/DataModel -I/builddir/build/BUILD/ParaView-v5.8.0/armv7hl-redhat-linux-gnueabi/VTK/Common/Math -I/builddir/build/BUILD/ParaView-v5.8.0/VTK/Common/Math -I/builddir/build/BUILD/ParaView-v5.8.0/armv7hl-redhat-linux-gnueabi/VTK/Common/Transforms -I/builddir/build/BUILD/ParaView-v5.8.0/VTK/Common/Transforms -I/builddir/build/BUILD/ParaView-v5.8.0/armv7hl-redhat-linux-gnueabi/VTK/Common/ExecutionModel -I/builddir/build/BUILD/ParaView-v5.8.0/VTK/Common/ExecutionModel -I/builddir/build/BUILD/ParaView-v5.8.0/armv7hl-redhat-linux-gnueabi/VTK/Filters/General -I/builddir/build/BUILD/ParaView-v5.8.0/VTK/Filters/General -I/builddir/build/BUILD/ParaView-v5.8.0/armv7hl-redhat-linux-gnueabi/VTK/Common/Misc -I/builddir/build/BUILD/ParaView-v5.8.0/VTK/Common/Misc -I/builddir/build/BUILD/ParaView-v5.8.0/armv7hl-redhat-linux-gnueabi/VTK/Filters/Core -I/builddir/build/BUILD/ParaView-v5.8.0/VTK/Filters/Core -I/builddir/build/BUILD/ParaView-v5.8.0/armv7hl-redhat-linux-gnueabi/VTK/Filters/Geometry -I/builddir/build/BUILD/ParaView-v5.8.0/VTK/Filters/Geometry -I/builddir/build/BUILD/ParaView-v5.8.0/armv7hl-redhat-linux-gnueabi/VTK/Imaging/Core -I/builddir/build/BUILD/ParaView-v5.8.0/VTK/Imaging/Core -I/builddir/build/BUILD/ParaView-v5.8.0/armv7hl-redhat-linux-gnueabi/VTK/ThirdParty/vtkm/vtkvtkm -I/builddir/build/BUILD/ParaView-v5.8.0/VTK/ThirdParty/vtkm/vtkvtkm -I/builddir/build/BUILD/ParaView-v5.8.0/VTK/ThirdParty/vtkm/vtkvtkm/vtk-m -I/builddir/build/BUILD/ParaView-v5.8.0/armv7hl-redhat-linux-gnueabi/VTK/ThirdParty/vtkm/vtkvtkm/vtk-m/include -I/builddir/build/BUILD/ParaView-v5.8.0/VTK/ThirdParty/vtkm/vtkvtkm/vtk-m/vtkm/thirdparty/taotuple -I/builddir/build/BUILD/ParaView-v5.8.0/VTK/ThirdParty/vtkm/vtkvtkm/vtk-m/vtkm/thirdparty/optionparser -I/builddir/build/BUILD/ParaView-v5.8.0/VTK/ThirdParty/vtkm/vtkvtkm/vtk-m/vtkm/thirdparty/diy -I/builddir/build/BUILD/ParaView-v5.8.0/VTK/ThirdParty/vtkm/vtkvtkm/vtk-m/vtkm/thirdparty/lcl/vtkmlcl -isystem /builddir/build/BUILD/ParaView-v5.8.0/armv7hl-redhat-linux-gnueabi/VTK/Utilities/KWIML -isystem /builddir/build/BUILD/ParaView-v5.8.0/VTK/Utilities/KWIML -isystem /builddir/build/BUILD/ParaView-v5.8.0/armv7hl-redhat-linux-gnueabi/VTK/Utilities/KWSys -isystem /builddir/build/BUILD/ParaView-v5.8.0/VTK/Utilities/KWSys -isystem /builddir/build/BUILD/ParaView-v5.8.0/armv7hl-redhat-linux-gnueabi/VTK/ThirdParty/vtkm -isystem /builddir/build/BUILD/ParaView-v5.8.0/VTK/ThirdParty/vtkm -O2 -g -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS -fexceptions -fstack-protector-strong -grecord-gcc-switches -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -fcommon -march=armv7-a -mfpu=vfpv3-d16 -mtune=generic-armv7-a -mabi=aapcs-linux -mfloat-abi=hard -O2 -g -DNDEBUG -fPIC -fvisibility=hidden -fvisibility-inlines-hidden -ffunction-sections -std=c++11 -o CMakeFiles/AcceleratorsVTKm.dir/vtkmClip.cxx.o -c /builddir/build/BUILD/ParaView-v5.8.0/VTK/Accelerators/Vtkm/vtkmClip.cxx virtual memory exhausted: Operation not permitted I have already reduced the make parallelism to 1, so not sure what else I can do to avoid this other than to exclude it (which I'm probably happy to do). Suggestions welcome. -- 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/

4 4

Want to claim vault
by Dave Dykstra 27 Feb '20

27 Feb '20

I made a ticket (bug #1806737) for the maintainer of the existing vault package in Fedora to see if he'd be willing to give it up so it can be used for Hashicorp vault (https://vaultproject.io) and he decided to mark it EOL so I could claim it. Dave

3 3

taskotron going down for emergency maintenance
by Tim Flink 27 Feb '20

27 Feb '20

The subject says it all, really. Taskotron is having some problems with an internal component, it can't wait for a better time and we need some downtime to fix it. If all goes well, it should be back up shortly. I'll send another email to update once we're done. Tim

1 1

Revamping the Release Readiness meeting
by Ben Cotton 27 Feb '20

27 Feb '20

(Posting to many mailing lists for visibility. I apologize if you see this more times than you'd like.) You may have already seen my Community Blog post[1] about changing the Release Readiness meeting process. The meeting has questionable value in the current state, so I want to make it more useful. We'll do this by having teams self-report readiness issues on a dedicated wiki page[2] beginning now. This gives the community time to chip in and help with areas that need help without waiting until days before the release. I invite teams to identify a representative to keep the wiki page up to date. Update it as your status changes and I'll post help requests in my weekly CommBlog posts[3] and the FPgM office hours[4] IRC meeting. The Release Readiness meeting will be shortened to one hour and will review open concerns instead of polling for teams that may or may not be there. We will use the logistics mailing list[5] to discuss issues and make announcements, so I encourage representatives to join this list. [1] https://communityblog.fedoraproject.org/fedora-program-update-2020-08/ [2] https://fedoraproject.org/wiki/Release_Readiness [3] https://communityblog.fedoraproject.org/category/program-management/ [4] https://apps.fedoraproject.org/calendar/council/#m9570 -- Ben Cotton He / Him / His Senior Program Manager, Fedora & CentOS Stream Red Hat TZ=America/Indiana/Indianapolis

1 0

Can not build new package: not in list for tag f33-updates-candidate
by Alejandro Álvarez Ayllón 27 Feb '20

27 Feb '20

Hello all, I am trying to build sourcextractor++, which was accepted yesterday, and every time I try I get the following error: BuildError: package sourcextractor++ not in list for tag f33-updates-candidate https://koji.fedoraproject.org/koji/taskinfo?taskID=41969086 I have seen some packages that were accepted at the same time, or even after, already built. And since I have two trailing '+' on the package name, I was wondering if this could have caused some kind of issue. Any hints? -- Alejandro

2 2

← Newer
1
...
4
5
6
7
8
9
10
...
43
Older →

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

devel February 2020