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

Re: [PRQ#74949] Deletion Request for xlibre-server

by Vitalii Kuzhdin

Greetings, Uploading duplicate packages under a new name is not allowed on the AUR, and aggressive takeovers aren’t appreciated either. I’ve followed the naming convention used by official Xorg packages in the extra repository, and I see no reason to reinvent the wheel. To clarify and compare our approaches: 1. XLibre packages cannot provide their Xorg counterparts. The ABI versions have changed, meaning XLibre is not a drop-in replacement. Having it otherwise will result in broken systems and GUI sessions. I initially did this myself only because users would be reading the install instructions anyway, which required them to rebuild necessary components manually. However, now that there are discussions about adding XLibre to binary repositories, such provides/replaces must be removed. I agree it's inconvenient and I don’t enjoy the install process either, but for as long as there are several ABI versions, this trade-off is unavoidable. The author of the project has also made this clear: https://github.com/chaotic-aur/packages/issues/3684#issuecomment-3013197463 2. Apart from problems related to ABIs, there is also an issue with circular dependencies, namely with xlibre-input-libinput. The issue has been addressed in my packages using a bootstrap package. Your approach involves a “preupgrade” package to install before and then immediately replace. Again, your approach will result in broken setups, as users will not be forced to recompile anything after an update. Resolving this once at install time is also better than having to deal with it on every upgrade. In addition, users installing from binary repos won’t encounter this thanks to the replaces entries I added. 3. I haven't found meaningful differences in our packages beyond a few violations of AUR guidelines in yours (e.g., unneeded dependencies, ignored user build flags). So I see no reason to replace mine. Unrelated to the deletion request, I’d also like to address a few things: 1. The number of packages I maintain does not reflect my ability to support them. Plenty of AUR and official maintainers handle significantly more packages. I’ve also responded to each and every comment and email about XLibre and my other packages. In fact, this lasted daily for years, until a few weeks ago, when I had to update my packages once every few days instead of daily for very good reasons. I've also seen vague claims about my other packages being broken. If anyone feels that way, I invite them to point out specific cases and see how quickly I resolve them (if there are any at all). 2. I will not tolerate hate directed at me or my work. This especially shouldn't come from the XLibre community (either very active contributors or co-maintainers, I haven’t researched it) and should not be tolerated by you personally. I understand that reading step-by-step instructions is not for all of us, but I expect feedback to be constructive and respectful. Whoever sent the hateful messages and spammed my email by abusing the Out-of-Date flag: I expect an apology under your real name, not from an anonymous account. Otherwise, direct further communication to: vitaliikuzhdin+spam(a)gmail.com. 3. Once the above issues are resolved, and as long as the PKGBUILDs remain compliant, I’d be happy to add you as co-maintainers. With my slight experience in the topic and your official involvement, I think this project can be extremely useful and well-supported. Best regards, Vitalii Kuzhdin On Tue, Jul 29, 2025 at 8:18 PM <notify(a)aur.archlinux.org> wrote: > xlibre [1] filed a deletion request for xlibre-server [2]: > > Hello vitaliikuzhdin, > Thank you for the xlibre pkgs. > Currently we from the offcial Xlibre team are adding our supported > PKGBUILD and related files to the AUR. So can you pls remove all you > xlibre related packages? > Thank you. > artist for Xlibre > > [1] https://aur.archlinux.org/account/xlibre/ > [2] https://aur.archlinux.org/pkgbase/xlibre-server/

1 month, 1 week

Re: [PRQ#74820] Deletion Request for discord-canary-with-stable-dot-desktop

by MrPowerGamerBR

Hey (I hope I'm replying to this the right way), so, if the AUR maintainers think that the package should be removed, then it can be removed. It is my first AUR package so I may have misunderstood when I should actually create a new package vs contact the maintainers. The reason why I didn't contact the "discord-canary" maintainers is because my fix is a workaround to a bug on the original deb (as provided by Discord) Discord Canary package. My fix, however, does conflict with the original Discord installation, so you wouldn't be able to have "discord" and "discord-canary" installed on the same machine, which is why I thought it would be better to upload as a new package instead of trying to patch the original package (which could break some users workflows). The bug is that it seems that Discord hardcodes somewhere "discord.desktop" in the Discord source code, so all notifications and the unread notification badge relies on the "discord.desktop" file name but, because the "discord-canary" package uses the "discord-canary.desktop" (Which isn't wrong mind you! That's the name of the file inside the original deb package!) notifications are bound to an unknown application (so you can't disable them in KDE Plasma Notifications panel) and unread notifications badges do not work even if you have libunity installed. In fact I did provide a workaround to the bug in the original "discord-canary" package comments, however my workaround was not *that* great because it does break every time a new Discord Canary update is released, due to my DE (KDE Plasma) preferring the updated package desktop file instead of using the "discord.desktop" copy until the system is restarted or the local desktop cache refreshed. So I've decided to patch it on the PKGBUILD level. About the name: It was inspired by the "discord-canary-with-flags" package name. I couldn't figure out a better name for it because the package does what it says on the tin, I also didn't want to use a vague name like "discord-canary-fix" because that would feel very sketchy (see the names used by malicious AUR packages). So it is a conundrum of: "Should this be fixed in the original package and break users that have both discord and discord-canary installed, or should I create my own package for the users that understand the drawbacks?" But anyway, if the package feels like it can be removed, feel free to go ahead with it. I do understand that my package is, for all intents and purposes, just a clone of the current "discord-canary" package with a fix that, honestly, I think that only myself cares about. Em qui., 24 de jul. de 2025 às 15:35, <notify(a)aur.archlinux.org> escreveu: > yochananmarqos [1] filed a deletion request for discord-canary-with- > stable-dot-desktop [2]: > > Unnecessary duplicate of discord-canary. If there is an issue with the > existing package, contact the Maintainer instead of creating a > duplicate with such a minor change. Also, the package name is > ridiculous. > > [1] https://aur.archlinux.org/account/yochananmarqos/ > [2] > https://aur.archlinux.org/pkgbase/discord-canary-with-stable-dot-desktop/

1 month, 2 weeks

Re: [PRQ#50811] Deletion Request for enchant-pure

by Marcell Meszaros

Hi, Based on what you wrote, I surmise that shared library import warning logs are irrelevant for users, and those warnings can also be filtered out from system logs when debugging real problems. So it leads me to conclude that this package is not sufficiently useful to users to justify having this lesser-functionality duplicate in AUR. If the reported warnings have relevant detrimental effects, I suggest that you file an Arch bug ticket. Also, repo's enchant could solve this issue by making a split package of it, and putting each spell checking engine related .so library in separate subpackages, which in turn should each depend on their respective engine library, with the main enchant package optdepending on these engine-specific split 'enchant-*' packages. On 11 November 2023 17:57:05 GMT+01:00, Behnam Momeni <s.b.momeni(a)gmail.com> wrote: >Greetings MarsSeed and Marcell, > > >The enchant-pure is more "pure" than extra repo's version because it is built by disabling all backends, but the aspell and hunspell which allow all languages to be enabled/disabled selectively. If we install those other backends, they will be detected and used at runtime with no issue too (as demonstrated by the enchant-hspell AUR package). > >However, the extra repo's version is built by enabling all backend engines. Therefore, even when those backends are not installed, the built enchant contains those (missing) dependencies binding. > >This problem can be seen by running "gedit" as an example enchant client, after installing the extra repo's version of enchant package, and watching its warnings in the console (open gedit with the enchant-pure version and no such warning will be printed): > > >(gedit:6143): libenchant-WARNING **: 20:05:16.243: Error loading plugin: libvoikko.so.1: cannot open shared object file: No such file or directory > > (gedit:6143): libenchant-WARNING **: 20:05:16.243: Error loading plugin: libnuspell.so.5: cannot open shared object file: No such file or directory > > (gedit:6143): libenchant-WARNING **: 20:05:16.243: Error loading plugin: libhspell.so.0: cannot open shared object file: No such file or directory > > (gedit:6143): libenchant-WARNING **: 20:05:16.259: Error loading plugin: libvoikko.so.1: cannot open shared object file: No such file or directory > > (gedit:6143): libenchant-WARNING **: 20:05:16.260: Error loading plugin: libnuspell.so.5: cannot open shared object file: No such file or directory > > (gedit:6143): libenchant-WARNING **: 20:05:16.261: Error loading plugin: libhspell.so.0: cannot open shared object file: No such file or directory > >On 11/11/23 12:30, Marcell Meszaros wrote: > >Actually this has not one, but two more mandatory spell checker library depends compared to repo's enchant. So it is even more "impure", to coin this package's weird choice of qualifier suffix. On 11 November 2023 09:49:08 GMT+01:00, notify(a)aur.archlinux.org <mailto:notify@aur.archlinux.org> wrote: > >MarsSeed [1] filed a deletion request for enchant-pure [2]: Unneeded duplicate of extra/enchant, with misleading name. This is less "pure" than extra repo's package, because it has one more mandatory depends than the latter. The repo package defines its dependency on all spell checking engines as optional. [1] https://aur.archlinux.org/account/MarsSeed/ [2] https://aur.archlinux.org/pkgbase/enchant-pure/ > >-- Best Regards, Behnam Momeni

1 year, 10 months

Re: [aur-requests] [PRQ#12066] Deletion Request for popcorntime

by Jean Lucas

Agreed on suspicious claims. However, both sides point the finger at each other, so I read the code. During build, gulp downloads a custom version of NW.js from get.popcorntime.sh[1]. I have verified that various binaries in the upstream and downstream NW.js packages vary in size. I haven't found a statement by a Popcorn Time organization member saying that they use the Butter Project's NW.js build script[2], only that a custom version is used[3]. One might suppose that PT's NW.js is built from BP's script, but I have not been able to confirm this via checksums, seeing as BP's CI site[4] is down[5], and NW.js is a very heavy build. Until the CI site comes back online and we are able to confirm checksum matches, the get.popcorntime.sh NW.js package should be considered dangerous. A negative clamscan alone should not be deemed proof that the various binaries are not malicious. As for forks/alternatives, its worth noting that Popcorn Time built with upstream NW.js[6] succeeds and runs, although the internal media player will not be able to playback a lot of media due to lack of codecs, so you'd have to use an external media player in many cases. In lieu of the inconvenience, this seems to be the safest option for now. [1]: https://github.com/popcorn-official/popcorn-desktop/blob/development/gulpfi… [2]: https://github.com/butterproject/nwjs-build [3]: https://github.com/popcorn-official/popcorn-desktop/issues/624#issuecomment… [4]: https://github.com/butterproject/butter-desktop/issues/647#issuecomment-303… [5]: http://builds.butterproject.org/nw/ [6]: https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=popcorntime-git#n32 On 07/21/2018 09:53 AM, Giovanni Santini (ItachiSan) wrote: > I would like to point out the following facts: > The package I do provide is built from source, based on the code hosted here: https://github.com/popcorn-official/popcorn-desktop (https://link.getmailspring.com/link/1532179678.local-251a76dc-d25e-v1.3.0-f…) > You can report found spyware there (can you prove me is there any? A clamscan?) > On my side, I do have no malware: > $ clamscan /mnt/build/archlinux/chroots/bauerbill/popcorntime/popcorntime-0.3.10-8-x86_64.pkg.tar.xz > /mnt/build/archlinux/chroots/bauerbill/popcorntime/popcorntime-0.3.10-7-x86_64.pkg.tar.xz: OK > I could approve on redistributed binary builds, but this is not the case, as users build their package theirselves. > > The sources you provide are by far more suspicious, as the website you point to redirect to a Git repository which has as homepage an no-existing one. > > The claims provided in the link are quite general; there is no actual proof and the link provided by the 'spyware team', which is: > https://blog.popcorntime.sh/popcorn-time-safety-and-ransomware/ (https://link.getmailspring.com/link/1532179678.local-251a76dc-d25e-v1.3.0-f…) > provides by far better description and information. > To finish up, deleting the package is something I wouldn't like to do; I would be glad to switch to another fork, if you can provide me a good one. > > Giovanni SantiniComputer scientist and geek > giovannisantini93(a)yahoo.it (https://link.getmailspring.com/link/1532179678.local-251a76dc-d25e-v1.3.0-f…) > https://giovannisantini.tk (https://link.getmailspring.com/link/1532179678.local-251a76dc-d25e-v1.3.0-f…) > > On lug 17 2018, at 8:18 am, notify(a)aur.archlinux.org wrote: >> flacks [1] filed a deletion request for popcorntime [2]: >> Package reportedly distributes viruses/spyware https://www.popcorn- >> time.is/official-statement.html >> >> [1] https://aur.archlinux.org/account/flacks/ >> [2] https://aur.archlinux.org/pkgbase/popcorntime/ >> >

7 years, 1 month

[aur-requests] [PRQ#32348] Deletion Request for ninvaders

by notify＠aur.archlinux.org

Demax12 [1] filed a deletion request for ninvaders [2]: gcc -Wl,-O1,--sort-common,--as-needed,-z,relro,-z,now -onInvaders globals.o view.o aliens.o ufo.o player.o nInvaders.o -lncurses /usr/bin/ld: ufo.o:(.bss+0x6d0): multiple definition of `aliens'; aliens.o:(.bss+0x6d0): first defined here /usr/bin/ld: ufo.o:(.bss+0x0): multiple definition of `skill_level'; aliens.o:(.bss+0x0): first defined here /usr/bin/ld: ufo.o:(.bss+0x4): multiple definition of `level'; aliens.o:(.bss+0x4): first defined here /usr/bin/ld: ufo.o:(.bss+0x8): multiple definition of `weite'; aliens.o:(.bss+0x8): first defined here /usr/bin/ld: ufo.o:(.bss+0x20): multiple definition of `bunker'; aliens.o:(.bss+0x20): first defined here /usr/bin/ld: ufo.o:(.bss+0x540): multiple definition of `alienBlock'; aliens.o:(.bss+0x540): first defined here /usr/bin/ld: ufo.o:(.bss+0x608): multiple definition of `alienshotnum'; aliens.o:(.bss+0x608): first defined here /usr/bin/ld: ufo.o:(.bss+0x620): multiple definition of `alienshoty'; aliens.o:(.bss+0x620): first defined here /usr/bin/ld: ufo.o:(.bss+0x660): multiple definition of `alienshotx'; aliens.o:(.bss+0x660): first defined here /usr/bin/ld: ufo.o:(.bss+0x6a0): multiple definition of `lowest_ship'; aliens.o:(.bss+0x6a0): first defined here /usr/bin/ld: ufo.o:(.bss+0x6c8): multiple definition of `shipnum'; aliens.o:(.bss+0x6c8): first defined here /usr/bin/ld: player.o:(.bss+0x6f0): multiple definition of `aliens'; aliens.o:(.bss+0x6d0): first defined here /usr/bin/ld: player.o:(.bss+0x18): multiple definition of `skill_level'; aliens.o:(.bss+0x0): first defined here /usr/bin/ld: player.o:(.bss+0x6e8): multiple definition of `shipnum'; aliens.o:(.bss+0x6c8): first defined here /usr/bin/ld: player.o:(.bss+0x1c): multiple definition of `level'; aliens.o:(.bss+0x4): first defined here /usr/bin/ld: player.o:(.bss+0x20): multiple definition of `weite'; aliens.o:(.bss+0x8): first defined here /usr/bin/ld: player.o:(.bss+0x28): multiple definition of `ufo'; ufo.o:(.bss+0x6e8): first defined here /usr/bin/ld: player.o:(.bss+0x40): multiple definition of `bunker'; aliens.o:(.bss+0x20): first defined here /usr/bin/ld: player.o:(.bss+0x560): multiple definition of `alienBlock'; aliens.o:(.bss+0x540): first defined here /usr/bin/ld: player.o:(.bss+0x628): multiple definition of `alienshotnum'; aliens.o:(.bss+0x608): first defined here /usr/bin/ld: player.o:(.bss+0x640): multiple definition of `alienshoty'; aliens.o:(.bss+0x620): first defined here /usr/bin/ld: player.o:(.bss+0x680): multiple definition of `alienshotx'; aliens.o:(.bss+0x660): first defined here /usr/bin/ld: player.o:(.bss+0x6c0): multiple definition of `lowest_ship'; aliens.o:(.bss+0x6a0): first defined here /usr/bin/ld: nInvaders.o:(.bss+0x6f0): multiple definition of `weite'; aliens.o:(.bss+0x8): first defined here /usr/bin/ld: nInvaders.o:(.bss+0x6ec): multiple definition of `level'; aliens.o:(.bss+0x4): first defined here /usr/bin/ld: nInvaders.o:(.bss+0x6e8): multiple definition of `skill_level'; aliens.o:(.bss+0x0): first defined here /usr/bin/ld: nInvaders.o:(.bss+0x6c8): multiple definition of `shipnum'; aliens.o:(.bss+0x6c8): first defined here /usr/bin/ld: nInvaders.o:(.bss+0x18): multiple definition of `ufo'; ufo.o:(.bss+0x6e8): first defined here /usr/bin/ld: nInvaders.o:(.bss+0x20): multiple definition of `bunker'; aliens.o:(.bss+0x20): first defined here /usr/bin/ld: nInvaders.o:(.bss+0x540): multiple definition of `alienBlock'; aliens.o:(.bss+0x540): first defined here /usr/bin/ld: nInvaders.o:(.bss+0x608): multiple definition of `alienshotnum'; aliens.o:(.bss+0x608): first defined here /usr/bin/ld: nInvaders.o:(.bss+0x620): multiple definition of `alienshoty'; aliens.o:(.bss+0x620): first defined here /usr/bin/ld: nInvaders.o:(.bss+0x660): multiple definition of `alienshotx'; aliens.o:(.bss+0x660): first defined here /usr/bin/ld: nInvaders.o:(.bss+0x6a0): multiple definition of `lowest_ship'; aliens.o:(.bss+0x6a0): first defined here /usr/bin/ld: nInvaders.o:(.bss+0x6d0): multiple definition of `aliens'; aliens.o:(.bss+0x6d0): first defined here collect2: error: ld returned 1 exit status make: *** [Makefile:11: nInvaders] Error 1 Any ideas? [1] https://aur.archlinux.org/account/Demax12/ [2] https://aur.archlinux.org/pkgbase/ninvaders/

3 years, 7 months

Re: [PRQ#49836] Deletion Request for lib32-gd

by sL1pKn07 SpinFlo

El vie, 24 nov 2023 a las 12:56, Marcell Meszaros (< marcell.meszaros(a)runbox.eu>) escribió: > >>There is no other part of the libgphoto2 code that links to gd. > > > >that statement is not true at all > > > >https://github.com/search?q=repo%3Agphoto%2Flibgphoto2%20gd&type=code > > https://github.com/gphoto/libgphoto2/blob/807d44d0dcb0a8a8df151baa27830127f… > > Duh, of course the libgphoto2 configure script refers to gd / libgd. But > this does not refute my statement. > > I've checked the entire source code of libgphoto2 for references, that's > how I've found all the use cases of gd, and none of those are relevant in > lib32. > > I'd suggest you do the same checking as I did if you are in doubt. > > The configure script of libgphoto2 let's one easily disable gd support. > > @sl1pkn07 I see the obvious pattern with you that you like to try to > contradict others apparently just for the sake of it. But this kind of > disagreement that you presented here is not a counterpoint at all. > > Also you seem to like to maintain newly introduced multimedia libraries in > lib32 that have no use case whatsoever. You also tend to cling to extremely > old, deprecated, discontinued software that have no users on AUR apart from > you. > > Deleting lib32-gd of course will allow the deletion of lib32-libheif, a > package you maintain in vain, because that also falls into the category of > "too new, so no imaginable practical use cases at all in lib32". > > Please try, really try to refrain from coming up with moot arguments. Such > things do not contribute anything useful to deciding the fate of packages, > and the attitude behind it is also detrimental to the community as a whole. > > > On 30 October 2023 01:35:05 GMT+01:00, sL1pKn07 SpinFlo < > sl1pkn07(a)gmail.com> wrote: > >> >There is no other part of the libgphoto2 code that links to gd. >> >> that statement is not true at all >> >> https://github.com/search?q=repo%3Agphoto%2Flibgphoto2%20gd&type=code >> >> https://github.com/gphoto/libgphoto2/blob/807d44d0dcb0a8a8df151baa27830127f… >> >> i think you need talk with upstream for why still keep this type of thing >> in the code if is not used >> >> greetings >> >> El dom, 29 oct 2023 a las 22:55, <notify(a)aur.archlinux.org> escribió: >> >>> MarsSeed [1] filed a deletion request for lib32-gd [2]: >>> >>> lib32-gd is absolutely unnecessary for lib32-libgphoto2. >>> >>> The latter could only use gd for on-the-fly image conversion two >>> specific digital "picture frame" hardware, for which libgphoto2 >>> introduced support in 2015, well within the 64-bit era. Also that >>> library is utilized for Docupen scanner pen support, starting from >>> 2020. >>> >>> There is no other part of the libgphoto2 code that links to gd. >>> Therefore I cannot conceive any application that is bin32 only and >>> needs this specialized functionality of libgphoto2 for those 2015 and >>> 2020 released, 64-bit compatible niche hardware devices. >>> >>> I've notified the maintainer of lib32-libgphoto2 about this in July >>> 2023. >>> >>> Deleting this unneeded library would in turn allow other lib32 >>> packages to be dropped. And also it would help reduce the dependency >>> build burden on people who use AUR/wine-stable. >>> >>> [1] https://aur.archlinux.org/account/MarsSeed/ >>> [2] https://aur.archlinux.org/pkgbase/lib32-gd/ >> >> no problem, the package can live in my own :), like always greetings

1 year, 9 months

Re: [PRQ#42162] Deletion Request for libopenblas

by Marcell Meszaros

The issue mentioned in the following bug report: https://bugs.archlinux.org/task/78725 is theoretical. In the sense that there are currently zero packages in AUR that are affected by it. On 15 June 2023 01:11:34 GMT+02:00, sL1pKn07 SpinFlo <sl1pkn07(a)gmail.com> wrote: >El jue, 15 jun 2023 a las 1:09, Marcell Meszaros (< >marcell.meszaros(a)runbox.eu>) escribió: > >> There is no 32-bit build of openblas in AUR, and there is no 32-bit >> consumer of openblas in AUR. >> >> Your complaints are nonsensical at worst and nonexistent, theoretical at >> best. >> >> No harm will be done in deleting AUR/libopenblas which is a duplicate of >> [extra] openblas. >> >> AUR submission guidelines says under no circumstances should an AUR >> package build the same package that repo also builds and carries. >> >> >> On 15 June 2023 00:43:49 GMT+02:00, sL1pKn07 SpinFlo <sl1pkn07(a)gmail.com> >> wrote: >> >>> yes if a new user tries to install itself in local. If try to install it >>> with openblas in repo, it fails because file conflicts. and if forced to >>> install, when trying to build a 64 bits program with 64bits openblas, gets >>> link failed because cmake found the 32bit libs because new cmake files >>> point to it (see the bug report). >>> >>> so no, i think need solve the bug report first , then can you delete it >>> without mercy >>> >>> greetings >>> >>> El jue, 15 jun 2023 a las 0:37, Marcell Meszaros (< >>> marcell.meszaros(a)runbox.eu>) escribió: >>> >>>> The linked bug report should be addressed, but that does not necessitate >>>> keeping AUR/libopenblas. >>>> >>>> As there is no lib32-(lib)openblas package and nothing in AUR seem to >>>> need a multilib version of openblas. >>>> >>>> Also, AUR submission guidelines also mandate no copying of repo packages >>>> to address packaging bugs/requests, but to have them resolved via bug >>>> report. >>>> >>>> As for x86_64 builds on AUR requiring openblas, they should find the >>>> CMake files of repo openblas package just fine. >>>> >>>> >>>> On 15 June 2023 00:05:59 GMT+02:00, sL1pKn07 SpinFlo <sl1pkn07(a)gmail.com> >>>> wrote: >>>> >>>>> >>>>> >>>>> El jue, 15 jun 2023 a las 0:02, <notify(a)aur.archlinux.org> escribió: >>>>> >>>>>> MarsSeed [1] filed a deletion request for libopenblas [2]: >>>>>> >>>>>> This has not been needed for quite some time, as Arch repo carries >>>>>> openblas, including its libs, and it can be installed side-by-side >>>>>> with blas. >>>>>> >>>>>> [1] https://aur.archlinux.org/account/MarsSeed/ >>>>>> [2] https://aur.archlinux.org/pkgbase/libopenblas/ >>>>> >>>>> >>>>> https://bugs.archlinux.org/task/78725 >>>>> >>>>> greetings (sorry if dupped, but not CC all) >>>>> >>>> >is not theory. happens, and can you try yourself like i do before open the >issue > >try it :) > >greetings

2 years, 2 months

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

by Marcell Meszaros

> *windows only 32bits scanner software cries in the corner* The hypothetical users of those hypothetically still-in-use scanners would hypothetically best choose to install AUR/wine-wow64, or the same from Chaotic-AUR, which can execute 32-bit Windows software without touching any lib32 binaries on the Linux system. And you know, starting in 2005 Microsoft had pushed OEM's to the extreme in making them come out with 64-bit drivers for their devices, that even scanners and printers manufactured in the late 1990's have received those drivers and at least the bare minimum of supporting software. On 10 September 2023 17:04:26 GMT+02:00, sL1pKn07 SpinFlo <sl1pkn07(a)gmail.com> wrote: >*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#43382] Deletion Request for openblas-lapack

by Marcell Mészáros

Dynamic architecture support means one binary can take advantage of a wide range of microarchitectures. Also, your build turns on USE_TLS, a "new, still somewhat experimental code that uses thread-local storage instead of a central memory buffer". Which is exactly what it should not do in a production-targeted build. You should create a new package with a descriptive name suffix, like '-experimental-tls' or something. On 3 July 2023 19:33:04 GMT+02:00, Marcell Meszaros <marcell.meszaros(a)runbox.eu> wrote: >Arch repo openblas is already built with multiple microarchitecture support through > cmake '-DDYNAMIC_ARCH=ON'. > >https://gitlab.archlinux.org/archlinux/packaging/packages/openblas/ > >Your PKGBUILD, however, does not seem to enable the same for its build with make. > >The latter also does not build 64-bit precision libraries, whereas the repo buildscript does. > >So as of now, the new repo package is superior to this original AUR one, in every aspect that you mentioned. > >On 3 July 2023 19:11:20 GMT+02:00, Guillaume Horel <guillaume.horel(a)gmail.com> wrote: >>Openblas is a performance oriented package, microarchitecture optimization >>is exactly what it's about. Moreover this PKGBUILD has different build >>options than the official one which is allowed by the guidelines. >> >>On Mon, Jul 3, 2023 at 11:32 AM Marcell Meszaros <marcell.meszaros(a)runbox.eu> >>wrote: >> >>> > The package in community provides the dynamic arch version, whereas this >>> one will be specifically tuned for your current architecture. >>> >>> But this is not a good enough reason to keep PKGBUILDs for the same source >>> in both Arch repo and on AUR. >>> >>> Arch is not a binary-only distribution: all the build scripts are availabe. >>> >>> One can always grab a couple of PKGBUILDs from Arch repo's GitLab for >>> fine-tuned, microarchitecture-optimized rebuild, if that is what they want. >>> >>> But AUR submission guidelines are quite clear: they don't mention allowing >>> duplication for this purpose. >>> >>> >>> On 2 July 2023 17:34:03 GMT+02:00, Guillaume Horel < >>> guillaume.horel(a)gmail.com> wrote: >>> >>>> This is not the exactly the same package. The package in community >>>> provides the dynamic arch version, whereas this one will be specifically >>>> tuned for your current architecture. >>>> I've responded in the comments that there is nothing broken at the moment >>>> with this package, and I don't see the need to delete it. >>>> >>>> On Sun, Jul 2, 2023 at 7:17 AM <notify(a)aur.archlinux.org> wrote: >>>> >>>>> MarsSeed [1] filed a deletion request for openblas-lapack [2]: >>>>> >>>>> Same package is now in [extra], named blas-openblas: >>>>> >>>>> https://archlinux.org/packages/extra/x86_64/blas-openblas/ >>>>> >>>>> See announcement about it: >>>>> https://archlinux.org/news/openblas-0323-2-update-requires-manual- >>>>> intervention/ >>>>> <https://archlinux.org/news/openblas-0323-2-update-requires-manual-intervent…> >>>>> >>>>> I have notified AUR maintainers in comments about their need to review >>>>> this change, and possibly adapt their PKGBUILD's. >>>>> >>>>> [1] https://aur.archlinux.org/account/MarsSeed/ >>>>> [2] https://aur.archlinux.org/pkgbase/openblas-lapack/ >>>> >>>>

2 years, 2 months

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

by Ashleigh Rowe

One can also install many things on the AUR by using flatpak or a package manager. Does not mean they should be removed. Just stop with the seeming anti-appimage, ok? On Sat, 17 Jun 2023, 13:51 Marcell Meszaros, <marcell.meszaros(a)runbox.eu> wrote: > One can also install a standalone AppImage file by running it. It does not > need to be packaged via an AUR PKGBUILD. > > > On 16 June 2023 18:55:00 GMT+02:00, Ashleigh Rowe <administrator(a)hax.ie> > wrote: > >> 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> >> <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, 2 months

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