- Aur-general - lists.archlinux.org

[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 16 Sep '21

16 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

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

14 Sep '21

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. > Was there any comment or anything to let the maintainer know about the issue? Filing a deletion request right away seems a little harsh. sorry about that. From now on, I will let the submitter know first, then submit a deletion request. How long I should wait tho?? > If there *was* an upstream release, why not simply use the "out of date" flag? No. The last commit was on "May 29, 2019" and the last release was on "Feb 26, 2019". > Is there a need to constantly "update" PKGBUILDs? What about software that doesn't see upstream releases very often? I added this part to show "it's kinda dead". Nothing serious. > Of course if there is an issue for over 2 years, that's another thing. But again, was the author previously notified about the issue at all (e.g. via AUR comment)? there was nothing anywhere. no comment, no vote, no out of date. I would have added that comment and out-of-date note, if there was any. ok, let me tell you what I did before submitting the request... 1. when I tried to build with default, it failed. 2. I changed "gtksourceview2" to "gtksourceview3" and "gtksourceview4", build failed. 3. then I went to https://github.com/drankinatty/gtkwrite to try building but the first paragraph said... > A small fast standalone text editor written in C using Gtk+2 and optionally GtkSourceView2 to provide syntax highlighting... you need "gtksourceview". > The editor can be compiled with or without GtkSourceView. Without GtkSourceView it will compile as gtkedit. it's gtkwrite we are talking about. > With GtkSourceView it compiles as gtkwrite (requires GtkSourceView 2.x). and you need "gtksourceview2" and only v2 to build gtkwrite. we need that app's code to be updated or "gtksourceview2" package alive again. after getting no hope of fixing the PKGBUILD, I submit that deletion request. I hope it's not a mistake. ps, what else I should do to avoid wrong requests ?? your's zoorat.

1 0

Re: [aur-general] Why were my packages gtkwrite, gtkwrite-git, and gtkate deleted from AUR?
by zoorat 13 Sep '21

13 Sep '21

Hi David, I'm zoorat. I'm the guy who sent deletion requests to "gtkwrite" and "gtkwrite-git". no clue about "gtkate" tho. The reason for deletion are 1. Missing dependency (gtksourceview2) with that broken dependency, you can't build any of those packages. and I tried by removing the dependency but build will fail. 2.Last Updated: 2019-02-21 00:53. or Last Updated: 2019-02-26 10:41. It's been more than 2 years... If you think I made a mistake please let me know. If you need those packages clone "https://aur.archlinux.org/gtkwrite-git" and "https://aur.archlinux.org/gtkwrite".

3 2