[gentoo-portage-dev] [PATCH] estrip: fix race when creating build-id debug symlinks
Bug: https://bugs.gentoo.org/831927
Closes: https://github.com/gentoo/portage/pull/786
Signed-off-by: Mike Gilbert
---
bin/estrip | 19 ---
1 file changed, 16 insertions(+), 3 deletions(-)
diff --git a/bin/estrip b/bin/estrip
index 599ca2ceb..cdad58c31 100755
--- a/bin/estrip
+++ b/bin/estrip
@@ -189,6 +189,19 @@ save_elf_sources() {
"${x}")
}
+# Try to create a symlink.
+# Return success if it already exists.
+__try_symlink() {
+ local target=$1
+ local name=$2
+ # Check for an existing link before and after in case we are racing
against
+ # another process.
+ [[ -L ${name} ]] ||
+ ln -s "${target}" "${name}" ||
+ [[ -L ${name} ]] ||
+ die "failed to create symlink '${name}'"
+}
+
# Usage: save_elf_debug [splitdebug]
save_elf_debug() {
${FEATURES_splitdebug} || return 0
@@ -245,7 +258,7 @@ save_elf_debug() {
[[ -g ${src} || -u ${src} ]] && args+=",go-r"
chmod ${args} "${dst}"
# symlink so we can read the name back.
- ln -s "${dst}" "${inode_debug}" || die "failed to
create symlink '${inode_debug}'"
+ __try_symlink "${dst}" "${inode_debug}"
# if we don't already have build-id from debugedit,
look it up
if [[ -z ${buildid} ]] ; then
@@ -258,8 +271,8 @@ save_elf_debug() {
local
src_buildid_rel="../../../../../${src#${ED%/}/}"
local
dst_buildid_rel="../../${dst#${ED%/}/usr/lib/debug/}"
mkdir -p "${buildid_dir}" || die
- [[ -L "${buildid_file}".debug ]] || ln -s
"${dst_buildid_rel}" "${buildid_file}.debug" || die "failed to create symlink
'${buildid_file}.debug'"
- [[ -L "${buildid_file}" ]] || ln -s
"${src_buildid_rel}" "${buildid_file}" || die "failed to create symlink
'${buildid_file}'"
+ __try_symlink "${dst_buildid_rel}"
"${buildid_file}.debug"
+ __try_symlink "${src_buildid_rel}"
"${buildid_file}"
fi
fi
fi
--
2.35.1
Re: [gentoo-dev] Unmask >=net-p2p/bitcoin*-0.21.1
On Wed, Feb 2, 2022 at 10:31 AM Joonas Niilola wrote: > > Maybe I'm overthinking it due to all the attention bitcoin has received > lately in Gentoo. But yeah, we haven't received any comments or bugs > about the mask so I guess it's fine to remove it finally. I still kind > of do think a news item wouldn't be the "wrong thing to do" either, but > don't wish to prolong this process any further. > My two cents: bitcoin should work the same as any other package with updates. Any package update could do something you don't want it to do. That's why you have --pretend, and the ability to impose your own masks. Any package can of course issue news but it isn't very typical for packages to issue "release notes" in advance for every single update. Upstream of course often has them, and people who want them can just subscribe to the upstream lists. If somebody isn't interested in following upstream they probably aren't interested in vetting every single release, and I'm guessing that being 2 versions behind on everything is going to cause them and the network more harm than good. If you actually want to participate in some fork of the network I fully support your right to do that, but it shouldn't really be the default behavior of a package (and as I understand it that is basically what happens if you aren't running a version that supports some feature when that feature becomes mandatory/etc). -- Rich
Re: [gentoo-dev] Unmask >=net-p2p/bitcoin*-0.21.1
On 29.1.2022 19.51, Florian Schmaus wrote: > On 25/01/2022 07.49, Joonas Niilola wrote: >> On 24.1.2022 20.37, Florian Schmaus wrote: > > Hi Joonas, > >>> I think it is time to unmask the currently masked Bitcoin versions. The >>> mask was added in Juli of 2021 [1], with the mask's commit message >>> indicating that unmasking is planned for November 2021. >>> >>> I doubt that the mask was ever needed in the first place, as it was >>> intended to prevent automated updates of Bitcoin in Gentoo. However, >>> Gentoo has no unattended upgrade mechanism. Instead, the user explicitly >>> triggers all updates. >>> >>> As this has already caused a little bit of friction, I'd like to get a >>> feeling of the community's view on that. >>> >>> - Flow >>> >>> 1: >>> https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=d0bbc4dcc33927cbf0ca27a054c430f6866ed72e >>> >>> >>> >> >> Publishing a news item 2-4 weeks prior wouldn't cost much for us, I feel >> like just to make sure it'd be the right thing to do. > > I am skeptical that a news item would be the right thing to do > > First, I doubt that the package mask was needed, as I already wrote. > Hence unmasking the package is nothing that the users need to be > notified about. > > Secondly, we never did a news item for Bitcoin in the past, even on > consensus changes. So I want to prevent creating a precedent that puts > us in a position where people expect us to do one for every Bitcoin > protocol consensus change. > > Finally, the news item would state the obvious: Newer software versions > may include changes that you, as a user, may want to review before > upgrading. > > That said, I wouldn't object if someone published one. Please let me > know if you plan to publish one. Otherwise, I would unmask Bitcoin in > one week since no fundamental objections have been raised so far. > > - Flow > > > > Maybe I'm overthinking it due to all the attention bitcoin has received lately in Gentoo. But yeah, we haven't received any comments or bugs about the mask so I guess it's fine to remove it finally. I still kind of do think a news item wouldn't be the "wrong thing to do" either, but don't wish to prolong this process any further. -- juippis OpenPGP_signature Description: OpenPGP digital signature
[gentoo-dev] [PATCH] kernel-build.eclass: add HPPA support
Support HPPA kernel builds.
Notes:
- HPPA 2.0 supports 32-bit and 64-bit kernels (HPPA 2.0 userland remains
32-bit for now as toolchain support isn't there yet for 64-bit).
I've decided to only accommodate 64-bit kernels here unless/until someone
requests & can help figure out an acceptable solution for 32-bit kernels
for HPPA 2.0.
- HPPA 1.x should be fine as there's no need for a cross-compiler there,
unlike HPPA 2.x for 64-bit (sys-devel/kgcc64). It should Just Work,
but not tested.
Not adding a BDEPEND on sys-devel/kgcc64 as it's unclear how to do this
cleanly only for HPPA 2.0.
Tested on RP3440 and C8000.
Signed-off-by: Sam James
---
eclass/kernel-build.eclass | 16 +++-
1 file changed, 15 insertions(+), 1 deletion(-)
diff --git a/eclass/kernel-build.eclass b/eclass/kernel-build.eclass
index 2796493010878..0a49533e48d34 100644
--- a/eclass/kernel-build.eclass
+++ b/eclass/kernel-build.eclass
@@ -1,4 +1,4 @@
-# Copyright 2020-2021 Gentoo Authors
+# Copyright 2020-2022 Gentoo Authors
# Distributed under the terms of the GNU General Public License v2
# @ECLASS: kernel-build.eclass
@@ -52,6 +52,20 @@ BDEPEND="
kernel-build_src_configure() {
debug-print-function ${FUNCNAME} "${@}"
+ if ! tc-is-cross-compiler && use hppa ; then
+ if [[ ${CHOST} == hppa2.0-* ]] ; then
+ # Only hppa2.0 can handle 64-bit anyway.
+ # Right now, hppa2.0 can run both 32-bit and 64-bit
kernels,
+ # but it seems like most people do 64-bit kernels now
+ # (obviously needed for more RAM too).
+
+ # TODO: What if they want a 32-bit kernel?
+ # Not too worried about this case right now.
+ elog "Forcing 64 bit (${CHOST/2.0/64}) build..."
+ export CHOST=${CHOST/2.0/64}
+ fi
+ fi
+
# force ld.bfd if we can find it easily
local LD="$(tc-getLD)"
if type -P "${LD}.bfd" &>/dev/null; then
--
2.35.1
