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

Re: [aur-requests] [PRQ#5273] Merge Request for tensorflow-git

by Pieter ROBYNS

I believe there's an issue to consider here. Tensorflow is not a Python module. It is a C++ library that happens to provide Python bindings. Bindings for other scripting languages (e.g. Go) could be introduced in the future. There is a C API and C++ API as well, though these are - presently - not as easy to use [1]. I'm wondering whether it would make more sense to have two packages: "tensorflow" and "tensorflow-git", where both python2 and python3 bindings are installed by default. A similar approach is taken in the "gnuradio" package for example: it also provides a C++ library and the python2 bindings are implicitly installed. Perhaps a TU can help decide which approach should be taken. If they consider the python2-*, python-* approach to be cleaner, I will remove "tensorflow-git" from the AUR. [1]: https://www.tensorflow.org/versions/r0.8/get_started/basic_usage.html 2016-04-25 7:41 GMT+02:00 <notify(a)aur.archlinux.org>: > qazokm [1] filed a request to merge tensorflow-git [2] into > python2-tensorflow-git [3]: > > Ignore previous deletion request. Both packages are near identical > just newer one supports CUDA. Can they be merged to prevent confusing > over naming > > [1] https://aur.archlinux.org/account/qazokm/ > [2] https://aur.archlinux.org/pkgbase/tensorflow-git/ > [3] https://aur.archlinux.org/pkgbase/python2-tensorflow-git/

9 years, 5 months

Re: [PRQ#49216] Deletion Request for ghc-cabal-arts

by Byron Johnson

It has usefulness, and it's more than a duplicate. It includes a patch for fixing errors with the default static build options, to make it easier for people wanting a fresh cabal and ghc install that is capable of building packages instead of failing to build pretty much anything once installed, without configuration to fix them other than dropped command-line flags that were being ignored (this part at least has already been fixed). I shared it hoping it would benefit more than just me. There already is an issue (#8624) and work for it, and hopefully they can be finished in not too long, and then upstream will have the patches too. Byron On Thu, Oct 19, 2023 at 10:01 AM <notify(a)aur.archlinux.org> wrote: > MarsSeed [1] filed a deletion request for ghc-cabal-arts [2]: > > Duplicate of extra repo's cabal-install, ghc, ghc-libs, ghc-static - > bundled together. > > As per AUR submission guidelines, please kindly file a bug report if > there is an issue needed to be solved in repo packages, but don't > duplicate them on AUR. > > [1] https://aur.archlinux.org/account/MarsSeed/ > [2] https://aur.archlinux.org/pkgbase/ghc-cabal-arts/

1 year, 11 months

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, 1 month

[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

[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, 7 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/

5 years, 9 months

[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, 8 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, 7 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, 4 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, 7 months

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