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

Re: [PRQ#59779] Deletion Request for ffmpeg-nocuda

by Marcell Meszaros

On 29 April 2024 21:59:28 GMT+02:00, notify(a)aur.archlinux.org wrote: >MarsSeed [1] filed a deletion request for ffmpeg-nocuda [2]: > >Unbuildable duplicate build of Arch/extra/ffmpeg (though newer >version.) >This is the 2nd resubmit of this package after it was already deleted >once. [a] > >Maintainer @eggz does not properly test their pushed packages, and >defiantly resubmits the ones that get deleted, even if for valid >reasons. > >Arch repo's ffmpeg also builds without cuda support, so there is no >benefit in keeping a '-nocuda' pkg. > >See other instances of defiance: >- 3rd resubmit of the one-line modded pikaur-aurnews, disguised VCS >package, [b] [c] >- 2nd resubmit of the never-buildable mate-wayland-session-git. [d] >[e] > >[a]: >https://lists.archlinux.org/archives/list/aur- >requests(a)lists.archlinux.org/thread/NVZTMTOTO3RELF75PW5MQ4HE4PEKBRIQ >[b]: >https://aur.archlinux.org/packages/pikaur-aurnews >[c]: >https://lists.archlinux.org/archives/search?q=pikaur- >aurnews&mlist=aur-requests%40lists.archlinux.org&sort=date-desc >[d]: >https://aur.archlinux.org/packages/mate-wayland-session-git >[e]: >https://lists.archlinux.org/archives/search?q=mate-wayland-session- >git&mlist=aur-requests%40lists.archlinux.org&sort=date-desc > >[1] https://aur.archlinux.org/account/MarsSeed/ >[2] https://aur.archlinux.org/pkgbase/ffmpeg-nocuda/ Package submitter's account has been deleted (@eggz). Safe to delete this broken, unneeded functional duplicate of Arch/extra/ffmpeg. @eggz has confessed the true intent of creating this package (in 2020) - that he was experiencing issues with the repo ffmpeg on his non-NVIDIA setup. [a] It is evidence of defiance of AUR submission guidelines that say no duplicate submission on AUR for bugs in repo packages. May I remark that I feel vindicated in the face of my last rejected deletion request for this package, even though it was still broken at the time and its duplication intent was obvious. [a]: https://aur.archlinux.org/packages/ffmpeg-nocuda#comment-970136

1 year, 7 months

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

by Johannes Frankenau

Hi Marcell, actually, I just remembered why the original maintainer didn't add those attributes. Because xdg-utils-no-open is meant to be used with packages like linopen, mimi, busking, or mimejs it should not provide or conflict with xdg-utils, because those packages already provide xdg-utils (to be correct only the xdg-open binary without the additional utilities). So, I believe I should revert my last commit here. That was the reason why I didn’t add provides and conflicts fields in response to the request from 2022. Johannes On 27 Jun 2023, at 13:49, Marcell Meszaros wrote: > 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: [PRQ#46561] Deletion Request for librsvg-og

by Marcell Meszaros

The AUR package was updated, but is still a duplicate of the ArchLinuxARM.org repo package and is not needed on AUR. On 22 August 2023 08:35:30 GMT+02:00, Marcell Meszaros <marcell.meszaros(a)runbox.eu> wrote: >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#5971] Deletion Request for packettracer

by Rick

Yes, Doug are right, you don't know very well the AUR rules: 1 If you detects something wrong, first read the existing comments of the package, perhaps the solution is in the comments. 2 If your problem isn't exposed before, put a new comment with the issue and the tests you did. 3 If in a good space of time noone responds your issue, you could make a request for disown the package, and you or other person, fix the issue or explain the possible solution. In this case the solution are in the comments, cisco's packet tracer are freeware but it's not free to redistribute, you need to open a netcad account (free), and download from the cisco's webpage, to get packettracer installed. 2016-07-14 20:14 GMT+02:00 care by john <carebyjohn(a)gmail.com>: > Ask Doug. He is the man questioning someone's ability. None of the > packettracer links are valid. > > On Thursday 14 July 2016, Rick <runnytu(a)gmail.com> wrote: > >> Hi, >> >> I don't understand what are you telling, what are the reason for remove >> the packettracert AUR package? >> >> 2016-07-14 19:04 GMT+02:00 <notify(a)aur.archlinux.org>: >> >>> redhat_boy [1] filed a deletion request for packettracer [2]: >>> >>> Remove this page itself, please. New Arch Linux users reaching out to >>> this page by Google search engine and getting confused. >>> >>> [1] https://aur.archlinux.org/account/redhat_boy/ >>> [2] https://aur.archlinux.org/pkgbase/packettracer/ >>> >> >>

9 years, 5 months

Re: [PRQ#46880] Deletion Request for pology

by Marcell Meszaros

My original request: PRQ#46854. Just for the record, I am not going behind anyone's backs. When I submit a request, it is just a proposal, and a public one, not a verdict, and not a secret. I am not a TU, only a fellow user, so there is no decision made at this point. And the package maintainers receive my submitted message, whether they are subscribed to the aur-requests mailing list or not, and they have also ample time to reply to it. Trusted Users evaluate the requests several weeks to 1-2 months later, and they take maintainers' feedback into account. And I don't think it is so outrageous to submit a request for a 9-year-old release which uses deprecated and broken Python2 based dependencies, when upstream maintains their tool in an active git repository which continually receives commits, and for which there is already an AUR package from same AUR owner, which I linked to in a comment I left on the old package's page. I think it is not reflecting very well on the maintainer to let a package rot for such a long time and not inform users with at least a suggestion to not use the stable package abandoned by upstream, and at least recommending them to use the always fresh git package. On 31 August 2023 09:01:32 GMT+02:00, notify(a)aur.archlinux.org wrote: >Gilrain [1] filed a deletion request for pology [2]: > >Though I don't support MarsSeed cavalier method by going behind >maintainers backs, I agree that this package should be deleted based >on upstream lack of "stable" releases in a decade. > >[1] https://aur.archlinux.org/account/Gilrain/ >[2] https://aur.archlinux.org/pkgbase/pology/

2 years, 3 months

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

by Marcell Meszaros

I suggest that you discuss your proposals in the public comments section of the package's AUR page instead of sending it to this deletion request thread. Also please note that @XeonDead does not receive mails sent to this list because he is not a subscriber. And TLDR; I am still convinced that regional geoblocking on its own is not a valid reason to delete a working and maintained AUR package. On 19 July 2022 14:26:17 GMT+02:00, "Christopher Snowhill (kode54) via aur-requests" <aur-requests(a)lists.archlinux.org> wrote: >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, 4 months

Re: [aur-requests] [PRQ#19650] Deletion Request for asf-ui

by Kusoneko

On July 23, 2020 7:01:04 AM UTC, Gilrain via aur-requests <aur-requests(a)archlinux.org> wrote: >Hi, >I'm the maintainer of the asf-ui package (and its parent asf). >I would support the original request made by trbn1 to rename the >package >as -git, if it's truly necessary. >Duplicating what is already a git package under a different name would >only waste everyones time. > >FYI, there hasn't been an official release of asf-ui, it's purely a git >software. > >Le 22/07/2020 à 19:35, Justin Kromlinger a écrit : >> Instead of deleting this package I would recommend creating a new >> package from the git sources and pushing it to asf-ui-git and a >> successive merge request. trbn1 would you like to do that and adopt >the >> package? >> >> On Sat, 06 Jun 2020 16:34:15 +0000 >> notify(a)aur.archlinux.org wrote: >> >>> trbn1 [1] filed a deletion request for asf-ui [2]: >>> >>> This package tracks git master branch so it's missing a -git suffix. >>> Package name should be asf-ui-git >>> >>> [1] https://aur.archlinux.org/account/trbn1/ >>> [2] https://aur.archlinux.org/pkgbase/asf-ui/ > >-- >Gilrain Justin had the correct solution here though. trbn1's would simply delete the package and you'd have to republish it to the AUR under the correct name, whereas this solution seems to be publish it under the correct name and ask (by submitting a merge request) to have the old one merged into it.

5 years, 4 months

Re: [PRQ#71006] Deletion Request for cammus-ff-dkms

by Tomasz Pakuła

Hi! I'm one of the two current (and most active now) developers of hid-universal-pidff. We merged some projects a while back so they don't receive any more support. 6.12 changed the report fixup to be static, but it seems like I forgot that this one didn't use it previously. So it actually is not broken technically. Still, we've done A LOT of development with hid-pidff since this one was achieved and it shouldn't be used anymore. The newer project adds things like extended button range, additional fixes and completely fixed handling of DEVICE_CONTROL collection. It is a mirror of the upstreamed changes that are now slated for 6.15. If there's a need, I could even ask spikerguy to file this request himself. Still, cammus-ff basically moved to universal-pidff like moza-ff which I reauested to be deleted some time ago now and I'll probably request universal-pidff deletion after 6.15 hits stable core repositories. My intention here is just not to confuse end users if they maybe would find this with google. Cheers. Tomasz On Thu, 13 Mar 2025, 00:03 Muflone Ovinis, <muflone(a)muflone.com> wrote: > Hi Lawstorant > > Lawstorant [1] filed a deletion request for cammus-ff-dkms [2]: > > re-submitting deletion request > Superseded by: https://aur.archlinux.org/packages/universal-pidff- > dkms-git (universal pidff driver) > > cammus-ff no longer works. Broken since linux 6.12. Repo was archived > and won't be worked on as it was superseded by the universal-pidff > driver as stated before. > > [1] https://aur.archlinux.org/account/Lawstorant/ > [2] https://aur.archlinux.org/pkgbase/cammus-ff-dkms/ > > > > regarding your deletion request, could you please clarify what's broken? > > There's not any comment on the package page > https://aur.archlinux.org/packages/cammus-ff-dkms about issues, I can > still build the module, install and load it > > What are the issues with this package? > > > Best regards > > > Muflone >

9 months

Re: [PRQ#46918] Deletion Request for waterfox-g3-bin

by Marcell Meszaros

Nothing depends on this broken EOL waterfox package anymore. Upstream only maintains WaterFox, for which the current release version is G6.0. The letter 'G' is a (permanent) part of the version string, but not part of the application's name. Upstream also does not maintain 'LTS' / 'ESR' legacy branches. So there is no reason to keep any 'waterfox-g*' packages on AUR. There's a properly named 'waterfox' [a] and 'waterfox-bin' [b] pkg now. (The latter is up-to-date, the former is in need of some maintainer attention.) [a]: https://aur.archlinux.org/packages/waterfox [b]: https://aur.archlinux.org/packages/waterfox-bin On 1 September 2023 22:01:41 GMT+02:00, notify(a)aur.archlinux.org wrote: >MarsSeed [1] filed a deletion request for waterfox-g3-bin [2]: > >Waterfox G3 version line is out of development since 2021: last G3 >release date is September 15, 2021. [a] > >This package is reported defunct as per last user feedback: > >"tbb commented on 2022-12-25: >it keeps crashing :(" > >The current main version line of WaterFox is G5, and the website no >longer offers WaterFox G3 for download. [b] > >I don't see any point in keeping this non-working package on AUR; >there are PKGBUILDs for the current WaterFox here. > >[a]: >https://github.com/WaterfoxCo/Waterfox/releases/tag/G3.2.6 >[b]: >https://www.waterfox.net/en-US/download/ > >[1] https://aur.archlinux.org/account/MarsSeed/ >[2] https://aur.archlinux.org/pkgbase/waterfox-g3-bin/

2 years, 2 months

[aur-requests] [PRQ#36723] Deletion Request for python2-gcp-devrel-py-tools

by notify＠aur.archlinux.org

MarsSeed [1] filed a deletion request for python2-gcp-devrel-py-tools [2]: Please kindly delete this Python 2 package. It is not needed by anything. I've originally imported it to AUR together with python2-urllib3, because this was in the latter's checkdepends() array. I've since realized that it is not mandatory for testing. URLlib3 1.26.11 still has its built-in support for running on Google AppEngine via gcp-devrel-py-tools and using its Python2-only 'URLFetch' service, but this feature has not seen much development during the last few years. [a] Google AppEngine support has been removed from the main branch for the upcoming URLlib3 v2.0 release, because the latter project is about to drop Python 2 altogether. [b] Anyway, this deprecated support was only used if running python- urllib3 with Python 2 on Google AppEngine itself. I am not sure if it is possible to run Arch Linux on it, as it seems it is a Platform-as- a-Service (PaaS) having its own OS. Also, Python 2 is deprecated so Google's cloud platforms are in the process of phasing it out for good. The gcp-devrel-py-tools project seems to have been neglected / unmaintained by Google since 2020. [c] It is not officially deprecated yet, but there are already byte- compilation errors at least when building with Python 2.7. All in all, it's best to delete this package. [a] https://github.com/urllib3/urllib3/commits/1.26.11/src/urllib3/contrib/appe… [b] https://github.com/urllib3/urllib3/commit/6af53ac41757399607382bf10a92b288f… [c] https://github.com/GoogleCloudPlatform/python-repo-tools [1] https://aur.archlinux.org/account/MarsSeed/ [2] https://aur.archlinux.org/pkgbase/python2-gcp-devrel-py-tools/

3 years, 4 months

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