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

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, 6 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, 1 month

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, 8 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, 2 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, 1 month

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, 1 month

[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, 5 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, 6 months

Re: [PRQ#74949] Deletion Request for xlibre-server

by Vitalii Kuzhdin

Greetings, Uploading duplicate packages under a new name is not allowed on the AUR, and aggressive takeovers aren’t appreciated either. I’ve followed the naming convention used by official Xorg packages in the extra repository, and I see no reason to reinvent the wheel. To clarify and compare our approaches: 1. XLibre packages cannot provide their Xorg counterparts. The ABI versions have changed, meaning XLibre is not a drop-in replacement. Having it otherwise will result in broken systems and GUI sessions. I initially did this myself only because users would be reading the install instructions anyway, which required them to rebuild necessary components manually. However, now that there are discussions about adding XLibre to binary repositories, such provides/replaces must be removed. I agree it's inconvenient and I don’t enjoy the install process either, but for as long as there are several ABI versions, this trade-off is unavoidable. The author of the project has also made this clear: https://github.com/chaotic-aur/packages/issues/3684#issuecomment-3013197463 2. Apart from problems related to ABIs, there is also an issue with circular dependencies, namely with xlibre-input-libinput. The issue has been addressed in my packages using a bootstrap package. Your approach involves a “preupgrade” package to install before and then immediately replace. Again, your approach will result in broken setups, as users will not be forced to recompile anything after an update. Resolving this once at install time is also better than having to deal with it on every upgrade. In addition, users installing from binary repos won’t encounter this thanks to the replaces entries I added. 3. I haven't found meaningful differences in our packages beyond a few violations of AUR guidelines in yours (e.g., unneeded dependencies, ignored user build flags). So I see no reason to replace mine. Unrelated to the deletion request, I’d also like to address a few things: 1. The number of packages I maintain does not reflect my ability to support them. Plenty of AUR and official maintainers handle significantly more packages. I’ve also responded to each and every comment and email about XLibre and my other packages. In fact, this lasted daily for years, until a few weeks ago, when I had to update my packages once every few days instead of daily for very good reasons. I've also seen vague claims about my other packages being broken. If anyone feels that way, I invite them to point out specific cases and see how quickly I resolve them (if there are any at all). 2. I will not tolerate hate directed at me or my work. This especially shouldn't come from the XLibre community (either very active contributors or co-maintainers, I haven’t researched it) and should not be tolerated by you personally. I understand that reading step-by-step instructions is not for all of us, but I expect feedback to be constructive and respectful. Whoever sent the hateful messages and spammed my email by abusing the Out-of-Date flag: I expect an apology under your real name, not from an anonymous account. Otherwise, direct further communication to: vitaliikuzhdin+spam(a)gmail.com. 3. Once the above issues are resolved, and as long as the PKGBUILDs remain compliant, I’d be happy to add you as co-maintainers. With my slight experience in the topic and your official involvement, I think this project can be extremely useful and well-supported. Best regards, Vitalii Kuzhdin On Tue, Jul 29, 2025 at 8:18 PM <notify(a)aur.archlinux.org> wrote: > xlibre [1] filed a deletion request for xlibre-server [2]: > > Hello vitaliikuzhdin, > Thank you for the xlibre pkgs. > Currently we from the offcial Xlibre team are adding our supported > PKGBUILD and related files to the AUR. So can you pls remove all you > xlibre related packages? > Thank you. > artist for Xlibre > > [1] https://aur.archlinux.org/account/xlibre/ > [2] https://aur.archlinux.org/pkgbase/xlibre-server/

2 weeks, 1 day

Re: [PRQ#74820] Deletion Request for discord-canary-with-stable-dot-desktop

by MrPowerGamerBR

Hey (I hope I'm replying to this the right way), so, if the AUR maintainers think that the package should be removed, then it can be removed. It is my first AUR package so I may have misunderstood when I should actually create a new package vs contact the maintainers. The reason why I didn't contact the "discord-canary" maintainers is because my fix is a workaround to a bug on the original deb (as provided by Discord) Discord Canary package. My fix, however, does conflict with the original Discord installation, so you wouldn't be able to have "discord" and "discord-canary" installed on the same machine, which is why I thought it would be better to upload as a new package instead of trying to patch the original package (which could break some users workflows). The bug is that it seems that Discord hardcodes somewhere "discord.desktop" in the Discord source code, so all notifications and the unread notification badge relies on the "discord.desktop" file name but, because the "discord-canary" package uses the "discord-canary.desktop" (Which isn't wrong mind you! That's the name of the file inside the original deb package!) notifications are bound to an unknown application (so you can't disable them in KDE Plasma Notifications panel) and unread notifications badges do not work even if you have libunity installed. In fact I did provide a workaround to the bug in the original "discord-canary" package comments, however my workaround was not *that* great because it does break every time a new Discord Canary update is released, due to my DE (KDE Plasma) preferring the updated package desktop file instead of using the "discord.desktop" copy until the system is restarted or the local desktop cache refreshed. So I've decided to patch it on the PKGBUILD level. About the name: It was inspired by the "discord-canary-with-flags" package name. I couldn't figure out a better name for it because the package does what it says on the tin, I also didn't want to use a vague name like "discord-canary-fix" because that would feel very sketchy (see the names used by malicious AUR packages). So it is a conundrum of: "Should this be fixed in the original package and break users that have both discord and discord-canary installed, or should I create my own package for the users that understand the drawbacks?" But anyway, if the package feels like it can be removed, feel free to go ahead with it. I do understand that my package is, for all intents and purposes, just a clone of the current "discord-canary" package with a fix that, honestly, I think that only myself cares about. Em qui., 24 de jul. de 2025 às 15:35, <notify(a)aur.archlinux.org> escreveu: > yochananmarqos [1] filed a deletion request for discord-canary-with- > stable-dot-desktop [2]: > > Unnecessary duplicate of discord-canary. If there is an issue with the > existing package, contact the Maintainer instead of creating a > duplicate with such a minor change. Also, the package name is > ridiculous. > > [1] https://aur.archlinux.org/account/yochananmarqos/ > [2] > https://aur.archlinux.org/pkgbase/discord-canary-with-stable-dot-desktop/

2 weeks, 6 days

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