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

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

10 years, 9 months

[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/

3 years, 9 months

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/

1 year, 11 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/>

1 year, 9 months

Re: [PRQ#46835] Deletion Request for python2-flask

by Marcell Meszaros

I forgot to add that actually python2-flask has been continuously broken since its submission to AUR in 2022-11, because repo dropped many Python2 modules around that time, and not all of python2-flask's dependencies were recreated on AUR. The required python2-jinja's dependencies were also among the missing ones. It also got deleted on Feb 25, 2022 (PRQ#32767). The latter has been (re)uploaded to AUR on 2022-05-22, but without declaring its mandatory requirement, python2-markupsafe. (Which no longer exists on AUR.) No one mentioned this issue on python2-flask's page. (In fact it has no comments at all.) And only I submitted a comment on python2-jinja's page about the missing dependency, in Aug 2023, because I was testing another downstream package when I ran into this blocking issue. +1: python2-flask needs python2-click, which was removed from its PKGBUILD depends array on 2023-06-29. But no one complained. It is clear that this package has not been in a usable state *ever* on AUR. On 29 August 2023 19:34:08 GMT+02:00, notify(a)aur.archlinux.org wrote: >MarsSeed [1] filed a deletion request for python2-flask [2]: > >This legacy Python2 version of the Flask web application framework is >not needed or useful to keep. > >For production purposes it is not just deprecated but also insecure. > >Current AUR consumer python2-flask-table is already broken due to >missing another dependency. > >And python2-requests only optdepends on it, but actually this was >originally a checkdepend of that. However, I found out last year that >executing the test suite of that package would have required >recreating an excessively large and complex dependency chain just for >the purpose of testing that one build. Therefore I decided to put >python2-requests' checkdepends in its optdepends, and make the test >execution inside check() get launched only if all of the optionally >defined checkdepends are satisfied. > >As several of python2-requests' optional checkdepends don't exist on >AUR, no check() function gets run by its PKGBUILD. So at this point, >the current maintainer of python2-requests would do best to remove >those optdepends, as they are superfluous. > >Safe to drop this package; no negative impact. > >[1] https://aur.archlinux.org/account/MarsSeed/ >[2] https://aur.archlinux.org/pkgbase/python2-flask/

1 year, 11 months

Re: [aur-requests] [PRQ#16805] Deletion Request for the-darkmod-tweaked

by Alberto Salvia Novella

On 26/11/19 2:27, notify(a)aur.archlinux.org wrote: > eschwartz [1] filed a deletion request for the-darkmod-tweaked [2]: > > After discussion in the package comments for thedarkmod-bin, it was > determined that the custom installer used in the former package > "darkmod" violated the rules of submission on numerous levels. > > The package was reimplemented by a Trusted User, and for good measure > cleaned up and renamed to something more closely matching upstream > intentions, but for all this, the core issue with > https://gitlab.com/es20490446e/the-darkmod-tweaked had nothing to do > whether mv is better than cp, or whatever else this justification > entails: > > ``` > So I'm providing an alternative version for this package, called "the- > darkmod-tweaked", with the following enhancements over the official > bundle: > > Separated saved games and downloaded mission repository for each > user. > Missions cache auto-cleanup. > Enhanced installation speed compared with the official installer. > ``` > > No, this is not acceptable. Your new package is still obfuscation and > violates the rules of submission. > > Your "tweaks" in comparison with thedarkmod-bin do not answer the > question: "why was the previous package orphaned via moderator > action". > > You may not re-upload a package which was deemed inadmissible to the > AUR, and simply rename the pkgname in order to justify its existence. > You are REQUIRED to either: > - first defend your claim that the initial judgment "this is unfit for > the AUR" was incorrect, or > - fix the problems > > You have done neither. > > [1]https://aur.archlinux.org/account/eschwartz/ > [2]https://aur.archlinux.org/pkgbase/the-darkmod-tweaked/ Even when I thought that could piss you off, I genuinely believed that would fall within the rules. Now you suspended my account, and destroyed all my work on Arch. But that was a less risky decision than keeping you around. Your purpose was never to enforce good practices but to boycott. What you call quality standards won't allow me to reach my goals. You don't care about the contents of the book, you only care about how well it's written.

5 years, 8 months

Re: [PRQ#47124] Deletion Request for lib32-net-snmp

by Marcell Meszaros

No, it is not needed in AUR wine builds. And neither you nor any other user has provided any use case existing today where one would need lib32-sane. On 10 September 2023 15:35:41 GMT+02:00, sL1pKn07 SpinFlo <sl1pkn07(a)gmail.com> wrote: >thats is because none of the packages on aur is builded with lib32-sane >support, but yes. is indeed needs in custom builds > >sl1-wine-git W: Dependency sane detected but optional (libraries >['usr/lib/libsane.so.1'] needed in files >['usr/lib/wine/x86_64-unix/sane.so']) >sl1-wine-git W: Dependency lib32-sane detected but optional (libraries >['usr/lib32/libsane.so.1'] needed in files >['usr/lib32/wine/i386-unix/sane.so']) > >greetings > >El dom, 10 sept 2023 a las 15:30, Marcell Meszaros (< >marcell.meszaros(a)runbox.eu>) escribió: > >> >PRQ#45251 is for lib32-sane? also needs for wine >> >> This is also not true. Only the 64-bit sane is linked to by multilib/wine, >> and none of the AUR wine package depend on lib32-sane as well. >> >> >> On 10 September 2023 09:19:45 GMT+02:00, sL1pKn07 SpinFlo < >> sl1pkn07(a)gmail.com> wrote: >> >>> >>> >>> El dom, 10 sept 2023 a las 9:17, sL1pKn07 SpinFlo (<sl1pkn07(a)gmail.com>) >>> escribió: >>> >>>> >>>> >>>> El sáb, 9 sept 2023 a las 13:42, <notify(a)aur.archlinux.org> escribió: >>>> >>>>> MarsSeed [1] filed a deletion request for lib32-net-snmp [2]: >>>>> >>>>> This unmaintained, unused package can be deleted as well after >>>>> PRQ#45251. >>>>> >>>>> [1] https://aur.archlinux.org/account/MarsSeed/ >>>>> [2] https://aur.archlinux.org/pkgbase/lib32-net-snmp/ >>>> >>>> >>>> needs for wine >>>> >>>> greetings >>>> >>> >>> PRQ#45251 is for lib32-sane? also needs for wine >>> >>> greetings >>> >>

1 year, 11 months

Re: [aur-requests] [PRQ#11354] Deletion Request for firefox-always-nightly

by Morgan Adamiec

On 10 May 2018 at 22:36, Félix Saparelli <felix(a)passcod.name> wrote: > How do I tell this request to, politely, go away? > > always-nightly has a number of differences to -nightly, not just the > "always" part of it. But if this is the main point of difference, then I > contest the claim that -nightly has "pretty good tracking". As a blatant > example, right now it is on 62.0a1.20180509, while always-nightly downloads > 62.0a1.20180510. > > There is also the fact that firefox nightly updates twice a day, not once, > so the -nightly package is never accurately tracking the latest. > > Some more occurences from the firefox-nightly comments: > > owstoni commented on 2017-08-02 22:15 > > 57 is out, could you post the new source? > > K900 commented on 2017-08-02 14:40 > > 57.0a1 is out now, needs a version bump. > > > tux-86 commented on 2017-07-21 20:11 > > Version string seems now 56.0a1.-1 > > > That's two fairly recent occasions where firefox-nightly was behind. The 57 > one shows no update in 8 hours at least. Firefox-always-nightly would have > produced the right version within a few minutes of the update actually going > out. That is why it exists. > > > On Fri, May 11, 2018 at 9:15 AM <notify(a)aur.archlinux.org> wrote: >> >> Morganamilo [1] filed a deletion request for firefox-always-nightly >> [2]: >> >> Duplicate of aur/firefox-nightly >> >> See https://lists.archlinux.org/pipermail/aur- >> general/2018-May/034080.html >> >> [1] https://aur.archlinux.org/account/Morganamilo/ >> [2] https://aur.archlinux.org/pkgbase/firefox-always-nightly/ I would think the rules on this would say it's still a duplicate. If there's problems they should be fixed, not have a new package pop up. Your PKGBUILD does a lot of hacky stuff that I don't know how to feel about it. using curl for global variables. Forcing an insanely high pkgver so that it always wants to update. It's not up to me though. I brought this up briefly in the linked thread and Eli seemed to agree so I thought I would send this request and see what happens.

7 years, 3 months

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