Re: Configure mailing lists to automatically reject mails by non-members
On Thu, Jul 21, 2022 at 08:54:20AM -0700, Brett Cornwall wrote: > On 2022-07-21 10:15, David Runge wrote: > > Hi all, > > > > I'm currently partly moderating mailing lists for Arch Linux. > > Since we've switched to mailman3 I receive *a lot* of info from the > > system, that mails are being held in the moderation queue due to being > > sent by non-members of the respective lists. > > > > IMHO, we should configure all of our mailing lists to be subscription > > only (i.e. automatically reject all mail by non-members). It makes no > > sense for anyone to moderate these emails and is a huge waste of time > > for people dealing with the moderation of the lists (I get enough spam > > everyday as it is... ;-)). > > Sounds reasonable to me. > > > While at it: To my knowledge, we are currently still allowing HTML > > emails to be sent to the lists and I think those should be automatically > > rejected as well, as it is unnecessary bloat and is not fitting our > > context at all (we are not trying to click-track users on a commercial > > info list). > > Kill it! +1 signature.asc Description: PGP signature
Re: Finding a new home for a bunch of my packages
On Tue, Sep 20, 2022 at 08:14:47PM +0200, Pierre Schmitz wrote: > Hi all, > > I have been thinking about refocusing my contributions on Arch. As > Andreas rightfully asked about openssl it's probably best to go ahead. > I have been maintaining a couple of packages simply because they where > orphaned a long time ago. They are all maintained but maybe someone > could be found who is more knowledgeable or is even an active user of > these packages. > > Here is a list of all the packages I care or know less about; just > answer to this list if you like to maintain any of these. > > * archiso, archlinux-keyring, devtools: These already have other > people working on it, so I probably can safely remove myself as > maintainer. > * aspell-de > * imap: This is a dead package and should not be used by anybody. I > just maintain it as dependency of php/c-client. If nobody is > interested I might look into removing it > * grml-zsh-config, hefur, lighttpd, lynx: I am no longer using these packages > * logrotate > * openssl, openssl-1.0, openssl-1.1: An update to Openssl 3.0 is > prepared and packaged. Though I lack the knowledge to fix the packages > depending on it and I do not feel confident to apply random patches. > This is also better handled by someone who knows more about C; > especially about handling different library versions and symbols. > * run-parts > * xz > * zlib: Someone with a deeper knowledge might be advisable as this > needs custom patches due to difficult upstream. Someone might also > consider switching to a more maintained zlib-ng. > * zsh > > I am not orphaning any of these if nobody could be found; ideally > there is someone with a sense of passion for some of these more > important packages. > > Greetings, > > Pierre Thank you for acting on the openssl-3.0 issue. Why don't we push it to [staging] and let the maintainer of the affected packages deal with patching? I don't think you have to do this on your own :) I've adopted zsh and grml-zsh-config. Best regards, Frederik signature.asc Description: PGP signature
Re: db6 license concerns
On Sun, Dec 11, 2022 at 08:46:07PM +0100, Andreas Radke wrote: > I have noticed freswa has bumped BerkeleyDB to > v6 (again) and started pushing rebuilds to staging repo. I've checked every affected package for it's license: 389-ds-base: GPLv3+ https://github.com/389ds/389-ds-base/blob/main/LICENSE.GPLv3%2B apr-util Apache 2.0 https://github.com/apache/apr/blob/trunk/LICENSE bogofilter GPLv2 and v3 mixed https://gitlab.com/bogofilter/bogofilter/-/blob/main/bogofilter/COPYING dsniff BSD https://github.com/tecknicaltom/dsniff/blob/master/LICENSE evolution-data-server LGPLv2 All source files contain "under the terms of the GNU Lesser General Public License" COPYING file contains GPLv2: https://gitlab.gnome.org/GNOME/evolution-data-server/-/blob/master/COPYING gnucobol GPLv3 and LGPLv3 https://sourceforge.net/p/gnucobol/code/HEAD/tree/trunk/README https://sourceforge.net/p/gnucobol/code/HEAD/tree/trunk/COPYING inn INN, GPLv2+, Public Domain, BSD, BSD-2, MD5 https://github.com/InterNetNews/inn/blob/main/LICENSE iproute2 GPLv2 https://git.kernel.org/pub/scm/network/iproute2/iproute2.git/tree/COPYING isync GPLv2+ All src files contain "the Free Software Foundation; either version 2 of the License, or (at your option) any later version." https://sourceforge.net/p/isync/isync/ci/master/tree/LICENSES/GPL-2.0-or-later.txt jack2 linux subfolder: LGPLv2.1 and GPLv2+ dbus subfolder: GPLv2 jack2-dbus doesn't link against libdb, only libjackserver.so and libjack.so do. => Linking happends between LGPLv2.1 and AGPLv3 src: https://github.com/jackaudio/jack2 jnettop GPLv2 Main homepage seems to be down, but there are mirrors, for example: https://github.com/jwilk-mirrors/jnettop/blob/trunk/COPYING libical MPL or LGPL2.1 https://github.com/libical/libical/blob/master/COPYING neomutt GPLv2+, GPLv3 See src files. https://github.com/neomutt/neomutt/blob/main/LICENSE.md opendkim BSD and sendmail https://github.com/trusteddomainproject/OpenDKIM/blob/master/LICENSE https://github.com/trusteddomainproject/OpenDKIM/blob/master/LICENSE.Sendmail perl GPLv1+ https://github.com/Perl/perl5/blob/blead/README perl-berkeleydb Perl https://metacpan.org/pod/BerkeleyDB php PHP https://github.com/php/php-src/blob/master/LICENSE php7 PHP https://github.com/php/php-src/blob/master/LICENSE postfix EPL https://de.postfix.org/ftpmirror/index.html python-bsddb BSD-3 https://github.com/underrun/pybsddb/blob/master/LICENSE.txt reprepro GPLv2 https://salsa.debian.org/debian/reprepro/-/blob/debian/COPYING skktools GPLv2+ and GPLv3 See src files here: http://openlab.ring.gr.jp/skk/tools/ License: http://openlab.jp/skk/skk/main/READMEs/COPYING squid GPLv2+ See src files. https://github.com/squid-cache/squid/blob/master/COPYING subversion Apache2 swi-prolog BSD https://github.com/SWI-Prolog/swipl-devel/blob/master/LICENSE As far as I understand, the main concern is linking GPLv2 against AGPLv3. Thus I'd propose to create db5.3 for the GPLv2 only projects: bogofilter iproute2 jnettop reprepro Best regards, Frederik signature.asc Description: PGP signature
Re: db6 license concerns
On Mon, Dec 12, 2022 at 07:14:42PM +0100, Balló György wrote: > 2022. 12. 12, hétfő keltezéssel 17.16-kor Frederik Schwan ezt írta: > > As far as I understand, the main concern is linking GPLv2 against > > AGPLv3. > > Thus I'd propose to create db5.3 for the GPLv2 only projects: > > > > bogofilter > > iproute2 > > jnettop > > reprepro > > I seems to me it's not enough. Probably all dependent packages must be > compatible with the AGPLv3 license, not just those packages which > specify BerkeleyDB as a dependency explicitly. Good point. That adds a few to the list: bogofilter iproute2 jnettop reprepro inn (links against pam) jack2 (depends on dbus) neomutt (didn't check, depend on libdb can be removed probably) subversion (depends on lz4) swi-prolog (depends on gperftools -> libunwind) These are fine: isync (depends are BSD, GPLv3 and zlib) libical (depends on LGPLv2, MIT, BSD, zlib, GPLv3) opendkim (depends on BSD, OpenLDAP Public, cyrus-sasl, LGPLv2) postfix (depends on openssl, cyrus-sasl, zlib) skktools (depends on GPLv3 and LGPLv2, MIT, BSD) evolution-data-server and squid have been moved away from bdb in the meantime. signature.asc Description: PGP signature
Re: db6 license concerns
On Wed, Dec 14, 2022 at 10:56:30AM +0100, Pierre Schmitz wrote: > What is the latest news on this? I noticed PHP was patched for db-6 > and later on db support was removed completely. Will the db/db5 > package be dropped entirely? I removed db support where it seemed like a proper solution. For PHP I couldn't find any application in our repos nor in the (maintained) wild relying on it. In general the goal from 2013 to deprecate db entirely still stands. Though some applications don't give us a choice. I'll move the rebuilds to testing later today. I plan to keep them there for a couple of days to check if I missed some use cases (e.g. for PHP). If all goes well, I'll work on bumping db to v18 afterwards. signature.asc Description: PGP signature
glibc 2.37 release
Glibc 2.37 is about to be released to [testing]. Please be aware that any package that links against the 2.37 libc has to stay in testing for as long as glibc stays there. Otherwise breakage will be imminent. Best regards, Frederik signature.asc Description: PGP signature
News draft: Valkey to replace Redis in the [extra] Repository
Hi everyone, As you might have heard by now redis got a new license and *some* forks were created [1]. Valkey as one of them is developed by the Linux Foundation, and adopted by Fedora already [2]. So we think it's a good step to follow that path and replace redis by valkey. -- # Valkey to replace Redis in the [extra] Repository valkey, a modern in-memory data store, will soon be replacing redis in the [extra] repository. This change is due to Redis modifying its license from BSD-3-Clause to RSALv2 and SSPLv1 on March 20th, 2024[1]. Arch Linux Package Maintainers intend to support the availability of the redis package for roughly 90 days from the day of this post, to enable a smooth transition to valkey. After the 90 transition period has ended, the redis package will be moved to the AUR. Also, from this point forward, the redis package will not receive any additional updates and should be considered deprecated until it is removed. Users are recommended to begin transitioning their use of redis to valkey as soon as possible to avoid possible complications after the 90 day transition window closes. [0] https://github.com/redis/redis/commit/0b34396924eca4edc524469886dc5be6c77ec4ed -- Best regards, Andrew and Frederik [1] https://redis.io/blog/redis-adopts-dual-source-available-licensing/ [2] https://www.linuxfoundation.org/press/linux-foundation-launches-open-source-valkey-community signature.asc Description: PGP signature
News draft: glibc 2.41 breaks Discord
Hi everyone, as discussed in the Matrix packaging channel, the upcoming glibc move from testing to stable will break audio connectivity for Discord clients. Discord has fixed the issue in their canary build and has communicated an eta for the fix in stable for 2025-02-10. As the glibc update holds off package moves from testing to stable I would like to continue releasing the toolchain and give everyone instructions on how to fix their Discord installation. -- # Glibc 2.41 corrupting Discord installation Glibc and it's friends will move from testing to stable on approx. 2025-02-03. After installing the update, the Discord client will show a read warning that the installation is corrupt. This issue has been fixed in the Discord canary build. Until the fix hits the stable Discord release, please use the canary build or login via browser if you rely on audio connectivity. There have been no reports that (written) chat connectivity is affected. -- Best regards, Frederik signature.asc Description: PGP signature
glibc 2.41 in testing - moving to stable repos affected
I just pushed glibc 2.41 to testing. Do not move packages linked against 2.41 to extra or core until glibc itself moves around Sunday/Monday. Otherwise the package will probably break. Best regards, Frederik signature.asc Description: PGP signature
Re: News draft: glibc 2.41 breaks Discord
On Sun, Feb 02, 2025 at 02:43:25PM +0100, Frederik Schwan wrote: > Hi everyone, > > as discussed in the Matrix packaging channel, the upcoming glibc move from > testing to stable > will break audio connectivity for Discord clients. Discord has fixed the > issue in their canary build > and has communicated an eta for the fix in stable for 2025-02-10. As the > glibc update holds off package > moves from testing to stable I would like to continue releasing the toolchain > and give everyone > instructions on how to fix their Discord installation. > > -- > # Glibc 2.41 corrupting Discord installation > > Glibc and it's friends will move from testing to stable on approx. > 2025-02-03. After installing > the update, the Discord client will show a read warning that the installation > is corrupt. > > This issue has been fixed in the Discord canary build. Until the fix hits the > stable Discord release, > please use the canary build or login via browser if you rely on audio > connectivity. There have been > no reports that (written) chat connectivity is affected. > > -- > > Best regards, > Frederik New version below. I'll send it out tomorrow around 1400 UTC+1. -- # Glibc 2.41 corrupting Discord installation We plan to move `glibc` and its friends to stable later today, Feb 3. After installing the update, the Discord client will show a red warning that the installation is corrupt. This issue has been fixed in the Discord canary build. If you rely on audio connectivity, please use the canary build, login via browser or use the flatpak version until the fix hits the stable Discord release. There have been no reports that (written) chat connectivity is affected. -- signature.asc Description: PGP signature
Re: News draft: glibc 2.41 breaks Discord
On Sun, Feb 02, 2025 at 11:22:20PM +0100, gromit wrote: > On 25/02/02 02:43PM, Frederik Schwan wrote: > > # Glibc 2.41 corrupting Discord installation > > > > Glibc and it's friends will move from testing to stable on approx. > > 2025-02-03. After installing the update, the Discord client will show > > a read warning that the installation is corrupt. > > > > This issue has been fixed in the Discord canary build. Until the fix > > hits the stable Discord release, please use the canary build or login > > via browser if you rely on audio connectivity. There have been no > > reports that (written) chat connectivity is affected. > > I think we could also more clearly adivise people to just not upgrade > their system until we have also shipped the fixed discord version, as > this is the most simple solution to the problem. I think this may lead to partial upgrades since people may come to the conclusion to just not upgrade to the "bad" glibc version. But that will break every updated package that is linked against glibc. But Flatpak, as heftig pointed out, may be a good alternative here. I'm not sure if the fix will come with a package release. The broken code is loaded dynamically into ~/.config by Discord itself. Frederik signature.asc Description: PGP signature
Re: News draft: Valkey to replace Redis in the [extra] Repository
Hi Jiachen, we intended to mean 1). Sorry for the confusion. Best regards, Frederik On Fri, Apr 18, 2025 at 09:48:13AM +0900, Jiachen Yang wrote: > Hi Frederik, > > Sorry again, I found some miswording in my previous email. > > > 2. from the moving to the [extra] repo, the AUR redis package will also not > receive updates in the future, and should be considered deprecated until it is > removed from AUR in the future. > > I was meant to ask: > > 2. from the moving to AUR after the 14days period, the AUR redis package will > also not receive updates in the future, and should be considered deprecated > until it is removed from AUR in the future. > > Thanks > > Best regards, > Jiachen YANG > > 2025年4月18日(金) 9:43 Jiachen Yang <[1]farsee...@gmail.com>: > > Hi Frederik, > > As someone who translates news articles into Chinese for the Chinese > community, I would like to ask for some clarification about this > announcement. > > > Also, from this point forward, the redis package will not receive any > additional updates and should be considered deprecated until it is > removed. > > "This point" could mean either the following: > 1. from when this news is announced, PMs will not update redis in the > [extra] repo during the 14 days period, and it should be considered > deprecated until it is removed from the [extra] repo. > or > 2. from the moving to the [extra] repo, the AUR redis package will also > not > receive updates in the future, and should be considered deprecated until > it > is removed from AUR in the future. > > Which explanation is this announcement intended to convey to the users? > > Thank you. > > Best regards, > Jiachen YANG > > 2024年8月14日(水) 7:28 Frederik Schwan <[2]fre...@archlinux.org>: > > Hi everyone, > > As you might have heard by now redis got a new license and *some* > forks > were created [1]. > Valkey as one of them is developed by the Linux Foundation, and > adopted > by Fedora already [2]. > So we think it's a good step to follow that path and replace redis by > valkey. > > -- > # Valkey to replace Redis in the [extra] Repository > > valkey, a modern in-memory data store, will soon be replacing redis in > the [extra] repository. This > change is due to Redis modifying its license from BSD-3-Clause to > RSALv2 and SSPLv1 on March 20th, 2024[1]. > > Arch Linux Package Maintainers intend to support the availability of > the redis package for roughly > 90 days from the day of this post, to enable a smooth transition to > valkey. After the 90 transition > period has ended, the redis package will be moved to the AUR. Also, > from this point forward, the redis > package will not receive any additional updates and should be > considered deprecated until it is removed. > > Users are recommended to begin transitioning their use of redis to > valkey as soon as possible to > avoid possible complications after the 90 day transition window > closes. > > [0] [3]https://github.com/redis/redis/commit/ > 0b34396924eca4edc524469886dc5be6c77ec4ed > > -- > > Best regards, > Andrew and Frederik > > [1] [4]https://redis.io/blog/ > redis-adopts-dual-source-available-licensing/ > [2] [5]https://www.linuxfoundation.org/press/ > linux-foundation-launches-open-source-valkey-community > > > > -- > > -- > 楊 嘉晨 (YANG Jiachen) > TEL：080-3853-2770 > --- > > > > -- > > -- > 楊 嘉晨 (YANG Jiachen) > TEL：080-3853-2770 > --- > > References: > > [1] mailto:farsee...@gmail.com > [2] mailto:fre...@archlinux.org > [3] > https://github.com/redis/redis/commit/0b34396924eca4edc524469886dc5be6c77ec4ed > [4] https://redis.io/blog/redis-adopts-dual-source-available-licensing/ > [5] > https://www.linuxfoundation.org/press/linux-foundation-launches-open-source-valkey-community signature.asc Description: PGP signature
Re: On dropping Redis
On Fri, May 02, 2025 at 05:04:51PM +0200, Bert Peters wrote: > Hi all, > > A while ago we as a distro decided to stop supporting Redis, due to > their licence change [1], and move to Valkey. Through a combined > effort, we removed all direct dependencies on redis, replacing them > with vault and patching until that worked. The announcement was posted, > and a deadline was set. > > This may or may not have caused Redis to reconsider their license > change, and have announced another relicencing, this time to the AGPL > [2] [3]. With that change, I personally believe there is no longer a > reason to remove redis from [extra], and keep it in the repos as-is. > Redis is almost but not quite compatible with Valkey, so dropping it > without good cause would be a disservice to our community. > > Now, I don't want to make light of the harm that Redis inc initially > wrought on the open source community with their license change, or > waste the work that was done to make everything work with Valkey. > Pushback like this is what caused the license change. As such, I > propose we continue to use Valkey as the implementation for all > purposes that don't strictly require Redis, and maintain Redis simply > as a package for our commynity's convenience. That way, should the > licensing change again in the future, we do not have a similar amount > of work ahead of us. This seems to me the Arch way: pragmatic and user > central. > > Now I know that this is not a universally shared opinion, so please > consider this email an invitation for discussion on what we should be > doing here. > > Cheers, > > Bert > > > [1]: > https://lists.archlinux.org/archives/list/arch-dev-public@lists.archlinux.org/message/2ERGX565GSSBUMADBG7DQJYNPJD5GUXD/ > [2]: https://antirez.com/news/151 > [3]: https://redis.io/blog/agplv3/ Hi Bert, First of all, thank you for bringing the IRC/Matrix discussion to the ML! Whatever led redis to reconsider, the way they treated us is unacceptable to me as a volunteer package maintainer. Anthraxx, then Andrew and I got contacted by a product manager from Redis. There were no apologies for the licensing issues, nor any for future coorperation - only some information about the latest Redis features and a statement that removing Redis from the official repos would not be in the interest of "the community" (whatever community is meant in this context). In contract, we've had very positive interactions with the Valkey upstream. There is a clear interest in making Valkey packaging easier for distributions. For example, we'll likely be able to remove the jemalloc patch that makes valkey/redis link against the system jemalloc in the future. So how do we proceed? I agree with Morten, that Redis upstream has proven itself abolutely unreliable. I propose we exclude redis from the official repos for one year, after which we can reevaluate its status. Contining to aintain Redis will only result in more unnecessary drama. We've already announced Redis's replacement and we should stand by that decision rather than follow upstream’s erratic direction. Best regards, Frederik signature.asc Description: PGP signature
Re: Standardize on running autoreconf in prepare()
On Wed, Feb 26, 2025 at 09:53:50PM +0100, Jelle van der Waa wrote: > Hi All, > > After all the recent RISC-V news I went ahead and checked out the existing > effort to get Arch Linux supported on RISC-V. Felix maintains an overlay of > PKGBUILDs which require customization to be be able to build on RISC-V. A > lot of these PKGBUILD's patch autotools projects to run `autoreconf -fiv` in > prepare(), this re-generates `configure` to understand RISC-V. > > Since these patches are simple enough and I don't see them harming Arch > Linux, I would argue that we want these patches applied in our packages. > Re-generating configure should not break, and if it does we should not > accept the patch and get a bug filled upstream. > > Re-creating configure and thus not using the provided `configure` could > arguably also be a good thing regarding supply chain security. And this also > should help with other architecture ports. > > As a follow up we can discuss providing our own "/usr/share/config.site" and > then ./configure --prefix=/usr would automatically configure localstatedir, > libexecdir, etc. > > [1] https://github.com/felixonmars/archriscv-packages > [2] > https://github.com/felixonmars/archriscv-packages/blob/master/libafterimage/riscv64.patch +1 signature.asc Description: PGP signature
[arch-dev-public] News draft: Archlinux mailing list id changes
Hey all, below is the news item I would like to post. We had to change some mailing list ids which used to be @archlinux.org to @lists.archlinux.org to mitigate anti spam issues. Sending to @archlinux.org still works as usual though. ``` Due to issues with our anti spam measures, we had to migrate those mailing lists, that were sent from @archlinux.org before to the @lists.archlinux.org domain. Submission to the mailing list is not affected and still works with @archlinux.org. Mails get redirected automagically. The only change that may need to be considered on your side are filters and rules matching the From or List-id header which changed accordingly. ``` If you have improvement suggestions, please let me know! Best regards, Frederik signature.asc Description: PGP signature
Re: [arch-dev-public] Packages seeking Maintainers
On Fri, Jan 21, 2022 at 11:32:59AM +0100, Jelle van der Waa via arch-dev-public wrote: > Hello, > > Noticing that I don't really have time and energy to maintain a part of my > packages. I think it's better to disown them and let others take care of > them, the list is: > > chromium-bsu > guetzli > hey (can be dropped as it's not really maintained anymore and oha is much > nicer) > podofo > rdesktop > tidy > python-pytest-qt > leptonica > bonnie++ > asciidoctor > acpi > gsmartcontrol > ccd2iso > avrdude > avr-libc > vim-pastie > vim-align > > I've also disowned tesseract* which already has a maintainer, but maybe > someone is interested in co-maintaining it. > > Greetings, > > Jelle van der Waa Took over guetzli, avrdude and avr-libc. Cheers signature.asc Description: PGP signature
Re: [arch-dev-public] [RFC] archweb nvchecker integration
On Mon, Jan 31, 2022 at 09:25:41PM +0100, Jelle van der Waa via arch-dev-public wrote: > We’ve wanted automatic flagging packages out of date for a while and > currently every packager has to come up with it’s own solution. Let’s solve > this centralized by integrating nvchecker into archweb. > > nvchecker is a program which can monitor versions upstreams, github, pypi, > haskell, crates.io or custom provided for updates. Various packagers already > use nvchecker in some form. [1] > > The idea is that every package in svn has a .NVCHECKER file > (linux/trunk/.NVCHECKER) which contains the package specific settings i.e.: > > [go] > source = “github” > github = “golang/go” > prefix = “go” > use_max_tag = true > exclude_regex = “.(release|weekly|rc|alpha|beta).” > > Archweb will have a systemd service which regularly goes through the > pkgbases, check if the file exists, runs nvchecker and if required flags the > package out of date automatically. > > For Github sources a token is required so we can do 5000 requests per hour, > Arch Linux already has a Github account so this is no issue. > > Felix already has a script which converts a subset of packages to nvchecker. > This could be extended to apply to more packages. [2] > > The question is if anyone object to checking these small .NVCHECKER files > into our svn repository. If there are no real objections, I'll start > implementing this functionality into archweb in two weeks. > > [1] https://nvchecker.readthedocs.io/en/latest/usage.html#check-crates-io > [2] > https://github.com/felixonmars/archlinux-futils/blob/master/arch-to-nvchecker > > Greetings, > > Jelle van der Waa Using nvchecker for a couple of years now not only for Arch packages, but also for a lot of IoT devices, hobby equipment and more. Pretty happy with nvchecker-notify :) An integration into Archweb would be awesome. Do we remove the ability to mark packages out-of-date manually then? It seems to me that a broken nvchecker config in a certain repo is more a bug than an ood package after such an addition. Best regards, Frederik signature.asc Description: PGP signature
Re: [arch-dev-public] On the toolchain current status
On Mon, Feb 07, 2022 at 12:26:54PM -0300, Giancarlo Razzolini via arch-dev-public wrote: > Hi All, > > Most of you are aware that our toolchain is currently outdated. We always had > very few people > working on it through the years and I took over once Barth left, because it > was needed. > > However, I have been having very little time to work on Arch related stuff > lately and the > toolchain is the most noticeable victim, given it is one of the most time > consuming. > In this meantime, a few things also happened that compounded to the issue, > among them, we enabled LTO. > > Right now I'm working on bringing new glibc 2.35 and also waiting on binutils > release so we > can bring the toolchain up to date. I'm aware we also have a GCC release > coming out soon, and > the toolchain will need a new rebuild then. > > For the future, we are trying to bring more people to work with the whole > toolchain, so it is > not too much of a bus factor. We should have at least two toolchain > maintainers, not just one. > > I hope this serves to assuage the concerns over the current status of our > toolchain, both present > and going future. > > Regards, > Giancarlo Razzolini Hey there, binutils 2.38 has been released today and so the prepared build of glibc 2.35 happened along with the bump of gcc to 11.2.0. Many thanks to Allan McRae, Bartłomiej Piotrowski and Giancarlo Razzolini for helping me to unterstand the toolchain. The builds are available in [testing]. Please give a test. Best regards, Frederik signature.asc Description: PGP signature
