<oriansj>stikonas: Nope doing ACCEPT_LICENSE="-* @FREE" in /etc/portage/make.conf still results in media-fonts/font-bh-ttf having a license issue. <sam_>it would, as FREE is still the default <sam_>can you show me the output? <sam_>i.e. setting that is a noop <oriansj>sam_: sure, just let me build pastebinit and I'll have that uploaded shortly after <sam_>profiles/license_groups:70:BINARY-REDISTRIBUTABLE @FREE Amazon Atmel AVASYS bh-luxi bonnie Broadcom freedist intel-ucode ipw2100-fw ipw2200-fw ipw3945 ISSL JSON linux-fw-redistributable LSI-tw_cli Mellanox-AS-IS MicroChip-SDCC no-source-code NVIDIA-r1 NVIDIA-r2 qlogic-fibre-channel-firmware shmux SmartLabs unRAR <sam_>it's in the @BINARY-REDISTRIBUTABLE licence set <sam_>1. always allow @BINARY-REDISTRIBUTABLE (I doubt you want this) <sam_>2. allow the 'bh-luxi' licence purely for this package <sam_>3. allow the 'bh-luxi' licence for media-fonts/* <sam_>4. allow @BINARY-REDISTRIBUTABLE (or any) for media-fonts/* <sam_>5. something else I'm forgetting <oriansj>is there an option of setting an alternate font? <sam_>good question, was just checking that <sam_>so x11-base/xorg-x11 is a meta package with a USE=fonts which just tries to pull in a bunch of fonts it thinks you'll want <sam_>i.e. they're not real dependencies of something per se <oriansj>so how do I strip away the non-free? <sam_>I suspect best option is: 1. set USE=-fonts on xorg-x11 in package.use, then 2. either see what's broken, if anything, or we proactively look for some alternative font now <sam_>(this is an interesting issue we should poke at more, I don't have a chance right now, bu we might be able to make xorg-x11 in future depend on default free stuff instead) <sam_>I suspect you can just live without that font <sam_>as long as you have a provider of virtual/ttf-fonts <oriansj>well I haven't setup a virtual/ttf-fonts yet because I didn't know to do so yet <sam_>something should depend on it so you should be fine <sam_>so purely setting USE=-fonts on xorg-x11 might be sufficient <oriansj>so echo "x11-base/xorg-x11 USE=-fonts" >> /etc/portage/package.use/x11 <sam_>echo "x11-base/xorg-x11 -fonts" >> /etc/portage/package.use/x11 <oriansj>and it looks like it solved the issue (the build is starting) <oriansj>after that I hopefully can make i3 and see a functional GUI <sam_>(and no, you really stumbled on a real issue anyway: it should be harder for users to hit such a problem immediately) <sam_>i'll file a bug for it but c an't poke at it properly atm ***ChanServ sets mode: +o janneke
***Server sets mode: +cnt
<ekaitz>hi! I have a weird instruction that is not supported by M1 appearing when compiling with mes <ekaitz>it appears when compiling a function from a modified TCC <ekaitz>stikonas[m]: do you have any idea about what's going on here? <ekaitz>I have exactly 0 knowledge about i386 and x84, btw <ekaitz>me neither, that's my big problem <ekaitz>is there any way I can use to track where does that exactly come from? <ekaitz>mov____%si,(%rdi) <--- this one is the only other wrong instruction it generates <ekaitz>stikonas[m]: let me take a look (i'm not very used to M1 so it's going to be hard :) ) <ekaitz>the full mov___... is not defined <ekaitz>but there are some uses of the sil (commented) <ekaitz>#DEFINE movsbq_%sil,%rsi 480fbef6 <ekaitz>why i don't understand is why is the compilation process generating an instruction it doesn't know, which one is the previous step? why does it do that? <stikonas[m]>Probably somebody added new instruction in emitted code but did not add how it expands <stikonas[m]>Check commit where that line was added with git blame <ekaitz>oh I can't find who generated this instruction ***Noisytoot_ is now known as Noisytoot
<ekaitz>stikonas[m]: no, it's not there, but i can't either find it in the generator