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

Re: [PRQ#50635] Deletion Request for quasar-client

by Philip A Reimer

I'm fine with this being deleted. Especially if it is possible to resubmit this under the same name if at the time it is still available. I am part of the upstream project which has a year or two ago been upgraded to Qt5. The new upstream url is https://quasaraccounting.com/ . I don't think anybody is using the current aur packages. On Mon, Nov 13, 2023, 11:47 AM Marcell Meszaros <marcell.meszaros(a)runbox.eu> wrote: > +1 for deletion, as this Qt3 based package has not been updated since > 2015, and is broken. > > It uses foreign binaries built for Kununtu 14.04, and its legacy icu52 > dependency from AUR has been abandoned for years, and fails to build. > > But no one noticed it: there are no comments from plain users whatsoever. > (There's only one comment, from 2013, made by maintainer.) > > On 9 November 2023 15:32:16 GMT+01:00, notify(a)aur.archlinux.org wrote: > >mhdi [1] filed a deletion request for quasar-client [2]: > > > >The upstream url is dead. > > > >[1] https://aur.archlinux.org/account/mhdi/ > >[2] https://aur.archlinux.org/pkgbase/quasar-client/ >

2 years, 1 month

Re: [aur-requests] [PRQ#27234] Deletion Request for telegram-desktop9

by Caleb Maclennan

On 2021-07-25 06:48, notify--- via aur-requests wrote: > grawlinson [1] filed a deletion request for telegram-desktop9 [2]: > > Caters to one person, quite niche. > > [1] https://aur.archlinux.org/account/grawlinson/ > [2] https://aur.archlinux.org/pkgbase/telegram-desktop9/ I posted this in the AUR comments before deleting, but in the event the author didn't have notifications turned on I'm copying it here for posterity: ---- There are quite a few reasons this build doesn't belong on the AUR. Individually maybe no one of them pushed it over the line but I think all together they make a case this doesn't belong here. If you want to fork telegram, go right ahead but 1) don't call it official when it's so patched up as to be completely different, 2) store the sources off the AUR somewhere on your own such as a Github repo, 3) don't link the upstream URL to the official site, link your fork, 4) don't post things that are only personal convenience. If they are useful for others that's fine, but make a project out of it, then come here to package it. Don't make the AUR the project. ----

4 years, 4 months

Re: [aur-requests] [PRQ#36746] Deletion Request for ngxtop

by Marcell Meszaros

Correction; It seems its Python 3 port, ngxtop-ce is also discontinued. But anyhow, ngxtop itself is still a defunct project and this package doesn't work because of the missing Py2 dependency. I think this CLI app was likely not essential, otherwise it would not have become ababdoned. There should be supported ways to gather metrics from a running Nginx server and its internal processes already. On 3 August 2022 06:07:31 GMT+02:00, notify(a)aur.archlinux.org wrote: >MarsSeed [1] filed a deletion request for ngxtop [2]: > >Dead Python2 based project - got forked to ngxtop-ce (available on >AUR). The latter supports Python3. > >Meanwhile this package is defunct, because its mandatory dependency >python2-tabulate is gone, and AUR/python2-tabulate-git does not >actually >support Python 2 anymore so it needs to be dropped. > >Safe to delete - nothing depends on it as it is an end-user CLI app. >Moreover, the continuation fork - ngxtop-ce - is already mentioned >here in a comment from 2020 so users had a chance to get informed >about it. > >[1] https://aur.archlinux.org/account/MarsSeed/ >[2] https://aur.archlinux.org/pkgbase/ngxtop/

3 years, 4 months

[PRQ#51462] Deletion Request for python-thrift-sasl

by notify＠aur.archlinux.org

MarsSeed [1] filed a deletion request for python-thrift-sasl [2]: I've considered helping out with this Python library package here, but realized it isn't worth it. It has been abandoned since 2021 not just on AUR but also by upstream. [a] It is practically broken for real-world use cases, see issue #28. [b] Upstream is not a garage project or a lone individual, but billion dollar revenue commercial company Cloudera, with a strong presence and participation in open-source technologies. Which means that if they did see a practical use case for themselves and/or any of their clients, who do use a wide variety of cloud stack elements, then they wouldn't have left this to become obsolete and burdened with use-case breaking bugs. Also there are just a few comments on the few issues in their GitHub, which is also an indication that this is not in need by people and projects. Also nothing depends on it. Safe to delete. [a]: https://github.com/cloudera/thrift_sasl [b]: https://github.com/cloudera/thrift_sasl/issues [1] https://aur.archlinux.org/account/MarsSeed/ [2] https://aur.archlinux.org/pkgbase/python-thrift-sasl/

2 years, 1 month

[PRQ#50540] Deletion Request for balsa-gtk2

by notify＠aur.archlinux.org

MarsSeed [1] filed a deletion request for balsa-gtk2 [2]: Unbuildable old version of balsa from 2013. Has been broken for years on AUR at least due to broken dependencies, then missing Python2 deps, then incompetently replaced deps. But this package's owner did nothing to fix these issues or communicate with those who can remedy them. It seems though that this build has zero prospective users on AUR, so it's not beneficial to keep. Also, there's virtually no pure-Gtk2 desktop environments available from not just the Arch repo but from the AUR as well. So it's not practical to stick to decade-old versions of GUI applications just for the sake of gtk2. (AUR has the 'gtk3-classic' package, which is a community-maintained patched "fork" of gtk3, tailored for non-GNOME desktops and those people who prefer the more traditional desktop GUI experience akin to what gkt2 provided. The project welcomes further contributions as well.) The current version of balsa, released in 2022, is available in extra repo. It uses the gtk3 toolkit. [1] https://aur.archlinux.org/account/MarsSeed/ [2] https://aur.archlinux.org/pkgbase/balsa-gtk2/

2 years, 1 month

[PRQ#49388] Deletion Request for ffmpeg-obs

by notify＠aur.archlinux.org

MarsSeed [1] filed a deletion request for ffmpeg-obs [2]: Arch extra repo carries obs-studio and ffmpeg, and the two seem to work just fine with each other. OBS studio carries two very minimal, one-line patches for ffmpeg. One is a crude hack for flvdec (FLV decoder), to handle 'TYPE_UNKNOWN'. FLV is practically a dead format (Flash Video). This patch makes FFMPEG accept FLV files with malformed/nonexistent header, which is not really something that people would need in general. The other is for AOMenc, minimally changing the default quality preset - which is configurable via command line option anyway. Hardy any of these changes are essential. Please kindly delete this package, it doesn't seem worth the trouble to keep it. In case there is a bug with OBS Studio and its use of FFMPEG, please file a bug report in Arch bug tracking system and preferably with upstream as well (OBS and/or FFMPEG, whichever is relevant). This is what the AUR submission guidelines is asking for as well, instead of creating duplicates of repo packages on AUR. [1] https://aur.archlinux.org/account/MarsSeed/ [2] https://aur.archlinux.org/pkgbase/ffmpeg-obs/

2 years, 1 month

[PRQ#42586] Deletion Request for python-setuptools-scm-git-archive

by notify＠aur.archlinux.org

MarsSeed [1] filed a deletion request for python-setuptools-scm-git- archive [2]: "This plugin is obsolete. ``setuptools_scm >= 7.0.0`` supports Git archives by itself." [a] As per my checking, only one maintained package has this declared in their 'requires' (python-vispy), but that can and should be easily patched to be removed. This was already confirmed by upstream issue ticket. I've notified the maintainer. This legacy package was recreated for python-vispy instead of removing it from its requires definition. I've also left comments or flags on the few other, abandoned AUR consumer packages' pages. But those are seemingly leftovers and not used by anyone. (However, none of those packages' 'requires' list include setuptools_scm_git_archive, so only the PKGBUILDs need to drop it in these packages.) This package was rightly dropped from Arch repos. python-vispy packaging needs to fix the issue instead of having this package on AUR. And this deprecated package is better to be deleted. [a]: https://github.com/Changaco/setuptools_scm_git_archive#readme [1] https://aur.archlinux.org/account/MarsSeed/ [2] https://aur.archlinux.org/pkgbase/python-setuptools-scm-git-archive/

2 years, 5 months

[PRQ#46598] Deletion Request for ping-bin

by notify＠aur.archlinux.org

MarsSeed [1] filed a deletion request for ping-bin [2]: Problematic orphan binary package from 2020: - Downloads the release DEB through insecure HTTP even though HTTPS server source is available. - Does not use install command in package(), it just extracts the 'data.tar.xz' from the DEB and keeps all privileges from the archive. - Package is broken as there are several direct dependencies that are undeclared and not satisfied by existing ones. - Also this is a desktop application but there is no desktop integration, no .desktop file, no icons, nada. - On top of it all, the pkgname could have been better, as /usr/bin/ping is in Arch repo's iputils package, part of the 'base' metapackage, so this is confusing. Upstream's last release is from 2019 and no development happened since 2020. [a] As this is a graphical REST HTTP API testing client, there are several well-maintained alternatives so there is no loss in deleting this misleading and wrongly put together PKGBUILD. [a]: https://github.com/jeremyvaartjes/ping [1] https://aur.archlinux.org/account/MarsSeed/ [2] https://aur.archlinux.org/pkgbase/ping-bin/

2 years, 3 months

[PRQ#75053] Deletion Request for opencode

by notify＠aur.archlinux.org

envolution [1] filed a deletion request for opencode [2]: Maintainer is aware that including binary packages in a non-bin namespace is not correct, and continues committing updates here several times daily. This package has been merged and deleted based on this more than once: https://lists.archlinux.org/archives/list/aur- requests(a)lists.archlinux.org/message/IDPYIMVZ2UHDINZNWLMFDC27IUYS5ZRZ/ https://lists.archlinux.org/archives/list/aur- requests(a)lists.archlinux.org/message/QQGT4YFLYRFFZN536CIVHMIPTJWZOHP7/ Maintainer has confirmed his intention of only submitting binary releases in: https://lists.archlinux.org/archives/list/aur- requests(a)lists.archlinux.org/message/HTTWLJSRHPWHJNUEUAVKS2ULI5XR7ER6/ Maintainer has been informed that this package is a duplicate of aur/opencode-bin and suggested it was an error (1 month ago) https://aur.archlinux.org/packages/opencode-bin#comment-1030701 Maintainer was contacted letting him know his CI actions were recreating aur/opencode with binaries here: https://aur.archlinux.org/packages/opencode#comment-1033898 and here: https://github.com/sst/opencode/issues/1358 His new reasoning is that it's to prevent namesquatters. I am concerned that deleting this package will (again) only be a temporary measure - considering opencode-bin seems popular, and is generated by the project's github actions - maybe at least for now block the opencode namespace or free up both to allow others them as per the guidelines [1] https://aur.archlinux.org/account/envolution/ [2] https://aur.archlinux.org/pkgbase/opencode/

4 months, 2 weeks

Re: [aur-requests] [PRQ#9294] Deletion Request for linux-aufs_friendly

by Calimero

Le 28/09/2017 à 18:32, notify(a)aur.archlinux.org a écrit : > Alad [1] filed a deletion request for linux-aufs_friendly [2]: > > Obscured PKGBUILD, dead upstream patchset, EOL upstream version. Also > maintainer comment: > > "For some time now, OverlayFS has been able to do everything I've been > using AUFS for. I'll continue maintaining this, but I won't be using > it myself and suggest that AUFS users take a look at the latest > version of OverlayFS (which can do several branches, too)." > > [1] https://aur.archlinux.org/account/Alad/ > [2] https://aur.archlinux.org/pkgbase/linux-aufs_friendly/ Hello, I admit that I was very slow fixing that package, but I did it now, and I'm maintaining it again. Two people reacted in the comments in the hope that I would fix it, so it seems useful to at least someone. As for the comment I pinned about OverlayFS, mdevaev answered that as well: round-robin writes are a valid reason why someone would use AUFS. OverlayFS does not have that feature. When properly updating the package version to 4.13 (4.11 is indeed EOL), we're on a branch where the last commit is from 6 days ago [1] so it seems to me that the patchset is well-maintained, no worries here. Could deletion be reconsidered? Thanks [1] https://github.com/sfjro/aufs4-standalone/tree/aufs4.13

8 years, 2 months

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