-
Notifications
You must be signed in to change notification settings - Fork 5
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
1.4 series is missing #16
Comments
I will try to find some time for this… :) |
Our PPA build pipeline uses dl.mumble.info to download source tarballs. With the migration into subfolders there it looks the our PPA pipeline broke back then for 1.3 releases too. |
I removed now unsupported Ubuntu versions. Our PPA is currently missing releases for Ubuntu versions Hirsute, Impish, Jammy (future LTS). The released and supported LTS versions are already there. I may have fixed the PPA scripts For 1.4 we changed our build pipeline to CMake, so additional adjustments will have to be made on the build scripts.(?) It’s unclear to me what the relationship between our four CIs is now, and which ones do the actual release, and whether the old PPA CI job on our older, internal CI is still being triggered. Related resources |
What four CI? Cirrus, Azure, GitHub Actions and AppVeyor? Cirrus and GA disqualify as one has nothing to do with Linux and the other has only been created long after the PPA pipeline. In terms of source tarballs: I think it would be better if the CI job checked out the repo via git and then simply creates a source tarball from that to upload on launchpad. And in terms of triggering, I think it's not a good idea to make the PPA depend on any CI in the upstream repo. |
Note also that there exists a PR in the main repo that is dedicated to get cmake deb packaging to work. It has stalled at figuring out the correct dependencies but other than that it already works, iirc |
Yes exactly 👍 |
Any chance to get an update to this @Kissaki ? Or is there not time at all? (completely understandable :) ) |
Update in what way? I am not working on this. I am not familiar with CMake, and find it hard to get into. Same with my build environment. Unfortunately, it doesn’t look like anyone else is picking it up either. |
oh boy. it's about a decade since i started to add Mumble PPAs to my systems after installations to always get the fresh stuff. what's changed since the last has been released via ppa? |
From what I understand, the new(?) Mumble build process doesn't work with the existing PPA infrastructure. FWIW, I ran the Docker build and just copied the binary out of the container image, out of desperation. This situation wouldn't be as bad if the Mumble team at least provided an official Linux binary. |
There was a major switch to CMake build toolchain with 1.4. That means the previous logic does not work anymore. |
I asked out of interest in #cmake:matrix.org and got the answer, if a developer wants to join the channel and asks for help about CPack, they(or at least one of them :D ) would be happy to support. |
The problem wasn't CPack, but dependency management |
I wonder if we should just set up our own APT repository, which could probably be used on most (if not all) Debian derivates. That is, as long as dependencies are satisfied. If they aren't, APT (or DPKG) shows a warning when installing the relevant package. |
+1 |
I am in favor of hosting our own APT. Would that be too much work? Would we be able to do the same thing for DNF or whatever for Fedora/Cent based stuff? |
I think whether or not we want to host our own APT is pretty irrelevant until we are actually able to build DEB (or other) packages in the first place 🤷 |
Just dropping by to mention that it'd be great to have working DEB packages (via Ubuntu PPA or some other means) again. |
I just add this here, it seems mumble-voip/mumble#5006 might resolve the problem or at least is a big step forward, if i understood Krzmbrzl correct :) |
Yes, indeed. To my understanding of things, once mumble-voip/mumble#5006 is completed, all that is left to do is upload the generated .deb somewhere suitable and the PPA should be up and running again. If you want to help move this forward, you could test the .deb package generated with the code from that PR. If you don't want to build Mumble yourself, let me know and I can give you the built package. |
I would be interested in testing the .deb package. While I have some experience compiling mumble, I think the safest bet is to provide me the .deb file. |
@ethaldeman thanks for volunteering. You can find the pre-built packages here. |
@Krzmbrzl All these tests were made on Ubuntu 22.04 and a mumble client compiled from github's master branch is also present on the computer. The client appears to be fully functional. I confirmed audio in and out, positional audio, and text-to-speech are working. I also connected to two different mumble servers. The server's deb successful installed, however I couldn't find anyway to interact with it beyond that. I tried running |
i tried on Ubuntu 20.04 but it fails:
|
@ViBE-HU you need to uninstall your current 1.3.4 mumble installation to continue. |
@ethaldeman you are right but it should not conflict. and here is another issue:
and if i try to start:
|
The method you used to install the |
i tried already via the store but it failed because of the dependencies. these packages are not available for 20.04 i guess. as far as i remember Mumble now use newer Qt:
|
@ViBE-HU
Why shouldn't it conflict? You have a completely unrelated package installed (from the package manager's POV) and now that new package tries to overwrite its files.
What about calling the installed binary from the command line directly? That should work, right?
Uhm... yeah the ini file should be under |
It seems the Ubuntu computer I was testing on may have had some old mumble-server services still hanging around, making it unclear what the server .deb was really installing. So I uninstalled the server .deb and then purged all the mumble-server services related items I could find. I then installed the .deb and executed the binary, located at So in summary, both the client and server .deb appear to be functioning on Ubuntu 22.04 with the note that the server .deb longer installs a mumbler-server service. In there are any specific aspects you would like me to test, just let me know. |
not exactly clear how DEB packaging works but as far as i understand how dependencies works maybe yes(?) i didn't know that this build is not related with the recent versions but the main issue are the dependencies. |
The package file should have installed |
@ViBE-HU I re-checked my packaging setup and those dependency versions are in fact those that I have written in the respective config. I have simply copied those from the mumble Ubuntu package, but that then presumably was the one from Ubuntu 22.04. For the time being though, I will not focus on making things work with anything before Ubuntu 22.04. We can focus on these things, once the package works fine on >= 22.04. |
I have confirmed the server .deb did install
|
Hm... then I guess I'll have to research a bit more and choose a different path for that 🤔 |
While I don't know what best pratices are, |
Have you opened |
It could definitely be that the service file is corrupt. I have no clue about that thing, so the chances that I made some sort of mistake is somewhat high here ^^ |
I dug into
After that I ran |
@ethaldeman these are valuable insights! As for the user, someone will have to look into how it is possible to make the deb create that on installation and how to generate the package via cpack in the desired way... |
While I still have not made much progress trying to understand how cmake actualy builds the server .deb, adding the user account should be achievable by having the .deb run |
Alright, I had another look at this. The reason why the paths in the service file are off is because those assume that things get installed relative to the value of (Maybe we can make use of CPACK_INSTALL_SCRIPTS to do the in-source patching for us. Though that will be a bit tedious since that might easily overlook a place where the paths require updating for things to work) In terms of the missing user, I was told that |
Update: It seems that we are already shipping a sysusers config file that seems like it should create the correct user entry: https://github.com/mumble-voip/mumble/blob/master/auxiliary_files/config_files/mumble-server.sysusers |
@Krzmbrzl Are the deb files you linked above still the best to use for testing, or is there a commit I should build from? If a commit, I will need general guidance for how to build the deb file unless they are a by product of the normal mumble build process. My Linux environment has undergone a lot of mumble deb testing and different versions, so I plan on testing in a clean Ubuntu 22.04 VM. I will install the deb and specifcy check if user In theory |
There have been only minor changes, but if you want to use to most up-to-date state (which I guess makes sense), you can simply build the package as follows:
In terms of the different install prefixes, I was told that there is no easy/standard way of doing this, so I'll have to improvise... |
I successfully built the deb files from your branch and ran
I also had this problem when I tried to install your deb file linked above. When I tested before on my Linux box, I didn't have this issue, but my brand-new VM is having this issue. A quick Goggle suggests Ubuntu 22.04 has dropped support for libssl1.1 and only supports libssl3 now. |
Ah yes, indeed. I have updated the dependency list to use |
I just saw that our sysusers config file gets installed to |
With the |
The wrong install paths of the sysusers config file should be fixed once mumble-voip/mumble#6100 is merged. |
Alright, I have just discovered CPACK_PACKAGING_INSTALL_PREFIX that should be able to help with the install path issues. |
See mumble-voip/mumble#5484
The text was updated successfully, but these errors were encountered: