Re: [arch-dev-public] News draft: Archlinux mailing list id changes

[Morten Linderud via arch-dev-public]

On Tue, Dec 29, 2020 at 07:23:34PM +0100, Frederik Schwan via arch-dev-public 
wrote:
> Subject: News draft: Archlinux mailing list id changes
   ^

Should be "Arch Linux". Rest looks good!

-- 
Morten Linderud
PGP: 9C02FF419FECBE16


signature.asc
Description: PGP signature

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

[Morten Linderud via arch-dev-public]

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

-- 
Morten Linderud
PGP: 9C02FF419FECBE16


signature.asc
Description: PGP signature

Re: [arch-dev-public] Chromium losing Sync support on March 15

[Morten Linderud via arch-dev-public]

On Tue, Jan 26, 2021 at 09:20:04PM +0200, Evangelos Foutras via arch-dev-public 
wrote:
> If people are still concerned about angering Google, even though
> there's probably nothing illegal about bundling Chrome's keys (when
> also considering the aforementioned permission from 2013) then let's
> just remove the package from our repos instead of officially providing
> a potentially unsafe and feature-incomplete browser.

Frankly, I'd love to "stick it to the Man" and bundle the chrome keys. It would
place Google in an interesting position. 

With that said... looking at the mailing list this feels like doing Google a
favour. Clearly they do not care about their users, and do not want us to
distribute the packages. Why help them keep users for a few more weeks and put
in a liable situation?

It's dissapointing frankly.

-- 
Morten Linderud
PGP: 9C02FF419FECBE16



signature.asc
Description: PGP signature

Re: [arch-dev-public] Chromium losing Sync support on March 15

[Morten Linderud via arch-dev-public]

On Wed, Jan 27, 2021 at 01:23:58AM +0200, Konstantin Gizdov via arch-dev-public 
wrote:
> I am not sure how this would be taken, but I propose we not only remove
> it from the repos, but we clean the AUR of Chromium and Chrome too and
> we enforce no one uploads any more such variants. This, I believe, is
> the only way the message will be loud and clear to our users because
> people will have to really share Chrome PKGBUILDs on 3rd party platforms
> as if it were illegal. In the end, this is what Google wants, right!? We
> cannot distribute Chrome's binary nor can we build a functioning
> Chromium. They essentially want their software no where near our _dirty_
> platform. I think we should abide.

I disagree on utilzing the AUR for an extended turf-war. Drop it from the
repositories and people can maintain it in the AUR. It's user contributed stuff
anyway and you are going to battle fork regardless for moderation purposes.

Is chrome banned? Ungoogled-chromium fine? Banned? What about other derivative
crap you suddenly need to actively ban and think about?

Assuming someone is even there to even hit the button on the deletion request.

> What is more, I believe if we do have access to a willing legal team, we
> should write and submit an official complaint to the EU ombudsman --
> Google are in fact crippling an open source alternative to their
> browser, limiting choice, disrupting the market place, coercing the
> "little man", etc. -- all things for which they were recently found
> guilty of and fined by the EU [1].

I don't think we should spend money on this.

-- 
Morten Linderud
PGP: 9C02FF419FECBE16



signature.asc
Description: PGP signature

Re: [arch-dev-public] Chromium losing Sync support on March 15

[Morten Linderud via arch-dev-public]

On Wed, Jan 27, 2021 at 03:19:09AM +0200, Konstantin Gizdov via arch-dev-public 
wrote:
> On 1/27/21 1:31 AM, Morten Linderud via arch-dev-public wrote:
> > I disagree on utilzing the AUR for an extended turf-war. Drop it from the
> > repositories and people can maintain it in the AUR. It's user contributed 
> > stuff
> > anyway and you are going to battle fork regardless for moderation purposes.
> > 
> > Is chrome banned? Ungoogled-chromium fine? Banned? What about other 
> > derivative
> > crap you suddenly need to actively ban and think about?
> > 
> > Assuming someone is even there to even hit the button on the deletion 
> > request.
> > 
> Correct me if I'm wrong. An AUR package will have to have the keys
> verbatim in the PKGBUILD. We would be essentially hosting this
> information on the AUR, which would be in violation of Google's new
> terms, right? So how are we going to allow such packages and not get a
> Cease and Desist?
> 
> On that point, we could grep by the value of the keys and delete
> automatically.

It doesn't matter. They wouldn't get anywhere with a cease and desist on some
semi-public strings in some PKGBUILD. It's user submitted content and we are not
breaking anything by giving people recipes for ToS/EULA breaking products of
said recipe.

This is how we can keep proprietary software in the AUR after all. Nothing
changes.

-- 
Morten Linderud
PGP: 9C02FF419FECBE16


signature.asc
Description: PGP signature

Re: [arch-dev-public] RFC: Using RFCs

[Morten Linderud via arch-dev-public]

On Mon, Feb 15, 2021 at 06:19:10PM +0100, David Runge via arch-dev-public wrote:
> This first RFC is rather special, as it is meant to bootstrap the
> process and introduce it for adoption (while the process is actually not
> yet in place). Therefore I am skipping the "Final Comment Period" on the
> issue tracker and instead move the proposal for adoption of the RFC
> process back to this mailing list for ratification (aka. the final ACK
> by you!).

A general concern is "who has access to the repository"? Can anyone take the
template and submit an RFC that we'd need to consider on the mailing list after
a subsequent discussion? I can see it clear as sky the day Gitlab opens and
someone figures they'll submit an RFC to move away from systemd to
sysvinit/openrc/runit clear as day.

Do we only allow pull-requests from staff with comments from users, or do we
allow anyone to send pull-requests? I'm not sure about the correct approach here
and curious if the concern is still premature at this stage.

-- 
Morten Linderud
PGP: 9C02FF419FECBE16


signature.asc
Description: PGP signature

Re: [arch-dev-public] RFC: Using RFCs

[Morten Linderud via arch-dev-public]

On Mon, Feb 15, 2021 at 06:45:02PM -0300, Giancarlo Razzolini wrote:
> Em fevereiro 15, 2021 15:27 Morten Linderud via arch-dev-public escreveu:
> > 
> > A general concern is "who has access to the repository"? Can anyone take the
> > template and submit an RFC that we'd need to consider on the mailing list 
> > after
> > a subsequent discussion? I can see it clear as sky the day Gitlab opens and
> > someone figures they'll submit an RFC to move away from systemd to
> > sysvinit/openrc/runit clear as day.
> > 
> 
> We discussed this and I think eventually anyone should be able to propose a 
> RFC. But,
> since as our gitlab isn't open and, the rfc requires an a-d-p announcement, 
> this is limited
> to staff members for now.
>
> The repository currently allows anyone with access to create MR's, but it can 
> be restricted to
> members only, if needed.

This doesn't address the issue and just reiterated the points? Gitlab is going
to be opened within the next months and we have users on Gitlab today. It's not
limited to staff.

Is it our obligation to propose any user-made RFC to a-d-p on behalf of them? Do
we want that?

The process is not clear and either assumes the RFC proposer can announce it, or
makes it implicit that it will be announced.

-- 
Morten Linderud
PGP: 9C02FF419FECBE16


signature.asc
Description: PGP signature

Re: [arch-dev-public] RFC: Using RFCs

[Morten Linderud via arch-dev-public]

On Tue, Feb 16, 2021 at 01:38:06PM -0300, Giancarlo Razzolini wrote:
> Em fevereiro 15, 2021 18:54 Morten Linderud escreveu:
> > On Mon, Feb 15, 2021 at 06:45:02PM -0300, Giancarlo Razzolini wrote:
> > > Em fevereiro 15, 2021 15:27 Morten Linderud via arch-dev-public escreveu:
> > > > > A general concern is "who has access to the repository"? Can
> > > anyone take the
> > > > template and submit an RFC that we'd need to consider on the mailing 
> > > > list after
> > > > a subsequent discussion? I can see it clear as sky the day Gitlab opens 
> > > > and
> > > > someone figures they'll submit an RFC to move away from systemd to
> > > > sysvinit/openrc/runit clear as day.
> > > >
> > > 
> > > We discussed this and I think eventually anyone should be able to propose 
> > > a RFC. But,
> > > since as our gitlab isn't open and, the rfc requires an a-d-p 
> > > announcement, this is limited
> > > to staff members for now.
> > > 
> > > The repository currently allows anyone with access to create MR's, but it 
> > > can be restricted to
> > > members only, if needed.
> > 
> > This doesn't address the issue and just reiterated the points? Gitlab is 
> > going
> > to be opened within the next months and we have users on Gitlab today. It's 
> > not
> > limited to staff.
> > 
> > Is it our obligation to propose any user-made RFC to a-d-p on behalf of 
> > them? Do
> > we want that?
> > 
> > The process is not clear and either assumes the RFC proposer can announce 
> > it, or
> > makes it implicit that it will be announced.
> > 
> 
> It's my understanding that Allan made some amendments that address this issue 
> specifically.
> But basically I think that a TU/Dev/Staff should be the one doing the post to 
> a-d-p after
> vetting/sponsoring the RFC. But I maintain that I think anyone should 
> eventually be able to
> create RFC's.

Yep!

My thinking after I went to bed is that if we do want user contribution it
should be explicitly handled in the process. I saw two suggestions:

1. A form of RFC sherparding where the person or a team ensures the
   submitted RFC are vetted and proposed properly.

2. Some form of explicit sponsoring by Devs and/or TUs.

If we don't have this the RFCs that can't be proposed by the submitter probably
wont be if the queue catches up to us. See the AUR requests piling up and
sometimes dealt with by a few people (or the bugtracker).

The first idea is essentially what NixOS does for all their RFCs[1]. But Allan
also came up with the second idea after reading this thread (I assume). I like
that amendment as we are probably not there yet where we need a sherparding
team.

Link for the folks following the thread:
https://gitlab.archlinux.org/allan/rfcs/-/commit/23dae7a83ea79f3b5da1e5c3b6c598266ae89b65

[1]: https://github.com/NixOS/rfcs/

-- 
Morten Linderud
PGP: 9C02FF419FECBE16


signature.asc
Description: PGP signature

Re: [arch-dev-public] News draft: Moving to Zstandard images by default on mkinitcpio

[Morten Linderud via arch-dev-public]

On Wed, Feb 17, 2021 at 11:40:58AM -0300, Giancarlo Razzolini via 
arch-dev-public wrote:
> Em fevereiro 17, 2021 11:13 Christian Hesse escreveu:
> > Giancarlo Razzolini via arch-dev-public 
> > 
> > on Wed, 2021/02/17 10:51:
> > > All official kernels of Arch Linux now support zstd compressed initramfs
> > > images, so mkinitcpio is switching to zstd compressed images by default on
> > > the version that is currently on [testing].
> > 
> > You should name the version number, just to make sure the context is not 
> > lost
> > after the move.
> > -- 
> 
> Good idea. I've reworked the text of the first paragraph to:
> 
> 
> As linux-lts moved to the 5.10 version, all official kernels of Arch Linux 
> now support zstd compressed
> initramfs images, so mkinitcpio is switching to zstd compressed images by 
> default with version 30,
> which is currently on [testing].
> 

Why the rush though? The kernels where released not even a day ago and why risk
breaking peoples setup? Even if partial upgrading the kernel is not recommended
it's a fairly common strategy. 

I'd rather wait a good week for people to have completed the upgrades. I
personally do this so I can chug along the testing repositories more easily and
not have to reboot every day for my webcam to work.

zstd is nice, but not lets-break-a-common-upgrade-strategy nice.

-- 
Morten Linderud
PGP: 9C02FF419FECBE16


signature.asc
Description: PGP signature

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

[Morten Linderud via arch-dev-public]

On Wed, Mar 03, 2021 at 11:00:38AM +, Filipe Laíns via arch-dev-public 
wrote:
> On Wed, 2021-03-03 at 20:52 +1000, Allan McRae via arch-dev-public wrote:
> > I'd hate to be the dbscripts maintainer who implements that!  Also,
> > $arch in mirror URLs would likely have issues, as it would need be
> > x86_64 unless there was a complete x86_64-v2 build.
> > 
> > I think a partial x86_64-v2 port would be more effort than having a full
> > one.
> > 
> > Allan
> 
> We are already rewriting dbscripts for the git migration anyway, so I think 
> it's
> worth exploring.

We are not rewriting anything (yet) and this is not happening unless more people
are interested hacking on the abmysmal dread that is dbscripts.

Nothing is going to be explored without someone willing to hack on the code, and
that has been few people.

-- 
Morten Linderud
PGP: 9C02FF419FECBE16


signature.asc
Description: PGP signature

[arch-dev-public] Killing python2 v3...v4...v5

[Morten Linderud via arch-dev-public]

Yo!

As people know python2 has been unsupported for a year and we current have ~170
python2 packages in our repositories. Currently the removal has been fairly slow
and done a bit ad-hoc. There has been a todo list but the follow up to that has
not really been great and I think it's reasonable for us to try and fix the
remaining packages to the best of our abilities.

Thus I'm proposing a game plan!

1) Todo list for removal of all python2 checkdepends in packages
2) Remove free python2 packages 
3) Remove packages with python3 equivalents
4) Remove unported and unsupported packages depending on python2

Clearly this is ambitious and there are going to be exceptions, but it would be
great to have most of this work done within the next couple of months.

The exceptions are largely going to be anything still using python2 for their
build system dependencies. This is a fine compromise as this should leave us
with a minimal set of packages to take care of.

Rest of the problematic packages can be found on a handy list with what fedora
is working on: https://fedora.portingdb.xyz/

If there are no objections I'll start preparing the needed todo lists and figure
out the uneeded python2 packages. Should probably update the long-standing
python2 removal todo as well.

https://archlinux.org/todo/conversion-of-programs-that-use-python-2-to-python-3/


Cheers!

-- 
Morten Linderud
PGP: 9C02FF419FECBE16


signature.asc
Description: PGP signature

Re: [arch-dev-public] Killing python2 v3...v4...v5

[Morten Linderud via arch-dev-public]

On Mon, Mar 15, 2021 at 02:46:52PM -0400, Eli Schwartz via arch-dev-public 
wrote:
> On 3/15/21 2:10 PM, Morten Linderud via arch-dev-public wrote:
> > Yo!
> > 
> > As people know python2 has been unsupported for a year and we current have 
> > ~170
> > python2 packages in our repositories. Currently the removal has been fairly 
> > slow
> > and done a bit ad-hoc. There has been a todo list but the follow up to that 
> > has
> > not really been great and I think it's reasonable for us to try and fix the
> > remaining packages to the best of our abilities.
> > 
> > Thus I'm proposing a game plan!
> > 
> > 1) Todo list for removal of all python2 checkdepends in packages
> 
> For the record, I'm not really happy about this since I feel we should
> endeavor to test all software in the repos. I don't believe python2
> should be an exception.
> 
> I believe we can do this right, though.
> 
> For example, yesterday you asked me directly about html5lib and its
> check dependency on the lxml, bs4, soupsieve build cycle dependency. I
> responded that I don't want to drop the testsuite entirely, however,
> lxml is an optional treebuilder for html5lib and we only have html5lib
> in the repos *anyway* due to being used in the leaf package "python2-pip".
> 
> So, I removed the checkdepends on python2-lxml, excluded the lxml
> treebuilder tests from the check() function, and stopped advertising
> lxml support in python2-html5lib:
> 
> https://git.archlinux.org/svntogit/community.git/commit/trunk?h=packages/python-html5lib&id=872eb6022921c71ef871bd9699f6353262f29b5c
> 
> However, I did not drop python2-pytest-expect since I need it to test
> the functionality which pip uses.
> 
> I would like to continue doing so...

I think investigating and fixing these cycles we have is a waste of time.

You asked for an example, you got it and you fixed it. Great! Was this one time
thing or are you going to keep looking for more packages you can remove this
way? What about other packagers that simply does not want to spend the time?

The point is that this just increases the effort needed to contribute killing
off the python2 packages we have. The loss of correctness for making it easier
to remove python2 packages is a net win. And keep in mind a minimum of people
are actively trying to remove packages at all.

It's important to realize that removing the checkdependencies makes it *so*
*much* *easier* to reason about dependency tree as the cycles are broken.

-- 
Morten Linderud
PGP: 9C02FF419FECBE16


signature.asc
Description: PGP signature

Re: [arch-dev-public] Killing python2 v3...v4...v5

[Morten Linderud via arch-dev-public]

On Mon, Mar 15, 2021 at 09:39:12PM +0100, Jelle van der Waa via arch-dev-public 
wrote:
> FYI,
> 
> A list of packages in our repository that require python2 but are not
> required by anything else:
> 
> wesnoth
> wifite
> android-tools
> arduino
> dia
> geda-gaf
> ghidra
> gif2png
> john
> opensips
> pycharm-community-edition
> python-pywal
> 389-ds-base
> dia
> distorm
> geda-gaf
> grafana-zabbix
> i810-dri
> mach64-dri
> mattermost
> mga-dri
> pypy3

I believe `crda` as well. Which is in core and shouldn't(?) be needed anymore.

-- 
Morten Linderud
PGP: 9C02FF419FECBE16


signature.asc
Description: PGP signature

Re: [arch-dev-public] archlinux-tools group

[Morten Linderud via arch-dev-public]

On Sat, Apr 24, 2021 at 04:55:19PM -0400, Santiago Torres-Arias via 
arch-dev-public wrote:
> On Sat, Apr 24, 2021 at 10:43:38PM +0200, Jelle van der Waa via 
> arch-dev-public wrote:
> > Hi All,
> > 
> > I've introduced a new group "archlinux-tools" for arch-rebuild-order and
> > orhun will add it to arch-repro-status. I'm planning to add arch-signoff,
> > and ask Fox to add archlinux-contrib as well.
> > 
> > The idea is that Arch Linux related tools which benefit packaging get added
> > to the archlinux-tools group.
> 
> I'm confused though, wasn't the goal of -contrib to be exactly
> this?

It is, but Rust/Go/Complicated Python projects lend them themself poorly to a
project intended for scripts.

> Feels that we could get away with making it all -contrib...

Then someone would need to figure out how to stuff it into the contrib :)

-- 
Morten Linderud
PGP: 9C02FF419FECBE16


signature.asc
Description: PGP signature

Re: [arch-dev-public] archlinux.org update

[Morten Linderud via arch-dev-public]

On Thu, Apr 29, 2021 at 12:00:34AM +0200, Jelle van der Waa via arch-dev-public 
wrote:
> Hi All,
> 
> Today I've updated archlinux.org with some interesting changes for
> packagers. Two new reports have been added:
> 
> * A new report which includes all required orphan packages in our
> repositories. [1]
> * A new report which which includes all orphan non reproducible packages [2]
> 
> The non reproducible packages dashboard now includes links to the build log
> and diffoscope output of the packages. Which should help fixing those
> packages.
> 
> Lastly archweb now parses the links databases which exists in our
> repository. So as alternative to 'sogrep'
> 
> curl -s "https://archlinux.org/packages/sonames?name=libwebsockets.so"; | jq
> '.[].pkgname'
> "kismet"
> "libwebsockets"
> "ardour"
> "csound"
> "mosquitto"
> "kismet"
> "libwebsockets"
> 
> This is still a bit alpha-ish as there seems to be some issues with updating
> the data. [4]
> 
> Feedback is welcome, as I just realized it shows packages for all
> repositories so some people might want a filter on "stable" or "testing" or
> "staging" repositories.
> 
> Finally what sonames the package requires is shown in the package detail
> page [6]


This is great :) Awesome work!

-- 
Morten Linderud
PGP: 9C02FF419FECBE16


signature.asc
Description: PGP signature

[arch-dev-public] gnupg 2.3.1-1 pulled from [testing]

[Morten Linderud via arch-dev-public]

Yo!

It seems like gnupg 2.3.1-1 was built and pushed to [testing] briefly before
being removed. The reason from the removal is because there are changes to how
gnupg verifies signatures that depends on the key UIDs being properly signed.

In the case of my key, "foxbo...@archlinux.org" is of marginal trust while
"mor...@linderud.pw" is fully trusted. Since packages are signed with "--sender
foxbo...@archlinux.org" gnupg cares about this trust level starting from
2.3.0-1. This results in failing signature checks if you have this package and
attempt to fetch packages signed by me.

Related issue:
https://dev.gnupg.org/T4735

Why was this removed with no headsup? It caused a fair bit of confusion for a
few people and the cause of this issue isn't very clear when packaged fail to
verify. Ideally we should have pushed gnupg with an epoch?


To testers:
The best course of action is to downgrade the gnupg package to 2.2.27-1 
from the
package archive or your local package cache.

https://archive.archlinux.org/packages/g/gnupg/


 gnupg is terrible :) 

-- 
Morten Linderud
PGP: 9C02FF419FECBE16


signature.asc
Description: PGP signature

Re: [arch-dev-public] gnupg 2.3.1-1 pulled from [testing]

[Morten Linderud via arch-dev-public]

On Tue, May 11, 2021 at 08:28:24AM -0400, Lukas Fleischer wrote:
> Hi Morten,
> 
> Thanks for the summary.

Yoo!

Thanks for explaining :)

> On Mon, 10 May 2021 at 13:31:13, Morten Linderud via arch-dev-public wrote:
> > Why was this removed with no headsup? It caused a fair bit of confusion for 
> > a
> > few people and the cause of this issue isn't very clear when packaged fail 
> > to
> > verify. Ideally we should have pushed gnupg with an epoch?
> 
> I removed the package after Jan informed me yesterday that the package
> is broken. Apologies for not making a public announcement; I should have
> send an email to our mailing lists.

No worries. People started bugging me on IRC and there is now a thread on the
subreddit as well. I thought I'd just send one before people started sending me
personal emails about some weird conspiracies about compromised signing keys :p

> The package has two undocumented patches, one to remove a warning and
> another one that's required for pacman. I was not aware that pacman
> required a patched version of GnuPG and will work on porting/rebasing
> and documenting the patches before pushing a new build.

Thanks! But it's probably a few more changes with the signing UIDs we need to
account for. I believe Santiago and/or Jonas can explain but it would probably
be better to share the package on the mailing list or throw it into staging so
we can look at it before it enters testing.

> When it comes to pushing with epoch, my understanding was that it is
> expected that packages break occasionally in [testing] and might get
> dropped. The recommendation for all [testing] users used to be to
> subscribe to arch-dev-public where dropped packages are (or at least
> should be) announced. Do we want to provide upgrade paths for broken
> packages in [testing]?

I'm not sure about if we traditionally drop packages from testing or do an 
epoch.
I might be wrong and developers probably have a stronger opinion. 

Ideally testers should follow arch-dev-public closely. I thought it was
mentioned somewhere but it apparently hasn't been on the testing team wikipage.
NetSysFire has added a note for it :)

https://wiki.archlinux.org/title/Arch_Testing_Team

Thanks!

-- 
Morten Linderud
PGP: 9C02FF419FECBE16


signature.asc
Description: PGP signature

Re: [arch-dev-public] gnupg 2.3.1-1 pulled from [testing]

[Morten Linderud via arch-dev-public]

On Tue, May 11, 2021 at 11:15:50PM +1000, Allan McRae via arch-dev-public wrote:
> I'd also like to query why 2.3.x was packaged at all?  From the 2.3
> series announcement:
> 
> "We are pleased to announce the availability of a new GnuPG release:
> version 2.3.0. This release marks the start of public testing releases
> eventually leading to a new stable version 2.4."
> 
> It seems that we should stay with 2.2.x until 2.4 is released, and the
> out-of-date flag should be ignored.  That will give time to fix the
> fallout from this change (which is the root cause of the issue that was
> noticed):
> https://dev.gnupg.org/T4735

Consider the announcement for the 2.3.1 release:

"Although some bugs might linger in the 2.3 versions, they are intended
to replace the 2.2 series."

I'm not sure if the note was only intended for the 2.3.0 release?

https://lists.gnupg.org/pipermail/gnupg-announce/2021q2/000459.html

-- 
Morten Linderud
PGP: 9C02FF419FECBE16


signature.asc
Description: PGP signature

Re: [arch-dev-public] New Arch Linux Developer: Jonas Witschel (diabonas)

[Morten Linderud via arch-dev-public]

On Sun, May 16, 2021 at 12:38:39AM +0200, Jonas Witschel via arch-dev-public 
wrote:
> Hi everyone,
> 
> On 2021-05-16 00:28, Levente Polyak via arch-dev-public wrote:
> > I would like to welcome Jonas Witschel (diabonas) among the Arch Linux
> > Developers.
> > 
> > Jonas has been a Trusted User since 2019 and lately joined the Arch Linux
> > Security Team.
> > 
> > We wish you good luck and joy with your new responsibilities within Arch
> > Linux!
> 
> thank you for your trust, I am excited to be part of the team! So many systems
> to break, so little time ;)

Congratz from a very proud TU sponsor<3

-- 
Morten Linderud
PGP: 9C02FF419FECBE16


signature.asc
Description: PGP signature

Re: [arch-dev-public] New Arch Linux Developer: Jonas Witschel (diabonas)

[Morten Linderud via arch-dev-public]

On Sun, May 16, 2021 at 12:45:13AM +0200, Morten Linderud wrote:
> On Sun, May 16, 2021 at 12:38:39AM +0200, Jonas Witschel via arch-dev-public 
> wrote:
> > Hi everyone,
> > 
> > On 2021-05-16 00:28, Levente Polyak via arch-dev-public wrote:
> > > I would like to welcome Jonas Witschel (diabonas) among the Arch Linux
> > > Developers.
> > > 
> > > Jonas has been a Trusted User since 2019 and lately joined the Arch Linux
> > > Security Team.
> > > 
> > > We wish you good luck and joy with your new responsibilities within Arch
> > > Linux!
> > 
> > thank you for your trust, I am excited to be part of the team! So many 
> > systems
> > to break, so little time ;)
> 
> Congratz from a very proud TU sponsor<3

I realized I didn't sponsor Jonas. I mixed up you and Maxim!
Ah awkward :)

-- 
Morten Linderud
PGP: 9C02FF419FECBE16

Re: [arch-dev-public] packager key revokation

[Morten Linderud via arch-dev-public]

Yo Andrzej :)

I hope you are doing fine despite the circumstances!

I adopted a few of your packages when you announced this in October. I'm just
going to paste the current list of your packages missing a co-maintainer so
people have a list.

I'll probably try pick up a bunch of the python-* stuff unless people are
looking for stuff to maintain.


λ ~ » pkgsearch -m aginiewicz -l 1
blosc
dhex
dsdp
languagetool
mayavi
python-apptools
python-blosc
python-bottleneck
python-envisage
python-et-xmlfile
python-fonttools
python-googleapis-common-protos
python-jdcal
python-joblib
python-numexpr
python-oauth2client
python-openpyxl
python-patsy
python-pyface
python-requests-file
python-requests-ftp
python-scikit-build
python-scikit-learn
python-seaborn
python-statsmodels
python-threadpoolctl
python-traits
python-traitsui
python-unicodedata2
python-uritemplate
python-xlrd
python-xlsxwriter
python-xlwt
unionfs-fuse

-- 
Morten Linderud
PGP: 9C02FF419FECBE16


signature.asc
Description: PGP signature

[arch-dev-public] Gone for the next couple of weeks

[Morten Linderud via arch-dev-public]

Yo!

Sunday evening I'm heading for a cabin trip where we don't have water and
electricity is all solar power my dad rigged up a couple of years ago :) It's
going to be great. I'm also moving from Bergen to Oslo next weekend! I need to
spend some time to settle inn I expect I'll do less upkeep on my regular package
maintaining as a result (also getting vaccinated 🥳).

I should still be reachable on Matrix or Signal if there is anything urgent, but
might not keep that much up with email! I have attached a list of packages I'm
the sole maintainer of, but there is nothing here which should require anything
urgent while I'm gone 😃.

Have a lovely summer!


If you want to adopt and need nvchecker stuff, please do check my repo:
https://github.com/Foxboron/archlinux-pkgbuilds/blob/master/.repo/packages.toml

λ ~ » /usr/bin/pkgsearch -m Foxboron
archlinux-contrib
archlinux-repro
b4
barrier
bmusb
bucklespring
catatonit
cni-plugins
conmon
crun
dqlite
flatpak-xdg-utils
fuse-overlayfs
gopls
go-tools
hy
i3-gaps
influxdb
jgmenu
libmd
libslirp
mopidy
nageru
nano-syntax-highlighting
pass-otp
pdfjs
perl-data-perl
perl-gnupg-interface
perl-moox-handlesvia
perl-moox-late
perl-strictures
perl-sub-handlesvia
perl-type-tiny
plocate
podman-dnsname
protege
python2-docs
python2-typing
python-adblock
python-babel
python-docs
python-dotty-dict
python-flask-babel
python-guzzle-sphinx-theme
python-halo
python-hid
python-hjson
python-jsonrpclib-pelix
python-keyutils
python-ldap
python-log_symbols
python-m2crypto
python-milc
python-nbxmpp
python-nltk
python-pew
python-pydbus
python-pydocstyle
python-pydrive
python-pygame
python-pykka
python-pypeg2
python-pywal
python-reportlab
python-rope
python-send2trash
python-shutilwhich
python-speaklater
python-sphinx-autorun
python-spinners
python-sqlobject
python-sqlparse
python-typed-ast
python-xlib
qmk
qprint
raft
runc
screenkey
signing-party
skopeo
slirp4netns
staticcheck
step-ca
tailscale
toolbox
vim-ultisnips

-- 
Morten Linderud
PGP: 9C02FF419FECBE16


signature.asc
Description: PGP signature

[arch-dev-public] Go 1.17 released - to rebuild or not to rebuild

[Morten Linderud via arch-dev-public]

Yo,

I packaged up the new Go release yesterday and moved it over to stable earlier
today. 

Usually new Go minor releases frequently include new compiler improvements and
some assorted runtime changes. Previous releases I have done complete rebuilds
of Go packages in our repositories but the reception for these rebuilds have
been a bit mixed.

People do not really see the need to rebuild $goWorld when packages a compiled
and nothing inherently breaks unless there is a rebuild. We don't do this for
GCC, Rust and so on. However I do think it's nice to group up these ecosystem
changes in one swoop as it spares me from having to repeat myself for the next
few months as people occasionally update their Go packages.

But on the other hand I'm not super eager to be alone rebuilding all of this
either. So what are peoples thoughts on the subject?


Go 1.1 release notes: https://golang.org/doc/go1.17 
Previous rebuild: https://archlinux.org/todo/go-116-rebuild/

-- 
Morten Linderud
PGP: 9C02FF419FECBE16


signature.asc
Description: PGP signature

Re: [arch-dev-public] linux-firmware package, some thoughts

[Morten Linderud via arch-dev-public]

On Tue, Sep 28, 2021 at 08:34:45AM +0200, Tobias Powalowski via arch-dev-public 
wrote:
> Hi,
> short summarize from irc:
> https://fedoraproject.org/wiki/Changes/CompressKernelFirmware
> xz -C crc32 is the only supported mode
> 
> mkinitcpio needs to be patched:
> https://bugs.archlinux.org/task/72263
> 
> From my side unknown, if dracut and booster can handle compressed firmware
> files.

Namarrgon submitted a WIP patch for this in August as a side-note.

https://github.com/archlinux/mkinitcpio/pull/65

-- 
Morten Linderud
PGP: 9C02FF419FECBE16


signature.asc
Description: PGP signature

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

[Morten Linderud via arch-dev-public]

On Fri, Oct 08, 2021 at 07:24:58PM +1000, Allan McRae via arch-dev-public wrote:
> On 8/10/21 6:01 pm, David Runge wrote:
> > Starting a discussion about the length and form of the Code of Conduct
> > *after* not interacting with the own changes to the Code of Conduct that
> > would fix it, *after* not interacting with the RFC that wants to
> > establish the CoC distribution-wide during its comment period and also
> > *after* not interacting with the changes that were done last to the CoC
> > (which in fact you gave the initial idea for and were informed about its
> > progress multiple times) by Jonas and I, but instead complained about
> > *after the fact*, to me, quite frankly at this point feels nothing short
> > of condescending and disrespectful.
> 
> The RFC does not give the option of an edited version of the Code of
> Conduct being adopted.  The RFC states that the Code of Conduct "is
> hereby officially adopted in its current form".  Hence the RFC is about
> adopting the *current* version of the Code of Conduct, which I object to.

I'm not sure why you stopped reading after that part. The next section specifies
that it's a living document and changes can be merged going forward.

"The Code of Conduct is a living document that may change over time. Changes
are applied by merge request towards the `Service Agreements repository
`_. Any
contributions follow the repository's contribution guidelines."

Which should satisfy your current problem with the document as-is. We can amend
and fix it at a later point regardless. Your current issues with the document
isn't a good enough reason to block this process, and we can work it out at a
later point.

-- 
Morten Linderud
PGP: 9C02FF419FECBE16


signature.asc
Description: PGP signature

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

[Morten Linderud via arch-dev-public]

On Fri, Oct 08, 2021 at 09:40:24PM +1000, Allan McRae via arch-dev-public wrote:
> On 8/10/21 9:31 pm, Morten Linderud via arch-dev-public wrote:
> > On Fri, Oct 08, 2021 at 07:24:58PM +1000, Allan McRae via arch-dev-public 
> > wrote:
> >> On 8/10/21 6:01 pm, David Runge wrote:
> >>> Starting a discussion about the length and form of the Code of Conduct
> >>> *after* not interacting with the own changes to the Code of Conduct that
> >>> would fix it, *after* not interacting with the RFC that wants to
> >>> establish the CoC distribution-wide during its comment period and also
> >>> *after* not interacting with the changes that were done last to the CoC
> >>> (which in fact you gave the initial idea for and were informed about its
> >>> progress multiple times) by Jonas and I, but instead complained about
> >>> *after the fact*, to me, quite frankly at this point feels nothing short
> >>> of condescending and disrespectful.
> >>
> >> The RFC does not give the option of an edited version of the Code of
> >> Conduct being adopted.  The RFC states that the Code of Conduct "is
> >> hereby officially adopted in its current form".  Hence the RFC is about
> >> adopting the *current* version of the Code of Conduct, which I object to.
> > 
> > I'm not sure why you stopped reading after that part. The next section 
> > specifies
> > that it's a living document and changes can be merged going forward.
> > 
> > "The Code of Conduct is a living document that may change over time. 
> > Changes
> > are applied by merge request towards the `Service Agreements repository
> > <https://gitlab.archlinux.org/archlinux/service-agreements/>`_. Any
> > contributions follow the repository's contribution guidelines."
> > 
> > Which should satisfy your current problem with the document as-is. We can 
> > amend
> > and fix it at a later point regardless. Your current issues with the 
> > document
> > isn't a good enough reason to block this process, and we can work it out at 
> > a
> > later point.
> 
> That would apply if I thought the current version was good enough for
> formal adoption.  However, I think the current version is unacceptable.

You still have your open Merge Request you can work on after this RFC has been
accepted. Or do you want us to pause this RFC until your rewrite is complete? Do
you have any expectations when you will have more time to work on it?

-- 
Morten Linderud
PGP: 9C02FF419FECBE16


signature.asc
Description: PGP signature

Re: [arch-dev-public] Arch Monthly Report - November

[Morten Linderud via arch-dev-public]

On Wed, Nov 17, 2021 at 10:27:12PM +1000, Allan McRae via arch-dev-public wrote:
> On 17/11/21 22:03, Jelle van der Waa via arch-dev-public wrote:
> > ## DBScripts
> > 
> > There has been great progress on debug support for dbscripts , review
> > and testing is very much appreciated. [1]
> 
> I reviewed the code changes in detail many, many months ago, and again when
> I reviewed the test suite changes about 2 months ago.  Apart from a minor
> issue with the testsuite (I flagged those on github), I consider the changes
> ready.

Turns out I have in many places written "$pkgname" instead of "$pkgbase", so 
split
package support with debug packages is just plainly broken :)

Needs a little bit more work sadly but most likely achievable within 2021!

-- 
Morten Linderud
PGP: 9C02FF419FECBE16


signature.asc
Description: PGP signature

Re: [arch-dev-public] community.files pacman database corrupt

[Morten Linderud via arch-dev-public]

On Tue, Dec 21, 2021 at 05:43:44PM +0100, Pierre Schmitz via arch-dev-public 
wrote:
> Hi all,
> 
> seems to have happened again: the desc file of lxqt-runner had 0
> bytes. I re-added the package. I got the following output. I did not
> get the "...was not locked" message when trying again. Maybe our
> locking does not work as expected:
> 
> ==> ERROR: Repo [community] (x86_64) is already locked by
> repo-{add,remove} process 2150481
> ==> WARNING: Repo [community-debug] (x86_64) is already locked by svenstaro.
>   -> Retrying in 10 seconds...
> ==> Adding lxqt-runner-1.0.0-1-x86_64.pkg.tar.zst to [community]...
> ==> WARNING: An entry for 'lxqt-runner-1.0.0-1' already existed
> ==> WARNING: Repo lock [community] (x86_64) was not locked!

So I'm a little bit unsure what is expected behaviour and what isn't.

I have an annotated version of the log with what happens in the above log
output. Note that the tacke on -debug repositories is what was added last week.


* db-repo-add gets ran
* runs `repo_lock` -> `_repo_lock community`, `_ repo_lock community-debug`

==> ERROR: Repo [community] (x86_64) is already locked by repo-{add,remove} 
process 2150481
* `_repo_lock` checks if the `community.db.lck` exists.
* this file is created by repo-add/repo-remove.
* `_repo_lock` return 1, this exit code is never checked
* Note that we never locked anything. We returned early.

==> WARNING: Repo [community-debug] (x86_64) is already locked by svenstaro.
  -> Retrying in 10 seconds...
* same is done for `community-debug`
* we don't have `community.db.lck` so we continue
* timeout happens because svenstaro is modifying the repository
* we lock `community-debug`
* `_repo_lock` returns 0, exit code is never checked

==> Adding lxqt-runner-1.0.0-1-x86_64.pkg.tar.zst to [community]...
==> WARNING: An entry for 'lxqt-runner-1.0.0-1' already existed
* We continue adding package

* We run `repo_unlock` -> `_repo_unlock community`, `_repo_unlock 
community-debug`

==> WARNING: Repo lock [community] (x86_64) was not locked!
* `_repo_unlock` checks if `community` is locked.
* It isn't, return and give warning

* `_repo_unlock` unlocks `community-debug`
* unlocked properly and returns

I'm not sure if this is new behaviour. It seems like most of this workflow was
there before my debug package implementation. But I'm not sure if this is the
actual root of the bug?

Does anyone know if `repo-add` and `repo-remove` maybe doesn't have proper lock
checking? Could there be a race here?

-- 
Morten Linderud
PGP: 9C02FF419FECBE16


signature.asc
Description: PGP signature

Re: [arch-dev-public] Fun with LTO and stripping

[Morten Linderud via arch-dev-public]

Just an additional headsup as we are on the topic of "LTO fun"; it seems like
any Go packages utilizing cgo/the external linker seems to be just broken with
LTO.

The error looks like:
net._cgo_3c1cec0c9a4e_C2func_getaddrinfo: relocation target 
_cgo_3c1cec0c9a4e_C2func_getaddrinfo not defined

Please do just disable LTO if you spot this issue in your builds.

-- 
Morten Linderud
PGP: 9C02FF419FECBE16


signature.asc
Description: PGP signature

Re: [arch-dev-public] Updates to archlinux-keyring and signatures for packager keys

[Morten Linderud via arch-dev-public]

On Fri, Jan 14, 2022 at 09:12:37PM +0100, David Runge via arch-dev-public wrote:
> If you have gained more than or equal to three main key signatures for
> your new PGP key and the key as well as those signatures are already
> available in the keyring in [core] please rebuild all of your packages
> using your new key and start the process of having your old key removed
> [4].
>
> For the purpose of mass package rebuilding you may create a TODO [5] and
> use `rebuild-todo` (in the archlinux-contrib package) which makes use of
> our build server infrastructure.

Just to be a bit fun and showcasing contrib tooling. You don't actually *need*
to create a TODO for rebuild-todo. You can pipe a search from `pkgsearch` (also
from contrib, previously named co-maintainers) directly into `rebuild-todo`.

$ pkgsearch -p Foxboron -r community | rebuild-todo --community -m "package 
rebuild" -

This would rebuild all my packages from communtiy. pkgsearch is a bit slow, but
I promise that it works :)

Please do note that `rebuild-todo` won't necessarily keep track of what it has
and hasn't rebuilt. Also do note you need to specify the repositories since
`rebuild-todo` doesn't understand where packages belong :)

Hopefully I'll get some more tooling improvements done for package rebuilds. But
this is already quite neat and handy.

-- 
Morten Linderud
PGP: 9C02FF419FECBE16


signature.asc
Description: PGP signature

Re: [arch-dev-public] Updates to archlinux-keyring and signatures for packager keys

[Morten Linderud via arch-dev-public]

On Fri, Jan 14, 2022 at 04:57:00PM -0800, Brett Cornwall via arch-dev-public 
wrote:
> On 2022-01-14 21:12, David Runge via arch-dev-public wrote:
> > To all that have added a new @archlinux.org UID or have created a new
> > key, please make sure that all signatures you have received from main
> > signing keys are also present in the current keyring (`pacman-key
> > --list-sigs @archlinux.org`) or in the current HEAD of
> > archlinux-keyring (`./keyringctl inspect ` in a clone of the
> > archlinux-keyring repository). If you have signatures that are not yet
> > in the keyring, you can add them yourself [2] and do not have to wait on
> > a main signing key holder to do it.
> 
> Thanks for your work on this initiative.
> 
> I see that my key has made it but the trust is only marginal:
> 
> 
> [~]$ pacman -Q archlinux-keyring
> archlinux-keyring 20220114-1
> [~]$ pacman-key --list-sigs ain...@archlinux.org
> gpg: Note: trustdb not writable
> pub   ed25519 2018-10-03 [SC] [expires: 2022-07-18]
>   BE2DBCF2B1E3E588AC325AEAA06B49470F8E620A
> [snip]
> uid   [marginal] Brett Cornwall 
> sig 3A06B49470F8E620A 2021-11-18  Brett Cornwall 
> sig  4DC95B6D7BE9892E 2021-11-20  David Runge (Arch Linux Master Key) 
> 
> 
> 
> 
> Is this expected behavior?

No it's not :)

It seems like you haven't pulled the signature from Florian which is on your
issue. But you still need one signature for full trust.

This means you still need to sign packages with the br...@i--b.com UID.

-- 
Morten Linderud
PGP: 9C02FF419FECBE16


signature.asc
Description: PGP signature

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

[Morten Linderud via arch-dev-public]

On Sat, Jan 29, 2022 at 10:12:30AM +1000, Allan McRae via arch-dev-public wrote:
> Is there any particular objection to requiring packagers upload both
> architectures?

I'm personally not really motivated doing the required builds. We have an
underdeveloped infrastructure which hasn't changed since we abandoned i686 5
years ago.

I'd personally like to see more work on our build tooling before we commit to
new architectures.

-- 
Morten Linderud
PGP: 9C02FF419FECBE16


signature.asc
Description: PGP signature

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

[Morten Linderud via arch-dev-public]

On Sat, Jan 29, 2022 at 11:22:32AM +1000, Allan McRae via arch-dev-public wrote:
> On 29/1/22 11:13, Morten Linderud via arch-dev-public wrote:
> > On Sat, Jan 29, 2022 at 10:12:30AM +1000, Allan McRae via arch-dev-public 
> > wrote:
> > > Is there any particular objection to requiring packagers upload both
> > > architectures?
> > 
> > I'm personally not really motivated doing the required builds. We have an
> > underdeveloped infrastructure which hasn't changed since we abandoned i686 5
> > years ago.
> > 
> > I'd personally like to see more work on our build tooling before we commit 
> > to
> > new architectures.
> 
> FYI, it is a single extra command.  Either of these will work...
> 
> offload-build --arch x86_64_v3
> extra-x86_64_v3-build
> 
> Nothing else changes for the packager.
> 
> Allan

I'll spend twice as long waiting for a package to build which increases the time
spent packaging. Which again requires me to spend more time watching stuff fly
by.

This also assumes people are capable of using the buildserver which is not
always the case either.

This wasn't great with i686, and I'm not sure why we'd find this acceptable
today?

-- 
Morten Linderud
PGP: 9C02FF419FECBE16


signature.asc
Description: PGP signature

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

[Morten Linderud via arch-dev-public]

On Sat, Jan 29, 2022 at 11:45:57AM +1000, Allan McRae via arch-dev-public wrote:
> On 29/1/22 11:28, Morten Linderud via arch-dev-public wrote:
> > On Sat, Jan 29, 2022 at 11:22:32AM +1000, Allan McRae via arch-dev-public 
> > wrote:
> > > On 29/1/22 11:13, Morten Linderud via arch-dev-public wrote:
> > > > On Sat, Jan 29, 2022 at 10:12:30AM +1000, Allan McRae via 
> > > > arch-dev-public wrote:
> > > > > Is there any particular objection to requiring packagers upload both
> > > > > architectures?
> > > > 
> > > > I'm personally not really motivated doing the required builds. We have 
> > > > an
> > > > underdeveloped infrastructure which hasn't changed since we abandoned 
> > > > i686 5
> > > > years ago.
> > > > 
> > > > I'd personally like to see more work on our build tooling before we 
> > > > commit to
> > > > new architectures.
> > > 
> > > FYI, it is a single extra command.  Either of these will work...
> > > 
> > > offload-build --arch x86_64_v3
> > > extra-x86_64_v3-build
> > > 
> > > Nothing else changes for the packager.
> > > 
> > > Allan
> > 
> > I'll spend twice as long waiting for a package to build which increases the 
> > time
> > spent packaging. Which again requires me to spend more time watching stuff 
> > fly
> > by.
> 
> I have concerns if that is how you spend your time...  :)
> 

I have plenty time left over to ask for pacman backports :) DO NOT WORRY!


> > This also assumes people are capable of using the buildserver which is not
> > always the case either.
> > 
> > This wasn't great with i686, and I'm not sure why we'd find this acceptable
> > today?
> 
> What was not great with i686?  We managed two architectures for many, many
> years.  The reason for removing i686 was to do with outdated technology, not
> to do with build times or infrastructure.
> 
> Do you have objections beyond not wanting to package for both repos? i.e. do
> you object to option C in my original email, where we have a team to keep
> the repos in sync when package maintainers do not build both?

I'm simply not sure where you are going to get the people for that and how you
want to deal with it?

A *lot* has changed since the x86_64 port. Bringing on people to do these
rebuild implies they need access to infrastructure, keyring and so on. And we
already have a staff shortage.

I'd like to see some details on how you envision C should be working first.

Generally my thoughts is that we shouldn't *need* to have a more manhours to
deal with a x86_64_v3. We should instead strenghten our staff and work on the
following:

* Signing enclave
* Better rebuilding tools
* Build automation
* Git migration

It would make discussions like these completely obsolete. Do we want v2, v3,
v4, v5, v90001? Enable it in a setting and we'd have the repos. It is a lot of
work but it would modernize and make things a lot simpler for us.

-- 
Morten Linderud
PGP: 9C02FF419FECBE16


signature.asc
Description: PGP signature

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

[Morten Linderud via arch-dev-public]

On Sat, Jan 29, 2022 at 10:53:41PM +1000, Allan McRae via arch-dev-public wrote:
> On 29/1/22 22:11, Morten Linderud via arch-dev-public wrote:
> > On Sat, Jan 29, 2022 at 11:45:57AM +1000, Allan McRae via arch-dev-public 
> > wrote:
> > > On 29/1/22 11:28, Morten Linderud via arch-dev-public wrote:
> > > > On Sat, Jan 29, 2022 at 11:22:32AM +1000, Allan McRae via 
> > > > arch-dev-public wrote:
> > > > > On 29/1/22 11:13, Morten Linderud via arch-dev-public wrote:
> > > > > > On Sat, Jan 29, 2022 at 10:12:30AM +1000, Allan McRae via 
> > > > > > arch-dev-public wrote:
> > > > > > > Is there any particular objection to requiring packagers upload 
> > > > > > > both
> > > > > > > architectures?
> > > > > > 
> > > > > > I'm personally not really motivated doing the required builds. We 
> > > > > > have an
> > > > > > underdeveloped infrastructure which hasn't changed since we 
> > > > > > abandoned i686 5
> > > > > > years ago.
> > > > > > 
> > > > > > I'd personally like to see more work on our build tooling before we 
> > > > > > commit to
> > > > > > new architectures.
> > > > > 
> > > > > FYI, it is a single extra command.  Either of these will work...
> > > > > 
> > > > > offload-build --arch x86_64_v3
> > > > > extra-x86_64_v3-build
> > > > > 
> > > > > Nothing else changes for the packager.
> > > > > 
> > > > > Allan
> > > > 
> > > > I'll spend twice as long waiting for a package to build which increases 
> > > > the time
> > > > spent packaging. Which again requires me to spend more time watching 
> > > > stuff fly
> > > > by.
> > > 
> > > I have concerns if that is how you spend your time...  :)
> > > 
> > 
> > I have plenty time left over to ask for pacman backports :) DO NOT WORRY!
> > 
> > 
> > > > This also assumes people are capable of using the buildserver which is 
> > > > not
> > > > always the case either.
> > > > 
> > > > This wasn't great with i686, and I'm not sure why we'd find this 
> > > > acceptable
> > > > today?
> > > 
> > > What was not great with i686?  We managed two architectures for many, many
> > > years.  The reason for removing i686 was to do with outdated technology, 
> > > not
> > > to do with build times or infrastructure.
> > > 
> > > Do you have objections beyond not wanting to package for both repos? i.e. 
> > > do
> > > you object to option C in my original email, where we have a team to keep
> > > the repos in sync when package maintainers do not build both?
> > 
> > I'm simply not sure where you are going to get the people for that and how 
> > you
> > want to deal with it?
> 
> There is community demand for this port - it will provide benefit for the
> majority of our users.  I'm sure I can find interested parties to join.
> 
> > A *lot* has changed since the x86_64 port. Bringing on people to do these
> > rebuild implies they need access to infrastructure, keyring and so on. And 
> > we
> > already have a staff shortage.
> > 
> > I'd like to see some details on how you envision C should be working first.
> 
> Exactly the same as it did in the i686/x86_64 days.  Some packagers will
> upload both variants, some will not.  There was a webpage that showed the
> package differences between the architectures and a group of people built
> and uploaded packages to keep x86_64 in sync.  This was particularly
> important when many devs did not have x86_64 hardware yet.
> 
> We may/will need to recruit some people to do these rebuilds.  The number of
> people needed depends on how many packagers would package for both
> architectures.

This doesn't explain what I wanted to know though.

Are you expecting we find 5-10-20 people and then onboard them as developers or 
TUs?

Are you envioning a seperate signing keyring, or are you planning on adding them
to the archlinux-keyring?

How are we dealing with access? Do they get full access to our package repos as
devs, or are you planning on a seperate role which has access to the required
repositories? This is relevant because of how dbscripts is deployed on gemini.

All of this requires a fair bit of planning and thought before it's a feasable
option to mention.

-- 
Morten Linderud
PGP: 9C02FF419FECBE16


signature.asc
Description: PGP signature

Re: [arch-dev-public] Signing enclave

[Morten Linderud via arch-dev-public]

On Sat, Jan 29, 2022 at 06:22:29PM +0100, Kristian Klausen via arch-dev-public 
wrote:
> Signing:
> - SSHing to a restricted UNIX user with ForceCommand=signing-script
> - All signing operations are logged
> - Only signing requests from gemini's WireGuard IP address is allowed

Some general thoughts about how we suppose to log these options.

We should preferably use a Transparency Log for these as it would give us
tamper evidence if our signing enclave gets compromised.

For people unfamiliar with Transparency Logs; 
https://transparency.dev/verifiable-data-structures/
It's the same technology as Certificate Transparency; 
https://datatracker.ietf.org/doc/html/rfc6962

We have few options here:

* Implement our own Trillian Log
* Use an existing implementation
* Use sigstore[1].

I'm a bit biased towards just using sigstore as it's essentially a continuation
of stuff i wrote about in my master thesis. It's also fairly trivial to
integrate towards and we don't need to host anything ourself. It's also funded
by our own Santiago :)

We would be using `rekor-cli` which would give us a lot of this for free.[2]

The other option is hosting our own log. This is not super trivial as we want
monitors and people replicating the log outside of our own organization to
ensure nobody can tamper with the log. The LVFS has opted for such an
implementation.

I personally think this is an important part of our signing infrastructure.

In the future we could have pacman ensure database signatures are present on the
Transparency Log which would prevent most of the trivial compromises of our
signing enclave.

Does anyone have any opinions around this or have any questions?

[1]: https://www.sigstore.dev/
[2]: https://docs.sigstore.dev/rekor/CLI

-- 
Morten Linderud
PGP: 9C02FF419FECBE16


signature.asc
Description: PGP signature

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

[Morten Linderud via arch-dev-public]

On Sat, Jan 29, 2022 at 09:35:07AM -0800, Brett Cornwall via arch-dev-public 
wrote:
> On 2022-01-29 15:16, Pierre Schmitz via arch-dev-public 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.
> 
> Indeed, I would rather that we just move everything to v3 instead of
> supporting different versions.
> 
> This seems the simplest way forward.

This was already discussed in our RFC and rejected. I'd prefer if we stick to
what was agreed on there. Multiple points was raised which is worth reading up
on.

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

-- 
Morten Linderud
PGP: 9C02FF419FECBE16


signature.asc
Description: PGP signature

[arch-dev-public] Debug packages for Arch Linux

[Morten Linderud via arch-dev-public]

I'm very happy to announce that debug packages in Arch Linux has been deployed 
:)

This work began after FOSDEM 2020 and was announced in November 2020. However
because of time constraints it took quite a while before we managed to deploy
it.

Currently we have a debuginfod service which is capable of delivering source
listings and debug symbols to users with gdb, delve and other debuggers. This
can be enabled by installing the `debuginfod` package and setting the
environment variable `DEBUGINFOD_URLS="https://debuginfod.archlinux.org"`. The
`debuginfod` package is also going to be providing this variable :)

The debug package repositories themself are not publicly accessible nor
distributed to our mirrors. This is because there is a general concern around
the repository size increase. The goal is to take a look at distributing them
and/or making them accessible in the future. 

Packages are being rebuilt for debug symbols where deemed needed by the packager
and I suspect we should have a discussion around enabling the debug option by
default or not. However see the section below around creating debug packages as
there are some caveats of the current approach.

I have added some links to the work that has been done to accomplish all of this
at the bottom of this email.

For general information about the instance one can look at the service itself:
https://debuginfod.archlinux.org/

Previous emails on this topic:
* 
https://lists.archlinux.org/pipermail/arch-dev-public/2020-November/030222.html
* 
https://lists.archlinux.org/pipermail/arch-dev-public/2021-December/030583.html


# archlinux.org news announcement

Suggestion for the news announcement on archweb. I'll post it in a day or two
unless there are any objections.

Subject: Debug packages and debuginfod
We are very happy to announce that debug packages are now available in Arch
Linux.

Debug symbols and source listing are provided through our debuginfod instance
which can be utilized by debuggers such as gdb and delve. In the future we are
planning to make these repositories public on our mirrors.

For more information on this please visit the
[archwiki](https://wiki.archlinux.org/title/Debuginfod) article, Or the
debuginfod service.

https://debuginfod.archlinux.org/


# Creating debug packages

Currently with pacman 6.0.1-3 debug package only works on C/C++ projects. This
is mostly because pacman utilizes a fairly ugly awk hack to extract sources and
if it encounters a binary from Go or Rust (as an example) it is simply unable to
deal with them and produces invalid packages.

This is fixed with a patch i wrote which replaces the AWK hack with debugedit.
https://gitlab.archlinux.org/pacman/pacman/-/commit/ae2f506ddfd11d9becda7216033fe1b159536982

Until this patch is backported, or a pacman release is done, I would advise us
to not build debug packages for anything that isn't using gcc/clangd.

Saying that, I'm unsure how we should be documenting debug packages across our
distro. They probably belong in package guidelines sections of each package, or
we make a common wiki page for this. Generally Rust needs a environment variable
and Golang needs a bit of work to disable decompressed DWARF headers.

We can probably work something out as we go along, currently I think we should
try enable debug packages on our [core] packages.

When we have pacman with the above patch I can try compile a list of available
methods to get debug packages from Rust, Go and other languages. Obviously I'd
need some help with that :)

Cheers!
-- 
Morten Linderud
PGP: 9C02FF419FECBE16

# infrastructure
https://gitlab.archlinux.org/archlinux/infrastructure/-/merge_requests/168

# dbscripts
https://gitlab.archlinux.org/archlinux/dbscripts/-/merge_requests/21
https://gitlab.archlinux.org/archlinux/dbscripts/-/merge_requests/33

# devtools
https://gitlab.archlinux.org/archlinux/devtools/-/merge_requests/78


signature.asc
Description: PGP signature

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

[Morten Linderud via arch-dev-public]

On Sun, Jan 30, 2022 at 12:02:46PM +0100, Andreas Radke via arch-dev-public 
wrote:
>
> [5) Why don't we care about ARM and OpenRISC at all? Aren't we riding
> pretty dead horses here just for very minor improvements?]

ALARM has refused to join the project because of our ancient tooling. RISC is
being worked on by Felix.

https://github.com/felixonmars/archriscv-packages

-- 
Morten Linderud
PGP: 9C02FF419FECBE16


signature.asc
Description: PGP signature

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

[Morten Linderud via arch-dev-public]

On Sun, Jan 30, 2022 at 02:00:51PM +0100, Maxime Gauduin via arch-dev-public 
wrote:
> On Sat, 2022-01-29 at 20:17 +0100, Sven-Hendrik Haase via arch-dev-
> >
> > 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
> 
> We already have 2 working automated build tools, that I know of,
> Evangelos' and mine [0]. I'm sure we can figure something out fairly
> quickly, unless we'd rather go with some Gitlab CI now that we have
> one. It would probably make more sense to go that route, but I've
> already fitted several Gitlab instances with a Buildbot CI, I find it
> more flexible and it also works wonders.

I think having buildbot would be more flexible for such an infrastructure then
piggy back on the pipeline system for gitlab. It sometimes feels too restrictive
being tied to git repositories and buildbot is a *lot* more flexible when it
comes to it.

It might also be worth a consideration that the build infrastructure would be
completely seperate from our git forge. This would make it easier if we want to
move VCS/forge in the future.

-- 
Morten Linderud
PGP: 9C02FF419FECBE16


signature.asc
Description: PGP signature

Re: [arch-dev-public] Debug packages for Arch Linux

[Morten Linderud via arch-dev-public]

On Sun, Jan 30, 2022 at 08:49:29PM +0100, sL1pKn07 SpinFlo wrote:
> hi
> 
> thanks for the work!

Thanks!

> one question. This thing works, for example, if I build one of the packages
> with debug package in the arch debuginfod site with my custom flag for
> disable an option/feature. the debug package stored in the debuginfod site
> still works? or i need to create a debug package locally?

The buildid would be different so our debuginfo won't work with your packages.

You can check with: readelf -n /bin/ls | grep -A4 build.id

> If I need to build a local debug package and I want to use it
> with debuginfod, is it possible add the link of the custom debuginfod site
> in the DEBUGINFOD_URLS variable? how? is , separate? or ;?

Yes, space is the seperator. See 
https://man.archlinux.org/man/debuginfod-find.1#ENVIRONMENT_VARIABLES

You can also add a file under /etc/debuginfod/*.urls like we did with our
`debuginfod` package.

-- 
Morten Linderud
PGP: 9C02FF419FECBE16


signature.asc
Description: PGP signature

Re: [arch-dev-public] Debug packages for Arch Linux

[Morten Linderud via arch-dev-public]

On Sun, Jan 30, 2022 at 08:59:34PM +0100, sL1pKn07 SpinFlo wrote:
> El dom, 30 ene 2022 a las 20:54, Morten Linderud ()
> escribió:
> 
> > On Sun, Jan 30, 2022 at 08:49:29PM +0100, sL1pKn07 SpinFlo wrote:
> > > hi
> > >
> > > thanks for the work!
> >
> > Thanks!
> >
> > > one question. This thing works, for example, if I build one of the
> > packages
> > > with debug package in the arch debuginfod site with my custom flag for
> > > disable an option/feature. the debug package stored in the debuginfod
> > site
> > > still works? or i need to create a debug package locally?
> >
> > The buildid would be different so our debuginfo won't work with your
> > packages.
> >
> > You can check with: readelf -n /bin/ls | grep -A4 build.id
> >
> > > If I need to build a local debug package and I want to use it
> > > with debuginfod, is it possible add the link of the custom debuginfod
> > site
> > > in the DEBUGINFOD_URLS variable? how? is , separate? or ;?
> >
> > Yes, space is the seperator. See
> > https://man.archlinux.org/man/debuginfod-find.1#ENVIRONMENT_VARIABLES
> >
> > You can also add a file under /etc/debuginfod/*.urls like we did with our
> > `debuginfod` package.
> >
> > --
> > Morten Linderud
> > PGP: 9C02FF419FECBE16
> >
> 
> Hi
> 
> thanks for the reply
> 
> is here documented the file/directory structure of debuginfod "repo"?
> 
> greetings

I recommend reading the documentation frankly. debuginfod just recursively scans
a set of directories which is polling our package repositories. The
implementation is linked in the email.

https://gitlab.archlinux.org/archlinux/infrastructure/-/merge_requests/168/diffs?commit_id=b7202bd6da295654171d890c4d139ddae96ace54

-- 
Morten Linderud
PGP: 9C02FF419FECBE16


signature.asc
Description: PGP signature

Re: [arch-dev-public] Debug packages for Arch Linux

[Morten Linderud via arch-dev-public]

(Sorry for the offlist spam. I'm too quick and forget to remove the CC :c)

-- 
Morten Linderud
PGP: 9C02FF419FECBE16

Re: [arch-dev-public] arch-repo-management walkthrough 2022-02-02 19:00 CET (UTC+01:00)

[Morten Linderud via arch-dev-public]

On Mon, Jan 31, 2022 at 11:55:07PM +1000, Allan McRae via arch-dev-public wrote:
> On 31/1/22 23:23, David Runge via arch-dev-public wrote:
> > Hi all,
> > 
> > given recent topics for build automation and work on internal projects I
> > would like to announce a code walkthrough for arch-repo-management [1].
> > 
> > I would like to give an overview of the scope of the project, its
> > current features and which features I would like to see implemented
> > (some of which are still in a discussion phase).
> > I will try to add a few more tickets beforehand to track open features
> > and to outline them better. This way I hope that it becomes easier for
> > interested people to follow up on them.
> > 
> > The meeting will take place on Jitsi
> > https://meet.jit.si/20220202-arch-repo-management
> > 
> > on 2022-02-02 starting around 19:00 CET (UTC+01:00).
> > 
> > Any changes to the date and/or location will be announced in this mail
> > thread.
> > 
> > Best,
> > David
> > 
> > [1] https://gitlab.archlinux.org/archlinux/arch-repo-management/
> > 
> 
> Any chance this can be recorded?  It will be at 4am in my timezone?
> 
> I am interested in mainly what problem this is solving.  From what I can
> tell, our current workflow is package->db, and this goes package->json->db.
> What is the advantage of the extra step?  Will this be covered by your talk?

It would be in python which is more maintainable then the juggle of bash we
curently have. JSON would also provide us with a machine readable format which
is usefull for us in extending tooling in the future.

The JSON document would also replace the repository state that is kept in our
svn mono-repository, so it solves a few more issues with the git migration.

https://wiki.archlinux.org/title/User:Foxboron/GitMigration

You can see a plaintext space seperated version of this in this mock up which we
decided on a couple of years ago when we discussed git.

-- 
Morten Linderud
PGP: 9C02FF419FECBE16


signature.asc
Description: PGP signature

Re: [arch-dev-public] Debug packages for Arch Linux

[Morten Linderud via arch-dev-public]

On Mon, Jan 31, 2022 at 10:20:35AM +0100, Jelle van der Waa via arch-dev-public 
wrote:
> On 30/01/2022 12:59, Kristian Klausen via arch-dev-public wrote:
> >
> > We have three sponsored machines, which are used as package mirrors and
> > archive mirrors[1].
> > At the time of writing they have 14TB available storage each, so we
> > could mirror the debug packages to them.
> 
> Thanks for deploying debuginfod Kristian/Morten! I think we should just
> mirror debug packages to our own controlled mirrors.

Should I mention in the news post that the debug repositories should be
available on our pkgbuild.com mirrors in a few days? Or should I wait with the
announcement until this has been deployed? Thoughts?

-- 
Morten Linderud
PGP: 9C02FF419FECBE16


signature.asc
Description: PGP signature

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

[Morten Linderud via arch-dev-public]

On Tue, Feb 01, 2022 at 03:55:44AM +, George Rawlinson via arch-dev-public 
wrote:
>
> I have no objections to this, and happily support this endeavour.
> 
> However, I currently track 8 packages via shell scripts (available via
> nvchecker's "cmd" source), all found here[0].
> 
> Some of them require specific dependencies to be installed, e.g.
> html-xml-utils for normalising/extracting HTML elements. Would we be
> able to list specific dependencies in the .nvchecker files?
> 
> [0]: 
> https://git.little.kiwi/grawlinson/arch-pkgs/src/branch/primary/.repo/pkgver

These require running arbitrary scripts on archweb so they should probably 
remain
unsupported. Is there no better options?

-- 
Morten Linderud
PGP: 9C02FF419FECBE16


signature.asc
Description: PGP signature

Re: [arch-dev-public] mkinitcpio some improvements and question on how kernel modules should be treated

[Morten Linderud via arch-dev-public]

On Tue, Feb 01, 2022 at 03:54:03PM +0100, Tobias Powalowski via arch-dev-public 
wrote:
> Hi guys,
> did some initcpio optimizing lately and implemented correct symlink
> handling. This saves already some space.
> https://bugs.archlinux.org/task/73439
> 
> Now one major problem left in recent initcpio, uncompressed modules:
> https://github.com/archlinux/mkinitcpio/pull/25
> https://bugs.archlinux.org/task/72882
> At the moment modules are uncompressed during initcpio creation. This leads
> to bigger RAM usage during boot, makes it a bit smaller on storage, due to
> not recompress compressed modules. On small initrds for normal boot this is
> not a big matter.
> 
> My measurement with all patches added:
> Ramdisk size uncompressed modules: 13261677
> Ramdisk size compressed modules: 13112083
> (Note the compressed one is smaller due to the symlink patches added)
> Unpacked initramfs uncompressed modules: 35 MB
> Unpacked initramfs compressed modules:  26 MB
> Using this on the biggest "initramfs testsuite" archboot shows the most
> advantages.
> 
> If you like to test it on your own initramfs setup you can use:
> https://gitlab.archlinux.org/tpowa/archboot/-/blob/master/usr/share/archboot/patches/31-initcpio.functions.fixed
> for /usr/lib/initcpio/functions and recreate your initramdisk.
> 
> Now my question to the list, what should be the default how arch handles
> modules in initramfs?
> - Shall we leave the modules at compression level used during kernel build?
>  --> This means the uncompression should be optional.
> - Shall we still uncompress the modules always? (Status now)
> --> Then using modules as is needs to be optional.

I think we should leave it as-is and much rather have a flag if someone want to
compress kernel modules or not.

The space increase vs RAM increase vs mkinitcpio build time is something that
it's generally a bit hard to make call on and I reckon there are arguments on
both of these sides.

I wouldn't mind rewriting the patch submitted to mkinitcpio and fix up the
issues it had.

-- 
Morten Linderud
PGP: 9C02FF419FECBE16


signature.asc
Description: PGP signature

Re: [arch-dev-public] Arch Linux Secure Boot support, get it done ; )

[Morten Linderud via arch-dev-public]

On Wed, Feb 02, 2022 at 12:20:19PM +0100, Tobias Powalowski via arch-dev-public 
wrote:
> Hi guys,
> next topic to step up: Secure Boot support
> I wanted to bring this up to the mailing list to collect all info about the
> status of SB support.
> There are different approaches on how to implement SB.
> My question first: Do we want a signed shim for Arch Linux?
> If yes, how to achieve this? We should make a process in our infrastructure
> and document what needs to be done and who does it.
> Morten would you please add your thoughts about this topic on the ML, i
> think you are most into SB on linux.

Quick notes from me!


# Signed SHIM

First of we need to have a signing solution for this. My idea has been to
piggy-back on the existing work on the signing-enclave. However it's current
focus is GnuPG and I need something which can support x509 certificates and
preferably PKCS11 for hardware tokens.

I think having a separate POC for this and later folding it into the
signing-enclave is a good options as well.

Once we have a key we can embed into the shim, we can build a shim package and
submit it for review to Microsoft.

https://github.com/rhboot/shim-review

Once this is signed and approved by Microsoft we can provide our own
"shim-signed" package.


# Packaging

Next up is how to solve the packaging? We need to sign the bootloader we want to
support with our MOK which is embedded into our signed shim. This implies
extracting recent packages, get the binaries and sign them.

The signed packages we would end up with would look something like:

* grub-signed
* systemd-boot-signed
* refind-signed
* fwupd-signed

But we need to figure out how this process should be done. I'm not super
interested this being dependant on a single Developer/Packager. And we would
preferably want all of these packages reproducible.

The idea could be to make detached signature's and fetch the package from the
archive with the signature and construct the signed binary in our package. This
would mostly solve that issue.

Here is a mock up of how Debian has intended to solve this:
https://wiki.debian.org/SecureBoot/Discussion#Earlier_proposed_signing_architectures

There is also an entire SBAT thing we need to document and properly administer
across our EFI binaries.
https://github.com/rhboot/shim/blob/main/SBAT.md


# Installation

Now, how do we actually work this into the installation process? With the above
we can have archiso boot on a Secure Boot enabled system. But we do not control
how users install their systems, and I think it would be overzealous to enforce
this on new installation?

So do we update the wiki for accounting for secure boot? How do we explain what
needs to be done so people are not installing a system that won't boot because
of Secure Boot?


# RFC

I think this entire process should be an RFC along with how we want to
accomplish each step.

https://gitlab.archlinux.org/archlinux/rfcs/

My main focus is mostly going to be around the Git package migration but I have
been tempted writing up a POC when I have a weekend. It would mostly be to make
an example signing solution and some package examples.

-- 
Morten Linderud
PGP: 9C02FF419FECBE16


signature.asc
Description: PGP signature

Re: [arch-dev-public] Debug packages for Arch Linux

[Morten Linderud via arch-dev-public]

Hi,

This is an updated news entry for the debug package announcement. We have been
working on the system and provided a few repositories for the debug repositories
as well.

I'll post this when we have an updated "Getting traces" article ready :)

# Debug packages and debuginfod
We are very happy to announce that debug packages are now available in Arch 
Linux.

Debug symbols and source listing are provided through our debuginfod instance 
which can be utilized by debuggers such as gdb and delve.

https://debuginfod.archlinux.org/

A couple of sponsored mirrors are providing the debug repositories while we 
figure out and communicate the new [mirror 
requirements](https://wiki.archlinux.org/title/DeveloperWiki:NewMirrors).

* https://america.mirror.pkgbuild.com
* https://asia.mirror.pkgbuild.com
* https://europe.mirror.pkgbuild.com

For more information on this, please visit the 
[Debuginfod](https://wiki.archlinux.org/title/Debuginfod) wiki article, and 
also our newly renovated [Debugging/Getting 
traces](https://wiki.archlinux.org/title/Debugging/Getting_traces) article.

-- 
Morten Linderud
PGP: 9C02FF419FECBE16


signature.asc
Description: PGP signature

Re: [arch-dev-public] Debug packages for Arch Linux

[Morten Linderud via arch-dev-public]

On Fri, Feb 04, 2022 at 11:07:29PM +1000, Allan McRae via arch-dev-public wrote:
> On 4/2/22 22:49, Jelle van der Waa via arch-dev-public wrote:
> > 
> > * How do I create a debug package?
> > 
> > Add 'debug' to the options array in your PKGBUILD, bump pkgrel and
> > rebuild. This should result into a debug package based on the 'pkgbase'
> > of the package/PKGBUILD so for linux it ends up creating
> > linux-debug-$pkgver-$pkgrel.tar.zst.
> 
> 
> Are we intending to make that the default in devtools?

Yes, but not with the current pacman release as it would produce more broken
debug packages then valid ones.

I also need to fix up a few debugedit issues which has been found the past week
in terms of non-unique source directory in the debug package.

-- 
Morten Linderud
PGP: 9C02FF419FECBE16


signature.asc
Description: PGP signature

Re: [arch-dev-public] build automation discussions

[Morten Linderud via arch-dev-public]

On Mon, Feb 07, 2022 at 11:28:02AM +0100, Xyne via arch-dev-public wrote:
> Hi,
> 
> In the recent discussions about possibly adding support for x86_64-v3 the
> general consensus seemed to be that we need to first work on our packaging
> infrastructure (build pipelines, reproducible builds, etc.).
> 
> Who's currently working on that and where I can get involved? Are there 
> already
> any tools in development? Aside from some helper tools such as
> arch-rebuild-order I didn't find anything in the list of official projects on
> our Gitlab.

I'm sorta working a bit on extending the devtools tooling in contrib. I don't
think it replaces a proper CI build system. But it might give some inspiration
for how we can resolve dependency chains and doing rebuilds.

https://github.com/archlinux/contrib/blob/morten/rebuild/package/rebuildctl
https://github.com/archlinux/contrib/blob/master/package/rebuild-todo

I'm working a bit on joining the above tools into buildctl which should be able
to resolve dependency chains, do rebuild and todo lists. Which I have some hopes
can be the frontend for some CI infrastructure. Also in Python so I don't have
to do more bash-golfing.

For creating a CI infra I'm wondering if buildbot would allow us the flexibility
we'd need to have something that works. I haven't made up my mind if using
Gitlab for this is a good idea?

https://buildbot.net/

Generally the people that actively work on this gather on IRC in the
#archlinux-projects and #archlinux-reproducible IRC channels. There are a lot of
experimentation so any contribution would be great.

-- 
Morten Linderud
PGP: 9C02FF419FECBE16


signature.asc
Description: PGP signature

Re: [arch-dev-public] Decisions on AUR management - Was: RFC: Forbid dummy packages from AUR

[Morten Linderud via arch-dev-public]

On Thu, Mar 24, 2022 at 09:24:03PM +1000, Allan McRae via arch-dev-public wrote:
> As I said, I'm happy the discussion around this RFC is public and open. But
> if this is a big enough change for an RFC, then it almost certainly needs to
> go through the TU voting procedure.

I'd be happy with having this proposal going through the RFC process and later
go through the TU voting if the RFC gets accepted. That seems like a fair
compromise to me?

-- 
Morten Linderud
PGP: 9C02FF419FECBE16


signature.asc
Description: PGP signature