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

Re: [aur-requests] [PRQ#33096] Deletion Request for whatismyip

by Brett Cornwall

On 2022-03-12 03:41, Christopher Snowhill (kode54) via aur-requests wrote: > > >> On Mar 9, 2022, at 1:42 AM, notify--- via aur-requests <aur-requests(a)lists.archlinux.org> wrote: >> >> kleintux [1] filed a deletion request for whatismyip [2]: >> >> Script is hosted in aur git. no description / upstream url. uses 3th >> party service to get the external ip. >> >> [1] https://aur.archlinux.org/account/kleintux/ >> [2] https://aur.archlinux.org/pkgbase/whatismyip/ > >This has to use an external service, since its purpose is querying your external facing IP address, even if you're behind a NAT. They could have used ifconfig.me <http://ifconfig.me/> instead, though, since that's another service. Depends on whether they trust the permanence of the owner of that domain, versus the permanence of Amazon Web Services running their own IP query service. > >I do agree, however, that it may be required to host this tiny script on a Github repository or a Gist on Github, rather than using the AUR to host it. Even if it is under 1 KiB. It's so trivial and essentially a custom user script (since it includes cowsay) that I'd say it doesn't belong at all. Deleted.

3 years, 9 months

Re: [PRQ#49231] Merge Request for spflashtool5-bin

by Omar Pakker

Hi dakataca, I also left (part of) this message on the package, just in case you aren't on the mailing list or something. Why exactly was this request created? I don't see a case where these should be merged to be honest. The spflahtool5 [3] package was created way after spflashtol5-bin [2] and I'm unable to see why. The more logical thing seems to be a deletion of spflashtool5 [3] as a duplicate. If you're providing a variant with different options, they shouldn't be merged either; in that case, update it to clearly reflect what the differences are. If you have any suggestions or improvements for spflashtool5-bin [2], feel free to leave a comment there or send me a message. Kind regards, Omar On do, okt 19 2023 at 16:41:35 +00:00:00, notify(a)aur.archlinux.org wrote: > dakataca [1] filed a request to merge spflashtool5-bin [2] into > spflashtool5 [3]: > > It would be a good idea to combine the best of both PKGBUILDs, and the > same version of spflashtool. > > [1] <https://aur.archlinux.org/account/dakataca/> > [2] <https://aur.archlinux.org/pkgbase/spflashtool5-bin/> > [3] <https://aur.archlinux.org/pkgbase/spflashtool5/>

2 years, 2 months

Re: [PRQ#48150] Deletion Request for gcr-git

by Marcell Meszaros

Also this package builds the gcr-4 source but depends on gtk3 instead of the needed gtk4, like extra/gcr-4 does. On 29 September 2023 17:54:45 GMT+02:00, notify(a)aur.archlinux.org wrote: >MarsSeed [1] filed a deletion request for gcr-git [2]: > >Extra/gcr is kept on v3.x, and there is an extra/gcr-4 that tracks the >latest version of this library. > >Therefore this VCS package wrongly states it provides 'gcr', which on >Arch means gcr v3, so it is not true. > >The problem has been pointed out by @arenm in a comment on 2022-10-18, >but hasn't been addressed since. > >Upstream's legacy 'gcr-3-41' branch for the last gcr v3 is not >developed since Jan 2022. [a] > >So it's best to delete this PKGBUILD at this point. > >If a VCS build that tracks the master branch is needed, a new package >should be resubmitted for it as gcr-4-git, to align properly with >extra repo. > >[a]: https://gitlab.gnome.org/GNOME/gcr/-/commits/gcr-3-41/ > >[1] https://aur.archlinux.org/account/MarsSeed/ >[2] https://aur.archlinux.org/pkgbase/gcr-git/

2 years, 2 months

[aur-requests] [PRQ#12915] Deletion Request for drozer

by notify＠aur.archlinux.org

edoz90 [1] filed a deletion request for drozer [2]: # Maintainer: Daniel Lawson <daniel dot lawson at mwrinfosecurity dot com> pkgname=drozer pkgver=2.4.4 pkgrel=1 pkgdesc='Comprehensive security and attack framework for Android' arch=('i686' 'x86_64') url='https://labs.mwrinfosecurity.com/tools/drozer/' license=('bsd') options=('!emptydirs' '!strip') provides=('drozer') depends=( 'bash' 'python2' 'python2-protobuf' 'python2-pyopenssl' 'python2-twisted') source_x86_64=("https://github.com/mwrlabs/drozer/releases/download/2.4.4/drozer_2.4.4.deb") source_i686=("https://github.com/mwrlabs/drozer/releases/download/2.4.4/drozer_2.4.4.deb") md5sums_i686=('fef0802db020d91eb33a8326da89dee9') md5sums_x86_64=('fef0802db020d91eb33a8326da89dee9') prepare() { # Extract out data file \tar xvf data.tar.xz } package() { # Bash completions get installed to a different location on Arch mkdir -p "${pkgdir}"/usr/share/bash-completion/completions/ cp -dr --no-preserve=ownership etc/bash_completion.d/drozer "${pkgdir}"/usr/share/bash-completion/completions/ # Arch uses python3 by default, so we have to explicitly call python2 find . -type f -print0 | xargs -0 sed -i 's/\#\!\/usr\/bin\/python/\#\!\/usr\/bin\/python2/' # Install rest of files cp -dr --no-preserve=ownership usr/{bin,share} "${pkgdir}"/usr/ mkdir -p "${pkgdir}"/usr/lib/python2.7/ cp -dr --no-preserve=ownership usr/lib/python2.7/dist- packages/{drozer,mwr,pydiesel} "${pkgdir}"/usr/lib/python2.7/ } [1] https://aur.archlinux.org/account/edoz90/ [2] https://aur.archlinux.org/pkgbase/drozer/

7 years, 2 months

Re: [PRQ#75813] Deletion Request for rofi-dmenu

by Chris Werner Rau

Hello, That is a workaround for direct installations, but I would also have to use this flag every time I manually touch that package (like with a reinstall) and even every time I run `pacman -Syu`! Furthermore, if dmenu is pulled transitively for a random package you want to try, you have to provide that flag every time for that as well. So basically I'd have to set `--assume-installed=dmenu` *every* *single* *time* I do anything with pacman to be sure nothing breaks. And in my opinion, "you can do this manually" is not really a good argument. One could argue that every package could be removed, as you could do it manually instead. Lastly, I don't really see what rule this package breaks. I can only imagine "usefulness", but as I said, it does provide usefulness to at least me and actually a couple of friends I know. On Fri, 5 Sept 2025 at 11:56, Robin Candau <antiz(a)archlinux.org> wrote: > On 9/3/25 10:18 AM, Chris Werner Rau wrote: > > Hello, > > > > I myself find it extremely useful as this package satisfies the `dmenu` > > dependency of other packages, the ones I'm using are clipmenu, rofi- > > randr and udiskie-dmenu-git. Without this package I would have to > > install the dmenu package without needing/using it. > > > > On Wed, 3 Sept 2025 at 09:44, <notify(a)aur.archlinux.org > > <mailto:notify@aur.archlinux.org>> wrote: > > > > oech3 [1] filed a deletion request for rofi-dmenu [2]: > > > > Not useful. Symlink to /usr/local/bin/ > > > > [1] https://aur.archlinux.org/account/oech3/ <https:// > > aur.archlinux.org/account/oech3/> > > [2] https://aur.archlinux.org/pkgbase/rofi-dmenu/ <https:// > > aur.archlinux.org/pkgbase/rofi-dmenu/> > > > > Hi, > > This doesn't require a package, you can handle this via the > `--assume-installed` pacman flag. > > -- > Regards, > Robin Candau / Antiz >

3 months, 2 weeks

[aur-requests] [PRQ#36400] Deletion Request for style50

by notify＠aur.archlinux.org

MayorBender [1] filed a deletion request for style50 [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/style50/ This package was not originally hosted in pip when this pkgbuild was first submitted. The second is that its dependencies conflict with what's provided by Arch repos. For example, it depends on lib50, which 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 user would have to install lib50 with pip anyways. At that point, the user should install this package with pip rather than through the AUR. Note: I 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/style50/

3 years, 5 months

[PRQ#49560] Deletion Request for git-fc

by notify＠aur.archlinux.org

MarsSeed [1] filed a deletion request for git-fc [2]: Hostile, personal fork of git, which resets the versioning and is at v0.1 right now. It is also 1812 commits behind upstream git as of this day. It means this is not a feature-equivalent drop-in for repo's git package, nor for AUR/git-git. The pkgdesc is bogus ("Fork of Junio's git for users"). (Junio C Hamano is upstream Git's chief maintainer/developer since 2005. It is misleading to use his name in the pkgdesc, as this has nothing to do with him, nor with his personal GitHub fork of git, published for technical purposes, not for main development.) Purportedly, this fork only wants to add a new convenience subcommand, 'git stage'. There are upstream-friendly ways of doing that without forking. Many third-party git addons have been created that work with upstream git and expose new, custom git subcommands. There are no AUR comments and this has only 1 vote. AUR packages have to be useful to more than a few users. This particular one does not qualify. Best to delete. [a]: https://github.com/felipec/git/ [1] https://aur.archlinux.org/account/MarsSeed/ [2] https://aur.archlinux.org/pkgbase/git-fc/

2 years, 1 month

Re: [PRQ#45664] Deletion Request for python2-pyo

by Marcell Meszaros

Hi Mathieu, Thank you for your response. Only an AUR Trusted User or Developer user can delete packages here, so there's nothing for you to do apart from what you already did by responding that you agree to the deletion. Cheers, Marcell On 31 July 2023 14:41:30 GMT+02:00, Matthieu Amiguet <contact(a)matthieuamiguet.ch> wrote: >I'm the maintainer of the package. It's true that I did not maintain this package properly lately. Also, maintaining such a package for python2 makes less and less sense. >I agree to delete it, only I'm not sure how I'm supposed to do this... > >Cheers, > >Matthieu > >Le 31.07.23 à 14:26, notify(a)aur.archlinux.org a écrit : >> MarsSeed [1] filed a deletion request for python2-pyo [2]: >> >> Nothing depends on this Python2 module from 2018, and it's broken >> because its wxpython dependency fails to build. >> >> Also this package wrongly states it provides 'python-pyo', which it >> does not. There exists a separate package on AUR for the Python3 >> variant. >> >> Safe to delete this defunct one. >> >> [1] https://aur.archlinux.org/account/MarsSeed/ >> [2] https://aur.archlinux.org/pkgbase/python2-pyo/

2 years, 4 months

Re: [aur-requests] [PRQ#2128] Deletion Request for sigrok-cli-git

by Thomas Krug

On 01/28/2015 01:02 AM, Doug Newgard wrote: > On Tue, 27 Jan 2015 23:46:32 +0000 (UTC) > notify(a)aur.archlinux.org wrote: > >> phragment [1] filed a deletion request for sigrok-cli-git [2]: >> >> I'd like to remove sigrok git packages, since the development is to >> fast to keep providing useful pkgbuilds. >> >> [1] https://aur.archlinux.org/account/phragment/ >> [2] https://aur.archlinux.org/pkgbase/sigrok-cli-git/ > > This makes little sense. How is development too fast when you haven't > uploaded a new PKGBUILD in over 2 months? The PKGBUILD is pretty > simple, too, I don't see a ton of stuff that would need changed all of > the time... > Since git head sees a lot of developmen people kept emailing me, that the packages won't build or worse, they do build and just do not work or crash. Typical approach is to remove all five packages and build from the ground up. Dependencies between their libraries change often. Besides this the devs already contacted me, that people also keep bugging them. Of course people should know better and I can just disown the package. Greetings, Thomas

10 years, 10 months

Re: [aur-requests] [PRQ#22119] Deletion Request for visual-studio-code-insiders

by Duru Can Celasun

I wish this came in as a comment first and not a deletion request. To address the complaint: > pkgver uses external resources (curls vendor website) The version of the insiders build changes dozens of times a day as it's automated upstream. I don't see anything in AUR guidelines against pkgver using external resources, but I'm open to suggestions here. > possibly confusion around sources and pkgver No idea what this means. > missing -bin suffix for a binary package Omitting the suffix is common and popular practice on AUR [1][2][3][4][5][6] when the source code is not available. Visual Studio Code is a closed source, proprietary product. So I'm not sure a rename is warranted here but I'd be happy to change it if a TU says so. [1] https://aur.archlinux.org/packages/dropbox/ [2] https://aur.archlinux.org/packages/spotify/ [3] https://aur.archlinux.org/packages/google-chrome/ [4] https://aur.archlinux.org/packages/teamviewer/ [5] https://aur.archlinux.org/packages/jdk/ [6] https://aur.archlinux.org/packages/google-earth-pro/ On Tue, 3 Nov 2020, at 12:29, notify(a)aur.archlinux.org wrote: > daurnimator [1] filed a deletion request for visual-studio-code- > insiders [2]: > > Does not follow PKGBUILD guidelines > - pkgver uses external resources (curls vendor website) > - possibly confusion around sources and pkgver > - missing -bin suffix for a binary package > > [1] https://aur.archlinux.org/account/daurnimator/ > [2] https://aur.archlinux.org/pkgbase/visual-studio-code-insiders/

5 years, 1 month

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