[needs-packaging] intel-dpcpp

[Will French]

The DPC++ compiler is a LLVM-based compiler project that implements compiler and runtime support for the SYCL* language. We have worked with Intel to create and test this compiler in a PPA (linked below).

[needs-packaging] intel-dpcpp

Upstream: https://github.com/intel/llvm
Upstream branch: sycl
Upstream tag: v6.2.0
License: Apache 2.0 (components from Intel's LLVM fork), various others for upstream LLVM
Target OS Release: 26.04 only
PPA: https://launchpad.net/~kobuk-team/+archive/ubuntu/oneapi-release?field.series_filter=resolute
Source package in PPA: https://launchpad.net/~kobuk-team/+archive/ubuntu/oneapi-release/+sourcepub/17790840/+listing-archive-extra
Source package in GitHub: https://github.com/canonical/oneapi-packaging/tree/resolute/compiler

Note I am also submitting separate needs-packaging bugs to add two build-time dependencies for the compiler:

- intel-umf source package: https://bugs.launchpad.net/ubuntu/+bug/2130189
- emhash source package: https://bugs.launchpad.net/ubuntu/+bug/2130190

In addition, note that to create a stable build we vendored two build dependencies. An explanation of this vendoring can be found here: https://github.com/canonical/oneapi-packaging/blob/compiler/package-improvements/compiler/debian/README.md

[Brian Murray (brian-murray)]

*** This is an automated message ***

This bug is tagged needs-packaging which identifies it as a request for a new package in Ubuntu. As a part of the managing needs-packaging bug reports specification, https://wiki.ubuntu.com/QATeam/Specs/NeedsPackagingBugs, all needs-packaging bug reports have Wishlist importance. Subsequently, I'm setting this bug's status to Wishlist.

[Will French (wfrench)]

The package build on resolute is currently failing due to an incompatibility with the version of the opencl-headers that ships with resolute. This is not an issue on questing or plucky. I have reached out to the DPC++ compiler development team to notify them. Ideally this would be fixed upstream in an upcoming release, as vendoring an old version of opencl-headers may lead to runtime conflicts. More details can be found in the GitHub issues below.

https://github.com/canonical/oneapi-packaging/issues/16

https://github.com/intel/llvm/issues/20511

[Will French (wfrench)]

The build failure on resolute has been resolved using a small patch from upstream, and I have verified that all autopkgtests for the intel-dpcpp and onedpl on resolute using the resulting packages from the oneapi-release PPA.

[Antoine Lassagne (antoinelassagne)]

Hello,

I had a quick look and can give you some improvement tips:

- It's not very clear which package the reviewer shall review. I used the master branch of your repo, and the Resolute upload on your PPA, but unsure it's the latests? There seem to be other packages in the mix, too (onednn, etc.)
- You must reference the LP bug number in the changelog. I think the changelog must be clean for the first upload, with only one entry.
- You mention that you don't have a manpage yet. You can generate one with help2man for example. See here [1] for an example.
- You have a lot of lintian errors. Run lintian -EvIL +pendantic against both the .changes file and the built .deb
- There seem to be a few vendored things in there. Not sure it's a blocker for Ubuntu, but listing them in a readme would be helpful.
- The copyright file is surprisingly small given the size of the package. I've ran `licensecheck --check '.*' --recursive --deb-machine --lines 0 -- *` to compare, but the result is awful. nYou should double check it, and at least the vendored stuff must be mentioned in the copyright file (if you keep it)
- Are you running any of the provided build-time tests? if no, you should probably
 do so. Either way, you can also add the integration tests as autopkgtests, to harden this package against the rest of the archive.
- libumf-dev does not look to be in the archive. I don't see in the sponsorship queue, either.

[1]: https://git.launchpad.net/ubuntu/+source/spirv-reflect/tree/debian/rules#n12

[Will French (wfrench)]

Thanks for the feedback!

> - It's not very clear which package the reviewer shall review. I used the master branch of your repo, and the Resolute upload on your PPA, but unsure it's the latests? There seem to be other packages in the mix, too (onednn, etc.)

See the resolute branch on GitHub for the latest version which matches what is in the PPA: https://github.com/canonical/oneapi-packaging/tree/resolute/compiler

> - You must reference the LP bug number in the changelog. I think the changelog must be clean for the first upload, with only one entry.

Will do. Just to clarify, by "clean" do you mean only a single entry? If so I guess I'll need to publish the package (and others I'm submitting) to a new PPA.

> - You mention that you don't have a manpage yet. You can generate one with help2man for example. See here [1] for an example.

Thanks, help2man looks useful. The compiler commands do accept a --help flag so hopefully this will work.

> - You have a lot of lintian errors. Run lintian -EvIL +pendantic against both the .changes file and the built .deb

I have only run vanilla lintian (without extra flags) until now, I'll try with the additional flags and address as much as I can.

> - There seem to be a few vendored things in there. Not sure it's a blocker for Ubuntu, but listing them in a readme would be helpful.

I currently have it documented here: https://github.com/canonical/oneapi-packaging/blob/resolute/compiler/debian/vendor.sh#L22-L35

But adding those details to a README is a good idea.

> - The copyright file is surprisingly small given the size of the package. I've ran `licensecheck --check '.*' --recursive --deb-machine --lines 0 -- *` to compare, but the result is awful. nYou should double check it, and at least the vendored stuff must be mentioned in the copyright file (if you keep it)

You may have been looking at a previous version that was incomplete. The version now (https://github.com/canonical/oneapi-packaging/blob/resolute/compiler/debian/copyright) is consistent with the copyright file for upstream LLVM plus new paths for the Intel-specific OpenAPI compiler work. I have not added paths for the vendored components, but I will do that soon.

> - Are you running any of the provided build-time tests? if no, you should probably
 do so. Either way, you can also add the integration tests as autopkgtests, to harden this package against the rest of the archive.

We stripped out a lot of the build-time tests that are already performed by upstream LLVM, but you're right that there are definitely some tests that are specific to Intel/oneAPI that could be added.

As for integration tests, we created our own autopkgtests for the compiler. Do you mean that we need more or should take some from upstream?

> - libumf-dev does not look to be in the archive. I don't see in the sponsorship queue, either.

It's one of the build dependencies for the compiler that is also now packaged in the PPA (see source package definition here: https://github.com/canonical/oneapi-packaging/tree/resolute/umf/debian). I edited the ticket description to include links to the needs-packaging requests for build-time dependencies of the compiler that are n...

[Will French (wfrench)]

I have addressed Antoine's feedback in this PR: https://github.com/canonical/oneapi-packaging/pull/21

The updated version is now published to https://launchpad.net/~kobuk-team/+archive/ubuntu/oneapi-release

[Frank Heimes (fheimes)]

I did another review, squashed the changes to an "initial package upload" and an Xubuntu1 version, build a src package, ran lintian on it, build the bin packages, and ran again lintial on them and finally uploaded - it's now in the new queue.