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/46
Please visit the above link for discussion.
Summary:
Improve the security of Arch Linux d
On 2025-02-26 21:53:50 (+0100), Jelle van der Waa wrote:
> After all the recent RISC-V news I went ahead and checked out the existing
> effort to get Arch Linux supported on RISC-V. Felix maintains an overlay of
> PKGBUILDs which require customization to be be able to build on RISC-V. A
> lot of th
On 2025-02-18 19:29:41 (+0100), kpcyrd wrote:
> hello,
>
> following up on an irc discussion on the Rust packaging guideline, I'd like
> to propose changing the command in section 5 from:
>
> cargo build --frozen --release --all-features
>
> to
>
> cargo build --frozen --release
>
> En
Hi all,
back in October I have created channels for the buildbtw and signstar projects
[1] which are meant to be publicly accessible for development and general user
activities.
While these work fine on the Libera.Chat side, the bridging via our private
Matrix bridge causes friction:
It is not po
On 2024-12-15 22:34:55 (+0100), Torsten Keßler wrote:
> WARNING: This version of the TensorFlow package is not compatible with
> Python 3.13
>
> If you want to use TensorFlow, consider installing an older version of
> Python and use a virtual environment or use the official Docker image,
> https:/
ALPM project in a part time capacity over the course
of 15 months.
The developers are [Arne Christian Beer][2], [Heiko Schäfer][3], [Orhun
Parmaksız][4] and [David Runge (myself)][5].
Work on the project has started in October 2024 and the funding continues until
the end of 2025.
The ALPM
A new RFC (request for comment) has been opened here:
https://gitlab.archlinux.org/archlinux/rfcs/-/merge_requests/46
Please visit the above link for discussion.
Summary:
Improve the security of Arch Linux distribution packages by relying on
transparent and if possible also cryptographically ver
Hi all,
with python-pynitrokey dropping the dependency on python-spsdk and others, I am
able to drop a few packages.
If you are interested in any of them, please make sure to adopt them, else I
will drop the following packages to the AUR in a week from now (2024-10-16):
python-spsdk
python-binco
On 2024-09-03 13:42:46 (+0200), 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/ar
On 2024-08-24 12:03:18 (+0200), Morten Linderud wrote:
> The question is if people feel a strong desire to keep a locate implementation
> in `[core]` or if we are fine with this living inside `[extra]`. Adding
> `plocate` to `[core]` would mean we would need to move a `liburing` to
> `[core]`
> an
On 2024-09-01 11:56:30 (+0300), Orhun Parmaksiz wrote:
> The other day, I started wondering why Arch Linux shouldn't support a
> similar public service, like https://paste.ubuntu.com, but powered by
> rustypaste. I believe we could configure rustypaste to allow public
> uploads with a retention per
Hi all,
I'll be on holidays from tomorrow until 2024-08-12 and only sporadically read
mails etc.
Please feel free to bump/move packages I maintain.
Have a good summer! :)
Best,
David
--
https://sleepmap.de
signature.asc
Description: PGP signature
Hi all,
please note that I have just pulled libassuan 3.0.1-1 from core-testing.
In this patch-level release some major issues emerged, that break pacman:
```
pacman -Ss test
pacman: /usr/lib/libassuan.so.9: version `LIBASSUAN_1.0' not found (required by
/usr/lib/libgpgme.so.11)
```
Please not
On 2024-07-14 21:14:27 (+0200), Florian Pritz wrote:
> 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.
>
>
On 2024-07-01 17:31:58 (+0200), Robin Candau wrote:
>
> # The sshd service needs to be restarted after upgrading to openssh-9.8p1
>
> After upgrading to openssh-9.8p1, the existing SSH daemon will be unable to
> accept new connections. (See
> https://gitlab.archlinux.org/archlinux/packaging/pack
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/32
Please visit the above link for discussion.
Summary:
Introduce "Arch Linux Ports" as testb
On 2024-03-11 21:09:15 (+0100), gromit wrote:
> On 24/03/02 12:48PM, gromit wrote:
>
> > Please head to https://archlinux.org/devel/reports/unneeded-orphans/ and
> > adopt packages that you'd like to keep in the repos.
> >
> > I will start dropping packages on 2024-03-17, so please try to have a
>
On 2024-03-11 21:23:36 (+0100), Morten Linderud wrote:
> I've adopted the tpm2-* stuff and pesign.
Cool, thanks!
> Some quick observations is that there are several packages on the list we
> should probably not be dropping. The ones that come to mind is refind at the
> very least.
>
> Here is a
A new RFC (request for comment) has been opened here:
https://gitlab.archlinux.org/archlinux/rfcs/-/merge_requests/32
Please visit the above link for discussion.
Summary:
Introduce "Arch Linux Ports" as testbed for unofficial architectures until they
are integrated in the main Arch Linux reposit
Hi all!
With RFC0016 [1] we have worked out a way to reason about SPDX license
identifiers [2] in the context of PKGBUILDs and packages.
Over the past months I have worked on the licenses package [3], as well as
namcap [4] to create the integration for all packagers.
This mail serves as a refreshe
Hi all!
I just dropped freerdp from [extra-testing], as I moved it there erroneously.
Freerdp > 3 is currently *not* compatible with most dependents.
I will try to figure out whether a freerdp2 package is feasible in the coming
days.
Patching the dependents is of course also an option, however mo
Hi again,
as the changes are rather diverse and manual intervention should not be
needed, Leonidas and I have spent some time to restructure the text a bit for
readability (also altered title slightly):
```markdown
With shadow >= `4.14.0`, Arch Linux's default password hashing algorithm
changed
On 2023-09-19 09:43:17 (+0200), David Runge wrote:
I have been asked by Kristian Klausen (offlist) to add information on the
motivation for using yescrypt as new default.
I propose this update:
> ```markdown
> With shadow >= `4.14.0`, Arch Linux's default password hashing algori
Hi all,
with shadow 4.14.0 I introduced some changes to default password hashing
algorithms and would like to post the following on the website once the relevant
packages (filesystem, pambase, shadow) move to [core]:
```markdown
With shadow >= `4.14.0`, Arch Linux's default password hashing algor
On 2023-08-27 11:45:45 (+0200), Jelle van der Waa wrote:
> Reminder, this is next weekend!
>
> On 05/08/2023 17:53, Jelle van der Waa wrote:
> > I'd like to propose that we have a bug weekend on 1-3 September to clean
> > up our bug tracker before we fully migrate it to Gitlab.
Thanks for getting
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/20
Please visit the above link for discussion.
Summary:
Default to not using PyPI for Python
A new RFC (request for comment) has been opened here:
https://gitlab.archlinux.org/archlinux/rfcs/-/merge_requests/20
Please visit the above link for discussion.
Summary:
Default to not using https://pypi.org for Python package sources and only use
the platform if there is no other alternative.
Hi Jerome,
just a friendly reminder, that we would still need a message signed with your
packager key, so that we can take further action. :)
On 2023-06-07 17:19:37 (+0200), David Runge wrote:
> If you indeed want to stop packaging, please make sure to reply
> with a signed email (using yo
On 2023-06-06 20:40:36 (+0200), Jerome Leclanche wrote:
> I've not been able to update any of my packages in a couple of months and
> unfortunately I don't see the situation resolving itself any time soon with
> my life being busier than ever.
>
> I'd rather officially step down and re-apply in th
On 2023-05-28 12:26:59 (+0200), Jelle van der Waa wrote:
> Let's just give everyone access by default.
Yes please!
Best,
David
--
https://sleepmap.de
signature.asc
Description: PGP signature
On 2023-04-06 14:30:25 (+0200), Jelle van der Waa wrote:
> Early Easter suprise,
>
> After some delay Python 3.11 rebuilds are happening in [staging], so please
> don't start any rebuild.
>
> Thanks to felixonmars for starting and rebuilding!
>
> Thanks,
>
> Jelle van der Waa
Just a short head
On 2023-04-25 16:31:29 (+0200), Morten Linderud wrote:
> Initially I really want to move the hooks from `cryptsetup` and `systemd`:
>
> * encrypt and sd-encrypt from core/cryptsetup
> * systemd and udev from core/systemd
>
> We could maybe consider a few other hooks from [core] depending on peopl
On 2023-04-24 08:26:54 (+0200), Laurent Carlier wrote:
> Last week I fell from my bike and was diagnosed with a broken pelvis/ankle.
> So for weeks I must stay on a bed for some weeks - and away from my main
> computer.
>
> I was not able to build amdvlk with last releases, so if some can fix it,
Hi all,
squashfs-tools 4.6 has been dropped from testing due to a regression [1].
Please make sure to downgrade.
Best,
David
[1] https://bugs.archlinux.org/task/77914
--
https://sleepmap.de
signature.asc
Description: PGP signature
On 2023-01-15 12:25:36 (+0100), David Runge wrote:
> There has been a problem [1] introduced by not renaming the soname of
> libphp-legacy.so. The soname was still libphp.so, so linking against
> libphp-legacy.so led to dependents requiring libphp.so instead (this was
> also the
On 2022-12-20 11:49:28 (+0100), Pierre Schmitz wrote:
> On Tue, Dec 20, 2022 at 11:25 AM David Runge wrote:
> > Hm, I'm not so happy about this removing the checks and hardcoding
> > php-legacy though.
>
> The check is done by calling versioncheck.php directly
On 2023-01-08 12:13:36 (+0100), Jelle van der Waa wrote:
> On 05/01/2023 23:15, Levente Polyak wrote:
> > # Introduction
> >
> > Behold, ~~winter~~ Git is coming. We've been working on and off to get
> > Git packaging sources ready for a while now. Today I'd like to outline
> > the final proposal
On 2022-12-16 22:46:12 (+0100), Andreas Radke wrote:
> Nowadays systemd has become much more than a plain init system
> and plans to grow further. This may leadd to problems from a user and
> system administrator perspective once you are hit by some bug. Systemd
> as a whole thing doesn't care abou
On 2022-12-20 11:09:15 (+0100), Pierre Schmitz wrote:
> On Tue, Dec 20, 2022 at 10:44 AM Pierre Schmitz wrote:
> >(I can do the required changes if you like)
>
> As some code is probably easier to talk about here is my idea in patch
> from: https://gist.github.com/pierres/227602544b54a1b027471b6c
On 2022-12-20 10:00:09 (+0100), Pierre Schmitz wrote:
> The rebuild for modules and anything that links against PHP went quite
> well and I have moved the packages into [testing]. Even uwsgi did
> build with a simple patch. I did notice that this project is in
> maintenance mode according to upstre
On 2022-11-28 23:19:09 (+0100), Jan Alexander Steffens (heftig) wrote:
> Hello list,
>
> We're planning to make PipeWire the default PulseAudio sound server, and
> for that we need to change some dependencies around. Notably, we want a
> virtual "pulseaudio server" package that is fulfilled by bot
On 2022-11-13 21:17:29 (+0100), Jelle van der Waa wrote:
> https://sources.archlinux.org/sources/$pkgbase/whatever.tar.gz
>
> They are versioned, example:
>
> -rw-r--r-- 1 sourceballs sourceballs 49M May 22 13:42
> zynaddsubfx-3.0.6-3.src.tar.gz
> So I never said I wanted the archive in a Git
On 2022-11-13 17:42:27 (+0100), Jelle van der Waa wrote:
> For packaging we now rely on external parties to keep the source code
> hosted which can be a problem and some packagers want to search
> through all our packages code. [1]
>
> Currently we already archive sources using `sourceballs` on
>
On 2022-11-06 13:53:51 (+0100), Andreas 'Segaja' Schleifer wrote:
> Recently Felix found a way to only build the gem and possible extensions
> once and use them for both testing and packaging.
>
> To reflect these changes I would propose that we update our ruby package
> guidelines with the new wa
Hi all,
today I have moved the realtime kernels to [extra]:
https://archlinux.org/packages/extra/x86_64/linux-rt/
https://archlinux.org/packages/extra/x86_64/linux-rt-lts/
I have been maintaining these kernels in the AUR via a custom repository
[1] for a couple of years now and believe that quit
On 2022-11-01 18:27:23 (+0100), Pierre Schmitz wrote:
> I updated to 3.0.7 in staging. I had libprovides in my branch. Do you
> guys think this might be handy to define versioned dependencies when
> we have potentially three different openssl verions to maintain?
>
> provides=('libcrypto.so' 'libs
Hi all,
we have recently cleaned up parts of the developer wiki a bit and moved
the list of internal projects to a more prominent location:
https://wiki.archlinux.org/title/Getting_involved#Software_projects
As you can see, we have quite a few projects and some of them would be
happy about more
On 2022-10-12 11:29:52 (+1000), Allan McRae wrote:
> On 11/10/22 21:00, Levente Polyak wrote:
> > On 10/11/22 12:05, David Runge wrote:
> > > - preserve base-devel as a group there
> >
> > makedepends doesn't actually matter, similar how checkdepends doesn
On 2022-10-11 16:30:42 (+0200), Andreas Radke wrote:
> How comes? Nano is actually pretty well maintained and has seen lots
> of updates over the past years. See
Yep, that's why I wrote, that it is at least still somewhat maintained
(vi does not seem like it). :)
My rationale would be, that text e
Hey Tobias,
On 2022-10-11 12:53:25 (+0200), Tobias Powalowski wrote:
> here my short additions:
> - syslinux:
> is dead and not used in our projects anymore
I added it to the list. Syslinux itself is still somewhat useful if one
doesn't want to deal with grub on legacy boot systems.
> - nano vs.
On 2022-10-11 13:00:57 (+0200), Levente Polyak wrote:
> I'm actually currently working on moving it to a meta-package as well.
> We didn't do it when introducing `base` as we never really changed it.
> Now we did with debugedit and face small inconveniences and we are
> better of to have it as meta
Hi all,
we need to do a bit of [core] repository cleanup.
In this MD [1] (publicly visible readonly link [2]) we have a list of
packages that should leave [core], some maybes that need discussion
before moving them and some that should be moved to [core] from the
other repositories.
If you have
Hi all,
I've started a discussion [1] around a potential improvement for dealing
with archlinux-keyring and pacman-key.
Lately we have been facing quite a few issues (e.g. initialization and
ordering issues in archiso and arch-boxes) again, that emerge from how
gnupg is used in the context of pac
Hi all,
On 2022-09-06 22:06:12 (+0200), Levente Polyak wrote:
> Therefore I'm proposing we replace Giancarlo's key and pass on the
> duties to Johannes.
I'd be happy for us to gain another functional main signing key, which
is much needed to arrive at a setup in which we are resilient towards
pro
Hi all,
I've just released repod 0.2.0 [1] (it is available as "repod" in our
repositories).
There are some significant changes in this release which allow for
rudimentary handling of binary package repositories in configurable
directory structures.
For further information please refer to the docu
On 2022-08-09 12:16:26 (+0900), Nicola Squartini wrote:
> Dear all,
>
> Due to my involvement in other projects I'm unable to dedicate the time it
> deserves to Arch Linux, therefore I decided to resign from my role of
> Trusted User.
>
> I thank György Balló for sponsoring me 6 years ago, and ev
On 2022-08-09 09:43:49 (+0200), Morten Linderud wrote:
> I have one exception I'd like us to make regarding auto rejection.
>
> Historically the aur-requests list has not required subscription to
> reply. At some point this was removed and I think it's unreasonable
> for AUR maintainers to subscri
Hi all,
On 2022-07-21 10:15:12 (+0200), David Runge wrote:
> I'm currently partly moderating mailing lists for Arch Linux.
> Since we've switched to mailman3 I receive *a lot* of info from the
> system, that mails are being held in the moderation queue due to being
> sent
On 2022-07-24 12:23:29 (+1000), Allan McRae wrote:
> Not shipping keys that are marginally trusted is ideal in principle...
> However we have seen it many times recently as main/master keys were
> cycled. Hopefully this is less of an issue moving forward. This is
> why the keyring was set up to ha
On 2022-07-25 09:23:53 (+0100), Leonidas Spyropoulos wrote:
> I'm aligning probably against such systemd unit. Mainly because or
> privacy issues and given the options users will probably set something
> like refresh every 1 hour and then we need to go into rate-limiting
> just to keep our gitlab u
On 2022-07-24 21:56:28 (+0200), Johannes Löthberg wrote:
> I'm fine with it existing, and I would be fine with it being enabled
> in a vendor preset, but I'm against it being statically enabled in
> /usr. This is not something that's critical for the regular
> functioning of the system, and so is
On 2022-07-24 10:53:24 (-0700), Brett Cornwall wrote:
> Just wanna point out that just because we already do something it
> doesn't validate doing a similar thing. :)
No. That was not the point I was trying to make. :)
It serves as a good example as to why such a thing does not have to be a
privac
On 2022-07-23 23:49:09 (+0300), Evangelos Foutras wrote:
> This is solvable by not cutting a release with marginally trusted
> keys. Having all Arch Linux installations make 100-ish requests daily
> to cover such an edge case is a misutilization of resources (on both
> sides).
Refreshing existing
On 2022-07-23 21:24:38 (+0200), Kristian Klausen wrote:
> The load aspect should be solvable, worst-case DevOps gets annoyed ;)
>
> My main concern is putting ourselves in a position, where we know
> every arch installation, yes it is just the IP addresses, but still.
> At the same time it becomes
Hi all,
I currently have a MR open against archlinux-keyring [1], that adds a
systemd service and timer, which would automatically refresh valid and
existing keys on user systems. For people without access to the
repository's ticket and merge request features, it is possible to browse
the commits
Hi all,
I'm currently partly moderating mailing lists for Arch Linux.
Since we've switched to mailman3 I receive *a lot* of info from the
system, that mails are being held in the moderation queue due to being
sent by non-members of the respective lists.
IMHO, we should configure all of our mailin
Hi all,
if you are a main signing key holder or a packager for Arch Linux,
please read this mail very carefully!
We are currently blocked from releasing a new version of
archlinux-keyring, as a release would imply demoting a few packager keys
to marginal trust (aka. not enough signatures from our
On 2022-07-02 13:07:38 (+0200), David Runge wrote:
> As there has been no negative feedback to this suggestion, I'd move
> ruby and rubygems to [community] tomorrow, so that work on the topic
> can commence.
The packages are now moved and the updated package guidelines are i
On 2022-06-24 22:47:04 (+0200), David Runge wrote:
> Ruby does not seem to be directly required by anything in extra. E.g.
> apparmor only carries it as an optional dependency.
> So moving should not be an issue. @anatol what do you think?
As there has been no negative feedback to this s
On 2022-06-26 19:36:47 (+0200), Morten Linderud wrote:
> I'll be gone from the start of July until the start of August! Vacation time
> along with starting a new job over the summer. I also need to recharge some
> batteries.
Enjoy your time off and have a great summer!
> I've included a list of p
Hi all,
sorry for the late reply.
On 2022-06-14 21:18:18 (+0200), Andreas 'Segaja' Schleifer wrote:
> As to the state of things and a patch for the PKGBUILD:
>
> I have a diff of the ruby PKGBUILD ready [0]. I’m adding another split
> package to the mix called ruby-stdlib which is defining the d
Hi Andreas,
first off: Thanks for looking into this! I guess not all of the
packagers knows how complicated and time-consuming packaging ruby can
be.
On 2022-06-01 23:05:45 (+0200), Andreas 'Segaja' Schleifer wrote:
> The problem is that in order to get this fully working we need to package
> all
On 2022-05-29 12:40:22 (+0200), kpcyrd wrote:
> I blogged about a new tool that can be used to verify a tarball from a
> signed git tag, while still pinning the sourcecode with >= sha256sum:
>
> https://vulns.xyz/2022/05/auth-tarball-from-git/
>
> Let me know what you think - that's all,
Hi,
in
On 2022-04-25 17:25:47 (+0200), David Runge via arch-dev-public wrote:
> And a note on the versioned provides (e.g. `php-apcu=7.4` for the
> current php7-apcu). I believe this should be done, but it would only
> prove useful if packagers then relied on two dependency contraints (I'
On 2022-04-24 21:13:43 (+0200), David Runge via arch-dev-public wrote:
> On 2022-04-24 19:08:37 (+0200), Pierre Schmitz via arch-dev-public wrote:
> > I'd still suggest to provide two different php versions as mentioned
> > some time ago: the current "php" and &qu
On 2022-04-24 19:08:37 (+0200), Pierre Schmitz via arch-dev-public wrote:
> I'd still suggest to provide two different php versions as mentioned
> some time ago: the current "php" and "php-legacy" which will always be
> the oldest supported version. These may provide the versions as you
> suggested
On 2022-03-08 13:56:04 (+0100), David Runge via arch-dev-public wrote:
> after waiting another couple of weeks, the situation with nextcloud
> unfortunately has still not improved.
> We see issues with utf-8 compatibility [1] and meanwhile the version
> 24.0.0 which is supposed to pr
On 2022-04-22 11:07:26 (+0200), David Runge via arch-dev-public wrote:
> On 2022-04-22 10:52:06 (+0200), Jan Alexander Steffens (heftig) wrote:
> > I'm still unhappy with `pacman -S qemu` not doing anything useful. Maybe we
> > could name that `qemu-misc` or `qemu-common` inst
On 2022-04-22 10:52:06 (+0200), Jan Alexander Steffens (heftig) wrote:
> On Fri, Apr 22, 2022 at 10:38 AM David Runge via arch-dev-public <
> arch-dev-public@lists.archlinux.org> wrote:
>
> > The `qemu` package now only carries a few common files and tracks all of
>
On 2022-04-21 23:20:32 (+0200), David Runge via arch-dev-public wrote:
> with qemu 7.0.0 now in [staging] we have a more extensive split package
> setup (see accompanying TODO [1]). Under certain circumstances this will
> require manual intervention (or rather a specific upgrade) to r
Hi all,
with qemu 7.0.0 now in [staging] we have a more extensive split package
setup (see accompanying TODO [1]). Under certain circumstances this will
require manual intervention (or rather a specific upgrade) to regain the
previous functionality:
```
With the update to qemu 7.0.0 the package h
On 2022-04-06 15:49:54 (+0200), Luna Jernberg wrote:
> Hey!
> Will miss the meeting today, and missed the one 2 weeks ago (if there was
> one?)
> But would gladly read the writeup or see a recording when i have time
Hi!
Yes, see the mail on archlinux-projects [1]. However, I might be a few
minute
On 2022-03-16 17:09:59 (+0200), Felix Yan via arch-dev-public wrote:
> certbot
> certbot-apache
> certbot-dns-cloudflare
> certbot-dns-cloudxns
> certbot-dns-digitalocean
> certbot-dns-dnsimple
> certbot-dns-dnsmadeeasy
> certbot-dns-gehirn
> certbot-dns-google
> certbot-dns-linode
> certbot-dns-lu
Hi again,
after waiting another couple of weeks, the situation with nextcloud
unfortunately has still not improved.
We see issues with utf-8 compatibility [1] and meanwhile the version
24.0.0 which is supposed to provide native support for php 8.1 is being
delayed until end of April [2].
This all
Hi all,
I'll be away for most of March and beginning of April.
I still have time sporadically over the next week but will likely not be
available for packaging or other things afterwards until the beginning
of April.
Feel free to upgrade packages that are out-of-date while I'm away.
Best,
David
Hi all,
as mentioned mid January [1] we are currently en-route to deprecating
Allan's main signing key [2].
For this purpose I have added 11 rebuild TODOs for packages signed by
packager keys that have been superseded by newer ones (and should then
also be removed). These packages need to be rebu
On 2022-01-31 21:25:41 (+0100), Jelle van der Waa via arch-dev-public wrote:
> We’ve wanted automatic flagging packages out of date for a while and
> currently every packager has to come up with it’s own solution. Let’s
> solve this centralized by integrating nvchecker into archweb.
One thing that
On 2022-02-03 22:07:09 (+1000), Allan McRae via arch-dev-public wrote:
> On 3/2/22 21:53, David Runge via arch-dev-public wrote:
> > Unless there are any objections, I propose to
> >
> > * add arch-repo-management and arch-release-promotion to it
> > * change arch-
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, ne
Hi all,
as announced on arch-dev-public, we would like to do bi-weekly meetings
for arch-repo-management [1].
I misjudged the (current) use-case for the arch-projects mailing list
though and therefore am doing the meeting announcement here.
I will send another mail to discuss the current/future s
On 2022-01-31 14:23:10 (+0100), David Runge via arch-dev-public wrote:
> 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
On 2022-02-02 12:40:56 (+0100), Morten Linderud via arch-dev-public wrote:
> # 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 su
On 2022-01-31 23:55:07 (+1000), Allan McRae via arch-dev-public wrote:
> Any chance this can be recorded? It will be at 4am in my timezone?
I think that can certainly be arranged!
> I am interested in mainly what problem this is solving. From what I
> can tell, our current workflow is package->
On 2022-01-31 14:23:10 (+0100), David Runge via arch-dev-public wrote:
> 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 anno
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 w
On 2022-01-30 12:13:45 (+0100), Morten Linderud via arch-dev-public wrote:
> ALARM has refused to join the project because of our ancient tooling.
Case in point. :)
--
https://sleepmap.de
signature.asc
Description: PGP signature
On 2022-01-29 13:11:05 (+0100), Morten Linderud via arch-dev-public wrote:
> * 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
y TU role!
>
> This notice is due to revocation of Bartłomiej Piotrowski's main key.
> Together with David Runge we decided, that best approach would be to
> remove my current key, and add a new one when I have access to my Arch
> machine. We will transfer the trust to a new key t
Hi Pierre,
On 2022-01-22 20:45:45 (+0100), Pierre Schmitz via arch-dev-public wrote:
> sorry about the hassle. I did not expect much issues here. I would
> consider this one of the smoother PHP updates. Unless people ignored
> warnings by previous PHP versions. I guess that is what mostly happend
On 2022-01-21 17:51:17 (+0100), Pierre Schmitz via arch-dev-public wrote:
> I just released PHP 8.1 into [extra].
>
> Please also check https://archlinux.org/todo/php-7-retiredment/ so PHP
> 7 can be dropped soon.
>
> have a nice weekend,
Unfortunately, it likely won't be ;_;
https://bugs.archl
1 - 100 of 128 matches
Mail list logo
