Re: how to do minor bump using %autorelease?
On 27-04-2024 23:51, Sandro wrote: On 27-04-2024 22:41, Julian Sikorski wrote: I need to rebuild mame on F40 only for qt-6.7. On rawhide, mame-0.265-1.fc41 is already built against it so I only need to build mame-0.265-1.fc40.1. Can it be done using %autorelease? Make an empty commit: git commit -m 'Rebuild for mame' --allow-empty Or rather: git commit -m 'Rebuild for qt-6.7' --allow-empty Sorry, was only half reading the message. -- 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: how to do minor bump using %autorelease?
On 27-04-2024 22:41, Julian Sikorski wrote: I need to rebuild mame on F40 only for qt-6.7. On rawhide, mame-0.265-1.fc41 is already built against it so I only need to build mame-0.265-1.fc40.1. Can it be done using %autorelease? Make an empty commit: git commit -m 'Rebuild for mame' --allow-empty -- 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: Idea: pynose as drop-in replacement for nose
On 11-04-2024 13:54, Miro Hrončok wrote: On 11. 04. 24 11:55, Sandro wrote: While I ponder those thoughts some more, moving forward in either direction, the next step would be writing a change proposal? I'd start by: Packaging pynose without hacks (only making it Conflict with nose, no compatibility Provides, Obsoletes or dist-infos). That way, pro-active packagers can switch already. And the change proposal can then describe what will be *added* to pynose, rather than describing the approach from scratch. I put together a first draft for a change proposal [1]. The pynose package has been reviewed and will be imported as soon as all fires have been put out. Miro, I added you as a proposal owner as per the comment "owners of all affected packages need to be included here" since you are maintaining python-nose. I would appreciate a review from people having more experience witch change proposals before I submit it. Lumír, if you have a list of packages that are affected by the removal of nose setup/teardown functions/methods, I can add them as a separate bullet point list to the proposal as well as to the testing repo in Copr and start working on those, porting them back to `nosetests`. [1] https://fedoraproject.org/wiki/Changes/ReplaceNoseWithPynose -- Sandro -- ___ 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: Idea: pynose as drop-in replacement for nose
On 11-04-2024 15:30, Sandro wrote: I see "# Package doesn't provide any tests" in the %check section. That certainly feels a bit dodgy. This successor of a test framework decided to ditch all of the tests it used to have? That is certainly a red flag. More like a chicken and egg story, maybe? If I were to provide a testing framework, I'd very much like to use that testing framework for testing. Anyway, I'll contact upstream asking them about it. It's the least I can do. I'll also ask about the documentation link on PyPI, which points to the RTD page of ye olde . Upstream uses GitHub Actions for testing. I haven't looked into how those are set up. Apparently they also test with pynose on SeleniumBase (same maintainer, see elsewhere in this thread). While this still not provides us with the ability to test downstream, all tests I've run while investigating the feasibility of my idea so far haven't brought up any issues. If anyone wants to chime in, here is the ticket: https://github.com/mdmintz/pynose/issues/25 Last but not least, the documentation link on PyPI was fixed right away and will be in the next release. -- Sandro -- ___ 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: Idea: pynose as drop-in replacement for nose
On 11-04-2024 15:49, Ben Beasley wrote: For a proposed nose successor, pynose doesn’t seem to have gained much community traction so far: it has seven stars on GitHub[1] (compared to 770 for nose2, which itself was never that widely adopted and has fewer than ten dependent packages in Fedora); and the imperfect but fairly useful reverse dependency index at Wheelodex[2] shows only three packages that explicitly depend on it. Well, Wheelodex doesn't show pysb. They have just switched from nose to pynose. When looking into updating the package to the latest release the noses were no longer aligned (pun intended). That's how I started looking into pynose. As far as I can tell, pynose exists because SeleniumBase[3] found it easier to fork nose than to port away from it. I’m *definitely* not saying we should only package things with a bunch of GitHub stars, but I do have some concerns about whether or not pynose is going to remain a generally-useful project in the medium-to-long term. I think you are right there. The current maintainer of pynose is also a/the maintainer of SeleniumBase. Currently, pynose is seeing regular releases - seven since May 2023. When I just inquired regarding unit tests, I received a response within minutes. This might just be coincidence. But it shows the project is alive. Regarding usefulness, almost all packages in Fedora still depending on nose worked out of the box when I tested with a build of pynose mimicking nose also in the Python meta data. Two packages I couldn't test since they are currently FTBFS. One package, pycdio, is using `%python3 setup.py nosetests`. I have not yet looked into why that works with nose but not with pynose. But that line could simply be changed back to `nosetests -v`. I think the takeaway here is swapping an unmaintained package for a maintained package. How widely it will get adopted seems lees important to me. The future will tell. [1] https://github.com/mdmintz/pynose/stargazers [2] https://www.wheelodex.org/projects/pynose/rdepends/ [3] https://github.com/seleniumbase/SeleniumBase -- Sandro -- ___ 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: Idea: pynose as drop-in replacement for nose
On 11-04-2024 15:17, Miro Hrončok wrote: On 11. 04. 24 15:05, Sandro wrote: On 11-04-2024 13:54, Miro Hrončok wrote: On 11. 04. 24 11:55, Sandro wrote: While I ponder those thoughts some more, moving forward in either direction, the next step would be writing a change proposal? I'd start by: Packaging pynose without hacks (only making it Conflict with nose, no compatibility Provides, Obsoletes or dist-infos). That way, pro-active packagers can switch already. That makes sense. Review is up [1]. If enough packagers adapt, I may not need to go through the changes process. And the change proposal can then describe what will be *added* to pynose, rather than describing the approach from scratch. Since predicting the future is difficult, I'll start on writing up a proposal while the package is being introduced, anyway. [1] https://bugzilla.redhat.com/show_bug.cgi?id=2274514 I see "# Package doesn't provide any tests" in the %check section. That certainly feels a bit dodgy. This successor of a test framework decided to ditch all of the tests it used to have? That is certainly a red flag. More like a chicken and egg story, maybe? If I were to provide a testing framework, I'd very much like to use that testing framework for testing. Anyway, I'll contact upstream asking them about it. It's the least I can do. I'll also ask about the documentation link on PyPI, which points to the RTD page of ye olde . -- Sandro -- ___ 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: Idea: pynose as drop-in replacement for nose
On 11-04-2024 13:54, Miro Hrončok wrote: On 11. 04. 24 11:55, Sandro wrote: While I ponder those thoughts some more, moving forward in either direction, the next step would be writing a change proposal? I'd start by: Packaging pynose without hacks (only making it Conflict with nose, no compatibility Provides, Obsoletes or dist-infos). That way, pro-active packagers can switch already. That makes sense. Review is up [1]. If enough packagers adapt, I may not need to go through the changes process. And the change proposal can then describe what will be *added* to pynose, rather than describing the approach from scratch. Since predicting the future is difficult, I'll start on writing up a proposal while the package is being introduced, anyway. [1] https://bugzilla.redhat.com/show_bug.cgi?id=2274514 -- Sandro -- ___ 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: Idea: pynose as drop-in replacement for nose
On 10-04-2024 17:50, Miro Hrončok wrote:
On 10. 04. 24 17:30, Sandro wrote:
On 10-04-2024 12:04, Miro Hrončok wrote:
On 09. 04. 24 19:30, Sandro wrote:
Therefore, I'm thinking of introducing pynose as a drop in
replacement of deprecated nose. Pynose uses the same namespace as
nose, but provides python3dist(pynose). Thus adding Provides: for
nose would make it a drop-in replacement for packages currently
depending on nose.
FTR We MUST NOT add RPM Provides for python3dist(nose) unless we
package nose dist-info metadata.
Thanks for pointing that out. I was indeed experimenting with it.
Is there some documentation or example for packaging extra dist-info
metadata?
Not really, because it is a hack that should not be done if it can be
avoided.
You can see a working example in python-lark
https://src.fedoraproject.org/rpms/python-lark/c/c7a9aa2e7b0b1d9d621ac60f73c854fdcc154ab2
Agreed. If we do add python3dist(nose) it needs to work not cause more
issues. Most packages I've looked at recently have a BR for
python3-nose. That's covered by adding "%py_provides python3-nose".
But dependency resolution in %pyproject_buildrequires uses
python3dist. If the package configuration has a dependency on nose
declared, I would like that to be satisfiable, both in RPM and pip, by
installing python3-pynose.
If that is too much hassle or simply (currently) not possible, a
fallback to not providing nose at all, is also possible. In that case
more packages might need to be patched and we need to educate people
te replace dependencies on nose with pynose.
My preference at the moment is for the former.
If we are to retire python-nose at the same time, I'd do:
- have python3-pynose %py_provides (and Obsolete) python3-nose
- don't mess with dist metadata at all
That way:
- packages that use upstream requirements will need to be updated
(preferably upstream first => good)
- packages that manually BuildRequire python3-nose will likely keep
working
If the pynose package has a "nose" importable module, providing
python3-nose even follows
https://docs.fedoraproject.org/en-US/packaging-guidelines/Python/#_provides_for_importable_modules
Well, `pynose` provides `nose` as an importable module, which is
installed into `%{python3_sitelib}/nose`. Since that conflicts with
python3-nose, proper Provides and Obsoletes are required, indeed.
Thanks for the example, I used that to properly provide `nose`. Building
against that package reduced the troublesome packages to one (two more
are currently FTBFS in rawhide/F40) compared to 11+2[1] when using only
`%py_provides python3-nose`.
I think that justifies carrying the "hack". Moreover, `nose` has been
dead for a long time upstream, yet we still have packages depending on
it. In a way the justification here doesn't differ very much from that
of `lark`.
I agree that maintainers of packages still depending on `nose` should
ask upstream to switch to `pynose` or some other testing framework. Yet,
I wouldn't be surprised that exactly those packages are also
un(der)maintained upstream.
While I ponder those thoughts some more, moving forward in either
direction, the next step would be writing a change proposal?
[1] Some failures were unrelated to `nose` vs. `pynose` and have been
fixed by having `pynose` require `setuptools`.
-- Sandro
--
___
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: Idea: pynose as drop-in replacement for nose
On 10-04-2024 12:04, Miro Hrončok wrote: On 09. 04. 24 19:30, Sandro wrote: Therefore, I'm thinking of introducing pynose as a drop in replacement of deprecated nose. Pynose uses the same namespace as nose, but provides python3dist(pynose). Thus adding Provides: for nose would make it a drop-in replacement for packages currently depending on nose. FTR We MUST NOT add RPM Provides for python3dist(nose) unless we package nose dist-info metadata. Thanks for pointing that out. I was indeed experimenting with it. Is there some documentation or example for packaging extra dist-info metadata? I also played around pith setuptools' `provide` only to learn later on that pip ignores it entirely (as well as `obsoletes`, which is deprecated). So, the pyproject-rpm-macros are probably not honoring that either. For example %pyproject_buildrequires queries Python for installed packages (hence it reads the packaged dist-info/egg-info metadata) and it will see nose is not installed. It will then query dnf to install python3dist(nose). dnf will install pynose. %pyproject_buildrequires will see nose is not installed. It will query dnf to install python3dist(nose) again. dnf will install nothing. The %pyproject_buildrequires phase will end prematurely when dnf installs nothing. Agreed. If we do add python3dist(nose) it needs to work not cause more issues. Most packages I've looked at recently have a BR for python3-nose. That's covered by adding "%py_provides python3-nose". But dependency resolution in %pyproject_buildrequires uses python3dist. If the package configuration has a dependency on nose declared, I would like that to be satisfiable, both in RPM and pip, by installing python3-pynose. If that is too much hassle or simply (currently) not possible, a fallback to not providing nose at all, is also possible. In that case more packages might need to be patched and we need to educate people te replace dependencies on nose with pynose. My preference at the moment is for the former. -- Sandro -- ___ 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: Idea: pynose as drop-in replacement for nose
On 10-04-2024 11:57, Lumír Balhar wrote:
This sounds like an interesting idea for one more reason. We are
currently working on the update of pytest to version 8 and that version
no longer runs nose setup/teardown functions/methods which, as far as we
know now, is a change that breaks a lot of packages we previously
migrated from nose to pytest.
For some of those it might be easier to switch them to pynose than to
try to fix their tests for pytest.
Sure. That could probably be done independently of the "greater" goal of
making pynose a drop-in replacement. Of course, it still requires the
package to be added to Fedora. It's kinda ready for review. But I'd like
to polish it some more. Stay tuned.
But we already saw some successors of nose and they weren't really
successfull.
Well, from my preliminary examination of the packages that failed with
pynose, I found six could trivially be reverted to using nosetests.
Another six failed for unrelated reasons. And four need some more
investigation[1].
For the trivial packages it was usually replacing `%{__python3} setup.py
test` with `nosetests -v`. Going by the project's description, "pynose
is an updated version of nose". Not a successor that needs adaptation,
but basically a continuation. Time will tell.
[1] Ik know that adds up to 16. One package sneaked its way onto the
list, though it works fine with pynose.
-- Sandro
--
___
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
Idea: pynose as drop-in replacement for nose
Hi, While looking into a package upgrade I came across pynose [1]. It appears to be a drop-in replacement for nose [2], which has been deprecated in Fedora 32 [3]. There are still quite a few packages depending on nose, that have not yet moved away from it. The official successor to nose is nose2 [4]. But that package does not support all of the behavior of nose. Therefore, I'm thinking of introducing pynose as a drop in replacement of deprecated nose. Pynose uses the same namespace as nose, but provides python3dist(pynose). Thus adding Provides: for nose would make it a drop-in replacement for packages currently depending on nose. As a preliminary smoke test I built all packages depending on nose in Copr against pynose [5]. Packages failing to build against pynose I also built against nose [6]. I haven't checked all packages in detail yet, but the amount packages failing appears manageable (17). Going by [3] I suppose this would also need to go through the changes process. If so, I'd be willing to drive that. But I could use some help/support since this would be my first change proposal. In a way this e-mail is kind of an informal general rehearsal. With that said, please shoot! [1] https://github.com/mdmintz/pynose [2] https://github.com/nose-devs/nose [3] https://fedoraproject.org/wiki/Changes/DeprecateNose [4] https://github.com/nose-devs/nose2 [5] https://copr.fedorainfracloud.org/coprs/gui1ty/pynose [6] https://copr.fedorainfracloud.org/coprs/gui1ty/nose Cheers, -- Sandro FAS: gui1ty Matrix:Penguinpee Elsewhere: [Pp]enguinpee -- ___ 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
[EPEL-devel] Re: EPEL9 updates obsoleted
On 07-04-2024 19:04, Antonio T. sagitter wrote: Can this update be re-activated or i have to rebuild everything? https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2024-c154b725ab Have you tried re-submitting the side tag to Bodhi? -- ___ 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: %pyproject_buildrequires -r/-x: Attempt to read runtime dependencies from pyproject.toml?
On 27-03-2024 15:48, Karolina Surma wrote: One way to mitigate would be to make the proposed behavior opt-in only, with the possibility to either build wheel with -w option (already existing) or e.g. -p (now-proposed: reading from pyproject.toml) in case backend doesn't have prepare_metadata_for_build_wheel. However, this adds a layer of complexity for packagers and macros maintainers. The questions we'd love your input for: - Should %pyproject_buildrequires try to read dependencies from pyproject.toml first and fall back to calling hooks only if that fails? - Should %pyproject_buildrequires call the hook and try to fall back to reading dependencies from pyproject.toml when the hook is not availbale? - Should this behavior exist but not be the default (explicit flag would be required to opt-in)? - Can you think of a better alternative than the ones described here? I'd be in favor of option two in combination with option three. That is, set a flag explicitly two enable the behavior described in option two, fallback to pyproject.toml if hook is not available. Doing it that way also means the current behavior remains unchanged for package maintainers being unaware similar to the -l flag of %pyproject_save_files. I'm approaching this purely from a packager's point of view. I dislike having the wheel built twice, once for the metadata and again for the package itself. The documentation could point to the build backends, where it makes sense enabling -p, e.g. meson-python. -- Sandro -- ___ 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: F41 Change Proposal: Pytest 8 (self-contained)
On 05-04-2024 23:45, Aoife Moloney wrote: == Summary == Update to a new upstream release of pytest that is not completely compatible with previous releases. Pytest 8 is a major upstream release removing a lot of deprecated functions and introducing breaking changes. I was wondering how this will pan out with the introduction of Python 3.13, which is also planned for F41 and comes with its own set of breaking changes. Some of those affecting tests. The current test builds are run against Python 3.12. Will all Python packages also be tested against Python 3.13 with pytest 8 later on? Does that even make sense? Anyway, it's two major updates affecting the Python ecosystem, which are both aiming at F41. Maybe letting the dust settle on Python 3.13 first and then updating pytest to the next major release will let package maintainers (and upstream) focus more. Just some food for thought. -- 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 03-04-2024 18:35, Jens-Ulrik Petersen wrote: I took botan as a penance for my sins in the previous thread haha הַלְּלוּ־יָהּ Thanks! -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Reminder: F40 final freeze starts next week (2024-04-02)
On 26-03-2024 22:15, Adam Williamson wrote: On Tue, 2024-03-26 at 21:34 +0100, Sandro wrote: On 26-03-2024 16:25, Kevin Fenzi wrote: So, please take this time to do any last minute testing and bugfixing and make sure any packages you expect to be in the final f40 base repositories are pushed stable before next Tuesday (2024-04-02). I was just wondering, and someone else with me, if today's updates would still make it in time? If not, I thank you for the reminder nonetheless, but would also like to ask to have it sent in time for updates to still be able to land in the release before freeze happens. Of course, there's always the option of going around begging for (instant) karma ... You still have a week until next Tuesday, so...yes. We are one week down the road. I've submitted an update a week ago shortly after Adam's reply was sent (March 26, 21:48 UTC). Final freeze is now in effect and the update[1] has *not* made it to stable. It's still in testing. Luckily, this update can wait until after freeze. I'm glad I decided to ask for karma for another update submitted earlier the same day. [1] https://bodhi.fedoraproject.org/updates/FEDORA-2024-3ebd1e2c45 -- 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
Planning to orphan freeimage
Hi I intend to orphan freeimage. Probably, the package should rather just be retired. Upstream is effectively dead, and there is a constant stream of CVEs getting filed against the package which are not addressed upstream. Over the past two years I've fixed many of those CVEs downstream, but the most recent batch of 15 CVEs is leading me to capitulate. Currently, the following packages require freeimage: PerceptualDiff allegro5 cegui06 deepin-image-viewer gazebo imv ogre photoqt A minimal impact check: PerceptualDiff: freeimage is a hard dependency. PerceptualDiff itself has seen its last commit 4 years ago, last release 8 years ago allegro5: freeimage is an optional dependency cegui06: freeimage is an optional dependency deepin-image-viewer: freeimage is a hard dependency gazebo: freeimage is a hard dependency. (The fedora package is for "gazebo-classic" https://github.com/gazebosim/gazebo-classic, which points to https://github.com/gazebosim/gz-sim as the "latest version", which does not appear to require freeimage) imv: freeimage is an optional dependency ogre: freeimage is an optional dependency photoqt: freeimage is an optional dependency Thanks 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: xz backdoor
On 01-04-2024 19:12, Adam Williamson wrote: On Mon, 2024-04-01 at 09:32 -0500, Michael Catanzaro wrote: On Sun, Mar 31 2024 at 06:52:53 PM +00:00:00, Christopher Klooz wrote: "Fedora Linux 40 branched users (i.e. pre-Beta) likely received the potentially vulnerable 5.6.0-2.fc40 build if the system updated between March 2nd and March 6th. Fedora Linux 40 Beta users only using stable repositories are NOT impacted. Fedora Linux 39 and 38 users are also NOT impacted." -> only pre-beta, not beta, affected -> F40 beta using stable NOT impacted (without challenging the previously distributed assumption that testing is disabled by default) That's still the same false information, isn't it? It looks correct to me. The bug was fixed prior to the final release of F40 beta, This is not really correct, or at least at all relevant. The bug wasn't in F40 Beta simply because the update never made it to 'stable'. Only 'stable' packages go into *composes*. However, saying that is not really useful because anyone who *installed* Beta and then updated it regularly may have got the vulnerable package. We should not say anything to give people the impression that if they installed Beta, they don't need to worry. That is not true or helpful. so describing it as "pre-beta" makes sense. And people who used only the stable repos were indeed not affected. The article later clarifies that updates-testing is enabled by default (although it would be nicer to do this higher up rather than lower down the page). For the same reason I think it's dangerous and not useful to try and draw this distinction between notional "people who only use stable repos" and people who use testing. Who would actually install F40 but then manually turn updates-testing off? Very few people. I don't think we should talk about this because it just confuses the issue. It would be like saying a stable release security issue that appeared in a stable update didn't affect people who turned off the updates repo. Technically true, but people don't do that, why would we say it? This boils down to the initial confusion as to when `updates-testing` is switched off. Both Justin and I thought it would be turned off again as soon as Beta is officially released. If you take that confusion into account, making that distinction makes perfect sense. Unfortunately, it turned out to be the wrong assumption. We should have a simple and clear message that covers the most common and important case: if you installed Fedora 40 and updated regularly during the vulnerable time frame, you very likely got the vulnerable package and should take appropriate action. We should not confuse this with unnecessary verbiage about stable and testing and pre-Beta and post-Beta. Agreed. I'm sure the text would have been different if the confusion (see above) hadn't happened. OTOH, I also expect users, even inexperienced users, to bring some common sense. I oppose having to put "contents may be hot" on a coffee cup ... -- 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: xz backdoor
On 31-03-2024 20:54, Christopher Klooz wrote: On 31/03/2024 20.52, Christopher Klooz wrote: On 31/03/2024 20.21, Michael Catanzaro wrote: On Sun, Mar 31 2024 at 09:56:04 AM -05:00:00, Michael Catanzaro wrote: I'm really frustrated with our communication regarding this issue. Does anybody know who can fix this? The Fedora Magazine article has been fixed (thanks!). "*Fedora Linux 40 branched users (i.e. pre-Beta) likely received the potentially vulnerable /5.6.0-2.fc40/ build <https://bodhi.fedoraproject.org/updates/FEDORA-2024-4417db3376> if the system updated between March 2nd and March 6th*. Fedora Linux 40 Beta users only using stable repositories are NOT impacted. Fedora Linux 39 and 38 users are also NOT impacted." -> only pre-beta, not beta, affected -> F40 beta using stable NOT impacted (without challenging the previously distributed assumption that testing is disabled by default) That's still the same false information, isn't it? Justin just has shown up in discourse. I suggested to get in touch with you, Adam or Kevin since he seemed to be convinced the article is fine as it is. When I refresh the article, it still seems to be unchanged. Is the update you mean already online Michael? I clarified what's wrong with Justin in a DM on Matrix. He was on the same garden path as I was regarding "Beta release" vs. "Final release". There will be another update to the article. -- 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: xz backdoor
On 31-03-2024 00:41, Kevin Fenzi wrote: On Sat, Mar 30, 2024 at 11:12:02PM +0100, Sandro wrote: From what I understood, F40 Beta, the official Beta release, available from the website as of March 26, has updates-testing disabled by default. That Nope. was confirmed by several people in #devel yesterday when the Fedora Magazine article was still being worked on. I am pretty sure I said the opposite... nirik: Branched enables updates-testing... so if you installed f40 anytime, you will have it enabled and if you then applied updates it would be in them nirik: yes, we disable updates-testing by default right before release. I guess that could have been read as right before beta release, but thats not the case or what I meant. ;) It's before _Final_ release that we disable updates-testing. It's enabled by default from when we branch the release off until the time right before release when we switch it (usually with a freeze break/blocker bug) Thanks for clarifying that. Context matters and there was a lot going on in the channel at the time. My wording was to the extend covering composes before Beta was released. I used the the term "pre-Beta". Good to know that the switch is made "pre-Final". It's the RC composes that are made after branching and before Beta is declared GO, that have updates-testing enabled by default. I was one of the persons raising that point. I'm less certain wrt upgrades in the period between branching and Beta release. I think the confusion here is "Beta Release" vs "Final release". Yup! I was thinking "Beta Release". We enable updates-testing at branching time all the way until right before "Final release". :) If that is incorrect and Beta shipped with updates-testing enabled, deliberately or by accident, then I stand corrected. Yes, it did/does. :) The logic is that most people who install betas or pre-releases want to help test updates. If for some reason they don't, they can disable it, but the default option is on. That makes sense. I thought along the same lines as to why it is enabled by default right after branching. Thanks also to @adamwill and @pbrobinson for further clarification/confirmation later on. The following sentence in the magazine article: "Fedora Linux 40 Beta users may have received it from the testing repositories, which are enabled by default in branched versions (i.e. pre-Beta) to assist with testing." should probably be amended in the light of above. Though, most people affected probably took measures already and new installations won't be affected. -- 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: xz backdoor
On 30-03-2024 22:10, Christopher Klooz wrote: On 30/03/2024 20.08, Sandro wrote: On 30-03-2024 13:26, Christopher Klooz wrote: I don't know how the assumption came up that F40 is only affected if users opted in for testing, but that interpretation already ended up in the Fedora Magazine and in the official linkedin post of Fedora (I already asked to correct it). I believe that statement is correct, since none of the xz-5.6.x packages ever made it to F40 stable. The furthest they've got was updates-testing, which is not enabled in the official Beta releases. However, if you installed F40 before Beta was released, then updates-testing is enabled and users may have installed the vulnerable package with a simple `sudo dnf upgrade`. I admit the wording could be clearer in that opting in to updates-testing might have been done on your behalf simply by installing F40 sometime between branching and the Beta release. Some users might not be aware of that. It may also help providing some simple instructions on how users can check if they have any of the vulnerable versions installed in the article itself. I see a comment to that extent. So, the situation around F40 is somewhat murky since a lot of factors come into play, but the statement that 5.6.x never made to F40 stable is correct[1] and therefore users not having updates-testing enabled could not have installed 5.6.x without expressly enabling it. [1] https://bodhi.fedoraproject.org/updates/?search=xz-5.6 I don't think this is right. Adam Williamson and Michael Catanzaro already confirmed that F40 has testing enabled by default because it is pre-release. It was also confirmed that some packages could have been installed on F40 variants (see also the points of Michael and Richard here in the devel mailing list). Michael and Adam also wrote some references in the Fedora Discussion topic [1] about this. From what I understood, F40 Beta, the official Beta release, available from the website as of March 26, has updates-testing disabled by default. That was confirmed by several people in #devel yesterday when the Fedora Magazine article was still being worked on. It's the RC composes that are made after branching and before Beta is declared GO, that have updates-testing enabled by default. I was one of the persons raising that point. I'm less certain wrt upgrades in the period between branching and Beta release. If that is incorrect and Beta shipped with updates-testing enabled, deliberately or by accident, then I stand corrected. It is obviously still an issue that is evolving and what seems clear now might prove different later. But so far I tend to leave the discussion topic as it is and ensure that F40 users expect being compromised and get informed to act correspondingly with the suggested actions. However, I already added a point how users can check if they have a malicious build. I agree. Once the levees broke, news was traveling fast and, for some, panic may have set in, not helping in determining what information is accurate. Advise to err on the side of caution, check your system and upgrade if unsure, is certainly what I would tell anyone. Even distros (Arch, Gentoo) where it turned out the payload wasn't injected, acted out of an abundance of caution, put out advisories and updates for their users. What's written on Discussion looks to be covering the broad spectrum. Maybe the Fedora Magazine article could link to that post for further clarification. [1] https://discussion.fedoraproject.org/t/attention-malicious-code-in-current-pre-release-testing-versions-variants-f40-and-rawhide-affected-users-of-f40-rawhide-need-to-respond/110683/36 -- 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: xz backdoor
On 30-03-2024 13:26, Christopher Klooz wrote: I don't know how the assumption came up that F40 is only affected if users opted in for testing, but that interpretation already ended up in the Fedora Magazine and in the official linkedin post of Fedora (I already asked to correct it). I believe that statement is correct, since none of the xz-5.6.x packages ever made it to F40 stable. The furthest they've got was updates-testing, which is not enabled in the official Beta releases. However, if you installed F40 before Beta was released, then updates-testing is enabled and users may have installed the vulnerable package with a simple `sudo dnf upgrade`. I admit the wording could be clearer in that opting in to updates-testing might have been done on your behalf simply by installing F40 sometime between branching and the Beta release. Some users might not be aware of that. It may also help providing some simple instructions on how users can check if they have any of the vulnerable versions installed in the article itself. I see a comment to that extent. So, the situation around F40 is somewhat murky since a lot of factors come into play, but the statement that 5.6.x never made to F40 stable is correct[1] and therefore users not having updates-testing enabled could not have installed 5.6.x without expressly enabling it. [1] https://bodhi.fedoraproject.org/updates/?search=xz-5.6 -- 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: Reminder: F40 final freeze starts next week (2024-04-02)
On 26-03-2024 16:25, Kevin Fenzi wrote: So, please take this time to do any last minute testing and bugfixing and make sure any packages you expect to be in the final f40 base repositories are pushed stable before next Tuesday (2024-04-02). I was just wondering, and someone else with me, if today's updates would still make it in time? If not, I thank you for the reminder nonetheless, but would also like to ask to have it sent in time for updates to still be able to land in the release before freeze happens. Of course, there's always the option of going around begging for (instant) karma ... -- 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
Next Open NeuroFedora Meeting: Monday, 25 March 2024 (today) at 13:00 UTC
Hello everyone, Please join us at the next Open NeuroFedora team meeting on Monday, 25 March at 13:00 UTC. The meeting is a public meeting, and open for everyone to attend. You can join us over on Matrix in the Fedora Meeting channel: https://matrix.to/#/#meeting:fedoraproject.org You can use this link to see the local time for the meeting: https://www.timeanddate.com/worldclock/fixedtime.html?msg=Open+NeuroFedora+Meeting=20240325T13=1440=1 or you can use this command in a terminal: $ date -d 'Monday, March 25, 2024 13:00 UTC' The meeting will be chaired by @Penguinpee. The agenda for the meeting is: - New introductions and roll call. - Tasks from last meeting: https://meetbot.fedoraproject.org/latest/neurofedora - Open Pagure tickets: https://pagure.io/neuro-sig/NeuroFedora/issues?status=Open=S%3A+Next+meeting - Package health check: https://packager-dashboard.fedoraproject.org/dashboard?groups=neuro-sig - Open package reviews check: https://bugzilla.redhat.com/show_bug.cgi?id=fedora-neuro - CompNeuro lab compose status check for F40: https://koji.fedoraproject.org/koji/packageinfo?packageID=30691 - Neuroscience query of the week - Next meeting day, and chair. - Open floor. We hope to see you there! The meeting announcement is also posted on the NeuroFedora blog here: https://neuroblog.fedoraproject.org/2024/03/25/next-open-neurofedora-meeting-25-march-1300-utc.html You can learn more about NeuroFedora here: https://neuro.fedoraproject.org Cheers, -- Sandro FAS: gui1ty Matrix:Penguinpee Elsewhere: [Pp]enguinpee -- ___ 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: QGIS rebuild needed after GRASS GIS update
Hi Markus I'm happy to help coordinating the grass update. Note however that: - If the update does not carry ABI changes (and hence soname bumps), a rebuild of QGIS is not needed - If The update does carry a soname bump, it should be avoided in stable releases Sandro On 19.03.24 13:44, Markus Neteler wrote: Hi, While being a maintainer of the GRASS GIS rpms for years, I am not fully sure about the procedure to get QGIS rebuilds triggered (in a side-tag with GRASS GIS). I have updated GRASS GIS to the latest stable: https://bugzilla.redhat.com/show_bug.cgi?id=2268514 and submitted it to - https://src.fedoraproject.org/rpms/grass/commits/rawhide - https://src.fedoraproject.org/rpms/grass/commits/f40 - https://src.fedoraproject.org/rpms/grass/commits/f39 What would be the next step? I don't have write access for QGIS (https://src.fedoraproject.org/rpms/qgis). Sorry if this is RTFM, the procedure isn't fully clear to me :) Thanks, Markus -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Heads-up: Updating libunibreak to 6.1 in rawhide and F40
On 10-03-2024 18:10, Sandro wrote: On 03-03-2024 21:42, Sandro wrote: I plan to update libunibreak to version 6.1 in rawhide and F40 in about a week. This update comes with an soname bump. The following packages depend on libunibreak: fedrq wrsrc -Xs libunibreak -F name coolreader fbreader krita naev I ran a smoke test in Copr [1] rebuilding those packages against libunibreak-6.1 and all packages built successfully. I added the maintainers in Bcc. Please use the following side tags for rebuilding your package against the updated libunibreak: rawhide: f41-build-side-85041 f40: f40-build-side-85045 [1] https://copr.fedorainfracloud.org/coprs/gui1ty/libunibreak_6/builds/ I will be moving forward with submitting the update to rawhide even though none of the dependent packages have been rebuilt in aforementioned side tags. I can wait a little longer with the F40 update, but I still think it's worth updating the package in F40 as well. Let me know if you think otherwise. Updates for F40 have been pushed now as well. Only fbreader was not rebuilt against updated `libunibreak`. -- 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: Announcement: Retiring zlib and minizip-compat from Rawhide
On 13-03-2024 22:12, Germano Massullo wrote: I hope this is the last time I have to deal with minizip invasive changes (both upstream and downstream). With the new keepassxc release, I had to test it against all minizip* packages on all active branches https://src.fedoraproject.org/rpms/keepassxc/c/3ec631d9175e82d9d8320374037e3d78bf7e190d?branch=rawhide Fingers crossed and thanks for your work on KeePassXC. -- 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: Heads-up: Updating libunibreak to 6.1 in rawhide and F40
On 10-03-2024 18:10, Sandro wrote: On 03-03-2024 21:42, Sandro wrote: I plan to update libunibreak to version 6.1 in rawhide and F40 in about a week. This update comes with an soname bump. The following packages depend on libunibreak: fedrq wrsrc -Xs libunibreak -F name coolreader fbreader krita naev I ran a smoke test in Copr [1] rebuilding those packages against libunibreak-6.1 and all packages built successfully. I added the maintainers in Bcc. Please use the following side tags for rebuilding your package against the updated libunibreak: rawhide: f41-build-side-85041 f40: f40-build-side-85045 [1] https://copr.fedorainfracloud.org/coprs/gui1ty/libunibreak_6/builds/ I will be moving forward with submitting the update to rawhide even though none of the dependent packages have been rebuilt in aforementioned side tags. The update has been pushed to rawhide along with krita (thank you Alessandro) and coolreader. Maintainers of fbreader and naev could not be reached. I can wait a little longer with the F40 update, but I still think it's worth updating the package in F40 as well. Let me know if you think otherwise. Should you prefer, you are welcome to add me as co-maintainer and I will take care of the rebuild myself. I held back on the F40 update. I'm thinking of postponing for another week or maybe dropping the update entirely. I'm open to suggestions. -- 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: Heads-up: Updating libunibreak to 6.1 in rawhide and F40
On 03-03-2024 21:42, Sandro wrote: I plan to update libunibreak to version 6.1 in rawhide and F40 in about a week. This update comes with an soname bump. The following packages depend on libunibreak: fedrq wrsrc -Xs libunibreak -F name coolreader fbreader krita naev I ran a smoke test in Copr [1] rebuilding those packages against libunibreak-6.1 and all packages built successfully. I added the maintainers in Bcc. Please use the following side tags for rebuilding your package against the updated libunibreak: rawhide: f41-build-side-85041 f40: f40-build-side-85045 [1] https://copr.fedorainfracloud.org/coprs/gui1ty/libunibreak_6/builds/ I will be moving forward with submitting the update to rawhide even though none of the dependent packages have been rebuilt in aforementioned side tags. I can wait a little longer with the F40 update, but I still think it's worth updating the package in F40 as well. Let me know if you think otherwise. Should you prefer, you are welcome to add me as co-maintainer and I will take care of the rebuild myself. Cheers, -- Sandro FAS: gui1ty Matrix:Penguinpee Elsewhere: [Pp]enguinpee -- ___ 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
Review requests: mingw-directxmath, python-jsonformatter
Hi I'd apprechiate a review of the following two packages: - mingw-directxmath: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=2268585 (required for mingw-gstreamer1-plugins-bad-free 1.24.0) - python-jsonformatter: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=2268579 (required for pgadmin4 8.4) Both are very simple packages. Happy to review in exchange. Thanks 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: [Fedora-legal-list] Trivy for licenses
On 04-03-2024 07:59, Miroslav Suchý wrote: It would welcome if anyone can help Robert here: https://bugzilla.redhat.com/show_bug.cgi?id=2235055 I had a look and it seems the package is currently stuck on broken python-pymaven-patch, which requires python-lxml < 5~~. In rawhide and f40 python-lxml was updated to 5.1.0 two months ago. For about as long there has been a PR open for python-pymaven-patch removing that version constraint. Notably, the maintainer of python-pymaven-patch is the same person, who submitted the scancode-toolkit review request. There may be more trouble down the road. But for the moment, I don't see how others can help driving this forward. A proven packager could merge the PR. But I don't know how eclipseo, who's a proven packager, would feel about that. -- 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
Heads-up: Updating libunibreak to 6.1 in rawhide and F40
I plan to update libunibreak to version 6.1 in rawhide and F40 in about a week. This update comes with an soname bump. The following packages depend on libunibreak: fedrq wrsrc -Xs libunibreak -F name coolreader fbreader krita naev I ran a smoke test in Copr [1] rebuilding those packages against libunibreak-6.1 and all packages built successfully. I added the maintainers in Bcc. Please use the following side tags for rebuilding your package against the updated libunibreak: rawhide: f41-build-side-85041 f40: f40-build-side-85045 [1] https://copr.fedorainfracloud.org/coprs/gui1ty/libunibreak_6/builds/ Cheers, -- Sandro FAS: gui1ty Matrix:Penguinpee Elsewhere: [Pp]enguinpee -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Orphaning raptor
On 19-02-2024 14:28, Jaroslav Škarvada wrote: I would like to step-out from raptor maintenance [1] and orphan it. Currently, raptor is obsoleted by raptor2 and IMHO unsupported. It seems it's required only by the COPASI package in Fedora Traverso also BRs raptor-devel. But that package appears to be dead in the water. The domain of the upstream URL has gone. That was also used for the sources and the package hasn't seen an update for almost five years. -- 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: zuul-config-generator - add your packages to Zuul CI seamlessly
On 06-02-2024 14:43, Cristian Le via devel wrote: Are you using IRC? The IRC bridge is dead I think around that time. You might have to use a proper matrix client in this case. I joined the Matrix room (https://matrix.to/#/#fedora-ci:fedora.im). We are active even yesterday. Then I somehow do not get to see the recent messages after joining or I entered the wrong room. -- ___ 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: zuul-config-generator - add your packages to Zuul CI seamlessly
On 06-02-2024 14:27, Ondrej Mosnáček wrote:
On Tue, 6 Feb 2024 at 14:18, Sandro wrote:
On 06-02-2024 10:32, Karolina Surma wrote:
Please note, if you want to add hundreds of packages at once, coordinate
with the Zuul folks -- they know best how much it can handle.
Do you happen to have contact details or a pointer to them?
I have an issue with Zuul (not related to adding packages) that I'd like
them to look into, but so far I have been unable to figure out where to
report that or whom to contact.
I usually report them to https://pagure.io/fedora-ci/general/issues -
you can see a bunch of existing Zuul issues there and there is even an
issue label for "Zuul CI", so one can assume this is the right place.
Thank you. I will report the issue there.
My apologies for hijacking the ${SUBJECT}.
-- 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: zuul-config-generator - add your packages to Zuul CI seamlessly
On 06-02-2024 14:27, Cristian Le via devel wrote: Can join the #fedora-ci:fedoraproject.org matrix group. I did. Not much activity there though. The last message (before mine) dates back to July 25, 2023. Thanks for the pointer nonetheless. -- 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: zuul-config-generator - add your packages to Zuul CI seamlessly
On 06-02-2024 10:32, Karolina Surma wrote: Please note, if you want to add hundreds of packages at once, coordinate with the Zuul folks -- they know best how much it can handle. Do you happen to have contact details or a pointer to them? I have an issue with Zuul (not related to adding packages) that I'd like them to look into, but so far I have been unable to figure out where to report that or whom to contact. -- 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: Fw: [Bug 2066129] mingw-libgsf-1_14_52 is available
On 06.02.24 8:50 AM, Marc-André Lureau wrote: Hi On Mon, Feb 5, 2024 at 8:52 PM Daniel P. Berrangé wrote: On Mon, Feb 05, 2024 at 05:34:06PM +0100, Dan Horák wrote: Hi, could someone in the mingw team look at mingw-libgsf / libgsf (please see the bug forwarded below)? If I see right, then the standalone mingw-libgsf package should be retired as there are mingw builds from the regular libgsf package, which seems to be regularly updated. Copying Marc-André who added the mingw sub-RPMs to the native package. The mingw-libgsf should have been retired on rawhide, as soon as the libgsf native had a successful build with mingw packages. At this point I guess it'll need retiring on both rawhide and f39 Correct, I missed that. Geg, Sandro, can you retire the mingw-libgsf package? I've retired the package, but not sure if it worked 100% as I'm not listed as package admin. 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: mingw packaging: equivalent of %cmake_build, %cmake_install macros?
On 29.01.24 10:38 PM, Eric Smith wrote: On Mon, Jan 29, 2024, 02:32 Sandro Mani wrote: For mingw, the most common approach is %build %mingw_cmake %mingw_make_build %install %mingw_make_install # Don't forget this one |%mingw_debug_install_post| Thank you, but as I said in my request, that is exactly what I already tried. It worked fine for pugixml and zipios, but failed for fmt. In the fmt.spec you posted, I see %mingw_cmake -G Ninja [...] this means that you are generating ninja build scripts, not Makefiles. If you want to use ninja, you should call %mingw_ninja after %mingw_cmake -G Ninja. To generate Makefiles, call %mingw_cmake without the -G Ninja, and after this %mingw_make_build 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: poppler soname bump in Rawhide soon
On 30-01-2024 12:15, Michael J Gruber wrote: Marek Kasik venit, vidit, dixit 2024-01-30 12:02:34: Hi, I plan to rebase poppler to 24.02.0 once it is released. It will be probably released this week and I would like to get it to rawhide before the branching together with rebuilds of dependent packages. I'll prepare the build in a side tag and will message relevant maintainers to rebuild their packages there. The packages which will need rebuilds: calligra gambas3 gdal gdcm inkscape kf5-kitinerary libreoffice pdf2djvu scribus That list is surprisingly short. For example, poppler-glib requires a specific poppler version, and via poppler-glib-devel that affects more packages (zathura-pdf-poppler comes to my mind). How about: $ fedrq wrsrc -s poppler -F name LabPlot OpenSceneGraph R-pdftools abiword apvlv atril booksorg bookworm boomaga calibre calligra cantor claws-mail deepin-api deepin-file-manager diff-pdf diffoscope diffpdf docparser efl engauge-digitizer evince extractpdfmark fbida gambas3 gdal gdcm geeqie gimagereader gimp gle gnome-commander graphviz gscan2pdf gsequencer gummi inkscape kbibtex kf5-kfilemetadata kf5-kitinerary kf6-kfilemetadata kile kitinerary krita ktikz latex2html libcupsfilters libppd libreoffice mat2 okular pdf2djvu pdf2svg pdfgrep pdfpc pg_auto_failover photoqt poppler-sharp python-img2pdf python-paperwork-backend python-pdf2image python-pikepdf python3-poppler-qt5 qcomicbook qpdfview qt5-qtwebengine qt6-qtwebengine rubygem-activestorage rubygem-asciidoctor-pdf rubygem-poppler scribus setzer tellico texmaker texstudio texworks tikzit tracker-miners tumbler vfrnav vips weston xournal xournalpp xreader yacreader zathura-pdf-poppler -- 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: Looking for new maintainer for boswars
On 30-01-2024 13:33, Hans de Goede wrote: Hi Sandro, On 1/30/24 12:48, Sandro wrote: On 30-01-2024 10:41, Hans de Goede wrote: I used to do a lot of gaming related Fedora packaging and I still maintain over 200 pkgs, but I really don't have much time for Fedora package maintainership anymore. Many thanks! I'm sure many still enjoy the fruits of your labor. The last few years I have been limiting my package maintainership to fixing FTBFS, which for many game packages is fine since they are not seeing any new upstream releases. Boswars however still has an active upstream and 6 months ago a new version was released. I have been unable to find the time to upgrade to this new release and I don't expect I will find the time to do so in the near future. So I hope someone else is willing to takeover as maintainer, if not then I'll have to orphan boswars. I'd be willing to give that a shot. As always, co-maintainers are more than welcome. Great thank you. If you can give me your FAS username then I can hand over the package to you and you can merge your PR yourself :) Sure. My FAS username is gui1ty. It was mentioned in my signature ;) Happy to merge my own PR. -- 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: Looking for new maintainer for boswars
On 30-01-2024 10:41, Hans de Goede wrote: I used to do a lot of gaming related Fedora packaging and I still maintain over 200 pkgs, but I really don't have much time for Fedora package maintainership anymore. Many thanks! I'm sure many still enjoy the fruits of your labor. The last few years I have been limiting my package maintainership to fixing FTBFS, which for many game packages is fine since they are not seeing any new upstream releases. Boswars however still has an active upstream and 6 months ago a new version was released. I have been unable to find the time to upgrade to this new release and I don't expect I will find the time to do so in the near future. So I hope someone else is willing to takeover as maintainer, if not then I'll have to orphan boswars. I'd be willing to give that a shot. As always, co-maintainers are more than welcome. Note boswars is currently also FTBFS I don't know if the new upstream release will fix this, but I would start with rebasing to the new upstream release. It won't. The issue is actually with `python3-scon`, which used to provide /usr/bin/scons-3. It no longer does. Changing the executable name to 'scons' makes the package build again. I'll submit a PR. There also is one ABRT bug when can be closed when updating to the new release since the backtrace will be invalid for the new version. Ack. Cheers, -- Sandro FAS: gui1ty Matrix:Penguinpee Elsewhere: [Pp]enguinpee -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Heads-up: abseil-cpp 20240116.0 coming to F40/Rawhide
On 29-01-2024 11:16, Dominik 'Rathann' Mierzejewski wrote:
Hello, Ben.
On Sunday, 28 January 2024 at 19:43, Ben Beasley wrote:
In one week, 2024-02-04, or slightly later, I plan to update abseil-cpp from
20230802.1 to 20230116.0 (Abseil LTS branch, Jan 2024)[1] in side tags for
Correct me if I'm wrong, but this looks like a downgrade:
$ rpmdev-vercmp 0 20230802.1 1 0 20230116.0 1
0:20230802.1-1 > 0:20230116.0-1
Did you mean "update to 20240116.0"?
He did, see ${subject}.
--
___
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: mingw packaging: equivalent of %cmake_build, %cmake_install macros?
For mingw the more recent "%cmake_build" and "%cmake_install" have never
been implemented (one could add them [1]).
For mingw, the most common approach is
%build
%mingw_cmake
%mingw_make_build
%install
%mingw_make_install
# Don't forget this one
|%mingw_debug_install_post|
See also [1] for an example.
Hope this helps
Sandro
[1] https://src.fedoraproject.org/rpms/proj/blob/rawhide/f/proj.spec
[1]
https://src.fedoraproject.org/rpms/mingw-filesystem/blob/rawhide/f/macros.mingw64
On 29.01.24 10:13 AM, Eric Smith wrote:
I'm trying to add mingw build support to the fmt package spec. I've
done this previously with the pugixml and zipios packages, and
submitted the spec diffs to the package maintainer of those.. Both
packages use cmake. Both in the %build section use %cmake then
%cmake_build, and in the %install section use %cmake_install. As
expert neither on cmake nor on mingw, I'm somewhat baffled as to why
there are %cmake_build and %cmake_install macros, but no corresponding
%mingw_cmake_build and %mingw_cmake_install macros. Is there some
equivalent that just happens to not be obvious to me? What I found
worked for both pugixml and zipios was:
original: %cmake; %cmake_build
original install: %cmake_install
added for mingw build: %mingw_cmake (and did not add anything
equivalent to %cmake_build)
added for mingw install: %mingw_make_install; %{?mingw_debug_install_post)
Unfortunately this simple attempt failed for fmt. The %mingw_cmake
doesn't cause an error, but also doesn't build fmt. The attempted
%mingw_make_install results in: "make: *** No rule to make target
'install'. Stop." Perhaps this has to do with the fmt build also
using Ninja, which pugixml and zipios do not.
If anyone can offer advice, it would be much appreciated. I started
from the specs from the packages:
pugixml-1.13-4
zipios-2.2.5.0-7
fmt-10.0.0-3
My modified spec files are at:
http://www.brouhaha.com/~eric/fedora-packaging-test/
Best regards,
Eric
@brouhaha
--
___
devel mailing list --devel@lists.fedoraproject.org
To unsubscribe send an email todevel-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
Next Open NeuroFedora Meeting: Monday, 29 January 2024 (today) at 13:00 UTC
Hello everyone, Please join us at the next Open NeuroFedora team meeting on Monday, 29 January at 13:00 UTC. The meeting is a public meeting, and open for everyone to attend. You can join us over on Matrix in the Fedora Meeting channel: https://matrix.to/#/#meeting:fedoraproject.org You can use this link to see the local time for the meeting: https://www.timeanddate.com/worldclock/fixedtime.html?msg=Open+NeuroFedora+Meeting=20240129T13=%3A=1 or you can use this command in a terminal: $ date --date='Monday, 13:00 UTC' The meeting will be chaired by @Penguinpee. The agenda for the meeting is: - New introductions and roll call. - Tasks from last meeting: https://meetbot.fedoraproject.org/latest/neurofedora - Open Pagure tickets: https://pagure.io/neuro-sig/NeuroFedora/issues?status=Open=S%3A+Next+meeting - Package health check: https://packager-dashboard.fedoraproject.org/dashboard?groups=neuro-sig - Open package reviews check: https://bugzilla.redhat.com/show_bug.cgi?id=fedora-neuro - CompNeuro lab compose status check for F40: https://koji.fedoraproject.org/koji/packageinfo?packageID=30691 - Neuroscience query of the week - Next meeting day, and chair. - Open floor. We hope to see you there! The meeting announcement is also posted on the NeuroFedora blog here: https://neuroblog.fedoraproject.org/2024/01/26/next-open-neurofedora-meeting-29-january-1300-utc.html You can learn more about NeuroFedora here: https://neuro.fedoraproject.org Cheers, -- Sandro FAS: gui1ty Matrix:Penguinpee Elsewhere: [Pp]enguinpee -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: HEADS UP: update to tesseract-5.3.4
On 28.01.24 10:48 AM, Sandro Mani wrote: On 28.01.24 4:21 AM, Yaakov Selkowitz wrote: On Sat, 2024-01-27 at 23:20 +0100, Sandro Mani wrote: I'll be updating to tesseract-5.3.4 in rawhide shortly, which carries a soname bump (despite it being a minor version, unfortunately upstream versions the SO with the package version). I'll rebuild the following dependent packages: ffmpeg gimagereader mupdf opencv python-PyMuPDF qpdfview R-tesseract skanpage zathura-pdf-mupdf Since it's not clear from your email, please be sure to do this in a side tag. Yes, the builds will be submitted to f40-build-side-82395 This is now done, except for ffmpeg which was already FTBFS. 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: HEADS UP: update to tesseract-5.3.4
On 28.01.24 4:21 AM, Yaakov Selkowitz wrote: On Sat, 2024-01-27 at 23:20 +0100, Sandro Mani wrote: I'll be updating to tesseract-5.3.4 in rawhide shortly, which carries a soname bump (despite it being a minor version, unfortunately upstream versions the SO with the package version). I'll rebuild the following dependent packages: ffmpeg gimagereader mupdf opencv python-PyMuPDF qpdfview R-tesseract skanpage zathura-pdf-mupdf Since it's not clear from your email, please be sure to do this in a side tag. Yes, the builds will be submitted to f40-build-side-82395 Thanks 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
HEADS UP: update to tesseract-5.3.4
Hi I'll be updating to tesseract-5.3.4 in rawhide shortly, which carries a soname bump (despite it being a minor version, unfortunately upstream versions the SO with the package version). I'll rebuild the following dependent packages: ffmpeg gimagereader mupdf opencv python-PyMuPDF qpdfview R-tesseract skanpage zathura-pdf-mupdf Thanks 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: List of long term FTBFS packages to be retired in February
On 24-01-2024 17:38, Miro Hrončok wrote: Dear maintainers. Based on the current fail to build from source policy, the following packages should be retired from Fedora 40 approximately one week before branching. yaksa zbyszek I updated and build yaksa and checked that mpich is still building against the updated version. We have quite a few packages depending on mpich in the neuro-sig pool of packages, so we wouldn't want to see mpich going FTBFS. @zbyszek, feel free to add neuro-sig as co-maintainers to the package. For now there's a PR [1] for you. [1] https://src.fedoraproject.org/rpms/yaksa/pull-request/1 -- 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: Fedora Linux 37 is EOL
On 15-01-2024 09:52, Vít Ondruch wrote: Any update? This ticket is still open: https://bugzilla.redhat.com/show_bug.cgi?id=2235331 I believe the script is chugging along. I've seen a few more bugs being closed the last couple of days. -- 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 15-01-2024 18:11, Miro Hrončok wrote:
On 15. 01. 24 16:46, Maxwell G wrote:
Report started at 2024-01-15 15:04:52 UTC
The following packages are orphaned and will be retired when they
are orphaned for six weeks, unless someone adopts them. If you know
for sure
that the package should be retired, please do so now with a proper
reason:
https://fedoraproject.org/wiki/How_to_remove_a_package_at_end_of_life
...
Depending on: python-Pympler (64), status change: 2024-01-05 (1 weeks
ago)
...
python-attrs (maintained by: @python-packagers-sig, churchyard,
lbalhar)
python-attrs-23.1.0-4.fc39.src requires python3dist(pympler) =
1.0.1
This seems unused, I've opened:
https://src.fedoraproject.org/rpms/python-attrs/pull-request/19
The rest of the impacted packages pretty much depend on attrs, not pympler.
$ repoquery -q --repo=rawhide{,-source} --whatrequires python3-Pympler
matrix-synapse+cache_memory-0:1.98.0-3.fc40.x86_64
matrix-synapse-0:1.98.0-3.fc40.src
python-attrs-0:23.1.0-4.fc39.src
That is correct and the suggested removal of Pympler from attrs will
solve the problem for the indirectly impacted packages.
On the other hand, Pympler is what shows up on Packager Dashboard for
orphan-impacted packages as "remotely depends on orphaned package".
There, the dependency graph makes it clear that the intermediary package
is python-attrs.
I'm thinking the distinction between directly impacted and remotely
impacted as shown on the dashboard is actually rather helpful (as is the
graph itself). Maybe that is something that could be improved in the
scripts output?
For python-google-crc32c the list of indirectly impacted packages is
rather long. In fact, so long that the script truncates it. When I
looked into it last time, trying to find the connection between
python-plotnine and google-crc32c, I eventually gave up. That was before
I discovered the graph on the dashboard.
Today I ended up with something "horrible" like
fedrq wrsrc -X -F source python-google-crc32c | \
fedrq wrsrc -i -X -F source | \
fedrq wrsrc -i -X -F source | \
fedrq wrsrc -i -X -F source | \
fedrq wrsrc -i -X -F source
to arrive at plotnine.
I have yet to find a simple way of producing an output akin to the
dashboard graph for showing the chain of dependencies between two
packages. I'm open to suggestions.
-- 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
License correction for python-elephant
The license for python-elephant has been converted to SPDX and corrected to: BSD-3-Clause AND MIT It used to be just 'BSD'. Cheers, -- Sandro FAS: gui1ty IRC: Penguinpee Elsewhere: [Pp]enguinpee -- ___ 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 Linux 37 is EOL
On 08-01-2024 17:16, Adam Williamson wrote: On Mon, 2024-01-08 at 16:10 +, Aoife Moloney wrote: I'll get the EOL-close script running again, it kept timing out so I thought it was finished but clearly not - my mistake and apologies :-/ Just so folks are aware, the EOL closure uses a script: https://pagure.io/fedora-pgm/pgm_scripts/blob/main/f/closebugs/fedora_bz.py which runs bug-by-bug - so it comments on, or closes, one bug at a time. This means it takes a very long time to do the ~2-3k bugs that are typically commented-on then closed at EOL time. Doing it this way was Ben's preference (he wanted to be able to see that every bug was updated and get a notice from the script for any single bug change that failed), but if it causes problems for Aoife we can have it mass-update bugs instead, since Bugzilla and its API allow that (now, they probably didn't when the predecessors to this script were written). I'll just have to check with the BZ admin whether there's any upper limit on how many bugs you can request a mass change to at once. I just noticed that some bugs with version '37' were still open while others were already closed. I think it makes perfect sense to do a mass update to the extend possible to have this process finish quicker. It's fairly easy to query for bugs that may have been missed afterwards. That's essentially what I did with my query. You may also have to check with mail admins, because it might break the levees of the mail river doing a mass update, I could imagine. -- 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
Review Request: mingw-python-blinker
Hi I'd appreciate a review of mingw-python-blinker [1] which is a new dependency of mingw-python-flask-3.0.0. Happy to review in exchange. Thanks Sandro [1] https://bugzilla.redhat.com/show_bug.cgi?id=2257095 -- ___ 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: Planning to update to podofo-0.10.1 + review request for podofo-compat for legacy 0.9.x library
On 05.01.24 17:57, Zbigniew Jędrzejewski-Szmek wrote: On Sun, Dec 17, 2023 at 04:44:36PM +, 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. Bump in the new year. PTAL. Hi Zbyszek I already took care of this: https://koji.fedoraproject.org/koji/buildinfo?buildID=2334737 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: Non responsive maintainer check for marxin
On 05-01-2024 01:50, Priscila Gutierres wrote:
I would like to apologize if it seems that I’m being rude asking for a
review in this thread.
It's perfectly fine asking for a review. But that should go into its own
mail to the list or, preferably, to <${package}-maintainers@fp.o>.
Currently, this thread aims to solve the maintainer situation with
regards to pebble. Once that's done, the package will be handed over to
an active maintainer.
Since you appear to be interested in maintaining pebble, you might even
get to be added as a maintainer once the current situation has been solved.
My point of view is that if the package is a dependency and no one is
looking on it, it would be a priority to keep it up to date.
That depends...
I don’t know if merging it would be possible, since the maintainer is not
responding, if not, I can close it.
Leave it open. A proven packager can still merge it or you may get to
merge it yourself once the package has been handed over.
Also, I noticed any maintainer can merge it.
Yes. Anyone with commit rights can merge. But currently there's only one
person enlisted and only that person can add co-maintainers.
I am a new maintainer and I don’t want to create polemics, I am here to
hear and learn, but if I don’t participate in the discussion is more hard
to learn. In any case, I apologize again if I was impolite.
It's all good. This thread is regarding the non-responsive maintainer
check [1]. It shouldn't become a discussion thread. That's all I was/am
concerned about.
[1]
https://docs.fedoraproject.org/en-US/fesco/Policy_for_nonresponsive_package_maintainers/
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
Re: Non responsive maintainer check for marxin
On 04-01-2024 23:05, Priscila Gutierres wrote: I bumped python-pebble to the latest version. Can someone please review this PR? https://src.fedoraproject.org/rpms/python-pebble/pull-request/3 Reviewing the PR is not a problem. However, who would merge it, once approved? That needs a proven packager in the current situation, since the sole maintainer is unresponsive. No offense, but you are kinda hijacking this thread. -- 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: Non responsive maintainer check for marxin
On 02-01-2024 20:28, Priscila Gutierres wrote: Does any package depend on python-pebble? I could not find anything running repoquery --whatrequires python-pebble You need to query for `python3-pebble`. $ dnf repoquery --whatrequires python3-pebble Last metadata expiration check: 0:04:03 ago on Tue 02 Jan 2024 20:57:02. cvise-0:2.8.0-1.fc39.x86_64 python3-bluepyopt-0:1.14.3-1.fc39.x86_64 python3-bluepyopt-0:1.14.6-5.fc39.x86_64 I use `fedrq` these days. $ fedrq wr -s python3-pebble cvise-2.9.0-1.fc40.src python-bluepyopt-1.14.6-5.fc40.src -- 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: Troubleshooting MD RAID assembly not working after upgrade to F39
On 12/27/23 23:41, Sandro wrote: Thanks for sparring! Whatever the outcome, I'll report here and on discussion. As promised, here is the outcome of a lengthy investigation. While I was on the right track right from the start, I failed to recognize (something about moving parts, some trees and a forest). The culprit turns out to be `blkid`, which returns incomplete information for, in my case, the raid partitions using version 1.1 superblock. For more info see: https://bugzilla.redhat.com/show_bug.cgi?id=2249392 or, for the journey diary, see: https://discussion.fedoraproject.org/t/system-fails-to-boot-after-dnf-system-upgrade-due-to-missing-md-raid-devices/100218 Cheers, -- Sandro FAS: gui1ty IRC: Penguinpee Elsewhere: [Pp]enguinpee -- ___ 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
Orphaned python-compressed-rtf and python-red-black-tree-mod
Hi, I orphaned python-compressed-rtf and python-red-black-tree-mod. These were brought into Fedora as dependencies of extract-msg. However, I've decided to not pursue this any further. Instead, I will maintain extract-msg and its dependencies in Copr [1]. [1] https://copr.fedorainfracloud.org/coprs/gui1ty/extract-msg/ Cheers, -- Sandro FAS: gui1ty IRC: Penguinpee Elsewhere: [Pp]enguinpee -- ___ 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: Troubleshooting MD RAID assembly not working after upgrade to F39
On 12/28/23 00:47, Sandro wrote: On 12/28/23 00:04, Samuel Sieb wrote: On 12/27/23 08:20, Sandro wrote: I added `level` and `num-devices` to all entries in mdadm.conf and rebooted. It didn't change anything. Manual assembly still freezes the system as well. You need to also update the initramfs using dracut or the modified mdadm.conf won't be available at boot. Ah, good point. I'll give that a shot tomorrow. For now I will have a good rest knowing that there's still something I haven't tried (correctly). ;) I tried two things: 1) adding `level` and `num-devices` to the ARRAY definitions 2) Adding DEVICE section and `devices` to the ARRAY lines With both changes I updated initramfs and rebooted. Unfortunately, the issue remains unsolved. I have now reached out to the linux-raid mailing 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
Re: Troubleshooting MD RAID assembly not working after upgrade to F39
On 12/28/23 00:04, Samuel Sieb wrote: On 12/27/23 08:20, Sandro wrote: I added `level` and `num-devices` to all entries in mdadm.conf and rebooted. It didn't change anything. Manual assembly still freezes the system as well. You need to also update the initramfs using dracut or the modified mdadm.conf won't be available at boot. Ah, good point. I'll give that a shot tomorrow. For now I will have a good rest knowing that there's still something I haven't tried (correctly). ;) -- ___ 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: Troubleshooting MD RAID assembly not working after upgrade to F39
On 12/27/23 22:48, pgnd wrote: without seeing all the details, unfound superblocks aren't good. But isn't the information `mdadm --examine` prints coming from the superblock stored on the device? The magic number, that this command reports, matches what was expected (a92b4efc). I can access that information for each and every of the component devices. if you were assembling with the wrong metadata format, that'd be unsurprising. but, it sounds like these_were_ working for you at some point. Yes, they were working right until I upgraded from f37 to f39, which was mostly (actually only) hammering the SSD, which holds the root volume. if you're hoping to explore/identify/repair any damage, there's this for a good start, https://raid.wiki.kernel.org/index.php/Recovering_a_damaged_RAID this too, https://wiki.archlinux.org/title/RAID i'd recommend subscribing asking at, https://raid.wiki.kernel.org/index.php/Asking_for_help before guessing. a much better place to ask than here. even with good help from the list, i've had mixed luck with superblock recovery -- best, when able to find multiple clean copies of backup superblocks on the array/drives. -- worst, lost it all Thanks. I will ask for help on the mailing list. I actually got good hope since I'm able to manually assemble and access the data. But first I will do some reading up. given the change in behavior, and the older metadata, i'd consider starting fresh. wiping the array & disks, scanning/mapping bad blocks, reformatting & repartitioning, creating new arrays with lastest metadata, and restoring from backup. if you've still got good harwdare, should be good -- better than the uncertainty. yup, it'll take awhile. but, so might the hunt & repair process. Yeah. It's currently still on the bottom of my list. If all else fails, I will have no other option I guess. At moment I'm a bit torn apart between wanting to understand what's going and wanting to be able to use my system again. Going through all the information, I just discovered that the oldest of the arrays is close to ten years old and one of the disks has been part of the setup right from the start (Power_On_Hours: 80952). I've replaced disks whenever the need arose, never ran into trouble until now... Thanks for sparring! Whatever the outcome, I'll report here and on discussion. -- ___ 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: Troubleshooting MD RAID assembly not working after upgrade to F39
On 12/27/23 17:36, Sandro wrote: I'll try with a F39 live ISO as well. If nothing else, it could confirm the issue to be with/in F39. I did that. Right after boot only one of the arrays was assembled. In /proc/mdstat is was listed as "active (auto-read-only)" and the component devices matched with what is known on my system as md54. No entry in the journal regarding any of the other arrays. No attempted assembly. Nothing. I stopped the array and ran `mdadm --assemble --verbose --scan --no-degraded` and all arrays were assembled without any issues. In the verbose output of the command `mdadm` told me: mdadm: No super block found on /dev/sda2 (Expected magic a92b4efc, got 6d746962) That was repeated for all the component devices of md1 and md5. For drives / partitions not being component devices it reported: mdadm: No super block found on /dev/sda1 (Expected magic a92b4efc, got ) instead. In contrast, about the component devices of md54, `mdadm` had the following to report: mdadm: /dev/sda4 is identified as a member of /dev/md/urras.penguinpee.nl:54, slot 0. This smells very much like something is off with the version 1.1 superblock. This being the only notable difference between arrays md1 and md5 and array md54. Yet, I have no clue as to what or what to do about it. :-\ -- ___ 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: Troubleshooting MD RAID assembly not working after upgrade to F39
On 12/27/23 17:28, pgnd wrote: WAG? https://www.urbandictionary.com/define.php?term=wild%20ass%20guess ;) I should have guessed... I added `level` and `num-devices` to all entries in mdadm.conf and rebooted. It didn't change anything. Manual assembly still freezes the system as well. hm (1) are the mods explicitly in the initrd? Yes, they are. (2) can you boot from a usb key with a f39 live-iso and see if the arrays assemble? if they do, it's likely your config if they don't, the probs in the array itself (bad metadata, out of sync, etc ...) Well, I booted from a F38 USB everything ISO. It didn't assemble any of the arrays. But I was able to do so manually and subsequently mount one of the logical volumes on it readonly. I'd say that pretty much rules out a failure on the arrays. Two at the same time while a third is unaffected seems unlikely as well since they all share the same spinning metal underneath. It's not impossible. But, if so, I'd better buy myself a lottery ticket. ;) I'll try with a F39 live ISO as well. If nothing else, it could confirm the issue to be with/in F39. -- ___ 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: Troubleshooting MD RAID assembly not working after upgrade to F39
On 12/27/23 17:03, pgnd wrote: also make sure your drivers are in the initrd lsinitrd | grep -Ei "kernel/drivers/md/raid" -rw-r--r-- 1 root root10228 Nov 15 19:00 usr/lib/modules/6.6.8-200.fc39.x86_64/kernel/drivers/md/raid0.ko.xz -rw-r--r-- 1 root root35376 Nov 15 19:00 usr/lib/modules/6.6.8-200.fc39.x86_64/kernel/drivers/md/raid10.ko.xz -rw-r--r-- 1 root root26912 Nov 15 19:00 usr/lib/modules/6.6.8-200.fc39.x86_64/kernel/drivers/md/raid1.ko.xz -rw-r--r-- 1 root root90144 Nov 15 19:00 usr/lib/modules/6.6.8-200.fc39.x86_64/kernel/drivers/md/raid456.ko.xz I have raid0.ko.xz and raid456.ko.xz present in initrd. where, here, grep -i raid /etc/dracut.conf.d/99-local.conf add_dracutmodules+=" mdraid " add_drivers+=" raid0 raid1 raid10 raid456 " On my system /etc/dracut.conf.d/ is empty and /etc/dracut.conf only contains comments. Seeing that the required modules are in initrd, I suppose I don't need to spell them out explicitly. I suppose without the modules loaded I wouldn't be able to perform any MD operations at all. Thanks for the pointers, anyway. It helps in understanding how all these pieces fit together. -- ___ 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: Troubleshooting MD RAID assembly not working after upgrade to F39
On 12/27/23 17:10, pgnd wrote: If it works, I'd still wonder why md54 comes up fine. That entry is also missing `level` and `num-devices`. 1st WAG ? WAG? /dev/md/54 is 'just' raid1, without an atypical spare It's not. It's a raid5 without any spare just like md5. Only difference between the two is the metadata version, 1.1 vs. 1.2. And the partitions making up md54 have a bunch of additional entries like UUID_SUB as reported by `blkid`. More details in the discussion post. raid5 & raid1+spare are less common. whether autoassembly is smart enough to pick up the diffs without the explicit spec in /etc/mdadm.conf? again, dunno without trying. I added `level` and `num-devices` to all entries in mdadm.conf and rebooted. It didn't change anything. Manual assembly still freezes the system as well. -- ___ 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: Troubleshooting MD RAID assembly not working after upgrade to F39
On 12/27/23 16:47, pgnd wrote: i explicitly add the level= num-devices i've had issues long ago with mis-assembly that that cured. whether it's STILL a problem, i don't know; all my array spec contain contain these, and don't cause harm. it's now SOP here. i'd at least consider checking ... Sure. It's worth a try. Although, I've read that /etc/mdadm.conf is kinda obsolete. If it works, I'd still wonder why md54 comes up fine. That entry is also missing `level` and `num-devices`. -- ___ 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: Troubleshooting MD RAID assembly not working after upgrade to F39
On 12/27/23 15:14, pgnd wrote: what's the output of: mdadm -Es cat /etc/mdadm.conf # mdadm -Es ARRAY /dev/md/5 metadata=1.1 UUID=39295d93:e5a75797:b72287f3:51563755 name=urras.penguinpee.nl:5 ARRAY /dev/md/1 metadata=1.1 UUID=4a2c44b5:25f2a6c9:0e7f6cae:37a8a9cc name=urras.penguinpee.nl:1 spares=1 ARRAY /dev/md/54 metadata=1.2 UUID=fb919273:c6bfb891:ea1ca83c:0a8b3ad7 name=urras.penguinpee.nl:54 # cat /etc/mdadm.conf ARRAY /dev/md/5 metadata=1.1 name=urras.penguinpee.nl:5 UUID=39295d93:e5a75797:b72287f3:51563755 ARRAY /dev/md/54 metadata=1.2 name=urras.penguinpee.nl:54 UUID=fb919273:c6bfb891:ea1ca83c:0a8b3ad7 ARRAY /dev/md/1 metadata=1.1 spares=1 name=urras.penguinpee.nl:1 UUID=4a2c44b5:25f2a6c9:0e7f6cae:37a8a9cc MAILADDR root PROGRAM /usr/share/doc/mdadm/syslog-events -- ___ 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: Troubleshooting MD RAID assembly not working after upgrade to F39
On 12/27/23 15:05, Sandro wrote:
I could you use some help with ${SUBJECT}. I posted the details in
discussion [1], but have yet to receive a response. I thought maybe
folks on the list may have an idea.
I'm kinda lost as to where this is going wrong. Feel free to reply
either on discussion or here. I'd appreciate any help I can get.
The missing link:
[1]
https://discussion.fedoraproject.org/t/system-fails-to-boot-after-dnf-system-upgrade-due-to-missing-md-raid-devices/100218
--
___
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
Troubleshooting MD RAID assembly not working after upgrade to F39
I could you use some help with ${SUBJECT}. I posted the details in
discussion [1], but have yet to receive a response. I thought maybe
folks on the list may have an idea.
I'm kinda lost as to where this is going wrong. Feel free to reply
either on discussion or here. I'd appreciate any help I can get.
Thank you,
--
Sandro
FAS: gui1ty
IRC: Penguinpee
Elsewhere: [Pp]enguinpee
--
___
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
HEADS UP: upgrade to shapelib-1.6.0
Hello I'll be updating to shapelib-1.6.0 in the coming days, which carries a soname bump from libshp.so.2 to libshp.so.4, rebuilding the following dependent packages: cloudcompare cyrus-imapd gdl gpsbabel marble plplot xastir Thanks and happy holidays 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: armadillo soname bump to version 12
On 22.12.23 10:41, Florian Weimer wrote: * Ryan Curtin: Hello there, I plan to bump the major version of the Armadillo linear algebra library to version 12 for rawhide next week; this will be an ABI/API change. I will rebuild the package and its dependencies (looks like gdal and mlpack only) in the side tag 'f40-build-side-79101'. Looks like this was partially merged into rawhide? | Failed to resolve the transaction: | No match for argument: /usr/share/fonts/dejavu-sans-fonts/DejaVuSans-Bold.ttf | No match for argument: /usr/share/fonts/dejavu-sans-fonts/DejaVuSans.ttf | Problem: package gdal-devel-3.8.2-1.fc40.x86_64 requires libgdal.so.34()(64bit), but none of the providers can be installed | - package gdal-devel-3.8.2-1.fc40.x86_64 requires gdal-libs(x86-64) = 3.8.2-1.fc40, but none of the providers can be installed | - cannot install the best candidate for the job | - nothing provides libarmadillo.so.10()(64bit) needed by gdal-libs-3.8.2-1.fc40.x86_64 Seen while trying to rebuild mapserver with unchanged sources. There is gdal-3.8.2-2.fc40 which is correctly built against libarmadillo.so.12 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: 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
[Heads up]: biosig4c++ 2.5.2 coming to rawhide
In one week (2023-12-19) or a little later I will update biosig4c++ to version 2.5.2 in rawhide. This will bring an soname bump. However, there are no consuming packages, making this a self contained change. Cheers, -- Sandro FAS: gui1ty IRC: Penguinpee Elsewhere: [Pp]enguinpee -- ___ 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 08-12-2023 07:22, Nathan Scott wrote:
ValueError: Globs did not match any module: xgboost
This sounds like the module is not installed where you think it is. In
other words %{pyproject_files} would be empty because the glob (xgboost)
after %pyproject_save_files doesn't match anything.
What do you have in
build/BUILDROOT/*/usr/lib64/python3.12/site-packages/ inside your mock
changeroot?
-- Sandro
--
___
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: Unretiring keepass
On 21-11-2023 10:56, Julian Sikorski wrote: as the CVE (which was not even a problem with keepass in the first place) leading to keepass retirement has been resolved in the meantime, I would like to unretire the package. I have submitted a re-review already: https://bugzilla.redhat.com/show_bug.cgi?id=2250816 Just a thought in case you aren't aware, KeePassXC [1,2] is still maintained in Fedora and the databases are compatible. So, in case you are after using an existing KeePass database, you can use KeePassXC to do so. KeePassXC is written in C++ instead of C# and thus does not depend on Mono. There's also a client for mobile called KeePassDX [3]. [1] https://keepassxc.org/ [2] https://src.fedoraproject.org/rpms/keepassxc [3] https://www.keepassdx.com/ -- 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: Inactive packages removed from packager group
On 18-11-2023 21:08, Kevin Fenzi wrote: After 6 weeks, the package will be retired. After another 8 weeks, a new review is needed to unretire it. seehttps://docs.fedoraproject.org/en-US/fesco/Policy_for_orphan_and_retired_packages/ for more details. I'm wondering if there shouldn't be some impact assessment comparable to the "orphaned packages looking for new maintainer" mail. Or will that happen with the next round of "orphaned packages ..."? I think ordering the list of orphaned packages alphabetically would make it easier to pinpoint packages one may be interested in or depend on. -- 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: HEADS UP: gdal-3.8.0 coming to rawhide
This is now done, there are two unrelated failures: - gazebo: graphviz 9.x incompatibility - vfrnav: broken build dependencies (nothing provides libsundials_sunlinsolklu.so.4.6.1()(64bit) needed by octave-6:8.4.0-1.fc40.x86_64 from build) Sandro On 15.11.23 11:42, Sandro Mani wrote: Hi I'll be building gdal-3.8.0 in the f40-build-side-77750 side tag. It carries a soname bump, and I'll rebuild the following dependencies: GMT mapserver liblas python-fiona postgis merkaartor R-rgdal bes qmapshack PDAL ncl vfrnav python-rasterio vtk paraview kealib OpenSceneGraph cloudcompare grass mapnik opencv mingw-opencv osgearth qgis gazebo Thanks 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
HEADS UP: gdal-3.8.0 coming to rawhide
Hi I'll be building gdal-3.8.0 in the f40-build-side-77750 side tag. It carries a soname bump, and I'll rebuild the following dependencies: GMT mapserver liblas python-fiona postgis merkaartor R-rgdal bes qmapshack PDAL ncl vfrnav python-rasterio vtk paraview kealib OpenSceneGraph cloudcompare grass mapnik opencv mingw-opencv osgearth qgis gazebo Thanks 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: Didn't get an email about a new merge request on a package
On 08-11-2023 21:33, Kevin Fenzi wrote: Oct 28 09:04:13 pkgs01 celery[1147999]: File "/usr/lib/python3.6/site-packages/celery/app/trace.py", line 385, in trace_task I am not sure what happened there. ;( Some kind of race condition? Python getting old and not being able to keep ahead in the enduring race? -- 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: HEADS UP: broken dependencies due to gdal-3.6.2-7.fc37
On 07.11.23 12:17, Sandro Mani wrote: Hi Due to an unfortunate oversight of an incorrect branch merge a couple of months ago, a recently backported security fix caused an unwanted gdal soname bump in F37, due to an update from the 3.5.x series to the 3.6.x series. I'm preparing a gdal-3.6.2-8.really3.5.3.fc37 to address this, please don't rebuild any dependencies in the meantime, as the new package will bring back the previous soname. The new update is now pushed to testing: https://bodhi.fedoraproject.org/updates/FEDORA-2023-c0ac8784e8 ___ 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
HEADS UP: broken dependencies due to gdal-3.6.2-7.fc37
Hi Due to an unfortunate oversight of an incorrect branch merge a couple of months ago, a recently backported security fix caused an unwanted gdal soname bump in F37, due to an update from the 3.5.x series to the 3.6.x series. I'm preparing a gdal-3.6.2-8.really3.5.3.fc37 to address this, please don't rebuild any dependencies in the meantime, as the new package will bring back the previous soname. Apologies for the troubles. 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: Wrong branch built into side tags, what to do?
On 06-11-2023 17:08, Julian Sikorski wrote: I have accidentally built f39/rawhide branch of gnumeric and gnome-chemistry-utils for f38 and f37 side tags (f39 too but rawhide and f39 are the same commit). Can this be fixed? Or is the effort not worth it? Thanks. Maybe I'm missing something. But can you not just untag the builds from the side tag they don't belong in? koji untag-build Then rebuild into the correct side tag. That step may require that you bump the release. I'm not entirely sure. -- 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: Heads up: libunibreak 5.1 update coming to rawhide
On 02-11-2023 11:19, Fabio Valentini wrote: I have an update for libunibreak ready and plan to release that for rawhide in a week (or slightly later). The new version bumps libunibreak from so.3 to so.5. I also intend to drop building for i686. Note: Dropping builds for i686 is technically only allowed to happen without bureaucracy if * and only if* the package is already a leaf package on i686. Dropping i686 builds while package still depend on them is a breaking change that needs to be coordinated better than via side note in an soname bump notification. Duly noted. However, I don't think "side note in an soname bump notification" applies here. There are three dependent packages. One of which is mine. The other two need to be rebuilt and coordinated anyway. And I didn't just "note" dropping i686, I also submitted PRs to that extend and provided a side tag (as mentioned below). Of the three packages, two have already been rebuilt. Should the third not follow suit, I can revert dropping i686 for libunibreak, keeping it for the packages that have already been rebuilt. So, there will still be a win of two leaf packages having dropped i686. The following packages depend on libunibreak: $ fedrq wr -s libunibreak-devel coolreader-3.2.59-6.fc39.src fbreader-0.99.4-12.fc39.src naev-0.10.2-3.fc39.src I will take care of coolreader. I have tested fbreader and naev in Copr [1] and they build fine. I've created f40-build-side-76870 for rebuilding against the updated libunibreak and dropping support for i686. -- 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
Heads up: libunibreak 5.1 update coming to rawhide
I have an update for libunibreak ready and plan to release that for rawhide in a week (or slightly later). The new version bumps libunibreak from so.3 to so.5. I also intend to drop building for i686. The following packages depend on libunibreak: $ fedrq wr -s libunibreak-devel coolreader-3.2.59-6.fc39.src fbreader-0.99.4-12.fc39.src naev-0.10.2-3.fc39.src I will take care of coolreader. I have tested fbreader and naev in Copr [1] and they build fine. I've created f40-build-side-76870 for rebuilding against the updated libunibreak and dropping support for i686. Please rebuild fbreader and naev (PRs submitted and maintainers in Cc) in the side tag to ensure a smooth update. If you prefer, you can also grant me commit rights and I will take care of rebuilding myself. [1] https://copr.fedorainfracloud.org/coprs/gui1ty/libunibreak/builds/ Cheers, -- Sandro FAS: gui1ty IRC: Penguinpee Elsewhere: [Pp]enguinpee ___ 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: PEP-668, cmake FindPython Python_SITEARCH and rpm_prefix
On 25.10.23 02:20, Neal Gompa wrote:
On Tue, Oct 24, 2023 at 5:18 PM Sandro Mani wrote:
Hi
Since some time, Fedora's cmake FindPython will return
Python_SITEARCH=/usr/local/lib64/pythonX.Y/site-packages, which results in
possible failure to find python libraries below the system site packages dir
(aka shipped by RPMs). A workaround(?) is to call
EXECUTE_PROCESS(COMMAND ${Python_EXECUTABLE} -c "import sysconfig;print(sysconfig.get_path(\"platlib\",
\"rpm_prefix\"), end=\"\")" OUTPUT_VARIABLE Python_SITEARCH)
and such workarounds are starting to appear in applications [1]. Any opinions
on whether this is indeed the best way to handle the issue, whether Fedoras
FindPython needs fixing, or whether there already is a cleaner solution?
This needs to be fixed in FindPython.cmake to detect whether cmake is
running in a package build environment to get the correct path.
Though this also concerns the case where I build the application locally
say for development, not necessarily just when building the rpm?
Shouldn't FindPython just always return the rpm_prefix paths, since you
are most-likely attempting to find the system python?
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
PEP-668, cmake FindPython Python_SITEARCH and rpm_prefix
Hi
Since some time, Fedora's cmake FindPython will return
Python_SITEARCH=/usr/local/lib64/pythonX.Y/site-packages, which results
in possible failure to find python libraries below the system site
packages dir (aka shipped by RPMs). A workaround(?) is to call
EXECUTE_PROCESS(COMMAND ${Python_EXECUTABLE} -c "import
sysconfig;print(sysconfig.get_path(\"platlib\", \"rpm_prefix\"),
end=\"\")" OUTPUT_VARIABLE Python_SITEARCH)
and such workarounds are starting to appear in applications [1]. Any
opinions on whether this is indeed the best way to handle the issue,
whether Fedoras FindPython needs fixing, or whether there already is a
cleaner solution?
Thanks
Sandro
[1] https://github.com/qgis/QGIS/pull/55039/files
___
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: Upgrades of Sundials and PETSc
On 20-10-2023 15:52, Ben Beasley wrote:
For next time, this seems to work for me:
for p in petsc{,64,-openmpi,-mpich} libpetsc.so; do repoquery -q
--repo=rawhide{,-source} --whatrequires "$p"; done | sort -u
An alternative to above, using gotmax23's excellent fedrq [1], you'd get
the same result with a oneliner:
$ fedrq wr -s petsc*
bout++-5.0.0-11.fc40.src
dolfin-2019.1.0.post0-47.fc40.src
freefem++-4.13-6.fc40.src
getdp-3.5.0-9.fc40.src
python-steps-3.6.0-30.fc39.src
sundials-6.6.1-3.fc40.src
[1] https://fedrq.gtmx.me
-- 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: Looking for a volunteer to automate the orphaned packages process
On 19-10-2023 11:06, Miro Hrončok wrote: I can provide all the details about the operation if you want to become the reaper's apprentice. A reaper by the name of Churchyard! ⚰️ ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Orphaning python-rdflib-jsonld
On 18-10-2023 06:56, Aniket Pradhan wrote: We, at the neuro-sig would be orphaning the package: python-rdflib-jsonld [0]. The package is no longer maintained upstream and is now inherently provided by python-rdflib v6.0.0+. [0]:https://src.fedoraproject.org/rpms/python-rdflib-jsonld For the reason given above the package should be retired, not orphaned. It doesn't make sense for someone else to pick it up, since it is conflicting with `python-rdflib`. -- 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
Review request: python-simple-websocket
Hi python-socketio / python-engineio grew a new dependency on python-simple-websocket. I've submitted it for review at https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=2244587. Happy to review in exchange. Thanks 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 Statistics - Miracle of the Sun edition
On 13-10-2023 08:15, Miroslav Suchý wrote: Reviewers wanted: Package review of scancode-toolkit still need 3 dependencies to be review https://bugzilla.redhat.com/show_bug.cgi?id=2235055 I took up three of those reviews, but they have been idling ever since... -- 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: 16 packages still need a Python 3.12 rebuild, final freeze in 6 days
On 27-09-2023 11:56, Miro Hrončok wrote: here is the list of packages that still need a Python 3.12 rebuild for Fedora 39+. Not mentioned on the list, but still pending, is the update for spyder. That's finally ready now the last of the dependencies has been updated. However, it's a bit messy since two of the packages spyder depends on are still in testing and need to be pushed stable before or together with spyder. python-lsp-server: https://bodhi.fedoraproject.org/updates/FEDORA-2023-ed1146b71b python-ipykernel: https://bodhi.fedoraproject.org/updates/FEDORA-2023-b09ddb8c90 spyder: https://bodhi.fedoraproject.org/updates/FEDORA-2023-518a1d3a2f We need karma for these updates and once that's done they need to be pushed to stable. I have cc'ed the submitters of the dependent updates. Since QA (rightfully) doesn't like messy updates[1], it would be great to get this in before the freeze. [1] Neither do I. But, it's not always avoidable. If I had the time, I would have let the two dependent updates go stable before pushing spyder. Thanks for your help, Sandro ___ 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: 16 packages still need a Python 3.12 rebuild, final freeze in 6 days
On 27-09-2023 11:56, Miro Hrončok wrote: here is the list of packages that still need a Python 3.12 rebuild for Fedora 39+. Not mentioned on the list, but still pending, is the update for spyder. That's finally ready now the last of the dependencies has been updated. However, it's a bit messy since two of the packages spyder depends on are still in testing and need to be pushed stable before or together with spyder. python-lsp-server: https://bodhi.fedoraproject.org/updates/FEDORA-2023-ed1146b71b python-ipykernel: https://bodhi.fedoraproject.org/updates/FEDORA-2023-b09ddb8c90 spyder: https://bodhi.fedoraproject.org/updates/FEDORA-2023-518a1d3a2f We need karma for these updates and once that's done they need to be pushed to stable. I have cc'ed the submitters of the dependent updates. Since QA (rightfully) doesn't like messy updates[1], it would be great to get this in before the freeze. [1] Neither do I. But, it's not always avoidable. If I had the time, I would have let the two dependent updates go stable before pushing spyder. Thanks for your help, 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: 16 packages still need a Python 3.12 rebuild, final freeze in 6 days
On 30-09-2023 02:16, Jonathan Steffan wrote: supervisor in fedora 39 is 4.2.2 but the version that supports python 3.12 is 4.2.5. I filed Bug 2239529 about this and have received no response. I've updatedhttps://bugzilla.redhat.com/show_bug.cgi?id=2239529 with links to an updated Rawhide scratch build and two PRs (Rawhide & F39) to update this software. It's such a useful software package it would be a shame to drop it. I would also be willing to co-maintain this package, but the current package admin has not been responsive to other requests. Did you send a mail to supervisor-maintainers@fp.o requesting for the PRs to be merged and being added as a co-maintainer? I saw there's another co-maintainer of the package. If that has been done and still no response on the PRs or Bugzilla, I'd say it's time to kick off the non-responsive maintainer procedure[1]. In the meantime a proven packager could merge the PRs and thus save the package from being retired. [1] https://docs.fedoraproject.org/en-US/fesco/Policy_for_nonresponsive_package_maintainers/ -- 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: python-3.12 distutils removal just happened after python mass rebuild and Fedora mass rebuild ?
On 29-09-2023 20:32, Sérgio Basto wrote: Recent build of some packages like opencv and an old gpgme shows that python-3.12 disutils has gone for good , but just after all mass rebuilds and recently , what you advice to do ? Any quick way to replace distutils ? the python 3.12 final release, currently is scheduled for 2023-10-02 ... Maybe this is helpful: https://peps.python.org/pep-0632/#migration-advice https://setuptools.pypa.io/en/latest/deprecated/distutils-legacy.html I used it for fixing some packages after Python 3.12 was dropped in rawhide. In other cases it was a friendly outcry to upstream to wake up. -- 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: -Werror=implicit-int -Werror=implicit-function-declaration coming to rawhide
On 28-09-2023 21:12, Florian Weimer wrote:
* Stephen Gallagher:
On Wed, Sep 27, 2023 at 12:59 PM Ron Olson wrote:
I mean this sincerely: Where is the excellent documentation? I admit that I’ve
been frustrated that web searches leads me all over the place, sometimes the
documentation is obsolete, or it’s someone’s blog post, etc. I’ve been
surprised again and again there’s a macro for this or that which could have
made the job much easier, but I had no idea until I asked here or in IRC.
The documentation he's referring to is the
https://src.fedoraproject.org/rpms/redhat-rpm-config/blob/rawhide/f/buildflags.md
Indeed, we probably should figure out a way to make that link more
prominent on the Packaging Guidelines pages, though.
I couldn't figure out the contribution process for the documentation (it
probably has changed since), but I did file
<https://pagure.io/packaging-committee/issue/743> a while back.
Making a copy is disappointing because it will bit-rot fairly quickly.
Every Fedora release will change some build flags. And ideally, you'd
consult the documentation for the Fedora release you are working on.
The on-the-side documentation wouldn't be versioned per Fedora release.
I see what you mean. The file is constantly evolving.
How about adding a section to the top of the document saying something
along the lines:
The build flags are constantly evolving You can find the most recent
version of this document online at
https://src.fedoraproject.org/rpms/redhat-rpm-config/blob/${RELEASE}/f/buildflags.md
where ${RELEASE} refers to the Fedora release you are packaging for
(e.g. f38, f39 or rawhide).
That way someone looking at the installed version of the file will be
directed towards the most current version for any release.
That aside, having the document linked in the packaging guidelines is a
big step towards letting packagers know of its existence.
Thanks for all the work!
-- 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: -Werror=implicit-int -Werror=implicit-function-declaration coming to rawhide
On 27-09-2023 19:01, Stephen Gallagher wrote: On Wed, Sep 27, 2023 at 12:59 PM Ron Olson wrote: I mean this sincerely: Where is the excellent documentation? I admit that I’ve been frustrated that web searches leads me all over the place, sometimes the documentation is obsolete, or it’s someone’s blog post, etc. I’ve been surprised again and again there’s a macro for this or that which could have made the job much easier, but I had no idea until I asked here or in IRC. The documentation he's referring to is the https://src.fedoraproject.org/rpms/redhat-rpm-config/blob/rawhide/f/buildflags.md Indeed, we probably should figure out a way to make that link more prominent on the Packaging Guidelines pages, though. How about importing it there directly? Maybe have some monitoring in place to get it updated when the file changes? Or, alternatively, mention the source: "The most recent version can be found on ...". This would give a much higher score in search results, I'd assume. ___ 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 25-09-2023 14:00, Miro Hrončok wrote: neuro-sig: python-textdistance, python-qstylizer, python-whatthepatch, python-pyls-spyder I've adopted all of these. They are all part of the spyder dependency stack. I'll look into them and fix what needs fixing as soon as I can. -- 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
