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

Re: [PRQ#46142] Deletion Request for zfs-dkms-helper

by Marcell Meszaros

The zfs project's latest stable release does not officially support Linux 6.4.* yet, but your metapackage allows that version. If someone installs zfs for that kernel version, they should already be aware that it can break at any point release of it. Your package doesn't "help" in that area. If someone wants to be certain that zfs does not break with their kernel, they should install it for a supported version, which on current Arch is only the LTS kernels (6.1.x). Also 'helper' packages are usually meant to have some executable in them, but this package is empty. On 13 August 2023 04:52:52 GMT+02:00, Bin Jin <bjin(a)ctrl-d.org> wrote: >This is a meta package I created to prevent future mainline linux updates >breaking zfs-dkms packages. zfs-dkms is closely tied to linux kernel >versions and has a compatibility layer to add specific support for each >major linux kernel release (e.g. "6.x"). > >So zfs-dkms has long been worried about linux kernel upgrades, a major >upgrade could make dkms fail, and this happened a few times in the past >since Arch is very edge on kernel version upgrades. > >For users using zfs as root, this become critical if dkms is not noticed >during "pacman -Syu". The system won't boot for next reboot. > >This meta package will be updated for each zfs release, and updating the >linux kernel version upperbounds accordingly. > ><notify(a)aur.archlinux.org> 于 2023年8月13日周日 00:34写道： > >> MarsSeed [1] filed a deletion request for zfs-dkms-helper [2]: >> >> Unneeded new metapackage. Name doesn't make sense, and description is >> also not really understandable. >> >> Users can install any linux kernel and the zfs-dkms module for it, or >> a kernel-specific zfs module. This package does not add anything >> useful, and it also has a hidden upper version constraint, which is >> unnecessary. >> >> [1] https://aur.archlinux.org/account/MarsSeed/ >> [2] https://aur.archlinux.org/pkgbase/zfs-dkms-helper/

2 years

Re: [PRQ#46835] Deletion Request for python2-flask

by Marcell Meszaros

I forgot to add that actually python2-flask has been continuously broken since its submission to AUR in 2022-11, because repo dropped many Python2 modules around that time, and not all of python2-flask's dependencies were recreated on AUR. The required python2-jinja's dependencies were also among the missing ones. It also got deleted on Feb 25, 2022 (PRQ#32767). The latter has been (re)uploaded to AUR on 2022-05-22, but without declaring its mandatory requirement, python2-markupsafe. (Which no longer exists on AUR.) No one mentioned this issue on python2-flask's page. (In fact it has no comments at all.) And only I submitted a comment on python2-jinja's page about the missing dependency, in Aug 2023, because I was testing another downstream package when I ran into this blocking issue. +1: python2-flask needs python2-click, which was removed from its PKGBUILD depends array on 2023-06-29. But no one complained. It is clear that this package has not been in a usable state *ever* on AUR. On 29 August 2023 19:34:08 GMT+02:00, notify(a)aur.archlinux.org wrote: >MarsSeed [1] filed a deletion request for python2-flask [2]: > >This legacy Python2 version of the Flask web application framework is >not needed or useful to keep. > >For production purposes it is not just deprecated but also insecure. > >Current AUR consumer python2-flask-table is already broken due to >missing another dependency. > >And python2-requests only optdepends on it, but actually this was >originally a checkdepend of that. However, I found out last year that >executing the test suite of that package would have required >recreating an excessively large and complex dependency chain just for >the purpose of testing that one build. Therefore I decided to put >python2-requests' checkdepends in its optdepends, and make the test >execution inside check() get launched only if all of the optionally >defined checkdepends are satisfied. > >As several of python2-requests' optional checkdepends don't exist on >AUR, no check() function gets run by its PKGBUILD. So at this point, >the current maintainer of python2-requests would do best to remove >those optdepends, as they are superfluous. > >Safe to drop this package; no negative impact. > >[1] https://aur.archlinux.org/account/MarsSeed/ >[2] https://aur.archlinux.org/pkgbase/python2-flask/

2 years

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

2 years

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, 4 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, 4 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, 5 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/

2 years

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

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