[MIR] egl-wayland

The process for adding packages to Main is slightly more complex - there’s a template that should be used and certain details that need to be included, as well as specific steps to take in order to cause the right people to see it and advance the process. This wiki page has all the details: https://wiki.ubuntu.com/MainInclusionProcess
I think you should be able to add the relevant information here (edit the description), no need to open a new bug.

@michagogo thanks for your help. Additional info and subscription added.

[Summary]
After the requirements ("Required TODOs") below are addressed, this is an ACK from the MIR team

This does need a security review, so after the requirements are addressed, it needs to be assigned to ubuntu-security

List of specific binary packages to be promoted to main:
- libnvidia-egl-wayland1

Notes:
Required TODOs:
- add symbol tracking
- add at least basic build test
  - an autopkgtest in would be good in addition but not required
- requires a team bug subscriber (this can be done after the security review)

[Duplication]
There is no other package in main providing the same functionality.

[Dependencies]
OK:
- no other Dependencies to MIR due to this

Problems:
- Should exclude binary package libnvidia-egl-wayland-dev

[Embedded sources and static linking]
OK:
- no embedded source present
- no static linking

[Security]
OK:
- history of CVEs (none) does not look concerning
- does not run a daemon as root
- does not use webkit1,2
- does not use lib*v8 directly
- does not parse data formats
- does not process arbitrary web content
- does not use centralized online accounts
- does not integrate arbitrary javascript into the desktop
- does not deal with system authentication (eg, pam), etc)

Problems:
- may open a port, depending on configuration (it appears)

[Common blockers]
OK:
- does not FTBFS currently
- no translation present, but none needed for this case (library only)
- not a python/go package, no extra constraints to consider in that regard

Problems:
- The package does not have a team bug subscriber
- does not have a test suite that runs at build time
- does not have a test suite that runs as autopkgtest

[Packaging red flags]
OK:
- Ubuntu does not carry a delta
- d/watch is present and looks ok
- Upstream update history is good
- Debian/Ubuntu update history is good
- the current release is packaged
- promoting this does not seem to cause issues for MOTUs that so far
  maintained the package
- no massive Lintian warnings
- d/rules is rather clean
- Does not have Built-Using
- Not go package
- Not on lto-disabled list

Problems:
- symbols tracking is not in place

[Upstream red flags]
OK:
- no Errors/warnings during the build
- no incautious use of malloc/sprintf (as far as I can check it)
- no use of sudo, gksu, pkexec, or LD_LIBRARY_PATH
- no use of user nobody
- no use of setuid
- no important open bugs (crashers, etc) in Debian or Ubuntu or Upstream
- no dependency on webkit, qtwebkit, seed or libgoa-*
- not part of the UI for extra checks

Am I misunderstanding the MIR process/flow? I would have expected a status change to Incomplete and the assignment to remain as ddstreet from a reading of that page.

you're right, i've changed to incomplete status waiting on reporter actions

if someone has suggestions to fix the issues, patches are welcome

-2 adds symbols tracking

So I looked at providing a trivial library loading test for this, but since the -dev pkg doesn't even ship any headers, I don't know what to do.

Symbols tracking has been added in https://launchpad.net/ubuntu/+source/egl-wayland/1:1.1.7-2 which is not migrating as it is stuck behind glibc

ADT test is hard to provide => functional one needs nvidia graphics cards that are not present in ADT; and compile test is equally hard given that it is effectively a plugin.

ubuntu-x-swat is now subscribed.

@cpaelzer the build and/or autopkgtest requirement for MIR possibly should be expanded to allow for hardware-specific code like this, where 'normal' testing isn't easy and/or possible. In such cases, IMO at least, it seems like an exception would be reasonable, but only if the subscribing team agrees to take some level of ownership in managing the ongoing hardware-specific testing that would be needed.

Something we could discuss at next MIR mtg.

...
>
> Something we could discuss at next MIR mtg.
>

I totally agree and I think this also is how we handled it so far (to
discuss it in the meeting AND how you suggested handling those HW
dependent cases).
It only seems right to formally express it in the process description.
Please remind me in the meeting later today if I forget it.

From the MIR meeting.
We are ok in regard to the testing, but please be sure that you as the owning Team should ensure to have the necesary HW to be able to test this on merges/updates as well as on debugging.

The only concern that is left (which can be clatrified while waiting on security review) is that we have discused in the past that "ubuntu-x-swat" is no sufficient Team for the MIR process.
Since canonical is providing the support it has to be one of the canonical teams. Essentially one of the major teams listed in http://reqorts.qa.ubuntu.com/reports/m-r-package-team-mapping.html
On the last such case Desktop also subscribed to fullfil this need (you can have multiple subscriptions - if you need the one of ubuntu-x-swat please feel free to keep it).

kernel-packages -team was supposed to be subscribed to egl-wayland bugs last month... I'll poke folks again

kernel-packages is now subscribed.

> kernel-packages is now subscribed.

Thanks, then it has the MIR-team ACK now and waits on security to be complete.

I reviewed egl-wayland 1:1.1.7-2build1 as checked into impish. This shouldn't be
considered a full audit but rather a quick gauge of maintainability.

egl-wayland is a bit of graphics glue. I don't understand what it does.

- CVE History:
  Nothing in our database
- Build-Depends?
  debhelper-compat (= 12),
   eglexternalplatform-dev,
   libegl1-mesa-dev,
   libwayland-dev,
   libwayland-egl-backend-dev,
   meson,
   pkg-config,
- pre/post inst/rm scripts?
  none
- init scripts?
  none
- systemd units?
  none
- dbus services?
  none
- setuid binaries?
  none
- binaries in PATH?
  none
- sudo fragments?
  none
- polkit files?
  none
- udev rules?
  none
- unit tests / autopkgtests?
  none :(
- cron jobs?
  none
- Build logs:
  clean

- Processes spawned?
  None
- Memory management?
  Mostly good; some malloc() calls may invite integer overflows, but
  untrusted inputs to the functions can probably do worse than this.
- File IO?
  None
- Logging?
  Very little, looked safe.
- Environment variable usage?
  Very little, looked safe
- Use of privileged functions?
  none
- Use of cryptography / random number sources etc?
  none
- Use of temp files?
  none
- Use of networking?
  This *can* use TCP, which is surprising to me, but it's a third-place
  fallback, and the server has gone to efforts to accept a single
  connection. I don't love it.
- Use of WebKit?
  none
- Use of PolicyKit?
  none

- Any significant cppcheck results?
  only false positives
- Any significant Coverity results?
  a few unrelated things, a handful of very low severity things
- Any significant shellcheck results?
  none
- Any significant bandit results?
  none

I don't really understand what this package does, but it's short and seems
to be professionally programmed, with the exception of lacking tests. That
might be difficult if it relies upon specific hardware but it does mean
that the security team will need assistance from the owning team to test
updates.

Security team ACK for promoting egl-wayland to main conditional upon the
owning team comitting to assisting with tests when necessary.

Here's a handful of minor things I found while reviewing the package:

wlEglCreatePbufferSurfaceHook() surface might be leaked in second goto fail

wlEglCreateStreamProducerSurfaceHook() surface might be leaked in second goto fail

wlEglGetPlatformDisplayExport() if (display->ownNativeDpy) NULL derefence,
via goto fail

assignWlEglSurfaceAttribs(), wlEglCreateStreamAttribHook(),
wlEglChooseConfigHook(), use unguarded
integer operations in arguments to malloc(); overflows are very unlikely
since they depend upon memory arrays being passed in with the correct
formats. Probably fine.

Hi,
now everything is complete except the QA via testing.
We have amended the MIR rules to better clarify as this is one of the cases that is hard to autopkgtest/build-test but some QA should happen still.

The new rule is:
"The package must include a non-trivial test suite, and if there is no obvious reason why it cannot work during build (e.g. it needs root privileges or network access), it should be run during package build, and a failing test suite should fail the build. The package should, but is not required to, also contain non-trivial autopkgtest(s). If no build tests nor autopkgtests are included, and/or if the package requires specific hardware to perform testing, the subscribed team must provide a written test plan in a comment to the MIR bug, and commit to running that test either at each upload of the package or at least once each release cycle. In the comment to the MIR bug, please link to the codebase of these tests (scripts or doc of manual steps) and attach a full log of these test runs. This is meant to assess their validity (e.g. not just superficial)"

Therefore I'd ask to add to the bug:
- the test plan / code / guide (whatever you have of that)
- logs of a successful run thereof.
- the written commitment to do (regularly)

I have been running NVIDIA on Wayland and accelerated Wayland without problems for a while now. I tested Steam, which runs fine.

I think egl-wayland is ready to be in main.

We will make sure to test this, so that NVIDIA on Wayland doesn't break.

I am not sure what logs you would like to see.

Hi,
I'd expect something based on those to questions:

- can the test be automated?
  - yes => "link to the scripts you run"
  - no => a list of the steps & tests that you will do (think of you are run over by a bus, the next QA person has to do them by the script)

- does this have console output
  - yes => the example console output of a good run
  - no => a doc that outlines the expected test results

@Alberto - Does that clarify it a bit?

No, unfortunately, the test can't be automated.

Here are some steps to test it.

1) Make sure that libnvidia-egl-wayland1

2) Run a Wayland session using the NVIDIA driver (KMS needs to be enabled).

3) If it is a single GPU system, run a 3D application such as a game, that is not Wayland native. If you are using a hybrid (Intel+NVIDIA, or AMD + NVIDIA) system, you can launch the app by right-clicking on it and by selecting "Run using Discrete GPU".

4) If the application runs without problems, then everything works.

Hello Alberto,

Thanks for sketching out the QA steps for this package; egl-wayland is the first package to go through our new testing requirements, so we're still iterating on what we'd like to see. We discussed this and decided that we needed more information to have confidence that someone else could perform these steps in your absence.

Can you provide us with more details on how to perform these tests?

After installing libnvidia-egl-wayland1 and restarting the Wayland compositor, how do you verify that this package is being used? Does this work with any Wayland compositor in the archive or only specific ones?

How do you enable KMS? How do you verify that KMS has been enabled?

Can you expand upon the 'not Wayland native 3D application'? Is the idea to test the X11 compatibility layer? Or is this also not an X11 application? What application will you use for testing this, is this in the archive already or is it packaged elsewhere?

Can you expand upon the 'single GPU' bit? What happens on systems with eg two or more GPUs?

Thanks

Moving to incomplete until we have an answer on Seth’s questions. Please reset it once answered.

> After installing libnvidia-egl-wayland1 and restarting the Wayland compositor, how do you verify that this package is being used? Does this work with any Wayland compositor in the archive or only specific ones?

The main scenario that we support is Gnome shell, with its default compositor (Mutter), which comes by default with Ubuntu 21.10.

As for verifying that libnvidia-egl-wayland1 is in use, you probably can't, at least directly. You will notice, though, if 3D applications run unaccelerated.

> How do you enable KMS? How do you verify that KMS has been enabled?

If you install the driver using the ubuntu-drivers tool (or if you install Ubuntu 21.10, and select the proprietary drivers) Wayland support will be enabled by default, as long as your GPU is supported by the NVIDIA 470 driver:

https://help.ubuntu.com/community/NvidiaDriversInstallation

> Can you expand upon the 'not Wayland native 3D application'? Is the idea to test the X11 compatibility layer? Or is this also not an X11 application? What application will you use for testing this, is this in the archive already or is it packaged elsewhere?

3D acceleration on Wayland already works on native applications (using the GTK3, GTK4, QT5 toolkits, etc). Applications which use their own toolkit, such as Firefox, may also feature Wayland support. GTK2 apps, apps that rely on Wine, and older QT apps can be assumed to run on X11 (XWayland) when Gnome Shell is running on Wayland.

To check that you are running a Wayland compositor:

$ echo $XDG_SESSION_TYPE

You can also get a list of the apps which run on X11 on your system using the following command:

$ xlsclients

> Can you expand upon the 'single GPU' bit? What happens on systems with eg two or more GPUs?

If your system has an integrated (AMD or Intel) GPU, and an NVIDIA discrete GPU, the Gnome session will run off the integrated GPU, and you will have to tell the shell to use the discrete GPU for selected applications.

Thanks

Thanks Alberto, while this is n't perfect yet (many would still need help to run the test as it isn't detailed enough yet for e.g. me desktop-noob) but you outlined what it is about - thanks.
But especially for a package like this which could be lost between kernel (owning it) and Desktop (everybody thinks it is theirs) - please let me ask a final question.

You are committing to do such tests:
a) after every upload
b) at least X times per cycle (manual CI)
c) combination of the above

And in that scope You = ?? Read - who commits to do that testing.

Per the MIR team meeting of today, once that is settled we think we can move forward on this case.

Still waiting on a response on this - marking incomplete

Christian, that would be a). The kernel team will own this, and our QA certification team will run the tests.

Thank you Alberto for clarifying that last bit.
By that we now have the MIR-team and the security-team Acks.
That should indeed be ready for promotion now \o/

Any updates on this?

As I understand the process, what remains now is for the package to be pulled into main, either by being directly added to a seed or as a dependency of another package. In this case if I understand correctly the package is required iff the Nvidia drivers are installed, so it would seem to me that it would make the most sense for it to be a dependency of those drivers - I’m not familiar with the structure of the graphics driver source packages and all the various binary packages they produce, but perhaps xserver-xorg-video-nvidia-470 or nvidia-driver-470 would be the right place?

Also, I see 470 is in bionic, focal, and impish - does this need to get SRUed back to those as well to avoid the performance penalty? I’m not clear on how MIRs and SRUs intersect, but besides the dependency change that nvidia-graphics-drivers-470 needs, ISTM that focal would need to have 1.1.7 (or later) SRUed, and bionic would need to get it uploaded as a new package. (Edit: hirsute is EOL)

I think this only makes sense for Impish and Jammy, where Wayland is the default.

Ah, I see, thanks for the clarification. Are you able to prepare an upload that adds the dependency?

Sure, I'll take care of the uploads.

Override component to main
egl-wayland 1:1.1.9-1.1 in jammy: universe/misc -> main
libnvidia-egl-wayland-dev 1:1.1.9-1.1 in jammy amd64: universe/libdevel/optional/100% -> main
libnvidia-egl-wayland-dev 1:1.1.9-1.1 in jammy arm64: universe/libdevel/optional/100% -> main
libnvidia-egl-wayland-dev 1:1.1.9-1.1 in jammy armhf: universe/libdevel/optional/100% -> main
libnvidia-egl-wayland-dev 1:1.1.9-1.1 in jammy i386: universe/libdevel/optional/100% -> main
libnvidia-egl-wayland-dev 1:1.1.9-1.1 in jammy ppc64el: universe/libdevel/optional/100% -> main
libnvidia-egl-wayland-dev 1:1.1.9-1.1 in jammy riscv64: universe/libdevel/optional/100% -> main
libnvidia-egl-wayland-dev 1:1.1.9-1.1 in jammy s390x: universe/libdevel/optional/100% -> main
libnvidia-egl-wayland1 1:1.1.9-1.1 in jammy amd64: universe/libs/optional/100% -> main
libnvidia-egl-wayland1 1:1.1.9-1.1 in jammy arm64: universe/libs/optional/100% -> main
libnvidia-egl-wayland1 1:1.1.9-1.1 in jammy armhf: universe/libs/optional/100% -> main
libnvidia-egl-wayland1 1:1.1.9-1.1 in jammy i386: universe/libs/optional/100% -> main
libnvidia-egl-wayland1 1:1.1.9-1.1 in jammy ppc64el: universe/libs/optional/100% -> main
libnvidia-egl-wayland1 1:1.1.9-1.1 in jammy riscv64: universe/libs/optional/100% -> main
libnvidia-egl-wayland1 1:1.1.9-1.1 in jammy s390x: universe/libs/optional/100% -> main

This bug was fixed in the package nvidia-graphics-drivers-495 - 495.46-0ubuntu3

---------------
nvidia-graphics-drivers-495 (495.46-0ubuntu3) jammy; urgency=medium

  * debian/templates/libnvidia-gl-flavour.{install|links}.in:
    Include libnvidia-vulkan-producer.so now that
    libnvidia-egl-wayland1 is in main (LP: #1935082).
  * debian/templates/control.in:
    - Add build dependency on libnvidia-egl-wayland1.

 -- Alberto Milone <email address hidden> Wed, 26 Jan 2022 16:56:33 +0100

This bug was fixed in the package nvidia-graphics-drivers-470 - 470.86-0ubuntu2

---------------
nvidia-graphics-drivers-470 (470.86-0ubuntu2) jammy; urgency=medium

  * debian/templates/control.in,
    debian/templates/libnvidia-gl-flavour.install.in,
    debian/templates/libnvidia-gl-flavour.links.in:
    - Add libnvidia-vulkan-producer.so and build depend on
      libnvidia-egl-wayland1 (LP: #1935082).

 -- Alberto Milone <email address hidden> Wed, 26 Jan 2022 17:20:50 +0100

The verification of the Stable Release Update for nvidia-graphics-drivers-470-server has completed successfully and the package is now being released to -updates. Subsequently, the Ubuntu Stable Release Updates Team is being unsubscribed and will not receive messages about this bug report. In the event that you encounter a regression using the package from -updates please report a new bug using ubuntu-bug and tag the bug report regression-update so we can easily find any regressions.

This bug was fixed in the package nvidia-graphics-drivers-470 - 470.103.01-0ubuntu0.21.10.1

---------------
nvidia-graphics-drivers-470 (470.103.01-0ubuntu0.21.10.1) impish; urgency=medium

  * New upstream release (LP: #1957790).
  * debian/templates/control.in,
    debian/templates/libnvidia-gl-flavour.install.in,
    debian/templates/libnvidia-gl-flavour.links.in:
    - Add build-dependency on libnvidia-egl-wayland1, and
      re-enable libnvidia-vulkan-producer (LP: #1935082).

 -- Alberto Milone <email address hidden> Fri, 28 Jan 2022 17:59:05 +0100