Created attachment 458632 [details] build.log It looks like this: /var/tmp/portage/dev-libs/icu-58.2/work/icu/source/i18n/digitlst.cpp:67:24: fatal error: xlocale.h: No such file or directory # include <xlocale.h> ^ compilation terminated. Openembedded seems to also have run into this problem: http://lists.openembedded.org/pipermail/openembedded-core/2016-November/128323.html It affects versions 58.1-r1 and 58.2. Very much musl-libc related. I will mask them on my system and use v57.1 for now. I also just rebuilt dev-libs/icu-57.1 to make sure it still works, and I can confirm that my system still builds dev-libs/icu-57.1 just fine.
Created attachment 458634 [details] emerge --info '=dev-libs/icu-58.2::gentoo'
Created attachment 458636 [details] emerge -pqv '=dev-libs/icu-58.2::gentoo'
The versions from the musl overlay should work fine for you. This bug is also reported upstream: http://bugs.icu-project.org/trac/ticket/12851
Hmmm, I don't see versions in the musl overlay. Here is what comes up for dev-libs/icu: $ eix -e icu [I] dev-libs/icu Available versions: 55.1(0/55) 57.1(0/57) [m]58.1-r1(0/58.1) [m]~58.2(0/58.2) {debug doc examples static-libs ABI_MIPS="n32 n64 o32" ABI_PPC="32 64" ABI_S390="32 64" ABI_X86="32 64 x32"} Installed versions: 57.1(02:17:43 01/04/17)(-debug -doc -examples -static-libs ABI_MIPS="-n32 -n64 -o32" ABI_PPC="-32 -64" ABI_S390="-32 -64" ABI_X86="64 -32 -x32") Homepage: http://www.icu-project.org/ Description: International Components for Unicode By comparison, here is gcc, which I will use to demonstrate that the musl overlay is present elsewhere: $ eix -e gcc [I] sys-devel/gcc Available versions: (2.95.3) [m]~*2.95.3-r10^s (3.3.6) [m]~3.3.6-r1^s (3.4.6) [m]3.4.6-r2^s (4.0.4) [m]**4.0.4^s (4.1.2) [m]4.1.2^s (4.2.4) [m]~4.2.4-r1^s (4.3.6) [m]4.3.6-r1^s (4.4.7) [m]4.4.7^s (4.5.4) [m]4.5.4^s (4.6.4) [m]4.6.4^s (4.7.4) [m]4.7.4^s 4.7.4-r99^s[1] (4.8.5) [m]4.8.5^s 4.8.5-r99^s[1] 4.8.5-r999^s[1] (4.9.3) [m]4.9.3^s 4.9.3-r99^s[1] **4.9.3-r999^s[1] (4.9.4) [m]4.9.4^s (5.1.0) [m]**5.1.0^s (5.2.0) [m]**5.2.0^s (5.3.0) [m]~5.3.0^s (5.4.0) [m]~5.4.0^s [m]~5.4.0-r2^s (6.1.0) **6.1.0^s[1] (6.3.0) [m]**6.3.0^s {altivec awt boundschecking cilk +cxx d debug doc fixed-point +fortran gcj go graphite hardened jit libssp mpx mudflap multilib multislot +nls nopie nossp +nptl objc objc++ objc-gc +openmp (+)pch pie regression-test +sanitize (+)ssp vanilla +vtv} Installed versions: 4.9.3-r99(4.9.3)^s[1](00:46:50 08/28/16)(cxx fortran gcj hardened nptl openmp -altivec -awt -cilk -debug -doc -fixed-point -go -graphite -libssp -multilib -multislot -nls -nopie -nossp -objc -objc++ -objc-gc -regression-test -sanitize -vanilla) Homepage: https://gcc.gnu.org/ Description: The GNU Compiler Collection [1] "musl" /var/lib/layman/musl Thanks!
Are you sure that your copy of the musl overlay is up to date? Note that the version of sandbox that you are using does not exist anymore.
I ran eix-sync that day. That should give me updated trees in portage and all overlays, right? If not, how do I update my update?
Below is the URL that I am pulling my musl overlay from. Perhaps it is out of date, or I picked the wrong one somehow? $ layman -l * musl [Git ] (git://anongit.gentoo.org/proj/musl.git)
eix-sync should sync everything if "*" is in /etc/eix-sync.conf, or indirectly when /etc/portage/repos.conf is set up for all overlays. The url for the musl overlay is correct.
I can't confirm those above things: I don't have an /etc/eix-sync.conf file and /etc/portage/repos.conf is a directory containing gentoo.conf and local.conf. If I run `eix --dump | grep -i sync` then I get this: # This variable is used for delayed substitution in EIX_SYNC_CONF. # It contains code which is evaluated by eix-sync, so be aware of security! EIX_SYNC_OPTS="" # The content of this variable is appended to /etc/eix-sync.conf # Parts of this variable are evaluated in eix-sync: Be aware of security! EIX_SYNC_CONF="%{EIX_SYNC_OPTS}" # This file is the previous eix cache (used by eix-diff and eix-sync). So I don't think it gets the *. However, I am pretty sure it is updating musl. When I run `eix-sync`, I see this text among other things: Reading Portage settings... Building database (/var/cache/eix/portage.eix)... [0] "gentoo" /usr/portage/ (cache: metadata-md5-or-flat) Reading category 163|163 (100) Finished [1] "musl" /var/lib/layman/musl (cache: parse|ebuild*#metadata-md5#metadata-flat#assign) Reading category 163|163 (100) Finished [2] "local" /usr/local/portage (cache: parse|ebuild*#metadata-md5#metadata-flat#assign) Reading category 163|163 (100) Finished I think it is picking up the "/var/lib/layman/musl" in /var/lib/layman/make.conf. I suspect I set it up that way so that layman can manage its own references, or maybe documentation somewhere told me to do it ;) I do really wish I knew why we see different overlay contents, since this could have a profound impact on what I report in the bug tracker. I should probably mention that while my sandbox version seems non-existent to you, it is most recent (stable) from my view of the universe: $ eix -e sandbox [I] sys-apps/sandbox Available versions: 2.6-r1 2.6-r999[1] ~2.7 ~2.8 ~2.9 2.10-r1 ~2.10-r2 ~2.10-r3 2.10-r99[1] [M]~2.11-r3 [M]~2.11-r4 {multilib ABI_MIPS="n32 n64 o32" ABI_PPC="32 64" ABI_S390="32 64" ABI_X86="32 64 x32"} Installed versions: 2.10-r99[1](12:32:53 08/04/16)(-multilib) Homepage: http://www.gentoo.org/proj/en/portage/sandbox/ Description: sandbox'd LD_PRELOAD hack [1] "musl" /var/lib/layman/musl This is right after I ran eix-sync to get the above "Building database" text. Sorry for bringing a weird configuration problem. o.O And thanks for helping with it.
I am very sure that your copy of the musl overlay is not being synced. sandbox-2.6-r999 was removed on Nov 17. Please take a look at https://wiki.gentoo.org/wiki/Eix#Method_2:_Using_eix-sync Or alternatively refer to https://wiki.gentoo.org/wiki//etc/portage/repos.conf on how to set up /etc/portage/repos.conf . Make sure that the musl overlay has higher priority than the main tree. I don't think it is has hurted to report this bug since it also tracks the upstream issue with icu.
I am very sure that you're right. I read those links, and I think the * in /etc/eix-sync.conf did the trick for this system. Now I see some steps in eix-sync that I did not see before: [...] delete mode 100644 x11-libs/libva-vdpau-driver/files/libva-vdpau-driver-0.7.4-nouveau.patch rename x11-libs/libva-vdpau-driver/{libva-vdpau-driver-0.7.4-r99.ebuild => libva-vdpau-driver-0.7.4-r4.ebuild} (93%) delete mode 100644 x11-libs/vte/files/vte-0.42.4-fix-musl-NULLs.patch delete mode 100644 x11-libs/vte/vte-0.42.4-r99.ebuild create mode 100644 x11-misc/slim/files/slim-1.3.6-envcpy-bad-pointer-arithmetic.patch create mode 100644 x11-misc/slim/files/slim-1.3.6-freetype.patch rename x11-misc/slim/{slim-1.3.6-r99.ebuild => slim-1.3.6-r5.ebuild} (65%) * * Succeeded: * ------ * Successfully synchronized overlay "musl". * And I see musl overlay entries for dev-libs/icu: $ eix -e icu [I] dev-libs/icu Available versions: 55.1(0/55) 57.1(0/57) [m]58.1-r1(0/58.1) [m]58.1-r1(0/58.1)[1] [m]~58.2(0/58.2) [m]~58.2(0/58.2)[1] {debug doc examples static-libs ABI_MIPS="n32 n64 o32" ABI_PPC="32 64" ABI_S390="32 64" ABI_X86="32 64 x32"} Installed versions: 57.1(02:17:43 01/04/17)(-debug -doc -examples -static-libs ABI_MIPS="-n32 -n64 -o32" ABI_PPC="-32 -64" ABI_S390="-32 -64" ABI_X86="64 -32 -x32") Homepage: http://www.icu-project.org/ Description: International Components for Unicode [1] "musl" /var/lib/layman/musl Overlay priorities seem fine to my eyes: $ emerge --info --verbose | sed -n '/^Repo/,/^ABI/p' | head -n -1 Repositories: gentoo location: /usr/portage sync-type: rsync sync-uri: rsync://rsync.gentoo.org/gentoo-portage priority: -1000 musl location: /var/lib/layman/musl masters: gentoo priority: 0 local location: /usr/local/portage masters: gentoo priority: 1 ... I'll have to do some unmasking/updating later. So, uh, neglecting to put * into /etc/eix-sync.conf is kind of disastrous. Oh my. Thanks so much for helping me figure that out.
I think this bug can be closed, right?
(In reply to tt_1 from comment #12) > I think this bug can be closed, right? No objections here.
The reporter can close this bug as well, and in this case should, if it has been resolved.