Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[bob]

We are considering going to stretch for the amd64 build since it will give us the capability amongst other things to let us use gpu accelerated video decoding for h.265.

We tried this about a year ago but reverted to Jessie since the other distros we were trying to stay compatible with weren't quite able to deal with the updated libraries stretch required.

This change would leave behind some not very current distros. In this case we'd recommend running the i386 version (which would remain jessie for the time being) with a multiarch enabled distro.

Looking for comments...

Thanks.

[Awesome Donkey]

If I recall, Linux Mint was one of the main issues when you guys tried it a year ago because its libraries were too out-of-date. But that's not an issue anymore, with the releases of Linux Mint 19 and elementary OS 5.0.

Though I suppose Ubuntu 16.04 LTS might be an issue, not sure. If it is an issue you might consider adding an additional repository for the last working build for those older platforms. Something like a legacy-stable repo or something like that. That way both the amd64 and i386 builds can be updated to Stretch and you can keep an older compatible, stable build in a different repo - 24.0.64-3 has been pretty stable, so it could be a good candidate. I suppose even the arm build could be updated to Stretch too (since Raspbian is based on Stretch)? Though I'm not sure what benefits that'd give to the arm build on a Raspberry Pi.

Otherwise, I say go for it. There's no real reason not to at this point, since all the major Debian-based distros have been updated since Stretch's release.

[bob]

If I recall, Linux Mint was the main issue when you guys tried it a year ago because its libraries were too out-of-date. But that's not an issue anymore, with the releases of Linux Mint 19 and elementary OS 5.0.

Though I suppose Ubuntu 16.04 LTS might be an issue, not sure. If it is an issue you might consider adding an additional repository for the last working build for those older platforms. Something like a legacy-stable repo or something like that.

Otherwise, I say go for it. There's no real reason not to at this point.

I'm a bit concerned that the SUSE and the Redhat variants might have issues.

[trajanmcgill]

But that's not an issue anymore, with the releases of Linux Mint 19 and elementary OS 5.0.

Isn't that sort of like saying in the first few months after Windows 10 came out that it isn't an issue anymore if something fails to work with Windows 8.1? Mint 18 is an officially supported version until 2021, and the Mint team actively recommends not blindly upgrading from 17 or 18 just to be on the latest version (that is, not doing so unless you have a reason to do so). I've got 19 running on one dedicated MC client machine currently, but my everyday PC is a Windows 10 / Mint 18 dual boot machine and probably will remain so for a while.

[bob]

Isn't that sort of like saying in the first few months after Windows 10 came out that it isn't an issue anymore if something fails to work with Windows 8.1? Mint 18 is an officially supported version until 2021, and the Mint team actively recommends not blindly upgrading from 17 or 18 just to be on the latest version (that is, not doing so unless you have a reason to do so). I've got 19 running on one dedicated MC client machine currently, but my everyday PC is a Windows 10 / Mint 18 dual boot machine and probably will remain so for a while.

It's also possible that the current version of mint 18 has updated the libraries that were causing the issue.

I don't think the fallback to the i386 build is totally unreasonable.

[Awesome Donkey]

Having a fourth repository, e.g. legacy-stable, could 'solve' that issue. Though the main caveat would be there'd likely be no more MC updates for that repo once the Stretch jump happens. But at the same time I suppose keeping i386 back on Jessie for a while for the sake of compatibility makes sense too.

Either way, I think the Stretch jump, at least for amd64, should still happen. If you keep waiting Debian Buster might be out.

[Awesome Donkey]

I'm a bit concerned that the SUSE and the Redhat variants might have issues.

Hmmm, Fedora may not be an issue but I guess that'd probably need tested. Does anyone run MC on RHEL? I guess it depends on which SUSE is being used? Hmmmm. openSUSE Tumbleweed *shouldn't* be an issue though.

[BryanC]

Hmmm, Fedora may not be an issue but I guess that'd probably need tested. Does anyone run MC on RHEL? I guess it depends on which SUSE is being used? Hmmmm. openSUSE Tumbleweed *shouldn't* be an issue though.

AFAIK there are ABI issues on RHEL 7 that prevent MC from running. RHEL 8 should probably be OK.

[Hendrik]

Isn't that sort of like saying in the first few months after Windows 10 came out that it isn't an issue anymore if something fails to work with Windows 8.1?

Except that Microsoft actually works quite a bit to allow apps to support brand new features and stay compatible with the old version at the same time. Linux generally does no work for this, for various reasons, the primary one being that they assume everything is open-source and will just be re-compiled for every distribution that exists. But as a small developer of closed-source software, we don't have the resources to build a special MC version for every distribution, so we often face the issue of compatibility vs. supporting new features.

We do offer a "legacy compatibility" version, which is the 32-bit build, which will remain on an older distribution. Its not ideal, but it works.

(Mac is even worse, everything is closed-source and Apple just assumes everyone updates to the latest OSX, screw people with hardware that doesn't get updates anymore)

[BryanC]

But as a small developer of closed-source software, we don't have the resources to build a special MC version for every distribution, so we often face the issue of compatibility vs. supporting new features.

What are the prevailing thoughts on using AppImage?

[Hendrik]

What are the prevailing thoughts on using AppImage?

Many of those key problem areas are where we have to actually interface with the host system, ie. video or audio, which interact with the drivers in the kernel. If versions are widely mismatched here, that might still not solve the problems.

[BryanC]

Many of those key problem areas are where we have to actually interface with the host system, ie. video or audio, which interact with the drivers in the kernel. If versions are widely mismatched here, that might still not solve the problems.

I was under the impression that Linux doesn't break userspace. I suppose that the drivers could be less audited?

[Hendrik]

I was under the impression that Linux doesn't break userspace. I suppose that the drivers could be less audited?

Compatibility is only preserved in one direction - a newer kernel won't break old libraries. But what if we need a new library/userspace driver and the kernel is old? Many of those hardware-near libraries have a minimum kernel version they require, of course.

[trajanmcgill]

It's also possible that the current version of mint 18 has updated the libraries that were causing the issue.

Having a Mint 18 installation that I keep up-to-date, I can probably check this if someone can tell me what I need to check.

[Mike Noe]

Probably more than a few of us that would be willing to test with Tumbleweed.  Since we have the OBS, if there are lib issues, we can fork into our own repos.  Though, TW is rolling very quickly, hard to imagine that it would have issues.

I wonder if you guys run your own version (since you're closed) of the OpenSuse Build Service (OBS) as it automates building for many distro/arches.

[trajanmcgill]

Except that Microsoft actually works quite a bit to allow apps to support brand new features and stay compatible with the old version at the same time. Linux generally does no work for this, for various reasons, the primary one being that they assume everything is open-source and will just be re-compiled for every distribution that exists. But as a small developer of closed-source software, we don't have the resources to build a special MC version for every distribution, so we often face the issue of compatibility vs. supporting new features.

Sure, that may make things difficult, but my point was about the statement that supporting Mint 18 "isn't an issue anymore" even as the vast majority of Mint users are probably running 17 or 18.

From a technical perspective, an issue has gone away, but from a user-facing perspective, to say the issue is no longer relevant is mistaken. But you do need minimum requirements at some point, too. It isn't unreasonable to say that a new version of software X will now require at least version Y of OS Z. (It might be less than fair to stop supporting a particular OS halfway through a single paid version cycle, though.)

[Awesome Donkey]

The thing is, JRiver only officially supports Debian with MC for Linux. Ubuntu, Linux Mint, elementary OS, etc. only work out-of-the-box because those are all based on Debian. Arch Linux, Fedora, etc. only work because there's a community either providing RPM conversion scripts (in the case of Fedora) or PKGBUILDs (in the case of Arch Linux) or whatever else.

Right now, they're building MC on Debian Jessie. If they move onto Debian Stretch, they can get H.265 GPU accelerated video decoding working. It's been over a year since Stretch was released, which is an acceptable amount of time for those distros to update, and they have... except that those older distros (Ubuntu 14.04/16.04 LTS and Linux Mint 17/18) are still supported by Canonical, Mint, etc. However I'm also going to go out on a limb here and say it's likely the amount of users running those older distros affected by the proposed change might be minimal. Having to wait for those older distros' support to end would just slow MC's development progress. They also couldn't update to Stretch or Buster next year once that's out since the support for those older Ubuntu/Mint releases is several years. IMO, not a good idea to let those dictate (or slow) the progress of MC... gotta draw the line somewhere.

Still it does make sense to jump to Stretch for the amd64 build since enough time has passed. Keeping the i386 build on Jessie for the time being for the sake of compatibility for those distros makes sense. Maybe once MC25 development starts, start requiring Stretch for the i386 and arm builds as well. Having the amd64 build of MC24 target Debian Stretch along with Ubuntu 18.04 LTS and Linux Mint 19 (aka the latest LTS releases) unofficially would work - I can update the tutorial informing users of older Ubuntu/Mint distros about that change along with the recommended way to switch to the i386 build.

Having the amd64 build based on Stretch showing a message about it not being able to be ran on older distros might be a good idea, so users know to install the i386 build instead.

[Kott]

Probably more than a few of us that would be willing to test with Tumbleweed.  Since we have the OBS, if there are lib issues, we can fork into our own repos.  Though, TW is rolling very quickly, hard to imagine that it would have issues.

I wonder if you guys run your own version (since you're closed) of the OpenSuse Build Service (OBS) as it automates building for many distro/arches.

I think OBS will be great, it supports a lot of distros and fairly easy to use. But requires some time to initial deploy.

[erviv]

I have been running MC24 latest on Debian stretch on my rpi for quite some time now.  I have not had any issues,  in fact I found it solved some of my audio (occasional freeze) issues.

[mwillems]

My opinion, for what its worth: Jessie has seen it's final official "oldstable" point release, and will be entirely unsupported by the debian security team in six or seven months when Buster launches.  I think it might be worth rebasing onto current stable if nothing else just to get the kinks out before Jessie support gets kicked down to the LTS teams (and stretch moves to old stable). 

No offense intended to folks who are in their second or third year of using a 5-year LTS release of a Debian downstream (like Ubuntu or Mint), but part of opting into that kind of LTS arrangement is getting used to using old software.

[bob]

Probably more than a few of us that would be willing to test with Tumbleweed.  Since we have the OBS, if there are lib issues, we can fork into our own repos.  Though, TW is rolling very quickly, hard to imagine that it would have issues.

I wonder if you guys run your own version (since you're closed) of the OpenSuse Build Service (OBS) as it automates building for many distro/arches.

We are running native build systems on the Debian platforms we support.
I took a quick look at the OBS, I don't see how it would handle things like the libva1 vs libva2 issue nor the different architecture issues. Do you have any experience with it to report?

[Hendrik]

I took a quick look at the OBS, I don't see how it would handle things like the libva1 vs libva2 issue nor the different architecture issues. Do you have any experience with it to report?

The libva1/2 case is special anyway, since its not in MC, but our build of FFmpeg, which is a plugin, and not part of the main .deb package. So even if we were to re-compile MC for different targets, we would also have to do that for some or all plugins, which would be really annoying.

[Kott]

We are running native build systems on the Debian platforms we support.
I took a quick look at the OBS, I don't see how it would handle things like the libva1 vs libva2 issue nor the different architecture issues. Do you have any experience with it to report?

Sorry, not clear to me, what kind of issues?
In rpm there spec-files where conditions describes what and how to compile in different distros/architectures.

for example:
https://wiki.debian.org/Repackage_srcrpm#spec_file

something like that:

%if 0%{?suse_version} > 1320
buildrequire "some_modern_library"
%else
%define distro_is_too_old_build_against_coprolith_libs 1
%endif