Minetest has been broken for almost two months on Fedora 31. The rpms just need to be rebuilt to work.
https://bugzilla.redhat.com/show_bug.cgi?id=1764611
See my comments on the BZ. The module appears defunct, and we have 4.x in f31 and 5.x in rawhide.
-- Gwyn Ciesla she/her/hers ------------------------------------------------ in your fear, seek only peace in your fear, seek only love -d. bowie
Sent with ProtonMail Secure Email.
‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ On Tuesday, December 17, 2019 8:51 AM, Dennis Payne dulsi@identicalsoftware.com wrote:
Minetest has been broken for almost two months on Fedora 31. The rpms just need to be rebuilt to work.
Dennis Payne dulsi@identicalsoftware.com https://social.freegamedev.net/channel/dulsi
Fedora Games SIG mailing list -- games@lists.fedoraproject.org To unsubscribe send an email to games-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/games@lists.fedoraproject.org
I never explicitly enabled the module to my knowledge. Did upgrading at some point enable the module? How are people supposed to know that a module is defunct and stop using it? If save files modified by minetest 5 don't work with minetest 4, are we telling people "Sorry we enabled the minetest module automatically. You can wait to Fedora 32 to load those save files."?
I see gimp also enabled as a module. So at some point I might have a problem with that as well and need to disable the module.
Don't get me wrong. I think it is great that we have the ability to enable modules to install newer versions. But I don't think we should enable them automatically especially if we can drop support at any moment.
On Tue, 2019-12-17 at 14:56 +0000, Gwyn Ciesla wrote:
See my comments on the BZ. The module appears defunct, and we have 4.x in f31 and 5.x in rawhide.
-- Gwyn Ciesla she/her/hers
in your fear, seek only peace in your fear, seek only love -d. bowie
Sent with ProtonMail Secure Email.
It was enabled by default. I'm not sure how that decision came to be.
-- Gwyn Ciesla she/her/hers ------------------------------------------------ in your fear, seek only peace in your fear, seek only love -d. bowie
Sent with ProtonMail Secure Email.
‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ On Tuesday, December 17, 2019 10:13 AM, Dennis Payne dulsi@identicalsoftware.com wrote:
I never explicitly enabled the module to my knowledge. Did upgrading at some point enable the module? How are people supposed to know that a module is defunct and stop using it? If save files modified by minetest 5 don't work with minetest 4, are we telling people "Sorry we enabled the minetest module automatically. You can wait to Fedora 32 to load those save files."?
I see gimp also enabled as a module. So at some point I might have a problem with that as well and need to disable the module.
Don't get me wrong. I think it is great that we have the ability to enable modules to install newer versions. But I don't think we should enable them automatically especially if we can drop support at any moment.
On Tue, 2019-12-17 at 14:56 +0000, Gwyn Ciesla wrote:
See my comments on the BZ. The module appears defunct, and we have 4.x in f31 and 5.x in rawhide.
-- Gwyn Ciesla she/her/hers
in your fear, seek only peace in your fear, seek only love -d. bowie Sent with ProtonMail Secure Email.
Fedora Games SIG mailing list -- games@lists.fedoraproject.org To unsubscribe send an email to games-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/games@lists.fedoraproject.org
Hi, Dennis,
On Tue, Dec 17, 2019 at 5:13 PM Dennis Payne dulsi@identicalsoftware.com wrote:
I never explicitly enabled the module to my knowledge. Did upgrading at some point enable the module? How are people supposed to know that a module is defunct and stop using it? If save files modified by minetest 5 don't work with minetest 4, are we telling people "Sorry we enabled the minetest module automatically. You can wait to Fedora 32 to load those save files."?
Minetest:5 stream was enabled by default so you got it installed automatically.
And to clarify, Gwyn is not to blame here. She is helping with the package, but it is me and Igor who made this mess. And sorry that we didn't realize the full consequences.
Let's look at our options to fix it.
Current state:
1) for rawhide modules are disabled, version 5.1.0 is available in the repo as a regular package;
2) for f30 and f31: - there is a version 4.17 available as a regular package - there is a module for minetest:5 which is enabled by default, it includes version 5.0.0-1 which can not be installed because of dependencies.
3) modular repo is deprecated.
What we can do:
I think we should resurrect modular repo for minetest but only for fedora 30 and fedora 31. This will allow us to publish an update to 5.1.0 via module update process, which will solve the current issue. Then we can decide whether or not we actually want to keep two versions of minetest package in Fedora.
I asked Igor for admin access to modular repo [1] so i can reintroduce the module config. Once I get it, I will build a 5.1.0 version for f30 and f31 through it.
As a temporary workaround you can install the rpm from scratch build [2].
[1] https://src.fedoraproject.org/modules/minetest/
[2] https://koji.fedoraproject.org/koji/taskinfo?taskID=39690300 https://kojipkgs.fedoraproject.org//work/tasks/300/39690300/minetest-5.1.0-1... https://kojipkgs.fedoraproject.org//work/tasks/300/39690300/minetest-server-...
I see gimp also enabled as a module. So at some point I might have a problem with that as well and need to disable the module.
Don't get me wrong. I think it is great that we have the ability to enable modules to install newer versions. But I don't think we should enable them automatically especially if we can drop support at any moment.
@Aleksandra: I'm not blaming Gwyn. I understand she is just trying to help me out.
I can work around the problem like rebuilding from src. It isn't really a big problem for me. I'm just trying to explain how it will look to less technical users. I'll probably hold off on updating the kids' machines to Fedora 31 but that isn't a big deal.
As for your solution how will that work when we upgrade to Fedora 32? Will all modules be disabled since we are getting rid of them?
On Tue, Dec 17, 2019 at 7:38 PM Dennis Payne dulsi@identicalsoftware.com wrote:
@Aleksandra: I'm not blaming Gwyn. I understand she is just trying to help me out.
I can work around the problem like rebuilding from src. It isn't really a big problem for me. I'm just trying to explain how it will look to less technical users. I'll probably hold off on updating the kids' machines to Fedora 31 but that isn't a big deal.
Sure, I agree with your point.
As for your solution how will that work when we upgrade to Fedora 32? Will all modules be disabled since we are getting rid of them?
I need to verify the upgrade process which is being developed. My expectation is that default stream packages should cleanly update to the nonmodular package, but I need to check it.
But I don't want to get rid of modules completely.
We do have minetest version 4.16 in epel repositories. And since it is not compatible with 5.x client, it makes sense to keep minetest 4.x packaged for Fedora (if it can be built and doesn't require dependencies to be rebuilt into the module). I would try to use module for that, I just don't want to expose it as default, so that people would need to explicitly configure it to try it out.
5.1.0 is now available in modular testing repo for Fedora 31:
You can try it with:
dnf install minetest --enablerepo=updates-testing-modular
Please provide feedback/karma at https://bodhi.fedoraproject.org/updates/FEDORA-MODULAR-2019-44e78ce21d
On Tuesday, December 17, 2019 10:35:22 AM MST Aleksandra Fedorova wrote:
Hi, Dennis,
On Tue, Dec 17, 2019 at 5:13 PM Dennis Payne dulsi@identicalsoftware.com
wrote:
I never explicitly enabled the module to my knowledge. Did upgrading at some point enable the module? How are people supposed to know that a module is defunct and stop using it? If save files modified by minetest 5 don't work with minetest 4, are we telling people "Sorry we enabled the minetest module automatically. You can wait to Fedora 32 to load those save files."?
Minetest:5 stream was enabled by default so you got it installed automatically.
And to clarify, Gwyn is not to blame here. She is helping with the package, but it is me and Igor who made this mess. And sorry that we didn't realize the full consequences.
Let's look at our options to fix it.
Current state:
- for rawhide modules are disabled, version 5.1.0 is available in the repo
as a regular package;
- for f30 and f31:
- there is a version 4.17 available as a regular package
- there is a module for minetest:5 which is enabled by default, it
includes version 5.0.0-1 which can not be installed because of dependencies.
- modular repo is deprecated.
What we can do:
I think we should resurrect modular repo for minetest but only for fedora 30 and fedora 31. This will allow us to publish an update to 5.1.0 via module update process, which will solve the current issue. Then we can decide whether or not we actually want to keep two versions of minetest package in Fedora.
I asked Igor for admin access to modular repo [1] so i can reintroduce the module config. Once I get it, I will build a 5.1.0 version for f30 and f31 through it.
As a temporary workaround you can install the rpm from scratch build [2].
[1] https://src.fedoraproject.org/modules/minetest/
[2] https://koji.fedoraproject.org/koji/taskinfo?taskID=39690300 https://kojipkgs.fedoraproject.org//work/tasks/300/39690300/minetest-5.1.0-1 .fc31.x86_64.rpm https://kojipkgs.fedoraproject.org//work/tasks/300/39690300/minetest-server -5.1.0-1.fc31.x86_64.rpm
I see gimp also enabled as a module. So at some point I might have a problem with that as well and need to disable the module.
Don't get me wrong. I think it is great that we have the ability to enable modules to install newer versions. But I don't think we should enable them automatically especially if we can drop support at any moment.
Wait, how did this get enabled as a default module without FESCo approval?
On Wed, Dec 18, 2019 at 1:01 AM John M. Harris Jr johnmh@splentity.com wrote:
On Tuesday, December 17, 2019 10:35:22 AM MST Aleksandra Fedorova wrote:
Hi, Dennis,
On Tue, Dec 17, 2019 at 5:13 PM Dennis Payne dulsi@identicalsoftware.com
wrote:
I never explicitly enabled the module to my knowledge. Did upgrading at some point enable the module? How are people supposed to know that a module is defunct and stop using it? If save files modified by minetest 5 don't work with minetest 4, are we telling people "Sorry we enabled the minetest module automatically. You can wait to Fedora 32 to load those save files."?
Minetest:5 stream was enabled by default so you got it installed automatically.
And to clarify, Gwyn is not to blame here. She is helping with the package, but it is me and Igor who made this mess. And sorry that we didn't realize the full consequences.
Let's look at our options to fix it.
Current state:
- for rawhide modules are disabled, version 5.1.0 is available in the repo
as a regular package;
- for f30 and f31:
- there is a version 4.17 available as a regular package
- there is a module for minetest:5 which is enabled by default, it
includes version 5.0.0-1 which can not be installed because of dependencies.
- modular repo is deprecated.
What we can do:
I think we should resurrect modular repo for minetest but only for fedora 30 and fedora 31. This will allow us to publish an update to 5.1.0 via module update process, which will solve the current issue. Then we can decide whether or not we actually want to keep two versions of minetest package in Fedora.
I asked Igor for admin access to modular repo [1] so i can reintroduce the module config. Once I get it, I will build a 5.1.0 version for f30 and f31 through it.
As a temporary workaround you can install the rpm from scratch build [2].
[1] https://src.fedoraproject.org/modules/minetest/
[2] https://koji.fedoraproject.org/koji/taskinfo?taskID=39690300 https://kojipkgs.fedoraproject.org//work/tasks/300/39690300/minetest-5.1.0-1 .fc31.x86_64.rpm https://kojipkgs.fedoraproject.org//work/tasks/300/39690300/minetest-server -5.1.0-1.fc31.x86_64.rpm
I see gimp also enabled as a module. So at some point I might have a problem with that as well and need to disable the module.
Don't get me wrong. I think it is great that we have the ability to enable modules to install newer versions. But I don't think we should enable them automatically especially if we can drop support at any moment.
Wait, how did this get enabled as a default module without FESCo approval?
This happened before FESCo policy was defined.
-
Aleksandra Fedorova -
Dennis Payne -
Gwyn Ciesla -
John M. Harris Jr