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

Re: [aur-requests] [PRQ#9564] Deletion Request for steamcmd

by Mark Weiman

On Thu, 2017-10-26 at 20:59 +0000, notify(a)aur.archlinux.org wrote: > Shatur [1] filed a deletion request for steamcmd [2]: > > This package is abandoned and don't work now because need to make > some > changes in PKGBUILD. I'm going to reupload this package and be a > maintainer. > > [1] https://aur.archlinux.org/account/Shatur/ > [2] https://aur.archlinux.org/pkgbase/steamcmd/ First of all, I didn't see the notification for the latest comments. Honestly, one of the problems I wanted to avoid is to have ownership of the files in /usr/share/steamcmd being set to the user running the steamcmd script, which is why I did not change those file permissions to 777 (or something similar with everyone having write permissions). If you run steamcmd as root to allow the app to update (which I originally did, but people complained about it leaving files behind), it does work as expected. The two solutions are as follows, change the .install to tell the user to run as root or just have the .install run steamcmd once. For the TU looking at this, I am active and I do intend to continue maintaining this PKGBUILD. For Shatur, in the future, if you want to take control of a package, file an "Orphan Request" instead of a deletion request. Mark Weiman (markzz)

8 years, 1 month

[aur-requests] [PRQ#36397] Deletion Request for lib50

by notify＠aur.archlinux.org

MayorBender [1] filed a deletion request for lib50 [2]: This package should be deleted for two reasons. The first is that it's already easily install-able through the Package Installer for Python (pip) here: https://pypi.org/project/lib50/ The second is that its dependencies conflict with what's provided by Arch repos. For example, it depends on depends on attrs version >=18.1,<21. This conflicts with the upstream version of attrs, which is 21.4.0 and is the one the Arch repos provide. Meaning the AUR installed version will fail to run and the user will have to install it through pip anyways. Note: I am the original submitter of this PKGBUILD and maintain all AUR packages related to CS50. I tried to find a reasonable way to keep this package up to date in the AUR but considering the dependency conflicts, it no longer makes sense to keep it in the AUR. I will continue to maintain packages related to CS50 that make sense to maintain, such as the libcs50 & libcs50-git packages since they are not easily install-able elsewhere nor do they have annoying dependency conflicts. [1] https://aur.archlinux.org/account/MayorBender/ [2] https://aur.archlinux.org/pkgbase/lib50/

3 years, 5 months

Re: [PRQ#52290] Deletion Request for postgresql-12

by Jake Barnes

On Tuesday, 19 December 2023 at 23:03, notify(a)aur.archlinux.org <notify(a)aur.archlinux.org> wrote: > > > MarsSeed [1] filed a deletion request for postgresql-12 [2]: > > This legacy PostgreSQL v12 (first released in 2019) fails to build on > current Arch Linux. As mentioned in the comments, this package indeed does not build recently due to a breaking change in libxml2, but could probably be easily fixed with a patch if any users are interested in submitting one (I don't actually personally use this package any more). I am not sure if this situation warrants a deletion or not tbh. > > It is also not a drop-in replacement for [extra] repo's postgresql 16. Not sure what you mean by this, older versions of repo packages are common on the AUR. > > I don't think this is useful to keep. > > Users should upgrade their databases for a newer PostgreSQL major > version. Upstream support ends this coming November which would be the deadline for users still on 12, until then it may still be useful to people, since people still complain when it doesn't build. That said, I'm not against deletion if no patch appears for a while. > > [1] https://aur.archlinux.org/account/MarsSeed/ > [2] https://aur.archlinux.org/pkgbase/postgresql-12/

1 year, 11 months

[PRQ#39529] Deletion Request for wemeet-bin

by notify＠aur.archlinux.org

NotOrange [1] filed a deletion request for wemeet-bin [2]: dwm用户，当我选择一个窗口打开wemeet, 然后切换到另一个窗口，此时wemeet会直接崩溃退出，该问题只发生在登陆后的场景，重装wemeet,并且删除～/.local/share/wemeetapp后重复以上操作可以复现，在终端里运行wemeet给不了太多错误信息，不过还是附上 $ wemeet wemeet:WemeetSatrt in3 LoadCustomFont() in4 Microsoft YaHei in4 Microsoft YaHei UI Failed to create variant from json2023-01-03 04:23:24|139696426467584|xnn.XNNHandleMonitor|xnnhandlemonitor.cpp:37||regist handle,type:0 handle:21479072 2023-01-03 04:23:24|139696426467584|xnn.XNNContext|xnncontext.cpp:95||init xnn context succ 2023-01-03 04:23:24|139696426467584|xnn.XNNContext|xnncontext.cpp:134||SetParalleTaskCount, cnt:0 2023-01-03 04:23:24|139696426467584|xnn.XNNRTResource|xnnrtresource.cpp:20||the acc thread cnt is 0 2023-01-03 04:23:24|139696426467584|XNNReg|xnnlayerreg.cpp:726||layer map inited 2023-01-03 04:23:24|139696426467584|xnn.XNNHandleMonitor|xnnhandlemonitor.cpp:37||regist handle,type:0 handle:21480576 2023-01-03 04:23:24|139696426467584|xnn.XNNContext|xnncontext.cpp:95||init xnn context succ 2023-01-03 04:23:24|139696426467584|xnn.XNNContext|xnncontext.cpp:134||SetParalleTaskCount, cnt:0 2023-01-03 04:23:24|139696426467584|xnn.XNNRTResource|xnnrtresource.cpp:20||the acc thread cnt is 0 2023-01-03 04:23:24|139696426467584|XNNReg|xnnlayerreg.cpp:726||layer map inited 2023-01-03 04:23:24|139696426467584|xnn.XNNHandleMonitor|xnnhandlemonitor.cpp:37||regist handle,type:0 handle:21482192 2023-01-03 04:23:24|139696426467584|xnn.XNNContext|xnncontext.cpp:95||init xnn context succ 2023-01-03 04:23:24|139696426467584|xnn.XNNContext|xnncontext.cpp:134||SetParalleTaskCount, cnt:0 2023-01-03 04:23:24|139696426467584|xnn.XNNRTResource|xnnrtresource.cpp:20||the acc thread cnt is 0 NavigationBarViewController::CreateNavigationView():navigation:navgitaion_home 闪退前给的信息就这么多 [1] https://aur.archlinux.org/account/NotOrange/ [2] https://aur.archlinux.org/pkgbase/wemeet-bin/

2 years, 11 months

[PRQ#68185] Deletion Request for wechat

by notify＠aur.archlinux.org

unn [1] filed a deletion request for wechat [2]: we don't want to remove this package, he can do whatever he want to pack what ever he likes, we just want a place to host our wechat-bin package, duplication is a reason that we refuse to accept to merge wechat-bin into this package. You can rename whatever you like of our wechat-bin, we can't accept this package as the only aur package of wechat. If this is the culture or some of the EULA rules, then I would say it's toxic. The behavior of the K user just made the aur his b****. If the merge of wechat-bin is the final desicion of the aur maintainers, I will quit and stop using arch linux. I'm sure you guys don't lack one user of this beloved distribution. The whole thing is an absolute farce, and what's even more unbearable is that the AUR administrators actually condone such behavior. [1] https://aur.archlinux.org/account/unn/ [2] https://aur.archlinux.org/pkgbase/wechat/

11 months, 2 weeks

Re: [aur-requests] [PRQ#18055] Deletion Request for uperm

by Dmitri McGuckin

Not that I care about the package itself but most of the criticisms laid out are subjective. Nothing listed above is explicitly laid out in the guidelines for user-packages: https://wiki.archlinux.org/index.php/Unofficial_user_repositories#Adding_yo… Unless I'm missing something, /opt is intended for user programs. If you have a better idea of where it should be, I'd love to hear it, but again, not inherently a valid reason for removal. All the best, Dmitri McGuckin On Sun, Feb 23, 2020 at 4:42 PM <notify(a)aur.archlinux.org> wrote: > eschwartz [1] filed a deletion request for uperm [2]: > > self-published shellscript with no votes. After extensively reading > the source I sort of think *maybe* it's supposed to chown+chgrp+chmod > a file/directory all at once, but it ha a super vague pkgdesc, > unhelpful --help, and you can just use chown/chmod/chgrp directly with > less bother. It definitely does not meet the guidelines for "useful to > more than one person". > > The main problem, though, is that this installs itself directly to > /opt using sudo. > > [1] https://aur.archlinux.org/account/eschwartz/ > [2] https://aur.archlinux.org/pkgbase/uperm/

5 years, 9 months

Re: [aur-requests] [PRQ#35417] Deletion Request for requests-aws

by Konstantin Shalygin

Hi, I was remove py2 from PKGBUILD We are use this package for [1] and [2] at least. If you knews the "new" library for replacement - I can try rewrite requests part of code [1] https://github.com/blemmenes/radosgw_usage_exporter <https://github.com/blemmenes/radosgw_usage_exporter> [2] https://github.com/cernceph/ceph-scripts/blob/master/tools/s3_quota_notice.… <https://github.com/cernceph/ceph-scripts/blob/master/tools/s3_quota_notice.…> Thanks, k > On 17 Jun 2022, at 01:21, notify(a)aur.archlinux.org wrote: > > MarsSeed [1] filed a deletion request for requests-aws [2]: > > Discontinued after 2015 (both for Python 2.7 and 3). > Nothing depends on either the python (3) or the python2 subpackage. > > I'd suggest to delete this, as part of eliminating truly old packages > that are not used - especially this kind, which is a library, > not an end-user application - to ease maintenance burden also > with respect to dependencies. > > And as AWS is so popular, there are many other currently > supported ways to communicate with it. > > I think it's safe to suppose that a 7-year-old interface > library for a fast-developing cloud provider such as Amazon/AWS > could not really be relied upon for stability or security. > > [1] https://aur.archlinux.org/account/MarsSeed/ > [2] https://aur.archlinux.org/pkgbase/requests-aws/

3 years, 6 months

[PRQ#48751] Deletion Request for waybar-hyprland-cava-git

by notify＠aur.archlinux.org

MarsSeed [1] filed a deletion request for waybar-hyprland-cava-git [2]: This package is now defunct. TLDR; Waybar now fully supports Hyprland workspaces and persistent workspaces. Also the patch used in this package is no longer valid or workable. Details: Since waybar 0.9.20+ release, upstream no longer invokes the hyprctl CLI to manipulate and query Hyprland workspaces. The patch is based on invoking hyprctl. Also @zjeffer, one of the contributing developers of Waybar replied on 2023-09-07 to my remark above that I submitted as a comment on the AUR/waybar-hyprland-git page [a]: " I can confirm that this package is no longer necessary, for the reasons @MarsSeed listed, and also the fact that wlr/workspaces does not work anymore with Hyprland, since this Hyprland commit: https://github.com/hyprwm/Hyprland/commit/bb09334 " The patch used in 'waybar-hyprland-cava-git' modifies Waybar's wlr/workspaces manager, which is defunct for Hyprland. Users and maintainer have been notified by me in the beginning of September 2023. [a]: https://archive.li/eoEyI#comment-932841 [1] https://aur.archlinux.org/account/MarsSeed/ [2] https://aur.archlinux.org/pkgbase/waybar-hyprland-cava-git/

2 years, 2 months

[PRQ#42431] Deletion Request for nodejs-astrojs-language-server

by notify＠aur.archlinux.org

MarsSeed [1] filed a deletion request for nodejs-astrojs-language- server [2]: Please delete this, name does not follow Node.js package guidelines. [a] @tlvince, thank you for making this PKGBUILD available for others to use. Please kindly resubmit under a new, proper name: astrojs-language-server See naming rules - basically only nodejs libraries shoud be prefixed with 'nodejs-'. A language server is to be consumed as a plugin by any type of LSP- conformant application, not just nodejs modules. See other language servers hosted by Arch repo - the majority of them are nodejs code, but they don't have that name prefix: https://archlinux.org/packages/?q=language-server Another reason for my requested renaming is that prefixing language servers with the name of their interpreter would just lead to unnecessary confusion. See some fictitious examples I've made up based on existing LSP packages to illustrate: - go-arduino-language-server (Arduino LSP) - java-groovy-language-server (Groovy LSP) - nodejs-bash-language-server (Bash LSP) - python-cmake-language-server (CMake LSP) - typescript-java-gradle-language-server (Gradle LSP) [a]: https://wiki.archlinux.org/title/Node.js_package_guidelines#Package_naming [1] https://aur.archlinux.org/account/MarsSeed/ [2] https://aur.archlinux.org/pkgbase/nodejs-astrojs-language-server/

2 years, 6 months

Re: [aur-requests] [PRQ#22517] Orphan Request for pipewire-git

by sL1pKn07 SpinFlo

El mié, 2 dic 2020 a las 22:39, <notify(a)aur.archlinux.org> escribió: > > annisar [1] filed an orphan request for pipewire-git [2]: > > (This is 2nd request for the topic, previous was rejected because it > was wrongfully marked as deletion request instead of the orphan one) > > The package maintainer used very popular name that's in typical AUR > convention to introduce changes that are misleading and mainly usable > by himself only, which is not reflected by the name. I request for > deletion of it or changing the ownership (to me, for an example) so > someone can maintain the package more responsibly. There's a lot of > people who install -git packages without checking the PKGBUILD, > expecting that these will be built from master-bound official > PKGBUILD. Considering this, maintainer's behavior can be described as > irresponsible from community standpoint. > > [1] https://aur.archlinux.org/account/annisar/ > [2] https://aur.archlinux.org/pkgbase/pipewire-git/ Hi for the record https://lists.archlinux.org/pipermail/aur-requests/2020-November/046657.html greetings

5 years

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