bug#40626: Poor performance on low-end ARMv7 devices

[Denis 'GNUtoo' Carikli]

On Mon, 13 Jul 2020 15:34:15 +0200
Ludovic Courtès  wrote:

> Hi,
> 
> Denis 'GNUtoo' Carikli  skribis:
> 
> > Many ARM Single Board Computers are commonly used with microSD for
> > storage, and some microSD cards are extremely slow (and sometimes
> > unreliable when they are old).
> >
> > Could the performance issues be related to storage device I/Os?
> 
> It could be the reason; it’s definitely the case on the board I was
> using here.
> 
> Still I wonder what could be done on our side to improve on this.
I guessed that was the intent.

A way to deal with that could be to validate if it's actually the case,
for instance by installing an SSD, and doing performance comparison
with the time command.

Then if it helps a lot, we probably need to trace the filesystem access
and optimize it somehow. Maybe that can be done with BPF or gprof, but
I never looked into obtimizing I/O performances, so I'm unsure if
that's the right approach. Guile may have profiling tools too.

As for benchmarking the CPU, I've patched phoronix-test-suite in a very
quick and dirty way in Parabola, so we could at least have some
benchmarks. For now we only have "compilation" benchmarks with source
code that should be FSDG compliant.

With it I've found that the compilation performances can vary a lot
between different ARM and x86 boards:
- An I.MX6 Quad with 2G of RAM is about 4.5x faster than the AM335x of a
  Beaglebone Green with 512M of RAM.
- A Lime2 A20 is about 1.7x faster than the Beaglebone Green and 2.5x
  slower than the board with the I.MX6 Quad.
- My smartphone (Galaxy SIII GT-I9300) is about 2x faster than my server
  (PC Engines APU1) for compilation.

Denis.


pgpZXLpncBaQd.pgp
Description: OpenPGP digital signature

bug#42291: data service: Show list of files and allow qeuerying

[Christopher Baines]

Hartmut Goebel  writes:

> Serverity: wishlist
> I often find myself checking the content of a package. For this I
> would like to be able to inspect the list of files in a package, or
> even query for a specific file.
>
> This is much like Debian does in "list of files" for each package
> (e.g. 
> )
> and with "Search the contents of packages"
> 
>
> Many thanks :-)

Hi Hartmut,

So, I'm in total agreement that this data would be great to have, but so
far I've not been imagining meeting the need to search the files or
contents of store items through the Guix Data Service.

The contents of a package can also be viewed as the contents of a
directory in the store. The Guix Data Service does know about nars, but
just the information in the narinfo file.

What I've had in mind for a while is a service that listens to the Guix
Data Service for new nars, downloads them, indexes them (either just the
files, or file contents too), and then provides a search interface over
this data. It's a little tricky, as you have to decide what to do about
the build reproducibility problem, if a package doesn't build
reproducibly, it's possible to get multiple different lists of files for
the same package.

At the moment, I'm looking at the "building things" area, but I'm still
interested in this.

Thanks,

Chris


signature.asc
Description: PGP signature

bug#42162: Recovering source tarballs

[Christopher Baines]

Ludovic Courtès  writes:

> Hi,
>
> Ludovic Courtès  skribis:
>
>> There’s this other discussion you mentioned, which I hope will have a
>> positive outcome:
>>
>>   https://forge.softwareheritage.org/T2430
>
> This discussion as well as discussions on #swh-devel have made it clear
> that SWH will not archive raw tarballs, at least not in the foreseeable
> future.  Instead, it will keep archiving the contents of tarballs, as it
> has always done—that’s already a huge service.
>
> Not storing raw tarballs makes sense from an engineering perspective,
> but it does mean that we cannot rely on SWH as a content-addressed
> mirror for tarballs.  (In fact, some raw tarballs are available on SWH,
> but that’s mostly “by chance”, for instance because they appear as-is in
> a Git repo that was ingested.)  In fact this is one of the challenges
> mentioned in
> .
>
> So we need a solution for now (and quite urgently), and a solution for
> the future.
>
> For the now, since 70% of our packages use ‘url-fetch’, we need to be
> able to fetch or to reconstruct tarballs.  There’s no way around it.
>
> In the short term, we should arrange so that the build farm keeps GC
> roots on source tarballs for an indefinite amount of time.  Cuirass
> jobset?  Mcron job to preserve GC roots?  Ideas?

Going forward, being methodical as a project about storing the tarballs
and source material for the packages is probalby the way to ensure it's
available for the future. I'm not sure the data storage cost is
significant, the cost of doing this is probably in working out what to
store, doing so in a redundant manor, and making the data available.

The Guix Data Service knows about fixed output derivations, so it might
be possible to backfill such a store by just attempting to build those
derivations. It might also be possible to use the Guix Data Service to
work out what's available, and what tarballs are missing.

Chris


signature.asc
Description: PGP signature

bug#42346: Support Xcursor in Xlib

[Ivan Kozlov]

libX11 contains support for runtime loading of libXcursor. Without this 
support, programs that use Xlib’s mouse cursor routines, such as XTerm, do not 
follow the mouse cursor theme as determined by the Xcursor.theme resource and 
XCURSOR_THEME environment variable. This is in fact very noticeable and 
annoying.

How to reproduce:
1. Start XTerm.
2. Notice that the mouse cursor looks totally different from everything else. 
XTerm uses several mouse cursors: one for the text area, one for scrollbar, one 
for the menus, and they all stand out like a sore thumb.
3. Put libxcursor into LD_LIBRARY_PATH and start XTerm again.
4. Notice that the Xcursor theme is honoured.

This probably cannot be resolved by referencing libXcursor in libX11 because 
that would introduce a circular dependency.

The best solution I can think of is merging the libxcursor package into libx11. 
It is essentially a plugin.

bug#26302: Deploying the i18n’d web site

[pelzflorian (Florian Pelz)]

On Mon, Jul 13, 2020 at 04:48:00PM +0200, pelzflorian (Florian Pelz) wrote:
> On Mon, Jul 13, 2020 at 03:22:36PM +0200, Ludovic Courtès wrote:
> > I’m happy to press the red button on berlin when we feel ready.  Perhaps
> > we can synchronize on IRC in case things go wrong.
> > 
> > Thanks,
> > Ludo’.
> 
> I am currently at my grandma’s and unable to be on IRC most of the time.
> I will try to watch IRC now.
> I believe the berlin last patch works and suggest reverting otherwise.
> 
> Regards,
> Florian

No sorry, I would prefer not to do synchronous communication in the near future.

I am confident in my latest patch with explicit redirects though.

Regards,
Florian

bug#42327: Offload build to Childhurd selects linux-libre-headers

[Ludovic Courtès]

Hi!

Jan Nieuwenhuizen  skribis:

> With static-bash-for-glibc, however, it goes off track
>
> $ ./pre-inst-env guix build --system=i586-gnu \
>-e '(@@ (gnu packages commencement) static-bash-for-glibc)'
> The following derivations will be built:
>/gnu/store/gv40jpz4g0hbia28wa6d50z9x6ncgdlh-bash-static-5.0.16.drv
>
> /gnu/store/apj2ihazv6x3anhvfvmmqrkyak05p9yc-gcc-cross-boot0-wrapped-7.5.0.drv
>/gnu/store/yfpy5b3xqkarxchyhi339fw2ldwczj1d-linux-libre-headers-5.4.20.drv
>
>
> ...oops!  Note that a native build on the Childhurd works all the way up
> to "hello".
>
> The "glibc-final-with-bootstrap-bash" has a propagated-inputs that looks
> like this
>
> (define* (kernel-headers-boot0 #:optional (system (%current-system)))
>   (match system
> ("i586-gnu" hurd-core-headers-boot0)
> (_ linux-libre-headers-boot0)))
>
> (define glibc-final-with-bootstrap-bash
>[..]
>(propagated-inputs `(("kernel-headers" ,(kernel-headers-boot0
>[..])
>
> In KERNEL-HEADERS-BOOT0, SYSTEM is "x86_64-linux".  Passing SYSTEM from
> a LET-SYSTEM clause (see attached patch) seems to fix this...but i'm
> afraid that triggers a world rebuild.  Our offload Childhurds can only
> run master, right?  Is there any way around this?  Thoughts?

Here’s my powerful debugging trick for such dynamic binding issues (it’s
not related to offloading):

diff --git a/gnu/packages/commencement.scm b/gnu/packages/commencement.scm
index d0393ebe25..5ec7facd02 100644
--- a/gnu/packages/commencement.scm
+++ b/gnu/packages/commencement.scm
@@ -3116,6 +3116,9 @@ memoized as a function of '%current-system'."
   ,@(%boot0-inputs)
 
 (define* (kernel-headers-boot0 #:optional (system (%current-system)))
+  (when (string=? system "x86_64-linux")
+(pk system)
+(display-backtrace (make-stack #t) (current-error-port) #f 80))
   (match system
 ("i586-gnu" hurd-core-headers-boot0)
 (_ linux-libre-headers-boot0)))

That gives me this:

--8<---cut here---start->8---
$ ./pre-inst-env guix build -s i586-gnu hello -d --no-grafts

;;; ("x86_64-linux")
In ice-9/boot-9.scm:
  1736:10 30 (with-exception-handler _ _ #:unwind? _ #:unwind-for-type _)
In unknown file:
  29 (apply-smob/0 #)
In ice-9/boot-9.scm:
718:2 28 (call-with-prompt _ _ #)
In ice-9/eval.scm:
619:8 27 (_ #(#(#)))
In guix/ui.scm:
  1953:12 26 (run-guix-command _ . _)
663:2 25 (call-with-error-handling _)
In ice-9/boot-9.scm:
  1736:10 24 (with-exception-handler _ _ #:unwind? _ #:unwind-for-type _)
  1731:15 23 (with-exception-handler # _ #:unwind? _ # _)
In guix/status.scm:
776:4 22 (call-with-status-report _ _)
In ice-9/boot-9.scm:
  1736:10 21 (with-exception-handler _ _ #:unwind? _ #:unwind-for-type _)
In guix/store.scm:
   631:22 20 (thunk)
   1299:8 19 (call-with-build-handler # …)
In guix/scripts/build.scm:
925:2 18 (_)
In ice-9/boot-9.scm:
  1731:15 17 (with-exception-handler # _ #:unwind? _ # _)
  1736:10 16 (with-exception-handler _ _ #:unwind? _ #:unwind-for-type _)
In guix/ui.scm:
440:6 15 (_)
In guix/scripts/build.scm:
927:5 14 (_)
In srfi/srfi-1.scm:
   673:15 13 (append-map # ("i586-gnu"))
   586:17 12 (map1 ("i586-gnu"))
In guix/scripts/build.scm:
   929:20 11 (_ _)
In guix/store.scm:
   1340:2 10 (map/accumulate-builds # _ _)
In srfi/srfi-1.scm:
   586:17  9 (map1 (#))
In guix/store.scm:
   1299:8  8 (call-with-build-handler # _)
In guix/scripts/build.scm:
   888:18  7 (_ _)
In guix/packages.scm:
  1075:16  6 (package-derivation _ # _ #:graft? _)
  1393:22  5 (thunk)
927:4  4 (bag->derivation # #< 
name: "hello-2.10" system: "i586-…> …)
   812:23  3 (transitive-inputs _)
In gnu/packages/commencement.scm:
  3304:44  2 (propagated-inputs #)
  3121:23  1 (kernel-headers-boot0 _)
In unknown file:
   0 (make-stack #t)
--8<---cut here---end--->8---

At that point, it looks like a déjà-vu to me.  :-)

Should be fixed with efb10f175fa6323024aa471c58ea1da445085298.

Thanks,
Ludo’.

bug#26302: Deploying the i18n’d web site

[pelzflorian (Florian Pelz)]

On Mon, Jul 13, 2020 at 03:22:36PM +0200, Ludovic Courtès wrote:
> Looks like we’re pretty much ready, no?

I think we are.

> I’m happy to press the red button on berlin when we feel ready.  Perhaps
> we can synchronize on IRC in case things go wrong.
> 
> Thanks,
> Ludo’.

I am currently at my grandma’s and unable to be on IRC most of the time.
I will try to watch IRC now.
I believe the berlin last patch works and suggest reverting otherwise.

Regards,
Florian

bug#42343: 504 error

[Adam Kandur via Bug reports for GNU Guix]

Hi everyone, 
https://ci.guix.gnu.org/search/latest/image?query=spec:guix-master+status:success+system:x86_64-linux+hurd-barebones-disk-image
 returns 504

bug#41982: [PATCH v2] grub-core: Build fixes for i386

[Jan Nieuwenhuizen]

Ludovic Courtès writes:

Hi!

> Jan Nieuwenhuizen  skribis:
>
>> Jan Nieuwenhuizen writes:
>>
>> lib/i386/relocator64.S:97: Error: bad register name `%rsp'
>>
>> The attached v2 fixes that.
>
> On the Guix side I guess you can go ahead and apply it.
>
> Well done!

Thanks!  Ah, I already done in 54e70a70f2cb6336b02ed3ac4256f6b44da5c769
after discussing with Mathieu on IRC.  I wanted to keep a line to
upstream, being cautious for continuing to carry a diff here.

Janneke

-- 
Jan Nieuwenhuizen  | GNU LilyPond http://lilypond.org
Freelance IT http://JoyofSource.com | Avatar® http://AvatarAcademy.com

bug#41982: [PATCH v2] grub-core: Build fixes for i386

[Ludovic Courtès]

Hi!

Jan Nieuwenhuizen  skribis:

> Jan Nieuwenhuizen writes:
>
> Hello!
>
>> When cross-compiling Grub-2.04 from i386-linux-gnu to i586-pc-hurd on
>> GNU Guix, I got this error
>
> Today, we found* that my patch introduced a regression: a native, EFI
> build on i686-linux-gnu failed with
>
> lib/i386/relocator64.S:97: Error: bad register name `%rsp'
>
> The attached v2 fixes that.

On the Guix side I guess you can go ahead and apply it.

Well done!

Ludo’.

bug#42224: Emacs currently requires bash and gzip to be progatade to load core functionality.

[Ludovic Courtès]

Hi,

Maxim Cournoyer  skribis:

> It was discovered while troubleshooting an issue on help-guix [0] that
> Emacs cannot currently load its subr-x module (there are probably many
> more) when used in a pure environment (or container) that doesn't
> propagate bash and gzip, which it uses to decompress the said module.

D’oh!

> The fix would be to patch Emacs' sources so those programs are referred
> by their absolute store paths rather than simply being looked in PATH.

Yup, looks like the way to go.

Ludo’.

bug#42173: Nix on Guix System: can't update channels

[Ludovic Courtès]

Hi Alexandru-Sergiu,

Alexandru-Sergiu Marton  skribis:

> I tried to set up the Nix package manager on my Guix System following
> the instructions at http://guix.gnu.org/manual/en/guix.html#index-Nix
> . Unfortunately, after reconfiguring the system and adding a channel
> with `nix-channel --add https://nixos.org/channels/nixpkgs-unstable`,
> when I tried to update the channels (`nix-channel --update`), this is
> what I got:
>
> --8<---cut here---start->8--- 
> [brown@121408 ~]$ nix-channel --update unpacking channels... while setting up 
> the build environment: executing 
> '/gnu/store/pwcp239kjf7lnj5i4lkdzcfcxwcfyk72-bash-minimal-5.0.16/bin/bash': 
> No such file or directory builder for 
> '/nix/store/fqvvrsyznxfzckxbiz6krlykdb6w105n-nixpkgs-20.09pre232864.55668eb671b.drv'
>  failed with exit code 1 error: build of 
> '/nix/store/fqvvrsyznxfzckxbiz6krlykdb6w105n-nixpkgs-20.09pre232864.55668eb671b.drv'
>  failed error: program 
> '/gnu/store/lsixql26nig4v3icn124ja3ivjpgvn99-nix-2.3.6/bin/nix-env' failed 
> with exit code 100 --8<---cut 
> here---end--->8--- 
>
> Any tips on how to fix this?

It seems that the Nix binaries captured the
/gnu/store/pwcp239kjf7lnj5i4lkdzcfcxwcfyk72-bash-minimal-5.0.16/bin/bash
file name somewhere.  Does this file actually exist?

What does this return?

  guix gc --references /gnu/store/lsixql26nig4v3icn124ja3ivjpgvn99-nix-2.3.6

Thanks,
Ludo’.

bug#40626: Poor performance on low-end ARMv7 devices

[Ludovic Courtès]

Hi,

Denis 'GNUtoo' Carikli  skribis:

> Many ARM Single Board Computers are commonly used with microSD for
> storage, and some microSD cards are extremely slow (and sometimes
> unreliable when they are old).
>
> Could the performance issues be related to storage device I/Os?

It could be the reason; it’s definitely the case on the board I was
using here.

Still I wonder what could be done on our side to improve on this.

Ludo’.

bug#26302: Deploying the i18n’d web site

[Ludovic Courtès]

Hey!

"pelzflorian (Florian Pelz)"  skribis:

> On Thu, Jul 09, 2020 at 05:56:43PM +0100, Christopher Baines wrote:
>> Thanks for your continued time working on this Florian. I've made a
>> little bit of progress now, I've taken the wip-i18n branch, applied the
>> patch attached to this email and deployed that at [1].
>> 
>> 1: http://guix-website-test.cbaines.net/
>> 
>> This isn't a close test of the configuration for berlin, but might come
>> in useful when testing the NGinx configuration.
>> 
>> Thanks,
>> 
>> Chris
>
> This is a nice replica but with all the same issues.  Have you made
> improvements that should be added to my last patch for
> guix-maintenance before it is deployed?

Looks like we’re pretty much ready, no?

I’m happy to press the red button on berlin when we feel ready.  Perhaps
we can synchronize on IRC in case things go wrong.

Thanks,
Ludo’.

bug#42247: Channel news raise error on `guix pull`

[Bengt Richter]

On +2020-07-13 12:27:39 +0200, Ludovic Courtès wrote:
> Hi,
> 
> Pierre Neidhardt  skribis:
> 
> > Ludovic Courtès  writes:
> >
> >> This suggests that the ‘news.scm’ file of your channel is being picked
> >> up and evaluated as if it were a module, which it’s not.
> >>
> >> The solution is to rename it to, say, ‘news.txt’, or to move the actual
> >> modules to a sub-directory and specify that in ‘.guix-channel’ (info
> >> "(guix) Channels").
> >
> > Thanks for the hint, this works indeed!
> >
> > 1. Is there anything we can do to catch this error and output a more
> > intelligible error message?
> 
> I don’t think so: Guile is just doing its job and picking up .scm
> files.
>

You are not saying that a file extension is used as hard type data
when "Guile is just doing its job ..." are you?? (unless the producer
of the filename is contracted to guarantee the extension semantics in
guile's environment at the run-time in question ...
but where is such policy documented, if so? (I don't mean looking for
.go files newer than corresponding .scm, etc))

> > 2. I suggest we document this pitfall in the documentation.
> 
> Yup, makes sense; would you like to send a patch?
> 
> Thanks,
> Ludo’.
> 
> 
> 

-- 
Regards,
Bengt Richter

bug#42342: Wine64 segfaults (5.12/staging)

[Leo Prikler]

Interestingly enough 5.8 (ec16aaff5da9eb52b9d762531660f02e785d72de)
works without problems and there is no version packaged between it and
5.12/5.12.1 (wine64 and wine64-staging respectively).  Given this array
of results I'm pretty sure something goes wrong upstream.

I'll use inferiors as a local workaround for the time being and wait
for the problem to be fixed upstream.  I'll also look into 5.9 to 5.11
and perhaps provide a proper downgrade patch later on.

Regards, Leo

bug#42341: [BUG] build of ~guix-system-tests.drv failed

[Julien Lepiller]

Le 12 juillet 2020 22:08:42 GMT-04:00, Kurt I  a écrit 
:
>Greetings,
>
>Please see below:
>
>cannot build derivation `/gnu/store/521zc5vzprxjy76bzdzl32aa3dz080i8-
>guix-system-tests-modules.drv': 1 dependencies couldn't be built
>cannot build derivation `/gnu/store/5g9hars1x2bvn22v488aqi1yrcvlgiwp-
>guix-bea2134fe-modules.drv': 1 dependencies couldn't be built
>cannot build derivation `/gnu/store/m89gvvg6h24q8wg9qq3w4ly9v7b0pp1g-
>guix-bea2134fe.drv': 1 dependencies couldn't be built
>cannot build derivation `/gnu/store/4ipbj6sfwsvvi7cm1169b1vlysp82xf7-
>profile.drv': 1 dependencies couldn't be built
>guix pull: error: build of
>`/gnu/store/4ipbj6sfwsvvi7cm1169b1vlysp82xf7-profile.drv' failed
>guix@zippy ~$ bzcat
>/var/log/guix/drvs/4i/f6rdn4fmq6k9gm0qr7n1s921mabx3i-guix-system-
>tests.drv.bz2
>[  6/ 50] loading...24.0% of 25 filesrandom seed for tests:
>1594605857
>[ 24/ 50] loading...96.0% of 25 filesBacktrace:
>In ice-9/threads.scm:
>390:8 19 (_ _)
>In ice-9/boot-9.scm:
>  3507:20 18 (_)
>   2806:4 17 (save-module-excursion #9/boot-9.scm:3508:21 ()>)
>  3527:26 16 (_)
>In unknown file:
>  15 (primitive-load-path "gnu/tests/web" #7fffe874de40 at ice-9/boot-9.scm:3514:37 ()>)
>In ice-9/eval.scm:
>   626:19 14 (_ #)
>   293:34 13 (_ #(#(#
>"patchwork") "Connect to a running Patchwork service."))
>619:8 12 (_ #(#(#(#)
>#7fffebcaf960>) #>
># ?))
>   626:19 11 (_ #(#(#(#)
>#7fffebcaf960>) #>
># ?))
>163:9 10 (_ #(#(#(#)
>#7fffebcaf960>) #>
># ?))
>   293:34  9 (_ #(#(#)
>#7fffebcaf960>))
>   174:20  8 (_ #(#(#)
>#7fffebcaf960>))
>   177:49  7 (lp (#(env)> #
>#))
>   177:32  6 (lp (#(env)> #))
>163:9  5 (_ #(#(#)
>#7fffebcaf960>))
>155:9  4 (_ #(#(#)
>#7fffebcaf960>))
>   279:15  3 (_ #(#(#(#(#)
>#< engine:
>"django.db.backends.postgresql_psycopg2" name: "patchwork" user:
>"httpd" pas?>) #) #))
>159:9  2 (_ #(#(#(#(#)
>#< engine:
>"django.db.backends.postgresql_psycopg2" name: "patchwork" user:
>"httpd" pas?>) #) #))
>   223:20  1 (proc #(#(#(#(#)
>#< engine:
>"django.db.backends.postgresql_psycopg2" name: "patchwork" user:
>"httpd" ?>) #) #))
>In unknown file:
>   0 (%resolve-variable (7 . configuration>) #)
>
>ERROR: In procedure %resolve-variable:
>error: : unbound variable

I pushed a fix after this issue was reported on irc yesterday, as 5cd9cd64. I 
was able to run guix pull this morning, so closing.

bug#42247: Channel news raise error on `guix pull`

[Ludovic Courtès]

Hi,

Pierre Neidhardt  skribis:

> Ludovic Courtès  writes:
>
>> This suggests that the ‘news.scm’ file of your channel is being picked
>> up and evaluated as if it were a module, which it’s not.
>>
>> The solution is to rename it to, say, ‘news.txt’, or to move the actual
>> modules to a sub-directory and specify that in ‘.guix-channel’ (info
>> "(guix) Channels").
>
> Thanks for the hint, this works indeed!
>
> 1. Is there anything we can do to catch this error and output a more
> intelligible error message?

I don’t think so: Guile is just doing its job and picking up .scm
files.

> 2. I suggest we document this pitfall in the documentation.

Yup, makes sense; would you like to send a patch?

Thanks,
Ludo’.

bug#42342: Wine64 segfaults (5.12/staging)

[Leo Prikler]

Since commit 065a5ed677cdd1a65acae20f185d7c4bd23b1f2c wine and wine64
are upgraded to version 5.12.  The latter segfaults when doing anything
other than wine --help or wine --version.  (Try for example wine
regedit or winecfg).

The old 5.3 version continues to work after roll-back, and would
probably also work through inferiors.  I am currently checking previous
versions of wine64-staging with guix time-machine to see at which point
the error might have been introduced.  Until now, version 5.6 from
7b23a69d6b97c463cb1ef237931af11c22c19c67 fails with the following
output:

000b:fixme:winediag:__wine_start_process Wine Staging 5.6 is a testing
version containing experimental patches.
000b:fixme:winediag:__wine_start_process Please mention your exact
version when filing bug reports on winehq.org.
0009:err:module:LdrInitializeThunk "kernelbase.dll" failed to
initialize, aborting
0009:err:module:LdrInitializeThunk Initializing dlls for
L"C:\\windows\\system32\\winecfg.exe" failed, status c005

Regards, Leo