Package Details: radium 5.9.83-1

Git Clone URL: https://aur.archlinux.org/radium.git (read-only)
Package Base: radium
Description: A graphical music editor. A next generation tracker.
Upstream URL: https://users.notam02.no/~kjetism/radium
Licenses: GPL2
Submitter: speps
Maintainer: KenjiTakahashi (J5lx, Teteros)
Last Packager: Teteros
Votes: 12
Popularity: 0.22
First Submitted: 2013-05-22 03:41
Last Updated: 2019-11-28 11:48

Latest Comments

« First ‹ Previous 1 2 3 4 5 6 7 8 9 Next › Last »

J5lx commented on 2017-04-11 20:33

To address some of your points:
- The reason I don’t want to see $pkgname everywhere is because one of the most common reasons for changing it is to have something like radium-git or radium-with-custom-patch-xy. In both those cases you're still e.g. installing files of a program called just Radium, and usually they are drop-in replacements for the original package rather than being meant for side-by-side installation, meaning that files would go to the same location (/opt/radium), too. I hope that makes sense the way I wrote it.
- Regarding the user/group thing: Both transmission-cli and mariadb provide daemons running system-wide under their respective accounts via systemd (e.g. `systemctl start mariadb`). Radium however is not a daemon but a program run by end-users on their respective accounts rather than on a system account.
- On my system, removing radium deletes /opt/radium just fine. Maybe you created some files in that directory yourself? Maybe autosaves?
- I am going to test-build 4.6.8 now and if it works fine I'll push an update afterwards.

Teteros commented on 2017-04-11 20:07

Thanks for going through, and scrutinizing my changes rather than just merging blindly:
- Somehow I missed that while researching about changelog() That makes a lot of sense now.As I wasn't sure why pacman/makepkg used the Changelog file before downloading/sourcing the source() array.
- The sed lines were ment to reduce the high amount of one-liner diff .patch files we had in the previous PKGBUILD's. Though as I did them, I noticed they weren't even arch specific issues, so switched to making pull requests instead. I think the remaining .patch'a are matching lines very unlikely to be touched by upstream anytime soon, but I see your reasons.
- Eh $pkgname was supposed to be a practical change thing, but the maintainer will propably vim/sed search/replace the name anyway if upstream changed it. See last point.
- Giving a package its own user/group is standard practice whether it's an official package (transmission-cli: https://git.archlinux.org/svntogit/packages.git/tree/trunk?h=packages/transmission
maria-db: https://git.archlinux.org/svntogit/packages.git/tree/trunk?h=packages/mariadb)
or a popular self-contained aur package (jdownloader2)
I'd agree however that, assigning ACL permissions to have /opt/radium in the 'audio' group is excessive, but there are benefits to have /opt/radium in radium:radium.

Having said above, consider using the suggested .install file at least for the post_remove() function. The package as it is will leave /opt/radium lingering after package removal which might cause issues for the user when reinstalling the package at a later date.

- The patch for this PKGBUILD was much bigger before my pull requests were merged, so I opted for changing the comsmetics as it looked like a different PKGBUILD either way. Though now that those changes got merged (!) my cut-down PKGBUILD looked weird and out of place compared to the old one.

Having this comment way longer than I wanted... Thanks again for the merge, and I can confirm 4.6.8 builds fine with the current PKGBUILD, could you bump the version please? I'd say it's worth it as 4.6.8 introduces some long awaited features like sample-seek.

J5lx commented on 2017-04-11 18:43

Okay, so I just had a look at your changes and merged… some of them, because of this:
- The $changelog field in the PKGBUILD is for changelogs of the package itself, not for changelogs of the packaged software. Software changelogs usually go into /usr/share/doc
- We specifically opted to use patches rather than sed because sed lines broke on some updates in very subtle ways. Plus, it’s often harder to tell what exactly sed lines do.
- Don’t use $pkgname excessively just because you can, use it when it makes sense – it’s not inherently synonymous with the software name.
- I am absolutely not going to give write access to system directories under any circumstances unless there is a very, very, very good reason for it. Making a warning message disappear is not such a reason.
- Generally, refrain from making lots of cosmetic changes since that makes review much harder
Aside from that, thanks a lot for your efforts in getting those improvements into upstream (!) and integrating them into the PKGBUILD! So far, everything seems to work fine, so good job!

Teteros commented on 2017-04-09 05:30

I've worked with upstream to update this package and make it more user friendly.

Links

Diff: https://gist.github.com/Teteros/b6c7bc6d2b60b96b6fe643612cd0c1cf/revisions
Tarball: https://gist.github.com/Teteros/b6c7bc6d2b60b96b6fe643612cd0c1cf/archive/master.tar.gz
Related pull requests: https://github.com/kmatheussen/radium/pulls?utf8=%E2%9C%93&q=is%3Apr%20author%3ATeteros%20

Verified to compile on a clean chroot.

KenjiTakahashi commented on 2017-02-02 04:02

The problem reiterated for me and this time I was able to look at this in more detail. @pizzataco was mostly correct with his findings, but instead of crafting another part of a (primitive) package manager within a package (why radium's author is doing this is totally beyond me), I've patched it to use libxcb from [extra], which includes all necessary fixes.

I also see the message about dir not being writable, but it does not appear to do any bad, does it? It would probably be best to check in the code why it might actually want to write into it's own dir, but, honestly, this code is total spaghetti. I kinda adore the guy for being able to keep it in a mostly working fashion, lol ;-].

J5lx commented on 2016-12-17 01:16

@pizzataco If all you want to do is build the package in a clean chroot you should have a look at archbuild: https://wiki.archlinux.org/index.php/DeveloperWiki:Building_in_a_Clean_Chroot That’s what I use whenever I work on this package (IOW, it’s known to work) and I believe it’s pretty much the de facto standard for this task.

KenjiTakahashi commented on 2016-12-16 22:54

@pizzataco: I've written my own after getting annoyed enough by not being able to run makepkg as root anymore :-]. It's still quite hacky on the sides, so I've not released it to the public (yet).

pizzataco commented on 2016-12-14 07:06

So I encountered the same "tabs and spaces" issue when not using a clean chroot, the problem is from python3 I think. If you check out these patches over here:

http://linuxfromscratch.org/blfs/view/svn/x/xcb-proto.html

http://linuxfromscratch.org/blfs/view/svn/x/libxcb.html

It is possible then to patch bin/packages/build.sh from PKGBUILD to include these patches and build without chroot and install the package `pacman -U` style.

However, once you start radium it gives a message that the folder it's in is not writeable by your user.


@KenjiTakahashi what automated build tool are you using? I have always done things according to the AUR wiki page, which does not reference the technique.

KenjiTakahashi commented on 2016-12-01 19:28

I have an automated build tool that always builds in clean chroot :-). But I've triggered it manually to build again and... it went fine. Some transient problem? I don't know, but can't reproduce now, so sorry for the noise.

J5lx commented on 2016-11-30 23:03

That looks weird. For me it built just fine. My best guess right now is that it is somehow related to your system configuration. In that case building the package with archbuild (see https://wiki.archlinux.org/index.php/DeveloperWiki:Building_in_a_Clean_Chroot) should work just fine. I once had a similar issue where my system refused to build any OCaml packages because hardening-wrapper was installed (FS#42748). If archbuild doesn't solve it we'll have to dig deeper.