Fix Sid dependencies and autopkgtest#2033
Fix Sid dependencies and autopkgtest#2033peternewman merged 2 commits intoOpenLightingProject:0.10from
Conversation
Now needed for sid for some reason
|
|
||
| Test-Command: set -e ; for py in $(py3versions -s 2>/dev/null) ; do echo "Testing with $py:" ; $py $(which rdm_responder_test.py) --help ; done | ||
| Depends: ola-rdm-tests | ||
| Depends: python3-all, ola-rdm-tests |
There was a problem hiding this comment.
Does this need to be python3-all or can it be a smaller subset?
I'm wondering if this is really required since the sid build has been failing due to other factors. Where did this pop up?
There was a problem hiding this comment.
I just copied what the ola-python test has been doing for 3+ years, but @yoe would definitely be the expert:
https://github.com/peternewman/ola/blob/15948e72bc3eda5ba156bffb4a1f1da11e02d344/debian/tests/control#L10-L11
I think the idea is python3-all pulls in all the versions of python on that OS ( https://packages.debian.org/sid/python3-all ) and the you can use py3versions to confirm they're all compatible, which they should be currently...
I'm wondering if this is really required since the sid build has been failing due to other factors. Where did this pop up?
Yeah I finally had a look, and it was just due to the missing equivs package (I assume some code was split out).
All the sid build and test worked after this (on 0.10 branch):
https://github.com/OpenLightingProject/ola/actions/runs/22869778604/job/66347046491#step:8:725
There was a problem hiding this comment.
Wellll, calling me the expert might be pushing it a bit, in this case.
I just took the shortcut of "this will work and I don't have time to do dig into too many details here do shut up and get python3-all kthxbye".
It's very much possible that this will work with a smaller subset too, but I wouldn't know what exactly is required...
There was a problem hiding this comment.
Hah OK makes sense. Let's keep the python3-all for now.
There was a problem hiding this comment.
I don't have a strong opinion, but I suspect depending on python3 instead of python3-all might be more appropriate; we just need one version of python here don't we?
There was a problem hiding this comment.
Sorry -- Never mind, I indeed see py3versions is used to iterate over the versions, so then it might be useful to install just all versions available.
There was a problem hiding this comment.
Sorry -- Never mind, I indeed see
py3versionsis used to iterate over the versions, so then it might be useful to install just all versions available.
Yes exactly, we want to test widely and see what breaks at this stage!
There was a problem hiding this comment.
It's very much possible that this will work with a smaller subset too, but I wouldn't know what exactly is required...
Well it would, but presumably if those versions are all available on sid, we should ideally confirm OLA works with all those versions of Python on sid?
|
This PR along, @aroffringa's PRs, and #1855 should hopefully get us back into Debian for 0.11. |
Probably one for a discussion elsewhere, but I thought we were reasonably settled on me releasing the stale (unbroken) master as 0.11.0, it was more trying to work out if the one that will actually go places (with all the shiny C++ newness) and @aroffringa's PRs would be 0.12.0 or 1.0.0 or whatever. |
That's also what I understood, so that 0.11 is the last version without C++11 in it. But that does mean 0.11 won't get into debian (because of the init script), so we could probably try to release a new version relatively soon after which fixes debian. |
Well I guess that's a two-part question then. @yoe is it just #1855 to convert init to systemd that we have to fix to get into the next Debian? And if so, what sort of timeline are we looking at, when do we need to cut a release? I guess the elephant in the room question, somewhat depending on the answer to that, (and I'm not trying to stall, just see what others think) is do we want the next version (I guess in particular if it has a major version bump) to just be the minimum required for C++11 compatibility (i.e. #1889 and whatever else is needed #1989 ?), i.e. ship it as soon as master compiles and passes the tests again. Or do we also strip out any old cruft at the same time (e.g. Python 2, versions of our dependencies that don't themselves compile against C++11 etc, stuff we've marked as deprecated)?
No, I'm proposing to do something horrible and make 0.11 release master without 4e82005 and 597672a i.e. dropping the two breaking C++11 changes out of it, but sneaking anything else in that I can (in time). A few bits like this targeted 0.10 as that was the old workflow (as a fix not a feature) and then would have been pulled into master. I suspect (but I'm very open to comments still), that pretending to get the rest of #1841 and the uncommitted bits on my laptop in as 0.11.1 will make for an easier to review delta, then a fresh PR can be done en-mass where the code isn't particularly reviewed and it's essentially just changing auto_ptr to unique_ptr to make it compile against C++11. |
5 participants
No description provided.