wxPython 3.0 in Rawhide

[Scott Talbert]

All,

As discussed in [1], I've updated the wxPython package into Rawhide to 
wxPython 3.0.  I'll start working on testing all of the dependent 
packages.  If any maintainers of dependent packages can test their 
packages, that would be helpful too.  Please let me know the status, or 
update the changes wiki page.


Thanks,
Scott

[1] https://fedoraproject.org/wiki/Changes/wxPython3
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

gcc and re-initialization of dynamic libraries?

[Dave Johansen]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60731
https://bugzilla.redhat.com/show_bug.cgi?id=1083292

I know that this isn't directly related to Fedora, but I was wondering if
anyone had any recommendations on how to proceed with this. clang and icpc
generate code that has the correct behavior (or at least what I believe is
the correct behavior), but because of some flags that are set by gcc it
doesn't re-initialize the dynamic library as expected. Any
ideas/suggestions?

Thanks,
Dave
-- 
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: GCC5

[Peter Robinson]

On Wed, Jan 14, 2015 at 5:51 PM, Miloslav Trmač  wrote:
>> * Contingency mechanism: Revert to older gcc, mass rebuild everything again
>> * Contingency deadline: Before release
>
> This is an invasive contingency mechanism, requiring retesting a lot of 
> functionality; the contingency deadline for this (i.e. when we need to be 
> comfortable that the revert will not be needed, should certainly be at the 
> usual beta freeze at the latest, if not earlier.  Invoking this contingency 
> mechanism “before release”, say during the GA RC phase, would really not be 
> feasible without a massive slip.

Any revert of this would mean another mass rebuild similar to what was
needed in F-21 which will guarantee a slip of probably two weeks, late
in the beta phase this becomes more of an issue. 18K packages do take
some time to rebuild, tag etc.

Peter
-- 
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: Remove gcc, gcc-c++ and make from minimal build root

[Susi Lehtola]

On 01/14/2015 04:38 AM, Vít Ondruch wrote:

And it seems that this is the number of packages written in C++:

$ repoquery --disablerepo=* --enablerepo=rawhide --source --whatrequires
'libstdc++.so.6*' | sort -u | sed -r 's/(.*)-.*-.*/\1/' | uniq | wc -l
2396

I'd like to point out at this place, that this would help also the 5006
packages written in C, since they don't need C++ to build. Only 14.8 %
of packages, which happens to be written in C++, would not benefit from
this change.


Instead of dropping make, gcc, and gcc-c++ from the minimal build root, 
would it make sense just to drop gcc-c++? That would only affect a small 
minority of packages, while eliminating some amount of additional 
packages in the buildroot.

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

Re: GUI applications writing garbage to stdout/stderr

[Reindl Harald]

Am 15.01.2015 um 00:36 schrieb Zbigniew Jędrzejewski-Szmek:

the real problem with that crap messages is that if you are about
writing a longer command line and the in background mode started GUI
app decides to blow out it's helpful messages they appear unasked in
the middle of your input and so the only thing you can do is CTRL+C
and hope the next try don't get interrupted again

^L should work


which clears also the screen - bad if the input you make depends on the 
output of previous commands, the same if your foreground terminal app is 
producing output intended for copy&paste into a mail after finish


a application has *no* valid reason to spit debug output left and right 
unasked, and as said proven by deprecation warnings over years even the 
upstream developers don't read them - so why annoy endusers




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: GUI applications writing garbage to stdout/stderr

[Zbigniew Jędrzejewski-Szmek]

On Thu, Jan 15, 2015 at 12:35:02AM +0100, Reindl Harald wrote:
> 
> Am 15.01.2015 um 00:29 schrieb Alexander Ploumistos:
> >On Thu, Jan 15, 2015 at 1:16 AM, Björn Persson  >> wrote:
> >
> >If they don't have such a build-time option, then what I'm saying is
> >that if one were to suppress the messages, then one should do it with a
> >run-time option, not a build-time option. Then no different build would
> >be needed and debugging would be easy.
> >
> >No argument from me there. I just hate it when things start dying and
> >leave you clueless (without as much as a -v option). And let's not
> >forget that a special debug build may not suffer from the same issues as
> >the "regular" one. It has happened to me on occasion.
> >Perhaps over the years I've grown accustomed to the gibberish in my
> >terminal and started considering it normal, instead of buggy, as Reindl
> >Harald points out
> 
> the real problem with that crap messages is that if you are about
> writing a longer command line and the in background mode started GUI
> app decides to blow out it's helpful messages they appear unasked in
> the middle of your input and so the only thing you can do is CTRL+C
> and hope the next try don't get interrupted again
^L should work.

Zbyszek
-- 
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: GUI applications writing garbage to stdout/stderr

[Reindl Harald]

Am 15.01.2015 um 00:29 schrieb Alexander Ploumistos:

On Thu, Jan 15, 2015 at 1:16 AM, Björn Persson mailto:Bjorn@rombobjörn.se>> wrote:

If they don't have such a build-time option, then what I'm saying is
that if one were to suppress the messages, then one should do it with a
run-time option, not a build-time option. Then no different build would
be needed and debugging would be easy.

No argument from me there. I just hate it when things start dying and
leave you clueless (without as much as a -v option). And let's not
forget that a special debug build may not suffer from the same issues as
the "regular" one. It has happened to me on occasion.
Perhaps over the years I've grown accustomed to the gibberish in my
terminal and started considering it normal, instead of buggy, as Reindl
Harald points out


the real problem with that crap messages is that if you are about 
writing a longer command line and the in background mode started GUI app 
decides to blow out it's helpful messages they appear unasked in the 
middle of your input and so the only thing you can do is CTRL+C and hope 
the next try don't get interrupted again




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: GUI applications writing garbage to stdout/stderr

[Alexander Ploumistos]

On Thu, Jan 15, 2015 at 1:16 AM, Björn Persson  wrote:

> If they don't have such a build-time option, then what I'm saying is
> that if one were to suppress the messages, then one should do it with a
> run-time option, not a build-time option. Then no different build would
> be needed and debugging would be easy.
>

No argument from me there. I just hate it when things start dying and leave
you clueless (without as much as a -v option). And let's not forget that a
special debug build may not suffer from the same issues as the "regular"
one. It has happened to me on occasion.
Perhaps over the years I've grown accustomed to the gibberish in my
terminal and started considering it normal, instead of buggy, as Reindl
Harald points out.
-- 
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: GUI applications writing garbage to stdout/stderr

[Reindl Harald]

Am 15.01.2015 um 00:13 schrieb Reindl Harald:

Am 14.01.2015 um 23:36 schrieb Alexander Ploumistos:

On Thu, Jan 15, 2015 at 12:09 AM, Björn Persson wrote:

Alexander Ploumistos wrote:
>On the other hand, if every message that was not meant for the user
>were suppressed, it would be very difficult to troubleshoot such a
>program, should an actual bug come along, because you would need a
>different build to get useful output in the console or a logging
>service.

Nah, it takes only a command line parameter to turn on debug
logging. An
environment variable could also be used. A different build isn't
needed.
It's no harder to make logging conditional at run time than it is to
make it conditional at build time.

The programs mentioned above do not have a debugging or verbosity flag,
like e.g. "nmap -dd"


then they are broken and instead that the developer spits full my
terminal started a remote X11 appplication because i touch something in
that window he better would include such a switch defaulting to off

start "kate" (kde app) in a remote SSH session like below

"udisks2" is masked? so what - i know that
hence there is a entry in rsyslog to shut up

that crap appears everytime you successful open a file


and BTW messages like "Connecting to deprecated signal 
QDBusConnectionInterface::serviceOwnerChanged(QString,QString,QString)" 
which appears for many years now prove that it is *completly useless* 
and even the developers of the application itself don't care


otherwise such warning would go away over time

the same for broken desktop-files and what not reported again and again 
in that context and nobody cares about - so why annoy the ordinary user 
with that debug informations all day long?





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: GUI applications writing garbage to stdout/stderr

[Björn Persson]

Alexander Ploumistos wrote:
>On Thu, Jan 15, 2015 at 12:09 AM, Björn Persson 
>wrote:
>
>> Alexander Ploumistos wrote:
>> >On the other hand, if every message that was not meant for the user
>> >were suppressed, it would be very difficult to troubleshoot such a
>> >program, should an actual bug come along, because you would need a
>> >different build to get useful output in the console or a logging
>> >service.
>>
>> Nah, it takes only a command line parameter to turn on debug
>> logging. An environment variable could also be used. A different
>> build isn't needed. It's no harder to make logging conditional at
>> run time than it is to make it conditional at build time.
>
>The programs mentioned above do not have a debugging or verbosity flag,
>like e.g. "nmap -dd".

Do they have a build-time option to make the "different build" you
mentioned? If so, then that's the reason why they would be difficult to
troubleshoot if the messages were suppressed. The developers could
easily have made Marcel happy, and at the same time kept the programs
easy to debug, simply by making it a run-time option instead of a
build-time option.

If they don't have such a build-time option, then what I'm saying is
that if one were to suppress the messages, then one should do it with a
run-time option, not a build-time option. Then no different build would
be needed and debugging would be easy.

-- 
Björn Persson


pgpDpsssop0Og.pgp
Description: OpenPGP digital signatur
-- 
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: GUI applications writing garbage to stdout/stderr

[Reindl Harald]

Am 14.01.2015 um 23:36 schrieb Alexander Ploumistos:

On Thu, Jan 15, 2015 at 12:09 AM, Björn Persson wrote:

Alexander Ploumistos wrote:
>On the other hand, if every message that was not meant for the user
>were suppressed, it would be very difficult to troubleshoot such a
>program, should an actual bug come along, because you would need a
>different build to get useful output in the console or a logging
>service.

Nah, it takes only a command line parameter to turn on debug logging. An
environment variable could also be used. A different build isn't needed.
It's no harder to make logging conditional at run time than it is to
make it conditional at build time.

The programs mentioned above do not have a debugging or verbosity flag,
like e.g. "nmap -dd"


then they are broken and instead that the developer spits full my 
terminal started a remote X11 appplication because i touch something in 
that window he better would include such a switch defaulting to off


start "kate" (kde app) in a remote SSH session like below

"udisks2" is masked? so what - i know that
hence there is a entry in rsyslog to shut up

that crap appears everytime you successful open a file


Connecting to deprecated signal 
QDBusConnectionInterface::serviceOwnerChanged(QString,QString,QString)

kbuildsycoca4 running...
Object::connect: No such signal QDBusAbstractInterface::DeviceAdded(QString)
Object::connect: No such signal 
QDBusAbstractInterface::DeviceRemoved(QString)
Object::connect: No such signal 
QDBusAbstractInterface::DeviceAdded(QDBusObjectPath)
Object::connect: No such signal 
QDBusAbstractInterface::DeviceRemoved(QDBusObjectPath)

Failed enumerating UDisks2 objects: "org.freedesktop.systemd1.Masked"
 "Unit udisks2.service is masked."
Failed enumerating UDisks2 objects: "org.freedesktop.systemd1.Masked"
 "Unit udisks2.service is masked."
Failed enumerating UDisks2 objects: "org.freedesktop.systemd1.Masked"
 "Unit udisks2.service is masked."
Failed enumerating UDisks2 objects: "org.freedesktop.systemd1.Masked"
 "Unit udisks2.service is masked."
Failed enumerating UDisks2 objects: "org.freedesktop.systemd1.Masked"
 "Unit udisks2.service is masked."
Failed enumerating UDisks2 objects: "org.freedesktop.systemd1.Masked"
 "Unit udisks2.service is masked."
Failed enumerating UDisks2 objects: "org.freedesktop.systemd1.Masked"
 "Unit udisks2.service is masked."
Failed enumerating UDisks2 objects: "org.freedesktop.systemd1.Masked"
 "Unit udisks2.service is masked."
Object::connect: No such signal QDBusAbstractInterface::DeviceAdded(QString)
Object::connect: No such signal 
QDBusAbstractInterface::DeviceRemoved(QString)
Object::connect: No such signal 
QDBusAbstractInterface::DeviceAdded(QDBusObjectPath)
Object::connect: No such signal 
QDBusAbstractInterface::DeviceRemoved(QDBusObjectPath)

Failed enumerating UDisks2 objects: "org.freedesktop.systemd1.Masked"
 "Unit udisks2.service is masked."
Failed enumerating UDisks2 objects: "org.freedesktop.systemd1.Masked"
 "Unit udisks2.service is masked."



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: GUI applications writing garbage to stdout/stderr

[Zbigniew Jędrzejewski-Szmek]

On Thu, Jan 15, 2015 at 12:36:27AM +0200, Alexander Ploumistos wrote:
> On Thu, Jan 15, 2015 at 12:09 AM, Björn Persson  wrote:
> 
> > Alexander Ploumistos wrote:
> > >On the other hand, if every message that was not meant for the user
> > >were suppressed, it would be very difficult to troubleshoot such a
> > >program, should an actual bug come along, because you would need a
> > >different build to get useful output in the console or a logging
> > >service.
> >
> > Nah, it takes only a command line parameter to turn on debug logging. An
> > environment variable could also be used. A different build isn't needed.
> > It's no harder to make logging conditional at run time than it is to
> > make it conditional at build time.
> >
> 
> The programs mentioned above do not have a debugging or verbosity flag,
> like e.g. "nmap -dd". The output can help pinpoint anything from minor
> aesthetic glitches, like a missing gtk theme, to crashes at startup. And
> that is a lot faster than querying the environment or running debuggers.
According to this logic, any program should spout maximum possible information,
because it might be useful. The reality is different — only some users debug
those issues some of the time. They can easily flip a switch or set an
environment variable when they want to use debug output. For the majority
of users useless output annoys and makes it harder to find relevant things
or use the tools from the command line.

Zbyszek
-- 
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: Split DNS broken again - test case?

[Dan Williams]

On Wed, 2015-01-14 at 14:29 -0600, Ian Pilcher wrote:
> https://bugzilla.redhat.com/show_bug.cgi?id=1161232
> 
> It seems like this is the 3rd or 4th time that this functionality has
> been broken, leaving anyone who needs to simultaneously connect to both
> VPN and other non-public (e.g. home network) resources up a creek.
> 
> Would this be worth of a test case?

It seems that the issue never actually got fixed, so it was always
broken.  Patches have been submitted upstream (to the bug linked from
rhbz#1161232) which will be backported to F21's 0.9.10 and submitted as
an update soon.

Dan

-- 
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: Koji build root caching

[Dennis Gilmore]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Wed, 14 Jan 2015 16:40:35 +0100
Vít Ondruch  wrote:

> 
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
> 
> Dne 14.1.2015 v 16:00 Dennis Gilmore napsal(a):
> > On Wed, 14 Jan 2015 14:57:59 +0100
> > Miroslav Suchý  wrote:
> >
> > > On 01/13/2015 06:01 PM, Dennis Gilmore wrote:
> > >> that all being said. koji doesn't use any caching and will not
> > >> use the lvm plugin. we make every buildroot from scratch using a
> > >> fully clean environment to help with ensuring reproducability.
> >
> > > You can cache and still preserve reproducability. What I'm
> > > planning for Copr is to do (every week/month) for chroot in
> > > fedora-20-x86_64 fedora-21_86_64 ... ; do mock --init $chroot
> > >   done
> > > take snapshot of that. I plan to do that on VM level.
> > > And when new task come, I will just restore from that snapshot.
> > > And mock will start with already populated cache. So I will have
> > > better caching and yet reproducability.
> >
> > you really can't.  you would need to make a new cache any time one
> > of the packages in the minimal buildroot changes.
> 
> Actually this is not anytime. newRepo has to be run, which is not run
> more then 4 times per hour I'd say. If the new snapshot is prepared as
> part of newRepo task, the mock could reuse the snapshot.

ok I have a data point here https://ausil.fedorapeople.org/buildroots
the file in the link is the output of a sql query on koji's db it gives
the number of times a unique repo was used on a builder to do a build.
so basically it tells you if we cached the buildroots somehow  how many
times they would get used. 

$ grep "^ 19 |" buildroots|wc -l
1
$ grep "^ 18 |" buildroots|wc -l
0
$ grep "^ 17 |" buildroots|wc -l
0
$ grep "^ 16 |" buildroots|wc -l
2
$ grep "^ 15 |" buildroots|wc -l
1
$ grep "^ 14 |" buildroots|wc -l
0
$ grep "^ 13 |" buildroots|wc -l
8
$ grep "^ 12 |" buildroots|wc -l
13
$ grep "^ 11 |" buildroots|wc -l
14
$ grep "^ 10 |" buildroots|wc -l
15
$ grep "^  9 |" buildroots|wc -l
20
$ grep "^  8 |" buildroots|wc -l
24
$ grep "^  7 |" buildroots|wc -l
40
$ grep "^  6 |" buildroots|wc -l
59
$ grep "^  5 |" buildroots|wc -l
84
$ grep "^  4 |" buildroots|wc -l
155
$ grep "^  3 |" buildroots|wc -l
409
$ grep "^  2 |" buildroots|wc -l
1446
$ grep "^  1 |" buildroots|wc -l
4794

What I get from this is that in the majority of cases caching won't
help at all.  The cost of creating the cache is higher than the benefit
we would get.

Dennis
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBAgAGBQJUtvHgAAoJEH7ltONmPFDRP/sP/1iteUyvThkZLQGH4o+MY4uX
oIwdgwQQwkkjvpCyjFP1yyO5aJa/BTiOGSMtT0vQtnfAl+qYs7IiqGH6VJkNt+Io
Lmqr0yItXLr6ZyTwuKha2XYa88g+q657VmaJT/OmXGqi0Ezx8Rj/6NLXcV6twgKW
LD3YjxtPmyxX79p7RrkrI5+iJ+Iyw48HLepZup+XOfydOJ0RWZccRVlm0c0MYzt1
P6H0M+iiDikLl2NE1/jCTx+/P9yQNSQ8zhMVCjhevGiHSHmhIZmcpPib/IYGfRBN
OmgTaQ9XSaePNNrE4iqq6bQQ9fKqpA1FDlj1U2IaEHTh0CQ9zLCqKBuOl0ky98zY
/m3obzNSYu441tl/1Ig6imzRXga/iQ0jo8WnQoW8Grh3JtGpNM6NVPEUkkyKWCxE
XuagkPGWqP7x8YT/czn0Y9ZGjA+jIijzhdcAJ8R9R94wuhy+wvY5F69z6FKSycX6
Mho6yGj6cOrIB+F3Vs2+zn4rmtsU8jT7uhYc81CHJ0pEilcnINvFW9VDw7gYKq1E
LFzxMeixQugtGO39PqVFdG7WErqX2pjInJLu/CZIVz0bofQ17RuE006yl1pS4+jG
HoF6pCbZlapsRWS6TqXiMPhTSruszbZ733zihOgbDNSB6kIXZgI9nqj/jN8s8Dw1
ikGLTDN8nrnFxWMSt9pY
=/MGg
-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: GUI applications writing garbage to stdout/stderr

[Alexander Ploumistos]

On Thu, Jan 15, 2015 at 12:09 AM, Björn Persson  wrote:

> Alexander Ploumistos wrote:
> >On the other hand, if every message that was not meant for the user
> >were suppressed, it would be very difficult to troubleshoot such a
> >program, should an actual bug come along, because you would need a
> >different build to get useful output in the console or a logging
> >service.
>
> Nah, it takes only a command line parameter to turn on debug logging. An
> environment variable could also be used. A different build isn't needed.
> It's no harder to make logging conditional at run time than it is to
> make it conditional at build time.
>

The programs mentioned above do not have a debugging or verbosity flag,
like e.g. "nmap -dd". The output can help pinpoint anything from minor
aesthetic glitches, like a missing gtk theme, to crashes at startup. And
that is a lot faster than querying the environment or running debuggers.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Unplanned Fedora Outage 2015-01-14 21:30

[Stephen John Smoogen]

Fedora had a 35 minutes off the internet outage starting around 21:30 UTC.
This was due to my pushing an incomplete DNS table out causing named to
crash when it got to starting the file getfedora.com and not finding it.
Problem was backed out and changed but because of a bootstrap issue of
needing dns to get to dns in a couple of places it had to be done by hand
to get all DNS servers back up.

I am looking at what I can do to not have this happen again or make backing
out faster.

My apologies for the many many many pages people in sysadmin got.

-- 
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: GUI applications writing garbage to stdout/stderr

[Björn Persson]

Alexander Ploumistos wrote:
>On the other hand, if every message that was not meant for the user
>were suppressed, it would be very difficult to troubleshoot such a
>program, should an actual bug come along, because you would need a
>different build to get useful output in the console or a logging
>service.

Nah, it takes only a command line parameter to turn on debug logging. An
environment variable could also be used. A different build isn't needed.
It's no harder to make logging conditional at run time than it is to
make it conditional at build time.

-- 
Björn Persson


pgpe3awOb9zZ2.pgp
Description: OpenPGP digital signatur
-- 
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: How to contact Michale Cromeworth

[Felix Schwarz]

Am 14.01.2015 um 19:39 schrieb Chris Adams:
> MX->CNAME is against RFCs but in common enough real-world usage that
> anything that doesn't handle it is generally considered broken.

Well, one of the biggest German freemailers refused to send emails for
recipient domains using "MX is CNAME" when using their web interface (as of 
2014).

fs


-- 
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: Set sshd(8) PermitRootLogin=no

[Adam Williamson]

On Wed, 2015-01-14 at 16:54 +, P J P wrote:
>Hi,
> 
> > On Wednesday, 14 January 2015 8:01 PM, Simo Sorce wrote:
> > Ok, I state my opposition to without-password too inequivocably 
> > here. Mostly because it is just the same as 'no', given there is 
> > no way, in a regular install to seed a key into the root account.
> > 
> > Except you have no mechanism to inject a key at installation time,
> 
> 
>Sure. Could you please elaborate how would you like this key to be
> injected into the 'root' account? Feature page does have a listed 
> workflow change:
> 
>   "Anaconda installer OR maybe OpenSSH package needs to create
>initial set of authentication keys for 'root' user."
> 
> It'll help if you could add your details to the ether pad, for later 
> reference.

Still, you can't just invoke features into existence by describing 
them on a Change page. There needs to be a credible plan for actually 
*doing* that work, yet so far as I can tell, none of the anaconda 
developers is involved the Change proposal, nor has anyone said "I 
will write the code to make this work".

In a project like Fedora, it doesn't always work out well to do things 
the way this Change seems to be going: think of one change you want to 
do, write up a Change for it, realize that lots of other things would 
have to be done to make the change viable, and just write those things 
into the Change as bullet points, and assume that somehow they'll be 
made to happen if the change is approved.

Two other outcomes are more likely: 1) the Change will be rejected 
because FESCo is worried about whether the necessary work will 
actually get done, 2) the Change will get accepted but all the 
necessary work won't actually get done, and the Change will have to be 
backed out (wasting a lot of everyone's time), or the Change will go 
in broken and everyone loses.

Basically, when proposing a Change, you need to make sure that you 
have a plausible plan for all the necessary work to get done *ahead of 
time* - i.e. you need actual people who have said "yes, I will do this 
work, and I can believably commit to having it done in time". It 
doesn't work, normally, to draw up a Change which requires work to be 
done, then expect that you can get the Change accepted and resources 
will somehow transpire to do the work.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net

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

Split DNS broken again - test case?

[Ian Pilcher]

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

It seems like this is the 3rd or 4th time that this functionality has
been broken, leaving anyone who needs to simultaneously connect to both
VPN and other non-public (e.g. home network) resources up a creek.

Would this be worth of a test case?

-- 

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

Summary/Minutes from today's FESCo Meeting (2015-01-14)

[Matthew Miller]

===
#fedora-meeting: FESCO (2015-01-14)
===


Meeting started by mattdm at 18:01:50 UTC. The full logs are available
at
http://meetbot.fedoraproject.org/fedora-meeting/2015-01-14/fesco.2015-01-14-18.01.log.html
.



Meeting summary
---
* init process  (mattdm, 18:01:56)

* 1349 Fedora 22 scheduling strategy (and beyond)  (mattdm, 18:06:50)
  * LINK: https://fedorahosted.org/fesco/ticket/1349   (mattdm,
18:06:54)
  * AGREED: While Fedora prefers to always carry the latest features,
FESCo has determined that the Fedora 22 schedule is not compatible
with including a mass-rebuild. FESCo would prefer to hold to a
time-based schedule. (+6, 1, -1)  (sgallagh, 19:02:40)

* meeting schedule, continued  (mattdm, 19:08:58)

* #1374 SElf Contained Changes  (mattdm, 19:11:02)
  * LINK: https://fedorahosted.org/fesco/ticket/1374   (mattdm,
19:11:14)
  * AGREED: Lohit2 Odia Telugu self-contained change passes +7/-0
(mattdm, 19:15:47)
  * AGREED: New Default Console Font self-contained change passes +7/-0
(mattdm, 19:16:07)

* #1307 F22 System Wide Change: Default Local DNS Resolver  (mattdm,
  19:16:45)
  * LINK:
https://fedoraproject.org/wiki/Changes/Default_Local_DNS_Resolver
(mattdm, 19:16:49)
  * LINK: https://fedorahosted.org/fesco/ticket/1307   (mattdm,
19:16:51)
  * ACTION: pjp to add some notes about docker and cloud to the feature
page :)  (mattdm, 19:24:16)
  * ACTION: pavlix to look at init.d/network  (thozza, 19:24:36)
  * AGREED: Default Local DNS Resolver accepted for F22 (+7/0/0)
(mattdm, 19:25:17)

* #1379 F22 System Wide Change: Change xorg input stack to use libinput
  (mattdm, 19:25:31)
  * LINK: https://fedoraproject.org/wiki/Changes/LibinputForXorg
(mattdm, 19:25:34)
  * LINK: https://fedorahosted.org/fesco/ticket/1379   (mattdm,
19:25:36)
  * AGREED: Change xorg input stack to use libinpu accepted for F22
(+7/0/0)  (mattdm, 19:28:43)

* #1382 F22 System Wide Change: Fedora 22 Boost 1.58 Uplift  (mattdm,
  19:29:59)
  * LINK: https://fedoraproject.org/wiki/Changes/F22Boost158   (mattdm,
19:30:03)
  * LINK: https://fedorahosted.org/fesco/ticket/1382   (mattdm,
19:30:05)
  * AGREED: Side-tags must be merged into Rawhide by February 6th, with
Branch occurring on February 10th as previously scheduled. (+7/0/0)
(mattdm, 19:37:44)
  * AGREED: Boost 1.58 accepted for F22 (+6/-0/1)  (mattdm, 19:43:03)
  * timing makes 1.57 likely (as page explains)  (mattdm, 19:43:24)

* #1383 F22 System Wide Change: GHC 7.8  (mattdm, 19:43:59)
  * LINK: https://fedoraproject.org/wiki/Changes/GHC_7.8   (mattdm,
19:44:02)
  * LINK: https://fedorahosted.org/fesco/ticket/1383   (mattdm,
19:44:04)
  * AGREED: GHC 7.8 accepted for F22 (+7/0/0)  (mattdm, 19:45:52)

* #1384 F22 System Wide Change: Harden all packages with
  position-independent code  (mattdm, 19:45:59)
  * LINK:

https://fedoraproject.org/wiki/Changes/Harden_all_packages_with_position-independent_code
(mattdm, 19:46:03)
  * LINK: https://fedorahosted.org/fesco/ticket/1384   (mattdm,
19:46:05)
  * AGREED: System Wide Change: Harden all packages with
position-independent code NOT accepted for F22 (0,-7,0)  (mattdm,
19:49:04)
  * F23 decision defered until next week  (mattdm, 19:55:43)

* #1385 F22 System Wide Change: Ruby 2.2  (mattdm, 19:56:00)
  * LINK: https://fedoraproject.org/wiki/Changes/Ruby_2.2   (mattdm,
19:56:03)
  * LINK: https://fedorahosted.org/fesco/ticket/1385   (mattdm,
19:56:05)
  * AGREED: System Wide Change: Ruby 2.2 accepted for F22 (+6/0/0)
(mattdm, 19:56:55)

* #1386 F22 System Wide Change: Set sshd(8) PermitRootLogin=no
* # (mattdm,
  19:57:04)
  * LINK:
  * https://fedoraproject.org/wiki/Changes/SSHD_PermitRootLogin_no
(mattdm, 19:57:08)
  * LINK: https://fedorahosted.org/fesco/ticket/1386   (mattdm,
19:57:10)
  * The change text now actually proposes
PermitRootLogin=without-password  (mitr, 20:06:40)
  * AGREED: "Set sshd(8) PermitRootLogin=no" as systemwide DOES NOT
  * pass
for F22 (+0/-5/2)  (mattdm, 20:08:35)

* Next week's chair  (mattdm, 20:09:20)
  * dgilmore is the heroic chair for next week's meeting  (mattdm,
20:09:43)

* Open Floor  (mattdm, 20:09:47)

Meeting ended at 20:12:12 UTC.




Action Items

* pjp to add some notes about docker and cloud to the feature page :)
* pavlix to look at init.d/network




Action Items, by person
---
* pavlix
  * pavlix to look at init.d/network
* pjp
  * pjp to add some notes about docker and cloud to the feature page :)
* **UNASSIGNED**
  * (none)




People Present (lines said)
---
* mattdm (230)
* sgallagh (116)
* dgilmore (108)
* nirik (96)
* mitr (73)
* jwb (67)
* jreznik (38)
* jakubrh (37)
* kalev (35)
* thozza (30)
* pjp (28)
* zodbot (20)
* moezroy (9)
* vondruch (6)
* rdieter (5)
* drago01 (5)
* pavlix (5)
* hansg (5)
* tyll (2

Re: F22 System Wide Change: Set sshd(8) PermitRootLogin=no

[Mike Pinkerton]

On 14 Jan 2015, at 12:34, Miloslav Trmač wrote:


I'd request all(those who are opposing) too describe their
requirements in the etherpad page above.


Being able to authenticate as root right after installation would be
the requirement for me.


Let’s be precise here; “able to authenticate as root” is an  
implementation detail; the underlying requirement is something  
else.  “Able to set up IPA”?  “Able to run administrative  
commands in shell?” (e.g. we could just, as a part of firstboot,  
open a root shell without any authentication



It seems that the boxes affected by this proposal are either  
"product=server" or "product=nonproduct".  For servers, immediately  
after installing, I log in as root and run a set-up or configuration  
script which, among other things, sets the box to a non-graphical  
target and prevents firstboot from ever running.  I'm not sure why  
one would run firstboot on a server.


I also do something similar and prevent firstboot from running on  
boxes set up as general desktops for office workers, etc., as I don't  
want the first random user who logs into a box to be able to become  
part of the wheel group and have access to sudo.


As far as I can see, firstboot is only useful on one's personal box.

--
Mike Pinkerton

--
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: How to contact Michale Cromeworth

[Michael Cronenworth]

On 01/14/2015 12:39 PM, Chris Adams wrote:

MX->CNAME is against RFCs but in common enough real-world usage that
anything that doesn't handle it is generally considered broken.

However, that isn't the case for cchtml.com; the MX points to
cchtml.com, not mail.cchtml.com, and cchtml.com has an A record.


That was not the case 30 minutes ago. I modified the MX record to point to 
cchtml.com.


My registrar may have changed something recently as the interface allows for an 
IP address and that wasn't what it was doing.

--
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: How to contact Michale Cromeworth

[Chris Adams]

Once upon a time, Jochen Schmitt  said:
> I have retried to send the message without any success. But I have tried to
> maske an DNS query directly agins the Google DNS and have find out, that the
> hostname, which you have specified as a mail excahnge is a CNAME. But this is 
> not
> allowed for MX records. MX records have to point to A reords instead of CNAME
> records.

MX->CNAME is against RFCs but in common enough real-world usage that
anything that doesn't handle it is generally considered broken.

However, that isn't the case for cchtml.com; the MX points to
cchtml.com, not mail.cchtml.com, and cchtml.com has an A record.

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

Self Introduction and Review Request: Sinny Kumari

[Sinny Kumari]

Hi List,

I just pushed a package for review at
https://bugzilla.redhat.com/show_bug.cgi?id=1182261 and would like some
review on it.
I work at Red Hat India and contribute to KDE in my free time. I blog at
http://sinny.io/ and also give talks at local FOSS events (the last one was
on basic RPM packaging at Fedora 21 release party in Bangalore).

Please review my package and let me know if any changes are needed. I will
be more than happy to work on it.

Thanks
Sinny Kumari
-- 
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: How to contact Michale Cromeworth

[Reindl Harald]

Am 14.01.2015 um 18:26 schrieb Jochen Schmitt:

It very important, that your domain provides any MX records because
this is absolutly require to send mails to your domain


bullshit - fix your mailserver

there is no need for a MX record
read the SMTP RFC

the only reason when you need a MX is if your inbound mailserver is on a 
different machine then the A-record for the domain


[harry@srv-rhsoft:~]$ nslookup cchtml.com
Server: 127.0.0.1
Address:127.0.0.1#53

Non-authoritative answer:
Name:   cchtml.com
Address: 71.86.124.216

[harry@srv-rhsoft:~]$ telnet 71.86.124.216 25 



Trying 71.86.124.216... 



Connected to 71.86.124.216. 



Escape character is '^]'. 



220 cchtml.com ESMTP Postfix 



EHLO harry 



250-cchtml.com 



250-PIPELINING 



250-SIZE 2048 



250-VRFY 



250-ETRN 



250-STARTTLS 



250-AUTH PLAIN LOGIN 



250-AUTH=PLAIN LOGIN 



250-ENHANCEDSTATUSCODES
250-8BITMIM



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: How to contact Michale Cromeworth

[Michael Cronenworth]

On 01/14/2015 11:52 AM, Jochen Schmitt wrote:

I have retried to send the message without any success. But I have tried to
maske an DNS query directly agins the Google DNS and have find out, that the
hostname, which you have specified as a mail excahnge is a CNAME. But this is 
not
allowed for MX records. MX records have to point to A reords instead of CNAME
records.


Yes, my registrar over-simplified the mail record interface. I have now fixed 
that.

Regardless, this is the first time I've had an issue with receiving e-mail.
--
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: Set sshd(8) PermitRootLogin=no

[Miloslav Trmač]

> On Wed, 14 Jan 2015 12:34:22 -0500 (EST)
> Miloslav Trmač  wrote:
> 
> > > On Wed, 14 Jan 2015 16:54:09 + (UTC)
> > > P J P  wrote:
> > > > I'd request all(those who are opposing) too describe their
> > > > requirements in the etherpad page above.
> > > 
> > > Being able to authenticate as root right after installation would be
> > > the requirement for me.
> > 
> > Let’s be precise here; “able to authenticate as root” is an
> > implementation detail; the underlying requirement is something else.
> > “Able to set up IPA”?  “Able to run administrative commands in
> > shell?” (e.g. we could just, as a part of firstboot, open a root
> > shell without any authentication ☺ ). Mirek
> 
> except that will not work when you do not have access to a console and
> only have ssh access

At this point/in this sub-discussion, I personally very much don’t care.  Let’s 
collect the requirements first.
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 System Wide Change: GCC5

[Jakub Jelinek]

On Wed, Jan 14, 2015 at 12:51:24PM -0500, Miloslav Trmač wrote:
> > * Contingency mechanism: Revert to older gcc, mass rebuild everything again
> > * Contingency deadline: Before release
> 
> This is an invasive contingency mechanism, requiring retesting a lot of
> functionality; the contingency deadline for this (i.e.  when we need

It is a contingency mechanism which we never invoked in the past.

If there are bugs on the GCC side, they are just fixed.

And the GCC GA release time isn't that much special time, it is time when
the compiler is declared officially GA, but bugs are fixed before and after
that time under completely the same policy, only regression bugfixes and
documentation bugfixes are allowed starting with this Saturday onwards
(last two months allowed general bugfixes too, so not only for things that
regressed from earlier GCC releases).  So from the Fedora POV, starting this
Saturday only regression bugfixes will be allowed from now on until all
Fedoras that will ship GCC 5 go EOL.

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

Re: F22 System Wide Change: Set sshd(8) PermitRootLogin=no

[Dennis Gilmore]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Wed, 14 Jan 2015 12:34:22 -0500 (EST)
Miloslav Trmač  wrote:

> > On Wed, 14 Jan 2015 16:54:09 + (UTC)
> > P J P  wrote:
> > > > On Wednesday, 14 January 2015 8:01 PM, Simo Sorce wrote:
> > > > Ok, I state my opposition to without-password too inequivocably
> > > > here. Mostly because it is just the same as 'no', given there
> > > > is no way, in a regular install to seed a key into the root
> > > > account.
> > > > 
> > > > Except you have no mechanism to inject a key at installation
> > > > time,
> > > 
> > >Sure. Could you please elaborate how would you like this key
> > > to be injected into the 'root' account? Feature page does have a
> > > listed workflow change:
> > > 
> > >   "Anaconda installer OR maybe OpenSSH package needs to create
> > >initial set of authentication keys for 'root' user."
> 
> That’s not how, to my knowledge, ssh keys are usually deployed; there
> is one private key per user (or, for the paranoid, one private key
> per client machine / user’s home directory), not one private key per
> the server one is connecting to.  And creating a key does not really
> solve the problem: how do the administrators get the key so that they
> can connect?
> 
> 
> > > I'd request all(those who are opposing) too describe their
> > > requirements in the etherpad page above.
> > 
> > Being able to authenticate as root right after installation would be
> > the requirement for me.
> 
> Let’s be precise here; “able to authenticate as root” is an
> implementation detail; the underlying requirement is something else.
> “Able to set up IPA”?  “Able to run administrative commands in
> shell?” (e.g. we could just, as a part of firstboot, open a root
> shell without any authentication ☺ ). Mirek

except that will not work when you do not have access to a console and
only have ssh access

Dennis
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBAgAGBQJUtq2ZAAoJEH7ltONmPFDRzqsQAI59frCILBqB6zUWedryB5yp
378Wakimicon8HAHuUEqZb334246k4U3/d4FPaspGiqKtqSf2w1Y2nixFNdxGqor
mH5oyoToddasptFS2okRGh8IaPnZiBNXPVZ6emKrjeL+ln2DMsfSCPA9NN15AO/I
KllQ4j3YhDVm4qmL9a25pcNcPjUlIi1C6amR19eOkG7+788+7pMQ0yzcDcn3ow3O
F8u+j5bwPdPfwL/sEe6ZyGNgfHJEx+wtYCQjXMCQp3VkYHMkqHwkjR/q63l5TMtb
5SIFwzP6wmAaLvU3Nz4jEu8GWNQwm86cYIiEj1cRSN9muKffoIuJopKM1fchbveh
VuPH+FjZhvWShvN5tddaunOkGN2WtFJp8rgnWeVtT/09H+PbkzT3pigZt2OElnD/
49DWLork4uLOSuVPQvqMjMMsUbg1SLv9tB6AA45gtkEgkg+X256MdHUVK49HfOXS
ogCfgx7CfCPCd6cOEHx+exK3Xg9JlxqboIklR1pFyDLcyQUDkXaV0wrXq23hhrci
kLUpZ7yYTZwvHgKrQfQ99ael5alAHyCb/ZvWyAZyAoMeoJQKZoyCvNI5BWsVoGPQ
Ir1Z/nEGz2T/RbbpVrLvH5VzwkWY0hZyCEUwa+Wrh/LfyFBjxN6YM+YTdoPSI4Et
cifUPiu3gJqlrMnOJvyt
=nj7u
-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: How to contact Michale Cromeworth

[Jochen Schmitt]

On Wed, Jan 14, 2015 at 11:37:22AM -0600, Chris Adams wrote:

> Look at your results; you did not get that result in your dig.  You got

tahk you for your information, but the error message was created by a
relay host located by my ISP.


> failure while trying to resolve cchtml.com/MX.  It works for me from
> several locations on the Internet, so the problem would appear to be
> with your DNS.

I have retried to send the message without any success. But I have tried to
maske an DNS query directly agins the Google DNS and have find out, that the
hostname, which you have specified as a mail excahnge is a CNAME. But this is 
not
allowed for MX records. MX records have to point to A reords instead of CNAME
records.

Best Regards:

Jochen Schmitt

Skript gestartet auf Mi 14 Jan 2015 18:42:28 CET

; <<>> DiG 9.9.6-P1-RedHat-9.9.6-6.P1.fc21 <<>> @8.8.8.8 mail.cchtml.com
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 61595
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;mail.cchtml.com.   IN  A

;; ANSWER SECTION:
mail.cchtml.com.1720IN  CNAME   cchtml.com.
cchtml.com. 100 IN  A   71.86.124.216

;; Query time: 16 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Mi Jan 14 18:42:28 CET 2015
;; MSG SIZE  rcvd: 74


Skript beendet: Mi 14 Jan 2015 18:42:28 CET
-- 
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: GCC5

[Miloslav Trmač]

> * Contingency mechanism: Revert to older gcc, mass rebuild everything again
> * Contingency deadline: Before release

This is an invasive contingency mechanism, requiring retesting a lot of 
functionality; the contingency deadline for this (i.e. when we need to be 
comfortable that the revert will not be needed, should certainly be at the 
usual beta freeze at the latest, if not earlier.  Invoking this contingency 
mechanism “before release”, say during the GA RC phase, would really not be 
feasible without a massive slip.
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 System Wide Change: GCC5

[Miloslav Trmač]

> On Wed, Jan 14, 2015 at 02:24:29PM +, Peter Robinson wrote:
> > I was thinking exactly that, mass rebuild is scheduled for Jan 30th
> > according to the schedule [1] with branching 10 days or so later. That
> > is only two weeks away. With statements like "The release will happen
> > probably in the first half of April" when we're already suppose to be
> > be in freeze from end of March I think this would be better landing in
> > F-23 right after we branch F-22 off on Feb 10th. Ultimately the above
> > gives us no room to move and a roll back is another mass rebuild which
> > will only cause more delay!
> 
> Again, how is that different from F9, F11, F13, F15, F17, F19?

We are learning not to do the same mistakes all over again ☺

Now it could, I guess, be argued, that gcc has a long history of not having 
egregious failure modes we are learning from, and should be allowed to land 
later.  OTOH there is also, IIRC, a history of having to do a second (full or 
partial) or even a third rebuild due to necessary gcc bug fixes, and landing 
the .0 version at the time we ship Beta is basically an explicit bet that there 
will be no such bug in .0, or we are slipping.
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: How to contact Michale Cromeworth

[Kevin Fenzi]

On Wed, 14 Jan 2015 11:27:51 -0600
Michael Cronenworth  wrote:

> On 01/14/2015 11:26 AM, Jochen Schmitt wrote:
> > When I call dig with your domain, I have to recornized, thatyour
> > domain doesn't provides any MX records. I have tried to contact the
> > homstmaster of your domain without any response.
> >
> > It very important, that your domain provides any MX records because
> > this is absolutly require to send mails to your domain.
> 
> My domain does list an MX record. I'm afraid there is a problem with
> your local DNS.

...snip...

In addition, just to be clear, a MX record is not actually required. 

If there's no MX record, a A record should be used. (If any). 

If there's no MX or A, then there's a problem. :) 

kevin


pgpQGEoB98CTW.pgp
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: How to contact Michale Cromeworth

[Chris Adams]

Once upon a time, Jochen Schmitt  said:
> When I call dig with your domain, I have to recornized, thatyour domain
> doesn't provides any MX records. I have tried to contact the
> homstmaster of your domain without any response.

Look at your results; you did not get that result in your dig.  You got
a "status: SERVFAIL", which means your recursive server had some type of
failure while trying to resolve cchtml.com/MX.  It works for me from
several locations on the Internet, so the problem would appear to be
with your DNS.

-- 
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 System Wide Change: Set sshd(8) PermitRootLogin=no

[P J P]

> On Wednesday, 14 January 2015 10:44 PM, Simo Sorce wrote:
>>   "Anaconda installer OR maybe OpenSSH package needs to create
>> initial set of authentication keys for 'root' user."
> 
> Sorry, but what is the point of this operation, wrt auth with keys issue ?

  Well, it can be used it to export to other machines. It'll require you to
login as non-root user first.

> Being able to authenticate as root right after installation would be
> the requirement for me.

  Right. But how would you inject a key for that? 

If you must have only 'root' account in your set-up, remote root access
could be enabled by default. Feature page lists

  ...
  "Omission of such user account should prompt user if they wish to
enable remote 'root' login, and set the parameter appropriately."

---
Regards
   -Prasad
http://feedmug.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: Set sshd(8) PermitRootLogin=no

[Miloslav Trmač]

> On Wed, 14 Jan 2015 16:54:09 + (UTC)
> P J P  wrote:
> > > On Wednesday, 14 January 2015 8:01 PM, Simo Sorce wrote:
> > > Ok, I state my opposition to without-password too inequivocably
> > > here. Mostly because it is just the same as 'no', given there is no
> > > way, in a regular install to seed a key into the root account.
> > > 
> > > Except you have no mechanism to inject a key at installation time,
> > 
> >Sure. Could you please elaborate how would you like this key to be
> > injected into the 'root' account? Feature page does have a listed
> > workflow change:
> > 
> >   "Anaconda installer OR maybe OpenSSH package needs to create
> >initial set of authentication keys for 'root' user."

That’s not how, to my knowledge, ssh keys are usually deployed; there is one 
private key per user (or, for the paranoid, one private key per client machine 
/ user’s home directory), not one private key per the server one is connecting 
to.  And creating a key does not really solve the problem: how do the 
administrators get the key so that they can connect?


> > I'd request all(those who are opposing) too describe their
> > requirements in the etherpad page above.
> 
> Being able to authenticate as root right after installation would be
> the requirement for me.

Let’s be precise here; “able to authenticate as root” is an implementation 
detail; the underlying requirement is something else.  “Able to set up IPA”?  
“Able to run administrative commands in shell?” (e.g. we could just, as a part 
of firstboot, open a root shell without any authentication ☺ ).
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: How to contact Michale Cromeworth

[Michael Cronenworth]

On 01/14/2015 11:26 AM, Jochen Schmitt wrote:

When I call dig with your domain, I have to recornized, thatyour domain
doesn't provides any MX records. I have tried to contact the
homstmaster of your domain without any response.

It very important, that your domain provides any MX records because
this is absolutly require to send mails to your domain.


My domain does list an MX record. I'm afraid there is a problem with your local 
DNS.

$ dig @8.8.8.8 MX cchtml.com

; <<>> DiG 9.9.6-P1-RedHat-9.9.6-6.P1.fc21 <<>> @8.8.8.8 MX cchtml.com
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 30951
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;cchtml.com.IN  MX

;; ANSWER SECTION:
cchtml.com. 1799IN  MX  10 mail.cchtml.com.

;; Query time: 128 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Wed Jan 14 11:27:06 CST 2015
;; MSG SIZE  rcvd: 60

--
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: How to contact Michale Cromeworth

[Jochen Schmitt]

On Wed, Jan 14, 2015 at 10:47:07AM -0600, Michael Cronenworth wrote:

> Hi,
> 
> I'm here. I'm not sure why your e-mail failed. Could you try it again?

When I call dig with your domain, I have to recornized, thatyour domain
doesn't provides any MX records. I have tried to contact the
homstmaster of your domain without any response.

It very important, that your domain provides any MX records because
this is absolutly require to send mails to your domain.

Best Regards:

Jochen Schmitt

Skript gestartet auf Mi 14 Jan 2015 18:16:05 CET

; <<>> DiG 9.9.6-P1-RedHat-9.9.6-6.P1.fc21 <<>> cchtml.com mx
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 62795
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;cchtml.com.IN  MX

;; Query time: 6 msec
;; SERVER: 192.168.178.2#53(192.168.178.2)
;; WHEN: Mi Jan 14 18:16:05 CET 2015
;; MSG SIZE  rcvd: 39


Skript beendet: Mi 14 Jan 2015 18:16:05 CET


-- 
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: Set sshd(8) PermitRootLogin=no

[Simo Sorce]

On Wed, 14 Jan 2015 16:54:09 + (UTC)
P J P  wrote:

>Hi,
> 
> > On Wednesday, 14 January 2015 8:01 PM, Simo Sorce wrote:
> > Ok, I state my opposition to without-password too inequivocably
> > here. Mostly because it is just the same as 'no', given there is no
> > way, in a regular install to seed a key into the root account.
> > 
> > Except you have no mechanism to inject a key at installation time,
> 
> 
>Sure. Could you please elaborate how would you like this key to be
> injected into the 'root' account? Feature page does have a listed
> workflow change:
> 
>   "Anaconda installer OR maybe OpenSSH package needs to create
>initial set of authentication keys for 'root' user."

Sorry,
but what is the point of this operation, wrt auth with keys issue ?

> It'll help if you could add your details to the ether pad, for
> later reference.
> 
>   here -> https://www.piratepad.ca/p/ssh-remoterootloigin
> 
> 
> > The intention may be not, then I'll call it poor execution/planning
> > and still oppose this move *at this time* unless there is proof we
> > address the usability problem first.
> 
>   We are still in the proposal state, not execution yet. IMO, before
> we request the respective upstream developers to provide the needed
> functionality, we need to state and agree on the usability
> requirements. That'll be useful in the evaluation of the feature by
> the FES committee too. Otherwise it's a chicken-and-egg problem.

It *is* a chicken-egg issue to some degree.

> I'd request all(those who are opposing) too describe their
> requirements in the etherpad page above.

Being able to authenticate as root right after installation would be
the requirement for me.

Simo.

-- 
Simo Sorce * Red Hat, Inc * New York
-- 
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: GCC5

[David Howells]

Jaroslav Reznik  wrote:

> Switch GCC in Fedora 22 to 5.x.y, rebuild all packages with it.

Does cross-gcc need to switch simultaneously?  Some packages are built with
that, I believe.

David
-- 
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: GCC5

[Jakub Jelinek]

On Wed, Jan 14, 2015 at 05:05:50PM +, David Howells wrote:
> Jaroslav Reznik  wrote:
> 
> > Switch GCC in Fedora 22 to 5.x.y, rebuild all packages with it.
> 
> Does cross-gcc need to switch simultaneously?  Some packages are built with
> that, I believe.

It is a different package, so it can switch independently.

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

Re: F22 System Wide Change: Set sshd(8) PermitRootLogin=no

[P J P]

   Hi,

> On Wednesday, 14 January 2015 8:01 PM, Simo Sorce wrote:
> Ok, I state my opposition to without-password too inequivocably here.
> Mostly because it is just the same as 'no', given there is no way, in a
> regular install to seed a key into the root account.
> 
> Except you have no mechanism to inject a key at installation time,


   Sure. Could you please elaborate how would you like this key to be
injected into the 'root' account? Feature page does have a listed
workflow change:

  "Anaconda installer OR maybe OpenSSH package needs to create
   initial set of authentication keys for 'root' user."

It'll help if you could add your details to the ether pad, for
later reference.

  here -> https://www.piratepad.ca/p/ssh-remoterootloigin


> The intention may be not, then I'll call it poor execution/planning and
> still oppose this move *at this time* unless there is proof we address
> the usability problem first.

  We are still in the proposal state, not execution yet. IMO, before
we request the respective upstream developers to provide the needed
functionality, we need to state and agree on the usability requirements.
That'll be useful in the evaluation of the feature by the FES committee too.
Otherwise it's a chicken-and-egg problem.

I'd request all(those who are opposing) too describe their requirements in
the etherpad page above.

Thank you.
---
Regards
   -Prasad
http://feedmug.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: How to contact Michale Cromeworth

[Michael Cronenworth]

On 01/14/2015 10:42 AM, Jochen Schmitt wrote:

I have got a mail from a guy which ask me for co-maintainership of the inady-mt 
package.

Unfortunately, I have got the below error report on the try to contact
him via mail.

So I would like to ask how I can contact him via an alternative mail
contact.

Best Regards:

Jochen Schmitt


Hi,

I'm here. I'm not sure why your e-mail failed. Could you try it again?
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

How to contact Michale Cromeworth

[Jochen Schmitt]

Halle,

I have got a mail from a guy which ask me for co-maintainership of the inady-mt 
package.

Unfortunately, I have got the below error report on the try to contact
him via mail.

So I would like to ask how I can contact him via an alternative mail
contact.

Best Regards:

Jochen Schmitt

- Forwarded message from Mail Delivery System 
 -

Date: Sat, 03 Jan 2015 20:47:02 +0100
From: Mail Delivery System 
To: joc...@herr-schmitt.de
Subject: Mail delivery failed: returning message to sender

This message was created automatically by mail delivery software.

A message that you sent could not be delivered to one or more of
its recipients. This is a permanent error. The following address
failed:

"m...@cchtml.com":
no valid MX hosts found



--- The header of the original message is following. ---

Received: from omega.inet.herr-schmitt.de ([80.128.217.208]) by
 mrelayeu.kundenserver.de (mreue003) with ESMTPSA (Nemesis) id
 0M0MwL-1Xp8iK3d5J-00uZ2Z for ; Sat, 03 Jan 2015 20:41:45
 +0100
Received: by omega.inet.herr-schmitt.de (Postfix, from userid 1000)
id 0D6CB60382; Sat,  3 Jan 2015 20:41:09 +0100 (CET)
Date: Sat, 3 Jan 2015 20:41:09 +0100
From: Jochen Schmitt 
To: Michael Cronenworth 
Subject: Re: inadyn-mt help
Message-ID: <20150103194108.gb1...@omega.inet.herr-schmitt.de>
References: <5499e0df.3030...@cchtml.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <5499e0df.3030...@cchtml.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Provags-ID:  V03:K0:jTSMh79IfVn8wJZUna2WoNiPIhCAPcRhE/vWzPNUmm75tiuIMaV
 pfnQYi00z1YKcr6YXhDhQ4PcD3cEJQrR08EMILgoGBvVa8+rHWpvshkAqOX2CNuPqxvP0+R
 /anI9CkhfEh3LnJZoVZvrVfge/kaEzDiOdFmYrfmyy6CpiKLdYpQxeKBv1EJGeyEMM3Eq92
 RLkoS3LjtCUSw5kMr1RmQ==
X-UI-Out-Filterresults: notjunk:1;




- End forwarded message -
-- 
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: GCC5

[Helio Chissini de Castro]

On Wed, Jan 14, 2015 at 1:46 PM, Jonathan Underwood <
jonathan.underw...@gmail.com> wrote:

> On 14 January 2015 at 14:47, Jakub Jelinek  wrote:
> > On Wed, Jan 14, 2015 at 02:44:03PM +, Richard Hughes wrote:
> >> On 14 January 2015 at 14:37, Jonathan Underwood
> >>  wrote:
> >> > Only a partial answer to your question, but one fairly significant
> >> > change (as you know) compared to the GCC upgrades for those releases
> >> > is moving from C89 to C11 as the default C standard for the compiler
> >>
> >> Is there any easy way for humble little upstream maintainers to test
> >> their code with the new compiler?
> >
> > You mean for the C89 -> C11 default change, or for other changes in GCC
> 5?
> > For the former, just build with -std=gnu11 with GCC 4.9 (or 4.8).
>
> Perhaps it would be worth adding -std=gnu11 to the F22 default flags
> now and having a rebuild, before gcc5 lands, to start shaking out
> problems now?
> --
> devel mailing list
> devel@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/devel
> Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
>

+1 for this.

Will help a lot to see how all the code base is behaving well on new
standards
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Invitation to DevConf.cz 2015

[Jiri Eischmann]

Hi,
let me invite you to DevConf.cz 2015 [1] which will take place in Brno,
Czech Republic on Feb 6-8.
The third day of the conference will again be Fedora Day with a lot of
Fedora-focused talks and discussions (and also with a lot of Fedora
contributors around). You can find the list of Fedora-focused talks and
workshops at [2]. There are, of course, much more talks on
Fedora-related technologies, just check the schedule [3].

Jiri

[1] http://devconf.cz/
[2]
https://eischmann.wordpress.com/2015/01/13/fedora-at-devconf-cz-2015/
[3] http://devconf.cz/schedule

-- 
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: Hundreds of bugzilla mails on one day

[Matthew Miller]

On Sat, Jan 10, 2015 at 12:43:46PM +0100, drago01 wrote:
> Yeah I just delete those mails now days. Its just spam "F19 is EOL" is
> not news that I need to get 1000 times.

Right, clearly, that message is not really for _you_. It's for the
people who reported the bug.

-- 
Matthew Miller

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

Re: F22 Self Contained Change: Gnome Shell - New Notifications

[Pierre-Yves Chibon]

On Wed, Jan 14, 2015 at 10:31:05AM -0500, Matthias Clasen wrote:
> On Wed, 2015-01-14 at 13:24 +, Peter Robinson wrote:
> > On Wed, Jan 14, 2015 at 1:17 PM, Pierre-Yves Chibon  
> > wrote:
> > > On Wed, Jan 14, 2015 at 01:00:27PM +0100, Jaroslav Reznik wrote:
> > >> = Proposed Self Contained Change: Gnome Shell - New Notifications =
> > >> https://fedoraproject.org/wiki/Changes/GnomeShell_NewNotifications
> > >>
> > >> Change owner(s): Florian Müllner 
> > >>
> > >> Redesign the way in which notifications are shown and kept available in 
> > >> gnome-
> > >> shell.
> > >>
> > >> == Detailed Description ==
> > >> The message tray is one of the remaining weaker points of the original 
> > >> gnome-
> > >> shell design. This change will replace it with a new implementation of
> > >> notifications that avoids the problems of the current implementation.
> > >
> > > Is there a place where the detailed description is more detailed?
> > > A wiki page on gnome.org maybe listing the current problems and the new 
> > > approach
> > > taken?
> > > I'm curious and would like to read more about this :)
> > 
> > Allan Day, one of the gnome designers, did a pretty good overview in a
> > couple of blog posts.
> > 
> > http://blogs.gnome.org/aday/2014/06/18/a-notifications-update/
> 
> Good point - I've added that link to the page now.


Thank you both :)

Pierre
-- 
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: Wine to use mesa Direct3D

[Igor Gnatenko]

On Wed, Jan 14, 2015 at 5:16 PM, Michael Cronenworth  wrote:
> On 01/14/2015 06:28 AM, Jaroslav Reznik wrote:
> [snip]
>>
>> * Contingency mechanism: Revert and try to do in next release
>
>
> I don't see this one happening. The patch set is large. Upstream has
> rejected it. The affected user base is small. I'm unconvinced right now that
> it's worth the time and effort to maintain.
I will cite Axel Davy who wrote this patchset (he sent this privately
to me, you and other maintainer)
1) you can find a list of D3D11 only apps here:
http://en.wikipedia.org/wiki/List_of_games_with_DirectX_11_support

As you can see all d3d11 apps before 2012 had a d3d9 backend, and some
d3d11 apps still had
a d3d9 backend after that. A lot of new games released this year (most
non-big production games) are still using d3d9.

2) After several discussions with wine devs, they said they would
never consider putting us upstream,
but that we could with - a lot of work and refactoring - compile our
mesa code with the wine compiler and get a resulting d3d9.dll that we
could distribute and give to users so that they can use it instead of
wine dll.
This scheme requires work, and we would like to let the possibility to
have nine outside of wine. It's probably not going to happen in the
next two years, but who knows...

3) wine nine code doesn't change a lot of wine code. Most of the ~20
patches are on our code.
Our team take care of rebasing often under the last version of wine.

4) Do you play some games with wine ? Some games have severe issues,
like stutter, etc. While on radeon cards, there is obvious gains, on
nouveau there is too according to one of our nouveau tester.

I think for fedora it would make sense to keep the mesa nine package,
but I'm not 100% sure for the wine part.
We are probably going to have PlayOnLinux support soon, which allows
to install easily different version of wine, including non-official
ones. Users wanting to use wine nine could go through that if it isn't
shipped in the main wine package.

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



-- 
-Igor Gnatenko
-- 
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: Summary/Minutes from today's FESCo Meeting (2015-01-07)

[Jaroslav Reznik]

- Original Message -
> On Wed, Jan 14, 2015 at 4:32 AM, Jaroslav Reznik  wrote:
> > - Original Message -
> >> On Tue, 2015-01-13 at 15:58 -0700, Kevin Fenzi wrote:
> >> > The Fedora 21 mass rebuild took about 40 hours. ;)
> >>
> >> BTW, https://fedoraproject.org/wiki/Fedora_22_Mass_Rebuild is empty.
> >> What are the goals of a mass rebuild now, given that we just had one
> >> before F21 Beta?
> >
> > This is actually that reason I liked how we constructed schedule last two
> > releases - based on proposed changes, taking look what needs mass rebuild
> > etc. And it could even end with no mass rebuild (or mass rebuild request
> > can come on Jan-20 when the deadline for changes is). But I was alone
> > who liked the old-new way and FESCo decided to set schedule the old-old
> > way, I'm just the guy who puts it to the wiki :).
> 
> You aren't alone.  I'm still not convinced the strict time-based
> schedule will work, but most of FESCo wanted to give it a shot.
> Rather then be a stick in the mud, I went with "don't be afraid to
> fail".
>
> Who knows, maybe it will work out.  If it does, I think it's going to
> change some of the things people expect from Fedora in both good and
> bad ways.  Good, delivered on time.  Bad (maybe), delivered with less
> cutting-edge packages.

I didn't mean it bad and yes - the result may lead to less cutting
edge packages but on the other hand with predictable schedule, you know
the next window is pretty soon (within 6 months). I'm just not convinced
(planned) slips are that big deal (unless Phoronix forum complaints
makes it a big deal;-). It can put more stress on folks, flexibility
has some costs but... And we have that power to define what Fedora
should be and I accepted it :). 

Jaroslav

> josh
> --
> 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: F22 Self Contained Change: Gnome Shell - New Notifications

[Jiri Eischmann]

Jaroslav Reznik píše v St 14. 01. 2015 v 13:00 +0100:
> = Proposed Self Contained Change: Gnome Shell - New Notifications =
> https://fedoraproject.org/wiki/Changes/GnomeShell_NewNotifications
> 
> Change owner(s): Florian Müllner  
> 
> Redesign the way in which notifications are shown and kept available in gnome-
> shell. 
> 
> == Detailed Description ==
> The message tray is one of the remaining weaker points of the original gnome-
> shell design. This change will replace it with a new implementation of 
> notifications that avoids the problems of the current implementation. 
> 
> == Scope ==
> * Proposal owners:
> ** Implement the new design
> ** Get the changes reviewed and merged upstream
> 
> * 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) 
> 
> == Contingency Plan ==
> N/A (not a System Wide Change)

What is still not very clear to me is if IM will still be somehow
integrated into the Shell. I know I will be able to reply directly in
the notification, but now if I miss the notification I can always go
back to the contact in the message tray and see the conversation there.
It's been a killer feature for me and many people around me and since
Empathy itself is not very usable in GNOME 3 it'd be a pity to lose the
integration.
What about app icons for the notification area (Dropbox, Pidgin,...),
where will they go?

Jiri 

-- 
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: Summary/Minutes from today's FESCo Meeting (2015-01-07)

[Vít Ondruch]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Dne 14.1.2015 v 15:53 Dennis Gilmore napsal(a):
> On Wed, 14 Jan 2015 10:48:16 +0100
> Vít Ondruch  wrote:
>
>
> > -BEGIN PGP SIGNED MESSAGE-
> > Hash: SHA1
>
> > Dne 14.1.2015 v 00:24 Dennis Gilmore napsal(a):
> >> On Tue, 13 Jan 2015 15:58:51 -0700
> >> Kevin Fenzi  wrote:
> >>
> >>> On Tue, 13 Jan 2015 15:50:06 -0700
> >>> Stephen John Smoogen  wrote:
> >>
>  You forgot "too many packages?" There are 15842 packages in
>  Fedora 21 and 16230 in Rawhide. That is a lot of packages that
>  have to be rebuilt possibly multiple times due to FTBFS, multiple
>  architectures, etc.
> 
>  2.5 weeks is 25200 minutes. That means a mass rebuild is doing
>  0.6 packages a minute across 3 architectures. That is pretty
>  darn fast
> >>
> >>> The Fedora 21 mass rebuild took about 40 hours. ;)
> >>
> >>> That's really not the reason for more time, its the fallout from
> >>> that. When the mass rebuild is tagged in, sometimes there's
> >>> things broken in the build root, those need humans to look at and
> >>> fix. Then, there are all the packages that didn't build for
> >>> whatever reason, those need humans to look at them and fix them
> >>> up. The ones with broken deps need fixing, etc.
> >>
> >>> So, while the mass rebuild itself is less than 2 days, it takes a
> >>> while to stablize things after that. If we branched right after
> >>> the mass rebuild we would have to then stablize both rawhide and
> >>> f22.
> >>
> >>> It's hard to say how much time we really need there... it depends
> >>> on how much stuff got broken, how hard it is to fix and how much
> >>> time maintainers have to fix things.
> >>
> >> right. in the past the building took around a week or a bit more, we
> >> have gotten that down. which is why I said we could drop the 4
> >> weeks to 3. the time consuming part is the cleanup and fixing of
> >> issues. that needs people. If everything is perfect a week could
> >> well be sufficient. Ideally we want secondary arches to be done in
> >> the window as well. just to make sure that there is no fallout on
> >> them requiring a second rebuild. which could also happen on
> >> primary. we have had ABI issues etc in the past on all arches.
> >>
> >> Dennis
>
> > What I would love to see is to leave out the packages which are build
> > in side tag from mass rebuild.
>
> > E.g. if I have side tag for Ruby, I rebuild every package in the side
> > tag in two weeks before mass rebuild, I can hardly see any
> > justification to build them once again (unless there lands gcc in the
> > man time or something like this). So if you could exclude the
> > packages which are already build in side tag from mass rebuild, it
> > would help you with following merge and it would give me additional
> > time to rebuild Ruby packages.
>
> > Is something like this feasible?
>
> It really depends on a lot of things. like does gcc 5 land after you
> have started your builds? we can go about excluding things viaa few
> different means. but it all really depends on a bunch of currently
> unknown factors.
>
> Dennis

Yes sure, depends on precise timing. It could be also solved by sidetag
mini-mass rebuild ...


Vít
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBAgAGBQJUto6kAAoJEAzgnueZF7h8CEYQAIVjaHhx6MxII4XaRLygGEoB
iJqiH1D0b2FWmPwwAVMQ0Lzqibj19VbyLqm9+3FsxZcSs4X2uJ4oACKJlAAfv4Yc
imK4oMQiB4iSnOpxk5IFQpDvm1yU+1yl6S7O3CA/R/sLOzXuM+nd7iqWwkVYYG2V
1vvilhLKcwm51wDJ+HlIvmIWFjR0yRy1Q8LFybdveKR3XlJHIPhAY+F8BHRM8SfI
tcQ46lS/YOQYZa0VDxO3x6pY6759OOHEI02DQG7agU3KT15Vk6Cg4qw9HUXoJDvM
IN35Wnr/nFKfwwxRYyQWYBNnfXnK1KM8UONNG+wQ/ieXTQet7/DWLWLzfr4Dccz0
FZ30tirxhX7UDinKgk6sYytxjxbQGOdb8NB3KO+/ddmFQN5FMnWhiEWQGitHt221
vHil3HV6FaUQ71c7hBWWQftOIDbRIUaz4oH3NCzw0tnilQzq2CWmVekYip0zQ+/u
c1HoMUu1B+JddklZJ+a6Ad92eKEZiJCsZESJDxN71SNgWTpy1DOXPAiIUsFQBdJp
X+Lr9SMc515UME1uvEBC7RO5ufC7cWoCq1KkCm1J5xViX3UR5KTcbMuVVdqPgegM
7taueRHcn2HX3+8LcC5ZTgTWaPX26IXwWZQ3y86Yd/oIqTwC6obJY4g9GcBodFdx
sQxIvjcwJSBYsVSUBEbo
=B71B
-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 System Wide Change: GCC5

[Jonathan Underwood]

On 14 January 2015 at 14:47, Jakub Jelinek  wrote:
> On Wed, Jan 14, 2015 at 02:44:03PM +, Richard Hughes wrote:
>> On 14 January 2015 at 14:37, Jonathan Underwood
>>  wrote:
>> > Only a partial answer to your question, but one fairly significant
>> > change (as you know) compared to the GCC upgrades for those releases
>> > is moving from C89 to C11 as the default C standard for the compiler
>>
>> Is there any easy way for humble little upstream maintainers to test
>> their code with the new compiler?
>
> You mean for the C89 -> C11 default change, or for other changes in GCC 5?
> For the former, just build with -std=gnu11 with GCC 4.9 (or 4.8).

Perhaps it would be worth adding -std=gnu11 to the F22 default flags
now and having a rebuild, before gcc5 lands, to start shaking out
problems now?
-- 
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: GCC5

[Zbigniew Jędrzejewski-Szmek]

On Wed, Jan 14, 2015 at 03:47:18PM +0100, Jakub Jelinek wrote:
> On Wed, Jan 14, 2015 at 02:44:03PM +, Richard Hughes wrote:
> > On 14 January 2015 at 14:37, Jonathan Underwood
> >  wrote:
> > > Only a partial answer to your question, but one fairly significant
> > > change (as you know) compared to the GCC upgrades for those releases
> > > is moving from C89 to C11 as the default C standard for the compiler
> > 
> > Is there any easy way for humble little upstream maintainers to test
> > their code with the new compiler?
> 
> You mean for the C89 -> C11 default change, or for other changes in GCC 5?
> For the former, just build with -std=gnu11 with GCC 4.9 (or 4.8).
> The latter is mainly C++ or new features, so something you don't hit on
> average C code.
I think it's a valid request. Of course packagers can approximate, but
to test for issues it would be best to have a simple way to build with gcc5
from the latest snapshot. How do you expect people to make an informed
decision otherwise?

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

Koji build root caching

[Vít Ondruch]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Dne 14.1.2015 v 16:00 Dennis Gilmore napsal(a):
> On Wed, 14 Jan 2015 14:57:59 +0100
> Miroslav Suchý  wrote:
>
> > On 01/13/2015 06:01 PM, Dennis Gilmore wrote:
> >> that all being said. koji doesn't use any caching and will not use
> >> the lvm plugin. we make every buildroot from scratch using a fully
> >> clean environment to help with ensuring reproducability.
>
> > You can cache and still preserve reproducability. What I'm planning
> > for Copr is to do (every week/month) for chroot in fedora-20-x86_64
> > fedora-21_86_64 ... ; do mock --init $chroot
> >   done
> > take snapshot of that. I plan to do that on VM level.
> > And when new task come, I will just restore from that snapshot. And
> > mock will start with already populated cache. So I will have better
> > caching and yet reproducability.
>
> you really can't.  you would need to make a new cache any time one of
> the packages in the minimal buildroot changes.

Actually this is not anytime. newRepo has to be run, which is not run
more then 4 times per hour I'd say. If the new snapshot is prepared as
part of newRepo task, the mock could reuse the snapshot.


Vít

> while it may not be
> intentional you can get differences in setup and behaviour due to
> scriptlets doing different things on update and initial install. to get
> reproducability you would need to start with the same packages set and
> get the same updates. it really is not simple to do nor to track. which
> is why we purposely disable all caching.
>
> Dennis
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBAgAGBQJUto3yAAoJEAzgnueZF7h8WqoP/28+1zNKBSnYp8UfKJkBgltT
qslYPgfwKWIVDsYVAKDf1Yqi/hYXl7cQuNOwDwgROO8Y34R0zPKGOVavl9CX7j4u
+i8UGdpa9AmFe2WffTa6Z3U9rw93sMlPYtNhMKv3LeyQfgbhEIIqhVe4RL7bnht6
WfGrxWonWfipI8SL/jm60DgbT7634uoj0XZoVekETBoF67nmW5Y1U3zoLnpTJnEM
ZO0+i2hHYPfRE3nPgN6Vw983Mh8pGya2vGFyRmyL5mjgz8i5fiSD0zjxhoX6BBF9
QYqVVPCCs8IJRhvX27AOSOKc9O3aBLYg1DczSpHTWMKGGTr9TgtgU5mOQuAhA06q
8c65nI5t/owmNwjQeC2uiQHa8jaqBtpmHYDevcjnqhsSfbCcdvLRjS7b80bvNWdg
IcEv9ui6Af8+x75hTVhGUyvb7N02rQaOQx9MSVrWISG59AvRpBvE0HXM2d9lSdnN
Kzs9EHerihLO+doZNZBD6qj9AaSzY2tKXJtBQL3myhi0Oj2wmUulUAm67VZmP4XK
zZ9JGZ7DJCQOFAL2xkl/t1t4/0tDFwBZM1OFt8wQjE91CS3eCpV1iQRDVtDWZx2B
Ih6y3gRNfJMRLBdUHSVfvU32kNmvxkloT98mv5F5bhJH4cYiY8OxmEoEvmg29u/y
n7Ry0RU1Z37l7v5LvfRB
=TqRs
-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: Gnome Shell - New Notifications

[Matthias Clasen]

On Wed, 2015-01-14 at 13:24 +, Peter Robinson wrote:
> On Wed, Jan 14, 2015 at 1:17 PM, Pierre-Yves Chibon  
> wrote:
> > On Wed, Jan 14, 2015 at 01:00:27PM +0100, Jaroslav Reznik wrote:
> >> = Proposed Self Contained Change: Gnome Shell - New Notifications =
> >> https://fedoraproject.org/wiki/Changes/GnomeShell_NewNotifications
> >>
> >> Change owner(s): Florian Müllner 
> >>
> >> Redesign the way in which notifications are shown and kept available in 
> >> gnome-
> >> shell.
> >>
> >> == Detailed Description ==
> >> The message tray is one of the remaining weaker points of the original 
> >> gnome-
> >> shell design. This change will replace it with a new implementation of
> >> notifications that avoids the problems of the current implementation.
> >
> > Is there a place where the detailed description is more detailed?
> > A wiki page on gnome.org maybe listing the current problems and the new 
> > approach
> > taken?
> > I'm curious and would like to read more about this :)
> 
> Allan Day, one of the gnome designers, did a pretty good overview in a
> couple of blog posts.
> 
> http://blogs.gnome.org/aday/2014/06/18/a-notifications-update/

Good point - I've added that link to the page now.

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

[Jakub Jelinek]

On Wed, Jan 14, 2015 at 03:05:09PM +, Peter Robinson wrote:
> > Well, if we want to turn Fedora into a collection of obsolete software
> > rather than trying to lead progress, we don't have to update anything.
> 
> I think that's a bit of an over reaction, ultimately F-22 is due to
> branch on February 10th which is less than a month from now, the
> moment it branches gcc5 could land and people are then free to rebuild
> anything they like and gcc5 will be in the October release which is in
> all likely hood earlier than most other distros would adopt it anyway.

For a product with a rough schedule every 6 month and another quite time
based every 12 months that is significant.  It turns Fedora from being one
of the first distros to ship the new compilers to one of the last if not the
last one.

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

Re: F22 System Wide Change: Set sshd(8) PermitRootLogin=no

[Ian Malone]

On 14 January 2015 at 14:31, Simo Sorce  wrote:
> On Wed, 14 Jan 2015 05:53:23 + (UTC)
> P J P  wrote:
>

>> IMO, the ones opposing are those who fear their current
>> setups/practices would break. Because they need remote 'root' access
>> in their set-up. Which is a genuine use-case. And to support it, we
>> could provide an option to enable remote root access with
>> 'PermitRootLogin=Yes', based on the the user's response to Anaconda
>> at install time, as was suggested in previous email. However, let's
>> not assume _all_ Fedora users have this use-case.
>
> Workstation do not even enable sshd (IIRC) so this impacts the server
> images (cloud images already do their magic with sshd so I am not
> counting them here), and server has different use cases and security
> implications than a generic population.
>

Not just workstation, spin images, it's a decision pre-dating workstation.

-- 
imalone
http://ibmalone.blogspot.co.uk
-- 
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: GCC5

[Peter Robinson]

>> > > http://gcc.gnu.org/gcc-5/porting_to.html → 404
>> >
>> > That will be added likely after the test mass rebuild with what we find
>> > during that.
>>
>> Do you have any estimate when it will be done? F22 schedule is/will be pretty
>> tight. We already have problem scheduling mass rebuild and I expect GCC 5
>> would require as long as possible period to fix issues/build problems. This
>
> How is that different from any other past Fedora releases (with the
> exception of F21)?  If I remember well, at least starting with GCC 4.3 (March 
> 2008)
> new GCC was deployed always in the spring release of Fedora, we've skipped
> 4.2 before that and as there was no spring release last year, GCC 4.9 was
> kind of an exception too.
>
>> time, schedule is more strict time based - what would it mean for you if
>> GCC 5 will miss F22? I'm not saying it's going to happen but it could be
>> option.
>
> Well, if we want to turn Fedora into a collection of obsolete software
> rather than trying to lead progress, we don't have to update anything.

I think that's a bit of an over reaction, ultimately F-22 is due to
branch on February 10th which is less than a month from now, the
moment it branches gcc5 could land and people are then free to rebuild
anything they like and gcc5 will be in the October release which is in
all likely hood earlier than most other distros would adopt it anyway.

> In the past, from my experience with both GCC distro maintainer and upstream
> maintainer hats, shipping GCC early in Fedora helped both projects,
> the early deployment in Fedora helped Fedora developers to use latest
> langauge features (e.g. GCC 5 will finally have C++11 compliant std::string

And how is that any different if it lands in f-23/rawhide in mid Feb?

> or std::list, and feature completeness on the C++14 language side, see
> changes.html for other stuff), help upstreams make the packages more
> portable and enjoy better generated code (e.g. if you really want to make
> PIE the default on x86_64, doing it with 4.9 is just a terribly bad idea
> because only in 5 you can actually rely on PIE copy relocs and not get hit
> as much by the PIE penalty as before), and for the GCC project lead to
> wider testing and more bugfixes.

So the feature gets delayed by a release and it gets enabled in F-23
-- 
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: Remove gcc, gcc-c++ and make from minimal build root

[Dennis Gilmore]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Wed, 14 Jan 2015 14:57:59 +0100
Miroslav Suchý  wrote:

> On 01/13/2015 06:01 PM, Dennis Gilmore wrote:
> > that all being said. koji doesn't use any caching and will not use
> > the lvm plugin. we make every buildroot from scratch using a fully
> > clean environment to help with ensuring reproducability.
> 
> You can cache and still preserve reproducability. What I'm planning
> for Copr is to do (every week/month) for chroot in fedora-20-x86_64
> fedora-21_86_64 ... ; do mock --init $chroot
>   done
> take snapshot of that. I plan to do that on VM level.
> And when new task come, I will just restore from that snapshot. And
> mock will start with already populated cache. So I will have better
> caching and yet reproducability.

you really can't.  you would need to make a new cache any time one of
the packages in the minimal buildroot changes. while it may not be
intentional you can get differences in setup and behaviour due to
scriptlets doing different things on update and initial install. to get
reproducability you would need to start with the same packages set and
get the same updates. it really is not simple to do nor to track. which
is why we purposely disable all caching.

Dennis
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBAgAGBQJUtoSFAAoJEH7ltONmPFDR4ssP/RF2a1sQ1h+M7bU6A455311X
Q1JH7h6gcBLiYlcDfDURB2EoeQTqTkyqNgXRjNIZQc9B74/DprH2Tqipz/E3dvt2
i9oRL7yyO7uzaj+Epyg0Pa1ktCz4eEqvuTdUokgQtbwtK4nkgj7O5G9ui48vCbE2
bqsLzcavQqHb/UHT1yqBiEQaTptu07u8/KFRWwTI2HNAS8naQ+07/e26OkGT+NDZ
QT2nnVPPOAd21wps5Bi2r33CZzQHwQRnUd+XcXn0hARWy+9A06T4/4x0/N8C60Rf
NgDF0RyJouIilw4Y0YGijBPMY5aQ88YljVYm5UG8foGxi2romvW0DmpNumlB+1S+
gHS27G3EgY8zdlvZcIOlOR6TLRpfFBmGEMz9JrvNNoDaKEqBlBxt55AOBRw16oFQ
Oq9jdYMq1hlIjz58812yd/Qoc0RqreMU5UVX8NxLw0GLKUeDMTWyCU+jmqKWiWnC
99DiUOTjwncZL55wjXEgFAztL9XxcsJcFuzz3WJR84RI4OUNZbpyFlJ8u1/a5iaL
JYx1j6MrkVMBjtz3W8jOQ4218feB/kiGNbm37hH+GHTeuFPTIUu/dv/eE0LSMT0T
LFLSqe6toEZrlapIEmYEuHNpLnOPg1Y/0+mAEj6PEwVKWyXKDms53rICKq3y9dw2
2fhJJ4duyZKIYSfWA8KJ
=jxfx
-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: Summary/Minutes from today's FESCo Meeting (2015-01-07)

[Dennis Gilmore]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Wed, 14 Jan 2015 10:48:16 +0100
Vít Ondruch  wrote:

> 
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
> 
> Dne 14.1.2015 v 00:24 Dennis Gilmore napsal(a):
> > On Tue, 13 Jan 2015 15:58:51 -0700
> > Kevin Fenzi  wrote:
> >
> > > On Tue, 13 Jan 2015 15:50:06 -0700
> > > Stephen John Smoogen  wrote:
> >
> > >> You forgot "too many packages?" There are 15842 packages in
> > >> Fedora 21 and 16230 in Rawhide. That is a lot of packages that
> > >> have to be rebuilt possibly multiple times due to FTBFS, multiple
> > >> architectures, etc.
> > >>
> > >> 2.5 weeks is 25200 minutes. That means a mass rebuild is doing
> > >> 0.6 packages a minute across 3 architectures. That is pretty
> > >> darn fast
> >
> > > The Fedora 21 mass rebuild took about 40 hours. ;)
> >
> > > That's really not the reason for more time, its the fallout from
> > > that. When the mass rebuild is tagged in, sometimes there's
> > > things broken in the build root, those need humans to look at and
> > > fix. Then, there are all the packages that didn't build for
> > > whatever reason, those need humans to look at them and fix them
> > > up. The ones with broken deps need fixing, etc.
> >
> > > So, while the mass rebuild itself is less than 2 days, it takes a
> > > while to stablize things after that. If we branched right after
> > > the mass rebuild we would have to then stablize both rawhide and
> > > f22.
> >
> > > It's hard to say how much time we really need there... it depends
> > > on how much stuff got broken, how hard it is to fix and how much
> > > time maintainers have to fix things.
> >
> > right. in the past the building took around a week or a bit more, we
> > have gotten that down. which is why I said we could drop the 4
> > weeks to 3. the time consuming part is the cleanup and fixing of
> > issues. that needs people. If everything is perfect a week could
> > well be sufficient. Ideally we want secondary arches to be done in
> > the window as well. just to make sure that there is no fallout on
> > them requiring a second rebuild. which could also happen on
> > primary. we have had ABI issues etc in the past on all arches.
> >
> > Dennis
> 
> What I would love to see is to leave out the packages which are build
> in side tag from mass rebuild.
> 
> E.g. if I have side tag for Ruby, I rebuild every package in the side
> tag in two weeks before mass rebuild, I can hardly see any
> justification to build them once again (unless there lands gcc in the
> man time or something like this). So if you could exclude the
> packages which are already build in side tag from mass rebuild, it
> would help you with following merge and it would give me additional
> time to rebuild Ruby packages.
> 
> Is something like this feasible?

It really depends on a lot of things. like does gcc 5 land after you
have started your builds? we can go about excluding things viaa few
different means. but it all really depends on a bunch of currently
unknown factors.

Dennis
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBAgAGBQJUtoLsAAoJEH7ltONmPFDRBp8P/RpWJ1hF3plD/zUMh6jR8bZS
frgXBJ/R9uFvLXASEAfLoaHjrALeygRCF/ZDvd5RaZz3folzXF7YYhXsAijTRiwU
vfmZj4svkJrDCU+uSWZeIC/KKmza4n4mFw8894njJCHfxggD6VupsYAoaQfWboBa
gz4mC9srLZX10KOhyPuf+5GZ+ywZbsf0ELkdYitTGVYjYWrxhHjW9pC7dLCBUk+a
4d+Y3fNHqzNzOLIhL/NASB1cJpPqTV89g5yemDjGPPojUtj2qK2IAxHIh573JfgN
dmjmAHsgOBA1GneUXLlMi/X42S9rm5gYNf+Cbr3sIhQghUUC79aeW0gG93PzTxGk
iI106UaxEYuJ/NZXWMOkHaw/pvLluo8CtneXXskGRGdPAKHGrdyqtfFP93UfDn5t
uGkJ403ESZSxkSv1sDJW9IhUdyJyVcp/tvyCHCgPnGpEz7eDEj3K52jPlLOLPmeT
nWSvw7doMBUJX0oHtbDsSGm7jt3QhAHX/ru5LsQYNARn1A406vffqYnZnN3FpVHL
Mnt9fVzm8iH/8wtz3taRQuTVOWLXyJzrq1+CTqxvkxp72sLxgRAMog+paUoD77IZ
EX/b9L65pQ4WxLAHkm4mSd0yyJb29xLNWchahqwu1w2dBTo0hX5jXlpgejFyBcPw
bRyCWm2X1sgM3p8QAqkO
=gxJf
-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

[perl-Data-Flow] Specify all dependencies

[Petr Pisar]

commit fe850d568e8d59fb2c295c191fa53ee85f7f7c50
Author: Petr Písař 
Date:   Wed Jan 14 15:46:28 2015 +0100

Specify all dependencies

 perl-Data-Flow.spec |   19 ---
 1 files changed, 12 insertions(+), 7 deletions(-)
---
diff --git a/perl-Data-Flow.spec b/perl-Data-Flow.spec
index 76a524a..f3aa2fd 100644
--- a/perl-Data-Flow.spec
+++ b/perl-Data-Flow.spec
@@ -1,6 +1,6 @@
 Name:   perl-Data-Flow
 Version:1.02
-Release:8%{?dist}
+Release:9%{?dist}
 Summary:Perl extension for simple-minded recipe-controlled build of 
data
 # Author declared license there:
 # 
@@ -9,11 +9,14 @@ Group:  Development/Libraries
 URL:http://search.cpan.org/dist/Data-Flow/
 Source0:
http://www.cpan.org/authors/id/I/IL/ILYAZ/modules/Data-Flow-%{version}.tar.gz
 BuildArch:  noarch
+BuildRequires:  perl
 BuildRequires:  perl(ExtUtils::MakeMaker)
-# Run-time
-BuildRequires:  perl(Exporter)
+# Run-time:
 BuildRequires:  perl(AutoLoader)
-Requires:   perl(:MODULE_COMPAT_%(eval "`%{__perl} -V:version`"; echo 
$version))
+BuildRequires:  perl(Exporter)
+BuildRequires:  perl(strict)
+BuildRequires:  perl(vars)
+Requires:   perl(:MODULE_COMPAT_%(eval "`perl -V:version`"; echo $version))
 
 %description
 %{summary}.
@@ -22,13 +25,12 @@ Requires:   perl(:MODULE_COMPAT_%(eval "`%{__perl} 
-V:version`"; echo $versi
 %setup -q -n Data-Flow-%{version}
 
 %build
-%{__perl} Makefile.PL INSTALLDIRS=vendor
+perl Makefile.PL INSTALLDIRS=vendor
 make %{?_smp_mflags}
 
 %install
-make pure_install PERL_INSTALL_ROOT=$RPM_BUILD_ROOT
+make pure_install DESTDIR=$RPM_BUILD_ROOT
 find $RPM_BUILD_ROOT -type f -name .packlist -exec rm -f {} \;
-find $RPM_BUILD_ROOT -depth -type d -exec rmdir {} 2>/dev/null \;
 %{_fixperms} $RPM_BUILD_ROOT/*
 
 %check
@@ -40,6 +42,9 @@ make test
 %{_mandir}/man3/*
 
 %changelog
+* Wed Jan 14 2015 Petr Pisar  - 1.02-9
+- Specify all dependencies
+
 * Wed Aug 27 2014 Jitka Plesnikova  - 1.02-8
 - Perl 5.20 rebuild
 
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel

Re: F22 System Wide Change: GCC5

[Jakub Jelinek]

On Wed, Jan 14, 2015 at 02:44:03PM +, Richard Hughes wrote:
> On 14 January 2015 at 14:37, Jonathan Underwood
>  wrote:
> > Only a partial answer to your question, but one fairly significant
> > change (as you know) compared to the GCC upgrades for those releases
> > is moving from C89 to C11 as the default C standard for the compiler
> 
> Is there any easy way for humble little upstream maintainers to test
> their code with the new compiler?

You mean for the C89 -> C11 default change, or for other changes in GCC 5?
For the former, just build with -std=gnu11 with GCC 4.9 (or 4.8).
The latter is mainly C++ or new features, so something you don't hit on
average C code.

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

Re: F22 System Wide Change: GCC5

[Richard Hughes]

On 14 January 2015 at 14:37, Jonathan Underwood
 wrote:
> Only a partial answer to your question, but one fairly significant
> change (as you know) compared to the GCC upgrades for those releases
> is moving from C89 to C11 as the default C standard for the compiler

Is there any easy way for humble little upstream maintainers to test
their code with the new compiler?

Richard
-- 
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: GCC5

[Jakub Jelinek]

On Wed, Jan 14, 2015 at 02:37:02PM +, Jonathan Underwood wrote:
> On 14 January 2015 at 14:31, Jakub Jelinek  wrote:
> > Again, how is that different from F9, F11, F13, F15, F17, F19?
> 
> Only a partial answer to your question, but one fairly significant
> change (as you know) compared to the GCC upgrades for those releases
> is moving from C89 to C11 as the default C standard for the compiler,
> which could have quite some consequences. Or do you plan to have
> -std=gnu89 added to the default compiler flags?

That is to be decided based on Mass rebuild results.
I think in many packages it means no changes needed at all, in others
only very small changes, then of course there could be packages with helplessly
obsolete codebases where -std=gnu89 will be probably the only possibility,
at least short term.
The C99->C11 step is a fairly minor, C89->C99 is bigger, but mainly for
old packages that haven't ever seen -Wmissing-prototypes or similar options.

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

Re: Summary/Minutes from today's FESCo Meeting (2015-01-07)

[Josh Boyer]

On Wed, Jan 14, 2015 at 4:32 AM, Jaroslav Reznik  wrote:
> - Original Message -
>> On Tue, 2015-01-13 at 15:58 -0700, Kevin Fenzi wrote:
>> > The Fedora 21 mass rebuild took about 40 hours. ;)
>>
>> BTW, https://fedoraproject.org/wiki/Fedora_22_Mass_Rebuild is empty.
>> What are the goals of a mass rebuild now, given that we just had one
>> before F21 Beta?
>
> This is actually that reason I liked how we constructed schedule last two
> releases - based on proposed changes, taking look what needs mass rebuild
> etc. And it could even end with no mass rebuild (or mass rebuild request
> can come on Jan-20 when the deadline for changes is). But I was alone
> who liked the old-new way and FESCo decided to set schedule the old-old
> way, I'm just the guy who puts it to the wiki :).

You aren't alone.  I'm still not convinced the strict time-based
schedule will work, but most of FESCo wanted to give it a shot.
Rather then be a stick in the mud, I went with "don't be afraid to
fail".

Who knows, maybe it will work out.  If it does, I think it's going to
change some of the things people expect from Fedora in both good and
bad ways.  Good, delivered on time.  Bad (maybe), delivered with less
cutting-edge packages.

josh
-- 
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: GCC5

[Jonathan Underwood]

On 14 January 2015 at 14:31, Jakub Jelinek  wrote:
> Again, how is that different from F9, F11, F13, F15, F17, F19?

Only a partial answer to your question, but one fairly significant
change (as you know) compared to the GCC upgrades for those releases
is moving from C89 to C11 as the default C standard for the compiler,
which could have quite some consequences. Or do you plan to have
-std=gnu89 added to the default compiler flags?
-- 
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: GCC5

[Josh Boyer]

On Wed, Jan 14, 2015 at 9:28 AM, Jakub Jelinek  wrote:
> On Wed, Jan 14, 2015 at 09:12:42AM -0500, Jaroslav Reznik wrote:
>> - Original Message -
>> > On Wed, Jan 14, 2015 at 02:55:15PM +0100, Zbigniew Jędrzejewski-Szmek 
>> > wrote:
>> > > http://gcc.gnu.org/gcc-5/porting_to.html → 404
>> >
>> > That will be added likely after the test mass rebuild with what we find
>> > during that.
>>
>> Do you have any estimate when it will be done? F22 schedule is/will be pretty
>> tight. We already have problem scheduling mass rebuild and I expect GCC 5
>> would require as long as possible period to fix issues/build problems. This
>
> How is that different from any other past Fedora releases (with the
> exception of F21)?  If I remember well, at least starting with GCC 4.3 (March 
> 2008)
> new GCC was deployed always in the spring release of Fedora, we've skipped
> 4.2 before that and as there was no spring release last year, GCC 4.9 was
> kind of an exception too.

The difference this time is that FESCo decided to set a time-based
schedule and adhere to it.  The past two releases were set based on
submitted Changes (with F21 being weird all around).  Before that, the
schedule was time-based but not strictly stuck to which led to lots of
slips.  Essentially, this is an attempt to _actually_ do a time-based
schedule.

That being said, FESCo is discussing the schedule again today because
there's no room for a mass rebuild at all.  It will be interesting to
see if they actually stick to the plan and defer any Change that
requires a mass rebuild.

josh
-- 
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: Set sshd(8) PermitRootLogin=no

[Simo Sorce]

On Wed, 14 Jan 2015 05:53:23 + (UTC)
P J P  wrote:

>   Hello Simo,
> 
> > On Wednesday, 14 January 2015 2:29 AM, Simo Sorce wrote:
> > Sorry this is false. You got enough emails telling you this
> > change is undesirable, that's the definition of opposition
> > and means you have no _consensus_.
> 
> 
>   IIUC, that was for disabling remote root access completely with
> 'PermitRootLogin=no'. As the 'PermitRootLoing=without-password'
> option seems more preferred. As for the emails, many folks have also
> said that it is a useful change.

Ok, I state my opposition to without-password too inequivocably here.
Mostly because it is just the same as 'no', given there is no way, in a
regular install to seed a key into the root account.

> IMO, the ones opposing are those who fear their current
> setups/practices would break. Because they need remote 'root' access
> in their set-up. Which is a genuine use-case. And to support it, we
> could provide an option to enable remote root access with
> 'PermitRootLogin=Yes', based on the the user's response to Anaconda
> at install time, as was suggested in previous email. However, let's
> not assume _all_ Fedora users have this use-case.

Workstation do not even enable sshd (IIRC) so this impacts the server
images (cloud images already do their magic with sshd so I am not
counting them here), and server has different use cases and security
implications than a generic population.

> - IMHO, the change helps to harden Fedora systems and raise the
> security bar a notch higher. It is similar to how we run services as
> non-root user instead of 'root' user.

I disagree that there is any similarity, and it doesn't bring security
up a notch, most ssh attempts already probe for multiple users,
preventing just root+password login is just cosmetics if
user+password+sudo can do the same operations when broken in.

If you want to do something effective against password guessing attack
there are a few much better (and easy to implement) methods:

1) require a longer root password, so that brute forcing just fail
2) implement throttling so that trying to log in as root is
slowed down considerably (and the related brute-force)
3) implement temporary black-listing, so that an IP that fails a
pre-set number of times simply gets black-list for a pre-set period of
time.

> - The proposed change of using ssh keys for remote 'root' access
> introduces that mechanism to a wider audience, which in turn would
> help increase its usage in the future. Hence bring more value in the
> long term.

Except you have no mechanism to inject a key at installation time, you
would have to implement that first, *then* you can think of changing
the default.

> - IMO, it is beneficial to supply hardened default configurations,
> because they protect maximum users and have greater impact, than
> otherwise. Security is not a feature, it must be available by default.

Security and Usability are always at odds, exceeding in one and
destroying the other is always as bad. The solution you propose only
minimally affect security, the security increase is really negligible.
But the usability is affected greatly, I think disproportionally, which
is why I am opposed to this change.
I am not against hardening, but this is just make things diofficult for
little to no gain.

> - Of course that does not mean we overlook the usability aspect. As
> said before intention is _not_ to trouble users, but increase their
> safety as much as we can.

The intention may be not, then I'll call it poor execution/planning and
still oppose this move *at this time* unless there is proof we address
the usability problem first.

Simo.

-- 
Simo Sorce * Red Hat, Inc * New York
-- 
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: GCC5

[Jakub Jelinek]

On Wed, Jan 14, 2015 at 02:24:29PM +, Peter Robinson wrote:
> On Wed, Jan 14, 2015 at 2:12 PM, Jaroslav Reznik  wrote:
> > - Original Message -
> >> On Wed, Jan 14, 2015 at 02:55:15PM +0100, Zbigniew Jędrzejewski-Szmek 
> >> wrote:
> >> > http://gcc.gnu.org/gcc-5/porting_to.html → 404
> >>
> >> That will be added likely after the test mass rebuild with what we find
> >> during that.
> >
> > Do you have any estimate when it will be done? F22 schedule is/will be 
> > pretty
> > tight. We already have problem scheduling mass rebuild and I expect GCC 5
> > would require as long as possible period to fix issues/build problems. This
> > time, schedule is more strict time based - what would it mean for you if
> > GCC 5 will miss F22? I'm not saying it's going to happen but it could be
> > option.
> 
> I was thinking exactly that, mass rebuild is scheduled for Jan 30th
> according to the schedule [1] with branching 10 days or so later. That
> is only two weeks away. With statements like "The release will happen
> probably in the first half of April" when we're already suppose to be
> be in freeze from end of March I think this would be better landing in
> F-23 right after we branch F-22 off on Feb 10th. Ultimately the above
> gives us no room to move and a roll back is another mass rebuild which
> will only cause more delay!

Again, how is that different from F9, F11, F13, F15, F17, F19?

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

Re: F22 System Wide Change: GCC5

[Jakub Jelinek]

On Wed, Jan 14, 2015 at 09:12:42AM -0500, Jaroslav Reznik wrote:
> - Original Message -
> > On Wed, Jan 14, 2015 at 02:55:15PM +0100, Zbigniew Jędrzejewski-Szmek wrote:
> > > http://gcc.gnu.org/gcc-5/porting_to.html → 404
> > 
> > That will be added likely after the test mass rebuild with what we find
> > during that.
> 
> Do you have any estimate when it will be done? F22 schedule is/will be pretty
> tight. We already have problem scheduling mass rebuild and I expect GCC 5
> would require as long as possible period to fix issues/build problems. This

How is that different from any other past Fedora releases (with the
exception of F21)?  If I remember well, at least starting with GCC 4.3 (March 
2008)
new GCC was deployed always in the spring release of Fedora, we've skipped
4.2 before that and as there was no spring release last year, GCC 4.9 was
kind of an exception too.

> time, schedule is more strict time based - what would it mean for you if
> GCC 5 will miss F22? I'm not saying it's going to happen but it could be
> option.

Well, if we want to turn Fedora into a collection of obsolete software
rather than trying to lead progress, we don't have to update anything.
In the past, from my experience with both GCC distro maintainer and upstream
maintainer hats, shipping GCC early in Fedora helped both projects,
the early deployment in Fedora helped Fedora developers to use latest
langauge features (e.g. GCC 5 will finally have C++11 compliant std::string
or std::list, and feature completeness on the C++14 language side, see
changes.html for other stuff), help upstreams make the packages more
portable and enjoy better generated code (e.g. if you really want to make
PIE the default on x86_64, doing it with 4.9 is just a terribly bad idea
because only in 5 you can actually rely on PIE copy relocs and not get hit
as much by the PIE penalty as before), and for the GCC project lead to
wider testing and more bugfixes.

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

Re: F22 System Wide Change: GCC5

[Peter Robinson]

On Wed, Jan 14, 2015 at 2:12 PM, Jaroslav Reznik  wrote:
> - Original Message -
>> On Wed, Jan 14, 2015 at 02:55:15PM +0100, Zbigniew Jędrzejewski-Szmek wrote:
>> > http://gcc.gnu.org/gcc-5/porting_to.html → 404
>>
>> That will be added likely after the test mass rebuild with what we find
>> during that.
>
> Do you have any estimate when it will be done? F22 schedule is/will be pretty
> tight. We already have problem scheduling mass rebuild and I expect GCC 5
> would require as long as possible period to fix issues/build problems. This
> time, schedule is more strict time based - what would it mean for you if
> GCC 5 will miss F22? I'm not saying it's going to happen but it could be
> option.

I was thinking exactly that, mass rebuild is scheduled for Jan 30th
according to the schedule [1] with branching 10 days or so later. That
is only two weeks away. With statements like "The release will happen
probably in the first half of April" when we're already suppose to be
be in freeze from end of March I think this would be better landing in
F-23 right after we branch F-22 off on Feb 10th. Ultimately the above
gives us no room to move and a roll back is another mass rebuild which
will only cause more delay!

Peter

[1] https://fedoraproject.org/wiki/Releases/22/Schedule
-- 
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: Wine to use mesa Direct3D

[Michael Cronenworth]

On 01/14/2015 06:28 AM, Jaroslav Reznik wrote:
[snip]

* Contingency mechanism: Revert and try to do in next release


I don't see this one happening. The patch set is large. Upstream has rejected 
it. The affected user base is small. I'm unconvinced right now that it's worth 
the time and effort to maintain.


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

[Jaroslav Reznik]

- Original Message -
> On Wed, Jan 14, 2015 at 02:55:15PM +0100, Zbigniew Jędrzejewski-Szmek wrote:
> > http://gcc.gnu.org/gcc-5/porting_to.html → 404
> 
> That will be added likely after the test mass rebuild with what we find
> during that.

Do you have any estimate when it will be done? F22 schedule is/will be pretty
tight. We already have problem scheduling mass rebuild and I expect GCC 5
would require as long as possible period to fix issues/build problems. This
time, schedule is more strict time based - what would it mean for you if
GCC 5 will miss F22? I'm not saying it's going to happen but it could be
option.

Jaroslav

>   Jakub
> --
> devel mailing list
> devel@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/devel
> Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
-- 
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: GCC5

[Jakub Jelinek]

On Wed, Jan 14, 2015 at 02:55:15PM +0100, Zbigniew Jędrzejewski-Szmek wrote:
> http://gcc.gnu.org/gcc-5/porting_to.html → 404

That will be added likely after the test mass rebuild with what we find
during that.

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

Re: F22 System Wide Change: GCC5

[Zbigniew Jędrzejewski-Szmek]

On Wed, Jan 14, 2015 at 02:55:15PM +0100, Zbigniew Jędrzejewski-Szmek wrote:
> On Wed, Jan 14, 2015 at 12:53:18PM +0100, Jaroslav Reznik wrote:
> > = Proposed System Wide Change: GCC5 =
> > https://fedoraproject.org/wiki/Changes/GCC5
> > 
> > Change owner(s):  Jakub Jelínek 
> > 
> > Switch GCC in Fedora 22 to 5.x.y, rebuild all packages with it.
> > 
> > == Detailed Description ==
> > GCC 5 is currently in stage3, but in 3 days will move to stage4, in 
> > prerelease 
> > state with only regression bugfixes and documentation fixes allowed. The 
> > release 
> > will happen probably in the first half of April. We are working on scratch 
> > gcc 
> > rpms and will perform a test mass rebuild. Other distributions have 
> > performed 
> > test mass rebuilds already. 
> > 
> > == Scope ==
> > All packages should be rebuilt with the new gcc once it hits f22.
> > 
> > * Proposal owners: Build gcc in f22, rebuild packages that have direct 
> > dependencies on exact gcc version (libtool, llvm, gcc-python-plugin).
> > 
> > * Other developers: First few days/weeks just voluntary rebuilds using the 
> > new 
> > system gcc, if things fail, look at
> 
> http://gcc.gnu.org/gcc-5/porting_to.html → 404
> 
> (also on the wiki)
BTW: is there a copr or another place to get gcc5 without compiling from source?
-- 
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: Summary/Minutes from today's FESCo Meeting (2015-01-07)

[Kevin Fenzi]

On Wed, 14 Jan 2015 01:53:02 -0600
Yaakov Selkowitz  wrote:

> On Tue, 2015-01-13 at 15:58 -0700, Kevin Fenzi wrote:
> > The Fedora 21 mass rebuild took about 40 hours. ;) 
> 
> BTW, https://fedoraproject.org/wiki/Fedora_22_Mass_Rebuild is empty.
> What are the goals of a mass rebuild now, given that we just had one
> before F21 Beta?

We don't yet know. Changes are still being submitted and discussed and
reviewed by FESCo. Until the change submission deadline + 1 week we
will not have a full list of changes and be able to tell if a mass
rebuild is needed and for what. 

There are of course already some changes that call for one... like
enabling hardened_build for all packages and gcc 5.0. 

kevin


pgp3PVu7aP2WI.pgp
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: Remove gcc, gcc-c++ and make from minimal build root

[Miroslav Suchý]

On 01/13/2015 06:01 PM, Dennis Gilmore wrote:
> that all being said. koji doesn't use any caching and will not use the
> lvm plugin. we make every buildroot from scratch using a fully clean
> environment to help with ensuring reproducability.

You can cache and still preserve reproducability. What I'm planning for Copr is 
to do (every week/month)
  for chroot in fedora-20-x86_64 fedora-21_86_64 ... ; do
mock --init $chroot
  done
take snapshot of that. I plan to do that on VM level.
And when new task come, I will just restore from that snapshot. And mock will 
start with already populated cache. So I
will have better caching and yet reproducability.


-- 
Miroslav Suchy, RHCE, RHCDS
Red Hat, Senior Software Engineer, #brno, #devexp, #fedora-buildsys
-- 
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: GCC5

[Zbigniew Jędrzejewski-Szmek]

On Wed, Jan 14, 2015 at 12:53:18PM +0100, Jaroslav Reznik wrote:
> = Proposed System Wide Change: GCC5 =
> https://fedoraproject.org/wiki/Changes/GCC5
> 
> Change owner(s):  Jakub Jelínek 
> 
> Switch GCC in Fedora 22 to 5.x.y, rebuild all packages with it.
> 
> == Detailed Description ==
> GCC 5 is currently in stage3, but in 3 days will move to stage4, in 
> prerelease 
> state with only regression bugfixes and documentation fixes allowed. The 
> release 
> will happen probably in the first half of April. We are working on scratch 
> gcc 
> rpms and will perform a test mass rebuild. Other distributions have performed 
> test mass rebuilds already. 
> 
> == Scope ==
> All packages should be rebuilt with the new gcc once it hits f22.
> 
> * Proposal owners: Build gcc in f22, rebuild packages that have direct 
> dependencies on exact gcc version (libtool, llvm, gcc-python-plugin).
> 
> * Other developers: First few days/weeks just voluntary rebuilds using the 
> new 
> system gcc, if things fail, look at

http://gcc.gnu.org/gcc-5/porting_to.html → 404

(also on the wiki)

Zbyszek
-- 
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: Wine to use mesa Direct3D

[David Howells]

Jaroslav Reznik  wrote:

> Gallium Nine implements the d3d9 API with Gallium 
> internal API, which maps better to d3d9 than OpenGL.

Does it pass D3D9 requests down to the graphics card where possible?

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

Meeting minutes for Env-and-Stacks WG meeting (2015-01-14)

[Honza Horak]

#fedora-meeting: Env and Stacks (2015-01-14)



Meeting started by hhorak at 12:01:10 UTC. The full logs are available
at
http://meetbot.fedoraproject.org/fedora-meeting/2015-01-14/env-and-stacks.2015-01-14-12.01.log.html
.



Meeting summary
---
* hello-ing  (hhorak, 12:01:44)

* Fedora Rings  (hhorak, 12:03:21)
  * LINK: http://mattdm.org/fedora/next/#15   (hhorak, 12:05:39)
  * LINK: http://mattdm.org/fedora/next/#20   (hhorak, 12:05:40)
  * there is no clear sense of the details of each ring.. e.g.
definition, type of things in the ring, loose guidelines, users'
expectations, motivation to use the rings  (hhorak, 12:18:13)
  * IDEA: ring2 may be split into ring 2 and ring 3 - the new ring 2
should contain only system high-level stacks (we'll always need
system versions of e.g. interpreted langauges) and ring 3 should
contain copr/playground and possibly also upstream-type of repos
(hhorak, 12:18:17)
  * ring 0 is a minimal bootable system - basically the domain of the
Base WG  (hhorak, 12:33:37)
  * IDEA: question is what can be moved out of ring 1 to ring 2?
(hhorak, 12:40:13)
  * IDEA: the "promotion" idea.. as in ... the lower the number of ring
the higher quality of the package and the more it must be maintained
(hhorak, 12:40:13)
  * IDEA: definition of ring 1 is a minimal set of packages that give
you a functional system, with some sort of approval  (hhorak,
13:31:21)
  * IDEA: ring 1 should be self-hosted -- because you want to build very
solid important packages using very solid important packages
(hhorak, 13:31:21)
  * IDEA: WG-wkstn may want to package httpd differently than WG-server
-- that could be solved on configuration - level like httpd-dev and
httpd-prod  (hhorak, 13:31:21)
  * IDEA: then ring 2 includes clean/good pkgs of other stuff; ring 3
good pkgs but not complete; ring 4 any old stuff  (hhorak, 13:32:31)
  * IDEA: topic for ML or some of the next meetings: setting some
technical expectations about how to differ ring 0, 1, 2..  (hhorak,
13:40:44)
  * IDEA: topic for ML or some of the next meetings: look more closely
on users' wok-flow -- say he wants to develop or use some app from
ring X -- what it actually means in practice..  (hhorak, 13:40:44)

Meeting ended at 13:45:30 UTC.




Action Items






Action Items, by person
---
* **UNASSIGNED**
  * (none)




People Present (lines said)
---
* juhp_ (69)
* bkabrda (64)
* langdon (50)
* hhorak (45)
* vpavlin (28)
* zodbot (4)
* jzeleny-mtg (1)
* samkottler (0)
* tjanez (0)
* sicampbell (0)
* juhp (0)
* ncoghlan (0)
* pkovar (0)




Generated by `MeetBot`_ 0.1.4

.. _`MeetBot`: http://wiki.debian.org/MeetBot
--
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: GUI applications writing garbage to stdout/stderr

[Zbigniew Jędrzejewski-Szmek]

On Wed, Jan 14, 2015 at 11:22:57AM +0100, Marcel Oliver wrote:
> Hallo,
> 
> there is one more thing which I found really annoying after upgrading
> to F21.  I like to launch GUI applications from the command line (I
> know there is some debate on whether this habit makes me a target user
> of Fedora, but I am writing under the assumption that it might).
> 
> Many GUI applications write garbage to either stdout or stderr, making
> the terminal windows difficult to view and navigate.  I have seen this
> on earlier releases, too, but the volume being written and the number
> of applications affected has increased to the extent that it is
> becoming a real problem.
> 
> Some, like nemo, even keep writing messages during operation, which is
> very distracting as there is sudden movement in the corner of one's
> eye. 
> 
> Yes, I know that I could write, for example
> 
>   okular file.pdf &> /dev/null
> 
> but that somehow defeats the efficiency of the command line operation.
> 
> Some of the main culprints for me are nemo, evince, and okular; if I
> am go looking, I can probably find many more.  The only well-behaved
> application I know is libreoffice.
> 
> Are these considered bugs that I should file against the package?  Is
> there a policy that applies?
I think you should. I regularly file bugs against packages writing to
the console during boot, logging random things at
warning/error/critical/or higher syslog levels, which is not visible
during graphical boot but affects people booting in text mode or
looking at logs and they usually get fixed as any other bug. The issue
of things being dumped to the console is similar — usability of the
distribution for command-line usage.

When I run okular I see:

Connecting to deprecated signal 
QDBusConnectionInterface::serviceOwnerChanged(QString,QString,QString)
kbuildsycoca4 running...
okular(16844) KMimeTypeRepository::parents: "/usr/share/mime/subclasses"  
refers to unknown mimetype  
"application/vnd.ms-excel.sheet.binary.macroEnabled.12" 
okular(16844) KMimeTypeRepository::parents: "/usr/share/mime/subclasses"  
refers to unknown mimetype  "application/vnd.ms-excel.addin.macroEnabled.12" 
okular(16844) KMimeTypeRepository::parents: "/usr/share/mime/subclasses"  
refers to unknown mimetype  
"application/vnd.ms-powerpoint.slideshow.macroEnabled.12" 
okular(16844) KMimeTypeRepository::parents: "/usr/share/mime/subclasses"  
refers to unknown mimetype  "application/vnd.ms-excel.sheet.macroEnabled.12" 
okular(16844) KMimeTypeRepository::parents: "/usr/share/mime/subclasses"  
refers to unknown mimetype  
"application/vnd.ms-powerpoint.presentation.macroEnabled.12" 
okular(16844) KMimeTypeRepository::parents: "/usr/share/mime/subclasses"  
refers to unknown mimetype  "application/vnd.ms-word.template.macroEnabled.12" 
okular(16844) KMimeTypeRepository::parents: "/usr/share/mime/subclasses"  
refers to unknown mimetype  "application/vnd.ms-excel.template.macroEnabled.12" 
okular(16844) KMimeTypeRepository::parents: "/usr/share/mime/subclasses"  
refers to unknown mimetype  
"application/vnd.ms-powerpoint.template.macroEnabled.12" 
okular(16844) KMimeTypeRepository::parents: "/usr/share/mime/subclasses"  
refers to unknown mimetype  "application/vnd.ms-word.document.macroEnabled.12" 
okular(16844) KMimeTypeRepository::parents: "/usr/share/mime/subclasses"  
refers to unknown mimetype  
"application/vnd.ms-powerpoint.slide.macroEnabled.12" 
QInotifyFileSystemWatcherEngine::addPaths: inotify_add_watch failed: Nie ma 
takiego pliku ani katalogu
QFileSystemWatcher: failed to add paths: 
/home/zbyszek/.kde/share/config/activitymanager-pluginsrc

This is an issue. It either ends up on the terminal or in the logs. When
looking through logs to diagnose a problem this kind of garbage is very
annoying. Especially repeating the same message over and over should be
fixed.

On Wed, Jan 14, 2015 at 12:00:49PM +0100, François Cami wrote:
> Quoting https://fedoraproject.org/wiki/Staying_close_to_upstream_projects
> : "The Fedora Project focuses, as much as possible, on not deviating
> from upstream in the software it includes in the repository. " - and
> patching upstream software to not write to stdout or stderr would be
> such a change, IMHO.
>
> I would therefore file bugs at upstream bug report tools, not against
> Fedora packages.
> For instance, in evince's case, see
> https://wiki.gnome.org/Apps/Evince/ReportingBugs
Nah, uses can file bugs in Fedora, maintainers will forward them upstream
if necessary.

Zbyszek
-- 
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: Gnome Shell - New Notifications

[Peter Robinson]

On Wed, Jan 14, 2015 at 1:17 PM, Pierre-Yves Chibon  wrote:
> On Wed, Jan 14, 2015 at 01:00:27PM +0100, Jaroslav Reznik wrote:
>> = Proposed Self Contained Change: Gnome Shell - New Notifications =
>> https://fedoraproject.org/wiki/Changes/GnomeShell_NewNotifications
>>
>> Change owner(s): Florian Müllner 
>>
>> Redesign the way in which notifications are shown and kept available in 
>> gnome-
>> shell.
>>
>> == Detailed Description ==
>> The message tray is one of the remaining weaker points of the original gnome-
>> shell design. This change will replace it with a new implementation of
>> notifications that avoids the problems of the current implementation.
>
> Is there a place where the detailed description is more detailed?
> A wiki page on gnome.org maybe listing the current problems and the new 
> approach
> taken?
> I'm curious and would like to read more about this :)

Allan Day, one of the gnome designers, did a pretty good overview in a
couple of blog posts.

http://blogs.gnome.org/aday/2014/06/18/a-notifications-update/

Peter
-- 
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: Gnome Shell - New Notifications

[Pierre-Yves Chibon]

On Wed, Jan 14, 2015 at 01:00:27PM +0100, Jaroslav Reznik wrote:
> = Proposed Self Contained Change: Gnome Shell - New Notifications =
> https://fedoraproject.org/wiki/Changes/GnomeShell_NewNotifications
> 
> Change owner(s): Florian Müllner  
> 
> Redesign the way in which notifications are shown and kept available in gnome-
> shell. 
> 
> == Detailed Description ==
> The message tray is one of the remaining weaker points of the original gnome-
> shell design. This change will replace it with a new implementation of 
> notifications that avoids the problems of the current implementation. 

Is there a place where the detailed description is more detailed?
A wiki page on gnome.org maybe listing the current problems and the new approach
taken?
I'm curious and would like to read more about this :)

Thanks,
Pierre
-- 
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: Wine to use mesa Direct3D

[Pasi Kärkkäinen]

Hey, 

On Wed, Jan 14, 2015 at 01:28:57PM +0100, Jaroslav Reznik wrote:
> = Proposed Self Contained Change: Wine to use mesa Direct3D =
> https://fedoraproject.org/wiki/Changes/Wine_to_use_mesa_Direct3D
> 
> Change owner(s): Igor Gnatenko  
> 
> Enhancing mesa and wine with Direct3D9 support will increase performance and 
> reduce resource usage in applications which using D3D9 framework. 
> 
> == Detailed Description ==
> When playing d3d9 games on Wine, their d3d9 calls are translated to OpenGL. 
> This is complicated process, because you have to deal with different drivers 
> having different extensions available, and the fact that opengl and d3d9 
> don't 
> map perfectly together. Gallium Nine implements the d3d9 API with Gallium 
> internal API, which maps better to d3d9 than OpenGL. You remove some layers 
> of 
> translation in the process which enables better performance. Gallium Nine is 
> not as mature as Wine OpenGL translation, and it is likely to have more bugs, 
> but when the games work, you can expect 5-10% improvement for gpu limited 
> games, or much more (sometimes 100%) for cpu limited games.
> 
> what is Gallium: Gallium is an internal graphic driver abstraction of Mesa to 
> enable support of non-opengl languages more easily (it is used for vdpau and 
> vaapi on r600/radeonsi for example). It is used by nouveau and r300 up to 
> radeonsi for AMD. Intel OpenGL support doesn't use gallium, but a gallium 
> driver named ilo exists, but isn't sponsored by Intel.
> 
> In practice, games have also smoother frame rate on Gallium Nine. Gallium 
> Nine 
> has good DRI_PRIME support, and if you have a system with an iGPU+dGPU, you 
> can play without issues with the parameters DRI_PRIME=1 thread_submit=true
> 
> https://wiki.ixit.cz/d3d9 
>

The wiki link doesn't seem to work..

Is it possible for the user to tell wine which backend to use? OpenGL or 
Gallium-Nine ? 


-- Pasi
 

-- 
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: A little problem with dnf

[Radek Holy]

- Original Message -
> From: "Adrian Soliard" 
> To: "Development discussions related to Fedora" 
> 
> Sent: Tuesday, January 13, 2015 1:09:43 PM
> Subject: Re: A little problem with dnf
> 
> 2015-01-13 6:33 GMT-03:00 Radek Holy :
> > - Original Message -
> >> From: "Jan Zelený" 
> >> To: devel@lists.fedoraproject.org
> >> Sent: Tuesday, January 13, 2015 8:33:21 AM
> >> Subject: Re: A little problem with dnf
> >>
> >> On 12. 1. 2015 at 07:55:26, Adrian Soliard wrote:
> >> > 2015-01-12 5:35 GMT-03:00 Igor Gnatenko :
> >> > > On Mon, Jan 12, 2015 at 11:27 AM, Jan Zelený 
> >> > > wrote:
> >> > >> On 11. 1. 2015 at 20:40:56, Adrian Soliard wrote:
> >> > >>> Hi everyone!
> >> > >>>
> >> > >>>I'm struggling a bit with dnf. It may have advantages, but as an
> >> > >>>
> >> > >>> end-user, I'm fighting with the list of packages when I press TAB.
> >> > >>> It's complicated, if I forget to install a specific package, dnf
> >> > >>> wouldn't show it to me, yum do it [1].
> >> > >>>
> >> > >>> I know that dnf is newer, and surely will improve, I'm just writing
> >> > >>> to
> >> > >>> let seated such problem.
> >> > >>>
> >> > >>> [1] http://asoliard.fedorapeople.org/dnf.png
> >> > >>
> >> > >> What happens when you press "y"? Does it show you the completions
> >> > >> then?
> >> > >> I
> >> > >> have just tried it and the list seems to be correct to me - it's just
> >> > >> quite long because there are many packages starting with "eclipse"
> >> >
> >> > If I press "y" it show me a list of coincidence, but It don't matter
> >> > if is installed or not.
> >> >
> >> > >> In any case if you think there is something wrong with dnf, we
> >> > >> encourage
> >> > >> you to file a bug but this doesn't seem to be the case.
> >> >
> >> > I know, that's not a problem, I'm not going to open a bug for this.;
> >> > But I think is good to know, as I said before, dnf is newer than yum,
> >> > it will improve
> >> >
> >> > > This will happens, because installed packages is available packages I
> >> > > think and we relying completion on available packages.
> >> >
> >> > Try it: Install a package (a simple package, like "homebank"), and
> >> > then write "dnf install homeba" and TAB.
> >> > dnf will autocomplete "homebank", and you already has installed it.
> >>
> >> Ah I didn't get what the problem was. Now I can see the problem and
> >> reproduce
> >> it. Not a big deal but should be fixed somewhere down the road. I would
> >> still
> >> like to ask you to file a bug so this doesn't get lost in the swamp of
> >> other
> >> bugs and enhancements we work on.
> >
> 
> Ok, I will consider sending a bug, as you say, It's not a big deal,
> but, in this case, I'm looking for different packages with yum, dnf
> returns a long list of eclipse* packages, even if installed.
> 
> > BTW, in case of YUM, it would make sense to suggest even installed packages
> > because "yum install homebank" means "install the latest homebank or
> > upgrade to the latest version of homebank".
> 
> The problem is that when you press TAB to autocomplete, dnf returns a
> list with all packages, and yum exclude the installed ones.

I understand your problem. My point was that people who are used type "yum 
install pkg" instead of "yum upgrade pkg" (even when they want to upgrade an 
already installed package) wouldn't consider it a bug.
-- 
Radek Holý
Associate Software Engineer
Software Management Team
Red Hat Czech
-- 
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: GCC5

[Jakub Jelinek]

On Wed, Jan 14, 2015 at 01:34:26PM +0100, Dan Horák wrote:
> On Wed, 14 Jan 2015 12:53:18 +0100
> Jaroslav Reznik  wrote:
> 
> > = Proposed System Wide Change: GCC5 =
> > https://fedoraproject.org/wiki/Changes/GCC5
> > 
> > Change owner(s):  Jakub Jelínek 
> > 
> > Switch GCC in Fedora 22 to 5.x.y, rebuild all packages with it.
> > 
> > == Detailed Description ==
> > GCC 5 is currently in stage3, but in 3 days will move to stage4, in 
> > prerelease 
> > state with only regression bugfixes and documentation fixes allowed. The 
> > release 
> > will happen probably in the first half of April. We are working on scratch 
> > gcc 
> > rpms and will perform a test mass rebuild. Other distributions have 
> > performed 
> > test mass rebuilds already. 
> 
> on what architectures and with which results? How can we help to avoid
> issues with s390, ppc or aarch64 like we saw with gcc 4.9 and s390?

Depends on what kind of issues.  If it is something detected during the mass
rebuild (ICEs, failures in package testsuite), you can gain a few days/weeks by
doing a test mass rebuild on the arches where you fear that (the plan was to do
just x86-64 test mass rebuild ourselves); the question is if there is beefy
enough hardware with spare cycles for that.
If it is something that can be detected only when running the distro, then
somebody would need to also install and try the test mass rebuilt distro, or
just let stuff be fixed after mass rebuild.  If there are GCC bugs that need
to be resolved, the better bugreports the less time we need to spend on
testcase reduction and analysis and the more we can spend on actual bug
fixing.

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

Re: Remove gcc, gcc-c++ and make from minimal build root

[Vít Ondruch]

Dne 13.1.2015 v 18:20 Vít Ondruch napsal(a):
> Dne 13.1.2015 v 18:09 Vít Ondruch napsal(a):
>> Dne 13.1.2015 v 17:54 Vít Ondruch napsal(a):
> So lets try to find what is written in C/C++ by some different way. Is
> that true, that every package in C/C++ compiled using gcc depends on
> glibc? Then we can use this query to get the number of packages:
>
> $ repoquery --source --whatrequires 'libc.so.6(GLIBC_2.4)(64bit)' | sort
> | uniq | wc -l
> 2834
>> The additional sed should remove the duplicated versions:
>>
>> $ repoquery --source --whatrequires 'libc.so.6(GLIBC_2.4)(64bit)' | sort
>> -u | sed -r 's/(.*)-.*-.*/\1/' | uniq | wc -l
>> 2645
>>
> And the wildcard in libc makes the difference :) So these seems to be
> numbers for Rawhide:
>
> $ repoquery --disablerepo=* --enablerepo=rawhide --source --whatrequires
> 'libc.so.6*' | sort -u | sed -r 's/(.*)-.*-.*/\1/' | uniq | wc -l
> 7402
>
> $ dnf repoquery --disablerepo=* --enablerepo=rawhide-source --arch src
> '*' | wc -l
> 16230
>
> I.e. 45.6 % of packages seems to be written in C/C++

And it seems that this is the number of packages written in C++:

$ repoquery --disablerepo=* --enablerepo=rawhide --source --whatrequires
'libstdc++.so.6*' | sort -u | sed -r 's/(.*)-.*-.*/\1/' | uniq | wc -l
2396

I'd like to point out at this place, that this would help also the 5006
packages written in C, since they don't need C++ to build. Only 14.8 %
of packages, which happens to be written in C++, would not benefit from
this change.


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 System Wide Change: GCC5

[Dan Horák]

On Wed, 14 Jan 2015 12:53:18 +0100
Jaroslav Reznik  wrote:

> = Proposed System Wide Change: GCC5 =
> https://fedoraproject.org/wiki/Changes/GCC5
> 
> Change owner(s):  Jakub Jelínek 
> 
> Switch GCC in Fedora 22 to 5.x.y, rebuild all packages with it.
> 
> == Detailed Description ==
> GCC 5 is currently in stage3, but in 3 days will move to stage4, in 
> prerelease 
> state with only regression bugfixes and documentation fixes allowed. The 
> release 
> will happen probably in the first half of April. We are working on scratch 
> gcc 
> rpms and will perform a test mass rebuild. Other distributions have performed 
> test mass rebuilds already. 

on what architectures and with which results? How can we help to avoid
issues with s390, ppc or aarch64 like we saw with gcc 4.9 and s390?


Dan
-- 
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: Wine to use mesa Direct3D

[Jaroslav Reznik]

= Proposed Self Contained Change: Wine to use mesa Direct3D =
https://fedoraproject.org/wiki/Changes/Wine_to_use_mesa_Direct3D

Change owner(s): Igor Gnatenko  

Enhancing mesa and wine with Direct3D9 support will increase performance and 
reduce resource usage in applications which using D3D9 framework. 

== Detailed Description ==
When playing d3d9 games on Wine, their d3d9 calls are translated to OpenGL. 
This is complicated process, because you have to deal with different drivers 
having different extensions available, and the fact that opengl and d3d9 don't 
map perfectly together. Gallium Nine implements the d3d9 API with Gallium 
internal API, which maps better to d3d9 than OpenGL. You remove some layers of 
translation in the process which enables better performance. Gallium Nine is 
not as mature as Wine OpenGL translation, and it is likely to have more bugs, 
but when the games work, you can expect 5-10% improvement for gpu limited 
games, or much more (sometimes 100%) for cpu limited games.

what is Gallium: Gallium is an internal graphic driver abstraction of Mesa to 
enable support of non-opengl languages more easily (it is used for vdpau and 
vaapi on r600/radeonsi for example). It is used by nouveau and r300 up to 
radeonsi for AMD. Intel OpenGL support doesn't use gallium, but a gallium 
driver named ilo exists, but isn't sponsored by Intel.

In practice, games have also smoother frame rate on Gallium Nine. Gallium Nine 
has good DRI_PRIME support, and if you have a system with an iGPU+dGPU, you 
can play without issues with the parameters DRI_PRIME=1 thread_submit=true

https://wiki.ixit.cz/d3d9 

== Scope ==
* Proposal owners: work on the Mesa Direct3D support 
* 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) 

== Contingency Plan ==
* Contingency mechanism: Revert and try to do in next release
* Contingency deadline: beta freeze 
* Blocks release? N/A (not a System Wide Change) 
* Blocks product? 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

F22 Self Contained Change: Nautilus Improvements

[Jaroslav Reznik]

= Proposed Self Contained Change: Nautilus Improvements =
https://fedoraproject.org/wiki/Changes/Nautilus_Improvements

Change owner(s): Carlos Soriano  

Tie up some of the loose ends that were leftover after the nautilus design 
refresh work that has happened a while ago. 

== Detailed Description ==
The nautilus code base will be cleaned up by porting it from the deprecated 
GtkAction APIs to GAction. As part of this, the view, gear and app menus will 
be updated to match the current designs. In addition, several long-standing 
annoyances will be addressed, such as the problematic floating statusbar, and 
the keyboard shortcut for deleting files. 

== Scope ==
* Proposal owners:
** Get the [1] branch reviewed and merged (in progress)
** Write a patch to change from Ctrl-Delete to Delete with an undo notification 
(bug [2])
** Implement a different solution for the floating statusbar

* 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)

== Contingency Plan ==
N/A (not a System Wide Change)

[1] https://git.gnome.org/browse/nautilus/log/?h=wip/gaction wip/gaction
[2] https://bugzilla.gnome.org/show_bug.cgi?id=648658
___
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: Gnome Shell - New Notifications

[Jaroslav Reznik]

= Proposed Self Contained Change: Gnome Shell - New Notifications =
https://fedoraproject.org/wiki/Changes/GnomeShell_NewNotifications

Change owner(s): Florian Müllner  

Redesign the way in which notifications are shown and kept available in gnome-
shell. 

== Detailed Description ==
The message tray is one of the remaining weaker points of the original gnome-
shell design. This change will replace it with a new implementation of 
notifications that avoids the problems of the current implementation. 

== Scope ==
* Proposal owners:
** Implement the new design
** Get the changes reviewed and merged upstream

* 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) 

== Contingency Plan ==
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: F22 System Wide Change: GCC5

[Vít Ondruch]

Dne 14.1.2015 v 12:53 Jaroslav Reznik napsal(a):
> = Proposed System Wide Change: GCC5 =
> https://fedoraproject.org/wiki/Changes/GCC5
>
> Change owner(s):  Jakub Jelínek 
>
> Switch GCC in Fedora 22 to 5.x.y, rebuild all packages with it.
>
> == Detailed Description ==
> GCC 5 is currently in stage3, but in 3 days will move to stage4, in 
> prerelease 
> state with only regression bugfixes and documentation fixes allowed. The 
> release 
> will happen probably in the first half of April. We are working on scratch 
> gcc 
> rpms and will perform a test mass rebuild. Other distributions have performed 
> test mass rebuilds already. 
>
> == Scope ==
> All packages should be rebuilt with the new gcc once it hits f22.
>
> * Proposal owners: Build gcc in f22, rebuild packages that have direct 
> dependencies on exact gcc version (libtool, llvm, gcc-python-plugin).
>
> * Other developers: First few days/weeks just voluntary rebuilds using the 
> new 
> system gcc, if things fail, look at http://gcc.gnu.org/gcc-5/porting_to.html 
> and fix bugs in packages or, if there is a gcc bug or suspected gcc bug, 
> analyze and report.

Ah, few days/weeks. Now I really can't see how this will fit into schedule.


Vít


>  
>
> * Release engineering: Organize a mass rebuild 
> * Policies and guidelines: No policies need to be changed 
>
> == Contingency Plan ==
> If bugs are discovered, I'd appreciate help from the package owners in 
> preparing self-contained testcases to speed up analysis and fixing the bugs. 
> Don't have time to debug issues in 12000+ packages, especially when in many 
> cases it could be caused by undefined code in the packages etc. I don't 
> expect 
> we'll have to fall back to the older gcc, we've never had to do it in the 
> past, but worst case we can mass rebuild everything with older gcc again.
>
> * Contingency mechanism: Revert to older gcc, mass rebuild everything again
> * Contingency deadline: Before release
> * Blocks release? Yes
> * 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

F22 System Wide Change: GCC5

[Jaroslav Reznik]

= Proposed System Wide Change: GCC5 =
https://fedoraproject.org/wiki/Changes/GCC5

Change owner(s):  Jakub Jelínek 

Switch GCC in Fedora 22 to 5.x.y, rebuild all packages with it.

== Detailed Description ==
GCC 5 is currently in stage3, but in 3 days will move to stage4, in prerelease 
state with only regression bugfixes and documentation fixes allowed. The 
release 
will happen probably in the first half of April. We are working on scratch gcc 
rpms and will perform a test mass rebuild. Other distributions have performed 
test mass rebuilds already. 

== Scope ==
All packages should be rebuilt with the new gcc once it hits f22.

* Proposal owners: Build gcc in f22, rebuild packages that have direct 
dependencies on exact gcc version (libtool, llvm, gcc-python-plugin).

* Other developers: First few days/weeks just voluntary rebuilds using the new 
system gcc, if things fail, look at http://gcc.gnu.org/gcc-5/porting_to.html 
and fix bugs in packages or, if there is a gcc bug or suspected gcc bug, 
analyze and report. 

* Release engineering: Organize a mass rebuild 
* Policies and guidelines: No policies need to be changed 

== Contingency Plan ==
If bugs are discovered, I'd appreciate help from the package owners in 
preparing self-contained testcases to speed up analysis and fixing the bugs. 
Don't have time to debug issues in 12000+ packages, especially when in many 
cases it could be caused by undefined code in the packages etc. I don't expect 
we'll have to fall back to the older gcc, we've never had to do it in the 
past, but worst case we can mass rebuild everything with older gcc again.

* Contingency mechanism: Revert to older gcc, mass rebuild everything again
* Contingency deadline: Before release
* Blocks release? Yes
* 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: Content of change announcements Was:F22 System Wide Change: RpmOstree - Server side composes and atomic upgrades

[Jaroslav Reznik]

- Original Message -
> On Tue, Jan 13, 2015 at 3:27 PM, Miloslav Trmač  wrote:
> >> Jaroslav, there is a lot more information on the actual wiki page.
> >> Like the fact that this is only for particular opt-in new installs and
> >> that yum/dnf/RPM can only operate in read-only mode on such installs.
> >> Could you resend this with the entirety of the text?  It might lead to
> >> fewer questions.
> >
> > This is being sent to devel-announce, so should not overwhelm people who
> > are not interested.  That’s why it includes the basic description (to let
> > you decide whether you are interested) and the Scope section (to let you
> > check whether this will, through the “Other developers” bullet point,
> > place demands on you).  It is somewhat important that everybody reads
> > these parts; wouldn’t including the full page drown these parts out?
> 
> No.  People can stop reading wherever they'd like.  Omitting relevant
> information from the actual Change page makes it rather difficult to
> _discuss_ the Change on the devel list, which is the main reason they
> are sent.  Doing the discussion on the wiki is terrible.  I would much
> rather be able to quote the sections via email.

Actually it was Mitr who asked me first to add more parts into email
announcement but then we talked about it - and I think current way is
a good compromise - to give overview of change but not to overload
people with two many details. Also it really depends on how change is
filled, usually detailed description and scope are that parts really
needed to do the decision/get overview of changes in detail. With more
aim on contingency plans, I can add contingency plan section. By these
three, you have covered 95% of content of standard changes. Let's try
it.

You can easily copy excerpt from wiki to the email and start that 
discussion, wiki for discussion is not needed (and really very bad
place to do so). 

Btw. it's my opinion, if more people would like to see the whole
change page announced, I'll do it. Or any other ideas in the way
how announcement is structured...

Jaroslav

> josh
> --
> 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: GUI applications writing garbage to stdout/stderr

[Alexander Ploumistos]

On Wed, Jan 14, 2015 at 12:22 PM, Marcel Oliver <
m.oli...@jacobs-university.de> wrote:

> Some of the main culprints for me are nemo, evince, and okular;
>

The applications that you mention are parts of specific desktop
environments. The messages that you see are not meant to be visible to the
user, unless something breaks; in such a case, such programs would pop up a
warning/info/error window, notifying the user about the problem. Messages
about missing themes or services that belong to the parent DE, but which
are not essential to the core functionality of the programs, do not
(usually) fall under that category, given that they don't stop the programs
from working and in most cases they are logged somewhere (e.g. in
.xsession-errors or journald).

On the other hand, if every message that was not meant for the user were
suppressed, it would be very difficult to troubleshoot such a program,
should an actual bug come along, because you would need a different build
to get useful output in the console or a logging service.

So, your options are to learn to live with the output of these programs,
redirect it to the null device, start them from their launchers or via the
command prompt (Alt+F2).
-- 
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: GUI applications writing garbage to stdout/stderr

[François Cami]

Hello,

On Wed, Jan 14, 2015 at 11:22 AM, Marcel Oliver
 wrote:
>
> Many GUI applications write garbage to either stdout or stderr, making
> the terminal windows difficult to view and navigate.
(...)
> Some of the main culprints for me are nemo, evince, and okular; if I
> am go looking, I can probably find many more.  The only well-behaved
> application I know is libreoffice.
>
> Are these considered bugs that I should file against the package?

Quoting https://fedoraproject.org/wiki/Staying_close_to_upstream_projects
: "The Fedora Project focuses, as much as possible, on not deviating
from upstream in the software it includes in the repository. " - and
patching upstream software to not write to stdout or stderr would be
such a change, IMHO.

I would therefore file bugs at upstream bug report tools, not against
Fedora packages.
For instance, in evince's case, see
https://wiki.gnome.org/Apps/Evince/ReportingBugs

Best regards,
François
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

GUI applications writing garbage to stdout/stderr

[Marcel Oliver]

Hallo,

there is one more thing which I found really annoying after upgrading
to F21.  I like to launch GUI applications from the command line (I
know there is some debate on whether this habit makes me a target user
of Fedora, but I am writing under the assumption that it might).

Many GUI applications write garbage to either stdout or stderr, making
the terminal windows difficult to view and navigate.  I have seen this
on earlier releases, too, but the volume being written and the number
of applications affected has increased to the extent that it is
becoming a real problem.

Some, like nemo, even keep writing messages during operation, which is
very distracting as there is sudden movement in the corner of one's
eye. 

Yes, I know that I could write, for example

  okular file.pdf &> /dev/null

but that somehow defeats the efficiency of the command line operation.

Some of the main culprints for me are nemo, evince, and okular; if I
am go looking, I can probably find many more.  The only well-behaved
application I know is libreoffice.

Are these considered bugs that I should file against the package?  Is
there a policy that applies?

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

Automatic background downloading of package metadata

[Marcel Oliver]

Hallo,

I came to this list via Google while trying to find some information
after having a rather unpleasant experience recently: I was engaged in
a last-minute professional email exchange trying to beat a critical
deadline while on a flaky tethered wireless connection when something
(I think it was packagekitd) started downloading megabytes of
presumably package metadata, almost completely saturating the link.

I desperately tried to kill it, but maybe systemd respawned it
immediately, at least I couldn't figure out how to do it and I
couldn't Google for help as I usually do as the link was - well -
saturated.

I was lucky the whole thing finished in time, but now I am trying to
fix the issue for good.  I found that it has been discussed in passing
as a side topic under the subject heading "F21 downloads repository
metadata in 3 places!" without really coming to a resolution, and I
found bits and pieces of information that leave me somewhat confused.

I believe that this is a critical issue that users should not fight
for themselves, but where the distribution should assist and be
considerate.

Here are some specific points for comment and consideration:

First, I am very sure that F20 did not do this, it must have happened
quietly after I did a fedup update (which otherwise worked well).

Second, I have some trouble understanding how the pieces of software
fit together.  I am a technical user and not afraid to dig into
details if necessary, but this is more complicated than I expected it
to be.  There is yum, dnf, packagekitd (I saw it with top), and Gnome
software potentially involved, but instructions I find on the web seem
to be ambiguous who is responsible for automatic metadata downloads.
Some instructions point me to open the Gnome software dconf settings,
where there is a "download updates" option (how about metadata then -
I find it unlikely that actual packages were downloaded because the
complete download volume was in the several MB range).  Also, there is
a listing "compatible-projects" which contains Gnome, KDE, XFCE.  But
I am a happy cinnamon user.  Does this apply to me?

I am sure I can find all of this out given enough time, but I think
that if I am finding this difficult, there will be many others who
will be in a similar boat, and there should probably be some
brainstorming at the distribution level on how to set/unset such
actions, and also how to protect users from sudden unexpected behavior
which can render the network practically unusable at random times.

Last, in the mailing list thread mentioned earlier, I read the opinion
that nowadays bandwidth is not as much an issue as it used to be.  In
my experience, also from observing how others use their devices, this
is not the case: we are now using mobile networked devices in
situations where a few years back we would not have dreamed being
online, including on airplanes, in remote spots with flaky mobile
reception, or at crowded conference venues where everybody is
competing for bandwidth on few configured access points.  And we are
expecting that we can get work done this way.  Thus, in my experience,
the ability to control who is using bandwidth at any time is a crucial
capability of an operating system and should be exposed to the user in
a more explicit way than fiddling with dconf settings.

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