Description of problem: tcl-tile-0.8.2 has a hard-coded verson pathc, which is not needed Version-Release number of selected component (if applicable): tcl-tile-0.8.2 Patch below and Portability Fix: Wrote: /home/herrold/rpmbuild/SRPMS/tcl-tile-0.8.2-5orc.src.rpm Wrote: /home/herrold/rpmbuild/RPMS/x86_64/tcl-tile-0.8.2-5orc.x86_64.rpm Wrote: /home/herrold/rpmbuild/RPMS/x86_64/tcl-tile-devel-0.8.2-5orc.x86_64.rpm Wrote: /home/herrold/rpmbuild/RPMS/x86_64/tcl-tile-debuginfo-0.8.2-5orc.x86_64.rpm Executing(%clean): /bin/sh -e /var/tmp/rpm-tmp.44379 + umask 022 + cd /home/herrold/rpmbuild/BUILD + cd tile-0.8.2 + rm -rf /var/tmp/tcl-tile-0.8.2-5orc-o23108 + exit 0 real 0m29.734s user 0m9.233s sys 0m2.856s [herrold@centos-5 tcl-tile]$ rpm -qp --requires /home/herrold/rpmbuild/RPMS/x86_64/tcl-tile-0.8.2-5orc.x86_64.rpm | grep tcl tcl(abi) = 8.4 [herrold@centos-5 tcl-tile]$ diff -u tcl-tile.spec-ORIG tcl-tile.spec --- tcl-tile.spec-ORIG 2008-10-29 15:21:21.000000000 -0400 +++ tcl-tile.spec 2008-10-29 15:45:24.000000000 -0400 @@ -2,7 +2,16 @@ # using this for the versioned Requires on tcl(abi), so we hardcode it. # This sucks, but there is no other clean way around it, because tcl # (and tclsh) aren't in the default buildroot. -%{!?tcl_version: %define tcl_version 8.5} +# +# This hardcode define breaks building on RHEL 5 when added to: +# Requires: tcl(abi) = %{tcl_version} +# -- please consider determining tcl version, alternatively +# while a BuildRequires can pull tcl into the buildroot, it is not +# needed, as we can get it from: +# [herrold@centos-5 SPECS]$ rpm -qf /usr/lib64/tclConfig.sh +# tcl-devel-8.4.13-3.fc6 +# +%{!?tcl_version: %define tcl_version %(echo `grep TCL_VERSION /usr/lib64/tclConfig.sh | tr -d "'" | awk -F= {'print $2'}`)} %{!?tcl_sitearch: %define tcl_sitearch %{_libdir}/tcl%{tcl_version}} %define realname tile [herrold@centos-5 tcl-tile]$
This is one of the first ideas I had when I was first developing this package, but unfortunately, it does not work in koji. Koji tries to evaluate the tcl_version macro outside of the buildroot, where there is no tcl-devel installed, thus it errors out. See: http://koji.fedoraproject.org/koji/getfile?taskID=911096&name=build.log I'd be happy to do EPEL builds of this if there are interested users, the only change needed would be to alter the hardcoding to 8.4 (just like F-8).
What you describe is a koji shortcoming, then. reopening and moving into that component Koji needs to supportinstallation BR's benore .spec file macro expansion i.e., functionally a build needs to run in an after enumerated and implicit BR installation environment setup This is needed to support non-manual tcl version determination derived from non-base build environment situations.
Which is a bit of a problem when you may need one of those BRs just to evaluate the .spec file. A bit of chicken/egg there.
?? no chickens here I solved this years ago in cAos' autobuilder with a pre-build extract of just the .spec file, and grepping out ^Build lines, and then massaging after an awk split at -F: {'print $2'} This produces an enumeration of BR's which are passed into the pre-installation BR completion phase, treated as Suggests (soft BR's) Optional packages which might bring in BR's inside of conditionals can safely 'overpopulate' with soft BR's What other issue remains?
Well sure, if you want to bypass the rpm api all together and just manually scrape out lines, that in theory would work, although not something I'd be too keen on putting into a buildsystem. More realistically we'll come up with an environment more suited to processing spec files.
The prefect vision on the hill may be an illusion. An 'agile': "write the test, and solve just the problem presented; refactor when the next use case solution permits (really 'requires')" The problem with .spec files is that there is not a defined 'grammar' which, taken with extensibility, makes attainment of the 'ideal' a _very hard_ problem. Let me restate the matter: will you apply such a 'solve just the test presented' patch? If not, what is the ETA for the Platonic spec parser?
Pardon me while I wade through the slurry of words... I /think/ that our plan does what you mean, be agile and fix things as they go wrong, instead of shooting for perfect. That is, when generating a chroot to process a spec file and build an srpm to pass around, put in the buildroot the current known set of things people expect to be able to evaluate macros within a spec. The set is relatively small at the moment, a number of language packages plus the rpm stack. As people add more languages or such to spec files, we can adjust the buildroot used. This way we continue to use the rpm api to query the spec file, so that there is a canonical source for spec parsing. We bolster this by having an "agile" config for what we put in the chroot that does the parsing. The ETA is well "sometime in the future", but the not too distant future. We need this to be able to support newer rpm features anyway.
at night, all I have is TUI pine and Lynx -- sorry about slurry 'agile' as in 'agile programming techniques'; XP made socially acceptable
This book is well buying and reading The Art of Agile Development [ILLUSTRATED] (Paperback) by James Shore (Author), Shane Warden # Paperback: 438 pages # Publisher: O'Reilly Media, Inc. (October 26, 2007) # Language: English # ISBN-10: 0596527675 on the topic as it will make you fantastically more focused and productive
This bug appears to have been reported against 'rawhide' during the Fedora 10 development cycle. Changing version to '10'. More information and reason for this action is here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
I went to retest, and this seems to not be in today's rawHide .... Is there an issue? Comment 5 and 7 seem not to be advancing. May I help? -- Russ herrold
This bug appears to have been reported against 'rawhide' during the Fedora 12 development cycle. Changing version to '12'. More information and reason for this action is here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
This message is a reminder that Fedora 12 is nearing its end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 12. 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 WONTFIX if it remains open with a Fedora 'version' of '12'. 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 prior to Fedora 12's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 12 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 please change the 'version' of this bug to the applicable version. If you are unable to change the version, please add a comment here and someone will do it for you. 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. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
moving away from the autoclosed, as to a koji deficiency not addressed
This package has changed ownership in the Fedora Package Database. Reassigning to the new owner of this component.
This bug appears to have been reported against 'rawhide' during the Fedora 19 development cycle. Changing version to '19'. (As we did not run this process for some time, it could affect also pre-Fedora 19 development cycle bugs. We are very sorry. It will help us with cleanup during Fedora 19 End Of Life. Thank you.) More information and reason for this action is here: https://fedoraproject.org/wiki/BugZappers/HouseKeeping/Fedora19
This message is a notice that Fedora 19 is now at end of life. Fedora has stopped maintaining and issuing updates for Fedora 19. It is Fedora's policy to close all bug reports from releases that are no longer maintained. Approximately 4 (four) weeks from now this bug will be closed as EOL if it remains open with a Fedora 'version' of '19'. 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 19 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.
Fedora 19 changed to end-of-life (EOL) status on 2015-01-06. Fedora 19 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.