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

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

Re: [PRQ#60466] Deletion Request for gnome-shell-extension-rounded-window-corners-reborn

by Mark Wagie

Alright, I'll concede. There will be a release eventually. I've closed the deletion request. Sent with [Proton Mail](https://proton.me/) secure email. On Thursday, May 23rd, 2024 at 10:58 PM, Grzegorz Kozub <grzegorz.kozub(a)gmail.com> wrote: > Correct. So far we established: > > Git package builds on people's PCs from the extension source. This pulls build dependencies, takes time, and is error prone. You seem to prefer it but some people may not like it. Let's respect that. > > Non-git package uses the pre-built archives provided by the extension developer as an official way of installing it, see https://github.com/flexagoon/rounded-window-corners?tab=readme-ov-file#from…. This is faster to install and some people, myself included, prefer it. > > There is no EGO release yet but my motivation was to give this community a way of hassle-free installation before the extension developer releases it. Why don't I add something like `pre-release` suffix to the `pkgver` and explain in the package comment that this is a pre-release package? > > What is the potential harm this package brings to the community? > > (Sorry for sending this email again. Used Reply To before.) > > --greg > > On Thu, May 23, 2024 at 10:48 PM Mark Wagie <mark.wagie(a)proton.me> wrote: > >> Oh, sorry. You're right, 'just pack' does call build before zipping the extension. >> >> Either way, there is no upstream release and it has not been uploaded to EGO yet. It seems the developer is waiting for a new version of Blur My Shell before submitting it as he mentioned here: https://github.com/yilozt/rounded-window-corners/pull/159#issuecomment-2093… >> >> Sent with [Proton Mail](https://proton.me/) secure email. >> >> On Thursday, May 23rd, 2024 at 2:31 PM, Grzegorz Kozub <grzegorz.kozub(a)gmail.com> wrote: >> >>> But "just pack" actually also triggers the whole build. Zipping is just the final step. See "pack: build" in the justfile. >>> >>> So that's what happens in the git version of the aur package. >>> >>> The non-git version just pulls the extension authors zip that he built via GitHub actions. >>> >>> So I'm confused. You wanted to delete the non-git version of the aur package and seem to be confused about what happens in the git version. Maybe you flagged a wrong package? >>> >>> I still don't see a valid reason to delete any of them. Granted we fix the version you seem to have an issue with. >>> >>> On Thu, May 23, 2024, 22:19 Mark Wagie <mark.wagie(a)proton.me> wrote: >>> >>>> Greg: >>>> >>>> There is no "prebuild". Running 'just pack' only zips the files. >>>> >>>> Sent with [Proton Mail](https://proton.me/) secure email. >>>> >>>> On Thursday, May 23rd, 2024 at 1:35 PM, Grzegorz Kozub <grzegorz.kozub(a)gmail.com> wrote: >>>> >>>>> Hi there! I maintain both AUR packages based on https://github.com/flexagoon/rounded-window-corners. The git one builds on your PC and the other uses the pre-build package provided by the extension author. I prefer the pre-build one. Let's not remove it but rather fix the issues you've come across. Can you help fixing the pkgver=12.61c326e, please? I wanted it to reflect the git commit the pre-build was made from. >>>>> >>>>> https://aur.archlinux.org/packages/gnome-shell-extension-rounded-window-cor… >>>>> https://aur.archlinux.org/packages/gnome-shell-extension-rounded-window-cor… >>>>> >>>>> --greg >>>>> >>>>> On Thu, May 23, 2024 at 9:08 PM <notify(a)aur.archlinux.org> wrote: >>>>> >>>>>> yochananmarqos [1] filed a deletion request for gnome-shell-extension- >>>>>> rounded-window-corners-reborn [2]: >>>>>> >>>>>> There is no release and the Maintainer is inventing an erroneous >>>>>> pkgver. We already have a properly maintained VCS package: gnome- >>>>>> shell-extension-rounded-window-corners-reborn-git >>>>>> >>>>>> [1] https://aur.archlinux.org/account/yochananmarqos/ >>>>>> [2] https://aur.archlinux.org/pkgbase/gnome-shell-extension-rounded-window-corn…

1 year, 3 months

Re: [PRQ#42226] Deletion Request for wire-desktop-appimage

by Ashleigh Rowe

In your opinion, maybe. but to anyone who actually prefers appimages? Not so much. Just drop it. We've already acknowledged that they are not the same. On 17/06/2023 17:37, Marcell Meszaros wrote: > I am not at all against AppImage. > > But the latest wire-desktop is in Arch repo, so having > wire-desktop-appimage in AUR is pointless. > > > On 17 June 2023 18:23:08 GMT+02:00, Ashleigh Rowe > <administrator(a)hax.ie> wrote: > > 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> <mailto:administrator@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: [PRQ#42226] Deletion Request for wire-desktop-appimage

by Marcell Meszaros

I am not at all against AppImage. But the latest wire-desktop is in Arch repo, so having wire-desktop-appimage in AUR is pointless. On 17 June 2023 18:23:08 GMT+02:00, Ashleigh Rowe <administrator(a)hax.ie> wrote: >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: [PRQ#60466] Deletion Request for gnome-shell-extension-rounded-window-corners-reborn

by Grzegorz Kozub

Correct. So far we established: Git package builds on people's PCs from the extension source. This pulls build dependencies, takes time, and is error prone. You seem to prefer it but some people may not like it. Let's respect that. Non-git package uses the pre-built archives provided by the extension developer as an official way of installing it, see https://github.com/flexagoon/rounded-window-corners?tab=readme-ov-file#from…. This is faster to install and some people, myself included, prefer it. There is no EGO release yet but my motivation was to give this community a way of hassle-free installation before the extension developer releases it. Why don't I add something like `pre-release` suffix to the `pkgver` and explain in the package comment that this is a pre-release package? What is the potential harm this package brings to the community? (Sorry for sending this email again. Used Reply To before.) -- greg On Thu, May 23, 2024 at 10:48 PM Mark Wagie <mark.wagie(a)proton.me> wrote: > Oh, sorry. You're right, 'just pack' does call build before zipping the > extension. > > Either way, there is no upstream release and it has not been uploaded to > EGO yet. It seems the developer is waiting for a new version of Blur My > Shell before submitting it as he mentioned here: > https://github.com/yilozt/rounded-window-corners/pull/159#issuecomment-2093… > > Sent with Proton Mail <https://proton.me/> secure email. > > On Thursday, May 23rd, 2024 at 2:31 PM, Grzegorz Kozub < > grzegorz.kozub(a)gmail.com> wrote: > > But "just pack" actually also triggers the whole build. Zipping is just > the final step. See "pack: build" in the justfile. > > So that's what happens in the git version of the aur package. > > The non-git version just pulls the extension authors zip that he built via > GitHub actions. > > So I'm confused. You wanted to delete the non-git version of the aur > package and seem to be confused about what happens in the git version. > Maybe you flagged a wrong package? > > I still don't see a valid reason to delete any of them. Granted we fix the > version you seem to have an issue with. > > On Thu, May 23, 2024, 22:19 Mark Wagie <mark.wagie(a)proton.me> wrote: > >> Greg: >> >> There is no "prebuild". Running 'just pack' only zips the files. >> >> Sent with Proton Mail <https://proton.me/> secure email. >> >> On Thursday, May 23rd, 2024 at 1:35 PM, Grzegorz Kozub < >> grzegorz.kozub(a)gmail.com> wrote: >> >> Hi there! I maintain both AUR packages based on >> https://github.com/flexagoon/rounded-window-corners. The git one builds >> on your PC and the other uses the pre-build package provided by the >> extension author. I prefer the pre-build one. Let's not remove it but >> rather fix the issues you've come across. Can you help fixing the >> pkgver=12.61c326e, please? I wanted it to reflect the git commit the >> pre-build was made from. >> >> >> https://aur.archlinux.org/packages/gnome-shell-extension-rounded-window-cor… >> >> https://aur.archlinux.org/packages/gnome-shell-extension-rounded-window-cor… >> -- >> greg >> >> >> >> On Thu, May 23, 2024 at 9:08 PM <notify(a)aur.archlinux.org> wrote: >> >>> yochananmarqos [1] filed a deletion request for gnome-shell-extension- >>> rounded-window-corners-reborn [2]: >>> >>> There is no release and the Maintainer is inventing an erroneous >>> pkgver. We already have a properly maintained VCS package: gnome- >>> shell-extension-rounded-window-corners-reborn-git >>> >>> [1] https://aur.archlinux.org/account/yochananmarqos/ >>> [2] >>> https://aur.archlinux.org/pkgbase/gnome-shell-extension-rounded-window-corn… >> >> >> >

1 year, 3 months

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

by Gaspard d'Hautefeuille

https://terms.archlinux.org/docs/code-of-conduct/#spamadvertisingsolicitati… Spamming is forbidden which you continue to do on this page: https://aur.archlinux.org/packages/archey3-git. You also flagged out-of-date the archey3-git package while it was in sync with the upstream archey3 repo in order to promote archey4. You should only flag out-of-date when the upstream has submitted a new release. As it is a VCS package that is maintained and the upstream has not submitted any breaking changes for the package, I’m not sure it was the right way to do things. Your interpretation of "Ship it” slang is only yours. Going ahead is only meaning this in my opinion: 1) I am currently maintaining archey4-git <https://aur.archlinux.org/packages/archey4-git>, if votes and comments should be merged into of the VCS package archey3-git, it should go there. But I don’t think merging is a good idea. 2) The TU maintaining archey3 in [extra] would have to delete archey3 and promote archey4 in [extra] 3) Then, I would submit archey3-git for deletion because as long as there is an archey3 official package and official archey3 wiki page, a VCS-equivalent package should still be offered to the Arch Linux users 4) It does not make really sense to merge archey3-git into archey4 on the AUR: not the same upstream package, not the same upstream dev, VCS vs normal releases... > On 4 Aug 2023, at 11:40, Marcell Meszaros <marcell.meszaros(a)runbox.eu> wrote: > > # 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 >> >> 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#60466] Deletion Request for gnome-shell-extension-rounded-window-corners-reborn

by Grzegorz Kozub

Nice! Thanks. On Fri, May 24, 2024, 16:07 Mark Wagie <mark.wagie(a)proton.me> wrote: > Alright, I'll concede. There will be a release eventually. I've closed the > deletion request. > > Sent with Proton Mail <https://proton.me/> secure email. > > On Thursday, May 23rd, 2024 at 10:58 PM, Grzegorz Kozub < > grzegorz.kozub(a)gmail.com> wrote: > > Correct. So far we established: > > Git package builds on people's PCs from the extension source. This pulls > build dependencies, takes time, and is error prone. You seem to prefer it > but some people may not like it. Let's respect that. > > Non-git package uses the pre-built archives provided by the extension > developer as an official way of installing it, see > https://github.com/flexagoon/rounded-window-corners?tab=readme-ov-file#from…. > This is faster to install and some people, myself included, prefer it. > > There is no EGO release yet but my motivation was to give this community a > way of hassle-free installation before the extension developer releases it. > Why don't I add something like `pre-release` suffix to the `pkgver` and > explain in the package comment that this is a pre-release package? > > What is the potential harm this package brings to the community? > > (Sorry for sending this email again. Used Reply To before.) > > -- > greg > > > On Thu, May 23, 2024 at 10:48 PM Mark Wagie <mark.wagie(a)proton.me> wrote: > >> Oh, sorry. You're right, 'just pack' does call build before zipping the >> extension. >> >> Either way, there is no upstream release and it has not been uploaded to >> EGO yet. It seems the developer is waiting for a new version of Blur My >> Shell before submitting it as he mentioned here: >> https://github.com/yilozt/rounded-window-corners/pull/159#issuecomment-2093… >> >> Sent with Proton Mail <https://proton.me/> secure email. >> >> On Thursday, May 23rd, 2024 at 2:31 PM, Grzegorz Kozub < >> grzegorz.kozub(a)gmail.com> wrote: >> >> But "just pack" actually also triggers the whole build. Zipping is just >> the final step. See "pack: build" in the justfile. >> >> So that's what happens in the git version of the aur package. >> >> The non-git version just pulls the extension authors zip that he built >> via GitHub actions. >> >> So I'm confused. You wanted to delete the non-git version of the aur >> package and seem to be confused about what happens in the git version. >> Maybe you flagged a wrong package? >> >> I still don't see a valid reason to delete any of them. Granted we fix >> the version you seem to have an issue with. >> >> On Thu, May 23, 2024, 22:19 Mark Wagie <mark.wagie(a)proton.me> wrote: >> >>> Greg: >>> >>> There is no "prebuild". Running 'just pack' only zips the files. >>> >>> Sent with Proton Mail <https://proton.me/> secure email. >>> >>> On Thursday, May 23rd, 2024 at 1:35 PM, Grzegorz Kozub < >>> grzegorz.kozub(a)gmail.com> wrote: >>> >>> Hi there! I maintain both AUR packages based on >>> https://github.com/flexagoon/rounded-window-corners. The git one builds >>> on your PC and the other uses the pre-build package provided by the >>> extension author. I prefer the pre-build one. Let's not remove it but >>> rather fix the issues you've come across. Can you help fixing the >>> pkgver=12.61c326e, please? I wanted it to reflect the git commit the >>> pre-build was made from. >>> >>> >>> https://aur.archlinux.org/packages/gnome-shell-extension-rounded-window-cor… >>> >>> https://aur.archlinux.org/packages/gnome-shell-extension-rounded-window-cor… >>> -- >>> greg >>> >>> >>> >>> On Thu, May 23, 2024 at 9:08 PM <notify(a)aur.archlinux.org> wrote: >>> >>>> yochananmarqos [1] filed a deletion request for gnome-shell-extension- >>>> rounded-window-corners-reborn [2]: >>>> >>>> There is no release and the Maintainer is inventing an erroneous >>>> pkgver. We already have a properly maintained VCS package: gnome- >>>> shell-extension-rounded-window-corners-reborn-git >>>> >>>> [1] https://aur.archlinux.org/account/yochananmarqos/ >>>> [2] >>>> https://aur.archlinux.org/pkgbase/gnome-shell-extension-rounded-window-corn… >>> >>> >>> >> >

1 year, 3 months

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