Hello everyone,
As per the F36 schedule [1], rawhide starts F36 development on 2021-08-10. I would like to bring in OpenSSL 3.0.0 [2] and the compat package [3] (along with devel subpackage) into rawhide.
I would like your opinion/suggestion on: 1. Merging it and building it directly in rawhide. This will make OpenSSL 3.0.0 available by default for immediate use in rawhide. FTBFS bugs can be reported when there is a mass-rebuild as per [1] versus 2. Building it in a side-tag, adding all packages. Allowing the packages to port and fix build failures on the side-tag and finally merge the side-tag. FTBFS bugs can be reported immediately.
I have a slight preference for option 1:
1. As rawhide enables us to try out stuff like this. 2. It is very early in the cycle to bring this change. 3. Many upstream packages have been ported (or are in the process of porting) to OpenSSL 3.0.0 4. Compat package (rebased to 1.1.1k version) is available with devel files.
Although option 2 sounds more organized.
But I could be missing some information/details. It would be nice to hear about the experiences in the past and the preferred method by the community.
COPR repo [4] is updated with openssl-3.0.0-beta2. Change proposal [5] is updated for F36.
[1] https://fedorapeople.org/groups/schedule/f-36/f-36-key-tasks.html [2] https://src.fedoraproject.org/fork/saprasad/rpms/openssl/tree/rawhide [3] https://src.fedoraproject.org/fork/saprasad/rpms/openssl1.1/tree/rawhide [4] https://copr.fedorainfracloud.org/coprs/saprasad/openssl-3.0/builds/ [5] https://fedoraproject.org/wiki/Changes/OpenSSL3.0
Thank you, Regards Sahana Prasad
On 05. 08. 21 11:03, Sahana Prasad wrote:
Hello everyone,
As per the F36 schedule [1], rawhide starts F36 development on 2021-08-10. I would like to bring in OpenSSL 3.0.0 [2] and the compat package [3] (along with devel subpackage) into rawhide.
I would like your opinion/suggestion on:
- Merging it and building it directly in rawhide. This will make OpenSSL 3.0.0
available by default for immediate use in rawhide. FTBFS bugs can be reported when there is a mass-rebuild as per [1] versus 2. Building it in a side-tag, adding all packages. Allowing the packages to port and fix build failures on the side-tag and finally merge the side-tag. FTBFS bugs can be reported immediately.
I have a slight preference for option 1:
- As rawhide enables us to try out stuff like this.
- It is very early in the cycle to bring this change.
- Many upstream packages have been ported (or are in the process of porting) to
OpenSSL 3.0.0 4. Compat package (rebased to 1.1.1k version) is available with devel files.
Although option 2 sounds more organized.
But I could be missing some information/details. It would be nice to hear about the experiences in the past and the preferred method by the community.
Is it not probable that when the rebuilds happen gradually, weird stuff will happen?
E.g. when:
- python links to libopenssl 3 - libdnf or similar links to openssl 1.x
An application, such as dnf, uses both. Can that be a problem?
----
To minimize unknown problems like this, I suggest to:
1. define a minimal acceptance criteria (e.g. "dnf works") 2. test (1) in copr, do not open the side tag until verified there 3. open a side tag 4. build openssl 3 in it 5. build as much packages linking to openssl in it as possible 6. verify (1), improvise until it is a success 7. merge the side tag 8. rebuild "misfits" once again (packages that succeeded in (5) but packagers rebuilt them in regular rawhide while the side tag was open)
This is different from your proposed side tag solution because there is no window left for "allowing the packages to port and fix build failures on the side-tag". Side tags are painful when opened for a long.
IMHO This combines benefits of both of your solutions:
- it is fast - it is more or less atomic, sans the packages that FTBFS
On Thu, Aug 5, 2021 at 11:51 AM Miro Hrončok mhroncok@redhat.com wrote:
On 05. 08. 21 11:03, Sahana Prasad wrote:
Hello everyone,
As per the F36 schedule [1], rawhide starts F36 development on
2021-08-10.
I would like to bring in OpenSSL 3.0.0 [2] and the compat package [3]
(along
with devel subpackage) into rawhide.
I would like your opinion/suggestion on:
- Merging it and building it directly in rawhide. This will make
OpenSSL 3.0.0
available by default for immediate use in rawhide. FTBFS bugs can be reported when there is a mass-rebuild as per [1] versus 2. Building it in a side-tag, adding all packages. Allowing the packages
to
port and fix build failures on the side-tag and finally merge the side-tag. FTBFS bugs can be
reported
immediately.
I have a slight preference for option 1:
- As rawhide enables us to try out stuff like this.
- It is very early in the cycle to bring this change.
- Many upstream packages have been ported (or are in the process of
porting) to
OpenSSL 3.0.0 4. Compat package (rebased to 1.1.1k version) is available with devel
files.
Although option 2 sounds more organized.
But I could be missing some information/details. It would be nice to
hear about
the experiences in the past and the preferred method by the community.
Is it not probable that when the rebuilds happen gradually, weird stuff will happen?
E.g. when:
- python links to libopenssl 3
- libdnf or similar links to openssl 1.x
An application, such as dnf, uses both. Can that be a problem?
To minimize unknown problems like this, I suggest to:
- define a minimal acceptance criteria (e.g. "dnf works")
- test (1) in copr, do not open the side tag until verified there
- open a side tag
- build openssl 3 in it
- build as much packages linking to openssl in it as possible
- verify (1), improvise until it is a success
- merge the side tag
- rebuild "misfits" once again (packages that succeeded in (5) but
packagers rebuilt them in regular rawhide while the side tag was open)
Thank you for these helpful steps Miro. I'll follow them.
This is different from your proposed side tag solution because there is no window left for "allowing the packages to port and fix build failures on the side-tag". Side tags are painful when opened for a long.
IMHO This combines benefits of both of your solutions:
- it is fast
- it is more or less atomic, sans the packages that FTBFS
Yes, I agree.
Thank you, Regards, Sahana Prasad
-- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok
On Thu, Aug 5, 2021 at 11:51 AM Miro Hrončok mhroncok@redhat.com wrote:
On 05. 08. 21 11:03, Sahana Prasad wrote:
Hello everyone,
As per the F36 schedule [1], rawhide starts F36 development on
2021-08-10.
I would like to bring in OpenSSL 3.0.0 [2] and the compat package [3]
(along
with devel subpackage) into rawhide.
I would like your opinion/suggestion on:
- Merging it and building it directly in rawhide. This will make
OpenSSL 3.0.0
available by default for immediate use in rawhide. FTBFS bugs can be reported when there is a mass-rebuild as per [1] versus 2. Building it in a side-tag, adding all packages. Allowing the packages
to
port and fix build failures on the side-tag and finally merge the side-tag. FTBFS bugs can be
reported
immediately.
I have a slight preference for option 1:
- As rawhide enables us to try out stuff like this.
- It is very early in the cycle to bring this change.
- Many upstream packages have been ported (or are in the process of
porting) to
OpenSSL 3.0.0 4. Compat package (rebased to 1.1.1k version) is available with devel
files.
Although option 2 sounds more organized.
But I could be missing some information/details. It would be nice to
hear about
the experiences in the past and the preferred method by the community.
Is it not probable that when the rebuilds happen gradually, weird stuff will happen?
E.g. when:
- python links to libopenssl 3
- libdnf or similar links to openssl 1.x
An application, such as dnf, uses both. Can that be a problem?
To minimize unknown problems like this, I suggest to:
- define a minimal acceptance criteria (e.g. "dnf works")
- test (1) in copr, do not open the side tag until verified there
- open a side tag
- build openssl 3 in it
- build as much packages linking to openssl in it as possible
- verify (1), improvise until it is a success
- merge the side tag
- rebuild "misfits" once again (packages that succeeded in (5) but
packagers rebuilt them in regular rawhide while the side tag was open)
Hello everyone,
I will follow these steps and start working on it tomorrow onwards.
Thank you, Regards, Sahana Prasad
This is different from your proposed side tag solution because there is no window left for "allowing the packages to port and fix build failures on the side-tag". Side tags are painful when opened for a long.
IMHO This combines benefits of both of your solutions:
- it is fast
- it is more or less atomic, sans the packages that FTBFS
-- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok
Hi everyone,
No major progress on this task yet. I found out that the compat package needs some more fixing. I have more time in the coming days, so I should have an update soon hopefully.
Thank you, Regards, Sahana Prasad
On Tue, Aug 10, 2021 at 7:57 PM Sahana Prasad sahana@redhat.com wrote:
On Thu, Aug 5, 2021 at 11:51 AM Miro Hrončok mhroncok@redhat.com wrote:
On 05. 08. 21 11:03, Sahana Prasad wrote:
Hello everyone,
As per the F36 schedule [1], rawhide starts F36 development on
2021-08-10.
I would like to bring in OpenSSL 3.0.0 [2] and the compat package [3]
(along
with devel subpackage) into rawhide.
I would like your opinion/suggestion on:
- Merging it and building it directly in rawhide. This will make
OpenSSL 3.0.0
available by default for immediate use in rawhide. FTBFS bugs can be reported when there is a mass-rebuild as per [1] versus 2. Building it in a side-tag, adding all packages. Allowing the
packages to
port and fix build failures on the side-tag and finally merge the side-tag. FTBFS bugs can be
reported
immediately.
I have a slight preference for option 1:
- As rawhide enables us to try out stuff like this.
- It is very early in the cycle to bring this change.
- Many upstream packages have been ported (or are in the process of
porting) to
OpenSSL 3.0.0 4. Compat package (rebased to 1.1.1k version) is available with devel
files.
Although option 2 sounds more organized.
But I could be missing some information/details. It would be nice to
hear about
the experiences in the past and the preferred method by the community.
Is it not probable that when the rebuilds happen gradually, weird stuff will happen?
E.g. when:
- python links to libopenssl 3
- libdnf or similar links to openssl 1.x
An application, such as dnf, uses both. Can that be a problem?
To minimize unknown problems like this, I suggest to:
- define a minimal acceptance criteria (e.g. "dnf works")
- test (1) in copr, do not open the side tag until verified there
- open a side tag
- build openssl 3 in it
- build as much packages linking to openssl in it as possible
- verify (1), improvise until it is a success
- merge the side tag
- rebuild "misfits" once again (packages that succeeded in (5) but
packagers rebuilt them in regular rawhide while the side tag was open)
Hello everyone,
I will follow these steps and start working on it tomorrow onwards.
Thank you, Regards, Sahana Prasad
This is different from your proposed side tag solution because there is no window left for "allowing the packages to port and fix build failures on the side-tag". Side tags are painful when opened for a long.
IMHO This combines benefits of both of your solutions:
- it is fast
- it is more or less atomic, sans the packages that FTBFS
-- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok
On Wed, Aug 18, 2021 at 3:55 PM Sahana Prasad sahana@redhat.com wrote:
Hi everyone,
No major progress on this task yet. I found out that the compat package needs some more fixing. I have more time in the coming days, so I should have an update soon hopefully.
Let us know if you need help with getting the compat stuff fixed up. We're happy to help! :)
On Wed, Aug 18, 2021 at 11:11 PM Neal Gompa ngompa13@gmail.com wrote:
On Wed, Aug 18, 2021 at 3:55 PM Sahana Prasad sahana@redhat.com wrote:
Hi everyone,
No major progress on this task yet. I found out that the compat package needs some more fixing. I have more time in the coming days, so I should have an update soon hopefully.
Let us know if you need help with getting the compat stuff fixed up. We're happy to help! :)
Thanks Neal. It is fixed now and dnf builds well with it and OpenSSL 3.0 in my copr repo. Performing some more tests now.
Thank you, Regards, Sahana Prasad
-- 真実はいつも一つ！/ Always, there's only one truth! _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Hi everyone,
dnf builds well after building all OpenSSL dependent packages (in batches) with the compat package and OpenSSL 3.0.0 beta2 version. You can have a look at [1] with the side-tag f36-build-side-44794
I think we are in a good state to merge OpenSSL 3.0.0 and compat packages into rawhide. Let me know if you think otherwise.
(There are some failing packages, that need to be looked at by respective maintainers)
[1] https://koji.fedoraproject.org/koji/tasks?start=0&owner=saprasad&sta...
Thank you, Regards, Sahana Prasad
On Fri, Aug 20, 2021 at 11:36 AM Sahana Prasad sahana@redhat.com wrote:
On Wed, Aug 18, 2021 at 11:11 PM Neal Gompa ngompa13@gmail.com wrote:
On Wed, Aug 18, 2021 at 3:55 PM Sahana Prasad sahana@redhat.com wrote:
Hi everyone,
No major progress on this task yet. I found out that the compat package needs some more fixing. I have more time in the coming days, so I should have an update soon hopefully.
Let us know if you need help with getting the compat stuff fixed up. We're happy to help! :)
Thanks Neal. It is fixed now and dnf builds well with it and OpenSSL 3.0 in my copr repo. Performing some more tests now.
Thank you, Regards, Sahana Prasad
-- 真実はいつも一つ！/ Always, there's only one truth! _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
On 31. 08. 21 11:17, Sahana Prasad wrote:
Hi everyone,
dnf builds well after building all OpenSSL dependent packages (in batches) with the compat package and OpenSSL 3.0.0 beta2 version. You can have a look at [1] with the side-tag f36-build-side-44794
Hello Sahana,
I am afraid the side tag has no builds in it:
https://koji.fedoraproject.org/koji/builds?inherited=0&tagID=44794&o...
So when you built scratch builds in it:
https://koji.fedoraproject.org/koji/tasks?start=0&owner=saprasad&sta...
They all built with openssl 1:1.1.1k-2.fc35.
Scratch builds don't "see each other".
On Tue, Aug 31, 2021 at 12:02 PM Miro Hrončok mhroncok@redhat.com wrote:
On 31. 08. 21 11:17, Sahana Prasad wrote:
Hi everyone,
dnf builds well after building all OpenSSL dependent packages (in
batches)
with the compat package and OpenSSL 3.0.0 beta2 version. You can have a look at [1] with the side-tag f36-build-side-44794
Hello Sahana,
I am afraid the side tag has no builds in it:
https://koji.fedoraproject.org/koji/builds?inherited=0&tagID=44794&o...
Thanks Miro, I'll check and fix it.
So when you built scratch builds in it:
https://koji.fedoraproject.org/koji/tasks?start=0&owner=saprasad&sta...
They all built with openssl 1:1.1.1k-2.fc35.
Scratch builds don't "see each other".
-- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok
Hi all,
An update that I will directly bring in the OpenSSL 3.0.0 final RC (released upstream yesterday) into rawhide in the next few days. (Compared to beta2, this version has one moderate CVE-2021-3712 fix in addition to other fixes.)
Thank you, Regards, Sahana Prasad
On Tue, Aug 31, 2021 at 12:21 PM Sahana Prasad sahana@redhat.com wrote:
On Tue, Aug 31, 2021 at 12:02 PM Miro Hrončok mhroncok@redhat.com wrote:
On 31. 08. 21 11:17, Sahana Prasad wrote:
Hi everyone,
dnf builds well after building all OpenSSL dependent packages (in
batches)
with the compat package and OpenSSL 3.0.0 beta2 version. You can have a look at [1] with the side-tag f36-build-side-44794
Hello Sahana,
I am afraid the side tag has no builds in it:
https://koji.fedoraproject.org/koji/builds?inherited=0&tagID=44794&o...
Thanks Miro, I'll check and fix it.
So when you built scratch builds in it:
https://koji.fedoraproject.org/koji/tasks?start=0&owner=saprasad&sta...
They all built with openssl 1:1.1.1k-2.fc35.
Scratch builds don't "see each other".
-- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok
Hi,
Sahana Prasad sahana@redhat.com writes:
An update that I will directly bring in the OpenSSL 3.0.0 final RC (released upstream yesterday)
Thanks for doing this!
I read the upstream announcement and it certainly reads like it's the final/GA release, not an RC:
https://www.openssl.org/blog/blog/2021/09/07/OpenSSL3.Final/
Do you know what's going on? Did they phrase it badly or did they perform multiple releases in parallel?
Thanks, Omair
-- PGP Key: B157A9F0 (http://pgp.mit.edu/) Fingerprint = 9DB5 2F0B FD3E C239 E108 E7BD DF99 7AF8 B157 A9F0
On Wed, Sep 8, 2021 at 4:35 PM Omair Majid omajid@redhat.com wrote:
Hi,
Sahana Prasad sahana@redhat.com writes:
An update that I will directly bring in the OpenSSL 3.0.0 final RC (released upstream yesterday)
Thanks for doing this!
I read the upstream announcement and it certainly reads like it's the final/GA release, not an RC:
https://www.openssl.org/blog/blog/2021/09/07/OpenSSL3.Final/
Do you know what's going on? Did they phrase it badly or did they perform multiple releases in parallel?
Hi Omair,
Sorry I phrased it incorrectly. It is the final major version only, not the RC.
Thank you, Regards, Sahana Prasad
Thanks, Omair
-- PGP Key: B157A9F0 (http://pgp.mit.edu/) Fingerprint = 9DB5 2F0B FD3E C239 E108 E7BD DF99 7AF8 B157 A9F0
Hi all,
The builds of packages that depend on OpenSSL are being rebuilt in the side tag f36-build-side-44794 [1] now.
Note to package maintainers: If you see a "Rebuilt with OpenSSL 3.0.0" commit in your package, do not build it in regular rawhide unless the side tag is merged
[1] https://koji.fedoraproject.org/koji/builds?inherited=0&tagID=44794&o...
Thank you, Regards, Sahana Prasad
On Wed, Sep 8, 2021 at 5:06 PM Sahana Prasad sahana@redhat.com wrote:
On Wed, Sep 8, 2021 at 4:35 PM Omair Majid omajid@redhat.com wrote:
Hi,
Sahana Prasad sahana@redhat.com writes:
An update that I will directly bring in the OpenSSL 3.0.0 final RC (released upstream yesterday)
Thanks for doing this!
I read the upstream announcement and it certainly reads like it's the final/GA release, not an RC:
https://www.openssl.org/blog/blog/2021/09/07/OpenSSL3.Final/
Do you know what's going on? Did they phrase it badly or did they perform multiple releases in parallel?
Hi Omair,
Sorry I phrased it incorrectly. It is the final major version only, not the RC.
Thank you, Regards, Sahana Prasad
Thanks, Omair
-- PGP Key: B157A9F0 (http://pgp.mit.edu/) Fingerprint = 9DB5 2F0B FD3E C239 E108 E7BD DF99 7AF8 B157 A9F0
On Tue, Sep 14, 2021 at 12:57 PM Sahana Prasad sahana@redhat.com wrote:
Hi all,
The builds of packages that depend on OpenSSL are being rebuilt in the side tag f36-build-side-44794 [1] now.
Note to package maintainers: If you see a "Rebuilt with OpenSSL 3.0.0" commit in your package, do not build it in regular rawhide unless the side tag is merged
[1] https://koji.fedoraproject.org/koji/builds?inherited=0&tagID=44794&o...
I had a build in progress for Node.js with the same release number as your attempt to rebuild for OpenSSL 3.0 in the side-tag. I've merged your changes with mine into the rawhide branch and kicked off a build targeted at f36-build-side-44794. There *shouldn't* be any issues with the upgrade path here, since the Rawhide build I was running was built against OpenSSL 1.1.1 and I bumped the release number for the side-tag build.
On 14. 09. 21 22:52, Stephen Gallagher wrote:
On Tue, Sep 14, 2021 at 12:57 PM Sahana Prasad <sahana@redhat.com mailto:sahana@redhat.com> wrote:
Hi all, The builds of packages that depend on OpenSSL are being rebuilt in the side tag f36-build-side-44794 [1] now. Note to package maintainers: If you see a "Rebuilt with OpenSSL 3.0.0" commit in your package, do not build it in regular rawhide unless the side tag is merged [1] https://koji.fedoraproject.org/koji/builds?inherited=0&tagID=44794&order=-build_id&latest=1 <https://koji.fedoraproject.org/koji/builds?inherited=0&tagID=44794&order=-build_id&latest=1>I had a build in progress for Node.js with the same release number as your attempt to rebuild for OpenSSL 3.0 in the side-tag. I've merged your changes with mine into the rawhide branch and kicked off a build targeted at f36-build-side-44794. There *shouldn't* be any issues with the upgrade path here, since the Rawhide build I was running was built against OpenSSL 1.1.1 and I bumped the release number for the side-tag build.
I wonder how this happened. Was you build with the same release number submitted from another branch than rawhide?
On Tue, Sep 14, 2021 at 5:28 PM Miro Hrončok mhroncok@redhat.com wrote:
On 14. 09. 21 22:52, Stephen Gallagher wrote:
On Tue, Sep 14, 2021 at 12:57 PM Sahana Prasad <sahana@redhat.com mailto:sahana@redhat.com> wrote:
Hi all, The builds of packages that depend on OpenSSL are being rebuilt in the side tag f36-build-side-44794 [1] now. Note to package maintainers: If you see a "Rebuilt with OpenSSL 3.0.0" commit in your package, do not build it in regular rawhide unless the side tag is merged [1] https://koji.fedoraproject.org/koji/builds?inherited=0&tagID=44794&order=-build_id&latest=1 <https://koji.fedoraproject.org/koji/builds?inherited=0&tagID=44794&order=-build_id&latest=1>I had a build in progress for Node.js with the same release number as your attempt to rebuild for OpenSSL 3.0 in the side-tag. I've merged your changes with mine into the rawhide branch and kicked off a build targeted at f36-build-side-44794. There *shouldn't* be any issues with the upgrade path here, since the Rawhide build I was running was built against OpenSSL 1.1.1 and I bumped the release number for the side-tag build.
I wonder how this happened. Was you build with the same release number submitted from another branch than rawhide?
Yes, I built it from the `16` branch (which has a package.cfg that builds it for both Rawhide and F35) and I failed to notice when I merged it to Rawhide that it was behind `origin`. Mine had been started first, so the mass-rebuild attempt was rejected. I just went ahead and bumped the release number again and built it for the side-tag against OpenSSL 3.0, so things should be in the proper state.
Hi Sahana,
it would be nice, if changelog entry contained bug id we could use to watch the progress. Or any other link to some tracker. bind package has a new release, I am preparing update for it, but I am not sure where should I watch for a progress. Even build of openssl itself does not reference any bug. Is there any better tracker than bug #1825937, which I can monitor for progress? Is the koji build the best way to check readiness? Does exist any variant of RHEL9 bug #1958021 https://bugzilla.redhat.com/show_bug.cgi?id=1958021 for Fedora Rawhide?
Is there any expected timeline, how long it might take to merge the side-tag?
Thanks!
Regards, Petr
On 9/14/21 6:56 PM, Sahana Prasad wrote:
Hi all,
The builds of packages that depend on OpenSSL are being rebuilt in the side tag f36-build-side-44794 [1] now.
Note to package maintainers: If you see a "Rebuilt with OpenSSL 3.0.0" commit in your package, do not build it in regular rawhide unless the side tag is merged
[1] https://koji.fedoraproject.org/koji/builds?inherited=0&tagID=44794&o... https://koji.fedoraproject.org/koji/builds?inherited=0&tagID=44794&order=-build_id&latest=1
Thank you, Regards, Sahana Prasad
On Wed, Sep 8, 2021 at 5:06 PM Sahana Prasad <sahana@redhat.com mailto:sahana@redhat.com> wrote:
On Wed, Sep 8, 2021 at 4:35 PM Omair Majid <omajid@redhat.com <mailto:omajid@redhat.com>> wrote: Hi, Sahana Prasad <sahana@redhat.com <mailto:sahana@redhat.com>> writes: > An update that I will directly bring in the OpenSSL 3.0.0 final RC > (released upstream yesterday) Thanks for doing this! I read the upstream announcement and it certainly reads like it's the final/GA release, not an RC: https://www.openssl.org/blog/blog/2021/09/07/OpenSSL3.Final/ <https://www.openssl.org/blog/blog/2021/09/07/OpenSSL3.Final/> Do you know what's going on? Did they phrase it badly or did they perform multiple releases in parallel? Hi Omair, Sorry I phrased it incorrectly. It is the final major version only, not the RC. Thank you, Regards, Sahana Prasad Thanks, Omair -- PGP Key: B157A9F0 (http://pgp.mit.edu/ <http://pgp.mit.edu/>) Fingerprint = 9DB5 2F0B FD3E C239 E108 E7BD DF99 7AF8 B157 A9F0
devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Dne 15. 09. 21 v 12:57 Petr Menšík napsal(a):
Hi Sahana,
it would be nice, if changelog entry contained bug id we could use to watch the progress.
The commit message should contain reference to the change proposal IMO
Vít
Or any other link to some tracker. bind package has a new release, I am preparing update for it, but I am not sure where should I watch for a progress. Even build of openssl itself does not reference any bug. Is there any better tracker than bug #1825937, which I can monitor for progress? Is the koji build the best way to check readiness? Does exist any variant of RHEL9 bug #1958021 https://bugzilla.redhat.com/show_bug.cgi?id=1958021 for Fedora Rawhide?
Is there any expected timeline, how long it might take to merge the side-tag?
Thanks!
Regards, Petr
On 9/14/21 6:56 PM, Sahana Prasad wrote:
Hi all,
The builds of packages that depend on OpenSSL are being rebuilt in the side tag f36-build-side-44794 [1] now.
Note to package maintainers: If you see a "Rebuilt with OpenSSL 3.0.0" commit in your package, do not build it in regular rawhide unless the side tag is merged
[1] https://koji.fedoraproject.org/koji/builds?inherited=0&tagID=44794&o... https://koji.fedoraproject.org/koji/builds?inherited=0&tagID=44794&order=-build_id&latest=1
Thank you, Regards, Sahana Prasad
On Wed, Sep 8, 2021 at 5:06 PM Sahana Prasad <sahana@redhat.com mailto:sahana@redhat.com> wrote:
On Wed, Sep 8, 2021 at 4:35 PM Omair Majid <omajid@redhat.com <mailto:omajid@redhat.com>> wrote: Hi, Sahana Prasad <sahana@redhat.com <mailto:sahana@redhat.com>> writes: > An update that I will directly bring in the OpenSSL 3.0.0 final RC > (released upstream yesterday) Thanks for doing this! I read the upstream announcement and it certainly reads like it's the final/GA release, not an RC: https://www.openssl.org/blog/blog/2021/09/07/OpenSSL3.Final/ <https://www.openssl.org/blog/blog/2021/09/07/OpenSSL3.Final/> Do you know what's going on? Did they phrase it badly or did they perform multiple releases in parallel? Hi Omair, Sorry I phrased it incorrectly. It is the final major version only, not the RC. Thank you, Regards, Sahana Prasad Thanks, Omair -- PGP Key: B157A9F0 (http://pgp.mit.edu/ <http://pgp.mit.edu/>) Fingerprint = 9DB5 2F0B FD3E C239 E108 E7BD DF99 7AF8 B157 A9F0
devel mailing list --devel@lists.fedoraproject.org To unsubscribe send an email todevel-leave@lists.fedoraproject.org Fedora Code of Conduct:https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines:https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives:https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it:https://pagure.io/fedora-infrastructure
-- Petr Menšík Software Engineer Red Hat,http://www.redhat.com/ email:pemensik@redhat.com PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB
devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
On 15. 09. 21 13:00, Vít Ondruch wrote:
Dne 15. 09. 21 v 12:57 Petr Menšík napsal(a):
Hi Sahana,
it would be nice, if changelog entry contained bug id we could use to watch the progress.
The commit message should contain reference to the change proposal IMO
I've never referenced the Bugzilla ID or change proposal when I've done Python 3.X rebuilds and I have never heard somebody that it mattered to them.
Referencing the change in the commit message is actually a good idea in retrospect. However, referencing a bug ID might create a lot of noise, we once did that here:
https://bugzilla.redhat.com/show_bug.cgi?id=1748018
People kept associating unrelated EPEL updates with this for months, as "fedpkg update" or some other clever thing automatically added that bug ID to them.
On 9/15/21 1:54 PM, Miro Hrončok wrote:
On 15. 09. 21 13:00, Vít Ondruch wrote:
Dne 15. 09. 21 v 12:57 Petr Menšík napsal(a):
Hi Sahana,
it would be nice, if changelog entry contained bug id we could use to watch the progress.
The commit message should contain reference to the change proposal IMO
Yes, something similar to mass rebuilds before new release. They also have URL to details. I think all non-maintainer commits should have some reference to details, why is it done.
I've never referenced the Bugzilla ID or change proposal when I've done Python 3.X rebuilds and I have never heard somebody that it mattered to them.
Referencing the change in the commit message is actually a good idea in retrospect. However, referencing a bug ID might create a lot of noise, we once did that here:
This bug is something I had on mind. But I would expect it would be only used as Depends: field on bugs filled to failed components. I were looking for a bug number to add to block
People kept associating unrelated EPEL updates with this for months, as "fedpkg update" or some other clever thing automatically added that bug ID to them.
Indeed, there were a lot of EPEL builds referencing Fedora bug. If that were done by any existing tool, it should be fixed. I doubt we ever want EPEL builds to directly reference Fedora builds. It might be done in rare cases by a person, but I doubt it should ever be done by any automated tool. Maybe if it had bug cloned to EPEL, it might followed clone with matching product for the build.
I think we miss here way to make that bug only related. It might be added to bodhi updates of such builds, but it should not switch state of referenced bug in any way, let alone close it. It should just be clickable link from bodhi update. It should be considered only as indication similar problem had multiple packages. Would such feature make sense also to others?
Cheers, Petr
On Wed, Sep 15, 2021 at 12:57 PM Petr Menšík pemensik@redhat.com wrote:
Hi Sahana,
it would be nice, if changelog entry contained bug id we could use to watch the progress. Or any other link to some tracker. bind package has a new release, I am preparing update for it, but I am not sure where should I watch for a progress. Even build of openssl itself does not reference any bug. Is there any better tracker than bug #1825937, which I can monitor for progress? Is the koji build the best way to check readiness? Does exist any variant of RHEL9 bug #1958021 https://bugzilla.redhat.com/show_bug.cgi?id=1958021 for Fedora Rawhide?
Is there any expected timeline, how long it might take to merge the side-tag?
Hi Petr,
I have merged the side-tag [1]. I would however need karma for it to get to stable.
https://bodhi.fedoraproject.org/updates/FEDORA-2021-ee8c904f46
I will send a list of the failed packages shortly.
Thank you, Regards, Sahana Prasad
Thanks!
Regards, Petr On 9/14/21 6:56 PM, Sahana Prasad wrote:
Hi all,
The builds of packages that depend on OpenSSL are being rebuilt in the side tag f36-build-side-44794 [1] now.
Note to package maintainers: If you see a "Rebuilt with OpenSSL 3.0.0" commit in your package, do not build it in regular rawhide unless the side tag is merged
[1] https://koji.fedoraproject.org/koji/builds?inherited=0&tagID=44794&o...
Thank you, Regards, Sahana Prasad
On Wed, Sep 8, 2021 at 5:06 PM Sahana Prasad sahana@redhat.com wrote:
On Wed, Sep 8, 2021 at 4:35 PM Omair Majid omajid@redhat.com wrote:
Hi,
Sahana Prasad sahana@redhat.com writes:
An update that I will directly bring in the OpenSSL 3.0.0 final RC (released upstream yesterday)
Thanks for doing this!
I read the upstream announcement and it certainly reads like it's the final/GA release, not an RC:
https://www.openssl.org/blog/blog/2021/09/07/OpenSSL3.Final/
Do you know what's going on? Did they phrase it badly or did they perform multiple releases in parallel?
Hi Omair,
Sorry I phrased it incorrectly. It is the final major version only, not the RC.
Thank you, Regards, Sahana Prasad
Thanks, Omair
-- PGP Key: B157A9F0 (http://pgp.mit.edu/) Fingerprint = 9DB5 2F0B FD3E C239 E108 E7BD DF99 7AF8 B157 A9F0
devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
-- Petr Menšík Software Engineer Red Hat, http://www.redhat.com/ email: pemensik@redhat.com PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB
On Wed, Sep 15, 2021 at 7:54 PM Sahana Prasad sahana@redhat.com wrote:
On Wed, Sep 15, 2021 at 12:57 PM Petr Menšík pemensik@redhat.com wrote:
Hi Sahana,
it would be nice, if changelog entry contained bug id we could use to watch the progress. Or any other link to some tracker. bind package has a new release, I am preparing update for it, but I am not sure where should I watch for a progress. Even build of openssl itself does not reference any bug. Is there any better tracker than bug #1825937, which I can monitor for progress? Is the koji build the best way to check readiness? Does exist any variant of RHEL9 bug #1958021 for Fedora Rawhide?
Is there any expected timeline, how long it might take to merge the side-tag?
Hi Petr,
I have merged the side-tag [1]. I would however need karma for it to get to stable.
https://bodhi.fedoraproject.org/updates/FEDORA-2021-ee8c904f46
I will send a list of the failed packages shortly.
Updates for rawhide do not need karma to get pushed to stable. Right now, the update is only stuck in "pending" because some koji builds are still getting signed. Once that's done, it will get pushed to stable automatically (assuming there are no failed gating tests).
Fabio
On Wed, Sep 15, 2021 at 7:56 PM Fabio Valentini decathorpe@gmail.com wrote:
On Wed, Sep 15, 2021 at 7:54 PM Sahana Prasad sahana@redhat.com wrote:
On Wed, Sep 15, 2021 at 12:57 PM Petr Menšík pemensik@redhat.com wrote:
Hi Sahana,
it would be nice, if changelog entry contained bug id we could use to watch the progress. Or any other link to some tracker. bind package has a new release, I am preparing update for it, but I am not sure where should I watch for a progress. Even build of openssl itself does not reference any bug. Is there any better tracker than bug #1825937, which I can monitor for progress? Is the koji build the best way to check readiness? Does exist any variant of RHEL9 bug #1958021 for Fedora Rawhide?
Is there any expected timeline, how long it might take to merge the side-tag?
Hi Petr,
I have merged the side-tag [1]. I would however need karma for it to get to stable.
https://bodhi.fedoraproject.org/updates/FEDORA-2021-ee8c904f46
I will send a list of the failed packages shortly.
Updates for rawhide do not need karma to get pushed to stable. Right now, the update is only stuck in "pending" because some koji builds are still getting signed. Once that's done, it will get pushed to stable automatically (assuming there are no failed gating tests).
However, it looks like one build (collectd-5.12.0-9.fc36) is stuck without getting signed: https://koji.fedoraproject.org/koji/buildinfo?buildID=1831700
Maybe somebody needs to poke koji / robosignatory / sigul / <insert another alphabet soup fedora-infra service here>.
Fabio
On Wed, Sep 15, 2021 at 10:28:44PM +0200, Fabio Valentini wrote:
However, it looks like one build (collectd-5.12.0-9.fc36) is stuck without getting signed: https://koji.fedoraproject.org/koji/buildinfo?buildID=1831700
Maybe somebody needs to poke koji / robosignatory / sigul / <insert another alphabet soup fedora-infra service here>.
Ha. It would be robosignatory.
I just retagged the package and it seems to have been signed now. (well, is being signed as I type this, it has a lot of subpackages)
kevin
On Wed, Sep 15, 2021 at 11:06 PM Kevin Fenzi kevin@scrye.com wrote:
On Wed, Sep 15, 2021 at 10:28:44PM +0200, Fabio Valentini wrote:
However, it looks like one build (collectd-5.12.0-9.fc36) is stuck without getting signed: https://koji.fedoraproject.org/koji/buildinfo?buildID=1831700
Maybe somebody needs to poke koji / robosignatory / sigul / <insert another alphabet soup fedora-infra service here>.
Ha. It would be robosignatory.
I just retagged the package and it seems to have been signed now. (well, is being signed as I type this, it has a lot of subpackages)
Thanks, that did the trick. But of course somebody built stuff during the side-tag window and now it can't be pushed. *le big sigh* According to bodhi, createrepo_c and curl are newer in f36, and probably need to be rebuilt again?
Fabio
On Wed, Sep 15, 2021 at 9:40 PM Fabio Valentini decathorpe@gmail.com wrote:
Thanks, that did the trick. But of course somebody built stuff during the side-tag window and now it can't be pushed. *le big sigh*
This seems to happen every time there is a large(ish) side-tag. I do wish that (probably using a server side git push hook) there was a `fedpkg lock` command that would block accidental pushes for the appropriate branch due to various missed emails, or automated activities (with the corresponding `fedpkg unlock` of course). Ah well, one can dream.
On Wed, Sep 15, 2021 at 10:26 PM Gary Buhrmaster gary.buhrmaster@gmail.com wrote:
On Wed, Sep 15, 2021 at 9:40 PM Fabio Valentini decathorpe@gmail.com wrote:
Thanks, that did the trick. But of course somebody built stuff during the side-tag window and now it can't be pushed. *le big sigh*
This seems to happen every time there is a large(ish) side-tag. I do wish that (probably using a server side git push hook) there was a `fedpkg lock` command that would block accidental pushes for the appropriate branch due to various missed emails, or automated activities (with the corresponding `fedpkg unlock` of course). Ah well, one can dream.
It's *possible*. Pagure Dist-Git[0] dynamically generates the ACLs from PDC, so if someone wanted to work on PDC to offer an API that could be used to temporarily close a branch until a certain date passed or until a side-tag was merged (obviously by listening to fedora messaging queue for it), then fedpkg could be extended to offer "fedpkg lock" to lock rawhide branches temporarily accordingly.
The problem is that PDC has been a dead project since early 2018[1] (just shortly after Pagure went into production at the end of 2017). So despite being made extremely critical to our infrastructure, unless someone has the chops to extend the codebase themselves, the other pieces will never gain the necessary capabilities.
[0]: https://pagure.io/pagure-dist-git [1]: https://github.com/product-definition-center/product-definition-center/commi...
On Wed, Sep 15, 2021 at 11:54 AM Sahana Prasad sahana@redhat.com wrote:
I will send a list of the failed packages shortly.
I have been in contact with pl's upstream about its build failure:
https://github.com/SWI-Prolog/packages-ssl/issues/160
I have a workaround ready to go as soon as the merge into Rawhide is complete.
On Wed, Sep 15, 2021 at 07:53:46PM +0200, Sahana Prasad wrote:
On Wed, Sep 15, 2021 at 12:57 PM Petr Menšík pemensik@redhat.com wrote:
Hi Sahana,
it would be nice, if changelog entry contained bug id we could use to watch the progress. Or any other link to some tracker. bind package has a new release, I am preparing update for it, but I am not sure where should I watch for a progress. Even build of openssl itself does not reference any bug. Is there any better tracker than bug #1825937, which I can monitor for progress? Is the koji build the best way to check readiness? Does exist any variant of RHEL9 bug #1958021 https://bugzilla.redhat.com/show_bug.cgi?id=1958021 for Fedora Rawhide?
Is there any expected timeline, how long it might take to merge the side-tag?
Hi Petr,
I have merged the side-tag [1]. I would however need karma for it to get to stable.
https://bodhi.fedoraproject.org/updates/FEDORA-2021-ee8c904f46
I will send a list of the failed packages shortly.
systemd was built into the side-tag yesterday [1], but doesn't appear in the update…
[1] https://koji.fedoraproject.org/koji/buildinfo?buildID=1832196
Zbyszek
On Thu, Sep 16, 2021 at 08:13:08AM +0000, Zbigniew Jędrzejewski-Szmek wrote:
On Wed, Sep 15, 2021 at 07:53:46PM +0200, Sahana Prasad wrote:
On Wed, Sep 15, 2021 at 12:57 PM Petr Menšík pemensik@redhat.com wrote:
Hi Sahana,
it would be nice, if changelog entry contained bug id we could use to watch the progress. Or any other link to some tracker. bind package has a new release, I am preparing update for it, but I am not sure where should I watch for a progress. Even build of openssl itself does not reference any bug. Is there any better tracker than bug #1825937, which I can monitor for progress? Is the koji build the best way to check readiness? Does exist any variant of RHEL9 bug #1958021 https://bugzilla.redhat.com/show_bug.cgi?id=1958021 for Fedora Rawhide?
Is there any expected timeline, how long it might take to merge the side-tag?
Hi Petr,
I have merged the side-tag [1]. I would however need karma for it to get to stable.
https://bodhi.fedoraproject.org/updates/FEDORA-2021-ee8c904f46
I will send a list of the failed packages shortly.
systemd was built into the side-tag yesterday [1], but doesn't appear in the update…
[1] https://koji.fedoraproject.org/koji/buildinfo?buildID=1832196
Oh, I see it finished building after you merged the tag. Dunno, maybe the update should be updated?
--
Another issue: the update has 1006 "automated tests", out of which 1001 fail! I think is very wrong with "automated tests" is the out-of-the-box success rate is below 0.005%.
Error: Problem: conflicting requests - nothing provides libcrypto.so.3()(64bit) needed by zola-0.12.2-8.fc36.x86_64 - nothing provides libcrypto.so.3(OPENSSL_3.0.0)(64bit) needed by zola-0.12.2-8.fc36.x86_64 - nothing provides libssl.so.3()(64bit) needed by zola-0.12.2-8.fc36.x86_64 - nothing provides libssl.so.3(OPENSSL_3.0.0)(64bit) needed by zola-0.12.2-8.fc36.x86_64 (try to add '--skip-broken' to skip uninstallable packages) Installation of zola-0:0.12.2-8.fc36.x86_64 failed.
So... is the test ignoring the fact that the package is part of an update and trying to install rpms individually?
Zbyszek
On Thu, Sep 16, 2021 at 08:20:06AM +0000, Zbigniew Jędrzejewski-Szmek wrote:
On Thu, Sep 16, 2021 at 08:13:08AM +0000, Zbigniew Jędrzejewski-Szmek wrote:
On Wed, Sep 15, 2021 at 07:53:46PM +0200, Sahana Prasad wrote:
On Wed, Sep 15, 2021 at 12:57 PM Petr Menšík pemensik@redhat.com wrote:
Hi Sahana,
it would be nice, if changelog entry contained bug id we could use to watch the progress. Or any other link to some tracker. bind package has a new release, I am preparing update for it, but I am not sure where should I watch for a progress. Even build of openssl itself does not reference any bug. Is there any better tracker than bug #1825937, which I can monitor for progress? Is the koji build the best way to check readiness? Does exist any variant of RHEL9 bug #1958021 https://bugzilla.redhat.com/show_bug.cgi?id=1958021 for Fedora Rawhide?
Is there any expected timeline, how long it might take to merge the side-tag?
Hi Petr,
I have merged the side-tag [1]. I would however need karma for it to get to stable.
https://bodhi.fedoraproject.org/updates/FEDORA-2021-ee8c904f46
I will send a list of the failed packages shortly.
systemd was built into the side-tag yesterday [1], but doesn't appear in the update…
[1] https://koji.fedoraproject.org/koji/buildinfo?buildID=1832196
Oh, I see it finished building after you merged the tag. Dunno, maybe the update should be updated?
--
Another issue: the update has 1006 "automated tests", out of which 1001 fail! I think is very wrong with "automated tests" is the out-of-the-box success rate is below 0.005%.
Error: Problem: conflicting requests
- nothing provides libcrypto.so.3()(64bit) needed by zola-0.12.2-8.fc36.x86_64
- nothing provides libcrypto.so.3(OPENSSL_3.0.0)(64bit) needed by zola-0.12.2-8.fc36.x86_64
- nothing provides libssl.so.3()(64bit) needed by zola-0.12.2-8.fc36.x86_64
- nothing provides libssl.so.3(OPENSSL_3.0.0)(64bit) needed by zola-0.12.2-8.fc36.x86_64
(try to add '--skip-broken' to skip uninstallable packages) Installation of zola-0:0.12.2-8.fc36.x86_64 failed.
So... is the test ignoring the fact that the package is part of an update and trying to install rpms individually?
Another one (https://osci-jenkins-1.ci.fedoraproject.org/job/fedora-ci/job/rpminspect-pip...)
""" Error Message Test "/annocheck" failed. Find out more about this test in the documentation: https://github.com/rpminspect/rpminspect#rpminspect Found a bug? Please open an issue in the issue tracker: https://pagure.io/fedora-ci/general/issues """
How on earth are we supposed to figure out what annocheck doesn't like? There's 185328 bytes of "Standard Output" that follows…
Zbyszek
Hello all,
The side-tag was merged yesterday. OpenSSL 3.0.0 is available in rawhide now. You can continue to port your changes for OpenSSL 3.0.0 now.
The following packages FTBFS (attached), kindly have a look at them. I haven't reported FTBFS bugs right away. As I know many packages have the porting ready already and they were waiting for 3.0.0 to land in rawhide. Some packages fail due to usage of deprecated functions. Consider treating those warnings as not errors for a quick fix and you could slowly stop using deprecated functions in the future.
Thanks Miro for your help with building packages in the side-tag and getting a list of failed packages.
We will try a rebuild of all these failed packages after 3/4 weeks and report bugs for failing packages then.
Thank you, Regards, Sahana Prasad
On Thu, Sep 16, 2021 at 10:25 AM Zbigniew Jędrzejewski-Szmek < zbyszek@in.waw.pl> wrote:
On Thu, Sep 16, 2021 at 08:20:06AM +0000, Zbigniew Jędrzejewski-Szmek wrote:
On Thu, Sep 16, 2021 at 08:13:08AM +0000, Zbigniew Jędrzejewski-Szmek
wrote:
On Wed, Sep 15, 2021 at 07:53:46PM +0200, Sahana Prasad wrote:
On Wed, Sep 15, 2021 at 12:57 PM Petr Menšík pemensik@redhat.com
wrote:
Hi Sahana,
it would be nice, if changelog entry contained bug id we could use
to
watch the progress. Or any other link to some tracker. bind
package has a
new release, I am preparing update for it, but I am not sure where
should I
watch for a progress. Even build of openssl itself does not
reference any
bug. Is there any better tracker than bug #1825937, which I can
monitor for
progress? Is the koji build the best way to check readiness? Does
exist any
variant of RHEL9 bug #1958021 https://bugzilla.redhat.com/show_bug.cgi?id=1958021 for Fedora
Rawhide?
Is there any expected timeline, how long it might take to merge the side-tag?
Hi Petr,
I have merged the side-tag [1]. I would however need karma for it to get to stable.
https://bodhi.fedoraproject.org/updates/FEDORA-2021-ee8c904f46
I will send a list of the failed packages shortly.
systemd was built into the side-tag yesterday [1], but doesn't appear in the update…
[1] https://koji.fedoraproject.org/koji/buildinfo?buildID=1832196
Oh, I see it finished building after you merged the tag. Dunno, maybe the update should be updated?
--
Another issue: the update has 1006 "automated tests", out of which 1001 fail! I think is very wrong with "automated tests" is the out-of-the-box success rate is below 0.005%.
Error: Problem: conflicting requests
- nothing provides libcrypto.so.3()(64bit) needed by
zola-0.12.2-8.fc36.x86_64
- nothing provides libcrypto.so.3(OPENSSL_3.0.0)(64bit) needed by
zola-0.12.2-8.fc36.x86_64
- nothing provides libssl.so.3()(64bit) needed by
zola-0.12.2-8.fc36.x86_64
- nothing provides libssl.so.3(OPENSSL_3.0.0)(64bit) needed by
zola-0.12.2-8.fc36.x86_64
(try to add '--skip-broken' to skip uninstallable packages) Installation of zola-0:0.12.2-8.fc36.x86_64 failed.
So... is the test ignoring the fact that the package is part of an update and trying to install rpms individually?
Another one ( https://osci-jenkins-1.ci.fedoraproject.org/job/fedora-ci/job/rpminspect-pip... )
""" Error Message Test "/annocheck" failed. Find out more about this test in the documentation: https://github.com/rpminspect/rpminspect#rpminspect Found a bug? Please open an issue in the issue tracker: https://pagure.io/fedora-ci/general/issues """
How on earth are we supposed to figure out what annocheck doesn't like? There's 185328 bytes of "Standard Output" that follows…
Zbyszek _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
On pe, 17 syys 2021, Sahana Prasad wrote:
Hello all,
The side-tag was merged yesterday. OpenSSL 3.0.0 is available in rawhide now. You can continue to port your changes for OpenSSL 3.0.0 now.
The following packages FTBFS (attached), kindly have a look at them. I haven't reported FTBFS bugs right away. As I know many packages have the porting ready already and they were waiting for 3.0.0 to land in rawhide. Some packages fail due to usage of deprecated functions. Consider treating those warnings as not errors for a quick fix and you could slowly stop using deprecated functions in the future.
Thanks Miro for your help with building packages in the side-tag and getting a list of failed packages.
We will try a rebuild of all these failed packages after 3/4 weeks and report bugs for failing packages then.
I did a scratch build for freeipa without any changes and it succeeded: https://koji.fedoraproject.org/koji/taskinfo?taskID=75835593
Side-tag rebuild failed due to nodejs issues which aren't a problem anymore: DEBUG util.py:444: Error: DEBUG util.py:444: Problem: conflicting requests DEBUG util.py:444: - nothing provides /usr/bin/pwsh needed by nodejs-1:16.9.1-3.fc36.s390x DEBUG util.py:446: (try to add '--skip-broken' to skip uninstallable packages)
Looks like we don't need any rebuild this time? FreeIPA doesn't work currently in rawhide due to libdb regression which broke 389-ds installs.
Thank you, Regards, Sahana Prasad
On Thu, Sep 16, 2021 at 10:25 AM Zbigniew Jędrzejewski-Szmek < zbyszek@in.waw.pl> wrote:
On Thu, Sep 16, 2021 at 08:20:06AM +0000, Zbigniew Jędrzejewski-Szmek wrote:
On Thu, Sep 16, 2021 at 08:13:08AM +0000, Zbigniew Jędrzejewski-Szmek
wrote:
On Wed, Sep 15, 2021 at 07:53:46PM +0200, Sahana Prasad wrote:
On Wed, Sep 15, 2021 at 12:57 PM Petr Menšík pemensik@redhat.com
wrote:
Hi Sahana,
it would be nice, if changelog entry contained bug id we could use
to
watch the progress. Or any other link to some tracker. bind
package has a
new release, I am preparing update for it, but I am not sure where
should I
watch for a progress. Even build of openssl itself does not
reference any
bug. Is there any better tracker than bug #1825937, which I can
monitor for
progress? Is the koji build the best way to check readiness? Does
exist any
variant of RHEL9 bug #1958021 https://bugzilla.redhat.com/show_bug.cgi?id=1958021 for Fedora
Rawhide?
Is there any expected timeline, how long it might take to merge the side-tag?
Hi Petr,
I have merged the side-tag [1]. I would however need karma for it to get to stable.
https://bodhi.fedoraproject.org/updates/FEDORA-2021-ee8c904f46
I will send a list of the failed packages shortly.
systemd was built into the side-tag yesterday [1], but doesn't appear in the update…
[1] https://koji.fedoraproject.org/koji/buildinfo?buildID=1832196
Oh, I see it finished building after you merged the tag. Dunno, maybe the update should be updated?
--
Another issue: the update has 1006 "automated tests", out of which 1001 fail! I think is very wrong with "automated tests" is the out-of-the-box success rate is below 0.005%.
Error: Problem: conflicting requests
- nothing provides libcrypto.so.3()(64bit) needed by
zola-0.12.2-8.fc36.x86_64
- nothing provides libcrypto.so.3(OPENSSL_3.0.0)(64bit) needed by
zola-0.12.2-8.fc36.x86_64
- nothing provides libssl.so.3()(64bit) needed by
zola-0.12.2-8.fc36.x86_64
- nothing provides libssl.so.3(OPENSSL_3.0.0)(64bit) needed by
zola-0.12.2-8.fc36.x86_64
(try to add '--skip-broken' to skip uninstallable packages) Installation of zola-0:0.12.2-8.fc36.x86_64 failed.
So... is the test ignoring the fact that the package is part of an update and trying to install rpms individually?
Another one ( https://osci-jenkins-1.ci.fedoraproject.org/job/fedora-ci/job/rpminspect-pip... )
""" Error Message Test "/annocheck" failed. Find out more about this test in the documentation: https://github.com/rpminspect/rpminspect#rpminspect Found a bug? Please open an issue in the issue tracker: https://pagure.io/fedora-ci/general/issues """
How on earth are we supposed to figure out what annocheck doesn't like? There's 185328 bytes of "Standard Output" that follows…
Zbyszek _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
On Fri, Sep 17, 2021 at 5:09 AM Sahana Prasad sahana@redhat.com wrote:
Hello all,
The side-tag was merged yesterday. OpenSSL 3.0.0 is available in rawhide now. You can continue to port your changes for OpenSSL 3.0.0 now.
The following packages FTBFS (attached), kindly have a look at them. I haven't reported FTBFS bugs right away. As I know many packages have the porting ready already and they were waiting for 3.0.0 to land in rawhide. Some packages fail due to usage of deprecated functions. Consider treating those warnings as not errors for a quick fix and you could slowly stop using deprecated functions in the future.
Thanks Miro for your help with building packages in the side-tag and getting a list of failed packages.
We will try a rebuild of all these failed packages after 3/4 weeks and report bugs for failing packages then.
I noticed that the changelog for the openssl package got truncated. Is there a reason for this? The spec file wasn't significantly rewritten, nor was there some other condition invalidating the entire recorded history of the package. Would you kindly please restore the changelog to the spec file?
-- 真実はいつも一つ！/ Always, there's only one truth!
On Fri, Sep 17, 2021 at 12:50 PM Neal Gompa ngompa13@gmail.com wrote:
On Fri, Sep 17, 2021 at 5:09 AM Sahana Prasad sahana@redhat.com wrote:
Hello all,
The side-tag was merged yesterday. OpenSSL 3.0.0 is available in rawhide
now.
You can continue to port your changes for OpenSSL 3.0.0 now.
The following packages FTBFS (attached), kindly have a look at them. I haven't reported FTBFS bugs right away. As I know many packages have
the porting ready already
and they were waiting for 3.0.0 to land in rawhide. Some packages fail due to usage of deprecated functions. Consider
treating those warnings as not errors
for a quick fix and you could slowly stop using deprecated functions in
the future.
Thanks Miro for your help with building packages in the side-tag and
getting a list of failed packages.
We will try a rebuild of all these failed packages after 3/4 weeks and
report bugs for failing packages then.
I noticed that the changelog for the openssl package got truncated. Is there a reason for this? The spec file wasn't significantly rewritten, nor was there some other condition invalidating the entire recorded history of the package. Would you kindly please restore the changelog to the spec file?
Hi Neal, I will restore it. Thank you, Regards, Sahana Prasad
-- 真実はいつも一つ！/ Always, there's only one truth!
Hello Sahana and Jakub,
openssl-pkcs11 module failed during rebuild. It has no separate bug yet, but missing pkcs11 engine for OpenSSL 3.0 bind build makes freeipa server fail to even start.
Filled bug #2005832 [1]. CentOS Stream 9 build of openssl-pkcs11 were successful, I think there are missing changes required on Rawhide. Please include required fixes also in Rawhide.
Is there any timeline, when would be FTBFS bugs filled? I did not yet found any bug on openssl-pkcs11. I would expect openssl engine packages would be ready before mass rebuild. Could it be fixed soon please?
Cheers, Petr
1. https://bugzilla.redhat.com/show_bug.cgi?id=2005832
On 9/20/21 10:47, Sahana Prasad wrote:
On Fri, Sep 17, 2021 at 12:50 PM Neal Gompa ngompa13@gmail.com wrote:
On Fri, Sep 17, 2021 at 5:09 AM Sahana Prasad <sahana@redhat.com> wrote: > > Hello all, > > The side-tag was merged yesterday. OpenSSL 3.0.0 is available in rawhide now. > You can continue to port your changes for OpenSSL 3.0.0 now. > > The following packages FTBFS (attached), kindly have a look at them. > I haven't reported FTBFS bugs right away. As I know many packages have the porting ready already > and they were waiting for 3.0.0 to land in rawhide. > Some packages fail due to usage of deprecated functions. Consider treating those warnings as not errors > for a quick fix and you could slowly stop using deprecated functions in the future. > > Thanks Miro for your help with building packages in the side-tag and getting a list of failed packages. > > We will try a rebuild of all these failed packages after 3/4 weeks and report bugs for failing packages then. > I noticed that the changelog for the openssl package got truncated. Is there a reason for this? The spec file wasn't significantly rewritten, nor was there some other condition invalidating the entire recorded history of the package. Would you kindly please restore the changelog to the spec file?Hi Neal, I will restore it. Thank you, Regards, Sahana Prasad
-- 真実はいつも一つ！/ Always, there's only one truth!
devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
On Mon, Sep 20, 2021 at 12:26 PM Petr Menšík pemensik@redhat.com wrote:
Hello Sahana and Jakub,
openssl-pkcs11 module failed during rebuild. It has no separate bug yet, but missing pkcs11 engine for OpenSSL 3.0 bind build makes freeipa server fail to even start.
Filled bug #2005832 [1]. CentOS Stream 9 build of openssl-pkcs11 were successful, I think there are missing changes required on Rawhide. Please include required fixes also in Rawhide.
Hi Petr,
Jakub has fixed it in openssl-pkcs11-0.4.11-6.fc36.
Is there any timeline, when would be FTBFS bugs filled?
Yeah I wanted to file them 3/4 weeks after the introduction of OpenSSL 3.0.0. So tentatively around mid october.
Thank you, Regards, Sahana Prasad
I did not yet found any bug on openssl-pkcs11. I would expect openssl engine packages would be ready before mass rebuild. Could it be fixed soon please?
Cheers, Petr
On 9/20/21 10:47, Sahana Prasad wrote:
On Fri, Sep 17, 2021 at 12:50 PM Neal Gompa ngompa13@gmail.com wrote:
On Fri, Sep 17, 2021 at 5:09 AM Sahana Prasad sahana@redhat.com wrote:
Hello all,
The side-tag was merged yesterday. OpenSSL 3.0.0 is available in
rawhide now.
You can continue to port your changes for OpenSSL 3.0.0 now.
The following packages FTBFS (attached), kindly have a look at them. I haven't reported FTBFS bugs right away. As I know many packages have
the porting ready already
and they were waiting for 3.0.0 to land in rawhide. Some packages fail due to usage of deprecated functions. Consider
treating those warnings as not errors
for a quick fix and you could slowly stop using deprecated functions in
the future.
Thanks Miro for your help with building packages in the side-tag and
getting a list of failed packages.
We will try a rebuild of all these failed packages after 3/4 weeks and
report bugs for failing packages then.
I noticed that the changelog for the openssl package got truncated. Is there a reason for this? The spec file wasn't significantly rewritten, nor was there some other condition invalidating the entire recorded history of the package. Would you kindly please restore the changelog to the spec file?
Hi Neal, I will restore it. Thank you, Regards, Sahana Prasad
-- 真実はいつも一つ！/ Always, there's only one truth!
devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
-- Petr Menšík Software Engineer Red Hat, http://www.redhat.com/ email: pemensik@redhat.com PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB
On 17. 09. 21 11:07, Sahana Prasad wrote:
Hello all,
The side-tag was merged yesterday. OpenSSL 3.0.0 is available in rawhide now. You can continue to port your changes for OpenSSL 3.0.0 now.
The following packages FTBFS (attached), kindly have a look at them.
I have switched the following packages to OpenSSL 1.1 explicitly as they will not support OpenSSL 3.0:
python2.7 python3.7 python3.6 pypy pypy3.7
See an example PR for inspiration:
https://src.fedoraproject.org/rpms/python3.6/pull-request/36
The constrict is compatible with Fedora 33-35 as well.
It is not compatible with RHELs, but if deemed necessary, we can add openssl1.1 matapackage to EPEL.
I've also requested the openssl1.1-devel provide to be added to RHEL 8, but it might be rejected or take a long time:
https://bugzilla.redhat.com/show_bug.cgi?id=2006238
On Tue, Sep 21, 2021 at 11:58 AM Miro Hrončok mhroncok@redhat.com wrote:
On 17. 09. 21 11:07, Sahana Prasad wrote:
Hello all,
The side-tag was merged yesterday. OpenSSL 3.0.0 is available in rawhide
now.
You can continue to port your changes for OpenSSL 3.0.0 now.
The following packages FTBFS (attached), kindly have a look at them.
I have switched the following packages to OpenSSL 1.1 explicitly as they will not support OpenSSL 3.0:
python2.7 python3.7 python3.6 pypy pypy3.7
See an example PR for inspiration:
https://src.fedoraproject.org/rpms/python3.6/pull-request/36
The constrict is compatible with Fedora 33-35 as well.
It is not compatible with RHELs, but if deemed necessary, we can add openssl1.1 matapackage to EPEL.
I've also requested the openssl1.1-devel provide to be added to RHEL 8, but it might be rejected or take a long time:
Hi Miro,
Thanks for reporting this RFE. We have decided to provide support for it.
Thank you, Regards, Sahana Prasad
https://bugzilla.redhat.com/show_bug.cgi?id=2006238
-- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok
Hi everyone,
Reminder to kindly think about porting your packages to avoid build failures with OpenSSL 3.0.0. We will try a rebuild in the next 2 weeks, and report FTBFS bugs.
Thank you, Regards, Sahana Prasad
On Tue, Sep 28, 2021 at 9:45 AM Sahana Prasad sahana@redhat.com wrote:
On Tue, Sep 21, 2021 at 11:58 AM Miro Hrončok mhroncok@redhat.com wrote:
On 17. 09. 21 11:07, Sahana Prasad wrote:
Hello all,
The side-tag was merged yesterday. OpenSSL 3.0.0 is available in
rawhide now.
You can continue to port your changes for OpenSSL 3.0.0 now.
The following packages FTBFS (attached), kindly have a look at them.
I have switched the following packages to OpenSSL 1.1 explicitly as they will not support OpenSSL 3.0:
python2.7 python3.7 python3.6 pypy pypy3.7
See an example PR for inspiration:
https://src.fedoraproject.org/rpms/python3.6/pull-request/36
The constrict is compatible with Fedora 33-35 as well.
It is not compatible with RHELs, but if deemed necessary, we can add openssl1.1 matapackage to EPEL.
I've also requested the openssl1.1-devel provide to be added to RHEL 8, but it might be rejected or take a long time:
Hi Miro,
Thanks for reporting this RFE. We have decided to provide support for it.
Thank you, Regards, Sahana Prasad
https://bugzilla.redhat.com/show_bug.cgi?id=2006238
-- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok
On 29. 09. 21 9:11, Sahana Prasad wrote:
Hi everyone,
Reminder to kindly think about porting your packages to avoid build failures with OpenSSL 3.0.0. We will try a rebuild in the next 2 weeks, and report FTBFS bugs.
I also see that we have openssl1.1 in the default build root, likely to (at least) krb5-libs which has been fixed in CentOS Stream 9, but not in Fedora Rawhide yet:
https://gitlab.com/redhat/centos-stream/rpms/krb5/-/commits/c9s https://src.fedoraproject.org/rpms/krb5/commits/rawhide
On Wed, Sep 29, 2021 at 6:00 AM Miro Hrončok mhroncok@redhat.com wrote:
On 29. 09. 21 9:11, Sahana Prasad wrote:
Hi everyone,
Reminder to kindly think about porting your packages to avoid build failures with OpenSSL 3.0.0. We will try a rebuild in the next 2 weeks, and report FTBFS bugs.
I also see that we have openssl1.1 in the default build root
How long (how many Fedora releases) do we expect to have openssl1.1-devel available in the buildroot? I maintain modules of Node.js 12 and 14 that will likely never be updated to support OpenSSL 3.0 and I'd prefer to keep them alive until their upstream EOLs (2022-04-30 and 2023-04-30, respectively).
On Wed, Sep 29, 2021 at 3:26 PM Stephen Gallagher sgallagh@redhat.com wrote:
On Wed, Sep 29, 2021 at 6:00 AM Miro Hrončok mhroncok@redhat.com wrote:
On 29. 09. 21 9:11, Sahana Prasad wrote:
Hi everyone,
Reminder to kindly think about porting your packages to avoid build failures with OpenSSL 3.0.0. We will try a rebuild in the next 2 weeks, and report FTBFS bugs.
I also see that we have openssl1.1 in the default build root
How long (how many Fedora releases) do we expect to have openssl1.1-devel available in the buildroot? I maintain modules of Node.js 12 and 14 that will likely never be updated to support OpenSSL 3.0 and I'd prefer to keep them alive until their upstream EOLs (2022-04-30 and 2023-04-30, respectively).
Hi Stephen, I can keep it in Fedora until then, sure. 1.1.1 upstream EOL is in 2023. After that we would not support CVE fixes.
Thank you, Regards, Sahana Prasad
Hi everyone,
Reminder to kindly think about porting your packages to avoid build failures with OpenSSL 3.0.0. We will try a rebuild of previously shared failed packages on 15th, and report FTBFS bugs.
Thank you, Regards, Sahana Prasad
On Thu, Sep 30, 2021 at 4:31 PM Sahana Prasad sahana@redhat.com wrote:
On Wed, Sep 29, 2021 at 3:26 PM Stephen Gallagher sgallagh@redhat.com wrote:
On Wed, Sep 29, 2021 at 6:00 AM Miro Hrončok mhroncok@redhat.com wrote:
On 29. 09. 21 9:11, Sahana Prasad wrote:
Hi everyone,
Reminder to kindly think about porting your packages to avoid build failures with OpenSSL 3.0.0. We will try a rebuild in the next 2 weeks, and report FTBFS bugs.
I also see that we have openssl1.1 in the default build root
How long (how many Fedora releases) do we expect to have openssl1.1-devel available in the buildroot? I maintain modules of Node.js 12 and 14 that will likely never be updated to support OpenSSL 3.0 and I'd prefer to keep them alive until their upstream EOLs (2022-04-30 and 2023-04-30, respectively).
Hi Stephen, I can keep it in Fedora until then, sure. 1.1.1 upstream EOL is in 2023. After that we would not support CVE fixes.
Thank you, Regards, Sahana Prasad
On Wed, Sep 29, 2021 at 9:11 AM Sahana Prasad sahana@redhat.com wrote:
Hi everyone,
Reminder to kindly think about porting your packages to avoid build failures with OpenSSL 3.0.0. We will try a rebuild in the next 2 weeks, and report FTBFS bugs.
Hi all, FTBFS bugs have been reported for all those packages that failed to build with OpenSSL 3.0.0. Attached list of failed packages and logs [1].
Thank you, Regards, Sahana Prasad
Thank you, Regards, Sahana Prasad
On Tue, Sep 28, 2021 at 9:45 AM Sahana Prasad sahana@redhat.com wrote:
On Tue, Sep 21, 2021 at 11:58 AM Miro Hrončok mhroncok@redhat.com wrote:
On 17. 09. 21 11:07, Sahana Prasad wrote:
Hello all,
The side-tag was merged yesterday. OpenSSL 3.0.0 is available in
rawhide now.
You can continue to port your changes for OpenSSL 3.0.0 now.
The following packages FTBFS (attached), kindly have a look at them.
I have switched the following packages to OpenSSL 1.1 explicitly as they will not support OpenSSL 3.0:
python2.7 python3.7 python3.6 pypy pypy3.7
See an example PR for inspiration:
https://src.fedoraproject.org/rpms/python3.6/pull-request/36
The constrict is compatible with Fedora 33-35 as well.
It is not compatible with RHELs, but if deemed necessary, we can add openssl1.1 matapackage to EPEL.
I've also requested the openssl1.1-devel provide to be added to RHEL 8, but it might be rejected or take a long time:
Hi Miro,
Thanks for reporting this RFE. We have decided to provide support for it.
Thank you, Regards, Sahana Prasad
https://bugzilla.redhat.com/show_bug.cgi?id=2006238
-- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok
On 08.09.21 09:59, Sahana Prasad wrote:
Hi all,
An update that I will directly bring in the OpenSSL 3.0.0 final RC (released upstream yesterday) into rawhide in the next few days. (Compared to beta2, this version has one moderate CVE-2021-3712 fix in addition to other fixes.)
Looks like nodejs does not work properly with openssl-3.0? I.e.
Error: error:0308010C:digital envelope routines::unsupported at new Hash (node:internal/crypto/hash:67:19) at Object.createHash (node:crypto:130:10) at module.exports (/home/sandro/Documents/Devel/QWC2/qwc2-demo-app/node_modules/webpack/lib/util/createHash.js:135:53)
at NormalModule._initBuildHash (/home/sandro/Documents/Devel/QWC2/qwc2-demo-app/node_modules/webpack/lib/NormalModule.js:417:16)
at handleParseError (/home/sandro/Documents/Devel/QWC2/qwc2-demo-app/node_modules/webpack/lib/NormalModule.js:471:10)
at /home/sandro/Documents/Devel/QWC2/qwc2-demo-app/node_modules/webpack/lib/NormalModule.js:503:5
at /home/sandro/Documents/Devel/QWC2/qwc2-demo-app/node_modules/webpack/lib/NormalModule.js:358:12
at /home/sandro/Documents/Devel/QWC2/qwc2-demo-app/node_modules/loader-runner/lib/LoaderRunner.js:373:3
at iterateNormalLoaders (/home/sandro/Documents/Devel/QWC2/qwc2-demo-app/node_modules/loader-runner/lib/LoaderRunner.js:214:10)
at iterateNormalLoaders (/home/sandro/Documents/Devel/QWC2/qwc2-demo-app/node_modules/loader-runner/lib/LoaderRunner.js:221:10)
at /home/sandro/Documents/Devel/QWC2/qwc2-demo-app/node_modules/loader-runner/lib/LoaderRunner.js:236:3
at context.callback (/home/sandro/Documents/Devel/QWC2/qwc2-demo-app/node_modules/loader-runner/lib/LoaderRunner.js:111:13)
at Object.loader (/home/sandro/Documents/Devel/QWC2/qwc2-demo-app/node_modules/source-map-loader/dist/index.js:37:5)
at LOADER_EXECUTION (/home/sandro/Documents/Devel/QWC2/qwc2-demo-app/node_modules/loader-runner/lib/LoaderRunner.js:119:14)
at runSyncOrAsync (/home/sandro/Documents/Devel/QWC2/qwc2-demo-app/node_modules/loader-runner/lib/LoaderRunner.js:120:4)
at iterateNormalLoaders (/home/sandro/Documents/Devel/QWC2/qwc2-demo-app/node_modules/loader-runner/lib/LoaderRunner.js:232:2) { opensslErrorStack: [ 'error:03000086:digital envelope routines::initialization error'], library: 'digital envelope routines', reason: 'unsupported', code: 'ERR_OSSL_EVP_UNSUPPORTED'
Anyone encountered this one? Google just gives a single hit for ERR_OSSL_EVP_UNSUPPORTED, which is a rhbz bug [1]. This is kinda fatal for nodejs/webpack development :S
Thanks Sandro
[1] https://bugzilla.redhat.com/show_bug.cgi?format=multiple&id=1975437
* Sandro Mani:
Anyone encountered this one? Google just gives a single hit for ERR_OSSL_EVP_UNSUPPORTED, which is a rhbz bug [1]. This is kinda fatal for nodejs/webpack development :S
MD4 has been deprecated since about 1995.
It should be possible to re-activate these old algorithms:
https://www.openssl.org/docs/manmaster/man7/migration_guide.html#Legacy-Algorithms
It's probably easier to tell webpack to use a different hash algorithm. I understand there's a configuration option for that.
Thanks, Florian
On 20.09.21 11:40, Florian Weimer wrote:
- Sandro Mani:
Anyone encountered this one? Google just gives a single hit for ERR_OSSL_EVP_UNSUPPORTED, which is a rhbz bug [1]. This is kinda fatal for nodejs/webpack development :S
MD4 has been deprecated since about 1995.
It should be possible to re-activate these old algorithms:
https://www.openssl.org/docs/manmaster/man7/migration_guide.html#Legacy-Algorithms
It's probably easier to tell webpack to use a different hash algorithm. I understand there's a configuration option for that.
Thanks! I ended up replacing every occurrence of md4 with sha256 in node_modules/webpack... || ||
|Sandro |
devel@lists.stg.fedoraproject.org
-
Alexander Bokovoy -
Fabio Valentini -
Florian Weimer -
Gary Buhrmaster -
Jerry James -
Kevin Fenzi -
Miro Hrončok -
Neal Gompa -
Omair Majid -
Petr Menšík -
Sahana Prasad -
Sandro Mani -
Stephen Gallagher -
Vít Ondruch -
Zbigniew Jędrzejewski-Szmek