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

Re: [PRQ#54086] Deletion Request for wxwidgets-light

by Marcell Meszaros

On 22 February 2024 20:58:03 GMT+01:00, notify(a)aur.archlinux.org wrote: >MarsSeed [1] filed a deletion request for wxwidgets-light [2]: > >Unmaintained since 2023-07-31, and currently several point releases >older than repo's wxwidgets (3.2.2.1 vs 3.2.4). > >But this is also apparently unused, as no one flagged it. > >And it's not beneficial to keep. This package is not compatible with >repo's wxwidgets-gtk3. and therefore most downstream dependent builds >cannot use it, e.g. due to its divergent naming of the relevant wx- >config executable. > >But no one complained - again, an evidence of disuse. > >This also cannot be coinstalled e.g. with repo's veracrypt (which I >use). > >It also builds and puts the headless wxbase into wxwidgets-common- >light - another divergence from repo's corresponding package, which >does no such thing. > >Even if configured properly, this build would still break many reverse >dependencies - those that need multimedia capabilities - as it omits >gstreamer support. > >Therefore I don't see any benefit in keeping this. Maybe one person >(submitter) would disagree, but no one else has shown any indication >that they would needs this build. > >Enough to keep repo's wxwidgets (and AUR's wxwidgets-git). > >[1] https://aur.archlinux.org/account/MarsSeed/ >[2] https://aur.archlinux.org/pkgbase/wxwidgets-light/ Even after the update right after my deletion request was submitted (3.2.2.1-5 →3.2.4-2), the gtk3 package is still not compatible with repo's counterpart. And it still cannot be installed together with e.g. repo's veracrypt. Useless to keep this partially broken partial duplicate.

1 year, 8 months

Re: [PRQ#57934] Deletion Request for any-dl

by Marcell Meszaros

On 23 March 2024 14:55:52 GMT+01:00, Oliver Bandel <oliver(a)first.in-berlin.de> wrote: >Quoting Marcell Meszaros <marcell.meszaros(a)runbox.eu> (snt: 2024-03-23 07:23 +0100 CET) (rcv: 2024-03-23 07:23 +0100 CET): >> On 17 March 2024 13:22:23 GMT+01:00, notify(a)aur.archlinux.org wrote: >> >MarsSeed [1] filed a deletion request for any-dl [2]: >> > >> >ocamlnet is not compatible with ocaml5, so this package in turn is not >> >compatible with current Arch Linux. >> > >> >[1] https://aur.archlinux.org/account/MarsSeed/ >> >[2] https://aur.archlinux.org/pkgbase/any-dl/ >> >> >> The last package change is ill-conceived. The build stays broken. >> >> A package cannot depend on both 'ocaml' (v5) and 'ocaml4', as they conflict with each other. Still not useful to keep this dead build. > >This package has problems because of ocamlnet not being available for >ocaml5. > >I asked the author of ocamlnet, if it was planned to update it for OCaml5. >The answer was yes. >So far there is no time plan for that, but next week I may habe more >information. > It was asked from developer of ocamlnet more than one year ago (Fev 2023), and he didn't bother to answer. [a] Also there were work-in-progress were pull request commits submitted, but dev couldn't care less. And the submitting users admitted they are facing some difficulties and had hit a roadblock in making the patch work properly. [a]: https://gitlab.com/gerdstolpmann/lib-ocamlnet3/-/issues/27

1 year, 8 months

Re: [PRQ#49637] Deletion Request for accountable2you-bin

by Ryan McKeown

Thanks for the detailed description! I will go ahead and submit my own delete request. Thanks again! > On 26 Oct 2023, at 12:50, Marcell Meszaros <marcell.meszaros(a)runbox.eu> wrote: > > Hi, thank you for your reply. > >> Sorry for a silly question, but do you know how I accept this request, and/or perform the deletion? > > It's not a silly question. I can answer it for you. :) > > On AUR, regular users, even if they maintain packages, do not have the privileges on the server to delete packages. You would have to be an elevated status user for that (formerly titled 'Trusted User', or 'Developer', but now there are other special titles, such as 'Package Maintainer'). > > But you can submit your own deletion request, mentioning you are the package owner and that this is no longer needed. > > Trusted Users see maintainers's own request as a separate category, so they can and do treat these with priority. > > (Outsiders' requests can queue up for a pretty long time, even for months, when there's thousands of them pending.) > > Also keep ownership of the package until a TU acts upon your request. (If you disown it before that, your request will not be visible in the maintainer's requests category.) > > Keep up the good work. Cheers. :) > > On 26 October 2023 13:05:54 GMT+02:00, Ryan McKeown <ryanmckeown(a)mail4me.com> wrote: >> Sorry for a silly question, but do you know how I accept this request, and/or perform the deletion? I’ve been searching for 15 minutes and can’t find instructions. >> >> >>> On 26 Oct 2023, at 11:26, notify(a)aur.archlinux.org wrote: >>> >>> MarsSeed [1] filed a deletion request for accountable2you-bin [2]: >>> >>> As per maintainer's last comment, this package from 2020 is now >>> unneeded. >>> >>> By brief checking, I was able to find a Snap store release - people >>> can easily install the latest version from there. >>> >>> [1] https://aur.archlinux.org/account/MarsSeed/ >>> [2] https://aur.archlinux.org/pkgbase/accountable2you-bin/ >>

2 years, 1 month

[aur-requests] [PRQ#34619] Deletion Request for gimp-gap

by notify＠aur.archlinux.org

pepebc [1] filed a deletion request for gimp-gap [2]: ranlib: 'libavfilter/libavfilter.a': No hay tal fichero make[3]: *** [libavfilter/../subdir.mak:28: libavfilter/libavfilter.a] Error 1 make[3]: *** Se espera a que terminen otras tareas.... AR libavformat/libavformat.a AR libpostproc/libpostproc.a AR libavcodec/libavcodec.a AR libavfilter/libavfilter.a AR libavformat/libavformat.a AR libavcodec/libavcodec.a AR libpostproc/libpostproc.a AR libswscale/libswscale.a AR libswscale/libswscale.a AR libavutil/libavutil.a AR libavutil/libavutil.a make[3]: *** [libavformat/../subdir.mak:28: libavformat/libavformat.a] Error del bus (core dumped) [Núcleo vaciado a un archivo] make[3]: *** Se borra el archivo 'libavformat/libavformat.a' ranlib: libavcodec/libavcodec.a: error reading h264_intrapred_init.o: file truncated make[3]: *** [libavcodec/../subdir.mak:28: libavcodec/libavcodec.a] Error 1 make[3]: se sale del directorio '/var/tmp/pamac-build-pepe/gimp- gap/src/gimp-gap/extern_libs/ffmpeg' make[2]: *** [Makefile:584: /var/tmp/pamac-build-pepe/gimp- gap/src/gimp-gap/extern_libs/ffmpeg/libavformat/libavformat.a] Error 2 make[2]: *** Se espera a que terminen otras tareas.... make[3]: se sale del directorio '/var/tmp/pamac-build-pepe/gimp- gap/src/gimp-gap/extern_libs/ffmpeg' make[3]: se sale del directorio '/var/tmp/pamac-build-pepe/gimp- gap/src/gimp-gap/extern_libs/ffmpeg' make[2]: *** [Makefile:594: /var/tmp/pamac-build-pepe/gimp- gap/src/gimp-gap/extern_libs/ffmpeg/libavutil/libavutil.a] Error 2 make[2]: se sale del directorio '/var/tmp/pamac-build-pepe/gimp- gap/src/gimp-gap/extern_libs' make[1]: *** [Makefile:479: all-recursive] Error 1 make[1]: se sale del directorio '/var/tmp/pamac-build-pepe/gimp- gap/src/gimp-gap' make: *** [Makefile:420: all] Error 2 ==> ERROR: Se produjo un fallo en package(). Cancelando... [1] https://aur.archlinux.org/account/pepebc/ [2] https://aur.archlinux.org/pkgbase/gimp-gap/

3 years, 7 months

Re: [PRQ#58056] Merge Request for python-pixcat-an-prata Rejected

by Marcell Meszaros

On 23 March 2024 12:46:55 GMT+01:00, notify(a)aur.archlinux.org wrote: >Request #58056 has been Rejected by Foxboron [1]: > >submit a deletion request. > >[1] https://aur.archlinux.org/account/Foxboron/ Hi @Foxboron, Please kindly help me, I am at a loss here. I would like to understand your view on what the actual, practical difference would have been in this particular case between a merge and a delete. Maintainer originally create this fork package, but it is a Git VCS build, so I advised them to change the pkgname and resubmit with a '-git' suffix. Which they were kind enough to do. So in real-world human logic, this is a rename. AUR guidelines say that a merge type request is used for such cases. Would there have been any harm if you accepted the merge request? (As far as I know, an AUR merge, once accepted by PM, is an automated process, with no manual labor involved, so there is no additional work burden. Am I wrong in this assumption? Also, again AFAIK, a merge does not create any constraint on the source pkgbase name, it does not blacklist it, does not prevent anyone in recreating that pkgbase on AUR once it's gone / hidden.) So far you are the only AUR PM / Arch Developer among everyone I've encountered during the last 3 years on AUR who did not accept this kind of merge request. Please, please kindly help me understand your line of reasoning, to better able to adhere to your guidelines and best practices. Thank you in advance! Cheers, Marcell (MarsSeed)

1 year, 8 months

Re: [PRQ#46561] Deletion Request for librsvg-og

by Marcell Meszaros

Former maintainer disowned it in agreement. (And also sent two other deletion requests: PRQ#47737, PRQ#49587). On 15 September 2023 11:29:13 GMT+02:00, Marcell Meszaros <marcell.meszaros(a)runbox.eu> wrote: >The AUR package was updated, but is still a duplicate of the ArchLinuxARM.org repo package and is not needed on AUR. > >On 22 August 2023 08:35:30 GMT+02:00, Marcell Meszaros <marcell.meszaros(a)runbox.eu> wrote: >>Minor correction: the i586 microarchitecture is not the same as the one referred to as 'pentium4' by compilers like the gcc. >> >>But this error on my part has no bearing on the request to delete this package whose newer equivalent is available in ArchLinux32 repos. >> >>On 22 August 2023 08:15:00 GMT+02:00, notify(a)aur.archlinux.org wrote: >>>MarsSeed [1] filed a deletion request for librsvg-og [2]: >>> >>>This is an ArchLinux32 package from 2021-05: >>> >>>arch=(i486 i686 pentium4) >>> >>>Not needed: same owner maintains this package for those architectures >>>directly in ArchLinux32.org repos, where it is already on a newer git >>>version (last updated on 2022-07-23). >>> >>>Also in ArchLinux32, there is a working rust compiler for i686 and >>>pentium4 (i586) platforms, so the repo for those also carries the >>>current main librsvg 2.56.x which needs rustc. >>> >>>As stated by librsvg-og fork repo (last updated in 2020): >>>"The goal of this fork is to keep the C implementation alive and up to >>>date, to help provide librsvg for platforms without a working rust >>>compiler." [a] >>> >>>[a]: https://github.com/oaken-source/librsvg-og >>> >>>[1] https://aur.archlinux.org/account/MarsSeed/ >>>[2] https://aur.archlinux.org/pkgbase/librsvg-og/

2 years, 1 month

Re: [aur-requests] [PRQ#11833] Deletion Request for linux-amd-staging-git

by Yurii Kolesnykov

Is it possible to read and save info about desired branch/repo from some config, e.g. ~/.config/linux-amd-git-branch? ср, 11 лип. 2018, 13:55 користувач Yurii Kolesnykov <yurikoles(a)gmail.com> пише: > Yes, it's mostly the same. Thank you for mentioning other branches. I hope > to create different packages for this branches. > Now I just manually switch the branch to most recent one, e.g. 4.19-wip -> > 4.19 -> drm-next in second package. > > Now I think to create linux-amd-staging-wip, that points to $ver-wip and > point this package to $ver. And point second package to drm-next. There is > also drm-next from drm subsystem maintainer, which accumulates patches for > all drivers in one repo. > > Because of that I think that maybe it will be better to create an > interective AIO package to make it easy to maintain? > > ср, 11 лип. 2018, 06:07 користувач Eli Schwartz <eschwartz(a)archlinux.org> > пише: > >> On 06/16/2018 10:29 PM, notify--- via aur-requests wrote: >> > yurikoles [1] filed a deletion request for linux-amd-staging-git [2]: >> > >> > Not updating upstream. >> > >> > [1] https://aur.archlinux.org/account/yurikoles/ >> > [2] https://aur.archlinux.org/pkgbase/linux-amd-staging-git/ >> >> Is this the same as >> https://cgit.freedesktop.org/~agd5f/linux/log/?h=amd-staging-drm-next >> >> Because there's definitely other branches besides the one this PKGBUILD >> currently uses, which do get updates. >> >> >> -- >> Eli Schwartz >> Bug Wrangler and Trusted User >> >>

7 years, 5 months

Re: [aur-requests] [PRQ#35618] Deletion Request for python2-pytest-expect

by Marcell Meszaros

# Note: resending to aur-requests as previously I was not subscribed. # Note2: @Zigsaz: you haven't actually responded to my question about this package, so please do so. No, this is not unneeded. I've just restored this to AUR, to allow using check() in the PKGBUILD of python2-html5lib, itself recently restored by me. I am working in concert with @hexd and a few other AUR volunteers to temporarily restore a select few core Python 2 packages that help in bring back to life some legacy apps which haven't yet migrated to Python 3 or have no alternatives yet, and which are still useful to people in the interim. Testing related modules are extremely useful to keep as long as there are Python 2 based PKGBUILDs in AUR, so these are the very last that should be deleted. It was testing done in the check() function that uncovered some utf-8 related configuration errors or source errors with some packages (e.g. discrepancy between PyPI and GitHub tarball, where one was missing important files). So instead of forcing AUR maintainers to disable check(), I am trying to help them as well as myself to (re)enable testing, to see if everything is all right with the built package. Is this answer acceptable for you as to the raison d'être of this AUR package? :) Cheers, Marcell On 21 June 2022 22:06:28 GMT+02:00, notify(a)aur.archlinux.org wrote: >Zigsaz [1] filed a deletion request for python2-pytest-expect [2]: > >Python 2 is EOL. This package looks to be unneeded. > >[1] https://aur.archlinux.org/account/Zigsaz/ >[2] https://aur.archlinux.org/pkgbase/python2-pytest-expect/

3 years, 5 months

Re: [PRQ#59772] Deletion Request for widevine

by Dan Johansen

Den 29.04.2024 kl. 20.09 skrev notify(a)aur.archlinux.org: > MarsSeed [1] filed a deletion request for widevine [2]: > > Re-filing a deletion request due to not receiving any response [a] as > to the rationale to keep this duplicate of the properly packaged > AUR/chromium-widevine. [b] > > The AUR/widevine package was created with the sole purpose of offering > ARM support, and x86_64 was only added to mask its intent. > > Also I believe it is not okay to create duplicates on AUR when there > is already a maintained package which works with Arch Linux. > AUR/widevine's maintainer should collaborate with that of > AUR/chromium-widevine and suggest enhancements there, if there are > relevant ones. > > In addition, AUR/widevine has other problems. As its used release > deliverables for different platforms diverge in their version: > > - AUR/widevine pkgver: 4.10.2252.0 > - x86_64: upstream - 4.10.2710.0 (released 2024-02-12) > - aarch64/armhf: RaspberryPi.org/Debian - 4.10.2252.0 (released > 2023-10-05) > - (AUR/chromium-widevine pkgver: 4.10.2710.0, released 2024-02-12) > > As the RPI distro does not carry the latest version, it seems not to > be viable to carry binaries for different architectures in the same > PKGBUILD. > > Which leads me to conclude that a PKGBUILD for the RPI releases should > be submitted to the ArchLinuxARM.org repositories only. The problem with that is that widevine is not open source and not distributable, so the package is not allowed to be in any repository, thus an AUR package is required. > > That would actually benefit users more, while not cluttering the AUR. > > [a]: > https://lists.archlinux.org/archives/list/aur- > requests@lists.archlinux.org/thread/IAHLWRGRNHHUZRU2LRMX5UTZUNGJBAUO/#5CT5XAQZNIHQYPSRZ6CMDTY67XE3QOU2 > [b]: > https://aur.archlinux.org/packages/chromium-widevine > > [1] https://aur.archlinux.org/account/MarsSeed/ > [2] https://aur.archlinux.org/pkgbase/widevine/ -- Med venlig hilsen Dan Johansen

1 year, 7 months

Re: [aur-requests] [PRQ#20485] Deletion Request for openscad-mcad-dev-git

by Dario Pellegrini

Ok, I pushed a new version of the PKGBUILD. Il giorno ven 24 lug 2020 alle ore 14:18 Magnus Boman < magunasu.b97(a)gmail.com> ha scritto: > You can set > `source=(git+https://github.com/openscad/MCAD.git#branch=dev)` > <https://github.com/openscad/MCAD.git#branch=dev)> > instead, which is the recommended way of doing this. > Also I see your build() function is empty so you might as well remove > it, cleaner output that way. And maybe combine all those rm's? I'm just > nitpicking at this point though ;p > > Please see > https://wiki.archlinux.org/index.php/VCS_package_guidelines#VCS_sources > btw, specifically the #fragment bit. > > Without doing this your pkgver() and other things will be printing the > wrong thing. Unless you're actually pulling files from both branches, in > which case I think you should be including both in the source array. > > Thank you for reaching out and seeking advice rather than ignoring all > advice given. Cheers, katt. > > On 24/07/2020 09:40, Dario Pellegrini wrote: > > Uh, how do you switch to a particular upstream branch from which to pick > > some files without git checkout? > > > > On Fri, 24 Jul 2020, 00:37 , <notify(a)aur.archlinux.org > > <mailto:notify@aur.archlinux.org>> wrote: > > > > katt [1] filed a deletion request for openscad-mcad-dev-git [2]: > > > > git checkout in package() > > > > [1] https://aur.archlinux.org/account/katt/ > > [2] https://aur.archlinux.org/pkgbase/openscad-mcad-dev-git/ > > >

5 years, 4 months

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