Re: Council Elections - July/August 2017 - Result announcement

[Till Maas]

Am 16. August 2017 02:01:09 MESZ schrieb Kevin Kofler :
>Jan Kurik wrote:
>> It was the one sent to you by Justin with subject "[Fedora elections]
>> ausil: Your Council interview template".
>
>Wait, are we talking about the same Justin there? I.e., was one of the 
>candidates really also in charge of asking the interview questions? I
>sense 
>an obvious conflict of interest there. Who proves that the questions
>were 
>actually sent to the other candidates and that all the replies received
>were 
>actually published? The interviews really ought to be conducted by
>somebody 
>who is NOT a candidate.
>
>Kevin Kofler
>___
>devel mailing list -- devel@lists.fedoraproject.org
>To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Hey Kevin,

you are sceptical, which is good. You can easily ask the candidates if their 
interview was not publishes. I received the mails from Justin and the interview 
I submitted was published. Nick Bebout helped with it. As long as no candidate 
claims there was some wrongdoing I do not see any reason to doubt Jason. Would 
you be willing to oversee the next election?

Kind regards
Till
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Council Elections - July/August 2017 - Result announcement

[Jan Kurik]

On Wed, Aug 16, 2017 at 2:01 AM, Kevin Kofler  wrote:
> Jan Kurik wrote:
>> It was the one sent to you by Justin with subject "[Fedora elections]
>> ausil: Your Council interview template".
>
> Wait, are we talking about the same Justin there? I.e., was one of the
> candidates really also in charge of asking the interview questions? I sense
> an obvious conflict of interest there. Who proves that the questions were
> actually sent to the other candidates and that all the replies received were
> actually published? The interviews really ought to be conducted by somebody
> who is NOT a candidate.

I do not see the conflict of interests here. Justin is one of
volunteers (for several election cycles already) who contacts all
candidates at the beginning of Campaign period providing them with
instructions how to work with CommOps team to publish their
interviews. I really do not think that people helping with
administrative work behind elections should be punished by their
exclusion from nominations.

Anyone in the community can add a question into the questionnaire
during the nomination period. And it is free will of a nominee which
questions he/she answers in the interview.

Regards,
Jan

> Kevin Kofler
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org



-- 
Jan Kuřík
Platform & Fedora Program Manager
Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

openQA test failures due to typing errors

[Adam Williamson]

Hi folks! Another note for anyone paying attention to openQA test
results.

Since 2017-08-09 there's been kind of a flood of failures caused by
'typing errors' - that is, when the test runner is trying to type a
string into the test VM and it doesn't get through correctly (usually
due to one or more keypresses being dropped). We've always seen this
kind of failure *very occasionally* in openQA tests, but it suddenly
become massively more common (as in, half the tests for every update
were failing).

With some invaluable help from Cole Robinson I'm pretty sure we have
this figured out now; it was caused by a change to qemu which was
introduced to address a potential denial-of-service issue. For now I've
reverted qemu to the known good older version on the openQA worker
hosts (there isn't any realistic vector for anyone to cause any harm by
exploiting that DoS in the case of the openQA deployment, or any of the
other similar issues the updated qemu fixed), and we've identified some
later upstream commits that look like they may well resolve the
problem, so we should hopefully be able to put a more permanent fix in
place soon.

I'll be re-running all the tests that have run since 2017-08-09 with a
working qemu, so we have more accurate results.

Very sorry for this problem; I'd usually have noticed and addressed
this sooner, but it came at an unfortunate time.

While I'm here - there's also a consistent failure in the
'desktop_browser' test which is just caused by a screenshot that needs
updating. I'll get on that ASAP.
-- 
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
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Planned Outage - Taskotron update - 2017-08-15 @16:00 UTC

[Tim Flink]

The outage took a little longer than we planned but everything is back
up and has been running smoothly.

Tim

On Tue, 15 Aug 2017 09:46:47 -0600
Tim Flink  wrote:

> Apologies on not announcing this farther ahead of time, the
> announcement slipped through the cracks :(
> 
> There will be an outage starting at 2017-08-15 16:00:00 UTC, which
> will last approximately 3 hours.
> 
> To convert UTC to your local time, take a look at
> http://fedoraproject.org/wiki/Infrastructure/UTCHowto
> or run:
> 
> date -d '2017-08-15 16:00:00 UTC'
> 
> Reason for outage:
> 
> We are upgrading the hosts which run the services required for
> Taskotron.
> 
> Affected Services:
> 
> taskotron.fedoraproject.org
> 
> Contact Information:
> 
> Please join #fedora-admin or #fedora-noc on irc.freenode.net



pgpTmzpL35_9c.pgp
Description: OpenPGP digital signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Council Elections - July/August 2017 - Result announcement

[Dominik 'Rathann' Mierzejewski]

On Wednesday, 16 August 2017 at 02:01, Kevin Kofler wrote:
> Jan Kurik wrote:
> > It was the one sent to you by Justin with subject "[Fedora elections]
> > ausil: Your Council interview template".
> 
> Wait, are we talking about the same Justin there? I.e., was one of the 
> candidates really also in charge of asking the interview questions? I sense 
> an obvious conflict of interest there. Who proves that the questions were 
> actually sent to the other candidates and that all the replies received were 
> actually published? The interviews really ought to be conducted by somebody 
> who is NOT a candidate.

Kevin, please calm down and stop implying that Justin might have acted
inappropriately unless you have proof. I don't know if everyone got
the questionnaire mailed to them individually, but it was announced
publicly in advance (two times, even), for example on fedora-devel:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/AJX3FF47CXZ5JMDP2524YPBNU4GFTDAL/
and my reminder was Cc'd to Jan Kurik, so you can direct this
question to him. As for publishing, Justin is indeed one of the
Community Blog editors, but he's not the only one. The full list is
here: https://fedoraproject.org/wiki/Community_Blog#Editors .

Regards,
Dominik
-- 
Fedora   https://getfedora.org  |  RPMFusion   http://rpmfusion.org
There should be a science of discontent. People need hard times and
oppression to develop psychic muscles.
-- from "Collected Sayings of Muad'Dib" by the Princess Irulan
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Council Elections - July/August 2017 - Result announcement

[Kevin Kofler]

Jan Kurik wrote:
> It was the one sent to you by Justin with subject "[Fedora elections]
> ausil: Your Council interview template".

Wait, are we talking about the same Justin there? I.e., was one of the 
candidates really also in charge of asking the interview questions? I sense 
an obvious conflict of interest there. Who proves that the questions were 
actually sent to the other candidates and that all the replies received were 
actually published? The interviews really ought to be conducted by somebody 
who is NOT a candidate.

Kevin Kofler
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Council Elections - July/August 2017 - Result announcement

[Dennis Gilmore]

El mar, 15-08-2017 a las 22:37 +0200, Jan Kurik escribió:
> On Tue, Aug 15, 2017 at 10:22 PM, Dennis Gilmore 
> wrote:
> > El mar, 15-08-2017 a las 12:36 +0200, Kevin Kofler escribió:
> > > Jan Kurik wrote:
> > > >   # votes |  name
> > > > - +--
> > > >  505  | Justin W. Flory (jwf / jflory7)
> > > > - +--
> > > 
> > > No wonder, he is the only candidate who bothered filling out the
> > > questionnaire. It shows that answering voters' questions helps.
> > > (Though I
> > > personally did not vote for him because the answers were not even
> > > close to
> > > what I wanted to hear.) May this be a lesson for future
> > > candidates!
> > > 
> > > Kevin Kofler
> > 
> > What questionnaire? I was not asked to fill one out, I would have
> > done
> > so if asked.
> 
> It was the one sent to you by Justin with subject "[Fedora elections]
> ausil: Your Council interview template".
okay, must have been when I had mail server issues the other week as I
do not have it that I can find. No biggie, Justin is doing good work in
Fedora and I am possitive that he will do an excellent job

Dennis

signature.asc
Description: This is a digitally signed message part
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Council Elections - July/August 2017 - Result announcement

[Jan Kurik]

On Tue, Aug 15, 2017 at 10:22 PM, Dennis Gilmore  wrote:
> El mar, 15-08-2017 a las 12:36 +0200, Kevin Kofler escribió:
>> Jan Kurik wrote:
>> >   # votes |  name
>> > - +--
>> >  505  | Justin W. Flory (jwf / jflory7)
>> > - +--
>>
>> No wonder, he is the only candidate who bothered filling out the
>> questionnaire. It shows that answering voters' questions helps.
>> (Though I
>> personally did not vote for him because the answers were not even
>> close to
>> what I wanted to hear.) May this be a lesson for future candidates!
>>
>> Kevin Kofler
> What questionnaire? I was not asked to fill one out, I would have done
> so if asked.

It was the one sent to you by Justin with subject "[Fedora elections]
ausil: Your Council interview template".

Regards,
Jan

> Dennis
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
>



-- 
Jan Kuřík
Platform & Fedora Program Manager
Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: g2clib static lib file name change

[Michael Schwendt]

On Tue, 15 Aug 2017 22:13:00 +0200, Jos de Kloe wrote:

> Hi,
> 
> I just build a new version of g2clib (upgraded from 1.4.0 to 1.6.0), and
> with this change this static library for grib file handling changes name:
> old: libgrib2c.a
> new: libg2c_v1.6.0.a
> 
> I dont know of a packaging guideline that tells me to announce this, but
> to prevent surprises for dependent packages I thought I'd mention it.

Well, are you aware of any src.rpm that needs this library as build
requirement? If so, better inform the packager directly, because the next
(re)build of that package will fail. If not other packages in the distribution
use this lib, there may be private users of the Fedora package, but it's
uncertain whether they can be reached via devel@ list.

Packaging guidelines don't cover changes like that, but Update guidelines
may: https://fedoraproject.org/wiki/Category:Package_Maintainers
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Council Elections - July/August 2017 - Result announcement

[Dennis Gilmore]

El mar, 15-08-2017 a las 12:36 +0200, Kevin Kofler escribió:
> Jan Kurik wrote:
> >   # votes |  name
> > - +--
> >  505  | Justin W. Flory (jwf / jflory7)
> > - +--
> 
> No wonder, he is the only candidate who bothered filling out the 
> questionnaire. It shows that answering voters' questions helps.
> (Though I 
> personally did not vote for him because the answers were not even
> close to 
> what I wanted to hear.) May this be a lesson for future candidates!
> 
> Kevin Kofler
What questionnaire? I was not asked to fill one out, I would have done
so if asked.

Dennis

signature.asc
Description: This is a digitally signed message part
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

g2clib static lib file name change

[Jos de Kloe]

Hi,

I just build a new version of g2clib (upgraded from 1.4.0 to 1.6.0), and
with this change this static library for grib file handling changes name:
old: libgrib2c.a
new: libg2c_v1.6.0.a

I dont know of a packaging guideline that tells me to announce this, but
to prevent surprises for dependent packages I thought I'd mention it.

Best regards,

Jos
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Many 'map' SELinux denials in current Rawhide

[Adam Williamson]

On Tue, 2017-08-15 at 21:50 +0300, Joonas Sarajärvi wrote:
> Adam Williamson kirjoitti 15.08.2017 klo 02:37:
> > Of course, for day-to-day Rawhide users, booting with 'enforcing=0' can
> > work around these issues for now (or you could, I suppose, create a
> > local policy that just blanket allowed the 'map' permission in all
> > cases, so all other SELinux restrictions would remain in place).
> 
> For those less familiar with SELinux but still using it and wishing to 
> keep things that way, it would be awesome to have a quick summary (or 
> just pointer to documentation) on how you do this. It sounds like a 
> fairly straightforward task to describe if you know your way around SELinux.

Welp, that's me busted: I would've had to look up specifically how to
do this, and I was too lazy to. :P I do create custom policies very
occasionally, but not often enough to remember exactly how to do it off
the top of my head (I always have to look it up), and I don't think
I've tried one which just blanket allows a permission in *all* cases
before.

The reference I usually start from, FWIW, is:

https://wiki.centos.org/HowTos/SELinux#head-aa437f65e1c7873cddbafd9e9a73bbf9d102c072

There are various other references (mainly in RHEL and SELinux
documentation) that you can find by googling stuff like 'selinux custom
policy', and with the help of those I usually muddle through...
-- 
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
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Council Elections - July/August 2017 - Result announcement

[Zbigniew Jędrzejewski-Szmek]

On Tue, Aug 15, 2017 at 08:11:15PM +0300, Benson Muite wrote:
> Would be happy to help with linking interviews.
> 
> Benson
> 
> On 08/15/2017 08:08 PM, Brian Exelbierd wrote:
> >
> >
> >
> >On Tue, Aug 15, 2017, at 05:49 PM, Zbigniew Jędrzejewski-Szmek wrote:
> >
> > > Just linking to the User page is not enough,
> > > because those vary widely and often don't contain any info relevant for
> > > elections.
> >
> >This came up in another conversation I was having today. I agree
> >with linking to the interviews, however that may require some code
> >changes and "care and feeding" we don't have the capacity for (any
> >volunteers?).
> >
> >As an interim measure, Jan, could you modify the interview
> >instructions to include "and add a link to your published
> >interview at the top of your wiki user page"?
> >
> >This will add value and solve some of this. It's not a huge
> >request of a candidate.

I think I was able to add some links myself a few elections back
(the page was not protected), but in the last elections this wasn't
possible (and there weren't many interviews to link to either).

Zbyszek
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Many 'map' SELinux denials in current Rawhide

[Joonas Sarajärvi]

Adam Williamson kirjoitti 15.08.2017 klo 02:37:

Of course, for day-to-day Rawhide users, booting with 'enforcing=0' can
work around these issues for now (or you could, I suppose, create a
local policy that just blanket allowed the 'map' permission in all
cases, so all other SELinux restrictions would remain in place).


For those less familiar with SELinux but still using it and wishing to 
keep things that way, it would be awesome to have a quick summary (or 
just pointer to documentation) on how you do this. It sounds like a 
fairly straightforward task to describe if you know your way around SELinux.


Thanks,
- Joonas
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Many 'map' SELinux denials in current Rawhide

[Lukas Vrabec]

On 08/15/2017 05:25 PM, Adam Williamson wrote:

On Tue, 2017-08-15 at 16:58 +0200, Lukas Vrabec wrote:

On 08/15/2017 01:37 AM, Adam Williamson wrote:

Hi folks!

Just wanted to give a heads-up on this: it seems that a recent selinux-
policy update, 3.13.1-269 , introduced a new permission called 'map'.
This seems to have resulted in rather a large amount of new SELinux
denials for this permission in various cases. Some are fairly serious -
e.g. there's a denial for the systemd journal - and in some cases seem
to prevent systems from booting correctly at all.

I've created a tracker bug for now:
https://bugzilla.redhat.com/show_bug.cgi?id=1481454

and intend to mark all the 'map' bugs I find as blocking that tracker.
Petr, Lukas, it'd be great if we could get as many of these cleaned up
as fast as possible; it's been hard to get a decent evaluation of
Rawhide's current state for quite a while, now, due to various
problems, and now *this* problem is making things difficult too.

Of course, for day-to-day Rawhide users, booting with 'enforcing=0' can
work around these issues for now (or you could, I suppose, create a
local policy that just blanket allowed the 'map' permission in all
cases, so all other SELinux restrictions would remain in place).

Thanks!



Hi Adam,

I fixed all BZs from tracker bug. selinux-policy build is in koji:
https://koji.fedoraproject.org/koji/taskinfo?taskID=21243824


Thanks a lot, we'll see how the next compose goes.



Okay,
Please let me know ASAP if there will be more issues.

Thanks,
Lukas.

--
Lukas Vrabec
SELinux Solutions
Red Hat, Inc.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Pagure over dist-git: Workflow RFEs

[Pierre-Yves Chibon]

On Tue, Aug 15, 2017 at 09:24:24AM -0400, Matthew Miller wrote:
> On Tue, Aug 15, 2017 at 12:05:06PM +0200, Miro Hrončok wrote:
> > I have few questions / improvement suggestions:
> > 1) Does the PR build?
> > It would be **awesome** if we could have some sort of CI for PRs.
> 
> This is the eventual plan. See https://fedoraproject.org/wiki/CI
> 
> > Now when I merge a PR, I have to go from the web browser to
> > terminal, fedpkg clone the package (or pull) and run fedpkg build.
> > It would be great, if after merging, it would offer a "Fedpkg Build"
> > button (probably only available if the version-release was bumped).
> > The button would only show up if the last merged commit is still on
> > the top of the branch where it was merged.
> > This could be also written as a standalone bot, however probably
> > only in a way that it always builds, which is probably not desired.
> 
> This would be super-awesome. I don't think it's on anyone's immediate
> todo list, though.

This was very much one of the idea behind: https://pagure.io/fedobuild
that Randy and I presented at devconf: 
https://www.youtube.com/watch?v=ESt_ipOzJUI

Pierre
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Council Elections - July/August 2017 - Result announcement

[Benson Muite]

Would be happy to help with linking interviews.

Benson

On 08/15/2017 08:08 PM, Brian Exelbierd wrote:




On Tue, Aug 15, 2017, at 05:49 PM, Zbigniew Jędrzejewski-Szmek wrote:

 > Just linking to the User page is not enough,
 > because those vary widely and often don't contain any info relevant for
 > elections.

This came up in another conversation I was having today. I agree with 
linking to the interviews, however that may require some code changes 
and "care and feeding" we don't have the capacity for (any volunteers?).


As an interim measure, Jan, could you modify the interview instructions 
to include "and add a link to your published interview at the top of 
your wiki user page"?


This will add value and solve some of this. It's not a huge request of a 
candidate.


Regards,

bex


___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org


___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Council Elections - July/August 2017 - Result announcement

[Brian Exelbierd]

On Tue, Aug 15, 2017, at 05:49 PM, Zbigniew Jędrzejewski-Szmek wrote:

> Just linking to the User page is not enough,
> because those vary widely and often don't contain any info
> relevant for> elections.

This came up in another conversation I was having today. I agree with
linking to the interviews, however that may require some code changes
and "care and feeding" we don't have the capacity for (any volunteers?).
As an interim measure, Jan, could you modify the interview instructions
to include "and add a link to your published interview at the top of
your wiki user page"?
This will add value and solve some of this. It's not a huge request of a
candidate.
Regards,

bex 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Pylint is uninstallable in EPEL 7.10

[Orion Poplawski]

On 08/15/2017 06:58 AM, max ulidtko wrote:
> Hello again,
> 
> With EPEL 7.10, I observe that pylint is uninstallable, this time even with
> epel-testing enabled.
> 
> --> Processing Dependency: python-astroid >= 1.4.5 for package:
> python2-pylint-1.6.5-4.el7.noarch
> --> Finished Dependency Resolution
> Error: Package: python2-pylint-1.6.5-4.el7.noarch (epel)
>Requires: python-astroid >= 1.4.5
> 
> $ yum list available | grep astroid
> — empty output.
> 
> Is there anything wrong with the repository infrastructure right now?.. This
> is the second breakage I witness in just a few months.
> 
> Let me clarify: mashups like these quite literally break our builds at the
> company. As "the build person", I'm being held responsible for that.
> 
> If there's a need in a pair of hands which can write .spec files, I'm willing
> to takeover a handful of packages for maintenance. Just let me know how can I
> help.
> 
> Max

With the change from pkgdb to pagure for managing the Fedora/EPEL branches,
some packages got accidentally retired due to stray dead.package files.  We're
working on fixing this and hopefully with the next EPEL7 compose this
particular package will be back.

> 
> On Fri, Apr 7, 2017 at 8:24 PM Orion Poplawski  > wrote:
> 
> On 04/07/2017 10:28 AM, max ulidtko wrote:
> > Hi Orion, all,
> >
> > Currently on CentOS 7.3 it's not possible to install neither 
> python2-pylint
> > nor python34-pylint.
> >
> > --> Processing Dependency: python2-mccabe for package:
> > python2-pylint-1.6.5-4.el7.noarch
> > --> Finished Dependency Resolution
> > Error: Package: python2-pylint-1.6.5-4.el7.noarch (epel)
> >Requires: python2-mccabe
> >  You could try using --skip-broken to work around the problem
> >  You could try running: rpm -Va --nofiles --nodigest
> >
> > This happens because python2-pylint and python34-pylint `require`
> > python2-mccabe and python34-mccabe respectively, and those are not
> available.
> >
> > There is however a python-mccabe package available, but it doesn't 
> `provide`
> > python2-mccabe or python34-mccabe:
> >
> > ⚓  repoquery --provides python-mccabe
> > python-mccabe = 0.2.1-4.el7
> >
> > I believe there're two ways to fix this:
> >   1) rebuild python{2,34}-pylint with corrected Requires: in the spec.
> >   2) rebuild python-mccabe with added Provides: specs.
> >
> > Orion, I found your signature in the changelog and I believe you're the
> right
> > person to ask to fix this. Kindly let me know if you need any help with
> this.
> >
> > Regards,
> > Max
> >
> 
> The problem is that pylint got pushed to stable before the latest
> python-mccabe update. partly due to bodhi issues.  If you enable 
> epel-testing
> the install will work.  Also - karma needed for
> https://bodhi.fedoraproject.org/updates/python-mccabe-0.6.1-2.el7
> 
> 
> --
> Orion Poplawski
> Technical Manager  720-772-5637
> NWRA, Boulder/CoRA Office FAX: 303-415-9702
> 3380 Mitchell Lane   or...@nwra.com
> 
> Boulder, CO 80301   http://www.nwra.com
> 


-- 
Orion Poplawski
Technical Manager  720-772-5637
NWRA, Boulder/CoRA Office FAX: 303-415-9702
3380 Mitchell Lane   or...@nwra.com
Boulder, CO 80301   http://www.nwra.com
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Council Elections - July/August 2017 - Result announcement

[Zbigniew Jędrzejewski-Szmek]

On Tue, Aug 15, 2017 at 06:58:00PM +0530, Parag Nemade wrote:
> Just a suggestion, election wrangler can ask for submitting and preparing
> the final questionnaires in advance maybe before the nomination period
> starts so that probable candidate can know about them and they can start
> preparing for their answers along with their nomination and submit it for
> blog publishing review during nomination period. These blogs can be
> published then in Campaign period. I am not sure but I guess publishing
> these interviews also takes some amount time if no one is available to
> review them.

I'd like to make this even stronger: all interviews should be published
*before* the voting period starts and linked directly from the voting page.

(I always vote when I get the announcement from wrangler, because I'd
otherwise most likely forget to vote, and if the interviews are not
available then, I'm not going to go back later and change my vote when
they appear.)

Unless we want people to vote just for people they happen to know, we
have to make it easier to view information about the activity in Fedora
and platform of candidates. Just linking to the User page is not enough,
because those vary widely and often don't contain any info relevant for
elections.

Zbyszek
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Planned Outage - Taskotron update - 2017-08-15 @16:00 UTC

[Tim Flink]

Apologies on not announcing this farther ahead of time, the
announcement slipped through the cracks :(

There will be an outage starting at 2017-08-15 16:00:00 UTC, which will
last approximately 3 hours.

To convert UTC to your local time, take a look at
http://fedoraproject.org/wiki/Infrastructure/UTCHowto
or run:

date -d '2017-08-15 16:00:00 UTC'

Reason for outage:

We are upgrading the hosts which run the services required for
Taskotron.

Affected Services:

taskotron.fedoraproject.org

Contact Information:

Please join #fedora-admin or #fedora-noc on irc.freenode.net


pgpzeIW7eWBDz.pgp
Description: OpenPGP digital signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Many 'map' SELinux denials in current Rawhide

[Adam Williamson]

On Tue, 2017-08-15 at 16:58 +0200, Lukas Vrabec wrote:
> On 08/15/2017 01:37 AM, Adam Williamson wrote:
> > Hi folks!
> > 
> > Just wanted to give a heads-up on this: it seems that a recent selinux-
> > policy update, 3.13.1-269 , introduced a new permission called 'map'.
> > This seems to have resulted in rather a large amount of new SELinux
> > denials for this permission in various cases. Some are fairly serious -
> > e.g. there's a denial for the systemd journal - and in some cases seem
> > to prevent systems from booting correctly at all.
> > 
> > I've created a tracker bug for now:
> > https://bugzilla.redhat.com/show_bug.cgi?id=1481454
> > 
> > and intend to mark all the 'map' bugs I find as blocking that tracker.
> > Petr, Lukas, it'd be great if we could get as many of these cleaned up
> > as fast as possible; it's been hard to get a decent evaluation of
> > Rawhide's current state for quite a while, now, due to various
> > problems, and now *this* problem is making things difficult too.
> > 
> > Of course, for day-to-day Rawhide users, booting with 'enforcing=0' can
> > work around these issues for now (or you could, I suppose, create a
> > local policy that just blanket allowed the 'map' permission in all
> > cases, so all other SELinux restrictions would remain in place).
> > 
> > Thanks!
> > 
> 
> Hi Adam,
> 
> I fixed all BZs from tracker bug. selinux-policy build is in koji:
> https://koji.fedoraproject.org/koji/taskinfo?taskID=21243824

Thanks a lot, we'll see how the next compose goes.
-- 
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
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Council Elections - July/August 2017 - Result announcement

[Matthew Miller]

On Tue, Aug 15, 2017 at 03:47:49PM +0200, Jan Kurik wrote:
> I am personally not convinced this will help as the set of questions
> in Questionnaire is almost the same for the last several elections, as
> we copy them from one elections to another. So, candidates can prepare
> them self in advance even now. However, I do not see a reason why we
> can not start collection of questions for the Questionnaire one week
> earlier. I can modify the schedule for F27 release cycle, if agreed.

Sounds good to me. Thanks!

-- 
Matthew Miller

Fedora Project Leader
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Re: Many 'map' SELinux denials in current Rawhide

[Lukas Vrabec]

On 08/15/2017 04:58 PM, Lukas Vrabec wrote:

On 08/15/2017 01:37 AM, Adam Williamson wrote:

Hi folks!

Just wanted to give a heads-up on this: it seems that a recent selinux-
policy update, 3.13.1-269 , introduced a new permission called 'map'.
This seems to have resulted in rather a large amount of new SELinux
denials for this permission in various cases. Some are fairly serious -
e.g. there's a denial for the systemd journal - and in some cases seem
to prevent systems from booting correctly at all.

I've created a tracker bug for now:
https://bugzilla.redhat.com/show_bug.cgi?id=1481454

and intend to mark all the 'map' bugs I find as blocking that tracker.
Petr, Lukas, it'd be great if we could get as many of these cleaned up
as fast as possible; it's been hard to get a decent evaluation of
Rawhide's current state for quite a while, now, due to various
problems, and now *this* problem is making things difficult too.

Of course, for day-to-day Rawhide users, booting with 'enforcing=0' can
work around these issues for now (or you could, I suppose, create a
local policy that just blanket allowed the 'map' permission in all
cases, so all other SELinux restrictions would remain in place).

Thanks!



Hi Adam,

I fixed all BZs from tracker bug. selinux-policy build is in koji:
https://koji.fedoraproject.org/koji/taskinfo?taskID=21243824

Lukas.



--
Lukas Vrabec
Software Engineer, Security Technologies
Red Hat, Inc.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Many 'map' SELinux denials in current Rawhide

[Lukas Vrabec]

On 08/15/2017 01:37 AM, Adam Williamson wrote:

Hi folks!

Just wanted to give a heads-up on this: it seems that a recent selinux-
policy update, 3.13.1-269 , introduced a new permission called 'map'.
This seems to have resulted in rather a large amount of new SELinux
denials for this permission in various cases. Some are fairly serious -
e.g. there's a denial for the systemd journal - and in some cases seem
to prevent systems from booting correctly at all.

I've created a tracker bug for now:
https://bugzilla.redhat.com/show_bug.cgi?id=1481454

and intend to mark all the 'map' bugs I find as blocking that tracker.
Petr, Lukas, it'd be great if we could get as many of these cleaned up
as fast as possible; it's been hard to get a decent evaluation of
Rawhide's current state for quite a while, now, due to various
problems, and now *this* problem is making things difficult too.

Of course, for day-to-day Rawhide users, booting with 'enforcing=0' can
work around these issues for now (or you could, I suppose, create a
local policy that just blanket allowed the 'map' permission in all
cases, so all other SELinux restrictions would remain in place).

Thanks!



Hi Adam,

I fixed all BZs from tracker bug. selinux-policy build is in koji:
https://koji.fedoraproject.org/koji/taskinfo?taskID=21243824

Lukas.

--
Lukas Vrabec
Software Engineer, Security Technologies
Red Hat, Inc.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Council Elections - July/August 2017 - Result announcement

[Ben Rosser]

On Tue, Aug 15, 2017 at 9:54 AM, Silvia Sanchez  wrote:

>
> I don't think Justin won *only* because of the interview but I do think
> it had a lot to do.
> Personally, I think that dedicating some time to answer these questions
> (it doesn't take that much anyway, I know because I did it for FAmSCo)
> shows interest and commitment.
> My 2 cents.
>

I agree.

I know that, for example, I wasn't personally familiar with two of the
Council candidates' history in the Fedora project (and most of the FAmSCo
candidates, for that matter). I didn't know why they wanted to run, what
their goals for the project were, etc. If they'd filled out the interview
it would have been much clearer what their positions were and why I should
vote for them and what they might focus on if elected.

I would go so far as to say answering the questionnaire, or at least giving
a brief statement about your goals for the position, should be a
*requirement* for running for an elected position in the project.

Ben Rosser
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Council Elections - July/August 2017 - Result announcement

[Silvia Sanchez]

I don't think Justin won  only  because of the interview but I do think
it had a lot to do.Personally, I think that dedicating some time to
answer these questions  (it doesn't take that much anyway, I know
because I did it for FAmSCo)  shows interest and commitment.My 2 cents.


On Tue, 2017-08-15 at 15:21 +0200, Radka Janekova wrote:
> > I agree with Kevin on the interviews. Personally I find them very
> important
> > and read them religiously.
> > Even though I'm fairly active in certain areas of Fedora, there are
> many candidates
> > (especially for famsco and council) whom I don't know and haven't
> interacted
> > with at all. Doing the review on time is also a sign of commitment
> and
> > organizational skills ;)
> 
> You misunderstood me, I never said that they were not important. I
> meant that you can't and shouldn't say that Justin won only and only
> because nobody else did their interview. That statement would be
> wrong on multiple levels.
> 
> 
> Radka
>   
> 
> 
> Radka Janeková
> .NET & OpenShift Engineer, Red Hat
> radka.ja...@redhat.com
> IRC: radka | Freenode: Rhea
> 
> 
> 
> On Tue, Aug 15, 2017 at 2:55 PM, Zbigniew Jędrzejewski-Szmek  @in.waw.pl> wrote:
> > On Tue, Aug 15, 2017 at 02:35:48PM +0200, Radka Janekova wrote:
> > 
> > > Hi Kevin,
> > 
> > >
> > 
> > > I don't think that it has much to do with others not answering
> > questions.
> > 
> > > Justin was very high in the results last election as well, and
> > has been
> > 
> > > doing great job all around Fedora project for a long time now.
> > 
> > 
> > 
> > I agree with Kevin on the interviews. Personally I find them very
> > important
> > 
> > and read them religiously.
> > 
> > Even though I'm fairly active in certain areas of Fedora, there are
> > many candidates
> > 
> > (especially for famsco and council) whom I don't know and haven't
> > interacted
> > 
> > with at all. Doing the review on time is also a sign of commitment
> > and
> > 
> > organizational skills ;)
> > 
> > 
> > 
> > > > No wonder, he is the only candidate who bothered filling out
> > the
> > 
> > > > questionnaire. It shows that answering voters' questions helps.
> > (Though I
> > 
> > > > personally did not vote for him because the answers were not
> > even close to
> > 
> > > > what I wanted to hear.) May this be a lesson for future
> > candidates!
> > 
> > Hmmm, that's intersting too. In the interview, flory7 talks about
> > 
> > increasing communication and interconnectedness of different
> > 
> > initiatives. Then about increasing new contributor retention. Then
> > to
> > 
> > "represent the perspectives, views, and ambitions of a wide range
> > of
> > 
> > contributors and to help connect the community". Do you disagree
> > with
> > 
> > those goals, or do you think that the focus should be on something
> > else?
> > 
> > I'm intrigued.
> > 
> > 
> > 
> > Zbyszek
> > 
> > ___
> > 
> > devel mailing list -- devel@lists.fedoraproject.org
> > 
> > To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> > 
> 
> 
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Council Elections - July/August 2017 - Result announcement

[Jan Kurik]

On Tue, Aug 15, 2017 at 3:32 PM, Matthew Miller
 wrote:
> On Tue, Aug 15, 2017 at 06:58:00PM +0530, Parag Nemade wrote:
>> Just a suggestion, election wrangler can ask for submitting and preparing
>> the final questionnaires in advance maybe before the nomination period
>> starts so that probable candidate can know about them and they can start
>> preparing for their answers along with their nomination and submit it for
>> blog publishing review during nomination period. These blogs can be
>> published then in Campaign period. I am not sure but I guess publishing
>> these interviews also takes some amount time if no one is available to
>> review them.
>
> Jan, maybe a little longer between nomination and voting period next
> time?

I am personally not convinced this will help as the set of questions
in Questionnaire is almost the same for the last several elections, as
we copy them from one elections to another. So, candidates can prepare
them self in advance even now. However, I do not see a reason why we
can not start collection of questions for the Questionnaire one week
earlier. I can modify the schedule for F27 release cycle, if agreed.

Regards,
Jan

> --
> Matthew Miller
> 
> Fedora Project Leader
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org



-- 
Jan Kuřík
Platform & Fedora Program Manager
Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Council Elections - July/August 2017 - Result announcement

[Kevin Kofler]

Zbigniew Jędrzejewski-Szmek wrote:
> Hmmm, that's intersting too. In the interview, flory7 talks about
> increasing communication and interconnectedness of different
> initiatives. Then about increasing new contributor retention. Then to
> "represent the perspectives, views, and ambitions of a wide range of
> contributors and to help connect the community". Do you disagree with
> those goals, or do you think that the focus should be on something else?
> I'm intrigued.

What I disagree with is the technical goals, pushing further initiatives 
such as Atomic and Modularity.

Kevin Kofler
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Council Elections - July/August 2017 - Result announcement

[Matthew Miller]

On Tue, Aug 15, 2017 at 06:58:00PM +0530, Parag Nemade wrote:
> Just a suggestion, election wrangler can ask for submitting and preparing
> the final questionnaires in advance maybe before the nomination period
> starts so that probable candidate can know about them and they can start
> preparing for their answers along with their nomination and submit it for
> blog publishing review during nomination period. These blogs can be
> published then in Campaign period. I am not sure but I guess publishing
> these interviews also takes some amount time if no one is available to
> review them.

Jan, maybe a little longer between nomination and voting period next
time?

-- 
Matthew Miller

Fedora Project Leader
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Council Elections - July/August 2017 - Result announcement

[Parag Nemade]

Hi,

On Tue, Aug 15, 2017 at 6:38 PM, Langdon White 
wrote:

>
>
> On Tue, Aug 15, 2017 at 6:37 AM Kevin Kofler 
> wrote:
>
>> Jan Kurik wrote:
>> >   # votes |  name
>> > - +--
>> >  505  | Justin W. Flory (jwf / jflory7)
>> > - +--
>>
>> No wonder, he is the only candidate who bothered filling out the
>> questionnaire. It shows that answering voters' questions helps. (Though I
>> personally did not vote for him because the answers were not even close to
>> what I wanted to hear.) May this be a lesson for future candidates!
>>
>> Kevin Kofler
>> ___
>> devel mailing list -- devel@lists.fedoraproject.org
>> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
>
>
> Personally, I find this to be pretty offensive. I care a lot about Fedora
> and between F26 being late & the short cycle for f27, not to mention
> $DAYJOB, I just didn't get to it. I am really sorry to have lost the seat
> and not campaigned hard enough.
>
> Congrats to Justin!
>
>

Just a suggestion, election wrangler can ask for submitting and preparing
the final questionnaires in advance maybe before the nomination period
starts so that probable candidate can know about them and they can start
preparing for their answers along with their nomination and submit it for
blog publishing review during nomination period. These blogs can be
published then in Campaign period. I am not sure but I guess publishing
these interviews also takes some amount time if no one is available to
review them.

Regards,
Parag
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Pagure over dist-git: Workflow RFEs

[Matthew Miller]

On Tue, Aug 15, 2017 at 12:05:06PM +0200, Miro Hrončok wrote:
> I have few questions / improvement suggestions:
> 1) Does the PR build?
> It would be **awesome** if we could have some sort of CI for PRs.

This is the eventual plan. See https://fedoraproject.org/wiki/CI

> Now when I merge a PR, I have to go from the web browser to
> terminal, fedpkg clone the package (or pull) and run fedpkg build.
> It would be great, if after merging, it would offer a "Fedpkg Build"
> button (probably only available if the version-release was bumped).
> The button would only show up if the last merged commit is still on
> the top of the branch where it was merged.
> This could be also written as a standalone bot, however probably
> only in a way that it always builds, which is probably not desired.

This would be super-awesome. I don't think it's on anyone's immediate
todo list, though.

> 3) Fork and PR from terminal
> I know there's the "pag" command that should be able to fork repos
> and create PRs on pagure.io. Is there a configuration I can use with
> dist-git? Would adding "fedpkg fork" and "fedpkg pull-request" be
> possible?

I'd also like to see something where fedpkg would notify of pending
PRs.


-- 
Matthew Miller

Fedora Project Leader
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Council Elections - July/August 2017 - Result announcement

[Radka Janekova]

> I agree with Kevin on the interviews. Personally I find them very
important
> and read them religiously.
> Even though I'm fairly active in certain areas of Fedora, there are many
candidates
> (especially for famsco and council) whom I don't know and haven't
interacted
> with at all. Doing the review on time is also a sign of commitment and
> organizational skills ;)

You misunderstood me, I never said that they were not important. I meant
that you can't and shouldn't say that Justin won only and only because
nobody else did their interview. That statement would be wrong on multiple
levels.


Radka

--
*Radka Janeková*
.NET & OpenShift Engineer, Red Hat
*radka.ja...@redhat.com *
IRC: radka | Freenode: Rhea


On Tue, Aug 15, 2017 at 2:55 PM, Zbigniew Jędrzejewski-Szmek <
zbys...@in.waw.pl> wrote:

> On Tue, Aug 15, 2017 at 02:35:48PM +0200, Radka Janekova wrote:
> > Hi Kevin,
> >
> > I don't think that it has much to do with others not answering questions.
> > Justin was very high in the results last election as well, and has been
> > doing great job all around Fedora project for a long time now.
>
> I agree with Kevin on the interviews. Personally I find them very important
> and read them religiously.
> Even though I'm fairly active in certain areas of Fedora, there are many
> candidates
> (especially for famsco and council) whom I don't know and haven't
> interacted
> with at all. Doing the review on time is also a sign of commitment and
> organizational skills ;)
>
> > > No wonder, he is the only candidate who bothered filling out the
> > > questionnaire. It shows that answering voters' questions helps.
> (Though I
> > > personally did not vote for him because the answers were not even
> close to
> > > what I wanted to hear.) May this be a lesson for future candidates!
> Hmmm, that's intersting too. In the interview, flory7 talks about
> increasing communication and interconnectedness of different
> initiatives. Then about increasing new contributor retention. Then to
> "represent the perspectives, views, and ambitions of a wide range of
> contributors and to help connect the community". Do you disagree with
> those goals, or do you think that the focus should be on something else?
> I'm intrigued.
>
> Zbyszek
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Council Elections - July/August 2017 - Result announcement

[Langdon White]

On Tue, Aug 15, 2017 at 6:37 AM Kevin Kofler  wrote:

> Jan Kurik wrote:
> >   # votes |  name
> > - +--
> >  505  | Justin W. Flory (jwf / jflory7)
> > - +--
>
> No wonder, he is the only candidate who bothered filling out the
> questionnaire. It shows that answering voters' questions helps. (Though I
> personally did not vote for him because the answers were not even close to
> what I wanted to hear.) May this be a lesson for future candidates!
>
> Kevin Kofler
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org


Personally, I find this to be pretty offensive. I care a lot about Fedora
and between F26 being late & the short cycle for f27, not to mention
$DAYJOB, I just didn't get to it. I am really sorry to have lost the seat
and not campaigned hard enough.

Congrats to Justin!

Langdon
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Council Elections - July/August 2017 - Result announcement

[Zbigniew Jędrzejewski-Szmek]

On Tue, Aug 15, 2017 at 02:35:48PM +0200, Radka Janekova wrote:
> Hi Kevin,
> 
> I don't think that it has much to do with others not answering questions.
> Justin was very high in the results last election as well, and has been
> doing great job all around Fedora project for a long time now.

I agree with Kevin on the interviews. Personally I find them very important
and read them religiously.
Even though I'm fairly active in certain areas of Fedora, there are many 
candidates
(especially for famsco and council) whom I don't know and haven't interacted
with at all. Doing the review on time is also a sign of commitment and
organizational skills ;)

> > No wonder, he is the only candidate who bothered filling out the
> > questionnaire. It shows that answering voters' questions helps. (Though I
> > personally did not vote for him because the answers were not even close to
> > what I wanted to hear.) May this be a lesson for future candidates!
Hmmm, that's intersting too. In the interview, flory7 talks about
increasing communication and interconnectedness of different
initiatives. Then about increasing new contributor retention. Then to
"represent the perspectives, views, and ambitions of a wide range of
contributors and to help connect the community". Do you disagree with
those goals, or do you think that the focus should be on something else?
I'm intrigued.

Zbyszek
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Council Elections - July/August 2017 - Result announcement

[Radka Janekova]

Hi Kevin,

I don't think that it has much to do with others not answering questions.
Justin was very high in the results last election as well, and has been
doing great job all around Fedora project for a long time now.

Regards,
Radka

--
*Radka Janeková*
.NET & OpenShift Engineer, Red Hat
*radka.ja...@redhat.com *
IRC: radka | Freenode: Rhea


On Tue, Aug 15, 2017 at 12:36 PM, Kevin Kofler 
wrote:

> Jan Kurik wrote:
> >   # votes |  name
> > - +--
> >  505  | Justin W. Flory (jwf / jflory7)
> > - +--
>
> No wonder, he is the only candidate who bothered filling out the
> questionnaire. It shows that answering voters' questions helps. (Though I
> personally did not vote for him because the answers were not even close to
> what I wanted to hear.) May this be a lesson for future candidates!
>
> Kevin Kofler
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Is it possible atlas is linked wrongly by new binutils?

[Kevin Kofler]

Dave Love wrote:
> You'll find Dominik was correct if you try it.

If you are talking about the missing RPM AutoProvides:
Provides: libblas.so.3()(64bit)
does wonders.

> Various things have been changed to use openblas on x86 after some of us
> agitated.

The problem is, "various things" is not enough, we need a plan to ensure ALL 
things use it.

> As far as I remember, there's good reason (apart from the previous
> (FPC?) vote against it), like the atlas blas and lapack have to go
> together.

If the ld.so.conf.d override were implemented correctly, it would just work. 
The issue with the old state was that there was only an override for 
liblapack installed and not for libblas, which is of course very broken.

But the new approach I am proposing installs only one version of both BLAS 
and LAPACK (the OpenBLAS one), so there cannot possibly be mismatched 
versions (except if you have third-party binaries bundling BLAS and linking 
to the system LAPACK or the other way round, but those are then very broken 
and will also fail on other distributions for the same reason).

> It will exceed it on any relevant platform that openblas doesn't
> support,

Is there even such a platform, the keyword being "relevant"? :-)

OpenBLAS supports all these:
https://github.com/xianyi/OpenBLAS/blob/develop/GotoBLAS_01Readme.txt#L21
https://github.com/xianyi/OpenBLAS#additional-support-cpu

If you want anything else, sure, you can ExcludeArch OpenBLAS on them, build 
ATLAS as an ExclusiveArch package for them, and set up the symlinks 
accordingly. That should not be an obstacle to shipping an optimal 
implementation on our primary architectures. (Quite the opposite, it means 
that no other package would need %ifarch hacks, all the logic would stay 
confined to the OpenBLAS and ATLAS packages as it should be.)

> but where OB doesn't do DYNAMIC_ARCH you still have the problem of needing
> micro-architecture-specific packages (which seems to be against policy,
> although atlas does it).

ld.so.conf.d is the only way to build those, if you want to support them. I 
wonder whether non-x86 architectures are even worth investing the effort.

>> It is the job of the distribution to ensure that software uses the most
>> efficient BLAS/LAPACK implementation available. Other distributions ship
>> symlinks ensuring that. The current packaging in Fedora is horrible.
> 
> I presume that means the most efficient free implementation.

Sure, I mean the most efficient implementation available in Fedora, for 
which freeness is of course a prerequisite.

> On avx512, that's BLIS (+libxsmm), but MKL is still substantially faster.

Well, another technical criterion is that we can really only pick the 
default implementation per architecture (e.g., x86_64), not per 
subarchitecture (e.g., AVX-512), and I think OpenBLAS is still the best 
option for x86_64 overall (also because it supports runtime subarchitecture 
detection and BLIS does not).

For AVX-512, I think what we really want is to get AVX-512 optimizations 
into OpenBLAS. It can match MKL performance when it is using the same 
instruction set, see e.g. the graph for Sandy Bridge (AVX):
https://github.com/xianyi/OpenBLAS/wiki/faq#sandybridge_perf
Of course, if your CPU supports AVX-512 and your BLAS is only using AVX2 (as 
OpenBLAS currently does), it will not be optimal, no surprise there.

Kevin Kofler
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

tcp_wrappers deprecation

[Jakub Jelen]

Hello Fedora devels and users,

more than three years ago, the same topic started discussion if we want
this package in Fedora or not and how [1]. The discussion resulted
mostly in flames and in the removal of the dependency on tcp_wrappers
from systemd. But it was quite agreed that it is considered as a
security layer for some users, if they use it correctly, or something
that is or should be replaced by firewalls.

So can we discuss it now once more without the affiliation to systemd?
The fact is that we still do not have any other replacement except
firewalls. But do we need one?

The complete removal of the package is probably not a wise step, even
though we can not find tcp_wrappers in recent SuSE anymore [2]. It is
still available in Arch [3] without other tools depending on it. To be
fair, Debian [4] is still building tools (for example openssh) with a
build-time support for it.

My primary concern is OpenSSH, which upstream dropped support for
tcp_wrappers three years ago (late 2014) [5] and since then we are
maintaining one more downstream patch. But this effort should be
coordinated among other components to simplify the transition for users
who insist on using it (using tcpd).

Removing the dependency will also allow us to trim the default
install for few more Kb.

If there will be no significant drawbacks, I will progress with filling
a system wide change for Fedora 28 and I will pull the maintainers of
other tolls using libwrap into the round and discussion.


[1] https://lists.fedoraproject.org/pipermail/devel/2014-March/196913.h
tml
[2] https://www.rpmfind.net/linux/rpm2html/search.php?query=tcpd&submit
=Search+...&system=&arch=
[3] https://www.archlinux.org/packages/community/x86_64/tcp-wrappers/
[4] https://packages.debian.org/sid/openssh-server
[5] http://www.openssh.com/txt/release-6.7


Thank you for comments and constructive ideas.
Regards,
-- 
Jakub Jelen
Software Engineer
Security Technologies
Red Hat, Inc.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Is it possible atlas is linked wrongly by new binutils?

[Kevin Kofler]

(I am reversing the paragraphs so that the order of the replies makes 
sense.)

Dominik 'Rathann' Mierzejewski wrote:
> Thinking again, we had this discussion over 3 years ago:
> https://pagure.io/packaging-committee/issue/352
> and another one starting 2 years ago:
> https://pagure.io/packaging-committee/issue/588
> which is stalled because Orion doesn't have any time lately.

Please note that what I am proposing here is not the same as my proposal 
from 3 years ago that was rejected. While I would not complain if my old 
proposal were implemented, I am now suggesting a much simpler approach 
(which was already hinted at in the last paragraph of my old proposal):

* drop the inefficient implementations reference (netlib) BLAS/LAPACK and 
ATLAS (have OpenBLAS Obsolete them),

* use one-way symlinks or linker scripts to make everything linking or 
linked to them pick up OpenBLAS instead. So libblas, liblapack and libsatlas 
would just redirect to libopenblas,

* I am not sure about libtatlas, ideally it should redirect to libopenblaso, 
but libtatlas uses raw pthread wheres libopenblaso uses OpenMP, this may 
make a difference (e.g., it will certainly cause problems if the client 
program uses OpenMP itself). If libopenblaso does not work as a drop-in 
libtatlas replacement, libopenblas would have to be used instead (and the 
programs that really want libopenblaso would have to be rebuilt for it).

> On Monday, 14 August 2017 at 02:35, Kevin Kofler wrote:
>> Dominik 'Rathann' Mierzejewski wrote:
>> Symlinking
>> libblas.so.3 → libopenblas.so.0
>> liblapack.so.3 → libopenblas.so.0
>> is enough to get things linked against BLAS and/or LAPACK to pick up
>> OpenBLAS instead. A similar symlinking should work for the -devel
>> package. If the symlinks confuse ldconfig or cause some other issues,
>> linker scripts can be used instead.
> 
> It certainly won't be enough for RPM. There needs to be a libblas.so
> pointing to a library with SONAME libblas.so.3, same for lapack.

With the above proposal, if libblas.so symlinks to libopenblas.so.0, the 
built RPM will have an AutoRequires on libopenblas.so.0, which is fine 
(because that is what we want things to use).

For the runtime symlinks (e.g. libblas.so.3 → libopenblas.so.0), explicit 
Provides would be needed so that the dependencies in programs still 
depending on the legacy sonames can be resolved.


My old proposal, on the other hand, does not use symlinks to do the 
redirection at all, but ld.so.conf.d overrides. So that entirely bypasses 
the AutoRequires/AutoProvides system. In that proposal, the "libblas.so
pointing to a library with SONAME libblas.so.3" would come from the 
reference (netlib) BLAS's blas-devel package.

Hence, I do not understand your objection.


The old proposal is the way to go if you want to support multiple 
BLAS/LAPACK implementations. The new proposal is the way to go if you want 
to ship a BLAS/LAPACK that just works.

In any case, the goal ought to be that we centrally pick the BLAS/LAPACK 
implementation, either at runtime (old proposal) or at compile time (new 
proposal) instead of expecting each and every package using BLAS and/or 
LAPACK to be patched to pick up the preferred implementation, which is 
clearly not working. (We still have different packages linking to different 
implementations.)

This is really the same issue as what I complained about with the libidn2 
migration. It just does not scale to expect each and every package to be 
patched to change the name of the library to link, when the new library is a 
drop-in replacement API/ABI-wise and could just be shipped as a true drop-in 
replacement also picking up the old name. Doing the latter is not only much 
more efficient for the distribution, but also much less error-prone. Not 
only does it avoid inconsistencies (as we are seeing with BLAS/LAPACK) now, 
but, e.g., the pointless changes that were required for libidn2 ended up 
causing this fun bug:
https://bugzilla.redhat.com/show_bug.cgi?id=1479146

Kevin Kofler
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Pagure over dist-git: what changes?

[Miro Hrončok]

On 3.8.2017 17:21, Pierre-Yves Chibon wrote:

Good morning everyone,

We're now in the final sprint before Pagure over dist-git is a real thing. This
is a great time and we're very excited to see it happen.
However this change brings other changes with it which are detailed below.
Is it possible to subscribe to a PR and/or add somebody to CC? I don't 
see a way using the GUI.


--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Council Elections - July/August 2017 - Result announcement

[Kevin Kofler]

Jan Kurik wrote:
>   # votes |  name
> - +--
>  505  | Justin W. Flory (jwf / jflory7)
> - +--

No wonder, he is the only candidate who bothered filling out the 
questionnaire. It shows that answering voters' questions helps. (Though I 
personally did not vote for him because the answers were not even close to 
what I wanted to hear.) May this be a lesson for future candidates!

Kevin Kofler
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Pagure over dist-git: Workflow RFEs

[Miro Hrončok]

On 3.8.2017 17:21, Pierre-Yves Chibon wrote:

Good morning everyone,

We're now in the final sprint before Pagure over dist-git is a real thing. This
is a great time and we're very excited to see it happen.
However this change brings other changes with it which are detailed below.


Hi,

let me say that the ability to have Pull Requests in dist-git is super cool!

I have few questions / improvement suggestions:

1) Does the PR build?

It would be **awesome** if we could have some sort of CI for PRs.

Something that watches fedmsg for dist-git PR changes, fires a scratch 
build and sends status back to Pagure. I realize this could be written 
as a standalone bot that posts comments. (And I might even try to write 
such thing.) However, integration to Pagure UI would be even better.



2) Merges PR -> fires build

Now when I merge a PR, I have to go from the web browser to terminal, 
fedpkg clone the package (or pull) and run fedpkg build.
It would be great, if after merging, it would offer a "Fedpkg Build" 
button (probably only available if the version-release was bumped).
The button would only show up if the last merged commit is still on the 
top of the branch where it was merged.
This could be also written as a standalone bot, however probably only in 
a way that it always builds, which is probably not desired.



3) Fork and PR from terminal

I know there's the "pag" command that should be able to fork repos and 
create PRs on pagure.io. Is there a configuration I can use with 
dist-git? Would adding "fedpkg fork" and "fedpkg pull-request" be possible?


Thanks
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Is it possible atlas is linked wrongly by new binutils?

[Jakub Martisko]

On 15.8.2017 10:39, Dave Love wrote:

> 
> I don't know whether that's true, but Fedora could at least improve the
> situation by providing more than the -sse2 and -sse3 packages.
> 

I am planning to drop the sse2 sse3 subpackages and replace
them with something a bit more "modern" [1] with the rebase
to 3.10.3.

[1]: https://bugzilla.redhat.com/show_bug.cgi?id=1304402
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Is it possible atlas is linked wrongly by new binutils?

[Dave Love]

Kevin Kofler  writes:

> Dominik 'Rathann' Mierzejewski wrote:
>> It also needs some patching, because each library has a different
>> SONAME.
>
> Symlinking
> libblas.so.3 → libopenblas.so.0
> liblapack.so.3 → libopenblas.so.0
> is enough to get things linked against BLAS and/or LAPACK to pick up 
> OpenBLAS instead. A similar symlinking should work for the -devel package. 
> If the symlinks confuse ldconfig or cause some other issues, linker scripts 
> can be used instead.

You'll find Dominik was correct if you try it.

>> I think atlas used to provide a drop-in replacement, but it was abandoned
>
> Ouch! Indeed, the current ATLAS packages provide only libsatlas and 
> libtatlas, no libblas or liblapack. This is a regression and should never 
> have been packaged that way. Now all the packages end up with the 
> unoptimized reference BLAS.

Various things have been changed to use openblas on x86 after some of us
agitated.

> (In fact, I think I already noticed that when it 
> happened and complained loudly about it, but was ignored, as it seems. 
> Sigh!)

As far as I remember, there's good reason (apart from the previous
(FPC?) vote against it), like the atlas blas and lapack have to go
together.

> That said, ATLAS should really go away, unless they add support for runtime 
> CPU detection and the result matches or exceeds OpenBLAS performance.

It will exceed it on any relevant platform that openblas doesn't
support, but where OB doesn't do DYNAMIC_ARCH you still have the problem
of needing micro-architecture-specific packages (which seems to be
against policy, although atlas does it).

> In its 
> current state (which has been the state since its inception), ATLAS is 
> really unsuitable for distribution packaging. They just do not care about 
> binary packages, at all.

I don't know whether that's true, but Fedora could at least improve the
situation by providing more than the -sse2 and -sse3 packages.

>> on the premise that scientific codes are compiled specificlly for their
>> target clusters anyway
>
> … which is of course not true for distribution packages!

I might note that, typically, people who insist on specific compilation
haven't made relevant measurements -- I know that's not true generally
-- e.g. the myths about MKL et al.  Where reasonable, the computational
kernels that are sensitive to SIMD should be abstracted into libraries
like openblas, libxsmm, fftw, elpa, etc.

>> and Intel's math library (MKL) doesn't provide a drop-in replacement.
>
> … which is entirely irrelevant.
>
> It is the job of the distribution to ensure that software uses the most 
> efficient BLAS/LAPACK implementation available. Other distributions ship 
> symlinks ensuring that. The current packaging in Fedora is horrible.

I presume that means the most efficient free implementation.  On avx512,
that's BLIS (+libxsmm), but MKL is still substantially faster.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Is it possible atlas is linked wrongly by new binutils?

[Dave Love]

Matthew Miller  writes:

> On Sun, Aug 13, 2017 at 11:01:04AM +0200, Kevin Kofler wrote:
>> Can't we make it a drop-in replacement for reference BLAS/LAPACK and ATLAS, 
>> i.e., having symlinks or linker scripts pointing at least libblas.so and 
>> liblapack.so to libopenblas.so.*, ideally also libblas.so.3 and 
>> liblapack.so.3 so that no rebuilds are necessary and so that things using 
>> dlopen and third-party binary blobs also use OpenBLAS?
>> 
>> The current situation where we have 3 different BLAS implementations and 
>> where for most programs, depending on your setup, you get either the worst 
>> one (reference BLAS) or a suboptimal one (ATLAS compiled for the baseline 
>> architecture), but never the best one (OpenBLAS with runtime CPU detection), 
>> is a mess.
>
> This sounds like a good idea (and worthy of a Change). I hate to
> suggest Alternatives but maybe it's appropriate here? 

The sane Debian approach was rejected in committee previously.

There's some discussion and a technique for subverting the non-optimal
BLAS/LAPACK at .
[I actually only care about EPEL, and presumably RHEL's treatment of
linear algebra won't change.]

To support libraries which don't dispatch on the micro-architecture
(like BLIS, currently) it would be useful if SIMD hardware capabilities
were supported.  I could never find useful doc on those, but as far as I
can tell, there's no such support on x86, at least.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org