[gentoo-dev] [PATCH] xorg-3.eclass: strip -fno-plt from *FLAGS
From: Niklāvs Koļesņikovs <89q1r1...@relay.firefox.com>
As discussed in #778494, the GCC flag -fno-plt will break lazy
binding, which appears to still be necessary for Xorg. Stripping the
offending flag out is the next best solution for reliable user
experience on Gentoo.
Closes: https://bugs.gentoo.org/778494
Closes: https://github.com/gentoo/gentoo/pull/20166
Signed-off-by: Niklāvs Koļesņikovs <89q1r1...@relay.firefox.com>
Signed-off-by: Matt Turner
---
eclass/xorg-3.eclass | 8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/eclass/xorg-3.eclass b/eclass/xorg-3.eclass
index 811168ead98..6835c6617c5 100644
--- a/eclass/xorg-3.eclass
+++ b/eclass/xorg-3.eclass
@@ -1,4 +1,4 @@
-# Copyright 1999-2020 Gentoo Authors
+# Copyright 1999-2021 Gentoo Authors
# Distributed under the terms of the GNU General Public License v2
# @ECLASS: xorg-3.eclass
@@ -326,8 +326,10 @@ xorg-3_flags_setup() {
# Win32 require special define
[[ ${CHOST} == *-winnt* ]] && append-cppflags -DWIN32 -D__STDC__
# hardened ldflags
- [[ ${PN} == xorg-server || ${PN} == xf86-video-* || ${PN} ==
xf86-input-* ]] \
- && append-ldflags -Wl,-z,lazy
+ if [[ ${PN} == xorg-server || ${PN} == xf86-video-* || ${PN} ==
xf86-input-* ]]; then
+ filter-flags -fno-plt
+ append-ldflags -Wl,-z,lazy
+ fi
# Quite few libraries fail on runtime without these:
if has static-libs ${IUSE//+}; then
--
2.26.2
Re: [gentoo-dev] timezone configuration - why copying, not symlinking /etc/localtime ?
On 3/28/2021 05:25, James Le Cuirot wrote:> On Sat, 27 Mar 2021 18:40:52 -0400 Joshua Kinard > wrote: > >> On 3/27/2021 18:16, James Le Cuirot wrote: >>> On Sat, 27 Mar 2021 17:43:34 -0400 Joshua Kinard >>> wrote: >>> I kinda wish the Linux kernel had an ability to partially boot, init the networking subsystem, then fetch an initramfs image over TFTP like it can do with NFS Root. That would solve the problem on my MIPS system(s) (and make install netboots better). I've dug around, but this does not seem to be a capability currently in the kernel, unless I have over looked something. Otherwise in the future, I may just have to setup an initramfs into an NFS Root and teach the SGI's to somehow deal with it. Which all still seems unnecessarily complicated because some other distro thinks it knows what's best for everyone else (but I digress...). >>> >>> NBD may be a slightly simpler alternative and a bit more like an >>> initramfs. nbdkit can do all sorts of weird things. I thought it >>> might have a plugin for cpio archives, allowing you to use a regular >>> initramfs generated by Dracut or similar directly. It doesn't >>> appear to but plugins are quite easy to write. Alternatively you >>> could just extract the initramfs and use nbdkit-linuxdisk-plugin. >> >> Can NBD be used like I described? Never played with it before. The >> MIPS machine has functioning local disk drives, and currently, it >> boots fine by just pulling a kernel off my TFTP server and booting from >> the local drive, no initramfs needed because I compiled everything into >> it. If we ever force sep-usr to end, then I'll need a way to teach it >> to mount /usr before dropping into /bin/init (and nothing else). > > Apologies, I went to experiment with this idea but I'd forgotten that > booting over NBD is not a built-in kernel feature and requires... an > initramfs. NFS looks like the only option with this general approach. I've kinda come to this conclusion myself. I could probably host an extracted, micro-initramfs on my NFS server that would be loaded by the kernel to jump to $REAL_ROOT. Not *too* much of an issue on the Octane, because I can store the kernel command line args in a PROM variable so that all I have to do is type "$foo" at the PROM prompt to load something. But, SGI did their best to be inconsistent, and IP27 systems cannot permanently save variables to NVRAM. Once you power cycle, all user-defined PROM vars are lost. And Linux's NFS Root command args are somewhat complicated from what I remember. Upshot is I boot the IP27 over serial console, so I can just save bootp() args in a text file on my desktop and paste it into the console for those instances. In any event, I kinda wish there was some way to just boot the kernel to a point, have it copy an initramfs image via TFTP, load it, run it, jump to $REAL_ROOT. If I had the time, maybe I could put something together like that myself, but time is not something I have much of right now. > Rich is right though, the initramfs can be tiny. Dracut images are heavy > because they are very flexible and pack a lot of features but none of > that is required. > > The kexec idea would be a nice bonus for you, if it works. Limiting what > kernel features you can enable must be frustrating. My primary kernel image for daily use on the Octane isn't terribly limited. The final vmlinux output is ~39MB, due to loading debugging symbols in. But the cutoff in size for Octane seems to be somewhere around 43-45MB, before the PROM errors out due to no available contiguous FreeMemory() areas (the mem region defined by the ARCS PROM where stuff can be loaded and executed). Netboot kernels for installs can creep up there if you go too crazy on kernel features and pack the netboot with supporting packages (mainly filesystem tools). This already impacts older systems, like SGI Indy, which cannot boot current MIPS netboot images because they have smaller FreeMemory() areas. I thought switching to musl would make the netboots smaller, but that oddly didn't work and musl netboots are about ~2MB larger than the older uclibc-ng versions. And all of my uclibc-ng stages have become unusable for some unknown reason. As soon as you rebuild ncurses in one, all binaries linked to it throws SIGSEGVs (which kills portage). glibc-based netboots are too big and will not load at all, even on the Octane. > It's also worth bearing in mind that you could just generate an image > with Dracut and extract it to a disk partition. That may seem a little > pointless if you're not using something like LVM or encryption but I > don't see the point in separate /usr either. ;) I'm guessing you don't > want to change your partition layout at this point though. No, no LUKS, encryption, btrfs, etc. Just mdraid w/ 0.90 metadata for auto-assemble. Which is why I hate having to use an initramfs for something so simple. Unnecessary
Re: [gentoo-dev] timezone configuration - why copying, not symlinking /etc/localtime ?
On 3/28/2021 16:05, William Hubbs wrote:
> On Sat, Mar 27, 2021 at 10:51:11PM -0400, Joshua Kinard wrote:
>> On 3/27/2021 20:32, William Hubbs wrote:
>>> On Sat, Mar 27, 2021 at 05:43:34PM -0400, Joshua Kinard wrote:
On 3/23/2021 07:31, Rich Freeman wrote:
> On Mon, Mar 22, 2021 at 6:54 PM Andreas K. Huettel
> wrote:
>>
Council decided years ago that we don't support separate /usr without
an initramfs, but we haven't completed that transition yet.
>>>
>>> Which doesn't imply that we deliberately break things.
>>
>> That's right. Though we should at some point start thinking about an end
>> of support for separate usr without initramfs.
>>
>
> Just to clarify - it is already unsupported at a distro level. It is
> just that some individual packages still work with it.
>
> The current Council decisions on the issue are (just providing for
> general reference):
>
> - "Since that particular setup may already be subtly broken today
> depending on the installed software, Council recommends using an
> early boot mount mechanism, e.g. initramfs, to mount /usr if /usr
> is on a separate partition."
> Accepted unanimously. [1]
>
> - "The intention is to eventually not require maintainers to support
> a separate /usr without an early boot mechanism once the Council
> agrees that the necessary docs/migration path is in place."
> Accepted with 4 yes votes, 1 no vote, 2 abstentions. [1]
>
> - "The Council agrees that all preparations for dropping support for
> separate /usr without an initramfs or similar boot mechanism are
> complete. A news item will be prepared, and users will be given one
> month to switch after the news item has been sent."
> Accepted with 5 yes votes, 1 no vote, 1 abstention. [2]
>
> Current policy documentation:
> Developers are not required to support using separate /usr filesystem
> without an initramfs. [3]
>
> 1 - https://projects.gentoo.org/council/meeting-logs/20130813-summary.txt
> 2 - https://projects.gentoo.org/council/meeting-logs/20130924-summary.txt
> 3 - https://projects.gentoo.org/qa/policy-guide/filesystem.html#pg0202
Is there a list of software/ebuilds that currently do this "subtle"
handling
of separate /usr w/o initramfs?
I've got just my MIPS systems left that use a separate /usr and do not boot
with initramfs because I build fully monolithic kernels and that makes the
resulting vmlinux images run up against hard size limits in the SGI PROM
(firmware, BIOS, etc) on these machines if I try to pack too large of an
initramfs in. I can check for any software that may be switched over soon
to a hard initramfs requirement and look at my options.
>>>
>>> One group of packages involved in this is any package that calls
>>> gen_usr_ldscript. We have this function for a couple of reasons.
>>>
>>> Gentoo has a policy that bans *.a static libraries from being
>>> installed in /lib*. I think this policy is unique to Gentoo,
>>> because Most build systems I've seen do not
>>> have separate paths for static vs dynamic libraries, so all libraries
>>> from a package are installed in /usr/lib* or /lib*. This policy was
>>> originally hard coded into portage some time back (I can find the commit
>>> if you want it) before it was made a formal policy by the qa team.
>>> It has since become a formal policy.
>>>
>>> Because of this policy, we have to tell upstream build systems to
>>> install libraries in ${ED}/usr/$(get_libdir). This is fine unless you
>>> have separate usr with no initramfs. In that case, you have binaries on
>>> / that link to shared libraries on /usr. When we saw this happening, we
>>> started manually moving shared libraries from /usr/lib* to /lib* if
>>> someone needed the package at boot time. Then we hit bug 4411 [1]
>>> where the linker was prioritizing static libraries in /usr/lib* over shared
>>> libraries in /lib*.
>>>
>>> I don't know if we tried to address that upstream or not, but ultimately
>>> gen_usr_ldscript came out of it.
>>>
>>> Several folks have wanted to get rid of this function for years [2].
>>>
>>> I have looked into it before, and there are several things that can be done.
>>>
>>> We can have packages that currently build static libraries and
>>> use gen_usr_ldscript stop building static libraries and use the
>>> appropriate setting in their build systems to install libraries in
>>> /$(get_libdir). This is the path OpenRC is taking per request of the qa
>>> lead. The next release will not support the static-libs use flag. This
>>> will actively break anyone who is expecting this use flag to exist for
>>> OpenRC.
>>>
>>> If a package does not build static libraries in the first place, there is
>>> really no reason to call gen_usr_ldscript; the ebuild should be using
>>> the upstream build
[gentoo-dev] Packages up for grabs: x11-misc/piedock
Dear all the following packages are up for grabs after dropping desktop-misc: x11-misc/piedock https://packages.gentoo.org/packages/x11-misc/piedock It does not compile and needs patches. Upstream is informed too. We will have to last rite, if it is not fixed soon. I send in CC to Lars, who committed upstream some time ago. -- Best, Jonas
[gentoo-dev] developing a separate repo spec
Hi all, Is there any interest these days in developing and maintaining a separate repo spec [1]? Among other uses, it would help in describing standardized repo features related to metadata/layout.conf settings allowing devs to reference a single, canonical source in order to support repo/profiles features. The current spec doesn't define many repo specific features leading to people jamming all sorts of conditional features in metadata/layout.conf via profile-formats and other entries, none of which is defined in the current spec. Mostly I'm asking because I'm tired of trying to support a pseudo-spec and am quite close to dropping pkgcore's support for the few profile-formats features it tries to enable. Thanks, Tim [1]: https://bugs.gentoo.org/417013
Re: [gentoo-dev] timezone configuration - why copying, not symlinking /etc/localtime ?
On Sat, Mar 27, 2021 at 10:51:11PM -0400, Joshua Kinard wrote:
> On 3/27/2021 20:32, William Hubbs wrote:
> > On Sat, Mar 27, 2021 at 05:43:34PM -0400, Joshua Kinard wrote:
> >> On 3/23/2021 07:31, Rich Freeman wrote:
> >>> On Mon, Mar 22, 2021 at 6:54 PM Andreas K. Huettel
> >>> wrote:
>
> >> Council decided years ago that we don't support separate /usr without
> >> an initramfs, but we haven't completed that transition yet.
> >
> > Which doesn't imply that we deliberately break things.
>
> That's right. Though we should at some point start thinking about an end
> of support for separate usr without initramfs.
>
> >>>
> >>> Just to clarify - it is already unsupported at a distro level. It is
> >>> just that some individual packages still work with it.
> >>>
> >>> The current Council decisions on the issue are (just providing for
> >>> general reference):
> >>>
> >>> - "Since that particular setup may already be subtly broken today
> >>> depending on the installed software, Council recommends using an
> >>> early boot mount mechanism, e.g. initramfs, to mount /usr if /usr
> >>> is on a separate partition."
> >>> Accepted unanimously. [1]
> >>>
> >>> - "The intention is to eventually not require maintainers to support
> >>> a separate /usr without an early boot mechanism once the Council
> >>> agrees that the necessary docs/migration path is in place."
> >>> Accepted with 4 yes votes, 1 no vote, 2 abstentions. [1]
> >>>
> >>> - "The Council agrees that all preparations for dropping support for
> >>> separate /usr without an initramfs or similar boot mechanism are
> >>> complete. A news item will be prepared, and users will be given one
> >>> month to switch after the news item has been sent."
> >>> Accepted with 5 yes votes, 1 no vote, 1 abstention. [2]
> >>>
> >>> Current policy documentation:
> >>> Developers are not required to support using separate /usr filesystem
> >>> without an initramfs. [3]
> >>>
> >>> 1 - https://projects.gentoo.org/council/meeting-logs/20130813-summary.txt
> >>> 2 - https://projects.gentoo.org/council/meeting-logs/20130924-summary.txt
> >>> 3 - https://projects.gentoo.org/qa/policy-guide/filesystem.html#pg0202
> >>
> >> Is there a list of software/ebuilds that currently do this "subtle"
> >> handling
> >> of separate /usr w/o initramfs?
> >>
> >> I've got just my MIPS systems left that use a separate /usr and do not boot
> >> with initramfs because I build fully monolithic kernels and that makes the
> >> resulting vmlinux images run up against hard size limits in the SGI PROM
> >> (firmware, BIOS, etc) on these machines if I try to pack too large of an
> >> initramfs in. I can check for any software that may be switched over soon
> >> to a hard initramfs requirement and look at my options.
> >
> > One group of packages involved in this is any package that calls
> > gen_usr_ldscript. We have this function for a couple of reasons.
> >
> > Gentoo has a policy that bans *.a static libraries from being
> > installed in /lib*. I think this policy is unique to Gentoo,
> > because Most build systems I've seen do not
> > have separate paths for static vs dynamic libraries, so all libraries
> > from a package are installed in /usr/lib* or /lib*. This policy was
> > originally hard coded into portage some time back (I can find the commit
> > if you want it) before it was made a formal policy by the qa team.
> > It has since become a formal policy.
> >
> > Because of this policy, we have to tell upstream build systems to
> > install libraries in ${ED}/usr/$(get_libdir). This is fine unless you
> > have separate usr with no initramfs. In that case, you have binaries on
> > / that link to shared libraries on /usr. When we saw this happening, we
> > started manually moving shared libraries from /usr/lib* to /lib* if
> > someone needed the package at boot time. Then we hit bug 4411 [1]
> > where the linker was prioritizing static libraries in /usr/lib* over shared
> > libraries in /lib*.
> >
> > I don't know if we tried to address that upstream or not, but ultimately
> > gen_usr_ldscript came out of it.
> >
> > Several folks have wanted to get rid of this function for years [2].
> >
> > I have looked into it before, and there are several things that can be done.
> >
> > We can have packages that currently build static libraries and
> > use gen_usr_ldscript stop building static libraries and use the
> > appropriate setting in their build systems to install libraries in
> > /$(get_libdir). This is the path OpenRC is taking per request of the qa
> > lead. The next release will not support the static-libs use flag. This
> > will actively break anyone who is expecting this use flag to exist for
> > OpenRC.
> >
> > If a package does not build static libraries in the first place, there is
> > really no reason to call gen_usr_ldscript; the ebuild should be using
> > the upstream build system to put the libraries where
Re: [gentoo-dev] [PATCH] autotools.eclass: eclassdoc, cosmetic changes, drop old EAPIs
> On 28 Mar 2021, at 13:46, Ulrich Mueller wrote: > > >>> On Sun, 28 Mar 2021, David Seifert wrote: >> This is just bringing it in line with the rest of the eclass. You know, >> consistency. > > If that's the goal then the patch should update all occurences, though. Well, that was definitely the aim. To avoid any doubt, I don’t feel particularly passionate about which style we use so it was not the main point of this patch. Just copying existing style for consistency. > Especially those where usage is inconsistent within the same line. I’m mobile right now but maybe you could show me what you’re referring to? Thank you! We have review for a reason - to improve - but being vague doesn’t help me do that ;)
Re: [gentoo-dev] [PATCH] autotools.eclass: eclassdoc, cosmetic changes, drop old EAPIs
> On Sun, 28 Mar 2021, David Seifert wrote: > This is just bringing it in line with the rest of the eclass. You know, > consistency. If that's the goal then the patch should update all occurences, though. Especially those where usage is inconsistent within the same line. signature.asc Description: PGP signature
Re: [gentoo-dev] [PATCH] autotools.eclass: eclassdoc, cosmetic changes, drop old EAPIs
Hi,
Thank you for doing this. LGTM modulo a few nits below.
On Sat, 2021-03-27 at 22:21 +, Sam James wrote:
> - if [[ ${EBUILD_PHASE} != "unpack" && ${EBUILD_PHASE} != "prepare" ]];
> then
> - ewarn "QA Warning: running $1 in ${EBUILD_PHASE} phase"
> + if [[ ${EBUILD_PHASE_FUNC} != "src_unpack" && ${EBUILD_PHASE_FUNC} !=
> "src_prepare" ]] ; then
Maybe use 'has' here?
> + eqawarn "Running '${1}' in ${EBUILD_PHASE_FUNC} phase"
> fi
>
>
>
>
>
>
>
>
> if ${missing_ok} && ! type -P ${1} >/dev/null ; then
> - einfo "Skipping '$*' due $1 not installed"
> + einfo "Skipping '$*' because '${1}' not installed"
...is not installed? ;-)
--
Best regards,
Michał Górny
Re: [gentoo-dev] [PATCH] autotools.eclass: eclassdoc, cosmetic changes, drop old EAPIs
On Sat, 2021-03-27 at 22:21 +, Sam James wrote: > (Relatively) significant changes: > * inherit eutils for < EAPI 7 for eqawarn > * mark WANT_AUTO*, AUTOTOOLS_AUTO_DEPEND as @PRE_INHERIT > * convert phase test to EBUILD_PHASE_FUNC > * drop support for < EAPI 5 LGTM
Re: [gentoo-dev] [PATCH] autotools.eclass: eclassdoc, cosmetic changes, drop old EAPIs
On Sun, 2021-03-28 at 10:13 +0200, Ulrich Mueller wrote:
> > > > > > On Sat, 27 Mar 2021, Sam James wrote:
>
> > -if [[ -z ${_AUTOTOOLS_ECLASS} ]]; then
> > +if [[ -z ${_AUTOTOOLS_ECLASS} ]] ; then
>
> This just adds unnecessary noise to the git history. We don't have any
> policy on whitespace before punctuation marks, but the examples in the
> Bash manual don't have whitespace before semicolons. (Several more of
> these changes in the reset of the commit.)
This is just bringing it in line with the rest of the eclass. You know,
consistency.
Re: [gentoo-dev] timezone configuration - why copying, not symlinking /etc/localtime ?
On Sat, 27 Mar 2021 18:40:52 -0400 Joshua Kinard wrote: > On 3/27/2021 18:16, James Le Cuirot wrote: > > On Sat, 27 Mar 2021 17:43:34 -0400 > > Joshua Kinard wrote: > > > >> I kinda wish the Linux kernel had an ability to partially boot, init the > >> networking subsystem, then fetch an initramfs image over TFTP like it can > >> do > >> with NFS Root. That would solve the problem on my MIPS system(s) (and make > >> install netboots better). I've dug around, but this does not seem to be a > >> capability currently in the kernel, unless I have over looked something. > >> > >> Otherwise in the future, I may just have to setup an initramfs into an NFS > >> Root and teach the SGI's to somehow deal with it. Which all still seems > >> unnecessarily complicated because some other distro thinks it knows what's > >> best for everyone else (but I digress...). > > > > NBD may be a slightly simpler alternative and a bit more like an > > initramfs. nbdkit can do all sorts of weird things. I thought it might > > have a plugin for cpio archives, allowing you to use a regular > > initramfs generated by Dracut or similar directly. It doesn't appear to > > but plugins are quite easy to write. Alternatively you could just > > extract the initramfs and use nbdkit-linuxdisk-plugin. > > Can NBD be used like I described? Never played with it before. The MIPS > machine has functioning local disk drives, and currently, it boots fine by > just pulling a kernel off my TFTP server and booting from the local drive, > no initramfs needed because I compiled everything into it. If we ever force > sep-usr to end, then I'll need a way to teach it to mount /usr before > dropping into /bin/init (and nothing else). Apologies, I went to experiment with this idea but I'd forgotten that booting over NBD is not a built-in kernel feature and requires... an initramfs. NFS looks like the only option with this general approach. Rich is right though, the initramfs can be tiny. Dracut images are heavy because they are very flexible and pack a lot of features but none of that is required. The kexec idea would be a nice bonus for you, if it works. Limiting what kernel features you can enable must be frustrating. It's also worth bearing in mind that you could just generate an image with Dracut and extract it to a disk partition. That may seem a little pointless if you're not using something like LVM or encryption but I don't see the point in separate /usr either. ;) I'm guessing you don't want to change your partition layout at this point though. -- James Le Cuirot (chewi) Gentoo Linux Developer pgpAb6gauIo0N.pgp Description: OpenPGP digital signature
Re: [gentoo-dev] [PATCH] autotools.eclass: eclassdoc, cosmetic changes, drop old EAPIs
> On Sat, 27 Mar 2021, Sam James wrote:
> -if [[ -z ${_AUTOTOOLS_ECLASS} ]]; then
> +if [[ -z ${_AUTOTOOLS_ECLASS} ]] ; then
This just adds unnecessary noise to the git history. We don't have any
policy on whitespace before punctuation marks, but the examples in the
Bash manual don't have whitespace before semicolons. (Several more of
these changes in the reset of the commit.)
> - # Subdirs often share a common build dir #529404. If so, we can't
> safely
> + # Subdirs often share a common build dir, bug #529404. If so, we can't
> safely
Long line.
> - if [[ ${EBUILD_PHASE} != "unpack" && ${EBUILD_PHASE} != "prepare" ]];
> then
> - ewarn "QA Warning: running $1 in ${EBUILD_PHASE} phase"
> + if [[ ${EBUILD_PHASE_FUNC} != "src_unpack" && ${EBUILD_PHASE_FUNC} !=
> "src_prepare" ]] ; then
> + eqawarn "Running '${1}' in ${EBUILD_PHASE_FUNC} phase"
What is wrong with checking EBUILD_PHASE?
Ulrich
signature.asc
Description: PGP signature
