Search results for "Deletion request for pkgbase" - Aur-requests

Re: [aur-requests] [PRQ#23743] Deletion Request for brutal-legend-hib

by Christopher Snowhill (kode54)

What? The developer let the primary domain expire, but they still list it on their main site, which is still maintained: https://www.doublefine.com/games/brutal-legend And the Humble Bundle store still sells it here: https://www.humblebundle.com/store/brutal-legend Not sure if the DRM-free direct download or torrent installer was exclusive to the old bundles it was included in, or if this store portal lets you acquire the same installers. Usually purchases from HB add to a list on your account with them, which lets you retrieve installers for all supported computer and sometimes mobile platforms, and sometimes included keys for stores like Steam instead of the original DRM-free downloads. > On Feb 18, 2021, at 1:11 AM, notify--- via aur-requests <aur-requests(a)lists.archlinux.org> wrote: > > fordprefect [1] filed a deletion request for brutal-legend-hib [2]: > > Lost relevance long ago, even the upstream web presence vanished and > became a russian something site. > > [1] https://aur.archlinux.org/account/fordprefect/ > [2] https://aur.archlinux.org/pkgbase/brutal-legend-hib/

4 years, 10 months

[PRQ#67154] Deletion Request for curl-quiche-git

by notify＠aur.archlinux.org

MarsSeed [1] filed a deletion request for curl-quiche-git [2]: Unused, badly packaged, unneeded. Executes git clone in prepare(), to fetch CloudFlare's quiche library, recursively, with its boringssl git submodule repo (the latter is Google's somewhat experimental fork of openssl.) BoringSSL's statically built libcrypto.a and libssl.so are used in this curl build, but still the PKGBUILD erroneously lists 'openssl' in depends. Also the pkgname is not good enough: it should reference 'boringssl' too, not just 'quiche', to differentiate from default Arch curl and AUR/curl-git build. Now upsteam openssl supports the QUIC protocol natively, and so does the stable curl release in repo - doesn't need BoringSSL and the quiche library for it. As for AUR usage, or the lack thereof: Votes: 0 Popularity: 0.000000 First Submitted: 2023-04-05 Last Updated: 2023-04-05 Comments: 0 Specific reverse dependencies: 0 [1] https://aur.archlinux.org/account/MarsSeed/ [2] https://aur.archlinux.org/pkgbase/curl-quiche-git/

1 year

[PRQ#68075] Deletion Request for tako

by notify＠aur.archlinux.org

TrialnError [1] filed a deletion request for tako [2]: This is a project, which isn't actively maintained anymore, although the owner may still use it?[0][1] Latest release is 0.2.8 (found on pypi.org and not on the homepage itself) which brought minimal support for python3.8. And this source cannot be compiled with python3.10+ (ImportError: cannot import name 'Sequence' from 'collections'). Was moved into collections.abc. [2]. If that would be the only issue, it could be patched. But I suspect there is more. And I don't intend to put time into this. Furthermore this PKGBUILD is broken since years and no one complained. Usage == 0. I assume people are most likely using xonsh (tako being a fork of xonsh) ___________ [0] https://hz.mit.edu/ (software -> things I use, but don't maintain) [1] https://takoshell.org/contact.html [2] https://docs.python.org/3/library/collections.abc.html [1] https://aur.archlinux.org/account/TrialnError/ [2] https://aur.archlinux.org/pkgbase/tako/

11 months, 3 weeks

[aur-requests] [PRQ#35643] Deletion Request for python2-pycrypto

by notify＠aur.archlinux.org

MarsSeed [1] filed a deletion request for python2-pycrypto [2]: This is not required. It has been discontinued in 2013 and has been replaced by [community] python2-pycryptodome. The package is also not proper, as this should at least conflict with python2-pycryptodome; as they share the same namespace. PyCryptodome is the continuation fork of this deprecated module, therefore there is no good reason to provide this except maybe to very old modules before 2012 (which, if exist, have a high chance of not working correctly now with Python 2.7 anyway). Even worse, it declares it provides python2-pycryptodome, which is impossible; an ancestor module from 2013 cannot provide 2022's version of its successor module. Anyway, nothing in AUR requires this. They depend either on python2-pycryptodome from repo, or on 'python2-crypto', which leads them to use the former from repo (via its virtual provides). So I urge you to delete this package. [1] https://aur.archlinux.org/account/MarsSeed/ [2] https://aur.archlinux.org/pkgbase/python2-pycrypto/

3 years, 5 months

Re: [PRQ#42534] Deletion Request for linux-pf-stable-git

by Yurii Kolesnykov

But I agree that the package's purpose is very niche, so I agree with deletion. > 5 лип. 2023 р. о 06:55 Yurii Kolesnykov <root(a)yurikoles.com> написав(ла): > > linux-pf points to the latest stable _tag_ while linux-pf-stable-git points to the latest stable _branch_ > >> 22 черв. 2023 р. о 13:59 notify(a)aur.archlinux.org написав(ла): >> >> MarsSeed [1] filed a deletion request for linux-pf-stable-git [2]: >> >> Having this package is pointless. >> >> The linux-pf repo always points to the latest stable branch. >> >> This package is also outdated without manual intervention by ower: it >> still points to linux-pf 6.2 branch even though 6.3 is the latest >> stable branch. >> >> The AUR/linux-pf-git package is enough to keep. >> >> [1] https://aur.archlinux.org/account/MarsSeed/ >> [2] https://aur.archlinux.org/pkgbase/linux-pf-stable-git/ > >

2 years, 5 months

[PRQ#59681] Deletion Request for flexpkg

by notify＠aur.archlinux.org

MarsSeed [1] filed a deletion request for flexpkg [2]: #include <cstdlib> Junk pkg that runs sudo during runtime and deletes and puts files inside /usr/: https://github.com/VPeti1/CWAcces/blob/e94a00c/flexpkg.tar.gz C++ source code of included file 'installer.cpp': #include <iostream> #define clear std::cout << "\033[2J\033[1;1H"; using namespace std; int main() { clear; system("sudo touch /usr/flex/arch.cw"); clear system("read -p 'Press Enter to continue...'"); system("sudo rm -rf /usr/flex/"); system("sudo mkdir /usr/flex"); system("sudo git clone https://github.com/VPeti1/FlexPkg.git /usr/flex"); system("sudo g++ /usr/flex/run.cpp -o /bin/flex"); system("sudo chmod +x /bin/flex"); system("sudo rm -r /usr/flex/chococ.cpp /usr/flex/chococ.exe /usr/flex/installer.cpp /usr/flex/installer.out /usr/flex/LICENSE /usr/flex/README.md /usr/flex/run.cpp /usr/flex/run.out /usr/flex/examples /usr/flex/wininstall"); } [1] https://aur.archlinux.org/account/MarsSeed/ [2] https://aur.archlinux.org/pkgbase/flexpkg/

1 year, 7 months

Re: [PRQ#66341] Deletion Request for puppet-bolt-git

by Marcell Meszaros

>dpvpro [1] filed a deletion request for puppet-bolt-git [2]: > >Very old version software > >[1] https://aur.archlinux.org/account/dpvpro/ >[2] https://aur.archlinux.org/pkgbase/puppet-bolt-git/ The version is actually very new. Latest upstream commit as of now is from 20 November 2024. [a] The problem lies elsewhere. The PKGBUILD cannot be built as is, due to lacking the needed makedepends=rubygems. And it violates Arch packaging etiquette by executing gem install net-ssh-krb which, if the user happens to have rubygems installed, can result in a Ruby module getting installed system-wide. It is also missing its required runtime depends, the mandatory provides entry, and does not execute testing despite the Arch Ruby package guidelines calling for it. All in all, these together can be reason enough for deletion, along with the following evidence of complete disuse of this broken package: Votes: 1 Popularity: 0.000000 Comments: 0 Specific reverse dependencies: 0 First Submitted: 2020-02-08 08:12 (CET) Last Updated: 2020-02-08 08:12 (CET) [a]: https://github.com/puppetlabs/bolt

1 year

[PRQ#44684] Deletion Request for rocblas-polaris

by notify＠aur.archlinux.org

MarsSeed [1] filed a deletion request for rocblas-polaris [2]: Abandoned patched variant from 2022-04 of rocblas, available in repo. One-time effort, flagged OOD since 2022-07, but never updated. Doesn't declare the needed conflicts. Uploader never tested his, due to lack of sufficient hardware to build. Two other users tried to compile but got severe, complicated errors. Gfx8 (gfx803) Radeon devices from 2017 like Radeon RX 550, 570, 580 have been having crashes as far back as ROCm 3.7, then ROCm 4.0 in 2020 has officially declared that these platforms as unsupported. [a] Just because a patched build enables the use of these legacy GPU's, it won't make this rocblas 5.x build run without errors, if it works at all. Not useful to keep this unofficial, broken package that falsely promises compute support for legacy GPU's from 2017. [a]: https://github.com/RadeonOpenCompute/ROCm/issues/1353 [1] https://aur.archlinux.org/account/MarsSeed/ [2] https://aur.archlinux.org/pkgbase/rocblas-polaris/

2 years, 5 months

Re: [PRQ#49071] Deletion Request for jdk13-openjdk-bin

by Marcell Meszaros

Hi, Thank you for your reply, and sorry that I didn't consider this. I will revoke my deletion request shortly. Cheers, Marcell (MarsSeed) On 16 October 2023 17:09:16 GMT+02:00, "Jochum Döring" <jochum(a)home.nl> wrote: >Have you looked into this? It's a dependency for a CNC software package. It won't work without this specific version. >The depending package is actively being worked on and has since migrated to jdk17, but building with jdk17 currently fails and succeeds with openjdk13. I'm working with the devs to find a solution. >So for now it is still required until the problem is resolved. > >On 16-10-23 14:39, notify(a)aur.archlinux.org wrote: >> MarsSeed [1] filed a deletion request for jdk13-openjdk-bin [2]: >> >> Cleanup of deprecated JDK 13 short-term support packages. >> >> JDK 13 is EOL since March 2020; >> not even security patches get delivered after that date. >> >> Users should migrate to a newer JDK/JRE. >> >> [1] https://aur.archlinux.org/account/MarsSeed/ >> [2] https://aur.archlinux.org/pkgbase/jdk13-openjdk-bin/ >

2 years, 2 months

Re: [PRQ#57160] Merge Request for ffmpeg21 Rejected

by Marcell Meszaros

>>MarsSeed [1] filed a request to merge ffmpeg21 [2] into ffmpeg2.1 [3]: >> >>Package got renamed by maintainer, and changed the two reverse >>dependencies to require the new one instead of the old. >> >>[1] https://aur.archlinux.org/account/MarsSeed/ >>[2] https://aur.archlinux.org/pkgbase/ffmpeg21/ >>[3] https://aur.archlinux.org/pkgbase/ffmpeg2.1/ > >Request #57160 has been Rejected by Foxboron [1]: > >Submit a deletion request. Foxboron, thank you for your guidance. Please help me to understand by what measure I should have known that metadata is not important here. The way I see it: - Maintainer has renamed and resubmitted the package. - There are comments and change notification subscriptions on the old package. - The new package is supposed to "replace" the old one. So in this particular case, I seem to be unable to reconcile your previous recommendation about the usage of merge to keep metadata with your current decision to not transfer such with a merge. Thank you in advance for your help in clearing this up for me. Cheers, Marcell / MarsSeed

1 year, 8 months

Aur-requests search results for query "Deletion request for pkgbase"