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

[PRQ#52617] Orphan Request for python-sphinxcontrib-confluencebuilder

by notify＠aur.archlinux.org

MarsSeed [1] filed an orphan request for python-sphinxcontrib- confluencebuilder [2]: Broken Python2/Python3 package. Needs maintainer attention, or otherwise it will eventually become a candidate for deletion. Last updated: 2022-10-03. Flagged out-of-date: 2023-06-30. [1] https://aur.archlinux.org/account/MarsSeed/ [2] https://aur.archlinux.org/pkgbase/python-sphinxcontrib-confluencebuilder/

1 year, 11 months

[PRQ#58362] Orphan Request for openssl-1.0-chacha20

by notify＠aur.archlinux.org

MarsSeed [1] filed an orphan request for openssl-1.0-chacha20 [2]: Broken. Flagged since 2024-02-22. Please fix or disown. (Or file it for deletion, as this variant is not actually useful due to it using an experimental cipher that no server uses as an exclusive cipher.) [1] https://aur.archlinux.org/account/MarsSeed/ [2] https://aur.archlinux.org/pkgbase/openssl-1.0-chacha20/

1 year, 8 months

[PRQ#67167] Orphan Request for mingw-w64-libsearpc

by notify＠aur.archlinux.org

MarsSeed [1] filed an orphan request for mingw-w64-libsearpc [2]: Unused library. Can be considered for deletion. Last updated: 2015-07-23 Flagged out-of-date: 2024-03-19 [1] https://aur.archlinux.org/account/MarsSeed/ [2] https://aur.archlinux.org/pkgbase/mingw-w64-libsearpc/

1 year

Re: [PRQ#43370] Deletion Request for find-orb-git

by Marcell Meszaros

I see. Well, fine. It's your call them. :) On 2 July 2023 10:48:38 GMT+02:00, Yuriy Ivanov <yuriy.ivanov.spb(a)gmail.com> wrote: >In debian they are called correctly. There are several projects. I noticed it just now: > >https://salsa.debian.org/debian-astro-team/pluto-find-orb > >https://salsa.debian.org/debian-astro-team/pluto-jpl-eph > >https://salsa.debian.org/debian-astro-team/pluto-lunar > >https://salsa.debian.org/debian-astro-team/pluto-sat-code > > >02.07.2023 11:45, Marcell Meszaros пишет: >>> It should be called "pluto-find-orb-git" >> Why? >> >> I don't think so. >> >> The name of the application is "Find_orb". [a] >> >> Developed as part of the Pluto Project. >> >> So I think the current AUR package name can remain. >> >> [a]:https://www.projectpluto.com/find_orb.htm >> >> On 2 July 2023 07:58:27 GMT+02:00,notify@aur.archlinux.org wrote: >>> Mr.Smith1974 [1] filed a deletion request for find-orb-git [2]: >>> >>> Please remove the package, because I made a mistake with the name. It >>> should be called "pluto-find-orb-git" >>> >>> [1]https://aur.archlinux.org/account/Mr.Smith1974/ >>> [2]https://aur.archlinux.org/pkgbase/find-orb-git/

2 years, 5 months

Re: [aur-requests] [PRQ#28274] Deletion Request for petalinux-v2020.1

by Alex Henrie

On Tue, Sep 21, 2021 at 12:01 AM Amin Vakil <info(a)aminvakil.com> wrote: > > On 9/20/21 20:38, Alex Henrie wrote: > > On Sat, Sep 18, 2021 at 12:19 AM <notify(a)aur.archlinux.org> wrote: > >> > >> aminvakil [1] filed a deletion request for petalinux-v2020.1 [2]: > >> > >> https://aur.archlinux.org/packages/petalinux-v2021.1/ is already > >> present. > >> > >> [1] https://aur.archlinux.org/account/aminvakil/ > >> [2] https://aur.archlinux.org/pkgbase/petalinux-v2020.1/ > > > > I'm surprised that petalinux-v2020.1, petalinux-v2020.2, and > > petalinux-v2020.3 were deleted from the AUR. It would be nice to have > > the older versions in the AUR because the latest version (2021.1) is > > not 100% compatible. And the AUR has lots of old versions of other > > packages like gcc-arm-none-eabi-bin, so why not petalinux? > > > > $ yay -Ssq gcc-arm-none-eabi > > gcc-arm-none-eabi-bin-92 > > gcc-arm-none-eabi-bin-83 > > gcc-arm-none-eabi-bin-63 > > gcc-arm-none-eabi-bin-72 > > gcc-arm-none-eabi-bin-73 > > gcc-arm-none-eabi-bin-102 > > gcc-arm-none-eabi-bin-93 > > gcc-arm-none-eabi-bin-49 > > gcc-arm-none-eabi-bin-82 > > gcc-arm-none-eabi-bin > > Thanks for bringing this up, I've submitted deletion requests for all of > them as well. Are you going to delete all the old versions of GCC for x86 too (gcc34, gcc43, gcc44, gcc45, gcc46, gcc47, gcc48, gcc49, gcc5, gcc53, gcc6, gcc7, gcc8, gcc9)? And if so, why? gcc10 was even promoted out of the AUR. -Alex

4 years, 2 months

[PRQ#43417] Deletion Request for ytmenu-git

by notify＠aur.archlinux.org

MarsSeed [1] filed a deletion request for ytmenu-git [2]: Badly packaged, seemingly hobby project. Runs curl inside package() to download a source file script that is already downloaded from declared git repo. Short-term effort project, from Feb to April 2022, plus one arbitrary commit in Jun 2022. [a] The ytmenu shell script has an option to update itself during runtime, upon which it silently executes curl to fetch the latest commit version of the script and send it to STDOUT, but that gets redirected to a shell variable. It uses the following URL: https://raw.githubusercontent.com/DemonKingSwarn/ytmenu/main/ytmenu The script then tries to use the patch command to update the contents of ytmenu shell script file that is currently running, with the source that is stored in the shell variable. Btw the package does not declare depends and makedepends for curl, nor depens for patch. (curl is not part of 'base'. It is a dependency of pacman, but pacman in theory could change it at any time in the future. And patch is only part of base-devel, not base.) There are so many grievous errors here that I don't have any confidence in author's code. There are proper alternatives to play and/or download videos via CLI. [a]: https://github.com/DemonKingSwarn/ytmenu/commits/main [1] https://aur.archlinux.org/account/MarsSeed/ [2] https://aur.archlinux.org/pkgbase/ytmenu-git/

2 years, 5 months

Re: [aur-requests] [PRQ#3401] Deletion Request for nuvolaplayer3

by Patrick Burroughs

On Tue, 26 May 2015 15:37:01 +0100 Michael Corrigan <ghost.vonage(a)gmail.com> wrote: > Good afternoon Celti, > > The git package refuses to compile for me. That is why I made this > package. You yourself commented on that package saying that it only > build with a version of vala that the git package does not depend > on. Once the git package is updated with this new dependency, I will > delete this package as requested. That's an upstream modification required, I'm pretty sure; it's not a matter of changing the AUR package to have a specific dependency. Regardless, it can currently be worked around by downgrading vala (which few other things depend upon). > Also the RPMs are coming from the stable branch of the repo. The RPMs are coming from the repository for the stable version of Fedora; they are still beta builds of NuvolaPlayer, clearly marked as such on the website. This is both a beta and a binary package and not marked as either. > Kind Regards, > Michael > On 26 May 2015 14:45, <notify(a)aur.archlinux.org> wrote: > > > Celti [1] filed a deletion request for nuvolaplayer3 [2]: > > > > Repackages a (beta) RPM when there's a perfectly good -git package > > to use. Should at the very least be renamed to > > nuvolaplayer-beta-bin. > > > > [1] https://aur.archlinux.org/account/Celti/ > > [2] https://aur.archlinux.org/pkgbase/nuvolaplayer3/

10 years, 6 months

[aur-requests] [PRQ#36123] Deletion Request for turpial

by notify＠aur.archlinux.org

lucaswerkmeister [1] filed a deletion request for turpial [2]: Turpial <https://github.com/satanas/Turpial/> is Python 2 software, and thus this package cannot be built as several of its python2 dependencies have gone. I don’t see any sign of development towards a Python 3 version, neither in Turpial’s branches <https://github.com/satanas/Turpial/branches> nor in a fork <https://github.com/satanas/Turpial/network>. There *is* a python3 branch of the underlying libturpial library <https://github.com/satanas/libturpial/tree/python3>, as MarsSeed pointed out. I don’t know what it’s used for, if not for a Python 3 version of Turpial. (It looks like a first-time contributor sent some Python 3 conversion pull requests, and the maintainer merged them into the python3 branch; that doesn’t necessarily mean that the maintainer has any further plans for this branch, or that the contributor is going to send further pull requests.) I propose to: * delete turpial, turpial-git, and libturpial from the AUR * point libturpial-git to the python3 branch * potentially, recreate turpial, turpial-git and/or libturpial later if Python 3 versions or releases ever show up Deleting the packages is up to y’all; I’m happy to update the libturpial-git package, but want to wait with that for what you decide for the packages. I could also imagine other outcomes, such as deleting all the packages (I personally haven’t used Turpial in years), or just leaving them around in their current state. What do you think? [Procedural note: I’m not subscribed to the mailing list, I hope that’s okay.] [1] https://aur.archlinux.org/account/lucaswerkmeister/ [2] https://aur.archlinux.org/pkgbase/turpial/

3 years, 5 months

[PRQ#49537] Deletion Request for bin32-firefox

by notify＠aur.archlinux.org

MarsSeed [1] filed a deletion request for bin32-firefox [2]: Seems this package is not much used anymore, and not very actively maintained, so maybe it's best to delete it. It is still on v116.0.3 as of now, whereas upstream is already on v119.0. Also this package is for a foreign binary build, so it has a wrong pkgname (should have been bin32-firefox-bin). Last user comment apart from mine is from 2020. I don't see a point for end-users to run a 32-bit browser on a 64-bit system. It is unnecessarily memory-constrained, but apart from that, there's no difference. On the other hand, the native-built Firefox is very tame when it comes to RAM usage, and it can be tweaked further to minimize the memory footprint, if that's what one's use case calls for. ArchLinux32 repo's Firefox is outdated as of now, but the currently latest stable v119.0 i686 and pentium4 builds seem to be in the pipeline, after dropping the i486 build. But this package is not useful at all for ArchLinux32. There is a firefox-bin PKGBUILD on AUR, so ArchLinux32 users could ask its maintainers to just add upstream's 32-bit build if they wanted to. So far, it hasn't happened. AUR submission guidelines state that packages kept here must be useful to more than a few people. I don't see this one hitting that particular bar anymore - hence this deletion proposal. [1] https://aur.archlinux.org/account/MarsSeed/ [2] https://aur.archlinux.org/pkgbase/bin32-firefox/

2 years, 1 month

[PRQ#67757] Orphan Request for python-etcd3

by notify＠aur.archlinux.org

MarsSeed [1] filed an orphan request for python-etcd3 [2]: Flagged since 2024-03-05 for needing untagged patch commits from upstream. Seems though that the project is abandoned, so I'm not sure if this package is viable going forward. Can be evaluated later for deletion, if its maintenance status remains unchanged. [1] https://aur.archlinux.org/account/MarsSeed/ [2] https://aur.archlinux.org/pkgbase/python-etcd3/

11 months, 3 weeks

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