This request is superseded by
request 689955
(Show diff)
Overview
Request 673135 superseded
Continuation of https://build.opensuse.org/request/show/673101
- Created by jayvdb
- In state superseded
- Superseded by 689955
Loading...
Request History
jayvdb created request
Continuation of https://build.opensuse.org/request/show/673101
scarabeus_iv declined request
Same as the git python, just supersede it when you have time, see how I minimalized the service in https://build.opensuse.org/package/view_file/home:jayvdb:django/python-GitPython/_service?expand=1
It is not possible to use tags, as they do not exist https://github.com/ryanmcgrath/twython/issues/506
And what about switching to _service and following the master branch then? https://en.opensuse.org/openSUSE:Build_Service_Concept_SourceService#Step_by_step (or see for example https://build.opensuse.org/package/show/devel:languages:python:Factory/python-rpm-macros ).
The intention is not to follow the master branch. The sha that I used is roughly equivalent to released version, and will need to be updated only when a new release is packaged.
The intention is to have a stop gap measure in place until the next upstream release, to ensure that the tests are actually working.
As opposed to the very large number of python packages in d:l:py that are riddled with packaging bugs preventing the tests from running.
Used by python-nltk
Oky, lets give the author of the software few days to act upon the tags/etc as this is pretty ugly.
Funny ... several other packages I've found in d:l:py do exactly this. Im getting quite tired of different standards being applied.
Where, only thing I am aware of is pytoml where it is special case of having patched toml-tests package that won't work otherwise.
dl-p> grep -E 'define.[a-f0-9]{38}' */.spec python-ansicolor/python-ansicolor.spec:%define tag a5a5c31dc6de5c864a0c5684ae326972573a712b python-autoflake/python-autoflake.spec:%define tag 44b07bb9dab60a74cb5da0b67cc78b734763785c python-coverage-config-reload-plugin/python-coverage-config-reload-plugin.spec:%define tag 2abc0b1f930ee5b281e15e8fb7e3dfe7a456e414 python-dash/python-dash.spec:%define tag ff93d2c4331a576b445be87bb3b77576f18b030a python-promise/python-promise.spec:%define tag b055d1e2aa1368062bc4f265b525bf2e48fadc47 python-pyparallel/python-pyparallel.spec:%define tag b33995136e433839cb5cd139214d02c7c6dd2008 python-pythonwhois/python-pythonwhois.spec:%define commit 60adc3acc2d59627b2e32dc36d27802942e0820d/ python-RegexOrder/python-RegexOrder.spec:%define tag 23f0ac4ac46527404e3ec9097df931378d3d803a dl-py-misc> grep -E 'define.[a-f0-9]{38}' */.spec python-clevercss/python-clevercss.spec:%define gitrev 2272da5785fd9a5a723ea12a5d7081bec20b7c9b
Did you actually look for what is it used there? It is for fetching license file only, one could even argue it is pointless they could've gotten it from HEAD directly, but who am i to judge they want to waste time finding the tag.
Of course I looked. I recently fixed one of them; autoflake, and the LICENSE was added upstream since the last time. The audit trail of using master is very bad. A GitHub repo can be completely replaced, all contents completely rewritten. With a hash at least there is some evidence that can be used to verify a forked copy is legitimate and thus the license can be verified. I guess you already know that.
Based on upstream comments in the ticket I really recommend switching to _service file that fetches git master...
This has absolutely nothing to do with tracking their master. That is a red herring. If they enhance their tests, it would break this package, which is inappropriate. The tarball should be a static set of tests based as closely on the release date as possible, which is what I have done.
We are talking about https://en.opensuse.org/openSUSE:Build_Service_Concept_SourceService not about just taking their tests from git HEAD
I had a look at _service in d-l-py - there are very few of them, and they all are in state disabled afaic. Is that what you are asking me to do?
What about I add a .patch of the tests which are not skipped? Would that be ok?
they are disabled and you can run them only when needed with "osc service disabledrun" which is okay. otherwise the services are run with every trigger (like rebuilds/etc.)
We are human, and mostly volunteers. We do our best to be careful and consistent but sometimes stuff slips through. When it is brought to our attention we try to fix it.
@TheBlackCat, @alarrosa, @aplanas, @cyberiad, @czerw, @dirkmueller, @glaubitz, @mcepl, @mimi_vx, @pavlix, @posophe, @rjschwei, @scarabeus_iv, @sleep_walker, @tbechtold: review reminder