Re: IntelliJ

[Mikolaj Izdebski]

On 01/20/2015 09:41 PM, Greg Hellings wrote:
> I'm curious about the possibility of bringing IntelliJ/IDEA back into
> Fedora. It was there previously, then was taken out sometime around
> Fedora 15 or thereabouts. Back then the app was at version 9, it's
> currently landed at version 14. With the announcement of Gradle making
> an improved landing in Fedora 22, it might be possible to bring back
> in. I was curious if anyone had a particular feeling strongly one way
> or another, or if there were solid reasons not to resurrect it.
> 
> It looks like it was a behemoth to maintain, so I don't know how
> deeply I want to dive into it (the build involved a large number of
> bundled jars) at this time. I just wanted to put out feelers regarding
> it.

AFAIK IntelliJ was retired because it lacked interested people to
maintain it.  If there is someone (or better, group of people) willing
to maintain, then I don't see a reason why it shouldn't be revived.

There was some interest from a few people to have PyCharm (Python IDE
based on IntelliJ) in Fedora, see [1]. You may want to join forces with
them to make this happen.

People in Java SIG (including myself) are usually quite busy with their
current packages, but you can count on help with package reviews and
solving problems you may encounter.

In any case you may add IntelliJ to Java SIG package wishlist [2] or ask
for volounteers on java-devel mailing list.

[1]
https://lists.fedoraproject.org/pipermail/java-devel/2014-July/005297.html
[2] https://fedoraproject.org/wiki/SIGs/Java#Package_Wishlist

-- 
Mikolaj Izdebski
Software Engineer, Red Hat
IRC: mizdebsk
-- 
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: IntelliJ

[Sudhir Khanger]

On Wednesday, January 21, 2015 05:02:32 AM Reindl Harald wrote:
> since with Java7 OpenJDK is the *official reference implementation* it 
> is somehow pervert having such recommendations at all

We in any case don't support OpenJDK 7 which makes Fedora 21 and onward a 
second class citizen for Android development. OpenJDK 7 vs Oracle JDK 7 is a 
moot point.

IntelliJ 14 fully supports JDK 8 and next preview version of Android Studio 
will be based off IntelliJ 14.

-- 
Regards,
Sudhir Khanger,
sudhirkhanger.com,
github.com/donniezazen,
5577 8CDB A059 085D 1D60  807F 8C00 45D9 F5EF C394.

signature.asc
Description: This is a digitally signed message part.
-- 
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: IntelliJ

[Reindl Harald]

Am 21.01.2015 um 04:59 schrieb Sudhir Khanger:

On Wednesday, January 21, 2015 12:39:56 AM Julien Enselme wrote:

For android studio, the Oracle JDK is more a recommendation. I made some
basic Android development today with Android studio running on the
OpenJDK and Fedora 21 and I experienced no problems at all.


Oracle JDK 7 is the specific requirement for Android Studio. The only caveat
of using OpenJDK with IntelliJ is that upstream won't take bug reports. If
people can live with that I think it is a great idea. Maybe if enough folks
were using IntelliJ with OpenJDK, it might help change their stance on Oracle
JDK requirement


since with Java7 OpenJDK is the *official reference implementation* it 
is somehow pervert having such recommendations at all




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: IntelliJ

[Sudhir Khanger]

On Wednesday, January 21, 2015 12:39:56 AM Julien Enselme wrote:
> For android studio, the Oracle JDK is more a recommendation. I made some
> basic Android development today with Android studio running on the
> OpenJDK and Fedora 21 and I experienced no problems at all.

Oracle JDK 7 is the specific requirement for Android Studio. The only caveat 
of using OpenJDK with IntelliJ is that upstream won't take bug reports. If 
people can live with that I think it is a great idea. Maybe if enough folks 
were using IntelliJ with OpenJDK, it might help change their stance on Oracle 
JDK requirement.

-- 
Regards,
Sudhir Khanger,
sudhirkhanger.com,
github.com/donniezazen,
5577 8CDB A059 085D 1D60  807F 8C00 45D9 F5EF C394.

signature.asc
Description: This is a digitally signed message part.
-- 
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: F22 System Wide Change: Login Screen Over Wayland

[Rahul Sundaram]

Hi

On Tue, Jan 20, 2015 at 7:25 PM, Ian Pilcher  wrote:

> How does this affect users of other display managers (or does it)?
>

It doesn't affect them afaik.

Rahul
-- 
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: Python 3 as a Default - Status

[Haïkel]

Thanks for the heads-up.

As for the cloud image, if we switch to yum, python-urlgrabber won't
be needed anymore.

H.
-- 
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: F22 System Wide Change: Login Screen Over Wayland

[Ian Pilcher]

How does this affect users of other display managers (or does it)?

-- 

Ian Pilcher arequip...@gmail.com
 "I grew up before Mark Zuckerberg invented friendship" 


-- 
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: F22 System Wide Change: Login Screen Over Wayland

[Felix Schwarz]

Am 20.01.2015 um 13:34 schrieb drago01:
> On Tue, Jan 20, 2015 at 1:27 PM, Felix Schwarz
>  wrote:
>> component is currently "gnome-shell" but it seems to be hardware-dependent as
>> it works on r600g.
> 
> Doesn't look like it ... xwayland crashes but the logs in the bug are
> not enough to find out why:
> https://bugzilla.redhat.com/attachment.cgi?id=970564 i.e need the log
> output before that.

Does this help?
https://bugzilla.redhat.com/attachment.cgi?id=982103

If not: What can I do to generate helpful logs? (feel free to leave your
comments in bugzilla so we don't have to hijack this thread)



-- 
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: Boost 1.57.0

[Petr Machata]

The packages with MPICH enabled are here:

http://koji.fedoraproject.org/koji/taskinfo?taskID=8678117
http://ppc.koji.fedoraproject.org/koji/taskinfo?taskID=2283793
http://s390.koji.fedoraproject.org/koji/taskinfo?taskID=1706653
http://arm.koji.fedoraproject.org/koji/taskinfo?taskID=2852781

Thanks,
Petr
-- 
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: IntelliJ

[Julien Enselme]

On 01/20/2015 11:55 PM, Yohan Graterol wrote:
> Hi
> 
> It's a great idea, but IntelliJ (For Android and Java) need as
> requirement Oracle JDK, so, Fedora has OpenJDK. PyCharm, RubyMine and
> Webstorm not need Oracle JDK.
> 
> Regards!
> 
> 
> 
> Enviado con MailTrack
> 
> 
> On Tue, Jan 20, 2015 at 4:58 PM, Julien Enselme  > wrote:
> 
> On 01/20/2015 10:40 PM, Corey Sheldon wrote:
> > intellij/IDEA  has now mostly  been folded into  AndroidStudio which
> > while  not in the default repos can be obtained on the android dev d/l
> > page  for linux as a .zip/tarball
> >
> >
> > Corey W Sheldon
> > Freelance IT Consultant, Multi-Discipline Tutor
> > 310.909.7672 
> > www.facebook.com/1stclassmobileshine
> 
> > 
> >
> >
> >
> >
> >
> > On Tue, Jan 20, 2015 at 4:00 PM, Eric Smith  
> > >> wrote:
> >
> > I think it's a great idea. IntelliJ is the basis for the new Android
> > dev env (though Eclipse can still be used). I looked at trying to
> > package it again, but as you say it looks like a pretty big task.
> >
> >
> > --
> > devel mailing list
> > devel@lists.fedoraproject.org
> 
>  >
> > https://admin.fedoraproject.org/mailman/listinfo/devel
> > Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
> >
> >
> >
> >
> Hi,
> 
> I also think this is a great idea. I just have a question: do you intend
> to package just the Java IDE or do you intend to include plugins for
> other languages like python (the version for python is called Pycharm
> but I guess it has the same code base than the Jave version)?
> 
> BTW: there is a copr repo for Pycharm
> (https://copr.fedoraproject.org/coprs/phracek/PyCharm/). Maybe it can
> help you start.
> 
> Regards,
> Julien Enselme
> --
> devel mailing list
> devel@lists.fedoraproject.org 
> https://admin.fedoraproject.org/mailman/listinfo/devel
> Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
> 
> 
> 
> 
For android studio, the Oracle JDK is more a recommendation. I made some
basic Android development today with Android studio running on the
OpenJDK and Fedora 21 and I experienced no problems at all.

I just got a message saying that some display problems might appear with
the OpenJDK and suggesting to use Oracle JDK instead.

Regards,
Julien Enselme
-- 
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: IntelliJ

[Yohan Graterol]

Hi

It's a great idea, but IntelliJ (For Android and Java) need as requirement
Oracle JDK, so, Fedora has OpenJDK. PyCharm, RubyMine and Webstorm not need
Oracle JDK.

Regards!



Enviado con MailTrack


On Tue, Jan 20, 2015 at 4:58 PM, Julien Enselme  wrote:

> On 01/20/2015 10:40 PM, Corey Sheldon wrote:
> > intellij/IDEA  has now mostly  been folded into  AndroidStudio which
> > while  not in the default repos can be obtained on the android dev d/l
> > page  for linux as a .zip/tarball
> >
> >
> > Corey W Sheldon
> > Freelance IT Consultant, Multi-Discipline Tutor
> > 310.909.7672
> > www.facebook.com/1stclassmobileshine
> > 
> >
> >
> >
> >
> >
> > On Tue, Jan 20, 2015 at 4:00 PM, Eric Smith  > > wrote:
> >
> > I think it's a great idea. IntelliJ is the basis for the new Android
> > dev env (though Eclipse can still be used). I looked at trying to
> > package it again, but as you say it looks like a pretty big task.
> >
> >
> > --
> > devel mailing list
> > devel@lists.fedoraproject.org 
> > https://admin.fedoraproject.org/mailman/listinfo/devel
> > Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
> >
> >
> >
> >
> Hi,
>
> I also think this is a great idea. I just have a question: do you intend
> to package just the Java IDE or do you intend to include plugins for
> other languages like python (the version for python is called Pycharm
> but I guess it has the same code base than the Jave version)?
>
> BTW: there is a copr repo for Pycharm
> (https://copr.fedoraproject.org/coprs/phracek/PyCharm/). Maybe it can
> help you start.
>
> Regards,
> Julien Enselme
> --
> 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: IntelliJ

[Julien Enselme]

On 01/20/2015 10:40 PM, Corey Sheldon wrote:
> intellij/IDEA  has now mostly  been folded into  AndroidStudio which
> while  not in the default repos can be obtained on the android dev d/l
> page  for linux as a .zip/tarball
> 
> 
> Corey W Sheldon
> Freelance IT Consultant, Multi-Discipline Tutor
> 310.909.7672
> www.facebook.com/1stclassmobileshine
> 
> 
> 
> 
> 
> 
> On Tue, Jan 20, 2015 at 4:00 PM, Eric Smith  > wrote:
> 
> I think it's a great idea. IntelliJ is the basis for the new Android
> dev env (though Eclipse can still be used). I looked at trying to
> package it again, but as you say it looks like a pretty big task.
> 
> 
> --
> devel mailing list
> devel@lists.fedoraproject.org 
> https://admin.fedoraproject.org/mailman/listinfo/devel
> Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
> 
> 
> 
> 
Hi,

I also think this is a great idea. I just have a question: do you intend
to package just the Java IDE or do you intend to include plugins for
other languages like python (the version for python is called Pycharm
but I guess it has the same code base than the Jave version)?

BTW: there is a copr repo for Pycharm
(https://copr.fedoraproject.org/coprs/phracek/PyCharm/). Maybe it can
help you start.

Regards,
Julien Enselme
-- 
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: IntelliJ

[Corey Sheldon]

intellij/IDEA  has now mostly  been folded into  AndroidStudio which while
 not in the default repos can be obtained on the android dev d/l page  for
linux as a .zip/tarball


Corey W Sheldon
Freelance IT Consultant, Multi-Discipline Tutor
310.909.7672
www.facebook.com/1stclassmobileshine
-BEGIN PGP PUBLIC KEY BLOCK-
Version: GnuPG v1

mQSuBFSFm3MRDADMQUFvE2zeREEV2+mARfGttXR0HmamD3kJJMdRmGrtvHpEgTjK
cg8ylpkjRTBOl3pWzrEfoxREnS5Ej6BbGbEdGP8cRgpnACkzVirTDtb6JLatzPzh
4xqpuO6st8ATh7/RkLdsK8R5IzjqvkJ+Q99MGZxBr6w0AaP8KMKe32TU5CzQkSMH
hL+sZQlIVa5kiEbsvrYnYVrlvw9YFsHZQ38mxFyg0A4nmt3L+CBFS4LRdaQmsu07
Qr22aeOYdD4fWKkvEtGsy2MtxIOjqljdPk+lBqBiW3qK9J3DfGLQsVBholJFBMvY
S6aLj6ITDOezJ36hHNlpQmPMOQLShIkP3/dlq7Y2xhyLY/hXG83Pw6WF7kRzF7vG
bSqSDlMlmdnRzulnNtAaE4fzNtBR26oKSfMIwX9NUz4U1wFCVrzrOzEvvU2ZvU3k
ZlpyMdm1fCEdXJt/oOWBVa6PH31TTGaYKl8JH2gQ0Z9DixaTmPS56ch3mbRGMqyz
5PzEtzvaM5b3yzMBAN/guLOJVzGKSqHwEMjhfxwDweHiOS50FAXH8i9w8qyVC/sG
4iFlS/yjH6SBm5DEdAKwIbY5EuFexgyVoVDpCZ65VSspDwoiXaHubOfNYUAEkOFJ
o/YShNMInmajsB7kTlt5mlqsJlU/xAMGH6Zv+f5GIi2k8aDryZr+rHPHqs3lyCkb
7t7041z5mfy9/rJE+U20aVvBh/uUtSMm78CvmTcwdasskEpsiZR2ScuGUgc4ahlF
61dvEnCN+5mrTtPUQPISxtLGDUMhhrrw75z7LafPF6gFmMT/RLcnbrB1xPxPwxWR
m5QpfV6qUNmRoGKnGRlyYkBbLwWRsZRSEtgFHUqb8Y3ghG1rKkEh4paFyPOzbGFo
dZOHR4dsTStu41UE1MAdn41VhTjS/mQjI/CQPCIRPscjI64svBjQria3SV0iDqxb
+Z3ACGoHdKaUI5TiJhJkjEWUjOunUfSnhR124mf7uEIG/1sHJoYonPKTtYNy2mlB
ryZs7kZ3u7V3DV4TPMji3UC8sVV2+9HR2g0xxMEXyTA1AEoQeQIK05BthxX/auoM
AKrGRPvY96RfaO9rNSerJGH+7VGpr/O4UxRDytHzRRfDb9PzMjUSspS6DtSMhk1z
lB2+riyDwQ9HqgFk2PLgnj0LE/k9IxXDxtjjMAGAM1iBRJCsQZzoXfphOtZzU1bd
6teOAW2lsT+rp/+BwU7YxSLnEj0eFJgZTMAgNblLLzh3Cu53FNPauxdhacklYjj3
LO3d0CAkcHMA0ny+zXVoQupabgFLsgvVoSLqPqWVgrd5vS8gGWwvc+b4Q9YLWYpK
qwI9tD6Z5poSbQjJPKJLuJfhiQqMgvjeLZGFnTHe9O5s1+dKInW1DhUH6yq61Exj
0grDevF7vyBBEfxkGVeKPyOd7gy7dXMRUwuaQZZ/yd2vbPv8Vbe4ux5TaltFekYc
/F6bPWB2LwGAbxKchl5O9133C4VM6yO9bb0DiMMZFsJIUlIqnkDREgjMA30n2HZ4
Xzg+aho33VMRhzaE+YTZVfmNSZk7VlM4mprFKeBERycOyUNfU0B6hOwtrwrMp6gZ
47Q0Q29yZXkgU2hlbGRvbiAoRmVkb3JhIEtleSkgPHNoZWxkb24uY29yZXlAZ21h
aWwuY29tPoiABBMRCAAoBQJUhZtzAhsjBQkB4TOABgsJCAcDAgYVCAIJCgsEFgID
AQIeAQIXgAAKCRDpWMXWcYv1l0L9APwJ2famE03OlzpOMddQIxsGEnb6cgb4X8ZE
tXNnkfmPZwD9Gt8tXcaLOqiwKjQqyiLRP3SoIqwUAJHe7GciZDZ5A/S5BA0EVIWb
cxAQAK6uQCb9BZLnWUTXZAAKDK0qT2BVOzUBefB3YD5Eixtmdf7mqjxSfs2Mci5D
rGdNZowgA9HnEeIzqg78giit21UlXhqCOt22hj0eO+Q1F401Dr6RFkkN8yQdVI1D
1UePDZQ/zz/fD0miD9KPQxGr6mwGWbn8it5NFHt1EnZMIYkXfS/TJxaMsrGY6Q2F
RLjhQ3f69i0XjqPg1/IFx5C34ds0hw3K47yDTrgqR5pp309FjselYfLkC4z8R6ti
TRbaXMwOhGuk56rEYB7Y6uzdxuQvS1zM/qqqmff3VqjwyCpVgTuqUlpiD8k/e2nq
HB/ZvrOUWgSqT6NKWBn915DlVB5U95jxLFafopI4N12rsEGW7wIgPolXZ2yU8C4S
E5kE84T8ahdHGAP9lHbqPhnA7aO1zuAl6hJB+Dcpt1nbPdqfwWR0FffkUU9kL6Qh
CiV2ZiAx6Eqm8i5pM21aTlYo0RUosK4r0xFTDZ7SR7d7EGjmfO5k+YjoUSlqOvIb
2jNg6+ZD9EFzSEq5QHMViFnMsp1j+nEYiL44GIH4NPnQWCc3/p7vdxje3HTC4eBt
E4Dp4CkTjX4MpiNrUMw57kjahv/nfITsDUcu4WcMc9e0F8GtfIgy/p3XVsXTqdcm
CersMUgFZIbptI/bGwfj713QElkNiah1NGZc52YAmFWO9f4/AAMFD/4mjUWEaW/D
plbV2tyo7w4j9cHT89+uz5R/Q/OOUjY6PhoFfAzfRAiBlOVjGba/IiYig0HJoBW8
r1HDrfO8xHCHCA9NXiBrhCLFnGM+T6m5+5YpMz5jnhv+xvudm0Dg5VxLtcBjo0/j
OUxIHBEcvm0/H3MgABHJc/vTR5n/hNJ6kGRgfgg37qIruE4GOu7BeNABBW+8IIyP
1mXvQl/zIfokAPiDqW9Rmmuj5znOc+UvOX8CcJU/8YQYNIHtCzISkFGtkcz1spET
BL6Bu5WrGbdStHFzoUKpaHQumyaHBBDn0VpJCjiRwf7Gu+LlZ/Wlah4KVo4nhk3k
NsonNqOZjK16UZnrMrdK4VIDLxzCtlrmlmbGLuH8YUmmlxuw0Nt9EiYtpFTiNUQq
Iplu8Me9O9hZ8ZmzlgJ+0tSzlXELOUUOwIgiQs67c9bEn18pHIln4YyrfCvPlhyw
Ke+xXUeGGEXmIrKTjCQrFA9eWs3nPTfTG7xQmGkf93kUZHOJMohDJlpIHQza1uyt
lu2s+s8HXiAHOBh6ZbMloL+Rg4M+w5+eKU2abQCW8QC1v9u3OgKWcZ1jZbYyTCyI
8Y7NQyiE/akAXQiUb1MHIezN7QpzHEpGxDyVr3tEYF26deJ8sVBxzd+m2wSWyFlT
dPyuTxJJFIRCYtK5wpbPhrDlQfwL5riDzIhnBBgRCAAPBQJUhZtzAhsMBQkB4TOA
AAoJEOlYxdZxi/WXW8wA/jWWfofUPZYg3QOquXIR/QDTm/fsQwTx+2vO4nEXRKlq
AP0YOSlkGoCbaeFHgX+RU5lVfHzRyONK5T7RcDTcvJD83A==
=v6Cq
-END PGP PUBLIC KEY BLOCK-





On Tue, Jan 20, 2015 at 4:00 PM, Eric Smith  wrote:

> I think it's a great idea. IntelliJ is the basis for the new Android dev
> env (though Eclipse can still be used). I looked at trying to package it
> again, but as you say it looks like a pretty big task.
>
> --
> 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: IntelliJ

[Eric Smith]

I think it's a great idea. IntelliJ is the basis for the new Android dev
env (though Eclipse can still be used). I looked at trying to package it
again, but as you say it looks like a pretty big task.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

IntelliJ

[Greg Hellings]

I'm curious about the possibility of bringing IntelliJ/IDEA back into
Fedora. It was there previously, then was taken out sometime around
Fedora 15 or thereabouts. Back then the app was at version 9, it's
currently landed at version 14. With the announcement of Gradle making
an improved landing in Fedora 22, it might be possible to bring back
in. I was curious if anyone had a particular feeling strongly one way
or another, or if there were solid reasons not to resurrect it.

It looks like it was a behemoth to maintain, so I don't know how
deeply I want to dive into it (the build involved a large number of
bundled jars) at this time. I just wanted to put out feelers regarding
it.

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

Boost 1.57.0

[Petr Machata]

Your favorite time of the year, and mine as well, is here!

The plan is to do the rebase next week, maybe on the weekend already.
As usual, I'll request a side tag, build boost, and then work through
the dependent packages.  I'll wrap the work on Thursday at the latest
regardless on what state it is in (hopefully most will have been done
by then), as I'll be traveling to FOSDEM on Friday.

If you want to take a fresh-from-the-oven candidate package for a spin,
help yourselves:

http://koji.fedoraproject.org/koji/taskinfo?taskID=8677132
http://arm.koji.fedoraproject.org/koji/taskinfo?taskID=2852665
http://s390.koji.fedoraproject.org/koji/taskinfo?taskID=1706650
http://ppc.koji.fedoraproject.org/koji/taskinfo?taskID=2283587

I just noticed there are no MPICH packages, because I had MPICH support
turned off locally.  I'm spinning a new batch, but if you happen not to
care about MPICH, the above should be just fine.

The sources are here:
https://github.com/pmachata/F22Boost158

I'll squash merge to Fedora just before I build the final package.

Thanks,
Petr
-- 
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: Ruby 2.2 landed in Rawhide

[Jason Rist]

On 01/20/2015 08:01 AM, Vít Ondruch wrote:
> Hi everybody,
>
> Just heads up that Ruby 2.2 landed in Rawhide. We tried to rebuild every
> package which depends on ruby-devel and libruby.so so most of you should
> be fine already. Nevertheless, there are still some packages remaining,
> usually due to other issues then Ruby. Namely, it is (if I have not
> forget anything):
>
> hub
> rubygem-openssl_cms
> subversion
> swig
> uwsgi
> vim
>
> Please let me know if you need any assistance with fixing Ruby related
> build issues of your packages.
>
>
> Thanks
>
>
> Vít
>
Isn't hub Go based now?

-J

-- 
Jason E. Rist
Senior Software Engineer
OpenStack Infrastructure Integration
Red Hat, Inc.
openuc: +1.972.707.6408
mobile: +1.720.256.3933
Freenode: jrist
github/identi.ca: knowncitizen
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

F22 System Wide Change: Atomic Host

[Jaroslav Reznik]

= Proposed System Wide Change: Atomic Host =
https://fedoraproject.org/wiki/Changes/AtomicHost

Change owner(s): Cloud SIG / Joe Brockmeier  and Colin 
Walters 

New Fedora product: Fedora Atomic Host, an implementation of the Project 
Atomic [1] pattern.

This is a continuation and expansion of Changes/Atomic_Cloud_Image [2].

== Detailed Description ==
The original Changes/Atomic_Cloud_Image was a host system delivered just as a 
cloud image. This Change for Fedora 22 expands it to a multitude of delivery 
vehicles:

* Bare metal support via Anaconda
* Cloud providers
** OpenStack/KVM qcow2
** EC2 AMI
** Google Compute Engine 
* Vagrant boxes (OS X and vagrant-libvirt)
* Ultra-minimal LiveOS image designed for PXE booting diskless servers 

== Scope ==
* Proposal owners: Maintain kickstart and tree configuration, integration with 
Anaconda and other tools, maintain packages in Fedora
* Other developers: Unknown.
* Release engineering: Will need to generate trees during the general Fedora 
compose process, and generate install media and cloud image based on trees.
* Policies and guidelines: May need updates for RpmOstree. 

== Contingency Plan ==
* Blocks product? Yes, Atomic Host 

If something fails and this product can't ship, some upgrade mechanism for 
Fedora 21 Atomic Cloud Image users would need to be evaluated. The simplest 
fallback is to tell those users to reinstall with a traditional Fedora 22 
Cloud image. 

[1] http://www.projectatomic.io/
[2] https://fedoraproject.org/wiki/Changes/Atomic_Cloud_Image
___
devel-announce mailing list
devel-annou...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel-announce
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Agenda for Env-and-Stacks WG meeting (2015-01-21)

[Honza Horak]

WG meeting will be at 12:00 UTC (07:00 EST, 13:00 Brno, 7:00 Boston, 
21:00 Tokyo, 22:00 Brisbane) in #fedora-meeting on Freenode.


= Topics =
* Nominations & Elections
* Fedora Rings
  * elaborating ML feedback
* Open Floor

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

F22 System Wide Change: Plasma 5

[Jaroslav Reznik]

= Proposed System Wide Change: Plasma 5 =
https://fedoraproject.org/wiki/Changes/Plasma_5

Change owner(s): KDE SIG & Daniel Vrátil , Lukáš Tinkl 
, Jan Grulich , Rex Dieter 
, Than Ngo , Kevin Kofler 


Plasma 5 is successor to KDE Plasma 4 created by the KDE Community. It is 
based on Qt 5 and KDE Frameworks 5 and brings many changes and improvements 
over previous versions, including new look & feel as well as important changes 
under the hood. 

== Detailed Description ==
Plasma 5 is a new major version of KDE's workspaces. It has a new theme called 
Breeze, which has cleaner visuals and better readability, improves certain 
work-flows and provides overall more consistent and polished interface.

Changes under the hood include switch to Qt 5 and KDE Frameworks 5 and 
migration to fully hardware-accelerated graphics stack based on OpenGL(ES).

Note that Plasma 5 only includes the actual shell, decorations, icons and a 
few applications coupled with workspace (e.g. KWin, System Settings, 
KSysGuard). It does not include "regular" applications like Dolphin, Okular, 
Konqueror, etc. which are part of KDE Applications product and released 
independently of Plasma 5.

Plasma 5 gets a new feature release every three months, and each feature 
release has monthly bugfix releases. Plasma 5.2 is scheduled to be released on 
January 27. KDE SIG intends to ship Plasma 5.2.2 or Plasma 5.3, depending on 
the final schedules. 

== Scope ==
* Proposal owners:
** Submit, review and import new packages for Plasma 5 to rawhide/F22
** Modify existing KDE 4 packages to ensure smooth upgrade path to Plasma 5
** Retire KDE 4 packages not compatible with Plasma 5, or available in Plasma 
5 under different names/components

* Other developers:
Optionally, maintainers of 3rd party KDE Workspace 4 packages such as Plasma 
applets or KCMs may want to consult upstream regarding Qt 5/Frameworks 
versions of their packages, and eventually update them to Frameworks version, 
so that they are available in Plasma 5.

* Release engineering: 
No, this change requires no coordination with rel-eng.

* Policies and guidelines:
No, this change requires no update to packaging guidelines or policies.

== Contingency Plan ==
* Contingency mechanism: Rolling back to KDE 4 and shipping KDE Workspace 
4.11.X. As rawhide would already have packages with version 5.x.y, we would 
have to increase the epoch number of all affected KDE 4 packages, and making 
them Obsolete their Plasma 5 equivalents (since some Plasma 5 packages have 
been renamed or split from larger KDE 4 packages)
* Contingency deadline: Before F22 beta freeze
* Blocks release? No
* Blocks product? No 

___
devel-announce mailing list
devel-annou...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel-announce
-- 
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: [Test-Announce] Urgent F21 testing request: libhif and PackageKit

[Michel Alexandre Salim]

On Tue Jan 20 2015 at 3:20:41 AM Adam Williamson 
wrote:

> It would be great if folks could, as a matter of urgency, test this
> update:
>
> https://admin.fedoraproject.org/updates/PackageKit-1.0.4-1.fc21,libhif-
> 0.1.8-1.fc21
>
> Please install the updated packages, reboot (or at least restart the
> packagekit service), run 'pkcon repair' as root, reboot again, and
> then test regular use of GNOME Software and pkcon as much as possible -
>

pkcon repair shows my database is fine, but I've been using dnf
exclusively. pkcon update works fine (it prompts for confirmation about
installing new packages -- the list of packages tallies with that provided
by dnf), and GNOME Software works fine installing new apps.

Regards,

-- 
Michel Alexandre Salim
-- 
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: F22 Self Contained Change: Database Server Role

[Stephen Gallagher]

On Tue, 2015-01-20 at 10:20 -0500, Miloslav Trmač wrote:
> > == Scope ==
> > * Release engineering:
> > ** Pre-loading roles will need to be a capability of the Anaconda install
> > system, both in the graphical installer and kickstart
> 
> While this functionality is desirable, it seems not to be directly related to 
> the database server.  
> Mirek





Whoops. That was an oversight. I repurposed the deferred Change page
from F21 and forgot to remove that optional piece.


signature.asc
Description: This is a digitally signed message part
-- 
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: Meeting minutes for Env-and-Stacks WG meeting (2015-01-14)

[Bohuslav Kabrda]

- Original Message -

> On 19 January 2015 at 05:08, Bohuslav Kabrda < bkab...@redhat.com > wrote:

> > - Original Message -
> 
> > > Bohuslav Kabrda wrote:
> 
> > > > Please note, that this proposal is absolutely not about imposing some
> 
> > > > restrictions on who can/should maintain what. It's really just a
> 
> > > > categorization of packages based on our WG's perception of importance
> > > > to
> 
> > > > Fedora.
> 
> > >
> 
> > > Sure, but there is still a distinction in that proposal between first-
> 
> > > class/Core (ring 1) and second-class/Extras (ring 2) packages. Even
> > > without
> 
> > > the political/maintainership issues that the old Core/Extras split had,
> 
> > > there were also some technical issues, which this proposal is
> > > reintroducing.
> 
> > > Those stem from the requirement that ring 1 be self-hosting. It means
> > > that
> 
> > > not only everything required to build ring 1 packages must be in ring 1,
> > > but
> 
> > > also everything required to build optional subpackages of ring 1 package
> 
> > > SRPMs! In practice, this means that either, e.g., large portions of
> > > TeXLive
> 
> > > end up in ring 1, or we end up having to disable features, documentation
> 
> > > etc. for several packages, or build them as separate SRPMs (which is
> > > always
> 
> > > painful; we try to avoid that for a reason).
> 

> > I personally don't have a problem with putting large portions of TeXLive
> > into
> > ring 1. Again, I have to repeat that this is only a categorization of a
> > state that currently exists with no intention of changing it (except
> > perhaps
> > suggesting that the ring 0+1 packages get more QE, perhaps in Taskotron).
> 

> > > For those not familiar with the issue from the Fedora Core past, just
> > > have
> > > a
> 
> > > look at EPEL, where the split still exists. We end up with hacks like a
> > > kde-
> 
> > > plasma-nm-extras SRPM that builds some plugins for the kde-plasma-nm
> > > package
> 
> > > in RHEL (those that depend on VPN libraries not in RHEL and thus cannot
> > > be
> 
> > > built in the RHEL package). Such an -extras package then typically needs
> > > to
> 
> > > track the base package exactly, making updates painful (requiring
> 
> > > coordination). (This would be much more of a problem in the fast-moving
> 
> > > Fedora than in RHEL with its extremely conservative update policy.) We
> > > also
> 
> > > end up with RHEL's KDE applications having many optional features simply
> 
> > > disabled (at compile time), with no way to add them (other than replacing
> 
> > > the entire packages with ones built with the optional features enabled
> > > from
> 
> > > a third-party repository, in this case Rex Dieter's kde-redhat).
> 
> > >
> 
> > > IMHO, such a self-hosting "ring 1" is a step backwards, even if the
> 
> > > implementation keeps it open to all Fedora packagers.
> 

> > It's not. I don't see why we would need to do such hacks as are done in
> > EPEL.
> > The way I see it, if kde-plasma-nm builds several binary RPMs, then some of
> > them are on LiveCDs, hence in ring 1, while others are not (=> ring 2). And
> > there's no problem with that. Or is there?
> 

> The issues that come up are if ring0 and ring1 has a different update process
> than ring2. If an SRPM has both in them, then you may not be able to fix
> problems in ring2 because ring0, ring1 would supercede ring2. Thus you end
> up splitting out a lot of packages into sub-rpms to deal with what the
> developer sees as needless bureaucracy but the 'product manager' does not.

Yeah, I meant that either 
a) the process shouldn't be different, at least from maintainers point of view 
- in other words, maintainer would work as he now does, but the package would 
be tested (for example in Taskotron) and bugs would be reported 
or 
b) if at least one binary RPM produced by a SRPM would be in 0 or 1, then all 
others should be there as well (making ring 1 defined by SRPMs, not RPMs) 

Since b) has a potential of significantly expanding ring 1, I'd vote for a). 
But again, that's my perception of this all, I'll make sure to bring this topic 
up on next Env & Stacks meeting, so that others express their opinions as well. 

Slavek 

> --
> Stephen J Smoogen.
-- 
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: F22 Self Contained Change: Database Server Role

[Miloslav Trmač]

> == Scope ==
> * Release engineering:
> ** Pre-loading roles will need to be a capability of the Anaconda install
> system, both in the graphical installer and kickstart

While this functionality is desirable, it seems not to be directly related to 
the database server.  
Mirek
-- 
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: F22 Self Contained Change: Database Server Role

[Jaroslav Reznik]

- Original Message -
> Once upon a time, Stephen Gallagher  said:
> > One of the core focuses of Fedora Server is to simplify things. It's
> > meant to help less-experienced users of Linux get up and running with
> > common activities more quickly. Providing the "PostgreSQL" role and the
> > "MariaDB" role means that we've forced the user to do additional
> > research to figure out what they want. However, if we name one "Database
> > Server", we are implicitly telling the user: "use this one, unless you
> > have a specific need".
> 
> Well, but a user will still have to do that research.  A database isn't
> like a browser or word processor; it doesn't exist in a vacuum and one
> database engine can't just replace another at will.  Some programs
> support a wide variety of database engines, and some don't.  For
> example, for good or bad, many PHP-based things assume MySQL; some can
> be configured otherwise, but most default to MySQL (and that may be all
> the developers actually test).

Maybe this could be a very nice LAMP role. Or in our case FAMP :).

> Database engines are probably one of the least interchangeable pieces,
> so choosing _any_ (I'd say the same thing if this was a proposal to use
> MariaDB) as "THE database engine" is poor IM(very)HO.  It isn't about
> promoting one engine over another, it is just that none are really the
> one engine to rule them all.  Given that, I don't see a reason to
> declare any engine as the one true Database Server.  I think any role
> for a database should have the engine name in the Role.

I understand what you mean but also - if someone is going to deploy 
application that depends on specific DB, it would probably mean own
installation based on app requirements.

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

Ruby 2.2 landed in Rawhide

[Vít Ondruch]

Hi everybody,

Just heads up that Ruby 2.2 landed in Rawhide. We tried to rebuild every
package which depends on ruby-devel and libruby.so so most of you should
be fine already. Nevertheless, there are still some packages remaining,
usually due to other issues then Ruby. Namely, it is (if I have not
forget anything):

hub
rubygem-openssl_cms
subversion
swig
uwsgi
vim

Please let me know if you need any assistance with fixing Ruby related
build issues of your packages.


Thanks


Vít

-- 
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: F22 Self Contained Change: Database Server Role

[Chris Adams]

Once upon a time, Stephen Gallagher  said:
> One of the core focuses of Fedora Server is to simplify things. It's
> meant to help less-experienced users of Linux get up and running with
> common activities more quickly. Providing the "PostgreSQL" role and the
> "MariaDB" role means that we've forced the user to do additional
> research to figure out what they want. However, if we name one "Database
> Server", we are implicitly telling the user: "use this one, unless you
> have a specific need".

Well, but a user will still have to do that research.  A database isn't
like a browser or word processor; it doesn't exist in a vacuum and one
database engine can't just replace another at will.  Some programs
support a wide variety of database engines, and some don't.  For
example, for good or bad, many PHP-based things assume MySQL; some can
be configured otherwise, but most default to MySQL (and that may be all
the developers actually test).

Database engines are probably one of the least interchangeable pieces,
so choosing _any_ (I'd say the same thing if this was a proposal to use
MariaDB) as "THE database engine" is poor IM(very)HO.  It isn't about
promoting one engine over another, it is just that none are really the
one engine to rule them all.  Given that, I don't see a reason to
declare any engine as the one true Database Server.  I think any role
for a database should have the engine name in the Role.

But yeah, that's just my opinion, probably not even worth two cents.
-- 
Chris Adams 
-- 
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: F22 Self Contained Change: Database Server Role

[Reindl Harald]

Am 20.01.2015 um 15:28 schrieb Stephen Gallagher:

On Tue, 2015-01-20 at 08:03 -0600, Chris Adams wrote:

Once upon a time, Jaroslav Reznik  said:

The Fedora Server Product will provide a standard deployment mechanism for a
Linux Database Server (powered by the postgresql project).


How about just calling this the PostgreSQL Server role?  Why should this
get the generic "database" name (what if the MariaDB maintainers want to
make a Database Server as well for example)?  No matter the engine,
users have to know what they are connecting to; there is no generic
"talk to the database server" protocol, so I don't see a reason to try
to make a generic database server role.


The intent is that we plan to offer one "official" Database Server Role
for Fedora Server. By electing to use the generic name, we provide a
subtle indication that this is the one that you should code against. A
MariaDB or MySQL Role is certainly welcome, but by a strong majority
vote in the WG, we picked PostgreSQL as the technology that Fedora
Server will be backing directly. Thus, it gets to have the generic name.

One of the core focuses of Fedora Server is to simplify things. It's
meant to help less-experienced users of Linux get up and running with
common activities more quickly. Providing the "PostgreSQL" role and the
"MariaDB" role means that we've forced the user to do additional
research to figure out what they want. However, if we name one "Database
Server", we are implicitly telling the user: "use this one, unless you
have a specific need"


you think you do "less-experienced" users a favor with postgresql?

the hundrets of MySQL databases i am responsible for are mostly origined 
in MySQL 3.x times, moved from Windows over OSX to Linux and seamless 
upgraded up to MariaDB 10 with any dump/restore


postgresql is not *that* easy to handle hence i gave even up my 
playground for it long ago




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

F22 Self Contained Change: Minglish - New input method for Marathi Language

[Jaroslav Reznik]

= Proposed Self Contained Change: Minglish - New input method for Marathi 
Language =
https://fedoraproject.org/wiki/Changes/minglish

Change owner(s): anish 

New input method for Marathi language users. 

== Detailed Description ==
Minglish input method is to type Marathi using Latin alpha-bates.However there 
are existing mim layouts are available though each layout has few problems. 
e.g to type word "anish" in Marathi using phonetic input method one has to 
type sequence as "FniS" while with itrans input method one has to type 
"anisha". In given example user often expects "अनिश" to be appear with 
keystrokes "anish". In India, people who have familiar with English language 
tend to type Marathi letters upon English letter pronunciation, that is why we 
have new term http://en.wikipedia.org/wiki/Hinglish. 

== Scope ==
* Proposal owner: Initial plan is to send this patch to upstream and otherwise 
patch it into Fedora 

* Other developers: N/A (not a System Wide Change) 
* Release engineering: N/A (not a System Wide Change) 
* Policies and guidelines: N/A (not a System Wide Change) 
___
devel-announce mailing list
devel-annou...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel-announce
-- 
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: smuxi builds stalled

[Antonio Trande]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 01/20/2015 12:21 AM, Jeff Peeler wrote:
> On Wed, Jan 07, 2015 at 02:41:25PM -0700, Kevin Fenzi wrote:
>> On Wed, 07 Jan 2015 13:59:29 +0100 Antonio Trande
>>  wrote:
>> 
>>> -BEGIN PGP SIGNED MESSAGE- Hash: SHA1
>>> 
>>> Hi all.
>>> 
>>> Rawhide smuxi builds seem blocked on Koji; this is my third
>>> attempt: 
>>> http://koji.fedoraproject.org/koji/taskinfo?taskID=8541548
>>> 
>>> No errors, but stopped. This is SPEC that generates Smuxi's
>>> RPMs: 
>>> http://pkgs.fedoraproject.org/cgit/smuxi.git/tree/smuxi.spec
>> 
>> This might be this (or related to this) mono problem:
>> 
>> https://bugzilla.redhat.com/show_bug.cgi?id=1128499
> 
> Was it ever determined that the above bug was responsible for the 
> failing smuxi builds?

No, unfortunately.

I keep checking for it to hit f21, but it looks
> like the build has been re-attempted around six times so far (only
> way I know to check is to see that the finished date keeps getting
> updated):
> 
> http://koji.fedoraproject.org/koji/packageinfo?packageID=19723

I don't know what's the real problem. Just tried to build on F21 some
times.

- -- 
Antonio Trande

mailto: sagitter 'at' fedoraproject 'dot' org
http://fedoraos.wordpress.com/
https://fedoraproject.org/wiki/User:Sagitter
GPG Key: 0x66E15D00
Check on https://keys.fedoraproject.org/
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBAgAGBQJUvmaIAAoJEFyovWBm4V0A4REP/3aSdBrqrDb05Nppw7KnS6gF
yeW00veOnriPAomFl3HtB08TssKO0t1GJUnKbS1b9SThh493w3xh32JVIqRnuWU6
KLEHgJSfeNPRSMCyR+QvjG8aqtAzMt2G5ZTEI6OGq8WI6ByZOKaWM6Cb9coBmLut
c5K/BS6INO9NEQ2Wf8mBCE3nwVv4F0L2LHyYRhM7iY4WprvXHCLdXjQawj4z7kZE
fGGJsuTHqg1EgEmrCW9bJu08KyVSUGyI18yGByLxOHr2cQqX4xbKSyNduNPD8LBx
zw7NClGN1cyHPI4crVlGsbnk3KJLUSv4MVFizKzO6366vkGCiIhstCRANHD8zWoS
e981+XeVQc8osJ7uPvAoIYuuVtMWPlbBJzL67cZ0HOGVo6HEP+37FqTK7LeLyUWt
iYa5WdXPBw4UweuuIezmst/eAj7oR77EUt3U335b1zUJ5dEYLb2JHi61XbruG9cG
GXbAOtcFXYa9P/59qyVB2+s8hv0T+OKNvgGAnkAr/Huc5lA78uTMu6fqQTOsKbni
TvMDQRNwNHmV7+/217pcmwqy9Uzrh+Y8YGoSsr1RUipNDmHcsyqK4ZShGkhNMQzN
HYn2TpYtzxOlhTQBVj8YAK+t9pq4ZQcyDE1whjQmjoqjmrhoUpHlwioA4anSCEUE
FzZVDPX/TTCpzbSlpq6G
=cfIT
-END PGP 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: F22 Self Contained Change: Database Server Role

[Stephen Gallagher]

On Tue, 2015-01-20 at 08:03 -0600, Chris Adams wrote:
> Once upon a time, Jaroslav Reznik  said:
> > The Fedora Server Product will provide a standard deployment mechanism for 
> > a 
> > Linux Database Server (powered by the postgresql project). 
> 
> How about just calling this the PostgreSQL Server role?  Why should this
> get the generic "database" name (what if the MariaDB maintainers want to
> make a Database Server as well for example)?  No matter the engine,
> users have to know what they are connecting to; there is no generic
> "talk to the database server" protocol, so I don't see a reason to try
> to make a generic database server role.


The intent is that we plan to offer one "official" Database Server Role
for Fedora Server. By electing to use the generic name, we provide a
subtle indication that this is the one that you should code against. A
MariaDB or MySQL Role is certainly welcome, but by a strong majority
vote in the WG, we picked PostgreSQL as the technology that Fedora
Server will be backing directly. Thus, it gets to have the generic name.

One of the core focuses of Fedora Server is to simplify things. It's
meant to help less-experienced users of Linux get up and running with
common activities more quickly. Providing the "PostgreSQL" role and the
"MariaDB" role means that we've forced the user to do additional
research to figure out what they want. However, if we name one "Database
Server", we are implicitly telling the user: "use this one, unless you
have a specific need".

Yes, this amounts to "picking a winner". This is done in the name of
simplification, both in the choices that the inexperienced user has to
make and in the level of resources needed to support things. (If people
tend to use this database more often than the others, then it becomes
easier to maintain and build up a useful knowledge base).

I'll repeat, so I'm clear: If the SIGs around MariaDB, MySQL, MongoDB
and others would like to create a Server Role, they are welcome to do so
(and I will quite happily review those patches for inclusion!).


signature.asc
Description: This is a digitally signed message part
-- 
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: F22 Self Contained Change: Database Server Role

[Chris Adams]

Once upon a time, Jaroslav Reznik  said:
> The Fedora Server Product will provide a standard deployment mechanism for a 
> Linux Database Server (powered by the postgresql project). 

How about just calling this the PostgreSQL Server role?  Why should this
get the generic "database" name (what if the MariaDB maintainers want to
make a Database Server as well for example)?  No matter the engine,
users have to know what they are connecting to; there is no generic
"talk to the database server" protocol, so I don't see a reason to try
to make a generic database server role.

-- 
Chris Adams 
-- 
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: TBB rebase

[Petr Machata]

Dodji Seketeli  writes:

> Petr Machata  a écrit:
>
>> The soname didn't change.  I reviewed the actual changes using abidiff,
>> and the only thing reported that I think is an actual ABI violation is
>> insertion of one virtual method.  I don't think that's real however:
>>
>>  https://sourceware.org/bugzilla/show_bug.cgi?id=17861
>
> Indeed, the reported insertion of the virtual method is a false positive
> resulting from a bug in abidiff.  I have committed a change to abidiff
> that should fix that issue now.

Great!

> And I confirm that the other abi
> changes reported by abidiff do not represent ABI-incompatible changes.

Cool, thanks for confirmation.

Petr
-- 
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: F22 System Wide Change: RpmOstree - Server side composes and atomic upgrades

[Colin Walters]

On Tue, Jan 20, 2015, at 06:27 AM, Jan Zelený wrote:

> You are probably right, I might have misunderstood what you actually propose. 
> Does it mean that you actually don't require this part to be implemented at 
> all and you can go with what's in /var without any distribution-wide changes? 

Fedora 21 Atomic does work with a current F21 packageset.  For example Docker 
stores
state in /var/lib/docker, and no changes were required to the docker RPM or or 
rpm-ostree
for this.

(Although an aside, Fedora 21 Atomic also stores docker images in a LVM volume
 which means they would need special factory reset handling if the feature was
 implemented)

> In other words, do you propose this change to be gradually implemented where 
> it makes sense?

Right, on demand.  If there's a Fedora RPM that doesn't work with this scheme
and is desirable to use by a 3rd party or by the Fedora Atomic subproject, we'd
engage with the RPM maintainer to figure out a solution.

> Thank you for the additional explanation. Now I think that the problem is not 
> in what you want but in possibly ambiguous specification. What I'm afraid of 
> is 
> that some people will use this opportunity to push through fully transient 
> /var.

There's a commit to OSTree which does make fully transient /var happen out of
the box if the underlying / is read-only:
https://git.gnome.org/browse/ostree/commit/?id=ff6883ca0655ac8844cd783caf6a7d8815515ba3

Which is pretty nice for some use cases, but definitely not the default =)

At a high level, I do agree this part of the change needs analysis, and
I'm glad you brought it up.  In the end I think the risk here is going to 
vary a lot per package.

For example, I need to look closely at the alternatives system.

But I certainly don't want to break the traditional install model - among other 
things, it's
going to be a while before rpm-ostree would be a usable way to run my desktop,
and also packages need to be backportable to older branches, etc.



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

systemd in F21 breaks namespaces for units

[Reindl Harald]

https://bugzilla.redhat.com/show_bug.cgi?id=1184016

most, if not all of my systemd-units on a dozen of servers using 
constructs like below to make the whole tree /var/lib readonly and the 
needed subfolder RW which is now broken in Fedora 21 and kills all my setups


that is a *major regression* because this affects a lot of customized, 
non-packaged systemd units all over the place



ReadOnlyDirectories=/var/lib
ReadWriteDirectories=/var/lib/mysql

150120 13:44:01 [ERROR] Can't start server : Bind on unix socket: 
Read-only file system
150120 13:44:01 [ERROR] Do you already have another mysqld server 
running on socket: /var/lib/mysql/mysqld_dbmail.sock ?




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

Python 3 as a Default - Status

[Bohuslav Kabrda]

Hi all,
since the "Python 3 as a Default" change [1] has been accepted a while ago and 
is scheduled for F22, I'd like to share with you the status.

The proposed change [1] mentions several goals that should be reached to 
pronounce python3 the "default":
1) DNF is the default package manager instead of Yum, which only works with 
Python 2
2) Python 3 is the only Python implementation in the minimal buildroot
3) Python 3 is the only Python implementation on the LiveCD
4) Anaconda and all of its dependencies run on Python 3
5) cloud-init and all of its dependencies run on Python 3

Before I go through the 5 goals, let me explain the approach that has been 
taken so far:
There are basically two types of packages (from Fedora's point of view) that 
depend on Python: "libraries" and "applications" (note that the distinction is 
intentionally not very clear, there are packages that are both)
"Libraries" are, simply put, Python extension modules, those that live in 
%{python2_sitelib} and %{python2_sitearch} in python2 builds. "Libraries" were 
receiving both upstream and downstream care from the people working on the 
change - upstream porting and downstream python3- subpackage additions, to also 
put files in %{python3_sitelib} and %{python3_sitearch}. We could afford to do 
the subpackage additions downstream during F21 lifecycle, since this doesn't 
change anything, it's just one more binary RPM that's spit out of the SRPM 
build process.
"Applications" are stuff that users run (an important characteristic is that 
users don't care under which Python the application runs) - like Anaconda. 
"Applications" have been receiving some upstream patches, but weren't rebuilt 
with Python 3 yet. The reason for not rebuilding yet is that we first wanted to 
make sure that we've ported all "applications" upstream to be able to switch 
them all to Python 3 in Fedora at once - we wanted to be sure we wouldn't 
introduce both Python runtimes to livemedia, cloudimages, etc. As of now, 
Python 2 is still the suggested Python runtime to build "applications" against. 
We will start filing bugs to rebuild against Python 3 once we're sure that the 
switch can safely happen (which I think is now according to the points below).

Let's go through the 5 goals:
1) DNF will be the default package manager for F22 [2], so everything is ok 
here.
2) One of our goals was to not make minimal buildroot larger. The only package 
from minimal buildroot requiring python (python-libs to be precise) is gdb, 
which is compatible with python3 in upstream (but it's considered to be an 
"application", so it hasn't been rebuilt yet). So minimal buildroot is fine.
3) As for LiveCD, we now have more of these - Workstation, Server and all the 
various flavours and spins. Let me go through Workstation and Server:
Workstation:
Fedora LiveCDs have, since at least Fedora 20, included both Python 2 and 
Python 3 runtimes (the primary reason for having Python 3 back then was AFAICS 
speech-dispatcher, which is Python 3 only in upstream). Although we may not be 
able to port all libraries and applications (but we may, there's still chance!) 
from workstation livecd to Python 3, the fact that it already ships both 
runtimes makes me think that we should build as much apps as possible with 
Python 3.
Server:
Because of giants like samba and freeipa, I think we won't be able to achieve 
python2-free server livecd for F22. But as it is with Workstation, I think we 
should proceed and build as much with Python 3 as possible.
4) Anaconda is work in progress. I'm communicating with Anaconda devs quite 
regularly and everything looks promising.
5) cloud-init is a problem. Basically, Python 3 cloud-init is the only thing 
blocking the cloud images (*). Other packages are ready or being worked on. The 
problem here is that cloud-init upstream is really unresponsive about Python 3 
porting (patch is submitted in their bug tracker [3]) - if someone knows these 
people, please help us by pinging them.

Attached to this mail, you'll find 3 files (fedora-cloud-base.txt, 
fedora-install-server.txt, fedora-live-workstation.txt). Each one of them is a 
result of automated script that tells with quite a good certainty what Python 
dependent packages are on a livecd/image generated by a kickstart with the same 
name.
The files have two sections: "Good" and "Bad". "Good" packages are either 
"libraries" that have python3- subpackage or "applications" that have already 
been built with Python 3. "Bad" packages are either "libraries" not having 
python3- subpackage or "applications" built with Python 2. Note that lots of 
applications are now "bad" even though their code is Python 3 compatible, they 
just haven't been built with Python 3 yet. Also, "Bad" contains packages that 
will not be ported at all and will disappear from livecd, e.g. pyliblzma or yum.
We're tracking all packages needed for Workstation and Cloud images at [4] - 
feel free to grab anything unassigned there or h

Re: F22 System Wide Change: Login Screen Over Wayland

[drago01]

On Tue, Jan 20, 2015 at 1:27 PM, Felix Schwarz
 wrote:
>
> Am 20.01.2015 um 13:16 schrieb drago01:
>> On Tue, Jan 20, 2015 at 1:07 PM, Felix Schwarz
>>  wrote:
>>> Is there any plan to force an X-based login session? For example on my old
>>> Intel (gen4) laptop I can not open a wayland session in F21 (I'm taken back 
>>> to
>>> the login screen immediately).
>>
>> This ought to work so please file a bug.
>
> another user already took care of that: see bug 1175708
>
> component is currently "gnome-shell" but it seems to be hardware-dependent as
> it works on r600g.

Doesn't look like it ... xwayland crashes but the logs in the bug are
not enough to find out why:
https://bugzilla.redhat.com/attachment.cgi?id=970564 i.e need the log
output before that.
-- 
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: F22 System Wide Change: Enable Polyinstantiated /tmp and /var/tmp directories by default

[Tom Hughes]

On 20/01/15 12:16, Tomas Hozza wrote:

On 01/20/2015 01:08 PM, Tom Hughes wrote:

On 20/01/15 11:53, Jaroslav Reznik wrote:


* Other developers:
** Add /tmp-inst and /var/tmp/tmp-inst to filesystem. (packagename: filesystem)
** Enable namespaces in /etc/security/namespace.conf (packagename: PAM)
** Enable proper selinux context and polyinstantiation_enabled boolean to be
set (packagename: selinux-policy-targeted or selinux-policy)


So this effectively reverses tmp-on-tmpfs for users other than root and adm
right? Because /tmp will actually be a subdirectory of /tmp-inst which will be a
real directory?


Why do you think this? I don't see any reason why the new tmp-inst directories 
can
not be on tmpfs...


I guess that will work as well, but it wasn't clear that was the 
intention since it talked of adding them to the filesystem package.


I suppose technically the directories still exist in filesystem but 
currently it is systemd that then overmounts them with tmpfs instances.


Tom

--
Tom Hughes (t...@compton.nu)
http://compton.nu/
--
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: F22 System Wide Change: Enable Polyinstantiated /tmp and /var/tmp directories by default

[Lennart Poettering]

On Tue, 20.01.15 12:53, Jaroslav Reznik (jrez...@redhat.com) wrote:

> = Proposed System Wide Change: Enable Polyinstantiated /tmp and /var/tmp 
> directories by default =
> https://fedoraproject.org/wiki/Changes/Polyinstantiated_tmp_by_Default
> 
> Change owner(s): Huzaifa Sidhpurwala 
> 
> Polyinstantiation of temperary directories is a pro-active security measure, 
> which reduced chances of attacks caused due to the /tmp and /var/tmp 
> directories being world-writable. These include flaws caused by predictive 
> temp. file names, race conditions due to symbolic links etc. 
> 
> == Detailed Description ==
> The basic idea is to provide better security to Fedora installs. Though 
> Polyinstantiated /tmp has worked since Fedora 19, its not a single step 
> process to configure it. Secondly people don't really understand its 
> benefits. 
> Because of this having it on by default makes more sense. It is completely 
> transparent to the user, they wont even realize that it has been enabled.
> 
> The Red Hat Product Security Team assigns CWE ids to severe flaws (CVSSv2 > 
> 7). 
> Here is a list of severe flaws caused by insecure tmp files [1].
> 
> == Scope ==
> * Proposal owners: No work required to be done by proposal owner.
> 
> * Other developers:
> ** Add /tmp-inst and /var/tmp/tmp-inst to filesystem. (packagename: 
> filesystem)
> ** Enable namespaces in /etc/security/namespace.conf (packagename: PAM)
> ** Enable proper selinux context and polyinstantiation_enabled boolean to be 
> set (packagename: selinux-policy-targeted or selinux-policy)

Well, /tmp is used by X11 among other for IPC across user
boundaries. If you give each other their private instance of it, they
cannot use this for communication anymore. You are breaking X11 this
way.

Moreover, if you want to give each user a private instance of /tmp you
have to run that user in a private mount namespace and disable
propagation from that namespace into the host for the / directory for
this. (After all the /tmp over-mounting shall be private to the user,
and not propagate to the rest of the system.)  This of course means
that if the user later-on invokes /bin/mount or /bin/umount on any
subdir of / the commands have will have zero effect for the rest of
the system. You pretty much brek mounting/umounting for normal
users. If you do this, pretty much every admin will hate you deeply.

Also, introducing "/tmp-inst" sounds really wrong to me, what's the
point of that? systemd's PrivateTmp= works by mounting /tmp over with
a subdir of /tmp, so that things stay on the same file system. Why
introduce a new directory?

How do you intend for the new /tmp instance to be life-cycled? When is
the private /tmp instance removed? On logout? Tracking a user
session's lifecycle is not easy, as the user might have processes
running that are not attached to any session, and you shouldn't remove
the private /tmp before those processes are dead too.

To me this sounds very much not thought to the end. 

We thought a couple of times in adding an option for this to
systemd/logind, after all, we have the namespacing code in systemd
anyway, and we can at least track the sessions through logind very
precisely. However, X11 and the mount propagation breakage are real
blockers to make this useful in the general case.

This idea can only fly for very special systems where the propagation
is irrelevant. It's not compatible with admin workflows, at all.

Lennart

-- 
Lennart Poettering, Red Hat
-- 
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: F22 System Wide Change: Login Screen Over Wayland

[Felix Schwarz]

Am 20.01.2015 um 13:16 schrieb drago01:
> On Tue, Jan 20, 2015 at 1:07 PM, Felix Schwarz
>  wrote:
>> Is there any plan to force an X-based login session? For example on my old
>> Intel (gen4) laptop I can not open a wayland session in F21 (I'm taken back 
>> to
>> the login screen immediately).
> 
> This ought to work so please file a bug.

another user already took care of that: see bug 1175708

component is currently "gnome-shell" but it seems to be hardware-dependent as
it works on r600g.

Felix



-- 
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: F22 System Wide Change: Enable Polyinstantiated /tmp and /var/tmp directories by default

[Tomas Hozza]

On 01/20/2015 01:08 PM, Tom Hughes wrote:
> On 20/01/15 11:53, Jaroslav Reznik wrote:
>
> > * Other developers:
> > ** Add /tmp-inst and /var/tmp/tmp-inst to filesystem. (packagename: 
> > filesystem)
> > ** Enable namespaces in /etc/security/namespace.conf (packagename: PAM)
> > ** Enable proper selinux context and polyinstantiation_enabled boolean to be
> > set (packagename: selinux-policy-targeted or selinux-policy)
>
> So this effectively reverses tmp-on-tmpfs for users other than root and adm
> right? Because /tmp will actually be a subdirectory of /tmp-inst which will 
> be a
> real directory?
>
Why do you think this? I don't see any reason why the new tmp-inst directories 
can
not be on tmpfs...
> Incidentally, why /tmp-inst but /var/tmp/tmp-inst? Why not /tmp/tmp-inst for
> /tmp or /var/tmp-inst for /var/tmp? Shouldn't the naming be consistent?
>
> Tom
>
Regards,
-- 
Tomas Hozza
Software Engineer - EMEA ENG Developer Experience

PGP: 1D9F3C2D
Red Hat Inc. http://cz.redhat.com
-- 
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: F22 System Wide Change: Login Screen Over Wayland

[drago01]

On Tue, Jan 20, 2015 at 1:07 PM, Felix Schwarz
 wrote:
>
>
> Am 20.01.2015 um 12:32 schrieb Jaroslav Reznik:
>> ** Come up with some answer for proprietary Nvidia driver users, since that
>> stack doesn't yet support Wayland.  One idea is to force the login session to
>> use software-based mesa if the proprietary Nvidia driver is detected.
>
> Is there any plan to force an X-based login session? For example on my old
> Intel (gen4) laptop I can not open a wayland session in F21 (I'm taken back to
> the login screen immediately).

This ought to work so please file a bug.
-- 
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: F22 System Wide Change: Enable Polyinstantiated /tmp and /var/tmp directories by default

[Tom Hughes]

On 20/01/15 11:53, Jaroslav Reznik wrote:


* Other developers:
** Add /tmp-inst and /var/tmp/tmp-inst to filesystem. (packagename: filesystem)
** Enable namespaces in /etc/security/namespace.conf (packagename: PAM)
** Enable proper selinux context and polyinstantiation_enabled boolean to be
set (packagename: selinux-policy-targeted or selinux-policy)


So this effectively reverses tmp-on-tmpfs for users other than root and 
adm right? Because /tmp will actually be a subdirectory of /tmp-inst 
which will be a real directory?


Incidentally, why /tmp-inst but /var/tmp/tmp-inst? Why not /tmp/tmp-inst 
for /tmp or /var/tmp-inst for /var/tmp? Shouldn't the naming be consistent?


Tom

--
Tom Hughes (t...@compton.nu)
http://compton.nu/
--
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: F22 System Wide Change: Login Screen Over Wayland

[Felix Schwarz]

Am 20.01.2015 um 12:32 schrieb Jaroslav Reznik:
> ** Come up with some answer for proprietary Nvidia driver users, since that 
> stack doesn't yet support Wayland.  One idea is to force the login session to 
> use software-based mesa if the proprietary Nvidia driver is detected.

Is there any plan to force an X-based login session? For example on my old
Intel (gen4) laptop I can not open a wayland session in F21 (I'm taken back to
the login screen immediately).

So I'd be interested in a "X fallback" for the login screen (even if this
needs to be enabled manually).

Felix


-- 
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: F22 System Wide Change: Enable Polyinstantiated /tmp and /var/tmp directories by default

[Jóhann B. Guðmundsson]

On 01/20/2015 11:53 AM, Jaroslav Reznik wrote:

= Proposed System Wide Change: Enable Polyinstantiated /tmp and /var/tmp
directories by default =
https://fedoraproject.org/wiki/Changes/Polyinstantiated_tmp_by_Default

Change owner(s): Huzaifa Sidhpurwala 

Polyinstantiation of temperary directories is a pro-active security measure,
which reduced chances of attacks caused due to the /tmp and /var/tmp
directories being world-writable. These include flaws caused by predictive
temp. file names, race conditions due to symbolic links etc.

== Detailed Description ==
The basic idea is to provide better security to Fedora installs. Though
Polyinstantiated /tmp has worked since Fedora 19, its not a single step
process to configure it. Secondly people don't really understand its benefits.
Because of this having it on by default makes more sense. It is completely
transparent to the user, they wont even realize that it has been enabled.

The Red Hat Product Security Team assigns CWE ids to severe flaws (CVSSv2 > 7).
Here is a list of severe flaws caused by insecure tmp files [1].

== Scope ==
* Proposal owners: No work required to be done by proposal owner.

* Other developers:
** Add /tmp-inst and /var/tmp/tmp-inst to filesystem. (packagename: filesystem)
** Enable namespaces in /etc/security/namespace.conf (packagename: PAM)
** Enable proper selinux context and polyinstantiation_enabled boolean to be
set (packagename: selinux-policy-targeted or selinux-policy)

* Release engineering: N/A
* Policies and guidelines: N/A

== Contingency Plan ==
* Contingency mechanism: Poly tmp can be rolled back quite easily, by using
the previous versions of packages which provides the old directory structures
and old versions of the configuration files (poly tmp is just configuration and 
a
few new directories). In releases earlier gnome-shell had issues with poly
tmp, which now seems to be resolved. In any case, by Beta deadline if any
blockers exists, we can easily remove this feature, by tagging previous
versions of the affected packages, before the final spin.

* Contingency deadline: Beta freeze
* Blocks release? No

[1] http://red.ht/1EkZ1gT
__


Assuming this wont collide with existing setup systemd provides, what 
benefits does this provide over systemds /tmp /var/tmp setup and 
PrivateTmp?


JBG
--
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: TBB rebase

[Dodji Seketeli]

Petr Machata  a écrit:

> The soname didn't change.  I reviewed the actual changes using abidiff,
> and the only thing reported that I think is an actual ABI violation is
> insertion of one virtual method.  I don't think that's real however:
>
>   https://sourceware.org/bugzilla/show_bug.cgi?id=17861

Indeed, the reported insertion of the virtual method is a false positive
resulting from a bug in abidiff.  I have committed a change to abidiff
that should fix that issue now.  And I confirm that the other abi
changes reported by abidiff do not represent ABI-incompatible changes.

> So the current plan is to simply update TBB and not even bump and
> rebuild clients,

Assuming abidiff hasn't forgotten to report any ABI-incompatible change,
this should work, yes.

> but if you could take your packages for a spin with the
> scratch builds, and report back, that would be great.

Good plan.

Cheers.

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

F22 System Wide Change: Enable Polyinstantiated /tmp and /var/tmp directories by default

[Jaroslav Reznik]

= Proposed System Wide Change: Enable Polyinstantiated /tmp and /var/tmp 
directories by default =
https://fedoraproject.org/wiki/Changes/Polyinstantiated_tmp_by_Default

Change owner(s): Huzaifa Sidhpurwala 

Polyinstantiation of temperary directories is a pro-active security measure, 
which reduced chances of attacks caused due to the /tmp and /var/tmp 
directories being world-writable. These include flaws caused by predictive 
temp. file names, race conditions due to symbolic links etc. 

== Detailed Description ==
The basic idea is to provide better security to Fedora installs. Though 
Polyinstantiated /tmp has worked since Fedora 19, its not a single step 
process to configure it. Secondly people don't really understand its benefits. 
Because of this having it on by default makes more sense. It is completely 
transparent to the user, they wont even realize that it has been enabled.

The Red Hat Product Security Team assigns CWE ids to severe flaws (CVSSv2 > 7). 
Here is a list of severe flaws caused by insecure tmp files [1].

== Scope ==
* Proposal owners: No work required to be done by proposal owner.

* Other developers:
** Add /tmp-inst and /var/tmp/tmp-inst to filesystem. (packagename: filesystem)
** Enable namespaces in /etc/security/namespace.conf (packagename: PAM)
** Enable proper selinux context and polyinstantiation_enabled boolean to be 
set (packagename: selinux-policy-targeted or selinux-policy)

* Release engineering: N/A
* Policies and guidelines: N/A

== Contingency Plan ==
* Contingency mechanism: Poly tmp can be rolled back quite easily, by using 
the previous versions of packages which provides the old directory structures 
and old versions of the configuration files (poly tmp is just configuration and 
a 
few new directories). In releases earlier gnome-shell had issues with poly 
tmp, which now seems to be resolved. In any case, by Beta deadline if any 
blockers exists, we can easily remove this feature, by tagging previous 
versions of the affected packages, before the final spin.

* Contingency deadline: Beta freeze
* Blocks release? No 

[1] http://red.ht/1EkZ1gT
___
devel-announce mailing list
devel-annou...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel-announce
-- 
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: F22 System Wide Change: Login Screen Over Wayland

[drago01]

On Tue, Jan 20, 2015 at 12:32 PM, Jaroslav Reznik  wrote:
> = Proposed System Wide Change: Login Screen Over Wayland =
> https://fedoraproject.org/wiki/Changes/Login_Screen_Over_Wayland
>
> Change owner(s): Ray Strode 
>
> Change the Login screen that GDM uses to run on Wayland instead of X.
>
> == Detailed Description ==
> At the moment, a user can choose to log in to a Wayland session from the login
> screen, but the login screen itself always runs on top of X. The point of this
> change is to change that, and make the login screen always run on a Wayland
> session.
>
> == Scope ==
> * Proposal owners: The main things that need be accomplished are:
> ** Change GDM to not start an X server at startup, instead run the login
> screen in Wayland mode
> ** Change X based user sessions to run on their own VT, since they can no
> longer piggyback off the login screen VT
> ** Come up with some answer for proprietary Nvidia driver users, since that
> stack doesn't yet support Wayland.  One idea is to force the login session to
> use software-based mesa if the proprietary Nvidia driver is detected.

I don't think this part is as simple that. For a wayland session to
work we need a working gbm and for that some kind of drm driver ...
for that we could use simpledrm (if it ever got upstream) but not sure
whether it can run when the nvidia driver is loaded. I can't test that
anymore because my nvidia card is dead  the other idea would be
"fall back to X" but not sure how much work that would be.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

F22 System Wide Change: Login Screen Over Wayland

[Jaroslav Reznik]

= Proposed System Wide Change: Login Screen Over Wayland =
https://fedoraproject.org/wiki/Changes/Login_Screen_Over_Wayland

Change owner(s): Ray Strode 

Change the Login screen that GDM uses to run on Wayland instead of X.

== Detailed Description ==
At the moment, a user can choose to log in to a Wayland session from the login 
screen, but the login screen itself always runs on top of X. The point of this 
change is to change that, and make the login screen always run on a Wayland 
session. 

== Scope ==
* Proposal owners: The main things that need be accomplished are:
** Change GDM to not start an X server at startup, instead run the login 
screen in Wayland mode
** Change X based user sessions to run on their own VT, since they can no 
longer piggyback off the login screen VT
** Come up with some answer for proprietary Nvidia driver users, since that 
stack doesn't yet support Wayland.  One idea is to force the login session to 
use software-based mesa if the proprietary Nvidia driver is detected.

* Other developers: We may need to get the mesa maintainer involved as part of 
a proprietary Nvidia driver handling, but also might not need to pending 
investigation.

* Release engineering: This change doesn't affect release workflow
* Policies and guidelines: This change doesn't affect packaging guidelines

== Contingency Plan ==
* Contingency mechanism: Revert to existing mechanism of login screen on Xorg
* Contingency deadline: Beta Freeze
* Blocks release? No
* Blocks product? No
___
devel-announce mailing list
devel-annou...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel-announce
-- 
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: F22 System Wide Change: RpmOstree - Server side composes and atomic upgrades

[Jan Zelený]

On 19. 1. 2015 at 11:30:22, Colin Walters wrote:
> On Mon, Jan 19, 2015, at 07:02 AM, Jan Zelený wrote:
> > I have hard time figuring out what exactly is the purpose of including the
> > factory reset feature in your proposal. No offense but unless I'm missing
> > something, it seems to me that you are trying to solve some of ostree
> > problems in the rest of the distribution rather than in ostree itself.
> 
> I wouldn't say ostree problems exactly.  I certainly could change ostree
> to write to /var.  But I think the benefits of it not doing so are worth the
> change in terms of getting a much cleaner separation between what's owned
> by the OS and what's user data.
> 
> > I think this part of the proposed change has implications as severe as
> > those the infamous UsrMove had. And from what I can remember, some of us
> > spent another two releases fixing that up.
> 
> Yep, I too made changes for UsrMove.
> 
> > In this particular case, I foresee
> > problems with all databases (they store data in /var) and web servers
> > (/var/www). For me personally the most immediate blocker is the rpm stack
> > which stores its data in /var on multiple different levels.
> 
> Storing data in /var is fine!
> 
> > Even if we consider
> > something as unimportant as metadata cache, re-downloading it because of
> > transient /var is not something our users will be happy about.
> 
> Hmm, there may be confusion on this, which is understandable because
> documentation is very thin.  This isn't about making /var transient
> by default.  In the default OSTree model it's fully persistent.  It *can*
> be optionally transient, or reset explicitly.

You are probably right, I might have misunderstood what you actually propose. 
Does it mean that you actually don't require this part to be implemented at 
all and you can go with what's in /var without any distribution-wide changes? 
In other words, do you propose this change to be gradually implemented where 
it makes sense?

> > All in all, I'm rather against this part of the proposal. In my opinion,
> > ostree should take /var as it is now instead of re-designing it.
> 
> Does the above help to address your concerns?

Yes, it does. Thank you

> >  If there is a
> > 
> > strong demand for the factory reset feature, it should be proposed,
> > decided
> > and implemented separately.
> 
> Fair enough, again to be clear this is only partly about factory reset; it's
> also about making upgrades more reliable by having it be clear who owns
> data and when it's modified, which is why the ostree model uses it.

Thank you for the additional explanation. Now I think that the problem is not 
in what you want but in possibly ambiguous specification. What I'm afraid of is 
that some people will use this opportunity to push through fully transient 
/var.

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

F22 Self Contained Change: Gradle 2.x

[Jaroslav Reznik]

= Proposed Self Contained Change: Gradle 2.x =
https://fedoraproject.org/wiki/Changes/Gradle

Change owner(s): Mikolaj Izdebski 

This change aims at making latest version of Gradle available in Fedora and 
making it possible to easily build Fedora packages using Gradle. 

== Detailed Description ==
Gradle [1] is a popular Java build automation tool, which can automate 
building, testing, publishing, deployment and more of software packages or 
other types of projects such as generated static websites, generated 
documentation or indeed anything else.

This change brings latest upstream version of Gradle to Fedora, which enables 
Fedora users to use Gradle to work with software projects.

This change also implements integration with software used for Java packaging 
in Fedora (XMvn and Javapackages), which makes it possible to use standard 
Fedora pagkaging techniques to build RPM packages with Gradle with all 
features, such as automatic artifact installation or auto-requires/provides. 

== Scope ==
* Proposal owners:
** Package latest Gradle 2.x
** Implement local Gradle resolver so that RPM packages can be built with 
Gradle
** Update Java Packaging HOWTO to include information about Gradle packaging

* Other developers:
** Maintainers of packages not built with Gradle and which upstreams are using 
Gradle as build system can optionally update their packages to be built with 
Gradle, but that's not absolutely required as existing ways of building Java 
packages will continue to work.

* Release engineering: N/A

* Policies and guidelines: N/A

[1] http://gradle.org/
___
devel-announce mailing list
devel-annou...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel-announce
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

F22 System Wide Change: Glibc Unicode 7.0

[Jaroslav Reznik]

= Proposed System Wide Change: Glibc Unicode 7.0 =
https://fedoraproject.org/wiki/Changes/Glibc_Unicode_7

Change owner(s):  Mike Fabian , Pravin Satpute 
, Siddhesh Poyarekar

We are updating Glibc Unicode data from Unicode 5.1 to Unicode 7.0 version. It 
took long time since there was not much documentation on how to update Unicode 
data and also there was chance of loosing backward compatibility. Most of the 
issues are resolved now and patches are ready for inclusion. This update adds 
around 8000 number of character support in Glibc and also correcting the 
Unicode data of many characters as per latest Unicode standard. 

== Detailed Description ==
In this update we are planning to update Glibc's the Unicode locale data - 
character map and LC_CTYPE information to Unicode 7.0 version. This data is 
used almost in all locales and going to affect all applications using these 
locales. It is system wide change since it impacting glibc and application 
dependent on it. Glibc provides two files for Unicode data, UTF-8 and i18n. 
UTF-8 file provides information about CHARMAP and WIDTH for Unicode characters. 
i18n file provides CTYPE (uppercase, lowercase, punct etc.) information for all 
Unicode characters. It has been long time this is not updated due to 
incomplete documentation and also possible chances of loosing backward 
compatibility. Work has been started on this 5-6 months back and now most of 
the issues are resolved.

Respective bugs in upstream for more information.

* Update locale data to Unicode 7.0.0 [1]
* Update UTF-8 charmap and width to Unicode 7.0.0 [2]

Github repo for scripts. [3]

== Scope ==
* Proposal owners:
1. Writing scripts for generating UTF-8 and i18n files from Unicode character 
database.
2. Preparing patch for UTF-8 and i18n files.
3. Preparing backward compatibility report.
4. Applying patches to Fedora.
5. Testing whether does it breaks anything around.

* Other developers: This change impacting glibc and all applications that 
using locales. Other Developers do not need to do any changes from there end 
but they need to watch how there application behave with improved localedata. 
We need proper testing to see it does not break any application.

* Release engineering: No work required from Release engineering.

* Policies and guidelines: No, this change does not required any updates to 
Policies or packaging guideline updates.

== Contingency Plan ==
* Contingency mechanism: Will drop patches from Glibc build.
* Contingency deadline: Before F22 Beta release eg. Beta freeze.
* Blocks release? No
* Blocks product? product No 

[1] https://sourceware.org/bugzilla/show_bug.cgi?id=14094
[2] https://sourceware.org/bugzilla/show_bug.cgi?id=17588
[3] https://github.com/pravins/lohit
___
devel-announce mailing list
devel-annou...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel-announce
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

F22 Self Contained Change: Dnf Langpack Plugin

[Jaroslav Reznik]

= Proposed Self Contained Change: Dnf Langpack Plugin =
https://fedoraproject.org/wiki/Changes/DnfLangpacksPlugin

Change owner(s): Parag Nemade 

A dnf plugin that allows langpacks to be installed/removed for the given 
languages using its commands. 

== Detailed Description ==
This is similar to what we have yum langpacks plugin which is already a 
Features/YumLangpackPlugin [1] in Fedora but there is one missing thing that 
this plugin currently does not provide automatic installation of langpacks 
which is under development [2]. Therefore I am proposing this as basic 
langpacks plugin that provides all the required commands for langpacks only.

== Scope ==
* Proposal owners: implement langpacks plugin
* Other developers: N/A (not a System Wide Change) 
* Release engineering: N/A (not a System Wide Change) 
* Policies and guidelines: N/A (not a System Wide Change) 

[1] https://fedoraproject.org/wiki/Features/YumLangpackPlugin
[2] https://bugzilla.redhat.com/show_bug.cgi?id=1114422
___
devel-announce mailing list
devel-annou...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel-announce
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

F22 System Wide Change: Django 1.8

[Jaroslav Reznik]

= Proposed System Wide Change: Django 1.8 =
https://fedoraproject.org/wiki/Changes/Django18

Change owner(s): Matthias Runge 

Update python-django to version 1.8. 

== Detailed Description ==
Update python-django to version 1.8. Fedora 21 contains version 1.6, which 
will become deprecated by upstream, once Django-1.8 is out. This is a change, 
impacting many of python-django-* packages.

Django upstream is transparent and announces deprecation far in advance. 

== Scope ==
* Proposal owners: 
** update python-django to version 1.8. To support maintainers of dependent 
packages, a copr repo containing latest Django-1.8 is here: [1]
** A build containing latest Django will be pushed to f22 branch late in dev 
cycle. If we decide not to push Django-1.8, nothing will be broken.
** Django 1.8 final release is expected around April 1st, 2015: [2] 

* Other developers: update dependent packages to work with Django-1.8
* Release engineering: N/A 
* Policies and guidelines: N/A

== Contingency Plan ==
* Contingency mechanism: If we can not make it, we'll keep Django-1.7 from 
rawhide.
* Contingency deadline: Fedora 22 Beta release.
* Blocks release? No 
* Blocks product? doesn't block a product.

[1] https://copr.fedoraproject.org/coprs/mrunge/django-1.8/ 
[2] https://code.djangoproject.com/wiki/Version1.8Roadmap#schedule
___
devel-announce mailing list
devel-annou...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel-announce
-- 
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: TBB rebase

[Marcin Juszkiewicz]

W dniu 19.01.2015 o 23:55, Dan Horák pisze:

> oh, nice, TBB isn't x86-only anymore? Did I miss something? :-)

They added "generic" support which can be used for any architecture.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

F22 Self Contained Change: Database Server Role

[Jaroslav Reznik]

= Proposed Self Contained Change: Database Server Role =
https://fedoraproject.org/wiki/Changes/DatabaseServerRole

Change owner(s): Stephen Gallagher , Kevin Fenzi 
 and Truong Anh Tuan  and Server WG 


The Fedora Server Product will provide a standard deployment mechanism for a 
Linux Database Server (powered by the postgresql project). 

== Detailed Description ==
The Fedora Server Product will be shipped with a role-deployment mechanism. 
One such role will be to act as a primary or replica Database Server for the 
Linux machines in the network.

This will be implemented by taking advantage of the postgresql project, 
packaging it up within the Server Role Framework and enabling it to be 
deployed through the mechanisms described in the Framework for Server Role 
Deployment Change Proposal.

Note that this role is a secondary target of the Server Working group. 

== Scope ==
* Proposal owners:
** Postgresql server and related tools need to be packaged appropriately for 
use with the Server Role Infrastructure.
** A D-BUS API plugin needs to be written and tested to support deployment and 
monitoring of the Database server.

* Other developers:
** None

* Release engineering:
** Pre-loading roles will need to be a capability of the Anaconda install 
system, both in the graphical installer and kickstart

* Policies and guidelines:
** Packaging guidelines for this Change should be inherited from the Framework 
for Server Role Deployment Change Proposal.

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

F22 Self Contained Change: Domain Controller Set Up Through Cockpit

[Jaroslav Reznik]

= Proposed Self Contained Change: Domain Controller Set Up Through Cockpit =
https://fedoraproject.org/wiki/Changes/CockpitDomainController

Change owner(s): Stephen Gallagher  

With Fedora 21, the rolekit project now provides a public D-BUS interface for 
creating a Domain Controller based on the FreeIPA project. This Change will 
track adding this capability to the Cockpit management console of Fedora 
Server. 

== Detailed Description ==
Providing users with a simple graphical user interface to set up a FreeIPA 
Domain Controller will provide a fast way to bootstrap an enterprise-grade 
Linux environment. Once the Domain Controller is made available, it becomes 
easy to manage single-sign-on between systems (and Cockpit instances), control 
user authentication and authorization centrally and manage DNS entries (among 
other things). 

== Scope ==
* Proposal owners: The Cockpit user experience needs to be written and added 
to that upstream project. It needs to be connected to the local rolekit 
daemon.

* Other developers: N/A (not a System Wide Change)
* Release engineering: N/A (not a System Wide Change)
* Policies and guidelines: N/A (not a System Wide Change)
___
devel-announce mailing list
devel-annou...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel-announce
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct