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

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

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/

1 month, 3 weeks

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/

1 month, 4 weeks

Re: [PRQ#50811] Deletion Request for enchant-pure

by Marcell Meszaros

Hi, Based on what you wrote, I surmise that shared library import warning logs are irrelevant for users, and those warnings can also be filtered out from system logs when debugging real problems. So it leads me to conclude that this package is not sufficiently useful to users to justify having this lesser-functionality duplicate in AUR. If the reported warnings have relevant detrimental effects, I suggest that you file an Arch bug ticket. Also, repo's enchant could solve this issue by making a split package of it, and putting each spell checking engine related .so library in separate subpackages, which in turn should each depend on their respective engine library, with the main enchant package optdepending on these engine-specific split 'enchant-*' packages. On 11 November 2023 17:57:05 GMT+01:00, Behnam Momeni <s.b.momeni(a)gmail.com> wrote: >Greetings MarsSeed and Marcell, > > >The enchant-pure is more "pure" than extra repo's version because it is built by disabling all backends, but the aspell and hunspell which allow all languages to be enabled/disabled selectively. If we install those other backends, they will be detected and used at runtime with no issue too (as demonstrated by the enchant-hspell AUR package). > >However, the extra repo's version is built by enabling all backend engines. Therefore, even when those backends are not installed, the built enchant contains those (missing) dependencies binding. > >This problem can be seen by running "gedit" as an example enchant client, after installing the extra repo's version of enchant package, and watching its warnings in the console (open gedit with the enchant-pure version and no such warning will be printed): > > >(gedit:6143): libenchant-WARNING **: 20:05:16.243: Error loading plugin: libvoikko.so.1: cannot open shared object file: No such file or directory > > (gedit:6143): libenchant-WARNING **: 20:05:16.243: Error loading plugin: libnuspell.so.5: cannot open shared object file: No such file or directory > > (gedit:6143): libenchant-WARNING **: 20:05:16.243: Error loading plugin: libhspell.so.0: cannot open shared object file: No such file or directory > > (gedit:6143): libenchant-WARNING **: 20:05:16.259: Error loading plugin: libvoikko.so.1: cannot open shared object file: No such file or directory > > (gedit:6143): libenchant-WARNING **: 20:05:16.260: Error loading plugin: libnuspell.so.5: cannot open shared object file: No such file or directory > > (gedit:6143): libenchant-WARNING **: 20:05:16.261: Error loading plugin: libhspell.so.0: cannot open shared object file: No such file or directory > >On 11/11/23 12:30, Marcell Meszaros wrote: > >Actually this has not one, but two more mandatory spell checker library depends compared to repo's enchant. So it is even more "impure", to coin this package's weird choice of qualifier suffix. On 11 November 2023 09:49:08 GMT+01:00, notify(a)aur.archlinux.org <mailto:notify@aur.archlinux.org> wrote: > >MarsSeed [1] filed a deletion request for enchant-pure [2]: Unneeded duplicate of extra/enchant, with misleading name. This is less "pure" than extra repo's package, because it has one more mandatory depends than the latter. The repo package defines its dependency on all spell checking engines as optional. [1] https://aur.archlinux.org/account/MarsSeed/ [2] https://aur.archlinux.org/pkgbase/enchant-pure/ > >-- Best Regards, Behnam Momeni

1 year, 10 months

Re: [aur-requests] [PRQ#12066] Deletion Request for popcorntime

by Jean Lucas

Agreed on suspicious claims. However, both sides point the finger at each other, so I read the code. During build, gulp downloads a custom version of NW.js from get.popcorntime.sh[1]. I have verified that various binaries in the upstream and downstream NW.js packages vary in size. I haven't found a statement by a Popcorn Time organization member saying that they use the Butter Project's NW.js build script[2], only that a custom version is used[3]. One might suppose that PT's NW.js is built from BP's script, but I have not been able to confirm this via checksums, seeing as BP's CI site[4] is down[5], and NW.js is a very heavy build. Until the CI site comes back online and we are able to confirm checksum matches, the get.popcorntime.sh NW.js package should be considered dangerous. A negative clamscan alone should not be deemed proof that the various binaries are not malicious. As for forks/alternatives, its worth noting that Popcorn Time built with upstream NW.js[6] succeeds and runs, although the internal media player will not be able to playback a lot of media due to lack of codecs, so you'd have to use an external media player in many cases. In lieu of the inconvenience, this seems to be the safest option for now. [1]: https://github.com/popcorn-official/popcorn-desktop/blob/development/gulpfi… [2]: https://github.com/butterproject/nwjs-build [3]: https://github.com/popcorn-official/popcorn-desktop/issues/624#issuecomment… [4]: https://github.com/butterproject/butter-desktop/issues/647#issuecomment-303… [5]: http://builds.butterproject.org/nw/ [6]: https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=popcorntime-git#n32 On 07/21/2018 09:53 AM, Giovanni Santini (ItachiSan) wrote: > I would like to point out the following facts: > The package I do provide is built from source, based on the code hosted here: https://github.com/popcorn-official/popcorn-desktop (https://link.getmailspring.com/link/1532179678.local-251a76dc-d25e-v1.3.0-f…) > You can report found spyware there (can you prove me is there any? A clamscan?) > On my side, I do have no malware: > $ clamscan /mnt/build/archlinux/chroots/bauerbill/popcorntime/popcorntime-0.3.10-8-x86_64.pkg.tar.xz > /mnt/build/archlinux/chroots/bauerbill/popcorntime/popcorntime-0.3.10-7-x86_64.pkg.tar.xz: OK > I could approve on redistributed binary builds, but this is not the case, as users build their package theirselves. > > The sources you provide are by far more suspicious, as the website you point to redirect to a Git repository which has as homepage an no-existing one. > > The claims provided in the link are quite general; there is no actual proof and the link provided by the 'spyware team', which is: > https://blog.popcorntime.sh/popcorn-time-safety-and-ransomware/ (https://link.getmailspring.com/link/1532179678.local-251a76dc-d25e-v1.3.0-f…) > provides by far better description and information. > To finish up, deleting the package is something I wouldn't like to do; I would be glad to switch to another fork, if you can provide me a good one. > > Giovanni SantiniComputer scientist and geek > giovannisantini93(a)yahoo.it (https://link.getmailspring.com/link/1532179678.local-251a76dc-d25e-v1.3.0-f…) > https://giovannisantini.tk (https://link.getmailspring.com/link/1532179678.local-251a76dc-d25e-v1.3.0-f…) > > On lug 17 2018, at 8:18 am, notify(a)aur.archlinux.org wrote: >> flacks [1] filed a deletion request for popcorntime [2]: >> Package reportedly distributes viruses/spyware https://www.popcorn- >> time.is/official-statement.html >> >> [1] https://aur.archlinux.org/account/flacks/ >> [2] https://aur.archlinux.org/pkgbase/popcorntime/ >> >

7 years, 2 months

[aur-requests] [PRQ#32348] Deletion Request for ninvaders

by notify＠aur.archlinux.org

Demax12 [1] filed a deletion request for ninvaders [2]: gcc -Wl,-O1,--sort-common,--as-needed,-z,relro,-z,now -onInvaders globals.o view.o aliens.o ufo.o player.o nInvaders.o -lncurses /usr/bin/ld: ufo.o:(.bss+0x6d0): multiple definition of `aliens'; aliens.o:(.bss+0x6d0): first defined here /usr/bin/ld: ufo.o:(.bss+0x0): multiple definition of `skill_level'; aliens.o:(.bss+0x0): first defined here /usr/bin/ld: ufo.o:(.bss+0x4): multiple definition of `level'; aliens.o:(.bss+0x4): first defined here /usr/bin/ld: ufo.o:(.bss+0x8): multiple definition of `weite'; aliens.o:(.bss+0x8): first defined here /usr/bin/ld: ufo.o:(.bss+0x20): multiple definition of `bunker'; aliens.o:(.bss+0x20): first defined here /usr/bin/ld: ufo.o:(.bss+0x540): multiple definition of `alienBlock'; aliens.o:(.bss+0x540): first defined here /usr/bin/ld: ufo.o:(.bss+0x608): multiple definition of `alienshotnum'; aliens.o:(.bss+0x608): first defined here /usr/bin/ld: ufo.o:(.bss+0x620): multiple definition of `alienshoty'; aliens.o:(.bss+0x620): first defined here /usr/bin/ld: ufo.o:(.bss+0x660): multiple definition of `alienshotx'; aliens.o:(.bss+0x660): first defined here /usr/bin/ld: ufo.o:(.bss+0x6a0): multiple definition of `lowest_ship'; aliens.o:(.bss+0x6a0): first defined here /usr/bin/ld: ufo.o:(.bss+0x6c8): multiple definition of `shipnum'; aliens.o:(.bss+0x6c8): first defined here /usr/bin/ld: player.o:(.bss+0x6f0): multiple definition of `aliens'; aliens.o:(.bss+0x6d0): first defined here /usr/bin/ld: player.o:(.bss+0x18): multiple definition of `skill_level'; aliens.o:(.bss+0x0): first defined here /usr/bin/ld: player.o:(.bss+0x6e8): multiple definition of `shipnum'; aliens.o:(.bss+0x6c8): first defined here /usr/bin/ld: player.o:(.bss+0x1c): multiple definition of `level'; aliens.o:(.bss+0x4): first defined here /usr/bin/ld: player.o:(.bss+0x20): multiple definition of `weite'; aliens.o:(.bss+0x8): first defined here /usr/bin/ld: player.o:(.bss+0x28): multiple definition of `ufo'; ufo.o:(.bss+0x6e8): first defined here /usr/bin/ld: player.o:(.bss+0x40): multiple definition of `bunker'; aliens.o:(.bss+0x20): first defined here /usr/bin/ld: player.o:(.bss+0x560): multiple definition of `alienBlock'; aliens.o:(.bss+0x540): first defined here /usr/bin/ld: player.o:(.bss+0x628): multiple definition of `alienshotnum'; aliens.o:(.bss+0x608): first defined here /usr/bin/ld: player.o:(.bss+0x640): multiple definition of `alienshoty'; aliens.o:(.bss+0x620): first defined here /usr/bin/ld: player.o:(.bss+0x680): multiple definition of `alienshotx'; aliens.o:(.bss+0x660): first defined here /usr/bin/ld: player.o:(.bss+0x6c0): multiple definition of `lowest_ship'; aliens.o:(.bss+0x6a0): first defined here /usr/bin/ld: nInvaders.o:(.bss+0x6f0): multiple definition of `weite'; aliens.o:(.bss+0x8): first defined here /usr/bin/ld: nInvaders.o:(.bss+0x6ec): multiple definition of `level'; aliens.o:(.bss+0x4): first defined here /usr/bin/ld: nInvaders.o:(.bss+0x6e8): multiple definition of `skill_level'; aliens.o:(.bss+0x0): first defined here /usr/bin/ld: nInvaders.o:(.bss+0x6c8): multiple definition of `shipnum'; aliens.o:(.bss+0x6c8): first defined here /usr/bin/ld: nInvaders.o:(.bss+0x18): multiple definition of `ufo'; ufo.o:(.bss+0x6e8): first defined here /usr/bin/ld: nInvaders.o:(.bss+0x20): multiple definition of `bunker'; aliens.o:(.bss+0x20): first defined here /usr/bin/ld: nInvaders.o:(.bss+0x540): multiple definition of `alienBlock'; aliens.o:(.bss+0x540): first defined here /usr/bin/ld: nInvaders.o:(.bss+0x608): multiple definition of `alienshotnum'; aliens.o:(.bss+0x608): first defined here /usr/bin/ld: nInvaders.o:(.bss+0x620): multiple definition of `alienshoty'; aliens.o:(.bss+0x620): first defined here /usr/bin/ld: nInvaders.o:(.bss+0x660): multiple definition of `alienshotx'; aliens.o:(.bss+0x660): first defined here /usr/bin/ld: nInvaders.o:(.bss+0x6a0): multiple definition of `lowest_ship'; aliens.o:(.bss+0x6a0): first defined here /usr/bin/ld: nInvaders.o:(.bss+0x6d0): multiple definition of `aliens'; aliens.o:(.bss+0x6d0): first defined here collect2: error: ld returned 1 exit status make: *** [Makefile:11: nInvaders] Error 1 Any ideas? [1] https://aur.archlinux.org/account/Demax12/ [2] https://aur.archlinux.org/pkgbase/ninvaders/

3 years, 7 months

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

by sL1pKn07 SpinFlo

El vie, 24 nov 2023 a las 12:56, Marcell Meszaros (< marcell.meszaros(a)runbox.eu>) escribió: > >>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/ >> >> no problem, the package can live in my own :), like always greetings

1 year, 9 months

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