Re: OCaml 5.1.1 rebuild in Rawhide
On Mon, Dec 18, 2023 at 10:50:11AM +, Richard W.M. Jones wrote: > On Mon, Dec 18, 2023 at 10:48:18AM +, Richard W.M. Jones wrote: > > On Thu, Dec 14, 2023 at 11:46:58AM +, Richard W.M. Jones wrote: > > > These are done now, bar waiting for a couple of builds to complete. > > > > ... or so we thought. > > > > It turns out that Jerry James identified a code generation bug on s390x: > > > > https://github.com/ocaml/ocaml/issues/12829 > > > > which is fixed upstream in: > > > > https://github.com/ocaml/ocaml/pull/12831 > > > > We may need to rebuild either just OCaml or potentially all OCaml > > packages (in a side tag). I'll try to get this done today. > > Actually it's all of them since this alters generated code potentially > in any s390x package. The second rebuild is now done. https://bodhi.fedoraproject.org/updates/FEDORA-2023-5a1287b99c Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com virt-p2v converts physical machines to virtual machines. Boot with a live CD or over the network (PXE) and turn machines into KVM guests. http://libguestfs.org/virt-v2v -- ___ 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 2255149] New: perl-MooseX-Getopt-0.76 is available
https://bugzilla.redhat.com/show_bug.cgi?id=2255149 Bug ID: 2255149 Summary: perl-MooseX-Getopt-0.76 is available Product: Fedora Version: rawhide Status: NEW Component: perl-MooseX-Getopt Keywords: FutureFeature, Triaged Assignee: emman...@seyman.fr Reporter: upstream-release-monitor...@fedoraproject.org QA Contact: extras...@fedoraproject.org CC: emman...@seyman.fr, iarn...@gmail.com, p...@city-fan.org, perl-devel@lists.fedoraproject.org Target Milestone: --- Classification: Fedora Releases retrieved: 0.76 Upstream release that is considered latest: 0.76 Current version/release in rawhide: 0.75-10.fc39 URL: http://search.cpan.org/dist/MooseX-Getopt/ 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/10663/ To change the monitoring settings for the project, please visit: https://src.fedoraproject.org/rpms/perl-MooseX-Getopt -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2255149 Report this comment as SPAM: https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla=report-spam_desc=Report%20of%20Bug%202255149%23c0 -- ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: libcap-ng upcoming change
On Mon, Dec 18 2023 at 01:17:43 PM -05:00:00, Steve Grubb wrote: So, what should I do to remove the patch? Do I push the new release into rawhide without the patch or does this need to go through the Fedora Change Process? And if so, self-contained or system wide? Just remove it in rawhide. You don't need a change proposal to fix a bug. That's too much overhead! -- ___ 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: libcap-ng upcoming change
On Monday, December 18, 2023 1:40:55 PM EST Tomasz Kłoczko wrote: > On Mon, 18 Dec 2023 at 18:18, Steve Grubb wrote: > > Hello, > > > > I wanted to ask about the right tactic to make a change in Fedora 40. > > Libcap- > > ng is ready for a new release. I want to remove a Fedora only patch that > > allows an errant call to capng_apply to succeed. > > BTW libcap-ng. > Is there any plan to get rid of libcap?樂 Not really. Just the same as we have at least 3 TLS implementations, we also have more than 1 API for capabilities manipulation. The two projects have entirely different goals. libcap is meant to be a thin veneer over the raw kernel API. Libcap-ng is meant to make using capabilities simple. -Steve -- ___ 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: libcap-ng upcoming change
On Mon, 18 Dec 2023 at 18:18, Steve Grubb wrote: > Hello, > > I wanted to ask about the right tactic to make a change in Fedora 40. > Libcap- > ng is ready for a new release. I want to remove a Fedora only patch that > allows an errant call to capng_apply to succeed. BTW libcap-ng. Is there any plan to get rid of libcap?樂 kloczek -- Tomasz Kłoczko | inkedIn: http://lnkd.in/FXPWxH -- ___ 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: Orphaned packages looking for new maintainers
virtme-ng makes testing a new kernel and developing new modules A LOT easier. On Mon, Dec 18, 2023 at 10:27 AM Richard W.M. Jones wrote: > On Mon, Dec 18, 2023 at 11:20:22AM +0100, Miro Hrončok wrote: > > virtmeorphan 4 > weeks ago > > I have no special knowledge of this package, but I did read the > article below a few weeks ago about virtme-ng. In particular > virtme-ng uses virtiofs (instead of 9p) which is a more modern way to > export filesystems into VMs. We (the virt team) have for a very very > long time recommended people steer clear of 9p, for security, > performance and maintainability reasons. > > https://lwn.net/Articles/951313/ > > Rich. > > -- > Richard Jones, Virtualization Group, Red Hat > http://people.redhat.com/~rjones > Read my programming and virtualization blog: http://rwmj.wordpress.com > nbdkit - Flexible, fast NBD server with plugins > https://gitlab.com/nbdkit/nbdkit > -- > ___ > 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
libcap-ng upcoming change
Hello, I wanted to ask about the right tactic to make a change in Fedora 40. Libcap- ng is ready for a new release. I want to remove a Fedora only patch that allows an errant call to capng_apply to succeed. Back in Oct 2020, a bug was reported upstream where the user needed to know that a call to capng_apply failed because its bounding set did not have the right permission but success was being accidentally returned. This bug was fixed and libcap-ng-0.8.1 was released with the issue fixed. Soon after, people started noticing other applications failing because it was now passing the error back to the caller. A few examples: https://bugzilla.redhat.com/show_bug.cgi?id=1899540 https://bugzilla.redhat.com/show_bug.cgi?id=1899840 https://bugzilla.redhat.com/show_bug.cgi?id=1924218 https://bugzilla.redhat.com/show_bug.cgi?id=1952715 etc This really was a problem in all these applications. But we couldn't allow them to just fail, so a patch was created that reverted the behavior but syslogged that it would have failed. Then a new wave of bug reports came for applications that didn't check the return code that now had warnings in syslog. That was 3 years ago. I think it's been long enough that any applications that had problematic behaviour should have had the syslog message reported upstream and fixed. In September of this year, I pushed out an updated version of libcap-ng that had warn about unused results annotations added to the canng_apply function declaration. This was to increase visibility to anyone doing builds. So, what should I do to remove the patch? Do I push the new release into rawhide without the patch or does this need to go through the Fedora Change Process? And if so, self-contained or system wide? Thanks, -Steve -- ___ 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: F40 Change Proposal: Unified Kernel Support Phase Two (System-Wide)
Hi, On 12/18/23 06:41, Gerd Hoffmann wrote: On Fri, Dec 15, 2023 at 02:03:27PM -0600, Jeremy Linton wrote: Hi, Phase 2 goals * Add support for booting UKIs directly. ** Boot path is shim.efi -> UKI, without any boot loader (grub, sd-boot) involved. This is IMHO a mistake, the systemd-boot and UKI paths are the perfect time to break with shim and require some form of actual fedora/whatever secure boot key enrollment on the machine. This is not going to fly. There are too many cases where you simply can't enroll fedora keys, so booting on machines with the MS 3rd party certificate enrolled IMHO must continue to work. I agree solving this for every possible machine combination is an intractable problem at the moment. But, the UKI use case, as I understand it, is a handful of hyperscalers and machines. Those organizations either participate in this community or we have engineering contacts at who can assist with cleaning it up. And this isn't unheard of, poke around in a few machine's key database and you will find other distro's keys. I agree that depending on MS signing exclusively is a problem. I'd love to see fedora signing as an option. Given that EFI binaries can have multiple signatures we could have shim.efi signed by both microsoft and fedora. Which would allow to enroll the fedora keys instead of the microsoft keys (in case your platform offers that option) and everything works as it did before, except that the machine would only accept fedora-signed EFI binaries. Problem #1 is we don't have that in fedora today. Which btw is different from rhel/centos, where we actually have a second, distro-signed shim binary. Not as useful as one binary with two signatures, but better than nothing. I'm talking about removing shim from the boot flow. The UKI would be signed with the fedora key same as would be done with shim in the boot path. The fedora public key is itself enrolled in the UEFI key db alongside the assortment of existing db entries, and the boot path would be UEFI->UKI. Alternatively, better instructions for putting specific machines into UEFI setup mode can be provided, and something like the key enroller being used for fedora/libvirt/qemu today is used to replace the key infrastructure (PK/KEK/etc) on a given machine. The argument against this has always been that it breaks multiboot, but that is not applicable here. Frankly, none of this should be an issue for any machine that conforms to MS's requirements, as there is already a windows/everyone else boot switch to enable the keys needed to boot linux/shim vs the keys needed to boot modern windows versions. Problem #2 is we don't have a signed system-boot binary. Switching over to use systemd-boot when this has changed should be easy. The UKIs are already placed in $ESP/EFI/Linux, according to the boot loader spec, where systemd-boot would look for them. So the kernel-install workflow would need only minor changes. I'm not sure that is strictly needed. Your example boot flow shim->UKI depends on the BDS as the boot selector. If that boot flow works for the end user, there isn't a need the systemd-boot loader itself. It does solve various problems, like boot selection and command line editing, and a few other things, but isn't otherwise necessary. Of course it too, would be signed with the fedora keys rather than the MS ones, and maybe it should be built without the shim + LoadImage/StartImage hacks. Problem #3 is that apparently everything touching fedora secure boot signing takes ages to make any progress. One ticket I've looked at recently (IIRC the one to enable secure boot signing for aarch64) was roughly five years (!) old. So I'm not going to make my change proposals depend on any progress there. But I'll happily file a Phase #3 proposal once the problems outlined above are solved. Right, but little of it has been strictly technical. Other distro's have signed their aarch64 shim/boot path. That isn't to say there haven't been plenty of technical things needing attention, but those have been in the, "this should be cleaned up" category rather than "it doesn't work" category. But, your not really asking for more or less of the fedora infra with or without shim in the path. In both cases the UKI is signed with a fedora key. The difference is where the public key(s) gets enrolled. whole UKI concept works at all. Put another way, there isn't really an answer to a generic boots everywhere UKI at the movement unless one is willing to create GB+ UKIs with every boot critical driver in existence, Well, CoreOS actually does that. They don't use UKIs specifically, but they ship a generic initrd created on fedora infrastructure instead of generating an host-specific initrd on the installed machine (with only the drivers needed on the host included). Last time I looked it was ~80 MB in size. Well on x86, and a fair number of SystemReady SR
Orphaning python-markdown-include
I’m orphaning the package python-markdown-include[1]. It is a leaf package in Fedora and EPEL9, and has been for several releases, although it is still used by a number of packages in the wider Python ecosystem[2]. The package is up to date, upstream remains active, and the spec file is clean, trivial, and follows modern practices. I’m not going to keep maintaining it “just in case” any longer, but feel free to pick it up if you think you will need it for something. [1] https://src.fedoraproject.org/rpms/python-markdown-include [2] https://www.wheelodex.org/projects/markdown-include/rdepends/ -- ___ 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: python packaging assistance sought for xgboost
On 12. 12. 23 7:56, Nathan Scott wrote: Thanks Miro - that size pointer was helpful. Indeed, the only thing in the wheel are 3 metadata files. Things seem to be OK up to this point in the upstream hatchling build: https://github.com/dmlc/xgboost/blob/43897b829680d241491abe1ecd46b2ba9d338967/python-package/packager/pep517.py#L86 ... that temporary directory is populated with all the python files in what looks like a good format, but the generated wheel is essentially empty. Is there any way to see what's happening inside that hatchling.build.build_wheel call I wonder? I don't know. Try adding: [tool.hatch.build.targets.wheel] packages = ["xgboost"] to pyproject.toml. Does it help? -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok -- ___ python-devel mailing list -- python-devel@lists.fedoraproject.org To unsubscribe send an email to python-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/python-devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Planning to update to podofo-0.10.1 + review request for podofo-compat for legacy 0.9.x library
On 17.12.23 17:44, Zbigniew Jędrzejewski-Szmek wrote: On Tue, Aug 15, 2023 at 11:56:56PM +0200, Sandro Mani wrote: Hi I'm planning to update to podofo-0.10.1 in rawhide. I did a series of test builds here [1], according to which scribus, vfrnav and pdfsign currently do not support podofo-0.10.x. To keep these functional, I've prepared a podofo-compat package with the previous 0.9.x library. The review request is here [2]. Happy to review in exchange. Hi, we have the opposite situation with calibre: it builds fine in rawhide with podofo-0.10, but does not compile against podofo-0.9.8 in F39. I just built calibre-7.2.0 in rawhide, and would like to do the same update for F39. Is there any chance you can also push podofo-0.10.x + podofo-compat-0.9.x also to F39? I think that'd be OK, because we can keep the packages that need the old version building, possibly after adjusting some BuildRequires line. Hi I've done so: https://bodhi.fedoraproject.org/updates/FEDORA-2023-e8f9188f10 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: Orphaned packages looking for new maintainers
On Mon, Dec 18, 2023 at 11:20:22AM +0100, Miro Hrončok wrote: > virtmeorphan 4 weeks ago I have no special knowledge of this package, but I did read the article below a few weeks ago about virtme-ng. In particular virtme-ng uses virtiofs (instead of 9p) which is a more modern way to export filesystems into VMs. We (the virt team) have for a very very long time recommended people steer clear of 9p, for security, performance and maintainability reasons. https://lwn.net/Articles/951313/ Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com nbdkit - Flexible, fast NBD server with plugins https://gitlab.com/nbdkit/nbdkit -- ___ 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 2161639] Pregenerated File-RsyncP-0.76/FileList/configure is missing a source
https://bugzilla.redhat.com/show_bug.cgi?id=2161639 Florian Weimer changed: What|Removed |Added Version|38 |rawhide Keywords||FutureFeature -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2161639 -- ___ 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: F40 Change Proposal: Unified Kernel Support Phase Two (System-Wide)
On Fri, Dec 15, 2023 at 02:03:27PM -0600, Jeremy Linton wrote: > Hi, > > > Phase 2 goals > > > > * Add support for booting UKIs directly. > > ** Boot path is shim.efi -> UKI, without any boot loader (grub, > > sd-boot) involved. > > This is IMHO a mistake, the systemd-boot and UKI paths are the perfect time > to break with shim and require some form of actual fedora/whatever secure > boot key enrollment on the machine. This is not going to fly. There are too many cases where you simply can't enroll fedora keys, so booting on machines with the MS 3rd party certificate enrolled IMHO must continue to work. I agree that depending on MS signing exclusively is a problem. I'd love to see fedora signing as an option. Given that EFI binaries can have multiple signatures we could have shim.efi signed by both microsoft and fedora. Which would allow to enroll the fedora keys instead of the microsoft keys (in case your platform offers that option) and everything works as it did before, except that the machine would only accept fedora-signed EFI binaries. Problem #1 is we don't have that in fedora today. Which btw is different from rhel/centos, where we actually have a second, distro-signed shim binary. Not as useful as one binary with two signatures, but better than nothing. Problem #2 is we don't have a signed system-boot binary. Switching over to use systemd-boot when this has changed should be easy. The UKIs are already placed in $ESP/EFI/Linux, according to the boot loader spec, where systemd-boot would look for them. So the kernel-install workflow would need only minor changes. Problem #3 is that apparently everything touching fedora secure boot signing takes ages to make any progress. One ticket I've looked at recently (IIRC the one to enable secure boot signing for aarch64) was roughly five years (!) old. So I'm not going to make my change proposals depend on any progress there. But I'll happily file a Phase #3 proposal once the problems outlined above are solved. > whole UKI concept works at all. Put another way, there isn't really an > answer to a generic boots everywhere UKI at the movement unless one is > willing to create GB+ UKIs with every boot critical driver in existence, Well, CoreOS actually does that. They don't use UKIs specifically, but they ship a generic initrd created on fedora infrastructure instead of generating an host-specific initrd on the installed machine (with only the drivers needed on the host included). Last time I looked it was ~80 MB in size. > at which point its probably worth revisiting the entire initramfs boot > method. That is *way* beyond the scope of this change proposal ... take care, Gerd -- ___ 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: Mock Configs v39.3 released - DNF5 used for F40+ builds
On pondělí 18. prosince 2023 11:46:07 CET Miro Hrončok wrote:
> On 18. 12. 23 10:08, Pavel Raiskup wrote:
> > In any case, if you need to - stay with DNF4 for a while - either do
> >
> > $ cat ~/.config/mock/fedora-rawhide-x86_64.cfg
> > include("/etc/mock/fedora-rawhide-x86_64.cfg")
> > config_opts["package_manager"] = "dnf"
> >
> > ... or stay with the `mock-core-configs v39.2` a bit longer please.
>
>
> Hi Pavel,
> this works locally, but not in Copr.
>
> Our Python 3.13 Copr builds started failing today with the builddep globbing
> issue.
>
> What do we do?
I should work again actually, so no explicit action is needed.
I reverted the change for Fedora Copr, per
https://github.com/fedora-copr/copr/issues/3067
Pavel
signature.asc
Description: This is a digitally signed message part.
--
___
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: OCaml 5.1.1 rebuild in Rawhide
On Mon, Dec 18, 2023 at 10:48:18AM +, Richard W.M. Jones wrote: > On Thu, Dec 14, 2023 at 11:46:58AM +, Richard W.M. Jones wrote: > > These are done now, bar waiting for a couple of builds to complete. > > ... or so we thought. > > It turns out that Jerry James identified a code generation bug on s390x: > > https://github.com/ocaml/ocaml/issues/12829 > > which is fixed upstream in: > > https://github.com/ocaml/ocaml/pull/12831 > > We may need to rebuild either just OCaml or potentially all OCaml > packages (in a side tag). I'll try to get this done today. Actually it's all of them since this alters generated code potentially in any s390x package. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com virt-top is 'top' for virtual machines. Tiny program with many powerful monitoring features, net stats, disk stats, logging, etc. http://people.redhat.com/~rjones/virt-top -- ___ 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: OCaml 5.1.1 rebuild in Rawhide
On Thu, Dec 14, 2023 at 11:46:58AM +, Richard W.M. Jones wrote: > These are done now, bar waiting for a couple of builds to complete. ... or so we thought. It turns out that Jerry James identified a code generation bug on s390x: https://github.com/ocaml/ocaml/issues/12829 which is fixed upstream in: https://github.com/ocaml/ocaml/pull/12831 We may need to rebuild either just OCaml or potentially all OCaml packages (in a side tag). I'll try to get this done today. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com libguestfs lets you edit virtual machines. Supports shell scripting, bindings from many languages. http://libguestfs.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: Mock Configs v39.3 released - DNF5 used for F40+ builds
On 18. 12. 23 10:08, Pavel Raiskup wrote:
In any case, if you need to - stay with DNF4 for a while - either do
$ cat ~/.config/mock/fedora-rawhide-x86_64.cfg
include("/etc/mock/fedora-rawhide-x86_64.cfg")
config_opts["package_manager"] = "dnf"
... or stay with the `mock-core-configs v39.2` a bit longer please.
Hi Pavel,
this works locally, but not in Copr.
Our Python 3.13 Copr builds started failing today with the builddep globbing
issue.
What do we do?
--
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 2254730] perl-PAR-Packer-1.061 is available
https://bugzilla.redhat.com/show_bug.cgi?id=2254730 Fedora Update System changed: What|Removed |Added Status|MODIFIED|CLOSED Fixed In Version||perl-PAR-Packer-1.061-1.fc4 ||0 Resolution|--- |ERRATA Last Closed||2023-12-18 10:27:08 --- Comment #2 from Fedora Update System --- FEDORA-2023-c037fc34dd has been pushed to the Fedora 40 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=2254730 Report this comment as SPAM: https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla=report-spam_desc=Report%20of%20Bug%202254730%23c2 -- ___ 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 2254730] perl-PAR-Packer-1.061 is available
https://bugzilla.redhat.com/show_bug.cgi?id=2254730 Fedora Update System changed: What|Removed |Added Status|ASSIGNED|MODIFIED --- Comment #1 from Fedora Update System --- FEDORA-2023-c037fc34dd has been submitted as an update to Fedora 40. https://bodhi.fedoraproject.org/updates/FEDORA-2023-c037fc34dd -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2254730 Report this comment as SPAM: https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla=report-spam_desc=Report%20of%20Bug%202254730%23c1 -- ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Fedora rawhide compose report: 20231218.n.0 changes
OLD: Fedora-Rawhide-20231217.n.1 NEW: Fedora-Rawhide-20231218.n.0 = SUMMARY = Added images:4 Dropped images: 1 Added packages: 2 Dropped packages:0 Upgraded packages: 51 Downgraded packages: 0 Size of added packages: 1.58 MiB Size of dropped packages:0 B Size of upgraded packages: 3.71 GiB Size of downgraded packages: 0 B Size change of upgraded packages: -1.92 GiB Size change of downgraded packages: 0 B = ADDED IMAGES = Image: Workstation live-osbuild x86_64 Path: Workstation/x86_64/iso/Fedora-Workstation-Live-osb-Rawhide-20231218.n.0.x86_64.iso Image: Kinoite dvd-ostree x86_64 Path: Kinoite/x86_64/iso/Fedora-Kinoite-ostree-x86_64-Rawhide-20231218.n.0.iso Image: Workstation live-osbuild aarch64 Path: Workstation/aarch64/iso/Fedora-Workstation-Live-osb-Rawhide-20231218.n.0.aarch64.iso Image: Workstation live aarch64 Path: Workstation/aarch64/iso/Fedora-Workstation-Live-aarch64-Rawhide-20231218.n.0.iso = DROPPED IMAGES = Image: i3 live aarch64 Path: Spins/aarch64/iso/Fedora-i3-Live-aarch64-Rawhide-20231217.n.1.iso = ADDED PACKAGES = Package: rust-startup-disk-0.1.3-1.fc40 Summary: Interface to choose the startup volume on Apple Silicon systems RPMs:startup-disk Size:1.55 MiB Package: rust-sudo-0.6.0-1.fc40 Summary: Detect if you are running as root, restart self with sudo if needed or setup uid zero when running with the SUID flag set RPMs:rust-sudo+default-devel rust-sudo-devel Size:23.32 KiB = DROPPED PACKAGES = = UPGRADED PACKAGES = Package: PyMca-5.9.2-1.fc40 Old package: PyMca-5.9.1-1.fc40 Summary: X-ray Fluorescence Toolkit RPMs: PyMca PyMca-data Size: 20.15 MiB Size change: 17.65 KiB Changelog: * Tue Nov 21 2023 Zbigniew J??drzejewski-Szmek - 5.9.1-2 - Convert license tag to SPDX * Sun Dec 17 2023 Zbigniew J??drzejewski-Szmek - 5.9.2-1 - Version 7.2.0 (rhbz#2252290) Package: akonadi-server-24.01.80-3.fc40 Old package: akonadi-server-24.01.80-2.fc40 Summary: PIM Storage Service RPMs: akonadi-server akonadi-server-devel akonadi-server-mysql Size: 15.80 MiB Size change: 978 B Changelog: * Sun Dec 17 2023 Alessandro Astone - 24.01.80-3 - Make upgrade path for mysql subpackage Package: amg4psblas-1.1.2-1.fc40.1 Old package: amg4psblas-1.1.0-7.fc39 Summary: Algebraic Multigrid Package based on PSBLAS RPMs: amg4psblas-doc amg4psblas-mpich amg4psblas-mpich-devel amg4psblas-mpich-static amg4psblas-openmpi amg4psblas-openmpi-devel amg4psblas-openmpi-static Added RPMs: amg4psblas-mpich-static amg4psblas-openmpi-static Dropped RPMs: amg4psblas-serial amg4psblas-serial-devel Size: 748.66 MiB Size change: -506.03 MiB Changelog: * Sat Dec 16 2023 Antonio Trande - 1.1.2-1 - Release 1.1.2 - Exclude serial libraries (not fully supported) Package: blosc2-2.11.3-1.fc40 Old package: blosc2-2.11.2-2.fc40 Summary: High performance compressor optimized for binary data RPMs: blosc2 blosc2-devel Size: 1.24 MiB Size change: 2.86 KiB Changelog: * Wed Nov 29 2023 Laura Barcziova - 2.11.2-3 - [Packit config] move upstream_tag_template definition globally * Sun Dec 17 2023 Zbigniew J??drzejewski-Szmek - 2.11.3-1 - Version 2.11.3 (rhbz#2252346) Package: calibre-7.2.0-1.fc40 Old package: calibre-7.0.0-5.fc40 Summary: E-book converter and library manager RPMs: calibre Size: 51.66 MiB Size change: -231.22 KiB Changelog: * Mon Dec 11 2023 Yaakov Selkowitz - 7.0.0-6 - Fix flatpak build * Sun Dec 17 2023 Zbigniew J??drzejewski-Szmek - 7.2.0-1 - Version 7.2.0 (rhbz#2251386) Package: fast_float-6.0.0-1.fc40 Old package: fast_float-5.3.0-1.fc40 Summary: Fast & exact implementation of C++ from_chars for number types RPMs: fast_float-devel Size: 59.30 KiB Size change: 1.62 KiB Changelog: * Fri Dec 15 2023 Benjamin A. Beasley - 6.0.0-1 - Update to 6.0.0 (close RHBZ#2254687) Package: freefem++-4.14-2.fc40 Old package: freefem++-4.14-1.fc40 Summary: PDE solving tool RPMs: freefem++ freefem++-mpich freefem++-openmpi Size: 194.77 MiB Size change: 11.51 KiB Changelog: * Sun Dec 17 2023 Antonio Trande - 4.14-2 - Rebuild for superlu_dist-8.2.0 Package: giac-1.9.0.73-1.fc40 Old package: giac-1.9.0.69-1.fc40 Summary: Computer Algebra System, Symbolic calculus, Geometry RPMs: giac giac-devel giac-doc giac-xcas pgiac Size: 155.41 MiB Size change: 350.34 KiB Changelog: * Sun Dec 17 2023 Antonio Trande 1.9.0.73-1 - Update to 1.9.0 sub-73 (rhbz#2253863) Package: golang-github-gdamore-tcell-2-2.7.0-1.fc40 Old package: golang-github-gdamore-tcell-2-2.6.0-2.fc39 Summary: Alternate terminal package RPMs: golang-github-gdamore-tcell-2 golang-github-gdamore-tcell-2-devel Size: 3.14 MiB Size change: -2.51 KiB Chang
[Bug 2254730] perl-PAR-Packer-1.061 is available
https://bugzilla.redhat.com/show_bug.cgi?id=2254730 Jitka Plesnikova changed: What|Removed |Added Status|NEW |ASSIGNED CC|anon.am...@gmail.com, | |jples...@redhat.com,| |mmasl...@redhat.com | Doc Type|--- |If docs needed, set a value -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2254730 -- ___ 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: Mock Configs v39.3 released - DNF5 used for F40+ builds
On pátek 1. prosince 2023 15:04:10 CET Pavel Raiskup wrote:
> Hello maintainers!
>
> Let me announce a new release of Mock Core Configs v39.3, aka
> the configuration files for Mock, the chroot build environment manager
> for building RPMs.
>
> The notable change in this release is that we are switching the default
> package_manager from DNF4 to DNF5, according to the F40 change:
> https://fedoraproject.org/wiki/Changes/BuildWithDNF5
> Full release notes:
>https://rpm-software-management.github.io/mock/Release-Notes-Configs-39.3
>
> We plan to push this update into Fedora Copr to get some early testing
> next week. Then, depending on the releng team, we might push this into
> Koji soon. The Bodhi updates links are here:
>
> F39 https://bodhi.fedoraproject.org/updates/FEDORA-2023-0a947db1d0
> F38 https://bodhi.fedoraproject.org/updates/FEDORA-2023-6ef1e12930
> F37 https://bodhi.fedoraproject.org/updates/FEDORA-2023-cd9c489f40
> EL9 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2023-c2c4082053
> EL8 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2023-eab5217f46
>
> Note that we **will not** push these updates into Fedora stable earlier
> than on Monday 2023-12-18 (but very likely we'll wait till the next
> year, depending on the feedback).
And the push eventually happened, despite that I did not want it to
happen, yet. I probably messed up the Bodhi updates (I thought I
disabled the stable-by-time feature). Sorry, folks.
The builds often just work. But there are two issues that blocks us
from letting this update go to Fedora Copr at least:
- the builddep globbing issue
https://github.com/rpm-software-management/dnf5/pull/1088 which is
going to be fixed by a new release (just a new DNF5 release into
Rawhide means the problem is fixed)
- the weird hangs against Fedora Copr repositories
https://github.com/fedora-copr/copr/issues/3067 - this will probably
not hit you locally, but I am not sure yet.
In any case, if you need to - stay with DNF4 for a while - either do
$ cat ~/.config/mock/fedora-rawhide-x86_64.cfg
include("/etc/mock/fedora-rawhide-x86_64.cfg")
config_opts["package_manager"] = "dnf"
... or stay with the `mock-core-configs v39.2` a bit longer please.
Sorry again for the inconvenience,
Pavel
signature.asc
Description: This is a digitally signed message part.
--
___
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
