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

Re: [PRQ#70009] Deletion Request for rpcs3

by Vitalii Kuzhdin

Greetings, Thank you for bringing the rolling version scheme to my attention, I wasn't aware of this. I understand the concerns about outdated builds being misleading. However, I believe there may still be value in maintaining this package with some modifications. As you already know, VCS and regular packages have differences beyond the pkgver() function. For example, the AUR guidelines for VCS packages suggest version bumps only when the build process changes, as pkgver() handles version updates otherwise. However, if the version is not changed on the AUR, users may miss notifications about new commits and important updates. AUR helpers (at least mainstream ones I am aware of) don't automatically watch the repo for changes. Without manual rebuild requests, users won't receive automatic updates, potentially leading to RPCN-related issues you've mentioned. Additionally, VCS packages lack reproducibility. Given RPCS3's extensive dependency chain, this could make bug tracking significantly more challenging. Many rolling release software packages exist in the official Arch repos (e.g., LuaJIT). Since official repos don't allow VCS packages, the solution is regular version bumps. As a compromise, I propose committing to, say, weekly version updates for the RPCS3 package. I'm open to further discussion, but if it is still not useful to keep this, I understand you obviously do not want to get bug reports coming from an outdated package. Thank you for the seriously impressive work behind the emulator. Best regards, Vitalii On Sun, Feb 16, 2025 at 8:27 PM <notify(a)aur.archlinux.org> wrote: > AniLeo [1] filed a deletion request for rpcs3 [2]: > > Please read our release notes at > https://github.com/RPCS3/rpcs3/releases/ and remove this AUR. > > This AUR is misleading, offering outdated builds as if they were some > kind of RPCS3 stable builds, such a thing does not exist. It is > offering a random outdated build that had no special quality control > whatsoever compared to every other build. > > I leave a copy of the relevant line from our release notes below, just > in case: > > "Note: These are NOT stable builds. RPCS3 is a rolling release > software without stable builds. These are random tags we do from time > to time. Do NOT use the branch from these tags to package RPCS3." > > --- > > Verification that I am a member of the RPCS3 team and am formally > requesting for this AUR to be removed: > https://forums.rpcs3.net/showthread.php?tid=208697&pid=328170#pid328170 > > [1] https://aur.archlinux.org/account/AniLeo/ > [2] https://aur.archlinux.org/pkgbase/rpcs3/

6 months, 1 week

[aur-requests] On the topic of [PRQ#20203]

by FennecTECH (FennecTECH)

I was updating another package and got mixed up with repositories. Ive (finally) straightened them out. Please do not delete this package. From a brief discussion on the archlinux forum katt [1] filed a deletion request for radegast-git [2]: Absolute mess of a package, maintainer decided to rename their -git package to -ng while switching to releases, all while avoiding .SRCINFO to presumable avoid git stopping their madness dead in its tracks. This is backed up by them actually submitting a separate .SRCINFO with just an upped pkgrel. Call the exorcist! [1] https://aur.archlinux.org/account/katt/ [2] https://aur.archlinux.org/pkgbase/radegast-git/ This is a reply to this message. My package is the git from the classic fork that was superseded by Radegast-ng. (Which is releases from the updated version) Some time ago the founder of Radegast passed and the original repository was left. Radegast-NG is a fork of the codebase this package installs. I would like to keep this package around a while longer as some still do use the original version. Today’s mistake was the result of me pushing to the wrong repository. Please do not delete my package. I’m still learning git. https://bbs.archlinux.org/viewtopic.php?pid=1915036#p1915036 Sent from my iPad

5 years, 1 month

Re: [aur-requests] [PRQ#5971] Deletion Request for packettracer

by care by john

Basically, none of the packet tracer URL's are working on AUR. First correct these. You do not have the right to question my ability about anything because you don't know me and what I am doing. If you know a bit more about anything than me or others, keep it with you and good for your career. Good luck and God bless you. On Thu, Jul 14, 2016 at 10:52 PM, care by john <carebyjohn(a)gmail.com> wrote: > ==> Retrieving sources... > -> Downloading Cisco Packet Tracer 6.1.1 for Linux - Ubuntu installation > (no tutorials) - Student version.tar.gz... > % Total % Received % Xferd Average Speed Time Time Time > Current > Dload Upload Total Spent Left > Speed > 0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- > 0Warning: Transient problem: timeout Will retry in 3 seconds. 3 retries > left. > 0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- > 0Warning: Transient problem: timeout Will retry in 3 seconds. 2 retries > left. > 0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- > 0Warning: Transient problem: timeout Will retry in 3 seconds. 1 retries > left. > 0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- > 0curl: (6) Could not resolve host: Cisco Packet Tracer 6.1.1 for Linux - > Ubuntu installation (no tutorials) - Student version.tar.gz > ==> ERROR: Failure while downloading http://Cisco Packet Tracer 6.1.1 for > Linux - Ubuntu installation (no tutorials) - Student version.tar.gz > Aborting... > > > On Thu, Jul 14, 2016 at 10:50 PM, care by john <carebyjohn(a)gmail.com> > wrote: > >> ah there you are. >> >> Are these ones downloadable? >> >> https://aur.archlinux.org/packages/packettracer >> https://aur.archlinux.org/packages/packettracer61 >> https://aur.archlinux.org/packages/packettracer62 >> >> All three shows invalid links. >> >> On Thu, Jul 14, 2016 at 10:41 PM, Doug Newgard <scimmia(a)archlinux.info> >> wrote: >> >>> On Thu, 14 Jul 2016 17:04:01 +0000 (UTC) >>> notify(a)aur.archlinux.org wrote: >>> >>> > redhat_boy [1] filed a deletion request for packettracer [2]: >>> > >>> > Remove this page itself, please. New Arch Linux users reaching out to >>> > this page by Google search engine and getting confused. >>> > >>> > [1] https://aur.archlinux.org/account/redhat_boy/ >>> > [2] https://aur.archlinux.org/pkgbase/packettracer/ >>> >>> Your inability to understand a package is not a reason to delete it from >>> the >>> AUR. >>> >> >> >

9 years, 1 month

Re: [PRQ#59291] Merge Request for plasma5-applets-mpdnowplaying

by Marcell Meszaros

>> >marcel83 [1] filed a request to merge plasma5-applets-mpdnowplaying >> >[2] into plasma-applet-mpdnowplaying [3]: >> > >> >Ported to Plasma 6, hence the old package name is misleading. >> > >> >[1] https://aur.archlinux.org/account/marcel83/ >> >[2] https://aur.archlinux.org/pkgbase/plasma5-applets-mpdnowplaying/ >> >[3] https://aur.archlinux.org/pkgbase/plasma-applet-mpdnowplaying/ >> This should not be merged, as the target package name does not adhere to >> ArchWiki's KDE package guidelines. >> >> The new name should refer to plasma6, not plasma, and have 'applets' in >> plural, i.e.: >> plasma6-applets-mpdnowplaying. >> > On 20 April 2024 11:09:46 GMT+02:00, Marcel Hasler <mahasler(a)gmail.com> wrote: >Thanks, I renamed the package and submitted a new merge request and a >deletion request for this one. > >Just as a side note: I had looked what other applets are available from the >official repositories and only found one >(extra/plasma-applet-window-buttons) so I followed that naming scheme for >consistency. Shouldn't that package also be renamed? > You are right. Arch Developer Antonio Rojas chose the name of extra/plasma-applet-window-buttons in a way that it does not conform to current ArchWiki KDE package guidelines. I do not currently have an account at ArchLinux GitLab so I cannot file an issue to request its renaming. But thanks anyway for changing the name of your package. ArchWiki is the canonical source of guidelines, and your new package name aligns correctly with those. Oh, and please kindly close (cancel) this earlier merge request (PRQ#59291) to avoid confusing AUR PM's. You can use the following form to close it: https://aur.archlinux.org/requests/59291/close Thank you! Cheers, Marcell / MarsSeed

1 year, 4 months

Re: [PRQ#42162] Deletion Request for libopenblas

by Marcell Meszaros

There is no 32-bit build of openblas in AUR, and there is no 32-bit consumer of openblas in AUR. Your complaints are nonsensical at worst and nonexistent, theoretical at best. No harm will be done in deleting AUR/libopenblas which is a duplicate of [extra] openblas. AUR submission guidelines says under no circumstances should an AUR package build the same package that repo also builds and carries. On 15 June 2023 00:43:49 GMT+02:00, sL1pKn07 SpinFlo <sl1pkn07(a)gmail.com> wrote: >yes if a new user tries to install itself in local. If try to install it >with openblas in repo, it fails because file conflicts. and if forced to >install, when trying to build a 64 bits program with 64bits openblas, gets >link failed because cmake found the 32bit libs because new cmake files >point to it (see the bug report). > >so no, i think need solve the bug report first , then can you delete it >without mercy > >greetings > >El jue, 15 jun 2023 a las 0:37, Marcell Meszaros (< >marcell.meszaros(a)runbox.eu>) escribió: > >> The linked bug report should be addressed, but that does not necessitate >> keeping AUR/libopenblas. >> >> As there is no lib32-(lib)openblas package and nothing in AUR seem to need >> a multilib version of openblas. >> >> Also, AUR submission guidelines also mandate no copying of repo packages >> to address packaging bugs/requests, but to have them resolved via bug >> report. >> >> As for x86_64 builds on AUR requiring openblas, they should find the CMake >> files of repo openblas package just fine. >> >> >> On 15 June 2023 00:05:59 GMT+02:00, sL1pKn07 SpinFlo <sl1pkn07(a)gmail.com> >> wrote: >> >>> >>> >>> El jue, 15 jun 2023 a las 0:02, <notify(a)aur.archlinux.org> escribió: >>> >>>> MarsSeed [1] filed a deletion request for libopenblas [2]: >>>> >>>> This has not been needed for quite some time, as Arch repo carries >>>> openblas, including its libs, and it can be installed side-by-side >>>> with blas. >>>> >>>> [1] https://aur.archlinux.org/account/MarsSeed/ >>>> [2] https://aur.archlinux.org/pkgbase/libopenblas/ >>> >>> >>> https://bugs.archlinux.org/task/78725 >>> >>> greetings (sorry if dupped, but not CC all) >>> >>

2 years, 2 months

Re: [PRQ#45251] Deletion Request for lib32-sane

by sL1pKn07 SpinFlo

El vie, 6 oct 2023 9:13, Marcell Meszaros <marcell.meszaros(a)runbox.eu> escribió: > This library was adopted and updated, but it still does not have other > packages that would utilize it. > > It is still better to delete this, which in turn will allow other unneded > and not very actively maintained packages, like lib32-avahi, and several of > its lib32 dependencies, to be dropped as well. > > Savvy users like @sl1pkn07 can install AUR/wine-wow64 if they really want > to use their likely 20+ year old bin32 Windows-only scanners through wine. > (Scanner support was the one reason cited by @sl1pkn07 to having a need for > this package, though he failed to mention any concrete model or > driver/software package that would actually benefit from having this pkg > installed.) > > (Around 2004-2006, Microsoft was pushing OEM's to release 64-bit software > for their still in-use hardware devices, even those that were sold > previously. Consequently, many printers and scanners marketed after > 1999-2000 got those support software at least for the bare minimum > functionality in 64-bit.) > > (Also, no wine builds on AUR utilize lib32-sane, so even if someone > installed the latter, it would be pointless without recompiling said wine > package. But as I mentioned above, wine-wow64 works with both 32-bit and > 64-bit Windows software without relying on any 32-bit Linux libraries.) > > Also, AUR submission guidelines say that packages kept there should be > useful to more than a few user. It seems only @sl1pkn07 wants to hang on to > this package. > > On 22 July 2023 17:45:54 GMT+02:00, notify(a)aur.archlinux.org wrote: > >MarsSeed [1] filed a deletion request for lib32-sane [2]: > > > >Orphan package, last updated in 2021-11, no dependents. > > > >I flagged it OOD 2.5 years ago. > > > >There are no comments since 2021. > > > >I think it is better to delete. > > > >Only wine-stable-ununtu package depended on this from 2021; it has > >been deleted since. > > > >The new wine-wow64 package supports running 32-bit code with only > >64-bit Linux libraries. > > > >[1] https://aur.archlinux.org/account/MarsSeed/ > >[2] https://aur.archlinux.org/pkgbase/lib32-sane/ hi since the last request i maintain the package in my own. if is already upload again, is by mistake (first notice the new push). can delete again sorry :( > >

1 year, 10 months

Re: [PRQ#54086] Deletion Request for wxwidgets-light

by sL1pKn07 SpinFlo

El sáb, 23 mar 2024 a las 15:24, sL1pKn07 SpinFlo (<sl1pkn07(a)gmail.com>) escribió: > > > El sáb, 23 mar 2024 a las 15:08, Marcell Meszaros (< > marcell.meszaros(a)runbox.eu>) escribió: > >> On 22 February 2024 20:58:03 GMT+01:00, notify(a)aur.archlinux.org wrote: >> >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/ >> >> >> Even after the update right after my deletion request was submitted >> (3.2.2.1-5 →3.2.4-2), the gtk3 package is still not compatible with repo's >> counterpart. >> >> And it still cannot be installed together with e.g. repo's veracrypt. >> >> Useless to keep this partially broken partial duplicate. >> > > Zero logs, user not proves what failed. > > of course not install with veracrypt because this package not provide any > support to gstreamer, and is not the intention. if you want use veracrypt, > use [extra] wxwidgets-foo > > greetings > if you mean "advertencia: no se pudo resolver «wxwidgets-gtk3>=3.2», una dependencia de «veracrypt»", fixed and again, this ML is not for support,a and again, use the package comments for this type of things greetings

1 year, 5 months

[aur-requests] [PRQ#33152] Deletion Request for cainteoir-engine

by notify＠aur.archlinux.org

Bid [1] filed a deletion request for cainteoir-engine [2]: Hi I am getting compile error, could you please help -------------------------------------- ucd-tools/src/categories.cpp:3366:1: warning: control reaches end of non-void function [-Wreturn-type] 3366 | } | ^ In file included from src/include/cainteoir/document.hpp:24, from src/libcainteoir/document.cpp:24: src/include/cainteoir/metadata.hpp:358:44: error: 'function' in namespace 'std' does not name a template type 358 | const std::function<void (const rdf::uri &aUri)> &onuri); | ^~~~~~~~ src/include/cainteoir/metadata.hpp:27:1: note: 'std::function' is defined in header '<functional>'; did you forget to '#include <functional>'? 26 | #include <set> +++ |+#include <functional> 27 | src/include/cainteoir/metadata.hpp:358:52: error: expected ',' or '...' before '<' token 358 | const std::function<void (const rdf::uri &aUri)> &onuri); | ^ src/include/cainteoir/metadata.hpp:383:48: error: 'function' in namespace 'std' does not name a template type 383 | const std::function<void (const std::shared_ptr<const triple> &aStatement)> &onlistitem); | ^~~~~~~~ src/include/cainteoir/metadata.hpp:383:43: note: 'std::function' is defined in header '<functional>'; did you forget to '#include <functional>'? 383 | const std::function<void (const std::shared_ptr<const triple> &aStatement)> &onlistitem); | ^~~ src/include/cainteoir/metadata.hpp:383:56: error: expected ',' or '...' before '<' token 383 | const std::function<void (const std::shared_ptr<const triple> &aStatement)> &onlistitem); | ^ src/libcainteoir/document.cpp: In function 'std::vector<cainteoir::ref_entry> cainteoir::navigation(const cainteoir::rdf::graph&, const cainteoir::rdf::uri&, const cainteoir::rdf::uri&)': src/libcainteoir/document.cpp:117:28: error: cannot convert 'cainteoir::navigation(const cainteoir::rdf::graph&, const cainteoir::rdf::uri&, const cainteoir::rdf::uri&)::<lambda(const std::shared_ptr<const cainteoir::rdf::triple>&)>' to 'int' 117 | rql::rdf_list_items(aMetadata, *toc_entries, rdf::ref("entries"), | ~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ | | | cainteoir::navigation(const cainteoir::rdf::graph&, const cainteoir::rdf::uri&, const cainteoir::rdf::uri&)::<lambda(const std::shared_ptr<const cainteoir::rdf::triple>&)> 118 | [&aMetadata, &nav](const std::shared_ptr<const rdf::triple> &item) | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 119 | { | ~ 120 | nav.push_back({ rql::select(aMetadata, rql::subject == rql::object(item)) }); | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 121 | }); | ~~ In file included from src/include/cainteoir/document.hpp:24, from src/libcainteoir/document.cpp:24: src/include/cainteoir/metadata.hpp:383:37: note: initializing argument 4 of 'void cainteoir::rdf::query::rdf_list_items(const cainteoir::rdf::graph&, const cainteoir::rdf::uri&, const cainteoir::rdf::uri&, int)' 383 | const std::function<void (const std::shared_ptr<const triple> &aStatement)> &onlistitem); | ^~~~~~~~~~~~~~~~~~~ make[2]: *** [Makefile:1894: src/libcainteoir/libcainteoir_la- document.lo] Error 1 make[1]: *** [Makefile:2525: all-recursive] Error 1 make: *** [Makefile:1058: all] Error 2 ==> ERROR: A failure occurred in build(). [1] https://aur.archlinux.org/account/Bid/ [2] https://aur.archlinux.org/pkgbase/cainteoir-engine/

3 years, 5 months

Re: [aur-requests] [PRQ#8874] Deletion Request for firefox-dev

by Denys Vitali

If the package needs to be deleted, go on. Do it. If we have to fill up a mailing list just for this, it would be better to just delete the package. The package was reuploaded automatically, because I dindn't turn off the auto-maintainer once the first package deletion happened. I then stopped once the package was deleted for the second time. I proceeded to add the package again when I noticed that jnbek <https://aur.archlinux.org/account/jnbek> was one version behind, despite the numerous complains about the package not being updated. Look, if you guys don't want an automatically updated package, it's okay. I'm not getting paid from nobody to keep it up and running. My only goal was to provide a reliable AUR package for the Firefox Developer Edition - I never intended to break any rule, nor to turn the whole AUR community against me. It is up to you, the sources for the auto-maintainer are here <https://github.com/denysvitali/aur-firefox-dev-automaintainer>, the package itself is reliable. Sure, in the an "hands on check to ensure everything went well" before publishing it is not performed (because yeah, it is automaintained), but in 36 releases I never really needed to do anything, and there was no problem at all. I guess the choice now is the following: 1) Keep firefox-dev and merge it into firefox-developer 2) Delete firefox-dev, keep firefox-developer and hope the new maintainer provides a release as soon as it comes out 3) Delete firefox-developer and change the way the releases are rolled out 4) Keep everything as is, and let the user choose if they want rolling out releases, or a more "stable" approach 5) ??? Please note that `firefox-dev-ru` follows my same principle, and also note that by searching for firefox-dev* <https://aur.archlinux.org/packages/?O=0&K=firefox-dev> half of the results are packages that aren't updated. Keep also in mind that now the firefox-developer package has got a new maintainer, but has been updated to the newest 57.0a1.20170830-1 version, which isn't officially rolled out yet. I hope this message explains my reasons behind the choices of the firefox-dev package - I was (and still am) just trying to improve the Firefox Developer AUR experience. On 30. 08. 17 19:31, John D Jones III wrote: > On 8/28/17 13:54, notify(a)aur.archlinux.org wrote: >> jnbek [1] filed a deletion request for firefox-dev [2]: >> >> This package has been a hostile attempt at taking control of the >> formerly my firefox-developer PKGBUILD, which is built by strict >> standards for Mozilla software. This PKGBUILD autoupdates willy nilly >> without any hands on checks to ensure everything went well. >> >> [1] https://aur.archlinux.org/account/jnbek/ >> [2] https://aur.archlinux.org/pkgbase/firefox-dev/ >> > It's also worth noting that the firefox-dev PKGBUILD was already > deleted from the AUR and denvit readded it anyways. >

7 years, 11 months

Re: [aur-requests] [PRQ#15312] Orphan Request for qbittorrent-dark-git

by Yurii Kolesnykov

Ok, I see. But I don't know how to withdraw my request. пт, 28 черв. 2019 о 15:55 Vladislav Suratov <suratovvlad(a)gmail.com> пише: > > Sure, Plasma forces Qt applications to look in the same way, but Gnome doesn't have such ability by default, and qBittorent looks very bright. > Maintainers of this project refused this request (as well as change) from me https://github.com/qbittorrent/qBittorrent/pull/5076 > and I support it for AUR and Windows with my fork, which is this current package. > So, I am not happy for deletion request and I ask you to cancel this request. > > P.S. They are going to add probably add this https://github.com/qbittorrent/qBittorrent/pull/10702 but I don't think I will stop to support my fork. > > On Fri, Jun 28, 2019 at 3:44 PM Yurii Kolesnykov <root(a)yurikoles.com> wrote: >> >> qBittorrent 4.1.6 honors KDE Plasma Dark Mode, I haven't checked in GNOME. >> >> пт, 28 черв. 2019 о 14:47 Vladislav Suratov <suratovvlad(a)gmail.com> пише: >> > >> > Hi Yurii, >> > >> > What do you mean about dark mode in stable? >> > Have they added it to the 4.1.6? or released 4.2.0 already? >> > >> > On Fri, Jun 28, 2019 at 2:33 PM <notify(a)aur.archlinux.org> wrote: >> >> >> >> yurikoles [1] filed a orphan request for qbittorrent-dark-git [2]: >> >> >> >> Dark mode already in stable and obviously git. >> >> >> >> [1] https://aur.archlinux.org/account/yurikoles/ >> >> [2] https://aur.archlinux.org/pkgbase/qbittorrent-dark-git/

6 years, 1 month

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