Konstantin Gizdov is now a developer

[Sven-Hendrik Haase]

Hey everyone,

I internally proposed Konstantin Gizdov to become a developer for his 
sustained good work on Arch Linux and the need to touch some [extra] 
packages sometimes. I'm pleased to announce that he has now become a 
full developer. All the relevant steps have been completed and he should 
now already be fully onboarded.


Welcome aboard, Konstantin!

Sven


OpenPGP_signature
Description: OpenPGP digital signature

Re: Orphan keenerd packages

[Sven-Hendrik Haase]

I took armagetronad and the cataclysms.


OpenPGP_signature
Description: OpenPGP digital signature

Re: Proposal to increase the default vm.max_map_count value

[Sven-Hendrik Haase]

On 25.03.24 09:10, Robin Candau wrote:

Hi everyone,

I'm writing this mail as proposal to increase the default 
`vm.max_map_count` [1] value in Arch Linux.


The default `vm.max_map_count` 65530 value is making some Windows games 
crash (or even prevent them to start at all) while being played through 
Wine or Steam Play (Proton).
Examples are (but not limited to) Star Citizen, THE FINALS, Hogwarts 
Legacy, DayZ or Counter-Strike 2 (see [2] for a list of bug reported to 
Valve for these games on that matter).


In that regard, SteamOS is shipping an increased `vm.max_map_count` 
default value to address the above issue and numerous distributions have 
since then decided to implement that change on their side as well, such 
as Fedora [3], NixOS [4] and, more recently, Ubuntu [5].


While I'm aware that Arch is a user centric/DIY distro and everyone can 
set their own `vm.max_map_count` value fairly easily, shipping an 
increased value on our side would be a beneficial change to make in my 
opinion as it would result in a smoother gaming experience out of the 
box for our users without representing any downside/side effect (as far 
as I'm aware).


In terms of implementation, the change basically consists of shipping 
the following sysctl file:


```
# Increase the number of virtual memory areas that one process may request
vm.max_map_count=1048576
```

For reference, Fedora added it to their systemd package [6], while 
Ubuntu handled it at the procps level [7].

I personally don't have a strong opinion on the implementation way/place.

To sum up, I think this would be a reasonable and positive change to 
make to our distro.

I'd be happy to read your thoughts (or eventual objection)! 😊

[1] https://docs.kernel.org/admin-guide/sysctl/vm.html#max-map-count
[2] https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2057792/comments/5
[3] https://fedoraproject.org/wiki/Changes/IncreaseVmMaxMapCount
[4] https://github.com/NixOS/nixpkgs/pull/238459
[5] https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2057792
[6] https://src.fedoraproject.org/rpms/systemd/blob/f39/f/10-map-count.conf
[7] 
https://git.launchpad.net/ubuntu/+source/procps/commit/?h=applied/2%254.0.4-4ubuntu2&id=b4a4a046cf018a942598e55f3fbc7b5ef474f676




Nice idea, I'm in favour. This has actually bitten me before. If other 
distros have this, users will come to expect it as the defacto default 
and would be confused if Arch behaved differently.


I'm curious: At this point, I think we have a good case to try to get 
this changed upstream. Has this been attempted?


OpenPGP_signature.asc
Description: OpenPGP digital signature

Re: Resignation

[Sven-Hendrik Haase]

On 14.07.24 21:14, Florian Pritz wrote:

Hi,

Sadly I have no longer had the time necessary to properly handle master
key holder and packager duties for a while now. I don't feel like it's
fair to you guys and our users to keep this up any longer so I'm
officially resigning now.

Most pressing topics that come to mind for someone wanting to take over:

* I hold a master key, so you'll need to find a new holder for that
* perl 5.40 update
* various bug reports on Gitlab for my packages
* a few flagged packages

Thanks for all the nice memories since "[2008-10-19 14:38] installed
filesystem (2008.03-2)". While I will no longer be involved in Arch
development, I'll still continue to use it and this nice, old install
will also continue to live on.

Hope to see you guys around :)

Florian


Hey Florian,

sad to see you go even though the writing's been on the wall for a while 
now I suppose. Thank you for all the time you put into the project. 
Sadly I never got to meet you in person.


Good luck in your next endeavours!

Cheers,
Sven


OpenPGP_signature.asc
Description: OpenPGP digital signature

RFC: License Package Sources

[Sven-Hendrik Haase]

A new RFC (request for comment) has been opened here:

https://gitlab.archlinux.org/archlinux/rfcs/-/merge_requests/40

Please visit the above link for discussion.

Summary: Our package sources currently do not have explicit licenses.
This RFC proposes to license all Arch Linux package sources under the terms of 
the Zero-Clause BSD license.



OpenPGP_signature.asc
Description: OpenPGP digital signature

RFC Final Comment Period: License Package Sources

[Sven-Hendrik Haase]

An RFC has now entered its Final Comment Period. In 14 days, discussion
will end and the proposal will either be accepted, rejected or withdrawn:

https://gitlab.archlinux.org/archlinux/rfcs/-/merge_requests/40

Please visit the above link for discussion.

Summary:
Our package sources currently do not have explicit licenses.
This RFC proposes to license all Arch Linux package sources under the 
terms of the Zero-Clause BSD license.


OpenPGP_signature.asc
Description: OpenPGP digital signature

Re: RFC Final Comment Period: License Package Sources

[Sven-Hendrik Haase]

On 03.09.24 13:30, Sven-Hendrik Haase wrote:

An RFC has now entered its Final Comment Period. In 14 days, discussion
will end and the proposal will either be accepted, rejected or withdrawn:

https://gitlab.archlinux.org/archlinux/rfcs/-/merge_requests/40

Please visit the above link for discussion.

Summary:
Our package sources currently do not have explicit licenses.
This RFC proposes to license all Arch Linux package sources under the 
terms of the Zero-Clause BSD license.


I'm so sorry. I apparently sent an HTML email because it wasn't disabled 
for this account.


Here's the real link:
https://gitlab.archlinux.org/archlinux/rfcs/-/merge_requests/40


OpenPGP_signature.asc
Description: OpenPGP digital signature

Let's drop ollama-gemma2-2b and forbid GenAI models

[Sven-Hendrik Haase]

Hey all,

There's been some discussion about this via chat but no action has been 
taken. Some time ago, ollama-gemma2-2b was uploaded to [extra] which has 
caused some discussion for various reasons.


I'm not writing this mail to address or open up the discussion for 
ethical or political concerns. This is about pragmatism. With the 
current state of things, I don't think we should have any LLMs or other 
GenAI models in official repos. I think it would be much more practical 
to offer downloaders such as huggingface-cli or ollama instead. GenAI 
models become out of date every other week and they tend to be rather 
large too. Downloaders allow users to download these models from 
specialized hosters at good speeds and to easily stay up to date.


I don't think we're doing anyone a service by offering outdated GenAI 
models in the repos.


This mail is explicitly NOT about other ML model types such as rnnoise. 
Those tend to be small and unchanging. They should stay in repos where 
it makes sense and if there's software that uses them (such as Mumble in 
this particular example).


I propose this:

- Drop ollama-gemma2-2b
- Forbid other GenAI models from entering official repos for the time being

What do you guys think?

Cheers,
Sven


OpenPGP_signature.asc
Description: OpenPGP digital signature

Re: RFC Final Comment Period: License Package Sources

[Sven-Hendrik Haase]

On 03.09.24 13:42, Sven-Hendrik Haase wrote:

On 03.09.24 13:30, Sven-Hendrik Haase wrote:

An RFC has now entered its Final Comment Period. In 14 days, discussion
will end and the proposal will either be accepted, rejected or withdrawn:

https://gitlab.archlinux.org/archlinux/rfcs/-/merge_requests/40

Please visit the above link for discussion.

Summary:
Our package sources currently do not have explicit licenses.
This RFC proposes to license all Arch Linux package sources under the 
terms of the Zero-Clause BSD license.


I'm so sorry. I apparently sent an HTML email because it wasn't disabled 
for this account.


Here's the real link:
https://gitlab.archlinux.org/archlinux/rfcs/-/merge_requests/40


The final comment period is over! The RFC has been accepted and will be 
merged and implemented.


OpenPGP_signature.asc
Description: OpenPGP digital signature

Re: Let's drop ollama-gemma2-2b and forbid GenAI models

[Sven-Hendrik Haase]

On 13.11.24 05:53, Sven-Hendrik Haase wrote:

Hey all,

There's been some discussion about this via chat but no action has been 
taken. Some time ago, ollama-gemma2-2b was uploaded to [extra] which has 
caused some discussion for various reasons.


I'm not writing this mail to address or open up the discussion for 
ethical or political concerns. This is about pragmatism. With the 
current state of things, I don't think we should have any LLMs or other 
GenAI models in official repos. I think it would be much more practical 
to offer downloaders such as huggingface-cli or ollama instead. GenAI 
models become out of date every other week and they tend to be rather 
large too. Downloaders allow users to download these models from 
specialized hosters at good speeds and to easily stay up to date.


I don't think we're doing anyone a service by offering outdated GenAI 
models in the repos.


This mail is explicitly NOT about other ML model types such as rnnoise. 
Those tend to be small and unchanging. They should stay in repos where 
it makes sense and if there's software that uses them (such as Mumble in 
this particular example).


I propose this:

- Drop ollama-gemma2-2b
- Forbid other GenAI models from entering official repos for the time being

What do you guys think?

Cheers,
Sven


Thanks for the feedback everyone. Removed ollama-gemma2-2b from [extra].


OpenPGP_signature.asc
Description: OpenPGP digital signature

Re: Amending RFC40 to remove custom 0BSD license

[Sven-Hendrik Haase]

On 03.01.25 21:07, Morten Linderud wrote:

Yo,

Today I noticed that the "License package sources" RFC contained an amended 0BSD
license that added a two paragraph exception for patch files and other auxiliary
files. The purpose of this change is to ensure the license is not covering other
files in the repository that the author can't license from the upstream.

See: https://rfc.archlinux.page/0040-license-package-sources/

While this is a practical problem that needs to be solved, we should not be
doing that through additional text in a FSF- and OSI approved license. This
essentially makes it a custom license that is not really going to detected as
0BSD from external sources, and runs against the original goal of removing legal
uncertainty.

As the change, and by extension the problem itself, is not mentioned in the text
it came as a surprise to me that it was done.

What I think is more proper is to remove these two lines from the proposed
license file, and move this to a separate RFC that would cover a use of the
REUSE specification, or SPDX license identifiers. This would serve the same
purpose as the Debian `copyright` files, while also being standardized.

I have written a proposed amendment to the text that I hope people find okay.

https://gitlab.archlinux.org/archlinux/rfcs/-/merge_requests/49


*Please note that any licenses already added to the repository needs to be
amended.*


My goal is to write up a RFC for the REUSE/SPDX part of this before the current
3 month timeline where we'll start adding licenses to ensure we don't prolong
the process.

If people are curious how this would look like, I annotated the `usd` package as
an example.

https://gitlab.archlinux.org/foxboron/usd/-/tree/morten/reuse

See the spec for more details: https://reuse.software/spec-3.2/

Cheers!



As per the discussion on IRC, I think this suggestion makes sense. I 
agree that the custom 0BSD change should have been called out in the RFC.


I'm ok with changing the RFC text since it's kind of an implementation 
detail to make sure we are in line with the original intent of the RFC. 
However, we need to make sure people are on-board with this as not a 
trivial RFC change and I don't think we've done this before.


Thanks for doing the mockup on usd, really helps to visualize how this 
would look.


OpenPGP_signature.asc
Description: OpenPGP digital signature

Cleaning up old [community*] repos

[Sven-Hendrik Haase]

Hey,

The git/community-to-extra migration was almost two years ago. Back 
then, we left the [community] repository and friends 
([community-staging], [community-testing]) in place (though empty) so 
that users would have an easier time migrating.


They've sat there unused for a long time now and I think users have had 
enough time to migrate. I would like to suggest removing the empty 
[community] repos from repos.archlinux.org.


This could break update workflows for users who haven't updated their 
/etc/pacman.conf in a long time but apart from that I don't expect any 
drawbacks.


Opinions?

Sven


OpenPGP_signature.asc
Description: OpenPGP digital signature

Re: Cleaning up old [community*] repos

[Sven-Hendrik Haase]

On 07.02.25 16:11, Sven-Hendrik Haase wrote:

Hey,

The git/community-to-extra migration was almost two years ago. Back 
then, we left the [community] repository and friends ([community- 
staging], [community-testing]) in place (though empty) so that users 
would have an easier time migrating.


They've sat there unused for a long time now and I think users have had 
enough time to migrate. I would like to suggest removing the empty 
[community] repos from repos.archlinux.org.


This could break update workflows for users who haven't updated their / 
etc/pacman.conf in a long time but apart from that I don't expect any 
drawbacks.


Opinions?

Sven


On that note, I would also like to nuke the other old repos:
- testing (it's now extra-testing)
- testing-debug (it's now extra-testing-debug)
- staging (it's now extra-staging)
- staging-debug (it's now extra-staging-debug)


OpenPGP_signature.asc
Description: OpenPGP digital signature

Re: News draft: Cleaning up old repositories

[Sven-Hendrik Haase]

On 14.02.25 19:11, Robin Candau wrote:

On 2/14/25 6:49 PM, Sven-Hendrik Haase wrote:

Hey all,



Yo Sven,

in an earlier thread [0], I proposed cleaning up the unused repos from 
repos.archlinux.org.
They've become unused and stagnant after the git migration almost two 
years ago.
We kept them around so it wouldn't break setups of users that tried to 
get the repository sync databases with an outdated pacman.conf.

The old repos are safe to remove.
Originally I had planned to just remove them and leave it at that.
However, some people mentioned that it might still confuse users who 
haven't updated their pacman.conf in a long time.

In order to inform those users there should be a news post.

[0] https://lists.archlinux.org/archives/list/arch-dev- 
pub...@lists.archlinux.org/thread/OWHVWRBOUDCW7BUQ2DLCENJ6QRPCTGQJ/




Thanks for taking care of this!
Tiny suggestions below.


---
# Cleaning up old repositories

Around two years ago, we've merged the [community] repository into 
[extra] as part of the git migration. In order to not break user 
setups, we kept these repositories around in an unused and empty state.

We're going to clean up these old repositories on *2025-03-01*.



Maybe link people to the related news, which already mentioned the merge 
of the [community] repo into [extra] (and the related `/etc/ 
pacman.conf.pacnew`)?:


"Around two years ago, we've merged the [community] repository into 
[extra] as part of the [git migration](https://archlinux.org/news/git- 
migration-completed/)"


On systems where `/etc/pacman.conf` still references the old 
`[community]` repository, `pacman -Sy` will return an error on trying 
to sync repository metadata.


The following deprecated repositories will be removed: `[community], 
`[community-testing]`, `[testing]`, `[testing-debug]`, `[staging]`, 
`[staging-debug]`.


Please make sure to remove all use of the aforementioned repositories 
from your `/etc/pacman.conf`!


Maybe a good occasion to remind that a pacnew was shipped for that (and 
that people should *not* ignore them :P):


"Please make sure to remove all use of the aforementioned repositories 
from your `/etc/pacman.conf` (for which a pacnew was shipped with 
pacman>=6.0.2-7)!"


Just details though, looks good to me overall! :)


---

Cheers,
Sven




Thanks, I updated my draft with your feedback, fixed some formatting, 
and sent it off.


OpenPGP_signature.asc
Description: OpenPGP digital signature

News draft: Cleaning up old repositories

[Sven-Hendrik Haase]

Hey all,

in an earlier thread [0], I proposed cleaning up the unused repos from 
repos.archlinux.org.
They've become unused and stagnant after the git migration almost two 
years ago.
We kept them around so it wouldn't break setups of users that tried to 
get the repository sync databases with an outdated pacman.conf.

The old repos are safe to remove.
Originally I had planned to just remove them and leave it at that.
However, some people mentioned that it might still confuse users who 
haven't updated their pacman.conf in a long time.

In order to inform those users there should be a news post.

[0] 
https://lists.archlinux.org/archives/list/arch-dev-public@lists.archlinux.org/thread/OWHVWRBOUDCW7BUQ2DLCENJ6QRPCTGQJ/


---
# Cleaning up old repositories

Around two years ago, we've merged the [community] repository into 
[extra] as part of the git migration. In order to not break user setups, 
we kept these repositories around in an unused and empty state.

We're going to clean up these old repositories on *2025-03-01*.

On systems where `/etc/pacman.conf` still references the old 
`[community]` repository, `pacman -Sy` will return an error on trying to 
sync repository metadata.


The following deprecated repositories will be removed: `[community], 
`[community-testing]`, `[testing]`, `[testing-debug]`, `[staging]`, 
`[staging-debug]`.


Please make sure to remove all use of the aforementioned repositories 
from your `/etc/pacman.conf`!

---

Cheers,
Sven


OpenPGP_signature.asc
Description: OpenPGP digital signature

Re: Cleaning up old [community*] repos

[Sven-Hendrik Haase]

On 07.02.25 16:23, Sven-Hendrik Haase wrote:

On 07.02.25 16:11, Sven-Hendrik Haase wrote:

Hey,

The git/community-to-extra migration was almost two years ago. Back 
then, we left the [community] repository and friends ([community- 
staging], [community-testing]) in place (though empty) so that users 
would have an easier time migrating.


They've sat there unused for a long time now and I think users have 
had enough time to migrate. I would like to suggest removing the empty 
[community] repos from repos.archlinux.org.


This could break update workflows for users who haven't updated 
their / etc/pacman.conf in a long time but apart from that I don't 
expect any drawbacks.


Opinions?

Sven


On that note, I would also like to nuke the other old repos:
- testing (it's now extra-testing)
- testing-debug (it's now extra-testing-debug)
- staging (it's now extra-staging)
- staging-debug (it's now extra-staging-debug)


All old repos have been moved.

Sven


OpenPGP_signature.asc
Description: OpenPGP digital signature

[arch-dev-public] News draft: Manual pages indexing service

[Sven-Hendrik Haase via arch-dev-public]

Hey all,

lahwaacz made a service for collecting and displaying manpages from our 
packages that we now operate at man.archlinux.org.


I believe this is news-post worthy.

---
Title: man.archlinux.org is live

We are happy to announce our newest public service: A manual pages 
indexing site at [man.archlinux.org](https://man.archlinux.org) that 
publishes all man pages of all our packages and allows you to 
[search](https://man.archlinux.org/search) and 
[browse](https://man.archlinux.org/listing) them. Check out, for 
example, the [man page of 
tar](https://man.archlinux.org/man/core/tar/tar.1.en).


You can also find a link to this service in our sidebar. Thanks to Wiki 
Admin [lahwaacz](https://wiki.archlinux.org/index.php/User:Lahwaacz) for 
developing 
[archmanweb](https://gitlab.archlinux.org/archlinux/archmanweb) for this 
purpose.


While there are other man page indexing sites out there, it is our hope 
that publishing man pages that match the version of our released 
packages makes Arch more accessible and that it improves our 
documentation even further.

---

Thoughts?

Cheers,
Sven



OpenPGP_signature
Description: OpenPGP digital signature

Re: [arch-dev-public] News draft: Manual pages indexing service

[Sven-Hendrik Haase via arch-dev-public]

On 13.01.21 00:12, Sven-Hendrik Haase wrote:

Hey all,

lahwaacz made a service for collecting and displaying manpages from our 
packages that we now operate at man.archlinux.org.


I believe this is news-post worthy.

---
Title: man.archlinux.org is live

We are happy to announce our newest public service: A manual pages 
indexing site at [man.archlinux.org](https://man.archlinux.org) that 
publishes all man pages of all our packages and allows you to 
[search](https://man.archlinux.org/search) and 
[browse](https://man.archlinux.org/listing) them. Check out, for 
example, the [man page of 
tar](https://man.archlinux.org/man/core/tar/tar.1.en).


You can also find a link to this service in our sidebar. Thanks to Wiki 
Admin [lahwaacz](https://wiki.archlinux.org/index.php/User:Lahwaacz) for 
developing 
[archmanweb](https://gitlab.archlinux.org/archlinux/archmanweb) for this 
purpose.


While there are other man page indexing sites out there, it is our hope 
that publishing man pages that match the version of our released 
packages makes Arch more accessible and that it improves our 
documentation even further.

---

Thoughts?

Cheers,
Sven



Typo'd. I wanted to write:

"that publishes the man pages of all our packages and allows you to"

Re: [arch-dev-public] News draft: Manual pages indexing service

[Sven-Hendrik Haase via arch-dev-public]

On 13.01.21 00:16, Morten Linderud via arch-dev-public wrote:

On Wed, Jan 13, 2021 at 12:12:05AM +0100, Sven-Hendrik Haase via 
arch-dev-public wrote:

While there are other man page indexing sites out there, it is our hope that
publishing man pages that match the version of our released packages makes
Arch more accessible and that it improves our documentation even further.


I would suggest

"..makes Arch more accessible and improves our documentation even furhter."

Isn't "that it" redundant here?

Nice work! Thanks again for fixing this :)<3



How about:
While there are other man page indexing sites out there, it is our hope 
that publishing man pages matching the versions of our released packages 
further improves Arch accessibility and documentation.




OpenPGP_signature
Description: OpenPGP digital signature

[arch-dev-public] Decommissioning dragon and upgrading to new box

[Sven-Hendrik Haase via arch-dev-public]

Hey everyone,

A new sponsorship term for dragon (our build server for those who 
weirdly enough don't know) was coming up and as the box was getting 
pretty slow for 2021 I felt perhaps we should also try for an upgrade.


Anyway so Hetzner kindly agreed to give us a sponsorship deal for a 
bigger box which is roughly twice as fast as dragon. It'll be called 
"mir" and will be made available in the next few days.


dragon is scheduled to be decommissioned on the 19th of January. Since 
nobody is supposed to be storing any data on dragon, we won't be 
performing a home directory transfer. Still, if there's any data you 
care about on dragon, please back it up until the 19th.


Have fun with the new box!

Cheers,
Sven



OpenPGP_signature
Description: OpenPGP digital signature

Re: [arch-dev-public] Decommissioning dragon and upgrading to new box

[Sven-Hendrik Haase via arch-dev-public]

On 14.01.21 20:40, Sven-Hendrik Haase wrote:

Hey everyone,

A new sponsorship term for dragon (our build server for those who 
weirdly enough don't know) was coming up and as the box was getting 
pretty slow for 2021 I felt perhaps we should also try for an upgrade.


Anyway so Hetzner kindly agreed to give us a sponsorship deal for a 
bigger box which is roughly twice as fast as dragon. It'll be called 
"mir" and will be made available in the next few days.


dragon is scheduled to be decommissioned on the 19th of January. Since 
nobody is supposed to be storing any data on dragon, we won't be 
performing a home directory transfer. Still, if there's any data you 
care about on dragon, please back it up until the 19th.


Have fun with the new box!

Cheers,
Sven



Since the new box doesn't appear to be ready in time for a direct 
replacement, I've cancelled the cancellation so that we don't break any 
workflows that depend on a fast build box being available.


Also, since apparently some people appear to be storing some specific 
config on dragon, we'll transfer home dirs once the new box becomes 
available but we'll perform a cleanup beforehand (such as cleaning .cache).


Cheers,
Sven

[arch-dev-public] build.archlinux.org now available

[Sven-Hendrik Haase via arch-dev-public]

Hello all,

A new bigger and badder build box is now available to all packagers at 
build.archlinux.org. home dirs (but not .cache) have been transferred to 
the new box from dragon and all users should have access.


The new box, as previously mentioned, is roughly twice as fast as dragon 
and has enough memory and storage to handle some load.


dragon is scheduled to be decommissioned on the 31st of January so you 
still have some time to check whether everything was properly transferred.


Have fun!

Sven



OpenPGP_signature
Description: OpenPGP digital signature

Re: [arch-dev-public] Decommissioning dragon and upgrading to new box

[Sven-Hendrik Haase via arch-dev-public]

On 18.01.21 01:40, Sven-Hendrik Haase wrote:

On 14.01.21 20:40, Sven-Hendrik Haase wrote:

Hey everyone,

A new sponsorship term for dragon (our build server for those who 
weirdly enough don't know) was coming up and as the box was getting 
pretty slow for 2021 I felt perhaps we should also try for an upgrade.


Anyway so Hetzner kindly agreed to give us a sponsorship deal for a 
bigger box which is roughly twice as fast as dragon. It'll be called 
"mir" and will be made available in the next few days.


dragon is scheduled to be decommissioned on the 19th of January. Since 
nobody is supposed to be storing any data on dragon, we won't be 
performing a home directory transfer. Still, if there's any data you 
care about on dragon, please back it up until the 19th.


Have fun with the new box!

Cheers,
Sven



Since the new box doesn't appear to be ready in time for a direct 
replacement, I've cancelled the cancellation so that we don't break any 
workflows that depend on a fast build box being available.


Also, since apparently some people appear to be storing some specific 
config on dragon, we'll transfer home dirs once the new box becomes 
available but we'll perform a cleanup beforehand (such as cleaning .cache).


Cheers,
Sven


So dragon is now officially decommissioned. Please use 
build.archlinux.org from now on. If you're using offload-build, you'll 
have to use offload-build -s build.archlinux.org until devtools is updated.


Cheers,
Sven



OpenPGP_signature
Description: OpenPGP digital signature

Re: [arch-dev-public] RFC: Use x86_64-v2 architecture

[Sven-Hendrik Haase via arch-dev-public]

On Wed, 3 Mar 2021 at 23:13, Evangelos Foutras via arch-dev-public
 wrote:
>
> On Wed, 3 Mar 2021 at 23:34, Allan McRae via arch-dev-public
>  wrote:
> > Options realistically are:
> >
> > 1) bump the baseline
> > 2) provide a second more optimized port.
>
> 3) defer this until better tooling is available to implement (2)
>
> Since the RFC is about bumping -march to x86_64-v2, it either gets
> accepted and my desktop computer can no longer run Arch, or the RFC
> gets rejected and another approach is proposed in the future.
> Discussing alternative implementations seems out of scope.
>
> For what is worth, you mentioned RHEL 9 adopting x86_64-v2 but I'm not
> sure it translates well to Arch; companies have shorter replacement
> timelines for servers and workstations so it makes sense for upcoming
> RHEL releases to target newer hardware. Furthermore, older machines
> can stay with RHEL 8 until 2029; Arch doesn't have a fallback like
> that.

I'll also back 3). I think having a general mechanism for this and not
just bumping baseline and then being able to ship baseline, -v2, -v3,
-v4 with that hypothetical general mechanism would make more sense and
be less of a hack. Otherwise, we're just going to have the same
conversation again down the road.

Re: [arch-dev-public] Tracking different CPU architectures with pkgstats

[Sven-Hendrik Haase via arch-dev-public]

On Sun, 14 Mar 2021 at 15:17, Levente Polyak via arch-dev-public
 wrote:
>
> On 3/14/21 3:07 PM, Pierre Schmitz via arch-dev-public wrote:
> > I just updated the server to also accept x86_64 feature levels, ARM
> > and even i686. There is a new version of pkgstats (>= 3.1.0; currently
> > in [testing]) which is able to detect feature levels. ARM support is
> > pretty early, but x86_64 should be fine (using Intel's cpuid library).
> >
> > If you like to check what gets detected on your system run:
> > $ pkgstats submit --dump-json | head
> > system.architecture is your CPU and os.architecture should be the same
> > as "uname -m"
> >
> > Let me know if this does work for you and especially if it does not.
> > Using Qemu for testing is quite limited and I lack old, new and AMD
> > CPUs.
> >
> > An API and UI to analyze these data will follow in the future. (I
> > guess we need to wait a few weeks to see some valid results)
>
> Hi Pierre,
>
> that sounds wonderful, thanks for the work, this will be nice data points :)
>
> Did you see my previous mail? It would be amazing if you can consider
> growing this side-project into something official in terms of being
> available on http://pkgstats.archlinux.org/
>
> I think this is really a great idea and project that we should advocate
> in the official hosting namespace :)
>
> cheers and thanks,
> Levente
>

I second this and we've tried to touch on this in the past. I think
"officializing" pkgstats would be neat.

Cheers,
Sven

Re: [arch-dev-public] [arch-devops] deprecating git.archlinux.org

[Sven-Hendrik Haase via arch-dev-public]

On Wed, Jun 23, 2021, 22:05 Daniel M. Capella via arch-devops <
arch-dev...@lists.archlinux.org> wrote:

> On June 23, 2021 4:01:06 PM EDT, Jelle van der Waa via arch-dev-public <
> arch-dev-public@lists.archlinux.org> wrote:
> > Hi All,
> >
> > Today mailman was moved to a dedicated vps, making git.archlinux.org
> > the
> > last service to run on luna which we intend to retire as it's an old
> > expensive box and GitLab is our replacement for Git hosting.
> >
> > If your project has not been migrated to Gitlab yet please contact
> > devops for help migrating it. A list of known to require migration is
> > listed in this ticket. [1]
> >
> > As the invoice date comes up the 8th, it would be awesome if we can
> > cancel the box before that date.
> >
> > [1] https://gitlab.archlinux.org/archlinux/infrastructure/-/issues/6
> >
> > Greetings,
> >
> > Jelle van der Waa
>
> Could we get an ETA on the lawyer side when we can expect to make our
> GitLab open access?
>
> --
> Best,
> Daniel 
>

The ball is currently in their court again. We expected a response sooner
than this to be honest. Perhaps Levente needs to bug them again.

>

Re: [arch-dev-public] RFC Final Comment Period: Adoption of a distribution-wide Code of Conduct

[Sven-Hendrik Haase via arch-dev-public]

On 06.10.21 12:47, Allan McRae via arch-dev-public wrote:

On 27/9/21 4:33 am, David Runge via arch-dev-public wrote:

An RFC has now entered Final Comment Period. In 14 days, discussion will
end and the proposal will either be accepted, rejected or withdrawn:

https://gitlab.archlinux.org/archlinux/rfcs/-/merge_requests/6

Please visit the above link for discussion.

Note that visiting the above link to make a comment would require
agreeing to the Terms of Service, which includes the document under
discussion. However, the RFC process does allow discussion external to
the merge request, so people should feel free to respond elsewhere.

I do not disagree with Arch having *a* code of conduct. I disagree with
Arch formally adopting *this* code of conduct. As I stated in [1], I
find the current document to be extremely long. This is mostly due to
explaining points in a level of detail that I consider condescending to
the community. For example, I'm not sure a word other than condescending
can be used to describe explaining in great detail what a troll is to a
technical Linux distribution community.

I do not think Arch should formally adopt *this* code of conduct.

[1]
https://lists.archlinux.org/pipermail/arch-dev-public/2021-July/030474.html

Regards,
Allan


I think it's important to move forward here and I really like that David 
has been keeping the ball rolling for so long. We've also blocked for a 
really long time on getting a proper set of documents for GDPR 
compliance in the form of ToS and the Privacy Policy.


I don't think it's condescending. If anything, the level of detail 
things are explained in make it easier to refer to this document alone 
when pointing our digressions as opposed to having to refer to external 
resources. The length doesn't appear to be unreasonable to me but I see 
how it could be improved.


However, I think it's somewhat necessary to get _something_ in place 
here as a CoC. Having something (even perhaps something that you think 
has some need of shortening) is certainly better than no CoC at all! As 
a compromise, I suggest perhaps pulling more detailed content (such as 
the stuff that you deem to be condescending) into foot notes so that the 
main body of the document will become a bit more focused and less 
explanatory. Would that work for you?


You appear to generally be agreeing to the overall do's and don'ts (as 
your MR's [0] overall points are about the same). I therefore would like 
to implore you to roll with this version for now and then improve upon 
it as a direct follow up.


We have to be careful not to burn out David here with too much 
controversy as when that happens, no one will be here to pick up this 
topic and there won't be any CoC at all.


Cheers,
Sven

[0] 
https://gitlab.archlinux.org/archlinux/service-agreements/-/merge_requests/14




OpenPGP_signature
Description: OpenPGP digital signature

Re: [arch-dev-public] Starting x86_64_v3 port

[Sven-Hendrik Haase via arch-dev-public]

On Sat, 29 Jan 2022 at 15:17, Pierre Schmitz via arch-dev-public <
arch-dev-public@lists.archlinux.org> wrote:

> On Sat, Jan 29, 2022 at 2:49 PM Allan McRae via arch-dev-public
>  wrote:
> > Assuming we need people to help the x86_64_v3 port, I would post a news
> > item and have people apply.  We have advertised developer positions in
> > the past and received dozens of applications, and readily filled the
> > available positions with quality applicants.  They would be brought on
> > as Package Maintainers (once approved on the staff list) with access to
> > [extra] and [community], and have packaging privileges including being
> > added to the keyring.
> >
> > While advertising for x86_64_v3 specific packagers, we should make a
> > list of other packaging areas needing help and recruit for those too.
>
> While I would have preferred to gradually have raised the CPU
> requirements of our main repo (e.g. v2 right now and v3 in a few
> years), maintaining two x86_64 variants for a transition period might
> work. Nonetheless we should in work on how to get Arch back to be
> bleeding edge regardless of this. One aspect might be to reduce the
> overall amount of packages and get rid of unmaintained software
> (either by us or upstream).
>
> As the vast majority of hardware is v3 already we should consider
> x86_64 ( when support for such CPUs will be dropped. Personally I would only
> use and test on v3 once it is available. While not all of you might
> agree right now, this is how it will end up eventually, like it did
> with i686. Long story short: we might be looking for people
> maintaining the x86_64 repos and not the v3 ones.
>
> Greetings,
>
> Pierre
>
> --
> Pierre Schmitz, https://pierre-schmitz.com


This wouldn't really be too much of an issue if we had proper automation.
With automation, this exact problem solves itself to a degree. Surely there
will still be specific breakages now and then but the bulk of the burden
will go away. We'd even be able to support other targets with ease.

However, I realize this will require a lot of upfront infra work before
we're there and I'm not sure we should block this proposal on that work.

If we don't eventually get good automation (and packages in git), this
kinda problem will keep reoccurring. Sadly I don't really have time to work
on this right now though I'd love to.

Sven

Re: [arch-dev-public] [RFC] archweb nvchecker integration

[Sven-Hendrik Haase via arch-dev-public]

On 31.01.22 21:25, 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


I got nothing to add to what the others have said but I just wanted to 
say that this is awesome and thank you for the effort. :)


Sven


OpenPGP_signature
Description: OpenPGP digital signature

Re: [arch-dev-public] Scope of arch-projects mailing list

[Sven-Hendrik Haase via arch-dev-public]

On 03.02.22 12:53, David Runge via arch-dev-public wrote:

Hi all,

while trying to use the arch-projects mailing list for an announcement I
realized, that it is (probably?) not really supposed to be used for
that at the moment.

It explicitly states to be used for development discussion and providing
patches for dbscripts, devtools, mkinitcpio, namcap, netctl, archweb and
pyalpm.

It seems that apart from netctl none of the above really make much use
of this anymore though when it comes to development, as the projects
have pivoted towards merge/pull requests on their respective VCS forges.

Unless there are any objections, I propose to

* add arch-repo-management and arch-release-promotion to it


Sure.


* change arch-projects to *also* become a general discussion list around
   the above mentioned Arch Linux projects


Ok.


* extend mailing list "about" section with information on how each
   project prefers to receive patches (e.g. I do not want to use the
   mailing list for that, but others may)


Yeah that's probably good.



Rationale:
We lack a mailing list that revolves around our internal projects and
which can also be used by non "elevated users" (such as Trusted Users
and Developers) for more general discussion.
Given the very low traffic on the arch-projects mailing list I see no
issue with it becoming a per-project discussion list as well (as in our
case mailing lists seem to be mainly used for discussion and not so much
for development anymore these days).

Best,
David



I think that makes sense. Go for it!

Sven


OpenPGP_signature
Description: OpenPGP digital signature