Description of problem: While working on bind module for F27 I forked https://github.com/modularity-modules/bind as https://github.com/InfrastructureServices/modulatity-modules-bind to distinguish the fork. After cloning it, git created "modulatity-modules-bind" directory. Then I created modulemd file called "bind.yml", as it will be the name of the module. When trying to build the module by following https://docs.pagure.org/modularity/development/building-modules/building-local.html, the command ends with traceback, because of making assumptions. Version-Release number of selected component (if applicable): module-build-service-1.3.24-3.fc25.noarch How reproducible: always Steps to Reproduce: 1. run mbs-build local in a directory with modulemd file named differently, than the directory itself Actual results: thozza@thozza-pc ~/devel/projects/modularity/modulatity-modules-bind (master %=) $ mbs-build local INFO: You have not provided SCM URL or branch. Trying to get it from current working directory INFO: Starting local build of file:///home/thozza/devel/projects/modularity/modulatity-modules-bind, branch master 2017-08-29 15:42:56,961 - MainThread - module_build_service - DEBUG - Setting topics: * 2017-08-29 15:42:57,079 - MainThread - module_build_service - DEBUG - Verifying modulemd 2017-08-29 15:42:57,084 - MainThread - module_build_service - DEBUG - Getting/verifying commit hash for file:///home/thozza/devel/projects/modularity/modulatity-modules-bind Traceback (most recent call last): File "/usr/bin/mbs-manager", line 9, in <module> load_entry_point('module-build-service==1.3.24', 'console_scripts', 'mbs-manager')() File "/usr/lib/python2.7/site-packages/module_build_service/manage.py", line 316, in manager_wrapper manager.run() File "/usr/lib/python2.7/site-packages/flask_script/__init__.py", line 412, in run result = self.handle(sys.argv[0], sys.argv[1:]) File "/usr/lib/python2.7/site-packages/flask_script/__init__.py", line 383, in handle res = handle(*args, **config) File "/usr/lib/python2.7/site-packages/flask_script/commands.py", line 216, in __call__ return self.run(*args, **kwargs) File "/usr/lib/python2.7/site-packages/module_build_service/manage.py", line 153, in build_module_locally skiptests=skiptests) File "/usr/lib/python2.7/site-packages/module_build_service/utils.py", line 733, in submit_module_build_from_scm mmd, scm, yaml = _fetch_mmd(url, branch, allow_local_url) File "/usr/lib/python2.7/site-packages/module_build_service/utils.py", line 431, in _fetch_mmd with open(cofn, "r") as mmdfile: IOError: [Errno 2] No such file or directory: '/tmp/tmpzDCJdn/modulatity-modules-bind/modulatity-modules-bind.yaml' Expected results: No traceback Additional info:
Thanks for the bug report. There's already an existing patch for this which should fix this issue: https://pagure.io/fm-orchestrator/c/09b3f32dbb35bb159d6bb77f696c58baa20667a7 This patch is already present in 1.3.26 release. You can verify the current status of module-build-service: https://bodhi.fedoraproject.org/updates/?search=module-build-service-1.3.26 The update has been submitted for stable by jkaluza. I will mark this one as duplicate for: https://bugzilla.redhat.com/show_bug.cgi?id=1486346
*** This bug has been marked as a duplicate of bug 1486346 ***
(In reply to Filip Valder from comment #1) > Thanks for the bug report. > > There's already an existing patch for this which should fix this issue: > https://pagure.io/fm-orchestrator/c/09b3f32dbb35bb159d6bb77f696c58baa20667a7 > > This patch is already present in 1.3.26 release. > > You can verify the current status of module-build-service: > https://bodhi.fedoraproject.org/updates/?search=module-build-service-1.3.26 > The update has been submitted for stable by jkaluza. > > I will mark this one as duplicate for: > https://bugzilla.redhat.com/show_bug.cgi?id=1486346 This is not a duplicate. I tried 1.3.26 from updates-testing and mbs-build still assumes that the modulemd file has the same name as the CWD, which is NOT true in my case. Also there is still no way how to tell mbs-build what is the name of modulemd file.
The same name of modulemd file and directory of git repo is the presumption we have now in Fedora dist-git and since the code is the very same for local builds as it is for official Fedora infra, it expects git repository as an input and it expects that the name of modulemd file is the same as the name of that directory. I see your use-case and we could make a difference between local builds and official builds done by MBS, but it is not the case right now. The input is the same for both currently.
(In reply to Jan Kaluža from comment #4) > The same name of modulemd file and directory of git repo is the presumption > we have now in Fedora dist-git and since the code is the very same for local > builds as it is for official Fedora infra, it expects git repository as an > input and it expects that the name of modulemd file is the same as the name > of that directory. > > I see your use-case and we could make a difference between local builds and > official builds done by MBS, but it is not the case right now. The input is > the same for both currently. Thanks for the explanation. I understand the main use-case and the reason for assumptions. However I'm afraid that I won't be the only one having this problem, since we are now starting to finally create some modules for F27. It would be helpful, if the tooling could help us to develop modules locally, before they are even added to official Fedora dist-git. This bug is definitely not blocking anyone from experimenting with modules, but it is a usability bug...
Not that because of this bug, it is not possible to locally build modules from git repository if not all assumptions are obeyed. See Bug #1486369 comment #2.
I agree this is confusing. Let's take discussion over here please: https://pagure.io/fm-orchestrator/issue/727