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

[PRQ#37727] Deletion Request for chrysalis

by notify＠aur.archlinux.org

algernon [1] filed a deletion request for chrysalis [2]: I am the upstream maintainer and primary developer of Chrysalis, and I am requesting the deletion of the `chrysalis` package in that capacity. The major reason for the request is that the way this package is made completely breaks Chrysalis. Running with an external Electron is unsupported upstream to begin with, and results in Chrysalis not finding some of its static assets, such as the firmware files it is supposed to flash. This already breaks an important capability of the application. On top of that, the packaging upgrades Electron from version 17 to 19. This breaks pretty much every functionality of the package, because of breaking changes within Electron. We have intentionally stayed on Electron 17 upstream due to this reason. Anything higher introduces subtle bugs that simply do not exist with Electron 17. We will upgrade Electron once we verified that the regressions have been fixed, or if we figure out how to work them around. Due to these issues, and after numerous reports on our Discord by frustrated Arch users, we added a sanity check at startup, that verifies Chrysalis is running in a sane environment. For the past two releases, when installed via the `chrysalis` package in AUR, the application displays this screen on start: https://user- images.githubusercontent.com/17243/193005865-46313413-5ae7-46d4-b52b-8438c7… Running Chrysalis with an external Electron, one that is TWO MAJOR VERSIONS HIGHER than what is officially supported is never, ever going to work. Please remove the package, so it doesn't cause more confusion and frustration among Chrysalis users that happen to use Arch. If you need more information, you can email me at algernon(a)keyboard.io. Thanks in advance! [1] https://aur.archlinux.org/account/algernon/ [2] https://aur.archlinux.org/pkgbase/chrysalis/

2 years, 11 months

Re: [PRQ#43605] Deletion Request for advanced-rest-client-appimage

by Marcell Meszaros

There's already an AUR/advanced-rest-client for this. Upstream provides a DEB release, which can be more easily used to strip out the included Electron (Chromium) runtime. And these kinds of packages should have the '-bin' name suffix. On 5 July 2023 02:57:29 GMT+02:00, notify(a)aur.archlinux.org wrote: >MarsSeed [1] filed a deletion request for advanced-rest-client- >appimage [2]: > >Please don't upload AppImage binaries of Electron- (Chromium) based >applications. > >These are hugely bloated and go against Arch's Electron application >guidelines, namely that they should use and depend on one of the >electron packages carried by Arch repo. > >I know that creating good quality packages is hard work, but that >doesn't mean that it should be okay to spam the AUR with five hundred >foreign binary packages which duplicate a lots of binary libraries and >runtimes already existing in the Arch Linux operating system. > >This is not Windows, where bloat and duplication is the norm. Please >learn and adhere to Linux principles. When there is source available, >use primarily that to build and package an application. Or in case of >Electron applications, you can choose to use the ASAR files with Arch >repo's electron runtime, and create a -bin suffixed electron package. > >[1] https://aur.archlinux.org/account/MarsSeed/ >[2] https://aur.archlinux.org/pkgbase/advanced-rest-client-appimage/

2 years, 1 month

Re: [PRQ#42292] Deletion Request for joplin-electron

by Marcell Meszaros

Hi @dianqk, Thank you for your feedback. I will revoke my deletion request promptly. I see that joplin-desktop declares electron as dependency, but then goes on an makes the package use the bundled Electron. Your package, on the other hand, gets this right and configures the usage of system Electron properly. It would be ideal in my opinion of you could cooperate with the maintainer of joplin-desktop, maybe request co-maintenance. You could help them improve that package. It has existed for much longer and therefore it is significantly more popular. And the package name makes more sense to users. Whereas your package is more advanced and optimal, and contains the Wayland IME enhancement as well. I think maintainers and users could benefit from your expertise if you advised popular Electron-based package owners on how to make use of the Arch repo electron and how to better integrate with desktop features like those provided via Wayland. Cheers, Marcell (Mars) On 18 June 2023 15:44:00 GMT+02:00, dianqk <dianqk(a)dianqk.net> wrote: >This is a different build version. Firstly, this version utilizes the system's Electron to save disk space. Additionally, it provides support for IME (Input Method Editor) under Wayland. > >On Sat, Jun 17, 2023, at 11:21 PM, notify(a)aur.archlinux.org wrote: >> MarsSeed [1] filed a deletion request for joplin-electron [2]: >> >> Duplicate of the also Electron-based AUR/joplin-desktop: >> >> https://aur.archlinux.org/packages/joplin-desktop >> >> And the latter has a better name, since AUR/joplin is a CLI version of >> this note-taking app, whereas the Electron-based ones are desktop GUI >> programs. >> >> [1] https://aur.archlinux.org/account/MarsSeed/ >> [2] https://aur.archlinux.org/pkgbase/joplin-electron/

2 years, 3 months

Re: [PRQ#47419] Deletion Request for cherrytree-bin

by presfil

> Earler, owner updated it to 1.0.0 without adjusting the dependencies > accordingly. Sorry, this is my mistake and not an attempt to reject a previous deletion request. > I don't think it is useful to keep this on AUR. I agree with you. Haven't seen the latest version from extra. Recently I tried to build cherrytree-bin, but I could not create the libcmt ABI, it was always ahead of the Debian version, so support does not make sense. Sent with Proton Mail secure email. ------- Original Message ------- On Sunday, September 17th, 2023 at 3:30 PM, notify(a)aur.archlinux.org <notify(a)aur.archlinux.org> wrote: > MarsSeed [1] filed a deletion request for cherrytree-bin [2]: > > This is a badly maintained package. > > Earler, owner updated it to 1.0.0 without adjusting the dependencies > accordingly. > > I left a detailed feedback in a comment, listing all the needed > changes, backing it up with the output of a namcap analysis. > > Then, instead of fixing the dependencies, owner just downgraded the > package to 0.99.37 without bumping the epoch. > > In addition, owner chose to make the PKGBUILD extract the tarball > directly into the $pkgdir, keeping the upstream files' ownership and > access attributes. > > I don't think it is useful to keep this on AUR. > Arch maintainers competently take care of the package for this in > extra repo, which is on the latest upstream version (not even 1.0.0 > but 1.0.1 as of now, released on August 25th, 2023). [a] > > [a]: https://archlinux.org/packages/?q=cherrytree > > [1] https://aur.archlinux.org/account/MarsSeed/ > [2] https://aur.archlinux.org/pkgbase/cherrytree-bin/

2 years

Re: [PRQ#59779] Deletion Request for ffmpeg-nocuda

by Marcell Meszaros

On 29 April 2024 21:59:28 GMT+02:00, notify(a)aur.archlinux.org wrote: >MarsSeed [1] filed a deletion request for ffmpeg-nocuda [2]: > >Unbuildable duplicate build of Arch/extra/ffmpeg (though newer >version.) >This is the 2nd resubmit of this package after it was already deleted >once. [a] > >Maintainer @eggz does not properly test their pushed packages, and >defiantly resubmits the ones that get deleted, even if for valid >reasons. > >Arch repo's ffmpeg also builds without cuda support, so there is no >benefit in keeping a '-nocuda' pkg. > >See other instances of defiance: >- 3rd resubmit of the one-line modded pikaur-aurnews, disguised VCS >package, [b] [c] >- 2nd resubmit of the never-buildable mate-wayland-session-git. [d] >[e] > >[a]: >https://lists.archlinux.org/archives/list/aur- >requests(a)lists.archlinux.org/thread/NVZTMTOTO3RELF75PW5MQ4HE4PEKBRIQ >[b]: >https://aur.archlinux.org/packages/pikaur-aurnews >[c]: >https://lists.archlinux.org/archives/search?q=pikaur- >aurnews&mlist=aur-requests%40lists.archlinux.org&sort=date-desc >[d]: >https://aur.archlinux.org/packages/mate-wayland-session-git >[e]: >https://lists.archlinux.org/archives/search?q=mate-wayland-session- >git&mlist=aur-requests%40lists.archlinux.org&sort=date-desc > >[1] https://aur.archlinux.org/account/MarsSeed/ >[2] https://aur.archlinux.org/pkgbase/ffmpeg-nocuda/ Package submitter's account has been deleted (@eggz). Safe to delete this broken, unneeded functional duplicate of Arch/extra/ffmpeg. @eggz has confessed the true intent of creating this package (in 2020) - that he was experiencing issues with the repo ffmpeg on his non-NVIDIA setup. [a] It is evidence of defiance of AUR submission guidelines that say no duplicate submission on AUR for bugs in repo packages. May I remark that I feel vindicated in the face of my last rejected deletion request for this package, even though it was still broken at the time and its duplication intent was obvious. [a]: https://aur.archlinux.org/packages/ffmpeg-nocuda#comment-970136

1 year, 4 months

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

by Johannes Frankenau

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

Re: [PRQ#46561] Deletion Request for librsvg-og

by Marcell Meszaros

The AUR package was updated, but is still a duplicate of the ArchLinuxARM.org repo package and is not needed on AUR. On 22 August 2023 08:35:30 GMT+02:00, Marcell Meszaros <marcell.meszaros(a)runbox.eu> wrote: >Minor correction: the i586 microarchitecture is not the same as the one referred to as 'pentium4' by compilers like the gcc. > >But this error on my part has no bearing on the request to delete this package whose newer equivalent is available in ArchLinux32 repos. > >On 22 August 2023 08:15:00 GMT+02:00, notify(a)aur.archlinux.org wrote: >>MarsSeed [1] filed a deletion request for librsvg-og [2]: >> >>This is an ArchLinux32 package from 2021-05: >> >>arch=(i486 i686 pentium4) >> >>Not needed: same owner maintains this package for those architectures >>directly in ArchLinux32.org repos, where it is already on a newer git >>version (last updated on 2022-07-23). >> >>Also in ArchLinux32, there is a working rust compiler for i686 and >>pentium4 (i586) platforms, so the repo for those also carries the >>current main librsvg 2.56.x which needs rustc. >> >>As stated by librsvg-og fork repo (last updated in 2020): >>"The goal of this fork is to keep the C implementation alive and up to >>date, to help provide librsvg for platforms without a working rust >>compiler." [a] >> >>[a]: https://github.com/oaken-source/librsvg-og >> >>[1] https://aur.archlinux.org/account/MarsSeed/ >>[2] https://aur.archlinux.org/pkgbase/librsvg-og/

2 years

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

by Rick

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: [PRQ#46880] Deletion Request for pology

by Marcell Meszaros

My original request: PRQ#46854. Just for the record, I am not going behind anyone's backs. When I submit a request, it is just a proposal, and a public one, not a verdict, and not a secret. I am not a TU, only a fellow user, so there is no decision made at this point. And the package maintainers receive my submitted message, whether they are subscribed to the aur-requests mailing list or not, and they have also ample time to reply to it. Trusted Users evaluate the requests several weeks to 1-2 months later, and they take maintainers' feedback into account. And I don't think it is so outrageous to submit a request for a 9-year-old release which uses deprecated and broken Python2 based dependencies, when upstream maintains their tool in an active git repository which continually receives commits, and for which there is already an AUR package from same AUR owner, which I linked to in a comment I left on the old package's page. I think it is not reflecting very well on the maintainer to let a package rot for such a long time and not inform users with at least a suggestion to not use the stable package abandoned by upstream, and at least recommending them to use the always fresh git package. On 31 August 2023 09:01:32 GMT+02:00, notify(a)aur.archlinux.org wrote: >Gilrain [1] filed a deletion request for pology [2]: > >Though I don't support MarsSeed cavalier method by going behind >maintainers backs, I agree that this package should be deleted based >on upstream lack of "stable" releases in a decade. > >[1] https://aur.archlinux.org/account/Gilrain/ >[2] https://aur.archlinux.org/pkgbase/pology/

2 years

Re: [aur-requests] [PRQ#36474] Deletion Request for powerpill

by Marcell Meszaros

I suggest that you discuss your proposals in the public comments section of the package's AUR page instead of sending it to this deletion request thread. Also please note that @XeonDead does not receive mails sent to this list because he is not a subscriber. And TLDR; I am still convinced that regional geoblocking on its own is not a valid reason to delete a working and maintained AUR package. On 19 July 2022 14:26:17 GMT+02:00, "Christopher Snowhill (kode54) via aur-requests" <aur-requests(a)lists.archlinux.org> wrote: >How about instead, someone sets up a Gitlab.com <http://gitlab.com/> repository set to mirror the upstream? Gitlab can be configured to only mirror a repository, where it doesn't allow commits, but instead simply periodically tracks a repository and mirrors the remote commits. > >> On Jul 19, 2022, at 3:11 AM, Marcell Meszaros <marcell.meszaros(a)runbox.eu> wrote: >> >> I understand your frustration completely. And for what it's worth, >> I fully disagree with any indiscriminate geoblocking by public hosting >> providers for political or ideological reasons, absent of any valid justification (of which I can barely name any). >> >> But still, please try to be reasonable with respect to this issue. >> By the logic of your deletion proposal, all Qt software should be banned >> from Linux because The Qt Company also geoblocks Russian Federation IP addresses. >> >> On 19 July 2022 11:44:42 GMT+02:00, "Дмитрий Елисеев" <xeondead(a)gmail.com> wrote: >> Revenge? I'm not sure where you've got that from. >> My provider's IPs are sometimes getting blocked, and sometimes they're not. >> Open Source Software should be free for everyone, drawn lines based upon GeoIP isn't very nice, and such package has no place on AUR, or should at least be marked as inappropriate to use on specific territories. >> >> пн, 18 июл. 2022 г. в 20:21, Marcell Meszaros <marcell.meszaros(a)runbox.eu <mailto:marcell.meszaros@runbox.eu>>: >> Unless *all* IP's are blocked throughout the world from downloading the sources, this should not be deleted. >> >> Revenge is not a valid reason for dropping a package from AUR. >> >> On 18 July 2022 10:08:33 GMT+02:00, "Christopher Snowhill (kode54) via aur-requests" <aur-requests(a)lists.archlinux.org <mailto:aur-requests@lists.archlinux.org>> wrote: >> > >> >> On Jul 18, 2022, at 12:26 AM, notify--- via aur-requests <aur-requests(a)lists.archlinux.org <mailto:aur-requests@lists.archlinux.org>> wrote: >> >> >> >> XeonDead [1] filed a deletion request for powerpill [2]: >> >> >> >> The author has disabled connections to his storage server based on >> >> GeoIP. Just so happens, I've been hit, so the package can't be built, >> >> or it's dependencies. >> >> >> >> [1] https://aur.archlinux.org/account/XeonDead/ <https://aur.archlinux.org/account/XeonDead/> >> >> [2] https://aur.archlinux.org/pkgbase/powerpill/ <https://aur.archlinux.org/pkgbase/powerpill/> >> > >> >Sounds like the dev is one of those helpful people who think it's really "helpful" to geoblock Russia right now. That sort of "help" doesn't belong in the AUR, in my opinion. >> >> >> -- >> С уважением, >> Елисеев Дмитрий >> моб. +7 (995) 593-01-64 >

3 years, 2 months

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