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
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
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
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
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-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
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
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,
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
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
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-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-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-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 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
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-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
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
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
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 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,
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
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
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 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
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
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-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,
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-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
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-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-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-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-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-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 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-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-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
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-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,
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-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-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-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
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
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.
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
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
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-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 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
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 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
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
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
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
>
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-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
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.
>
>
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
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
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
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-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
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
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
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
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:/
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 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
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
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 2021-01-21 14:08:11 (+0100), Bartłomiej Piotrowski via arch-dev-public wrote:
> Hi everyone,
>
> I'm stepping down as a developer. It's been mostly fantastic ride for
> the last 10 years but it's clear to me now that for better or worse it's
> far from the project I initially joined.
>
> Thank
Hi!
I have just upgraded postfix to 3.5.9.
The package has been split to allow specific installations based on
requirements while not pulling in all of the backends at once:
postfix
postfix-cdb
postfix-ldap
postfix-lmdb
postfix-mysql
postfix-pcre
postfix-pgsql
postfix-sqlite
Please do test the i
On 2021-01-26 22:18:21 (+0100), Levente Polyak via arch-dev-public wrote:
> On 1/26/21 9:53 PM, Morten Linderud via arch-dev-public wrote:
> >
> > It's dissapointing frankly.
> >
>
> Disappointing doesn't really catch it tho. If it would be just about the
> sync functionality: so be it. But crip
On 2021-01-27 08:45:53 (-0300), Giancarlo Razzolini wrote:
> If google drops the api key, yes. They said we can continue using
> them, but we don't know for how long, and they also mentioned
> reviewing quotas, which would render them unusable.
We don't have any specifics, so we will have to wait
Dear staff,
I have begun work on a Request for Comment (RFC) process for Arch Linux
and I am excited to now be able to open the first RFC... to introduce
"Using RFCs" :)
A new RFC (request for comment) has been opened here:
https://gitlab.archlinux.org/archlinux/rfcs/-/merge_requests/1
Please v
Hey all,
it has been roughly two weeks since my first mail and the discussions we
have had via comments on the RFC merge request have concluded. Thank you
all for your improvement suggestions and feedback!
This first RFC is rather special, as it is meant to bootstrap the
process and introduce it
On 2021-02-16 13:38:06 (-0300), Giancarlo Razzolini via arch-dev-public wrote:
> > Gitlab is going to be opened within the next months and we have
> > users on Gitlab today. It's not limited to staff.
True, but as we enforce the access rights to all of our repositories,
we can change that if the n
Hey all,
I'll be away for about a week for holidays.
If anything urgent comes up, feel free to bump or fix my packages.
Best,
David
--
https://sleepmap.de
signature.asc
Description: PGP signature
Dear all,
Jonas and I have been working on changes to our Code of Conduct, which
are represented in the following merge request:
https://gitlab.archlinux.org/archlinux/service-agreements/-/merge_requests/11
While most changes are based on e.g. merging sections or moving topics
to separate docum
On 2021-07-14 13:58:07 (+1000), Allan McRae via arch-dev-public wrote:
> I just read the document as it stands after your proposed changes. My
> conclusion was it is too long, often explained points in too much
> detail, and was too long!
I agree. The current work focusses mainly on splitting out
Hey all,
I made a dodo this morning by accidentally adding a TODO for a
fluidsynth rebuild [1].
The rebuild can only be done after the hdf5 rebuild [2] is done, due to
overlap. I will re-open it once we can proceed.
Sorry for the noise.
Best,
David
[1] https://archlinux.org/todo/fluidsynth-220-
On 2021-07-23 10:48:19 (+0200), Antonio Rojas via arch-dev-public wrote:
> El viernes, 23 de julio de 2021 10:28:42 (CEST), Archange via
> arch-dev-public escribió:
> > Please mind that here is already an (intel-)tbb rebuild waiting for the
> > hdf5 one to finish. As well as a VTK one, but since I
Hi all,
I'll be away for about two weeks and likely not be super active
packaging.
There are a few TODOs for rebuilds [1][2][3] that I have started, which
I may be able to move, but probably not be able to further help rebuild
at the moment.
Feel free to rebuild out-of-date packages. Note, that
On August 21, 2021 9:24:20 PM GMT+02:00, Jelle van der Waa via arch-dev-public
wrote:
>I would love to see someone from our team pick up namcap maintainership,
>take a look at all the pending patches, bugs on the tracker and keep it
>in shape. Is anyone interested in potentially picking up thi
On 2021-08-30 22:35:39 (+0200), Pierre Schmitz via arch-dev-public wrote:
> Thanks for looking into this. It's still weird but let's see if it
> will happen again. I hope it wasn't a memory issue and we can just
> blame Allan. ;-)
Unfortunately this has happened before.
On 2021-04-06 I noticed th
A new RFC (request for comment) has been opened here:
https://gitlab.archlinux.org/archlinux/rfcs/-/merge_requests/6
Please visit the above link for discussion.
Summary:
The adoption of a distribution-wide Code of Conduct (CoC) helps to
describe the social contract by which communication takes p
An RFC has now entered Final Comment Period. In 14 days, discussion will
end and the proposal will either be accepted, rejected or withdrawn:
https://gitlab.archlinux.org/archlinux/rfcs/-/merge_requests/6
Please visit the above link for discussion.
Summary:
The adoption of a distribution-wide Co
On 2021-10-08 09:44:56 (+1000), Allan McRae via arch-dev-public wrote:
> On 7/10/21 1:41 am, Sven-Hendrik Haase via arch-dev-public wrote:
> > On 06.10.21 12:47, Allan McRae via arch-dev-public wrote:
> >> On 27/9/21 4:33 am, David Runge via arch-dev-public wrote:
> >&
Hi Pierre,
On 2021-11-01 15:32:51 (+0100), Pierre Schmitz via arch-dev-public wrote:
> I did have some trouble build the current ISO image. As archiso
> requires to be run as root I had to work around some issues with GPG.
> As those did no longer work I thought I manually sign the artifacts.
> Th
On 2021-11-01 18:49:48 (+0100), Pierre Schmitz via arch-dev-public wrote:
> On Mon, Nov 1, 2021 at 5:10 PM David Runge wrote:
> > ... use an ephemeral PGP key (which is fine, as
> > it is not relevant whether it is a specific PGP key, only that the
> > *correct* PGP key is
On 2021-12-06 16:11:45 (+0100), Pierre Schmitz via arch-dev-public wrote:
> Hi all,
>
> a little heads up as it takes longer than expected. I'll start the PHP
> 8.1 update and the required rebuilds soon. I noticed some unexpected
> incompatibilities and I'd like to look into these first. I'll also
On 2021-12-06 17:58:57 (+0100), Levente Polyak via arch-dev-public wrote:
> On 12/6/21 17:48, David Runge via arch-dev-public wrote:
> > On 2021-12-06 16:11:45 (+0100), Pierre Schmitz via arch-dev-public wrote:
> > > Hi all,
> > >
> > > a little heads up as
On 2021-12-06 18:32:49 (+0100), Pierre Schmitz via arch-dev-public wrote:
> In general we could provide PHP 7 till its end of life in about eleven
> months. But I don't think its worth providing several different minor
> versions at the same time.
I agree.
> This is not how semver is supposed to
Thanks for taking care of this!
It generally looks good, but I would replace
> If you get errors like these
with
"If you get errors such as the following"
Best,
David
--
https://sleepmap.de
signature.asc
Description: PGP signature
Hi all,
in the past days there have been a few releases of our archlinux-keyring
package, which contains the root trust of our distribution.
We have successfully switched to using keyringctl [1] to manage the
keyring. From now on all changes to the keyring are done via merge
requests towards the
On 2022-01-14 16:57:00 (-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 m
On 2022-01-16 16:40:00 (+0100), Pierre Schmitz via arch-dev-public wrote:
> So far everything looks fine. I am even using PHP 8.1 in production
> for a week now, without any issues. So I'd like to move the packages
> to [extra].
>
> The remaining blocker is nextcloud though. What is the best opti
1 - 100 of 128 matches
Mail list logo
