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

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

7 months, 4 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/

2 years, 2 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, 7 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, 9 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, 8 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, 6 months

Re: [aur-requests] [PRQ#1301] Deletion Request for update

by Lukas Fleischer

On Sat, 01 Nov 2014 at 00:47:30, Colin Keenan wrote: > Please do not delete my package in the AUR, 'update'. Although the script > contains only one line of relevant code that could better be done with an > alias, the package also contains a desktop file which can easily be put on > a panel or other launcher for one-click updating similar to a GUI. When > installing Arch to other people's computers, people who may not be all that > comfortable with the command line, it's much easier for me to install this > update package for them than to find and copy the script and desktop file > onto their computer. > > The idea behind this package is to add the desktop launcher to your panel > (for example the Xfce panel), and then just click on it when you want to > update your computer. The user just enters their password when asked for, > and the rest is done automatically (unless it takes so long that another > password entry is required). By making updating as easy as possible, users > will update more frequently. > This sounds like a bad idea. You should not run `pacman -Syu` (or even `yaourt -Syu`) unless you know what you are doing. Arch Linux quite often requires manual intervention. If people blindly run `pacman -Syu`, they will not read (or not understand, at least) install messages, they won't merge .pacnew files and will not take care of what is mentioned in the frontpage news. By using yaourt, they will probably also install AUR packages without reviewing the PKGBUILDs (I never used yaourt myself, so I might be wrong here). > The script and desktop file are so simple that anyone can see it's safe. > What would be the harm in leaving it in the AUR? > > On Fri, Oct 31, 2014 at 4:24 PM, <notify(a)aur.archlinux.org> wrote: > > > karol_007 [1] filed a deletion request for update [2]: > > > > A package is a bit of an overkill for this oneliner. > > > > [1] https://aur.archlinux.org/account/karol_007/ > > [2] https://aur.archlinux.org/pkgbase/update/ > > > >

11 years, 1 month

[aur-requests] [PRQ#29341] Deletion Request for ros-jade-kinect2

by notify＠aur.archlinux.org

zoorat [1] filed a deletion request for ros-jade-kinect2 [2]: sorry for the huge part of output of `paru -S --noconfirm ros-jade- kinect2`. better be deleted... ``` error: could not find all required packages: ros-jade-message-generation (wanted by: ros-jade-kinect2 -> ros- jade-tf2-ros -> ros-jade-actionlib-msgs) ros-jade-catkin (wanted by: ros-jade-kinect2 -> ros-jade-tf2-ros -> ros-jade-actionlib-msgs) ros-jade-std-msgs (wanted by: ros-jade-kinect2 -> ros-jade-tf2-ros -> ros-jade-actionlib-msgs) ros-jade-message-runtime (wanted by: ros-jade-kinect2 -> ros-jade- tf2-ros -> ros-jade-actionlib-msgs) ros-jade-geometry-msgs (wanted by: ros-jade-kinect2 -> ros-jade- tf2-ros) ros-jade-rostime (wanted by: ros-jade-kinect2 -> ros-jade-tf2-ros -> ros-jade-tf2-py -> ros-jade-tf2) ros-jade-roslib (wanted by: ros-jade-kinect2 -> ros-jade-tf2-ros -> ros-jade-tf2-py -> ros-jade-rospy) ros-jade-genmsg (wanted by: ros-jade-kinect2 -> ros-jade-tf2-ros -> ros-jade-tf2-py -> ros-jade-rospy -> ros-jade-genpy) ros-jade-roscpp (wanted by: ros-jade-kinect2 -> ros-jade-tf2-ros -> ros-jade-tf2-py -> ros-jade-rospy) ros-jade-rosunit (wanted by: ros-jade-kinect2 -> ros-jade-tf2-ros -> ros-jade-actionlib -> ros-jade-rostest) ros-jade-cpp-common (wanted by: ros-jade-kinect2 -> ros-jade- tf2-ros -> ros-jade-message-filters -> ros-jade-xmlrpcpp) ros-jade-rosconsole (wanted by: ros-jade-kinect2 -> ros-jade- tf2-ros -> ros-jade-message-filters) ros-jade-angles (wanted by: ros-jade-kinect2 -> ros-jade- kinect2-bridge -> ros-jade-tf) ros-jade-rosbuild (wanted by: ros-jade-kinect2 -> ros-jade- kinect2-bridge -> ros-jade-tf -> ros-jade-roswtf) ros-jade-cmake-modules (wanted by: ros-jade-kinect2 -> ros-jade- kinect2-bridge -> ros-jade-compressed-depth-image-transport -> ros- jade-image-transport -> ros-jade-pluginlib -> ros-jade-class-loader) ros-jade-cv-bridge (wanted by: ros-jade-kinect2 -> ros-jade- kinect2-bridge -> ros-jade-compressed-depth-image-transport) ros-jade-bondcpp (wanted by: ros-jade-kinect2 -> ros-jade- kinect2-bridge -> ros-jade-nodelet) eigen3 (wanted by: ros-jade-kinect2 -> ros-jade-kinect2-bridge -> ros-jade-depth-image-proc -> ros-jade-eigen-conversions -> ros-jade- orocos-kdl) ``` [1] https://aur.archlinux.org/account/zoorat/ [2] https://aur.archlinux.org/pkgbase/ros-jade-kinect2/

4 years, 1 month

Re: [PRQ#46142] Deletion Request for zfs-dkms-helper

by Marcell Meszaros

The zfs project's latest stable release does not officially support Linux 6.4.* yet, but your metapackage allows that version. If someone installs zfs for that kernel version, they should already be aware that it can break at any point release of it. Your package doesn't "help" in that area. If someone wants to be certain that zfs does not break with their kernel, they should install it for a supported version, which on current Arch is only the LTS kernels (6.1.x). Also 'helper' packages are usually meant to have some executable in them, but this package is empty. On 13 August 2023 04:52:52 GMT+02:00, Bin Jin <bjin(a)ctrl-d.org> wrote: >This is a meta package I created to prevent future mainline linux updates >breaking zfs-dkms packages. zfs-dkms is closely tied to linux kernel >versions and has a compatibility layer to add specific support for each >major linux kernel release (e.g. "6.x"). > >So zfs-dkms has long been worried about linux kernel upgrades, a major >upgrade could make dkms fail, and this happened a few times in the past >since Arch is very edge on kernel version upgrades. > >For users using zfs as root, this become critical if dkms is not noticed >during "pacman -Syu". The system won't boot for next reboot. > >This meta package will be updated for each zfs release, and updating the >linux kernel version upperbounds accordingly. > ><notify(a)aur.archlinux.org> 于 2023年8月13日周日 00:34写道： > >> MarsSeed [1] filed a deletion request for zfs-dkms-helper [2]: >> >> Unneeded new metapackage. Name doesn't make sense, and description is >> also not really understandable. >> >> Users can install any linux kernel and the zfs-dkms module for it, or >> a kernel-specific zfs module. This package does not add anything >> useful, and it also has a hidden upper version constraint, which is >> unnecessary. >> >> [1] https://aur.archlinux.org/account/MarsSeed/ >> [2] https://aur.archlinux.org/pkgbase/zfs-dkms-helper/

2 years, 3 months

Re: [PRQ#49231] Merge Request for spflashtool5-bin

by Omar Pakker

Just got a message back through the AUR comments: > I've created it so that it doesn't need to compile qtwebkit (very time-consuming), since the package itself contains the necessary libraries. If you notice, the installation times are very different. That means spflashtool5 [3] was created with a specific (different) goal from spflashtool5-bin [2] and is not a pure duplicate. In that case, it should not be removed as one. But it also means they should NOT be merged into each other. Kind regards, Omar On do, okt 19 2023 at 20:27:08 +02:00:00, Omar Pakker <archlinux(a)opakker.nl> wrote: > Hi dakataca, > > I also left (part of) this message on the package, just in case you > aren't on the mailing list or something. > > Why exactly was this request created? I don't see a case where these > should be merged to be honest. > The spflahtool5 [3] package was created way after spflashtol5-bin [2] > and I'm unable to see why. The more logical thing seems to be a > deletion of spflashtool5 [3] as a duplicate. > If you're providing a variant with different options, they shouldn't > be merged either; in that case, update it to clearly reflect what the > differences are. > > If you have any suggestions or improvements for spflashtool5-bin [2], > feel free to leave a comment there or send me a message. > > Kind regards, > Omar > > On do, okt 19 2023 at 16:41:35 +00:00:00, notify(a)aur.archlinux.org > wrote: >> dakataca [1] filed a request to merge spflashtool5-bin [2] into >> spflashtool5 [3]: >> >> It would be a good idea to combine the best of both PKGBUILDs, and >> the >> same version of spflashtool. >> >> [1] <https://aur.archlinux.org/account/dakataca/> >> [2] <https://aur.archlinux.org/pkgbase/spflashtool5-bin/> >> [3] <https://aur.archlinux.org/pkgbase/spflashtool5/>

2 years, 1 month

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