Search Criteria
Package Details: bugwarrior 1.8.0-1
Package Actions
Git Clone URL: | https://aur.archlinux.org/bugwarrior.git (read-only, click to copy) |
---|---|
Package Base: | bugwarrior |
Description: | pull issues from issue trackers into taskwarrior (GitHub, GitLab, Bitbucket, etc.) |
Upstream URL: | https://bugwarrior.readthedocs.io |
Licenses: | GPL3 |
Conflicts: | bugwarrior-git |
Submitter: | wookietreiber |
Maintainer: | Arvedui |
Last Packager: | Arvedui |
Votes: | 8 |
Popularity: | 0.000100 |
First Submitted: | 2017-02-21 14:26 (UTC) |
Last Updated: | 2020-12-13 20:31 (UTC) |
Dependencies (21)
- python (python38, python36, python37, python3.7, nogil-python, python311, python39)
- python-click
- python-dateutil
- python-dogpile.cache
- python-future
- python-jinja
- python-lockfile
- python-pytz
- python-requests
- python-setuptools
- python-six
- python-taskw
- python-bugzilla (optional) – bugzilla support
- python-debianbts (optional) – bts support
- python-google-api-python-client (optional) – gmail support
- python-jira (optional) – jira support
- python-keyring (optional) – keyring support
- python-oauth2client (optional) – gmail support
- python-offtrac (optional) – Trac support
- python-phabricator (optional) – phabricator support
- Show 1 more dependencies...
Latest Comments
Arvedui commented on 2020-04-13 08:54 (UTC)
Yes, of course. Thank your for bringing this to my attention!
I added other optdepends as well, some are still missing because they are not packaged at all for arch right now. I made a todo item to fix that.
tjaart commented on 2020-04-13 01:13 (UTC)
I think this package should optionally depend on
python-jira
for jira supportrvasilev commented on 2017-12-10 08:47 (UTC)
wrong sha256sum.
should be
ab03c3872e8f27f954b60bb6ff4f0646a2b7e2a7fb9c12116a90cdc297b4b34f
Foxboron commented on 2017-12-09 23:31 (UTC) (edited on 2017-12-09 23:32 (UTC) by Foxboron)
Yes, I saw it now :p Missed that one.
Pushed and should be without errors. Please feel free to yell if you spot anything.
rvasilev commented on 2017-12-09 16:43 (UTC) (edited on 2017-12-09 17:02 (UTC) by rvasilev)
The second
package()
should be install()?... My bad. The 1st package() should be build()
Foxboron commented on 2017-12-09 15:01 (UTC)
Something strange with the setup.py when utilizing python3, the egg-info is inserted but the module is missing.
Don't have time to investigate this today, so incase anyone else wants to take a look:
rvasilev commented on 2017-12-08 12:40 (UTC)
omitting setup.py dependency check is also a workaround with potential to brake the build.
even
python3 setup.py install --optimize=1
is installingfuture-0.15
. is it a bug or a feature?so, you as maintainer can do both - make it up to date and working, or leave it broken and wait until all upstreams/AUR dependencies will be fixed
just for reference
Foxboron commented on 2017-12-08 11:38 (UTC)
If you read what i wrote you'd realize that setup.py dependency check can be omitted. The bug that happens with future is a python2 regression.
taskw will be fixed whenever I accept the orphan request.
rvasilev commented on 2017-12-08 11:34 (UTC) (edited on 2017-12-08 11:39 (UTC) by rvasilev)
not everything is solved with python3
even if upstream will be fixed, it will not 'just build' with AUR dependencies as of now.
i see number of options, choose one of them:
1 Ideal linux-way with python3:
python-taskw
that is absent in AURpython-future-0.15
to workaround2 Ideal linux-way with python2:
python2-taskw
python2-future-0.15
to workaround3 My linux-way with python2:
setup.py
to unpin version frompython2-future
python2-taskw
4 My python2-3 way:
the last one is the fastest and more future proof until all the fixes will be accepted to upstream/AUR. and it will just work.
Foxboron commented on 2017-12-08 10:38 (UTC)
Looking at this, it's only a python2 problem. Everything is solved by migrating to python3.
Foxboron commented on 2017-12-08 10:32 (UTC)
Instead of patching setup.py, we can tell setup.py to ignore any dependency checks.
We are also not going to do horrible workarounds when it helps everyone if we just submit patches to upstream to solve the problem.
rvasilev commented on 2017-12-08 09:46 (UTC) (edited on 2017-12-08 09:50 (UTC) by rvasilev)
for upstream 1.5.1
the easiest way to do it is patching setup.py that comes with source and remove version pin for
python2-future
. check this out https://gist.github.com/rvasilev/d90e20c76e39821b9dd3a924d4703227that's possible and package is even building, but it's not the best choice because
python2-taskw
,python2-twiggy
)so, we could go with less linux, but more pythonic way and step off of dependancy tracking and build self-contained python module in virtualenv. to do so, you may look https://gist.github.com/rvasilev/c86d9f4522d5375f12f22dd8718c9729
commented on 2017-12-08 08:08 (UTC)
Besides waiting for https://github.com/ralphbean/bugwarrior/issues/427 to be solved, I think the more pragmatic way for us to workaround this issue on our side is to create a separate package named python2-future-0.15 (or whatever the version bugwarrior needs) and this package should conflict with the normal
python2-future
meanwhile, until the issue noted above is solved.rvasilev commented on 2017-12-07 20:29 (UTC) (edited on 2017-12-07 20:30 (UTC) by rvasilev)
https://gist.github.com/rvasilev/c86d9f4522d5375f12f22dd8718c9729
PKGBUILD builds latest tagged 1.5.1 bugwarrior within isolated virtualenv. Bugwarrior will be self-contained with all non-system dependencies. That's the only way that not bothers about outdated arch-python packages.
wookietreiber commented on 2017-12-07 08:33 (UTC)
the real (and only) problem is getting in the old version of python2-future. see my older comment on how it works with virtualenv. I suppose you could depend on everything BUT python2-future and do the remaining python2-future/bugwarrior installation via virtualenv to /opt or something.
Foxboron commented on 2017-12-07 00:30 (UTC)
Helluw.
I just adopted this package. I'll get to work fixing it during the weekend!
thelinuxguy commented on 2017-12-06 23:34 (UTC)
Do you intend to continue maintaining this package? I am interested in using it myself, so I could take over.
wookietreiber commented on 2017-07-31 12:46 (UTC)