Re: [arch-dev-public] Changing compilation flags

On 7 July 2017 at 19:17, Jordan Glover wrote: > I'm surprised as it seemed to me that Daniel took it for granted that > patch like that will get accepted. Anyway it's hard for an outsider to > successfully submit anything to big upstream project. I hope you'll be

Re: [arch-dev-public] Changing compilation flags

On 7 July 2017 at 16:39, Jordan Glover wrote: > FYI clang devs don't want to take 1 line patch adding another no-op flag > upstream. > https://lists.llvm.org/pipermail/cfe-dev/2017-July/054588.html Thanks for trying to push the change upstream. I'm sorry they

Re: [arch-dev-public] Changing compilation flags

On 30 June 2017 at 18:56, Daniel Micay via arch-dev-public wrote: > It's probably a good idea to leave it in CFLAGS for Clang. I am planning to patch Clang to follow GCC's behavior similarly to what Alpine does. [1] We can discuss dropping the related compilation

Re: [arch-dev-public] Changing compilation flags

On 30/06/17 22:22, Jelle van der Waa wrote: > On 06/30/17 at 09:49pm, Evangelos Foutras via arch-dev-public wrote: >> On 30 June 2017 at 18:56, Daniel Micay via arch-dev-public >> <arch-dev-public@archlinux.org> wrote: >>> It's probably a good idea to leave it i

Re: [arch-dev-public] Changing compilation flags

On 2 July 2017 at 19:19, Daniel Micay via arch-dev-public wrote: > Using -fno-plt would be a nice tiny little performance boost at runtime > but then it's important to make sure everything is compiled with -Wl,- > z,now and there might be programs ignoring LDFLAGS

Re: [arch-dev-public] Changing compilation flags

On 5 July 2017 at 19:51, Daniel Micay wrote: > On Wed, 2017-07-05 at 12:36 +0300, Evangelos Foutras wrote: >> On 2 July 2017 at 19:19, Daniel Micay via arch-dev-public >> wrote: >> > Using -fno-plt would be a nice tiny little performance

[arch-dev-public] Resigning as TU

For a long time I have been inactive in TU matters (i.e.: handling AUR requests, looking into TU applicants, and overseeing community contributions in general). Due to this, I feel it's proper to let go of my TU title. No heartfelt goodbyes, since my involvement in Arch remains unchanged. (On a

[arch-dev-public] Replacing pycrypto with pycryptodome

Antonio suggested on IRC to drop pycrypto in favor of pycryptodome. The latter is "an almost drop-in replacement for the old PyCrypto library" according to its documentation. pycrypto has been unmaintained for several years. [1] Unless someone objects in the next few days, I'll proceed to drop

Re: [arch-dev-public] Replacing pycrypto with pycryptodome

On 27 August 2018 at 22:19, Evangelos Foutras wrote: > Unless someone objects in the next few days, I'll proceed to drop > python-crypto and add replaces=() to python-pycryptodome. This has now been implemented.

[arch-dev-public] LLVM 6 and splitting up {clang, lld, lldb, compiler-rt} into separate PKGBUILDs

I pushed llvm 6.0.0-1 to [staging] without the rest of the packages mentioned in the subject. I am planning to add them back as individual packages in the following days. This separation will bring faster builds when one of these components needs patching. It also allows building clang with

[arch-dev-public] Caution when moving packages built against glibc 2.27

Care should be taken when building against glibc 2.27 (which is currently in [staging]). In particular: - While glibc 2.27 is in [staging], new rebuilds should not be started. - After glibc 2.27 migrates to [testing], packages built against it should remain in [testing] until glibc 2.27

Re: [arch-dev-public] Caution when moving packages built against glibc 2.27

On 13 April 2018 at 18:17, Evangelos Foutras wrote: > Care should be taken when building against glibc 2.27 (which is currently > in [staging]). > > In particular: > >- While glibc 2.27 is in [staging], new rebuilds should not be started. >- After glibc 2.27

Re: [arch-dev-public] New build server in Singapore

On 24 March 2018 at 21:33, Bartłomiej Piotrowski via arch-dev-public < arch-dev-public@archlinux.org> wrote: > For the record, the build server lives on at sgp.mirror.pkgbuild.com. > Thanks for taking care of it. I updated the sgp.pkgbuild.com record to point to the same box.

Re: [arch-dev-public] LLVM 6.0 rebuild

On 16/03/18 17:29, Anatol Pomozov via arch-dev-public wrote: > This LLVM bug is fixed in HEAD (https://reviews.llvm.org/D44140) and > should be released in 6.0.1. Or maybe we can pull it to the Arch > package? It will be included in llvm-6.0.0-4 shortly.

[arch-dev-public] Ongoing rebuilds; keep [staging] clear

The following rebuilds will be taking place in the following days: - readline - mariadb - boost - exiv2 - libidn2 - poppler Please avoid starting any new rebuilds until these are done.

Re: [arch-dev-public] RFC: (devtools) Changing default compression method to zstd

On Mon, 25 Mar 2019 at 02:47, Robin Broda via arch-dev-public wrote: > What's unclear to me is the difference between zstd -T0 and zstdmt, however. zstdmt is an alias/shortcut for "zstd -T0". > I do think that at -19+, memory usage becomes a bigger issue. > The difference between -18 and -19 on

Re: [arch-dev-public] RFC: (devtools) Changing default compression method to zstd

On Sun, 24 Mar 2019 at 23:45, Allan McRae via arch-dev-public wrote: > > 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

Re: [arch-dev-public] RFC: (devtools) Changing default compression method to zstd

On Mon, 25 Mar 2019 at 01:22, Jan Alexander Steffens via arch-dev-public wrote: > > On Sun, Mar 24, 2019 at 7:35 PM Robin Broda via arch-dev-public > wrote: > > The required changeset is, i think: > > PKGEXT='.pkg.tar.zst' > > COMPRESSZST=(zstd -c -T0 -18 -) > > When we implement this, I would

Re: [arch-dev-public] Spring cleaning (take 2)

On Thu, 28 Mar 2019 at 10:04, yan12125--- via arch-dev-public wrote: > > ttf-arphic-ukai > > ttf-arphic-uming > > Hi, > > These two fonts are still useful to me. Could anyone move them to > [community]? Moved. :)

Re: [arch-dev-public] GCC 9 removed from [testing]

On Sun, 26 May 2019 at 19:51, Bartłomiej Piotrowski via arch-dev-public wrote: > You will have to -Syuu your systems. Also remember to recreate your testing and staging chroots!

Re: [arch-dev-public] packaging hunspell dictionaries converted for qt5-webengine

On Tue, 13 Aug 2019 at 18:50, Eli Schwartz via arch-dev-public < arch-dev-public@archlinux.org> wrote: > On August 13, 2019 3:03:59 AM EDT, "Bartłomiej Piotrowski via > arch-dev-public" wrote: > > I'd go with updating all packages to ship the converted files. > > Cluttering /usr with untracked

Re: [arch-dev-public] Python 3.8 rebuilds

On Fri, 25 Oct 2019 at 14:34, Evangelos Foutras wrote: > > For the next few days we'll be doing (semi-automated) rebuilds for Python 3.8. > > Please avoid adding new Python packages and starting other rebuilds > during this time. Quick update: The rebuild is taking longer than expected, mainly

[arch-dev-public] Python 3.8 rebuilds

For the next few days we'll be doing (semi-automated) rebuilds for Python 3.8. Please avoid adding new Python packages and starting other rebuilds during this time.

Re: [arch-dev-public] libx11/xorgproto dependency

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 dependency stays with the regular libx11 package. You already called (a)

Re: [arch-dev-public] libx11/xorgproto dependency

On Sat, 21 Dec 2019 at 18:13, Jan Alexander Steffens via arch-dev-public wrote: > > We now have many packages that want libx11 but say nothing about *proto, > yet they now need xorgproto as a makedepend. > Even worse, this extends further downstream, and packages building against > GTK now also

[arch-dev-public] Potential removal of Chromium in ~2 months

Just a quick heads up that I am considering dropping Chromium from [extra] a week or two before the Chromium 82 stable release (~April 28). The reason for this is that our API keys no longer work for geolocation requests and there is no clear upstream guidance on how to resolve this issue. [1]

Re: [arch-dev-public] Potential removal of Chromium in ~2 months

On 22/02/2020 14:31, Dave Reisner wrote: > We've talked about this. You're well aware that this isn't an accurate > portrayal of the situation. I'm happy to guide you (or anyone else) > through the remedy. What you're looking for is continuation of the > preferential treatment that distros have

Re: [arch-dev-public] Discussion - Increasing our CPU requirements

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 applications can and frequently are optimized for the running

Re: [arch-dev-public] Pam lockout

On Fri, 11 Sep 2020 at 17:05, Giancarlo Razzolini via arch-dev-public wrote: > I third you and Levente's opinion. This is a sane upstream default and should > be handled by users, if they wish to. We shouldn't deviate from upstream in > this > case. It's not an upstream default though. It's

Re: [arch-dev-public] Pam lockout

On Fri, 11 Sep 2020 at 17:33, Tobias Powalowski via arch-dev-public wrote: > > Hi, > the 3 attempts are default. It is not overridden in the config. It was just > a transition to the new module. tally2 used to be in system-login, whereas faillock is part of system-auth. sudo includes the latter

Re: [arch-dev-public] Packages added to todo list 'Remove libjpeg from depends/makedepends/optdepends and use shared object dependency'

David, following the concerns raised on IRC [1], is this todo getting canceled? [1] no prior discussion, library with stable soname, prioritization and scalability of adding sodeps to more packages

Re: [arch-dev-public] [RFC] Removing maintainer/contributor lines from PKGBUILDs

On Wed, 26 Aug 2020 at 01:11, Eli Schwartz via arch-dev-public wrote: > The information cannot be replaced and is not redundant. But it might be > that no one actually cares about the information. On the other hand, is > it bothersome to have it there anyway? All right, I'm withdrawing my

[arch-dev-public] [RFC] Removing maintainer/contributor lines from PKGBUILDs

I am not sure these serve any purpose. The maintainer line duplicates information available from the archweb or aur interfaces and could also be outdated. The contributor lines are mostly redundant with svn or git history, can take up several lines in the PKGBUILD and can become irrelevant after

Re: [arch-dev-public] [PATCH 2/2] makepkg.conf: Update our default FLAGS

On Fri, 10 Jul 2020 at 21:45, Jan Alexander Steffens (heftig) via arch-dev-public wrote: > 3. -fstack-clash-protection: >Hardening of large stack allocations. Cost should be negigible. > >We need to patch clang to ignore this, like we once did for -fno-plt. Apparently, Fedora didn't

[arch-dev-public] Python 3.9 enters the testing repos

We'll probably want to keep it in testing for a week or two. Please don't add new Python packages during this time. Many thanks to everyone who helped with the build failures. 殺

[arch-dev-public] Python 3.9 rebuilds

For the next few days we'll be doing (semi-automated) rebuilds for Python 3.9. Please avoid adding new Python packages and starting other rebuilds during this time. Some PKGBUILDs were modified in /trunk to use the Python 3.9 site-packages path (among other tweaks). Building those against Python

Re: [arch-dev-public] Python 3.9 rebuilds

On Sun, 15 Nov 2020 at 10:56, wrote: > > I see you have added kodi in this list. Currently python 3 is still > out-of-scope here. Until there is an official release that requires > python 3, kodi will be built against its python 2 dependencies. Indeed, kodi was included by mistake (also: dia,