Re: F38 prospoal: Enable bootupd for Fedora Silverblue & Kinoite (Self-Contained Change proposal)
On Thu, Nov 10, 2022, at 6:08 PM, Robbie Harwood wrote: > Ben Cotton writes: > >> By design, ostree does not manage bootloader updates as they can not >> (yet) happen in a transactional, atomic and safe fashion. > > As we've talked about before, it's not possible to make updates > transactional. It involves, per spec and depending on processor > architecture, updating multiple files in different directories, > potentially on different filesystems entirely, one of which is fat32. EFI/FedoraA EFI/FedoraB NVRAM bootorder uses A then B Update the bootloader in EFI/FedoraB At any point of failure, only the EFI/FedoraA bootloader path is used. Once everything in EFI/FedoraB is committed to stable media, set bootnext FedoraB. If the boot fails, automatic failback to FedoraA. If the boot succeeds, bootupd can change bootorder. B then A. ? -- Chris Murphy ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: webkit2gtk5.0 -> webkitgtk6.0
On Fri, Nov 11 2022 at 09:49:29 PM +0100, Vitaly Zaitsev via devel wrote: What about webkit2gtk4.0? Telegram Desktop can use 4.0, 4.1 and 5.0. Maybe it will be better to switch to webkit2gtk4.x? Better to use -4.1. That is stable and should be safe to depend on. The -4.0 is the obsolete libsoup 2 version. It's stable too, but it's time for it to go away. Michael ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: webkit2gtk5.0 -> webkitgtk6.0
On Fri, Nov 11 2022 at 10:02:39 PM +0100, Fabio Valentini wrote: Have you considered bumping to 5.1, 5.2, 5.3 ... for the continuously expected ABI / soname bumps? Jumping by a major version number every time kind of pollutes the namespace upwards unnecessarily, doesn't it? Hi, there are no plans for any more API version bumps. It should stay at -6.0 from now on. Hopefully. Michael ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[Bug 2142173] perl-IO-Tty-1.17 is available
https://bugzilla.redhat.com/show_bug.cgi?id=2142173
--- Comment #1 from Upstream Release Monitoring
---
Scratch build failed. Details below:
GenericError: File upload failed:
cli-build/1668203187.693843.xHlWaVGB/perl-IO-Tty-1.17-1.fc36.src.rpm
Traceback:
File
"/usr/local/lib/python3.10/site-packages/hotness/use_cases/package_scratch_build_use_case.py",
line 56, in build
result = self.builder.build(request.package, request.opts)
File "/usr/local/lib/python3.10/site-packages/hotness/builders/koji.py", line
198, in build
output["build_id"] = self._scratch_build(session, package.name, srpm)
File "/usr/local/lib/python3.10/site-packages/hotness/builders/koji.py", line
451, in _scratch_build
session.uploadWrapper(source, serverdir)
File "/usr/lib/python3.10/site-packages/koji/__init__.py", line 3083, in
uploadWrapper
self.fastUpload(localfile, path, name, callback, blocksize, overwrite,
volume=volume)
File "/usr/lib/python3.10/site-packages/koji/__init__.py", line 3018, in
fastUpload
raise GenericError("File upload failed: %s/%s" % (path, name))
If you think this issue is caused by some bug in the-new-hotness, please report
it on the-new-hotness issue tracker:
https://github.com/fedora-infra/the-new-hotness/issues
--
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2142173
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
[Bug 2142173] New: perl-IO-Tty-1.17 is available
https://bugzilla.redhat.com/show_bug.cgi?id=2142173 Bug ID: 2142173 Summary: perl-IO-Tty-1.17 is available Product: Fedora Version: rawhide Status: NEW Component: perl-IO-Tty Keywords: FutureFeature, Triaged Assignee: spo...@gmail.com Reporter: upstream-release-monitor...@fedoraproject.org QA Contact: extras...@fedoraproject.org CC: jose.p.oliveira@gmail.com, jples...@redhat.com, mspa...@redhat.com, p...@city-fan.org, perl-devel@lists.fedoraproject.org, ppi...@redhat.com, spo...@gmail.com, st...@silug.org Target Milestone: --- Classification: Fedora Releases retrieved: 1.17 Upstream release that is considered latest: 1.17 Current version/release in rawhide: 1.16-7.fc37 URL: http://search.cpan.org/dist/IO-Tty/ Please consult the package updates policy before you issue an update to a stable branch: https://docs.fedoraproject.org/en-US/fesco/Updates_Policy/ More information about the service that created this bug can be found at: https://docs.fedoraproject.org/en-US/package-maintainers/Upstream_Release_Monitoring Please keep in mind that with any upstream change, there may also be packaging changes that need to be made. Specifically, please remember that it is your responsibility to review the new version to ensure that the licensing is still correct and that no non-free or legally problematic items have been added upstream. Based on the information from Anitya: https://release-monitoring.org/project/7281/ To change the monitoring settings for the project, please visit: https://src.fedoraproject.org/rpms/perl-IO-Tty -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2142173 ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[EPEL-devel] Updated KDE for RHEL 8 available in epel-testing
RHEL 8.7 was released earlier this week. Among other things, it has an updated qt5 that needed many KDE packages to be rebuilt. In addition, it is time for the yearly major update of KDE Plasma Desktop for epel8. If you would like to test the KDE update, or if you are having troubles updating to RHEL 8.7 due to qt5 dependency issues, simply enable the epel-testing repo to get the update. dnf --enablerepo=epel-testing update This will get you: qt5 5.15.3 plasma 5.24.6 kf5 5.96 apps 22.04 / 21.12 (Mostly) Note1: There are seven packages still giving me trouble. They are not critical and should be in epel-testing by Monday. Note2: This is the last major update of KDE Plasma Desktop for epel8. There are many older libraries in RHEL 8 that are preventing us from updating it to the next version of plasma. This is not Red Hat's fault, but simply the nature of an Enterprise release. We will continue to provide security and critical bug fixes, but no major updates. Troy Dawson ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: webkit2gtk5.0 -> webkitgtk6.0
On Fri, Nov 11, 2022, 17:06 Michael Catanzaro wrote: > Hi, > > The webkit2gtk5.0 package in rawhide will be removed and replaced by > webkitgtk6.0. Affected packages that will need to be patched to use the > new API version and rebuilt are: evolution-data-server, gnome-builder, > gnome-initial-setup. My plan is to handle all of these builds in a > side tag. > Have you considered bumping to 5.1, 5.2, 5.3 ... for the continuously expected ABI / soname bumps? Jumping by a major version number every time kind of pollutes the namespace upwards unnecessarily, doesn't it? Fabio (sent from my phone, sorry for possible html formatting) > Normally we're supposed to wait a week before making changes like this, > but since I have commit access to care for all the dependent packages, > I assume it should be fine to go ahead sooner. > > Michael > > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > Do not reply to spam, report it: > https://pagure.io/fedora-infrastructure/new_issue > ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: webkit2gtk5.0 -> webkitgtk6.0
On 11/11/2022 17:48, Neal Gompa wrote: Vitaly Zaitsev is the maintainer. It hasn't moved to Fedora yet. We can't move yet, because it requires openh264-devel at the build time. -- Sincerely, Vitaly Zaitsev (vit...@easycoding.org) ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: webkit2gtk5.0 -> webkitgtk6.0
On 11/11/2022 17:44, Michael Catanzaro wrote: I wasn't able to figure out the Fedora package name to contact the maintainer. Do you know what it is? I'm maintainer of the telegram-desktop package in RPM Fusion. We'll have to patch the library version there and include a new build in the side tag. And it's going to break on every WebKitGTK update for the foreseeable future, because webkitgtk-6.0 will receive regular soname bumps until the API stabilizes. What about webkit2gtk4.0? Telegram Desktop can use 4.0, 4.1 and 5.0. Maybe it will be better to switch to webkit2gtk4.x? -- Sincerely, Vitaly Zaitsev (vit...@easycoding.org) ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Help understanding Fedora CI failure wrt RPM Sequoia
Hi all, https://gitlab.com/testing-farm/infrastructure/-/merge_requests/90/diffs That would be the reason. We would never think this would cause so much confusion, our bad :( As the original issue is gone, we have reverted this workaround and I hope it is resolved now. Best regards, /M On Thu, Nov 10, 2022 at 9:49 PM Kevin Fenzi wrote: > On Thu, Nov 10, 2022 at 11:39:27AM +0200, Panu Matilainen wrote: > > > > So, overnight somebody updated the koji package in > > https://kojipkgs.fedoraproject.org/repos/rawhide/ to the current > unsigned > > rawhide build, which makes the issue go away. > > Nothing should have updated the koji package. > > The last change was in october: > > Wed Oct 26 14:08:39 2022 koji-1.30.1-2.fc38 tagged into f38 by bodhi > [still active] > > In fact there's no such actual build: > > ➜ ~ koji list-history --build koji-1.28.1-1.fc38 > 2022-11-10 12:39:45,017 [ERROR] koji: GenericError: No such build: > 'koji-1.28.1-1.fc38' > > Very odd that ci would use a build that doesn't exist. (I guess it's a > scratch build it made itself?) > > kevin > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > Do not reply to spam, report it: > https://pagure.io/fedora-infrastructure/new_issue > -- Miroslav Vadkerti :: Senior Principal QE :: Testing Farm / Linux QE IRC mvadkert #tft #tmt #osci :: Mobile +420 773 944 252 Remote Czech Republic :: Red Hat Czech s.r.o ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: fedora libbpf upgrade to 1.0
On Fri, Nov 11, 2022 at 12:04 PM Jiri Olsa wrote: > > On Fri, Nov 04, 2022 at 09:59:49AM +0100, Jiri Olsa wrote: > > hi, > > I'm upgrading libbpf to 1.0 and because it's changing the soname it > > requires changes in dependent packages. > > > > You're receiving this email because you're maintainer of one of those > > packages (if not please kindly forward this to the maintainer). > > > > Following the guidelines for such upgrade in: > > > > https://docs.fedoraproject.org/en-US/package-maintainers/Package_Update_Guide/#updating_inter_dependent_packages > > > > I need to create a side tag and build new libbpf and all its users in > > that. After that it will get submitted to bodhi and it will happen ;-) > > > > > > I created side tag 'f38-build-side-59808': > > https://koji.fedoraproject.org/koji/taginfo?tagID=59808 > > > > and it has libbpf 1.0 built in: > > https://koji.fedoraproject.org/koji/taskinfo?taskID=93681960 > > > > I was able to build following packages with that: > > > > - dpdk > > - iproute > > - pcp > > - kernel-tools > > - qemu > > - xdp-tools > > > > and I can make the change myself for them (please scream if you want > > to do it yourself) > > > > I was NOT able to build following packages with libbpf 1.0: > > > >- bcc (needs 0.25 update first) > >- bpftrace (needs bcc update first) > >- below > >- knot > >- rust-libbpf-cargo > >- openvswitch > >- suricata > > > > and I'd need to ask to help with them.. which means: > > > > - adjust your package to build with libbpf 1.0 > > - build your package for 'f38-build-side-59808' > > > > > > Please note the side tag was created on Nov 4th and it seems it will > > be removed in 30 days. > > heya, > > as of today packages done: > xdp-tools > iproute > bcc > bpftrace > > > packages still need to be updated: > dpdk > iproute > pcp > kernel-tools > qemu > below > knot > rust-libbpf-cargo > openvswitch > suricata > > I'll need above owners to actually update the packages, > because I don't have rights to do that kernel-tools is done. thanks, Justin > thanks, > jirka > ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F38 proposal: Reproducible builds: Clamp build mtimes to $SOURCE_DATE_EPOCH (System-Wide Change proposal)
On Fri, 2022-11-11 at 12:42 -0500, Colin Walters wrote: > > On Fri, Nov 11, 2022, at 5:53 AM, Petr Pisar wrote: > > > > Wouldn't be easier to admit that timesamps are nonsense and simply eradicate > > all of them stamps from various data formats rather than trying to fake > > them? > > Simply changing rpmbuild to set timestamp to 0 for all contained files, or > > removing the time attribute from the RPM format completely? > > This is what ostree has done since its inception. And it broke some software, I know because i had to fix it. Simo. -- Simo Sorce RHEL Crypto Team Red Hat, Inc ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: SPDX Change update
On 11-11-2022 19:17, Miro Hrončok wrote: On 11. 11. 22 17:24, Sandro wrote: I'm not quite sure why pulling in an additional supplemental dependency would be considered a breaking change. Is it because rpmlint behaves differently with the new license definitions? Yes. Suppose I am running a Fedora 36 system with rpmlint installed and I use it to validate spec files for RHEL 9. When I install rpmlint-fedora-license-data, a huge bulk of licenses that were not valid when I started to use Fedora 36 and that are not valid for RHEL 9 are suddenly valid. That begs the question of how exactly to handle this specific case. I just installed rpmlint-fedora-license-data. Starting with F38 rpmlint will pull in rpmlint-fedora-license-data. How is one to provide a spec file for both Fedora and RHEL, if the valid license strings differ? (I am not saying that we should never backport the dependency ever, I am just explaining why it was not done in the past. If the consensus is that the hard dependency is easier to our users that validate Fedora spec files, and that this level of backwards compatibility is not worth it, that's alright with me.) I'm not seeking justification. I'm well aware that there are multiple use cases to consider and options to weigh. I was trying to understand why rpmlint would (still) warn about invalid licenses, though the SPDX licenses are accepted in all current releases and should be used for all new packages. I was blissfully unaware of the existence of rpmlint-fedora-license-data until today. -- Sandro ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: SPDX Change update
On 11. 11. 22 17:24, Sandro wrote: I'm not quite sure why pulling in an additional supplemental dependency would be considered a breaking change. Is it because rpmlint behaves differently with the new license definitions? Yes. Suppose I am running a Fedora 36 system with rpmlint installed and I use it to validate spec files for RHEL 9. When I install rpmlint-fedora-license-data, a huge bulk of licenses that were not valid when I started to use Fedora 36 and that are not valid for RHEL 9 are suddenly valid. (I am not saying that we should never backport the dependency ever, I am just explaining why it was not done in the past. If the consensus is that the hard dependency is easier to our users that validate Fedora spec files, and that this level of backwards compatibility is not worth it, that's alright with me.) -- 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, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F38 proposal: Reproducible builds: Clamp build mtimes to $SOURCE_DATE_EPOCH (System-Wide Change proposal)
On Fri, Nov 11, 2022, at 5:53 AM, Petr Pisar wrote: > > Wouldn't be easier to admit that timesamps are nonsense and simply eradicate > all of them stamps from various data formats rather than trying to fake them? > Simply changing rpmbuild to set timestamp to 0 for all contained files, or > removing the time attribute from the RPM format completely? This is what ostree has done since its inception. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[rpms/perl-Tie-DataUUID] PR #1: Package tests and update license to SPDX format
mspacek merged a pull-request against the project: `perl-Tie-DataUUID` that you are following. Merged pull-request: `` Package tests and update license to SPDX format `` https://src.fedoraproject.org/rpms/perl-Tie-DataUUID/pull-request/1 ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: webkit2gtk5.0 -> webkitgtk6.0
OK, I think telegram-desktop will actually be fine with no changes. When webkit2gtk-5.0 disappears, it should just fall back to using the stable GTK 3 version instead of the unstable GTK 4 version, which is probably a good idea for now. If you really want to use the GTK 4 API before it's stable, then LoadLibrary(webkit2gtk, "libwebkit2gtk-5.0.so.0" should be replaced with "libwebkitgtk-6.0.so.0" and incremented for each soname bump. There will probably be 2-3 soname bumps during the next 3 months or so. Then, if all goes well, we'll freeze the API and it will be stable indefinitely, like webkit2gtk-4.0 and webkit2gtk-4.1 are currently. If I fail to stabilize the API, then it could take until F39, but the goal is F38. I also looked closer at the code that's loading deprecated JSC functions that will be removed, and it looks like it's designed to load the deprecated functions only if the newer alternatives are not available at all, so I think that should be fine too. Michael ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[rpms/perl-Tie-DataUUID] PR #1: Package tests and update license to SPDX format
mspacek opened a new pull-request against the project: `perl-Tie-DataUUID` that you are following: `` Package tests and update license to SPDX format `` To reply, visit the link below https://src.fedoraproject.org/rpms/perl-Tie-DataUUID/pull-request/1 ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: webkit2gtk5.0 -> webkitgtk6.0
On Fri, Nov 11, 2022 at 11:44 AM Michael Catanzaro wrote: > > On Fri, Nov 11 2022 at 05:10:03 PM +0100, Vitaly Zaitsev via devel > wrote: > > What about packages that use dlopen() like Telegram Desktop? > > Uh-oh, I didn't know about this... I did a repoquery and thought only > GNOME was using it. :/ I guess this will require more coordination > after all. I found the code here: > > https://github.com/desktop-app/lib_webview/blob/b9d81771a0d7533dd07805f0618193277715da80/webview/platform/linux/webview_linux_webkit_gtk.cpp#L45 > > We'll have to patch the library version there and include a new build > in the side tag. And it's going to break on every WebKitGTK update for > the foreseeable future, because webkitgtk-6.0 will receive regular > soname bumps until the API stabilizes. (The goal is for it to be stable > in time for Fedora 38, but we'll see.) > > I also see that it's loading deprecated JavaScriptCore APIs, which will > break soon, see https://bugs.webkit.org/show_bug.cgi?id=232078. > > I wasn't able to figure out the Fedora package name to contact the > maintainer. Do you know what it is? > It's telegram-desktop in RPM Fusion: https://koji.rpmfusion.org/koji/packageinfo?packageID=492 Vitaly Zaitsev is the maintainer. It hasn't moved to Fedora yet. -- 真実はいつも一つ！/ Always, there's only one truth! ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: webkit2gtk5.0 -> webkitgtk6.0
On Fri, Nov 11 2022 at 05:10:03 PM +0100, Vitaly Zaitsev via devel wrote: What about packages that use dlopen() like Telegram Desktop? Uh-oh, I didn't know about this... I did a repoquery and thought only GNOME was using it. :/ I guess this will require more coordination after all. I found the code here: https://github.com/desktop-app/lib_webview/blob/b9d81771a0d7533dd07805f0618193277715da80/webview/platform/linux/webview_linux_webkit_gtk.cpp#L45 We'll have to patch the library version there and include a new build in the side tag. And it's going to break on every WebKitGTK update for the foreseeable future, because webkitgtk-6.0 will receive regular soname bumps until the API stabilizes. (The goal is for it to be stable in time for Fedora 38, but we'll see.) I also see that it's loading deprecated JavaScriptCore APIs, which will break soon, see https://bugs.webkit.org/show_bug.cgi?id=232078. I wasn't able to figure out the Fedora package name to contact the maintainer. Do you know what it is? Michael ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Self Introduction: Simon Bachenberg
On 11/11/22 3:15 AM, Simon Bachenberg wrote: Ideally, I would like Fedora to become the standard Linux client of the Deutsche Welle instead of Ubuntu. But I would also like to help make Fedora even better and more popular. Welcome Simon. I agree with you and I am glad you have joined us. :) Joe -- Joe Doss j...@solidadmin.com ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F38 prospoal: Enable bootupd for Fedora Silverblue & Kinoite (Self-Contained Change proposal)
> As we've talked about before, it's not possible to make updates > transactional. It involves, per spec and depending on processor > architecture, updating multiple files in different directories, > potentially on different filesystems entirely, one of which is fat32. I should probably have used only 'safe' here. My understanding of the "fallback work" was that with it, we could do updates automatically and retry them after failures without risking ending up in a state where we have no working bootloader. The update process would look like this: 1. Verify current bootloader hash 2. Fix it if not good 3. Copy current version to fallback 4. Update bootloader to new version What I've indeed forgotten to specify is that this only applies to EFI (so probably only x86 & aarch64) for now as that's what's implemented in bootupd. Am I missing something? > What's the plan to apply the outstanding security updates (shim, grub2, > and dbx push from June) to fedora silverblue 36 + 37 that aren't covered > by this change? We definitely want to backport all that to F36/37. This will only be possible for changes not in Anaconda, as we don't respin the installers. I'm not 100% sur yet we'll need Anaconda changes but mentioning it here in case it turns out we do. Thanks for the comments, I'll update the proposal. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: SPDX Change update
On Fri, Nov 11, 2022 at 11:24 AM Sandro wrote: > > On 11-11-2022 13:56, Miro Hrončok wrote: > > On 11. 11. 22 13:07, Sandro wrote: > >> On 11-11-2022 10:33, Neal Gompa wrote: > >>> On Fri, Nov 11, 2022 at 4:32 AM Neal Gompa wrote: > > On Fri, Nov 11, 2022 at 4:18 AM Sandro wrote: > > > > On 11-11-2022 10:12, Neal Gompa wrote: > >> On Fri, Nov 11, 2022 at 4:10 AM Sandro wrote: > >>> > >>> On 08-11-2022 15:06, David Cantrell wrote: > On Tue, Nov 08, 2022 at 09:45:57AM +, Richard W.M. Jones wrote: > > Should new package reviews (for Rawhide) now be rejected if they > > don't have SPDX tags? > > Yes, new packages going forward should use SPDX expressions in the > License tag. > >>> > >>> When will rpmlint be updated to correctly recognize SPDX license > >>> tags? I > >>> don't see it as part of the change proposal. > >>> > >>> Right now it throws a warning, e.g.: W: invalid-license GPL-3.0-only. > >> > >> Does it go away when you install rpmlint-fedora-license-data? > > > > It does. Thanks for the pointer. So, I guess rpmlint should depend on > > it? > > > > I will add a Recommends to it. > > >>> > >>> Actually, looks like this has been done a while ago: > >>> https://src.fedoraproject.org/rpms/rpmlint/c/9c506b5c4fe457944fbbfd51dec5a3f663995cdf > >> > >> That change has only been pushed to rawhide. I tent to verify my packages > >> on a > >> current release, currently either f35 or f36. My f35 machine will be > >> upgraded > >> to f37 in the near future. But even in f37 rpmlint-fedora-license-data is > >> not > >> required by rpmlint. > >> > >> Simply adding 'Requires: rpmlint-fedora-license-data' to rpmlint.spec for > >> the > >> current release branches should be sufficient, seeing that installing > >> rpmlint-fedora-license-data manually solves the false warning. > > > > rpmlint-fedora-license-data already Supplements rpmlint. Adding the > > requirement > > might be considered as a breaking change, so we only did it in rawhide. > > Hmm. But somehow this weak dependency seems to be too weak to be pulled > in on update. So, it's of no use if rpmlint is already installed. > > I'm not quite sure why pulling in an additional supplemental dependency > would be considered a breaking change. Is it because rpmlint behaves > differently with the new license definitions? > Supplements no longer affect already-installed packages, so that's why it didn't get pulled in. -- 真実はいつも一つ！/ Always, there's only one truth! ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: SPDX Change update
On 11-11-2022 13:56, Miro Hrončok wrote: On 11. 11. 22 13:07, Sandro wrote: On 11-11-2022 10:33, Neal Gompa wrote: On Fri, Nov 11, 2022 at 4:32 AM Neal Gompa wrote: On Fri, Nov 11, 2022 at 4:18 AM Sandro wrote: On 11-11-2022 10:12, Neal Gompa wrote: On Fri, Nov 11, 2022 at 4:10 AM Sandro wrote: On 08-11-2022 15:06, David Cantrell wrote: On Tue, Nov 08, 2022 at 09:45:57AM +, Richard W.M. Jones wrote: Should new package reviews (for Rawhide) now be rejected if they don't have SPDX tags? Yes, new packages going forward should use SPDX expressions in the License tag. When will rpmlint be updated to correctly recognize SPDX license tags? I don't see it as part of the change proposal. Right now it throws a warning, e.g.: W: invalid-license GPL-3.0-only. Does it go away when you install rpmlint-fedora-license-data? It does. Thanks for the pointer. So, I guess rpmlint should depend on it? I will add a Recommends to it. Actually, looks like this has been done a while ago: https://src.fedoraproject.org/rpms/rpmlint/c/9c506b5c4fe457944fbbfd51dec5a3f663995cdf That change has only been pushed to rawhide. I tent to verify my packages on a current release, currently either f35 or f36. My f35 machine will be upgraded to f37 in the near future. But even in f37 rpmlint-fedora-license-data is not required by rpmlint. Simply adding 'Requires: rpmlint-fedora-license-data' to rpmlint.spec for the current release branches should be sufficient, seeing that installing rpmlint-fedora-license-data manually solves the false warning. rpmlint-fedora-license-data already Supplements rpmlint. Adding the requirement might be considered as a breaking change, so we only did it in rawhide. Hmm. But somehow this weak dependency seems to be too weak to be pulled in on update. So, it's of no use if rpmlint is already installed. I'm not quite sure why pulling in an additional supplemental dependency would be considered a breaking change. Is it because rpmlint behaves differently with the new license definitions? -- Sandro ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F38 proposal: Reproducible builds: Clamp build mtimes to $SOURCE_DATE_EPOCH (System-Wide Change proposal)
V Fri, Nov 11, 2022 at 02:05:11PM +0100, Miro Hrončok napsal(a): > > > As a result, more RPM packages will be reproducible: > > > > Where will this reproducibility stop? An RPM package itself carry a build > > time in its RPM header. Are we also going to fake this time in the name of > > reproducibility? > > Not as part of this change proposal and I have no intention to propose such > a thing. > Then a goal of this change cannot be a reproducible RPM package. We could rather speak about reproducible cpio archives inside the RPM packages. > > What value these faked timestamps have? E.g. a compiled file is a function > > not > > only of its source, but also of the compiler. This proposed change removes > > the compiler part from the timestamp. Will timestamps like this be helpful? > > Are the current timestamps helpful? > None of the timestamps are reliable. But a universe where two versions of a file have the same timestamp but a different content violates my perception of time. It's connected to the tracability touched by Alexander. > > Wouldn't be easier to admit that timesamps are nonsense and simply eradicate > > all of them stamps from various data formats rather than trying to fake > > them? > > I don't think it would be easier, but I have not tried that. > > > Simply changing rpmbuild to set timestamp to 0 for all contained files, or > > removing the time attribute from the RPM format completely? > > RPM does not currently support this. RPM currently supports mtime clamping > which is what we have proposed. You seem to not like the idea but you don't > say so explicitly. If you prefer status quo over this change and would > rather see the proposal rejected, please say so, so FESCo can evaluate your > feedback when voting about the proposal. > I asked all the questions because I think it's quite convoluted way to reproducible builds. If the purpose is just normalize timestamps to a release date of the package, then fine. I didn't write explicitly that I don't like this change, because I can see some advantages of it. I'm only not convinced, wheter loosing advatages of the current systems is worth of it. -- 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, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: webkit2gtk5.0 -> webkitgtk6.0
On 11/11/2022 17:05, Michael Catanzaro wrote: The webkit2gtk5.0 package in rawhide will be removed and replaced by webkitgtk6.0. Affected packages that will need to be patched to use the new API version What about packages that use dlopen() like Telegram Desktop? -- Sincerely, Vitaly Zaitsev (vit...@easycoding.org) ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
webkit2gtk5.0 -> webkitgtk6.0
Hi, The webkit2gtk5.0 package in rawhide will be removed and replaced by webkitgtk6.0. Affected packages that will need to be patched to use the new API version and rebuilt are: evolution-data-server, gnome-builder, gnome-initial-setup. My plan is to handle all of these builds in a side tag. Normally we're supposed to wait a week before making changes like this, but since I have commit access to care for all the dependent packages, I assume it should be fine to go ahead sooner. Michael ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Direct to stable updates
On Fri, 11 Nov 2022 at 10:19, Kevin Kofler via devel < devel@lists.fedoraproject.org> wrote: > Stephen Smoogen wrote: > > You can only refactor it when you have a steady set of requirements. The > > code has been 'refactored' at least 4 times but what happens is that you > > will get into about 1/3rd of the way into it and find you have now to add > > a bunch of new requirements. > > Sounds like pretty much what I had guessed. ;-) > > So I think it would really help if Bodhi were to become more of an > enabling > tool and less of an enforcing tool again. Package maintainers have this > wonderful organ between their ears that allows them to know better what is > best for their packages than some piece of software, no matter how much > complexity we force that software's maintainers to add to the latter. :-) > > Pretty much every one of those bodhi requirements is because either * a developer did not use that wonderful organ for some reason, and people said 'that should never happen again.' * what the developer decided was not liked by other developers enough that it was decided 'that should never happen again.' Look back on the 15-20 years of fedora devel emails and see how many times someone has said that something should never happen. Guess what? Enough other developers agreed at times, and decided it needed to be automated because the other big old complaint was about how long it took for people to review things and how prone to failure was also true. -- Stephen Smoogen, Red Hat Automotive Let us be kind to one another, for most of us are fighting a hard battle. -- Ian MacClaren ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F38 proposal: Reproducible builds: Clamp build mtimes to $SOURCE_DATE_EPOCH (System-Wide Change proposal)
On Fri, Nov 11, 2022 at 8:46 AM Clemens Lang wrote: > > Hi, > > Alexander Sosedkin wrote: > > > In RPM world, I've even entertained an idea of having a subpackage for > > auditability not unlike how we have debuginfo, since rebuilding a package > > reproducibly requires builddep pinning. But if that's avoidable, I’d > > rather just not mix artifacts with meta. > > Debian is working on this already, they call those “buildinfo” files: > >https://wiki.debian.org/ReproducibleBuilds/BuildinfoFiles >https://manpages.debian.org/testing/dpkg-dev/deb-buildinfo.5.en.html > > If we want something similar, I’d propose not to completely re-invent the > wheel. > We've discussed an RPM-specific format upstream. Debian and Arch both have their own formats that are tailored to their package systems, and RPM may have one too, eventually. -- 真実はいつも一つ！/ Always, there's only one truth! ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: OpenMPI tests blocked
On 11/11/22 07:52, Christoph Junghans wrote: On Thu, Nov 10, 2022 at 10:27 PM Orion Poplawski wrote: On 11/6/22 07:31, Dominik 'Rathann' Mierzejewski wrote: On Saturday, 05 November 2022 at 21:27, Antonio T. sagitter wrote: Hi all. Many OpenMPI tests in RPM packaging are blocked for unknown reason, no output or error, just hanged until test timeout. For example, PETSc test is blocked with this message: Executing: /usr/lib64/openmpi/bin/mpiexec -n 8 --mca btl_base_warn_component_unused 0 -n 1 /tmp/petsc-p7fo3olx/config.packages.MPI/conftest Running Executable with threads to time it out at 120 Executing: /usr/lib64/openmpi/bin/mpiexec -n 8 --mca btl_base_warn_component_unused 0 -n 1 /tmp/petsc-p7fo3olx/config.packages.MPI/conftest Runaway process exceeded time limit of 120 ERROR while running executable: Could not execute "['/usr/lib64/openmpi/bin/mpiexec -n 8 --mca btl_base_warn_component_unused 0 -n 1 /tmp/petsc-p7fo3olx/config.packages.MPI/conftest']": Runaway process exceeded time limit of 120 Something like this happened with Sundials and Ipopt, when OpenMPI is used, not with MPICH. At this time, these tests in Rawhide (and ELN) cannot be executed. I've got the same issue with elpa. OpenMPI hangs, MPICH works fine. Let's open a bug against OpenMPI and compare notes. ;) Regards, Dominik We have: https://bugzilla.redhat.com/show_bug.cgi?id=2141137 I've reported it upstream as well. Hopefully they can help. openSUSE had a similar bug: https://bugzilla.opensuse.org/show_bug.cgi?id=1205139 Maybe that is related. Christoph Thank you! I believe that is it exactly. -- Orion Poplawski he/him/his - surely the least important thing about me IT Systems Manager 720-772-5637 NWRA, Boulder/CoRA Office FAX: 303-415-9702 3380 Mitchell Lane or...@nwra.com Boulder, CO 80301 https://www.nwra.com/ smime.p7s Description: S/MIME Cryptographic Signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[Bug 2142076] perltidy-20221112 is available
https://bugzilla.redhat.com/show_bug.cgi?id=2142076 Fedora Update System changed: What|Removed |Added Status|MODIFIED|CLOSED Resolution|--- |ERRATA Fixed In Version||perltidy-20221112-1.fc38 Last Closed||2022-11-11 14:57:18 --- Comment #4 from Fedora Update System --- FEDORA-2022-d659d3c835 has been pushed to the Fedora 38 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=2142076 ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[Bug 2142076] perltidy-20221112 is available
https://bugzilla.redhat.com/show_bug.cgi?id=2142076 Fedora Update System changed: What|Removed |Added Status|NEW |MODIFIED --- Comment #3 from Fedora Update System --- FEDORA-2022-d659d3c835 has been submitted as an update to Fedora 38. https://bodhi.fedoraproject.org/updates/FEDORA-2022-d659d3c835 -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2142076 ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: OpenMPI tests blocked
On Thu, Nov 10, 2022 at 10:27 PM Orion Poplawski wrote: > > On 11/6/22 07:31, Dominik 'Rathann' Mierzejewski wrote: > > On Saturday, 05 November 2022 at 21:27, Antonio T. sagitter wrote: > >> Hi all. > >> > >> Many OpenMPI tests in RPM packaging are blocked for unknown reason, no > >> output or error, just hanged until test timeout. > >> For example, PETSc test is blocked with this message: > >> > >> > >> Executing: /usr/lib64/openmpi/bin/mpiexec -n 8 --mca > >> btl_base_warn_component_unused 0 -n 1 > >> /tmp/petsc-p7fo3olx/config.packages.MPI/conftest > >> Running Executable with threads to time it out at 120 > >> Executing: /usr/lib64/openmpi/bin/mpiexec -n 8 --mca > >> btl_base_warn_component_unused 0 -n 1 > >> /tmp/petsc-p7fo3olx/config.packages.MPI/conftest > >> Runaway process exceeded time limit of 120 > >> ERROR while running executable: Could not execute > >> "['/usr/lib64/openmpi/bin/mpiexec -n 8 --mca btl_base_warn_component_unused > >> 0 -n 1 /tmp/petsc-p7fo3olx/config.packages.MPI/conftest']": > >> Runaway process exceeded time limit of 120 > >> > >> Something like this happened with Sundials and Ipopt, when OpenMPI is used, > >> not with MPICH. > >> > >> At this time, these tests in Rawhide (and ELN) cannot be executed. > > > > I've got the same issue with elpa. OpenMPI hangs, MPICH works fine. > > Let's open a bug against OpenMPI and compare notes. ;) > > > > Regards, > > Dominik > > We have: > > https://bugzilla.redhat.com/show_bug.cgi?id=2141137 > > I've reported it upstream as well. Hopefully they can help. openSUSE had a similar bug: https://bugzilla.opensuse.org/show_bug.cgi?id=1205139 Maybe that is related. Christoph > > -- > Orion Poplawski > he/him/his - surely the least important thing about me > IT Systems Manager 720-772-5637 > NWRA, Boulder/CoRA Office FAX: 303-415-9702 > 3380 Mitchell Lane or...@nwra.com > Boulder, CO 80301 https://www.nwra.com/ > > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > Do not reply to spam, report it: > https://pagure.io/fedora-infrastructure/new_issue -- Christoph Junghans Web: http://www.compphys.de ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F38 proposal: Reproducible builds: Clamp build mtimes to $SOURCE_DATE_EPOCH (System-Wide Change proposal)
* Alexander Sosedkin: > On Fri, Nov 11, 2022 at 2:03 PM Florian Weimer wrote: >> >> * Alexander Sosedkin: >> >> > On Fri, Nov 11, 2022 at 11:53 AM Petr Pisar wrote: >> >> An RPM package itself carry a build time in its RPM header. >> >> Are we also going to fake this time in the name of >> >> reproducibility? >> > >> > My opinion: yes, please do (%use_source_date_epoch_as_buildtime). >> > And fake the builder hostname (%_buildhost). >> > And enable back --enable-deterministic-archives in binutils: >> > (https://bugzilla.redhat.com/show_bug.cgi?id=1195883). >> > And do whatever else is necessary to stop shipping binary packages >> > that users can't reproduce bit-to-bit. >> >> The downside of doing this is that it's no longer possible to check >> whether a build happened against a buildroot with a particular fix in >> it. The time-based check was never 100% reliable, but it could be used >> as a good indicator in the past. > > No, no, false dichotomy alert. > This is not a case where reproducibility rules out auditability. Sure, not in principle. I merely wanted to point out that this takes a way a bit of information that was useful to some of us before. 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, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Direct to stable updates
Stephen Smoogen wrote: > You can only refactor it when you have a steady set of requirements. The > code has been 'refactored' at least 4 times but what happens is that you > will get into about 1/3rd of the way into it and find you have now to add > a bunch of new requirements. Sounds like pretty much what I had guessed. ;-) So I think it would really help if Bodhi were to become more of an enabling tool and less of an enforcing tool again. Package maintainers have this wonderful organ between their ears that allows them to know better what is best for their packages than some piece of software, no matter how much complexity we force that software's maintainers to add to the latter. :-) 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, report it: https://pagure.io/fedora-infrastructure/new_issue
[Bug 2142076] perltidy-20221112 is available
https://bugzilla.redhat.com/show_bug.cgi?id=2142076 --- Comment #2 from Upstream Release Monitoring --- the-new-hotness/release-monitoring.org's scratch build of perltidy-20221112-1.fc36.src.rpm for rawhide completed http://koji.fedoraproject.org/koji/taskinfo?taskID=94052350 -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2142076 ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[Bug 2142076] New: perltidy-20221112 is available
https://bugzilla.redhat.com/show_bug.cgi?id=2142076 Bug ID: 2142076 Summary: perltidy-20221112 is available Product: Fedora Version: rawhide Status: NEW Component: perltidy Keywords: FutureFeature, Triaged Assignee: p...@city-fan.org Reporter: upstream-release-monitor...@fedoraproject.org QA Contact: extras...@fedoraproject.org CC: lxt...@gmail.com, p...@city-fan.org, perl-devel@lists.fedoraproject.org Target Milestone: --- Classification: Fedora Releases retrieved: 20221112 Upstream release that is considered latest: 20221112 Current version/release in rawhide: 2022-1.fc38 URL: http://search.cpan.org/dist/Perl-Tidy/ Please consult the package updates policy before you issue an update to a stable branch: https://docs.fedoraproject.org/en-US/fesco/Updates_Policy/ More information about the service that created this bug can be found at: https://docs.fedoraproject.org/en-US/package-maintainers/Upstream_Release_Monitoring Please keep in mind that with any upstream change, there may also be packaging changes that need to be made. Specifically, please remember that it is your responsibility to review the new version to ensure that the licensing is still correct and that no non-free or legally problematic items have been added upstream. Based on the information from Anitya: https://release-monitoring.org/project/3553/ To change the monitoring settings for the project, please visit: https://src.fedoraproject.org/rpms/perltidy -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2142076 ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[Bug 2142076] perltidy-20221112 is available
https://bugzilla.redhat.com/show_bug.cgi?id=2142076 --- Comment #1 from Upstream Release Monitoring --- Created attachment 1923781 --> https://bugzilla.redhat.com/attachment.cgi?id=1923781=edit Update to 20221112 (#2142076) -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2142076 ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[Bug 2134967] perl-Mojolicious-9.29 is available
https://bugzilla.redhat.com/show_bug.cgi?id=2134967 Upstream Release Monitoring changed: What|Removed |Added Summary|perl-Mojolicious-9.28 is|perl-Mojolicious-9.29 is |available |available --- Comment #2 from Upstream Release Monitoring --- Releases retrieved: 9.29 Upstream release that is considered latest: 9.29 Current version/release in rawhide: 9.27-1.fc38 URL: https://metacpan.org/release/Mojolicious Please consult the package updates policy before you issue an update to a stable branch: https://docs.fedoraproject.org/en-US/fesco/Updates_Policy/ More information about the service that created this bug can be found at: https://docs.fedoraproject.org/en-US/package-maintainers/Upstream_Release_Monitoring Please keep in mind that with any upstream change, there may also be packaging changes that need to be made. Specifically, please remember that it is your responsibility to review the new version to ensure that the licensing is still correct and that no non-free or legally problematic items have been added upstream. Based on the information from Anitya: https://release-monitoring.org/project/5966/ To change the monitoring settings for the project, please visit: https://src.fedoraproject.org/rpms/perl-Mojolicious -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2134967 ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F38 proposal: Reproducible builds: Clamp build mtimes to $SOURCE_DATE_EPOCH (System-Wide Change proposal)
Hi, Alexander Sosedkin wrote: In RPM world, I've even entertained an idea of having a subpackage for auditability not unlike how we have debuginfo, since rebuilding a package reproducibly requires builddep pinning. But if that's avoidable, I’d rather just not mix artifacts with meta. Debian is working on this already, they call those “buildinfo” files: https://wiki.debian.org/ReproducibleBuilds/BuildinfoFiles https://manpages.debian.org/testing/dpkg-dev/deb-buildinfo.5.en.html If we want something similar, I’d propose not to completely re-invent the wheel. HTH, Clemens ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F38 proposal: Reproducible builds: Clamp build mtimes to $SOURCE_DATE_EPOCH (System-Wide Change proposal)
On 11. 11. 22 14:18, Barry wrote: Change log has the date of a change but no time. What time of day and timezone is used? 00:00:00 UTC? Changelogs can have times as well. When they don't, they are considered 12:00 (noon) UTC: https://github.com/rpm-software-management/rpm/blob/rpm-4.18.0-release/build/parseChangelog.c#L33 https://github.com/rpm-software-management/rpm/blob/rpm-4.18.0-release/build/parseChangelog.c#L145 -- 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, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F38 proposal: Reproducible builds: Clamp build mtimes to $SOURCE_DATE_EPOCH (System-Wide Change proposal)
On Fri, Nov 11, 2022 at 2:03 PM Florian Weimer wrote: > > * Alexander Sosedkin: > > > On Fri, Nov 11, 2022 at 11:53 AM Petr Pisar wrote: > >> An RPM package itself carry a build time in its RPM header. > >> Are we also going to fake this time in the name of > >> reproducibility? > > > > My opinion: yes, please do (%use_source_date_epoch_as_buildtime). > > And fake the builder hostname (%_buildhost). > > And enable back --enable-deterministic-archives in binutils: > > (https://bugzilla.redhat.com/show_bug.cgi?id=1195883). > > And do whatever else is necessary to stop shipping binary packages > > that users can't reproduce bit-to-bit. > > The downside of doing this is that it's no longer possible to check > whether a build happened against a buildroot with a particular fix in > it. The time-based check was never 100% reliable, but it could be used > as a good indicator in the past. No, no, false dichotomy alert. This is not a case where reproducibility rules out auditability. Not only build system (koji) can track exact versions of builddeps (and if it doesn't, it really should, regardless of reproducibility), I'm not against including builddep versions into the artifacts, in any form, as long as it's done in a reproducible manner. E.g., I have no problem with NixOS having them hashed and used as the installation prefix, not at all. In RPM world, I've even entertained an idea of having a subpackage for auditability not unlike how we have debuginfo, since rebuilding a package reproducibly requires builddep pinning. But if that's avoidable, I'd rather just not mix artifacts with meta. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F38 proposal: Reproducible builds: Clamp build mtimes to $SOURCE_DATE_EPOCH (System-Wide Change proposal)
> On 10 Nov 2022, at 20:24, Ben Cotton wrote: > > https://fedoraproject.org/wiki/Changes/ReproducibleBuildsClampMtimes > > 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 == > > The `%clamp_mtime_to_source_date_epoch` RPM macro will be set to `1`. > When an RPM package is built, mtimes of packaged files will be clamped > to `$SOURCE_DATE_EPOCH` which is already set to the date of the latest > `%changelog` entry. As a result, more RPM packages will be > reproducible: The actual modification time of files that are e.g. > modified in the `%prep` section or built in the `%build` section will > not be reflected in the resulting RPM packages. Files in RPM packages > will have mtimes that are independent of the time of the actual build. > > == Owner == > * Name: [[User:Churchyard|Miro Hrončok]], [[User:Zbyszek|Zbigniew > Jędrzejewski-Szmek]] > * Email: mhroncok at redhat.com, zbyszek at in.waw.pl > > > == Detailed Description == > This change exists to make RPM package builds more reproducible. A > common problem that prevents [https://reproducible-builds.org/ build > reproducibility] is the mtime (modification times) of the packaged > files. > > Suppose we package an RPM package of software called `skynet` in > version `1.0`. Upstream released this version at datetime A. A Fedora > packager creates the RPM package at datetime B. Unfortunately, the > packager needs to patch the sources in the RPM `%prep` section. When > the build runs at datetime C, the modification datetime of the patched > file is set to C. When the build runs again in an otherwise identical > environment at datetime D, the modification datetime of the patched > file is set to D. As a result, the build is not bit-by-bit > reproducible, because the datetime of the build is saved in the > resulting package. > Patching is not necessary to make this happen. When a source file is > compiled into a binary file, the modification datetime is also set to > the datetime of the build. In practice, the modification datetime of > many files packaged in RPM packages is dependent on when the package > was actually built. > > To eliminate this problem, we propose to clamp build mtimes to > `$SOURCE_DATE_EPOCH`. RPM build in Fedora already sets the > `$SOURCE_DATE_EPOCH` environment variable based on the latest > `%changelog` entry because the `%source_date_epoch_from_changelog` > macro is set to `1` Change log has the date of a change but no time. What time of day and timezone is used? 00:00:00 UTC? Barry > . We will also set the > `%clamp_mtime_to_source_date_epoch` macro to `1`. As a result, when > files are packaged to the RPM package, their modification datetimes > will be clamped to `$SOURCE_DATE_EPOCH` (to the latest changelog entry > datetime). Clamping means that all files which would otherwise have a > modification datetime higher than `$SOURCE_DATE_EPOCH` will have the > modification datetime changed to `$SOURCE_DATE_EPOCH`; files with > mtime lower (or equal) to `$SOURCE_DATE_EPOCH` will retain the > original mtimes. > > This functionality is already implemented in RPM. We will enable it by > setting `%clamp_mtime_to_source_date_epoch` to `1`. > > === Non-goal === > > We do not aim to make all Fedora packages reproducible (at least not > as part of this change proposal). We just eliminate one problem that > we consider the biggest blocker for reproducible builds. > > === Python bytecode === > > When Python bytecode cache (a `.pyc` file) is built, the mtime of the > corresponding Python source file (`.py`) is included in it for > invalidation purposes. Since the `.pyc` file is created before RPM > clamps the mtime of the `.py` file, the mtime stored in the `.pyc` > file might be higher than the corresponding mtime of the `.py` file. > > With the previous example, if `skynet` is written in Python: > # `skynet.py` is modified in `%prep` and hence has mtime set to the > time of the build > # `skynet.pyc` is generated in `%install` and the mtime of `skynet.py` > is saved in it > # RPM clamps the mtime of `skynet.py` > # `skynet.pyc` is considered invalid by Python on runtime, as the > stored and actual mtime of `skynet.py` don't match > > To solve this, we will modify Python to clamp the stored mtime to > `$SOURCE_DATE_EPOCH` as well (when building RPM packages). Upstream > Python chooses to invalidate bytecode cache based on hashes instead of > mtimes when `$SOURCE_DATE_EPOCH` is set, but that could cause > performance issues for big files, so Fedora's Python already deviates > from upstream behavior when building RPM packages. To avoid > accidentally breaking the behavior when > `%clamp_mtime_to_source_date_epoch` is not set to `1`, RPM macros and > buildroot policy scripts for creating the Python bytecode cache
Re: F38 proposal: Perl: Replace versioned MODULE_COMPAT_ requires by macro (System-Wide Change proposal)
Something like this should work:
File: /usr/lib/rpm/fileattrs/perllib.attr
%__perllib_requires() %{lua:
if macros['1']:match('.+%.so$') and macros.perl_version then
print('perl(:MODULE_COMPAT_' .. macros.perl_version .. ')')
else
print('perl-libs')
end
}
%__perllib_path ^(%{perl_vendorarch}|%{perl_vendorlib})/.+
(Untested.)
Thanks for hint. I'll check if it works for my change.
Jitka
--
Jitka Plesnikova
Senior Software Engineer
Red Hat
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
Re: F38 proposal: Reproducible builds: Clamp build mtimes to $SOURCE_DATE_EPOCH (System-Wide Change proposal)
On 11. 11. 22 11:53, Petr Pisar wrote: V Thu, Nov 10, 2022 at 03:23:49PM -0500, Ben Cotton napsal(a): https://fedoraproject.org/wiki/Changes/ReproducibleBuildsClampMtimes == Summary == The `%clamp_mtime_to_source_date_epoch` RPM macro will be set to `1`. When an RPM package is built, mtimes of packaged files will be clamped to `$SOURCE_DATE_EPOCH` Clamp as capping maximal mtime, or resetting mtime for all files? I.e. If I had a source file dated 1970-01-01 and installed it with "install -p", will the packaged file retain that 1970-01-01 date, or will it be set to the date of the latest changlog, e.g. 2022-11-11? In other words, will all files in a package have the same mtime, or there won't be an mtime newer than the changelog entry? Capping maximal mtime. It's actually described in the detailed description: """Clamping means that all files which would otherwise have a modification datetime higher than $SOURCE_DATE_EPOCH will have the modification datetime changed to $SOURCE_DATE_EPOCH; files with mtime lower (or equal) to $SOURCE_DATE_EPOCH will retain the original mtimes.""" Possibly "higher" should say "greater" instead, not sure. which is already set to the date of the latest `%changelog` entry. What's a changelog entry date in case of rpmautospec changelog? Is it a git AuthorDate or CommitDate? I don't know from top of my head. There's also https://pagure.io/fedora-infra/rpmautospec/issue/209 which touches this topic a bit. As a result, more RPM packages will be reproducible: Where will this reproducibility stop? An RPM package itself carry a build time in its RPM header. Are we also going to fake this time in the name of reproducibility? Not as part of this change proposal and I have no intention to propose such a thing. What value these faked timestamps have? E.g. a compiled file is a function not only of its source, but also of the compiler. This proposed change removes the compiler part from the timestamp. Will timestamps like this be helpful? Are the current timestamps helpful? Wouldn't be easier to admit that timesamps are nonsense and simply eradicate all of them stamps from various data formats rather than trying to fake them? I don't think it would be easier, but I have not tried that. Simply changing rpmbuild to set timestamp to 0 for all contained files, or removing the time attribute from the RPM format completely? RPM does not currently support this. RPM currently supports mtime clamping which is what we have proposed. You seem to not like the idea but you don't say so explicitly. If you prefer status quo over this change and would rather see the proposal rejected, please say so, so FESCo can evaluate your feedback when voting about the proposal. -- 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, report it: https://pagure.io/fedora-infrastructure/new_issue
[Bug 2130625] Please branch and build perl-Inline in epel9
https://bugzilla.redhat.com/show_bug.cgi?id=2130625 Fedora Update System changed: What|Removed |Added Status|ASSIGNED|MODIFIED --- Comment #2 from Fedora Update System --- FEDORA-EPEL-2022-a935feca4a has been submitted as an update to Fedora EPEL 9. https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2022-a935feca4a -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2130625 ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F38 proposal: Reproducible builds: Clamp build mtimes to $SOURCE_DATE_EPOCH (System-Wide Change proposal)
* Alexander Sosedkin: > On Fri, Nov 11, 2022 at 11:53 AM Petr Pisar wrote: >> An RPM package itself carry a build time in its RPM header. >> Are we also going to fake this time in the name of >> reproducibility? > > My opinion: yes, please do (%use_source_date_epoch_as_buildtime). > And fake the builder hostname (%_buildhost). > And enable back --enable-deterministic-archives in binutils: > (https://bugzilla.redhat.com/show_bug.cgi?id=1195883). > And do whatever else is necessary to stop shipping binary packages > that users can't reproduce bit-to-bit. The downside of doing this is that it's no longer possible to check whether a build happened against a buildroot with a particular fix in it. The time-based check was never 100% reliable, but it could be used as a good indicator in the past. 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, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Direct to stable updates
On Fri, 11 Nov 2022 at 02:34, Demi Marie Obenour wrote: > On 11/10/22 21:02, Gary Buhrmaster wrote: > > On Fri, Nov 11, 2022 at 12:52 AM Stephen Smoogen > wrote: > >> On Thu, Nov 10, 2022 at 18:55 Neal Gompa wrote: > >>> > >>> I sympathize greatly here. It was a pain to wire up "logout" to the > >>> "relogin" property in updateinfo (the field had been in bodhi for a > >>> decade and nobody wired it up to the appropriate rpm metadata field!). > >>> Bodhi is an unusually difficult codebase for what it does. > >>> > >> > >> From what I can tell is that every time someone says that and then > tries to fix it they find about 20 reasons why the code is not complex > enough for all the corner cases and “obvious” requirements that people > expect of it > >> > > > > The code is both too complex, and nowhere near complex > > enough. > > > > I really dislike code like that. > Time for some serious refactoring? > > You can only refactor it when you have a steady set of requirements. The code has been 'refactored' at least 4 times but what happens is that you will get into about 1/3rd of the way into it and find you have now to add a bunch of new requirements. You will still have to keep the old ones working also because of older releases. OK you have gotten to adding that and you find that the business logic has a major flaw in it that FPC and FESCO need to explain when they said 'SHOULD' in something, did they want it enforced in Bodhi or not.. oh wait it turns out they both disagree with each other. OK go do some other refactoring while that works out. Oh look another conflict and you now have to refactor in that the message bus is changed AND now you need to add in containers in 3 different formats made by different tools. And look 3 new tools need to be added into the logic. And two parts of the things you were told you had to call out to no longer exist.. And crap we are in freeze so nothing changes except fixing the little bugs you can. Freeze is over, deploy the stage and find out that production and stage don't match well enough because there isn't enough resources in people, time and servers to do a 1:1 stage/product environment. Crap crap crap.. need to get it all working before the mass rebuild.. put off all the refactoring for another month. Oh new requirements to add in. Repeat every 3-6 months until you are reassigned to a different project. -- Stephen Smoogen, Red Hat Automotive Let us be kind to one another, for most of us are fighting a hard battle. -- Ian MacClaren ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: SPDX Change update
On 11. 11. 22 13:07, Sandro wrote: On 11-11-2022 10:33, Neal Gompa wrote: On Fri, Nov 11, 2022 at 4:32 AM Neal Gompa wrote: On Fri, Nov 11, 2022 at 4:18 AM Sandro wrote: On 11-11-2022 10:12, Neal Gompa wrote: On Fri, Nov 11, 2022 at 4:10 AM Sandro wrote: On 08-11-2022 15:06, David Cantrell wrote: On Tue, Nov 08, 2022 at 09:45:57AM +, Richard W.M. Jones wrote: Should new package reviews (for Rawhide) now be rejected if they don't have SPDX tags? Yes, new packages going forward should use SPDX expressions in the License tag. When will rpmlint be updated to correctly recognize SPDX license tags? I don't see it as part of the change proposal. Right now it throws a warning, e.g.: W: invalid-license GPL-3.0-only. Does it go away when you install rpmlint-fedora-license-data? It does. Thanks for the pointer. So, I guess rpmlint should depend on it? I will add a Recommends to it. Actually, looks like this has been done a while ago: https://src.fedoraproject.org/rpms/rpmlint/c/9c506b5c4fe457944fbbfd51dec5a3f663995cdf That change has only been pushed to rawhide. I tent to verify my packages on a current release, currently either f35 or f36. My f35 machine will be upgraded to f37 in the near future. But even in f37 rpmlint-fedora-license-data is not required by rpmlint. Simply adding 'Requires: rpmlint-fedora-license-data' to rpmlint.spec for the current release branches should be sufficient, seeing that installing rpmlint-fedora-license-data manually solves the false warning. rpmlint-fedora-license-data already Supplements rpmlint. Adding the requirement might be considered as a breaking change, so we only did it in rawhide. -- 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, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F38 proposal: Perl: Replace versioned MODULE_COMPAT_ requires by macro (System-Wide Change proposal)
On 11. 11. 22 13:13, Miro Hrončok wrote:
Something like this should work:
File: /usr/lib/rpm/fileattrs/perllib.attr
%__perllib_requires() %{lua:
if macros['1']:match('.+%.so$') and macros.perl_version then
The quotes around 1 are actually redundant here, I've realized after sending
the email:
if macros[1]:match('.+%.so$') and macros.perl_version then
print('perl(:MODULE_COMPAT_' .. macros.perl_version .. ')')
else
print('perl-libs')
end
}
%__perllib_path ^(%{perl_vendorarch}|%{perl_vendorlib})/.+
(Untested.)
--
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, report it:
https://pagure.io/fedora-infrastructure/new_issue
Re: F38 proposal: Perl: Replace versioned MODULE_COMPAT_ requires by macro (System-Wide Change proposal)
On 10. 11. 22 21:57, Miro Hrončok wrote:
On 10. 11. 22 21:23, Ben Cotton wrote:
The macro ''%perl_require_compat'' will evaluate the run-require based
on ''%{_target_cpu}''. The macro will be defined in the rpm
''perl-srpm-macros'' and the definition is:
`%perl_require_compat %[ "%{_target_cpu}" == "noarch" ? "perl-libs" :
"%{!?perl_version:perl-libs}%{?perl_version:perl(:MODULE_COMPAT_%{perl_version})}"
]`
Jitka,
have you considered making this an RPM dependency generator instead? What are
the reasons not to use it?
Something like this should work:
File: /usr/lib/rpm/fileattrs/perllib.attr
%__perllib_requires() %{lua:
if macros['1']:match('.+%.so$') and macros.perl_version then
print('perl(:MODULE_COMPAT_' .. macros.perl_version .. ')')
else
print('perl-libs')
end
}
%__perllib_path ^(%{perl_vendorarch}|%{perl_vendorlib})/.+
(Untested.)
--
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, report it:
https://pagure.io/fedora-infrastructure/new_issue
Re: SPDX Change update
On 11-11-2022 10:33, Neal Gompa wrote: On Fri, Nov 11, 2022 at 4:32 AM Neal Gompa wrote: On Fri, Nov 11, 2022 at 4:18 AM Sandro wrote: On 11-11-2022 10:12, Neal Gompa wrote: On Fri, Nov 11, 2022 at 4:10 AM Sandro wrote: On 08-11-2022 15:06, David Cantrell wrote: On Tue, Nov 08, 2022 at 09:45:57AM +, Richard W.M. Jones wrote: Should new package reviews (for Rawhide) now be rejected if they don't have SPDX tags? Yes, new packages going forward should use SPDX expressions in the License tag. When will rpmlint be updated to correctly recognize SPDX license tags? I don't see it as part of the change proposal. Right now it throws a warning, e.g.: W: invalid-license GPL-3.0-only. Does it go away when you install rpmlint-fedora-license-data? It does. Thanks for the pointer. So, I guess rpmlint should depend on it? I will add a Recommends to it. Actually, looks like this has been done a while ago: https://src.fedoraproject.org/rpms/rpmlint/c/9c506b5c4fe457944fbbfd51dec5a3f663995cdf That change has only been pushed to rawhide. I tent to verify my packages on a current release, currently either f35 or f36. My f35 machine will be upgraded to f37 in the near future. But even in f37 rpmlint-fedora-license-data is not required by rpmlint. Simply adding 'Requires: rpmlint-fedora-license-data' to rpmlint.spec for the current release branches should be sufficient, seeing that installing rpmlint-fedora-license-data manually solves the false warning. -- Sandro ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[rpms/perl-Text-Markdown] PR #3: Package tests and update license to SPDX format
mspacek merged a pull-request against the project: `perl-Text-Markdown` that you are following. Merged pull-request: `` Package tests and update license to SPDX format `` https://src.fedoraproject.org/rpms/perl-Text-Markdown/pull-request/3 ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Fedora rawhide compose report: 20221111.n.0 changes
OLD: Fedora-Rawhide-20221110.n.0 NEW: Fedora-Rawhide-2022.n.0 = SUMMARY = Added images:2 Dropped images: 1 Added packages: 8 Dropped packages:1 Upgraded packages: 129 Downgraded packages: 0 Size of added packages: 1.81 MiB Size of dropped packages:1.01 MiB Size of upgraded packages: 2.49 GiB Size of downgraded packages: 0 B Size change of upgraded packages: 95.68 MiB Size change of downgraded packages: 0 B = ADDED IMAGES = Image: Silverblue dvd-ostree ppc64le Path: Silverblue/ppc64le/iso/Fedora-Silverblue-ostree-ppc64le-Rawhide-2022.n.0.iso Image: Games live x86_64 Path: Labs/x86_64/iso/Fedora-Games-Live-x86_64-Rawhide-2022.n.0.iso = DROPPED IMAGES = Image: Silverblue dvd-ostree x86_64 Path: Silverblue/x86_64/iso/Fedora-Silverblue-ostree-x86_64-Rawhide-20221110.n.0.iso = ADDED PACKAGES = Package: golang-github-twpayne-xdg-6-6.0.0-1.fc38 Summary: Package xdg provides support for the XDG Base Directory Specification RPMs:golang-github-twpayne-xdg-6-devel Size:13.21 KiB Package: golang-github-zalando-keyring-0.2.1-1.fc38 Summary: Cross-platform keyring interface for Go RPMs:golang-github-zalando-keyring-devel Size:18.41 KiB Package: priv_wrapper-1.0.0-3.fc38 Summary: A library to disable resource limits and other privilege dropping RPMs:priv_wrapper Size:148.24 KiB Package: python-formulaic-0.5.2-4.fc38 Summary: A high-performance implementation of Wilkinson formulas RPMs:python3-formulaic Size:192.20 KiB Package: python-oslo-metrics-0.5.0-1.fc38 Summary: OpenStack Oslo Metrics library RPMs:python-oslo-metrics-doc python3-oslo-metrics python3-oslo-metrics-tests Size:1016.95 KiB Package: rpmdistro-repoquery-0^20220419git2aff449-1.fc38 Summary: Tool to easily do repository queries for different distributions using DNF RPMs:rpmdistro-repoquery Size:14.31 KiB Package: rust-rustfft-6.1.0-1.fc38 Summary: High-performance FFT library written in pure Rust RPMs:rust-rustfft+avx-devel rust-rustfft+default-devel rust-rustfft+neon-devel rust-rustfft+sse-devel rust-rustfft-devel Size:209.30 KiB Package: xdg-desktop-portal-lxqt-0.2.0-1.fc38 Summary: A backend implementation for xdg-desktop-portal that is using Qt/KF5/libfm-qt RPMs:xdg-desktop-portal-lxqt Size:242.64 KiB = DROPPED PACKAGES = Package: slv2-0.6.6-33.fc35 Summary: LV2 host library RPMs:slv2 slv2-devel Size:1.01 MiB = UPGRADED PACKAGES = Package: aqute-bnd-6.3.1-2.fc38 Old package: aqute-bnd-6.3.1-1.fc38 Summary: BND Tool RPMs: aqute-bnd aqute-bnd-javadoc aqute-bndlib bnd-maven-plugin Size: 5.04 MiB Size change: -26.44 KiB Changelog: * Tue Nov 08 2022 Stephen Gallagher - 6.3.1-2 - Re-enable maven plugin for RHEL 10+ Package: awscli-1.27.7-1.fc38 Old package: awscli-1.27.5-1.fc38 Summary: Universal Command Line Environment for AWS RPMs: awscli Size: 3.24 MiB Size change: 26 B Changelog: * Thu Nov 10 2022 Gwyn Ciesla - 1.27.6-1 - 1.27.6 * Thu Nov 10 2022 Gwyn Ciesla - 1.27.7-1 - 1.27.7 Package: batctl-2022.3-1.fc38 Old package: batctl-2022.2-1.fc37 Summary: B.A.T.M.A.N. advanced control and management tool RPMs: batctl Size: 331.76 KiB Size change: 28 B Changelog: * Thu Nov 10 2022 Felix Kaechele - 2022.3-1 - update to 2022.3 Package: bluedevil-5.26.3.1-1.fc38 Old package: bluedevil-5.26.2-1.fc38 Summary: Bluetooth stack for KDE RPMs: bluedevil Size: 2.75 MiB Size change: 33.21 KiB Changelog: * Wed Nov 09 2022 Marc Deop - 5.26.3.1-1 - 5.26.3.1 Package: breeze-gtk-5.26.3-1.fc38 Old package: breeze-gtk-5.26.2-1.fc38 Summary: Breeze widget theme for GTK RPMs: breeze-gtk breeze-gtk-common breeze-gtk-gtk2 breeze-gtk-gtk3 breeze-gtk-gtk4 Size: 406.24 KiB Size change: -1.50 KiB Changelog: * Wed Nov 09 2022 Marc Deop - 5.26.3-1 - 5.26.3 Package: cockatrice-2.8.0-7.fc38 Old package: cockatrice-2.8.0-6.fc37 Summary: A cross-platform virtual tabletop software for multi-player card games RPMs: cockatrice cockatrice-langpack-cs cockatrice-langpack-de cockatrice-langpack-en cockatrice-langpack-es cockatrice-langpack-et cockatrice-langpack-fr cockatrice-langpack-it cockatrice-langpack-ja cockatrice-langpack-ko cockatrice-langpack-nb cockatrice-langpack-nl cockatrice-langpack-pl cockatrice-langpack-pt cockatrice-langpack-pt_BR cockatrice-langpack-ru cockatrice-langpack-sr cockatrice-langpack-sv cockatrice-langpack-zh-Hans cockatrice-server cockatrice-utils Added RPMs: cockatrice-server cockatrice-utils Size: 28.38 MiB Size change: 752.87 KiB Changelog: * Thu Nov 10 2022 Link Dupont - 2.8.0-7 - Split servatrice into separate subpackage Package: crypto-policies-20221110-1.git87a75f4.fc38 Old package: crypto-policies-20221003-1.gitcb1ad32.fc38 Summary: System
[rpms/perl-Text-Markdown] PR #3: Package tests and update license to SPDX format
mspacek opened a new pull-request against the project: `perl-Text-Markdown` that you are following: `` Package tests and update license to SPDX format `` To reply, visit the link below https://src.fedoraproject.org/rpms/perl-Text-Markdown/pull-request/3 ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F38 proposal: Reproducible builds: Clamp build mtimes to $SOURCE_DATE_EPOCH (System-Wide Change proposal)
On Fri, Nov 11, 2022 at 11:53 AM Petr Pisar wrote: > > V Thu, Nov 10, 2022 at 03:23:49PM -0500, Ben Cotton napsal(a): > > https://fedoraproject.org/wiki/Changes/ReproducibleBuildsClampMtimes > > > > == Summary == > > > > The `%clamp_mtime_to_source_date_epoch` RPM macro will be set to `1`. > > When an RPM package is built, mtimes of packaged files will be clamped > > to `$SOURCE_DATE_EPOCH` > > Clamp as capping maximal mtime, or resetting mtime for all files? I.e. If > I had a source file dated 1970-01-01 and installed it with "install -p", will > the packaged file retain that 1970-01-01 date, or will it be set to the date > of the latest changlog, e.g. 2022-11-11? In other words, will all files in > a package have the same mtime, or there won't be an mtime newer than the > changelog entry? Second. Original message: >> Clamping means that all files which would otherwise have a >> modification datetime higher than `$SOURCE_DATE_EPOCH` will have the >> modification datetime changed to `$SOURCE_DATE_EPOCH`; files with >> mtime lower (or equal) to `$SOURCE_DATE_EPOCH` will retain the >> original mtimes. > > which is already set to the date of the latest `%changelog` entry. > > What's a changelog entry date in case of rpmautospec changelog? Is it > a git AuthorDate or CommitDate? > > > As a result, more RPM packages will be reproducible: > > Where will this reproducibility stop? Ideally, when it's achieved, and 100% of Fedora will be reproducible under reprotest =P > An RPM package itself carry a build time in its RPM header. > Are we also going to fake this time in the name of > reproducibility? My opinion: yes, please do (%use_source_date_epoch_as_buildtime). And fake the builder hostname (%_buildhost). And enable back --enable-deterministic-archives in binutils: (https://bugzilla.redhat.com/show_bug.cgi?id=1195883). And do whatever else is necessary to stop shipping binary packages that users can't reproduce bit-to-bit. > What value these faked timestamps have? None. > E.g. a compiled file is a function not only of its source, but also of the > compiler. Nods in NixOS. > This proposed change removes > the compiler part from the timestamp. Will timestamps like this be helpful? > Wouldn't be easier to admit that timesamps are nonsense and simply eradicate > all of them stamps from various data formats rather than trying to fake them? > Simply changing rpmbuild to set timestamp to 0 for all contained files, or > removing the time attribute from the RPM format completely? Would be wonderful. Mixing metadata with data has always been a mistake. Reproducibility is at stakes with auditability, and the second must be driven off or given up on. The metainformation of which host has built the artifact and when has no place within the artifact itself. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F38 proposal: Reproducible builds: Clamp build mtimes to $SOURCE_DATE_EPOCH (System-Wide Change proposal)
V Thu, Nov 10, 2022 at 03:23:49PM -0500, Ben Cotton napsal(a): > https://fedoraproject.org/wiki/Changes/ReproducibleBuildsClampMtimes > > == Summary == > > The `%clamp_mtime_to_source_date_epoch` RPM macro will be set to `1`. > When an RPM package is built, mtimes of packaged files will be clamped > to `$SOURCE_DATE_EPOCH` Clamp as capping maximal mtime, or resetting mtime for all files? I.e. If I had a source file dated 1970-01-01 and installed it with "install -p", will the packaged file retain that 1970-01-01 date, or will it be set to the date of the latest changlog, e.g. 2022-11-11? In other words, will all files in a package have the same mtime, or there won't be an mtime newer than the changelog entry? > which is already set to the date of the latest `%changelog` entry. What's a changelog entry date in case of rpmautospec changelog? Is it a git AuthorDate or CommitDate? > As a result, more RPM packages will be reproducible: Where will this reproducibility stop? An RPM package itself carry a build time in its RPM header. Are we also going to fake this time in the name of reproducibility? What value these faked timestamps have? E.g. a compiled file is a function not only of its source, but also of the compiler. This proposed change removes the compiler part from the timestamp. Will timestamps like this be helpful? Wouldn't be easier to admit that timesamps are nonsense and simply eradicate all of them stamps from various data formats rather than trying to fake them? Simply changing rpmbuild to set timestamp to 0 for all contained files, or removing the time attribute from the RPM format completely? -- 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, report it: https://pagure.io/fedora-infrastructure/new_issue
[Bug 2130630] Please branch and build perl-TestML in epel9
https://bugzilla.redhat.com/show_bug.cgi?id=2130630 --- Comment #3 from Fedora Update System --- FEDORA-EPEL-2022-b15398a7ea has been submitted as an update to Fedora EPEL 9. https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2022-b15398a7ea -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2130630 ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[Bug 2130630] Please branch and build perl-TestML in epel9
https://bugzilla.redhat.com/show_bug.cgi?id=2130630 Petr Pisar changed: What|Removed |Added Fixed In Version||perl-TestML-0.54.05-15.el9 Status|ASSIGNED|MODIFIED -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2130630 ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: SPDX Change update
On Fri, Nov 11, 2022 at 4:32 AM Neal Gompa wrote: > > On Fri, Nov 11, 2022 at 4:18 AM Sandro wrote: > > > > On 11-11-2022 10:12, Neal Gompa wrote: > > > On Fri, Nov 11, 2022 at 4:10 AM Sandro wrote: > > >> > > >> On 08-11-2022 15:06, David Cantrell wrote: > > >>> On Tue, Nov 08, 2022 at 09:45:57AM +, Richard W.M. Jones wrote: > > Should new package reviews (for Rawhide) now be rejected if they > > don't have SPDX tags? > > >>> > > >>> Yes, new packages going forward should use SPDX expressions in the > > >>> License tag. > > >> > > >> When will rpmlint be updated to correctly recognize SPDX license tags? I > > >> don't see it as part of the change proposal. > > >> > > >> Right now it throws a warning, e.g.: W: invalid-license GPL-3.0-only. > > > > > > Does it go away when you install rpmlint-fedora-license-data? > > > > It does. Thanks for the pointer. So, I guess rpmlint should depend on it? > > > > I will add a Recommends to it. > Actually, looks like this has been done a while ago: https://src.fedoraproject.org/rpms/rpmlint/c/9c506b5c4fe457944fbbfd51dec5a3f663995cdf -- 真実はいつも一つ！/ Always, there's only one truth! ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: SPDX Change update
On Fri, Nov 11, 2022 at 4:18 AM Sandro wrote: > > On 11-11-2022 10:12, Neal Gompa wrote: > > On Fri, Nov 11, 2022 at 4:10 AM Sandro wrote: > >> > >> On 08-11-2022 15:06, David Cantrell wrote: > >>> On Tue, Nov 08, 2022 at 09:45:57AM +, Richard W.M. Jones wrote: > Should new package reviews (for Rawhide) now be rejected if they > don't have SPDX tags? > >>> > >>> Yes, new packages going forward should use SPDX expressions in the > >>> License tag. > >> > >> When will rpmlint be updated to correctly recognize SPDX license tags? I > >> don't see it as part of the change proposal. > >> > >> Right now it throws a warning, e.g.: W: invalid-license GPL-3.0-only. > > > > Does it go away when you install rpmlint-fedora-license-data? > > It does. Thanks for the pointer. So, I guess rpmlint should depend on it? > I will add a Recommends to it. -- 真実はいつも一つ！/ Always, there's only one truth! ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: SPDX Change update
On 11-11-2022 10:12, Neal Gompa wrote: On Fri, Nov 11, 2022 at 4:10 AM Sandro wrote: On 08-11-2022 15:06, David Cantrell wrote: On Tue, Nov 08, 2022 at 09:45:57AM +, Richard W.M. Jones wrote: Should new package reviews (for Rawhide) now be rejected if they don't have SPDX tags? Yes, new packages going forward should use SPDX expressions in the License tag. When will rpmlint be updated to correctly recognize SPDX license tags? I don't see it as part of the change proposal. Right now it throws a warning, e.g.: W: invalid-license GPL-3.0-only. Does it go away when you install rpmlint-fedora-license-data? It does. Thanks for the pointer. So, I guess rpmlint should depend on it? -- Sandro ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Self Introduction: Simon Bachenberg
Hi, my name is Simon Bachenberg. I am 36 years old and live with my wife and our 5 children in Germany. I started my career as a Java and PHP developer for 7 years. Since running PHP applications on Windows servers is not fun, I started learning Linux. That's how I came to work for Deutsche Welle in the operation of online systems and have now been working there for 8 years as a DevOps engineer. I have gained experience with: Adabas, Oracle, DB2, MySQL, MongoDB, Elasticsearch, Apache Solr, Java, Hibernate, J2ME, Natural ( for Adabas ), C++, PHP, Python, ( Semantic ) Mediawiki, Apache Solr, Apache Tomcat, HTML/CSS, Hudson / Jenkins, Ant, Ansibel, Docker / Podman, Subversion, Git. Ideally, I would like Fedora to become the standard Linux client of the Deutsche Welle instead of Ubuntu. But I would also like to help make Fedora even better and more popular. Cheers, Simon ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: SPDX Change update
On Fri, Nov 11, 2022 at 4:10 AM Sandro wrote: > > On 08-11-2022 15:06, David Cantrell wrote: > > On Tue, Nov 08, 2022 at 09:45:57AM +, Richard W.M. Jones wrote: > >> Should new package reviews (for Rawhide) now be rejected if they > >> don't have SPDX tags? > > > > Yes, new packages going forward should use SPDX expressions in the > > License tag. > > When will rpmlint be updated to correctly recognize SPDX license tags? I > don't see it as part of the change proposal. > > Right now it throws a warning, e.g.: W: invalid-license GPL-3.0-only. Does it go away when you install rpmlint-fedora-license-data? -- 真実はいつも一つ！/ Always, there's only one truth! ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: SPDX Change update
On 08-11-2022 15:06, David Cantrell wrote: On Tue, Nov 08, 2022 at 09:45:57AM +, Richard W.M. Jones wrote: Should new package reviews (for Rawhide) now be rejected if they don't have SPDX tags? Yes, new packages going forward should use SPDX expressions in the License tag. When will rpmlint be updated to correctly recognize SPDX license tags? I don't see it as part of the change proposal. Right now it throws a warning, e.g.: W: invalid-license GPL-3.0-only. -- Sandro ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
