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

Re: [PRQ#42343] Deletion Request for gpac-full

by Marcell Meszaros

>Duplicate of extra/gpac that just shuffles files around into different >split packages. This statement is not correct, @xiota. [extra] gpac build disables the dvb4linux module and oss-audio support, whereas this one enables dvb4linux and seemingly leaves oss-audio to be autodetected at build-time (a bad choice if it is like that). Granted, there are some serious packaging errors in this package, like basically all of its provides fields and some of its conflicts fields are wrong, and the split package 'mp4box' both depends on 'libgpac' but conflicts with 'gpac'. And using this package would preclude using any downstream packages that depend on 'gpac'. Hence, breaking at least 15 builds from AUR - see list in "Required by" column: https://aur.archlinux.org/packages/gpac-git But in the end all of the issues seem to be rectifiable by the maintainer. The intent of the package is valid: to provide more features/modules of gpac than what [extra] gpac does. (Cf. AUR/ffmpeg-full et al.) @fbrennan, please kindly work on fixing your packaging. It currently clashes with the packages mentioned as "Required by" on the above URL. @xiota I am asking you to revoke this deletion request. It is heavy-handed and not warranted in light of the situation. Thank you for your understanding. Have a nice day, folks. Marcell (MarsSeed) On 19 June 2023 02:56:53 GMT+02:00, notify(a)aur.archlinux.org wrote: >xiota [1] filed a deletion request for gpac-full [2]: > >Duplicate of extra/gpac that just shuffles files around into different >split packages. The split packages depend on each other, so the end >result is the same files installed under different package names. > >[1] https://aur.archlinux.org/account/xiota/ >[2] https://aur.archlinux.org/pkgbase/gpac-full/

2 years, 1 month

Re: [PRQ#66609] Deletion Request for primitive-git

by neitsab

Le 25/11/2024 à 19:52, Marcell Meszaros a écrit : > On 25 November 2024 13:51:09 GMT+01:00, notify(a)aur.archlinux.org wrote: >> neitsab [1] filed a deletion request for primitive-git [2]: >> >> Created in 2016 and never updated, user request in 2019 to use Go and >> CVS packaging guidelines was never honored, (badly) duplicates already >> existing https://aur.archlinux.org/packages/primitive (which we are >> fixing after latest error report). >> >> [1] https://aur.archlinux.org/account/neitsab/ >> [2] https://aur.archlinux.org/pkgbase/primitive-git/ > Please don't delete it. Upstream does not have any tagged release, and AUR/primitive is a VCS package in disguise, which should be merged into primitive-git (PRQ#66641) [1]. > > The '-git' pkgname suffix is mandatory. The package is now an orphan, which can be adopted and modernized. > > [1]: https://lists.archlinux.org/archives/list/aur-requests@lists.archlinux.org/… My idea was to get primitive-git deleted since: - it's never been updated since its initial upload - its PKGBUILD doesn't respect neither Go nor VCS packaging guidelines (as a commenter noted in... 2019) and then get primitive renamed into primitive-git. Would that be okay with you? We're talking about a package whose upstream hasn't been touched since 2020 and with a grand total of respectively 1 and 4 votes for primitive-git and primitive, so I doubt it will be earth shattering to too many users. Of course if we can merge primitive into primitive-git while keeping the PKGBUILD of the former (after it's hopefully fixed by its maintainer -- I posted a diff for it in its comments), all the better.

8 months, 3 weeks

Re: [aur-requests] [PRQ#31497] Deletion Request for anbox-modules-dkms

by eNV25

On Sat, Jan 15, 2022 at 11:10 AM <info(a)sick.codes> wrote: > > This is a false deletion request, the maintainer knows this is a correct non-git dkms PKGBUILD I don't think so. > > https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=anbox-modules-dkms > > The maintainer discussion between myself and the other maintainer is on https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=anbox-modules-dkms > > I don’t we know what the current maintainer is trying to achieve here but the two packages are distinct. > > 1) I personally maintain the fork with the GitHub user fine > > 2) I had already made env25 a co maintainer And I made you a co-maintainer for anbox-modules-dkms-git > 3) I am on the WayDroid dev team It's not relevant who you are > 2) this fork was created by myself and Choff fine > 3) the non-git is perfectly fine now No it's not it's a duplicate of anbox-modules-dkms-git > 4) eNV25 has already merged requested this, in a rush, for no apparent reason. The TU ainola merged this. I submitted the request. https://lists.archlinux.org/pipermail/aur-requests/2021-December/063155.html https://lists.archlinux.org/pipermail/aur-requests/2021-December/063596.html > > Please reject this merge & deletion request for the following reasons: Please don't reject this deletion request. > > And if possible please merge back the non-git repo comment history as you can clearly see > > I have been maintaining the WIKI on Anbox to be accurate https://wiki.archlinux.org/title/Anbox fine > > In good faith, > > Sick Codes of the Security Research Team @SickCodes > > https://sick.codes > https://github.com/sickcodes > https://twitter.com/sickcodes > https://www.linkedin.com/in/sickcodes/ > https://www.youtube.com/c/sickcodes > https://parler.com/profile/sickcodes/ > https://hackerone.com/sickcodes > https://bugcrowd.com/sickcodes > https://hub.docker.com/r/sickcodes > > > > > > > Jan 14, 2022, 22:57 by notify(a)aur.archlinux.org: > > eNV25 [1] filed a deletion request for anbox-modules-dkms [2]: > > This package is a duplicate of anbox-modules-dkms-git. > > I previously submitted a merge request from anbox-modules-dkms to > anbox-modules-dkms-git. > > I maintain anbox-modules-dkms-git. > > [1] https://aur.archlinux.org/account/eNV25/ > [2] https://aur.archlinux.org/pkgbase/anbox-modules-dkms/ > >

3 years, 7 months

[PRQ#58553] Deletion Request for stylelint-config-recess-order

by notify＠aur.archlinux.org

worstuser [1] filed a deletion request for stylelint-config-recess- order [2]: Dear AUR Administrator, I am writing to request the removal of a software package from the Arch User Repository (AUR). I believe this action is necessary and appropriate for the reasons outlined below. Firstly, the software in question has been deprecated. The original developers have ceased maintaining the software, and there have been no updates or patches for over two years. This lack of maintenance has resulted in the software becoming incompatible with recent versions of its dependencies, causing it to fail during runtime. Secondly, the software has been superseded by a newer, more efficient, and more secure alternative. The new software provides all the functionality of the old one, but with additional features and improved performance. It is also actively maintained and regularly updated to ensure compatibility with the latest system updates and security patches. Thirdly, the presence of the deprecated software in the AUR could potentially confuse or mislead users. Users looking for the software might inadvertently install the deprecated version instead of the newer one, leading to unnecessary troubleshooting and potential security risks. Lastly, removing the software from the AUR would help to keep the repository clean and manageable. It would reduce clutter and make it easier for users to find the software they need. It would also set a good precedent for the removal of other deprecated software in the future. In light of these reasons, I kindly request that you consider removing the software from the AUR. I understand that this may require some effort and I appreciate your understanding and assistance in this matter. Thank you for your time and consideration. [1] https://aur.archlinux.org/account/worstuser/ [2] https://aur.archlinux.org/pkgbase/stylelint-config-recess-order/

1 year, 4 months

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, 2 days

[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/

7 years

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, 8 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

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