PKGBuild for Arch Linux

[ghost]

For the record, congos on the great effort. Want to jump straight to using this!

[Eloston]

Alright. Thanks for the complement, I appreciate it. :)

If you or others are interested: If you have some Python background, you can adapt the Debian build module from buildlib/debian.py to work on Arch Linux. Or, you can detail out the exact steps to make a build. It would be ideal if Arch-specific changes to Chromium were included in the build of ungoogled-chromium, much like the way it is done for Debian.

Though I wonder what @gcarq would think about this... (since @gcarq provides Arch binaries of Inox patchset)

[ilikenwf]

To be fair, even the Inox PKGBUILD just grabs the patches itself:

https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=inox

Otherwise the only other options are those in the build there, and possibly the ones to toggle GTK3 and whatever plugins/libs should be included.

I'm chiming in here because while I support Palemoon in principle and goals, it is becoming a hindrance to use it.

[ilikenwf]

I've not got a PKGBUILD yet, but to get a bit further in Arch, you have to specify the PKG_CONFIG_PATH before running build.py :

export PKG_CONFIG_PATH=/usr/lib/pkgconfig

From there, we fail, despite having libcups installed, at:

gyp: Call to 'python cups_config_helper.py --api-version /media/disk/makepkg/ungoogled-chromium/build/sandbox/build/linux/debian_wheezy_amd64-sysroot' returned exit status 1 while in /media/disk/makepkg/ungoogled-chromium/build/sandbox/printing/printing.gyp. 2016-11-26 02:00:43,777 - ERROR: GYP command returned non-zero exit code: 1

[Eloston]

@ilikenwf Are you using version 53? I'm in the middle of upgrading to 54, which will use GN. IIRC, an issue relating to cups compilation error in Inox was fixed with the upgrade to 54.

[ilikenwf]

@Eloston yes, I am, since it's the current master HEAD.

I'll give er a shot once you've got it updated, probably tomorrow, and if it works out ok I'll write a PKGBUILD that just wraps around your python build script, at least for now...

In the future it may be nice to break out all the steps your builder takes, if possible, inside of a PKGBUILD instead as many times the people using the AUR like to tweak these packages before compilation to add/remove flags, patches, and features.

[Eloston]

I'll give er a shot once you've got it updated, probably tomorrow,

That is, if I can get it done tomorrow... at this stage, it's hard to predict what kind of problems I might run into (especially due to the switch to GN, which is pretty new to me).

In the future it may be nice to break out all the steps your builder takes, if possible, inside of a PKGBUILD instead as many times the people using the AUR like to tweak these packages before compilation to add/remove flags, patches, and features.

Yeah I haven't really considered this use-case when I evolved buildlib. I had the same problem back when people wanted to use OBS, which required a debian folder to do everything. I'll create a new issue for this topic.

[ilikenwf]

I'm patient, basically whenever you can is when I'll get to it...Arch needs this in it's life.

I use a combo of Pale Moon and Ungoogled Chromium on my Windows machines but am waiting for Ungoogled-Chromium to arrive for my Arch machines..PM and vanilla Chromium can suffice until then, since I use Chromium myself more for sites that won't render properly with my privacy setup in Pale Moon.

On Sat, Nov 26, 2016 at 2:23 AM, Eloston notifications@github.com wrote:

I'll give er a shot once you've got it updated, probably tomorrow,

That is, if I can get it done tomorrow... at this stage, it's hard to predict what kind of problems I might run into (especially due to the switch to GN, which is pretty new to me).

In the future it may be nice to break out all the steps your builder takes, if possible, inside of a PKGBUILD instead as many times the people using the AUR like to tweak these packages before compilation to add/remove flags, patches, and features.

Yeah I haven't really considered this use-case when I evolved buildlib. I had the same problem back when people wanted to use OBS, which required a debian folder to do everything. I'll create a new issue for this topic.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/Eloston/ungoogled-chromium/issues/44#issuecomment-263051156, or mute the thread https://github.com/notifications/unsubscribe-auth/AAZUOg0dJy-lHeP4nBEiq57xrpRqV8XUks5rB-x-gaJpZM4KGCx8 .

[ilikenwf]

Just so you know, even with the current system, I get as far as this, and know not what to do next:

/bin/sh: ../../third_party/llvm-build/Release+Asserts/bin/clang++: No such file or directory

[Eloston]

That can be fixed with a GN flag as it is done on Debian. But I don't remember if I implemented the Python 2 hacking like it is done in the PKGBuild.

[ilikenwf]

I'll have to investigate how you did that for debian.

The real fun with open source is that every new thing like this makes us all noobs again, except for the creator :)

On Thu, Dec 1, 2016 at 10:14 PM, Eloston notifications@github.com wrote:

That can be fixed with a GN flag as it is done on Debian. But I don't remember if I implemented the Python 2 hacking like it is done in the PKGBuild.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/Eloston/ungoogled-chromium/issues/44#issuecomment-264369502, or mute the thread https://github.com/notifications/unsubscribe-auth/AAZUOhCV64yFw9WcaJxi5itjTtl5WeOnks5rD5s_gaJpZM4KGCx8 .

[Eloston]

Alright then. You can try 8b6994f3a3eab1accc49e5642111f52ca227bccf out and see how that blows up for you. I basically copied over the Debian patches and GN flags for Arch.

[ilikenwf]

Closer, but no cigar:

FAILED: gen/blink/core/CSSValueKeywords.cpp gen/blink/core/CSSValueKeywords.h 
python ../../third_party/WebKit/Source/build/scripts/make_css_value_keywords.py ../../third_party/WebKit/Source/core/css/CSSValueKeywords.in ../../third_party/WebKit/Source/core/css/SVGCSSValueKeywords.in --output_dir gen/blink/core --gperf gperf
Traceback (most recent call last):
  File "../../third_party/WebKit/Source/build/scripts/make_css_value_keywords.py", line 177, in <module>
    in_generator.Maker(CSSValueKeywordsWriter).main(sys.argv)
  File "/media/disk/Linux/makepkg/ungoogled-chromium/build/sandbox/third_party/WebKit/Source/build/scripts/in_generator.py", line 95, in main
    writer.write_files(options.output_dir)
  File "/media/disk/Linux/makepkg/ungoogled-chromium/build/sandbox/third_party/WebKit/Source/build/scripts/in_generator.py", line 71, in write_files
    self._write_file_if_changed(output_dir, generator(), file_name)
  File "../../third_party/WebKit/Source/build/scripts/make_css_value_keywords.py", line 172, in generate_implementation
    gperf = subprocess.Popen(gperf_args, stdin=subprocess.PIPE, stdout=subprocess.PIPE, universal_newlines=True)
  File "/usr/lib/python2.7/subprocess.py", line 711, in __init__
    errread, errwrite)
  File "/usr/lib/python2.7/subprocess.py", line 1343, in _execute_child
    raise child_exception
OSError: [Errno 2] No such file or directory
[2798/22635] ACTION //third_party/WebKit/Source/core:make_core_generated_css_property_names(//build/toolchain/linux:clang_x64)
FAILED: gen/blink/core/CSSPropertyNames.cpp gen/blink/core/CSSPropertyNames.h 
python ../../third_party/WebKit/Source/build/scripts/make_css_property_names.py ../../third_party/WebKit/Source/core/css/CSSProperties.in --output_dir gen/blink/core --gperf gperf
Traceback (most recent call last):
  File "../../third_party/WebKit/Source/build/scripts/make_css_property_names.py", line 238, in <module>
    in_generator.Maker(CSSPropertyNamesWriter).main(sys.argv)
  File "/media/disk/Linux/makepkg/ungoogled-chromium/build/sandbox/third_party/WebKit/Source/build/scripts/in_generator.py", line 95, in main
    writer.write_files(options.output_dir)
  File "/media/disk/Linux/makepkg/ungoogled-chromium/build/sandbox/third_party/WebKit/Source/build/scripts/in_generator.py", line 71, in write_files
    self._write_file_if_changed(output_dir, generator(), file_name)
  File "../../third_party/WebKit/Source/build/scripts/make_css_property_names.py", line 233, in generate_implementation
    gperf = subprocess.Popen(gperf_args, stdin=subprocess.PIPE, stdout=subprocess.PIPE, universal_newlines=True)
  File "/usr/lib/python2.7/subprocess.py", line 711, in __init__
    errread, errwrite)
  File "/usr/lib/python2.7/subprocess.py", line 1343, in _execute_child
    raise child_exception
OSError: [Errno 2] No such file or directory

[Eloston]

@ilikenwf Try installing gperf and bison.

[ilikenwf]

Closer now...but it doesn't like ICU 58.1 - seems someone at FreeBSD has a patch:

https://reviews.freebsd.org/rP426523

On Wed, Dec 7, 2016 at 10:42 PM, Eloston notifications@github.com wrote:

@ilikenwf https://github.com/ilikenwf Try installing gperf and bison.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/Eloston/ungoogled-chromium/issues/44#issuecomment-265651664, or mute the thread https://github.com/notifications/unsubscribe-auth/AAZUOsRdcG1j_5RuwsBZk7DsRGA3VbH0ks5rF4qggaJpZM4KGCx8 .

[ilikenwf]

Better yet, at gentoo: https://gitweb.gentoo.org/repo/gentoo.git/tree/www-client/chromium/files/chromium-icu-58.patch

On Wed, Dec 7, 2016 at 11:00 PM, parwok@gmail.com parwok@gmail.com wrote:

Closer now...but it doesn't like ICU 58.1 - seems someone at FreeBSD has a patch:

https://reviews.freebsd.org/rP426523

On Wed, Dec 7, 2016 at 10:42 PM, Eloston notifications@github.com wrote:

@ilikenwf https://github.com/ilikenwf Try installing gperf and bison.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/Eloston/ungoogled-chromium/issues/44#issuecomment-265651664, or mute the thread https://github.com/notifications/unsubscribe-auth/AAZUOsRdcG1j_5RuwsBZk7DsRGA3VbH0ks5rF4qggaJpZM4KGCx8 .

[ilikenwf]

I tried that patch locally, and with it things build and run correctly.

I'll try to put together a PKGBUILD tomorrow.

[Eloston]

@ilikenwf How are you writing this PKGBUILD? Is it going to invoke buildlib, or are you going to make buildlib invoke it?

[ilikenwf]

It will invoke buildlib and package the resulting output...

I haven't dug into the specifics yet, but is there any way to have it leave the output without tarring it up, as PKGBUILDs typically expect to copy or use make install or manually install -D /path/to/each/file for a given package, to create the Arch specific package itself?

On Thu, Dec 8, 2016 at 1:35 AM, Eloston notifications@github.com wrote:

@ilikenwf https://github.com/ilikenwf How are you writing this PKGBUILD? Is it going to invoke buildlib, or are you going to make buildlib invoke it?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/Eloston/ungoogled-chromium/issues/44#issuecomment-265673027, or mute the thread https://github.com/notifications/unsubscribe-auth/AAZUOqdY6mYksQYXDSBZUJMQwJRhVb_oks5rF7NSgaJpZM4KGCx8 .

[Eloston]

It will invoke buildlib and package the resulting output...

Let me clarify. Is your PKGBUILD going to run buildlib, or are you going to modify buildlib by overriding the generate_package method in the Archlinux builder class to call some commands to use a PKGBUILD file?

EDIT: I should note that Debian overrides generate_package to copy a DPKG directory into the source tree and run dpkg-buildpackage

[ilikenwf]

I've not dug into this yet, but ideally we'd only need to override generate_package to have it just dump all the files into a given directory, after which the Arch package can be compressed...

Ideally, we do what the Inox package does for packaging:

https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=inox#n236

[Eloston]

Okay. The only concern I have is that this implementation will be scrapped once I deprecate buildlib. If you still want to implement this before that happens, that'll be fine by me.

[ilikenwf]

So should I hold off and just decompress the resulting tarball for now? I can do that in the interim.

On Sun, Dec 11, 2016 at 10:41 PM, Eloston notifications@github.com wrote:

Okay. The only concern I have is that this implementation will be scrapped once I deprecate buildlib. If you still want to implement this before that happens, that'll be fine by me.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/Eloston/ungoogled-chromium/issues/44#issuecomment-266341923, or mute the thread https://github.com/notifications/unsubscribe-auth/AAZUOuk5khESyWCykfT3H2G-XZ8PCf9Aks5rHNBdgaJpZM4KGCx8 .

[Eloston]

@ilikenwf That is probably a good idea, assuming I can implement the new system within a reasonable period of time.

[ilikenwf]

I was tempted to override the package building line, but didn't feel like it tonight.

If you could perhaps give us a way of passing an argument or setting an environment variable to not pack a tarball, but just dump the final output that would otherwise be tarballed into a directory, that'd be great!

https://aur.archlinux.org/packages/ungoogled-chromium/

[pickfire]

Seems like quilt is needed for build but it is not a makedepend.

[Eloston]

@pickfire I can drop the quilt requirement in the new build system if you want to.

[HellishINC]

Currently the following error is thrown when building:

2016-12-21 01:05:12,811 - INFO: Initialized default console logging handler 2016-12-21 01:05:12,811 - INFO: Using builder LinuxStaticBuilder 2016-12-21 01:05:12,812 - INFO: Setting up environment overrides... 2016-12-21 01:05:12,812 - INFO: Checking Python 2 command... 2016-12-21 01:05:12,812 - INFO: No Python 2 command specified; testing with 'python' 2016-12-21 01:05:12,834 - ERROR: Unsupported Python version '3.5.2'

This error is thrown when manually running python3 build.py as well though so I'm not sure if it's an issue with the buildpkg itself.

[ilikenwf]

python2 is in the makedepends, you should install it

On Wed, Dec 21, 2016 at 12:11 AM, Helly notifications@github.com wrote:

Currently the following error is thrown when building:

2016-12-21 01:05:12,811 - INFO: Initialized default console logging handler 2016-12-21 01:05:12,811 - INFO: Using builder LinuxStaticBuilder 2016-12-21 01:05:12,812 - INFO: Setting up environment overrides... 2016-12-21 01:05:12,812 - INFO: Checking Python 2 command... 2016-12-21 01:05:12,812 - INFO: No Python 2 command specified; testing with 'python' 2016-12-21 01:05:12,834 - ERROR: Unsupported Python version '3.5.2'

This error is thrown when manually running python3 build.py as well though so I'm not sure if it's an issue with the buildpkg itself.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/Eloston/ungoogled-chromium/issues/44#issuecomment-268444677, or mute the thread https://github.com/notifications/unsubscribe-auth/AAZUOomsP0f1VZwkb--0OCSzervfsAnVks5rKMMegaJpZM4KGCx8 .

[Eloston]

@HellishINC Looks like some problem with the Python distro module since it's not detecting your system to be Arch Linux.

[HellishINC]

@ilikenwf Correct me if I'm wrong but isn't that the point of makedepends in the pkgbuild? Python2 along with everything else mentioned in the current latest tag build docs was installed.

@Eloston Thanks for pointing that out. That was due to my "unpure" Antergos installation. I managed to temporarily work around that by editing my os-release (not recommended if anyone else reads this).

After working on this all day I finally got it to compile. I had to add minizip as a build dependency, though because I'm a stated newcomer to makepkg, I also added quilt (from the build.md) and clang (from a comment on the AUR). I think that's understandable considering it took well over 4 hours to build on its successful run.

I am however now running into a sandbox issue using the stock arch kernel. Using --disable-setuid-sandbox from #149 results in the same and with --no-sandbox everything under chrome://sandbox has a 'No'. Should I open a new issue instead of spamming this one?

[Eloston]

@HellishINC As mentioned in the issue report you linked, there's no user namespace support on Arch by default. So the sandboxing part of this document should apply to you. The PKGBuild can be modified to setup the SUID sandbox properly in the future.

[HellishINC]

Well, I renamed chrome_sandbox to chrome-sandbox and set ownership to root/4755 and it now runs.

[ilikenwf]

Personally I use firejail...

[Eloston]

The Arch PKGBUILD ungoogled-chromium was - is - will be hopelessly flawed affair from the begin.

Sorry, to sound rude - but yet again, infamous russians hackers were involved here.

I don't know what you're talking about but it doesn't seem relevant to this discussion.

Right now all that's left is to implement in the new build system is the build script generator. Once I get the build script generator working on Debian, it will be relatively easy to extend it to work on other platforms.

[Eloston]

@altblitz I still don't see how it is related to this issue, which is about adding a PKGBuild for Arch Linux. I don't understand how a independent Chromium build is relevant to the discussion.

[Eloston]

@altblitz I think we will be using some version of clang available in the Arch repos.

[Eloston]

Chromium can be build seemingly... And will fail at one test.

What test are you referring to?

BTW, all Linux distributions I've seen use their own version of clang when building their own versions of Chromium.

[Eloston]

Clang 3.9.1 is the latest stable available, and what most distributions would be willing to package. Clang 4.0 is still in development. I don't know if Chromium can still compile on clang 3.8 or older. For ungoogled-chromium's Debian builds (stretch or equivalent), clang 3.9 is used from the repository.

Why is this important? What one test does it fail at if another version of clang is used?

[Eloston]

Yet, proper clang 4.0 build did compile .gn and chromium. From same chromium v55 source.

Well Chromium can build with the system's clang 3.9 if the correct clang flags are set. I don't know what PKGBuild you're using or whether these flags are set correctly.

I know now, chromium can starts and correctly displays sites, till it encounter certain site with 'font-awesome'. That is the real world test. Proper clang SVN build chromium passes this test, clang lesser SVN number - would fail always.

Can you show me some images of what it is supposed to look like and how it fails? I went to some sites using "font-awesome" and I don't see any problems.

[Eloston]

@altblitz I tried that page on ungoogled-chromium Debian 55.0.2883.87-1 and I have no problems. Arch Linux has Clang 3.9.1 just like Debian, so there might be another factor that is causing the crash.

[ilikenwf]

Recent changes (replacing buildlib with utilkit) breaks building on Arch, it seems, as we run python 3.6 :(

See user comments at https://aur.archlinux.org/packages/ungoogled-chromium/

[Eloston]

@ilikenwf What's the error that you get?

[ilikenwf]

python check_requirements.py --common [04/04 01:14 AM] Checking common requirements... Checking Python 2 command... Traceback (most recent call last): File "check_requirements.py", line 143, in exit(main(sys.argv[1:])) File "check_requirements.py", line 137, in main method() File "check_requirements.py", line 44, in check_common_requirements result.stdout.strip("\n"))) Exception: Unsupported Python version '3.6.1'

On Tue, Apr 4, 2017 at 1:09 AM, Eloston notifications@github.com wrote:

@ilikenwf https://github.com/ilikenwf What's the error that you get?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/Eloston/ungoogled-chromium/issues/44#issuecomment-291402943, or mute the thread https://github.com/notifications/unsubscribe-auth/AAZUOv6wiMYKWPyDU26XVcMraxqOGXXSks5rsd6ngaJpZM4KGCx8 .

[Eloston]

@ilikenwf Oh. I forgot to add arguments to specify a different Python 2 interpreter. It defaults to python.

There shouldn't actually be anything in utilikit that breaks on Python 3.6, since I test it on 3.5 and I don't believe there is any backwards-compatibility breakage in 3.6. You can just skip check_requirements.py altogether since it's supposed to be a script for the user's convenience.

[ilikenwf]

Yeah, well 3.6 works other than the python2 thing...

I've yet to have time to mess with it past this point though.

On Tue, Apr 4, 2017 at 1:15 AM, Eloston notifications@github.com wrote:

@ilikenwf https://github.com/ilikenwf Oh. I forgot to add arguments to specify a different Python 2 interpreter. It defaults to python.

There shouldn't actually be anything in utilikit that breaks on Python 3.6, since I test it on 3.5 and I don't believe there is any backwards-compatibility breakage in 3.6. You can just skip check_requirements.py altogether since it's supposed to be a script for the user's convenience.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/Eloston/ungoogled-chromium/issues/44#issuecomment-291403827, or mute the thread https://github.com/notifications/unsubscribe-auth/AAZUOohLF2KPm7VoeuXHPVld2q7zcLoTks5rseASgaJpZM4KGCx8 .

[ilikenwf]

Is there something missing from the readmes as far as generating a vanilla style build script, or do I need to manually go into the sandbox at this point and have the PKGBUILD patch the patches in?

`export UTILIKIT_CONFIG_TYPE=archlinux export UTILIKIT_DOWNLOADS_DIR=${srcdir}

mkdir -p "$srcdir/${pkgname}/build/sandbox"
/usr/bin/python "$srcdir/${pkgname}/utilikit/prepare_sources.py"
/usr/bin/python "$srcdir/${pkgname}/utilikit/substitute_domains.py"
/usr/bin/python "$srcdir/${pkgname}/utilikit/generate_build_files.py" "--files_type debian --flavor standard --apply-domain-substitution"

/media/disk/Linux/makepkg/ungoogled-chromium/src/chromium-57.0.2987.110.tar.xz already exists. Skipping download. /media/disk/Linux/makepkg/ungoogled-chromium/src/chromium-57.0.2987.110.tar.xz.hashes already exists. Skipping download. Checking source archive integrity... Running 'md5' hash check... Running 'sha1' hash check... Running 'sha224' hash check... Running 'sha256' hash check... Running 'sha384' hash check... Running 'sha512' hash check... Extracting source archive into building sandbox... usage: generate_build_files.py [-h] [--ignore-environment] [--resources DIRECTORY] [--output-dir DIRECTORY] {debian} ... generate_build_files.py: error: argument files_type: invalid choice: 'debian --flavor standard --apply-domain-substitution' (choose from 'debian')`

[Eloston]

@ilikenwf

I made some changes to BUILDING.md in an attempt to eliminate confusion. Let me know if there are parts that need clarification.

Regarding the commands you used, I don't believe you want to put quotes around the arguments to the script because that will cause the shell to pass that in as one argument to Python. Also, you don't need to use --files_type because that is a positional argument (though it seems to work if you do anyway).

[ilikenwf]

Thank you, sir.

I'll investigate once I get a free moment.

[ilikenwf]

Oh, and the quotes are expanded, this is within a PKGBUILD, the syntax is a bit weird.

[Eloston]

Oh, and the quotes are expanded, this is within a PKGBUILD, the syntax is a bit weird.

Hm, really? It seems to me that the script is receiving one argument:

generate_build_files.py: error: argument files_type: invalid choice: 'debian --flavor standard --apply-domain-substitution' (choose from 'debian')`