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

Re: [aur-requests] [PRQ#8414] Merge Request for openshift-origin-bin

by Óscar García Amor

Hi Jeremy, That's good. But take note that you cannot rename AUR packages, you can only add the new ones with the new name and make a request of deletion of old ones [1]. Greetings. [1]: https://lists.archlinux.org/pipermail/aur-general/2011-June/014866.html 2017-07-05 19:19 GMT+02:00 Jeremy Asuncion <jeremyasuncion808(a)gmail.com>: > That makes sense. I'll make sure to rename my package as soon as I get home > from work. > > Thanks! :) > > Best regards, > Jeremy. > > On Tue, Jul 4, 2017 at 11:35 PM, Óscar García Amor <ogarcia(a)moire.org> > wrote: >> >> Ok, then in this case the name of package is wrong. Must be >> openshift-origin-server-bin to avoid the confusion with the client, >> must provide origin-client-bin and have conflicts with them. >> >> I think that there is a little mess with the names of packages. IMHO >> the packages must be renamed as: >> - origin-client-bin -> openshift-origin-client-bin >> - openshift-origin-bin -> openshift-origin-server-bin >> - openshift-source-to-image -> openshift-origin-source-to-image-bin >> - openshift-origin-git -> openshift-origin-server-git >> >> The rest of openshift packages are duplicates: >> openshift-origin-client-tools (outdated and newer than his duplicate) >> is the same that origin-client-bin >> openshift-origin-source-to-image (outdated and newer than his >> duplicate) is the same that openshift-source-to-image >> >> Greetings. >> >> 2017-07-04 20:54 GMT+02:00 Jeremy Asuncion <jeremyasuncion808(a)gmail.com>: >> > origin-client-bin only includes the client tool, oc. >> > openshift-origin-bin >> > includes the openshift server. >> > >> > Thanks! :) >> > >> > Best regards, >> > Jeremy. >> > >> > On Sun, Jul 2, 2017 at 4:28 AM, <notify(a)aur.archlinux.org> wrote: >> >> >> >> ogarcia [1] filed a request to merge openshift-origin-bin [2] into >> >> origin-client-bin [3]: >> >> >> >> Are the same package >> >> >> >> [1] https://aur.archlinux.org/account/ogarcia/ >> >> [2] https://aur.archlinux.org/pkgbase/openshift-origin-bin/ >> >> [3] https://aur.archlinux.org/pkgbase/origin-client-bin/ >> > >> > >> >> >> >> -- >> Óscar García Amor | ogarcia at moire.org | http://ogarcia.me > > -- Óscar García Amor | ogarcia at moire.org | http://ogarcia.me

8 years, 1 month

Re: [PRQ#70945] Merge Request for openshift-codeready-bin

by Rubin

Hi all, So I've semi-recently had to do some work on an OpenShift-based platform, so I packaged a couple of at-the-time missing packages. At the time, I searched AUR for "openshift" related packages and found the "openshift-client-bin" package, which contains the oc command. I needed to work with tekton, codeready and odo, so I figured: "let me add the missing clients in the same vein as openshift-client-bin". So I added "openshift-developer-bin" for the 'odo' command, openshift-pipelines-bin for the 'opc', 'tkn' and 'tkn-pac' commands and openshift-codeready-bin for the 'crc' command (crc stands for code-ready-containers). It turned out that there is a crc-bin package already. I didn't catch that at the time, and now I have this merge-into-theirs (crc-bin) request. This is fine in principle, but I do think it is a better experience for ArchLinux and AUR users if they can find openshift-related packages simply by looking for openshift in the package name instead of for a specific binary, plus, not unimportantly, some of these clients (pipelines) consist of mutiple binaries, hence my thinking that simply "binary + name" might not be the best naming convention in this case. So I'm not sure if my voice has any weight here, and I'm not sure what is the best way forward: * Do nothing, just abandon my variant? * Or should I engage (how? where? with whom?) and try to work for a bit of naming consistency? In any case, the re-upload of this package was by accident a couple of months ago (I have a script that iterates over my packages and uploads after I've done changes, and I left this directory in the wrong place, leading to it being re-uploaded - I thought that would be impossible, and/or that the package would be hidden, but it turns out it actually got re-created). I also asked on #archlinux-aur but I didn't get any response (yet). Kind regards, Rubin! On Sunday, March 9th, 2025 at 13:22, Marcell Meszaros <marcell.meszaros(a)runbox.eu> wrote: > > > On 9 March 2025 11:15:24 GMT+01:00, notify(a)aur.archlinux.org wrote: > > > pfeifferj [1] filed a request to merge openshift-codeready-bin [2] > > into crc-bin [3]: > > > > duplicate > > > > [1] https://aur.archlinux.org/account/pfeifferj/ > > [2] https://aur.archlinux.org/pkgbase/openshift-codeready-bin/ > > [3] https://aur.archlinux.org/pkgbase/crc-bin/ > > +1 for either deletion or merge. > > Moreover, the same openshift-codeready-bin package has already been deleted once, because the upstream software name is 'crc'. [1] > > [1]: https://lists.archlinux.org/archives/list/aur-requests@lists.archlinux.org/…

5 months

Re: [PRQ#65702] Deletion Request for kdeplasma-blurredwallpaper-git

by Bouteiller Alan

Hello, - I'm not the author of the plasma6-wallpapers-blurredwallpaper package, but I'm the author of the github repository. And historically I maintain the AUR package, and for obvious reason I want to keep maintaining the AUR package for my work, plus this package is out of date with the version of my work on github, what I can do about that? The guy built this package while I was migrating the AUR and the source between plasma 5 and 6 without ever contacting me before doing it. - I followed the wiki for building my package (https://wiki.archlinux.org/title/Arch_package_guidelines#Package_sources) I'm a little bit lost about what I have to do between what the wiki says and what you have written in your email: - If I have to take an example, is this package good: https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=python-shgo-git? - For the following "provides, conflicts, and depends" I do not see why I have to put the "provides" in my package. I understand that conflicts may contain the plasma6 package from dr460nf1r3 and that depends must contain plasma-workspace. - If I update my code on github (let's say to v4) with a well written VCS package, I just need to update the pkgver key, right? Thanks for all your answers, I'm doing this for fun, but I want to do it properly, so sorry if my questions sound silly. I'm also going to update the kdeplasma-arch-update-notifier-git package because it has the same kind of problem in it. Best. Alan Bouteiller Reach me @linkedin Or via my website alanbouteiller.pm On Thursday, 14 November 2024 at 6:59 AM, notify(a)aur.archlinux.org <notify(a)aur.archlinux.org> wrote: > MarsSeed [1] filed a deletion request for kdeplasma-blurredwallpaper- > git [2]: > > Not a VCS package: uses a fixed git tag as source. > Also missing its mandatory provides, conflicts, and depends. > > Does not follow Arch KDE package naming guidelines. [a] > > Please keep only the correctly named and packaged > AUR/plasma6-wallpapers-blurredwallpaper [b] for the same stable git > tag. > > If you want to maintain a rolling VCS package for the main branch, > please do the following: > - take the latter package as a starting point, > - declare provides and conflicts arrays containing the pkgname > 'plasma6-wallpapers-blurredwallpaper', > - specify the git repo as source but without the "#tag=" fragment in > the URL, > - and submit it under the name 'plasma6-wallpapers-blurredwallpaper- > git'. > > [a]: > https://wiki.archlinux.org/title/KDE_package_guidelines#KF_package_naming > [b]: > https://aur.archlinux.org/packages/plasma6-wallpapers-blurredwallpaper > > [1] https://aur.archlinux.org/account/MarsSeed/ > [2] https://aur.archlinux.org/pkgbase/kdeplasma-blurredwallpaper-git/

8 months, 4 weeks

Re: [aur-requests] [PRQ#11354] Deletion Request for firefox-always-nightly

by Félix Saparelli

Yeah, I'm deliberately in contravention of the rules and style of AUR to get those advantages. Also note it's not really a "new" package (four years)! But I understand if it gets deleted. Although, if it does get picked for deletion is there a way I could request a stay of execution? I'm investigating an alternate solution that wouldn't rely on the AUR at all, and therefore wouldn't push against its rules, but it's going to take a while (~1 month?) to get set up, and if I could offer a good transition strategy to those who like this flavour, then voluntarily kill it, that would probably be a better user experience. On Fri, May 11, 2018 at 9:49 AM Morgan Adamiec <morganamilo(a)gmail.com> wrote: > On 10 May 2018 at 22:36, Félix Saparelli <felix(a)passcod.name> wrote: > > How do I tell this request to, politely, go away? > > > > always-nightly has a number of differences to -nightly, not just the > > "always" part of it. But if this is the main point of difference, then I > > contest the claim that -nightly has "pretty good tracking". As a blatant > > example, right now it is on 62.0a1.20180509, while always-nightly > downloads > > 62.0a1.20180510. > > > > There is also the fact that firefox nightly updates twice a day, not > once, > > so the -nightly package is never accurately tracking the latest. > > > > Some more occurences from the firefox-nightly comments: > > > > owstoni commented on 2017-08-02 22:15 > > > > 57 is out, could you post the new source? > > > > K900 commented on 2017-08-02 14:40 > > > > 57.0a1 is out now, needs a version bump. > > > > > > tux-86 commented on 2017-07-21 20:11 > > > > Version string seems now 56.0a1.-1 > > > > > > That's two fairly recent occasions where firefox-nightly was behind. The > 57 > > one shows no update in 8 hours at least. Firefox-always-nightly would > have > > produced the right version within a few minutes of the update actually > going > > out. That is why it exists. > > > > > > On Fri, May 11, 2018 at 9:15 AM <notify(a)aur.archlinux.org> wrote: > >> > >> Morganamilo [1] filed a deletion request for firefox-always-nightly > >> [2]: > >> > >> Duplicate of aur/firefox-nightly > >> > >> See https://lists.archlinux.org/pipermail/aur- > >> general/2018-May/034080.html > >> > >> [1] https://aur.archlinux.org/account/Morganamilo/ > >> [2] https://aur.archlinux.org/pkgbase/firefox-always-nightly/ > > I would think the rules on this would say it's still a duplicate. If > there's problems they should be fixed, not have a new package pop up. > Your PKGBUILD does a lot of hacky stuff that I don't know how to feel > about it. using curl for global variables. Forcing an insanely high > pkgver so that it always wants to update. > > It's not up to me though. I brought this up briefly in the linked > thread and Eli seemed to agree so I thought I would send this request > and see what happens. > >

7 years, 3 months

Re: [aur-requests] [PRQ#25316] Deletion Request for multimc-lhaus-git

by Christopher Snowhill (kode54)

From what I've gathered from watching the list on these launchers, at least the official TLauncher Legacy: Apparently, the AUR doesn't like to get into enforcing end user license agreements, or EULAs, and tracks that EULAs are not legally enforceable. I'm not entirely sure where to stand on this issue, since the launchers are not supplying the pirated game, only allowing downloading it from Microsoft's own servers, using the same method as the official launcher, which doesn't guard this download process behind any DRM. The only thing they do which may be considered a circumvention device, is spoof the authentication or session information to the game's own API calls, so that it will actually run and think that it's genuinely connected to Microsoft's servers and authenticated with either a Mojang or a Microsoft account via the launcher. They also spoof the email address or user name that allegedly authenticated, so technically you could try to connect to any Minecraft server as any user that you want, and it will just generate an arbitrary deterministic UUID for your fake account when you "log in" to offline mode. So, not so much just an EULA violation, but also a copy protection circumvention device. Feel free to correct me if I'm wrong. Anyone who is willing to, is welcome to use a VM or something to install all these various launchers one by one and verify whether they let you play the game "offline", and if so, if that can just connect to arbitrary Minecraft servers using a spoofed deterministic UUID. Then we can decide whether it's in the AUR's best interest to ban these clients, or just stick to saying "we only host the recipe to install and/or build the app, not our problem". > On Jul 19, 2021, at 5:23 AM, xcfrg <xcfrg(a)protonmail.com> wrote: > > That launcher does indeed support "offline mode" but my request for the package seemed to get denied because "it wasn't hosted on the aur". That doesn't make any sense, the package is still on the aur and at the very least, it's enabling piracy. > ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ > On Saturday, May 8th, 2021 at 4:23 PM, Christopher Snowhill <kode54(a)gmail.com> wrote: >> >> While we're narcing on Minecraft launchers, may as well look into tlauncher as well, I hear that one's been on AUR since at least 2015, and possibly supports the same "offline" mode. >> >> >> >> On Thursday, May 06, 2021 at 6:59 PM, notify--- via aur-requests <aur-requests(a)lists.archlinux.org <mailto:aur-requests@lists.archlinux.org>> wrote: >> xcfrg [1] filed a deletion request for multimc-lhaus-git [2]: >> >> This package allows one to play minecraft without purchase in full >> (not demo mode), making it illegal and piracy. You can find the >> offending code here, >> https://github.com/lhaus/MultiMC/commit/1642383dcfe9f9e4b0edfb49b6e6803e3c7…. >> >> [1] https://aur.archlinux.org/account/xcfrg/ >> [2] https://aur.archlinux.org/pkgbase/multimc-lhaus-git/ >

4 years

Re: [PRQ#45699] Merge Request for archey3-git

by Marcell Meszaros

> You are lying. > > He did not comment about the merge request. You are not quoting him on that because he did not comment specifically on it. You mentioned the proposed merge to the archey3 dev and asked, among other things, if he would support in any way the archey4 fork. And he replied summarily with "Ship it!". Which means "Go ahead!", in case you misunderstood. On 4 August 2023 11:23:56 GMT+02:00, Gaspard d'Hautefeuille <gaspard(a)dhautefeuille.eu> wrote: >You are lying. > >He did not comment about the merge request. You are not quoting him on that because he did not comment specifically on it. > >He said he will no longer develop archey3 and that he will soon archive his repo. > >https://github.com/lclarkmichalek/archey3/issues/52#issuecomment-1663777320 > >Arguments against the merge request: > >1) archey3 is on the wiki <https://wiki.archlinux.org/title/Archey3>, not archey4 >2) archey3 is maintained in the [extra] repo <https://archlinux.org/packages/extra/any/archey3/>, not archey4 >3) archey3-git is maintained on the AUR <https://aur.archlinux.org/packages/archey3-git>, there is no such thing as archey4-git >4) archey3-git is up-to-date with the upstream repo <https://github.com/lclarkmichalek/archey3> >5) archey3-git has 171 votes, archey4 has 16 votes >6) archey3 and archey4 are forks from different authors, so votes & comments should not be merged (stolen) into a whole different package > >Argument for deletion: > >1) The archey3 author has said he will archive his repo and will no longer maintain archey3 <https://github.com/lclarkmichalek/archey3/issues/52#issuecomment-1663777320> > >Arguments against deletion: > >1) I contacted the TU Alexander Rødseth that maintains the [extra] archey3 package, he would need to consider maintaining archey4 in [extra] rather than archey3 before we consider for deletion archey3-git >2) When the TU does that, I would need to start maintaining archey4-git, before I submit for deletion archey3-git > >> On 4 Aug 2023, at 11:17, Marcell Meszaros <marcell.meszaros(a)runbox.eu> wrote: >> >> Maintainer @HLFH also asked the archery3 fork's developer if he plans to get back to it and develop it further, and he replied that he won't be doing so any longer, and in fack he only considers archiving the repo. His "archeying days are over", he said. [a] >> >> The developer also indicated he has no objection to the AUR package merge and of the "stealing" (@HLFH's choice of word) of the votes and comments by the "hippies like MarsSeed" (again @HLFH's characterisation). >> >> Arch repo's archey3 carries the exact same code from 2018 as archey3-git. >> >> Only the archey4 fork is maintained. >> >> Please note that I am not affiliated with archey4 in any way, I have no intention of stealing anything, and I guess being a hippie is not such a bad thing after all. :) >> >> [a]: https://github.com/lclarkmichalek/archey3/issues/52 >> >> On 1 August 2023 17:26:43 GMT+02:00, notify(a)aur.archlinux.org wrote: >>> MarsSeed [1] filed a request to merge archey3-git [2] into archey4 >>> [3]: >>> >>> As discussed with maintainer @HLFH in comments 10+ months ago, this >>> application has been superseded by continuation fork archey4. He >>> posted a link to the new AUR package then, so users should be well- >>> informed at this point. >>> >>> Archey3 has not been developed since 2018. [a] >>> >>> Arch repo still carries the last archey3 (however, devs would be >>> advised to consider adopting archey4 to [extra]). >>> >>> Though archey3-git is a VCS package and AUR/archey4 is not, there's no >>> VCS package for the latter but it would still be good to migrate the >>> high number of votes and comments to the successor application's >>> package rather than just deleting them. >>> >>> AUR/archey3-git is defunct so there's no harm in removing that in >>> favor of archey4. >>> >>> [a]: https://github.com/lclarkmichalek/archey3/commits/master >>> >>> [1] https://aur.archlinux.org/account/MarsSeed/ >>> [2] https://aur.archlinux.org/pkgbase/archey3-git/ >>> [3] https://aur.archlinux.org/pkgbase/archey4/ >

2 years

Re: [PRQ#52086] Deletion Request for libsrsbsns

by Marcell Meszaros

On 13 December 2023 12:12:32 GMT+01:00, heinrich5991(a)gmail.com wrote: >On 12/10/23 14:27, notify(a)aur.archlinux.org wrote: >> MarsSeed [1] filed a deletion request for libsrsbsns [2]: >> >> Unneeded, discontinued joke library from 2013. [a] >> >> Just read upstream repo's "About" section to see it's BS [b]: >> " >> Award winning unique innovative solution for cutting edge >> revolutionary business application. Feature rich robust scalable >> platform provides seamless and user-friendly out-of-box experience. >> State of art next generation cloud ecosystem leverages best practices >> for sustainable real-time performance. De-facto industry standard and >> 42% more serious… >> " >> >> Also see todo list created by co-developer [c]: >> ( ) Create a todo list asap (As Srs As Possible) >> (*) Check some boxes to indicate a thriving bsns activity >> ( ) ????? >> ( ) PROFIT >> >> [a]: https://github.com/srsbsns/libsrsbsns/tags >> [b]: https://github.com/srsbsns/libsrsbsns >> [c]: https://github.com/srsbsns/libsrsbsns/issues/3 >> >> [1] https://aur.archlinux.org/account/MarsSeed/ >> [2] https://aur.archlinux.org/pkgbase/libsrsbsns/ > >While the description is indeed a joke, the library contains data structures etc. implemented in C. It's not a joke library AFAIK. > >Where do I respond to this ticket properly? > >Kind regards, >heinrich5991 Uh, hi, I'm terribly sorry that I missed your response. But indeed I have receive your message through the mailing list, so it is a proper form of reply. Just for clarification, I am just a fellow AUR user and not at all any kind of authority figure here. I was going through the AUR packages looking for potentially unneeded ones. Since you have expressed that this package is legit, can you maybe elaborate on what is the use case of this library? E.g., what do you personally use it for? And what does it offer to AUR users? I see that it was submitted to the current AUR database on 2015-06-19, and has 3 votes. Upstream's last git tag, v0.0.1 was created on Jul 4, 2013, and the devel branch has 210 newer commits, with the last one created ~4.5 years ago, on Nov 15, 2019. But from the looks of the code, the readme, the repo, the few (already accepted or closed) pull requests, and the few issues, everything seems to be a joke, or belonging to someone's personal learning sandbox rather than any focused and purpose-made project. On AUR there are no comments, and no reverse dependencies. I personally am not opposed to keeping this package, but on the other hand, if it does not offer anything that other AUR users benefit from, then by AUR submission guidelines it is not something worth having here. Thank you in advance for any insight you can provide on the utility and merits of this library! Cheers, Marcell / MarsSeed

1 year, 4 months

Re: [PRQ#69725] Deletion Request for kubectl-bin

by GeorgeRaven

Hey Vitalii, I understand different cultures or customs approach these things differently, however I am culturally British, and I found your opening language in your package comments needlessly combative. I appreciate and accept your apology, however I still contest this deletion request, this is not the way to suggest improvement or fixes to problems that may exist in the packages. I appreciate you have now added more constructive comments elsewhere, which I will follow up on shortly. Lastly, I am not opposed to deleting genuinely useless packages if they were not useful to me, and I did not expect them to be reasonably useful to others. Thanks, Dr. GO For genuine in-good-faith clarity, the offending / inflammatory statements are: - "What is the point of this package?" is very pejorative, and is the opening sentence of which you wrote in our first contact, "What drove you to make this package if it already exists?" could have been more conducive to productive discussion as it is less accusatory. - "If the package is any different (it's not)" for a native English speaker portrays a certain level of disregard / disrespect. Alternatively, you could have said, "I do not believe adding kubectl to be necessary as X." - or describing aspects of what I have made or do as "pointless" which could have arbitrarily been chosen differently but in conjunction with the rest I likely took in bad faith. A term like "fruitless" or "unnecessary" may have been preferable, but this one is largely context driven. Along with the sudden, spurious escalation of these deletion requests, I found the sum total of your actions to be needlessly combative / inflammatory. I hope that helps brings some clarity to my perspective, so you do not feel it is a random or unreasonable response. On Monday, February 10th, 2025 at 9:45 PM, Vitalii Kuzhdin <vitaliikuzhdin(a)gmail.com> wrote: > Greetings, > > The reason I submitted multiple requests was to have unique PRQs (see the subject of the automated email) assigned to each, so that there is a precedent for a Package Maintainer action. Please don't consider it as spam; I wasn't trying to flood your inbox. > > I'll leave a few more of my points in the comments, though obviously, the decision will be made by a Package Maintainer. However, the ultimate reason why I'm writing this email here is to address the 'inflammatory language' you mentioned. I honestly do not see where I have used such language, and you can be sure I didn't mean it even if there was indeed something harsh. Re-reading, I can only see myself addressing each point that you made and even giving you advice on one. Obviously, I am not a professional to be teaching others, but I also had the same issues with managing architectures in my first package, so I thought I'd leave a link to the wiki to help you. > > Again, I'm sorry that I made you feel this way. I hope this email has cleared things up and we can move forward constructively. > > Vitalii > > On Mon, Feb 10, 2025 at 10:24 PM GeorgeRaven <GeorgeRavenCommunity(a)pm.me> wrote: > > > Hey, > > > > This user has spuriously opened a deletion request for this and a few other multi-arch packages I manage for Kubernetes, namely: > > > > - kubectl-bin > > - kubeadm-bin > > - kubelet-bin > > - cni-plugins-bin > > > > While they do not see the value in multi-arch packages which extend beyond upstream support, I do not believe this precludes the packages' existence to support more architectures. > > > > As I have stated to them in other messages, if they have a particular issue with the package not working for them on other architectures they should instead inform me to remedy the issue, rather than spurious deletion requests, and inflammatory language. > > > > Thanks, > > > > Dr. GO > > > > PS: I have replied to each deletion request to ensure they are in the chain for each request, so apologies for the repetition of the message if you happen to read all back to back. > > > > On Monday, February 10th, 2025 at 8:47 PM, notify(a)aur.archlinux.org <notify(a)aur.archlinux.org> wrote: > > > > > > > > > > > vitaliikuzhdin [1] filed a deletion request for kubectl-bin [2]: > > > > > > Already exists in the official repositories. > > > > > > [1] https://aur.archlinux.org/account/vitaliikuzhdin/ > > > [2] https://aur.archlinux.org/pkgbase/kubectl-bin/

6 months

Re: [PRQ#58235] Deletion Request for python-mod

by Marcell Meszaros

On 23 March 2024 21:34:29 GMT+01:00, notify(a)aur.archlinux.org wrote: >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/ grok has been deleted now (PRQ#58232). Safe to drop this DOA package as well

1 year, 4 months

Re: [PRQ#54150] Deletion Request for shellcheck-bin

by Silvio F.

Hello. I don't see the point why I should have 218MB dependencies on my computer. And I'm not interested in haskel development at all. And the shellcheck package is almost twice as big. $ paru -S shellcheck resolving dependencies... looking for conflicting packages... :: shellcheck and shellcheck-bin are in conflict. Remove shellcheck-bin? [y/N] y Package (49) Old Version New Version Net Change Download Size extra/ghc-libs 9.0.2-3 138.41 MiB 19.03 MiB extra/haskell-aeson 2.1.2.1-37 10.38 MiB 1.33 MiB extra/haskell-assoc 1.0.2-246 0.07 MiB 0.02 MiB extra/haskell-attoparsec 0.14.4-70 2.63 MiB 0.39 MiB extra/haskell-base-compat 0.12.2-1 0.33 MiB 0.08 MiB extra/haskell-base-compat-batteries 0.12.2-75 0.33 MiB 0.08 MiB extra/haskell-base-orphans 0.8.8.2-6 0.34 MiB 0.07 MiB extra/haskell-bifunctors 5.6-57 3.10 MiB 0.43 MiB extra/haskell-comonad 5.0.8-241 0.63 MiB 0.11 MiB extra/haskell-contravariant 1.5.5-3 0.45 MiB 0.06 MiB extra/haskell-data-array-byte 0.1.0.1-47 0.13 MiB 0.03 MiB extra/haskell-data-fix 0.3.2-98 0.20 MiB 0.04 MiB extra/haskell-diff 0.4.1-71 0.33 MiB 0.07 MiB extra/haskell-distributive 0.6.2.1-205 0.27 MiB 0.04 MiB extra/haskell-dlist 1.0-235 0.26 MiB 0.06 MiB extra/haskell-erf 2.0.0.0-24 0.06 MiB 0.02 MiB extra/haskell-fgl 5.8.2.0-4 2.03 MiB 0.36 MiB extra/haskell-foldable1-classes-compat 0.1-57 0.57 MiB 0.08 MiB extra/haskell-generically 0.1.1-1 0.10 MiB 0.02 MiB extra/haskell-ghc-bignum-orphans 0.1.1-1 0.01 MiB 0.01 MiB extra/haskell-hashable 1.4.3.0-36 0.63 MiB 0.11 MiB extra/haskell-indexed-traversable 0.1.3-49 0.82 MiB 0.12 MiB extra/haskell-indexed-traversable-instances 0.1.1.2-34 0.09 MiB 0.02 MiB extra/haskell-integer-logarithms 1.0.3.1-6 0.11 MiB 0.03 MiB extra/haskell-onetuple 0.3.1-71 0.02 MiB 0.01 MiB extra/haskell-primitive 0.7.4.0-103 1.84 MiB 0.28 MiB extra/haskell-quickcheck 2.14.3-53 3.45 MiB 0.58 MiB extra/haskell-random 1.2.1.1-154 1.70 MiB 0.23 MiB extra/haskell-regex-base 0.94.0.2-2 0.39 MiB 0.07 MiB extra/haskell-regex-tdfa 1.3.2.2-34 3.25 MiB 0.55 MiB extra/haskell-scientific 0.3.7.0-109 0.56 MiB 0.12 MiB extra/haskell-semialign 1.2.0.1-150 0.81 MiB 0.14 MiB extra/haskell-semigroupoids 5.3.7-132 2.87 MiB 0.38 MiB extra/haskell-splitmix 0.1.0.5-14 0.18 MiB 0.04 MiB extra/haskell-statevar 1.2.2-2 0.09 MiB 0.02 MiB extra/haskell-strict 0.4.0.1-220 1.08 MiB 0.18 MiB extra/haskell-tagged 0.8.8-1 0.33 MiB 0.06 MiB extra/haskell-text-short 0.1.5-75 0.34 MiB 0.08 MiB extra/haskell-th-abstraction 0.4.5.0-1 1.01 MiB 0.17 MiB extra/haskell-these 1.1.1.1-247 0.61 MiB 0.10 MiB extra/haskell-time-compat 1.9.6.1-93 0.73 MiB 0.14 MiB extra/haskell-transformers-compat 0.7.2-1 0.83 MiB 0.12 MiB extra/haskell-unordered-containers 0.2.20-8 1.68 MiB 0.26 MiB extra/haskell-uuid-types 1.0.5.1-12 0.31 MiB 0.07 MiB extra/haskell-vector 0.13.1.0-21 9.49 MiB 1.17 MiB extra/haskell-vector-stream 0.1.0.1-1 0.52 MiB 0.08 MiB extra/haskell-witherable 0.4.2-91 0.94 MiB 0.14 MiB shellcheck-bin 0.9.0-1 -14.63 MiB extra/shellcheck 0.9.0-79 23.27 MiB 3.55 MiB Total Download Size: 31.17 MiB Total Installed Size: 218.57 MiB Net Upgrade Size: 203.94 MiB Best regards, Silvio > AlphaJack [1] filed a deletion request for shellcheck-bin [2]: > > Package is now available in official repos: > https://archlinux.org/packages/extra/x86_64/shellcheck/ > > [1] https://aur.archlinux.org/account/AlphaJack/ > [2] https://aur.archlinux.org/pkgbase/shellcheck-bin/ -- -- Silvio ------------------------------------------- silvio(a)port1024.net --

1 year, 5 months

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