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

Re: [PRQ#50396] Deletion Request for petsc-free+opts Accepted

by Muflone

Hola > This package was being maintained by yours truly, as compared to--let's > say petsc-git (which I abandoned) or pygtk-object-browser. The need for > the package was clarified as a pinned comment and at the top of the > PKGBUILD. It was not violating any license nor anything. It was a > perfectly innocent package that was not harming anyone and could be useful. The package petsc-free+opts was removed because it contained a couple of issues: 1) it was a duplicate of petsc-git 2) the name was plain wrong: it was a git package whose name didn't ended with -git 3) the name was meaningless: +opts is not a package classification and explains nothing about its nature 4) the documentation package was also meaningless: the pkgbase don't point to a "binary" package but when it builds it produces parts of prebuilt packages and parts of build packages. 5) the pkgver variable used in the makedepends is not valid and produces errors in the case hypre was not previously prebuilt 6) the whole PKGBUILD was very chaotic, with a lot of commented lines, disabled code, empty arrays, confused instructions Regards -- Fabio Castelli aka Muflone

1 year, 5 months

[aur-requests] [PRQ#31505] Deletion Request for nagstamon-beta

by notify＠aur.archlinux.org

ghostbuster [1] filed a deletion request for nagstamon-beta [2]: The upstream workflow of Nagstamon has been changed to github actions to create an automatic pre-release on a per commit or daiThe upstream workflow of Nagstamon has been changed to use github actions to create an automatic pre-release on a per commit or daily basis. The former manually released and announced pre-releases which were used for this package seem to be finally gone. Due to this upstream change using the prereleases would result in a git-like package. So I orphaned this package and adopted the nagstamon-git package roughly 6 month ago. The aur package nagstamon is not affected by any of these changed and is still based on official Nagstamon releases. From my point of view there is currently no need to keep this package as it is outdated and there is no Nagstamon release type available, which could be used to revive this package. In consequence, please consider deleting this package.ly basis. The former manually released and announced pre-releases which were used for this package seem to be finally gone. Due to this upstream change using the prereleases would result in a git-like package. So I orphaned this package and adopted the nagstamon-git package roughly 6 month ago. The aur package nagstamon is not affected by any of these changed and is still based on official Nagstamon releases. From my point of view there is currently no need to keep this package as it is outdated and there is no Nagstamon release type available, which could be used to revive this package. In consequence, please consider deleting this package. [1] https://aur.archlinux.org/account/ghostbuster/ [2] https://aur.archlinux.org/pkgbase/nagstamon-beta/

3 years, 7 months

Re: [PRQ#42357] Deletion Request for sensible-terminal

by Marcell Meszaros

@foxboron, thank you for explaining the issue in a clear way. Now I understand. @fbrennan, please accept my apologies. For the future, I would like to ask you to strive to state problem points in a clear language, like @foxboron did. If you do, your messages would be greatly helpful in getting others up-to-speed. Thank you for caring to maintain good quality packages! On 19 June 2023 14:50:35 GMT+02:00, Morten Linderud <foxboron(a)archlinux.org> wrote: >This is just wrong. > >xiota is name-squatting package names to force fbrennan to change the package. > >I've deleted these packages and expect xiota to reasonably interact with the AUR >maintainer to resolve this issue. > >Please don't incorrectly reframe the issue. > >On Mon, Jun 19, 2023 at 02:46:05PM +0200, Marcell Meszaros wrote: >> @fbrennan, this deletion request is not reasonable. I am asking you to kindly >> revoke it. >> >> Package maintainer @xiota has precisely explained in a comment the current >> problems with the sensible-utils package. >> >> Please try to use proper argument points and aim to convince others on the >> merit of your exposition, not by blaming them and accusing them of being >> deliberately hostile to you, where in fact they just use logical explanations >> and show a helpful attitude. >> >> On 19 June 2023 14:00:34 GMT+02:00, notify(a)aur.archlinux.org wrote: >> >fbrennan [1] filed a deletion request for sensible-terminal [2]: >> > >> >I am trying to add this to sensible-utils but this user seems to hate >> >me in particular and so has made everything about maintaining this >> >package needlessly more difficult. >> > >> >[1] https://aur.archlinux.org/account/fbrennan/ >> >[2] https://aur.archlinux.org/pkgbase/sensible-terminal/

2 years, 2 months

Re: [aur-requests] [PRQ#18963] Deletion Request for dxvk-winelib

by Stelios Tsampas

On 4/22/20 8:20 AM, Christopher Snowhill (kode54) wrote: > > >> On Apr 21, 2020, at 3:28 AM, Stelios Tsampas via aur-requests >> <aur-requests(a)archlinux.org> wrote: >> >> >> On 4/21/20 11:53 AM, notify(a)aur.archlinux.org wrote: >>> soredake [1] filed a deletion request for dxvk-winelib [2]: >>> >>> https://github.com/doitsujin/dxvk/commit/436357e28096f5e1e25aa8b72fceb77123… >>> >>> [1] https://aur.archlinux.org/account/soredake/ >>> [2] https://aur.archlinux.org/pkgbase/dxvk-winelib/ >> >> The version pointed by the tag still builds correctly under wine. The >> commit you are pointing to >> >> is after the tag built by this package. And even so, since this >> package builds correctly for this version, >> >> what is the problem with it existing? Why should this be deleted? >> > Are you suggesting that this package maintain a fork of the library > which still supports winelib builds? Or instead that it continue to > exist to build and install this old commit which will quickly become > obsolete as further improvements are added past this commit? I am suggesting neither. If you bother to look at the commit history, since the tagged version `1.6.1` there have been two commits at the time of writing, one of which is removing winelib support. There has been no release neither any groundbreaking change. It is rather premature to request to delete a package that build the latest version, especially without contacting the maintainer first about it. Also, allowing it to exist to build the last tagged version with winelib support is not unheard of and it has been done with numerous python packages in the past of example as python2 support was being dropped.

5 years, 4 months

Re: [PRQ#40704] Deletion Request for font-awesome-6

by Anirudh Konduru

Indeed, you are right. I was only looking at the AUR packages and not the community repo. Thank you for the clarification. I see that I cannot delete it myself, and only TUs can delete packages. Is there anything I could do to speed up the process? Best, Anirudh On Tue, Mar 21, 2023 at 10:11 AM Mark Wagie <mark.wagie(a)proton.me> wrote: > > > font-awesome has been in the community repo for years: https://archlinux.org/packages/community/any/font-awesome/ > > > > Sent with Proton Mail secure email. > > ------- Original Message ------- > On Monday, March 20th, 2023 at 7:48 PM, Anirudh Konduru <anirudhmkonduru(a)gmail.com> wrote: > > > > Hi, > > > > There doesn't seem to be a ttf-font-awesome / otf-font-awesome > > community package. The existing packages > > (ttf-font-awesome-5/otf-font-awesome-5 and > > ttf-font-awesome-4/otf-font-awesome-4) are meant to stay at their > > respective major versions. > > > > The maintainer of the ttf-font-awesome-5 provides some justification > > as to why this is the way it is: > > https://aur.archlinux.org/packages/ttf-font-awesome-5#comment-851649 > > > > > > > > On Mon, Mar 20, 2023 at 10:31 AM notify(a)aur.archlinux.org wrote: > > > > > yochananmarqos [1] filed a deletion request for font-awesome-6 [2]: > > > > > > Duplicate of ttf-font-awesome / otf-font-awesome community package. > > > > > > [1] https://aur.archlinux.org/account/yochananmarqos/ > > > [2] https://aur.archlinux.org/pkgbase/font-awesome-6/

2 years, 5 months

Re: [PRQ#62416] Deletion Request for quiterss-git

by Marcell Meszaros

On 20 August 2024 16:17:35 GMT+02:00, Fabio Loli <fabio.loli(a)disroot.org> wrote: >> MarsSeed [1] filed a deletion request for quiterss-git [2]: >> >> It seems this has become obsolete because it depends on the >> increasingly more frequently breaking component qt5-webkit, EOL since >> 2017. >> >> As of now, all providers of that lib, the qt5-webkit, qt5-webkit-git, >> qt5-webkit-movableink-git AUR packages fail to build, due to different >> reasons each (and this has been the case for at least 2-3 months). >> >> Upstream has not been maintained since 3 years ago. [a] >> >> Meanwhile the continuation fork, AUR/quiterss2-git [b] has been ported >> to the currently supported qt5-webengine, and therefore it can still >> be built and used. >> >> [a]: https://github.com/QuiteRSS/quiterss.git >> [b]: https://aur.archlinux.org/packages/quiterss2-git >> >> [1] https://aur.archlinux.org/account/MarsSeed/ >> [2] https://aur.archlinux.org/pkgbase/quiterss-git/ > >At least qt5-webkit builded fine as of 7 Aug 2024, it isn't failing >to build for months > In any case, there is still a maintained stable AUR/quiterss, there is no need to keep a -git variant for the same, as upstream is not touched for 3 years. It's enough for users to have the option to install either AUR/quiterss or AUR/quiterss2-git, in my view. Also, the less qt5-webkit dependent packages there are, the better, I think. I mean, especially when there are already modernized forks that use more reliable web rendering engines like Qt{5,6}-webengine.

1 year

Re: [PRQ#75077] Deletion Request for illogical-impulse-bibata-modern-classic-bin

by envolution

On Sun Aug 3, 2025 at 12:32 PM EDT, notify wrote: > AlphaLynx [1] filed a deletion request for illogical-impulse-bibata- > modern-classic-bin [2]: > > Duplicate of bibata-cursor-theme-bin which contains the Classic theme. > This was recently deleted for this reason [PRQ#74866], and the user is > aware of deletion [0] but resubmitted with no changes anyway. > > [0] > https://aur.archlinux.org/cgit/aur.git/commit/?h=illogical-impulse- > bibata-modern-classic-bin&id=2ed8b3e0e3660468ae2b9a8cbf5640d4d31042d3 > > [1] https://aur.archlinux.org/account/AlphaLynx/ > [2] https://aur.archlinux.org/pkgbase/illogical-impulse-bibata-modern-classic-b… I think the whole ^illogical-impulse series of packages should be removed as they seem to be some sort of custom theming/dotfiles configuration. Their upstream repo has instructions on how to configure linux with their defaults (that doesn't include these 'meta' and 'custom' packages) https://end-4.github.io/dots-hyprland-wiki/en/i-i/01setup/ aur/illogical-impulse-ags r525.05e0f23-1 [+2 ~0.12] Aylurs's Gtk Shell (AGS), version fixed for illogical-impulse dotfiles. aur/illogical-impulse-basic 1.0-1 [+1 ~0.07] Illogical Impulse Basic Dependencies aur/illogical-impulse-gtk 1.0-1 [+1 ~0.07] Illogical Impulse GTK Dependencies aur/illogical-impulse-microtex-git r494.0e3707f-1 [+1 ~0.07] MicroTeX for illogical-impulse dotfiles. aur/illogical-impulse-oneui4-icons-git r70.55eada4-1 [+1 ~0.07] A fork of mjkim0727/OneUI4-Icons for illogical-impulse dotfiles. aur/illogical-impulse-pymyc-aur 1.0-1 [+1 ~0.07] Illogical Impulse PyMYC Dependencies aur/illogical-impulse-python 1.0-1 [+1 ~0.07] Illogical Impulse Python Dependencies aur/illogical-impulse-bibata-modern-classic-bin 2.0.6-1 [+0 ~0.00] Material Based Cursor Theme, installed for illogical-impulse dotfiles aur/illogical-impulse-fonts-themes 1.0-1 [+0 ~0.00] Illogical Impulse Fonts and Theming Dependencies aur/illogical-impulse-oneui4-icons r64.9ba2190-1 [+0 ~0.00] A fork of mjkim0727/OneUI4-Icons for illogical-impulse dotfiles. aur/illogical-impulse-toolkit 1.0-1 [+0 ~0.00] Illogical Impulse GTK/Qt Dependencies aur/illogical-impulse-widgets-lite 1.0-1 [+0 ~0.00] Illogical Impulse Widget Dependencies (Lite version that doesnt lock you into certain dependencies)

1 month, 1 week

Re: [PRQ#57938] Deletion Request for ocamlnet

by Oliver Bandel

Quoting Marcell Meszaros <marcell.meszaros(a)runbox.eu> (snt: 2024-03-23 07:22 +0100 CET) (rcv: 2024-03-23 07:22 +0100 CET): > On 17 March 2024 14:30:01 GMT+01:00, notify(a)aur.archlinux.org wrote: > >MarsSeed [1] filed a deletion request for ocamlnet [2]: > > > >Broken for close to 1 year due to not being compatible with repo's > >ocaml 5, first published in May 2023. > > > >Upstream seems to be abandoned (developer only attends to their other > >projects). > > > >There has been a work-in-progress, partially viable port to ocaml 5, > >contributed to upstream in the form of a merge request 1.5 years ago, > >but it has been abandoned and ignored since. [a] > > > >That unfinished patch does not make this buildable. Also, now the code > >does not support the current gnutls, needed for https support in this > >library. > > > >Downstream dependents have either moved on to other solutions, or got > >discontinued 3+ years ago. (All AUR reverse dependencies have been > >submitted for deletion.) > > > >I think it's best to delete this package. > > > >[a]: https://gitlab.com/gerdstolpmann/lib- > >ocamlnet3/-/merge_requests/21 > > > >[1] https://aur.archlinux.org/account/MarsSeed/ > >[2] https://aur.archlinux.org/pkgbase/ocamlnet/ > > > The last package change is ill-conceived. The build stays broken. > > A package cannot depend on both 'ocaml' (v5) and 'ocaml4', as they conflict with each other. Still not useful to keep this library that is EOL for 3+ years. I asked the author of ocamlnet, if it was planned to update it for OCaml5. The answer was yes. So far there is no time plan for that, but next week I may habe more information.

1 year, 5 months

[PRQ#60974] Deletion Request for wechat-uos-bwrap

by notify＠aur.archlinux.org

7Ji [1] filed a deletion request for wechat-uos-bwrap [2]: The upstream name is Wechat (Universal), and it's released onto both the UOS app store and Kylin OS app store with such name. As its official usage is not limited to UOS it shall not bear uos in its name. As it also uses a mixed tech stack and -[GUI framework] suffix is conventionally used for GUI split package (e.g. transmission-qt is the GUI part of tranmission PKGBUILD) it shall also not bear qt in its name. There're already a lot of packging using wechat-universal as the name base, examples on AUR include -universal-privileged and -universal (without suffix) by lihe07 and -appimage by yifwon; examles outside AUR include -universal-flatpak ( https://github.com/web1n/wechat- universal-flatpak ) by web1n. For a complete history about official WeChat builds and why wechat- universal was chosen, please check the previous reply I made to the related aur-general thread: https://lists.archlinux.org/archives/list/aur- general(a)lists.archlinux.org/message/CFBKZH23X2ZP4VWEXR5HU4FL3ADAIQNL/ . About why deletion instead of merge: as the maintainer of -universal- bwrap and the co-maintainer of -beta-bwrap, I don't want unrelated comments in the history of -universal, neither its votes. While -beta- bwrap was created by leaeasy initially as a fork of -uos-bwrap, the packaging went a different way after I joined to help improving it and it became its own thing, their history is completely different as they had completely different user bases from day 1, and -universal-bwrap, created as a workaround for the AUR limitation that PKGBUILD could not be renamed (PRQ#57762 to merge -beta-bwrap to -universal-bwrap was filed as soon as I pushed the PKGBUILD), would want no history from -uos-bwrap. [1] https://aur.archlinux.org/account/7Ji/ [2] https://aur.archlinux.org/pkgbase/wechat-uos-bwrap/

1 year, 2 months

Re: [aur-requests] [PRQ#3401] Deletion Request for nuvolaplayer3

by Michael Corrigan

Requested merge into package with correct name. Please close request. On 26 May 2015 at 15:43, Patrick Burroughs <celti(a)celti.name> wrote: > On Tue, 26 May 2015 15:37:01 +0100 Michael Corrigan > <ghost.vonage(a)gmail.com> wrote: > >> Good afternoon Celti, >> >> The git package refuses to compile for me. That is why I made this >> package. You yourself commented on that package saying that it only >> build with a version of vala that the git package does not depend >> on. Once the git package is updated with this new dependency, I will >> delete this package as requested. > > That's an upstream modification required, I'm pretty sure; it's not a > matter of changing the AUR package to have a specific dependency. > Regardless, it can currently be worked around by downgrading vala > (which few other things depend upon). > >> Also the RPMs are coming from the stable branch of the repo. > > The RPMs are coming from the repository for the stable version of > Fedora; they are still beta builds of NuvolaPlayer, clearly marked as > such on the website. This is both a beta and a binary package and not > marked as either. > >> Kind Regards, >> Michael >> On 26 May 2015 14:45, <notify(a)aur.archlinux.org> wrote: >> >> > Celti [1] filed a deletion request for nuvolaplayer3 [2]: >> > >> > Repackages a (beta) RPM when there's a perfectly good -git package >> > to use. Should at the very least be renamed to >> > nuvolaplayer-beta-bin. >> > >> > [1] https://aur.archlinux.org/account/Celti/ >> > [2] https://aur.archlinux.org/pkgbase/nuvolaplayer3/ >> > >> > > >

10 years, 3 months

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