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

Re: [PRQ#47124] Deletion Request for lib32-net-snmp

by Marcell Meszaros

> *windows only 32bits scanner software cries in the corner* The hypothetical users of those hypothetically still-in-use scanners would hypothetically best choose to install AUR/wine-wow64, or the same from Chaotic-AUR, which can execute 32-bit Windows software without touching any lib32 binaries on the Linux system. And you know, starting in 2005 Microsoft had pushed OEM's to the extreme in making them come out with 64-bit drivers for their devices, that even scanners and printers manufactured in the late 1990's have received those drivers and at least the bare minimum of supporting software. On 10 September 2023 17:04:26 GMT+02:00, sL1pKn07 SpinFlo <sl1pkn07(a)gmail.com> wrote: >*windows only 32bits scanner software cries in the corner* > >ok, you won. another package add (and count...) to my own local packages >for maintain list *sic* > > >greetings > >El dom, 10 sept 2023 a las 15:56, Marcell Meszaros (< >marcell.meszaros(a)runbox.eu>) escribió: > >> No, it is not needed in AUR wine builds. >> >> And neither you nor any other user has provided any use case existing >> today where one would need lib32-sane. >> >> >> On 10 September 2023 15:35:41 GMT+02:00, sL1pKn07 SpinFlo < >> sl1pkn07(a)gmail.com> wrote: >> >>> thats is because none of the packages on aur is builded with lib32-sane >>> support, but yes. is indeed needs in custom builds >>> >>> sl1-wine-git W: Dependency sane detected but optional (libraries >>> ['usr/lib/libsane.so.1'] needed in files >>> ['usr/lib/wine/x86_64-unix/sane.so']) >>> sl1-wine-git W: Dependency lib32-sane detected but optional (libraries >>> ['usr/lib32/libsane.so.1'] needed in files >>> ['usr/lib32/wine/i386-unix/sane.so']) >>> >>> greetings >>> >>> El dom, 10 sept 2023 a las 15:30, Marcell Meszaros (< >>> marcell.meszaros(a)runbox.eu>) escribió: >>> >>>> >PRQ#45251 is for lib32-sane? also needs for wine >>>> >>>> This is also not true. Only the 64-bit sane is linked to by >>>> multilib/wine, and none of the AUR wine package depend on lib32-sane as >>>> well. >>>> >>>> >>>> On 10 September 2023 09:19:45 GMT+02:00, sL1pKn07 SpinFlo < >>>> sl1pkn07(a)gmail.com> wrote: >>>> >>>>> >>>>> >>>>> El dom, 10 sept 2023 a las 9:17, sL1pKn07 SpinFlo (<sl1pkn07(a)gmail.com>) >>>>> escribió: >>>>> >>>>>> >>>>>> >>>>>> El sáb, 9 sept 2023 a las 13:42, <notify(a)aur.archlinux.org> escribió: >>>>>> >>>>>>> MarsSeed [1] filed a deletion request for lib32-net-snmp [2]: >>>>>>> >>>>>>> This unmaintained, unused package can be deleted as well after >>>>>>> PRQ#45251. >>>>>>> >>>>>>> [1] https://aur.archlinux.org/account/MarsSeed/ >>>>>>> [2] https://aur.archlinux.org/pkgbase/lib32-net-snmp/ >>>>>> >>>>>> >>>>>> needs for wine >>>>>> >>>>>> greetings >>>>>> >>>>> >>>>> PRQ#45251 is for lib32-sane? also needs for wine >>>>> >>>>> greetings >>>>> >>>>

2 years

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

by Marcell Mészáros

Dynamic architecture support means one binary can take advantage of a wide range of microarchitectures. Also, your build turns on USE_TLS, a "new, still somewhat experimental code that uses thread-local storage instead of a central memory buffer". Which is exactly what it should not do in a production-targeted build. You should create a new package with a descriptive name suffix, like '-experimental-tls' or something. On 3 July 2023 19:33:04 GMT+02:00, Marcell Meszaros <marcell.meszaros(a)runbox.eu> wrote: >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#42226] Deletion Request for wire-desktop-appimage

by Ashleigh Rowe

One can also install many things on the AUR by using flatpak or a package manager. Does not mean they should be removed. Just stop with the seeming anti-appimage, ok? On Sat, 17 Jun 2023, 13:51 Marcell Meszaros, <marcell.meszaros(a)runbox.eu> wrote: > One can also install a standalone AppImage file by running it. It does not > need to be packaged via an AUR PKGBUILD. > > > On 16 June 2023 18:55:00 GMT+02:00, Ashleigh Rowe <administrator(a)hax.ie> > wrote: > >> Hi Marcell, >> >> That may be the case, but there are many reasons to want to use an >> appimage over a natively installed application. And, given that it is not >> the same package, it need not be deleted. Taking the same logic to it's >> extreme, one could argue that a -git and a -bin version of a package need >> not both be on the AUR, as for users, it is the same. >> We both know, however, that this is not the case. >> On 16/06/2023 17:31, Marcell Meszaros wrote: >> >> > So, by your own admission, it is not a duplicate of a repo package then? >> >> Hi Asleigh, >> >> Thank you for your reply. >> >> The way I see it, the Arch repo version integrates better with the system >> and does not include unnecessary bloat. >> >> The AUR AppImage version carries its own Electron runtime rather than >> using one available from Arch repo. >> >> The feature set is the same. >> >> So, for all intents and purposes, the AUR package is the same for users. >> >> Except the latter takes up more space, and is potentially more insecure >> >> There are frequent updates of Electron in repo. >> The AUR package won't update its built-in electron separately. >> >> On the other hand, repo's wire-desktop package will always use the latest >> repo-updated version of its electron runtime. >> >> All in all, the AUR version is an inferior duplicate. >> >> In my understanding, it is only useful to have AppImage packages of >> especially Electron-based applications on AUR if the Arch repo does not >> carry that application. >> >> Cheers, >> Marcell (Mars) >> >> >> On 16 June 2023 17:23:12 GMT+02:00, Ashleigh Rowe <administrator(a)hax.ie> >> <administrator(a)hax.ie> wrote: >> >>> So, by your own admission, it is not a duplicate of a repo package then? >>> >>> On Fri, 16 Jun 2023 at 16:20, <notify(a)aur.archlinux.org> wrote: >>> >>>> MarsSeed [1] filed a deletion request for wire-desktop-appimage [2]: >>>> >>>> Duplicate of repo package, not needed: >>>> >>>> https://archlinux.org/packages/extra/any/wire-desktop/ >>>> >>>> This is an Electron-based application, so there is no benefit in using >>>> this AppImage in a PKGBUILD. The repo version has the exact same >>>> application code. >>>> >>>> And repo verison is even better because it does not duplicate the >>>> electron runtime, but depends on the relevant repo electron package. >>>> >>>> [1] https://aur.archlinux.org/account/MarsSeed/ >>>> [2] https://aur.archlinux.org/pkgbase/wire-desktop-appimage/ >>> >>>

2 years, 2 months

Re: [aur-requests] [PRQ#407] Deletion Request for python-argparse

by Eduardo Machado

> > > This actually makes sense to me. Most people will only want one version > > or the other of the lib, depending on what software is using it. Having > > it as a split package forces them to build both and have all the deps > > for both installed. Makes sense in a binary repo, not so much in the > > AUR. > I thinked just liked this after i built these packages, and therefore, i discovered that some of then aren' t compatible with python2 and python3, two of then are python2 only, so i had to comment some lines to hide the python3 part. but i thought this was a bad solution to only keep the script ready for python3 compatibility. > I just built the python-argparse split package in less than three > seconds. Build time isn't a valid argument here. Also, I highly > recommend building all AUR packages inside a chroot; otherwise, you have > no control of what happens on your file system (think of broken build > scripts that ignore $(DESTDIR) etc.) > > I think it is a good idea to use split packages unless there are good > reasons not to do so. Note that the AUR can also be viewed as a staging > area for source packages that might eventually be moved to the official > repositories. Not using split packages means more work for Trusted Users > and developers when moving. > Thinking this way you are right. Personally i don't mind to work with one or another spec. But i would like the advise of yours to standardize this "trade of". ;) --- Eduardo M. Machado Engenheiro de Computação Rio de Janeiro - RJ Brasil 2014-08-03 15:19 GMT-03:00 Lukas Fleischer <archlinux(a)cryptocrack.de>: > On Sun, 03 Aug 2014 at 19:12:38, Doug Newgard wrote: > > On 2014-08-03 10:15, Lukas Fleischer wrote: > > > On Sun, 03 Aug 2014 at 15:33:28, Doug Newgard wrote: > > >> On 2014-08-03 08:26, notify(a)aur.archlinux.org wrote: > > >> > mawcomw [1] filed a deletion request for python-argparse [2]: > > >> > > > >> > It was a split package, and now i will use two pkgbuilds, one for > > >> > python2 and another for python3. > > >> > > > >> > [1] https://aur.archlinux.org/account/mawcomw/ > > >> > [2] https://aur.archlinux.org/pkgbase/python-argparse/ > > >> > > >> So upload the py3 version to the current python-argparse package, then > > >> upload a new python2-argparse. No need to remove what's there. > > >> > > > > > > Agreed. I would also be interested in why you would like to replace a > > > split package with two separate packages? > > > > This actually makes sense to me. Most people will only want one version > > or the other of the lib, depending on what software is using it. Having > > it as a split package forces them to build both and have all the deps > > for both installed. Makes sense in a binary repo, not so much in the > > AUR. > > > > I just built the python-argparse split package in less than three > seconds. Build time isn't a valid argument here. Also, I highly > recommend building all AUR packages inside a chroot; otherwise, you have > no control of what happens on your file system (think of broken build > scripts that ignore $(DESTDIR) etc.) > > I think it is a good idea to use split packages unless there are good > reasons not to do so. Note that the AUR can also be viewed as a staging > area for source packages that might eventually be moved to the official > repositories. Not using split packages means more work for Trusted Users > and developers when moving. >

11 years, 1 month

Re: [PRQ#46940] Deletion Request for motivewave-latest-bin

by xiota

Please reject deletion requests: PRQ#46635, PRQ#46640, and PRQ#46940. They are all opened by the same user, xavierbaez, against motivewave-latest-bin. PRQ#46635: Falsely stated motivewave package brakes. Causes conflicts. The state of another package is not relevant to whether motivewave-latest-bin should be deleted. Regardless, motivewave was broken for over four months, when 6.7.0 was released on 2023-04-17, until the package was updated on 2023-08-25 (over four months). This can be confirmed by reviewing the commit log <https://aur.archlinux.org/cgit/aur.git/log/?h=motivewave>. Build log showing the broken state of the package: motivewave.log <https://github.com/chaotic-aur/packages/files/12443975/motivewave.log>. The relevant error is: ==> Validating source files with sha512sums... motivewave-6.6.15.deb ... FAILED ==> ERROR: One or more files did not pass the validity check! PRQ#46640: Issue here guy created a package with the files because he wants to duplicate packages instead of helping with code 👨🏻‍💻 Not working open source but pushing his package. He created an issue that doesn’t exist. He merged his own code in those repositories. He approved his own issue. What’s the point of creating the exact same package as motivewave but with a different maintainer. It is based on the file we download from motivewave anyway. These concern internal Chaotic AUR package selection and build policies. None of it is relevant to whether a package should be deleted from AUR proper. PRQ#46940: This guy Xiota is a stalked. This is a false accusation. Rather, evidence of xavierbaez’s behavior in violation of Arch Linux Code and Chaotic AUR code of conduct may be seen in the aurweb comments of motivewave and motivewave-latest-bin, as well as in the Chaotic AUR GitHub repository. The Chaotic AUR owner issued a “final warning” (prior to ban) to user xavierbaez for his conduct. He is flagging out of date to AUR for no reason. Whether another package is flagged has no bearing on whether this package should be deleted. Regardless, the purpose of the flag on motivewave was to encourage the maintainer to fix the package after refusing to do so after notification via ordinary comments. - motivewave has a chmod syntax error (PKGBUILD line 17, 61d4efc <https://aur.archlinux.org/cgit/aur.git/commit/?h=motivewave&id=61d4efc5898c…> ) - `.SRCINFO was manually edited for unknown purpose in 294195 <https://aur.archlinux.org/cgit/aur.git/commit/?h=motivewave&id=2941953be7ac…>, fe66229 <https://aur.archlinux.org/cgit/aur.git/commit/?h=motivewave&id=fe6622969cc4…> . Even with the exact same lines of code, he has nothing better to do to try to bring motivewave down. It is perfectly reasonable to ask package maintainers to maintain their packages. Those who do not wish to do so should disown the packages so someone who is willing to maintain them can do so. motivewave-latest-bin has diverged from motivewave in the following ways: - motivewave-latest-bin checks for upstream releases (-latest-bin) before building the package. - Dependencies have been updated. - chmod syntax error was never introduced. - .SRCINFO is generated by makepkg --printsrcinfo, not manually edited. I have already asked him to focus on his duties with other packages. Review of xavierbaez’s previous comments at aforementioned locations show no such request. He also works for Chaotic AUR, where he removed motivewave… motivewave was removed from Chaotic AUR for poor maintainership, including refusal to correct defects that were identified by Chaotic AUR maintainers. As an independent package repository, Chaotic AUR activities have no bearing on whether a package should be deleted from AUR proper. On Sat, Sep 2, 2023 at 10:51 PM <notify(a)aur.archlinux.org> wrote: > xavierbaez [1] filed a deletion request for motivewave-latest-bin [2]: > > This guy Xiota is a stalked. > He is flagging out of date to AUR for no reason. > Even with the exact same lines of code, he has nothing better to do to > try to bring motivewave down. > I have already asked him to focus on his duties with other packages. > > He also works for Chaotic AUR, where he removed motivewave, then > inmediately asked for a change, then deleted motivewave again, and > then went again against motivewave on 09/02/2023 saying it's out of > date. > > Both packages use the exact same deb file as source. > Please fix the following issues: > > a) `PKGBUILD` contains `chmod` syntax error. > > You have the same CHMOD issues as motivewave > > Here is the evidence > Original package motivewave: > > find "$pkgdir" -exec chmod g-w {} + > > Stalker package: > find "$pkgdir" -exec chmod g-w {} + > > [1] https://aur.archlinux.org/account/xavierbaez/ > [2] https://aur.archlinux.org/pkgbase/motivewave-latest-bin/

2 years

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

by Marcell Meszaros

(Resending with slight edit, because I sent it earlier from non-subscribed email address alias). Dynamic architecture support used in the repo package means one binary can take advantage of a wide range of microarchitectures. Also, your build turns on USE_TLS, a "new, still somewhat experimental code that uses thread-local storage instead of a central memory buffer". Which is exactly what it should not do in a production-targeted, stable build. You should create a new package with a descriptive name suffix, like '-experimental-tls' or something. On 3 July 2023 19:33:04 GMT+02:00, Marcell Meszaros <marcell.meszaros(a)runbox.eu> wrote: >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#45699] Merge Request for archey3-git

by Marcell Meszaros

# Do not flame # Flaming, in the most common sense definition, is directing negative, disrespectful, and/or insulting comments toward someone. An equally or more negative response, resulting in a cycling exchange of insults is often the consequence. Flaming fellow members (including the Arch team) will not be tolerated. Avoid personal insults and sarcastic or patronizing language. Discussions can be productive, but quarreling is always destructive. https://terms.archlinux.org/docs/code-of-conduct/#do-not-flame On 2 August 2023 10:32:16 GMT+02:00, Gaspard d'Hautefeuille <gaspard(a)dhautefeuille.eu> wrote: >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#43621] Deletion Request for dnschanger-bin

by Scarlett Haxie

Would just like to interject that changing the DNS server *can* bypass some types of blocking, including those set in place by many ISPs. Additionally, while the download speed of a single large file (the arch iso, for example) may not be sped up, most real-world tests have found that a DNS server that responds faster can make the web browsing experience significantly snappier and more responsive. This is, in part, due to the fact that the internet is not just one large single file that is downloaded, but many small files, and if the DNS requests for resolving how to access all of those is slow, you may not notice an additional 50ms delay for a single file, but you definitely will for the thousands required to load a standard webpage. On Wed, 5 Jul 2023 at 11:11, Marcell Meszaros <marcell.meszaros(a)runbox.eu> wrote: > 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: [aur-requests] [PRQ#9551] Deletion Request for spinach

by Garrett

As I look at it, those points correctly illustrate that this is not the greatest AUR helper out there. I will not disagree with that. (For example, the resurgence of bauerbill is refreshing.) However, I at present do not believe spinach is "risky." It does not source the PKGBUILD directly. I do not think it will allow arbitrary code execution before viewing unless there is a method for executing code in a string in Bash other than with tick marks or $(...). I would easily be convinced that it is risky if I could find such an example. Note that such things are listed in a security section in the man page. Though, as you said, I could (and should) change this fairly easily to use a more modern method. In my view this discussion might be more suited as a bug report for spinach rather than a cause for deleting the package, but delete it if you wish. On Tue, Oct 24, 2017 at 3:48 PM, Alad Wenter <alad(a)mailbox.org> wrote: > > Garrett <garrett.floft(a)gmail.com> hat am 24. Oktober 2017 um 21:57 > geschrieben: > > > > > > I would be fine with removing it from the AUR helpers page as there are > > presently many Bash AUR helpers. I don't know why it should be removed > from > > the AUR though. > > > The reason is that these undeveloped helpers have no purpose in 2017, > apart from to expose users to risky practice. > > > This is not a clone of yaourt. Though according to the AUR Helpers page > it > > is as secure as yaourt, i.e., not very secure except for spinach you'd > have > > to do some interesting escaping (that to my present knowledge is not > > possible, but there might be some way to do it) to get around the > function > > that cleans what is sourced for finding the depends. Yaourt package is > 0.53 > Since at least 2014 it's trivial to retrieve dependencies via the AUR RPC, > and any reasonable helper does exactly that. Even if the RPC does not > contain some information that the PKGBUILD does, it's easy to retrieve the > .SRCINFO instead. > > > MiB whereas the spinach package is 23 KiB. It was originally created for > > being very small and only doing the minimum required while still being > fast > > and useful. At the time (and maybe still now) I don't think many of the > > others were as small while still having features like downloading updates > > in multiple "threads". Also not sure if any of the others allow > installing > The "size" is nothing special and comparable to any of the script helpers. > Threads are mostly useless since the arrival of the multiinfo interface. > (See the related discussion on the AUR helper wiki article) > > > from a local directory of PKGBUILDs. Since I haven't used all of them I > Not sure how (a customizepkg variant) is useful when spinach can't > properly resolve dependencies to begin with. > > > don't really know how it compares to everything out there. Not saying > it's > > the greatest, but I think it has uses. > Maybe in 2011. Right now it might serve as historical perspective for > those writing their own AUR helpers (and in fact, I wouldn't mind having a > "Defunct AUR helpers" or such section on the wiki). Otherwise you should > look at a helper which uses modern, safe methods. > > > > > On Tue, Oct 24, 2017 at 9:27 AM, <notify(a)aur.archlinux.org> wrote: > > > > > Alad [1] filed a deletion request for spinach [2]: > > > > > > Antiquated yaourt clone, sources PKGBUILDs for dependency resolution > > > before users can inspect them. Otherwise no unique functionality. > > > > > > [1] https://aur.archlinux.org/account/Alad/ > > > [2] https://aur.archlinux.org/pkgbase/spinach/ > > > >

7 years, 10 months

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

by eNV25

bbswitch-ati-dkms-git bbswitch-ati-git are split packages from the same PKGBUILD. Of course they have same version. darling is a duplicate of darling-git yay follows upstream release, yay-git follows git branch On Sat, Jan 15, 2022 at 9:57 PM <info(a)sick.codes> wrote: > > Are you suggesting that every AUR package that is up to date with master where there is a -git package should be removed? > > bbswitch-ati-dkms-git 0.8.5.gddbd243-1 3 > bbswitch-ati-git 0.8.5.gddbd243-1 > > darling r3131.fa5348c8a-1 > darling-git r3131.fa5348c8a-1 > > yay 11.1.0-1 > yay-git 11.1.0.r0.gac13060-1 > > AUR rules https://wiki.archlinux.org/title/AUR_submission_guidelines#Rules_of_submiss… > > “If it is currently maintained, changes can be submitted in a comment for the maintainer's attention. If it is unmaintained or the maintainer is unresponsive, the package can be adopted and updated as required. Do not create duplicate packages.“ > > It’s not a duplicate, it’s the pegged non-git package which uses a specific commit. > > The package was merged because I removed myself from the mailing list and didn’t reply stating that the issues were resolved. > > Why did you merge instead of suggesting changes? Your package is git package that does not have -git sufflix. > > And why do you want the package deleted so urgently? > It's not urgent. > Jan 15, 2022, 20:00 by env252525(a)gmail.com: > > It is still a duplicate. There are no releases upstream. What's the point of having a non git version if it's just going to follow the latest git commit anyway? > > Yes this matter was resolved. The package was merged. That is why anbox-modules-dkms should not exist. > > On Sat, Jan 15, 2022 at 4:08 PM <info(a)sick.codes> wrote: > > Hey eNV25, > > Just because the non-git and git packages are on the same commit id does not mean the whole package should be wiped and its changelog, comments, AUR git history, and any other informative discussion should be deleted. > > Once master is updated, the non-git will be out of date. That's what Out of Date is for. > > # non-git > source=("git+https://github.com/choff/${_pkgname}.git#commit=8148a162755bf5500a07cf4…" > > # git > source=("git+$url#branch=master") > > As you know your original Merge Request reasons were already addressed. > > Merge request: https://lists.archlinux.org/pipermail/aur-requests/2021-December/063155.html > > Fixes: https://aur.archlinux.org/cgit/aur.git/commit/?h=anbox-modules-dkms&id=8790… > > And: https://aur.archlinux.org/cgit/aur.git/commit/?h=anbox-modules-dkms&id=20a6… > > - Removed the build function from previous 2017 maintainer > - Removed linux-headers from previous 2017 maintainer > - Removed /usr/lib/modules-load.d/ from previous 2017 maintainer > > I didn't create the original pkgbuild, I simply revived it as-is, including it's git history for transparency. I didn't write the original PKGBUILD. I re-uploaded it with accurate git history so that anyone else can actually see the commit history of the package: https://aur.archlinux.org/cgit/aur.git/log/?h=anbox-modules-dkms > > Given you are well aware I was actively maintaining the package, why would you submit a merge request instead of emailing me or submit a pull request? > > I really don't understand your sudden urgency to remove the package from the AUR. > > Why did you merge instead of suggesting changes? > > And why do you want the package deleted so urgently? > > In good faith, > > Sick Codes of the Security Research Team @SickCodes > > https://sick.codes > https://github.com/sickcodes > https://twitter.com/sickcodes > https://www.linkedin.com/in/sickcodes/ > https://www.youtube.com/c/sickcodes > https://parler.com/profile/sickcodes/ > https://hackerone.com/sickcodes > https://bugcrowd.com/sickcodes > https://hub.docker.com/r/sickcodes > > > > > > > Jan 15, 2022, 09:05 by env252525(a)gmail.com: > > On Sat, Jan 15, 2022 at 11:10 AM <info(a)sick.codes> wrote: > > > This is a false deletion request, the maintainer knows this is a correct non-git dkms PKGBUILD > > > I don't think so. > > > https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=anbox-modules-dkms > > The maintainer discussion between myself and the other maintainer is on https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=anbox-modules-dkms > > I don’t we know what the current maintainer is trying to achieve here but the two packages are distinct. > > 1) I personally maintain the fork with the GitHub user > > > fine > > > 2) I had already made env25 a co maintainer > > > And I made you a co-maintainer for anbox-modules-dkms-git > > 3) I am on the WayDroid dev team > > > It's not relevant who you are > > 2) this fork was created by myself and Choff > > > fine > > 3) the non-git is perfectly fine now > > > No it's not it's a duplicate of anbox-modules-dkms-git > > 4) eNV25 has already merged requested this, in a rush, for no apparent reason. > > > The TU ainola merged this. I submitted the request. > > https://lists.archlinux.org/pipermail/aur-requests/2021-December/063155.html > https://lists.archlinux.org/pipermail/aur-requests/2021-December/063596.html > > > Please reject this merge & deletion request for the following reasons: > > > Please don't reject this deletion request. > > > And if possible please merge back the non-git repo comment history as you can clearly see > > I have been maintaining the WIKI on Anbox to be accurate https://wiki.archlinux.org/title/Anbox > > > fine > > > In good faith, > > Sick Codes of the Security Research Team @SickCodes > > https://sick.codes > https://github.com/sickcodes > https://twitter.com/sickcodes > https://www.linkedin.com/in/sickcodes/ > https://www.youtube.com/c/sickcodes > https://parler.com/profile/sickcodes/ > https://hackerone.com/sickcodes > https://bugcrowd.com/sickcodes > https://hub.docker.com/r/sickcodes > > > > > > > Jan 14, 2022, 22:57 by notify(a)aur.archlinux.org: > > eNV25 [1] filed a deletion request for anbox-modules-dkms [2]: > > This package is a duplicate of anbox-modules-dkms-git. > > I previously submitted a merge request from anbox-modules-dkms to > anbox-modules-dkms-git. > > I maintain anbox-modules-dkms-git. > > [1] https://aur.archlinux.org/account/eNV25/ > [2] https://aur.archlinux.org/pkgbase/anbox-modules-dkms/ > > >

3 years, 7 months

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