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

Re: [PRQ#70009] Deletion Request for rpcs3

by Annie Leonhardt

Hello, Thank you for your reply. We can bump the AUR version should we need to push a protocol update, for example. And even then, users can still trigger an AUR update on their side if they see it's outdated and they need something from newer. We are not interested in bug reports on old builds, as we do not accept those, only the latest build is supported. We tend to break master branch every so often, and we can quickly remove builds from our updater to prevent regressions from spreading. The updater then updates to the last good build. And again, we can quickly push a version update to the git version if we want users to get explicitly prompted for update. With arbitrary version bumps, there is no way to tell if a version is good or not. Furthermore, we are already receiving support requests from people on this AUR because it's outdated, and we do not want to have these. A version of this AUR existed in the past, but due to the same reasons we also asked for it to be removed. Best Regards, Ani ________________________________ From: Vitalii Kuzhdin <vitaliikuzhdin(a)gmail.com> Sent: Sunday, February 16, 2025 8:14 PM To: noreply(a)aur.archlinux.org <noreply(a)aur.archlinux.org> Cc: aur-requests(a)lists.archlinux.org <aur-requests(a)lists.archlinux.org>; ani-leo(a)outlook.com <ani-leo(a)outlook.com> Subject: Re: [PRQ#70009] Deletion Request for rpcs3 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<mailto:notify@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, 3 weeks

Re: [PRQ#54226] Deletion Request for ly-git-openrc

by Robin Candau

On 2/27/24 18:15, jahway603 wrote: > I was not aware of that, so thank you for sharing that insight with me Robin. What I am aware of is that when I search the AUR for "-openrc" that the result yields 83 results meaning there are 83 packages which utilize OpenRC as their init system, including my package in question here. > > Marcell's argument that "This package was intended for a systemd-less Arch derivative, and is not useful on Arch Linux, due to the fact that it is virtually impossible nowadays to run Arch without systemd..." is not valid as Arch Linux gives us the freedom to run whatever init system we choose to run. The power of Arch Linux is to enable the user to be able to use whatever they choose. > > If Marcell's logic to delete this package is to remain valid then are there also plans to delete the other 82 packages using OpenRC from the AUR? And are there also plans to delete the Arch Wiki page about OpenRC (https://wiki.archlinux.org/title/OpenRC)? > Hi, As I said, my remark was strictly about the "the AUR is also used by all derivatives" argument, which is not relevant/acceptable on its own as the AUR is made for Arch Linux only. I wasn't necessarily taking position regarding the deletion request below. However, when it comes to openrc specifically, I think it is important to notice that only systemd is officially supported on Arch Linux, as stated in the OpenRC wiki page you linked (it's actually the first thing noted on the page as a warning block [1]) and as demonstrated by the fact that OpenRC itself is an AUR package (which are not officially supported either, see the warning block on the related wiki page [2]). The fact that Artix (or whatever other derivatives) officially supports openrc will not change the fact that Arch Linux itself does not, neither the fact that the AUR is an official Arch Linux ressource made for Arch Linux specifically (while it does not prevent derivatives to use it, they are not specifically taken into consideration). Once again, I'm not necessarily saying that this deletion request should be accepted or not, it will be evaluated carefully as every other pending requests. However, it's only fair to expose the current state of things when it comes to the Arch/AUR and unsupported derivatives/init system. I hope you get my point :) [1] https://wiki.archlinux.org/title/OpenRC [2] https://wiki.archlinux.org/title/Arch_User_Repository > > On Tuesday, February 27th, 2024 at 11:50 AM, Robin Candau <antiz(a)archlinux.org> wrote: > >> On 2/27/24 16:38, jahway603 wrote: >> >>> THIS SHOULD NOT BE DELETED as the AUR is used by Arch and ALL derivatives of Arch, like Artix, Manjaro, EndeavourOS, etc. >> >> The AUR has been made by Arch Linux for Arch Linux. Derivatives are >> not supported and packages made specifically for such distros are >> not allowed. >> So, regardless of the below request and whether it will lead to a >> deletion of the package or not, the above argument is not relevant. >> >>> On Monday, February 26th, 2024 at 2:11 PM, notify(a)aur.archlinux.org notify(a)aur.archlinux.org wrote: >>> >>>> MarsSeed [1] filed a deletion request for ly-git-openrc [2]: >>>> >>>> Problematic, but unneeded VCS package with wrong name, missing >>>> provides field and pkgver() function. >>>> >>>> The stable ly package is carried by extra repo, and there is a proper >>>> ly-git on AUR. >>>> >>>> This package was intended for a systemd-less Arch derivative, and is >>>> not useful on Arch Linux, due to the fact that it is virtually >>>> impossible nowadays to run Arch without systemd (hence the other >>>> distros). >>>> >>>> [1] https://aur.archlinux.org/account/MarsSeed/ >>>> [2] https://aur.archlinux.org/pkgbase/ly-git-openrc/ >> >> >> -- >> Regards, >> Robin Candau / Antiz -- Regards, Robin Candau / Antiz

1 year, 6 months

Re: [aur-requests] [PRQ#31497] Deletion Request for anbox-modules-dkms

by info＠sick.codes

Hey eNV25, Just because the non-git and git packages are on the same commit id does not mean the whole package should be wiped and its changelog, comments, AUR git history, and any other informative discussion should be deleted. Once master is updated, the non-git will be out of date. That's what Out of Date is for. # non-git source=("git+https://github.com/choff/${_pkgname}.git#commit=8148a162755bf5500a07cf4…" # git source=("git+$url#branch=master") As you know your original Merge Request reasons were already addressed. Merge request: https://lists.archlinux.org/pipermail/aur-requests/2021-December/063155.html Fixes: https://aur.archlinux.org/cgit/aur.git/commit/?h=anbox-modules-dkms&id=8790… And: https://aur.archlinux.org/cgit/aur.git/commit/?h=anbox-modules-dkms&id=20a6… - Removed the build function from previous 2017 maintainer - Removed linux-headers from previous 2017 maintainer - Removed /usr/lib/modules-load.d/ from previous 2017 maintainer I didn't create the original pkgbuild, I simply revived it as-is, including it's git history for transparency. I didn't write the original PKGBUILD. I re-uploaded it with accurate git history so that anyone else can actually see the commit history of the package: https://aur.archlinux.org/cgit/aur.git/log/?h=anbox-modules-dkms Given you are well aware I was actively maintaining the package, why would you submit a merge request instead of emailing me or submit a pull request? I really don't understand your sudden urgency to remove the package from the AUR. Why did you merge instead of suggesting changes? And why do you want the package deleted so urgently? In good faith, Sick Codes of the Security Research Team @SickCodes <https://twitter.com/sickcodes> https://sick.codes https://github.com/sickcodes https://twitter.com/sickcodes https://www.linkedin.com/in/sickcodes/ https://www.youtube.com/c/sickcodes https://parler.com/profile/sickcodes/ https://hackerone.com/sickcodes https://bugcrowd.com/sickcodes https://hub.docker.com/r/sickcodes Jan 15, 2022, 09:05 by env252525(a)gmail.com: > On Sat, Jan 15, 2022 at 11:10 AM <info(a)sick.codes> wrote: > >> >> This is a false deletion request, the maintainer knows this is a correct non-git dkms PKGBUILD >> > > I don't think so. > >> >> https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=anbox-modules-dkms >> >> The maintainer discussion between myself and the other maintainer is on https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=anbox-modules-dkms >> >> I don’t we know what the current maintainer is trying to achieve here but the two packages are distinct. >> >> 1) I personally maintain the fork with the GitHub user >> > > fine > >> >> 2) I had already made env25 a co maintainer >> > > And I made you a co-maintainer for anbox-modules-dkms-git > >> 3) I am on the WayDroid dev team >> > > It's not relevant who you are > >> 2) this fork was created by myself and Choff >> > > fine > >> 3) the non-git is perfectly fine now >> > > No it's not it's a duplicate of anbox-modules-dkms-git > >> 4) eNV25 has already merged requested this, in a rush, for no apparent reason. >> > > The TU ainola merged this. I submitted the request. > > https://lists.archlinux.org/pipermail/aur-requests/2021-December/063155.html > https://lists.archlinux.org/pipermail/aur-requests/2021-December/063596.html > >> >> Please reject this merge & deletion request for the following reasons: >> > > Please don't reject this deletion request. > >> >> And if possible please merge back the non-git repo comment history as you can clearly see >> >> I have been maintaining the WIKI on Anbox to be accurate https://wiki.archlinux.org/title/Anbox >> > > fine > > >> >> In good faith, >> >> Sick Codes of the Security Research Team @SickCodes >> >> https://sick.codes >> https://github.com/sickcodes >> https://twitter.com/sickcodes >> https://www.linkedin.com/in/sickcodes/ >> https://www.youtube.com/c/sickcodes >> https://parler.com/profile/sickcodes/ >> https://hackerone.com/sickcodes >> https://bugcrowd.com/sickcodes >> https://hub.docker.com/r/sickcodes >> >> >> >> >> >> >> Jan 14, 2022, 22:57 by notify(a)aur.archlinux.org: >> >> eNV25 [1] filed a deletion request for anbox-modules-dkms [2]: >> >> This package is a duplicate of anbox-modules-dkms-git. >> >> I previously submitted a merge request from anbox-modules-dkms to >> anbox-modules-dkms-git. >> >> I maintain anbox-modules-dkms-git. >> >> [1] https://aur.archlinux.org/account/eNV25/ >> [2] https://aur.archlinux.org/pkgbase/anbox-modules-dkms/ >>

3 years, 8 months

Re: [PRQ#42162] Deletion Request for libopenblas

by sL1pKn07 SpinFlo

El jue, 15 jun 2023 a las 1:09, Marcell Meszaros (< marcell.meszaros(a)runbox.eu>) escribió: > 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) >>>> >>> is not theory. happens, and can you try yourself like i do before open the issue try it :) greetings

2 years, 3 months

Re: [PRQ#49836] Deletion Request for lib32-gd

by Marcell Meszaros

>>There is no other part of the libgphoto2 code that links to gd. > >that statement is not true at all > >https://github.com/search?q=repo%3Agphoto%2Flibgphoto2%20gd&type=code https://github.com/gphoto/libgphoto2/blob/807d44d0dcb0a8a8df151baa27830127f… Duh, of course the libgphoto2 configure script refers to gd / libgd. But this does not refute my statement. I've checked the entire source code of libgphoto2 for references, that's how I've found all the use cases of gd, and none of those are relevant in lib32. I'd suggest you do the same checking as I did if you are in doubt. The configure script of libgphoto2 let's one easily disable gd support. @sl1pkn07 I see the obvious pattern with you that you like to try to contradict others apparently just for the sake of it. But this kind of disagreement that you presented here is not a counterpoint at all. Also you seem to like to maintain newly introduced multimedia libraries in lib32 that have no use case whatsoever. You also tend to cling to extremely old, deprecated, discontinued software that have no users on AUR apart from you. Deleting lib32-gd of course will allow the deletion of lib32-libheif, a package you maintain in vain, because that also falls into the category of "too new, so no imaginable practical use cases at all in lib32". Please try, really try to refrain from coming up with moot arguments. Such things do not contribute anything useful to deciding the fate of packages, and the attitude behind it is also detrimental to the community as a whole. On 30 October 2023 01:35:05 GMT+01:00, sL1pKn07 SpinFlo <sl1pkn07(a)gmail.com> wrote: >>There is no other part of the libgphoto2 code that links to gd. > >that statement is not true at all > >https://github.com/search?q=repo%3Agphoto%2Flibgphoto2%20gd&type=code >https://github.com/gphoto/libgphoto2/blob/807d44d0dcb0a8a8df151baa27830127f… > >i think you need talk with upstream for why still keep this type of thing >in the code if is not used > >greetings > >El dom, 29 oct 2023 a las 22:55, <notify(a)aur.archlinux.org> escribió: > >> MarsSeed [1] filed a deletion request for lib32-gd [2]: >> >> lib32-gd is absolutely unnecessary for lib32-libgphoto2. >> >> The latter could only use gd for on-the-fly image conversion two >> specific digital "picture frame" hardware, for which libgphoto2 >> introduced support in 2015, well within the 64-bit era. Also that >> library is utilized for Docupen scanner pen support, starting from >> 2020. >> >> There is no other part of the libgphoto2 code that links to gd. >> Therefore I cannot conceive any application that is bin32 only and >> needs this specialized functionality of libgphoto2 for those 2015 and >> 2020 released, 64-bit compatible niche hardware devices. >> >> I've notified the maintainer of lib32-libgphoto2 about this in July >> 2023. >> >> Deleting this unneeded library would in turn allow other lib32 >> packages to be dropped. And also it would help reduce the dependency >> build burden on people who use AUR/wine-stable. >> >> [1] https://aur.archlinux.org/account/MarsSeed/ >> [2] https://aur.archlinux.org/pkgbase/lib32-gd/

1 year, 9 months

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

by Mark Wagie

Oh, sorry. You're right, 'just pack' does call build before zipping the extension. Either way, there is no upstream release and it has not been uploaded to EGO yet. It seems the developer is waiting for a new version of Blur My Shell before submitting it as he mentioned here: https://github.com/yilozt/rounded-window-corners/pull/159#issuecomment-2093… Sent with [Proton Mail](https://proton.me/) secure email. On Thursday, May 23rd, 2024 at 2:31 PM, Grzegorz Kozub <grzegorz.kozub(a)gmail.com> wrote: > 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, 3 months

Re: [PRQ#43239] Deletion Request for mesa-steamos

by Luke Short

Hey MarsSeed, Thank you for your feedback. There is a lot of missing context that I will add. I will start by saying that I am not simply duplicating SteamOS packages for no reason. * SteamOS actually splits their Mesa drivers into two packages: * "mesa" and "mesa-radv". Mesa is a slightly older version (22.2.0 right now). RADV (23.1.1-git right now) and more likely to break. * Instead of packaging both, I took the more conservative path with just re-packaging "mesa". In the next update, I already have plans to switch to "mesa-radv". Both are the exact same code-base/commits from Valve. "mesa-radv" is just slightly newer. * Refer to the latest stable packages here: https://steamdeck-packages.steamos.cloud/archlinux-mirror/jupiter-rel/os/x8… * Mesa in SteamOS only has drivers enabled for AMD. I have re-enabled drivers for Intel, virtualization, software rendering, etc. * Refer to the change log of the "mesa-steamos" package: https://aur.archlinux.org/cgit/aur.git/log/?h=mesa-steamos * You cannot simply install Mesa from SteamOS by enabling their repositories. They are using an old version of Arch Linux. It's built using LLVM that is now (1) only available in the AUR and (2) does not have a 32-bit package so 32-bit graphics drivers cannot be re-built or used. * Mesa from SteamOS provides patches to help with gamescope-session and improved AMD RDNA 2 support. It is different from upstream Mesa as Valve makes many of their own patches and not all of them end up upstream. Deleting these packages seems very drastic. I do keep these up-to-date and am planning to rebase again when SteamOS 3.5 is released. Let me know if this makes sense or if you have any other concerns. Sincerely, Luke Short On Fri, Jun 30, 2023 at 12:57 AM <notify(a)aur.archlinux.org> wrote: > MarsSeed [1] filed a deletion request for mesa-steamos [2]: > > This package doesn't make sense to have. > > Name suggests it duplicates SteamOS package, but maintainer actually > tries (and fails) to duplicate the Steam Deck version of the package. > Which is not the same, given that Steam Deck gets periodical batches > of upgrades, not minute-by-minute rolling updates as on Arch. > > Current package version is '22.2.0.157821.radeonsi_3.4.0_2'. > But the commit message for this update says "Update to SteamOS 3.4.6". > > Well, as per Valve's release announcement, Steam Deck 3.4.6 has Mesa > 23.1. [a] > > @LukeShortCloud, please don't confuse SteamOS per se with Steam Deck > when it comes to package naming. Steam Deck has a different release > cadence than main SteamOS. > > If you want to maintain packages for Steam Deck, use the '-steamdeck' > suffix in package name. > > Even then, don't duplicate alredy existing Steam Deck / SteamOS > packages for no reason. > > Thank you. > > [a]: > > https://steamcommunity.com/games/1675200/announcements/detail/3675538825744… > > [1] https://aur.archlinux.org/account/MarsSeed/ > [2] https://aur.archlinux.org/pkgbase/mesa-steamos/

2 years, 2 months

Re: [PRQ#42226] Deletion Request for wire-desktop-appimage

by Marcell Meszaros

One can also install a standalone AppImage file by running it. It does not need to be packaged via an AUR PKGBUILD. On 16 June 2023 18:55:00 GMT+02:00, Ashleigh Rowe <administrator(a)hax.ie> wrote: >Hi Marcell, > >That may be the case, but there are many reasons to want to use an appimage over a natively installed application. And, given that it is not the same package, it need not be deleted. Taking the same logic to it's extreme, one could argue that a -git and a -bin version of a package need not both be on the AUR, as for users, it is the same. >We both know, however, that this is not the case. > >On 16/06/2023 17:31, Marcell Meszaros wrote: >> > So, by your own admission, it is not a duplicate of a repo package then? >> >> Hi Asleigh, >> >> Thank you for your reply. >> >> The way I see it, the Arch repo version integrates better with the system and does not include unnecessary bloat. >> >> The AUR AppImage version carries its own Electron runtime rather than using one available from Arch repo. >> >> The feature set is the same. >> >> So, for all intents and purposes, the AUR package is the same for users. >> >> Except the latter takes up more space, and is potentially more insecure >> >> There are frequent updates of Electron in repo. >> The AUR package won't update its built-in electron separately. >> >> On the other hand, repo's wire-desktop package will always use the latest repo-updated version of its electron runtime. >> >> All in all, the AUR version is an inferior duplicate. >> >> In my understanding, it is only useful to have AppImage packages of especially Electron-based applications on AUR if the Arch repo does not carry that application. >> >> Cheers, >> Marcell (Mars) >> >> >> On 16 June 2023 17:23:12 GMT+02:00, Ashleigh Rowe <administrator(a)hax.ie> wrote: >> >> So, by your own admission, it is not a duplicate of a repo package >> then? >> >> On Fri, 16 Jun 2023 at 16:20, <notify(a)aur.archlinux.org> wrote: >> >> MarsSeed [1] filed a deletion request for >> wire-desktop-appimage [2]: >> >> Duplicate of repo package, not needed: >> >> https://archlinux.org/packages/extra/any/wire-desktop/ >> >> This is an Electron-based application, so there is no benefit >> in using >> this AppImage in a PKGBUILD. The repo version has the exact same >> application code. >> >> And repo verison is even better because it does not duplicate the >> electron runtime, but depends on the relevant repo electron >> package. >> >> [1] https://aur.archlinux.org/account/MarsSeed/ >> [2] https://aur.archlinux.org/pkgbase/wire-desktop-appimage/ >>

2 years, 3 months

[PRQ#54031] Deletion Request for prusa-slicer-git

by notify＠aur.archlinux.org

klickmo [1] filed a deletion request for prusa-slicer-git [2]: I've installed the prusa-slicer-git in my Endeavouros Cassini OS and I can neither use it nor remove it. What else can I do to use or remove it properly? [paul@Kallisto ~]$ git clone https://aur.archlinux.org/prusa-slicer- git.git Klone nach 'prusa-slicer-git'... remote: Enumerating objects: 225, done. remote: Counting objects: 100% (225/225), done. remote: Compressing objects: 100% (186/186), done. remote: Total 225 (delta 41), reused 218 (delta 37), pack-reused 0 Empfange Objekte: 100% (225/225), 80.06 KiB | 1.23 MiB/s, fertig. Löse Unterschiede auf: 100% (41/41), fertig. [paul@Kallisto ~]$ cd prusa-slicer-git [paul@Kallisto prusa-slicer-git]$ ls PKGBUILD [paul@Kallisto prusa-slicer-git]$ makepkg -si ==> Erstelle Paket: prusa-slicer-git 2.6.0.beta4.r1.gdbc2584d8-1 (Lu 19 feb 2024 22:22:27 +0200) ==> Prüfe Laufzeit-Abhängigkeiten... ==> Prüfe Buildtime-Abhängigkeiten... ==> Installiere fehlende Abhängigkeiten... [sudo] Passwort für paul: Abhängigkeiten werden aufgelöst … Nach in Konflikt stehenden Paketen wird gesucht … Paket (4) Neue Version Netto-Veränderung Größe des Downloads extra/compiler-rt 16.0.6-3 36,95 MiB 3,16 MiB extra/clang 16.0.6-2 209,20 MiB 42,43 MiB extra/eigen 3.4.0-2 8,37 MiB 1,05 MiB extra/gtest 1.14.0-1 2,14 MiB 0,46 MiB Gesamtgröße des Downloads: 47,10 MiB Gesamtgröße der installierten Pakete: 256,66 MiB :: Installation fortsetzen? [J/n] J :: Pakete werden empfangen … gtest-1.14.0-1-x... 468,8 KiB 2,74 MiB/s 00:00 [----------------------] 100% eigen-3.4.0-2-any 1077,6 KiB 3,54 MiB/s 00:00 [----------------------] 100% compiler-rt-16.0... 3,2 MiB 1446 KiB/s 00:02 [----------------------] 100% clang-16.0.6-2-x... 42,4 MiB 8,77 MiB/s 00:05 [----------------------] 100% Gesamt (4/4) 47,1 MiB 9,68 MiB/s 00:05 [----------------------] 100% (4/4) Schlüssel im Schlüsselbund werden geprüft [----------------------] 100% (4/4) Paket-Integrität wird überprüft [----------------------] 100% (4/4) Paket-Dateien werden geladen [----------------------] 100% (4/4) Auf Dateikonflikte wird geprüft [----------------------] 100% :: Paketänderungen werden verarbeitet … (1/4) Installiert wird compiler-rt [----------------------] 100% (2/4) Installiert wird clang [----------------------] 100% Optionale Abhängigkeiten für clang openmp: OpenMP support in clang with -fopenmp python: for scan-view and git-clang-format [Installiert] llvm: referenced by some clang headers (3/4) Installiert wird eigen [----------------------] 100% (4/4) Installiert wird gtest [----------------------] 100% Optionale Abhängigkeiten für gtest python: gmock generator [Installiert] :: Post-transaction-Hooks werden gestartet … (1/1) Arming ConditionNeedsUpdate... ==> Empfange Quellen... -> Klone das PrusaSlicer git Repo... Klone in Bare-Repository '/home/paul/prusa-slicer-git/PrusaSlicer' ... remote: Enumerating objects: 263654, done. remote: Counting objects: 100% (2847/2847), done. remote: Compressing objects: 100% (1408/1408), done. remote: Total 263654 (delta 1983), reused 2118 (delta 1435), pack- reused 260807 Empfange Objekte: 100% (263654/263654), 419.56 MiB | 4.77 MiB/s, fertig. Löse Unterschiede auf: 100% (206384/206384), fertig. ==> Überprüfe source Dateien mit sha256sums... PrusaSlicer ... Übersprungen ==> Entpacke Quellen... -> Erstelle Arbeitskopie des PrusaSlicer git Repos... Klone nach 'PrusaSlicer'... Fertig. ==> Beginne prepare()... Schwerwiegend: bad object 72f6a4e7c7dccc47f203ce8c27b3022c6d7743e8 ==> FEHLER: Ein Fehler geschah in prepare(). Breche ab... [paul@Kallisto prusa-slicer-git]$ ls PKGBUILD PrusaSlicer src [paul@Kallisto prusa-slicer-git]$ cd PrusaSlicer [paul@Kallisto PrusaSlicer]$ ls branches config description HEAD hooks info objects packed-refs refs [paul@Kallisto PrusaSlicer]$ cd .. [paul@Kallisto prusa-slicer-git]$ cd .. [paul@Kallisto ~]$ sudo pacman -R prusa-slicer-git Fehler: Ziel nicht gefunden: prusa-slicer-git [paul@Kallisto ~]$ yay -R prusa-slicer-git Fehler: Ziel nicht gefunden: prusa-slicer-git -> exit status 1 [1] https://aur.archlinux.org/account/klickmo/ [2] https://aur.archlinux.org/pkgbase/prusa-slicer-git/

1 year, 7 months

Re: [aur-requests] [PRQ#31497] Deletion Request for anbox-modules-dkms

by eNV25

It is still a duplicate. There are no releases upstream. What's the point of having a non git version if it's just going to follow the latest git commit anyway? Yes this matter was resolved. The package was merged. That is why anbox-modules-dkms should not exist. On Sat, Jan 15, 2022 at 4:08 PM <info(a)sick.codes> wrote: > Hey eNV25, > > Just because the non-git and git packages are on the same commit id does > not mean the whole package should be wiped and its changelog, comments, AUR > git history, and any other informative discussion should be deleted. > > Once master is updated, the non-git will be out of date. That's what Out > of Date is for. > > # non-git > source=("git+ > https://github.com/choff/${_pkgname}.git#commit=8148a162755bf5500a07cf41a65… > " > > # git > source=("git+$url#branch=master") > > As you know your original Merge Request reasons were already addressed. > > Merge request: > https://lists.archlinux.org/pipermail/aur-requests/2021-December/063155.html > > Fixes: > https://aur.archlinux.org/cgit/aur.git/commit/?h=anbox-modules-dkms&id=8790… > > And: > https://aur.archlinux.org/cgit/aur.git/commit/?h=anbox-modules-dkms&id=20a6… > > - Removed the build function from previous 2017 maintainer > - Removed linux-headers from previous 2017 maintainer > - Removed /usr/lib/modules-load.d/ from previous 2017 maintainer > > I didn't create the original pkgbuild, I simply revived it as-is, > including it's git history for transparency. I didn't write the original > PKGBUILD. I re-uploaded it with accurate git history so that anyone else > can actually see the commit history of the package: > https://aur.archlinux.org/cgit/aur.git/log/?h=anbox-modules-dkms > > Given you are well aware I was actively maintaining the package, why would > you submit a merge request instead of emailing me or submit a pull request? > > I really don't understand your sudden urgency to remove the package from > the AUR. > > Why did you merge instead of suggesting changes? > > And why do you want the package deleted so urgently? > > In good faith, > > Sick Codes of the Security Research Team @SickCodes > <https://twitter.com/sickcodes> > > https://sick.codes > https://github.com/sickcodes > https://twitter.com/sickcodes > https://www.linkedin.com/in/sickcodes/ > https://www.youtube.com/c/sickcodes > https://parler.com/profile/sickcodes/ > https://hackerone.com/sickcodes > https://bugcrowd.com/sickcodes > https://hub.docker.com/r/sickcodes > > > > > > > Jan 15, 2022, 09:05 by env252525(a)gmail.com: > > On Sat, Jan 15, 2022 at 11:10 AM <info(a)sick.codes> wrote: > > > This is a false deletion request, the maintainer knows this is a correct > non-git dkms PKGBUILD > > > I don't think so. > > > https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=anbox-modules-dkms > > The maintainer discussion between myself and the other maintainer is on > https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=anbox-modules-dkms > > I don’t we know what the current maintainer is trying to achieve here but > the two packages are distinct. > > 1) I personally maintain the fork with the GitHub user > > > fine > > > 2) I had already made env25 a co maintainer > > > And I made you a co-maintainer for anbox-modules-dkms-git > > 3) I am on the WayDroid dev team > > > It's not relevant who you are > > 2) this fork was created by myself and Choff > > > fine > > 3) the non-git is perfectly fine now > > > No it's not it's a duplicate of anbox-modules-dkms-git > > 4) eNV25 has already merged requested this, in a rush, for no apparent > reason. > > > The TU ainola merged this. I submitted the request. > > > https://lists.archlinux.org/pipermail/aur-requests/2021-December/063155.html > > https://lists.archlinux.org/pipermail/aur-requests/2021-December/063596.html > > > Please reject this merge & deletion request for the following reasons: > > > Please don't reject this deletion request. > > > And if possible please merge back the non-git repo comment history as you > can clearly see > > I have been maintaining the WIKI on Anbox to be accurate > https://wiki.archlinux.org/title/Anbox > > > fine > > > In good faith, > > Sick Codes of the Security Research Team @SickCodes > > https://sick.codes > https://github.com/sickcodes > https://twitter.com/sickcodes > https://www.linkedin.com/in/sickcodes/ > https://www.youtube.com/c/sickcodes > https://parler.com/profile/sickcodes/ > https://hackerone.com/sickcodes > https://bugcrowd.com/sickcodes > https://hub.docker.com/r/sickcodes > > > > > > > Jan 14, 2022, 22:57 by notify(a)aur.archlinux.org: > > eNV25 [1] filed a deletion request for anbox-modules-dkms [2]: > > This package is a duplicate of anbox-modules-dkms-git. > > I previously submitted a merge request from anbox-modules-dkms to > anbox-modules-dkms-git. > > I maintain anbox-modules-dkms-git. > > [1] https://aur.archlinux.org/account/eNV25/ > [2] https://aur.archlinux.org/pkgbase/anbox-modules-dkms/ > > >

3 years, 8 months

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