Package Details: radium 7.4.76-1

Git Clone URL: https://aur.archlinux.org/radium.git (read-only, click to copy)
Package Base: radium
Description: A graphical music editor. A next generation tracker.
Upstream URL: https://users.notam02.no/~kjetism/radium
Licenses: GPL2
Groups: pro-audio
Submitter: speps
Maintainer: yustin (Carotino)
Last Packager: yustin
Votes: 19
Popularity: 0.000002
First Submitted: 2013-05-22 03:41 (UTC)
Last Updated: 2024-06-07 06:47 (UTC)

Dependencies (50)

Required by (0)

Sources (3)

Pinned Comments

Latest Comments

« First ‹ Previous 1 .. 3 4 5 6 7 8 9 10 11 12 Next › Last »

Teteros commented on 2017-04-29 06:38 (UTC) (edited on 2017-04-29 07:03 (UTC) by Teteros)

Indeed 4.7.6 compiles without errors. However after I installed the build package and try to run radium, this is the output. $ radium JUCE v4.2.4 INIT4 INIT5 Executing -LD_LIBRARY_PATH= /opt/radium/crashreporter L3RtcC9yYWRpdW0uSjEyNjY4 PG5vcGx1Z2lubmFtZXM+ PG5vZW1lcmdlbmN5c2F2ZT4= is_crash&- QWidget: Must construct a QApplication before a QWidget Official x64 build runs without this error.

J5lx commented on 2017-04-28 20:18 (UTC)

The commit you mentioned is part of 4.7.6, so I suppose their is nothing special left to do for me. That aside, the package builds perfectly fine for me, both 4.7.4 and 4.7.6, so I’m a little curious as to what exactly you are referring to.

Teteros commented on 2017-04-27 21:15 (UTC)

New master: https://github.com/kmatheussen/radium/commit/6078496bfd480e882a879d49b1f9fb9d7e9b770b Allows it to build now, but I am getting "QWidget: Must construct a QApplication before a QWidget" on runtime with it, and 4.7.4

Teteros commented on 2017-04-11 20:58 (UTC)

You're right, on investigation: the extra files present in /opt/radium are actually the ones radium creates when it's able to at runtime (the 'warning' file import_midi/mod, python stuff, logs, autosaves...) Making whole .install file redundant, unless used for documenting.

J5lx commented on 2017-04-11 20:33 (UTC)

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 (UTC)

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 (UTC)

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 (UTC) (edited on 2017-04-09 05:34 (UTC) by Teteros)

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 (UTC)

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 (UTC)

@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.

« First ‹ Previous 1 .. 3 4 5 6 7 8 9 10 11 12 Next › Last »