Package Details: nasc 0.8.0-2

Git Clone URL: https://aur.archlinux.org/nasc.git (read-only, click to copy)
Package Base: nasc
Description: Do maths like a normal person.
Upstream URL: https://parnold-x.github.io/nasc/
Licenses: GPL3
Conflicts: nasc-bzr, nasc-git
Submitter: aperez
Maintainer: aperez
Last Packager: aperez
Votes: 9
Popularity: 0.001052
First Submitted: 2018-03-21 12:50 (UTC)
Last Updated: 2022-09-08 12:49 (UTC)

Latest Comments

aperez commented on 2022-09-08 12:51 (UTC)

@komex: Thanks for the tip, I have pushed your suggested fix =)

komex commented on 2022-08-31 10:21 (UTC)

Hi, @aperez. I have an error while building package:

nasc-0.8.0/subprojects/libqalculate/libqalculate/meson.build:119:0: ERROR: declare_dependency keyword argument 'link_with' was of type array[str] but should have been array[BothLibraries | SharedLibrary | StaticLibrary | CustomTarget | CustomTargetIndex | Jar | Executable | Dependency]

To fix that, I've added one line to the end of prepare() in PKGBUILD:

sed -i "s/link_with: 'libqalculate_lib_static'/link_with: libqalculate_lib_static/g" libqalculate/libqalculate/meson.build

Could you, please, check this works and fix build?

alerque commented on 2021-01-07 15:26 (UTC)

@ghoti It's not a compatibility problem. This app works fine but it must be rebuilt using sources that match the ICU version you are running. If you installed manually rebuild and it will work fine. If you used yay, try yay --rebuild -S nasc.

ghoti commented on 2020-12-31 17:42 (UTC)

the ICU UC libraries seem to be broken, and 67 and 68 really do appear to be incompatible with eachother.

Not sure what could be done to fix this.

darrSonik commented on 2020-12-27 06:23 (UTC)

icu package got updated, but this build still points at libicuuc.so.67. Therefore, it fails to start. It should point to libicuuc.so.68 while loading shared libraries.

alerque commented on 2020-08-31 07:32 (UTC) (edited on 2021-04-19 11:55 (UTC) by alerque)

Renaming the binary does not achieve any practical goal

Sure it does. It would mean I can launch it from the CLI or my desktop UI's launcher by typing in something sensible and expected. Reverse domain names as /usr/bin entries are nonsense and I have no idea what to type from the command line to find them.

Even the upstream started out doing something sensible and only switched to the RDNN scheme because their primary distribution channel is Elementary OS's AppCenter and it uses RDNN for all desktop apps. Their entire user model is heavily mouse/menu driven though so they don't care about the things Arch Linux users are likely to care about. I want to be able to launch an app under the sensible name that the $pkgname and even upstream project repository are sensible enough to use: nasc.

I don't see why Arch packaging should be held to doing silly things like this just because some other OS packaging scheme calls for them.

Alexmaras commented on 2020-08-13 13:52 (UTC)

Thanks @aperez, fair point. It's a fairly unfortunate binary name to launch, but I suppose a user can symlink if they prefer the actual app name instead of the namespaced one.

aperez commented on 2020-08-12 18:40 (UTC)

@Alexmaras: In general the way things are done when packaging software for Arch is avoiding modifications of the upstream software if possible. Renaming the binary does not achieve any practical goal, and would introduce differences with upstream, so I would rather not do that.

Alexmaras commented on 2020-08-11 05:50 (UTC) (edited on 2020-08-11 05:50 (UTC) by Alexmaras)

Might be worth updating the PKGBUILD package() function to rename the binary from com.github.parnold-x.nasc to just nasc