Re: libgit2 switch from mbedTLS to OpenSSL

Quoting Heinrich Schuchardt (2022-06-29 12:56:57)
> On 6/29/22 10:33, Simon Chopin wrote:
> > Hi!
> >
> > As part of our efforts to support the Rust toolchain in main, we need to
> > have libgit2 in main (dependency of cargo). However, it currently links
> > against mbedTLS for its HTTPS backend rather than OpenSSL, for licensing
> > reasons IIUC. Those reasons would now be invalid with the new OpenSSL
> > 3.0 licensing.
> >
> > I'd like to switch it back to OpenSSL to avoid pulling yet another TLS
> > implementation in main, however I'm a bit fuzzy whether this would
> > constitute a breaking change for the libgit2 package. The libgit2
> > library does not expose anything from its crypto implem as part of its
> > API, nor does it re-export any of their symbols (assuming I understand
> > the output of readelf -s correctly).
> >
> > Could someone confirm that this does not represent a breaking change?
>
> Libgit2 is licensed under GPLv2 which is incompatible with the Apache v2
> license of OpenSSL 3.0 (see
> https://www.gnu.org/licenses/license-list.html.en).
>
> But a "Linking Exception" is present in the COPYRIGHT file of libgit2.
> Please, recheck if that exception is enough for your use case.

Looking closer at the linking exception, I think we're good since it is
rather broad.

--
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Re: libgit2 switch from mbedTLS to OpenSSL

On 6/29/22 10:33, Simon Chopin wrote:
> Hi!
>
> As part of our efforts to support the Rust toolchain in main, we need to
> have libgit2 in main (dependency of cargo). However, it currently links
> against mbedTLS for its HTTPS backend rather than OpenSSL, for licensing
> reasons IIUC. Those reasons would now be invalid with the new OpenSSL
> 3.0 licensing.
>
> I'd like to switch it back to OpenSSL to avoid pulling yet another TLS
> implementation in main, however I'm a bit fuzzy whether this would
> constitute a breaking change for the libgit2 package. The libgit2
> library does not expose anything from its crypto implem as part of its
> API, nor does it re-export any of their symbols (assuming I understand
> the output of readelf -s correctly).
>
> Could someone confirm that this does not represent a breaking change?
>
> Cheers,
> --
> Simon Chopin
> Foundations Team Ubuntu Core Dev
> simon.chopin@canonical.com schopin@ubuntu.com
>

Libgit2 is licensed under GPLv2 which is incompatible with the Apache v2
license of OpenSSL 3.0 (see
https://www.gnu.org/licenses/license-list.html.en).

But a "Linking Exception" is present in the COPYRIGHT file of libgit2.
Please, recheck if that exception is enough for your use case.

Best regards

Heinrich

--
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

libgit2 switch from mbedTLS to OpenSSL

Hi!

As part of our efforts to support the Rust toolchain in main, we need to
have libgit2 in main (dependency of cargo). However, it currently links
against mbedTLS for its HTTPS backend rather than OpenSSL, for licensing
reasons IIUC. Those reasons would now be invalid with the new OpenSSL
3.0 licensing.

I'd like to switch it back to OpenSSL to avoid pulling yet another TLS
implementation in main, however I'm a bit fuzzy whether this would
constitute a breaking change for the libgit2 package. The libgit2
library does not expose anything from its crypto implem as part of its
API, nor does it re-export any of their symbols (assuming I understand
the output of readelf -s correctly).

Could someone confirm that this does not represent a breaking change?

Cheers,
--
Simon Chopin
Foundations Team Ubuntu Core Dev
simon.chopin@canonical.com schopin@ubuntu.com

--
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

+1 Maintenance Report

I was on +1 maintenance for the week of June 20-24. Below are the
things I worked on.

On Monday, I found many packages had FTBFS without logs, or failed to
upload, and I retried these.

On Tuesday, the autopkgtest queues were empty so I scheduled retries
of all regressed autopkgtests (826 in total). Once these were done, I
scheduled migration-reference/0 autopkgtests of those that were still
regressed (579 in total). Presumably the difference being those that
passed on retry.

I found several packages that were blocked because of missing binaries
on architectures that had been dropped and filed bugs for the removal
of their binaries:
pyopencl (mesa stopped building mesa-opencl-icd on riscv64) LP: #1979297
sysbench dropped ppc64el LP: #1979299
gromacs dropped 32-bit LP: #1979302
kallisto dropped 32-bit LP: #1979304
abyss dropped 32-bit LP: #1969297 (re-opened)

dd-opentracing-cpp
==================
The version in Ubuntu FTBFS, so I sync'd the new version from Debian
which included the Ubuntu delta and a fix for the FTBFS.

sfxr-qt
=======
I fixed a FTBFS with glibc 2.34 and filed Debian bug #1013307.

chktex
======
I fixed a FTBFS when TERM is not set and filed Debian bug #1013358.

toil
====
I fixed a FTBFS with Python 3.10 as the only supported version and
filed Debian bug #1013275.

python-bayespy
==============
I cherry-picked an upstream commit to fix a FTBFS with scipy 1.8.
Since this is an orphaned package in Debian, I intended to do a QA
upload, but luckily somebody beat me to it, and I was able sync again
from Debian.

r-base
======
I merged the new upstream version from Debian unstable.

macaulay2
=========
I investigated autopkgtest flakiness on amd64 and opened an upstream
PR relaxing the timing of a test.

--
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Re: Jammy regressions

FWIW, iommu also appears to be a culprit on a private bug from one of
our OEM partners that was causing Jammy installs to crash.

We've been working with them and Intel and for that bug in particular
there is a patch in the works from Intel:
https://lore.kernel.org/all/20220622044120.21813-1-baolu.lu@linux.intel.com/T/

That said, I'm not sure if that relates to the previously listed bugs,
but in case it is of interest here, I thought I'd share.

Jeff

On Mon, Jun 27, 2022 at 2:41 AM Daniel van Vugt
<daniel.van.vugt@canonical.com> wrote:
>
> Sounds like intel_iommu=igfx_off should be suggested in each bug so please get
> involved by replying to the bugs:
>
> https://bugs.launchpad.net/ubuntu/+bugs?field.tag=iommu
>
>
> On 24/6/22 9:14 pm, Heinrich Schuchardt wrote:
> > Doesn't intel_iommu=off imply a security risk because a thunderbolt device can
> > access all of the RAM? intel_iommu=igfx_off should be enough to resolve issues
> > with GPUs.
> >
> > On Fri, Jun 24, 2022 at 11:25 AM Daniel van Vugt <daniel.van.vugt@canonical.com
> > <mailto:daniel.van.vugt@canonical.com>> wrote:
> >
> > Looking at jammy's remaining release regressions:
> >
> > https://bugs.launchpad.net/ubuntu/?field.searchtext=&search=Search&field.tag=jammy%20regression-release&field.tags_combinator=ALL&orderby=-heat&start=0
> > <https://bugs.launchpad.net/ubuntu/?field.searchtext=&search=Search&field.tag=jammy%20regression-release&field.tags_combinator=ALL&orderby=-heat&start=0>
> >
> > It appears 21% of them are solvable (by most reports) using the kernel
> > parameter
> > "intel_iommu=off". Is this something the kernel team would consider?
> >
> > https://launchpad.net/bugs/1958191 <https://launchpad.net/bugs/1958191>
> > https://launchpad.net/bugs/1965882 <https://launchpad.net/bugs/1965882>
> > https://launchpad.net/bugs/1959041 <https://launchpad.net/bugs/1959041>
> > https://launchpad.net/bugs/1971146 <https://launchpad.net/bugs/1971146>
> >
> > - Daniel
> >
> > --
> > ubuntu-devel mailing list
> > ubuntu-devel@lists.ubuntu.com <mailto:ubuntu-devel@lists.ubuntu.com>
> > Modify settings or unsubscribe at:
> > https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
> > <https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel>
> >
>
> --
> kernel-team mailing list
> kernel-team@lists.ubuntu.com
> https://lists.ubuntu.com/mailman/listinfo/kernel-team

--
Jeff Lane
Engineering Manager
IHV/OEM Alliances and Server Certification

"Entropy isn't what it used to be."

--
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Re: Jammy regressions

Sounds like intel_iommu=igfx_off should be suggested in each bug so please get
involved by replying to the bugs:

https://bugs.launchpad.net/ubuntu/+bugs?field.tag=iommu

On 24/6/22 9:14 pm, Heinrich Schuchardt wrote:
> Doesn't intel_iommu=off imply a security risk because a thunderbolt device can
> access all of the RAM? intel_iommu=igfx_off should be enough to resolve issues
> with GPUs.
>
> On Fri, Jun 24, 2022 at 11:25 AM Daniel van Vugt <daniel.van.vugt@canonical.com
> <mailto:daniel.van.vugt@canonical.com>> wrote:
>
> Looking at jammy's remaining release regressions:
>
> https://bugs.launchpad.net/ubuntu/?field.searchtext=&search=Search&field.tag=jammy%20regression-release&field.tags_combinator=ALL&orderby=-heat&start=0
> <https://bugs.launchpad.net/ubuntu/?field.searchtext=&search=Search&field.tag=jammy%20regression-release&field.tags_combinator=ALL&orderby=-heat&start=0>
>
> It appears 21% of them are solvable (by most reports) using the kernel
> parameter
> "intel_iommu=off". Is this something the kernel team would consider?
>
> https://launchpad.net/bugs/1958191 <https://launchpad.net/bugs/1958191>
> https://launchpad.net/bugs/1965882 <https://launchpad.net/bugs/1965882>
> https://launchpad.net/bugs/1959041 <https://launchpad.net/bugs/1959041>
> https://launchpad.net/bugs/1971146 <https://launchpad.net/bugs/1971146>
>
> - Daniel
>
> --
> ubuntu-devel mailing list
> ubuntu-devel@lists.ubuntu.com <mailto:ubuntu-devel@lists.ubuntu.com>
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
> <https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel>
>

--
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Re: Jammy regressions

Doesn't intel_iommu=off imply a security risk because a thunderbolt device can access all of the RAM? intel_iommu=igfx_off should be enough to resolve issues with GPUs.

On Fri, Jun 24, 2022 at 11:25 AM Daniel van Vugt <daniel.van.vugt@canonical.com> wrote:

Looking at jammy's remaining release regressions:

https://bugs.launchpad.net/ubuntu/?field.searchtext=&search=Search&field.tag=jammy%20regression-release&field.tags_combinator=ALL&orderby=-heat&start=0

It appears 21% of them are solvable (by most reports) using the kernel parameter
"intel_iommu=off". Is this something the kernel team would consider?

https://launchpad.net/bugs/1958191
https://launchpad.net/bugs/1965882
https://launchpad.net/bugs/1959041
https://launchpad.net/bugs/1971146

- Daniel

--
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel