| Summary: | dev-python/celery-3.1.10 version bump | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Ștefan Talpalaru <stefantalpalaru> |
| Component: | [OLD] Development | Assignee: | Python Gentoo Team <python> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | python |
| Priority: | Normal | Keywords: | EBUILD |
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| URL: | https://github.com/celery/celery/issues/1964 | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Bug Depends on: | 505486 | ||
| Bug Blocks: | |||
| Attachments: |
celery-3.1.10.ebuild
celery.confd celery.initd diff -u of ebuilds |
||
|
Description
Ștefan Talpalaru
2014-03-23 19:22:54 UTC
Created attachment 373348 [details]
celery-3.1.10.ebuild
Created attachment 373608 [details]
celery.confd
Created attachment 373610 [details]
celery.initd
Sorry, I forgot to attach the conf and init files when I created the issue. *** This bug has been marked as a duplicate of bug 483356 *** why have you re-written the celery.confd celery.initd ? I rewrote them because the name and syntax of some commands changed (celeryd / celery multi / celery beat), some commands where removed (celeryev), Django support is done differently and important options where missing from the example arguments. Created attachment 374566 [details, diff] diff -u of ebuilds (In reply to Stefan Talpalaru from comment #7) > I rewrote them because the name and syntax of some commands changed (celeryd > / celery multi / celery beat), some commands where removed (celeryev), > Django support is done differently and important options where missing from > the example arguments. Ah right. I take it the current files files/{celery.confd,celery.initd} are no longer apt. for this celery. Until I remove those all together, these new can be named files/{celery.confd-r1,celery.initd-r1}. You suggested ebuild is a copy of the prior version which is based on how I re-wrote it back then. While it might work, this new version needs some updating of the deps and python impls, particularly for the test phase (see URL). A couple you can see are no longer req'd. gevent seems the only straggler not supporting py3, is req'd only in tests, and is skipable hence optional. However good try. Technically the bump can be blocked by a single test failure, so when bumping you need address the testsuite and file upstream accordingly but yep it's a pain. Add the new files with those names and substitute with newinitd "${FILESDIR}/celery.initd-r1" celery newconfd "${FILESDIR}/celery.confd-r1" celery (the re-naming is quite arbitrary or just replace them temporarily). While I could commit as is, there's no urgency. Give this a test run. It allows for time to upstream to reply to the test failures. By rights it will need editing again once upstream maker a fix for the failing tests. Clearly you're a celery user but I have no idea how many more of you are 'out there'. *celery-3.1.10 (09 Apr 2014) 09 Apr 2014; Ian Delaney <idella4@gentoo.org> +celery-3.1.10.ebuild, +files/celery.confd-r1, +files/celery.initd-r1, metadata.xml: bump; add IUSE redis, optional flag for tests, py3 support, update test phase, new initd and confd files submitted by S. Talpalru in Bug #505492, initially masked for further testing I have tested your ebuild and it works as it should. Any reason why you removed 2_6 and 3_4 from PYTHON_COMPAT? Those versions are specified in setup.py: https://github.com/celery/celery/blob/v3.1.10/setup.py . (In reply to Stefan Talpalaru from comment #10) > I have tested your ebuild and it works as it should. Any reason why you > removed 2_6 and 3_4 from PYTHON_COMPAT? Those versions are specified in > setup.py: https://github.com/celery/celery/blob/v3.1.10/setup.py . py2.6 was already excluded from -3.0.21 and is close to being deprecated from portage. To add it requires shoring up all deps with py2.6. py3.4 is still only just added and unmasked in portage. Its presence or listing alone in setup.py is just 1 part of the puzzle. To support py3.4, all deps must also support py3.4 and it's easy to see they don't. Thx for the /etc /scripts |
