[EPEL-devel] Fedora EPEL 7 updates-testing report
The following Fedora EPEL 7 Security updates need testing: Age URL 63 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2021-1f259a45ef openjpeg2-2.3.1-11.el7 5 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2021-edab6b43f2 seamonkey-2.53.8.1-1.el7 The following builds have been pushed to Fedora EPEL 7 updates-testing dmlite-1.15.0-7.el7 qpid-proton-0.34.0-2.el7 sympa-6.2.64-1.el7 Details about builds: dmlite-1.15.0-7.el7 (FEDORA-EPEL-2021-bc7588bbe1) Lcgdm grid data management and storage framework Update Information: Fix interoperability issue using older dmlite version on headnode and newer on disknode(s) Minor bugfixes for 1.15.0 release. ChangeLog: * Thu Jul 29 2021 Petr Vokac - 1.15.0-7 - fix interoperability with older dmlite releases * Fri Jul 23 2021 Petr Vokac - 1.15.0-6 - Minor bugfixes - Puppet modules version updated * Wed Jul 21 2021 Fedora Release Engineering - 1.15.0-5 - Rebuilt for https://fedoraproject.org/wiki/Fedora_35_Mass_Rebuild qpid-proton-0.34.0-2.el7 (FEDORA-EPEL-2021-e083b5011a) A high performance, lightweight messaging library Update Information: Updated dependency for python2-qpid-proton package. ChangeLog: * Thu Jul 29 2021 Irina Boverman - 0.34.0-2 - Updated python2-qpid-proton sympa-6.2.64-1.el7 (FEDORA-EPEL-2021-ab2510229f) Powerful multilingual List Manager Update Information: See https://github.com/sympa-community/sympa/blob/6.2.64/NEWS.md for details ChangeLog: * Thu Jul 15 2021 Xavier Bachelot 6.2.64-1 - Update to 6.2.64 - Fix jquery-ui unbundling - Add 2 upstream patches ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[Bug 1814107] Please make perl-Text-Iconv available on EPEL8
https://bugzilla.redhat.com/show_bug.cgi?id=1814107 Fedora Update System changed: What|Removed |Added Status|ON_QA |CLOSED Fixed In Version||perl-Text-Iconv-1.7-42.el8 Resolution|--- |ERRATA Last Closed||2021-07-30 00:33:08 --- Comment #8 from Fedora Update System --- FEDORA-EPEL-2021-3d5f3e02ff has been pushed to the Fedora EPEL 8 stable repository. If problem still persists, 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://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[Bug 1981927] APC::ThreadMutex is not available on x86_64 mod_perl
https://bugzilla.redhat.com/show_bug.cgi?id=1981927 Fedora Update System changed: What|Removed |Added Fixed In Version|mod_perl-2.0.11-9.fc35 |mod_perl-2.0.11-9.fc35 |mod_perl-2.0.11-8.fc34 |mod_perl-2.0.11-8.fc34 |mod_perl-2.0.11-7.fc33 |mod_perl-2.0.11-7.fc33 ||mod_perl-2.0.11-4.el8 --- Comment #10 from Fedora Update System --- FEDORA-EPEL-2021-813118785a has been pushed to the Fedora EPEL 8 stable repository. If problem still persists, 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://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: f35 check rpaths failure - false trigger?
Update: the appears to only be an issue with the aarch64 build so that explains why I can't duplicate it on my x86_64 machine. Looking closer at the aarch64 build output, reveals the rpath is being inserted via libtool: /bin/sh ../libtool --tag=CXX --mode=link g++ -O2 -flto=auto -ffat-lto-objects -fexceptions -g -grecord-gcc-switches -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -fstack-protector-strong -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -mbranch-protection=standard -fasynchronous-unwind-tables -fstack-clash-protection -Wl,-z,relro -Wl,--as-needed -Wl,-z,now -specs=/usr/lib/rpm/redhat/redhat-hardened-ld -o libfcgi++.la -lfcgi -rpath /usr/lib64 fcgio.lo Following the rpath removal steps for libtool, solves the issue and fcgi now builds on all arches: %configure sed -i 's|^hardcode_libdir_flag_spec=.*|hardcode_libdir_flag_spec=""|g' libtool sed -i 's|^runpath_var=LD_RUN_PATH|runpath_var=DIE_RPATH_DIE|g' libtool ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
f35 check rpaths failure - false trigger?
The fgci package I maintain is failing the rpath check: ERROR 0001: file '/usr/lib64/libfcgi++.so.0.0.0' contains a standard '/usr/lib64' in [/usr/lib64] ERROR 0001: file '/usr/bin/cgi-fcgi' contains a standard '/usr/lib64' in [/usr/lib64] New policy change is documented well here: https://fedoraproject.org/wiki/Changes/Broken_RPATH_will_fail_rpmbuild And what to do about it is documented here: https://docs.fedoraproject.org/en-US/packaging-guidelines/#_beware_of_rpath Make sense. I went and followed the following steps to duplicate the problem on my local machine: https://fedoraproject.org/wiki/Changes/Broken_RPATH_will_fail_rpmbuild#How_To_Test The build finished with no errors, which seemed odd. I then checked the binary rpm with these commands: rpmlint -c BinariesCheck /var/lib/mock/fedora-rawhide-x86_64/result/fcgi-2.4.0-39.fc35.x86_64.rpm rpminspect-fedora --tests runpath /var/lib/mock/fedora-rawhide-x86_64/result/fcgi-2.4.0-39.fc35.x86_64.rpm ...both tests passed with no errors?!?! So is this a false trigger, or am I doing this wrong? I am interested in doing this the right way, rather than just exclude the rpath test from the build, without knowing what the real issue is. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Package requests: mingw-glfw, gtkmm-4
Am 29.07.21 um 12:42 schrieb Sandro Mani: mingw packages are dedicated like any other packages, with a respecitve maintainer. Though there was some initiative in March 2021 of building (some?) mingw packages directly from the regular linux specs. Not sure if something happened there: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/FR5OEMAIROHKECQB2NGLMMXQGG7IQMHM/ Felix PS: I'd like thank all mingw packagers in Fedora. I'm actively using it to cross-compile an in-house Windows application with Linux. Not having to use Windows for development is really a time saver :-) ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Fedora-IoT-35-20210729.0 compose check report
No missing expected images. Failed openQA tests: 1/15 (aarch64) Old failures (same test failed in Fedora-IoT-35-20210728.0): ID: 937902 Test: aarch64 IoT-dvd_ostree-iso iot_clevis@uefi URL: https://openqa.fedoraproject.org/tests/937902 Soft failed openQA tests: 3/16 (x86_64), 1/15 (aarch64) (Tests completed, but using a workaround for a known bug) Old soft failures (same test soft failed in Fedora-IoT-35-20210728.0): ID: 937881 Test: x86_64 IoT-dvd_ostree-iso install_default@uefi URL: https://openqa.fedoraproject.org/tests/937881 ID: 937882 Test: x86_64 IoT-dvd_ostree-iso install_default_upload URL: https://openqa.fedoraproject.org/tests/937882 ID: 937885 Test: x86_64 IoT-dvd_ostree-iso iot_clevis URL: https://openqa.fedoraproject.org/tests/937885 ID: 937897 Test: aarch64 IoT-dvd_ostree-iso install_default_upload@uefi URL: https://openqa.fedoraproject.org/tests/937897 Passed openQA tests: 13/15 (aarch64), 13/16 (x86_64) New passes (same test not passed in Fedora-IoT-35-20210728.0): ID: 937905 Test: aarch64 IoT-dvd_ostree-iso iot_zezere_server@uefi URL: https://openqa.fedoraproject.org/tests/937905 ID: 937911 Test: aarch64 IoT-dvd_ostree-iso iot_zezere_ignition@uefi URL: https://openqa.fedoraproject.org/tests/937911 Installed system changes in test x86_64 IoT-dvd_ostree-iso install_default@uefi: Used mem changed from 191 MiB to 218 MiB Previous test data: https://openqa.fedoraproject.org/tests/936947#downloads Current test data: https://openqa.fedoraproject.org/tests/937881#downloads Installed system changes in test x86_64 IoT-dvd_ostree-iso install_default_upload: Used mem changed from 186 MiB to 226 MiB Previous test data: https://openqa.fedoraproject.org/tests/936945#downloads Current test data: https://openqa.fedoraproject.org/tests/937882#downloads Installed system changes in test aarch64 IoT-dvd_ostree-iso install_default_upload@uefi: Used mem changed from 184 MiB to 208 MiB System load changed from 0.43 to 0.54 Previous test data: https://openqa.fedoraproject.org/tests/936961#downloads Current test data: https://openqa.fedoraproject.org/tests/937897#downloads -- Mail generated by check-compose: https://pagure.io/fedora-qa/check-compose ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[Bug 1987801] perl-POE: FTBFS in Fedora rawhide/f35
https://bugzilla.redhat.com/show_bug.cgi?id=1987801 --- Comment #2 from Fedora Release Engineering --- Created attachment 1808296 --> https://bugzilla.redhat.com/attachment.cgi?id=1808296=edit root.log file root.log too big, will only attach last 32768 bytes -- 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://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[Bug 1987801] New: perl-POE: FTBFS in Fedora rawhide/f35
https://bugzilla.redhat.com/show_bug.cgi?id=1987801 Bug ID: 1987801 Summary: perl-POE: FTBFS in Fedora rawhide/f35 Product: Fedora Version: rawhide Status: NEW Component: perl-POE Assignee: mspa...@redhat.com Reporter: rel...@fedoraproject.org QA Contact: extras...@fedoraproject.org CC: mspa...@redhat.com, perl-devel@lists.fedoraproject.org, steve.tray...@cern.ch Blocks: 1927309 (F35FTBFS,RAWHIDEFTBFS) Target Milestone: --- Classification: Fedora perl-POE failed to build from source in Fedora rawhide/f35 https://koji.fedoraproject.org/koji/taskinfo?taskID=72438396 For details on the mass rebuild see: https://fedoraproject.org/wiki/Fedora_35_Mass_Rebuild Please fix perl-POE at your earliest convenience and set the bug's status to ASSIGNED when you start fixing it. If the bug remains in NEW state for 8 weeks, perl-POE will be orphaned. Before branching of Fedora 36, perl-POE will be retired, if it still fails to build. For more details on the FTBFS policy, please visit: https://docs.fedoraproject.org/en-US/fesco/Fails_to_build_from_source_Fails_to_install/ Referenced Bugs: https://bugzilla.redhat.com/show_bug.cgi?id=1927309 [Bug 1927309] Fedora 35 FTBFS Tracker -- 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://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[Bug 1987798] New: perl-GnuPG-Interface: FTBFS in Fedora rawhide/f35
https://bugzilla.redhat.com/show_bug.cgi?id=1987798 Bug ID: 1987798 Summary: perl-GnuPG-Interface: FTBFS in Fedora rawhide/f35 Product: Fedora Version: rawhide Status: NEW Component: perl-GnuPG-Interface Assignee: emman...@seyman.fr Reporter: rel...@fedoraproject.org QA Contact: extras...@fedoraproject.org CC: emman...@seyman.fr, fed...@mj41.cz, perl-devel@lists.fedoraproject.org, xav...@bachelot.org Blocks: 1927309 (F35FTBFS,RAWHIDEFTBFS) Target Milestone: --- Classification: Fedora perl-GnuPG-Interface failed to build from source in Fedora rawhide/f35 https://koji.fedoraproject.org/koji/taskinfo?taskID=72429035 For details on the mass rebuild see: https://fedoraproject.org/wiki/Fedora_35_Mass_Rebuild Please fix perl-GnuPG-Interface at your earliest convenience and set the bug's status to ASSIGNED when you start fixing it. If the bug remains in NEW state for 8 weeks, perl-GnuPG-Interface will be orphaned. Before branching of Fedora 36, perl-GnuPG-Interface will be retired, if it still fails to build. For more details on the FTBFS policy, please visit: https://docs.fedoraproject.org/en-US/fesco/Fails_to_build_from_source_Fails_to_install/ Referenced Bugs: https://bugzilla.redhat.com/show_bug.cgi?id=1927309 [Bug 1927309] Fedora 35 FTBFS Tracker -- 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://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[Bug 1987798] perl-GnuPG-Interface: FTBFS in Fedora rawhide/f35
https://bugzilla.redhat.com/show_bug.cgi?id=1987798 --- Comment #1 from Fedora Release Engineering --- Created attachment 1808286 --> https://bugzilla.redhat.com/attachment.cgi?id=1808286=edit build.log -- 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://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: systemd-oomd blows away the gnome-shell desktop session
related: systemd-oomd kills the whole session if it's started from console https://bugzilla.redhat.com/show_bug.cgi?id=1933494 ср, 28 июл. 2021 г. в 10:28, David Airlie : > > Hi, > > I've been using f34 with gnome/wayland session on a 16MB machine which > has 8GB zram swap configured. > > If I build anything large inside my desktop environment (llvm/clang) > from a gnome-terminal, systemd-oomd blows away my whole desktop slice. > This seems overly hostile. > > Now in theory I can use systemd-run to run a shell but my > understanding is the DE is meant to be smarter here. > > Is it at least launching firefox etc in new cgroups or are all > processes on my desktop in one big cgroup? > > Even if it launched gnome-terminal in another group I assume this > would result in it blowing away all my open terminals just to kill the > compiler/linker that is consuming all the RAM/swap. Again this seems > overly hostile. > > Any ideas other than campaigning for systemd-oomd to be turned off again? > > Dave. > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > Do not reply to spam on the list, report it: > https://pagure.io/fedora-infrastructure ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Fedora-Rawhide-20210729.n.0 compose check report
No missing expected images. Compose FAILS proposed Rawhide gating check! 1 of 43 required test results missing Unsatisfied gating requirements that could not be mapped to openQA tests: MISSING: fedora.Cloud_Base-qcow2-qcow2.x86_64.64bit - compose.cloud_autocloud Failed openQA tests: 9/203 (x86_64), 8/139 (aarch64) New failures (same test not failed in Fedora-Rawhide-20210728.n.3): ID: 937550 Test: x86_64 Server-dvd-iso install_blivet_standard_partition_ext4@uefi URL: https://openqa.fedoraproject.org/tests/937550 ID: 937615 Test: x86_64 Workstation-live-iso evince URL: https://openqa.fedoraproject.org/tests/937615 ID: 937638 Test: x86_64 KDE-live-iso desktop_update_graphical URL: https://openqa.fedoraproject.org/tests/937638 ID: 937648 Test: x86_64 Silverblue-dvd_ostree-iso desktop_browser URL: https://openqa.fedoraproject.org/tests/937648 ID: 937651 Test: x86_64 Silverblue-dvd_ostree-iso evince URL: https://openqa.fedoraproject.org/tests/937651 ID: 937680 Test: aarch64 Server-dvd-iso anaconda_help@uefi URL: https://openqa.fedoraproject.org/tests/937680 ID: 937728 Test: aarch64 Workstation-raw_xz-raw.xz install_arm_image_deployment_upload@uefi URL: https://openqa.fedoraproject.org/tests/937728 ID: 937767 Test: x86_64 universal support_server URL: https://openqa.fedoraproject.org/tests/937767 ID: 937804 Test: x86_64 universal install_iscsi URL: https://openqa.fedoraproject.org/tests/937804 ID: 937840 Test: aarch64 universal support_server@uefi URL: https://openqa.fedoraproject.org/tests/937840 ID: 937862 Test: aarch64 universal install_iscsi@uefi URL: https://openqa.fedoraproject.org/tests/937862 ID: 937863 Test: aarch64 universal install_repository_http_variation@uefi URL: https://openqa.fedoraproject.org/tests/937863 ID: 937867 Test: aarch64 universal install_multi_empty@uefi URL: https://openqa.fedoraproject.org/tests/937867 ID: 937878 Test: aarch64 universal install_mirrorlist_graphical@uefi URL: https://openqa.fedoraproject.org/tests/937878 Old failures (same test failed in Fedora-Rawhide-20210728.n.3): ID: 937631 Test: x86_64 KDE-live-iso apps_startstop URL: https://openqa.fedoraproject.org/tests/937631 ID: 937761 Test: x86_64 universal memtest URL: https://openqa.fedoraproject.org/tests/937761 ID: 937855 Test: aarch64 universal install_asian_language@uefi URL: https://openqa.fedoraproject.org/tests/937855 Soft failed openQA tests: 22/203 (x86_64), 17/139 (aarch64) (Tests completed, but using a workaround for a known bug) Old soft failures (same test soft failed in Fedora-Rawhide-20210728.n.3): ID: 937536 Test: x86_64 Server-boot-iso install_default URL: https://openqa.fedoraproject.org/tests/937536 ID: 937537 Test: x86_64 Server-boot-iso install_default@uefi URL: https://openqa.fedoraproject.org/tests/937537 ID: 937594 Test: x86_64 Everything-boot-iso install_default URL: https://openqa.fedoraproject.org/tests/937594 ID: 937595 Test: x86_64 Everything-boot-iso install_default@uefi URL: https://openqa.fedoraproject.org/tests/937595 ID: 937652 Test: x86_64 Cloud_Base-qcow2-qcow2 cloud_autocloud@uefi URL: https://openqa.fedoraproject.org/tests/937652 ID: 937662 Test: aarch64 Minimal-raw_xz-raw.xz install_arm_image_deployment_upload@uefi URL: https://openqa.fedoraproject.org/tests/937662 ID: 937671 Test: aarch64 Server-boot-iso install_default@uefi URL: https://openqa.fedoraproject.org/tests/937671 ID: 937719 Test: aarch64 Server-raw_xz-raw.xz install_arm_image_deployment_upload@uefi URL: https://openqa.fedoraproject.org/tests/937719 ID: 937748 Test: aarch64 Cloud_Base-qcow2-qcow2 cloud_autocloud@uefi URL: https://openqa.fedoraproject.org/tests/937748 ID: 937753 Test: x86_64 universal install_kickstart_firewall_configured URL: https://openqa.fedoraproject.org/tests/937753 ID: 937763 Test: x86_64 universal install_repository_http_variation URL: https://openqa.fedoraproject.org/tests/937763 ID: 937769 Test: x86_64 universal upgrade_2_minimal_64bit URL: https://openqa.fedoraproject.org/tests/937769 ID: 937771 Test: x86_64 universal install_kickstart_hdd URL: https://openqa.fedoraproject.org/tests/937771 ID: 937775 Test: x86_64 universal install_kickstart_user_creation URL: https://openqa.fedoraproject.org/tests/937775 ID: 937776 Test: x86_64 universal install_repository_http_graphical URL: https://openqa.fedoraproject.org/tests/937776 ID: 937791 Test: x86_64 universal upgrade_minimal_64bit URL: https://openqa.fedoraproject.org/tests/937791 ID: 937792 Test: x86_64 universal upgrade_minimal_uefi@uefi URL: https://openqa.fedoraproject.org/tests/937792 ID: 937793 Test: x86_64 universal install_kickstart_nfs URL: https://openqa.fedoraproject.org/tests/937793 ID: 937796 Test: x86_64 universal upgrade_2_minimal_uefi@uefi URL: https://openqa.fedoraproject.org/tests/937796 ID: 937797 Test: x86_64 universal
Re: Package requests: mingw-glfw, gtkmm-4
On Thursday, 29 July 2021 at 12:42, Sandro Mani wrote: > Hi > > mingw packages are dedicated like any other packages, with a respecitve > maintainer. If something is not packaged yet it's because well no-one did it > yet. If you want to package them, I'll happily review them. They can also be built as subpackages from the main package to avoid version discrepancy and maintainership can be shared if the Linux package maintainer doesn't want to/have knowledge about MinGW builds. 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://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: poppler soname bump in rawhide
On Mon, Jul 26, 2021 18:06:28 +0200, Marek Kasik wrote: > Hi, Hello, > I've prepared rebase of poppler to 21.07.0 in the side tag > "f35-build-side-43960". I'm asking you to build your dependent packages in > it and I will ask to merge it to main branch next Monday (2nd of August). > > There are several API changes and soname bump of the base library > libpoppler.so.*. > > If your package still uses the unstable API (headers from poppler-devel), > could you consider to change it to use a stable API (glib, qt5, C++)? It > would mean less work for you and I would be able to disable the unstable > API. pdfpc depends on poppler-glib but failed the mass rebuild so won't build in the side tag either. I'll look into it once the FTBFS bug has been filed and update accordingly. -- Thanks, Regards, Ankur Sinha "FranciscoD" (He / Him / His) | https://fedoraproject.org/wiki/User:Ankursinha Time zone: Europe/London signature.asc Description: PGP signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Fedora rawhide compose report: 20210729.n.0 changes
OLD: Fedora-Rawhide-20210728.n.3 NEW: Fedora-Rawhide-20210729.n.0 = SUMMARY = Added images:0 Dropped images: 2 Added packages: 4 Dropped packages:3 Upgraded packages: 262 Downgraded packages: 0 Size of added packages: 49.15 MiB Size of dropped packages:2.25 MiB Size of upgraded packages: 6.84 GiB Size of downgraded packages: 0 B Size change of upgraded packages: -69.39 MiB Size change of downgraded packages: 0 B = ADDED IMAGES = = DROPPED IMAGES = Image: Workstation raw-xz armhfp Path: Workstation/armhfp/images/Fedora-Workstation-Rawhide-20210728.n.3.armhfp.raw.xz Image: KDE raw-xz armhfp Path: Spins/armhfp/images/Fedora-KDE-Rawhide-20210728.n.3.armhfp.raw.xz = ADDED PACKAGES = Package: guile30-3.0.7-1.fc35 Summary: A GNU implementation of Scheme for application extensibility RPMs:guile30 guile30-devel Size:48.64 MiB Package: libxcvt-0.1.0-1.fc35 Summary: VESA CVT standard timing modelines generator RPMs:cvt libxcvt libxcvt-devel Size:200.85 KiB Package: python-tomli-1.0.4-1.fc35 Summary: A little TOML parser for Python RPMs:python3-tomli Size:26.56 KiB Package: snoopy-2.4.14-1.fc35 Summary: A preload library to send shell commands to syslog RPMs:snoopy Size:290.63 KiB = DROPPED PACKAGES = Package: python-flask-restplus-0.13.0-8.fc35 Summary: Framework for fast, easy and documented API development with Flask RPMs:python3-flask-restplus Size:1.56 MiB Package: python-glusterfs-api-1.2-11.fc35 Summary: Python bindings for GlusterFS libgfapi RPMs:python3-glusterfs-api Size:50.55 KiB Package: stax2-api-4.2.1-6.fc35 Summary: Experimental API extending basic StAX implementation RPMs:stax2-api stax2-api-javadoc Size:657.57 KiB = UPGRADED PACKAGES = Package: ModemManager-1.16.8-3.fc35 Old package: ModemManager-1.16.8-2.fc35 Summary: Mobile broadband modem management service RPMs: ModemManager ModemManager-devel ModemManager-glib ModemManager-glib-devel ModemManager-vala Size: 11.47 MiB Size change: 19.52 KiB Changelog: * Thu Jul 29 2021 Bastien Nocera - 1.16.8-3 + ModemManager-1.16.8-3 - Add polkit support as used upstream Package: NetworkManager-1:1.32.6-1.fc35 Old package: NetworkManager-1:1.32.4-1.fc35.1 Summary: Network connection manager and user applications RPMs: NetworkManager NetworkManager-adsl NetworkManager-bluetooth NetworkManager-cloud-setup NetworkManager-config-connectivity-fedora NetworkManager-config-server NetworkManager-dispatcher-routing-rules NetworkManager-libnm NetworkManager-libnm-devel NetworkManager-ovs NetworkManager-ppp NetworkManager-team NetworkManager-tui NetworkManager-wifi NetworkManager-wwan Size: 28.99 MiB Size change: 27.05 KiB Changelog: * Wed Jul 28 2021 Thomas Haller - 1:1.32.6-1 - update to 1.32.6 release Package: accel-config-3.4-1.fc35 Old package: accel-config-3.2-3.fc35 Summary: Configure accelerator subsystem devices RPMs: accel-config accel-config-devel accel-config-libs Size: 292.08 KiB Size change: 4.17 KiB Changelog: * Thu Jul 29 2021 Yunying Sun - 3.4-1 - Updated to 3.4 release Package: adcli-0.9.1-9.fc35 Old package: adcli-0.9.1-8.fc35 Summary: Active Directory enrollment RPMs: adcli adcli-doc Size: 663.94 KiB Size change: -400 B Changelog: * Wed Jul 28 2021 Sumit Bose - 0.9.1-9 - Add ns_get16() and ns_get32() to configure check Resolves: rhbz#1984891 Package: akonadi-calendar-tools-21.04.3-1.fc35 Old package: akonadi-calendar-tools-21.04.2-2.fc35 Summary: Akonadi Calendar Tools RPMs: akonadi-calendar-tools Size: 1.23 MiB Size change: -514 B Changelog: * Wed Jul 28 2021 Rex Dieter - 21.04.3-1 - 21.04.3 Package: akonadi-import-wizard-21.04.3-1.fc35 Old package: akonadi-import-wizard-21.04.2-2.fc35 Summary: Akonadi Import Wizard RPMs: akonadi-import-wizard akonadi-import-wizard-devel Size: 2.98 MiB Size change: -29 B Changelog: * Wed Jul 28 2021 Rex Dieter - 21.04.3-1 - 21.04.3 Package: akonadiconsole-21.04.3-1.fc35 Old package: akonadiconsole-21.04.2-2.fc35 Summary: Akonadi developer tool RPMs: akonadiconsole Size: 1.61 MiB Size change: -125 B Changelog: * Wed Jul 28 2021 Rex Dieter - 21.04.3-1 - 21.04.3 Package: akregator-21.04.3-1.fc35 Old package: akregator-21.04.2-2.fc35 Summary: Feed Reader RPMs: akregator akregator-libs Size: 8.18 MiB Size change: 251 B Changelog: * Wed Jul 28 2021 Rex Dieter - 21.04.3-1 - 21.04.3 Package: analitza-21.04.3-1.fc35 Old package: analitza-21.04.2-2.fc35 Summary: Library of mathematical features RPMs: analitza analitza-devel Size: 3.26 MiB Size change: -1.68 KiB Changelog: * Wed Jul 28 2021 Rex Dieter - 21.04.3-1 - 21.04.3 Package: apostrophe-2.4-7
Re: Self Introduction: Peter Savage
It was a long time ago - but thank you for the welcome :) On Wed, Jul 28, 2021 at 7:56 PM Dominik 'Rathann' Mierzejewski < domi...@greysector.net> wrote: > On Tuesday, 27 July 2021 at 15:31, Pete Savage wrote: > > Hi all, > > > > I was a MOTU for Ubuntu in the past, recently I've become interested in > > composing music and there are a number of packages that I'd like to see > in > > Fedora's main repo. I'm tacklingthe sFizz package first, hoping you'll > see > > a package for review from me soon! > > Welcome to Fedora! > It's nice to see an Ubuntu maintainer in Fedora, too. > > 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://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > Do not reply to spam on the list, report it: > https://pagure.io/fedora-infrastructure > ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: How to easily automate test builds in a COPR project
Hello Richard,
we're currently evaluating a proper approach with the Packit team, to
deduplicate (and optimize) the work, as I've written a set of tools
for such automation:
https://github.com/pvalena/theprototype
https://www.youtube.com/watch?v=gUjwSj6iypw_channel=DevConf
Currently does not have wide adoption, and some tools are still
domain-specific (rubygems). So it's in the "testing" phase (please, do
file issues if you find something does not work!). After some
iterations (~months), it should be quite suitable for automating
various packaging tasks.
Should I keep you in the loop?
Regards,
Pavel
On Thu, Dec 31, 2020 at 2:58 PM Richard Shaw wrote:
>
> I maintain a suite of ham radio related packages. The developer is very
> active and often creates test versions adding and incrementing the "tweak"
> part of the version which is removed for the full releases and the patch
> level incremented.
>
> Currently I'm just trying to keep up with them by hand using pagure forks of
> the official repos so I don't accidentally pollute SCM with the changes and
> build them in COPR.
>
> Things I need to manage automagically:
> 1. Monitor the test URLs to look for new versions.
>
> I could write a bash script for this and add a cron or systemd timer but I
> was hoping for something that took less time as I don't have a lot of that :)
>
> Would it be permissible to create a -testing entry in
> release-monitoring.org?
>
>
> 2. Trigger a "fedpkg clone" and add a tweak version.
>
> This could probably be managed with macros easy enough, %{?tweak}, or
> something like that. And then use a script to substitute into "%global tweak
> ..."
>
>
> 3. I need to download the files from a different location.
>
> %if %{?tweak}
> ... use difference Source0?
>
>
> 4. Build the packages in COPR.
>
> Easy enough using a bash script but is there a better way?
>
> 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://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it:
https://pagure.io/fedora-infrastructure
Re: F35 Change: Restart User Services after Upgrade (very-very-very late System-Wide Change proposal)
On Wed, Jul 28, 2021 at 09:07:58AM -0400, Ben Cotton wrote:
> Note from the change owner: I'm submitting this as very-very-late
> change for F35. The implementation in systemd is mostly done, so it'll
> become available in rawhide pretty soon. To actually make use of the
> new functionality, individual packages should be changed to use
> _with_restart in their scriptlets and rebuilt. This will happen over
> time, and it's fine if each package does that on its own schedule. We
> still do not have that many user services, and restarting from
> packaging scriptlets will be possible and appropriate only for some of
> them. I think it's important to make the functionality available,
> without trying to use it everywhere immediately.
>
> https://fedoraproject.org/wiki/Changes/Restart_User_Service_after_Upgrade
We've been restarting httpd on upgrades in %posttrans for a while, so
it's good to see a more general version of this available. A couple of
notes:
1) Users asked to be able to turn this off ("why did running dnf break
my web server" etc), which I think is reasonable, we added a crude
mechanism (touch /etc/sysconfig/thing) to disable it.
2) Blocking the dnf transaction from completing before the service
restarts turned out to be quite painful UX and we now only run
try-restart with --no-block. Depending on the service or service
configuration there it can be a significant delay. Obviously a trade-off
here since it can hide the failure case.
I tried to trace through the systemd macros (the links from the Change
wiki under "Macro details" are broken) and it looks like you do block on
restart/reload, is that worth reconsidering? Maybe we could wrap the
systemd macros to achieve (1) as well for httpd, but I'd say that it
might be a more generally useful feature too to allow users control over
this feature.
Regards, Joe
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it:
https://pagure.io/fedora-infrastructure
Re: Fedora 34 90 second timeout in initrd / dbus ordering issue
On Thu, Jul 29, 2021 at 1:58 AM Hans de Goede wrote: > > Hi Zbigniew, Justin, > > I assume you are familiar with $subject, also see e.g. : > > https://bugzilla.redhat.com/show_bug.cgi?id=1976653 > > I have just come back from a week vacation and I see that this is > still not resolved, what is the current status of this ? > > This is really making Fedora look bad, IMHO we really need to > get this fixed ASAP. Are there any ideas what is necessary to > fix / who we need to poke to get this fixed? > I am unfortunately very aware of it, as most bug reports on it (and there have been a lot) are opened against kernel. Unfortunately the kernel has nothing to do with it, and I cannot fix it there. Justin ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[Fedocal] Reminder meeting : ELN SIG
Dear all, You are kindly invited to the meeting: ELN SIG on 2021-07-30 from 12:00:00 to 13:00:00 US/Eastern At fedora-meet...@irc.libera.chat The meeting will be about: Source: https://calendar.fedoraproject.org//meeting/9920/ ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F35 Change: Restart User Services after Upgrade (very-very-very late System-Wide Change proposal)
On 7/29/21 11:51 AM, Daniel P. Berrangé wrote: > On Thu, Jul 29, 2021 at 09:37:53AM +, Zbigniew Jędrzejewski-Szmek wrote: >> On Wed, Jul 28, 2021 at 07:04:03PM +0200, Miroslav Suchý wrote: >> So... personally I think we should restart many more things than >> we currently do. Even in systemd itself we fall short of this >> goal: systemd-logind is not restarted because of bugs (gnome >> session gets killed when logind is restarted, and it's really a >> problem with how logind manages resources during restart [1]). >> To be able to safely restart, the application has to provide the >> appropriate functionality: it needs to either always keep all >> state serialized, or serialize it on demand. Systemd provides a >> "file descriptor store" [2] that can be used to keep files open >> while the process is not running. There are obviously exceptions… >> for example graphical applications. But for many system services and >> background user services, my expecation is that they are invisibly >> restarted in the background without any user interaction. Each program >> that allows this moves us one step closer towards the goal of being >> upgrades being a non-event. > I'd question the criteria we use for deciding when to restart services. > Typically we only restart a daemon if the daemon binary is upgraded. > This ignores any libraries that the daemon links to, which are just > as important to its functionality, reliability and security as the > executable binary. Only restarting daemons when the executable binary > changes gives us a false sense of having solved the upgrades problems. > To arbitrarily pick on 'colord', there are 35 libraries it links to > that could be considered triggers for restart on upgrade. This is > an especially important problem for any daemons that link to TLS or > general crypto libraries, as it means we're not actually applying > security updates in those libraries to any running daemons that use > them, unless you always restart the entire host OS. This is out of the scope of this Change but I am wondering whether this should be something RPM supports somehow. Yes, there are triggers, that would allow for scriptlets to run if another package gets updated. But this is super cumbersome for this use case and requires the packager to keep track of all the dependencies (recursively!). My first thought was a new trigger scriptlet type that would run if any dependencies get updated. But I guess this would trigger much too often. Dependencies from scriptlets or meta dependencies can ofc be filtered out but this will probably still leave too many dependencies. May be we could have some REs to filter the dependencies to look at. Just matching *.so* may do the trick but looks pretty fragile. Florian ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Fedora 34 90 second timeout in initrd / dbus ordering issue
Hi, On 7/29/21 12:57 PM, Zbigniew Jędrzejewski-Szmek wrote: > On Thu, Jul 29, 2021 at 09:16:48AM +0200, drago01 wrote: >> On Thursday, July 29, 2021, Hans de Goede wrote: >> >>> Hi Zbigniew, Justin, >>> >>> I assume you are familiar with $subject, also see e.g. : >>> >>> https://bugzilla.redhat.com/show_bug.cgi?id=1976653 >>> >>> I have just come back from a week vacation and I see that this is >>> still not resolved, what is the current status of this ? >>> >>> This is really making Fedora look bad, IMHO we really need to >>> get this fixed ASAP. Are there any ideas what is necessary to >>> fix / who we need to poke to get this fixed? >>> >> >> Revert the change that caused it? I don't get from the bug why it was added. > > I assume David is on vacation… I fired of a build for F34 and rawhide with > After=sysinit.target removed. I also opened a pull request upstream [1]. > > [1] https://github.com/bus1/dbus-broker/pull/271 Great, thank you. Regards, Hans ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Fedora 34 90 second timeout in initrd / dbus ordering issue
On Thu, Jul 29, 2021 at 09:16:48AM +0200, drago01 wrote: > On Thursday, July 29, 2021, Hans de Goede wrote: > > > Hi Zbigniew, Justin, > > > > I assume you are familiar with $subject, also see e.g. : > > > > https://bugzilla.redhat.com/show_bug.cgi?id=1976653 > > > > I have just come back from a week vacation and I see that this is > > still not resolved, what is the current status of this ? > > > > This is really making Fedora look bad, IMHO we really need to > > get this fixed ASAP. Are there any ideas what is necessary to > > fix / who we need to poke to get this fixed? > > > > Revert the change that caused it? I don't get from the bug why it was added. I assume David is on vacation… I fired of a build for F34 and rawhide with After=sysinit.target removed. I also opened a pull request upstream [1]. [1] https://github.com/bus1/dbus-broker/pull/271 Zbyszek ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Package requests: mingw-glfw, gtkmm-4
Hi mingw packages are dedicated like any other packages, with a respecitve maintainer. If something is not packaged yet it's because well no-one did it yet. If you want to package them, I'll happily review them. Sandro On 29.07.21 12:33, Marián Konček wrote: As a hobbyist developer it is very convenient to use Fedora even for building for Windows. In dnf i see a huge array of mingw-* libraries but glfw is missing. The upstream project https://www.glfw.org/ provides them so it is probably simple enough. So my first question is related to this: How are mingw packages built in Fedora? Who usually maintains them (the maintainer of the linux library package)? Is the process of building a mingw library largely automated is the build for the linux package is available? Is there a reason why there is no mingw-glfw in Fedora? 2) gtkmm-4. I noticed there is already gtk4-devel but no gtkmm-4 (the C++ wrapper). Are there any plans to include this as well? Thanks. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Package requests: mingw-glfw, gtkmm-4
As a hobbyist developer it is very convenient to use Fedora even for building for Windows. In dnf i see a huge array of mingw-* libraries but glfw is missing. The upstream project https://www.glfw.org/ provides them so it is probably simple enough. So my first question is related to this: How are mingw packages built in Fedora? Who usually maintains them (the maintainer of the linux library package)? Is the process of building a mingw library largely automated is the build for the linux package is available? Is there a reason why there is no mingw-glfw in Fedora? 2) gtkmm-4. I noticed there is already gtk4-devel but no gtkmm-4 (the C++ wrapper). Are there any plans to include this as well? Thanks. -- Marián Konček ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Fedora-Cloud-34-20210729.0 compose check report
No missing expected images. Soft failed openQA tests: 1/8 (x86_64), 1/8 (aarch64) (Tests completed, but using a workaround for a known bug) Old soft failures (same test soft failed in Fedora-Cloud-34-20210728.0): ID: 937461 Test: x86_64 Cloud_Base-qcow2-qcow2 cloud_autocloud URL: https://openqa.fedoraproject.org/tests/937461 ID: 937471 Test: aarch64 Cloud_Base-qcow2-qcow2 cloud_autocloud@uefi URL: https://openqa.fedoraproject.org/tests/937471 Passed openQA tests: 7/8 (x86_64), 7/8 (aarch64) -- Mail generated by check-compose: https://pagure.io/fedora-qa/check-compose ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F35 Change: Restart User Services after Upgrade (very-very-very late System-Wide Change proposal)
On Thu, Jul 29, 2021 at 09:37:53AM +, Zbigniew Jędrzejewski-Szmek wrote: > On Wed, Jul 28, 2021 at 07:04:03PM +0200, Miroslav Suchý wrote: > So... personally I think we should restart many more things than > we currently do. Even in systemd itself we fall short of this > goal: systemd-logind is not restarted because of bugs (gnome > session gets killed when logind is restarted, and it's really a > problem with how logind manages resources during restart [1]). > To be able to safely restart, the application has to provide the > appropriate functionality: it needs to either always keep all > state serialized, or serialize it on demand. Systemd provides a > "file descriptor store" [2] that can be used to keep files open > while the process is not running. There are obviously exceptions… > for example graphical applications. But for many system services and > background user services, my expecation is that they are invisibly > restarted in the background without any user interaction. Each program > that allows this moves us one step closer towards the goal of being > upgrades being a non-event. I'd question the criteria we use for deciding when to restart services. Typically we only restart a daemon if the daemon binary is upgraded. This ignores any libraries that the daemon links to, which are just as important to its functionality, reliability and security as the executable binary. Only restarting daemons when the executable binary changes gives us a false sense of having solved the upgrades problems. To arbitrarily pick on 'colord', there are 35 libraries it links to that could be considered triggers for restart on upgrade. This is an especially important problem for any daemons that link to TLS or general crypto libraries, as it means we're not actually applying security updates in those libraries to any running daemons that use them, unless you always restart the entire host OS. Regards, Daniel -- |: https://berrange.com -o-https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o-https://fstop138.berrange.com :| |: https://entangle-photo.org-o-https://www.instagram.com/dberrange :| ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F35 Change: Restart User Services after Upgrade (very-very-very late System-Wide Change proposal)
On Wed, Jul 28, 2021 at 07:04:03PM +0200, Miroslav Suchý wrote: > Dne 28. 07. 21 v 15:07 Ben Cotton napsal(a): > == Benefit to Fedora == > >This fixes a long-standing missing feature. We certainly wanted to > >have this, but the technical implementation is not trivial, because we > >need to (safely and robustly) reach from the a privileged context into > >unprivileged user manager instances. Such functionality has been added > >in systemd, so finally we are able to do this in a fairly clean > >manner. > > Only partially true. There is `tracer` with dnf plugin. It have been > here for few years. Users are suggested which services need to be > restarted (and are safe to be restarted), if they need to > logoff/login or even restart a machine. Right. Those approaches are complementary really — it is better to restart everything that can be safely restarted directly from package scriptlets, and 'tracer' or similar approaches can be used to figure out what was missed. > >User services are becoming more and more important. In particular, we > >want to be able to restart services such as `pipewire.service` during > >upgrades, without requiring a restart of the machine for the upgrade > >to take effect. Systemd only provides the general functionality. > >Package maintainers will need to mark their services for restart using > >`%systemd_postun_with_restart` if appropriate. > > I think that this needs to be expanded. Thanks. I added a paragraph and reworded some stuff. Please say if you think there should be more. > 1) It will be good to expand what is actually an user service. I had to look > it up. Hint for others: > > systemctl --user status > > 2) Do you want to restart all user services? Or just these which are > marked by maintainers to be safe to be restarted (e.g., pipewire)? Only select ones. This is maintainer choice. > 3) Can we have some discussions which user services are safe to > restart and which not? E.g., the Tracer configuration is a good > start point. So... personally I think we should restart many more things than we currently do. Even in systemd itself we fall short of this goal: systemd-logind is not restarted because of bugs (gnome session gets killed when logind is restarted, and it's really a problem with how logind manages resources during restart [1]). To be able to safely restart, the application has to provide the appropriate functionality: it needs to either always keep all state serialized, or serialize it on demand. Systemd provides a "file descriptor store" [2] that can be used to keep files open while the process is not running. There are obviously exceptions… for example graphical applications. But for many system services and background user services, my expecation is that they are invisibly restarted in the background without any user interaction. Each program that allows this moves us one step closer towards the goal of being upgrades being a non-event. As to which applications can be restarted: each case is different… I hope that package maintainers mostly know this for their packages. And in cases where it's not already possible, working with upstream will be necessary. I looked briefly into the tracer package metadata, and it seems rather sparse… It knows about systemd, but not systemd --user, afaict. So it may be used as a starting to point to figure out what is not restarted, but not how to restart it. [1] https://github.com/systemd/systemd/issues/17308 [2] https://www.freedesktop.org/software/systemd/man/sd_notify.html#FDSTORE=1 > >== How To Test == > >Upgrade packages with user services that should be restarted. Look at > >logs or otherwise verify that the new version is running. > > Can the guidance be more specific here? Also updated, ptal. > >== User Experience == > >Updates of user services take effect immediately (if so configured in > >the providing packages). > > Can this be expanded too? What will be the **practical** impact? > Will my audio stops? Or has just little glitch? What about my > bluetooth connections? Etc. Oh, I don't know audio well enough… It'll be up to the package maintainer to decide if the service can support this at all, and if the update creates some user-visible interruption, if this interruption is worth it. Zbyszek ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F35 Change: Restart User Services after Upgrade (very-very-very late System-Wide Change proposal)
On Wed, Jul 28, 2021 at 05:35:08PM +, Gary Buhrmaster wrote: > On Wed, Jul 28, 2021 at 5:28 PM Vitaly Zaitsev via devel > wrote: > > > > On 28/07/2021 15:07, Ben Cotton wrote: > > > Updates of user services take effect immediately (if so configured in > > > the providing packages). > > > > Restarting plasma-ksmserver.service, plasma-kwin_x11.service, etc. will > > cause a DE crash with termination of all running desktop applications > > (including terminal with DNF). > > As I understand it, this is a opt-in proposal, > and if a package does not choose to opt-in, > nothing changes (for them). > > And I would certainly expect that those > plasma services will choose not to opt-in > by add a _with_restart to their scriptlets. Yes, exactly. It's the same as for *system* services: some are restarted, some not, per maintainer choice. Zbyszek ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Fedora-Cloud-33-20210729.0 compose check report
No missing expected images. Soft failed openQA tests: 1/8 (x86_64), 1/8 (aarch64) (Tests completed, but using a workaround for a known bug) Old soft failures (same test soft failed in Fedora-Cloud-33-20210728.0): ID: 937387 Test: x86_64 Cloud_Base-qcow2-qcow2 cloud_autocloud URL: https://openqa.fedoraproject.org/tests/937387 ID: 937397 Test: aarch64 Cloud_Base-qcow2-qcow2 cloud_autocloud@uefi URL: https://openqa.fedoraproject.org/tests/937397 Passed openQA tests: 7/8 (x86_64), 7/8 (aarch64) -- Mail generated by check-compose: https://pagure.io/fedora-qa/check-compose ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Fedora 34 90 second timeout in initrd / dbus ordering issue
On Thursday, July 29, 2021, Hans de Goede wrote: > Hi Zbigniew, Justin, > > I assume you are familiar with $subject, also see e.g. : > > https://bugzilla.redhat.com/show_bug.cgi?id=1976653 > > I have just come back from a week vacation and I see that this is > still not resolved, what is the current status of this ? > > This is really making Fedora look bad, IMHO we really need to > get this fixed ASAP. Are there any ideas what is necessary to > fix / who we need to poke to get this fixed? > Revert the change that caused it? I don't get from the bug why it was added. Regards, > > Hans > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: https://docs.fedoraproject. > org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: https://lists.fedoraproject.org/archives/list/devel@lists. > fedoraproject.org > Do not reply to spam on the list, report it: https://pagure.io/fedora- > infrastructure > ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Fedora 34 90 second timeout in initrd / dbus ordering issue
Hi Zbigniew, Justin, I assume you are familiar with $subject, also see e.g. : https://bugzilla.redhat.com/show_bug.cgi?id=1976653 I have just come back from a week vacation and I see that this is still not resolved, what is the current status of this ? This is really making Fedora look bad, IMHO we really need to get this fixed ASAP. Are there any ideas what is necessary to fix / who we need to poke to get this fixed? Regards, Hans ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
