Re: F36 Change: Drop NIS(+) support from PAM (System-Wide Change proposal)
On Thu, 2021-10-28 at 10:41 -0400, Simo Sorce wrote: > On Thu, 2021-10-28 at 10:28 -0400, Frank Ch. Eigler wrote: > > Stephen John Smoogen writes: > > > > > Mainly because it is the authentication service equivalent of > > > telnet**. Very simple to set up, very simple to use, and very > > > easy to > > > steal all the information about logins, users, and setups. [...] > > > > ... well, compared to what? LDAP commonly distributes crypttext > > passwords and databases with about the same amount of discernment > > and > > theft-enablement as ypserv. Plaintext as in telnet makes an > > appearance > > nowhere but with yppasswd, AFAIK, which is nonessential. > > LDAP is normally deployed on a secure channel (TLS or GSSAPI), that > the > client can cryptographically check. > > NIS is a clear text protocol that can be trivially MitMed to provide > arbitrary information to the target system. > > Also generally LDAP *does not* in fact distribute passwords, most > systems use the LDAP Bind operation to test a password and the LDAP > server does *not* provide access to password hashes. > > > I thin k it is legitimate to question whether it is yet time to drop > this obsolete protocol (NIS) on backwards compatibility grounds. > But on security grounds it is indefensible, don't go there. There's no question NIS has poor security, as bad a using a local password plus shadow file anyway. People that use it must know that. The valid use is company internal only, on systems whose data is freely available to company personnel and where accounts and groups info. isn't security critical. It's been that way for many, many years ... it's no secret. It's a pity NIS+ was such a pain to setup and use ... a bridge to far IMHO ... Ian ___ 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-35-20211028.n.1 compose check report
No missing expected images. Failed openQA tests: 4/204 (x86_64), 2/141 (aarch64) New failures (same test not failed in Fedora-35-20211028.n.0): ID: 1044974 Test: x86_64 Server-dvd-iso install_default_upload URL: https://openqa.fedoraproject.org/tests/1044974 ID: 1045055 Test: x86_64 KDE-live-iso desktop_notifications_postinstall URL: https://openqa.fedoraproject.org/tests/1045055 ID: 1045114 Test: aarch64 Server-dvd-iso install_repository_hd_variation@uefi URL: https://openqa.fedoraproject.org/tests/1045114 ID: 1045170 Test: x86_64 universal install_btrfs@uefi URL: https://openqa.fedoraproject.org/tests/1045170 Old failures (same test failed in Fedora-35-20211028.n.0): ID: 1045048 Test: x86_64 KDE-live-iso apps_startstop URL: https://openqa.fedoraproject.org/tests/1045048 ID: 1045149 Test: aarch64 Workstation-raw_xz-raw.xz gedit@uefi URL: https://openqa.fedoraproject.org/tests/1045149 Soft failed openQA tests: 4/204 (x86_64), 2/141 (aarch64) (Tests completed, but using a workaround for a known bug) Old soft failures (same test soft failed in Fedora-35-20211028.n.0): ID: 1045029 Test: x86_64 Workstation-live-iso gedit URL: https://openqa.fedoraproject.org/tests/1045029 ID: 1045068 Test: x86_64 Silverblue-dvd_ostree-iso evince URL: https://openqa.fedoraproject.org/tests/1045068 ID: 1045069 Test: x86_64 Silverblue-dvd_ostree-iso gedit URL: https://openqa.fedoraproject.org/tests/1045069 ID: 1045078 Test: x86_64 Cloud_Base-qcow2-qcow2 cloud_autocloud URL: https://openqa.fedoraproject.org/tests/1045078 ID: 1045145 Test: aarch64 Workstation-raw_xz-raw.xz install_arm_image_deployment_upload@uefi URL: https://openqa.fedoraproject.org/tests/1045145 ID: 1045162 Test: aarch64 Cloud_Base-qcow2-qcow2 cloud_autocloud@uefi URL: https://openqa.fedoraproject.org/tests/1045162 Passed openQA tests: 137/141 (aarch64), 171/204 (x86_64) New passes (same test not passed in Fedora-35-20211028.n.0): ID: 1045155 Test: aarch64 Workstation-raw_xz-raw.xz evince@uefi URL: https://openqa.fedoraproject.org/tests/1045155 Skipped non-gating openQA tests: 25 of 345 Installed system changes in test x86_64 Server-boot-iso install_default@uefi: System load changed from 0.01 to 0.14 Previous test data: https://openqa.fedoraproject.org/tests/1043573#downloads Current test data: https://openqa.fedoraproject.org/tests/1044952#downloads Installed system changes in test x86_64 Workstation-live-iso install_default_upload: System load changed from 0.68 to 0.47 Previous test data: https://openqa.fedoraproject.org/tests/1043634#downloads Current test data: https://openqa.fedoraproject.org/tests/1045013#downloads Installed system changes in test x86_64 Workstation-live-iso install_default@uefi: 1 services(s) added since previous compose: geoclue.service System load changed from 0.49 to 0.68 Previous test data: https://openqa.fedoraproject.org/tests/1043647#downloads Current test data: https://openqa.fedoraproject.org/tests/1045026#downloads Installed system changes in test x86_64 KDE-live-iso install_default@uefi: System load changed from 0.51 to 0.78 Previous test data: https://openqa.fedoraproject.org/tests/1043665#downloads Current test data: https://openqa.fedoraproject.org/tests/1045044#downloads Installed system changes in test x86_64 Silverblue-dvd_ostree-iso install_default_upload: Used swap changed from 5 MiB to 7 MiB System load changed from 0.57 to 0.95 Previous test data: https://openqa.fedoraproject.org/tests/1043680#downloads Current test data: https://openqa.fedoraproject.org/tests/1045059#downloads Installed system changes in test aarch64 Server-dvd-iso install_default_upload@uefi: System load changed from 0.10 to 0.31 Previous test data: https://openqa.fedoraproject.org/tests/1044171#downloads Current test data: https://openqa.fedoraproject.org/tests/1045095#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
Fedora 35 compose report: 20211028.n.1 changes
OLD: Fedora-35-20211028.n.0
NEW: Fedora-35-20211028.n.1
= SUMMARY =
Added images:1
Dropped images: 0
Added packages: 1
Dropped packages:0
Upgraded packages: 7
Downgraded packages: 0
Size of added packages: 37.11 KiB
Size of dropped packages:0 B
Size of upgraded packages: 79.14 MiB
Size of downgraded packages: 0 B
Size change of upgraded packages: -921.87 KiB
Size change of downgraded packages: 0 B
= ADDED IMAGES =
Image: Container_Minimal_Base docker aarch64
Path:
Container/aarch64/images/Fedora-Container-Minimal-Base-35-20211028.n.1.aarch64.tar.xz
= DROPPED IMAGES =
= ADDED PACKAGES =
Package: rust-thread-tree-0.3.2-1.fc35
Summary: Tree-structured thread pool for splitting jobs hierarchically
RPMs:rust-thread-tree+default-devel
rust-thread-tree+unstable-thread-sea-devel rust-thread-tree-devel
Size:37.11 KiB
= DROPPED PACKAGES =
= UPGRADED PACKAGES =
Package: PackageKit-1.2.4-3.fc35
Old package: PackageKit-1.2.4-2.fc35
Summary: Package management service
RPMs: PackageKit PackageKit-command-not-found PackageKit-cron
PackageKit-glib PackageKit-glib-devel PackageKit-gstreamer-plugin
PackageKit-gtk3-module
Size: 6.76 MiB
Size change: 22.03 KiB
Changelog:
* Fri Oct 22 2021 Owen Taylor - 1.2.4-3
- Add patch to fix #2016510
Package: anaconda-35.22.2-3.fc35
Old package: anaconda-35.22.2-2.fc35
Summary: Graphical system installer
RPMs: anaconda anaconda-core anaconda-dracut anaconda-gui
anaconda-install-env-deps anaconda-install-img-deps anaconda-live anaconda-tui
anaconda-widgets anaconda-widgets-devel
Size: 19.85 MiB
Size change: -488.80 KiB
Changelog:
* Mon Oct 25 2021 Martin Kolman - 35.22.2-3
- Show correctly that no admin user is set up (#2015508) (vslavik)
Package: kbd-2.4.0-8.fc35
Old package: kbd-2.4.0-7.fc35
Summary: Tools for configuring the console (keyboard, virtual terminals,
etc.)
RPMs: kbd kbd-legacy kbd-misc
Size: 3.81 MiB
Size change: 1.87 KiB
Changelog:
* Thu Oct 21 2021 Adam Williamson - 2.4.0-8
- Symlink fa.map.gz to ara.map.gz so Arabic console layout works (#2015972)
- Drop one mapping from fa.map that causes it to fail to load
Package: mutter-41.0-4.fc35
Old package: mutter-41.0-3.fc35
Summary: Window and compositing manager based on Clutter
RPMs: mutter mutter-devel mutter-tests
Size: 16.69 MiB
Size change: -3.05 KiB
Changelog:
* Mon Oct 25 2021 Adam Williamson - 41.0-4
- Backport MR #2059 to fix cursor jumping around in text editors (#2017192)
Package: sddm-0.19.0-18.fc35
Old package: sddm-0.19.0-15.fc35
Summary: QML based X11 desktop manager
RPMs: sddm sddm-themes
Size: 18.63 MiB
Size change: -485.34 KiB
Changelog:
* Wed Oct 13 2021 Timoth??e Ravier - 0.19.0-16
- Install the correct configuration for systemd-sysusers
* Sat Oct 23 2021 Adam Williamson - 0.19.0-17
- Patch udev rules, logind race and seat0 fallback (jlinton) (#2011991)
(#2016310)
* Mon Oct 25 2021 Adam Williamson - 0.19.0-18
- Simplify Wayland session hiding to just look for /dev/dri (jlinton)
(#2016788)
Package: toolbox-0.0.99.2^3.git075b9a8d2779-4.fc35
Old package: toolbox-0.0.99.2^3.git075b9a8d2779-2.fc35
Summary: Tool for containerized command line environments on Linux
RPMs: toolbox toolbox-experience toolbox-support toolbox-tests
Size: 10.93 MiB
Size change: -25.87 KiB
Changelog:
* Fri Oct 22 2021 Debarshi Ray -
0.0.99.2^3.git075b9a8d2779-3
- Ensure that binaries are run against their build-time ABI
- Require containers-common for ownership of %{_sysconfdir}/containers
* Mon Oct 25 2021 Debarshi Ray -
0.0.99.2^3.git075b9a8d2779-4
- Restore backwards compatibility with existing containers
Package: wireplumber-0.4.4-2.fc35
Old package: wireplumber-0.4.3-3.fc35
Summary: A modular session/policy manager for PipeWire
RPMs: wireplumber wireplumber-devel wireplumber-libs
Size: 2.47 MiB
Size change: 57.30 KiB
Changelog:
* Fri Oct 15 2021 Wim Taymans - 0.4.4-1
- wireplumber 0.4.4
* Sun Oct 24 2021 Neal Gompa - 0.4.4-2
- Ensure WirePlumber activates on upgrade to F35+ (#2016253)
= 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: [Rawhide] ImageMagick-6.9.12-26 available
On Thu, 2021-10-28 at 21:14 -0400, Nico Kadel-Garcia wrote: > On Thu, Oct 28, 2021 at 8:02 PM Sérgio Basto wrote: > > > > On Tue, 2021-10-26 at 16:42 -0700, Luya Tshimbalanga wrote: > > > Hello team, > > > > > > I would like to let you know ImageMagick-6.9.12-26 recently landed > > > upstream. > > > > Hello , when you update from 6.9.11 to 6.9.12, we need rebuild all > > depended packages because we got one soname bump and packages won't > > will give us rpm broken dependencies on dnf update > > I would not expect an update of the third number in semver numbering > to update the sonames. That sounds like an issue with the upstream > numbering versus release building. Unfortunately that is just how ImageMagick does things. -- Yaakov Selkowitz Senior Software Engineer - Platform Enablement Red Hat, Inc. ___ 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-20211028.n.1 compose check report
Missing expected images: Xfce raw-xz armhfp 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: 7/141 (aarch64), 5/206 (x86_64) New failures (same test not failed in Fedora-Rawhide-20211027.n.0): ID: 1044569 Test: aarch64 Workstation-raw_xz-raw.xz install_arm_image_deployment_upload@uefi URL: https://openqa.fedoraproject.org/tests/1044569 ID: 1044623 Test: x86_64 universal install_multi_empty@uefi URL: https://openqa.fedoraproject.org/tests/1044623 ID: 1044640 Test: x86_64 universal install_multi **GATING** URL: https://openqa.fedoraproject.org/tests/1044640 ID: 1044675 Test: aarch64 universal install_asian_language@uefi URL: https://openqa.fedoraproject.org/tests/1044675 ID: 1044680 Test: aarch64 universal install_european_language@uefi URL: https://openqa.fedoraproject.org/tests/1044680 ID: 1044684 Test: aarch64 universal install_cyrillic_language@uefi URL: https://openqa.fedoraproject.org/tests/1044684 ID: 1044715 Test: aarch64 universal install_addrepo_metalink_graphical@uefi URL: https://openqa.fedoraproject.org/tests/1044715 Old failures (same test failed in Fedora-Rawhide-20211027.n.0): ID: 1044452 Test: x86_64 Workstation-live-iso desktop_login URL: https://openqa.fedoraproject.org/tests/1044452 ID: 1044456 Test: x86_64 Workstation-live-iso apps_startstop URL: https://openqa.fedoraproject.org/tests/1044456 ID: 1044470 Test: x86_64 KDE-live-iso apps_startstop URL: https://openqa.fedoraproject.org/tests/1044470 ID: 1044558 Test: aarch64 Server-dvd-iso server_cockpit_basic@uefi URL: https://openqa.fedoraproject.org/tests/1044558 ID: 1044714 Test: aarch64 universal upgrade_minimal_64bit@uefi URL: https://openqa.fedoraproject.org/tests/1044714 Soft failed openQA tests: 4/206 (x86_64), 1/141 (aarch64) (Tests completed, but using a workaround for a known bug) Old soft failures (same test soft failed in Fedora-Rawhide-20211027.n.0): ID: 1044451 Test: x86_64 Workstation-live-iso gedit URL: https://openqa.fedoraproject.org/tests/1044451 ID: 1044490 Test: x86_64 Silverblue-dvd_ostree-iso evince URL: https://openqa.fedoraproject.org/tests/1044490 ID: 1044491 Test: x86_64 Silverblue-dvd_ostree-iso gedit URL: https://openqa.fedoraproject.org/tests/1044491 ID: 1044496 Test: x86_64 Cloud_Base-qcow2-qcow2 cloud_autocloud@uefi URL: https://openqa.fedoraproject.org/tests/1044496 ID: 1044586 Test: aarch64 Cloud_Base-qcow2-qcow2 cloud_autocloud@uefi URL: https://openqa.fedoraproject.org/tests/1044586 Passed openQA tests: 196/206 (x86_64), 117/141 (aarch64) New passes (same test not passed in Fedora-Rawhide-20211027.n.0): ID: 1044498 Test: x86_64 Cloud_Base-qcow2-qcow2 base_service_manipulation@uefi URL: https://openqa.fedoraproject.org/tests/1044498 ID: 1044515 Test: aarch64 Server-dvd-iso install_vncconnect_client@uefi URL: https://openqa.fedoraproject.org/tests/1044515 ID: 1044539 Test: aarch64 Server-dvd-iso install_vncconnect_server@uefi URL: https://openqa.fedoraproject.org/tests/1044539 ID: 1044687 Test: aarch64 universal install_scsi_updates_img@uefi URL: https://openqa.fedoraproject.org/tests/1044687 Skipped non-gating openQA tests: 16 of 347 Installed system changes in test x86_64 Server-boot-iso install_default: System load changed from 0.04 to 0.19 Previous test data: https://openqa.fedoraproject.org/tests/1041895#downloads Current test data: https://openqa.fedoraproject.org/tests/1044375#downloads Installed system changes in test x86_64 Server-dvd-iso install_default@uefi: System load changed from 0.15 to 0.28 Previous test data: https://openqa.fedoraproject.org/tests/1041902#downloads Current test data: https://openqa.fedoraproject.org/tests/1044382#downloads Installed system changes in test x86_64 Workstation-live-iso install_default_upload: Used swap changed from 3 MiB to 16 MiB 1 packages(s) added since previous compose: julietaula-montserrat-fonts 2 packages(s) removed since previous compose: julietaula-montserrat-base-web-fonts, julietaula-montserrat-fonts-common System load changed from 0.63 to 2.86 Average CPU usage changed from 12.8333 to 28.39047619 Previous test data: https://openqa.fedoraproject.org/tests/1041955#downloads Current test data: https://openqa.fedoraproject.org/tests/1044435#downloads Installed system changes in test x86_64 Workstation-live-iso install_default@uefi: Used swap changed from 5 MiB to 12 MiB 1 packages(s) added since previous compose: julietaula-montserrat-fonts 2 packages(s) removed since previous compose: julietaula-montserrat-base-web-fonts, julietaula-montserrat-fonts-common System load changed from 0.59 to 0.75 Previous test data: https://openqa.fedoraproject.org/tests/1041968#downloads Current test data: https://openqa.fedoraproject.org/tests/108#downloads Installed system
Re: [Rawhide] ImageMagick-6.9.12-26 available
On Thu, Oct 28, 2021 at 8:02 PM Sérgio Basto wrote: > > On Tue, 2021-10-26 at 16:42 -0700, Luya Tshimbalanga wrote: > > Hello team, > > > > I would like to let you know ImageMagick-6.9.12-26 recently landed > > upstream. > > Hello , when you update from 6.9.11 to 6.9.12, we need rebuild all > depended packages because we got one soname bump and packages won't > will give us rpm broken dependencies on dnf update I would not expect an update of the third number in semver numbering to update the sonames. That sounds like an issue with the upstream numbering versus release building. ___ 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: [Rawhide] ImageMagick-6.9.12-26 available
On Tue, 2021-10-26 at 16:42 -0700, Luya Tshimbalanga wrote: > Hello team, > > I would like to let you know ImageMagick-6.9.12-26 recently landed > upstream. Hello , when you update from 6.9.11 to 6.9.12, we need rebuild all depended packages because we got one soname bump and packages won't will give us rpm broken dependencies on dnf update I propose do a side-tag to update from 6.9.11 to 6.9.12 on F35 since ImageMagick should have been updated a long time ago and it was tested on rawhide . I know is a exception to guidelines , but wait more 6 months for end users have ImageMagick update is a bad alternative ... > Learning from the previous experiences, I or my co-maintainer are > planning to commit and build this package for Rawhide only in about a > week, so the following maintainers of the respective packages will > need > to get in sync: > > NsCDE > a2ps > anyremote > c-graph > caja-image-converter > chordpro-abc > conky-manager > darktable-tools-noise > devedeng > dvd-slideshow > epix > fbida > ffmulticonverter > freewrl > geeqie > gscan2pdf > gyazo > jumpnbump-menu > latex2rtf > libpst > lives > lyx > mediawiki > mtpaint > nautilus-image-converter > nemo-image-converter > perl-Graphics-TIFF-tests > perl-PDF-API2-tests > perl-PDF-Builder-tests > perl-Panotools-Script > playonlinux > rubygem-mini_magic > rubygem-rmagick > shutter > texlive-graphicxpsd > variety > vfrnav-utils > w3m-img > wdune > > > The scratch-build is successful on > https://koji.fedoraproject.org/koji/taskinfo?taskID=77869076 meaning > proven packagers are welcome to commit the changes. Let know if > anyone > has a question. > > Regards, > > -- > Luya Tshimbalanga > Fedora Design Team > Fedora Design Suite maintainer > ___ > 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 -- Sérgio M. B. ___ 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 compose report: 20211028.n.1 changes
OLD: Fedora-Rawhide-20211027.n.0 NEW: Fedora-Rawhide-20211028.n.1 = SUMMARY = Added images:0 Dropped images: 0 Added packages: 6 Dropped packages:0 Upgraded packages: 173 Downgraded packages: 1 Size of added packages: 3.57 MiB Size of dropped packages:0 B Size of upgraded packages: 7.73 GiB Size of downgraded packages: 15.30 MiB Size change of upgraded packages: 782.70 MiB Size change of downgraded packages: 175.69 KiB = ADDED IMAGES = = DROPPED IMAGES = = ADDED PACKAGES = Package: python-google-cloud-bigquery-connection-1.3.0-2.fc36 Summary: Python SDK for Google Cloud BigQuery Connection API RPMs:python3-google-cloud-bigquery-connection Size:59.99 KiB Package: python-google-cloud-bigquery-reservation-1.4.0-2.fc36 Summary: Python SDK for Google Cloud BigQuery Reservation API RPMs:python3-google-cloud-bigquery-reservation Size:81.21 KiB Package: python-google-cloud-bigquery-storage-2.9.1-2.fc36 Summary: Python SDK for Google Cloud BigQuery Storage API RPMs:python3-google-cloud-bigquery-storage python3-google-cloud-bigquery-storage+fastavro python3-google-cloud-bigquery-storage+pandas Size:211.09 KiB Package: python-grafeas-1.3.0-2.fc36 Summary: Python SDK for Google Cloud Grafeas API RPMs:python3-grafeas Size:87.74 KiB Package: rust-btrd-0.5.0-1.fc36 Summary: Btrfs debugger RPMs:btrd rust-btrd+default-devel rust-btrd-devel Size:3.11 MiB Package: rust-stratisd_proc_macros-0.1.0-1.fc36 Summary: Stratis daemon procedural macros RPMs:rust-stratisd_proc_macros+default-devel rust-stratisd_proc_macros-devel Size:24.99 KiB = DROPPED PACKAGES = = UPGRADED PACKAGES = Package: Lmod-8.5.21-1.fc36 Old package: Lmod-8.5.19-1.fc36 Summary: Environmental Modules System in Lua RPMs: Lmod Size: 1.10 MiB Size change: 1.19 KiB Changelog: * Thu Oct 28 2021 Orion Poplawski - 8.5.21-1 - Update to 8.5.21 Package: PackageKit-1.2.4-3.fc36 Old package: PackageKit-1.2.4-2.fc36 Summary: Package management service RPMs: PackageKit PackageKit-command-not-found PackageKit-cron PackageKit-glib PackageKit-glib-devel PackageKit-gstreamer-plugin PackageKit-gtk3-module Size: 6.76 MiB Size change: 5.67 KiB Changelog: * Wed Oct 27 2021 Rex Dieter - 1.2.4-3 - own /var/cache/PackageKit (#2016636) Package: arm-none-eabi-gcc-cs-1:11.1.0-2.fc36 Old package: arm-none-eabi-gcc-cs-1:11.1.0-0.fc35 Summary: GNU GCC for cross-compilation for arm-none-eabi target RPMs: arm-none-eabi-gcc-cs arm-none-eabi-gcc-cs-c++ Size: 938.87 MiB Size change: 813.01 MiB Changelog: * Tue May 04 2021 Michal Hlavinka - 1:11.1.0-1 - regular build for 11.1.0 * Wed Jul 21 2021 Fedora Release Engineering - 1:11.1.0-2 - Rebuilt for https://fedoraproject.org/wiki/Fedora_35_Mass_Rebuild Package: avr-gcc-1:11.1.0-2.fc36 Old package: avr-gcc-1:11.1.0-2.fc35 Summary: Cross Compiling GNU GCC targeted at avr RPMs: avr-gcc avr-gcc-c++ Size: 155.72 MiB Size change: 188.78 KiB Package: awscli-1.21.5-1.fc36 Old package: awscli-1.21.3-1.fc36 Summary: Universal Command Line Environment for AWS RPMs: awscli Size: 2.11 MiB Size change: 226 B Changelog: * Wed Oct 27 2021 Gwyn Ciesla - 1.21.4-1 - 1.21.4 * Wed Oct 27 2021 Gwyn Ciesla - 1.21.5-1 - 1.21.5 Package: bear-3.0.15-4.fc36 Old package: bear-3.0.15-3.fc36 Summary: Tool that generates a compilation database for clang tooling RPMs: bear Size: 2.81 MiB Size change: -10.85 KiB Changelog: * Sun Oct 24 2021 Adrian Reber 3.0.15-4 - Rebuilt for protobuf 3.18.1 Package: bind-32:9.16.22-1.fc36 Old package: bind-32:9.16.21-3.fc36 Summary: The Berkeley Internet Name Domain (BIND) DNS (Domain Name System) server RPMs: bind bind-chroot bind-devel bind-dlz-filesystem bind-dlz-ldap bind-dlz-mysql bind-dlz-sqlite3 bind-dnssec-doc bind-dnssec-utils bind-doc bind-libs bind-license bind-pkcs11 bind-pkcs11-devel bind-pkcs11-libs bind-pkcs11-utils bind-utils python3-bind Size: 26.27 MiB Size change: 11.13 KiB Changelog: * Wed Oct 27 2021 Petr Menk - 32:9.16.22-1 - Update to 9.16.22 Package: bind-dyndb-ldap-11.9-8.fc36 Old package: bind-dyndb-ldap-11.9-7.fc36 Summary: LDAP back-end plug-in for BIND RPMs: bind-dyndb-ldap Size: 530.44 KiB Size change: 1.85 KiB Changelog: * Thu Oct 28 2021 Petr Menk - 11.9-8 - Rebuilt for BIND 9.16.22 (#2017912) Package: blueman-1:2.2.3-1.fc36 Old package: blueman-1:2.2.2-1.fc35 Summary: GTK+ Bluetooth Manager RPMs: blueman Size: 6.78 MiB Size change: 31.97 KiB Changelog: * Thu Oct 28 2021 Artur Frenszek-Iwicki - 1:2.2.3-1 - Update to v2.2.3 Package: bottles-2021.10.28-1.fc36 Old package: bottles-2021.10.14-1.fc36 Summary: Easily manage Wine
Future of Fedora Cloud as an Edition?
Today I learned that some people are quite surprised (and not in a happy way) that Fedora Cloud base is no longer considered an Edition. Please see discussion here, both on the history and the potential futures: https://discussion.fedoraproject.org/t/fedora-cloud-edition-not-an-edition-and-the-future/34064 -- Matthew Miller Fedora Project Leader ___ 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
[EPEL-devel] Re: Planning to add a "distribution" component to EPEL product in BZ
On Thu, Oct 28, 2021 at 1:29 PM Ben Cotton wrote: > On Thu, Oct 28, 2021 at 4:18 PM Troy Dawson wrote: > > > > Will we be able to add additional people, like a normal package, so that > we all get the emails? > > If we can, then I don't mind being the initial person to add. > > If we can not, then I think it would be good to create an epel-sig bz > account. > > > I can add people to the default CC list. But there will be a single > *assignee*. > Let's put me on for the assignee. And that can be something that gets passed to the next chair. It sounds like we want at least Kevin and Carl on the cc list. Beyond that, I don't want to volunteer others without their consent. So, if other people want to be on the CC list, I guess now is the best time to speak up, although I'm sure we can add more later. Troy ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[Bug 1961865] perl-Net-CIDR-Lite: Incorrect handling of IP address with leading zeros in IP octets
https://bugzilla.redhat.com/show_bug.cgi?id=1961865 Tomas Hoger changed: What|Removed |Added Resolution|--- |NOTABUG Status|NEW |CLOSED Last Closed||2021-10-28 20:49:27 -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=1961865 ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-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/perl-devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[EPEL-devel] Re: Planning to add a "distribution" component to EPEL product in BZ
On Thu, Oct 28, 2021 at 4:18 PM Troy Dawson wrote: > > Will we be able to add additional people, like a normal package, so that we > all get the emails? > If we can, then I don't mind being the initial person to add. > If we can not, then I think it would be good to create an epel-sig bz account. > I can add people to the default CC list. But there will be a single *assignee*. -- Ben Cotton He / Him / His Fedora Program Manager Red Hat TZ=America/Indiana/Indianapolis ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[Bug 2018102] stompclt-1.7 is available
https://bugzilla.redhat.com/show_bug.cgi?id=2018102 --- Comment #9 from Fedora Update System --- FEDORA-EPEL-2021-903b0ef95e has been pushed to the Fedora EPEL 7 testing repository. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2021-903b0ef95e See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates. -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2018102 ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-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/perl-devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[EPEL-devel] Re: Planning to add a "distribution" component to EPEL product in BZ
On Thu, Oct 28, 2021 at 1:02 PM Kevin Fenzi wrote: > On Thu, Oct 28, 2021 at 03:10:38PM -0400, Ben Cotton wrote: > > Hi folks, > > > > In a conversation with Carl George and Troy Dawson earlier this week, > > we discussed the possibility of creating a "distribution" component in > > the EPEL product in Bugzilla. The idea would be that they could use it > > as a place for tracking bugs and other not-tied-to-a-specific > > component bugs. > > > > I wanted to share this more broadly for feedback and to get > > suggestions on who should be the default contact. Is there a BZ > > account for the EPEL SIG or should I have Carl and Troy arm wrestle > > for it? :-) > > There's no epel bz account I am aware of, but of course we could make > one. Or not. It doesn't seem worth it to me, I'd just say whoever wants > to be point of contact can be. I'll probibly add myself to CC since I > enjoy redirecting the misfiled bugs that will definitely appear (I do > that for fedora/distribution a lot). > > kevin > We have the epel-packagers-sig, but I don't think that is correct. Will we be able to add additional people, like a normal package, so that we all get the emails? If we can, then I don't mind being the initial person to add. If we can not, then I think it would be good to create an epel-sig bz account. Troy ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[Bug 2018102] stompclt-1.7 is available
https://bugzilla.redhat.com/show_bug.cgi?id=2018102 --- Comment #8 from Fedora Update System --- FEDORA-2021-05fb85d77c has been pushed to the Fedora 34 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2021-05fb85d77c` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2021-05fb85d77c See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates. -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2018102 ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-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/perl-devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[Bug 2018102] stompclt-1.7 is available
https://bugzilla.redhat.com/show_bug.cgi?id=2018102 --- Comment #7 from Fedora Update System --- FEDORA-EPEL-2021-30b2469a06 has been pushed to the Fedora EPEL 8 testing repository. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2021-30b2469a06 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates. -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2018102 ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-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/perl-devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[EPEL-devel] Re: Planning to add a "distribution" component to EPEL product in BZ
On Thu, Oct 28, 2021 at 03:10:38PM -0400, Ben Cotton wrote: > Hi folks, > > In a conversation with Carl George and Troy Dawson earlier this week, > we discussed the possibility of creating a "distribution" component in > the EPEL product in Bugzilla. The idea would be that they could use it > as a place for tracking bugs and other not-tied-to-a-specific > component bugs. > > I wanted to share this more broadly for feedback and to get > suggestions on who should be the default contact. Is there a BZ > account for the EPEL SIG or should I have Carl and Troy arm wrestle > for it? :-) There's no epel bz account I am aware of, but of course we could make one. Or not. It doesn't seem worth it to me, I'd just say whoever wants to be point of contact can be. I'll probibly add myself to CC since I enjoy redirecting the misfiled bugs that will definitely appear (I do that for fedora/distribution a lot). kevin signature.asc Description: PGP signature ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F36 Change: Package information on ELF objects (System-Wide Change proposal)
> On Thu, Oct 28, 2021 at 2:40 PM Luca Boccassi > It is not enough. It's not enough in *any* distribution, because > people can (re)build and deploy the same NEVRA. You *need* a build-id > to guarantee uniqueness of the binary. If the NVR is the same but the > build has been modified, the build-id changes. > > Debian has the same problem, especially when someone uses an Ubuntu > package on Debian or vice-versa. NEVRAs are *not* globally unique. Maybe I'm misunderstanding the use case, but in Debian when a build of the same source is done again (eg: library ABI transition), the revision gets +bX appended, so the metadata changes. I know Suse does the same on OBS, there's both a build counter and a source checkout counter (ie, download the same source twice and it gets an incremental revision). But anyway, the build-id doesn't go anywhere anyway? It's there and collected too by systemd-coredump/coredumpctl. > I think you've already failed at that. This would not help solve that > problem, only guarantee that you need to. Well we use this system internally at $work already, so I know for a fact that it does help. In some cases one has the luxury of being able to ignore bug reports, in others, not so much. > Even if we did this, it will be a long, long, long time before there > will be interop between Fedora and Debian. Of course, that's understood. It's going to be a long and difficult road. ___ 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: F36 Change: Package information on ELF objects (System-Wide Change proposal)
On Do, 28.10.21 15:10, Neal Gompa (ngomp...@gmail.com) wrote: > It is not enough. It's not enough in *any* distribution, because > people can (re)build and deploy the same NEVRA. You *need* a > build-id to guarantee uniqueness of the binary. If the NVR is the > same but the build has been modified, the build-id changes. Yes, some hackers rebuild stuff locally, I think it's not something to be concerned about too much though. It's not the common case, and the people doing that are probably technically proficient enough to not report bugs for crashes they collect that way or at least will quickly recognize if things go wrong that tway. Build-Ids are not going to go away. You can use them in combination if you like. For automated bug reporting/server side processing it's probably a good idea to automatically verify build ids too and then filter out stuff where nevra and build ids don't match up. > > Finally, as Mark said, with this scheme you can actually enable what you > > propose for the cases where it's possible, because as part of the metadata > > file you can include the debuginfod URL. Please think bigger picture than > > single distro: maybe the entity that created the binary uses the federated > > service so the build-id is enough, but maybe it does not. > > > > Fedora can be a trailblazer as always and be one of the first adopters > > (although CBL-Mariner beat you folks for first place :-) ) but our desired > > goal is very much to have this enabled cross-distro, so that a Fedora > > container on a Debian host or whatnot still works out of the box. > > Even if we did this, it will be a long, long, long time before there > will be interop between Fedora and Debian. Yes, Debian is slow with things, but that's certainly not a reason to give up already before starting the process. Note that the spec is useful also if Debian doesn't ever come around to adopt the spec — even when we get coredump reports from debian compiled binaries! How so? simply because soon enough the absence of the annotation already tells us something too: that the crashing binary is certainly not from a recent fedora version, even if we can't determine where it actually *is* from. But that is already enough to quickly respond to the crash report and let the report know that this is almost certainly not a Fedora issue. Lennart -- Lennart Poettering, Berlin ___ 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: F36 Change: Package information on ELF objects (System-Wide Change proposal)
On Thu, Oct 28, 2021 at 12:10:15PM -0400, David Cantrell wrote: > On Mon, Oct 25, 2021 at 07:26:47PM +, Zbigniew Jędrzejewski-Szmek wrote: > >On Mon, Oct 25, 2021 at 03:09:00PM -0400, Ben Cotton wrote: > >>https://fedoraproject.org/wiki/Changes/Package_information_on_ELF_objects > >> > >>== Summary == > >>All binaries (executables and shared libraries) are annotated with an > >>ELF note that identifies the rpm for which this file was built. This > >>allows binaries to be identified when they are distributed without any > >>of the rpm metadata. `systemd-coredump` uses this to log package > >>versions when reporting crashes. > > > >This is a resubmission of the proposal for F35 which was (narrowly) > >rejected at the time. We added copious descriptions of motivations > >for the change, and analysis of impact on upgrades, and more links > >to documentation. > > > >Zbyszek > > > >>== Owner == > >>* Name: [[User:Zbyszek|Zbigniew Jędrzejewski-Szmek]] > >>* Email: zbys...@in.waw.pl > >>* Name: Lennart Poettering > >>* Email: mzsrq...@0pointer.net > >> > >> > >>== Detailed Description == > >>People mix binaries (programs and libraries) from different > >>distributions (for example using Fedora containers on Debian or vice > >>versa), and distribute binaries without packaging metadata (for > >>example by stripping everything except the binary from a container > >>image, also removing `/usr/lib/.build-id/*`), compile their own rpm > >>packages (for internal distribution and installation), and compile and > >>distribute their own binaries. Sometimes we need to introspect a > >>binary and figure out its provenance, for example when a program > >>crashes and we are looking at a core dump, but also when we have a > >>binary without the packaging metadata. When the need to introspect a > >>binary arises, we have some very good mechanisms to show the > >>provenance: when a file is installed through the package manager we > >>can directly list the providing package, but even without this we can > >>use build-ids embedded in the binary to uniquely identify the > >>originating build. But those mechanisms work best when we're in the > >>realm of a single distribution. In particular, build-ids can be easily > >>tied to a source rpm, but only when we have the source rpm is part of > >>the distribution and the build-id was registered in the appropriate > >>database which maps build-ids to real package names. When we move > >>outside of the realm of a single distribution, it can be hard to > >>figure out where a given binary originates from. If we know that a > >>binary is from a given distribution, we may be able to use some > >>distro-specific mechanism to figure out this information. But those > >>mechanisms will be different for different distributions and will > >>often require network access. With this change we aim to provide a > >>mechanism that is is very simple, provides a "human-readable" origin > >>information without further processing, is portable across distros, > >>and works without network access. > >> > >>The directly motivating use case is display of core dumps. Right now > >>we have build-ids, but those are just opaque hexadecimal numbers that > >>are not meaningful to users. We would like to immediately list > >>versions of packages involved in the crash (including both the program > >>and any libraries it links to). It is not enough to query the rpm > >>database to do the equivalent of `rpm -qf …`: very often programs > >>crash after some packages have been upgraded and the binaries loaded > >>into memory are not the binaries that are currently present on disk, > >>or when through some mishap, the binaries on disk do not match the > >>installed rpms. A mechanism that works without rpm database lookup or > >>network access allows this information to be showed immediately in > >>`coredumpctl` listings and journal entries about the crash. This > >>includes crashes that happen in the initrd and sandboxed containers. > >> > >>A second motivating use case is when users distribute their own > >>binaries and would like to collect crash information. Build-ids are a > >>solution that is technically possible, but easy to get wrong in > >>practice: users would need to immediately record the build-id after > >>the build and store the mapping to program names, versions, and build > >>number in some database. It's much easier to be able to record > >>something during the build in the build product itself. > >> > >>A third motivating use case is the general mixing of Fedora binaries > >>with programs and libraries from different distributions, both with > >>our binaries being used as the base for foreign binaries, and the > >>other way around. Whilst most distributions provide some mechanism to > >>figure out the source build information, those mechanisms vary by > >>distribution and may not be easy to access from a "foreign" system. > >>Such mixing is expected with containers, flatpaks, snaps, Python > >>binary
[Bug 2018102] stompclt-1.7 is available
https://bugzilla.redhat.com/show_bug.cgi?id=2018102 --- Comment #6 from Fedora Update System --- FEDORA-2021-01fdca has been pushed to the Fedora 33 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2021-01fdca` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2021-01fdca See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates. -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2018102 ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-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/perl-devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F36 Change: Package information on ELF objects (System-Wide Change proposal)
On Do, 28.10.21 12:10, David Cantrell (dcantr...@redhat.com) wrote: > Thanks for revising the change proposal and filling in more details. > After reading through it, I have some questions: > > 1) The proposal notes that users tend to combine built packages from > different distributions. Even in the current environment, do we care > about those use cases without also getting a reproducer for Fedora? I'd see it this way: ultimately, if this gets adopted by multiple distros this annotation will helps us separating out the reports by distro, and then ignore everything but fedora. i.e. if someone deploys a debian or ubuntu container on a fedora host this should be something we shouldn't be bothered with supporting. But right now a coredump generated that way won't tell us much about the situation. But once this spec is adopted this becomes easy: if we get a report we'll immediately see that the code that aborted was actually from a different distro, and we can point the reporter to that and tell them politely to ask the other distro for help, or alternatively invest the time and reproduce the issue with the binary provided by fedora instead. So, having this info around us allows us to be more efficient with "not caring" for non-fedora issues. > For me, I feel that in a situation like that where a user has > submitted a bug report that implies using a binary from some other > distribution will lead me to ask "ok, but does this happen with the > packages provided in Fedora? If so, how can I reproduce the problem > locally?" So while these scenarios are described in the proposal, are > they something that Fedora is trying to support? Well, I don't think Fedora has to care about crashes in other distro's binaries. we have more than enough to look after anyway. But I do think we should make it easier to detect this situation and more easily provide helpful pointers how to find someone else who might be interested or what to do to make fedora interested. > 3) The proposal notes making crash reporting more user-readable. NVRs > instead of Build-IDs, for instance. Why can't systemd ask debuginfod > for that information for reporting? Why does this need to be embedded > in the ELF objects? If it's a value-add, then it could happen if > debuginfod is set up and just have it fall back on the current > reporting mechanism. We want to be able to do things generically in an offline fashion in systemd-coredump. I.e. we run the coredump analyzer in a tight sandbox, and we want quick answers without relying on the network. The goal of systemd-coredump is to make a coredump something that is primarily a relatively cheapish log event, and were we do analysis as much as possible locally, automatically, securely, in privacy and quickly. If we'd always talk to the network we'd have to open our sandbox quite a bit, we'd be dependent on external services, we'd leak some data to the outside, we'd be unreliable and slower — and all that even though we are interested in only a single string of data ultimately. (I think debuginfod is excellent, but I think it would probably be a consumer of this spec, not a replacement. for example, consider that the spec has a suggested field 'debugInfoUrl' already, which would inform debugging tools about the debuginfod servers to talk to to acquire extended debug info data) Lennart -- Lennart Poettering, Berlin ___ 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: F36 Change: Package information on ELF objects (System-Wide Change proposal)
On Thu, Oct 28, 2021 at 2:40 PM Luca Boccassi wrote: > > > On Mon, Oct 25, 2021 at 07:26:47PM +, Zbigniew Jędrzejewski-Szmek wrote: > > > > Thanks for revising the change proposal and filling in more details. > > After reading through it, I have some questions: > > > > 1) The proposal notes that users tend to combine built packages from > > different distributions. Even in the current environment, do we care > > about those use cases without also getting a reproducer for Fedora? > > For me, I feel that in a situation like that where a user has > > submitted a bug report that implies using a binary from some other > > distribution will lead me to ask "ok, but does this happen with the > > packages provided in Fedora? If so, how can I reproduce the problem > > locally?" So while these scenarios are described in the proposal, are > > they something that Fedora is trying to support? > > There are and there will be some who do care, and whose life will be made oh > so much easier. Maybe they will be Fedora developers, or maybe they will be > just Fedora users. Maybe it's someone managing a bunch of containers, and one > of them happens to be Fedora, so it won't be you receiving the bug report, > but someone else. We are trying to enable a cross distro specification, and > this is part of building a solid base upon which others can build on. That > should be enough already, no? > > > 2) The proposal is built around using the package NVR to indicate > > where it came from. But those names aren't unique. In some cases > > it'll work, but in cases where the noted package cannot be found or > > has been reaped or is just otherwise unavailable, you're back to > > asking for a reproducer on a Fedora release, right? Does the NVR data > > save much work over having build-ID plus debuginfod? That's not > > rhetorical? I don't have many bug reports that are not resolvable by > > just talking through a reproducer and seeing it happen locally, but I > > know I'm not a control case. > > Isn't the combination of distro name + distro version + package name + > package version + package arch enough to uniquely identify? Are there cases > where there can be duplicates in Fedora? Speaking of the Debian case, the > distro version isn't even needed, you won't have duplicates even across > multiple releases. > It is not enough. It's not enough in *any* distribution, because people can (re)build and deploy the same NEVRA. You *need* a build-id to guarantee uniqueness of the binary. If the NVR is the same but the build has been modified, the build-id changes. Debian has the same problem, especially when someone uses an Ubuntu package on Debian or vice-versa. NEVRAs are *not* globally unique. > > 3) The proposal notes making crash reporting more user-readable. NVRs > > instead of Build-IDs, for instance. Why can't systemd ask debuginfod > > for that information for reporting? Why does this need to be embedded > > in the ELF objects? If it's a value-add, then it could happen if > > debuginfod is set up and just have it fall back on the current > > reporting mechanism. > > First of all, we do not want to do network accesses from systemd-coredump, > and keep any other system accesses to the bare minimum possible. It runs > sandboxed, because core files are fundamentally unknown untrusted data, so > the process doing that is restricted as much as possible. > > Secondly, internet access might be forbidden in the setup where a problem is > happening. > > Thirdly, maybe it's the components that allow you to do network access in the > first place that are crashing, and all you have is a serial console and > desperation. > I think you've already failed at that. This would not help solve that problem, only guarantee that you need to. > Finally, as Mark said, with this scheme you can actually enable what you > propose for the cases where it's possible, because as part of the metadata > file you can include the debuginfod URL. Please think bigger picture than > single distro: maybe the entity that created the binary uses the federated > service so the build-id is enough, but maybe it does not. > > Fedora can be a trailblazer as always and be one of the first adopters > (although CBL-Mariner beat you folks for first place :-) ) but our desired > goal is very much to have this enabled cross-distro, so that a Fedora > container on a Debian host or whatnot still works out of the box. Even if we did this, it will be a long, long, long time before there will be interop between Fedora and Debian. -- 真実はいつも一つ！/ 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:
[EPEL-devel] Planning to add a "distribution" component to EPEL product in BZ
Hi folks, In a conversation with Carl George and Troy Dawson earlier this week, we discussed the possibility of creating a "distribution" component in the EPEL product in Bugzilla. The idea would be that they could use it as a place for tracking bugs and other not-tied-to-a-specific component bugs. I wanted to share this more broadly for feedback and to get suggestions on who should be the default contact. Is there a BZ account for the EPEL SIG or should I have Carl and Troy arm wrestle for it? :-) Thanks, BC -- Ben Cotton He / Him / His Fedora Program Manager Red Hat TZ=America/Indiana/Indianapolis ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F36 Change: Package information on ELF objects (System-Wide Change proposal)
On Thu, Oct 28, 2021 at 05:44:44PM +0200, Vitaly Zaitsev via devel wrote: > On 28/10/2021 15:53, Chris Adams wrote: > > New 500G SSDs are available under $50, and 1TB under $90. > > QLC is not an option. Too slow outside of the SLC cache. Stop moving the goalposts, okay? -- Tomasz TorczOnly gods can safely risk perfection, to...@pipebreaker.pl it's a dangerous thing for a man. — Alia ___ 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: F36 Change: Package information on ELF objects (System-Wide Change proposal)
> On Mon, Oct 25, 2021 at 07:26:47PM +, Zbigniew Jędrzejewski-Szmek wrote: > > Thanks for revising the change proposal and filling in more details. > After reading through it, I have some questions: > > 1) The proposal notes that users tend to combine built packages from > different distributions. Even in the current environment, do we care > about those use cases without also getting a reproducer for Fedora? > For me, I feel that in a situation like that where a user has > submitted a bug report that implies using a binary from some other > distribution will lead me to ask "ok, but does this happen with the > packages provided in Fedora? If so, how can I reproduce the problem > locally?" So while these scenarios are described in the proposal, are > they something that Fedora is trying to support? There are and there will be some who do care, and whose life will be made oh so much easier. Maybe they will be Fedora developers, or maybe they will be just Fedora users. Maybe it's someone managing a bunch of containers, and one of them happens to be Fedora, so it won't be you receiving the bug report, but someone else. We are trying to enable a cross distro specification, and this is part of building a solid base upon which others can build on. That should be enough already, no? > 2) The proposal is built around using the package NVR to indicate > where it came from. But those names aren't unique. In some cases > it'll work, but in cases where the noted package cannot be found or > has been reaped or is just otherwise unavailable, you're back to > asking for a reproducer on a Fedora release, right? Does the NVR data > save much work over having build-ID plus debuginfod? That's not > rhetorical? I don't have many bug reports that are not resolvable by > just talking through a reproducer and seeing it happen locally, but I > know I'm not a control case. Isn't the combination of distro name + distro version + package name + package version + package arch enough to uniquely identify? Are there cases where there can be duplicates in Fedora? Speaking of the Debian case, the distro version isn't even needed, you won't have duplicates even across multiple releases. > 3) The proposal notes making crash reporting more user-readable. NVRs > instead of Build-IDs, for instance. Why can't systemd ask debuginfod > for that information for reporting? Why does this need to be embedded > in the ELF objects? If it's a value-add, then it could happen if > debuginfod is set up and just have it fall back on the current > reporting mechanism. First of all, we do not want to do network accesses from systemd-coredump, and keep any other system accesses to the bare minimum possible. It runs sandboxed, because core files are fundamentally unknown untrusted data, so the process doing that is restricted as much as possible. Secondly, internet access might be forbidden in the setup where a problem is happening. Thirdly, maybe it's the components that allow you to do network access in the first place that are crashing, and all you have is a serial console and desperation. Finally, as Mark said, with this scheme you can actually enable what you propose for the cases where it's possible, because as part of the metadata file you can include the debuginfod URL. Please think bigger picture than single distro: maybe the entity that created the binary uses the federated service so the build-id is enough, but maybe it does not. Fedora can be a trailblazer as always and be one of the first adopters (although CBL-Mariner beat you folks for first place :-) ) but our desired goal is very much to have this enabled cross-distro, so that a Fedora container on a Debian host or whatnot still works out of the box. ___ 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 Linux 35 Final is GO
The Fedora 35 Final RC1.2 compose [1] is GO and will be shipped live on Tuesday, 2 November 2021. For more information please check the Go/No-Go meeting minutes [2] or logs [3]. Thank you to everyone who has worked on this release. Be sure to join us November 12–13 for the F35 Release Party[4] [1] https://dl.fedoraproject.org/pub/alt/stage/35_RC-1.2/ [2] https://meetbot.fedoraproject.org/fedora-meeting/2021-10-28/f35-final-go_no_go-meeting.2021-10-28-17.01.html [3] https://meetbot.fedoraproject.org/fedora-meeting/2021-10-28/f35-final-go_no_go-meeting.2021-10-28-17.01.log.html [4] https://hopin.com/events/fedora-linux-35-release-party/ -- Ben Cotton He / Him / His Fedora Program Manager Red Hat TZ=America/Indiana/Indianapolis ___ devel-announce mailing list -- devel-announce@lists.fedoraproject.org To unsubscribe send an email to devel-announce-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-announce@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[Test-Announce] Fedora Linux 35 Final is GO
The Fedora 35 Final RC1.2 compose [1] is GO and will be shipped live on Tuesday, 2 November 2021. For more information please check the Go/No-Go meeting minutes [2] or logs [3]. Thank you to everyone who has worked on this release. Be sure to join us November 12–13 for the F35 Release Party[4] [1] https://dl.fedoraproject.org/pub/alt/stage/35_RC-1.2/ [2] https://meetbot.fedoraproject.org/fedora-meeting/2021-10-28/f35-final-go_no_go-meeting.2021-10-28-17.01.html [3] https://meetbot.fedoraproject.org/fedora-meeting/2021-10-28/f35-final-go_no_go-meeting.2021-10-28-17.01.log.html [4] https://hopin.com/events/fedora-linux-35-release-party/ -- Ben Cotton He / Him / His Fedora Program Manager Red Hat TZ=America/Indiana/Indianapolis ___ test-announce mailing list -- test-annou...@lists.fedoraproject.org To unsubscribe send an email to test-announce-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/test-annou...@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure ___ 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: F36 Change: Package information on ELF objects (System-Wide Change proposal)
On Mon, Oct 25, 2021 at 07:26:47PM +, Zbigniew Jędrzejewski-Szmek wrote: On Mon, Oct 25, 2021 at 03:09:00PM -0400, Ben Cotton wrote: https://fedoraproject.org/wiki/Changes/Package_information_on_ELF_objects == Summary == All binaries (executables and shared libraries) are annotated with an ELF note that identifies the rpm for which this file was built. This allows binaries to be identified when they are distributed without any of the rpm metadata. `systemd-coredump` uses this to log package versions when reporting crashes. This is a resubmission of the proposal for F35 which was (narrowly) rejected at the time. We added copious descriptions of motivations for the change, and analysis of impact on upgrades, and more links to documentation. Zbyszek == Owner == * Name: [[User:Zbyszek|Zbigniew Jędrzejewski-Szmek]] * Email: zbys...@in.waw.pl * Name: Lennart Poettering * Email: mzsrq...@0pointer.net == Detailed Description == People mix binaries (programs and libraries) from different distributions (for example using Fedora containers on Debian or vice versa), and distribute binaries without packaging metadata (for example by stripping everything except the binary from a container image, also removing `/usr/lib/.build-id/*`), compile their own rpm packages (for internal distribution and installation), and compile and distribute their own binaries. Sometimes we need to introspect a binary and figure out its provenance, for example when a program crashes and we are looking at a core dump, but also when we have a binary without the packaging metadata. When the need to introspect a binary arises, we have some very good mechanisms to show the provenance: when a file is installed through the package manager we can directly list the providing package, but even without this we can use build-ids embedded in the binary to uniquely identify the originating build. But those mechanisms work best when we're in the realm of a single distribution. In particular, build-ids can be easily tied to a source rpm, but only when we have the source rpm is part of the distribution and the build-id was registered in the appropriate database which maps build-ids to real package names. When we move outside of the realm of a single distribution, it can be hard to figure out where a given binary originates from. If we know that a binary is from a given distribution, we may be able to use some distro-specific mechanism to figure out this information. But those mechanisms will be different for different distributions and will often require network access. With this change we aim to provide a mechanism that is is very simple, provides a "human-readable" origin information without further processing, is portable across distros, and works without network access. The directly motivating use case is display of core dumps. Right now we have build-ids, but those are just opaque hexadecimal numbers that are not meaningful to users. We would like to immediately list versions of packages involved in the crash (including both the program and any libraries it links to). It is not enough to query the rpm database to do the equivalent of `rpm -qf …`: very often programs crash after some packages have been upgraded and the binaries loaded into memory are not the binaries that are currently present on disk, or when through some mishap, the binaries on disk do not match the installed rpms. A mechanism that works without rpm database lookup or network access allows this information to be showed immediately in `coredumpctl` listings and journal entries about the crash. This includes crashes that happen in the initrd and sandboxed containers. A second motivating use case is when users distribute their own binaries and would like to collect crash information. Build-ids are a solution that is technically possible, but easy to get wrong in practice: users would need to immediately record the build-id after the build and store the mapping to program names, versions, and build number in some database. It's much easier to be able to record something during the build in the build product itself. A third motivating use case is the general mixing of Fedora binaries with programs and libraries from different distributions, both with our binaries being used as the base for foreign binaries, and the other way around. Whilst most distributions provide some mechanism to figure out the source build information, those mechanisms vary by distribution and may not be easy to access from a "foreign" system. Such mixing is expected with containers, flatpaks, snaps, Python binary wheels, anaconda packages, and quite often when somebody compiles a binary and puts it up on the web for other people to download. We propose a new mechanism which is designed to be very simple but extensible: a small JSON document is embedded in an section in the ELF binary. This document can be easily read by a human if necessary, but it is also well-defined and can be processed
Fedora-35-20211028.n.0 compose check report
No missing expected images. Failed openQA tests: 7/141 (aarch64), 1/204 (x86_64) New failures (same test not failed in Fedora-35-20211027.n.0): ID: 1043715 Test: aarch64 Server-dvd-iso anaconda_help@uefi URL: https://openqa.fedoraproject.org/tests/1043715 ID: 1043716 Test: aarch64 Server-dvd-iso install_default_upload@uefi URL: https://openqa.fedoraproject.org/tests/1043716 ID: 1043723 Test: aarch64 Server-dvd-iso install_blivet_standard_partition_ext4@uefi URL: https://openqa.fedoraproject.org/tests/1043723 ID: 1043913 Test: aarch64 universal install_lvmthin@uefi URL: https://openqa.fedoraproject.org/tests/1043913 ID: 1043928 Test: aarch64 Workstation-raw_xz-raw.xz evince@uefi URL: https://openqa.fedoraproject.org/tests/1043928 Old failures (same test failed in Fedora-35-20211027.n.0): ID: 1043669 Test: x86_64 KDE-live-iso apps_startstop URL: https://openqa.fedoraproject.org/tests/1043669 ID: 1043901 Test: aarch64 universal install_btrfs@uefi URL: https://openqa.fedoraproject.org/tests/1043901 ID: 1043922 Test: aarch64 Workstation-raw_xz-raw.xz gedit@uefi URL: https://openqa.fedoraproject.org/tests/1043922 Soft failed openQA tests: 4/204 (x86_64), 2/141 (aarch64) (Tests completed, but using a workaround for a known bug) Old soft failures (same test soft failed in Fedora-35-20211027.n.0): ID: 1043650 Test: x86_64 Workstation-live-iso gedit URL: https://openqa.fedoraproject.org/tests/1043650 ID: 1043689 Test: x86_64 Silverblue-dvd_ostree-iso evince URL: https://openqa.fedoraproject.org/tests/1043689 ID: 1043690 Test: x86_64 Silverblue-dvd_ostree-iso gedit URL: https://openqa.fedoraproject.org/tests/1043690 ID: 1043699 Test: x86_64 Cloud_Base-qcow2-qcow2 cloud_autocloud URL: https://openqa.fedoraproject.org/tests/1043699 ID: 1043783 Test: aarch64 Cloud_Base-qcow2-qcow2 cloud_autocloud@uefi URL: https://openqa.fedoraproject.org/tests/1043783 ID: 1043918 Test: aarch64 Workstation-raw_xz-raw.xz install_arm_image_deployment_upload@uefi URL: https://openqa.fedoraproject.org/tests/1043918 Passed openQA tests: 108/141 (aarch64), 198/204 (x86_64) New passes (same test not passed in Fedora-35-20211027.n.0): ID: 1043739 Test: aarch64 Server-dvd-iso support_server@uefi URL: https://openqa.fedoraproject.org/tests/1043739 ID: 1043749 Test: aarch64 Server-dvd-iso install_resize_lvm@uefi URL: https://openqa.fedoraproject.org/tests/1043749 ID: 1043750 Test: aarch64 Server-dvd-iso install_updates_nfs@uefi URL: https://openqa.fedoraproject.org/tests/1043750 ID: 1043924 Test: aarch64 Workstation-raw_xz-raw.xz desktop_update_graphical@uefi URL: https://openqa.fedoraproject.org/tests/1043924 ID: 1043926 Test: aarch64 Workstation-raw_xz-raw.xz desktop_browser@uefi URL: https://openqa.fedoraproject.org/tests/1043926 Skipped non-gating openQA tests: 24 of 345 Installed system changes in test x86_64 Server-dvd-iso install_default_upload: System load changed from 0.13 to 0.33 Previous test data: https://openqa.fedoraproject.org/tests/1043015#downloads Current test data: https://openqa.fedoraproject.org/tests/1043595#downloads Installed system changes in test x86_64 Workstation-live-iso install_default_upload: 1 packages(s) removed since previous compose: biosdevname System load changed from 0.56 to 0.68 Previous test data: https://openqa.fedoraproject.org/tests/1042302#downloads Current test data: https://openqa.fedoraproject.org/tests/1043634#downloads Installed system changes in test x86_64 Workstation-live-iso install_default@uefi: 1 packages(s) removed since previous compose: biosdevname 2 services(s) removed since previous compose: fwupd.service, geoclue.service System load changed from 0.72 to 0.49 Previous test data: https://openqa.fedoraproject.org/tests/1042315#downloads Current test data: https://openqa.fedoraproject.org/tests/1043647#downloads Installed system changes in test x86_64 KDE-live-iso install_default_upload: System load changed from 0.71 to 0.87 Previous test data: https://openqa.fedoraproject.org/tests/1042328#downloads Current test data: https://openqa.fedoraproject.org/tests/1043660#downloads Installed system changes in test x86_64 KDE-live-iso install_default@uefi: System load changed from 0.67 to 0.51 Previous test data: https://openqa.fedoraproject.org/tests/1042333#downloads Current test data: https://openqa.fedoraproject.org/tests/1043665#downloads Installed system changes in test x86_64 Silverblue-dvd_ostree-iso install_default@uefi: System load changed from 1.17 to 0.55 Previous test data: https://openqa.fedoraproject.org/tests/1042346#downloads Current test data: https://openqa.fedoraproject.org/tests/1043678#downloads Installed system changes in test x86_64 universal install_package_set_kde: System load changed from 1.34 to 0.88 Previous test data: https://openqa.fedoraproject.org/tests/1042476#downloads Current test data:
Re: F36 Change: Package information on ELF objects (System-Wide Change proposal)
On 28/10/2021 15:53, Chris Adams wrote: New 500G SSDs are available under $50, and 1TB under $90. QLC is not an option. Too slow outside of the SLC cache. -- Sincerely, Vitaly Zaitsev (vit...@easycoding.org) ___ 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: F36 Change: Package information on ELF objects (System-Wide Change proposal)
On Thu, 28 Oct 2021 at 10:03, Kevin Kofler via devel wrote: > > Stephen John Smoogen wrote: > > a) Not have Lennart's name tied to a request. That just pulls in all > > kinds of over-the-top statements where people will say 99.99% of the > > people won't use it without any evidence. > > What does Lennart's name have to do with this? I would have objected the > same way to this change no matter whose name(s) are on it. (And for what it > is worth, I actually considered this to be mainly Zbyszek's change proposal. > But it does not matter anyway. I have nothing against Zbyszek and I have > seen a lot of good ideas from him. This change just happens to be a bad > idea.) > > > b) Don't mention disk space growth. You will get nothing about how you > > are bloating the operating system. ** > > Nonsense. It is blatantly obvious to me that adding annotations to > executables will bloat the operating system, even if you attempt to swipe > that issue under the carpet. Do not take me for dumb! > > > c) Don't mention anything about making debugging or security easier. > > Anyone who has a workflow will see that as a challenge to their own > > choices. > > That is also a nonsensical assertion. The issue here is that there is a > tradeoff between provable global bloat to the entire distribution and a very > questionable gain in functionality. > > > This change has all three and so is going to be yelled at over and > > over again. Instead you should make a change request which will give > > you all those but has some other item tied to it. > > So you are advocating deliberately using a dishonest and misleading > political tactic that politicians are rightfully criticized for, namely > hiding unwanted changes in a larger change proposal? > I should have dropped my sarcasm and stated the following: These threads end up with people emailing dozens or more times about the growth of kilobytes or megabytes while not giving the same amount of comment to growth 10x that much. Developers just want to get their work and changes done efficiently, and what we have taught them is that 'ask for forgiveness rather than permission' is the most efficient path. Any current or future complaints that developers are acting like politicians are moot, when we have made the best way to get a change done is to act like one. -- Stephen J Smoogen. I've seen things you people wouldn't believe. Flame wars in sci.astro.orion. I have seen SPAM filters overload because of Godwin's Law. All those moments will be lost in time... like posts on a BBS... time to shutdown -h now. ___ 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: F36 Change: Package information on ELF objects (System-Wide Change proposal)
> On Wed, Oct 27, 2021 at 02:10:37PM +0100, Daniel P. Berrangé wrote: > > It breaks libguestfs. It also breaks basic stuff like "what is > installed in this container?" "Is this file owned by RPM?" "Has > this > file been modified?" I think deleting the RPM database is broken, and > tools that do this should be corrected. > > Rich. That is not going to happen, because people doing it do not care about any of that in the slightest, and have very different needs. And that's ok, your requirements != everyone else's. And as mentioned already, dracut does exactly that for initrds in Fedora. ___ 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: glusterfs on armv7
Perfect. Thank you Mamoru-san.
armv7hl is now back in.
Regards,
On Thu, Oct 28, 2021 at 10:31 AM Mamoru TASAKA
wrote:
> Kaleb Keithley wrote on 2021/10/28 22:41:
> >
> >
> > See
> >
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/3MQ4ZRPS4MOIDG2RPAR6YX43VX2MCOLW/
> >
> > I have not had a chance to follow through yet with a self contained
> > change...
>
> Looks like the same "issue" written on
> https://www.mail-archive.com/lttng-dev@lists.lttng.org/msg12950.html
> and the same "workaround" written above works:
>
> https://koji.fedoraproject.org/koji/taskinfo?taskID=77972946
>
> What I did is:
> ```
> @@ -822,6 +822,11 @@ done
> %endif
>
> %build
> +%ifarch %arm
> +%set_build_flags
> +export CFLAGS="$(echo $CFLAGS) -DUATOMIC_NO_LINK_ERROR"
> +%endif
> +
> sed -i -e 's/--quiet//' configure.ac
> ./autogen.sh && %configure \
> %{?_with_asan} \
> ```
>
> Regards,
> Mamoru
>
> >
> >
> >
> > On Thu, Oct 28, 2021 at 9:36 AM Richard W.M. Jones
> > wrote:
> >
> >>
> >> https://bugzilla.redhat.com/show_bug.cgi?id=2018182
> >>
> >> Looks like glusterfs has been dropped on armv7. Is this a permanent
> >> state of affairs? Is there a bug about it?
> >>
> >> (I don't care either way, just want to know if we should drop the
> >> libvirt support for glusterfs on armv7 too.)
> >>
> >> Rich.
> >>
> >> --
> >> Richard Jones, Virtualization Group, Red Hat
> >> http://people.redhat.com/~rjones
> >> Read my programming and virtualization blog: http://rwmj.wordpress.com
> >> Fedora Windows cross-compiler. Compile Windows programs, test, and
> >> build Windows installers. Over 100 libraries supported.
> >> http://fedoraproject.org/wiki/MinGW
> >>
> >>
> >
> >
> > ___
> > 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
> >
> ___
> 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
>
--
Kaleb
___
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
[Bug 2018102] stompclt-1.7 is available
https://bugzilla.redhat.com/show_bug.cgi?id=2018102 Fedora Update System changed: What|Removed |Added Status|MODIFIED|ON_QA --- Comment #5 from Fedora Update System --- FEDORA-2021-a04189483a has been pushed to the Fedora 35 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2021-a04189483a` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2021-a04189483a See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates. -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2018102 ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-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/perl-devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F36 Change: Drop NIS(+) support from PAM (System-Wide Change proposal)
On Thu, 2021-10-28 at 10:28 -0400, Frank Ch. Eigler wrote: > Stephen John Smoogen writes: > > > Mainly because it is the authentication service equivalent of > > telnet**. Very simple to set up, very simple to use, and very easy to > > steal all the information about logins, users, and setups. [...] > > ... well, compared to what? LDAP commonly distributes crypttext > passwords and databases with about the same amount of discernment and > theft-enablement as ypserv. Plaintext as in telnet makes an appearance > nowhere but with yppasswd, AFAIK, which is nonessential. LDAP is normally deployed on a secure channel (TLS or GSSAPI), that the client can cryptographically check. NIS is a clear text protocol that can be trivially MitMed to provide arbitrary information to the target system. Also generally LDAP *does not* in fact distribute passwords, most systems use the LDAP Bind operation to test a password and the LDAP server does *not* provide access to password hashes. I thin k it is legitimate to question whether it is yet time to drop this obsolete protocol (NIS) on backwards compatibility grounds. But on security grounds it is indefensible, don't go there. Simo. -- Simo Sorce RHEL Crypto Team Red Hat, Inc ___ 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: glusterfs on armv7
Kaleb Keithley wrote on 2021/10/28 22:41:
See
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/3MQ4ZRPS4MOIDG2RPAR6YX43VX2MCOLW/
I have not had a chance to follow through yet with a self contained
change...
Looks like the same "issue" written on
https://www.mail-archive.com/lttng-dev@lists.lttng.org/msg12950.html
and the same "workaround" written above works:
https://koji.fedoraproject.org/koji/taskinfo?taskID=77972946
What I did is:
```
@@ -822,6 +822,11 @@ done
%endif
%build
+%ifarch %arm
+%set_build_flags
+export CFLAGS="$(echo $CFLAGS) -DUATOMIC_NO_LINK_ERROR"
+%endif
+
sed -i -e 's/--quiet//' configure.ac
./autogen.sh && %configure \
%{?_with_asan} \
```
Regards,
Mamoru
On Thu, Oct 28, 2021 at 9:36 AM Richard W.M. Jones
wrote:
https://bugzilla.redhat.com/show_bug.cgi?id=2018182
Looks like glusterfs has been dropped on armv7. Is this a permanent
state of affairs? Is there a bug about it?
(I don't care either way, just want to know if we should drop the
libvirt support for glusterfs on armv7 too.)
Rich.
--
Richard Jones, Virtualization Group, Red Hat
http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
Fedora Windows cross-compiler. Compile Windows programs, test, and
build Windows installers. Over 100 libraries supported.
http://fedoraproject.org/wiki/MinGW
___
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
___
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: F36 Change: Drop NIS(+) support from PAM (System-Wide Change proposal)
Stephen John Smoogen writes: > Mainly because it is the authentication service equivalent of > telnet**. Very simple to set up, very simple to use, and very easy to > steal all the information about logins, users, and setups. [...] ... well, compared to what? LDAP commonly distributes crypttext passwords and databases with about the same amount of discernment and theft-enablement as ypserv. Plaintext as in telnet makes an appearance nowhere but with yppasswd, AFAIK, which is nonessential. - 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: F36 Change: Package information on ELF objects (System-Wide Change proposal)
On Do, 28.10.21 14:24, Fedora Development ML (devel@lists.fedoraproject.org) wrote: > Lennart Poettering wrote: > > I understand you are not working with backtraces/coredumps every > > day. > > For core dumps, this is true. (I have found those to not be of much use, > other than getting a backtrace, but I would rather just get the backtrace > directly.) The `coredumpctl gdb` command is pure bliss btw. It allows you to asynchronously debug crashes in a very easy way. > Sorry, but I do not see those "MiniDebugInfo" and "package information" > features as helping me maintain software in any way. I think we can agree on that. Thing though is that it would help a lot of other people. And I am pretty sure that's a good reason to do this feature. Lennart -- Lennart Poettering, Berlin ___ 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: F36 Change: Package information on ELF objects (System-Wide Change proposal)
Michael Catanzaro wrote: > What I just don't understand is why so much argument over a minuscule > disk space increase. We can argue over the best way to create > backtraces. But trying to step on the toes of other people who are > working on this problem just because their work requires a tiny > annotation in each binary seems weird. Well, my point is that the bar for adding any kind of annotation to *all* ELF binaries in the distribution needs to be set much higher. We already have MiniDebugInfo, Annobin, and now this, when will this ever stop? When the executables will contain more annotations than code? tiny+tiny+tiny+… adds up quickly (and MiniDebugInfo and Annobin are not so tiny – I have complained about those back when they were introduced and still want them removed ASAP). Kevin Kofler ___ 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: F36 Change: Package information on ELF objects (System-Wide Change proposal)
On Wed, Oct 27, 2021 at 02:10:37PM +0100, Daniel P. Berrangé wrote: > On Wed, Oct 27, 2021 at 02:00:36PM +0200, Kevin Kofler via devel wrote: > > Zbigniew Jędrzejewski-Szmek wrote: > > > 5. This proposal is not about licensing, but if it is adopted, it'll only > > > make figuring out potential licensing violations easier (in some cases, > > > primarily when distributing without recompilation). > > > > True, but is that worth bloating the entire distribution for all users, > > even > > those who are not violating the licenses? > > It is beneficial even for users who are not violating the license. > > > >> And those Dockerfiles are broken, any bug reports from them (i.e., where > > >> the package information is missing in the report) should be closed as > > >> INSUFFICIENT_DATA immediately. > > > > > > The fact that you don't like what somebody else is doing doesn't make it > > > "broken" or a "blatant violation of ... license". As discussed in the > > > other part of my reply, you're just making very general far-fetched > > > statements that may be true in some cases, but are trivially shown to be > > > groundless in many other cases. > > > > Deleting the RPM database turns a working Fedora image into a corrupt one > > that can be neither updated nor queried for metadata, how can this not be > > broken? > > Container images are often not used and maintained in the same way as > a traditional OS. If people want to pull in the latest RPM updates, > they won't run 'dnf update' in the container, they'll simply build > a new container image. Being able to query/manipulate the RPM DB > inside a container just isn't a high priority requirement in general. > It does have its downsides, as it is sometimes useful to query the > RPM DB for debugging purposes, but that doesn't mean it is broken. > It is simply a different approach / attitude / tradeoff towards using > & maintaining the software stack. > > This change proposal is showing that some of the debugging needs > can be satisfied in a different way that's arguably more reliable > for both container & non-container use cases, as it is guaranteed > to reflect what is actually resident in memory. It breaks libguestfs. It also breaks basic stuff like "what is installed in this container?" "Is this file owned by RPM?" "Has this file been modified?" I think deleting the RPM database is broken, and tools that do this should be corrected. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com Fedora Windows cross-compiler. Compile Windows programs, test, and build Windows installers. Over 100 libraries supported. http://fedoraproject.org/wiki/MinGW ___ 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: F36 Change: Package information on ELF objects (System-Wide Change proposal)
Stephen John Smoogen wrote: > a) Not have Lennart's name tied to a request. That just pulls in all > kinds of over-the-top statements where people will say 99.99% of the > people won't use it without any evidence. What does Lennart's name have to do with this? I would have objected the same way to this change no matter whose name(s) are on it. (And for what it is worth, I actually considered this to be mainly Zbyszek's change proposal. But it does not matter anyway. I have nothing against Zbyszek and I have seen a lot of good ideas from him. This change just happens to be a bad idea.) > b) Don't mention disk space growth. You will get nothing about how you > are bloating the operating system. ** Nonsense. It is blatantly obvious to me that adding annotations to executables will bloat the operating system, even if you attempt to swipe that issue under the carpet. Do not take me for dumb! > c) Don't mention anything about making debugging or security easier. > Anyone who has a workflow will see that as a challenge to their own > choices. That is also a nonsensical assertion. The issue here is that there is a tradeoff between provable global bloat to the entire distribution and a very questionable gain in functionality. > This change has all three and so is going to be yelled at over and > over again. Instead you should make a change request which will give > you all those but has some other item tied to it. So you are advocating deliberately using a dishonest and misleading political tactic that politicians are rightfully criticized for, namely hiding unwanted changes in a larger change proposal? > ** We do not have these conversations that the linux-firmware over > time has eaten more disk space or that other compiler choices have > done even worse. It only comes up when people ask for permission > versus just doing it. Oh, we do complain about the creeping bloat, repeatedly. Though there is only so much we can do downstream about linux-firmware growing all the time. This change, on the other hand, is entirely a Fedora decision that we have full control of. Kevin Kofler ___ 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 35 compose report: 20211028.n.0 changes
OLD: Fedora-35-20211027.n.0 NEW: Fedora-35-20211028.n.0 = SUMMARY = Added images:0 Dropped images: 1 Added packages: 0 Dropped packages:0 Upgraded packages: 0 Downgraded packages: 0 Size of added packages: 0 B Size of dropped packages:0 B Size of upgraded packages: 0 B Size of downgraded packages: 0 B Size change of upgraded packages: 0 B Size change of downgraded packages: 0 B = ADDED IMAGES = = DROPPED IMAGES = Image: Container_Minimal_Base docker aarch64 Path: Container/aarch64/images/Fedora-Container-Minimal-Base-35-20211027.n.0.aarch64.tar.xz = ADDED PACKAGES = = DROPPED PACKAGES = = UPGRADED PACKAGES = = 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: F36 Change: Package information on ELF objects (System-Wide Change proposal)
On Wed, Oct 27, 2021 at 03:24:07AM +0200, Kevin Kofler via devel wrote: > > == Owner == > > (for example using Fedora containers on Debian or vice versa), > > Containers ought to include the (guest) distribution's package database. > Everything else is just broken and needs to be fixed. Indeed. This stupidity in something called "Bazel" breaks libguestfs for one. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com virt-df lists disk usage of guests without needing to install any software inside the virtual machine. Supports Linux and Windows. http://people.redhat.com/~rjones/virt-df/ ___ 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: F36 Change: Package information on ELF objects (System-Wide Change proposal)
Once upon a time, Vitaly Zaitsev via devel said: > SSD is must have nowadays. Typical SSD size is still 128/256 GB, > because 500+ GB is too expensive for now. New 500G SSDs are available under $50, and 1TB under $90. -- Chris Adams ___ 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
F36 Change: Stratis 3.0.0 (Self-Contained Change proposal)
https://fedoraproject.org/wiki/Changes/Stratis_3.0.0 == Summary == Stratis 3.0.0 includes many internal improvements, bug fixes, and user-visible changes. == Owner == * Name: [[User:dkeefe|Dennis Keefe]], [[User:mulhern|Anne Mulhern]], [[User:jbaublitz|John Baublitz]] * Email: dke...@redhat.com, amulh...@redhat.com, jbaubl...@redhat.com == Detailed Description == === stratisd 3.0.0 === stratisd 3.0.0 includes a number of significant internal improvements and a few bug fixes. In stratisd 3.0.0 the D-Bus API has undergone a revision and the prior interfaces are all removed. The `FetchProperties` interfaces that were supported by all objects have been removed. The values that were previously obtainable via the `FetchProperties` methods are now conventional D-Bus properties. The possible values of error codes returned by the D-Bus methods have been reduced to 0 and 1, with the usual interpretation. `stratisd` bug fixes: * The `--prompt` option was not passed to `stratis-min` in the `stratis-fstab-setup` script; this prevented the user from entering the password necessary to unlock an encrypted pool during boot. This is no longer the case. * `stratisd` was not immediately updating the devicemapper device stack when a cache was initialized with the result that the cache was not immediately put in use. This is no longer the case. * `stratisd` was not immediately updating the Clevis encryption info associated with a pool on a command to bind an encrypted pool with Clevis. This problem has been corrected. * `stratisd` was sending an incorrect D-Bus signal on a pool name change; this has been fixed. * Previously, when stratisd-min, which runs during boot before D-Bus functionality is available, gave way to stratisd when the D-Bus had been set up, it was possible for inconsistencies to arise if the Stratis engine was performing an operation which required invoking a distinct executable. The executable might be terminated during its execution, and stratisd-min would take the action appropriate to the command failure before exiting. Now, systemd is instructed to send a kill signal only to stratisd-min and not to any of stratisd-min's child processes when shutting down stratisd-min. * Previously, if the same device was specified using two different paths when creating or extending a pool the different paths would be interpreted as two different devices and an error would be returned when stratisd attempted to initialize the device a second time. Now, the different paths are canonicalized eagerly, and converted into a single canonical representation of the device, stratisd initializes the device only once, and no error is returned. * Previously, stratisd did not report all existing object paths in the result of a D-Bus Introspect() call. This was due to a bug in version 0.9.1 and previous of stratisd's dbus-tree dependency. stratisd now requires dbus-tree 0.9.2, so all nodes are reported. Other `stratisd` improvements: * Previously, stratisd relied entirely on udev information when deciding whether a storage device was not in use by another application and could safely be overwritten with Stratis metadata. Now it performs a supplementary check using libblkid and exits with an error if libblkid reports that the device is in use. * Handling of errors returned by internal methods is improved; a chaining mechanism has been introduced and the error chains can be scrutinized programatically to identify expected scenarios like rollback failures. * A set of states indicating that a pool has reduced capability have been added internally and are published on the D-Bus. A pool's capability is reduced on an error being returned internally which contains, somewhere in its chain, the appropriate identifying error variant. * The code used to roll back failed encryption operations on a list of pool devices has been refactored and generalized. It is now capable of returning an error that can be used to identify a restricted pool capability due to a rollback failure. * `stratisd` uses sha-256 instead of sha-1 for Clevis-related encryption operations to conform with Clevis's own usage. * `stratisd` exits more elegantly and less frequently if it encounters an error during execution of the distinct tasks that are assigned to the individual threads that it manages internally. * In preparation for edition 2021 of the Rust language, `stratisd` source code has been updated to conform entirely to edition 2018 recommendations. == Detailed Description == === stratis-cli 3.0.0 === Users of the Stratis CLI may observe the following changes: * It is now possible to set the filesystem logical size when creating a filesystem. * It is possible to rebind a pool using a Clevis tang server or with a key in the kernel keyring. * Filesystem and pool list output have been extended and improved. The pool listing includes an `Alerts` column. Currently this column is used to indicate whether the pool is in a restricted operation mode. A new
F36 Change: Stratis 3.0.0 (Self-Contained Change proposal)
https://fedoraproject.org/wiki/Changes/Stratis_3.0.0 == Summary == Stratis 3.0.0 includes many internal improvements, bug fixes, and user-visible changes. == Owner == * Name: [[User:dkeefe|Dennis Keefe]], [[User:mulhern|Anne Mulhern]], [[User:jbaublitz|John Baublitz]] * Email: dke...@redhat.com, amulh...@redhat.com, jbaubl...@redhat.com == Detailed Description == === stratisd 3.0.0 === stratisd 3.0.0 includes a number of significant internal improvements and a few bug fixes. In stratisd 3.0.0 the D-Bus API has undergone a revision and the prior interfaces are all removed. The `FetchProperties` interfaces that were supported by all objects have been removed. The values that were previously obtainable via the `FetchProperties` methods are now conventional D-Bus properties. The possible values of error codes returned by the D-Bus methods have been reduced to 0 and 1, with the usual interpretation. `stratisd` bug fixes: * The `--prompt` option was not passed to `stratis-min` in the `stratis-fstab-setup` script; this prevented the user from entering the password necessary to unlock an encrypted pool during boot. This is no longer the case. * `stratisd` was not immediately updating the devicemapper device stack when a cache was initialized with the result that the cache was not immediately put in use. This is no longer the case. * `stratisd` was not immediately updating the Clevis encryption info associated with a pool on a command to bind an encrypted pool with Clevis. This problem has been corrected. * `stratisd` was sending an incorrect D-Bus signal on a pool name change; this has been fixed. * Previously, when stratisd-min, which runs during boot before D-Bus functionality is available, gave way to stratisd when the D-Bus had been set up, it was possible for inconsistencies to arise if the Stratis engine was performing an operation which required invoking a distinct executable. The executable might be terminated during its execution, and stratisd-min would take the action appropriate to the command failure before exiting. Now, systemd is instructed to send a kill signal only to stratisd-min and not to any of stratisd-min's child processes when shutting down stratisd-min. * Previously, if the same device was specified using two different paths when creating or extending a pool the different paths would be interpreted as two different devices and an error would be returned when stratisd attempted to initialize the device a second time. Now, the different paths are canonicalized eagerly, and converted into a single canonical representation of the device, stratisd initializes the device only once, and no error is returned. * Previously, stratisd did not report all existing object paths in the result of a D-Bus Introspect() call. This was due to a bug in version 0.9.1 and previous of stratisd's dbus-tree dependency. stratisd now requires dbus-tree 0.9.2, so all nodes are reported. Other `stratisd` improvements: * Previously, stratisd relied entirely on udev information when deciding whether a storage device was not in use by another application and could safely be overwritten with Stratis metadata. Now it performs a supplementary check using libblkid and exits with an error if libblkid reports that the device is in use. * Handling of errors returned by internal methods is improved; a chaining mechanism has been introduced and the error chains can be scrutinized programatically to identify expected scenarios like rollback failures. * A set of states indicating that a pool has reduced capability have been added internally and are published on the D-Bus. A pool's capability is reduced on an error being returned internally which contains, somewhere in its chain, the appropriate identifying error variant. * The code used to roll back failed encryption operations on a list of pool devices has been refactored and generalized. It is now capable of returning an error that can be used to identify a restricted pool capability due to a rollback failure. * `stratisd` uses sha-256 instead of sha-1 for Clevis-related encryption operations to conform with Clevis's own usage. * `stratisd` exits more elegantly and less frequently if it encounters an error during execution of the distinct tasks that are assigned to the individual threads that it manages internally. * In preparation for edition 2021 of the Rust language, `stratisd` source code has been updated to conform entirely to edition 2018 recommendations. == Detailed Description == === stratis-cli 3.0.0 === Users of the Stratis CLI may observe the following changes: * It is now possible to set the filesystem logical size when creating a filesystem. * It is possible to rebind a pool using a Clevis tang server or with a key in the kernel keyring. * Filesystem and pool list output have been extended and improved. The pool listing includes an `Alerts` column. Currently this column is used to indicate whether the pool is in a restricted operation mode. A new
Re: glusterfs on armv7
See https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/3MQ4ZRPS4MOIDG2RPAR6YX43VX2MCOLW/ I have not had a chance to follow through yet with a self contained change... On Thu, Oct 28, 2021 at 9:36 AM Richard W.M. Jones wrote: > > https://bugzilla.redhat.com/show_bug.cgi?id=2018182 > > Looks like glusterfs has been dropped on armv7. Is this a permanent > state of affairs? Is there a bug about it? > > (I don't care either way, just want to know if we should drop the > libvirt support for glusterfs on armv7 too.) > > Rich. > > -- > Richard Jones, Virtualization Group, Red Hat > http://people.redhat.com/~rjones > Read my programming and virtualization blog: http://rwmj.wordpress.com > Fedora Windows cross-compiler. Compile Windows programs, test, and > build Windows installers. Over 100 libraries supported. > http://fedoraproject.org/wiki/MinGW > > -- Kaleb ___ 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
glusterfs on armv7
https://bugzilla.redhat.com/show_bug.cgi?id=2018182 Looks like glusterfs has been dropped on armv7. Is this a permanent state of affairs? Is there a bug about it? (I don't care either way, just want to know if we should drop the libvirt support for glusterfs on armv7 too.) Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com Fedora Windows cross-compiler. Compile Windows programs, test, and build Windows installers. Over 100 libraries supported. http://fedoraproject.org/wiki/MinGW ___ 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] PHP 8.1 mass rebuild - Done
Le 28/10/2021 à 10:50, Remi Collet a écrit : Mass rebuild is in progress in f36-build-side-47161 which already have php-8.1.0~RC5-1.fc36 Mass rebuild done 58/63 packages were built with success and are now available in rawhide See: https://bodhi.fedoraproject.org/updates/FEDORA-2021-610b3547a3 FTBFS for #2018180php-facedetect php-pecl-ds php-pecl-solr2 php-zmq #2018182libguestfs Cheers, Remi ___ 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: F36 Change: Package information on ELF objects (System-Wide Change proposal)
On Thu, 28 Oct 2021 at 08:51, Michael Catanzaro wrote: > > > What I just don't understand is why so much argument over a minuscule > disk space increase. We can argue over the best way to create > backtraces. But trying to step on the toes of other people who are > working on this problem just because their work requires a tiny > annotation in each binary seems weird. > My take from these conversations is that it is best to a) Not have Lennart's name tied to a request. That just pulls in all kinds of over-the-top statements where people will say 99.99% of the people won't use it without any evidence. b) Don't mention disk space growth. You will get nothing about how you are bloating the operating system. ** c) Don't mention anything about making debugging or security easier. Anyone who has a workflow will see that as a challenge to their own choices. This change has all three and so is going to be yelled at over and over again. Instead you should make a change request which will give you all those but has some other item tied to it. ** We do not have these conversations that the linux-firmware over time has eaten more disk space or that other compiler choices have done even worse. It only comes up when people ask for permission versus just doing it. -- Stephen J Smoogen. I've seen things you people wouldn't believe. Flame wars in sci.astro.orion. I have seen SPAM filters overload because of Godwin's Law. All those moments will be lost in time... like posts on a BBS... time to shutdown -h now. ___ 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: F36 Change: Package information on ELF objects (System-Wide Change proposal)
What I just don't understand is why so much argument over a minuscule disk space increase. We can argue over the best way to create backtraces. But trying to step on the toes of other people who are working on this problem just because their work requires a tiny annotation in each binary seems weird. ___ 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
Review Swap sugar-view-slides
Hi Everyone, I currently have a review request open for the sugar-view-slides package, the package was dropped a while back due to an FTB and the package has been fixed and now builds but is still been dropped by rawhide. Can someone help me review it so it can get added back to rawhide? Thanks. signature.asc Description: This is a digitally signed message part ___ 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: F36 Change: Package information on ELF objects (System-Wide Change proposal)
Lennart Poettering wrote: > I understand you are not working with backtraces/coredumps every > day. For core dumps, this is true. (I have found those to not be of much use, other than getting a backtrace, but I would rather just get the backtrace directly.) For backtraces, it is not. I regularly look a backtraces. Often my own ones, but sometimes also those submitted by users. > But as someone who's at the upstream receiving end of bug reports of one > major project I can tell you that MiniDebugInfo is literally the best > thing since sliced bread: in systemd upstream the bug reports we get from > Fedora are *ridiculously* more useful than bug reports from any other > distro, since the default way how things are reported already carry > backtraces that are quite useful. This does not match my experience at all. I find MiniDebugInfo backtraces to be only marginally more useful than backtraces with no debugging information at all (and incidentally, at least last I checked, the backtrace quality rating algorithms in both ABRT and DrKonqi happen(ed) to agree with me and will (would?) ask the user to install the full -debuginfo anyway). Those backtraces have: * no line numbers and * no function argument values so there is little to no clue where exactly it crashed nor under what conditions. (Are your functions so small that you can figure out the exact location of the crash from the function name alone?) And if the crash is in a shared library (which it often is), in an exported function (which crashes in a shared library often are), then even the backtraces with no debugging information will tell you the function in which the crash happened. (Of course, this is not the case if the crash is in some out-of-process systemd-foo executable.) So there are several cases where MiniDebugInfo adds no value at all. > It's a complete mess with other distros, since we have to ask people to > come back with proper backtraces with debuginfo installed, and only a > subset of people is willing to bother with that. Bug reports from > ArchLinux, Debian, Gentoo and so on are total crap by default compared to > Fedora. Well, the issue on ArchLinux is that they do not ship -debuginfo packages at all. So the user has to recompile the package with debugging information, which unsurprisingly they will not be willing to do in most cases. And Gentoo obviously requires recompilation as well because (almost) everything gets compiled on the user's machine to begin with. > So if you are going to dump shit on MiniDebugInfo like you are doing then > what I hear is that you just have no clue with working and maintaining > software upstream. I take offense at this assertion. > (And I understand that mrqonki or what's it called DrKonqi: * Dr as in Doctor (because it diagnoses programs just like a medical doctor diagnoses patients), * Konqi as in the mascot of KDE (a dragon named after the browser and file manager Konqueror that used to be the flagship application of KDE). > is your holy grail of crash reporting, but I find it entirely > uninteresting since it's in no way set up for doing system-level > backtraces, run during early boot or anything like that. True, DrKonqi will only work if you have X11 or Wayland already running. > It might be OK for app crash dumps if it actually works, but we are not > just building apps here, we are first and foremost *OS* builders, and > something that can't handle system level stuff properl is just not > relevant then. Now it is you who are assuming that everyone only works with what you are familiar with. Large parts of our operating system are user-level applications that either always run in or can be run in a desktop session. > That said, running back trace processors in-process or even just with user > creds like mrqonki is doing it apparently The way DrKonqi works is that there are actually 2 separate components: KCrash and DrKonqi: * KCrash is the in-process crash handler. It is shipped in a shared library (the "KDE Framework" KCrash, one of the several "KDE Frameworks"). It is just a small signal handler that does not do much, basically just: - fork, - pause/halt the parent fork, waiting for GDB to attach, - exec DrKonqi in the child fork, passing the PID for it to attach GDB to. * DrKonqi is the out-of-process crash reporter. It gets launched by KCrash as explained above. It brings up a GUI dialog showing what application crashed and where to report bugs to. It also attaches GDB to the crashed process and shows the backtrace in a text field in the GUI. It also offers to install missing debugging information through a shell script shipped with it. And it can automatically upload reports to the bugs.kde.org Bugzilla. > is a really bad idea anyway: if an app has crashed, its memory is fucked > then you don't want to run code inside it and you want to process its > coredump tightly sandboxed with the least privs possible — something > systemd-coredump
Re: F36 Change: Drop NIS(+) support from PAM (System-Wide Change proposal)
On Wed, 27 Oct 2021 at 23:47, Ian Kent wrote: > > On Wed, 2021-10-27 at 13:40 -0400, Matthew Miller wrote: > > On Thu, Oct 21, 2021 at 04:37:18PM -0400, Ben Cotton wrote: > > > == User Experience == > > > For some users this change may be a bit disruptive and it may > > > require > > > some learning curve for switching to alternative solutions. > > > > I've spoken with some of my sysadmin friends and universities, and > > they > > suggest that the above is enough of an understatement to feel > > insulting. > > > > They would like, at least, more time than F36 to adjust to this, and > > broader > > communication that we plan to drop it. > > Remind me, why is NIS support being dropped? > > Personally I thought it was a bad idea from the first I heard of it > and never saw any actual valid reasons to do so. I was simply told > to drop it from my package which I did. > > Ian Mainly because it is the authentication service equivalent of telnet**. Very simple to set up, very simple to use, and very easy to steal all the information about logins, users, and setups. You can secure it up to a point, but many of its faults like unencrypted text are designed into its 35 year old structure. It is a service which gets flagged on many security scans as a 'incredibly' high and is beginning to be flagged as a 'this should not even be shipped to us' by various sites (mainly because they have had major security breakins and their insurance company will no longer cover them unless they get serious.). ** And like telnet, it will only be dragged out of various infrastructures on the retirement of a generation of sysadmins. -- Stephen J Smoogen. I've seen things you people wouldn't believe. Flame wars in sci.astro.orion. I have seen SPAM filters overload because of Godwin's Law. All those moments will be lost in time... like posts on a BBS... time to shutdown -h now. ___ 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
CPE Weekly Update – Week of October 25th – 29th
Hello, This is a weekly report from the CPE (Community Platform Engineering) Team. If you have any questions or feedback, please respond to this report or contact us on #redhat-cpe channel on libera.chat (https://libera.chat/). If you wish to read in a well-formatted blog post, check the post on Fedora community blog: https://communityblog.fedoraproject.org/cpe-weekly-update-week-of-october-25th-29th/ # Highlights of the week ## Infrastructure & Release Engineering Goal of this Initiative --- Purpose of this team is to take care of day to day business regarding CentOS and Fedora Infrastructure and Fedora release engineering work. It’s responsible for services running in Fedora and CentOS infrastructure and preparing things for the new Fedora release (mirrors, mass branching, new namespaces etc.). The ARC (which is a subset of the team) investigates possible initiatives that CPE might take on. Updates --- ### Fedora Infra * Freeze breaks: added regions to aws fedimg uploads and fixed a caching issue with upgrade json * Rebooted: proxy34 and bvmhost-x86-07 * Tried to fix move of wiki talk pages, ended up creating PR to disable all talk pages. * At 66 tickets, but many should be closable after freeze ### CentOS Infra including CentOS CI * Kicked some migration for tenants on legacy cluster (nfs-ganesha) * Rebased cico-workspace container to 8-stream (staging) (Ref https://quay.io/repository/centosci/cico-workspace/build/b197513b-0105-4774-a651-89cc4fe8e19d ) * Pushed some new ciphers in prod through ansible role to get A+ cert on Qualys (Ref https://www.ssllabs.com/ssltest/analyze.html?d=git.centos.org=on ) * Mirrormanager tuning with Adrian for 9-stream inside CI infra (Ref https://admin.fedoraproject.org/mirrormanager/host/2751) * Added/announced aarch64 as covered architecture for CI infra tenants ### Release Engineering * F35 RC-1.2 is out and can be found at https://dl.fedoraproject.org/pub/alt/stage/35_RC-1.2/ * Business as usual ## CentOS Stream Goal of this Initiative --- This initiative is working on CentOS Stream/Emerging RHEL to make this new distribution a reality. The goal of this initiative is to prepare the ecosystem for the new CentOS Stream. Updates --- * Basic Stream/RHEL Buildroot reporting is in place, thanks James! * Open discussion on pruning older packages from what we publish to the mirrors * Open discussion on the impact of consolidating the Stream 8 and Stream 9 workflows for maintainers * Business as usual ## CentOS Duffy CI Goal of this Initiative --- Duffy is a system within CentOS CI Infra which allows tenants to provision and access bare metal resources of multiple architectures for the purposes of CI testing. We need to add the ability to checkout VMs in CentOS CI in Duffy. We have OpenNebula hypervisor available, and have started developing playbooks which can be used to create VMs using the OpenNebula API, but due to the current state of how Duffy is deployed, we are blocked with new dev work to add the VM checkout functionality. Updates --- * Set up a boilerplate with a skeleton application * Set up the CI in the repository with tests and coverage * Created a CLI for configuring parameters * Discussed workflows and methods for implementing models ## FCOS OpenShift migration Goal of this Initiative --- Move current Fedora CoreOS pipeline from the centos-ci OCP4 cluster to the newly deployed fedora infra OCP4 cluster. Updates --- * Obtaining access on the cluster * Creating playbook to create OpenShift resources * Got the cluster updated and ready Thanks and regards, Akashdeep Dhar t0xic0...@fedoraproject.org akashd...@redhat.com ___ 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: F36 Change: Package information on ELF objects (System-Wide Change proposal)
Hi Lennart, On Thu, 2021-10-28 at 09:56 +0200, Lennart Poettering wrote: > But as someone who's at the upstream receiving end of bug > reports > of one major project I can tell you that MiniDebugInfo is literally > the best thing since sliced bread: in systemd upstream the bug reports > we get from Fedora are *ridiculously* more useful than bug reports > from any other distro, since the default way how things are reported > already carry backtraces that are quite useful. It's a complete mess > with other distros, since we have to ask people to come back with > proper backtraces with debuginfo installed, and only a subset of > people is willing to bother with that. Bug reports from ArchLinux, > Debian, Gentoo and so on are total crap by default compared to > Fedora. This is good to hear (the Fedora part). Note that we have moved all the symbol/debuginfo manipulation done in Fedora into upstream rpm first and have now spun out that part into a separate project "debugedit" that rpm (and flatpak) now uses and that we hope other distros/packaging tools will adopt: https://sourceware.org/debugedit/ debugedit provides programs and scripts for creating debuginfo and source file distributions, collect build-ids and rewrite source paths in DWARF data for debugging, tracing and profiling. So please point other distros/packagers our way and we'll try to work with them to make these tools as useful to them as they are to Fedora. Thanks, Mark ___ 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
[Bug 2018102] stompclt-1.7 is available
https://bugzilla.redhat.com/show_bug.cgi?id=2018102 Fedora Update System changed: What|Removed |Added Status|ASSIGNED|MODIFIED --- Comment #1 from Fedora Update System --- FEDORA-2021-05fb85d77c has been submitted as an update to Fedora 34. https://bodhi.fedoraproject.org/updates/FEDORA-2021-05fb85d77c -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2018102 ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-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/perl-devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[Bug 2018102] stompclt-1.7 is available
https://bugzilla.redhat.com/show_bug.cgi?id=2018102 --- Comment #4 from Fedora Update System --- FEDORA-EPEL-2021-903b0ef95e has been submitted as an update to Fedora EPEL 7. https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2021-903b0ef95e -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2018102 ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-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/perl-devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[Bug 2018102] stompclt-1.7 is available
https://bugzilla.redhat.com/show_bug.cgi?id=2018102 Fedora Update System changed: What|Removed |Added Status|ASSIGNED|MODIFIED --- Comment #1 from Fedora Update System --- FEDORA-2021-05fb85d77c has been submitted as an update to Fedora 34. https://bodhi.fedoraproject.org/updates/FEDORA-2021-05fb85d77c --- Comment #2 from Fedora Update System --- FEDORA-EPEL-2021-30b2469a06 has been submitted as an update to Fedora EPEL 8. https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2021-30b2469a06 -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2018102 ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-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/perl-devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F36 Change: Package information on ELF objects (System-Wide Change proposal)
Hi Daniel, On Wed, 2021-10-27 at 10:01 +0100, Daniel P. Berrangé wrote: > Getting RPM NEVRs directly from the coredumps is something that > will be incredibly helpful for people dealing with support > requests after crashes. build-ids have always been very tedious > to deal with and as you say RPM database may be newer than what > is in memory. This benefit alone will make it all worthwhile > from my POV. > [...] > Furthermore as someone dealing with bug reports I don't have access > to the RPM database. That is on the end user's machine. Often all I > get is a core dump attached to a bug report, and if I'm lucky they > manually typed a couple of RPM NEVRs into the bug description. On > many occassions I've found the NEVRs the user supplied in the > description to be wrong due to mistakes on the bug reporter's side > collecting the data. Note that we have been working on integrating debuginfod in more distros (it will be enable by default in Fedora 35): https://debuginfod.fedoraproject.org/ There is also an "global" debuginfod server that aggregates all other distros debuginfod servers: https://debuginfod.elfutils.org/ Which should delegate to the fedora, opensuse, debian, altlinux, etc. debuginfod servers to query their build-id databases. Which means it should be a lot easier to get, given a build-id (in a core file, or simply in memory even if the original ELF file on disk is gone) the executable, debuginfo and associated source files. For the next version of debuginfod we are trying to also give you information about the original archive (including the nevr in the name) that the information came from. This is not to say we don't need the Package information in ELF files. Having that (especially if it includes the corresponding debuginfod URL) will make it even easier to get the corresponding debuginfo and sources for a given ELF binary/build-id. Cheers, Mark ___ 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
[Bug 2018102] stompclt-1.7 is available
https://bugzilla.redhat.com/show_bug.cgi?id=2018102 lionel.c...@cern.ch changed: What|Removed |Added Doc Type|--- |If docs needed, set a value Status|NEW |ASSIGNED -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2018102 ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-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/perl-devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F36 Change: Package information on ELF objects (System-Wide Change proposal)
> On 27/10/2021 21:38, Luca Boccassi wrote: > > I will ask additional information from user if the bug report has no > useful backtrace. Which you might get or not, and might be correct or not. This is what we experience daily - just because you are lucky and don't need it, it doesn't mean nobody else does. See: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/DNCBX76FW5Y7OAA2BWXQZKSVX7LXS6MD/ > Most upstream developers are too busy and just close the bug report > without useful information such as a full crash core dump or a backtrace. Exactly, which is a bad state of affairs as bugs go unfixed and users are kept unhappy and developers are frustrated. ___ 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-34-20211028.0 compose check report
No missing expected images. Soft failed openQA tests: 1/8 (x86_64), 1/8 (aarch64) (Tests completed, but using a workaround for a known bug) Old soft failures (same test soft failed in Fedora-Cloud-34-20211027.0): ID: 1043564 Test: x86_64 Cloud_Base-qcow2-qcow2 cloud_autocloud URL: https://openqa.fedoraproject.org/tests/1043564 ID: 1043565 Test: aarch64 Cloud_Base-qcow2-qcow2 cloud_autocloud@uefi URL: https://openqa.fedoraproject.org/tests/1043565 Passed openQA tests: 7/8 (x86_64), 7/8 (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
[Bug 2018102] New: stompclt-1.7 is available
https://bugzilla.redhat.com/show_bug.cgi?id=2018102 Bug ID: 2018102 Summary: stompclt-1.7 is available Product: Fedora Version: rawhide Status: NEW Component: stompclt Keywords: FutureFeature, Triaged Assignee: lionel.c...@cern.ch Reporter: upstream-release-monitor...@fedoraproject.org QA Contact: extras...@fedoraproject.org CC: lionel.c...@cern.ch, perl-devel@lists.fedoraproject.org Target Milestone: --- Classification: Fedora Latest upstream release: 1.7 Current version/release in rawhide: 1.6-9.fc35 URL: https://github.com/cern-mig/stompclt Please consult the package updates policy before you issue an update to a stable branch: https://docs.fedoraproject.org/en-US/fesco/Updates_Policy/ More information about the service that created this bug can be found at: https://fedoraproject.org/wiki/Upstream_release_monitoring Please keep in mind that with any upstream change, there may also be packaging changes that need to be made. Specifically, please remember that it is your responsibility to review the new version to ensure that the licensing is still correct and that no non-free or legally problematic items have been added upstream. Based on the information from anitya: https://release-monitoring.org/project/4896/ -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2018102 ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-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/perl-devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[HEADS UP] PHP 8.1 mass rebuild
Hi, I started working on PHP 8.1 on F36/Rawhide https://fedoraproject.org/wiki/Changes/php81 Mass rebuild is in progress in f36-build-side-47161 which already have php-8.1.0~RC5-1.fc36 I will try to take care of most extensions so please don't build any, or use the side tag and please tell me. Remi ___ 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: F36 Change: Package information on ELF objects (System-Wide Change proposal)
On 28/10/2021 00:22, Kevin Kofler via devel wrote: IMHO, core dumps should not even be enabled by default to begin with. They are typically just a useless waste of disk space. Uploading them is a bad idea because they are huge and can contain sensitive personal information. Yes, publishing and working with full core dumps can violate GDPR, because they may contain personal information. Minudumps or backtraces are safe. -- Sincerely, Vitaly Zaitsev (vit...@easycoding.org) ___ 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: F36 Change: Package information on ELF objects (System-Wide Change proposal)
On 27/10/2021 22:22, Lennart Poettering wrote: So no, if you aren't interested in reading coredumps yourself you won't benefit immediately. But if you want to increase the chance that the various bugs you undoubtly run into every now and then have the highest chance to be fixed quickly, then it's a good thing if the people who provide you with the software can determine with minimal effort what a coredump or minimal backtrace actually belongs to. And the price for improving the life of your distro developers is just a few 100K on your disk. So while you might not benefit immediately, you will benefit in the long run. I think the most popular distributions should install and enable the automatic coredumps analyzer, like Fedora has[1]. It will help much more. [1]: https://retrace.fedoraproject.org/faf/summary/ -- Sincerely, Vitaly Zaitsev (vit...@easycoding.org) ___ 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: F36 Change: Package information on ELF objects (System-Wide Change proposal)
On 27/10/2021 21:38, Luca Boccassi wrote: As an upstream developer, you get what users send you, which might or might not be what you prefer I will ask additional information from user if the bug report has no useful backtrace. With this change, the bare minimum produced as a corefile is useful and actionable even when everything else has failed. Most upstream developers are too busy and just close the bug report without useful information such as a full crash core dump or a backtrace. -- Sincerely, Vitaly Zaitsev (vit...@easycoding.org) ___ 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: F36 Change: Package information on ELF objects (System-Wide Change proposal)
On Do, 28.10.21 00:22, Fedora Development ML (devel@lists.fedoraproject.org) wrote: > And me mentioning "crash handler" and "no core dumps" together is > not a mistake. A well-designed crash handler does NOT operate on > core dumps, but on live processes. This implies that it should be > triggered by a signal handler within the executable, ideally shipped > by the upstream so that it reports the crashes directly > upstream. (This is how KCrash and DrKonqi work. But also, e.g., > Google Breakpad.) I am sorry but this is a rubbish idea. Don't process crashes from inside the crashed process, you are working in a corrupted environment, with memory issues and you might modify the image as you are part of it. You run with full user creds while doing so, and since crash dumping/backtrace generation is ultimately parsing data that#s a bad idea. If you want to analyze crashes safely then do it strictly offline, i.e. on an immutable, frozen dump of the image, from the outside, and do it in a sandboxed environment, so that your analysis can't easily be exploited. It's the only safe and robust thing you can do if you actually want to do this in an automatic way. (hint: this is what systemd-coredump does. For a reason.) Lennart -- Lennart Poettering, Berlin ___ 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: F36 Change: Package information on ELF objects (System-Wide Change proposal)
On Do, 28.10.21 01:48, Fedora Development ML (devel@lists.fedoraproject.org) wrote: > That said, you are probably right that this change proposal is not the worst > source of bloat we have ever encountered. There has been much worse. (Just > in terms of bloat added to each ELF binary by Fedora-specific settings, I > think both MiniDebugInfo and Annobin really ought to be dropped. > MiniDebugInfo is no useful replacement for full debuginfo and only wastes > space. Annobin has no benefit for the end user at all and should be only > enabled in private QA rebuilds.) But the benefit of this change proposal is > also very small. And I disagree with the concept that "we have done worse" > is a valid argument for doing something bad. I understand you are not working with backtraces/coredumps every day. But as someone who's at the upstream receiving end of bug reports of one major project I can tell you that MiniDebugInfo is literally the best thing since sliced bread: in systemd upstream the bug reports we get from Fedora are *ridiculously* more useful than bug reports from any other distro, since the default way how things are reported already carry backtraces that are quite useful. It's a complete mess with other distros, since we have to ask people to come back with proper backtraces with debuginfo installed, and only a subset of people is willing to bother with that. Bug reports from ArchLinux, Debian, Gentoo and so on are total crap by default compared to Fedora. So if you are going to dump shit on MiniDebugInfo like you are doing then what I hear is that you just have no clue with working and maintaining software upstream. And the package JSON ELF note stuff we are talking about here will improve things further for us because we then can sanely filter out stuff that is already fixed and irrelevant: people are really bad at providing us with the necessary info manually with matching things up properly, and get it wrong *all* *the* *time*, and that problem goes away entirely then. So, for one minute, try to see things from the perspective of people who actually have to work with the backtraces and coredumps that are generated on Fedora systems. Just because Mr. Kevin Kofler himself doesn't deal with coredumps/backtraces that's not a reason to make life harder for those people who do. (And I understand that mrqonki or what's it called is your holy grail of crash reporting, but I find it entirely uninteresting since it's in no way set up for doing system-level backtraces, run during early boot or anything like that. It might be OK for app crash dumps if it actually works, but we are not just building apps here, we are first and foremost *OS* builders, and something that can't handle system level stuff properl is just not relevant then. — That said, running back trace processors in-process or even just with user creds like mrqonki is doing it apparently is a really bad idea anyway: if an app has crashed, its memory is fucked then you don't want to run code inside it and you want to process its coredump tightly sandboxed with the least privs possible — something systemd-coredump does btw) Software maintainability *matters*. And yes, a few 100K on a distro install are a very cheap price to pay for this. Lennart -- Lennart Poettering, Berlin ___ 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-20211028.0 compose check report
No missing expected images. Soft failed openQA tests: 1/8 (x86_64), 1/8 (aarch64) (Tests completed, but using a workaround for a known bug) Old soft failures (same test soft failed in Fedora-Cloud-33-20211027.0): ID: 1043548 Test: x86_64 Cloud_Base-qcow2-qcow2 cloud_autocloud URL: https://openqa.fedoraproject.org/tests/1043548 ID: 1043549 Test: aarch64 Cloud_Base-qcow2-qcow2 cloud_autocloud@uefi URL: https://openqa.fedoraproject.org/tests/1043549 Passed openQA tests: 7/8 (x86_64), 7/8 (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: F36 Change: Package information on ELF objects (System-Wide Change proposal)
On 28/10/2021 00:43, Luca Boccassi wrote: Today, 1 TB+ hard drives are common Have you tried using modern GNU/Linux distributions on hard drives? I tried. They were too slw. SSD is must have nowadays. Typical SSD size is still 128/256 GB, because 500+ GB is too expensive for now. -- Sincerely, Vitaly Zaitsev (vit...@easycoding.org) ___ 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: [Rawhide] ImageMagick-6.9.12-26 available
Le 28/10/2021 à 08:33, l...@fedoraproject.org a écrit : On 2021-10-27 10:21 a.m., "Antonio T. sagitter" wrote: Use a side-tag (https://docs.fedoraproject.org/en-US/package-maintainers/Package_Update_Guide/#multiple_packages), please. Done. ''' Side tag 'f36-build-side-47153' (id 47153) created. Use 'fedpkg build --target=f36-build-side-47153' to use it. Use 'koji wait-repo f36-build-side-47153' to wait for the build repo to be generated > ''' I don't see any value for using a side tag for a patch release (6.9.12.25 to 6.9.12.27) This make sense when major changes happen, so when library soname change. OK, with this strange library this may happen in patch version (4th digit), but should only be in 3rd digit bump, in which case installation directory also change and may require more work (e.g. /usr/lib64/ImageMagick-6.9.12) Remi ___ 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 ___ 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: [Rawhide] ImageMagick-6.9.12-26 available
Le 27/10/2021 à 01:42, Luya Tshimbalanga a écrit : Hello team, I would like to let you know ImageMagick-6.9.12-26 recently landed upstream. Learning from the previous experiences, I or my co-maintainer are planning to commit and build this package for Rawhide only in about a week, so the following maintainers of the respective packages will need to get in sync: Again, this list is not the right one, looks like you check what requires "ImageMagick" (the commands) but not "ImageMagick-libs" (the libraries) NsCDE a2ps anyremote c-graph caja-image-converter chordpro-abc conky-manager darktable-tools-noise devedeng dvd-slideshow epix fbida ffmulticonverter freewrl geeqie gscan2pdf gyazo jumpnbump-menu latex2rtf libpst lives lyx mediawiki mtpaint nautilus-image-converter nemo-image-converter perl-Graphics-TIFF-tests perl-PDF-API2-tests perl-PDF-Builder-tests perl-Panotools-Script playonlinux rubygem-mini_magic rubygem-rmagick shutter texlive-graphicxpsd variety vfrnav-utils w3m-img wdune The scratch-build is successful on https://koji.fedoraproject.org/koji/taskinfo?taskID=77869076 meaning proven packagers are welcome to commit the changes. Let know if anyone has a question. Regards, ___ 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: [Rawhide] ImageMagick-6.9.12-26 available
On 2021-10-27 10:21 a.m., "Antonio T. sagitter" wrote: Use a side-tag (https://docs.fedoraproject.org/en-US/package-maintainers/Package_Update_Guide/#multiple_packages), please. Done. ''' Side tag 'f36-build-side-47153' (id 47153) created. Use 'fedpkg build --target=f36-build-side-47153' to use it. Use 'koji wait-repo f36-build-side-47153' to wait for the build repo to be generated. ''' ___ 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
