Vee one suite: migrate to CMake build system, add recent versions

[mazes-80]

As all ebuild are just symlinks to live ebuild, I chose to remove all previous version. You should maybe keep 0.9.21 for all ebuilds from v1 suite

[NexAdn]

And a final thing: since we have reworked our CI pipeline, please rebase your changes onto the current master so the CI pipeline does its checks as required.

[mazes-80]

Let me put an hand on my local copy of audio-overlay first. The PR has been opened forever, i don't remember every details

Le Sat, 11 Feb 2023 03:19:57 -0800, Adrian Schollmeyer @.***> a écrit :

@NexAdn requested changes on this pull request.

The overall rework looks good and reduces the complexity of the ebuilds quite well. A few minor changes should still be applied.

Furthermore, please try to use pkgdev commit to create your commits. It automatically prefixes the commit message properly (you have a typo in all your commit messages :sweat_smile: ) and adds Closes: tags for each issue link via -c. Since these commits also close some of the issues in our issue tracker, please add them to the commit message by means of appending a Closes: <issue-link> line in the commit message body or using pkgdev commit -c <URL> (which does that automatically). still not used to pkgdev

Would you like to add yourself as maintainer for these packages and take over responsibility for future version bumps? Since you seem to be interested in having these packages up to date, you are a good candidate for becoming a maintainer for these packages. I may send pr when they get updated but not really interested in maintainership, I have many packages locally already, and still no proper workflow to check for updates.

Lastly, I think there were new releases for these packages available, so please consider adding ebuilds for the most recent versions as well (I think Simon's policy was to keep about two versions per package around).

@@ -1,12 +1,13 @@
-# Copyright 1999-2021 Gentoo Authors +# Copyright 1999-2022 Gentoo Authors

We have 2023 now. Please update the copyright year accordingly. Copyright may be updated only when changes occurs, not every year's eve.

lv2? ( media-libs/lv2 )  

osc? ( media-libs/liblo ) " DEPEND="${RDEPEND}"

src_prepare() {

• eautoreconf

• Remove compression of manpages

• sed -i -e @.****man1/d" Makefile.in || die "sed failed"

• Disable stripping

• echo "QMAKE_STRIP=" >> src/src_core.pri.in
• echo "QMAKE_STRIP=" >> src/src_jack.pri.in
• echo "QMAKE_STRIP=" >> src/src_ui.pri.in
• echo "QMAKE_STRIP=" >> src/src_lv2.pri.in
• sed -i -e '/strip $(TARGET)/d' src/src_jack.pro || die "sed failed"
• sed -i -e '/strip $(TARGET)/d' src/src_lv2.pro || die "sed failed" -
• default
• sed -i 's:strip:true:' src/CMakeLists.txt || die

What is this for? A short comment above this line would be nice. It avoids QA error for pre-stripped binaries

[NexAdn]

Would you like to add yourself as maintainer for these packages

I may send pr when they get updated but not really interested in maintainership, I have many packages locally already, and still no proper workflow to check for updates.

There is always a package to start off with^^ Especially for projects hosted on GitHub and GitLab, you can just enable release notifications, so you will be notified via email when a package needs version bumping. It's really not that hard for those platforms. For Linux Audio in particular, there is an announcement mailing list linux-audio-announce where you can receive notifications about new versions for many Linux Audio software. I am doing quite well with these kinds of notifications for some time now, so maybe now is the time for you to try that out^^

Copyright may be updated only when changes occurs, not every year's eve.

That is true. However, I have requested changes, so if you incorporate these changes, the ebuild will be changed this year and thus qualifies for a copyright year bump. I didn't go around bumping copyright for every file in the overlay; that would be nonsense.

It avoids QA error for pre-stripped binaries

I assume you mean it disables stripping (which is what we want). So this is what you should write as a comment. An anonymous sed line is generally not a good idea in an ebuild, since its behavior might change and if you don't know what it's for, people might fix the ebuild in a wrong way.

[mazes-80]

changed http: -> https: added comment on stripping updated year

forced push to eliminate typo in commit messages

----Maintainership really no, I'm not interested by these packages.

---- Releases Using ebump seems better for me, it fails in many case but support multiple common sources hosts. For projects with unsupported upstream format, suscribe to release mailing lists, if they exist. Finally ultimate level of difficulty with some projects like arnold cpc emulator: you must watch threads in http://www.cpctech.org.uk to find out for releases.

--- Sed Commenting any sed line in ebuild may be hard -> my latest citra-canary

Nowadays using sed in ebuilds seems only allowed for dynamic changes. For static changes patches are the way to go. I am still reluctant to use patches for trivial changes like in this case.

Moreover instead of using sed I should just pass /bin/true as being strip executable used by cmake from configure phase, not prepare phase