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

Re: [PRQ#62914] Deletion Request for gstreamer113

by Vitalii Kuzhdin

Greetings, I suggest you actually examine the PKGBUILD before submitting deletion requests. To address your point, there isn't a standalone Python version '311' either; it's a reference to Python 3.11, which exists in the AUR <https://aur.archlinux.org/packages/python311> and is quite popular. I followed a similar naming convention here, with the proper naming specified in the provides array. The idea of merging all dependencies into a single PKGBUILD, simply because it’s possible, is impractical—and I trust I don’t need to explain why. This is especially true for older source trees that may require future patches. The fact that a package currently has only one dependent, just a few days after being uploaded, doesn’t invalidate its existence. Many packages exist without any dependents and are still valuable. My package serves a purpose, and bundling multiple packages into a single one (like cutter-test) is impractical. Furthermore, removing cutter-test would be unreasonable, given the number of packages that depend on it. I am actively reaching out to other maintainers to integrate testing with cutter-test. Best regards, Vitalii On Wed, Aug 28, 2024 at 4:46 PM <notify(a)aur.archlinux.org> wrote: > MarsSeed [1] filed a deletion request for gstreamer113 [2]: > > There is no gstreamer version 113 (one hundred and thirteen). > > This package was made for use by one package, cutter-test. > > Please don't duplicate repo packages for such a purpose; build your > specifically needed gstreamer version inline in the cutter-test > PKGBUILD, and install it in a location that is specific to cutter-test > only. > > [1] https://aur.archlinux.org/account/MarsSeed/ > [2] https://aur.archlinux.org/pkgbase/gstreamer113/

1 year, 3 months

Re: [PRQ#66951] Deletion Request for muse-hub-bin

by Marcell Meszaros

On 1 December 2024 20:53:35 GMT+01:00, notify(a)aur.archlinux.org wrote: >aliu [1] filed a deletion request for muse-hub-bin [2]: > >Was told to submit a deletion request after merge request to muse- >sounds-manager-bin (which I support) was denied for some reason. > >[1] https://aur.archlinux.org/account/aliu/ >[2] https://aur.archlinux.org/pkgbase/muse-hub-bin/ Hi Aaron, It seems it was one Arch Developer in particular, Morten Linderud, a.k.a. @Foxboron, who was denying almost all merge requests for a short burst of time early this year. In my observation of AUR decision precedent, @Foxboron's very strong stance against most merge requests is not shared by other Arch Developers and Package Maintainers. As a fellow AUR user I encourage you to do due diligence when deciding to request transfer of comments from one package to another. If the comments of a package that is to be removed would unnecessarily litter the target package's comment history, I would decide against a merge. On the other side of this consideration are the notification subscriptions. If a new package is a successor of an old package, a merge is useful for transferring the user notification subscriptions from the former to the latter. This information is secret, so we as AUR users don't know if and how many users in total are subscribed to each package. Upon a merge, subscribed users of an old package will continue to get notifications relating to the new package. For me personally, this was a welcome feature, when packages that I was subscribed to didn't just "get lost" upon getting merged to a different one, but instead I started to receive notifications about the new package. These are just my personal views and not in any way constitute any kind of official Arch Linux policy. Cheers, Marcell / MarsSeed

1 year

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

by edgar

On 2023-11-06 13:13, notify(a)aur.archlinux.org wrote: > MarsSeed [1] filed a deletion request for petsc-free+opts [2]: > > Badly configured PKGBUILD, fails execution. > VCS package in disguise, with wrong pkgname. > > Also, please refrain from using the '+' sign in pkgname. While it is > allowed by pacman, AURweb and AUR helpers had some issues with that > character earlier. (It is very rarely used, so support for it is not > much tested I guess.) > > If you want to maintain this package, please name it properly, like > 'petsc-free-plus-opts-git', and also don't add a split package with a > '-bin' suffix (petsc-doc-bin). Make the docs package reflect the > pkgbase name. (Using the previous example: petsc-free-plus-opts-doc- > git). > > [1] https://aur.archlinux.org/account/MarsSeed/ > [2] https://aur.archlinux.org/pkgbase/petsc-free+opts/ First, you complained about a non-existing -git suffix (a suffix means: at the end, the last part). Now you complain of a VCS in disguise. It was *_you_* who said that this package cannot have a -git suffix (never did), and now, you are suggesting that I add one to the only part of the package that does *not* use Git sources? Please, RTFM: https://wiki.archlinux.org/title/Arch_package_guidelines#Package_naming Package names can contain only alphanumeric characters and any of @, ., _, +, -. Names are not allowed to start with hyphens or dots. All letters should be lowercase. 1. This package is not in the official repo 2. It provides extra features 3. It does include at least one of these "executable(s); configuration file(s); online or offline documentation for specific software or the Arch Linux distribution as a whole; media intended to be used directly by software." 4. The part building from source does not use prebuilt binaries (no -bin suffix) 5. "> Badly configured PKGBUILD, fails execution." May be you did something wrong? (it works for me). I don't think that this mailing list is the right place for such a complaint. 6. It does provide information about past and present contributors 7. The documentation does come with *prebuilt* binaries, unless you consider a 2.5 MB PDF plain-text. If you don't like my PKGBUILD, please, don't use it and leave me alone. If you want to involve in a constructive discussion, please be polite and do it in the right place.

2 years, 1 month

Re: [PRQ#49836] Deletion Request for lib32-gd

by sL1pKn07 SpinFlo

>There is no other part of the libgphoto2 code that links to gd. that statement is not true at all https://github.com/search?q=repo%3Agphoto%2Flibgphoto2%20gd&type=code https://github.com/gphoto/libgphoto2/blob/807d44d0dcb0a8a8df151baa27830127f… i think you need talk with upstream for why still keep this type of thing in the code if is not used greetings El dom, 29 oct 2023 a las 22:55, <notify(a)aur.archlinux.org> escribió: > MarsSeed [1] filed a deletion request for lib32-gd [2]: > > lib32-gd is absolutely unnecessary for lib32-libgphoto2. > > The latter could only use gd for on-the-fly image conversion two > specific digital "picture frame" hardware, for which libgphoto2 > introduced support in 2015, well within the 64-bit era. Also that > library is utilized for Docupen scanner pen support, starting from > 2020. > > There is no other part of the libgphoto2 code that links to gd. > Therefore I cannot conceive any application that is bin32 only and > needs this specialized functionality of libgphoto2 for those 2015 and > 2020 released, 64-bit compatible niche hardware devices. > > I've notified the maintainer of lib32-libgphoto2 about this in July > 2023. > > Deleting this unneeded library would in turn allow other lib32 > packages to be dropped. And also it would help reduce the dependency > build burden on people who use AUR/wine-stable. > > [1] https://aur.archlinux.org/account/MarsSeed/ > [2] https://aur.archlinux.org/pkgbase/lib32-gd/

2 years, 1 month

Re: [PRQ#59704] Deletion Request for element-desktop-deb-package

by Marcell Meszaros

On 28 April 2024 15:01:27 GMT+02:00, a.m.wollmarker(a)miluriel.info wrote: >A parcel was already provided by me with the suffix BIN. This was not correct either. > >You are not following your own rules. > >It is not a rebuild. It downloads the DEB package directly and uses it directly. No rebuild, recompiling. Nothing like that. Direct use of the manufacturer package. > >One last time I ask, what exactly do you want and what are your requirements to accept it. Otherwise that's it with my cooperation in the sense of the Linux idea that everyone helps each other. > >Am 2024-04-28 14:12, schrieb Marcell Meszaros: > >> On 28 April 2024 13:16:50 GMT+02:00, "André M. Wollmarker" <a.m.wollmarker(a)miluriel.info> wrote: This package will be updated as soon as I receive an EOL message. >> It is 100% based on the deb package from the original developers and thus >> minimises some of the problems I and others have with the Arch package. >> It is therefore not incorrectly labelled. >> Deb is in the name and is referred to in the description. >> So it definitely has benefits. >> Am Sonntag, 28. April 2024, 11:40:26 MESZ schrieben Sie: MarsSeed [1 [1]] filed a deletion request for element-desktop-deb-package >> [2 [2]]: >> >> Unneeded. Exists in Arch extra repo. [a] >> >> Less frequently updated than the repo package. >> Has wrong pkgname. >> >> There's absolutely zero benefit in keeping it on AUR. >> >> [a]: >> https://archlinux.org/packages/?q=element-desktop >> >> [1] https://aur.archlinux.org/account/MarsSeed/ >> [2] https://aur.archlinux.org/pkgbase/element-desktop-deb-package/ > >As per AUR submission guidelines, if there are issues with a repo package, don't create duplicates of it on AUR, but create an Arch package issue. > >Also, AUR packages that use prebuilt artifacts of open-source code must be named with a '-bin' suffix. > >This is the second time you submitted an element-desktop binary package to AUR with wrong name. Thus, you have already defied an AUR PM's deletion decision. > > > >Links: >------ >[1] https://aur.archlinux.org/account/MarsSeed/ >[2] https://aur.archlinux.org/pkgbase/element-desktop-deb-package/ 1. Please report bugs you encounter with Arch/extra/element-desktop to the Arch Gitlab issue tracking system. 2. If you insist on maintaining an AUR package for upstream's build, rename this package to 'element-desktop-bin' AND keep it up-to-date.

1 year, 7 months

[PRQ#46792] Deletion Request for abgx360gui

by notify＠aur.archlinux.org

MarsSeed [1] filed a deletion request for abgx360gui [2]: Unfortunately this code that is used for creating Xbox360 "home backup" (or pirated) ISO's is illegal to use and redistribute, because it is an unlicensed continuation fork made by GitHub user @BakasuraRCE of the fully copyrighted abgx360 / abgx360gui source code. [a] The abgx360.hadzz.com website has a remark: "© 2008-2020 by Seacrest, © 2021-2023 by Hadzz" [a] 1) 'abgx360gui' package: The abgx360gui source does not contain a license file or comment, but every C++ source file contains a header stating the author's identity - see for example 'abgx360gui.cpp' [b]: "// // Name: abgx360gui.cpp // Author: Seacrest // Created: 10/8/2007 9:06:46 PM // Description: abgx360gui class implementation " @BakasuraRCE's for adds an additional line to the above [c]: "// Author: 2021 Bakasura <bakasura(a)protonmail.ch>" But their change is not legal, as they did not have the license permission to modify and redistribute the code. 2) 'abgx360' package The main backend executable file, 'abgx360.c', which does all the actual workload, bears the statement [d]: "Copyright 2008-2012 by Seacrest <Seacrest[at]abgx360[dot]net>" The implication is the standard "all rights reserved". In 2021-07-25 @FabioLolix has raised the license question in a comment on the AUR/abgx360 page, but submitter expressed unwillingness to address it. I do not see any other legal choice but to delete this package. I've submitted the related deletion request for AUR/abgx360 as PRQ#46791. [a]: https://abgx360.hadzz.com/download.php [b]: https://abgx360.hadzz.com/dl/abgx360gui-1.0.2.tar.gz [c]: https://raw.githubusercontent.com/BakasuraRCE/abgx360/c38475c/abgx360gui/sr… [d]: https://raw.githubusercontent.com/BakasuraRCE/abgx360/c38475c/linux/abgx360… [1] https://aur.archlinux.org/account/MarsSeed/ [2] https://aur.archlinux.org/pkgbase/abgx360gui/

2 years, 3 months

Re: [aur-requests] [PRQ#9551] Deletion Request for spinach

by Garrett

I would be fine with removing it from the AUR helpers page as there are presently many Bash AUR helpers. I don't know why it should be removed from the AUR though. This is not a clone of yaourt. Though according to the AUR Helpers page it is as secure as yaourt, i.e., not very secure except for spinach you'd have to do some interesting escaping (that to my present knowledge is not possible, but there might be some way to do it) to get around the function that cleans what is sourced for finding the depends. Yaourt package is 0.53 MiB whereas the spinach package is 23 KiB. It was originally created for being very small and only doing the minimum required while still being fast and useful. At the time (and maybe still now) I don't think many of the others were as small while still having features like downloading updates in multiple "threads". Also not sure if any of the others allow installing from a local directory of PKGBUILDs. Since I haven't used all of them I don't really know how it compares to everything out there. Not saying it's the greatest, but I think it has uses. On Tue, Oct 24, 2017 at 9:27 AM, <notify(a)aur.archlinux.org> wrote: > Alad [1] filed a deletion request for spinach [2]: > > Antiquated yaourt clone, sources PKGBUILDs for dependency resolution > before users can inspect them. Otherwise no unique functionality. > > [1] https://aur.archlinux.org/account/Alad/ > [2] https://aur.archlinux.org/pkgbase/spinach/ >

8 years, 1 month

[PRQ#37727] Deletion Request for chrysalis

by notify＠aur.archlinux.org

algernon [1] filed a deletion request for chrysalis [2]: I am the upstream maintainer and primary developer of Chrysalis, and I am requesting the deletion of the `chrysalis` package in that capacity. The major reason for the request is that the way this package is made completely breaks Chrysalis. Running with an external Electron is unsupported upstream to begin with, and results in Chrysalis not finding some of its static assets, such as the firmware files it is supposed to flash. This already breaks an important capability of the application. On top of that, the packaging upgrades Electron from version 17 to 19. This breaks pretty much every functionality of the package, because of breaking changes within Electron. We have intentionally stayed on Electron 17 upstream due to this reason. Anything higher introduces subtle bugs that simply do not exist with Electron 17. We will upgrade Electron once we verified that the regressions have been fixed, or if we figure out how to work them around. Due to these issues, and after numerous reports on our Discord by frustrated Arch users, we added a sanity check at startup, that verifies Chrysalis is running in a sane environment. For the past two releases, when installed via the `chrysalis` package in AUR, the application displays this screen on start: https://user- images.githubusercontent.com/17243/193005865-46313413-5ae7-46d4-b52b-8438c7… Running Chrysalis with an external Electron, one that is TWO MAJOR VERSIONS HIGHER than what is officially supported is never, ever going to work. Please remove the package, so it doesn't cause more confusion and frustration among Chrysalis users that happen to use Arch. If you need more information, you can email me at algernon(a)keyboard.io. Thanks in advance! [1] https://aur.archlinux.org/account/algernon/ [2] https://aur.archlinux.org/pkgbase/chrysalis/

3 years, 2 months

Re: [PRQ#43605] Deletion Request for advanced-rest-client-appimage

by Marcell Meszaros

There's already an AUR/advanced-rest-client for this. Upstream provides a DEB release, which can be more easily used to strip out the included Electron (Chromium) runtime. And these kinds of packages should have the '-bin' name suffix. On 5 July 2023 02:57:29 GMT+02:00, notify(a)aur.archlinux.org wrote: >MarsSeed [1] filed a deletion request for advanced-rest-client- >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/advanced-rest-client-appimage/

2 years, 4 months

Re: [PRQ#42292] Deletion Request for joplin-electron

by Marcell Meszaros

Hi @dianqk, Thank you for your feedback. I will revoke my deletion request promptly. I see that joplin-desktop declares electron as dependency, but then goes on an makes the package use the bundled Electron. Your package, on the other hand, gets this right and configures the usage of system Electron properly. It would be ideal in my opinion of you could cooperate with the maintainer of joplin-desktop, maybe request co-maintenance. You could help them improve that package. It has existed for much longer and therefore it is significantly more popular. And the package name makes more sense to users. Whereas your package is more advanced and optimal, and contains the Wayland IME enhancement as well. I think maintainers and users could benefit from your expertise if you advised popular Electron-based package owners on how to make use of the Arch repo electron and how to better integrate with desktop features like those provided via Wayland. Cheers, Marcell (Mars) On 18 June 2023 15:44:00 GMT+02:00, dianqk <dianqk(a)dianqk.net> wrote: >This is a different build version. Firstly, this version utilizes the system's Electron to save disk space. Additionally, it provides support for IME (Input Method Editor) under Wayland. > >On Sat, Jun 17, 2023, at 11:21 PM, notify(a)aur.archlinux.org wrote: >> MarsSeed [1] filed a deletion request for joplin-electron [2]: >> >> Duplicate of the also Electron-based AUR/joplin-desktop: >> >> https://aur.archlinux.org/packages/joplin-desktop >> >> And the latter has a better name, since AUR/joplin is a CLI version of >> this note-taking app, whereas the Electron-based ones are desktop GUI >> programs. >> >> [1] https://aur.archlinux.org/account/MarsSeed/ >> [2] https://aur.archlinux.org/pkgbase/joplin-electron/

2 years, 6 months

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