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

Re: [PRQ#42892] Deletion Request for xdg-utils-no-open

by Marcell Meszaros

After lingering in abandonment for the last 5 years, now after my deletion request, maintainer @frankenau added provides and conflicts fields requested by a user in 2021. But I still see no point in keeping this package. There is no maintained alternative of xdg-open on AUR, and that script is still needed by many applications. So this package will just break lots of things. Also it is still outdated compared to repo version of xdg-utils. On 27 June 2023 12:23:20 GMT+02:00, notify(a)aur.archlinux.org wrote: >MarsSeed [1] filed a deletion request for xdg-utils-no-open [2]: > >Abandoned mod of repo's xdg-utils. >Last updated in 2018. > >Badly packaged: no provides or conflicts. >Cannot be installed on most systems because of this. > >There is only one comment: a user mentions this same problem in >2022-11. They got no reply from maintainer. > >Better to delete this defunct package. > >[1] https://aur.archlinux.org/account/MarsSeed/ >[2] https://aur.archlinux.org/pkgbase/xdg-utils-no-open/

2 years, 5 months

Re: [aur-requests] [PRQ#10358] Deletion Request for nodejs-fake

by Eli Schwartz

On 01/19/2018 01:24 PM, Eric Jardas via aur-requests wrote: > On 19/01/2018 sL1pKn07 fabio via aur-requests wrote: >>///FabioLolix [1] filed a deletion request for nodejs-fake [2]: />//>///pacman --assume-installed option exist />//>///[1] https://aur.archlinux.org/account/FabioLolix/ > <https://aur.archlinux.org/account/FabioLolix/> //>///[2] https://aur.archlinux.org/pkgbase/nodejs-fake/ > <https://aur.archlinux.org/pkgbase/nodejs-fake/>/// / > > > Of course it does, but that has to be used on every update and > installation of package that has nodejs as dependency (which lets be > honest not a lot of people look into before installing a package). > This pseudo package helps nvm be the only source of nodejs regardless of > installs and updates. Since the package is in aur, it doesn't have to be > used if you want to do the hassle of using --assume-installed on every > install and update. Having a choice is a good thing in my opinion. IMHO it is less about --assume-installed existing, and more about "if we let people submit dummy packages, eventually we will have one dummy package in the AUR for each real package in the repos, on top of the numerous variations, patched versions, git version, devel versions, and compat versions". If you really need a dummy package, why can't you just make your own private dummy package? It's what I do... This has the advantage of not cluttering up the AUR with do-nothing packages. ... For people who do not know how to make a dummy package on their own, I'm not sure we should condone offering them an easy way to fool pacman's dependency parsing. They'll just get into trouble when it finally breaks on them. -- Eli Schwartz Bug Wrangler and Trusted User

7 years, 11 months

[aur-requests] [PRQ#32194] Deletion Request for libx32-python-greenlet

by notify＠aur.archlinux.org

MarsSeed [1] filed a deletion request for libx32-python-greenlet [2]: Please delete libx32- AUR packages: • Package has not been updated in 6 years or more. • Owner replied in email to me, agreeing to the deletion. • In case of libx32- packages, naming violates Arch guidelines*. Name should end with '-x32', not start with 'libx32-'. • Most such packages cannot be built because of already dropped dependencies from AUR. • Even if built, X32 executables won't work with any mainstream kernels from any distros. Only on kernels custom-built with niche x32 ABI support. • Whoever wants to use such a special architecture would not be able to use it from unbuildable, unmaintained 6-year old build scripts from the AUR. But they could use Debian x32 or build Gentoo from scratch for the x32 ABI, or find some IoT-specific distro (X32 ABI might be relevant for some low-end IoT devices). [1] https://aur.archlinux.org/account/MarsSeed/ [2] https://aur.archlinux.org/pkgbase/libx32-python-greenlet/

3 years, 10 months

Re: [PRQ#74893] Deletion Request for wlroots-0.19-mao-git

by xiota

Asserts are typically disabled when building for release. However, if patch is actually needed, should open an issue at https://gitlab.archlinux.org/archlinux/packaging/packages/wlroots0.19 to request backport. On Sun, Jul 27, 2025 at 11:15 AM 雅色清茶 <2523610504(a)qq.com> wrote: > On Sun Jul 27, 2025 at 11:10 PM CST, notify wrote: > > xiota [1] filed a deletion request for wlroots-0.19-mao-git [2]: > > > > Should be deleted on basis that it is not useful. Commit was merged > > upstream [a]. extra/wlroots0.19 works fine. > > > > [a] > > > https://gitlab.freedesktop.org/wlroots/wlroots/-/commit/a08acfcee0261ae9b08… > > > > [1] https://aur.archlinux.org/account/xiota/ > > [2] https://aur.archlinux.org/pkgbase/wlroots-0.19-mao-git/ > > This patch is not included in the current wlroots0.19,we need to wait > for the 0.19.1 backports to release. > > https://gitlab.freedesktop.org/wlroots/wlroots/-/merge_requests/5094 > >

4 months, 3 weeks

[aur-requests] [PRQ#24368] Deletion Request for vim-coc-master-git

by notify＠aur.archlinux.org

sainnhe [1] filed a deletion request for vim-coc-master-git [2]: The upstream releases their source code in a very different way: the default branch "release" doesn't contain any src, but only provides some precompiled javascript files, while the development branch "master" contains the typescript code that needs to be compiled. This package is based on master branch, but I realized that it doesn't match the naming rules, it should be named as "vim-coc-git" since it needs to be compiled from src. The current "vim-coc-git" is based on release branch which doesn't need to be compiled, I think it should be renamed as "vim-coc-bin- git". So I request to remove this package, I'm going to create "vim-coc-bin" and "vim-coc-bin-git" later. [1] https://aur.archlinux.org/account/sainnhe/ [2] https://aur.archlinux.org/pkgbase/vim-coc-master-git/

4 years, 8 months

Re: [aur-requests] [PRQ#6744] Deletion Request for libtiff3

by Doug Newgard

On Sun, 30 Oct 2016 21:10:51 -0500 Doug Newgard <scimmia(a)archlinux.info> wrote: > On Sun, 30 Oct 2016 23:04:35 +0000 > WorMzy Tykashi via aur-requests <aur-requests(a)archlinux.org> wrote: > > > On 30 October 2016 at 23:00, <notify(a)aur.archlinux.org> wrote: > > > > > > WorMzy [1] filed a deletion request for libtiff3 [2]: > > > > > > Now in Community: > > > https://www.archlinux.org/packages/community/x86_64/libtiff4/ > > > > > > [1] https://aur.archlinux.org/account/WorMzy/ > > > [2] https://aur.archlinux.org/pkgbase/libtiff3/ > > > > > > My bad, this package is a split package which also provides libtiff3 > > so should be updated rather than removed. > > > > Sorry for the noise. > > No, you're right. The other package (which was just symlinks) is now correctly > provided in community as well. Er, nevermind, I made the same mistake you did.

9 years, 1 month

Re: [PRQ#47128] Deletion Request for lib32-smbclient

by Fabian Maurer

On Samstag, 9. September 2023 21:00:49 CEST you wrote: > El sáb, 9 sept 2023 a las 14:50, <notify(a)aur.archlinux.org> escribió: > > DarkShadow44 [1] filed a deletion request for lib32-smbclient [2]: > > > > This is not needed anymore, the last packages that had this as > > dependency (lib32-gnome-vfs) was deleted a while ago. > > > > [1] https://aur.archlinux.org/account/DarkShadow44/ > > [2] https://aur.archlinux.org/pkgbase/lib32-smbclient/ > > needs for wine You're right, wine configure mentions missing support when that 32bit samba is missing. Not sure what exactly it does though, it's not even optional for wine and the wine tests pass even without the libs installed... FWIW, once the thunks work well enough, 32bit dependencies are going to be obsolete anyways. Should we keep it around until then? Regards, Fabian Maurer

2 years, 3 months

[aur-requests] [PRQ#16877] Deletion Request for fairy-wallet

by notify＠aur.archlinux.org

diabonas [1] filed a deletion request for fairy-wallet [2]: This (recently) orphaned package has multiple severe issues: - Currently it doesn't even build due to the wrong pkgver() function ("git describe" for a non-Git source). - It attempts to dynamically update the source array according to the latest upstream version (cf. the "$Version" variable), potentially leading to a mismatch between sources and pkgver. - It downloads precompiled binaries instead of building from source, so the package should be named fairy-wallet-bin. - The precompiled binary doesn't even work, it segfaults on startup. This could possibly be fixed by building from source, but I don't own the required physical hardware to verify this. Given the low popularity of the AUR and the fact that there is no active upstream development any more, I suggest deleting the package altogether. [1] https://aur.archlinux.org/account/diabonas/ [2] https://aur.archlinux.org/pkgbase/fairy-wallet/

6 years

Re: [PRQ#37842] Deletion Request for polymc-bin

by Morten Linderud

On Mon, Oct 17, 2022 at 07:38:01PM +0000, notify(a)aur.archlinux.org wrote: > thenumeralone [1] filed a deletion request for polymc-bin [2]: > > Hi! There was a hostile takeover upstream by LennyLennington. It is > not known if their account was hacked. Until upstream resolves this I > would recommend removing LennyLennington as maintainer and replacing > them with Scrumplex in order to prevent malware from being introduced. > Deletion would also be fine. > > I would recommend verifying my story by emailing Scrumplex. > > I am submitting an equivalent request for polymc-git. > > [1] https://aur.archlinux.org/account/thenumeralone/ > [2] https://aur.archlinux.org/pkgbase/polymc-bin/ This got a bit messy. Can't force orphan any packages so I have accidentally deleted one. Scrumplex is back as co-maintainer while I consider the other options. The Lenny guy has been banned until we know what is happening. Feel free to say if anything else needs to be done. -- Morten Linderud PGP: 9C02FF419FECBE16

3 years, 2 months

[PRQ#49347] Deletion Request for libpcl

by notify＠aur.archlinux.org

MarsSeed [1] filed a deletion request for libpcl [2]: This EOL library was last released in 2010. Current source and upstream URL leads to 404 not found error. Not useful to keep this package: the only functioning and actively maintained packages that could utilize it are AUR/ocserv and ocserv- git, but actually ocserv upstream tree contains the project's own maintenance fork of pcl, which at this point should be the preferred version of the pcl library when building ocserv. (That pcl code was last updated 4 months ago as of this writing, as opposed to 13 years ago for the original libpcl.) I've submitted a comment on each packages' AUR page to inform maintainer and the community about this situation, and the recommended resolution, to remove depends=libpcl from those PKGBUILDs. [1] https://aur.archlinux.org/account/MarsSeed/ [2] https://aur.archlinux.org/pkgbase/libpcl/

2 years, 2 months

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