Re: Release criteria proposal: drop kickstart package criterion

[Adam Williamson]

On Tue, 2018-06-05 at 21:29 -0400, Neal Gompa wrote:
> 
> I'm not in favor of this change. Actually, what concerns me is that
> there's an underlying problem that caused Adam to propose this: there
> are only a few people with the necessary permissions to be able to
> prepare the release, and that this is a manual process that is
> forgotten often.
> 
> If we were to say: "hey guys, we're just gonna use these autogen'd git
> tag thingies from now on", what stops us from just autogenerating a
> push to generate the required package and have it built in Koji to be
> part of the distribution release?

Two things.

One, auto-building packages is significantly more complex than auto-
tagging a git repo. The git repo is a one-liner: 'git tag {composeid}'.
Building a package is...not. (It also requires privileges the build
process does not have, I don't think).

Two, you missed an important step: things don't go from Koji to 'the
distribution release'. They have to go through Bodhi, and that is by
design *not* automatable during a freeze. Only things that are manually
accepted as release blockers or FEs get through the freeze. That's a
whole other set of hoops to jump through.

> And perhaps this is something that doesn't get talked about much
> anymore, but I know that when I'm presenting Fedora to people, they
> *like* that it's only a couple of package installs away to get
> everything in place to make spins or remixes. And being able to offer
> in the distribution *everything* needed to build it is powerful.

Is 'git clone {url}; git checkout {branch}' that onerous?

> We've been bad about this in recent releases, sure. But why can't we
> look at making that process better, rather than throwing out the baby
> with the bathwater?

There's been about seven years in which that could have happened. It
hasn't. I'm not waiting any longer.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/SUA6HO4NNIR2MH4P6VBV66GGOUF52ULM/

Re: Self Introduction

[Feather Lin]

Hello Jerry,
Thank you! (謝謝！） Yes the 歡迎光臨 is mean welcome the people.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/ASYNZJW6TGIU4GIUYWKCJPIBEWF6GZHK/

Re: F29 System Wide Change: Strong crypto settings: phase 2

[Chris Murphy]

On Tue, Jun 5, 2018 at 2:27 PM, John Florian  wrote:
> On 06/05/2018 12:55 PM, Chris Murphy wrote:
>>
>> I don't understand the motivation of departing from upstreams, which
>> by their nature are on a knife's edge balancing security and practical
>> use in the real world. Why second guess that effort and on what basis?
>
> Totally agree!
>>
>> Slightly off topic as an anecdote, but the Payment Card Industry Data
>> Security Standard (PCI DSS) is only calling for the end to TLS 1.0
>> support at the end of this month, recommending TLS 1.2 but permitting
>> TLS 1.1. This is the spec for transmitting people's credit card
>> magnetic stripe/chip information for payment authorizations. Now maybe
>> that's a bit eyebrow raising, but if they're willing to take the risk
>> of allowing TLS 1.1 for such a use case, I hardly think Fedora should
>> be jumping the gun.
>
> That's why there's transaction fees.  Oops!  Oh well, here's a few million
> to deal with that.  They advertise like they can't get rid of the money fast
> enough.  I always figured the Visa "Magic Moments" were something like hot
> database redirection where some transactions fell off the end of the cable,
> landed on the floor and turned into customer's lucky day simply due to the
> timing.  Like it was easier/cheaper to give away the fruits rather than fix
> the real problem.

Yes that's true, and so the analogy fails on this point, they're
effectively dragging everyone into an insurance racket. But the contra
argument is Fedora isn't providing guarantees or charging fees, and
we're not on questionable footing by following the lead of upstreams
on the issue of security.

> I doubt it's actually like that, but I do bet they have more luxury than
> Fedora does.  While I'd prefer the best security, I don't want it at the
> risk of things being broken.  I don't have the confidence that my work
> around is as safe as an older more trusting Fedora. When I see those cipher
> suite strings my head just goes into a tailspin.


I think second guessing any upstream is fair. But it also comes with
burden of making a really compelling argument that upstream is isn't
adequately serving Fedora community interests. And that argument needs
to be dropped in the lap of the upstream so they have a chance of
responding to the criticism.

Maybe it makes more sense Fedora is aggressive on security by default,
and we push flatpak versions of Firefox (or other browser) configured
to support TLS 1.0 and 1.1 as the way to provide legacy support. But
my first instinct is that Fedora's in parity with upstream, and the
Security spin folks can produce the more aggressively secure variant.
*shrug*


-- 
Chris Murphy
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/IN7CZESP6Q4RBAS4O7CGGMPYNTWN66ZB/

Re: F29 System Wide Change: i686 Is For x86-64

[Dennis Gilmore]

El mar, 05-06-2018 a las 15:59 -0400, Adam Jackson escribió:
> On Tue, 2018-06-05 at 13:20 -0500, Dennis Gilmore wrote:
> 
> > as part of this change I suspect we would need to make kernel
> > changes
> > to stop building a i686 kernel, and all i686 deliverables would
> > stop
> > being made.
> 
> We would?
It may be a bad assumption on my part, I am assuming that optimising to
run on x86_64 means that we will not be able to run on any actual
x86_32 hardware.

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
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/ZZ65EEUBDU7YHBUYKQ2X5IYX7KSSTDID/

Re: Release criteria proposal: drop kickstart package criterion

[Neal Gompa]

On Tue, Jun 5, 2018 at 9:21 PM Josh Boyer  wrote:
>
> On Tue, Jun 5, 2018 at 2:13 AM Zbigniew Jędrzejewski-Szmek
>  wrote:
> >
> > On Tue, Jun 05, 2018 at 02:26:25AM +0100, Peter Robinson wrote:
> > > On Tue, Jun 5, 2018 at 12:39 AM, Adam Williamson
> > >  wrote:
> > > > Hi, folks!
> > > >
> > > > We currently have a Final release criterion that reads as follows:
> > > >
> > > > "A spin-kickstarts package which contains the exact kickstart files
> > > > used to build the release must be present in the release repository.
> > > > The included kickstarts must define the correct set of release
> > > > repositories.
> > > >
> > > > Why?
> > > >
> > > > This is considered part of Fedora's duty to be 'self-hosting': the
> > > > kickstarts used to produce the release images are a vital piece of
> > > > information required to duplicate that release, so they must be
> > > > preserved along with the release."
> > > >
> > > > Lately this requirement has been fairly annoying in practice. Updating
> > > > the package prior to release does not appear to be in anyone's regular
> > > > schedule, so invariably what happens is shortly before the release
> > > > deadline I realize we haven't built a 'release' spin-kickstarts package
> > > > and have to file a blocker bug and ping people with the necessary
> > > > permissions (of which there are only a few) to build one in a tearing
> > > > hurry. Then we have to approve the blocker bug and push the updated
> > > > package through the freeze, all wasting time we could be spending on
> > > > more important fixes.
> > > >
> > > > The benefit here is really fairly tiny, as well. It's arguable whether
> > > > anyone cares particularly whether a Fedora release, as a frozen
> > > > artifact, is 100% internally reproducible (and I'm not sure whether our
> > > > releases actually *are* reproducible in any case, these days, I'm not
> > > > at all sure we ship all the necessary metadata and so on for *every
> > > > single deliverable* within the distribution).
> > > >
> > > > These days I'd suggest it should be quite acceptable to simply use git
> > > > tags for this purpose. It should be quite easy for rel-eng to adjust
> > > > the release scripts to create a tag in the fedora-kickstarts repo (and
> > > > why not fedora-comps too, while we're at it) for each 'candidate'
> > > > compose, named for the compose ID. That would make it very easy to
> > > > access the correct kickstarts for any Fedora candidate compose just by
> > > > a 'git checkout', with no need for the cumbersome work of getting the
> > > > package into the compose.
> > > >
> > > > Naturally this would go along with updates to any relevant docs or wiki
> > > > pages, recommending to use the git repository instead of the RPM
> > > > packages, and explaining the tagging scheme. As for the package, we
> > > > could either keep it but not sweat about updating it for each release,
> > > > retire it entirely, or change it to contain only a text file pointing
> > > > to the git repository (or to the doc / wiki page that explains the git
> > > > repo location and tagging strategy).
> > > >
> > > > Thoughts? Thanks!
> > >
> > > It makes perfect sense, the package is not actually shipped as part of
> > > any of the actual deliverable artifacts and they're widely available
> > > in a public git repository for people to consume so it's not reducing
> > > the ability to reproduce Fedora, we don't rush around and ensure all
> > > the tools that might need last minute patches in the compose process
> > > are all tagged stable in the release either so I don't see actually
> > > shipping this package as stable makes any difference in reality, we
> > > don't even use the package in the compose process, we pull the
> > > kickstarts directly from git.
> >
> > +1 too.
>
> Yes, let's do what makes sense.  I like the proposal.
>

I'm not in favor of this change. Actually, what concerns me is that
there's an underlying problem that caused Adam to propose this: there
are only a few people with the necessary permissions to be able to
prepare the release, and that this is a manual process that is
forgotten often.

If we were to say: "hey guys, we're just gonna use these autogen'd git
tag thingies from now on", what stops us from just autogenerating a
push to generate the required package and have it built in Koji to be
part of the distribution release?

And perhaps this is something that doesn't get talked about much
anymore, but I know that when I'm presenting Fedora to people, they
*like* that it's only a couple of package installs away to get
everything in place to make spins or remixes. And being able to offer
in the distribution *everything* needed to build it is powerful.

We've been bad about this in recent releases, sure. But why can't we
look at making that process better, rather than throwing out the baby
with the bathwater?


-- 
真実はいつも一つ！/ Always, there's only one truth!
___
devel mailing l

Self Introduction: Alois Mahdal

[Alois Mahdal]

Hi everyone!

My name is Alois Mahdal ('netvor' on FAS, freenode and other places),
and I'm QE Engineer at Red Hat -- that is for last ~4.5 years.  I live
in Brno, Czech Republic.

I've been FLOSS user/fan/enthusiast/advocate for about last 10 years or
so, using GNU/Linux distros exclusively for over 5 years.  I love coding
and designing software, and although most of my creations are basically
just for my own use, I do keep releasing them in the wild when I can ---
if only to motivate myself to write less ugly code.

I've filed some bugs, pushed some repos to Github, but my first attempt
for "more serious" contribution to Fedora has arrived just few minutes
ago[1].

OK, enough self-presentation, see my https://netvor.info/ for links to
my other Keybase github's, gitea's, twitter's, etc.)

  [1]: https://bugzilla.redhat.com/show_bug.cgi?id=1586291

Thanks,
aL.

-- 
Alois Mahdal 
Platform QE Engineer at Red Hat, Inc.
#brno, #daemons, #preupgrade
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/2GPSPEZE56GT3IRXUMF3ZUF7PRDIVMEP/

Re: [X86] Fwd: F29 System Wide Change: i686 Is For x86-64

[Jeff Backus]

On Tue, Jun 5, 2018 at 1:54 PM, Stephen John Smoogen 
wrote:

> On 5 June 2018 at 12:49, Jeff Backus  wrote:
> >
> >
> > On Mon, Jun 4, 2018 at 10:07 PM, Matthew Miller <
> mat...@fedoraproject.org>
> > wrote:
> >>
> >> On Mon, Jun 04, 2018 at 03:50:34PM -0400, Jeff Backus wrote:
> >> > Thanks for the data. 25k is still a pretty healthy number. :) I
> realize
> >>
> >> Yeah, absolutely. And it's likely that those mirror numbers undercount,
> >> because not every system checks in daily, and then there's also NAT.
> >>
> >> But, my gut feeling is that about half of those are not using a current
> >> release _anyway_. Honest question: do you think that 12k would still
> >> count as a healthy number? I mean, it's not peanuts. But maybe it'd be
> >> better served by a Fedora remix (or similar) specifically targetting
> >> older and low-powered systems?
> >
> >
> > Good question. I think it would be more productive to think in
> percentages
> > instead of raw numbers, in this case. There are a lot of FOSS projects
> out
> > there that would love to have 12k users. :)
> >
> > Certainly, I would consider 10% a healthy number when talking about
> portion
> > of user base. I would even argue that 1% is still a healthy number,
> > particularly with regard to decisions that have a reasonable chance of
> > disenfranchising those affected. While I hate seeing people leave a
> > community, I wouldn't be able to defend 0.1%. So, somewhere in there is
> my
> > general boundary.
> >
> > Now cost changes all of that, of course. Obviously if 75% of our effort
> is
> > going to please 10%, then 10% isn't a healthy number.
> >
> > Clearly effort is going into enabling Fedora to work on non-SSE2 systems
> by
> > teams invested in the success of Fedora in general and not the success of
> > non-SSE2 systems in particular. I just don't know how to quantify it.
> >
> > Based on Smooge's awesome numbers, it looks like x86_32 is in the 2.3%
> > range. It would be interesting to see how this stacks up to AArch64 and
> > other secondary arches. Unfortunately, what complicates things is how
> x86_32
> > is so intertwined with x86_64.
> >
>
> It is also complicated in that most of the large sites using aarch64
> and arm32 do so in ways which make them uncountable. They will have
> 'thousands' of nodes but all of them use an internal mirror so we see
> them as only 1..
>

Good point. Does this affect x86_64, as well?


> The other issue is that the arm/aarch64 have active upstream help from
> people who are building the boards. There isn't any such support on
> the x86_32 side with the manufacturers getting to the point of saying
> "here is $20.00 and an ebay link.. buy at least a  pentium iv or v
> please. " The question that the x86 group needs to figure out is how
> many of the 3800 active systems are going to not have SSE2.
>

re: upstreams - Agreed. Clearly we are on borrowed time.

re: SSE2 - Agreed. We might be able to do some clever filtering with
Bugzilla to get an idea...


> > To your point re: a remix, that is an option we've discussed within the
> SIG
> > and is one we are open to exploring. A remix wouldn't resolve issues
> > introduced by enabling SSE2 by default, unless we maintained a parallel
> set
> > of packages e.g. i586 (which I've already been warned about. :) )
> >
> >>
> >> > that there are a lot of unknowns in the data, so it is difficult to
> draw
> >> > any hard conclusions, but 25k is still much larger than 0. Splitting
> >> > into
> >> > i686 into i586 and i686 would give more insight into who still needs
> >> > non-SSE2... Probably hurts my argument, though. :)
> >>
> >> Soo this is the kind of thing that more a detailed hardware
> >> census could really help us with!
> >
> >
> > Yes, I would agree :)
> >
>
> So it would probably be a lot more detailed than other sites are
> running. I looked at the popcorn data and they seem to count whether
> an OS is i386 or amd64 not if the CPU is pentium iii. Neither did any
> of the other OS census programs.
>

Thanks for looking. It's unfortunate, but not surprising.

-- 
Jeff Backus
jeff.bac...@gmail.com
http://github.com/jsbackus
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/N5KOEDV5N5DA5B45UT3WIRCFTGNUODN4/

Re: Firefox is crashing constantly?

[Chris Murphy]

The bug:

https://bugzilla.redhat.com/show_bug.cgi?id=1568097
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/BPTHDU7NYFPQUHDLNYD3JD5MLT4LVUIY/

Firefox is crashing constantly?

[Chris Murphy]

Since, firefox-60.0.1-5.fc28.x86_64 and unchanged with
firefox-60.0.1-6.fc28.x86_64 I'm getting a dozen random crashes per
day. It's not reproducible, near as I can tell, but happens often
whether clicking on a link, typing in a field, or just looking away
and having touched nothing.

Abrt points me to this bug. I attached the output from processing the
crash with coredumpctl gdb.

I guess maybe I'll revert to -4 and see if that solves the problem.



-- 
Chris Murphy
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/KXOEWI5XGFNIJ3MQY2ACGGWCD5D5UBQH/

Re: F29 System Wide Change: Strong crypto settings: phase 2

[John Florian]

On 06/05/2018 12:25 PM, Tomas Mraz wrote:

On Tue, 2018-06-05 at 16:11 +, Christian Stadelmann wrote:

"Fallback option" always smells like "protocol downgrade attack".
This would undermine the idea of a crypto policy. Anyway,
implementing it seems way out of scope for the crypto policy.

Yes, a fallback option is a no-way. You can switch the system policy to
LEGACY, however that does not necessarily mean that some very old
legacy HW will start to work with Firefox or another web browser,
because with newer versions of the browsers and newer versions of
TLS/crypto libraries some very old and insecure algorithm and protocol
support is being also removed.



Makes sense, but what is the best way to deal with such old HW if you're 
stuck with it?  I don't want to compromise my workstation for all my 
normal needs just to deal with some ancient embedded https server, but 
it would kind of suck to have to boot some old live image just to do 
some routine config change.  It seems the industry has room for 
improvement here.

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/3J6I2UK3QPE6THJBJVYNLTX3ZTF5WIAM/

Re: F29 System Wide Change: Strong crypto settings: phase 2

[John Florian]

On 06/05/2018 12:55 PM, Chris Murphy wrote:

I don't understand the motivation of departing from upstreams, which
by their nature are on a knife's edge balancing security and practical
use in the real world. Why second guess that effort and on what basis?

Totally agree!

Slightly off topic as an anecdote, but the Payment Card Industry Data
Security Standard (PCI DSS) is only calling for the end to TLS 1.0
support at the end of this month, recommending TLS 1.2 but permitting
TLS 1.1. This is the spec for transmitting people's credit card
magnetic stripe/chip information for payment authorizations. Now maybe
that's a bit eyebrow raising, but if they're willing to take the risk
of allowing TLS 1.1 for such a use case, I hardly think Fedora should
be jumping the gun.
That's why there's transaction fees.  Oops!  Oh well, here's a few 
million to deal with that.  They advertise like they can't get rid of 
the money fast enough.  I always figured the Visa "Magic Moments" were 
something like hot database redirection where some transactions fell off 
the end of the cable, landed on the floor and turned into customer's 
lucky day simply due to the timing.  Like it was easier/cheaper to give 
away the fruits rather than fix the real problem.


I doubt it's actually like that, but I do bet they have more luxury than 
Fedora does.  While I'd prefer the best security, I don't want it at the 
risk of things being broken.  I don't have the confidence that my work 
around is as safe as an older more trusting Fedora. When I see those 
cipher suite strings my head just goes into a tailspin.

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/BQ54WDRZ3F4ATFGFYCJSMI6NY2BNNVCU/

Re: Release criteria proposal: drop kickstart package criterion

[John Florian]

On 06/05/2018 07:59 AM, Stephen Gallagher wrote:



On Tue, Jun 5, 2018 at 7:13 AM Josh Boyer > wrote:


On Tue, Jun 5, 2018 at 2:13 AM Zbigniew Jędrzejewski-Szmek
mailto:zbys...@in.waw.pl>> wrote:
>
> On Tue, Jun 05, 2018 at 02:26:25AM +0100, Peter Robinson wrote:
> > On Tue, Jun 5, 2018 at 12:39 AM, Adam Williamson
> > mailto:adamw...@fedoraproject.org>> wrote:
> > > Hi, folks!
> > >
> > > We currently have a Final release criterion that reads as
follows:
> > >
> > > "A spin-kickstarts package which contains the exact
kickstart files
> > > used to build the release must be present in the release
repository.
> > > The included kickstarts must define the correct set of release
> > > repositories.
> > >
> > > Why?
> > >
> > > This is considered part of Fedora's duty to be
'self-hosting': the
> > > kickstarts used to produce the release images are a vital
piece of
> > > information required to duplicate that release, so they must be
> > > preserved along with the release."
> > >
> > > Lately this requirement has been fairly annoying in
practice. Updating
> > > the package prior to release does not appear to be in
anyone's regular
> > > schedule, so invariably what happens is shortly before the
release
> > > deadline I realize we haven't built a 'release'
spin-kickstarts package
> > > and have to file a blocker bug and ping people with the
necessary
> > > permissions (of which there are only a few) to build one in
a tearing
> > > hurry. Then we have to approve the blocker bug and push the
updated
> > > package through the freeze, all wasting time we could be
spending on
> > > more important fixes.
> > >
> > > The benefit here is really fairly tiny, as well. It's
arguable whether
> > > anyone cares particularly whether a Fedora release, as a frozen
> > > artifact, is 100% internally reproducible (and I'm not sure
whether our
> > > releases actually *are* reproducible in any case, these
days, I'm not
> > > at all sure we ship all the necessary metadata and so on for
*every
> > > single deliverable* within the distribution).
> > >
> > > These days I'd suggest it should be quite acceptable to
simply use git
> > > tags for this purpose. It should be quite easy for rel-eng
to adjust
> > > the release scripts to create a tag in the fedora-kickstarts
repo (and
> > > why not fedora-comps too, while we're at it) for each
'candidate'
> > > compose, named for the compose ID. That would make it very
easy to
> > > access the correct kickstarts for any Fedora candidate
compose just by
> > > a 'git checkout', with no need for the cumbersome work of
getting the
> > > package into the compose.
> > >
> > > Naturally this would go along with updates to any relevant
docs or wiki
> > > pages, recommending to use the git repository instead of the RPM
> > > packages, and explaining the tagging scheme. As for the
package, we
> > > could either keep it but not sweat about updating it for
each release,
> > > retire it entirely, or change it to contain only a text file
pointing
> > > to the git repository (or to the doc / wiki page that
explains the git
> > > repo location and tagging strategy).
> > >
> > > Thoughts? Thanks!
> >
> > It makes perfect sense, the package is not actually shipped as
part of
> > any of the actual deliverable artifacts and they're widely
available
> > in a public git repository for people to consume so it's not
reducing
> > the ability to reproduce Fedora, we don't rush around and
ensure all
> > the tools that might need last minute patches in the compose
process
> > are all tagged stable in the release either so I don't see
actually
> > shipping this package as stable makes any difference in
reality, we
> > don't even use the package in the compose process, we pull the
> > kickstarts directly from git.
>
> +1 too.

Yes, let's do what makes sense.  I like the proposal.


And my axe! Err, or my +1, yeah.


Ditto!  I've referenced these a number of times to see where my variants 
have gone astray, but have always used the git repo for this and hadn't 
even thought of looking for such an artifact.  The proposal of tags and 
docs will only make this easier.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/YKGYRR3

Re: F29 System Wide Change: i686 Is For x86-64

[Adam Jackson]

On Tue, 2018-06-05 at 13:20 -0500, Dennis Gilmore wrote:

> as part of this change I suspect we would need to make kernel changes
> to stop building a i686 kernel, and all i686 deliverables would stop
> being made.

We would?

- ajax
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/52TT3XLRTVUUHSGB7YPOM6RXXC2UTPNB/

Re: Intent to drop python2-notebook

[Jerry James]

On Tue, Jun 5, 2018 at 10:50 AM, Miro Hrončok  wrote:

> Let's bring it back.
>

Thank you, Miro, and sorry again for the trouble.  I'm serious about
helping to maintain the package, too, so let me know what I can do on that
score.

The second sagemath upstream releases a python 3 version, we can drop quite
a few python 2 packages out of Fedora.  I'll let everybody know when that
happens.
-- 
Jerry James
http://www.jamezone.org/
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/QPKI3ORJ3EP4PUXNZJ6CVRCUH3XNIAW7/

Re: F29 System Wide Change: i686 Is For x86-64

[Dennis Gilmore]

as part of this change I suspect we would need to make kernel changes
to stop building a i686 kernel, and all i686 deliverables would stop
being made. With the current tooling we would never be able to build 32
bit x86 containers, which is not something that is done today.  I would
also be curious what the plan is to test the 32 bit bits. they are
likely to get significantly less testing than the little they get
today.

Dennis

El lun, 04-06-2018 a las 10:35 +0200, Jan Kurik escribió:
> = Proposed System Wide Change: i686 Is For x86-64 =
> https://fedoraproject.org/wiki/Changes/i686_Is_For_x86-64
> 
> 
> Owner(s):
>   * Florian Weimer 
> 
> 
> Fedora builds its i686 packages for use on x86-64 systems as multi-
> lib RPMs.
> 
> 
> 
> == Detailed description ==
> Currently, the i686 RPM packages are built in such a way that they
> are
> compatible with very old i686 systems, such as the Pentium III.  The
> only addition over the i686/Pentium Pro baseline is a requirement to
> support long NOPs, for Intel CET.  However, the majority of
> installations of i686 packages is for use on x86_64 systems, as
> multi-lib RPMs.  Furthermore, there are reports that the i686 kernel
> does not run stable on old hardware which is not x86-64-capable (
> https://lists.fedoraproject.org/archives/list/x86@lists.fedoraproject
> .org/thread/ZHV6I4IEO7GRYAZ4TUMO5VH2ZHLCNJZQ/
> ).
> This proposal suggests to accept this reality and build the i686
> packages in such a way that they require the ISA level of (early)
> x86-64 CPUs.
> 
> 
> == Scope ==
> * Proposal owners:
> Adjust the redhat-rpm-config, gcc, and glibc packages to switch to
> the
> new compiler flags. Except for mstackrealign, there is substantial
> experience with this configuration downstream.
> 
> * Other developers:
> Other developers can enable SSE2 optimization in their packages if
> they want, where this has been a compile-time option only.
> 
> * Release engineering:
> https://pagure.io/releng/issues/7543 #7543
> 
> ** List of deliverables: TBD
> 
> * Policies and guidelines:
> i686 is no longer a primary architecture. The Packaging Guidelines do
> not currently require support for non-SSE2 x86 systems, so no change
> is required there.
> 
> * Trademark approval:
> N/A (not needed for this Change)
> -- 
> Jan Kuřík
> JBoss EAP 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
> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelin
> es
> List Archives: https://lists.fedoraproject.org/archives/list/devel@li
> sts.fedoraproject.org/message/CC22ZTFDB5L3BFSQG7M3TUZUVYKFUSKP/

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
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/MXGUMNK7H4PEEOKPB72YNPN7OEX3IRCN/

Re: [X86] Fwd: F29 System Wide Change: i686 Is For x86-64

[Josh Boyer]

On Tue, Jun 5, 2018 at 1:55 PM Stephen John Smoogen  wrote:
>
> On 5 June 2018 at 12:49, Jeff Backus  wrote:
> >
> >
> > On Mon, Jun 4, 2018 at 10:07 PM, Matthew Miller 
> > wrote:
> >>
> >> On Mon, Jun 04, 2018 at 03:50:34PM -0400, Jeff Backus wrote:
> >> > Thanks for the data. 25k is still a pretty healthy number. :) I realize
> >>
> >> Yeah, absolutely. And it's likely that those mirror numbers undercount,
> >> because not every system checks in daily, and then there's also NAT.
> >>
> >> But, my gut feeling is that about half of those are not using a current
> >> release _anyway_. Honest question: do you think that 12k would still
> >> count as a healthy number? I mean, it's not peanuts. But maybe it'd be
> >> better served by a Fedora remix (or similar) specifically targetting
> >> older and low-powered systems?
> >
> >
> > Good question. I think it would be more productive to think in percentages
> > instead of raw numbers, in this case. There are a lot of FOSS projects out
> > there that would love to have 12k users. :)
> >
> > Certainly, I would consider 10% a healthy number when talking about portion
> > of user base. I would even argue that 1% is still a healthy number,
> > particularly with regard to decisions that have a reasonable chance of
> > disenfranchising those affected. While I hate seeing people leave a
> > community, I wouldn't be able to defend 0.1%. So, somewhere in there is my
> > general boundary.
> >
> > Now cost changes all of that, of course. Obviously if 75% of our effort is
> > going to please 10%, then 10% isn't a healthy number.
> >
> > Clearly effort is going into enabling Fedora to work on non-SSE2 systems by
> > teams invested in the success of Fedora in general and not the success of
> > non-SSE2 systems in particular. I just don't know how to quantify it.
> >
> > Based on Smooge's awesome numbers, it looks like x86_32 is in the 2.3%
> > range. It would be interesting to see how this stacks up to AArch64 and
> > other secondary arches. Unfortunately, what complicates things is how x86_32
> > is so intertwined with x86_64.
> >
>
> It is also complicated in that most of the large sites using aarch64
> and arm32 do so in ways which make them uncountable. They will have
> 'thousands' of nodes but all of them use an internal mirror so we see
> them as only 1..
>
> The other issue is that the arm/aarch64 have active upstream help from
> people who are building the boards. There isn't any such support on
> the x86_32 side with the manufacturers getting to the point of saying
> "here is $20.00 and an ebay link.. buy at least a  pentium iv or v
> please. " The question that the x86 group needs to figure out is how
> many of the 3800 active systems are going to not have SSE2.
>
>
>
> > To your point re: a remix, that is an option we've discussed within the SIG
> > and is one we are open to exploring. A remix wouldn't resolve issues
> > introduced by enabling SSE2 by default, unless we maintained a parallel set
> > of packages e.g. i586 (which I've already been warned about. :) )
> >
> >>
> >> > that there are a lot of unknowns in the data, so it is difficult to draw
> >> > any hard conclusions, but 25k is still much larger than 0. Splitting
> >> > into
> >> > i686 into i586 and i686 would give more insight into who still needs
> >> > non-SSE2... Probably hurts my argument, though. :)
> >>
> >> Soo this is the kind of thing that more a detailed hardware
> >> census could really help us with!
> >
> >
> > Yes, I would agree :)
> >
>
> So it would probably be a lot more detailed than other sites are
> running. I looked at the popcorn data and they seem to count whether
> an OS is i386 or amd64 not if the CPU is pentium iii. Neither did any
> of the other OS census programs.

I think this is a red herring.  We have no concrete plans around an
improved hardware census and the goals of such a service aren't to
count how many 32-bit x86 installs we have anyway.  It's fine to
discuss this, but it should be done in a separate thread.  Likely from
the viewpoint of justifying an i586 effort by the x86 SIG.

It should not have any bearing on the proposed Change though.  With no
set timeframe for even having people to drive forward with the idea
for a hardware census tool, let alone software actually written to do
it, involving that in this discussion is kicking the can down the road
indefinitely.

josh
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/3H5OAY7URJADVQL5DBQ7XMTVUIO2C7YI/

Re: [X86] Fwd: F29 System Wide Change: i686 Is For x86-64

[Stephen John Smoogen]

On 5 June 2018 at 12:49, Jeff Backus  wrote:
>
>
> On Mon, Jun 4, 2018 at 10:07 PM, Matthew Miller 
> wrote:
>>
>> On Mon, Jun 04, 2018 at 03:50:34PM -0400, Jeff Backus wrote:
>> > Thanks for the data. 25k is still a pretty healthy number. :) I realize
>>
>> Yeah, absolutely. And it's likely that those mirror numbers undercount,
>> because not every system checks in daily, and then there's also NAT.
>>
>> But, my gut feeling is that about half of those are not using a current
>> release _anyway_. Honest question: do you think that 12k would still
>> count as a healthy number? I mean, it's not peanuts. But maybe it'd be
>> better served by a Fedora remix (or similar) specifically targetting
>> older and low-powered systems?
>
>
> Good question. I think it would be more productive to think in percentages
> instead of raw numbers, in this case. There are a lot of FOSS projects out
> there that would love to have 12k users. :)
>
> Certainly, I would consider 10% a healthy number when talking about portion
> of user base. I would even argue that 1% is still a healthy number,
> particularly with regard to decisions that have a reasonable chance of
> disenfranchising those affected. While I hate seeing people leave a
> community, I wouldn't be able to defend 0.1%. So, somewhere in there is my
> general boundary.
>
> Now cost changes all of that, of course. Obviously if 75% of our effort is
> going to please 10%, then 10% isn't a healthy number.
>
> Clearly effort is going into enabling Fedora to work on non-SSE2 systems by
> teams invested in the success of Fedora in general and not the success of
> non-SSE2 systems in particular. I just don't know how to quantify it.
>
> Based on Smooge's awesome numbers, it looks like x86_32 is in the 2.3%
> range. It would be interesting to see how this stacks up to AArch64 and
> other secondary arches. Unfortunately, what complicates things is how x86_32
> is so intertwined with x86_64.
>

It is also complicated in that most of the large sites using aarch64
and arm32 do so in ways which make them uncountable. They will have
'thousands' of nodes but all of them use an internal mirror so we see
them as only 1..

The other issue is that the arm/aarch64 have active upstream help from
people who are building the boards. There isn't any such support on
the x86_32 side with the manufacturers getting to the point of saying
"here is $20.00 and an ebay link.. buy at least a  pentium iv or v
please. " The question that the x86 group needs to figure out is how
many of the 3800 active systems are going to not have SSE2.



> To your point re: a remix, that is an option we've discussed within the SIG
> and is one we are open to exploring. A remix wouldn't resolve issues
> introduced by enabling SSE2 by default, unless we maintained a parallel set
> of packages e.g. i586 (which I've already been warned about. :) )
>
>>
>> > that there are a lot of unknowns in the data, so it is difficult to draw
>> > any hard conclusions, but 25k is still much larger than 0. Splitting
>> > into
>> > i686 into i586 and i686 would give more insight into who still needs
>> > non-SSE2... Probably hurts my argument, though. :)
>>
>> Soo this is the kind of thing that more a detailed hardware
>> census could really help us with!
>
>
> Yes, I would agree :)
>

So it would probably be a lot more detailed than other sites are
running. I looked at the popcorn data and they seem to count whether
an OS is i386 or amd64 not if the CPU is pentium iii. Neither did any
of the other OS census programs.


-- 
Stephen J Smoogen.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/BI4EB53BMDKDDNJDPMBQ3ZTI2AVOGUCK/

Re: F29 System Wide Change: Strong crypto settings: phase 2

[mcatanzaro]

On Fri, Jun 1, 2018 at 6:40 AM, Jan Kurik  wrote:

and weak
Diffie-Hellman key exchange sizes (1024 bit)


What size is currently required by upstream Firefox and Chrome?

The most recent reference I could find is 
https://groups.google.com/a/chromium.org/forum/#!topic/security-dev/WyGIpevBV1s 
which suggests they are still using 1024.


Michael
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/UGWSYDWBCTALCQ5B2MKYXFLKE47S7BCM/

Re: F29 System Wide Change: Strong crypto settings: phase 2

[Chris Murphy]

I don't understand the motivation of departing from upstreams, which
by their nature are on a knife's edge balancing security and practical
use in the real world. Why second guess that effort and on what basis?

Slightly off topic as an anecdote, but the Payment Card Industry Data
Security Standard (PCI DSS) is only calling for the end to TLS 1.0
support at the end of this month, recommending TLS 1.2 but permitting
TLS 1.1. This is the spec for transmitting people's credit card
magnetic stripe/chip information for payment authorizations. Now maybe
that's a bit eyebrow raising, but if they're willing to take the risk
of allowing TLS 1.1 for such a use case, I hardly think Fedora should
be jumping the gun.

The Secure Spin folks could make a different decision for their
Firefox if they want, or maybe a flatpak of Firefox could have more
aggressive security by default. But I don't see the value in departing
from the upstreams and confusing users.

Chris Murphy
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/ISOX36KH7Z7FN6QRCQS6YGROOOILNHRC/

Re: F29 System Wide Change: Strong crypto settings: phase 2

[Adam Williamson]

On Tue, 2018-06-05 at 09:47 -0700, Adam Williamson wrote:
> On Tue, 2018-06-05 at 17:59 +0200, Till Maas wrote:
> > On Tue, Jun 05, 2018 at 08:08:00AM -0700, Adam Williamson wrote:
> > 
> > > I don't know, but it seems worth considering, and my basic point here
> > > is this is something the Change owner should be responsible for
> > > figuring out: making at least a reasonable effort to evaluate which
> > > important (particularly release-critical) software and workflows will
> > > be affected by the change and proposing plans for testing them. "we
> > > should check curl behaves as expected" just doesn't really cut it as a
> > > test plan.
> > 
> > Should we add a QA review step to the change process to address this?
> 
> That's, er, sort of what I'm doing. The Change has been proposed. I'm
> reviewing it. :P

Sorry, I was being a bit loose for the purpose of flippancy there :P I
should make it clear that it's not just *me* reviewing it. We (QA)
review and discuss the proposed Changes for each release in our group
meetings. My comments on this change and the grub menu change were not
just my personal thoughts but me relaying the outcome of our
discussions about those Changes. You can see this in the minutes and
logs of our meeting this week:

https://meetbot-raw.fedoraproject.org/teams/fedora-qa/fedora-qa.2018-06-04-15.00.html
https://meetbot-raw.fedoraproject.org/teams/fedora-qa/fedora-qa.2018-06-04-15.00.log.html
-- 
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
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/MLJCQC6U354Q6Z5YQ3OVXDX4SGTBY3PU/

Re: Intent to drop python2-notebook

[Miro Hrončok]

On 5.6.2018 18:42, Miro Hrončok wrote:

On 5.6.2018 18:21, Jerry James wrote:
On Tue, Jun 5, 2018 at 9:30 AM, Miro Hrončok > wrote:


    On 11.5.2018 17:54, Miro Hrončok wrote:

    python2-notebook is a leaf package (nothing in Fedora
    (build)requires it). I'd like to drop it from rawhide. Any
    objections?

    Dropped.


Uh oh.  I just added both a BR and an R from sagemath to 
python2-notebook a couple of days ago, because sagemath does require it.


Does it require all of it? It's not a library. Can we see what exactly 
is required and why maybe? How is it used - via Python imports or via 
the command form /usr/bin?



OK, it does:

from notebook.notebookapp import main
from notebook.notebookapp import NotebookApp


Can we bring it back?  I can help maintain it if maintenance cycles 
are an issue.


Let's bring it back.

--
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
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/QPJRG4NFITO3L6NARNYCHSO7X2TSG2RX/

Re: [X86] Fwd: F29 System Wide Change: i686 Is For x86-64

[Jeff Backus]

On Mon, Jun 4, 2018 at 10:07 PM, Matthew Miller 
wrote:

> On Mon, Jun 04, 2018 at 03:50:34PM -0400, Jeff Backus wrote:
> > Thanks for the data. 25k is still a pretty healthy number. :) I realize
>
> Yeah, absolutely. And it's likely that those mirror numbers undercount,
> because not every system checks in daily, and then there's also NAT.
>
> But, my gut feeling is that about half of those are not using a current
> release _anyway_. Honest question: do you think that 12k would still
> count as a healthy number? I mean, it's not peanuts. But maybe it'd be
> better served by a Fedora remix (or similar) specifically targetting
> older and low-powered systems?
>

Good question. I think it would be more productive to think in percentages
instead of raw numbers, in this case. There are a lot of FOSS projects out
there that would love to have 12k users. :)

Certainly, I would consider 10% a healthy number when talking about portion
of user base. I would even argue that 1% is still a healthy number,
particularly with regard to decisions that have a reasonable chance of
disenfranchising those affected. While I hate seeing people leave a
community, I wouldn't be able to defend 0.1%. So, somewhere in there is my
general boundary.

Now cost changes all of that, of course. Obviously if 75% of our effort is
going to please 10%, then 10% isn't a healthy number.

Clearly effort is going into enabling Fedora to work on non-SSE2 systems by
teams invested in the success of Fedora in general and not the success of
non-SSE2 systems in particular. I just don't know how to quantify it.

Based on Smooge's awesome numbers, it looks like x86_32 is in the 2.3%
range. It would be interesting to see how this stacks up to AArch64 and
other secondary arches. Unfortunately, what complicates things is how
x86_32 is so intertwined with x86_64.

To your point re: a remix, that is an option we've discussed within the SIG
and is one we are open to exploring. A remix wouldn't resolve issues
introduced by enabling SSE2 by default, unless we maintained a parallel set
of packages e.g. i586 (which I've already been warned about. :) )


> > that there are a lot of unknowns in the data, so it is difficult to draw
> > any hard conclusions, but 25k is still much larger than 0. Splitting into
> > i686 into i586 and i686 would give more insight into who still needs
> > non-SSE2... Probably hurts my argument, though. :)
>
> Soo this is the kind of thing that more a detailed hardware
> census could really help us with!
>

Yes, I would agree :)


-- 
Jeff Backus
jeff.bac...@gmail.com
http://github.com/jsbackus
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/RREBM5JKGKSSO5MDLVKXTHNZSWNTMDZP/

Re: F29 System Wide Change: Strong crypto settings: phase 2

[Adam Williamson]

On Tue, 2018-06-05 at 17:59 +0200, Till Maas wrote:
> On Tue, Jun 05, 2018 at 08:08:00AM -0700, Adam Williamson wrote:
> 
> > I don't know, but it seems worth considering, and my basic point here
> > is this is something the Change owner should be responsible for
> > figuring out: making at least a reasonable effort to evaluate which
> > important (particularly release-critical) software and workflows will
> > be affected by the change and proposing plans for testing them. "we
> > should check curl behaves as expected" just doesn't really cut it as a
> > test plan.
> 
> Should we add a QA review step to the change process to address this?

That's, er, sort of what I'm doing. The Change has been proposed. I'm
reviewing it. :P

> IMHO we cannot expect Change owners to know this or have the same eye
> for detail as quality engineers have, therefore the best approach is to
> provide them guidance. Or can we assume that the open discussion here
> where this can be pointed out is enough?

There is a brief mention in the Changes policy page:

"Fedora QA reviews announced changes on the devel-announce list to
commit to testing of the change, or adjust release criteria as
necessary."

https://fedoraproject.org/wiki/Changes/Policy
-- 
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
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/VHNWYAZE7PJE242BWQKQDS4LMMKUUV5D/

Re: F29 System Wide Change: Strong crypto settings: phase 2

[Adam Williamson]

On Tue, 2018-06-05 at 18:29 +0200, Tomas Mraz wrote:
> On Tue, 2018-06-05 at 08:08 -0700, Adam Williamson wrote:
> > On Tue, 2018-06-05 at 11:16 +0200, Nikos Mavrogiannopoulos wrote:
> > > On Mon, 2018-06-04 at 11:46 -0700, Adam Williamson wrote:
> > > > On Fri, 2018-06-01 at 13:40 +0200, Jan Kurik wrote:
> > > > > = Proposed System Wide Change: Strong crypto settings: phase 2
> > > > > =
> > > > > https://fedoraproject.org/wiki/Changes/StrongCryptoSettings2
> > > > 
> > > > 
> > > > How about clients for networking with other OSes - e.g. Samba
> > > > clients,
> > > > and the tools for enrolling systems as Active Directory domain
> > > > members?
> > > > Do those respect the system policy? If so, have we considered the
> > > > impact of these changes on those configurations?
> > > 
> > > Do these clients use TLS?
> > 
> > I don't know, but it seems worth considering, and my basic point here
> > is this is something the Change owner should be responsible for
> > figuring out: making at least a reasonable effort to evaluate which
> > important (particularly release-critical) software and workflows will
> > be affected by the change and proposing plans for testing them. "we
> > should check curl behaves as expected" just doesn't really cut it as
> > a
> > test plan.
> 
> Do we have a list of the release-critical software and functionality?

Sure: refer to the release criteria and the release validation tests.

https://fedoraproject.org/wiki/Basic_Release_Criteria
https://fedoraproject.org/wiki/Fedora_29_Beta_Release_Criteria
https://fedoraproject.org/wiki/Fedora_29_Final_Release_Criteria

https://fedoraproject.org/wiki/Template:Installation_test_matrix
https://fedoraproject.org/wiki/Template:Base_test_matrix
https://fedoraproject.org/wiki/Template:Server_test_matrix
https://fedoraproject.org/wiki/Template:Cloud_test_matrix
https://fedoraproject.org/wiki/Template:Desktop_test_matrix
-- 
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
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/EKMYQ3CTBBOZPQM22VAU7PS76QSQKUTK/

Re: Intent to drop python2-notebook

[Miro Hrončok]

On 5.6.2018 18:21, Jerry James wrote:
On Tue, Jun 5, 2018 at 9:30 AM, Miro Hrončok > wrote:


On 11.5.2018 17:54, Miro Hrončok wrote:

python2-notebook is a leaf package (nothing in Fedora
(build)requires it). I'd like to drop it from rawhide. Any
objections?

Dropped.


Uh oh.  I just added both a BR and an R from sagemath to 
python2-notebook a couple of days ago, because sagemath does require 
it.


Does it require all of it? It's not a library. Can we see what exactly 
is required and why maybe? How is it used - via Python imports or via 
the command form /usr/bin?


Can we bring it back?  I can help maintain it if maintenance cycles 
are an issue.


We can, but please check the above first.

The issue is that upstream no longer seem to care about Python 2. Last 
time, it had some SyntaxErrors on legacy Python. Fortunatelly, only in 
some tests, so I've dropped those from the py2 package, but I just 
didn't want to deal with this any more.





--
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
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/SHQ4V22UQJ22GOVFIP34YV6BRSTYCMAE/

Re: F29 System Wide Change: Strong crypto settings: phase 2

[mcatanzaro]

On Tue, Jun 5, 2018 at 4:14 AM, Nikos Mavrogiannopoulos 
 wrote:

Note that this change, if applied, includes browsers shipped by fedora
(i.e., firefox). That is pretty much all or nothing plan, either we
bump the defaults for all software, or for none.


Nikos, I'm really surprised to see you commenting here without saying 
anything for or against the change.


Surely this will break a large number of websites?

And, if not, then surely we should be able to first convince upstream 
Firefox and Chrome to drop support for TLS 1.0 and 1.1? I would not 
have any objections if these upstreams were to take the step first. Yet 
that seems extremely unlikely.


Michael
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/AQ5G7JYTQQHCXV6OEWUZ26YT35NCAX7M/

Re: F29 System Wide Change: Strong crypto settings: phase 2

[Tomas Mraz]

On Tue, 2018-06-05 at 08:08 -0700, Adam Williamson wrote:
> On Tue, 2018-06-05 at 11:16 +0200, Nikos Mavrogiannopoulos wrote:
> > On Mon, 2018-06-04 at 11:46 -0700, Adam Williamson wrote:
> > > On Fri, 2018-06-01 at 13:40 +0200, Jan Kurik wrote:
> > > > = Proposed System Wide Change: Strong crypto settings: phase 2
> > > > =
> > > > https://fedoraproject.org/wiki/Changes/StrongCryptoSettings2
> > > 
> > > 
> > > How about clients for networking with other OSes - e.g. Samba
> > > clients,
> > > and the tools for enrolling systems as Active Directory domain
> > > members?
> > > Do those respect the system policy? If so, have we considered the
> > > impact of these changes on those configurations?
> > 
> > Do these clients use TLS?
> 
> I don't know, but it seems worth considering, and my basic point here
> is this is something the Change owner should be responsible for
> figuring out: making at least a reasonable effort to evaluate which
> important (particularly release-critical) software and workflows will
> be affected by the change and proposing plans for testing them. "we
> should check curl behaves as expected" just doesn't really cut it as
> a
> test plan.

Do we have a list of the release-critical software and functionality?

Of course verifying that all the packages in Fedora still work (in what
sense?) is a quite bit unrealistic requirement.

-- 
Tomáš Mráz
No matter how far down the wrong road you've gone, turn back.
  Turkish proverb
[You'll know whether the road is wrong if you carefully listen to your
conscience.]
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/JODSHUPXNLSEXFFJQBH5EDYGDEAP4CIQ/

Re: F29 System Wide Change: Strong crypto settings: phase 2

[Tomas Mraz]

On Tue, 2018-06-05 at 16:11 +, Christian Stadelmann wrote:
> "Fallback option" always smells like "protocol downgrade attack".
> This would undermine the idea of a crypto policy. Anyway,
> implementing it seems way out of scope for the crypto policy.

Yes, a fallback option is a no-way. You can switch the system policy to
LEGACY, however that does not necessarily mean that some very old
legacy HW will start to work with Firefox or another web browser,
because with newer versions of the browsers and newer versions of
TLS/crypto libraries some very old and insecure algorithm and protocol
support is being also removed.

-- 
Tomáš Mráz
No matter how far down the wrong road you've gone, turn back.
  Turkish proverb
[You'll know whether the road is wrong if you carefully listen to your
conscience.]
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/4YGCDHY6W7G66YPP4QIJL23AOXKDNPYF/

Re: Intent to drop python2-notebook

[Jerry James]

On Tue, Jun 5, 2018 at 9:30 AM, Miro Hrončok  wrote:

> On 11.5.2018 17:54, Miro Hrončok wrote:
>
>> python2-notebook is a leaf package (nothing in Fedora (build)requires
>> it). I'd like to drop it from rawhide. Any objections?
>>
>> This **does not** affect the ability to run Jupyter Notebook (via the
>> jupyter-notebook command) with Python 2 kernel (from the python2-ipykernel
>> package).
>>
>
> Dropped.
>

Uh oh.  I just added both a BR and an R from sagemath to python2-notebook a
couple of days ago, because sagemath does require it.  Can we bring it
back?  I can help maintain it if maintenance cycles are an issue.

Sagemath upstream is working on converting to python 3, but they aren't
quite there yet.  In the meantime, we have to keep all of its dependencies
available for python 2.

I probably didn't think twice about the original message, because it was
sent before I started digging into sagemath's dependencies.  Sorry about
any hassle this causes.
-- 
Jerry James
http://www.jamezone.org/
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/4X6ZABPINFI56C4V4Z4LQXCHJPL6HWUJ/

Re: F29 System Wide Change: Strong crypto settings: phase 2

[Christian Stadelmann]

"Fallback option" always smells like "protocol downgrade attack". This would 
undermine the idea of a crypto policy. Anyway, implementing it seems way out of 
scope for the crypto policy.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/VJGXNB66WVRQVPG5XKXUPAT6QRCVEUPY/

Re: F29 System Wide Change: Strong crypto settings: phase 2

[Till Maas]

On Tue, Jun 05, 2018 at 08:08:00AM -0700, Adam Williamson wrote:

> I don't know, but it seems worth considering, and my basic point here
> is this is something the Change owner should be responsible for
> figuring out: making at least a reasonable effort to evaluate which
> important (particularly release-critical) software and workflows will
> be affected by the change and proposing plans for testing them. "we
> should check curl behaves as expected" just doesn't really cut it as a
> test plan.

Should we add a QA review step to the change process to address this?
IMHO we cannot expect Change owners to know this or have the same eye
for detail as quality engineers have, therefore the best approach is to
provide them guidance. Or can we assume that the open discussion here
where this can be pointed out is enough?

Kind regards
Till
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/CTGJIDTEIEEK46TTWB5BERAF5MGLICW4/

Re: Intent to drop python2-notebook

[Miro Hrončok]

On 11.5.2018 17:54, Miro Hrončok wrote:
python2-notebook is a leaf package (nothing in Fedora (build)requires 
it). I'd like to drop it from rawhide. Any objections?


This **does not** affect the ability to run Jupyter Notebook (via the 
jupyter-notebook command) with Python 2 kernel (from the 
python2-ipykernel package).


Dropped.

--
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
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/3DVA7ZZAIUIVNM6GWJ34L756CI34JKTQ/

Re: F29 System Wide Change: Strong crypto settings: phase 2

[Adam Williamson]

On Tue, 2018-06-05 at 11:16 +0200, Nikos Mavrogiannopoulos wrote:
> On Mon, 2018-06-04 at 11:46 -0700, Adam Williamson wrote:
> > On Fri, 2018-06-01 at 13:40 +0200, Jan Kurik wrote:
> > > = Proposed System Wide Change: Strong crypto settings: phase 2 =
> > > https://fedoraproject.org/wiki/Changes/StrongCryptoSettings2
> > 
> > 
> > How about clients for networking with other OSes - e.g. Samba
> > clients,
> > and the tools for enrolling systems as Active Directory domain
> > members?
> > Do those respect the system policy? If so, have we considered the
> > impact of these changes on those configurations?
> 
> Do these clients use TLS?

I don't know, but it seems worth considering, and my basic point here
is this is something the Change owner should be responsible for
figuring out: making at least a reasonable effort to evaluate which
important (particularly release-critical) software and workflows will
be affected by the change and proposing plans for testing them. "we
should check curl behaves as expected" just doesn't really cut it as a
test plan.
-- 
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
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/KISDZLKOQB4B3AKKJXYYZ3VQ2RL4Z66U/

Re: Hiding the grub menu by default on single OS installs

[Sven Kieske]

Am 01.06.2018 um 20:22 schrieb Chris Murphy:
> Ironically, server, cloud, and VMs all benefit the most from the
> feature.

I'm just a user/bystander for the most part of this discussion but I
feel I have to correct this statement:

For the most part, server boot time is determined by firmware stuff,
before even grub gets loaded, so reduced startup time is always nice,
but when your HP DL380 Gen10 Server already need 5-15 Minutes until POST
is complete you really do not care about 5 Second grub display.

you really _need_ grub menus in production DCs where you still
run pet workloads and shit hits the fan (emergency boot into old kernel,
tweaking your already custom kernel cmdline etc), it happens really
rare, but when, you absolutely need it.

HTH to clarify what actual datacenter users _do_ care about (well, this
might vary, depending which DC OPs person you ask).

That said, it's less of a concern because we can of course recreate
the old behaviour, but I must admit, I like sane defaults.

But as I understand it, this change is limited to the workstation
edition of fedora, so I don't know why people come up with the topic
of servers in the first place.

-- 
Mit freundlichen Grüßen / Regards

Sven Kieske

Systemadministrator

Mittwald CM Service GmbH & Co. KG
Königsberger Straße 4-6
32339 Espelkamp

T: +495772 293100
F: +495772 29

https://www.mittwald.de

Geschäftsführer: Robert Meyer, Maik Behring

St.Nr.: 331/5721/1033, USt-IdNr.: DE814773217
HRA 6640, AG Bad Oeynhausen

Komplementärin: Robert Meyer Verwaltungs GmbH
HRB 13260, AG Bad Oeynhausen



signature.asc
Description: OpenPGP digital signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/TONKLOACW2NSB4FCM2E4J7REDTH4VZ3K/

Re: F29 System Wide Change: Hide the grub menu

[Till Maas]

Hi,

On Mon, Jun 04, 2018 at 05:09:46PM +0200, Vít Ondruch wrote:

> Talking from my experience running Rawhide on two my laptops for ~5
> years, I really don't remember where I would really need to use older
> kernel. If I had to, it was probably due to something like audio issues
> with my docking station and that is hardly the situation you describe.

for other people working audio can be essential, e.g. when doing video
conferences. I remember problems with VGA output problems that were
introduced with a kernel with full FLOSS intel drivers which is also
essential for presentations.

Kind regards
Till
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/MDOPYBMOIW2HFHBMUL4OXNVWKU2MP3T5/

Re: F29 System Wide Change: Strong crypto settings: phase 2

[Michael Watters]

Not just web sites.  Changes in Firefox and Chrome have already made
working with embedded devices such as DRAC and storage servers nearly
impossible.  IMO there needs to be a fallback option to still allow
access to "insecure" sites that still use TLS 1.0 or older certificates
that still use SHA-1.


On 06/02/2018 05:57 AM, Christian Stadelmann wrote:
>> On Fri, Jun 01, 2018 at 01:40:58PM +0200, Jan Kurik wrote:
>> What is the availibility of TLS 1.2 vs 1.1/1.0 on the internet ?
>> ie how likely is this to break the ability of users to access websites
>> they care about ?
> There is quite a lot, sadly. I'd say about 0.1…1% of all internet sites of my 
> personal browsing behavior. Fedora's infrastructure works fine with TLS 1.0 
> and 1.1 disabled. Essential parts of the eclipse.org infrastructure is still 
> on historic crypto levels, including its wiki, git server and marketplace. 
> This DEFAULT policy probably will break the eclipse marketplace client in 
> Fedora.
>
> I haven't found perfect data but SSLLabs' "SSL Pulse" [1] gives some hints. 
> Applying their current metric, any server without TLS 1.2 support will be 
> rewarded with grade C or worse. See [2] for an example. Assuming that 
> grade-F-sites are broken beyond any repair, there's still 7.7% grade C and a 
> few grade D pages resulting in up to 7.8% of all websites still using TLS < 
> 1.2. Without good data on this I highly recommend not disabling TLS <1.2 by 
> default on F29.
>
> [1] https://www.ssllabs.com/ssl-pulse/
> [2] https://www.ssllabs.com/ssltest/analyze.html?d=marketplace.eclipse.org
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/Z6RXR5W6KH4NODRINVJFEBIBQRX4I6HP/
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/BPNMA54WJ5B7QMBTEMPDVDGOHCIHQDHN/

F29 Self Contained Change: Changes/Update festival to 2.5

[Jan Kurik]

= Proposed Self Contained Change: Changes/Update festival to 2.5 =
https://fedoraproject.org/wiki/Changes/Update_festival_to_2.5


Owner(s):
  * Lukáš Tyrychtr 


Update the packaged festival speech synthesis system to the latest
upstream version. And just as a bonus make it actually work.



== Detailed description ==
Festival provides capabilities for speech synthesis and a framework
for synthetic voice creation. It generally provides higher quality
voices than Espeak.


== Scope ==
* Proposal owners:
Actually do the package updates (almost done) and get them in to Fedora.

* Other developers:
N/A (not a System Wide Change)

* Release engineering:
https://pagure.io/releng/issue/7551 #7551

** List of deliverables:
N/A (not a System Wide Change)

* Policies and guidelines:
N/A (not a System Wide Change)

* Trademark approval:
N/A (not needed for this Change)
-- 
Jan Kuřík
JBoss EAP 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
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/FNFK7QVGFUKXCI7AUIEZKO6HFKHAI64C/

Re: Release criteria proposal: drop kickstart package criterion

[Stephen Gallagher]

On Tue, Jun 5, 2018 at 7:13 AM Josh Boyer  wrote:

> On Tue, Jun 5, 2018 at 2:13 AM Zbigniew Jędrzejewski-Szmek
>  wrote:
> >
> > On Tue, Jun 05, 2018 at 02:26:25AM +0100, Peter Robinson wrote:
> > > On Tue, Jun 5, 2018 at 12:39 AM, Adam Williamson
> > >  wrote:
> > > > Hi, folks!
> > > >
> > > > We currently have a Final release criterion that reads as follows:
> > > >
> > > > "A spin-kickstarts package which contains the exact kickstart files
> > > > used to build the release must be present in the release repository.
> > > > The included kickstarts must define the correct set of release
> > > > repositories.
> > > >
> > > > Why?
> > > >
> > > > This is considered part of Fedora's duty to be 'self-hosting': the
> > > > kickstarts used to produce the release images are a vital piece of
> > > > information required to duplicate that release, so they must be
> > > > preserved along with the release."
> > > >
> > > > Lately this requirement has been fairly annoying in practice.
> Updating
> > > > the package prior to release does not appear to be in anyone's
> regular
> > > > schedule, so invariably what happens is shortly before the release
> > > > deadline I realize we haven't built a 'release' spin-kickstarts
> package
> > > > and have to file a blocker bug and ping people with the necessary
> > > > permissions (of which there are only a few) to build one in a tearing
> > > > hurry. Then we have to approve the blocker bug and push the updated
> > > > package through the freeze, all wasting time we could be spending on
> > > > more important fixes.
> > > >
> > > > The benefit here is really fairly tiny, as well. It's arguable
> whether
> > > > anyone cares particularly whether a Fedora release, as a frozen
> > > > artifact, is 100% internally reproducible (and I'm not sure whether
> our
> > > > releases actually *are* reproducible in any case, these days, I'm not
> > > > at all sure we ship all the necessary metadata and so on for *every
> > > > single deliverable* within the distribution).
> > > >
> > > > These days I'd suggest it should be quite acceptable to simply use
> git
> > > > tags for this purpose. It should be quite easy for rel-eng to adjust
> > > > the release scripts to create a tag in the fedora-kickstarts repo
> (and
> > > > why not fedora-comps too, while we're at it) for each 'candidate'
> > > > compose, named for the compose ID. That would make it very easy to
> > > > access the correct kickstarts for any Fedora candidate compose just
> by
> > > > a 'git checkout', with no need for the cumbersome work of getting the
> > > > package into the compose.
> > > >
> > > > Naturally this would go along with updates to any relevant docs or
> wiki
> > > > pages, recommending to use the git repository instead of the RPM
> > > > packages, and explaining the tagging scheme. As for the package, we
> > > > could either keep it but not sweat about updating it for each
> release,
> > > > retire it entirely, or change it to contain only a text file pointing
> > > > to the git repository (or to the doc / wiki page that explains the
> git
> > > > repo location and tagging strategy).
> > > >
> > > > Thoughts? Thanks!
> > >
> > > It makes perfect sense, the package is not actually shipped as part of
> > > any of the actual deliverable artifacts and they're widely available
> > > in a public git repository for people to consume so it's not reducing
> > > the ability to reproduce Fedora, we don't rush around and ensure all
> > > the tools that might need last minute patches in the compose process
> > > are all tagged stable in the release either so I don't see actually
> > > shipping this package as stable makes any difference in reality, we
> > > don't even use the package in the compose process, we pull the
> > > kickstarts directly from git.
> >
> > +1 too.
>
> Yes, let's do what makes sense.  I like the proposal.
>
>
And my axe! Err, or my +1, yeah.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/BMDWP3UKY55OGKGS6MQCMF24LRCAWUZP/

Re: Release criteria proposal: drop kickstart package criterion

[Josh Boyer]

On Tue, Jun 5, 2018 at 2:13 AM Zbigniew Jędrzejewski-Szmek
 wrote:
>
> On Tue, Jun 05, 2018 at 02:26:25AM +0100, Peter Robinson wrote:
> > On Tue, Jun 5, 2018 at 12:39 AM, Adam Williamson
> >  wrote:
> > > Hi, folks!
> > >
> > > We currently have a Final release criterion that reads as follows:
> > >
> > > "A spin-kickstarts package which contains the exact kickstart files
> > > used to build the release must be present in the release repository.
> > > The included kickstarts must define the correct set of release
> > > repositories.
> > >
> > > Why?
> > >
> > > This is considered part of Fedora's duty to be 'self-hosting': the
> > > kickstarts used to produce the release images are a vital piece of
> > > information required to duplicate that release, so they must be
> > > preserved along with the release."
> > >
> > > Lately this requirement has been fairly annoying in practice. Updating
> > > the package prior to release does not appear to be in anyone's regular
> > > schedule, so invariably what happens is shortly before the release
> > > deadline I realize we haven't built a 'release' spin-kickstarts package
> > > and have to file a blocker bug and ping people with the necessary
> > > permissions (of which there are only a few) to build one in a tearing
> > > hurry. Then we have to approve the blocker bug and push the updated
> > > package through the freeze, all wasting time we could be spending on
> > > more important fixes.
> > >
> > > The benefit here is really fairly tiny, as well. It's arguable whether
> > > anyone cares particularly whether a Fedora release, as a frozen
> > > artifact, is 100% internally reproducible (and I'm not sure whether our
> > > releases actually *are* reproducible in any case, these days, I'm not
> > > at all sure we ship all the necessary metadata and so on for *every
> > > single deliverable* within the distribution).
> > >
> > > These days I'd suggest it should be quite acceptable to simply use git
> > > tags for this purpose. It should be quite easy for rel-eng to adjust
> > > the release scripts to create a tag in the fedora-kickstarts repo (and
> > > why not fedora-comps too, while we're at it) for each 'candidate'
> > > compose, named for the compose ID. That would make it very easy to
> > > access the correct kickstarts for any Fedora candidate compose just by
> > > a 'git checkout', with no need for the cumbersome work of getting the
> > > package into the compose.
> > >
> > > Naturally this would go along with updates to any relevant docs or wiki
> > > pages, recommending to use the git repository instead of the RPM
> > > packages, and explaining the tagging scheme. As for the package, we
> > > could either keep it but not sweat about updating it for each release,
> > > retire it entirely, or change it to contain only a text file pointing
> > > to the git repository (or to the doc / wiki page that explains the git
> > > repo location and tagging strategy).
> > >
> > > Thoughts? Thanks!
> >
> > It makes perfect sense, the package is not actually shipped as part of
> > any of the actual deliverable artifacts and they're widely available
> > in a public git repository for people to consume so it's not reducing
> > the ability to reproduce Fedora, we don't rush around and ensure all
> > the tools that might need last minute patches in the compose process
> > are all tagged stable in the release either so I don't see actually
> > shipping this package as stable makes any difference in reality, we
> > don't even use the package in the compose process, we pull the
> > kickstarts directly from git.
>
> +1 too.

Yes, let's do what makes sense.  I like the proposal.

josh
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/FO72VPNREVN5XKHZ64RXIGFNDCKJCZZ5/

Re: equivalent of Debian config-package?

[Neal Gompa]

On Tue, Jun 5, 2018 at 5:51 AM Dave Love  wrote:
>
> You wrote:
>
> > I think generally the Fedora/RH-ecosystem answer is to use Ansible for
> > configuration, rather than configuration packages.
> >
> > That's not sayin' there can't be another answer, but in general that's
> > the route *I'd* take to solve this problem on my systems.
>
> I guess we disagree about what the problem is, but it's unfortunate if
> Fedora/RH isn't interested in the sort of environment for which
> config-package was developed.

The reason Ansible is used is because we have no current equivalent
facilities to do delayed script execution or diversion of
configuration files. Both are functions required for Debian-style
configuration packages. Feel free to file an issue with rpm upstream[1]
to figure out a good way to support configuration packages if you want it.

On the flip side, because these facilities haven't existed for so long
and the RPM ecosystem largely rejected interactive script hooks in
RPMs, most packages ship with "working defaults" and are trivially
reconfigurable through external automation tools, which is why mass
provisioning and configuration management systems work so well for RPM
based systems.

[1]: https://github.com/rpm-software-management/rpm/issues


--
真実はいつも一つ！/ Always, there's only one truth!
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/KOYWCYKBDBQUY532IQCBOYDT2FBGN4A5/

Re: F29 System Wide Change: Strong crypto settings: phase 2

[Nikos Mavrogiannopoulos]

On Mon, 2018-06-04 at 11:46 -0700, Adam Williamson wrote:
> On Fri, 2018-06-01 at 13:40 +0200, Jan Kurik wrote:
> > = Proposed System Wide Change: Strong crypto settings: phase 2 =
> > https://fedoraproject.org/wiki/Changes/StrongCryptoSettings2
> 
> 
> How about clients for networking with other OSes - e.g. Samba
> clients,
> and the tools for enrolling systems as Active Directory domain
> members?
> Do those respect the system policy? If so, have we considered the
> impact of these changes on those configurations?

Do these clients use TLS?

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/ZGHNNM2KKFXIKSXA5ZEQVTKBDCD5F6SZ/

Re: F29 System Wide Change: Strong crypto settings: phase 2

[Nikos Mavrogiannopoulos]

On Fri, 2018-06-01 at 10:25 -0500, mcatanz...@gnome.org wrote:
> On Fri, Jun 1, 2018 at 8:06 AM, Daniel P. Berrangé 
>  wrote:
> > What is the availibility of TLS 1.2 vs 1.1/1.0 on the internet ?
> > ie how likely is this to break the ability of users to access
> > websites
> > they care about ?
> 
> Yeah... this has been discussed on this list before. If this change
> is 
> made, then we will need to drop our glib-networking patch that
> causes 
> glib-networking to respect Fedora's system crypto policy, since we 
> simply cannot afford to be more restrictive than major browsers.

Note that this change, if applied, includes browsers shipped by fedora
(i.e., firefox). That is pretty much all or nothing plan, either we
bump the defaults for all software, or for none.

regards,
Nikos
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/FQYOX5LB2E4NENAHO3A2XOTPY4FBM3YK/

Re: F29 System Wide Change: Hide the grub menu

[Panu Matilainen]

On 06/04/2018 06:09 PM, Vít Ondruch wrote:



Dne 1.6.2018 v 16:29 Ken Coar napsal(a):

On 06/01/2018 05:06 AM, Vít Ondruch wrote:

It is irony, that people, who are capable to get into the grub menu if
they need, complain about it being hidden. So to say, I am 100% for
hiding the grub menu, speeding up the boot process, and if need it, I'll
find a way to get it.

I fail to see any irony here.  When I need to get into the
grub menu, it's usually an emergency (or at least highly-stressful)
situation, with no documentation handy, and flailing about
trying to figure out how to make it appear just adds to the
stress and the blue tinge of the air in my vicinity.

What *exactly* is this trying to solve?

IIRC, the patch is to hide the grub menu IFF there's only one
kernel because 'it serves no useful function.'  A number of
people (myself included) have disputed that assertion.  If
the assertion is invalid, the patch shouldn't be applied.
Correct?  That seems simple enough.  Or maybe I don't understand
the process, lacking sufficient Fedora-devel-fu karma.

How many non-tech end users install Fedora straight
from the distro, as opposed to those who install a frobbed
version, with different defaults, from a repackager?
_I.e._, repackagers can set grub up however they like.

Is Fedora's goal to be end-user friendly, tech friendly, or
the all-singing all-dancing Linux distro?


Talking from my experience running Rawhide on two my laptops for ~5
years, I really don't remember where I would really need to use older
kernel. If I had to, it was probably due to something like audio issues
with my docking station and that is hardly the situation you describe.

In my family, there are another 2 computers running Fedora. I don't
remember any kernel related issues. And if there were kernel issues,
explaining my sister that she should use older kernel would be similarly
difficult if the menu is displayed or not.


While we're comparing experiences, all our computers run on Fedora. And 
while issues are rare, there have been some. The most recent one (last 
year IIRC) was a laptop freezing in middle of boot after certain kernel 
>= x.y.z for several months before whateveritwas got fixed. If a 13 
year old kid learns to select the kernel from the menu after seeing it 
once...




But the true is, that the computers are not using any proprietary
drivers, which might be issue.


Neither was the laptop in the above case, FWIW. Regressions do happen.

- Panu -
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/3ANM5JJRSFK4N7SI6ZIPYKOHNMDPLBHH/