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

[PRQ#58235] Deletion Request for python-mod

by notify＠aur.archlinux.org

MarsSeed [1] filed a deletion request for python-mod [2]: Useless dead-on-arrival package, only reverse dependency is the similarly broken-from-day-one grok (deletion request submitted by @Muflone: PRQ#58232). ==> Starting build()... /usr/lib/python3.11/site-packages/setuptools/__init__.py:80: _DeprecatedInstaller: setuptools.installer and fetch_build_eggs are deprecated. !! ********************************************************************** Requirements should be satisfied by a PEP 517 installer. If you are using pip, you can try `pip install --use-pep517`. ********************************************************************** !! dist.fetch_build_eggs(dist.setup_requires) WARNING: The wheel package is not available. /usr/bin/python: No module named pip Traceback (most recent call last): File "/usr/lib/python3.11/site-packages/setuptools/installer.py", line 101, in _fetch_build_egg_no_warn subprocess.check_call(cmd) File "/usr/lib/python3.11/subprocess.py", line 413, in check_call raise CalledProcessError(retcode, cmd) subprocess.CalledProcessError: Command '['/usr/bin/python', '-m', 'pip', '--disable-pip-version-check', 'wheel', '--no-deps', '-w', '/tmp/tmp6tjq_fpq', '--quiet', 'pytest-runner']' returned non- zero exit status 1. The above exception was the direct cause of the following exception: Traceback (most recent call last): File "/build/python-mod/src/mod- df62c20c053024953a800b26d94599e10a1fdf38/ setup.py", line 35, in <module> setup( File "/usr/lib/python3.11/site-packages/setuptools/__init__.py", line 102, in setup _install_setup_requires(attrs) File "/usr/lib/python3.11/site-packages/setuptools/__init__.py", line 75, in _install_setup_requires _fetch_build_eggs(dist) File "/usr/lib/python3.11/site-packages/setuptools/__init__.py", line 80, in _fetch_build_eggs dist.fetch_build_eggs(dist.setup_requires) File "/usr/lib/python3.11/site-packages/setuptools/dist.py", line 636, in fetch_build_eggs return _fetch_build_eggs(self, requires) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/usr/lib/python3.11/site-packages/setuptools/installer.py", line 38, in _fetch_build_eggs resolved_dists = pkg_resources.working_set.resolve( ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/usr/lib/python3.11/site-packages/pkg_resources/__init__.py", line 829, in resolve dist = self._resolve_dist( ^^^^^^^^^^^^^^^^^^^ File "/usr/lib/python3.11/site-packages/pkg_resources/__init__.py", line 865, in _resolve_dist dist = best[req.key] = env.best_match( ^^^^^^^^^^^^^^^ File "/usr/lib/python3.11/site-packages/pkg_resources/__init__.py", line 1135, in best_match return self.obtain(req, installer) ^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/usr/lib/python3.11/site-packages/pkg_resources/__init__.py", line 1147, in obtain return installer(requirement) ^^^^^^^^^^^^^^^^^^^^^^ File "/usr/lib/python3.11/site-packages/setuptools/installer.py", line 103, in _fetch_build_egg_no_warn raise DistutilsError(str(e)) from e distutils.errors.DistutilsError: Command '['/usr/bin/python', '-m', 'pip', '--disable-pip-version-check', 'wheel', '--no- deps', '-w', '/tmp/tmp6tjq_fpq', '--quiet', 'pytest-runner']' returned non-zero exit status 1. ==> ERROR: A failure occurred in build(). Aborting... [1] https://aur.archlinux.org/account/MarsSeed/ [2] https://aur.archlinux.org/pkgbase/python-mod/

1 year, 5 months

Re: [aur-requests] Rules evasion: repeatedly re-uploading deleted packages (Was: [PRQ#23352] Deletion Request for rtl8821ce-dkms)

by Eli Schwartz

On 1/28/21 5:57 PM, Doug Newgard via aur-requests wrote: > On Thu, 28 Jan 2021 22:49:58 +0000 > notify--- via aur-requests <aur-requests(a)lists.archlinux.org> wrote: > >> alium [1] filed a deletion request for rtl8821ce-dkms [2]: >> >> hi, >> rtl8821ce-dkms use git source (but -git suffix missing) and it is >> practically the same package as >> https://aur.archlinux.org/packages/rtl8821ce-dkms-git/ (maintained by >> driver developer). So there are two package, which are same. >> >> Thank you. >> >> [1] https://aur.archlinux.org/account/alium/ >> [2] https://aur.archlinux.org/pkgbase/rtl8821ce-dkms/ > > It has also been deleted twice already, and the maintainer keeps re-uploading > it. > > https://lists.archlinux.org/pipermail/aur-requests/2020-December/047147.html > https://lists.archlinux.org/pipermail/aur-requests/2020-December/047680.html > > Along with the -lts variants (seriously, and dkms package for the -lts kernel). I agree that this should not be done, and I'm not sure why it was re-uploaded after being deleted for good reason. If a package is deleted by a Trusted User, it MUST NOT be re-uploaded unless the person re-uploading it is confident that the reason it was originally deleted no longer applies. Knowingly and intentionally violating this qualifies as rules evasion and will not be tolerated. It is the responsibility of the person wishing to re-upload the package to verify that it is reasonable to re-upload (e.g. deleted due to lack of interest rather than being a violation of the rules of submission). I strongly recommend doing your due diligence. If in doubt, ask a Trusted User on the mailing list or in Freenode IRC's #archlinux-aur channel. Mounir Erhili, I'll give you the benefit of the doubt and assume you overlooked the email alert that the package was deleted, and you git pushed without realizing it was removed. Twice in a row. :/ However, I will require your written confirmation that you realize the problem, will be more careful in the future, and this will not occur again. I've suspended your account for now, so you will not be able to accidentally or deliberately repeat the infraction before seeing this email. Please respond to this email and confirm that you've received the warning. Then I will agree to re-enable your account. -- Eli Schwartz Bug Wrangler and Trusted User

4 years, 6 months

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

by Guillaume Horel

Openblas is a performance oriented package, microarchitecture optimization is exactly what it's about. Moreover this PKGBUILD has different build options than the official one which is allowed by the guidelines. On Mon, Jul 3, 2023 at 11:32 AM Marcell Meszaros <marcell.meszaros(a)runbox.eu> wrote: > > The package in community provides the dynamic arch version, whereas this > one will be specifically tuned for your current architecture. > > But this is not a good enough reason to keep PKGBUILDs for the same source > in both Arch repo and on AUR. > > Arch is not a binary-only distribution: all the build scripts are availabe. > > One can always grab a couple of PKGBUILDs from Arch repo's GitLab for > fine-tuned, microarchitecture-optimized rebuild, if that is what they want. > > But AUR submission guidelines are quite clear: they don't mention allowing > duplication for this purpose. > > > On 2 July 2023 17:34:03 GMT+02:00, Guillaume Horel < > guillaume.horel(a)gmail.com> wrote: > >> This is not the exactly the same package. The package in community >> provides the dynamic arch version, whereas this one will be specifically >> tuned for your current architecture. >> I've responded in the comments that there is nothing broken at the moment >> with this package, and I don't see the need to delete it. >> >> On Sun, Jul 2, 2023 at 7:17 AM <notify(a)aur.archlinux.org> wrote: >> >>> MarsSeed [1] filed a deletion request for openblas-lapack [2]: >>> >>> Same package is now in [extra], named blas-openblas: >>> >>> https://archlinux.org/packages/extra/x86_64/blas-openblas/ >>> >>> See announcement about it: >>> https://archlinux.org/news/openblas-0323-2-update-requires-manual- >>> intervention/ >>> <https://archlinux.org/news/openblas-0323-2-update-requires-manual-intervent…> >>> >>> I have notified AUR maintainers in comments about their need to review >>> this change, and possibly adapt their PKGBUILD's. >>> >>> [1] https://aur.archlinux.org/account/MarsSeed/ >>> [2] https://aur.archlinux.org/pkgbase/openblas-lapack/ >> >>

2 years, 1 month

Re: [aur-requests] [PRQ#15312] Orphan Request for qbittorrent-dark-git

by Vladislav Suratov

Sure, Plasma forces Qt applications to look in the same way, but Gnome doesn't have such ability by default, and qBittorent looks very bright. Maintainers of this project refused this request (as well as change) from me https://github.com/qbittorrent/qBittorrent/pull/5076 and I support it for AUR and Windows with my fork, which is this current package. So, I am not happy for deletion request and I ask you to cancel this request. P.S. They are going to add probably add this https://github.com/qbittorrent/qBittorrent/pull/10702 but I don't think I will stop to support my fork. On Fri, Jun 28, 2019 at 3:44 PM Yurii Kolesnykov <root(a)yurikoles.com> wrote: > qBittorrent 4.1.6 honors KDE Plasma Dark Mode, I haven't checked in GNOME. > > пт, 28 черв. 2019 о 14:47 Vladislav Suratov <suratovvlad(a)gmail.com> пише: > > > > Hi Yurii, > > > > What do you mean about dark mode in stable? > > Have they added it to the 4.1.6? or released 4.2.0 already? > > > > On Fri, Jun 28, 2019 at 2:33 PM <notify(a)aur.archlinux.org> wrote: > >> > >> yurikoles [1] filed a orphan request for qbittorrent-dark-git [2]: > >> > >> Dark mode already in stable and obviously git. > >> > >> [1] https://aur.archlinux.org/account/yurikoles/ > >> [2] https://aur.archlinux.org/pkgbase/qbittorrent-dark-git/ >

6 years, 1 month

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

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