Description of problem: In review.txt sh: /usr/bin/python: No such file or directory 1 packages and 0 specfiles checked; 0 errors, 0 warnings. Version-Release number of selected component (if applicable): 0.6.0 How reproducible: Always Steps to Reproduce: 1. fedora-review -v xxx 2. 3. Actual results: sh: /usr/bin/python: No such file or directory Expected results: rpmlint executed on built packages Additional info:
This is with fedora-review-0.5.3-1.fc21.noarch
This is a bug in rpmlint (pulls in /usr/bin/python3 but requires /usr/bin/python)
(In reply to Stanislav Ochotnicky from comment #2) > This is a bug in rpmlint (pulls in /usr/bin/python3 but requires > /usr/bin/python) Need more details. $ rpm -qRp http://dl.fedoraproject.org/pub/fedora/linux/updates/testing/21/x86_64/r/rpmlint-1.7-1.fc21.noarch.rpm | grep bin/python /usr/bin/python No /usr/bin/python3 there, just /usr/bin/python. $ wget http://dl.fedoraproject.org/pub/fedora/linux/updates/testing/21/x86_64/r/rpmlint-1.7-1.fc21.noarch.rpm $ rpmdev-extract rpmlint-1.7-1.fc21.noarch.rpm $ grep -rF bin/python rpmlint-1.7-1.fc21.noarch rpmlint-1.7-1.fc21.noarch/usr/share/rpmlint/config: "/usr/bin/python", rpmlint-1.7-1.fc21.noarch/usr/share/doc/rpmlint/ChangeLog: [A-Z]*.py Unknown option: - usage: /usr/bin/python [option] ... [-c rpmlint-1.7-1.fc21.noarch/usr/bin/rpmdiff:#!/usr/bin/python -tt rpmlint-1.7-1.fc21.noarch/usr/bin/rpmlint:#!/usr/bin/python -ttOu No python3 there either, just /usr/bin/python. The F-23 package is similarly consistent, it requires and uses /usr/bin/python3.
This is in F23 (rawhide), not F21 version: http://koji.fedoraproject.org/koji/rpminfo?rpmID=6535868
(In reply to Stanislav Ochotnicky from comment #4) > This is in F23 (rawhide), not F21 version: Well, this bug is reported against F21. > http://koji.fedoraproject.org/koji/rpminfo?rpmID=6535868 And as I said at end of comment 3 the F23/rawhide package seems consistent to me: it has a dependency on python3 (and /usr/bin/python3) and uses /usr/bin/python3 in shebangs so I still don't get what the problem is, the details I requested are still needed...
Nevermind, must be something else. Initial report said version 0.6.0 of FR which doesn't exist in F21 and then it was just confusing...
Notice, I report this issue against fedora-review, not rpmlint. Yes, rpmlint seems ok. But fedora-review (seems to) run its local rpmlint version (which use python) in the rawhide buildroot where python is not available. The error is only in "Rpmlint (installed packages)" (classic "Rpmlint" is ok).
This message is a reminder that Fedora 21 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 21. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '21'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 21 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
There is a reproducer (without fedora-review) in [1]. The error message is there, but rpmlint seems to run OK anyway (?) [1] https://bugzilla.redhat.com/show_bug.cgi?id=1253917#c4
Ok, reproduced, this originates from the rpm.expandMacro("%python_sitearch") call in rpmlint's TagsCheck, here's an even smaller reproducer without even rpmlint installed: <mock-chroot>sh-4.3# python3 >>> import rpm >>> rpm.expandMacro("%python_sitearch") sh: /usr/bin/python: No such file or directory '' I don't think it would be a good idea to have rpmlint or rpm pull in /usr/bin/python just for this. It's just a message, and doesn't cause anything to fail. Not sure if it would be possible to tell rpm's python bindings to be quiet about this...?
Seems that this bug belongs to rpm. However, I'm either to dumb or just not allowed to change the component. Could someone please...
I can, so here it is :)
FWIW, I don't think this necessarily belongs anywhere, maybe it should just be closed as NOTABUG.
Fedora 21 changed to end-of-life (EOL) status on 2015-12-01. Fedora 21 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.
Hello, (In reply to Ville Skyttä from comment #10) > Ok, reproduced, this originates from the rpm.expandMacro("%python_sitearch") > call in rpmlint's TagsCheck, here's an even smaller reproducer without even > rpmlint installed: > > <mock-chroot>sh-4.3# python3 > >>> import rpm > >>> rpm.expandMacro("%python_sitearch") > sh: /usr/bin/python: No such file or directory > '' > > I don't think it would be a good idea to have rpmlint or rpm pull in > /usr/bin/python just for this. It's just a message, and doesn't cause > anything to fail. Not sure if it would be possible to tell rpm's python > bindings to be quiet about this...? IMO this is a bug and we should find a solution, we have this situation when we use fedora-review in a package that not use python ! , but feel free to close this bug . So : rpm.expandMacro("%python_sitearch") sh: /usr/bin/python: No such file or directory exploring this: cd /usr/lib/rpm/ grep python_sitearch * macros:%python_sitearch %(%{__python} -c "from distutils.sysconfig import get_python_lib; import sys; sys.stdout.write(get_python_lib(1))") and >>> rpm.expandMacro("%{__python}") '/usr/bin/python' So the error happens when running : /usr/bin/python -c "from distutils.sysconfig import get_python_lib; import sys; sys.stdout.write(get_python_lib(1))" In /usr/lib/rpm/macros definition of %python_sitearch should not drop errors when we don't have /usr/bin/python installed or fedora-review shouldn't use %python_sitearch or fedora-review shouldn't use %python_sitearch without install python2 , I don't know . Since file /usr/lib/rpm/macros is part of rpm package [1] the bug component still in rpm. [1] rpm -qf /usr/lib/rpm/macros rpm-4.13.0-0.rc1.7.fc23.x86_64
(In reply to Sergio Monteiro Basto from comment #15) > Since file /usr/lib/rpm/macros is part of rpm package [1] the bug component > still in rpm. The situation is also same for example for %perl_sitearch, %__scm_setup_hg, %__scm_setup_git, and %__scm_apply_bzr to name a few macros from /usr/lib/rpm/macros. It would not make sense to have the rpm package have dependencies on perl, git, mercurial, and bzr just because of this. While pulling in python is not that prominent problem yet, it will become more and more so as more stuff moves from python 2 to 3. NOTABUG is a better resolution to this than adding those deps. There might be some other resolutions if for example someone wants to start splitting those macros away from the rpm package, but that's probably a can of worms of its own.
And what about define python with something like this [1] ? [1] %__python %(if [ -f /usr/bin/python ]; then echo "/usr/bin/python"; else echo ":"; fi)
*** Bug 1297448 has been marked as a duplicate of this bug. ***
In /usr/lib/rpm/macros, we can or should test the definitions and we may also not hide the problem. If we can define a function, we may could have one function to test the existent of command and define something like this: %__python %(if [ -f /usr/bin/python ]; then echo "/usr/bin/python"; else echo ">&2 echo system dont have /usr/bin/python "; fi)
The problem is not hidden; the current error message output by the shell is "sh: /usr/bin/python: No such file or directory". I don't think the suggestion in comment 19 adds any value, it just adds some code and complexity.
(In reply to Ville Skyttä from comment #20) > The problem is not hidden; the current error message output by the shell is > "sh: /usr/bin/python: No such file or directory". I don't think the > suggestion in comment 19 adds any value, it just adds some code and > complexity. yes , Suggestion 1 (hide the problem) : %__python %(if [ -f /usr/bin/python ]; then echo "/usr/bin/python"; else echo ":"; fi) Suggestion 2 (explain the problem) : %__python %(if [ -f /usr/bin/python ]; then echo "/usr/bin/python"; else echo ">&2 echo system dont have /usr/bin/python "; fi) This problem appears for example with this top 5 lines in mlt.spec [1] %{!?ruby_sitelib: %global ruby_sitelib %(ruby -rrbconfig -e 'puts RbConfig::CONFIG["sitelibdir"] ')} %{!?ruby_sitearch: %global ruby_sitearch %(ruby -rrbconfig -e 'puts RbConfig::CONFIG["sitearchdir"] ')} %{!?python_sitelib: %global python_sitelib %(%{__python} -c "from distutils.sysconfig import get_python_lib; print get_python_lib()")} %{!?python_sitearch: %global python_sitearch %(%{__python} -c "from distutils.sysconfig import get_python_lib; print get_python_lib(1)")} %global php_extdir %(php-config --extension-dir 2>/dev/null || echo "undefined") [1] https://github.com/rpmfusion/mlt/blob/master/mlt.spec
I really fail to see the point of both those suggestions. 1) If there's a problem, why hide it at that level, where we don't know how serious the lack of the executable/macro is? Just makes things harder to debug. 2) Equivalent to current behavior, just different (worse IMO) error message. Note that the title of this bug is misleading, rpmlint does not fail. This is just some output in stderr.
(In reply to Ville Skyttä from comment #22) Ville , First, this report is about, output messages like "sh: /usr/bin/python: No such file or directory" when we run rpmlint (in a chroot), moreover running : mock -r fedora-23-x86_64 --rebuild foo.src.rpm we see lots of strange messages like "/usr/bin/python: No such file or directory" So we discover that rpm macros sometimes try run commands that not exist in environment, in #c10 you wrote that rpmlint shouldn't pull python and remember in that perceptive, should also pull perl, ruby and a lot of other packages . But we should do something, in the middle of a mock build or in an rpmlint , shouldn't appear messages like "/usr/bin/python: No such file or directory" So my suggestion is: when we are defining commands like python, in /lib/rpm/macros, we should check if python exist in environment and if not, what we should do ? hide the problem ? explain the problem ? etc.
I understand the problem and your suggestions, and I think I have already made it clear that I disagree with them, and I've explained my reasoning. I do however agree that it would be nice to get rid of those messages in some sane way, but I don't think any sane ways have been suggested yet. I don't have such suggestions either, nor time or interest to spend on trying to come up with them.
The right solution would probably to move the macros into either the python-macros or the python-devel package respectively /usr/lib/rpm/macros.d/macros.python or /usr/lib/rpm/macros.d/macros.python2 Moving to python for now. Please bounce the bug back to rpm when the macros can be removed from the rpm package.
hey, the problem is not just with python, it is with: ruby , perl, git etc please read #c16
Hi, Add some new elements , finally I understood what I'm looking for . Description of problem: Running commands like mock, rpmdev-bumpspec, fedora-review , rpmlint appears strange messages like : sh: /usr/bin/python: No such file or directory Other example is : rpmdev-bumpspec -c "Update to 0.22" ufraw.spec sh: /usr/bin/gimptool-2.0: No such file or directory but is just a message to stderr, not prevent anything to run normally , although we might think that we have a serious problem (when we don't). And why this happens ? when rpm try resolve definitions of globals, some calculations fails (when commands are not available) and we got messages to stderr. in ufraw.spec we got this: %global gimptool %{_bindir}/gimptool-2.0 %global gimpplugindir %(%gimptool --gimpplugindir)/plug-ins The syntax of spec "%()" lets us run almost all we want, but if system or chroot , don't have that command, it will output messages to stderr and at most not calculate well the variable. So the problem are in definitions of global in the .spec files. Another example, running: mock --rebuild ./mlt-6.0.0-1.fc23.src.rpm (...) Start: build setup for mlt-6.0.0-1.fc23.src.rpm sh: ruby: command not found sh: ruby: command not found sh: /usr/bin/python: No such file or directory sh: /usr/bin/python: No such file or directory sh: /usr/bin/python: No such file or directory sh: /usr/bin/python: No such file or directory (...) Assuming we want to suppress these messages, the correct way, IMO, is this .spec requires install ruby and python before we starting query the .spec. So SpecRequires: ruby-devel python-devel Other way is somehow send stderr of calculation of global variables to other file descriptor ... Anyway I think the bug should be assign back to rpm component . Hope that helps something. Best regards.
I found that most of scriptlets in head of spec files are obsolete and should be removed. I mean, we should remove from spec files things like : %{!?ruby_sitelib: %global ruby_sitelib %(ruby -rrbconfig -e 'puts RbConfig::CONFIG["sitelibdir"] ')} %{!?ruby_sitearch: %global ruby_sitearch %(ruby -rrbconfig -e 'puts RbConfig::CONFIG["sitearchdir"] ')} %{!?python_sitelib: %global python_sitelib %(%{__python} -c "from distutils.sysconfig import get_python_lib; print get_python_lib()")} %{!?python_sitearch: %global python_sitearch %(%{__python} -c "from distutils.sysconfig import get_python_lib; print get_python_lib(1)")} %global php_extdir %(php-config --extension-dir 2>/dev/null || echo "undefined") Instead we should use predefined macros, for example %{python2_sitelib} and %{ruby_vendorarchdir} that are recommended by package guidelines: https://fedoraproject.org/wiki/Packaging:Python https://fedoraproject.org/wiki/Packaging:Ruby https://fedoraproject.org/wiki/Packaging:PHP Conclusion, removing this obsolete scriptlets solved almost all cases of this bug, in others words, this obsolete scriptlets cause this kind of messages.
This message is a reminder that Fedora 23 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 23. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '23'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 23 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
(In reply to Florian Festi from comment #25) > The right solution would probably to move the macros into either the > python-macros or the python-devel package respectively > /usr/lib/rpm/macros.d/macros.python or /usr/lib/rpm/macros.d/macros.python2 > > Moving to python for now. Please bounce the bug back to rpm when the macros > can be removed from the rpm package. > Component: rpm → python This bug is not in python but more in rpm tools like spectool, rpmdev-bumpspec and rpmlint running these commands generate some warning messages , that not affect the functionally, but confuse the user. Like I wrote in https://bugzilla.redhat.com/show_bug.cgi?id=1243292#c27 Description of problem: Running commands like mock, rpmdev-bumpspec, fedora-review , rpmlint appears strange messages like : sh: /usr/bin/python: No such file or directory
Fedora 23 changed to end-of-life (EOL) status on 2016-12-20. Fedora 23 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.
Not sure why this got reassigned to me and rpmdevtools; I think I've made my position about this clear in comment 24.
Hi, (In reply to Ville Skyttä from comment #24) > I do however agree that it would be nice to get rid of those messages in some > sane way, but I don't think any sane ways have been suggested yet. I don't > have such suggestions either, nor time or interest to spend on trying to > come up with them. OK , you agree that would be nice to get rid of those messages, some of those messages come from spectool and rpmdev-bumpspec , if we fix there maybe we can fix in other places like fedora-review and mock, so I'd like keep this bug open until we have a solution, be assign to python didn't make sense so I reassign to rpmdevtools ...
Sergio, playing ping-pong with a ticket by reassigning it once more does not lead to anything. rpmdev-bumpspec clearly isn't wrong in any way, for example. Discarding stderr output (or any other output when executing "rpm") would be the wrong thing to do. The environment that executes rpmdev-bumpspec would need to make sure a spec file's BuildRequires are all satisfied. If not, there can be warnings about many others missing programs run within RPM macros.
While I fully respect minimization efforts, this is clear bug in RPM which provides (e.g.) broken %python_sitelib macro (or %perl_sitelib, etc.) because no 'Requires: perl python' is in rpm.spec .. Doing %(..whatever..) in system RPM macros _is_ wrong _unless_ there's guaranteed '..whatever..' will work in minimal buildroot. I understand that we do not want to have python/perl/other_big_thing in rpm's Requires or by default in minimal buildroot -- but tell me why we don't have statically set %python_sitelib in system macros (e.g. generated at build-time). If we can not generate '%python_sitelib' during _rpm_ build-time (because we can't have BuildRequries: python there), feel free to move %python_sitelib out from 'rpm' package and put it into (for example) 'python-rpm-macros' (and install this package into minimal buildroot).
(In reply to Ville Skyttä from comment #24) Also , there is no point in close this bug and open a new one with new examples for the same problem . Runing rpmdev-bumpspec with a spec with %autosetup will produce one error message for each patch defined , but rpmdev-bumpspec works, for example ufraw.spec [1]: rpmdev-bumpspec ufraw.spec sh: /usr/bin/gimptool-2.0: No such file or directory error: File /home/sergio/rpmbuild/SOURCES /05_fix_build_due_to_unsigned_char.patch: No such file or directory error: File /home/sergio/rpmbuild/SOURCES/ufraw-0.22-multipliers.patch: No such file or directory error: File /home/sergio/rpmbuild/SOURCES/ufraw-0.22-find_green.patch: No such file or directory error: File /home/sergio/rpmbuild/SOURCES/ufraw-0.22-lf-destroy.patch: No such file or directory and also rpmlint BTW rpmlint /var/lib/mock/backup/fedora-23-x86_64/ufraw-0.22-3.fc23.src.rpm (...) sh: /usr/bin/gimptool-2.0: No such file or directory error: File /home/sergio/rpmbuild/SOURCES/05_fix_build_due_to_unsigned_char.patch: No such file or directory error: File /home/sergio/rpmbuild/SOURCES/ufraw-0.22-multipliers.patch: No such file or directory error: File /home/sergio/rpmbuild/SOURCES/ufraw-0.22-find_green.patch: No such file or directory 1 packages and 0 specfiles checked; 0 errors, 1 warnings. [1] https://src.fedoraproject.org/cgit/rpms/ufraw.git/tree/ufraw.spec
> Runing rpmdev-bumpspec with a spec with %autosetup will produce one > error message for each patch defined Cannot reproduce: $ rpmdev-bumpspec -V ufraw.spec ufraw.spec -4%{?dist} +5%{?dist} sh: /usr/bin/gimptool-2.0: No such file or directory $ Why would "rpm" not find the patch files in %_sourcedir, if you've extracted the src.rpm properly? But once more, _any_ RPM macros may lead to output depending on what is available in the buildroot. It is nothing to work around in rpmdev-bumpspec.
I use: fedpkg clone ufraw; cd ufraw; fedpkg srpm , I don't extract src.rpm, I create src.rpm to build in mock as test. I may need bump a release or do something and I tested rpmlint on one result of mock build . (In reply to Michael Schwendt from comment #38) > But once more, _any_ RPM macros may lead to output depending on what is > available in the buildroot. yes > It is nothing to work around in rpmdev-bumpspec. and rpmdev-bumpspec or rpmlint may output erroneous messages ? (In reply to Michael Schwendt from comment #34) > rpmdev-bumpspec clearly isn't wrong in any way, for example. Discarding > stderr output (or any other output when executing "rpm") would be the wrong > thing to do. The environment that executes rpmdev-bumpspec would need to > make sure a spec file's BuildRequires are all satisfied. If not, there can > be warnings about many others missing programs run within RPM macros. I don't know and I believe in you but note this report begin with one tentative of understand erroneous messages that appears in Fedora review, this also happens in mock. I think this is not an minor issue because, for example, many erroneous messages appears in mock builds and we should avoid that. Cheers.
(In reply to Sergio Monteiro Basto from comment #39) > I use: fedpkg clone ufraw; cd ufraw; fedpkg srpm , I don't extract src.rpm, > I create src.rpm to build in mock as test. I may need bump a release or do > something and I tested rpmlint on one result of mock build . $ mock -r fedora-rawhide-x86_64 --scrub all $ mock -r fedora-rawhide-x86_64 --install fedpkg $ mock -r fedora-rawhide-x86_64 --shell <mock-chroot> sh-4.3# su - mockbuild [mockbuild@nb ~]$ fedpkg clone -a ufraw && cd ufraw [mockbuild@nb ~]$ fedpkg srpm [mockbuild@nb ufraw]$ rpmlint /builddir/ufraw/ufraw-0.22-5.fc26.src.rpm sh: /usr/bin/gimptool-2.0: No such file or directory 1 packages and 0 specfiles checked; 0 errors, 0 warnings. The only issue I see is the missing gimptool, which is packaging issue. $ mock -r fedora-rawhide-x86_64 --install rpmdevtools $ mock -r fedora-rawhide-x86_64 --shell <mock-chroot> sh-4.3# su - mockbuild [mockbuild@nb ~]$ cd ufraw [mockbuild@nb ufraw]$ LANG=en_US.utf8 rpmdev-bumpspec ufraw.spec sh: /usr/bin/gimptool-2.0: No such file or directory > (In reply to Michael Schwendt from comment #38) > > But once more, _any_ RPM macros may lead to output depending on what is > > available in the buildroot. > > yes It might or might not be an issue, case-by-case. But if possible, builds should be deterministic; regardless where those builds are done to not complicate reproducing FTBFSs. > but note this report begin with one tentative of understand erroneous messages > that appears in Fedora review That's would be serious enough to have the fix ... fedora-review is one of the first tools newcomers use; and misleading errors just cause confusion.
> I use: fedpkg clone ufraw; cd ufraw; fedpkg srpm , > I don't extract src.rpm, I create src.rpm to build in mock as test. Then you may want to open a ticket against "fedpkg" and request that it redefines %_sourcedir to the current directory, so that "rpm" would find the sources and patch files and would not look in your user's default %_sourcedir. > The only issue I see is the missing gimptool, which is packaging issue. Not if all BuildRequires are satisfied. Mind you, you cannot build the package anyway, if BuildRequires are missing. > and rpmdev-bumpspec or rpmlint may output erroneous messages ? rpmdev-bumpspec doesn't. It executes "rpm" as one way to retrieve package EVR from the spec file. Install all BuildRequires that are needed for building the package and processing the spec file.
(In reply to Michael Schwendt from comment #41) > > The only issue I see is the missing gimptool, which is packaging issue. > > Not if all BuildRequires are satisfied. Mind you, you cannot build the > package anyway, if BuildRequires are missing. Mock needs to read/parse the BuildRequires first, to be able to install them.. so to me this is packaging issue (one should make sure that even log for building srpm is warning free).
> (one should make sure that even log for building srpm is warning free). At this point I strongly suggest discussing this on a mailing-list first. Maybe packaging@ list. When executing programs in macro definitions, some packagers redirect output to /dev/null in order to reduce the noise that may be printed even during a simple "rpmbuild -bs foo.spec" (which is the one step Mock needs to do to build the src.rpm). However, it is up to the packager to decide whether to discard stdout/stderr. Whereas a warning about a missing executable may be uninteresting, discarding everything sent to stdout/stderr may be too much.
I agree that blindly discarding all stderr/errors does not makes sense, but I haven't claimed that.. The point is that the spec file in this case is clean enough, maintainers _know good_ what they are doing; so _discarding_ error output in this case makes sense (to me). Or even better; while trying to not over-complicate this (lua, etc.) - this would be quick proposed fix: %global gimptool_path %{_bindir}/gimptool-2.0 # Don't pollute stderr when generating src.rpm; but make sure that # gimptool's errors are not discarded. %global gimptool %(test -f %gimptool_path && echo %gimptool_path || echo :) %global gimpplugindir %(%gimptool --gimpplugindir)/plug-ins This ensures that if %gimptool_path _is_ available, no output will be discarded for debugging purposes (note that gimptool-2.0 should put the error output to stderr). Comments in such cases are crucial. Maybe we could form a RFE against 'rpm' to have declarative way of doing similar things?
Hello, One more element, if on changelog one entry is not in chronological order when we run rpmdev-bumpspec you will got messages of errors but rpmdev-bumpspec works correctly. For example: rpmdev-bumpspec -n 16.12.2 -c "Update foo to 16.12.2" foo.spec error: %changelog not in descending chronological order error: query of specfile kdenlive.spec failed, can't parse
This message is a reminder that Fedora 24 is nearing its end of life. Approximately 2 (two) weeks from now Fedora will stop maintaining and issuing updates for Fedora 24. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '24'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 24 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
This bug is so convoluted and mixing up several things it's just not useful anymore, closing as NOTABUG as suggested several times by Ville. Lets please leave it that way. If you have specific proposals on improving rpm, please take them upstream with a concise description of the issue and proposal, one per ticket: https://github.com/rpm-software-management/rpm/issues Thank you.
I referenced this bug at least dozens of times, so FWIW, it is really hard to respect your "let's please leave it that way" wish... Moved here then: https://github.com/rpm-software-management/rpm/issues/424 No-thanks because closing this helped nothing (single issue bug). If here was tracked anything else (I doubt so), please paste the report here, too.
fine by me , I'd like close it as MOVED , but only rpmfusiom bugzilla have this state :)