Re: [arch-general] postgres 12

[Levente Polyak via arch-general]

Checking the bug tracker should be the first spot to look for an answer

https://bugs.archlinux.org/task/68601

Local files got mixed after the test build as the tree contained a rebuild 
bump. Just wait for -3 hitting the repos and upgrade to it.

Cheers

Re: [arch-general] Update to Boost Libraries

[Levente Polyak via arch-general]

On October 7, 2020 11:58:52 PM GMT+02:00, karx via arch-general 
 wrote:
>On Wed, Oct 7, 2020 at 3:05 PM Jayesh Badwaik via arch-general <
>arch-general@archlinux.org> wrote:
>How long has the updated version been available? If it was just
>released
>then it will take some time for it to get packaged. If it has been a
>while,
>you can flag the package out of date through the web interface.
>

Nah unfortunately it has been for a while. I'm
very much involved in other time consuming
parts lately and hence trying to find a new
maintainer that coordinates the massive
rebuilds and patches required on each bump.
However so far I was unlucky after third time of
asking on irc.
I will bump this on our ML and hopefully finally
find someone motivated and having time for this task.

Re: [arch-general] usbguard package neglected

[Levente Polyak via arch-general]

On 6/24/20 11:37 PM, arch user via arch-general wrote:
> Hello,
> 
> the package usbguard was flagged out of date in november. Three new
> versions came out since then. A package update or any info on this would
> be greatly appreciated.
> 
> Kind regards
> 

The trust chain is broken as the signing key changed and after multiple
back and forth I still did not get a signed confirmation of the old key
regarding the new maintainers and keys.

I will try to re ping them with w 5th mail, lets see if we have more
luck now.

cheers,
Levente



signature.asc
Description: OpenPGP digital signature

Re: [arch-general] A few out of date packages

[Levente Polyak via arch-general]

On 2/12/20 12:58 AM, Genes Lists via arch-general wrote:
> I've selected a few to highlight based on age and my own view of
> importance (no claim its a good view).
> 
> So, here's a few that might benefit from an update:
>Cal Pkg
> NameVers Updt   Flag   CVers   DateAge Age Pkger
> ---  -- -- --- --  --- -
> thunderbird 68.4.2   200126 200211 68.5.0  200210  16  15 LP
> bash5.0.011  191118 200208 5.0.016 200207  85  81 EF
> fail2ban0.10.5   200112 200112 0.11.1  200111  30  -1 FY
> ipset   7.4  191202 200109 7.5 200109  71  38 SL
> samba   4.10.10  191114 191101 4.11.6  200128  89  75 TP
> smbclient   4.10.10  191114 191101 4.11.6  200128  89  75 TP
> ebtables2.0.10_4 181113 191203 2.0.11  190212 455 384 EF
> biber   1:2.13   191101 191202 2.14191201 102  30 RO
> diffstat1.62 190106 191130 1.63191129 401 327 AW
> libelf  0.177191118 191128 0.178   191126  85   8 EF
> elfutils0.177191118 191128 0.178   191126  85   8 EF
> refind-efi  0.11.3   180723 181119 0.11.4  191112 568 112 TP [1]
> 
> [1] 0.11.5 looks to be coming out soon
> 
>   Cal Age = days since last update
>   Pkg Age = days between current and arch release
>   Cvers = Current version
> 

Hi gene,

thanks for taking time and trying to improve something in our distro,
however I believe your numbers are, lets say: suboptimal

You are listing a cal age, which just doesn't say anything as it doesn't
matter how long ago the last update was if the upstream release cycle is
like that.

On top you list Pkg Age as the delta between the latest upstream release
and the last packaging date of the current version in the repos. This
metric again says nothing important.

You are collecting the wrong metrics, what is interesting is "today
minus upstream release date" to get the delta how long a package version
in the repo is not the latest available one. Maybe a second row for how
many days passed since it has been flagged, but the above age is just
nothing useful to take into account.

Actually what does thunderbird even do on this list? I guess because its
"Age" is 15? Which exactly proves my point above:
Version 68.5.0, first offered to channel users on February 11, 2020
which was exactly 1 day ago.

On top this data set is inconsistent, thunderbird was released 200211
and not as listed 200210 plus refind-efi was not released 191112 but
181112 and I didn't even check any other numbers besides those two.

cheers,
Levente

https://sourceforge.net/projects/refind/files/0.11.4/
https://www.thunderbird.net/en-US/thunderbird/68.5.0/releasenotes/



signature.asc
Description: OpenPGP digital signature

Re: [arch-general] Pacman Database Signatures

[Levente Polyak via arch-general]

On 2/2/20 10:59 PM, Christopher W. via arch-general wrote:
> Hi. The wiki states that database signatures for pacman are currently
> a work in progress. It's been that way for a long time, so I assume
> there is no "progress" happening. What is currently in the way of this
> much-needed security feature to be fully implemented?
> 
> Right now, pacman is taking untrusted input from the internet as root.
> That's very bad. Most of the comments I've seen say that an attacker
> could hold back vulnerable packages, but this is assuming the attacker
> does not have bigger plans. The pacman tool is not immune to bugs in
> the way it parses the database files. It has no privilege separation
> in the download/parsing code as far as I can see (apt and others have
> had this for a long time) so it's really an even more dire situation.
> Pacman should not perform any operations as root until it has verified
> the signature of all files being used to install/upgrade the packages,
> but it currently does everything (downloading, verifying, etc) as root.
> 
> I'd like to get a discussion going about how and when these two issues
> could be resolved so that all Arch users can be safer. Thanks.
> 

Hi,

it was indeed stalled for quite a long time without real progress. The
reason has been that some packagers refused to sign the database file
with their own key for various reasons.
The good news is, it is being worked on lately. Right now we are
figuring out some flows and models how we want to do that, like
smartcards or TPM and how to set that up and maintain it. In fact we
have been working on that today and during the whole weekend at FOSDEM,
so things are moving and we will get there :)

However, this doesn't mean it will instantly become bullet proof.
Software and security is far more complex than that and also APT and
friends are not an unbreakable software even when having signed
databases/indicies:

APT CVE-2019-3462
Incorrect sanitation of the 302 redirect field in HTTP transport method
of apt versions 1.4.8 and earlier can lead to content injection by a
MITM attacker, potentially leading to remote code execution on the
target machine.

In case of pacman, signed databases would have protected against
CVE-2019-18183 and CVE-2019-18182 but not against:
https://security.archlinux.org/CVE-2019-9686 leading to arbitrary code
execution when using -U on a remote target.

Before drifting to much away and philosophizing about privilege
separation and dropping privileges for certain tasks, lets get back to
the main question/topic here: Right now there isn't much discussion
needed, a team is actively working on exactly that topic and will
present their considerations, implementations and results to A-D-P for
some feedback rounds before potentially going live.

cheers,
Levente



signature.asc
Description: OpenPGP digital signature

Re: [arch-general] Does Arch Linux support containers, dockers and Kubernetes?

[Levente Polyak via arch-general]

On 10/1/19 12:58 AM, Turritopsis Dohrnii Teo En Ming via arch-general wrote:
> Noted with thanks.
> 
> [...]

@Turritopsis Dohrnii Teo En Ming
@José Vilmar Estácio de Souza

Please do not top-post. On all Arch mailing lists we have a bottom-post
policy for replies (it also makes reading posts more natural). :-)

Thanks in advance,
Levente



signature.asc
Description: OpenPGP digital signature

Re: [arch-general] CVE-2019-11477 (/proc/sys/net/ipv4/tcp_sack)

[Levente Polyak via arch-general]

On 6/21/19 8:25 AM, David C. Rankin wrote:
> After 5.12.1 is there any further mitigation needed for:
> 
> 
> https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-11477
> 
> related:
> 
> https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-11478
> https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-11479
> 
>   Suggested work-around:
> 
> echo 0 > /proc/sys/net/ipv4/tcp_sack
> 
>   or
> 
> iptables -A INPUT -p tcp -m tcpmss --mss 1:500 -j DROP
> 
> Are either needed after latest kernel, or is this resolved?
> 

I guess you mean 5.1.12 as long as you are not a visitor from the future.

5.1.11 was the upstream fix version for the SACK issues, you can use our
Arch Linux specific security tracker to get this information:


https://security.archlinux.org/CVE-2019-11477
https://security.archlinux.org/CVE-2019-11478
https://security.archlinux.org/CVE-2019-11479

which lists all affected and fixed variants/versions.

there have been advisories published on the tracker and via our sec
announcements ML.


So as long as you are running latest kernels, no other mitigation is needed.

cheers,
Levente



signature.asc
Description: OpenPGP digital signature

Re: [arch-general] Is it secure to just sign repository databases?

[Levente Polyak via arch-general]

On June 16, 2019 5:57:34 PM GMT+02:00, Eli Schwartz via arch-general 
 wrote:
>That being said, if you have signed the repository db then as you
>mentioned the sha256 checksums for the package file are securely
>signed,
>so you are guaranteed that use of pacman -S pkgname will securely
>verify
>that it is installing the package the repo-add user expected to provide
>when running repo-add.
>
>What is your threat model? These things will not be protected against:
>
>- people installing the package file directly, as such:
>  pacman -U https://example.com/foopkg-1-1-x86_64.pkg.tar.xz
>- An attacker with local filesystem access on the signing/hosting
>server
>  can retroactively replace *all* packages built at any date, and trick
>  you into signing a new repo DB referencing them.
>- In shared packaging situations, like when a team of dozens of people
>  all upload packages, you want to be able to verify who signed each
>  package, as opposed to only verifying that the last person to update
> the repository asserted that all other packages are good and backed by
>  his/her good name -- this does not concern you.


An important side note: This will only really help
if users of the repo have set the repository SigLevel
to Required (which is not the default).
When using the default of Optional a MitM
attacker can just drop signatures for that database,
which obviously is much much much easier to
achieve for non https mirrors.

Cheers,
Levente

Re: [arch-general] steam-native can't find libpcre.so.3, breaks embedded browser

[Levente Polyak via arch-general]

On April 4, 2019 7:11:07 PM GMT+02:00, Maarten de Vries via arch-general 
 wrote:
>A better fix is mentioned on the steam forum [1] by a WorMzy:
>> $ export
>LD_PRELOAD="/usr/lib/libgio-2.0.so.0:/usr/lib/libglib-2.0.so.0"
>> $ steam-native
>
>Apparently those libraries still come from the steam distribution,
>even with steam-native, and those pull in libpcre.so.3 and
>libselinux.so.1. Preloading the system versions avoids that.
>
>[1]
>https://steamcommunity.com/groups/SteamClientBeta/discussions/0/1848072002764995823/#c1769259642875894556
>


That looks a lot more appropriate as a fix,
however please keep the discussion and
information flow at a single place and further
responses should be made in the bug ticket.

We will provide a fix soon, but should first dive
into why those libs were used in the first place.

Thanks for the useful information. 

Cheers,
Levente

Re: [arch-general] BrlTTY Hard Dependency on eSpeak

[Levente Polyak via arch-general]

As already stated, may you just wait until it's rules out, problems with other 
packages fixed, rebuild and replaced? Thanks

Re: [arch-general] BrlTTY Hard Dependancy on eSpeak

[Levente Polyak via arch-general]

On February 14, 2019 12:17:02 AM GMT+01:00, "brent s."  
wrote:
>On 2/13/19 5:18 PM, Doug Newgard via arch-general wrote:
>> On Wed, 13 Feb 2019 15:25:19 -0500
>> "brent s."  wrote:
>> 
>>> On 2/13/19 3:16 PM, Storm Dragon via arch-general wrote:
 Hi,

 I'm having some issues with installing brltty. The problem is, it
 depends on espeak but I'm using the espeak-ng from community and it
>is
 giving me the unresolvable conflicts problem for that reason.

 I don't think that brltty actually needs espeak at all, and it
>could
 probably be listed as an optional dependancy along with espeak-ng.

 Thanks,
 Storm  
>>>
>>> hopefully polyzen is on this list.
>>>
>>> polyzen-
>>>
>>> any reason why you couldn't add espeak to espeak-ng's provides?
>seems
>>> like it's mostly compatible, at least from the interface and lib
>level:
>>>
>>> https://github.com/espeak-ng/espeak-ng#espeak-compatibility
>>>
>> 
>> Libs are different, so it's not a drop-in replacement. Provides would
>be
>> incorrect.
>> 
>
>really?
>
>the section i linked to claims this:
>
>"The espeak speak_lib.h include file is located in
>espeak-ng/speak_lib.h
>*with an optional symlink in espeak/speak_lib.h*. This file *contains
>the espeak 1.48.15 API*, with a change to the ESPEAK_API macro to fix
>building on Windows and some minor changes to the documentation
>comments. *This C API is API and ABI compatible with espeak.*"
>(emphasis
>added)
>
>granted, we have espeak 1.48.04 in [community], but 1.48.15's been
>development status since 2015[0]. i have a hard time imagining that
>1.48.04's API and ABI have had breaking changes on what seems to be a
>single patch level release, and one four years old at that.
>
>
>
>[0] http://espeak.sourceforge.net/test/latest.html

Then I'm sorry to tell you that's indeed the case.
Look at espeak package history, the epoch is
there for a reason. It was tried to be a drop in
replacement before and had to be reverted.

I still have plans to transform espeak back to the
NG variant, but that needs a bit of time, staging
and planning. For time being you need to accept
it doesn't work that easily.

Re: [arch-general] How to have multiple JDKs parallel?

[Levente Polyak via arch-general]

On 9/17/18 6:27 PM, Doug Newgard via arch-general wrote:
> 
> Going forward with the new release policies, would it be better to just have 
> an
> openjdk/openjre package that's always the latest version, then versioned
> packages for the lts releases, such as they are?
> 

This is exactly what will happen when java-11 is released, a generic
named java package will replace java-10.

Don't think there will be LTS releases anymore, but we will have
versioned variants whenever some breaking changes require a specific jre
for an application in our repositories.

cheers,
Levente



signature.asc
Description: OpenPGP digital signature

Re: [arch-general] AppArmor support

[Levente Polyak via arch-general]

On 9/10/18 7:31 PM, Geo Kozey wrote:
>> 
>> From: Levente Polyak 
>> Sent: Mon Sep 10 18:42:14 CEST 2018
>> To: Geo Kozey 
>> Cc: General Discussion about Arch Linux 
>> Subject: Re: [arch-general] AppArmor support
>>
>> I think you are totally missing the point, everyone can happily debug,
>> bisect and get proper crash information. The problem is reporting
>> upstream, which won't be accepted if you use anything but a vanilla
>> kernel (which hardened isn't as it provides custom patches).
>>
>> If you want to approach upstream then reproducing the same thing on the
>> vanilla kernel is the only option you have, otherwise it will be rejected.
>>
>> cheers,
>> Levente
>>
> 
> Nope. Not everyone can happily debug and bisect if every bug causes panic
> and forced reboot of their machine.
> 
> As a person who reported dozen of bugs (mostly upstream specific but some
> of them can be found only with linux-hardened - all of them fixed) and who
> tests every rc kernel with linux-hardened patch and several others patches on
> top of it, I can tell you that none valid report will be rejected. Of course 
> I don't
> report issues with linux-hardened patch itself upstream.
> 
> I have to admit that if I haven't disabled myself CONFIG_PANIC_ON_OOPS I
> would give up long time ago.
> 

Sure, and thanks for doing so! Fair enough, at least if you are
bisecting/debugging... but then you are recompiling multiple times
anyway and nobody wants to and nothing stops you from keeping
CONFIG_PANIC_ON_OOPS off while doing so.

However, that's not the average use case and that doesn't mean it must
be off for everyone, it will remain  "better safe then sorry" by default
for the reasons i pointed out.

cheers,
Levente



signature.asc
Description: OpenPGP digital signature

Re: [arch-general] AppArmor support

[Levente Polyak via arch-general]

On 9/10/18 5:58 PM, Geo Kozey wrote:
> I think you may consider disabling CONFIG_PANIC_ON_OOPS in linux-hardened
> default config. Preventing users from being able to debug and report their
> issues upstream or even discouraging them from using linux-hardend at all is
> quite a big cost of it. Asking users to recompile their kernels every time 
> they want
> to investigate their issues is also a little too much.
> 
> There is "oops=panic" cmdline which everyone can use and which is much more
> flexible to switch between debug/non-debug mode than recompiling. I don't 
> think
> adding something to cmdline is beyond capabilities of Arch users, especially 
> if
> they're interested in security. 
> 
> Yours sincerely
> 
> G. K.
> 


I think you are totally missing the point, everyone can happily debug,
bisect and get proper crash information. The problem is reporting
upstream, which won't be accepted if you use anything but a vanilla
kernel (which hardened isn't as it provides custom patches).

If you want to approach upstream then reproducing the same thing on the
vanilla kernel is the only option you have, otherwise it will be rejected.

cheers,
Levente



signature.asc
Description: OpenPGP digital signature

Re: [arch-general] AppArmor support

[Levente Polyak via arch-general]

On 9/10/18 1:43 PM, Carsten Mattner wrote:
> On 9/10/18, Levente Polyak via arch-general  
> wrote:
>> Just a crazy idea but how about contributing back instead of just
>> complaining? People on the bug tracker always help guiding how to report
>> upstream or finding relevant commits. Yeah, i know it takes a while to
>> compile, but it's not that complicated:
>> - take a look at the panic in hardened
>> - peek the code around it to find out which of the protective config
>>   values may have triggered it (if not already obvious from the panic)
>> - reproduce on stock/vanilla kernel by building it including the
>>   responsible configs
>> - report upstream using the gathered information of the vanilla kernel
>> - bonus points for git bisecting the commit that broke it
>>
>> This would not only contribute to make hardened run on your or similar
>> setups, all vanilla linux users would benefit by helping to fix a bug
>> that can or does result in a corruption.
> 
> I did and do. I have open bugs in freedesktop and kernel bugzilla which
> are not resolved and in NEW state for months and years. These are usually
> regressions in drivers due to the Linux driver packaging model and
> insufficient testing on supported hardware configurations. What happens
> is that a driver that works flawlessly on hardware rev-1.8 suddenly starts
> misbehaving with a newer kernel that has seen improvements, refactorings,
> and support for newer hardware. It's most prominent in the graphics stack,
> which is complex, hard to test, and easy to break. I don't blame the
> developers for having a hard time, I'm discouraged stable drivers for
> old hardware get regressions and stop being tested as well as hardware
> of years -2/+2 years.
> 
> Therefore, I hope you don't mind if my frustration level with the issues
> I'm tracking right now is high enough that I'm not in the mood to debug
> and track issues I can avoid by using a different stable kernel branch.
> 

Nice to hear that you do or at least did, bear with me for
overgeneralizing in in your case.

However, the point of my whole response was that you are most
definitively triggering/encountering the very same bug on the stock
kernel, stock variant just tries to go ahead instead of panic, which
means it may result in corruption and possibly killing kittens. Whatever
is encountered there is at least a "regular regression" and possibly
could provide surface for exploitation.

If you are not using linux-lts you are pretty much using the very same
stable branch/tag in linux-hardened that vanilla linux uses so there is
no "different stable kernel branch". If former is the case you can
pretty much blame vanilla linux package to an equal amount as the
hardened variant for being buggy.

cheers,
Levente



signature.asc
Description: OpenPGP digital signature

Re: [arch-general] AppArmor support

[Levente Polyak via arch-general]

On 9/9/18 10:26 PM, Carsten Mattner via arch-general wrote:
> On 9/9/18, Gus  wrote:
>> Linux-hardened doesn't support hibernation and i think it's overkill to
>> use it on desktop.
> 
> Not arguing in anyway for or against AppArmor, just another
> data point regarding linux-hardened 4.17 and 4.18:
> 
> I tried linux-hardened on two Intel machines, and it was less stable
> than "linux". Some of the changes are probably invasive/destabilising,
> which makes sense seeing how slowly and carefully the mitigations are
> traveling via Kees Cook into Linus' tree. I didn't have stability
> issues with the old linux-grsec packages, though to be fair those
> were also way older major releases which may matter.
> 

It is quite definitively equally stable as vanilla linux is, there is no
crazy overly invasive stuff in hardened that would justify claiming
otherwise.

What you most likely encountered, like literally all other "instability"
issues so far, is that with your setup you triggered a stock vanilla
linux bug with the difference that hardened immediately shuts itself
down for security reasons. These bugs are corruption and integrity
related and shutting down follows "better safe then sorry" for the
hardened variant.
There are various kernel configs doing so, to name some:
CONFIG_BUG_ON_DATA_CORRUPTION, CONFIG_DEBUG_LIST, CONFIG_DEBUG_SG and
lots more including slab sanitizing/verifying specifically in
combination with CONFIG_PANIC_ON_OOPS.

Just a crazy idea but how about contributing back instead of just
complaining? People on the bug tracker always help guiding how to report
upstream or finding relevant commits. Yeah, i know it takes a while to
compile, but it's not that complicated:
- take a look at the panic in hardened
- peek the code around it to find out which of the protective config
  values may have triggered it (if not already obvious from the panic)
- reproduce on stock/vanilla kernel by building it including the
  responsible configs
- report upstream using the gathered information of the vanilla kernel
- bonus points for git bisecting the commit that broke it

This would not only contribute to make hardened run on your or similar
setups, all vanilla linux users would benefit by helping to fix a bug
that can or does result in a corruption.

cheers,
Levente



signature.asc
Description: OpenPGP digital signature

Re: [arch-general] Unresponsive maintainer

[Levente Polyak via arch-general]

On July 30, 2018 5:14:56 PM GMT+02:00, "данила кивер via arch-general" 
 wrote:
>
>I want one of his packages (
>https://www.archlinux.org/packages/extra/x86_64/visualvm ) to be
>updated because an important bug was fixed  in the upstream (I've
>already built this package, installed  and tested locally with the
>newest upstream software version). What is the correct way to handle
>this situation?
>


We had a chat recently as he currently lacks the amount of
time he had before, so we discussed I jump in and help with
the Java things.
I gonna take a look at visualvm as well, if you have important changes
other then just bumping please send me your version.

Cheers,
Levente

Re: [arch-general] Kernel modules not loaded after Linux update

[Levente Polyak via arch-general]

On 07/23/2018 10:43 AM, Ralf Mardorf wrote:
> [1]
> 4.17.8 still in Core allegedly also contains it.
> 
> $ grep pkg.e.= linux/repos/core-x86_64/PKGBUILD
> pkgver=4.17.8
> pkgrel=1
> $ grep SALSA linux/repos/core-x86_64/config 
> CONFIG_CRYPTO_SALSA20=m
> CONFIG_CRYPTO_SALSA20_X86_64=m
> 
> I uninstalled
> 
> $ uname -a
> Linux archlinux 4.17.9-1-ARCH #1 SMP PREEMPT Sun Jul 22 20:23:36 UTC 2018 
> x86_64 GNU/Linux
> 
> from Staging and removed it from the cache and then installed it from
> Testing and rebooted.
> 
> It remains
> 
> $ uname -a
> Linux archlinux 4.17.9-1-ARCH #1 SMP PREEMPT Sun Jul 22 20:23:36 UTC 2018 
> x86_64 GNU/Linux
> $ zgrep SALSA /proc/config.gz
> CONFIG_CRYPTO_SALSA20=m
> $ grep SALSA /lib/modules/4.17.9-1-ARCH/build/.config
> CONFIG_CRYPTO_SALSA20=m
> 
> so it differs from config provided by the asp checkout
> 
> grep SALSA linux/repos/testing-x86_64/config 
> CONFIG_CRYPTO_SALSA20=m
> CONFIG_CRYPTO_SALSA20_X86_64=m
> 
> FWIW
> 
> $ grep SALSA linux/repos/core-i686/config.i686 
> CONFIG_CRYPTO_SALSA20=m
> CONFIG_CRYPTO_SALSA20_586=m
> 

No, it won't come back. The reason for the mismatch is that the config
in the checkout is not regularly updated/synced for every minor kernel
bump and removed options will remain there while the effective config at
the end (which you can observe via config.gz) of cause won't have it.

CRYPTO_SALSA20_X86_64 was removed in 4.17.7

https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=49c8ef6d52ed6dacbca5a731ebe253bfb44e0ea9



signature.asc
Description: OpenPGP digital signature

Re: [arch-general] valgrind 3.13.0-6 exclusions broken again

[Levente Polyak via arch-general]

On April 7, 2018 6:18:39 AM GMT+02:00, "David C. Rankin" 
 wrote:
>On 04/01/2018 07:43 PM, David C. Rankin wrote:
>> 
>> 
>> I was looking for confirmation of the bug and whether the devs want
>it
>> filed here to track or to not waste time filing with Arch and just
>file
>> upstream?
>> 
>
>I suspect this is a gcc-libs/valgrind issue, I updated
>https://bugs.archlinux.org/task/49681 with the information.


Please bring this issue upstream, where it could actually be fixed.

Cheers, 
Levente 

Re: [arch-general] OpenRA / Mono exceptions

[Levente Polyak via arch-general]

On March 2, 2018 12:38:33 PM GMT+01:00, Dan Haworth  wrote:
>On 02/03/18 11:17, Alajos Odoyle wrote:
>> On 2018-03-02 11:38, Dan Haworth wrote:
>>>
>>> I had the same issue, seems to be related to the following bug 
>>> https://github.com/mono/mono/issues/6752. I downgraded ncurses to
>6.0 
>>> to get things going again.
>>>
>>> --dan
>>
>> Thanks, that was quick! I also had to install libtinfo5 (AUR) and 
>> symlink /usr/lib/libtinfo.so.5 to /usr/lib/libtinfo.so.6 (I guess 
>> alternatively rebuilding Mono or something could work). Cheers!
>
>I play a LOT of OpenRA ;)
>
>Glad it solved your issue!
>
>--dan

That's literally an incredibly stupid idea. Symlink /usr/lib/libtinfo.so.5 to 
/usr/lib/libtinfo.so.6 does not magically make it compatible for both, it is 
ABI incompatible that's the whole point of a soname bump. Anything linking to 
libtinfo.so.6 may now be broken in one or the other way. never ever overwrite 
existing versioned so libs with any other version.