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

Re: [PRQ#68006] Deletion Request for python-thinc-bin-8.3.2

by involution

The 312 wheel is the latest version provided upstream but appears to work fine with 313. This temporary package exists only to bridge the gap while python-spacy <https://aur.archlinux.org/packages/python-spacy> catches up to python-thinc <https://aur.archlinux.org/packages/python-thinc>. Without this package, all dependencies relying on python-spacy would break. I’m open to modifying the package but need clarification on the naming convention. Should it be *python-thinc-bin-3.8.3* or *python-thinc-3.8.3-bin*? Earlier discussions on this mailing list suggested that appending the version to the package name was correct (unrelated package), however this is indeed a '-bin' package normally I’m unsure about the preferred naming order in this case. On 2024-12-27 11:06 a.m., notify(a)aur.archlinux.org wrote: > MarsSeed [1] filed a deletion request for python-thinc-bin-8.3.2 [2]: > > Prebuilt binaries need to have a pkgname suffix '-bin'. > > Besides, the wheel used in source is only for Python 3.12, not 3.13. > > [1]https://aur.archlinux.org/account/MarsSeed/ > [2]https://aur.archlinux.org/pkgbase/python-thinc-bin-8.3.2/

11 months, 3 weeks

[PRQ#43604] Deletion Request for open-video-downloader-appimage

by notify＠aur.archlinux.org

MarsSeed [1] filed a deletion request for open-video-downloader- appimage [2]: Please don't upload AppImage binaries of Electron- (Chromium) based applications. These are hugely bloated and go against Arch's Electron application guidelines, namely that they should use and depend on one of the electron packages carried by Arch repo. I know that creating good quality packages is hard work, but that doesn't mean that it should be okay to spam the AUR with five hundred foreign binary packages which duplicate a lots of binary libraries and runtimes already existing in the Arch Linux operating system. This is not Windows, where bloat and duplication is the norm. Please learn and adhere to Linux principles. When there is source available, use primarily that to build and package an application. Or in case of Electron applications, you can choose to use the ASAR files with Arch repo's electron runtime, and create a -bin suffixed electron package. [1] https://aur.archlinux.org/account/MarsSeed/ [2] https://aur.archlinux.org/pkgbase/open-video-downloader-appimage/

2 years, 5 months

[PRQ#43605] Deletion Request for advanced-rest-client-appimage

by notify＠aur.archlinux.org

MarsSeed [1] filed a deletion request for advanced-rest-client- appimage [2]: Please don't upload AppImage binaries of Electron- (Chromium) based applications. These are hugely bloated and go against Arch's Electron application guidelines, namely that they should use and depend on one of the electron packages carried by Arch repo. I know that creating good quality packages is hard work, but that doesn't mean that it should be okay to spam the AUR with five hundred foreign binary packages which duplicate a lots of binary libraries and runtimes already existing in the Arch Linux operating system. This is not Windows, where bloat and duplication is the norm. Please learn and adhere to Linux principles. When there is source available, use primarily that to build and package an application. Or in case of Electron applications, you can choose to use the ASAR files with Arch repo's electron runtime, and create a -bin suffixed electron package. [1] https://aur.archlinux.org/account/MarsSeed/ [2] https://aur.archlinux.org/pkgbase/advanced-rest-client-appimage/

2 years, 5 months

Re: [PRQ#51750] Deletion Request for python-unittest-xml-reporting

by Marcell Meszaros

As of now, nothing depends on this broken EOL package on AUR. On 25 November 2023 14:12:19 GMT+01:00, notify(a)aur.archlinux.org wrote: >MarsSeed [1] filed a deletion request for python-unittest-xml- >reporting [2]: > >Broken on Python 3.11+ due to AttributeError. > >Active development stopped since January 2022. [a] >Upstream did not respond to query made in April 2023 about Python 3.11 >support plans. [b] > >This was only an optional checkdepend, to create additional XML output >from test results. > >I've notified the maintainers of the two current AUR consumers that >this package is broken and should be removed from (check/make)depends >and disabled in check() if necessary. > >Safe to delete, not useful to keep. (The two dependents are already >failing to build until maintainer takes action.) > >[a]: https://github.com/xmlrunner/unittest-xml- >reporting/commits/master >[b]: https://github.com/xmlrunner/unittest-xml-reporting/issues/277 > >[1] https://aur.archlinux.org/account/MarsSeed/ >[2] https://aur.archlinux.org/pkgbase/python-unittest-xml-reporting/

2 years

[aur-requests] [PRQ#35362] Deletion Request for rst-proto-stable-git

by notify＠aur.archlinux.org

MarsSeed [1] filed a deletion request for rst-proto-stable-git [2]: Orphaned VCS package. The https://projects.cor-lab.org website's SSL certificate has expired. Shows only an empty loginwall when HTTPS is skipped. No identification of what this was. Not even available from web.archive.org. (cor-lab.org redirects to "Cor-Lab" at the Universität Bielefeld: Research Institute for Cognition and Robotics.) From the dependencies it seems it was using Python 2: it's missing python2-protobuf. Google discontinued Python 2 support last year, and it is a binding for the binary protobuf library, so the old Python 2 code is now incompatible an unworkable. The source came from the site's hosted git repository. It also doesn't work anymore. The HTTP server enforces HTTPS but git refuses to connect due to the invalid certificate. Using the unsecured legacy git:// protocol leads to the server not responding at all (timeout). I was not able to find alternative sources or websites for the project, so it seems it's unmaintained and has been discontinued. Safe to delete this package; only AUR/rsb-process-monitor-git depends on it from the same dead project (deletion request to be submitted separately). [1] https://aur.archlinux.org/account/MarsSeed/ [2] https://aur.archlinux.org/pkgbase/rst-proto-stable-git/

3 years, 6 months

[PRQ#42837] Deletion Request for graceful-settings

by notify＠aur.archlinux.org

MarsSeed [1] filed a deletion request for graceful-settings [2]: There is no "Graceful Linux" distro. Google results only show unrelated stuff. The few AUR/graceful-* packages from user @dingjing are not useful. There are no documentation on how to put together a "Graceful Linux" themed, seemingly Qt and LightDM based custom install. Not even basic stuff, like what desktop framework/environment it supports. From GitHub commit history, it can be seen that actual code was developed only in 2020 and 2021. Since then, only packaging and metadata and comment/readme changes were done, many times quite randomly and without utility. There seems to have been one minor development addon commit in 2022. And so far all packages I've checked from @dingjing are badly packaged, suspicious, without documentation, and seemingly not useful for "outsiders" who lack information about what was going on in the creator's head. For all I know, this seems like a pet project of one Chinese-speaking person done mostly during the COVID quarantine years. [1] https://aur.archlinux.org/account/MarsSeed/ [2] https://aur.archlinux.org/pkgbase/graceful-settings/

2 years, 5 months

Re: [PRQ#50235] Orphan Request for lynx-dock

by Marcell Meszaros

I have filed a deletion request for this (PRQ#50280), as all Lynx desktop packages are not installable because of missing depends and other PKGBUILDs pointing to nonexistent sources, and also because no one is using these from AUR. On 4 November 2023 14:15:54 GMT+01:00, notify(a)aur.archlinux.org wrote: >kleintux [1] filed an orphan request for lynx-dock [2]: > >pkgbuild use sudo to install files direct to the filesystem. >maintainer did not react. want adopt and fix the package. > >[1] https://aur.archlinux.org/account/kleintux/ >[2] https://aur.archlinux.org/pkgbase/lynx-dock/

2 years, 1 month

[PRQ#50340] Deletion Request for pdfalto

by notify＠aur.archlinux.org

MarsSeed [1] filed a deletion request for pdfalto [2]: I am proposing to delete this from AUR, for the following reasons: - cannot download sources in clean chroot, - with git installed, linking phase fails after compilation, - there are many severe unresolved upstream issues (build/linking failure, crashes/segfaults with standard PDF features like comments, annotations). [a] Also: - This was an experimental tool to convert PDF files to ALTO, an obscure format conceived in the early 2000's as an open standard alternative to the then-proprietary formats like PDF, for archival purposes. - But nowadays, PDF is a royalty-free open standard, and its PDF/A derivative is specifically tailored for long-term archival and backward-forward compatibility. Upstream pdfalto is not actively maintained/developed: - last released in April 2021 [b], - a few newer commits from 2021, and one from 2022. [c] Does not seem to be used on AUR: - 1 vote, 0 comments, - no one mentioned the linking failure here. [a]: https://github.com/kermitt2/pdfalto/issues [b]: https://github.com/kermitt2/pdfalto/releases [c]: https://github.com/kermitt2/pdfalto/commits/master [1] https://aur.archlinux.org/account/MarsSeed/ [2] https://aur.archlinux.org/pkgbase/pdfalto/

2 years, 1 month

[PRQ#50370] Deletion Request for kf5-transition-dummy

by notify＠aur.archlinux.org

MarsSeed [1] filed a deletion request for kf5-transition-dummy [2]: This dummy package is not just bogus, but actually ill-conceived. Arch's KDE-Unstable repo kept KDE6 Frameworks package names intact, and most VCS packages for those components on AUR also already provide the KF6 build and kept the unsuffixed virtual provides names. E.g. 'kitemmodels' or 'kdoctools' are in Arch/KDE-Unstable, and also kitemmodels-git and kdoctools-git provide the same, respectively. Whereas Arch/extra has kitemmodels5 and kdoctools5. This pattern is true for several dozen packages now. So keeping the non-suffixed names to mean the KF6 variant is proper. This dummy package makes one think that there is some problem with that, but there isn't. And anyhow, dummy packages should not be used for tracking reverse dependencies, because these packages would just break builds and runtime libraries if ever installed. The VCS packages for KDE Frameworks and KDE Plasma components can serve the same purpose ('tracking') while also not providing any disfunction to AUR. [1] https://aur.archlinux.org/account/MarsSeed/ [2] https://aur.archlinux.org/pkgbase/kf5-transition-dummy/

2 years, 1 month

[aur-requests] [PRQ#36238] Deletion Request for alienvault-agent

by notify＠aur.archlinux.org

MarsSeed [1] filed a deletion request for alienvault-agent [2]: Orphaned package, version is from 2020. USM Anywhere and AlienVault are now part of "AT&T Cybersecurity". They don't seem to provide installation tarballs from their website. "USM Anywhere is a software as a service (SaaS) security monitoring solution that centralizes threat detection, incident response, and compliance management across your on-premises, cloud, or hybrid environments" "The AlienVault Agent is a lightweight endpoint agent based on osquery [...]. It enables endpoint detection and monitoring with central management, contributing to complete and effective threat visibility, detection, and compliance." As this package is abandoned, outdated, and there are no votes or comments, I suggest to delete it. I would think that only an "insider" (subscriber) to this service would possibly be able to adapt a PKGBUILD for the deployment of the current version. But this kind of software does not seem like one for a casual user to install on their own. Likely this requires centralized mass-deployment at an organization's fleet of client computers, providing customized configuration with that deployment. [1] https://aur.archlinux.org/account/MarsSeed/ [2] https://aur.archlinux.org/pkgbase/alienvault-agent/

3 years, 5 months

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