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

Re: [PRQ#60466] Deletion Request for gnome-shell-extension-rounded-window-corners-reborn

by Grzegorz Kozub

Hi there! I maintain both AUR packages based on https://github.com/flexagoon/rounded-window-corners. The git one builds on your PC and the other uses the pre-build package provided by the extension author. I prefer the pre-build one. Let's not remove it but rather fix the issues you've come across. Can you help fixing the pkgver=12.61c326e, please? I wanted it to reflect the git commit the pre-build was made from. https://aur.archlinux.org/packages/gnome-shell-extension-rounded-window-cor… https://aur.archlinux.org/packages/gnome-shell-extension-rounded-window-cor… -- greg On Thu, May 23, 2024 at 9:08 PM <notify(a)aur.archlinux.org> wrote: > yochananmarqos [1] filed a deletion request for gnome-shell-extension- > rounded-window-corners-reborn [2]: > > There is no release and the Maintainer is inventing an erroneous > pkgver. We already have a properly maintained VCS package: gnome- > shell-extension-rounded-window-corners-reborn-git > > [1] https://aur.archlinux.org/account/yochananmarqos/ > [2] > https://aur.archlinux.org/pkgbase/gnome-shell-extension-rounded-window-corn…

1 year, 6 months

Re: [PRQ#51905] Deletion Request for polify

by Marcell Meszaros

> Looks like this software is abandoned by upstream @WilfredNicdock, a simple Bash script (@budRich's polify) does not need constant updates. This is no reason to delete a package. > Conflict with my local package > https://github.com/BillotP/polify This has nothing to do with AUR/polify. You can, however, submit your PKGBUILD with any other name for BillotP/polify, e.g. polify-music or polify-music-streaming etc. Just ensure that the Amazon S3 bucket is configurable by user during (or before) runtime, and with non-root privileges, instead of baking in predetermined Amazon S3 bucket access credentials at build-time. Until that feature is implemented in BillotP/polify, it is not ready for packaging for users, so in that case it does not belong to the AUR. On 1 December 2023 20:12:15 GMT+01:00, notify(a)aur.archlinux.org wrote: >WilfredNicdock [1] filed a deletion request for polify [2]: > >Looks like this software is abandoned by upstream. >Conflict with my local package https://github.com/BillotP/polify >wonder if someone could do smthing about it :) > >[1] https://aur.archlinux.org/account/WilfredNicdock/ >[2] https://aur.archlinux.org/pkgbase/polify/

2 years

[PRQ#74850] Deletion Request for illogical-impulse-pymyc-aur

by AlphaLynx

On Saturday, July 26, 2025 2:41:20 AM Eastern Daylight Time you wrote: > Have you ever heard of a metapackage? This is the only way it works on > certain arch derivatives. Please take your deletion requests away > > > On Fri, Jul 25, 2025, 11:36 PM <notify(a)aur.archlinux.org> wrote: > > AlphaLynx [1] filed a deletion request for illogical-impulse-pymyc-aur > [2]: > > The PKGBUILD [0] doesn't do anything. > > [0] https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=illogical-> impulse-pymyc-aur > > [1] https://aur.archlinux.org/account/AlphaLynx/ > [2] https://aur.archlinux.org/pkgbase/illogical-impulse-pymyc-aur/ Of course I have heard of a meta package, but I struggle to see how these metapackages are useful and how they can't just be dependecies of a illogical- impulse package (which doesn't exist?). Secondly, packages must be useful on Arch Linux (see [1] and my comment [2]), not derivatives or other distributions. Meta packages like `base` and `base- devel` serve a great purpose [3], but how are these meta packages useful on Arch Linux specifically? [1] https://lists.archlinux.org/archives/list/aur-general@lists.archlinux.org/ message/GMYC74CRSFH7GGNENEUOODZUPWHOMX7A/ [2] https://aur.archlinux.org/packages/zen-browser-compat-bin#comment-1033760 [3] https://lists.archlinux.org/archives/list/arch-dev-public@lists.archlinux.o…

4 months, 3 weeks

[aur-requests] [PRQ#20889] Orphan Request for virtualbox-bin-5

by notify＠aur.archlinux.org

drankinatty [1] filed an orphan request for virtualbox-bin-5 [2]: Oracle ended support for the Virtualbox 5.2 branch at the end of July 2020. As of Linux 5.8 the kernel modules will no longer build -- but the package continues to work just fine for LTS and will for the foreseeable future so long as the LTS is <= 5.7 so there isn't an immediate deletion need. I request to disown this package as there will be no future changes to the package or new releases of the 5.2 branch beyond 5.2.44 by Oracle. [1] https://aur.archlinux.org/account/drankinatty/ [2] https://aur.archlinux.org/pkgbase/virtualbox-bin-5/

5 years, 3 months

[aur-requests] [PRQ#31414] Deletion Request for libx32-glibc

by notify＠aur.archlinux.org

MarsSeed [1] filed a deletion request for libx32-glibc [2]: Note: This deletion request is intended not for 1 but 64 AUR packages: https://aur.archlinux.org/packages/?O=0&SeB=n&K=libx32&outdated=&SB=l&SO=d&… Reasons outlined below are true for all linked packages: • Package naming violates Arch guidelines*. Name should en d with '-x32', not start with 'libx32-'. The name will only confuse users, and the built executables won't work with any Arch/Arch-downstream distro kernels from binary repos. (*ref: https://wiki.archlinux.org/title/32-bit_package_guidelines#Package_naming ) • Packages have not been updated in 6 years or more. • All erroneously named libx32- packages were uploaded by one user, fantix. He seems to have maintained Arch x32 PKGBUILD repos* separate from AUR, but have stopped updating them as well in 2016. * https://github.com/orgs/ArchLinux-x32/repositories • Virtually no one uses x32 ABI software, which needs to run on x86_64 CPU but with a special build of the Linux kernel* that enables the usage of the x32 ABI. (E.g.: https://aur.archlinux.org/packages/linux-x32/ ) • Whoever wants to use such a niche architecture will not in their right mind want to build it from 6-year old unmaintained build scripts from the AUR. They would use Debian x32 or build Gentoo from scratch for the x32 ABI. [1] https://aur.archlinux.org/account/MarsSeed/ [2] https://aur.archlinux.org/pkgbase/libx32-glibc/

3 years, 11 months

Re: [PRQ#54226] Deletion Request for ly-git-openrc

by Robin Candau

On 2/27/24 16:38, jahway603 wrote: > THIS SHOULD NOT BE DELETED as the AUR is used by Arch and ALL derivatives of Arch, like Artix, Manjaro, EndeavourOS, etc. The AUR has been made by Arch Linux for Arch Linux. Derivatives are **not** supported and packages made specifically for such distros are not allowed. So, regardless of the below request and whether it will lead to a deletion of the package or not, the above argument is not relevant. > > On Monday, February 26th, 2024 at 2:11 PM, notify(a)aur.archlinux.org <notify(a)aur.archlinux.org> wrote: > >> MarsSeed [1] filed a deletion request for ly-git-openrc [2]: >> >> Problematic, but unneeded VCS package with wrong name, missing >> provides field and pkgver() function. >> >> The stable ly package is carried by extra repo, and there is a proper >> ly-git on AUR. >> >> This package was intended for a systemd-less Arch derivative, and is >> not useful on Arch Linux, due to the fact that it is virtually >> impossible nowadays to run Arch without systemd (hence the other >> distros). >> >> [1] https://aur.archlinux.org/account/MarsSeed/ >> [2] https://aur.archlinux.org/pkgbase/ly-git-openrc/ -- Regards, Robin Candau / Antiz

1 year, 9 months

Re: [aur-requests] [PRQ#7460] Deletion Request for pdf.js

by Florian Bruhin

* Bruno Pagani <bruno.n.pagani(a)gmail.com> [2017-02-14 16:59:10 +0100]: > Le 08/02/2017 à 22:16, notify(a)aur.archlinux.org a écrit : > > > The-Compiler [1] filed a deletion request for pdf.js [2]: > > > > Duplicate of pdfjs (without dot) which was first submitted 10 months > > earlier (and has packages optdepending on it) > > > > [1] https://aur.archlinux.org/account/The-Compiler/ > > [2] https://aur.archlinux.org/pkgbase/pdf.js/ > > Indeed, but pdf.js seems like a more correct package name in fact. Could > you agree on the maintainership of it, and file a merge request of pdfjs > to pdf.js instead? I'd be fine either way, but [1] says: For the sake of consistency, pkgname should match the name of the source tarball of the software: for instance, if the software is in foobar-2.5.tar.gz, use pkgname=foobar. And the name used in their release tarballs[2] is "pdfjs". [1] https://wiki.archlinux.org/index.php/PKGBUILD [2] https://github.com/mozilla/pdf.js/releases/download/v1.7.225/pdfjs-1.7.225-… Florian -- http://www.the-compiler.org | me(a)the-compiler.org (Mail/XMPP) GPG: 916E B0C8 FD55 A072 | http://the-compiler.org/pubkey.asc I love long mails! | http://email.is-not-s.ms/

8 years, 10 months

[PRQ#59772] Deletion Request for widevine

by notify＠aur.archlinux.org

MarsSeed [1] filed a deletion request for widevine [2]: Re-filing a deletion request due to not receiving any response [a] as to the rationale to keep this duplicate of the properly packaged AUR/chromium-widevine. [b] The AUR/widevine package was created with the sole purpose of offering ARM support, and x86_64 was only added to mask its intent. Also I believe it is not okay to create duplicates on AUR when there is already a maintained package which works with Arch Linux. AUR/widevine's maintainer should collaborate with that of AUR/chromium-widevine and suggest enhancements there, if there are relevant ones. In addition, AUR/widevine has other problems. As its used release deliverables for different platforms diverge in their version: - AUR/widevine pkgver: 4.10.2252.0 - x86_64: upstream - 4.10.2710.0 (released 2024-02-12) - aarch64/armhf: RaspberryPi.org/Debian - 4.10.2252.0 (released 2023-10-05) - (AUR/chromium-widevine pkgver: 4.10.2710.0, released 2024-02-12) As the RPI distro does not carry the latest version, it seems not to be viable to carry binaries for different architectures in the same PKGBUILD. Which leads me to conclude that a PKGBUILD for the RPI releases should be submitted to the ArchLinuxARM.org repositories only. That would actually benefit users more, while not cluttering the AUR. [a]: https://lists.archlinux.org/archives/list/aur- requests@lists.archlinux.org/thread/IAHLWRGRNHHUZRU2LRMX5UTZUNGJBAUO/#5CT5XAQZNIHQYPSRZ6CMDTY67XE3QOU2 [b]: https://aur.archlinux.org/packages/chromium-widevine [1] https://aur.archlinux.org/account/MarsSeed/ [2] https://aur.archlinux.org/pkgbase/widevine/

1 year, 7 months

[PRQ#53365] Deletion Request for python2-backports.shutil_get_terminal_size

by notify＠aur.archlinux.org

MarsSeed [1] filed a deletion request for python2-backports.shutil_get_terminal_size [2]: This has already been deleted twice in response to: - PRQ#30859 (2021-12-18) [a] - PRQ#48185 (2023-09-29) [b] Now it got recreated dead-on-arrival, failing the integrity check. This is very typical with submitter Pellegrino Prevete's packages (who is both @tallero and @truocolo) He is prone to pushing broken commits to AUR repos. Reverse dependency ipython2 has been dead on AUR since 2021, and already got deleted once: - PRQ#31463 (2022-01-12) [c] It does not make sense to keep either packages, as no user commented throughout the AUR existence of either, apart from him and me in the last few days. As per AUR submission guidelines, packages kept here should be in demand by more than a few users. These broken builds clearly don't hit that particular bar. [a]: http://tinyurl.com/aurPRQ30859 / Full URL: https://lists.archlinux.org/hyperkitty/list/aur- requests(a)lists.archlinux.org/thread/S236DZWKIDSSC23J7KHMVVCFBZ2D6FQB [b]: http://tinyurl.com/aurPRQ48185 / Full URL: https://lists.archlinux.org/hyperkitty/list/aur- requests(a)lists.archlinux.org/thread/MO53FSYNYBSYBDUXENSO4IGWA5A7JK33 [c]: http://tinyurl.com/aurPRQ31463 / Full URL: https://lists.archlinux.org/hyperkitty/list/aur- requests(a)lists.archlinux.org/thread/DQCDU4ENTVC6HDQAV5YVCY6ZSDUZO3QR [1] https://aur.archlinux.org/account/MarsSeed/ [2] https://aur.archlinux.org/pkgbase/python2-backports.shutil_get_terminal_siz…

1 year, 10 months

Re: [PRQ#39202] Deletion Request for radicle

by Adam Szkoda

Hi! I'm an official member of the Radicle project (I'm @adaszko on the project's official Discord: https://discord.gg/vhGXkazpNc) We maintain statically linked binaries so that end users do not experience build problems with the project, which we had many. We just today had someone come to Discord and complain the PKGBUILD is not building for them hence the conversion to binaries. We use the strategy of distribution statically linked binaries on macOS too and it's been very successful: the number of reported problems dropped significantly. The next release should also provide binaries for ARM64 for Linux and macOS (the scripts for building them are in place, but we're yet to have a release). I'm open for a chat on the #support channel at our Discord too. Wish you all the best — Adam On Thu, Dec 15, 2022 at 3:10 PM <notify(a)aur.archlinux.org> wrote: > Foxboron [1] filed a deletion request for radicle [2]: > > Duplicate package, and distributes a static binary when the source is > available. > > [1] https://aur.archlinux.org/account/Foxboron/ > [2] https://aur.archlinux.org/pkgbase/radicle/

3 years

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