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

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

[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, 6 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, 8 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 >>>>> >>>>

1 year, 11 months

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

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

Re: [aur-requests] [PRQ#407] Deletion Request for python-argparse

by Eduardo Machado

> > > This actually makes sense to me. Most people will only want one version > > or the other of the lib, depending on what software is using it. Having > > it as a split package forces them to build both and have all the deps > > for both installed. Makes sense in a binary repo, not so much in the > > AUR. > I thinked just liked this after i built these packages, and therefore, i discovered that some of then aren' t compatible with python2 and python3, two of then are python2 only, so i had to comment some lines to hide the python3 part. but i thought this was a bad solution to only keep the script ready for python3 compatibility. > I just built the python-argparse split package in less than three > seconds. Build time isn't a valid argument here. Also, I highly > recommend building all AUR packages inside a chroot; otherwise, you have > no control of what happens on your file system (think of broken build > scripts that ignore $(DESTDIR) etc.) > > I think it is a good idea to use split packages unless there are good > reasons not to do so. Note that the AUR can also be viewed as a staging > area for source packages that might eventually be moved to the official > repositories. Not using split packages means more work for Trusted Users > and developers when moving. > Thinking this way you are right. Personally i don't mind to work with one or another spec. But i would like the advise of yours to standardize this "trade of". ;) --- Eduardo M. Machado Engenheiro de Computação Rio de Janeiro - RJ Brasil 2014-08-03 15:19 GMT-03:00 Lukas Fleischer <archlinux(a)cryptocrack.de>: > On Sun, 03 Aug 2014 at 19:12:38, Doug Newgard wrote: > > On 2014-08-03 10:15, Lukas Fleischer wrote: > > > On Sun, 03 Aug 2014 at 15:33:28, Doug Newgard wrote: > > >> On 2014-08-03 08:26, notify(a)aur.archlinux.org wrote: > > >> > mawcomw [1] filed a deletion request for python-argparse [2]: > > >> > > > >> > It was a split package, and now i will use two pkgbuilds, one for > > >> > python2 and another for python3. > > >> > > > >> > [1] https://aur.archlinux.org/account/mawcomw/ > > >> > [2] https://aur.archlinux.org/pkgbase/python-argparse/ > > >> > > >> So upload the py3 version to the current python-argparse package, then > > >> upload a new python2-argparse. No need to remove what's there. > > >> > > > > > > Agreed. I would also be interested in why you would like to replace a > > > split package with two separate packages? > > > > This actually makes sense to me. Most people will only want one version > > or the other of the lib, depending on what software is using it. Having > > it as a split package forces them to build both and have all the deps > > for both installed. Makes sense in a binary repo, not so much in the > > AUR. > > > > I just built the python-argparse split package in less than three > seconds. Build time isn't a valid argument here. Also, I highly > recommend building all AUR packages inside a chroot; otherwise, you have > no control of what happens on your file system (think of broken build > scripts that ignore $(DESTDIR) etc.) > > I think it is a good idea to use split packages unless there are good > reasons not to do so. Note that the AUR can also be viewed as a staging > area for source packages that might eventually be moved to the official > repositories. Not using split packages means more work for Trusted Users > and developers when moving. >

11 years

Re: [PRQ#46940] Deletion Request for motivewave-latest-bin

by xiota

Please reject deletion requests: PRQ#46635, PRQ#46640, and PRQ#46940. They are all opened by the same user, xavierbaez, against motivewave-latest-bin. PRQ#46635: Falsely stated motivewave package brakes. Causes conflicts. The state of another package is not relevant to whether motivewave-latest-bin should be deleted. Regardless, motivewave was broken for over four months, when 6.7.0 was released on 2023-04-17, until the package was updated on 2023-08-25 (over four months). This can be confirmed by reviewing the commit log <https://aur.archlinux.org/cgit/aur.git/log/?h=motivewave>. Build log showing the broken state of the package: motivewave.log <https://github.com/chaotic-aur/packages/files/12443975/motivewave.log>. The relevant error is: ==> Validating source files with sha512sums... motivewave-6.6.15.deb ... FAILED ==> ERROR: One or more files did not pass the validity check! PRQ#46640: Issue here guy created a package with the files because he wants to duplicate packages instead of helping with code 👨🏻‍💻 Not working open source but pushing his package. He created an issue that doesn’t exist. He merged his own code in those repositories. He approved his own issue. What’s the point of creating the exact same package as motivewave but with a different maintainer. It is based on the file we download from motivewave anyway. These concern internal Chaotic AUR package selection and build policies. None of it is relevant to whether a package should be deleted from AUR proper. PRQ#46940: This guy Xiota is a stalked. This is a false accusation. Rather, evidence of xavierbaez’s behavior in violation of Arch Linux Code and Chaotic AUR code of conduct may be seen in the aurweb comments of motivewave and motivewave-latest-bin, as well as in the Chaotic AUR GitHub repository. The Chaotic AUR owner issued a “final warning” (prior to ban) to user xavierbaez for his conduct. He is flagging out of date to AUR for no reason. Whether another package is flagged has no bearing on whether this package should be deleted. Regardless, the purpose of the flag on motivewave was to encourage the maintainer to fix the package after refusing to do so after notification via ordinary comments. - motivewave has a chmod syntax error (PKGBUILD line 17, 61d4efc <https://aur.archlinux.org/cgit/aur.git/commit/?h=motivewave&id=61d4efc5898c…> ) - `.SRCINFO was manually edited for unknown purpose in 294195 <https://aur.archlinux.org/cgit/aur.git/commit/?h=motivewave&id=2941953be7ac…>, fe66229 <https://aur.archlinux.org/cgit/aur.git/commit/?h=motivewave&id=fe6622969cc4…> . Even with the exact same lines of code, he has nothing better to do to try to bring motivewave down. It is perfectly reasonable to ask package maintainers to maintain their packages. Those who do not wish to do so should disown the packages so someone who is willing to maintain them can do so. motivewave-latest-bin has diverged from motivewave in the following ways: - motivewave-latest-bin checks for upstream releases (-latest-bin) before building the package. - Dependencies have been updated. - chmod syntax error was never introduced. - .SRCINFO is generated by makepkg --printsrcinfo, not manually edited. I have already asked him to focus on his duties with other packages. Review of xavierbaez’s previous comments at aforementioned locations show no such request. He also works for Chaotic AUR, where he removed motivewave… motivewave was removed from Chaotic AUR for poor maintainership, including refusal to correct defects that were identified by Chaotic AUR maintainers. As an independent package repository, Chaotic AUR activities have no bearing on whether a package should be deleted from AUR proper. On Sat, Sep 2, 2023 at 10:51 PM <notify(a)aur.archlinux.org> wrote: > xavierbaez [1] filed a deletion request for motivewave-latest-bin [2]: > > This guy Xiota is a stalked. > He is flagging out of date to AUR for no reason. > Even with the exact same lines of code, he has nothing better to do to > try to bring motivewave down. > I have already asked him to focus on his duties with other packages. > > He also works for Chaotic AUR, where he removed motivewave, then > inmediately asked for a change, then deleted motivewave again, and > then went again against motivewave on 09/02/2023 saying it's out of > date. > > Both packages use the exact same deb file as source. > Please fix the following issues: > > a) `PKGBUILD` contains `chmod` syntax error. > > You have the same CHMOD issues as motivewave > > Here is the evidence > Original package motivewave: > > find "$pkgdir" -exec chmod g-w {} + > > Stalker package: > find "$pkgdir" -exec chmod g-w {} + > > [1] https://aur.archlinux.org/account/xavierbaez/ > [2] https://aur.archlinux.org/pkgbase/motivewave-latest-bin/

1 year, 11 months

Re: [PRQ#43382] Deletion Request for openblas-lapack

by Marcell Meszaros

(Resending with slight edit, because I sent it earlier from non-subscribed email address alias). Dynamic architecture support used in the repo package 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, stable 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, 1 month

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