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

Re: [PRQ#75053] Deletion Request for opencode

by thdxr

we've removed opencode from our CI process we have had issues with people publishing fake versions under the opencode name (see opencode-ai-bin) so we were trying to protect the name if this happens again i expect action to be taken Sent via Superhuman <https://sprh.mn/?vip=d@ironbay.co> On Sat, Aug 02, 2025 at 4:58 PM, <notify(a)aur.archlinux.org> wrote: > envolution [1] filed a deletion request for opencode [2]: > > Maintainer is aware that including binary packages in a non-bin namespace > is not correct, and continues committing updates here several times daily. > This package has been merged and deleted based on this more than once: > > https://lists.archlinux.org/archives/list/aur- > requests(a)lists.archlinux.org/message/IDPYIMVZ2UHDINZNWLMFDC27IUYS5ZRZ/ > > https://lists.archlinux.org/archives/list/aur- > requests(a)lists.archlinux.org/message/QQGT4YFLYRFFZN536CIVHMIPTJWZOHP7/ > > Maintainer has confirmed his intention of only submitting binary releases > in: https://lists.archlinux.org/archives/list/aur- requests@lists. > archlinux.org/message/HTTWLJSRHPWHJNUEUAVKS2ULI5XR7ER6/ > > Maintainer has been informed that this package is a duplicate of > aur/opencode-bin and suggested it was an error (1 month ago) https://aur. > archlinux.org/packages/opencode-bin#comment-1030701 > > Maintainer was contacted letting him know his CI actions were recreating > aur/opencode with binaries here: > https://aur.archlinux.org/packages/opencode#comment-1033898 and here: > https://github.com/sst/opencode/issues/1358 > > His new reasoning is that it's to prevent namesquatters. > > I am concerned that deleting this package will (again) only be a temporary > measure - considering opencode-bin seems popular, and is generated by the > project's github actions - maybe at least for now block the opencode > namespace or free up both to allow others them as per the guidelines > > [1] https://aur.archlinux.org/account/envolution/ > [2] https://aur.archlinux.org/pkgbase/opencode/ >

4 months

Re: [aur-requests] [PRQ#3328] Deletion Request for exfalso

by "Pedro A. López-Valencia"

El 17/05/2015 a las 4:52 p. m., Bruno Pagani escribió: > Le 17/05/2015 23:45, Johannes Löthberg a écrit : >> On 17/05, Johannes Löthberg wrote: >>> On 17/05, notify(a)aur.archlinux.org wrote: >>>> ArchangeGabriel [1] filed a deletion request for exfalso [2]: >>>> >>>> I need to reupload this package with a pkgbase (quodlibet) variable, >>>> and AFAIK, this goes through removal of the existing package. >>>> >>> >>> Could you upload a quodlibet package without the exfalso split >>> package in it and then request a merge if you want the new package >>> to keep the votes and comments? >>> >> >> Actually, scratch that, you won't be able to upload a quodlibet >> package because it exists in the repos and the repo package has >> exfalso in it. Is there anything different at all in this package? >> > > Indeed. It’s exfalso without quodlibet (I only use the former, and a > lot of other people too), another way to do this would be splitting > the repo package into four (or more, if splitting l10n): > > ... > > Should I open a bug against quodlibet packaging on Arch? As Johannes Lothberg pointed out, not the Arch way. If it happens, is the exception that confirms the rule. I have not examined the source code, but considering that Python is so flexible about namespaces, you could even manage to make it coexist with the repo package by renaming the executable script, perhaps renaming the main library entry point and do some sed magic in a couple of files in the package() section of your PKGBUILD.

10 years, 7 months

Re: [PRQ#75011] Deletion Request for linux-versioned-bin

by Chris Billington

On Fri, 1 Aug 2025, 17:44 , <notify(a)aur.archlinux.org> wrote: > oech3 [1] filed a deletion request for linux-versioned-bin [2]: > > Arch linux archive should not be repacked. > > [1] https://aur.archlinux.org/account/oech3/ > [2] https://aur.archlinux.org/pkgbase/linux-versioned-bin/ This package isn't a straight-up repackage of the existing kernel from the repos, it is modified so as to allow multiple kernel versions to be installed simultaneously, as a solution to the "lost all my modules upon reboot" problem. I'm under the impression it has a reasonable number of users (including myself), and it has been around in largely this form for the past five years. I think this is a legitimate addition of functionality that falls under the allowed exceptions to the "don't upload AUR packages already in the official repo" rule. I'm happy to use a different source than the Arch Linux Archive, though I don't see a rule against using the Arch Linux Archive as a source. I used to have a hack in this package so that it would use the user's preferred mirror, but this meant the information in the .SRCINFO was not consistent with what would actually be used, so it seemed better to use a fixed source URL. What would be better - using a specific mirror? I could do that, though I'd want to add signature checking or something if the source isn't the user's mirror or an archlinux.org domain over https, so users can have some confidence they're not installing malware. Happy to discuss, but consider this an appeal to the rejection request, I think that is premature. -Chris

4 months, 2 weeks

Re: [PRQ#75011] Deletion Request for linux-versioned-bin

by Chris Billington

On Fri, 1 Aug 2025, 17:44 , <notify(a)aur.archlinux.org> wrote: > oech3 [1] filed a deletion request for linux-versioned-bin [2]: > > Arch linux archive should not be repacked. > > [1] https://aur.archlinux.org/account/oech3/ > [2] https://aur.archlinux.org/pkgbase/linux-versioned-bin/ This package isn't a straight-up repackage of the existing kernel from the repos, it is modified so as to allow multiple kernel versions to be installed simultaneously, as a solution to the "lost all my modules upon reboot" problem. I'm under the impression it has a reasonable number of users (including myself), and it has been around in largely this form for the past five years. I think this is a legitimate addition of functionality that falls under the allowed exceptions to the "don't upload AUR packages already in the official repo" rule. I'm happy to use a different source than the Arch Linux Archive, though I don't see a rule against using the Arch Linux Archive as a source. I used to have a hack in this package so that it would use the user's preferred mirror, but this meant the information in the .SRCINFO was not consistent with what would actually be used, so it seemed better to use a fixed source URL. What would be better - using a specific mirror? I could do that, though I'd want to add signature checking or something if the source isn't the user's mirror or an archlinux.org domain over https, so users can have some confidence they're not installing malware. Happy to discuss, but consider this an appeal to the rejection request, I think that is premature. -Chris

4 months, 2 weeks

Re: [aur-requests] [PRQ#19626] Deletion Request for dyuganga

by विश्वासो वासुकिजः (Vish vas Vasuki)

Namaste, I hope to answer the objection with the following points: - The package is meant for quickly setting up a working environment on an Arch Linux based computer for use by Sanskrit language specialists who are NOT AT ALL familiar with Linux (even if they happen to have used the computer a few times). - Tasks they typically aim to accomplish include: - Reading texts in rare Indic scripts - Typing in Indic scripts (including vedic accents). - Editing and curating multimedia (especially audio files). - Viewing and creating skycharts pertaining to Hindu astronomy. - Communicating with colleagues in the process as needed. - Teaching each other how to use the system. - I am happy to note that with the dyuganga package, I have personally seen 3 people get up to speed and be very productive on an Arch based rented laptop. Please understand that the tasks I described above are NOT trivial even for the computer savvy Sanskritist (lots of trial and error involved in even typing well), let alone those who have never seen or used a linux computer. Hence, I request Mr Caleb and AUR people to support retaining the package. On Fri, Jun 5, 2020 at 3:44 PM <notify(a)aur.archlinux.org> wrote: > caleb [1] filed a deletion request for dyuganga [2]: > > Not really what it says on the tin, nor really useful. I could see a > package with a currated list of dependencies to support a language > group or specific workflow, but this is just random stuff with no > relation to what the title says. Zoom? Gimp? IntelliJ? parcelite? > Audacity? This is somebodies preferred desktop environment. > > Keeping this in an Arch package build makes sense. Keeping it in the > AUR does not. > > [1] https://aur.archlinux.org/account/caleb/ > [2] https://aur.archlinux.org/pkgbase/dyuganga/ -- -- Vishvas /विश्वासः

5 years, 6 months

Re: [PRQ#45600] Deletion Request for gamejolt-client

by Marcell Meszaros

@yochananmarqos, I see you have posted the source code link in the OOD flag comment. I was not aware that the source is open, as I only briefly checked the GameJolt website earlier, and it surely doesn't advertise the GitHub repo. Also I only advised the maintainer to create a '-bin' suffixed package, OR a package without such suffix *if the application is closed source*. I guess we were both unaware of the published source, an honest mistake. Also btw, maintainer only took over the earlier long-abandoned gamejolt-client-bin-aur package 11 days ago. And as far as I can tell, this is their first package on AUR. So let's not be so harsh with our newest contributors, shall we? :) Cheers, Marcell (MarsSeed) On 29 July 2023 20:45:49 GMT+02:00, Marcell Meszaros <marcell.meszaros(a)runbox.eu> wrote: >@yochananmarqos, please don't turn to such draconian measures. It's not the maintainer's fault that the GameJolt provider arbitrarily changes their shitty download URL. > >And this new package was created because I suggested/requested that the earlier package, gamejolt-client-bin-aur be renamed, because that name is both nonconformant to AUR naming rules, and also the '-aur' suffix is irrelevant. > >This is a closed-source application, so maintainer renamed and resubmitted their earlier package as 'gamejolt-client', and initiated an AUR merge (see PRQ#45586.) > >Let the maintainer update the source URL, don't go for the nuclear option within the first minute. > >Thank you for your cooperation and understanding. > >Marcell (MarsSeed) > >On 29 July 2023 20:20:50 GMT+02:00, notify(a)aur.archlinux.org wrote: >>yochananmarqos [1] filed a deletion request for gamejolt-client [2]: >> >>Please don't add non-functional packages to the AUR. >>See the comments and address the issues before this deletion request >>comes up in the queue. If the issues are addressed in the meantime, >>I'll close this request. >> >>[1] https://aur.archlinux.org/account/yochananmarqos/ >>[2] https://aur.archlinux.org/pkgbase/gamejolt-client/

2 years, 4 months

Re: [aur-requests] [PRQ#13420] Deletion Request for gosh

by Sauyon Lee

Hi, I'm the maintainer of the gosh package, and this seems reasonable enough to me, but obviously there's the concern that people who have the old gosh installed may be using it and not want this to go through (though I doubt there are many of them). If my input is at all necessary (which I doubt) I'm happy with any decision from the TUs. I assume there's some kind of protocol for this. Thanks, Sauyon On Fri, Nov 30, 2018, 23:33 <notify(a)aur.archlinux.org> wrote: > mvdan [1] filed a deletion request for gosh [2]: > > Hi, > > I'm the author of shfmt, which was recently added to the Community > repo: https://www.archlinux.org/packages/community/x86_64/shfmt/ > > As part of the same "shell tooling" project, I'm now working on a > second tool called "gosh". You can see both here: > https://github.com/mvdan/sh/tree/master/cmd > > It seems like the name is mostly free. The only official package > providing /usr/bin/gosh is "gauche", but being Scheme, I doubt many > people will run into that conflict. > > This package hasn't seen a real update in three years, and the > upstream project seems like it stalled in early 2015. I was wondering > if you could free up this package name in the AUR, so that I may use > it to package my shell tool. > > The command name in my project first appeared in early 2017, so this > isn't a last-minute attempt to take over someone else's package :) I > hope it doesn't seem that way. > > Thanks! > > [1] https://aur.archlinux.org/account/mvdan/ > [2] https://aur.archlinux.org/pkgbase/gosh/

7 years

Re: [aur-requests] [PRQ#34934] Deletion Request for run-mailcap

by Erik Johnson

The package has been updated to 3.70. In addition, I updated the package description to clarify that the package provides the run-mailcap script. This should address any "confusion". Please withdraw the deletion request. On Sun, May 29, 2022 at 8:30 AM Erik Johnson <palehose(a)gmail.com> wrote: > This is still a useful package, as it provides a useful utility to open > attachments in Mutt in external applications, based on mime type. > > I will update it the package, not delete it. > > On Sun, May 29, 2022 at 7:22 AM <notify(a)aur.archlinux.org> wrote: > >> m040601 [1] filed a deletion request for run-mailcap [2]: >> >> This is a very old PKGBUILD that references a obsolete 2014 Ubuntu >> version. It should be removed. It only confuses archlinux users >> looking for mailcap related tools. >> >> >> ```` >> Conflicts: mime-support >> ```` >> >> There is no PKGBUILD "mime-support" anymore. >> >> >> ```` >> Upstream URL: http://packages.ubuntu.com/utopic/mime-support >> ```` >> >> references a 2014, Ubuntu 14.10 (Utopic Unicorn) version. >> >> And leads to a non existing page, >> >> ```` >> Error >> two or more packages specified (mime-support utopic) >> ```` >> >> >> >> As of 2022 there is no "run-mailcap" package in recent versions of >> Ubuntu. The only thing related to "mailcap" in Ubuntu is, according >> to, https://packages.ubuntu.com/ a package called "mailcap", >> https://packages.ubuntu.com/source/jammy/mailcap >> >> [1] https://aur.archlinux.org/account/m040601/ >> [2] https://aur.archlinux.org/pkgbase/run-mailcap/ > > > > -- > > -Erik > > "For me, it is far better to grasp the universe as it really is than to > persist in delusion, however satisfying and reassuring." -- Carl Sagan > -- -Erik "For me, it is far better to grasp the universe as it really is than to persist in delusion, however satisfying and reassuring." -- Carl Sagan

3 years, 6 months

Re: [PRQ#75049] Deletion Request for hyde-ext

by Da4ndo

Hi *matthewq337*, I just read your deletion request for *hyde‑ext*—and I’m furious. Frankly, taking a shot at an AUR package *without bothering to fully understand what it is or how it works* is irresponsible. You wrote: *“a PKGBUILD for someone’s personal dotfiles does not really meet the usefulness criteria of the AUR”* You apparently filed that request as if the package were just someone’s private configs—but *hyde‑ext* isn’t. It's a *component of the HyDE framework*, a well‑established *Arch Linux environment* used by hundreds (if not thousands) of people. You can use Hyde-Ext to quickly install, configure, and restore system presets, dev tools, wallpapers, firewall rules, and more GitHub <https://github.com/HyDE-Project/HyDE>. Your request completely ignores the fact that: - *hyde‑ext* is a standalone AUR package with its own PKGBUILD, releases, votes, and metadata; it’s clearly listed in the AUR and meets all submission requirements aur.archlinux.org <https://aur.archlinux.org/packages/hyde-ext?utm_source=chatgpt.com>. - The *AUR guidelines explicitly state* that deletion requests must provide *solid justification*, not just vague assumptions—especially since the package maintainer may rely only on the aur‑requests thread for context wiki.archlinux.org <https://wiki.archlinux.org/title/AUR_submission_guidelines?utm_source=chatg…> . Here’s what *hyde-ext* actually *does*: - Provides *modular dotfiles and system configurations* for the HyDE environment—in essence, a centralized installer and *restoration utility* for user-selectable tools and settings. - Allows users to define *custom sets* of tools: editors, fonts, sys-configs, dev toolchains, wallpapers, firewall profiles—you name it—and install them with one command. - Includes *restore functionality*: lost configurations due to config wipes or system reinstall? Just rerun hyde-ext to pull everything back. - It’s *not “someone’s personal PKGBUILD”;* it’s fully configurable, transparent, and documented. Moreover, a major update is imminent that will greatly expand what users can do—adding *comprehensive documentation*, enhanced modularity, and functionality newly requested by community contributors. Your deletion request not only misrepresents the tool’s purpose, but *undermines the input of an entire user community* that relies on *hyde-ext* to bootstrap and maintain their HyDE environments. If you stand by your request after that process, fine. But filing a deletion request comes with *responsibility*, and right now, you're neglecting yours. HyDE is a mature, arch-native environment. *hyde-ext* is part of the HyDe experience and *serves a clear purpose*—removing it without due diligence is not only unfair, it’s *damaging the community infrastructure*. So please: *rescind your deletion request* immediately. *_________________________________________________________* *Da4ndo* Software Engineer — Backend & Full‑Stack Developer *Experienced in Rust, TypeScript, **Python, **C #, **C ++ ,**Go, Java* 📄 Portfolio & Blog: https://da4ndo.com 📧 contact(a)da4ndo.com <contact(a)da4ndo.com> <notify(a)aur.archlinux.org> ezt írta (időpont: 2025. aug. 2., Szo, 21:43): > matthewq337 [1] filed a deletion request for hyde-ext [2]: > > a PKGBUILD for someone's personal dotfiles does not really > meet the usefulness criteria of the AUR > > [1] https://aur.archlinux.org/account/matthewq337/ > [2] https://aur.archlinux.org/pkgbase/hyde-ext/

4 months, 2 weeks

Re: [PRQ#69254] Deletion Request for jdk16-adoptopenjdk

by Chris duke

If you do it makes fresh arch based installs unable to play those versions. On Thu, Feb 6, 2025, 1:32 PM Chris duke <christopherduke032(a)gmail.com> wrote: > Yes there is, MarsSeed. Pre 1.21 Minecraft Vanilla does and that's still > attainable. Do not delete. > > On Wed, Feb 5, 2025, 4:39 PM Marcell Meszaros <marcell.meszaros(a)runbox.eu> > wrote: > >> On 5 February 2025 13:48:53 GMT+01:00, FPSUsername < >> FPSUsername(a)protonmail.com> wrote: >> >As mentioned before some years ago. Some programs rely on java 16 for >> example some versions of Minecraft do. >> >It's the final version available and I think it should remain as an >> available package for users to install when they need Java 16. >> > >> >--Best Regards, >> >FPSUsername >> > >> >B.Eng. in Electrical Engineering >> > >> >Sent from Proton Mail Android >> > >> > >> >-------- Original Message -------- >> >On 2/5/25 13:40, <notify(a)aur.archlinux.org> wrote: >> > >> >> MarsSeed [1] filed a deletion request for jdk16-adoptopenjdk [2]: >> >> >> >> EOL since 2021, insecure, unneeded. >> >> >> >> [1] https://aur.archlinux.org/account/MarsSeed/ >> >> [2] https://aur.archlinux.org/pkgbase/jdk16-adoptopenjdk/ >> >> There are no programs that rely on this specific JDK/JRE build.. >> >> It is also badly packaged upstream is open-source, but this PKGBUILD uses >> a prebuilt binary. >> >> There are other jdk16 packages on AUR that are properly configured, e.g. >> jdk16-openjdk maintained by PM @Muflone. >> >

10 months, 1 week

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