Native installation for Ubuntu 22.04

[chreekat]

On 22.04 / x86_64, the following commands should get p4c installed:

echo 'deb http://download.opensuse.org/repositories/home:/p4lang:/latest/xUbuntu_22.04/ /' | sudo tee /etc/apt/sources.list.d/home:p4lang:latest.list
curl -fsSL https://download.opensuse.org/repositories/home:p4lang:latest/xUbuntu_22.04/Release.key | gpg --dearmor | sudo tee /etc/apt/trusted.gpg.d/home_p4lang_latest.gpg > /dev/null
sudo apt update
sudo apt install p4lang-p4c

-- https://software.opensuse.org/download.html?project=home%3Ap4lang%3Alatest&package=p4lang-p4c

This is based on https://github.com/chreekat/p4lang-packages/pull/2 . (I intend to move into that project into the p4lang organization.)

The instructions above pull from a new OBS project, home:p4lang:latest. It is a staging ground where I published new debs based on the latest tagged releases of pi, bmv2, and p4c. The fate of this new project is undecided.

All of this is preliminary. I just wanted to get the information out about the new packages. @jafingerhut if you have a chance to try it out and identify any problems or gaps, that would be great.

[jafingerhut]

Thanks!

Out of curiosity, is this x86_64 processor architecture only? Or would you expect it also to work for aarch64?

If only x86_64, that is fine. I will be able to try it out early next week after returning from my current travel.

[chreekat]

Great question! I had started small with one distro × one architecture.

I just enabled aarch64. You can watch the progress at https://build.opensuse.org/project/monitor/home:p4lang:latest?arch_aarch64=1&blocked=1&broken=1&building=1&defaults=0&deleting=1&dispatching=1&failed=1&finished=1&locked=1&repo_xUbuntu_22_04=1&scheduled=1&signing=1&succeeded=1&unresolvable=1

I'm about to head to bed, but you should be able to see if it worked in 1-2 hours.

[chreekat]

All the aarch64 packages seem to have built. The installation instructions are the same.

[jafingerhut]

I tried it out on an x86_64 Ubuntu 22.04 system. The install steps you gave worked just fine. I tested the p4c-bm2-ss binary and p4c Python program installed in a few small things, and they seemed to work as expected. Great!

It does seem that the list of packages that p4lang-p4c depends upon is more than p4c requires:

Depends: libboost-iostreams1.74.0 (>= 1.74.0), libc6 (>= 2.34), libgc1 (>= 1:8.0), libgcc-s1 (>= 4.2), libstdc++6 (>= 11), libz3-4 (>= 4.8.12), python3:any, cpp, libboost-dev, libboost-all-dev, libboost-graph-dev, libboost-iostreams-dev, libfl-dev, libgc-dev, libgmp-dev, libbpf-dev, pkg-config, tcpdump, libelf-dev, llvm, clang, iproute2, net-tools, python3-grpcio, python3-pyroute2, python3-ply, python3-scapy, python3-setuptools, python3-thrift, python3-protobuf, libprotobuf-dev, libprotoc-dev, protobuf-compiler, libgrpc-dev, libgrpc++-dev, protobuf-compiler-grpc, libthrift | libthrift-0.11.0 | libthrift-0.13.0 | libthrift-0.16.0 | libthrift-0.17.0, libthrift-dev, thrift-compiler, p4lang-bmv2

I agree with these dependences, which I believe are required for most or all of the installed binaries like p4c-bm2-ss to execute:

• libboost-iostreams
• libstdc++6
• libc6
• libgc-dev

and maybe one or two others I am neglecting to include.

The packages with python in their names should definitely not be needed in order for the p4c executables to run (correction: python3:any is probably required). Nor scapy, protobuf, or thrift. No libboost libraries other than libboost-iostreams seem to be required.

Do you know of any reason why those things should be in the dependencies of the p4lang-p4c package?

[chreekat]

Hm yep, there's an explanation for that. The debian control file lists all the build-time dependencies as runtime dependencies. I'm going to try to push an update to those packages today.

[chreekat]

Building now: https://build.opensuse.org/project/monitor/home:p4lang:latest?arch_aarch64=1&building=1&defaults=0&repo_xUbuntu_22_04=1

[chreekat]

Built successfully. :)

BTW the problem already existed in the p4lang-packages repo before I started messing with it. There are probably other cleanups I could do, so let me know if you see any other oddities.

There's a number of parallel tracks I could take, now that I've got builds of recent packages for a single OS. I'll probably start by getting builds on more recent Debian/Ubuntus.

[jafingerhut]

It appears that the package p4lang-p4c has package p4lang-bmv2 as some kind of dependency, such that if you install p4lang-p4c, by default it also installs p4lang-bmv2. I'd recommend removing that dependency. Each of those packages should be independently installable, I think. It is true that there are many p4c test cases that require p4lang-bmv2 executables in order to run, but I don't think that should cause an install dependency between those packages.

[chreekat]

Indeed -- it looks like p4c has bmv2 under "Recommends", and apt install recommended packages by default.

That means if you use "apt install --no-recommends p4lang-p4c", it should leave out bmv2.

However, I've always thought that the Recommends machinery is a little suspicious, especially if the recommended packages are kinda big. I think I'll remove the recommendation.

[chreekat]

By the way, do you think it makes sense to drop the "p4lang-" prefix? Should the debian packages just be named p4c and bmv2?

[jafingerhut]

Pinging @fruffy for his opinion, too.

My personal belief is that keeping the p4lang- prefix in these package names is a good idea, given that p4lang is fairly niche, and keeping that in the package names makes it more obvious from the name itself what the package is for.

[fruffy]

Yes, we should namespace this. Also to show that these packages are provided by the p4lang org.

[jafingerhut]

@chreekat I have created a bash script that I have successfully tested on an x86_64 Ubuntu 22.04 VM, which installs p4lang-p4c and p4lang-bmv2 packages, and also Mininet and several Python packages into a venv, and after that script runs I can successfully run several tests and tutorials from the tutorials repository, as well as some tests from my personal repository https://github.com/jafingerhut/p4-guide

Excellent! I would say that these apt packages are ready to publicize for use by others. I'd also ask how much work you think it might be to create similar x86_64 and aarch64 packages for Ubuntu 24.04?

Note: I have had difficulty creating aarch64 Ubuntu 22.04 VMs on my personal Apple Silicon Macs, so have not tried testing out your aarch64 Ubuntu 22.04 apt packages.

FYI, that bash script can be found here: https://github.com/jafingerhut/p4-guide/blob/master/bin/install-p4-tools-via-ubuntu-apt-packages.sh

I will likely copy that bash script into the tutorials repository after I have tested it to work on Ubuntu 24.04. I don't have any scripts that are tailored specifically for Ubuntu 22.04 for the tutorials repository, and do not plan to add any, since Ubuntu 24.04 is already well supported.

[chreekat]

Great!

Creating 24.04 packages should not take very much time. I'm still cleaning up the prototype that generated the 22.04 packages, but once that's done, I will do 24.04 next.

One small blocker stands in the way of publishing these debs more widely. But I think I've made a decision about it.

The potential blocker is that OBS seems to have a non-atomic, unreliable mirror system. And the resolution: I think we'll just try it for a while, anyway.

The linked problem was exacerbated when I uploaded a different .deb with the exact same version. I'll just... not do that. Each upload -- even if the underlying version is the same -- can get a new deb version. Debian versioning is designed just to support this. This may help avoid the digest conflicts. I think we'll find out quickly if this is a sustainable choice.

Oh, one other thing: I'll switch to the "official" OBS project, home:p4lang once the cleanup is done. I don't think we need home:p4lang:latest.

[jafingerhut]

Making every upload a distinct name/version combination sounds like a good idea, given the problems you encountered earlier. Write once only!