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

[PRQ#61247] Deletion Request for emoji-keyboard-appimage

by notify＠aur.archlinux.org

xiota [1] filed a deletion request for emoji-keyboard-appimage [2]: PM stated, "I'd like to remove it but this is not prohibited". On the contrary, this package is in violation of AUR submission guidelines: * "Do not create duplicate packages." The -appimage and -bin packages are duplicates of each other. * Exceptions for duplicates are "extra features" or "patches". The packages do not differ in these respects. * Packages are also required to be "useful". "Will anyone else want to use this package?" There is no reason to prefer the appimage package over the bin package, or vice versa. * "Packages that use prebuilt deliverables, when the sources are available, must use the -bin suffix." The appimage package lacks the -bin suffix. Sometimes users create duplicate packages when another package is broken with a maintainer who refuses or is unable to fix it. In such cases, the duplicate may be allowed because working packages have "extra features" with respect to non-working packages. Fixing the package may also be considered, or require, using "patches". This scenario does not apply to emoji-keyboard-appimage and -bin because they have the same maintainer. The packages are equally working or equally broken, and the maintainer is equally able or unable to fix them. [1] https://aur.archlinux.org/account/xiota/ [2] https://aur.archlinux.org/pkgbase/emoji-keyboard-appimage/

1 year, 5 months

[PRQ#62873] Deletion Request for zim-dev

by notify＠aur.archlinux.org

MarsSeed [1] filed a deletion request for zim-dev [2]: VCS package in disguise, duplicate of AUR/zim-git [a], which is also an orphan. (Upstream's default branch is 'develop', so the default clone/checkout will switch to that branch even without explicitly specifying that in the source URL fragment.) @wooptoo, thank you for your valuable contribution to AUR. As a fellow regular member, I would like to ask your cooperation in making it a habit to check if there are existing package(s) for the codebase that you would submit a PKGBUILD for plus the type of the source (fixed-release or 'rolling' with every new revision/commit of a version control system - VCS). As AUR/zim-git is an orphan, it would be welcome if you chose to adopt it and become its maintainer. Also please keep in mind the AUR submission guidelines when it comes to package naming. A VCS package has to have a relevant pkgname suffix - in this case, '*-git'. Your zim-dev PKGBUILD seems very good, and your explicit declaration of the git branch to use is commendable and in accordance with best practice. Can you maybe adapt that PKGBUILD for the 'zim-git' pkgname and submit that to the latter AUR repo? Thank you in advance, for your understanding and cooperation! [a]: https://aur.archlinux.org/packages/zim-git [1] https://aur.archlinux.org/account/MarsSeed/ [2] https://aur.archlinux.org/pkgbase/zim-dev/

1 year, 3 months

Re: [aur-requests] [PRQ#2585] Merge Request for upower-pm-utils

by Evgeniy Alekseev

On Sunday 08 March 2015 10:48:42 notify(a)aur.archlinux.org wrote: > Alad [1] filed a request to merge upower-pm-utils [2] into > upower-nosystemd [3]: > > Identical to upower-nosystemd, except this has an overly specific > dependency (eudev instead of udev) for the sole reason of packaging > for another distro > > [1] https://aur.archlinux.org/account/Alad/ > [2] https://aur.archlinux.org/pkgbase/upower-pm-utils/ > [3] https://aur.archlinux.org/pkgbase/upower-nosystemd/ Currently one package [1] depends on it. I've left a comment. About this package deletion. I think that we are free to remove packages which are uploaded to provide Manjaro compatibility according to the idea that AUR is _Arch_ repository, not Arch-based one. And to provide compatibility Manjaro users should use own repository. 1. https://aur.archlinux.org/packages/mate-session-manager-upower/ -- Sincerely yours, Evgeniy Alekseev e-mail: darkarcanis(a)mail.ru ICQ: 407-398-235 Jabber: arcanis(a)jabber.ru

10 years, 9 months

[PRQ#40901] Deletion Request for onedev-bin

by notify＠aur.archlinux.org

PolarianDev [1] filed a deletion request for onedev-bin [2]: I have to make this clear, I am not submitting this request out of personal bias, I think onedev is a decent solution. On 07/04/2023, I attempted to update onedev, the update failed and human error probably caused me to accidentally destroy data, this is because data and code is stored within the same directory, which makes this highly likely you will overwrite the wrong data, and end up destroying data. This was brought up with upstream, and they clearly stated they are not interested in the idea of conforming to any conventions, such as splitting code and data up, and conforming to the linux filesystem structure. I believe strongly in keeping things as conventional as possible, but this is not why I am submitting this request, this request is because o of the final comment: https://code.onedev.io/onedev/server/~issues/1322#IssueComment-4725 The upstream owner has made it clear since the addition of this package, that he is against the idea of an AUR package. I attempted to make it work, going to lengths to discuss with Antiz and other TUs to try to get it to work. Jelle told me to drop the package like a dead horse about a month ago, I finally have come to terms that this software is not packagable. Again, this is not bias, this is me finally following upstreams wishes! [1] https://aur.archlinux.org/account/PolarianDev/ [2] https://aur.archlinux.org/pkgbase/onedev-bin/

2 years, 8 months

[PRQ#45463] Orphan Request for powwow

by notify＠aur.archlinux.org

MarsSeed [1] filed an orphan request for powwow [2]: Broken; needs maintainer attention or deletion. Also there are newer versions (latest is from 2021); flagged since 2022-02-16. [1] https://aur.archlinux.org/account/MarsSeed/ [2] https://aur.archlinux.org/pkgbase/powwow/

2 years, 4 months

[PRQ#73343] Orphan Request for rdkit-inchi

by notify＠aur.archlinux.org

e-kwsm [1] filed an orphan request for rdkit-inchi [2]: I mean this is orphaned, not deletion. [1] https://aur.archlinux.org/account/e-kwsm/ [2] https://aur.archlinux.org/pkgbase/rdkit-inchi/

7 months

Re: [aur-requests] [PRQ#17157] Deletion Request for f5vpn

by Zach Hoffman

What is the status of this deletion request? Can we please reject it? Does anything need to change? On Wed, Jan 1, 2020 at 11:10 AM Zach Hoffman <zach(a)zrhoffman.net> wrote: > The package absolutely does not contain university-specific installation > files. The reason the two linked files contain different hashes is that > they are different versions. Steps to verify this: > 1. Download both RPMs > 2. Extractthe RPM > 3. Open ${srcdir}/opt/f5/vpn/f5vpn in the editor of your choice > 4. Search for the text Version: > 5. Notice that it.emory.edu's RPM is version 7171.2018.0808.1, while > vpn.uts.edu.au's RPM is version 7181.2019.0620.1 > > These RPMs would have been downloaded originally from F5's website by > downloading the APM Clients ISO (latest version is > 7182.2019.923.1603-4727.0) and copying linux_f5vpn.x86_64.rpm. This ISO > does not vary based on who downloads it. > > On Wed, Jan 1, 2020 at 7:50 AM <notify(a)aur.archlinux.org> wrote: > >> HailHydra [1] filed a deletion request for f5vpn [2]: >> >> Package contains university specific installation files with no >> indication of such in package naming or description. >> The 'linux_f5vpn.x86_64.rpm' file is specific to the university it is >> downloaded from, this can be seen by the differing hash sums of the >> file linked in the PKGBUILD >> ("https://it.emory.edu/vpntools/linux_f5vpn.x86_64.rpm") and one >> provided by a different university (ie. >> "https://vpn.uts.edu.au/public/download/linux_f5vpn.x86_64.rpm") >> >> [1] https://aur.archlinux.org/account/HailHydra/ >> [2] https://aur.archlinux.org/pkgbase/f5vpn/ > >

5 years, 11 months

Re: [aur-requests] [PRQ#28554] Deletion Request for docker-compose1

by Amin Vakil

On 9/30/21 23:34, Tom Braack wrote: > Hi, > > yes, I've read that. > > I created that to specifically provide the 1.x release line of docker-compose, as the official package was recently bumped to 2.x, which has major incompatibilities. > > If having such a package is not the right way, what's your suggestion for providing older, yet widely used versions? > > Thanks, > sh0rez > >> On 30. Sep 2021, at 21:34, notify(a)aur.archlinux.org wrote: >> >> aminvakil [1] filed a deletion request for docker-compose1 [2]: >> >> 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. >> >> [1] https://aur.archlinux.org/account/aminvakil/ >> [2] https://aur.archlinux.org/pkgbase/docker-compose1/ Hi, 1.x is not going to be maintained anymore (except security fixes), so I'd suggest using docker-compose-1.29.2 from your local cache until you change your yaml files and make them compatible with 2.x. Also --compatibility is a flag on 2.x. Best Regards, Amin Vakil

4 years, 2 months

Re: [PRQ#43209] Deletion Request for xdg-utils-custom-open

by Marcell Meszaros

@yochananmarqos, this deletion request is based on mistaken assumptions. TLDR: It is not hard to create a modified package based on xdg-utils source by deleting one script, 'xdg-open', and making the package depend on another package that either has an alternative implementation of that script with the same name, or a symlink with the same name pointing to another shell script that is interface-compatible with the original 'xdg-open'. For more details, please kindly read the discussion that took place on 2023-06-27 on the following page: https://aur.archlinux.org/packages/xdg-utils-no-open (archived: https://archive.ph/zk7uR) Ref also owner's merge request [PRQ#43206] from xdg-utils-no-open to xdg-utils-custom-open. Please kindly revoke this ill-conceived deletion request and let @jfrankenau implement a viable, Arch-repo-compatible drop-in customization solution for xdg-utils that is mostly similar to what Arch's 'xdg-desktop-portal' package already utilizes: https://archlinux.org/packages/extra/x86_64/xdg-desktop-portal/ Thank you for your kind cooperation. :) Marcell (MarsSeed) On 29 June 2023 21:23:34 GMT+02:00, notify(a)aur.archlinux.org wrote: >yochananmarqos [1] filed a deletion request for xdg-utils-custom-open >[2]: > >Duplicate of xdg-utils. Custom? How? Open? As opposed to closed? >There's also a non-existent dependency on xdg-open-impl--whatever that >is. > >"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." > >-- >https://wiki.archlinux.org/title/AUR_submission_guidelines#Rules_of_submiss… > > > >[1] https://aur.archlinux.org/account/yochananmarqos/ >[2] https://aur.archlinux.org/pkgbase/xdg-utils-custom-open/

2 years, 5 months

Re: [PRQ#69254] Deletion Request for jdk16-adoptopenjdk

by Chris duke

Yes there is, MarsSeed. Pre 1.21 Minecraft Vanilla does and that's still attainable. Do not delete. On Wed, Feb 5, 2025, 4:39 PM Marcell Meszaros <marcell.meszaros(a)runbox.eu> wrote: > On 5 February 2025 13:48:53 GMT+01:00, FPSUsername < > FPSUsername(a)protonmail.com> wrote: > >As mentioned before some years ago. Some programs rely on java 16 for > example some versions of Minecraft do. > >It's the final version available and I think it should remain as an > available package for users to install when they need Java 16. > > > >--Best Regards, > >FPSUsername > > > >B.Eng. in Electrical Engineering > > > >Sent from Proton Mail Android > > > > > >-------- Original Message -------- > >On 2/5/25 13:40, <notify(a)aur.archlinux.org> wrote: > > > >> MarsSeed [1] filed a deletion request for jdk16-adoptopenjdk [2]: > >> > >> EOL since 2021, insecure, unneeded. > >> > >> [1] https://aur.archlinux.org/account/MarsSeed/ > >> [2] https://aur.archlinux.org/pkgbase/jdk16-adoptopenjdk/ > > There are no programs that rely on this specific JDK/JRE build.. > > It is also badly packaged upstream is open-source, but this PKGBUILD uses > a prebuilt binary. > > There are other jdk16 packages on AUR that are properly configured, e.g. > jdk16-openjdk maintained by PM @Muflone. >

10 months, 1 week

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