- Aur-general - lists.archlinux.org

Re: [aur-general] Duplicate yt-dlp packages
by Maxwell G 11 Oct '21

11 Oct '21

Oct 10, 2021 4:19:07 PM Alexandre Mendes <reversebob(a)gmail.com>: > Hello, > > This package was my first package ever created, and I used a script to do it, but have been informed the convention is not respected (python- should apparently be for libraries). > Anyway, my package needs to disappear. > Should I delete it myself ? What exactly is the correct process ? > > > > On Sun, 10 Oct 2021 at 22:41, Maxwell Gottlieb <gotmax(a)e.email> wrote: >> Hi everyone, >> >> I hope you are having a good weekend! >> >> There are several duplicate packages for yt-dlp[1] available on the AUR. >> There are two regular packages (yt-dlp and youtube-dlp), as well as two >> Git packages (yt-dlp-git and python-yt-dlp-git). I think we should keep >> yt-dlp and yt-dlp-git, because they are the most popular, but I wanted >> to ask before creating any deletion requests. >> >> I have CC'd the maintainers of the aforementioned packages. >> >> Thanks, >> Maxwell >> >> [1]: https://github.com/yt-dlp/yt-dlp >> >> -- >> Maxwell G (@gotmax23) >> Pronouns: He/Him/His >> gotmax(a)e.email Hi Alexandre, I'm not sure what the process of deleting packages looks like. One of the Trusted Users can chime in on that. Please make sure that you reply to the entire mailing list and not just me. I think you have to subscribe[1] to the mailing list before posting. Thanks, Maxwell [1]: https://lists.archlinux.org/listinfo/aur-general -- Maxwell G Pronouns: He/Him/His gotmax(a)e.email

2 1

[aur-general] Duplicate yt-dlp packages
by Maxwell Gottlieb 10 Oct '21

10 Oct '21

Hi everyone, I hope you are having a good weekend! There are several duplicate packages for yt-dlp[1] available on the AUR. There are two regular packages (yt-dlp and youtube-dlp), as well as two Git packages (yt-dlp-git and python-yt-dlp-git). I think we should keep yt-dlp and yt-dlp-git, because they are the most popular, but I wanted to ask before creating any deletion requests. I have CC'd the maintainers of the aforementioned packages. Thanks, Maxwell [1]: https://github.com/yt-dlp/yt-dlp -- Maxwell G (@gotmax23) Pronouns: He/Him/His gotmax(a)e.email

1 0

[aur-general] poe-git maintainership
by Strahinya Radich 07 Oct '21

07 Oct '21

Hi, I am the author of the program poe (https://sr.ht/~strahinja/poe) When I wanted to create an AUR package for my program, I found out that someone (with the username fossdd) already made a package for my program, called poe-git. The version of the package in the AUR, however, is 0.1.alpha.r11.g4a843ea-1 and I've moved on to v1.3.3. Granted, when poe-git is installed through an AUR helper, the latest source is pulled, but the PKGBUILD doesn't use the intended command for the installation (which is now PREFIX=... ./do install, I've added respecting the PREFIX environment variable), but instead uses the install(1) program manually, so the manpage isn't installed. I would be fine with fossdd maintaining poe-git AUR package if it is kept up-to-date, but I would prefer maintaining it myself. I tried contacting fossdd today early in the morning about this, but got no response yet. I would appreciate an advice on this.

5 6

Re: [aur-general] Not receiving password reset emails for new account
by Ken Taylor 27 Sep '21

27 Sep '21

I am having the same problem as jake. New account, email is correct (won't let me create another one with the same email address -- taylork(a)alum.mit.edu) Have tried reset password for a couple days and no emails. Thanks, -Ken On Sat, Sep 25, 2021 at 6:25 PM Jake Barnes <me(a)jakebarn.es> wrote: > > Hi, > > Last week I tried creating the account `vivi` for automating releases of our package (also `vivi`), instead of using my personal account `DuBistKomisch`. The email address should be `devops at vivi.io`, which is a shared mailbox on my company's Office 365. I didn't receive the initial password reset after registration, nor any requested from the password reset page. > > If I made a typo in the email, could it please be corrected? Otherwise, please advise anything else I can do here. > > Thanks, Jake

4 3

[aur-general] Special removal of inactive Trusted User Brad Fanella (cesura)
by David Runge 24 Sep '21

24 Sep '21

Hi all, I would like to raise the special removal [1] of the Trusted User Brad Fanella (cesura) due to inactivity. * last vote: 124 * last AUR login: 2020-11-08 * last action: 2020-08-19 13:33 * the user has no packages in the official repositories I have tried to reach out to Brad via e-mail on 2021-08-10 granting a three week grace period (which has now passed by more than a week), but did not receive a reply. After a three day discussion period I will start a vote. Best, David [1] https://gitlab.archlinux.org/archlinux/tu-bylaws/-/blob/master/tu-bylaws.ad… -- https://sleepmap.de

2 3

[aur-general] Question about AUR submission rules
by networkException 23 Sep '21

23 Sep '21

Hello, I maintain the ungoogled-chromium packaging for Arch Linux as an officially supported platform. As a quick overview, ungoogled-chromium is a set of patches that aims to remove all dependencies on Google services from Chromium. Compiling Chromium is a quite resource and time intensive task, which is why I use both Open Build Service and GitHub Actions for offering binary releases. As the packing is Arch Linux specific, both build systems produce a package archive for pacman. A highly requested feature by users is to offer such a binary release in the AUR as it is more convenient for them compared to adding a custom repository for example. In the past there were already ungoogled-chromium-bin packages in the AUR, usually submitted by people not affiliated with the project and removed for some reason at some point in time. The most recent one would download a pacman package from an OBS repository and install it by extracting files manually. In the delete request removing this last package (#19142) it was stated that "the AUR is not intended to provide an index for PKGBUILDs that repackage the build package originally created by another PKGBUILD". While I understand that the AUR would want to avoid to just include repackaged entries like that, I am now wondering what the best way to offer a binary package in the AUR would be in my situation. Building Chromium separately into a non makepkg archive just for the AUR on GitHub Actions for example seems wasteful and would defeat the way package checksums are currently handled, as such making it harder for end users to quickly verify that the binary an AUR helper for example would download is legitimate. I tried looking for a rule that explicitly states the mentioned repackaging restrictions, but I was unable to find one. I have also found another AUR package which is normally available that repackages a pkg.tar.zst (codelite-bin). Thank your for taking the time to reading, I hope it will be possible to find a way to submit ungoogled-chromium-bin properly. Kind regards, networkException

3 4

[aur-general] Not receiving password reset emails for new account
by Jake Barnes 23 Sep '21

23 Sep '21

Hi, Last week I tried creating the account `vivi` for automating releases of our package (also `vivi`), instead of using my personal account `DuBistKomisch`. The email address should be `devops@vivi.io`, which is a shared mailbox on my company's Office 365. I didn't receive the initial password reset after registration, nor any requested from the password reset page. If I made a typo in the email, could it please be corrected? Otherwise, please advise anything else I can do here. Thanks, Jake

1 0

[aur-general] [neard] neard release v0.17
by Krzysztof Kozlowski 22 Sep '21

22 Sep '21

Hi all, v0.17 ===== After quiet period, the neard user-space counterpart of Linux kernel NFC stack, gets a new release - v0.17. The release includes several fixes (including potential security fixes) and improvements, plus few new features. Source code release: https://git.kernel.org/pub/scm/network/nfc/neard.git/tag/?h=v0.17 https://git.kernel.org/pub/scm/network/nfc/neard.git/snapshot/neard-0.17.ta… Few notes on new names and maintainers ====================================== The neard package was previously maintained Samuel Ortiz and Marcel Holtmann, which were also main contributors. Last years Mark Greer was looking after neard. I joined in 2021, both as a maintainer of Linux kernel NFC stack and the neard. The project development still happens via linux-nfc mailing list but also got a second home on GitHub: https://github.com/linux-nfc/neard Under GitHub I set up also Continuous Integration: https://github.com/linux-nfc/neard/actions Feel free join and hack via both channels. Best regards, Krzysztof

1 0

[aur-general] RPC v1-v4 Deprecation Notice
by Kevin Morris 20 Sep '21

20 Sep '21

Hello AUR users, With the advent of FastAPI aurweb development, we've done some reviewing of the RPC API. With each increasing version to the RPC, it has become quite a heavy component of aurweb to maintain in complete back-compatibility mode for legacy RPC version users. These legacy versions reduce flexibility in the implementation and there are several bugs with the legacy versions which will not be addressed in favor of moving forward and focusing on the current highest version: 5 and future unreleased versions. For these reasons, we have decided to deprecate the following RPC versions: - 1 - 2 - 3 - 4 Undeprecated versions: - 5 A deprecation warning has been patched into the RPC soon for all requests which use a version less than 5. This notice will be shown to users under the "warning" key of JSON output for a minimum of one month before true deprecation occurs: The use of versions lower than 5 is now deprecated and will soon be unsupported. To ensure your API client supports the change without issue, it should use version 5 and adjust for any changes in the API interface. See https://aur.archlinux.org/rpc for documentation related to v5. After one month has passed (from now), the RPC API should be seen to only support v5. Users should update their code to use v5 before this time to avoid any imminent client breakage. See https://aur.archlinux.org/rpc for documentation on working with version 5. NOTE: Upcoming changes which completely remove v1-4 from operation will require your clients to supply a valid `v` query argument. Currently, this defaults to version 1, and that will change with the completion of the deprecation. A changelog will be posted to aur-general regarding RPC when this occurs, but this is a bit of forewarning so that users may prepare without issues. Example: https://aur.archlinux.org/rpc?v=5&type=multiinfo&arg[]=package We thank you all for your understanding and look forward to improving the API in future versions (v6) which development will have begun after the FastAPI initial port is complete. We'd like to thank you all for your contributions to the AUR; without you, the AUR would simply not be a useful tool. We apologize for any inconvenience this may cause, but we do feel that this is the right direction for the project; especially since we'll be adding more features to the API in the very near future, this allows us to more easily develop and release these additions. Thank you for reading, aurweb Development Team -- Kevin Morris Software Developer Identities: - kevr @ Libera

1 0

[aur-general] Problem downloading a source package with new curl version
by Jan Kohnert 20 Sep '21

20 Sep '21

Hi, one of my aur packages (eccodes) has a problem getting the source package using the new version of curl (7.79.0). The output of the old curl version looks like: ----------------------------------------------------------------------------- jankoh@kohni-mobil ~/projects/eccodes $ curl -v https://confluence.ecmwf.int/ download/attachments/45757960/eccodes-2.23.0-Source.tar.gz?api=v2 * Trying 136.156.180.232:443... * Connected to confluence.ecmwf.int (136.156.180.232) port 443 (#0) * ALPN, offering h2 * ALPN, offering http/1.1 * successfully set certificate verify locations: * CAfile: /etc/ssl/certs/ca-certificates.crt * CApath: none * TLSv1.3 (OUT), TLS handshake, Client hello (1): * TLSv1.3 (IN), TLS handshake, Server hello (2): * TLSv1.2 (IN), TLS handshake, Certificate (11): * TLSv1.2 (IN), TLS handshake, Server key exchange (12): * TLSv1.2 (IN), TLS handshake, Server finished (14): * TLSv1.2 (OUT), TLS handshake, Client key exchange (16): * TLSv1.2 (OUT), TLS change cipher, Change cipher spec (1): * TLSv1.2 (OUT), TLS handshake, Finished (20): * TLSv1.2 (IN), TLS handshake, Finished (20): * SSL connection using TLSv1.2 / ECDHE-RSA-AES128-GCM-SHA256 * ALPN, server did not agree to a protocol * Server certificate: * subject: jurisdictionC=GB; businessCategory=Non-Commercial Entity; serialNumber=ISBN: 9780101820028; C=GB; ST=West Berkshire; L=Reading; O=European Cen tre for Medium-Range Weather Forecasts; CN=confluence.ecmwf.int * start date: Mar 29 16:16:45 2021 GMT * expire date: Mar 29 16:26:00 2022 GMT * subjectAltName: host "confluence.ecmwf.int" matched cert's "confluence.ecmwf.int" * issuer: C=NL; O=QuoVadis Trustlink B.V.; CN=QuoVadis Europe EV SSL CA G1 * SSL certificate verify ok. > GET /download/attachments/45757960/eccodes-2.23.0-Source.tar.gz?api=v2 HTTP/ 1.1 > Host: confluence.ecmwf.int > User-Agent: curl/7.78.0 > Accept: */* > * Mark bundle as not supporting multiuse < HTTP/1.1 200 200 < Date: Sun, 19 Sep 2021 19:48:11 GMT < Server: Apache < Cache-Control: no-cache, must-revalidate < Expires: Thu, 01 Jan 1970 00:00:00 GMT < X-Confluence-Request-Time: 1632080871142 < Set-Cookie: JSESSIONID=659BDBFF1F03F2DC7848A7BEECF3CCC3; Path=/; HttpOnly < Last-Modified: Mon, 19 Jan 1970 20:46:07 GMT < Accept-Ranges: bytes < X-Content-Type-Options: nosniff < Content-Disposition: inline; filename="eccodes-2.23.0-Source.tar.gz" < Content-Type: application/x-gzip;charset=UTF-8 < Content-Length: 12037258 < Strict-Transport-Security: max-age=15552000 < Warning: Binary output can mess up your terminal. Use "--output -" to tell Warning: curl to output it to your terminal anyway, or consider "--output Warning: <FILE>" to save to a file. * Failure writing output to destination * Closing connection 0 * TLSv1.2 (OUT), TLS alert, close notify (256): jankoh@kohni-mobil ~/projects/eccodes $ ----------------------------------------------------------------------------- The new version outputs: ----------------------------------------------------------------------------- jankoh@kohni-mobil ~/projects/eccodes $ curl -v -i https:// confluence.ecmwf.int/download/attachments/45757960/eccodes-2.23.0- Source.tar.gz?api=v2 * Trying 136.156.180.232:443... * Connected to confluence.ecmwf.int (136.156.180.232) port 443 (#0) * ALPN, offering h2 * ALPN, offering http/1.1 * successfully set certificate verify locations: * CAfile: /etc/ssl/certs/ca-certificates.crt * CApath: none * TLSv1.3 (OUT), TLS handshake, Client hello (1): * TLSv1.3 (IN), TLS handshake, Server hello (2): * TLSv1.2 (IN), TLS handshake, Certificate (11): * TLSv1.2 (IN), TLS handshake, Server key exchange (12): * TLSv1.2 (IN), TLS handshake, Server finished (14): * TLSv1.2 (OUT), TLS handshake, Client key exchange (16): * TLSv1.2 (OUT), TLS change cipher, Change cipher spec (1): * TLSv1.2 (OUT), TLS handshake, Finished (20): * TLSv1.2 (IN), TLS handshake, Finished (20): * SSL connection using TLSv1.2 / ECDHE-RSA-AES128-GCM-SHA256 * ALPN, server did not agree to a protocol * Server certificate: * subject: jurisdictionC=GB; businessCategory=Non-Commercial Entity; serialNumber=ISBN: 9780101820028; C=GB; ST=West Berkshire; L=Reading; O=European Centre for Medium-Range Weather Forecasts; CN=confluence.ecmwf.int * start date: Mar 29 16:16:45 2021 GMT * expire date: Mar 29 16:26:00 2022 GMT * subjectAltName: host "confluence.ecmwf.int" matched cert's "confluence.ecmwf.int" * issuer: C=NL; O=QuoVadis Trustlink B.V.; CN=QuoVadis Europe EV SSL CA G1 * SSL certificate verify ok. > GET /download/attachments/45757960/eccodes-2.23.0-Source.tar.gz?api=v2 HTTP/ 1.1 > Host: confluence.ecmwf.int > User-Agent: curl/7.79.0 > Accept: */* > * Unsupported response code in HTTP response * Closing connection 0 * TLSv1.2 (OUT), TLS alert, close notify (256): curl: (1) Unsupported response code in HTTP response jankoh@kohni-mobil ~/projects/eccodes $ ----------------------------------------------------------------------------- I see the response code is 200 200, which has an additional errournous 200. Since the upgrade my automated daily test builds fail, so I'd like to know if I should file a bug report either upstream or the arch bugtracker. I can download the file using chrome or wget, so it might be a workaroud if I could tell makepkg to use wget instead of curl. However, executing ----------------------------------------------------------------------------- sudo sed -i -r "s/(http[s]?::)\/usr\/bin\/curl\ -qgb\ \"\"\ -fLC\ -\ --retry\ 3\ --retry-delay\ 3 -o/\1\/usr\/sbin\/wget\ --no-cookies\ --retry-connrefused\ -t\ 3\ --waitretry\ 3 -O/" /etc/makepkg.conf ----------------------------------------------------------------------------- inside the build container will not help users that upgrade or install the package. I could post the workaround to the packages page, but this will also affect other packages to be build, and wget needs to be installed before that workaround will actually work. Any tips on how to go on? TIA -- MfG Jan

3 5