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

Re: [PRQ#42226] Deletion Request for wire-desktop-appimage

by Ashleigh Rowe

Hi Marcell, That may be the case, but there are many reasons to want to use an appimage over a natively installed application. And, given that it is not the same package, it need not be deleted. Taking the same logic to it's extreme, one could argue that a -git and a -bin version of a package need not both be on the AUR, as for users, it is the same. We both know, however, that this is not the case. On 16/06/2023 17:31, Marcell Meszaros wrote: > > 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, 3 months

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

by sL1pKn07 SpinFlo

*windows only 32bits scanner software cries in the corner* ok, you won. another package add (and count...) to my own local packages for maintain list *sic* greetings El dom, 10 sept 2023 a las 15:56, Marcell Meszaros (< marcell.meszaros(a)runbox.eu>) escribió: > 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 >>>> >>>

2 years

Re: [PRQ#62914] Deletion Request for gstreamer113

by Marcell Meszaros

On 28 August 2024 16:32:00 GMT+02:00, Marcell Meszaros <marcell.meszaros(a)runbox.eu> wrote: >On 28 August 2024 16:00:47 GMT+02:00, Vitalii Kuzhdin <vitaliikuzhdin(a)gmail.com> wrote: >>Greetings, >> >>I suggest you actually examine the PKGBUILD before submitting deletion >>requests. To address your point, there isn't a standalone Python version >>'311' either; it's a reference to Python 3.11, which exists in the AUR >><https://aur.archlinux.org/packages/python311> and is quite popular. I >>followed a similar naming convention here, with the proper naming specified >>in the provides array. >> >>The idea of merging all dependencies into a single PKGBUILD, simply because >>it’s possible, is impractical—and I trust I don’t need to explain why. This >>is especially true for older source trees that may require future patches. >> >>The fact that a package currently has only one dependent, just a few days >>after being uploaded, doesn’t invalidate its existence. Many packages exist >>without any dependents and are still valuable. My package serves a purpose, >>and bundling multiple packages into a single one (like cutter-test) is >>impractical. Furthermore, removing cutter-test would be unreasonable, given >>the number of packages that depend on it. I am actively reaching out to >>other maintainers to integrate testing with cutter-test. >> >>Best regards, >>Vitalii >> >>On Wed, Aug 28, 2024 at 4:46 PM <notify(a)aur.archlinux.org> wrote: >> >>> MarsSeed [1] filed a deletion request for gstreamer113 [2]: >>> >>> There is no gstreamer version 113 (one hundred and thirteen). >>> >>> This package was made for use by one package, cutter-test. >>> >>> Please don't duplicate repo packages for such a purpose; build your >>> specifically needed gstreamer version inline in the cutter-test >>> PKGBUILD, and install it in a location that is specific to cutter-test >>> only. >>> >>> [1] https://aur.archlinux.org/account/MarsSeed/ >>> [2] https://aur.archlinux.org/pkgbase/gstreamer113/ > >The 'python311' pkgname, but the package itself has legitimate purpose as a standalone PKGBUILD. (Even if it has grave packaging mistakes like its provides=python entry.) > >And, the key difference is, python311 does not conflict with repo's python package, whereas your gstreamer113 does. With this, it can potentially break hundreds of packages, if they were built against the repo version and not your legacy release. > >AUR submission guidelines explicitly say not to duplicate the repo builds, not with same or different release versions. > >If you don't want to merge this build into cutter-test, please make a different 'gstreamer-1.13' package that does not conflict with repo's gstreamer and does not declare provides=gstreamer. I wanted to say, the 'python311' pkgname is wrong. (But still, that PKGBUILD is legitimate, and it does not conflict with repo's python pkg.)

1 year

Re: [aur-requests] [PRQ#5971] Deletion Request for packettracer

by care by john

Just see how many comments are there in the last two links. Only two comments and those are complaints about invalid links. I hope you can see it before taking someone's side who questions others ability. and finally the packet tracer wiki https://aur.archlinux.org/packages/packettracer which still has that old packet tracer AUR page https://aur.archlinux.org/packages/packettracer I already tried downloading the package manually from Cisco official page and try building but it ends up only in errors. This is the thread I started last day >> https://bbs.archlinux.org/viewtopic.php?pid=1641320#p1641320 If you expect only an Arch Pro to work on your AUR stuff, then I have nothing to say. Let them pick all these pieces from diff location and try to build it. Well, Packettracer is inevitable to me for another purpose. I think I may need to go back to my previous distros for this issue which has the easy way to install it. I am done here. I expect no more talk about the same. Thank you. On Fri, Jul 15, 2016 at 12:50 AM, Rick <runnytu(a)gmail.com> wrote: > Yes, Doug are right, you don't know very well the AUR rules: > 1 If you detects something wrong, first read the existing comments of the > package, perhaps the solution is in the comments. > 2 If your problem isn't exposed before, put a new comment with the issue > and the tests you did. > 3 If in a good space of time noone responds your issue, you could make a > request for disown the package, and you or other person, fix the issue or > explain the possible solution. > In this case the solution are in the comments, cisco's packet tracer are > freeware but it's not free to redistribute, you need to open a netcad > account (free), and download from the cisco's webpage, to get packettracer > installed. > > 2016-07-14 20:14 GMT+02:00 care by john <carebyjohn(a)gmail.com>: > >> Ask Doug. He is the man questioning someone's ability. None of the >> packettracer links are valid. >> >> On Thursday 14 July 2016, Rick <runnytu(a)gmail.com> wrote: >> >>> Hi, >>> >>> I don't understand what are you telling, what are the reason for remove >>> the packettracert AUR package? >>> >>> 2016-07-14 19:04 GMT+02:00 <notify(a)aur.archlinux.org>: >>> >>>> redhat_boy [1] filed a deletion request for packettracer [2]: >>>> >>>> Remove this page itself, please. New Arch Linux users reaching out to >>>> this page by Google search engine and getting confused. >>>> >>>> [1] https://aur.archlinux.org/account/redhat_boy/ >>>> [2] https://aur.archlinux.org/pkgbase/packettracer/ >>>> >>> >>> >

9 years, 2 months

Re: [aur-requests] [PRQ#8414] Merge Request for openshift-origin-bin

by Óscar García Amor

Hi Jeremy, That's good. But take note that you cannot rename AUR packages, you can only add the new ones with the new name and make a request of deletion of old ones [1]. Greetings. [1]: https://lists.archlinux.org/pipermail/aur-general/2011-June/014866.html 2017-07-05 19:19 GMT+02:00 Jeremy Asuncion <jeremyasuncion808(a)gmail.com>: > That makes sense. I'll make sure to rename my package as soon as I get home > from work. > > Thanks! :) > > Best regards, > Jeremy. > > On Tue, Jul 4, 2017 at 11:35 PM, Óscar García Amor <ogarcia(a)moire.org> > wrote: >> >> Ok, then in this case the name of package is wrong. Must be >> openshift-origin-server-bin to avoid the confusion with the client, >> must provide origin-client-bin and have conflicts with them. >> >> I think that there is a little mess with the names of packages. IMHO >> the packages must be renamed as: >> - origin-client-bin -> openshift-origin-client-bin >> - openshift-origin-bin -> openshift-origin-server-bin >> - openshift-source-to-image -> openshift-origin-source-to-image-bin >> - openshift-origin-git -> openshift-origin-server-git >> >> The rest of openshift packages are duplicates: >> openshift-origin-client-tools (outdated and newer than his duplicate) >> is the same that origin-client-bin >> openshift-origin-source-to-image (outdated and newer than his >> duplicate) is the same that openshift-source-to-image >> >> Greetings. >> >> 2017-07-04 20:54 GMT+02:00 Jeremy Asuncion <jeremyasuncion808(a)gmail.com>: >> > origin-client-bin only includes the client tool, oc. >> > openshift-origin-bin >> > includes the openshift server. >> > >> > Thanks! :) >> > >> > Best regards, >> > Jeremy. >> > >> > On Sun, Jul 2, 2017 at 4:28 AM, <notify(a)aur.archlinux.org> wrote: >> >> >> >> ogarcia [1] filed a request to merge openshift-origin-bin [2] into >> >> origin-client-bin [3]: >> >> >> >> Are the same package >> >> >> >> [1] https://aur.archlinux.org/account/ogarcia/ >> >> [2] https://aur.archlinux.org/pkgbase/openshift-origin-bin/ >> >> [3] https://aur.archlinux.org/pkgbase/origin-client-bin/ >> > >> > >> >> >> >> -- >> Óscar García Amor | ogarcia at moire.org | http://ogarcia.me > > -- Óscar García Amor | ogarcia at moire.org | http://ogarcia.me

8 years, 2 months

Re: [PRQ#70945] Merge Request for openshift-codeready-bin

by Rubin

Hi all, So I've semi-recently had to do some work on an OpenShift-based platform, so I packaged a couple of at-the-time missing packages. At the time, I searched AUR for "openshift" related packages and found the "openshift-client-bin" package, which contains the oc command. I needed to work with tekton, codeready and odo, so I figured: "let me add the missing clients in the same vein as openshift-client-bin". So I added "openshift-developer-bin" for the 'odo' command, openshift-pipelines-bin for the 'opc', 'tkn' and 'tkn-pac' commands and openshift-codeready-bin for the 'crc' command (crc stands for code-ready-containers). It turned out that there is a crc-bin package already. I didn't catch that at the time, and now I have this merge-into-theirs (crc-bin) request. This is fine in principle, but I do think it is a better experience for ArchLinux and AUR users if they can find openshift-related packages simply by looking for openshift in the package name instead of for a specific binary, plus, not unimportantly, some of these clients (pipelines) consist of mutiple binaries, hence my thinking that simply "binary + name" might not be the best naming convention in this case. So I'm not sure if my voice has any weight here, and I'm not sure what is the best way forward: * Do nothing, just abandon my variant? * Or should I engage (how? where? with whom?) and try to work for a bit of naming consistency? In any case, the re-upload of this package was by accident a couple of months ago (I have a script that iterates over my packages and uploads after I've done changes, and I left this directory in the wrong place, leading to it being re-uploaded - I thought that would be impossible, and/or that the package would be hidden, but it turns out it actually got re-created). I also asked on #archlinux-aur but I didn't get any response (yet). Kind regards, Rubin! On Sunday, March 9th, 2025 at 13:22, Marcell Meszaros <marcell.meszaros(a)runbox.eu> wrote: > > > On 9 March 2025 11:15:24 GMT+01:00, notify(a)aur.archlinux.org wrote: > > > pfeifferj [1] filed a request to merge openshift-codeready-bin [2] > > into crc-bin [3]: > > > > duplicate > > > > [1] https://aur.archlinux.org/account/pfeifferj/ > > [2] https://aur.archlinux.org/pkgbase/openshift-codeready-bin/ > > [3] https://aur.archlinux.org/pkgbase/crc-bin/ > > +1 for either deletion or merge. > > Moreover, the same openshift-codeready-bin package has already been deleted once, because the upstream software name is 'crc'. [1] > > [1]: https://lists.archlinux.org/archives/list/aur-requests@lists.archlinux.org/…

6 months, 2 weeks

Re: [PRQ#65702] Deletion Request for kdeplasma-blurredwallpaper-git

by Bouteiller Alan

Hello, - I'm not the author of the plasma6-wallpapers-blurredwallpaper package, but I'm the author of the github repository. And historically I maintain the AUR package, and for obvious reason I want to keep maintaining the AUR package for my work, plus this package is out of date with the version of my work on github, what I can do about that? The guy built this package while I was migrating the AUR and the source between plasma 5 and 6 without ever contacting me before doing it. - I followed the wiki for building my package (https://wiki.archlinux.org/title/Arch_package_guidelines#Package_sources) I'm a little bit lost about what I have to do between what the wiki says and what you have written in your email: - If I have to take an example, is this package good: https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=python-shgo-git? - For the following "provides, conflicts, and depends" I do not see why I have to put the "provides" in my package. I understand that conflicts may contain the plasma6 package from dr460nf1r3 and that depends must contain plasma-workspace. - If I update my code on github (let's say to v4) with a well written VCS package, I just need to update the pkgver key, right? Thanks for all your answers, I'm doing this for fun, but I want to do it properly, so sorry if my questions sound silly. I'm also going to update the kdeplasma-arch-update-notifier-git package because it has the same kind of problem in it. Best. Alan Bouteiller Reach me @linkedin Or via my website alanbouteiller.pm On Thursday, 14 November 2024 at 6:59 AM, notify(a)aur.archlinux.org <notify(a)aur.archlinux.org> wrote: > MarsSeed [1] filed a deletion request for kdeplasma-blurredwallpaper- > git [2]: > > Not a VCS package: uses a fixed git tag as source. > Also missing its mandatory provides, conflicts, and depends. > > Does not follow Arch KDE package naming guidelines. [a] > > Please keep only the correctly named and packaged > AUR/plasma6-wallpapers-blurredwallpaper [b] for the same stable git > tag. > > If you want to maintain a rolling VCS package for the main branch, > please do the following: > - take the latter package as a starting point, > - declare provides and conflicts arrays containing the pkgname > 'plasma6-wallpapers-blurredwallpaper', > - specify the git repo as source but without the "#tag=" fragment in > the URL, > - and submit it under the name 'plasma6-wallpapers-blurredwallpaper- > git'. > > [a]: > https://wiki.archlinux.org/title/KDE_package_guidelines#KF_package_naming > [b]: > https://aur.archlinux.org/packages/plasma6-wallpapers-blurredwallpaper > > [1] https://aur.archlinux.org/account/MarsSeed/ > [2] https://aur.archlinux.org/pkgbase/kdeplasma-blurredwallpaper-git/

10 months, 1 week

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

by Félix Saparelli

Yeah, I'm deliberately in contravention of the rules and style of AUR to get those advantages. Also note it's not really a "new" package (four years)! But I understand if it gets deleted. Although, if it does get picked for deletion is there a way I could request a stay of execution? I'm investigating an alternate solution that wouldn't rely on the AUR at all, and therefore wouldn't push against its rules, but it's going to take a while (~1 month?) to get set up, and if I could offer a good transition strategy to those who like this flavour, then voluntarily kill it, that would probably be a better user experience. On Fri, May 11, 2018 at 9:49 AM Morgan Adamiec <morganamilo(a)gmail.com> wrote: > 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, 4 months

Re: [aur-requests] [PRQ#25316] Deletion Request for multimc-lhaus-git

by Christopher Snowhill (kode54)

From what I've gathered from watching the list on these launchers, at least the official TLauncher Legacy: Apparently, the AUR doesn't like to get into enforcing end user license agreements, or EULAs, and tracks that EULAs are not legally enforceable. I'm not entirely sure where to stand on this issue, since the launchers are not supplying the pirated game, only allowing downloading it from Microsoft's own servers, using the same method as the official launcher, which doesn't guard this download process behind any DRM. The only thing they do which may be considered a circumvention device, is spoof the authentication or session information to the game's own API calls, so that it will actually run and think that it's genuinely connected to Microsoft's servers and authenticated with either a Mojang or a Microsoft account via the launcher. They also spoof the email address or user name that allegedly authenticated, so technically you could try to connect to any Minecraft server as any user that you want, and it will just generate an arbitrary deterministic UUID for your fake account when you "log in" to offline mode. So, not so much just an EULA violation, but also a copy protection circumvention device. Feel free to correct me if I'm wrong. Anyone who is willing to, is welcome to use a VM or something to install all these various launchers one by one and verify whether they let you play the game "offline", and if so, if that can just connect to arbitrary Minecraft servers using a spoofed deterministic UUID. Then we can decide whether it's in the AUR's best interest to ban these clients, or just stick to saying "we only host the recipe to install and/or build the app, not our problem". > On Jul 19, 2021, at 5:23 AM, xcfrg <xcfrg(a)protonmail.com> wrote: > > That launcher does indeed support "offline mode" but my request for the package seemed to get denied because "it wasn't hosted on the aur". That doesn't make any sense, the package is still on the aur and at the very least, it's enabling piracy. > ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ > On Saturday, May 8th, 2021 at 4:23 PM, Christopher Snowhill <kode54(a)gmail.com> wrote: >> >> While we're narcing on Minecraft launchers, may as well look into tlauncher as well, I hear that one's been on AUR since at least 2015, and possibly supports the same "offline" mode. >> >> >> >> On Thursday, May 06, 2021 at 6:59 PM, notify--- via aur-requests <aur-requests(a)lists.archlinux.org <mailto:aur-requests@lists.archlinux.org>> wrote: >> xcfrg [1] filed a deletion request for multimc-lhaus-git [2]: >> >> This package allows one to play minecraft without purchase in full >> (not demo mode), making it illegal and piracy. You can find the >> offending code here, >> https://github.com/lhaus/MultiMC/commit/1642383dcfe9f9e4b0edfb49b6e6803e3c7…. >> >> [1] https://aur.archlinux.org/account/xcfrg/ >> [2] https://aur.archlinux.org/pkgbase/multimc-lhaus-git/ >

4 years, 2 months

Re: [PRQ#45699] Merge Request for archey3-git

by Marcell Meszaros

> You are lying. > > He did not comment about the merge request. You are not quoting him on that because he did not comment specifically on it. You mentioned the proposed merge to the archey3 dev and asked, among other things, if he would support in any way the archey4 fork. And he replied summarily with "Ship it!". Which means "Go ahead!", in case you misunderstood. On 4 August 2023 11:23:56 GMT+02:00, Gaspard d'Hautefeuille <gaspard(a)dhautefeuille.eu> wrote: >You are lying. > >He did not comment about the merge request. You are not quoting him on that because he did not comment specifically on it. > >He said he will no longer develop archey3 and that he will soon archive his repo. > >https://github.com/lclarkmichalek/archey3/issues/52#issuecomment-1663777320 > >Arguments against the merge request: > >1) archey3 is on the wiki <https://wiki.archlinux.org/title/Archey3>, not archey4 >2) archey3 is maintained in the [extra] repo <https://archlinux.org/packages/extra/any/archey3/>, not archey4 >3) archey3-git is maintained on the AUR <https://aur.archlinux.org/packages/archey3-git>, there is no such thing as archey4-git >4) archey3-git is up-to-date with the upstream repo <https://github.com/lclarkmichalek/archey3> >5) archey3-git has 171 votes, archey4 has 16 votes >6) archey3 and archey4 are forks from different authors, so votes & comments should not be merged (stolen) into a whole different package > >Argument for deletion: > >1) The archey3 author has said he will archive his repo and will no longer maintain archey3 <https://github.com/lclarkmichalek/archey3/issues/52#issuecomment-1663777320> > >Arguments against deletion: > >1) I contacted the TU Alexander Rødseth that maintains the [extra] archey3 package, he would need to consider maintaining archey4 in [extra] rather than archey3 before we consider for deletion archey3-git >2) When the TU does that, I would need to start maintaining archey4-git, before I submit for deletion archey3-git > >> On 4 Aug 2023, at 11:17, Marcell Meszaros <marcell.meszaros(a)runbox.eu> wrote: >> >> Maintainer @HLFH also asked the archery3 fork's developer if he plans to get back to it and develop it further, and he replied that he won't be doing so any longer, and in fack he only considers archiving the repo. His "archeying days are over", he said. [a] >> >> The developer also indicated he has no objection to the AUR package merge and of the "stealing" (@HLFH's choice of word) of the votes and comments by the "hippies like MarsSeed" (again @HLFH's characterisation). >> >> Arch repo's archey3 carries the exact same code from 2018 as archey3-git. >> >> Only the archey4 fork is maintained. >> >> Please note that I am not affiliated with archey4 in any way, I have no intention of stealing anything, and I guess being a hippie is not such a bad thing after all. :) >> >> [a]: https://github.com/lclarkmichalek/archey3/issues/52 >> >> On 1 August 2023 17:26:43 GMT+02:00, notify(a)aur.archlinux.org wrote: >>> MarsSeed [1] filed a request to merge archey3-git [2] into archey4 >>> [3]: >>> >>> As discussed with maintainer @HLFH in comments 10+ months ago, this >>> application has been superseded by continuation fork archey4. He >>> posted a link to the new AUR package then, so users should be well- >>> informed at this point. >>> >>> Archey3 has not been developed since 2018. [a] >>> >>> Arch repo still carries the last archey3 (however, devs would be >>> advised to consider adopting archey4 to [extra]). >>> >>> Though archey3-git is a VCS package and AUR/archey4 is not, there's no >>> VCS package for the latter but it would still be good to migrate the >>> high number of votes and comments to the successor application's >>> package rather than just deleting them. >>> >>> AUR/archey3-git is defunct so there's no harm in removing that in >>> favor of archey4. >>> >>> [a]: https://github.com/lclarkmichalek/archey3/commits/master >>> >>> [1] https://aur.archlinux.org/account/MarsSeed/ >>> [2] https://aur.archlinux.org/pkgbase/archey3-git/ >>> [3] https://aur.archlinux.org/pkgbase/archey4/ >

2 years, 1 month

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