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

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

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, 5 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/

7 months, 2 weeks

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

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

by Gaspard d'Hautefeuille

A fork is a fork. It does not mean it has been superseded. https://wiki.archlinux.org/title/Archey3 Archey3 is on the wiki, not Archey4. You have already mentioned Archey4 on the Archey3 AUR page, one year ago. And you spammed yesterday the Archey3 AUR page, by flagging it out-of-date while this archey3-git package is up-to-date with the upstream repo. https://github.com/lclarkmichalek/archey3 Not everyone wants to use Archey4, and forking by changing the number to make it seem like it has been superseded is not a good practice. Furthermore, you want to steal the 171 votes and comments of archey3 with this merge request. If the fork of archey4 was by the same author, we could have understood that, it is not the case here. Archey4 has 16 votes, does not have a wiki page (yet). It does seem too early to consider a deletion request for archey3-git in the AUR (Arch Linux User Repository). Maybe you could contact the author https://github.com/lclarkmichalek/archey3/issues and see what he is up to and if he really gives the seal of approval to archey4. AUR/archey3-git is not defunct and I am still maintaining it. You know that archey - first of his name - decided to remove archey4 as a listed fork on GitHub. https://github.com/djmelik/archey djmelik/archey: Archey is a system information tool written in Python. github.com And even, djmelik is planning a complete re-write of Archey. It is very much too early to say 100% that the fork archey4 has to take the crown. Sincerely, HLFH > On 1 Aug 2023, at 17:26, 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, 1 month

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

by Marcell Meszaros

Arch repo openblas is already built with multiple microarchitecture support through cmake '-DDYNAMIC_ARCH=ON'. https://gitlab.archlinux.org/archlinux/packaging/packages/openblas/ Your PKGBUILD, however, does not seem to enable the same for its build with make. The latter also does not build 64-bit precision libraries, whereas the repo buildscript does. So as of now, the new repo package is superior to this original AUR one, in every aspect that you mentioned. On 3 July 2023 19:11:20 GMT+02:00, Guillaume Horel <guillaume.horel(a)gmail.com> wrote: >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, 2 months

Re: [PRQ#43621] Deletion Request for dnschanger-bin

by Marcell Meszaros

The software is suspicious because it is for a purpose that is superfluous on Linux, to change the DNS server settings. And then the website is very marketing-heavy and purports claims that are far-fetched and unreasonable. Turns out, the website is in Persian, with Arabic script. Google Translate did not find the language, it set it to English source language. Translated from Persian by Google translate: "It is an open source software with which users can simply change their DNS settings and thus have access to the Internet at a faster and more efficient rate" " Features of DNS Changer-Desktop: Changing Asan DNS is personal - you will also need to change the DNS parameters of the system. Prestibani from a different DNS - There are 3000 different DNS servers. Without speed limitation - There are no limits to the internet speed, as you can find a number. a dozen guns - With the help of a dozen items, you can quickly press the button. Take a quick step. Sazi character - What you need to know is that the DNS is specialized, so that you have enough storage and payments after you use it. I wish - An application in the form of an open source has became widespread, and now there are no security problems that have arisen. " My takeaway: Changing the DNS server does not remove any speed limit on the internet connection. And it has nothing to do with storage or payments. From Iran, one needs to use a foreign VPN server to access many, otherwise completely blocked Western websites and services, like social media. VPN's are typically provided for a fee. Changing the DNS server on its own does nothing to lift the blocking of affected servers and services. And VPN is not a DNS-based technology, so a DNS changer application cannot create a VPN connection. Which means these bombastic claims the website is making are still suspicious. On 5 July 2023 07:25:31 GMT+02:00, "é" <eclairevoyant9(a)gmail.com> wrote: > >Jul 5, 2023 00:44:53 notify(a)aur.archlinux.org: > >> zxp19821005 [1] filed a deletion request for dnschanger-bin [2]: >> >> Suspicious GUI application. >> Website and GitHub readme only in Arabic. >> And for Linux, changing the DNS server does not need specialized GUI >> application binary from untrusted source that uses its own custom- >> built Chromium/Electron engine. >> And also such an application does not warrant a very nice, shiny, PR- >> heavy facade that the website presents. >> >> [1] https://aur.archlinux.org/account/zxp19821005/ >> [2] https://aur.archlinux.org/pkgbase/dnschanger-bin/ > > >What's actually suspicious to me is your account. > >You submitted this package yourself on May 17, 2023. Presumably the language used by the project maintainers has not changed in the last two months, and now you are requesting deletion? > >First off, the readme is actually entirely in English [3]. Beyond this, you presented racist reasoning instead of technical reasons to delete this package. The website is in Arabic - and what? There's over 360 million native Arabic speakers (dialects notwithstanding). > >The actual technical reasoning would be at best "0 votes, 0 popularity, and I don't use this package that I submitted anymore". Please keep your bigotry to yourself. > >And honestly, I am very suspicious about why you've submitted so many -bin packages in the last few months that you are recently requesting deletion of... > >- éclairevoyant > >[3] https://github.com/DnsChanger/dnsChanger-desktop

2 years, 2 months

Re: [PRQ#70009] Deletion Request for rpcs3

by Annie Leonhardt

Hello, Thank you for your reply. We can bump the AUR version should we need to push a protocol update, for example. And even then, users can still trigger an AUR update on their side if they see it's outdated and they need something from newer. We are not interested in bug reports on old builds, as we do not accept those, only the latest build is supported. We tend to break master branch every so often, and we can quickly remove builds from our updater to prevent regressions from spreading. The updater then updates to the last good build. And again, we can quickly push a version update to the git version if we want users to get explicitly prompted for update. With arbitrary version bumps, there is no way to tell if a version is good or not. Furthermore, we are already receiving support requests from people on this AUR because it's outdated, and we do not want to have these. A version of this AUR existed in the past, but due to the same reasons we also asked for it to be removed. Best Regards, Ani ________________________________ From: Vitalii Kuzhdin <vitaliikuzhdin(a)gmail.com> Sent: Sunday, February 16, 2025 8:14 PM To: noreply(a)aur.archlinux.org <noreply(a)aur.archlinux.org> Cc: aur-requests(a)lists.archlinux.org <aur-requests(a)lists.archlinux.org>; ani-leo(a)outlook.com <ani-leo(a)outlook.com> Subject: Re: [PRQ#70009] Deletion Request for rpcs3 Greetings, Thank you for bringing the rolling version scheme to my attention, I wasn't aware of this. I understand the concerns about outdated builds being misleading. However, I believe there may still be value in maintaining this package with some modifications. As you already know, VCS and regular packages have differences beyond the pkgver() function. For example, the AUR guidelines for VCS packages suggest version bumps only when the build process changes, as pkgver() handles version updates otherwise. However, if the version is not changed on the AUR, users may miss notifications about new commits and important updates. AUR helpers (at least mainstream ones I am aware of) don't automatically watch the repo for changes. Without manual rebuild requests, users won't receive automatic updates, potentially leading to RPCN-related issues you've mentioned. Additionally, VCS packages lack reproducibility. Given RPCS3's extensive dependency chain, this could make bug tracking significantly more challenging. Many rolling release software packages exist in the official Arch repos (e.g., LuaJIT). Since official repos don't allow VCS packages, the solution is regular version bumps. As a compromise, I propose committing to, say, weekly version updates for the RPCS3 package. I'm open to further discussion, but if it is still not useful to keep this, I understand you obviously do not want to get bug reports coming from an outdated package. Thank you for the seriously impressive work behind the emulator. Best regards, Vitalii On Sun, Feb 16, 2025 at 8:27 PM <notify(a)aur.archlinux.org<mailto:notify@aur.archlinux.org>> wrote: AniLeo [1] filed a deletion request for rpcs3 [2]: Please read our release notes at https://github.com/RPCS3/rpcs3/releases/ and remove this AUR. This AUR is misleading, offering outdated builds as if they were some kind of RPCS3 stable builds, such a thing does not exist. It is offering a random outdated build that had no special quality control whatsoever compared to every other build. I leave a copy of the relevant line from our release notes below, just in case: "Note: These are NOT stable builds. RPCS3 is a rolling release software without stable builds. These are random tags we do from time to time. Do NOT use the branch from these tags to package RPCS3." --- Verification that I am a member of the RPCS3 team and am formally requesting for this AUR to be removed: https://forums.rpcs3.net/showthread.php?tid=208697&pid=328170#pid328170 [1] https://aur.archlinux.org/account/AniLeo/ [2] https://aur.archlinux.org/pkgbase/rpcs3/

7 months

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

by Robin Candau

On 2/27/24 18:15, jahway603 wrote: > 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)? > Hi, As I said, my remark was strictly about the "the AUR is also used by all derivatives" argument, which is not relevant/acceptable on its own as the AUR is made for Arch Linux only. I wasn't necessarily taking position regarding the deletion request below. However, when it comes to openrc specifically, I think it is important to notice that only systemd is officially supported on Arch Linux, as stated in the OpenRC wiki page you linked (it's actually the first thing noted on the page as a warning block [1]) and as demonstrated by the fact that OpenRC itself is an AUR package (which are not officially supported either, see the warning block on the related wiki page [2]). The fact that Artix (or whatever other derivatives) officially supports openrc will not change the fact that Arch Linux itself does not, neither the fact that the AUR is an official Arch Linux ressource made for Arch Linux specifically (while it does not prevent derivatives to use it, they are not specifically taken into consideration). Once again, I'm not necessarily saying that this deletion request should be accepted or not, it will be evaluated carefully as every other pending requests. However, it's only fair to expose the current state of things when it comes to the Arch/AUR and unsupported derivatives/init system. I hope you get my point :) [1] https://wiki.archlinux.org/title/OpenRC [2] https://wiki.archlinux.org/title/Arch_User_Repository > > 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 -- Regards, Robin Candau / Antiz

1 year, 6 months

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