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

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

by Gaspard d'Hautefeuille

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

2 years

Re: [PRQ#62914] Deletion Request for gstreamer113

by Marcell Meszaros

On 28 August 2024 16:00:47 GMT+02:00, Vitalii Kuzhdin <vitaliikuzhdin(a)gmail.com> wrote: >Greetings, > >I suggest you actually examine the PKGBUILD before submitting deletion >requests. To address your point, there isn't a standalone Python version >'311' either; it's a reference to Python 3.11, which exists in the AUR ><https://aur.archlinux.org/packages/python311> and is quite popular. I >followed a similar naming convention here, with the proper naming specified >in the provides array. > >The idea of merging all dependencies into a single PKGBUILD, simply because >it’s possible, is impractical—and I trust I don’t need to explain why. This >is especially true for older source trees that may require future patches. > >The fact that a package currently has only one dependent, just a few days >after being uploaded, doesn’t invalidate its existence. Many packages exist >without any dependents and are still valuable. My package serves a purpose, >and bundling multiple packages into a single one (like cutter-test) is >impractical. Furthermore, removing cutter-test would be unreasonable, given >the number of packages that depend on it. I am actively reaching out to >other maintainers to integrate testing with cutter-test. > >Best regards, >Vitalii > >On Wed, Aug 28, 2024 at 4:46 PM <notify(a)aur.archlinux.org> wrote: > >> MarsSeed [1] filed a deletion request for gstreamer113 [2]: >> >> There is no gstreamer version 113 (one hundred and thirteen). >> >> This package was made for use by one package, cutter-test. >> >> Please don't duplicate repo packages for such a purpose; build your >> specifically needed gstreamer version inline in the cutter-test >> PKGBUILD, and install it in a location that is specific to cutter-test >> only. >> >> [1] https://aur.archlinux.org/account/MarsSeed/ >> [2] https://aur.archlinux.org/pkgbase/gstreamer113/ The 'python311' pkgname, but the package itself has legitimate purpose as a standalone PKGBUILD. (Even if it has grave packaging mistakes like its provides=python entry.) And, the key difference is, python311 does not conflict with repo's python package, whereas your gstreamer113 does. With this, it can potentially break hundreds of packages, if they were built against the repo version and not your legacy release. AUR submission guidelines explicitly say not to duplicate the repo builds, not with same or different release versions. If you don't want to merge this build into cutter-test, please make a different 'gstreamer-1.13' package that does not conflict with repo's gstreamer and does not declare provides=gstreamer.

11 months, 2 weeks

Re: [PRQ#62155] Deletion Request for azure-cli-bin

by Rodrigo Farias

Hello! This is a reasonable and well-founded request. Thanks for taking the time to review this package. Feel free to delete azure-cli-bin from AUR. Rod On Fri, Aug 16, 2024 at 9:51 AM <notify(a)aur.archlinux.org> wrote: > > MarsSeed [1] filed a deletion request for azure-cli-bin [2]: > > The azure-cli package has been added to Arch/extra repo in March 2024. > > I don't think it is very useful to keep this old-distro-targeting > (Debian Bookworm), Python 3.11 based upstream build, which btw > contains its own Python 3.11 runtimes (python3, pip, pbr, etc.) and > binary+Python-module ecosystem in the install, with up to two hundred > of its own Python modules. > > Also this PKGBUILD strips the upstream binaries, therefore the > installed package is useless for crash reporting purposes. > > Upstream's binaries are also less secure than the Arch build, as the > ELF files here lack full RELRO and PIE. > > The AUR package is also configured improperly: > - It defines 'python' as its dependency, but it is not true, as I > mentioned, this package installs its own /opt/az/bin/python3 symlink > to the /opt/az/bin/python3.11 runtime. > - Man viewing doesn't work in the AUR package, as the relevant files > are installed inside /opt/az and not to their proper places inside > '/usr/share'. > - Bash completions get installed in the wrong place, inside > /etc/bash_completon.d, instead of the expected '/usr/share/bash- > completion/completions'. > - It does not install the mandatory MIT license file. > > > I am observing that there is a discrepancy in AUR PM decisionmaking > regarding keeping or deleting upstream's binary releases from AUR when > a source-based build gets added to the official Arch repos. > > I typically saw Arch Developers like @arojas, and Package Maintainers > like @Antiz delete '-bin' counterparts of Arch repo packages from AUR, > citing the reason that the in such cases the '-bin' builds do not add > any meaningful benefit to users. > > I think this specific PKGBUILD has even stronger than typical reasons > to be dropped from AUR. > > [1] https://aur.archlinux.org/account/MarsSeed/ > [2] https://aur.archlinux.org/pkgbase/azure-cli-bin/

11 months, 4 weeks

Re: [PRQ#47561] Deletion Request for python-pillow-simd

by Christopher Hillenbrand

Current package maintainer here. I agree with your reasoning and consent to the deletion request. On Tue, Sep 19, 2023 at 05:42 <notify(a)aur.archlinux.org> wrote: > MarsSeed [1] filed a deletion request for python-pillow-simd [2]: > > This is an old duplicate of python-pillow, at version 9.2.0, whereas > repo's pillow is on 10.0.1 atm. > > The fork project's README.md clearly states about their versioning > scheme [a]: > > " > Pillow-SIMD is »following« Pillow which means it is drop-in > replacements for Pillow of the same version. For example, Pillow-SIMD > 3.2.0.post3 is a drop-in replacement for Pillow 3.2.0, and Pillow-SIMD > 3.3.3.post0 — for Pillow 3.3.3. > " > > So as this AUR package is on 9.2.0 rather than 9.2.0.post[number], it > is using a copy of upstream Pillow's 9.2.0 source. > > As one digs a little deeper, it becomes obvious that the fork project > no longer produces their patched versions of upstream's latest > releases. [b] > > In fact, the last pillow-simd release was: > v9.0.0.post1 (Jan 4, 2022) > (seen on the second page of the git tags list [c]). > (Also on PyPI [d].) > > The fact that the fork project has newer (vanilla, upstream) tags and > commits on GitHub than its Jan 2022 patched release is misleading. It > just means they mechanically pulled in ("copied") commits and tags > from the upstream pillow codebase, without maintaining their own fork. > > As of now the fork repo's imported codebase is also out-of-sync with > upstream pillow: last pillow-simd imported tag is 9.5.0 (Apr 1, 2023), > as opposed to python-pillow's 10.0.1 (Sep 15, 2023). > > In light of all the above facts, I posit that it is no longer useful > to keep this fork package. > > Summary of the reasons: > - old duplicate of python-pillow, > - if reverted to pillow-simd 9.0.0.post1 (Jan 4, 2022), it would be > even older, > - not feature and API equivalent to pillow 10+, > - so it potentially breaks packages that rely on pillow 10's changed > or new API elements, > - all in all this can no longer be a drop-in replacement of python- > pilllow, > - fork is essentially unmaintained since Jan 2022. > > [a]: > https://github.com/uploadcare/pillow-simd#readme > [b]: > https://github.com/uploadcare/pillow-simd/tags > [c]: > https://github.com/uploadcare/pillow-simd/tags?after=9.1.0 > [d]: > https://pypi.org/project/pillow-simd/ > > [1] https://aur.archlinux.org/account/MarsSeed/ > [2] https://aur.archlinux.org/pkgbase/python-pillow-simd/

1 year, 10 months

Re: [PRQ#47128] Deletion Request for lib32-smbclient

by sL1pKn07 SpinFlo

/me makes saitama face OK (and count.....) greetings El dom, 10 sept 2023 a las 15:54, Marcell Meszaros (< marcell.meszaros(a)runbox.eu>) escribió: > I think it is totally safe to delete this, because no user mentioned any > use case where they would need 32-bit smbclient using wine on a 64-bit > system. And no AUR wine packages are configured to build lib32 support for > Samba. Therefore none of the existing wine builds would use lib32-smbclient > even if they are coinstalled. > > WINE has many legacy features, but if no one demands those, there is no > point in providing them and maintaining unused packages. > > There are many other builds on AUR that really need expert maintainer > attention. It is not worth the effort to waste it on something no > application ever needs. > > @sl1pkn07, you might be preferring to be a completionist or to err on the > theoretical extreme safe side when it comes to lib32 packages, but even you > have not provided any existing use case for this one. > > On 10 September 2023 01:23:52 GMT+02:00, Fabian Maurer < > dark.shadow4(a)web.de> wrote: > >On Samstag, 9. September 2023 21:00:49 CEST you wrote: > >> El sáb, 9 sept 2023 a las 14:50, <notify(a)aur.archlinux.org> escribió: > >> > DarkShadow44 [1] filed a deletion request for lib32-smbclient [2]: > >> > > >> > This is not needed anymore, the last packages that had this as > >> > dependency (lib32-gnome-vfs) was deleted a while ago. > >> > > >> > [1] https://aur.archlinux.org/account/DarkShadow44/ > >> > [2] https://aur.archlinux.org/pkgbase/lib32-smbclient/ > >> > >> needs for wine > > > >You're right, wine configure mentions missing support when that 32bit > samba is > >missing. Not sure what exactly it does though, it's not even optional for > wine > >and the wine tests pass even without the libs installed... > > > >FWIW, once the thunks work well enough, 32bit dependencies are going to > be > >obsolete anyways. Should we keep it around until then? > > > >Regards, > >Fabian Maurer > > > > >

1 year, 11 months

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

by Grzegorz Kozub

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

Re: [aur-requests] [PRQ#28274] Deletion Request for petalinux-v2020.1

by Christopher Snowhill (kode54)

> On Sep 22, 2021, at 12:03 AM, Amin Vakil via aur-requests <aur-requests(a)lists.archlinux.org> wrote: > > On 9/21/21 20:58, Alex Henrie wrote: >>> On Tue, Sep 21, 2021 at 12:01 AM Amin Vakil <info(a)aminvakil.com> wrote: >>> >>> On 9/20/21 20:38, Alex Henrie wrote: >>>> On Sat, Sep 18, 2021 at 12:19 AM <notify(a)aur.archlinux.org> wrote: >>>>> >>>>> aminvakil [1] filed a deletion request for petalinux-v2020.1 [2]: >>>>> >>>>> https://aur.archlinux.org/packages/petalinux-v2021.1/ is already >>>>> present. >>>>> >>>>> [1] https://aur.archlinux.org/account/aminvakil/ >>>>> [2] https://aur.archlinux.org/pkgbase/petalinux-v2020.1/ >>>> >>>> I'm surprised that petalinux-v2020.1, petalinux-v2020.2, and >>>> petalinux-v2020.3 were deleted from the AUR. It would be nice to have >>>> the older versions in the AUR because the latest version (2021.1) is >>>> not 100% compatible. And the AUR has lots of old versions of other >>>> packages like gcc-arm-none-eabi-bin, so why not petalinux? >>>> >>>> $ yay -Ssq gcc-arm-none-eabi >>>> gcc-arm-none-eabi-bin-92 >>>> gcc-arm-none-eabi-bin-83 >>>> gcc-arm-none-eabi-bin-63 >>>> gcc-arm-none-eabi-bin-72 >>>> gcc-arm-none-eabi-bin-73 >>>> gcc-arm-none-eabi-bin-102 >>>> gcc-arm-none-eabi-bin-93 >>>> gcc-arm-none-eabi-bin-49 >>>> gcc-arm-none-eabi-bin-82 >>>> gcc-arm-none-eabi-bin >>> >>> Thanks for bringing this up, I've submitted deletion requests for all of >>> them as well. >> Are you going to delete all the old versions of GCC for x86 too >> (gcc34, gcc43, gcc44, gcc45, gcc46, gcc47, gcc48, gcc49, gcc5, gcc53, >> gcc6, gcc7, gcc8, gcc9)? And if so, why? gcc10 was even promoted out >> of the AUR. >> -Alex > > Arch Wiki is very clear about this: > https://wiki.archlinux.org/title/AUR_submission_guidelines#Rules_of_submiss… > > The submitted PKGBUILDs must not build applications already in any of the official binary repositories under any circumstances. Check the official package database for the package. If any version of it exists, do not submit the package. If the official package is out-of-date, flag it as such. If the official package is broken or is lacking a feature, then please file a bug report. > > "If any version of it exists, do not submit the package." > > But I think gcc is a specific case which I will not get involved in submitting a deletion request for it, but I have asked about it in #archlinux-aur channel on Libera to see what are others' opinions. > > - Amin Vakil I'd say the same also applies to any dependency for an aur package that doesn't work with the latest version. May I even go so far as to suggest there should be zero legacy version packages, even if the latest is only an aur package? Drop mongodb44 too, old computers serve no purpose, much like old software. Huge /s btw

3 years, 10 months

Re: [PRQ#42352] Deletion Request for prusa-slicer-bin

by JP Roemer

I see, thanks a lot for enlightening me on that front. I wasn't aware of that nomenclature and might have submitted this package too quickly at first. I've seen that the removal request went through and will be re-creating it according to the proper naming scheme. Have a nice day, Orax On Tue, 20 Jun 2023, at 23:44, Marcell Meszaros wrote: > @Orax, > > You can create a package for release candidate (rc) versions if you > would like to. Suggested names e.g.: > > prusa-slicer-rc-bin > -or- > prusa-slicer-preview-bin > > In package description, you can add "(preview version)" or "(release > candidate)". > > It could provide either the latest stable or the latest preview / > release candidate, whichever is newer. > > That package would not be considered a duplicate variant of the repo > package. It is valid and allowed on AUR to have > devel/alpha/beta/preview/rc whatever packages. > > On 20 June 2023 09:44:46 GMT+02:00, JP Roemer <jp(a)roemer.im> wrote: >>As the current maintainer of this aur package, I would like to note that prusa-slicer-bin do provide some value over https://archlinux.org/packages/extra/x86_64/prusa-slicer/ as it includes pre-release binaries (as specified in its description). >> >>Those pre-release / release candidate version do use the same configuration folder as final release one (which alpha & beta version do not) and are considered mostly safe to use with just some cutting edge new features available. >> >>The value of this package is to be able to install and tests pre-release versions which are not shipped as part of extra/prusa-slicer. >> >>If this is something that is not welcomed in the aur, I understand and this package can be removed. I just felt like the specific way configuration are handled by this package warranted the existence of a package that included stable and release-candidate versions. >> >>Best, >>Orax >> >>On Mon, 19 Jun 2023, at 12:20, notify(a)aur.archlinux.org wrote: >>> MarsSeed [1] filed a deletion request for prusa-slicer-bin [2]: >>> >>> Not needed anymore, same is in [extra]: >>> >>> https://archlinux.org/packages/extra/x86_64/prusa-slicer/ >>> >>> [1] https://aur.archlinux.org/account/MarsSeed/ >>> [2] https://aur.archlinux.org/pkgbase/prusa-slicer-bin/

2 years, 1 month

Re: [PRQ#70009] Deletion Request for rpcs3

by Vitalii Kuzhdin

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

5 months, 4 weeks

[aur-requests] On the topic of [PRQ#20203]

by FennecTECH (FennecTECH)

I was updating another package and got mixed up with repositories. Ive (finally) straightened them out. Please do not delete this package. From a brief discussion on the archlinux forum katt [1] filed a deletion request for radegast-git [2]: Absolute mess of a package, maintainer decided to rename their -git package to -ng while switching to releases, all while avoiding .SRCINFO to presumable avoid git stopping their madness dead in its tracks. This is backed up by them actually submitting a separate .SRCINFO with just an upped pkgrel. Call the exorcist! [1] https://aur.archlinux.org/account/katt/ [2] https://aur.archlinux.org/pkgbase/radegast-git/ This is a reply to this message. My package is the git from the classic fork that was superseded by Radegast-ng. (Which is releases from the updated version) Some time ago the founder of Radegast passed and the original repository was left. Radegast-NG is a fork of the codebase this package installs. I would like to keep this package around a while longer as some still do use the original version. Today’s mistake was the result of me pushing to the wrong repository. Please do not delete my package. I’m still learning git. https://bbs.archlinux.org/viewtopic.php?pid=1915036#p1915036 Sent from my iPad

5 years, 1 month

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