Aur-requests search results for query "Deletion request for pkgbase"
aur-requests@lists.archlinux.org- 49001 messages
[aur-requests] [PRQ#4455] Deletion Request for 4kvideotomp3
by notify＠aur.archlinux.org
Sukumi [1] filed a deletion request for 4kvideotomp3 [2]:
########### !!!! URGENT ACTION REQUIRED !!!!!!!!!
#####################
########### !!!! REQUEST FOR DELETION SUBMITTED !!!!!!!
###############
NO SOURCE, PROPRIETARY SOFTWARE LICENSE, BINARIES ONLY
The maintainer is responsible that the managed packaged adhere and
comply with the community
and ArchLinux philosophy and rules of package submission.
ALL PRODUCTS OF COMPANY OpenMedia LLC US ARE AFFECTED
I THINK THE COMPLIANCE AUDIT RULES NEED A REVIEW.
LICENSE EXCERPT GIVEN BELOW
########### !!!! REQUEST FOR DELETION SUBMITTED !!!!!!!!!!!!!!
###############
########### !!!! URGENT ACTION REQUIRED !!!!!!!!!!!!!!
#######################
IMPORTANT: THIS SOFTWARE END USER LICENSE AGREEMENT ("EULA") IS A
LEGAL AGREEMENT
BETWEEN YOU AND COMPANY ("OPEN MEDIA LLC"). USE OF THE SOFTWARE
PROVIDED WITH
THIS EULA (THE "SOFTWARE") CONSTITUTES YOUR ACCEPTANCE OF THESE TERMS.
READ IT
CAREFULLY BEFORE COMPLETING THE INSTALLATION PROCESS AND USING THE
SOFTWARE.
IF YOU DO NOT AGREE TO THE TERMS OF THIS EULA, DO NOT INSTALL AND/OR
USE THIS
SOFTWARE. BY INSTALLING, COPYING, OR OTHERWISE USING THE SOFTWARE
PRODUCT, YOU
AGREE TO BE BOUND BY THE TERMS OF THIS EULA.
1. LICENSE GRANT. The Software is licensed on per user basis. "User"
means the
company, entity or individual whose funds are used to pay the license
fee. "Use"
means storing, loading, installing, executing or displaying the
Software. You may
not modify the Software or disable any licensing or control features
of the Software
except as an intended part of the Software programming features. This
license is not
transferable to any other system, or to another organization or
individual.
2. OWNERSHIP. The Software is owned and copyrighted by Open Media LLC.
Your license
confers no title or ownership in the Software and should not be
construed as a sale
of any right in the Software.
3. SOFTWARE COPYRIGHT. The Software and all rights, without limitation
including
proprietary rights therein, are owned by Open Media LLC or its
suppliers and are
protected by copyright laws and international copyright treaties, as
well as other
intellectual property laws and treaties. The Software is licensed, not
sold. You
acknowledge that no title to the intellectual property in the Software
is transferred
to you. You further acknowledge that title and full ownership rights
to the Software
will remain the exclusive property of Open Media LLC and you will not
acquire any
rights to the Software except as expressly set forth in this license.
You agree that
any copies of the Software will contain the same proprietary notices
which appear on
and in the Software.
4. "PRO" VERSION. That which is established in this clause will only
be applied to
users of the "pro" version of the software. Open Media LLC. declares
that the "pro"
version of this software offers the following characteristics:
* It is free of publicity/advertisements
* It has all declared functions activated
* It allows free updates from the date of acquisition. However the
user understands
that Open Media LLC does not have the obligation to execute these
updates during
this time or any whatsoever at any other moment.
* Open Media LLC reserves the right to dissolve this agreement with
the user of the
pro version without previous notice if any of the clauses included
in the document
have been violated.
5. CONTENT COPYRIGHT AND OWNERSHIP. You agree that the owners,
employees and
volunteers of the Company are not responsible for any loss or damages
which may
result from your illegal use of images, video clips or music files.
Make sure that
you have the right to use the images, video clips and music files you
upload to the
service. The Company claims no intellectual property rights over the
content you
upload, create or provide to the Service.
6. REVERSE ENGINEERING. You agree that you will not attempt to reverse
compile,
modify, translate, or disassemble the Software in whole or in part.
7. NO OTHER WARRANTIES. THE SOFTWARE IS PROVIDED "AS IS" WITHOUT
WARRANTY OF ANY
KIND. OPEN MEDIA LLC DISCLAIMS ALL OTHER WARRANTIES WITH RESPECT TO
THE SOFTWARE,
EITHER EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO IMPLIED
WARRANTIES OF
MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT
OF THIRD
PARTY RIGHTS. SOME JURISDICTIONS DO NOT ALLOW THE EXCLUSION OF IMPLIED
WARRANTIES
OR LIMITATIONS ON HOW LONG AN IMPLIED WARRANTY MAY LAST, OR THE
EXCLUSION OR
LIMITATION OF INCIDENTAL OR CONSEQUENTIAL DAMAGES, SO THE ABOVE
LIMITATIONS OR
EXCLUSIONS MAY NOT APPLY TO YOU. THIS WARRANTY GIVES YOU SPECIFIC
LEGAL RIGHTS
AND YOU MAY ALSO HAVE OTHER RIGHTS WHICH VARY FROM JURISDICTION TO
JURISDICTION.
8. YOUR INFORMATION and OPEN MEDIA LLC'S PRIVACY POLICY
8.1 Privacy Policy. The personal information you provide to Open Media
LLC during
the ordering and registration process is used for Open Media LLC's
internal
purposes only. Open Media LLC uses the information it collects to
learn what
you like and to improve the Software. Except as otherwise expressly
permitted
by this EULA or as otherwise authorized by you, Open Media LLC will
not give any
of your personal information to any third party without your express
approval
except as reasonably required by law, as authorized by this provision
or as
necessary to protect Open Media LLC, its agents and other
Participants. Open Media
LLC can (and you authorize Open Media LLC to) disclose any information
about you to
private entities, law enforcement agencies or government officials, as
Open Media
LLC, in its sole discretion, believe necessary or appropriate to
investigate or
resolve possible problems or inquiries, or as otherwise required by
law.
8.2 Email Communication. You agree that Open Media LLC may communicate
with you via
email and any similar technology for any purpose relating to the
Software, other
Open Media LLC products and any services or software which may in the
future be
provided by Open Media LLC or on Open Media LLC's behalf. If you do
not want to
receive communication from Open Media LLC, you can unsubscribe at any
time following
the instructions contained in any email received from Open Media LLC
or by writing
an opt-out request to Open Media LLC at support(a)4kdownload.com.
8.3 Statistics. In order to innovate and continuously improve its
products, the
company may collect some anonymous usage statistics from its Software
including,
without limitation, the collection of information on how software is
used by users.
STATISTICS POTENTIALLY COLLECTED IS ANONYMOUS AND CAN NOT IN ANY WAY
LEAD TO
IDENTIFY USERS.
9. SEVERABILITY. In the event of invalidity of any provision of this
license, the
parties agree that such invalidity shall not affect the validity of
the remaining
portions of this license.
10. NO LIABILITY FOR CONSEQUENTIAL DAMAGES. IN NO EVENT SHALL OPEN
MEDIA LLC OR
ITS SUPPLIERS BE LIABLE TO YOU FOR ANY CONSEQUENTIAL, SPECIAL,
INCIDENTAL OR
INDIRECT DAMAGES OF ANY KIND ARISING OUT OF THE DELIVERY, PERFORMANCE
OR USE OF
THE SOFTWARE, EVEN IF OPEN MEDIA LLC HAS BEEN ADVISED OF THE
POSSIBILITY OF SUCH
DAMAGES. IN NO EVENT WILL OPEN MEDIA LLC's LIABILITY FOR ANY CLAIM,
WHETHER IN
CONTRACT, TORT OR ANY OTHER THEORY OF LIABILITY, EXCEED THE LICENSE
FEE PAID BY
YOU, IF ANY.
11. GENERAL PROVISION. This is the entire agreement between you and
Open Media LLC,
which supersedes any prior agreement or understanding, whether
written, or oral,
relating to the subject matter of this EULA. If any part of this EULA
is found void
and unenforceable, it will not affect the validity of the balance of
the agreement,
which shall remain valid and enforceable according to its terms. This
EULA shall
automatically terminate upon failure by you to comply with its terms.
Open Media
LLC, on its sole discretion, may modify this EULA in writing at any
time.
[1] https://aur.archlinux.org/account/Sukumi/
[2] https://aur.archlinux.org/pkgbase/4kvideotomp3/
10 years
[aur-requests] [PRQ#4456] Deletion Request for 4kyoutubetomp3
by notify＠aur.archlinux.org
Sukumi [1] filed a deletion request for 4kyoutubetomp3 [2]:
########### !!!! URGENT ACTION REQUIRED !!!!!!!!!
#####################
########### !!!! REQUEST FOR DELETION SUBMITTED !!!!!!!
###############
NO SOURCE, PROPRIETARY SOFTWARE LICENSE, BINARIES ONLY
The maintainer is responsible that the managed packaged adhere and
comply with the community
and ArchLinux philosophy and rules of package submission.
ALL PRODUCTS OF COMPANY OpenMedia LLC US ARE AFFECTED
I THINK THE COMPLIANCE AUDIT RULES NEED A REVIEW.
LICENSE EXCERPT GIVEN BELOW
########### !!!! REQUEST FOR DELETION SUBMITTED !!!!!!!!!!!!!!
###############
########### !!!! URGENT ACTION REQUIRED !!!!!!!!!!!!!!
#######################
IMPORTANT: THIS SOFTWARE END USER LICENSE AGREEMENT ("EULA") IS A
LEGAL AGREEMENT
BETWEEN YOU AND COMPANY ("OPEN MEDIA LLC"). USE OF THE SOFTWARE
PROVIDED WITH
THIS EULA (THE "SOFTWARE") CONSTITUTES YOUR ACCEPTANCE OF THESE TERMS.
READ IT
CAREFULLY BEFORE COMPLETING THE INSTALLATION PROCESS AND USING THE
SOFTWARE.
IF YOU DO NOT AGREE TO THE TERMS OF THIS EULA, DO NOT INSTALL AND/OR
USE THIS
SOFTWARE. BY INSTALLING, COPYING, OR OTHERWISE USING THE SOFTWARE
PRODUCT, YOU
AGREE TO BE BOUND BY THE TERMS OF THIS EULA.
1. LICENSE GRANT. The Software is licensed on per user basis. "User"
means the
company, entity or individual whose funds are used to pay the license
fee. "Use"
means storing, loading, installing, executing or displaying the
Software. You may
not modify the Software or disable any licensing or control features
of the Software
except as an intended part of the Software programming features. This
license is not
transferable to any other system, or to another organization or
individual.
2. OWNERSHIP. The Software is owned and copyrighted by Open Media LLC.
Your license
confers no title or ownership in the Software and should not be
construed as a sale
of any right in the Software.
3. SOFTWARE COPYRIGHT. The Software and all rights, without limitation
including
proprietary rights therein, are owned by Open Media LLC or its
suppliers and are
protected by copyright laws and international copyright treaties, as
well as other
intellectual property laws and treaties. The Software is licensed, not
sold. You
acknowledge that no title to the intellectual property in the Software
is transferred
to you. You further acknowledge that title and full ownership rights
to the Software
will remain the exclusive property of Open Media LLC and you will not
acquire any
rights to the Software except as expressly set forth in this license.
You agree that
any copies of the Software will contain the same proprietary notices
which appear on
and in the Software.
4. "PRO" VERSION. That which is established in this clause will only
be applied to
users of the "pro" version of the software. Open Media LLC. declares
that the "pro"
version of this software offers the following characteristics:
* It is free of publicity/advertisements
* It has all declared functions activated
* It allows free updates from the date of acquisition. However the
user understands
that Open Media LLC does not have the obligation to execute these
updates during
this time or any whatsoever at any other moment.
* Open Media LLC reserves the right to dissolve this agreement with
the user of the
pro version without previous notice if any of the clauses included
in the document
have been violated.
5. CONTENT COPYRIGHT AND OWNERSHIP. You agree that the owners,
employees and
volunteers of the Company are not responsible for any loss or damages
which may
result from your illegal use of images, video clips or music files.
Make sure that
you have the right to use the images, video clips and music files you
upload to the
service. The Company claims no intellectual property rights over the
content you
upload, create or provide to the Service.
6. REVERSE ENGINEERING. You agree that you will not attempt to reverse
compile,
modify, translate, or disassemble the Software in whole or in part.
7. NO OTHER WARRANTIES. THE SOFTWARE IS PROVIDED "AS IS" WITHOUT
WARRANTY OF ANY
KIND. OPEN MEDIA LLC DISCLAIMS ALL OTHER WARRANTIES WITH RESPECT TO
THE SOFTWARE,
EITHER EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO IMPLIED
WARRANTIES OF
MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT
OF THIRD
PARTY RIGHTS. SOME JURISDICTIONS DO NOT ALLOW THE EXCLUSION OF IMPLIED
WARRANTIES
OR LIMITATIONS ON HOW LONG AN IMPLIED WARRANTY MAY LAST, OR THE
EXCLUSION OR
LIMITATION OF INCIDENTAL OR CONSEQUENTIAL DAMAGES, SO THE ABOVE
LIMITATIONS OR
EXCLUSIONS MAY NOT APPLY TO YOU. THIS WARRANTY GIVES YOU SPECIFIC
LEGAL RIGHTS
AND YOU MAY ALSO HAVE OTHER RIGHTS WHICH VARY FROM JURISDICTION TO
JURISDICTION.
8. YOUR INFORMATION and OPEN MEDIA LLC'S PRIVACY POLICY
8.1 Privacy Policy. The personal information you provide to Open Media
LLC during
the ordering and registration process is used for Open Media LLC's
internal
purposes only. Open Media LLC uses the information it collects to
learn what
you like and to improve the Software. Except as otherwise expressly
permitted
by this EULA or as otherwise authorized by you, Open Media LLC will
not give any
of your personal information to any third party without your express
approval
except as reasonably required by law, as authorized by this provision
or as
necessary to protect Open Media LLC, its agents and other
Participants. Open Media
LLC can (and you authorize Open Media LLC to) disclose any information
about you to
private entities, law enforcement agencies or government officials, as
Open Media
LLC, in its sole discretion, believe necessary or appropriate to
investigate or
resolve possible problems or inquiries, or as otherwise required by
law.
8.2 Email Communication. You agree that Open Media LLC may communicate
with you via
email and any similar technology for any purpose relating to the
Software, other
Open Media LLC products and any services or software which may in the
future be
provided by Open Media LLC or on Open Media LLC's behalf. If you do
not want to
receive communication from Open Media LLC, you can unsubscribe at any
time following
the instructions contained in any email received from Open Media LLC
or by writing
an opt-out request to Open Media LLC at support(a)4kdownload.com.
8.3 Statistics. In order to innovate and continuously improve its
products, the
company may collect some anonymous usage statistics from its Software
including,
without limitation, the collection of information on how software is
used by users.
STATISTICS POTENTIALLY COLLECTED IS ANONYMOUS AND CAN NOT IN ANY WAY
LEAD TO
IDENTIFY USERS.
9. SEVERABILITY. In the event of invalidity of any provision of this
license, the
parties agree that such invalidity shall not affect the validity of
the remaining
portions of this license.
10. NO LIABILITY FOR CONSEQUENTIAL DAMAGES. IN NO EVENT SHALL OPEN
MEDIA LLC OR
ITS SUPPLIERS BE LIABLE TO YOU FOR ANY CONSEQUENTIAL, SPECIAL,
INCIDENTAL OR
INDIRECT DAMAGES OF ANY KIND ARISING OUT OF THE DELIVERY, PERFORMANCE
OR USE OF
THE SOFTWARE, EVEN IF OPEN MEDIA LLC HAS BEEN ADVISED OF THE
POSSIBILITY OF SUCH
DAMAGES. IN NO EVENT WILL OPEN MEDIA LLC's LIABILITY FOR ANY CLAIM,
WHETHER IN
CONTRACT, TORT OR ANY OTHER THEORY OF LIABILITY, EXCEED THE LICENSE
FEE PAID BY
YOU, IF ANY.
11. GENERAL PROVISION. This is the entire agreement between you and
Open Media LLC,
which supersedes any prior agreement or understanding, whether
written, or oral,
relating to the subject matter of this EULA. If any part of this EULA
is found void
and unenforceable, it will not affect the validity of the balance of
the agreement,
which shall remain valid and enforceable according to its terms. This
EULA shall
automatically terminate upon failure by you to comply with its terms.
Open Media
LLC, on its sole discretion, may modify this EULA in writing at any
time.
[1] https://aur.archlinux.org/account/Sukumi/
[2] https://aur.archlinux.org/pkgbase/4kyoutubetomp3/
10 years
Re: [PRQ#42226] Deletion Request for wire-desktop-appimage
by Marcell Meszaros
> We've already acknowledged that they are not the same.
No, we can only acknowledge that we disagree on that point.
I believe that Trusted Users are trusted to enforce some quality guidelines on AUR.
Otherwise AUR will just descent into more and more chaos.
Which does not benefit either users, nor maintainers or TU's themselves.
When an Electron (Javascript) application is already properly configured and hosted in Arch repo, it is detrimental to have on AUR a differently packaged copy of the same internal contents with unnecessary and potentially insecure duplicated chromium/electron runtime.
You have not refuted the validity of any of my points above.
On 17 June 2023 19:41:05 GMT+02:00, Ashleigh Rowe <administrator(a)hax.ie> wrote:
>In your opinion, maybe. but to anyone who actually prefers appimages? Not so much.
>Just drop it. We've already acknowledged that they are not the same.
>
>On 17/06/2023 17:37, Marcell Meszaros wrote:
>> I am not at all against AppImage.
>>
>> But the latest wire-desktop is in Arch repo, so having wire-desktop-appimage in AUR is pointless.
>>
>>
>> On 17 June 2023 18:23:08 GMT+02:00, Ashleigh Rowe <administrator(a)hax.ie> wrote:
>>
>> 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> <mailto:administrator@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, 5 months
Re: [PRQ#70009] Deletion Request for rpcs3
by Vitalii Kuzhdin
Hello Ani,
Firstly, I would like to point out that VCS package functionality is rarely
found in major repositories. For example, ALT Linux, FreeBSD Ports, Scoop,
SlackBuilds, and T2 SDE all use Git tags similarly to how this package is
structured. Meanwhile, Nixpkgs and OpenSUSE employ a version+revision
approach, where the package is periodically updated to a newer commit. I am
unsure how you expect non-AUR users to always have access to the latest
build.
Secondly, I want to reiterate that updating the version of a VCS package
without any changes to the build process is against the rules. While it is
technically possible, it violates AUR guidelines. Another issue with VCS
packages is their poor integration with AUR helpers. Even if a user
manually requests a rebuild (e.g., with yay -S rpcs3-git), yay will update
pkgver but will skip the build, silently installing an older cached version
under a misleading new pkgver. This only makes the matters worse, as you
will receive bug reports from outdated versions misidentified as the latest.
Furthermore, as I have already explained with the LuaJIT example, official
Arch repositories (core, extra, etc.) do not support VCS packages. If this
package were ever to gain enough popularity for inclusion in the official
repositories, there would be no option to build the latest commit directly.
The only alternative would be to explicitly inform users that the official
Arch package is, in fact, unofficial and that they must install
aur/rpcs3-git, forcing them to:
1. Trust an unsigned script from an unknown third party,
2. Install an extensive toolchain (several gigabytes in size) just to
compile the package locally,
3. Maintain a stable internet connection to avoid failures during
multiple git clone operations,
4. Spend significant time compiling the package,
5. Potentially encounter build errors due to the instability of VCS
packages,
6. Possibly discover that a newer commit was published before their
build even completed,
7. Realize that their bug reports may be of little value due to the
inherent non-reproducibility of VCS packages.
If you plan to contact all distributions currently packaging RPCS3 this way
to enforce your versioning scheme, I would like to reiterate my proposed
solution: periodic version bumps. I have not seen any direct
counterarguments to this approach, and if you already have an automated
system for triggering updates, I do not see why this would be an issue. As
long as there are no changes to .gitmodules dependencies, new versions
could be released automatically without manual intervention. Even if
adjustments were required, modifying the PKGBUILD would be trivial.
On a side note, there is a reason why most widely adopted software projects
maintain multiple branches and restrict bug reports from stable releases.
As long as new commits are pushed faster than the project can be rebuilt, a
rolling-release package will inevitably lag behind the latest development
state.
Best regards,
Vitalii
On Wed, Feb 26, 2025 at 5:57 PM Annie Leonhardt <annie(a)outlook.at> wrote:
> Hello,
>
> Thank you for your reply.
>
> We can bump the AUR version should we need to push a protocol update, for
> example. And even then, users can still trigger an AUR update on their side
> if they see it's outdated and they need something from newer.
>
> We are not interested in bug reports on old builds, as we do not accept
> those, only the latest build is supported.
>
> We tend to break master branch every so often, and we can quickly remove
> builds from our updater to prevent regressions from spreading. The updater
> then updates to the last good build. And again, we can quickly push a
> version update to the git version if we want users to get explicitly
> prompted for update. With arbitrary version bumps, there is no way to tell
> if a version is good or not.
>
> Furthermore, we are already receiving support requests from people on this
> AUR because it's outdated, and we do not want to have these.
>
> A version of this AUR existed in the past, but due to the same reasons we
> also asked for it to be removed.
>
> Best Regards,
> Ani
> ------------------------------
> *From:* Vitalii Kuzhdin <vitaliikuzhdin(a)gmail.com>
> *Sent:* Sunday, February 16, 2025 8:14 PM
> *To:* noreply(a)aur.archlinux.org <noreply(a)aur.archlinux.org>
> *Cc:* aur-requests(a)lists.archlinux.org <aur-requests(a)lists.archlinux.org>;
> ani-leo(a)outlook.com <ani-leo(a)outlook.com>
> *Subject:* Re: [PRQ#70009] Deletion Request for rpcs3
>
> Greetings,
>
> Thank you for bringing the rolling version scheme to my attention, I
> wasn't aware of this.
>
> I understand the concerns about outdated builds being misleading. However,
> I believe there may still be value in maintaining this package with some
> modifications.
>
> As you already know, VCS and regular packages have differences beyond the
> pkgver() function. For example, the AUR guidelines for VCS packages suggest
> version bumps only when the build process changes, as pkgver() handles
> version updates otherwise. However, if the version is not changed on the
> AUR, users may miss notifications about new commits and important updates.
> AUR helpers (at least mainstream ones I am aware of) don't automatically
> watch the repo for changes. Without manual rebuild requests, users won't
> receive automatic updates, potentially leading to RPCN-related issues
> you've mentioned.
>
> Additionally, VCS packages lack reproducibility. Given RPCS3's extensive
> dependency chain, this could make bug tracking significantly more
> challenging.
>
> Many rolling release software packages exist in the official Arch repos
> (e.g., LuaJIT). Since official repos don't allow VCS packages, the solution
> is regular version bumps. As a compromise, I propose committing to, say,
> weekly version updates for the RPCS3 package.
>
> I'm open to further discussion, but if it is still not useful to keep
> this, I understand you obviously do not want to get bug reports coming from
> an outdated package. Thank you for the seriously impressive work behind the
> emulator.
>
> Best regards,
>
> Vitalii
>
> On Sun, Feb 16, 2025 at 8:27 PM <notify(a)aur.archlinux.org> wrote:
>
> AniLeo [1] filed a deletion request for rpcs3 [2]:
>
> Please read our release notes at
> https://github.com/RPCS3/rpcs3/releases/ and remove this AUR.
>
> This AUR is misleading, offering outdated builds as if they were some
> kind of RPCS3 stable builds, such a thing does not exist. It is
> offering a random outdated build that had no special quality control
> whatsoever compared to every other build.
>
> I leave a copy of the relevant line from our release notes below, just
> in case:
>
> "Note: These are NOT stable builds. RPCS3 is a rolling release
> software without stable builds. These are random tags we do from time
> to time. Do NOT use the branch from these tags to package RPCS3."
>
> ---
>
> Verification that I am a member of the RPCS3 team and am formally
> requesting for this AUR to be removed:
> https://forums.rpcs3.net/showthread.php?tid=208697&pid=328170#pid328170
>
> [1] https://aur.archlinux.org/account/AniLeo/
> [2] https://aur.archlinux.org/pkgbase/rpcs3/
>
>
9 months, 1 week
Re: [PRQ#45699] Merge Request for archey3-git
by Marcell Meszaros
You said I want to steal, referred to me as "hippies like MarsSeed", you said I was lying. You falsely accused me of spamming, to disqualify my legitimate answers.
That's flaming, fair and square.
Please try to aim for a more civil tone in the future. Explain your side without derogatory statements and deliberate mischaracterization of the opposing argument. Don't attribute hostile and malicious intent to the other side where there is none (it is a form of ad hominem, and a failure of reasoning).
I think you can do better than that.
Please don't continue in this antagonistic manner. I thank you for that in advance if you adhere to it.
MarsSeed
On 4 August 2023 12:42:07 GMT+02:00, Gaspard d'Hautefeuille <gaspard(a)dhautefeuille.eu> wrote:
>Sure. I’ll do the same.
>I did not insult you in any way.
>
>Flaming is about "posting insults, often including profanity or other offensive language”.
>I considered you spammed by flagging out-of-date an up-to-date package, submitting too many comments on the archey3 AUR page, submitting a merge request into a different package rather than a deletion request which could have been relevant when the archey3 package in [extra] will be deleted.
>
>You misappropriated my comment when I said to you that archey4 is more relevant for Arch users.
>I considered as well you misappropriated in my opinion the comment from the upstream archey3 dev, if I got it wrong on that, I’m sorry.
>
>> On 4 Aug 2023, at 12:30, Marcell Meszaros <marcell.meszaros(a)runbox.eu> wrote:
>>
>> I will let trusted users deal with this package and with your messages from now on.
>>
>> But please don't flame anymore. Thank you.
>>
>>
>> On 4 August 2023 12:20:05 GMT+02:00, Gaspard d'Hautefeuille <gaspard(a)dhautefeuille.eu> wrote:
>>> https://terms.archlinux.org/docs/code-of-conduct/#spamadvertisingsolicitati…
>>>
>>> Spamming is forbidden which you continue to do on this page: https://aur.archlinux.org/packages/archey3-git.
>>> You also flagged out-of-date the archey3-git package while it was in sync with the upstream archey3 repo in order to promote archey4.
>>> You should only flag out-of-date when the upstream has submitted a new release.
>>> As it is a VCS package that is maintained and the upstream has not submitted any breaking changes for the package, I’m not sure it was the right way to do things.
>>>
>>> Your interpretation of "Ship it” slang is only yours.
>>>
>>> Going ahead is only meaning this in my opinion:
>>>
>>> 1) I am currently maintaining archey4-git <https://aur.archlinux.org/packages/archey4-git>, if votes and comments should be merged into of the VCS package archey3-git, it should go there. But I don’t think merging is a good idea.
>>>
>>> 2) The TU maintaining archey3 in [extra] would have to delete archey3 and promote archey4 in [extra]
>>>
>>> 3) Then, I would submit archey3-git for deletion because as long as there is an archey3 official package and official archey3 wiki page, a VCS-equivalent package should still be offered to the Arch Linux users
>>>
>>> 4) It does not make really sense to merge archey3-git into archey4 on the AUR: not the same upstream package, not the same upstream dev, VCS vs normal releases...
>>>
>>>
>>>> On 4 Aug 2023, at 11:40, Marcell Meszaros <marcell.meszaros(a)runbox.eu> wrote:
>>>>
>>>> # Do not flame #
>>>>
>>>> Flaming, in the most common sense definition, is directing negative, disrespectful, and/or insulting comments toward someone. An equally or more negative response, resulting in a cycling exchange of insults is often the consequence. Flaming fellow members (including the Arch team) will not be tolerated. Avoid personal insults and sarcastic or patronizing language. Discussions can be productive, but quarreling is always destructive.
>>>>
>>>> https://terms.archlinux.org/docs/code-of-conduct/#do-not-flame
>>>>
>>>>
>>>> On 2 August 2023 10:32:16 GMT+02:00, Gaspard d'Hautefeuille <gaspard(a)dhautefeuille.eu> wrote:
>>>>> A fork is a fork. It does not mean it has been superseded.
>>>>> https://wiki.archlinux.org/title/Archey3
>>>>>
>>>>> Archey3 is on the wiki, not Archey4.
>>>>> You have already mentioned Archey4 on the Archey3 AUR page, one year ago.
>>>>> And you spammed yesterday the Archey3 AUR page, by flagging it out-of-date while this archey3-git package is up-to-date with the upstream repo. https://github.com/lclarkmichalek/archey3
>>>>> Not everyone wants to use Archey4, and forking by changing the number to make it seem like it has been superseded is not a good practice.
>>>>>
>>>>> Furthermore, you want to steal the 171 votes and comments of archey3 with this merge request.
>>>>> If the fork of archey4 was by the same author, we could have understood that, it is not the case here.
>>>>>
>>>>> Archey4 has 16 votes, does not have a wiki page (yet).
>>>>>
>>>>> It does seem too early to consider a deletion request for archey3-git in the AUR (Arch Linux User Repository).
>>>>> Maybe you could contact the author https://github.com/lclarkmichalek/archey3/issues and see what he is up to and if he really gives the seal of approval to archey4.
>>>>> AUR/archey3-git is not defunct and I am still maintaining it.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> You know that archey - first of his name - decided to remove archey4 as a listed fork on GitHub.
>>>>> https://github.com/djmelik/archey
>>>>>
>>>>> And even, djmelik is planning a complete re-write of Archey.
>>>>>
>>>>> It is very much too early to say 100% that the fork archey4 has to take the crown.
>>>>>
>>>>>
>>>>> Sincerely,
>>>>>
>>>>> HLFH
>>>>>
>>>>>> On 1 Aug 2023, at 17:26, notify(a)aur.archlinux.org wrote:
>>>>>>
>>>>>> MarsSeed [1] filed a request to merge archey3-git [2] into archey4
>>>>>> [3]:
>>>>>>
>>>>>> As discussed with maintainer @HLFH in comments 10+ months ago, this
>>>>>> application has been superseded by continuation fork archey4. He
>>>>>> posted a link to the new AUR package then, so users should be well-
>>>>>> informed at this point.
>>>>>>
>>>>>> Archey3 has not been developed since 2018. [a]
>>>>>>
>>>>>> Arch repo still carries the last archey3 (however, devs would be
>>>>>> advised to consider adopting archey4 to [extra]).
>>>>>>
>>>>>> Though archey3-git is a VCS package and AUR/archey4 is not, there's no
>>>>>> VCS package for the latter but it would still be good to migrate the
>>>>>> high number of votes and comments to the successor application's
>>>>>> package rather than just deleting them.
>>>>>>
>>>>>> AUR/archey3-git is defunct so there's no harm in removing that in
>>>>>> favor of archey4.
>>>>>>
>>>>>> [a]: https://github.com/lclarkmichalek/archey3/commits/master
>>>>>>
>>>>>> [1] https://aur.archlinux.org/account/MarsSeed/
>>>>>> [2] https://aur.archlinux.org/pkgbase/archey3-git/
>>>>>> [3] https://aur.archlinux.org/pkgbase/archey4/
>>>>>
>>>
>
2 years, 4 months
Re: [PRQ#42226] Deletion Request for wire-desktop-appimage
by Ashleigh Rowe
Marcell, As you so clearly pointed out, the TUs are trusted to enforce
some quality quidelines on the AUR. You are not a TU.
You claim I have not refuted your claims, however there is little reason
to do so, as I have not seen you refute any of mine. I suggest we both
drop this as I suggested a few messages ago, as clogging up the mailing
list with this BS is hardly productive, and I didn't think I'd need to
spell it out.
On 17/06/2023 19:07, Marcell Meszaros wrote:
> > We've already acknowledged that they are not the same.
>
> No, we can only acknowledge that we disagree on that point.
>
> I believe that Trusted Users are trusted to enforce some quality
> guidelines on AUR.
>
> Otherwise AUR will just descent into more and more chaos.
>
> Which does not benefit either users, nor maintainers or TU's themselves.
>
> When an Electron (Javascript) application is already properly
> configured and hosted in Arch repo, it is detrimental to have on AUR a
> differently packaged copy of the same internal contents with
> unnecessary and potentially insecure duplicated chromium/electron runtime.
>
> You have not refuted the validity of any of my points above.
>
>
> On 17 June 2023 19:41:05 GMT+02:00, Ashleigh Rowe
> <administrator(a)hax.ie> wrote:
>
> In your opinion, maybe. but to anyone who actually prefers
> appimages? Not so much.
> Just drop it. We've already acknowledged that they are not the same.
>
> On 17/06/2023 17:37, Marcell Meszaros wrote:
>> I am not at all against AppImage.
>>
>> But the latest wire-desktop is in Arch repo, so having
>> wire-desktop-appimage in AUR is pointless.
>>
>>
>> On 17 June 2023 18:23:08 GMT+02:00, Ashleigh Rowe
>> <administrator(a)hax.ie> wrote:
>>
>> 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> <mailto:administrator@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, 5 months
Re: [PRQ#45699] Merge Request for archey3-git
by Gaspard d'Hautefeuille
Sure ok, you did spam and I considered you misappropriated comments from me and the upstream archey3 dev.
I consider this merge request inappropriate as you requested to merge a VCS package into a non-VCS package from a different upstream author with a different package.
And you did not give examples of successful merge requests with this exact scenario.
As said previously, I am now maintaining as well archey4-git <https://aur.archlinux.org/packages/archey4-git> to support Arch Linux users.
I edited my GitHub issue on the archey3 upstream repo so it now reflects a more civil tone and it does not mention you.
> On 4 Aug 2023, at 13:07, Marcell Meszaros <marcell.meszaros(a)runbox.eu> wrote:
>
> You said I want to steal, referred to me as "hippies like MarsSeed", you said I was lying. You falsely accused me of spamming, to disqualify my legitimate answers.
>
> That's flaming, fair and square.
>
> Please try to aim for a more civil tone in the future. Explain your side without derogatory statements and deliberate mischaracterization of the opposing argument. Don't attribute hostile and malicious intent to the other side where there is none (it is a form of ad hominem, and a failure of reasoning).
>
> I think you can do better than that.
>
> Please don't continue in this antagonistic manner. I thank you for that in advance if you adhere to it.
>
> MarsSeed
>
>
> On 4 August 2023 12:42:07 GMT+02:00, Gaspard d'Hautefeuille <gaspard(a)dhautefeuille.eu> wrote:
>> Sure. I’ll do the same.
>> I did not insult you in any way.
>>
>> Flaming is about "posting insults, often including profanity or other offensive language”.
>> I considered you spammed by flagging out-of-date an up-to-date package, submitting too many comments on the archey3 AUR page, submitting a merge request into a different package rather than a deletion request which could have been relevant when the archey3 package in [extra] will be deleted.
>>
>> You misappropriated my comment when I said to you that archey4 is more relevant for Arch users.
>> I considered as well you misappropriated in my opinion the comment from the upstream archey3 dev, if I got it wrong on that, I’m sorry.
>>
>>> On 4 Aug 2023, at 12:30, Marcell Meszaros <marcell.meszaros(a)runbox.eu> wrote:
>>>
>>> I will let trusted users deal with this package and with your messages from now on.
>>>
>>> But please don't flame anymore. Thank you.
>>>
>>>
>>> On 4 August 2023 12:20:05 GMT+02:00, Gaspard d'Hautefeuille <gaspard(a)dhautefeuille.eu> wrote:
>>>> https://terms.archlinux.org/docs/code-of-conduct/#spamadvertisingsolicitati…
>>>>
>>>> Spamming is forbidden which you continue to do on this page: https://aur.archlinux.org/packages/archey3-git.
>>>> You also flagged out-of-date the archey3-git package while it was in sync with the upstream archey3 repo in order to promote archey4.
>>>> You should only flag out-of-date when the upstream has submitted a new release.
>>>> As it is a VCS package that is maintained and the upstream has not submitted any breaking changes for the package, I’m not sure it was the right way to do things.
>>>>
>>>> Your interpretation of "Ship it” slang is only yours.
>>>>
>>>> Going ahead is only meaning this in my opinion:
>>>>
>>>> 1) I am currently maintaining archey4-git <https://aur.archlinux.org/packages/archey4-git>, if votes and comments should be merged into of the VCS package archey3-git, it should go there. But I don’t think merging is a good idea.
>>>>
>>>> 2) The TU maintaining archey3 in [extra] would have to delete archey3 and promote archey4 in [extra]
>>>>
>>>> 3) Then, I would submit archey3-git for deletion because as long as there is an archey3 official package and official archey3 wiki page, a VCS-equivalent package should still be offered to the Arch Linux users
>>>>
>>>> 4) It does not make really sense to merge archey3-git into archey4 on the AUR: not the same upstream package, not the same upstream dev, VCS vs normal releases...
>>>>
>>>>
>>>>> On 4 Aug 2023, at 11:40, Marcell Meszaros <marcell.meszaros(a)runbox.eu> wrote:
>>>>>
>>>>> # Do not flame #
>>>>>
>>>>> Flaming, in the most common sense definition, is directing negative, disrespectful, and/or insulting comments toward someone. An equally or more negative response, resulting in a cycling exchange of insults is often the consequence. Flaming fellow members (including the Arch team) will not be tolerated. Avoid personal insults and sarcastic or patronizing language. Discussions can be productive, but quarreling is always destructive.
>>>>>
>>>>> https://terms.archlinux.org/docs/code-of-conduct/#do-not-flame
>>>>>
>>>>>
>>>>> On 2 August 2023 10:32:16 GMT+02:00, Gaspard d'Hautefeuille <gaspard(a)dhautefeuille.eu> wrote:
>>>>>> A fork is a fork. It does not mean it has been superseded.
>>>>>> https://wiki.archlinux.org/title/Archey3
>>>>>>
>>>>>> Archey3 is on the wiki, not Archey4.
>>>>>> You have already mentioned Archey4 on the Archey3 AUR page, one year ago.
>>>>>> And you spammed yesterday the Archey3 AUR page, by flagging it out-of-date while this archey3-git package is up-to-date with the upstream repo. https://github.com/lclarkmichalek/archey3
>>>>>> Not everyone wants to use Archey4, and forking by changing the number to make it seem like it has been superseded is not a good practice.
>>>>>>
>>>>>> Furthermore, you want to steal the 171 votes and comments of archey3 with this merge request.
>>>>>> If the fork of archey4 was by the same author, we could have understood that, it is not the case here.
>>>>>>
>>>>>> Archey4 has 16 votes, does not have a wiki page (yet).
>>>>>>
>>>>>> It does seem too early to consider a deletion request for archey3-git in the AUR (Arch Linux User Repository).
>>>>>> Maybe you could contact the author https://github.com/lclarkmichalek/archey3/issues and see what he is up to and if he really gives the seal of approval to archey4.
>>>>>> AUR/archey3-git is not defunct and I am still maintaining it.
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> You know that archey - first of his name - decided to remove archey4 as a listed fork on GitHub.
>>>>>> https://github.com/djmelik/archey
>>>>>>
>>>>>> And even, djmelik is planning a complete re-write of Archey.
>>>>>>
>>>>>> It is very much too early to say 100% that the fork archey4 has to take the crown.
>>>>>>
>>>>>>
>>>>>> Sincerely,
>>>>>>
>>>>>> HLFH
>>>>>>
>>>>>>> On 1 Aug 2023, at 17:26, notify(a)aur.archlinux.org wrote:
>>>>>>>
>>>>>>> MarsSeed [1] filed a request to merge archey3-git [2] into archey4
>>>>>>> [3]:
>>>>>>>
>>>>>>> As discussed with maintainer @HLFH in comments 10+ months ago, this
>>>>>>> application has been superseded by continuation fork archey4. He
>>>>>>> posted a link to the new AUR package then, so users should be well-
>>>>>>> informed at this point.
>>>>>>>
>>>>>>> Archey3 has not been developed since 2018. [a]
>>>>>>>
>>>>>>> Arch repo still carries the last archey3 (however, devs would be
>>>>>>> advised to consider adopting archey4 to [extra]).
>>>>>>>
>>>>>>> Though archey3-git is a VCS package and AUR/archey4 is not, there's no
>>>>>>> VCS package for the latter but it would still be good to migrate the
>>>>>>> high number of votes and comments to the successor application's
>>>>>>> package rather than just deleting them.
>>>>>>>
>>>>>>> AUR/archey3-git is defunct so there's no harm in removing that in
>>>>>>> favor of archey4.
>>>>>>>
>>>>>>> [a]: https://github.com/lclarkmichalek/archey3/commits/master
>>>>>>>
>>>>>>> [1] https://aur.archlinux.org/account/MarsSeed/
>>>>>>> [2] https://aur.archlinux.org/pkgbase/archey3-git/
>>>>>>> [3] https://aur.archlinux.org/pkgbase/archey4/
>>>>>>
>>>>
>>
2 years, 4 months
Re: [aur-requests] [PRQ#10670] Deletion Request for dune
by Archange
Hi,
Thanks for your email and sorry about this… This is quite a long story,
but those deletion notifications (as a matter of fact, 5 packages from
the `(ocaml-)merlin` dependency tree are “affected”) now remind me I was
only half-way through before I had to go…
First thing is that I did not use AUR PKGUILDs for any of those packages
for two reasons:
1. I missed them in the first place, because I did look for
`ocaml-merlin` only /sigh/ —especially to end up with the name `merlin`
for the package after more carefully looking at OCaml packaging
guidelines— and then was clearly tired (did that between 10 p.m. and 2
a.m., on and before a day I had other things to do) and just started to
recursively package anything needed I could not find in our repos,
without checking at AUR once again… This has actual consequences that I
need to address btw (regarding version numbers).
2. I mostly never use AUR PKGBUILDs anyway when pushing to [community],
unless they are things that are hard to figure when trying to build,
because their quality is generally poor.
Now, I actually spent almost 4 hours for writing those PKGBUILDs
“correctly” (in the sense of having them build in a [community]-suitable
way), so I can definitively agree that it is not just a `./configure;
make; make install` thing (and even worse than that, there is actually a
`./configure` in `merlin`, but it is not `autotools` one… And most
mjambon’s libs had strange `make` targets and no install ones… since his
switch to `dune/jbuilder` for his projects. Reminded me of that FOSDEM
talk on “How to make package managers cry”…).
So actually finding the AUR package (well finding them earlier, because
I did find `dune` afterwards and wrote somewhere I should look at that)
would have helped me a lot, because that was quite painful indeed
(especially finding how to pass flags during `make` and which ones where
supported). That being said, I’m perfectly fine in adding you to the
“credits”, and by the way don’t really care about that tag (I only care
about the `Maintainer` tag being accurate, because it is useful for some
tools like repology).
On the technical side of things, you’ve raised some concerns:
1. Why is there no dependency on `ocaml`?
2. Why is there no dependency on `opam`?
3. Why is there no optional runtime dependency on `ocaml-find`?
4. What is going on with the versioning scheme?
And here are some answers:
1. That’s a perfectly valid concern. I admit having not given many
thought about it and mostly went with what `namcap` returned. I cannot
find a case where it would be useful without it, so I’m adding it to
dependencies, thanks.
2. While I was working on the packaging of `dune`, I did not noticed it
needed `opam` for some actions. I did when trying to build mjambon’s
libs, and he kindly sent me toward
https://github.com/ocaml/dune/issues/372 (from
https://github.com/mjambon/easy-format/pull/20, which is something I’ve
also forgotten to do for the other ones). So I hope for `opam` to not be
required anymore in the future, at least for my use of `dune`, but in
the meantime I will add it to the dependencies.
3. Well I did not thought about putting it there since it was already in
my `makedepends` array for my mjambon’s libs PKGBUILDs (as per OCaml
packaging guidelines). But now that I look at it again, those
`makedepends` arrays are basically `(ocaml-findlib dune opam)`, so
moving this as well as `opam` to `dune` dependencies totally makes
sense. Hard dependency, that is.
4. That’s a more though point. Your (well actually upstream’s)
versioning scheme is actually not valid for a PKGBUILD, because
`1.0+beta17` is in fact an higher version number than `1.0`, and thus
would have required an epoch when updating to the final release. That
being said, since your package does exist, this also means my version
number is not higher than AUR’s one, which is not necessarily a good
practice (and actually they are similar issues because of pkgrel for the
other ones). They are two solution, with one minor variation: either we
tell people to manually install the [community] one over the AUR one, or
we add an `epoch`, which can be then done either now (and then keeping
“my” —as a matter of fact the standard for this kind of things—
versioning scheme) or when 1.0 final is released by moving to your
versioning scheme. Any opinion on this?
BTW, you have also made me notice I forgot to enable tests in `dune` and
`cppo` (but I did latter in `merlin` and `ocaml-*`). So at this point
you have definitively earned your `Contributor` tag if you care about
it. ;) (And please read below if you even want the `Maintainer` one,
that’s possible)
And thanks for mentioning `ocp-build`, because as a matter of fact in my
attempt to package `merlin`, I was also after `ocp-indent` and thus
`ocp-build`, already added them in my staging directory and thus missed
to check AUR again, but stopped there because of time. Seems like
`ocp-indent` is not there, but I’m already interested by your
`ocp-build` would it be just because it carry a patch with it,
containing something I would probably not have thought about, or its
clear indication that I will have to look carefully at that
`./configure`… ;)
And for what is worth, I’m actually not doing any development in OCaml,
but we have very recently switched to it for some algorithm teaching in
France (from caml-light, for which we have been the only users I believe
for the past 20 years…), and for some reasons not relevant for this
discussion I needed proper support for OCaml in my editor (and the
student’s ones). So that’s why I’m packaging all this, but otherwise
don’t care at all about OPAM and such because we are not going to use
anything outside of the standard. But if you are interested in packaging
them and maybe other things for ArchLinux, you might consider applying
for TU in which case I’d be OK to be your sponsor, since you will likely
do a better maintainer than I do for those OCaml packages, at least on
the ocaml building side. :)
Regards,
Bruno
P.S.: I have exactly the same issue as you when it comes to people
interpreting my mood by reading my writing, so I totally understand
that. Hint: I’ve learned that adding smileys, even if it might not look
very “professional“, helps a lot. ;)
Le 19/02/2018 à 17:03, Jakob Gahde a écrit :
> FWIW, great to have this in community. Not so great that a deletion request is the first thing that informs me about this and even less so to have somebody else run off with the work that I put into figuring out how to make this piece of software install correctly and only add a few mostly cosmetic changes for good measure, without even a mention. The process isn’t just './configure; make; make install'; at least for me it took a while to figure everything out, and I’m not exactly a newbie to all the crazy stuff that OCaml people tend to use in their build infrastructure.
> While I’m at it, I wonder what the purpose is behind not depending on OCaml for a tool aimed at building OCaml software. Secondly, OPAM is run automatically on most invocations of dune to my knowledge, so I believe depending on it is somewhat reasonable. And lastly, the sources of dune happen to mention in plain English that dune can make use of ocamlfind as an optional runtime dependency[1]. So much for my reasoning on the dependencies, I would have been happy to explain this earlier if someone had let me.
> Forgive me if I’m a little upset, but when the new community package even goes out of it’s way to provide compatibility with the versioning scheme I used on the jbuilder package before it was renamed to dune, I just don’t understand why not even a little heads-up à la “BTW this package is now in community” was possible. Personally, I even left a contributor line saying “Your Name <youremail(a)domain.com>” untouched in one of the packages I adopted, just to let people know that I’m not the only person who ever invested time in that package (namely ocp-build).
>
> tl;dr I know that in written form my thoughts tend to come off as being more furious than I actually am, and while I do in fact not like what I believe went on, what I really want you, Bruno, to take away from this is just „Please be a little more communicative in the future” :)
>
> Have a nice day
> Jakob Gahde aka J5lx
>
> [1] https://github.com/ocaml/dune/blob/1.0%2Bbeta17/jbuilder.opam#L17-L22
>
> On Mon, 19 Feb 2018, at 15:34, notify(a)aur.archlinux.org wrote:
>> mis [1] filed a deletion request for dune [2]:
>>
>> in [community]
>> https://www.archlinux.org/packages/community/x86_64/dune/
>>
>> [1] https://aur.archlinux.org/account/mis/
>> [2] https://aur.archlinux.org/pkgbase/dune/
7 years, 9 months
Re: [PRQ#42226] Deletion Request for wire-desktop-appimage
by Marcell Meszaros
• AUR submission guidelines say that uploaded packages should be useful to users and significantly different than Arch repo packages.
• Arch Electron packaging guidelines suggest to strip out the bundled Electron/Chromium runtime from application package.
AUR/wire-desktop-appimage does not fulfill any of the above requirements.
And on top, it is more bloated and potentially less secure.
Therefore only Arch [extra] wire-desktop should be kept.
On 18 June 2023 00:24:49 GMT+02:00, Ashleigh Rowe <administrator(a)hax.ie> wrote:
>Marcell, As you so clearly pointed out, the TUs are trusted to enforce some quality quidelines on the AUR. You are not a TU.
>
>You claim I have not refuted your claims, however there is little reason to do so, as I have not seen you refute any of mine. I suggest we both drop this as I suggested a few messages ago, as clogging up the mailing list with this BS is hardly productive, and I didn't think I'd need to spell it out.
>
>
>On 17/06/2023 19:07, Marcell Meszaros wrote:
>> > We've already acknowledged that they are not the same.
>>
>> No, we can only acknowledge that we disagree on that point.
>>
>> I believe that Trusted Users are trusted to enforce some quality guidelines on AUR.
>>
>> Otherwise AUR will just descent into more and more chaos.
>>
>> Which does not benefit either users, nor maintainers or TU's themselves.
>>
>> When an Electron (Javascript) application is already properly configured and hosted in Arch repo, it is detrimental to have on AUR a differently packaged copy of the same internal contents with unnecessary and potentially insecure duplicated chromium/electron runtime.
>>
>> You have not refuted the validity of any of my points above.
>>
>>
>> On 17 June 2023 19:41:05 GMT+02:00, Ashleigh Rowe <administrator(a)hax.ie> wrote:
>>
>> In your opinion, maybe. but to anyone who actually prefers
>> appimages? Not so much.
>> Just drop it. We've already acknowledged that they are not the same.
>>
>> On 17/06/2023 17:37, Marcell Meszaros wrote:
>>> I am not at all against AppImage.
>>>
>>> But the latest wire-desktop is in Arch repo, so having
>>> wire-desktop-appimage in AUR is pointless.
>>>
>>>
>>> On 17 June 2023 18:23:08 GMT+02:00, Ashleigh Rowe
>>> <administrator(a)hax.ie> wrote:
>>>
>>> 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> <mailto:administrator@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, 5 months
[PRQ#52396] Deletion Request for mpd-git
by notify＠aur.archlinux.org
mackel [1] filed a deletion request for mpd-git [2]:
I installed it with throw problem. Maybe it is because ffmpeg update
the vmaf.
FAILED: mpd
c++ -o mpd mpd.p/meson-generated_.._GitVersion.cxx.o
mpd.p/src_Main.cxx.o mpd.p/src_protocol_ArgParser.cxx.o
mpd.p/src_command_CommandError.cxx.o
mpd.p/src_command_PositionArg.cxx.o
mpd.p/src_command_AllCommands.cxx.o
mpd.p/src_command_QueueCommands.cxx.o
mpd.p/src_command_TagCommands.cxx.o
mpd.p/src_command_PlayerCommands.cxx.o
mpd.p/src_command_PlaylistCommands.cxx.o
mpd.p/src_command_FileCommands.cxx.o
mpd.p/src_command_OutputCommands.cxx.o
mpd.p/src_command_MessageCommands.cxx.o
mpd.p/src_command_ClientCommands.cxx.o
mpd.p/src_command_PartitionCommands.cxx.o
mpd.p/src_command_OtherCommands.cxx.o
mpd.p/src_command_CommandListBuilder.cxx.o
mpd.p/src_config_PartitionConfig.cxx.o
mpd.p/src_config_PlayerConfig.cxx.o
mpd.p/src_config_ReplayGainConfig.cxx.o mpd.p/src_Idle.cxx.o
mpd.p/src_IdleFlags.cxx.o mpd.p/src_decoder_Thread.cxx.o
mpd.p/src_decoder_Control.cxx.o mpd.p/src_decoder_Bridge.cxx.o
mpd.p/src_decoder_DecoderPrint.cxx.o mpd.p/src_client_Listener.cxx.o
mpd.p/src_client_Client.cxx.o mpd.p/src_client_Config.cxx.o
mpd.p/src_client_Domain.cxx.o mpd.p/src_client_Event.cxx.o
mpd.p/src_client_Expire.cxx.o mpd.p/src_client_Idle.cxx.o
mpd.p/src_client_List.cxx.o mpd.p/src_client_New.cxx.o
mpd.p/src_client_Process.cxx.o mpd.p/src_client_Read.cxx.o
mpd.p/src_client_Write.cxx.o mpd.p/src_client_Message.cxx.o
mpd.p/src_client_Subscribe.cxx.o mpd.p/src_client_File.cxx.o
mpd.p/src_client_Response.cxx.o
mpd.p/src_client_ThreadBackgroundCommand.cxx.o mpd.p/src_Listen.cxx.o
mpd.p/src_LogInit.cxx.o mpd.p/src_ls.cxx.o mpd.p/src_Instance.cxx.o
mpd.p/src_MusicBuffer.cxx.o mpd.p/src_MusicPipe.cxx.o
mpd.p/src_MusicChunk.cxx.o mpd.p/src_MusicChunkPtr.cxx.o
mpd.p/src_Mapper.cxx.o mpd.p/src_Partition.cxx.o
mpd.p/src_Permission.cxx.o mpd.p/src_player_CrossFade.cxx.o
mpd.p/src_player_Thread.cxx.o mpd.p/src_player_Control.cxx.o
mpd.p/src_PlaylistError.cxx.o mpd.p/src_PlaylistPrint.cxx.o
mpd.p/src_PlaylistSave.cxx.o mpd.p/src_playlist_PlaylistStream.cxx.o
mpd.p/src_playlist_PlaylistMapper.cxx.o
mpd.p/src_playlist_PlaylistAny.cxx.o
mpd.p/src_playlist_PlaylistSong.cxx.o
mpd.p/src_playlist_PlaylistQueue.cxx.o mpd.p/src_playlist_Print.cxx.o
mpd.p/src_db_PlaylistVector.cxx.o mpd.p/src_queue_Queue.cxx.o
mpd.p/src_queue_Print.cxx.o mpd.p/src_queue_Save.cxx.o
mpd.p/src_queue_Selection.cxx.o mpd.p/src_queue_Playlist.cxx.o
mpd.p/src_queue_PlaylistControl.cxx.o
mpd.p/src_queue_PlaylistEdit.cxx.o mpd.p/src_queue_PlaylistTag.cxx.o
mpd.p/src_queue_PlaylistState.cxx.o mpd.p/src_LocateUri.cxx.o
mpd.p/src_SongUpdate.cxx.o mpd.p/src_SongLoader.cxx.o
mpd.p/src_SongPrint.cxx.o mpd.p/src_SongSave.cxx.o
mpd.p/src_StateFile.cxx.o mpd.p/src_StateFileConfig.cxx.o
mpd.p/src_Stats.cxx.o mpd.p/src_TagPrint.cxx.o mpd.p/src_TagSave.cxx.o
mpd.p/src_TagFile.cxx.o mpd.p/src_TagStream.cxx.o
mpd.p/src_TagAny.cxx.o mpd.p/src_TimePrint.cxx.o
mpd.p/src_mixer_Memento.cxx.o mpd.p/src_PlaylistFile.cxx.o
mpd.p/src_CommandLine.cxx.o mpd.p/src_unix_SignalHandlers.cxx.o
mpd.p/src_unix_Daemon.cxx.o mpd.p/src_storage_StorageState.cxx.o
mpd.p/src_queue_PlaylistUpdate.cxx.o
mpd.p/src_command_StorageCommands.cxx.o
mpd.p/src_command_DatabaseCommands.cxx.o
mpd.p/src_RemoteTagCache.cxx.o mpd.p/src_command_StickerCommands.cxx.o
mpd.p/src_sticker_Database.cxx.o mpd.p/src_sticker_Print.cxx.o
mpd.p/src_sticker_SongSticker.cxx.o mpd.p/src_sticker_TagSticker.cxx.o
mpd.p/src_sticker_AllowedTags.cxx.o
mpd.p/src_sticker_CleanupService.cxx.o
mpd.p/src_command_FingerprintCommands.cxx.o
mpd.p/src_lib_chromaprint_DecoderClient.cxx.o
mpd.p/src_command_NeighborCommands.cxx.o mpd.p/src_TagArchive.cxx.o
mpd.p/src_db_update_Archive.cxx.o -flto -Wl,--as-needed -Wl,--no-
undefined -pie -Wl,-z,relro -Wl,-z,now -Wl,--gc-sections -Wl,-O1,--
sort-common,--as-needed,-z,relro,-z,now -march=x86-64 -mtune=generic
-O2 -pipe -fno-plt -fexceptions -Wp,-D_FORTIFY_SOURCE=2 -Wformat
-Werror=format-security -fstack-clash-protection -fcf-protection
-Wp,-D_GLIBCXX_ASSERTIONS -Wl,--start-group src/cmdline/libcmdline.a
src/lib/fmt/libfmt.a libbasic.a src/config/libfs.a liblog.a
src/fs/libfs.a src/lib/icu/libicu.a src/util/libutil.a
src/fs/glue/libfs_glue.a src/io/libio.a src/io/libio_fs.a
src/lib/dbus/libdbus.a src/event/libevent.a src/io/uring/liburing.a
src/thread/libthread.a src/net/libnet.a src/system/libsystem.a
src/neighbor/libneighbor_glue.a
src/neighbor/plugins/libneighbor_plugins.a src/lib/upnp/libupnp.a
src/lib/curl/libcurl.a src/lib/expat/libexpat.a
src/input/libinput_glue.a src/input/plugins/libinput_plugins.a
src/lib/alsa/libalsa.a src/pcm/libpcm_basic.a
src/lib/ffmpeg/libffmpeg.a src/lib/ffmpeg/libffmpeg_util.a
src/lib/nfs/libnfs.a src/lib/yajl/libyajl.a
src/lib/crypto/libcrypto_md5.a src/input/libinput_api.a
src/pcm/libpcm.a src/tag/libtag.a src/time/libtime.a
src/archive/libarchive_glue.a src/archive/plugins/libarchive_plugins.a
src/archive/libarchive_api.a src/output/liboutput_glue.a
src/output/liboutput_registry.a src/output/plugins/liboutput_plugins.a
src/lib/pipewire/libpipewire.a src/lib/pulse/libpulse.a
src/output/liboutput_api.a src/filter/plugins/libfilter_plugins.a
src/filter/libfilter_api.a src/mixer/plugins/libmixer_plugins.a
src/mixer/libmixer_api.a src/zeroconf/libzeroconf_bonjour.a
src/zeroconf/avahi/libavahi.a src/filter/libfilter_glue.a
src/mixer/libmixer_glue.a src/decoder/libdecoder_glue.a
src/decoder/plugins/libdecoder_plugins.a src/lib/xiph/libflac.a
src/lib/xiph/libxiph.a src/lib/xiph/libvorbis.a src/lib/xiph/libogg.a
src/lib/crypto/libcrypto_base64.a src/decoder/libdecoder_api.a
src/encoder/libencoder_glue.a src/encoder/plugins/libencoder_plugins.a
src/playlist/libplaylist_glue.a
src/playlist/plugins/libplaylist_plugins.a
src/playlist/libplaylist_api.a src/db/libdb_glue.a
src/db/plugins/libdb_plugins.a src/lib/pcre/libpcre.a
src/lib/zlib/libzlib.a src/db/libdb_api.a src/storage/libstorage_api.a
src/storage/libstorage_glue.a src/storage/plugins/libstorage_plugins.a
src/song/libsong.a src/lib/systemd/libsystemd.a
src/lib/sqlite/libsqlite.a /usr/lib/libdbus-1.so /usr/lib/libfmt.so
/usr/lib/liburing.so /usr/lib/libavutil.so /usr/lib/libavformat.so
/usr/lib/libavcodec.so /usr/lib/libavfilter.so /usr/lib/libpcre2-8.so
/usr/lib/libsqlite3.so /usr/lib/libchromaprint.so
/usr/lib/libicui18n.so /usr/lib/libicuuc.so /usr/lib/libicudata.so
-pthread /usr/lib/libupnp.so /usr/lib/libixml.so /usr/lib/libcurl.so
/usr/lib/libexpat.so /usr/lib/libcdio_paranoia.so
/usr/lib/libcdio_cdda.so /usr/lib/libcdio.so -lm /usr/lib/libmms.so
/usr/lib/libnfs.so /usr/lib/libyajl.so /usr/lib/libasound.so
/usr/lib/libsamplerate.so /usr/lib/libsoxr.so /usr/lib/libid3tag.so
/usr/lib/libz.so -lbz2 /usr/lib/libiso9660.so /usr/lib/libzzip.so
/usr/lib/libao.so /usr/lib/libjack.so /usr/lib/libpipewire-0.3.so
/usr/lib/libpulse.so /usr/lib/libshout.so /usr/lib/libopenal.so
/usr/lib/libavahi-common.so /usr/lib/libavahi-client.so
/usr/lib/libFLAC.so /usr/lib/libfluidsynth.so /usr/lib/libaudiofile.so
-lfaad /usr/lib/libgme.so -lmad /usr/lib/libmikmod.so
/usr/lib/libmodplug.so -lmpcdec /usr/lib/libmpg123.so
/usr/lib/libopus.so /usr/lib/libsidplayfp.so -fopenmp
/usr/lib/libsndfile.so /usr/lib/libogg.so /usr/lib/libvorbis.so
/usr/lib/libwavpack.so /usr/lib/libWildMidi.so
/usr/lib/libvorbisenc.so -lmp3lame /usr/lib/libtwolame.so
/usr/lib/libmpdclient.so /usr/lib/libsystemd.so -Wl,--end-group
In member function ‘__ct ’,
inlined from ‘__ct ’ at ../src/util/AllocatedString.hxx:159:30,
inlined from ‘soundcloud_resolve’ at
../src/playlist/plugins/SoundCloudPlaylistPlugin.cxx:56:29,
inlined from ‘TranslateSoundCloudUri’ at
../src/playlist/plugins/SoundCloudPlaylistPlugin.cxx:102:32,
inlined from ‘soundcloud_open_uri’ at
../src/playlist/plugins/SoundCloudPlaylistPlugin.cxx:261:37:
../src/util/AllocatedString.hxx:58:20: warning: writing 1 byte into a
region of size 0 [-Wstringop-overflow=]
58 | *p = SENTINEL;
| ^
../src/util/AllocatedString.hxx:53:24: note: at offset
[-9223372036854775808, -1] into destination object of size [9,
9223372036854775807] allocated by ‘operator new []’
53 | :value(new value_type[TotalSize(src) + 1])
| ^
/usr/bin/ld: warning: libvmaf.so.1, needed by /usr/lib/libavfilter.so,
not found (try using -rpath or -rpath-link)
/usr/bin/ld: /usr/lib/libavfilter.so: undefined reference to
`vmaf_model_destroy'
/usr/bin/ld: /usr/lib/libavfilter.so: undefined reference to
`vmaf_close'
/usr/bin/ld: /usr/lib/libavfilter.so: undefined reference to
`vmaf_feature_dictionary_set'
/usr/bin/ld: /usr/lib/libavfilter.so: undefined reference to
`vmaf_init'
/usr/bin/ld: /usr/lib/libavfilter.so: undefined reference to
`vmaf_model_feature_overload'
/usr/bin/ld: /usr/lib/libavfilter.so: undefined reference to
`vmaf_picture_unref'
/usr/bin/ld: /usr/lib/libavfilter.so: undefined reference to
`vmaf_write_output'
/usr/bin/ld: /usr/lib/libavfilter.so: undefined reference to
`vmaf_score_pooled'
/usr/bin/ld: /usr/lib/libavfilter.so: undefined reference to
`vmaf_read_pictures'
/usr/bin/ld: /usr/lib/libavfilter.so: undefined reference to
`vmaf_model_load'
/usr/bin/ld: /usr/lib/libavfilter.so: undefined reference to
`vmaf_model_load_from_path'
/usr/bin/ld: /usr/lib/libavfilter.so: undefined reference to
`vmaf_use_features_from_model'
/usr/bin/ld: /usr/lib/libavfilter.so: undefined reference to
`vmaf_picture_alloc'
/usr/bin/ld: /usr/lib/libavfilter.so: undefined reference to
`vmaf_use_feature'
collect2: error: ld returned 1 exit status
ninja: build stopped: subcommand failed.
==> ERROR: A failure occurred in build().
Aborting...
error: failed to build 'mpd-git-0.23.13.792.gba2df05fb-2':
error: packages failed to build: mpd-git-0.23.13.792.gba2df05fb-2
[1] https://aur.archlinux.org/account/mackel/
[2] https://aur.archlinux.org/pkgbase/mpd-git/
1 year, 11 months