Schedule for Thursday's FPC Meeting (2019-04-25 16:00 UTC)
Following is the list of topics that will be discussed in the FPC meeting Thursday at 2019-04-25 16:00 UTC in #fedora-meeting-1 on irc.freenode.net. Local time information (via. uitime): = Day: Thursday == 2019-04-25 09:00 PDT US/Pacific 2019-04-25 12:00 EDT --> US/Eastern <-- 2019-04-25 16:00 UTC UTC 2019-04-25 17:00 BST Europe/London 2019-04-25 18:00 CEST Europe/Berlin 2019-04-25 18:00 CEST Europe/Paris 2019-04-25 21:30 IST Asia/Calcutta New Day: Friday - 2019-04-26 00:00 HKT Asia/Hong_Kong 2019-04-26 00:00 +08 Asia/Singapore 2019-04-26 01:00 JST Asia/Tokyo 2019-04-26 02:00 AEST Australia/Brisbane Links to all tickets below can be found at: https://pagure.io/packaging-committee/issues?status=Open=meeting = Followups = #topic #382 Go Packaging Guidelines Draft .fpc 382 https://pagure.io/packaging-committee/issue/382 #topic #845 Wiki deprecation status .fpc 845 https://pagure.io/packaging-committee/issue/845 #topic #859 Scriptlet to replace a directory: try delete first? .fpc 859 https://pagure.io/packaging-committee/issue/859 = Open Floor = For more complete details, please visit each individual ticket. The report of the agenda items can be found at: https://pagure.io/packaging-committee/issues?status=Open=meeting If you would like to add something to this agenda, you can: * Reply to this e-mail * File a new ticket at: https://pagure.io/packaging-committee * E-mail me directly * Bring it up at the end of the meeting, during the open floor topic. Note that added topics may be deferred until the following meeting. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Thoughts on things getting harder (WAS: Orphaning js-jquery)
On Wed, Apr 24, 2019 at 4:15 PM Stephen Gallagher wrote: > > On Wed, Apr 24, 2019 at 3:33 PM Christopher > wrote: > > > > I'm orphaning js-jquery, since I do not have time to maintain it. > > > > It's getting harder to contribute to Fedora with all the mass > > orphaning of dependencies, and I don't have time to figure it all out. > > This is one that needs frequent attention, as jQuery is subject to > > lots of vulnerabilities, and deserves much more attention than I've > > been giving it. > > The orphaning of dependencies shouldn't be happening, but I (and > others) are working hard to get a solution in place that will un > the situation. I would have preferred not needing to do so under > emergency conditions, but what is, is. > > FWIW, things should *not* be getting harder. Some folks just jumped > the gun and made changes they weren't supposed to (yet) and now the > Modularity team has a lot of fires to put out and very few resources > with which to do it. When I first started contributing to Fedora, after having been a long-time user, it felt like it was easy for a "user" like me to contribute back to the OS that runs on their own computers. Now, things seem to be changing so much within Fedora that it's hard for someone like me to contribute to my preferred "Desktop Linux distro". A lot of these recent fast-paced changes seem to be very specialized... affecting all contributors to help slightly improve things for specific, small groups of people (such as those who work on composes (dist-git) or who need a mixed duration SLAs to support their enterprise customers (modularity), and those who operate in containers/cloud (Atomic)). I wish the focus would shift back to the "regular" users, so that Fedora would feel like a community-centric "Desktop Linux" OS again where anybody in the community can go from being a user to a contributor relatively easily. Until Fedora stops focusing tooling improvements on advanced users and specialized needs, at the cost of regular users, and focuses a proportional amount of effort on tooling that lowers the bar so that regular users can transition to contributor more easily, Fedora is probably going to continue to see a mass exodus of packages, including important dependencies, from the distro, as advanced users are lost to attrition, and their replacements will have a harder time becoming contributors. As an existing contributor, I feel the bar is raising... I can't imagine how somebody new would feel. I would like Fedora to do a few things to address this problem: 1. Focus on mentoring to onboard new people 2. Focus on tooling for contributing 3. Slow big changes to contributor processes down a bit... let tooling catch up 4. Slow things down with the release cadence; a breather, even if temporary, could allow community healing from previous big changes, and would give time to focus on items 1-3. I wish I saw more focus in Fedora on community-building, and onboarding new people, lowering the bar to contribute by improving contributor workflows for the average contributor... so it feels like a community distro again. Instead, I see a lot of stuff changing that feels like it (primarily) favors the few. And, when younger or less-experienced people do try to get involved... they just get bombarded with toxic conversations about why they should be ashamed of themselves for top-posting. It's not good. Not healthy. I'm optimistic things will improve... eventually... but in the meantime, I might have to orphan more of my packages (not that I have very many) until things get easier. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Fedora 30 RC 1.1 compose check report
No missing expected images. Failed openQA tests: 1/24 (i386), 3/146 (x86_64), 1/2 (arm) ID: 390773 Test: i386 Workstation-boot-iso install_default URL: https://openqa.fedoraproject.org/tests/390773 ID: 390787 Test: x86_64 KDE-live-iso apps_startstop URL: https://openqa.fedoraproject.org/tests/390787 ID: 390790 Test: arm Minimal-raw_xz-raw.xz install_arm_image_deployment_upload URL: https://openqa.fedoraproject.org/tests/390790 ID: 390896 Test: x86_64 universal install_arabic_language URL: https://openqa.fedoraproject.org/tests/390896 ID: 390897 Test: x86_64 universal install_cyrillic_language URL: https://openqa.fedoraproject.org/tests/390897 Soft failed openQA tests: 5/146 (x86_64), 3/24 (i386) (Tests completed, but using a workaround for a known bug) ID: 390745 Test: x86_64 Server-dvd-iso realmd_join_sssd URL: https://openqa.fedoraproject.org/tests/390745 ID: 390750 Test: i386 Server-boot-iso install_default URL: https://openqa.fedoraproject.org/tests/390750 ID: 390751 Test: i386 Server-dvd-iso install_default URL: https://openqa.fedoraproject.org/tests/390751 ID: 390760 Test: x86_64 Workstation-live-iso desktop_update_graphical URL: https://openqa.fedoraproject.org/tests/390760 ID: 390769 Test: x86_64 Workstation-boot-iso memory_check URL: https://openqa.fedoraproject.org/tests/390769 ID: 390770 Test: x86_64 Workstation-boot-iso memory_check@uefi URL: https://openqa.fedoraproject.org/tests/390770 ID: 390774 Test: i386 Workstation-boot-iso memory_check URL: https://openqa.fedoraproject.org/tests/390774 ID: 390792 Test: x86_64 Silverblue-dvd_ostree-iso install_default_upload URL: https://openqa.fedoraproject.org/tests/390792 Passed openQA tests: 138/146 (x86_64), 20/24 (i386) Skipped non-gating openQA tests: 1 of 172 -- 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://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Fedora 30-20190424.n.0 compose check report
Missing expected images: Atomichost raw-xz x86_64 Atomichost qcow2 x86_64 Failed openQA tests: 1/137 (x86_64), 1/2 (arm) ID: 390624 Test: x86_64 KDE-live-iso apps_startstop URL: https://openqa.fedoraproject.org/tests/390624 ID: 390627 Test: arm Minimal-raw_xz-raw.xz install_arm_image_deployment_upload URL: https://openqa.fedoraproject.org/tests/390627 Soft failed openQA tests: 3/23 (i386), 3/137 (x86_64) (Tests completed, but using a workaround for a known bug) ID: 390588 Test: i386 Server-boot-iso install_default URL: https://openqa.fedoraproject.org/tests/390588 ID: 390589 Test: i386 Server-dvd-iso install_default URL: https://openqa.fedoraproject.org/tests/390589 ID: 390598 Test: x86_64 Workstation-live-iso desktop_update_graphical URL: https://openqa.fedoraproject.org/tests/390598 ID: 390607 Test: x86_64 Workstation-boot-iso memory_check URL: https://openqa.fedoraproject.org/tests/390607 ID: 390608 Test: x86_64 Workstation-boot-iso memory_check@uefi URL: https://openqa.fedoraproject.org/tests/390608 ID: 390611 Test: i386 Workstation-boot-iso memory_check URL: https://openqa.fedoraproject.org/tests/390611 Passed openQA tests: 133/137 (x86_64), 20/23 (i386) Skipped non-gating openQA tests: 1 of 162 -- 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://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
[Bug 1702366] perl-Storable-3.15 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1702366 --- Comment #7 from Fedora Update System --- perl-Storable-3.15-1.fc29 has been pushed to the Fedora 29 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2019-e0f6509bb0 -- You are receiving this mail because: You are on the CC list for the bug. ___ 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://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
Fedora 30 compose report: 20190424.n.0 changes
OLD: Fedora-30-20190423.n.0 NEW: Fedora-30-20190424.n.0 = SUMMARY = Added images:1 Dropped images: 6 Added packages: 0 Dropped packages:0 Upgraded packages: 11 Downgraded packages: 0 Size of added packages: 0 B Size of dropped packages:0 B Size of upgraded packages: 148.19 MiB Size of downgraded packages: 0 B Size change of upgraded packages: 22.73 MiB Size change of downgraded packages: 0 B = ADDED IMAGES = Image: Python_Classroom live i386 Path: Labs/i386/iso/Fedora-Python-Classroom-Live-i386-30-20190424.n.0.iso = DROPPED IMAGES = Image: Scientific_KDE live x86_64 Path: Labs/x86_64/iso/Fedora-Scientific_KDE-Live-x86_64-30-20190423.n.0.iso Image: SoaS raw-xz armhfp Path: Spins/armhfp/images/Fedora-SoaS-armhfp-30-20190423.n.0-sda.raw.xz Image: Server boot s390x Path: Server/s390x/iso/Fedora-Server-netinst-s390x-30-20190423.n.0.iso Image: Server dvd s390x Path: Server/s390x/iso/Fedora-Server-dvd-s390x-30-20190423.n.0.iso Image: Workstation live i386 Path: Workstation/i386/iso/Fedora-Workstation-Live-i386-30-20190423.n.0.iso Image: Silverblue dvd-ostree x86_64 Path: Silverblue/x86_64/iso/Fedora-Silverblue-ostree-x86_64-30-20190423.n.0.iso = ADDED PACKAGES = = DROPPED PACKAGES = = UPGRADED PACKAGES = Package: appstream-generator-0.7.7-1.fc30 Old package: appstream-generator-0.7.4-1.fc30 Summary: Fast AppStream metadata generator RPMs: appstream-generator Size: 2.04 MiB Size change: 549.74 KiB Changelog: * Mon Feb 18 2019 Kalev Lember - 0.7.4-2 - Rebuilt for ldc 1.14 * Tue Apr 16 2019 Neal Gompa - 0.7.7-1 - Update to 0.7.7 (#1674286) Package: arm-image-installer-2.12-1.fc30 Old package: arm-image-installer-2.10-2.fc30 Summary: Writes binary image files to any specified block device RPMs: arm-image-installer Size: 46.82 KiB Size change: 2.24 KiB Changelog: * Tue Apr 09 2019 Paul Whalen - 2.11-1 - Update to 2.11 Package: desktop-backgrounds-30.0.0-2.fc30 Old package: desktop-backgrounds-30.0.0-1.fc30 Summary: Desktop backgrounds RPMs: desktop-backgrounds-basic desktop-backgrounds-compat desktop-backgrounds-gnome desktop-backgrounds-waves Size: 13.38 MiB Size change: 304 B Package: elementary-files-4.1.7-2.fc30 Old package: elementary-files-4.1.6-1.fc30 Summary: File manager from elementary RPMs: elementary-files elementary-files-devel Size: 5.12 MiB Size change: 5.03 KiB Changelog: * Sat Apr 13 2019 Fabio Valentini - 4.1.7-1 - Update to version 4.1.7. * Tue Apr 16 2019 Adam Williamson - 4.1.7-2 - Rebuild with Meson fix for #1699099 Package: gir-to-d-0.19.0-1.fc30 Old package: gir-to-d-0.18.0-4.fc30 Summary: Tool to create D bindings from GObject introspection files RPMs: gir-to-d Size: 1.13 MiB Size change: 108 B Changelog: * Tue Apr 16 2019 Neal Gompa - 0.19.0-1 - Update to 0.19.0 (#1689701) Package: glibd-2.1.0-1.fc30 Old package: glibd-2.0.2-1.fc30 Summary: D bindings for the GLib C Utility Library RPMs: glibd glibd-devel Size: 4.64 MiB Size change: 179.80 KiB Changelog: * Mon Feb 18 2019 Kalev Lember - 2.0.2-2 - Rebuilt for ldc 1.14 * Tue Apr 16 2019 Neal Gompa - 2.1.0-1 - Update to 2.1.0 Package: lollypop-1.0.6-3.fc30 Old package: lollypop-1.0.5-1.fc30 Summary: Music player for GNOME RPMs: lollypop Dropped RPMs: lollypop-cli Size: 829.29 KiB Size change: -15.17 KiB Changelog: * Tue Apr 16 2019 Martin Gansser - 1.0.6-1 - Update to 1.0.6 - Drop lollypop-cli * Tue Apr 16 2019 Adam Williamson - 1.0.6-2 - Rebuild with Meson fix for #1699099 * Wed Apr 17 2019 Martin Gansser - 1.0.6-3 - Obsoletes lollypop-cli Package: pacemaker-2.0.1-2.fc30 Old package: pacemaker-2.0.1-1.fc30 Summary: Scalable High-Availability cluster resource manager RPMs: pacemaker pacemaker-cli pacemaker-cluster-libs pacemaker-cts pacemaker-doc pacemaker-libs pacemaker-libs-devel pacemaker-nagios-plugins-metadata pacemaker-remote pacemaker-schemas Size: 33.60 MiB Size change: 21.95 MiB Changelog: * Wed Apr 17 2019 Jan Pokorn?? - 2.0.1-2 - Apply fixes for security issues: . CVE-2019-3885 (use-after-free with potential information disclosure) . CVE-2018-16877 (insufficient local IPC client-server authentication) . CVE-2018-16878 (insufficient verification inflicted preference of uncontrolled processes) Package: sequeler-0.7.0-2.fc30 Old package: sequeler-0.6.9-1.fc30 Summary: SQL Client built in Vala RPMs: sequeler Size: 1.16 MiB Size change: 1.64 KiB Changelog: * Mon Apr 15 2019 Fabio Valentini - 0.7.0-1 - Update to version 0.7.0. * Tue Apr 16 2019 Adam Williamson - 0.7.0-2 - Rebuild with Meson fix for #1699099 Package: switchboard-plug-sound-2.2.1-2.fc30 Old package
[Bug 1698174] perl-Sereal-Encoder-4.007 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1698174 Fedora Update System changed: What|Removed |Added Fixed In Version|perl-Sereal-Encoder-4.007-1 |perl-Sereal-Encoder-4.007-1 |.fc31 |.fc31 |perl-Sereal-Encoder-4.007-1 |perl-Sereal-Encoder-4.007-1 |.fc30 |.fc30 |perl-Sereal-Encoder-4.007-1 |perl-Sereal-Encoder-4.007-1 |.fc28 |.fc28 ||perl-Sereal-Encoder-4.007-1 ||.fc29 --- Comment #10 from Fedora Update System --- perl-Sereal-Encoder-4.007-1.fc29 has been pushed to the Fedora 29 stable repository. If problems still persist, please make note of it in this bug report. -- You are receiving this mail because: You are on the CC list for the bug. ___ 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://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
[Bug 1697634] perl-Sereal-Decoder-4.006 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1697634 Fedora Update System changed: What|Removed |Added Fixed In Version|perl-Sereal-Decoder-4.006-1 |perl-Sereal-Decoder-4.006-1 |.fc31 |.fc31 |perl-Sereal-Decoder-4.007-1 |perl-Sereal-Decoder-4.007-1 |.fc30 |.fc30 |perl-Sereal-Decoder-4.007-1 |perl-Sereal-Decoder-4.007-1 |.fc28 |.fc28 ||perl-Sereal-Decoder-4.007-1 ||.fc29 --- Comment #12 from Fedora Update System --- perl-Sereal-Decoder-4.007-1.fc29 has been pushed to the Fedora 29 stable repository. If problems still persist, please make note of it in this bug report. -- You are receiving this mail because: You are on the CC list for the bug. ___ 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://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
[Bug 1697635] perl-Sereal-Encoder-4.006 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1697635 Fedora Update System changed: What|Removed |Added Fixed In Version|perl-Sereal-Encoder-4.006-1 |perl-Sereal-Encoder-4.006-1 |.fc31 |.fc31 |perl-Sereal-Encoder-4.007-1 |perl-Sereal-Encoder-4.007-1 |.fc30 |.fc30 |perl-Sereal-Encoder-4.007-1 |perl-Sereal-Encoder-4.007-1 |.fc28 |.fc28 ||perl-Sereal-Encoder-4.007-1 ||.fc29 --- Comment #14 from Fedora Update System --- perl-Sereal-Encoder-4.007-1.fc29 has been pushed to the Fedora 29 stable repository. If problems still persist, please make note of it in this bug report. -- You are receiving this mail because: You are on the CC list for the bug. ___ 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://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
[Bug 1698173] perl-Sereal-Decoder-4.007 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1698173 Fedora Update System changed: What|Removed |Added Fixed In Version|perl-Sereal-Decoder-4.007-1 |perl-Sereal-Decoder-4.007-1 |.fc31 |.fc31 |perl-Sereal-Decoder-4.007-1 |perl-Sereal-Decoder-4.007-1 |.fc30 |.fc30 |perl-Sereal-Decoder-4.007-1 |perl-Sereal-Decoder-4.007-1 |.fc28 |.fc28 ||perl-Sereal-Decoder-4.007-1 ||.fc29 --- Comment #10 from Fedora Update System --- perl-Sereal-Decoder-4.007-1.fc29 has been pushed to the Fedora 29 stable repository. If problems still persist, please make note of it in this bug report. -- You are receiving this mail because: You are on the CC list for the bug. ___ 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://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
Fedora Rawhide-20190424.n.0 compose check report
Missing expected images: Atomichost qcow2 x86_64 Atomichost raw-xz x86_64 Compose FAILS proposed Rawhide gating check! 1 of 47 required tests failed openQA tests matching unsatisfied gating requirements shown with **GATING** below Failed openQA tests: 8/146 (x86_64), 3/24 (i386), 1/2 (arm) ID: 390370 Test: x86_64 Server-dvd-iso modularity_tests URL: https://openqa.fedoraproject.org/tests/390370 ID: 390399 Test: x86_64 Workstation-live-iso apps_startstop URL: https://openqa.fedoraproject.org/tests/390399 ID: 390402 Test: x86_64 Workstation-boot-iso memory_check@uefi URL: https://openqa.fedoraproject.org/tests/390402 ID: 390403 Test: x86_64 Workstation-boot-iso install_default@uefi **GATING** URL: https://openqa.fedoraproject.org/tests/390403 ID: 390405 Test: i386 Workstation-boot-iso install_default URL: https://openqa.fedoraproject.org/tests/390405 ID: 390406 Test: i386 Workstation-boot-iso memory_check URL: https://openqa.fedoraproject.org/tests/390406 ID: 390419 Test: x86_64 KDE-live-iso apps_startstop URL: https://openqa.fedoraproject.org/tests/390419 ID: 390422 Test: arm Minimal-raw_xz-raw.xz install_arm_image_deployment_upload URL: https://openqa.fedoraproject.org/tests/390422 ID: 390425 Test: x86_64 Silverblue-dvd_ostree-iso install_no_user URL: https://openqa.fedoraproject.org/tests/390425 ID: 390482 Test: x86_64 universal install_arabic_language URL: https://openqa.fedoraproject.org/tests/390482 ID: 390494 Test: x86_64 universal install_asian_language URL: https://openqa.fedoraproject.org/tests/390494 ID: 390519 Test: i386 universal install_package_set_kde URL: https://openqa.fedoraproject.org/tests/390519 Soft failed openQA tests: 9/146 (x86_64), 2/24 (i386) (Tests completed, but using a workaround for a known bug) ID: 390381 Test: x86_64 Server-dvd-iso server_freeipa_replication_client URL: https://openqa.fedoraproject.org/tests/390381 ID: 390382 Test: i386 Server-boot-iso install_default URL: https://openqa.fedoraproject.org/tests/390382 ID: 390383 Test: i386 Server-dvd-iso install_default URL: https://openqa.fedoraproject.org/tests/390383 ID: 390392 Test: x86_64 Workstation-live-iso desktop_update_graphical URL: https://openqa.fedoraproject.org/tests/390392 ID: 390401 Test: x86_64 Workstation-boot-iso memory_check URL: https://openqa.fedoraproject.org/tests/390401 ID: 390442 Test: x86_64 universal upgrade_minimal_64bit URL: https://openqa.fedoraproject.org/tests/390442 ID: 390444 Test: x86_64 universal upgrade_server_64bit URL: https://openqa.fedoraproject.org/tests/390444 ID: 390445 Test: x86_64 universal upgrade_server_domain_controller URL: https://openqa.fedoraproject.org/tests/390445 ID: 390446 Test: x86_64 universal upgrade_realmd_client URL: https://openqa.fedoraproject.org/tests/390446 ID: 390481 Test: x86_64 universal upgrade_2_server_64bit URL: https://openqa.fedoraproject.org/tests/390481 ID: 390502 Test: x86_64 universal upgrade_2_minimal_64bit URL: https://openqa.fedoraproject.org/tests/390502 Passed openQA tests: 129/146 (x86_64), 19/24 (i386) Skipped non-gating openQA tests: 1 of 172 -- 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://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 31 System-Wide Change proposal: Set skip_if_unavailable default to false
On Wed, Apr 24, 2019 at 7:04 PM Zbigniew Jędrzejewski-Szmek wrote: > > == Detailed Description == > > > > Dnf team wants to change a default setting for the repo option > > `skip_if_unavailable` to `FALSE`. The option is responsible for > > behavior when metadata of a repository is unavailable. When it is set > > to false, it will stop on the first unavailable repository with > > raising an error. The default behavior could be overwritten by a > > configuration of each repository or in dnf by configuration in > > /etc/dnf/dnf.conf. > > > > The behavior is not new, because it was used already by YUM, and the > > behavior is really essential because all Fedora ropos are already > > shipped with `skip_if_unavailable=FALSE`. > > Do I understand correctly that this is the global default, and > the setting in each repo file overrides the setting for that repo? > Most repos contain either skip_if_unavailable=False or > skip_if_unavailable=True and they will not be affected by this? > That was my understanding, yes. If it is set in the repo file, that will override the default. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
[EPEL-devel] Fedora EPEL 6 updates-testing report
The following Fedora EPEL 6 Security updates need testing: Age URL 54 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-06b243cced guacamole-server-1.0.0-1.el6 34 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-62f9745b71 drupal7-7.65-1.el6 11 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-9f732040bd python3-jinja2-2.8.1-2.el6 2 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-bd4638e5a3 libmediainfo-18.12-3.el6 1 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-009f5f140b php-horde-horde-5.2.21-1.el6 1 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-b9ea566899 php-horde-turba-4.2.24-1.el6 1 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-e406623fec bird-1.6.6-1.el6 The following builds have been pushed to Fedora EPEL 6 updates-testing php-theseer-autoload-1.25.4-2.el6 Details about builds: php-theseer-autoload-1.25.4-2.el6 (FEDORA-EPEL-2019-b5a3aad8ee) A tool and library to generate autoload code Update Information: ** Release 1.25.4** * Ensure include/exclude filter gets applied also in composer.json mode when files are explicitly set * Ensure files do not get processed multiple times in case composer.json has duplicate definitions in autoload section ChangeLog: * Wed Apr 24 2019 Remi Collet - 1.25.4-2 - add patch for PHP 5.3 from https://github.com/theseer/Autoload/pull/86 * Fri Apr 19 2019 Remi Collet - 1.25.4-1 - update to 1.25.4 ___ 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://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org
[Test-Announce] Fedora 30 Candidate RC-1.1 Available Now!
According to the schedule [1], Fedora 30 Candidate RC-1.1 is now available for testing. Please help us complete all the validation testing! For more information on release validation testing, see: https://fedoraproject.org/wiki/QA:Release_validation_test_plan Test coverage information for the current release can be seen at: https://www.happyassassin.net/testcase_stats/30 You can see all results, find testing instructions and image download locations, and enter results on the Summary page: https://fedoraproject.org/wiki/Test_Results:Fedora_30_RC_1.1_Summary The individual test result pages are: https://fedoraproject.org/wiki/Test_Results:Fedora_30_RC_1.1_Installation https://fedoraproject.org/wiki/Test_Results:Fedora_30_RC_1.1_Base https://fedoraproject.org/wiki/Test_Results:Fedora_30_RC_1.1_Server https://fedoraproject.org/wiki/Test_Results:Fedora_30_RC_1.1_Cloud https://fedoraproject.org/wiki/Test_Results:Fedora_30_RC_1.1_Desktop https://fedoraproject.org/wiki/Test_Results:Fedora_30_RC_1.1_Security_Lab All RC priority test cases for each of these test pages [2] must pass in order to meet the RC Release Criteria [3]. Help is available on #fedora-qa on irc.freenode.net [4], or on the test list [5]. Current Blocker and Freeze Exception bugs: http://qa.fedoraproject.org/blockerbugs/current [1] http://fedorapeople.org/groups/schedule/f-30/f-30-quality-tasks.html [2] https://fedoraproject.org/wiki/QA:Release_validation_test_plan [3] https://fedoraproject.org/wiki/Fedora_30_RC_Release_Criteria [4] irc://irc.freenode.net/fedora-qa [5] https://lists.fedoraproject.org/archives/list/t...@lists.fedoraproject.org/ ___ 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://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/test-annou...@lists.fedoraproject.org ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
[Bug 1702366] perl-Storable-3.15 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1702366 --- Comment #6 from Fedora Update System --- perl-Storable-3.15-1.fc28 has been pushed to the Fedora 28 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2019-4b8dd26bb6 -- You are receiving this mail because: You are on the CC list for the bug. ___ 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://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
Fedora rawhide compose report: 20190424.n.0 changes
OLD: Fedora-Rawhide-20190422.n.0 NEW: Fedora-Rawhide-20190424.n.0 = SUMMARY = Added images:3 Dropped images: 4 Added packages: 26 Dropped packages:7 Upgraded packages: 185 Downgraded packages: 0 Size of added packages: 147.83 MiB Size of dropped packages:74.06 MiB Size of upgraded packages: 9.27 GiB Size of downgraded packages: 0 B Size change of upgraded packages: -3.46 GiB Size change of downgraded packages: 0 B = ADDED IMAGES = Image: Cinnamon live i386 Path: Spins/i386/iso/Fedora-Cinnamon-Live-i386-Rawhide-20190424.n.0.iso Image: KDE raw-xz armhfp Path: Spins/armhfp/images/Fedora-KDE-armhfp-Rawhide-20190424.n.0-sda.raw.xz Image: Silverblue dvd-ostree x86_64 Path: Silverblue/x86_64/iso/Fedora-Silverblue-ostree-x86_64-Rawhide-20190424.n.0.iso = DROPPED IMAGES = Image: Games live x86_64 Path: Labs/x86_64/iso/Fedora-Games-Live-x86_64-Rawhide-20190422.n.0.iso Image: Minimal raw-xz aarch64 Path: Spins/aarch64/images/Fedora-Minimal-Rawhide-20190422.n.0.aarch64.raw.xz Image: Server dvd s390x Path: Server/s390x/iso/Fedora-Server-dvd-s390x-Rawhide-20190422.n.0.iso Image: Mate raw-xz armhfp Path: Spins/armhfp/images/Fedora-Mate-armhfp-Rawhide-20190422.n.0-sda.raw.xz = ADDED PACKAGES = Package: biboumi-8.3-2.fc31 Summary: An XMPP gateway that connects to IRC servers RPMs:biboumi Size:2.27 MiB Package: c-ares-1.15.0-3.module_f31+3989+7dd527f9 Summary: A library that performs asynchronous DNS operations RPMs:c-ares c-ares-devel Size:1.06 MiB Package: cockpit-podman-1-2.fc31 Summary: Cockpit component for Podman containers RPMs:cockpit-podman Size:1.22 MiB Package: cog-0.3.0-1.fc31 Summary: A small single ???window??? launcher for the WebKit WPE port RPMs:cog cog-devel Size:408.45 KiB Package: corsix-th-0.63-0.4.beta1.fc31 Summary: Open source clone of Theme Hospital RPMs:corsix-th corsix-th-data Size:3.06 MiB Package: golang-github-decker502-dnspod-0.2.0-1.fc31 Summary: Go client for the DNSPod API RPMs:golang-github-decker502-dnspod-devel Size:15.96 KiB Package: golang-github-dnsimple-0.23.0-1.fc31 Summary: Go client for the DNSimple API v2 RPMs:golang-github-dnsimple-devel Size:55.70 KiB Package: golang-github-oracle-oci-sdk-5.4.0-1.fc31 Summary: Go SDK for Oracle Cloud Infrastructure RPMs:golang-github-oracle-oci-sdk-devel Size:661.48 KiB Package: ibsim-0.8-1.fc31 Summary: InfiniBand fabric simulator for management RPMs:ibsim Size:316.77 KiB Package: kiwix-tools-1.2.1-1.fc31 Summary: Common code base for all Kiwix ports RPMs:kiwix-tools Size:1.49 MiB Package: libsquish-1.15-2.fc31 Summary: Open source DXT compression library RPMs:libsquish libsquish-devel Size:237.47 KiB Package: mozilla-iot-gateway-0.7.0-2.fc31 Summary: Mozilla's Web of Things gateway RPMs:mozilla-iot-gateway Size:53.68 MiB Package: mythes-eo-0.20180330-2.fc31 Summary: Esperanto thesaurus RPMs:hyphen-eo mythes-eo Size:139.48 KiB Package: nghttp2-1.38.0-1.module_f31+3989+7dd527f9 Summary: Experimental HTTP/2 client, server and proxy RPMs:libnghttp2 libnghttp2-devel nghttp2 Size:4.18 MiB Package: nodejs-1:12.0.0-2.module_f31+3989+7dd527f9 Summary: JavaScript runtime RPMs:nodejs nodejs-devel nodejs-docs nodejs-libs npm v8-devel Size:71.05 MiB Package: python-django-markdownx-2.0.28-1.fc31 Summary: A comprehensive Markdown editor built for Django RPMs:python3-django-markdownx Size:53.62 KiB Package: python-portend-2.3-1.fc31 Summary: TCP port monitoring utilities RPMs:python3-portend Size:14.93 KiB Package: python-pycotap-1.1.0-1.fc31 Summary: A tiny test runner that outputs TAP results to standard output RPMs:python3-pycotap Size:12.75 KiB Package: reuse-0.3.4-1.fc31 Summary: A tool for compliance with the REUSE Initiative recommendations RPMs:reuse Size:61.84 KiB Package: rust-atomicwrites-0.2.2-2.fc31 Summary: Atomic file-writes RPMs:rust-atomicwrites+default-devel rust-atomicwrites-devel Size:21.58 KiB Package: rust-fd-find-7.2.0-2.module_f31+3985+5f831d54 Summary: Simple, fast and user-friendly alternative to find RPMs:fd-find Size:4.39 MiB Package: rust-fuzzy-matcher-0.2.1-2.fc31 Summary: Fuzzy Matching Library RPMs:rust-fuzzy-matcher+default-devel rust-fuzzy-matcher-devel Size:23.82 KiB Package: rust-sd-0.5.0-1.fc31 Summary: An intuitive find & replace CLI RPMs:sd Size:3.38 MiB Package: rust-timer-0.2.0-2.fc31 Summary: Simple timer to schedule execution of closures RPMs:rust-timer+default-devel rust-timer-devel Size:27.40 KiB Package: rust-unescape-0.1.0-2.fc31 Summary: Unescapes strings with escape sequences written out as literal characters RPMs:rust-unescape+default-devel rust-unescape-devel Size:18.07 KiB Package: rust-utf8parse-0.1.1-2.fc31 Summary: Table-driven UTF-8 parser RPMs:rust-utf8parse+default-devel rust-utf8parse-devel
Re: Fedora 31 System-Wide Change proposal: Set skip_if_unavailable default to false
On Wed, Apr 24, 2019 at 05:04:41PM -0400, Ben Cotton wrote: > https://fedoraproject.org/wiki/Changes/Set_skip_if_unavailable_default_to_false > > == Summary == > Dnf team wants to change a default setting for the repo option > `skip_if_unavailable` to `FALSE`. > > == Owner == > * Name: [[User:jmracek| Jaroslav Mracek]] > * Email: jmra...@redhat.com > > == Detailed Description == > > Dnf team wants to change a default setting for the repo option > `skip_if_unavailable` to `FALSE`. The option is responsible for > behavior when metadata of a repository is unavailable. When it is set > to false, it will stop on the first unavailable repository with > raising an error. The default behavior could be overwritten by a > configuration of each repository or in dnf by configuration in > /etc/dnf/dnf.conf. > > The behavior is not new, because it was used already by YUM, and the > behavior is really essential because all Fedora ropos are already > shipped with `skip_if_unavailable=FALSE`. Do I understand correctly that this is the global default, and the setting in each repo file overrides the setting for that repo? Most repos contain either skip_if_unavailable=False or skip_if_unavailable=True and they will not be affected by this? Zbyszek > The change will be applied in libdnf library, and the changed behavior > will be visible for all direct and indirect users of the library: dnf, > microdnf, PackageKit, ... . > > == Benefit to Fedora == > > It should provide a better security because some Important updates > from third-party repositories could be present in temporary > unavailable repository, but user can easily overlook it during `dnf > update` because the issue is reported as a warning. > > == Scope == > * Proposal owners: > ** Backport the following upstream pull requests into the DNF stack on > Fedora: https://github.com/rpm-software-management/libdnf/pull/701 > * Other developers: N/A > * Release engineering: [https://pagure.io/releng/issue/8307 #8307] > * Policies and guidelines: N/A > * Trademark approval: not needed for this Change > > == How To Test == > Edit .repo file in /etc/yum.repos.d/* and set an url that is not accessible. > > Case 1: > No skip_if_unavailable in the repo file, in /etc/dnf/dnf.conf or > overwritten from commandline using `--setopt`. > Any command that requires available repositories like `dnf repoquery` > will fail due to an error `Error: Failed to synchronize cache for repo > ''` > > Case 2: > Set skip_if_unavailable=true in the repo file. > Any command that requires available repositories like `dnf repoquery` > will not fail due to missing metadata of the `` > > == User Experience == > > Broken repositories are recognized early, enabling the users to act > upon them by double-checking their repository configuration or filing > bugs, instead of assuming no upgrades are available. > > > == Dependencies == > Depend packages - dnf, microdnf, PackageKit > > There are no changes on which completion of this change depends. > > == Contingency Plan == > * Contingency mechanism: (What to do? Who will do it?) > The change requires a merge and a release of the pull-request > https://github.com/rpm-software-management/libdnf/pull/701 > > * Contingency deadline: Should be delivered before 2019-07-24. > * Blocks release? No > * Blocks product? No > > == Documentation == > https://dnf.readthedocs.io/en/latest/conf_ref.html > > Update for documentation: > https://github.com/rpm-software-management/dnf/pull/1358 > > -- > Ben Cotton > Fedora Program Manager > TZ=America/Indiana/Indianapolis > Pronouns: he/him > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
[Bug 1699250] perl-Test2-Suite-0.000111-1.fc28 FTBFS: Failed test 'sanitize' at t/modules/Util/Table.t line 277
https://bugzilla.redhat.com/show_bug.cgi?id=1699250 Fedora Update System changed: What|Removed |Added Status|ON_QA |CLOSED Fixed In Version||perl-Test2-Suite-0.000111-2 ||.fc28 Resolution|--- |ERRATA Last Closed||2019-04-24 22:58:30 --- Comment #4 from Fedora Update System --- perl-Test2-Suite-0.000111-2.fc28 has been pushed to the Fedora 28 stable repository. If problems still persist, please make note of it in this bug report. -- You are receiving this mail because: You are on the CC list for the bug. ___ 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://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
[Bug 1698173] perl-Sereal-Decoder-4.007 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1698173 Fedora Update System changed: What|Removed |Added Fixed In Version|perl-Sereal-Decoder-4.007-1 |perl-Sereal-Decoder-4.007-1 |.fc31 |.fc31 |perl-Sereal-Decoder-4.007-1 |perl-Sereal-Decoder-4.007-1 |.fc30 |.fc30 ||perl-Sereal-Decoder-4.007-1 ||.fc28 --- Comment #9 from Fedora Update System --- perl-Sereal-Decoder-4.007-1.fc28 has been pushed to the Fedora 28 stable repository. If problems still persist, please make note of it in this bug report. -- You are receiving this mail because: You are on the CC list for the bug. ___ 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://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
[Bug 1698174] perl-Sereal-Encoder-4.007 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1698174 Fedora Update System changed: What|Removed |Added Fixed In Version|perl-Sereal-Encoder-4.007-1 |perl-Sereal-Encoder-4.007-1 |.fc31 |.fc31 |perl-Sereal-Encoder-4.007-1 |perl-Sereal-Encoder-4.007-1 |.fc30 |.fc30 ||perl-Sereal-Encoder-4.007-1 ||.fc28 --- Comment #9 from Fedora Update System --- perl-Sereal-Encoder-4.007-1.fc28 has been pushed to the Fedora 28 stable repository. If problems still persist, please make note of it in this bug report. -- You are receiving this mail because: You are on the CC list for the bug. ___ 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://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
[Bug 1697635] perl-Sereal-Encoder-4.006 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1697635 Fedora Update System changed: What|Removed |Added Fixed In Version|perl-Sereal-Encoder-4.006-1 |perl-Sereal-Encoder-4.006-1 |.fc31 |.fc31 |perl-Sereal-Encoder-4.007-1 |perl-Sereal-Encoder-4.007-1 |.fc30 |.fc30 ||perl-Sereal-Encoder-4.007-1 ||.fc28 --- Comment #13 from Fedora Update System --- perl-Sereal-Encoder-4.007-1.fc28 has been pushed to the Fedora 28 stable repository. If problems still persist, please make note of it in this bug report. -- You are receiving this mail because: You are on the CC list for the bug. ___ 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://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
[Bug 1697634] perl-Sereal-Decoder-4.006 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1697634 Fedora Update System changed: What|Removed |Added Fixed In Version|perl-Sereal-Decoder-4.006-1 |perl-Sereal-Decoder-4.006-1 |.fc31 |.fc31 |perl-Sereal-Decoder-4.007-1 |perl-Sereal-Decoder-4.007-1 |.fc30 |.fc30 ||perl-Sereal-Decoder-4.007-1 ||.fc28 --- Comment #11 from Fedora Update System --- perl-Sereal-Decoder-4.007-1.fc28 has been pushed to the Fedora 28 stable repository. If problems still persist, please make note of it in this bug report. -- You are receiving this mail because: You are on the CC list for the bug. ___ 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://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
Fedora 32 System-Wide Change proposal: Retire Python 2
https://fedoraproject.org/wiki/Changes/RetirePython2
== Summary ==
The {{package|python2}} package and all its subpackages will be
removed from Fedora 32.
A legacy {{package|python27}} package for developers and users will
be provided.
All packages in Fedora that need Python 2 to run will be removed from
Fedora 32 regardless of their dependencies.
All packages in Fedora that need Python 2 to build will be removed
from Fedora 32 regardless of their dependencies.
Exceptions can be granted by FESCo.
== Owner ==
* Name: [[User:Churchyard|Miro Hrončok]]
* Email:
== Detailed Description ==
Python 2 is unsupported upstream since 2020-01-01. Packages dependent
on Python 2 are being removed from Fedora for several releases
already:
* [[Changes/Mass_Python_2_Package_Removal|Fedora 30 Mass Python 2
Package Removal]]
* [[Changes/F31_Mass_Python_2_Package_Removal|Fedora 31 Mass Python 2
Package Removal]]
Now, the Python maintainers have decided to pull the plug. The
{{package|python2}} package and all its subpackages will be retired
(read: removed) from Fedora 32 (Rawhide) as soon as Fedora 31 is
branched.
All packages depending on any python2 package will be removed. The
removal starts 2 weeks before the planned Fedora 32 Mass Rebuild.
Broken dependencies will not stop the removals.
Packages that Fail to Build From Source and prevent to remove Python 2
subpackages may end up with broken dependencies,
in cases where it is not desired, those packages will be retired instead.
The rules also apply to modules built for Fedora 32+.
The package removal will be executed in an automated fashion.
Removed packages that would block the upgrades to Fedora 32 will be
obsoleted from {{package|fedora-obsolete-packages}}.
=== The python27 package ===
Similarly to existing {{package|python36}}, {{package|python37}} etc.
packages, a {{package|python27}} package will be created.
This package is indented for Python developers who still need to
support the legacy version of Python.
This package is indented for users, who still need to use some
software depending on the legacy version of Python.
This package is not intended for other Fedora packages to be depended upon.
The {{package|python27}} package has several drawbacks compared to the
original {{package|python2}} package:
* it is "flat" - there are no subpackages, everything lives in one package
* there is no debug build (previously available as {{package|python2-debug}})
* there is no /usr/bin/python (note: there might be
already the case before this change)
* any special backwards compatible Provides are removed (this package
is not intended to be depended upon)
=== FESCo exceptions ===
We realize that there are some packages whose removal could seriously
hurt Fedora. FESCo can grant exceptions for packages to use the
{{package|python27}} as a runtime or build dependency.
The package maintainer is responsible to check the entire dependency
chain and they need to request exceptions for the entire list of
packages. For example, when seeking exception for the
{{package|chromium}} package, the request should contain
{{package|python-psutil}} and other dependent packages. (Yes, this is
tedious. Maintaining a Python 2 dependent package is a burden.)
The exception request must include a plan for migrating to Python 3.
Any non-essential dependency must be dropped. That includes optional
dependencies, test dependencies, optional subpackages etc.
Package that fail to get an exception when the removal starts (see
above) will be removed. Their importance for Fedora Release
Engineering, Fedora Infrastructure or any other body will not be
automagically respected; every package that needs Python 2 needs an
exception.
The change owners will send regular reminders to the package owners.
== Benefit to Fedora ==
Python 2 is past upstream End of Life since 2020-01-01. This changes
is generally crafted in a way that:
* it leaves Python developers an option to use it in case they still
need to support it
* it leaves Fedora users an option to use it in case they still need
it to run their (3rd party) software
* it leaves Fedora packagers an option to keep using it (complicated,
but possible)
While:
* it removes Python 2 software from Fedora that was only preserved so
far by inaction
Using Python 2 is dangerous. While the Fedora Python maintainers will
try to fix as many security bugs as possible, without the upstream
involvement this will be hard.
Python 2 is deprecated since Fedora 30. This change moves Python 2
from second class citizen to third class citizen.
== Scope ==
* Proposal owners:
** retire {{package|python2}}
** introduce {{package|python27}}
** remove all {{package|python2}} dependent packages that do not have
FESCo exceptions
** obsolete removed packages that break the upgrade path via
{{package|fedora-obsolete-packages}}
* Other developers:
** remove their {{package|python2}} dependent packages without exceptions
** get exceptions if needed
** fix broken
Fedora 31 System-Wide Change proposal: Set skip_if_unavailable default to false
https://fedoraproject.org/wiki/Changes/Set_skip_if_unavailable_default_to_false == Summary == Dnf team wants to change a default setting for the repo option `skip_if_unavailable` to `FALSE`. == Owner == * Name: [[User:jmracek| Jaroslav Mracek]] * Email: jmra...@redhat.com == Detailed Description == Dnf team wants to change a default setting for the repo option `skip_if_unavailable` to `FALSE`. The option is responsible for behavior when metadata of a repository is unavailable. When it is set to false, it will stop on the first unavailable repository with raising an error. The default behavior could be overwritten by a configuration of each repository or in dnf by configuration in /etc/dnf/dnf.conf. The behavior is not new, because it was used already by YUM, and the behavior is really essential because all Fedora ropos are already shipped with `skip_if_unavailable=FALSE`. The change will be applied in libdnf library, and the changed behavior will be visible for all direct and indirect users of the library: dnf, microdnf, PackageKit, ... . == Benefit to Fedora == It should provide a better security because some Important updates from third-party repositories could be present in temporary unavailable repository, but user can easily overlook it during `dnf update` because the issue is reported as a warning. == Scope == * Proposal owners: ** Backport the following upstream pull requests into the DNF stack on Fedora: https://github.com/rpm-software-management/libdnf/pull/701 * Other developers: N/A * Release engineering: [https://pagure.io/releng/issue/8307 #8307] * Policies and guidelines: N/A * Trademark approval: not needed for this Change == How To Test == Edit .repo file in /etc/yum.repos.d/* and set an url that is not accessible. Case 1: No skip_if_unavailable in the repo file, in /etc/dnf/dnf.conf or overwritten from commandline using `--setopt`. Any command that requires available repositories like `dnf repoquery` will fail due to an error `Error: Failed to synchronize cache for repo ''` Case 2: Set skip_if_unavailable=true in the repo file. Any command that requires available repositories like `dnf repoquery` will not fail due to missing metadata of the `` == User Experience == Broken repositories are recognized early, enabling the users to act upon them by double-checking their repository configuration or filing bugs, instead of assuming no upgrades are available. == Dependencies == Depend packages - dnf, microdnf, PackageKit There are no changes on which completion of this change depends. == Contingency Plan == * Contingency mechanism: (What to do? Who will do it?) The change requires a merge and a release of the pull-request https://github.com/rpm-software-management/libdnf/pull/701 * Contingency deadline: Should be delivered before 2019-07-24. * Blocks release? No * Blocks product? No == Documentation == https://dnf.readthedocs.io/en/latest/conf_ref.html Update for documentation: https://github.com/rpm-software-management/dnf/pull/1358 -- Ben Cotton Fedora Program Manager TZ=America/Indiana/Indianapolis Pronouns: he/him ___ 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://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel-announce@lists.fedoraproject.org
Fedora 31 System-Wide Change proposal: Set skip_if_unavailable default to false
https://fedoraproject.org/wiki/Changes/Set_skip_if_unavailable_default_to_false == Summary == Dnf team wants to change a default setting for the repo option `skip_if_unavailable` to `FALSE`. == Owner == * Name: [[User:jmracek| Jaroslav Mracek]] * Email: jmra...@redhat.com == Detailed Description == Dnf team wants to change a default setting for the repo option `skip_if_unavailable` to `FALSE`. The option is responsible for behavior when metadata of a repository is unavailable. When it is set to false, it will stop on the first unavailable repository with raising an error. The default behavior could be overwritten by a configuration of each repository or in dnf by configuration in /etc/dnf/dnf.conf. The behavior is not new, because it was used already by YUM, and the behavior is really essential because all Fedora ropos are already shipped with `skip_if_unavailable=FALSE`. The change will be applied in libdnf library, and the changed behavior will be visible for all direct and indirect users of the library: dnf, microdnf, PackageKit, ... . == Benefit to Fedora == It should provide a better security because some Important updates from third-party repositories could be present in temporary unavailable repository, but user can easily overlook it during `dnf update` because the issue is reported as a warning. == Scope == * Proposal owners: ** Backport the following upstream pull requests into the DNF stack on Fedora: https://github.com/rpm-software-management/libdnf/pull/701 * Other developers: N/A * Release engineering: [https://pagure.io/releng/issue/8307 #8307] * Policies and guidelines: N/A * Trademark approval: not needed for this Change == How To Test == Edit .repo file in /etc/yum.repos.d/* and set an url that is not accessible. Case 1: No skip_if_unavailable in the repo file, in /etc/dnf/dnf.conf or overwritten from commandline using `--setopt`. Any command that requires available repositories like `dnf repoquery` will fail due to an error `Error: Failed to synchronize cache for repo ''` Case 2: Set skip_if_unavailable=true in the repo file. Any command that requires available repositories like `dnf repoquery` will not fail due to missing metadata of the `` == User Experience == Broken repositories are recognized early, enabling the users to act upon them by double-checking their repository configuration or filing bugs, instead of assuming no upgrades are available. == Dependencies == Depend packages - dnf, microdnf, PackageKit There are no changes on which completion of this change depends. == Contingency Plan == * Contingency mechanism: (What to do? Who will do it?) The change requires a merge and a release of the pull-request https://github.com/rpm-software-management/libdnf/pull/701 * Contingency deadline: Should be delivered before 2019-07-24. * Blocks release? No * Blocks product? No == Documentation == https://dnf.readthedocs.io/en/latest/conf_ref.html Update for documentation: https://github.com/rpm-software-management/dnf/pull/1358 -- Ben Cotton Fedora Program Manager TZ=America/Indiana/Indianapolis Pronouns: he/him ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Fedora 32 System-Wide Change proposal: Retire Python 2
https://fedoraproject.org/wiki/Changes/RetirePython2
== Summary ==
The {{package|python2}} package and all its subpackages will be
removed from Fedora 32.
A legacy {{package|python27}} package for developers and users will
be provided.
All packages in Fedora that need Python 2 to run will be removed from
Fedora 32 regardless of their dependencies.
All packages in Fedora that need Python 2 to build will be removed
from Fedora 32 regardless of their dependencies.
Exceptions can be granted by FESCo.
== Owner ==
* Name: [[User:Churchyard|Miro Hrončok]]
* Email:
== Detailed Description ==
Python 2 is unsupported upstream since 2020-01-01. Packages dependent
on Python 2 are being removed from Fedora for several releases
already:
* [[Changes/Mass_Python_2_Package_Removal|Fedora 30 Mass Python 2
Package Removal]]
* [[Changes/F31_Mass_Python_2_Package_Removal|Fedora 31 Mass Python 2
Package Removal]]
Now, the Python maintainers have decided to pull the plug. The
{{package|python2}} package and all its subpackages will be retired
(read: removed) from Fedora 32 (Rawhide) as soon as Fedora 31 is
branched.
All packages depending on any python2 package will be removed. The
removal starts 2 weeks before the planned Fedora 32 Mass Rebuild.
Broken dependencies will not stop the removals.
Packages that Fail to Build From Source and prevent to remove Python 2
subpackages may end up with broken dependencies,
in cases where it is not desired, those packages will be retired instead.
The rules also apply to modules built for Fedora 32+.
The package removal will be executed in an automated fashion.
Removed packages that would block the upgrades to Fedora 32 will be
obsoleted from {{package|fedora-obsolete-packages}}.
=== The python27 package ===
Similarly to existing {{package|python36}}, {{package|python37}} etc.
packages, a {{package|python27}} package will be created.
This package is indented for Python developers who still need to
support the legacy version of Python.
This package is indented for users, who still need to use some
software depending on the legacy version of Python.
This package is not intended for other Fedora packages to be depended upon.
The {{package|python27}} package has several drawbacks compared to the
original {{package|python2}} package:
* it is "flat" - there are no subpackages, everything lives in one package
* there is no debug build (previously available as {{package|python2-debug}})
* there is no /usr/bin/python (note: there might be
already the case before this change)
* any special backwards compatible Provides are removed (this package
is not intended to be depended upon)
=== FESCo exceptions ===
We realize that there are some packages whose removal could seriously
hurt Fedora. FESCo can grant exceptions for packages to use the
{{package|python27}} as a runtime or build dependency.
The package maintainer is responsible to check the entire dependency
chain and they need to request exceptions for the entire list of
packages. For example, when seeking exception for the
{{package|chromium}} package, the request should contain
{{package|python-psutil}} and other dependent packages. (Yes, this is
tedious. Maintaining a Python 2 dependent package is a burden.)
The exception request must include a plan for migrating to Python 3.
Any non-essential dependency must be dropped. That includes optional
dependencies, test dependencies, optional subpackages etc.
Package that fail to get an exception when the removal starts (see
above) will be removed. Their importance for Fedora Release
Engineering, Fedora Infrastructure or any other body will not be
automagically respected; every package that needs Python 2 needs an
exception.
The change owners will send regular reminders to the package owners.
== Benefit to Fedora ==
Python 2 is past upstream End of Life since 2020-01-01. This changes
is generally crafted in a way that:
* it leaves Python developers an option to use it in case they still
need to support it
* it leaves Fedora users an option to use it in case they still need
it to run their (3rd party) software
* it leaves Fedora packagers an option to keep using it (complicated,
but possible)
While:
* it removes Python 2 software from Fedora that was only preserved so
far by inaction
Using Python 2 is dangerous. While the Fedora Python maintainers will
try to fix as many security bugs as possible, without the upstream
involvement this will be hard.
Python 2 is deprecated since Fedora 30. This change moves Python 2
from second class citizen to third class citizen.
== Scope ==
* Proposal owners:
** retire {{package|python2}}
** introduce {{package|python27}}
** remove all {{package|python2}} dependent packages that do not have
FESCo exceptions
** obsolete removed packages that break the upgrade path via
{{package|fedora-obsolete-packages}}
* Other developers:
** remove their {{package|python2}} dependent packages without exceptions
** get exceptions if needed
** fix broken
Re: Looking for comaintainers for AV1 related stuff
On Wed, Apr 24, 2019 at 4:36 PM Robert-André Mauchin wrote: > > On Wednesday, 24 April 2019 22:18:56 CEST Igor Gnatenko wrote: > > Count me in! :) > > > > I've added you to these 3 projects. Thanks for your support! > If you still want comaintainers, I'm happy to help. -- 真実はいつも一つ！/ 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://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: grub2-editenv: error: environment block too small after kernel install
I ended up just deleting my grubenv and creating a new one and then did an update that included a new kernel. No errors. The only diference I can spot is perhaps on line endings? I "cat"ed both files and the one I modified had a newline (shell prompt started on a new line) and with the newly created one the shell prompt ended up on the back end of the padded line. Thanks, Richard ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Schedule for Friday's FESCo Meeting (2019-04-26)
On Wed, 2019-04-24 at 16:13 -0400, Randy Barlow wrote: > Following is the list of topics that will be discussed in the > FESCo meeting Friday at 15:00UTC in #fedora-meeting-1 on > irc.freenode.net. Correction, the meeting will be in #fedora-meeting. 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://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Looking for comaintainers for AV1 related stuff
On Wednesday, 24 April 2019 22:18:56 CEST Igor Gnatenko wrote: > Count me in! :) > I've added you to these 3 projects. Thanks for your support! > > > > I have packaged almost all project related to AV1: > > - aom: https://src.fedoraproject.org/rpms/aom > > - dav1d: https://src.fedoraproject.org/rpms/dav1d > > - go-avif: https://src.fedoraproject.org/rpms/go-avif ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
[Bug 1702366] perl-Storable-3.15 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1702366 Fedora Update System changed: What|Removed |Added Status|MODIFIED|ON_QA --- Comment #5 from Fedora Update System --- perl-Storable-3.15-1.fc30 has been pushed to the Fedora 30 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2019-ef2ca6df10 -- You are receiving this mail because: You are on the CC list for the bug. ___ 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://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
Re: Looking for comaintainers for AV1 related stuff
Count me in! :) On Wed, Apr 24, 2019 at 7:09 PM Robert-André Mauchin wrote: > Hello, > > I'm very interested in AV1, the new royalty-free video codec developed by > Xiph, Google and others (https://aomedia.org/). > > I have packaged almost all project related to AV1: > - aom: https://src.fedoraproject.org/rpms/aom > - dav1d: https://src.fedoraproject.org/rpms/dav1d > - rav1e: Not packaged yet but all Rust deps are in > - go-avif: Repo will be created soon > > Maybe SVT-AV1 in the future: https://github.com/OpenVisualCloud/SVT-AV1 > > I'm looking for comaintainers on these projects who are equally motivated > by > AV1, so that if I'm unavailable, they will still be maintained in Fedora > in > the future. If that's you, great, send me a mail! > > Best regards, > > Robert-André > > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Orphaning js-jquery
On Wed, Apr 24, 2019 at 3:33 PM Christopher wrote: > > I'm orphaning js-jquery, since I do not have time to maintain it. > > It's getting harder to contribute to Fedora with all the mass > orphaning of dependencies, and I don't have time to figure it all out. > This is one that needs frequent attention, as jQuery is subject to > lots of vulnerabilities, and deserves much more attention than I've > been giving it. The orphaning of dependencies shouldn't be happening, but I (and others) are working hard to get a solution in place that will un the situation. I would have preferred not needing to do so under emergency conditions, but what is, is. FWIW, things should *not* be getting harder. Some folks just jumped the gun and made changes they weren't supposed to (yet) and now the Modularity team has a lot of fires to put out and very few resources with which to do it. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Schedule for Friday's FESCo Meeting (2019-04-26)
Following is the list of topics that will be discussed in the FESCo meeting Friday at 15:00UTC in #fedora-meeting-1 on irc.freenode.net. To convert UTC to your local time, take a look at http://fedoraproject.org/wiki/UTCHowto or run: date -d '2019-04-26 15:00 UTC' Links to all issues to be discussed can be found at: https://pagure.io/fesco/report/meeting_agenda = Discussed and Voted in the Ticket = changing meeting time? https://pagure.io/fesco/issue/2112 FESCo now meets on Fridays at 15:00 UTC Emergency vote: BZ #1688462 https://pagure.io/fesco/issue/2118 APPROVED (+9, 0, -0) = Followups = #topic #2088 F31 Change – “dnf --best” as default behavior .fesco 2088 https://pagure.io/fesco/issue/2088 #topic #2096 F31 System-Wide Change: BuildRequires generators .fesco 2096 https://pagure.io/fesco/issue/2096 = New business = #topic #2114 What is the scope of Modularity? .fesco 2114 https://pagure.io/fesco/issue/2114 #topic #2115 Missing PkgDB features should be implemented .fesco 2115 https://pagure.io/fesco/issue/2115 = Open Floor = For more complete details, please visit each individual issue. The report of the agenda items can be found at https://pagure.io/fesco/report/meeting_agenda If you would like to add something to this agenda, you can reply to this e-mail, file a new issue at https://pagure.io/fesco, e-mail me directly, or bring it up at the end of the meeting, during the open floor topic. Note that added topics may be deferred until the following meeting. 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://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Orphaning js-jquery
I'm orphaning js-jquery, since I do not have time to maintain it. It's getting harder to contribute to Fedora with all the mass orphaning of dependencies, and I don't have time to figure it all out. This is one that needs frequent attention, as jQuery is subject to lots of vulnerabilities, and deserves much more attention than I've been giving it. -- Christopher ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Understanding Fedora's use of systemd presets and packaging requirements
On Wed, 2019-04-24 at 12:11 -0700, Adam Williamson wrote: > On Mon, 2019-04-22 at 10:49 -0700, Samuel Sieb wrote: > > On 4/22/19 9:25 AM, Adam Williamson wrote: > > > AIUI, the design is that any package that *ships a preset* should run > > > systemctl preset on it in its scriptlets (there should be guidelines > > > for this somewhere but I can't find them right now). However, there's a > > > loophole here in that if any package that ships a preset gets ordered > > > before systemd itself during install, its attempt to run 'systemctl > > > preset' will obviously fail. This is why we run 'preset-all' in the > > > systemd package scriptlets: to apply the presets for any packages which > > > were already installed. It's not intended that all other packages can > > > *rely* on the call in systemd's scripts. > > > > > > So, basically: if you're making a package that includes presets, run > > > 'systemctl preset' on the presets it ships in its scripts. Not 'preset- > > > all', but run it specifically per preset that you ship. > > > > Couldn't you run the preset script in a %posttrans block to ensure > > everything is installed? > > I mean, in theory, yeah. I don't know for sure if there's a reason why > this isn't done, or even if it's been specifically considered. ...though of course this would *solely* function as a sort of 'safety valve' for install system installation, because a package including a preset can always be installed *after initial system installation* and that situation still has to be handled, which a systemd %posttrans script obviously doesn't do. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Understanding Fedora's use of systemd presets and packaging requirements
On Mon, 2019-04-22 at 10:49 -0700, Samuel Sieb wrote: > On 4/22/19 9:25 AM, Adam Williamson wrote: > > AIUI, the design is that any package that *ships a preset* should run > > systemctl preset on it in its scriptlets (there should be guidelines > > for this somewhere but I can't find them right now). However, there's a > > loophole here in that if any package that ships a preset gets ordered > > before systemd itself during install, its attempt to run 'systemctl > > preset' will obviously fail. This is why we run 'preset-all' in the > > systemd package scriptlets: to apply the presets for any packages which > > were already installed. It's not intended that all other packages can > > *rely* on the call in systemd's scripts. > > > > So, basically: if you're making a package that includes presets, run > > 'systemctl preset' on the presets it ships in its scripts. Not 'preset- > > all', but run it specifically per preset that you ship. > > Couldn't you run the preset script in a %posttrans block to ensure > everything is installed? I mean, in theory, yeah. I don't know for sure if there's a reason why this isn't done, or even if it's been specifically considered. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Understanding Fedora's use of systemd presets and packaging requirements
On Mon, 2019-04-22 at 18:42 +, Zbigniew Jędrzejewski-Szmek wrote: > > > > AIUI, the design is that any package that *ships a preset* should run > > > systemctl preset on it in its scriptlets (there should be guidelines > > > for this somewhere but I can't find them right now). > > There's no explicitly stated rule, afaik, but scriptlets [1] document > %systemd_requires and scriptlets are part of the guidelines. > > [1] > https://docs.fedoraproject.org/en-US/packaging-guidelines/Scriptlets/#_scriptlets > > > > However, there's a > > > loophole here in that if any package that ships a preset gets ordered > > > before systemd itself during install, its attempt to run 'systemctl > > > preset' will obviously fail. This is why we run 'preset-all' in the > > > systemd package scriptlets: to apply the presets for any packages which > > > were already installed. It's not intended that all other packages can > > > *rely* on the call in systemd's scripts. > > > > BTW if you're wondering "why not just make sure everything that ships a > > preset gets installed after systemd"...sadly there are some awkward > > cases that make that not practical, basically 'systemd depends on > > something that installs a preset' or 'systemd depends on something that > > depends on something that installs a preset'. > > I think that the attempt to install all packages that provide services > after systemd is misguided / outdated. As you say, doing this > comprehensively isn't possible because of circular deps. Furthermore, > since you restored the call to preset-all, there is no point. The > effect is the same in either order. > > I want to open an FPC ticket to change the guidelines to not require > any dependency on systemd for packages that simply provide a service file. > Things are complicated by the fact that packages might require systemd > for different reasons, e.g. use some systemd helper in installation > scriptlets. So we can't simply drop the dependency and ordering on > systemd everywhere, but I think we could do it in many places. This > will remove some noise, shorten our spec files a bit, and give rpm > more freedom to order package installation according to requirements > (there will be less requirements, so less loops). > > I was planning to start the discussion on this after F30 is released, > but since we're already discussing this, I'll try to write up a proposal > for fedora-devel in the next few days. Sure, I don't think I see any problems with that. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Understanding Fedora's use of systemd presets and packaging requirements
On 4/22/19 12:25 PM, Adam Williamson wrote:
On Sat, 2019-04-20 at 07:59 +, Zbigniew Jędrzejewski-Szmek wrote:
On Fri, Apr 19, 2019 at 04:35:54PM -0400, John Florian wrote:
I'm generally familiar with how systemd presets work but I'm at a
bit of loss as to how part of all the magic works. To best explain
my confusion, let me say that I make a customized live spin of
Fedora and I have a package we'll call "my-dist" which is similar in
nature to the "fedora-release" package in that it provides a custom
preset file. I still use fedora-release because this spin is not
*that* customized, so it's best to think of this as an extension. I
have another package we'll call "my-service" which has a systemd
service unit file and all the usual %systemd_post, etc. macros.
When I boot my live spin I find that my-service is not enabled
despite the preset in my-dist. I can "systemctl preset-all" to
rectify this so I believe most requirements are correct. I do see
that livemedia-creator installs my-service *before* it installs
my-dist so if the %systemd_post is called as each rpm is installed
that would explain my problem because my custom preset isn't present
yet.
How does Fedora itself accomplish this??? I don't see every package
providing a service having a dependency on fedora-release to address
this ordering issue. I can certainly stick the "systemctl
preset-all" into the %post of my kickstart as final cleanup, but
that feels dirty and wrong. Similarly, I don't wish to have to have
a "Requires: my-dist" in every one of "my-service" and other
packages like it. I've scrutinized fedora-release.spec and didn't
see anything all that different than what I have in my-dist.
systemd.rpm does preset-all when it is installed, so it is enough
that systemd.rpm is installed after fedora-release-common.rpm.
fedora-release-common is required by setup.rpm, so it is installed
early. But you raise a good point — I don't see any *explicit*
ordering chain between fedora-release-common and systemd.
There is no need to order individual rpms against either
fedora-release-common and other packages providing presets or
systemd. The only thing that is necessary is for systemd.rpm to be
installed after all presets. If that is satisfied, packages proving
services can be installed both earlier and later and the effect
(in the sense of service enablement) should be identical.
AIUI, the design is that any package that *ships a preset* should run
systemctl preset on it in its scriptlets (there should be guidelines
for this somewhere but I can't find them right now). However, there's a
loophole here in that if any package that ships a preset gets ordered
before systemd itself during install, its attempt to run 'systemctl
preset' will obviously fail. This is why we run 'preset-all' in the
systemd package scriptlets: to apply the presets for any packages which
were already installed. It's not intended that all other packages can
*rely* on the call in systemd's scripts.
So, basically: if you're making a package that includes presets, run
'systemctl preset' on the presets it ships in its scripts. Not 'preset-
all', but run it specifically per preset that you ship.
Ahha! That was worded perfectly for me to recognize where I erred. All
the other comments were doing great things for my understanding, but
this put the spotlight just right. I have numerous services I use to
transform Fedora into a stateless appliance OS, but I went too far in
mimic what I saw from Fedora itself. Each of my packages that provides
a service do indeed use the wonderful systemd scriptlets, but all of my
presets ship in separate package ("my-dist" from above) that kind of
mimics fedora-release (and its
/usr/lib/systemd/system-preset/90-default.preset file). This my-dist
package doesn't use the scriptlets at all since I didn't see that in
fedora-release.spec. I went this route because I wanted to capture the
policy of each of my custom services all in one place, much like the
aforementioned file does for Fedora.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Understanding Fedora's use of systemd presets and packaging requirements
On 4/22/19 12:31 PM, Adam Williamson wrote: On Mon, 2019-04-22 at 09:25 -0700, Adam Williamson wrote: On Sat, 2019-04-20 at 07:59 +, Zbigniew Jędrzejewski-Szmek wrote: On Fri, Apr 19, 2019 at 04:35:54PM -0400, John Florian wrote: I'm generally familiar with how systemd presets work but I'm at a bit of loss as to how part of all the magic works. To best explain my confusion, let me say that I make a customized live spin of Fedora and I have a package we'll call "my-dist" which is similar in nature to the "fedora-release" package in that it provides a custom preset file. I still use fedora-release because this spin is not *that* customized, so it's best to think of this as an extension. I have another package we'll call "my-service" which has a systemd service unit file and all the usual %systemd_post, etc. macros. When I boot my live spin I find that my-service is not enabled despite the preset in my-dist. I can "systemctl preset-all" to rectify this so I believe most requirements are correct. I do see that livemedia-creator installs my-service *before* it installs my-dist so if the %systemd_post is called as each rpm is installed that would explain my problem because my custom preset isn't present yet. How does Fedora itself accomplish this??? I don't see every package providing a service having a dependency on fedora-release to address this ordering issue. I can certainly stick the "systemctl preset-all" into the %post of my kickstart as final cleanup, but that feels dirty and wrong. Similarly, I don't wish to have to have a "Requires: my-dist" in every one of "my-service" and other packages like it. I've scrutinized fedora-release.spec and didn't see anything all that different than what I have in my-dist. systemd.rpm does preset-all when it is installed, so it is enough that systemd.rpm is installed after fedora-release-common.rpm. fedora-release-common is required by setup.rpm, so it is installed early. But you raise a good point — I don't see any *explicit* ordering chain between fedora-release-common and systemd. There is no need to order individual rpms against either fedora-release-common and other packages providing presets or systemd. The only thing that is necessary is for systemd.rpm to be installed after all presets. If that is satisfied, packages proving services can be installed both earlier and later and the effect (in the sense of service enablement) should be identical. AIUI, the design is that any package that *ships a preset* should run systemctl preset on it in its scriptlets (there should be guidelines for this somewhere but I can't find them right now). However, there's a loophole here in that if any package that ships a preset gets ordered before systemd itself during install, its attempt to run 'systemctl preset' will obviously fail. This is why we run 'preset-all' in the systemd package scriptlets: to apply the presets for any packages which were already installed. It's not intended that all other packages can *rely* on the call in systemd's scripts. BTW if you're wondering "why not just make sure everything that ships a preset gets installed after systemd"...sadly there are some awkward cases that make that not practical, basically 'systemd depends on something that installs a preset' or 'systemd depends on something that depends on something that installs a preset'. I hadn't yet, but probably would've eventually, so thanks for this!!! ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Looking for comaintainers for AV1 related stuff
Hello, I'm very interested in AV1, the new royalty-free video codec developed by Xiph, Google and others (https://aomedia.org/). I have packaged almost all project related to AV1: - aom: https://src.fedoraproject.org/rpms/aom - dav1d: https://src.fedoraproject.org/rpms/dav1d - rav1e: Not packaged yet but all Rust deps are in - go-avif: Repo will be created soon Maybe SVT-AV1 in the future: https://github.com/OpenVisualCloud/SVT-AV1 I'm looking for comaintainers on these projects who are equally motivated by AV1, so that if I'm unavailable, they will still be maintained in Fedora in the future. If that's you, great, send me a mail! Best regards, Robert-André ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: problem with rpm dependencies
On Wed, 2019-04-24 at 13:34 +, Martin Gansser wrote:
> > On 24. 04. 19 11:14, Martin Gansser wrote:
> >
> > I see:
> >
> > Obsoletes: python2-mlt < 6.12.0-8
> > Obsoletes: mlt-python < 6.12.0-8
> >
> > %package -n python3-mlt
> > Obsoletes: %{name}-python2 < 6.12.0-8
> >
> > I believe you should only obsolete from one place.
> > Had mlt-python2 ever existed?
>
> mlt-python2 had existed in old f27 packages and was then renamed to
> python-mlt. I have removed: Obsoletes: mlt-python <6.12.0-8
These packages renames, which we use provides i.e. we rename mlt-python
to python2-mlt and we add Provides: mlt-python , give a lot of
confusions for example in dnf query --whatrequires, we may miss some
packages etc .
So IMO these "Provides" should be cleaned in next one or two releases
and all dependent packages should be adjust.
I.e. we shouldn't have any package requiring foo-python , they should
already require the correct name, python2-foo and python3-foo .
Thanks.
> > Note that the sections in the specfile are really weirdly sorted
> > (description > of python3 package is ebllow the devel package
> > etc.).
>
> I have sorted the package section
>
> > As a result, the python3 package can obsolete mlt-ruby if the
> > package is build
> > --without ruby.
>
> what does that mean exactly?
>
> Regards
> Martin
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> List Guidelines:
> https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
--
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://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: RFC: switch to uvesafb and drop openchrome in F31+
W dniu 24.04.2019 o 02:46, Adam Jackson pisze: > Finally, uvesafb only supports video devices that support VBE 2.0 or > higher. In principle, X's vesa driver supports any VBE implementation > at all. I'm not convinced this is a real issue for us though. VBE 2.0 > dates to 1994, and I have maybe one pre-2.0 video card in my > collection of old weird junk. Pure curiosity: which gpus are in any use nowadays? Other than AMD, Intel, NVidia ones. Probably some server onboard ones only. Lot of graphic cards got dropped in past already. Matrox ones for example. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Using %verify and %ghost and other issues for mass cleanups
On Wed, 24 Apr 2019 at 12:49, Pavel Valena wrote: [..] > Hello, > I'm not a provenpackager, but I want to help a bit. > Commands inline should do the trick. I've tested them, so it should be > smooth. > Thank you Pavel. Good job :) kloczek -- Tomasz Kłoczko | LinkedIn: http://lnkd.in/FXPWxH ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Can we maybe reduce the set of packages we install by default a bit?
On Wed, 24 Apr 2019 at 11:30, Björn Persson wrote: > Lennart Poettering wrote: > >As mentioned before: systemd itself already needs entropy itself (it > >assigns a random 128bit id to each service invocation, dubbed the > >"invocation ID" of it, and it generates the machine ID and seeds its > >hash table hash functions) > > Given that access to entropy during early boot is so problematic, > hardware-dependent and full of catch-22s, it seems to me that an init > system should use the entropy pool only if it really must. > > With that in mind, could you explain why the invocation ID and the hash > tables need to be cryptographically secure? Why is rand or a simple > serial number not good enough? I never heard that lack of a > cryptographically secure invocation ID was a big security problem > before SystemD. > > I expect they have to be because someone pointed out some security hack that can be done without it and no one ever noticed it before (or had a way to fix it before so we just knocked it as a 'well cant fix it so never mind'). Over the years in this business I have seen a lot of issues in the past with that mantra... they only usually get re-earthed when someone gets a nit because a new tool doesn't have it. > Björn Persson > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > -- Stephen J Smoogen. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Can we maybe reduce the set of packages we install by default a bit?
On Wed, 2019-04-24 at 14:16 +0200, Lennart Poettering wrote: > On Mi, 24.04.19 12:37, Nikos Mavrogiannopoulos (n...@redhat.com) > wrote: > > > > As mentioned before: systemd itself already needs entropy itself > > > (it > > > assigns a random 128bit id to each service invocation, dubbed the > > > "invocation ID" of it, and it generates the machine ID and seeds > > > its > > > hash table hash functions), hence rngd doesn't cut it anyway, > > > since it > > > starts after systemd, being a service managed by systemd. If rngd > > > was > > > supposed to fill up the entropy pool at boot, it would have to > > > run as > > > initial PID 1 in the initrd, before systemd, and then hand over > > > to > > > systemd only after the pool is full. But it doesn't, hence rngd > > > is > > > pointless: it runs too late to be useful. > > > > The goal of running rngd early was to have the system boot, not > > necessarily to address systemd's need for random numbers. In that > > it > > is successful. I do not disagree that it is not a clean solution. > > But how can it be successful? If systemd already needs to wait until > the pool is full to get the randomness it needs (and thus blocks > system boot-up as a whole) then what's the point in running rngd > afterwards? To reach the point where rngd can be run we already need > the pool to be full, and hence rngd can't do any good at all anymore, > whatsoever. What does systemd use to generate these random numbers? Does it directly call getrandom() or does something else? -- Tomáš Mráz No matter how far down the wrong road you've gone, turn back. Turkish proverb [You'll know whether the road is wrong if you carefully listen to your conscience.] ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: announcing HTTPS pushing to dist-git/src.fedoraproject.org for packagers and non-packagers
> The 2FA scheme that we are solely planning to support is U2F/FIDO2, and to > the best of my knowledge there has so far not been any work on integrating > this with any krb5 server. It's not done, but I'm definitely working on this. We deployed [SPAKE](https://www.ietf.org/id/draft-ietf-kitten-krb-spake-preauth-06.txt) which was the first step, and it is planned. You know who we are and can absolutely reach out to us when you have feature requests. I enjoy hearing from users - especially when I can make things better, which I can't do when I don't know what the problems are. Thanks, --Robbie ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Can we maybe reduce the set of packages we install by default a bit?
Lennart Poettering wrote: >As mentioned before: systemd itself already needs entropy itself (it >assigns a random 128bit id to each service invocation, dubbed the >"invocation ID" of it, and it generates the machine ID and seeds its >hash table hash functions) Given that access to entropy during early boot is so problematic, hardware-dependent and full of catch-22s, it seems to me that an init system should use the entropy pool only if it really must. With that in mind, could you explain why the invocation ID and the hash tables need to be cryptographically secure? Why is rand or a simple serial number not good enough? I never heard that lack of a cryptographically secure invocation ID was a big security problem before SystemD. Björn Persson pgpbHdZeSq8DS.pgp Description: OpenPGP digital signatur ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Can we maybe reduce the set of packages we install by default a bit?
On Wed, 2019-04-24 at 14:25 +0200, Lennart Poettering wrote: > On Mi, 24.04.19 06:40, Stephen John Smoogen (smo...@gmail.com) wrote: > > > > As mentioned before: systemd itself already needs entropy itself (it > > > assigns a random 128bit id to each service invocation, dubbed the > > > "invocation ID" of it, and it generates the machine ID and seeds its > > > hash table hash functions), hence rngd doesn't cut it anyway, since it > > > starts after systemd, being a service managed by systemd. If rngd was > > > supposed to fill up the entropy pool at boot, it would have to run as > > > initial PID 1 in the initrd, before systemd, and then hand over to > > > systemd only after the pool is full. But it doesn't, hence rngd is > > > pointless: it runs too late to be useful. > > > > useful to systemd and your problems. What people are trying to say is that > > it is useful to their problems. > > but it can't be. it's logically impossible. let me explain this again: > > 1. systemd needs entropy to start services and other purposes > 2. if the entropy pool is not filled up systemd thus might need to >wait for it to fill up, in a blocking fashion. When it blocks for >that it won't start any services until it unblocks again. > 3. rngd is supposed to fill up the entropy pool, thus allowing systemd >to unblock and start the first services > 4. rngd runs as regular service however, i.e. > > And ther you have your ordering cycle: > > a. systemd starts before rngd. > b. rngd runs before the entropy pool is full. > c. the entropy pool needs to be full for systemd to start > > a before b before c before a before b before c before a? How's that > solvable? > > So if you want rngd to stay and do something useful, then it needs to > be modified to start *before* systemd, in the initrd, before systemd > is invoked. i.e. not as regular service, but as kind of an init before > the real init. > > The current mode is just entirely bogus... This is all based, though, on your expectation that everything uses non-blocking interfaces, right? For anything that *does* use /dev/random or blocking getrandom() - which absolutely does happen, even the docs say it's deprecated - rngd is still useful. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
(fix some typos) Re: How to submit Root CA to ship with Fedora
On Wed, 2019-04-24 at 11:35 +0530, Danishka Navin wrote: > Hi, > > Sri Lanka Cert is gonna implement local Root CA. > How we can submit this Root CA with Fedora? > > I could not find enough information on this. You can do one custom ca-certificates.noarch package and add your certificate to ca-truted in your system. or you just need copy your ca cert to /etc/pki/ca-trust/source/anchors and run update-ca-trust I used or as reference [1] [1] https://ask.fedoraproject.org/en/question/37820/confusion-with-rpm-fusions-signing-keys/?answer=38282#post-id-38282 cd /etc/pki/ca-trust/source/anchors wget http://www.cacert.org/certs/root.crt update-ca-trust Best regards, -- 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://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Can we maybe reduce the set of packages we install by default a bit?
On Wed, 2019-04-24 at 12:02 +0200, Nikos Mavrogiannopoulos wrote: > Can the jitter entropy gather be done by the kernel? It seems yes via > the jitterentropy_rng module. So a combo of CONFIG_RANDOM_TRUST_CPU > and the jitterentropy_rng may help in simplifying fedora (if people > agree :). This sounds like a useful change, can we make Fedora load this module by default in initrd before systemd starts? Will it help? Or is this module not adding into the entropy estimate as well ? Simo. -- Simo Sorce Sr. Principal Software Engineer 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://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 30 Release Readiness meeting
This is your reminder that the Fedora 30 release readiness meeting will be held TOMORROW (Thursday), 2018-04-25 at 19:00 UTC in #fedora-meeting-1 We will meet to make sure we are coordinated and ready for the release of Fedora 30. Please note that this meeting will be held even if the release is delayed at the Go/No-Go meeting on the same day two hours earlier. For more information, see https://fedoraproject.org/wiki/Release_Readiness_Meetings. View the meeting on Fedocal: https://apps.fedoraproject.org/calendar/meeting/9514/?from_date=2019-04-22 -- Ben Cotton Fedora Program Manager TZ=America/Indiana/Indianapolis Pronouns: he/him ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: RFC: switch to uvesafb and drop openchrome in F31+
Hi, You laid this out pretty nicely. So a few questions: 1) uvesafb is only a /dev/fb driver right ? I guess it won't help with gnome-shell, but might help with weston? 2) I believe SimpleDRM is a drm version of uvesafb...have you considered it? 3) One thing i'm worried about is races with the real modesetting drivers. can we avoid loading this if theres another driver that advertises support for the pci device? does it already? 4) if you drop vesa and openchrome, maybe you could move fbdev in the server tree like modesetting. If you went with simpledrm instead, maybe you could drop fbdev entirely too? Anyway, your email makes it sound like there are more pluses than cons, so i'm on board. --Ray On Tue, Apr 23, 2019 at 8:47 PM Adam Jackson wrote: > > I'm considering changing the vesa support code in future Fedora > releases, for a few reasons. I think this will both simplify the > support burden for developers, and increase the number of supported > video configurations in practice. But it's not clear-cut, hence this > email. > > The fallback video path on x86 machines is either efifb if you're > living in the future, or X's vesa driver if you're living in the past. > At this point there are only two X drivers that require userspace setup > support, vesa and openchrome. (The latter I'm also considering nerfing, > because I sincerely doubt there are any Fedora users of it; if this is > you, speak up.) Removing this code would simplify some awkward device > enumeration cases in the X server - cases which have come up in the F30 > blocker list, and I would like not to be on the critical path for that > kind of thing in the future. > > This would also move an 8086 emulator out of the X server to a > dedicated usermode helper. Which is nice, since X still has to run with > elevated privileges in these cases, and X hasn't exactly lacked for > CVEs. > > Having done this, we would also potentially _expand_ the number of > devices we support for graphics, because we would have a vesa-backed > fbdev driver. There exist wayland servers that can display to fbdev, > but I'm not aware of any that can display directly to vesa. > > But there are risks. For one, we've never tried this. uvesafb itself is > not untested - I believe you can coax ubuntu and gentoo into using it - > but we've never built it in Fedora before, so the interactions with > with our initramfs, with plymouth, and so on are only "tested" to the > extent that they're the same thing everyone else is doing. > > In particular, I'm not entirely sure how well the handoff from uvesafb > to drm works in practice. From efifb to drm is fairly well tested, and > also fairly likely to be safe, because efifb does not give you any > ability to _change_ video device state. uvesafb does, and we could end > up putting the GPU in a new funky state that the drm driver doesn't > know how to handle. I suspect this is unlikely, and possible to > mitigate (by blocking uvesafb from initializing in more cases, for > instance), but it's something to be aware of. > > Finally, uvesafb only supports video devices that support VBE 2.0 or > higher. In principle, X's vesa driver supports any VBE implementation > at all. I'm not convinced this is a real issue for us though. VBE 2.0 > dates to 1994, and I have maybe one pre-2.0 video card in my collection > of old weird junk. > > So. Pros: remove some sketchy code from a setuid program everyone has > installed, potentially lower its privilege profile, potentially enable > wayland in more scenarios. Cons: maybe lose some device support, maybe > break gfx fallback on old-firmware systems. > > What do we think? > > - ajax > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: problem with rpm dependencies
As a result, the python3 package can obsolete mlt-ruby if the package is build
--without ruby.
%if %{with ruby}
BuildRequires: ruby-devel ruby
%else
Obsoletes: mlt-ruby < 0.8.8-5
%endif
This section was part of the python3 subpackage.
The Obsoletes would be applied on the python3 subpackage if the package was
built without ruby support. The --without ruby switches the conditional (%if
%{with ruby}).
See https://rpm.org/user_doc/conditional_builds.html
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 30 Release Readiness meeting
This is your reminder that the Fedora 30 release readiness meeting will be held TOMORROW (Thursday), 2018-04-25 at 19:00 UTC in #fedora-meeting-1 We will meet to make sure we are coordinated and ready for the release of Fedora 30. Please note that this meeting will be held even if the release is delayed at the Go/No-Go meeting on the same day two hours earlier. For more information, see https://fedoraproject.org/wiki/Release_Readiness_Meetings. View the meeting on Fedocal: https://apps.fedoraproject.org/calendar/meeting/9514/?from_date=2019-04-22 -- Ben Cotton Fedora Program Manager TZ=America/Indiana/Indianapolis Pronouns: he/him ___ 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://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel-announce@lists.fedoraproject.org
Re: Fedora 30 Go/No-Go meeting
This is your reminder that the Go/No-Go meeting for the Fedora 30 release will be held TOMORROW (Thursday), 2019-04-25 at 17:00 UTC in #fedora-meeting-1. For more information, see: https://fedoraproject.org/wiki/Go_No_Go_Meeting View the meeting on Fedocal at: https://apps.fedoraproject.org/calendar/meeting/9513/?from_date=2019-04-22 -- Ben Cotton Fedora Program Manager TZ=America/Indiana/Indianapolis Pronouns: he/him ___ 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://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel-announce@lists.fedoraproject.org
[Test-Announce] Re: Fedora 30 Go/No-Go meeting
This is your reminder that the Go/No-Go meeting for the Fedora 30 release will be held TOMORROW (Thursday), 2019-04-25 at 17:00 UTC in #fedora-meeting-1. For more information, see: https://fedoraproject.org/wiki/Go_No_Go_Meeting View the meeting on Fedocal at: https://apps.fedoraproject.org/calendar/meeting/9513/?from_date=2019-04-22 -- Ben Cotton Fedora Program Manager TZ=America/Indiana/Indianapolis Pronouns: he/him ___ 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://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/test-annou...@lists.fedoraproject.org ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Help with broken UTF-8 on F30 (Rawhide) mock target
It works! Thanks a lot for your suggestion. Jirka On Fri, 2019-04-19 at 20:18 +0200, Rafal Luzynski wrote: > 18.04.2019 21:16 jkone...@redhat.com wrote: > > [...] > > All the information can be found here: > > > > https://github.com/rpm-software-management/mock/issues/250 > > The discussion contains the suggestion that adding glibc-all- > langpacks > to BuildRequires fixes the problem. My other suggestion is that > maybe glibc-langpack-en is sufficient. > > Regards, > > Rafal ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: grub2-editenv: error: environment block too small after kernel install
On Tue, Apr 23, 2019 at 7:20 PM Chris Murphy wrote: > On Tue, Apr 23, 2019 at 8:38 AM Richard Shaw wrote: > > > > I made the mistake of editing my grubenv while converting my system from > BIOS to UEFI. > > > > I have since manually used grub2-editenv successfully but I still get > "grub2-editenv: error: environment block too small." on kernel upgrades. > I've even tried manually re-padding the file with # to get to 1024 bytes. > > > > I have also filed and issue upstream that grub2-editenv is too fragile. > It should be able to automatically re-pad the file to 1024 bytes. > > > > How do I "fix" this? > > Is it really 1024 bytes? > # stat /boot/efi/EFI/fedora/grubenv > # stat /boot/efi/EFI/fedora/grubenv File: /boot/efi/EFI/fedora/grubenv Size: 1024Blocks: 8 IO Block: 4096 regular file Device: 10301h/66305d Inode: 299 Links: 1 Access: (0700/-rwx--) Uid: (0/root) Gid: (0/root) Context: system_u:object_r:dosfs_t:s0 Access: 2019-04-22 19:00:00.0 -0500 Modify: 2019-04-23 09:29:08.0 -0500 Change: 2019-04-23 09:29:09.51000 -0500 > I'm not exactly sure when we started doing this, but.. > > # ls -ls /boot/grub2 > total 4 > 4 lrwxrwxrwx. 1 root root 25 Apr 18 11:34 grubenv -> > ../efi/EFI/fedora/grubenv > > It's actually a symlink on both BIOS and UEFI. This file will be on > the /boot volume (typically ext4) on BIOS systems, and it will be on > the EFI System partition (FAT16 if anaconda creates it) on UEFI. But > if you did a conversion from BIOS to UEFI, it's possible this symlink > is broken and that's why you're getting the error. > I reinstalled all the efi related packages so things would get "created" properly. # file grub2/grubenv grub2/grubenv: symbolic link to ../efi/EFI/fedora/grubenv # parted -l | grep EFI 1 1049kB 211MB 210MB fat16EFI System Partition boot, esp If the real grub env on /boot/efi doesn't actually exist then you > might need to do: > > #grub2-editenv /boot/efi/EFI/fedora/grubenv create > I may move mine to a backup and try that anyway. Thanks, Richard ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: grub2-editenv: error: environment block too small after kernel install
On Tue, Apr 23, 2019 at 06:19:14PM -0600, Chris Murphy wrote: > On Tue, Apr 23, 2019 at 8:38 AM Richard Shaw wrote: > > > > I made the mistake of editing my grubenv while converting my system from > > BIOS to UEFI. > > > > I have since manually used grub2-editenv successfully but I still get > > "grub2-editenv: error: environment block too small." on kernel upgrades. > > I've even tried manually re-padding the file with # to get to 1024 bytes. > > > > I have also filed and issue upstream that grub2-editenv is too fragile. It > > should be able to automatically re-pad the file to 1024 bytes. > > > > How do I "fix" this? > > # ls -ls /boot/grub2 > total 4 > 4 lrwxrwxrwx. 1 root root 25 Apr 18 11:34 grubenv -> ../efi/EFI/fedora/grubenv > > It's actually a symlink on both BIOS and UEFI. This file will be on > the /boot volume (typically ext4) on BIOS systems, and it will be on > the EFI System partition (FAT16 if anaconda creates it) on UEFI. This part is really counter-intuitive. Using “EFI” in path on BIOS system made me waste some time when I was recovering my system after f29→f30 system upgrade. (the problem turned out to be translation from grub2.cfg to BLS removing all important rd.luks.uuid= entries from kernel cmdline). -- Tomasz Torcz 72->| 80->| xmpp: zdzich...@chrome.pl 72->| 80->| ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: problem with rpm dependencies
> On 24. 04. 19 11:14, Martin Gansser wrote:
>
> I see:
>
> Obsoletes: python2-mlt < 6.12.0-8
> Obsoletes: mlt-python < 6.12.0-8
>
> %package -n python3-mlt
> Obsoletes: %{name}-python2 < 6.12.0-8
>
> I believe you should only obsolete from one place.
> Had mlt-python2 ever existed?
mlt-python2 had existed in old f27 packages and was then renamed to python-mlt.
I have removed: Obsoletes: mlt-python <6.12.0-8
> Note that the sections in the specfile are really weirdly sorted (description
> > of python3 package is ebllow the devel package etc.).
I have sorted the package section
> As a result, the python3 package can obsolete mlt-ruby if the package is
> build
> --without ruby.
what does that mean exactly?
Regards
Martin
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: I plan to remove python2-pep8
On Wed, Apr 24, 2019 at 14:43:39 +0200, Miro Hrončok wrote: > If the upstream maintainer as no interest in Python 3 support, I guess we > have > no interest in cachedir. That's my thought as well. > Disclaimer: I don't know or use cachedir. However from the first glance, it > looks like something that could be reimplemented in a Bash one-liner. > Could you please elaborate on its importance to Fedora? Because I don't > really > see it. I might be missing something. I use it for tagging and untagging cache directories for by backup tool of choice (restic) to avoid backing up things like my browser cache or other things that don't "matter". It could probably be replaced with a short script or other small tool. But maintaining Bash code is worse than maintaining Python2 code IMO, so maybe I'll find some time to rewrite it in Python3 using something like click to avoid having to port cliapp and cmdtest as well. --Ben ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Can we maybe reduce the set of packages we install by default a bit?
On Wed, 24 Apr 2019 at 08:26, Lennart Poettering wrote: > On Mi, 24.04.19 06:40, Stephen John Smoogen (smo...@gmail.com) wrote: > > > > As mentioned before: systemd itself already needs entropy itself (it > > > assigns a random 128bit id to each service invocation, dubbed the > > > "invocation ID" of it, and it generates the machine ID and seeds its > > > hash table hash functions), hence rngd doesn't cut it anyway, since it > > > starts after systemd, being a service managed by systemd. If rngd was > > > supposed to fill up the entropy pool at boot, it would have to run as > > > initial PID 1 in the initrd, before systemd, and then hand over to > > > systemd only after the pool is full. But it doesn't, hence rngd is > > > pointless: it runs too late to be useful. > > > > useful to systemd and your problems. What people are trying to say is > that > > it is useful to their problems. > > but it can't be. it's logically impossible. let me explain this again: > > 1. systemd needs entropy to start services and other purposes > 2. if the entropy pool is not filled up systemd thus might need to >wait for it to fill up, in a blocking fashion. When it blocks for >that it won't start any services until it unblocks again. > 3. rngd is supposed to fill up the entropy pool, thus allowing systemd >to unblock and start the first services > 4. rngd runs as regular service however, i.e. > > And ther you have your ordering cycle: > > a. systemd starts before rngd. > b. rngd runs before the entropy pool is full. > c. the entropy pool needs to be full for systemd to start > > a before b before c before a before b before c before a? How's that > solvable? > > Again, I am not disagreeing that it isn't important.. I am just saying that the other people saying they need it later and you are coming across as saying get rid of it completely just because it doesn't meet your needs. Most of them are seeing the system way after your problem and needing it fixed then. Let us look at it as a plumbing issue. We currently have a building with a bunch of pipes with small feeds and you as the morning janitor come in first of the day to wash the floors and clean things so other people can get to work. To fill your buckets you need a big basin to start up and have to instead wait around as the pipes fill up your cleaning bucket. You look around and see that people installed various buckets and pots to act as basins in their rooms they use to wash their hands and fases with but you can't use them as they need to be cleaned first. No one sees your problem because by the time their day starts.. you have been in there for hours and got your drip drip going and done your work. The problem here is that how you have come across is "Well I need more water, so we should rip out all the basins until I get one too. Just use this mopbucket water like I do." I don't know if that is what you are meaning to say or not. If it isn't then I am just trying to explain why people are 'reacting' versus 'fixing'. Yes the problem needs to be solved sooner in the chain. You need a proper basin to fill up water in. In fact we all need proper plumbing which helps each service we are running. Working out how to get it is what we should be doing but instead we are arguing over who is going to go on strike first to get it. So if you want rngd to stay and do something useful, then it needs to > be modified to start *before* systemd, in the initrd, before systemd > is invoked. i.e. not as regular service, but as kind of an init before > the real init. > > Which is what I was trying to say but you cut out. > The current mode is just entirely bogus... > > 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://getfedora.org/code-of-conduct.html > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > -- Stephen J Smoogen. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: I plan to remove python2-pep8
On 24. 04. 19 14:28, Ben Boeckel wrote: On Mon, Apr 22, 2019 at 17:20:02 -0400, Ben Boeckel wrote: [ Removed pylast and ovirt-guest-agent emails from Cc. ] On Mon, Apr 22, 2019 at 17:53:03 +0200, Miro Hrončok wrote: Maintainers by package: cachedir mathstuf cmdtest salimma genbackupdatasalimma python-cliappsalimma python-larch salimma These are all packages from obnam which is now retired/EOL. I think larch and genbackupdata can probably be retired (though maybe others find genbackupdata useful?). cachedir is still useful and uses cliapp. cmdtest *could* be dropped; it is only used for the testing in cachedir (as is pep8), but running the testsuite is nice-to-have. Talking with Lars Wirzenius, upstream for this stack, he has no interest in Python3 support for this stack (well, explicitly about cachedir; I'm assuming about the others) and would prefer a new maintainer for them if such work were to occur. Should we discuss with other distributions about doing this or just start the retirement process? Note that Lars is the Debian packager, so I imagine we can skip that part. Whatever works for you. As the Python maintainer I care for 2 things: - move away from pep8 to pycodestyle - move to Python 3 or retire from Fedora My e-mail was mostly about the first thing. If the upstream maintainer as no interest in Python 3 support, I guess we have no interest in cachedir. Disclaimer: I don't know or use cachedir. However from the first glance, it looks like something that could be reimplemented in a Bash one-liner. Could you please elaborate on its importance to Fedora? Because I don't really see it. I might be missing something. -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: How to submit Root CA to ship with Fedora
On Wed, 2019-04-24 at 11:35 +0530, Danishka Navin wrote: > Hi, > > Sri Lanka Cert is gonna implement local Root CA. > How we can submit this Root CA with Fedora? > > I could not find enough information on this. you can do one custom ca-certificates-2018.2.26-2.fc29.noarch package and add your certificate to ca-truted in you system or you just need copy you ca to /etc/pki/ca-trust/source/anchors and run update-ca-trust I used or as reference [1] [1] https://ask.fedoraproject.org/en/question/37820/confusion-with-rpm-fusions-signing-keys/?answer=38282#post-id-38282 Best regards, -- 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://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: I plan to remove python2-pep8
On Mon, Apr 22, 2019 at 17:20:02 -0400, Ben Boeckel wrote: > [ Removed pylast and ovirt-guest-agent emails from Cc. ] > > On Mon, Apr 22, 2019 at 17:53:03 +0200, Miro Hrončok wrote: > > Maintainers by package: > > cachedir mathstuf > > cmdtest salimma > > genbackupdatasalimma > > python-cliappsalimma > > python-larch salimma > > These are all packages from obnam which is now retired/EOL. I think > larch and genbackupdata can probably be retired (though maybe others > find genbackupdata useful?). cachedir is still useful and uses cliapp. > cmdtest *could* be dropped; it is only used for the testing in cachedir > (as is pep8), but running the testsuite is nice-to-have. Talking with Lars Wirzenius, upstream for this stack, he has no interest in Python3 support for this stack (well, explicitly about cachedir; I'm assuming about the others) and would prefer a new maintainer for them if such work were to occur. Should we discuss with other distributions about doing this or just start the retirement process? Note that Lars is the Debian packager, so I imagine we can skip that part. --Ben ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Can we maybe reduce the set of packages we install by default a bit?
On Mi, 24.04.19 06:40, Stephen John Smoogen (smo...@gmail.com) wrote: > > As mentioned before: systemd itself already needs entropy itself (it > > assigns a random 128bit id to each service invocation, dubbed the > > "invocation ID" of it, and it generates the machine ID and seeds its > > hash table hash functions), hence rngd doesn't cut it anyway, since it > > starts after systemd, being a service managed by systemd. If rngd was > > supposed to fill up the entropy pool at boot, it would have to run as > > initial PID 1 in the initrd, before systemd, and then hand over to > > systemd only after the pool is full. But it doesn't, hence rngd is > > pointless: it runs too late to be useful. > > useful to systemd and your problems. What people are trying to say is that > it is useful to their problems. but it can't be. it's logically impossible. let me explain this again: 1. systemd needs entropy to start services and other purposes 2. if the entropy pool is not filled up systemd thus might need to wait for it to fill up, in a blocking fashion. When it blocks for that it won't start any services until it unblocks again. 3. rngd is supposed to fill up the entropy pool, thus allowing systemd to unblock and start the first services 4. rngd runs as regular service however, i.e. And ther you have your ordering cycle: a. systemd starts before rngd. b. rngd runs before the entropy pool is full. c. the entropy pool needs to be full for systemd to start a before b before c before a before b before c before a? How's that solvable? So if you want rngd to stay and do something useful, then it needs to be modified to start *before* systemd, in the initrd, before systemd is invoked. i.e. not as regular service, but as kind of an init before the real init. The current mode is just entirely bogus... 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://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Can we maybe reduce the set of packages we install by default a bit?
On Mi, 24.04.19 12:37, Nikos Mavrogiannopoulos (n...@redhat.com) wrote: > > As mentioned before: systemd itself already needs entropy itself (it > > assigns a random 128bit id to each service invocation, dubbed the > > "invocation ID" of it, and it generates the machine ID and seeds its > > hash table hash functions), hence rngd doesn't cut it anyway, since it > > starts after systemd, being a service managed by systemd. If rngd was > > supposed to fill up the entropy pool at boot, it would have to run as > > initial PID 1 in the initrd, before systemd, and then hand over to > > systemd only after the pool is full. But it doesn't, hence rngd is > > pointless: it runs too late to be useful. > > The goal of running rngd early was to have the system boot, not > necessarily to address systemd's need for random numbers. In that it > is successful. I do not disagree that it is not a clean solution. But how can it be successful? If systemd already needs to wait until the pool is full to get the randomness it needs (and thus blocks system boot-up as a whole) then what's the point in running rngd afterwards? To reach the point where rngd can be run we already need the pool to be full, and hence rngd can't do any good at all anymore, whatsoever. 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://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: How to submit Root CA to ship with Fedora
Hello, Danishka Navin. Wed, 24 Apr 2019 14:12:44 +0530 you wrote: > I have already a passwed relavent information and asked to create a > ticket against NSS product and 'CA Certificate Root Program' component. Mozilla will never accept CA certificates for government MITM. -- 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://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
[Bug 1702366] perl-Storable-3.15 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1702366 --- Comment #4 from Fedora Update System --- perl-Storable-3.15-1.fc28 has been submitted as an update to Fedora 28. https://bodhi.fedoraproject.org/updates/FEDORA-2019-4b8dd26bb6 -- You are receiving this mail because: You are on the CC list for the bug. ___ 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://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
[Bug 1702366] perl-Storable-3.15 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1702366 --- Comment #3 from Fedora Update System --- perl-Storable-3.15-1.fc29 has been submitted as an update to Fedora 29. https://bodhi.fedoraproject.org/updates/FEDORA-2019-e0f6509bb0 -- You are receiving this mail because: You are on the CC list for the bug. ___ 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://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
[Bug 1702366] perl-Storable-3.15 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1702366 --- Comment #2 from Fedora Update System --- perl-Storable-3.15-1.fc30 has been submitted as an update to Fedora 30. https://bodhi.fedoraproject.org/updates/FEDORA-2019-ef2ca6df10 -- You are receiving this mail because: You are on the CC list for the bug. ___ 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://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
Re: Using %verify and %ghost and other issues for mass cleanups
- Original Message -
> From: "Tomasz Kłoczko"
> To: "Development discussions related to Fedora"
>
> Sent: Thursday, April 4, 2019 3:38:11 PM
> Subject: Using %verify and %ghost and other issues for mass cleanups
>
> Hi,
>
> Looks like I found something to do for someone with proven packager
> privileges (which allow straight modify of any Fedora package git repo
> without asking package maintainer to do modification).
> Submitting hundreds of separated PRs for all below cases does not make to
> much sense and totally will consume few man/days and with proven packager
> privs it should take minutes.
Hello,
I'm not a provenpackager, but I want to help a bit.
Commands inline should do the trick. I've tested them, so it should be smooth.
>
> !) (over)use %veryfy() with %ghost
>
> Just results of two commands:
>
> [tkloczko@domek SPECS.fedora]$ grep %ghost * | grep %verify | awk -F: '{print
> $1}' | sort | uniq | wc -l
> 45
> [tkloczko@domek SPECS.fedora]$ grep %ghost * | grep %verify | awk -F: '{print
> $1}' | sort | uniq -c
> 1 arpwatch.spec
> 1 at.spec
> 8 bind.spec
> 2 certmaster.spec
> 2 clamav.spec
> 1 community-mysql.spec
> 1 cone.spec
> 3 cronie.spec
> 1 cyrus-imapd.spec
> 2 dovecot.spec
> 2 efont-unicode-bdf.spec
> 2 elinks.spec
> 2 exim.spec
> 1 fail2ban.spec
> 1 freeipa.spec
> 3 func.spec
> 14 glibc.spec
> 2 hitch.spec
> 1 initscripts.spec
> 1 japanese-bitmap-fonts.spec
> 2 jwhois.spec
> 1 kde-workspace.spec
> 1 libXvMC.spec
> 2 links.spec
> 1 logrotate.spec
> 1 mariadb.spec
> 5 monotone.spec
> 1 nessus-libraries.spec
> 3 openvswitch.spec
> 2 PackageKit.spec
> 1 pam.spec
> 2 pax.spec
> 2 setup.spec
> 1 sgml-common.spec
> 3 sssd.spec
> 2 star.spec
> 1 system-config-printer.spec
> 2 t1lib.spec
> 1 texlive-base.spec
> 2 tog-pegasus.spec
> 4 urw-base35-fonts.spec
> 2 util-linux.spec
> 2 uw-imap.spec
> 2 whois.spec
> 72 xorg-x11-fonts.spec
find -maxdepth 2 -name '*.spec' -exec sed -i '/%ghost/ s/%verify\s*([^)]*)//g'
"{}" \;
>
> What exactly is wrong with those specs files?
> In all those specs %verify() token can be dropped without any consequences.
>
> Example fragment from last whois.spec:
>
> %ghost %verify(not md5 size mtime) %{_bindir}/%{name}
> %{_mandir}/man1/%{name}.%{alternative}.*
> %ghost %verify(not md5 size mtime) %{_mandir}/man1/%{name}.1.gz
>
> In all those cases looks like packagers don't know that %ghost disables md5,
> size, mtime verification automatically . Fragment from rpm C code from:
> https://github.com/rpm-software-management/rpm/blob/master/lib/verify.c#L117
>
> /* Content checks of %ghost files are meaningless. */
> if (fileAttrs & RPMFILE_GHOST)
> flags &= ~(RPMVERIFY_FILEDIGEST | RPMVERIFY_FILESIZE |
> RPMVERIFY_MTIME | RPMVERIFY_LINKTO);
>
> +2 years ago I've submitted PR for glibc.spec patch to simplify (already
> horrible and hard to read spec) but even above URL to the rpm code was
> not able convince glibc maintainers.
>
> 2) Using .gz suffix with man and info pages %files entries
>
> That is possible to see in already quoted whois.spec part.
>
> Number of affected packages:
>
> [tkloczko@domek SPECS.fedora]$ grep "^%{_mandir}/.*.gz" * -l | wc -l
> 618
>
> List of the packages which needst to be corrected:
>
> [tkloczko@domek SPECS.fedora]$ grep "^%{_mandir}/.*.gz" * -l | awk -F.
> '{print $1}' | xargs
> 389-ds-base 3proxy abiword abrt-java-connector acpid agedu AGReader ahcpd
> alacarte alsa-utils amoebax amora amtterm anyremote anyterm
> api-sanity-checker archivemail arduino-ctags aria2 arm-none-eabi-binutils-cs
> arm-none-eabi-gcc-cs artha asc aterm atf atop audit autogen avr-binutils
> avrdude avr-gcc awesfx aws balance barcode barman batctl bats bchunk beaker
> bibtex2html biosig4c++ bip bluez-hcidump bluez boinc-client bombardier
> boomaga botan2 bspwm btrfs-progs busybox byobu ca-certificates cairo-clock
> caja-extensions calcurse calendar ccd2iso cduce certmaster cfv CGAL cgdb
> check-mk checkpolicy chirp chocolate-doom chromium-bsu cifs-utils cjdns ck
> clamsmtp clang ClanLib06 clazy clive clpbar cmark codeblocks colord-gtk
> colorhug-client colrdx connman conserver console-image-viewer corkscrew
> cqrlog crack-attack cryptlib cryptobone cryptsetup cups-filters cups
> curblaster cwdaemon daemonize dahdi-tools danmaq darktable dasher datamash
> davfs2 dconf debmirror deepin-mutter deja-dup desktop-file-utils detox
> device-mapper-multipath device-mapper-persistent-data devilspie2 devilspie
> dex-autostart dhcpcd dillo disper dmtcp dnscap dnssec-tools docker-latest
> docker dogtag-pki doxy2man dpkg drawtiming drbd dt dxcc dynamite
> ecryptfs-utils efibootmgr electric emelfm2 enchant endless-sky
> environment-modules esound espeak-ng espeak expect ezstream fastd fbterm
> fedrepos ffgtk Field3D fishpoll fldigi fmtools fntsample focuswriter foo2zjs
> fpaste fpm2 fprintd freecad freecol freedroidrpg freight-tools fribidi frysk
> fts func fuse-emulator fuse-emulator-utils fuse-sshfs fuse-zip fwrestart
> gammaray gammu gbrainy
Re: problem with rpm dependencies
On 24. 04. 19 11:14, Martin Gansser wrote:
Hi Miro, Tom,
i have changed the spec file, now you can install the package.
Can you have a look again to the spec file, if it is ok ?
[1] https://martinkg.fedorapeople.org/Packages/mlt/mlt.spec
I see:
Obsoletes: python2-mlt < 6.12.0-8
Obsoletes: mlt-python < 6.12.0-8
%package -n python3-mlt
Obsoletes: %{name}-python2 < 6.12.0-8
I believe you should only obsolete from one place.
Had mlt-python2 ever existed?
Note that the sections in the specfile are really weirdly sorted (description of
python3 package is ebllow the devel package etc.).
As a result, the python3 package can obsolete mlt-ruby if the package is build
--without ruby.
I recommend sorting th sections like this:
%package XXX
# XXX package related provides/obsoletes/(build)requires/summary...
%description XXX
...
%package YYY
# YYY package related provides/obsoletes/(build)requires/summary...
%description YYY
...
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
[EPEL-devel] Re: EPEL7: Adapting %python_provide to provide python3- for python36-
On Wed, 24 Apr 2019 at 06:23, Miro Hrončok wrote:
> Hey,
>
> since the plan is to have some python3-... packages in RHEL proper, should
> we
> adapt the %python_provide macro to provide python3-... when it gets
> python36-...?
>
> %{python_provide python36-foo} currently does nothing.
> I propose to change it to do: Provides: python3-foo =
> %{version}-%{release}.
>
>
Thank you for asking for input on this... I think that your view as subject
matter expert has a lot of weight here and EPEL will most likely go with
that. However getting input from people who are affected can make that
clearer.
> Note: %{python_provide python2-foo} currently adds obsoletes, let's not
> add them
> for the python36 case (there is nothing to obsolete here, quite the
> opossite -
> python3-foo from RHEL would in theory obsolete python36-foo from EPEL).
>
> Arguably, this discussion should have happened before we did the mass
> rebuild
> for 3.4 -> 3.6 transition, however I don't consider such provides
> essential. The
> idea is to change the macro, but don't mass rebuild - instead start
> providing
> the provides gradually.
>
> Note that not all EPEL7 Python 3 packages use this macro, but many do.
>
>
Should they?
> --
> Miro Hrončok
> --
> Phone: +420777974800
> IRC: mhroncok
> ___
> 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://getfedora.org/code-of-conduct.html
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org
>
--
Stephen J Smoogen.
___
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://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org
Re: Can we maybe reduce the set of packages we install by default a bit?
On Wed, 24 Apr 2019 at 06:24, Lennart Poettering wrote: > On Mi, 24.04.19 12:02, Nikos Mavrogiannopoulos (n...@redhat.com) wrote: > > > On Thu, Apr 18, 2019 at 10:23 AM Lennart Poettering > > wrote: > > > Sure, you can invoke rngd before systemd, in which case it would have > > > to be able to run as PID 1 itself pretty much and then hand over > > > things. > > > > > > But why do that in userspace at all? the "Trust CPU RNG" kernel > > > compile time option shows that these things are trivial to solve if > > > people just want to. Instead of involving rngd at all, why not add a > > > similar option for the TPM RNG (or any other non-CPU hw rng) and then > > > rngd doesn't do anything useful anymore whatsoever? I mean, to my > > > knowledge all those other RNGs already feed into the pool anyway, they > > > just don't get trusted and thus don't add to the entropy > > > estimate. Fixing that should be quite doable and given that > > > CONFIG_RANDOM_TRUST_CPU exists now it shouldn't be politically too > > > hard to argue for a CONFIG_RANDOM_TRUST_TPM either... > > > > I like the part that this is trivial to solve if people want to. > > Making people agree is an order of magnitude harder than fixing any > > code. Nevertheless, without rngd, getrandom() would block in one of > > the first services started by systemd (if it doesn't block in systemd > > itself). > > As mentioned before: systemd itself already needs entropy itself (it > assigns a random 128bit id to each service invocation, dubbed the > "invocation ID" of it, and it generates the machine ID and seeds its > hash table hash functions), hence rngd doesn't cut it anyway, since it > starts after systemd, being a service managed by systemd. If rngd was > supposed to fill up the entropy pool at boot, it would have to run as > initial PID 1 in the initrd, before systemd, and then hand over to > systemd only after the pool is full. But it doesn't, hence rngd is > pointless: it runs too late to be useful. > > useful to systemd and your problems. What people are trying to say is that it is useful to their problems. There are several solutions to try here: 1. Make something like it run sooner so it helps your problems 2. Add something like it into the kernel (which has been a Sisyphus task from what i can tell) 3. Pull it into systemd so it helps your problems and others. 4. Keep this thread going with everyone talking past each other. -- Stephen J Smoogen. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Can we maybe reduce the set of packages we install by default a bit?
On Wed, Apr 24, 2019 at 12:24 PM Lennart Poettering wrote: > > > But why do that in userspace at all? the "Trust CPU RNG" kernel > > > compile time option shows that these things are trivial to solve if > > > people just want to. Instead of involving rngd at all, why not add a > > > similar option for the TPM RNG (or any other non-CPU hw rng) and then > > > rngd doesn't do anything useful anymore whatsoever? I mean, to my > > > knowledge all those other RNGs already feed into the pool anyway, they > > > just don't get trusted and thus don't add to the entropy > > > estimate. Fixing that should be quite doable and given that > > > CONFIG_RANDOM_TRUST_CPU exists now it shouldn't be politically too > > > hard to argue for a CONFIG_RANDOM_TRUST_TPM either... > > > > I like the part that this is trivial to solve if people want to. > > Making people agree is an order of magnitude harder than fixing any > > code. Nevertheless, without rngd, getrandom() would block in one of > > the first services started by systemd (if it doesn't block in systemd > > itself). > > As mentioned before: systemd itself already needs entropy itself (it > assigns a random 128bit id to each service invocation, dubbed the > "invocation ID" of it, and it generates the machine ID and seeds its > hash table hash functions), hence rngd doesn't cut it anyway, since it > starts after systemd, being a service managed by systemd. If rngd was > supposed to fill up the entropy pool at boot, it would have to run as > initial PID 1 in the initrd, before systemd, and then hand over to > systemd only after the pool is full. But it doesn't, hence rngd is > pointless: it runs too late to be useful. The goal of running rngd early was to have the system boot, not necessarily to address systemd's need for random numbers. In that it is successful. I do not disagree that it is not a clean solution. regards, Nikos ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
[EPEL-devel] Re: EPEL7: Adapting %python_provide to provide python3- for python36-
On Wed, Apr 24, 2019 at 6:23 AM Miro Hrončok wrote:
>
> Hey,
>
> since the plan is to have some python3-... packages in RHEL proper, should we
> adapt the %python_provide macro to provide python3-... when it gets
> python36-...?
>
> %{python_provide python36-foo} currently does nothing.
> I propose to change it to do: Provides: python3-foo = %{version}-%{release}.
>
> Note: %{python_provide python2-foo} currently adds obsoletes, let's not add
> them
> for the python36 case (there is nothing to obsolete here, quite the opossite -
> python3-foo from RHEL would in theory obsolete python36-foo from EPEL).
>
> Arguably, this discussion should have happened before we did the mass rebuild
> for 3.4 -> 3.6 transition, however I don't consider such provides essential.
> The
> idea is to change the macro, but don't mass rebuild - instead start providing
> the provides gradually.
>
> Note that not all EPEL7 Python 3 packages use this macro, but many do.
>
That would actually be great, since it simplifies how people can use it.
--
真実はいつも一つ！/ Always, there's only one truth!
___
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://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org
Re: [EPEL-devel] EPEL7: Adapting %python_provide to provide python3- for python36-
On Wed, Apr 24, 2019 at 6:23 AM Miro Hrončok wrote:
>
> Hey,
>
> since the plan is to have some python3-... packages in RHEL proper, should we
> adapt the %python_provide macro to provide python3-... when it gets
> python36-...?
>
> %{python_provide python36-foo} currently does nothing.
> I propose to change it to do: Provides: python3-foo = %{version}-%{release}.
>
> Note: %{python_provide python2-foo} currently adds obsoletes, let's not add
> them
> for the python36 case (there is nothing to obsolete here, quite the opossite -
> python3-foo from RHEL would in theory obsolete python36-foo from EPEL).
>
> Arguably, this discussion should have happened before we did the mass rebuild
> for 3.4 -> 3.6 transition, however I don't consider such provides essential.
> The
> idea is to change the macro, but don't mass rebuild - instead start providing
> the provides gradually.
>
> Note that not all EPEL7 Python 3 packages use this macro, but many do.
>
That would actually be great, since it simplifies how people can use it.
--
真実はいつも一つ！/ Always, there's only one truth!
___
python-devel mailing list -- python-devel@lists.fedoraproject.org
To unsubscribe send an email to python-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/python-devel@lists.fedoraproject.org
Re: Can we maybe reduce the set of packages we install by default a bit?
On Mi, 24.04.19 12:02, Nikos Mavrogiannopoulos (n...@redhat.com) wrote: > On Thu, Apr 18, 2019 at 10:23 AM Lennart Poettering > wrote: > > Sure, you can invoke rngd before systemd, in which case it would have > > to be able to run as PID 1 itself pretty much and then hand over > > things. > > > > But why do that in userspace at all? the "Trust CPU RNG" kernel > > compile time option shows that these things are trivial to solve if > > people just want to. Instead of involving rngd at all, why not add a > > similar option for the TPM RNG (or any other non-CPU hw rng) and then > > rngd doesn't do anything useful anymore whatsoever? I mean, to my > > knowledge all those other RNGs already feed into the pool anyway, they > > just don't get trusted and thus don't add to the entropy > > estimate. Fixing that should be quite doable and given that > > CONFIG_RANDOM_TRUST_CPU exists now it shouldn't be politically too > > hard to argue for a CONFIG_RANDOM_TRUST_TPM either... > > I like the part that this is trivial to solve if people want to. > Making people agree is an order of magnitude harder than fixing any > code. Nevertheless, without rngd, getrandom() would block in one of > the first services started by systemd (if it doesn't block in systemd > itself). As mentioned before: systemd itself already needs entropy itself (it assigns a random 128bit id to each service invocation, dubbed the "invocation ID" of it, and it generates the machine ID and seeds its hash table hash functions), hence rngd doesn't cut it anyway, since it starts after systemd, being a service managed by systemd. If rngd was supposed to fill up the entropy pool at boot, it would have to run as initial PID 1 in the initrd, before systemd, and then hand over to systemd only after the pool is full. But it doesn't, hence rngd is pointless: it runs too late to be useful. 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://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
EPEL7: Adapting %python_provide to provide python3- for python36-
Hey,
since the plan is to have some python3-... packages in RHEL proper, should we
adapt the %python_provide macro to provide python3-... when it gets python36-...?
%{python_provide python36-foo} currently does nothing.
I propose to change it to do: Provides: python3-foo = %{version}-%{release}.
Note: %{python_provide python2-foo} currently adds obsoletes, let's not add them
for the python36 case (there is nothing to obsolete here, quite the opossite -
python3-foo from RHEL would in theory obsolete python36-foo from EPEL).
Arguably, this discussion should have happened before we did the mass rebuild
for 3.4 -> 3.6 transition, however I don't consider such provides essential. The
idea is to change the macro, but don't mass rebuild - instead start providing
the provides gradually.
Note that not all EPEL7 Python 3 packages use this macro, but many do.
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
___
python-devel mailing list -- python-devel@lists.fedoraproject.org
To unsubscribe send an email to python-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/python-devel@lists.fedoraproject.org
[389-devel] Groups are not accessible by filter
Hi all,
Please consider bellow condition .
UserAccount(topo.standalone, 'cn=Accounting
Managers,ou=groups,dc=example,dc=com').add('uniquemember', [
'uid=scarter, ou=People, dc=example,dc=com', 'uid=tmorris,
ou=People, dc=example,dc=com', 'uid=kvaughan, ou=People,
dc=example,dc=com',
'uid=rdaugherty, ou=People, dc=example,dc=com', 'uid=hmiller,
ou=People, dc=example,dc=com'])
UserAccount(topo.standalone, 'cn=HR
Managers,ou=groups,dc=example,dc=com').add('uniquemember', [
'uid=kvaughan, ou=People, dc=example,dc=com', 'uid=cschmith,
ou=People, dc=example,dc=com'])
And try to add filter:
With Filter: It fails gives 0 result for those involves Group
'cn=Accounting Managers,ou=groups,dc=example,dc=com' .
for i in ['(uniquemember=uid=kvaughan,ou=People,dc=example,dc=com)',
'(uniquemember=uid=rdaugherty, ou=People, dc=example,dc=com)',
'(uniquemember=uid=hmiller, ou=People, dc=example,dc=com)',
'(&(objectclass=inetorgperson)(uid=scarter))',
'(&(objectclass=organizationalperson)(uid=scarter))',
'(objectclass=inetorgperson)',
'(&(objectclass=organizationalPerson)(sn=Jensen))',
'(&(mail=*)(objectclass=organizationalPerson))',
'(mail=*)',
'(&(sn=Rentz)(objectclass=organizationalPerson))',
'(&(sn=Ward)(sn=Ward))',
'(sn=Jensen)',
'(sn=*)',
'(sn=*utz)']:
assert Accounts(topo.standalone, DEFAULT_SUFFIX).filter(i)
with search_s(Old Way): I gives correct results .
for i in ['(uniquemember=uid=kvaughan,ou=People,dc=example,dc=com)',
'(uniquemember=uid=rdaugherty, ou=People, dc=example,dc=com)',
'(uniquemember=uid=hmiller, ou=People, dc=example,dc=com)',
'(&(objectclass=inetorgperson)(uid=scarter))',
'(&(objectclass=organizationalperson)(uid=scarter))',
'(objectclass=inetorgperson)',
'(&(objectclass=organizationalPerson)(sn=Jensen))',
'(&(mail=*)(objectclass=organizationalPerson))',
'(mail=*)',
'(&(sn=Rentz)(objectclass=organizationalPerson))',
'(&(sn=Ward)(sn=Ward))',
'(sn=Jensen)',
'(sn=*)',
'(sn=*utz)']:
assert topo.standalone.search_s(DEFAULT_SUFFIX, ldap.SCOPE_SUBTREE, i)
I have attached the test script too . Test
test_various_combinations_of_filters_and_idlistscanlimit
Regards
Anuj Borah
# --- BEGIN COPYRIGHT BLOCK ---
# Copyright (C) 2019 Red Hat, Inc.
# All rights reserved.
#
# License: GPL (version 3 or any later version).
# See LICENSE for details.
# --- END COPYRIGHT BLOCK ---
import os
import re
import pytest
from lib389._constants import DEFAULT_SUFFIX, PW_DM
from lib389.topologies import topology_st as topo
from lib389.idm.user import UserAccount, UserAccounts
from lib389.idm.organizationalunit import OrganizationalUnit, OrganizationalUnits
from lib389.index import Index
from lib389.idm.account import Accounts
import ldap
GIVEN_NAME = 'cn=givenname,cn=index,cn=userRoot,cn=ldbm database,cn=plugins,cn=config'
CN_NAME = 'cn=sn,cn=index,cn=userRoot,cn=ldbm database,cn=plugins,cn=config'
uniquemember = 'cn=uniquemember,cn=index,cn=userRoot,cn=ldbm database,cn=plugins,cn=config'
objectclass = 'cn=objectclass,cn=index,cn=userRoot,cn=ldbm database,cn=plugins,cn=config'
mail = 'cn=mail,cn=index,cn=userRoot,cn=ldbm database,cn=plugins,cn=config'
ACLG_OU = f'ou=ACLGroup,{DEFAULT_SUFFIX}'
NESG_OU = f'ou=nestedgroup, {DEFAULT_SUFFIX}'
LIST_OF_USER_ACCOUNTING = [
f"uid=Ted Morris, ou=Accounting,{DEFAULT_SUFFIX}",
f"uid=David Miller, ou=Accounting,{DEFAULT_SUFFIX}",
f"uid=Gern Farmer, ou=Accounting,{DEFAULT_SUFFIX}",
f"uid=Judy Wallace, ou=Accounting,{DEFAULT_SUFFIX}",
f"uid=Marcus Ward, ou=Accounting,{DEFAULT_SUFFIX}",
f"uid=Judy McFarland, ou=Accounting,{DEFAULT_SUFFIX}",
f"uid=Anuj Hall, ou=Accounting,{DEFAULT_SUFFIX}",
f"uid=Gern Triplett, ou=Accounting,{DEFAULT_SUFFIX}",
f"uid=Emanuel Johnson, ou=Accounting,{DEFAULT_SUFFIX}",
f"uid=Brad Walker, ou=Accounting,{DEFAULT_SUFFIX}",
f"uid=Tobias Pierce, ou=Accounting,{DEFAULT_SUFFIX}",
f"uid=Randy Mills, ou=Accounting,{DEFAULT_SUFFIX}",
f"uid=David Thorud, ou=Accounting,{DEFAULT_SUFFIX}",
f"uid=Elba Kohler, ou=Accounting,{DEFAULT_SUFFIX}",
f"uid=Laurel Campbell, ou=Accounting,{DEFAULT_SUFFIX}",
f"uid=Torrey Schneider, ou=Accounting,{DEFAULT_SUFFIX}",
f"uid=Paula Rose, ou=Accounting,{DEFAULT_SUFFIX}",
f"uid=Frank Albers, ou=Accounting,{DEFAULT_SUFFIX}",
f"uid=Martin Schneider, ou=Accounting,{DEFAULT_SUFFIX}",
f"uid=Andrew Hel, ou=Accounting,{DEFAULT_SUFFIX}",
f"uid=Pete Tyler, ou=Accounting,{DEFAULT_SUFFIX}",
f"uid=Randy Ulrich, ou=Accounting,{DEFAULT_SUFFIX}",
f"uid=Richard Francis, ou=Accounting,{DEFAULT_SUFFIX}",
f"uid=Morgan White, ou=Accounting,{DEFAULT_SUFFIX}",
f"uid=Anuj Maddox, ou=Accounting,{DEFAULT_SUFFIX}",
f"uid=Jody Jensen, ou=Accounting,{DEFAULT_SUFFIX}",
Re: How to submit Root CA to ship with Fedora
On Wed, 2019-04-24 at 09:15 +0200, Dominik 'Rathann' Mierzejewski wrote: > Hi, > > On Wednesday, 24 April 2019 at 08:05, Danishka Navin wrote: > > Sri Lanka Cert is gonna implement local Root CA. > > How we can submit this Root CA with Fedora? > > > > I could not find enough information on this. > > The best path would be to get it included in Mozilla's root CA trust > store, which Fedora consumes. It is not just the best path but basically it is the only path. Fedora does not maintain its own list of trusted root CA but it directly consumes the Mozilla's list. -- Tomáš Mráz No matter how far down the wrong road you've gone, turn back. Turkish proverb [You'll know whether the road is wrong if you carefully listen to your conscience.] ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Can we maybe reduce the set of packages we install by default a bit?
On Thu, Apr 18, 2019 at 10:23 AM Lennart Poettering wrote: > Sure, you can invoke rngd before systemd, in which case it would have > to be able to run as PID 1 itself pretty much and then hand over > things. > > But why do that in userspace at all? the "Trust CPU RNG" kernel > compile time option shows that these things are trivial to solve if > people just want to. Instead of involving rngd at all, why not add a > similar option for the TPM RNG (or any other non-CPU hw rng) and then > rngd doesn't do anything useful anymore whatsoever? I mean, to my > knowledge all those other RNGs already feed into the pool anyway, they > just don't get trusted and thus don't add to the entropy > estimate. Fixing that should be quite doable and given that > CONFIG_RANDOM_TRUST_CPU exists now it shouldn't be politically too > hard to argue for a CONFIG_RANDOM_TRUST_TPM either... I like the part that this is trivial to solve if people want to. Making people agree is an order of magnitude harder than fixing any code. Nevertheless, without rngd, getrandom() would block in one of the first services started by systemd (if it doesn't block in systemd itself). The kernel option CONFIG_RANDOM_TRUST_CPU, is not portable so you'll need something more for non-x86. What rngd does that the kernel doesn't is a jitter entropy "subsystem" which will feed the kernel with random data, even when the hardware doesn't support something native. Can the jitter entropy gather be done by the kernel? It seems yes via the jitterentropy_rng module. So a combo of CONFIG_RANDOM_TRUST_CPU and the jitterentropy_rng may help in simplifying fedora (if people agree :). regards, Nikos ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: problem with rpm dependencies
Hi Miro, Tom, i have changed the spec file, now you can install the package. Can you have a look again to the spec file, if it is ok ? [1] https://martinkg.fedorapeople.org/Packages/mlt/mlt.spec Regards Martin ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: FF v dnf needs-restarting
On Wed, Apr 24, 2019 at 9:20 AM Dominik 'Rathann' Mierzejewski < domi...@greysector.net> wrote: > > Last time I used tracer, it had several issues. It was breaking > dist-upgrades and hogged the CPU for tens of seconds after the dnf > transaction was done. needs-restarting can be run after multiple > dnf updates. > > Is it better nowadays? > Tracer seems pretty fast now. It also seems pretty reliable (compared to needs-restarting, which sometimes shows bogus processes, and sometimes doesn't show processes which tracer identified correctly). ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: How to submit Root CA to ship with Fedora
On Wed, Apr 24, 2019 at 12:46 PM Dominik 'Rathann' Mierzejewski < domi...@greysector.net> wrote: > Hi, > > On Wednesday, 24 April 2019 at 08:05, Danishka Navin wrote: > > Sri Lanka Cert is gonna implement local Root CA. > > How we can submit this Root CA with Fedora? > > > > I could not find enough information on this. > > The best path would be to get it included in Mozilla's root CA trust > store, which Fedora consumes. > Thanks Dominik. I have already a passwed relavent information and asked to create a ticket against NSS product and 'CA Certificate Root Program' component. > https://wiki.mozilla.org/CA/Application_Process > > > https://blog.mozilla.org/security/2019/02/14/why-does-mozilla-maintain-our-own-root-certificate-store/ > > https://apps.fedoraproject.org/packages/ca-certificates/ > > https://fedoraproject.org/wiki/CA-Certificates > > Regards, > Dominik > -- > Fedora https://getfedora.org | RPM Fusion http://rpmfusion.org > There should be a science of discontent. People need hard times and > oppression to develop psychic muscles. > -- from "Collected Sayings of Muad'Dib" by the Princess Irulan > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > -- Danishka Navin http://danishkanavin.blogspot.com http://twitter.com/danishkanavin ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: problem with rpm dependencies
On 24/04/2019 09:25, Martin Gansser wrote: Hi, I'm trying to create a package for mlt-6.14.0, but during installation I get the following error: # rpm -Uvh /home/martin/rpmbuild/RPMS/x86_64/mlt-6.14.0-1.fc30.x86_64.rpm /home/martin/rpmbuild/RPMS/x86_64/python3-mlt-6.14.0-1.fc30.x86_64.rpm /home/martin/rpmbuild/RPMS/x86_64/mlt-devel-6.14.0-1.fc30.x86_64.rpm error: Failed dependencies: mlt(x86-64) = 6.12.0-7.fc30 is needed by (installed) python2-mlt-6.12.0-7.fc30.x86_64 the following old version is installed: # rpm -qa |grep mlt mlt-6.12.0-7.fc30.x86_64 mlt-devel-6.12.0-7.fc30.x86_64 python2-mlt-6.12.0-7.fc30.x86_64 how can i solve this in the rpm spec file [1] ? Obsoletes: python2-mlt < 6.12.0-8 See: https://docs.fedoraproject.org/en-US/packaging-guidelines/#renaming-or-replacing-existing-packages Tom -- Tom Hughes (t...@compton.nu) http://compton.nu/ ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: problem with rpm dependencies
On 24. 04. 19 10:25, Martin Gansser wrote: Hi, I'm trying to create a package for mlt-6.14.0, but during installation I get the following error: # rpm -Uvh /home/martin/rpmbuild/RPMS/x86_64/mlt-6.14.0-1.fc30.x86_64.rpm /home/martin/rpmbuild/RPMS/x86_64/python3-mlt-6.14.0-1.fc30.x86_64.rpm /home/martin/rpmbuild/RPMS/x86_64/mlt-devel-6.14.0-1.fc30.x86_64.rpm error: Failed dependencies: mlt(x86-64) = 6.12.0-7.fc30 is needed by (installed) python2-mlt-6.12.0-7.fc30.x86_64 the following old version is installed: # rpm -qa |grep mlt mlt-6.12.0-7.fc30.x86_64 mlt-devel-6.12.0-7.fc30.x86_64 python2-mlt-6.12.0-7.fc30.x86_64 how can i solve this in the rpm spec file [1] ? Add to the main package: Obsoletes: python2-mlt < 6.14.0-1 Obsoletes: mlt-python < 6.14.0-1 (Keep the version-release hardcoded, don't use macros). -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
PWG f2f - Lexington 2019 - report
Hi! I attended PWG (printing working group) f2f vie Webex last week (I attended one and half day of conference). It was held in Lexington this year and you can find by full report in the attachment. The main new (in comparison to previous year) points were: 1) CUPS license issue is coming to the solution - CUPS 2.3 will stay under new Apache License 2.0 and it will have exception like LLVM does for GPL2 only programs. Security fixes and other important fixes (if you want something to backport to 2.2.x, create an issue at cups github for backporting that specific patch) will stay under old license. But there is still open issue about it, so I would delay rebasing CUPS to 2.3 in Fedora rawhide until final outcome exists. 2) ippeveprinter binary came into CUPS master branch - the purpose of the binary is to be kind-of wrapper around PCL or Postscript printers, makes them visible for Avahi (preferred way of sharing printers since cca 2012) and process received document to wanted data for printer. You can check the code and try it from CUPS master branch. 3) Several projects of Openprinting+PWG were announced in Google Summer of Code 2019 - the main project is creating API for writing Printer Applications, I will mentor one small project - convert scp-dbus-service.py into C, since printing sw is mainly written in C. -- Zdenek Dohnal Software Engineer Red Hat Czech - Brno TPB-C PWG 2019 PWG plenary -- - ipp eve certified printers - now 365! - new versions of IPP eve - 1.1 and IPP eve selfcert - 1.1 - new project - ipp registry - imaging device security - security of hardcopy devices -focus on common criteria profiles for HCD - ipp workgroup - maintenance of IPP, support of network archs in IPP - IPP enterprise printing extension 1.0? - trusted computing group - specifications for mobile platforms and trusted mobility solutions - IETF - RFC for new TLS-1.3, security automation and continuous monitoring drafts - openprinting - new gsoc projects (Zdenek Dohnal is one of the mentors) - test script for IPP errata and IPP system service, printer app from legacy driver, improve pdftoraster filter, turn scp-dbus-service into C, new website - mopria - print and scanning services for mobiles - 3D printing Openprinting plenary - CUPS-filters - no new features, focus on reliability, pdftoopvp and pdftoijs deprecated, in the future remove CUPS PPD API, treat equal IPP printers and remote cups queues as equal - IPP system service - future - support for MFD and printers+possible driverless MFD and scan - GSoC projects CUPS plenary - licensing - report important issues for backporting to older CUPS with old license, security fixes will be still with old license, APACHE 2.0 otherwise - CUPS-2.3.0 - focus on license change, ipp eve, print accounting, scheduler - the last release with printer driver support (2021) - they will have exception for GPL2/LGPL2-only sw (same as LLVM) - ipp eve - localizations, job preset, finishing-template support, closing any CUPS API holes preventing of usage of ipp eve - print accounting - track total number of pages at the end of job - scheduler - sharing hostname can be set, .strings file is created when printer is created - for localization, support for printer id and no hardcoded script interpreters in CGI - API - new function for adding media options - cupsAddDestMediaOptions(), encoding IPP attr from CUPS options - cupsEncodeOption, -D_IPP_PRIVATE_STRUCTURES=1 does not work, -D_PPD_DEPRECATED="" does not work :) - FUTURE: Modular cups with following modules: commands, local server handles print requests on local temporary queues, cups sharing server handles network print requests (acounting, Acl, pam auth, oauth2 ipp shared infrastructure) with permanent CUPS queues, CUPS library, oauth 2.0 as replacement for Kerberos (does not need root access) - printer apps - printer drivers will look as ipp eve - ipp eve printer - replacement of ippserver, two commands - PCL printers ippevepcl - like PCL laser printer bundled with CUPS, ippeveps for postscript printers (runs pdftops and specific filters), use with PPD file - output from commands can be sent to AppSocket or spool dir - why? wonderful for debugging for now! just get PPD and create ippeve printer by it - FUTURE ippeveprinter vs ippserver - single ipp eve printer vs implements ipp system service with multiple IPP printers (print commands for ippserver will work for ippeveprinter, but not otherwise because missing backends and filters) Openprinting projects update - - 2018 - conversion bannertopdf to QPDF, enhancement ipptool (new support for attributes and operations), ippdoclint program (check-up if pwg raster document file is correct - structure, content), content-oriented printer auto-selection (cluster abritary collection of printers into one queue with merghed PPD with all options
problem with rpm dependencies
Hi, I'm trying to create a package for mlt-6.14.0, but during installation I get the following error: # rpm -Uvh /home/martin/rpmbuild/RPMS/x86_64/mlt-6.14.0-1.fc30.x86_64.rpm /home/martin/rpmbuild/RPMS/x86_64/python3-mlt-6.14.0-1.fc30.x86_64.rpm /home/martin/rpmbuild/RPMS/x86_64/mlt-devel-6.14.0-1.fc30.x86_64.rpm error: Failed dependencies: mlt(x86-64) = 6.12.0-7.fc30 is needed by (installed) python2-mlt-6.12.0-7.fc30.x86_64 the following old version is installed: # rpm -qa |grep mlt mlt-6.12.0-7.fc30.x86_64 mlt-devel-6.12.0-7.fc30.x86_64 python2-mlt-6.12.0-7.fc30.x86_64 how can i solve this in the rpm spec file [1] ? [1] https://martinkg.fedorapeople.org/Packages/mlt/mlt.spec Regards Martin ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Modularity component ref: behavior
Dne 23. 04. 19 v 18:14 Stephen Gallagher napsal(a): > It is not mentioned anywhere in the official packager documentation, > but the modulemd format for packages includes a default[1] for the > `ref:` attribute of RPM components. Essentially, if you leave the > `ref:` out of the YAML, the Module Build Service will interpret that > as a reference to the HEAD of the `master` branch in the git > repository. > > Recently, Vit Ondruch raised a request[2] that we change this behavior > such that instead of matching `master`, it should instead reference > the HEAD of a branch of that component that matches a prefixed branch > of the module. > > So, for example, if we were building the `nodejs:10` module stream, if we had: > ``` > data: > ... > components: > nodejs: > rationale: Javascript runtime and npm package manager. > buildorder: 10 > ``` > (lacking a `ref:`) > > This would be interpreted as `ref: stream-nodejs-10` instead of `ref: > master`, as now. And I also proposed fallback to master when no matching branch is found. > > > In today's Modularity Working Group Meeting[3], those present > generally agreed that this was a better approach and lends itself to a > better packager experience. We did not, however, come to an agreement > on how to transition to this new default. When I was thinking about the migration, it always felt natural to me to bump the module metadata version and treat the ref differently by the version. Vít > > There are two possible approaches we can take: > 1) Allow MBS to look first for the branch of the component matching > the module stream (`stream-nodejs-master`) and then fall back to > 'master'. > 2) Interrogate all of the modules in Fedora, migrate any components > missing a `ref:` explicitly to be `ref: master`, then change MBS to > treat the unset value as above. > > Arguments for 1) are that it won't break backwards-compatibility, but > on the other hand it could lead to subtle misbehavior, such as if MBS > did a shallow or otherwise incomplete `git clone` that misses the > proper branch. > > Arguments for 2) are that it lends itself to hard failures, forcing > packagers to correct their YAML documents, at the cost of some (as yet > unspecced) initial effort. > > > So I'm asking for opinions on which route we should take. > > > [1] > https://github.com/fedora-modularity/libmodulemd/blob/master/spec.v2.yaml#L270 > [2] https://github.com/fedora-modularity/libmodulemd/issues/269 > [3] > https://meetbot.fedoraproject.org/fedora-meeting-3/2019-04-23/modularity.2019-04-23-15.01.log.html ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
[Bug 1702366] perl-Storable-3.15 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1702366 Petr Pisar changed: What|Removed |Added Status|ASSIGNED|MODIFIED Fixed In Version||perl-Storable-3.15-1.fc31 --- Comment #1 from Petr Pisar --- A bug-fix release suitable for all Fedoras. -- You are receiving this mail because: You are on the CC list for the bug. ___ 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://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
F30 updates that need karma
I was looking at the F30final blockerlist, and there's a few updates that could use more testing: Bug https://bugzilla.redhat.com/show_bug.cgi?id=1701012 (meson execstack issue): https://bodhi.fedoraproject.org/updates/FEDORA-2019-37efac3628 for switchboard-plug-mouse-touchpad https://bodhi.fedoraproject.org/updates/FEDORA-2019-6241dc4fc3 for switchboard-plug-bluetooth https://bodhi.fedoraproject.org/updates/FEDORA-2019-88abfa74cb for cutter-re and radare2 https://bodhi.fedoraproject.org/updates/FEDORA-2019-83c33a90d2 for elementary-photos https://bodhi.fedoraproject.org/updates/FEDORA-2019-2a13be4497 for dippi Bug https://bugzilla.redhat.com/show_bug.cgi?id=1699852 (httpcomponents-client upgrade): https://bodhi.fedoraproject.org/updates/FEDORA-MODULAR-2019-dd28e893bc for maven:3.5 Bugs https://bugzilla.redhat.com/show_bug.cgi?id=1660597 (sugar Neighbourhood view missing buddies with collaboration server in Fedora 29 and later) and https://bugzilla.redhat.com/show_bug.cgi?id=1701593 (another collaboration issue): https://bodhi.fedoraproject.org/updates/FEDORA-2019-98a501f843 Bug https://bugzilla.redhat.com/show_bug.cgi?id=1697591 (modesetting driver on some Intel hardware fails to start after kernel 4.20.13 update): https://bodhi.fedoraproject.org/updates/FEDORA-2019-e84f6c34da for kernel Please give 'em some karma love. Zbyszek ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
[Bug 1702578] New: Upgrade perl-Net-CLI-Interact to 2.300003
https://bugzilla.redhat.com/show_bug.cgi?id=1702578 Bug ID: 1702578 Summary: Upgrade perl-Net-CLI-Interact to 2.33 Product: Fedora Version: rawhide Status: NEW Component: perl-Net-CLI-Interact Assignee: negativ...@gmail.com Reporter: jples...@redhat.com QA Contact: extras...@fedoraproject.org CC: negativ...@gmail.com, perl-devel@lists.fedoraproject.org Target Milestone: --- Classification: Fedora Latest Fedora delivers 2.32 version. Upstream released 2.33. When you have free time, please upgrade it. -- You are receiving this mail because: You are on the CC list for the bug. ___ 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://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
[Bug 1702577] New: Upgrade perl-Net-Appliance-Session to 4.300005
https://bugzilla.redhat.com/show_bug.cgi?id=1702577 Bug ID: 1702577 Summary: Upgrade perl-Net-Appliance-Session to 4.35 Product: Fedora Version: rawhide Status: NEW Component: perl-Net-Appliance-Session Assignee: negativ...@gmail.com Reporter: jples...@redhat.com QA Contact: extras...@fedoraproject.org CC: negativ...@gmail.com, perl-devel@lists.fedoraproject.org Target Milestone: --- Classification: Fedora Latest Fedora delivers 4.31 version. Upstream released 4.35. When you have free time, please upgrade it. -- You are receiving this mail because: You are on the CC list for the bug. ___ 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://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
Re: FF v dnf needs-restarting
On Tuesday, 23 April 2019 at 09:29, Miroslav Suchý wrote: > Dne 17. 04. 19 v 9:54 Kamil Paral napsal(a): > > The question is which tool is correct. My current guess is tracer. > > +1 > needs-restarting is very simple plugin. Tracer [1] is more > sophisticated and I encourage everyone to use Tracer instead of > needs-restarting. Last time I used tracer, it had several issues. It was breaking dist-upgrades and hogged the CPU for tens of seconds after the dnf transaction was done. needs-restarting can be run after multiple dnf updates. Is it better nowadays? Regards, Dominik -- Fedora https://getfedora.org | RPM Fusion http://rpmfusion.org There should be a science of discontent. People need hard times and oppression to develop psychic muscles. -- from "Collected Sayings of Muad'Dib" by the Princess Irulan ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
[Bug 1701068] perl-Clipboard-0.20 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1701068 Jitka Plesnikova changed: What|Removed |Added Status|NEW |CLOSED CC||jples...@redhat.com Fixed In Version||perl-Clipboard-0.20-1.fc31 Resolution|--- |RAWHIDE Last Closed||2019-04-24 07:19:27 -- You are receiving this mail because: You are on the CC list for the bug. ___ 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://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
Re: How to submit Root CA to ship with Fedora
Hi, On Wednesday, 24 April 2019 at 08:05, Danishka Navin wrote: > Sri Lanka Cert is gonna implement local Root CA. > How we can submit this Root CA with Fedora? > > I could not find enough information on this. The best path would be to get it included in Mozilla's root CA trust store, which Fedora consumes. https://wiki.mozilla.org/CA/Application_Process https://blog.mozilla.org/security/2019/02/14/why-does-mozilla-maintain-our-own-root-certificate-store/ https://apps.fedoraproject.org/packages/ca-certificates/ https://fedoraproject.org/wiki/CA-Certificates Regards, Dominik -- Fedora https://getfedora.org | RPM Fusion http://rpmfusion.org There should be a science of discontent. People need hard times and oppression to develop psychic muscles. -- from "Collected Sayings of Muad'Dib" by the Princess Irulan ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
[Bug 1696957] perl-Text-BibTeX-0.87 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1696957 Jitka Plesnikova changed: What|Removed |Added Status|NEW |CLOSED CC||jples...@redhat.com Fixed In Version||perl-Text-BibTeX-0.87-1.fc3 ||1 Resolution|--- |RAWHIDE Last Closed||2019-04-24 07:02:20 -- You are receiving this mail because: You are on the CC list for the bug. ___ 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://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
