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

[aur-requests] [PRQ#34750] Orphan Request for firefox-beta-i18n

by notify＠aur.archlinux.org

MarsSeed [1] filed an orphan request for firefox-beta-i18n [2]: Does not work; dependency firefox-beta got deleted from AUR. Maintainer @bittin never responds to any queries. Package imperfectly duplicates the build of Arch/community/firefox-developer-edition-i18n. But anyway it's superfluous because there is no more 'firefox-beta' package. (Also before deletion, firefox-beta package was not updated by @bittin since Nov 2021 despite multiple requests and messages.) This package has also been deleted cca. last month, but @bittin pushed it again - without its mandatory 'firefox-beta' dependency. This package is only spam on AUR. [1] https://aur.archlinux.org/account/MarsSeed/ [2] https://aur.archlinux.org/pkgbase/firefox-beta-i18n/

3 years, 3 months

Re: [PRQ#47128] Deletion Request for lib32-smbclient

by Marcell Meszaros

I think it is totally safe to delete this, because no user mentioned any use case where they would need 32-bit smbclient using wine on a 64-bit system. And no AUR wine packages are configured to build lib32 support for Samba. Therefore none of the existing wine builds would use lib32-smbclient even if they are coinstalled. WINE has many legacy features, but if no one demands those, there is no point in providing them and maintaining unused packages. There are many other builds on AUR that really need expert maintainer attention. It is not worth the effort to waste it on something no application ever needs. @sl1pkn07, you might be preferring to be a completionist or to err on the theoretical extreme safe side when it comes to lib32 packages, but even you have not provided any existing use case for this one. On 10 September 2023 01:23:52 GMT+02:00, Fabian Maurer <dark.shadow4(a)web.de> wrote: >On Samstag, 9. September 2023 21:00:49 CEST you wrote: >> El sáb, 9 sept 2023 a las 14:50, <notify(a)aur.archlinux.org> escribió: >> > DarkShadow44 [1] filed a deletion request for lib32-smbclient [2]: >> > >> > This is not needed anymore, the last packages that had this as >> > dependency (lib32-gnome-vfs) was deleted a while ago. >> > >> > [1] https://aur.archlinux.org/account/DarkShadow44/ >> > [2] https://aur.archlinux.org/pkgbase/lib32-smbclient/ >> >> needs for wine > >You're right, wine configure mentions missing support when that 32bit samba is >missing. Not sure what exactly it does though, it's not even optional for wine >and the wine tests pass even without the libs installed... > >FWIW, once the thunks work well enough, 32bit dependencies are going to be >obsolete anyways. Should we keep it around until then? > >Regards, >Fabian Maurer > >

2 years

Re: [PRQ#37842] Deletion Request for polymc-bin

by Numeral

It looks like upstream is currently in the process of establishing a fork with new branding of polymc. Regarding what happened, it appears that Lenny was not hacked. They were able to prove it using a gpg signed message with a pre-existing gpg key. However, they removed permissions from all other maintainers on Github as well as the community discord. I would still be careful with accepting packages from Lenny since Lenny's actions against the PolyMC community are most definitely malicious, regardless of whether they were hacked. It looks like Scrumpex is the main person leading the establishment of a new fork. They have been CC'd. I really appreciate how quickly I got a response from the AUR team. Please note, I am not a maintainer or developer from upstream. I am just one of their users. -- Numeral ------- Original Message ------- On Monday, October 17th, 2022 at 3:19 PM, Morten Linderud <foxboron(a)archlinux.org> wrote: > On Mon, Oct 17, 2022 at 07:38:01PM +0000, notify(a)aur.archlinux.org wrote: > > > thenumeralone [1] filed a deletion request for polymc-bin [2]: > > > > Hi! There was a hostile takeover upstream by LennyLennington. It is > > not known if their account was hacked. Until upstream resolves this I > > would recommend removing LennyLennington as maintainer and replacing > > them with Scrumplex in order to prevent malware from being introduced. > > Deletion would also be fine. > > > > I would recommend verifying my story by emailing Scrumplex. > > > > I am submitting an equivalent request for polymc-git. > > > > [1] https://aur.archlinux.org/account/thenumeralone/ > > [2] https://aur.archlinux.org/pkgbase/polymc-bin/ > > > This got a bit messy. Can't force orphan any packages so I have accidentally > deleted one. Scrumplex is back as co-maintainer while I consider the other > options. > > The Lenny guy has been banned until we know what is happening. > > > Feel free to say if anything else needs to be done. > > -- > Morten Linderud > PGP: 9C02FF419FECBE16

2 years, 11 months

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

by Marcell Meszaros

Yes, I saw you revoked it. Thanks! :) On 29 June 2023 23:15:23 GMT+02:00, Mark Wagie <mark.wagie(a)proton.me> wrote: > >Yes, you're right. Notice I rejected my deletion request before you replied. ;) > > > >Sent with Proton Mail secure email. > >------- Original Message ------- >On Thursday, June 29th, 2023 at 2:08 PM, Marcell Meszaros <marcell.meszaros(a)runbox.eu> wrote: > > >> @yochananmarqos, this deletion request is based on mistaken assumptions. >> >> TLDR: It is not hard to create a modified package based on xdg-utils source by deleting one script, 'xdg-open', and making the package depend on another package that either has an alternative implementation of that script with the same name, or a symlink with the same name pointing to another shell script that is interface-compatible with the original 'xdg-open'. >> >> For more details, please kindly read the discussion that took place on 2023-06-27 on the following page: >> >> https://aur.archlinux.org/packages/xdg-utils-no-open >> (archived: https://archive.ph/zk7uR) >> >> Ref also owner's merge request [PRQ#43206] from xdg-utils-no-open to xdg-utils-custom-open. >> >> Please kindly revoke this ill-conceived deletion request and let @jfrankenau implement a viable, Arch-repo-compatible drop-in customization solution for xdg-utils that is mostly similar to what Arch's 'xdg-desktop-portal' package already utilizes: >> >> https://archlinux.org/packages/extra/x86_64/xdg-desktop-portal/ >> >> Thank you for your kind cooperation. :) >> >> Marcell (MarsSeed) >> >> On 29 June 2023 21:23:34 GMT+02:00, notify(a)aur.archlinux.org wrote: >> >> > yochananmarqos [1] filed a deletion request for xdg-utils-custom-open >> > [2]: >> > >> > Duplicate of xdg-utils. Custom? How? Open? As opposed to closed? >> > There's also a non-existent dependency on xdg-open-impl--whatever that >> > is. >> > >> > "The submitted PKGBUILDs must not build applications already in any of >> > the official binary repositories under any circumstances. Check the >> > official package database for the package. If any version of it >> > exists, do not submit the package. If the official package is out-of- >> > date, flag it as such. If the official package is broken or is lacking >> > a feature, then please file a bug report." >> > >> > -- >> > https://wiki.archlinux.org/title/AUR_submission_guidelines#Rules_of_submiss… >> > >> > [1] https://aur.archlinux.org/account/yochananmarqos/ >> > [2] https://aur.archlinux.org/pkgbase/xdg-utils-custom-open/

2 years, 2 months

Re: [PRQ#38987] Deletion Request for drumstick-svn

by Pedro Lopez-Cabanillas

> plcl [1] filed a deletion request for drumstick-svn [2]: > > This package is orphan, and a perfectly fine package is available in > the Community repository. > > [1] https://aur.archlinux.org/account/plcl/ > [2] https://aur.archlinux.org/pkgbase/drumstick-svn/ Hi, I'm the upstream author of the drumstick libraries. I'm also the upstream author of vmpk[3], dmidiplayer[4], kmetronome[5] and kmidimon[6]. I've filed this deletion request because this unmaintained package has caused troubles to several users of my other applications depending on drumstick. In particular, there was an AUR package for kmidimon that was crashing at runtime. It is solved now because kmidimon has been moved to Arch Community, but there are still AUR packages for vmpk, dmidiplayer and kmetronome that may suffer similar problems. * My programs can be compiled with Qt5 or Qt6 right now. The preferred Qt version can be specified with the cmake option USE_QT=5/6 at configuration time. In Arch you may have both Qt versions installed, and in that case if you build drumstick with one version and the other programs with another version, troubles will arise. * There is a drumstick[7] package at Arch Community, depending on Qt6, well maintained including the new sonivox dependency. This drumstick-svn package is not. * I'm planning to move the source repository to Git soon. The SVN repository will remain read-only and frozen in time forever, like this package. * I always follow the "release early, release often" philosophy. In fact, there is no difference between the latest drumstick v2.7.2 and SVN revision r684. * I would understand the existence of different AUR packages if they provide different features/variations. For instance, there could be an AUR package providing drumstick-qt5 along with vmpk-qt5, dmidiplayer-qt5 and kmetronome-qt5 with explicit/strong dependencies to qt5 and drumstick-qt5. But the current situation is calling for troubles with little/no gain. * And finally, please get in touch with upstream authors. There was little dialog between AUR users/maintainers and this developer in the past. Please file bugs/requests and report crashes with stack traces. Thanks! Regards, Pedro [3] https://aur.archlinux.org/packages/vmpk-svn [4] https://aur.archlinux.org/packages/dmidiplayer [5] https://aur.archlinux.org/packages/kmetronome [6] https://archlinux.org/packages/community/x86_64/kmidimon/ [7] https://archlinux.org/packages/community/x86_64/drumstick/

2 years, 9 months

[PRQ#55074] Deletion Request for ruby-lint

by notify＠aur.archlinux.org

MarsSeed [1] filed a deletion request for ruby-lint [2]: EOL Ruby 2.x linter from 2016. Not compatible with current ruby 3+ and the corresponding ruby-parser 3+: > $ ruby-lint > /usr/lib/ruby/3.0.0/rubygems/specification.rb:1453:in > `rescue in block in activate_dependencies': Could not find > 'parser' (~> 2.2) among 88 total gem(s) > (Gem::MissingSpecError) > Checked in > 'GEM_PATH=/home/user/.local/share/gem/ruby/3.0.0:/usr/lib/ > ruby/gems/3.0.0' at: > /usr/lib/ruby/gems/3.0.0/specifications/ruby-lint-2.3.1. > gemspec, execute `gem env` for more information > from > /usr/lib/ruby/3.0.0/rubygems/specification.rb:1450:in `block > in activate_dependencies' > from > /usr/lib/ruby/3.0.0/rubygems/specification.rb:1439:in `each' > from > /usr/lib/ruby/3.0.0/rubygems/specification.rb:1439:in > `activate_dependencies' > from > /usr/lib/ruby/3.0.0/rubygems/specification.rb:1421:in > `activate' > from /usr/lib/ruby/3.0.0/rubygems.rb:286:in > `block in activate_bin_path' > from /usr/lib/ruby/3.0.0/rubygems.rb:285:in > `synchronize' > from /usr/lib/ruby/3.0.0/rubygems.rb:285:in > `activate_bin_path' > from /usr/bin/ruby-lint:25:in `<main>' > /usr/lib/ruby/3.0.0/rubygems/dependency.rb:313:in > `to_specs': Could not find 'parser' (~> 2.2) - did find: > [parser-3.1.3.0] (Gem::MissingSpecVersionError) > Checked in > 'GEM_PATH=/home/user/.local/share/gem/ruby/3.0.0:/usr/lib/ > ruby/gems/3.0.0' , execute `gem env` for more information > from > /usr/lib/ruby/3.0.0/rubygems/specification.rb:1451:in `block > in activate_dependencies' > from > /usr/lib/ruby/3.0.0/rubygems/specification.rb:1439:in `each' > from > /usr/lib/ruby/3.0.0/rubygems/specification.rb:1439:in > `activate_dependencies' > from > /usr/lib/ruby/3.0.0/rubygems/specification.rb:1421:in > `activate' > from /usr/lib/ruby/3.0.0/rubygems.rb:286:in > `block in activate_bin_path' > from /usr/lib/ruby/3.0.0/rubygems.rb:285:in > `synchronize' > from /usr/lib/ruby/3.0.0/rubygems.rb:285:in > `activate_bin_path' > from /usr/bin/ruby-lint:25:in `<main>' [1] https://aur.archlinux.org/account/MarsSeed/ [2] https://aur.archlinux.org/pkgbase/ruby-lint/

1 year, 6 months

[PRQ#62155] Deletion Request for azure-cli-bin

by notify＠aur.archlinux.org

MarsSeed [1] filed a deletion request for azure-cli-bin [2]: The azure-cli package has been added to Arch/extra repo in March 2024. I don't think it is very useful to keep this old-distro-targeting (Debian Bookworm), Python 3.11 based upstream build, which btw contains its own Python 3.11 runtimes (python3, pip, pbr, etc.) and binary+Python-module ecosystem in the install, with up to two hundred of its own Python modules. Also this PKGBUILD strips the upstream binaries, therefore the installed package is useless for crash reporting purposes. Upstream's binaries are also less secure than the Arch build, as the ELF files here lack full RELRO and PIE. The AUR package is also configured improperly: - It defines 'python' as its dependency, but it is not true, as I mentioned, this package installs its own /opt/az/bin/python3 symlink to the /opt/az/bin/python3.11 runtime. - Man viewing doesn't work in the AUR package, as the relevant files are installed inside /opt/az and not to their proper places inside '/usr/share'. - Bash completions get installed in the wrong place, inside /etc/bash_completon.d, instead of the expected '/usr/share/bash- completion/completions'. - It does not install the mandatory MIT license file. I am observing that there is a discrepancy in AUR PM decisionmaking regarding keeping or deleting upstream's binary releases from AUR when a source-based build gets added to the official Arch repos. I typically saw Arch Developers like @arojas, and Package Maintainers like @Antiz delete '-bin' counterparts of Arch repo packages from AUR, citing the reason that the in such cases the '-bin' builds do not add any meaningful benefit to users. I think this specific PKGBUILD has even stronger than typical reasons to be dropped from AUR. [1] https://aur.archlinux.org/account/MarsSeed/ [2] https://aur.archlinux.org/pkgbase/azure-cli-bin/

1 year, 1 month

Re: [PRQ#42352] Deletion Request for prusa-slicer-bin

by Marcell Meszaros

@Orax, You can create a package for release candidate (rc) versions if you would like to. Suggested names e.g.: prusa-slicer-rc-bin -or- prusa-slicer-preview-bin In package description, you can add "(preview version)" or "(release candidate)". It could provide either the latest stable or the latest preview / release candidate, whichever is newer. That package would not be considered a duplicate variant of the repo package. It is valid and allowed on AUR to have devel/alpha/beta/preview/rc whatever packages. On 20 June 2023 09:44:46 GMT+02:00, JP Roemer <jp(a)roemer.im> wrote: >As the current maintainer of this aur package, I would like to note that prusa-slicer-bin do provide some value over https://archlinux.org/packages/extra/x86_64/prusa-slicer/ as it includes pre-release binaries (as specified in its description). > >Those pre-release / release candidate version do use the same configuration folder as final release one (which alpha & beta version do not) and are considered mostly safe to use with just some cutting edge new features available. > >The value of this package is to be able to install and tests pre-release versions which are not shipped as part of extra/prusa-slicer. > >If this is something that is not welcomed in the aur, I understand and this package can be removed. I just felt like the specific way configuration are handled by this package warranted the existence of a package that included stable and release-candidate versions. > >Best, >Orax > >On Mon, 19 Jun 2023, at 12:20, notify(a)aur.archlinux.org wrote: >> MarsSeed [1] filed a deletion request for prusa-slicer-bin [2]: >> >> Not needed anymore, same is in [extra]: >> >> https://archlinux.org/packages/extra/x86_64/prusa-slicer/ >> >> [1] https://aur.archlinux.org/account/MarsSeed/ >> [2] https://aur.archlinux.org/pkgbase/prusa-slicer-bin/

2 years, 3 months

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

by Marcell Meszaros

> 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

[aur-requests] [PRQ#21563] Deletion Request for gcalendar

by notify＠aur.archlinux.org

porcaror [1] filed a deletion request for gcalendar [2]: Sorry to disturb you. My ggalendar doesn't work anymore. If I try to use gcalendar (I've launched it from the terminal) I have the following error message: Traceback (most recent call last): File "/usr/bin/gcalendar", line 33, in <module> sys.exit(load_entry_point('gcalendar==0.4', 'console_scripts', 'gcalendar')()) File "/usr/bin/gcalendar", line 25, in importlib_load_entry_point return next(matches).load() File "/usr/lib/python3.8/importlib/metadata.py", line 77, in load module = import_module(match.group('module')) File "/usr/lib/python3.8/importlib/__init__.py", line 127, in import_module return _bootstrap._gcd_import(name[level:], package, level) File "<frozen importlib._bootstrap>", line 1014, in _gcd_import File "<frozen importlib._bootstrap>", line 991, in _find_and_load File "<frozen importlib._bootstrap>", line 975, in _find_and_load_unlocked File "<frozen importlib._bootstrap>", line 671, in _load_unlocked File "<frozen importlib._bootstrap_external>", line 783, in exec_module File "<frozen importlib._bootstrap>", line 219, in _call_with_frames_removed File "/usr/lib/python3.8/site-packages/gcalendar/__main__.py", line 32, in <module> from gcalendar.gcalendar import GCalendar File "/usr/lib/python3.8/site-packages/gcalendar/gcalendar.py", line 22, in <module> from googleapiclient import discovery File "/usr/lib/python3.8/site- packages/googleapiclient/discovery.py", line 49, in <module> import google.api_core.client_options File "/usr/lib/python3.8/site-packages/google/api_core/__init__.py", line 20, in <module> from pkg_resources import get_distribution File "/usr/lib/python3.8/site-packages/pkg_resources/__init__.py", line 3239, in <module> def _initialize_master_working_set(): File "/usr/lib/python3.8/site-packages/pkg_resources/__init__.py", line 3222, in _call_aside f(*args, **kwargs) File "/usr/lib/python3.8/site-packages/pkg_resources/__init__.py", line 3251, in _initialize_master_working_set working_set = WorkingSet._build_master() File "/usr/lib/python3.8/site-packages/pkg_resources/__init__.py", line 567, in _build_master ws.require(__requires__) File "/usr/lib/python3.8/site-packages/pkg_resources/__init__.py", line 884, in require needed = self.resolve(parse_requirements(requirements)) File "/usr/lib/python3.8/site-packages/pkg_resources/__init__.py", line 770, in resolve raise DistributionNotFound(req, requirers) pkg_resources.DistributionNotFound: The 'aiohttp<4.0.0dev,>=3.6.2' distribution was not found and is required by google-auth Can you try to help me, please? [1] https://aur.archlinux.org/account/porcaror/ [2] https://aur.archlinux.org/pkgbase/gcalendar/

4 years, 11 months

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