Re: Having python3-faker installed causes pytest-3 to fail
> I think the problem is probably with faker, seems like this might be the > bug: https://github.com/joke2k/faker/issues/1421 Thanks, that looks like the root cause. > It appears to have been already fixed in a newer release of faker, so you > might just need to poke the Fedora maintainer to update. Indeed, but looking at upstream code, the fix is present only in faker 7.x and 8.x, whereas in Fedora 34 we have 6.1.1. Rawhide can jump all the way to latest 8.4.0, but for F34, we'd want to avoid doing a major version bump, so we'd need to backport this, instead. Thanks for the help! A.FI. ___ 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
[389-devel] 389 DS nightly 2021-05-31 - 94% PASS
https://fedorapeople.org/groups/389ds/ci/nightly/2021/05/31/report-389-ds-base-2.0.5-20210531git607bfbf16.fc34.x86_64.html ___ 389-devel mailing list -- 389-devel@lists.fedoraproject.org To unsubscribe send an email to 389-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/389-devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[EPEL-devel] Fedora EPEL 8 updates-testing report
The following Fedora EPEL 8 Security updates need testing: Age URL 11 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2021-58bc048b1a upx-3.96-9.el8 8 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2021-a20d7c1ddd rxvt-unicode-9.26-1.el8 7 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2021-bdd3e1ab81 opendmarc-1.4.1-1.el8 7 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2021-6c72c1c9a5 gromacs-2019.6-2.el8 kokkos-3.0.00-2.el8 slurm-20.11.7-2.el8 5 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2021-0e0c1a76c6 slurm-20.11.7-3.el8 5 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2021-c734316809 chromium-90.0.4430.212-1.el8 4 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2021-bb6ec0e942 singularity-3.7.4-1.el8 The following builds have been pushed to Fedora EPEL 8 updates-testing python-hstspreload-2021.5.24-1.el8 python-ncclient-0.6.12-1.el8 Details about builds: python-hstspreload-2021.5.24-1.el8 (FEDORA-EPEL-2021-78bb21cfce) Chromium HSTS Preload list Update Information: Update to latest upstream release 2021.5.24 ChangeLog: * Sun May 30 2021 Fabian Affolter - 2021.5.24-1 - Update to latest upstream release 2021.5.24 * Mon Apr 26 2021 Fabian Affolter - 2021.4.26-1 - Update to latest upstream release 2021.4.26 * Wed Feb 24 2021 Fabian Affolter - 2021.2.15-1 - Update to new upstream release 2021.2.15 * Sun Feb 14 2021 Fabian Affolter - 2021.2.1-1 - Update to new upstream release 2021.2.1 * Wed Jan 27 2021 Fedora Release Engineering - 2020.12.22-2 - Rebuilt for https://fedoraproject.org/wiki/Fedora_34_Mass_Rebuild * Tue Dec 22 2020 Fabian Affolter - 2020.12.22-1 - Update to new upstream release 2020.11.21 (#1910109) * Mon Nov 23 2020 Fabian Affolter - 2020.11.21-1 - Update to new upstream release 2020.11.21 (#1900151) * Tue Oct 20 2020 Fabian Affolter - 2020.10.20-1 - Update to new upstream release 2020.10.20 (#1889570) * Tue Oct 6 2020 Fabian Affolter - 2020.10.6-1 - Update to new upstream release 2020.10.6 (#1885451) * Tue Sep 29 2020 Fabian Affolter - 2020.9.29-1 - Update to new upstream release 2020.9.29 (#1883393) * Fri Sep 25 2020 Fabian Affolter - 2020.9.25-1 - Update to new upstream release 2020.9.25 (#1881756) * Thu Sep 24 2020 Fabian Affolter - 2020.9.23-1 - Update to new upstream release 2020.9.23 (#1881756) * Thu Sep 24 2020 Fabian Affolter - 2020.9.23-1 - Update to new upstream release 2020.9.23 (#1881756) * Tue Sep 22 2020 Fabian Affolter - 2020.9.22-1 - Update to new upstream release 2020.9.22 (#1881267) * Tue Sep 15 2020 Fabian Affolter - 2020.9.15-1 - Update to new upstream release 2020.9.15 (#1878942) * Wed Sep 9 2020 Fabian Affolter - 2020.9.9-1 - Update to new upstream release 2020.9.9 (#1877191) * Wed Sep 2 2020 Fabian Affolter - 2020.9.2-1 - Update to new upstream release 2020.9.2 (#1874701) * Tue Aug 18 2020 Fabian Affolter - 2020.8.18-1 - Update to new upstream release 2020.8.18 * Wed Aug 12 2020 Fabian Affolter - 2020.8.12-1 - Update to new upstream release 2020.8.12 * Sun Aug 9 2020 Fabian Affolter - 2020.8.8-1 - Update to new upstream release 2020.8.8 * Fri Jul 31 2020 Fabian Affolter - 2020.7.29-1 - Update to new upstream release 2020.7.29 * Tue Jul 28 2020 Fabian Affolter - 2020.7.22-1 - Update to new upstream release 2020.7.22 * Mon Jul 13 2020 Fabian Affolter - 2020.7.7-1 - Update to new upstream release 2020.7.7 * Fri Jul 3 2020 Fabian Affolter - 2020.6.30-1 - Update to new upstream release 2020.6.30 * Sat Jun 27 2020 Fabian Affolter - 2020.6.23-1 - Update to new upstream release 2020.6.23 * Fri Jun 19 2020 Fabian Affolter - 2020.6.16-1 - Update to new upstream release 2020.6.16 python-ncclient-0.6.12-1.el8 (FEDORA-EPEL-2021-96710d009e) Python library for the NETCONF protocol Update Information: Update to 0.6.12 - Fix for accidental breakage of Juniper ExecuteRPC support Update to 0.6.11 - Support for custom client capabilities - Restructuring/refactoring of example scripts - Minor bugfixes - Minor unit test refactoring ChangeLog: * Sun May 30 2021 Benjamin A. Beasley - 0.6.12-1 - Update to 0.6.12 * Sat May 29 2021 Benjamin A. Beasley - 0.6.11-1 - Update to 0.6.11 - Drop upstreamed patches References: [ 1 ] Bug #1965771 - python-ncclient-0.6.12 is available
Re: New Fedora Packages Ready For Testing
> and package source have two items not found in this app: > > Packages -> should link to this app when this is deployed? currently > returns 503 Yes, when deployed I would like to setup a 301 redirect at the old url pointing to the new app. > Koschei Status -> would make sense to have in this app also? > It would; I will add a link. Brendan ___ 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: New Fedora Packages Ready For Testing
> On Sun, May 30, 2021 at 11:59 AM Zbigniew Jędrzejewski-Szmek > > It looks like this is a side effect of confusing source and binary > package names as well. > As far as I can tell, it only works "correctly" when binary and source > package name match. If they don't, it might display an error, or show > activity for an entirely different package (for example, "zincati" > shows activity for the retired "zincati" module, but not for the > actually still existing "rust-zincati" source package). > That is a bug, it should be using the source package name. Brendan ___ 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: New Fedora Packages Ready For Testing
> Which pages is it supposed to replace? What is the relation to > https://src.fedoraproject.org/rpms/? > It is unrelated to src.fedoraproject.org. This is replacing the former https://apps.fedoraproject.org/packages/. It was taken down permanently during the datacenter move. > Some initial comments: > - the search results page seems … messy. Would it be possible to > group results by parent package? E.g. > https://packages.stg.fedoraproject.org/search?query=systemd returns > four pages of results, and a large number of entries is for > subpackages. Grouping them would make it easier to find other > interesting packages which are not part of the main package. > There seems to be a method to group things in Solr. The results are likely bloated because the query parser defaults to OR-ing multiple terms rather than dnf's default AND. I think that increasing the amount of results and using the shorter description should also make results more compact. > Maybe also sort the results somehow? I think the method that dnf > uses is pretty good: result are grouped by how they are matched: > "Name Exactly Matched", "Name & Summary Matched", "Name > Matched", > "Summary Matched". And within each group, results are sorted > alphabetically. This gives a "clean" look (also because subpackages > tend to be grouped together), gives the most relevant result first, > and still makes it easy to scan the list. > I think that this specifically is not possible without hacking together multiple queries. This would be better accomplished through changing the search rankings via reranking or using the DisMax query parser on the package descriptions and names with appropriate weighting. > - A search result for a subpackage links to a page for that subpackage. > That's more confusing than useful: > https://packages.stg.fedoraproject.org/pkgs/systemd-networkd/ shows > the description for systemd-networkd, but all the information is actually > for systemd source package. > > I think linking to a single page named after the source package > would be more useful to users. Subpackages should be listed on this > page. This is how Debian/Ubuntu to it. (It would also seem quite > natural if the results were grouped by source package, as suggested > above.) [EDIT: Oh, I see that this is done to an extent, the main > package has "Subpackages" section. Unfortunately this doesn't take > into account that different Fedora releases can have different sets > of subpackages. This information is very important to users too.] > I disagree here. systemd-networkd's metadata is significantly different from other subpackages for that source package. For example, the descriptions, provides, requires, and files (some of which is only visible after clicking a version number) for each subpackage are completely different. In some cases, such as texlive, even the versions for each subpackage differ. Clobbering all of this information into one page would be confusing for large source packages such as glibc. Every single subpackage would have to be enumerated along with a version table and description, completely hiding the recent activity section. Additionally, it doesn't make sense to return something completely different that what the user asked for. E.g. if I lookup systemd-networkd, I should retrieve information only for that specific subpackage rather than show a list of all related subpackages. From the point of view of someone who does not understand how packages are built, this behavior would be extremely confusing. This is also the case with Debian from my understanding? You can search for a package in a specific release and the source package is only linked at the top left as an index. I think the takeaway here is that everything needs to be grouped by source packages as you said. My actions on this will probably be: - Change urls to /pkgs// - /pkgs/ should become an index listing subpackages similar to suggested - /pkgs// will contain the current subpackage pages - Subpackages pages will contain a "Related Packages" section that links to other subpackages for a source package - If a subpackage matches the name of the source package, it is treated as the "primary" subpackage Different releases are taken into account to my understanding. E.g. systemd-oomd-defaults only lists versions for F34 and rawhide whereas the systemd package lists more releases. I plan to introduce filtering in search based on what version of Fedora a package is available for. > - Related to the above: source package names are unique. Binary package > names are also unique for any given release of Fedora/EPEL/ELN/etc, > but not unique globally. There's an epel-only systemd-extras source package > which also builds systemd-networkd binary subpackage. But right > now the name is "occupied" by one of the subpackages, and no information > is shown for the other one.
Re: Having python3-faker installed causes pytest-3 to fail
On Sun, 30 May 2021, Artur Frenszek-Iwicki wrote:
Long story short: I have a Python package ("cozy") which built fine in koji, but failed to build
locally - or rather, it built fine, but then caused pytest-3 to crash. After a bit of fiddling, I managed to
nail this down to having "python3-faker" installed - when I removed it from my system, pytest-3
worked fine. When I added "BuildRequires: python3-faker" to the package spec and submitted a
scratch build to koji, that failed with the same traceback as the local build.
Here's the link to a successful build (currently in Rawhide):
https://koji.fedoraproject.org/koji/taskinfo?taskID=68991239
Here's the link to a failed scratch build (same spec as above, with added BR on
python3-faker):
https://koji.fedoraproject.org/koji/taskinfo?taskID=69012902
I have very little Python knowledge, and the traceback lists some internal
Python libs, so I'm not really sure if this should be reported as a bug against
cozy, pytest-3, python-faker, or maybe even python3.9 itself. I'd be grateful
if someone knowledgeable in the matter took a look.
I think the problem is probably with faker, seems like this might be the
bug: https://github.com/joke2k/faker/issues/1421
It appears to have been already fixed in a newer release of faker, so you
might just need to poke the Fedora maintainer to update.
Also, see https://bugzilla.redhat.com/show_bug.cgi?id=1958987.
Scott.
___
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
Having python3-faker installed causes pytest-3 to fail
Long story short: I have a Python package ("cozy") which built fine in koji,
but failed to build locally - or rather, it built fine, but then caused
pytest-3 to crash. After a bit of fiddling, I managed to nail this down to
having "python3-faker" installed - when I removed it from my system, pytest-3
worked fine. When I added "BuildRequires: python3-faker" to the package spec
and submitted a scratch build to koji, that failed with the same traceback as
the local build.
Here's the link to a successful build (currently in Rawhide):
https://koji.fedoraproject.org/koji/taskinfo?taskID=68991239
Here's the link to a failed scratch build (same spec as above, with added BR on
python3-faker):
https://koji.fedoraproject.org/koji/taskinfo?taskID=69012902
I have very little Python knowledge, and the traceback lists some internal
Python libs, so I'm not really sure if this should be reported as a bug against
cozy, pytest-3, python-faker, or maybe even python3.9 itself. I'd be grateful
if someone knowledgeable in the matter took a look.
Thanks in advance,
A.FI.
___
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: New Fedora Packages Ready For Testing
Zbigniew Jędrzejewski-Szmek kirjoitti 30.5.2021 klo 12.59: On Sat, May 29, 2021 at 09:38:46PM -0500, Brendan Early wrote: Hi all, Fedora Packages Static is intended to replace the old Fedora Packages app and is now available for testing at https://packages.stg.fedoraproject.org. Any feedback would be appreciated here or on Pagure at https://pagure.io/fedora-packages-static. Which pages is it supposed to replace? What is the relation to https://src.fedoraproject.org/rpms/? (snip) - "SCM" links to a page that calls itself "fedora PACKAGE SOURCES" and that everybody seems to refer to as "dist-git" or "pagure" in conversations. Maybe it would be better to call the link "sources" or "dist-git source" or "package source"? (And "FAF" links to "retrace.fedoraproject.org" page that calls itself "ABRT Analytics". I don't even know what to suggest here ;| .) I think it would also be good to compare these links to basically identical links at the package sources [1]. The corresponding names there are: Bodhi -> Updates Status Bugzilla -> Bug Reports FAF -> not included, why the difference? Koji -> Builds Status SCM -> not included, because it would link to the same page and package source have two items not found in this app: Packages -> should link to this app when this is deployed? currently returns 503 Koschei Status -> would make sense to have in this app also? [1]: https://src.fedoraproject.org/rpms/firefox 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: Building for EPEL-8 and CMake (again)
On 5/18/21 2:24 PM, Ron Olson wrote: Hey all- Awhile back I asked about the status of CMake in CentOS so I could build my packages for EPEL-8; they require a version of CMake that is greater than 3.11.4 which is currently available. CentOS Stream has a later version, as does RHEL 8.4. I get that CentOS Stream is the future of CentOS, but when I run a koji build for EPEL 8 it uses CentOS 8, not CentOS Stream and thus all my builds fail. EPEL builds against RHEL, not CentOS. Now that RHEL8.4 has been released, cmake 3.18.2 is available in the EPEL8 buildroot. TL;DR: How can I build anything for EPEL 8 with CMake if the package is too old? Otherwise, someone would need to package a separate cmake3 package for EPEL to provide a newer cmake. -- Orion Poplawski he/him/his - surely the least important thing about me Manager of NWRA Technical Systems 720-772-5637 NWRA, Boulder/CoRA Office FAX: 303-415-9702 3380 Mitchell Lane or...@nwra.com Boulder, CO 80301 https://www.nwra.com/ smime.p7s Description: S/MIME Cryptographic 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 1965838] New: perl-Graphics-TIFF-14 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1965838 Bug ID: 1965838 Summary: perl-Graphics-TIFF-14 is available Product: Fedora Version: rawhide Status: NEW Component: perl-Graphics-TIFF Keywords: FutureFeature, Triaged Assignee: ppi...@redhat.com Reporter: upstream-release-monitor...@fedoraproject.org QA Contact: extras...@fedoraproject.org CC: perl-devel@lists.fedoraproject.org, ppi...@redhat.com Target Milestone: --- Classification: Fedora Latest upstream release: 14 Current version/release in rawhide: 13-1.fc35 URL: https://metacpan.org/release/Graphics-TIFF Please consult the package updates policy before you issue an update to a stable branch: https://docs.fedoraproject.org/en-US/fesco/Updates_Policy/ More information about the service that created this bug can be found at: https://fedoraproject.org/wiki/Upstream_release_monitoring Please keep in mind that with any upstream change, there may also be packaging changes that need to be made. Specifically, please remember that it is your responsibility to review the new version to ensure that the licensing is still correct and that no non-free or legally problematic items have been added upstream. Based on the information from anitya: https://release-monitoring.org/project/15735/ -- 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
[EPEL-devel] Fedora EPEL 8 updates-testing report
The following Fedora EPEL 8 Security updates need testing: Age URL 11 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2021-58bc048b1a upx-3.96-9.el8 8 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2021-a20d7c1ddd rxvt-unicode-9.26-1.el8 7 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2021-bdd3e1ab81 opendmarc-1.4.1-1.el8 7 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2021-6c72c1c9a5 gromacs-2019.6-2.el8 kokkos-3.0.00-2.el8 slurm-20.11.7-2.el8 4 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2021-0e0c1a76c6 slurm-20.11.7-3.el8 4 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2021-c734316809 chromium-90.0.4430.212-1.el8 3 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2021-bb6ec0e942 singularity-3.7.4-1.el8 The following builds have been pushed to Fedora EPEL 8 updates-testing ansible-collection-community-general-3.1.0-2.el8 python-tkrzw-0.1.7-1.el8 Details about builds: ansible-collection-community-general-3.1.0-2.el8 (FEDORA-EPEL-2021-b5274fdcde) Modules and plugins supported by Ansible community Update Information: Update to 3.1.0 release. ChangeLog: * Sat May 29 2021 Kevin Fenzi - 3.1.0-2 - Fix sed issue that caused python33 to be required. * Sat May 29 2021 Kevin Fenzi - 3.1.0-1 - Update to 3.1.0. Fixes rhbz#1957092 * Tue May 11 2021 Kevin Fenzi - 3.0.2-1 - Update to 3.0.2. Fixes rhbz#1957092 * Wed May 5 2021 Kevin Fenzi - 3.0.1-1 - Update to 3.0.1. Fixes rhbz#1957092 * Tue Apr 27 2021 Kevin Fenzi - 3.0.0-1 - Update to 3.0.0. Fixes rhbz#1953895 python-tkrzw-0.1.7-1.el8 (FEDORA-EPEL-2021-aa4e4729a4) TKRZW Python bindings Update Information: Version bump ChangeLog: * Fri May 14 2021 TI_Eugene - 0.1.7-1 - Version bump - Build against tkrzw-0.9.16 ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
again soname bump in fluidsynth-libs
Hello! I have started the process to update fluidsynth to fluidsynth-2.2.1 on rawhide with a build in the f35-build-side-41995 side tag. Upstream has again a soname bump: libfluidsynth.so.2 ---> libfluidsynth.so.3 Dependant packages are: >sudo dnf repoquery --source --whatrequires '*libfluidsynth.so*' Carla-2.3.0-1.fc34.src.rpm ardour6-6.6.0-1.fc34.src.rpm audacious-plugins-4.1-1.fc34.src.rpm calf-0.90.3-8.fc34.src.rpm csound-6.15.0-2.fc34.src.rpm denemo-2.5.0-1.fc34.src.rpm dosbox-staging-0.76.0-2.fc34.src.rpm drumstick-2.1.1-1.fc34.src.rpm fluidsynth-2.1.8-3.fc34.src.rpm fluidsynth-dssi-1.0.0-24.fc34.src.rpm gstreamer1-plugins-bad-free-1.18.4-1.fc34.src.rpm lmms-1.1.3-20.fc34.src.rpm minuet-21.04.1-1.fc34.src.rpm mpd-0.22.6-1.fc34.src.rpm muse-3.0.2-13.fc34.src.rpm openttd-1.11.2-1.fc34.src.rpm prboom-plus-2.5.1.4-20.fc34.src.rpm qsynth-0.9.2-1.fc34.src.rpm scummvm-2.2.0-3.fc34.src.rpm tuxguitar-1.5.3-6.fc34.src.rpm vlc-3.0.14-1.fc34.src.rpm Best Regards Christoph ___ 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: New Fedora Packages Ready For Testing
On Sun, May 30, 2021 at 11:59 AM Zbigniew Jędrzejewski-Szmek wrote: > > - There's "Recent Activity" at the bottom. For some packages this works, > but for others it only shows "Loading…". I see "TypeError: NetworkError > when attempting to fetch resource" shown for a fraction of a second. It looks like this is a side effect of confusing source and binary package names as well. As far as I can tell, it only works "correctly" when binary and source package name match. If they don't, it might display an error, or show activity for an entirely different package (for example, "zincati" shows activity for the retired "zincati" module, but not for the actually still existing "rust-zincati" source package). 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: Where is system-config-users?
On Sun, May 30, 2021 at 6:32 AM Robert-André Mauchin wrote: > > Hello, > > System-config-users > https://src.fedoraproject.org/rpms/system-config-users has been retired > due to FTBFS and lack of mainteance. I would like to revive it but I > can't find the source code anywhere. It was previously hosted on > fedorahosted but has not been moved to Pagure. > > Anyone knows if there is still an official repo for it? > You can file a ticket with fedora-infrastructure to restore the repo from backup and import it into pagure.io. -- 真実はいつも一つ！/ Always, there's only one truth! ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Where is system-config-users?
Hello, System-config-users https://src.fedoraproject.org/rpms/system-config-users has been retired due to FTBFS and lack of mainteance. I would like to revive it but I can't find the source code anywhere. It was previously hosted on fedorahosted but has not been moved to Pagure. Anyone knows if there is still an official repo for it? Best regards, Robert-André ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://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: New Fedora Packages Ready For Testing
On Sat, May 29, 2021 at 09:38:46PM -0500, Brendan Early wrote: > Hi all, > > Fedora Packages Static is intended to replace the old Fedora > Packages app and is now available for testing at > https://packages.stg.fedoraproject.org. Any feedback would be > appreciated here or on Pagure at > https://pagure.io/fedora-packages-static. Which pages is it supposed to replace? What is the relation to https://src.fedoraproject.org/rpms/? > The app is designed to function with the minimum amount of dynamic > server components needed. Pages are statically generated using a > Python script; the only dynamically generated page is the search > result page. Data is updated hourly. Search is handled externally by > an instance of Apache Solr. Clients do not need JS to use the app. That sounds good. I can confirm that the staging site seems snappy. > Thanks to Timothée Floure for the original version of Fedora > Packages Static and Kevin Fenzi for helping deploy the app on > OpenShift. Some initial comments: - the search results page seems … messy. Would it be possible to group results by parent package? E.g. https://packages.stg.fedoraproject.org/search?query=systemd returns four pages of results, and a large number of entries is for subpackages. Grouping them would make it easier to find other interesting packages which are not part of the main package. Maybe also sort the results somehow? I think the method that dnf uses is pretty good: result are grouped by how they are matched: "Name Exactly Matched", "Name & Summary Matched", "Name Matched", "Summary Matched". And within each group, results are sorted alphabetically. This gives a "clean" look (also because subpackages tend to be grouped together), gives the most relevant result first, and still makes it easy to scan the list. - A search result for a subpackage links to a page for that subpackage. That's more confusing than useful: https://packages.stg.fedoraproject.org/pkgs/systemd-networkd/ shows the description for systemd-networkd, but all the information is actually for systemd source package. I think linking to a single page named after the source package would be more useful to users. Subpackages should be listed on this page. This is how Debian/Ubuntu to it. (It would also seem quite natural if the results were grouped by source package, as suggested above.) [EDIT: Oh, I see that this is done to an extent, the main package has "Subpackages" section. Unfortunately this doesn't take into account that different Fedora releases can have different sets of subpackages. This information is very important to users too.] - Related to the above: source package names are unique. Binary package names are also unique for any given release of Fedora/EPEL/ELN/etc, but not unique globally. There's an epel-only systemd-extras source package which also builds systemd-networkd binary subpackage. But right now the name is "occupied" by one of the subpackages, and no information is shown for the other one. It would be even worse if there was an epel-only systemd-networkd source package, because the main package couldn't be shown at all. Putting both binary and source packages under the same prefix https://packages.stg.fedoraproject.org/pkgs/ cannot work. - Are the descriptions takes from some old release? For systemd I see "built from the 245.4-stable branch of systemd" while even f32 has 245.9 now. - Whitespace in descriptions is squished. E.g. https://packages.stg.fedoraproject.org/pkgs/systemd-swap/ looks very strange. Generally package descriptions are supposed to be preformatted text that fits in 80 columns. I don't think it should be wrapped at all. 'dnf info systemd-swap' looks good; https://src.fedoraproject.org/rpms/systemd-swap does a reasonable job, except that it centers everything; https://packages.stg.fedoraproject.org/pkgs/systemd-swap/ is hard to read. - There's "Recent Activity" at the bottom. For some packages this works, but for others it only shows "Loading…". I see "TypeError: NetworkError when attempting to fetch resource" shown for a fraction of a second. - "SCM" links to a page that calls itself "fedora PACKAGE SOURCES" and that everybody seems to refer to as "dist-git" or "pagure" in conversations. Maybe it would be better to call the link "sources" or "dist-git source" or "package source"? (And "FAF" links to "retrace.fedoraproject.org" page that calls itself "ABRT Analytics". I don't even know what to suggest here ;| .) - https://packages.stg.fedoraproject.org/pkgs/systemd-swap/ has a number of broken images in the "Recent Activity" part. Since that's generated content, it's not so easy to see what's going on… I hope that's useful feedback. Thanks for working on this! Zbyszek ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to
Fedora-Cloud-34-20210530.0 compose check report
No missing expected images. Failed openQA tests: 8/8 (x86_64) Old failures (same test failed in Fedora-Cloud-34-20210529.0): ID: 899303 Test: x86_64 Cloud_Base-qcow2-qcow2 base_package_install_remove URL: https://openqa.fedoraproject.org/tests/899303 ID: 899304 Test: x86_64 Cloud_Base-qcow2-qcow2 base_service_manipulation URL: https://openqa.fedoraproject.org/tests/899304 ID: 899305 Test: x86_64 Cloud_Base-qcow2-qcow2 base_reboot_unmount URL: https://openqa.fedoraproject.org/tests/899305 ID: 899306 Test: x86_64 Cloud_Base-qcow2-qcow2 base_services_start URL: https://openqa.fedoraproject.org/tests/899306 ID: 899307 Test: x86_64 Cloud_Base-qcow2-qcow2 base_selinux URL: https://openqa.fedoraproject.org/tests/899307 ID: 899308 Test: x86_64 Cloud_Base-qcow2-qcow2 cloud_autocloud URL: https://openqa.fedoraproject.org/tests/899308 ID: 899309 Test: x86_64 Cloud_Base-qcow2-qcow2 base_system_logging URL: https://openqa.fedoraproject.org/tests/899309 ID: 899310 Test: x86_64 Cloud_Base-qcow2-qcow2 base_update_cli URL: https://openqa.fedoraproject.org/tests/899310 Soft failed openQA tests: 1/8 (aarch64) (Tests completed, but using a workaround for a known bug) Old soft failures (same test soft failed in Fedora-Cloud-34-20210529.0): ID: 899315 Test: aarch64 Cloud_Base-qcow2-qcow2 cloud_autocloud@uefi URL: https://openqa.fedoraproject.org/tests/899315 Passed openQA tests: 7/8 (aarch64) New passes (same test not passed in Fedora-Cloud-34-20210529.0): ID: 899318 Test: aarch64 Cloud_Base-qcow2-qcow2 base_service_manipulation@uefi URL: https://openqa.fedoraproject.org/tests/899318 -- Mail generated by check-compose: https://pagure.io/fedora-qa/check-compose ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Fedora-Cloud-33-20210530.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-20210529.0): ID: 899292 Test: x86_64 Cloud_Base-qcow2-qcow2 cloud_autocloud URL: https://openqa.fedoraproject.org/tests/899292 ID: 899299 Test: aarch64 Cloud_Base-qcow2-qcow2 cloud_autocloud@uefi URL: https://openqa.fedoraproject.org/tests/899299 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
