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

Re: [PRQ#60466] Deletion Request for gnome-shell-extension-rounded-window-corners-reborn

by Grzegorz Kozub

But "just pack" actually also triggers the whole build. Zipping is just the final step. See "pack: build" in the justfile. So that's what happens in the git version of the aur package. The non-git version just pulls the extension authors zip that he built via GitHub actions. So I'm confused. You wanted to delete the non-git version of the aur package and seem to be confused about what happens in the git version. Maybe you flagged a wrong package? I still don't see a valid reason to delete any of them. Granted we fix the version you seem to have an issue with. On Thu, May 23, 2024, 22:19 Mark Wagie <mark.wagie(a)proton.me> wrote: > Greg: > > There is no "prebuild". Running 'just pack' only zips the files. > > Sent with Proton Mail <https://proton.me/> secure email. > > On Thursday, May 23rd, 2024 at 1:35 PM, Grzegorz Kozub < > grzegorz.kozub(a)gmail.com> wrote: > > Hi there! I maintain both AUR packages based on > https://github.com/flexagoon/rounded-window-corners. The git one builds > on your PC and the other uses the pre-build package provided by the > extension author. I prefer the pre-build one. Let's not remove it but > rather fix the issues you've come across. Can you help fixing the > pkgver=12.61c326e, please? I wanted it to reflect the git commit the > pre-build was made from. > > > https://aur.archlinux.org/packages/gnome-shell-extension-rounded-window-cor… > > https://aur.archlinux.org/packages/gnome-shell-extension-rounded-window-cor… > -- > greg > > > > On Thu, May 23, 2024 at 9:08 PM <notify(a)aur.archlinux.org> wrote: > >> yochananmarqos [1] filed a deletion request for gnome-shell-extension- >> rounded-window-corners-reborn [2]: >> >> There is no release and the Maintainer is inventing an erroneous >> pkgver. We already have a properly maintained VCS package: gnome- >> shell-extension-rounded-window-corners-reborn-git >> >> [1] https://aur.archlinux.org/account/yochananmarqos/ >> [2] >> https://aur.archlinux.org/pkgbase/gnome-shell-extension-rounded-window-corn… > > >

1 year, 2 months

Re: [aur-requests] [PRQ#28274] Deletion Request for petalinux-v2020.1

by Christopher Snowhill (kode54)

> On Sep 22, 2021, at 12:03 AM, Amin Vakil via aur-requests <aur-requests(a)lists.archlinux.org> wrote: > > On 9/21/21 20:58, Alex Henrie wrote: >>> On Tue, Sep 21, 2021 at 12:01 AM Amin Vakil <info(a)aminvakil.com> wrote: >>> >>> On 9/20/21 20:38, Alex Henrie wrote: >>>> On Sat, Sep 18, 2021 at 12:19 AM <notify(a)aur.archlinux.org> wrote: >>>>> >>>>> aminvakil [1] filed a deletion request for petalinux-v2020.1 [2]: >>>>> >>>>> https://aur.archlinux.org/packages/petalinux-v2021.1/ is already >>>>> present. >>>>> >>>>> [1] https://aur.archlinux.org/account/aminvakil/ >>>>> [2] https://aur.archlinux.org/pkgbase/petalinux-v2020.1/ >>>> >>>> I'm surprised that petalinux-v2020.1, petalinux-v2020.2, and >>>> petalinux-v2020.3 were deleted from the AUR. It would be nice to have >>>> the older versions in the AUR because the latest version (2021.1) is >>>> not 100% compatible. And the AUR has lots of old versions of other >>>> packages like gcc-arm-none-eabi-bin, so why not petalinux? >>>> >>>> $ yay -Ssq gcc-arm-none-eabi >>>> gcc-arm-none-eabi-bin-92 >>>> gcc-arm-none-eabi-bin-83 >>>> gcc-arm-none-eabi-bin-63 >>>> gcc-arm-none-eabi-bin-72 >>>> gcc-arm-none-eabi-bin-73 >>>> gcc-arm-none-eabi-bin-102 >>>> gcc-arm-none-eabi-bin-93 >>>> gcc-arm-none-eabi-bin-49 >>>> gcc-arm-none-eabi-bin-82 >>>> gcc-arm-none-eabi-bin >>> >>> Thanks for bringing this up, I've submitted deletion requests for all of >>> them as well. >> Are you going to delete all the old versions of GCC for x86 too >> (gcc34, gcc43, gcc44, gcc45, gcc46, gcc47, gcc48, gcc49, gcc5, gcc53, >> gcc6, gcc7, gcc8, gcc9)? And if so, why? gcc10 was even promoted out >> of the AUR. >> -Alex > > Arch Wiki is very clear about this: > https://wiki.archlinux.org/title/AUR_submission_guidelines#Rules_of_submiss… > > The submitted PKGBUILDs must not build applications already in any of the official binary repositories under any circumstances. Check the official package database for the package. If any version of it exists, do not submit the package. If the official package is out-of-date, flag it as such. If the official package is broken or is lacking a feature, then please file a bug report. > > "If any version of it exists, do not submit the package." > > But I think gcc is a specific case which I will not get involved in submitting a deletion request for it, but I have asked about it in #archlinux-aur channel on Libera to see what are others' opinions. > > - Amin Vakil I'd say the same also applies to any dependency for an aur package that doesn't work with the latest version. May I even go so far as to suggest there should be zero legacy version packages, even if the latest is only an aur package? Drop mongodb44 too, old computers serve no purpose, much like old software. Huge /s btw

3 years, 10 months

Re: [PRQ#42352] Deletion Request for prusa-slicer-bin

by JP Roemer

I see, thanks a lot for enlightening me on that front. I wasn't aware of that nomenclature and might have submitted this package too quickly at first. I've seen that the removal request went through and will be re-creating it according to the proper naming scheme. Have a nice day, Orax On Tue, 20 Jun 2023, at 23:44, Marcell Meszaros wrote: > @Orax, > > You can create a package for release candidate (rc) versions if you > would like to. Suggested names e.g.: > > prusa-slicer-rc-bin > -or- > prusa-slicer-preview-bin > > In package description, you can add "(preview version)" or "(release > candidate)". > > It could provide either the latest stable or the latest preview / > release candidate, whichever is newer. > > That package would not be considered a duplicate variant of the repo > package. It is valid and allowed on AUR to have > devel/alpha/beta/preview/rc whatever packages. > > On 20 June 2023 09:44:46 GMT+02:00, JP Roemer <jp(a)roemer.im> wrote: >>As the current maintainer of this aur package, I would like to note that prusa-slicer-bin do provide some value over https://archlinux.org/packages/extra/x86_64/prusa-slicer/ as it includes pre-release binaries (as specified in its description). >> >>Those pre-release / release candidate version do use the same configuration folder as final release one (which alpha & beta version do not) and are considered mostly safe to use with just some cutting edge new features available. >> >>The value of this package is to be able to install and tests pre-release versions which are not shipped as part of extra/prusa-slicer. >> >>If this is something that is not welcomed in the aur, I understand and this package can be removed. I just felt like the specific way configuration are handled by this package warranted the existence of a package that included stable and release-candidate versions. >> >>Best, >>Orax >> >>On Mon, 19 Jun 2023, at 12:20, notify(a)aur.archlinux.org wrote: >>> MarsSeed [1] filed a deletion request for prusa-slicer-bin [2]: >>> >>> Not needed anymore, same is in [extra]: >>> >>> https://archlinux.org/packages/extra/x86_64/prusa-slicer/ >>> >>> [1] https://aur.archlinux.org/account/MarsSeed/ >>> [2] https://aur.archlinux.org/pkgbase/prusa-slicer-bin/

2 years, 1 month

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/

5 months, 4 weeks

[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, 3 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#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, 4 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

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