[EPEL-devel] Fedora EPEL 8 updates-testing report
The following Fedora EPEL 8 Security updates need testing: Age URL 6 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2023-76db503610 seamonkey-2.53.18-1.el8 5 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2023-ad7d095358 rdiff-backup-2.2.6-3.el8 0 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2023-a79d31df77 chromium-120.0.6099.109-1.el8 The following builds have been pushed to Fedora EPEL 8 updates-testing python3.11-ldap-epel-3.4.4-1.el8 python3.11-pyasn1-epel-0.5.1-1.el8 s3cmd-2.4.0-1.el8 Details about builds: python3.11-ldap-epel-3.4.4-1.el8 (FEDORA-EPEL-2023-d13b2c153c) An object-oriented API to access LDAP directory servers Update Information: Build for Python 3.11 on EPEL ChangeLog: * Thu Dec 14 2023 Orion Poplawski - 3.4.4-1 - Build for EPEL with Python 3.11 python3.11-pyasn1-epel-0.5.1-1.el8 (FEDORA-EPEL-2023-d13b2c153c) ASN.1 tools for Python Update Information: Build for Python 3.11 on EPEL ChangeLog: * Thu Dec 14 2023 Orion Poplawski - 0.5.1-1 - Build for EPEL with Python 3.11 s3cmd-2.4.0-1.el8 (FEDORA-EPEL-2023-f8b44aadb3) Tool for accessing Amazon Simple Storage Service Update Information: New upstream release. ChangeLog: * Fri Dec 15 2023 Frank Crawford - 2.4.0-1 - New upstream release. * Thu Nov 16 2023 Frank Crawford - 2.3.0^20231020gita2b1bdf-1 - Upgraded to latest snapshot as fix for BZ2249487. * Sat Jul 22 2023 Fedora Release Engineering - 2.3.0-6 - Rebuilt for https://fedoraproject.org/wiki/Fedora_39_Mass_Rebuild * Tue Jun 13 2023 Python Maint - 2.3.0-5 - Rebuilt for Python 3.12 References: [ 1 ] Bug #2254119 - s3cmd-2.4.0 is available https://bugzilla.redhat.com/show_bug.cgi?id=2254119 -- ___ 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
[Bug 2254783] New: perl-Getopt-Long-Descriptive-0.113 is available
https://bugzilla.redhat.com/show_bug.cgi?id=2254783 Bug ID: 2254783 Summary: perl-Getopt-Long-Descriptive-0.113 is available Product: Fedora Version: rawhide Status: NEW Component: perl-Getopt-Long-Descriptive Keywords: FutureFeature, Triaged Assignee: p...@city-fan.org Reporter: upstream-release-monitor...@fedoraproject.org QA Contact: extras...@fedoraproject.org CC: iarn...@gmail.com, p...@city-fan.org, perl-devel@lists.fedoraproject.org Target Milestone: --- Classification: Fedora Releases retrieved: 0.113 Upstream release that is considered latest: 0.113 Current version/release in rawhide: 0.112-1.fc40 URL: http://search.cpan.org/dist/Getopt-Long-Descriptive 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/7110/ To change the monitoring settings for the project, please visit: https://src.fedoraproject.org/rpms/perl-Getopt-Long-Descriptive -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2254783 Report this comment as SPAM: https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla=report-spam_desc=Report%20of%20Bug%202254783%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
[Bug 2254783] perl-Getopt-Long-Descriptive-0.113 is available
https://bugzilla.redhat.com/show_bug.cgi?id=2254783 --- Comment #2 from Upstream Release Monitoring --- Created attachment 2004461 --> https://bugzilla.redhat.com/attachment.cgi?id=2004461=edit Update to 0.113 (#2254783) -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2254783 Report this comment as SPAM: https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla=report-spam_desc=Report%20of%20Bug%202254783%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 2254783] perl-Getopt-Long-Descriptive-0.113 is available
https://bugzilla.redhat.com/show_bug.cgi?id=2254783 --- Comment #1 from Upstream Release Monitoring --- Scratch build failed. Details below: BuilderException: Build failed: Command '['rpmbuild', '-D', '_sourcedir .', '-D', '_topdir .', '-bs', '/var/tmp/thn-7l_0t9cc/perl-Getopt-Long-Descriptive.spec']' returned non-zero exit status 1. StdOut: setting SOURCE_DATE_EPOCH=1702598400 error: Bad file: ./Getopt-Long-Descriptive-0.113.tar.gz: No such file or directory RPM build errors: Bad file: ./Getopt-Long-Descriptive-0.113.tar.gz: No such file or directory Traceback: File "/usr/local/lib/python3.11/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.11/site-packages/hotness/builders/koji.py", line 229, in build raise BuilderException( 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=2254783 Report this comment as SPAM: https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla=report-spam_desc=Report%20of%20Bug%202254783%23c1 -- ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F40 Change Proposal: Unified Kernel Support Phase Two (System-Wide)
Hi, On 12/5/23 14:38, Aoife Moloney wrote: 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 == Improve support for unified kernels in Fedora. == Owner == * Name: [[User:kraxel| Gerd Hoffmann]] * Email: kra...@redhat.com * Name: [[User:vittyvk| Vitaly Kuznetsov]] * Email: vkuzn...@redhat.com == Detailed Description == See [[ Changes/Unified_Kernel_Support_Phase_1 ]] for overview and Phase 1 goals. 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. Shim's fundamentally backdooring the UEFI security infrastructure, and frankly some of what is being done is pretty sketchy and its somewhat amazing it hasn't broken by vendors cleaning up their UEFI implementations*. Furthermore, the dependency on MS signing shim is also strongly in the pragmatic but not idea category as well. Some of the stronger reasons for using shim (MOK's and 3rd party binary modules, ex nvidia) really shouldn't be considered a problem for UKI based machines as the hardware profiles need to be restricted enough that the 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, at which point its probably worth revisiting the entire initramfs boot method. For example, the current method of: load a compressed filesystem, decompress it, and then pick out the needed pieces, switch root then free the initramfs is very inferior to a "sealed volume" method that can mount and read the fs directly without all the overhead of loading/decompressing/freeing a huge blob of unused data. Furthermore, UKI are largely just a stopgap to solve the lack of a manifest like system that can validate the executable and shared libraries in the initramfs itself. Nevermind the piles and piles of configuration options that end up in the initrd for every obscure boot method (ex: where will the iscsi authentication information be placed, surely not the the kernel command line) * I would expect that the UEFI hardening to continue to the point where shim's antics are no longer allowed now that people are continuing to look at the weaknesses in the current vendors UEFI boot paths. Thanks, ** The UEFI boot configuration will get an entry for each kernel installed. ** Newly installed kernels are configured to be booted once (via BootNext). ** Successful boot of the system will make the kernel update permanent (update BootOrder). * Enable UKIs for aarch64. ** Should be just flipping the switch, dependencies such as kernel zboot support are merged. * Add a UEFI-only cloud image variant which uses UKIs. ** Also suitable for being used in confidential VMs. ** Cover both x86_64 and aarch64. Related bugs * shim: remove dependency on grub2-efi-x64 ([https://bugzilla.redhat.com/show_bug.cgi?id=2240989 buzilla 2240989]) * shim: handling of multiple lines in BOOT.CSV is inconsistent ([https://issues.redhat.com/browse/RHEL-10704 jira RHEL-10704], [https://github.com/rhboot/shim/issues/554 github 554]) * anaconda: add support for [https://www.freedesktop.org/wiki/Specifications/DiscoverablePartitionsSpec/ discoverable partitions] ([https://bugzilla.redhat.com/show_bug.cgi?id=2160074 bugzilla 2160074], [https://bugzilla.redhat.com/show_bug.cgi?id=2178043 bugzilla 2178043]) * dracut: do not create yet another initramfs for UKIs ([https://github.com/dracutdevs/dracut/pull/2521 github PR 2521]) * kernel: enable UKIs on aarch64 ([https://gitlab.com/cki-project/kernel-ark/-/merge_requests/2818 MR 2818]) == Feedback == == Benefit to Fedora == * Better secure boot support: the UKI initrd is covered by the signature. * Better support for tpm measurements and confidential computing. ** measurements are more useful if we know what hashes to expect for the initrd. ** measurements are more useful without grub.efi in the boot path (which measures each grub.cfg line processed). * More robust boot process ** generating the initrd on the installed system is fragile == Scope == * Proposal owners: ** updates for virt-firmware and uki-direct packages. ** enable UKIs on aarch64 ([https://gitlab.com/cki-project/kernel-ark/-/merge_requests/2818 MR 2818]). ** prepare kickstart ([https://pagure.io/fedora-kickstarts.git Fedora kickstarts]) changes for generating UKI enabled images. * Other developers: ** installer/anaconda: implement discoverable partition support. ** bootloader/shim: fix bugs. ** Fedora
Re: F40 Change Proposal: Unified Kernel Support Phase Two (System-Wide)
Hi, On 12/6/23 11:26, Vitaly Kuznetsov wrote: Gerd Hoffmann writes: Hi, Does that mean that the Linux EFI boot code knows how to call back to shim to get the certificates instead of reading the firmware directly? No. The linux efi stub doesn't need that. shim.efi does: (a) Set efi variables, where the linux kernel can read the certificates from. This works the same way for both traditional kernels and UKIs. (b) provide an efi protocol for bootloaders, which can be called by grub and systemd-boot to verify the signature for binaries they load (typically the linux kernel, but could also be fwupd.efi). Note, the protocol is also used by systemd-stub (the base for UKIs) to verify cmdline addons, see commit 05c9f9c2517c54b98d55f08f8afa67c79be861e8 Author: Luca Boccassi Date: Fri May 12 00:55:58 2023 +0100 stub: allow loading and verifying cmdline addons this AFAIU means that we also need shim in the boot chain if we want to support these addons. That is true, buts its also false. The LoadImage protocol is more than capable of doing exactly what that patch does (AFAIK), and using strictly the UEFI protocols for validation. Of course if you want to backdoor the process then you need to add shim into it, which is part of what that patch is doing. -- ___ 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
pyproject-rpm-macros 1.11.0: %pyproject_save_files gains the -l flag (and more)
Hello Pythonistas,
pyproject-rpm-macros 1.11.0 is available in Rawhide + updates-testing for older
releases.
https://bodhi.fedoraproject.org/updates/?packages=pyproject-rpm-macros
I plan to sync it to c9s eventually early next year.
It contains one new feature and several smaller bugfixes:
The new -l/-L flag to %pyproject_save_files
===
As said by Maxwell G on this list [1]:
%pyproject_save_files automatically handles marking license files
with %license when a build backend installs them into a package's
dist-info directory and the License-File header is specified in the
METADATA file. Currently, only setuptools and hatchling meet this
criteria. Notably, poetry and flit do not support this. They will
install license texts into the dist-info directory, but they do not add
the License-File metadata. The License-File tag is not standardized, and
discussion on PEP 639 which defines this standard has stalled. I believe
relying on this feature is a problem, as if a project changes build
systems or some other config and a packager doesn't realize, suddenly
the license file won't be marked with %license or even worse, not
installed at all. Since the pyproject macros read the build backend from
pyproject.toml without packagers having to manually specify anything
(which is generally great!), this situation seems likely to occur.
You can now use `%pyproject_save_files -l` to assert at least one license file
was detected and marked as %license. This is good in case you want a protection
from an accidental silent drop of the %license file in a next release.
Note that the -l flag only asserts *at least one license file was detected*.
It can still mean one of multiple files are silently dropped during a package
upgrade, but that's unlikely to happen for unrelated reasons (such as a change
of a build backend upstream).
For the time being, this assertion is opt-in only. Use `%pyproject_save_files
-L` if you list the %license file manually and you would like to explicitly
opt-out from this check in case it ever becomes the default (no such plan
exists for the time being).
(Note that this still needs to be documented in the Python packaging
guidelines.)
Prevent incorrect usage of %pyproject_buildrequires -R with -x/-e/-t
Using `%pyproject_buildrequires -R` with -x, -t, or -e previously silently
discarded the -R option. Combining either of the flags with -R is actually not
possible and will now error properly.
https://bugzilla.redhat.com/2244282
Show a better error message when %pyproject_install finds no wheel
==
When there is no wheel to install (e.g. when you forget to run
%pyproject_wheel), the underlying pip error message was leaking:
ERROR: You must give at least one requirement to install (maybe you meant "pip
install /builddir/build/BUILD/Pello-1.0.4/pyproject-wheeldir"?)
It has been explicitly changed to:
ERROR: %pyproject_install found no wheel in %{_pyproject_wheeldir}
/builddir/build/BUILD/Pello-1.0.4/pyproject-wheeldir
https://bugzilla.redhat.com/2242452
Fix %pyproject_buildrequires -w when build backend is installed and pip isn't
=
Packages using `%pyproject_buildrequires -w` would fail to build if the build
backend was already (manually) installed before pip.
This was happening e.g. when testing a local version of the RPM with the build
backend and running something like:
$ mock init
$ mock install ../my-rpms/pytohn3-hatchling-1.2.3-1.fc50.noarch.rpm
$ fedpkg mockbuild -N
But it was also possible to achieve with manual BuildRequires:
BuildRequires: pytohn3-hatchling
...
%generate_buildrequires
%pyproject_buildrequires -w
The %pyproject_buildrequires macro generated a BuildRequires on pip, but it
attempted to build a wheel using pip before the generated pip dependency was
installed. This has now been fixed and the macro will "restart" in case pip is
not yet available to build the wheel.
https://bugzilla.redhat.com/2169855
---
Happy packaging.
Special thanks to Maxwell G, Karolina Surma, and Benjamin Beasley for help with
this release.
[1]
https://lists.fedoraproject.org/archives/list/python-devel@lists.fedoraproject.org/thread/YDIHALW766GRSYU3GL635QER2MQABML6/
--
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
[Bug 2254730] New: perl-PAR-Packer-1.061 is available
https://bugzilla.redhat.com/show_bug.cgi?id=2254730 Bug ID: 2254730 Summary: perl-PAR-Packer-1.061 is available Product: Fedora Version: rawhide Status: NEW Component: perl-PAR-Packer Keywords: FutureFeature, Triaged Assignee: jples...@redhat.com Reporter: upstream-release-monitor...@fedoraproject.org QA Contact: extras...@fedoraproject.org CC: anon.am...@gmail.com, jples...@redhat.com, mmasl...@redhat.com, perl-devel@lists.fedoraproject.org Target Milestone: --- Classification: Fedora Releases retrieved: 1.061 Upstream release that is considered latest: 1.061 Current version/release in rawhide: 1.059-2.fc40 URL: https://metacpan.org/dist/PAR-Packer/ 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/3189/ To change the monitoring settings for the project, please visit: https://src.fedoraproject.org/rpms/perl-PAR-Packer -- 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%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
[EPEL-devel] Re: Broken version of wsdd released in EPEL7
I'll see if I can remember that next time. In the meanwhile, how does it get fixed? Does the package get pulled and 0.7.0-1 re-released until the maintainer builds, perhaps, a 0.7.1-2? Obviously, untagging 0.7.1 and re-tagging 0.7.0 won't help anyone who has already picked up the update. On 15/12/2023 14:46, Troy Dawson wrote: The way to stop it from being pushed is to give it negative karma in it's bodhi testing. https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2023-4e7c9d636e You know what's strange, the updates-testing report that get's automatically generated, doesn't put the bodhi link in for the new packages. It gives all sorts of details about the new package, but not the bodhi testing link. But it does give the link for the older packages. On Fri, Dec 15, 2023 at 12:20 AM Nick Howitt via epel-devel wrote: When it was announced that wsdd-0.7.1-1.el7 was available for testing, I responded to the announcement that it was a bad installation with breaking changes and raised a bug https://bugzilla.redhat.com/show_bug.cgi?id=2253415. Unfortunately, my bug report and mailing list response have been ignored and now there has bee a breaking release. How can we get it fixed and what could I have done differently to get it fixed prior to release? Regards, Nick -- ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue -- ___ epel-devel mailing list --epel-devel@lists.fedoraproject.org To unsubscribe send an email toepel-devel-le...@lists.fedoraproject.org Fedora Code of Conduct:https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines:https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives:https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org Do not reply to spam, report it:https://pagure.io/fedora-infrastructure/new_issue -- ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[EPEL-devel] Re: Broken version of wsdd released in EPEL7
The way to stop it from being pushed is to give it negative karma in it's bodhi testing. https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2023-4e7c9d636e You know what's strange, the updates-testing report that get's automatically generated, doesn't put the bodhi link in for the new packages. It gives all sorts of details about the new package, but not the bodhi testing link. But it does give the link for the older packages. On Fri, Dec 15, 2023 at 12:20 AM Nick Howitt via epel-devel < epel-devel@lists.fedoraproject.org> wrote: > When it was announced that wsdd-0.7.1-1.el7 was available for testing, I > responded to the announcement that it was a bad installation with > breaking changes and raised a bug > https://bugzilla.redhat.com/show_bug.cgi?id=2253415. Unfortunately, my > bug report and mailing list response have been ignored and now there has > bee a breaking release. How can we get it fixed and what could I have > done differently to get it fixed prior to release? > > Regards, > > > Nick > -- > ___ > epel-devel mailing list -- epel-devel@lists.fedoraproject.org > To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org > Do not reply to spam, report it: > https://pagure.io/fedora-infrastructure/new_issue > -- ___ epel-devel 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: [Fedocal] Reminder meeting : ELN SIG
I’m canceling the meeting today as we don’t have anything urgent to discuss. The next meeting will be in January. On Thu, Dec 14, 2023 at 7:00 AM wrote: > Dear all, > > You are kindly invited to the meeting: >ELN SIG on 2023-12-15 from 12:00:00 to 13:00:00 US/Eastern >At fedora-meet...@irc.libera.chat > > The meeting will be about: > > > > Source: https://calendar.fedoraproject.org//meeting/10568/ > > -- > ___ > 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
FYI: morphio changed license from LGPL-3.0 to Apache-2.0
Hi folks, Just an FYI. Morphio has changed its license from LGPL-3.0 to Apache-2.0 in the latest version 3.3.7: https://github.com/BlueBrain/MorphIO/pull/467 -- Thanks, Regards, Ankur Sinha "FranciscoD" (He / Him / His) | https://fedoraproject.org/wiki/User:Ankursinha Time zone: Europe/London signature.asc Description: PGP signature -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[EPEL-devel] Re: Broken version of wsdd released in EPEL7
On 15/12/2023 08:20, Nick Howitt wrote: When it was announced that wsdd-0.7.1-1.el7 was available for testing, I responded to the announcement that it was a bad installation with breaking changes and raised a bug https://bugzilla.redhat.com/show_bug.cgi?id=2253415. Unfortunately, my bug report and mailing list response have been ignored and now there has bee a breaking release. How can we get it fixed and what could I have done differently to get it fixed prior to release? Regards, Nick Not only are the changes breaking, but it can never run in the released state because it looks for its parameters in /etc/defaults/wsdd, but creates them in /etc/sysconfig/wsdd leading to an immediate failure on start.-- ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[EPEL-devel] Broken version of wsdd released in EPEL7
When it was announced that wsdd-0.7.1-1.el7 was available for testing, I responded to the announcement that it was a bad installation with breaking changes and raised a bug https://bugzilla.redhat.com/show_bug.cgi?id=2253415. Unfortunately, my bug report and mailing list response have been ignored and now there has bee a breaking release. How can we get it fixed and what could I have done differently to get it fixed prior to release? Regards, Nick -- ___ 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
Orphaned sassc and it's build dependencies.
sassc rubygem-hrx rubygem-linked-list -- ___ 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
