Tracking Surge XT in the downstream package ecosystem

[luzpaz]

Currently there is a lot of conflicting data in downstream package repos, see https://repology.org/project/surgext/related

Once we've sorted them in repology I'll post a badge here to see what repos are up to date and which repos are missing Surge. Then the need to request said repos for a package to be implemented (if warranted).

At the time of this post repology is tracking the following surge* downstream packages:

TODO

• Alpine
• Void

[baconpaul]

Thank you for looking at this

The surge 1.9 and surge xt should exist both in parallel; there’s an archival reason to have both installed.

but I agree the 1.7 and 1.0.1 and all the names is not really … good

there’s also the question of whether these packages work. Many apply patches and changes which we never test. But there’s nothing to be done about that

[mkruselj]

Packages maintained by someone other than us (especially doing changes not sanctioned by us) are not our responsibility.

[baconpaul]

Yeah but wrangling them into shape a bit as @luzpaz offered to do is welcome

[luzpaz]

So to be clear how should the packages in repology look like?

The surge 1.9 and surge xt should exist both in parallel; there’s an archival reason to have both installed.

Does this mean there should be a placeholder for surge1.9 and for surge-xt ?

Which are the ones that are acting as 'forks' ?

JFYI, all these things can be tweaked in https://github.com/repology/repology-rules to better clarify the perplexing situation

[baconpaul]

well in homebrew (which I maintain for mac) we have the (older) surge-synthesizer and (newer) surge-xt which provide 1.9 and xt respectively. They have distinct package names inside the macOS environment and can install side-by-side. I have both installed so my older projects using surge 1.9 still render when I open them in logic.

I think most of the packages, if you look in the pkgbuild, apply some diff which they haven't upstreamed. The Arch ones for instance attempt to devendor some things and change our version information and stuff (which is a pain).

But really, I'm not a linux user much. I run ubuntu for dev.

[mkruselj]

From my POV packages should be called surge and surge-xt.

[baconpaul]

There was already a home brew package called surge for completely different software hence the surge-synthesizer moniker there just fyi

[mkruselj]

Hmmm well darn. How about sst-surge and sst-surge-xt?

[baconpaul]

Oh it’s too late to change homebrew - I was just sharing we have two packages there and we could model the distros the same

[luzpaz]

We can tell repology to associate the homebrew packages with whatever project name you choose.

[baconpaul]

so if repology tracks homebrew, then

https://github.com/Homebrew/homebrew-cask/blob/master/Casks/surge-synthesizer.rb

and

https://github.com/Homebrew/homebrew-cask/blob/master/Casks/surge-xt.rb

are the two packages

[luzpaz]

At the time of this post repology is tracking 2 package names:

Edit: here is the repology commit that did this: repology/repology-rules@d85a1fe

[baconpaul]

Wow thank you. So I guess we need to find a nix maintainer yeah?

[luzpaz]

Are these current name assignments amicable? (Or does anything need to be tweaked?)

[mkruselj]

No, that's perfectly fine!

[luzpaz]

Added request for downstream Chocolatey: chocolatey-community/chocolatey-package-requests#1443

Edit: requested version bump in FreeBSD https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=272970

[baconpaul]

thank you so much for doing this work. It's really appreciated.

If you join (or have joined) our discord please let us know your name and we can tag you with the team member role!

[mkruselj]

@baconpaul @luzpaz So what do we do with this ticket? Do we close so we don't need to track it, but still open for discussion, or?

[luzpaz]

I vote to keep open for exposure to help improve downstream availability.

Edit: it could even be pinned to the top of the issue queue (since there are pinned tickets that have already been merged and therefore potentially can be unpinned)

[mkruselj]

Yeha let's try doing that.

The tickets we have pinned already are pinned for general info so that people don't open duplicate tickets anymore. So we are not gonna unpin them. the release plan could be unpinned tho. there's a max of 3 tickets that can be pinned.

[luzpaz]

You can also transfer this ticket to a discussion... ? (that's another option if you'd like)

[mkruselj]

It is already tagged as a discussion but as long as it is open it counts towards our open issues. And it's not really an issue per se.

[luzpaz]

Opened a downstream ticket request to bump nixOS unstable to 1.2.3

[baconpaul]

OK!

We are about to release 1.3 - probably this weekend latest - just so you know!
Is there a way we would let you know that that works? If so we can add it to our release checklist.
Thanks so much

[luzpaz]

Is there a way we would let you know that that works?

Just post to this ticket 👍

[baconpaul]

Good morning! We updated to 1.3.0 this morning.

Thanks for all your efforts.

[luzpaz]

Flagged Arch repo that new update is available

[baconpaul]

Hi! Just FYI we updated to 1.3.1 today

[luzpaz]

No response from Arch maintainer 😞

[Andreya-Autumn]

No response from Arch maintainer 😞

Oof! Well, we may do a 1.3.2 with some bugfixes and small QOL stuff anyway. We'll let you know when that's up and you can ping them again, hopefully just a hiccup.

[luzpaz]

nixOS unstable updated to 1.3.1

edit:
and bumped downstream freebsd ticket

[mkruselj]

@luzpaz We have released 1.3.2!