Could we please get a new release, quick? (packaging)

[mirabilos]

Good news: Jamulus was just accepted to Debian proper!

There’s been 210 commits since the last release. As long as there are no regressions, it might make sense to create a new release, which I can then upload. Debian freezes on 2021-02-12, so I’ll need to upload the new release before 2021-02-02, and I need some time to prepare the upload (review the changes for licence problems etc.) as well, so having a new release within 3–5 days would be preferrable.

If the current state is not in a state you wish users to have for the next few years (or in a worse state than 3.6.2 anyway), then we should not do that, of course ☻

[ann0see]

This sounds great!

So will it be available in sid or stable-backports too?

Edit: I did a few changes to the Debian packaging you should look into (systemd now configures a private Server based on the service file on jamulus.io)

[mirabilos]

ann0see dixit:

So will it be available in sid or stable-backports?

It’s already in sid. Once I know which one we’ll release bullseye with I’ll also upload to buster-backports; I’ve already prepared such backport, as I wanted to try out Jamulus with some others before, and, in contrast to me, they aren’t running sid. bye, //mirabilos -- „Cool, /usr/share/doc/mksh/examples/uhr.gz ist ja ein Grund, mksh auf jedem System zu installieren.“ -- XTaran auf der OpenRheinRuhr, ganz begeistert (EN: “[…]uhr.gz is a reason to install mksh on every system.”)

[corrados]

@ann0see Are the scripts for the automated release process ready? What about the Windows installer? Is this ready for a release?

We'll also need to ping the translators to update the translations.

There is a bug which I would like to fix for the upcoming release: #796.

So, it's gonna be tough to fulfill the deadline...

[ann0see]

Are the scripts for the automated release process ready?

Tested the headless build yesterday and it should work.

The installer is in a working state. (Although a few under the hood improvements could be done but they're not critical)

What about a Linux only release?

[corrados]

Having thought about this for a bit, I don't think we should rush a Jamulus release now. Here are the reasons:

• 3.6.2 is out for a while and has proven to be working and stable.
• In the current Git repo we have changed a lot regarding the Windows installer and we should definitely put out a beta version before the final release version, otherwise the risk for the Windows user is too high.
• There were no important features added since 3.6.2 regarding the Linux version of Jamulus.
• The bug mentioned above is only relevant for Windows.

Of course, one could argument that we now will introduce new server lists which should come into the Debian release. But following the discussions around the server lists, I expect that we have changes in that area in the next half year anyway. And you are talking about years with no change of the Jamulus version in Debian.

So, please use 3.6.2 as a base for your integration. We might open a debian security branch based on that version were I can merge possible security fixes into so that you can easily update your package.

I guess you already know this but when integrating Jamulus:

• You should use the noupcasename config flag.
• Avoid the opus_shared_lib config flag. This is because the current OPUS release version does crash for the custom interface. You need a patch from their code repo to fix this issue. You can have a look in the Raspberry Pi script of mine where I apply this patch: https://github.com/corrados/jamulus/blob/5f116ce2c494bd5aef113b5f5d86c371e54d5b28/distributions/raspijamulus.sh#L25

[gilgongo]

How is the headless (server only?) install handled? Looking forward to massively simplifying the Linux install instructions I have to say. They've been a bit of a time sink.

[mirabilos]

Volker Fischer dixit:

Having thought about this for a bit, I don't think we should rush a Jamulus release now. Here are the reasons: - 3.6.2 is out for a while and has proven to be working and stable.

[…] OK, then I’ll target 3.6.2 for the next Debian stable, expected in 3 months or so. Very good, as this means less work for me too, and I have even more packages I probably ought to work on…

- There were no important features added since 3.6.2 regarding the Linux version of Jamulus.

OK, good.

Of course, one could argument that we now will introduce new server lists which should come into the Debian release. But following the discussions around the server lists, I expect that we have changes in that area in the next half year anyway. And you are talking about years with no change of the Jamulus version in Debian.

Right. If the version in stable won’t work with new servers, I’ll need to backport just enough code to make that work, later. But let’s look at that when and if it comes to it only. Maybe that can be avoided…

So, please use 3.6.2 as a base for your integration. We might open a debian security branch based on that version were I can merge possible security fixes into so that you can easily update your package.

That would help massively!

- You should use the noupcasename config flag.

I didn’t, that’s no problem.

- Avoid the opus_shared_lib config flag.

I had to do that anyway because OPUS is currently packaged without the custom codecs stuff, and this was not likely going to be changed. Normally, embedding a library like that is not acceptable, but the specific need plus the… maintainance situation, or lack thereof, that OPUS in Debian has, allowed me to get excepted (for now).

This is because the current OPUS release version does crash for the custom interface.

Oh, ouch. But it’s applied in the code that is used, so that’s okay. Thanks for the feedback! bye, //mirabilos -- Solange man keine schmutzigen Tricks macht, und ich meine *wirklich* schmutzige Tricks, wie bei einer doppelt verketteten Liste beide Pointer XORen und in nur einem Word speichern, funktioniert Boehm ganz hervorragend. -- Andreas Bogk über boehm-gc in d.a.s.r

[mirabilos]

Jonathan dixit:

How is the headless (server only?) install handled?

At the moment, I decided against adding a second binary package with only the server. Every binary package has hidden cost, and in 3.5.2 at least, there was no visible benefit from making a server-only package because it also needs the full Qt libraries because Jamulus is written in Qt.

Looking forward to massively simplifying the Linux install instructions I have to say. They've been a bit of a time sink I have to say.

“sudo apt-get install jamulus” ☻ or in two weeks or so even “sudo apt-get install -t buster-backports jamulus” I’ll also provide them for *buntu in my PPA then (for the current and as many previous LTS releases as feasible), just like I do for MuseScore. bye, //mirabilos -- 21:12⎜<Vutral> sogar bei opensolaris haben die von der community so ziemlich jeden mist eingebaut │ man sollte unices nich so machen das desktopuser zuviel intresse kriegen │ das macht die code base kaputt 21:13⎜<Vutral:#MirBSD> linux war früher auch mal besser :D

[ann0see]

because it also needs the full Qt libraries

Is this really the case? The produced headless deb doesn't need qtwidgets etc (at least for me).

[mirabilos]

ann0see dixit:

> because it also needs the full Qt libraries Is this really the case? The produced headless deb doesn't need qtwidgets etc (at least for me).

A few versions ago, it was the case. The headless deb was added only afterwards, and it’s too late to add it to the Debian packaging now as adding a binary package must go through ftpmaster review again. That being said, qtwidgets isn’t that large compared to the rest of Qt plus its dependencies that are already necessary. bye, //mirabilos -- 15:39⎜«mika:#grml» mira|AO: "mit XFree86® wär’ das nicht passiert" - muhaha 15:48⎜<thkoehler:#grml> also warum machen die xorg Jungs eigentlich alles kaputt? :) 15:49⎜<novoid:#grml> thkoehler: weil sie als Kinder nie den gebauten Turm selber umschmeissen durften? -- ~/.Xmodmap wonders…

[mirabilos]

Dixi quod…

Jonathan dixit: >How is the headless (server only?) install handled? At the moment, I decided against adding a second binary package with only the server. Every binary package has hidden cost, and

Plus think of the benefits. Install xrdp, xorgxrdp, and a suitable small window manager like icewm, and probably xterm, and you can log into your server using any RDP client (rdesktop or xfreerdp under Unix) and manage the GUI version of the Jamulus server there ☺ bye, //mirabilos -- [00:02] <Vutral> gecko: benutzt du emacs ? [00:03] <gecko> nö [00:03] <gecko> nur n normalen mac [00:04] <Vutral> argl [00:04] <Vutral> ne den editor -- Vutral und gecko2 in #deutsch (NB: Editor? Betriebssystem.)

[mirabilos]

My PPA https://launchpad.net/~mirabilos/+archive/ubuntu/ppa already contains the Debian jamulus package for bionic (18.04 LTS) and focal (20.04 LTS), in the hope that this helps someone. If more builds are needed, ping me.