Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 650052 - sys-apps/sed[forced-sandbox]: sed can't re-build itself
Summary: sys-apps/sed[forced-sandbox]: sed can't re-build itself
Status: RESOLVED FIXED
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: Current packages (show other bugs)
Hardware: All Linux
: Normal normal (vote)
Assignee: Gentoo's Team for Core System packages
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2018-03-09 19:54 UTC by Nils Freydank
Modified: 2018-03-12 10:10 UTC (History)
0 users

See Also:
Package list:
Runtime testing required: ---


Attachments
build.log (sys-apps:sed-4.4-r1:20180308-141037.log,33.73 KB, text/x-log)
2018-03-09 19:55 UTC, Nils Freydank
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Nils Freydank 2018-03-09 19:54:23 UTC
Hi,

sed should be able to rebuild itself with all possible USE, even the non-default ones.

This is currently not the case.

Reproducible: Always

Steps to Reproduce:
1. USE="forced-sandbox" emerge --oneshot '=sys-apps/sed-4.4-r1'
2. emerge --oneshot sed
Actual Results:  
sed: -e expression #8, char 34: e/r/w commands disabled in sandbox mode

Expected Results:  
normal build without errors
Comment 1 Nils Freydank 2018-03-09 19:55:08 UTC
Created attachment 523190 [details]
build.log
Comment 2 Larry the Git Cow gentoo-dev 2018-03-11 22:37:55 UTC
The bug has been referenced in the following commit(s):

https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=1088728d5541b66d6e572a431ac15d1013f8fc7d

commit 1088728d5541b66d6e572a431ac15d1013f8fc7d
Author:     Mike Frysinger <vapier@gentoo.org>
AuthorDate: 2018-03-11 22:30:04 +0000
Commit:     Mike Frysinger <vapier@gentoo.org>
CommitDate: 2018-03-11 22:36:28 +0000

    sys-apps/sed: use bootstrap logic with USE=forced-sandbox #650052
    
    The build system runs sed scripts that use r (read) commands, so if the
    system version had sandbox enabled, we won't be able to rebuild sed.
    Use the existing bootstrap logic so people can enable/disable this flag
    on the fly w/out wedging their systems.
    
    Bug: https://bugs.gentoo.org/650052

 sys-apps/sed/metadata.xml      | 6 +++++-
 sys-apps/sed/sed-4.4-r1.ebuild | 4 ++--
 2 files changed, 7 insertions(+), 3 deletions(-)

https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=a64fc681cba91934c0ebb96fc7c2312fbcb5cef4

commit a64fc681cba91934c0ebb96fc7c2312fbcb5cef4
Author:     Mike Frysinger <vapier@gentoo.org>
AuthorDate: 2018-03-11 22:24:58 +0000
Commit:     Mike Frysinger <vapier@gentoo.org>
CommitDate: 2018-03-11 22:36:27 +0000

    sys-apps/sed: update bootstrap logic #650052
    
    The bootstrap.sh logic was deleted upstream a while back.  Switch to
    using busybox's sed as a fallback as needed.  This should be good
    enough for most cases, and we can figure out something more if the
    need comes up.
    
    Bug: https://bugs.gentoo.org/650052

 sys-apps/sed/sed-4.2.2.ebuild  | 10 ++++------
 sys-apps/sed/sed-4.3-r1.ebuild | 10 ++++------
 sys-apps/sed/sed-4.4-r1.ebuild | 10 ++++------
 sys-apps/sed/sed-4.4.ebuild    | 10 ++++------
 4 files changed, 16 insertions(+), 24 deletions(-)}
Comment 3 SpanKY gentoo-dev 2018-03-11 22:38:46 UTC
sed can rebuild itself now, but be aware that you're going to run into similar build failures in other packages that use the r command, so you prob don't want to deploy this on your dev system where you compile packages.
Comment 4 Lars Wendler (Polynomial-C) (RETIRED) gentoo-dev 2018-03-12 09:23:41 UTC
  if ! type -p sed > /dev/null || has_version 'sys-apps/sed[forced-sandbox]' ; then

Mike, are you sure this will really help? I mean, even if you have installed sed with forced-sandbox enabled, "type -p sed" will still return 0, no? Shouldn't the has_version check be first here?
Comment 5 Lars Wendler (Polynomial-C) (RETIRED) gentoo-dev 2018-03-12 10:09:03 UTC
Nevermind, too low caffeine level this morning. Thanks for your fix Mike ;)
Comment 6 Nils Freydank 2018-03-12 10:10:38 UTC
Thanks from my side aswell, works fine now.