Re: [gentoo-alt] CLT for Xcode 15 is out
Of you can, sync the tree up (you need commit 39ebcce123). move to var/db/repos/gentoo/sys-devel/binutils-config then run: env CC=/usr/bin/clang ebuild binutils-config-5.1-r6.ebuild digest clean merge clean This should fix the wrapper so you can link again. Do an emerge update on at least binutils-config I guess to be safe. Thanks, Fabian On 20-09-2023 08:39:54 +0200, Fabian Groffen wrote: > OK, it seems we'll need some runtime detection for this one :( > > On 20-09-2023 08:27:55 +0200, Fabian Groffen wrote: > > I think we'd need to know if there is an equivalent, or that they simply > > don't need it any more. I don't remember why it was added any more. > > > > Is this dyld-1015.7 you're seeing? > > > > Thanks, > > Fabian > > > > On 20-09-2023 09:28:57 +0800, WuYiyang wrote: > > > Hi, > > > > > > Good news! There's already a bug [2] ticket about this, and now you have > > > found a > > > workaround. > > > > > > [2] https://bugs.gentoo.org/910277 > > > > > > On Tue, Sep 19, 2023 at 07:07:43PM +, Askar Bektassov wrote: > > > > Hey folks, > > > > > > > > After upgrading to command line tools for Xcode 15 on macOS, the linker > > > > started complaining that -sdk_version option is not recognized, which > > > > apparently has been dropped in the last iteration of the linker and yet > > > > it is still called by the ldwrapper. > > > > > > > > In my case, I found this immediate workaround [1] which essentially > > > > requires re emerging the binutils-config, while telling it to add the > > > > -ld64 option in the ldwrapper, which in turn will ensure that the “old > > > > version” of the linker is used. It is not elegant, nor definitive > > > > solution… but this is just until our super maintainers figure out what > > > > other options should passed to the new ld instead. > > > > > > > > Also, I am attaching the patch I used with > > > > sys-devel/binutils-config-5.1-r5 > > > > > > > >  > > > > > > > > [1] https://youtrack.jetbrains.com/issue/KT-60230 > > > > -- > > > > Askar Bektassov (Аскар Бектасов) > > > > Sent from desktop > > > > > > > > > > Best, > > > Yiyang Wu > > > > > > > -- > > Fabian Groffen > > Gentoo on a different level > > > > -- > Fabian Groffen > Gentoo on a different level -- Fabian Groffen Gentoo on a different level signature.asc Description: PGP signature
Re: [gentoo-alt] CLT for Xcode 15 is out
OK, it seems we'll need some runtime detection for this one :( On 20-09-2023 08:27:55 +0200, Fabian Groffen wrote: > I think we'd need to know if there is an equivalent, or that they simply > don't need it any more. I don't remember why it was added any more. > > Is this dyld-1015.7 you're seeing? > > Thanks, > Fabian > > On 20-09-2023 09:28:57 +0800, WuYiyang wrote: > > Hi, > > > > Good news! There's already a bug [2] ticket about this, and now you have > > found a > > workaround. > > > > [2] https://bugs.gentoo.org/910277 > > > > On Tue, Sep 19, 2023 at 07:07:43PM +, Askar Bektassov wrote: > > > Hey folks, > > > > > > After upgrading to command line tools for Xcode 15 on macOS, the linker > > > started complaining that -sdk_version option is not recognized, which > > > apparently has been dropped in the last iteration of the linker and yet > > > it is still called by the ldwrapper. > > > > > > In my case, I found this immediate workaround [1] which essentially > > > requires re emerging the binutils-config, while telling it to add the > > > -ld64 option in the ldwrapper, which in turn will ensure that the “old > > > version” of the linker is used. It is not elegant, nor definitive > > > solution… but this is just until our super maintainers figure out what > > > other options should passed to the new ld instead. > > > > > > Also, I am attaching the patch I used with > > > sys-devel/binutils-config-5.1-r5 > > > > > >  > > > > > > [1] https://youtrack.jetbrains.com/issue/KT-60230 > > > -- > > > Askar Bektassov (Аскар Бектасов) > > > Sent from desktop > > > > > > > Best, > > Yiyang Wu > > > > -- > Fabian Groffen > Gentoo on a different level -- Fabian Groffen Gentoo on a different level signature.asc Description: PGP signature
Re: [gentoo-alt] CLT for Xcode 15 is out
I think we'd need to know if there is an equivalent, or that they simply don't need it any more. I don't remember why it was added any more. Is this dyld-1015.7 you're seeing? Thanks, Fabian On 20-09-2023 09:28:57 +0800, WuYiyang wrote: > Hi, > > Good news! There's already a bug [2] ticket about this, and now you have > found a > workaround. > > [2] https://bugs.gentoo.org/910277 > > On Tue, Sep 19, 2023 at 07:07:43PM +, Askar Bektassov wrote: > > Hey folks, > > > > After upgrading to command line tools for Xcode 15 on macOS, the linker > > started complaining that -sdk_version option is not recognized, which > > apparently has been dropped in the last iteration of the linker and yet it > > is still called by the ldwrapper. > > > > In my case, I found this immediate workaround [1] which essentially > > requires re emerging the binutils-config, while telling it to add the -ld64 > > option in the ldwrapper, which in turn will ensure that the “old version” > > of the linker is used. It is not elegant, nor definitive solution… but this > > is just until our super maintainers figure out what other options should > > passed to the new ld instead. > > > > Also, I am attaching the patch I used with sys-devel/binutils-config-5.1-r5 > > > >  > > > > [1] https://youtrack.jetbrains.com/issue/KT-60230 > > -- > > Askar Bektassov (Аскар Бектасов) > > Sent from desktop > > > > Best, > Yiyang Wu > -- Fabian Groffen Gentoo on a different level signature.asc Description: PGP signature
Re: [gentoo-alt] Porposal on binary based RAP bootstrap using stage3 tarball
On 22-07-2023 12:53:57 +0200, Fabian Groffen wrote: > On 22-07-2023 14:38:59 +0800, Yiyang Wu wrote: > > Hi Fabian, > > > > Glad you are also interested in this direction! > > > > On Sat, Jul 22, 2023 at 08:09:57AM +0200, Fabian Groffen wrote: > > > Hi! > > > > > > This is indeed the way to go, in order to skip a lot of the complexities > > > of Prefix bootstrap. > > > > > > chpathtool indeed worked for a lot of packages, and particularly when > > > everything is emerged afterwards, any inconsistencies or problems will > > > be wiped away. > > > > Right. The only problem is chpathtool requires a working portage (or at > > least > > python). That means whether you need a working prefix or a successful stage > > 1 > > bootstrap. My script [1] can depend only on bash, coreutils and sed, which > > doesn't require the stage 1 bootstrap. > > I once wrote a C-version, that one could simply be run standalone. But > as I suggested below, you actually don't need this if you are willing to > accept a path like /var/tmp/ to always exist. The C-version right before it was removed from the tree (just in case it's of any use) https://gitweb.gentoo.org/proj/portage.git/tree/src/chpathtool.c?h=prefix=3fcce02f31976dcc8f40b350288f81b648955597 Thanks, Fabian > > > > The bootstrap currently works by using a temporary location, and then > > > cross-prefix merging into the final destination. The temporary > > > location could be an unpacked tar, in e.g. > > > > That is also a good idea -- instead of emerge -e @system in-place, the user > > can > > extract the tarball into a temp location. I think both in-place emerge and > > cross-magic is OK. > > Right. Exactly that. You just need tar and a compressor (we can offer > zlib, bz2 and xz compressed versions, current bootstrap-prefix script > magic already has code for picking whatever best is possible). > > > > /var/tmp/gentoo-prefix-installer which will be a path available on > > > nearly any machine, and won't even require chpathtooling, the > > > cross-magic will do its thing to populate the final Prefix. > > > > Yes, but there's always strange system on the world, e.g. Android. One sure > > thing is the user has at least one writable location with finite path > > length, so > > it would 100% success if the gentoo-prefix-installer can change its prefix. > > Yes, and with the standalone tool, you could actually run this over the > entire unpacked tarball whenever this indeed is not the location it > prefers. If my memory serves well, it even had a mode in which it > recursed over a directory. > > > > I once had an idea to bootstrap using binpkgs, e.g. by providing a > > > static build of portage-utils, such that qmerge could be used to create > > > this temporary location prefix. However thinking about it, it is > > > probably just a lot more complicated, even though it would mean the > > > current logic of installing packages one by one could be kept. I think > > > starting from stage3 (bootstrap-prefix.sh's stage3) by unpacking what > > > was the result of stage2 would be easier. > > > > Agreed that static build of portage-utils is more complex. Whether starting > > from > > unpacked stage 2 or unpacked stage 3, I does not now which one is better. > > Portage-utils would require a tree, plus, it doesn't have the guts yet > to do proper dependency calculation, so it's out of the equation for > now. > > > > Question though, with Linux, is the host, how much do you need to know > > > about the kernel and libc, as the stage2 will be still using parts of > > > it, I think? Should we try and build a staticly linked stage perhaps? > > > > > > > As I understand, after stage 3, it has nothing to do with the host's > > userspace, > > just depend on the Linux kernel. A 3.2+ kernel would be enough to install > > the > > most up-to-date glibc [2] for amd64/arm64/x86/riscv/ppc64le. > > Sure, but that means a 2.6 kernel needs a different install/stage. That > was what I was after. > > Thanks, > Fabian > > > > > > Thanks, > > > Fabian > > > > Thanks, > > Yiyang > > > > [1] https://github.com/littlewu2508/migrate-prefix > > [2] > > https://gitweb.gentoo.org/repo/gentoo.git/tree/profiles/default/linux/amd64/23.0/no-multilib/prefix > > -- > Fabian Groffen > Gentoo on a different level -- Fabian Groffen Gentoo on a different level signature.asc Description: PGP signature
Re: [gentoo-alt] Porposal on binary based RAP bootstrap using stage3 tarball
On 22-07-2023 14:38:59 +0800, Yiyang Wu wrote: > Hi Fabian, > > Glad you are also interested in this direction! > > On Sat, Jul 22, 2023 at 08:09:57AM +0200, Fabian Groffen wrote: > > Hi! > > > > This is indeed the way to go, in order to skip a lot of the complexities > > of Prefix bootstrap. > > > > chpathtool indeed worked for a lot of packages, and particularly when > > everything is emerged afterwards, any inconsistencies or problems will > > be wiped away. > > Right. The only problem is chpathtool requires a working portage (or at least > python). That means whether you need a working prefix or a successful stage 1 > bootstrap. My script [1] can depend only on bash, coreutils and sed, which > doesn't require the stage 1 bootstrap. I once wrote a C-version, that one could simply be run standalone. But as I suggested below, you actually don't need this if you are willing to accept a path like /var/tmp/ to always exist. > > The bootstrap currently works by using a temporary location, and then > > cross-prefix merging into the final destination. The temporary > > location could be an unpacked tar, in e.g. > > That is also a good idea -- instead of emerge -e @system in-place, the user > can > extract the tarball into a temp location. I think both in-place emerge and > cross-magic is OK. Right. Exactly that. You just need tar and a compressor (we can offer zlib, bz2 and xz compressed versions, current bootstrap-prefix script magic already has code for picking whatever best is possible). > > /var/tmp/gentoo-prefix-installer which will be a path available on > > nearly any machine, and won't even require chpathtooling, the > > cross-magic will do its thing to populate the final Prefix. > > Yes, but there's always strange system on the world, e.g. Android. One sure > thing is the user has at least one writable location with finite path length, > so > it would 100% success if the gentoo-prefix-installer can change its prefix. Yes, and with the standalone tool, you could actually run this over the entire unpacked tarball whenever this indeed is not the location it prefers. If my memory serves well, it even had a mode in which it recursed over a directory. > > I once had an idea to bootstrap using binpkgs, e.g. by providing a > > static build of portage-utils, such that qmerge could be used to create > > this temporary location prefix. However thinking about it, it is > > probably just a lot more complicated, even though it would mean the > > current logic of installing packages one by one could be kept. I think > > starting from stage3 (bootstrap-prefix.sh's stage3) by unpacking what > > was the result of stage2 would be easier. > > Agreed that static build of portage-utils is more complex. Whether starting > from > unpacked stage 2 or unpacked stage 3, I does not now which one is better. Portage-utils would require a tree, plus, it doesn't have the guts yet to do proper dependency calculation, so it's out of the equation for now. > > Question though, with Linux, is the host, how much do you need to know > > about the kernel and libc, as the stage2 will be still using parts of > > it, I think? Should we try and build a staticly linked stage perhaps? > > > > As I understand, after stage 3, it has nothing to do with the host's > userspace, > just depend on the Linux kernel. A 3.2+ kernel would be enough to install the > most up-to-date glibc [2] for amd64/arm64/x86/riscv/ppc64le. Sure, but that means a 2.6 kernel needs a different install/stage. That was what I was after. Thanks, Fabian > > > Thanks, > > Fabian > > Thanks, > Yiyang > > [1] https://github.com/littlewu2508/migrate-prefix > [2] > https://gitweb.gentoo.org/repo/gentoo.git/tree/profiles/default/linux/amd64/23.0/no-multilib/prefix -- Fabian Groffen Gentoo on a different level signature.asc Description: PGP signature
Re: [gentoo-alt] Porposal on binary based RAP bootstrap using stage3 tarball
n't be a > problem for users who want to use prefix. > > So, what do you think :) > > Best, > Yiyang Wu > > [1] https://groups.google.com/g/xidian_linux/c/kk1eKQy-g44/m/xLK1S3WfNrAJ > [2] https://github.com/littlewu2508/migrate-prefix > [3] > https://archives.gentoo.org/gentoo-alt/message/70af7338f80498a4398c7ca94af3f018 > [4] > https://github.com/gentoo/portage/blob/f228252f4b4c3b33ff1e199f55bec9a6a104b80c/bin/chpathtool.py > [4] https://gitweb.gentoo.org/proj/portage.git/tree/bin/chpathtool.py > [5] https://github.com/gentoo/gentoo/pull/28851 > [6] > https://archives.gentoo.org/gentoo-dev/message/ebfaecd19edac44df726acd2d79e8562 > [7] https://bugs.gentoo.org/buglist.cgi?quicksearch=prefix%20bootstrap > -- Fabian Groffen Gentoo on a different level signature.asc Description: PGP signature
Re: [gentoo-alt] Command Line Tools for Xcode 14.3.1
_groupfile authz_host authz_owner > authz_user autoindex cache cgi cgid dav dav_fs dav_lock deflate dir disk_cache > env expires ext_filter file_cache filter headers include info log_config logio > mem_cache mime mime_magic negotiation rewrite setenvif speling status > unique_id > userdir usertrack vhost_alias" CALLIGRA_FEATURES="karbon sheets words" > COLLECTD_PLUGINS="df interface irq load memory rrdtool swap syslog" > ELIBC="Darwin" GPSD_PROTOCOLS="ashtech aivdm earthmate evermore fv18 garmin > garmintxt gpsclock greis isync itrax mtk3301 nmea ntrip navcom oceanserver > oldstyle oncore rtcm104v2 rtcm104v3 sirf skytraq superstar2 timing tsip > tripmate > tnt ublox ubx" INPUT_DEVICES="libinput" KERNEL="Darwin" LCD_DEVICES="bayrad > cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" > LIBREOFFICE_EXTENSIONS="presenter-console presenter-minimizer" > LUA_SINGLE_TARGET="lua5-1" LUA_TARGETS="lua5-1" > OFFICE_IMPLEMENTATION="libreoffice" PHP_TARGETS="php7-4 php8-0" > POSTGRES_TARGETS="postgres12 postgres13" PYTHON_SINGLE_TARGET="python3_11" > PYTHON_TARGETS="python3_11" RUBY_TARGETS="ruby32" XTABLES_ADDONS="quota2 psd > pknock lscan length2 ipv4options ipset ipp2p iface geoip fuzzy condition tee > tarpit sysrq proto steal rawnat logmark ipmark dhcpmac delude chaos account" > Unset: ADDR2LINE, AR, ARFLAGS, AS, ASFLAGS, CC, CCLD, CPP, CPPFLAGS, CTARGET, > CXX, CXXFILT, ELFEDIT, EMERGE_DEFAULT_OPTS, EXTRA_ECONF, F77FLAGS, FC, GCOV, > GPROF, INSTALL_MASK, LANG, LC_ALL, LD, LFLAGS, LIBTOOL, LINGUAS, MAKE, > MAKEFLAGS, NM, OBJCOPY, OBJDUMP, PORTAGE_BINHOST, PORTAGE_BUNZIP2_COMMAND, > PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS, RANLIB, > READELF, RUSTFLAGS, SIZE, STRINGS, STRIP, YACC, YFLAGS > -- > Askar Bektassov (Аскар Бектасов) > Sent from desktop > -- Fabian Groffen Gentoo on a different level signature.asc Description: PGP signature
Re: [gentoo-alt] What happened?
Hi Askar,
On 24-02-2023 21:23:24 +, Askar Bektassov wrote:
> Hey Fabian,
>
> All correct. Tinkering with my M1 Pro MacBook Pro. Indeed, I assumed you did
> some hacks with keywords, but definitely your solution is the most elegant
> one.
>
> Now everything is back, like charm… although I suspect I have to recompile
> some
> packages because they broke after gcc recompile. Any idea how I could identify
> quickly which packages should be recompiled to fix dylib references?
I noticed those myself too, it was just a few though, so I manually
recompiled as soon as I ran into them. But it's all C++-related, so
grep libstdc++ $EPREFIX/var/db/pkg/*/*/NEEDED.MACHO.3
should give you a list, I guess you can narrow down into, by using
scanmacho -r on the binaries from those matches, if they reference
gcc/arm64-apple-darwin21/12.2.0, you'll need to rebuild.
Something like
% grep -l libstdc++ $EPREFIX/var/db/pkg/*/*/NEEDED.MACHO.3 | sed
"s:${EPREFIX}/var/db/pkg/::" | cut -d/ -f1,2 | xargs qlist -o | grep '/bin/' |
xargs scanmacho -BF '%F|%r' | grep "gcc/arm64-apple-darwin21/12.2.0" | cut
-d'|' -f1 | xargs qfile | cut -d: -f1 | sort -u
(you could use that in emerge -1av `...` I guess :))
Fabian
>
> Thanks for the usual flash support,
> --
> Askar Bektassov (Аскар Бектасов)
> Sent from desktop
>
> On 24 Feb 2023, at 08:23, Fabian Groffen wrote:
>
> Hi Askar,
>
> Given that you reference dylib and MBP, I assume you are running on a
> Mac, and possibly an Apple M1. For the latter, for QA reasons, I had
> to
> remove a hack I did to provide keywords for arm64-macos.
>
> It is easiest to "revert" this change by adding a file
> EPREFIX/etc/portage/make.conf/0900_local.conf with contents:
>
> ACCEPT_KEYWORDS="~x64-macos"
>
> Then all keywords you previously had, should be back.
>
> Thanks,
> Fabian
>
> On 23-02-2023 21:47:03 +, Askar Bektassov wrote:
> Folks,
>
> After the last eix-sync, and emerge world -uDNpv (I think
> gcc has been rebuilt)
> my whole prefix broke, or at least seems so.
>
> All packages installed now are either masked or unknown.
>
> askarbektassov@Askars-MBP ~ $ eix -cI
> [?] acct-group/man (0-r1@10/27/22 -> ??): System group: man
> [?] acct-user/man (1-r1@10/27/22 -> ??): System user: man
> [?] app-admin/eselect (1.4.20@10/27/22 -> ??): Gentoo's
> multi-purpose
> configuration and management tool
> [?] app-admin/perl-cleaner (2.30-r1@01/03/23 -> ??): User
> land tool for cleaning
> up old perl installs
> [?] app-alternatives/awk (4@01/03/23 -> ??): /bin/awk and /
> usr/bin/awk symlinks
> [?] app-alternatives/bzip2 (1@01/03/23 -> ??): bzip2 symlink
> [?] app-alternatives/cpio (0@12/11/22 -> ??): CPIO symlink
> [?] app-alternatives/gzip (0@12/06/22 -> ??): gzip symlinks
> [?] app-alternatives/lex (0-r1@12/11/22 -> ??): lex symlinks
> [?] app-alternatives/sh (0@01/03/23 -> ??): /bin/sh (POSIX
> shell) symlink
> [?] app-alternatives/tar (0@12/06/22 -> ??): Tar symlink
> [?] app-alternatives/yacc (1-r2@12/06/22 -> ??): yacc
> symlinks
> [I] app-arch/bzip2 (1.0.8-r4(0/1)@01/03/23): A high-quality
> data compressor used
> extensively by Gentoo Linux
> [?] app-arch/cpio (2.13-r5@01/03/23 -> ??): A file archival
> tool which can also
> read and write tar files
> [?] app-arch/gzip (1.12-r4@01/20/23 -> ??): Standard GNU
> compressor
> [?] app-arch/libarchive (3.6.1-r1(0/13)@12/06/22 -> ??):
> Multi-format archive
> and compression library
> [?] app-arch/rpm2targz (2021.03.16@10/05/22 -> ??): Convert
> a .rpm file to a
> .tar.gz archive
>
> And the list goes on… the first thing I noticed, is that git
> was not connecting
> and man stopped working…
>
> askarbektassov@Askars-MBP ~/Documents/Books/SDS/github/
> A5kar.github.io (main) $
> man git
> man: command exited with status 134: (cd /Users/
> askarbektassov/Gentoo/usr/share/
> man && /Users/askarbektassov/Gentoo/usr/libexec/man-db/
> zsoelim) | (cd /Users/
> askarbektassov/Gentoo/usr/share/man && /Users/
> askarbektassov/Gentoo/usr/libexec/
> man-db/manconv -f UTF-8:ISO-88
Re: [gentoo-alt] What happened?
Hi Askar, Given that you reference dylib and MBP, I assume you are running on a Mac, and possibly an Apple M1. For the latter, for QA reasons, I had to remove a hack I did to provide keywords for arm64-macos. It is easiest to "revert" this change by adding a file EPREFIX/etc/portage/make.conf/0900_local.conf with contents: ACCEPT_KEYWORDS="~x64-macos" Then all keywords you previously had, should be back. Thanks, Fabian On 23-02-2023 21:47:03 +, Askar Bektassov wrote: > Folks, > > After the last eix-sync, and emerge world -uDNpv (I think gcc has been > rebuilt) > my whole prefix broke, or at least seems so. > > All packages installed now are either masked or unknown. > > askarbektassov@Askars-MBP ~ $ eix -cI > [?] acct-group/man (0-r1@10/27/22 -> ??): System group: man > [?] acct-user/man (1-r1@10/27/22 -> ??): System user: man > [?] app-admin/eselect (1.4.20@10/27/22 -> ??): Gentoo's multi-purpose > configuration and management tool > [?] app-admin/perl-cleaner (2.30-r1@01/03/23 -> ??): User land tool for > cleaning > up old perl installs > [?] app-alternatives/awk (4@01/03/23 -> ??): /bin/awk and /usr/bin/awk > symlinks > [?] app-alternatives/bzip2 (1@01/03/23 -> ??): bzip2 symlink > [?] app-alternatives/cpio (0@12/11/22 -> ??): CPIO symlink > [?] app-alternatives/gzip (0@12/06/22 -> ??): gzip symlinks > [?] app-alternatives/lex (0-r1@12/11/22 -> ??): lex symlinks > [?] app-alternatives/sh (0@01/03/23 -> ??): /bin/sh (POSIX shell) symlink > [?] app-alternatives/tar (0@12/06/22 -> ??): Tar symlink > [?] app-alternatives/yacc (1-r2@12/06/22 -> ??): yacc symlinks > [I] app-arch/bzip2 (1.0.8-r4(0/1)@01/03/23): A high-quality data compressor > used > extensively by Gentoo Linux > [?] app-arch/cpio (2.13-r5@01/03/23 -> ??): A file archival tool which can > also > read and write tar files > [?] app-arch/gzip (1.12-r4@01/20/23 -> ??): Standard GNU compressor > [?] app-arch/libarchive (3.6.1-r1(0/13)@12/06/22 -> ??): Multi-format archive > and compression library > [?] app-arch/rpm2targz (2021.03.16@10/05/22 -> ??): Convert a .rpm file to a > .tar.gz archive > > And the list goes on… the first thing I noticed, is that git was not > connecting > and man stopped working… > > askarbektassov@Askars-MBP ~/Documents/Books/SDS/github/A5kar.github.io (main) > $ > man git > man: command exited with status 134: (cd > /Users/askarbektassov/Gentoo/usr/share/ > man && /Users/askarbektassov/Gentoo/usr/libexec/man-db/zsoelim) | (cd /Users/ > askarbektassov/Gentoo/usr/share/man && > /Users/askarbektassov/Gentoo/usr/libexec/ > man-db/manconv -f UTF-8:ISO-8859-1 -t UTF-8//IGNORE) | (cd /Users/ > askarbektassov/Gentoo/usr/share/man && preconv -e UTF-8) | (cd /Users/ > askarbektassov/Gentoo/usr/share/man && tbl) | (cd > /Users/askarbektassov/Gentoo/ > usr/share/man && nroff -mandoc -c -rLL=157n -rLT=157n -Tutf8) > > But then, even eix did not work, until I’ve added it to accept_keywords list > and > recompiled it (I guess it lost some dylib links, with the gcc recompile). > > But for the rest… what happened? > > Thanks, > -- > Askar Bektassov (Аскар Бектасов) > Sent from desktop > -- Fabian Groffen Gentoo on a different level signature.asc Description: PGP signature
Re: [gentoo-alt] cpudetection USE flag for gmp
On 06-12-2022 10:56:28 +, Sam James wrote: > > On 5 Dec 2022, at 17:40, Askar Bektassov wrote: > > > > Hey folks, > > > > Any idea how to address below the thing below on MacOS apple chip? > > > > From last week, apparently I have to activate cpudetection USE flag for > > gmp, but even if I do so… I am not sure which chip should I select for > > Apple M1. > > > > Thanks in advance, > > > > > > Thanks, this should be resolved by > https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=7ef68af1ef637e90f9ffdda8f8fceacf394e1c6b. Indeed, this is the correct fix, the flag shouldn't be enabled (for now). I did this locally already to test, and everything is ok with it. Thanks, Fabian -- Fabian Groffen Gentoo on a different level signature.asc Description: PGP signature
Re: [gentoo-alt] [RFC] build some more deps before stage3 main show
I think adding those two packages at that stage is fine. Thanks, Fabian On 06-12-2022 10:58:03 +, Sam James wrote: > > > > On 18 Aug 2022, at 03:22, Etienne Buira wrote: > > > > On Thu, Aug 18, 2022 at 01:11:53AM +0100, Sam James wrote: > >>> Things are more complicated about diffutils, as merging ncurses reported > >>> many errors (because missing cmp, and the same script also needs sed, > >>> which is already there in this case). > >> > >> What exactly needed cmp? I know I fixed an issue with the Python > >> eclasses recently involving that. > > > > include/edit_cfg.sh > > c++/edit_cfg.sh > > ncurses*/edit_man.sh > > > > > > Thanks. Sounds OK but I'd prefer to know what grobian thinks before > merging. -- Fabian Groffen Gentoo on a different level signature.asc Description: PGP signature
Re: [gentoo-alt] [PATCH] script/bootstrap-prefix.sh: check PIPESTATUS on unpack
Hi!
This looks like both an improvement as well as a fix.
Applied as 52e3a39449 and pushed, thanks!
Fabian
On 19-02-2022 20:34:21 +0500, Anna Vyalkova wrote:
> Both programs need to exit with status 0.
>
> Signed-off-by: Anna Vyalkova
> ---
> I encountered a situation when bzip2 failed but tar didn't return error
> code. This patch fixes it.
>
> Tested with stage1 (can't get past it).
>
> scripts/bootstrap-prefix.sh | 51 +
> 1 file changed, 29 insertions(+), 22 deletions(-)
>
> diff --git a/scripts/bootstrap-prefix.sh b/scripts/bootstrap-prefix.sh
> index 76383c0210..b8ad960e6d 100755
> --- a/scripts/bootstrap-prefix.sh
> +++ b/scripts/bootstrap-prefix.sh
> @@ -602,8 +602,8 @@ do_tree() {
> fi
> einfo "Unpacking, this may take a while"
> estatus "stage1: unpacking Portage tree"
> - bzip2 -dc ${DISTDIR}/$2 | \
> - tar -xf - -C ${PORTDIR} --strip-components=1 || return 1
> + bzip2 -dc ${DISTDIR}/$2 | tar -xf - -C ${PORTDIR}
> --strip-components=1
> + [[ ${PIPESTATUS[*]} == '0 0' ]] || return 1
> touch ${PORTDIR}/.unpacked
> fi
> }
> @@ -692,7 +692,8 @@ bootstrap_portage() {
> rm -rf "${S}" >& /dev/null
> mkdir -p "${S}" >& /dev/null
> cd "${S}"
> - bzip2 -dc "${DISTDIR}/${A}" | tar -xf - || return 1
> + bzip2 -dc "${DISTDIR}/${A}" | tar -xf -
> + [[ ${PIPESTATUS[*]} == '0 0' ]] || return 1
> S="${S}/prefix-portage-${PV}"
> cd "${S}"
>
> @@ -787,7 +788,8 @@ bootstrap_simple() {
> bz2) decomp=bzip2 ;;
> gz|"") decomp=gzip ;;
> esac
> - ${decomp} -dc "${DISTDIR}"/${A} | tar -xf - || return 1
> + ${decomp} -dc "${DISTDIR}"/${A} | tar -xf -
> + [[ ${PIPESTATUS[*]} == '0 0' ]] || return 1
> S="${S}"/${PN}-${PV}
> cd "${S}"
>
> @@ -842,18 +844,21 @@ bootstrap_gnu() {
> rm -rf "${S}"
> mkdir -p "${S}"
> cd "${S}"
> - if [[ ${t} == "tar.gz" ]] ; then
> - gzip -dc "${DISTDIR}"/${URL##*/} | tar -xf - || continue
> - elif [[ ${t} == "tar.xz" ]] ; then
> - xz -dc "${DISTDIR}"/${URL##*/} | tar -xf - || continue
> - elif [[ ${t} == "tar.bz2" ]] ; then
> - bzip2 -dc "${DISTDIR}"/${URL##*/} | tar -xf - ||
> continue
> - elif [[ ${t} == "tar" ]] ; then
> - tar -xf "${DISTDIR}"/${A} || continue
> - else
> - einfo "unhandled extension: $t"
> - return 1
> - fi
> + case ${t} in
> + tar.xz) decomp=xz;;
> + tar.bz2) decomp=bzip2 ;;
> + tar.gz) decomp=gzip ;;
> + tar)
> + tar -xf "${DISTDIR}"/${A} || continue
> + break
> + ;;
> + *)
> + einfo "unhandled extension: $t"
> + return 1
> + ;;
> + esac
> + ${decomp} -dc "${DISTDIR}"/${URL##*/} | tar -xf -
> + [[ ${PIPESTATUS[*]} == '0 0' ]] || continue
> break
> done
> S="${S}"/${PN}-${PV}
> @@ -1202,7 +1207,8 @@ bootstrap_cmake_core() {
> rm -rf "${S}"
> mkdir -p "${S}"
> cd "${S}"
> - gzip -dc "${DISTDIR}"/${A} | tar -xf - || return 1
> + gzip -dc "${DISTDIR}"/${A} | tar -xf -
> + [[ ${PIPESTATUS[*]} == '0 0' ]] || return 1
> S="${S}"/cmake-${PV}
> cd "${S}"
>
> @@ -1253,11 +1259,12 @@ bootstrap_zlib_core() {
> rm -rf "${S}"
> mkdir -p "${S}"
> cd "${S}"
> - if [[ ${A} == *.tar.gz ]] ; then
> - gzip -dc "${DISTDIR}"/${A} | tar -xf - || return 1
> - else
> - bzip2 -dc "${DISTDIR}"/${A} | tar -xf - || return 1
> - fi
> + case ${A} in
> + *.tar.gz) decomp=gzip ;;
> + *)decomp=bzip2 ;;
> + esac
> + ${decomp} -dc "${DISTDIR}"/${A} | tar -xf -
> + [[ ${PIPESTATUS[*]} == '0 0' ]] || return 1
> S="${S}"/zlib-${PV}
> cd "${S}"
>
> --
> 2.35.1
>
>
--
Fabian Groffen
Gentoo on a different level
signature.asc
Description: PGP signature
Re: [gentoo-alt] [PATCH v2 1/3] scripts/bootstrap-prefix: bugfix: use given EPREFIX
Thanks, pushed all three.
Fabian
On 04-12-2021 08:53:26 +0100, Etienne Buira wrote:
> Using $1 should not be reserved to uninteractive
>
> v2:
> - leave some comment
> - not moved down, because the following environment sanitiser unsets
> $ROOT
> - shortened $subject
>
> Thanks grobian for review
> ---
> scripts/bootstrap-prefix.sh | 5 ++---
> 1 file changed, 2 insertions(+), 3 deletions(-)
>
> diff --git a/scripts/bootstrap-prefix.sh b/scripts/bootstrap-prefix.sh
> index 1c6c42dad6..a2b1db7235 100755
> --- a/scripts/bootstrap-prefix.sh
> +++ b/scripts/bootstrap-prefix.sh
> @@ -2322,9 +2322,8 @@ EOF
> echo
> echo "It seems to me you are '${USER:-$(whoami 2> /dev/null)}'
> (${UID}), that looks cool to me."
>
> - # Expect noninteractive users to know what they do:
> - # Take EPREFIX from argv1 (=ROOT), not from env var.
> - [[ ${TODO} == 'noninteractive' ]] && EPREFIX=${ROOT}
> + # In case $ROOT were specified as $1, use it
> + [[ -z "${EPREFIX}" ]] && EPREFIX="${ROOT}"
>
> echo
> echo "I'm going to check for some variables in your environment now:"
> --
> 2.32.0
>
>
--
Fabian Groffen
Gentoo on a different level
signature.asc
Description: PGP signature
Re: [gentoo-alt] [PATCH 3/3] scripts/bootstrap-prefix.sh: create etc/make.conf as dir (or populate it if exists)
need to make
> # sure we actually use it
> + mkdir -p -- "${ROOT}/etc/portage/make.conf"
> {
> echo
> echo "# System compiler on $(uname) Prefix is Clang, do
> not remove this"
> @@ -1836,7 +1839,7 @@ bootstrap_stage2() {
> echo "OBJCXX=${CHOST}-clang++"
> echo "BUILD_CC=${CHOST}-clang"
> echo "BUILD_CXX=${CHOST}-clang++"
> - } >> "${ROOT}"/etc/portage/make.conf
> + } >>
> "${ROOT}"/etc/portage/make.conf/0100_bootstrap_prefix_clang.conf
use the var here too, probably define it globally as constant in the
set_helper_vars() function
> # llvm won't setup symlinks to CHOST-clang here because
> # we're in a cross-ish situation (at least according to
> # multilib.eclass -- can't blame it at this point really)
>
Thanks,
Fabian
--
Fabian Groffen
Gentoo on a different level
signature.asc
Description: PGP signature
Re: [gentoo-alt] [PATCH 2/3] scripts/bootstrap-prefix.sh: cleanup: this dir is unconditionaly created a few lines above
ACK
could you shorten the subject line to 80 chars (and move the explanation
to the commit message)?
Thanks,
Fabian
On 31-10-2021 16:39:51 +0100, Etienne Buira wrote:
> ---
> scripts/bootstrap-prefix.sh | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --git a/scripts/bootstrap-prefix.sh b/scripts/bootstrap-prefix.sh
> index 42b116b0e7..2b9e2e76f2 100755
> --- a/scripts/bootstrap-prefix.sh
> +++ b/scripts/bootstrap-prefix.sh
> @@ -549,7 +549,6 @@ do_tree() {
> else
> efetch "$1/$2" || return 1
> fi
> - [[ -e ${PORTDIR} ]] || mkdir -p ${PORTDIR}
> einfo "Unpacking, this may take a while"
> estatus "stage1: unpacking Portage tree"
> bzip2 -dc ${DISTDIR}/$2 | \
>
--
Fabian Groffen
Gentoo on a different level
signature.asc
Description: PGP signature
Re: [gentoo-alt] [PATCH 1/3] scripts/bootstrap-prefix: bugfix: do not arbitrarily overwrite EPREFIX
On 31-10-2021 16:39:34 +0100, Etienne Buira wrote:
> EPREFIX is given anyway (as $ROOT) when calling bootstrap-prefix.sh with
> $1 and $2, and a (following) code sets a default value if empty.
> ---
> scripts/bootstrap-prefix.sh | 4 +---
> 1 file changed, 1 insertion(+), 3 deletions(-)
>
> diff --git a/scripts/bootstrap-prefix.sh b/scripts/bootstrap-prefix.sh
> index 0e21c83953..42b116b0e7 100755
> --- a/scripts/bootstrap-prefix.sh
> +++ b/scripts/bootstrap-prefix.sh
> @@ -2306,9 +2306,7 @@ EOF
> echo
> echo "It seems to me you are '${USER:-$(whoami 2> /dev/null)}'
> (${UID}), that looks cool to me."
>
> - # Expect noninteractive users to know what they do:
> - # Take EPREFIX from argv1 (=ROOT), not from env var.
> - [[ ${TODO} == 'noninteractive' ]] && EPREFIX=${ROOT}
> + [[ -z "${EPREFIX}" ]] && EPREFIX="${ROOT}"
can you move this one down to right before the while loop where EPREFIX
is determined (line 2783), and add a brief explanation (comment) before it?
While at it, can you please shorten the subject of the commit message to
fit within 80 chars?
Thanks,
Fabian
>
> echo
> echo "I'm going to check for some variables in your environment now:"
>
--
Fabian Groffen
Gentoo on a different level
signature.asc
Description: PGP signature
Re: [gentoo-alt] [slight ping] not arbitrarily overwrite EPREFIX
On 01-12-2021 14:25:44 +0100, Etienne Buira wrote: > On Mon, Nov 29, 2021 at 10:53:15AM +, Alexey Sokolov wrote: > ../.. > > This list doesn't seem to be well monitored. To get some progress on my > > patches I sometimes have to ping grobian@ directly > > Oh, ok, thank you. > > Fabian, can you take a look at those patches please ? The patches don't go without some thorough checking, I should have replied when I reviewed them. Didn't have the time to actually dive into it at that point. Thanks, Fabian > > Regards > > -- Fabian Groffen Gentoo on a different level signature.asc Description: PGP signature
Re: [gentoo-alt] Future of x64-cygwin, x86-winnt?
With the lack of support, and bitrot in the tree, I see no other option but to remove x64-cygwin from the tree. I'll do so in the coming weeks. Fabian On 21-01-2021 21:40:51 +0100, Fabian Groffen wrote: > Hi Martin, > > On 19-01-2021 07:58:00 +0100, Martin Oberzalek wrote: > > > > gentoo prefix stack with > > > > this upcomming new cygwin release (when its released) and give some > > > > feedback. If > > > > I can get it working I would update > > > > > > > > https://wiki.gentoo.org/wiki/Prefix/Cygwin[1] > > > > > > I'm trying to understand what this means. I'm sure/certain the current > > > tree doesn't work for Cygwin. This means I anticipate you'll have to > > > patch/fix a lot of packages for it. Would it be more useful to use an > > > overlay for Cygwin instead? > > > > I agree, maybe this would be a good solution. > > I'm looking for who would maintain Cygwin/Windows, and how. > > Currently there is a lot of remnants of Cygwin, but also decay. Python > for instance got its Cygwin patches dropped (they didn't apply, and we > had to move on for security and other reasons), hence I know for sure > that Cygwin support is virtually non-existant in the current tree. > > I don't want to destroy the work of others, but at the current state, I > cannot maintain Cygwin or Windows (nor do I have incentive to do so). > With haubi retiring from the project, there's officially no Gentoo > developers working on this. > > If a separate overlay or fork is the way to go, we can see if we can get > such repo on Gentoo hardware and set it up, turn Cygwin into a proper > sub-project or something, and move anything necessary there as not to > hold back the Prefix migration of whatever's left back into the main > gentoo repository. > > Thanks, > Fabian > > > -- > Fabian Groffen > Gentoo on a different level -- Fabian Groffen Gentoo on a different level signature.asc Description: PGP signature
Re: [gentoo-alt] [Prefix] macos x86_64: GCC Bootstrap fails
I tried this on a virgin BigSur install, but found no problems, I suspect it's due to updated Xcode tools. Fabian On 06-08-2021 10:29:52 +, Sven Goericke wrote: > Dear Gentto Prefix team, > > I tried to setup Gentoo Prefix a couple of times on my MBP 2018. > Unfortunately it always fails during bootstrap of GCC, comparison > between stage 2 and stage 3. > > OS: macos Big Sur 11.5.1 > MacBook Pro (13-inch, 2018, Four Thunderbolt 3 Ports) (8GB RAM, i5) > Latest Xcode installed Version 12.5.1 (12E507) > > Since I have worked as C++ dev in the past I would assume that different > object files (from same source) using the same compiler could be caused > only by different compiler-flags . But to be honest, I have no knowledge > about the gcc bootstrap process (guessing it will compile once and then > itself again with the fresh compile). So maybe someone from you guys has > some hint. I already had Gentoo installed natively on this MBP but want > to play around with Prefix a bit. > > I'll try to attach the stage3.log, just let me know if you need further > information. However, probably the most important lines: > > make[2]: Entering directory > '/Users/svengoericke/Gentoo/var/tmp/portage/sys-devel/gcc-10.2.0-r5/work/build' > make[3]: Entering directory > '/Users/svengoericke/Gentoo/var/tmp/portage/sys-devel/gcc-10.2.0-r5/work/build' > rm -f stage_current > make[3]: Leaving directory > '/Users/svengoericke/Gentoo/var/tmp/portage/sys-devel/gcc-10.2.0-r5/work/build' > Comparing stages 2 and 3 > warning: gcc/cc1obj-checksum.o differs > warning: gcc/cc1objplus-checksum.o differs > Bootstrap comparison failure! > gcc/tree-ssa-operands.o differs > gcc/tree-ssanames.o differs > > Edit: stage3.log is too big to attach, I just upladed to my server: > > https://dg6lmp.de/stage1.log > https://dg6lmp.de/stage2.log > https://dg6lmp.de/stage3.log > > BR Sven > > -- Fabian Groffen Gentoo on a different level signature.asc Description: PGP signature
Re: [gentoo-alt] [PREFIX] arm64-macos
On 22-07-2021 20:58:53 +0100, Robin Randhawa wrote: > Hi Fabian. > > On 12.02.2021 19:43, Fabian Groffen wrote: > > >All, > > > >I'm looking for someone with an Apple SI M1 machine. I'm running into a > >very strange problem during bootstrap for native arm64 with flex, where > >no matter which flex I compile appears not to be able to exec m4, an > >issue that's completely puzzling me at the moment. > > Sure, happy to help. I am currently running MacPorts but would love to > have Gentoo Prefix on my Apple M1 silicon based MacBook Pro. > > >Wondering at this point if I'm just on some weird/monday morning model, > >or that this is fully reproducible (since macports/homebrew/noone seems > >to have noticed this problem, yet ship flex without issues). > > I've just run bootstrap-prefix.sh and I seem to have hit a different > problem: this exactly IS the problem :) > == > make[3]: Leaving directory > '/Users/robin/Gentoo/var/tmp/portage/sys-devel/gcc-11_pre20200206/work/build/gcc' > make[2]: *** [Makefile:4786: all-stage1-gcc] Error 2 > make[2]: Leaving directory > '/Users/robin/Gentoo/var/tmp/portage/sys-devel/gcc-11_pre20200206/work/build' > make[1]: *** [Makefile:22346: stage1-bubble] Error 2 > make[1]: Leaving directory > '/Users/robin/Gentoo/var/tmp/portage/sys-devel/gcc-11_pre20200206/work/build' > make: *** [Makefile:1009: all] Error 2 > * ERROR: sys-devel/gcc-11_pre20200206::gentoo_prefix failed (compile phase): > * emake failed ... > Please let me know if you would like me to share the gcc-build-logs > etc or if there is some other path you would like me to take. if you look a bit further in the logs you'll see it fails because of some compilation problem, which is caused by an empty file. This file is empty because the flex call to generate it failed. > I'll also try and hang out on IRC to help. I think there will be people there, but I rarely am. Thanks, Fabian -- Fabian Groffen Gentoo on a different level signature.asc Description: PGP signature
[gentoo-alt] [PREFIX] arm64-macos
All, I'm looking for someone with an Apple SI M1 machine. I'm running into a very strange problem during bootstrap for native arm64 with flex, where no matter which flex I compile appears not to be able to exec m4, an issue that's completely puzzling me at the moment. Wondering at this point if I'm just on some weird/monday morning model, or that this is fully reproducible (since macports/homebrew/noone seems to have noticed this problem, yet ship flex without issues). Thanks, Fabian -- Fabian Groffen Gentoo on a different level signature.asc Description: PGP signature
Re: [gentoo-alt] Future of x64-cygwin, x86-winnt?
Hi Martin, On 19-01-2021 07:58:00 +0100, Martin Oberzalek wrote: > > > gentoo prefix stack with > > > this upcomming new cygwin release (when its released) and give some > > > feedback. If > > > I can get it working I would update > > > > > > https://wiki.gentoo.org/wiki/Prefix/Cygwin[1] > > > > I'm trying to understand what this means. I'm sure/certain the current > > tree doesn't work for Cygwin. This means I anticipate you'll have to > > patch/fix a lot of packages for it. Would it be more useful to use an > > overlay for Cygwin instead? > > I agree, maybe this would be a good solution. I'm looking for who would maintain Cygwin/Windows, and how. Currently there is a lot of remnants of Cygwin, but also decay. Python for instance got its Cygwin patches dropped (they didn't apply, and we had to move on for security and other reasons), hence I know for sure that Cygwin support is virtually non-existant in the current tree. I don't want to destroy the work of others, but at the current state, I cannot maintain Cygwin or Windows (nor do I have incentive to do so). With haubi retiring from the project, there's officially no Gentoo developers working on this. If a separate overlay or fork is the way to go, we can see if we can get such repo on Gentoo hardware and set it up, turn Cygwin into a proper sub-project or something, and move anything necessary there as not to hold back the Prefix migration of whatever's left back into the main gentoo repository. Thanks, Fabian -- Fabian Groffen Gentoo on a different level signature.asc Description: PGP signature
Re: [gentoo-alt] Future of x64-cygwin, x86-winnt?
Hey Martin, On 18-01-2021 06:04:45 +0100, Martin Oberzalek wrote: > > Hello Fabian, > > > So, the inevitable question: who needs x64-cygwin/x86-winnt, and who > > would take care of maintaining it? If noone steps up (I cannot even run > > the platform) before Feb 1st 2021, I'll probably continue and drop these > > two from Gentoo at some point after that. > > > > Please chime in if you have an opinion, info, interest, etc. > > we are using a fork from haubi from last year und using > * x64-cygwin > * x86-winnt > * x64-winnt > > x86-winnt is not so important for us. In fact, maybe we will also switch to > WSL for our use case in future... Ok, I thought *-winnt targets were native Windows code, apparently WSL is too? (I'm just learning here, I guess.) > But now we are using actual cygwin versions and our fork of gentoo. Currently > this is only working > with the developer release of the cygwin.dll. What I can do is: testing the > gentoo prefix stack with > this upcomming new cygwin release (when its released) and give some feedback. > If I can get it working I would update > > https://wiki.gentoo.org/wiki/Prefix/Cygwin I'm trying to understand what this means. I'm sure/certain the current tree doesn't work for Cygwin. This means I anticipate you'll have to patch/fix a lot of packages for it. Would it be more useful to use an overlay for Cygwin instead? Thanks, Fabian -- Fabian Groffen Gentoo on a different level signature.asc Description: PGP signature
[gentoo-alt] Future of x64-cygwin, x86-winnt?
All, With haubi recently retiring from the project, I've taken a close look at platforms we have in use, and cleaned up a lot of them that we have absolutely no means to support (any more). This includes old Darwin and Solaris releases, entire support for HPUX, AIX, etc. I've left x64-cygwin and x86-winnt untouched in that process. However, x64-cygwin in particular requires a large amount of (non-trivial/disturbing) patches, basically blocking our merging of the Prefix overlay into gx86. It seems to me, x64-cygwin and x86-winnt have no sponsor whatsoever at this point within Gentoo, or our direct user-base. Some user that submitted a lot of patches/fixes on our bugzilla in the past pointed out that Cygwin is no longer necessary for him due to effortless bootstraps on "WSL". So, the inevitable question: who needs x64-cygwin/x86-winnt, and who would take care of maintaining it? If noone steps up (I cannot even run the platform) before Feb 1st 2021, I'll probably continue and drop these two from Gentoo at some point after that. Please chime in if you have an opinion, info, interest, etc. Thanks, Fabian -- Fabian Groffen Gentoo on a different level signature.asc Description: PGP signature
Re: [gentoo-alt] [PATCH 0/2] Xvfb in test dependencies in Prefix
On 13-01-2021 09:07:52 +, Alexey Sokolov wrote: > ср, 13 янв. 2021 г. в 08:49, Fabian Groffen : > > > > On 13-01-2021 08:45:23 +, Alexey Sokolov wrote: > > > Hi Fabian > > > > > > You already merged it a couple of months ago. I sent it to -dev first, > > > got no response for a while, then sent it here. > > > > That's excellent news. The mask seems missing though, let me push it. > > > > Do you mean this mask? > https://github.com/gentoo/gentoo/commit/4586707c18a802093926ce6db7a9c3df075a9a73 yeah found it, nothing to do here, all is well :) -- Fabian Groffen Gentoo on a different level signature.asc Description: PGP signature
Re: [gentoo-alt] [PATCH 0/2] Xvfb in test dependencies in Prefix
On 13-01-2021 08:45:23 +, Alexey Sokolov wrote: > Hi Fabian > > You already merged it a couple of months ago. I sent it to -dev first, > got no response for a while, then sent it here. That's excellent news. The mask seems missing though, let me push it. Thanks, Fabian > > ср, 13 янв. 2021 г. в 08:17, Fabian Groffen : > > > > This sounds good, the eclass change we'd have to run by -dev though. > > > > On 29-10-2020 11:29:27 +, alexey+gen...@asokolov.org wrote: > > > From: Alexey Sokolov > > > > > > I'm running a prefix but tests of various packages are failing in virtx > > > command. I discovered that this is because virtualx doesn't depend on > > > xvfb in prefix. But after installing xorg-server[xvfb,-elogind] tests > > > pass. > > > elogind flag had to be disabled otherwise it brings pam as dependency. > > > So, attached are patches to prefix profile to disable elogind for > > > xorg-server, and to virtualx eclass to depend on it even in prefix. > > > > > > Alexey Sokolov (2): > > > profiles: prefix: mask USE=elogind in x11-base/xorg-server > > > virtualx.eclass: don't skip xvfb dependency on Prefix > > > > > > eclass/virtualx.eclass | 2 +- > > > profiles/features/prefix/package.use.mask | 4 > > > 2 files changed, 5 insertions(+), 1 deletion(-) > > > > > > -- > > > 2.26.2 > > > > > > > > > > -- > > Fabian Groffen > > Gentoo on a different level > -- Fabian Groffen Gentoo on a different level signature.asc Description: PGP signature
Re: [gentoo-alt] [PATCH 0/2] Xvfb in test dependencies in Prefix
This sounds good, the eclass change we'd have to run by -dev though. On 29-10-2020 11:29:27 +, alexey+gen...@asokolov.org wrote: > From: Alexey Sokolov > > I'm running a prefix but tests of various packages are failing in virtx > command. I discovered that this is because virtualx doesn't depend on > xvfb in prefix. But after installing xorg-server[xvfb,-elogind] tests > pass. > elogind flag had to be disabled otherwise it brings pam as dependency. > So, attached are patches to prefix profile to disable elogind for > xorg-server, and to virtualx eclass to depend on it even in prefix. > > Alexey Sokolov (2): > profiles: prefix: mask USE=elogind in x11-base/xorg-server > virtualx.eclass: don't skip xvfb dependency on Prefix > > eclass/virtualx.eclass| 2 +- > profiles/features/prefix/package.use.mask | 4 > 2 files changed, 5 insertions(+), 1 deletion(-) > > -- > 2.26.2 > > -- Fabian Groffen Gentoo on a different level signature.asc Description: PGP signature
Re: [gentoo-alt] Issues bootstrapping Gentoo Prefix on Arch Linux
I think RAP simply pulls in attr, and we need to see if we can fix it. Can you file a bug for it on bugs.gentoo.org if you haven't yet? Thanks, Fabian On 15-12-2020 21:44:01 -0500, Joey Dumont wrote: > At this exploratory stage, I do not need a libc in my prefix. Arch is a > rolling > release, so I currently glibc-2.32, which I believe is the latest. > > Good to hear that it's working on both Ubuntu and CentOS: those are the likely > platforms for any production work. I was mostly curious to see how it would > fare > on my home system. It's a nice way of getting acquainted with portage as > well. > > The PREFIX_DISABLE_RAP=yes bootstrap worked! This is enough for me on Arch > Linux, although I'd be curious to know why RAP fails. I just tried emerging > attr > on my non-RAP prefix, and it also fails. Do you know if it's a function of the > host glibc? > > In any case, I think this is fine. I'll set prefix up on a CentOS or Ubuntu > system with a prefixed libc. > > Thanks! > > Joey Dumont (Profile[1]) > The supreme elegance of Nature lies in its apparent simplicity. > > > On Tue, 15 Dec 2020 at 02:55, Fabian Groffen wrote: > > I know this is not a small ask, but do you need a libc in your Prefix? > > E.g. do you anticipate one is neccesary because Arch's is too old? > > > > If not, could you try bootstrapping again from scratch with > > PREFIX_DISABLE_RAP=yes in your environment set. > > > > I see that yesterday's Ubuntu bootstrap (using RAP) succeeded, and the > > CentOS bootstrap succeeded not too long ago, so this may be a total > > pointless ask. > > > > Thanks, > > Fabian > > > > > > On 14-12-2020 20:59:52 -0500, Joey Dumont wrote: > > > I tried contacting the mailing list a couple times, but it seems my > > > messages weren't going through. Trying with plain text email, sorry if > > > I generated noise. > > > > > > I've been trying to bootstrap Gentoo Prefix on Arch Linux. However, I > > > am having issues during stage3. Specifically, I am having trouble > > > building sys-apps/attr-2.4.48-r4. Actually, it builds fine, but then > > > the symbol version sanity check fails: > > > > > > * ERROR: sys-apps/attr-2.4.48-r4::gentoo failed (install phase): > > > * symbol version sanity check failed; please comment on > > > https://bugs.gentoo.org/644048[3] > > > * > > > * Call stack: > > > * ebuild.sh, line 125: Called src_install > > > * environment, line 2163: Called multilib-minimal_src_install > > > * environment, line 1501: Called multilib_foreach_abi > > > 'multilib-minimal_abi_src_install' > > > * environment, line 1734: Called multibuild_foreach_variant > > > '_multilib_multibuild_wrapper' 'multilib-minimal_abi_src_install' > > > * environment, line 1388: Called _multibuild_run > > > '_multilib_multibuild_wrapper' 'multilib-minimal_abi_src_install' > > > * environment, line 1386: Called _multilib_multibuild_wrapper > > > 'multilib-minimal_abi_src_install' > > > * environment, line 474: Called multilib-minimal_abi_src_install > > > * environment, line 1491: Called multilib_src_install > > > * environment, line 1965: Called die > > > * The specific snippet of code: > > > * die "symbol version sanity check failed; please > > > comment on https://bugs.gentoo.org/644048[4];; > > > > > > I've checked the symbols, and it does seem that the issue fits the > > > parameters of bug 644048: > > > > > > ~/software/gentoo/2020.12/tmp/bin/x86_64-pc-linux-gnu-readelf -sW > > > /home/valandil/software/gentoo/2020.12/var/tmp/portage/sys-apps/attr-2.4.48- > > r4/image/home/valandil/software/gentoo/2020.12/usr/lib64/libattr.so.1 > > > | grep getxattr > > > 13: 0 FUNC GLOBAL DEFAULT UND > > > lgetxattr@GLIBC_2.3 (7) > > > 26: 0 FUNC GLOBAL DEFAULT UND > > > fgetxattr@GLIBC_2.3 (7) > > > 31: 0 FUNC GLOBAL DEFAULT UND > > > getxattr@GLIBC_2.3 (7) > > > 43: 40e0 0 FUNC GLOBAL DEFAULT 13 > > >fgetxattr@ATTR_1.0 > > > 54: 40a0 0 FUNC GLOBAL DEFAULT 13 > > >getxattr@ATTR_1.0 > > > 62: 40c0 0 FUNC GLOBAL DEFAULT 13 > > >lgetxattr@ATTR_1.0 > > > 47: 40c0 24 FUNC LOCAL DEFAULT 13 > > >libattr_lgetxattr > > > 50: 000
Re: [gentoo-alt] Issues bootstrapping Gentoo Prefix on Arch Linux
I know this is not a small ask, but do you need a libc in your Prefix? E.g. do you anticipate one is neccesary because Arch's is too old? If not, could you try bootstrapping again from scratch with PREFIX_DISABLE_RAP=yes in your environment set. I see that yesterday's Ubuntu bootstrap (using RAP) succeeded, and the CentOS bootstrap succeeded not too long ago, so this may be a total pointless ask. Thanks, Fabian On 14-12-2020 20:59:52 -0500, Joey Dumont wrote: > I tried contacting the mailing list a couple times, but it seems my > messages weren't going through. Trying with plain text email, sorry if > I generated noise. > > I've been trying to bootstrap Gentoo Prefix on Arch Linux. However, I > am having issues during stage3. Specifically, I am having trouble > building sys-apps/attr-2.4.48-r4. Actually, it builds fine, but then > the symbol version sanity check fails: > > * ERROR: sys-apps/attr-2.4.48-r4::gentoo failed (install phase): > * symbol version sanity check failed; please comment on > https://bugs.gentoo.org/644048 > * > * Call stack: > * ebuild.sh, line 125: Called src_install > * environment, line 2163: Called multilib-minimal_src_install > * environment, line 1501: Called multilib_foreach_abi > 'multilib-minimal_abi_src_install' > * environment, line 1734: Called multibuild_foreach_variant > '_multilib_multibuild_wrapper' 'multilib-minimal_abi_src_install' > * environment, line 1388: Called _multibuild_run > '_multilib_multibuild_wrapper' 'multilib-minimal_abi_src_install' > * environment, line 1386: Called _multilib_multibuild_wrapper > 'multilib-minimal_abi_src_install' > * environment, line 474: Called multilib-minimal_abi_src_install > * environment, line 1491: Called multilib_src_install > * environment, line 1965: Called die > * The specific snippet of code: > * die "symbol version sanity check failed; please > comment on https://bugs.gentoo.org/644048;; > > I've checked the symbols, and it does seem that the issue fits the > parameters of bug 644048: > > ~/software/gentoo/2020.12/tmp/bin/x86_64-pc-linux-gnu-readelf -sW > /home/valandil/software/gentoo/2020.12/var/tmp/portage/sys-apps/attr-2.4.48-r4/image/home/valandil/software/gentoo/2020.12/usr/lib64/libattr.so.1 > | grep getxattr > 13: 0 FUNCGLOBAL DEFAULT UND > lgetxattr@GLIBC_2.3 (7) > 26: 0 FUNCGLOBAL DEFAULT UND > fgetxattr@GLIBC_2.3 (7) > 31: 0 FUNCGLOBAL DEFAULT UND > getxattr@GLIBC_2.3 (7) > 43: 40e0 0 FUNCGLOBAL DEFAULT 13 fgetxattr@ATTR_1.0 > 54: 40a0 0 FUNCGLOBAL DEFAULT 13 getxattr@ATTR_1.0 > 62: 40c0 0 FUNCGLOBAL DEFAULT 13 lgetxattr@ATTR_1.0 > 47: 40c024 FUNCLOCAL DEFAULT 13 libattr_lgetxattr > 50: 40a024 FUNCLOCAL DEFAULT 13 libattr_getxattr > 57: 40e023 FUNCLOCAL DEFAULT 13 libattr_fgetxattr > 83: 0 FUNCGLOBAL DEFAULT UND > lgetxattr@@GLIBC_2.3 > 89: 40a0 0 FUNCGLOBAL DEFAULT 13 getxattr@ATTR_1.0 > 97: 40c0 0 FUNCGLOBAL DEFAULT 13 lgetxattr@ATTR_1.0 >113: 0 FUNCGLOBAL DEFAULT UND > fgetxattr@@GLIBC_2.3 >123: 0 FUNCGLOBAL DEFAULT UND getxattr@@GLIBC_2.3 >127: 40e0 0 FUNCGLOBAL DEFAULT 13 fgetxattr@ATTR_1.0 > > I tried adding the ebuild/patch attached to the bug above by adding a > local repo, and masking earlier versions of sys-apps/attr in > tmp/etc/portage/package.mask, but since the patch modifies a file > alled Makemodules.am, portage triggers automake-1.15, which is not > available on the prefix at this point. I tried installing it by adding > sys-devel/automake to the list of pkgs installed at this point, but > this fails at the install_qa_check_prefix stage, as automake contains > non-prefixed shebangs. > > What's the way forward here? Should I write my own automake patch to > fix the non-prefixed shebang? Or is that a known issue in Prefix with > a better (known) solution? > > Thanks for any help! > > Joey Dumont (Profile) > The supreme elegance of Nature lies in its apparent simplicity. > -- Fabian Groffen Gentoo on a different level signature.asc Description: PGP signature
Re: [gentoo-alt] [PREFIX] the road ahead for Darwin/macOS
To whom it may concern. After a few turbulent weeks, with lots of input and help from various people, the macOS bootstraps appear to be functional again. The recent default Python switch from 3.7 to 3.8 threw some mud on the road, but I can confirm this is now sorted out/fixed for: - powerpc-apple-darwin9 - x86_64-apple-darwin17 I have reasons to believe darwin20 (Big Sur) is also functioning, right before the Python thing happened, darwin19 and 20 were bootstrapping just fine. Bootstraps use Python 3.8.6 straight from stage1 now, and the resulting Prefix has just that single Python installed, so it's pretty much lean and clean. On macOS, by default a strategy of using FSF GCC (10.1.0 at this time) is used, which means, no Clang, but efforts for trying to get that running are underway (bug #758167). There is no linker/cctools being built, instead the Xcode ld/as etc. are used. This functions fairly well, and should provide a stable and functional enough Prefix for most users. Thanks to those who have been patient, and thanks Sam for jumping on the Prefix train to bring it forwards. Fabian On 27-12-2019 11:45:46 +0100, Fabian Groffen wrote: > To all interested in Gentoo Prefix on recent macOS. > > In the past few releases of macOS, /usr/include has disappeared. While > this previously was remedied by performing some commands, Apple has made > this more strict, and it appears the way forwards, is by no longer > relying on /usr/include. > > To deal with this, the packages sys-kernel/xnu-headers and > sys-libs/darwin-libc-headers were added to @system for newer macOS > profiles. While you may have seen these packages coming in, getting > some updates here and there, they may still not be perfect, yet I think > we're getting somewhere. The purpose of these packages obviously is to > provide system headers and frameworks without relying on Xcode. > > Next I've modified the bootstrap script to unpack a Prefix-built clang > compiler, and use it to bootstrap. This, in addition to the headers, > allowed me to progress until stage2 where a compiler is built. This > failed, for a number of reasons. 1) requirement of cmake, which is > horrible. It requires way too much in terms of dependencies, so I > resorted to an unpacked Prefix-built version to provide it. Can't use > upstream's binaries for cmake, because they insist on using Xcode SDKs. > Next, 2) clang fails to build halfway because it throws away CXXFLAGS > pointing to the headers provided. I seem to remember that this is what > GCC build does as well, so not that surprising, but it basically renders > the approach useless. > > This lead me to investigating how to tell the bootstrap compiler to keep > looking for the headers we provided. Turns out the compiler is > hard-wired to add c++ headers (stdinc) to its search-path, and this is > necessary (at least on Darwin) because the math.h header appears twice, > and only one of them is compatible with c++ code. Anyway. Apple seems > to use -isysroot to point to an SDK that's selected/targetted. It seems > to me, at this point we should follow that lead, and simply turn the > Prefix into such sysroot. Experimenting with this option on our > Prefix-build clang, results in not exactly desirable behaviour. Because > the offset prefix is added to the compiler's search paths, nothing ends > up right. > So I downloaded clang binary from llvm.org, and tried the same. That > made more sense, and it seems the search path is correct there. > > What I want to try now, is if I can set CC/CXX to "clang -isysroot > /path/to/prefix", and if that will get me through compiler building of > stage2 during bootstrap. > > If that works, it seems the first step towards Xcode free bootstrapping > on macOS. There will be some questions towards how we build our clang, > if we should step away from patching it and using isysroot instead. > Finally, how we're going to provide the binaries that we want to use > during bootstraps. Ideally we can provide stage1/stage2 by simply > installing form binpkgs, for instance using q/portage-utils. > > End of update, hopefully bootstrapping can be working again soon. > > Thanks, > Fabian > > -- > Fabian Groffen > Gentoo on a different level -- Fabian Groffen Gentoo on a different level signature.asc Description: PGP signature
Re: [gentoo-alt] Time has come, or: a story of success
Hey /haubi/, Thanks for all the kind words, and much more thanks for your numerous contributions on especially very hard problems (such as ncurses with libtool, and other mostly toolchain related). I hope we will see you around sometimes, I was even hoping to meet you once again at a FOSDEM. Whatever it is you do, take care, have fun, and compile it :) Many thanks, Fabian On 09-12-2020 20:01:58 +0100, Michael Haubenwallner wrote: > Dear Gentoo Prefix folks! > > TL;DR > It was a great pleasure to grow up Gentoo Prefix with you, yet for me > the time has come to leave. Thank you so much for a great experience! > > A story of success: > Back in 2004, at work, for a number of 3 packages I have been requested to > realize some mechanism to compile+install them together into some custom > filesystem location as normal (non-root) user on the proprietary Unix > platforms AIX (ppc), HP-UX (hppa, ia64) and Solaris (sparc, x86). > So I invented some package installer, using GNU make to resolve dependencies > and parallelize the build, with Bourne Shell files to define the package > metadata, dependencies and compilation commands. > > By the time, the list of packages I had to define in my installer grew up > and started to include things like GCC and some FOSS libraries. > > Around the same time, a colleague told me about Gentoo Linux to be a really > cool distro, and I migrated away from Debian as a Linux user. > > But it took me another ~2 years to realize that my invented package format > really is based on the very same ideas as the Gentoo ebuild format... > > > Here, multiple great Thanks! to Fabian (grobian) Groffen, fortunately a Gentoo > developer by that time already, for: > * Understanding the goal behind my initial Portage patch I submitted to > install > packages into some custom filesystem location as a normal user, > * Recognizing at all that a Portage patch has been submitted, > * Creating the Prefix project within the Gentoo ecosystem as sub-project of > the already existing gentoo-alt (Gentoo on Alternative Platforms) project, > * Providing non-Gentoo resources to run the Prefix project, > * Leading the Prefix project for a really long time, > * Mentoring myself to become a Gentoo developer as well, > * Drinking some beer together at FOSDEM a few times, > * a lot more > > Also, great Thanks! to all the (current and former) Prefix developers, namely > Benda (heroxbd) XU for leading Prefix these days, as well as Gentoo developers > for supporting or at least accepting Prefix in general. > > > Within the company, I have released forks of Gentoo Prefix in 2010 and 2015, > with some help of Markus (mduft) Duft to build packages necessary for our > application as native Windows binaries using the MSVC compiler, with the > driving Portage instance running in a Prefix instance on Cygwin. > > Using one Prefix instance (having build deps) to manage another one (without > build deps) is known as Prefix-Stack these days, and supported to a great > degree by EAPI 7. > > In 2019, I did hand over to a team of 3 colleagues, and they succeeded in > releasing our fork of Prefix in 2020 on their own already. They actually > intend to show up with some patches in the Prefix community, but as it's > not their main task, this may eventually be delayed until some 2025 release. > > For myself, a month after FOSDEM'20 I have switched my work focus onto the > Java world, but still I'm really proud to see the Prefix baby live on it's > own, exploring the world in a way I never could imagine! > > While I have to see whether I can remain active enough to keep my status > as Gentoo developer, I'm definitively inactive as Prefix developer now. > > So long, thank you for a great experience, it was a really good time! > > All the best, > /haubi/ > -- Fabian Groffen Gentoo on a different level signature.asc Description: PGP signature
Re: [gentoo-alt] Using Gentoo Prefix to support a more recent version of Eclipse?
On 19-08-2020 22:52:38 +0200, Rabbe Fogelholm wrote: > Thanks Benda for encouragement. > > The bootstrapping was a breeze. I started it off and it finished in a couple > of > hours. > > Emerging 'meld', another GTK application, was possible after adding some > masks and USE flags. > > With Java, no success yet. I am trying to use a LD_LIBRARY_PATH, but > that causes Java to crash immediately. Maybe this is just not doable. The Oracle SDKs (that are masked nowadays) always worked like a charm for me. Perhaps you can use those? Fabian > > BR and thanks / Rabbe > > > Benda Xu wrote: > > Hi Rabbe, > > > > Rabbe Fogelholm writes: > > > >> I have a situation where Gentoo Prefix may possibly help. > >> > >> I want to run Eclipse with a plugin for Erlang development. The plugin > >> requires me to use a recent version of Eclipse. However, the platform > >> that I am stuck with is Ubuntu 16.04.6 LTS, which has an old GTK 3 > >> version, which would force me to use Eclipse "Oxygen", not compatible > >> with the Erlang plugin. > >> > >> So, I am wondering: If I can get Gentoo Prefix set up, with presumably > >> an up-to-date version of GTK 3, could I then hope that this Eclipse > >> can find the newer GTK 3 and run happily? > > Yes, Gentoo Prefix will help. That said, it might not work out of the > > box. I don't know anyone who is using Eclipse on Gentoo Prefix. > > > > You can expect bugs along your way to the destiny. And that's a good > > way to contribute to Prefix by sharing your findings and solutions > > through the bugzilla. > > > > Yours, > > Benda > > > > -- Fabian Groffen Gentoo on a different level signature.asc Description: PGP signature
Re: [gentoo-alt] For prefix usage, is there any reason for portage to continue support for python <3.6?
Hi Zac, We bootstrap using Python 3.7 for a while now, so we should be safe in this regard. Thanks for considering Prefix though! Fabian On 16-07-2020 10:15:03 -0700, Zac Medico wrote: > Hi all, > > For prefix usage, is there any reason for portage to continue support > for python <3.6? We could potentially continue supporting 3.4 and 3.5 > for some time, but note that 3.5 EOL is scheduled for 2020-09-13: > > https://devguide.python.org/#status-of-python-branches > -- > Thanks, > Zac > -- Fabian Groffen Gentoo on a different level signature.asc Description: PGP signature
Re: [gentoo-alt] Please Bump Arm64 Prefix Stage3
On 30-06-2020 19:01:22 -0500, Sid Spry wrote: > On Sun, Jun 14, 2020, at 4:17 PM, Sid Spry wrote: > > On Sun, Jun 14, 2020, at 2:49 AM, Fabian Groffen wrote: > > > To the best of my knowledge, we don't build or use stage3 images. I > > > think you must have found something somewhere that isn't part of the > > > project. > > > > > I tried running setup.py and it ended up breaking my prefix install > > further. For Prefix on Android a stage3 is provided, there is no > > functional userland to run ./bootstrap-prefix.sh with. See > > https://wiki.gentoo.org/wiki/Project:Android/tarball. > > Sorry for bumping this, would filing a bug be appropriate so that it > eventually > gets addressed if someone is able? > > I'm not finding a good way to generate this on my own. Who knows about the Android tarball? Who generates it, who owns it? Thanks, Fabian -- Fabian Groffen Gentoo on a different level signature.asc Description: PGP signature
Re: [gentoo-alt] Please Bump Arm64 Prefix Stage3
On 13-06-2020 12:56:08 -0500, Sid Spry wrote: > I can try this later. Is there no way to trigger the release build machinery? > I realize the files are hosted from an experimental dir but doubt their > generation was entirely manual. > > I would try to build a prefix stage3 myself (via bootstrap-prefix.sh?) but I > am not sure I have an arm64 device that will work. To the best of my knowledge, we don't build or use stage3 images. I think you must have found something somewhere that isn't part of the project. Fabian -- Fabian Groffen Gentoo on a different level signature.asc Description: PGP signature
Re: [gentoo-alt] Please Bump Arm64 Prefix Stage3
On 13-06-2020 09:58:38 -0500, Sid Spry wrote: > On Sat, Jun 13, 2020, at 8:58 AM, Fabian Groffen wrote: > > Then update your portage? > > ... I can't, it's blocked by EAPI version mistmatch. The stage3 is EAPI6. > Most of the packages, and at least the most important ones like postage, are > EAPI7. This sounds a lot like the scenario I recently had when I started up an old VM. In the old days, the upgrade path was kept around, but with the current generation of devs, this is considered bloat. I ended up just respinning the VM, reinstalling Gentoo from scratch. Is that something possible for you to do? Your only alternative is (most likely) installing a more recent Portage manually, or by hacking the ebuild to make it EAPI=5 and wading your way through warnings and errors until it manages to install. I would just do ebuild portage... digest clean merge for this, making changes wherever you need to just get the new portage installed. After that, probably --sync to wipe out any modifications you had to make. Thanks, Fabian -- Fabian Groffen Gentoo on a different level signature.asc Description: PGP signature
Re: [gentoo-alt] Please Bump Arm64 Prefix Stage3
Then update your portage? On 13-06-2020 08:53:35 -0500, Sid Spry wrote: > On Sat, Jun 13, 2020, at 8:43 AM, Fabian Groffen wrote: > > What exactly do you need bumped? > > > > On 13-06-2020 08:36:08 -0500, Sid Spry wrote: > > > Hello, doing phone stuff. Most packages blocked by EAPI version mismatch. > > > > > > > -- > > Fabian Groffen > > Gentoo on a different level > > > > Attachments: > > * signature.asc > > Everything? Stage3 is mostly @system, so that. I need to merge some packages > to mess with IO. > -- Fabian Groffen Gentoo on a different level signature.asc Description: PGP signature
Re: [gentoo-alt] Allow non-interactive bootstrap to be stopped at arbitrary stages
I think pretty late, but this is committed in f6bbc6f470.
Thanks,
Fabian
On 03-02-2020 14:54:26 +1100, Sam Pfeiffer wrote:
> Hey Fabian,
>
> Thanks for chipping in. I do think it's useful and user-friendly to be able to
> control the target of the interactive/noninteractive script.
> I proposed in my first email in the thread something similar with the
> $STOP_AFTER_STAGE variable, even though I was capturing it from the
> commandline,
> and as I understand
> you propose, it would probably be better to capture it from an environment
> variable (it would actually be more in-line with other existing variables).
>
> Benda, I'm sorry for the noise I'm causing. I just want to improve the
> experience for the next person that tries to use this amazing project by
> taking advantage of already implemented stuff. And also just having this
> discussion is good to have more information archived to google about Gentoo
> Prefix and its bootstrap process. I think.
>
> On Sun, 2 Feb 2020 at 23:08, Fabian Groffen wrote:
> > What I gather from this discussion is that the bootstrap script is
> > complex, and grew more complexity over the years.
> >
> > Back in the early days, there was just documentation, one needed to
> > follow. Since this frequently needed an update, and people kept using
> > older copies, at some point the bootstrap-prefix.sh script was
> > introduced.
> >
> > This script followed the documentation to the letter. It was an exact
> > replica of the instructions in the bootstrap document. This included
> > the notions of 3 stages and a world recompile.
> >
> > Today, the purpose of the stages have blurred, and seem more like
> > batches in which to do things. Some of the initial intentions still
> > stand out, e.g. that stage1 is there to provide a working portage
> > environment with some minimal efforts. Minimal got redefined as soon as
> > we had to install python and more and more tools seemed necesary (sed,
> > path, awk, etc.).
> >
> > Now, it seems you need to cut time and sort of bootstrap up-to a stage.
> > Would it be an option to simply add a(nother) var that will control the
> > interactive target in terms of how far it will run along. Normal resume
> > strategies it employs already would simply allow a next run to run along
> > further.
> >
> > I think above can be done easily with a few lines of code.
> >
> > Let me know what you think.
> >
> > Thanks,
> > Fabian
> >
> > On 23-01-2020 13:31:05 +1100, Sam Pfeiffer wrote:
> > > Grobian, any input about this?
> > >
> > > On Thu, Jan 16, 2020, 17:39 Sam Pfeiffer <[1]sammypfeif...@gmail.com[2]>
> > wrote:
> > >
> > > > Hello Benda,
> > >
> > > > To be more specific... To easily go thru it I made a gist with the
> > > > latest
> > > > version of bootstrap-prefix.sh and I'll be pointing to specific lines
> > > > (this
> > > > also helps me recap why I did this, as I remember using stage{1,2,3}
> > > > didn't
> > > > work for me when I first came into this):
> > >
> > > > When you execute bootstrap-prefix.sh without arguments (other than the
> > > > EPREFIX, ./bootstrap-prefix.sh /MY/EPREFIX) it calls this line:
> > >
> > > > [2]https://gist.github.com/awesomebytes/
> > ba4df9c6ef3ab5742cb9aceed7998c3d#file-bootstrap-prefix-sh-L3033[3]
> > >
> > > > Calling bootstrap_interactive
> > >
> > > > If you give an extra argument (./bootstrap-prefix.sh /MY/EPREFIX
> > > > [noninteractive, stage{1,2,3}]) it calls this line:
> > > > [3]https://gist.github.com/awesomebytes/
> > ba4df9c6ef3ab5742cb9aceed7998c3d#file-bootstrap-prefix-sh-L3082[4]
> > >
> > > > bootstrap_${TODO#non} || exit 1
> > >
> > > > Which, on the noninteractive case, goes to the same place than no
> > > > arguments
> > > > (bootstrap_interactive). But in the stage{1,2,3} calls directly the
> > > > bootstrap_stageX function.
> > >
> > > > The thing is, noninteractive does some checks, finds resources and sets
> > > > up
> > > > environment variables like:
> > >
> > > > * Check for bad flags:
> > > > [4]https://gist.github.com/awesomebytes/
> > ba4df9c6ef3ab5742cb9aceed7998c3d#file-bootstrap-prefix-sh-L2200-L2247[5]
> > > > * We find a gcc:
> > > > [5]https://gist.github.com/awesomebytes/
> > ba4df9c6ef3ab5742cb9aceed7998c3d#file-bootstrap-pref
Re: [gentoo-alt] Please Bump Arm64 Prefix Stage3
What exactly do you need bumped? On 13-06-2020 08:36:08 -0500, Sid Spry wrote: > Hello, doing phone stuff. Most packages blocked by EAPI version mismatch. > -- Fabian Groffen Gentoo on a different level signature.asc Description: PGP signature
Re: [EXT] [gentoo-alt] [PREFIX] the road ahead for Darwin/macOS
On 03-06-2020 18:04:37 +, John Gibson wrote: > On Dec 27, 2019, at 5:45 AM, Fabian Groffen wrote: > > > > To all interested in Gentoo Prefix on recent macOS. > > > > In the past few releases of macOS, /usr/include has disappeared. While > > this previously was remedied by performing some commands, Apple has made > > this more strict, and it appears the way forwards, is by no longer > > relying on /usr/include. > > Hi Fabian, > > Any luck here? I'd like to install on my new Mac laptop. Not really. Current problem being that the latest binutils-apple we have is unable to interpret the objects from the system compiler. I need to upgrade that first. Thanks, Fabian -- Fabian Groffen Gentoo on a different level signature.asc Description: PGP signature
Re: [gentoo-alt] Allow non-interactive bootstrap to be stopped at arbitrary stages
too_prefix_ci_32b > > >>> Yours, > >>> Benda > > >> -- > > >> Sammy Pfeiffer > >> PhD Candidate at The Magic Lab within UTS. > > > -- > > > Sammy Pfeiffer > > PhD Candidate at The Magic Lab within UTS. > > > > References: >1. mailto:sammypfeif...@gmail.com >2. > https://gist.github.com/awesomebytes/ba4df9c6ef3ab5742cb9aceed7998c3d#file-bootstrap-prefix-sh-L3033 >3. > https://gist.github.com/awesomebytes/ba4df9c6ef3ab5742cb9aceed7998c3d#file-bootstrap-prefix-sh-L3082 >4. > https://gist.github.com/awesomebytes/ba4df9c6ef3ab5742cb9aceed7998c3d#file-bootstrap-prefix-sh-L2200-L2247 >5. > https://gist.github.com/awesomebytes/ba4df9c6ef3ab5742cb9aceed7998c3d#file-bootstrap-prefix-sh-L2273-L2433 >6. > https://gist.github.com/awesomebytes/ba4df9c6ef3ab5742cb9aceed7998c3d#file-bootstrap-prefix-sh-L2443-L2501 >7. > https://gist.github.com/awesomebytes/ba4df9c6ef3ab5742cb9aceed7998c3d#file-bootstrap-prefix-sh-L2503-L2576 >8. > https://gist.github.com/awesomebytes/ba4df9c6ef3ab5742cb9aceed7998c3d#file-bootstrap-prefix-sh-L2578-L2608 >9. > https://gist.github.com/awesomebytes/ba4df9c6ef3ab5742cb9aceed7998c3d#file-bootstrap-prefix-sh-L2610-L2681 > 10. > https://gist.github.com/awesomebytes/ba4df9c6ef3ab5742cb9aceed7998c3d#file-bootstrap-prefix-sh-L2724-L2726 > 11. > https://gist.github.com/awesomebytes/ba4df9c6ef3ab5742cb9aceed7998c3d#file-bootstrap-prefix-sh-L1355 > 12. mailto:sammypfeif...@gmail.com > 13. mailto:hero...@gentoo.org > 14. mailto:sammypfeif...@gmail.com > 15. https://gist.github.com/awesomebytes/3468477c6c90fe3d985372d50aabba9f > 16. https://wiki.gentoo.org/wiki/Project:Prefix/Manual_Bootstrap#Stage_1 > 17. https://gitweb.gentoo.org/repo/proj/prefix.git/ > 18. https://github.com/awesomebytes/gentoo_prefix_ci > 19. https://github.com/awesomebytes/gentoo_prefix_ci_32b > > read_char: errno==EILSEQ; invalid byte sequence for UTF-8: -- Fabian Groffen Gentoo on a different level signature.asc Description: PGP signature
[gentoo-alt] [PREFIX] the road ahead for Darwin/macOS
To all interested in Gentoo Prefix on recent macOS. In the past few releases of macOS, /usr/include has disappeared. While this previously was remedied by performing some commands, Apple has made this more strict, and it appears the way forwards, is by no longer relying on /usr/include. To deal with this, the packages sys-kernel/xnu-headers and sys-libs/darwin-libc-headers were added to @system for newer macOS profiles. While you may have seen these packages coming in, getting some updates here and there, they may still not be perfect, yet I think we're getting somewhere. The purpose of these packages obviously is to provide system headers and frameworks without relying on Xcode. Next I've modified the bootstrap script to unpack a Prefix-built clang compiler, and use it to bootstrap. This, in addition to the headers, allowed me to progress until stage2 where a compiler is built. This failed, for a number of reasons. 1) requirement of cmake, which is horrible. It requires way too much in terms of dependencies, so I resorted to an unpacked Prefix-built version to provide it. Can't use upstream's binaries for cmake, because they insist on using Xcode SDKs. Next, 2) clang fails to build halfway because it throws away CXXFLAGS pointing to the headers provided. I seem to remember that this is what GCC build does as well, so not that surprising, but it basically renders the approach useless. This lead me to investigating how to tell the bootstrap compiler to keep looking for the headers we provided. Turns out the compiler is hard-wired to add c++ headers (stdinc) to its search-path, and this is necessary (at least on Darwin) because the math.h header appears twice, and only one of them is compatible with c++ code. Anyway. Apple seems to use -isysroot to point to an SDK that's selected/targetted. It seems to me, at this point we should follow that lead, and simply turn the Prefix into such sysroot. Experimenting with this option on our Prefix-build clang, results in not exactly desirable behaviour. Because the offset prefix is added to the compiler's search paths, nothing ends up right. So I downloaded clang binary from llvm.org, and tried the same. That made more sense, and it seems the search path is correct there. What I want to try now, is if I can set CC/CXX to "clang -isysroot /path/to/prefix", and if that will get me through compiler building of stage2 during bootstrap. If that works, it seems the first step towards Xcode free bootstrapping on macOS. There will be some questions towards how we build our clang, if we should step away from patching it and using isysroot instead. Finally, how we're going to provide the binaries that we want to use during bootstraps. Ideally we can provide stage1/stage2 by simply installing form binpkgs, for instance using q/portage-utils. End of update, hopefully bootstrapping can be working again soon. Thanks, Fabian -- Fabian Groffen Gentoo on a different level signature.asc Description: PGP signature
Re: [gentoo-alt] Prefix-standalone profile has upgraded into dev
On 30-09-2019 09:28:17 +0800, Benda Xu wrote: > Jacob Godserv writes: > > > Wow! This is huge! Congratulations to the Prefix team for their hard > > work and the unofficial volunteers that supported them! This has been > > so long in the making I resigned myself to it never > > happening. Incredible! > > Thank you Jacob. It has been a long journey since around ~2005 > (@Fabian, correct me if I am wrong). Prefix has gradually matured over > the years, with love from all of us in the community. I joined in 2005. At that time there were a few hundreds of packages keyworded for ~ppc-macos. Main people that had been working on there (that I know of) were ferringb, kito, pvdabeel, gongloo and j4rg0n. The project started as Gentoo for Mac OS X. Around 2008 this became Gentoo Prefix (as we know it today) because a shift was made from installing "missing" software on Mac OS X in the usual locations (/usr/bin, etc.) to installing replacement software in a different location, replacing host software, and therefore relying as little as possible on that software. Initially it was easy to use Mac OS X's provided software, because it was up-to-date, but as time went, the software became outdated (think of automake/autoconf, often a problem) and problematic (Apple-specific modifications, or unfixed bugs because of old versions). Thus the only way forward was to install as much as possible Gentoo "versions", the sole aim of Gentoo Prefix. > The feeling that Prefix would remain an experimental project was real. > But as the quality of Prefix steadily grows, we could envision it to be > of production level hereafter. I'm happy to see it more mature for the Linux platforms. We've always been struggling to keep it "working". Historically, the macOS "target" was best supported, followed by Solaris, but as these platforms continued to evolve, or age, we couldn't always keep up fixing the packages and bootstrap process. Even today this is the case. There were a lot of contributors as wel as Gentoo devs that came and went over the years, making countless efforts and spending many hours to analyse, test and fix packages, processes or scenarios. For those of you, if you're still watching, your input has been vital for making the project what it has become today. It's still running, and for some scenarios still working fine/being super useful. Thanks a lot, Fabian > Big cheers to us all. > > Yours, > Benda > -- Fabian Groffen Gentoo on a different level signature.asc Description: PGP signature
Re: [gentoo-alt] Prefix on Darwin, ppc64
H, I gave up on ppc64, I tried not too long ago, but ran in these kinds of errors. I'm surprised it ever worked, actually! ppc-macos should be fine though, using gcc-8, clang is a no-go on ppc. Fabian On 10-09-2019 17:08:22 -0700, Johan Hattne wrote: > Dear all; > > I’m lead to believe that there’s at least one other person with a 64-bit PPC > Mac at hand. I see this problem with the linker when I try to build e.g. > gcc-apple: > > powerpc64-apple-darwin9-gcc -m64 -std=gnu89 -g -fkeep-inline-functions > -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes > -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings > -Wold-style-definition -Wmissing-format-attribute -fno-common > -DHAVE_CONFIG_H -o cc1-dummy c-lang.o stub-objc.o attribs.o c-errors.o > c-lex.o c-pragma.o c-decl.o c-typeck.o c-convert.o c-aux-info.o c-common.o > c-opts.o c-format.o c-semantics.o c-incpath.o cppdefault.o c-ppoutput.o > c-cppbuiltin.o prefix.o c-objc-common.o c-dump.o c-pch.o c-parser.o > darwin-c.o rs6000-c.o c-gimplify.o tree-mudflap.o c-pretty-print.o c-omp.o > dummy-checksum.o \ > main.o tree-browser.o libbackend.a ../libcpp/libcpp.a > ../libdecnumber/libdecnumber.a ../libcpp/libcpp.a > -L/home/hattne/Gentoo/usr/lib -lintl -L/home/hattne/Gentoo/usr/lib -liconv > ../libiberty/libiberty.a ../libdecnumber/libdecnumber.a > ld: bl out of range (-17201436 max is +/-16M) from _predict_loops at > 0x101321154 in __text of libbackend.a(predict.o) to _scev_initialize at > 0x1002B9878 in __text of libbackend.a(tree-scalar-evolution.o) in > _predict_loops from libbackend.a(predict.o) > collect2: error: ld returned 1 exit status > > This is within an old prefix, with 4.2.1_p5666-r1 and binutils-apple-3.2.6. > I’ve googled a bit, but haven’t found anything. Is the above something > anybody recognizes? > > // Best wishes; Johan -- Fabian Groffen Gentoo on a different level signature.asc Description: PGP signature
[gentoo-alt] [PREFIX] future of Solaris 10?
All, I recently noticed ISC bind people went on a killing spree for "old" systems and removed support for many older systems, including Solaris 10. GCC still supports it, but it's deprecated already. Solaris 10 should be in "Extendended support or Sustaining support" mode, since Feb 1st 2018. It's not really dead yet, but it won't get any improvements, or something like that. I've been running an old Sun Blade 100 (UltraSPARC IIe 500MHz) with Solaris 10 for years, it's been doing the sparc and sparcv9 targets on bootstraps (have patience :) ) successfully not too long ago: http://bootstrap.prefix.bitzolder.nl/results/ Since Solaris 11.4 isn't supported on this machine (heh), tribblix appears to be the only option if I want to run something more recent on the machine. This would effectively test illumnos (Solaris 11 isn't working for Prefix since its first appearance). Question here, are there still consumers for Solaris 10? I don't feel everything is broken beyond repair at this point. Thoughts? Thanks, Fabian -- Fabian Groffen Gentoo on a different level signature.asc Description: PGP signature
Re: [gentoo-alt] I tried installing gentoo prefix on WSL2 running debian.....
Here's an idea for you: in $EPREFIX/etc/bash/bashrc.d/Michael.sh add this: export GENTOO_PREFIX_ACTIVE=1 then in your .bashrc: if [ -z $GENTOO_PREFIX_ACTIVE ] ; then # Use global profile when available if [ -f /usr/share/defaults/etc/profile ]; then . /usr/share/defaults/etc/profile fi allow admin overrides if [ -f /etc/profile ]; then . /etc/profile fi fi Now when you ssh to your box, you'll get the env and setup from your host, once you run startprefix, it should be all Gentoo Prefix. Fabian On 18-07-2019 09:34:11 +, Michael Fothergill wrote: > I have managed to hack my way back into clear linux. > > It now doesn't find the profile file as expected. > > bash: /etc/profile: No such file or directory > > Both emerge and eselect news read run OK now. > > Regards > > MF > > > read_char: errno==EILSEQ; invalid byte sequence for UTF-8: -- Fabian Groffen Gentoo on a different level signature.asc Description: PGP signature
Re: [gentoo-alt] I tried installing gentoo prefix on WSL2 running debian.....
It's VERY unlikely that messing around with your .bashrc results in a "unknown user" login error. On 18-07-2019 10:19:57 +0100, Michael Fothergill wrote: > I tried this but now I cannot log back in again. > > The log in box doesn't recognise my username. > > Something like rescatux or some other system recovery software might help > here. > > I could use a live distro of debian to resize the root partition to create > some > free space and then install debian alongside it > > and then chroot into the clear linux install and fix the .bashrc file and > rescue > clear linux and prefix together. > > Comments appreciated. > > Regards > > MF > > On Thu, 18 Jul 2019 at 10:05, Fabian Groffen <[1]grob...@gentoo.org> wrote: > > > On 18-07-2019 09:02:49 +, Michael Fothergill wrote: > > > Dear All, > > > > > > I have edited the .bashrc file and commented out the offending lines. > > > > > > See here: > > > > > > more ../.bashrc > > > # Use global profile when available > > > #if [ -f /usr/share/defaults/etc/profile ]; then > > > # . /usr/share/defaults/etc/profile > > > #fi > > > # allow admin overrides > > > if [ -f /etc/profile ]; then > > > . /etc/profile > > > fi > > > I would remove the above one too... > > > > Exiting on signal Signals.SIGINT > > > mikef@clr-0fdd1f831fb14378ac28883a158cf04d ~/gentoo $ eselect read news > > > !!! Error: Can't load module read > > > exiting > > > $ eselect news read > > > :) > > > Fabian > > > -- > > Fabian Groffen > > Gentoo on a different level > > > > References: >1. mailto:grob...@gentoo.org > > read_char: errno==EILSEQ; invalid byte sequence for UTF-8: -- Fabian Groffen Gentoo on a different level signature.asc Description: PGP signature
Re: [gentoo-alt] I tried installing gentoo prefix on WSL2 running debian.....
On 18-07-2019 09:02:49 +, Michael Fothergill wrote: > Dear All, > > I have edited the .bashrc file and commented out the offending lines. > > See here: > > more ../.bashrc > # Use global profile when available > #if [ -f /usr/share/defaults/etc/profile ]; then > # . /usr/share/defaults/etc/profile > #fi > # allow admin overrides > if [ -f /etc/profile ]; then > . /etc/profile > fi I would remove the above one too... > Exiting on signal Signals.SIGINT > mikef@clr-0fdd1f831fb14378ac28883a158cf04d ~/gentoo $ eselect read news > !!! Error: Can't load module read > exiting $ eselect news read :) Fabian -- Fabian Groffen Gentoo on a different level signature.asc Description: PGP signature
Re: [gentoo-alt] I tried installing gentoo prefix on WSL2 running debian.....
On 18-07-2019 08:12:28 +, Michael Fothergill wrote: > Many thanks for your email and advice. > > On Thu, 18 Jul 2019 at 08:22, Fabian Groffen <[1]grob...@gentoo.org> wrote: > > > Your path is zapped by your .bashrc or something. Did the bootstrap > > script give a message/warning about this near the end of its execution? > > It should have. > > I remember a grumble about the path being overridden in some way by the host > OS > and warning me to fix this. > > It did this in other prefix installations but in practice prefix runs > perfectly > OK in them. > > But this time when the boy cried wolf it seems the wolf really was there after > all. > > I have looked at web pages explaining about the path in linux. > > I could run a command to add the path to the emerge directory to the path > list. > > But I don't know if that would help here. > > What would happen if I deleted the .bashrc file itself? That makes it work, but it's a bit crude ... You probably want to remove/comment the bits that source /etc/bashrc/ or something similar, that should probably help some. Fabian > > Comments appreciated. > > Regards > > MF > > PS A link to a copy of the stage 3 log file is attached below. > [2] stage3.log > > > > References: >1. mailto:grob...@gentoo.org >2. > https://drive.google.com/file/d/1RF7GojXGAAxZMZMUXhkHt_ND8QdEGchq/view?usp=drive_web > > read_char: errno==EILSEQ; invalid byte sequence for UTF-8: -- Fabian Groffen Gentoo on a different level signature.asc Description: PGP signature
Re: [gentoo-alt] I tried installing gentoo prefix on WSL2 running debian.....
Your path is zapped by your .bashrc or something. Did the bootstrap script give a message/warning about this near the end of its execution? It should have. Fabian On 17-07-2019 21:18:25 +0100, Michael Fothergill wrote: > Many thanks. > > Gentoo prefix installed successfully on clear linux. > > But something is wrong with the path to start the prefix working properly. > > emerge and eselect news read commands are not found. > > I changed directory to /home/mikef/gentoo/usr/bin and found emerge. > > I ran /home/mikef/gentoo/usr/bin/emerge --update --newuse @world as a > command. > > It ran OK. > > I need to set the locale. > > I ran /home/mikef/gentoo/usr/bin/eselect news read > > The error says that the package manager cannot get a list of repositories. > > echo $PATH > > gives > > /usr/local/bin:/usr/bin:/opt/3rd-party/bin > > Comments appreciated > > Regards > > MF > > > read_char: errno==EILSEQ; invalid byte sequence for UTF-8: -- Fabian Groffen Gentoo on a different level signature.asc Description: PGP signature
Re: [gentoo-alt] I tried installing gentoo prefix on WSL2 running debian.....
Thanks for following through with this. Too bad it isn't ready yet. Fabian On 06-07-2019 15:27:10 +0100, Michael Fothergill wrote: > Many thanks for all the help. > > I think that WSL2 is not quite ready for gentoo prefix at present. > > I tried several repeat tries with the installer. > > It is stuck in a loop of permission errors. > > I will try again Microsoft puts out another significant update. > > The WSL team they have will be aware of the kinds of problems I have > encountered > here. > > Regards > > MF > > > read_char: errno==EILSEQ; invalid byte sequence for UTF-8: -- Fabian Groffen Gentoo on a different level signature.asc Description: PGP signature
Re: [gentoo-alt] I tried installing gentoo prefix on WSL2 running debian.....
It's the same problem, so intermittent. I wonder if this can be worked around with some retries. Basically a limitation of windows/ntfs at this point I presume. On 04-07-2019 07:11:20 +0100, Michael Fothergill wrote: > > I ran the installation again . > > After 10 hours it crashed at a different point but with a "spawn-esque" > permission problem: > > !!! Failed to move > /home/mikef/gentoo/var/db/pkg/sys-apps/-MERGING-coreutils-8.31 to > /home/mikef/gentoo/var/db/pkg/sys-apps/coreutils-8.31 > !!! [Errno 13] Permission denied: > b'/home/mikef/gentoo/var/db/pkg/sys-apps/-MERGING-coreutils-8.31' -> > b'/home/mikef/gentoo/var/db/pkg/sys-apps/coreutils-8.31' > Traceback (most recent call last): > File > "/home/mikef/gentoo/tmp/usr/lib/python3.6/portage/dbapi/_MergeProcess.py", > line > 234, in _spawn > prev_mtimes=self.prev_mtimes, counter=counter) > File "/home/mikef/gentoo/tmp/usr/lib/python3.6/portage/dbapi/vartree.py", > line > 1691, in wrapper > return f(self, *args, **kwargs) > File "/home/mikef/gentoo/tmp/usr/lib/python3.6/portage/dbapi/vartree.py", > line > 5194, in merge > counter=counter) > File "/home/mikef/gentoo/tmp/usr/lib/python3.6/portage/dbapi/vartree.py", > line > 4465, in treewalk > _movefile(self.dbtmpdir, self.dbpkgdir, mysettings=self.settings) > File "/home/mikef/gentoo/tmp/usr/lib/python3.6/portage/__init__.py", line > 515, > in _movefile > "mv '%s' '%s'" % (src, dest)) > portage.exception.PortageException: mv > '/home/mikef/gentoo/var/db/pkg/sys-apps/-MERGING-coreutils-8.31' > '/home/mikef/gentoo/var/db/pkg/sys-apps/coreutils-8.31' > > >>> Failed to install sys-apps/coreutils-8.31, Log file: > > >>> > >>> '/home/mikef/gentoo/var/tmp/portage/sys-apps/coreutils-8.31/temp/build.log' > > I think you should be able to see the log file here: > > [1]https://drive.google.com/file/d/1yysBKt7n0MTXwZb2TAymZjiTpyZ5Y3ep/view?usp=drive_web > > It would be nice to be able to make use of ccache in these reruns > > Regards > > MF > > > > > > > References: >1. > https://drive.google.com/file/d/1yysBKt7n0MTXwZb2TAymZjiTpyZ5Y3ep/view?usp=drive_web > > read_char: errno==EILSEQ; invalid byte sequence for UTF-8: -- Fabian Groffen Gentoo on a different level signature.asc Description: PGP signature
Re: [gentoo-alt] I tried installing gentoo prefix on WSL2 running debian.....
Just run bootstrap-prefix.sh again with the same answers to its questions On 03-07-2019 19:34:52 +0100, Michael Fothergill wrote: > Do you mean the resume command you use alongside emerge -- skipfirst etc? > > Regards > > MF > > On Wed, 3 Jul 2019, 19:21 Fabian Groffen, <[1]grob...@gentoo.org> wrote: > > > portage expects it can rename a directory ... that fails, suddenly. > > > If you resume, does it just continue? > > > Fabian > > > On 03-07-2019 19:17:20 +0100, Michael Fothergill wrote: > > > Yes. > > > > > > The parent debian OS lives on the ntfs partition alongside Windows 10. > > > > > > WSL 2 is Microsoft''s latest foray into Linux. > > > > > > I will see what I can find out about this EPERM thing. > > > > > > Regards > > > > > > MF > > > > > > > > > read_char: errno==EILSEQ; invalid byte sequence for UTF-8: > > -- > > Fabian Groffen > > Gentoo on a different level > > > > References: >1. mailto:grob...@gentoo.org > > read_char: errno==EILSEQ; invalid byte sequence for UTF-8: -- Fabian Groffen Gentoo on a different level signature.asc Description: PGP signature
Re: [gentoo-alt] I tried installing gentoo prefix on WSL2 running debian.....
portage expects it can rename a directory ... that fails, suddenly. If you resume, does it just continue? Fabian On 03-07-2019 19:17:20 +0100, Michael Fothergill wrote: > Yes. > > The parent debian OS lives on the ntfs partition alongside Windows 10. > > WSL 2 is Microsoft''s latest foray into Linux. > > I will see what I can find out about this EPERM thing. > > Regards > > MF > > > read_char: errno==EILSEQ; invalid byte sequence for UTF-8: -- Fabian Groffen Gentoo on a different level signature.asc Description: PGP signature
Re: [gentoo-alt] I tried installing gentoo prefix on WSL2 running debian.....
On 02-07-2019 22:48:57 +0100, Michael Fothergill wrote: > !!! Failed to move > /home/mikef/gentoo/var/db/pkg/sys-devel/-MERGING-binutils-2.32-r1 to > /home/mikef/gentoo/var/db/pkg/sys-devel/binutils-2.32-r1 > !!! [Errno 13] Permission denied: > b'/home/mikef/gentoo/var/db/pkg/sys-devel/-MERGING-binutils-2.32-r1' -> > b'/home/mikef/gentoo/var/db/pkg/sys-devel/binutils-2.32-r1' I don't think it's fair that Portage bombs out after this, but this EPERM is odd, if not very odd. Is this on NFS or something? Fabian -- Fabian Groffen Gentoo on a different level signature.asc Description: PGP signature
Re: [gentoo-alt] I tried installing gentoo prefix on WSL2 running debian.....
configure:4968: g++ -c -g -I/home/mikef/gentoo/tmp/usr/include conftest.cpp >&5 /home/mikef/gentoo/tmp/usr/local/bin/g++: 3: exec: g++: not found I remember this problem from Ubuntu bootstraps, you need to apt-get g++. Fabian On 02-07-2019 12:45:11 +0100, Michael Fothergill wrote: > This early piece of output does not look encouraging to me: > > gcc version 6.3.0 20170516 (Debian 6.3.0-18+deb9u1) > configure:4306: $? = 0 > configure:4295: gcc -V >&5 > gcc: error: unrecognized command line option '-V' > gcc: fatal error: no input files > compilation terminated. > configure:4306: $? = 1 > configure:4295: gcc -qversion >&5 > gcc: error: unrecognized command line option '-qversion'; did you mean > '--version'? > gcc: fatal error: no input files > compilation terminated. > configure:4306: $? = 1 > > Comments appreciated. > > Regards > > MF > > On Tue, 2 Jul 2019 at 12:40, Michael Fothergill > <[1]michael.fotherg...@gmail.com> wrote: > > > I tried installing emacs but it is awkward to use in the windows terminal. > > > Regards > > > MF > > > > References: >1. mailto:michael.fotherg...@gmail.com > > read_char: errno==EILSEQ; invalid byte sequence for UTF-8: -- Fabian Groffen Gentoo on a different level signature.asc Description: PGP signature
Re: [gentoo-alt] I tried installing gentoo prefix on WSL2 running debian.....
Open config.log in an editor (e.g. nano) and search for /lib/cpp. Then a bound of lines around that are the interesting ones. On 02-07-2019 10:56:32 +0100, Michael Fothergill wrote: > Many thanks again. > > I have posted as much of the config.log file as the terminal buffer retains > here: > > [1]https://paste.debian.net/1089991/ > > Comments appreciated. > > Regards > > Michael > > > > References: >1. https://paste.debian.net/1089991/ > > read_char: errno==EILSEQ; invalid byte sequence for UTF-8: -- Fabian Groffen Gentoo on a different level signature.asc Description: PGP signature
Re: [gentoo-alt] I tried installing gentoo prefix on WSL2 running debian.....
We really need the config.log file around the place where it tests for /lib/ccp, which is the thing it believes is non-sane in your system. Fabian On 02-07-2019 10:15:06 +0100, Michael Fothergill wrote: > > Many thanks for your help again. > > I did the export command as you suggested and then ran the bootstrap script > again. > > It started at stage 2 and ran through and crashed again exactly as before. > > No cure yet. > > I can't emerge wgetpaste yet. > > So I have posted as much of the build log as the terminal buffer retains here: > > [1]https://paste.debian.net/1089980/ > > Suggestions on another solution is appreciated. > > Regards > > Michael > > > > References: >1. https://paste.debian.net/1089980/ > > read_char: errno==EILSEQ; invalid byte sequence for UTF-8: -- Fabian Groffen Gentoo on a different level signature.asc Description: PGP signature
Re: [gentoo-alt] I tried installing gentoo prefix on WSL2 running debian.....
sorry, I got the variable name wrong, it should be: export LATEST_TREE_YES=1 ./bootstrap-prefix.sh Fabian On 02-07-2019 10:20:49 +0200, Fabian Groffen wrote: > Can you try again after exporting LATEST_TREE=yes? Just to be sure, I > though I'd seen something in this area. > > Fabian > > > On 02-07-2019 08:52:59 +0100, Michael Fothergill wrote: > > Dear All. > > > > For a bit of fun I tried installing gentoo prefix on a debian stretch > > install > > running under WSL2 (Linux subsystem on Windows 10). > > > > The installation went OK until stage 2. I did not need to recruit a > > version of > > m4 from debian. I think Fabian Grobian's bug fix did that. > > > > A problem occurred with sys-devel/binutils: > > > > configure: error: in > > `/home/mikef/gentoo/tmp/var/tmp/portage/sys-devel/binutils-2.32-r1/work/build/gold': > > configure: error: C++ preprocessor "/lib/cpp" fails sanity check > > See `config.log' for more details > > config.status: executing default-1 commands > > config.status: creating po/POTFILES > > config.status: creating po/Makefile > > make[1]: *** [Makefile:5994: configure-gold] Error 1 > > make[1]: *** Waiting for unfinished jobs > > -lfl > > > > The output to the terminal buffer is here: > > > > [1]https://paste.debian.net/1089974/ > > > > Comments appreciated. > > > > My tutorial is getting longer > > > > Regards > > > > Michael Fothergill > > > > > > > > References: > >1. https://paste.debian.net/1089974/ > > > > read_char: errno==EILSEQ; invalid byte sequence for UTF-8: > -- > Fabian Groffen > Gentoo on a different level -- Fabian Groffen Gentoo on a different level signature.asc Description: PGP signature
Re: [gentoo-alt] I tried installing gentoo prefix on WSL2 running debian.....
Can you try again after exporting LATEST_TREE=yes? Just to be sure, I though I'd seen something in this area. Fabian On 02-07-2019 08:52:59 +0100, Michael Fothergill wrote: > Dear All. > > For a bit of fun I tried installing gentoo prefix on a debian stretch install > running under WSL2 (Linux subsystem on Windows 10). > > The installation went OK until stage 2. I did not need to recruit a version > of > m4 from debian. I think Fabian Grobian's bug fix did that. > > A problem occurred with sys-devel/binutils: > > configure: error: in > `/home/mikef/gentoo/tmp/var/tmp/portage/sys-devel/binutils-2.32-r1/work/build/gold': > configure: error: C++ preprocessor "/lib/cpp" fails sanity check > See `config.log' for more details > config.status: executing default-1 commands > config.status: creating po/POTFILES > config.status: creating po/Makefile > make[1]: *** [Makefile:5994: configure-gold] Error 1 > make[1]: *** Waiting for unfinished jobs > -lfl > > The output to the terminal buffer is here: > > [1]https://paste.debian.net/1089974/ > > Comments appreciated. > > My tutorial is getting longer > > Regards > > Michael Fothergill > > > > References: >1. https://paste.debian.net/1089974/ > > read_char: errno==EILSEQ; invalid byte sequence for UTF-8: -- Fabian Groffen Gentoo on a different level signature.asc Description: PGP signature
Re: [gentoo-alt] Re: simple question about installing chromium browser for use in debian OS using gentoo prefix..
Then now it should be as chromium wants it to be ... I'll keep my fingers crossed it works this time. Fabian On 28-06-2019 11:22:37 +0100, Michael Fothergill wrote: > I ran the chmod 4755 command again and now there is an "s" present.. > > mikef@fart:~/gentoo/etc/portage$ !472 > ls -la /home/mikef/gentoo/usr/lib64/chromium-browser/chrome-sandbox > -rwsr-xr-x 1 root root 22384 Jun 26 01:52 > /home/mikef/gentoo/usr/lib64/chromium-browser/chrome-sandbox > > Regards > > MF > > On Fri, 28 Jun 2019 at 11:19, Fabian Groffen <[1]grob...@gentoo.org> wrote: > > > chmod 4755 the file again, and check ls -la > > > On 28-06-2019 10:11:06 +0100, Michael Fothergill wrote: > > > Many thanks again. > > > > > > I ran the command to list the chromium sand box file: > > > > > > mikef@fart:~/gentoo/etc/portage$ ls -la > > > /home/mikef/gentoo/usr/lib64/chromium-browser/chrome-sandbox > > > -rwxr-xr-x 1 root root 22384 Jun 26 01:52 > > > /home/mikef/gentoo/usr/lib64/chromium-browser/chrome-sandbox > > > mikef@fart:~/gentoo/etc/portage$ > > > > > > I don't see any "s" in it but it is owned by root. > > > > > > Regards > > > > > > MF > > > > > > > > > read_char: errno==EILSEQ; invalid byte sequence for UTF-8: > > -- > > Fabian Groffen > > Gentoo on a different level > > > > References: >1. mailto:grob...@gentoo.org > > read_char: errno==EILSEQ; invalid byte sequence for UTF-8: -- Fabian Groffen Gentoo on a different level signature.asc Description: PGP signature
Re: [gentoo-alt] Re: simple question about installing chromium browser for use in debian OS using gentoo prefix..
chmod 4755 the file again, and check ls -la On 28-06-2019 10:11:06 +0100, Michael Fothergill wrote: > Many thanks again. > > I ran the command to list the chromium sand box file: > > mikef@fart:~/gentoo/etc/portage$ ls -la > /home/mikef/gentoo/usr/lib64/chromium-browser/chrome-sandbox > -rwxr-xr-x 1 root root 22384 Jun 26 01:52 > /home/mikef/gentoo/usr/lib64/chromium-browser/chrome-sandbox > mikef@fart:~/gentoo/etc/portage$ > > I don't see any "s" in it but it is owned by root. > > Regards > > MF > > > read_char: errno==EILSEQ; invalid byte sequence for UTF-8: -- Fabian Groffen Gentoo on a different level signature.asc Description: PGP signature
Re: [gentoo-alt] Re: simple question about installing chromium browser for use in debian OS using gentoo prefix..
On 28-06-2019 10:00:04 +0100, Michael Fothergill wrote: > I ran the command you suggested (should it be the chown command for a group - > would the chgrp command be help here?): > > root@fart:/home/mikef/gentoo# chown root: > /home/mikef/gentoo/usr/lib64/chromium-browser/chrome-sandbox > root@fart:/home/mikef/gentoo# > > It still gives the same error: > > mikef@fart:~$ /home/mikef/gentoo/usr/bin/chromium > [2223:2223:0628/084737.606858:FATAL:setuid_sandbox_host.cc(157)] The SUID > sandbox helper binary was found, but is not configured correctly. Rather than > run without sandboxing I'm aborting now. You need to make sure that > /home/mikef/gentoo/usr/lib64/chromium-browser/chrome-sandbox is owned by root > and has mode 4755. This seems pretty clear. Run ls -la /home/mikef/gentoo/usr/lib64/chromium-browser/chrome-sandbox That should show the file is owned by root, and that it has rwxr-xr-x with an s somewhere. Fabian > > I added an extra line into the package.use file when I was trying to get xorg > to > work as non root: > > mikef@fart:~/gentoo/etc/portage$ more package.use > x11-base/xorg-server -suid > # required by www-client/chromium-74.0.3729.169::gentoo > # required by chromium (argument) > >=dev-libs/libxml2-2.9.9-r1 icu > # required by www-client/chromium-74.0.3729.169::gentoo > # required by chromium (argument) > >=media-libs/harfbuzz-2.5.1 icu > # required by www-client/chromium-74.0.3729.169::gentoo > # required by chromium (argument) > >=sys-libs/zlib-1.2.11-r2 minizip > # required by www-client/chromium-74.0.3729.169::gentoo > # required by chromium (argument) > >=net-libs/nodejs-11.14.0 inspector > # required by x11-misc/xdg-utils-1.1.3-r1::gentoo > # required by www-client/chromium-74.0.3729.169::gentoo > # required by chromium (argument) > >=app-text/xmlto-0.0.28-r1 text > # required by x11-libs/gtk+-3.24.8::gentoo > # required by x11-themes/adwaita-icon-theme-3.30.1::gentoo > # required by x11-libs/gtk+-2.24.32-r1::gentoo > # required by x11-themes/gtk-engines-adwaita-3.28::gentoo > >=x11-libs/cairo-1.16.0-r3 X > # required by www-client/chromium-74.0.3729.169::gentoo > # required by chromium (argument) > =net-libs/nodejs-10.15.3 inspector > # required by www-client/chromium-74.0.3729.169::gentoo > # required by chromium (argument) > =net-libs/nodejs-8.16.0 inspector > # required by www-client/chromium-74.0.3729.169::gentoo > # required by chromium (argument) > =net-libs/nodejs-8.12.0 inspector > mikef@fart:~/gentoo/etc/portage$ > > It is affecting the suid function > > I commented it out but it did not help. > > Regards > > MF > > > read_char: errno==EILSEQ; invalid byte sequence for UTF-8: -- Fabian Groffen Gentoo on a different level signature.asc Description: PGP signature
Re: [gentoo-alt] Re: simple question about installing chromium browser for use in debian OS using gentoo prefix..
try # chown root: /home/mikef/gentoo/usr/lib64/chromium-browser/chrome-sandbox perhaps chromium also cares about the group On 28-06-2019 09:36:59 +0100, Michael Fothergill wrote: > Many thanks again for your advice. > > I ran the two commands you recommended: > > root@fart:/home/mikef/gentoo# chmod 4755 > /home/mikef/gentoo/usr/lib64/chromium-browser/chrome-sandbox > root@fart:/home/mikef/gentoo# chown root > /home/mikef/gentoo/usr/lib64/chromium-browser/chrome-sandbox > root@fart:/home/mikef/gentoo# /home/mikef/gentoo/usr/bin/chromium > [2098:2098:0628/083242.274727:ERROR:zygote_host_impl_linux.cc(89)] Running as > root without --no-sandbox is not supported. See [1]https://crbug.com/638180. > root@fart:/home/mikef/gentoo# > > I also tried running chromium as a user: > > mikef@fart:~$ /home/mikef/gentoo/usr/bin/chromium > [2105:2105:0628/083309.657067:FATAL:setuid_sandbox_host.cc(157)] The SUID > sandbox helper binary was found, but is not configured correctly. Rather than > run without sandboxing I'm aborting now. You need to make sure that > /home/mikef/gentoo/usr/lib64/chromium-browser/chrome-sandbox is owned by root > and has mode 4755. > > Maybe I need to talk to the chrome community. > > Regards > > MF > > > > References: >1. https://crbug.com/638180 > > read_char: errno==EILSEQ; invalid byte sequence for UTF-8: -- Fabian Groffen Gentoo on a different level signature.asc Description: PGP signature
Re: [gentoo-alt] Re: simple question about installing chromium browser for use in debian OS using gentoo prefix..
Chromium is just not going to be helpful here. If you've got root, you'll have to do something like: # chmod 4755 /home/mikef/gentoo/usr/lib64/chromium-browser/chrome-sandbox # chown root /home/mikef/gentoo/usr/lib64/chromium-browser/chrome-sandbox then run chromium as user. Fabian On 28-06-2019 09:27:49 +0100, Michael Fothergill wrote: > Many thanks for your response. > > I tried running chromium to see if it would work. > > I did as user and then as root. > > mikef@fart:~$ /home/mikef/gentoo/usr/bin/chromium > [1459:1459:0628/081848.057654:FATAL:setuid_sandbox_host.cc(157)] The SUID > sandbox helper binary was found, but is not configured correctly. Rather than > run without sandboxing I'm aborting now. You need to make sure that > /home/mikef/gentoo/usr/lib64/chromium-browser/chrome-sandbox is owned by root > and has mode 4755. > > as root > > root@fart:/home/mikef/gentoo# /home/mikef/gentoo/usr/bin/chromium > [1568:1568:0628/082021.807096:ERROR:zygote_host_impl_linux.cc(89)] Running as > root without --no-sandbox is not supported. See [1]https://crbug.com/638180. > > Suggestions on a fix here would be appreciated. > > If I get away with using the xorg-server of debian than that would be very > helpful. > > Regards > > MF > > > > References: >1. https://crbug.com/638180 > > read_char: errno==EILSEQ; invalid byte sequence for UTF-8: -- Fabian Groffen Gentoo on a different level signature.asc Description: PGP signature
Re: [gentoo-alt] Re: simple question about installing chromium browser for use in debian OS using gentoo prefix..
Michael, I don't think you should be trying to run startx at all. In fact, I think you already have one x running, so why run another one? This is typically one such thing that needs "root" privileges, and most likely you can also just use as-is from the host system. Why won't chromium start for you? You had it emerged, hadn't you? Fabian On 27-06-2019 22:23:22 +0100, Michael Fothergill wrote: > I also ran this command: > > mikef@fart:~/gentoo$ startx -- vt1 > > X.Org X Server 1.20.5 > X Protocol Version 11, Revision 0 > Build Operating System: Linux 4.19.0-5-amd64 x86_64 Gentoo > Current Operating System: Linux fart 4.19.0-5-amd64 #1 SMP Debian 4.19.37-3 > (2019-05-15) x86_64 > Kernel command line: BOOT_IMAGE=/boot/vmlinuz-4.19.0-5-amd64 > root=UUID=3097928b-798b-4ff0-9576-f0f020963daf ro quiet > Build Date: 27 June 2019 09:07:40PM > > Current version of pixman: 0.38.4 > Before reporting problems, check [1]http://wiki.x.org > to make sure that you have the latest version. > Markers: (--) probed, (**) from config file, (==) default setting, > (++) from command line, (!!) notice, (II) informational, > (WW) warning, (EE) error, (NI) not implemented, (??) unknown. > (==) Log file: "/home/mikef/.local/share/xorg/Xorg.1.log", Time: Thu Jun 27 > 21:19:35 2019 > (==) Using system config directory > "/home/mikef/gentoo/usr/share/X11/xorg.conf.d" > (EE) > Fatal server error: > (EE) xf86OpenConsole: Cannot open virtual console 1 (Permission denied) > (EE) > (EE) > Please consult the The X.Org Foundation support > at [2]http://wiki.x.org > for help. > (EE) Please also check the log file at > "/home/mikef/.local/share/xorg/Xorg.1.log" for additional information. > (EE) > (EE) Server terminated with error (1). Closing log file. > xinit: giving up > xinit: unable to connect to X server: Connection refused > xinit: server error > Couldn't get a file descriptor referring to the console > > I don't the permission as a user.. > > Regards > > MF > > > > References: >1. http://wiki.x.org >2. http://wiki.x.org > > read_char: errno==EILSEQ; invalid byte sequence for UTF-8: -- Fabian Groffen Gentoo on a different level signature.asc Description: PGP signature
Re: [gentoo-alt] Re: simple question about installing chromium browser for use in debian OS using gentoo prefix..
On 27-06-2019 22:15:38 +0100, Michael Fothergill wrote: > Dear All, > > I put the line > > x11-base/xorg-server -suid > > into the package.use file. > > I did the source update FYI, you don't have to source things after editing files in $EPREFIX/etc/portage/ > I then ran emerge xorg-server again. > > It ran OK until it decided it needed to emerge sys-fs/udev-init-scripts > > as a result of the -suid change: > * QA Notice: the following files are outside of the prefix: > * /etc > * /etc/conf.d > * /etc/conf.d/udev-settle > * /etc/conf.d/udev > * /etc/conf.d/udev-trigger > * /etc/init.d > * /etc/init.d/udev-settle > * /etc/init.d/udev > * /etc/init.d/udev-trigger > * ERROR: sys-fs/udev-init-scripts-33::gentoo failed: > * Aborting due to QA concerns: there are files installed outside the prefix > * > * Call stack: > > Do you have a fix for this? This is a similar problem as before. The fix is less obvious though. Since this package is not going to be working/useful in Prefix as is, I think it's better to avoid having this one installed. Do you know how to figure out which package needs sys-fs/udev-init-scripts? Fabian -- Fabian Groffen Gentoo on a different level signature.asc Description: PGP signature
Re: [gentoo-alt] Re: simple question about installing chromium browser for use in debian OS using gentoo prefix..
You got it compiled/installed, you don't need diff/patch anymore now :) On 27-06-2019 13:15:09 +0100, Michael Fothergill wrote: > I did it and I ran emerge libinput and it has compiled and installed. > > What do I run the diff command on? > > I don't even know if I have diff installed. > > Regards > > MF > > > read_char: errno==EILSEQ; invalid byte sequence for UTF-8: -- Fabian Groffen Gentoo on a different level signature.asc Description: PGP signature
Re: [gentoo-alt] Re: simple question about installing chromium browser for use in debian OS using gentoo prefix..
On 27-06-2019 13:06:40 +0100, Michael Fothergill wrote:
> Looking at your patch code based on what you have just explained,
>
> I could go back and re-edit the build file and remove the extra code I added
> at
> the end restoring the file to its original state.
>
> Then I could move the cursor up to the following section of the build file:
>
> src_configure() {
> # gui can be built but will not be installed
> local emesonargs=(
> -Ddebug-gui=false
> $(meson_use doc documentation)
> $(meson_use input_devices_wacom libwacom)
> -Dtests=false # tests are restricted
> -Dudev-dir="$(get_udevdir)"
> )
> meson_src_configure
>
> and then replace the line -Dudev-dir="$(get_udevdir) with
>
> -Dudev-dir="${EPREFIX}$(get_udevdir)
>
> Your patch also has these lines in it:
>
> --- a/dev-libs/libinput/libinput-1.13.2.ebuild
> +++ b/dev-libs/libinput/libinput-1.13.2.ebuild
> @@ -60,7 +60,7 @@ src_configure() {
>
> are these lines suggesting that I make any other changes to the ebuild file?
>
> They look like they are saying that an ebuild file has to be changed in a
> particular section.
>
> If the only change I have to make is the single line above I will do it and
> then
> run the digest command and try to
correct, there was only one actual change in it.
See also this:
https://stackoverflow.com/questions/987372/what-is-the-format-of-a-patch-file
Fabian
>
> emerge libinput again.
>
> Regards
>
> MF
>
> On Thu, 27 Jun 2019 at 12:46, Fabian Groffen <[1]grob...@gentoo.org> wrote:
>
> > Haha, I gave you a patch, sorry.
>
> > The patch just describes which change you need to make. If you really
> > want to have an easy life, then restore the original ebuild (rsync if
> > you will) and run this:
>
> > % patch libinput-1.13.2.ebuild < path/to/the-patch-content.patch
>
> > Then you can run ebuild .. digest.
>
> > There is a chance the patch won't apply, because I didn't attach it.
> > In this case I think it's quicker if you "read" the patch yourself, find
> > the location what the patch is about, and make the change (as indicated
> > by the lines prefixed with - (removed) and + (added)).
>
> > Does this help you?
>
> > Fabian
>
>
>
> References:
>1. mailto:grob...@gentoo.org
>
> read_char: errno==EILSEQ; invalid byte sequence for UTF-8:
--
Fabian Groffen
Gentoo on a different level
signature.asc
Description: PGP signature
Re: [gentoo-alt] Re: simple question about installing chromium browser for use in debian OS using gentoo prefix..
Haha, I gave you a patch, sorry.
The patch just describes which change you need to make. If you really
want to have an easy life, then restore the original ebuild (rsync if
you will) and run this:
% patch libinput-1.13.2.ebuild < path/to/the-patch-content.patch
Then you can run ebuild .. digest.
There is a chance the patch won't apply, because I didn't attach it.
In this case I think it's quicker if you "read" the patch yourself, find
the location what the patch is about, and make the change (as indicated
by the lines prefixed with - (removed) and + (added)).
Does this help you?
Fabian
On 27-06-2019 12:41:34 +0100, Michael Fothergill wrote:
> Many thanks again.
>
> OK I went into the ebuild directory for libinput.
>
> I then edited the ebuild file and added the code you gave at the end of the
> file:
>
> src_install() {
> meson_src_install
> if use doc ; then
> docinto html
> dodoc -r "${BUILD_DIR}"/Documentation/.
> fi
> }
>
> pkg_postinst() {
> udevadm hwdb --update --root="${ROOT%/}"
> }
>
> --- a/dev-libs/libinput/libinput-1.13.2.ebuild
> +++ b/dev-libs/libinput/libinput-1.13.2.ebuild
> @@ -60,7 +60,7 @@ src_configure() {
> $(meson_use doc documentation)
> $(meson_use input_devices_wacom libwacom)
> -Dtests=false # tests are restricted
> - -Dudev-dir="$(get_udevdir)"
> + -Dudev-dir="${EPREFIX}$(get_udevdir)"
> )
> meson_src_configure
> }
>
> I then ran
>
> ebuild libinput-1.13.2.ebuild digest
>
> and got an error message:
>
> mikef@fart:~/gentoo/usr/portage/dev-libs/libinput$ ebuild
> libinput-1.13.2.ebuild digest
> * ERROR: dev-libs/libinput-1.13.2::gentoo failed (depend phase):
> * External commands disallowed while sourcing ebuild: ---
> a/dev-libs/libinput/libinput-1.13.2.ebuild
> *
> * Call stack:
> * ebuild.sh, line 623: Called source
> '/home/mikef/gentoo/usr/portage/dev-libs/libinput/libinput-1.13.2.ebuild'
> * libinput-1.13.2.ebuild, line 80: Called command_not_found_handle '---'
> 'a/dev-libs/libinput/libinput-1.13.2.ebuild'
> * ebuild.sh, line 88: Called die
> * The specific snippet of code:
> * die "External commands disallowed while sourcing ebuild: ${*}"
> *
> * If you need support, post the output of `emerge --info
> '=dev-libs/libinput-1.13.2::gentoo'`,
> * the complete build log and the output of `emerge -pqv
> '=dev-libs/libinput-1.13.2::gentoo'`.
> * The ebuild environment file is located at
> '/home/mikef/gentoo/var/tmp/portage/dev-libs/libinput-1.13.2/temp/environment'.
> * Working directory:
> '/home/mikef/gentoo/var/tmp/portage/dev-libs/libinput-1.13.2/homedir'
> * S:
> '/home/mikef/gentoo/var/tmp/portage/dev-libs/libinput-1.13.2/work/libinput-1.13.2'
> mikef@fart:~/gentoo/usr/portage/dev-libs/libinput$
>
> Was I meant to add it to the existing code as I just did?
>
> Comments appreciated.
>
> Regards
>
> MF
>
>
> read_char: errno==EILSEQ; invalid byte sequence for UTF-8:
--
Fabian Groffen
Gentoo on a different level
signature.asc
Description: PGP signature
Re: [gentoo-alt] Re: simple question about installing chromium browser for use in debian OS using gentoo prefix..
On 27-06-2019 12:09:19 +0100, Michael Fothergill wrote:
> PS I forgot to add in step 3 that I will create a file to put the helpful
> patch
> code in using emacs.
>
> I will also replace the $EPREFIX symbol with /home/mikef/gentoo in each
> instance
> in the patch code.
You don't have to do that, in the ebuild ${EPREFIX} expands to the
correct thing.
> > I am using this one:
>
> > [2]https://wiki.gentoo.org/wiki//etc/portage/patches
this is for creating /code/ patches, not for patches against the ebuilds
themselves
You need patches to ebuilds, which, if I know what patches you tried and
worked for you, me and the team can commit to the tree so it sticks.
This also means below instructions aren't going to fly.
1. Change the libinput-1.13.2.ebuild file
2. run ebuild libinput-1.13.2.ebuild digest
3. emerge --resume or emerge (whichever is resuming what you
were doing)
4. if it works, report the diff here, or preferably in a bug so we can
see to getting it applied
Thanks,
Fabian
> > I am going to do the following things:
>
> > 1. I am going to create a directory to put the patch in:
> > 2. mkdir -p /etc/portage/patches/dev-libs/libinput-1.13.2
> > 3. /etc/portage/patches/dev-libs/libinput-1.13.2/prefix-libinput.patch
> > 4. I will then enter the ebuild directory for libinput-1.13.2 and run the
> > following command:
> > 5. ebuild libinput-1.13.2.ebuild clean prepare
> > 6. I will then run ebuild libinput-1.13.2.ebuild digest as you recommended.
> > 7. Finally I will run emerge dev-libs/libinput again and see if it compiles
> > and installs.
>
> > I am going to do this now.
>
> > If you think I should change anything in the above list please let me know
> > in
> > a post.
>
> > Regards
>
> > MF
>
>
>
> References:
>1. mailto:michael.fotherg...@gmail.com
>2. https://wiki.gentoo.org/wiki//etc/portage/patches
>
> read_char: errno==EILSEQ; invalid byte sequence for UTF-8:
--
Fabian Groffen
Gentoo on a different level
signature.asc
Description: PGP signature
Re: [gentoo-alt] Re: simple question about installing chromium browser for use in debian OS using gentoo prefix..
Scratch that. Try this please:
--- a/dev-libs/libinput/libinput-1.13.2.ebuild
+++ b/dev-libs/libinput/libinput-1.13.2.ebuild
@@ -60,7 +60,7 @@ src_configure() {
$(meson_use doc documentation)
$(meson_use input_devices_wacom libwacom)
-Dtests=false # tests are restricted
- -Dudev-dir="$(get_udevdir)"
+ -Dudev-dir="${EPREFIX}$(get_udevdir)"
)
meson_src_configure
}
run ebuild libinput-1.13.2.ebuild digest again before merging
On 26-06-2019 20:40:57 +0200, Fabian Groffen wrote:
> On 26-06-2019 15:43:11 +0100, Michael Fothergill wrote:
> > PS
> >
> > The build log file has this piece in it just before the crash occurs:
> >
> > 33;01m* [0m QA Notice: the following files are outside of the prefix:
> > [33;01m* [0m /lib
> > [33;01m* [0m /lib/udev
> > [33;01m* [0m /lib/udev/libinput-model-quirks
> > [33;01m* [0m /lib/udev/libinput-device-group
> > [33;01m* [0m /lib/udev/rules.d
> > [33;01m* [0m /lib/udev/rules.d/80-libinput-device-groups.rules
> > [33;01m* [0m /lib/udev/rules.d/90-libinput-model-quirks.rules
> >
> > Is that helpful?
>
> Yes.
> Does this patch fix the problem?
>
> diff --git a/eclass/meson.eclass b/eclass/meson.eclass
> index 7c62cf44f78..13dcbf94e1a 100644
> --- a/eclass/meson.eclass
> +++ b/eclass/meson.eclass
> @@ -218,7 +218,7 @@ meson_src_configure() {
> # Common args
> local mesonargs=(
> --buildtype plain
> - --libdir "$(get_libdir)"
> + --libdir "${EPREFIX}$(get_libdir)"
> --localstatedir "${EPREFIX}/var/lib"
> --prefix "${EPREFIX}/usr"
> --sysconfdir "${EPREFIX}/etc"
>
> Fabian
> >
> > Regards
> >
> > MF
> >
> >
> > read_char: errno==EILSEQ; invalid byte sequence for UTF-8:
> --
> Fabian Groffen
> Gentoo on a different level
--
Fabian Groffen
Gentoo on a different level
signature.asc
Description: PGP signature
Re: [gentoo-alt] Re: simple question about installing chromium browser for use in debian OS using gentoo prefix..
On 26-06-2019 15:43:11 +0100, Michael Fothergill wrote:
> PS
>
> The build log file has this piece in it just before the crash occurs:
>
> 33;01m* [0m QA Notice: the following files are outside of the prefix:
> [33;01m* [0m /lib
> [33;01m* [0m /lib/udev
> [33;01m* [0m /lib/udev/libinput-model-quirks
> [33;01m* [0m /lib/udev/libinput-device-group
> [33;01m* [0m /lib/udev/rules.d
> [33;01m* [0m /lib/udev/rules.d/80-libinput-device-groups.rules
> [33;01m* [0m /lib/udev/rules.d/90-libinput-model-quirks.rules
>
> Is that helpful?
Yes.
Does this patch fix the problem?
diff --git a/eclass/meson.eclass b/eclass/meson.eclass
index 7c62cf44f78..13dcbf94e1a 100644
--- a/eclass/meson.eclass
+++ b/eclass/meson.eclass
@@ -218,7 +218,7 @@ meson_src_configure() {
# Common args
local mesonargs=(
--buildtype plain
- --libdir "$(get_libdir)"
+ --libdir "${EPREFIX}$(get_libdir)"
--localstatedir "${EPREFIX}/var/lib"
--prefix "${EPREFIX}/usr"
--sysconfdir "${EPREFIX}/etc"
Fabian
>
> Regards
>
> MF
>
>
> read_char: errno==EILSEQ; invalid byte sequence for UTF-8:
--
Fabian Groffen
Gentoo on a different level
signature.asc
Description: PGP signature
Re: [gentoo-alt] Re: simple question about installing chromium browser for use in debian OS using gentoo prefix..
On 26-06-2019 10:40:49 +0100, Michael Fothergill wrote:
> Many thanks for the suggestions and advice again.
>
> Chromium has emerged and has been installed.
>
> I added the video card and input device entries to the gentoo prefix make.conf
> file.
>
> I ran the source and env updates.
>
> Then I emerged x11-base/xorg-server.
>
> It chuntered away through 15 of the 23 packages grumbling about there being no
> kernel in /usr/src/linux which I ignored.
>
> It then failed trying to emerge the input device package dev-libs/input:
>
> * Messages for package dev-libs/libinput-1.13.2:
>
> * ERROR: dev-libs/libinput-1.13.2::gentoo failed:
> * Aborting due to QA concerns: there are files installed outside the prefix
It would help if we'd know which files are installed out of the prefix.
Since this package uses meson.ebuild, it seems this one may not be aware
of Prefix. In particular, my guess meson.eclass should use
"${EPREFIX}/$(get_libdir)" in it's mesonargs in meson_src_configure.
Fabian
> *
> * Call stack:
> * misc-functions.sh, line 586: Called install_qa_check
> * misc-functions.sh, line 132: Called source 'install_symlink_html_docs'
> * 05prefix, line 114: Called install_qa_check_prefix
> * 05prefix, line 27: Called die
> * The specific snippet of code:
> * die "Aborting due to QA concerns: there are files
> installed outside the prefix"
> *
> * If you need support, post the output of `emerge --info
> '=dev-libs/libinput-1.13.2::gentoo'`,
> * the complete build log and the output of `emerge -pqv
> '=dev-libs/libinput-1.13.2::gentoo'`.
> * The complete build log is located at
> '/home/mikef/gentoo/var/tmp/portage/dev-libs/libinput-1.13.2/temp/build.log'.
> * The ebuild environment file is located at
> '/home/mikef/gentoo/var/tmp/portage/dev-libs/libinput-1.13.2/temp/environment'.
> * Working directory:
> '/home/mikef/gentoo/var/tmp/portage/dev-libs/libinput-1.13.2/image/home/mikef/gentoo'
> * S:
> '/home/mikef/gentoo/var/tmp/portage/dev-libs/libinput-1.13.2/work/libinput-1.13.2'
>
> * GNU info directory index is up-to-date.
> mikef@fart ~/gentoo/etc/portage $ ^C
> mikef@fart ~/gentoo/etc/portage $
>
>
>
> Suggestions on a cure here would be appreciated.
>
> Regards
>
> MF
>
> On Wed, 26 Jun 2019 at 02:37, Sam Pfeiffer <[1]sammypfeif...@gmail.com> wrote:
>
> > In my experience graphics stuff can work on Prefix. At least without drivers
> > on the way... I've used the 3D graphics visualizer Rviz from my prefix.
>
> > On Wed, Jun 26, 2019, 03:53 Fabian Groffen <[2]grob...@gentoo.org wrote:
>
> >> On 25-06-2019 17:37:16 +0100, Michael Fothergill wrote:
> >> > MAny thanks again.
> >> >
> >> > node js 999 has compiled and now chromium is slowly compiling.
> >> >
> >> > I should have turned on the jumbo-build flag..
> >> >
> >> > I have a conventional gentoo install on this machine alongside
> >> debian/gentoo
> >> > prefix.
> >> >
> >> > If I would take e.g. the video card settings etc from the make.conf from
> >> the
> >> > ordinary gentoo install and put them in
> >> >
> >> > the gentoo prefix make.conf would that help me configure xorg-server to
> >> work
> >> > properly when I come to emerge it?
>
> >> You can try this, I don't know how much will work (videocards and stuff
> >> sounds like things which won't work unprivileged).
>
> >> > Suggestions on the way forward here are welcome.
>
> >> Try it, see where you hit problems.
>
> >> Fabian
> >> >
> >> > Regards
> >> >
> >> > MF
> >> >
> >> >
> >> > read_char: errno==EILSEQ; invalid byte sequence for UTF-8:
> >> --
> >> Fabian Groffen
> >> Gentoo on a different level
>
>
>
> References:
>1. mailto:sammypfeif...@gmail.com
>2. mailto:grob...@gentoo.org
>
> read_char: errno==EILSEQ; invalid byte sequence for UTF-8:
--
Fabian Groffen
Gentoo on a different level
signature.asc
Description: PGP signature
Re: [gentoo-alt] Re: simple question about installing chromium browser for use in debian OS using gentoo prefix..
On 25-06-2019 17:37:16 +0100, Michael Fothergill wrote: > MAny thanks again. > > node js 999 has compiled and now chromium is slowly compiling. > > I should have turned on the jumbo-build flag.. > > I have a conventional gentoo install on this machine alongside debian/gentoo > prefix. > > If I would take e.g. the video card settings etc from the make.conf from the > ordinary gentoo install and put them in > > the gentoo prefix make.conf would that help me configure xorg-server to work > properly when I come to emerge it? You can try this, I don't know how much will work (videocards and stuff sounds like things which won't work unprivileged). > Suggestions on the way forward here are welcome. Try it, see where you hit problems. Fabian > > Regards > > MF > > > read_char: errno==EILSEQ; invalid byte sequence for UTF-8: -- Fabian Groffen Gentoo on a different level signature.asc Description: PGP signature
Re: [gentoo-alt] Re: simple question about installing chromium browser for use in debian OS using gentoo prefix..
Hi Mike,
Run:
ebuild nghttp2-1.39.1.ebuild digest
that would fix it
Fabian
On 25-06-2019 14:05:13 +0100, Michael Fothergill wrote:
> I took edited the ebuild file for the nghttp2 package as follows:
>
> multilib_src_configure() {
> local myeconfargs=(
> --disable-examples
> --disable-failmalloc
> --disable-python-bindings
> --disable-werror
> --without-cython
> --with-boost=/home/mikef/gentoo/usr
> $(use_enable cxx asio-lib)
> $(use_enable debug)
> $(multilib_native_use_enable hpack-tools)
> $(use_enable static-libs static)
> $(use_enable threads)
> $(multilib_native_use_enable utils app)
> $(multilib_native_use_with jemalloc)
> $(multilib_native_use_with xml libxml2)
> )
> ECONF_SOURCE="${S}" econf "${myeconfargs[@]}"
>
> }
>
> I added an extra line (shown in red) to the ebuild in the myeconfargs flag
> setup
> list or whatever it is called.
>
> I then tried running emerge again but it failed as follows:
>
> mikef@fart ~/gentoo/usr/portage/net-libs/nghttp2 $ !295
> emerge net-libs/nghttp2
> Calculating dependencies \ * Digest verification failed:
> * /home/mikef/gentoo/usr/portage/net-libs/nghttp2/nghttp2-1.39.1.ebuild
> * Reason: Filesize does not match recorded size
> * Got: 2005
> * Expected: 1966
> ... done!
>
> >>> Verifying ebuild manifests
>
> !!! Digest verification failed:
> !!! /home/mikef/gentoo/usr/portage/net-libs/nghttp2/nghttp2-1.39.1.ebuild
> !!! Reason: Filesize does not match recorded size
> !!! Got: 2005
> !!! Expected: 1966
> mikef@fart ~/gentoo/usr/portage/net-libs/nghttp2 $
>
> ***
>
> It didn't like the change made to the ebuild file it seems.
>
> Comments appreciated.
>
> Regards
>
> MF
>
>
> read_char: errno==EILSEQ; invalid byte sequence for UTF-8:
--
Fabian Groffen
Gentoo on a different level
signature.asc
Description: PGP signature
[gentoo-alt] Re: simple question about installing chromium browser for use in debian OS using gentoo prefix..
Hi Michael,
First, I think emerging something like chromium pulls in a lot of heavy
dependencies, which often haven't received any Prefix attention, or were
simply not kept up-to-date. I'm not aware if anyone is using Prefix as
their desktop env, I once did so (years ago) but it's tedious at times.
Now, with that "warning" in mind, it seems that for
https://bugs.gentoo.org/647740
adding --with-boost="${EPREFIX}"/usr might have the right effect. Did
you try modifying the ebuild adding that to myeconfargs?
It's in your portage tree (probably still in $EPREFIX/usr/portage, more
recent location in $EPREFIX/var/lib/repos/gentoo) in
net-libs/nghttp2/nghttp2-1.39.1.ebuild.
Thanks,
Fabian
On 23-06-2019 11:03:44 +0100, Michael Fothergill wrote:
> PS
>
> I have gone and tried to install the chromium browser using gentoo prefix.
>
> I have run into the bug discussed here:
>
> https://bugs.gentoo.org/647740
>
> The package net-libs/nghttp2-1.39.1
> fails to compile
>
> See here
> https://forums.gentoo.org/viewtopic-p-8346068.html#8346068
>
> and the appropriate log file pastes therein.
>
> I tried adding the local use flag asio to the make.conf file:
>
> mikef@fart ~ $ !229
> more /home/mikef/gentoo/etc/portage/make.conf
> # Added by bootstrap-prefix.sh for x86_64-pc-linux-gnu
> USE="asio unicode nls icu ssl"
> CFLAGS="${CFLAGS} -O2 -pipe"
> CXXFLAGS="${CFLAGS}"
> MAKEOPTS="-j3"
> CONFIG_SHELL="/home/mikef/gentoo/bin/bash"
> # sandbox does not work well on Prefix, bug 490246
> FEATURES="${FEATURES} -usersandbox -sandbox"
>
> and ran
>
> source /home/mikef/gentoo/etc/profile
>
> to update the system to let it see the new flag.
>
> I reran emerge chromium and it failed again for the same reason as before.
>
> Suggestions on a workaround are appreciated.
>
> Regards
>
> MF
>
> PS
>
> The bug discussion by Gabor Vida says "After debugging the configure
> script, I ended up that if configure gets --with-boost=${EPREFIX},
> then it properly finds Boost::ASIO, as it can set BOOST_ROOT and
> BOOST_LDFLAGS." amongst other things.
>
> What does this refer to and if it would help where does this script live?
>
> Can I edit e.g. with emacs and add this extra line somewhere and it
> would then fix the problem?
>
> Comments appreciated.
>
> Regards
>
> MF
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> On Fri, 21 Jun 2019 at 17:09, Michael Fothergill
> wrote:
> >
> > Dear All,
> >
> > I notice from looking at a recent post on the debian user list that
> > the current versions of the chromium browser available in debian
> > stretch and buster are rather old and are missing quite a few security
> > updates.
> >
> > The user was requesting a newer version of chromium be made available
> > in debian to solve the problem.
> >
> > It occurred to me that I could use gentoo prefix to install the latest
> > version of chromium from the gentoo repositories.
> >
> > That ought to be more recent.
> >
> > If I would do that, would the installed version of chromium be seen by
> > the debian OS window manager (e.g. LXDE or GNOME or can you only run
> > the browser from inside the gentoo prefix directory after starting it
> > up and specifying path to the browser ie something like
> > /usr/bin/chromium etc?
> >
> > What exactly is the offset used by gentoo prefix?
> >
> > Is it some kind of chroot environment?
> >
> > What is the correct way to copy files in an out of it from the debian
> > OS environment?
> >
> > Regards
> >
> > Michael Fothergill
>
--
Fabian Groffen
Gentoo on a different level
signature.asc
Description: PGP signature
Re: [gentoo-alt] problem installing gentoo prefix on debian buster
FWIW: I fixed this problem in https://gitweb.gentoo.org/repo/proj/prefix.git/commit/?id=65bb9581 Thanks, Fabian On 04-06-2019 10:47:15 +0100, Michael Fothergill wrote: > Dear All, > > I tried to install gentoo prefix an amd64 box running debian buster. > > I am using gcc 8. > > It failed as follows: > > > wctype.h-t && \ > mv wctype.h-t wctype.h > make all-am > make[3]: Entering directory > '/home/mikef/gentoo/var/tmp/m4-1.4.15/m4-1.4.15/lib' > gcc -I. -g -O2 -MT gl_avltree_oset.o -MD -MP -MF > .deps/gl_avltree_oset.Tpo -c -o gl_avltree_oset.o gl_avltree_oset.c > gcc -I. -g -O2 -MT c-ctype.o -MD -MP -MF .deps/c-ctype.Tpo -c -o > c-ctype.o c-ctype.c > gcc -I. -g -O2 -MT c-stack.o -MD -MP -MF .deps/c-stack.Tpo -c -o > c-stack.o c-stack.c > mv -f .deps/c-ctype.Tpo .deps/c-ctype.Po > mv -f .deps/c-stack.Tpo .deps/c-stack.Po > gcc -I. -g -O2 -MT clean-temp.o -MD -MP -MF .deps/clean-temp.Tpo > -c -o clean-temp.o clean-temp.c > gcc -I. -g -O2 -MT execute.o -MD -MP -MF .deps/execute.Tpo -c -o > execute.o execute.c > In file included from clean-temp.h:22, > from clean-temp.c:23: > ./stdio.h:456:1: error: 'gets' undeclared here (not in a function); > did you mean 'fgets'? > _GL_WARN_ON_USE (gets, "gets is a security hole - use fgets instead"); > ^~~ > make[3]: *** [Makefile:1279: clean-temp.o] Error 1 > make[3]: *** Waiting for unfinished jobs > mv -f .deps/execute.Tpo .deps/execute.Po > mv -f .deps/gl_avltree_oset.Tpo .deps/gl_avltree_oset.Po > make[3]: Leaving directory > '/home/mikef/gentoo/var/tmp/m4-1.4.15/m4-1.4.15/lib' > make[2]: *** [Makefile:1083: all] Error 2 > make[2]: Leaving directory > '/home/mikef/gentoo/var/tmp/m4-1.4.15/m4-1.4.15/lib' > make[1]: *** [Makefile:1023: all-recursive] Error 1 > make[1]: Leaving directory '/home/mikef/gentoo/var/tmp/m4-1.4.15/m4-1.4.15' > make: *** [Makefile:976: all] Error 2 > > I tried running > bootstrap_stage1_log > but that failed :( I have no clue, really. Please find friendly folks > in #gentoo-prefix on irc.gentoo.org, gentoo-alt@lists.gentoo.org mailing list, > or file a bug at bugs.gentoo.org under Gentoo/Alt, Prefix Support. > Sorry that I have failed you master. I shall now return to my humble cave. > You can find a log of what happened in /home/mikef/gentoo/stage1.log > mikef@fart:~$ > > I filed a bug report on gentoo bugzilla Bug 687286 and posted the problem > here: > > https://forums.gentoo.org/viewtopic-t-1097582.html > > Comments appreciated > > Regards > > Michael Fothergill > -- Fabian Groffen Gentoo on a different level signature.asc Description: PGP signature
Re: [gentoo-alt] problem installing gentoo prefix on debian buster
On 05-06-2019 18:16:31 +0100, Michael Fothergill wrote: > Dear Folks, > > Is this warning a big concern? yes, you effectively disable your Prefix with this path > WARNING: your shell initialisation (.cshrc, .bashrc, .profile) > * seems to prepend to your PATH, this might kill your > * Prefix: > * /usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin: > * You better fix this, YOU HAVE BEEN WARNED! > > I ran the etc-update on the hosts file. > > The system is up to date. No packages needed to be removed by emerge > --depclean. > > startprefix runs OK. > > Can I compile a new kernel for the parent debian install in gentoo > prefix and use debian to do the make deb-pkg or make bindeb-pkg or > fakeroot commands if they don't work in gentoo prefix? I think this is pretty much challenging. IIRC you mentioned something before, but out of curiosity why would you want a Gentoo kernel for your Debian system? Fabian -- Fabian Groffen Gentoo on a different level signature.asc Description: PGP signature
Re: [gentoo-alt] problem installing gentoo prefix on debian buster
On 04-06-2019 17:19:21 +0100, Michael Fothergill wrote: > Dear All, > > The installation is getting near completion. Unfortunately portage > seems to be compiling gcc 9.1.0-r1 a second time for good > measure.. This is expected behaviour. After all packages are brought in, it finishes with an emerge -e world to ensure everything is "clean", that is, not pointing to, or using programs or libraries from outside the prefix. Fabian > > Regards MF > > On Tue, 4 Jun 2019 at 11:38, Fabian Groffen wrote: > > > > Michael, > > > > Just to elaborate a bit. There is a newer version of m4, that is > > attempted first. However, newer versions of GNU software now require > > the xz decompressor to unpack. In your scenario, an old version of m4 > > is being compiled. One of the reasons for choosing an older version is > > because of not being able to unpack the newer versions due to lack of > > xz. Odd though, as the latest m4 (1.4.18) is also available as .gz and > > bz2. > > > > We'd need a larger part of the stage1 log to see why the newer versions > > didn't work. > > > > Fabian > > > > > > On 04-06-2019 11:10:47 +0100, Michael Fothergill wrote: > > > On Tue, 4 Jun 2019 at 11:01, Fabian Groffen wrote: > > > > > > > > Hi, > > > > > > > > Can you confirm you don't have xz tool available on your system? > > > > > > Many thanks for the response. I am not sure if xz utils is installed > > > by default in debian: > > > > > > https://packages.debian.org/sid/xz-utils > > > > > > I will log in to the debian install and check. > > > > > > Regards and thanks > > > > > > MF > > > > > > > > > > > Thanks, > > > > Fabian > > > > -- > > > > Fabian Groffen > > > > Gentoo on a different level > > > > > > > -- > > Fabian Groffen > > Gentoo on a different level > -- Fabian Groffen Gentoo on a different level signature.asc Description: PGP signature
Re: [gentoo-alt] problem installing gentoo prefix on debian buster
I agree, install m4 in your Debian box, and it should skip it: [[ $(m4 --version 2>&1) == *GNU*1.4.1?* ]] || (bootstrap_m4) || return 1 Fabian On 04-06-2019 13:46:39 +0200, Olivier Huber wrote: > Hi Michael, > > What does ``m4 --version'' return on your debian install? > > I'm no dev, however, if you have a valid m4 install, you shouldn't need to > have > m4 bootstrapped. > > If m4 is not installed, you may want to do so (as well as bison, patch, ...). > > Otherwise, you could apply some patch to m4 during the bootstrap process. > > For instance, this bug has been fixed in Gentoo with this patch > > [1]https://gitweb.gentoo.org/repo/gentoo.git/plain/sys-devel/m4/files/m4-1.4.18-glibc228.patch > > Best, > > -- > > Olivier Huber > > On Tue, Jun 4, 2019 at 1:35 PM Michael Fothergill > <[2]michael.fotherg...@gmail.com> wrote: > > > I have a separate gentoo installation on this machine. > > > Could I compile m4 on it and port it to the debian install and run it > > there in some way? > > > Regards > > > MF > > > > References: >1. > https://gitweb.gentoo.org/repo/gentoo.git/plain/sys-devel/m4/files/m4-1.4.18-glibc228.patch >2. mailto:michael.fotherg...@gmail.com > > read_char: errno==EILSEQ; invalid byte sequence for UTF-8: -- Fabian Groffen Gentoo on a different level signature.asc Description: PGP signature
Re: [gentoo-alt] problem installing gentoo prefix on debian buster
On 04-06-2019 12:01:42 +0100, Michael Fothergill wrote: > Many thanks again. > > I have posted the output at start of the install run which mentions > this m4 item: > > https://paste.debian.net/1085998/ freadahead.c: In function 'freadahead': freadahead.c:92:3: error: #error "Please port gnulib freadahead.c to your platform! Look at the definition of fflush, fread, ungetc on your system, then report this to bug-gnulib." #error "Please port gnulib freadahead.c to your platform! Look at the definition of fflush, fread, ungetc on your system, then report this to bug-gnulib." ^ ahem I wonder what Debian $*$***$ up this time... -- Fabian Groffen Gentoo on a different level signature.asc Description: PGP signature
Re: [gentoo-alt] problem installing gentoo prefix on debian buster
Michael, Just to elaborate a bit. There is a newer version of m4, that is attempted first. However, newer versions of GNU software now require the xz decompressor to unpack. In your scenario, an old version of m4 is being compiled. One of the reasons for choosing an older version is because of not being able to unpack the newer versions due to lack of xz. Odd though, as the latest m4 (1.4.18) is also available as .gz and bz2. We'd need a larger part of the stage1 log to see why the newer versions didn't work. Fabian On 04-06-2019 11:10:47 +0100, Michael Fothergill wrote: > On Tue, 4 Jun 2019 at 11:01, Fabian Groffen wrote: > > > > Hi, > > > > Can you confirm you don't have xz tool available on your system? > > Many thanks for the response. I am not sure if xz utils is installed > by default in debian: > > https://packages.debian.org/sid/xz-utils > > I will log in to the debian install and check. > > Regards and thanks > > MF > > > > > Thanks, > > Fabian > > -- > > Fabian Groffen > > Gentoo on a different level > -- Fabian Groffen Gentoo on a different level signature.asc Description: PGP signature
Re: [gentoo-alt] problem installing gentoo prefix on debian buster
Hi, Can you confirm you don't have xz tool available on your system? Thanks, Fabian On 04-06-2019 10:47:15 +0100, Michael Fothergill wrote: > Dear All, > > I tried to install gentoo prefix an amd64 box running debian buster. > > I am using gcc 8. > > It failed as follows: > > > wctype.h-t && \ > mv wctype.h-t wctype.h > make all-am > make[3]: Entering directory > '/home/mikef/gentoo/var/tmp/m4-1.4.15/m4-1.4.15/lib' > gcc -I. -g -O2 -MT gl_avltree_oset.o -MD -MP -MF > .deps/gl_avltree_oset.Tpo -c -o gl_avltree_oset.o gl_avltree_oset.c > gcc -I. -g -O2 -MT c-ctype.o -MD -MP -MF .deps/c-ctype.Tpo -c -o > c-ctype.o c-ctype.c > gcc -I. -g -O2 -MT c-stack.o -MD -MP -MF .deps/c-stack.Tpo -c -o > c-stack.o c-stack.c > mv -f .deps/c-ctype.Tpo .deps/c-ctype.Po > mv -f .deps/c-stack.Tpo .deps/c-stack.Po > gcc -I. -g -O2 -MT clean-temp.o -MD -MP -MF .deps/clean-temp.Tpo > -c -o clean-temp.o clean-temp.c > gcc -I. -g -O2 -MT execute.o -MD -MP -MF .deps/execute.Tpo -c -o > execute.o execute.c > In file included from clean-temp.h:22, > from clean-temp.c:23: > ./stdio.h:456:1: error: 'gets' undeclared here (not in a function); > did you mean 'fgets'? > _GL_WARN_ON_USE (gets, "gets is a security hole - use fgets instead"); > ^~~ > make[3]: *** [Makefile:1279: clean-temp.o] Error 1 > make[3]: *** Waiting for unfinished jobs > mv -f .deps/execute.Tpo .deps/execute.Po > mv -f .deps/gl_avltree_oset.Tpo .deps/gl_avltree_oset.Po > make[3]: Leaving directory > '/home/mikef/gentoo/var/tmp/m4-1.4.15/m4-1.4.15/lib' > make[2]: *** [Makefile:1083: all] Error 2 > make[2]: Leaving directory > '/home/mikef/gentoo/var/tmp/m4-1.4.15/m4-1.4.15/lib' > make[1]: *** [Makefile:1023: all-recursive] Error 1 > make[1]: Leaving directory '/home/mikef/gentoo/var/tmp/m4-1.4.15/m4-1.4.15' > make: *** [Makefile:976: all] Error 2 > > I tried running > bootstrap_stage1_log > but that failed :( I have no clue, really. Please find friendly folks > in #gentoo-prefix on irc.gentoo.org, gentoo-alt@lists.gentoo.org mailing list, > or file a bug at bugs.gentoo.org under Gentoo/Alt, Prefix Support. > Sorry that I have failed you master. I shall now return to my humble cave. > You can find a log of what happened in /home/mikef/gentoo/stage1.log > mikef@fart:~$ > > I filed a bug report on gentoo bugzilla Bug 687286 and posted the problem > here: > > https://forums.gentoo.org/viewtopic-t-1097582.html > > Comments appreciated > > Regards > > Michael Fothergill > -- Fabian Groffen Gentoo on a different level signature.asc Description: PGP signature
[gentoo-alt] [PREFIX] Python-2 now disabled by default
Python-2 is now disabled by default via https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=e9de14ba Since this changes the default for *all* users: - if you want to keep python2_7, in your etc/portage/make.conf: PYTHON_TARGETS="python2_7 python3_6" - if you're ok without python2_7, rebuild things to avoid dependency problems: emerge -Duva --newuse world Above after you synced to a tree that contains the change (in an hour from now or so). Thanks, Fabian On 31-05-2019 07:55:44 +0200, Guilherme Amadio wrote: > Hi all, > > On Fri, May 31, 2019 at 10:28:47AM +0800, Benda Xu wrote: > > Dear Fabian, > > > > Fabian Groffen writes: > > > > > Now we're using python-3 to bootstrap in stage1 (this has still some > > > issues on some platforms, but I'm assuming we can fix those), I've been > > > wondering myself whether we should disable python-2 by default in > > > Prefix. It would reduce some compilation time and files/disk footprint. > > > > > > Opinions, thoughts, ideas on disabling python-2 by default? > > > > > > (Obviously, people can enable and install python-2 after bootstrap, > > > there's no plans to remove the ebuild from the tree at this time.) > > > > I agree with you. We only need bootstrap to produce a minimal system > > for people to start with. If anything could be gotten rid of to make > > bootstrap simpler, it should happen. > > +1 > > -Guilherme > -- Fabian Groffen Gentoo on a different level signature.asc Description: PGP signature
[gentoo-alt] [PREFIX] disabling Python-2 by default?
Hi, Now we're using python-3 to bootstrap in stage1 (this has still some issues on some platforms, but I'm assuming we can fix those), I've been wondering myself whether we should disable python-2 by default in Prefix. It would reduce some compilation time and files/disk footprint. Opinions, thoughts, ideas on disabling python-2 by default? (Obviously, people can enable and install python-2 after bootstrap, there's no plans to remove the ebuild from the tree at this time.) Thanks, Fabian -- Fabian Groffen Gentoo on a different level signature.asc Description: PGP signature
[gentoo-alt] [PREFIX] no more interrevisions in the prefix tree please
Hi, $SUBJECT I've updated the portage used on rsync1 and rsync2 from 2.2.28 to 2.3.62 yesterday because I started to see errors about EAPI=7 being unknown. Once I put the newer portage in place I got a lot of errors about the use of versionator.eclass. This was fixed in f5b4e670e0d7a5686f67b5bcfe4c323d6f4fe050 by syncing all the eclasses, some of which depended on versionator. Next were errors about invalid versions due to our usage of interrevisions. I've removed them all in 82c2c71837628069aeb9484d295d304b3387d91c, d8c9f4611146c1e16b1aa795b8e599c56386a1a9 and 7d3f27a474ff2fc086c95440e29d0319b64f80b0. After this I expect the tree generation to be silent again. I've bumped the latest portage in tree to 2.3.67 in the process, as well as binutils-config to avoid downgrades due to removal of interrevision-versions. Please keep the tree clean from interrevisions (use a .1 extra version or something). Adding them makes egencache unhappy (thus generate no cache for those). Thanks, Fabian -- Fabian Groffen Gentoo on a different level signature.asc Description: PGP signature
Re: [gentoo-alt] RFC: abstract for Conference on Computing in High Energy & Nuclear Physics
Hi Benda, Thanks a lot for all the hard work on this! I hope your abstract gets through, and of course your paper will get accepted. Needless to say I'd like to help you where possible. I think you got it all covered, but feel free to reach out when necessary. Fabian On 12-05-2019 23:42:12 +0800, Benda Xu wrote: > Dear all, > > I am going to to submit an abstract on the use case of Gentoo Prefix to > Conference on Computing in High Energy & Nuclear Physics, to be held in > Australia. Please find the draft below. Comments before May 19 will be > reflected in the submitted version. > > By default I am going to list the Prefix team as authors. Please reply > me if you want to add or remove yourself from the author list. > > Thanks! > Benda > > Gentoo Prefix as a physics software manager > > In big physics experiments, as simulation, reconstruction and > analysis become more sophisticated, scientific reproducibility is > not a trivial task. Software is one of the biggest > challenges. Modularity is a common sense of software engineering to > facilitate quality and reusability of code. However, that often > introduces nested dependencies not obvious for physicists to work > with. Package manager is the widely practised solution to organize > dependencies systematically. > > Portage from Gentoo Linux is both robust and flexible, and is highly > regarded by the free operating system community. In the form of > Gentoo Prefix, portage can be deployed by a normal user into a > directory prefix, on a workstation, cloud or supercomputing node. > Software is described by its build recipes along with dependency > relations. Real world use cases of Gentoo Prefix in neutrino and > dark matter experiments will be demonstrated, to show how physicists > could benefit from existing tools of proven superiority to guarantee > reproducibility in simulation, reconstruction and analysis of big > physics experiments. > -- Fabian Groffen Gentoo on a different level signature.asc Description: PGP signature
[gentoo-alt] Re: Gentoo Prefix Lead election
Sorry for being a bit late. From the replies to this message, the only person who accepted the nomination (I frankly forgot to accept myself) is heroxbd. Recorded votes for the archives: amadio 3rd grobian 1st 1st 1st 1st 1st 1st haubi 1st 2nd 3rd heroxbd 2nd 1st 2nd 2nd 2nd Thus, the new lead for Gentoo Prefix will be the only eligable one: heroxbd. Congrats Benda! Can you update the wiki and the outstanding bug yourself? Fabian On 24-04-2019 11:33:07 +0200, Fabian Groffen wrote: > Ok, with these nominations in place, I'd like add: > > haubi > > and conclude the nominations period. > > Please cast your votes before May 1st 2019 by replying to this > email/list. > > Voting ends 2019-04-30 23:59:59 CEST. > > Thanks, > Fabian > > On 24-04-2019 11:28:06 +0200, Michael Haubenwallner wrote: > > > > On 4/16/19 8:59 PM, Fabian Groffen wrote: > > > Hi, > > > > > > As per https://bugs.gentoo.org/683610, we need to run the selection > > > process. > > > > > > Please nominate (possibly yourself) in reply to this email. > > > > So I nominate: > > amadio > > grobian > > heroxbd > > > > Thanks, > > /haubi/ > > > > > > > -- > Fabian Groffen > Gentoo on a different level -- Fabian Groffen Gentoo on a different level signature.asc Description: PGP signature
[gentoo-alt] Re: Gentoo Prefix Lead election
I vote for (in order): haubi heroxbd Thanks, Fabian On 24-04-2019 11:33:07 +0200, Fabian Groffen wrote: > Ok, with these nominations in place, I'd like add: > > haubi > > and conclude the nominations period. > > Please cast your votes before May 1st 2019 by replying to this > email/list. > > Voting ends 2019-04-30 23:59:59 CEST. > > Thanks, > Fabian > > On 24-04-2019 11:28:06 +0200, Michael Haubenwallner wrote: > > > > On 4/16/19 8:59 PM, Fabian Groffen wrote: > > > Hi, > > > > > > As per https://bugs.gentoo.org/683610, we need to run the selection > > > process. > > > > > > Please nominate (possibly yourself) in reply to this email. > > > > So I nominate: > > amadio > > grobian > > heroxbd > > > > Thanks, > > /haubi/ > > > > > > > -- > Fabian Groffen > Gentoo on a different level -- Fabian Groffen Gentoo on a different level signature.asc Description: PGP signature
[gentoo-alt] Re: Gentoo Prefix Lead election
Ok, with these nominations in place, I'd like add: haubi and conclude the nominations period. Please cast your votes before May 1st 2019 by replying to this email/list. Voting ends 2019-04-30 23:59:59 CEST. Thanks, Fabian On 24-04-2019 11:28:06 +0200, Michael Haubenwallner wrote: > > On 4/16/19 8:59 PM, Fabian Groffen wrote: > > Hi, > > > > As per https://bugs.gentoo.org/683610, we need to run the selection > > process. > > > > Please nominate (possibly yourself) in reply to this email. > > So I nominate: > amadio > grobian > heroxbd > > Thanks, > /haubi/ > -- Fabian Groffen Gentoo on a different level signature.asc Description: PGP signature
[gentoo-alt] Gentoo Prefix Lead election
This should've gone to the list, forwarding... - Forwarded message from Fabian Groffen - From: Fabian Groffen To: prefix Subject: Gentoo Prefix Lead election Date: Tue, 16 Apr 2019 20:59:02 +0200 Hi, As per https://bugs.gentoo.org/683610, we need to run the selection process. Please nominate (possibly yourself) in reply to this email. Thanks, Fabian -- Fabian Groffen Gentoo on a different level - End forwarded message - -- Fabian Groffen Gentoo on a different level signature.asc Description: PGP signature
Re: [gentoo-alt] Re: [PREFIX] Bootstrap stable?
Hi Francois, On 04-04-2019 07:23:50 +, Francois Bissey wrote: > > On 4/04/2019, at 19:49, Fabian Groffen wrote: [snip] > > On 04-04-2019 01:51:58 +, Francois Bissey wrote: [snip] > >> Basically if you want to reproduce some the scenarios managed by spack you > >> need multiple prefix. > > > > So what scenarios exactly are these? > > It can be several versions of the same software as stated earlier. Either > executable > or libraries. > For example while gromacs 5.x was stable a user wanted me to resurrect a copy > of gromacs > 3 something because it was the last version with a particular potential in > the feature > set and that’s what they wanted to use. > You can have the same software compiled with different compilers. Which can > be various > version of gcc/intel compilers or other proprietary compiler (PGI comes to > mind as well > as cray which has its own toolchain). Because of potential incompatibilities > in the > Fortran binary interface you will have a tree by fortran compiler vendor and > sometimes > different version of the same compiler (gcc 4 to 6, gcc 7 and gcc 8 all have > a different > runtime want to troll bugzilla to see how many problems that created to > users?). > People will want a particular compiler because the software they use compiled > with > another compiler won’t pass the test suite or crash in their particular > extreme > scenario. And another group using the same software will want a different > compiler for the > same reason. I see. The tendency of Gentoo (or: some developers) has been to reduce slots and concurrent versions. GCC once had USE=multislot for instance, Perl used to be slotted. but I see how there is a wide range of packages that never were slotted in Gentoo, and/or never will be. I know there are projects that install "pillars" or something that truely allow multiple concurrent versions to be installed, because they use completely different target trees. Prefix wasn't designed to be like that, this would require a different approach from Portage itself. I could see something like stacked prefixes to suit some of the above use-cases, combined with binpkg support to quickly launch various different incarnations of combinations of tools. Nevertheless, there will be problems. And Prefix is never going to solve them all :) Thanks for your explanation, I'm sure there must be some "pain" in even having to describe the situation ... Fabian [snip] -- Fabian Groffen Gentoo on a different level signature.asc Description: PGP signature
[gentoo-alt] Re: [PREFIX] bumped baselayout-prefix, "Stacked Prefix" with prefix-toolkit
Confirmed with x86_64-apple-darwin17/20190327, i386-pc-solaris2.11/20190326, x86_64-pc-solaris2.11/20190326 bumped snapshot to 20190326. Thanks, Fabian On 26-03-2019 10:08:11 +0100, Fabian Groffen wrote: > On 26-03-2019 09:57:24 +0100, Michael Haubenwallner wrote: > > On 3/25/19 7:10 PM, Fabian Groffen wrote: > > > On 25-03-2019 18:22:20 +0100, Michael Haubenwallner wrote: > > >>>> Instead of just creating /startprefix, at some time we may want to > > >>>> have bootstrap-prefix.sh emerge prefix-toolkit eventually. > > >>> > > >>> I'd prefer "now" over "eventually". If necessary, we can add it to > > >>> @world > > >>> on prefix, or just have it be emerged like the shell before it creates > > >>> startprefix. > > >> > > >> Ok then. Still need manual creation as fallback, as prefix-toolkit is not > > >> part of current tree tarball yet. > > >> https://gitweb.gentoo.org/repo/proj/prefix.git/commit/?id=032ef433319e81ca59fd4e064059fab3dc11bada > > > > > > Thanks, it will in a snapshot tomorrow. I'll bump it in the morning > > > (modulo I forget). > > > > Maybe we should get at least some build jobs green before: > > https://dev.azure.com/gentoo-prefix/ci-builds/_build/results?buildId=224 > > I'm running solaris and darwin builds now with the snapshot in place. I > see you're running with a bleeding-edge tree, so we should be testing > close to the same thing. I'm planning to wait for the solaris build > (8-ish hours?) and commit at the end of my day. > Your macOS build failed because clang/llvm-8 is broken. I'll have to > mask it for now. > > Fabian > > -- > Fabian Groffen > Gentoo on a different level -- Fabian Groffen Gentoo on a different level signature.asc Description: PGP signature
[gentoo-alt] Re: [PREFIX] bumped baselayout-prefix, "Stacked Prefix" with prefix-toolkit
On 26-03-2019 09:57:24 +0100, Michael Haubenwallner wrote: > On 3/25/19 7:10 PM, Fabian Groffen wrote: > > On 25-03-2019 18:22:20 +0100, Michael Haubenwallner wrote: > >>>> Instead of just creating /startprefix, at some time we may want to > >>>> have bootstrap-prefix.sh emerge prefix-toolkit eventually. > >>> > >>> I'd prefer "now" over "eventually". If necessary, we can add it to @world > >>> on prefix, or just have it be emerged like the shell before it creates > >>> startprefix. > >> > >> Ok then. Still need manual creation as fallback, as prefix-toolkit is not > >> part of current tree tarball yet. > >> https://gitweb.gentoo.org/repo/proj/prefix.git/commit/?id=032ef433319e81ca59fd4e064059fab3dc11bada > > > > Thanks, it will in a snapshot tomorrow. I'll bump it in the morning > > (modulo I forget). > > Maybe we should get at least some build jobs green before: > https://dev.azure.com/gentoo-prefix/ci-builds/_build/results?buildId=224 I'm running solaris and darwin builds now with the snapshot in place. I see you're running with a bleeding-edge tree, so we should be testing close to the same thing. I'm planning to wait for the solaris build (8-ish hours?) and commit at the end of my day. Your macOS build failed because clang/llvm-8 is broken. I'll have to mask it for now. Fabian -- Fabian Groffen Gentoo on a different level signature.asc Description: PGP signature
[gentoo-alt] Re: [PREFIX] bumped baselayout-prefix, "Stacked Prefix" with prefix-toolkit
On 25-03-2019 18:22:20 +0100, Michael Haubenwallner wrote: > >> Instead of just creating /startprefix, at some time we may want to > >> have bootstrap-prefix.sh emerge prefix-toolkit eventually. > > > > I'd prefer "now" over "eventually". If necessary, we can add it to @world > > on prefix, or just have it be emerged like the shell before it creates > > startprefix. > > Ok then. Still need manual creation as fallback, as prefix-toolkit is not > part of current tree tarball yet. > https://gitweb.gentoo.org/repo/proj/prefix.git/commit/?id=032ef433319e81ca59fd4e064059fab3dc11bada Thanks, it will in a snapshot tomorrow. I'll bump it in the morning (modulo I forget). Fabian -- Fabian Groffen Gentoo on a different level signature.asc Description: PGP signature
Re: [gentoo-alt] [PREFIX] bumped baselayout-prefix, "Stacked Prefix" with prefix-toolkit
On 25-03-2019 16:52:56 +0100, Michael Haubenwallner wrote: > Another heads up: > > I've rebased baselayout-prefix onto baselayout-2.6, with the prefix > patches designed for submission into baselayout, to get rid of > distinct baselayout-prefix at some point, let's see how that works. > > Also, there is the new app-portage/prefix-toolkit package, providing: > * /startprefix now (overrides the one created during bootstrap), > to get that one updateable, as well as > * prefix-stack-setup script as entry point to the "Stacked Prefix" > world (although without any further documentation yet). > > Instead of just creating /startprefix, at some time we may want to > have bootstrap-prefix.sh emerge prefix-toolkit eventually. I'd prefer "now" over "eventually". If necessary, we can add it to @world on prefix, or just have it be emerged like the shell before it creates startprefix. Thanks! Fabian -- Fabian Groffen Gentoo on a different level signature.asc Description: PGP signature
[gentoo-alt] [PREFIX] bumped versions of Python
Heads up: I've bumped the Python versions in the tree (due to security fixes), and also added Python 3.7.2. I hope this doesn't break anything, will know more once bootstraps complete. Thanks, Fabian -- Fabian Groffen Gentoo on a different level signature.asc Description: PGP signature
Re: [gentoo-alt] Re: 'Continuous Integration' for Gentoo Prefix?
On 13-02-2019 17:54:46 +, Michael Everitt wrote: > I did raise the idea of setting up the "prefix-ci"/"prefix-testing" mailing > list to get results send to interested parties by email with Michael at > FOSDEM - how would you feel about this, Fabian - I'm sure there are users > who might find access to the archives or even live updates useful - the > #g-prefix IRC channel is moderately active for those of us on it! There are > already lists for eg. repo-mirror-CI, we have set up a local list for > Kernel project CI and there is also releng-autobuilds .. so there is a > precident, if someone can petition Infra to set it up! > Best regards, Yeah, I think we should just do it. I'm just not that far with automating all of this, but I would like to encourage anyone to do things in this area. I've filed https://bugs.gentoo.org/677968, we can take it from there once the list is implemented. Thanks, Fabian -- Fabian Groffen Gentoo on a different level signature.asc Description: PGP signature
[gentoo-alt] Re: 'Continuous Integration' for Gentoo Prefix?
On 13-02-2019 12:32:08 +0100, Michael Haubenwallner wrote: > > So, with this in mind, I've started experimenting, here's my "progress": > > > > http://bootstrap.prefix.bitzolder.nl/results/ > > Nice! 1990-ish nice HTML, but yeah :) > > The idea is to rsync the result after the bootstrap-prefix.sh call to the > > server. I can have setup to be in an "upload" sense. The current call > > (which assumes direct access) can be found in the dobootstrap script I > > currently use to fire off a bootstrap on a platform: > > > > http://bootstrap.prefix.bitzolder.nl/dobootstrap (see DOPUBLISH) > > So I'm wondering how to enable myself to provide logs for some more CHOSTs. > What about rsync + ssh via pecker? Yeah, indeed, it will be rsync push to a module (I think I already enabled that). Not to pecker, but bootstrap.prefix.b.n directly. Some script-foo processes through cron and then does the analysis, etc. I think for remote targets (you) we can consider skipping the distfiles. The original idea I had behind shipping them is to make them available for the case where distfiles are no longer found. I usually pull them through my own mirror, but obviously this has the downside of not checking availability. (drop me a private mail, we can discuss the posibilities here to get your target's results pushed.) > > None of these targets are RAP by the way. I think the current CI is > > very good at that. > > Absolutely. However, it would be nice if we could integrate the Linux/RAP > results into this overwiew as well - besides the Linux/Guest ones, even > if they share the same CHOST... Yeah, perhaps just putting them aside. I already ran into LATEST_TREE_YES builds that are not the same as just bootstrapping of course. However, I think regarding the push I'd like some secrecy here regarding the access, so that's a slight problem. > Also, just've found https://wiki.gentoo.org/wiki/Prefix/tested where the > 'Last tried' column values seem outdated - maybe CI builds can provide > more recent dates there as well. > > > By the way, no bootstraps succeeded recently, so that's the goal to get > > that triggered so we can focus on fixing it. Just being able to pull in > > the CI success/fail for that would already be a start. > > FWIW, I've created a gentoo-prefix project with Azure pipelines, but their > 6 hours limit is too small for Prefix on Cygwin. So I've added my own > Windows VM there: https://dev.azure.com/gentoo-prefix/ci-builds/_build > However, I'm not sure if I should keep that for security concerns... > > BTW, Cygwin 3.0.0-0.8 does have the fork() that works for Gentoo Prefix! Hahaha, that is great news!!! Thanks, Fabian -- Fabian Groffen Gentoo on a different level signature.asc Description: PGP signature
