Distribution and packaging of Saucedacity on other platforms

[generic-pers0n]

Changelog
2022-07-28: Removed Haiku, Slackware, and Alpine. We'll have to look at those another time (Haiku will not be until very later, however).

---

Saucedacity could be packaged and distributed on a numerous amount of platforms. Of course, we focus on 2 main platforms: Windows and Linux. However, it could be a good opportunity to bring Saucedacity to platforms that either 1) need an audio editor or 2) need a modern audio editor (namely being an alternative to Audacity).

Proposed OSes

This list is to be expanded in the mean time, and it might seem surprising (with the way the list is currently):

• Flatpak - We can publish our flatpak to Flathub
• Arch Linux (AUR), as suggested by some.
• Maybe OpenIndiana

Help Wanted

I know that should Saucedacity be working on any platforms on the list above, it'll add to my tasks with Saucedacity, of which I already have enough to do right now. Therefore, I would like to put out a "Help Wanted" sign to anyone who might be interested. If you have experience with packaging, your skills will be especially useful to Saucedacity (and particularly to this issue).

Status

AUR: Researching
Flatpak: Researching. We might be eyeing Tenacity.
OpenIndiana: In progress

Notes on Building

AUR

• Might add some PKGBUILDS.

Flatpak

• Currently eyeing Tenacity's flatpak builds. Comment below if you think this is a good idea.

OpenIndiana

• Building with Conan fails due to Conan executing make -j<n> (e.g. make -j6), which OpenIndiana's make does not like.
  • Building without Conan is currently in the works. I am attempting to find development packages for the different required libraries (right now zlib)

[gotsum]

I hope this is the right place to ask, but have you discovered whether or not the Sauce works on Mint (and with Mint Cinnamon, MATE, and/or Xfce Editions, at that)? I assume so, but want to be sure before switching there from Ubuntu.

[generic-pers0n]

I hope this is the right place to ask, but have you discovered whether or not the Sauce works on Mint (and with Mint Cinnamon, MATE, and/or Xfce Editions, at that)? I assume so, but want to be sure before switching there from Ubuntu.

DE-wise, you should be fine. Distro-wise, I haven't tried Saucedacity on Linux Mint, but it should work without issue. If something tells me otherwise, I'll update you here.

[gotsum]

TY, and likewise if I run into any issues.

[FrostKnight]

I hope this is the right place to ask, but have you discovered whether or not the Sauce works on Mint (and with Mint Cinnamon, MATE, and/or Xfce Editions, at that)? I assume so, but want to be sure before switching there from Ubuntu.

DE-wise, you should be fine. Distro-wise, I haven't tried Saucedacity on Linux Mint, but it should work without issue. If something tells me otherwise, I'll update you here.

Unrelated message, dunno if this will help, but I sent a message to the now almost dead tenacity project in discussions, about how you are a project that they should support...

I hope you will succeed where the other forks trying to overcome audacity, have failed.

On an unrelated note, dunno about the project name, but I very highly recommend you, since unlike the others, you have refused to surrender.

Aka, after a year, you are still working on this.

This is what is needed to break the new owner's grip on the audacity project. Hoping you succeed!

Will try to install at some point, peace yall!

EDIT: Oh almost forgot, saw you were planning to move to QT in the future,

I do have two requests, if possible, can you, make sure you don't add the dbus part of qt, or the webengine part of qt as forced dependencies?

This would make it less likely for a distro I use to adopt your packages and it would unnecessarily bloat your software and make it slower over time.

Not saying, it shouldn't be an option, but I just ask you don't force it.

Again, I thank you for not giving up!

Oh and last thing, the fewer dependencies, the less headache in testing it, there will be, especially if you can build it quicker.

Now I actually will go for now,

My bad...

Have a good one though!

[generic-pers0n]

I hope this is the right place to ask, but have you discovered whether or not the Sauce works on Mint (and with Mint Cinnamon, MATE, and/or Xfce Editions, at that)? I assume so, but want to be sure before switching there from Ubuntu.

DE-wise, you should be fine. Distro-wise, I haven't tried Saucedacity on Linux Mint, but it should work without issue. If something tells me otherwise, I'll update you here.

Unrelated message, dunno if this will help, but I sent a message to the now almost dead tenacity project in discussions, about how you are a project that they should support...

I hope you will succeed where the other forks trying to overcome audacity, have failed.

On an unrelated note, dunno about the project name, but I very highly recommend you, since unlike the others, you have refused to surrender.

Aka, after a year, you are still working on this.

This is what is needed to break the new owner's grip on the audacity project. Hoping you succeed!

Will try to install at some point, peace yall!

EDIT: Oh almost forgot, saw you were planning to move to QT in the future,

I do have two requests, if possible, can you, make sure you don't add the dbus part of qt, or the webengine part of qt as forced dependencies?

This would make it less likely for a distro I use to adopt your packages and it would unnecessarily bloat your software and make it slower over time.

Not saying, it shouldn't be an option, but I just ask you don't force it.

Again, I thank you for not giving up!

Oh and last thing, the fewer dependencies, the less headache in testing it, there will be, especially if you can build it quicker.

Now I actually will go for now,

My bad...

Have a good one though!

Hello! Thanks for the message! I really do appreciate it since I've tried the best I can to keep Saucedacity as it is throughout this entire time. It appears that it's working quite well!

Now, quick thing about the name: the name is a little weird, yes, but...well, I don't know what else to say. It is quite weird XD

Finally, more about my plans for Qt: I don't plan to require the D-Bus part of Qt and WebEngine as dependencies when we switch to Qt for Saucedacity...unless I decide to use D-Bus in Saucedacity >:D (just kidding, I have no plans to use D-Bus at all, don't worry :). As for WebEngine, we shouldn't be needing to use it either, so we shouldn't be having to require that at all (and neither do I want it as a forced dependency). So, TL;DR: I don't plan to require QDBus or WebEngine in Saucedacity any time soon, and I do not plan to force them as dependencies because I also think they make unnecessary bloat.

About your thing about dependencies too: totally agreed. I kind of wish to reduce build time for Saucedacity so it builds faster. I will have to look into this later, but definitely at some point.

Anyways, thanks for stopping by!

[ZeroDot1]

It would be really nice if it is available in Arch Linux (AUR).

[generic-pers0n]

Okay, so I updated our focus for platforms. There are two main distribution platforms prioritized right now:

1. AUR
2. Flatpak

For Flatpak, I'm really taking a look at Tenacity for this. Please comment on this if you guys think this is a good idea.

[TheEvilSkeleton]

Hi, I've previously worked on the Tenacity flatpak. I can write the manifest and (hopefully get it working):

• Add org.tenacityaudio.Tenacity (Audacity fork) flathub/flathub#2444
• https://github.com/tenacityteam/tenacity-flatpak-nightly

[TheEvilSkeleton]

Now, quick thing about the name: the name is a little weird, yes, but...well, I don't know what else to say. It is quite weird XD

About this, perhaps you can try to collaborate with @tenacityteam? I got to know about this project from this Mastodon post: https://fosstodon.org/web/@tenacity/108734780637094669. In that post, there's the following:

We're discussing on how to carry over our work to their project.

Hopefully the name can be carried over or something. Out of respect, Saucedacity is not a good name.

[generic-pers0n]

Hi, I've previously worked on the Tenacity flatpak. I can write the manifest and (hopefully get it working):

* [Add org.tenacityaudio.Tenacity (Audacity fork) flathub/flathub#2444](https://github.com/flathub/flathub/pull/2444)

* https://github.com/tenacityteam/tenacity-flatpak-nightly

First of all, hello and welcome! Second off, sounds good! I do recommend that you test against the latest Saucedacity 1.2 beta 2, so this would likely be another nightly flatpak like Tenacity's flatpak. If you would like to test against Saucedacity 1.1 (our latest stable at the moment) however, that also would work, but Saucedacity 1.2 should be released any moment now, provided I get #20 fixed + everything else (which are mostly minor things).

[generic-pers0n]

Now, quick thing about the name: the name is a little weird, yes, but...well, I don't know what else to say. It is quite weird XD

About this, perhaps you can try to collaborate with @tenacityteam? I got to know about this project from this Mastodon post: https://fosstodon.org/web/@tenacity/108734780637094669. In that post, there's the following:

We're discussing on how to carry over our work to their project.

Hopefully the name can be carried over or something. Out of respect, Saucedacity is not a good name.

Umm...maybe that should be the first priority actually XD. I don't come up with good names, yes, so we should come up with a new name.

However, I am a little concerned that if we carry the name over, we might cause confusion. I'd go for another new name, but I am also not opposed to carrying over the name so long as we don't cause confusion.

[TheEvilSkeleton]

First of all, hello and welcome! Second off, sounds good! I do recommend that you test against the latest Saucedacity 1.2 beta 2, so this would likely be another nightly flatpak like Tenacity's flatpak. If you would like to test against Saucedacity 1.1 (our latest stable at the moment) however, that also would work, but Saucedacity 1.2 should be released any moment now, provided I get #20 fixed + everything else (which are mostly minor things).

Should I submit an MR to Flathub or is there another approach you'd like to take?

[TheEvilSkeleton]

However, I am a little concerned that if we carry the name over, we might cause confusion. I'd go for another new name, but I am also not opposed to carrying over the name so long as we don't cause confusion.

Personally, it's better to change the name now than later. The fork isn't that known so the impact will be minimal at worst. If we change it later, we'll end up causing more confusion.

[generic-pers0n]

First of all, hello and welcome! Second off, sounds good! I do recommend that you test against the latest Saucedacity 1.2 beta 2, so this would likely be another nightly flatpak like Tenacity's flatpak. If you would like to test against Saucedacity 1.1 (our latest stable at the moment) however, that also would work, but Saucedacity 1.2 should be released any moment now, provided I get #20 fixed + everything else (which are mostly minor things).

Should I submit an MR to Flathub or is there another approach you'd like to take?

Let's change our name first, actually. Like you said, it will be better if we do it now so there is minimal impact.

Personally, it's better to change the name now than later. The fork isn't that known so the impact will be minimal at worst. If we change it later, we'll end up causing more confusion.

I see and totally agree. So should we preserve Tenacity's name during the merges?

Edit: To clarify, should we use Tenacity's name? I will need to discuss this with them first. If not, then we can discuss a new name. Whichever path is desirable.

[TheEvilSkeleton]

I was only a Tenacity contributor, so I can't really give any authorization or speak on their behalf. I was just suggesting it. I think Tenacity is a great name, personally.

[generic-pers0n]

Okay. I will be discussing this with them.

[sosasees]

i think Saucedacity is a good name,

but this is coming from the person who made the game "Super Cube Drop into Void Simulator", canceled his game "Rhythm Sauce", and plans to make "Cubic Soup" in the future.

but yes, Tenacity is still a much better name than Saucedacity

[n0toose]

Here's everything I would suggest:

• start fresh, do not accept donations
• move to a different code forge other than GitHub
• establish discussion rooms on Matrix/IRC
• change the name, implicitly get rid of all the trolling that comes with bearing our other name
• utilize as much as work that has been already done possible, especially on the build system and e.g. removing conan
• reach out to the emails of old downstream maintainers and let them know about what you are doing

We have documented a bunch of alternative names in our GitHub Discussions, some ideas may be good. DON'T put it up to a public vote.

Feel free to reach out to me on my Matrix account, I'd like to contribute and explain where I can.

[generic-pers0n]

Here's everything I would suggest:

• start fresh, do not accept donations
• move to a different code forge other than GitHub
• establish discussion rooms on Matrix/IRC
• change the name, implicitly get rid of all the trolling that comes with bearing our other name
• utilize as much as work that has been already done possible, especially on the build system and e.g. removing conan
• reach out to the emails of old downstream maintainers and let them know about what you are doing

We have documented a bunch of alternative names in our GitHub Discussions, some ideas may be good. DON'T put it up to a public vote.

Feel free to reach out to me on my Matrix account, I'd like to contribute and explain where I can.

Sounds good!

I think I would also like to discuss more over Matrix too. I'll try to message you to see what we can discuss.

[TheEvilSkeleton]

move to a different code forge other than GitHub

While I do support this, it's hard to get started when the project is relatively small. I would suggest to stay on GitHub for a bit, and when the project takes off, switching to another forge, assuming you don't rely on GitHub's tools, shouldn't be a problem. The limiting factor with small projects is contributors. If the project gains little amount of contributors, it's hard to fix bugs and implement features alone.

[n0toose]

Okay, in order to deal with not depending on GitHub, I had to do the following things that other contributors in Tenacity ignored. In retrospect, I think one of them did it for the sake of spiting my idiosyncratic ways, but I did it in anticipation of moving away from the platform and I got screamed at multiple times because people would just straight up not get why I would raise the contribution bar higher instead of doing things like everyone else, when really, I was just trying to get rid of a behavior "imposed" by someone else that everyone got so accustomed to to the point where they thought it was normal.

1. When merging pull requests, it's a good idea to NOT let GitHub do the (#1249421) thing it does in reference to issues or pull requests, as these things are useless in other code forges and appear only as text in the command line, not in the form of a hyperlink. If you use a hyperlink in the commit message (say, https://github.com/saucedacity/saucedacity/issues/21), the web UI also condenses it down to #21. I preferred to use Reference-to:, as that is the standard that GitHub violates and the closest possible equivalent. (https://docs.github.com/en/get-started/writing-on-github/working-with-advanced-formatting/autolinked-references-and-urls)
2. We depended on GitHub Actions as we lacked the resources and manpower to host our own CI machines and provided builds to people through that using nightly.link. SourceHut's CI does not have macOS and Windows machines, although we definitely used their service to test our stuff against FreeBSD, something that upstream does not do. It's OK to not do that, and it's also OK if these platforms are served. One just has to be particularly careful (and have VMs ready) for changes that explicitly affect a specific operating system.
3. You have to have a plan as to how to migrate the issues and the pull requests. The Tor Project had to write their tooling themselves, AFAIK, not sure if Codeberg's migration tools does that for you as well.

As time goes on, this project will depend increasingly more on GitHub unless if one is very, very careful. But then again, being super careful and idiosyncratic annoys people and intimidates new contributors (I am pretty sure we successfully alienated at least 6 of them, sometimes because we could not communicate our 'mindset' properly and because people thought it would be as easy as using the web UI and being done with it), you might just as well move someplace else from the get-go.

A WIP-pull request that I worked on (https://github.com/tenacityteam/tenacity/pull/608), for example, implemented defining the default theme of Tenacity (during the first startup) depending on whether the system theme was Light or Dark. (It worked, but I abandoned it as I could not figure out how to change the theme if Windows's light/dark mode was changed on runtime, or at any given point after startup, as there were a lot more themes to consider and the logic would get way too complex. You can't get away with it through the CI, but maybe that's for the best?

We had this issue with Tenacity as well: We'd lose contributors if we moved away from GitHub, we need to keep our channels open! What wasn't a surprise, however, was how the QoL of the entire project got significantly worse once the huge wave of drive-by contributors left, after the lengths we had gone through to support drive-by contributors instead of core developers and maintainers. At the time of Tenacity, the tooling GitHub provided wasn't even that good to support drive-by contributors, something that I believe GitHub normally excels in/emphasizes on.

I think that @Codeberg-org is beneficial in the way that it supports drive-by contributors by wrapping many things around a beautiful UI and is not necessarily hostile to the new user. I am very skeptical about the accessibility, but I am sure that it will be improved upon. SourceHut feels more like something that a robust project depending on dedicated, repeated contributors would do, even if most young people will not be familiar with the "send patches by mail" workflow. Both services can be used interchangeably for different things (e.g. Codeberg with SourceHut CI)

Projects like this one are driven on ideals - I am not sure if my mindset is very gatekeep-ish, but if those ideals do not align with the user enough to the point where they'd go through the horrors of creating an account on a new website or if it's a simple two-line README.md change, do you really want to spend the time and the energy onboarding them if they are more than likely to just leave because you asked them to fix something or because you asked them to create an account somewhere (which people did anyways to e.g. communicate in real-time through our Matrix/IRC channels)?

[n0toose]

I think that this project has gone a bit far, with a bit of work you can develop a user base, and with a user base, some of them will be technical and annoyed at the little things enough to eventually make their way onto contributing. Although dealing with downstreams was largely unpleasant because people used work that was not kept up-to-date with our build system or because it was just a "let's just get it to run and not enable the build flags or use the dependencies that make the experience the most optimal" job, that got us a lot of traffic. I can definitely also ping or let people that had draft articles for when we were to make our stable release with a "hey, there's a new fork here!".

That should be OK enough, considering that the maintainer has definitely something to show here.

[generic-pers0n]

I think that this project has gone a bit far, with a bit of work you can develop a user base, and with a user base, some of them will be technical and annoyed at the little things enough to eventually make their way onto contributing. Although dealing with downstreams was largely unpleasant because people used work that was not kept up-to-date with our build system or because it was just a "let's just get it to run and not enable the build flags or use the dependencies that make the experience the most optimal" job, that got us a lot of traffic. I can definitely also ping or let people that had draft articles for when we were to make our stable release with a "hey, there's a new fork here!".

That should be OK enough, considering that the maintainer has definitely something to show here.

As much work as we've done, there is clearly still more to do. There is also more I have planned, some I know I can't do alone. But don't get me wrong here: I very much agree that if we put in more work, we can develop a good user base, even if it's a small one. After all, this fork has continued a year virtually in the dark, yet I decided to continue on it because it wasn't entirely in the dark. (I have a YouTube channel and posted videos about this fork there, although this was at the very start and I haven't posted a new video since). To mainstream, you can say that we were relatively unknown, however. Of course, this looks like it will all change, and I'm interested to see what's going to happen.

We've had some work and have persisted throughout this entire time, but I'm looking forward towards the work ahead of us. Whether it's my proposals I've had throughout this entire time or re-inventing Tenacity, I'm personally up for the challenge, and I'm very eager to work with others on this for practically the first time since this project started.

[generic-pers0n]

One just has to be particularly careful (and have VMs ready) for changes that explicitly affect a specific operating system.

Oh yeah: although my "home" development platforms is Linux, I will occasionally test things in a VM to make sure Saucedacity builds and runs just fine. I do this for Windows. For FreeBSD, I've been looking at that but haven't got to setting one up.

[n0toose]

One of us did some compatibility work for that.

[generic-pers0n]

One of us did some compatibility work for that.

Oh good! I'll take a look at that.

[generic-pers0n]

Okay, so about general packaging at this point:

Anyone who is willing to submit a package to somewhere etc may now do so. Please package the latest 1.2 stable release. However, be aware of the following things:

• Build system changes are coming in the next release.

• We will be using Tenacity's name in the future.

@TheEvilSkeleton you may now open a pull request for adding a Saucedacity 1.2 flatpak should you have everything ready. Take as much time as needed. Anyone else may do the same for other packages.

Given #48, I think it's best we start some distribution efforts. I admit that these Linux tarballs are not the most user friendly. Although AppImages are better, having something installable will be a huge benefit.

[FrostKnight]

Just wondering, of these dependencies, which do you plan to keep and which do you plan to add for the new way saucedacity or as it may be called later, tenacity will be using in the future? I am very curious.

I saw these:

(lib)expat
libflac
libid3tag
libmad
libnyquist
libogg
libsndfile
libsoxr
libvamp
libvorbis
lv2
portaudio-v19
portmidi
portsmf
portmixer
sbsms
soundtouch
sqlite
twolame

Btw, if you are switching to qt, can you make it possible to still be able to build with qt5? qt6 seems to be becoming more problematic, due to the changes in the way the qt organization is being run.

but if you did move to qt, wxwidgets is probably better to get rid of anyways.

Oh and also, can you tell me, what your dependencies will be for BSD as a whole?

I currently use Hyperbola, as some on github might know. Hence my interest... their new base is going to be in the spirit of libre software, with privacy/security/stability and minimalism for system stuff.

This is my main interest, but I suppose if any BSD's want less dependencies, this would make your fork even more attractive to them, especially OpenBSD probably, if I had to guess.

Anywho, also wondered how the progress is going to aquiring the new github name, etc... btw, if you don't like github, as a main choice, codeberg is another good one. Although it would be wise, to see what your contributors think first. ;)

These are just some thoughts, for now. I would say more, but still a bit in the dark.

Peace though!

[generic-pers0n]

The plan for dependencies is to ultimately de-vendor them. The only dependency I see being dropped is probably PortMixer because Tenacity dropped it. For BSD, these dependencies should be the same, if not similar, on Linux. We plan on de-vendoring all dependencies for all platforms to allow building against system libraries (or vcpkg; see #45 for more details).

For Qt, the plan is to support both Qt 5 and Qt 6. It is a bit of a problem that there aren't going to be any supported open source LTS version of Qt anymore, but we have to deal with this somehow.

[begin-theadventure]

Appimage when?

[sosasees]

@begin-theadventure in Saucedacity 1.2's release description is this piece of text:

I've also added a Linux tarball too, just like the old days. However, this will be the last release to feature this tarball. Future releases will use AppImages instead unless there is a special condition.

so Saucedacity/Tenacity 1.3 and future versions will most likely have AppImage when released.

[begin-theadventure]

Thanks!

[FrostKnight]

@begin-theadventure in Saucedacity 1.2's release description is this piece of text:

I've also added a Linux tarball too, just like the old days. However, this will be the last release to feature this tarball. Future releases will use AppImages instead unless there is a special condition.

so Saucedacity/Tenacity 1.3 and future versions will most likely have AppImage when released.

I don't know about other people, but as long as it is possible to compile from source code, as well, that should be sufficient in my opinion.

:)

Aka, precompiled tarballs, don't seem needed for everything.

[generic-pers0n]

Appimage when?

We also have AppImages for Saucedacity 1.2, although GTK theming is a little broken. While I'm fixing that for 1.3, you can try out our 1.2 AppImage right now on our 1.2 release page.

[edmundlaugasson]

Actually also pop-up appears, when opening v1.2.1 of AppImage with text:

UBUNTU_MENUPROXY=0 could not be found.

It has been removed from the list of recent files.

Tested with closely Arch-based EndeavourOS with all updates done.

Also even having /usr/lib/libavformat.so and ffmpeg installed (via OBS), when browsing and showing that library path, still Saucedacity does not recognize ffmpeg and basically cannot use it. Also command ffmpeg works on CLI.

ls /usr/lib/libavformat.so*
/usr/lib/libavformat.so     /usr/lib/libavformat.so.58.76.100  /usr/lib/libavformat.so.59.27.100
/usr/lib/libavformat.so.58  /usr/lib/libavformat.so.59

# /usr/lib/libavformat.so is symlink to latest version:
/usr/lib/libavformat.so -> libavformat.so.59.27.100

Even LAME exist but still cannot import *.mp3 file(s).

[edmundlaugasson]

Yet another pop-up with v1.2.1 of AppImage:

[generic-pers0n]

Yet another pop-up with v1.2.1 of AppImage:

This is very funny 🤣

But...looks like we have a couple of issues on our head. Thanks for bringing this to our attention.

[edmundlaugasson]

Using dark theme with KDE desktop and first pop-up, where is an option: don't show this again (or so), there was hard to mark not to show that pop-up. Several times tried to click that choice but still was showed that first pop-up, when opened. Finally succeeded, but hard to determine, how. Just regular clicking seemed not to work (did not mark anything).

[generic-pers0n]

Using dark theme with KDE desktop and first pop-up, where is an option: don't show this again (or so), there was hard to mark not to show that pop-up. Several times tried to click that choice but still was showed that first pop-up, when opened. Finally succeeded, but hard to determine, how. Just regular clicking seemed not to work (did not mark anything).

Sounds like those are theming issues. I am currently aware of them and are trying to fix those issues as well.

[crsib]

There were couple lines missing in AppImage creation script, you can check the fix in the upstream :-)

[generic-pers0n]

There were couple lines missing in AppImage creation script, you can check the fix in the upstream :-)

I have indeed cherry picked the fixes from upstream, although I broke AppImage generation in the process (I'll be fixing that). edit: turns out these AppImages are magically fixed??? Well, they work on my machine anyways...

Also, welcome!

[clort81]

Happy to see folks still working on *acity. THe Audacity takeover was unacceptable, and I found tenacity builds fixed the song-position-pointer-not-updating bug that audacity never fixed.
For my part it does what I need, but it'd be nice to get those nyquist plugins working again. Maybe I can help with that.
Godspeed righteous warriors.

[generic-pers0n]

Happy to see folks still working on *acity. THe Audacity takeover was unacceptable, and I found tenacity builds fixed the song-position-pointer-not-updating bug that audacity never fixed.
For my part it does what I need, but it'd be nice to get those nyquist plugins working again. Maybe I can help with that.
Godspeed righteous warriors.

Hello! Getting Nyquist working again sounds nice considering I never tested it. However, that should go in its own issue and not here, but talk about it is still welcome!

Unfortunately, there are a couple of major things that are planned to happen. We are planning to rename to Tenacity (of course), merge a major build system PR, and move to Codeberg. I advise you watch out when we move the repo, and everything should fully be settled then. Sadly, I have recently been lacking time on getting the new build system merged, so things might drag further than I wanted.

Nevertheless, contributions are welcome, and we'd welcome any contribution to the project you might have! :D

[sosasees]

We are planning to [] move to Codeberg

¡𝘆ess!
𝗰odeberg is my favorite git platform because they enforce the open-source spirit.

in my first 𝗰odeberg project, i didn't make the open-source license obvious enough, and i got a red warning box that i should add an open-source license to my project or it will get banned.
i made the open-source license more obvious and the warning is gone.