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

Re: [PRQ#63012] Deletion Request for nani

by Hans Müller

At this point it is more useful than sl which is also something called sometimes when users mistype a command. (And I would argue more useful than some scripts with "personal" in the description with pretty lacking descriptions that are in the AUR but tbf more of them turned up on the package search a few years ago so I guess you either actually go after them or they are vanishing for different reasons...) Maybe not that much, but you can now choose to let you show a quiz question before the start of nano. (Currently with lists for katakana and hiragana but I can easily expand it for lists for kanji within the following week) I can expand it with different learning content as well. Actually, since a few weeks after some longer break (see my GitHub contribution graph and codeberg profile) I'm working on getting older scripts I once wrote to get some of the functionality I once noted so that they are more useful in general. The recently submitted pdfgrep_sixel thing is such a case — the last real update I gave to the script behind that before working last week on it was four years ago. After the recent update I first submitted to the AUR since I determined it to be useful enough at that point. (Previously it had more problems depending on the TE, which is unfortunately the case due to different quality of sixel implementations.) I have a terminal emulator open with tabs for such projects and I'm working on them one after another. (However this doesn't mean I intend to add them onto the AUR. The huge majority of things I create stay only on GitHub or Codeberg and I only add something new to the AUR every few years). The nani script (that has at least three stars on GitHub, had a vote in the AUR and iirc somebody copied it to their custom Arch repo but I didn't find it yesterday evening after a quick search) would have surely gotten an overhaul in a few weeks if it wasn't for the surprising deletion request by a pretty new account that did only upload one AUR package and made one deletion request so far. If the person had contacted me, I could have told them that. And if that person was interested in getting the name, there could also have been a friendly contact with a potential positive outcome for that. Thanks for these friendly, motivating experiences... (This text was written before the other deletion requests that I find valid myself... just had to figure out how to be able to respond to this mailing list since this text didn't go through the first try.) <notify(a)aur.archlinux.org> schrieb am Do., 29. Aug. 2024, 11:25: > Muflone [1] filed a deletion request for nani [2]: > > trash/joke package not welcome in AUR. @schrmh please never upload > this jokes on the AUR again > > [1] https://aur.archlinux.org/account/Muflone/ > [2] https://aur.archlinux.org/pkgbase/nani/

1 year, 3 months

[PRQ#47521] Deletion Request for nvidia-pf

by notify＠aur.archlinux.org

MarsSeed [1] filed a deletion request for nvidia-pf [2]: It is not useful to keep this badly and sporadically maintained package. I've explained the problems in a comment in 2023-06, as well as in emails to the maintainer. He was unwilling to address those, and he still does not even regularly update the version. Also he updates his linux-pf package a bit more frequently than this - which in many cases breaks this package. My comment from 2023-06-22, the day of the last update: " This new version is wrong. It just repackages the current, fixed version of repo nvidia-dkms for the linux-pf kernel that is currently installed. The package will prevent pacman sysupgrade the instant repo pushes a new version update to nvidia-utils (because of this [*a] versioned depends). / As of now, it also has a bogus "linux-pf>" entry. / The installed package will also break when there is a new linux-pf update without a new nvidia-pf update. It can also potentially break if there is a simultaneous new linux-pf update and nvidia-pf bump, if the user just builds linux-pf without immediately installing it, then builds nvidia-pf, then wants to install both. (The reason behind the latter two issues is this line of PKGBUILD [*b], which was designed by repo maintainers for a specific setup of build steps - building, then installing the intended kernel version before creating the nvidia module package. It does not make sense to just copy-paste repo's solution to this AUR pkg.) It's better to just rely on nvidia-dkms, which will do the correct thing every time there's a new linux-pf update and/or an nvidia-dkms update, and won't ever prevent sysupgrade. My recommendation still stands: delete this package, no one has used it for the last 4 years, and no one needs to. " [*a]: https://tinyurl.com/nvidiapfPKGBUILDline10 (full URL: https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=nvidia- pf&id=41a9a1a8ff04697ba72292684aff010d3920336e#n10 ) [*b]: https://tinyurl.com/nvidiapfPKGBUILDline25 (full URL: https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=nvidia- pf&id=41a9a1a8ff04697ba72292684aff010d3920336e#n25 ) [1] https://aur.archlinux.org/account/MarsSeed/ [2] https://aur.archlinux.org/pkgbase/nvidia-pf/

2 years, 2 months

[PRQ#58235] Deletion Request for python-mod

by notify＠aur.archlinux.org

MarsSeed [1] filed a deletion request for python-mod [2]: Useless dead-on-arrival package, only reverse dependency is the similarly broken-from-day-one grok (deletion request submitted by @Muflone: PRQ#58232). ==> Starting build()... /usr/lib/python3.11/site-packages/setuptools/__init__.py:80: _DeprecatedInstaller: setuptools.installer and fetch_build_eggs are deprecated. !! ********************************************************************** Requirements should be satisfied by a PEP 517 installer. If you are using pip, you can try `pip install --use-pep517`. ********************************************************************** !! dist.fetch_build_eggs(dist.setup_requires) WARNING: The wheel package is not available. /usr/bin/python: No module named pip Traceback (most recent call last): File "/usr/lib/python3.11/site-packages/setuptools/installer.py", line 101, in _fetch_build_egg_no_warn subprocess.check_call(cmd) File "/usr/lib/python3.11/subprocess.py", line 413, in check_call raise CalledProcessError(retcode, cmd) subprocess.CalledProcessError: Command '['/usr/bin/python', '-m', 'pip', '--disable-pip-version-check', 'wheel', '--no-deps', '-w', '/tmp/tmp6tjq_fpq', '--quiet', 'pytest-runner']' returned non- zero exit status 1. The above exception was the direct cause of the following exception: Traceback (most recent call last): File "/build/python-mod/src/mod- df62c20c053024953a800b26d94599e10a1fdf38/ setup.py", line 35, in <module> setup( File "/usr/lib/python3.11/site-packages/setuptools/__init__.py", line 102, in setup _install_setup_requires(attrs) File "/usr/lib/python3.11/site-packages/setuptools/__init__.py", line 75, in _install_setup_requires _fetch_build_eggs(dist) File "/usr/lib/python3.11/site-packages/setuptools/__init__.py", line 80, in _fetch_build_eggs dist.fetch_build_eggs(dist.setup_requires) File "/usr/lib/python3.11/site-packages/setuptools/dist.py", line 636, in fetch_build_eggs return _fetch_build_eggs(self, requires) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/usr/lib/python3.11/site-packages/setuptools/installer.py", line 38, in _fetch_build_eggs resolved_dists = pkg_resources.working_set.resolve( ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/usr/lib/python3.11/site-packages/pkg_resources/__init__.py", line 829, in resolve dist = self._resolve_dist( ^^^^^^^^^^^^^^^^^^^ File "/usr/lib/python3.11/site-packages/pkg_resources/__init__.py", line 865, in _resolve_dist dist = best[req.key] = env.best_match( ^^^^^^^^^^^^^^^ File "/usr/lib/python3.11/site-packages/pkg_resources/__init__.py", line 1135, in best_match return self.obtain(req, installer) ^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/usr/lib/python3.11/site-packages/pkg_resources/__init__.py", line 1147, in obtain return installer(requirement) ^^^^^^^^^^^^^^^^^^^^^^ File "/usr/lib/python3.11/site-packages/setuptools/installer.py", line 103, in _fetch_build_egg_no_warn raise DistutilsError(str(e)) from e distutils.errors.DistutilsError: Command '['/usr/bin/python', '-m', 'pip', '--disable-pip-version-check', 'wheel', '--no- deps', '-w', '/tmp/tmp6tjq_fpq', '--quiet', 'pytest-runner']' returned non-zero exit status 1. ==> ERROR: A failure occurred in build(). Aborting... [1] https://aur.archlinux.org/account/MarsSeed/ [2] https://aur.archlinux.org/pkgbase/python-mod/

1 year, 8 months

Re: [aur-requests] Rules evasion: repeatedly re-uploading deleted packages (Was: [PRQ#23352] Deletion Request for rtl8821ce-dkms)

by Eli Schwartz

On 1/28/21 5:57 PM, Doug Newgard via aur-requests wrote: > On Thu, 28 Jan 2021 22:49:58 +0000 > notify--- via aur-requests <aur-requests(a)lists.archlinux.org> wrote: > >> alium [1] filed a deletion request for rtl8821ce-dkms [2]: >> >> hi, >> rtl8821ce-dkms use git source (but -git suffix missing) and it is >> practically the same package as >> https://aur.archlinux.org/packages/rtl8821ce-dkms-git/ (maintained by >> driver developer). So there are two package, which are same. >> >> Thank you. >> >> [1] https://aur.archlinux.org/account/alium/ >> [2] https://aur.archlinux.org/pkgbase/rtl8821ce-dkms/ > > It has also been deleted twice already, and the maintainer keeps re-uploading > it. > > https://lists.archlinux.org/pipermail/aur-requests/2020-December/047147.html > https://lists.archlinux.org/pipermail/aur-requests/2020-December/047680.html > > Along with the -lts variants (seriously, and dkms package for the -lts kernel). I agree that this should not be done, and I'm not sure why it was re-uploaded after being deleted for good reason. If a package is deleted by a Trusted User, it MUST NOT be re-uploaded unless the person re-uploading it is confident that the reason it was originally deleted no longer applies. Knowingly and intentionally violating this qualifies as rules evasion and will not be tolerated. It is the responsibility of the person wishing to re-upload the package to verify that it is reasonable to re-upload (e.g. deleted due to lack of interest rather than being a violation of the rules of submission). I strongly recommend doing your due diligence. If in doubt, ask a Trusted User on the mailing list or in Freenode IRC's #archlinux-aur channel. Mounir Erhili, I'll give you the benefit of the doubt and assume you overlooked the email alert that the package was deleted, and you git pushed without realizing it was removed. Twice in a row. :/ However, I will require your written confirmation that you realize the problem, will be more careful in the future, and this will not occur again. I've suspended your account for now, so you will not be able to accidentally or deliberately repeat the infraction before seeing this email. Please respond to this email and confirm that you've received the warning. Then I will agree to re-enable your account. -- Eli Schwartz Bug Wrangler and Trusted User

4 years, 10 months

Re: [PRQ#43382] Deletion Request for openblas-lapack

by Guillaume Horel

Openblas is a performance oriented package, microarchitecture optimization is exactly what it's about. Moreover this PKGBUILD has different build options than the official one which is allowed by the guidelines. On Mon, Jul 3, 2023 at 11:32 AM Marcell Meszaros <marcell.meszaros(a)runbox.eu> wrote: > > The package in community provides the dynamic arch version, whereas this > one will be specifically tuned for your current architecture. > > But this is not a good enough reason to keep PKGBUILDs for the same source > in both Arch repo and on AUR. > > Arch is not a binary-only distribution: all the build scripts are availabe. > > One can always grab a couple of PKGBUILDs from Arch repo's GitLab for > fine-tuned, microarchitecture-optimized rebuild, if that is what they want. > > But AUR submission guidelines are quite clear: they don't mention allowing > duplication for this purpose. > > > On 2 July 2023 17:34:03 GMT+02:00, Guillaume Horel < > guillaume.horel(a)gmail.com> wrote: > >> This is not the exactly the same package. The package in community >> provides the dynamic arch version, whereas this one will be specifically >> tuned for your current architecture. >> I've responded in the comments that there is nothing broken at the moment >> with this package, and I don't see the need to delete it. >> >> On Sun, Jul 2, 2023 at 7:17 AM <notify(a)aur.archlinux.org> wrote: >> >>> MarsSeed [1] filed a deletion request for openblas-lapack [2]: >>> >>> Same package is now in [extra], named blas-openblas: >>> >>> https://archlinux.org/packages/extra/x86_64/blas-openblas/ >>> >>> See announcement about it: >>> https://archlinux.org/news/openblas-0323-2-update-requires-manual- >>> intervention/ >>> <https://archlinux.org/news/openblas-0323-2-update-requires-manual-intervent…> >>> >>> I have notified AUR maintainers in comments about their need to review >>> this change, and possibly adapt their PKGBUILD's. >>> >>> [1] https://aur.archlinux.org/account/MarsSeed/ >>> [2] https://aur.archlinux.org/pkgbase/openblas-lapack/ >> >>

2 years, 5 months

Re: [aur-requests] [PRQ#15312] Orphan Request for qbittorrent-dark-git

by Vladislav Suratov

Sure, Plasma forces Qt applications to look in the same way, but Gnome doesn't have such ability by default, and qBittorent looks very bright. Maintainers of this project refused this request (as well as change) from me https://github.com/qbittorrent/qBittorrent/pull/5076 and I support it for AUR and Windows with my fork, which is this current package. So, I am not happy for deletion request and I ask you to cancel this request. P.S. They are going to add probably add this https://github.com/qbittorrent/qBittorrent/pull/10702 but I don't think I will stop to support my fork. On Fri, Jun 28, 2019 at 3:44 PM Yurii Kolesnykov <root(a)yurikoles.com> wrote: > qBittorrent 4.1.6 honors KDE Plasma Dark Mode, I haven't checked in GNOME. > > пт, 28 черв. 2019 о 14:47 Vladislav Suratov <suratovvlad(a)gmail.com> пише: > > > > Hi Yurii, > > > > What do you mean about dark mode in stable? > > Have they added it to the 4.1.6? or released 4.2.0 already? > > > > On Fri, Jun 28, 2019 at 2:33 PM <notify(a)aur.archlinux.org> wrote: > >> > >> yurikoles [1] filed a orphan request for qbittorrent-dark-git [2]: > >> > >> Dark mode already in stable and obviously git. > >> > >> [1] https://aur.archlinux.org/account/yurikoles/ > >> [2] https://aur.archlinux.org/pkgbase/qbittorrent-dark-git/ >

6 years, 5 months

Re: [PRQ#62896] Deletion Request for gnuplot4

by frazar0＠hotmail.it

Dear MarsSeed, as the current maintainer of the gnuplot4 package, I would like to thank you for bringing these issues to my attention. I will try to address each point, reporting the excerpts from your email in bold: */> Dependency chain (of wxgtk2.8) is broken. /*Could you please elaborate more on what you mean with "broken"? I just tried to compile the wxgtk2.8 package and I was able to build a package in a clean chroot. If you encountered a build issue, I invite you to report it in the comments section for the wxgtk2.8 package, and I will try to address it as soon as possible. */> The latest version of this utility software is available in Arch/extra > repo, and provides more features, not less./* Unfortunately, the latest version of gnuplot (v6.0.1) is not fully backward compatible with gnuplot v4 (among other changes, the default colors differ). Having an AUR package for a legacy version of a software can be crucial for reproducing old plots. Additionally (and please do correct me if I'm wrong, I'm not an expert), the sole fact that a package is outdated does not imply that it should not be available in AUR. Consider for example the "gcc43" package. The latest GCC version is indeed available in the official repositories, and they offer more features, but there is still value in providing the legacy version. *> Also AUR has GUI-less variants, for interactive CLI usage > (AUR/gnuplot-nogui) as well as headless (scripted) usage (AUR/gnuplot- > headless).* Unfortunately, as far as I know, none of the mentioned packages provides a fully backward-compatible way of re-generating old plots. I thank you again for raising the above points, and I completely understand the need to balance the maintenance burden between new and old software. If the final decision of the AUR maintainers is to delete the package, I will surely comply. The only reason I submitted the package is because I hoped others could share my work and take advantage of it. With my best regards, Francesco ------------------------------------------------------------------------ *From:* notify(a)aur.archlinux.org *Subject:* [PRQ#62896] Deletion Request for gnuplot4 *Date:* Wednesday, August 28, 2024 at 13:41 UTC+2 *To:* aur-requests(a)lists.archlinux.org *Cc:* frazar0(a)hotmail.it, marcell.meszaros(a)runbox.eu > MarsSeed [1] filed a deletion request for gnuplot4 [2]: > > Dependency chain (of wxgtk2.8) is broken. > The latest version of this utility software is available in Arch/extra > repo, and provides more features, not less. > > Also AUR has GUI-less variants, for interactive CLI usage > (AUR/gnuplot-nogui) as well as headless (scripted) usage (AUR/gnuplot- > headless). > > [1]https://aur.archlinux.org/account/MarsSeed/ > [2]https://aur.archlinux.org/pkgbase/gnuplot4/

1 year, 3 months

Re: [PRQ#54226] Deletion Request for ly-git-openrc

by jahway603

I was not aware of that, so thank you for sharing that insight with me Robin. What I am aware of is that when I search the AUR for "-openrc" that the result yields 83 results meaning there are 83 packages which utilize OpenRC as their init system, including my package in question here. Marcell's argument that "This package was intended for a systemd-less Arch derivative, and is not useful on Arch Linux, due to the fact that it is virtually impossible nowadays to run Arch without systemd..." is not valid as Arch Linux gives us the freedom to run whatever init system we choose to run. The power of Arch Linux is to enable the user to be able to use whatever they choose. If Marcell's logic to delete this package is to remain valid then are there also plans to delete the other 82 packages using OpenRC from the AUR? And are there also plans to delete the Arch Wiki page about OpenRC (https://wiki.archlinux.org/title/OpenRC)? On Tuesday, February 27th, 2024 at 11:50 AM, Robin Candau <antiz(a)archlinux.org> wrote: > On 2/27/24 16:38, jahway603 wrote: > > > THIS SHOULD NOT BE DELETED as the AUR is used by Arch and ALL derivatives of Arch, like Artix, Manjaro, EndeavourOS, etc. > > The AUR has been made by Arch Linux for Arch Linux. Derivatives are > not supported and packages made specifically for such distros are > not allowed. > So, regardless of the below request and whether it will lead to a > deletion of the package or not, the above argument is not relevant. > > > On Monday, February 26th, 2024 at 2:11 PM, notify(a)aur.archlinux.org notify(a)aur.archlinux.org wrote: > > > > > MarsSeed [1] filed a deletion request for ly-git-openrc [2]: > > > > > > Problematic, but unneeded VCS package with wrong name, missing > > > provides field and pkgver() function. > > > > > > The stable ly package is carried by extra repo, and there is a proper > > > ly-git on AUR. > > > > > > This package was intended for a systemd-less Arch derivative, and is > > > not useful on Arch Linux, due to the fact that it is virtually > > > impossible nowadays to run Arch without systemd (hence the other > > > distros). > > > > > > [1] https://aur.archlinux.org/account/MarsSeed/ > > > [2] https://aur.archlinux.org/pkgbase/ly-git-openrc/ > > > -- > Regards, > Robin Candau / Antiz

1 year, 9 months

Re: [aur-requests] [PRQ#16875] Deletion Request for gtk3-classic

by Robin Broda

On 12/3/19 9:13 PM, Eli Schwartz via aur-requests wrote: > On 12/3/19 2:27 PM, Jonathon Fernyhough wrote: >> On 03/12/2019 18:26, notify(a)aur.archlinux.org wrote: >>> rober_k [1] filed a deletion request for gtk3-classic [2]: >>> >>> this is an identical package as gtk3-mushrooms . >>> It pulls from the same repo, only is newer. >>> Proper way would be to mark gtk3-mushrooms out-of-date, not just >>> upload a different package with same content ;) >>> >>> [1] https://aur.archlinux.org/account/rober_k/ >>> [2] https://aur.archlinux.org/pkgbase/gtk3-classic/ >>> >> >> It's not a simply a more up-to-date package. The source repo is the same >> but gtk3-classic is essentially a forked gtk3-mushrooms which adds >> experimental/developmental (?) aspects to the PKGBUILD which the >> original does not (e.g. use of meson and quilt, see e.g. [1]). > > "Use quilt and meson" is not a valid reason to upload a new PKGBUILD. > The resulting package does not care what technology you use for applying > patches, and it *should* not care whether you use autotools or meson to > generate a series of compilation commands. > > Is there something that the resulting .pkg.tar.xz does, which is > different from "gtk3-mushrooms"? > > If it is just about the lib32-* variant, you can just upload a > lib32-gtk3-mushrooms package inspired by > https://git.archlinux.org/svntogit/community.git/tree/trunk/PKGBUILD?h=pack… > >> Also, technically the gtk3-mushrooms package is not out-of-date as the >> upstream is still at 3.24.11. >> >> If all of this is potentially too confusing let me update the PKGBUILD >> to use a different source rather than having the package deleted. > > I don't think changing the url= field makes a difference, if that is > what you mean. > >> [1] https://github.com/krumelmonster/gtk3-mushrooms/pull/26 >> > > As far as i could see by a quick inspection there does appear to be a difference in the patches applied as well, hence me rejecting the request. If this is actually not the case, we might have to revisit my decision -- Rob (coderobe) O< ascii ribbon campaign - stop html mail - www.asciiribbon.org

6 years

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

by dianqk

Hi Marcell (Mars), I apologize for the delayed response. The packaging of Joplin Desktop is closer to the official approach. On top of that, I have made several additional patches, switching from electron19 to electron22 and modifying the Joplin source code to support IME startup parameters. These modifications have not been thoroughly tested, and I'm unsure if integrating the system's electron alone will work correctly. However, everything appears to be OK in my local usage. I think we can wait until Joplin's official team makes relevant upgrades and changes before considering whether Joplin Desktop can be updated to use the system's electron. Cheers, dianqk On Sun, Jun 18, 2023, at 10:31 PM, Marcell Meszaros wrote: > 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, 5 months

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