Package Details: soundfonts-aur-meta 20250530-1

Git Clone URL: https://aur.archlinux.org/soundfonts-aur-meta.git (read-only, click to copy)
Package Base: soundfonts-aur-meta
Description: Meta package depending on all avaiable soundfonts
Upstream URL: None
Keywords: bank meta sample soundfont
Conflicts: soundfont-opl3-fm-128m
Submitter: milkii
Maintainer: milkii (denilsonsa, oech3)
Last Packager: oech3
Votes: 2
Popularity: 0.000000
First Submitted: 2019-04-16 08:38 (UTC)
Last Updated: 2025-07-02 23:00 (UTC)

Latest Comments

1 2 Next › Last »

oech3 commented on 2025-07-02 23:02 (UTC)

Added to optdepends at a moment. Also sso-sfz is successor of sso-sf2.

denilsonsa commented on 2025-07-02 21:54 (UTC)

This has been flagged as out-of-date, but I think it is a mistake.

soundfont-sso-sfz is indeed a soundfont, but it is installed in a different directory (/usr/share/sounds/ instead of /usr/share/soundfonts/). It is also the only package providing a soundfont in SFZ format.

Likewise, soundfont-ensembles exists, but installs files in a different location (for some reason) and thus is not included in this meta package.

Additionally, it uses 1.4GB for that single soundfont, while this meta-package depending on 19 packages uses 2.6GB. The four largest existing soundfounts in SF2 format take 1.5GB (including the SSO in SF2 format, which alone takes 472MB).

Thus, given all these reasons, I'm not convinced that soundfont-sso-sfz should be added as a dependency.

Granted, I'm not a musician and I don't know which software can take advantage of the SFZ format. If you think it should be included, an option would be to include it as an optional dependency. Any thoughts from anyone else?

oech3 commented on 2025-05-28 06:34 (UTC)

https://aur.archlinux.org/packages/soundfont-opl3-fm-128m#comment-1025894 may not source controled. Swapped until fixed.

Does anyone interested to gm.dls package? I did't found "clean" source for it yet.

denilsonsa commented on 2025-05-23 08:51 (UTC)

is it fine to pkgver(){ date -u +"%Y%m%d" }

I'm not sure, probably not. Because that means the version will change every day this PKGBUILD gets evaluated, which is probably not what we want. I've seen pkgver using the git commit version, but that's stable. The date/time isn't.

Bear in mind I'm not very experienced with the inner workings of PKGBUILD, so I may be wrong. Also, it seems you've been added as a co-maintainer as well.

oech3 commented on 2025-05-22 16:06 (UTC)

is it fine to pkgver(){ date -u +"%Y%m%d" } at next update ?

denilsonsa commented on 2025-05-21 10:15 (UTC)

@oech3, looks correct.

I initially understood "merge request" as a "pull request", not as a "merge this package into another". That was my confusion.

oech3 commented on 2025-05-21 09:55 (UTC) (edited on 2025-05-21 10:01 (UTC) by oech3)

[Edit] by similar method with deletion (https://lists.archlinux.org/archives/list/aur-requests@lists.archlinux.org/thread/TG5WA3ZAO6YW3IFKWIFOYNQSMYNREHAI/)

(Is the merge target correct?)

denilsonsa commented on 2025-05-21 09:35 (UTC)

@oech3, wait, can we send merge requests for AUR packages? Where?

oech3 commented on 2025-05-21 09:20 (UTC) (edited on 2025-05-21 09:56 (UTC) by oech3)

package() { true } and url is removable (maybe). I asked/sent a merge request for others.

1 2 Next › Last »