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

Re: [PRQ#62896] Deletion Request for gnuplot4

by frazar0＠hotmail.it

Dear MarsSeed, as the current maintainer of the gnuplot4 package, I would like to thank you for bringing these issues to my attention. I will try to address each point, reporting the excerpts from your email in bold: */> Dependency chain (of wxgtk2.8) is broken. /*Could you please elaborate more on what you mean with "broken"? I just tried to compile the wxgtk2.8 package and I was able to build a package in a clean chroot. If you encountered a build issue, I invite you to report it in the comments section for the wxgtk2.8 package, and I will try to address it as soon as possible. */> The latest version of this utility software is available in Arch/extra > repo, and provides more features, not less./* Unfortunately, the latest version of gnuplot (v6.0.1) is not fully backward compatible with gnuplot v4 (among other changes, the default colors differ). Having an AUR package for a legacy version of a software can be crucial for reproducing old plots. Additionally (and please do correct me if I'm wrong, I'm not an expert), the sole fact that a package is outdated does not imply that it should not be available in AUR. Consider for example the "gcc43" package. The latest GCC version is indeed available in the official repositories, and they offer more features, but there is still value in providing the legacy version. *> Also AUR has GUI-less variants, for interactive CLI usage > (AUR/gnuplot-nogui) as well as headless (scripted) usage (AUR/gnuplot- > headless).* Unfortunately, as far as I know, none of the mentioned packages provides a fully backward-compatible way of re-generating old plots. I thank you again for raising the above points, and I completely understand the need to balance the maintenance burden between new and old software. If the final decision of the AUR maintainers is to delete the package, I will surely comply. The only reason I submitted the package is because I hoped others could share my work and take advantage of it. With my best regards, Francesco ------------------------------------------------------------------------ *From:* notify(a)aur.archlinux.org *Subject:* [PRQ#62896] Deletion Request for gnuplot4 *Date:* Wednesday, August 28, 2024 at 13:41 UTC+2 *To:* aur-requests(a)lists.archlinux.org *Cc:* frazar0(a)hotmail.it, marcell.meszaros(a)runbox.eu > MarsSeed [1] filed a deletion request for gnuplot4 [2]: > > Dependency chain (of wxgtk2.8) is broken. > The latest version of this utility software is available in Arch/extra > repo, and provides more features, not less. > > Also AUR has GUI-less variants, for interactive CLI usage > (AUR/gnuplot-nogui) as well as headless (scripted) usage (AUR/gnuplot- > headless). > > [1]https://aur.archlinux.org/account/MarsSeed/ > [2]https://aur.archlinux.org/pkgbase/gnuplot4/

11 months, 2 weeks

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

by jahway603

I was not aware of that, so thank you for sharing that insight with me Robin. What I am aware of is that when I search the AUR for "-openrc" that the result yields 83 results meaning there are 83 packages which utilize OpenRC as their init system, including my package in question here. Marcell's argument that "This package was intended for a systemd-less Arch derivative, and is not useful on Arch Linux, due to the fact that it is virtually impossible nowadays to run Arch without systemd..." is not valid as Arch Linux gives us the freedom to run whatever init system we choose to run. The power of Arch Linux is to enable the user to be able to use whatever they choose. If Marcell's logic to delete this package is to remain valid then are there also plans to delete the other 82 packages using OpenRC from the AUR? And are there also plans to delete the Arch Wiki page about OpenRC (https://wiki.archlinux.org/title/OpenRC)? On Tuesday, February 27th, 2024 at 11:50 AM, Robin Candau <antiz(a)archlinux.org> wrote: > On 2/27/24 16:38, jahway603 wrote: > > > THIS SHOULD NOT BE DELETED as the AUR is used by Arch and ALL derivatives of Arch, like Artix, Manjaro, EndeavourOS, etc. > > The AUR has been made by Arch Linux for Arch Linux. Derivatives are > not supported and packages made specifically for such distros are > not allowed. > So, regardless of the below request and whether it will lead to a > deletion of the package or not, the above argument is not relevant. > > > On Monday, February 26th, 2024 at 2:11 PM, notify(a)aur.archlinux.org notify(a)aur.archlinux.org wrote: > > > > > MarsSeed [1] filed a deletion request for ly-git-openrc [2]: > > > > > > Problematic, but unneeded VCS package with wrong name, missing > > > provides field and pkgver() function. > > > > > > The stable ly package is carried by extra repo, and there is a proper > > > ly-git on AUR. > > > > > > This package was intended for a systemd-less Arch derivative, and is > > > not useful on Arch Linux, due to the fact that it is virtually > > > impossible nowadays to run Arch without systemd (hence the other > > > distros). > > > > > > [1] https://aur.archlinux.org/account/MarsSeed/ > > > [2] https://aur.archlinux.org/pkgbase/ly-git-openrc/ > > > -- > Regards, > Robin Candau / Antiz

1 year, 5 months

Re: [aur-requests] [PRQ#16875] Deletion Request for gtk3-classic

by Robin Broda

On 12/3/19 9:13 PM, Eli Schwartz via aur-requests wrote: > On 12/3/19 2:27 PM, Jonathon Fernyhough wrote: >> On 03/12/2019 18:26, notify(a)aur.archlinux.org wrote: >>> rober_k [1] filed a deletion request for gtk3-classic [2]: >>> >>> this is an identical package as gtk3-mushrooms . >>> It pulls from the same repo, only is newer. >>> Proper way would be to mark gtk3-mushrooms out-of-date, not just >>> upload a different package with same content ;) >>> >>> [1] https://aur.archlinux.org/account/rober_k/ >>> [2] https://aur.archlinux.org/pkgbase/gtk3-classic/ >>> >> >> It's not a simply a more up-to-date package. The source repo is the same >> but gtk3-classic is essentially a forked gtk3-mushrooms which adds >> experimental/developmental (?) aspects to the PKGBUILD which the >> original does not (e.g. use of meson and quilt, see e.g. [1]). > > "Use quilt and meson" is not a valid reason to upload a new PKGBUILD. > The resulting package does not care what technology you use for applying > patches, and it *should* not care whether you use autotools or meson to > generate a series of compilation commands. > > Is there something that the resulting .pkg.tar.xz does, which is > different from "gtk3-mushrooms"? > > If it is just about the lib32-* variant, you can just upload a > lib32-gtk3-mushrooms package inspired by > https://git.archlinux.org/svntogit/community.git/tree/trunk/PKGBUILD?h=pack… > >> Also, technically the gtk3-mushrooms package is not out-of-date as the >> upstream is still at 3.24.11. >> >> If all of this is potentially too confusing let me update the PKGBUILD >> to use a different source rather than having the package deleted. > > I don't think changing the url= field makes a difference, if that is > what you mean. > >> [1] https://github.com/krumelmonster/gtk3-mushrooms/pull/26 >> > > As far as i could see by a quick inspection there does appear to be a difference in the patches applied as well, hence me rejecting the request. If this is actually not the case, we might have to revisit my decision -- Rob (coderobe) O< ascii ribbon campaign - stop html mail - www.asciiribbon.org

5 years, 8 months

Re: [PRQ#42292] Deletion Request for joplin-electron

by dianqk

Hi Marcell (Mars), I apologize for the delayed response. The packaging of Joplin Desktop is closer to the official approach. On top of that, I have made several additional patches, switching from electron19 to electron22 and modifying the Joplin source code to support IME startup parameters. These modifications have not been thoroughly tested, and I'm unsure if integrating the system's electron alone will work correctly. However, everything appears to be OK in my local usage. I think we can wait until Joplin's official team makes relevant upgrades and changes before considering whether Joplin Desktop can be updated to use the system's electron. Cheers, dianqk On Sun, Jun 18, 2023, at 10:31 PM, Marcell Meszaros wrote: > Hi @dianqk, > > Thank you for your feedback. > I will revoke my deletion request promptly. > > I see that joplin-desktop declares electron as dependency, but then goes on an makes the package use the bundled Electron. > > Your package, on the other hand, gets this right and configures the usage of system Electron properly. > > It would be ideal in my opinion of you could cooperate with the maintainer of joplin-desktop, maybe request co-maintenance. > > You could help them improve that package. It has existed for much longer and therefore it is significantly more popular. And the package name makes more sense to users. > > Whereas your package is more advanced and optimal, and contains the Wayland IME enhancement as well. > > I think maintainers and users could benefit from your expertise if you advised popular Electron-based package owners on how to make use of the Arch repo electron and how to better integrate with desktop features like those provided via Wayland. > > Cheers, > Marcell (Mars) > > > On 18 June 2023 15:44:00 GMT+02:00, dianqk <dianqk(a)dianqk.net> wrote: >> This is a different build version. Firstly, this version utilizes the system's Electron to save disk space. Additionally, it provides support for IME (Input Method Editor) under Wayland. >> >> On Sat, Jun 17, 2023, at 11:21 PM, notify(a)aur.archlinux.org wrote: >>> MarsSeed [1] filed a deletion request for joplin-electron [2]: >>> >>> Duplicate of the also Electron-based AUR/joplin-desktop: >>> >>> https://aur.archlinux.org/packages/joplin-desktop >>> >>> And the latter has a better name, since AUR/joplin is a CLI version of >>> this note-taking app, whereas the Electron-based ones are desktop GUI >>> programs. >>> >>> [1] https://aur.archlinux.org/account/MarsSeed/ >>> [2] https://aur.archlinux.org/pkgbase/joplin-electron/ >>

2 years, 1 month

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

1 year, 9 months

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

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

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