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

[PRQ#39098] Deletion Request for fly-cli

by notify＠aur.archlinux.org

pancho [1] filed a deletion request for fly-cli [2]: This package's payload is already provided by concourse-fly-cli¹ (which predates it), being thus redundant. concourse-fly-cli is a well-maintained package, following current packaging best practices for Go binaries, and tracking upstream releases on a timely manner. It also packages the rest of the components of the Concourse CI system. OTOH, this package has several issues that are not being addressed, see my comment² from two months ago. I thus request its deletion, so that the users can find a single, well maintained package of the Concourse CI system in the AUR. Also note that my previous request for deletion has just been rejected by muflone, because the package was updated in the interim. The update was just a version bump, which did not address any of the issues the package has. Thanks a bunch, and happy hacking. ¹: https://aur.archlinux.org/packages/concourse-fly-cli ²: https://aur.archlinux.org/packages/fly-cli#comment-881656 I'll reproduce the comment here: pancho commented on 2022-09-15 08:03 (UTC) (edited on 2022-09-15 08:05 (UTC) by pancho) Hi, @lilac and @Sasasu! Thanks for providing and keeping up-to-date this package! Just a friendly heads-up, regarding the handling of pkgrel: remember to reset it to just 1 whenever pkgver is bumped. For example, when 7.8.3 comes out, besides updating pkgver to reflect that, also reset pkgrel to 1. Othewise the pkgrel will keep going up with no end in sight :-) See ¹ for rationale. Also, I would like to suggest that you perhaps might join forces (and packages) with @cheatsc, since you both provide this package (see their implementation on ². Please note that @cheatsc's packaging not only provides fly but the rest of the concourse system. It would be nice for the AUR users to find a single, well packaged option for an otherwise complex offer. Also note that @cheatsc's package is very well maintained, and follows³ current best practices 4 for building Go binaries. ¹: https://wiki.archlinux.org/title/PKGBUILD#pkgrel ²: https://aur.archlinux.org/packages/concourse-fly-cli ³: https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=concourse#n41 4: https://wiki.archlinux.org/title/Go_package_guidelines#Flags_and_build_opti… Hope that it helps. Friendly, pancho [1] https://aur.archlinux.org/account/pancho/ [2] https://aur.archlinux.org/pkgbase/fly-cli/

3 years

Re: [PRQ#46166] Deletion Request for gnuradio-maint38-git

by Nick Østergaard

Yeah, I agree. On Mon, 4 Sept 2023, 15:16 Marcell Meszaros, <marcell.meszaros(a)runbox.eu> wrote: > Upstream stated they have no intention or capacity to maintain the legacy > gnuradio 3.8 branch. > > This git package does not provide 'gnuradio38' [a], so it has no > dependents, only the latter does. > > But both this and that package fails to build. > > The few dependents of 'gnuradio38' are all dead and fail to build as well, > or some of them actually have upstream updates or third-party forks that > work with gnuradio 3.10. > > So keeping this package is completely superfluous in my view. > > [a]: https://aur.archlinux.org/packages/gnuradio38?all_reqs=1#pkgreqs > > > On 13 August 2023 06:46:05 GMT+02:00, "Nick Østergaard" <oe.nick(a)gmail.com> > wrote: > >> Hi >> >> I am not sure that is fair as such, people could be using it for legacy >> oot modules, and there is someone trying it out at least two weeks ago, see >> https://github.com/gnuradio/gnuradio/issues/6762 >> >> I must admit, that I have not touched it in a while. >> >> Nick >> >> On Sun, 13 Aug 2023 at 01:35, <notify(a)aur.archlinux.org> wrote: >> >>> MarsSeed [1] filed a deletion request for gnuradio-maint38-git [2]: >>> >>> gnuradio 3.8 is not maintained since >>> 2022-03 (last release 2022-01). [a] >>> >>> Nothing depends on this VCS package. >>> >>> I recommend deletion. >>> >>> [a]: https://github.com/gnuradio/gnuradio/commits/maint-3.8 >>> >>> [1] https://aur.archlinux.org/account/MarsSeed/ >>> [2] https://aur.archlinux.org/pkgbase/gnuradio-maint38-git/ >> >>

2 years, 3 months

Re: [PRQ#42162] Deletion Request for libopenblas

by sL1pKn07 SpinFlo

yes if a new user tries to install itself in local. If try to install it with openblas in repo, it fails because file conflicts. and if forced to install, when trying to build a 64 bits program with 64bits openblas, gets link failed because cmake found the 32bit libs because new cmake files point to it (see the bug report). so no, i think need solve the bug report first , then can you delete it without mercy greetings El jue, 15 jun 2023 a las 0:37, Marcell Meszaros (< marcell.meszaros(a)runbox.eu>) escribió: > The linked bug report should be addressed, but that does not necessitate > keeping AUR/libopenblas. > > As there is no lib32-(lib)openblas package and nothing in AUR seem to need > a multilib version of openblas. > > Also, AUR submission guidelines also mandate no copying of repo packages > to address packaging bugs/requests, but to have them resolved via bug > report. > > As for x86_64 builds on AUR requiring openblas, they should find the CMake > files of repo openblas package just fine. > > > On 15 June 2023 00:05:59 GMT+02:00, sL1pKn07 SpinFlo <sl1pkn07(a)gmail.com> > wrote: > >> >> >> El jue, 15 jun 2023 a las 0:02, <notify(a)aur.archlinux.org> escribió: >> >>> MarsSeed [1] filed a deletion request for libopenblas [2]: >>> >>> This has not been needed for quite some time, as Arch repo carries >>> openblas, including its libs, and it can be installed side-by-side >>> with blas. >>> >>> [1] https://aur.archlinux.org/account/MarsSeed/ >>> [2] https://aur.archlinux.org/pkgbase/libopenblas/ >> >> >> https://bugs.archlinux.org/task/78725 >> >> greetings (sorry if dupped, but not CC all) >> >

2 years, 6 months

Re: [aur-requests] [PRQ#10977] Deletion Request for arc-gtk-theme-git

by Stelios Tsampas

On Sun, Mar 25, 2018 at 4:48 AM, Eli Schwartz via aur-requests < aur-requests(a)archlinux.org> wrote: > On 03/24/2018 09:20 PM, Stelios Tsampas via aur-requests wrote: > > On Sun, Mar 25, 2018 at 4:10 AM, notify--- via aur-requests > > <aur-requests(a)archlinux.org <mailto:aur-requests@archlinux.org>> wrote: > > > > Eschwartz [1] filed a deletion request for arc-gtk-theme-git [2]: > > > > duplicate of gtk-theme-arc-git > > > > [1] https://aur.archlinux.org/account/Eschwartz/ > > <https://aur.archlinux.org/account/Eschwartz/> > > [2] https://aur.archlinux.org/pkgbase/arc-gtk-theme-git/ > > <https://aur.archlinux.org/pkgbase/arc-gtk-theme-git/> > > > > > > gtk-theme-arc-git should be deleted, arc-gtk-theme-git follows the > > naming of the package in community > > 1) I dislike the naming schema NicoHood used in [community] and IMHO he > should change it. It strikes me as terribly unintuitive. > > 2) The naming schema of the package in community is irrelevant, as this > is not the package in community and you are not allowed to submit > duplicate packages to the AUR and then attempt to browbeat the > maintainer of the original package into giving up his package. > > If you would like to politely *request* that he rename his package, and > agree to respect his choice, then I will respect his decision (which > does imply that it is his decision). > > ... > > It may be my personal opinion that things should be gtk-theme-foo and > that foo-gtk-theme is "wrong", but I'm not going to enforce my opinion > on others as it is sort of a bikeshed. > > I will pretty aggressively enforce my disapproval of the cavalier > attitude taken in uploading and re-uploading arc-gtk-theme-git. > > There were duplicate packages. The older package takes precedence. The > newer package is very firmly a duplicate, and should not continue to be > re-uploaded in contravention of its initial deletion. That just smacks > of disrespecting the administrative decisions that have *already been > declared*. > > ... > > I'm rather pissed off, and tremendously so, that someone pressured him > into orphaning his package. I'm also deeply confused, what on earth is > even going on here? > > The new maintainer then proceeded to abuse his new maintenance of > gtk-theme-arc-git by breaking the pkgver and using some terrible > abomination, then hiding this in amongst a bunch of trivial style changes. > > This does not impress me with his *capabilities* as an AUR maintainer, > so why should I trust his opinions on the naming any more? > > -- > Eli Schwartz > Bug Wrangler and Trusted User > > By mistake I sent the email from a different address than one I use in AUR, I am sorry for the confusion that it may have cause I am involved with neither of those packages, I am just pointing out that there is a naming schema, good or bad, in community and I made my suggestion on that. If there is a history between those packages, I wasn't aware of it, and if your decision is based on that, I respect it and don't have a say in the matter.

7 years, 8 months

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

by Eli Schwartz

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 > -- Eli Schwartz Bug Wrangler and Trusted User

6 years

Re: [PRQ#40147] Deletion Request for josm-stable

by RubenKelevra

I know the rules and followed it: - If the official package is out-of-date, flag it as such. This was done more than *seven* month ago (2022-07-06). - If the official package is broken or is lacking a feature, then please file a bug report. It's lacking an active maintainer. I created a bugreport, not because it is out of date, but because of non-active maintenance. https://bugs.archlinux.org/task/75049 This bug was closed with a pretty baffling comment instead of beeing handled. So I decided to make a fork here, just to make an updated package available to everyone and to avoid that more tickets will be created by other people. I like to stress that I don't want to maintain this package - I would be really happy to delete it again, as soon as it gets maintained in the official package repository. --- Now after more than seven months I created another ticket, because of the lacking maintenance. https://bugs.archlinux.org/task/77460 This resulted in this deletion request for my aur package and another closure request for my created account ticket - instead of getting the actual issue resolved. I don't get why users get punished just because they want to make issues known, or provide a temporary maintenance. I don't like this tone of communication which seems to be the norm here. Please provide guidance. Best regards and thanks in advance! Ruben Kelevra 11.02.2023 16:23:02 notify(a)aur.archlinux.org: > yochananmarqos [1] filed a deletion request for josm-stable [2]: > > Duplicate of josm community package. > > "The submitted PKGBUILDs must not build applications already in any of > the official binary repositories under any circumstances. Check the > official package database for the package. If any version of it > exists, do not submit the package. If the official package is out-of- > date, flag it as such. If the official package is broken or is lacking > a feature, then please file a bug report." > > -- > https://wiki.archlinux.org/title/AUR_submission_guidelines#Rules_of_submiss… > > [1] https://aur.archlinux.org/account/yochananmarqos/ > [2] https://aur.archlinux.org/pkgbase/josm-stable/

2 years, 10 months

[PRQ#45471] Deletion Request for tar-parallel

by notify＠aur.archlinux.org

MarsSeed [1] filed a deletion request for tar-parallel [2]: Referring to package creator Henry Graham's response for a previous AUR orphan request of mine (PRQ#45311), where he said he doubts this is still useful: I agree with that assessment, and I think this outdated variant/duplicate of repo's tar can be deleted. In my opinion, it's not worth the trouble. Especially if there are errors or potential problems with using this alternative build. Originally I would have though that a software such as tar is simple, but I've come to realize that the exact opposite is true. It is handling very complicated varieties of scenarios and runtime environments, so every release contains myriads of fixes, enhancements and refinements, along with lots of edge case handling. This current AUR package is 2 point releases behind upstream, whereas Arch repo carries the latest version. Tar is a dependency of Arch's base metapackage, which means that it should be part of every Arch Linux installation. Also because of this, it is not strictly mandatory for every Arch/AUR package to declare their dependency on tar, even if said package relies on it. Tar can be configured on-the-fly to be used with compression tools; I think it is best to resort to such case-by-case usage while having Arch repo's unchanged tar package installed on the system. This AUR package has no votes, and only owner commented in 2021, about his efforts in the background trying to fix some errors with tar 1.33 → 1.34 update (current upstream and repo version is 1.35) It was also me who flagged this package a year ago for v1.34. So it seems there is no evidence of user demand for this package. I've only found it because I was looking for (old) duplicates and variants. [1] https://aur.archlinux.org/account/MarsSeed/ [2] https://aur.archlinux.org/pkgbase/tar-parallel/

2 years, 4 months

Re: [aur-requests] [PRQ#11108] Deletion Request for emacs-rudel-bzr

by Eli Schwartz

On 04/10/2018 09:51 PM, Stefan Husmann wrote: > It may be doable but it is not easy. someone would have to write a tool > that does something like what is done by cabal2arch for haskell packages > for emacs lisp packages. No-one has written such a tool yet. > > As far as I understand the process, package.el loads e single emacs lisp > file from git://git.savannah.gnu.org/emacs/elpa.git which takes care for > the rest, i.e. fetching stuff from sourceforge, installing them locally > in a subdirectory of the user's home directory and integrating them into > the emacs infrastructure. Repeating these steps in bash for makepkg is > tedious. Well, if it is just a matter of the source code moving elsewhere, I'm not sure why that matters, since the current package does this anyway. It sounds like it would be a simple matter of modifying the checkout to clone from git instead of bzr, switching the pkgname suffix, and uploading to a new pkgbase. But of course, if no one is interested in maintaining this regardless, then lack of interest in switching to the git checkout would be reason enough to just get rid of this package altogether. I guess since it would need to be either deleted or merged, there's no real reason to first see if anyone cares enough to upload a git package... it's not like there are votes to preserve via merging. -- Eli Schwartz Bug Wrangler and Trusted User

7 years, 8 months

[PRQ#47520] Deletion Request for nvidia-pf

by notify＠aur.archlinux.org

MarsSeed [1] filed a deletion request for nvidia-pf [2]: It is not useful to keep this badly and sporadically maintained package. I've explained the problems in a comment in 2023-06, as well as in emails to the maintainer. He was unwilling to address those, and he still does not even regularly update the version. Also he updates his linux-pf package a bit more frequently than this - which in many cases breaks this package. My comment from 2023-06-22, the day of the last update: " This new version is wrong. It just repackages the current, fixed version of repo nvidia-dkms for the linux-pf kernel that is currently installed. The package will prevent pacman sysupgrade the instant repo pushes a new version update to nvidia-utils (because of this versioned depends). It will also break when there is a new linux-pf update without a new nvidia-pf update. It can also potentially break if there is a simultaneous new linux-pf update and nvidia-pf bump, if the user just builds linux-pf without immediately installing it, then builds nvidia-pf, then wants to install both. (The reason behind the latter is this line of PKGBUILD [*a], which was designed for a specific setup of build steps - building, then installing the intended kernel version before creating the nvidia module package.) It's better to just rely on nvidia-dkms, which will do the correct thing every time there's a new linux-pf update and won't ever prevent sysupgrade. My recommendation still stands: delete this package, no one has used it for the last 2-3 years, and no one needs to." [*a]: https://tinyurl.com/nvidiapfPKGBUILDline10 (full URL: https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=nvidia- pf&id=41a9a1a8ff04697ba72292684aff010d3920336e#n10 ) [1] https://aur.archlinux.org/account/MarsSeed/ [2] https://aur.archlinux.org/pkgbase/nvidia-pf/

2 years, 2 months

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

by Marcell Meszaros

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

2 years, 6 months

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