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

Re: [PRQ#42892] Deletion Request for xdg-utils-no-open

by Marcell Meszaros

Hi Johannes, Thank you for your reply. I recognized the possibility that this package could have been used with linopen. But I've observed that apart from that 1 user from 2021, nobody complained since that time that they need xdg-utils-no-open packaging to be corrected. Also, linopen is badly packaged, the source is not linked to external source, and after I found the external GitHub source, realized that linopen's 'open' script is 8 years old, from 2015, and unmaintained. Also AUR/linopen erroneously declares that it provides and conflicts with xdg-utils; both are incorrect. But the last comment on linopen's package was 3 years ago, apart from my comment about the source linking problem a year ago. For which I got no answer. 1 year should have been more than enough for *any* user to chime in, that they want the package fixed / updated (as it's also flagged OOD since that time). But no one responded. I do not see any point in keeping such abandoned packages on AUR, so after 1+ year of total silence, I've submitted a deletion request for linopen as well. (PRQ#42893). Consequently, I also do not see a pont in keeping this package; hence my current deletion request. On the other hand, if you say you really want to keep and use xdg-util-no-open, please state as such. In that case, I will revoke my deletion request for this package and for linopen. But that also entails that you take it upon yourself to make linopen a mandatory dependency of xdg-util-no-open, and keep the latter up-to-date like repo xdg-utils. And on top of that, you'll need to adopt linopen and fix its wrongly declared metadata, and use the externally hosted source (link in comment of linopen AUR page). If I were you, I think I would not go for keeping and maintaining these old solutions for a problem that's already been solved adequately by upstream xdg-utils. (It has a GitLab server: issues and patches are welcome.) I am awaiting your decision, and will act accordingly to accommodate your intentions. :) Cheers, Marcell (MarsSeed) On 27 June 2023 14:05:47 GMT+02:00, Johannes Frankenau <archlinux(a)johannes.frankenau.net> wrote: >Hi Marcell, > >actually, I just remembered why the original maintainer didn't add those attributes. Because xdg-utils-no-open is meant to be used with packages like linopen, mimi, busking, or mimejs it should not provide or conflict with xdg-utils, because those packages already provide xdg-utils (to be correct only the xdg-open binary without the additional utilities). So, I believe I should revert my last commit here. That was the reason why I didn’t add provides and conflicts fields in response to the request from 2022. > >Johannes > >On 27 Jun 2023, at 13:49, Marcell Meszaros wrote: >> After lingering in abandonment for the last 5 years, now after my deletion request, maintainer @frankenau added provides and conflicts fields requested by a user in 2021. >> >> But I still see no point in keeping this package. >> >> There is no maintained alternative of xdg-open on AUR, and that script is still needed by many applications. >> >> So this package will just break lots of things. >> >> Also it is still outdated compared to repo version of xdg-utils. >> >> On 27 June 2023 12:23:20 GMT+02:00, notify(a)aur.archlinux.org wrote: >>> MarsSeed [1] filed a deletion request for xdg-utils-no-open [2]: >>> >>> Abandoned mod of repo's xdg-utils. >>> Last updated in 2018. >>> >>> Badly packaged: no provides or conflicts. >>> Cannot be installed on most systems because of this. >>> >>> There is only one comment: a user mentions this same problem in >>> 2022-11. They got no reply from maintainer. >>> >>> Better to delete this defunct package. >>> >>> [1] https://aur.archlinux.org/account/MarsSeed/ >>> [2] https://aur.archlinux.org/pkgbase/xdg-utils-no-open/

2 years, 1 month

Re: [aur-requests] [PRQ#9551] Deletion Request for spinach

by Alad Wenter

> Garrett <garrett.floft(a)gmail.com> hat am 24. Oktober 2017 um 21:57 geschrieben: > > > I would be fine with removing it from the AUR helpers page as there are > presently many Bash AUR helpers. I don't know why it should be removed from > the AUR though. > The reason is that these undeveloped helpers have no purpose in 2017, apart from to expose users to risky practice. > This is not a clone of yaourt. Though according to the AUR Helpers page it > is as secure as yaourt, i.e., not very secure except for spinach you'd have > to do some interesting escaping (that to my present knowledge is not > possible, but there might be some way to do it) to get around the function > that cleans what is sourced for finding the depends. Yaourt package is 0.53 Since at least 2014 it's trivial to retrieve dependencies via the AUR RPC, and any reasonable helper does exactly that. Even if the RPC does not contain some information that the PKGBUILD does, it's easy to retrieve the .SRCINFO instead. > MiB whereas the spinach package is 23 KiB. It was originally created for > being very small and only doing the minimum required while still being fast > and useful. At the time (and maybe still now) I don't think many of the > others were as small while still having features like downloading updates > in multiple "threads". Also not sure if any of the others allow installing The "size" is nothing special and comparable to any of the script helpers. Threads are mostly useless since the arrival of the multiinfo interface. (See the related discussion on the AUR helper wiki article) > from a local directory of PKGBUILDs. Since I haven't used all of them I Not sure how (a customizepkg variant) is useful when spinach can't properly resolve dependencies to begin with. > don't really know how it compares to everything out there. Not saying it's > the greatest, but I think it has uses. Maybe in 2011. Right now it might serve as historical perspective for those writing their own AUR helpers (and in fact, I wouldn't mind having a "Defunct AUR helpers" or such section on the wiki). Otherwise you should look at a helper which uses modern, safe methods. > > On Tue, Oct 24, 2017 at 9:27 AM, <notify(a)aur.archlinux.org> wrote: > > > Alad [1] filed a deletion request for spinach [2]: > > > > Antiquated yaourt clone, sources PKGBUILDs for dependency resolution > > before users can inspect them. Otherwise no unique functionality. > > > > [1] https://aur.archlinux.org/account/Alad/ > > [2] https://aur.archlinux.org/pkgbase/spinach/ > >

7 years, 9 months

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

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

1 year, 11 months

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.)

11 months, 2 weeks

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

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

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

5 months

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/

8 months, 4 weeks

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, 3 months

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