Re: Review swaps: A bunch of PHP libraries
Le 16/07/2021 à 10:39, Christopher Engelhard a écrit : Hi all, I finally found some time to unbundle all the 3rdparty PHP/composer libraries from the nextcloud package. The bad news is that due to their various dependency trees, I now have a total of 24 new packages that need reviewing. The good news is that I think quite a few of them will be generally useful beyond just nextcloud. They are all fairly small & simple PHP libraries, build without issues and are basically identical in terms of packaging. If there are people out there who'd like to try their hand at reviewing for the first time, one of these might be a good place to start. From a quick look, for all these packages it seems useful to include upstream test suite by pulling a git snapshot (common practice in PHP to workaround the stupid .gitattributes usage) Unbundling make sense when we can run CI (Koschei) and ensure changes in the PHP stack (ex PHP 8.0 in F35 or 8.1 in F36) don't break Also use range dependencies everywhere (even if a single version packaged), this can change in the future. I should be able to review (or help) on this set of reviews. the PHP SIG mailing list (php-devel@...) is probably a better place if you have any question about PHP specific packaging Remi Obviously, if you need something reviewed in return, I'd be happy to do that. Full list of links is below, but to make it easier for people - I set up a dependency tree ( https://bugzilla.redhat.com/buglist.cgi?bug_id=1981857_id_type=anddependson=tvp_id=12016550 ) so you can pick a leaf. - I made a copr repository ( https://copr.fedorainfracloud.org/coprs/lcts/nextcloud/packages/ ) that has builds for all of these, including fedora-review/rpmlint logs (and a big thank you to whoever made that last bit possible in Copr, that was *extremely* useful). The repo also contains a few forks of existing packages, ignore those :) . Best, Christopher List of links: https://bugzilla.redhat.com/show_bug.cgi?id=1982616 https://bugzilla.redhat.com/show_bug.cgi?id=1982618 https://bugzilla.redhat.com/show_bug.cgi?id=1982619 https://bugzilla.redhat.com/show_bug.cgi?id=1982621 https://bugzilla.redhat.com/show_bug.cgi?id=1982624 https://bugzilla.redhat.com/show_bug.cgi?id=1982627 https://bugzilla.redhat.com/show_bug.cgi?id=1982629 https://bugzilla.redhat.com/show_bug.cgi?id=1982630 https://bugzilla.redhat.com/show_bug.cgi?id=1982631 https://bugzilla.redhat.com/show_bug.cgi?id=1982632 https://bugzilla.redhat.com/show_bug.cgi?id=1982633 https://bugzilla.redhat.com/show_bug.cgi?id=1982635 https://bugzilla.redhat.com/show_bug.cgi?id=1982636 https://bugzilla.redhat.com/show_bug.cgi?id=1982637 https://bugzilla.redhat.com/show_bug.cgi?id=1982638 https://bugzilla.redhat.com/show_bug.cgi?id=1982639 https://bugzilla.redhat.com/show_bug.cgi?id=1982640 https://bugzilla.redhat.com/show_bug.cgi?id=1982643 https://bugzilla.redhat.com/show_bug.cgi?id=1982645 https://bugzilla.redhat.com/show_bug.cgi?id=1982646 https://bugzilla.redhat.com/show_bug.cgi?id=1982647 https://bugzilla.redhat.com/show_bug.cgi?id=1982648 https://bugzilla.redhat.com/show_bug.cgi?id=1982651 https://bugzilla.redhat.com/show_bug.cgi?id=1982652 ___ 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: Why so long for EPEL-8?
On Mon, Jul 19, 2021 at 7:04 AM Fabio Valentini wrote: > > On Mon, Jul 19, 2021 at 12:06 PM Jiri Vanek wrote: > > > > On 7/17/21 11:15 PM, Ron Olson wrote: > > > Hey all- > > > > > > I’m curious as to why submitting a new build to Bodhi takes a week to be > > > pushed to stable, but two weeks for EPEL-8. Is the presumption that it’s > > > just that much more time for folks to test and verify? > > > > lack of reviewers, so longer in buildroot is kinda test... > > Surely not? The user base of EPEL is, by some measures, considerably > bigger than the user base of Fedora. > Those users might not participate in testing as much, because they > rely on the stability of their systems more, but this is certainly not > a *lack of reviewers*. There are odd trade-offs. Many EPEL users do so as a matter of course, treating EPEL as an adjunct to RHEL, and would find RHEL or CentOS quite useless without EPEL. The availability of python36 for RHEL 7, for example, was an excellent step towards python3 for RHEL 7 and CentOS 7 users, and I'd have had to consider migrating from RHEL without the stable python36 tools from EPEL, which avoided having to build up a python suite myself. I do wish our colleagues at RHEL, or that Fedora itself, had kept the "python34", "python36", etc. numbering from EPEL. It would have eased demands I'm seeing for people to build and ihstalll and manage python in their home directories with "linuxbrew", which does not work, or "pyenv", which is vulnerable to dependency skew adventures. I consider it a crying shame that the numbered versions, like python36 and python38, were abandoned. Unfortunately, it can't always be that stable because it's driven by things people want and are willing to do the work to put in. Don't get me started on the chromium and ansible regressions I've encountered in the last few years. tools like those which are used as part of automated testing suites are very vulnerable to quite small changes in their features or API's leading to quite adventuresome breakdowns. ___ 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: Nest 2021 - any Lenovo questions/topics I should cover?
I just bought a Lenovo X13 Yoga. It's unfortunate that the RAM is soldered, and the max was 16GB. My old x250 supported 16GB years ago. The SSD was easy to upgrade, so at least I could pick an option that shipped faster and do my own upgrade. Although the CPU and GPU are faster, the RAM and storage capacity have not really progressed in the last 3 or 4 generations. The main question I have now is - what's next for thermal support? These new 11th gen Intel CPUs share the same thermal budget between CPU & GPU, so if you try to run a workload that is both CPU+GPU heavy - the performance does not stabilize. I'm hoping they can expose independent power or thermal targets so thermald can smooth this out or set fixed caps to achieve predictable performance. ___ 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: Java packaging issue on EPEL7
On Mon, Jul 19, 2021 at 1:31 PM Vitaly Zaitsev via devel wrote: > Fedora: > Requires: /usr/bin/python3 /usr/bin/sh libc.so.6()(64bit) > libc.so.6(GLIBC_2.14)(64bit) libc.so.6(GLIBC_2.2.5)(64bit) > libc.so.6(GLIBC_2.3)(64bit) libc.so.6(GLIBC_2.4)(64bit) rtld(GNU_HASH) > > Downstream issue: > https://github.com/phracek/pycharm-community-edition/issues/62 > > SPEC file: > https://github.com/phracek/pycharm-community-edition/blob/master/pycharm-community.spec > > How I can fix this? You've got other problems. Those .spec files are not building from source, they're pulling in pre-compiled binary tarballs and plugging them into RPMs. If you're going to to that, please reflect it in the name of your packages, say as pycharm-community_bin. Source code for pycharm is apparently available: if you'd like to get that into EPEL or Fedora, I'd suggest you start from source. ___ 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
HEADS UP: OpenEXR 3.X coming soon!
So I've spent about 40 hours pushing through build problems in the COPR[1] I've set up beating what packages I could into submission and moving the ones I couldn't (or shouldn't) port to the openexr2 compat package. Some of the ones I didn't even try porting were packages that looked to be legacy like the kde3/kde4 ones or packages on their 40th release with no activity upstream. I don't want to update any package when it's unlikely or impossible (dead upstream) that OpenEXR 3 will ever be supported officially. Some packages only needed some build system updates because of the restructuring of the libraries. Others needed just a little bit of porting in the code. With all that said, I'm down to one package/problem... Blender The problem is not with Blender itself, but rather that it depends on OpenVDB and I've already confirmed with upstream that OpenEXR 3 will not be supported until the next major release. Ironically they are both under the stewardship of the Academy Software Foundation (AWSF) so great coordination there... :/ That being said, OpenSceneGraph wasn't ready either but it was relatively easy to port after I figured out that the EXR plugin it builds doesn't create a fatal error during the build when it fails (frustrating!) Ok, and as usual, writing all of this has helped me work through porting OpenVDB... I'll see about sending the patch upstream. I'll probably create the side-tag tomorrow and start working on the builds. 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: MUMPS-5.4.0 in Rawhide
Hi, On Tue, 2021-07-06 at 11:48 +0200, Antonio T. sagitter wrote: > Hi all. > > In a week i will compile MUMPS-5.4.0 in Rawhide; this implicates the > rebuilds of dependent packages: > > $ repoquery --whatrequires MUMPS-openmpi-devel --disablerepo=* > --enablerepo=*-source > > Last metadata expiration check: 0:00:14 ago on Tue 06 Jul 2021 11:32:14 > AM CEST. > > amg4psblas-0:1.0.0-2.fc34.src > > coin-or-Ipopt-0:3.13.0-11.fc34.src > > freefem++-0:4.7-3.fc34.src > > mld2p4-0:2.2.2-8.fc34.src > > petsc-0:3.14.4-1.fc34.src > > we also need rebuild coin-or-Clp [1], I found it when install opencv-devel [2] [1] https://src.fedoraproject.org/rpms/coin-or-Clp/blob/rawhide/f/coin-or-Clp.spec#_18 BuildRequires: MUMPS-devel [2] DEBUG util.py:444: Error: DEBUG util.py:444: Problem: package opencv-devel-4.5.3-1.fc35.x86_64 requires opencv-contrib(x86-64) = 4.5.3-1.fc35, but none of the providers can be installed DEBUG util.py:444:- package opencv-contrib-4.5.3-1.fc35.x86_64 requires libClp.so.1()(64bit), but none of the providers can be installed DEBUG util.py:444:- conflicting requests DEBUG util.py:444:- nothing provides libdmumps-5.3.so()(64bit) needed by coin-or-Clp-1.17.6-3.fc34.x86_64 DEBUG util.py:444:- nothing provides libmpiseq-5.3.so()(64bit) needed by coin-or-Clp-1.17.6-3.fc34.x86_64 DEBUG util.py:446: (try to add '--skip-broken' to skip uninstallable packages) > Except 'freefem++', they are all packages that i maintain; if the > maintainer of freefem++ is agree, i will rebuild it independently in > the > MUMPS side-tag. > > Regards. > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: > https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > Do not reply to spam on the list, report it: > https://pagure.io/fedora-infrastructure -- Sérgio M. B. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Strange issue with keymaps
On Mon, 2021-07-19 at 07:01 +, Zbigniew Jędrzejewski-Szmek wrote: > Anaconda should pull in kbd-legacy (I think > this might be done already, this is not the first time this bug is > discovered). Yes, this is done already for F35+. It was meant to be done for F34, but we realized too late it wasn't quite done properly for all cases. Sorry for the inconvenience. https://fedoraproject.org/wiki/Common_F34_bugs#kbd-legacy-media has more details. -- Adam Williamson Fedora QA IRC: adamw | Twitter: adamw_ha https://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://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: Orphaned packages looking for new maintainers
binA_H3nIaeSi.bin Description: PGP/MIME version identification encrypted.asc Description: OpenPGP encrypted message ___ 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
mscore-edwin-fonts license correction
The mscore-edwin-fonts package (a subpackage of mscore) was mistakenly given a License field of "AGPLv3 with exceptions". The correct license is actually "OFL". I have pushed a correction to git in Rawhide and will let the mass rebuild fix the binary package. The next builds for F33 and F34 will also contain this correction. -- Jerry James http://www.jamezone.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
Fedora-Rawhide-20210719.n.0 compose check report
No missing expected images. Compose PASSES proposed Rawhide gating check! All required tests passed Failed openQA tests: 13/138 (aarch64), 2/199 (x86_64) New failures (same test not failed in Fedora-Rawhide-20210718.n.0): ID: 931017 Test: aarch64 Minimal-raw_xz-raw.xz base_services_start@uefi URL: https://openqa.fedoraproject.org/tests/931017 ID: 931043 Test: aarch64 Server-dvd-iso install_btrfs_preserve_home_uefi@uefi URL: https://openqa.fedoraproject.org/tests/931043 ID: 931054 Test: aarch64 Server-dvd-iso install_blivet_btrfs_preserve_home_uefi@uefi URL: https://openqa.fedoraproject.org/tests/931054 ID: 931084 Test: aarch64 Workstation-raw_xz-raw.xz desktop_printing@uefi URL: https://openqa.fedoraproject.org/tests/931084 ID: 931087 Test: aarch64 Workstation-raw_xz-raw.xz unwanted_packages@uefi URL: https://openqa.fedoraproject.org/tests/931087 ID: 931089 Test: aarch64 Workstation-raw_xz-raw.xz desktop_terminal@uefi URL: https://openqa.fedoraproject.org/tests/931089 ID: 931093 Test: aarch64 Workstation-raw_xz-raw.xz desktop_background@uefi URL: https://openqa.fedoraproject.org/tests/931093 ID: 931119 Test: x86_64 universal install_asian_language URL: https://openqa.fedoraproject.org/tests/931119 ID: 931211 Test: aarch64 universal upgrade_realmd_client@uefi URL: https://openqa.fedoraproject.org/tests/931211 Old failures (same test failed in Fedora-Rawhide-20210718.n.0): ID: 930988 Test: x86_64 KDE-live-iso apps_startstop URL: https://openqa.fedoraproject.org/tests/930988 ID: 931030 Test: aarch64 Server-dvd-iso anaconda_help@uefi URL: https://openqa.fedoraproject.org/tests/931030 ID: 931069 Test: aarch64 Server-dvd-iso server_cockpit_basic@uefi URL: https://openqa.fedoraproject.org/tests/931069 ID: 931182 Test: aarch64 universal upgrade_server_domain_controller@uefi URL: https://openqa.fedoraproject.org/tests/931182 ID: 931192 Test: aarch64 universal install_asian_language@uefi URL: https://openqa.fedoraproject.org/tests/931192 ID: 931204 Test: aarch64 universal install_cyrillic_language@uefi URL: https://openqa.fedoraproject.org/tests/931204 Soft failed openQA tests: 3/138 (aarch64), 4/199 (x86_64) (Tests completed, but using a workaround for a known bug) New soft failures (same test not soft failed in Fedora-Rawhide-20210718.n.0): ID: 931101 Test: aarch64 Cloud_Base-qcow2-qcow2 cloud_autocloud@uefi URL: https://openqa.fedoraproject.org/tests/931101 ID: 931166 Test: x86_64 universal upgrade_2_kde_64bit URL: https://openqa.fedoraproject.org/tests/931166 Old soft failures (same test soft failed in Fedora-Rawhide-20210718.n.0): ID: 931011 Test: x86_64 Cloud_Base-qcow2-qcow2 cloud_autocloud URL: https://openqa.fedoraproject.org/tests/931011 ID: 931013 Test: aarch64 Minimal-raw_xz-raw.xz install_arm_image_deployment_upload@uefi URL: https://openqa.fedoraproject.org/tests/931013 ID: 931070 Test: aarch64 Server-raw_xz-raw.xz install_arm_image_deployment_upload@uefi URL: https://openqa.fedoraproject.org/tests/931070 ID: 931114 Test: x86_64 universal upgrade_server_domain_controller URL: https://openqa.fedoraproject.org/tests/931114 ID: 931150 Test: x86_64 universal upgrade_realmd_client URL: https://openqa.fedoraproject.org/tests/931150 Passed openQA tests: 193/199 (x86_64), 122/138 (aarch64) New passes (same test not passed in Fedora-Rawhide-20210718.n.0): ID: 930917 Test: x86_64 Server-dvd-iso support_server URL: https://openqa.fedoraproject.org/tests/930917 ID: 930935 Test: x86_64 Server-dvd-iso install_repository_nfs_variation URL: https://openqa.fedoraproject.org/tests/930935 ID: 931026 Test: aarch64 Server-dvd-iso install_repository_hd_variation@uefi URL: https://openqa.fedoraproject.org/tests/931026 ID: 931079 Test: aarch64 Workstation-raw_xz-raw.xz install_arm_image_deployment_upload@uefi URL: https://openqa.fedoraproject.org/tests/931079 ID: 931080 Test: aarch64 Workstation-raw_xz-raw.xz desktop_update_graphical@uefi URL: https://openqa.fedoraproject.org/tests/931080 ID: 931081 Test: aarch64 Workstation-raw_xz-raw.xz base_reboot_unmount@uefi URL: https://openqa.fedoraproject.org/tests/931081 ID: 931082 Test: aarch64 Workstation-raw_xz-raw.xz base_system_logging@uefi URL: https://openqa.fedoraproject.org/tests/931082 ID: 931083 Test: aarch64 Workstation-raw_xz-raw.xz desktop_browser@uefi URL: https://openqa.fedoraproject.org/tests/931083 ID: 931085 Test: aarch64 Workstation-raw_xz-raw.xz release_identification@uefi URL: https://openqa.fedoraproject.org/tests/931085 ID: 931086 Test: aarch64 Workstation-raw_xz-raw.xz base_update_cli@uefi URL: https://openqa.fedoraproject.org/tests/931086 ID: 931088 Test: aarch64 Workstation-raw_xz-raw.xz base_services_start@uefi URL: https://openqa.fedoraproject.org/tests/931088 ID: 931090 Test: aarch64 Workstation-raw_xz-raw.xz base_package_install_remove@uefi URL:
Fedora-IoT-35-20210719.0 compose check report
No missing expected images. Failed openQA tests: 7/15 (aarch64), 2/16 (x86_64) New failures (same test not failed in Fedora-IoT-35-20210718.0): ID: 931408 Test: aarch64 IoT-dvd_ostree-iso iot_rpmostree_rebase@uefi URL: https://openqa.fedoraproject.org/tests/931408 Old failures (same test failed in Fedora-IoT-35-20210718.0): ID: 931394 Test: x86_64 IoT-dvd_ostree-iso iot_zezere_server URL: https://openqa.fedoraproject.org/tests/931394 ID: 931397 Test: x86_64 IoT-dvd_ostree-iso iot_zezere_ignition URL: https://openqa.fedoraproject.org/tests/931397 ID: 931399 Test: aarch64 IoT-dvd_ostree-iso podman@uefi URL: https://openqa.fedoraproject.org/tests/931399 ID: 931403 Test: aarch64 IoT-dvd_ostree-iso iot_clevis@uefi URL: https://openqa.fedoraproject.org/tests/931403 ID: 931406 Test: aarch64 IoT-dvd_ostree-iso podman_client@uefi URL: https://openqa.fedoraproject.org/tests/931406 ID: 931407 Test: aarch64 IoT-dvd_ostree-iso iot_rpmostree_overlay@uefi URL: https://openqa.fedoraproject.org/tests/931407 ID: 931409 Test: aarch64 IoT-dvd_ostree-iso iot_zezere_server@uefi URL: https://openqa.fedoraproject.org/tests/931409 ID: 931412 Test: aarch64 IoT-dvd_ostree-iso iot_zezere_ignition@uefi URL: https://openqa.fedoraproject.org/tests/931412 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-20210718.0): ID: 931382 Test: x86_64 IoT-dvd_ostree-iso install_default_upload URL: https://openqa.fedoraproject.org/tests/931382 ID: 931387 Test: x86_64 IoT-dvd_ostree-iso iot_clevis URL: https://openqa.fedoraproject.org/tests/931387 ID: 931389 Test: x86_64 IoT-dvd_ostree-iso install_default@uefi URL: https://openqa.fedoraproject.org/tests/931389 ID: 931398 Test: aarch64 IoT-dvd_ostree-iso install_default_upload@uefi URL: https://openqa.fedoraproject.org/tests/931398 Passed openQA tests: 11/16 (x86_64), 7/15 (aarch64) Installed system changes in test aarch64 IoT-dvd_ostree-iso install_default_upload@uefi: System load changed from 2.60 to 0.52 Average CPU usage changed from 59.63809524 to 11.08095238 Previous test data: https://openqa.fedoraproject.org/tests/930502#downloads Current test data: https://openqa.fedoraproject.org/tests/931398#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
Summary/Minutes from today's FESCo Meeting (2021-07-19)
=== #fedora-meeting: FESCo (2021-07-19) === Meeting started by decathorpe at 19:00:36 UTC. The full logs are available at https://meetbot.fedoraproject.org/fedora-meeting/2021-07-19/fesco.2021-07-19-19.00.log.html Meeting summary --- * Init Process (decathorpe, 19:01:41) * LINK: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/RRV4E5P3QRBCJ7LZMUB73YW22E5SVSAE/ Schedule (decathorpe, 19:05:30) * #2648 F35 Change: GHC 8.10 and Stackage lts-18 (decathorpe, 19:06:00) * Ask Change owner(s) to adapt, if possible, to building after the F35 Mass rebuild, and to coordinate with releng (+6, 0, -0) (decathorpe, 19:17:37) * AGREED: APPROVED assuming the #info item (+6, 0, -0) (decathorpe, 19:27:26) * Next week's chair (decathorpe, 19:28:27) * ACTION: decathorpe to chair next week's meeting (decathorpe, 19:30:13) * Open Floor (decathorpe, 19:30:20) Meeting ended at 19:50:07 UTC. Action Items * decathorpe to chair next week's meeting Action Items, by person --- * decathorpe * decathorpe to chair next week's meeting * **UNASSIGNED** * (none) People Present (lines said) --- * decathorpe (66) * defolos (40) * mhroncok (21) * zodbot (18) * zbyszek (18) * Eighth_Doctor (17) * mboddu (17) * Sir_Gallantmon (0) * Conan_Kudo (0) * sgallagh (0) * nirik (0) * dcantrell (0) * King_InuYasha (0) * Son_Goku (0) * Pharaoh_Atem (0) Generated by `MeetBot`_ 0.1.4 .. _`MeetBot`: http://wiki.debian.org/MeetBot ___ 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-34-20210719.0 compose check report
No missing expected images. Failed openQA tests: 2/16 (x86_64), 3/15 (aarch64) Old failures (same test failed in Fedora-IoT-34-20210711.0): ID: 931357 Test: x86_64 IoT-dvd_ostree-iso iot_zezere_server URL: https://openqa.fedoraproject.org/tests/931357 ID: 931360 Test: x86_64 IoT-dvd_ostree-iso iot_zezere_ignition URL: https://openqa.fedoraproject.org/tests/931360 ID: 931366 Test: aarch64 IoT-dvd_ostree-iso iot_clevis@uefi URL: https://openqa.fedoraproject.org/tests/931366 ID: 931372 Test: aarch64 IoT-dvd_ostree-iso iot_zezere_server@uefi URL: https://openqa.fedoraproject.org/tests/931372 ID: 931375 Test: aarch64 IoT-dvd_ostree-iso iot_zezere_ignition@uefi URL: https://openqa.fedoraproject.org/tests/931375 Soft failed openQA tests: 1/16 (x86_64) (Tests completed, but using a workaround for a known bug) Old soft failures (same test soft failed in Fedora-IoT-34-20210711.0): ID: 931350 Test: x86_64 IoT-dvd_ostree-iso iot_clevis URL: https://openqa.fedoraproject.org/tests/931350 Passed openQA tests: 13/16 (x86_64), 12/15 (aarch64) -- Mail generated by check-compose: https://pagure.io/fedora-qa/check-compose ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Nest 2021 - any Lenovo questions/topics I should cover?
On Mon, Jul 19, 2021 at 12:53:42PM -0400, Matthew Miller wrote: > On Mon, Jul 19, 2021 at 11:52:59AM -0400, Mark Pearson wrote: > > I'd much rather make sure I'm answering any questions the community > > has - I figure that's more interesting than me blathering on. I > > can't promise to answer everything, but will do my best. If you send > > me any questions in the next few days that would be appreciated. > > So, things I've heard: > > * Why is the lag time so high (order now for ... Christmas?) > * What about AMD? > * What about ARM -- an M1 competitor? It's ridiculous the gap between the performance of my AMD (HP) and Intel (Lenovo) laptops, especially when you consider that one is half the price of the other (hint: Intel does not look good on any axis). ARM is a trickier proposition. Apple are never going to start selling M1s to other laptop makers, non-custom options like AllWinner and Rockchip are not serious, and custom development (like Microsoft Surface Pro X with its co-designed custom Snapdragon) will be very very expensive. > * More options? Lower-end systems? The higher-end ones with more RAM? More RAM for sure. I've got the same amount of RAM in my current Lenovo that I had in my two generations previous one. Rich. > * Pricing compared to pre-configured Windows systems? > * What about... the world? > > And, my own personal questions: > > * How well is this doing? Does Lenovo see it as a success? > * What can we do to make it even better from the Fedora side? > > -- > Matthew Miller > > Fedora Project Leader > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > Do not reply to spam on the list, report it: > https://pagure.io/fedora-infrastructure -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com virt-df lists disk usage of guests without needing to install any software inside the virtual machine. Supports Linux and Windows. http://people.redhat.com/~rjones/virt-df/ ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Fedora rawhide compose report: 20210719.n.0 changes
OLD: Fedora-Rawhide-20210718.n.0 NEW: Fedora-Rawhide-20210719.n.0 = SUMMARY = Added images:0 Dropped images: 4 Added packages: 11 Dropped packages:0 Upgraded packages: 52 Downgraded packages: 0 Size of added packages: 1.30 MiB Size of dropped packages:0 B Size of upgraded packages: 4.09 GiB Size of downgraded packages: 0 B Size change of upgraded packages: -21.09 MiB Size change of downgraded packages: 0 B = ADDED IMAGES = = DROPPED IMAGES = Image: Container_Minimal_Base docker aarch64 Path: Container/aarch64/images/Fedora-Container-Minimal-Base-Rawhide-20210718.n.0.aarch64.tar.xz Image: Container_Base docker ppc64le Path: Container/ppc64le/images/Fedora-Container-Base-Rawhide-20210718.n.0.ppc64le.tar.xz Image: Astronomy_KDE live x86_64 Path: Labs/x86_64/iso/Fedora-Astronomy_KDE-Live-x86_64-Rawhide-20210718.n.0.iso Image: Robotics live x86_64 Path: Labs/x86_64/iso/Fedora-Robotics-Live-x86_64-Rawhide-20210718.n.0.iso = ADDED PACKAGES = Package: python-nagiosplugin-1.3.2-1.fc35 Summary: Library for writing Nagios (Icinga) plugins RPMs:python3-nagiosplugin Size:61.27 KiB Package: rust-argh-0.1.5-1.fc35 Summary: Derive-based argument parser optimized for code size RPMs:rust-argh+default-devel rust-argh-devel Size:24.52 KiB Package: rust-argh_derive-0.1.5-1.fc35 Summary: Derive-based argument parsing optimized for code size RPMs:rust-argh_derive+default-devel rust-argh_derive-devel Size:32.01 KiB Package: rust-argh_shared-0.1.5-1.fc35 Summary: Derive-based argument parsing optimized for code size RPMs:rust-argh_shared+default-devel rust-argh_shared-devel Size:19.26 KiB Package: rust-bugreport-0.4.0-1.fc35 Summary: Collect system and environment information for bug reports RPMs:rust-bugreport+collector_operating_system-devel rust-bugreport+default-devel rust-bugreport+format_markdown-devel rust-bugreport+format_plaintext-devel rust-bugreport+git-version-devel rust-bugreport+git_hash-devel rust-bugreport+sys-info-devel rust-bugreport-devel Size:72.29 KiB Package: rust-fancy-regex-0.7.0-1.fc35 Summary: Implementation of regexes, supporting a relatively rich set of features RPMs:rust-fancy-regex+default-devel rust-fancy-regex+track_caller-devel rust-fancy-regex-devel Size:86.22 KiB Package: rust-filetreelist-0.2.0-1.fc35 Summary: Filetree abstraction based on a sorted path list RPMs:rust-filetreelist+default-devel rust-filetreelist-devel Size:891.60 KiB Package: rust-git-version-0.3.4-1.fc35 Summary: Compile the git version and dirty state into your program RPMs:rust-git-version+default-devel rust-git-version-devel Size:18.75 KiB Package: rust-git-version-macro-0.3.4-1.fc35 Summary: Internal macro crate for git-version RPMs:rust-git-version-macro+default-devel rust-git-version-macro+nightly-devel rust-git-version-macro-devel Size:25.50 KiB Package: rust-unicode-linebreak-0.1.1-1.fc35 Summary: Implementation of the Unicode Line Breaking Algorithm RPMs:rust-unicode-linebreak+default-devel rust-unicode-linebreak-devel Size:70.47 KiB Package: rust-unicode-truncate-0.2.0-1.fc35 Summary: Unicode-aware algorithm to pad or truncate `str` in terms of displayed width RPMs:rust-unicode-truncate+default-devel rust-unicode-truncate+std-devel rust-unicode-truncate-devel Size:32.30 KiB = DROPPED PACKAGES = = UPGRADED PACKAGES = Package: MUMPS-5.4.0-1.fc35 Old package: MUMPS-5.3.5-2.fc34 Summary: A MUltifrontal Massively Parallel sparse direct Solver RPMs: MUMPS MUMPS-common MUMPS-devel MUMPS-examples MUMPS-mpich MUMPS-mpich-devel MUMPS-mpich-examples MUMPS-openmpi MUMPS-openmpi-devel MUMPS-openmpi-examples MUMPS-srpm-macros Dropped RPMs: MUMPS-openmp MUMPS-openmp-devel MUMPS-openmp-examples Size: 54.02 MiB Size change: -23.04 MiB Changelog: * Fri Jul 16 2021 Antonio Trande - 5.4.0-1 - Release 5.4.0 Package: amg4psblas-1.0.0-3.fc35 Old package: amg4psblas-1.0.0-2.fc35 Summary: Algebraic Multigrid Package based on PSBLAS RPMs: amg4psblas-doc amg4psblas-mpich amg4psblas-mpich-devel amg4psblas-openmpi amg4psblas-openmpi-devel amg4psblas-serial amg4psblas-serial-devel Size: 1.54 GiB Size change: 4.18 KiB Changelog: * Sat Jul 17 2021 Antonio Trande - 1.0.0-3 - Rebuild for MUMPS-5.4.0 Package: ansible-lint-1:5.1.2-1.fc35 Old package: ansible-lint-1:5.0.12-1.fc35 Summary: Best practices checker for Ansible RPMs: python3-ansible-lint Size: 193.28 KiB Size change: 6.12 KiB Changelog: * Mon Jul 19 2021 Parag Nemade - 1:5.1.2-1 - Update to 5.1.2 version (#1983170) Package: coin-or-Ipopt-3.13.4-2.fc35 Old package: coin-or-Ipopt-3.13.4-1.fc35 Summary: Interior Point OPTimizer RPMs: coin-or-Ipopt coin-or-Ipopt-common coin-or-Ipopt-devel coin-or-Ipopt-mpich coin-or-Ipopt-mpich-devel coin-or-Ipopt-openmpi coin-or-Ipopt
Java packaging issue on EPEL7
Hello. Found a strange RPM autodeps issue, related to Java packaging, only on EPEL7. EPEL7 package contains additional auto-detected strict dependencies: osgi(com.github.jnr.jffi) and osgi(com.sun.jna). That's why the package cannot be installed due to lack of dependencies on RHEL/CentOS 7: Error: Package: pycharm-community-2021.1.3-1.el7.x86_64 (phracek-PyCharm) Requires: osgi(com.github.jnr.jffi) You could try using --skip-broken to work around the problem You could try running: rpm -Va --nofiles --nodigest EPEL7 package: Requires: /bin/sh /usr/bin/env libc.so.6()(64bit) libc.so.6(GLIBC_2.14)(64bit) libc.so.6(GLIBC_2.2.5)(64bit) libc.so.6(GLIBC_2.3)(64bit) libc.so.6(GLIBC_2.4)(64bit) osgi(com.github.jnr.jffi) osgi(com.sun.jna) rtld(GNU_HASH) EPEL8 package (uses the same pre-built binaries): Requires: /bin/sh /usr/bin/python3.6 libc.so.6()(64bit) libc.so.6(GLIBC_2.14)(64bit) libc.so.6(GLIBC_2.2.5)(64bit) libc.so.6(GLIBC_2.3)(64bit) libc.so.6(GLIBC_2.4)(64bit) rtld(GNU_HASH) Fedora: Requires: /usr/bin/python3 /usr/bin/sh libc.so.6()(64bit) libc.so.6(GLIBC_2.14)(64bit) libc.so.6(GLIBC_2.2.5)(64bit) libc.so.6(GLIBC_2.3)(64bit) libc.so.6(GLIBC_2.4)(64bit) rtld(GNU_HASH) Downstream issue: https://github.com/phracek/pycharm-community-edition/issues/62 SPEC file: https://github.com/phracek/pycharm-community-edition/blob/master/pycharm-community.spec How I can fix this? -- Sincerely, Vitaly Zaitsev (vit...@easycoding.org) ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Nest 2021 - any Lenovo questions/topics I should cover?
On Mon, Jul 19, 2021 at 11:52:59AM -0400, Mark Pearson wrote: > I'd much rather make sure I'm answering any questions the community > has - I figure that's more interesting than me blathering on. I > can't promise to answer everything, but will do my best. If you send > me any questions in the next few days that would be appreciated. So, things I've heard: * Why is the lag time so high (order now for ... Christmas?) * What about AMD? * What about ARM -- an M1 competitor? * More options? Lower-end systems? The higher-end ones with more RAM? * Pricing compared to pre-configured Windows systems? * What about... the world? And, my own personal questions: * How well is this doing? Does Lenovo see it as a success? * What can we do to make it even better from the Fedora side? -- Matthew Miller Fedora Project Leader ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F35 Change: Switch to WirePlumber as the PipeWire session manage (late Self-Contained Change proposal)
It would be great if the "How to test" section would include some steps on how to switch to WirePlumber so that anything can be tested. On Mon, Jul 19, 2021 at 6:18 PM Ben Cotton wrote: > https://fedoraproject.org/wiki/Changes/WirePlumber > > == Summary == > PipeWire currently uses a simple example session manager. This > proposal is to move to the more powerful WirePlumber session manager. > > == Owner == > * Name: [[User:Wtaymans| Wim Taymans]] > * Email: wim.taym...@gmail.com > > == Detailed Description == > PipeWire requires a session manager that at least needs to implements > the following features: > > * create and configure detected devices in the system. This includes > audio cards, video and bluetooth devices. > * configure applications and route audio/video to/from them to the > devices and filters. > * keep track of prefered devices and volumes. > * move audio/video streams when devices appear and disappear. > > PipeWire uses a simple example session manager with limited features > and configuration options. The proposal is to > move to WirePlumber. > > WirePlumber is built on GNOME (GObject) technologies and has bindings > for most languages using GObject introspection. > > WirePlumber allows one to implement many of the rules for setup and > configuration using small LUA scripts, which are > easier to maintain and customize. These are some of the functions that > are scriptable in LUA: > > * setup and configuration of the devices and streams. This includes > deciding if devices and streams need to operate in 5.1 or stereo mode, > depending on the available devices. > * routing of the streams based on metadata of the streams (Roles) and > overall state of the system. > * volume/mute restore of devices and streams > > > == Benefit to Fedora == > > PipeWire currently uses a simple example session manager with mostly > hardcoded logic and rules. This proposal wants to replace the session > manager with a more advanced session manager, called WirePlumber. > > WirePlumber brings to following improvements > > * Drop-in replacement session manager for PipeWire, implements the > exact same features as the example session manager > * built with GObject, which provides a richer development experience > and adds bindings for most languages > * extensible with loadable modules > * scriptable policy using small lua scripts > * better integration with desktop settings > > The main benefits will be that this session manager would allow for > more customization of the policy > and rules. Initially we aim for feature parity with the current > solution and work on more features > in the next releases. > > == Scope == > * Proposal owners: > This is a rather isolated changed. Instead of starting the > pipewire-media-session executable we would need to package > and start WirePlumber instead. > > WirePlumber has been kept up to data with the features in the example > session manager and would need testing. > > * Other developers: None. This is an isolated PipeWire change. > * Release engineering: A new systemd service will need to be activated > in the default install. > * Policies and guidelines: N/A (not needed for this Change) > * Trademark approval: N/A (not needed for this Change) > * Alignment with Objectives: > > == Upgrade/compatibility impact == > Should not cause any change. > > == How To Test == > > Experience should be the same as before. Retest all audio testcases. > > > == User Experience == > Should not cause any visible change. > > > == Dependencies == > None. > > == Contingency Plan == > * Contingency mechanism: (What to do? Who will do it?): If the > feature can not be completed we continue using the existing > pipewire-media-session. > * Contingency deadline: N/A (not a System Wide Change) > * Blocks release? N/A (not a System Wide Change) > > > == Documentation == > [WirePlumber](https://gitlab.freedesktop.org/pipewire/wireplumber) > > > > > > -- > Ben Cotton > He / Him / His > Fedora Program Manager > Red Hat > TZ=America/Indiana/Indianapolis > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > Do not reply to spam on the list, report it: > https://pagure.io/fedora-infrastructure > ___ 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
F35 Change: Switch to WirePlumber as the PipeWire session manage (late Self-Contained Change proposal)
https://fedoraproject.org/wiki/Changes/WirePlumber == Summary == PipeWire currently uses a simple example session manager. This proposal is to move to the more powerful WirePlumber session manager. == Owner == * Name: [[User:Wtaymans| Wim Taymans]] * Email: wim.taym...@gmail.com == Detailed Description == PipeWire requires a session manager that at least needs to implements the following features: * create and configure detected devices in the system. This includes audio cards, video and bluetooth devices. * configure applications and route audio/video to/from them to the devices and filters. * keep track of prefered devices and volumes. * move audio/video streams when devices appear and disappear. PipeWire uses a simple example session manager with limited features and configuration options. The proposal is to move to WirePlumber. WirePlumber is built on GNOME (GObject) technologies and has bindings for most languages using GObject introspection. WirePlumber allows one to implement many of the rules for setup and configuration using small LUA scripts, which are easier to maintain and customize. These are some of the functions that are scriptable in LUA: * setup and configuration of the devices and streams. This includes deciding if devices and streams need to operate in 5.1 or stereo mode, depending on the available devices. * routing of the streams based on metadata of the streams (Roles) and overall state of the system. * volume/mute restore of devices and streams == Benefit to Fedora == PipeWire currently uses a simple example session manager with mostly hardcoded logic and rules. This proposal wants to replace the session manager with a more advanced session manager, called WirePlumber. WirePlumber brings to following improvements * Drop-in replacement session manager for PipeWire, implements the exact same features as the example session manager * built with GObject, which provides a richer development experience and adds bindings for most languages * extensible with loadable modules * scriptable policy using small lua scripts * better integration with desktop settings The main benefits will be that this session manager would allow for more customization of the policy and rules. Initially we aim for feature parity with the current solution and work on more features in the next releases. == Scope == * Proposal owners: This is a rather isolated changed. Instead of starting the pipewire-media-session executable we would need to package and start WirePlumber instead. WirePlumber has been kept up to data with the features in the example session manager and would need testing. * Other developers: None. This is an isolated PipeWire change. * Release engineering: A new systemd service will need to be activated in the default install. * Policies and guidelines: N/A (not needed for this Change) * Trademark approval: N/A (not needed for this Change) * Alignment with Objectives: == Upgrade/compatibility impact == Should not cause any change. == How To Test == Experience should be the same as before. Retest all audio testcases. == User Experience == Should not cause any visible change. == Dependencies == None. == Contingency Plan == * Contingency mechanism: (What to do? Who will do it?): If the feature can not be completed we continue using the existing pipewire-media-session. * Contingency deadline: N/A (not a System Wide Change) * Blocks release? N/A (not a System Wide Change) == Documentation == [WirePlumber](https://gitlab.freedesktop.org/pipewire/wireplumber) -- Ben Cotton He / Him / His Fedora Program Manager Red Hat TZ=America/Indiana/Indianapolis ___ devel-announce mailing list -- devel-announce@lists.fedoraproject.org To unsubscribe send an email to devel-announce-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel-announce@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
F35 Change: Switch to WirePlumber as the PipeWire session manage (late Self-Contained Change proposal)
https://fedoraproject.org/wiki/Changes/WirePlumber == Summary == PipeWire currently uses a simple example session manager. This proposal is to move to the more powerful WirePlumber session manager. == Owner == * Name: [[User:Wtaymans| Wim Taymans]] * Email: wim.taym...@gmail.com == Detailed Description == PipeWire requires a session manager that at least needs to implements the following features: * create and configure detected devices in the system. This includes audio cards, video and bluetooth devices. * configure applications and route audio/video to/from them to the devices and filters. * keep track of prefered devices and volumes. * move audio/video streams when devices appear and disappear. PipeWire uses a simple example session manager with limited features and configuration options. The proposal is to move to WirePlumber. WirePlumber is built on GNOME (GObject) technologies and has bindings for most languages using GObject introspection. WirePlumber allows one to implement many of the rules for setup and configuration using small LUA scripts, which are easier to maintain and customize. These are some of the functions that are scriptable in LUA: * setup and configuration of the devices and streams. This includes deciding if devices and streams need to operate in 5.1 or stereo mode, depending on the available devices. * routing of the streams based on metadata of the streams (Roles) and overall state of the system. * volume/mute restore of devices and streams == Benefit to Fedora == PipeWire currently uses a simple example session manager with mostly hardcoded logic and rules. This proposal wants to replace the session manager with a more advanced session manager, called WirePlumber. WirePlumber brings to following improvements * Drop-in replacement session manager for PipeWire, implements the exact same features as the example session manager * built with GObject, which provides a richer development experience and adds bindings for most languages * extensible with loadable modules * scriptable policy using small lua scripts * better integration with desktop settings The main benefits will be that this session manager would allow for more customization of the policy and rules. Initially we aim for feature parity with the current solution and work on more features in the next releases. == Scope == * Proposal owners: This is a rather isolated changed. Instead of starting the pipewire-media-session executable we would need to package and start WirePlumber instead. WirePlumber has been kept up to data with the features in the example session manager and would need testing. * Other developers: None. This is an isolated PipeWire change. * Release engineering: A new systemd service will need to be activated in the default install. * Policies and guidelines: N/A (not needed for this Change) * Trademark approval: N/A (not needed for this Change) * Alignment with Objectives: == Upgrade/compatibility impact == Should not cause any change. == How To Test == Experience should be the same as before. Retest all audio testcases. == User Experience == Should not cause any visible change. == Dependencies == None. == Contingency Plan == * Contingency mechanism: (What to do? Who will do it?): If the feature can not be completed we continue using the existing pipewire-media-session. * Contingency deadline: N/A (not a System Wide Change) * Blocks release? N/A (not a System Wide Change) == Documentation == [WirePlumber](https://gitlab.freedesktop.org/pipewire/wireplumber) -- Ben Cotton He / Him / His Fedora Program Manager Red Hat TZ=America/Indiana/Indianapolis ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Orphaned packages looking for new maintainers
I have taken rust-ab_glyph_rasterizer and rust-owned_ttf_parser since i will need them for a future package. Sent with ProtonMail Secure Email. ‐‐‐ Original Message ‐‐‐ Le lundi 19 juillet 2021 à 03:49, Miro Hrončok a écrit : > The following packages are orphaned and will be retired when they > > are orphaned for six weeks, unless someone adopts them. If you know for sure > > that the package should be retired, please do so now with a proper reason: > > https://fedoraproject.org/wiki/How_to_remove_a_package_at_end_of_life > > Note: If you received this mail directly you (co)maintain one of the affected > > packages or a package that depends on one. Please adopt the affected package > or > > retire your depending package to avoid broken dependencies, otherwise your > > package will fail to install and/or build when the affected package gets > retired. > > Request package ownership via the Take button in he left column on > > https://src.fedoraproject.org/rpms/ > > Full report available at: > > https://churchyard.fedorapeople.org/orphans-2021-07-19.txt > > grep it for your FAS username and follow the dependency chain. > > For human readable dependency chains, > > see https://packager-dashboard.fedoraproject.org/ > > For all orphaned packages, > > see https://packager-dashboard.fedoraproject.org/orphan > > Package (co)maintainers Status Change > = > > 8sync orphan 3 weeks ago > > HdrHistogram acaringi, almac, hhorak, 4 weeks ago > > jvanek, orphan > > JSCookMenu orphan 4 weeks ago > > WebCalendar orphan 4 weeks ago > > apache-ivy java-maint-sig, mizdebsk, 0 weeks ago > > orphan > > biboumi louizatakk, orphan 4 weeks ago > > erlang-riak_pipe bowlofeggs, erlang-maint-sig, 5 weeks ago > > orphan > > java-atk-wrapper omajid, orphan 5 weeks ago > > jboss-annotations-1.2-api cfu, ckelley, dmoluguw, 4 weeks ago > > jmagne, mharmsen, orphan > > jmc almac, orphan, sasiddiq 4 weeks ago > > jmc-core almac, orphan, sasiddiq 4 weeks ago > > js-gl-matrix orphan 3 weeks ago > > libi40iw orphan, tatyana 0 weeks ago > > linuxcnc orphan 0 weeks ago > > lz4-java orphan 4 weeks ago > > mate-applet-softupd orphan 4 weeks ago > > mvel orphan 4 weeks ago > > owasp-java-encoder almac, orphan, sasiddiq 4 weeks ago > > php-PHPMailer orphan, remi 4 weeks ago > > php-captchaphp orphan 4 weeks ago > > php-hkit orphan 4 weeks ago > > php-pear-Auth-Yubico orphan 4 weeks ago > > php-rmccue-requests orphan 5 weeks ago > > python-glusterfs-api humble, orphan 4 weeks ago > > python-jsonrpcserver orphan 3 weeks ago > > python-nose-cov orphan 3 weeks ago > > python-nss jmagne, orphan 3 weeks ago > > python-pytest-helpers-namespace orion, orphan, python-sig 1 weeks ago > > python-pytest-relaxed orphan 4 weeks ago > > python-ruamel-std-pathlib orphan 0 weeks ago > > python-setuptools-lint orphan 3 weeks ago > > python-testfixtures orphan 0 weeks ago > > python-urlobject orphan 3 weeks ago > > python-vsc-install orphan 0 weeks ago > > qtile cicku, orphan 3 weeks ago > > rubygem-expression_parser orphan 3 weeks ago > > rubygem-fssm orphan 3 weeks ago > > rubygem-sdoc orphan 5 weeks ago > > rust-ab_glyph_rasterizer orphan, rust-sig 0 weeks ago > > rust-line_drawing orphan, rust-sig 0 weeks ago > > rust-owned_ttf_parser orphan, rust-sig 0 weeks ago > > rust-palette orphan, rust-sig 0 weeks ago > > rust-palette_derive orphan, rust-sig 0 weeks ago > > rust-tower-test orphan, rust-sig 0 weeks ago > > rust-tower-util orphan, rust-sig 0 weeks ago > > rust-tzfile orphan, rust-sig 0 weeks ago > > spectrwm larsks, lsm5, orphan 0 weeks ago > > stax2-api cfu, ckelley, java-maint-sig, 4 weeks ago > > jmagne, mharmsen, mizdebsk, > > orphan > > woodstox-core cfu, ckelley, java-maint-sig, 4 weeks ago > > jmagne, mharmsen, mizdebsk, > > orphan > > The following packages require above mentioned packages: > > Report too long, see the full version at > > https://churchyard.fedorapeople.org/orphans-2021-07-19.txt > > See dependency chains of your packages at > > https://packager-dashboard.fedoraproject.org/ > > See all orphaned packages at > https://packager-dashboard.fedoraproject.org/orphan > > Affected (co)maintainers (either directly or via packages' dependencies): > > acaringi: HdrHistogram > > ahughes: jmc, owasp-java-encoder, HdrHistogram, jmc-core > > akurtakov: apache-ivy, jmc-core, HdrHistogram, jmc, owasp-java-encoder > > almac: jmc, owasp-java-encoder, HdrHistogram, jmc-core > > amdunn: apache-ivy > > arobinso:
Re: F35 Change: Filtered Flathub Applications (System-Wide Change proposal)
Ben, FESCO: Thank you for your decision to destroy Silverblue, the best thing Fedora has done in the last 10 years. The only thing that makes Silverblue useful -- indeed, superior -- as a desktop is the ready availability of Flatpaks for any application the user could want. Unlike old-fashioned Fedora, modifying Fedora to accept the regular Flathub is a multi-step operation, and not one that's easy for standard users. This has allowed us to finally break out of the longstanding Fedora issue of "Sorry, I can't access that app because I'm on Fedora". For the last 3 years, Silverblue has spread through the developer ecosystem because it's the best immutable desktop. For a short time I dared hope that we'd retake desktop primacy from Ubuntu! But I should have known better. If another vendor like Ubuntu or Docker were to do this kind of surprise filtering of apps, Fedora would attack it and write long blogs taking a stance on user choice and against vendors using their influence to spread vertical monopolies. But I guess it's OK if Fedora does it? If y'all want folks to use Fedora Flatpaks instead of Flathub ones, the answer is to **make more applications available** via Fedora Flatpaks. Not to restrict user choice through underhanded BS like this move. ___ 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
Nest 2021 - any Lenovo questions/topics I should cover?
Hi Fedorans Lenovo are sponsoring Nest this year but unfortunately it clashes with my family holiday and so I won't be able to attend the event itself - I'll be by a lake in a cottage with no network access... I'm really disappointed to be missing Nest as I really enjoyed it last year. Hopefully some of the other members of the Lenovo team will join this year - I'm encouraging them to do so. I was planning on pre-recording a video with some updates on the Lenovo Fedora program - covering some of the high and low lights and (if I'm allowed) some of what's coming up. I'd much rather make sure I'm answering any questions the community has - I figure that's more interesting than me blathering on. I can't promise to answer everything, but will do my best. If you send me any questions in the next few days that would be appreciated. Thanks Mark ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Heads-up: python-engineio v4 / python-socketio v5
I claimed python-engineio, python-socketio, and python-flask-socketio after they were orphaned. I also claimed python-aiozmq. It does not currently work with Python 3.10, but it’s likely that upstream will get it fixed in time for Fedora 35. I probably will not claim python-jsonrpcserver, which is still orphaned. (If you, the reader, do want to claim it, I’m happy to send you a PR to update the packaging as I did for the other packages, and to work around the currently-missing python-aiozmq in Rawhide. I just don’t want to maintain this package.) In one week, I will update python-engineio to 4.2.0 (https://src.fedoraproject.org/rpms/python-engineio/pull-request/1), python-socketio to 5.3.0 (https://src.fedoraproject.org/rpms/python-socketio/pull-request/1), and python-flask-socketio to 5.1.0 (https://src.fedoraproject.org/rpms/python-flask-socketio/pull-request/1), all in Rawhide only. These are all breaking major version updates that introduce EngineIO protocol version 4 and SocketIO protocol version 5. The updates shouldn’t directly affect anything in Fedora at the moment, except perhaps the orphaned python-jsonrpcserver package. Still, the new versions will be built in a side tag as a multi-build update. ___ 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: Why so long for EPEL-8?
On Mon, Jul 19, 2021 at 7:06 AM Björn Persson wrote: > > I suspect that many users are like me: I don't want to constantly be a > guinea-pig for the whole testing repository, but if I could be notified > about updates of certain packages I'm interested in, then I could > choose to test those if I'm not too busy at the time. I don't know a > convenient way to do that, so I end up installing updates when they > show up in the updates repository. Exactly. If I see a user commenting in Bugzilla or giving feedback on current Bodhi updates, I make a mental note that the person could be interested in participating in the future. When I push future updates, I'll send them a quick email asking them to test the update and add +1 in Bodhi. It's not perfect but it helps. I recently did this for a random Ceph dependency update to fix a bug, and was very helpful. Sometimes users don't realize it's that easy. - Ken ___ 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: Why so long for EPEL-8?
On Mon, Jul 19, 2021 at 07:59:11AM -0400, Stephen John Smoogen wrote: > On Mon, 19 Jul 2021 at 07:06, Björn Persson wrote: > > > > Vitaly Zaitsev via devel wrote: > > > On 18/07/2021 13:38, Neal Gompa wrote: > > > > 1. People don't give feedback and only complain after the fact. > > > > > > On Fedora too. Only a few popular packages (kernel, firefox, > > > thunderbird) get user feedback on Bodhi. All others will need to stay in > > > testing for 7 days. > > > > I suspect that many users are like me: I don't want to constantly be a > > guinea-pig for the whole testing repository, but if I could be notified > > I expect that this is so, but I think the idea of not being a 'guinea > pig' is off. People are going to be guinea-pigs one way or another.. > either they take the time to test it or they get to test it when it > gets pushed automatically into production. So maybe putting off the > pain for 2 weeks isn't doing anything for anyone? I think some (many?) people have some machines with updates-testing enabled. I do on my laptop, and this catches the occasional bug in an update. I report negative karma almost exclusively, because I don't do any proactive testing of updates, so usually I don't have the basis to say that an update is "good". But the time spent in updates-testing is still useful for some form of testing. 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
Logs from Open NeuroFedora Meeting: 1300 UTC on Monday, 19th July (Today)
Hi folks, Please find the logs from today's meeting below. The next meeting will be in two weeks. === #fedora-neuro: NeuroFedora - 2021-07-19 === Meeting started by FranciscoD at 13:02:46 UTC. The full logs are available at https://meetbot.fedoraproject.org/fedora-neuro/2021-07-19/neurofedora.2021-07-19-13.02.log.html . Meeting summary --- * Agenda (FranciscoD, 13:05:34) * New introductions and roll call (FranciscoD, 13:06:02) * Tasks from last meeting (FranciscoD, 13:06:07) * Open Pagure tickets (FranciscoD, 13:06:13) * Open package reviews check (FranciscoD, 13:06:18) * Package health check (FranciscoD, 13:06:26) * CompNeuro compose check (FranciscoD, 13:06:36) * Query of the week (FranciscoD, 13:06:43) * Next meeting chair, time (FranciscoD, 13:06:53) * Open floor (FranciscoD, 13:06:57) * New introductions and roll call (FranciscoD, 13:07:04) * bittin sends regrets: busy with GUADEC (FranciscoD, 13:12:27) * Tasks from last meeting (FranciscoD, 13:14:40) * Last meeting minutes are here: https://meetbot.fedoraproject.org/teams/neurofedora/neurofedora.2021-06-21-13.02.html (FranciscoD, 13:14:52) * MeWjOr finish packaging remaining Snakemake deps: DONE (FranciscoD, 13:15:41) * ACTION: MeWjOr add new packages to docs (FranciscoD, 13:17:32) * neuro-sig go over their packages to fix FTBFS and FTI bugs: WIP (FranciscoD, 13:17:51) * ACTION: neuro-sig go over their packages to fix FTBFS and FTI bugs (FranciscoD, 13:18:05) * neuro-sig go over their packages to fix FTBFS and FTI bugs: WIP (FranciscoD, 13:18:16) * ACTION: neuro-sig go over their packages to fix FTBFS and FTI bugs (FranciscoD, 13:18:29) * Open Pagure tickets (FranciscoD, 13:18:52) * Here: https://pagure.io/neuro-sig/NeuroFedora/issues?status=Open=S%3A+Next+meeting (FranciscoD, 13:19:03) * Packages health check (FranciscoD, 13:21:36) * Neuro-sig packager dashboard is here: https://packager-dashboard.fedoraproject.org/neuro-sig (FranciscoD, 13:21:49) * Packages are in good health, we continue working on FTI/FTBFS issues and updataes (FranciscoD, 13:28:59) * Open package reviews check (FranciscoD, 13:29:10) * WIP PR for SALib update: https://src.fedoraproject.org/rpms/python-SALib/pull-request/2 (FranciscoD, 13:32:33) * CompNeuro compose status check (FranciscoD, 13:35:21) * Koji task: https://koji.fedoraproject.org/koji/packageinfo?packageID=30691 (FranciscoD, 13:35:27) * Compose is OK: building nicely (FranciscoD, 13:35:41) * Query of the week (FranciscoD, 13:35:55) * Next meeting chair, day (FranciscoD, 13:37:01) * Next meeting at 1300 UTC in 2 weeks (FranciscoD, 13:39:46) * FranciscoD chair next meeting (FranciscoD, 13:44:45) * Open floor (FranciscoD, 13:44:52) * The Bernstein conference will be held online this year, and is free to register for: https://www.bernstein-network.de/en/bernstein-conference/2021-online (FranciscoD, 13:45:16) * ACTION: MeWjOr create ticket for our submission to NEST (FranciscoD, 13:50:01) * ACTION: FranciscoD send out logs (FranciscoD, 13:53:55) * ACTION: FranciscoD reply to twitter thread with log link (FranciscoD, 13:54:04) Meeting ended at 13:55:14 UTC. Action Items * MeWjOr add new packages to docs * neuro-sig go over their packages to fix FTBFS and FTI bugs * neuro-sig go over their packages to fix FTBFS and FTI bugs * MeWjOr create ticket for our submission to NEST * FranciscoD send out logs * FranciscoD reply to twitter thread with log link Action Items, by person --- * FranciscoD * FranciscoD send out logs * FranciscoD reply to twitter thread with log link * MeWjOr * MeWjOr add new packages to docs * MeWjOr create ticket for our submission to NEST * neuro-sig * neuro-sig go over their packages to fix FTBFS and FTI bugs * neuro-sig go over their packages to fix FTBFS and FTI bugs * **UNASSIGNED** * (none) People Present (lines said) --- * FranciscoD (156) * MeWjOr (38) * omnidapps[m] (14) * zodbot (12) * major (0) * neuro-sig (0) * principis (0) * coremodule (0) * bittin (0) * zyn-kun[m] (0) * jnsamyak (0) Generated by `MeetBot`_ 0.1.4 .. _`MeetBot`: http://wiki.debian.org/MeetBot -- 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:
Re: Why so long for EPEL-8?
* Björn Persson [19/07/2021 13:05] : > > but if I could be notified > about updates of certain packages I'm interested in, then I could > choose to test those if I'm not too busy at the time. I don't know a > convenient way to do that, so I end up installing updates when they > show up in the updates repository. There are a number of options that I can see: 1) Bodhi has an RSS feed that you can apply filters to. I'm not sure if you can select packages you want to follow, though. 2) You can sign up as co-maintainer of the package on the EPEL branches. This will give you email notifications on pretty much anything that happens on those branches. 3) Bugzilla generates RSS feeds for virtually any list. You can follow bug activity via those. Emmanuel ___ 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
fail2banb: SELinux denices access to log file on nfs share
I'm trying to understand if this[1] is something I can account for
*properly* in the package's SELinux policy or if this is a case where the
end user really needs to modify their own.
type=AVC msg=audit(1626675276.055:38476): avc: denied { read } for
pid=2143832 comm="fail2ban-server" name="nextcloud_data" dev="dm-4"
ino=4199669 scontext=system_u:system_r:fail2ban_t:s0
tcontext=system_u:object_r:httpd_sys_rw_content_t:s0 tclass=lnk_file
permissive=0
Thanks,
Richard
[1] https://bugzilla.redhat.com/show_bug.cgi?id=1983564
___
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: tzdata-minimal (Self-Contained Change proposal)
On 15. 07. 21 20:33, Carlos O'Donell wrote: On 7/15/21 6:34 AM, Zbigniew Jędrzejewski-Szmek wrote: On Tue, Jul 06, 2021 at 01:20:47PM -0400, Ben Cotton wrote: https://fedoraproject.org/wiki/Changes/tzdata-minimal == Summary == Split the tzdata package into two parts - tzdata and tzdata-minimal. tzdata will require tzdata-minimal. tzdata-minimal provides the minimal files needed to support UTC on containers. == Owner == * Name: Patsy Griffin (Franklin) * Email: pa...@redhat.com == Detailed Description == This is the first step towards providing support for a minimal, UTC only, version of tzdata for containers. The tzdata-minimal package will be a stand-alone, UTC only, subset of tzdata. The tzdata package will require tzdata-minimal. With this framework in place, other packages can develop code to detect a minimal tzdata installation. These packages will also need to provide appropriate messages when users request timezone information not available when only tzdata-minimal is installed. In general, I like the idea of making it easier to not install tzdata. For many machines it's completely unnecessary, and 5MB is enough to make this worthwhile. Thanks for supporting the idea. I don't know enough about all the consumers to comment on the details. FWIW, systemd-timedated already has a reasonable message that encompasses both possible errors: $ timedatectl set-timezone Europe/Warsaw2 Failed to set time zone: Invalid or not installed time zone 'Europe/Warsaw2' But I think it'd be useful to use a different message if we can distinguish the two cases. I'd be happy to take a patch... Yes, you could say "invalid" (zone table files installed) if the zone is not in one of the tables, and "invalid or not installed" if there are no files (no tzdata installed). Without the split (i.e. if either all or none of tzdata is installed), it would be similar: If a zone1970.tab exists but doesn't list the zone (or, hopefully equivalently: a zone1970.tab exists but there's no file for the zone): it's "Invalid time zone". If the table doesn't exist: it's "Invalid or not installed". We are still in the process of checking with upstream tzdata if they are comfortable with, and will support *not* installing some of the zones, and document that upstream. ___ 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
Orphaned packages looking for new maintainers
The following packages are orphaned and will be retired when they are orphaned for six weeks, unless someone adopts them. If you know for sure that the package should be retired, please do so now with a proper reason: https://fedoraproject.org/wiki/How_to_remove_a_package_at_end_of_life Note: If you received this mail directly you (co)maintain one of the affected packages or a package that depends on one. Please adopt the affected package or retire your depending package to avoid broken dependencies, otherwise your package will fail to install and/or build when the affected package gets retired. Request package ownership via the *Take* button in he left column on https://src.fedoraproject.org/rpms/ Full report available at: https://churchyard.fedorapeople.org/orphans-2021-07-19.txt grep it for your FAS username and follow the dependency chain. For human readable dependency chains, see https://packager-dashboard.fedoraproject.org/ For all orphaned packages, see https://packager-dashboard.fedoraproject.org/orphan Package (co)maintainers Status Change 8sync orphan 3 weeks ago HdrHistogram acaringi, almac, hhorak, 4 weeks ago jvanek, orphan JSCookMenuorphan 4 weeks ago WebCalendar orphan 4 weeks ago apache-ivyjava-maint-sig, mizdebsk,0 weeks ago orphan biboumi louizatakk, orphan 4 weeks ago erlang-riak_pipe bowlofeggs, erlang-maint-sig,5 weeks ago orphan java-atk-wrapper omajid, orphan 5 weeks ago jboss-annotations-1.2-api cfu, ckelley, dmoluguw, 4 weeks ago jmagne, mharmsen, orphan jmc almac, orphan, sasiddiq 4 weeks ago jmc-core almac, orphan, sasiddiq 4 weeks ago js-gl-matrix orphan 3 weeks ago libi40iw orphan, tatyana 0 weeks ago linuxcnc orphan 0 weeks ago lz4-java orphan 4 weeks ago mate-applet-softupd orphan 4 weeks ago mvel orphan 4 weeks ago owasp-java-encoderalmac, orphan, sasiddiq 4 weeks ago php-PHPMailer orphan, remi 4 weeks ago php-captchaphporphan 4 weeks ago php-hkit orphan 4 weeks ago php-pear-Auth-Yubico orphan 4 weeks ago php-rmccue-requests orphan 5 weeks ago python-glusterfs-api humble, orphan 4 weeks ago python-jsonrpcserver orphan 3 weeks ago python-nose-cov orphan 3 weeks ago python-nssjmagne, orphan 3 weeks ago python-pytest-helpers-namespace orion, orphan, python-sig1 weeks ago python-pytest-relaxed orphan 4 weeks ago python-ruamel-std-pathlib orphan 0 weeks ago python-setuptools-lintorphan 3 weeks ago python-testfixtures orphan 0 weeks ago python-urlobject orphan 3 weeks ago python-vsc-installorphan 0 weeks ago qtile cicku, orphan3 weeks ago rubygem-expression_parser orphan 3 weeks ago rubygem-fssm orphan 3 weeks ago rubygem-sdoc orphan 5 weeks ago rust-ab_glyph_rasterizer orphan, rust-sig 0 weeks ago rust-line_drawing orphan, rust-sig 0 weeks ago rust-owned_ttf_parser orphan, rust-sig 0 weeks ago rust-palette orphan, rust-sig 0 weeks ago rust-palette_derive orphan, rust-sig 0 weeks ago rust-tower-test orphan, rust-sig 0 weeks ago rust-tower-util orphan, rust-sig 0 weeks ago rust-tzfile orphan, rust-sig
Re: Why so long for EPEL-8?
On Mon, 19 Jul 2021 at 07:06, Björn Persson wrote: > > Vitaly Zaitsev via devel wrote: > > On 18/07/2021 13:38, Neal Gompa wrote: > > > 1. People don't give feedback and only complain after the fact. > > > > On Fedora too. Only a few popular packages (kernel, firefox, > > thunderbird) get user feedback on Bodhi. All others will need to stay in > > testing for 7 days. > > I suspect that many users are like me: I don't want to constantly be a > guinea-pig for the whole testing repository, but if I could be notified I expect that this is so, but I think the idea of not being a 'guinea pig' is off. People are going to be guinea-pigs one way or another.. either they take the time to test it or they get to test it when it gets pushed automatically into production. So maybe putting off the pain for 2 weeks isn't doing anything for anyone? -- Stephen J Smoogen. I've seen things you people wouldn't believe. Flame wars in sci.astro.orion. I have seen SPAM filters overload because of Godwin's Law. All those moments will be lost in time... like posts on BBS... time to reboot. ___ 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: Why so long for EPEL-8?
Vitaly Zaitsev via devel wrote: > On 18/07/2021 13:38, Neal Gompa wrote: > > 1. People don't give feedback and only complain after the fact. > > On Fedora too. Only a few popular packages (kernel, firefox, > thunderbird) get user feedback on Bodhi. All others will need to stay in > testing for 7 days. I suspect that many users are like me: I don't want to constantly be a guinea-pig for the whole testing repository, but if I could be notified about updates of certain packages I'm interested in, then I could choose to test those if I'm not too busy at the time. I don't know a convenient way to do that, so I end up installing updates when they show up in the updates repository. Björn Persson pgpvoA3f6hGTK.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://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: Why so long for EPEL-8?
On Mon, Jul 19, 2021 at 12:06 PM Jiri Vanek wrote: > > On 7/17/21 11:15 PM, Ron Olson wrote: > > Hey all- > > > > I’m curious as to why submitting a new build to Bodhi takes a week to be > > pushed to stable, but two weeks for EPEL-8. Is the presumption that it’s > > just that much more time for folks to test and verify? > > lack of reviewers, so longer in buildroot is kinda test... Surely not? The user base of EPEL is, by some measures, considerably bigger than the user base of Fedora. Those users might not participate in testing as much, because they rely on the stability of their systems more, but this is certainly not a *lack of reviewers*. Additionally, builds that are in the "testing" state are not tagged into the buildroot until they reach "stable" status, unless buildroot overrides are created for them, so "time spent in buildroot" makes no sense as an argument for builds in updates-testing, either. Fabio ___ 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: Review swaps: A bunch of PHP libraries
On 2021-07-19 11:58, Tomas Korbar wrote: Hi guys, I will review https://bugzilla.redhat.com/show_bug.cgi?id=1982618 and https://bugzilla.redhat.com/show_bug.cgi?id=1982621 Thanks. Note that php-giggsey-libphonenumber-for-php requires php-giggsey-locale, which is also not in the repos yet. For exchange could you Christopher please review https://bugzilla.redhat.com/show_bug.cgi?id=1983601 ? Sure. ___ 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: Why so long for EPEL-8?
On 7/17/21 11:15 PM, Ron Olson wrote: Hey all- I’m curious as to why submitting a new build to Bodhi takes a week to be pushed to stable, but two weeks for EPEL-8. Is the presumption that it’s just that much more time for folks to test and verify? lack of reviewers, so longer in buildroot is kinda test... Ron ___ 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 -- Jiri Vanek Mgr. Principal QA Software Engineer Red Hat Inc. +420 775 39 01 09 ___ 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: Review swaps: A bunch of PHP libraries
Hi guys, I will review https://bugzilla.redhat.com/show_bug.cgi?id=1982618 and https://bugzilla.redhat.com/show_bug.cgi?id=1982621 For exchange could you Christopher please review https://bugzilla.redhat.com/show_bug.cgi?id=1983601 ? On Sun, Jul 18, 2021 at 8:40 PM Christopher Engelhard wrote: > On 18.07.21 16:06, Otto Urpelainen wrote: > > mt32emu - C/C++ library for emulating Roland MT-32, CM-32L and LAPC-I > > synthesizer modules > > A cmake project that is somewhat complicated by the fact that it comes > > from a monorepo that also contains other related projects. > > https://bugzilla.redhat.com/show_bug.cgi?id=1980482 > > > > rubygem-sync - A module that provides a two-phase lock with a counter > > Ruby library whose specfile was automatically generated with gem2rpm, > > only small adjustements were needed on top of that. > > https://bugzilla.redhat.com/show_bug.cgi?id=1978395 > > Sure, I'd be happy to. And thanks. > > Christopher > ___ > 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-Cloud-34-20210719.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-20210718.0): ID: 930768 Test: x86_64 Cloud_Base-qcow2-qcow2 cloud_autocloud URL: https://openqa.fedoraproject.org/tests/930768 ID: 930777 Test: aarch64 Cloud_Base-qcow2-qcow2 cloud_autocloud@uefi URL: https://openqa.fedoraproject.org/tests/930777 Passed openQA tests: 7/8 (x86_64), 7/8 (aarch64) -- Mail generated by check-compose: https://pagure.io/fedora-qa/check-compose ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[Bug 1938300] perl-WWW-Shorten-3.094 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1938300 Jitka Plesnikova changed: What|Removed |Added Status|NEW |CLOSED CC||jples...@redhat.com Fixed In Version||perl-WWW-Shorten-3.094-1.fc ||35 Resolution|--- |RAWHIDE Assignee|jd...@aquezada.com |jples...@redhat.com Doc Type|--- |If docs needed, set a value Last Closed||2021-07-19 09:06: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://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: Why so long for EPEL-8?
On Mon, Jul 19, 2021 at 10:09:28AM +0200, Vitaly Zaitsev via devel wrote: > > 1. People don't give feedback and only complain after the fact. > > On Fedora too. Only a few popular packages (kernel, firefox, thunderbird) > get user feedback on Bodhi. All others will need to stay in testing for 7 > days. Are there stats to show this ? 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: rpmautospec deployment into production
Otto Urpelainen writes: > Dan Čermák kirjoitti 18.7.2021 klo 23.38: >> Otto Urpelainen writes: >> >>> Dan Čermák kirjoitti 17.7.2021 klo 23.10: Robert-André Mauchin writes: > What is the situation wrt new packages? Should we enforce the use of > rpmautospec during reviews or is it completely optional? I think we should encourage the usage of rpmautospec for new packages, provided that the packager feels comfortable enough to use it. E.g. I wouldn't suggest it for someone's first package. But this shouldn't become a *MUST*, at least not yet. >>> >>> I am curious regarding the reasons for not recommending rpmautospec for >>> new maintainers? It is an automation feature that removes manual steps >>> from the process. Using it is simpler than doing the same manually. I >>> think we should offer the simplest possible process for newcomers and >>> only recommend manual overrides for use cases that automation cannot >>> handle (yet). >> >> Well, I think that a total newcomer is already struggling enough to >> produce a good spec file for their first package, but now they also need >> to keep in mind that their changelog is tied to the git history (and can >> thus not be changed easily anymore). Back when I started packaging, I >> found a lot of the details quite confusing and was building packages on >> copr and locally for a few years before I dared to go near koji. At >> least for me using rpmautospec would've been another one of these >> confusing details. That's why I would only recommend its usage, until >> most other build system out there use something comparable and beginners >> can be expected to know this concept already. > > Understood. That makes sense. This is a case of different backgrounds. > The only rpm packages I have ever built are Fedora official packages. > From that angle, using rpmautospec is just simpler. In your case, it is > the other way round. Yeah, so for a package review I'd suggest the usage of rpmautospec if the packager is comfortable with that, but wouldn't enforce it for now. Cheers, Dan ___ 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 1983284] perl-Log-Report-1.33 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1983284 Petr Pisar changed: What|Removed |Added Status|ON_QA |CLOSED Resolution|--- |RAWHIDE Last Closed||2021-07-19 08:41:45 -- 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 1983408] perl-Math-BigRat-0.2617 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1983408 Jitka Plesnikova changed: What|Removed |Added Status|ASSIGNED|CLOSED Fixed In Version||perl-Math-BigRat-0.2617-1.f ||c35 Resolution|--- |RAWHIDE Last Closed||2021-07-19 08:31:37 -- 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: rpmautospec deployment into production
On 2021-07-19 09:07, Otto Urpelainen wrote: However, copr seems to understand rpmautospec. Here is a build that started from a specfile that uses rpmautospec and completed successfully: https://copr.fedorainfracloud.org/coprs/lcts/nextcloud/build/2329596/ Not quite. It doesn't error, but it doesn't deal with the macros either. %autochangelog should be replaced with the actual changelog during builds, which doesn't happen on Copr. I think, though I haven't tested, that it also always uses 1. as the release. See e.g. the .src.rpm here for a rpmautospec build on koji https://koji.fedoraproject.org/koji/buildinfo?buildID=1780088 Christopher ___ 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
Next Open NeuroFedora Meeting: 1300 UTC on Monday, 19th July (Today)
Hello everyone, Please join us at the next Open NeuroFedora team meeting on Monday 19th July (today!) at 1300UTC in #fedora-neuro on IRC (Freenode). The meeting is a public meeting, and open for everyone to attend. You can join us over: IRC: https://webchat.libera.chat/?channels=#fedora-neuro Matrix: https://tinyurl.com/matrix-neurofedora You can convert the meeting time to your local time using this command in a terminal: $ date --date='TZ="UTC" 1300 today' or you can use this link: https://www.timeanddate.com/worldclock/fixedtime.html?msg=Open+NeuroFedora+Meeting=20210719T13=%3A=1 The meeting will be chaired by @ankursinha. The agenda for the meeting is: - New introductions and roll call. - Tasks from last week's meeting: https://meetbot.fedoraproject.org/teams/neurofedora/neurofedora.2021-06-21-13.02.html - Open Pagure tickets: https://pagure.io/neuro-sig/NeuroFedora/issues?status=Open=S%3A+Next+meeting - Package health check: https://packager-dashboard.fedoraproject.org/neuro-sig - Open package reviews check: https://bugzilla.redhat.com/show_bug.cgi?id=fedora-neuro - Koschei packages check: https://koschei.fedoraproject.org/groups/neuro-sig - CompNeuro lab compose status check for F35: https://koji.fedoraproject.org/koji/packageinfo?packageID=30691 - Neuroscience query of the week - Next meeting day, and chair. - Open floor. We hope to see you there! You can learn more about NeuroFedora here: https://neuro.fedoraproject.org -- 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
[Bug 1983408] perl-Math-BigRat-0.2617 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1983408 Jitka Plesnikova changed: What|Removed |Added Status|NEW |ASSIGNED CC|jples...@redhat.com,| |mspa...@redhat.com, | |ppi...@redhat.com | Doc Type|--- |If docs needed, set a value -- 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 1982436] perl-CPAN-FindDependencies-3.09 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1982436 Jitka Plesnikova changed: What|Removed |Added Status|ASSIGNED|CLOSED Fixed In Version||perl-CPAN-FindDependencies- ||3.09-1.fc35 Resolution|--- |RAWHIDE Last Closed||2021-07-19 08:13:40 -- 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: Why so long for EPEL-8?
On 18/07/2021 13:38, Neal Gompa wrote:
Enterprise-grade stability is a lie unless you're being paid to
maintain that. The two-week time period does nobody any favors.
"Enterprise-grade stability" was a sarcasm.
I fully agree with you. 100% of my EPEL{7,8} updates received 0 Bodhi
karma (even with CVE vulnerabilities fixes).
1. People don't give feedback and only complain after the fact.
On Fedora too. Only a few popular packages (kernel, firefox,
thunderbird) get user feedback on Bodhi. All others will need to stay in
testing for 7 days.
--
Sincerely,
Vitaly Zaitsev (vit...@easycoding.org)
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it:
https://pagure.io/fedora-infrastructure
Mock v2.12 release and mock-core-configs v34.5
Hello! I'm glad I can announce that we have a new release of Mock + configs. There are several small bugfixes, and many new configuration files (CentOS Stream 9, Rocky, EPEL Next 8, Alma AArch64). Release notes: https://github.com/rpm-software-management/mock/wiki/Release-Notes-2.12 Note that this release is likely the last v2 release being shipped both in Fedora 33+ and EPEL 7+. We'll keep v2 in bugfix mode for the purpose of EPEL 7 builds, and elsewhere we'll forward with v3. For more info see: https://github.com/rpm-software-management/mock/issues/755 Happy building! Pavel ___ 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 1983284] perl-Log-Report-1.33 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1983284 Petr Pisar changed: What|Removed |Added Status|ASSIGNED|ON_QA Fixed In Version||perl-Log-Report-1.33-1.fc35 --- Comment #1 from Petr Pisar --- This release changes how the original exception is returned. It's not always a string anymore. Suitable for Rawhide only. -- 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: rpmautospec deployment into production
On Mon, 19 Jul 2021, 08:08 Otto Urpelainen, wrote: > > However, copr seems to understand rpmautospec. > Not really. The release will always be 1. When a package builds again, end users won't receive the updated version. https://pagure.io/fedora-infra/rpmautospec/issue/199 -- Peter Oliver > ___ 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
[rpms/perl-Log-Report] PR #1: Tests
ppisar merged a pull-request against the project: `perl-Log-Report` that you are following. Merged pull-request: `` Tests `` https://src.fedoraproject.org/rpms/perl-Log-Report/pull-request/1 ___ 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
Orphaned packages looking for new maintainers
The following packages are orphaned and will be retired when they are orphaned for six weeks, unless someone adopts them. If you know for sure that the package should be retired, please do so now with a proper reason: https://fedoraproject.org/wiki/How_to_remove_a_package_at_end_of_life Note: If you received this mail directly you (co)maintain one of the affected packages or a package that depends on one. Please adopt the affected package or retire your depending package to avoid broken dependencies, otherwise your package will fail to install and/or build when the affected package gets retired. Request package ownership via the *Take* button in he left column on https://src.fedoraproject.org/rpms/ Full report available at: https://churchyard.fedorapeople.org/orphans-2021-07-19.txt grep it for your FAS username and follow the dependency chain. For human readable dependency chains, see https://packager-dashboard.fedoraproject.org/ For all orphaned packages, see https://packager-dashboard.fedoraproject.org/orphan Package (co)maintainers Status Change 8sync orphan 3 weeks ago HdrHistogram acaringi, almac, hhorak, 4 weeks ago jvanek, orphan JSCookMenuorphan 4 weeks ago WebCalendar orphan 4 weeks ago apache-ivyjava-maint-sig, mizdebsk,0 weeks ago orphan biboumi louizatakk, orphan 4 weeks ago erlang-riak_pipe bowlofeggs, erlang-maint-sig,5 weeks ago orphan java-atk-wrapper omajid, orphan 5 weeks ago jboss-annotations-1.2-api cfu, ckelley, dmoluguw, 4 weeks ago jmagne, mharmsen, orphan jmc almac, orphan, sasiddiq 4 weeks ago jmc-core almac, orphan, sasiddiq 4 weeks ago js-gl-matrix orphan 3 weeks ago libi40iw orphan, tatyana 0 weeks ago linuxcnc orphan 0 weeks ago lz4-java orphan 4 weeks ago mate-applet-softupd orphan 4 weeks ago mvel orphan 4 weeks ago owasp-java-encoderalmac, orphan, sasiddiq 4 weeks ago php-PHPMailer orphan, remi 4 weeks ago php-captchaphporphan 4 weeks ago php-hkit orphan 4 weeks ago php-pear-Auth-Yubico orphan 4 weeks ago php-rmccue-requests orphan 5 weeks ago python-glusterfs-api humble, orphan 4 weeks ago python-jsonrpcserver orphan 3 weeks ago python-nose-cov orphan 3 weeks ago python-nssjmagne, orphan 3 weeks ago python-pytest-helpers-namespace orion, orphan, python-sig1 weeks ago python-pytest-relaxed orphan 4 weeks ago python-ruamel-std-pathlib orphan 0 weeks ago python-setuptools-lintorphan 3 weeks ago python-testfixtures orphan 0 weeks ago python-urlobject orphan 3 weeks ago python-vsc-installorphan 0 weeks ago qtile cicku, orphan3 weeks ago rubygem-expression_parser orphan 3 weeks ago rubygem-fssm orphan 3 weeks ago rubygem-sdoc orphan 5 weeks ago rust-ab_glyph_rasterizer orphan, rust-sig 0 weeks ago rust-line_drawing orphan, rust-sig 0 weeks ago rust-owned_ttf_parser orphan, rust-sig 0 weeks ago rust-palette orphan, rust-sig 0 weeks ago rust-palette_derive orphan, rust-sig 0 weeks ago rust-tower-test orphan, rust-sig 0 weeks ago rust-tower-util orphan, rust-sig 0 weeks ago rust-tzfile orphan, rust-sig
[rpms/perl-Log-Report] PR #1: Tests
ppisar opened a new pull-request against the project: `perl-Log-Report` that you are following: `` Tests `` To reply, visit the link below https://src.fedoraproject.org/rpms/perl-Log-Report/pull-request/1 ___ 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
Fedora-Cloud-33-20210719.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-20210718.0): ID: 930639 Test: x86_64 Cloud_Base-qcow2-qcow2 cloud_autocloud URL: https://openqa.fedoraproject.org/tests/930639 ID: 930648 Test: aarch64 Cloud_Base-qcow2-qcow2 cloud_autocloud@uefi URL: https://openqa.fedoraproject.org/tests/930648 Passed openQA tests: 7/8 (x86_64), 7/8 (aarch64) -- Mail generated by check-compose: https://pagure.io/fedora-qa/check-compose ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[Bug 1982436] perl-CPAN-FindDependencies-3.09 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1982436 Jitka Plesnikova changed: What|Removed |Added Status|NEW |ASSIGNED CC|i...@cicku.me, | |jples...@redhat.com | Doc Type|--- |If docs needed, set a value -- 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: rpmautospec deployment into production
Dan Čermák kirjoitti 18.7.2021 klo 23.38: Otto Urpelainen writes: Dan Čermák kirjoitti 17.7.2021 klo 23.10: Robert-André Mauchin writes: What is the situation wrt new packages? Should we enforce the use of rpmautospec during reviews or is it completely optional? I think we should encourage the usage of rpmautospec for new packages, provided that the packager feels comfortable enough to use it. E.g. I wouldn't suggest it for someone's first package. But this shouldn't become a *MUST*, at least not yet. I am curious regarding the reasons for not recommending rpmautospec for new maintainers? It is an automation feature that removes manual steps from the process. Using it is simpler than doing the same manually. I think we should offer the simplest possible process for newcomers and only recommend manual overrides for use cases that automation cannot handle (yet). Well, I think that a total newcomer is already struggling enough to produce a good spec file for their first package, but now they also need to keep in mind that their changelog is tied to the git history (and can thus not be changed easily anymore). Back when I started packaging, I found a lot of the details quite confusing and was building packages on copr and locally for a few years before I dared to go near koji. At least for me using rpmautospec would've been another one of these confusing details. That's why I would only recommend its usage, until most other build system out there use something comparable and beginners can be expected to know this concept already. Understood. That makes sense. This is a case of different backgrounds. The only rpm packages I have ever built are Fedora official packages. From that angle, using rpmautospec is just simpler. In your case, it is the other way round. However, copr seems to understand rpmautospec. Here is a build that started from a specfile that uses rpmautospec and completed successfully: https://copr.fedorainfracloud.org/coprs/lcts/nextcloud/build/2329596/ Otto ___ 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: Strange issue with keymaps
On Sat, Jul 17, 2021 at 03:48:16PM +0200, Vitaly Zaitsev via devel wrote: > Hello. > > We found a strange issue with non-US keymaps. If the kbd-legacy > package is not installed (not installed on F34 by default[1]), the > system will hang on boot due to the "Failed to start Setup Virtual > Console"[2] error. systemd-vconsole-setup fails if it cannot load the specified font and keymap. But that by itself should not cause a "hang" or stop the boot, because services have a Wants= (not Requires=) dependency on systemd-vconsole-setup.service. The only exception I see is dracut-cmdline-ask.service, which specifies Requires=systemd-vconsole-setup.service. The log snippet that is provided in the bug does not contain enough context to confirm that the failure is in the initramfs phase, but that seems very likely. (Please attach full boot logs in general for such bugs, it makes it easier to resolve them without unnecessary back-and-forth.) I think we should do three changes here: dracut units should be changed to not use Requires, and this will allow the boot to continue (albeit with the wrong keymap, which might cause problems if you're trying to input a decryption phase). Anaconda should pull in kbd-legacy (I think this might be done already, this is not the first time this bug is discovered). But also should change systemd-vconsole-setup to continue if the keymap cannot be loaded and load the font at least. It seems better to have the font loaded, even if you don't have the keymap, so at least you can *see* that wrong characters are being typed. The final exit value should still be failure, because the important job of the service wasn't done successfully, so this will not help with your problem, but it'll make the system a bit nicer. 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
[Bug 1983284] perl-Log-Report-1.33 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1983284 Petr Pisar changed: What|Removed |Added Status|NEW |ASSIGNED CC|jples...@redhat.com,| |ppi...@redhat.com | Doc Type|--- |If docs needed, set a value -- 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
