Re: Non-responsive maintainer: nando pavlix
On Mon, Apr 19, 2021 at 11:51:35AM +0200, Miro Hrončok wrote: > On 19. 04. 21 10:52, Pierre-Yves Chibon wrote: > > On Fri, Apr 16, 2021 at 03:12:34PM +0200, Pierre-Yves Chibon wrote: > > > Good Morning Everyone, > > > > > > The packagers listed here have been receiving a daily email asking them to > > > either adjust their bugzilla or their FAS account so the email address in > > > FAS > > > matches an existing bugzilla account. > > > > > > Having a bugzilla account is mandatory per: > > > https://fedoraproject.org/wiki/Join_the_package_collection_maintainers#Create_a_Bugzilla_Account > > > > > > - nando contacted since March 26th > > > - pavlix contacted since March 18th > > > > Thanks to zoglesby and liangwen12year for fixing their accounts. > > > > Does anyone know how to contact nando and pavlix? > > I know how to contact pavlix. That seems to have worked, thanks! The only person left is nando. Pierre ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to 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: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Fedora-Cloud-33-20210420.0 compose check report
No missing expected images. Soft failed openQA tests: 1/7 (x86_64), 1/7 (aarch64) (Tests completed, but using a workaround for a known bug) Old soft failures (same test soft failed in Fedora-Cloud-33-20210419.0): ID: 862272 Test: x86_64 Cloud_Base-qcow2-qcow2 cloud_autocloud URL: https://openqa.fedoraproject.org/tests/862272 ID: 862279 Test: aarch64 Cloud_Base-qcow2-qcow2 cloud_autocloud@uefi URL: https://openqa.fedoraproject.org/tests/862279 Passed openQA tests: 6/7 (x86_64), 6/7 (aarch64) -- Mail generated by check-compose: https://pagure.io/fedora-qa/check-compose ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to 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: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: [dm-crypt] Kdump with full-disk LUKS encryption
Hi, TL;DR what you are trying to do is to actually reverse many security measures we added. It is perhaps acceptable for debugging but hardly for real generic system. - using memory-hard function increases cost of dictionary and brute-force attacks You can always decrease amount of memory needed, but you should do it only if you know that security margin is ok (like password is randomly generated with enough entropy). - key is in keyring to remove possibility for normal userspace to receive the key from kernel. Moreover, there is no need to retain kernel in keyring once dm-crypt device is activated. (It is still in kernel memory but only in crypto functions context). (Systemd also uses keyring to cache passphrase but that's different thing.) You can still use old way for activation with --disable-keyring activation, but then you disable this possibility. More comments below. On 19/04/2021 12:00, Kairui Song wrote: > Hi all, > > I'm currently trying to add kdump support for systemd with full-disk > LUKS encryption. vmcores contain sensitive data so they should also be > protected, and network dumps sometimes are not available. So kdump has > to open the LUKS encrypted device in the kdump environment. > > I'm using systemd/dracut, my work machine is running Fedora 34, and > there are several problems I'm trying to solve: > 1. Users have to input the password in the kdump kernel environment. > But users often don't have shell access to the kdump environment. > (headless server, graphic card not working after kexec, both are very > common) > 2. LUKS2 prefers Argon2 as the key derivation function, designed to > use a lot of memory. kdump is expected to use a minimal amount of > memory. Users will have to reserve a huge amount of memory for kdump > to work (eg. 1G reserve for kdump with 4G total memory which is not > reasonable). When I added Argon2 to LUKS2, I actually expected such issues. Despite some people beats me that they cannot use arbitrary amount of memory, we have some hard limits that were selected that it should work on most recent systems. Maybe kdump can live with it. - maximum memory cost limit is 4GB, no LUKS2 device can use more for Argon2 - we never use more than half of available physical memory (measured on the host where the device was formatted) - required amount of memory is visible in LUKS2 metadata (luksDump) for the particular keyslot (Memory: the value is in kB) - we use benchmark to calculate memory cost with prefered unlocking time 2 seconds (again, on the device where LUKS was formatted) Small systems (like RPi2) the uses much smaller acceptable values. You can configure all costs (time, memory, threads) during format or even set them to predefined values. I am sorry, but there is really no way around this - and the requeired memory must be physical memory (otherwise it slows down extremely). This is a feature, not a bug :-) > To fix these problems, I tried to pass the master key to the second > kernel directly via initramfs. Kdump will modify the initramfs in > ramfs to include the key, kexec_load it, and never write to any actual > back storage. This worked with old LUKS configurations. Well, passing volume key this way is quite insecure, but perhaps acceptable for debugging. > > But LUKS2/cryptsetup now stores the key in the kernel keyring by > default. The key is accessible from userspace. If you are talking about volume key (not passsphrase), it is not available from userspace. Only reference to it. But you can use this reference to construct in-kernel dm-crypt device. Please read https://gitlab.com/cryptsetup/cryptsetup/-/blob/master/docs/Keyring.txt > Users can enter the password to start kdump manually and then it will > work, but usually people expect kdump service to start automatically. > > (WIP patch series: > https://lists.fedoraproject.org/archives/list/ke...@lists.fedoraproject.org/thread/RTYJEQ4BV25JYVYJHTTPOK476FUEJOWW/) > > I've several ideas about how to improve it but not sure which one is > better, and if this is a good idea after all: > 1. Simply introduce a config to let systemd-cryptsetup disable kernel > keyring on setup, there is currently no such option. Well, that option could be useful anyway and we have support for it in cryptsetup (--disable-keyring CLI option) and libcryptsetup, so why not. Just this should not be a default option. This is should be patch for systemd-cryptsetup only as libcryptsetup supports it. ... > 2. If we can let the key stay in userspace for a little longer, eg. > for systems booted with dracut/systemd, when > systemd-cryptsetup@%s.service opens the crypt device, keep the key in > dm-crypt. And later when services like kdump have finished loading, > cryptsetup can refresh the device and store the key in the kernel > keyring again. We invalidate volume key in keyring after libceyposetup operation is finished (and kernel removes the reference once keyring garbage collection is
Re: Next for ARC - researching how to replace PDC
Hi! > - fedora messaging - https://github.com/fedora-infra/fedora-messaging Hmm, I don't think we're using PDC in fedora messaging, but I might be wrong. Where did you find it? A. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to 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: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Next for ARC - researching how to replace PDC
On Mon, Apr 19, 2021 at 5:13 AM Adam Saleh wrote: > > Hi everyone, > > ARC team - that is me, Vipul and Mark, are looking to figure out > possible ways how we could replace our current PDC [0] whose project > has gone unmaintained for years [1]. > > We plan to share what we find out in our > https://fedora-arc.readthedocs.io/en/latest/pdc/index.html > > It would be really helpful if any other users of PDC would reach out, > so that we don't leave anybody behind. > > First, is there anybody using the PDC UI? So far we have identified, > only api/cli usage. > > Second, based on a cursory search through our infrastructure > configuration far we identified usage in: > > - Release Engineering scripts - https://pagure.io/releng/ > - fedpkg - https://pagure.io/fedpkg > - pungi - https://pagure.io/pungi/ > - fedfind - https://pagure.io/fedora-qa/fedfind > - bodhi - https://github.com/fedora-infra/bodhi/ > - pagure - https://pagure.io/pagure/ > - MBS - https://pagure.io/fm-orchestrator/ > - mirrormanager scripts - https://pagure.io/Fedora-Infra/ansible > - ODCS - https://pagure.io/odcs > - the new hotness - https://github.com/fedora-infra/the-new-hotness > - fedora messaging - https://github.com/fedora-infra/fedora-messaging > - osbs client - https://github.com/containerbuildsystem/osbs-client > > Is there anything we are forgetting about? > GNOME Software uses it: https://gitlab.gnome.org/GNOME/gnome-software/-/blob/master/plugins/fedora-pkgdb-collections/gs-plugin-fedora-pkgdb-collections.c Absent of something better, Plasma Discover will too. -- 真実はいつも一つ！/ Always, there's only one truth! ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to 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: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: [dm-crypt] Kdump with full-disk LUKS encryption
Hi, Thanks a lot, these info are very helpful. Better to keep it for debugging for now, and ask users to use it very carefully. On Tue, Apr 20, 2021 at 3:54 PM Milan Broz wrote: > > Hi, > > TL;DR what you are trying to do is to actually reverse many security measures > we added. It is perhaps acceptable for debugging but hardly for real generic > system. > > - using memory-hard function increases cost of dictionary and brute-force > attacks > You can always decrease amount of memory needed, but you should do it only > if you know that security margin is ok (like password is randomly generated > with enough entropy). > > - key is in keyring to remove possibility for normal userspace to receive > the key from kernel. Moreover, there is no need to retain kernel in keyring > once > dm-crypt device is activated. (It is still in kernel memory but only in crypto > functions context). (Systemd also uses keyring to cache passphrase but that's > different thing.) > > You can still use old way for activation with --disable-keyring activation, > but then you disable this possibility. > > More comments below. > > On 19/04/2021 12:00, Kairui Song wrote: > > Hi all, > > > > I'm currently trying to add kdump support for systemd with full-disk > > LUKS encryption. vmcores contain sensitive data so they should also be > > protected, and network dumps sometimes are not available. So kdump has > > to open the LUKS encrypted device in the kdump environment. > > > > I'm using systemd/dracut, my work machine is running Fedora 34, and > > there are several problems I'm trying to solve: > > 1. Users have to input the password in the kdump kernel environment. > > But users often don't have shell access to the kdump environment. > > (headless server, graphic card not working after kexec, both are very > > common) > > 2. LUKS2 prefers Argon2 as the key derivation function, designed to > > use a lot of memory. kdump is expected to use a minimal amount of > > memory. Users will have to reserve a huge amount of memory for kdump > > to work (eg. 1G reserve for kdump with 4G total memory which is not > > reasonable). > > When I added Argon2 to LUKS2, I actually expected such issues. Despite > some people beats me that they cannot use arbitrary amount of memory, > we have some hard limits that were selected that it should work on most recent > systems. Maybe kdump can live with it. > > - maximum memory cost limit is 4GB, no LUKS2 device can use more for Argon2 > - we never use more than half of available physical memory >(measured on the host where the device was formatted) > - required amount of memory is visible in LUKS2 metadata (luksDump) >for the particular keyslot (Memory: the value is in kB) > - we use benchmark to calculate memory cost with prefered unlocking >time 2 seconds (again, on the device where LUKS was formatted) >Small systems (like RPi2) the uses much smaller acceptable values. > You can configure all costs (time, memory, threads) during format > or even set them to predefined values. > > I am sorry, but there is really no way around this - and the requeired > memory must be physical memory (otherwise it slows down extremely). > This is a feature, not a bug :-) > > > > To fix these problems, I tried to pass the master key to the second > > kernel directly via initramfs. Kdump will modify the initramfs in > > ramfs to include the key, kexec_load it, and never write to any actual > > back storage. This worked with old LUKS configurations. > > Well, passing volume key this way is quite insecure, but perhaps > acceptable for debugging. > > > > > But LUKS2/cryptsetup now stores the key in the kernel keyring by > > default. The key is accessible from userspace. > > If you are talking about volume key (not passsphrase), it is not > available from userspace. Only reference to it. But you can use > this reference to construct in-kernel dm-crypt device. > Please read > https://gitlab.com/cryptsetup/cryptsetup/-/blob/master/docs/Keyring.txt > > > Users can enter the password to start kdump manually and then it will > > work, but usually people expect kdump service to start automatically. > > > > (WIP patch series: > > https://lists.fedoraproject.org/archives/list/ke...@lists.fedoraproject.org/thread/RTYJEQ4BV25JYVYJHTTPOK476FUEJOWW/) > > > > I've several ideas about how to improve it but not sure which one is > > better, and if this is a good idea after all: > > 1. Simply introduce a config to let systemd-cryptsetup disable kernel > > keyring on setup, there is currently no such option. > > Well, that option could be useful anyway and we have support for it > in cryptsetup (--disable-keyring CLI option) and libcryptsetup, so why not. > Just this should not be a default option. > > This is should be patch for systemd-cryptsetup only as libcryptsetup supports > it. > > ... > > > 2. If we can let the key stay in userspace for a little longer, eg. > > for systems booted with dracut/systemd, when > > syst
Fedora rawhide compose report: 20210420.n.0 changes
OLD: Fedora-Rawhide-20210419.n.0 NEW: Fedora-Rawhide-20210420.n.0 = SUMMARY = Added images:0 Dropped images: 0 Added packages: 11 Dropped packages:5 Upgraded packages: 140 Downgraded packages: 0 Size of added packages: 25.97 MiB Size of dropped packages:2.13 MiB Size of upgraded packages: 5.54 GiB Size of downgraded packages: 0 B Size change of upgraded packages: 103.77 MiB Size change of downgraded packages: 0 B = ADDED IMAGES = = DROPPED IMAGES = = ADDED PACKAGES = Package: ghc-koji-0.0.1-1.fc35 Summary: Koji buildsystem XML-RPC API bindings RPMs:ghc-koji ghc-koji-devel ghc-koji-doc ghc-koji-prof Size:2.52 MiB Package: gsl-lite-0.38.0-1.fc35 Summary: Header-only version of ISO C++ Guidelines Support Library (GSL) RPMs:gsl-lite-devel Size:340.16 KiB Package: highfive-2.2.2-1.fc35 Summary: Header-only C++ HDF5 interface RPMs:highfive-devel highfive-doc Size:14.00 MiB Package: hikari-2.3.0-1.fc35 Summary: Stacking Wayland compositor with tiling capabilities RPMs:hikari Size:4.46 MiB Package: php-composer-xdebug-handler2-2.0.0-1.fc35 Summary: Restarts a process without Xdebug, version 2 RPMs:php-composer-xdebug-handler2 Size:22.47 KiB Package: python-contextualbandits-0.3.14-1.fc35 Summary: Python Implementations of Algorithms for Contextual Bandits RPMs:python-contextualbandits-doc python3-contextualbandits Size:2.11 MiB Package: python-doxytag2zealdb-0.3.1-1.fc35 Summary: Create a SQLite3 database from a Doxygen tag file RPMs:doxytag2zealdb python3-doxytag2zealdb Size:61.62 KiB Package: python-op1repacker-0.2.6-1.fc35 Summary: Tool for unpacking, modding and repacking OP-1 firmware RPMs:op1repacker Size:86.27 KiB Package: python-pydyf-0.0.2-2.fc35 Summary: Low-level PDF creator RPMs:python3-pydyf Size:18.95 KiB Package: python-xeddsa-0.6.0~beta-3.fc35 Summary: Python implementation of the XEdDSA signature scheme RPMs:python3-xeddsa Size:476.09 KiB Package: wlroots0.12-0.12.0-1.fc35 Summary: A modular Wayland compositor library RPMs:wlroots0.12 wlroots0.12-devel Size:1.90 MiB = DROPPED PACKAGES = Package: jakarta-messaging-2.0.3-2.fc34 Summary: JMS / Jakarta Messaging API RPMs:jakarta-messaging jakarta-messaging-javadoc Size:461.00 KiB Package: jboss-el-3.0-api-1.0.13-6.fc34 Summary: JSR-341 Expression Language 3.0 API RPMs:jboss-el-3.0-api jboss-el-3.0-api-javadoc Size:455.43 KiB Package: jboss-servlet-3.1-api-1.0.2-5.fc34 Summary: Java Servlet 3.1 API RPMs:jboss-servlet-3.1-api jboss-servlet-3.1-api-javadoc Size:620.90 KiB Package: maven-verifier-1.7.2-4.fc34 Summary: Maven verifier RPMs:maven-verifier maven-verifier-javadoc Size:328.84 KiB Package: saxpath-1.0-23.fc34 Summary: Simple API for XPath RPMs:saxpath saxpath-javadoc Size:311.40 KiB = UPGRADED PACKAGES = Package: annobin-9.66-4.fc35 Old package: annobin-9.65-2.fc35 Summary: Annotate and examine compiled binary files RPMs: annobin-annocheck annobin-docs annobin-plugin-clang annobin-plugin-gcc annobin-plugin-llvm Added RPMs: annobin-docs Dropped RPMs: annobin Size: 1.22 MiB Size change: -299.59 KiB Changelog: * Fri Apr 09 2021 Nick Clifton - 9.66-1 - Fix anomolies reported by covscan. - Move documentation into a sub-package. * Thu Apr 15 2021 Martin Cermak - 9.66-2 - Fix bz1949570 * Fri Apr 16 2021 Petr Pisar - 9.66-3 - Correct a package rename (bug #1949570) - Require docs subpackage by the other ones because of a license - Build-requiring perl-interpreter is enough * Mon Apr 19 2021 Petr Pisar - 9.66-4 - Bump a release Package: arm-image-installer-3.4-1.fc35 Old package: arm-image-installer-3.3-1.fc35 Summary: Writes binary image files to any specified block device RPMs: arm-image-installer Size: 53.48 KiB Size change: 427 B Changelog: * Mon Apr 19 2021 Paul Whalen - 3.4-1 - Update to 3.4 - Add spi-flashing-disk script Package: audacity-3.0.2-2.fc35 Old package: audacity-3.0.0-2.fc35 Summary: Multitrack audio editor RPMs: audacity audacity-manual Size: 43.87 MiB Size change: -305.75 KiB Changelog: * Mon Apr 19 2021 Gwyn Ciesla - 3.0.2-1 - 3.0.2 * Mon Apr 19 2021 Gwyn Ciesla - 3.0.2-2 - Fix ffmpeg typo. Package: awscli-1.19.54-1.fc35 Old package: awscli-1.19.53-1.fc35 Summary: Universal Command Line Environment for AWS RPMs: awscli Size: 2.03 MiB Size change: -80 B Changelog: * Mon Apr 19 2021 Gwyn Ciesla - 1.19.54-1 - 1.19.54 Package: blender-1:2.92.0-5.fc35 Old package: blender-1:2.92.0-3.fc35 Summary: 3D modeling, animation, rendering and post-production RPMs: blender blender-rpm-macros Size: 125.47 MiB Size change: -444 B Changelog: * Mon Apr 19 2021 Luya Tshimbalanga - 1:2.92.0-4 - Rebuild for openxr
Schedule for Tuesdays's FESCo Meeting (2021-04-20)
Following is the list of topics that will be discussed in the FESCo meeting Tuesday at 17:00UTC in #fedora-meeting on irc.freenode.net. To convert UTC to your local time, take a look at http://fedoraproject.org/wiki/UTCHowto or run: date -d '2021-04-20 17:00 UTC' Links to all issues to be discussed can be found at: https://pagure.io/fesco/report/meeting_agenda = Discussed and Voted in the Ticket = #2593 F35 Change: RPM 4.17 https://pagure.io/fesco/issue/2593 APPROVED (+8, 0, 0) #2594 F35 Change: Smaller Container Base Image (remove sssd-client, util-linux) https://pagure.io/fesco/issue/2594 APPROVED (+7, 0, 0) = Followups = = New business = #2596 F35 Change: Switching Cyrus Sasl from BerkeleyDB to GDBM https://pagure.io/fesco/issue/2596 #2597 F35 Change: Debuginfod By Default https://pagure.io/fesco/issue/2597 = Open Floor = For more complete details, please visit each individual issue. The report of the agenda items can be found at https://pagure.io/fesco/report/meeting_agenda If you would like to add something to this agenda, you can reply to this e-mail, file a new issue at https://pagure.io/fesco, e-mail me directly, or bring it up at the end of the meeting, during the open floor topic. Note that added topics may be deferred until the following meeting. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to 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: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Fedora 34 compose report: 20210420.n.0 changes
OLD: Fedora-34-20210419.n.0 NEW: Fedora-34-20210420.n.0 = SUMMARY = Added images:0 Dropped images: 2 Added packages: 1 Dropped packages:0 Upgraded packages: 4 Downgraded packages: 0 Size of added packages: 3.37 MiB Size of dropped packages:0 B Size of upgraded packages: 198.96 MiB Size of downgraded packages: 0 B Size change of upgraded packages: 112.93 KiB Size change of downgraded packages: 0 B = ADDED IMAGES = = DROPPED IMAGES = Image: Astronomy_KDE live x86_64 Path: Labs/x86_64/iso/Fedora-Astronomy_KDE-Live-x86_64-34-20210419.n.0.iso Image: Xfce raw-xz armhfp Path: Spins/armhfp/images/Fedora-Xfce-34-20210419.n.0.armhfp.raw.xz = ADDED PACKAGES = Package: dionaea-0.7.0-9.fc33 Summary: Low interaction honeypot RPMs:dionaea dionaea-doc python3-dionaea Size:3.37 MiB = DROPPED PACKAGES = = UPGRADED PACKAGES = Package: pipewire-0.3.25-1.fc34 Old package: pipewire-0.3.24-4.fc34 Summary: Media Sharing Server RPMs: pipewire pipewire-alsa pipewire-devel pipewire-doc pipewire-gstreamer pipewire-jack-audio-connection-kit pipewire-libs pipewire-plugin-jack pipewire-pulseaudio pipewire-utils Size: 124.43 MiB Size change: 114.55 KiB Changelog: * Tue Apr 06 2021 Wim Taymans - 0.3.25-1 - Update to 0.3.25 Package: plasma-discover-5.21.4-2.fc34 Old package: plasma-discover-5.21.3-1.fc34 Summary: KDE and Plasma resources management GUI RPMs: plasma-discover plasma-discover-flatpak plasma-discover-libs plasma-discover-notifier plasma-discover-offline-updates plasma-discover-packagekit plasma-discover-snap Size: 41.91 MiB Size change: 3.91 KiB Changelog: * Tue Apr 06 2021 Jan Grulich - 5.21.4-1 - 5.21.4 * Fri Apr 16 2021 Rex Dieter - 5.21.4-2 - plasma-discover doesnt refresh metadata (#1903294) Package: xorg-x11-server-1.20.11-1.fc34 Old package: xorg-x11-server-1.20.10-5.fc34 Summary: X.Org X11 X server RPMs: xorg-x11-server-Xdmx xorg-x11-server-Xephyr xorg-x11-server-Xnest xorg-x11-server-Xorg xorg-x11-server-Xvfb xorg-x11-server-common xorg-x11-server-devel xorg-x11-server-source Size: 27.89 MiB Size change: -4.48 KiB Changelog: * Wed Apr 14 2021 Olivier Fourdan - 1.20.11-1 - xserver 1.20.11 (CVE-2021-3472 / ZDI-CAN-1259) Package: xorg-x11-server-Xwayland-21.1.1-1.fc34 Old package: xorg-x11-server-Xwayland-21.1.0-1.fc34 Summary: Xwayland RPMs: xorg-x11-server-Xwayland xorg-x11-server-Xwayland-devel Size: 4.73 MiB Size change: -1.04 KiB Changelog: * Wed Apr 14 2021 Olivier Fourdan - 21.1.1-1 - xwayland 21.1.1 (CVE-2021-3472 / ZDI-CAN-1259) = DOWNGRADED PACKAGES = ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to 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: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Next for ARC - researching how to replace PDC
On 4/19/21 11:13 AM, Adam Saleh wrote: Hi everyone, ARC team - that is me, Vipul and Mark, are looking to figure out possible ways how we could replace our current PDC [0] whose project has gone unmaintained for years [1]. We plan to share what we find out in our https://fedora-arc.readthedocs.io/en/latest/pdc/index.html It would be really helpful if any other users of PDC would reach out, so that we don't leave anybody behind. First, is there anybody using the PDC UI? So far we have identified, only api/cli usage. Second, based on a cursory search through our infrastructure configuration far we identified usage in: - Release Engineering scripts - https://pagure.io/releng/ - fedpkg - https://pagure.io/fedpkg - pungi - https://pagure.io/pungi/ - fedfind - https://pagure.io/fedora-qa/fedfind - bodhi - https://github.com/fedora-infra/bodhi/ - pagure - https://pagure.io/pagure/ - MBS - https://pagure.io/fm-orchestrator/ - mirrormanager scripts - https://pagure.io/Fedora-Infra/ansible - ODCS - https://pagure.io/odcs - the new hotness - https://github.com/fedora-infra/the-new-hotness - fedora messaging - https://github.com/fedora-infra/fedora-messaging - osbs client - https://github.com/containerbuildsystem/osbs-client Is there anything we are forgetting about? fedscm-admin? https://pagure.io/fedscm-admin/blob/main/f/fedscm_admin/pdc.py ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to 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: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: [dm-crypt] Antw: [EXT] [systemd-devel] Kdump with full-disk LUKS encryption
On 20/04/2021 08:05, Ulrich Windl wrote: Kairui Song schrieb am 19.04.2021 um 12:00 in > Nachricht > : >> Hi all, >> >> I'm currently trying to add kdump support for systemd with full‑disk >> LUKS encryption. vmcores contain sensitive data so they should also be >> protected, and network dumps sometimes are not available. So kdump has >> to open the LUKS encrypted device in the kdump environment. >> >> I'm using systemd/dracut, my work machine is running Fedora 34, and >> there are several problems I'm trying to solve: >> 1. Users have to input the password in the kdump kernel environment. >> But users often don't have shell access to the kdump environment. >> (headless server, graphic card not working after kexec, both are very >> common) >> 2. LUKS2 prefers Argon2 as the key derivation function, designed to >> use a lot of memory. kdump is expected to use a minimal amount of >> memory. Users will have to reserve a huge amount of memory for kdump >> to work (eg. 1G reserve for kdump with 4G total memory which is not >> reasonable). > > I'm not a LUKS specialist, but can't you use different KDFs in a different key > slot? Yes, you can (for LUKS2). There are also priorities, so you can configure "admin" keyslot that is never used unless explicitly specified. It can use different PBKDF and/or cost parameters. But this is not a solution for the mentioned problem - they have to work with arbitrary devices. Milan p.s. Some lists on cc rejects replies without subscription, so do not be surprised if you see only some replies. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to 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: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Fedora-Rawhide-20210420.n.0 compose check report
No missing expected images. Compose FAILS proposed Rawhide gating check! 1 of 43 required tests failed openQA tests matching unsatisfied gating requirements shown with **GATING** below Failed openQA tests: 10/189 (x86_64), 10/127 (aarch64) New failures (same test not failed in Fedora-Rawhide-20210419.n.0): ID: 862406 Test: x86_64 Server-dvd-iso install_repository_hd_variation URL: https://openqa.fedoraproject.org/tests/862406 ID: 862569 Test: aarch64 Workstation-raw_xz-raw.xz desktop_printing@uefi URL: https://openqa.fedoraproject.org/tests/862569 ID: 862625 Test: x86_64 universal install_scsi_updates_img **GATING** URL: https://openqa.fedoraproject.org/tests/862625 ID: 862677 Test: aarch64 universal install_blivet_lvmthin@uefi URL: https://openqa.fedoraproject.org/tests/862677 ID: 862682 Test: aarch64 universal install_blivet_resize_lvm@uefi URL: https://openqa.fedoraproject.org/tests/862682 Old failures (same test failed in Fedora-Rawhide-20210419.n.0): ID: 862428 Test: x86_64 Server-dvd-iso modularity_tests URL: https://openqa.fedoraproject.org/tests/862428 ID: 862431 Test: x86_64 Server-dvd-iso server_cockpit_updates URL: https://openqa.fedoraproject.org/tests/862431 ID: 862491 Test: x86_64 Silverblue-dvd_ostree-iso release_identification URL: https://openqa.fedoraproject.org/tests/862491 ID: 862546 Test: aarch64 Server-dvd-iso modularity_tests@uefi URL: https://openqa.fedoraproject.org/tests/862546 ID: 862637 Test: x86_64 universal upgrade_2_server_domain_controller URL: https://openqa.fedoraproject.org/tests/862637 ID: 862644 Test: x86_64 universal upgrade_server_domain_controller URL: https://openqa.fedoraproject.org/tests/862644 ID: 862659 Test: x86_64 universal upgrade_2_realmd_client URL: https://openqa.fedoraproject.org/tests/862659 ID: 862660 Test: x86_64 universal upgrade_realmd_client URL: https://openqa.fedoraproject.org/tests/862660 ID: 862663 Test: aarch64 universal install_asian_language@uefi URL: https://openqa.fedoraproject.org/tests/862663 ID: 862692 Test: aarch64 universal upgrade_2_server_domain_controller@uefi URL: https://openqa.fedoraproject.org/tests/862692 ID: 862693 Test: aarch64 universal upgrade_minimal_64bit@uefi URL: https://openqa.fedoraproject.org/tests/862693 ID: 862695 Test: aarch64 universal upgrade_server_domain_controller@uefi URL: https://openqa.fedoraproject.org/tests/862695 ID: 862705 Test: aarch64 universal upgrade_2_realmd_client@uefi URL: https://openqa.fedoraproject.org/tests/862705 ID: 862706 Test: aarch64 universal upgrade_realmd_client@uefi URL: https://openqa.fedoraproject.org/tests/862706 ID: 862708 Test: x86_64 universal install_asian_language URL: https://openqa.fedoraproject.org/tests/862708 Soft failed openQA tests: 6/127 (aarch64), 3/189 (x86_64) (Tests completed, but using a workaround for a known bug) New soft failures (same test not soft failed in Fedora-Rawhide-20210419.n.0): ID: 862541 Test: aarch64 Server-dvd-iso install_vnc_client@uefi URL: https://openqa.fedoraproject.org/tests/862541 ID: 862564 Test: aarch64 Workstation-raw_xz-raw.xz install_arm_image_deployment_upload@uefi URL: https://openqa.fedoraproject.org/tests/862564 Old soft failures (same test soft failed in Fedora-Rawhide-20210419.n.0): ID: 862399 Test: x86_64 Server-dvd-iso install_vncconnect_client URL: https://openqa.fedoraproject.org/tests/862399 ID: 862440 Test: x86_64 Server-dvd-iso install_vnc_client URL: https://openqa.fedoraproject.org/tests/862440 ID: 862497 Test: x86_64 Cloud_Base-qcow2-qcow2 cloud_autocloud URL: https://openqa.fedoraproject.org/tests/862497 ID: 862503 Test: aarch64 Minimal-raw_xz-raw.xz install_arm_image_deployment_upload@uefi URL: https://openqa.fedoraproject.org/tests/862503 ID: 862516 Test: aarch64 Server-dvd-iso install_vncconnect_client@uefi URL: https://openqa.fedoraproject.org/tests/862516 ID: 862556 Test: aarch64 Server-raw_xz-raw.xz install_arm_image_deployment_upload@uefi URL: https://openqa.fedoraproject.org/tests/862556 ID: 862578 Test: aarch64 Cloud_Base-qcow2-qcow2 cloud_autocloud@uefi URL: https://openqa.fedoraproject.org/tests/862578 Passed openQA tests: 175/189 (x86_64), 111/127 (aarch64) New passes (same test not passed in Fedora-Rawhide-20210419.n.0): ID: 862468 Test: x86_64 KDE-live-iso desktop_login URL: https://openqa.fedoraproject.org/tests/862468 ID: 862518 Test: aarch64 Server-dvd-iso install_blivet_btrfs_preserve_home_uefi@uefi URL: https://openqa.fedoraproject.org/tests/862518 ID: 862525 Test: aarch64 Server-dvd-iso install_vnc_server@uefi URL: https://openqa.fedoraproject.org/tests/862525 ID: 862526 Test: aarch64 Server-dvd-iso server_freeipa_replication_master@uefi URL: https://openqa.fedoraproject.org/tests/862526 ID: 862527 Test: aarch64 Server-dvd-iso server_freeipa_replication_replica@uefi URL: https://openqa.fedoraproject.org/tests/
Re: [Fedocal] Reminder meeting : Prioritized bugs and issues
On Tue, Apr 20, 2021 at 7:06 AM wrote: > > You are kindly invited to the meeting: >Prioritized bugs and issues on 2021-04-21 from 11:00:00 to 12:00:00 > America/Indiana/Indianapolis >At fedora-meetin...@irc.freenode.net > The following bugs are on the agenda for tomorrow's meeting: * Cpu usage very high until touchpad is touched --- https://bugzilla.redhat.com/show_bug.cgi?id=1847627 * screen never reactivates after dimming or blanking --- https://bugzilla.redhat.com/show_bug.cgi?id=1900890 -- Ben Cotton He / Him / His Senior Program Manager, Fedora & CentOS Stream Red Hat TZ=America/Indiana/Indianapolis ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to 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: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F35 Change: Debuginfod By Default (Self-Contained Change proposal)
Hi - Björn Persson writes: > · How is it verified that files received from debuginfo servers have not > been tampered with? Following up further to this, we're planning to add optional client-side hash-verification of cached content, to provide some protection against tampering: https://sourceware.org/bugzilla/show_bug.cgi?id=27758 - FChE ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to 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: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: wlroots 0.13.0 update for rawhide and f34
Thank you for update. 'labwc' built https://koji.fedoraproject.org/koji/taskinfo?taskID=66343993 ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to 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: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Fedora-IoT-33-20210420.0 compose check report
No missing expected images. Failed openQA tests: 1/15 (aarch64) Old failures (same test failed in Fedora-IoT-33-20210406.0): ID: 863282 Test: aarch64 IoT-dvd_ostree-iso iot_clevis@uefi URL: https://openqa.fedoraproject.org/tests/863282 Soft failed openQA tests: 1/16 (x86_64) (Tests completed, but using a workaround for a known bug) Old soft failures (same test soft failed in Fedora-IoT-33-20210406.0): ID: 863265 Test: x86_64 IoT-dvd_ostree-iso iot_clevis URL: https://openqa.fedoraproject.org/tests/863265 Passed openQA tests: 15/16 (x86_64), 14/15 (aarch64) Installed system changes in test x86_64 IoT-dvd_ostree-iso install_default_upload: System load changed from 0.29 to 0.11 Previous test data: https://openqa.fedoraproject.org/tests/845893#downloads Current test data: https://openqa.fedoraproject.org/tests/863266#downloads -- Mail generated by check-compose: https://pagure.io/fedora-qa/check-compose ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to 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: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Next for ARC - researching how to replace PDC
On Tue, Apr 20, 2021 at 04:57:34AM -0400, Neal Gompa wrote: > > GNOME Software uses it: > https://gitlab.gnome.org/GNOME/gnome-software/-/blob/master/plugins/fedora-pkgdb-collections/gs-plugin-fedora-pkgdb-collections.c > > Absent of something better, Plasma Discover will too. Thats actually not pdc. :) Thats a artisanally crafted static json file in the format the old pkgdb used to publish. But yes, it would be nice if whatever replaced pdc handled this case as well. kevin signature.asc Description: PGP signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to 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: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: wlroots 0.13.0 update for rawhide and f34
Rebuilt :)! Thank you for the update! Le 19/04/2021 à 19:01, Aleksei Bavshin a écrit : wlroots-0.13 is now available in rawhide. The compatibility issues are resolved via `wlroots0.12` package which will be installed on update if there is anything that depends on `libwlroots.so.7`. No rebuilds are necessary. If your package depends on the old wlroots API or hardware support, you may need to adjust build requirements to one of following: BuildRequires: pkgconfig(wlroots) = 0.12.0 BuildRequires: (pkgconfig(wlroots) >= 0.12 with pkgconfig(wlroots) < 0.13) for future builds. --- @atim, @fnux, @lyessaadi, if you want to have new versions of cage/hikari/labwc to be available in f34 as a day 0 update, you are welcome to use the side-tag `f34-build-side-40158` (`fedpkg build --target=f34-build-side-40158`). Merge ETA is in 1 day. Although in the case of hikari that might not work, as the side-tag does not contain libucl from `f34-updates-testing` :( On 4/7/21 1:54 PM, Aleksei Bavshin wrote: Greetings, wlroots 0.13.0 and sway 1.6 have been released today. As usual, the update is API and ABI breaking and all dependent packages must be rebuilt. For all the dependents I identified either upstream patches or ETA for the new release and have successful copr builds. I'm planning to create rawhide side-tag later today, rebuild all @sway-sig packages and send PRs with instructions to the packages I don't have access to. The side-tag will be merged in a week or when all the rebuilds are done. I also plan to prepare a day 0 update for f34 once rawhide rebuilds are completed. Let me know if you have any concerns about that. BCC: maintainer aliases for cage, labwc, phoc and wayfire ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to 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: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Fedora-34-20210420.n.0 compose check report
Missing expected images: Xfce raw-xz armhfp Failed openQA tests: 2/189 (x86_64), 2/127 (aarch64) New failures (same test not failed in Fedora-34-20210419.n.0): ID: 862944 Test: x86_64 universal install_sata@uefi URL: https://openqa.fedoraproject.org/tests/862944 ID: 863002 Test: aarch64 universal install_blivet_resize_lvm@uefi URL: https://openqa.fedoraproject.org/tests/863002 Old failures (same test failed in Fedora-34-20210419.n.0): ID: 862908 Test: x86_64 universal install_asian_language URL: https://openqa.fedoraproject.org/tests/862908 ID: 862983 Test: aarch64 universal install_asian_language@uefi URL: https://openqa.fedoraproject.org/tests/862983 Soft failed openQA tests: 6/127 (aarch64), 4/189 (x86_64) (Tests completed, but using a workaround for a known bug) New soft failures (same test not soft failed in Fedora-34-20210419.n.0): ID: 863012 Test: aarch64 universal upgrade_2_server_domain_controller@uefi URL: https://openqa.fedoraproject.org/tests/863012 Old soft failures (same test soft failed in Fedora-34-20210419.n.0): ID: 862719 Test: x86_64 Server-dvd-iso install_vncconnect_client URL: https://openqa.fedoraproject.org/tests/862719 ID: 862760 Test: x86_64 Server-dvd-iso install_vnc_client URL: https://openqa.fedoraproject.org/tests/862760 ID: 862817 Test: x86_64 Cloud_Base-qcow2-qcow2 cloud_autocloud URL: https://openqa.fedoraproject.org/tests/862817 ID: 862823 Test: aarch64 Minimal-raw_xz-raw.xz install_arm_image_deployment_upload@uefi URL: https://openqa.fedoraproject.org/tests/862823 ID: 862861 Test: aarch64 Server-dvd-iso install_vnc_client@uefi URL: https://openqa.fedoraproject.org/tests/862861 ID: 862876 Test: aarch64 Server-raw_xz-raw.xz install_arm_image_deployment_upload@uefi URL: https://openqa.fedoraproject.org/tests/862876 ID: 862898 Test: aarch64 Cloud_Base-qcow2-qcow2 cloud_autocloud@uefi URL: https://openqa.fedoraproject.org/tests/862898 ID: 862957 Test: x86_64 universal upgrade_2_server_domain_controller URL: https://openqa.fedoraproject.org/tests/862957 ID: 863362 Test: aarch64 Server-dvd-iso install_vncconnect_client@uefi URL: https://openqa.fedoraproject.org/tests/863362 Passed openQA tests: 119/127 (aarch64), 182/189 (x86_64) New passes (same test not passed in Fedora-34-20210419.n.0): ID: 862839 Test: aarch64 Server-dvd-iso install_default_upload@uefi URL: https://openqa.fedoraproject.org/tests/862839 ID: 862840 Test: aarch64 Server-dvd-iso server_cockpit_default@uefi URL: https://openqa.fedoraproject.org/tests/862840 ID: 862842 Test: aarch64 Server-dvd-iso server_filesystem_default@uefi URL: https://openqa.fedoraproject.org/tests/862842 ID: 862846 Test: aarch64 Server-dvd-iso server_freeipa_replication_master@uefi URL: https://openqa.fedoraproject.org/tests/862846 ID: 862847 Test: aarch64 Server-dvd-iso server_freeipa_replication_replica@uefi URL: https://openqa.fedoraproject.org/tests/862847 ID: 862848 Test: aarch64 Server-dvd-iso server_remote_logging_server@uefi URL: https://openqa.fedoraproject.org/tests/862848 ID: 862849 Test: aarch64 Server-dvd-iso server_role_deploy_database_server@uefi URL: https://openqa.fedoraproject.org/tests/862849 ID: 862850 Test: aarch64 Server-dvd-iso server_role_deploy_domain_controller@uefi URL: https://openqa.fedoraproject.org/tests/862850 ID: 862852 Test: aarch64 Server-dvd-iso base_service_manipulation@uefi URL: https://openqa.fedoraproject.org/tests/862852 ID: 862855 Test: aarch64 Server-dvd-iso realmd_join_sssd@uefi URL: https://openqa.fedoraproject.org/tests/862855 ID: 862856 Test: aarch64 Server-dvd-iso base_reboot_unmount@uefi URL: https://openqa.fedoraproject.org/tests/862856 ID: 862859 Test: aarch64 Server-dvd-iso release_identification@uefi URL: https://openqa.fedoraproject.org/tests/862859 ID: 862862 Test: aarch64 Server-dvd-iso server_freeipa_replication_client@uefi URL: https://openqa.fedoraproject.org/tests/862862 ID: 862863 Test: aarch64 Server-dvd-iso server_firewall_default@uefi URL: https://openqa.fedoraproject.org/tests/862863 ID: 862864 Test: aarch64 Server-dvd-iso base_selinux@uefi URL: https://openqa.fedoraproject.org/tests/862864 ID: 862865 Test: aarch64 Server-dvd-iso base_system_logging@uefi URL: https://openqa.fedoraproject.org/tests/862865 ID: 862866 Test: aarch64 Server-dvd-iso modularity_tests@uefi URL: https://openqa.fedoraproject.org/tests/862866 ID: 862867 Test: aarch64 Server-dvd-iso base_update_cli@uefi URL: https://openqa.fedoraproject.org/tests/862867 ID: 862868 Test: aarch64 Server-dvd-iso server_cockpit_basic@uefi URL: https://openqa.fedoraproject.org/tests/862868 ID: 862869 Test: aarch64 Server-dvd-iso base_services_start@uefi URL: https://openqa.fedoraproject.org/tests/862869 ID: 862870 Test: aarch64 Server-dvd-iso realmd_join_cockpit@uefi URL: https://openqa.fedoraproject.org/tests/862870 ID: 862871 Te
Fedora-IoT-34-20210420.0 compose check report
No missing expected images. Failed openQA tests: 1/15 (aarch64) Old failures (same test failed in Fedora-IoT-34-20210418.0): ID: 863382 Test: aarch64 IoT-dvd_ostree-iso iot_clevis@uefi URL: https://openqa.fedoraproject.org/tests/863382 Soft failed openQA tests: 1/16 (x86_64) (Tests completed, but using a workaround for a known bug) Old soft failures (same test soft failed in Fedora-IoT-34-20210418.0): ID: 863365 Test: x86_64 IoT-dvd_ostree-iso iot_clevis URL: https://openqa.fedoraproject.org/tests/863365 Passed openQA tests: 15/16 (x86_64), 14/15 (aarch64) -- Mail generated by check-compose: https://pagure.io/fedora-qa/check-compose ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to 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: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Heads up, upcoming mass spec update to explicitly BuildRequire python3-setuptools
Congratulations, this change impacted tons of packages! That's also a nice step towards more explicit build dependencies. I understood that it's also the purpose of the pyproject.toml file ;-) Victor On Mon, Apr 19, 2021 at 2:39 PM Tomas Hrnciar wrote: > > Hello everyone, > > we successfully pushed explicit python3-setuptools BuildRequire to all > affected packages. As mentioned in the Change proposal, there is no need to > rebuild them, it will be done together with Python 3.10. mass rebuild. > > Regards, > Tomáš Hrnčiar > > On Fri, Mar 26, 2021 at 2:50 PM Tomas Hrnciar wrote: >> >> Hello everyone, >> >> some of you might have already seen the F35 Change [0] we submitted last >> week. >> >> We are trying to reduce the number of Python packages unnecessarily >> Requiring python3-setuptools. If you are interested in technical details see >> the change proposal [1], there is a broad explanation of why we are doing >> this. >> >> If the change is approved by FESCo we plan to do the mass spec update that >> will add explicit BuildRequire on python3-setuptools for all affected >> packages. We'll try to make this addition consistent with the actual style >> used in the spec files, but nobody's perfect and there might be some >> discrepancies; so please, if your package is listed below, check this diff >> [2] to see how the change will look like. If you disagree with the way how >> the BuildRequires will be added, feel free to add it yourself in any other >> way you prefer before 2021-04-15. A push to the rawhide/main branch in >> dist-git is sufficient, no need to bump the release or rebuild the package. >> >> We plan to update the list of affected packages again before we actually do >> the change. If you wish to opt-out of this change entirely, please let us >> know by editing the change wiki page and moving your package into the >> "Packages to be ignored" section [3] before 2021-04-15. However, bear in >> mind that this will likely cause future failures to build from source if >> your package actually needs setuptools to build. >> >> Thank you for your cooperation. >> Tomáš Hrnčiar >> >> [0] >> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/LGAUGOYHFKQXTS55IRWSIUVVAO3YHD5R/ >> [1] >> https://fedoraproject.org/wiki/Changes/Reduce_dependencies_on_python3-setuptools >> [2] >> https://github.com/hrnciar/add-setuptools-buildrequire/compare/c082a1a...a60a447 >> [3] >> https://fedoraproject.org/wiki/Changes/Reduce_dependencies_on_python3-setuptools#Packages_to_be_ignored >> >> List of all affected packages: >> >> Maintainers by package: >> 0ad ignatenkobrain pcpa pwalter >> OpenMolcas jussilehtola >> PyGreSQL hhorak jmlich odubaj panovotn pkubat praiskup >> R2spec pingou >> ViTables tnorth zbyszek >> ansible-review dcallagh ttrinks >> barman slaanesh tsao >> blender design-sw hobbes1069 ignatenkobrain kwizart luya roma >> s4504kr slaanesh >> btrfs-progs ignatenkobrain josef ngompa sandeen >> bumpversion duriantang jdornak >> calypso rathann >> cinchgreghellings >> commissaire-client mbarnes smilner >> cppcheck c72578 jussilehtola sgrubb >> cranclenkaseg >> crudini apevec jruzicka pbrady >> cxxtest mgieseki >> datanommer ralph >> dlib bizdelnick luya >> ec2-hibinit-agentdavdunc >> electrum tredaell >> fbthrift dcavalca filbranden salimma >> fedora-messaging abompard >> firefox alexl caolanm erack gecko-maint jgrulich kalev kengert >> mbarnes rhughes rstrode sharkcz stransky tpopela ueno xhorak >> follydcavalca filbranden salimma >> fontforgefrixxon kevin pnemade >> gajimmichich suraia >> gau2grid jussilehtola >> gfal2-python adev andreamanzi >> gingalupinix >> git-filter-repo asn >> gns3-gui kwizart >> gns3-net-converter kwizart >> gns3-server kwizart nucleo >> gpsd fab mlichvar ttorling >> h5py stevetraylen terjeros >> khardmathstuf sdyroff >> kismon fab >> koji ausil kevin mikem puiterwijk >> lammps ellio167 junghans >> legofy lkf williamjmorenor >> libcaca hubbitus slaanesh thias >> libiptcdata dcm hobbes1069 jchaloup >> libnuml sagitter >> libreoffice caolanm dtardon erack sbergmann >> lldb airlied daveisfera jankratochvil sergesanspaille >> siddharths tstellar >> llvm dmalcolm ignatenkobrain jakub jistone kyle scottt >> sergesanspaille siddharths tstellar >> llvm10 sergesanspaille tstellar >> llvm11 sergesanspaille tstellar >> llvm7.0 jistone petersen se
Summary/Minutes from today's FESCo Meeting (2021-04-20)
= Discussed and Voted in the Ticket = #2595 F35 Change: Erlang 24 https://pagure.io/fesco/issue/2595 APPROVED (+5, 0, 0) = Meeting Minutes: https://meetbot.fedoraproject.org/fedora-meeting/2021-04-20/fesco.2021-04-20-17.01.html Minutes (text): https://meetbot.fedoraproject.org/fedora-meeting/2021-04-20/fesco.2021-04-20-17.01.txt Log: https://meetbot.fedoraproject.org/fedora-meeting/2021-04-20/fesco.2021-04-20-17.01.log.html Meeting summary --- * init process (zbyszek, 17:01:08) * #2596 F35 Change: Switching Cyrus Sasl from BerkeleyDB to GDBM (zbyszek, 17:03:20) * LINK: https://docs.google.com/spreadsheets/d/1z5eTSm3rtlKtEKPCxhI_wE861Xzg8kbvINWixSwQmLg/edit#gid=0 (dbelyavs, 17:12:25) * AGREED: APPROVED (+6, 0, 0) (zbyszek, 17:31:09) with the following qualification: move cyrus-sasl db change contingency deadline to F35 branch date (2021-08-10), add maybe/yes affected dependent packages to the change proposal page for easier tracking, add test plan for affected packages once changes land. * #2597 F35 Change: Debuginfod By Default (zbyszek, 17:31:40) * ACTION: dcantrell to raise the issue in a Council meeting (zbyszek, 17:49:08) * Next week's chair (zbyszek, 18:07:27) * ACTION: sgallagh will chair next meeting (sgallagh, 18:09:04) * Open Floor (sgallagh, 18:09:12) Meeting ended at 18:11:27 UTC. Action Items * dcantrell to raise the issue in a Council meeting * sgallagh will chair next meeting ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to 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: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F35 Change: Debuginfod By Default (Self-Contained Change proposal)
While trying to collect a backtrace for org.gnome.Tetravex, I got this in gdb: === Downloading separate debug info for /lib64/liblzma.so.5... Download failed: Timer expired. Continuing without debug info for /lib64/libbrotlicommon.so.1. Missing separate debuginfo for /lib64/libbrotlicommon.so.1 Try: dnf --enablerepo='*debug*' install /usr/lib/debug/.build-id/0e/bb3270fdbf40dbe56ea79d6630ac594b897ffe.debug Download failed: Timer expired. Continuing without debug info for /lib64/libzstd.so.1. Missing separate debuginfo for /lib64/libzstd.so.1 Try: dnf --enablerepo='*debug*' install /usr/lib/debug/.build-id/33/70d80a1bf749b3c2baaad0188c864ee9e4bbc4.debug Downloading separate debug info for /lib64/liblz4.so.1... Download failed: Timer expired. Continuing without debug info for /home/fcc/.var/app/org.gnome.Tetravex/cache/debuginfod_client/a2429c266188acc10181f6936915f35274bb4a38/debuginfo. Error while reading shared library symbols for /lib64/liblz4.so.1: could not find '.gnu_debugaltlink' file for /home/fcc/.var/app/org.gnome.Tetravex/cache/debuginfod_client/a2429c266188acc10181f6936915f35274bb4a38/debuginfo Downloading separate debug info for /lib64/libcap.so.2... === After running all the "Try" suggestions, the second run of gdb do not complain. I wanted to know how I can collect the required backtrace so that I can attach it to the bugzilla entry to help developers to looking at the bug. Thanks a lot! ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to 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: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
