Use of Open Build Service (OBS) about ungoogled-chromium-debian HOT 43 CLOSED

@Eloston

The biggest problem right now is installing LLVM inside OBS

I have good news. While ASFAIK it is (currently) not possible to use external repositories like apt.llvm.org, it is possible to mirror them.
I created a _service file which downloads all required .debs from apt.llvm.org.
Then the build.script can be used to put those .debs in the correct place, so they get uploaded.

It is then possible to use this mirror, and install clang-10 from it.

For creating the _service file I made a python script. It parses the Packages file of apt.llvm.org.

@Ryu0
On OBS I get an error when building ungoogled-chromium. Is this the same what you are getting?

[ 2089s] [4719/22203] CXX obj/third_party/angle/src/libANGLE/renderer/vulkan/angle_vulkan_backend/PersistentCommandPool.o
[ 2091s] [4720/22203] CXX obj/third_party/angle/src/libANGLE/renderer/vulkan/angle_vulkan_backend/ProgramPipelineVk.o
[ 2092s] [4721/22203] CXX obj/third_party/angle/src/libANGLE/renderer/vulkan/angle_vulkan_backend/GlslangWrapper.o
[ 2092s] FAILED: obj/third_party/angle/src/libANGLE/renderer/vulkan/angle_vulkan_backend/GlslangWrapper.o 
[ 2092s] clang++-10 -MMD -MF obj/third_party/angle/src/libANGLE/renderer/vulkan/angle_vulkan_backend/GlslangWrapper.o.d -DUSE_UDEV -DUSE_AURA=1 -DUSE_GLIB=1 -DUSE_NSS_CERTS=1 -DUSE_X11=1 -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -DNO_UNWIND_TABLES -D_GNU_SOURCE -DCR_CLANG_REVISION=\"373424-64a362e7-1\" -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D_FORTIFY_SOURCE=2 -DNDEBUG -DNVALGRIND -DDYNAMIC_ANNOTATIONS_ENABLED=0 -DANGLE_IS_64_BIT_CPU -DANGLE_ENABLE_VULKAN -DANGLE_USE_CUSTOM_VULKAN_CMD_BUFFERS=1 -DVK_USE_PLATFORM_XCB_KHR -DANGLE_VK_LAYERS_DIR=\"angledata\" -DANGLE_VK_MOCK_ICD_JSON=\"angledata/VkICD_mock_icd.json\" -DANGLE_VK_SWIFTSHADER_ICD_JSON=\"swiftshader/libvk_swiftshader_icd.json\" -DAPI_NAME=\"Vulkan\" -DHAVE_SECURE_GETENV -DENABLE_HLSL=1 -I../../third_party/angle/include -I../../third_party/angle/src -I../../third_party/angle/src/common/third_party/base -Igen/angle -I../../third_party/angle/include -I../../third_party/angle/third_party/vulkan-headers/src/include -I../../third_party/angle/third_party/vulkan-loader/src/loader/generated -I../../third_party/angle/third_party/vulkan-loader/src/loader -I../../third_party/glslang/src -I../../third_party/angle/include -I../../third_party/angle/src -I../../third_party/SPIRV-Tools/src/include -fno-strict-aliasing --param=ssp-buffer-size=4 -fstack-protector -fno-unwind-tables -fno-asynchronous-unwind-tables -fPIC -pthread -fcolor-diagnostics -fmerge-all-constants -fcrash-diagnostics-dir=../../tools/clang/crashreports -Xclang -mllvm -Xclang -instcombine-lower-dbg-declare=0 -m64 -march=x86-64 -Wno-builtin-macro-redefined -D__DATE__= -D__TIME__= -D__TIMESTAMP__= -no-canonical-prefixes -Wall -Wextra -Wimplicit-fallthrough -Wthread-safety -Wextra-semi -Wno-missing-field-initializers -Wno-unused-parameter -Wno-c++11-narrowing -Wno-unneeded-internal-declaration -Wno-undefined-var-template -Wno-ignored-pragma-optimize -O2 -fno-ident -fdata-sections -ffunction-sections -fno-omit-frame-pointer -g0 -fvisibility=hidden -Wheader-hygiene -Wstring-conversion -Wtautological-overlap-compare -Wexit-time-destructors -Wextra-semi-stmt -Wfloat-conversion -Wglobal-constructors -Wnon-virtual-dtor -Wunneeded-internal-declaration -Wparentheses -Wrange-loop-analysis -Wstrict-prototypes -Wunreachable-code -Wshorten-64-to-32 -std=c++14 -fno-exceptions -fno-rtti -fvisibility-inlines-hidden -resource-dir=/usr/lib/llvm-10/lib/clang/10.0.0  -resource-dir=/usr/lib/llvm-10/lib/clang/10.0.0  -resource-dir=/usr/lib/llvm-10/lib/clang/10.0.0  -Wno-pedantic -Wno-unused-result -Wno-unused-function -Wno-unused-variable -Wno-deprecated-declarations  -Wno-return-type -Wno-parentheses -Wno-enum-compare -Wno-dangling-else  -fno-delete-null-pointer-checks -resource-dir=/usr/lib/llvm-10/lib/clang/10.0.0  -Wno-pedantic -Wno-unused-result -Wno-unused-function -Wno-unused-variable -Wno-deprecated-declarations  -Wno-return-type -Wno-parentheses -Wno-enum-compare -Wno-dangling-else  -fno-delete-null-pointer-checks -c ../../third_party/angle/src/libANGLE/renderer/vulkan/GlslangWrapper.cpp -o obj/third_party/angle/src/libANGLE/renderer/vulkan/angle_vulkan_backend/GlslangWrapper.o
[ 2092s] In file included from ../../third_party/angle/src/libANGLE/renderer/vulkan/GlslangWrapper.cpp:18:
[ 2092s] In file included from ../../third_party/glslang/src/SPIRV/GlslangToSpv.h:42:
[ 2092s] In file included from ../../third_party/glslang/src/SPIRV/SpvTools.h:49:
[ 2092s] In file included from ../../third_party/glslang/src/SPIRV/../glslang/MachineIndependent/localintermediate.h:42:
[ 2092s] In file included from ../../third_party/glslang/src/glslang/Public/../MachineIndependent/../Include/intermediate.h:55:
[ 2092s] In file included from ../../third_party/glslang/src/glslang/Public/../Include/../Include/Common.h:108:
[ 2092s] ../../third_party/glslang/src/glslang/Public/../Include/PoolAlloc.h:307:54: error: 'operator=' is a private member of 'glslang::TPoolAllocator'
[ 2092s]     void setAllocator(TPoolAllocator* a) { allocator = *a; }
[ 2092s]                                            ~~~~~~~~~ ^ ~~
[ 2092s] ../../third_party/glslang/src/glslang/Public/../Include/PoolAlloc.h:244:21: note: declared private here
[ 2092s]     TPoolAllocator& operator=(const TPoolAllocator&);  // don't allow assignment operator
[ 2092s]                     ^
[ 2092s] 1 error generated.

from ungoogled-chromium-debian.

There's been a new development with debian's upstream packaging. They have patches to enable building on buster's LLVM 7 so I should be able to make it buildable without needing to enable another repository. This should help greatly with enabling usage of OBS.

from ungoogled-chromium-debian.

@Eloston I have setup a github workflow here that uploads to OBS on pushes. It can't be done for pull requests due to the risk of leaking secrets but it should be a good start for publishing officially initiated builds. I will see about extending it to official tags too.

EDIT: I have managed to get it to work for an experimental tag I published. Whether it'll work with the normal method used to publish a tag I'm not sure yet.

from ungoogled-chromium-debian.

With some more testing it should be possible to close this issue after we know the automated builds are working. They are published here:

Testing releases: https://build.opensuse.org/project/show/home:ungoogled_chromium:testing
Published releases: https://build.opensuse.org/project/show/home:ungoogled_chromium

from ungoogled-chromium-debian.

Yes. I've found some issues with the scripts while trying to start my own PPA. I am trying to get them patched as we speak.

from ungoogled-chromium-debian.

cool, but does PPA support debian?

Would be preferable to have one build service to rule them all, like OBS.
I made an working example (for debian) 1 month ago, in hope that @Eloston could make an official one.

from ungoogled-chromium-debian.

@zrose584 I have noted it, but this is a decently large packaging feature to implement. Also, it isn't a high priority for me.

The biggest problem right now is installing LLVM inside OBS. Switching to GCC is not an immediate option because we'd have to revert all the LLVM-specific changes and add back GCC-specific patches. There is probably a way to get the proper LLVM version in OBS, but I don't know exactly how to do that.

from ungoogled-chromium-debian.

@zrose584, PPAs are only for Ubuntu. But the issues I face there would likely also apply to OBS.

from ungoogled-chromium-debian.

@zrose584, not at all. The issue I've run into is documented in #45.

from ungoogled-chromium-debian.

After switching from clang-10 to clang-9, it worked.

from ungoogled-chromium-debian.

@zrose584 Awesome, thanks for that script. Do you have a complete process that uses that script?

Also, I'd recommend using LLVM 8 for now since that is the newest available in Buster backports. Unless you think there are some benefits in LLVM 9 that are significant enough for use to use apt.llvm.org?

from ungoogled-chromium-debian.

@zrose584 Awesome, thanks for that script. Do you have a complete process that uses that script?

Not sure if I understand your question, but after using updaty.py, all you have to do is run osc commit -m "my_message".
ofc. this requires a working copy of the repo, and the credentials.

Btw, one could consider using an CI to automatically update the obs-repo, when a new tag is published. I did some tests for this a while ago, see .travis.yml. The hook probably should be on this repo though.
The CI would have to authenticate itself (using hidden env variables), clone the obs-repo, call the update.bash script, and then push the changes.
One caveat: One has to tag the commit before pushing it to the GH, otherwise travis.yml is not called.
Interested?

Also, I'd recommend using LLVM 8 for now since that is the newest available in Buster backports. Unless you think there are some benefits in LLVM 9 that are significant enough for use to use apt.llvm.org?

Theoretically llvm-9 should be better than llvm-8, right?
I think the chromium-project is using bleeding-edge llvm-10, so llvm-8 might break faster than llvm-9.
Whats the advantage of using buster-backports instead of apt.llvm.org anyways?

from ungoogled-chromium-debian.

Not sure if I understand your question, but after using updaty.py, all you have to do is run osc commit -m "my_message".

That's also useful to know, but I meant the script for building ungoogled-chromium.

Btw, one could consider using an CI to automatically update the obs-repo, when a new tag is published. I did some tests for this a while ago, see .travis.yml. The hook probably should be on this repo though.
The CI would have to authenticate itself (using hidden env variables), clone the obs-repo, call the update.bash script, and then push the changes.
One caveat: One has to tag the commit before pushing it to the GH, otherwise travis.yml is not called.
Interested?

Sure, it'd be nice to see a specific example.

Whats the advantage of using buster-backports instead of apt.llvm.org anyways?

Fewer entities to trust; buster-backports is built by Debian. Not sure who specifically maintains apt.llvm.org (I think I've seen some people with Google emails signing the binaries IIRC. I still trust them, but IDK about others). Otherwise, it's possible but unlikely that Debian's version integrates a little better with the system.

from ungoogled-chromium-debian.

@Eloston, would it be advisable to create a separate issue for Launchpad PPAs? I found it not too difficult to get it going. I'll see what other issues I find that need to be streamlined. It should benefit any efforts for OBS as well.

from ungoogled-chromium-debian.

but I meant the script for building ungoogled-chromium.

hmm.. the CI could do that, OBS will detect when other packages it depends on are building, and waits for them.

CI

Sure, it'd be nice to see a specific example.

It's actually quite simple, see the new .travis.yml.

Fewer entities to trust; buster-backports is built by Debian.

I think thats an oversimplification. Debian concists out of many small teams. Some teams might do a bad job.

Also there is a trust-chain: the debian-team trusts the llvm-team, so if one trusts the debian-team, one indirectly trusts the llvm-team.

I don't think that the (often small) debian-team (in this case for llvm) scans the whole code for malicious parts. Their job is mainly to make it 'apt-get install'-able, no code review stuff.

I still trust them, but IDK about others

Not trusting llvm because google contributed to it? Nonsense.

Otherwise, it's possible but unlikely that Debian's version integrates a little better with the system.

As long as it's functional, who cares? Btw, man-pages etc. are installed correctly.

As the difference between llvm-8 and llvm-10 increases, it will get more likely that you get problems with llvm-8, but not with llvm-9

@Ryu0
What do you want to make an issue for?
One official build-service should be enough.
Using PPA != having single build-service.

from ungoogled-chromium-debian.

@zrose584, true but OBS has its own problems. I've found launchpad to be fairly easy to use if you already know how to setup Debian style packages. OBS appears to be more complicated to setup, probably due to its more generic design. Either way my work towards a PPA will also fix issues for OBS as far as the build process is concerned.

from ungoogled-chromium-debian.

@Ryu0 We should probably move discussion of PPAs to a new issue.

from ungoogled-chromium-debian.

OBS appears to be more complicated to setup

All one has to understand is that each package is represented by a seperate svc repository, and that osc is basically a wrapper around svc.

@Eloston
If you have any OBS-related questions please just ask them, happy to help.
I think official OBS could be setup in less than 1day, since a working example alredy exists!

Btw, each branch of this repo should get its own package (within the same project).
So one would have ungoogled-chromium-deb10, ungoogled-chromium-bionic, etc.

from ungoogled-chromium-debian.

@Eloston
Did you encountered another problem or didn't you have enough time yet?

from ungoogled-chromium-debian.

@zrose584 I lost interest and I don't have time either. I don't expect to pick this up anytime soon.

from ungoogled-chromium-debian.

@Eloston Hmm.. I see..
What do you think about adding the .travis hook, and I give you the credentials for my OBS account?
You'd only have to add these as hidden enviroment variables (OSC_USER and OSC_PASS).
After that it would automatically rebuild on every new tag you release, assuming you assigned the tag to the commit before you pushed it. Only on debian_buster.

Later, once you found motivation again, you could look at how the OBS project/package is set up, and make your own. I wouldn't mind you experimenting with the OBS project/package.

from ungoogled-chromium-debian.

They have patches to enable building on buster's LLVM 7 so I should be able to make it buildable without needing to enable another repository.

Is using the third-party repo apt.llvm.org reallly that evil in your eyes?
I'd expect a llvm-9 build to perform better than a llvm-7 build.

Also, OBS deployment alredy works (as described above).

I provided:

• a working OBS project for debian10
• .travis hook to automate rebuilding it
• detailed instructions on what @Eloston has to do

Really the problem is that @Eloston has no motivation to put time into this, as he said himself.

from ungoogled-chromium-debian.

No but it does introduce an extra external dependency that can create new maintenance hassles down the road. We already have to rely on Debian for part of the dependencies so I just consider it simpler if we can keep it entirely within their ecosystem. With their official packaging moving to LLVM as well it is now much easier to rely on the LLVM that ships with Buster. I was planning on looking into OBS anyway once I found a solution I liked for it.

from ungoogled-chromium-debian.

Isn't there the risk of llvm-7 support laaging behind their master/sid branch?

They have patches to enable building on buster's LLVM 7

Where can I find them? I only found this, but there must be more, right?

from ungoogled-chromium-debian.

I don't think so since the patches and LLVM 7 packages are provided by Debian themselves. See here: https://salsa.debian.org/chromium-team/chromium/-/blob/master/debian/patches/buster/clang7.patch

from ungoogled-chromium-debian.

Isn't there the risk of llvm-7 support laaging behind their master/sid branch?

Also that LLVM 7 patch looks buster-specific, so unstable probably uses its default version of LLVM. Interesting that the maintainer decided to switch to LLVM for a stable release; maybe it became too tedious to keep maintaing GCC patches.

To expand on what @braewoods mentioned, removing the need to add extra APT repos makes it easier to use automated packaging systems that might not support extra APT repos (e.g. pbuilder, debspawn). Also, it brings us closer to support inclusion in Debian, if we so choose.

from ungoogled-chromium-debian.

Incidentally I also discovered another good reason to stay with the distribution LLVM: support for arm architectures. The LLVM binary repositories only provide i386 and amd64 architecture support. We've had some interest in arm support so this is something I would like to include.

from ungoogled-chromium-debian.

I have managed to start a test build on OBS for Debian Buster. There's issues with getting Ubuntu setup with OBS that I cannot resolve myself so I will see if I can get the administrators to enable the Ports repository I need. Here's the repository link for the buster test:

https://build.opensuse.org/project/show/home:braewoods:ungoogled-chromium:buster

from ungoogled-chromium-debian.

I see you build the debian source package (as described here) and upload that to OBS.
While this woks, I found it quite tedious.
Not sure if you noticed, but my OBS Project uses the the build.script file to directly build the packages.

Besides not having to build the source-package locally, I can see at least 2 more advantages:

• You don't need to upload ~320mb to OBS
• People who care about reproducibility don't have to (somehow) verify the source package themself

What do you think?

from ungoogled-chromium-debian.

Ok. This is definitely an improvement. I think it needs some further work but I didn't know this was an option. I assumed I was going to have to upload a separately prepared tarball for every branch. This should also mean it will be possible to support all supported Debian, Ubuntu, and Arch flavors with one package setup.

Side note, I've been finding the limitations of the PPA system to make OBS worth looking at so I am going to want to move Ubuntu to this somehow too. The main issue I've run into is their Ports repositories do not expose the universe-update repository so the ARM packages do not have access to LLVM 9 at the moment.

Edit: It just occurred to me. How does the build.script know what build environment it is running in? That would be important for using different steps for different distributions.

from ungoogled-chromium-debian.

the ARM packages do not have access to LLVM 9

One solution would be to the mirror (not build!) the relevant packages into a seperate OBS project.
That project will then be used to resolve the missing packages.
The above comment explains how I did that for apt.llvm.org, it should work just the same for ports.ubuntu.com.
If you want I will update the relevant python script to do that.

How does the build.script know what build environment it is running in?

I guess it could just evaluate lsb_release -cs and uname -m
However I see an another problem: When any file is updated, OBS will rebuild for all distributions. So when you push updates for some ubuntu distro, it will also rebuild the debian package.
Unless this (somehow) can be prevented, I think it is a better idea to have separate packages for separate distributions, e.g. ungoogled-chromium-deb10, ungoogled-chromium-bionic, etc.

from ungoogled-chromium-debian.

As it turns out it's enabled on newer Ubuntu repositories on OBS but not 18.04. I've been seeing if I can get it enabled by contacting the admins. If that works out then it's less work for us in the long run.

I think I am going to want to create a setup to generate the files necessary for package checkin for OBS. This seems the best option to handle it in the long run so updates will be less painful. My main consideration then is how we want to distribute the packages. I think one package per branch is probably the right trade-off.

from ungoogled-chromium-debian.

I've been experimenting with a generation script to see how well it works with Sid and Buster as separate packages with the only project repository enabled the one it is intended for. This should give an idea of how feasible this division is. See here:

https://build.opensuse.org/package/show/home:braewoods:ungoogled-chromium/ungoogled-chromium-buster
https://build.opensuse.org/package/show/home:braewoods:ungoogled-chromium/ungoogled-chromium-sid

from ungoogled-chromium-debian.

looks good to me!

With generation script you mean something similar to my update.sh, right?
I think it's a good idea to include such a script in the OBS-repository itself, since this allows for easy integration scripts. Do you plan on using such "update OBS on push with tag" service?

One minor thing: I believe they configured their workers in MB, and not GB, meaning there are workers which have 16000 MB, but not 16GB = 16384 MB.
Also I found 10000MB to be enough. There are actually many lambXY workers which are super fast (2-4x faster build), but only have 10192MB.
For example: osc api /worker/x86_64:lamb74:1
If a worker runs out of memory the error message is quite obvious, so one can easily increase memory requirements as/if needed.

from ungoogled-chromium-debian.

Yes but mine generates the whole template set each time using information from a properly cloned git repository. It outputs to a given directory path so it could be used to regenerate your locally checked out OBS stuff and then you could submit it to OBS using a check in. It automates most of the work except submission to OBS.

from ungoogled-chromium-debian.

Regarding automation it appears that you need the password of the user you are using to create builds, etc, and that there is no other way to authenticate with the service. If this is the case I would suggest we create an account just for this purpose. Then we would need some way to safeguard the access credentials so they don't get leaked out of the automation system.

Of course we could always just make the upload process manual for the last step to avoid this situation but we wouldn't get the full benefits of sending builds to OBS. But at the same time I wouldn't want every change to trigger one either.

from ungoogled-chromium-debian.

Please see what I wrote above..

What do you think about adding the .travis hook [..]
[one has] to add the credentials as hidden enviroment variables (OSC_USER and OSC_PASS).
After that it would automatically rebuild on every new tag you release, assuming you assigned the tag to the commit before you pushed it.

Note that by using this method, only you (and maybe travis-ci.com) can see the credentials.
Also note that the travis hook is only executed if tag IS present

from ungoogled-chromium-debian.

@Eloston I would like to try to setup automatic dispatch to OBS but I don't think I can do that with pull-requests since it seems to require collaborator access. Is there any way I could receive that just for this repository? It would also mean I could approve basic pull-requests.

from ungoogled-chromium-debian.

@braewoods

Is there any way I could receive that just for this repository? It would also mean I could approve basic pull-requests.

Sounds good to me. I just invited you as a collaborator with Maintain access.

from ungoogled-chromium-debian.

@Eloston I discovered I am going to need you to create some secrets to hold the OBS credential secrets. GitHub doesn't allow collaborators to create them. How shall I send the details to you?

from ungoogled-chromium-debian.

@braewoods I'm trying something new so let's move this discussion about repo access and settings to https://github.com/orgs/ungoogled-software/teams/debian. We can also use it as a development forum (somewhat like the use-case for Gitter but hopefully more effective).

EDIT: Just realized it by default hides the entire team from the public. It works for this situation but ideally I'd like to make teams and most discussions publicly visible...

from ungoogled-chromium-debian.

@Eloston Adding to what @braewoods said, I also mentioned before that if we are going to set up some cross repository CI check then an account with write permission to all repos under ungoogled-software will be necessary, so I will suggest create something like a bot account for all CI/auto-build purposes.

BTW I think teams are meant to be only inside an organization so there is no way to make the discussions public.

from ungoogled-chromium-debian.

TIL. The order in which an OBS' project's repository's paths appear changes where packages are picked from first. I had to put the update channels before the standard channels to resolve a build error with Bionic. I went ahead and applied the correct ordering to all these kinds of repositories as I don't think it's a good idea to just leave it at that as I expect it to cause more issues later if left alone.

Also interesting is how all the Debian build environments default to POSIX locale which seems to be responsible for some weird build issues I've been having with Bionic. So I decided to force C.UTF-8 to have a UTF-8 locale for all of them. This is what I do in my test environments so it should be done regardless to reduce the differences that can cause weird build errors.

from ungoogled-chromium-debian.