Re: How to use llvm15 for building a package
On 04/07/2023 05:24, Tom Stellard wrote:
/usr/include/OpenImageIO/detail/fmt/core.h:1691:7: error: static
assertion failed: Cannot format an argument. To make type T formattable
provide a formatter specialization: https://fmt.dev/latest/api.html#udt
This seems like a failure unrelated to clang. Have you run into this?
fmt 10 issue:
Removed deprecated implicit conversions for enums and conversions to primitive
types for compatibility with std::format and to prevent potential ODR
violations.
You need to patch (or pick an upstream patch) your package and use an
explicit conversion.
Old variant (no longer works with fmt 10):
log("..str..", foo)
New:
log("..str..", static_castfoo)
--
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, report it:
https://pagure.io/fedora-infrastructure/new_issue
Re: How to use llvm15 for building a package
On 7/3/23 19:37, Luya Tshimbalanga wrote:
On 2023-07-03 17:08, Tom Stellard wrote:
On 7/3/23 11:31, Luya Tshimbalanga wrote:
Hello team,
I attempt to build openshadinglanguage with llvm15 as upstream has yet to
support LLVM 16. Can someone have a pointed how to set a cmake parameter for
llvm15 and its bitecode validation?
See the spec file on:
https://src.fedoraproject.org/rpms/openshadinglanguage/blob/rawhide/f/openshadinglanguage.spec
Have you tried changing the BuildRequires from llvm-devel to llvm15-devel and
clang-devel to clang15-devel?
It may autodetect llvm15 if you do that.
Unfortunately it did not as I had to manually set "-DLLVM_ROOT=%{_libdir}/llvm15
\".
The compiling led to the following error:
CMake Error at src/cmake/llvm_macros.cmake:43 (message):
You must have a valid llvm bitcode generator (clang++) somewhere.
Call Stack (most recent call first):
src/liboslexec/CMakeLists.txt:223 (EMBED_LLVM_BITCODE_IN_CPP)
When I try to build from the rawhide branch, I get:
/usr/include/OpenImageIO/detail/fmt/core.h:1691:7: error: static assertion failed:
Cannot format an argument. To make type T formattable provide a formatter
specialization: https://fmt.dev/latest/api.html#udt
This seems like a failure unrelated to clang. Have you run into this?
-Tom
--
Luya Tshimbalanga
Fedora Design Team
Fedora Design Suite maintainer
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
Re: How to use llvm15 for building a package
On 2023-07-03 17:08, Tom Stellard wrote:
On 7/3/23 11:31, Luya Tshimbalanga wrote:
Hello team,
I attempt to build openshadinglanguage with llvm15 as upstream has
yet to support LLVM 16. Can someone have a pointed how to set a cmake
parameter for llvm15 and its bitecode validation?
See the spec file on:
https://src.fedoraproject.org/rpms/openshadinglanguage/blob/rawhide/f/openshadinglanguage.spec
Have you tried changing the BuildRequires from llvm-devel to
llvm15-devel and clang-devel to clang15-devel?
It may autodetect llvm15 if you do that.
Unfortunately it did not as I had to manually set
"-DLLVM_ROOT=%{_libdir}/llvm15 \".
The compiling led to the following error:
CMake Error at src/cmake/llvm_macros.cmake:43 (message):
You must have a valid llvm bitcode generator (clang++) somewhere.
Call Stack (most recent call first):
src/liboslexec/CMakeLists.txt:223 (EMBED_LLVM_BITCODE_IN_CPP)
--
Luya Tshimbalanga
Fedora Design Team
Fedora Design Suite maintainer
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
RE: cups-2.4.2-11.fc39.src.rpm depends on autoconf-2.71 or newer, not mentioned in .spec file, fails build
On Wed, Jun 28, 2023 7:15AM +1000, Jan Pazdziora wrote: > On Sun, Mar 26, 2023 at 02:44:34PM +0300, ijaaskelai...@outlook.com wrote: > > Kind regards, The Improvement Skeleton. > > Please show the exact steps you use to build the cups package and the > exact error message you get. > > Technically you are correct because configure.ac has AC_PREREQ([2.71]). > But autoconf is pulled in by the automake which is listed as BuildRequires > in cups.spec file, and since Fedora rawhide only has > autoconf-2.71-5.fc38.noarch, there really is not an older autoconf around > to ruin your day. I suspect he may be trying to rebuild the Fedora CUPS RPMs on a RHEL 8 or 9 based machine. Ironically CUPS 2.4.x doesn't actually need autoconf to be at least 2.71, on openSUSE they have a downgrade-autoconf-requirement.patch file which downgrades the requirement to 2.69: https://build.opensuse.org/package/show/openSUSE%3AFactory/cups Cheers, Doug ___ 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, report it: https://pagure.io/fedora-infrastructure/new_issue
RE: PWG+OpenPrinting meetup 2023
Hi Zdenek, Regarding packaging pappl-retrofit and printer applications, looking at the pappl-retrofit based snaps from Till Kamppeter, I suspect the existing Fedora pappl package might need to be modified. For example, extract from ps-printer-app's snapcraft.yaml file which modifies pappl's default build settings: https://github.com/OpenPrinting/ps-printer-app/blob/master/snap/snapcraft.yaml pappl: ... override-build: | set -eux # Raise the supported number of vendor-specific options/attributes in # PAPPL to 256, as the original 32 can be too small for some busy PPD # files perl -p -i -e 's/(define\s+PAPPL_MAX_VENDOR\s+)32/\1 256/' pappl/printer.h # De-activate log-rotating. It does not work with the forked processes # of the filters perl -p -i -e 's/(system->logmaxsize\s+=).*/\1 0;/' pappl/system.c # As we do not use PAPPL's own backends but the CUPS backends using the # "cups" device scheme of pappl-retrofit, we let the manual "Network # Printer" device on the "Add Printer" page of the web interface use a # "cups:socket://..." URI instead of simply "socket://..." perl -p -i -e 's/(httpAssembleURI\(.*?)"socket"(.*?\))/\1"cups:socket"\2/' pappl/system-webif.c # PAPPL's build system does not insert the LDFLAGS when linking. # Patching Makedefs.in to fix this perl -p -i -e 's/^(\s*DSOFLAGS\s*=\s*\S*\s+)/\1\$\(LDFLAGS\) /' Makedefs.in Cheers, Doug -Original Message- From: Zdenek Dohnal Sent: Thursday, May 18, 2023 4:26 AM To: Development discussions related to Fedora Subject: PWG+OpenPrinting meetup 2023 Hi all, I've joined annual PWG+OpenPrinting virtual meetup where the news and statuses from the current printing development are discussed. The main points are: - cups-filters 2.0 betas and release candidates are released and present in Fedora 38 - since new cups-filters are in Fedora 38, nothing stands in the way of packaging pappl-retrofit and printer applications based on it into Fedora as RPMs - any volunteers are welcome! - CUPS 2.4.x, CUPS 2.5 and CUPS 3.0 are delayed: - 2.4.x - there are several regressions I haven't able to tackle yet, but I hope there is a new version in a month - 2.5 - OAuth support took lot of time to implement - 3.0 - libcups (its version 3.0) has a beta which developers which uses libcups 2.0 can compile and link their applications and see what changed between major release - GTK (its version 4) has merged support for Common Print Dialog Backends - universal print dialog, which can work not only with cups, but with other possible backends (like google cloud print) - WIP on Printer Setup Tool for GNOME Control Center - full support for driverless printers and printers via printer applications The full report is attached. Zdenek -- Zdenek Dohnal Software Engineer Red Hat, BRQ-TPBC ___ 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, report it: https://pagure.io/fedora-infrastructure/new_issue
[EPEL-devel] Fedora EPEL 7 updates-testing report
The following Fedora EPEL 7 Security updates need testing: Age URL 6 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2023-c5ad3565aa libmodsecurity-3.0.9-2.el7 4 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2023-560bc00f33 golang-1.19.10-1.el7 3 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2023-9dad7fa701 chromium-114.0.5735.198-1.el7 The following builds have been pushed to Fedora EPEL 7 updates-testing xrootd-5.6.0-1.el7 Details about builds: xrootd-5.6.0-1.el7 (FEDORA-EPEL-2023-d2c1d06db9) Extended ROOT file server Update Information: xrootd 5.6.0 ChangeLog: * Sun Jul 2 2023 Mattias Ellert - 1:5.6.0-1 - Update to version 5.6.0 - Drop patches (changes implemented upstream) * Wed Jun 14 2023 Python Maint - 1:5.5.5-3 - Rebuilt for Python 3.12 * Sun May 21 2023 Mattias Ellert - 1:5.5.5-2 - Fix build failure with latest glibc ___ 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, report it: https://pagure.io/fedora-infrastructure/new_issue
[EPEL-devel] Fedora EPEL 8 updates-testing report
The following Fedora EPEL 8 Security updates need testing: Age URL 3 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2023-81803bf20b chromium-114.0.5735.198-1.el8 The following builds have been pushed to Fedora EPEL 8 updates-testing classpathless-compiler-2.2-1.el8 conky-1.19.2-1.1.el8 fastfetch-1.12.1-1.el8 nativefiledialog-extended-1.1.0-1.el8 xrootd-5.6.0-1.el8 Details about builds: classpathless-compiler-2.2-1.el8 (FEDORA-EPEL-2023-9bbe7eb9a2) Tool for recompiling java sources with customizable class providers Update Information: bumped to 2.2 ChangeLog: * Wed Jan 18 2023 Fedora Release Engineering - 2.2 - bumped to 2.2 conky-1.19.2-1.1.el8 (FEDORA-EPEL-2023-35cee06924) A system monitor for X Update Information: - Update to 1.19.2 ChangeLog: * Mon Jul 3 2023 Mosaab Alzoubi - 1.19.2-1.1 - Build for EPEL8 * Wed Jun 21 2023 Miroslav Lichvar - 1.19.2-1 - update to 1.19.2 * Tue Jun 13 2023 Leigh Scott - 1.19.0-2 - Rebuild fo new imlib2 * Mon Apr 3 2023 Miroslav Lichvar - 1.19.0-1 - update to 1.19.0 * Mon Mar 6 2023 Miroslav Lichvar - 1.18.2-1 - update to 1.18.2 * Mon Feb 27 2023 Miroslav Lichvar - 1.18.1-1 - update to 1.18.1 * Mon Feb 20 2023 Miroslav Lichvar - 1.18.0-1 - update to 1.18.0 * Thu Jan 19 2023 Fedora Release Engineering - 1.15.0-2 - Rebuilt for https://fedoraproject.org/wiki/Fedora_38_Mass_Rebuild * Tue Oct 25 2022 Miroslav Lichvar - 1.15.0-1 - update to 1.15.0 * Tue Sep 20 2022 Miroslav Lichvar - 1.13.1-1 - update to 1.13.1 - enable ncurses support fastfetch-1.12.1-1.el8 (FEDORA-EPEL-2023-9444608408) Like neofetch, but much faster because written in c Update Information: update to 1.12.1 update to 1.11.3 ChangeLog: * Mon Jul 3 2023 Jonathan Wright - 1.12.1-1 - Update to 1.12.1 rhbz#2219147 * Mon Jun 26 2023 Jonathan Wright - 1.11.3-1 - Update to 1.11.3 rhbz#2210504 nativefiledialog-extended-1.1.0-1.el8 (FEDORA-EPEL-2023-133965e0e3) Native file dialog library with C and C++ bindings Update Information: update to 1.1.0 ChangeLog: * Mon Jul 3 2023 Jonathan Wright - 1.1.0-1 - Update to 1.1.1 rhbz#2219052 xrootd-5.6.0-1.el8 (FEDORA-EPEL-2023-568e2f7a94) Extended ROOT file server Update Information: xrootd 5.6.0 ChangeLog: * Sun Jul 2 2023 Mattias Ellert - 1:5.6.0-1 - Update to version 5.6.0 - Drop patches (changes implemented upstream) * Wed Jun 14 2023 Python Maint - 1:5.5.5-3 - Rebuilt for Python 3.12 * Sun May 21 2023 Mattias Ellert - 1:5.5.5-2 - Fix build failure with latest glibc ___ 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, report it: https://pagure.io/fedora-infrastructure/new_issue
[EPEL-devel] Fedora EPEL 9 updates-testing report
The following Fedora EPEL 9 Security updates need testing: Age URL 3 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2023-64db16429d chromium-114.0.5735.198-1.el9 The following builds have been pushed to Fedora EPEL 9 updates-testing classpathless-compiler-2.2-1.el9 conky-1.19.2-1.el9 fastfetch-1.12.1-1.el9 imapfilter-2.8.1-1.el9 imhex-1.30.1-4.el9 nativefiledialog-extended-1.1.0-1.el9 python-pillow-9.5.0-2.el9 rsyntaxtextarea-3.1.3-2.el9 rust-gix-trace-0.1.2-1.el9 rust-shellexpand-3.1.0-1.el9 rust-shellexpand2-2.1.2-1.el9 xrootd-5.6.0-1.el9 yt-dlp-2023.06.21-1.el9 Details about builds: classpathless-compiler-2.2-1.el9 (FEDORA-EPEL-2023-5f583ee98f) Tool for recompiling java sources with customizable class providers Update Information: CpLc for epel9! now bumped to 2.2 ChangeLog: * Wed Jan 18 2023 Fedora Release Engineering - 2.2 - bumped to 2.2 * Fri Jan 7 2022 Marian Koncek - 2.1.1-1 - Update to upstream version 2.1.1 * Thu Aug 12 2021 Marian Koncek - 1.4-4 - Fix Requires * Fri Aug 6 2021 Marian Koncek - 1.4-3 - Rebuild * Fri Aug 6 2021 Marian Koncek - 1.4-2 - Fix BuildRequires on java-11-headless * Thu Jul 22 2021 Marian Koncek - 1.4-1 - Update to upstream version 1.4 * Tue Jul 13 2021 Marian Koncek - 1.3-1 - Initial release conky-1.19.2-1.el9 (FEDORA-EPEL-2023-e0ea31b81a) A system monitor for X Update Information: - Update to 1.19.2 ChangeLog: * Wed Jun 21 2023 Miroslav Lichvar - 1.19.2-1 - update to 1.19.2 * Tue Jun 13 2023 Leigh Scott - 1.19.0-2 - Rebuild fo new imlib2 * Mon Apr 3 2023 Miroslav Lichvar - 1.19.0-1 - update to 1.19.0 * Mon Mar 6 2023 Miroslav Lichvar - 1.18.2-1 - update to 1.18.2 * Mon Feb 27 2023 Miroslav Lichvar - 1.18.1-1 - update to 1.18.1 * Mon Feb 20 2023 Miroslav Lichvar - 1.18.0-1 - update to 1.18.0 * Thu Jan 19 2023 Fedora Release Engineering - 1.15.0-2 - Rebuilt for https://fedoraproject.org/wiki/Fedora_38_Mass_Rebuild * Tue Oct 25 2022 Miroslav Lichvar - 1.15.0-1 - update to 1.15.0 * Tue Sep 20 2022 Miroslav Lichvar - 1.13.1-1 - update to 1.13.1 - enable ncurses support fastfetch-1.12.1-1.el9 (FEDORA-EPEL-2023-5504a21466) Like neofetch, but much faster because written in c Update Information: update to 1.12.1 update to 1.11.3 ChangeLog: * Mon Jul 3 2023 Jonathan Wright - 1.12.1-1 - Update to 1.12.1 rhbz#2219147 * Mon Jun 26 2023 Jonathan Wright - 1.11.3-1 - Update to 1.11.3 rhbz#2210504 imapfilter-2.8.1-1.el9 (FEDORA-EPEL-2023-d4cd960d99) A flexible client side mail filtering utility for IMAP servers Update Information: Initial release for epel9 ChangeLog: * Sun Jul 2 2023 Sandro - 2.8.1-1 - Update to 2.8.1 (RHBZ#2079180) References: [ 1 ] Bug #2079180 - imapfilter: add build for EPEL 8 https://bugzilla.redhat.com/show_bug.cgi?id=2079180 imhex-1.30.1-4.el9 (FEDORA-EPEL-2023-a0746a96db) A hex editor for reverse engineers and programmers Update Information: add subpackage for imhex-patterns Update to 1.30.1 ChangeLog: * Mon Jul 3 2023 Jonathan Wright - 1.30.1-4 - Use tar to uncompress source1 - rhel9 does not have rpmuncompress * Mon Jul 3 2023 Jonathan Wright - 1.30.1-3 - Create imhex-patterns subpackage rhbz#2219447 * Wed Jun 28 2023 Vitaly Zaitsev - 1.30.1-2 - Rebuilt due to fmt 10 update. * Mon Jun 26 2023 Jonathan Wright -
Re: How to use llvm15 for building a package
On 7/3/23 11:31, Luya Tshimbalanga wrote: Hello team, I attempt to build openshadinglanguage with llvm15 as upstream has yet to support LLVM 16. Can someone have a pointed how to set a cmake parameter for llvm15 and its bitecode validation? See the spec file on: https://src.fedoraproject.org/rpms/openshadinglanguage/blob/rawhide/f/openshadinglanguage.spec Have you tried changing the BuildRequires from llvm-devel to llvm15-devel and clang-devel to clang15-devel? It may autodetect llvm15 if you do that. -Tom Thanks in advance. -- Luya Tshimbalanga Fedora Design Team Fedora Design Suite maintainer ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue ___ 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, report it: https://pagure.io/fedora-infrastructure/new_issue
[Bug 2219483] New: perl-Sentinel-0.07 is available
https://bugzilla.redhat.com/show_bug.cgi?id=2219483 Bug ID: 2219483 Summary: perl-Sentinel-0.07 is available Product: Fedora Version: rawhide Status: NEW Component: perl-Sentinel Keywords: FutureFeature, Triaged Assignee: emman...@seyman.fr Reporter: upstream-release-monitor...@fedoraproject.org QA Contact: extras...@fedoraproject.org CC: emman...@seyman.fr, perl-devel@lists.fedoraproject.org Target Milestone: --- Classification: Fedora Releases retrieved: 0.07 Upstream release that is considered latest: 0.07 Current version/release in rawhide: 0.06-14.fc38 URL: http://search.cpan.org/dist/Sentinel/ 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://docs.fedoraproject.org/en-US/package-maintainers/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/13006/ To change the monitoring settings for the project, please visit: https://src.fedoraproject.org/rpms/perl-Sentinel -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2219483 Report this comment as SPAM: https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla=report-spam_desc=Report%20of%20Bug%202219483%23c0 ___ 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, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F39 Change Proposal: Anaconda WebUI for Fedora Workstation by default (System-Wide)
On Mon, Jul 3, 2023 at 6:36 PM Jiří Konečný wrote: > > Hi, see my replies below. > > 2. července 2023 23:56:59 SELČ, Demi Marie Obenour > napsal: > >On 6/27/23 05:00, Simon de Vlieger wrote: > >> On 6/27/23 10:40, Hans de Goede wrote: > >> > >> > Ok, so can you provide some instructions for how to make this work ? > >> I guess it would be something like add the cmdline option + then start > >> some systemd unit ? Can you please put some instructions for this in > >> the testing section of: > >> https://fedoraproject.org/wiki/Changes/AnacondaWebUIforFedoraWorkstation > >> (with a note that this is currently not supported / recommended). > >> > > >> >> About the improvements on the Live ISO, that should be a question on > >> Fedora Workstation SIG. Anaconda team is not in charge of the > >> environment on the Live ISO. > >> > > >> > Well you are suggesting a change that is likely going to > >> significantly increase the amount of memory needed to do a livecd > >> workstation install and as mentioned above pushing the requirements > >> above 2G would basically block this change since 2G RAM is currently the > >> advertised minimum RAM requirement for Fedora workstation installs. > >> > > >> > So although I realize this is not entirely fair IMHO if you want to > >> push forward with this feature then you may also be on the hook to look > >> into reducing the memory footprint elsewhere so that the end result > >> still fits in 2G RAM. I have some experience with tweaking the livecd to > >> work with less RAM and I'm happy to share my experience in this, but I > >> do not have time to actually implement needed changes for this. > >> Hi Hans, > >> > >> it would indeed involve adding the `inst.webui` and `inst.webui.remote` > >> kernel command line options and a systemd unit to start the relevant > >> services (I *think* that'd only be `cockpit.service`). > > > >Remote installation is not a solution to the memory bloat. It only > >pushes the problem to whatever machine the browser runs on, and it > >has significant and negative security implications. A solution > >here would be ensuring that the web UI uses no more RAM than the > >GTK UI that preceded it. > > Please, take into account that we are not an application which stays open on > background for hours (usually), so you can't put this to the same level as > music player or similar apps. > Anyway, I'm pretty sure that every usable machine as desktop PC, is able to > open one web page for the installation process. > > From the other point, I wonder how much memory the VNC client (solution right > now) is taking. And security point with VNC is (based on my understanding) > maybe worse than HTTPS browsers. > > > Hard to say what technology has the same memory footprint as GTK3. I think, > there are not many options. From the other point, using this logic in the > past, we would still be using ncurses based installations. Don't take me > wrong, I see your point and memory footprint is important. Just saying it is > not the only point you should take into account. I would also note that the work being done here does not obviate the future return of a community-developed graphical frontend for Anaconda. For example, the previous architecture made it impossible for anyone to consider developing a Qt based frontend for Anaconda. That option is now open for the first time in Anaconda's history. And the GUI could run unprivileged while the Anaconda services run privileged in the background, which is required for a Wayland-based application anyway. -- 真実はいつも一つ！/ 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, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F39 Change Proposal: Anaconda WebUI for Fedora Workstation by default (System-Wide)
Hi, see my replies below. 2. července 2023 23:56:59 SELČ, Demi Marie Obenour napsal: >On 6/27/23 05:00, Simon de Vlieger wrote: >> On 6/27/23 10:40, Hans de Goede wrote: >> >> > Ok, so can you provide some instructions for how to make this work ? >> I guess it would be something like add the cmdline option + then start >> some systemd unit ? Can you please put some instructions for this in >> the testing section of: >> https://fedoraproject.org/wiki/Changes/AnacondaWebUIforFedoraWorkstation >> (with a note that this is currently not supported / recommended). >> > >> >> About the improvements on the Live ISO, that should be a question on >> Fedora Workstation SIG. Anaconda team is not in charge of the >> environment on the Live ISO. >> > >> > Well you are suggesting a change that is likely going to >> significantly increase the amount of memory needed to do a livecd >> workstation install and as mentioned above pushing the requirements >> above 2G would basically block this change since 2G RAM is currently the >> advertised minimum RAM requirement for Fedora workstation installs. >> > >> > So although I realize this is not entirely fair IMHO if you want to >> push forward with this feature then you may also be on the hook to look >> into reducing the memory footprint elsewhere so that the end result >> still fits in 2G RAM. I have some experience with tweaking the livecd to >> work with less RAM and I'm happy to share my experience in this, but I >> do not have time to actually implement needed changes for this. >> Hi Hans, >> >> it would indeed involve adding the `inst.webui` and `inst.webui.remote` >> kernel command line options and a systemd unit to start the relevant >> services (I *think* that'd only be `cockpit.service`). > >Remote installation is not a solution to the memory bloat. It only >pushes the problem to whatever machine the browser runs on, and it >has significant and negative security implications. A solution >here would be ensuring that the web UI uses no more RAM than the >GTK UI that preceded it. Please, take into account that we are not an application which stays open on background for hours (usually), so you can't put this to the same level as music player or similar apps. Anyway, I'm pretty sure that every usable machine as desktop PC, is able to open one web page for the installation process. From the other point, I wonder how much memory the VNC client (solution right now) is taking. And security point with VNC is (based on my understanding) maybe worse than HTTPS browsers. Hard to say what technology has the same memory footprint as GTK3. I think, there are not many options. From the other point, using this logic in the past, we would still be using ncurses based installations. Don't take me wrong, I see your point and memory footprint is important. Just saying it is not the only point you should take into account. Best Regards, Jirka ___ 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, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F39 Change Proposal: Anaconda WebUI for Fedora Workstation by default (System-Wide)
Hi 3. července 2023 18:57:39 SELČ, Michael Catanzaro napsal: >On Mon, Jul 3 2023 at 12:32:02 PM -0400, Demi Marie Obenour > wrote: >> Why is that? WebKitGTK+ is one of those packages that one should only >> ship if one is willing to take every update from upstream, but my >> understanding is that WebKitGTK+ tries quite hard to make this easy. > >The set of packages to include in ELN is a business decision (which is in >contrast to normal Fedora, where Fedora contributors should hopefully be >making decisions in the best interest of the Fedora community). Although I >don't get to talk directly about future enterprise Linux, what we are doing in >ELN is inherently public and you can see some discussion here: > >https://src.fedoraproject.org/rpms/webkitgtk/pull-request/4 > >Michael Thanks Michael for answering this. I'll also add that even now we already hit a bug in WebKit which seems to not get fixed anytime soon. In other words Firefox has much better support level. Anyway, if someone really wish for something else to show the Anaconda it could be discussed. It's definitely doable but we have to think about maintainability PoV. Best Regards, Jirka >___ >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, report it: >https://pagure.io/fedora-infrastructure/new_issue ___ 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, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: [HEADS UP] Fedora 39 Python 3.12 rebuilds to start in a side tag this week
Hi Tomáš, I have been looking at this one: > python-metar jdekloe and I think it needs to be fixed upstream before it can be build for python3.12. Of course the failing tests can be disabled, but that may just hide that the module is crippled. So I opened this issue upstream: https://github.com/python-metar/python-metar/issues/175 Best regards, Jos. On 6/27/23 20:43, Tomáš Hrnčiar wrote: Hello, I'd like to provide an update on Python 3.12 mass rebuild. The mass rebuild is still in progress. So far 2666 packages were rebuilt in side tag which is about 65,8% out of 4049 python packages. We are now working on fixing important packages blocking others. As mentioned in previous email - if you see a "Rebuilt for Python 3.12" (or similar) commit in your package, please don't rebuild it in regular rawhide or another rawhide side tag. If you need to, please let us know, so we can coordinate. If you'd like to build a package after we already rebuilt it, you should be able to build it in the side tag via: on branch rawhide: $ fedpkg build --target=f39-python $ koji wait-repo f39-python --build Note that it will take a while before all the essential packages are rebuilt, so don't expect all your dependencies to be available right away. Please, don't attempt to build your package in the side tag before we do. When in trouble, ask here or on IRC (#fedora-python on Libera.Chat). Ping me (thrnciar) or Miro (mhroncok) if you need to talk to us. Builds: https://koji.fedoraproject.org/koji/builds?latest=0=f39-python=-build_id=0 Please avoid any potentially disturbing or major changes in Python packages until the rebuild is over. Thanks. Let us know if you have any questions. Here is the list of packages that failed to build but their dependencies are available. If you'd like to help us, any fixes are welcome. Please build the package with --target=f39-python if you fix it. If your package is failing with ModuleNotFoundError: No module named 'imp', this is happening because Python 3.12 removed the long deprecated imp module. As a stopgap measure, you can BuildRequire python3-zombie-imp package, which allows you to import the imp module even on Python 3.12. We strongly recommend talking to upstream and encouraging them to migrate to importlib instead. Maintainers by package: ... snip Please avoid any potentially disturbing or major changes in Python packages until the rebuild is over. Thanks. Let us know if you have any questions. ___ python-devel mailing list -- python-devel@lists.fedoraproject.org To unsubscribe send an email to python-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://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/python-devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Orphaning packages (was LibreOffice packages)
Am 03.07.23 um 18:07 schrieb Simon de Vlieger: On 7/3/23 13:46, Ralf Corsépius wrote: It is the core of the problem esp. big US companies tend to ignore. May-be you guys are not aware of there are tendencies to legally prohibit such "cloud solutions" in many countries? It's generally not so much 'legally prohibit' as 'data has to be kept within $jurisdiction and is not to be shared outside of it'. If $jurisdiction is large enough cloud operators tend to offer that solution. Its not a cloud provider its a software vendor. Further more a couple of authoritative entities have proven that such solutions do not comply with data protection requirements. Its of value having a standalone package (to getting back to the topic). If not now, for sure in the near future. -- Leon ___ 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, report it: https://pagure.io/fedora-infrastructure/new_issue
How to use llvm15 for building a package
Hello team, I attempt to build openshadinglanguage with llvm15 as upstream has yet to support LLVM 16. Can someone have a pointed how to set a cmake parameter for llvm15 and its bitecode validation? See the spec file on: https://src.fedoraproject.org/rpms/openshadinglanguage/blob/rawhide/f/openshadinglanguage.spec Thanks in advance. -- Luya Tshimbalanga Fedora Design Team Fedora Design Suite maintainer ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F39 Change Proposal: Anaconda WebUI for Fedora Workstation by default (System-Wide)
Hello. And to add to the reasons, if the GTK4 bindings of webkit would be used, we would lose screen reader accessibility completely, see https://bugs.webkit.org/show_bug.cgi?id=227528. Regards, Lukáš Dne 03.07.2023 v 18:15 Simon de Vlieger napsal(a): On 7/3/23 17:18, Demi Marie Obenour wrote: Fair. I wonder how much of that memory use would go away if instead of using Firefox, the web content ran in an embedded WebKitGTK+ webview. Browser security is not a concern here because in this case the web content is trusted, and this would also allow using WebKitGTK+’s URL redirection features instead of HTTP over localhost. Funnily enough it was switched explicitly from webkitgtk to Firefox for a reason I forget; I think it was related to disk size. Perhaps Martin or Jiri has more details to share on that. > That said, I do want to check that the new Anaconda installer and all > of its transitive dependencies will be built from source on Fedora > infrastructure. That means _actual_ sources as found in the SCM > repository, not the minified blobs one finds on NPM. Web stuff has > historically been extremely packaging-unfriendly for this reason, and > the Node ecosystem has a long history of supply-chain attacks. Using > a React-based UI should mean finding the original source code to all > of the transitive NPM dependencies, then rebuilding all of them on > Fedora infrastructure. As far as I know cockpit builds (don't know where) all its dependencies and ships them as part of their package but I could be very wrong on this. You could take a look there or direct questions about it there. The Anaconda WebUI is implemented "in" cockpit. ___ 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, report it: https://pagure.io/fedora-infrastructure/new_issue ___ 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, report it: https://pagure.io/fedora-infrastructure/new_issue
[rpms/perl-CPAN-Perl-Releases] PR #12: 5.20230703 bump
mspacek merged a pull-request against the project: `perl-CPAN-Perl-Releases` that you are following. Merged pull-request: `` 5.20230703 bump `` https://src.fedoraproject.org/rpms/perl-CPAN-Perl-Releases/pull-request/12 ___ 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, report it: https://pagure.io/fedora-infrastructure/new_issue
[rpms/perl-CPAN-Perl-Releases] PR #11: 5.20230703 bump
mspacek merged a pull-request against the project: `perl-CPAN-Perl-Releases` that you are following. Merged pull-request: `` 5.20230703 bump `` https://src.fedoraproject.org/rpms/perl-CPAN-Perl-Releases/pull-request/11 ___ 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, report it: https://pagure.io/fedora-infrastructure/new_issue
[rpms/perl-CPAN-Perl-Releases] PR #10: 5.20230703 bump
mspacek merged a pull-request against the project: `perl-CPAN-Perl-Releases` that you are following. Merged pull-request: `` 5.20230703 bump `` https://src.fedoraproject.org/rpms/perl-CPAN-Perl-Releases/pull-request/10 ___ 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, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F39 Change Proposal: Anaconda WebUI for Fedora Workstation by default (System-Wide)
On Mon, Jul 3 2023 at 12:32:02 PM -0400, Demi Marie Obenour wrote: Why is that? WebKitGTK+ is one of those packages that one should only ship if one is willing to take every update from upstream, but my understanding is that WebKitGTK+ tries quite hard to make this easy. The set of packages to include in ELN is a business decision (which is in contrast to normal Fedora, where Fedora contributors should hopefully be making decisions in the best interest of the Fedora community). Although I don't get to talk directly about future enterprise Linux, what we are doing in ELN is inherently public and you can see some discussion here: https://src.fedoraproject.org/rpms/webkitgtk/pull-request/4 Michael ___ 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, report it: https://pagure.io/fedora-infrastructure/new_issue
[rpms/perl-CPAN-Perl-Releases] PR #12: 5.20230703 bump
mspacek opened a new pull-request against the project: `perl-CPAN-Perl-Releases` that you are following: `` 5.20230703 bump `` To reply, visit the link below https://src.fedoraproject.org/rpms/perl-CPAN-Perl-Releases/pull-request/12 ___ 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, report it: https://pagure.io/fedora-infrastructure/new_issue
[rpms/perl-CPAN-Perl-Releases] PR #11: 5.20230703 bump
mspacek opened a new pull-request against the project: `perl-CPAN-Perl-Releases` that you are following: `` 5.20230703 bump `` To reply, visit the link below https://src.fedoraproject.org/rpms/perl-CPAN-Perl-Releases/pull-request/11 ___ 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, report it: https://pagure.io/fedora-infrastructure/new_issue
[rpms/perl-CPAN-Perl-Releases] PR #10: 5.20230703 bump
mspacek opened a new pull-request against the project: `perl-CPAN-Perl-Releases` that you are following: `` 5.20230703 bump `` To reply, visit the link below https://src.fedoraproject.org/rpms/perl-CPAN-Perl-Releases/pull-request/10 ___ 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, report it: https://pagure.io/fedora-infrastructure/new_issue
[Bug 2219204] perl-CPAN-Perl-Releases-5.20230703 is available
https://bugzilla.redhat.com/show_bug.cgi?id=2219204 Michal Josef Spacek changed: What|Removed |Added Doc Type|--- |If docs needed, set a value Status|NEW |ASSIGNED Assignee|jples...@redhat.com |mspa...@redhat.com --- Comment #1 from Michal Josef Spacek --- Changes: --- version 5.20230703 at 2023-07-02 23:53:11 + --- Change: bfcaedc47ff3b2eb41b8937c90d88f8d6e1f6978 Author: Chris 'BinGOs' Williams Date : 2023-07-03 00:53:11 + Updated for v5.38.0 For rawhide, f38, f37 -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2219204 Report this comment as SPAM: https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla=report-spam_desc=Report%20of%20Bug%202219204%23c1 ___ 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, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F39 Change Proposal: Anaconda WebUI for Fedora Workstation by default (System-Wide)
On 7/3/23 12:30, Michael Catanzaro wrote: > On Mon, Jul 3 2023 at 06:15:43 PM +0200, Simon de Vlieger > wrote: >> Funnily enough it was switched explicitly from webkitgtk to Firefox >> for >> a reason I forget; I think it was related to disk size. Perhaps Martin >> or Jiri has more details to share on that. > > It's because we're going to remove WebKitGTK from ELN. > > Michael Why is that? WebKitGTK+ is one of those packages that one should only ship if one is willing to take every update from upstream, but my understanding is that WebKitGTK+ tries quite hard to make this easy. -- Sincerely, Demi Marie Obenour (she/her/hers) ___ 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, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F39 Change Proposal: Anaconda WebUI for Fedora Workstation by default (System-Wide)
On Mon, Jul 3 2023 at 06:15:43 PM +0200, Simon de Vlieger wrote: Funnily enough it was switched explicitly from webkitgtk to Firefox for a reason I forget; I think it was related to disk size. Perhaps Martin or Jiri has more details to share on that. It's because we're going to remove WebKitGTK from ELN. Michael ___ 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, report it: https://pagure.io/fedora-infrastructure/new_issue
[Bug 2219232] perl-Lingua-EN-Fathom-1.24 is available
https://bugzilla.redhat.com/show_bug.cgi?id=2219232 Michal Josef Spacek changed: What|Removed |Added Doc Type|--- |If docs needed, set a value Status|NEW |ASSIGNED --- Comment #1 from Michal Josef Spacek --- Changes: Measure blank and non text lines correctly. Thanks to Jeffrey Grace for the bug report API changes, only for rawhide -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2219232 Report this comment as SPAM: https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla=report-spam_desc=Report%20of%20Bug%202219232%23c1 ___ 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, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F39 Change Proposal: Anaconda WebUI for Fedora Workstation by default (System-Wide)
On 7/3/23 17:18, Demi Marie Obenour wrote: Fair. I wonder how much of that memory use would go away if instead of using Firefox, the web content ran in an embedded WebKitGTK+ webview. Browser security is not a concern here because in this case the web content is trusted, and this would also allow using WebKitGTK+’s URL redirection features instead of HTTP over localhost. Funnily enough it was switched explicitly from webkitgtk to Firefox for a reason I forget; I think it was related to disk size. Perhaps Martin or Jiri has more details to share on that. > That said, I do want to check that the new Anaconda installer and all > of its transitive dependencies will be built from source on Fedora > infrastructure. That means _actual_ sources as found in the SCM > repository, not the minified blobs one finds on NPM. Web stuff has > historically been extremely packaging-unfriendly for this reason, and > the Node ecosystem has a long history of supply-chain attacks. Using > a React-based UI should mean finding the original source code to all > of the transitive NPM dependencies, then rebuilding all of them on > Fedora infrastructure. As far as I know cockpit builds (don't know where) all its dependencies and ships them as part of their package but I could be very wrong on this. You could take a look there or direct questions about it there. The Anaconda WebUI is implemented "in" cockpit. ___ 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, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Minified JS and CSS in Node packages
On 03/07/2023 17:09, Demi Marie Obenour wrote: On 7/3/23 11:59, Tom Hughes wrote: On 03/07/2023 16:41, Demi Marie Obenour wrote: Would it be possible to ensure that Node packages contain only actual source code, as in “the preferred form for making modifications” (quote from GNU GPL, I forget which version)? The simple answer is maybe in principle but in practice it's very hard as numerous previous threads will tell you. The tar balls from the npmjs registry which constitute the released versions of node packages frequently contain such things often without the original source or any of the tooling to build from it. The alternative is packaging from the upstream git but even then, and even if it is well maintained with version tags, there are often huge dependency chains to get all the tools needed to actually do the builds. I thought Fedora policy required shipping actual source code, in which case this alternative is the only option allowed. Yes you're right, and there's long been a question of exactly what constitutes that with javascript packages. When I was packaging and reviewing Node stuff I certainly tried to do so where it was in any way feasible. Minimisers weren't usually too bad - you can always just skip them after all - but once you start dealing with transpilers it can get a lot harder plus you often wind up having to write your own build script because the upstream one is using one of a dozen different Node based tools each of which has hundreds of dependent modules you would need to package. Tom -- Tom Hughes (t...@compton.nu) http://compton.nu/ ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://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, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Minified JS and CSS in Node packages
On 7/3/23 11:59, Tom Hughes wrote: > On 03/07/2023 16:41, Demi Marie Obenour wrote: > >> Would it be possible to ensure that Node packages contain only actual source >> code, as in “the preferred form for making modifications” (quote from GNU >> GPL, >> I forget which version)? > > The simple answer is maybe in principle but in practice it's > very hard as numerous previous threads will tell you. > > The tar balls from the npmjs registry which constitute the > released versions of node packages frequently contain such > things often without the original source or any of the tooling > to build from it. > > The alternative is packaging from the upstream git but even > then, and even if it is well maintained with version tags, there > are often huge dependency chains to get all the tools needed to > actually do the builds. I thought Fedora policy required shipping actual source code, in which case this alternative is the only option allowed. -- Sincerely, Demi Marie Obenour (she/her/hers) ___ 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, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: LibreOffice packages
On Sun, Jul 2, 2023 at 5:01 PM Demi Marie Obenour wrote: > On 6/3/23 08:42, Michael Catanzaro wrote: > > On Sat, Jun 3 2023 at 10:26:07 AM -, John Iliopoulos < > jxftw2...@gmail.com> wrote: > >> Hello, > >> > >> While i completely understand why you do this i do think that it is > >> important for desktop/workstation oriented devices to have some > >> optional access to Office directly from the image file. Have you > >> considered shipping the LibreOffice flatpak via the ISO much like > >> Fedora Silverblue does with various other applications? > >> > >> This is the first time i reply to a mailing list so i hope i have not > >> done anything wrong. > > > > Hi. Welcome to the list. You haven't done anything wrong. > > > > For Fedora Workstation, the mid-term plan is to ship all preinstalled > > apps as Fedora Flatpaks. We cannot ship anything from Flathub because > > FESCo will not allow it. I don't *like* this FESCo requirement, but I > > also don't expect that to change. Accordingly, since Fedora Flatpaks > > are built from Fedora RPMs, maintaining the LibreOffice RPMs is > > essential to keep LibreOffice preinstalled. (I think that applies to > > Silverblue as well?) > > Fedora Flatpaks are also a security disaster: they are shipped in OCI > format instead of OSTree format, but they aren’t signed by anyone. > I’ve disabled the Fedora remote and recommend that others do the same. > I think the words "security disaster" are painting a too strong picture here. When you install a Fedora Flatpak, the digest of the content being installed is checked against the checksums embedded in the index downloaded from (e.g. https://registry.fedoraproject.org/index/static?label:org.flatpak.ref:exists=1=linux=amd64=latest). These indexes are statically generated from data queried from Bodhi and Koji and downloaded from a static web server directly from Fedora bypassing the CDN. The most obvious way to get malicious content into this index would be to inject it at build time, by adding it upstream, infiltrating the Fedora project, hacking a Fedora contributor, etc. In all of these cases, if we had container signatures, robosignatory would happily sign it when the update was created. Yes, someone could hack the server hosting the index, get write-access to the mount hosting the indexes, or find some specific way to exploit the indexing process. And in those cases, having checked signatures would help. The first two cases would seem to imply a widespread breach of Fedora infrastructure that would likely affect security of builds as well. What would be needed to implement signatures would be roughly: - Implement container signatures in robosignatory/sigul - Implement distribution of signatures (probably easiest if we move registry.fedoraproject.org to quay.io as planned for a while) - Implement checkingo of container signatures in the Flatpak client One thing that helps now is that for a long time there was a lot of uncertainty in where signatures were going in the container world, but at this point, at least Red Hat parts of the container world seems to be solidly behind the approach of https://github.com/sigstore/cosign. (Still a lot of details / moving parts that would have to be researched.) - Owen ___ 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, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Orphaning packages (was LibreOffice packages)
On 7/3/23 13:46, Ralf Corsépius wrote: It is the core of the problem esp. big US companies tend to ignore. May-be you guys are not aware of there are tendencies to legally prohibit such "cloud solutions" in many countries? It's generally not so much 'legally prohibit' as 'data has to be kept within $jurisdiction and is not to be shared outside of it'. If $jurisdiction is large enough cloud operators tend to offer that solution. ___ 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, report it: https://pagure.io/fedora-infrastructure/new_issue
[Bug 2072972] Review Request: perl-IP-Geolocation-MMDB - Read MaxMind DB files
https://bugzilla.redhat.com/show_bug.cgi?id=2072972 Michal Josef Spacek changed: What|Removed |Added Flags|fedora-review? |fedora-review+ --- Comment #6 from Michal Josef Spacek --- Source file is ok Summary is ok License is ok Description is ok URL and Source are ok All tests passed BuildRequires are ok $ rpm -qp --requires perl-IP-Geolocation-MMDB-1.010-1.fc39.x86_64.rpm | sort | uniq -c | grep -v rpmlib 1 libc.so.6(GLIBC_2.2.5)(64bit) 1 libc.so.6(GLIBC_2.4)(64bit) 1 libc.so.6()(64bit) 1 libmaxminddb.so.0()(64bit) 1 libperl.so.5.36()(64bit) 1 perl(IP::Geolocation::MMDB::Metadata) 1 perl-libs 1 perl(Math::BigInt) >= 1.999806 1 perl(:MODULE_COMPAT_5.36.1) 1 perl(utf8) 1 perl(:VERSION) >= 5.16.0 1 perl(warnings) 1 perl(XSLoader) 1 rtld(GNU_HASH) Binary requires are Ok. $ rpm -qp --provides perl-IP-Geolocation-MMDB-1.010-1.fc39.x86_64.rpm | sort | uniq -c 1 perl(IP::Geolocation::MMDB::Metadata) = 1.010 1 perl-IP-Geolocation-MMDB(x86-64) = 1.010-1.fc39 1 perl(IP::Geolocation::MMDB) = 1.010 1 perl-IP-Geolocation-MMDB = 1.010-1.fc39 Binary provides are Ok. $ rpmlint perl-IP-Geolocation-MMDB-* 4 packages and 0 specfiles checked; 0 errors, 0 warnings, 0 badness; has taken 0.3 s Rpmlint is ok The package is in line with Fedora and Perl packaging guide lines. Resolution: approved -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2072972 Report this comment as SPAM: https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla=report-spam_desc=Report%20of%20Bug%202072972%23c6 ___ 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, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Minified JS and CSS in Node packages
On 03/07/2023 16:41, Demi Marie Obenour wrote: Would it be possible to ensure that Node packages contain only actual source code, as in “the preferred form for making modifications” (quote from GNU GPL, I forget which version)? The simple answer is maybe in principle but in practice it's very hard as numerous previous threads will tell you. The tar balls from the npmjs registry which constitute the released versions of node packages frequently contain such things often without the original source or any of the tooling to build from it. The alternative is packaging from the upstream git but even then, and even if it is well maintained with version tags, there are often huge dependency chains to get all the tools needed to actually do the builds. Tom -- Tom Hughes (t...@compton.nu) http://compton.nu/ ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://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, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F39 Change Proposal: No custom Qt theming for Fedora Workstation (Self Contained)
On Mon, Jul 3, 2023 at 10:16 AM Jan Grulich wrote: > > Hi, > > po 26. 6. 2023 v 19:26 odesílatel Fabio Valentini > napsal: >> >> On Thu, Jun 22, 2023 at 6:21 PM Aoife Moloney wrote: >> > >> >> (snip) >> >> > >> > == Detailed Description == >> > [https://github.com/FedoraQt/QGnomePlatform QGnomePlatform] project is >> > a Qt Platform Theme plugin. It reads GNOME configuration, like fonts >> > or icons and applies this configuration to Qt applications. It also >> > provides implementation of Client-Side Window Decorations or native >> > dialogs. This project partially overlaps with Qt's default GTK >> > Platform Theme plugin, but there are some additions that are existing >> > only in QGnomePlatform, like Client-Side Window Decorations. >> >> How will this affect Qt-on-GNOME applications? >> I remember there being problems in the past because gnome-shell / >> mutter apparently did not support SSD. >> Will windows still have decorations in all combinations of >> Qt+X11/Wayland-on-GNOME+X11/Wayland? >> > > Yes, I would like to ideally bring GNOME-like decorations that are currently > provided by QGnomePlatform directly > to Qt upstream. In case I don't make it in time, we will most likely end up > at least shipping that part of QGnomePlatform > that gives you exactly that. Thanks for the explanation, sounds like a good plan to me! 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, report it: https://pagure.io/fedora-infrastructure/new_issue
Minified JS and CSS in Node packages
Looking at the source to llparse reveals that it contains minified versions of lodash, source-map, js-yaml, diff, and snprintf-js. The corresponding source code also appears to be present, but my understanding of Fedora policy is that the minified versions should not be in a Fedora source package. I suspect other packages in the Node ecosystem have the same problem. Would it be possible to ensure that Node packages contain only actual source code, as in “the preferred form for making modifications” (quote from GNU GPL, I forget which version)? -- Sincerely, Demi Marie Obenour (she/her/hers) ___ 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, report it: https://pagure.io/fedora-infrastructure/new_issue
[Bug 2217660] perl-Log-Any-1.716 is available
https://bugzilla.redhat.com/show_bug.cgi?id=2217660 Bug 2217660 depends on bug 2217967, which changed state. Bug 2217967 Summary: Review Request: perl-Devel-StackTrace-Extract - Extract a stack trace from an exception object https://bugzilla.redhat.com/show_bug.cgi?id=2217967 What|Removed |Added Status|ASSIGNED|CLOSED Resolution|--- |RAWHIDE -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2217660 ___ 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, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F39 Change Proposal: Anaconda WebUI for Fedora Workstation by default (System-Wide)
On 7/3/23 03:18, Simon de Vlieger wrote: > On 7/2/23 23:56, Demi Marie Obenour wrote: > >> Remote installation is not a solution to the memory bloat. It only >> pushes the problem to whatever machine the browser runs on, and it >> has significant and negative security implications. A solution >> here would be ensuring that the web UI uses no more RAM than the >> GTK UI that preceded it. > > Hi Demi Marie, > > From what I can see by using `smem` the RSS/PSS for the Anaconda GTK > installer in Fedora 38 is 62 MiB RSS and 22 MiB PSS. The Anaconda WebUI > installer (Firefox) in Fedora 39 is 170 MiB RSS and 115 MiB PSS. > > Note that Hans mentioned removing/disabling sssd_kcm and gnome-calendar > in his thread about minimizing memory usage which is a much larger dent > in total memory usage in the scheme of things. > > Personally I'd also like to point out that I an using a 2 GiB memory > single core VM to test these images to see if the live installer > performs on the lower memory devices (yes, I think we can call 2 GiB low > memory nowadays...). > > Regards, > > Simon Fair. I wonder how much of that memory use would go away if instead of using Firefox, the web content ran in an embedded WebKitGTK+ webview. Browser security is not a concern here because in this case the web content is trusted, and this would also allow using WebKitGTK+’s URL redirection features instead of HTTP over localhost. That said, I do want to check that the new Anaconda installer and all of its transitive dependencies will be built from source on Fedora infrastructure. That means _actual_ sources as found in the SCM repository, not the minified blobs one finds on NPM. Web stuff has historically been extremely packaging-unfriendly for this reason, and the Node ecosystem has a long history of supply-chain attacks. Using a React-based UI should mean finding the original source code to all of the transitive NPM dependencies, then rebuilding all of them on Fedora infrastructure. -- Sincerely, Demi Marie Obenour (she/her/hers) ___ 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, report it: https://pagure.io/fedora-infrastructure/new_issue
[rpms/perl-Test2-Suite] PR #39: Add change for previous commit
mspacek merged a pull-request against the project: `perl-Test2-Suite` that you are following. Merged pull-request: `` Add change for previous commit `` https://src.fedoraproject.org/rpms/perl-Test2-Suite/pull-request/39 ___ 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, report it: https://pagure.io/fedora-infrastructure/new_issue
[rpms/perl-Test2-Suite] PR #39: Add change for previous commit
mspacek opened a new pull-request against the project: `perl-Test2-Suite` that you are following: `` Add change for previous commit `` To reply, visit the link below https://src.fedoraproject.org/rpms/perl-Test2-Suite/pull-request/39 ___ 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, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Red Hat & Fedora -- largely stepping out of this ecosystem
Dne 03. 07. 23 v 16:13 Leon Fauster via devel napsal(a): Am 03.07.23 um 00:41 schrieb Michael Catanzaro: On Sun, Jul 2 2023 at 08:33:46 AM -0700, Carlos Rodriguez-Fernandez wrote: Hi Michael, We have been told repeatedly that "the source is there" in CentOS stream. The source for the next minor version is there. I can see the scenario that RH branches from CentOS stream to create a new minor release, and during QA, a bug is discovered and a patch is backported (or created) to fix it internally in your minor release branch. However, if that bug wants to be addressed also in the next minor release, it will need to appear in the CentOS stream at some point, whether via a patch or an entire source version bump. Right; nobody wants regressions. In this particular example, the fix is there via "an entire source version bump." If that's not the case, then RH is having some long living parallel git repo which will eventually create ABI compatibility issues, and it is also not what we have been told. So I'm really primarily here to talk about Fedora and CentOS Stream, because we often can't talk very much about RHEL. I'm going to point you to this page: https://access.redhat.com/support/policy/updates/errata/ And in particular this graphic: https://access.redhat.com/sites/default/files/images/337_rhel_9_life_cycle_updates_0423.png With the transitioning to "maintenance phase" next summer (EL8), I assume that for the next 5 years nothing gets pushed into c8s git anymore?? Just FTR, the c8s EOL was already announced here: https://blog.centos.org/2023/04/end-dates-are-coming-for-centos-stream-8-and-centos-linux-7/ Vít OpenPGP_signature Description: OpenPGP digital 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, report it: https://pagure.io/fedora-infrastructure/new_issue
[rpms/perl-Test2-Suite] PR #38: Disable optional dependencies in RHEL builds
mspacek merged a pull-request against the project: `perl-Test2-Suite` that you are following. Merged pull-request: `` Disable optional dependencies in RHEL builds `` https://src.fedoraproject.org/rpms/perl-Test2-Suite/pull-request/38 ___ 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, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: CentOS Stream, RHEL, and Fedora [was Re: What is Fedora?]
Am 03.07.23 um 02:00 schrieb Michael Catanzaro: On Sun, Jul 2 2023 at 06:27:48 PM -0400, Demi Marie Obenour wrote: What about stuff that is too urgent to wait on Red Hat QA? There have been vulnerabilities (such as CVE-2013-0156 and Log4Shell) for which unauthenticated, fully automated, remote code execution exploits have been found very, _very_ quickly. There may well be times when attackers can write and use an exploit faster than Red Hat QA can process an update. For these vulnerabilities waiting on Red Hat QA is not an option. Dire emergencies like these are extremely rare, but when they do occur, everybody needs to work together to get updates out to all users ASAP. That's true for every distro. Hypothetically speaking, if I were ever unfortunate enough to be responsible for an emergency scenario like that, I'd still want enough basic QA to at least ensure that the update won't eat your disk, but such decisions would surely be handled on a case-by-case basis. In a more normal situation, updates take a few days to prepare. I really don't think there's any problem with how CVEs are handled in CentOS Stream *except* for the problem I mentioned earlier about maintainers forgetting to push package updates to CentOS Stream by mistake. We need a better process to ensure human error doesn't result in CentOS Stream missing security or non-security updates. (This impacts RHEL too, because future minor releases are built from CentOS Stream, and we don't want fixes to disappear in future releases.) There is also demand between major release, some "features" are missing in EL9 for instance. -- Leon ___ 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, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Red Hat & Fedora -- largely stepping out of this ecosystem
Am 03.07.23 um 00:41 schrieb Michael Catanzaro: On Sun, Jul 2 2023 at 08:33:46 AM -0700, Carlos Rodriguez-Fernandez wrote: Hi Michael, We have been told repeatedly that "the source is there" in CentOS stream. The source for the next minor version is there. I can see the scenario that RH branches from CentOS stream to create a new minor release, and during QA, a bug is discovered and a patch is backported (or created) to fix it internally in your minor release branch. However, if that bug wants to be addressed also in the next minor release, it will need to appear in the CentOS stream at some point, whether via a patch or an entire source version bump. Right; nobody wants regressions. In this particular example, the fix is there via "an entire source version bump." If that's not the case, then RH is having some long living parallel git repo which will eventually create ABI compatibility issues, and it is also not what we have been told. So I'm really primarily here to talk about Fedora and CentOS Stream, because we often can't talk very much about RHEL. I'm going to point you to this page: https://access.redhat.com/support/policy/updates/errata/ And in particular this graphic: https://access.redhat.com/sites/default/files/images/337_rhel_9_life_cycle_updates_0423.png With the transitioning to "maintenance phase" next summer (EL8), I assume that for the next 5 years nothing gets pushed into c8s git anymore?? So, the mentioned mantra is only the half of the story ... -- Leon ___ 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, report it: https://pagure.io/fedora-infrastructure/new_issue
[rpms/perl-Test2-Suite] PR #38: Disable optional dependencies in RHEL builds
yselkowitz opened a new pull-request against the project: `perl-Test2-Suite` that you are following: `` Disable optional dependencies in RHEL builds `` To reply, visit the link below https://src.fedoraproject.org/rpms/perl-Test2-Suite/pull-request/38 ___ 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, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Orphaning packages (was LibreOffice packages)
Am 01.07.23 um 14:28 schrieb Peter Robinson: On Sat, Jul 1, 2023 at 12:50 PM Vitaly Zaitsev via devel wrote: On 01/07/2023 13:36, Chris Adams wrote: A lot of the corporate world has gone to the "cloud" don't have to worry about local backups of important documents and spreadsheets, they get sharing with minimal effort, they can access things from their mobile devices, etc. And voluntarily hand over all the corporate secrets to Google and Microsoft. Brilliant idea. This sort of comment is off topic, It definitely is not off-topic. It is the core of the problem esp. big US companies tend to ignore. May-be you guys are not aware of there are tendencies to legally prohibit such "cloud solutions" in many countries? Ralf ___ 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, report it: https://pagure.io/fedora-infrastructure/new_issue
Fedora rawhide compose report: 20230703.n.0 changes
OLD: Fedora-Rawhide-20230702.n.0 NEW: Fedora-Rawhide-20230703.n.0 = SUMMARY = Added images:3 Dropped images: 1 Added packages: 3 Dropped packages:0 Upgraded packages: 18 Downgraded packages: 0 Size of added packages: 105.86 KiB Size of dropped packages:0 B Size of upgraded packages: 179.90 MiB Size of downgraded packages: 0 B Size change of upgraded packages: 29.81 MiB Size change of downgraded packages: 0 B = ADDED IMAGES = Image: Silverblue dvd-ostree ppc64le Path: Silverblue/ppc64le/iso/Fedora-Silverblue-ostree-ppc64le-Rawhide-20230703.n.0.iso Image: Kinoite dvd-ostree ppc64le Path: Kinoite/ppc64le/iso/Fedora-Kinoite-ostree-ppc64le-Rawhide-20230703.n.0.iso Image: Sericea dvd-ostree x86_64 Path: Sericea/x86_64/iso/Fedora-Sericea-ostree-x86_64-Rawhide-20230703.n.0.iso = DROPPED IMAGES = Image: Container_Base docker s390x Path: Container/s390x/images/Fedora-Container-Base-Rawhide-20230702.n.0.s390x.tar.xz = ADDED PACKAGES = Package: python-perky-0.8.2-1.fc39 Summary: A simple, Pythonic file format RPMs:python3-perky Size:45.91 KiB Package: rust-cstr-0.2.11-1.fc39 Summary: Macro for building static CStr reference RPMs:rust-cstr+default-devel rust-cstr-devel Size:27.06 KiB Package: rust-matchit-0.7.0-1.fc39 Summary: Blazing fast URL router RPMs:rust-matchit+default-devel rust-matchit-devel Size:32.88 KiB = DROPPED PACKAGES = = UPGRADED PACKAGES = Package: arp-scan-1.10.0-1.fc39 Old package: arp-scan-1.9.7-8.fc38 Summary: Scanning and fingerprinting tool RPMs: arp-scan Size: 1.98 MiB Size change: 551.56 KiB Changelog: * Sun Jul 02 2023 Mosaab Alzoubi - 1.10.0-1 - Update to 1.10.0 - New upstream URL Package: c4core-0.1.11-12.fc39 Old package: c4core-0.1.11-11.fc39 Summary: C++ core utilities RPMs: c4core c4core-devel Size: 642.77 KiB Size change: 777 B Changelog: * Sun Jul 02 2023 Benjamin A. Beasley - 0.1.11-12 - Rebuild with fast_float 5.2.0 Package: containers-common-4:1-91.fc39 Old package: containers-common-4:1-90.fc39 Summary: Common configuration and documentation for containers RPMs: containers-common containers-common-extra Size: 107.52 KiB Size change: -804 B Changelog: * Sun Jul 02 2023 Daniel J Walsh - 4:1-91 - local build Package: ethtool-2:6.4-1.fc39 Old package: ethtool-2:6.3-1.fc39 Summary: Settings tool for Ethernet NICs RPMs: ethtool Size: 959.64 KiB Size change: 3.53 KiB Changelog: * Sun Jul 02 2023 Robert Scheck - 2:6.4-1 - Upgrade to 6.4 (#2219094) Package: fast_float-5.2.0-1.fc39 Old package: fast_float-5.0.0-2.fc39 Summary: Fast & exact implementation of C++ from_chars for float/double RPMs: fast_float-devel Size: 57.61 KiB Size change: 870 B Changelog: * Sun Jul 02 2023 Benjamin A. Beasley - 5.2.0-1 - Update to 5.2.0 (close RHBZ#2213937) Package: golang-github-fatih-color-1.15.0-1.fc39 Old package: golang-github-fatih-color-1.13.0-3.fc38 Summary: Color package for Go RPMs: golang-github-fatih-color-devel Size: 18.80 KiB Size change: 481 B Changelog: * Sat Jul 01 2023 Mark E. Fuller - 1.15.0-1 - v1.15.0 Package: openni-1.5.7.10-29.fc39 Old package: openni-1.5.7.10-26.fc36 Summary: Library for human-machine Natural Interaction RPMs: openni openni-devel openni-doc openni-examples openni-java Size: 4.67 MiB Size change: -1.29 MiB Changelog: * Fri Jul 22 2022 Fedora Release Engineering - 1.5.7.10-27 - Rebuilt for https://fedoraproject.org/wiki/Fedora_37_Mass_Rebuild * Thu Jan 19 2023 Fedora Release Engineering - 1.5.7.10-28 - Rebuilt for https://fedoraproject.org/wiki/Fedora_38_Mass_Rebuild * Sun Jul 02 2023 Till Hofmann - 1.5.7.10-29 - Do not build on i686 Package: percolator-3.06.01-1.fc39 Old package: percolator-3.05-11.fc38 Summary: Software for postprocessing of shotgun proteomics data RPMs: percolator percolator-data percolator-static Size: 18.89 MiB Size change: -6.02 MiB Changelog: * Thu Jun 15 2023 Antonio Trande - 3.06.01-1 - Release 3.06.01 - Elude support dropped Package: perl-Finance-Quote-1.5700-1.fc39 Old package: perl-Finance-Quote-1.5600-4.fc39 Summary: A Perl module that retrieves stock and mutual fund quotes RPMs: perl-Finance-Quote Size: 237.74 KiB Size change: 10.49 KiB Changelog: * Mon Jun 26 2023 Gwyn Ciesla - 1.5600-3 - Require perl-JSON-Parse * Mon Jun 26 2023 Gwyn Ciesla - 1.5600-4 - Reverse prior change * Sun Jul 02 2023 Paul Howarth - 1.5700-1 - Update to 1.57 - Correct set exchange in YahooJSON.pm (GH#306) - Added close, change and p_change to Tradegate, XETRA and Sinvestor; added optional parameter INST_ID to specify the institute id; fixed bug in Tradegate, XETRA and Sinve
Re: F39 Change Proposal: LibuserDeprecation (System Wide)
On Monday, 26 June 2023 at 03:16, James Ralston wrote: [...] > To remove a user from a group: > > lgroupmod -m someuser somegroup [...] > But groupmod has no ability to remove a user from a group. [...] > For shadow-utils 4.10 or later, usermod has a new -r option, so it is > possible to construct an equivalent: > > usermod -r -G somegroup someuser > > While this is a vast improvement, I would argue this option was added > to the wrong utility: groupmod should have the ability to remove a > user from a group, the same as lgroupmod. It’s also fairly new (RHEL9 > still has shadow-utils 4.9, for example). Agreed. Have you tried opening an issue upstream and/or in RHEL bugzilla? Regards, Dominik -- Fedora https://fedoraproject.org There should be a science of discontent. People need hard times and oppression to develop psychic muscles. -- from "Collected Sayings of Muad'Dib" by the Princess Irulan ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Non responsive maintainer check for @ilgrad
FYI: also forwarded to the correct gmail address (I'd used org instead of com) On Mon, Jul 03, 2023 11:43:05 +0100, Ankur Sinha wrote: > Dear all, > > Would anyone know how to contact @ilgrad (Ilya Gradina)? They are one of > the original members of the neuro-sig packager group, but we've not > heard from them in quite a while now. > > I've filed a non-responsive check bug here: > https://bugzilla.redhat.com/show_bug.cgi?id=2219364 > > Here are the bugs that they've not responded to: > https://bugzilla.redhat.com/buglist.cgi?bug_status=__open__=Fedora=product%2Ccomponent%2Cassigned_to%2Cstatus%2Csummary%2Clast_change_time%2Cseverity%2Cpriority=ilya.gradina%40gmail.com_to1=1=1=substring_id=13252967=status%2C%20priority%2C%20assigned_to%2C%20id%2C%20=Fedora_format=advanced > > > fedora_active_user.py output: > > $ python fedora_active_user.py --user ilgrad --email ilya.grad...@gmail.com > --nofas > Last action on koji: >Fri, 10 Mar 2023 tag_package_owners entry created by humaton [still active] > > Last package update on bodhi: >2019-10-22 22:36:05 on package flacon-5.5.1-1.fc31 > Last actions performed according to fedmsg: > - io.pagure.prod.pagure.issue.comment.added on 2022-08-18 23:28:59 > > Last email on mailing list: > On 2016-04-07T11:58:30Z ilya.grad...@gmail.com emailed as Ilia Gradina on > https://lists.fedoraproject.org/archives/api/list/devel@lists.fedoraproject.org/ > On 2016-04-07T11:14:57Z ilya.grad...@gmail.com emailed as Ilia Gradina on > https://lists.fedoraproject.org/archives/api/list/devel@lists.fedoraproject.org/ > On 2016-04-07T10:47:15Z ilya.grad...@gmail.com emailed as Ilia Gradina on > https://lists.fedoraproject.org/archives/api/list/devel@lists.fedoraproject.org/ > On 2016-04-05T19:55:29Z ilya.grad...@gmail.com emailed as Ilia Gradina on > https://lists.fedoraproject.org/archives/api/list/devel@lists.fedoraproject.org/ > On 2016-04-04T22:26:04Z ilya.grad...@gmail.com emailed as Ilia Gradina on > https://lists.fedoraproject.org/archives/api/list/devel@lists.fedoraproject.org/ > On 2016-04-04T19:30:01Z ilya.grad...@gmail.com emailed as Ilia Gradina on > https://lists.fedoraproject.org/archives/api/list/devel@lists.fedoraproject.org/ > On 2015-08-07T20:28:02Z ilya.grad...@gmail.com emailed as Ilia Gradina on > https://lists.fedoraproject.org/archives/api/list/devel@lists.fedoraproject.org/ > On 2015-07-20T15:16:18Z ilya.grad...@gmail.com emailed as Ilia Gradina on > https://lists.fedoraproject.org/archives/api/list/devel@lists.fedoraproject.org/ > > Bugzilla activity >6 bugs assigned, cc or on which ilya.grad...@gmail.com commented > Last comment on the most recent ticket on bugzilla: > > > -- > Thanks, > Regards, > Ankur Sinha "FranciscoD" (He / Him / His) | > https://fedoraproject.org/wiki/User:Ankursinha > Time zone: Europe/London -- 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, report it: https://pagure.io/fedora-infrastructure/new_issue
Non responsive maintainer check for @ilgrad
Dear all, Would anyone know how to contact @ilgrad (Ilya Gradina)? They are one of the original members of the neuro-sig packager group, but we've not heard from them in quite a while now. I've filed a non-responsive check bug here: https://bugzilla.redhat.com/show_bug.cgi?id=2219364 Here are the bugs that they've not responded to: https://bugzilla.redhat.com/buglist.cgi?bug_status=__open__=Fedora=product%2Ccomponent%2Cassigned_to%2Cstatus%2Csummary%2Clast_change_time%2Cseverity%2Cpriority=ilya.gradina%40gmail.com_to1=1=1=substring_id=13252967=status%2C%20priority%2C%20assigned_to%2C%20id%2C%20=Fedora_format=advanced fedora_active_user.py output: $ python fedora_active_user.py --user ilgrad --email ilya.grad...@gmail.com --nofas Last action on koji: Fri, 10 Mar 2023 tag_package_owners entry created by humaton [still active] Last package update on bodhi: 2019-10-22 22:36:05 on package flacon-5.5.1-1.fc31 Last actions performed according to fedmsg: - io.pagure.prod.pagure.issue.comment.added on 2022-08-18 23:28:59 Last email on mailing list: On 2016-04-07T11:58:30Z ilya.grad...@gmail.com emailed as Ilia Gradina on https://lists.fedoraproject.org/archives/api/list/devel@lists.fedoraproject.org/ On 2016-04-07T11:14:57Z ilya.grad...@gmail.com emailed as Ilia Gradina on https://lists.fedoraproject.org/archives/api/list/devel@lists.fedoraproject.org/ On 2016-04-07T10:47:15Z ilya.grad...@gmail.com emailed as Ilia Gradina on https://lists.fedoraproject.org/archives/api/list/devel@lists.fedoraproject.org/ On 2016-04-05T19:55:29Z ilya.grad...@gmail.com emailed as Ilia Gradina on https://lists.fedoraproject.org/archives/api/list/devel@lists.fedoraproject.org/ On 2016-04-04T22:26:04Z ilya.grad...@gmail.com emailed as Ilia Gradina on https://lists.fedoraproject.org/archives/api/list/devel@lists.fedoraproject.org/ On 2016-04-04T19:30:01Z ilya.grad...@gmail.com emailed as Ilia Gradina on https://lists.fedoraproject.org/archives/api/list/devel@lists.fedoraproject.org/ On 2015-08-07T20:28:02Z ilya.grad...@gmail.com emailed as Ilia Gradina on https://lists.fedoraproject.org/archives/api/list/devel@lists.fedoraproject.org/ On 2015-07-20T15:16:18Z ilya.grad...@gmail.com emailed as Ilia Gradina on https://lists.fedoraproject.org/archives/api/list/devel@lists.fedoraproject.org/ Bugzilla activity 6 bugs assigned, cc or on which ilya.grad...@gmail.com commented Last comment on the most recent ticket on bugzilla: -- 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, report it: https://pagure.io/fedora-infrastructure/new_issue
Next Open NeuroFedora Meeting: 1300 UTC on Monday, 03 July (today)
Hello everyone, Please join us at the next Open NeuroFedora team meeting on Monday 03 July at 1300UTC in #fedora-neuro on Matrix or IRC (Libera.chat). The meeting is a public meeting, and open for everyone to attend. You can join us over: Matrix: https://matrix.to/#/#neuro:fedoraproject.org IRC: https://webchat.libera.chat/?channels=#fedora-neuro You can use this link to see the local time for the meeting: https://www.timeanddate.com/worldclock/fixedtime.html?msg=Open+NeuroFedora+Meeting=20230703T13=%3A=1 or you can use this command in a terminal: $ date --date='TZ="UTC" 1300 Monday' The meeting will be chaired by @ankursinha. The agenda for the meeting is: - New introductions and roll call. - Tasks from last meeting: https://meetbot.fedoraproject.org/latest/neurofedora - Open Pagure tickets: https://pagure.io/neuro-sig/NeuroFedora/issues?status=Open=S%3A+Next+meeting - Package health check: https://packager-dashboard.fedoraproject.org/dashboard?groups=neuro-sig - Open package reviews check: https://bugzilla.redhat.com/show_bug.cgi?id=fedora-neuro - CompNeuro lab compose status check for F39: 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! The meeting announcement is also posted on the NeuroFedora blog here: https://neuroblog.fedoraproject.org/2023/07/03/next-open-neurofedora-meeting-03-July-1300-utc.html 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, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Orphaning packages (was LibreOffice packages)
On 7/3/23 09:23, Victor Toso wrote: On Sat, Jul 01, 2023 at 10:09:15PM +0200, Kalev Lember wrote: Victor (CC'd), do you want to pick up grilo and grilo-plugins? Sure, I'll keep maintaining both in Fedora. Excellent! Can you click on the "Take" button at https://src.fedoraproject.org/rpms/grilo and https://src.fedoraproject.org/rpms/grilo-plugins ? Bastien was the package owner before and now they are orphaned. -- Kalev ___ 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, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: LibreOffice packages
On 03/07/2023 01:28, Michael Catanzaro wrote: OK, host shared libraries and flatpaked libraries will be loaded at the same time, but I really doubt that's going to be at all significant. Include dozens of bundled libraries here too. Only runtimes can use shared memory. They do consume significant disk space if your disk is really small. ostree deduplication is pretty good, though (and OCI images are deduplicated too) Many Flatpaks from Flathub still use the old runtimes. Each runtime consumes approximately 1 GB of disk space. They need to start doing mass rebuilds with every new major release of the runtime. As a matter of strategy, packaging applications is fine, but nowadays it is *optional*. I don't think so. Our most popular applications are nowadays available from Flathub or other third-party sources, and users are going to install them regardless of whether we package them. Sorry, but I can't trust them since they allow uploading pre-built blobs and DEB repacks for popular and even for security-focused applications: - Firefox (uploaded as ostree blob without sources, has disabled ASLR and hardening); - OBS Studio (uploaded as ostree blob); - Element (DEB repack: https://github.com/flathub/im.riot.Riot/blob/master/im.riot.Riot.yaml#L69-L70); - Signal (DEB repack: https://github.com/flathub/org.signal.Signal/blob/master/org.signal.Signal.yaml#L65-L66); - Blender (static binary repack: https://github.com/flathub/org.blender.Blender/blob/master/org.blender.Blender.json#L150-L151); - VS Codium (DEB repack: https://github.com/flathub/com.vscodium.codium/blob/master/com.vscodium.codium.yaml#L98-L99); - many others: https://github.com/search?q=org%3Aflathub+.deb=code They need to forbid uploading pre-built blobs and repacks. All packages (except proprietary ones) should be built on their infrastructure. Flatpaks without sandbox holes are also dramatically more secure than Fedora RPMs, which is why I'm *really* interested in Flatpaks. Also, many Flathub's apps don't use Flatpak isolation at all: - https://github.com/search?q=org%3Aflathub+--filesystem%3Dhost=code - https://github.com/search?q=org%3Aflathub+--filesystem%3Dhome=code They need to restrict such holes. Snap already did this a few years ago (classic snaps are only allowed in exceptional cases). -- 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, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F39 Change Proposal: No custom Qt theming for Fedora Workstation (Self Contained)
Hi, po 26. 6. 2023 v 19:26 odesílatel Fabio Valentini napsal: > On Thu, Jun 22, 2023 at 6:21 PM Aoife Moloney wrote: > > > > (snip) > > > > > == Detailed Description == > > [https://github.com/FedoraQt/QGnomePlatform QGnomePlatform] project is > > a Qt Platform Theme plugin. It reads GNOME configuration, like fonts > > or icons and applies this configuration to Qt applications. It also > > provides implementation of Client-Side Window Decorations or native > > dialogs. This project partially overlaps with Qt's default GTK > > Platform Theme plugin, but there are some additions that are existing > > only in QGnomePlatform, like Client-Side Window Decorations. > > How will this affect Qt-on-GNOME applications? > I remember there being problems in the past because gnome-shell / > mutter apparently did not support SSD. > Will windows still have decorations in all combinations of > Qt+X11/Wayland-on-GNOME+X11/Wayland? > > Yes, I would like to ideally bring GNOME-like decorations that are currently provided by QGnomePlatform directly to Qt upstream. In case I don't make it in time, we will most likely end up at least shipping that part of QGnomePlatform that gives you exactly that. Regards, Jan Grulich ___ 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, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Distro feature macros: a replacement for many %if rhel/fedora/amzn
Dne 02. 07. 23 v 23:15 Smith, Stewart via devel napsal(a):
3. Per distro package features (in some include file somewhere? Probably not
the SPEC file itself… maybe an include to it?)
In the Avahi example above, the WITH_PYTHON is distro dependent for some
reason, but is local to the package, it isn’t something that’s distro-wide.
Perhaps a package-local distro file?
i.e. adding in something like the following in the package spec file
Source1234: %{_vendor}-macros.inc
%include %{_vendor}-macros.inc
and then having the include have the %if{amzn/rhel/fedora} <>= VERSION logic
there
Thoughts?
My real world example:
%if 0%{?fedora} || 0%{?rhel} >= 8
BuildRequires: (python%{python3_pkgversion}-tomli if python%{python3_pkgversion}
< 3.11)
%else
BuildRequires: python%{python3_pkgversion}-tomli
%endif
# grammar
%if 0%{?fedora} || 0%{?rhel} > 8
BuildRequires: python3dist(lark-parser)
%endif
This will require macro %distro_has_python-lark-parser (can I use dashes in macro?). In this case it is forwad only, but
if there would be;
%if 0%{?rhel} && 0%{?rhel} < 8
then I will have to negate this formul (and not make mistake) or I will need to add it to RHEL7 retroactively. Which
takes time and in the mean time the builds will be broken. Or you had to define the macro yourself on the top of the
spec file. And once you add it there, it will likely stay there forever.
And wene if you implement it your way, then you will have to keep for transition period of 10 years the oldfashioned
%if-rhel.
It seems to me that it would be cat'n'mouse game with no winner. It seems
better to me to use the rich dependencies like:
BuildRequires: (python%{python3_pkgversion}-tomli if python%{python3_pkgversion}
< 3.11)
I reckognize though that this cannot be applied in all situations.
--
Miroslav Suchy, RHCA
Red Hat, Manager, Packit and CPT, #brno, #fedora-buildsys
___
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, report it:
https://pagure.io/fedora-infrastructure/new_issue
Re: F39 Change Proposal: Anaconda WebUI for Fedora Workstation by default (System-Wide)
On 7/2/23 23:56, Demi Marie Obenour wrote: Remote installation is not a solution to the memory bloat. It only pushes the problem to whatever machine the browser runs on, and it has significant and negative security implications. A solution here would be ensuring that the web UI uses no more RAM than the GTK UI that preceded it. Hi Demi Marie, From what I can see by using `smem` the RSS/PSS for the Anaconda GTK installer in Fedora 38 is 62 MiB RSS and 22 MiB PSS. The Anaconda WebUI installer (Firefox) in Fedora 39 is 170 MiB RSS and 115 MiB PSS. Note that Hans mentioned removing/disabling sssd_kcm and gnome-calendar in his thread about minimizing memory usage which is a much larger dent in total memory usage in the scheme of things. Personally I'd also like to point out that I an using a 2 GiB memory single core VM to test these images to see if the live installer performs on the lower memory devices (yes, I think we can call 2 GiB low memory nowadays...). Regards, Simon ___ 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, report it: https://pagure.io/fedora-infrastructure/new_issue
