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

Re: [PRQ#73744] Deletion Request for icecat

by xiota

1. There is precedent of rejection of deletion requests on the basis of critical security vulnerability. 2. Deletion of package would not protect existing users because nothing requires them to actually switch browsers. 3. This package poses no risk to potential users because it is currently unbuildable with Arch toolchain. Maintainers are still attempting to fix the package and watching for upstream changes that might improve the situation. Deletion would prevent the package from being fixed, prevent users from receiving notifications, and allow takeover by someone without intent to actually fix it. 4. Votes do not indicate actual usage. On Wed, Jun 4, 2025 at 7:55 AM <notify(a)aur.archlinux.org> wrote: > impulse [1] filed a deletion request for icecat [2]: > > SERIOUS SECURITY WARNING: > The version is fixed at 115.18.0, As of (June 4th 2025), > upstream(IceCat) is 115.24.0, which is still very outdated, as firefox > is 128. > > The fact this package is still being used, as indicated by votes is > also concerning, if this package gets deleted or updated, at least it > helps prevent people from installing it, or in case of being updated > (if the author decides to), then we can continue, but web browsers > should not be this outdated, its months or even mere weeks before a > serious CVE may apply. > > I wouldn't count on people using LibreJS correctly either, so > Javascript is still a vector for this browser. > > [1] https://aur.archlinux.org/account/impulse/ > [2] https://aur.archlinux.org/pkgbase/icecat/

6 months, 2 weeks

Re: [PRQ#43656] Deletion Request for electron25-bin

by Marcell Meszaros

That was not the same request, per se. But regardless, I don't think it's useful for users to have AUR bin packages for things that already exist in repo. Maybe if it's an '-arm-bin' package, for ARM/ARM64 architectures, that's okay. Also, this electron-25-bin was still at an alpha version right before the deletion request got submitted, even though the stable version has been out for more than 35 days. AUR submission guidelines say that the carried packages have to be useful for some amount of people, not just 1-2. Seems no one noticed that this is outdated until today. Which suggests no users. And also I would say leaving packages outdated in the AUR when the same package is available in a newer version in repo is even detrimental to users. So I would vote for deleting this, and support the creation of maybe an 'electron25-arm-bin' package or similar. Just my 2 cents. Cheers, Marcell (MarsSeed) On 5 July 2023 17:23:38 GMT+02:00, Yurii Kolesnykov <root(a)yurikoles.com> wrote: >The very same request [0] was filed 14 releases ago. > >[0] https://lists.archlinux.org/archives/list/aur-requests@lists.archlinux.org/… > >> 5 лип. 2023 р. о 17:26 notify(a)aur.archlinux.org написав(ла): >> >> samsapti [1] filed a deletion request for electron25-bin [2]: >> >> electron25 is provided by official repo `extra`. >> >> [1] https://aur.archlinux.org/account/samsapti/ >> [2] https://aur.archlinux.org/pkgbase/electron25-bin/ > >

2 years, 5 months

Re: [PRQ#57938] Deletion Request for ocamlnet

by Marcell Meszaros

On 17 March 2024 14:30:01 GMT+01:00, notify(a)aur.archlinux.org wrote: >MarsSeed [1] filed a deletion request for ocamlnet [2]: > >Broken for close to 1 year due to not being compatible with repo's >ocaml 5, first published in May 2023. > >Upstream seems to be abandoned (developer only attends to their other >projects). > >There has been a work-in-progress, partially viable port to ocaml 5, >contributed to upstream in the form of a merge request 1.5 years ago, >but it has been abandoned and ignored since. [a] > >That unfinished patch does not make this buildable. Also, now the code >does not support the current gnutls, needed for https support in this >library. > >Downstream dependents have either moved on to other solutions, or got >discontinued 3+ years ago. (All AUR reverse dependencies have been >submitted for deletion.) > >I think it's best to delete this package. > >[a]: https://gitlab.com/gerdstolpmann/lib- >ocamlnet3/-/merge_requests/21 > >[1] https://aur.archlinux.org/account/MarsSeed/ >[2] https://aur.archlinux.org/pkgbase/ocamlnet/ The last package change is ill-conceived. The build stays broken. A package cannot depend on both 'ocaml' (v5) and 'ocaml4', as they conflict with each other. Still not useful to keep this library that is EOL for 3+ years.

1 year, 8 months

[PRQ#44271] Deletion Request for poppler-lcd

by notify＠aur.archlinux.org

MarsSeed [1] filed a deletion request for poppler-lcd [2]: Orphan. Modded variant of repo package poppler from 2 years ago. The custom patches for LCD subixel rendering have been abandoned since 2021. This feature would be of marginal usefulness in this day and age, since even 'just' FullHD (1080p) screens have enough pixel density that properly pixel-hinted (but not subpixel-hinted) font rendering can create crisp-looking text. Subpixel rendering is also tricky, because there is a myriad variety of LCD subpixel arrangements, and the algorithm should be prepared to support the actual one that the users's screen has, and it has to be configurable, otherwise the whole endeavor makes no sense and just worsens the rendered output. Though Qt5/6 poppler renders in worse quality than the base poppler package with gtk/cairo backend, that has nothing to do with subpixel rendering, and more to do with poppler maintainer's unwillingness to support cairo backend for poppler-qt for somewhat questionable reasons (fear of bugs, but he is hostile to anyone else willing to help out with contributing to and improving the Qt code for cairo). [1] https://aur.archlinux.org/account/MarsSeed/ [2] https://aur.archlinux.org/pkgbase/poppler-lcd/

2 years, 5 months

Re: [PRQ#45142] Deletion Request for quick-n-easy-web-builder-10-bin

by Marcell Mészáros

Though package owner has fixed the issues, this package is superfluous. As maintainer's other AUR package, quick-n-easy-web-builder-10, is also created from a precompiled release. And as per AUR guidelines, -bin suffix is not needed for this application, as it seems no source code is available publicly. On 20 July 2023 20:43:11 GMT+02:00, Marcell Meszaros <marcell.meszaros(a)runbox.eu> wrote: >What's more, this AUR repo contains a hidden, undeclared precompiled binary pacman pkg.tar.zst file. > >Hosting this on AUR is explicitly forbidden by the AUR submission guidelines: [a] > ># The AUR should not contain the binary tarball created by makepkg, nor should it contain the filelist. > >[a]: https://wiki.archlinux.org/title/AUR_submission_guidelines > >On 20 July 2023 20:27:49 GMT+02:00, notify(a)aur.archlinux.org wrote: >>a821 [1] filed a deletion request for quick-n-easy-web-builder-10-bin >>[2]: >> >>The PKGBUILD does nothing except displaying a message. Not sure if >>this is actually spam. >> >>[1] https://aur.archlinux.org/account/a821/ >>[2] https://aur.archlinux.org/pkgbase/quick-n-easy-web-builder-10-bin/

2 years, 4 months

Re: [PRQ#46488] Deletion Request for python-nipype

by Liam Timms

Run it without testing. Tests are on by default to allow the user to see areas that might cause issues since it interacts with many different programs during the testing process. It has been building within the last two years but requires the user to inspect any failing tests before deciding whether or not to install anyway. The difference is that the conda and pip installations do not necessarily warn the user if some tests fail. I am waiting for the next release to include the commits which fix the current incompatibility issues with python 3.11 and the recent numpy depreciation of distutils. On Sat, Aug 19, 2023 at 9:45 PM <notify(a)aur.archlinux.org> wrote: > MarsSeed [1] filed a deletion request for python-nipype [2]: > > This package has been broken for 2+ years, and maintainer does not > seem able and willing enough to work on the issues pertaining to this > build and many of its dependencies. > > Better to delete this, otherwise quite complicated package, and let > users install it from PyPI with pip. > > [1] https://aur.archlinux.org/account/MarsSeed/ > [2] https://aur.archlinux.org/pkgbase/python-nipype/

2 years, 3 months

Re: [PRQ#78378] Deletion Request for paru-patch

by mia＠mia.jetzt

> yochananmarqos [1] filed a deletion request for paru-patch [2]: > > Please do not submit duplicate packages. The upstream developer is > also the Maintainer of paru. Have you contacted them? > > [1] https://aur.archlinux.org/account/yochananmarqos/ > [2] https://aur.archlinux.org/pkgbase/paru-patch/ This is a package to fix an active issue with paru. The same changes were submitted upstream three days ago [1] and the issue was noticed in arch testing and reported upstream two weeks ago [2]. Maintainer has shown no recent activity (maybe on vacation for holidays?), so this package lets people still use paru for the time being. Since AUR components can be critical system components, an AUR helper is also a critical component, and without this patch it does not build or run on up-to-date Arch Linux installations. Deleting after upstream fixes this issue would make sense, but for now this package is required. I can update the package description if that makes things easier, I understand that it's pretty unclear at the moment. [1] https://github.com/Morganamilo/paru/pull/1458 and https://github.com/Morganamilo/paru/pull/1461 and https://github.com/Morganamilo/aur-depends/pull/19 [2] https://github.com/Morganamilo/paru/issues/1454

3 days, 12 hours

Re: [PRQ#46561] Deletion Request for librsvg-og

by Marcell Meszaros

Minor correction: the i586 microarchitecture is not the same as the one referred to as 'pentium4' by compilers like the gcc. But this error on my part has no bearing on the request to delete this package whose newer equivalent is available in ArchLinux32 repos. On 22 August 2023 08:15:00 GMT+02:00, notify(a)aur.archlinux.org wrote: >MarsSeed [1] filed a deletion request for librsvg-og [2]: > >This is an ArchLinux32 package from 2021-05: > >arch=(i486 i686 pentium4) > >Not needed: same owner maintains this package for those architectures >directly in ArchLinux32.org repos, where it is already on a newer git >version (last updated on 2022-07-23). > >Also in ArchLinux32, there is a working rust compiler for i686 and >pentium4 (i586) platforms, so the repo for those also carries the >current main librsvg 2.56.x which needs rustc. > >As stated by librsvg-og fork repo (last updated in 2020): >"The goal of this fork is to keep the C implementation alive and up to >date, to help provide librsvg for platforms without a working rust >compiler." [a] > >[a]: https://github.com/oaken-source/librsvg-og > >[1] https://aur.archlinux.org/account/MarsSeed/ >[2] https://aur.archlinux.org/pkgbase/librsvg-og/

2 years, 3 months

Re: [aur-requests] [PRQ#10977] Deletion Request for arc-gtk-theme-git

by Eli Schwartz

On 03/24/2018 09:20 PM, Stelios Tsampas via aur-requests wrote: > On Sun, Mar 25, 2018 at 4:10 AM, notify--- via aur-requests > <aur-requests(a)archlinux.org <mailto:aur-requests@archlinux.org>> wrote: > > Eschwartz [1] filed a deletion request for arc-gtk-theme-git [2]: > > duplicate of gtk-theme-arc-git > > [1] https://aur.archlinux.org/account/Eschwartz/ > <https://aur.archlinux.org/account/Eschwartz/> > [2] https://aur.archlinux.org/pkgbase/arc-gtk-theme-git/ > <https://aur.archlinux.org/pkgbase/arc-gtk-theme-git/> > > > gtk-theme-arc-git should be deleted, arc-gtk-theme-git follows the > naming of the package in community 1) I dislike the naming schema NicoHood used in [community] and IMHO he should change it. It strikes me as terribly unintuitive. 2) The naming schema of the package in community is irrelevant, as this is not the package in community and you are not allowed to submit duplicate packages to the AUR and then attempt to browbeat the maintainer of the original package into giving up his package. If you would like to politely *request* that he rename his package, and agree to respect his choice, then I will respect his decision (which does imply that it is his decision). ... It may be my personal opinion that things should be gtk-theme-foo and that foo-gtk-theme is "wrong", but I'm not going to enforce my opinion on others as it is sort of a bikeshed. I will pretty aggressively enforce my disapproval of the cavalier attitude taken in uploading and re-uploading arc-gtk-theme-git. There were duplicate packages. The older package takes precedence. The newer package is very firmly a duplicate, and should not continue to be re-uploaded in contravention of its initial deletion. That just smacks of disrespecting the administrative decisions that have *already been declared*. ... I'm rather pissed off, and tremendously so, that someone pressured him into orphaning his package. I'm also deeply confused, what on earth is even going on here? The new maintainer then proceeded to abuse his new maintenance of gtk-theme-arc-git by breaking the pkgver and using some terrible abomination, then hiding this in amongst a bunch of trivial style changes. This does not impress me with his *capabilities* as an AUR maintainer, so why should I trust his opinions on the naming any more? -- Eli Schwartz Bug Wrangler and Trusted User

7 years, 8 months

Re: [PRQ#59573] Deletion Request for yandex-music

by Marcell Meszaros

On 25 April 2024 21:34:29 GMT+02:00, notify(a)aur.archlinux.org wrote: >qubeck [1] filed a deletion request for yandex-music [2]: > >According to clause 4.3 of the Yandex Music License Agreement, it's >prohibited to distribute modified versions of software without written >permission of the owner. The upstream repository states it's a >"Repacked Electron client of Yandex Music for Linux", implying it's >modified. >Since neither the package repository nor the upstream doesn't contain >any it must be removed. > >License agreement (in English): >https://yandex.ru/legal/music_mobile_agreement/?lang=en > >PS. License Agreement says it's for the "mobile version", but Yandex >Music for Windows/Mac OS has the same license. You can find it at the >bottom of the download page (https://music.yandex.ru/download/) > >[1] https://aur.archlinux.org/account/qubeck/ >[2] https://aur.archlinux.org/pkgbase/yandex-music/ @qubeck, please don't file these kinds of requests. This AUR package does not violate the stipulated provision. AUR does not host the Yandex application itself, it just offers an installation recipe and metadata. Essentially it is analogous to hosting a web URL and letting any user choose to feed that URL into a web browser for processing.

1 year, 7 months

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