Hi,
As part of the f34 change request[1] for removing make from the buildroot, I will be doing a mass update of packages[2] to add BuildRequires: make where it is needed.
If you are a package maintainer and would prefer to update your packages on your own, please do so before Dec 14, which is when I will begin doing the mass update.
I will be doing the updates in batches, so that if there is a mistake the impact will be limited. Here is the rough schedule of the changes:
Dec 14: Update first 50 packages. Dec 16: Next 1000. Dec 18: Next 1000. Jan 4: Next 1000. Jan 5: Next 1000. Jan 6: Next 1000. Jan 7: Next 1000. Jan 8: Rest of packages.
The deadline for completing these updates is the start of the f34 mass rebuild (Jan 20).
Thanks, Tom
[1] https://fedoraproject.org/wiki/Changes/Remove_make_from_BuildRoot [2] https://fedorapeople.org/~tstellar/needs_br_make_packages.txt
On Mon, Nov 30, 2020 at 3:07 PM Tom Stellard tstellar@redhat.com wrote:
As part of the f34 change request[1] for removing make from the buildroot, I will be doing a mass update of packages[2] to add BuildRequires: make where it is needed.
The packages listed for jjames have all been done, except for these. They look like possible false positives to me:
gap-pkg-circle ocaml-lablgtk3 ocaml-markup ocaml-mlmpfr ocaml-ppxlib ocaml-zmq
Regards,
On 11/30/20 2:20 PM, Jerry James wrote:
On Mon, Nov 30, 2020 at 3:07 PM Tom Stellard tstellar@redhat.com wrote:
As part of the f34 change request[1] for removing make from the buildroot, I will be doing a mass update of packages[2] to add BuildRequires: make where it is needed.
The packages listed for jjames have all been done, except for these. They look like possible false positives to me:
gap-pkg-circle
False positive because it matches the regex ^make
ocaml-lablgtk3 ocaml-mlmpfr ocaml-zmq ocaml-ppxlib
False positive because they use gcc which was crashing due to the (at the time) missing make dependency. Are these packages missing BuildRequires: gcc ?
ocaml-markup
False positive since the usage of make was removed since I last did the rebuild.
I will look into fixing these.
-Tom
Regards,
On Mon, Nov 30, 2020 at 6:37 PM Tom Stellard tstellar@redhat.com wrote:
On 11/30/20 2:20 PM, Jerry James wrote:
ocaml-lablgtk3 ocaml-mlmpfr ocaml-zmq ocaml-ppxlib
False positive because they use gcc which was crashing due to the (at the time) missing make dependency. Are these packages missing BuildRequires: gcc ?
They BR ocaml, which BRs gcc.
Dne 01. 12. 20 v 2:37 Tom Stellard napsal(a):
False positive because they use gcc which was crashing due to the (at the time) missing make dependency. Are these packages missing BuildRequires: gcc ?
Do I understand correctly, that gcc requires make [0]? Therefore at this stage, it should be enough to have `BuildRequires: gcc` and hence such packages should not be on your list?
I am asking, because for example rubygem-bcrypt is on the list while requiring gcc [1]. This is just one package I have checked (but actually I have added make to the ruby package, later wondering if it was necessary), but I suspect that also other rubygem- packages are similar case. Could you please make sure if they should or should not be on your list?
Vít
[0] https://src.fedoraproject.org/rpms/gcc/blob/master/f/gcc.spec#_252
[1] https://src.fedoraproject.org/rpms/rubygem-bcrypt/blob/master/f/rubygem-bcry...
On Tue, Dec 01, 2020 at 01:20:33PM +0100, VÃt Ondruch wrote:
Dne 01. 12. 20 v 2:37 Tom Stellard napsal(a):
False positive because they use gcc which was crashing due to the (at the time) missing make dependency. Are these packages missing BuildRequires: gcc ?
Do I understand correctly, that gcc requires make [0]? Therefore at this stage, it should be enough to have `BuildRequires: gcc` and hence such packages should not be on your list?
I have added that BuildRequires: make to gcc only recently.
Jakub
On Tuesday, December 1, 2020 1:49:59 PM CET Jakub Jelinek wrote:
On Tue, Dec 01, 2020 at 01:20:33PM +0100, VÃt Ondruch wrote:
Dne 01. 12. 20 v 2:37 Tom Stellard napsal(a):
False positive because they use gcc which was crashing due to the (at the time) missing make dependency. Are these packages missing BuildRequires: gcc ?
Do I understand correctly, that gcc requires make [0]? Therefore at this stage, it should be enough to have `BuildRequires: gcc` and hence such packages should not be on your list?
I have added that BuildRequires: make to gcc only recently.
Can you confirm there's also Requires: make?
Pavel
Jakub _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-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/devel@lists.fedoraproject.org
On Tue, Dec 01, 2020 at 03:41:59PM +0100, Pavel Raiskup wrote:
On Tuesday, December 1, 2020 1:49:59 PM CET Jakub Jelinek wrote:
On Tue, Dec 01, 2020 at 01:20:33PM +0100, VÃÂt Ondruch wrote:
Dne 01. 12. 20 v 2:37 Tom Stellard napsal(a):
False positive because they use gcc which was crashing due to the (at the time) missing make dependency. Are these packages missing BuildRequires: gcc ?
Do I understand correctly, that gcc requires make [0]? Therefore at this stage, it should be enough to have `BuildRequires: gcc` and hence such packages should not be on your list?
I have added that BuildRequires: make to gcc only recently.
Can you confirm there's also Requires: make?
Yes.
Jakub
On Tue, Dec 01, 2020 at 01:20:33PM +0100, Vít Ondruch wrote:
Dne 01. 12. 20 v 2:37 Tom Stellard napsal(a):
False positive because they use gcc which was crashing due to the (at the time) missing make dependency. Are these packages missing BuildRequires: gcc ?
Do I understand correctly, that gcc requires make [0]? Therefore at this stage, it should be enough to have `BuildRequires: gcc` and hence such packages should not be on your list?
Please don't rely on gcc requiring make. This is an internal implementation detail of the gcc package, and hopefully one day we'll be able to drop this dependency. If a package uses make directly, it should BR:make itself.
Zbyszek
I am asking, because for example rubygem-bcrypt is on the list while requiring gcc [1]. This is just one package I have checked (but actually I have added make to the ruby package, later wondering if it was necessary), but I suspect that also other rubygem- packages are similar case. Could you please make sure if they should or should not be on your list?
Dne 01. 12. 20 v 13:56 Zbigniew Jędrzejewski-Szmek napsal(a):
On Tue, Dec 01, 2020 at 01:20:33PM +0100, Vít Ondruch wrote:
Dne 01. 12. 20 v 2:37 Tom Stellard napsal(a):
False positive because they use gcc which was crashing due to the (at the time) missing make dependency. Are these packages missing BuildRequires: gcc ?
Do I understand correctly, that gcc requires make [0]? Therefore at this stage, it should be enough to have `BuildRequires: gcc` and hence such packages should not be on your list?
Please don't rely on gcc requiring make. This is an internal implementation detail of the gcc package, and hopefully one day we'll be able to drop this dependency. If a package uses make directly, it should BR:make itself.
I think this was never clear cut if such dependency should be specified or not. The dependencies, which are at some point added for whatever good reason might be left behind while they are not useful anymore. This problem on itself is much harder to solve then adding the missing dependencies should they be needed one day.
So while I don't disagree with your point, I think the the `BR: make` should be automatically added only where needed right now to prevent FTBFS after make removal.
Vít
Zbyszek
I am asking, because for example rubygem-bcrypt is on the list while requiring gcc [1]. This is just one package I have checked (but actually I have added make to the ruby package, later wondering if it was necessary), but I suspect that also other rubygem- packages are similar case. Could you please make sure if they should or should not be on your list?
devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-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/devel@lists.fedoraproject.org
On 12/1/20 8:33 AM, Vít Ondruch wrote:
Dne 01. 12. 20 v 13:56 Zbigniew Jędrzejewski-Szmek napsal(a):
On Tue, Dec 01, 2020 at 01:20:33PM +0100, Vít Ondruch wrote:
Dne 01. 12. 20 v 2:37 Tom Stellard napsal(a):
False positive because they use gcc which was crashing due to the (at the time) missing make dependency. Are these packages missing BuildRequires: gcc ?
Do I understand correctly, that gcc requires make [0]? Therefore at this stage, it should be enough to have `BuildRequires: gcc` and hence such packages should not be on your list?
Please don't rely on gcc requiring make. This is an internal implementation detail of the gcc package, and hopefully one day we'll be able to drop this dependency. If a package uses make directly, it should BR:make itself.
I think this was never clear cut if such dependency should be specified or not. The dependencies, which are at some point added for whatever good reason might be left behind while they are not useful anymore. This problem on itself is much harder to solve then adding the missing dependencies should they be needed one day.
So while I don't disagree with your point, I think the the `BR: make` should be automatically added only where needed right now to prevent FTBFS after make removal.
Now that gcc requires make, if we took this approach there would be very few packages that need to be updated for this change request. If gcc did decide to drop the make dependency or make it weak, who would take on the work of updating the thousands of packages that use make? Right now, we have someone (me) who is willing an able to do the updates, and I think we should this is a good reason to update all the packages now.
-Tom
Vít
Zbyszek
I am asking, because for example rubygem-bcrypt is on the list while requiring gcc [1]. This is just one package I have checked (but actually I have added make to the ruby package, later wondering if it was necessary), but I suspect that also other rubygem- packages are similar case. Could you please make sure if they should or should not be on your list?
devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-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/devel@lists.fedoraproject.org
devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-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/devel@lists.fedoraproject.org
On Tue, Dec 1, 2020 at 7:38 PM Tom Stellard tstellar@redhat.com wrote:
On 12/1/20 8:33 AM, Vít Ondruch wrote:
Dne 01. 12. 20 v 13:56 Zbigniew Jędrzejewski-Szmek napsal(a):
On Tue, Dec 01, 2020 at 01:20:33PM +0100, Vít Ondruch wrote:
Dne 01. 12. 20 v 2:37 Tom Stellard napsal(a):
False positive because they use gcc which was crashing due to the (at the time) missing make dependency. Are these packages missing BuildRequires: gcc ?
Do I understand correctly, that gcc requires make [0]? Therefore at this stage, it should be enough to have `BuildRequires: gcc` and hence such packages should not be on your list?
Please don't rely on gcc requiring make. This is an internal implementation detail of the gcc package, and hopefully one day we'll be able to drop this dependency. If a package uses make directly, it should BR:make itself.
I think this was never clear cut if such dependency should be specified or not. The dependencies, which are at some point added for whatever good reason might be left behind while they are not useful anymore. This problem on itself is much harder to solve then adding the missing dependencies should they be needed one day.
So while I don't disagree with your point, I think the the `BR: make` should be automatically added only where needed right now to prevent FTBFS after make removal.
Now that gcc requires make, if we took this approach there would be very few packages that need to be updated for this change request. If gcc did decide to drop the make dependency or make it weak, who would take on the work of updating the thousands of packages that use make? Right now, we have someone (me) who is willing an able to do the updates, and I think we should this is a good reason to update all the packages now.
Please, update all of them.
Assuming that something is present because default buildroot / my dependencies have always pulled it in for me / magic just leads to unexpected future breakage. If the packages call make, they need to BR make. And the same for everything else.
Yes, packages might accumulate dependencies that are no longer required but it's the packager's responsibility to ensure everything is up-to-date. Rebasing isn't just about uploading a new tarball and checking if it builds.
P
Dne 01. 12. 20 v 19:35 Tom Stellard napsal(a):
On 12/1/20 8:33 AM, Vít Ondruch wrote:
Dne 01. 12. 20 v 13:56 Zbigniew Jędrzejewski-Szmek napsal(a):
On Tue, Dec 01, 2020 at 01:20:33PM +0100, Vít Ondruch wrote:
Dne 01. 12. 20 v 2:37 Tom Stellard napsal(a):
False positive because they use gcc which was crashing due to the (at the time) missing make dependency. Are these packages missing BuildRequires: gcc ?
Do I understand correctly, that gcc requires make [0]? Therefore at this stage, it should be enough to have `BuildRequires: gcc` and hence such packages should not be on your list?
Please don't rely on gcc requiring make. This is an internal implementation detail of the gcc package, and hopefully one day we'll be able to drop this dependency. If a package uses make directly, it should BR:make itself.
I think this was never clear cut if such dependency should be specified or not. The dependencies, which are at some point added for whatever good reason might be left behind while they are not useful anymore. This problem on itself is much harder to solve then adding the missing dependencies should they be needed one day.
So while I don't disagree with your point, I think the the `BR: make` should be automatically added only where needed right now to prevent FTBFS after make removal.
Now that gcc requires make, if we took this approach there would be very few packages that need to be updated for this change request. If gcc did decide to drop the make dependency or make it weak, who would take on the work of updating the thousands of packages that use make? Right now, we have someone (me) who is willing an able to do the updates, and I think we should this is a good reason to update all the packages now.
As a Ruby maintainer, I generally care about all rubygems- packages and since there is more then a few on the list, I was considering also other options, such as adding `BR: make` as a dependency of ruby{,gems}-devel or possibly directly into rubygems package, because honestly it is not that obvious that some rubygem- packages depends on make, because this dependency is well hidden. This is one thing.
But there are others. If the decision is to move forward with the change, then there should be fixed not only the rubygem- packages in question, but there should be fixed also gem2rpm to add the dependency.
Please don't get me wrong, I don't object the change. I especially don't object to the "Remove make from BuildRoot". I just want to highlight that that the landscape slightly changed since the initial proposal, because gcc explicitly depends on make and there are different possible options for some of the packages. And there are necessary changes which are left out of the scope. Therefore it might be good to focus again on the original proposal, which was not to "Add make dependency to every package which requires make."
Vít
-Tom
Vít
Zbyszek
I am asking, because for example rubygem-bcrypt is on the list while requiring gcc [1]. This is just one package I have checked (but actually I have added make to the ruby package, later wondering if it was necessary), but I suspect that also other rubygem- packages are similar case. Could you please make sure if they should or should not be on your list?
devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-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/devel@lists.fedoraproject.org
devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-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/devel@lists.fedoraproject.org
Dne 30. 11. 20 v 23:06 Tom Stellard napsal(a):
I will be doing the updates in batches, so that if there is a mistake the impact will be limited.
You mean: create PRs is src.fedoraproject.org?
On 11/30/20 2:31 PM, Miroslav Suchý wrote:
Dne 30. 11. 20 v 23:06 Tom Stellard napsal(a):
I will be doing the updates in batches, so that if there is a mistake the impact will be limited.
You mean: create PRs is src.fedoraproject.org?
No, I will be committing to dist-git directly and not using PRs.
-Tom
On Mon, 30 Nov 2020 at 23:16, Tom Stellard tstellar@redhat.com wrote:
Hi,
As part of the f34 change request[1] for removing make from the buildroot, I will be doing a mass update of packages[2] to add BuildRequires: make where it is needed.
Packages listed for iucar, done.
On 30/11/2020 22:06, Tom Stellard wrote:
As part of the f34 change request[1] for removing make from the buildroot, I will be doing a mass update of packages[2] to add BuildRequires: make where it is needed.
What happened to excluding packages which use cmake?
Tom
On Mon, Nov 30, 2020 at 4:05 PM Tom Hughes via devel devel@lists.fedoraproject.org wrote:
On 30/11/2020 22:06, Tom Stellard wrote:
As part of the f34 change request[1] for removing make from the buildroot, I will be doing a mass update of packages[2] to add BuildRequires: make where it is needed.
What happened to excluding packages which use cmake?
The packages would still need to depend on make or ninja.
Christoph
Tom
-- Tom Hughes (tom@compton.nu) http://compton.nu/ _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-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/devel@lists.fedoraproject.org
On 30/11/2020 23:14, Christoph Junghans wrote:
On Mon, Nov 30, 2020 at 4:05 PM Tom Hughes via devel devel@lists.fedoraproject.org wrote:
On 30/11/2020 22:06, Tom Stellard wrote:
As part of the f34 change request[1] for removing make from the buildroot, I will be doing a mass update of packages[2] to add BuildRequires: make where it is needed.
What happened to excluding packages which use cmake?
The packages would still need to depend on make or ninja.
Do we really have to go through this all again?
As discussed in the previous cycle of this discussion make is the default - if you use the %cmake macros without specifying a backend then they will default to make which means you just run cmake and it runs make.
In that circumstance the package correctly depends on cmake, and it depends on make as it's chosen backend and there is no reason for the packager to know or care which backend cmake has chosen to use.
I thought that had eventually been accepted by the authors of this proposal but I see no sign of that in the latest list of affected packages.
But I guess at this point I need to give up arguing and get on with updating eleven packages...
Tom
On Tue, Dec 1, 2020 at 1:06 AM Tom Hughes via devel devel@lists.fedoraproject.org wrote:
On 30/11/2020 23:14, Christoph Junghans wrote:
On Mon, Nov 30, 2020 at 4:05 PM Tom Hughes via devel devel@lists.fedoraproject.org wrote:
On 30/11/2020 22:06, Tom Stellard wrote:
As part of the f34 change request[1] for removing make from the buildroot, I will be doing a mass update of packages[2] to add BuildRequires: make where it is needed.
What happened to excluding packages which use cmake?
The packages would still need to depend on make or ninja.
Do we really have to go through this all again?
As discussed in the previous cycle of this discussion make is the default - if you use the %cmake macros without specifying a backend then they will default to make which means you just run cmake and it runs make.
In that circumstance the package correctly depends on cmake, and it depends on make as it's chosen backend and there is no reason for the packager to know or care which backend cmake has chosen to use.
I thought that had eventually been accepted by the authors of this proposal but I see no sign of that in the latest list of affected packages.
But I guess at this point I need to give up arguing and get on with updating eleven packages...
I am unsure why there is so much confusion about this, because cmake *does* Require make: https://src.fedoraproject.org/rpms/cmake/blob/master/f/cmake.spec#_185 So, will this dependency be removed? Otherwise the whole point is moot in the case of CMake.
Fabio
On 11/30/20 4:06 PM, Tom Hughes via devel wrote:
On 30/11/2020 23:14, Christoph Junghans wrote:
On Mon, Nov 30, 2020 at 4:05 PM Tom Hughes via devel devel@lists.fedoraproject.org wrote:
On 30/11/2020 22:06, Tom Stellard wrote:
As part of the f34 change request[1] for removing make from the buildroot, I will be doing a mass update of packages[2] to add BuildRequires: make where it is needed.
What happened to excluding packages which use cmake?
The packages would still need to depend on make or ninja.
Do we really have to go through this all again?
As discussed in the previous cycle of this discussion make is the default - if you use the %cmake macros without specifying a backend then they will default to make which means you just run cmake and it runs make.
In that circumstance the package correctly depends on cmake, and it depends on make as it's chosen backend and there is no reason for the packager to know or care which backend cmake has chosen to use.
I thought that had eventually been accepted by the authors of this proposal but I see no sign of that in the latest list of affected packages.
We never came to a conclusion on this, because it was unclear whether make was going to be a weak or strong dependency of cmake.
-Tom
But I guess at this point I need to give up arguing and get on with updating eleven packages...
Tom
On Mon, Nov 30, 2020 at 11:10 PM Tom Stellard tstellar@redhat.com wrote:
If you are a package maintainer and would prefer to update your packages on your own, please do so before Dec 14, which is when I will begin doing the mass update.
Checking packages linked to my name...
pamix: only calls %cmake macros, BRs cmake, so that's the other topic perl-Dist-Zilla-Plugin-Test-Compile: uses perl(Module::Build); false positive, I believe sselp: fixed & switched to %make_* macros
P
On 30.11.2020 23:06, Tom Stellard wrote:
aircrack-ng argyllcms aseman-qt-tools earlyoom foo2zjs ghostwriter git-subrepo goldendict hashcat ht kiwix-desktop lcms pidgin-groupchat-typing-notifications pidgin-toobars purple-discord purple-hangouts purple-libsteam purple-matrix purple-skypeweb qr-code-generator
Fixed.
psi-plus purple-plugin_pack
False positives.
Dne 30. 11. 20 v 23:06 Tom Stellard napsal(a):
If you are a package maintainer and would prefer to update your packages on your own, please do so before Dec 14, which is when I will begin doing the mass update.
python-satyr is false positive as it is EPEL only package
abrt abrt-java-connector copr-backend copr-keygen libreport python-copr satyr
Changed in upstream. It should propagate to Fedora soon. If you will be first, I do not mind.
imvirt obs-signd pg-semver rpmconf
Updated.
Hi,
Le 30/11/2020 à 23:06, Tom Stellard a écrit :
If you are a package maintainer and would prefer to update your packages on your own, please do so before Dec 14, which is when I will begin doing the mass update.
php is done.
For all php-*, as they require "php-devel" which requires "make" no change are really needed
Remi
P.S. PHP extension development rely on php build system which generate stuff using auto*, make, gcc, ... so IMHO make sense to have them required by php-devel
On 11/30/20 4:06 PM, Tom Stellard wrote:
As part of the f34 change request[1] for removing make from the buildroot, I will be doing a mass update of packages[2] to add BuildRequires: make where it is needed.
If you are a package maintainer and would prefer to update your packages on your own, please do so before Dec 14, which is when I will begin doing the mass update.
rb_libtorrent
False positive, but this package was changed to Ninja on Nov. 25 and I don't know when you ran your scan.
Hi Tom,
On Mon, 2020-11-30 at 14:06 -0800, Tom Stellard wrote:
As part of the f34 change request[1] for removing make from the buildroot, I will be doing a mass update of packages[2] to add BuildRequires: make where it is needed.
As part of a previous change request [1] various packages were transformed to use make macros (%make_build, %make_install) do these macros automagically pull in the make build requires (or can they be made to do so)?
Thanks,
Mark
[1] https://fedoraproject.org/wiki/Changes/UseMakeBuildInstallMacro
On 12/2/20 2:37 AM, Mark Wielaard wrote:
Hi Tom,
On Mon, 2020-11-30 at 14:06 -0800, Tom Stellard wrote:
As part of the f34 change request[1] for removing make from the buildroot, I will be doing a mass update of packages[2] to add BuildRequires: make where it is needed.
As part of a previous change request [1] various packages were transformed to use make macros (%make_build, %make_install) do these macros automagically pull in the make build requires (or can they be made to do so)?
I don't know of a way to do this.
-Tom
Thanks,
Mark
[1] https://fedoraproject.org/wiki/Changes/UseMakeBuildInstallMacro _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-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/devel@lists.fedoraproject.org
How to quickly retest packages which listed here https://fedorapeople.org/~tstellar/needs_br_make_packages.txt? I've tested few locally and in Koji Rawhide scratch, but they are compiled fine.
On 12/2/20 5:45 AM, Artem Tim wrote:
How to quickly retest packages which listed here https://fedorapeople.org/~tstellar/needs_br_make_packages.txt? I've tested few locally and in Koji Rawhide scratch, but they are compiled fine. ___
If the packages use make and they BuildRequire: make then there is nothing else to do. I will try to re-run the scripts everyday to keep the list updated.
-Tom
____________________________________________
devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-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/devel@lists.fedoraproject.org
On Thu, Dec 3, 2020 at 4:35 PM Tom Stellard tstellar@redhat.com wrote:
On 12/2/20 5:45 AM, Artem Tim wrote:
How to quickly retest packages which listed here https://fedorapeople.org/~tstellar/needs_br_make_packages.txt? I've tested few locally and in Koji Rawhide scratch, but they are compiled fine. ___
If the packages use make and they BuildRequire: make then there is nothing else to do. I will try to re-run the scripts everyday to keep the list updated.
I still think a lot of those are "false positives". CMake has a hard Requires on make, so if I BuildRequires cmake, adding "BuildRequires: make" is just redundant. https://src.fedoraproject.org/rpms/cmake/blob/master/f/cmake.spec#_185
Fabio
On 03/12/2020 15:39, Fabio Valentini wrote:
On Thu, Dec 3, 2020 at 4:35 PM Tom Stellard tstellar@redhat.com wrote:
On 12/2/20 5:45 AM, Artem Tim wrote:
How to quickly retest packages which listed here https://fedorapeople.org/~tstellar/needs_br_make_packages.txt? I've tested few locally and in Koji Rawhide scratch, but they are compiled fine. ___
If the packages use make and they BuildRequire: make then there is nothing else to do. I will try to re-run the scripts everyday to keep the list updated.
I still think a lot of those are "false positives". CMake has a hard Requires on make, so if I BuildRequires cmake, adding "BuildRequires: make" is just redundant. https://src.fedoraproject.org/rpms/cmake/blob/master/f/cmake.spec#_185
Yes we've explained that multiple times.
I gave in in the end and just added the BR to my cmake packages.
Tom
On 12/3/20 7:39 AM, Fabio Valentini wrote:
On Thu, Dec 3, 2020 at 4:35 PM Tom Stellard tstellar@redhat.com wrote:
On 12/2/20 5:45 AM, Artem Tim wrote:
How to quickly retest packages which listed here https://fedorapeople.org/~tstellar/needs_br_make_packages.txt? I've tested few locally and in Koji Rawhide scratch, but they are compiled fine. ___
If the packages use make and they BuildRequire: make then there is nothing else to do. I will try to re-run the scripts everyday to keep the list updated.
I still think a lot of those are "false positives". CMake has a hard Requires on make, so if I BuildRequires cmake, adding "BuildRequires: make" is just redundant. https://src.fedoraproject.org/rpms/cmake/blob/master/f/cmake.spec#_185
The only safe way to do this is to add BuildRequires: make to every package that uses make. We can't depend on these dependency chains to keep things working, because they may not always be there.
-Tom
Fabio _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-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/devel@lists.fedoraproject.org
On Thu, 3 Dec 2020 at 11:18, Tom Stellard tstellar@redhat.com wrote:
On 12/3/20 7:39 AM, Fabio Valentini wrote:
On Thu, Dec 3, 2020 at 4:35 PM Tom Stellard tstellar@redhat.com wrote:
On 12/2/20 5:45 AM, Artem Tim wrote:
How to quickly retest packages which listed here
https://fedorapeople.org/~tstellar/needs_br_make_packages.txt? I've tested few locally and in Koji Rawhide scratch, but they are compiled fine.
If the packages use make and they BuildRequire: make then there is nothing else to do. I will try to re-run the scripts everyday to keep the list updated.
I still think a lot of those are "false positives". CMake has a hard Requires on make, so if I BuildRequires cmake, adding "BuildRequires: make" is just redundant. https://src.fedoraproject.org/rpms/cmake/blob/master/f/cmake.spec#_185
The only safe way to do this is to add BuildRequires: make to every package that uses make. We can't depend on these dependency chains to keep things working, because they may not always be there.
Why even use dependency chains then. Just cite every package every package needs in the buildroot and assume that nothing can expect anything 1 step further?
-Tom
Fabio _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-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/devel@lists.fedoraproject.org
devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-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/devel@lists.fedoraproject.org
On Thu, Dec 3, 2020 at 5:17 PM Tom Stellard tstellar@redhat.com wrote:
On 12/3/20 7:39 AM, Fabio Valentini wrote:
On Thu, Dec 3, 2020 at 4:35 PM Tom Stellard tstellar@redhat.com wrote:
On 12/2/20 5:45 AM, Artem Tim wrote:
How to quickly retest packages which listed here https://fedorapeople.org/~tstellar/needs_br_make_packages.txt? I've tested few locally and in Koji Rawhide scratch, but they are compiled fine. ___
If the packages use make and they BuildRequire: make then there is nothing else to do. I will try to re-run the scripts everyday to keep the list updated.
I still think a lot of those are "false positives". CMake has a hard Requires on make, so if I BuildRequires cmake, adding "BuildRequires: make" is just redundant. https://src.fedoraproject.org/rpms/cmake/blob/master/f/cmake.spec#_185
The only safe way to do this is to add BuildRequires: make to every package that uses make. We can't depend on these dependency chains to keep things working, because they may not always be there.
That argument doesn't hold much water. CMake always requires a backend, and right now it hard-requires make. Until that's no longer the case, adding BR: make to packages already having BR: cmake is just a waste of time. If I can't be sure of *anything*, then wouldn't I have to add the entire expected dependency tree as BRs?, down to glibc and filesystem?
In my spec files, I use %cmake, %cmake_build and %cmake_install. A priori, I now that I must add BuildRequires cmake but I don't now the details of the macro. So, I don't now if the %cmake macro is tuned to build a ninja or a make project. I think the cmake should ship a minima the build tools used by the %cmake macro.
----- Mail original ----- De: "Fabio Valentini" decathorpe@gmail.com À: "Development discussions related to Fedora" devel@lists.fedoraproject.org Envoyé: Jeudi 3 Décembre 2020 17:32:24 Objet: Re: Mass spec file change: Adding BuildRequires: make
On Thu, Dec 3, 2020 at 5:17 PM Tom Stellard tstellar@redhat.com wrote:
On 12/3/20 7:39 AM, Fabio Valentini wrote:
On Thu, Dec 3, 2020 at 4:35 PM Tom Stellard tstellar@redhat.com wrote:
On 12/2/20 5:45 AM, Artem Tim wrote:
How to quickly retest packages which listed here https://fedorapeople.org/~tstellar/needs_br_make_packages.txt? I've tested few locally and in Koji Rawhide scratch, but they are compiled fine. ___
If the packages use make and they BuildRequire: make then there is nothing else to do. I will try to re-run the scripts everyday to keep the list updated.
I still think a lot of those are "false positives". CMake has a hard Requires on make, so if I BuildRequires cmake, adding "BuildRequires: make" is just redundant. https://src.fedoraproject.org/rpms/cmake/blob/master/f/cmake.spec#_185
The only safe way to do this is to add BuildRequires: make to every package that uses make. We can't depend on these dependency chains to keep things working, because they may not always be there.
That argument doesn't hold much water. CMake always requires a backend, and right now it hard-requires make. Until that's no longer the case, adding BR: make to packages already having BR: cmake is just a waste of time. If I can't be sure of *anything*, then wouldn't I have to add the entire expected dependency tree as BRs?, down to glibc and filesystem? _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-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/devel@lists.fedoraproject.org
On 12/3/20 8:32 AM, Fabio Valentini wrote:
On Thu, Dec 3, 2020 at 5:17 PM Tom Stellard tstellar@redhat.com wrote:
On 12/3/20 7:39 AM, Fabio Valentini wrote:
On Thu, Dec 3, 2020 at 4:35 PM Tom Stellard tstellar@redhat.com wrote:
On 12/2/20 5:45 AM, Artem Tim wrote:
How to quickly retest packages which listed here https://fedorapeople.org/~tstellar/needs_br_make_packages.txt? I've tested few locally and in Koji Rawhide scratch, but they are compiled fine. ___
If the packages use make and they BuildRequire: make then there is nothing else to do. I will try to re-run the scripts everyday to keep the list updated.
I still think a lot of those are "false positives". CMake has a hard Requires on make, so if I BuildRequires cmake, adding "BuildRequires: make" is just redundant. https://src.fedoraproject.org/rpms/cmake/blob/master/f/cmake.spec#_185
The only safe way to do this is to add BuildRequires: make to every package that uses make. We can't depend on these dependency chains to keep things working, because they may not always be there.
That argument doesn't hold much water. CMake always requires a backend, and right now it hard-requires make. Until that's no longer the case, adding BR: make to packages already having BR: cmake is just a waste of time. If I can't be sure of *anything*, then wouldn't I have to add the entire expected dependency tree as BRs?, down to glibc and filesystem?
There is a difference between packages that are needed to build and packages that are just dependencies of other packages. For example, if your package uses make you should BuildRequire: make. You do not need to BuildRequire: guile22 which is a dependency of make. Why? Because if make drops the dependency on guile22, your package will continue to build correctly. I am not suggesting that packages that use make need to also BuildRequire: guile22, for example.
I do think cmake is a special case due to the new %cmake_build macros. It's possible for packages to only use the macros and rely on whatever make's default build system generator is. In this specific case, I think that omitting BuildRequires: make is a valid option.
However, in the discussion on the mailing list for this change, not everyone agreed that cmake should Require make and this point was never resolved. So, since there is still ambiguity here, I am planning to do the safest option, which is to add BuildRequires: make even for packages that use %cmake_build and do not invoke make directly.
I am not planning to start doing any changes for another 10 days. Would it make sense to take this specific issue with the %cmake_build macros to FESCO and get a definitive decision? I don't really have any strong opinions here, I just really want to avoid this change causing mass build failures either now or in the future, which is why I have been arguing for the 'safer' approach. I am perfectly fine to take a different approach if FESCO decides something else would be better.
-Tom
devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-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/devel@lists.fedoraproject.org
On 12/3/20 7:27 PM, Tom Stellard wrote:
On 12/3/20 8:32 AM, Fabio Valentini wrote:
On Thu, Dec 3, 2020 at 5:17 PM Tom Stellard tstellar@redhat.com wrote:
On 12/3/20 7:39 AM, Fabio Valentini wrote:
On Thu, Dec 3, 2020 at 4:35 PM Tom Stellard tstellar@redhat.com wrote:
On 12/2/20 5:45 AM, Artem Tim wrote:
How to quickly retest packages which listed here https://fedorapeople.org/~tstellar/needs_br_make_packages.txt? I've tested few locally and in Koji Rawhide scratch, but they are compiled fine. ___
If the packages use make and they BuildRequire: make then there is nothing else to do. I will try to re-run the scripts everyday to keep the list updated.
I still think a lot of those are "false positives". CMake has a hard Requires on make, so if I BuildRequires cmake, adding "BuildRequires: make" is just redundant. https://src.fedoraproject.org/rpms/cmake/blob/master/f/cmake.spec#_185
The only safe way to do this is to add BuildRequires: make to every package that uses make. We can't depend on these dependency chains to keep things working, because they may not always be there.
That argument doesn't hold much water. CMake always requires a backend, and right now it hard-requires make. Until that's no longer the case, adding BR: make to packages already having BR: cmake is just a waste of time. If I can't be sure of *anything*, then wouldn't I have to add the entire expected dependency tree as BRs?, down to glibc and filesystem?
There is a difference between packages that are needed to build and packages that are just dependencies of other packages. For example, if your package uses make you should BuildRequire: make. You do not need to BuildRequire: guile22 which is a dependency of make. Why? Because if make drops the dependency on guile22, your package will continue to build correctly. I am not suggesting that packages that use make need to also BuildRequire: guile22, for example.
+1
I do think cmake is a special case due to the new %cmake_build macros. It's possible for packages to only use the macros and rely on whatever make's default build system generator is. In this specific case, I think that omitting BuildRequires: make is a valid option.
Indeed. If you're only ever invoking 'cmake' and not 'make', then you're simply using services provided by 'cmake' and how they go about providing it is none of your business, and its up to cmake to handle the dependencies in that case.
However, in the discussion on the mailing list for this change, not everyone agreed that cmake should Require make and this point was never resolved. So, since there is still ambiguity here, I am planning to do the safest option, which is to add BuildRequires: make even for packages that use %cmake_build and do not invoke make directly.
I am not planning to start doing any changes for another 10 days. Would it make sense to take this specific issue with the %cmake_build macros to FESCO and get a definitive decision? I don't really have any strong opinions here, I just really want to avoid this change causing mass build failures either now or in the future, which is why I have been arguing for the 'safer' approach. I am perfectly fine to take a different approach if FESCO decides something else would be better.
These discussions reappear on semi-predictable cycles and then go around and round and round...
Fundamentally, the generic issue at hand is not any different from the DSO linkage change ten years ago. For those who don't remember or weren't around, see https://fedoraproject.org/wiki/Features/ChangeInImplicitDSOLinking https://fedoraproject.org/wiki/UnderstandingDSOLinkChange
The world is that little bit better place thanks to that change, and all the principles and reasoning holds for package dependencies as well.
- Panu -
-Tom
devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-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/devel@lists.fedoraproject.org
devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-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/devel@lists.fedoraproject.org
On 12/3/20 6:27 PM, Tom Stellard wrote:
However, in the discussion on the mailing list for this change, not everyone agreed that cmake should Require make and this point was never resolved. So, since there is still ambiguity here, I am planning to do the safest option, which is to add BuildRequires: make even for packages that use %cmake_build and do not invoke make directly.
For what's it worth I think that packages that only use make via cmake should not have an explcit dependency on make. Packages that use make directly should have an explicit dependency on make (even if they already BR cmake).
On Fri, Dec 4, 2020 at 12:55 PM Miro Hrončok mhroncok@redhat.com wrote:
For what's it worth I think that packages that only use make via cmake should not have an explcit dependency on make. Packages that use make directly should have an explicit dependency on make (even if they already BR cmake).
Does that mean that if the requires: make that is currently in the cmake package that was added due to rhbz#1862014 is removed (as has been proposed since ninja is a valid alternative) that you are fine with packagers having to go fix their packages? Or would you expect another pass across all packages to add a BR: make to be done? If the later, it makes sense to me to do it once (when someone is willing to do the work) to prepare for any cmake cleanup(s).
On Friday, 04 December 2020 at 17:20, Gary Buhrmaster wrote:
On Fri, Dec 4, 2020 at 12:55 PM Miro Hrončok mhroncok@redhat.com wrote:
For what's it worth I think that packages that only use make via cmake should not have an explcit dependency on make. Packages that use make directly should have an explicit dependency on make (even if they already BR cmake).
Does that mean that if the requires: make that is currently in the cmake package that was added due to rhbz#1862014 is removed (as has been proposed since ninja is a valid alternative) that you are fine with packagers having to go fix their packages? Or would you expect another pass across all packages to add a BR: make to be done? If the later, it makes sense to me to do it once (when someone is willing to do the work) to prepare for any cmake cleanup(s).
Wouldn't this work for cmake?
Requires: (make or ninja) Suggests: make
Regards, Dominik
On Fri, Dec 4, 2020 at 4:21 PM Gary Buhrmaster gary.buhrmaster@gmail.com wrote:
On Fri, Dec 4, 2020 at 12:55 PM Miro Hrončok mhroncok@redhat.com wrote:
For what's it worth I think that packages that only use make via cmake
should
not have an explcit dependency on make. Packages that use make directly
should
have an explicit dependency on make (even if they already BR cmake).
Does that mean that if the requires: make that is currently in the cmake package that was added due to rhbz#1862014 is removed (as has been proposed since ninja is a valid alternative) that you are fine with packagers having to go fix their packages? Or would you expect another pass across all packages to add a BR: make to be done? If the later, it makes sense to me to do it once (when someone is willing to do the work) to prepare for any cmake cleanup(s).
I think the CMake package should always provide at least one build system as a dependency, otherwise someone could install cmake and not be able to fully use it. This is a case where we can be "opinionated" in the CMake package and set a default build system for cmake in the package since it is trivial for the user to change the generator at runtime with the -G option.
Then any consumers of the %cmake_* macros should rely on the choice of the CMake package for the system unless they want to override it themselves.
-Ian
On 12/4/20 4:55 AM, Miro Hrončok wrote:
On 12/3/20 6:27 PM, Tom Stellard wrote:
However, in the discussion on the mailing list for this change, not everyone agreed that cmake should Require make and this point was never resolved. So, since there is still ambiguity here, I am planning to do the safest option, which is to add BuildRequires: make even for packages that use %cmake_build and do not invoke make directly.
For what's it worth I think that packages that only use make via cmake should not have an explcit dependency on make. Packages that use make directly should have an explicit dependency on make (even if they already BR cmake).
OK, so is it safe to assume then that the cmake package will always Require either make or ninja?
-Tom
On 12/4/20 5:51 PM, Tom Stellard wrote:
On 12/4/20 4:55 AM, Miro Hrončok wrote:
On 12/3/20 6:27 PM, Tom Stellard wrote:
However, in the discussion on the mailing list for this change, not everyone agreed that cmake should Require make and this point was never resolved. So, since there is still ambiguity here, I am planning to do the safest option, which is to add BuildRequires: make even for packages that use %cmake_build and do not invoke make directly.
For what's it worth I think that packages that only use make via cmake should not have an explcit dependency on make. Packages that use make directly should have an explicit dependency on make (even if they already BR cmake).
OK, so is it safe to assume then that the cmake package will always Require either make or ninja?
No. But it's safe to assume it will always require either make or ninja as long as it invokes make or ninja.
Packages only running "cmake" -> assume all cmake deps are present and don't think whether it is make or not.
Packages running "cmake" and "make" -> declare make as BR and don't assume it will be required by cmake forever.
On Thu, Dec 3, 2020 at 3:39 PM Fabio Valentini decathorpe@gmail.com wrote:
I still think a lot of those are "false positives". CMake has a hard Requires on make, so if I BuildRequires cmake, adding "BuildRequires: make" is just redundant. https://src.fedoraproject.org/rpms/cmake/blob/master/f/cmake.spec#_185
I think this was discussed previously, but while cmake may have a requires on make today, cmake can now use ninja rather than make in at least some cases, so one should certainly not presume cmake will always require make. If the build requires make, it should call it out explicitly.
On 03/12/2020 16:21, Gary Buhrmaster wrote:
On Thu, Dec 3, 2020 at 3:39 PM Fabio Valentini decathorpe@gmail.com wrote:
I still think a lot of those are "false positives". CMake has a hard Requires on make, so if I BuildRequires cmake, adding "BuildRequires: make" is just redundant. https://src.fedoraproject.org/rpms/cmake/blob/master/f/cmake.spec#_185
I think this was discussed previously, but while cmake may have a requires on make today, cmake can now use ninja rather than make in at least some cases, so one should certainly not presume cmake will always require make. If the build requires make, it should call it out explicitly.
Yes, if it actually calls make it should require it.
If it calls cmake and leaves cmake to decide what backend to call then it should just require cmake and cmake should require it's chosen backend.
But as I say this is just going round in circles and I'm giving up trying to explain this now.
Tom
On Thu, Dec 3, 2020 at 10:22 AM Gary Buhrmaster gary.buhrmaster@gmail.com wrote:
On Thu, Dec 3, 2020 at 3:39 PM Fabio Valentini decathorpe@gmail.com wrote:
I still think a lot of those are "false positives". CMake has a hard Requires on make, so if I BuildRequires cmake, adding "BuildRequires: make" is just redundant. https://src.fedoraproject.org/rpms/cmake/blob/master/f/cmake.spec#_185
I think this was discussed previously, but while cmake may have a requires on make today, cmake can now use ninja rather than make in at least some cases, so one should certainly not presume cmake will always require make. If the build requires make, it should call it out explicitly.
I think here is a RARE instance we disagree :)
Presumably everyone is using the %cmake / %cmake_build / %cmake_install macros. If so and the current default for cmake is to use make, and cmake has a hard dep on make, then why add the extra BR?
If the *default* is changed to ninja at some point I would expect for cmake to have a hard dep on ninja.
If you're not using the macros or overriding the default then you're already on your own and should BR make or ninja (or whatever) anyway.
Thanks, Richard
devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-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/devel@lists.fedoraproject.org
On 11/30/20 2:06 PM, Tom Stellard wrote:
Hi,
As part of the f34 change request[1] for removing make from the buildroot, I will be doing a mass update of packages[2] to add BuildRequires: make where it is needed.
If you are a package maintainer and would prefer to update your packages on your own, please do so before Dec 14, which is when I will begin doing the mass update.
Hi,
Thanks for all the feedback. It seems like there is consensus now that packages that use %cmake_build and %cmake_install but never invoke make directly should not have to BuildRequire: make, so I've updated my scripts to ignore those packages.
I have also eliminated some (but not all) of the false positives that have been reported on the list. I'm still working on getting rid of the rest of them.
I've updated the package list now[2] to reflect the %cmake_build change, and I will continue to update this at least once per day to account for package updates in Fedora.
There is still a week left before I start the updates, so please continue to give feedback.
Thanks, Tom
I will be doing the updates in batches, so that if there is a mistake the impact will be limited. Here is the rough schedule of the changes:
Dec 14: Update first 50 packages. Dec 16: Next 1000. Dec 18: Next 1000. Jan 4: Next 1000. Jan 5: Next 1000. Jan 6: Next 1000. Jan 7: Next 1000. Jan 8: Rest of packages.
The deadline for completing these updates is the start of the f34 mass rebuild (Jan 20).
Thanks, Tom
[1] https://fedoraproject.org/wiki/Changes/Remove_make_from_BuildRoot [2] https://fedorapeople.org/~tstellar/needs_br_make_packages.txt
On 12/7/20 7:18 PM, Tom Stellard wrote:
I've updated the package list now[2] to reflect the %cmake_build change,
I see for example libsavitar on the list.
https://src.fedoraproject.org/rpms/libsavitar/blob/master/f/libsavitar.spec
It only uses %cmake_... macros.
Was it indeed updated correctly?
On 12/7/20 10:33 AM, Miro Hrončok wrote:
On 12/7/20 7:18 PM, Tom Stellard wrote:
I've updated the package list now[2] to reflect the %cmake_build change,
I see for example libsavitar on the list.
https://src.fedoraproject.org/rpms/libsavitar/blob/master/f/libsavitar.spec
It only uses %cmake_... macros.
Was it indeed updated correctly?
I just fixed this now. I had pushed the wrong list earlier today.
-Tom
On 12/7/20 7:33 PM, Miro Hrončok wrote:
On 12/7/20 7:18 PM, Tom Stellard wrote:
I've updated the package list now[2] to reflect the %cmake_build change,
I see for example libsavitar on the list.
https://src.fedoraproject.org/rpms/libsavitar/blob/master/f/libsavitar.spec
It only uses %cmake_... macros.
Was it indeed updated correctly?
Now it was. Thanks.
On 07.12.2020 19:18, Tom Stellard wrote:
I have also eliminated some (but not all) of the false positives that have been reported on the list. I'm still working on getting rid of the rest of them.
Please check the purple-plugin_pack package. It uses the meson build system.
Hi Tom,
Tom Stellard tstellar@redhat.com writes:
On 11/30/20 2:06 PM, Tom Stellard wrote:
Hi,
As part of the f34 change request[1] for removing make from the buildroot, I will be doing a mass update of packages[2] to add BuildRequires: make where it is needed.
If you are a package maintainer and would prefer to update your packages on your own, please do so before Dec 14, which is when I will begin doing the mass update.
Hi,
Thanks for all the feedback. It seems like there is consensus now that packages that use %cmake_build and %cmake_install but never invoke make directly should not have to BuildRequire: make, so I've updated my scripts to ignore those packages.
I have also eliminated some (but not all) of the false positives that have been reported on the list. I'm still working on getting rid of the rest of them.
I've updated the package list now[2] to reflect the %cmake_build change, and I will continue to update this at least once per day to account for package updates in Fedora.
There is still a week left before I start the updates, so please continue to give feedback.
i3 now uses meson and no longer requires make. Also, I've fixed python-breathe myself today (so it's most likely not yet included).
Cheers,
Dan
On 11/30/20 2:06 PM, Tom Stellard wrote:
Hi,
As part of the f34 change request[1] for removing make from the buildroot, I will be doing a mass update of packages[2] to add BuildRequires: make where it is needed.
If you are a package maintainer and would prefer to update your packages on your own, please do so before Dec 14, which is when I will begin doing the mass update.
I will be doing the updates in batches, so that if there is a mistake the impact will be limited. Here is the rough schedule of the changes:
Dec 14: Update first 50 packages.
The 50 packages I'll update on Dec. 14 are listed here:
https://fedorapeople.org/~tstellar/br_make_day1.txt
-Tom
Dec 16: Next 1000. Dec 18: Next 1000. Jan 4: Next 1000. Jan 5: Next 1000. Jan 6: Next 1000. Jan 7: Next 1000. Jan 8: Rest of packages.
The deadline for completing these updates is the start of the f34 mass rebuild (Jan 20).
Thanks, Tom
[1] https://fedoraproject.org/wiki/Changes/Remove_make_from_BuildRoot [2] https://fedorapeople.org/~tstellar/needs_br_make_packages.txt
Hi!
On Saturday, 12 December 2020 at 08:24, Tom Stellard wrote: [...]
The 50 packages I'll update on Dec. 14 are listed here:
abcde abook
fixed, you can drop them from your list.
Regards, Dominik
On 11/30/20 2:06 PM, Tom Stellard wrote:
Hi,
As part of the f34 change request[1] for removing make from the buildroot, I will be doing a mass update of packages[2] to add BuildRequires: make where it is needed.
If you are a package maintainer and would prefer to update your packages on your own, please do so before Dec 14, which is when I will begin doing the mass update.
I will be doing the updates in batches, so that if there is a mistake the impact will be limited. Here is the rough schedule of the changes:
Dec 14: Update first 50 packages. Dec 16: Next 1000.
Here is the list of packages for Dec 16: https://fedorapeople.org/~tstellar/br_make_day2.txt
-Tom
Dec 18: Next 1000. Jan 4: Next 1000. Jan 5: Next 1000. Jan 6: Next 1000. Jan 7: Next 1000. Jan 8: Rest of packages.
The deadline for completing these updates is the start of the f34 mass rebuild (Jan 20).
Thanks, Tom
[1] https://fedoraproject.org/wiki/Changes/Remove_make_from_BuildRoot [2] https://fedorapeople.org/~tstellar/needs_br_make_packages.txt
On Wednesday, December 16, 2020 8:01:23 AM WET Tom Stellard wrote:
Here is the list of packages for Dec 16: https://fedorapeople.org/~tstellar/br_make_day2.txt
-Tom
Hi Tom, I have two packages in your list: armadillo and emacs-common-ess.
My issue is with armadillo that it has BuildRequires cmake. So I think that in this case the BuildRequires make does not make sense.
Bellow I am speculating. :-) Assuming that the check was done using a script (the only sane way to do it), cmake requirement line appears as:
BuildRequires: cmake, lapack-devel, arpack-devel
so if the script searches for cmake as the only element it will fail.
Best regards,
On 12/16/20 12:51 AM, José Abílio Matos wrote:
On Wednesday, December 16, 2020 8:01:23 AM WET Tom Stellard wrote:
Here is the list of packages for Dec 16:
-Tom
Hi Tom,
I have two packages in your list: armadillo and emacs-common-ess.
My issue is with armadillo that it has BuildRequires cmake. So I think that in this case the BuildRequires make does not make sense.
I'm only excluding packages that invoke make through the %cmake_build or %cmake_install macros. armadillo invokes make directly, which is why it is on the list.
-Tom
Bellow I am speculating. :-)
Assuming that the check was done using a script (the only sane way to do it), cmake requirement line appears as:
BuildRequires: cmake, lapack-devel, arpack-devel
so if the script searches for cmake as the only element it will fail.
Best regards,
--
José Abílio
On Wednesday, December 16, 2020 3:51:16 PM WET Tom Stellard wrote:
I'm only excluding packages that invoke make through the %cmake_build or %cmake_install macros. armadillo invokes make directly, which is why it is on the list.
-Tom
You are right, in the %check section.
OK I have added make as an explicit BR to armadillo and emacs-common-ess.
Thank you. :-)
On 11/30/20 2:06 PM, Tom Stellard wrote:
Hi,
As part of the f34 change request[1] for removing make from the buildroot, I will be doing a mass update of packages[2] to add BuildRequires: make where it is needed.
If you are a package maintainer and would prefer to update your packages on your own, please do so before Dec 14, which is when I will begin doing the mass update.
I will be doing the updates in batches, so that if there is a mistake the impact will be limited. Here is the rough schedule of the changes:
Dec 14: Update first 50 packages. Dec 16: Next 1000. Dec 18: Next 1000.
Were are the packages I'll be updating today: https://fedorapeople.org/~tstellar/br_make_day3.txt
-Tom
Jan 4: Next 1000. Jan 5: Next 1000. Jan 6: Next 1000. Jan 7: Next 1000. Jan 8: Rest of packages.
The deadline for completing these updates is the start of the f34 mass rebuild (Jan 20).
Thanks, Tom
[1] https://fedoraproject.org/wiki/Changes/Remove_make_from_BuildRoot [2] https://fedorapeople.org/~tstellar/needs_br_make_packages.txt
On 11/30/20 2:06 PM, Tom Stellard wrote:
Hi,
As part of the f34 change request[1] for removing make from the buildroot, I will be doing a mass update of packages[2] to add BuildRequires: make where it is needed.
If you are a package maintainer and would prefer to update your packages on your own, please do so before Dec 14, which is when I will begin doing the mass update.
I will be doing the updates in batches, so that if there is a mistake the impact will be limited. Here is the rough schedule of the changes:
Dec 14: Update first 50 packages. Dec 16: Next 1000. Dec 18: Next 1000. Jan 4: Next 1000.
Here are the list of packages that will be updated today:
https://fedorapeople.org/~tstellar/br_make_day4.txt
-Tom
Jan 5: Next 1000. Jan 6: Next 1000. Jan 7: Next 1000. Jan 8: Rest of packages.
The deadline for completing these updates is the start of the f34 mass rebuild (Jan 20).
Thanks, Tom
[1] https://fedoraproject.org/wiki/Changes/Remove_make_from_BuildRoot [2] https://fedorapeople.org/~tstellar/needs_br_make_packages.txt
On 11/30/20 2:06 PM, Tom Stellard wrote:
Hi,
As part of the f34 change request[1] for removing make from the buildroot, I will be doing a mass update of packages[2] to add BuildRequires: make where it is needed.
If you are a package maintainer and would prefer to update your packages on your own, please do so before Dec 14, which is when I will begin doing the mass update.
I will be doing the updates in batches, so that if there is a mistake the impact will be limited. Here is the rough schedule of the changes:
Dec 14: Update first 50 packages. Dec 16: Next 1000. Dec 18: Next 1000. Jan 4: Next 1000. Jan 5: Next 1000.
Here is the list of packages I'll be updating today:
https://fedorapeople.org/~tstellar/br_make_day5.txt
-Tom
Jan 6: Next 1000. Jan 7: Next 1000. Jan 8: Rest of packages.
The deadline for completing these updates is the start of the f34 mass rebuild (Jan 20).
Thanks, Tom
[1] https://fedoraproject.org/wiki/Changes/Remove_make_from_BuildRoot [2] https://fedorapeople.org/~tstellar/needs_br_make_packages.txt
On 1/5/21 6:58 AM, Tom Stellard wrote:
On 11/30/20 2:06 PM, Tom Stellard wrote:
Hi,
As part of the f34 change request[1] for removing make from the buildroot, I will be doing a mass update of packages[2] to add BuildRequires: make where it is needed.
If you are a package maintainer and would prefer to update your packages on your own, please do so before Dec 14, which is when I will begin doing the mass update.
I will be doing the updates in batches, so that if there is a mistake the impact will be limited. Here is the rough schedule of the changes:
Dec 14: Update first 50 packages. Dec 16: Next 1000. Dec 18: Next 1000. Jan 4: Next 1000. Jan 5: Next 1000.
Here is the list of packages I'll be updating today:
There were some issues reported with my update script, so I'm going to take the day to test some changes rather than doing a mass update. The problems that were reported are BuildRequires: make being added to sub-packages and also inside of multi-line conditions like:
%{?enablefeature: BuildRequires: foo }
The main change I'm going to be making is to insert BuildRequires: make before the first BuildRequires in the file instead of after the last. This should avoid the issue with sub-packages and should also reduce the number of manual changes I need to make. Currently, if the script sees %endif anywhere near where BuildRequires: make was inserted, it will skip making the change, and these conditionals seem to occur more frequently at the end of the BuildRequires list than at the beginning.
-Tom
-Tom
Jan 6: Next 1000. Jan 7: Next 1000. Jan 8: Rest of packages.
The deadline for completing these updates is the start of the f34 mass rebuild (Jan 20).
Thanks, Tom
[1] https://fedoraproject.org/wiki/Changes/Remove_make_from_BuildRoot [2] https://fedorapeople.org/~tstellar/needs_br_make_packages.txt
On 11/30/20 2:06 PM, Tom Stellard wrote:
Hi,
As part of the f34 change request[1] for removing make from the buildroot, I will be doing a mass update of packages[2] to add BuildRequires: make where it is needed.
If you are a package maintainer and would prefer to update your packages on your own, please do so before Dec 14, which is when I will begin doing the mass update.
I will be doing the updates in batches, so that if there is a mistake the impact will be limited. Here is the rough schedule of the changes:
Dec 14: Update first 50 packages. Dec 16: Next 1000. Dec 18: Next 1000. Jan 4: Next 1000. Jan 5: Next 1000. Jan 6: Next 1000.
Here is the list of packages I'll be updating today:
https://fedorapeople.org/~tstellar/br_make_day6.txt
-Tom
Jan 7: Next 1000. Jan 8: Rest of packages.
The deadline for completing these updates is the start of the f34 mass rebuild (Jan 20).
Thanks, Tom
[1] https://fedoraproject.org/wiki/Changes/Remove_make_from_BuildRoot [2] https://fedorapeople.org/~tstellar/needs_br_make_packages.txt
On 11/30/20 2:06 PM, Tom Stellard wrote:
Hi,
As part of the f34 change request[1] for removing make from the buildroot, I will be doing a mass update of packages[2] to add BuildRequires: make where it is needed.
If you are a package maintainer and would prefer to update your packages on your own, please do so before Dec 14, which is when I will begin doing the mass update.
I will be doing the updates in batches, so that if there is a mistake the impact will be limited. Here is the rough schedule of the changes:
Dec 14: Update first 50 packages. Dec 16: Next 1000. Dec 18: Next 1000. Jan 4: Next 1000. Jan 5: Next 1000. Jan 6: Next 1000. Jan 7: Next 1000.
Here are the packages I'll be updating on Thursday:
https://fedorapeople.org/~tstellar/br_make_day7.txt
-Tom
Jan 8: Rest of packages.
The deadline for completing these updates is the start of the f34 mass rebuild (Jan 20).
Thanks, Tom
[1] https://fedoraproject.org/wiki/Changes/Remove_make_from_BuildRoot [2] https://fedorapeople.org/~tstellar/needs_br_make_packages.txt
On 11/30/20 2:06 PM, Tom Stellard wrote:
Hi,
As part of the f34 change request[1] for removing make from the buildroot, I will be doing a mass update of packages[2] to add BuildRequires: make where it is needed.
If you are a package maintainer and would prefer to update your packages on your own, please do so before Dec 14, which is when I will begin doing the mass update.
I will be doing the updates in batches, so that if there is a mistake the impact will be limited. Here is the rough schedule of the changes:
Dec 14: Update first 50 packages. Dec 16: Next 1000. Dec 18: Next 1000. Jan 4: Next 1000. Jan 5: Next 1000. Jan 6: Next 1000. Jan 7: Next 1000. Jan 8: Rest of packages.
Here are the packages I will be updating today: https://fedorapeople.org/~tstellar/br_make_day7.txt
-Tom
The deadline for completing these updates is the start of the f34 mass rebuild (Jan 20).
Thanks, Tom
[1] https://fedoraproject.org/wiki/Changes/Remove_make_from_BuildRoot [2] https://fedorapeople.org/~tstellar/needs_br_make_packages.txt
devel@lists.stg.fedoraproject.org
-
Artem Tim -
Christoph Junghans -
Dan Čermák -
Dominik 'Rathann' Mierzejewski -
Fabio Valentini -
Gary Buhrmaster -
Ian McInerney -
Iñaki Ucar -
Jakub Jelinek -
Jerry James -
José Abílio Matos -
Mark Wielaard -
Michael Cronenworth -
Miro Hrončok -
Miroslav Suchý -
Panu Matilainen -
Pavel Raiskup -
Petr Šabata -
Remi Collet -
Richard Shaw -
Stephen John Smoogen -
Tom Hughes -
Tom Stellard -
Vitaly Zaitsev -
Vít Ondruch -
ycollette.nospam＠free.fr -
Zbigniew Jędrzejewski-Szmek