On 11/3/22 09:12, Allan McRae via arch-dev-public wrote:
An RFC has now entered Final Comment Period. In 14 days, discussion will
end and the proposal will either be accepted, rejected or withdrawn:
https://gitlab.archlinux.org/archlinux/rfcs/-/merge_requests/11
Please visit the above link
On 24/3/22 18:42, Brett Cornwall via arch-dev-public wrote:
On 2022-03-24 13:23, Allan McRae via arch-dev-public wrote:
On 24/3/22 11:07, Brett Cornwall via arch-dev-public wrote:
A new RFC (request for comment) has been opened here:
https://gitlab.archlinux.org/archlinux/rfcs
On 24/3/22 11:07, Brett Cornwall via arch-dev-public wrote:
A new RFC (request for comment) has been opened here:
https://gitlab.archlinux.org/archlinux/rfcs/-/merge_requests/12
Please visit the above link for discussion.
Summary: Reject AUR packages that fulfill package dependencies without
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/11
Please visit the above link for discussion.
Summary:
Store the PGP signing keys listed i
On 24/2/22 00:03, Allan McRae via arch-dev-public wrote:
On 23/2/22 22:24, Allan McRae via arch-dev-public wrote:
Hi all,
I notice when using devtools, the following packages from [extra] get
pulled into our clean build root:
extra/gc
extra/guile
extra/libsysprof-capture
extra/libxml2
The
A new RFC (request for comment) has been opened here:
https://gitlab.archlinux.org/archlinux/rfcs/-/merge_requests/11
Please visit the above link for discussion.
Summary:
Store the PGP signing keys listed in a PKGBUILDs `validpgpkeys` array in
the trunk directory of SVN.
Motivation:
The PGP
On 23/2/22 22:24, Allan McRae via arch-dev-public wrote:
Hi all,
I notice when using devtools, the following packages from [extra] get
pulled into our clean build root:
extra/gc
extra/guile
extra/libcroco
libcroco is dead and gettext should no longer depend on it. So we can
remove that
Hi all,
I notice when using devtools, the following packages from [extra] get
pulled into our clean build root:
extra/gc
extra/guile
extra/libcroco
extra/libsysprof-capture
extra/libxml2
These are all dependencies of base-devel packages. I'd like to move
them to [core] so they are captured
On 20/2/22 08:27, Filipe Laíns via arch-dev-public wrote:
I have filled RFC 10 [12] with a formal proposal for this, as it is a fairly big
change. Feel free to give feedback there.
Can you announce the RFC using the template provided in the RFC process.
This will ensure wider viability of the
Hi all,
Just a reminder with the toolchain in [testing] that you need to be
careful when building packages for the stable repos. If you build the
package using the [testing] toolchain and release it to [extra] or
[community] it will fail to run with errors like:
/usr/lib/libc.so.6: version
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
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-projects to*also* become a general discussion list around
the above mentioned Arch Linux projects
What do you mean
On 3/2/22 03:42, Leonidas Spyropoulos via arch-dev-public wrote:
On 02/02/2022 17:32, Evangelos Foutras via arch-dev-public wrote:
I'm not fond of the hidden all-caps filename for editable sources
(whereas it's fine for .BUILDINFO and friends). More importantly
though, has integration with [1] b
On 1/2/22 00:36, David Runge wrote:
When looking at svn vs. git approaches the fundamental difference is,
that with svn we track both the package sources *and* their "location"
state in the repositories while repo-add/repo-remove is used to
add/remove things on the fly to the package repository
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 an
On 30/1/22 21:13, Morten Linderud via arch-dev-public wrote:
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 t
On 30/1/22 03:22, Kristian Klausen via arch-dev-public wrote:
Hi all
The lack of package database signing was mentioned yet again and I think
it is time to get the "Signing enclave" project rolling.
A design was sketched two years ago[1], and based on that design I'm
proposing a new design,
On 29/1/22 23:02, Morten Linderud wrote:
On Sat, Jan 29, 2022 at 10:53:41PM +1000, Allan McRae via arch-dev-public wrote:
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
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
On 29/1/22 13:12, Felix Yan via arch-dev-public wrote:
On 1/29/22 02:12, Allan McRae via arch-dev-public wrote:
The decision to be made is who will package for this repo? I think
these are the options:
A) packagers upload both x86_64 and x86_64_v3 to the repos. Our build
server will help
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
On 29/1/22 10:12, Allan McRae via arch-dev-public wrote:
Apart from tooling (devtools/dbscripts), we need to make some decisions.
FYI - I just submitted merge requests for both devtools and dbscripts.
These should be committed in tandem with work at devops end preparing
the initial state of
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 build
Hi all,
You may remember long in the past we discussed adding an x86_64_v3 port.
From memory, pkgstats shows this will benefit ~2/3 (or 3/4?) of our
users! So lets get this underway!
Apart from tooling (devtools/dbscripts), we need to make some decisions.
My plan is to seed the x86_64_v3 r
On 24/12/21 00:03, Allan McRae via arch-dev-public wrote:
With the latest devtools, LTO is enabled by default. This causes an
issue with .a and .o archived when stripping. Look out for output like:
strip:
./usr/lib/st4RPjCb/libsyslog_ng_native_connector_a-native-grammar.o:
plugin needed to
With the latest devtools, LTO is enabled by default. This causes an
issue with .a and .o archived when stripping. Look out for output like:
strip:
./usr/lib/st4RPjCb/libsyslog_ng_native_connector_a-native-grammar.o:
plugin needed to handle lto object
That file is now nicely mangled!
Turns
On 7/12/21 04:32, Levente Polyak via arch-dev-public wrote:
## Devtools
A new devtools version 20211129 has been released [7]. The new devtools
package is waiting in [staging] for the python 3.10 rebuild to finish in
order to avoid additional hassle with an already cumbersome rebuild.
LTO ha
On 16/12/21 13:24, Xyne via arch-dev-public wrote:
On 2021-12-15 16:40 +1000
Allan McRae via arch-dev-public wrote:
The dependencies added are purely sonames that the binary are explicitly
linked to. So the binary will be non-function without libraries
providing that exact soname. Thus all
On 15/12/21 14:11, Xyne via arch-dev-public wrote:
On 2021-12-13 18:35 +1000
Allan McRae via arch-dev-public wrote:
Hi all,
I submitted a patchset to pacman that I would like some packager
feed-back on. [1]
Essentially this replaces the old libdepends/libprovides system into
something akin
Hi all,
I submitted a patchset to pacman that I would like some packager
feed-back on. [1]
Essentially this replaces the old libdepends/libprovides system into
something akin to that used by APK. In short, makepkg.conf will have
a variable like:
LIB_DIRS=('lib:usr/lib' 'lib32:usr/lib32')
At
On 1/12/21 08:33, Levente Polyak via arch-dev-public wrote:
On 11/18/21 03:19, Allan McRae via arch-dev-public wrote:
On 18/11/21 00:08, Levente Polyak via arch-dev-public wrote:
The idea so far was to release LTO in a second iteration as some
concerns were raised to do both set of changes at
On 18/11/21 00:08, Levente Polyak via arch-dev-public wrote:
On 11/17/21 13:27, Allan McRae via arch-dev-public wrote:
On 17/11/21 22:03, Jelle van der Waa via arch-dev-public wrote:
## Devtools
* pacman's makepkg.conf is synced with new hardening CFLAGS such as
`-D_FORTIFY_SOURCE=2 -Wf
On 17/11/21 22:03, Jelle van der Waa via arch-dev-public wrote:
## Devtools
* pacman's makepkg.conf is synced with new hardening CFLAGS such as
`-D_FORTIFY_SOURCE=2 -Wformat -Werror=format-security
-fstack-clash-protection -fcf-protection`
Any chance we enable LTO too. This was not added by
I had a long reply to the Konstantin's comments, but I deleted it. I
find the email repeatedly takes statements out of context, or states I
have made claims I clearly have not, and uses this to draw
unsubstantiated conclusions. This makes it difficult to reply in a
manner I consider fitting for i
On 9/10/21 10:07 pm, Alexander Epaneshnikov wrote:
> On Sat, Oct 09, 2021 at 09:17:05PM +1000, Allan McRae via arch-dev-public
> wrote:
>> I am objecting to this RFC being accepted, as that would mean adopting a
>> CoC I consider substandard to the point of being unacceptable.
On 8/10/21 10:20 pm, Konstantin Gizdov via arch-dev-public wrote:
> A new RFC (request for comment) has been opened here:
>
> https://gitlab.archlinux.org/archlinux/rfcs/-/merge_requests/7
>
> Please visit the above link for discussion.
>
> Summary:
> It is shown in some cases that the Trusted U
On 8/10/21 10:44 pm, Morten Linderud via arch-dev-public wrote:
> 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:
>>> Which should satisfy your current problem with the d
On 9/10/21 7:17 pm, Konstantin Gizdov via arch-dev-public wrote:
> Would it suffice if the RFC was changed to point at a specific branch,
> let's say "current"
> and then whatever CoC is later located at the top of that branch would
> be the one the RFC is pointing to, hence enforced?
No. That
On 8/10/21 9:39 pm, Konstantin Gizdov via arch-dev-public wrote:
> Firstly, you are correct that the current GitLab login requires you to
> accept the CoC. In an attempt to remedy this situation, given the
> current software constraints and the risk of being seen as condescending
> (although that i
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
>>>
On 8/10/21 6:01 pm, David Runge wrote:
> 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:3
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:
>>> An RFC has now entered Final Comment Period. In 14 days, discussion will
>>>
On 27/9/21 4:33 am, David Runge via arch-dev-public wrote:
> An RFC has now entered Final Comment Period. In 14 days, discussion will
> end and the proposal will either be accepted, rejected or withdrawn:
>
> https://gitlab.archlinux.org/archlinux/rfcs/-/merge_requests/6
>
> Please visit the abov
On 5/9/21 11:12 am, Giancarlo Razzolini wrote:
> Em setembro 4, 2021 12:17 Allan McRae via arch-dev-public escreveu:
>>
>> The CoC was adopted on the forum, because that is where it was developed
>> as the pet project of an admin at the time. And then spread to the
>> s
On 5/9/21 12:02 am, Giancarlo Razzolini wrote:
> Em setembro 4, 2021 9:36 Allan McRae via arch-dev-public escreveu:
>> We appear to be reaching the point where a formal code of conduct will
>> be officially adopted.
>>
>
> Hmm, it was a long time ago. It's pointed
We appear to be reaching the point where a formal code of conduct will
be officially adopted.
What is that I hear you say? We have had a Code of Conduct for a long
time? And you are incorrect.
The history of the Code of Conduct is poorly documented. But it started
out as a forum guidelines wri
On 14/7/21 8:41 pm, Jonas Witschel via arch-dev-public wrote:
> On 2021-07-14 12:00, David Runge via arch-dev-public wrote:
>> On 2021-07-14 13:58:07 (+1000), Allan McRae via arch-dev-public wrote:
>>> I highly recommend taking a scalpel to the current text. I'm happy to
On 13/7/21 11:42 pm, David Runge via arch-dev-public wrote:
> 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
It is time for my master key to be retired. That can not happen any
time soon, as revoking my key means ~25% of packagers will not be able
to validly sign packages...
For now, I will no longer be signing new packager keys with my master
key. I am unlikely to revoke signatures for people who reti
On 11/5/21 11:20 pm, Morten Linderud via arch-dev-public wrote:
> 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
On 11/5/21 10:28 pm, Lukas Fleischer via arch-dev-public wrote:
> Hi Morten,
>
> Thanks for the summary.
>
> 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
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/2
Please visit the above link for discussion. (Note much discussion in
that link is relevant
Hi all,
A "new" RFC has been opened here:
https://gitlab.archlinux.org/archlinux/rfcs/-/merge_requests/2
Summary:
This RFC is proposing adding an x86_64_v3 port in Arch Linux. Assuming
SSE4 and AVX2 (and others) while compiling will provide greater
out-of-the-box performance in Arch Linux.
This
On 13/3/21 6:47 am, Eli Schwartz via arch-dev-public wrote:
> On 3/4/21 6:33 AM, Allan McRae via arch-dev-public wrote:
>> On 3/3/21 10:54 am, Allan McRae via arch-dev-public wrote:
>>> On 2/3/21 9:51 pm, Allan McRae wrote:
>>>> Hi all,
>>>>
>&
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/4
Please visit the above link for discussion.
Summary: Enable LTO by default in our packages
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/3
Please visit the above link for discussion.
Summary: Update the buildflags in makepkg.con
On 4/3/21 9:51 pm, Filipe Laíns wrote:
> On Thu, 2021-03-04 at 21:33 +1000, Allan McRae via arch-dev-public wrote:
>> On 3/3/21 10:54 am, Allan McRae via arch-dev-public wrote:
>>> On 2/3/21 9:51 pm, Allan McRae wrote:
>>>> Hi all,
>>>>
>&
Hi,
When pacman-6.0 is release, makepkg will provide the option to build
packages using Link Time Optimisation (LTO) by default. This provides
smaller, faster executables/DSOs, and improves GCC diagnostics. SUSE
saw an average 5% decrease in binary size.
In short, makepkg.conf will have:
OPTIO
Hi,
Now we have had some controversy... lets look at some easier RFCs!
The first is about additions to build flags. Specifically, our
makepkg.conf would look like:
#CPPFLAGS=""
CFLAGS="-march=x86-64 -mtune=generic -O2 -pipe -fno-plt -fexceptions \
-Wp,-D_FORTIFY_SOURCE=2,-D_GLIBCXX_ASS
On 3/3/21 10:54 am, Allan McRae via arch-dev-public wrote:
> On 2/3/21 9:51 pm, Allan McRae wrote:
>> Hi all,
>>
>> A new RFC has been opened here:
>> https://gitlab.archlinux.org/archlinux/rfcs/-/merge_requests/2
>>
>> Summary:
>> Make -march=x86_64-v
On 4/3/21 8:30 am, Sven-Hendrik Haase via arch-dev-public wrote:
> I'll also back 3). I think having a general mechanism for this and not
> just bumping baseline and then being able to ship baseline, -v2, -v3,
> -v4 with that hypothetical general mechanism would make more sense and
> be less of a h
On 4/3/21 8:13 am, Evangelos Foutras wrote:
> On Wed, 3 Mar 2021 at 23:34, Allan McRae via arch-dev-public
> wrote:
>> Options realistically are:
>>
>> 1) bump the baseline
>> 2) provide a second more optimized port.
>
> 3) defer this until better tooling is a
On 4/3/21 6:38 am, Filipe Laíns wrote:
> On Wed, 2021-03-03 at 21:11 +1000, Allan McRae via arch-dev-public wrote:
>> On 3/3/21 9:00 pm, Filipe Laíns wrote:
>>> On Wed, 2021-03-03 at 20:52 +1000, Allan McRae via arch-dev-public wrote:
>>>> I'd hate to be the
On 3/3/21 9:00 pm, Filipe Laíns wrote:
> On Wed, 2021-03-03 at 20:52 +1000, Allan McRae via arch-dev-public wrote:
>> On 3/3/21 8:32 pm, Filipe Laíns wrote:
>>> On Wed, 2021-03-03 at 19:44 +1000, Allan McRae via arch-dev-public wrote:
>>>> On 3/3/21 7:31 pm, Filipe L
On 3/3/21 8:32 pm, Filipe Laíns wrote:
> On Wed, 2021-03-03 at 19:44 +1000, Allan McRae via arch-dev-public wrote:
>> On 3/3/21 7:31 pm, Filipe Laíns wrote:
>>> On Wed, 2021-03-03 at 12:12 +1000, Allan McRae via arch-dev-public wrote:
>>>> On 3/3/21 11:56 am, Filipe L
On 3/3/21 7:31 pm, Filipe Laíns wrote:
> On Wed, 2021-03-03 at 12:12 +1000, Allan McRae via arch-dev-public wrote:
>> On 3/3/21 11:56 am, Filipe Laíns wrote:
>>> On Wed, 2021-03-03 at 11:10 +1000, Allan McRae via arch-dev-public wrote:
>>>> On 3/3/21 11:03 am, El
On 3/3/21 11:23 am, Eli Schwartz via arch-dev-public wrote:
> On 3/2/21 8:10 PM, Allan McRae via arch-dev-public wrote:
>> On 3/3/21 11:03 am, Eli Schwartz via arch-dev-public wrote:
>>> I wonder, might this be an interesting time to reintroduce multiple
>>> architecture
On 3/3/21 6:33 pm, NicoHood via arch-dev-public wrote:
> On 3/2/21 12:51 PM, Allan McRae via arch-dev-public wrote:
>> Hi all,
>>
>> A new RFC has been opened here:
>> https://gitlab.archlinux.org/archlinux/rfcs/-/merge_requests/2
>>
>> Summary:
>&
On 3/3/21 11:56 am, Filipe Laíns wrote:
> On Wed, 2021-03-03 at 11:10 +1000, Allan McRae via arch-dev-public wrote:
>> On 3/3/21 11:03 am, Eli Schwartz via arch-dev-public wrote:
>>> I wonder, might this be an interesting time to reintroduce multiple
>>> architecture
On 3/3/21 11:03 am, Eli Schwartz via arch-dev-public wrote:
> I wonder, might this be an interesting time to reintroduce multiple
> architectures?
>
> We used to offer i686 and x86_64.
>
> Maybe now we could offer x86_64, x86_64-v2, and x86_64-v3. Or go right
> to -v4.
>
That is a possibility t
On 2/3/21 9:51 pm, Allan McRae wrote:
> Hi all,
>
> A new RFC has been opened here:
> https://gitlab.archlinux.org/archlinux/rfcs/-/merge_requests/2
>
> Summary:
> Make -march=x86_64-v2 the default for our packages. This assumes the
> following instruction sets which are essentially available on
Hi all,
A new RFC has been opened here:
https://gitlab.archlinux.org/archlinux/rfcs/-/merge_requests/2
Summary:
Make -march=x86_64-v2 the default for our packages. This assumes the
following instruction sets which are essentially available on all but
the oldest AMD CPUs:
CMPXCHG16B, LAHF-SAHF,
72 matches
Mail list logo
