This package has changed maintainer in the Fedora.
Reassigning to the new maintainer of this component.

FEDORA-2020-67eedc26ca has been submitted as an update to Fedora 31. https://bodhi.fedoraproject.org/updates/FEDORA-2020-67eedc26ca

FEDORA-2020-e25327f046 has been submitted as an update to Fedora 32. https://bodhi.fedoraproject.org/updates/FEDORA-2020-e25327f046

FEDORA-2020-e25327f046 has been pushed to the Fedora 32 testing repository.
In short time you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2020-e25327f046`
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2020-e25327f046

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.

FEDORA-2020-67eedc26ca has been pushed to the Fedora 31 testing repository.
In short time you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2020-67eedc26ca`
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2020-67eedc26ca

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.

FEDORA-2020-e25327f046 has been pushed to the Fedora 32 stable repository.
If problem still persists, please make note of it in this bug report.

FEDORA-2020-67eedc26ca has been pushed to the Fedora 31 stable repository.
If problem still persists, please make note of it in this bug report.

Hi!

Now the package can be installed, but it is not functional. The package did not require the 'mk-files' dependency anymore, and installed, but without those files the bmake tool cannot be used as intended.

I think the proper fix would have been fixing the build of 'mk-files' package, not removing them as dependencies. 

Ideally the following should work (provided gcc is installed, and is available as alias cc):

~~~sh
sudo dnf install bmake

cat << EOF > hello.c
#include <stdio.h>
int main(char **argv)
{
        printf("Hello world!\n");
        return 0;
}

EOF

bmake hello

./hello
~~~

bmake works this way on other distributions, and worked this way on earlier Fedora releases.

What happens now is:

~~~sh
bmake hello
~~~

~~~
bmake: no system rules (sys.mk).

bmake: stopped in /home/ggergely/bmake-test
~~~

and obviously `hello` cannot be executed this way.

Using a makefile with no reference to the system makefiles also does not work.

Thanks!

(In reply to Gabor Gergely from comment #8)
> Hi!
> 
> Now the package can be installed, but it is not functional. The package did
> not require the 'mk-files' dependency anymore, and installed, but without
> those files the bmake tool cannot be used as intended.
> 
> I think the proper fix would have been fixing the build of 'mk-files'
> package, not removing them as dependencies. 
> 
> Ideally the following should work (provided gcc is installed, and is
> available as alias cc):
> 
> ~~~sh
> sudo dnf install bmake
> 
> cat << EOF > hello.c
> #include <stdio.h>
> int main(char **argv)
> {
>         printf("Hello world!\n");
>         return 0;
> }
> 
> EOF
> 
> bmake hello
> 
> ./hello
> ~~~
> 
> bmake works this way on other distributions, and worked this way on earlier
> Fedora releases.
> 
> What happens now is:
> 
> ~~~sh
> bmake hello
> ~~~
> 
> ~~~
> bmake: no system rules (sys.mk).
> 
> bmake: stopped in /home/ggergely/bmake-test
> ~~~
> 
> and obviously `hello` cannot be executed this way.
> 
> Using a makefile with no reference to the system makefiles also does not
> work.
> 
> Thanks!

Oh, did not know this was supposed to work. But it does, once mk-files are installed (again). I have started mk-files review under bug #1839870, because they seem to be still maintained. But their refresh would take more steps than preserving bmake.

Please, report this as a new bug. I think bmake can work with existing Makefile, so it should Recommends: mk-files instead.
They are not mandatory for some use cases, but are obviously missing in this case. The last successfully built mk-files could be used until more recent pass review [1].

I am surprised GNU make allows this use as well. I expected Makefile file have to exist, but it does not.

1. https://koji.fedoraproject.org/koji/buildinfo?buildID=1130737

I also tried it with the following makefile, which also didn't work without mk-files, thus I think it is a hard dependency in case of bmake.

Consider the following:

~~~
[ggergely@semissis ~]$ cd bmake-test/
[ggergely@semissis bmake-test]$ ls
hello.c  makefile
[ggergely@semissis bmake-test]$ cat makefile
hello: hello.c
        cc -o $@ $>
[ggergely@semissis bmake-test]$ cat hello.c
#include <stdio.h>
int main(char **argv)
{
        printf("Hello world!\n");
        return 0;
}

[ggergely@semissis bmake-test]$ bmake
bmake: no system rules (sys.mk).

bmake: stopped in /home/ggergely/bmake-test
[ggergely@semissis bmake-test]$
~~~

No implicit rule is invoked in this case, still the lack of system rules is a blocker.

I happily open a new bug if that is the way to go, just lets agree on what should be its scope/goal first.

Should I open a new bug with the content: "bmake should explicitly depend on mk-files?"

Okay, you were correct. bmake indeed cannot work without mk-files well. I had installed mk-files from recent source and it worked well. After I removed it, most targets stopped working.

Fortunately, upstream maintainer pointed me to already shipped mk files inside bmake release. Extra package is not necessary, just noarch subpackage would be sufficient. So new build would have mk-files shipped.

But sure, once a bug is closed, please open a new one to report errors instead. I have noticed with luck this time, there are some comments. A new bug is more visible.

Ok, so should I open a new bug, to let you book your work onto, or this problem will be solved because I got lucky? It is no effort for me, just want to make sure duplicates and bookkeeping efforts don't waste valuable development time. Opening a new bug is a few minutes for me.