| Message ID | 20220317164434.387779-2-ross.burton@arm.com |
|---|---|
| State | Accepted, archived |
| Commit | 7c098aac08faf5da01aafec5c5d87f563d913744 |
| Headers | show |
| Series | [1/2] python3-cryptography-vectors: upgrade to 36.0.2 | expand |
Google perfetto recipes. They are quite crappy, but in case somebody wants to play around with it. Am 17.03.22 um 17:44 schrieb Ross Burton: > python3-cryptography and python3-cryptography-vectors are actually the > same project but are on Pypi as two separate modules. > > The test suite validates that they're the same version and fails if they > are not: > > FAIL: tests/test_utils.py::test_vector_version > def test_vector_version(): >> assert cryptography.__version__ == cryptography_vectors.__version__ > E AssertionError: assert '36.0.2' == '36.0.1' > > Catch this slightly earlier by mandating that python3-cryptography-ptest > pulls in an identically versioned python3-cryptography-vectors. > > Signed-off-by: Ross Burton <ross.burton@arm.com> > --- > meta/recipes-devtools/python/python3-cryptography_36.0.2.bb | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/meta/recipes-devtools/python/python3-cryptography_36.0.2.bb b/meta/recipes-devtools/python/python3-cryptography_36.0.2.bb > index 940df60d44..cb3acdf7e2 100644 > --- a/meta/recipes-devtools/python/python3-cryptography_36.0.2.bb > +++ b/meta/recipes-devtools/python/python3-cryptography_36.0.2.bb > @@ -91,7 +91,7 @@ RDEPENDS:${PN}:append:class-target = " \ > > RDEPENDS:${PN}-ptest += " \ > ${PYTHON_PN}-bcrypt \ > - ${PYTHON_PN}-cryptography-vectors \ > + ${PYTHON_PN}-cryptography-vectors (= ${PV}) \ > ${PYTHON_PN}-hypothesis \ > ${PYTHON_PN}-iso8601 \ > ${PYTHON_PN}-pretend \ > > -=-=-=-=-=-=-=-=-=-=-=- > Links: You receive all messages sent to this group. > View/Reply Online (#163426): https://lists.openembedded.org/g/openembedded-core/message/163426 > Mute This Topic: https://lists.openembedded.org/mt/89849717/3618223 > Group Owner: openembedded-core+owner@lists.openembedded.org > Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [f_l_k@t-online.de] > -=-=-=-=-=-=-=-=-=-=-=- >
Not sure if this is working correctly, with opkg and python3-cryptography-ptest included in the image I get: * Solver encountered 1 problem(s): * Problem 1/1: * - conflicting requests * - nothing provides python3-cryptography-vectors = 36.0.2 needed by python3-cryptography-ptest-36.0.2-r0.0.qemux86_64 * * Solution 1: * - do not ask to install a package providing python3-cryptography-ptest even when I do have python3-cryptography-vectors_36.0.2-r0.0_qemux86_64.ipk and python3-cryptography-ptest_36.0.2-r0.0_qemux86_64.ipk is rpm parsing the version differently or is the issue somewhere else? I guess forcing identical EXTENDPKGV (instead of PV) between python3-cryptography and python3-cryptography-vectors would be too much (especially for people with PRserv enabled). Cheers, On Thu, Mar 17, 2022 at 5:44 PM Ross Burton <ross@burtonini.com> wrote: > python3-cryptography and python3-cryptography-vectors are actually the > same project but are on Pypi as two separate modules. > > The test suite validates that they're the same version and fails if they > are not: > > FAIL: tests/test_utils.py::test_vector_version > def test_vector_version(): > > assert cryptography.__version__ == cryptography_vectors.__version__ > E AssertionError: assert '36.0.2' == '36.0.1' > > Catch this slightly earlier by mandating that python3-cryptography-ptest > pulls in an identically versioned python3-cryptography-vectors. > > Signed-off-by: Ross Burton <ross.burton@arm.com> > --- > meta/recipes-devtools/python/python3-cryptography_36.0.2.bb | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/meta/recipes-devtools/python/python3-cryptography_36.0.2.bb > b/meta/recipes-devtools/python/python3-cryptography_36.0.2.bb > index 940df60d44..cb3acdf7e2 100644 > --- a/meta/recipes-devtools/python/python3-cryptography_36.0.2.bb > +++ b/meta/recipes-devtools/python/python3-cryptography_36.0.2.bb > @@ -91,7 +91,7 @@ RDEPENDS:${PN}:append:class-target = " \ > > RDEPENDS:${PN}-ptest += " \ > ${PYTHON_PN}-bcrypt \ > - ${PYTHON_PN}-cryptography-vectors \ > + ${PYTHON_PN}-cryptography-vectors (= ${PV}) \ > ${PYTHON_PN}-hypothesis \ > ${PYTHON_PN}-iso8601 \ > ${PYTHON_PN}-pretend \ > -- > 2.25.1 > > > -=-=-=-=-=-=-=-=-=-=-=- > Links: You receive all messages sent to this group. > View/Reply Online (#163426): > https://lists.openembedded.org/g/openembedded-core/message/163426 > Mute This Topic: https://lists.openembedded.org/mt/89849717/3617156 > Group Owner: openembedded-core+owner@lists.openembedded.org > Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [ > Martin.Jansa@gmail.com] > -=-=-=-=-=-=-=-=-=-=-=- > >
I've tried with rpm and surprisingly it works and dnf was able to install python3-cryptography-ptest in the image (even after bumping PR to r1 -n python3-cryptography-vectors recipe). But still not clear why it works and if it's expected behavior. In fresh fedora:37 docker image with rpmdevtools installed I see: [root@aaa509e35d1f /]# rpmdev-vercmp 36.0.2-r0 36.0.2-r1 36.0.2-r0 < 36.0.2-r1 [root@aaa509e35d1f /]# rpmdev-vercmp 36.0.2-r0 36.0.2-r0 36.0.2-r0 == 36.0.2-r0 [root@aaa509e35d1f /]# rpmdev-vercmp 36.0.2-r0.0 36.0.2-r0.1 36.0.2-r0.0 < 36.0.2-r0.1 But I'm not familiar with dnf/rpm to see how the versioned runtime dependency is handled during installation (isn't it resolved by the same libsolv as what opkg is using now by default as well? + Alejandro in case it should be fixed in opkg somehow. On Fri, Apr 1, 2022 at 10:39 PM Martin Jansa via lists.openembedded.org <Martin.Jansa=gmail.com@lists.openembedded.org> wrote: > Not sure if this is working correctly, with opkg > and python3-cryptography-ptest included in the image I get: > > * Solver encountered 1 problem(s): > * Problem 1/1: > * - conflicting requests > * - nothing provides python3-cryptography-vectors = 36.0.2 needed by > python3-cryptography-ptest-36.0.2-r0.0.qemux86_64 > * > * Solution 1: > * - do not ask to install a package providing python3-cryptography-ptest > > even when I do have > python3-cryptography-vectors_36.0.2-r0.0_qemux86_64.ipk and > python3-cryptography-ptest_36.0.2-r0.0_qemux86_64.ipk > > is rpm parsing the version differently or is the issue somewhere else? > > I guess forcing identical EXTENDPKGV (instead of PV) between > python3-cryptography and python3-cryptography-vectors would be too much > (especially for people with PRserv enabled). > > Cheers, > > On Thu, Mar 17, 2022 at 5:44 PM Ross Burton <ross@burtonini.com> wrote: > >> python3-cryptography and python3-cryptography-vectors are actually the >> same project but are on Pypi as two separate modules. >> >> The test suite validates that they're the same version and fails if they >> are not: >> >> FAIL: tests/test_utils.py::test_vector_version >> def test_vector_version(): >> > assert cryptography.__version__ == >> cryptography_vectors.__version__ >> E AssertionError: assert '36.0.2' == '36.0.1' >> >> Catch this slightly earlier by mandating that python3-cryptography-ptest >> pulls in an identically versioned python3-cryptography-vectors. >> >> Signed-off-by: Ross Burton <ross.burton@arm.com> >> --- >> meta/recipes-devtools/python/python3-cryptography_36.0.2.bb | 2 +- >> 1 file changed, 1 insertion(+), 1 deletion(-) >> >> diff --git a/meta/recipes-devtools/python/python3-cryptography_36.0.2.bb >> b/meta/recipes-devtools/python/python3-cryptography_36.0.2.bb >> index 940df60d44..cb3acdf7e2 100644 >> --- a/meta/recipes-devtools/python/python3-cryptography_36.0.2.bb >> +++ b/meta/recipes-devtools/python/python3-cryptography_36.0.2.bb >> @@ -91,7 +91,7 @@ RDEPENDS:${PN}:append:class-target = " \ >> >> RDEPENDS:${PN}-ptest += " \ >> ${PYTHON_PN}-bcrypt \ >> - ${PYTHON_PN}-cryptography-vectors \ >> + ${PYTHON_PN}-cryptography-vectors (= ${PV}) \ >> ${PYTHON_PN}-hypothesis \ >> ${PYTHON_PN}-iso8601 \ >> ${PYTHON_PN}-pretend \ >> -- >> 2.25.1 >> >> >> >> >> > -=-=-=-=-=-=-=-=-=-=-=- > Links: You receive all messages sent to this group. > View/Reply Online (#163945): > https://lists.openembedded.org/g/openembedded-core/message/163945 > Mute This Topic: https://lists.openembedded.org/mt/89849717/3617156 > Group Owner: openembedded-core+owner@lists.openembedded.org > Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [ > Martin.Jansa@gmail.com] > -=-=-=-=-=-=-=-=-=-=-=- > >
On Thu, 2022-04-07 at 16:48 +0200, Martin Jansa wrote: > I've tried with rpm and surprisingly it works and dnf was able to > install python3-cryptography-ptest in the image (even after bumping PR to r1 - > n python3-cryptography-vectors recipe). > > But still not clear why it works and if it's expected behavior. > > In fresh fedora:37 docker image with rpmdevtools installed I see: > > [root@aaa509e35d1f /]# rpmdev-vercmp 36.0.2-r0 36.0.2-r1 > 36.0.2-r0 < 36.0.2-r1 > [root@aaa509e35d1f /]# rpmdev-vercmp 36.0.2-r0 36.0.2-r0 > 36.0.2-r0 == 36.0.2-r0 > [root@aaa509e35d1f /]# rpmdev-vercmp 36.0.2-r0.0 36.0.2-r0.1 > 36.0.2-r0.0 < 36.0.2-r0.1 > > But I'm not familiar with dnf/rpm to see how the versioned runtime dependency > is handled during installation (isn't it resolved by the same libsolv as what > opkg is using now by default as well? > > + Alejandro in case it should be fixed in opkg somehow. I did a bit of digging on this and it is basically a difference in behaviour between the debian and rpm worlds. In Debian, "1.2.3" != "1.2.3-r0" but in the rpm world, a recipe saying "(= 1.2.3)" with PR=r0 is ok and matches. We can't obtain the PR of another recipe when writing package manager fields so this is rather tricky to solve. Debian doesn't support any kind of wildcard in the versioning either. I've proposed a patch which uses >= and << to force a very specific range which is horrible but the best I could come up with. I'm open to other ideas... Cheers, Richard
On Thu, Apr 7, 2022 at 11:10 PM Richard Purdie < richard.purdie@linuxfoundation.org> wrote: > On Thu, 2022-04-07 at 16:48 +0200, Martin Jansa wrote: > > I've tried with rpm and surprisingly it works and dnf was able to > > install python3-cryptography-ptest in the image (even after bumping PR > to r1 - > > n python3-cryptography-vectors recipe). > > > > But still not clear why it works and if it's expected behavior. > > > > In fresh fedora:37 docker image with rpmdevtools installed I see: > > > > [root@aaa509e35d1f /]# rpmdev-vercmp 36.0.2-r0 36.0.2-r1 > > 36.0.2-r0 < 36.0.2-r1 > > [root@aaa509e35d1f /]# rpmdev-vercmp 36.0.2-r0 36.0.2-r0 > > 36.0.2-r0 == 36.0.2-r0 > > [root@aaa509e35d1f /]# rpmdev-vercmp 36.0.2-r0.0 36.0.2-r0.1 > > 36.0.2-r0.0 < 36.0.2-r0.1 > > > > But I'm not familiar with dnf/rpm to see how the versioned runtime > dependency > > is handled during installation (isn't it resolved by the same libsolv as > what > > opkg is using now by default as well? > > > > + Alejandro in case it should be fixed in opkg somehow. > > I did a bit of digging on this and it is basically a difference in > behaviour > between the debian and rpm worlds. > > In Debian, "1.2.3" != "1.2.3-r0" but in the rpm world, a recipe saying "(= > 1.2.3)" with PR=r0 is ok and matches. > > We can't obtain the PR of another recipe when writing package manager > fields so > this is rather tricky to solve. Debian doesn't support any kind of > wildcard in > the versioning either. I've proposed a patch which uses >= and << to force > a > very specific range which is horrible but the best I could come up with. > I'm > open to other ideas... > For this specific case the cure is almost more horrible than the issue this commit was trying to prevent, but I agree that being able to depend on version might be useful elsewhere as well and your package*bbclass fix helps with that. Thanks for looking into this. Regards,
On Thu, Apr 7, 2022 at 5:37 PM Martin Jansa <Martin.Jansa@gmail.com> wrote: > On Thu, Apr 7, 2022 at 11:10 PM Richard Purdie < > richard.purdie@linuxfoundation.org> wrote: > >> On Thu, 2022-04-07 at 16:48 +0200, Martin Jansa wrote: >> > I've tried with rpm and surprisingly it works and dnf was able to >> > install python3-cryptography-ptest in the image (even after bumping PR >> to r1 - >> > n python3-cryptography-vectors recipe). >> > >> > But still not clear why it works and if it's expected behavior. >> > >> > In fresh fedora:37 docker image with rpmdevtools installed I see: >> > >> > [root@aaa509e35d1f /]# rpmdev-vercmp 36.0.2-r0 36.0.2-r1 >> > 36.0.2-r0 < 36.0.2-r1 >> > [root@aaa509e35d1f /]# rpmdev-vercmp 36.0.2-r0 36.0.2-r0 >> > 36.0.2-r0 == 36.0.2-r0 >> > [root@aaa509e35d1f /]# rpmdev-vercmp 36.0.2-r0.0 36.0.2-r0.1 >> > 36.0.2-r0.0 < 36.0.2-r0.1 >> > >> > But I'm not familiar with dnf/rpm to see how the versioned runtime >> dependency >> > is handled during installation (isn't it resolved by the same libsolv >> as what >> > opkg is using now by default as well? >> > >> > + Alejandro in case it should be fixed in opkg somehow. >> >> I did a bit of digging on this and it is basically a difference in >> behaviour >> between the debian and rpm worlds. >> >> In Debian, "1.2.3" != "1.2.3-r0" but in the rpm world, a recipe saying "(= >> 1.2.3)" with PR=r0 is ok and matches. >> >> We can't obtain the PR of another recipe when writing package manager >> fields so >> this is rather tricky to solve. Debian doesn't support any kind of >> wildcard in >> the versioning either. I've proposed a patch which uses >= and << to >> force a >> very specific range which is horrible but the best I could come up with. >> I'm >> open to other ideas... >> > > For this specific case the cure is almost more horrible than the issue > this commit was trying to prevent, but I agree that being able to depend on > version might be useful elsewhere as well and your package*bbclass fix > helps with that. > > Thanks for looking into this. > If the pain (which is what I understand with limited investigation) is cryptography vs cryptography-vectors being in sync (already a painfully known problem) — I again propose merging the recipes. Now I think about PYPI_PACKAGE being extended to understanding lists… And I want a pony, with wings, and rainbow hair, and a horn. > Regards, > > -=-=-=-=-=-=-=-=-=-=-=- > Links: You receive all messages sent to this group. > View/Reply Online (#164149): > https://lists.openembedded.org/g/openembedded-core/message/164149 > Mute This Topic: https://lists.openembedded.org/mt/89849717/924729 > Group Owner: openembedded-core+owner@lists.openembedded.org > Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [ > ticotimo@gmail.com] > -=-=-=-=-=-=-=-=-=-=-=- > >
On Thu, 2022-04-07 at 17:50 -0700, Tim Orling wrote: > > > On Thu, Apr 7, 2022 at 5:37 PM Martin Jansa <Martin.Jansa@gmail.com> wrote: > > On Thu, Apr 7, 2022 at 11:10 PM Richard Purdie < > > > > For this specific case the cure is almost more horrible than the issue this > > commit was trying to prevent, but I agree that being able to depend on > > version might be useful elsewhere as well and your package*bbclass fix helps > > with that. > > > > Thanks for looking into this. > > > > > If the pain (which is what I understand with limited investigation) is > cryptography vs cryptography-vectors being in sync (already a painfully known > problem) — I again propose merging the recipes. Now I think about PYPI_PACKAGE > being extended to understanding lists… As Martin says, the cure is almost more horrible than the original problem. The deciding factor is that this can and will happen again somewhere else though, so horrible as my "fix" is, it is probably worth having. Whether we do something else with the python3-cypto recipes remains to be seen. Cheers, Richard
diff --git a/meta/recipes-devtools/python/python3-cryptography_36.0.2.bb b/meta/recipes-devtools/python/python3-cryptography_36.0.2.bb index 940df60d44..cb3acdf7e2 100644 --- a/meta/recipes-devtools/python/python3-cryptography_36.0.2.bb +++ b/meta/recipes-devtools/python/python3-cryptography_36.0.2.bb @@ -91,7 +91,7 @@ RDEPENDS:${PN}:append:class-target = " \ RDEPENDS:${PN}-ptest += " \ ${PYTHON_PN}-bcrypt \ - ${PYTHON_PN}-cryptography-vectors \ + ${PYTHON_PN}-cryptography-vectors (= ${PV}) \ ${PYTHON_PN}-hypothesis \ ${PYTHON_PN}-iso8601 \ ${PYTHON_PN}-pretend \
python3-cryptography and python3-cryptography-vectors are actually the same project but are on Pypi as two separate modules. The test suite validates that they're the same version and fails if they are not: FAIL: tests/test_utils.py::test_vector_version def test_vector_version(): > assert cryptography.__version__ == cryptography_vectors.__version__ E AssertionError: assert '36.0.2' == '36.0.1' Catch this slightly earlier by mandating that python3-cryptography-ptest pulls in an identically versioned python3-cryptography-vectors. Signed-off-by: Ross Burton <ross.burton@arm.com> --- meta/recipes-devtools/python/python3-cryptography_36.0.2.bb | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)