September 2021 - Aur-general - lists.archlinux.org

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(a)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

[aur-general] AUR Cleanup Day September 20th 2021
by Daniel M. Capella 17 Sep '21

17 Sep '21

Our requests system has been running awfully smoothly lately; luckily our bi-yearly AUR Cleanup Day is here to shake things up! This year it lands on this coming Monday, but as usual, feel free to start as soon as you like. See the AUR Cleanup Day wiki article[1] for details, and/or jump right in to the collaborative doc for this year's event[2]. IRC and Matrix users can chat and ask questions in #archlinux-aur on Libera.Chat. PS: Previously the wiki article was an option for collaboration. It's now locked down and will probably be made static, with an about section and a link to the template[3] for the collaborative doc. [1]: https://wiki.archlinux.org/title/DeveloperWiki:AUR_Cleanup_Day [2]: https://md.archlinux.org/amew_bGZSyySAHsQKig3AQ?both [3]: https://md.archlinux.org/pFMvWHrSRYi3buy3nBjFkA -- Best, Daniel<https://danielcapella.com>

3 3

Re: [aur-general] [aur-requests] [PRQ#28202] Deletion Request for obsidian-insider
by Alexander Epaneshnikov 16 Sep '21

16 Sep '21

On Thu, Sep 16, 2021 at 04:31:11AM +0000, notify--- via aur-requests wrote: > lishid [1] filed a deletion request for obsidian-insider [2]: > > Duplicate of https://aur.archlinux.org/packages/obsidian > > Also hotlinking of insider builds are illegal by the software's > license. I have already rejected PRQ # 28198 on the grounds that aur does not distribute any illegal content. maybe someone has other suggestions? > [1] https://aur.archlinux.org/account/lishid/ > [2] https://aur.archlinux.org/pkgbase/obsidian-insider/ -- Sincerely, Alexander | Trusted User

1 0

Re: [aur-general] Why were my packages gtkwrite, gtkwrite-git, and gtkate deleted from AUR? (Tinu Weber)
by John Briggs 14 Sep '21

14 Sep '21

On Tue, Sep 14, 2021 at 07:15:13AM +0000, zoorat via aur-general wrote: > Hi Tinu, > > In the last mail, I tried to explain the reasons behind my deletion request message, > where I should have sent this one. sorry. > 1. when I tried to build with default, it failed. > > 2. I changed "gtksourceview2" to "gtksourceview3" and "gtksourceview4", build failed. --------------cut-------------------------- Today I downloaded the git repository for gtkwrite. I followed the instructions in the README.md and compiled and generated gtkedit. I inspected my include directory for the gtksourceview* directories and found that I had both gtksourceview-3 and gtksourceview-4 installed. I suspected that I also could have installed gtksourceview-5 from AUR if I had wanted. As per the README.md file: $ make clean $ make with=-DWGTKSOURCEVIEW-4 and generated the gtkwrite executable. I did not install the program because I was not familiar with the PKGBUILD file. Because this package has been withdrawn I do not know how this will build against the PKGBUILD file. I suspect PKGBUILD will need to be modified. John

1 0