A big shout out to the Arch Conf Team!
This weekend's conference was nothing short of awesome. It pulled
together very well, particularly given the short organisation period and
it being the first one run online.
The recorded talks followed by live Q worked very well, and I enjoyed
the live
On 9/7/20 1:05 pm, Anatol Pomozov wrote:
> Given this information I would like to propose to stop using embedded
> signatures and move to detached signatures by default. This will
> require pacman 6.x or as alternative backport the fix(es) to 5.x
> branch. It will help to make system updates even
Hi all,
A quick updated on the progress of reproducible builds.
You may have noticed a couple of large rebuilds that occurred recently.
These fixed issues of non-reproducible file ordering with old versions
of makepkg. This and other hard work by the team improving our tooling
and fixing
On 30/3/20 12:39 am, Filipe Laíns wrote:
> On Sun, 2020-03-29 at 23:37 +1000, Allan McRae via arch-dev-public wrote:
>> On 29/3/20 11:17 pm, Filipe Laíns wrote:
>>> I would also like to note that rebuilding everything with forced
>>> support for AVX2 or whatever w
On 29/3/20 11:17 pm, Filipe Laíns wrote:
> I would also like to note that rebuilding everything with forced
> support for AVX2 or whatever won't have much effect. Most packages do
> not have workloads where it would make use sense to use these CPU
> extensions, and as such, GCC would not use them.
On 29/3/20 8:52 pm, Evangelos Foutras wrote:
> If I see a SIGILL on my AMD Phenom II X6 1090T then Arch will have failed me.
>
>
> I believe your proposal should only be discussed as co-existing
> optimized port(s) and even then I'm not sure it's worth the trouble.
> Performance-critical
On 29/3/20 9:27 pm, Amish wrote:
> Also if I am not wrong Arch philosophy talks only about latest software
> and no where there is mention of latest hardware being a compulsion.
It used to. One of the original selling points was i686 optimization.
Then we got lazy, and stopped innovating.
A
Remember when Arch Linux was optimized out of the box. We have the
blazingly fast i686 port while other distros hung out in i386 land.
Those were the days where the idea of Arch being fast started. Now it
has degraded to stuff of legend.
Now, x86_64 is old. We should continue to push forward
On 6/1/20 9:12 am, Giancarlo Razzolini wrote:
> Em janeiro 5, 2020 19:25 Allan McRae via arch-dev-public escreveu:
>>
>> Read the original message and not the partial quote that you made. I
>> explicitly said there was an exception for --overwrite type posts.
>>
>&g
On 6/1/20 8:04 am, Morten Linderud via arch-dev-public wrote:
> On Mon, Jan 06, 2020 at 07:53:21AM +1000, Allan McRae via arch-dev-public
> wrote:
>> Following the roll out of the base metapackage, and its poorly written
>> news post, we agreed that all new posts should h
On 6/1/20 8:17 am, Morten Linderud via arch-dev-public wrote:
> On Sun, Jan 05, 2020 at 11:10:17PM +0100, Bartłomiej Piotrowski via
> arch-dev-public wrote:
>> On 05/01/2020 23.04, Morten Linderud via arch-dev-public wrote:
>>> On Mon, Jan 06, 2020 at 07:53:21AM +1000, All
Hi all,
Following the roll out of the base metapackage, and its poorly written
news post, we agreed that all new posts should have a draft posted to
arch-dev-public. There was a potential exclusion for trivial
--overwrite posts [1].
This was followed for the Xorg update. It was not followed
On 4/1/20 12:47 pm, Sébastien Luttringer via arch-dev-public wrote:
> One unfortunate consequence could be to have packages rely on it to make
> dependencies shorter, and make us pull cups or cronie.
What?! That is like saying one unfortunate consequence of pamcan hooks
is that packages can have
On 21/12/19 7:31 pm, Evangelos Foutras via arch-dev-public wrote:
> Downstream consumers of libx11 shouldn't have to know and account for
> libx11's headers/pkg-config files referencing xorgproto. A
> libx11-devel package would depend on xorgproto. Since there's no
> separate -devel package, the
On 20/12/19 8:35 am, Andreas Radke via arch-dev-public wrote:
> Packages have been rebuilt and prepared to remove obsolete libdmx and
> libxxf86dga. Xorgproto legacy support has been removed and wherever it
> was added to be a runtime dependency it is now a build time
> dependency. Some packages
On 12/12/19 10:21 pm, Christian Rebischke via arch-dev-public wrote:
> 3. revive the discussion around better PKGBUILD quality (see also Eli's
> thread about PKGBUILD quality on arch-tu:
> https://lists.archlinux.org/private/arch-tu/2019-November/83.html)
Any chance that can be posted
Hi all,
As you may know, we have had people busy looking at what it takes to
make our packages reproducible.
There has been a lot of progress there lately. Our reproducible builds
team (along with the wider reproducible builds community) has been
building our packages in different environments
On 22/10/19 9:59 pm, Jerome Leclanche wrote:
> It would also be a
> little more accurate; eg. the SPDX allows for distinctions such as
> "LGPL-3.0-or-later" vs. "LGPL-3.0-only".
I thought we already managed that, but it seems in rather limited use
these days looking at our -Si output. e.g.
On 30/7/19 10:44 am, Christian Rebischke wrote:
> One problem I see with the News section is that it's Dev only. I
> wouldn't even know who I need to ask (and I am TU for several years
> now). I mean I could just ask around in the IRC, but it would be nice to
> have this at least documented
On 30/7/19 8:47 am, Christian Rebischke via arch-dev-public wrote:
> Hello everybody,
> I got assigned to this issue here:
>
> https://bugs.archlinux.org/task/62823
>
> The users would like to have a notice in pre/post install/upgrade
> notifications via pacman .install files.
>
> I am not a
On 3/6/19 2:39 pm, Christian Rebischke via arch-dev-public wrote:
> 3. I don't like that devs and TUs live aside each other instead of
> finally realizing themselves as community or group.
The TUs are set up as an independent organisation with their own bylaws.
Many of those bylaws were
On 2/6/19 9:08 am, Christian Rebischke via arch-dev-public wrote:
> 1. Simplified repositories
>
> Currently we have [core], [extra] and [community]. These three
> repositories are there, because they have grown to this structure over
> time. At the moment I don't see any real meaning for the
On 2/6/19 1:53 am, Ike Devolder via arch-dev-public wrote:
> On Sat, 2019-06-01 at 21:30 +1000, Allan McRae wrote:
>> You don't seem to
>> explain why you need to ask in your email.
>
> Because it is proprietary and I explain that now there is a valid
> reason compared to 3 years ago where there
On 1/6/19 8:12 pm, Ike Devolder via arch-dev-public wrote:
> 3 years have passed since I first proposed to bring vivaldi into
> community. Now there is a clear differentiation between what vivaldi
> offers out-of-the box compared to other browsers.
>
> Vivaldi offers a ton of customisation
On 25/5/19 9:34 pm, Bruno Pagani wrote:
> Out of curiosity, what did you rebuild of [core] lead to?
I had a potentially slightly faster system for a week... It was mainly
a test to see if I spotted some build issues of test suite failures
beyond what is seen for x86_64. All was good.
A
On 25/5/19 9:19 pm, Bruno Pagani via arch-dev-public wrote:
> Hi,
>
> Le 25/05/2019 à 02:17, Filipe Laíns via arch-dev-public a écrit :
>> I would also like to explore the idea of adding an "high performance"
>> architecture which would be able to make use of SSE{,2,3,4,4.1,4.2} and
>> AVX, which
On 25/5/19 5:22 pm, Lukas Jirkovsky via arch-dev-public wrote:
> On Sat, 25 May 2019 at 04:27, Filipe Laíns via arch-dev-public
> wrote:
>> Setting `-mtune` to generic won't add any additional instruction sets
>> by itself, but it does not prevent instruction sets from being added.
>> Looks like
On 25/5/19 10:17 am, Filipe Laíns via arch-dev-public wrote:
> Hello,
>
> Currently there are no guidelines stating which x86 extensions (ex.
> SSE2, SEE3, SSE4, AVX, etc.) we support. This is a bit problematic
> since it lets compilers do what they want and possible generate code
> that can't
Given the suggestion of using -18-, I decided to calculate how much
bigger our packages would be with the numbers given:
cuda-10.0.130-2-x86_64.pkg.tar 58.5M 104.40%
gcc-8.2.1+20181127-1-x86_64.pkg.tar 2.8M108.30%
go-2:1.12.1-1-x86_64.pkg.tar
On 25/3/19 9:28 am, Robin Broda via arch-dev-public wrote:
> On 3/25/19 12:22 AM, Andrew Gregory wrote:
>> On 03/25/19 at 12:15am, Robin Broda via arch-dev-public wrote:
>>> On 3/24/19 11:20 PM, Evangelos Foutras via arch-dev-public wrote:
>>>> On Sun, 24 Mar 2019
On 25/3/19 4:34 am, Robin Broda via arch-dev-public wrote:
> This change requires a new pacman release, as as of writing this, zstd
> support is in master but hasn't landed in a release yet.
Which is a complete blocker for quite a period of time.
We need to assume every system has a copy of
On 3/14/19 8:46 AM, Morten Linderud via arch-dev-public wrote:
> There is a *lot* of small tools people have written over the years that
> resides
> in bin/ directories which could be useful for more people. We also have
> several
> such tools on soyuz, where sogrep was added to devtools this
On 17/2/19 10:37 am, Eli Schwartz via arch-dev-public wrote:
> On 2/16/19 4:36 PM, Christian Hesse wrote:
>> Allan McRae via arch-dev-public on Sat,
>> 2019/02/16 11:19:
>>> Below is a list of python2 modules that are a dependency for any other
>>> package. I di
Hi all,
Python 2 reaches End of Life on 2020-01-01. We currently have >950
python2 modules in the repos. A lot of these are not used by any other
package in the repositories. I think we should work towards removing them.
Leaving only python2 modules that are really required by other
On 13/2/19 8:17 am, Levente Polyak via arch-dev-public wrote:
> On 2/12/19 7:16 PM, Gaetan Bisson via arch-dev-public wrote:
>> [2019-02-12 16:40:08 +0100] Bruno Pagani via arch-dev-public:
>>> Just in case it wasn’t clear, my answer would have been mostly the same
>>> as Eli’s.
>>>
>>> So,
On 5/2/19 11:38 pm, Bruno Pagani wrote:
> Maybe. As I said in my answer to Bartłomiej, I don’t know if beginners
> know enough things to install what they need beyond the minimum system,
> or if they just read the wiki about doing this or that, which might
> assume they have the current base group
On 5/2/19 9:06 pm, Bruno Pagani wrote:
> Le 22/01/2019 à 00:59, Allan McRae a écrit :
>> On 22/1/19 9:41 am, Bruno Pagani wrote:
>>> Le 22/01/2019 à 00:23, Allan McRae via arch-dev-public a écrit :
>>>> On 22/1/19 8:03 am, Levente Polyak via arch-dev-public wrot
On 22/1/19 9:41 am, Bruno Pagani wrote:
> Le 22/01/2019 à 00:23, Allan McRae via arch-dev-public a écrit :
>> On 22/1/19 8:03 am, Levente Polyak via arch-dev-public wrote:
>>> Everything that won’t be part of base-system needs to be added as a
>>> dependenc
On 22/1/19 8:03 am, Levente Polyak via arch-dev-public wrote:
> Everything that won’t be part of base-system needs to be added as a
> dependency to all requiring packages; alternatively don't omit any first
> level runtime dependencies at all.
>
> This package should only depend on strictly
On 17/1/19 12:02 am, Morten Linderud via arch-dev-public wrote:
> Yo!
>
> As probably some of you have realized, there is a discussion regarding mongodb
> and the relicense from AGPLv3 to SSPLv1.
> Under section "5. Conveying Modified Source Versions" the most relevant part
> for
> us is
On 6/11/18 8:15 pm, Bruno Pagani wrote:
> Le 06/11/2018 à 11:12, Christian Rebischke via arch-dev-public a écrit :
>> On Tue, Nov 06, 2018 at 08:09:03PM +1000, Allan McRae wrote:
>>> On 6/11/18 7:54 pm, Christian Rebischke via arch-dev-public wrote:
Hello everybody,
First of all,
On 6/11/18 7:54 pm, Christian Rebischke via arch-dev-public wrote:
> Hello everybody,
>
> First of all, the following mail has nothing to do with the last two TU
> applications, it's a general view on the current TU application process.
>
> I would like to propose a new process for TU
On 13/10/18 7:23 pm, NicoHood wrote:
> I ran extra-x86_64-build on a new system with an uninitialized gnupg
> keyring. I think it was responsible for creating a .~/gnupg directory,
> but with root privilegs.
>
> I chowned it to my user, it is all good now. Maybe the script could be
> improved to
On 29/05/18 11:00, Sven-Hendrik Haase wrote:
> Hey,
>
> I would like to move gcc7 (based on the latest version 7 commit of gcc [0])
> into [community] because of cuda 9.2 and in return drop gcc54.
>
> I tried to make it work with current gcc but to no avail. In earlier
> releases of cuda the
On 14/03/18 04:19, Bartłomiej Piotrowski via arch-dev-public wrote:
> On 2018-03-13 14:40, Allan McRae via arch-dev-public wrote:
>> On 13/03/18 21:22, Jan Alexander Steffens via arch-dev-public wrote:
>>> For that matter, I'm all for putting an arch-configure helper into our
&g
On 13/03/18 21:22, Jan Alexander Steffens via arch-dev-public wrote:
> For that matter, I'm all for putting an arch-configure helper into our
> autoconf package.
Don't muck around with vanilla packages. Put it in another package
(devtools).
A
On 14/02/18 22:28, Florian Pritz via arch-dev-public wrote:
> How about having this feature in pacman, maybe with an indicator if the
> package is still in a repository?
pacman -Qtd
Just because I had to look up the details of this
- xorgproto replaces a lot of packages, including fontsproto:
:: Replace fontsproto with extra/xorgproto? [Y/n]
- libxfont requires fontsproto, so this causes the following:
:: libxfont: removing fontsproto breaks dependency
On 04/01/18 22:02, Balló György via arch-dev-public wrote:
> Currently the 'xfce4-goodies' package group[1] is in split between [extra]
> and [community]. Most of its packages are in [extra], but 'ristretto' and
> 'xfce4-whiskermenu-plugin' are in [community].
>
> My question is: is it okay, or
49 matches
Mail list logo
