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

Re: [PRQ#49334] Deletion Request for qt5-translations-git

by João Figueiredo

Hi Marcell, First of all, I just want to say I really appreciate all the work you've been doing with your KDE/Qt requests! I've been extremely busy lately, so it's been hard to keep up with everything; I'm hoping to implement the rest of your suggestions this week. When it comes to the Qt5 stuff, I see your point that a -git version is no different from the one in the official repos at this point, when it comes to features. That said, I think there's still value in keeping the PKGBUILDs around, in case people want to build it from source with custom flags, or simply to support old software when Qt5 inevitably gets dropped from the official repos. Similarly, Qt4 is still around in the AUR. So I would suggest that we wait for Qt5 to be moved from the official repos to the AUR (without the -git suffix), and then I can submit merge requests from the -git versions to the non -git versions. What do you think? Best regards, João On Monday, 13 November 2023 14:45:50 WET you wrote: > Only in response to my deletion request, maintainer has changed the source to KDE's backport maintenance fork. > > But my original argument for dropping this from AUR still holds: it's not use to keep this package, as Arch extra repo's stable equivalent also gets bumped frequently to build from new commits published to same maintenance branch. Qt5 is EOL, and soon won't receive any backported patches whatsoever. The stable package should be enough to have around, as long as there are reverse dependencies. > > On 20 October 2023 17:35:09 GMT+02:00, notify(a)aur.archlinux.org wrote: > >MarsSeed [1] filed a deletion request for qt5-translations-git [2]: > > > >Not useful to keep this package. > > > >Qt5 is EOL since May 2023. > > > >This PKGBUILD currently builds from upstream's Qt5 branch, which is > >typically behind the source used by the stable PKGBUILD in extra repo. > >Qt devs delay pushing Qt5 patches to the public repo by one year, > >whereas the KDE project cherry-picks and backports most of the > >important commits accepted by Qt Group for Qt5 but not yet publicly > >pushed. > > > >Therefore the extra repo build is better for users and developers > >alike, because it is based on newer code which has less bugs. > > > >As a consequence of all this, the extra/qt5* packages are quite like > >git VCS packages. > > > >[1] https://aur.archlinux.org/account/MarsSeed/ > >[2] https://aur.archlinux.org/pkgbase/qt5-translations-git/ > >

2 years, 1 month

Re: [PRQ#41719] Deletion Request for wpewebkit-bin

by Andrea Giammarchi

OK, my bad, it used *not* to be the case (reason my builds were published) ... thanks for the update/info: it's all good! On Tue, Jun 6, 2023 at 12:21 PM Marcell Meszaros <marcell.meszaros(a)runbox.eu> wrote: > Arch Linux ARM repos carry armv7h and aarch64 builds. Maybe that distro > could be suitable for your needs? > > Search for wpewebkit here: > > https://archlinuxarm.org/packages > > > On 6 June 2023 11:51:59 GMT+02:00, Andrea Giammarchi < > andrea.giammarchi(a)gmail.com> wrote: > >> that's x86_64 ... .I've been building for arm and arm64 which is nowhere >> so now you broke all my Raspberry Pi Kiosks ... was that really needed? >> >> On Tue, Jun 6, 2023 at 10:57 AM Marcell Meszaros < >> marcell.meszaros(a)runbox.eu> wrote: >> >>> Hi, >>> >>> There is no need for anyone using Arch to rebuild wpewebkit, since it is >>> available in [extra] repo: >>> >>> https://archlinux.org/packages/?q=wpewebkit >>> >>> Cheers >>> >>> >>> On 30 May 2023 09:30:38 GMT+02:00, Andrea Giammarchi < >>> andrea.giammarchi(a)gmail.com> wrote: >>> >>>> This is not unmaintained. Life happened and I need to put back my setup >>>> to be able to build all the related packages. >>>> >>>> There's only this package pre-built and it takes hours to build it too >>>> so it'd be a shame if I can't update (sooner than later) this in the near >>>> future. >>>> >>>> On Tue, May 30, 2023 at 2:24 AM <notify(a)aur.archlinux.org> wrote: >>>> >>>>> MarsSeed [1] filed a deletion request for wpewebkit-bin [2]: >>>>> >>>>> Unmaintained package. >>>>> >>>>> Old duplicate of [extra] wpewebkit. >>>>> >>>>> ArchLinuxARM also carries the ARM binaries. >>>>> >>>>> [1] https://aur.archlinux.org/account/MarsSeed/ >>>>> [2] https://aur.archlinux.org/pkgbase/wpewebkit-bin/ >>>> >>>>

2 years, 6 months

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

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.

1 year, 3 months

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/

1 year, 4 months

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/

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

2 years, 3 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, 6 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

4 years, 2 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, 5 months

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