Gentoo Packages

Search

Install

Install this package:

emerge -a www-apps/gitlab

Package Information

Description:

The gitlab and gitaly parts of the GitLab DevOps platform

Homepage:

https://gitlab.com/gitlab-org/gitlab-foss

License:

MIT

Versions

Metadata

Upstream

• Bugs: https://gitlab.com/gitlab-org/gitlab-foss/-/issues
• Remote IDs:
  • github: gitlab-org/gitlab-foss

<pkgmetadata>
	<use>
		<flag name="favicon">For the Custom Favicon to work, GraphicsMagick needs to be installed</flag>
		<flag name="gitaly_git">Use the Git version provided by Gitaly</flag>
		<flag name="gitlab-config">Config in /opt/gitlab/gitlab/config instead of /etc/gitlab (s. news 2021-02-22-etc-gitlab)</flag>
		<flag name="mail_room">Enables support for GitLab MailRoom</flag>
		<flag name="pages">Pulls in the compatible version of www-apps/gitlab-pages</flag>
		<flag name="prometheus">Enables support for the Prometheus monitoring system</flag>
		<flag name="relative_url">Support for relative url</flag>
	</use>
	<upstream>
		<bugs-to>https://gitlab.com/gitlab-org/gitlab-foss/-/issues</bugs-to>
		<remote-id type="github">gitlab-org/gitlab-foss</remote-id>
	</upstream>
</pkgmetadata>

Lint Warnings

• [Warning] USE flag 'kerberos' in ebuild 19.2.1 is not documented in metadata.xml
• [Warning] USE flag 'systemd' in ebuild 19.2.1 is not documented in metadata.xml
• [Warning] USE flag 'kerberos' in ebuild 19.2.0 is not documented in metadata.xml
• [Warning] USE flag 'systemd' in ebuild 19.2.0 is not documented in metadata.xml
• [Warning] USE flag 'kerberos' in ebuild 19.1.3 is not documented in metadata.xml
• [Warning] USE flag 'systemd' in ebuild 19.1.3 is not documented in metadata.xml
• [Warning] USE flag 'kerberos' in ebuild 19.1.2 is not documented in metadata.xml
• [Warning] USE flag 'systemd' in ebuild 19.1.2 is not documented in metadata.xml
• [Warning] USE flag 'kerberos' in ebuild 19.1.1 is not documented in metadata.xml
• [Warning] USE flag 'systemd' in ebuild 19.1.1 is not documented in metadata.xml
• [Warning] USE flag 'kerberos' in ebuild 19.1.0 is not documented in metadata.xml
• [Warning] USE flag 'systemd' in ebuild 19.1.0 is not documented in metadata.xml
• [Warning] USE flag 'kerberos' in ebuild 19.0.5 is not documented in metadata.xml
• [Warning] USE flag 'systemd' in ebuild 19.0.5 is not documented in metadata.xml
• [Warning] USE flag 'kerberos' in ebuild 19.0.4 is not documented in metadata.xml
• [Warning] USE flag 'systemd' in ebuild 19.0.4 is not documented in metadata.xml
• [Warning] USE flag 'kerberos' in ebuild 19.0.3 is not documented in metadata.xml
• [Warning] USE flag 'systemd' in ebuild 19.0.3 is not documented in metadata.xml
• [Warning] USE flag 'kerberos' in ebuild 19.0.2 is not documented in metadata.xml
• [Warning] USE flag 'systemd' in ebuild 19.0.2 is not documented in metadata.xml
• [Warning] USE flag 'kerberos' in ebuild 19.0.1 is not documented in metadata.xml
• [Warning] USE flag 'systemd' in ebuild 19.0.1 is not documented in metadata.xml
• [Warning] USE flag 'kerberos' in ebuild 19.0.0 is not documented in metadata.xml
• [Warning] USE flag 'systemd' in ebuild 19.0.0 is not documented in metadata.xml
• Bypassing the network sandbox using `RESTRICT="network-sandbox"` violates Gentoo's core packaging policies. Ebuilds must support offline and reproducible builds, meaning all assets must be fetched via `SRC_URI` during the fetch phase and verified using Manifest checksums. To resolve this, you should package the required dependencies (e.g., node modules, cargo crates) into a tarball, host it, reference it in `SRC_URI` and perform an offline installation.
• Bypassing the network sandbox using `RESTRICT="network-sandbox"` violates Gentoo's core packaging policies. Ebuilds must support offline and reproducible builds, meaning all assets must be fetched via `SRC_URI` during the fetch phase and verified using Manifest checksums. To resolve this, you should package the required dependencies (e.g., node modules, cargo crates) into a tarball, host it, reference it in `SRC_URI` and perform an offline installation.
• Bypassing the network sandbox using `RESTRICT="network-sandbox"` violates Gentoo's core packaging policies. Ebuilds must support offline and reproducible builds, meaning all assets must be fetched via `SRC_URI` during the fetch phase and verified using Manifest checksums. To resolve this, you should package the required dependencies (e.g., node modules, cargo crates) into a tarball, host it, reference it in `SRC_URI` and perform an offline installation.
• Bypassing the network sandbox using `RESTRICT="network-sandbox"` violates Gentoo's core packaging policies. Ebuilds must support offline and reproducible builds, meaning all assets must be fetched via `SRC_URI` during the fetch phase and verified using Manifest checksums. To resolve this, you should package the required dependencies (e.g., node modules, cargo crates) into a tarball, host it, reference it in `SRC_URI` and perform an offline installation.
• Bypassing the network sandbox using `RESTRICT="network-sandbox"` violates Gentoo's core packaging policies. Ebuilds must support offline and reproducible builds, meaning all assets must be fetched via `SRC_URI` during the fetch phase and verified using Manifest checksums. To resolve this, you should package the required dependencies (e.g., node modules, cargo crates) into a tarball, host it, reference it in `SRC_URI` and perform an offline installation.
• Bypassing the network sandbox using `RESTRICT="network-sandbox"` violates Gentoo's core packaging policies. Ebuilds must support offline and reproducible builds, meaning all assets must be fetched via `SRC_URI` during the fetch phase and verified using Manifest checksums. To resolve this, you should package the required dependencies (e.g., node modules, cargo crates) into a tarball, host it, reference it in `SRC_URI` and perform an offline installation.
• Bypassing the network sandbox using `RESTRICT="network-sandbox"` violates Gentoo's core packaging policies. Ebuilds must support offline and reproducible builds, meaning all assets must be fetched via `SRC_URI` during the fetch phase and verified using Manifest checksums. To resolve this, you should package the required dependencies (e.g., node modules, cargo crates) into a tarball, host it, reference it in `SRC_URI` and perform an offline installation.
• Bypassing the network sandbox using `RESTRICT="network-sandbox"` violates Gentoo's core packaging policies. Ebuilds must support offline and reproducible builds, meaning all assets must be fetched via `SRC_URI` during the fetch phase and verified using Manifest checksums. To resolve this, you should package the required dependencies (e.g., node modules, cargo crates) into a tarball, host it, reference it in `SRC_URI` and perform an offline installation.
• Bypassing the network sandbox using `RESTRICT="network-sandbox"` violates Gentoo's core packaging policies. Ebuilds must support offline and reproducible builds, meaning all assets must be fetched via `SRC_URI` during the fetch phase and verified using Manifest checksums. To resolve this, you should package the required dependencies (e.g., node modules, cargo crates) into a tarball, host it, reference it in `SRC_URI` and perform an offline installation.
• Bypassing the network sandbox using `RESTRICT="network-sandbox"` violates Gentoo's core packaging policies. Ebuilds must support offline and reproducible builds, meaning all assets must be fetched via `SRC_URI` during the fetch phase and verified using Manifest checksums. To resolve this, you should package the required dependencies (e.g., node modules, cargo crates) into a tarball, host it, reference it in `SRC_URI` and perform an offline installation.
• Bypassing the network sandbox using `RESTRICT="network-sandbox"` violates Gentoo's core packaging policies. Ebuilds must support offline and reproducible builds, meaning all assets must be fetched via `SRC_URI` during the fetch phase and verified using Manifest checksums. To resolve this, you should package the required dependencies (e.g., node modules, cargo crates) into a tarball, host it, reference it in `SRC_URI` and perform an offline installation.
• Bypassing the network sandbox using `RESTRICT="network-sandbox"` violates Gentoo's core packaging policies. Ebuilds must support offline and reproducible builds, meaning all assets must be fetched via `SRC_URI` during the fetch phase and verified using Manifest checksums. To resolve this, you should package the required dependencies (e.g., node modules, cargo crates) into a tarball, host it, reference it in `SRC_URI` and perform an offline installation.
• [Error] Repository is missing a repo-name in metadata/layout.conf or profiles/repo_name
• [Warning] Missing md5-cache for ebuild gitlab-19.2.1
• [Warning] Missing md5-cache for ebuild gitlab-19.2.0
• [Warning] Missing md5-cache for ebuild gitlab-19.1.3
• [Warning] Missing md5-cache for ebuild gitlab-19.1.2
• [Warning] Missing md5-cache for ebuild gitlab-19.1.1
• [Warning] Missing md5-cache for ebuild gitlab-19.1.0
• [Warning] Missing md5-cache for ebuild gitlab-19.0.5
• [Warning] Missing md5-cache for ebuild gitlab-19.0.4
• [Warning] Missing md5-cache for ebuild gitlab-19.0.3
• [Warning] Missing md5-cache for ebuild gitlab-19.0.2
• [Warning] Missing md5-cache for ebuild gitlab-19.0.1
• [Warning] Missing md5-cache for ebuild gitlab-19.0.0
• [Error] Package has no maintainers defined in metadata.xml

USE Flags

Manage flags for this package: euse -i <flag> -p www-apps/gitlab | euse -E <flag> -p www-apps/gitlab | euse -D <flag> -p www-apps/gitlab

Files

• gitlab-19.1.0-pod-markup.patch
• gitlab-fix-checks-gentoo-r1.patch
• gitlab-fix-checks-gentoo.patch
• gitlab-fix-gitlab-shell-check-name.patch
• gitlab-fix-of-gem-version.patch
• gitlab-fix-sendmail-param.patch
• gitlab-fix-sidekiq_check.patch
• gitlab-gitaly.init
• gitlab-gitaly.service
• gitlab-mailroom.service
• gitlab-pod-markup.patch
• gitlab-puma.service
• gitlab-sidekiq.service
• gitlab-tmpfiles.conf
• gitlab-update-config.service
• gitlab-workhorse.service
• gitlab.confd
• gitlab.init
• gitlab.init.mailroom_start
• gitlab.init.mailroom_status
• gitlab.init.mailroom_stop
• gitlab.init.mailroom_vars
• gitlab.init.puma_start
• gitlab.logrotate
• gitlab.slice
• gitlab.target

Manifest