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

Re: [aur-requests] [PRQ#16805] Deletion Request for the-darkmod-tweaked

by Alberto Salvia Novella

On 26/11/19 2:27, notify(a)aur.archlinux.org wrote: > eschwartz [1] filed a deletion request for the-darkmod-tweaked [2]: > > After discussion in the package comments for thedarkmod-bin, it was > determined that the custom installer used in the former package > "darkmod" violated the rules of submission on numerous levels. > > The package was reimplemented by a Trusted User, and for good measure > cleaned up and renamed to something more closely matching upstream > intentions, but for all this, the core issue with > https://gitlab.com/es20490446e/the-darkmod-tweaked had nothing to do > whether mv is better than cp, or whatever else this justification > entails: > > ``` > So I'm providing an alternative version for this package, called "the- > darkmod-tweaked", with the following enhancements over the official > bundle: > > Separated saved games and downloaded mission repository for each > user. > Missions cache auto-cleanup. > Enhanced installation speed compared with the official installer. > ``` > > No, this is not acceptable. Your new package is still obfuscation and > violates the rules of submission. > > Your "tweaks" in comparison with thedarkmod-bin do not answer the > question: "why was the previous package orphaned via moderator > action". > > You may not re-upload a package which was deemed inadmissible to the > AUR, and simply rename the pkgname in order to justify its existence. > You are REQUIRED to either: > - first defend your claim that the initial judgment "this is unfit for > the AUR" was incorrect, or > - fix the problems > > You have done neither. > > [1]https://aur.archlinux.org/account/eschwartz/ > [2]https://aur.archlinux.org/pkgbase/the-darkmod-tweaked/ Even when I thought that could piss you off, I genuinely believed that would fall within the rules. Now you suspended my account, and destroyed all my work on Arch. But that was a less risky decision than keeping you around. Your purpose was never to enforce good practices but to boycott. What you call quality standards won't allow me to reach my goals. You don't care about the contents of the book, you only care about how well it's written.

5 years, 8 months

Re: [PRQ#47124] Deletion Request for lib32-net-snmp

by Marcell Meszaros

No, it is not needed in AUR wine builds. And neither you nor any other user has provided any use case existing today where one would need lib32-sane. On 10 September 2023 15:35:41 GMT+02:00, sL1pKn07 SpinFlo <sl1pkn07(a)gmail.com> wrote: >thats is because none of the packages on aur is builded with lib32-sane >support, but yes. is indeed needs in custom builds > >sl1-wine-git W: Dependency sane detected but optional (libraries >['usr/lib/libsane.so.1'] needed in files >['usr/lib/wine/x86_64-unix/sane.so']) >sl1-wine-git W: Dependency lib32-sane detected but optional (libraries >['usr/lib32/libsane.so.1'] needed in files >['usr/lib32/wine/i386-unix/sane.so']) > >greetings > >El dom, 10 sept 2023 a las 15:30, Marcell Meszaros (< >marcell.meszaros(a)runbox.eu>) escribió: > >> >PRQ#45251 is for lib32-sane? also needs for wine >> >> This is also not true. Only the 64-bit sane is linked to by multilib/wine, >> and none of the AUR wine package depend on lib32-sane as well. >> >> >> On 10 September 2023 09:19:45 GMT+02:00, sL1pKn07 SpinFlo < >> sl1pkn07(a)gmail.com> wrote: >> >>> >>> >>> El dom, 10 sept 2023 a las 9:17, sL1pKn07 SpinFlo (<sl1pkn07(a)gmail.com>) >>> escribió: >>> >>>> >>>> >>>> El sáb, 9 sept 2023 a las 13:42, <notify(a)aur.archlinux.org> escribió: >>>> >>>>> MarsSeed [1] filed a deletion request for lib32-net-snmp [2]: >>>>> >>>>> This unmaintained, unused package can be deleted as well after >>>>> PRQ#45251. >>>>> >>>>> [1] https://aur.archlinux.org/account/MarsSeed/ >>>>> [2] https://aur.archlinux.org/pkgbase/lib32-net-snmp/ >>>> >>>> >>>> needs for wine >>>> >>>> greetings >>>> >>> >>> PRQ#45251 is for lib32-sane? also needs for wine >>> >>> greetings >>> >>

1 year, 11 months

Re: [aur-requests] [PRQ#11354] Deletion Request for firefox-always-nightly

by Morgan Adamiec

On 10 May 2018 at 22:36, Félix Saparelli <felix(a)passcod.name> wrote: > How do I tell this request to, politely, go away? > > always-nightly has a number of differences to -nightly, not just the > "always" part of it. But if this is the main point of difference, then I > contest the claim that -nightly has "pretty good tracking". As a blatant > example, right now it is on 62.0a1.20180509, while always-nightly downloads > 62.0a1.20180510. > > There is also the fact that firefox nightly updates twice a day, not once, > so the -nightly package is never accurately tracking the latest. > > Some more occurences from the firefox-nightly comments: > > owstoni commented on 2017-08-02 22:15 > > 57 is out, could you post the new source? > > K900 commented on 2017-08-02 14:40 > > 57.0a1 is out now, needs a version bump. > > > tux-86 commented on 2017-07-21 20:11 > > Version string seems now 56.0a1.-1 > > > That's two fairly recent occasions where firefox-nightly was behind. The 57 > one shows no update in 8 hours at least. Firefox-always-nightly would have > produced the right version within a few minutes of the update actually going > out. That is why it exists. > > > On Fri, May 11, 2018 at 9:15 AM <notify(a)aur.archlinux.org> wrote: >> >> Morganamilo [1] filed a deletion request for firefox-always-nightly >> [2]: >> >> Duplicate of aur/firefox-nightly >> >> See https://lists.archlinux.org/pipermail/aur- >> general/2018-May/034080.html >> >> [1] https://aur.archlinux.org/account/Morganamilo/ >> [2] https://aur.archlinux.org/pkgbase/firefox-always-nightly/ I would think the rules on this would say it's still a duplicate. If there's problems they should be fixed, not have a new package pop up. Your PKGBUILD does a lot of hacky stuff that I don't know how to feel about it. using curl for global variables. Forcing an insanely high pkgver so that it always wants to update. It's not up to me though. I brought this up briefly in the linked thread and Eli seemed to agree so I thought I would send this request and see what happens.

7 years, 3 months

Re: [aur-requests] [PRQ#18963] Deletion Request for dxvk-winelib

by Christopher Snowhill

> On Wednesday, Apr 22, 2020 at 1:05 AM, Stelios Tsampas <loathingkernel(a)gmail.com (mailto:loathingkernel@gmail.com)> wrote: > On 4/22/20 8:20 AM, Christopher Snowhill (kode54) wrote: > > > > > > > On Apr 21, 2020, at 3:28 AM, Stelios Tsampas via aur-requests <aur-requests(a)archlinux.org> (mailto:aur-requests@archlinux.org) wrote: > > > > > > > > > On 4/21/20 11:53 AM, notify(a)aur.archlinux.org (mailto:notify@aur.archlinux.org) wrote: > > > > soredake [1] filed a deletion request for dxvk-winelib [2]: https://github.com/doitsujin/dxvk/commit/436357e28096f5e1e25aa8b72fceb77123… [1] https://aur.archlinux.org/account/soredake/ [2] https://aur.archlinux.org/pkgbase/dxvk-winelib/ > > > > > > The version pointed by the tag still builds correctly under wine. The commit you are pointing to > > > > > > > > > is after the tag built by this package. And even so, since this package builds correctly for this version, > > > > > > > > > what is the problem with it existing? Why should this be deleted? > > > > > > > > > > Are you suggesting that this package maintain a fork of the library which still supports winelib builds? Or instead that it continue to exist to build and install this old commit which will quickly become obsolete as further improvements are added past this commit? > > I am suggesting neither. If you bother to look at the commit history, since the tagged version `1.6.1` there > > > have been two commits at the time of writing, one of which is removing winelib support. There has been no > > > release neither any groundbreaking change. It is rather premature to request to delete a package that build the > > > latest version, especially without contacting the maintainer first about it. > > Also, allowing it to exist to build the last tagged version with winelib support is not unheard of and it has been done > > > with numerous python packages in the past of example as python2 support was being dropped. > > > > Ah, oops. I was not paying attention when I checked, and didn't realize they just did this in the latest revision of the project. Yeah, it should be fine to continue supporting this, at least for now. They may have had good reasons for dropping winelib support, though.

5 years, 3 months

Re: [PRQ#57938] Deletion Request for ocamlnet

by Marcell Meszaros

On 23 March 2024 14:55:10 GMT+01:00, Oliver Bandel <oliver(a)first.in-berlin.de> wrote: >Quoting Marcell Meszaros <marcell.meszaros(a)runbox.eu> (snt: 2024-03-23 07:22 +0100 CET) (rcv: 2024-03-23 07:22 +0100 CET): >> On 17 March 2024 14:30:01 GMT+01:00, notify(a)aur.archlinux.org wrote: >> >MarsSeed [1] filed a deletion request for ocamlnet [2]: >> > >> >Broken for close to 1 year due to not being compatible with repo's >> >ocaml 5, first published in May 2023. >> > >> >Upstream seems to be abandoned (developer only attends to their other >> >projects). >> > >> >There has been a work-in-progress, partially viable port to ocaml 5, >> >contributed to upstream in the form of a merge request 1.5 years ago, >> >but it has been abandoned and ignored since. [a] >> > >> >That unfinished patch does not make this buildable. Also, now the code >> >does not support the current gnutls, needed for https support in this >> >library. >> > >> >Downstream dependents have either moved on to other solutions, or got >> >discontinued 3+ years ago. (All AUR reverse dependencies have been >> >submitted for deletion.) >> > >> >I think it's best to delete this package. >> > >> >[a]: https://gitlab.com/gerdstolpmann/lib- >> >ocamlnet3/-/merge_requests/21 >> > >> >[1] https://aur.archlinux.org/account/MarsSeed/ >> >[2] https://aur.archlinux.org/pkgbase/ocamlnet/ >> >> >> The last package change is ill-conceived. The build stays broken. >> >> A package cannot depend on both 'ocaml' (v5) and 'ocaml4', as they conflict with each other. Still not useful to keep this library that is EOL for 3+ years. > >I asked the author of ocamlnet, if it was planned to update it for OCaml5. >The answer was yes. >So far there is no time plan for that, but next week I may habe more >information. > It was asked from developer of ocamlnet more than one year ago (Fev 2023), and he didn't bother to answer. [a] Also there were work-in-progress were pull request commits submitted, but dev couldn't care less. And the submitting users admitted they are facing some difficulties and had hit a roadblock in making the patch work properly. [a]: https://gitlab.com/gerdstolpmann/lib-ocamlnet3/-/issues/27

1 year, 4 months

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

by notify＠aur.archlinux.org

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#50209] Deletion Request for clash-premium-bin

by Marcell Meszaros

Adopting package, to facilitate quicker removal of this package whose release archives became unavailable. Former maintainer disowned it. Clarification about licensing (although IANAL): While an author / copyright holder can choose to relicense their originally GPL-licensed work under a nonfree license, as per GNU org's FAQ, in this particular case, it was a collaborative development project with many authors. So it follows (IMHO) to conclude that it could only have been relicensed with the express written permission of every participating author, which was not in place. It's sad that this enhanced version might be gone forever, although I hope others will take up the published code and add the missing capabilities. Also, while I particularly don't want to be petty about licensing when it comes to tools fighting for the freedom of people and against a totalitarian dictatorship, this package has no likelihood of ever being revived, with its closed source. And also this should serve as a lesson to every developer involved not to want to withhold their source code that facilitates access to free information in a closed-down society, lest this can happen. On 4 November 2023 02:28:54 GMT+01:00, notify(a)aur.archlinux.org wrote: >MarsSeed [1] filed a deletion request for clash-premium-bin [2]: > >Revenge of the Chinese Winnie the Pooh? > >GitHub repo deleted (404). [a] > >And in this particular case, there's no possibility of finding forks, >because this package was using prebuilt binaries made by the author >who chose to deliberately violate his own original clash software's >GPL license by not disclosing the derivative source code of 'Clash >Premium'. [b] > >Btw it's creepy that several PRC censorship evasion software repos >were deleted on the same day: November 3, 2023. And many other related >ones owned by different people were archived on that date. > >[a]: https://github.com/Dreamacro/clash/ >[b]: >http://web.archive.org/web/20231025223859/https://github.com/Dreamacro/clas… > >[1] https://aur.archlinux.org/account/MarsSeed/ >[2] https://aur.archlinux.org/pkgbase/clash-premium-bin/

1 year, 9 months

[PRQ#52568] Deletion Request for libelectron

by notify＠aur.archlinux.org

xiota [1] filed a deletion request for libelectron [2]: This package should be deleted because it compromises the security of the systems on which it is installed. This package is a customized electron build that the maintainer uses for his personal projects, which use Electron as a web browser to navigate some streaming media websites. It essentially duplicates the functionality of the `electron` packages, but with incorrect naming and unknown modifications. In addition to creating a man-in-the-middle scenario, this package compromises the security of its users by disregarding upstream security recommendations. Notably, Electron is *not* a web browser. Although it uses the same rendering engine as Chromium, it is not Chromium, and it does not have the same security features Chromium does. On the contrary, Electron intentionally has reduced security because it is intended for desktop apps, not web browsing. At [Security](https://www.electronjs.org/docs/latest/tutorial/security), Electron developers state: > A security issue exists whenever you receive code from an untrusted source (e.g. a remote server) and execute it locally. As an example, consider a remote website being displayed inside a default BrowserWindow. If an attacker somehow manages to change said content (either by attacking the source directly, or by sitting between your app and the actual destination), they will be able to execute native code on the user's machine. The maintainer's apps that use this package do what Electron devs describe avoiding: ``` const mainWindow = new BrowserWindow(...) ... mainWindow.loadURL('https://...') ``` This package also has multiple packaging defects that the maintainer is resistant to fixing. Even if they were fixed, the security implications described above would remain. * Does not guard path variables with quotes. Paths may contain spaces, which would not only break the script, but could damage users' systems. * Uses pkgrel in download link. Link will break when pkgrel is bumped. * Potentially missing provides/conflicts, since this is duplicating function of `electron` packages. * Runs a non-standard secondary setup script instead of including the commands directly in the PKGBUILD. This makes the package more difficult to review for malicious content. [1] https://aur.archlinux.org/account/xiota/ [2] https://aur.archlinux.org/pkgbase/libelectron/

1 year, 7 months

Re: [aur-requests] [PRQ#5273] Merge Request for tensorflow-git

by Nicholas O'Callaghan

I agree it would be nice to be able to share the common C++ library and then have separate bindings for other languages, although based on the current pip packages which come out of bazel (currently contain all the C++ binaries and related header files etc), it would require a lot of patching of the bazel builds to allow all the bindings to link with the C++ library. If anyone knows enough about bazel to properly set this up, without significant modification to the source, I'm happy to go with your approach, otherwise we will see what the trusted users prefer. On Mon, Apr 25, 2016 at 4:15 PM, Pieter ROBYNS <pieter.robyns(a)uhasselt.be> wrote: > I believe there's an issue to consider here. Tensorflow is not a Python > module. It is a C++ library that happens to provide Python bindings. > Bindings for other scripting languages (e.g. Go) could be introduced in the > future. There is a C API and C++ API as well, though these are - presently > - not as easy to use [1]. > > I'm wondering whether it would make more sense to have two packages: > "tensorflow" and "tensorflow-git", where both python2 and python3 bindings > are installed by default. A similar approach is taken in the "gnuradio" > package for example: it also provides a C++ library and the python2 > bindings are implicitly installed. > > Perhaps a TU can help decide which approach should be taken. If they > consider the python2-*, python-* approach to be cleaner, I will remove > "tensorflow-git" from the AUR. > > [1]: https://www.tensorflow.org/versions/r0.8/get_started/basic_usage.html > > 2016-04-25 7:41 GMT+02:00 <notify(a)aur.archlinux.org>: > >> qazokm [1] filed a request to merge tensorflow-git [2] into >> python2-tensorflow-git [3]: >> >> Ignore previous deletion request. Both packages are near identical >> just newer one supports CUDA. Can they be merged to prevent confusing >> over naming >> >> [1] https://aur.archlinux.org/account/qazokm/ >> [2] https://aur.archlinux.org/pkgbase/tensorflow-git/ >> [3] https://aur.archlinux.org/pkgbase/python2-tensorflow-git/ > > >

9 years, 3 months

Re: [PRQ#75194] Deletion Request for looking-glass

by O. Pakker

Hi, That's not at all what I said? I'm not sure where you're reading that. This request is filed in the context of the AUR and the PKGBUILD, which I /do/ maintain. I'm sorry for the delay in PKGBUILD updates and it'll need a bit more time. Best I could do this minute was adding the pinned message. I've rescheduled things here and I'll be working on getting my systems set up today. In regards to the host application specifically, I could remove the host build instructions from the PKGBUILD though it is news to me this has issues. Note that this deletion request is against the whole including the client not just the host. The host was/is included because it was and still is provided in the sources as well as the official upstream documentation without a deprecation note of any kind. Is the official upstream stance this component of looking-glass is deprecated, unmaintained and should no longer be used? Kind Regards, Omar Pakker On August 8, 2025 12:29:53 PM UTC, Geoffrey McRae <geoff(a)hostfission.com> wrote: >So you're telling me, the author of this project, that I am wrong? The Looking Glass Host application for Linux is UNMAINTAINED and does not work. Remove the looking-glass-host package please! > >On 2025-08-08 22:25, O. Pakker wrote: >> Hi, >> >> It is being maintained, unfortunately the binutils change coincided >> with me moving and as such I've not been able to do be on-top of >> rebuild bumps and such directly. >> I'm working on setting my systems back up this weekend so by Sunday it >> should be updated. >> >> I'll also add a message pin to not contact upstream if people >> encounter issues. I thought I had already done so but I guess I >> forgot. My sincere apologies for the noise that must have created the >> past week or so. >> >> Kind Regards, >> Omar Pakker >> >> On August 8, 2025 11:25:05 AM UTC, notify(a)aur.archlinux.org wrote: >> >>> gnif [1] filed a deletion request for looking-glass [2]: >>> >>> The `looking-glass-host` for Linux is unmaintained, incomplete and >>> non-functional. Please stop providing a package for it, you're >>> causing >>> us support issues. >>> >>> [1] https://aur.archlinux.org/account/gnif/ >>> [2] https://aur.archlinux.org/pkgbase/looking-glass/

5 days

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