F-21 Branched report: 20140928 changes

2014-09-28 Thread Fedora Branched Report 
Compose started at Sun Sep 28 07:15:02 UTC 2014

Broken deps for armhfp
--
[PyQuante]
PyQuante-libint-1.6.4-11.fc21.1.armv7hl requires libint(armv7hl-32) = 
0:1.1.6-2.fc21
[askbot]
askbot-0.7.48-13.fc21.noarch requires python-django14
[audtty]
audtty-0.1.12-9.fc20.armv7hl requires libaudclient.so.2
[authhub]
authhub-0.1.2-3.fc19.armv7hl requires libjson.so.0
[avro]
avro-mapred-1.7.5-9.fc21.noarch requires hadoop-mapreduce
avro-mapred-1.7.5-9.fc21.noarch requires hadoop-client
[cduce]
cduce-0.5.5-9.fc21.armv7hl requires ocaml(Camlp4) = 
0:ebd368022fd2bc7b305a42902efa4c90
[check-mk]
check-mk-agent-1.2.4p5-1.fc21.armv7hl requires /usr/bin/ksh
check-mk-multisite-1.2.4p5-1.fc21.noarch requires /usr/bin/ksh
[cp2k]
cp2k-2.5.1-8.fc21.armv7hl requires libint(armv7hl-32) = 0:1.1.6-2.fc21
cp2k-mpich-2.5.1-8.fc21.armv7hl requires libint(armv7hl-32) = 
0:1.1.6-2.fc21
cp2k-openmpi-2.5.1-8.fc21.armv7hl requires libmpi_usempi.so.1
cp2k-openmpi-2.5.1-8.fc21.armv7hl requires libint(armv7hl-32) = 
0:1.1.6-2.fc21
[deltacloud-core]
deltacloud-core-rackspace-1.1.3-1.fc20.noarch requires 
rubygem(cloudservers)
deltacloud-core-rackspace-1.1.3-1.fc20.noarch requires 
rubygem(cloudfiles)
[django-recaptcha]
django-recaptcha-0.1-7.20091212svn6.fc21.noarch requires python-django14
[docker-registry]
docker-registry-0.7.3-1.fc21.noarch requires docker-io
[dragonegg]
dragonegg-3.4-0.3.rc0.fc21.armv7hl requires gcc = 0:4.8.2-14.fc21
[edelib]
edelib-2.1-5.fc21.armv7hl requires libedelib.so
edelib-devel-2.1-5.fc21.armv7hl requires libedelib.so
[elpa]
elpa-openmpi-2013.11-4.008.fc21.armv7hl requires libmpi_usempi.so.1
[eucalyptus]
eucalyptus-common-java-3.3.0-0.5.20130408git32052445.fc20.armv7hl 
requires hibernate3-jbosscache >= 0:3.6.10-7
[fatrat]
1:fatrat-1.2.0-0.21.beta2.fc21.armv7hl requires 
libtorrent-rasterbar.so.7
[flashrom]
flashrom-0.9.6.1-5.svn1705.fc20.armv7hl requires libftdi.so.1
[flush]
flush-0.9.12-10.fc21.armv7hl requires libtorrent-rasterbar.so.7
[freesteam]
freesteam-ascend-2.1-6.20140724svn753.fc21.armv7hl requires 
libascend.so.1
[gcc-python-plugin]
gcc-python2-debug-plugin-0.12-18.fc21.armv7hl requires gcc = 
0:4.8.2-14.fc21
gcc-python2-plugin-0.12-18.fc21.armv7hl requires gcc = 0:4.8.2-14.fc21
gcc-python3-debug-plugin-0.12-18.fc21.armv7hl requires 
libpython3.3dm.so.1.0
gcc-python3-debug-plugin-0.12-18.fc21.armv7hl requires gcc = 
0:4.8.2-14.fc21
gcc-python3-plugin-0.12-18.fc21.armv7hl requires libpython3.3m.so.1.0
gcc-python3-plugin-0.12-18.fc21.armv7hl requires gcc = 0:4.8.2-14.fc21
[gdb-heap]
gdb-heap-0.5-18.fc21.armv7hl requires glibc(armv7hl-32) = 0:2.19.90
[gedit-valencia]
gedit-valencia-0.4.0-1.20131223git94442bf.fc21.armv7hl requires 
libvala-0.24.so.0
[ghc-hgettext]
ghc-hgettext-devel-0.1.30-2.fc21.armv7hl requires 
ghc-devel(setlocale-0.0.3-3cf3e7ebddb81827019e2578a9fb3114)
[gnome-python2-desktop]
gnome-python2-metacity-2.32.0-18.fc21.armv7hl requires 
libmetacity-private.so.0
[gnome-shell-extension-pomodoro]
gnome-shell-extension-pomodoro-0.10.0-4.fc21.armv7hl requires 
libupower-glib.so.2
[gofer]
ruby-gofer-0.77.1-2.fc21.noarch requires rubygem(qpid) >= 0:0.16.0
[js-of-ocaml]
js-of-ocaml-1.3.2-4.fc21.armv7hl requires ocaml(Camlp4) = 
0:ebd368022fd2bc7b305a42902efa4c90
[leiningen]
leiningen-1.7.1-7.fc20.noarch requires maven-ant-tasks
leiningen-1.7.1-7.fc20.noarch requires classworlds
[libghemical]
libghemical-2.99.1-24.fc20.armv7hl requires libf77blas.so.3
libghemical-2.99.1-24.fc20.armv7hl requires libatlas.so.3
[libopensync-plugin-irmc]
1:libopensync-plugin-irmc-0.22-7.fc20.armv7hl requires libopenobex.so.1
[ltsp]
ltsp-client-5.4.5-8.fc21.armv7hl requires fuse-unionfs
ltsp-server-5.4.5-8.fc21.armv7hl requires cdialog
[meshmagick]
meshmagick-0.6.0-20.svn2898.fc21.armv7hl requires libOgreMain.so.1.8.1
meshmagick-libs-0.6.0-20.svn2898.fc21.armv7hl requires 
libOgreMain.so.1.8.1
[monodevelop-vala]
monodevelop-vala-2.8.8.1-6.fc21.armv7hl requires vala < 0:0.25.0
[netdisco]
netdisco-1.1-7.fc21.noarch requires perl(SNMP::Info::Layer2::Bay)
[nodejs-w3cjs]
nodejs-w3cjs-0.1.25-1.fc21.noarch requires npm(superagent-proxy) < 0:0.3
nodejs-w3cjs-0.1.25-1.fc21.noarch requires npm(superagent-proxy) >= 
0:0.2.0
nodejs-w3cjs-0.1.25-1.fc21.noarch requires npm(commander) < 0:2.1
[ocaml-bin-prot]
ocaml-bin-prot-2.0.9-9.fc21.armv7hl requires ocaml(Camlp4) = 
0:ebd368022fd2bc7b305a42902efa4c90
[ocaml-bisect]
ocaml-bisect-1.3-3.fc21.armv7hl requires ocaml(Camlp4) = 
0:ebd368022fd2bc7b305a42902efa4c90
[ocaml-bitstring]
ocaml-bitstring

Re: Intent to update libinfinity to 0.6.1 (soname bump)

2014-09-28 Thread Kalev Lember 
On 09/26/2014 08:27 PM, Till Maas wrote:
> On Sat, Sep 20, 2014 at 04:00:36PM +0200, Kalev Lember wrote:
> 
>>> What are your opinions?
>>
>> gedit-collaboration should probably be retired in F21+. It's largely
>> unmaintained upstream and doesn't work with latest gedit anyway.
>>
>> Nacho, any opinions?
> 
> If gedit-collaboration can be retired, we can move forward with this. If
> I get a go-ahead, I will do the retirement.

I just talked to nacho and apparently his reply to the mailing list got
caught in moderation. He wanted to say that it's fine to retire
gedit-collaboration until someone takes up the work upstream and makes
it properly work again.

It's now retired in both F21 and master. Feel free to go ahead with the
libinfinity builds.

-- 
Thanks,
Kalev
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

rawhide report: 20140928 changes

2014-09-28 Thread Fedora Rawhide Report 
Broken deps for i386
--
[Agda]
ghc-Agda-2.3.2.2-5.fc22.i686 requires libHSterminfo-0.3.2.5-ghc7.6.3.so
ghc-Agda-2.3.2.2-5.fc22.i686 requires libHShaskeline-0.7.0.3-ghc7.6.3.so
ghc-Agda-2.3.2.2-5.fc22.i686 requires 
ghc(haskeline-0.7.0.3-775b029f16a4b58f3cc6b4cb4f7e7ac5)
ghc-Agda-devel-2.3.2.2-5.fc22.i686 requires 
libHSterminfo-0.3.2.5-ghc7.6.3.so
ghc-Agda-devel-2.3.2.2-5.fc22.i686 requires 
libHShaskeline-0.7.0.3-ghc7.6.3.so
ghc-Agda-devel-2.3.2.2-5.fc22.i686 requires 
ghc-devel(haskeline-0.7.0.3-775b029f16a4b58f3cc6b4cb4f7e7ac5)
ghc-Agda-devel-2.3.2.2-5.fc22.i686 requires 
ghc(terminfo-0.3.2.5-61e0dc43a1465e327dacd9ab37bbe1a3)
ghc-Agda-devel-2.3.2.2-5.fc22.i686 requires 
ghc(haskeline-0.7.0.3-775b029f16a4b58f3cc6b4cb4f7e7ac5)
[PyQuante]
PyQuante-libint-1.6.4-11.fc22.1.i686 requires libint(x86-32) = 
0:1.1.6-2.fc21
[Sprog]
Sprog-0.14-27.fc20.noarch requires perl(:MODULE_COMPAT_5.18.0)
[audtty]
audtty-0.1.12-9.fc20.i686 requires libaudclient.so.2
[authhub]
authhub-0.1.2-3.fc19.i686 requires libjson.so.0
[aws]
aws-devel-3.1.0-6.fc21.i686 requires libgrypt-devel
[blender]
1:blender-2.71-3.fc22.i686 requires libOpenCOLLADAStreamWriter.so.0.1
1:blender-2.71-3.fc22.i686 requires 
libOpenCOLLADASaxFrameworkLoader.so.0.1
1:blender-2.71-3.fc22.i686 requires libOpenCOLLADAFramework.so.0.1
1:blender-2.71-3.fc22.i686 requires libOpenCOLLADABaseUtils.so.0.1
1:blender-2.71-3.fc22.i686 requires libMathMLSolver.so.0.1
1:blender-2.71-3.fc22.i686 requires libGeneratedSaxParser.so.0.1
1:blenderplayer-2.71-3.fc22.i686 requires 
libOpenCOLLADAStreamWriter.so.0.1
1:blenderplayer-2.71-3.fc22.i686 requires 
libOpenCOLLADASaxFrameworkLoader.so.0.1
1:blenderplayer-2.71-3.fc22.i686 requires libOpenCOLLADAFramework.so.0.1
1:blenderplayer-2.71-3.fc22.i686 requires libOpenCOLLADABaseUtils.so.0.1
1:blenderplayer-2.71-3.fc22.i686 requires libMathMLSolver.so.0.1
1:blenderplayer-2.71-3.fc22.i686 requires libGeneratedSaxParser.so.0.1
[cab]
cab-0.1.9-12.fc22.i686 requires cabal-dev
[check-mk]
check-mk-agent-1.2.4p5-1.fc22.i686 requires /usr/bin/ksh
check-mk-multisite-1.2.4p5-1.fc22.noarch requires /usr/bin/ksh
[darcs]
darcs-2.8.4-5.fc22.i686 requires libHSterminfo-0.3.2.5-ghc7.6.3.so
darcs-2.8.4-5.fc22.i686 requires libHShaskeline-0.7.0.3-ghc7.6.3.so
darcs-2.8.4-5.fc22.i686 requires 
ghc(terminfo-0.3.2.5-61e0dc43a1465e327dacd9ab37bbe1a3)
darcs-2.8.4-5.fc22.i686 requires 
ghc(haskeline-0.7.0.3-775b029f16a4b58f3cc6b4cb4f7e7ac5)
ghc-darcs-2.8.4-5.fc22.i686 requires libHSterminfo-0.3.2.5-ghc7.6.3.so
ghc-darcs-2.8.4-5.fc22.i686 requires libHShaskeline-0.7.0.3-ghc7.6.3.so
ghc-darcs-2.8.4-5.fc22.i686 requires 
ghc(terminfo-0.3.2.5-61e0dc43a1465e327dacd9ab37bbe1a3)
ghc-darcs-2.8.4-5.fc22.i686 requires 
ghc(haskeline-0.7.0.3-775b029f16a4b58f3cc6b4cb4f7e7ac5)
ghc-darcs-devel-2.8.4-5.fc22.i686 requires 
ghc-devel(terminfo-0.3.2.5-61e0dc43a1465e327dacd9ab37bbe1a3)
ghc-darcs-devel-2.8.4-5.fc22.i686 requires 
ghc-devel(haskeline-0.7.0.3-775b029f16a4b58f3cc6b4cb4f7e7ac5)
[debconf]
debconf-1.5.53-1.fc22.noarch requires perl(:MODULE_COMPAT_5.18.2)
[deltacloud-core]
deltacloud-core-rackspace-1.1.3-1.fc20.noarch requires 
rubygem(cloudservers)
deltacloud-core-rackspace-1.1.3-1.fc20.noarch requires 
rubygem(cloudfiles)
[django-recaptcha]
django-recaptcha-0.1-7.20091212svn6.fc21.noarch requires python-django14
[dnssec-check]
dnssec-check-1.14.0.1-4.fc20.i686 requires libval-threads.so.14
dnssec-check-1.14.0.1-4.fc20.i686 requires libsres.so.14
[dragonegg]
dragonegg-3.4-0.3.rc0.fc21.i686 requires gcc = 0:4.8.2-14.fc21
[eclipse-rse]
eclipse-rse-3.6.0-2.fc22.noarch requires osgi(org.eclipse.rse.services) 
= 0:3.3.0
[edelib]
edelib-2.1-5.fc22.i686 requires libedelib.so
edelib-devel-2.1-5.fc22.i686 requires libedelib.so
[eucalyptus]
eucalyptus-common-java-3.3.0-0.5.20130408git32052445.fc20.i686 requires 
hibernate3-jbosscache >= 0:3.6.10-7
[fatrat]
1:fatrat-1.2.0-0.21.beta2.fc22.i686 requires libtorrent-rasterbar.so.7
[flush]
flush-0.9.12-10.fc22.i686 requires libtorrent-rasterbar.so.7
[ga]
ga-openmpi-5.3b-9.fc21.i686 requires libmpi_usempi.so.1
[gcc-python-plugin]
gcc-python2-debug-plugin-0.12-18.fc21.i686 requires gcc = 
0:4.8.2-14.fc21
gcc-python2-plugin-0.12-18.fc21.i686 requires gcc = 0:4.8.2-14.fc21
gcc-python3-debug-plugin-0.12-18.fc21.i686 requires 
libpython3.3dm.so.1.0
gcc-python3-debug-plugin-0.12-18.fc21.i686 requires gcc = 
0:4.8.2-14.fc21
gcc-python3-plugin-0.12-18.fc21.i686 requires libpython3.3m.so.1.0
gcc-python3-plugin-0.12-18.fc21.i686 r

Re: [RETRACTION] Re: Unofficial Poll: Flock 2015 (North America) Bids

2014-09-28 Thread Matthew Miller 
On Thu, Sep 25, 2014 at 04:59:45PM -0400, Paul W. Frields wrote:
> Right, I thought the point was the possibility of holding the
> conference slighly *later* if that improves EU folks' ability to
> attend.

Just throwing this out there (not necessarily for this next summer), but I
think _June_ works best with the Fedora release schedule and the original
idea of having Flock as a post-release planning meeting.

This year, the week after Labor Day (Sept. 7th), I have Jury Duty, which I
already postponed from this year due to conflicting with this year's Flock.
So... I have a strong preference for avoiding moving it to that week. :)

-- 
Matthew Miller

Fedora Project Leader
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: [Base] Base Design WG agenda meeting 26 September 2014 15:00 UTC on #fedora-meeting

2014-09-28 Thread Matthew Miller 
On Fri, Sep 26, 2014 at 11:02:47AM -0400, Jaroslav Reznik wrote:
> 
> Matt, any progress on 
> https://fedoraproject.org/wiki/Changes/%28A%29Periodic_Updates_to_Cloud_Images
> Let's try to get it moving a bit, even it's hard when being in the release
> process that takes a lot of energy from everyone involved (and needed for
> this change).

Some. See https://fedorahosted.org/cloud/ticket/51


(Also https://fedorahosted.org/cloud/ticket/43, but that's empty.)


-- 
Matthew Miller

Fedora Project Leader
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Request for testers: glibc update to work around Intel TSX errata microcode_ctl problems.

2014-09-28 Thread Carlos O'Donell 
On 09/26/2014 02:34 PM, Carlos O'Donell wrote:
> Developers.
> 
> Testers wanted immediately for:
> 
> https://admin.fedoraproject.org/updates/glibc-2.18-16.fc20
> 
> and
> 
> https://admin.fedoraproject.org/updates/glibc-2.20-4.fc21

For FC21 was missed a case where TSX was being used and had
to push one more update -5 to cover this case.

I unpushed the -4 update, and pushed the -5 update, and it's
ready for testing.

https://admin.fedoraproject.org/updates/FEDORA-2014-11673/glibc-2.20-5.fc21

Cheers,
Carlos.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: F-21 Branched report: 20140924 changes

2014-09-28 Thread Richard W.M. Jones 
On Sat, Sep 27, 2014 at 09:45:01AM +0200, Till Maas wrote:
> And the e-mail-address for ocamlmaint is not working:
> fedora-ocaml-list at redhat.com

I've been trying to kill off this virtual FAS account.  If it is still
watching any packages, feel free to unwatch it (if some FAS
administrator could just kill -9 ocamlmaint, that'd be great).

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
libguestfs lets you edit virtual machines.  Supports shell scripting,
bindings from many languages.  http://libguestfs.org
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: F-21 Branched report: 20140924 changes

2014-09-28 Thread Richard W.M. Jones 
Thanks for rebuilding those.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-builder quickly builds VMs from scratch
http://libguestfs.org/virt-builder.1.html
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Request for testers: glibc update to work around Intel TSX errata microcode_ctl problems.

2014-09-28 Thread drago01 
On Sun, Sep 28, 2014 at 6:49 PM, Carlos O'Donell  wrote:
> On 09/26/2014 02:34 PM, Carlos O'Donell wrote:
>> Developers.
>>
>> Testers wanted immediately for:
>>
>> https://admin.fedoraproject.org/updates/glibc-2.18-16.fc20
>>
>> and
>>
>> https://admin.fedoraproject.org/updates/glibc-2.20-4.fc21
>
> For FC21 was missed a case where TSX was being used and had
> to push one more update -5 to cover this case.

Does that update still make sense given that the kernel / dracut
update enables early microcode loading?
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Request for testers: glibc update to work around Intel TSX errata microcode_ctl problems.

2014-09-28 Thread Carlos O'Donell 
On 09/28/2014 01:24 PM, drago01 wrote:
> On Sun, Sep 28, 2014 at 6:49 PM, Carlos O'Donell  wrote:
>> On 09/26/2014 02:34 PM, Carlos O'Donell wrote:
>>> Developers.
>>>
>>> Testers wanted immediately for:
>>>
>>> https://admin.fedoraproject.org/updates/glibc-2.18-16.fc20
>>>
>>> and
>>>
>>> https://admin.fedoraproject.org/updates/glibc-2.20-4.fc21
>>
>> For FC21 was missed a case where TSX was being used and had
>> to push one more update -5 to cover this case.
> 
> Does that update still make sense given that the kernel / dracut
> update enables early microcode loading?

What about the case where the user runs a custom kernel?

Cheers,
Carlos.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Request for testers: glibc update to work around Intel TSX errata microcode_ctl problems.

2014-09-28 Thread Reindl Harald 

Am 28.09.2014 um 20:13 schrieb Carlos O'Donell:
> On 09/28/2014 01:24 PM, drago01 wrote:
>> On Sun, Sep 28, 2014 at 6:49 PM, Carlos O'Donell  wrote:
>>> On 09/26/2014 02:34 PM, Carlos O'Donell wrote:
 Developers.

 Testers wanted immediately for:

 https://admin.fedoraproject.org/updates/glibc-2.18-16.fc20

 and

 https://admin.fedoraproject.org/updates/glibc-2.20-4.fc21
>>>
>>> For FC21 was missed a case where TSX was being used and had
>>> to push one more update -5 to cover this case.
>>
>> Does that update still make sense given that the kernel / dracut
>> update enables early microcode loading?
> 
> What about the case where the user runs a custom kernel?

then he needs to build it right

don't get me wrong but you can't seriously disable TSX
completly because a *possible* out-of-distribution kernel



signature.asc
Description: OpenPGP digital signature
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Request for testers: glibc update to work around Intel TSX errata microcode_ctl problems.

2014-09-28 Thread drago01 
On Sun, Sep 28, 2014 at 8:17 PM, Reindl Harald  wrote:
>
> Am 28.09.2014 um 20:13 schrieb Carlos O'Donell:
>> On 09/28/2014 01:24 PM, drago01 wrote:
>>> On Sun, Sep 28, 2014 at 6:49 PM, Carlos O'Donell  wrote:
 On 09/26/2014 02:34 PM, Carlos O'Donell wrote:
> Developers.
>
> Testers wanted immediately for:
>
> https://admin.fedoraproject.org/updates/glibc-2.18-16.fc20
>
> and
>
> https://admin.fedoraproject.org/updates/glibc-2.20-4.fc21

 For FC21 was missed a case where TSX was being used and had
 to push one more update -5 to cover this case.
>>>
>>> Does that update still make sense given that the kernel / dracut
>>> update enables early microcode loading?
>>
>> What about the case where the user runs a custom kernel?
>
> then he needs to build it right
>
> don't get me wrong but you can't seriously disable TSX
> completly because a *possible* out-of-distribution kernel

Well the microcode update *does* disable TSX (so that only applies to
new yet to be introduced cpus) ... but yeah if you build your own
kernel you should try to be as close to possible to the distro config.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Request for testers: glibc update to work around Intel TSX errata microcode_ctl problems.

2014-09-28 Thread Reindl Harald 

Am 28.09.2014 um 21:15 schrieb drago01:
> On Sun, Sep 28, 2014 at 8:17 PM, Reindl Harald  wrote:
>>
>> Am 28.09.2014 um 20:13 schrieb Carlos O'Donell:
>>> On 09/28/2014 01:24 PM, drago01 wrote:
 On Sun, Sep 28, 2014 at 6:49 PM, Carlos O'Donell  wrote:
> On 09/26/2014 02:34 PM, Carlos O'Donell wrote:
>> Developers.
>>
>> Testers wanted immediately for:
>>
>> https://admin.fedoraproject.org/updates/glibc-2.18-16.fc20
>>
>> and
>>
>> https://admin.fedoraproject.org/updates/glibc-2.20-4.fc21
>
> For FC21 was missed a case where TSX was being used and had
> to push one more update -5 to cover this case.

 Does that update still make sense given that the kernel / dracut
 update enables early microcode loading?
>>>
>>> What about the case where the user runs a custom kernel?
>>
>> then he needs to build it right
>>
>> don't get me wrong but you can't seriously disable TSX
>> completly because a *possible* out-of-distribution kernel
> 
> Well the microcode update *does* disable TSX (so that only applies to
> new yet to be introduced cpus) ... 

that's the point of what i said:

* you buy a new CPU in 2 months
* the microcode don't disable TSX there
* if glibc now is built without TSX support you gain nothing from new hardware
* if kernel loads microcode early and you have hardware supporting
  TSX and glibc also supports it -> fine you hav ethe feature

it would be a big mistake to disable completly TSX forever and
if not forever how would someone decide when enable it - the only
sane way is to get microcode applid as early as possible and
after that use the CPU feautures which are enabled

> but yeah if you build your own kernel you should try to be 
> as close to possible to the distro config

exactly what i said



signature.asc
Description: OpenPGP digital signature
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Request for testers: glibc update to work around Intel TSX errata microcode_ctl problems.

2014-09-28 Thread Andrew Lutomirski 
On Sep 28, 2014 12:25 PM, "Reindl Harald"  wrote:
>
>
> Am 28.09.2014 um 21:15 schrieb drago01:
> > On Sun, Sep 28, 2014 at 8:17 PM, Reindl Harald 
wrote:
> >>
> >> Am 28.09.2014 um 20:13 schrieb Carlos O'Donell:
> >>> On 09/28/2014 01:24 PM, drago01 wrote:
>  On Sun, Sep 28, 2014 at 6:49 PM, Carlos O'Donell 
wrote:
> > On 09/26/2014 02:34 PM, Carlos O'Donell wrote:
> >> Developers.
> >>
> >> Testers wanted immediately for:
> >>
> >> https://admin.fedoraproject.org/updates/glibc-2.18-16.fc20
> >>
> >> and
> >>
> >> https://admin.fedoraproject.org/updates/glibc-2.20-4.fc21
> >
> > For FC21 was missed a case where TSX was being used and had
> > to push one more update -5 to cover this case.
> 
>  Does that update still make sense given that the kernel / dracut
>  update enables early microcode loading?
> >>>
> >>> What about the case where the user runs a custom kernel?
> >>
> >> then he needs to build it right
> >>
> >> don't get me wrong but you can't seriously disable TSX
> >> completly because a *possible* out-of-distribution kernel
> >
> > Well the microcode update *does* disable TSX (so that only applies to
> > new yet to be introduced cpus) ...
>
> that's the point of what i said:
>
> * you buy a new CPU in 2 months
> * the microcode don't disable TSX there

What hypothetical CPU is this?  I don't think Broadwell has TSX, so I think
we're talking about Skylake here.

> * if glibc now is built without TSX support you gain nothing from new
hardware
> * if kernel loads microcode early and you have hardware supporting
>   TSX and glibc also supports it -> fine you hav ethe feature
>
> it would be a big mistake to disable completly TSX forever and
> if not forever how would someone decide when enable it - the only
> sane way is to get microcode applid as early as possible and
> after that use the CPU feautures which are enabled
>
> > but yeah if you build your own kernel you should try to be
> > as close to possible to the distro config
>
> exactly what i said
>
>
> --
> devel mailing list
> devel@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/devel
> Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Request for testers: glibc update to work around Intel TSX errata microcode_ctl problems.

2014-09-28 Thread Reindl Harald 

Am 29.09.2014 um 00:21 schrieb Andrew Lutomirski:
> On Sep 28, 2014 12:25 PM, "Reindl Harald"  > wrote:
>>
>> Am 28.09.2014 um 21:15 schrieb drago01:
>> > On Sun, Sep 28, 2014 at 8:17 PM, Reindl Harald > > > wrote:
>> >>
>> >> Am 28.09.2014 um 20:13 schrieb Carlos O'Donell:
>> >>> On 09/28/2014 01:24 PM, drago01 wrote:
>>  On Sun, Sep 28, 2014 at 6:49 PM, Carlos O'Donell >  > wrote:
>>  Does that update still make sense given that the kernel / dracut
>>  update enables early microcode loading?
>> >>>
>> >>> What about the case where the user runs a custom kernel?
>> >>
>> >> then he needs to build it right
>> >>
>> >> don't get me wrong but you can't seriously disable TSX
>> >> completly because a *possible* out-of-distribution kernel
>> >
>> > Well the microcode update *does* disable TSX (so that only applies to
>> > new yet to be introduced cpus) ...
>>
>> that's the point of what i said:
>>
>> * you buy a new CPU in 2 months
>> * the microcode don't disable TSX there
> 
> What hypothetical CPU is this?  I don't think Broadwell has TSX

TSX was introduced with Haswell
otherwise the thread and the microcode to disable it now would not exist

http://www.anandtech.com/show/8376/intel-disables-tsx-instructions-erratum-found-in-haswell-haswelleep-broadwelly

> so I think we're talking about Skylake here

see above - who other than Intel knows if the next Haswell/Broadwell
becomes a new "Step" with fixes and enables TSX again but only for
the newer ones

however - how does that matter?

you can either build all without TSX forever or load microcode
early enough that it is masked controlled by the microcode
before it is used while apply the microcode later disables
the instructions which is the current topic

>> * if glibc now is built without TSX support you gain nothing from new 
>> hardware
>> * if kernel loads microcode early and you have hardware supporting
>>   TSX and glibc also supports it -> fine you hav ethe feature
>>
>> it would be a big mistake to disable completly TSX forever and
>> if not forever how would someone decide when enable it - the only
>> sane way is to get microcode applid as early as possible and
>> after that use the CPU feautures which are enabled
>>
>> > but yeah if you build your own kernel you should try to be
>> > as close to possible to the distro config
>>
>> exactly what i said



signature.asc
Description: OpenPGP digital signature
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Request for testers: glibc update to work around Intel TSX errata microcode_ctl problems.

2014-09-28 Thread Florian Weimer 

On 09/28/2014 09:25 PM, Reindl Harald wrote:

* you buy a new CPU in 2 months
* the microcode don't disable TSX there
* if glibc now is built without TSX support you gain nothing from new hardware


Or the fixed TSX implementation is slightly different, and glibc breaks 
again.  We don't know.  Maybe even Intel doesn't know.


--
Florian Weimer / Red Hat Product Security
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Request for testers: glibc update to work around Intel TSX errata microcode_ctl problems.

2014-09-28 Thread Jakub Jelinek 
On Mon, Sep 29, 2014 at 06:39:01AM +0200, Florian Weimer wrote:
> On 09/28/2014 09:25 PM, Reindl Harald wrote:
> >* you buy a new CPU in 2 months
> >* the microcode don't disable TSX there
> >* if glibc now is built without TSX support you gain nothing from new 
> >hardware
> 
> Or the fixed TSX implementation is slightly different, and glibc breaks
> again.  We don't know.  Maybe even Intel doesn't know.

Furthermore, it is very unlikely to be 2 months, from the info
provided/leaked so far, it seems that Broadwell-E/Broadwell-EP are the
first CPUs to have fixed TSX again, and Haswell-E has only been released
a month ago.  Note, Haswell-E usually seems to have TSX disabled already in
BIOS, so microcode_ctl doesn't do anything regarding TSX there.

Jakub
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct