no longer needed since it can use x86 bootstrap tarball for SLOT=8
Signed-off-by: Volkmar W. Pogatzki <gentoo@pogatzki.net>
Signed-off-by: Miroslav Šulc <fordfrog@gentoo.org>
The .gz and .xz dists are identical in content but the .xz is smaller. Cleanup
config args while here.
Noticed this when reviewing toralf's `sam.txt` for ebuilds w/ possible unwired-up
tests.
Signed-off-by: Sam James <sam@gentoo.org>
I'm porting media-sound/grip's ebuild to meson and it uses pkg-config to
look for cdparanoia. Fedora have the patch I'm adding here to add a .pc file
and it looks like it is upstream, just not in a release.
Unfortunately, cdparanoia doesn't seem to have been migrated to xiph's gitlab.
Signed-off-by: Sam James <sam@gentoo.org>
I cannot tell whether it's still a problem upstream. Too many
catastrophes going on in this codebase right now. Not going to report it
when I have no clue.
Maybe if it could be updated for a better baseline...
Closes: https://bugs.gentoo.org/862720
Signed-off-by: Eli Schwartz <eschwartz93@gmail.com>
Signed-off-by: Sam James <sam@gentoo.org>
I am not fighting with Modern C more than I have to, so just prune this.
The key here is that upstream hdf4 doesn't support it and doesn't want
you using it, because it appears to just be an uplifted copy of netcdf
code. So why not, erm, just use netcdf?
Good question, and this package doesn't have an answer to that. Yeet
these vendored tools into the sunset. No need to rename them to private
copies.
Signed-off-by: Eli Schwartz <eschwartz93@gmail.com>
Signed-off-by: Sam James <sam@gentoo.org>
Ideally I would like to solve this by updating to a new upstream
release. Unfortunately, that has a combination of complications:
- existing patches don't apply
- upstream changed download site
- upstream changed up the codebase quite a bit, and notes:
- XDR is now minimalist internals, and renamed
- lots of internal headers were dropped, which "may cause codebases to
stop compiling, so we are bumping the minor version"
It apparently constitutes a major version.
Surprisingly, porting individual Modern C fixes from upstream is *less*
work.
This message was sponsored by Big Science. Much gratitude. <3
Closes: https://bugs.gentoo.org/874414
Signed-off-by: Eli Schwartz <eschwartz93@gmail.com>
Signed-off-by: Sam James <sam@gentoo.org>
The upstream website is dead. There is a gitlab that seems to contain a
2.0.0 version totally unrelated to the current codebase, but only
release candidates of it.
Signed-off-by: Eli Schwartz <eschwartz93@gmail.com>
Signed-off-by: Sam James <sam@gentoo.org>
autotools is genius software. When you add a flag called
--disable-werror, it isn't actually a flag called --disable-werror. It's
a flag called AC_ARG_ENABLE(werror), which expands "code if argument
was passed on the command line" and "code if argument was not passed on
the command line" blocks. When you say "--disable-werror" all you
actually do is add a formatted help text, which is otherwise totally
ignored by autoconf.
kvazaar had an AC_ARG_ENABLE that defined an
action-if-argument-was-defined-on-the-command-line of nothing, and an
action-if-argument-was-excluded-on-the-command-line of adding -Werror to
CFLAGS.
Back in commit 019c44a86a, this was then
used to work around the default addition of -Werror. Logical.
In the very next release, upstream changed the help text to advertise
the --enable-* form, and switched it to
action-if-argument-was-defined-on-the-command-line of adding -Werror,
action-if-argument-was-excluded-on-the-command-line of nothing.
See:
https://github.com/ultravideo/kvazaar/commit/033bc6bc45b0c6b200a4227208d2fa6263e09166
This naturally meant that passing --disable-werror would add -Werror, in
addition to setting the ignored shell variable enable_werror=no. So for
seven years, we've been building with -Werror. Yay!
During that very version bump, --disable-werror was never removed.
Instead, append-flags was used to add an additional gcc switch back off,
per the redundancy requirements of the Department of Redundancy Department's
required approach to redundantly specifying redundant flags.
This also appears to tickle edge cases in LTO due to libtool dropping
some, but not all flags... sometimes. Leading to LTO being performed
with global -Werror.
Bug: https://bugs.gentoo.org/618434
Closes: https://bugs.gentoo.org/907263
Closes: https://bugs.gentoo.org/924296
Signed-off-by: Eli Schwartz <eschwartz93@gmail.com>
Signed-off-by: Sam James <sam@gentoo.org>
It was applied too late for ./configure. oops.
While we are at it, update the comment. I ended up filing a bug. Was
very iffy on doing so, but 2 days ago, upstream demonstrated signs of
life via committing an update to git:
> spelling fix in man page (from Debian; fixed by Graham Inggs; reported by Petter Reinholdtsen)
Fixes: 3e255fb3f9
Closes: https://bugs.gentoo.org/927483
Signed-off-by: Eli Schwartz <eschwartz93@gmail.com>
Signed-off-by: Sam James <sam@gentoo.org>
See https://www.mail-archive.com/rsync-announce@lists.samba.org/msg00113.html.
"""
The github repos have moved to a new RsyncProject organization. Because
various life events have been monopolizing my time, I reached out to Tridge
(the original author) and he has graciously agreed to get back into rsync
work, along with Paul Mackerras, who was also an early contributor to
rsync. This new team will be working mainly on maintenance tasks, and not
so much on new features. If you want to get involved, feel free to reach
out on the new discord RsyncProject channels.
"""
Signed-off-by: Sam James <sam@gentoo.org>