Arch Linux User Repository

All my packages are managed at GitHub where you can also contribute directly: https://github.com/Martchus/PKGBUILDs There also exist a binary repository: https://martchus.no-ip.biz/repo/arch/ownstuff

I saw the deletion request and you can go ahead with it. If anyone wants to see this package for whatever reasons, it is still on my PKGBUILDs repo (in an archive subdir, this is definitely not very interesting for me anymore).

mktemp: failed to create file via template ‘/opt/depot_tools/.cipd_client.XXXXXXX’: Permission denied curl: (23) Failed writing body (0 != 1388) WARNING: Your metrics.cfg file was invalid or nonexistent. A new one will be created. Could not write the metrics collection config: [Errno 13] Permission denied: '/opt/depot_tools/metrics.cfg' Metrics collection will be disabled. created .gclient mktemp: failed to create file via template ‘/opt/depot_tools/.cipd_client.XXXXXXX’: Permission denied curl: (23) Failed writing body (0 != 1388) WARNING: Your metrics.cfg file was invalid or nonexistent. A new one will be created. Could not write the metrics collection config: [Errno 13] Permission denied: '/opt/depot_tools/metrics.cfg' Metrics collection will be disabled.

Failed to fetch file gs://chromium-clang-format/8f37fe78cc478600761211413e4974ceef94501d for buildtools/linux64/clang-format. [Err: /opt/depot_tools/vpython: line 42: /opt/depot_tools/.cipd_bin/vpython: No such file or directory ]

Also replace gyp-git to gyp, damn python

resolved it using

export PATH="${PATH}:/opt/depot_tools"

but got another error (how to format snippets on this website?)

[0:00:06] Checked out 81c2e5ff92af29bab61c982808076ddce3d200a2 to a detached HEAD. Before making any commits in this repo, you should use 'git checkout <branch>' to switch to an existing branch or use 'git checkout origin -b <branch>' to create a new branch for your work. [0:00:06]</branch></branch>

<hr>

Traceback (most recent call last):

File "/opt/depot_tools/gclient.py", line 2836, in <module> sys.exit(main(sys.argv[1:]))</module>

File "/opt/depot_tools/gclient.py", line 2822, in main return dispatcher.execute(OptionParser(), argv)

File "/opt/depot_tools/subcommand.py", line 252, in execute return command(parser, args[1:])

File "/opt/depot_tools/gclient.py", line 2577, in CMDsync ret = client.RunOnDeps('update', args)

File "/opt/depot_tools/gclient.py", line 1578, in RunOnDeps work_queue.flush(revision_overrides, command, args, options=self._options)

File "/opt/depot_tools/gclient_utils.py", line 1059, in run self.item.run(self.args, *self.kwargs)

File "/opt/depot_tools/gclient.py", line 950, in run self.ParseDepsFile()

File "/opt/depot_tools/gclient.py", line 745, in ParseDepsFile deps_content, global_scope, local_scope, filepath)

File "/opt/depot_tools/gclient_eval.py", line 227, in Exec _visit_in_module(stmt)

File "/opt/depot_tools/gclient_eval.py", line 211, in _visit_in_module value = _gclient_eval(node.value, global_scope, filename=filename)

File "/opt/depot_tools/gclient_eval.py", line 191, in _gclient_eval return _convert(node_or_string)

File "/opt/depot_tools/gclient_eval.py", line 164, in _convert for k, v in zip(node.keys, node.values))

File "/usr/lib/python2.7/collections.py", line 69, in init self.__update(args, *kwds)

File "/usr/lib/python2.7/_abcoll.py", line 571, in update for key, value in other:

File "/opt/depot_tools/gclient_eval.py", line 164, in <genexpr> for k, v in zip(node.keys, node.values))</genexpr>

File "/opt/depot_tools/gclient_eval.py", line 164, in _convert for k, v in zip(node.keys, node.values))

File "/usr/lib/python2.7/collections.py", line 69, in init self.__update(args, *kwds)

File "/usr/lib/python2.7/_abcoll.py", line 571, in update for key, value in other:

File "/opt/depot_tools/gclient_eval.py", line 164, in <genexpr> for k, v in zip(node.keys, node.values))</genexpr>

File "/opt/depot_tools/gclient_eval.py", line 183, in _convert return _convert(node.left) + _convert(node.right)

File "/opt/depot_tools/gclient_eval.py", line 185, in _convert return _convert(node.left) % _convert(node.right)

TypeError: not all arguments converted during string formatting

==> ERROR: A failure occurred in prepare(). Aborting...

==> ERROR: Makepkg was unable to build mingw-w64-angleproject.

==> Restart building mingw-w64-angleproject ? [y/N]

==> ----------------------------------------------- ==>

Yes, this file seems to be gone in newer versions of depot-tools. You could try the following fix: https://github.com/Martchus/PKGBUILDs/commit/580bf7249e0e05f79989b49473dd37086f830107

If it works, I'll update the AUR package. Otherwise you can stick to depot-tools-git-r3726.e4f0fe0-1 till I have time to fix this package.

==> Starting prepare()... /mnt/ssd120/tmp/yaourt-tmp-nick/aur-mingw-w64-angleproject/./PKGBUILD: line 71: /etc/profile.d/depot_tools.sh: No such file or directory ==> ERROR: A failure occurred in prepare(). Aborting... ==> ERROR: Makepkg was unable to build mingw-w64-angleproject. ==> Restart building mingw-w64-angleproject ? [y/N]

I don't have depot_tools.sh even in /opt/depot_tools

gyp is now in official repo

@jbg I obviously didn't have that issue last time I built this package (December last year). Maybe a change in the behaviour of depot-tools/ninja. General note: I'll update mingw-w64-angleproject again when updating mingw-w64-qt5-webkit to 'ng' version. Then I'll drop the patches to make WebKit use this package which will allow to get rid of `0005-Export-shader-API-via-libGLESv2.dll.patch`. The idea of using system ANGLE rather than the bundled version for WebKit from the previous maintainer was nice, but it has become too hard to maintain.

To make this package build, I had to change `--depth .` to `--depth ..` in gyp_args and `out/Release` to `../out/Release` in ninja_args, in the build function in PKGBUILD.

I've just pushed a new commit. Added the flags for optimization and updated the to the latest version. However, I haven't tested whether it actually runs. This is using now dept-tools and ninja (seems to be the recommend way of building ANGLE). Concurrent builds are now not broken anymore, so this should build much faster. I hope I haven't broken shader API required by Qt WebKit.

As I already said, the flags are taken from Fedora. The Fedora devs chose the flags so they match as best as possible the default flags for regular packages under Fedora (according to some guy at #fedora-mingw IRC channel). I agree with that strategy. Hence, here we should use flags which match best the default flags under Arch. The default flags under Arch are defined makepkg.conf: https://git.archlinux.org/svntogit/packages.git/tree/trunk/makepkg.conf?h=packages/pacman where architecture specific flags are replaced within the PKGBUILD: https://git.archlinux.org/svntogit/packages.git/tree/trunk/PKGBUILD?h=packages/pacman So the default flags under Arch indeed include the proposed flag. I think that would be a good reason to also include the flags here. However, for consistency that decision should be done for all mingw-w64 packages and not only for this one. Till a general decision is made I will not update the flags. And there are more things to consider. I'm not sure about the default flags in Fedora but the Fedora Wiki states march/mtune as optional flags (whatever this means): https://fedoraproject.org/wiki/Packaging:RPMMacros#Build_flags_macros_and_variables That means that Fedora devs differ here from their own default flags and maybe they have a good reason for that. I should also mention that the current version of mingw-w64 has some serious bugs. The i686 version of binutils is more or less unusable (just have a look at the bug reports concerning the mingw-w64-binutils package). There are also bugs triggered by optimization. For example if you instantiate std::stringstream inside a library built with at least -O1 the application crashes with a page fault. (I already filed a bug report bug haven't got any response so far: https://sourceforge.net/p/mingw-w64/bugs/548/.) I've just took a look and noticed that ANLGE also makes use of that class so if you experience crashes that might be the reason. (That means using the flags currently present in the PKGBUILD is actually a bad idea with the current version of mingw-w64!) So you see that adding flags (especially concerning optimizations) might has side affect such as very annoying bugs. Hence I suppose it is best to wait for a more stable release of mingw-w64 before changing the flags for mingw-w64 packages. Some testing would also be required. BTW: I recently tried to rebuild this using a newer commit ID and it failed. Not even because of the patches but because of missing headers provided by another Google project. I guess it would be better if this PKGBUILD would use depot_tools and maybe ninja according to the build instructions.