Re: [gentoo-user] Several packages failing to build

2018-05-14 Thread Elijah Mark Anderson 
On Monday, May 14, 2018 4:53:09 PM CDT Mick wrote:
> On Monday, 14 May 2018 21:07:17 BST Elijah Mark Anderson wrote:
> > On Monday, May 14, 2018 12:58:13 PM CDT Mick wrote:
> > > On Monday, 14 May 2018 18:20:01 BST Elijah Mark Anderson wrote:
> > > > I'm having an issue with about a dozen packages not upgrading. I'd
> > > > really
> > > > appreciate some help getting them to build and install. I'm getting
> > > > the
> > > > feeling that the problems are somehow related, but really not sure.
> > > > 
> > > > First up: dev-libs/appstream-0.11.5::gentoo
> > > > Anyone know what's going on here? This package is blocking at least 5
> > > > other
> > > > packages from upgrading, and I find the information in the logs only
> > > > slightly more helpful than WIndows "Something went wrong" errors.
> > > 
> > > It's worth checking in BGO to see if your problems with ~amd64 packages
> > > are
> > > already reported and if any patches/fixes/workarounds have been posted.
> > > In
> > > this case have a look here, I think it is the same problem you have
> > > experienced:
> > > 
> > > https://bugs.gentoo.org/640916
> > > 
> > > --
> > > Regards,
> > > Mick
> > 
> > I did come across that. I don't believe it is the same problem. For them,
> > the problem is during the install phase. Mine is occurring in compile
> > phase.
> 
> Fair enough, I did not dig into it at any depth.  Without knowing the real
> cause of this failure and if nothing else resolves it, I would try to
> rebuild gettext & perhaps libxml2:
> 
> emerge -1aDv sys-devel/gettext dev-libs/libxml2
> 
> then try emerging dev-libs/appstream once more.  Running ~arch involves more
> troubleshooting and experimenting than I have time at present, hence I
> stick with stable where I can.
> 
> --
> Regards,
> Mick

I tried as you suggested, to no avail. But, I *finally* found the actual error 
in the build log. I had forgotten that I was running emerge with MAKEOPTS="-
j9", which means that errors are not always at the bottom of the log. When I 
remembered it, I searched the log for "error[: ]", and bingo! Here's the 
relevant entry:

[39/106] /usr/bin/python3.5 /usr/lib/python-exec/python3.5/meson --internal 
msgfmthelper ../appstream-APPSTREAM_0_11_5/data/
org.freedesktop.appstream.cli.metainfo.xml data/
org.freedesktop.appstream.cli.metainfo.xml xml /var/tmp/portage/dev-libs/
appstream-0.11.5/work/appstream-APPSTREAM_0_11_5/po --datadirs=/var/tmp/
portage/dev-libs/appstream-0.11.5/work/appstream-APPSTREAM_0_11_5/data/
FAILED: data/org.freedesktop.appstream.cli.metainfo.xml 
/usr/bin/python3.5 /usr/lib/python-exec/python3.5/meson --internal 
msgfmthelper ../appstream-APPSTREAM_0_11_5/data/
org.freedesktop.appstream.cli.metainfo.xml data/
org.freedesktop.appstream.cli.metainfo.xml xml /var/tmp/portage/dev-libs/
appstream-0.11.5/work/appstream-APPSTREAM_0_11_5/po --datadirs=/var/tmp/
portage/dev-libs/appstream-0.11.5/work/appstream-APPSTREAM_0_11_5/data/
msgfmt: error while opening "/var/tmp/portage/dev-libs/appstream-0.11.5/work/
appstream-APPSTREAM_0_11_5/po/zh_TW.po/nja.po/npt_BR.po/n...@latin.po/ncs.po/
ngd.po/nfi.po/nid.po/nlt.po/nen_GB.po/nzh_CN.po/nuk.po/nckb.po/nar.po/nnl.po/
nru.po/nko.po/nda.po/nsr.po/nfr.po/nhu.po/npt.po/nit.po/nsv.po/nca.po/nes.po/
nde.po/nsl.po/noc.po/ngl.po/npl.po/ntr.po/nsk.po/neu.po" for reading: Not a 
directory

Looks like you were right after all, as https://bugs.gentoo.org/640916#c7 is 
indeed a pretty dang close match. Looks like a bug in the package itself. I'll 
mask this version, as #c13 claims this is fixed in 0.11.8. Hopefully that'll be 
in the tree soon™.
-- 
Elijah Mark Anderson
m...@kd0bpv.name
--
「塵も積もれば山となる。」
"Even dust, when piled up, becomes a mountain" - Ancient Japanese proverb

signature.asc
Description: This is a digitally signed message part.

Re: [gentoo-user] Several packages failing to build

2018-05-14 Thread Mick 
On Monday, 14 May 2018 21:07:17 BST Elijah Mark Anderson wrote:
> On Monday, May 14, 2018 12:58:13 PM CDT Mick wrote:
> > On Monday, 14 May 2018 18:20:01 BST Elijah Mark Anderson wrote:
> > > I'm having an issue with about a dozen packages not upgrading. I'd
> > > really
> > > appreciate some help getting them to build and install. I'm getting the
> > > feeling that the problems are somehow related, but really not sure.
> > > 
> > > First up: dev-libs/appstream-0.11.5::gentoo
> > > Anyone know what's going on here? This package is blocking at least 5
> > > other
> > > packages from upgrading, and I find the information in the logs only
> > > slightly more helpful than WIndows "Something went wrong" errors.
> > 
> > It's worth checking in BGO to see if your problems with ~amd64 packages
> > are
> > already reported and if any patches/fixes/workarounds have been posted. 
> > In
> > this case have a look here, I think it is the same problem you have
> > experienced:
> > 
> > https://bugs.gentoo.org/640916
> > 
> > --
> > Regards,
> > Mick
> 
> I did come across that. I don't believe it is the same problem. For them,
> the problem is during the install phase. Mine is occurring in compile
> phase.

Fair enough, I did not dig into it at any depth.  Without knowing the real 
cause of this failure and if nothing else resolves it, I would try to rebuild 
gettext & perhaps libxml2:

emerge -1aDv sys-devel/gettext dev-libs/libxml2

then try emerging dev-libs/appstream once more.  Running ~arch involves more 
troubleshooting and experimenting than I have time at present, hence I stick 
with stable where I can.

-- 
Regards,
Mick

signature.asc
Description: This is a digitally signed message part.

Re: [gentoo-user] plasma-desktop-5.12.4 build process hangs

2018-05-14 Thread P Levine 
On Mon, May 14, 2018 at 2:55 PM, R0b0t1  wrote:

> On Mon, May 14, 2018 at 12:23 PM, Elijah Mark Anderson 
> wrote:
> > On Thursday, April 19, 2018 12:23:32 PM CDT Mick wrote:
> >> On Thursday, 19 April 2018 14:44:40 BST Elijah Mark Anderson wrote:
> >> > A friend has commissioned me to install Gentoo on one of their
> machines
> >> > for
> >> > them. I'm trying to run some final updates before I turn it back over
> to
> >> > them, but it keeps hanging on plasma-desktop-5.12.4 after linking
> >> > kcm_fontinst.so (see attachment).
> >> >
> >> > Anyone know what's going wrong? Is this just a bug in the ebuild,
> maybe?
> >>
> >> Your log shows no error.  I had a look for bug reports, but couldn't
> find
> >> anything relevant.  If it reports no error, have you waited long enough
> for
> >> the emerge to complete?
> >>
> >> --
> >> Regards,
> >> Mick
> >
> > Sorry about the late reply. Life got a little busy for a bit there. I no-
> > longer have the machine in question. But a few days later, the owner of
> the
> > machine tried syncing the mirrors and updating again, and it went
> through.
> >
> > I would certainly hope I waited long enough... considering that when I
> tried
> > again, I left it running all night just in-case. lol. Thanks for trying.
> :)
> >
>
> This is what happened for me. Plasma was experiencing errors, I lost
> interest, I tried again, plasma was not experiencing build errors.
> Works for things besides Plasma as well!
>
> Open source has taught me patience on the span of years. I wish it
> were not necessary, of course.
>
> Cheers,
>  R0b0t1
>
>
​Or, it could be the fact that ​the patch and solution to the problem I
posted to this very thread was applied downstream:
https://gitweb.gentoo.org/repo/gentoo.git/diff/?id=4b2a7ee17866dd768651b51cd6640f39506a8469.
That might have saved you some time.

Re: [gentoo-user] Several packages failing to build

2018-05-14 Thread Elijah Mark Anderson 
On Monday, May 14, 2018 12:58:13 PM CDT Mick wrote:
> On Monday, 14 May 2018 18:20:01 BST Elijah Mark Anderson wrote:
> > I'm having an issue with about a dozen packages not upgrading. I'd really
> > appreciate some help getting them to build and install. I'm getting the
> > feeling that the problems are somehow related, but really not sure.
> > 
> > First up: dev-libs/appstream-0.11.5::gentoo
> > Anyone know what's going on here? This package is blocking at least 5
> > other
> > packages from upgrading, and I find the information in the logs only
> > slightly more helpful than WIndows "Something went wrong" errors.
> 
> It's worth checking in BGO to see if your problems with ~amd64 packages are
> already reported and if any patches/fixes/workarounds have been posted.  In
> this case have a look here, I think it is the same problem you have
> experienced:
> 
> https://bugs.gentoo.org/640916
> 
> --
> Regards,
> Mick

I did come across that. I don't believe it is the same problem. For them, the 
problem is during the install phase. Mine is occurring in compile phase.

-- 
Elijah Mark Anderson
m...@kd0bpv.name
--
「塵も積もれば山となる。」
"Even dust, when piled up, becomes a mountain" - Ancient Japanese proverb

signature.asc
Description: This is a digitally signed message part.

Re: [gentoo-user] plasma-desktop-5.12.4 build process hangs

2018-05-14 Thread R0b0t1 
On Mon, May 14, 2018 at 12:23 PM, Elijah Mark Anderson  wrote:
> On Thursday, April 19, 2018 12:23:32 PM CDT Mick wrote:
>> On Thursday, 19 April 2018 14:44:40 BST Elijah Mark Anderson wrote:
>> > A friend has commissioned me to install Gentoo on one of their machines
>> > for
>> > them. I'm trying to run some final updates before I turn it back over to
>> > them, but it keeps hanging on plasma-desktop-5.12.4 after linking
>> > kcm_fontinst.so (see attachment).
>> >
>> > Anyone know what's going wrong? Is this just a bug in the ebuild, maybe?
>>
>> Your log shows no error.  I had a look for bug reports, but couldn't find
>> anything relevant.  If it reports no error, have you waited long enough for
>> the emerge to complete?
>>
>> --
>> Regards,
>> Mick
>
> Sorry about the late reply. Life got a little busy for a bit there. I no-
> longer have the machine in question. But a few days later, the owner of the
> machine tried syncing the mirrors and updating again, and it went through.
>
> I would certainly hope I waited long enough... considering that when I tried
> again, I left it running all night just in-case. lol. Thanks for trying. :)
>

This is what happened for me. Plasma was experiencing errors, I lost
interest, I tried again, plasma was not experiencing build errors.
Works for things besides Plasma as well!

Open source has taught me patience on the span of years. I wish it
were not necessary, of course.

Cheers,
 R0b0t1

Re: [gentoo-user] which microcode gets loaded?

2018-05-14 Thread David Haller 
Hello,

On Mon, 14 May 2018, tu...@posteo.de wrote:
[..]
>cat /proc/cpuinfo (from one of the six cores):
>processor  : 4
>vendor_id  : AuthenticAMD
>cpu family : 16
  ^^ decimal = 10h(ex)
>model  : 10
>model name : AMD Phenom(tm) II X6 1090T Processor
[..]
>from linux-firmware (related lines):
>/lib/firmware/amd-ucode/microcode_amd.bin
>/lib/firmware/amd-ucode/microcode_amd_fam15h.bin
>/lib/firmware/amd-ucode/microcode_amd_fam16h.bin  ***
>/lib/firmware/amd-ucode/microcode_amd_fam17h.bin
>
>(***) I think, these microcodes do I need...

Nope. You need microcode_amd.bin, if any. Go into the git-repo for
sys-kernel/linux-firmware[1] and you'll find that the non-versioned
microcode_amd.bin is for fam10h - fam14h.

HTH,
-dnh

[1] https://git.kernel.org/?p=linux/kernel/git/firmware/linux-firmware.git

-- 
I love deadlines. I like the whooshing sound they make as they fly by.
   -- Douglas Adams

Re: [gentoo-user] Several packages failing to build

2018-05-14 Thread Mick 
On Monday, 14 May 2018 18:20:01 BST Elijah Mark Anderson wrote:
> I'm having an issue with about a dozen packages not upgrading. I'd really
> appreciate some help getting them to build and install. I'm getting the
> feeling that the problems are somehow related, but really not sure.
> 
> First up: dev-libs/appstream-0.11.5::gentoo
> Anyone know what's going on here? This package is blocking at least 5 other
> packages from upgrading, and I find the information in the logs only
> slightly more helpful than WIndows "Something went wrong" errors.

It's worth checking in BGO to see if your problems with ~amd64 packages are 
already reported and if any patches/fixes/workarounds have been posted.  In 
this case have a look here, I think it is the same problem you have 
experienced:

https://bugs.gentoo.org/640916

-- 
Regards,
Mick

signature.asc
Description: This is a digitally signed message part.

Re: [gentoo-user] plasma-desktop-5.12.4 build process hangs

2018-05-14 Thread Elijah Mark Anderson 
On Thursday, April 19, 2018 12:23:32 PM CDT Mick wrote:
> On Thursday, 19 April 2018 14:44:40 BST Elijah Mark Anderson wrote:
> > A friend has commissioned me to install Gentoo on one of their machines
> > for
> > them. I'm trying to run some final updates before I turn it back over to
> > them, but it keeps hanging on plasma-desktop-5.12.4 after linking
> > kcm_fontinst.so (see attachment).
> > 
> > Anyone know what's going wrong? Is this just a bug in the ebuild, maybe?
> 
> Your log shows no error.  I had a look for bug reports, but couldn't find
> anything relevant.  If it reports no error, have you waited long enough for
> the emerge to complete?
> 
> --
> Regards,
> Mick

Sorry about the late reply. Life got a little busy for a bit there. I no-
longer have the machine in question. But a few days later, the owner of the 
machine tried syncing the mirrors and updating again, and it went through.

I would certainly hope I waited long enough... considering that when I tried 
again, I left it running all night just in-case. lol. Thanks for trying. :)

-- 
Elijah Mark Anderson
m...@kd0bpv.name
--
「塵も積もれば山となる。」
"Even dust, when piled up, becomes a mountain" - Ancient Japanese proverb

signature.asc
Description: This is a digitally signed message part.

[gentoo-user] Several packages failing to build

2018-05-14 Thread Elijah Mark Anderson 
I'm having an issue with about a dozen packages not upgrading. I'd really 
appreciate some help getting them to build and install. I'm getting the 
feeling that the problems are somehow related, but really not sure.

First up: dev-libs/appstream-0.11.5::gentoo
Anyone know what's going on here? This package is blocking at least 5 other 
packages from upgrading, and I find the information in the logs only slightly 
more helpful than WIndows "Something went wrong" errors.
-- 
Elijah Mark Anderson
m...@kd0bpv.name
--
「塵も積もれば山となる。」
"Even dust, when piled up, becomes a mountain" - Ancient Japanese proverb * Package:dev-libs/appstream-0.11.5
 * Repository: gentoo
 * Maintainer: k...@gentoo.org
 * USE:abi_x86_64 amd64 elibc_glibc kernel_linux qt5 userland_GNU
 * FEATURES:   preserve-libs sandbox userpriv usersandbox
>>> Unpacking source...
>>> Unpacking appstream-0.11.5.tar.gz to /var/tmp/portage/dev-libs/appstream-0.11.5/work
>>> Source unpacked in /var/tmp/portage/dev-libs/appstream-0.11.5/work
>>> Preparing source in /var/tmp/portage/dev-libs/appstream-0.11.5/work/appstream-APPSTREAM_0_11_5 ...
>>> Source prepared.
>>> Configuring source in /var/tmp/portage/dev-libs/appstream-0.11.5/work/appstream-APPSTREAM_0_11_5 ...
meson --buildtype plain --libdir lib64 --localstatedir /var/lib --prefix /usr --sysconfdir /etc --wrap-mode nodownload -Denable-docs=false -Denable-maintainer=false -Denable-stemming=true -Denable-vapi=false -Denable-apt-support=false -Denable-apidocs=false -Denable-qt=true /var/tmp/portage/dev-libs/appstream-0.11.5/work/appstream-APPSTREAM_0_11_5 /var/tmp/portage/dev-libs/appstream-0.11.5/work/appstream-0.11.5-build
The Meson build system
Version: 0.46.0
Source dir: /var/tmp/portage/dev-libs/appstream-0.11.5/work/appstream-APPSTREAM_0_11_5
Build dir: /var/tmp/portage/dev-libs/appstream-0.11.5/work/appstream-0.11.5-build
Build type: native build
Project name: AppStream
Native C compiler: x86_64-pc-linux-gnu-gcc (gcc 7.3.0 "x86_64-pc-linux-gnu-gcc (Gentoo 7.3.0-r1 p1.1) 7.3.0")
Appending CFLAGS from environment: '-march=native -O2 -pipe'
Appending LDFLAGS from environment: '-Wl,-O1 -Wl,--as-needed'
Build machine cpu family: x86_64
Build machine cpu: x86_64
Configuring config.h using configuration
Found pkg-config: /usr/bin/x86_64-pc-linux-gnu-pkg-config (0.29.2)
Native dependency glib-2.0 found: YES 2.52.3
Native dependency gobject-2.0 found: YES 2.52.3
Native dependency gio-2.0 found: YES 2.52.3
Native dependency gio-unix-2.0 found: YES 2.52.3
Native dependency libxml-2.0 found: YES 2.9.8
Native dependency yaml-0.1 found: YES 0.1.7
Library stemmer found: YES
Has header "libstemmer.h": YES
Native dependency glib-2.0 found: YES 2.52.3
Native dependency gobject-introspection-1.0 found: YES 1.52.1
Program xsltproc found: YES (/usr/bin/xsltproc)
Native C++ compiler: x86_64-pc-linux-gnu-g++ (gcc 7.3.0 "x86_64-pc-linux-gnu-g++ (Gentoo 7.3.0-r1 p1.1) 7.3.0")
Appending CXXFLAGS from environment: '-march=native -O2 -pipe'
Appending LDFLAGS from environment: '-Wl,-O1 -Wl,--as-needed'
WARNING: rcc dependencies will not work reliably until this upstream issue is fixed: https://bugreports.qt.io/browse/QTBUG-45460
Native dependency Qt5Core found: YES 5.9.5
Qt5 native `pkg-config` dependency (modules: Core) found: YES
Detecting Qt5 tools
 moc: YES (/usr/lib64/qt5/bin/moc, 5.9.5)
 uic: YES (/usr/lib64/qt5/bin/uic, 5.9.5)
 rcc: YES (/usr/lib64/qt5/bin/rcc, 5.9.5)
 lrelease: YES (/usr/lib64/qt5/bin/lrelease, 5.9.5)
Native dependency Qt5Core found: YES 5.9.5
Native dependency Qt5Test found: YES 5.9.5
Qt5 native `pkg-config` dependency (modules: Core, Test) found: YES
Configuring testpaths.h using configuration
Configuring AppStreamQtConfig.cmake using configuration
Configuring AppStreamQtConfigVersion.cmake using configuration
Build targets in project: 19
Found ninja-1.8.2 at /usr/bin/ninja
>>> Source configured.
>>> Compiling source in /var/tmp/portage/dev-libs/appstream-0.11.5/work/appstream-APPSTREAM_0_11_5 ...
ninja -v -j9 -l0 -C /var/tmp/portage/dev-libs/appstream-0.11.5/work/appstream-0.11.5-build
ninja: Entering directory `/var/tmp/portage/dev-libs/appstream-0.11.5/work/appstream-0.11.5-build'
[1/106] glib-compile-resources ../appstream-APPSTREAM_0_11_5/src/appstream.gresource.xml --sourcedir ../appstream-APPSTREAM_0_11_5/src/../data --sourcedir ../appstream-APPSTREAM_0_11_5/src/ --c-name as --internal --generate --target src/as-resources.h
[2/106]

Re: [gentoo-user] which microcode gets loaded?

2018-05-14 Thread Rich Freeman 
On Mon, May 14, 2018 at 10:46 AM Corbin Bird  wrote:

> No Spectre/Meltdown fixes in these files, apparently.


As far as I'm aware AMD has not directly released any public microcode
fixes to address spectre (AMD is not vulnerable to meltdown).  They've
apparently given something to motherboard manufacturers, who may or may not
be putting microcode updates into firmware updates.

I think I already commented recently that I'm not particularly happy with
AMD's level of documentation around their microcode, or the way they
release updates.

As far as I'm aware linux-firmware hasn't received any spectre-related AMD
microcode updates.  There may be important non-spectre-related updates in
there, however.  I couldn't tell you for sure because I can't find any
clear documentation as to what the AMD microcode updates in linux-firmware
actually do.

-- 
Rich

Re: [gentoo-user] which microcode gets loaded?

2018-05-14 Thread Corbin Bird 
On 05/13/2018 10:39 PM, tu...@posteo.de wrote:

> Hi,
>
> from a previous thread I learned which micorcode file needs
> to be loaded for the "fight against Spectre and Melddown"...
>
> Now two question came up for me:
> 1.) WIth this particular micorcode loaded: Do I need to activate
> the Spectre/Meldtown fix in the kernel itsself?
> 2.) Which microcode file gets loaded?
>
> cat /proc/cpuinfo (from one of the six cores):
> processor : 4
> vendor_id : AuthenticAMD
> cpu family: 16
> model : 10
> model name: AMD Phenom(tm) II X6 1090T Processor
> stepping  : 0
> microcode : 0x1bf
> cpu MHz   : 1755.530
> cache size: 512 KB
> physical id   : 0
> siblings  : 6
> core id   : 4
> cpu cores : 6
> apicid: 4
> initial apicid: 4
> fpu   : yes
> fpu_exception : yes
> cpuid level   : 6
> wp: yes
> flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov 
> pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt pdpe1gb 
> rdtscp lm 3dnowext 3dnow constant_tsc rep_good nopl nonstop_tsc cpuid 
> extd_apicid aperfmperf pni monitor cx16 popcnt lahf_lm cmp_legacy svm extapic 
> cr8_legacy abm sse4a misalignsse 3dnowprefetch osvw ibs skinit wdt cpb 
> hw_pstate vmmcall npt lbrv svm_lock nrip_save pausefilter
> bugs  : tlb_mmatch apic_c1e fxsave_leak sysret_ss_attrs null_seg 
> amd_e400 spectre_v1 spectre_v2
> bogomips  : 7224.41
> TLB size  : 1024 4K pages
> clflush size  : 64
> cache_alignment   : 64
> address sizes : 48 bits physical, 48 bits virtual
> power management: ts ttp tm stc 100mhzsteps hwpstate cpb
>
>
> from dmesg (microcode-related lines):
> [1.517265] microcode: CPU0: patch_level=0x01bf
> [1.517367] microcode: CPU1: patch_level=0x01bf
> [1.517450] microcode: CPU2: patch_level=0x01bf
> [1.517538] microcode: CPU3: patch_level=0x01bf
> [1.517628] microcode: CPU4: patch_level=0x01bf
> [1.517716] microcode: CPU5: patch_level=0x01bf
> [1.517824] microcode: Microcode Update Driver: v2.2.
>
> from linux-firmware (related lines):
> /lib/firmware/amd-ucode/microcode_amd.bin
> /lib/firmware/amd-ucode/microcode_amd_fam15h.bin
> /lib/firmware/amd-ucode/microcode_amd.bin.asc
> /lib/firmware/amd-ucode/microcode_amd_fam16h.bin  ***
> /lib/firmware/amd-ucode/microcode_amd_fam17h.bin
> /lib/firmware/amd-ucode/microcode_amd_fam16h.bin.asc  ***
> /lib/firmware/amd-ucode/microcode_amd_fam15h.bin.asc
>
> (***) I think, these microcodes do I need...
>
> Thanks for any help in advance!
> Cheers
>  Meino
>
>
>
>
>
.

No Spectre/Meltdown fixes in these files, apparently.

Simple experiment(s) to confirm the ucode file to use : ( repetitive, but 
simple )

Build a kernel with NO ucode, boot, note the patch_level.
Build a kernel with microcode_amd.bin ucode ONLY, boot, note the patch_level.
Build a kernel with microcode_amd_fam15h ucode ONLY, boot, note the patch_level.
Build a kernel with microcode_amd_fam16h ucode ONLY, boot, note the patch_level.
Build a kernel with microcode_amd_fam17h ucode ONLY, boot, note the patch_level.

Results :
When I did this on a Phenom II 980 x4, the only time the patch level changed 
was with "microcode_amd.bin" ucode.  
When I do this on a FX-9590, the only time the patch level changes is when 
"microcode_amd_fam15h.bin" ucode is used.

Corbin