This request is superseded by
request 627637
(Show diff)
You're not reviewing the full diff of
request 627628
, but the diff to the superseded
request 627624
(Show full diff)
Overview
Request 627628 superseded
- Switch to multibuild to run tests
- Drop doc subpkg, they have compiled docu on web, much better
* Drops patch for_sphinx.patch
- Version update to 4.1.1:
* Fixes on python 3.x
- Created by scarabeus_iv
- In state superseded
- Supersedes 627624
- Superseded by 627637
-
Open review for
factory-staging
-
Open review for
opensuse-review-team
-
Open review for
repo-checker
Loading...
Request History
scarabeus_iv created request
- Switch to multibuild to run tests
- Drop doc subpkg, they have compiled docu on web, much better
* Drops patch for_sphinx.patch
- Version update to 4.1.1:
* Fixes on python 3.x
licensedigger accepted review
ok
factory-auto added opensuse-review-team as a reviewer
Please review sources
factory-auto added repo-checker as a reviewer
Please review build success
factory-auto accepted review
Check script succeeded
scarabeus_iv superseded request
superseded by 627637
+Requires: this-is-only-for-build-envs
why? The -test should not contain the python code - at best you'd publish a test log in the package there; special tricks to make this not-installable seems weird here
It is a shortest way that makes the tests being run while not having to rewrite the whole %files section.
Lazyness is no excuse for crap, sorry
That is not laziness the package will not install any files, so it is better to just block it than to create empty files with license.
The test log in the files section would be value - as it could be inspected
(the problem with this is that the bot won't find an installable solution - which in turn means it needs be white listed; all the 'only-for-build-env' whitelists are for the sake of bootstrap/cycles, and not for sake of publishing unusable stuff into the repo)
You can have empty package like python-canonicaljson.spec Or have it much more readable with just one conflict, i will go for readable over empty package any day.
I frankly don't see this as a proper solution to the problem at hand; readable maybe... but still crap
The test doesn't even run against the 'exact' files we deliver to the user; and with TW not doing full rebuilds of the entire distro all the time, there is not even a relation establishable between rebuilds of the delivered package vs what the test ran against. This test is a pure proforma thing for somebodys conscious - but the value is questionable
(we had a very similar issue in meson/meson-testsuite - where the testsuite package intentionally was done to use meson (the package we deliver) to use for the test suite, intentionally removing all sources that could possibly interfere... we want to test what we deliver after all)