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

Re: [aur-requests] [PRQ#35023] Deletion Request for kamule

by sL1pKn07 SpinFlo

Hi again. seems (i have remember now) not build in systems with Qt5 +5.12, but the binaries (if you build before break) still working in updated systems (as the screenshot) needs updated by the dev, so i'm waiting to TU decisions greetings El mié, 1 jun 2022 a las 21:23, sL1pKn07 SpinFlo (<sl1pkn07(a)gmail.com>) escribió: > > > El mié, 1 jun 2022 a las 20:35, <notify(a)aur.archlinux.org> escribió: > >> MarsSeed [1] filed a deletion request for kamule [2]: >> >> This might be considered for removal. >> >> Development stopped 6 years ago. >> Might not work with the current KDE5. >> Also might not be really needed because it is just a 6 year old GUI >> frontend >> for Amule, which has its own GUI based on WxWidgets. >> >> Also source is 404 because it is hosted on the problematic >> linux-apps.com (the closed "OpenDesktop.org" platform), >> which does not provide direct download links. >> >> [1] https://aur.archlinux.org/account/MarsSeed/ >> [2] https://aur.archlinux.org/pkgbase/kamule/ > > > Still working, also in KF5 [1] > > yes, seems need update the source URL > > [1] https://ibb.co/dJtBkHX > > greetings >

3 years, 6 months

Re: [PRQ#52086] Deletion Request for libsrsbsns

by heinrich5991＠gmail.com

On 12/10/23 14:27, notify(a)aur.archlinux.org wrote: > MarsSeed [1] filed a deletion request for libsrsbsns [2]: > > Unneeded, discontinued joke library from 2013. [a] > > Just read upstream repo's "About" section to see it's BS [b]: > " > Award winning unique innovative solution for cutting edge > revolutionary business application. Feature rich robust scalable > platform provides seamless and user-friendly out-of-box experience. > State of art next generation cloud ecosystem leverages best practices > for sustainable real-time performance. De-facto industry standard and > 42% more serious… > " > > Also see todo list created by co-developer [c]: > ( ) Create a todo list asap (As Srs As Possible) > (*) Check some boxes to indicate a thriving bsns activity > ( ) ????? > ( ) PROFIT > > [a]: https://github.com/srsbsns/libsrsbsns/tags > [b]: https://github.com/srsbsns/libsrsbsns > [c]: https://github.com/srsbsns/libsrsbsns/issues/3 > > [1] https://aur.archlinux.org/account/MarsSeed/ > [2] https://aur.archlinux.org/pkgbase/libsrsbsns/ While the description is indeed a joke, the library contains data structures etc. implemented in C. It's not a joke library AFAIK. Where do I respond to this ticket properly? Kind regards, heinrich5991

2 years

Re: [PRQ#47205] Deletion Request for dbus-test-runner-bzr

by Cody Schafer

I (the maintainer of this package in aur) agree. I've disowned it, and it should be deleted. On Mon, Sep 11, 2023 at 14:12 <notify(a)aur.archlinux.org> wrote: > MarsSeed [1] filed a deletion request for dbus-test-runner-bzr [2]: > > Proposal to delete this VCS pkg from 2018. > > Upstream not developed since 2019. [a] > > As per my checking, the latest main Bazaar branch has the exact same > application code as the one in the last release tarball for v19.04.0. > > There seems to be an actively maintained stable package for that > version on AUR. [b] > > There were dependency changes in the latter PKGBUILD's v19.04.0 > update. So this VCS pkg is now out of alignment with upstream, and is > likely to fail during build in a clean chroot. > > But instead of fixing and testing this, I think it is better to > delete, and leave only the functionally equivalent stable package. > > [a]: https://launchpad.net/dbus-test-runner > [b]: https://aur.archlinux.org/packages/dbus-test-runner > > [1] https://aur.archlinux.org/account/MarsSeed/ > [2] https://aur.archlinux.org/pkgbase/dbus-test-runner-bzr/

2 years, 3 months

[aur-requests] [PRQ#33929] Deletion Request for vdr-api

by notify＠aur.archlinux.org

MarsSeed [1] filed a deletion request for vdr-api [2]: This dummy package is not useful and not required. It was created to accommodate some AUR helpers that lack such a basic and necessary feature as handling the provides entries on AUR during dependency resolution. (I am using yay and paru, both handle them well.) This package was created for AUR/vdr. That package now has a versioned provides - currently this: provides = vdr-api=2.6.1 This package, vdr-api, was not kept up to date with the above, as it currently has pkgver=2.4.7 Yet, dependents requiring vdr-api=2.6.1 can be installed just fine by paru and yay, because AUR/vdr provides exactly that. No need for this (outdated) intermediary dummy package. Example dependent that I tried and which installs fine without even requiring AUR/vdr-api: https://aur.archlinux.org/packages/vdr-play Safe to delete, as its now incorrect version proves my point. No users have complained that they couldn't install dependents of AUR/vdr because of a version mismatch. Guess they use a proper AUR helper like paru or yay or something on par with them, and their tool of choice was able to resolve the dependency correctly without AUR/vdr-api as a dummy intermediary. [1] https://aur.archlinux.org/account/MarsSeed/ [2] https://aur.archlinux.org/pkgbase/vdr-api/

3 years, 8 months

Re: [aur-requests] [PRQ#11833] Deletion Request for linux-amd-staging-git

by Yurii Kolesnykov

Yes, it's mostly the same. Thank you for mentioning other branches. I hope to create different packages for this branches. Now I just manually switch the branch to most recent one, e.g. 4.19-wip -> 4.19 -> drm-next in second package. Now I think to create linux-amd-staging-wip, that points to $ver-wip and point this package to $ver. And point second package to drm-next. There is also drm-next from drm subsystem maintainer, which accumulates patches for all drivers in one repo. Because of that I think that maybe it will be better to create an interective AIO package to make it easy to maintain? ср, 11 лип. 2018, 06:07 користувач Eli Schwartz <eschwartz(a)archlinux.org> пише: > On 06/16/2018 10:29 PM, notify--- via aur-requests wrote: > > yurikoles [1] filed a deletion request for linux-amd-staging-git [2]: > > > > Not updating upstream. > > > > [1] https://aur.archlinux.org/account/yurikoles/ > > [2] https://aur.archlinux.org/pkgbase/linux-amd-staging-git/ > > Is this the same as > https://cgit.freedesktop.org/~agd5f/linux/log/?h=amd-staging-drm-next > > Because there's definitely other branches besides the one this PKGBUILD > currently uses, which do get updates. > > > -- > Eli Schwartz > Bug Wrangler and Trusted User > >

7 years, 5 months

Re: [aur-requests] [PRQ#4044] Deletion Request for ttf-hpfonts

by respiranto

I don't see how this could be illegal. The packager simply provides us, the users of the AUR, with a script, that simplifies installing the mentioned font. If it's illegal to use this font on non HP-computers, then it should be noted in the pkgdesc, however it's still the users responsability not to use this script, provided the case he is actually not legally permitted to do so. Anyways, I'm not sure why HP should forbid the use of their font on non HP-hardware, regarding the fact, that as far as I know, HP is not as widespread as would be necessary to benefit from this. Furthermore, I doubt HP has the right to deny the use of their software if they generally provide it for free. Similarly it's unclear whether whether setting up a 'Hackintosh' is actually illegal, especially in different countries with different jurisdictions. On 09/18/2015 05:04 PM, notify(a)aur.archlinux.org wrote: > jetm [1] filed a deletion request for ttf-hpfonts [2]: > > This package converts a .deb file, the copyright of .deb package says > the content only can be used inside of HP. > > I still not sure if legally is allowed to be here in AUR. Either of > cases, I request deletion of ttf-hpfonts from AUR. > > Thanks, > > jetm > > [1] https://aur.archlinux.org/account/jetm/ > [2] https://aur.archlinux.org/pkgbase/ttf-hpfonts/

10 years, 3 months

[aur-requests] [PRQ#32975] Deletion Request for wine-stable-ubuntu

by notify＠aur.archlinux.org

MarsSeed [1] filed a deletion request for wine-stable-ubuntu [2]: I suggest to delete this orphaned, outdated package. Seems no one is volunteering to take it up. It is wrong to have this package for several reasons: * Should be suffixed with -bin, not with -ubuntu, as it's a binary package. * Ubuntu build is a wrong fit for Arch when it comes to foreign builds. People should at least adapt fresh Fedora or OpenSUSE builds, as they are relying on more up-to-date dependencies. * Should someone venture to adopt this package, their recommended course of action would be to use an aforementioned Fedora or OpenSUSE build, but then that source would mismatch with the -ubuntu name suffix of this package. * In my experience, even Arch/multilib/wine-staging is quite stable for day-to-day use, but there is also the Arch/multilib/wine package which is very good. * If someone has issues with the latest Arch wine, their best workaround is a downgrade to the previous version. If all else fails, their second best bet is to build AUR/wine-stable or download the same from ChaoticAUR. All in all, it's not useful at all for users to have a "wine-stable- ubuntu" package in AUR. [1] https://aur.archlinux.org/account/MarsSeed/ [2] https://aur.archlinux.org/pkgbase/wine-stable-ubuntu/

3 years, 9 months

[PRQ#51723] Deletion Request for gsettings-desktop-schemas-ubuntu

by notify＠aur.archlinux.org

MarsSeed [1] filed a deletion request for gsettings-desktop-schemas- ubuntu [2]: This package is not useful at all for Arch Linux. It has been updated just now to Ubuntu's 44.0-1ubuntu1 (2023-03-31) release. Current latest stable Ubuntu version is: 45.0-1ubuntu1 (2023-09-19). Current Arch Linux extra repo version: 45.0-1 (built 2023-09-30, released 2023-10-09). This package just applies Ubuntu's patches from its debian/patches tarball dir. Both 44.0 & 45.0 Ubuntu versions have only one Ubuntu-specific patch in *debian.tar.xz [a]: - ubuntu_lock-on-suspend.patch (fixes an Ubuntu-only bug). Even if this PKGBUILD were promptly maintained, it would functionally just be a duplicate of extra/gsettings-desktop-schemas. But as of now, it mismatches the Arch repo version, and the current track record shows lack of adequate attention by AUR maintainers. [b] There is no package that would benefit from this variant at all on Arch Linux. And nothing on AUR specifically requires it. Therefore I propose to delete it, and it is safe to do so. [a]: https://launchpad.net/ubuntu/+source/gsettings-desktop- schemas/45.0-1ubuntu1 [b]: https://aur.archlinux.org/cgit/aur.git/log/?h=gsettings-desktop- schemas-ubuntu [1] https://aur.archlinux.org/account/MarsSeed/ [2] https://aur.archlinux.org/pkgbase/gsettings-desktop-schemas-ubuntu/

2 years

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

2 years, 2 months

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