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

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

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

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

3 years, 11 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

Re: [PRQ#71703] Deletion Request for perl-parse-method-signatures

by Marcell Meszaros

On 13 April 2025 23:04:29 GMT+02:00, "Bence Csókás" <bence98(a)sch.bme.hu> wrote: >Hi all! > >On 2025. 04. 07. 9:51, notify wrote: >> MarsSeed [1] filed a deletion request for perl-parse-method-signatures >> [2]: >> >> Unused. EOL since 2017. >> >> Dependency AUR/perl-moosex-traits is EOL since 2015, > > >Don't know where you got this data from, Karen Etheridge has been committing to its repo [3] all the way into July 2019. > > >> and is a badly packaged orphan. >> The latter unnecessarily makedepends on AUR/perl-test-use-ok that is >> EOL since 2012 and is a partial predecessor duplicate of perl-test- >> simple, carried by Arch/core/perl. > > >From what you wrote, it seems all your problems stem from not this package, but `perl-moosex-traits`. So instead of deleting this, why not adopt and fix /that/ package instead? > > >> [1] https://aur.archlinux.org/account/MarsSeed/ >> [2] https://aur.archlinux.org/pkgbase/perl-parse-method-signatures/ > > >[3] https://github.com/moose/MooseX-Traits/commits/master/ > Hi Bence, Could you maybe adopt AUR/perl-moosex-traits and fix its packaging? Otherwise there seem to be no other users who would use that and this library, and these two packages are the only remaining holdovers that are tied to the obsolete, badly packaged AUR/perl-test-use-ok that is EOL as a dist since 2012 and whose later version is carried by Arch/core/perl. I myself do not use any of these packages, that's why I opted not to adopt and correct perl-moosex-traits. Please let me know of your decision on whether you want to keep and fix perl-moosex-traits along with keeping perl-parse-method-signatures, or if you choose not to adopt and adjust the former, in which case we can delete both. Thank you in advance for your answer, Marcell Meszaros / MarsSeed

4 months, 3 weeks

Re: [PRQ#45251] Deletion Request for lib32-sane

by Marcell Meszaros

This library was adopted and updated, but it still does not have other packages that would utilize it. It is still better to delete this, which in turn will allow other unneded and not very actively maintained packages, like lib32-avahi, and several of its lib32 dependencies, to be dropped as well. Savvy users like @sl1pkn07 can install AUR/wine-wow64 if they really want to use their likely 20+ year old bin32 Windows-only scanners through wine. (Scanner support was the one reason cited by @sl1pkn07 to having a need for this package, though he failed to mention any concrete model or driver/software package that would actually benefit from having this pkg installed.) (Around 2004-2006, Microsoft was pushing OEM's to release 64-bit software for their still in-use hardware devices, even those that were sold previously. Consequently, many printers and scanners marketed after 1999-2000 got those support software at least for the bare minimum functionality in 64-bit.) (Also, no wine builds on AUR utilize lib32-sane, so even if someone installed the latter, it would be pointless without recompiling said wine package. But as I mentioned above, wine-wow64 works with both 32-bit and 64-bit Windows software without relying on any 32-bit Linux libraries.) Also, AUR submission guidelines say that packages kept there should be useful to more than a few user. It seems only @sl1pkn07 wants to hang on to this package. On 22 July 2023 17:45:54 GMT+02:00, notify(a)aur.archlinux.org wrote: >MarsSeed [1] filed a deletion request for lib32-sane [2]: > >Orphan package, last updated in 2021-11, no dependents. > >I flagged it OOD 2.5 years ago. > >There are no comments since 2021. > >I think it is better to delete. > >Only wine-stable-ununtu package depended on this from 2021; it has >been deleted since. > >The new wine-wow64 package supports running 32-bit code with only >64-bit Linux libraries. > >[1] https://aur.archlinux.org/account/MarsSeed/ >[2] https://aur.archlinux.org/pkgbase/lib32-sane/

1 year, 11 months

Re: [PRQ#59772] Deletion Request for widevine

by Marcell Meszaros

On 29 April 2024 20:16:54 GMT+02:00, Dan Johansen <danjohansen(a)strits.dk> wrote: > >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/… >> [b]: >> https://aur.archlinux.org/packages/chromium-widevine >> >> [1] https://aur.archlinux.org/account/MarsSeed/ >> [2] https://aur.archlinux.org/pkgbase/widevine/ Hm, in that case, I believe the best course of action would be yet to add the RaspberryPi release tarballs to AUR/chromium-widevine, and its pkgver could reflect the divergent versions in the following way (example): pkgver=4.10.2710.0_rpi4.10.2252.0 Can you maybe request collaboration with AUR/chromium-widevine's maintainer to make the necessary changes in that PKGBUILD? That would be the best in my opinion. Thank you for considering my proposal.

1 year, 4 months

Re: [aur-requests] [PRQ#10670] Deletion Request for dune

by Jakob Gahde

FWIW, great to have this in community. Not so great that a deletion request is the first thing that informs me about this and even less so to have somebody else run off with the work that I put into figuring out how to make this piece of software install correctly and only add a few mostly cosmetic changes for good measure, without even a mention. The process isn’t just './configure; make; make install'; at least for me it took a while to figure everything out, and I’m not exactly a newbie to all the crazy stuff that OCaml people tend to use in their build infrastructure. While I’m at it, I wonder what the purpose is behind not depending on OCaml for a tool aimed at building OCaml software. Secondly, OPAM is run automatically on most invocations of dune to my knowledge, so I believe depending on it is somewhat reasonable. And lastly, the sources of dune happen to mention in plain English that dune can make use of ocamlfind as an optional runtime dependency[1]. So much for my reasoning on the dependencies, I would have been happy to explain this earlier if someone had let me. Forgive me if I’m a little upset, but when the new community package even goes out of it’s way to provide compatibility with the versioning scheme I used on the jbuilder package before it was renamed to dune, I just don’t understand why not even a little heads-up à la “BTW this package is now in community” was possible. Personally, I even left a contributor line saying “Your Name <youremail(a)domain.com>” untouched in one of the packages I adopted, just to let people know that I’m not the only person who ever invested time in that package (namely ocp-build). tl;dr I know that in written form my thoughts tend to come off as being more furious than I actually am, and while I do in fact not like what I believe went on, what I really want you, Bruno, to take away from this is just „Please be a little more communicative in the future” :) Have a nice day Jakob Gahde aka J5lx [1] https://github.com/ocaml/dune/blob/1.0%2Bbeta17/jbuilder.opam#L17-L22 On Mon, 19 Feb 2018, at 15:34, notify(a)aur.archlinux.org wrote: > mis [1] filed a deletion request for dune [2]: > > in [community] > https://www.archlinux.org/packages/community/x86_64/dune/ > > [1] https://aur.archlinux.org/account/mis/ > [2] https://aur.archlinux.org/pkgbase/dune/

7 years, 6 months

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

by sL1pKn07 SpinFlo

El sáb, 23 mar 2024 a las 15:08, Marcell Meszaros (< marcell.meszaros(a)runbox.eu>) escribió: > 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. > Zero logs, user not proves what failed. of course not install with veracrypt because this package not provide any support to gstreamer, and is not the intention. if you want use veracrypt, use [extra] wxwidgets-foo greetings

1 year, 5 months

Re: [aur-requests] [PRQ#8190] Deletion Request for hipchat

by John K. Luebs

I maintain this and know of no general issue with the package, please reject. To the requester: Note in the future that a deletion request is not the appropriate means to report a problem building a package. It is fine to post on the AUR package comments. The current version of this package has been built without issue. Without further information one must speculate, but I would look to see where your aur build tool is trying to build the package, it probably isn't the root filesystem. On Tue, May 30, 2017 at 4:09 AM, <notify(a)aur.archlinux.org> wrote: > milky_milk [1] filed a deletion request for hipchat [2]: > > Building hipchat... > Cloning into 'hipchat'... > remote: Counting objects: 70, done. > remote: Compressing objects: 100% (54/54), done. > remote: Total 70 (delta 25), reused 57 (delta 16) > Unpacking objects: 100% (70/70), done. > ==> Making package: hipchat 4.29.4.1662-2 (Вт май 30 13:03:44 +05 > 2017) > ==> Checking runtime dependencies... > ==> Checking buildtime dependencies... > ==> Retrieving sources... > -> Downloading HipChat4-4.29.4.1662-Linux.deb... > % Total % Received % Xferd Average Speed Time Time Time > Current > Dload Upload Total Spent Left > Speed > 100 98.1M 100 98.1M 0 0 3758k 0 0:00:26 0:00:26 > --:--:-- 4122k > -> Found license.html > ==> Validating source files with sha1sums... > HipChat4-4.29.4.1662-Linux.deb ... Passed > license.html ... Passed > ==> Extracting sources... > -> Extracting HipChat4-4.29.4.1662-Linux.deb with bsdtar > ==> Starting prepare()... > ==> Entering fakeroot environment... > ==> Starting package()... > ==> Tidying install... > -> Removing libtool files... > -> Purging unwanted files... > -> Removing static library files... > -> Stripping unneeded symbols from binaries and libraries... > strip:./opt/HipChat4/lib/st0YqbaN[.rodata]: No space left on device > strip:./opt/HipChat4/lib/stoGJoPP[.text]: No space left on device > -> Compressing man and info pages... > ==> Checking for packaging issue... > ==> Creating package "hipchat"... > -> Generating .PKGINFO file... > -> Generating .BUILDINFO file... > -> Generating .MTREE file... > -> Compressing package... > xz: (stdout): Write error: No space left on device > bsdtar: Write error > ==> ERROR: Failed to create package file. > > > df -ah / > Filesystem Size Used > Avail Use% Mounted on > /dev/mapper/luks-e5098076-de65-4e69-b179-ffe8026f3666 211G 95G > 106G 48% / > > > Is it possible to fix? > > [1] https://aur.archlinux.org/account/milky_milk/ > [2] https://aur.archlinux.org/pkgbase/hipchat/ >

8 years, 3 months

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