[Bug 2083360] perl-libwww-perl-6.65 is available
https://bugzilla.redhat.com/show_bug.cgi?id=2083360 --- Comment #7 from Fedora Update System --- FEDORA-2022-ceaddf5e41 has been pushed to the Fedora 34 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2022-ceaddf5e41` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2022-ceaddf5e41 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates. -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2083360 ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[Bug 2083360] perl-libwww-perl-6.65 is available
https://bugzilla.redhat.com/show_bug.cgi?id=2083360 --- Comment #6 from Fedora Update System --- FEDORA-2022-9acd402526 has been pushed to the Fedora 35 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2022-9acd402526` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2022-9acd402526 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates. -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2083360 ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[Bug 2083360] perl-libwww-perl-6.65 is available
https://bugzilla.redhat.com/show_bug.cgi?id=2083360 Fedora Update System changed: What|Removed |Added Status|MODIFIED|ON_QA --- Comment #5 from Fedora Update System --- FEDORA-2022-5558275b6c has been pushed to the Fedora 36 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2022-5558275b6c` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2022-5558275b6c See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates. -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2083360 ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[Bug 2076894] Add perl-List-AllUtils to EPEL8
https://bugzilla.redhat.com/show_bug.cgi?id=2076894 Fedora Update System changed: What|Removed |Added Resolution|--- |ERRATA Status|ON_QA |CLOSED Last Closed||2022-05-11 01:40:42 --- Comment #7 from Fedora Update System --- FEDORA-EPEL-2022-b98bbf4fb3 has been pushed to the Fedora EPEL 8 stable repository. If problem still persists, please make note of it in this bug report. -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2076894 ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F37 proposal: Build all JDKs in Fedora against in-tree libraries and with static stdc++lib (System-Wide Change proposal)
Ben Cotton wrote: > == Summary == > This is initial step to move JDKs to be more like other JDKs, to build > proper transferable images, and to lower certification burden of each > binary. Long storyshort, first step in: > https://fedoraproject.org/wiki/MoveFedoraJDKsToBecomePortableJDKs > > This first step will move, one by one, individual JDKs in F37 to be > built `--with-stdc++lib=static` and against in-tree (bundeld) > libraries: `--with-zlib="bundled" --with-freetype="bundled" > --with-libjpeg="bundled" --with-giflib="bundled" > --withlibpng="bundled" --with-lcms="bundled" > --with-harfbuzz="bundled" ` > > We already made a heavy testing of the behavior, and user should not > face negative experience. I'm not sure if this is > > == Owner == > * Name: [[User:jvanek| Jiri Vanek]] > * Email: jva...@redhat.com Let me join the train of -1 votes. I consider this a step entirely in the wrong direction. The JDK should be linked to system libraries wherever possible just like our other packages. Language interpreters/JITs are not exempt from that. In fact, I see very little value in providing JDK packages at all if they are built that way. > == Detailed Description == > Please see > https://fedoraproject.org/wiki/MoveFedoraJDKsToBecomePortableJDKs for > whole picture And this plan is entirely unacceptable. It is just plain not allowed in Fedora to ship prebuilt binary blobs (even if they are built by Fedora developers), packages are required to be built from source, and that requirement is there for good reasons. There have so far been no exceptions whatsoever to this rule (except temporarily for bootstrapping purposes, conditional on replacing the prebuilt binary with a rebuilt bootstrapped package before releasing it). I do not see any reason why Java should get an exception there. If passing the TCK is such an issue, then please just go back to shipping the packages under the name IcedTea or some other name not trademarked by Oracle. With Provides and Obsoletes in place, this will make very little difference in practice for the end user. Kevin Kofler ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F37 proposal: Build all JDKs in Fedora against in-tree libraries and with static stdc++lib (System-Wide Change proposal)
On Tue, May 10, 2022 at 11:51 PM Neal Gompa wrote: > > On Tue, May 10, 2022 at 5:20 PM Robert Relyea wrote: > > > > On 5/10/22 6:29 AM, Ben Cotton wrote: > > > https://fedoraproject.org/wiki/Changes/JdkInTreeLibsAndStdclibStatic > > > > > > This document represents a proposed Change. As part of the Changes > > > process, proposals are publicly announced in order to receive > > > community feedback. This proposal will only be implemented if approved > > > by the Fedora Engineering Steering Committee. > > > > > > == Summary == > > > This is initial step to move JDKs to be more like other JDKs, to build > > > proper transferable images, and to lower certification burden of each > > > binary. Long storyshort, first step in: > > > https://fedoraproject.org/wiki/MoveFedoraJDKsToBecomePortableJDKs > > > > > > This first step will move, one by one, individual JDKs in F37 to be > > > built `--with-stdc++lib=static` and against in-tree (bundeld) > > > libraries: `--with-zlib="bundled" --with-freetype="bundled" > > > --with-libjpeg="bundled" --with-giflib="bundled" > > > --withlibpng="bundled" --with-lcms="bundled" > > > --with-harfbuzz="bundled" ` > > > > > > We already made a heavy testing of the behavior, and user should not > > > face negative experience. I'm not sure if this is > > > > I'm very confused on why this reduces certification burden. In our > > crypto libraries this is exactly the kind of behavior we would *NOT* > > want packages to do because it increases our certification and support > > burden. > > > > I'm confused how this would not negatively impact the user experience, > because things like FreeType and HarfBuzz in Fedora have features and > configuration that are non-default that improve the font rendering > capabilities of applications that link to FreeType. I would rather > have our shared maintenance and evolution of font stuff be reused in > Java too... I agree, I don't think there's positives for the user experience here. And I don't understand what actual problem this change is trying to solve? Are people really installing OpenJDK RPM packages, taking the "/usr/bin/java" binary, and putting it onto some other system? Unless that's really the case (and I don't think that should even ever be supported for distro packages), I don't see a reason to change how we build OpenJDK. Also, I am particularly concerned with this statement from the linked follow-up change: "After this change is in air, we will certificate each binary only once, and redistribute." I cannot see how Fedora RPM packages for OpenJDK can redistributing pre-built binaries would ever be considered acceptable. Fabio ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: RHEL and CentOS specific Requires in spec file
On Tue, May 10, 2022 at 12:28 PM Vitaly Zaitsev via devel
wrote:
>
> On 10/05/2022 18:00, Ben Beasley wrote:
> > Could you please elaborate on why this form is better?
>
> For building on RHEL without EPEL being enabled.
>
> > At minimum, “%if 0%{?rhel} && 0%{?rhel} == 8” is exactly equivalent to
> > “%if 0%{?rhel} == 8”.
>
> Double checks are preferable, because "%if 0%{?rhel} < X" can easily
> break things.
>
> For example, on Fedora the %{?rhel} macro is not defined, so the
> condition 0%{?rhel} < 9 will be true because 0 is less than 9.
So what? If you're checking:
%if 0%{?rhel} == 8
There's no need for the double check. If you were looking for RHEL <
8, yeah, it could make sense
%if 0%{?rhel} && 0%{?rhel} < 8
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it:
https://pagure.io/fedora-infrastructure
Re: F37 proposal: Build all JDKs in Fedora against in-tree libraries and with static stdc++lib (System-Wide Change proposal)
On Tue, May 10, 2022 at 5:20 PM Robert Relyea wrote: > > On 5/10/22 6:29 AM, Ben Cotton wrote: > > https://fedoraproject.org/wiki/Changes/JdkInTreeLibsAndStdclibStatic > > > > This document represents a proposed Change. As part of the Changes > > process, proposals are publicly announced in order to receive > > community feedback. This proposal will only be implemented if approved > > by the Fedora Engineering Steering Committee. > > > > == Summary == > > This is initial step to move JDKs to be more like other JDKs, to build > > proper transferable images, and to lower certification burden of each > > binary. Long storyshort, first step in: > > https://fedoraproject.org/wiki/MoveFedoraJDKsToBecomePortableJDKs > > > > This first step will move, one by one, individual JDKs in F37 to be > > built `--with-stdc++lib=static` and against in-tree (bundeld) > > libraries: `--with-zlib="bundled" --with-freetype="bundled" > > --with-libjpeg="bundled" --with-giflib="bundled" > > --withlibpng="bundled" --with-lcms="bundled" > > --with-harfbuzz="bundled" ` > > > > We already made a heavy testing of the behavior, and user should not > > face negative experience. I'm not sure if this is > > I'm very confused on why this reduces certification burden. In our > crypto libraries this is exactly the kind of behavior we would *NOT* > want packages to do because it increases our certification and support > burden. > I'm confused how this would not negatively impact the user experience, because things like FreeType and HarfBuzz in Fedora have features and configuration that are non-default that improve the font rendering capabilities of applications that link to FreeType. I would rather have our shared maintenance and evolution of font stuff be reused in Java too... -- 真実はいつも一つ！/ Always, there's only one truth! ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F37 proposal: Build all JDKs in Fedora against in-tree libraries and with static stdc++lib (System-Wide Change proposal)
On 5/10/22 6:29 AM, Ben Cotton wrote: https://fedoraproject.org/wiki/Changes/JdkInTreeLibsAndStdclibStatic This document represents a proposed Change. As part of the Changes process, proposals are publicly announced in order to receive community feedback. This proposal will only be implemented if approved by the Fedora Engineering Steering Committee. == Summary == This is initial step to move JDKs to be more like other JDKs, to build proper transferable images, and to lower certification burden of each binary. Long storyshort, first step in: https://fedoraproject.org/wiki/MoveFedoraJDKsToBecomePortableJDKs This first step will move, one by one, individual JDKs in F37 to be built `--with-stdc++lib=static` and against in-tree (bundeld) libraries: `--with-zlib="bundled" --with-freetype="bundled" --with-libjpeg="bundled" --with-giflib="bundled" --withlibpng="bundled" --with-lcms="bundled" --with-harfbuzz="bundled" ` We already made a heavy testing of the behavior, and user should not face negative experience. I'm not sure if this is I'm very confused on why this reduces certification burden. In our crypto libraries this is exactly the kind of behavior we would *NOT* want packages to do because it increases our certification and support burden. bob == Owner == * Name: [[User:jvanek| Jiri Vanek]] * Email: jva...@redhat.com == Detailed Description == Please see https://fedoraproject.org/wiki/MoveFedoraJDKsToBecomePortableJDKs for whole picture Please see https://fedoraproject.org/wiki/MoveFedoraJDKsToBecomePortableJDKs#Move_JDKs_in_RPMs_to_become_portable for this particular step. I would rather keep the details in the main page then here. == Feedback == According to short investigations, there are already precedents, where certification is a reason to build once, certificate, and repack. According to developers, the non-portbale JDK is causing upredicted behavior different from other JDK vendors According to JDK packagers and testers, there is to much JDKs now, and the https://fedoraproject.org/wiki/MoveFedoraJDKsToBecomePortableJDKs#Move_Fedora_JDKs_to_become_single-built.2C_portable.2C_ordinary_JDKs.2C_while_keeping_comfortable.2C_usual_system_integration is the only way out == Benefit to Fedora == Please see https://fedoraproject.org/wiki/MoveFedoraJDKsToBecomePortableJDKs#Motivation for whole picture. This particular proposal's main benefit will be that Fedora's JDKs as packed in RPMs will again start to resemble upstream JDKs and other vendors build, and some platform specific issues disappear, while JDKs remain same in view of system integration and user experience == Scope == * Proposal owners: push improved version of https://src.fedoraproject.org/rpms/java-latest-openjdk/pull-request/98#request_diff to all JDKs - one by one from latest, over 17 to 11 and 8. Once settled down in F37 the backport to F36 is expected. * Other developers: really, nothing. If there will be unexpected impact to other developers, the https://fedoraproject.org/wiki/MoveFedoraJDKsToBecomePortableJDKs may need rework * Release engineering: N/A [https://pagure.io/releng/issues #Releng issue number] * Policies and guidelines: N/A (not needed for this Change) * Trademark approval: N/A (not needed for this Change) * Alignment with Objectives: == Upgrade/compatibility impact == The compatibility and upgrade path should remain completely smooth. == How To Test == Install system JDK (java-17-openjdk) and ru your favorite application or development. No regression should be noted. == User Experience == Because of in-tree libraries, minimal image or font rendering differences canbe spotted after very detailed investigations - https://fedoraproject.org/wiki/MoveFedoraJDKsToBecomePortableJDKs#Side_effects - still, no of th e https://fedoraproject.org/wiki/MoveFedoraJDKsToBecomePortableJDKs#Known_issues should be hit by this proposal. == Dependencies == No dependent packages should notice the change. == Contingency Plan == * Contingency mechanism: Revert the patches and rework https://fedoraproject.org/wiki/MoveFedoraJDKsToBecomePortableJDKs * Contingency deadline: before f37 release * Blocks release? Unless the java-stack will become completely borked then no. == Documentation == https://fedoraproject.org/wiki/MoveFedoraJDKsToBecomePortableJDKs ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[Bug 2083360] perl-libwww-perl-6.65 is available
https://bugzilla.redhat.com/show_bug.cgi?id=2083360 --- Comment #3 from Fedora Update System --- FEDORA-2022-9acd402526 has been submitted as an update to Fedora 35. https://bodhi.fedoraproject.org/updates/FEDORA-2022-9acd402526 -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2083360 ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[Bug 2083360] perl-libwww-perl-6.65 is available
https://bugzilla.redhat.com/show_bug.cgi?id=2083360 --- Comment #4 from Fedora Update System --- FEDORA-2022-ceaddf5e41 has been submitted as an update to Fedora 34. https://bodhi.fedoraproject.org/updates/FEDORA-2022-ceaddf5e41 -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2083360 ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: fedpkg sources - downloading unused source files: opt-in/opt-out
> Are you manually editing the "sources" file? No, why would I? A.FI. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: fedpkg sources - downloading unused source files: opt-in/opt-out
Neal Gompa kirjoitti 10.5.2022 klo 2.10: On Mon, May 9, 2022 at 7:00 PM Kevin Fenzi wrote: On Mon, May 09, 2022 at 01:21:53PM -0400, Neal Gompa wrote: On Mon, May 9, 2022 at 1:13 PM Kevin Fenzi wrote: On Wed, May 04, 2022 at 09:45:55PM +0300, Otto Urpelainen wrote: Ondrej Nosek kirjoitti 4.5.2022 klo 18.01: Hi all, A few months ago fedpkg introduced a change which avoids downloading source files (from dist-git) that are not used in the specfile and therefore downloading them would be wasting of resources and time. The original request was opened here [1] and implemented here [2]. The logic is part of the command "fedpkg sources" and currently can't be disabled manually. The logic parses specfile, but doesn't do a deep analysis, so it is doesn't always right. Recently we got a request for opt-in implementation of this. It means you should actively use some argument (ie. --skip-unused) to avoid downloading unused sources. The requestor points out that it broke the original functionality and it is not possible to add any extra arguments into the complicated release process (RHEL kernel). Author of the patch under discussion here. The premise was that "specfile sources" equal "sources file sources". Since there is a request like this, that is apparently not always the case. From that perspective, the patch is wrong and opt-in would be the correct way. I think opt-in will be useless and make the entire option pointless. Most maintainers won't be aware it exists. Why would someone want to opt-out of this? I need to when working on ffmpeg updates, since it clobbers my regenerated tarballs when I'm working normally. I had no idea about this until someone pointed it out to me. I have difficulties understanding this. If the problem is that downloads clobber locally modified files, how can "opting out of avoiding downloading" help? I would think "opting in to avoid downloading" or, equivalently, "opting out of downloading" would help. So you mean where you have modified the source, but the name is the same as in spec and it overwrites your local changes by downloading the lookaside one over it? Yes. Such problem is not related to the original post. The discussion here is if a file listed in the sources file, but *not* as Source in the specfile, should be downloaded. Fedpkg also has the feature that is avoids downloading sources that are locally available with matching hash. So, as already suggested in other replies, to avoid clobbering, after local changes, update the hash in the sources file. 'fedpkg new-sources --offline' will do that for you. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[Bug 2083360] perl-libwww-perl-6.65 is available
https://bugzilla.redhat.com/show_bug.cgi?id=2083360 Fedora Update System changed: What|Removed |Added Status|ASSIGNED|MODIFIED --- Comment #2 from Fedora Update System --- FEDORA-2022-5558275b6c has been submitted as an update to Fedora 36. https://bodhi.fedoraproject.org/updates/FEDORA-2022-5558275b6c -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2083360 ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F37 proposal: Build all JDKs in Fedora against in-tree libraries and with static stdc++lib (System-Wide Change proposal)
Hi, Ben Cotton writes: > According to short investigations, there are already precedents, where > certification is a reason to build once, certificate, and repack. This sounds fascinating. Can anyone share details about this? On the surface, building something once and packaging that up for all Fedora versions in an RPM sounds like it would violate all the guidelines under https://docs.fedoraproject.org/en-US/packaging-guidelines/what-can-be-packaged/#prebuilt-binaries-or-libraries Is there a sense of what defines "certification" in this context? What would it take for a random package $foo to meet this threshold and claim it needs to avoid rebuilding for certification? Thanks, Omair -- PGP Key: B157A9F0 (http://pgp.mit.edu/) Fingerprint = 9DB5 2F0B FD3E C239 E108 E7BD DF99 7AF8 B157 A9F0 ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F37 proposal: Build all JDKs in Fedora against in-tree libraries and with static stdc++lib (System-Wide Change proposal)
* Vitaly Zaitsev via devel: > On 10/05/2022 15:29, Ben Cotton wrote: >> This is initial step to move JDKs to be more like other JDKs, to build >> proper transferable images, and to lower certification burden of each >> binary. > > Strongly -1. Bundled versions are always outdated and may be even > vulnerable. And upstream only incorporates security fixes once per quarter, so the recent zlib bug (CVE-2018-25032) would have to be reintroduced, or a downstream-only patched for it applied. There was some confusion whether this bug only happened with Z_FIXED, but there's been another reproducer now. Given the lack of public discussion (following upstream policy), it's not clear whether this has been taken into account. Once the vulnerability scanners get better, we should really avoid copies of the demangler code because of its occasional vulnerabilities. They won't be exploitable in OpenJDK (at all), but scanners will eventually flag the presence of that code, still requiring security updates. If demangling can be disabled (so that mangled names show up in crash dumps), I think eliminating the remaining libstdc++ dependencies is a few week's work, mostly involving documenting interposable functions on the GCC side. Thanks, Florian ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[rpms/perl-libwww-perl] PR #34: 6.65 bump
mspacek merged a pull-request against the project: `perl-libwww-perl` that you are following. Merged pull-request: `` 6.65 bump `` https://src.fedoraproject.org/rpms/perl-libwww-perl/pull-request/34 ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[rpms/perl-libwww-perl] PR #34: 6.65 bump
mspacek opened a new pull-request against the project: `perl-libwww-perl` that you are following: `` 6.65 bump `` To reply, visit the link below https://src.fedoraproject.org/rpms/perl-libwww-perl/pull-request/34 ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[rpms/perl-libwww-perl] PR #33: 6.65 bump
mspacek merged a pull-request against the project: `perl-libwww-perl` that you are following. Merged pull-request: `` 6.65 bump `` https://src.fedoraproject.org/rpms/perl-libwww-perl/pull-request/33 ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Strange messages in Bodhi (ejected from push?)
Thank you very much Mattia! On 10 May 2022, at 11:36, Mattia Verga via devel wrote: > Il 10/05/22 18:30, Mattia Verga ha scritto: >> Il 09/05/22 22:28, Mikel Olasagasti ha scritto: >>> Hi Ron, >>> >>> Hau idatzi du Ron Olson (tachokni...@gmail.com) erabiltzaileak (2022 >>> mai. 9, al. (22:15)): Hi all- I got several strange messages on my update here: https://bodhi.fedoraproject.org/updates/FEDORA-2022-bf60d68bdc The (multiple) messages suggest the update was ejected, but I tested an install on a fresh image of 35 and 5.6.1 installed fine. Did I do something wrong? >>> Can you try with: >>> >>> koji tag-build f36-updates-candidate swift-lang-5.6-1.fc36 >>> >>> This has been reported in the past and there was a bug report that is >>> marked as fixed: >>> >>> https://pagure.io/releng/issue/10590 >>> >>> Kind regards, >>> Mikel >> This won't solve the problem here, because the update is in testing >> going stable, not pending going testing. >> >> To solve this kind of problems the update needs to be unpushed and then >> re-pushed to testing. I did it for you. Now it should go to stable in a >> couple of days. >> >> Mattia >> > Sorry, I now see that update has been obsoleted by > swift-lang-5.6.1-2.fc36 which is already pushed to stable. > > This is a known race condition that may happen during release freeze and > I've submitted a PR to fix this in Bodhi. For this particular update, > I've simply unpushed it again. > > Mattia > > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > Do not reply to spam on the list, report it: > https://pagure.io/fedora-infrastructure ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Strange messages in Bodhi (ejected from push?)
Il 10/05/22 18:30, Mattia Verga ha scritto: > Il 09/05/22 22:28, Mikel Olasagasti ha scritto: >> Hi Ron, >> >> Hau idatzi du Ron Olson (tachokni...@gmail.com) erabiltzaileak (2022 >> mai. 9, al. (22:15)): >>> Hi all- >>> >>> I got several strange messages on my update here: >>> >>> https://bodhi.fedoraproject.org/updates/FEDORA-2022-bf60d68bdc >>> >>> The (multiple) messages suggest the update was ejected, but I tested an >>> install on a fresh image of 35 and 5.6.1 installed fine. Did I do something >>> wrong? >> Can you try with: >> >> koji tag-build f36-updates-candidate swift-lang-5.6-1.fc36 >> >> This has been reported in the past and there was a bug report that is >> marked as fixed: >> >> https://pagure.io/releng/issue/10590 >> >> Kind regards, >> Mikel > This won't solve the problem here, because the update is in testing > going stable, not pending going testing. > > To solve this kind of problems the update needs to be unpushed and then > re-pushed to testing. I did it for you. Now it should go to stable in a > couple of days. > > Mattia > Sorry, I now see that update has been obsoleted by swift-lang-5.6.1-2.fc36 which is already pushed to stable. This is a known race condition that may happen during release freeze and I've submitted a PR to fix this in Bodhi. For this particular update, I've simply unpushed it again. Mattia ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Strange messages in Bodhi (ejected from push?)
Il 09/05/22 22:28, Mikel Olasagasti ha scritto: > Hi Ron, > > Hau idatzi du Ron Olson (tachokni...@gmail.com) erabiltzaileak (2022 > mai. 9, al. (22:15)): >> Hi all- >> >> I got several strange messages on my update here: >> >> https://bodhi.fedoraproject.org/updates/FEDORA-2022-bf60d68bdc >> >> The (multiple) messages suggest the update was ejected, but I tested an >> install on a fresh image of 35 and 5.6.1 installed fine. Did I do something >> wrong? > Can you try with: > > koji tag-build f36-updates-candidate swift-lang-5.6-1.fc36 > > This has been reported in the past and there was a bug report that is > marked as fixed: > > https://pagure.io/releng/issue/10590 > > Kind regards, > Mikel This won't solve the problem here, because the update is in testing going stable, not pending going testing. To solve this kind of problems the update needs to be unpushed and then re-pushed to testing. I did it for you. Now it should go to stable in a couple of days. Mattia ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: RHEL and CentOS specific Requires in spec file
On 10/05/2022 18:00, Ben Beasley wrote:
Could you please elaborate on why this form is better?
For building on RHEL without EPEL being enabled.
At minimum, “%if 0%{?rhel} && 0%{?rhel} == 8” is exactly equivalent to
“%if 0%{?rhel} == 8”.
Double checks are preferable, because "%if 0%{?rhel} < X" can easily
break things.
For example, on Fedora the %{?rhel} macro is not defined, so the
condition 0%{?rhel} < 9 will be true because 0 is less than 9.
--
Sincerely,
Vitaly Zaitsev (vit...@easycoding.org)
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it:
https://pagure.io/fedora-infrastructure
Re: F37 Change: Deprecate Legacy BIOS (System-Wide Change proposal)
On Mon, May 02, 2022 at 11:53:12PM -0400, Chris Murphy wrote: > On Mon, May 2, 2022 at 5:29 PM Jeremy Linton wrote: > > And of > > course it also requires disabling swap on zram (which was nonsense on > > the machine anyway, given the disks are faster than it can > > compress/decompress pages). > > I don't think it requires disabling swap on zram per se - from what > I've been told the hibernation code knows it can't use it for the > hibernation image, not least of which is it's not big enough for a > contiguous write of the image. The issue might be that so much needs > to be swapped out, to free ~50% RAM, which is used to create the > hibernation image in memory before it's written out. We need a clear > reproducer with logs and get it posted to the Linux memory management > mailing list to see what's going wrong. Since zram is threaded, it's > pretty unlikely drive writes are faster than memory writes with > compression. LZO+RLE is computationally pretty cheap. In general, hibernation is expected to work if a zram device is present. Systemd will automatically filter out zram devices from the candidate list. If it didn't work for you, it's probably somehting like Chris wrote, not enough swap for the amount of memory used. > > So, on a recent fedora machine, it took me more than 4 hours to get a > > hibernation file on btrfs plus LUKS encrypted partition working. The > > documentation for that wasn't to be found anywhere on the fedora/RH > > sites and required compiling a tool to do the block offset calculations > > and manually adding the resume_offset options to grub/etc. systemd has code to calculate the offset. It is used to try to figure out which of the swap partitions matches swap_offset= configured on the kernel command line. I guess it'd be helpful if we exposed this functionality somewhere. Maybe something like 'systemd-analyze suggest-hibernation-config-that-works' ;) Zbyszek ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[rpms/perl-libwww-perl] PR #33: 6.65 bump
mspacek opened a new pull-request against the project: `perl-libwww-perl` that you are following: `` 6.65 bump `` To reply, visit the link below https://src.fedoraproject.org/rpms/perl-libwww-perl/pull-request/33 ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Uninitialized variables and F37
Hello, On Monday, May 9, 2022 5:10:07 AM EDT Daniel P. Berrangé wrote: > On Fri, Jan 21, 2022 at 01:04:51PM -0500, Steve Grubb wrote: > > This is a continuation of the discussion from F36 Change: GNU Toolchain > > Update. > > snip. > > > He talks about -ftrivial-auto-var-init=zero being used for production > > builds and -ftrivial-auto-var-init= being used for debug > > builds. The use is not just the kernel. Consider a server that returns > > data across the network to a client. It could possibly leak crypto keys > > or passwords if the returned data structure has uninitialized memory. > > snip > > > I think this would be an important step forward to turn this on across > > all compilations. We could wipe out an entire class of bugs in one fell > > swoop. > > Fast-forward a few months and I see GCC 12.1 is released now with > -ftrivial-auto-var-init option support [2]. > > Are you going to take this idea forward and make a formal change proposal > for Fedora to set -ftrivial-auto-var-init=zero by default in its default > RPM build flags ? I would like to see this happen. But I have not yet tested anything with the flag added. I was under the impression from someone on the gcc team that they wanted to look into this after 12.1 and all of the fallout from that is settled. Maybe now is the time to start looking into it? I'd need someone from the gcc team to partner on this as I don't have permissions to actually do this. Best Regards, -Steve > [1] https://gcc.gnu.org/gcc-12/changes.html > [2] > https://gcc.gnu.org/onlinedocs/gcc-12.1.0/gcc/Optimize-Options.html#index-> > ftrivial-auto-var-init ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[rpms/perl-libwww-perl] PR #32: 6.65 bump
mspacek merged a pull-request against the project: `perl-libwww-perl` that you are following. Merged pull-request: `` 6.65 bump `` https://src.fedoraproject.org/rpms/perl-libwww-perl/pull-request/32 ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: RHEL and CentOS specific Requires in spec file
On Tue, May 10, 2022 at 11:42 AM Ron Olson wrote: > > No, it’s not available in RHEL nor in CentOS 8 and Stream 8; if I used the > rhel tag would that include those? > Either is fine. %rhel and %el8 are both defined for all EL8 platforms. Using %rhel is mostly useful if you want to handle multiple versions of RHEL. -- 真実はいつも一つ！/ Always, there's only one truth! ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: RHEL and CentOS specific Requires in spec file
Could you please elaborate on why this form is better? I would have
thought they were more or less equivalent, but it’s very possible that
there is some non-obvious difference I don’t know about.
At minimum, “%if 0%{?rhel} && 0%{?rhel} == 8” is exactly equivalent to
“%if 0%{?rhel} == 8”.
– Ben
On 5/10/22 11:53, Vitaly Zaitsev via devel wrote:
On 10/05/2022 17:01, Ron Olson wrote:
|%if 0%{?el8}|
Better fix:
%if 0%{?rhel} && 0%{?rhel} == 8
...
%else
...
%endif
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it:
https://pagure.io/fedora-infrastructure
[EPEL-devel] [Fedocal] Reminder meeting : EPEL Steering Committee
Dear all, You are kindly invited to the meeting: EPEL Steering Committee on 2022-05-11 from 16:00:00 to 17:00:00 US/Eastern At fedora-meet...@irc.libera.chat The meeting will be about: This is the weekly EPEL Steering Committee Meeting. A general agenda is the following: #meetingname EPEL #topic Intros #topic Old Business #topic EPEL-7 #topic EPEL-8 #topic EPEL-9 #topic Openfloor #endmeeting Source: https://calendar.fedoraproject.org//meeting/9854/ ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: RHEL and CentOS specific Requires in spec file
On 10/05/2022 17:01, Ron Olson wrote:
|%if 0%{?el8}|
Better fix:
%if 0%{?rhel} && 0%{?rhel} == 8
...
%else
...
%endif
--
Sincerely,
Vitaly Zaitsev (vit...@easycoding.org)
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it:
https://pagure.io/fedora-infrastructure
[rpms/perl-libwww-perl] PR #32: 6.65 bump
mspacek opened a new pull-request against the project: `perl-libwww-perl` that you are following: `` 6.65 bump `` To reply, visit the link below https://src.fedoraproject.org/rpms/perl-libwww-perl/pull-request/32 ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Canceled: Tuesday's FESCo Meeting (2022-05-10)
There is no agenda for the FESCo meeting today, so I decided to cancel it. If we have a volunteer chair for next week, that would be nice, as I am not sure I will be able to attend. = Discussed and Voted in the Ticket = Change proposal: Drop i686 builds of jdk8,11,17 and latest (18) rpms from f37 onward https://pagure.io/fesco/issue/2772 APPROVED (+3, 0, -0) -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: RHEL and CentOS specific Requires in spec file
No, it’s not available in RHEL nor in CentOS 8 and Stream 8; if I used the rhel
tag would that include those?
On 10 May 2022, at 10:24, Neal Gompa wrote:
> On Tue, May 10, 2022 at 11:01 AM Ron Olson wrote:
>>
>> Hey all-
>>
>> I got a bug report about installing Swift on RHEL 8 where nothing provides
>> binutils-gold. I think this will fix it:
>>
>> %if 0%{?el8}
>> Requires: binutils
>> %else
>> Requires: binutils-gold
>> %endif
>>
>> But was hoping for some confirmation about this being the right way to
>> handle this situation.
>>
>
> It works, but is binutils-gold available in RHEL at all? If not, you
> probably want to swap to 0%{?rhel} instead.
>
>
>
> --
> 真実はいつも一つ！/ Always, there's only one truth!
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> Do not reply to spam on the list, report it:
> https://pagure.io/fedora-infrastructure
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it:
https://pagure.io/fedora-infrastructure
Re: RHEL and CentOS specific Requires in spec file
On Tue, May 10, 2022 at 11:01 AM Ron Olson wrote:
>
> Hey all-
>
> I got a bug report about installing Swift on RHEL 8 where nothing provides
> binutils-gold. I think this will fix it:
>
> %if 0%{?el8}
> Requires: binutils
> %else
> Requires: binutils-gold
> %endif
>
> But was hoping for some confirmation about this being the right way to handle
> this situation.
>
It works, but is binutils-gold available in RHEL at all? If not, you
probably want to swap to 0%{?rhel} instead.
--
真実はいつも一つ！/ Always, there's only one truth!
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it:
https://pagure.io/fedora-infrastructure
RHEL and CentOS specific Requires in spec file
Hey all-
I got a bug report about installing Swift on RHEL 8 where nothing
provides binutils-gold. I _think_ this will fix it:
```
%if 0%{?el8}
Requires: binutils
%else
Requires: binutils-gold
%endif
```
But was hoping for some confirmation about this being the right way to
handle this situation.
Thanks!
Ron___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it:
https://pagure.io/fedora-infrastructure
[rpms/perl-libwww-perl] PR #31: 6.65 bump
mspacek merged a pull-request against the project: `perl-libwww-perl` that you are following. Merged pull-request: `` 6.65 bump `` https://src.fedoraproject.org/rpms/perl-libwww-perl/pull-request/31 ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: upstream systemd discussion about MACAddressPolicy for bonds and bridges
On 10/05/2022 14:57, Dusty Mabe wrote: On 5/10/22 02:05, Tom Hughes via devel wrote: On 10/05/2022 03:12, Dusty Mabe wrote: Just wanted to point interested people in the direction of an upstream discussion about how (by default) the MAC address should get set for bond and bridge devices. https://lists.freedesktop.org/archives/systemd-devel/2022-May/047893.html A few of us were originally going to propose a change to Fedora to change the current behavior back, but it was suggested we take the discussion upstream to hash out the merits there. All I can say is, no, just leave it alone. Having fixed all my machines two years ago when it stopped generating persistent addresses I have just spent this weekend doing it again now that F36 has gone back to them. I'm not aware of any change in behavior in F36, but maybe I missed something. F36 has gone back to using a persistent MAC calculated from the machine ID and bridge name. I'm not sure what F35 was doing but believe me when I say that all my bridges changed MAC on upgrade and they've now gone back to the address they had until late 2019 or early 2020. I don't care what address my bridges have, so long as it is fixed so that DHCP can allocate addresses against it, but I do prefer not to have to fix all my DHCP and DNS every time the policy flip flops and upgrades break my networks! With the current policy you'll get a new MAC every time you re-install a machine. Is that what you want? It doesn't bother me too much as I expect to be reconfiguring things then. The upstream proposal is to make it based on the actual MAC of the NIC(s) again. The problem is which NIC exactly? As I understand it's whatever interface gets added first so may be racy. From that point of view a persistent address seems better. 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 on the list, report it: https://pagure.io/fedora-infrastructure
Re: fedpkg sources - downloading unused source files: opt-in/opt-out
A ter, 10-05-2022 às 10:22 +0200, Vít Ondruch escreveu: > Ok, now I see commits such as: > > https://src.fedoraproject.org/rpms/ffmpeg/c/70ecae14df6b89cbd269778fc6808eb6e51e141e?branch=rawhide > > which is awful that we need something like this. But @Neal, wouldn't > it > be better if your `ffmpeg_gen_free_tarball.sh` simply updated the > hashes > in `sources` file? The `fedpkg new-sources --offline` could help with > that I guess. +1 @Neal I think you can solve your problem with: fedpkg new-sources --offline ffmpeg-free-5.0.1.tar.xz --offline is yet another feature, but what is asking here is the opposite, is the old behavior, `fedpkg srpm` download all sources in sources files, even if they aren't use anymore, which I don't see in what can be useful . Best regards > Vít > > > Dne 10. 05. 22 v 10:10 Vít Ondruch napsal(a): > > I somehow don't understand why there should be anything like > > "unused > > source files". Why is something like this even possible? It seems > > strange that this was not questioned originally and it seems still > > strange nobody questions this in this thread. > > > > > > Vít > > > > > > Dne 04. 05. 22 v 17:01 Ondrej Nosek napsal(a): > > > Hi all, > > > > > > A few months ago fedpkg introduced a change which avoids > > > downloading > > > source files (from dist-git) that are not used in the specfile > > > and > > > therefore downloading them would be wasting of resources and > > > time. > > > The original request was opened here [1] and implemented here > > > [2]. > > > The logic is part of the command "fedpkg sources" and currently > > > can't > > > be disabled manually. The logic parses specfile, but doesn't do a > > > deep analysis, so it is doesn't always right. > > > > > > Recently we got a request for opt-in implementation of this. It > > > means > > > you should actively use some argument (ie. --skip-unused) to > > > avoid > > > downloading unused sources. The requestor points out that it > > > broke > > > the original functionality and it is not possible to add any > > > extra > > > arguments into the complicated release process (RHEL kernel). > > > > > > On the other hand, opt-out (--download-unused) has (I think) a > > > significantly higher impact on saving resources (time and network > > > capacity). Of course, it doesn't have to be implemented as an > > > extra > > > argument, there might be a different (maybe not so clean) > > > solution > > > for such projects. > > > > > > What do you think about it? > > > > > > I added into a loop (bcc) names who already were involved in this > > > in > > > a past (on the Fedora devel mailing list) > > > > > > Thanks, Ondrej > > > > > > [1] https://pagure.io/rpkg/issue/559 > > > [2] https://pagure.io/rpkg/pull-request/564 > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: > https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > Do not reply to spam on the list, report it: > https://pagure.io/fedora-infrastructure -- Sérgio M. B. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: upstream systemd discussion about MACAddressPolicy for bonds and bridges
On 5/10/22 02:05, Tom Hughes via devel wrote: > On 10/05/2022 03:12, Dusty Mabe wrote: > >> Just wanted to point interested people in the direction of an upstream >> discussion about how (by default) the MAC address should get set for >> bond and bridge devices. >> >> https://lists.freedesktop.org/archives/systemd-devel/2022-May/047893.html >> >> A few of us were originally going to propose a change to Fedora to change >> the current behavior back, but it was suggested we take the discussion >> upstream to hash out the merits there. > > All I can say is, no, just leave it alone. > > Having fixed all my machines two years ago when it stopped generating > persistent addresses I have just spent this weekend doing it again now > that F36 has gone back to them. I'm not aware of any change in behavior in F36, but maybe I missed something. > > I don't care what address my bridges have, so long as it is fixed so > that DHCP can allocate addresses against it, but I do prefer not to > have to fix all my DHCP and DNS every time the policy flip flops and > upgrades break my networks! > With the current policy you'll get a new MAC every time you re-install a machine. Is that what you want? The upstream proposal is to make it based on the actual MAC of the NIC(s) again. Dusty ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F37 proposal: Build all JDKs in Fedora against in-tree libraries and with static stdc++lib (System-Wide Change proposal)
On 10/05/2022 15:29, Ben Cotton wrote: This is initial step to move JDKs to be more like other JDKs, to build proper transferable images, and to lower certification burden of each binary. Strongly -1. Bundled versions are always outdated and may be even vulnerable. --with-zlib="bundled" --with-freetype="bundled" --with-libjpeg="bundled" --with-giflib="bundled" --withlibpng="bundled" --with-lcms="bundled" --with-harfbuzz="bundled" ` Using bundled freetype, fontconfig and harfbuzz will result in ugly fonts (without system configuration support, including subpixel rendering, hinting, etc). Applications linking against libraries SHOULD link against shared libraries not static versions. https://docs.fedoraproject.org/en-US/packaging-guidelines/#packaging-static-libraries -- Sincerely, Vitaly Zaitsev (vit...@easycoding.org) ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F37 proposal: Build all JDKs in Fedora against in-tree libraries and with static stdc++lib (System-Wide Change proposal)
On 5/10/22 09:29, Ben Cotton wrote: We already made a heavy testing of the behavior, and user should not face negative experience. I'm not sure if this is Might be a copy-paste error there, the last sentence is incomplete. -- Kevin P. Fleming He/Him/His Principal Program Manager, RHEL Red Hat US/Eastern Time Zone ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
F37 proposal: Build all JDKs in Fedora against in-tree libraries and with static stdc++lib (System-Wide Change proposal)
https://fedoraproject.org/wiki/Changes/JdkInTreeLibsAndStdclibStatic This document represents a proposed Change. As part of the Changes process, proposals are publicly announced in order to receive community feedback. This proposal will only be implemented if approved by the Fedora Engineering Steering Committee. == Summary == This is initial step to move JDKs to be more like other JDKs, to build proper transferable images, and to lower certification burden of each binary. Long storyshort, first step in: https://fedoraproject.org/wiki/MoveFedoraJDKsToBecomePortableJDKs This first step will move, one by one, individual JDKs in F37 to be built `--with-stdc++lib=static` and against in-tree (bundeld) libraries: `--with-zlib="bundled" --with-freetype="bundled" --with-libjpeg="bundled" --with-giflib="bundled" --withlibpng="bundled" --with-lcms="bundled" --with-harfbuzz="bundled" ` We already made a heavy testing of the behavior, and user should not face negative experience. I'm not sure if this is == Owner == * Name: [[User:jvanek| Jiri Vanek]] * Email: jva...@redhat.com == Detailed Description == Please see https://fedoraproject.org/wiki/MoveFedoraJDKsToBecomePortableJDKs for whole picture Please see https://fedoraproject.org/wiki/MoveFedoraJDKsToBecomePortableJDKs#Move_JDKs_in_RPMs_to_become_portable for this particular step. I would rather keep the details in the main page then here. == Feedback == According to short investigations, there are already precedents, where certification is a reason to build once, certificate, and repack. According to developers, the non-portbale JDK is causing upredicted behavior different from other JDK vendors According to JDK packagers and testers, there is to much JDKs now, and the https://fedoraproject.org/wiki/MoveFedoraJDKsToBecomePortableJDKs#Move_Fedora_JDKs_to_become_single-built.2C_portable.2C_ordinary_JDKs.2C_while_keeping_comfortable.2C_usual_system_integration is the only way out == Benefit to Fedora == Please see https://fedoraproject.org/wiki/MoveFedoraJDKsToBecomePortableJDKs#Motivation for whole picture. This particular proposal's main benefit will be that Fedora's JDKs as packed in RPMs will again start to resemble upstream JDKs and other vendors build, and some platform specific issues disappear, while JDKs remain same in view of system integration and user experience == Scope == * Proposal owners: push improved version of https://src.fedoraproject.org/rpms/java-latest-openjdk/pull-request/98#request_diff to all JDKs - one by one from latest, over 17 to 11 and 8. Once settled down in F37 the backport to F36 is expected. * Other developers: really, nothing. If there will be unexpected impact to other developers, the https://fedoraproject.org/wiki/MoveFedoraJDKsToBecomePortableJDKs may need rework * Release engineering: N/A [https://pagure.io/releng/issues #Releng issue number] * Policies and guidelines: N/A (not needed for this Change) * Trademark approval: N/A (not needed for this Change) * Alignment with Objectives: == Upgrade/compatibility impact == The compatibility and upgrade path should remain completely smooth. == How To Test == Install system JDK (java-17-openjdk) and ru your favorite application or development. No regression should be noted. == User Experience == Because of in-tree libraries, minimal image or font rendering differences canbe spotted after very detailed investigations - https://fedoraproject.org/wiki/MoveFedoraJDKsToBecomePortableJDKs#Side_effects - still, no of th e https://fedoraproject.org/wiki/MoveFedoraJDKsToBecomePortableJDKs#Known_issues should be hit by this proposal. == Dependencies == No dependent packages should notice the change. == Contingency Plan == * Contingency mechanism: Revert the patches and rework https://fedoraproject.org/wiki/MoveFedoraJDKsToBecomePortableJDKs * Contingency deadline: before f37 release * Blocks release? Unless the java-stack will become completely borked then no. == Documentation == https://fedoraproject.org/wiki/MoveFedoraJDKsToBecomePortableJDKs -- Ben Cotton He / Him / His Fedora Program Manager Red Hat TZ=America/Indiana/Indianapolis ___ devel-announce mailing list -- devel-announce@lists.fedoraproject.org To unsubscribe send an email to devel-announce-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel-announce@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
F37 proposal: Build all JDKs in Fedora against in-tree libraries and with static stdc++lib (System-Wide Change proposal)
https://fedoraproject.org/wiki/Changes/JdkInTreeLibsAndStdclibStatic This document represents a proposed Change. As part of the Changes process, proposals are publicly announced in order to receive community feedback. This proposal will only be implemented if approved by the Fedora Engineering Steering Committee. == Summary == This is initial step to move JDKs to be more like other JDKs, to build proper transferable images, and to lower certification burden of each binary. Long storyshort, first step in: https://fedoraproject.org/wiki/MoveFedoraJDKsToBecomePortableJDKs This first step will move, one by one, individual JDKs in F37 to be built `--with-stdc++lib=static` and against in-tree (bundeld) libraries: `--with-zlib="bundled" --with-freetype="bundled" --with-libjpeg="bundled" --with-giflib="bundled" --withlibpng="bundled" --with-lcms="bundled" --with-harfbuzz="bundled" ` We already made a heavy testing of the behavior, and user should not face negative experience. I'm not sure if this is == Owner == * Name: [[User:jvanek| Jiri Vanek]] * Email: jva...@redhat.com == Detailed Description == Please see https://fedoraproject.org/wiki/MoveFedoraJDKsToBecomePortableJDKs for whole picture Please see https://fedoraproject.org/wiki/MoveFedoraJDKsToBecomePortableJDKs#Move_JDKs_in_RPMs_to_become_portable for this particular step. I would rather keep the details in the main page then here. == Feedback == According to short investigations, there are already precedents, where certification is a reason to build once, certificate, and repack. According to developers, the non-portbale JDK is causing upredicted behavior different from other JDK vendors According to JDK packagers and testers, there is to much JDKs now, and the https://fedoraproject.org/wiki/MoveFedoraJDKsToBecomePortableJDKs#Move_Fedora_JDKs_to_become_single-built.2C_portable.2C_ordinary_JDKs.2C_while_keeping_comfortable.2C_usual_system_integration is the only way out == Benefit to Fedora == Please see https://fedoraproject.org/wiki/MoveFedoraJDKsToBecomePortableJDKs#Motivation for whole picture. This particular proposal's main benefit will be that Fedora's JDKs as packed in RPMs will again start to resemble upstream JDKs and other vendors build, and some platform specific issues disappear, while JDKs remain same in view of system integration and user experience == Scope == * Proposal owners: push improved version of https://src.fedoraproject.org/rpms/java-latest-openjdk/pull-request/98#request_diff to all JDKs - one by one from latest, over 17 to 11 and 8. Once settled down in F37 the backport to F36 is expected. * Other developers: really, nothing. If there will be unexpected impact to other developers, the https://fedoraproject.org/wiki/MoveFedoraJDKsToBecomePortableJDKs may need rework * Release engineering: N/A [https://pagure.io/releng/issues #Releng issue number] * Policies and guidelines: N/A (not needed for this Change) * Trademark approval: N/A (not needed for this Change) * Alignment with Objectives: == Upgrade/compatibility impact == The compatibility and upgrade path should remain completely smooth. == How To Test == Install system JDK (java-17-openjdk) and ru your favorite application or development. No regression should be noted. == User Experience == Because of in-tree libraries, minimal image or font rendering differences canbe spotted after very detailed investigations - https://fedoraproject.org/wiki/MoveFedoraJDKsToBecomePortableJDKs#Side_effects - still, no of th e https://fedoraproject.org/wiki/MoveFedoraJDKsToBecomePortableJDKs#Known_issues should be hit by this proposal. == Dependencies == No dependent packages should notice the change. == Contingency Plan == * Contingency mechanism: Revert the patches and rework https://fedoraproject.org/wiki/MoveFedoraJDKsToBecomePortableJDKs * Contingency deadline: before f37 release * Blocks release? Unless the java-stack will become completely borked then no. == Documentation == https://fedoraproject.org/wiki/MoveFedoraJDKsToBecomePortableJDKs -- Ben Cotton He / Him / His Fedora Program Manager Red Hat TZ=America/Indiana/Indianapolis ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Fedora-IoT-37-20220510.0 compose check report
Missing expected images: Iot dvd aarch64 Iot dvd x86_64 Failed openQA tests: 2/15 (x86_64), 2/15 (aarch64) ID: 1262511 Test: x86_64 IoT-dvd_ostree-iso install_default_upload@uefi URL: https://openqa.fedoraproject.org/tests/1262511 ID: 1262514 Test: x86_64 IoT-dvd_ostree-iso iot_clevis@uefi URL: https://openqa.fedoraproject.org/tests/1262514 ID: 1262526 Test: aarch64 IoT-dvd_ostree-iso iot_clevis@uefi URL: https://openqa.fedoraproject.org/tests/1262526 ID: 1262527 Test: aarch64 IoT-dvd_ostree-iso install_default_upload@uefi URL: https://openqa.fedoraproject.org/tests/1262527 Skipped non-gating openQA tests: 26 of 30 -- Mail generated by check-compose: https://pagure.io/fedora-qa/check-compose ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Fedora-Rawhide-20220510.n.0 compose check report
Missing expected images: Minimal raw-xz armhfp Compose FAILS proposed Rawhide gating check! 19 of 43 required tests failed, 13 results missing openQA tests matching unsatisfied gating requirements shown with **GATING** below Failed openQA tests: 92/231 (x86_64), 53/161 (aarch64) New failures (same test not failed in Fedora-Rawhide-20220509.n.0): ID: 1262117 Test: x86_64 Server-boot-iso install_default **GATING** URL: https://openqa.fedoraproject.org/tests/1262117 ID: 1262119 Test: x86_64 Server-dvd-iso install_blivet_standard_partition_ext4 URL: https://openqa.fedoraproject.org/tests/1262119 ID: 1262120 Test: x86_64 Server-dvd-iso install_blivet_standard_partition_ext4@uefi URL: https://openqa.fedoraproject.org/tests/1262120 ID: 1262121 Test: x86_64 Server-dvd-iso install_btrfs_preserve_home URL: https://openqa.fedoraproject.org/tests/1262121 ID: 1262122 Test: x86_64 Server-dvd-iso install_vncconnect_client URL: https://openqa.fedoraproject.org/tests/1262122 ID: 1262123 Test: x86_64 Server-dvd-iso anaconda_help URL: https://openqa.fedoraproject.org/tests/1262123 ID: 1262124 Test: x86_64 Server-dvd-iso install_lvm_ext4 URL: https://openqa.fedoraproject.org/tests/1262124 ID: 1262126 Test: x86_64 Server-dvd-iso install_default_upload **GATING** URL: https://openqa.fedoraproject.org/tests/1262126 ID: 1262130 Test: x86_64 Server-dvd-iso install_standard_partition_ext4 URL: https://openqa.fedoraproject.org/tests/1262130 ID: 1262131 Test: x86_64 Server-dvd-iso install_standard_partition_ext4@uefi URL: https://openqa.fedoraproject.org/tests/1262131 ID: 1262133 Test: x86_64 Server-dvd-iso install_btrfs_preserve_home_uefi@uefi URL: https://openqa.fedoraproject.org/tests/1262133 ID: 1262136 Test: x86_64 Server-dvd-iso support_server URL: https://openqa.fedoraproject.org/tests/1262136 ID: 1262139 Test: x86_64 Server-dvd-iso install_vnc_server URL: https://openqa.fedoraproject.org/tests/1262139 ID: 1262141 Test: x86_64 Server-dvd-iso install_lvm_ext4@uefi URL: https://openqa.fedoraproject.org/tests/1262141 ID: 1262148 Test: x86_64 Server-dvd-iso install_blivet_btrfs_preserve_home_uefi@uefi URL: https://openqa.fedoraproject.org/tests/1262148 ID: 1262149 Test: x86_64 Server-dvd-iso install_blivet_lvm_ext4 URL: https://openqa.fedoraproject.org/tests/1262149 ID: 1262150 Test: x86_64 Server-dvd-iso install_blivet_lvm_ext4@uefi URL: https://openqa.fedoraproject.org/tests/1262150 ID: 1262151 Test: x86_64 Server-dvd-iso install_repository_nfsiso_variation URL: https://openqa.fedoraproject.org/tests/1262151 ID: 1262153 Test: x86_64 Server-dvd-iso install_repository_hd_variation URL: https://openqa.fedoraproject.org/tests/1262153 ID: 1262156 Test: x86_64 Server-dvd-iso install_blivet_btrfs_preserve_home URL: https://openqa.fedoraproject.org/tests/1262156 ID: 1262157 Test: x86_64 Server-dvd-iso install_default@uefi **GATING** URL: https://openqa.fedoraproject.org/tests/1262157 ID: 1262158 Test: x86_64 Server-dvd-iso install_updates_nfs URL: https://openqa.fedoraproject.org/tests/1262158 ID: 1262159 Test: x86_64 Server-dvd-iso install_vncconnect_server URL: https://openqa.fedoraproject.org/tests/1262159 ID: 1262165 Test: x86_64 Server-dvd-iso install_repository_nfs_graphical URL: https://openqa.fedoraproject.org/tests/1262165 ID: 1262167 Test: x86_64 Server-dvd-iso install_repository_nfs_variation URL: https://openqa.fedoraproject.org/tests/1262167 ID: 1262168 Test: x86_64 Server-dvd-iso install_vnc_client URL: https://openqa.fedoraproject.org/tests/1262168 ID: 1262173 Test: x86_64 Everything-boot-iso memory_check URL: https://openqa.fedoraproject.org/tests/1262173 ID: 1262174 Test: x86_64 Everything-boot-iso memory_check@uefi URL: https://openqa.fedoraproject.org/tests/1262174 ID: 1262175 Test: x86_64 Everything-boot-iso install_default@uefi **GATING** URL: https://openqa.fedoraproject.org/tests/1262175 ID: 1262176 Test: x86_64 Everything-boot-iso install_default **GATING** URL: https://openqa.fedoraproject.org/tests/1262176 ID: 1262203 Test: x86_64 KDE-live-iso anaconda_help URL: https://openqa.fedoraproject.org/tests/1262203 ID: 1262205 Test: x86_64 KDE-live-iso install_default_upload **GATING** URL: https://openqa.fedoraproject.org/tests/1262205 ID: 1262209 Test: x86_64 KDE-live-iso install_default@uefi **GATING** URL: https://openqa.fedoraproject.org/tests/1262209 ID: 1262216 Test: x86_64 KDE-live-iso install_no_user **GATING** URL: https://openqa.fedoraproject.org/tests/1262216 ID: 1262226 Test: x86_64 Silverblue-dvd_ostree-iso install_default_upload URL: https://openqa.fedoraproject.org/tests/1262226 ID: 1262249 Test: x86_64 Cloud_Base-qcow2-qcow2 base_selinux@uefi URL: https://openqa.fedoraproject.org/tests/1262249 ID: 1262259 Test: aarch64 Server-boot-iso install_default@uefi URL: https://openqa.fedoraproject.org/tests/1262259 ID: 1262261 Test: aarch64
[rpms/perl-libwww-perl] PR #31: 6.65 bump
mspacek opened a new pull-request against the project: `perl-libwww-perl` that you are following: `` 6.65 bump `` To reply, visit the link below https://src.fedoraproject.org/rpms/perl-libwww-perl/pull-request/31 ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Strange messages in Bodhi (ejected from push?)
On Mon, May 9, 2022 at 10:54 PM Ron Olson wrote: > > It was successful, apparently: > > ➜ ~ koji tag-build f36-updates-candidate swift-lang-5.6-1.fc36 > Created task 86848500 > Watching tasks (this may be safely interrupted)... > 86848500 tagBuild (noarch): free > 86848500 tagBuild (noarch): free -> closed > 0 free 0 open 1 done 0 failed > > 86848500 tagBuild (noarch) completed successfully > ➜ ~ > > But I’m not clear on what this does, and should I be doing it as part of > every koji update? No, this is only a workaround for a bug in koji and / or bodhi. They should handle moving builds for updates to the correct tags internally. But sometimes this breaks, and you need to move things along manually to un-break them, as in this case (which is what the "koji tag-build" command does). Fabio ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Fedora 36 Release Notes, do we have some?
> Am 10.05.2022 um 12:16 schrieb Miroslav Suchý : > > The workflow exists: > > The Change proposal guide you how to suggest release notes. E.g. I have one > change in this release and I wrote Yes, I know that. But, as far as I oversee, it’s not a (publication) workflow. E.g. there is no date when a text has to be delivered at latest, there is no one who checks it, there is no procedure what to do if something is missing, no date, when the final release note has to be completed, etc. It seems a more or less self-sustaining process. And there's no one publicly designated to be in charge - probably except poor Ben, who's in charge of everything no one else cares about. And that has often worked out well. So, the current state of release notes makes a rather incomplete impression, with a lot of empty chapters - just a few hours before release. But there a some hours left. Maybe, someone will fine-tuning it. -- Peter Boy https://fedoraproject.org/wiki/User:Pboy p...@uni-bremen.de CET (UTC+1) / CEST (UTC+2) Member of Fedora Server Edition WG Contributing to docs ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Taking over maintenance for orphaned git-up package
On Thu, May 05, 2022 at 11:27:45AM +0200, Fabio Valentini wrote: On Thu, May 5, 2022 at 11:11 AM Ewoud Kohl van Wijngaarden wrote: On Thu, May 05, 2022 at 08:39:27AM -, Artur Frenszek-Iwicki wrote: >git-up has been retired for over a year now. Packages that have been >retired for over 8 weeks need to go through Package Review again. > >https://docs.fedoraproject.org/en-US/package-maintainers/Package_Retirement_Process/#claiming I filed https://bugzilla.redhat.com/show_bug.cgi?id=2082032 for that. https://src.fedoraproject.org/rpms/git-up has a button "Retired" which opened a pre-filled ticket, which was the wrong template. Would it make sense (and be technically feasible) to detect it was retired >= 8 weeks ago and use the correct template? If so, where would I file this RFE? I see the problem: https://pagure.io/releng/new_issue?title=Unretire%20rpms/git-uptemplate=package_unretiremet There's a typo in the URL the button takes you to (should be unretiremeNt). Otherwise it would take you to the correct template. The component that's responsible for that button should be either https://pagure.io/pagure-dist-git or https://pagure.io/pagure itself, I'm not sure, because I can't find the code for it in the pagure-dist-git plugin. Looks like it's in pagure itself: https://pagure.io/pagure/pull-request/5296 ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Fedora-IoT-36-20220510.0 compose check report
No missing expected images. Failed openQA tests: 3/15 (aarch64) New failures (same test not failed in Fedora-IoT-36-20220505.0): ID: 1261934 Test: aarch64 IoT-dvd_ostree-iso podman@uefi URL: https://openqa.fedoraproject.org/tests/1261934 ID: 1261940 Test: aarch64 IoT-dvd_ostree-iso podman_client@uefi URL: https://openqa.fedoraproject.org/tests/1261940 Old failures (same test failed in Fedora-IoT-36-20220505.0): ID: 1261932 Test: aarch64 IoT-dvd_ostree-iso iot_clevis@uefi URL: https://openqa.fedoraproject.org/tests/1261932 Passed openQA tests: 15/15 (x86_64), 12/15 (aarch64) Installed system changes in test aarch64 IoT-dvd_ostree-iso install_default_upload@uefi: System load changed from 0.34 to 0.16 Previous test data: https://openqa.fedoraproject.org/tests/1255712#downloads Current test data: https://openqa.fedoraproject.org/tests/1261933#downloads -- Mail generated by check-compose: https://pagure.io/fedora-qa/check-compose ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: fedpkg sources - downloading unused source files: opt-in/opt-out
On 10/05/2022 10:23, Artur Frenszek-Iwicki wrote: 2. Edit the spec file in a way that changes which sources are used (say, update to a new version) 3. Do not run "fedpkg new-sources" to upload the new tarballs 4. The "sources" file now lists files that are not actually used by the spec Are you manually editing the "sources" file? -- Sincerely, Vitaly Zaitsev (vit...@easycoding.org) ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Fedora 36 Release Notes, do we have some?
Dne 10. 05. 22 v 11:40 Peter Boy napsal(a): Additionally, as fas as I see, docs team has no ==contentwise== workflow either (and can’t provide one because it doesn’t govern the process). There is a technical workflow, though, to ensure there is a file to be the next release notes and a way to add content. So the ==contentwise== workflow and responsibility should be part of the change process and its governance. Maybe, docs team can provide a lector (don’t know the english term, „editor in chief“?) to finally fine-tune and format the text. But I suppose we explicitly would have to find someone for each single release at the beginning of a release cycle. The workflow exists: The Change proposal guide you how to suggest release notes. E.g. I have one change in this release and I wrote https://fedoraproject.org/wiki/Changes/RetiredPackages#Release_Notes Wrangler (Ben) created https://pagure.io/fedora-docs/release-notes/issue/759 So the content and workflow is available. I agree that it would nice to have wrangler from documentation team who makes sure all documentation is added to Release notes in time. Miroslav ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[Bug 2083360] perl-libwww-perl-6.65 is available
https://bugzilla.redhat.com/show_bug.cgi?id=2083360 Michal Josef Spacek changed: What|Removed |Added Status|NEW |ASSIGNED Doc Type|--- |If docs needed, set a value --- Comment #1 from Michal Josef Spacek --- Changes: 6.65 2022-05-09 18:36:14Z - fix NAME in Makefile.PL (GH#413) (Graham Knop) No functional changes, for f34, f35, f36 and rawhide -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2083360 ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Fedora-Cloud-34-20220510.0 compose check report
No missing expected images. Soft failed openQA tests: 1/8 (x86_64), 1/8 (aarch64) (Tests completed, but using a workaround for a known bug) Old soft failures (same test soft failed in Fedora-Cloud-34-20220509.0): ID: 1261845 Test: x86_64 Cloud_Base-qcow2-qcow2 cloud_autocloud URL: https://openqa.fedoraproject.org/tests/1261845 ID: 1261854 Test: aarch64 Cloud_Base-qcow2-qcow2 cloud_autocloud@uefi URL: https://openqa.fedoraproject.org/tests/1261854 Passed openQA tests: 7/8 (x86_64), 7/8 (aarch64) -- Mail generated by check-compose: https://pagure.io/fedora-qa/check-compose ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Fedora 36 Release Notes, do we have some?
> Am 10.05.2022 um 10:47 schrieb Miro Hrončok : > > On Mon, May 9, 2022 at 11:17 PM Ben Cotton wrote: >> >> The #docs tag on Fedora Discussion is a better place to ask this >> question > > Noted. It's quite confusing to me to see that parts of our workflow > are not discussed here. Additionally, as fas as I see, docs team has no ==contentwise== workflow either (and can’t provide one because it doesn’t govern the process). There is a technical workflow, though, to ensure there is a file to be the next release notes and a way to add content. So the ==contentwise== workflow and responsibility should be part of the change process and its governance. Maybe, docs team can provide a lector (don’t know the english term, „editor in chief“?) to finally fine-tune and format the text. But I suppose we explicitly would have to find someone for each single release at the beginning of a release cycle. -- Peter Boy https://fedoraproject.org/wiki/User:Pboy p...@uni-bremen.de CET (UTC+1) / CEST (UTC+2) Member of Fedora Server Edition WG Contributing to docs ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: fedpkg sources - downloading unused source files: opt-in/opt-out
V Tue, May 10, 2022 at 08:23:17AM -, Artur Frenszek-Iwicki napsal(a): > > I somehow don't understand why there should be anything like "unused > > source files". Why is something like this even possible? > 1. Grab a package > 2. Edit the spec file in a way that changes which sources are used (say, > update to a new version) > 3. Do not run "fedpkg new-sources" to upload the new tarballs > 4. The "sources" file now lists files that are not actually used by the spec Here I do these two additional steps: 4.1. Review thew new sources for new licenses, usually by comparing them to the old sources. 4.2. Run "fedpkg new-sources" because now I know the sources are license-acceptable and because it prevents me from forgetting to run "fedpkg new-sources" before pushing commits to dist-git. > 5. Run "fedpkg mockbuild" > 6. Mockbuild attempts to download package sources > Here I do rsync to a virtual machine and "fedpkg local" there. But I guess it does not differ much from "fedpkg mockbuild". -- Petr signature.asc Description: PGP signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: fedpkg sources - downloading unused source files: opt-in/opt-out
> I very likely have the files listed in sources > around from previous attempts Well, yeah, but it's also likely that someone: 1. Has multiple machines, hadn't done any work on this package on the current machine, and did a fresh "fedpkg clone" 2. Got fed up with clutter in the directory and started their work with "rm *.tar.gz *.src.rpm" In both these cases the old sources wouldn't be around. A.FI. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Fedora 36 Release Notes, do we have some?
On Mon, May 9, 2022 at 11:17 PM Ben Cotton wrote: > > The #docs tag on Fedora Discussion is a better place to ask this > question Noted. It's quite confusing to me to see that parts of our workflow are not discussed here. > but the F36 docs will be published to the website prior to > the release tomorrow. In the meantime, I've added them to the config > for docs.stg.fedoraproject.org, so you'll be able to see them there > after the next rebuild: > https://docs.stg.fedoraproject.org/en-US/fedora/f36/ Thanks. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: fedpkg sources - downloading unused source files: opt-in/opt-out
Dne 10. 05. 22 v 10:23 Artur Frenszek-Iwicki napsal(a): I somehow don't understand why there should be anything like "unused source files". Why is something like this even possible? 1. Grab a package 2. Edit the spec file in a way that changes which sources are used (say, update to a new version) 3. Do not run "fedpkg new-sources" to upload the new tarballs 4. The "sources" file now lists files that are not actually used by the spec 5. Run "fedpkg mockbuild" 6. Mockbuild attempts to download package sources But in this scenario, I very likely have the files listed in sources around from previous attempts and once they were around, they were never downloaded again. Vít A.FI. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure 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 on the list, report it: https://pagure.io/fedora-infrastructure
Re: Static library linking error
* Florian Weimer: * Richard Shaw: I added the following to the libmqttc library and verified -fPIC -pie is in the build flags[1] per the recommendation from the hardening page[2] but the error remains. Code that is linked into a shared object (with -shared) must be compiled as PIC, not PIE. So using "-fPIC -pie" should elicit a warning from the compiler, something like: warning: '-pie' turns off '-fPIC' with an analogous warning whenever a command-line parameter conflicts with an earlier command-line parameter. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: fedpkg sources - downloading unused source files: opt-in/opt-out
> I somehow don't understand why there should be anything like "unused > source files". Why is something like this even possible? 1. Grab a package 2. Edit the spec file in a way that changes which sources are used (say, update to a new version) 3. Do not run "fedpkg new-sources" to upload the new tarballs 4. The "sources" file now lists files that are not actually used by the spec 5. Run "fedpkg mockbuild" 6. Mockbuild attempts to download package sources A.FI. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: fedpkg sources - downloading unused source files: opt-in/opt-out
Ok, now I see commits such as: https://src.fedoraproject.org/rpms/ffmpeg/c/70ecae14df6b89cbd269778fc6808eb6e51e141e?branch=rawhide which is awful that we need something like this. But @Neal, wouldn't it be better if your `ffmpeg_gen_free_tarball.sh` simply updated the hashes in `sources` file? The `fedpkg new-sources --offline` could help with that I guess. Vít Dne 10. 05. 22 v 10:10 Vít Ondruch napsal(a): I somehow don't understand why there should be anything like "unused source files". Why is something like this even possible? It seems strange that this was not questioned originally and it seems still strange nobody questions this in this thread. Vít Dne 04. 05. 22 v 17:01 Ondrej Nosek napsal(a): Hi all, A few months ago fedpkg introduced a change which avoids downloading source files (from dist-git) that are not used in the specfile and therefore downloading them would be wasting of resources and time. The original request was opened here [1] and implemented here [2]. The logic is part of the command "fedpkg sources" and currently can't be disabled manually. The logic parses specfile, but doesn't do a deep analysis, so it is doesn't always right. Recently we got a request for opt-in implementation of this. It means you should actively use some argument (ie. --skip-unused) to avoid downloading unused sources. The requestor points out that it broke the original functionality and it is not possible to add any extra arguments into the complicated release process (RHEL kernel). On the other hand, opt-out (--download-unused) has (I think) a significantly higher impact on saving resources (time and network capacity). Of course, it doesn't have to be implemented as an extra argument, there might be a different (maybe not so clean) solution for such projects. What do you think about it? I added into a loop (bcc) names who already were involved in this in a past (on the Fedora devel mailing list) Thanks, Ondrej [1] https://pagure.io/rpkg/issue/559 [2] https://pagure.io/rpkg/pull-request/564 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 on the list, report it: https://pagure.io/fedora-infrastructure
Re: Static library linking error
* Richard Shaw: > I added the following to the libmqttc library and verified -fPIC -pie > is in the build flags[1] per the recommendation from the hardening > page[2] but the error remains. Code that is linked into a shared object (with -shared) must be compiled as PIC, not PIE. Thanks, Florian ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: fedpkg sources - downloading unused source files: opt-in/opt-out
I somehow don't understand why there should be anything like "unused source files". Why is something like this even possible? It seems strange that this was not questioned originally and it seems still strange nobody questions this in this thread. Vít Dne 04. 05. 22 v 17:01 Ondrej Nosek napsal(a): Hi all, A few months ago fedpkg introduced a change which avoids downloading source files (from dist-git) that are not used in the specfile and therefore downloading them would be wasting of resources and time. The original request was opened here [1] and implemented here [2]. The logic is part of the command "fedpkg sources" and currently can't be disabled manually. The logic parses specfile, but doesn't do a deep analysis, so it is doesn't always right. Recently we got a request for opt-in implementation of this. It means you should actively use some argument (ie. --skip-unused) to avoid downloading unused sources. The requestor points out that it broke the original functionality and it is not possible to add any extra arguments into the complicated release process (RHEL kernel). On the other hand, opt-out (--download-unused) has (I think) a significantly higher impact on saving resources (time and network capacity). Of course, it doesn't have to be implemented as an extra argument, there might be a different (maybe not so clean) solution for such projects. What do you think about it? I added into a loop (bcc) names who already were involved in this in a past (on the Fedora devel mailing list) Thanks, Ondrej [1] https://pagure.io/rpkg/issue/559 [2] https://pagure.io/rpkg/pull-request/564 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 on the list, report it: https://pagure.io/fedora-infrastructure
Re: Static library linking error
On 5/10/22 06:21 UTC, Mamoru TASAKA wrote: Richard Shaw wrote on 2022/05/10 12:07: I'm working on some IIoT related packages in my COPR where I have a dynamic library linking to a static library and getting the following error: /usr/bin/ld: /usr/lib/gcc/x86_64-redhat-linux/12/../../../../lib64/libmqttc.a(mqtt.c.o): warning: relocation against `mqtt_fixed_header_rules' in read-only section `.text' /usr/bin/ld: /usr/lib/gcc/x86_64-redhat-linux/12/../../../../lib64/libmqttc.a(mqtt.c.o): relocation R_X86_64_PC32 against symbol `mqtt_fixed_header_rules' can not be used when making a shared object; recompile with -fPIC I added the following to the libmqttc library and verified -fPIC -pie is in the build flags[1] per the recommendation from the hardening page[2] but the error remains. Any ideas? Thanks, Richard [1] https://download.copr.fedorainfracloud.org/results/hobbes1069/IIoT/fedora-rawhide-x86_64/04386803-mqtt-c/builder-live.log.gz This log no longer seems to exist. I was able to access it just now. Some relevant lines are: = [ 18%] Building C object CMakeFiles/mqttc.dir/src/mqtt.c.o /usr/bin/gcc -DMQTT_USE_BIO -I/builddir/build/BUILD/MQTT-C-1.1.5/include -O2 -flto=auto -ffat-lto-objects -fexceptions \ -g -grecord-gcc-switches -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS \ -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -fstack-protector-strong -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1\ -m64 -mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection -fPIC -pie -MD -MT \ CMakeFiles/mqttc.dir/src/mqtt.c.o -MF CMakeFiles/mqttc.dir/src/mqtt.c.o.d -o CMakeFiles/mqttc.dir/src/mqtt.c.o \ -c /builddir/build/BUILD/MQTT-C-1.1.5/src/mqtt.c [ 27%] Linking C static library libmqttc.a /usr/bin/cmake -P CMakeFiles/mqttc.dir/cmake_clean_target.cmake /usr/bin/cmake -E cmake_link_script CMakeFiles/mqttc.dir/link.txt --verbose=1 /usr/bin/ar qc libmqttc.a CMakeFiles/mqttc.dir/src/mqtt_pal.c.o CMakeFiles/mqttc.dir/src/mqtt.c.o /usr/bin/ranlib libmqttc.a = which confirms that "-fPIC -pie" was used when compiling mqtt.c into CMakeFiles/mqttc.dir/src/mqtt.c.o . Suggestion: extract mqtt.c.o from libmqttc.a, then run "readelf --all --wide mqtt.c.o > foo" and look in file foo for more information about: relocation R_X86_64_PC32 against symbol `mqtt_fixed_header_rules' Also, upstream should remedy complaints from the compiler: = /builddir/build/BUILD/MQTT-C-1.1.5/examples/bio_publisher.c: In function 'main': /builddir/build/BUILD/MQTT-C-1.1.5/examples/bio_publisher.c:47:5: warning: 'ERR_load_BIO_strings' is deprecated: \ Since OpenSSL 3.0 [-Wdeprecated-declarations] 47 | ERR_load_BIO_strings(); | ^~~~ In file included from /usr/include/openssl/cryptoerr.h:17, from /usr/include/openssl/crypto.h:38, from /usr/include/openssl/bio.h:30, from /builddir/build/BUILD/MQTT-C-1.1.5/include/mqtt_pal.h:100, from /builddir/build/BUILD/MQTT-C-1.1.5/include/mqtt.h:43, from /builddir/build/BUILD/MQTT-C-1.1.5/examples/bio_publisher.c:10: /usr/include/openssl/cryptoerr_legacy.h:31:27: note: declared here 31 | OSSL_DEPRECATEDIN_3_0 int ERR_load_BIO_strings(void); | ^~~~ = and: = /builddir/build/BUILD/MQTT-C-1.1.5/examples/simple_subscriber.c: In function 'main': /builddir/build/BUILD/MQTT-C-1.1.5/examples/simple_subscriber.c:73:24: warning: passing argument 2 of 'mqtt_init' makes pointer from integer without a cast [-Wint-conversion] 73 | mqtt_init(, sockfd, sendbuf, sizeof(sendbuf), recvbuf, sizeof(recvbuf), publish_callback); |^~ || |int = plus several more int vs pointer conflicts. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[Bug 2078127] Please build csv for EPEL8
https://bugzilla.redhat.com/show_bug.cgi?id=2078127 --- Comment #4 from Stefano Biagiotti --- Works for me. Thanks Jitka. -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2078127 ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Static library linking error
Richard Shaw wrote on 2022/05/10 12:07: I'm working on some IIoT related packages in my COPR where I have a dynamic library linking to a static library and getting the following error: /usr/bin/ld: /usr/lib/gcc/x86_64-redhat-linux/12/../../../../lib64/libmqttc.a(mqtt.c.o): warning: relocation against `mqtt_fixed_header_rules' in read-only section `.text' /usr/bin/ld: /usr/lib/gcc/x86_64-redhat-linux/12/../../../../lib64/libmqttc.a(mqtt.c.o): relocation R_X86_64_PC32 against symbol `mqtt_fixed_header_rules' can not be used when making a shared object; recompile with -fPIC I added the following to the libmqttc library and verified -fPIC -pie is in the build flags[1] per the recommendation from the hardening page[2] but the error remains. Any ideas? Thanks, Richard [1] https://download.copr.fedorainfracloud.org/results/hobbes1069/IIoT/fedora-rawhide-x86_64/04386803-mqtt-c/builder-live.log.gz This log no longer seems to exist. [2] https://fedoraproject.org/wiki/Changes/Harden_All_Packages Regards, Mamoru ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[Bug 2083127] Upgrade perl-List-UtilsBy to 0.12
https://bugzilla.redhat.com/show_bug.cgi?id=2083127 Jitka Plesnikova changed: What|Removed |Added Resolution|--- |RAWHIDE Status|NEW |CLOSED Fixed In Version||perl-List-UtilsBy-0.12-1.fc ||37 ||perl-List-UtilsBy-0.12-1.fc ||36 Last Closed||2022-05-10 06:06:06 --- Comment #1 from Jitka Plesnikova --- Built by corsepiu. -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2083127 ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: upstream systemd discussion about MACAddressPolicy for bonds and bridges
On 10/05/2022 03:12, Dusty Mabe wrote: Just wanted to point interested people in the direction of an upstream discussion about how (by default) the MAC address should get set for bond and bridge devices. https://lists.freedesktop.org/archives/systemd-devel/2022-May/047893.html A few of us were originally going to propose a change to Fedora to change the current behavior back, but it was suggested we take the discussion upstream to hash out the merits there. All I can say is, no, just leave it alone. Having fixed all my machines two years ago when it stopped generating persistent addresses I have just spent this weekend doing it again now that F36 has gone back to them. I don't care what address my bridges have, so long as it is fixed so that DHCP can allocate addresses against it, but I do prefer not to have to fix all my DHCP and DNS every time the policy flip flops and upgrades break my networks! 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 on the list, report it: https://pagure.io/fedora-infrastructure
[Bug 2083124] Upgrade perl-Convert-Color to 0.12
https://bugzilla.redhat.com/show_bug.cgi?id=2083124 Jitka Plesnikova changed: What|Removed |Added Status|NEW |CLOSED Resolution|--- |RAWHIDE Fixed In Version||perl-Convert-Color-0.12-1.f ||c37 ||perl-Convert-Color-0.12-1.f ||c36 Last Closed||2022-05-10 06:05:14 --- Comment #1 from Jitka Plesnikova --- Built by corsepiu. -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2083124 ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
