| Summary: | dev-util/mingw64-runtime version bump | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Alon Bar-Lev <alon.barlev> |
| Component: | New packages | Assignee: | Gentoo Toolchain Maintainers <toolchain> |
| Status: | RESOLVED FIXED | ||
| Severity: | enhancement | ||
| Priority: | High | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Attachments: |
mingw64-runtime-20100604.ebuild.diff
mingw64-runtime-20100604.ebuild.diff |
||
|
Description
Alon Bar-Lev
2010-06-11 16:07:28 UTC
Created attachment 234983 [details, diff]
mingw64-runtime-20100604.ebuild.diff
seems the snapshot was made incorrectly as it tries to run autotools after `make` ?
also, the --enable-sdk is gone ?
* QA Notice: Automake "maintainer mode" detected:
*
* CDPATH="${ZSH_VERSION+.}:" && cd . && /bin/bash /var/tmp/portage/cross-x86_64-w64-mingw32/mingw64-runtime-20100604/work/mingw-w64-v1.0-20100604/mingw-w64-headers/missing --run aclocal-1.11
* CDPATH="${ZSH_VERSION+.}:" && cd . && /bin/bash /var/tmp/portage/cross-x86_64-w64-mingw32/mingw64-runtime-20100604/work/mingw-w64-v1.0-20100604/mingw-w64-headers/missing --run autoconf
* cd . && /bin/bash /var/tmp/portage/cross-x86_64-w64-mingw32/mingw64-runtime-20100604/work/mingw-w64-v1.0-20100604/mingw-w64-headers/missing --run automake-1.11 --foreign
*
* configure: WARNING: unrecognized options: --enable-sdk
* configure: WARNING: unrecognized options: --enable-sdk
* configure: WARNING: unrecognized options: --enable-sdk
* configure: WARNING: unrecognized options: --enable-sdk
Strange I did not notice these errors... sorry I was blind or something. --with-sdk exists in mingw-w64-headers autoconf, I will investigate why it does not work. It should be set to --with-sdk (yes) so all sdks will be installed. Created attachment 236135 [details]
mingw64-runtime-20100604.ebuild.diff
OK.
The only difference between the branches is --with-sdk and --enable-sdk
The maintenance mode is not solved, what should I do?
if it's just a screw up in the packaging, and the regenerated files arent really different, use something like this in src_unpack/src_prepare:
find "${S}" -type f -exec touch -r "${S}" {} +
(In reply to comment #5) > if it's just a screw up in the packaging, and the regenerated files arent > really different, use something like this in src_unpack/src_prepare: > find "${S}" -type f -exec touch -r "${S}" {} + > The package is OK. I never understood why maintainer mode should be used anyway... Also, the touch trick does not work, as it touches files in different order than dependency. The QA warning just alarms users, they cannot do anything about it. Maybe adding QA_IT_IS_OK_TO_USE_MAINTAINER_MODE=1 in the ebuild to eliminate this warning is appropriate, so developer can be informed, verify and then resolve. the touch order doesnt matter ... that's why i specified -r the maintainer warning is because the autotool timestamps are screwed up in the tarball and the package itself is attempting to regenerate its files. this can often lead to random build failures on people's systems. (In reply to comment #7) > the maintainer warning is because the autotool timestamps are screwed up in the > tarball and the package itself is attempting to regenerate its files. this can > often lead to random build failures on people's systems. True, but in this case for example, we verify that it is OK, and we wish to eliminate the QA warning. Can it be done? that's the point of my `find ... touch` suggestion. does that not work ? (In reply to comment #9) > that's the point of my `find ... touch` suggestion. does that not work ? I tried to set EAPI=2, but then build fails, something is different in econf? So we cannot src_prepare()... So I added src_unpack with the touch, no warning now. src_unpack() { unpack ${A} find "${S}"/.. -type f -exec touch -r "${S}" {} + } might as well use ${WORKDIR} rather than ${S}/..
added to the tree then, thanks |
