Search results for "arm" - Aur-requests

[PRQ#68540] Deletion Request for minecraft-launcher-arm Accepted

by notify＠aur.archlinux.org

Request #68540 has been Accepted by Muflone [1]: [Autogenerated] Accepted deletion for minecraft-launcher-arm. [1] https://aur.archlinux.org/account/Muflone/

7 months

[PRQ#72364] Deletion Request for eclipse-arm Accepted

by notify＠aur.archlinux.org

Request #72364 has been Accepted by Muflone [1]: [Autogenerated] Accepted deletion for eclipse-arm. [1] https://aur.archlinux.org/account/Muflone/

3 months, 3 weeks

[PRQ#73938] Deletion Request for anydesk-arm-bin Accepted

by notify＠aur.archlinux.org

Request #73938 has been Accepted by Muflone [1]: [Autogenerated] Accepted deletion for anydesk-arm-bin. [1] https://aur.archlinux.org/account/Muflone/

1 month, 3 weeks

[PRQ#74564] Deletion Request for masterpdfeditor-arm Accepted

by notify＠aur.archlinux.org

Request #74564 has been Accepted by Muflone [1]: [Autogenerated] Accepted deletion for masterpdfeditor-arm. [1] https://aur.archlinux.org/account/Muflone/

3 weeks, 6 days

[PRQ#75168] Deletion Request for arm-mem-git Accepted

by notify＠aur.archlinux.org

Request #75168 has been Accepted by Muflone [1]: [Autogenerated] Accepted deletion for arm-mem-git. [1] https://aur.archlinux.org/account/Muflone/

2 days, 16 hours

Re: [PRQ#47890] Deletion Request for ruffle-arm Accepted

by Robin Candau

Le 24/09/2023 à 15:52, notify(a)aur.archlinux.org a écrit : > Request #47890 has been Accepted by Antiz [1]: > > The AUR is meant for Arch Linux only. While AUR packages can support > **additional** architectures than x86_64 (which is the only officially > supported architecture by Arch as of today) [2], they can be > restricted to them. Typo correction: [...], they **can't** be restricted to them. > Arch ARM/Alarm isn't Arch Linux, it is a community project that isn't > maintained by Arch Linux and that is **not** officially supported [3]. > > Additionally, in line with the Arch Linux CoC [4], I'm asking you to > respect the staff and their decisions. Please do not try to re-upload > this package once again as it is forbidden on the AUR and avoid > writing comments with such a disrespectful ton like the ones you wrote > earlier today [5][6]. > Consider this an official warning. > > [2] https://wiki.archlinux.org/title/PKGBUILD#arch > [3] > https://wiki.archlinux.org/title/Frequently_asked_questions#What_architectu… > [4] https://terms.archlinux.org/docs/code-of-conduct/#respect-the- > staff > [5] https://aur.archlinux.org/packages/ruffle-arm#comment-935371 > [6] https://aur.archlinux.org/packages/ruffle-arm#comment-935383 > > [1] https://aur.archlinux.org/account/Antiz/ -- Regards, Robin Candau / Antiz

1 year, 10 months

Re: [PRQ#51243] Deletion Request for mesa-panfork-git

by Hüseyin BIYIK

I am still failing to see how mingw exception is relevant to the case. I have to ask a very simple question: yay-git package, the most voted package in AUR, is building for both x86 & arm, and running on both of them (even on more architectures) https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=yay mesa-panfork-git is building for both x86 & arm, and *RUNNING* on both of them https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=mesa-panfork-git How one should justify yay-git should not be deleted from AUR but mesa-panfork-git should be deleted. What is the difference? Mingw? On 11/18/23 15:03, Marcell Meszaros wrote: >> Is there any rule saying that packages do build on x86 but meant to be >> used in non-x86 is supposed to be deleted? > Only builds that create packages for Microsoft Windows are explicitly accepted (MinGW package guidelines [1]), and also compile toolchains that run on Arch Linux x86_64 but create binaries for other architectures (Cross-compiling tools package guidelines [2]). > > Other than that, there is no other allowance in Arch Wiki. Articles there about ARM and Arch Linux ARM, for example [3] firmly get redirected to Arch Linux Terms / Code of Conduct / "Arch Linux distribution support ONLY". [4] > > [1]: https://wiki.archlinux.org/title/MinGW_package_guidelines > [2]: https://wiki.archlinux.org/title/Cross-compiling_tools_package_guidelines > [3]: https://wiki.archlinux.org/index.php?title=Special%3ASearch&fulltext=1&sear… > [4]: https://terms.archlinux.org/docs/code-of-conduct/#arch-linux-distribution-s… > > On 18 November 2023 14:32:42 GMT+01:00, "Hüseyin BIYIK" <boogiepop(a)gmx.com> wrote: >> On 11/15/23 00:29, notify(a)aur.archlinux.org wrote: >>> FabioLolix [1] filed a deletion request for mesa-panfork-git [2]: >>> >>> While this have x86_64 in arch=() is in fact ARM specific. From >> Is there any rule saying that packages do build on x86 but meant to be >> used in non-x86 is supposed to be deleted? >> >>> pkgdesc "Mesa with Panfrost that supports Mali G610/G710 GPUs (Valhall >>> v10 CSF)", from internal comment "Removed Gallium3D drivers/packages >>> for chipsets that don't exist in our ARM devices (intel, VMware >>> svga)", untouched since 11 months >> This means that package is working, not necessarily it is broken. Why >> the deletion request? >>

1 year, 8 months

[aur-requests] [PRQ#35955] Deletion Request for arm-none-eabi-gcc60-linaro

by notify＠aur.archlinux.org

MarsSeed [1] filed a deletion request for arm-none-eabi-gcc60-linaro [2]: This legacy compiler from 2018 seems not needed anymore. Also its name seems not right; gcc60 implies gcc 6.0 from 2016, but its current version is 6.5 from 2018. Though as nothing depends on it on AUR, I recommend deletion, in order to ease maintenance burden. There are no user votes or comments that would indicate that anyone would protest. (Also, the main isl package has been adopted from AUR to Arch [core] under the name 'libisl'. As AUR in principle has to align with Arch repos, any isl* packages here should in theory be renamed to libisl*, and their dependents would need to change their depends arrays as well. But it is better to remove the truly unused legacy packages instead of pushing for effecting the former cross-maintainer changes for dozens of AUR packages.) [1] https://aur.archlinux.org/account/MarsSeed/ [2] https://aur.archlinux.org/pkgbase/arm-none-eabi-gcc60-linaro/

3 years, 1 month

Re: [aur-requests] [PRQ#26623] Deletion Request for python2-rpi.gpio

by Alex Stelmachonak

What is wrong if this package is ARM (and RPi) specific? AUR is available on ArchLinuxARM and used by many people (including me). I don't think "Specific for ARM hardware" is a valid reason to delete package. -- Alex Stelmachonak mail(a)ava1ar.me On Thu, Jun 24, 2021, at 13:57, notify(a)aur.archlinux.org wrote: > FabioLolix [1] filed a deletion request for python2-rpi.gpio [2]: > > Specific for ARM hardware > > [1] https://aur.archlinux.org/account/FabioLolix/ > [2] https://aur.archlinux.org/pkgbase/python2-rpi.gpio/

4 years, 1 month

Re: [PRQ#51243] Deletion Request for mesa-panfork-git

by Marcell Meszaros

>Is there any rule saying that packages do build on x86 but meant to be >used in non-x86 is supposed to be deleted? Only builds that create packages for Microsoft Windows are explicitly accepted (MinGW package guidelines [1]), and also compile toolchains that run on Arch Linux x86_64 but create binaries for other architectures (Cross-compiling tools package guidelines [2]). Other than that, there is no other allowance in Arch Wiki. Articles there about ARM and Arch Linux ARM, for example [3] firmly get redirected to Arch Linux Terms / Code of Conduct / "Arch Linux distribution support ONLY". [4] [1]: https://wiki.archlinux.org/title/MinGW_package_guidelines [2]: https://wiki.archlinux.org/title/Cross-compiling_tools_package_guidelines [3]: https://wiki.archlinux.org/index.php?title=Special%3ASearch&fulltext=1&sear… [4]: https://terms.archlinux.org/docs/code-of-conduct/#arch-linux-distribution-s… On 18 November 2023 14:32:42 GMT+01:00, "Hüseyin BIYIK" <boogiepop(a)gmx.com> wrote: >On 11/15/23 00:29, notify(a)aur.archlinux.org wrote: >> FabioLolix [1] filed a deletion request for mesa-panfork-git [2]: >> >> While this have x86_64 in arch=() is in fact ARM specific. From > >Is there any rule saying that packages do build on x86 but meant to be >used in non-x86 is supposed to be deleted? > >> pkgdesc "Mesa with Panfrost that supports Mali G610/G710 GPUs (Valhall >> v10 CSF)", from internal comment "Removed Gallium3D drivers/packages >> for chipsets that don't exist in our ARM devices (intel, VMware >> svga)", untouched since 11 months > >This means that package is working, not necessarily it is broken. Why >the deletion request? >

1 year, 8 months

Aur-requests search results for query "arm"