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

Re: [aur-requests] [PRQ#7738] Deletion Request for casablanca-git

by Alexander Shukaev

On 03/19/2017 06:39 PM, Doug Newgard wrote: > On Sun, 19 Mar 2017 17:33:19 +0000 (UTC) > notify(a)aur.archlinux.org wrote: > >> A.Shukaev [1] filed a deletion request for casablanca-git [2]: >> >> I need to change my e-mail address in the commit. Since force push is >> disabled, I cannot do it myself. If somebody could either delete the >> package or enable force push so that I can repush it, I'd be very >> grateful! >> >> [1] https://aur.archlinux.org/account/A.Shukaev/ >> [2] https://aur.archlinux.org/pkgbase/casablanca-git/ > > Just fix it, commit, and push. I can't see any reason why the current commit > has to be changed. > Because the e-mail address is invalid in the first commit. I actually have no pending updates to the package. I only want to fix the e-mail address by amending it in the existing commit. Nobody uses this package anyway yet.

8 years, 9 months

Re: [PRQ#49028] Deletion Request for android-platform-dummy

by Marcell Meszaros

In re to my remark, >I don't know why this one would be particularly useful. Having a dummy package installed defeats the purpose of using a package manager. If a package requires another package, there's a good reason for it, and both should be installed in the system for them to work. No one forces anyone to install Android IDE's and Android SDK's / platform tools into the system. They can live happily inside the user's home folder as well. In that case, the user is not using pacman to manage those installations. On 15 October 2023 12:15:04 GMT+02:00, notify(a)aur.archlinux.org wrote: >MarsSeed [1] filed a deletion request for android-platform-dummy [2]: > >According to some TU's, dummy packages are not allowed on AUR. > >I don't know why this one would be particularly useful. > >[1] https://aur.archlinux.org/account/MarsSeed/ >[2] https://aur.archlinux.org/pkgbase/android-platform-dummy/

2 years, 2 months

Re: [PRQ#62416] Deletion Request for quiterss-git

by Fabio Loli

> MarsSeed [1] filed a deletion request for quiterss-git [2]: > > It seems this has become obsolete because it depends on the > increasingly more frequently breaking component qt5-webkit, EOL since > 2017. > > As of now, all providers of that lib, the qt5-webkit, qt5-webkit-git, > qt5-webkit-movableink-git AUR packages fail to build, due to different > reasons each (and this has been the case for at least 2-3 months). > > Upstream has not been maintained since 3 years ago. [a] > > Meanwhile the continuation fork, AUR/quiterss2-git [b] has been ported > to the currently supported qt5-webengine, and therefore it can still > be built and used. > > [a]: https://github.com/QuiteRSS/quiterss.git > [b]: https://aur.archlinux.org/packages/quiterss2-git > > [1] https://aur.archlinux.org/account/MarsSeed/ > [2] https://aur.archlinux.org/pkgbase/quiterss-git/ At least qt5-webkit builded fine as of 7 Aug 2024, it isn't failing to build for months

1 year, 4 months

Re: [PRQ#46161] Deletion Request for openfoam2.4-git

by Marcell Meszaros

And btw default dependency 'parmetis' fails to build for the last ~6+ months. On 18 November 2023 14:06:37 GMT+01:00, Marcell Meszaros <marcell.meszaros(a)runbox.eu> wrote: >Also the build gracefully skips compiling many components including example and demo apps because of errors. This indicates that the library itself is having problems. > >Many missing headers are also reported, and lots of C++17 standard incompatibilities, which result in ignored class specifiers. But no one mentioned any of the issues. The build product is most certainly not properly usable anymore. > >On 13 August 2023 00:04:33 GMT+02:00, notify(a)aur.archlinux.org wrote: >>MarsSeed [1] filed a deletion request for openfoam2.4-git [2]: >> >>Development discontinued since 2015. [a] >> >>I think there's not much point in keeping this VCS package. >> >>[a]: https://github.com/OpenFOAM/OpenFOAM-2.4.x >> >>[1] https://aur.archlinux.org/account/MarsSeed/ >>[2] https://aur.archlinux.org/pkgbase/openfoam2.4-git/

2 years

[PRQ#41450] Deletion Request for pridefetch-laureegrd-git

by notify＠aur.archlinux.org

laureegrd [1] filed a deletion request for pridefetch-laureegrd-git [2]: Several reasons to ask for the deletion of this package: - It was never properly set up. I apologize for that. I created it the correct way (I think) but then I messed up on updating it and correcting a wrong dependency. - The name is very wrong, and I had to include my username on it to differentiate it from another package that is based on Neofetch instead of pfetch, creating more confusion. To make things worse, I am migrating my accounts to new ones with a different name, so upstream is no longer available for this package. - No one is actually using it, as it was borked. - I plan on figuring it out and some point and creating a new package that works as expected and doesn't have any names attached. I already have a good name planned for it. Once again, I apologize for the inconvenience this caused, and I hope this can be left in the past. Thanks in advance. [1] https://aur.archlinux.org/account/laureegrd/ [2] https://aur.archlinux.org/pkgbase/pridefetch-laureegrd-git/

2 years, 7 months

[aur-requests] [PRQ#34961] Deletion Request for kubesec

by notify＠aur.archlinux.org

MarsSeed [1] filed a deletion request for kubesec [2]: Orphaned package. The application itself is legacy. Last release happened in 2018; last commit was in 2019. This was a security module for Kubernetes, to manage 'secrets' (token keys, passwords, etc.) for cloud instances. The build is broken because of problems in the PKGBUILD itself. Also the code uses the now deprecated Golang Glide dependency manager. I think it's safe to assume that cloud security related management tools should be kept up-to-date, or otherwise cannot be trusted. 'Secrets' management is one of the central concepts and features of Kubernetes cloud management/instrumentation platform. Therefore I am certain that there do exist currently supported and maintained toolkits for such use cases and this old application is not needed anymore. It might be possible to make it build again but IMHO it's not worth the hassle, on the merits of the points above. Nothing depends on this on AUR so it's safe to delete. [1] https://aur.archlinux.org/account/MarsSeed/ [2] https://aur.archlinux.org/pkgbase/kubesec/

3 years, 6 months

Re: [PRQ#62415] Deletion Request for deadbeef-qt5-git

by Marcell Meszaros

On 20 August 2024 15:35:15 GMT+02:00, Fabio Loli <fabio.loli(a)disroot.org> wrote: >> begin-theadventu [1] filed a deletion request for deadbeef-qt5-git >> [2]: >> >> There's a working fork of the same project >> >> https://aur.archlinux.org/packages/deadbeef-qt5-git#comment-977674 >> >> [1] https://aur.archlinux.org/account/begin-theadventu/ >> [2] https://aur.archlinux.org/pkgbase/deadbeef-qt5-git/ > >Deletion requests are not for commenting, the pkgbuild is already orphan Quoting a comment from the AUR page: hippieben commented on 2024-01-20 04:39 (UTC) Seems to be abandoned. Code hasn't been touched in 3 years, build fails and throws a ton of deprecation warnings. Unfortunate. Hopefully someone can bring this back to life. PKGBUILD fails, as does building directly from repo with posted instructions. QT keeps marching on and this project has fallen behind. And then there is @ begin-theadventu's newer comment from 2024-06-11: https://aur.archlinux.org/packages?K=deadbeef-plugin-gui-qt5 fork of the same project. Edit: Qt 6 branch: https://aur.archlinux.org/packages?K=deadbeef-plugin-gui-qt6

1 year, 4 months

[aur-requests] [PRQ#33987] Deletion Request for troff-git

by notify＠aur.archlinux.org

MarsSeed [1] filed a deletion request for troff-git [2]: I'd say this AUR package is not useful to keep. The contents of the package is a subset of and partial duplicate of the contents of the following packages: groff (part of group base-devel): https://archlinux.org/packages/core/x86_64/groff/ plan9port: https://archlinux.org/packages/community/x86_64/plan9port/ It says it's "a port of Plan9 troff". It declares that it provides=troff but it doesn't say conflicts=troff. The package puts binaries in /usr/troff/bin. It is not added to the user's PATH envvar. There is only one dependent (consumer) of this on AUR, and it only optionally depends on this. Since the functionality provided by this package is already covered by Arch repo packages, there is zero need for this mismatching alternative package that has not been properly configured to work with other Arch packages. So there is only a benefit in deleting this, no harmful impact. [1] https://aur.archlinux.org/account/MarsSeed/ [2] https://aur.archlinux.org/pkgbase/troff-git/

3 years, 8 months

[aur-requests] [PRQ#11035] Deletion Request for v86d

by notify＠aur.archlinux.org

jghodd [1] filed a deletion request for v86d [2]: v86d and uvesafb-dkms depend on each other. since uvesafb was removed from the kernel config, and now has to be provided as an AUR package, both of these packages have to be provided together as a single unit. otherwise, v86d must depend on uvesafb-dkms, and uvesafb-dkms must depend on v86d. this is a circular dependency that doesn;t work. i've temporarily removed v86d from the uvesafb-dkms package and added v86d as an optional dependency, but this is a problem - uvesafb-dkms needs v86d to function. it's not optional. the only other option i have is to push the exact same packaging to both with different package names and remove their dependency on each other. and that's just stupid. one of these packages needs to go and be absorbed into the other. i believe that v86d should go and should become part of uvesafb-dkms. [1] https://aur.archlinux.org/account/jghodd/ [2] https://aur.archlinux.org/pkgbase/v86d/

7 years, 8 months

[PRQ#48069] Deletion Request for biicode

by notify＠aur.archlinux.org

MarsSeed [1] filed a deletion request for biicode [2]: Broken, not just because of totally incompetent packaging, missing half a dozen undeclared Python2 dependencies, but also because this is an online-only package manager tool, like the pacman -S functionality, or pip install [modulename], without an available server. If someone installs the required Python2 packages, biicode just makes a web call to a nonexistent Heroku PaaS container with a hardcoded URL: https://biiserverproduction.herokuapp.com/ And then it does not do anything: all it responds every time is, even to the '--help' invocation: ERROR: None or bad command. Type "bii --help" for available commands The company that created biicode is defunct since 2015. This tool is dead without its online repository / metadata server. By the way the package bundles not just the client but the server as well, which is totally bogus. And also defunct, relying on a long-EOL mongodb server. [1] https://aur.archlinux.org/account/MarsSeed/ [2] https://aur.archlinux.org/pkgbase/biicode/

2 years, 2 months

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