[PATCH 1/2] python3-cryptography-vectors: upgrade to 36.0.2

[PATCH 1/2] python3-cryptography-vectors: upgrade to 36.0.2

[Ross Burton]

This needs to be upgraded in lockstep with python3-cryptography.

Signed-off-by: Ross Burton <ross.burton@arm.com>
---
 ...vectors_36.0.1.bb => python3-cryptography-vectors_36.0.2.bb} | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
 rename meta/recipes-devtools/python/{python3-cryptography-vectors_36.0.1.bb => python3-cryptography-vectors_36.0.2.bb} (90%)

diff --git a/meta/recipes-devtools/python/python3-cryptography-vectors_36.0.1.bb b/meta/recipes-devtools/python/python3-cryptography-vectors_36.0.2.bb
similarity index 90%
rename from meta/recipes-devtools/python/python3-cryptography-vectors_36.0.1.bb
rename to meta/recipes-devtools/python/python3-cryptography-vectors_36.0.2.bb
index da6718fb90..be0eda056e 100644
--- a/meta/recipes-devtools/python/python3-cryptography-vectors_36.0.1.bb
+++ b/meta/recipes-devtools/python/python3-cryptography-vectors_36.0.2.bb
@@ -9,7 +9,7 @@ LIC_FILES_CHKSUM = "file://LICENSE;md5=8c3617db4fb6fae01f1d253ab91511e4 \
 # NOTE: Make sure to keep this recipe at the same version as python3-cryptography
 #       Upgrade both recipes at the same time
 
-SRC_URI[sha256sum] = "fc8490afd5424342b868215435bd174dcd76ab396b4ea9435498be5721dcd598"
+SRC_URI[sha256sum] = "2a7924449a03025faf7f8754a6f4200001cab210734a6ce6ac1f6bdacd3a68e4"
 
 PYPI_PACKAGE = "cryptography_vectors"
 
-- 
2.25.1

[PATCH 2/2] python3-cryptography: enforce identical version for -cryptography-vectors

[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 \
-- 
2.25.1

Re: [OE-core] [PATCH 2/2] python3-cryptography: enforce identical version for -cryptography-vectors

[Markus Volk]

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]
> -=-=-=-=-=-=-=-=-=-=-=-
>

Re: [OE-core] [PATCH 1/2] python3-cryptography-vectors: upgrade to 36.0.2

[Khem Raj]

On Thu, Mar 17, 2022 at 9:44 AM Ross Burton <ross@burtonini.com> wrote:
>
> This needs to be upgraded in lockstep with python3-cryptography.
>
> Signed-off-by: Ross Burton <ross.burton@arm.com>
> ---
>  ...vectors_36.0.1.bb => python3-cryptography-vectors_36.0.2.bb} | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>  rename meta/recipes-devtools/python/{python3-cryptography-vectors_36.0.1.bb => python3-cryptography-vectors_36.0.2.bb} (90%)
>
> diff --git a/meta/recipes-devtools/python/python3-cryptography-vectors_36.0.1.bb b/meta/recipes-devtools/python/python3-cryptography-vectors_36.0.2.bb
> similarity index 90%
> rename from meta/recipes-devtools/python/python3-cryptography-vectors_36.0.1.bb
> rename to meta/recipes-devtools/python/python3-cryptography-vectors_36.0.2.bb
> index da6718fb90..be0eda056e 100644
> --- a/meta/recipes-devtools/python/python3-cryptography-vectors_36.0.1.bb
> +++ b/meta/recipes-devtools/python/python3-cryptography-vectors_36.0.2.bb
> @@ -9,7 +9,7 @@ LIC_FILES_CHKSUM = "file://LICENSE;md5=8c3617db4fb6fae01f1d253ab91511e4 \
>  # NOTE: Make sure to keep this recipe at the same version as python3-cryptography
>  #       Upgrade both recipes at the same time
>
> -SRC_URI[sha256sum] = "fc8490afd5424342b868215435bd174dcd76ab396b4ea9435498be5721dcd598"
> +SRC_URI[sha256sum] = "2a7924449a03025faf7f8754a6f4200001cab210734a6ce6ac1f6bdacd3a68e4"
>

I think mine here [1] is better since it bumps up libc crate which
enables riscv64 as well

[1] https://patchwork.yoctoproject.org/project/oe-core/patch/20220316222526.264261-1-raj.khem@gmail.com/

>  PYPI_PACKAGE = "cryptography_vectors"
>
> --
> 2.25.1
>
>
> -=-=-=-=-=-=-=-=-=-=-=-
> Links: You receive all messages sent to this group.
> View/Reply Online (#163425): https://lists.openembedded.org/g/openembedded-core/message/163425
> Mute This Topic: https://lists.openembedded.org/mt/89849716/1997914
> Group Owner: openembedded-core+owner@lists.openembedded.org
> Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [raj.khem@gmail.com]
> -=-=-=-=-=-=-=-=-=-=-=-
>

Re: [OE-core] [PATCH 2/2] python3-cryptography: enforce identical version for -cryptography-vectors

[Martin Jansa]

[-- Attachment #1: Type: text/plain, Size: 2715 bytes --]

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]
> -=-=-=-=-=-=-=-=-=-=-=-
>
>

[-- Attachment #2: Type: text/html, Size: 4303 bytes --]

Re: [OE-core] [PATCH 2/2] python3-cryptography: enforce identical version for -cryptography-vectors

[Martin Jansa]

[-- Attachment #1: Type: text/plain, Size: 3754 bytes --]

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]
> -=-=-=-=-=-=-=-=-=-=-=-
>
>

[-- Attachment #2: Type: text/html, Size: 5801 bytes --]

Re: [OE-core] [PATCH 2/2] python3-cryptography: enforce identical version for -cryptography-vectors

[Richard Purdie]

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

Re: [OE-core] [PATCH 2/2] python3-cryptography: enforce identical version for -cryptography-vectors

[Martin Jansa]

[-- Attachment #1: Type: text/plain, Size: 1921 bytes --]

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,

[-- Attachment #2: Type: text/html, Size: 2497 bytes --]

Re: [OE-core] [PATCH 2/2] python3-cryptography: enforce identical version for -cryptography-vectors

[Tim Orling]

[-- Attachment #1: Type: text/plain, Size: 2911 bytes --]

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]
> -=-=-=-=-=-=-=-=-=-=-=-
>
>

[-- Attachment #2: Type: text/html, Size: 4563 bytes --]

Re: [OE-core] [PATCH 2/2] python3-cryptography: enforce identical version for -cryptography-vectors

[Richard Purdie]

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