Re: Dropping some packages
On 9/3/22 23:00, Filipe Laíns wrote: python-libcst This one is still in the reverse dependency tree of hypothesis. I'll take a look if no one else wanted to take it. python-litedram python-liteeth python-liteiclink python-litejesd204b python-litepcie python-litesata python-litescope python-litesdcard python-litex python-litex-boards I have adopted the litex family. -- Regards, Felix Yan OpenPGP_signature Description: OpenPGP digital signature
Experimental RISC-V port
Hi, As you may or may not have noticed, I have started an unofficial RISC-V port attempt targeting 64-bit RISC-V ISA (riscv64gc) since 2019. There is a simple intro page currently hosted at: https://archriscv.felixc.at/ In the past year, we have a boost in progress and currently ~87.5% of Arch x86_64 packages are available in the riscv64 repository. IMHO The current patch amount is still too high to consider adding riscv64 as an official supported architecture, but we are trying hard on upstreaming them. Yesterday I noticed that Manjaro has imported packages from this port and formed a Manjaro RISC-V port. Their repository is now available at https://repo-riscv.manjaro.org/ This reminds me that we should probably make the port more visible to get more hands on it. Would you consider adding a subdomain at pkgbuild.com or archlinux.org? -- Regards, Felix Yan OpenPGP_signature Description: OpenPGP digital signature
Re: Experimental RISC-V port
On 9/12/22 18:39, Jelle van der Waa wrote: This reminds me that we should probably make the port more visible to get more hands on it. Would you consider adding a subdomain at pkgbuild.com or archlinux.org? I'm all for mirroring it (we also already mirror arch32). But would love to see some more information, iirc you have a Github repository with the PKGBUILD's but only for overrides? And how can users contribute in adding packages to the port etc.. Yes, the repository mostly hosts patches on top of Arch PKGBUILDs (minus the arch=(riscv64) change, to avoid unnecessary conflicts). Except for the blacklisted packages (mostly binary blobs without riscv support or drivers/firmwares for x86-only devices), everything not on the status page is already at the same version as Arch x86_64. I went for the patch repository route way because, this way size of the repository is a direct reflect of the added maintenance burden whenever we want to re-evaluate whether to bring this architecture to an officially supported state. For the documentation/contributing guide part, I wanted to link to the repo's GitHub wiki but ... it turns out since the new members are mostly Chinese speaking, the newly added guides are in need of translation. This will be fixed soon! For the time being, there is an English guide about the basic environment setup part: https://github.com/felixonmars/archriscv-packages/wiki/Setup-Arch-Linux-RISC-V-Development-Environment -- Regards, Felix Yan OpenPGP_signature Description: OpenPGP digital signature
Re: Experimental RISC-V port
On 9/13/22 14:25, Evangelos Foutras wrote: Created a GeoIP-based mirror at https://riscv.mirror.pkgbuild.com/. Thanks, works great here. A basic contributing guide is also available now at: https://github.com/felixonmars/archriscv-packages/wiki/Contributing-Guide -- Regards, Felix Yan OpenPGP_signature Description: OpenPGP digital signature
Re: [arch-dev-public] openssl 3.0
On 9/20/22 11:23, Andreas Radke wrote: What's the status? Can we start the actual move and rebuilds? There should be enough work done by other distributions to fix major issues. We'are already late at that party. Yes. According to https://github.com/loqs/PACKAGES-OSSL3 all packages are either okay or fixable at this point. As there's no huge rebuilds now taking place in staging repos, I think we should push the new packages to [staging] and start the work now. @Pierre I think we have a buildbot infrastructure as well as foutrelis' rebuilder which is capable of handling most of the dependency ordering issues. It would also be great if you would join IRC for better coordination. -- Regards, Felix Yan OpenPGP_signature Description: OpenPGP digital signature
Bash 5.2 removed from [testing]
Hello, I was informed that a new feature (patsub_replacement) is enabled by default in the new release, which breaks makepkg. bash 5.2.0-1 is now removed from [testing] until this is fixed. -- Regards, Felix Yan OpenPGP_signature Description: OpenPGP digital signature
python-packaging 22.0 removed from [testing]
Hi all, python-packaging 22.0 was removed from [testing] due to incompatibility with setuptools [1]. [1] https://github.com/pypa/setuptools/discussions/3722 -- Regards, Felix Yan OpenPGP_signature Description: OpenPGP digital signature
Re: Python 3.11 in [staging]
On 4/29/23 14:13, David Runge wrote: On 2023-04-06 14:30:25 (+0200), Jelle van der Waa wrote: Early Easter suprise, After some delay Python 3.11 rebuilds are happening in [staging], so please don't start any rebuild. Thanks to felixonmars for starting and rebuilding! Thanks, Jelle van der Waa Just a short heads up to all package maintainers: Please refrain from using staging and/or testing atm, as we are running into some issues while moving the packages. There will be an update to this once the move is complete. The move is now done and everything should have been fixed. Have fun breaking something new :) -- Regards, Felix Yan OpenPGP_signature Description: OpenPGP digital signature
NEWS DRAFT: OpenBLAS >= 0.3.23-2 update requires manual intervention
The openblas package prior to version 0.3.23-2 doesn't ship optimized LAPACK routine and CBLAS/LAPACKE interfaces for compatibility. This decision has been reverted now, and the ability to choose a different default system BLAS/LAPACK implementation while keeping openblas installed is now provided to allow future co-installation of BLIS, ATLAS, etc. The default BLAS implementation will be used for most packages like NumPy or R. Please install "blas-openblas" and "blas64-openblas" to make OpenBLAS the default BLAS implementation, just like the old behavior. Unfortunately you will get errors on updating if you currently have OpenBLAS installed as the default BLAS implementation: error: failed to prepare transaction (could not satisfy dependencies) :: installing openblas (0.3.23-2) breaks dependency 'blas' required by cblas :: installing openblas (0.3.23-2) breaks dependency 'blas' required by lapack Please append your preferred default BLAS implementation to the regular -Syu command line to get around it. For example: # pacman -Syu blas-openblas or # pacman -Syu blas -- Regards, Felix Yan OpenPGP_signature Description: OpenPGP digital signature
News Draft: ppp >= 2.5.0-1 update may require manual intervention
As you may or may not have noticed, both `ppp` and `rp-pppoe` package used to ship a `rp-pppoe.so` and they are not 100% compatible. Back in 2021, ppp 2.4.9 starts to rename its own copy of `rp-pppoe.so` to `pppoe.so`. As of `ppp 2.5.0`, upstream decided to remove the `rp-pppoe.so` symlink and thus broke configurations with the old name. If you still have the old ppp package's `rp-pppoe.so` configured somewhere (likely in /etc/ppp/peers/), please update it to use just `pppoe.so`. Configurations with the same plugin from the `rp-pppoe` package (using full path like /usr/lib/rp-pppoe/rp-pppoe.so) are not affected. -- Regards, Felix Yan OpenPGP_signature.asc Description: OpenPGP digital signature
Re: News Draft: ppp >= 2.5.0-1 update may require manual intervention
On 9/13/23 22:53, Justin Kromlinger wrote: I had no idea what this even was, and the description isn't making it any better - 'A daemon which implements the Point-to-Point Protocol for dial-up networking'. How many users are gonna be affected by this? Maybe it makes sense to list (transitive) deps that are affected by this change. Mostly affects only people having ppp configured themselves. Other packages should fix themselves if they hit this. On 9/14/23 00:42, Jan Alexander Steffens (heftig) wrote: > Bare PPP seems obscure enough a post_upgrade message might be sufficient? > I've only ever used PPP with NetworkManager, which handles this already. Multiple people are hitting this and had to travel across cities to get this fixed. Well I'm also fine with only a post_upgrade message. -- Regards, Felix Yan OpenPGP_signature.asc Description: OpenPGP digital signature
Stepping down as Python maintainer
Hello, For the past ten years (and several days) I have been the guy maintaining Python itself and some libraries in Arch. It's been a long journey and I learned a lot from it. I was a web back-end developer back then, and I used Arch as the base OS of our company's servers and system-wide Python packages as the runtime. The server and website are still running today, but I am no longer developing Python very frequently these days. Plus, Python's type-hinting has been a headache for me for years and lowered my interest in contributing to upstream projects a lot. In the past, the large cross-minor-version Python rebuilds were done with either Evangelos' rebuilder or my own island solution. I understand Arch's striving to improve bus factor and formalizing process, so I am making room for others to try on the 3.11 and 3.12 rebuilds. As Jelle has progressed a lot now, I feel it's approaching the right time for me to step down as the Python maintainer. I will be disowning many of my no longer used Python module packages in the following days, so that they could find a better maintainer either in the Arch team, or later in the AUR if they are going to be dropped. Please also consider adopting the main python package and let me know :) -- Regards, Felix Yan OpenPGP_signature.asc Description: OpenPGP digital signature
GHC 9.2.8 enters [extra-testing]
Hi all, The long delayed GHC 9.2.x updates have been done and moved to [extra-testing]. There are a few notable changes regarding our GHC packaging: - Codegen backend has been switched back to NCG for multiple reasons: = GHC doesn't support latest LLVM and was using llvm14 in Arch. This adds up to our maintenance burden of LLVM. (IIRC LLVM 15 support was fixed only recently.) = LLVM backend actually generates slower code. We have evaluated the changes during the past years and noticed as large as 50% slower results in some benchmarks. I also got similar information from other distribution people. = LLVM backend sometimes deadlocks on compile-time. I hit this from time to time and it's not easy to reproduce reliably. (There are similar issues that are always reproducible, but got fixed already.) All `--ghc-option=-fllvm` has been removed from PKGBUILDs during the rebuild. - Build system of GHC itself has been switched to Hadrian. - Some obsolete packages have been retired from the distribution, and will be removed once the batch enters [extra]: haskell-bytestring-show haskell-random-source haskell-brittany haskell-hls-brittany-plugin haskell-hls-tactics-plugin haskell-hls-haddock-comments-plugin A lot of thanks to @Vekhir who helped me a lot for preparing this so that it's done much earlier and smoother than I expected :) As always, please report any issues and have fun! -- Regards, Felix Yan OpenPGP_signature.asc Description: OpenPGP digital signature
Deprecating Fcitx 4.x
Hello, It appears all upstream repositories for Fcitx 4 have been archived since May. This indicates that the framework is no longer being developed or supported by upstream. I will not remove all Fcitx 4.x packages from Arch repositories now, but I encourage everyone to try out Fcitx 5.x and migrate your configuration. Fcitx upstream provides a migration guide at: https://fcitx-im.org/wiki/Upgrade_from_Fcitx_4 -- Regards, Felix Yan OpenPGP_signature.asc Description: OpenPGP digital signature
GHC 9.4.8 enters [extra-testing]
Hi all, The long delayed GHC 9.4.x updates have been done and moved to [extra-testing]. Two obsolete packages were retired from the distribution. If you still have them installed, please consider removing them: - haskell-configurator - haskell-critbit Many thanks again to @Vekhir who helped me a lot for preparing this batch and many previous batches of Haskell updates. As always, please report any issues and have fun! -- Regards, Felix Yan OpenPGP_signature.asc Description: OpenPGP digital signature
Re: Spring cleanup '25
On 3/24/25 21:07, m...@sergej.pp.ru wrote: On 3/24/25 3:22 PM, nl6720 wrote: rp-pppoe As I understand dropping PPPoE support is bad idea while ADSL modems exist. I adopted it. Hi, FYI that the ppp package already contains a (Linux-only) PPPoE client plugin, which is enough for most users. They shared the same "rp-pppoe" name before, which was corrected in 2021 (https://github.com/ppp-project/ppp/commit/b2c36e6c0e1655aea9b1b0a03a8160f42a26c884). The rp-pppoe package provides additional PPPoE relay/server implementation (and supports user-mode pppoe which makes it work for BSD/Solaris). -- Regards, Felix Yan OpenPGP_signature.asc Description: OpenPGP digital signature
Re: [arch-dev-public] Goodbye
On Thu, 21 Jan 2021 14:08:11 +0100 Bartłomiej Piotrowski via arch-dev-public wrote: > Hi everyone, > > I'm stepping down as a developer. It's been mostly fantastic ride for > the last 10 years but it's clear to me now that for better or worse > it's far from the project I initially joined. > > Thank you and good luck with everything, > Bart Hi Bart Sad to see you go and thank you for all your work, especially bringing me onboard as a TU. Arch means a lot to me after all these years. Wszystkiego najlepszego! -- Regards, Felix Yan pgpHKFBpmtHmO.pgp Description: OpenPGP digital signature
Re: [arch-dev-public] Spring cleanup '21
On Thursday, April 29, 2021 12:16:48 AM CST Antonio Rojas via arch-dev- public wrote: >It's been over a year since our last package cleanup and orphans keep >piling up. Please head to >https://archlinux.org/devel/reports/unneeded-orphans/ and adopt >packages you'd like to keep in the repos. I have adopted privoxy. Thanks for taking care of this. -- Regards, Felix Yan signature.asc Description: This is a digitally signed message part.
[arch-dev-public] Deprecating systemd-swap
As per suggested by upstream [1], systemd-swap is now deprecated and will be removed from [community] in the following days. zram-generator has been added to [community] as the suggested alternative. [1] https://github.com/Nefelim4ag/systemd-swap#users-should-migrate-to-systemdzram-generator-since-zram-should-be-enough-in-most-systems -- Regards, Felix Yan signature.asc Description: This is a digitally signed message part.
[arch-dev-public] Disowning ruby packages
Hi All, I am disowning most of my ruby packages since I don't use any of them nowadays. Please consider adopting the following ones as they are now orphans: ruby-cairo ruby-faraday-middleware ruby-ffi ruby-multi_json ruby-power_assert ruby-test-unit -- Regards, Felix Yan signature.asc Description: This is a digitally signed message part.
Re: [arch-dev-public] Starting x86_64_v3 port
On 1/29/22 02:12, Allan McRae via arch-dev-public wrote: The decision to be made is who will package for this repo? I think these are the options: A) packagers upload both x86_64 and x86_64_v3 to the repos. Our build server will help those without x86_64_v3 machines. B) we recruit some packagers to build the x86_64_v3 packages. C) Some combination of A+B. My understanding is our x86_64 port started with B, then C, then A. I am fine with either and could happily help with B in long term. For me the issue with either B or C is that our packages are often FTBFS and we are slow to fix them, generally. To make the port really usable for a B/C workflow, we need a way to fill in the time gap (because the old package could be unusable for the time, like missing a so-name bump etc). Do you find it acceptable if the x86_64_v3 rebuilders put back in the new x86_64 package until the build was fixed and probably a point pkgrel was added for the real x86_64_v3 rebuild, as long as we use B/C to build for x86_64_v3, in the long term? -- Regards, Felix Yan OpenPGP_signature Description: OpenPGP digital signature
Re: [arch-dev-public] [RFC] archweb nvchecker integration
On 2/2/22 19:59, Anatol Pomozov via arch-dev-public wrote: And here is one more tool to check if package version is of out-of-date https://github.com/anatol/pkgoutofdate It is a pretty simple tool that does not require any modification to Arch repo. It simply tries to guess what is the next possible version and then checks the upstream download site for it. The drawback is that it does not handle slotted packages and projects that do not use semver release numbering. According to my past experience with it, there is an important additional drawback: it often detects pre-releases and broken (withdrawn) releases (as marked in a web page, github releases, or the corresponding repository) and the mechanism has no way to tell about this. I am also a regular user of this tool but unfortunately I don't think it's a good idea to use as the main tool. It's a nice addition to my nvchecker config to occasionally check the consistency among different upstream sources (like new version in PyPI but there is no corresponding git tag, or maybe the PyPI package has been moved to a different repository, etc). I think it would still be better to be explicit here. The maintainer should decide about which source to use. -- Regards, Felix Yan OpenPGP_signature Description: OpenPGP digital signature
Re: [arch-dev-public] [RFC] archweb nvchecker integration
On 2/1/22 22:54, George Rawlinson via arch-dev-public wrote: On 22-02-01 08:21, Morten Linderud via arch-dev-public wrote: At this stage, the following [community] packages that I maintain require massaging of HTML sources: * html-xml-utils * oil * parallel * libmilter (bundled with sendmail source) * time I suppose if a nvchecker plugin existed that utilised bs4 (beautiful soup), that would work. But I assume that would still fit your definition of "arbitrary script". :p There is a regex plugin and a htmlparser plugin for this. The htmlparser plugin accepts XPath, but if you want to process it further the regex plugin may just work better. Examples for your packages: [html-xml-utils] source = "regex" url = "https://www.w3.org/Tools/HTML-XML-utils/"; regex = "html-xml-utils-(.*?).tar.gz" [oil] source = "htmlparser" url = "https://www.oilshell.org/release/latest/"; xpath = "//h1/text()" prefix = "Oil " -- Regards, Felix Yan OpenPGP_signature Description: OpenPGP digital signature
[arch-dev-public] Disowning some packages
Hi, I am disowning the following packages as an attempt to shorten my TODO and focus on packages I still use. certbot certbot-apache certbot-dns-cloudflare certbot-dns-cloudxns certbot-dns-digitalocean certbot-dns-dnsimple certbot-dns-dnsmadeeasy certbot-dns-gehirn certbot-dns-google certbot-dns-linode certbot-dns-luadns certbot-dns-nsone certbot-dns-ovh certbot-dns-rfc2136 certbot-dns-route53 certbot-dns-sakuracloud certbot-nginx dart python-acme python-jaraco.envs python-pkginfo python-readme-renderer python-sqlalchemy python-telegram-bot python-tqdm ruby-bundler treefrog-framework twine Please consider adopting what you or your packages use. Thanks. -- Regards, Felix Yan OpenPGP_signature Description: OpenPGP digital signature
