Fix up all dependencies on all OSes to have matching versions and patches.

[mkrautz]

Right now, not all dependencies are up-to-date on all platforms for 1.3.x.

In particular, libsndfile and Ice.

We should fix that before 1.3.0 beta.

[Kissaki]

For Windows, this would be mumble-releng.
What does this mean for mac and linux?
For Ubuntu, we have a PPA that should build but we have no control over lib versions.
Where/what else would I look for?

[mkrautz]

For Mac and Linux it's also mumble-releng (buildenv/1.3.x/centos-ermine and buildenv/1.3.x/osx and buildenv/1.3.x/osx-universal)...

I guess this is mostly on my table though :)

But buildenv/1.3.x/centos-ermine can be updated mostly anywhere. It doesn't "need" to be a CentOS 5.9 box, an Ubuntu will do -- it should build there just fine. However, it'll probably need some fixups to actually build on CentOS 5.9.

[C0rn3j]

Since this is pretty much the last blocker for 1.3 release that can't be resolved almost immediately, what's the status on it?

However, it'll probably need some fixups to actually build on CentOS 5.9.

I see you're concerning yourself with an OS that was already EOL by the time you posted it, why?

[Morgyn]

Is there a list of target OSs?

[xnox]

Is there anything not up to date on Ubuntu that you need to release 1.3? I can update anything...

[AzP]

Does Mumble really need to concern itself with library versions in older (EOL) distributions? I thought the package maintainers for different distributions took care of most of the issues, allowing Mumble to focus on developing and releasing new versions.

[mkrautz]

We use CentOS as a base to get a good baseline libc that is compatible with older kernels.
Back when we initially did 1.2.5 (or 1.3.0 as it has become known), it wasn't as far-fetched as it sounds now.

Basically, our buildenvs are small distributions of their own. They only contain the dependencies that are relevant to us.

We aren't concerning ourselves with libraries for CentOS. We're concerning ourselves with the libraries that we link against in our "static"/AppImage build of Murmur on Linux. We use the same version of libraries with the same patches applied on all platforms we ship on.

[malteme]

@mkrautz Any progress on this issue?

[C0rn3j]

Alright so this is the sole remaining issue for getting 1.3 out I guess.

What's the status on each Linux, Windows and macOS? I know that Ubuntu PPAs were fixed but that's about it.

Would it still be possible to tag a 1.3 release without releasing a build yet? Distros build from source anyways so this would enable Linux distros to build a 1.3 stable.

[promi]

It is important to make a 1.3 release branch and stabilize that, so distros have a known working version of the software again.

Why should the release be delayed any further by the build infrastructure? Can't that be fixed during the beta phase?

I vote for moving it from P0 to P1, so the beta can be started.

[anarcat]

i would punt this in the court of distributions, to be honest... debian is shipping the git snapshot of mumble 1.3, for example...

[promi]

i would punt this in the court of distributions, to be honest... debian is shipping the git snapshot of mumble 1.3, for example...

That is a support nightmare. The idea of a stable version is that you have one version that you can report bugs / security issues against, etc. If everyone is maintaining their own git snapshot of Mumble work is duplicated.

[anarcat]

On 2019-01-16 22:15:23, Phobos wrote: > i would punt this in the court of distributions, to be honest... debian is shipping the git snapshot of mumble 1.3, for example... That is a support nightmare. The idea of a stable version is that you have one version that you can report bugs / security issues against, etc. If everyone is maintaining their own git snapshot of Mumble work is duplicated.

Yeah well, that nightmare is happening because there's no official release of course.

[AzP]

I think tagging a release and getting some sort of release out (even if it is an _rc1) is better than not having one, since some distributions will either start shipping the git HEAD (which I believe most of them are adamant to do) or simply remove the package completely.
Instead of tagging a rc1, perhaps it's better to just release a buggy version, to get a build into distributions, receive bug reports and release a patched release ASAP.

[VVD]

FreeBSD is in state of removing Qt4 from ports now. All dependent from Qt4 ports will be removed soon, mumble and murmur 1.2.19 too.
Please, make release 1.3.0 before 1.2.19 removed.

[VVD]

It was just removed:
audio/mumble||2019-03-16|Has expired: Qt4 has been EOL since december 2015
audio/murmur||2019-03-16|Has expired: Qt4 has been EOL since december 2015
Please, make release 1.3.0!

[davidebeatrici]

#2728 (comment)

[VVD]

mumble and murmur 1.3.0-r1 are in FreeBSD ports again!

[cknost]

I think this is no longer a problem, because there are appimages now.

[Kissaki]

@davidebeatrici @Krzmbrzl @ZeroAbility What’s the status of this ticket? It’s still labelled P0 Blocker. From the ticket description and followup comments it’s not really clear what it is about specifically?

I don’t think we want to change anything for 1.3 anymore in this regard? For 1.4 we already use up to date stuff? Is anything still open for the appimage or centos stuff then? I believe we dropped the old centos static binary?

[davidebeatrici]

Correct, all dependencies are synced for 1.4.x.

[Krzmbrzl]

Yep I think so to. Thus I'll close this issue ☝️

Is anything still open for the appimage or centos stuff then?

Well the AppImage is currently broken in the first place but if it weren't the dependencies should not be an issue since they are now managed by vcpkg.