The package does not compile for me, because java8-openjfx does not compile (java 8 should be installed, but java 17 is installed in my system). Checking the change log of Ányk: 2015: minimum java version is 1.8. 2019: works with java 9. I don't see any reason we should stuck with java 8. For me, Ányk compiles and works with the latest java-openjfx (java 17).
Search Criteria
Package Details: anyk 3.36.0-1
Package Actions
Git Clone URL: | https://aur.archlinux.org/anyk.git (read-only, click to copy) |
---|---|
Package Base: | anyk |
Description: | Form fill program of the Hungarian tax office (Általános Nyomtatványkitöltő (ÁNYK)) |
Upstream URL: | https://www.nav.gov.hu/nav/letoltesek/nyomtatvanykitolto_programok/nyomtatvany_apeh/keretprogramok/abevjava_install.html |
Keywords: | abevjava adó általános ányk apeh nav nyomtatványkitöltő |
Licenses: | Apache |
Provides: | abevjava |
Submitter: | mark.sagikazar |
Maintainer: | mark.sagikazar (bence.hornak, norbert.balazs) |
Last Packager: | norbert.balazs |
Votes: | 6 |
Popularity: | 0.000015 |
First Submitted: | 2016-02-03 16:50 (UTC) |
Last Updated: | 2024-12-17 18:34 (UTC) |
Dependencies (3)
- jre8-openjdk
- unzip (unzip-natspecAUR, unzip-zstdAUR) (make)
- ttf-ms-fontsAUR (ttf-win7-fontsAUR, ttf-ms-win8AUR, ttf-ms-win8-arabicAUR, ttf-ms-win8-hebrewAUR, ttf-ms-win8-seaAUR, ttf-ms-win8-indicAUR, ttf-ms-win8-japaneseAUR, ttf-ms-win8-koreanAUR, ttf-ms-win8-zh_cnAUR, ttf-ms-win8-zh_twAUR, ttf-ms-win8-thaiAUR, ttf-ms-win8-otherAUR, ttf-ms-win10AUR, fake-ms-fontsAUR, ttf-ms-win10-autoAUR, ttf-ms-win11-autoAUR, ttf-ms-win10-cdnAUR, ttf-ms-win11AUR) (optional) – for better font rendering
Required by (0)
Sources (6)
nagyesz commented on 2022-03-16 08:05 (UTC)
norbert.balazs commented on 2022-03-12 15:43 (UTC)
Seems like the GID can't be dynamic because of the way the package installation works. I updated it to 569, which is not conflicting with any GID listed here: https://wiki.archlinux.org/title/DeveloperWiki:UID_/_GID_Database
From my testing, this change doesn't seem to affect existing installations, but I have a hunch that next the upgrade may not work correctly if you already have the anyk group with GID 169.
In that case, running this + a relogin will fix it:
sudo groupmod -g 569 anyk
sudo chgrp -R 569 "/usr/share/abevjava/abev"
sudo chgrp -R 569 "/usr/share/abevjava/eroforrasok"
sudo chgrp -R 569 "/usr/share/abevjava/nyomtatvanyok"
sudo chgrp -R 569 "/usr/share/abevjava/upgrade"
sudo chgrp -R 569 "/usr/share/abevjava/segitseg"
labuwx commented on 2022-03-12 05:12 (UTC)
Hi,
The sys group ID (169) is in conflict with transmission-cli
.
In this case the group is still created but with a different ID.
Could you please pick a different ID, or use chgrp -R anyk ...
norbert.balazs commented on 2022-01-12 21:47 (UTC)
Fixed. Looks like nav messed up the rpm link on their site. The package still has 3.11.0 in the name, but it actually points to 3.12.0.
tombenko commented on 2022-01-12 19:22 (UTC)
==> Making package: anyk 3.11.0-1 (Wed Jan 12 20:22:03 2022) ==> Checking runtime dependencies... ==> Checking buildtime dependencies... ==> Retrieving sources... -> Found abevjava_install-3.11.0-0.1.noarch.rpm -> Found abevjava -> Found abevjavapath.cfg -> Found anyk.desktop -> Found setenv -> Found anyk.sysusers ==> Validating source files with md5sums... abevjava_install-3.11.0-0.1.noarch.rpm ... FAILED abevjava ... Passed abevjavapath.cfg ... Passed anyk.desktop ... Passed setenv ... Passed anyk.sysusers ... Passed ==> ERROR: One or more files did not pass the validity check!
mark.sagikazar commented on 2021-02-22 17:56 (UTC)
Frissítettem a csomagot.
Winux11 commented on 2021-02-20 21:58 (UTC)
Sajnos megint nem jó a csomag
mark.sagikazar commented on 2021-01-11 14:03 (UTC)
Nemsokára átállok a világos oldalra megint (aka. lesz Archom), úgyhogy remélhetőleg fogom tudni frissítgetni, de ha bárki beugrana addig, feel free to ping me.
sajo commented on 2021-01-11 13:48 (UTC)
A 2021. január 8-i csomagfrissítés óta nem működik a build.
Pinned Comments
norbert.balazs commented on 2022-03-12 15:43 (UTC)
Seems like the GID can't be dynamic because of the way the package installation works. I updated it to 569, which is not conflicting with any GID listed here: https://wiki.archlinux.org/title/DeveloperWiki:UID_/_GID_Database
From my testing, this change doesn't seem to affect existing installations, but I have a hunch that next the upgrade may not work correctly if you already have the anyk group with GID 169.
In that case, running this + a relogin will fix it: