On 07/07/2017 11:42 AM, Florian Pritz via arch-dev-public wrote:
> Hi,
>
> Eli Schwartz has just joined Doug as a bug wrangler and will help us
> deal with bugs even better.
>
> Welcome Eli!
>
> Florian
>
Hi. :)
Thanks, Doug, for inviting me to help out. I'm grateful for the
opportunity to co
On 01/03/2018 10:05 AM, Bartłomiej Piotrowski via arch-dev-public wrote:
> - autoconf-archive:
> jgc: dbus, gspell, gnumeric
> tomegun: dbus, dbus-docs, libimobiledevice
> heftig: gst-plugins-base-libs, gstreamer, libgweather
> zorun: ring-daemon
> fyan: lib32-gst-plugins-good,
On 01/14/2018 10:20 AM, Baptiste Jonglez wrote:
> Hi,
>
> Today I am experiencing build failures of several packages when using the
> devtools:
>
> $ extra-x86_64-build -- -I ../../another-package/trunk/foo.pkg.tar.xz
> (...)
> ==> Making package: ring-gnome 3:20180112.2.d0bda53-1 (Su
On 01/21/2018 02:39 PM, Christian Rebischke via arch-dev-public wrote:
> No idea about the bootstrap image. Is there a big difference between the
> bootstrap image and `pacstrap` in some random directory?
There is no difference, the bootstrap image is what you use to pacstrap.
The issue is merely
On 01/29/2018 02:19 PM, Pierre Schmitz wrote:
> Hi all. I feel bad about this. I was not transparent at all about my
> plans and got lost in a pile of projects which are only slowly
> progressing. I started improving dbscripts to make it easier to work
> with; which led to creating a Docker base im
On 01/29/2018 03:27 PM, Pierre Schmitz wrote:
> Two possible strategies:
> a) Gradual migration: It might not work out for some aspects, but
> maybe there is way to prepare the current code to replace svn by git
> and postpoing the actual switch to the very end. It's also a good
> strategy to alway
On 01/29/2018 04:00 PM, Christian Rebischke via arch-dev-public wrote:
> I would like to hear as much feedback as possible. So don't be shy :)
> I want to give feedback to the microsoft guys in round about 1 week.
> I guess that should be enough to dicuss this topic.
I'd like to reiterate what eve
On 02/13/2018 09:29 AM, Bartłomiej Piotrowski via arch-dev-public wrote:
>>> I have updated gcc in the repository to snapshot from 2018-02-11
>>> (r257571). Additionally, if you have access to soyuz, the repo can be
>>> easily used in build chroots with 'gcc8-x86_64-build' command (which
>>> also e
On 02/13/2018 06:56 PM, Baptiste Jonglez wrote:
> Hi,
>
> Eli and I disagree about how dependency conflicts should be handled when
> packaging. This was prompted by the libxfont dependency conflict arising
> from recent xorgproto changes [1].
>
> [...]
>
> [1] https://bugs.archlinux.org/task/5749
On 03/10/2018 05:34 AM, Antonio Rojas via arch-dev-public wrote:
> Hi, Currently most of our packages which use the cmake build system
> are built with -DCMAKE_BUILD_TYPE=Release. This provides a reasonable
> (according to upstream) set of C(XX)FLAGS defaults which are appended
> to and override ou
On 03/11/2018 05:00 AM, Antonio Rojas via arch-dev-public wrote:
> This is very poorly documented, so you have to dig into the cmake
> code to figure it out. The default build type is None, which means
> CMAKE_C(XX)_FLAGS is used (see
> /usr/share/cmake-3.10/Modules/CMakeCInformation.cmake:117), wh
On 03/13/2018 07:22 AM, Jan Alexander Steffens wrote:
> It's not magical. This doesn't even compare to dpkg-buildpackage's hooks
> and buildsystem handling, which changes behavior drastically based on
> what's installed and what the source tree looks like.
>
> arch-meson is just a wrapper providin
It's the Passover holiday season again... I'll be a combination of
offline and difficult to reach for the next week, week and a half.
--
Eli Schwartz
Bug Wrangler and Trusted User
signature.asc
Description: OpenPGP digital signature
On 04/16/2018 07:24 AM, Bartłomiej Piotrowski via arch-dev-public wrote:
> On 2018-04-16 13:02, Bartłomiej Piotrowski via arch-dev-public wrote:
>> Hi team,
>>
>> During libnsl rebuild heftig pointed out that we are shipping
>> pam_unix2 that has been dead upstream for a long time (to the point
>>
On 04/19/2018 03:19 PM, Florian Pritz via arch-dev-public wrote:
> We already have a second build server (sgp.pkgbuild.com) which is hardly
> used. Souyz is really used quite a bit, but in general it has quite some
> resources left to spare. I guess it depends on what you want and when.
> Do you wa
The last package to depend on js38 was cjs, and with the completion of
the cinnamon 3.8 rollout this too is ported to js52.
There's no reason to continue to keep this in the repos AFAICT.
...
On the topic of the various js* packages, we've had to rebuild some
packages which used the /usr/bin/js
On 05/28/2018 09:09 PM, Allan McRae via arch-dev-public wrote:
> 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 wit
On 05/29/2018 03:56 PM, Anatol Pomozov wrote:
> gcc-cuda will probably introduce a lot of confusion. Let's use
> standard naming practice for the old versioned packages (i.e. gcc7 or
> gcc-7).
Sorry, that was a joke. :D
I think gcc7 is fine, if anyone complains tell them it's really gcc-cuda
in d
On 05/22/2018 04:25 PM, Morten Linderud via arch-dev-public wrote:
> Yo!
>
> In April there was some discussion regarding how to properly do unit testing
> in
> Python PKGBUILDs[1]. Felix had some amazing notes that was super useful. But
> as
> pointed out we don't really strive to document thes
On 06/28/2018 05:59 PM, Felix Yan wrote:
> The main reason behind this (or why I started doing this) was sometimes
> the tests run inside the sources tree made both versions' .pyc files
> into the tree itself, and finally end up in the package. I had this
> problem for several times and end up havi
On 06/28/2018 05:06 PM, Eli Schwartz wrote:
> The one case where this would make a difference is where 2to3 is being
> used, so depending on which version of python you use the actual source
> code is modified. I think the guidelines should only mention that "if
> 2to3 is used, you'll need to make
Hi, so for a while now I've been using a tool I wrote at
https://github.com/eli-schwartz/aurpublish -- recently split out from a
vendored script in https://github.com/eli-schwartz/pkgbuilds -- to
maintain my AUR packages. Some of you will probably have heard about it
before. :)
I certainly think i
On 07/20/2018 04:23 AM, WorMzy Tykashi via arch-general wrote:
> On 20 July 2018 at 08:38, Jelle van der Waa wrote:
>
>> On 07/20/18 at 09:05am, Jelle van der Waa wrote:
>>> On 07/19/18 at 07:23pm, Florian Pritz via arch-dev-public wrote:
>>>> On Wed 18.07.18 -
via arch-dev-public wrote:
>>>>> On Wed 18.07.18 - 15:28, Eli Schwartz via arch-dev-public wrote:
>>>>>> I would like to add this to [community], but I'm unsure what people
>>>>>> think about this; specifically, whether this might come t
On 8/9/18 12:41 PM, Morten Linderud via arch-dev-public wrote:
> Yo!
>
> The subreddit /r/linux have started organizing AMA threads for relevant
> projects. Gentoo had one of these a few months ago and is an interesting read.
>
> https://www.reddit.com/r/linux/comments/8nsdj0/we_are_gentoo_develo
On 8/24/18 6:00 AM, David Runge wrote:
>> lmms
> This should already be Qt5 capable. Rebuild incoming.
https://bugs.archlinux.org/task/47723
Available in the beta only, AFAIK.
>> mixxx
> I hope this is portable! It's the only cross-platform tool for DJing.
Also builds with qt5 on master (so sho
On 8/29/18 4:23 PM, Jelle van der Waa wrote:
> Most of our PKGBUILDs svn propset's break reproducible builds and the
> pkgbuild_sha256sum in the BUILDINFO file. When building a package before
> commiting the PKGBUILD the propset $Id will differ since the $Id is set on
> commit.
>
> This has a few
On 8/29/18 6:35 PM, Gaetan Bisson via arch-dev-public wrote:
> [2018-08-29 20:20:29 +0200] Morten Linderud via arch-dev-public:
>> The rewrites have been up for a few months now and I intend to merge them
>> soon.
>> Feel free to still review them, either with a reply on the ML or on IRC.
>> What
It is High Holiday season, so I will be away at a minimum, tomorrow and
Tuesday, then Wednesday the 19th and the week after that. (Plus, you
know, general hecticness.) I'll be irregularly available until October
3rd, in other words.
All the best. :)
--
Eli Schwartz
Bug Wrangler and Trusted User
On 11/6/18 7:32 AM, Bartłomiej Piotrowski via arch-dev-public wrote:
>> Here again I would argue that they are devs that have [core] pushing
>> rights, as well as devs that are Master Key holders. So even if you
>> don’t want to write this black on white, this actually means a small
>> group of peo
On 11/9/18 5:29 PM, Jelle van der Waa wrote:
> On 11/09/18 at 10:54pm, Jelle van der Waa wrote:
>> Hi all,
>>
>> There are rebuilds ongoing for packages build before 2017-01-01, this
>> *should* add PIE and the newer BUILDINFO format to these old packages.
>> And uncovers some build failures, which
On 12/16/18 3:52 PM, Dave Reisner wrote:
> Hi,
>
> I'm finding myself lacking these days in both time and motivation to
> continue maintenance of both mkinitcpio and arch-install-scripts. Is
> anyone interested in taking these over? Both projects are fairly stable,
> but bugs do crop up as the res
In the effort to have reproducible builds, it is important to have
availability of all dependent packages listed in the .BUILDINFO
description of a built package. Due to previous efforts within Arch
Linux, we do have a daily snapshot of the repos, but this could
potentially result in missing packag
On 1/21/19 5:03 PM, Levente Polyak via arch-dev-public wrote:
> # Proposal
>
> There is no strict definition of what a minimal Arch Linux system
> installation must contain. However in reality we mostly don’t add any
> packages that are in the base group as a dependency to other packages,
> which
On 1/21/19 6:53 PM, Giancarlo Razzolini via arch-dev-public wrote:
> I agree with this package list. It's missing mkinitcpio though.
No it is not, mkinitcpio is definitively not needed.
It's only required in order to execute the pacman hooks for a linux
kernel package (or do so manually). And cor
On 2/5/19 4:31 PM, Gaetan Bisson via arch-dev-public wrote:
> Bruno,
>
> We all seem to agree that [base] plays no satisfactory role in its
> current state, so I think Allan definitely has a point: let us first
> turn [base] into something useful, and only then wonder if we need
> something more.
On 2/6/19 4:16 PM, Jelle van der Waa wrote:
> Hi,
>
> I still believe we should take some initiative on thse issues. What we
> have so far is:
>
> - Getting involved page, not sure where it's linked from? Only findable
> on the wiki. [1] Which links to a nice list of projects with an
> alread
On 2/11/19 1:17 PM, NicoHood wrote:
> Hi,
> I am using devtools to create a package with php scripts. It uses
> composer to build the package. I get the error:
>
> The requested PHP extension ext-iconv * is missing from your system.
> Install or enable PHP's iconv extension.
>
> This can be solve
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 did not check makedepends and I did not check recursively to
>> build this list.
>
> The list contains o
On 2/17/19 4:23 AM, Allan McRae wrote:
> 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 modu
On 3/24/19 8:38 PM, Evangelos Foutras via arch-dev-public wrote:
> 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'
>>
On 3/25/19 12:13 AM, Robin Broda via arch-dev-public wrote:
> Given that low-end systems can simply change the thread allocation to 1 or 2
> to slash the compressor memory usage as a trade-off on speed,
> i don't think that is a problem.
>
> New changeset:
> PKGEXT='.pkg.tar.zst'
> COMPRESSZST=(z
On 4/28/19 6:44 AM, Antonio Rojas via arch-dev-public wrote:
> Hi all,
>
> Now that mumble has been ported to Qt5, I think it's time to finally
> drop Qt4, which has been EOL for 4 years. Most stuff that still depends
> on it has been dead upstream for many years. Here is a full list of
> applicat
On 5/26/19 12:51 PM, Bartłomiej Piotrowski via arch-dev-public wrote:
> Hi all,
>
> I just deleted GCC 9 and related packages from [testing] due to the
> filesystem corruption bug when bcache is used[1]. You will have to -Syuu
> your systems.
>
> People hungry for breakage can install it from [gc
On 6/1/19 5:43 PM, Allan McRae via arch-dev-public wrote:
> 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
On 6/1/19 7:08 PM, Christian Rebischke via arch-dev-public wrote:
> Hello everybody,
>
>
> DISCLAIMER:
> Sorry for the huge mail, I didn't thought it would get so long. If you
> feel attacked/angry or whatever about it, take a deep breath before you
> answer. I hope fo
On 6/2/19 2:59 AM, Ike Devolder wrote:
> On Sat, 2019-06-01 at 22:11 -0400, Eli Schwartz via arch-dev-public
> wrote:
>> On 6/1/19 5:43 PM, Allan McRae via arch-dev-public wrote:
>>> On 2/6/19 1:53 am, Ike Devolder via arch-dev-public wrote:
>>>> On Sat, 2019-
On 7/29/19 6:47 PM, 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 fan
On 8/6/19 1:21 PM, Jürgen Hötzel wrote:
> Hi,
>
> Unfortunately it is not possible to compile camlp4 with OCaml >= 4.08.
>
> But some well known packages depend on this preprocessor. E.g. :Haxe,
> lablgtk2 (therefore also: Unison and Coq).
>
> I don't see that these projects will be migrated to
QtWebEngine supports spellchecking:
https://doc.qt.io/qt-5/qtwebengine-features.html#spellchecker
However, they have helpfully decided (steered by upstream chromium) to
*not* use hunspell dictionaries, and instead to use... hunspell
dictionaries stored in /usr/share/qt/qtwebengine_dictionaries/ as
On 8/6/19 3:22 PM, Eli Schwartz wrote:
> BTW in addition to haxe and lablgtk2, there is also lablgl, which I need
> for llpp -- but I don't really know ocaml as a programming language so I
> don't know if that can be easily migrated to something new; also, it
> seems to be kind of "feature frozen"
On August 13, 2019 5:17:27 AM EDT, Florian Bruhin wrote:
> Hey,
>
> My $0.02 as qutebrowser maintainer (off-list because I can't send to
> arch-dev-public):
Forwarded back to a-d-p with inline comments. :)
> On Mon, Aug 12, 2019 at 07:50:44PM -0400, Eli Schwartz via
>
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 files doesn't sound good.
I agree, that's my preferred option too -- but I need buy-in from all
hunspell-* main
On August 13, 2019 3:22:39 AM EDT, Jan Alexander Steffens via arch-dev-public
wrote:
> On Tue, Aug 13, 2019 at 9:04 AM Bartłomiej Piotrowski via
> arch-dev-public <
> arch-dev-public@archlinux.org> wrote:
> > I'd go with updating all packages to ship the converted files.
> > Cluttering /usr with
On 8/13/19 12:05 PM, Eli Schwartz wrote:
> On August 13, 2019 3:22:39 AM EDT, Jan Alexander Steffens wrote:
>> Assuming that WebEngine will not be the only consumer of .bdic
>> dictionaries, how about putting them in /usr/share/bdic, and then
>> either patching sources to use that dir or linking
On 9/3/19 4:47 AM, David Runge wrote:
> Not that it is of our direct concern, but qt5-webengine seems to suffer
> from unresolved questionable licensing issues, which is why e.g.
> Parabola doesn't package it [1]. I don't know the specifics, but assume,
> that it is due to the Chromium license [2].
On 11/10/19 9:54 PM, Sébastien Luttringer via arch-dev-public wrote:
> Nice to see that moving forward. It is a smart to move pacman installed kernel
> out of /boot.
> Why do you rely on mkinitcpio (or later dracut) to install them in /boot
> instead of the systemd kernel-install logic?
As I said
On 11/12/19 1:24 PM, Sébastien Luttringer wrote:
> On Mon, 2019-11-11 at 15:41 -0500, Eli Schwartz via arch-dev-public wrote:
>> On 11/10/19 9:54 PM, Sébastien Luttringer via arch-dev-public wrote:
>> As I said above, the documentation for kernel-install is pretty clear on
>&g
On 11/14/19 12:21 PM, Robin Broda via arch-dev-public wrote:
> On 11/13/19 3:46 AM, Allan McRae via arch-dev-public wrote:
>> To keep this momentum going, it would be great to rebuild every package
>> in [core] using makepkg from pacman-5.2+. That way we can test which
>> packages are actually rep
On 11/18/19 1:34 AM, Sven-Hendrik Haase via arch-devops wrote:
> Hi all,
>
> I set up a new Hetzner VPS that is going to become our new
> homedir/public_html server available to all TUs and Devs like soyuz was. We
> decided to decommission soyuz and put the public_html stuff on its own
> server fo
On 12/8/19 7:39 AM, Robin Broda via arch-dev-public wrote:
> Hello everyone,
>
> Now that Zstd 1.4.4 has been out, and released into our repos as well, i
> think it's time for a new status report on this.
>
> I re-ran the benchmarks with the new zstd, and we are hitting marginally
> better time
On 12/12/19 7:21 AM, Christian Rebischke via arch-dev-public wrote:
> 5. What do we do with the existing beta and alpha packages? Are they
> granted asylum? Or do we remove them, to be consistent?
>
> extra libmspack 1:0.10.1alpha-2
> extra qt5-webkit 5.212.0alpha3-6
qt5-webkit is a security-cri
On 12/14/19 1:58 PM, Robin Broda via arch-dev-public wrote:
> Hello again,
>
> We are on our way to getting zstd merged.
>
> The planned merge window for this is **2019/12/27** at around 20:00
> Europe/Berlin time.
> Several team members will be meeting at the 36c3, so we figured this is a
> go
On 12/19/19 6:05 PM, Allan McRae via arch-dev-public wrote:
>> There's no package replacing libdmx and libxxf86dga so manual
>> intervention will be needed. So here's a small news draft:
>>
>> "Xorg cleanup requires manual intervention
>>
>> "In the process of Xorg cleanup [1] the update requires m
On 12/21/19 3:41 AM, Andreas Radke via arch-dev-public wrote:
> With this move I've "fixed" libx11 no more depending at runtime on
> xorgproto package. I think no headers belong to an end user system and
> the libx11 library itself doesn't depend on it. But we also ship
> libx11-devel part inside t
On 1/2/20 11:12 AM, Jelle van der Waa wrote:
> # Remove python2 support
>
> * pycharm-community-edition - remove python2 support
Seems reasonable to not encourage people to use python2 in an IDE these
days.
> * vim - remove python2 support
Are there any stats on vim ecosystem plugins which use
On 1/2/20 7:19 PM, keenerd via arch-dev-public wrote:
> On 1/2/20, Jelle van der Waa wrote:
>> * rox - python2, dead and GTK2
>
> Also was an easy fix. Well, the python2 part at least.
>
> -Kyle
https://bugs.archlinux.org/task/65023
There are a couple of forks apparently, which might be worth
After a bit of research work and making sure one or two things have been
properly packaged, I've developed a PKGBUILD which ensures that a system
has the POSIX shell and utilities (XCU) section installed. I believe
this is an interesting thing to track, and people will want to know they
have it ins
On 1/3/20 10:22 AM, Santiago Torres-Arias via arch-dev-public wrote:
> On Fri, Jan 03, 2020 at 03:49:11PM +0100, Robin Broda via arch-dev-public
> wrote:
>> On 1/3/20 5:35 AM, Eli Schwartz via arch-dev-public wrote:
>>> After a bit of research work and making sure one or
On 1/3/20 10:48 AM, Sébastien Luttringer wrote:
>
> On Thu, 2020-01-02 at 23:35 -0500, Eli Schwartz via arch-dev-public wrote:
>> ...
>>
>> Thoughts?
>
> Posix is an old standard which fail to make a common ground to Unix systems.
>
> If we think user needs
On 1/3/20 9:47 PM, Sébastien Luttringer wrote:
>> I would argue that POSIX is a standard which people actually care about,
>> and LSB is a standard which no one cares about.
>
> I agree that few people are interested in LSB. I think it's barely the same
> for
> POSIX.
>
> Our scripts are not wri
On 1/2/20 11:35 PM, Eli Schwartz wrote:
> After a bit of research work and making sure one or two things have been
> properly packaged, I've developed a PKGBUILD which ensures that a system
> has the POSIX shell and utilities (XCU) section installed. I believe
> this is an interesting thing to trac
On 1/11/20 4:51 PM, Jelle van der Waa wrote:
> Some languages however require special treatment such as Haskell and
> require rebuilds from GHC => Haskell-foo => Haskell-bar etc which can
> become complicated. For example if I want to update a dependency of
> taskell I will have to rebuild all dep
On 1/10/20 4:42 PM, Christian Rebischke via arch-dev-public wrote:
> Hi everybody,
>
> I would like to propose that we create todos for rebuilds of language
> specific packages.
>
> We had two major rebuilds in the last months: python3.8 and ruby2.7.
>
> Can we agree that we create a todo before
On 1/13/20 11:23 AM, Christian Hesse wrote:
> Hello everybody,
>
> to date we ship rsync with bundled zlib to keep compatibility with rsync
> up to version 3.1.0 and it's old-style --compress option. This is no longer
> required with rsync 3.1.1, which was released on 2014-06-22 - nearly six
> yea
Due to a family wedding, I will be gone for a week, until late Monday
Feb. 3 or Tuesday Feb. 4. I won't have internet other than limited
mobile data, but can still be contacted via email/IRC, which I shall
check semi-regularly. Sorry for the late notice. :)
Feel free to update anything that needs
On 2/16/20 7:47 PM, Gaetan Bisson via arch-dev-public wrote:
> Dear all,
>
> I'd like to post the following news item within the hour.
>
>
>
> Title: sshd needs restarting after upgrading to openssh-8.2p1
>
> Conent: After upgrading to openssh-8.2p1, the existing SSH daemon will
>
On 2/16/20 7:47 PM, Gaetan Bisson via arch-dev-public wrote:
> And I also regret not being able to diagnose what the exact problem is
> just now.
As was pointed out in the bug:
https://bugs.archlinux.org/task/65517#comment186483
ssh errors with:
kex_exchange_identification: read: Connection reset
On 2/16/20 7:54 PM, Gaetan Bisson wrote:
>> Is it sufficient to add a post_upgrade message?
>
> Probably, yes but then we'd need a new package out of [testing] fast.
> And users might complain that the post_upgrade message wasn't visible
> enough... :)
We could even try to detect a running sshd.s
On 2/16/20 8:11 PM, Gaetan Bisson wrote:
> [2020-02-16 20:03:16 -0500] Eli Schwartz via arch-dev-public:
>> It's pretty plausible that this commit is simply incompatible with the
>> previous version of sshd, therefore it could not reexec:
>> https://github.com/opens
On 2/24/20 10:36 AM, Brett Cornwall via arch-dev-public wrote:
> On 2020-02-13 02:24, David C. Rankin wrote:
>> And with the note that much of Howard Hinnant's date/time library is
>> being
>> incorporated into the next C++ standard. Quite a feather in anyone's cap.
>
>
> Does anyone have any str
On 3/15/20 4:40 PM, Morten Linderud via arch-dev-public wrote:
> I'm aware that go {list,build,test} fetches dependencies on the fly.
>
> And let me reiterate again; *This shouldn't happen*.
>
> We should be capable of performing complete software builds without internet
> connection. If we can'
On 3/13/20 6:33 AM, Jan de Groot wrote:
> Balló György via arch-dev-public schreef op 2020-03-13 10:56:
>> Hi all,
>>
>> I would propose to remove PyGTK from the official repositories. PyGTK
>> was used to create GTK2 applications in python2. It's deprecated and
>> unmaintained since 2011 in favor
On 3/29/20 11:25 AM, Filipe Laíns via arch-dev-public wrote:
> I want to clarify what I am proposing.
>
> I would not be an entirely new architecture in the sense of i686, CPU
> extensions are not different architectures and shouldn't be treated as
> such.
>
> What I would for us to do is to crea
On 3/30/20 6:35 AM, Chih-Hsuan Yen via arch-dev-public wrote:
> On Mon, Mar 30, 2020 at 01:26:11AM +0200, Frederik Schwan via arch-dev-public
> wrote:
>> We received a Feature Request today to remove fontconfig and
>> xorg-mkfontscale dependencies from our font packages according to our own
>> f
I've been only sporadically available the last few days, as some people
may have noticed, and I will be mostly inaccessible until after
Passover[1] / the 19th. It's been very hectic here recently, and ugh, it
is so frustrating to get ready for a major holiday in the middle of a
pandemic. :( We have
On 4/30/20 3:56 AM, Anatol Pomozov via arch-dev-public wrote:
> Thank you for coming up with this document.
>
> Go is a fantastic language and I would love to see more people using
> it. Having things documented will help our users to get more
> comfortable with the golang packaging.
This RFC is
On 5/13/20 4:16 PM, Morten Linderud via arch-dev-public wrote:
> The complete future Go PKGBUILD is attached to this email below.
```
replaces=(go-pie)
provides=(go-pie)
```
Should this provide it too? Anything that explicitly expected go-pie
cannot assume the new package is a drop-in replacemen
On 5/17/20 4:37 PM, Lukas Fleischer via arch-dev-public wrote:
> Email addresses of aurweb accounts have to be confirmed (and accounts
> without verified email addresses are not usable and can be filtered out
> by a simple SQL query). Old accounts have been purged in ~2014 and, to
> the best of my
On 5/17/20 7:22 PM, Sven-Hendrik Haase via arch-dev-public wrote:
>> On a related note, will this impact projects that prefer email patch
>> submissions in any way (except that they can now opt-in to GitLab too)?
>>
>
> Yes and no: The current idea is to stop operating patchwork, the current
> pri
On 6/2/20 3:35 PM, Ike Devolder via arch-dev-public wrote:
> On Thu, May 28, 2020 at 10:05:58AM +0200, Antonio Rojas via arch-dev-public
> wrote:
>> El jueves, 28 de mayo de 2020 10:01:23 (CEST), Ike Devolder via
>> arch-dev-public escribió:
>>> I have segfaults with multiple programs (keepassxc,
On 6/5/20 9:04 AM, Filipe Laíns via arch-dev-public wrote:
> My main concern here is that it is not as simple as it just being
> Kyle's decision, it sets a precedent. I believe the naming is
> incorrect, and as such, should be fixed. I have tried initiating a
> conversation with the maintainer but
On 3/31/20 12:36 PM, Eli Schwartz wrote:
> On 3/30/20 6:35 AM, Chih-Hsuan Yen via arch-dev-public wrote:
>> On Mon, Mar 30, 2020 at 01:26:11AM +0200, Frederik Schwan via
>> arch-dev-public wrote:
>>> We received a Feature Request today to remove fontconfig and
>>> xorg-mkfontscale dependencies fr
On 6/25/20 11:29 PM, Chih-Hsuan Yen via arch-dev-public wrote:
> On Thu, Jun 25, 2020 at 05:53:28PM -0400, Eli Schwartz via arch-dev-public
> wrote:
>> On 3/31/20 12:36 PM, Eli Schwartz wrote:
>>> On 3/30/20 6:35 AM, Chih-Hsuan Yen via arch-dev-public wrote:
>>>&
On 6/26/20 2:39 AM, Andreas Radke via arch-dev-public wrote:
> We have to choose if we want simple
>
> makedepends=('xorg-font-utils') or
> makedepends=('xorg-mkfontscale' 'xorg-bdftopcf' 'xorg-font-util')
>
> Sure we can drop the meta package "xorg-font-utils" entirely but it
> simply covers al
On 7/8/20 11:05 PM, Anatol Pomozov via arch-dev-public wrote:
> TLDR; let’s start using detached package signatures to make system
> updates faster.
That all sounds great, but it's really down to how repo-add does its
thing. So maybe this belongs on pacman-dev?
--
Eli Schwartz
Bug Wrangler and Tr
On 7/10/20 2:38 PM, Jan Alexander Steffens (heftig) via arch-dev-public
wrote:
> From: "Jan Alexander Steffens (heftig)"
>
> Most people create packages from the AUR for local installation. This
> allows these packages to be created more quickly.
This doesn't switch to .zst (we already set this
On 7/10/20 2:38 PM, Jan Alexander Steffens (heftig) via arch-dev-public
wrote:
> From: "Jan Alexander Steffens (heftig)"
>
> I recently read [Fedora's documentation on build flags][1] and I think
> they have some useful ideas.
>
> 1. Move -D_FORTIFY_SOURCE=2 from CPPFLAGS to CFLAGS using -Wp:
>
On 7/24/20 3:24 PM, Giancarlo Razzolini via arch-dev-public wrote:
> Em julho 23, 2020 17:09 Giancarlo Razzolini via aur-general escreveu:
>> Hi All,
>>
>> In continuing with the improvements being done to our infrastructure,
>> we're
>> planning to migrate the AUR to another machine. This means th
On 7/27/20 8:03 PM, Gaetan Bisson via arch-dev-public wrote:
> [2020-07-25 00:18:55 +0200] Baptiste Jonglez:
>> On 24-07-20, Giancarlo Razzolini via arch-dev-public wrote:
>>> The migration is almost done. Since we are moving to a new machine, it will
>>> have new host keys. They are:
>>>
>>>Ed
1 - 100 of 113 matches
Mail list logo
