Bug 1748895
| Summary: | On Fedora 31 the ruby module does not meet the criteria. | ||
|---|---|---|---|
| Product: | [Fedora] Fedora Modules | Reporter: | Lukas Ruzicka <lruzicka> |
| Component: | ruby | Assignee: | Vít Ondruch <vondruch> |
| Status: | NEW --- | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
| Severity: | medium | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | unspecified | CC: | csutherl, deadletterfile, jaruga, jprokop, mkocka, mkolman, phracek, rbean, vondruch |
| Target Milestone: | --- | Keywords: | Reopened |
| Target Release: | --- | ||
| Hardware: | x86_64 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | If docs needed, set a value | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2019-09-04 12:14:35 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
|
Description
Lukas Ruzicka
2019-09-04 11:55:48 UTC
We had this discussion previously: https://pagure.io/fesco/issue/2178 *** This bug has been marked as a duplicate of bug 1729150 *** > In Fedora 31, the ruby module has streams with no default profile set, which in my understanding violates the criteria. Each stream of the module should have a valid defaults profile, so that it can be installed using the "dnf module install <module>:<stream>" command. modules/ruby has the default profile on Fedora 30. See below settings. https://pagure.io/releng/fedora-module-defaults/blob/f31/f/ruby.yaml modules/ruby does not have the default stream intentionally. See the discussion https://bugzilla.redhat.com/show_bug.cgi?id=1729150 for detail. > The master stream is malformed! Oh "master" stream is not allowed anymore? What is the alternative? How to fix this? I like keeping the status: NEW until I understand how to fix it. Hello,
I have no objection against a "master" stream in your module. The described problem lies in the fact that the master stream does not have a default profile set. The "table" in my previous comment shows, that streams 2.5 and 2.6 include a profile called "default" that is set as a *default* profile. In that case, DNF reports it in the output of "dnf module list ruby".
It also shows that the master stream does not have such a *default* profile, even if there is a profile called "default". Pretty confusing, right?
For better understanding, let us say that you do not have a profile called "default", but you call it a "server" and you have another called "client". The *default profile* specifies what to install, if the user does not pick up a specific profile. In case the "server" is the *default* profile, "server" would be installed using "dnf module install module:stream".
The ruby.yaml in the fedora-module-defaults does not even show a master stream, have you removed it?:
===========================
document: modulemd-defaults
version: 1
data:
module: ruby
profiles:
2.5: [default]
2.6: [default]
========================
I think what only should be necessary to fix the problem is to alter the ruby.yaml file and build the modules:
===========================
document: modulemd-defaults
version: 1
data:
module: ruby
profiles:
master: [default]
2.5: [default]
2.6: [default]
========================
@jaruga: Maybe the question should be why we have "master" stream. Thanks for the explanation. > The ruby.yaml in the fedora-module-defaults does not even show a master stream, have you removed it?: No, I have not removed it. Because the fedora-module-defaults yaml files are not created automatically from something, but created manually by each maintainer. When I created the initial file, I did not include "master" in it. https://pagure.io/releng/fedora-module-defaults/blob/f31/f/ruby.yaml I do not intend to add "master" stream to the ruby.yaml file, because "master" stream is a kind of development stream. > @jaruga: Maybe the question should be why we have "master" stream. Good point. The role of "master" stream is to test the module's installation and check if the proper binary RPMs are included in the module and the the result of "dnf module ruby info", before releasing "2.5" and "2.6" stream. It is like a development stream. Because right now there is no way to test it before releasing a module in my understanding. Or Budhi can do? *** Bug 1876245 has been marked as a duplicate of this bug. *** Another ticket was opened related to this issue today. If we keeping current status as master without profile, we will potentially receive other ticket related to this issue. That means the current situation is unfriendly, and not intuitive. It's good to time to make a decision. The possible decision I like is as Vit said, to drop "master" branch completely. Pros: We do not need to care about master branch saving our working time. Cons: The modules/ruby's 2.7 branch (the latest version branch) could be more messy. But doing scratch build for a forked repository's branch before pushing the commits might help this issue. Last time I did not know the scratch build for the module build. But when using this, we can solve the messy commits issue. Just in case, now running the scratch build by this operation. If the build is no problem, I think we can stop shipping the master. ``` $ git remote -v j ssh://jaruga.org/modules/ruby.git (fetch) j ssh://jaruga.org/modules/ruby.git (push) origin ssh://jaruga.org/modules/ruby (fetch) origin ssh://jaruga.org/modules/ruby (push) $ git checkout 2.7 $ git checkout -b wip/2.7 $ git commit --allow-empty $ git push j wip/2.7 $ git branch -u j/wip/2.7 Branch 'wip/2.7' set up to track remote branch 'wip/2.7' from 'j'. $ fedpkg module-build --scratch Submitting the module build... The builds 10085, 10086, 10087 and 10088 were submitted to the MBS Build URLs: https://mbs.fedoraproject.org/module-build-service/2/module-builds/10085 https://mbs.fedoraproject.org/module-build-service/2/module-builds/10086 https://mbs.fedoraproject.org/module-build-service/2/module-builds/10087 https://mbs.fedoraproject.org/module-build-service/2/module-builds/10088 $ fedpkg module-build-info 10085 ``` > $ git remote -v > j ssh://jaruga.org/modules/ruby.git (fetch) > j ssh://jaruga.org/modules/ruby.git (push) > origin ssh://jaruga.org/modules/ruby (fetch) > origin ssh://jaruga.org/modules/ruby (push) I am sorry for my wrong operation about above. Actually I created the remote name "j" as same repo URL with "origin" unintentionally. So, when I pushed wip/2.7 branch to "j", it was created to "origin" too. Now "wip/2.7" branch is created on the modules/ruby. And we can not remove it ... https://src.fedoraproject.org/modules/ruby/branches I am trying to test on the wip/2.7 branch in the forked repository again. ``` $ git remote -v j ssh://jaruga.org/forks/jaruga/modules/ruby.git (fetch) j ssh://jaruga.org/forks/jaruga/modules/ruby.git (push) origin ssh://jaruga.org/modules/ruby (fetch) origin ssh://jaruga.org/modules/ruby (push) $ git push j wip/2.7 $ git branch -u j/wip/2.7 $ fedpkg module-build --scratch Submitting the module build... The builds 10089, 10090, 10091 and 10092 were submitted to the MBS Build URLs: https://mbs.fedoraproject.org/module-build-service/2/module-builds/10089 https://mbs.fedoraproject.org/module-build-service/2/module-builds/10090 https://mbs.fedoraproject.org/module-build-service/2/module-builds/10091 https://mbs.fedoraproject.org/module-build-service/2/module-builds/10092 $ fedpkg module-build-info 10089 ``` Error. Humm. https://koji.fedoraproject.org/koji/taskinfo?taskID=51000243 FileNotFoundError: [Errno 2] No such file or directory: '/etc/mock/koji/scrmod-ruby-wip/2.7-3420200907130559-058368ca_2+10089-build-22655560-2043316.cfg' > FileNotFoundError: [Errno 2] No such file or directory: '/etc/mock/koji/scrmod-ruby-wip/2.7-3420200907130559-058368ca_2+10089-build-22655560-2043316.cfg' Asking here. https://pagure.io/fm-orchestrator/issue/1652 > I am sorry for my wrong operation about above. Actually I created the remote name "j" as same repo URL with "origin" unintentionally. I found the branch can be removed as long as commits in the branch are reachable from another branch. [1] Now asking releng to remove the branch. [2] [1] https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/O3CW7QJ53DWGCXM36YDXU5ATBXMNJMKD/ [2] https://pagure.io/releng/issue/9745 We don't technically use the modules/ruby master branch any more. But we cannot update the master branch due to the limitation of the master branch. So, the master branch has still some files. https://src.fedoraproject.org/modules/ruby And we don't have the master branch setting on the following yaml files in the active maintained Fedoras. https://pagure.io/releng/fedora-module-defaults/blob/main/f/ruby.yaml https://pagure.io/releng/fedora-module-defaults/blob/f34/f/ruby.yaml https://pagure.io/releng/fedora-module-defaults/blob/f33/f/ruby.yaml https://pagure.io/releng/fedora-module-defaults/blob/f32/f/ruby.yaml So, if we can drop the shipped ruby master stream that we can see by `dnf module list ruby` on the available Fedoras, we can close this ticket, right? We will drop (untag) the shipped modules/ruby master stream on available Fedoras. Here is what I did to untag a wrongly released ruby module as a reference. https://pagure.io/releng/issue/8279 Not sure we can easily drop the master Ruby module stream, quote from [0] regarding untagging the modules: "This cannot be fixed as we are not running any composes out of f34-modular or f33-modular tag as that is the GA content." So we would probably have to solve another issue concerning the master module branches in general [1]. [0] https://pagure.io/releng/issue/10154 [1] https://pagure.io/releng/issue/10139 |