Alternatively we could define it by adding another bdep on more archaic
unmaintained software. But it does nothing...
Signed-off-by: Eli Schwartz <eschwartz93@gmail.com>
Signed-off-by: Sam James <sam@gentoo.org>
* QA Notice: The ebuild is installing to one or more unexpected paths:
*
* /var/tmp/portage/sys-cluster/legion-9999/image/usr/bin/legion_prof_files
* /var/tmp/portage/sys-cluster/legion-9999/image/usr/bin/serializer_examples
*
* Please fix the ebuild to use correct FHS/Gentoo policy paths.
This message is hard to understand. Is it saying that the resulting
package contains files prefixed with ${D} which would be immensely
broken? Is it saying that these paths are *directories* and the FHS does
not approve of directories in /usr/bin/*/?
In fact, it's the latter. Fix this in two ways:
- clarify that it's an unexpected directory, not just some kind of path
- strip ${D} so that people can better visualize what sort of path gets
installed. This has the downside of not being able to copy/paste the
path in order to inspect the image directory, but I think this is a
very small downside. Usually by the time you see this message, portage
has cleaned up. And if it hasn't, you can still copy/paste that from:
Completed installing sys-cluster/legion-9999 into /var/tmp/portage/sys-cluster/legion-9999/image
Signed-off-by: Eli Schwartz <eschwartz93@gmail.com>
Signed-off-by: Sam James <sam@gentoo.org>
It curently uses some magic test to decide whether handcrafted code
works with or without -latomic. But it can claim that -latomic is not
needed for that case, while it is still needed for other cases.
> okay so append-atomic-flags does not work for me in this case
> noise-suppression-for-voice is doing `struct RnNoiseStats { uint32_t a, b, c, d; }; std::atomic<RnNoiseStats> m_stats;`
> not just a single large integer
It is simplest to always add -latomic when an ebuild gets that deep
feeling that yeah, it would like some atomics please. The downsides to
listing a linker library are exactly:
- it might be unavailable
- it might be unneeded
And the former case is trivial to solve -- this function already does so
-- while the latter case has a sanctioned approach that is already used
for other intrinsic compiler libraries, but not for atomic "because the
build system would have a hard time if we had to build atomic early on"
which isn't a very good reason to break ebuilds which aren't building
sys-devel/gcc.
As a side benefit, we now handle -latomic such that a package which
requires it, but only for parts of the installed package, does not
overlink to libatomic in *all* binaries/libraries, even if the default
LDFLAGS are overridden and the global -Wl,--as-needed disappears.
Bug: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81358
Bug: https://bugs.gentoo.org/820101
Bug: https://bugs.gentoo.org/925672
Signed-off-by: Eli Schwartz <eschwartz93@gmail.com>
Signed-off-by: Sam James <sam@gentoo.org>
The (newly available) GH repo does not seem to have anything to
generate version.py (which would rather not risk getting wrong),
and also lacks the Changelog and some other generated docs files.
Then pypi's tarball lack tests.
Bit wasteful but both tarballs are small and combining seems safe
(verified that no changes to installed files, so skipping a safety
revbump to ~testing).
Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
Eli Schwartz
Florian Schmaus
Arthur Zamarin
Michael Mair-Keimberger
Andrew Ammerlaan
Michał Górny
Sam James
Ionen Wolkens
Viorel Munteanu
Ben Kohler
Alfred Wingate