Deb/PPA packaging?

[BloodyIron]

Any chance we could see this with a DEB packaging for releases or perhaps a PPA? :)

[flightlessmango]

I don't have any experience with packaging or PPA so I won't be doing it, but anyone who is willing can do it

[BloodyIron]

And releasing deb packages on the releases section? Would you be game for doing that? :)

[stephanlachnit]

I will look into packing it for Debian, shouldn't be too hard thanks to meson.

[BloodyIron]

Yay! :D

[stephanlachnit]

I don't see any problems with building or dependencies on Debian so far, however right now the build requires networking for the Dear ImGUI module. This is something which is not allowed in Debian, so there would be some changes required. Right now I try to get a build system (meson) for Dear ImGUI upstream to simplify packing it for Debian (ocornut/imgui#3060), then I would propose to use it here as a fallback via wrap.

[jackun]

Just making a MangoHud source package with meson dist would be enough?

[stephanlachnit]

Enough to build it from a source tarball, yes. I still prefer wrap and a proper submodule, that way you eliminate the need of a git repository for building from your actual working dir (aka not the source tarball, helpful but not strictly necessary). See #83.

[stephanlachnit]

Just making a MangoHud source package with meson dist would be enough?

@jackun @flightlessmango can you release a complete source tarball for 0.3.1? Then I could start working on the package. Best just call it v0.3.1.tar.gz to replace github's tarball.

[stephanlachnit]

Thanks for uploading the source tarball for v0.3.1, however you forgot to include hidden files (the .github dirs to be precise), and the Debian build system is veeery nitpicky when it comes to source differences. I can do an exception in the build files for this release, but please include it in the next one if possible.

[jackun]

I blame meson dist :P

[stephanlachnit]

I don't think 0.3.1 tag had any.

It did, but even if not Dear ImGui's .github/ was missing as well.

I blame meson dist :P

Ahh that makes sense. I'll guess I'll need to contact Meson then that they maybe should include everything.

Anyway, the first build attempt is up on salsa. It does build just fine as far as I see it, but when I was looking into the copyright situation I got some headaches.
Apart from the fact the Dear ImGui is a bit messy regarding copyright (still manageable, but I haven't done it yet), I'm pretty sure the NVIDIA license note in nvml.h is not DFSG compliant, which is basically the open source definition. Debian takes copyright veeery seriously, the license of every file needs to be specified.
I'm no lawyer though and I will ask some people in the nvidia team of Debian if this may could still land in non-free if it really breaks with the DFSG, we'll see.

[noah1510]

How did you even get it to build the package?
On my machine I could create the source package (after modifying the control and adding the missing compat file) but I had no success in building the package.
I tried to build it using debuild the same tool used for creating and building packages for a ppa and my machine runs linux mint 19.3 (based on ubuntu binoic which was my target).
My problem was that the script needs root privileges to call sudo but normally you try to prevent calling debuild with sudo so the whole dependencies function of the script has to rewritten possibly with proper exit codes.
Do you see any other way or is this something that has to be done?

[jackun]

Something is up with source tar but just running debuild -- binary worked for me. Any way for debuild to install deps itself automagically?

[stephanlachnit]

(after modifying the control and adding the missing compat file)

There should be no compat file, your build system is just way out of date (Ubuntu 18.04 is really old and does not have debhelper 12). Install debhelper 12 from backports.
What did you change in the control file though?

How did you even get it to build the package? [...] My problem was that the script needs root privileges

Hm weird, it worked for me, which script do you mean exactly? Can you try it with Rules-Requires-Root: binary-targets in the control file? (added in debian-policy 4.1.5, boinic was created with 4.1.4 so I guess it doesn't work without backports)

Any way for debuild to install deps itself automagically?

You can setup pbuilder and run pdebuild, that does build in a clean chroot and installs all dependencies (and hence you will see if you missed something), but it takes ages to build.
But else no, I'm not aware of a feature like this during building.

[noah1510]

Thanks for the help after installing all the dependencies (including debhelper from the backports) it starts to build the package but gets an error while compiling meson.build:194:2: ERROR: File /usr/share/vulkan/registry/vk.xml does not exist.
What is happening here I don't even have a registry folder inside of /usr/vulkan so meson complains when calling debuild -- binary but ./build.sh build works just fine.

Can you try it with Rules-Requires-Root: binary-targets in the control file?

I can change it however I want this error still happens.
Do you know what went wrong?

What did you change in the control file though?

I tried to change the control and rules file to get them working without debhelper 12 but with the backports it is sort of working.

[stephanlachnit]

meson.build:194:2: ERROR: File /usr/share/vulkan/registry/vk.xml does not exist.

This is due to Run-time dependency vulkan found: YES 1.1.70, you need >=1.1.74. Maybe the version from disco works (install the .deb manually). If not, you can change the rules file to:

override_dh_auto_configure:
	dh_auto_configure -- -Duse_system_vulkan=disabled

However the source tarball does not include the Vulkan Headers, so you need exclude the diff in the debian/source/options file. This won't be the case once #83 is merged, then it's pretty easy to include all subprojects in the source tarball.

[noah1510]

Is version 1.1.74 really needed because of features or is it just the latest version you can test. I don't like to manually installing package because of the missing updates.
What about shipping an updated version of libvulkan-dev in the same ppa of the newer version is necessary?

At the moment Ubuntu 18.04 (and distros based on it) is still one of the most used version. Yes a lot of packages are outdated (so I have to use the oibaf ppa and install the newest kernel using mainline) but it somehow works reliably and I don't think it is a good idea to abandon a really large user base.

[stephanlachnit]

Is version 1.1.74 really needed because of features or is it just the latest version you can test.

Yes it is. Before that version there is no vk.xml so no chance.

I don't like to manually installing package because of the missing updates.

I don't really understand what you mean here. disco is old-stable (soon old-old-stable) for Ubuntu so there will be no new updates for disco. Bionic won't get any Vulkan updates either, not even in backports.

At the moment Ubuntu 18.04 (and distros based on it) is still one of the most used version. Yes a lot of packages are outdated (so I have to use the oibaf ppa and install the newest kernel using mainline) but it somehow works reliably and I don't think it is a good idea to abandon a really large user base.

First of all, I'm not a member of MangoHud, I'm just building a deb for the distro I use, which is Debian Sid (or "unstable"). I don't abandon anyone.
Second of all, if you want to use a "stable" distro (which is perfectly fine, I'll use these myself for certain applications), don't except new software to run on that machine, that just now how LTS releases work.

If you want to have a deb anyway, you have two options:

• create your own PPA with the change in the rules file I mentioned before
• create your own PPA with an updated version of libvulkan-dev

I won't maintain a PPA, I'm sorry, it's just not what I use.

[Batcastle]

I'm working on packaging this as a *.deb right now. Calling ./build.sh package got me most of the way done.

All I need now are the dependencies. From what I can tell, the only package required to be installed with the MangoHud binaries, etc, is libvulkan1 Is this correct?

[stephanlachnit]

I'm working on packaging this as a *.deb right now.

I already did it (source is on salsa), so you don't need to do it again, except of course if you want to do it for bionic, but I already wrote what's necessary for that. The only thing left for a Debian Policy compliant package is a solution for #121 and the full copyright information from Dear ImGui.

Calling ./build.sh package got me most of the way done.

That is not how a deb should be build, it should invoke the build system itself (aka meson).

All I need now are the dependencies. From what I can tell, the only package required to be installed with the MangoHud binaries, etc, is libvulkan1 Is this correct?

You can check the dependencies for building on my salsa, if you want to have the runtime dependencies check what shlibs:Depends will be replaced with.

[noah1510]

I got the package to build by using the vulkan backports ppa and it seems to work.

I will try uploading it to a ppa to test if I get that to work.
However I don't get the source package built any idea what might help to get it working?

[stephanlachnit]

Can you send me the debuild log?

[noah1510]

running debuild -S -sa causes this.
It seems like a source package is needed for debuild to work nicely with quilt.
Would it be possible to siply change the format to native which works?

[stephanlachnit]

running debuild -S -sa causes this.

The problem is not in the build files, this is the problem:

dpkg-source: error: can't build with source format '3.0 (quilt)': no upstream tarball found at ../mangohud_0.3.1~bionic.orig.tar.{bz2,gz,lzma,xz}

I'm not quite familiar how Ubuntu handles it, but it should just be the renamed upstream source tarball.
Since I added a watch file, you can also run uscan -dd -vv, it should download the upstream source tarball and symlink it.

It seems like a source package is needed for debuild to work nicely with quilt.

The source package is not necessary (at least not for bulding), running debuild gives the deb. The quilt format is the default format for Debian packages these days, it doesn't require any additional steps.

Would it be possible to siply change the format to native which works?

Yes, it would work, but there are a couple of reasons against it. Native packages are intended for programs which just don't make sense on other distros, for example apt has no "upstream" without Debian packaging. It removes all checks for source diffs (this is exactly why it works for you) so it's handy for testing purposes, but it also assumes a lot of stuff you don't want in a release file.
For example, you can't use a watch file to check new upstream versions (bad practice but not the end of the world), you can't do revisions, i.e. when you did an error on version 0.3.1-1 and want to correct it with 0.3.1-2 (very bad), just because there only is 0.3.1, and you don't have a control instance which checks for accidentally modified files (and now don't forget that you can't do revisions). So overall, do everything you can to not pack it as native.

I will try uploading it to a ppa to test if I get that to work.

Btw before you promote it, the copyright file is still partially incorrect (I just didn't bother to invest the time yet), so be aware of that, and don't forget to mark it as non-free (change the section to non-free/games) as it is not free with nvml.h (#121). You may want to wait until a version with #122 is released, I'll update my source then (before doesn't make sense, it will be rejected).
And you may want to force the libvulkan-dev package to be >=1.1.74 so nobody accidently tries to build it with the version from bionic.

[noah1510]

I'm not quite familiar how Ubuntu handles it, but it should just be the renamed upstream source tarball.
Since I added a watch file, you can also run uscan -dd -vv, it should download the upstream source tarball and symlink it.

Thanks for the help that got the package to work.
For uploading to launchpad it is required to set the distribution to the required value so I simply added a new changelog entry using dch by appending ~b to the version number and setting the distribution to bionic.
I also had to add the oibaf graphics driver ppa and vulkan backports ppa as a ppa dependency in order to have packages with the version requirements.

And you may want to force the libvulkan-dev package to be >=1.1.74 so nobody accidently tries to build it with the version from bionic.

I create a merge request to your repository which added the required version information to the control file.
Do you know which version of meson is needed because the build fails on launchpad without adding the oibaf graphics driver ppa ?
It should be between 0.45.1 and 0.51.2.

Also thanks for the detailed explanations it makes it really easy to get this to work on other distributions and helps (at least me) understand why things are done this way.

[jackun]

0.47 for feature get_option() , 0.49 for not having to use conf = configuration_data() and 0.50 to use a super advanced feature like line breaks using \ 😒

[stephanlachnit]

Also thanks for the detailed explanations it makes it really easy to get this to work on other distributions and helps (at least me) understand why things are done this way.

You're welcome. Creating a deb isn't exactly easy in the beginning, but once you master it you start to appreciate it's pedanticness.

[stephanlachnit]

@flightlessmango @jackun can you upload the source packages from build-source.sh for v0.3.5? With the DFSG compliant archive I can try to get MangoHud uploaded to Debian.

[jackun]

Did it need to be exactly at tag? It might need a commit with version.h generation dependency. Probably have to retag it anyway.

[stephanlachnit]

I should be exactly at the tag, if there is a fixup I can patch it.

[stephanlachnit]

@noah1510 if you're still interested in doing the PPA, I got everything for v0.3.5 up on Salsa, including a full copyright (except for include/nvml.h since I used the DFSG tarball). You might want to use the shipped NVML for the PPA though.

[noah1510]

I'm on it but there seems to be a problem when downloading the source tarball using uscan -dd -vv.
You can find the log here.
It seems like libxnvctrl-dev is missing in the build dependencies and libnvidia-ml-dev does not exist for bionic but building for focal seems to work.
Do you an idea how to get around the issue with the missing libnvidia-ml-dev for the bionic build?

[stephanlachnit]

Ah sorry I haven't mentioned I pushed a fixup today. Latest sources should work. Btw I now use debhelper compat 13, you might want to downgrade that to 12 for bionic.

It seems like libxnvctrl-dev is missing in the build dependencies

Whoops, yeah I could add it, instead I disabled xnvctrl completely. If you wait 15min I push a fixup for that.

Do you an idea how to get around the issue with the missing libnvidia-ml-dev for the bionic build?

Yes, just don't use -Duse_system_nvml=true in the rules file and remove the "-DFSG" part from the watch file. You can remove libnvidia-ml-dev from the control file as well. If you're publishing it in a PPA, it shouldn't matter anyway, I just do it to get it in the Debian archives.

[noah1510]

Thanks for the advice I got the package to build for bionic and it seems to work just fine.

[stephanlachnit]

@jackun @flightlessmango can you release the source tarballs for 0.4.0 generated from ./build-source.sh?

[jackun]

@stephanlachnit check it
E: ugh, i keep forgetting the submodules

[stephanlachnit]

Thanks! Hopefully I get this version sponsored^^

[jackun]

Quick bug ifx 0.4.1 incoming 💯

[stephanlachnit]

@noah1510 are you still working on a PPA? I got the build files for 0.4.1 up here: https://salsa.debian.org/games-team/mangohud/-/commit/5d7b889ed9bdcfb00f89600c1382b116b8455b05

For Ubuntu you probably want to build with NVML, I added an explanation how to do it in debian/README.debian.

[SwampRabbit]

@stephanlachnit I am able to build mangohud for a Debian 10 base with pbuilder using the dfsg source and your debian directory, but upon install none of the mangohud config files exist as per https://github.com/flightlessmango/MangoHud#hud-configuration. I'm not even sure the built package is good at all honestly.

Also I had to build with newer build depends than what ship with Buster in my local repo, trying to build on a Buster base failed. By chance are there specific versions for the build depends that should be used?

I'm going to see if the openSUSE Build Service can build this for Buster and Bullseye and if the package comes out fine.

[stephanlachnit]

No config files is installed by the upstream build system, so I won't add one either. You can use the example config file (for the location see the readme). You can also use GOverlay (check my Salsa, you can find the build files for Debian there).

At least for me, the package builds just fine, tested it and it worked.

I'm running Sid, so I can't tell you exactly what I used when I builded it the last time. You can change pbuilder to use the Sid repos though I think.
I suspect it's probably due to libvulkan-dev, but I'm not sure.

[SwampRabbit]

No config files is installed by the upstream build system, so I won't add one either. You can use the example config file (for the location see the readme). You can also use GOverlay (check my Salsa, you can find the build files for Debian there).
....
I suspect it's probably due to libvulkan-dev, but I'm not sure.

ah ok, thanks, I just assumed that a default was created under
$HOME/.config/MangoHud/MangoHud.conf

I should probably figure out how it all works lol ;)

The dependency thing isn't a problem really either, I did and plan on building against whats in Sid anyway for the most part.

I plan on getting to GOverlay soon.

Thanks again!

[stephanlachnit]

Just for reference, Dear ImGui is a major blocker for a Debian package. I got a response from a DD: https://lists.debian.org/debian-devel-games/2020/06/msg00010.html

In a nutshell, some of the files included in ImGui make it impossible to distribute it within Debian, and I'm not a big fan of repacking MangoHud by hand every single time. Easiest solution is #153.

[stephanlachnit]

@jackun can you upload the DFSG source package for 0.5.1?

[jackun]

Doh, right.

[noah1510]

I created this ppa where the debian package source is automatically built.

Because the debian source is for debian sid, the focal packages are too old, so its only able to build for groovy. which will be out this month Ubuntu 20.10 (groovy) is officially released now.

Unless somebody want to handle the releases, the automatic build will only work for the latest ubuntu version because debain sid packages tend to be on the latest debhelper-compat version which is only part of the latest ubuntu version so when debain introduces a new debhelper version, the package will be broken for every ubuntu version except the latest.

[stephanlachnit]

Can be closed, an official Debian package is now available: https://tracker.debian.org/pkg/mangohud

[noah1510]

automated ubuntu builds also work.
You can get the package for groovy and hirsute: https://launchpad.net/~noasakurajin/+archive/ubuntu/useful-tools

[flightlessmango]

@noah1510 does that build include nvml and xnvctrl?

[stephanlachnit]

Iirc not NVML, xnvctrl if the lib is installed (will be suggested to the user during installation).

Someone did a PPA with (system) NVML enabled: https://mobile.twitter.com/m_wimpress/status/1337782085025673222

But besides that both are identical to the Debian package.

[noah1510]

@flightlessmango I don't think it does. It is simply a build of the debian sid sources without any modifications.

[flightlessmango]

I assume it's safe to close this by now