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

[aur-requests] [PRQ#27836] Deletion Request for perl-text-findindent

by notify＠aur.archlinux.org

zoorat [1] filed a deletion request for perl-text-findindent [2]: normally trying to build ``` [builduser@d4373b4a58bc perl-text-findindent]$ makepkg ==> ERROR: provides contains invalid characters: '::' ``` after removing "'Text::FindIndent=0.10'" ``` [builduser@d4373b4a58bc perl-text-findindent]$ makepkg ==> Making package: perl-text-findindent 0.10-1 (Sun 29 Aug 2021 06:34:33 PM UTC) ==> Checking runtime dependencies... ==> Checking buildtime dependencies... ==> Retrieving sources... -> Downloading Text-FindIndent-0.10.tar.gz... % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 100 5 100 5 0 0 2 0 0:00:02 0:00:01 0:00:01 2 100 34541 100 34541 0 0 14897 0 0:00:02 0:00:02 --:--:-- 82436 ==> Validating source files with md5sums... Text-FindIndent-0.10.tar.gz ... Passed ==> Extracting sources... -> Extracting Text-FindIndent-0.10.tar.gz with bsdtar ==> Entering fakeroot environment... ==> Starting package()... Can't locate inc/Module/Install/DSL.pm in @INC (you may need to install the inc::Module::Install::DSL module) (@INC contains: /usr/lib/perl5/5.34/site_perl /usr/share/perl5/site_perl /usr/lib/perl5/5.34/vendor_perl /usr/share/perl5/vendor_perl /usr/lib/perl5/5.34/core_perl /usr/share/perl5/core_perl) at Makefile.PL line 1. BEGIN failed--compilation aborted at Makefile.PL line 1. ==> ERROR: A failure occurred in package(). Aborting... ``` Last Updated: 2015-06-10 08:15, Flagged out-of-date (2021-05-03). [1] https://aur.archlinux.org/account/zoorat/ [2] https://aur.archlinux.org/pkgbase/perl-text-findindent/

4 years, 3 months

[PRQ#52758] Deletion Request for revchatgpt-git

by notify＠aur.archlinux.org

MarsSeed [1] filed a deletion request for revchatgpt-git [2]: Discontinued, broken, GitHub repo archived since August 2023. [a] The bundled cli apps crash when executing them. Upstream's name, "ChatGPT", and the implementation itself infringes on OpenAI's trademarks as well as Terms of Service, because this was an unofficial, reverse-engineered client that resorted to hacks and obfuscation to gain unlicensed access to ChatGPT. Maybe that's why issue reports from June-August 2023 [b] indicate it is no longer usable with OpenAI's services: they say that the server asks for frequent CAPTCHA verifications, expires the access token every minute, and OpenAI's servers suspend access due to detecting "unusual activity". There are even Python crashes mentioned that are caused by failure to parse the CAPTCHA verification response. This library also relied on a Cloudflare human verification CAPTCHA evading proxy library. But apparently it no longer fools OpenAI's systems. Not useful to keep this package at all. There are working, maintained clients and integration libraries available in Arch and AUR repos that conform to OpenAI's Terms of Service. [a]: https://github.com/acheong08/ChatGPT [b]: https://github.com/acheong08/ChatGPT/issues [1] https://aur.archlinux.org/account/MarsSeed/ [2] https://aur.archlinux.org/pkgbase/revchatgpt-git/

1 year, 11 months

Re: [aur-requests] [PRQ#17157] Deletion Request for f5vpn

by Zach Hoffman

The package absolutely does not contain university-specific installation files. The reason the two linked files contain different hashes is that they are different versions. Steps to verify this: 1. Download both RPMs 2. Extractthe RPM 3. Open ${srcdir}/opt/f5/vpn/f5vpn in the editor of your choice 4. Search for the text Version: 5. Notice that it.emory.edu's RPM is version 7171.2018.0808.1, while vpn.uts.edu.au's RPM is version 7181.2019.0620.1 These RPMs would have been downloaded originally from F5's website by downloading the APM Clients ISO (latest version is 7182.2019.923.1603-4727.0) and copying linux_f5vpn.x86_64.rpm. This ISO does not vary based on who downloads it. On Wed, Jan 1, 2020 at 7:50 AM <notify(a)aur.archlinux.org> wrote: > HailHydra [1] filed a deletion request for f5vpn [2]: > > Package contains university specific installation files with no > indication of such in package naming or description. > The 'linux_f5vpn.x86_64.rpm' file is specific to the university it is > downloaded from, this can be seen by the differing hash sums of the > file linked in the PKGBUILD > ("https://it.emory.edu/vpntools/linux_f5vpn.x86_64.rpm") and one > provided by a different university (ie. > "https://vpn.uts.edu.au/public/download/linux_f5vpn.x86_64.rpm") > > [1] https://aur.archlinux.org/account/HailHydra/ > [2] https://aur.archlinux.org/pkgbase/f5vpn/

5 years, 11 months

Re: [PRQ#42352] Deletion Request for prusa-slicer-bin

by JP Roemer

As the current maintainer of this aur package, I would like to note that prusa-slicer-bin do provide some value over https://archlinux.org/packages/extra/x86_64/prusa-slicer/ as it includes pre-release binaries (as specified in its description). Those pre-release / release candidate version do use the same configuration folder as final release one (which alpha & beta version do not) and are considered mostly safe to use with just some cutting edge new features available. The value of this package is to be able to install and tests pre-release versions which are not shipped as part of extra/prusa-slicer. If this is something that is not welcomed in the aur, I understand and this package can be removed. I just felt like the specific way configuration are handled by this package warranted the existence of a package that included stable and release-candidate versions. Best, Orax On Mon, 19 Jun 2023, at 12:20, notify(a)aur.archlinux.org wrote: > MarsSeed [1] filed a deletion request for prusa-slicer-bin [2]: > > Not needed anymore, same is in [extra]: > > https://archlinux.org/packages/extra/x86_64/prusa-slicer/ > > [1] https://aur.archlinux.org/account/MarsSeed/ > [2] https://aur.archlinux.org/pkgbase/prusa-slicer-bin/

2 years, 5 months

Re: [aur-requests] [PRQ#36474] Deletion Request for powerpill

by Christopher Snowhill (kode54)

How about instead, someone sets up a Gitlab.com <http://gitlab.com/> repository set to mirror the upstream? Gitlab can be configured to only mirror a repository, where it doesn't allow commits, but instead simply periodically tracks a repository and mirrors the remote commits. > On Jul 19, 2022, at 3:11 AM, Marcell Meszaros <marcell.meszaros(a)runbox.eu> wrote: > > I understand your frustration completely. And for what it's worth, > I fully disagree with any indiscriminate geoblocking by public hosting > providers for political or ideological reasons, absent of any valid justification (of which I can barely name any). > > But still, please try to be reasonable with respect to this issue. > By the logic of your deletion proposal, all Qt software should be banned > from Linux because The Qt Company also geoblocks Russian Federation IP addresses. > > On 19 July 2022 11:44:42 GMT+02:00, "Дмитрий Елисеев" <xeondead(a)gmail.com> wrote: > Revenge? I'm not sure where you've got that from. > My provider's IPs are sometimes getting blocked, and sometimes they're not. > Open Source Software should be free for everyone, drawn lines based upon GeoIP isn't very nice, and such package has no place on AUR, or should at least be marked as inappropriate to use on specific territories. > > пн, 18 июл. 2022 г. в 20:21, Marcell Meszaros <marcell.meszaros(a)runbox.eu <mailto:marcell.meszaros@runbox.eu>>: > Unless *all* IP's are blocked throughout the world from downloading the sources, this should not be deleted. > > Revenge is not a valid reason for dropping a package from AUR. > > On 18 July 2022 10:08:33 GMT+02:00, "Christopher Snowhill (kode54) via aur-requests" <aur-requests(a)lists.archlinux.org <mailto:aur-requests@lists.archlinux.org>> wrote: > > > >> On Jul 18, 2022, at 12:26 AM, notify--- via aur-requests <aur-requests(a)lists.archlinux.org <mailto:aur-requests@lists.archlinux.org>> wrote: > >> > >> XeonDead [1] filed a deletion request for powerpill [2]: > >> > >> The author has disabled connections to his storage server based on > >> GeoIP. Just so happens, I've been hit, so the package can't be built, > >> or it's dependencies. > >> > >> [1] https://aur.archlinux.org/account/XeonDead/ <https://aur.archlinux.org/account/XeonDead/> > >> [2] https://aur.archlinux.org/pkgbase/powerpill/ <https://aur.archlinux.org/pkgbase/powerpill/> > > > >Sounds like the dev is one of those helpful people who think it's really "helpful" to geoblock Russia right now. That sort of "help" doesn't belong in the AUR, in my opinion. > > > -- > С уважением, > Елисеев Дмитрий > моб. +7 (995) 593-01-64

3 years, 5 months

Re: [aur-requests] [PRQ#4023] Deletion Request for fish-git

by SanskritFritz

On Wed, Sep 16, 2015 at 11:35 AM, Maxime Gauduin <alucryd(a)archlinux.org> wrote: > > > On Wed, Sep 16, 2015 at 11:24 AM, Levente Polyak <anthraxx(a)archlinux.org> > wrote: > >> On 09/15/2015 09:27 PM, notify(a)aur.archlinux.org wrote: >> > SanskritFritz [1] filed a deletion request for fish-git [2]: >> > >> > Gitorius is gone, this package is deprecated anyway long time. >> > >> > [1] https://aur.archlinux.org/account/SanskritFritz/ >> > [2] https://aur.archlinux.org/pkgbase/fish-git/ >> > >> >> Wouldn't it make more sense to keep fish-git and merge figh-shell-git >> into the first one? The official fish package in the community >> repository is named 'fish', it sounds more appropriate to have a >> matching name for the VCS package. >> >> Indeed, as long as the package in [community] is called fish, its git > counterpart in AUR must be called fish-git. There is very little chance > that, in the future, anything other than this shell will be called fish > anyway, I believe it is fine to keep fish{,-git} as package name rather > than changing it to fish-shell{,-git}. > Yes, that is why I requested a delete, so that we can rename fish-shell-git into fish-git. Should I request for a merge now?

10 years, 2 months

Re: [PRQ#49334] Deletion Request for qt5-translations-git

by Marcell Meszaros

Only in response to my deletion request, maintainer has changed the source to KDE's backport maintenance fork. But my original argument for dropping this from AUR still holds: it's not use to keep this package, as Arch extra repo's stable equivalent also gets bumped frequently to build from new commits published to same maintenance branch. Qt5 is EOL, and soon won't receive any backported patches whatsoever. The stable package should be enough to have around, as long as there are reverse dependencies. On 20 October 2023 17:35:09 GMT+02:00, notify(a)aur.archlinux.org wrote: >MarsSeed [1] filed a deletion request for qt5-translations-git [2]: > >Not useful to keep this package. > >Qt5 is EOL since May 2023. > >This PKGBUILD currently builds from upstream's Qt5 branch, which is >typically behind the source used by the stable PKGBUILD in extra repo. >Qt devs delay pushing Qt5 patches to the public repo by one year, >whereas the KDE project cherry-picks and backports most of the >important commits accepted by Qt Group for Qt5 but not yet publicly >pushed. > >Therefore the extra repo build is better for users and developers >alike, because it is based on newer code which has less bugs. > >As a consequence of all this, the extra/qt5* packages are quite like >git VCS packages. > >[1] https://aur.archlinux.org/account/MarsSeed/ >[2] https://aur.archlinux.org/pkgbase/qt5-translations-git/

2 years, 1 month

[PRQ#43084] Deletion Request for lib32-libsidplay

by notify＠aur.archlinux.org

MarsSeed [1] filed a deletion request for lib32-libsidplay [2]: This Commodore64 SID music file playback library was last updated in 2004. It was used through gstreamer via one of its "ugly plugins". Repo dropped the 64-bit package recently due to "failing to build" (FS#78686; no details specified or logs shared). As of today, AUR's lib32-gst-plugins-ugly has also removed this dependency. Irrespective of the viability of the 64-bit build, this lib32 package is emphatically not needed. By following the dependency graph in Arch and AUR repos, one can see that the only consumers of lib32-gstreamer are wine packages, and its commercial alternative, crossover. There is hardly any bin32 media player in the whole ecosystem. (And there's no reason for such to exist in x86_64 land.) Emulators of Commode 64 et al never needed libsidplay, as they implement full emulation internally, including the waveform generator of the original SID chip of Commodore machines. As for applications external to Arch/AUR packages, I can hardly think of any that would need this niche, extremely old library either directly or through lib32-gstreamer. So I conclude that it's safe to delete this package from here. [1] https://aur.archlinux.org/account/MarsSeed/ [2] https://aur.archlinux.org/pkgbase/lib32-libsidplay/

2 years, 5 months

Re: [PRQ#73348] Deletion Request for zoom-firejail

by Xiao Pan

On Sat, May 17, 2025 at 06:58:57AM +0000, notify(a)aur.archlinux.org wrote: > oech3 [1] filed a deletion request for zoom-firejail [2]: > > This just runs zoom on firejail. > > But it seems user-side workaround is also needed according to > maintainer of this :https://aur.archlinux.org/packages/zoom- > firejail#comment-978751 . > > If it is impossible to add package itself, this should be move to Arch > wiki. > > [1] https://aur.archlinux.org/account/oech3/ > [2] https://aur.archlinux.org/pkgbase/zoom-firejail/ Firejail 0.9.74 is released and it contains the fix, no workaround is needed any more. I have tested it on my Nvidia GPU. Please read [1] carefully, I mentioned there was a pull request [2] fixed the issue and I also wrote "wait until new firejail version 0.9.74", the meaning of this is firejail version 0.9.74 contains the fix so no workaround is needed if you are using firejail version 0.9.74. Arch Linux already has official firejail version 0.9.74 package since 2025-03-25 see [3]. I repeat again, no user-side workaround is needed for aur/zoom-firejail to work now because official Arch firejail version 0.9.74 package contains the fix for the issue in pull request [2]. Please do not delete zoom-firejail package from AUR. [1] https://aur.archlinux.org/packages/zoom-firejail#comment-978751 [2] https://github.com/netblue30/firejail/pull/6387 [3] https://archlinux.org/packages/extra/x86_64/firejail/

7 months

Re: [PRQ#73348] Deletion Request for zoom-firejail

by Xiao Pan

On Sat, May 17, 2025 at 06:58:57AM +0000, notify(a)aur.archlinux.org wrote: > oech3 [1] filed a deletion request for zoom-firejail [2]: > > This just runs zoom on firejail. > > But it seems user-side workaround is also needed according to > maintainer of this :https://aur.archlinux.org/packages/zoom- > firejail#comment-978751 . > > If it is impossible to add package itself, this should be move to Arch > wiki. > > [1] https://aur.archlinux.org/account/oech3/ > [2] https://aur.archlinux.org/pkgbase/zoom-firejail/ Firejail 0.9.74 is released and it contains the fix, no workaround is needed any more. I have tested it on my Nvidia GPU. Please read [1] carefully, I mentioned there was a pull request [2] fixed the issue and I also wrote "wait until new firejail version 0.9.74", the meaning of this is firejail version 0.9.74 contains the fix so no workaround is needed if you are using firejail version 0.9.74. Arch Linux already has official firejail version 0.9.74 package since 2025-03-25 see [3]. I repeat again, no user-side workaround is needed for aur/zoom-firejail to work now because official Arch firejail version 0.9.74 package contains the fix for the issue in pull request [2]. Please do not delete zoom-firejail package from AUR. [1] https://aur.archlinux.org/packages/zoom-firejail#comment-978751 [2] https://github.com/netblue30/firejail/pull/6387 [3] https://archlinux.org/packages/extra/x86_64/firejail/

7 months

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