This is the last release signed by Lasse Collin, the previous signer of xz-utils
releases.
Downgrade to this out of an abundance of caution. We are not aware of any issues
that *specifically* require this.
Note that the Manifest matches dfcc1f271f from
when 5.4.2 was removed from ::gentoo in the past.
Bug: https://bugs.gentoo.org/928134
Signed-off-by: Sam James <sam@gentoo.org>
As per upstream issue, the segfaults are caused die to lxml being linked
against a different libxml2 than xmlsec. This isn't a problem for
package manager installed packages, especially source based installs.
Closes: https://bugs.gentoo.org/927927
Signed-off-by: Patrick McLean <chutzpah@gentoo.org>
The client programs can depend on sasl as well. But we never passed the
relevant options when building with USE=minimal, as is the default on
desktop profiles to avoid building the entire server infrastructure.
This was then detected on the official binhost, producing a totally
invalid package.
Signed-off-by: Eli Schwartz <eschwartz93@gmail.com>
Signed-off-by: Sam James <sam@gentoo.org>
Needed to e.g. pass LTO warning flags through to the linker.
Signed-off-by: Eli Schwartz <eschwartz93@gmail.com>
Signed-off-by: Sam James <sam@gentoo.org>
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>
Ionen Wolkens
Sam James
Zac Medico
Andreas K. Hüttel
Michał Górny
Patrick McLean
Alfred Wingate
Eli Schwartz
Florian Schmaus
Arthur Zamarin
Michael Mair-Keimberger
Andrew Ammerlaan
Viorel Munteanu
Ben Kohler