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

Re: [PRQ#46479] Deletion Request for exoscale-cli

by Philipp Sauter

Dear TU's and MarsSeed thank you for notifying us, pointing out the problem and the solution. We take the AUR guidelines seriously and will comply with them. I am working on this with priority and will fix it this week. Please let us handle this on our own and don't delete the package. Thank you. Regards, Philipp On Sun, Aug 20, 2023 at 2:29 AM <notify(a)aur.archlinux.org> wrote: > > MarsSeed [1] filed a deletion request for exoscale-cli [2]: > > Binary package in disguise, even though the source is available. > > This problem has not been addressed by any of the two maintainers, one > of whom is the upstream developer, for 2+ years. This is despite the > fact that it had been raised by @FabioLolix on 2021-08-17 in AUR > comment as well as in an upstream GitHub issue ticket. @FabioLolix > also submitted correct PKGBUILD's for a source-build package, a -bin > package and a -git variant to that GitHub issue. > > Dear TU's, please delete this package that is now clearly in > deliberate violation of AUR guidelines. > > [1] https://aur.archlinux.org/account/MarsSeed/ > [2] https://aur.archlinux.org/pkgbase/exoscale-cli/

2 years, 3 months

[PRQ#53690] Deletion Request for dcled

by notify＠aur.archlinux.org

a821 [1] filed a deletion request for dcled [2]: Orphan, out-of-date since 2017, one vote, one comment, one time effort. The last version (2.2) of this software was released exactly 10 years ago on 08-Feb-2014 [0]. I find weird that the maintainer decided to upload an older version in 2016 (1.9), because the github repo seems to be outdated compared to the last version, the link of which can be found on the same github page (he should have seen this). The PKGBUILD needs to be updated as in its current form is a disguised VCS (which broken sources by the way) and also the dependency on `libhid` is no longer necessary according to upstream [0]. However, this software is a controller for a USB message board that doesn't seem to be available anymore on Dream Cheeky (the link to it [1] on [0] redirects to something else), so I do not think this controller is useful (or worth fixing) without such board. In conclusion, given that it's orphan and unfixed for way too long, I think this can be deleted. [0] http://www.last-outpost.com/~malakai/dcled/ [1] http://www.dreamcheeky.com/index.php?pagename=product&pid=52 [1] https://aur.archlinux.org/account/a821/ [2] https://aur.archlinux.org/pkgbase/dcled/

1 year, 10 months

[aur-requests] [PRQ#12619] Deletion Request for linux-aufs_friendly

by notify＠aur.archlinux.org

eschwartz [1] filed a deletion request for linux-aufs_friendly [2]: This automatically clones the latest svntogit PKGBUILD from the official repos and applies unverified everything to it. It's completely hands-off maintenance and absolutely no verification is done to see whether it works. Even the maintainer has stated for the record that they don't use this, and only "maintain" it out of a sense of duty to theoretical? aufs users. Some problems with the current approach: - when no patches exist on https://github.com/sfjro/aufs4-standalone, attempting to download them fails. - when the official repository package is not in testing, attempting to download *this*, fails. Since no one tries to test the PKGBUILD before updating the pkgver (which does nothing as it is overwritten by sourcing the PKGBUILD from [testing]), these issues are not noticed by the maintainer. The theoretical aufs users probably don't exist, since if people were using this *they* would notice when it was broken. If anyone actually needs aufs, they are welcome to submit a new linux- aufs package that does this properly and is actually maintained. This would be in keeping with the way every other custom kernel is done in the Arch Linux community. [1] https://aur.archlinux.org/account/eschwartz/ [2] https://aur.archlinux.org/pkgbase/linux-aufs_friendly/

7 years, 3 months

[aur-requests] [PRQ#17034] Deletion Request for xf86-video-nv

by notify＠aur.archlinux.org

waschtl [1] filed a deletion request for xf86-video-nv [2]: * This package is superseded. The package extra/xf86-video-nouveau can presumably do everything this one does, just much more smoothly. * This package is no longer developed. The most recent version is 2.1.21 from 2017-01-17. In 2010, NVIDIA stated that this driver will not get support for new cards, and future X server versions will only be supported "within reason" [1] * This package causes confusion. A newcomer to proprietary NVIDIA drivers in Arch will see the various nvidia* packages, assuming they only contain a kernel module. Since they in fact also contain the xorg driver, there is no package named xf86-video-nvidia. Before realizing this, they are likely to attempt to use this package due to its similar name, assuming that the names haven't been homogenized. * This package is an orphan. * This package does not compile with the current version of xorg due to its dependency on X-ABI-VIDEODRV_VERSION=23. It also contains an explicit conflict with all other versions. Presumably this might be fixed in 2.1.21, but in almost 3 years, no one stepped in to update this package. [1] https://www.ubuntu-user.com/Online/News/NVIDIA-Drops-Xf86-video- nv-Support-No-Open-Source-for-New-Cards [1] https://aur.archlinux.org/account/waschtl/ [2] https://aur.archlinux.org/pkgbase/xf86-video-nv/

6 years

[PRQ#52935] Deletion Request for riseup-vpn

by notify＠aur.archlinux.org

Cyberfox69 [1] filed a deletion request for riseup-vpn [2]: => Starting check()... ? 0xacab.org/leap/bitmask-vpn/pkg/backend [no test files] ? 0xacab.org/leap/bitmask-vpn/pkg/bitmask [no test files] ? 0xacab.org/leap/bitmask-vpn/pkg/config [no test files] ? 0xacab.org/leap/bitmask-vpn/pkg/config/version [no test files] ? 0xacab.org/leap/bitmask-vpn/pkg/config/version/genver [no test files] ? 0xacab.org/leap/bitmask-vpn/pkg/helper [no test files] ? 0xacab.org/leap/bitmask-vpn/pkg/pickle [no test files] ? 0xacab.org/leap/bitmask-vpn/pkg/pickle/statik [no test files] ? 0xacab.org/leap/bitmask-vpn/pkg/snowflake [no test files] ? 0xacab.org/leap/bitmask-vpn/pkg/vpn [no test files] ok 0xacab.org/leap/bitmask-vpn/pkg/motd 0.002s ok 0xacab.org/leap/bitmask-vpn/pkg/pid (cached) ok 0xacab.org/leap/bitmask-vpn/pkg/snowflake/lib (cached) 2024/01/12 06:04:07 Client expects invalid auth 2024/01/12 06:04:09 Post "https://api.black.riseup.net/3/cert": tls: failed to verify certificate: x509: certificate signed by unknown authority FAIL 0xacab.org/leap/bitmask-vpn/pkg/vpn/bonafide 1.775s FAIL make: *** [Makefile:326: test] Error 1 ==> ERROR: A failure occurred in check(). Aborting... -> error making: riseup-vpn-exit status 4 -> Failed to install the following packages. Manual intervention is required: riseup-vpn - exit status 4 [1] https://aur.archlinux.org/account/Cyberfox69/ [2] https://aur.archlinux.org/pkgbase/riseup-vpn/

1 year, 11 months

Re: [PRQ#53426] Deletion Request for ttf-topaz-unicode

by Óscar García Amor

As I commented in the AUR comments[1] I was not aware of the existence of a ttf-topaz package since I did not search by topaz but by topaz-unicode which is actually the name of the font in the upstream[2] and since I saw that it did not exist I created the package. From my point of view the one that should be removed is the ttf-topaz[3] as it does not correspond to the real name of the upstream. In any case I have offered to be co-maintainer of this package to vcalv[4] which I think is the best thing to do. [1]: https://aur.archlinux.org/packages/ttf-topaz-unicode [2]: https://gitlab.com/Screwtapello/topaz-unicode [3]: https://aur.archlinux.org/packages/ttf-topaz [4]: https://aur.archlinux.org/account/vcalv/ El mar, 30 ene 2024 a las 14:55, <notify(a)aur.archlinux.org> escribió: > vcalv [1] filed a deletion request for ttf-topaz-unicode [2]: > > Duplicate of ttf-topaz that was already submitted. > > No new function in this package. > > [1] https://aur.archlinux.org/account/vcalv/ > [2] https://aur.archlinux.org/pkgbase/ttf-topaz-unicode/ -- Óscar García Amor | ogarcia at moire.org | http://ogarcia.me

1 year, 10 months

Re: [aur-requests] [PRQ#3328] Deletion Request for exfalso

by Bruno Pagani

Le 17/05/2015 23:45, Johannes Löthberg a écrit : > On 17/05, Johannes Löthberg wrote: >> On 17/05, notify(a)aur.archlinux.org wrote: >>> ArchangeGabriel [1] filed a deletion request for exfalso [2]: >>> >>> I need to reupload this package with a pkgbase (quodlibet) variable, >>> and AFAIK, this goes through removal of the existing package. >>> >> >> Could you upload a quodlibet package without the exfalso split >> package in it and then request a merge if you want the new package to >> keep the votes and comments? >> > > Actually, scratch that, you won't be able to upload a quodlibet > package because it exists in the repos and the repo package has > exfalso in it. Is there anything different at all in this package? > Indeed. It’s exfalso without quodlibet (I only use the former, and a lot of other people too), another way to do this would be splitting the repo package into four (or more, if splitting l10n): – /quodlibet/ – /exfalso/ – /quodlibet-libs/, on which one the previous two should depends – /quodlibet-l10n/ with /usr/share/locale files (and, as said above, eventually split that one for each locale) Should I open a bug against quodlibet packaging on Arch? Thanks, Bruno

10 years, 7 months

[PRQ#54086] Deletion Request for wxwidgets-light

by notify＠aur.archlinux.org

MarsSeed [1] filed a deletion request for wxwidgets-light [2]: Unmaintained since 2023-07-31, and currently several point releases older than repo's wxwidgets (3.2.2.1 vs 3.2.4). But this is also apparently unused, as no one flagged it. And it's not beneficial to keep. This package is not compatible with repo's wxwidgets-gtk3. and therefore most downstream dependent builds cannot use it, e.g. due to its divergent naming of the relevant wx- config executable. But no one complained - again, an evidence of disuse. This also cannot be coinstalled e.g. with repo's veracrypt (which I use). It also builds and puts the headless wxbase into wxwidgets-common- light - another divergence from repo's corresponding package, which does no such thing. Even if configured properly, this build would still break many reverse dependencies - those that need multimedia capabilities - as it omits gstreamer support. Therefore I don't see any benefit in keeping this. Maybe one person (submitter) would disagree, but no one else has shown any indication that they would needs this build. Enough to keep repo's wxwidgets (and AUR's wxwidgets-git). [1] https://aur.archlinux.org/account/MarsSeed/ [2] https://aur.archlinux.org/pkgbase/wxwidgets-light/

1 year, 9 months

Re: [PRQ#70024] Deletion Request for wacom-utility

by dreieck

Ahoj, On Tue, 18 Feb 2025 12:39:34 +0100, Marcell Meszaros <marcell.meszaros(a)runbox.eu> wrote: > On 17 February 2025 15:30:29 GMT+01:00, dreieck <oid-maps(a)seznam.cz> > wrote: > > On Mon, 17 Feb 2025 03:07:24 +0000, notify(a)aur.archlinux.org wrote: > > > > > MarsSeed [1] filed a deletion request for wacom-utility [2]: > > > > > > EOL stable version from 2011. > > > Current Wacom tablets are unsupported. > > > > But oder hardware is still functional. > > > > So I object this deletion request. > > > > Maybe an update in the `$pkgdesc` is suitable, so reflect that "only > > older Wacom tablets are supported". > > Hello, @dreieck, > > I see your point. > > In that case, however, wouldn't it be better to keep > AUR/wacom-utility-git [1] instead? > > The stable package is from 2011, whereas the git package builds from > a maintenance fork GitHub repo by @lubosz that is not archived, and > whose last commit is from 2019. > > It seems to me that the latter code has more hardware support > coverage than the EOL stable version from 2011. > > I have submitted a deletion request for wacom-git too, but I can > revoke that if you want to keep it. If `wacom-utility-git` is more up to date and also still functional, I am willing to take over that and drop `wacom-utility`. I have not tested `wacom-utility-git` yet. > [1]: https://aur.archlinux.org/pkgbase/wacom-utility-git

10 months

Re: [PRQ#68156] Deletion Request for wechat

by Marcell Meszaros

On 30 December 2024 04:35:52 GMT+01:00, notify(a)aur.archlinux.org wrote: >unn [1] filed a deletion request for wechat [2]: > >The maintainer of this AUR package treats its users as a testing >ground, with multiple inappropriate submissions in between. >Furthermore, they forcibly merged another simple and reliable AUR >package, wechat-bin. Due to distrust in this maintainer and >considering the large user base of the wechat package, I do not >believe this maintainer is capable of maintaining wechat. Therefore, I >request its deletion. > >[1] https://aur.archlinux.org/account/unn/ >[2] https://aur.archlinux.org/pkgbase/wechat/ The deletion request facility is not the comment section, and not a private grievance outlet. Please submit a constructive and well-reasoned feedback as a comment on the AURweb page of this package. This package is named well in accordance of all AUR guidelines, whereas 'wechat-bin' is not. Upstream is closed-source, so the package should be named 'wechat'. The maintainer of AUR/wechat is actually responsive to user feedback, and has taken many steps so far to address previous objections, e.g. about the former practice of forcing this to use bubblewrap sandbox. Now that is made optional, so users can choose whether to use it with or without bwrap. Please read the AUR submission guidelines [1] and the Nonfree applications package guidelines [2] to understand the expected packaging practices, to which AUR/wechat seems to conform to appropriately. [1]: https://wiki.archlinux.org/title/AUR_submission_guidelines [2]: https://wiki.archlinux.org/title/Nonfree_applications_package_guidelines

11 months, 2 weeks

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