A message to switch to the new used DNS entries for central servers

[genesisproject2020]

Now when the new DNS entries for the central servers are implemented it would be good to present a message when starting the server with an old DNS entry.

Any Genre 1: anygenre1.jamulus.io:22124 old jamulus.fischvolk.de:22124
Any Genre 2: anygenre2.jamulus.io:22224 old jamulusallgenres.fischvolk.de:22224
Genre Rock: rock.jamulus.io:22424 old jamulusrock.fischvolk.de:22424
Genre Jazz: jazz.jamulus.io:22324 old jamulusjazz.fischvolk.de:22324
Genre Classical/Folk: classical.jamulus.io:22524 old jamulusclassical.fischvolk.de:22524
Genre Choral/Barbershop: choral.jamulus.io:22724 old jamuluschoral.fischvolk.de:22724

(The reference at https://jamulus.io/wiki/Central-Servers should be updates as well.)

[genesisproject2020]

Ref: #919

[ann0see]

(The reference at https://jamulus.io/wiki/Central-Servers should be updates as well.)

this should be part of the next documentation release

[gilgongo]

this should be part of the next documentation release

It is.

[gene96817]

What will we recommend to groups with users with old client releases?
I am guessing that when I register my servers to a new genre (e.g. Choral/Barbershop) it will go invisible for users looking for servers as Classical/Choral/Barbershop.

[dcorson-ticino-com]

We had the same problem that last time new servers were added.
We had a lot of forum topics about people not finding servers.
The answer was to update.

[gene96817]

Should we make updating clients to be a key part of the next release? If so, we need to plan how we will message this. A lot of people choose to wait some weeks after a release before installing an update. We need to advise server owners about how to manage this transition.

[hoffie]

Should we make updating clients to be a key part of the next release?

It's planned to make this a prominent part of the release announcement: https://github.com/jamulussoftware/jamulus/pull/1223/files#diff-053320059888336200b4b193337b38d79fc36752a7f76787303d8c40b71ac10fR3

[hoffie]

Should we make updating clients to be a key part of the next release?

I think it would be a good idea to add an emphasis on this in the release announcement. I have added a reminder to our checklist in #1086.
Using one of the new lists would still be a deliberate¹ choice by the server operator, so at least in case of semi-private servers they can tell their users beforehand.

¹ Unless they are forced to because the older lists are full. But they'd be a problem right now as well.

[ghost]

Should we make updating clients to be a key part of the next release?

What about the jamulus 3.6.2 debian package?
It must be maintained at version 3.6.2 for updates.
You don't want it to loose access to the servers.
See #896

[ghost]

Maybe a Debian bugfix package can be made (eg. Jamulus-3.6.2-1.deb) that is actually Jamulus-3.7.0 ... That would spare you much trouble. You can get past 3.6.2.x at some convenient time in the future. After all, new versions of Jamulus are based on old versions and this is just a package labelling issue. If Jamulus were developed for Debian, Jamulus versions would play well with Debian. We can still have the Debian packaging play nice for Debian.

[softins]

Maybe a Debian bugfix package can be made (eg. Jamulus-3.6.2-1.deb) that is actually Jamulus-3.7.0 ...

But that would decieve and mislead the users and the rest of the Jamulus community. If it says 3.6.2, it should behave as 3.6.2, warts and all, with nothing more than security updates or major bugfixes backported.

[mirabilos]

So what’s the status on this? Is there a minimal-complete patch for 3.6.2? (Ideally you’d even do a git branch off the 3.6.2 tag containing only the fixes targetted for Debian bullseye, then I’d have a reference I can point my reviewers to.)

Note we’ve been at a point where all changes must be targetted for the release and fix important or critical or security bugs only for some time already, so please bear that in mind. No code formatting changes, etc. (If you do the git branch, you can even skip changing the changelog file, as that will suffice as documentation.)

[softins]

So what’s the status on this? Is there a minimal-complete patch for 3.6.2? (Ideally you’d even do a git branch off the 3.6.2 tag containing only the fixes targetted for Debian bullseye, then I’d have a reference I can point my reviewers to.)

Note we’ve been at a point where all changes must be targetted for the release and fix important or critical or security bugs only for some time already, so please bear that in mind. No code formatting changes, etc. (If you do the git branch, you can even skip changing the changelog file, as that will suffice as documentation.)

My view is that it is not the Jamulus team's responsibility to maintain a branch for the official Debian distribution. It's the responsibility of the packager to fork the upstream repo, set their own version number, and cherry pick what commits they want to back-port.

I'm not yet familiar with Debian packaging. In the RedHat/CentOS RPM world, the packager uses an unchanged ("pristine") upstream tarball as the source, and maintains their own set of patches against this, which are included in the source RPM.

[hoffie]

My view is that it is not the Jamulus team's responsibility to maintain a branch for the official Debian distribution. It's the responsibility of the packager to fork the upstream repo, set their own version number, and cherry pick what commits they want to back-port.

I mostly agree. What we should do though is make packagers' lives as easy as possible. I hope that we are mostly doing that already by separating bugfixes from new features in the Changelog and adding references to the relevant PRs so that that the associated commits can easily be found. I guess it would help if we had a closer look at the number of commits in PRs and squashed if there are more than necessary.

I'm not yet familiar with Debian packaging. In the RedHat/CentOS RPM world, the packager uses an unchanged ("pristine") upstream tarball as the source, and maintains their own set of patches against this, which are included in the source RPM.

Yes, it uses an unchanged upstream, but it can be really old and their "own patches" may well be backports from newer upstream versions. RHEL7's kernel at 3.10 is my favourite example. :)

[gene96817]

Perhaps this is a bad idea....
Is it possible to hack a pseudo server entry at the directory (example under Genre Classical/Folk) to say "some servers have been moved to Genre Choral/Barbershop". We need this where old genres have been redefined or split. In this way, users would have a clue that they need to update their client.

[mirabilos]

Tony Mountifield dixit:

I don’t understand what the solution is then.

Easy, we patch the version in Debian. This is business as usual and expected(!) from distributions, acting in their role as integrators and, well, distributors.

[mirabilos]

DavidSavinkoff dixit:

Maybe a Debian bugfix package can be made (eg. Jamulus-3.6.2-1.deb) that is actually Jamulus-3.7.0

No, we cannot do that at this point any more. Only targetted bugfixes. Tony Mountifield dixit:

But that would decieve and mislead the users and the rest of the Jamulus community. If it says 3.6.2, it should behave as 3.6.2, warts

Debian packages are *always* patched. It does not say 3.6.2, it says “3.6.2” (upstream version) “+dfsg1” (unfree files and embedded code copies removed) “-2” (Debian patchlevel). I also included commit 6d9693e already in there so that the manual link keeps working, and fixed lrelease runs, for example. bye, //mirabilos -- <igli> exceptions: a truly awful implementation of quite a nice idea. <igli> just about the worst way you could do something like that, afaic. <igli> it's like anti-design. <mirabilos> that too… may I quote you on that? <igli> sure, tho i doubt anyone will listen ;)

[mirabilos]

Tony Mountifield dixit:

My view is that it is not the Jamulus team's responsibility to maintain a branch for the official Debian distribution.

That’s fair.

cherry pick what commits they want to back-port.

I’m not involved enough with this to know what to take at this point. I’d probably miss something or use too much, or something.

[ann0see]

I think the memory leak bug fixes and maybe the server lists (but that's debatable) should be included.

[ghost]

I think that if Jamulus continues to complie on a given version of Debian without changing the dependencies that Debian AND Jamulus started with, Then Jamulus has not substantially changed despite Jamulus' version. Maybe Debian could use some metric to determine code-churn for rejecting Jamulus commits.

[mirabilos]

DavidSavinkoff dixit:

Jamulus' version. Maybe Debian could use some metric to determine code-churn for rejecting Jamulus commits.

Easy: right now, we reject by default. Anything that must go in at this point needs justification. I can justify a memory leak fix, if it introduces no regressions, and if the server lists change, I can justify this as well, I think. I don’t currently have enough time to figure out these changes myself.

[ann0see]

Yes, the changed server lists are here: #885

Probably also this: 72ff3ae#diff-95447242d2d9a6faee110005c62053f1bdac647f66f546227c4868a1752ee5c7

@softins should be able to tell you where the memory leak fix is.

[softins]

@softins should be able to tell you where the memory leak fix is.

The merge commit for those is f95d2e9 from PR #1073

[mirabilos]

I’ve merged most of the changes mentioned, plus the --serverpublicip addition (which is a prerequisite of the privacy bugfix and useful anyway) and added a manual page. I’ve not merged the addition of the Qt deprecated thing because I already handled that in CXXFLAGS, and I’ve commented on the addition on -Wl,--as-needed that this probably should not be present in Jamulus.pro but handled by the surrounding package management (it is, in Debian).

I’ve also quickly tested this, but if someone could test this (e.g. on a Debian bullseye system, install jamulus 3.6.2+dfsg1-2 normally first, download the .deb of 3.6.2+dfsg1-3 in unstable, sudo dpkg -i it) I’d not say no ☻

I cannot update the buster backport before this lands in bullseye, which will, at the current point in time, take a minimum 20 days and a manual review by the release team. I’m prepared to argue for every change I included, but having someone look through the changes and test it would help making my point. (The release team review won’t start before I ask for it, and I’ll only do that at least one week into that 20-day period so that any obvious bugs will be found prior to that by users.)

And yes, I’ll contribute the manual page (properly adjusted for the possibility of naming the binary either Jamulus or jamulus and integrated with the .pro file) later… but I’m focussing on the thing that has a deadline first.

[hoffie]

This sounds great! :)

plus the --serverpublicip addition (which is a prerequisite of the privacy bugfix and useful anyway)

If you are referring to the "cloudflare" privacy bugfix, then this should not be related.

[mirabilos]

This is unblocked and should enter Debian bullseye in 11 days, after which it can be backported for buster.

[ghost]

I went looking for Jamulus-3.6.2 bugfixes and found a few that may be useful.
A patch for the "server lists change" will be a bit of work (not included here)

What I did to get patches:
Use browser and navigate to
https://github.com/jamulussoftware/jamulus/commits/master

scroll to interesting commit and take a look
Add .diff or .patch to line to get a useable diff or patch
see following:

• Server: Use a traffic-less way to get external IP feb 25
  cd8ba80
  Add .diff or .patch to previous line to get a useable diff or patch:
  https://github.com/jamulussoftware/jamulus/commit/cd8ba805d209247a754747e7fe39559879951d14.diff
  Or
  https://github.com/jamulussoftware/jamulus/commit/cd8ba805d209247a754747e7fe39559879951d14.patch

• Merge pull request Fix memory leaks in Jam Recorder #1073 from softins/memory-leaks feb 22
  https://github.com/jamulussoftware/jamulus/commit/f95d2e97dd102a9a77d809ac4bfb711b1213a19b.diff

• Escape chat messages at the server Escape chat messages at the server #939 feb 10
  https://github.com/jamulussoftware/jamulus/commit/3fa94217cf447d3aa9549b023435d6e9fd79f237.diff

• Remove ConsoleWriterFactory memory leaks jan 30
  https://github.com/jamulussoftware/jamulus/commit/e1b11dd741d76b96c26c5502f760ee4ee7222246.diff
  https://github.com/jamulussoftware/jamulus/commit/89cdff65af417dde9331c0f798730e4aeee51934.diff

• qmake: avoid unnecessary runtime dependencies jan 16
  https://github.com/jamulussoftware/jamulus/commit/435b2fcc3f01bf8e6dad59cc1b101e757fd0206a.diff

• QT_NO_DEPRECATED_WARNINGS jan 11
  https://github.com/jamulussoftware/jamulus/commit/89181118e53b99bdc7b9f6ca6d1bcbe92832928c.diff

[mirabilos]

Christian Hoffmann dixit:

> plus the `--serverpublicip` addition (which is a prerequisite of the > privacy bugfix and useful anyway) If you are referring to the "cloudflare" privacy bugfix, then this should not be related.

Should not but made it possible to apply the patch without changing it in major ways.