New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
net-p2p/go-ipfs-bin: add services for openrc & systemd #8857
Conversation
Package-Manager: Portage-2.3.40, Repoman-2.3.9
Package-Manager: Portage-2.3.40, Repoman-2.3.9
Closes: https://bugs.gentoo.org/657804 Package-Manager: Portage-2.3.40, Repoman-2.3.9
Package-Manager: Portage-2.3.24, Repoman-2.3.6
Package-Manager: Portage-2.3.24, Repoman-2.3.6
Provide a proper multi-impl Python support for scons-utils in EAPI 7, to account for new versions of dev-util/scons (3.0.1-r100+, to be committed) that support Python 3 and break SConstruct files using Python 2 constructs. Combining scons-utils with python-any-r1 and python-single-r1 is added retroactively for older EAPIs as well, with fallback to Python 2.7. The new (hard-to-use) API for python-r1 is specific to EAPI 7 since it requires adding explicit BDEPEND. The new use of the eclass is described on the wiki page, along with series of examples covering different use cases: https://wiki.gentoo.org/wiki/Project:Python/scons-utils_integration
This change blocks prior patch removing EAPI=0 support from git-r3. If you really want to keep this live ebuild, please update it to use newer EAPI. Otherwise, removing it would be a better solution.
The code already uses USE dependencies which are not valid for EAPIs 0 and 1. Furthermore, according to qa-reports the eclass is not used in any EAPI older than 4.
Since HTTPS is strongly preferred in git-r3 eclass, there is no point in optimizing it for non-HTTPS use. Therefore, unconditionally depend on dev-vcs/git[curl] rather than verbosely failing when HTTPS is used and the dependency is not satisfied.
Sanitize insopts when calling doins, in order to avoid prior insopts calls accidentally affecting do*/new* functions defined by the eclass.
Sanitize insopts when calling doins, in order to avoid prior insopts calls accidentally affecting do*/new* functions defined by the eclass.
Sanitize exeopts when calling newexe, in order to avoid prior insopts calls accidentally affecting make_wrapper.
Sanitize exeopts when calling doexe, in order to avoid prior insopts calls accidentally affecting do*/new* functions defined by the eclass.
Sanitize insopts/exeopts when calling doins/doexe, in order to avoid prior insopts calls accidentally affecting do*/new* functions defined by the eclass.
Sanitize insopts when calling doins, in order to avoid prior insopts calls accidentally affecting do*/new* functions defined by the eclass.
Sanitize insopts when calling doins, in order to avoid prior insopts calls accidentally affecting do*/new* functions defined by the eclass.
Sanitize insopts when calling doins, in order to avoid prior insopts calls accidentally affecting do*/new* functions defined by the eclass.
Fix the documentation for recently changed cache update functions that no longer rely on their _savelist() counterpart to indicate that.
Package-Manager: Portage-2.3.40, Repoman-2.3.9 Closes: gentoo#8766
Package-Manager: Portage-2.3.40, Repoman-2.3.9
Package-Manager: Portage-2.3.40, Repoman-2.3.9
Package-Manager: Portage-2.3.40, Repoman-2.3.9
Package-Manager: Portage-2.3.40, Repoman-2.3.9
Package-Manager: Portage-2.3.24, Repoman-2.3.6
Package-Manager: Portage-2.3.24, Repoman-2.3.6
Package-Manager: Portage-2.3.24, Repoman-2.3.6
Package-Manager: Portage-2.3.40, Repoman-2.3.9
Closes: https://bugs.gentoo.org/616170 Package-Manager: Portage-2.3.40, Repoman-2.3.9
Closes: https://bugs.gentoo.org/630620 Closes: https://bugs.gentoo.org/648130 Closes: gentoo#8258 Package-Manager: Portage-2.3.40, Repoman-2.3.9
Package-Manager: Portage-2.3.40, Repoman-2.3.9 RepoMan-Options: --include-arches="amd64"
Signed-off-by: Brian Evans <grknight@gentoo.org>
Signed-off-by: Brian Evans <grknight@gentoo.org>
Package-Manager: Portage-2.3.40, Repoman-2.3.9
Package-Manager: Portage-2.3.40, Repoman-2.3.9
Package-Manager: Portage-2.3.40, Repoman-2.3.9
Package-Manager: Portage-2.3.40, Repoman-2.3.9
Notable upstream changes: * all fp32 and fp64 builtins implemented * early support for cl_khr_fp16 builtins * math builtins pass CTS (AMDGCN)^ * CTS complaint sw fma implementation for ASICs that lack ISA support for fma operation ^other than asin
Drop runtime depend on clang. Closes: https://bugs.gentoo.org/603454
It does not allow any of the required video_cards useflags Closes: gentoo#8794
Package-Manager: Portage-2.3.40, Repoman-2.3.9
Package-Manager: Portage-2.3.40, Repoman-2.3.9
Package-Manager: Portage-2.3.40, Repoman-2.3.9 RepoMan-Options: --force
Package-Manager: Portage-2.3.40, Repoman-2.3.9
Package-Manager: Portage-2.3.40, Repoman-2.3.9
Package-Manager: Portage-2.3.40, Repoman-2.3.9
Package-Manager: Portage-2.3.40, Repoman-2.3.9
Package-Manager: Portage-2.3.40, Repoman-2.3.9
Package-Manager: Portage-2.3.40, Repoman-2.3.9
enewgroup ipfs | ||
enewuser ipfs "" "" /var/lib/ipfs ipfs | ||
|
||
su -s /bin/sh -c "ipfs init -e" ipfs |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
better not to perfor such an actioon here but put a note about it
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ok, I will change it. What's the reasoning behind it? If there are something that needs to be done so the program can work correctly, isn't best to do it as soon as possible?
Pull request CI report Report generated at: 2018-06-27 18:55 UTC No issues found |
Closes: https://bugs.gentoo.org/643634
I'm not very sure if this part is correct or no, but seems to work. Also /bin/sh should point to a valid shell, and su should be installed on every system, so I don't think it should gave problems: