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

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/

3 years

[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, 9 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, 4 months

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, 5 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, 6 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/

5 years, 2 months

Re: [aur-requests] [PRQ#15875] Deletion Request for python-semantic_version

by Eli Schwartz

On 9/1/19 10:58 AM, brent s. wrote: > On 9/1/19 10:29 AM, notify(a)aur.archlinux.org wrote: >> sl1pkn07 [1] filed a deletion request for python-semantic_version [2]: >> >> in [community] >> >> [1] https://aur.archlinux.org/account/sl1pkn07/ >> [2] https://aur.archlinux.org/pkgbase/python-semantic_version/ >> > > AUR maintainer for python-semantic_version here - wow, something got > goofed here! I think it was adopted into [community] without it being > removed from AUR. > > My last update[0] was 2017-11-24. The package was added to [community] > on 2017-12-06[1] but I never made a new commit to "re-create" the AUR > pkg or anything (as git history shows)... The [community] package is python-semantic-version. It was moved from the AUR, and the AUR version was deleted at the time: https://aur.archlinux.org/cgit/aur.git/log/PKGBUILD?h=python-semantic-versi… This package was first uploaded half a year after the package with a "-" instead of a "_" was first uploaded, however, the original version (not yours) was simply migrated from AUR 3 to AUR 4 ("Initial import" four days after the great migration began) so I'm not sure how long it existed before that. So your package was just a duplicate since its inception. Sorry. :( > Is that AUR removal process automatic or manual? If it's automatic, does > it warrant an auditing of other possible packages that were missed in > this fashion? It is manual, but you can see the list of duplicates using something like this: $ declare -f aurdupes aurdupes () { comm -12 <(pacman -Sql core extra community multilib| sort) <(curl -s https://aur.archlinux.org/packages.gz | gzip -d | sed 1d | sort ) } Since the package names are different, they don't even register as duplicates and you should be able to push to it just fine (which you *cannot* do for a package in community, as it would be added to the "this is in community" blacklist) -- Eli Schwartz Bug Wrangler and Trusted User

6 years, 3 months

Re: [PRQ#43605] Deletion Request for advanced-rest-client-appimage

by Marcell Meszaros

It turns out that AUR/advanced-rest-client [a] is a binary package made from DEB release, so that should be renamed to have a -bin suffix, and this package is a duplicate of that, just based on AppImage. [a]: https://aur.archlinux.org/packages/advanced-rest-client On 8 August 2023 11:23:03 GMT+02:00, Marcell Meszaros <marcell.meszaros(a)runbox.eu> wrote: >There's already an AUR/advanced-rest-client for this. > >Upstream provides a DEB release, which can be more easily used to strip out the included Electron (Chromium) runtime. > >And these kinds of packages should have the '-bin' name suffix. > >On 5 July 2023 02:57:29 GMT+02:00, notify(a)aur.archlinux.org wrote: >>MarsSeed [1] filed a deletion request for advanced-rest-client- >>appimage [2]: >> >>Please don't upload AppImage binaries of Electron- (Chromium) based >>applications. >> >>These are hugely bloated and go against Arch's Electron application >>guidelines, namely that they should use and depend on one of the >>electron packages carried by Arch repo. >> >>I know that creating good quality packages is hard work, but that >>doesn't mean that it should be okay to spam the AUR with five hundred >>foreign binary packages which duplicate a lots of binary libraries and >>runtimes already existing in the Arch Linux operating system. >> >>This is not Windows, where bloat and duplication is the norm. Please >>learn and adhere to Linux principles. When there is source available, >>use primarily that to build and package an application. Or in case of >>Electron applications, you can choose to use the ASAR files with Arch >>repo's electron runtime, and create a -bin suffixed electron package. >> >>[1] https://aur.archlinux.org/account/MarsSeed/ >>[2] https://aur.archlinux.org/pkgbase/advanced-rest-client-appimage/

2 years, 4 months

Re: [aur-requests] [PRQ#28274] Deletion Request for petalinux-v2020.1

by Amin Vakil

On 9/21/21 20:58, Alex Henrie wrote: > On Tue, Sep 21, 2021 at 12:01 AM Amin Vakil <info(a)aminvakil.com> wrote: >> >> On 9/20/21 20:38, Alex Henrie wrote: >>> On Sat, Sep 18, 2021 at 12:19 AM <notify(a)aur.archlinux.org> wrote: >>>> >>>> aminvakil [1] filed a deletion request for petalinux-v2020.1 [2]: >>>> >>>> https://aur.archlinux.org/packages/petalinux-v2021.1/ is already >>>> present. >>>> >>>> [1] https://aur.archlinux.org/account/aminvakil/ >>>> [2] https://aur.archlinux.org/pkgbase/petalinux-v2020.1/ >>> >>> I'm surprised that petalinux-v2020.1, petalinux-v2020.2, and >>> petalinux-v2020.3 were deleted from the AUR. It would be nice to have >>> the older versions in the AUR because the latest version (2021.1) is >>> not 100% compatible. And the AUR has lots of old versions of other >>> packages like gcc-arm-none-eabi-bin, so why not petalinux? >>> >>> $ yay -Ssq gcc-arm-none-eabi >>> gcc-arm-none-eabi-bin-92 >>> gcc-arm-none-eabi-bin-83 >>> gcc-arm-none-eabi-bin-63 >>> gcc-arm-none-eabi-bin-72 >>> gcc-arm-none-eabi-bin-73 >>> gcc-arm-none-eabi-bin-102 >>> gcc-arm-none-eabi-bin-93 >>> gcc-arm-none-eabi-bin-49 >>> gcc-arm-none-eabi-bin-82 >>> gcc-arm-none-eabi-bin >> >> Thanks for bringing this up, I've submitted deletion requests for all of >> them as well. > > Are you going to delete all the old versions of GCC for x86 too > (gcc34, gcc43, gcc44, gcc45, gcc46, gcc47, gcc48, gcc49, gcc5, gcc53, > gcc6, gcc7, gcc8, gcc9)? And if so, why? gcc10 was even promoted out > of the AUR. > > -Alex > Arch Wiki is very clear about this: https://wiki.archlinux.org/title/AUR_submission_guidelines#Rules_of_submiss… The submitted PKGBUILDs must not build applications already in any of the official binary repositories under any circumstances. Check the official package database for the package. If any version of it exists, do not submit the package. If the official package is out-of-date, flag it as such. If the official package is broken or is lacking a feature, then please file a bug report. "If any version of it exists, do not submit the package." But I think gcc is a specific case which I will not get involved in submitting a deletion request for it, but I have asked about it in #archlinux-aur channel on Libera to see what are others' opinions. - Amin Vakil

4 years, 2 months

[aur-requests] [PRQ#596] Deletion Request for drupal-l10n-af

by notify＠aur.archlinux.org

jamesan [1] filed a deletion request for drupal-l10n-af [2]: I uploaded a series of AUR packages corresponding to various Drupal core localisation .po files. I've managed to collapse all these into a single drupal-l10n split package, but AUR returns an error when I try to upload this split package: "You are not allowed to overwrite the drupal-l10n-af package." even though I'm maintainer for drupal-l10n-af. You can view the split package PKGBUILD at: http://pastebin.com/Q3wAkZQy and the following lists all the distinct localisation packages for which I'm maintainer that I'd like to have removed since the split package will generate them: drupal-l10n-cy drupal-l10n-vi drupal-l10n-ur drupal-l10n-uk drupal-l10n-ug drupal-l10n-tr drupal-l10n-bo drupal-l10n-th drupal-l10n-te drupal-l10n-ta drupal-l10n-sv drupal-l10n-sw drupal-l10n-es drupal-l10n-sl drupal-l10n-sk drupal-l10n-si drupal-l10n-sr drupal-l10n-gd drupal-l10n-ru drupal-l10n-ro drupal-l10n-pa drupal-l10n-pt-pt drupal-l10n-pt-br drupal-l10n-pl drupal-l10n-fa drupal-l10n-or drupal-l10n-oc drupal-l10n-nn drupal-l10n-nb drupal-l10n-se drupal-l10n-ne drupal-l10n-mn drupal-l10n-mr drupal-l10n-ml drupal-l10n-mg drupal-l10n-mk drupal-l10n-xx-lolspeak drupal-l10n-lt drupal-l10n-lv drupal-l10n-lo drupal-l10n-ky drupal-l10n-ku drupal-l10n-ko drupal-l10n-km drupal-l10n-kk drupal-l10n-kn drupal-l10n-jv drupal-l10n-ja drupal-l10n-it drupal-l10n-ga drupal-l10n-id drupal-l10n-is drupal-l10n-hu drupal-l10n-hi drupal-l10n-he drupal-l10n-ht drupal-l10n-gu drupal-l10n-el drupal-l10n-de drupal-l10n-ka drupal-l10n-gl drupal-l10n-fy drupal-l10n-fr drupal-l10n-fi drupal-l10n-fo drupal-l10n-et drupal-l10n-eo drupal-l10n-en-gb drupal-l10n-dz drupal-l10n-nl drupal-l10n-da drupal-l10n-cs drupal-l10n-hr drupal-l10n-zh-hant drupal-l10n-zh-hans drupal-l10n-ca drupal-l10n-my drupal-l10n-bg drupal-l10n-bs drupal-l10n-bn drupal-l10n-be drupal-l10n-eu drupal-l10n-ms drupal-l10n-az drupal-l10n-hy drupal-l10n-ar drupal-l10n-am drupal-l10n-sq drupal-l10n-af drupal-be drupal-eu drupal-ms drupal-az drupal-hy drupal-ar drupal-am drupal-sq drupal-af [1] https://aur.archlinux.org/account/jamesan/ [2] https://aur.archlinux.org/pkgbase/drupal-l10n-af/

11 years, 3 months

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