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

Re: [PRQ#52449] Deletion Request for tensorflow-amd-git

by Mark Peschel

Dear MarsSeed et al, The difference between tensorflow-rocm and tensorflow-amd-git is that tensorflow-rocm pulls from Google's official repo while tensorflow-amd-git builds from AMD's fork. Google's repo is behind AMD's fork. I don't know if this justifies having separate packages. I adopted tensorflow-amd-git six months ago because, at the time, tensorflow-rocm did not work on my not-officially-supported GPU. I can build and install that package without errors, but any code that actually runs on the GPU would cause a segfault or similar. However, tensorflow-amd-git worked fine. It is possible, now that we are at Tensorflow 2.13, that this is not an issue. I have no plans to test this due to the time commitment. I would not be opposed to deleting this package. My GPU, the RX 6750 XT (gfx1031) is not officially supported, and I think I might be the only person using tensorflow-amd-git. It's not a big deal to delete it. I'm not very active anymore. I hope this helps clarify the situation; I apologize if I have sent my remarks to the wrong place. Regards, Mark Peschel On 12/25/23, notify(a)aur.archlinux.org <notify(a)aur.archlinux.org> wrote: > MarsSeed [1] filed a deletion request for tensorflow-amd-git [2]: > > Duplicte non-VCS package of AUR/tensorflow-rocm. > The latter also conforms better to upstream fork's name. > > [1] https://aur.archlinux.org/account/MarsSeed/ > [2] https://aur.archlinux.org/pkgbase/tensorflow-amd-git/

1 year, 7 months

Re: [PRQ#74850] Deletion Request for illogical-impulse-pymyc-aur

by Ameer Arsala

This is for the end-4 dotfiles and is the only way for it to work on immutable arch derivatives. You are attacking a project with many stars on GitHub for essentially no reason On Sat, Jul 26, 2025, 12:59 AM AlphaLynx <alphalynx(a)protonmail.com> wrote: > On Saturday, July 26, 2025 2:41:20 AM Eastern Daylight Time you wrote: > > Have you ever heard of a metapackage? This is the only way it works on > > certain arch derivatives. Please take your deletion requests away > > > > > > On Fri, Jul 25, 2025, 11:36 PM <notify(a)aur.archlinux.org> wrote: > > > > AlphaLynx [1] filed a deletion request for illogical-impulse-pymyc-aur > > [2]: > > > > The PKGBUILD [0] doesn't do anything. > > > > [0] https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=illogical-> > impulse-pymyc-aur > > > > [1] https://aur.archlinux.org/account/AlphaLynx/ > > [2] https://aur.archlinux.org/pkgbase/illogical-impulse-pymyc-aur/ > > Of course I have heard of a meta package, but I struggle to see how these > metapackages are useful and how they can't just be dependecies of a > illogical- > impulse package (which doesn't exist?). > > Secondly, packages must be useful on Arch Linux (see [1] and my comment > [2]), > not derivatives or other distributions. Meta packages like `base` and > `base- > devel` serve a great purpose [3], but how are these meta packages useful > on > Arch Linux specifically? > > [1] > https://lists.archlinux.org/archives/list/aur-general@lists.archlinux.org/ > message/GMYC74CRSFH7GGNENEUOODZUPWHOMX7A/ > <https://lists.archlinux.org/archives/list/aur-general@lists.archlinux.org/m…> > [2] > https://aur.archlinux.org/packages/zen-browser-compat-bin#comment-1033760 > [3] > https://lists.archlinux.org/archives/list/arch-dev-public@lists.archlinux.o… > > > >

3 weeks

[aur-requests] [PRQ#12376] Deletion Request for strawberry-bin

by notify＠aur.archlinux.org

Snuggle [1] filed a deletion request for strawberry-bin [2]: This package is in complete shambles. I hate being grumpy and I'm usually an upbeat person, but damn, this grinds my gears. 1 - He is using a Ubuntu-Bionic .deb build which has massively incompatible libraries, instead of using upstream's .RPM or .tar.xz releases available below. (https://github.com/jonaski/strawberry/releases) (http://builds.strawbs.net/ubuntu/bionic/) 2 - It's taken from upstream's Ubuntu builds and uploaded to his own GitHub as a source. (https://github.com/liberodark/Strawberry-Bin) 3 - He's then complained on upstream's GitHub about the library version mismatch and confused the heck out of everyone. (https://github.com/jonaski/strawberry/issues/12) 4 - It's a potential security risk as his own GitHub could contain *anything* and people will not know unless they notice the borked source in the PKGBUILD or extract the .deb themselves. 5 - The package is entirely broken, doesn't work and complains about needing libprotobuf.so.10, when Arch is currently on libprotobuf.so.16. (Due to the Ubuntu build for no reason) 6 - There already exists `strawberry`, `strawberry-git` and `strawberry-full-git`. This package doesn't add any value and is irreparably broken. You might be able to orphan this instead and get a new maintainer. I don't think this maintainer is able to package correctly, they don't seem to speak English very well and I have no clue why they thought any of this was a good idea, but this is a potential security risk and it's totally broken anyway. Apologies for the rant and thank you for doing an awesome job. ❤️ [1] https://aur.archlinux.org/account/Snuggle/ [2] https://aur.archlinux.org/pkgbase/strawberry-bin/

6 years, 11 months

Re: [PRQ#50346] Deletion Request for psx

by Marcell Meszaros

@FabioLolix, all your points are true. However, is this closed-source discontinued bin32 emulator really needed? Even the closed-source EPSXE is much newer (2016). And then there is pcsxr (2020) and its continuation fork, pcsx-redux (2023), both open-source. Btw the pkgname for this is wrong: should have been bin32-psx. But I don't think this PKGBUILD hits the bar on being actually useful and needed by "more than a few people", to quote the AUR submission guidelines. What's your take on these observations? Cheers, Marcell (MarsSeed) On 5 November 2023 22:11:03 GMT+01:00, Fabio Loli <fabio.loli(a)disroot.org> wrote: >Il 05/11/23 17:02, notify(a)aur.archlinux.org ha scritto: >> MarsSeed [1] filed a deletion request for psx [2]: >> >> Dead foreign-built binary PSX emulator from 2007; >> source code unavailable as this was closed source. >> PKGBUILD does not install the needed license (which seems to be >> unknown/undeclared by author). >> >> Upstream website gone. >> >> Some AUR dependencies are unbuildable with current libtool. >> >> Not worth keeping. There are many working alternatives nowadays that >> are maintained. Most of them are also open-source. >> >> [1] https://aur.archlinux.org/account/MarsSeed/ >> [2] https://aur.archlinux.org/pkgbase/psx/ > >The license is correctly listed as 'unknown' and no license file is included in the upstream archive, not an issue. > >I have all the depends build with devtools recently, I'll check if need to send a patch for something. > >The program still run.

1 year, 9 months

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

by Duru Can Celasun

On Mon, 18 Dec 2017, at 19:27, notify(a)aur.archlinux.org wrote: > Earnest [1] filed a deletion request for visual-studio-code [2]: > > Since the required request type doesn't exist, I'd like to suggest > this package *needs* to be named with a -bin suffix as it does not > build the actual package. > > This is what https://aur.archlinux.org/packages/visual-studio-code-oss > seems to do, but it should not need to call itself "-oss". > > So if I may request, this package be renamed to visual-studio-code- > bin. > > [1] https://aur.archlinux.org/account/Earnest/ > [2] https://aur.archlinux.org/pkgbase/visual-studio-code/ I wish this was opened as a comment first, instead of a deletion request. As I've mentioned in the pinned comment, this package doesn't have a -bin suffix for historical reasons. Specifically, when Visual Studio Code was released it was not an open source project and there was no indication it ever would be. By the time Microsoft decided to release it with the MIT license, the package was already widely used. Currently, it's one of the 3 most popular packages on AUR [1]. The idea at the time was to avoid breaking updates for so many people by renaming. That reasoning is even more valid today. Nevertheless, I've pushed a new package with the -bin suffix [2]. However, I'd like to urge everyone to reject this rename request. Assuming the -oss package renames itself to remove the suffix, it will cause tremendous confusion among users of the binary package, especially since the "new" package would have reduced functionality (no extension gallery) compared to the current binary package. As far as I can see, there is no way to use conflicts/replaces in the PKGBUILD to avoid the above situation. So please, let's not do this. [1] https://aur.archlinux.org/packages/?O=0&SeB=nd&K=&outdated=&SB=p&SO=d&PP=50… [2] https://aur.archlinux.org/packages/visual-studio-code-bin

7 years, 7 months

Re: [PRQ#43603] Deletion Request for youtube-downloader-appimage

by zxp

Hello,All In China, we often said a sentence: first there is a solution, then make it good. I think this is particularly reasonable. Some software only has AppImage format packages when released. But according to your request, I am gradually removing the already ported AppImage software package. Personally, I am not a developer and do not know how to program. However, the migration of Appimage format packages is relatively convenient. 在 2023/7/5 08:54, notify(a)aur.archlinux.org 写道: > MarsSeed [1] filed a deletion request for youtube-downloader-appimage > [2]: > > Please don't upload AppImage binaries of Electron- (Chromium) based > applications. > > These are hugely bloated and go against Arch's Electron application > guidelines, namely that they should use and depend on one of the > electron packages carried by Arch repo. > > I know that creating good quality packages is hard work, but that > doesn't mean that it should be okay to spam the AUR with five hundred > foreign binary packages which duplicate a lots of binary libraries and > runtimes already existing in the Arch Linux operating system. > > This is not Windows, where bloat and duplication is the norm. Please > learn and adhere to Linux principles. When there is source available, > use primarily that to build and package an application. Or in case of > Electron applications, you can choose to use the ASAR files with Arch > repo's electron runtime, and create a -bin suffixed electron package. > > [1] https://aur.archlinux.org/account/MarsSeed/ > [2] https://aur.archlinux.org/pkgbase/youtube-downloader-appimage/

2 years, 1 month

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, 4 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, 1 month

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, 3 months

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