Re: Let's retire original glib and gtk+ (new report)

[Bill Nottingham]

Peter Boy (p...@uni-bremen.de) said: 
> And, by the way, it is one of Linux’s (and Fedora Linux’s) core
> distinguishing features that it does not follow the short-term commercial
> life cycles, but enables long-term usability, for "old" hardware as well
> as software.  And we should not give that up lightly and without need. 

I don't think removing something that has not been the main supported
library version for literally *20 years* is caving to short-term
It's not caving to short-term commercial lifecycles to remove something
that has been the obsoleted library version for literally *20 years*.

It has been obsolete for longer than any Fedora supported architecture
has existed.

Bill
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Packaging of Ansible collections

[Bill Nottingham]

James Cassell (fedoraproj...@cyberpear.com) said: 
> > > I guess if would be enough to put the files somewhere under
> > > /usr/share/ansible, but not sure. Also I'm not sure what download URL 
> > > could
> > > be used.
> > 
> > What is the goal of downstream collection packaging here - what collections
> > are you looking to package and why?
> 
> Same reason as openshift-ansible or ceph-ansible or ansible-freeipa, or
> any pip-installable package.  Unfortunately, ansible is kicking all the
> community modules out of core, so things like ini_file won't work without
> the appropriate collection installed.

Yes, but there will be a deliverable/distribution that will be produced with
the goal of allowing playbooks to work more or less as they do now; the goal
is that community content can be maintained on its own release stream as
it's needed, but delivery can still be in the form of a larger community
package.

Bill
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Packaging of Ansible collections

[Bill Nottingham]

Igor Gnatenko (ignatenkobr...@fedoraproject.org) said: 
> Hello,
> 
> Did anybody had an experience of packaging Ansible collections into an RPM?
> 
> I guess if would be enough to put the files somewhere under
> /usr/share/ansible, but not sure. Also I'm not sure what download URL could
> be used.

What is the goal of downstream collection packaging here - what collections
are you looking to package and why?

Bill
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

orphaning: comps-extras, goffice08

[Bill Nottingham]

comps-extras: required by PackageKit
goffice08: required by nip2, cutter

Neither has required any significant maintenance if someone wants to pick them 
up.

Bill
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

[rpms/perl-HTML-TableExtract] PR #1: Update to 2.15 and a number of small corrections.

[Bill Nottingham]

notting commented on the pull-request: `Update to 2.15 and a number of small 
corrections.` that you are following:
``
N/M, build started:  
https://koji.fedoraproject.org/koji/taskinfo?taskID=33921967

``

To reply, visit the link below
https://src.fedoraproject.org/rpms/perl-HTML-TableExtract/pull-request/1
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-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/perl-devel@lists.fedoraproject.org

[rpms/perl-HTML-TableExtract] PR #1: Update to 2.15 and a number of small corrections.

[Bill Nottingham]

notting commented on the pull-request: `Update to 2.15 and a number of small 
corrections.` that you are following:
``
feel free to build for rawhide (or respond if you can't, and I'll get to it)
``

To reply, visit the link below
https://src.fedoraproject.org/rpms/perl-HTML-TableExtract/pull-request/1
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-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/perl-devel@lists.fedoraproject.org

[rpms/perl-HTML-TableExtract] PR #1: Update to 2.15 and a number of small corrections.

[Bill Nottingham]

notting merged a pull-request against the project: `perl-HTML-TableExtract` 
that you are following.

Merged pull-request:

``
Update to 2.15 and a number of small corrections.
``

https://src.fedoraproject.org/rpms/perl-HTML-TableExtract/pull-request/1
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-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/perl-devel@lists.fedoraproject.org

Re: Fedora Lifecycles: imagine longer-term possibilities

[Bill Nottingham]

Josh Boyer (jwbo...@fedoraproject.org) said: 
> > > If 7 years is what manufacturers really want, then it sounds like
> > > CentOS is much better positioned to be get shipped on laptops than
> > > Fedora. Instead of working on a new "Fedora LTS" for this usage case,
> > > would time be better spent improving EPEL and CentOS for the
> > > desktop/laptop use case? I'd always thought of CentOS/RHEL as "Fedora
> > > LTS" anyway, to be honest.
> >
> > The point of a Fedora LTS for these manufacturers, if it were to exist,
> > is to give them a channel to partner with, work on support with, and
> > a software base they can get needed changes into.
> 
> Agreed.  Fedora is well positioned to do that.  In fact, it's well
> positioned for the manufacturers themselves to get their software
> changes in as well.  I think there is an opportunity here for both
> sides that's worth looking at.
> 
> > AFAIK, CentOS isn't set up to accept changes (into the base repo) or
> > provide that level of support. And if they wanted to do it with Red Hat
> > at the RHEL level... presumably they would already be doing so.
> 
> That would presume a lot more as well.  Do both parties want to pursue
> that market?  Do both parties get benefits from it?  Are the
> development models and support terms structured in a way that
> facilitates that?  Even if we assume an answer of "yes" for all of
> those things and RHEL is pursuing it, that doesn't mean Fedora cannot
> or should not, right?

No, it doesn't mean Fedora can't do that. My main point is that I don't
see any situations where those answers are all 'yes' for CentOS, so I don't
think trying to position CentOS for this makes sense it either makes
sense for RHEL, or for Fedora (or for both).

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

Re: Fedora Lifecycles: imagine longer-term possibilities

[Bill Nottingham]

Ben Rosser (rosser@gmail.com) said: 
> On Wed, Nov 14, 2018 at 2:55 PM Stephen John Smoogen  wrote:
> > From what I have talked with in the past.. 3 years is their bare
> > minimum and 7 is their what we really want. It usually takes the
> > vendor about 3-6 months of work to make sure the OS works on their
> > hardware without major problems and then they want people to buy
> > support contracts for 3-5 years where the number of problems needed in
> > year 3-5 are none. [This means that they want to have Fedora N for 3-6
> > months before their laptops ship with it. So you ship them a frozen
> > preload before you release to public. They also want any shipped to
> > 'last' for the warranty cycle because trying to deal with update
> > questions when N eol's in the middle costs them a lot.]
> 
> If 7 years is what manufacturers really want, then it sounds like
> CentOS is much better positioned to be get shipped on laptops than
> Fedora. Instead of working on a new "Fedora LTS" for this usage case,
> would time be better spent improving EPEL and CentOS for the
> desktop/laptop use case? I'd always thought of CentOS/RHEL as "Fedora
> LTS" anyway, to be honest.

The point of a Fedora LTS for these manufacturers, if it were to exist,
is to give them a channel to partner with, work on support with, and
a software base they can get needed changes into.

AFAIK, CentOS isn't set up to accept changes (into the base repo) or
provide that level of support. And if they wanted to do it with Red Hat
at the RHEL level... presumably they would already be doing so.

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

Re: Semi-serious proposal: drop all optional entries from comps

[Bill Nottingham]

Matthew Miller (mat...@fedoraproject.org) said: 
> On Sun, Sep 23, 2018 at 06:05:16AM +0100, Peter Robinson wrote:
> > Some of the group stuff is also used during the compose and if things
> > aren't in groups specified but needed by say a kickstart the packages
> > won't be in certain places and will break things. I did this by
> > accident when adding zram in F-29 and not adding it to comps.
> 
> How much if this is an artifact of the compose being designed around trying
> to pack subsets of installable media onto a DVD? Do we currently do that for
> anything but Server, and is it really important that we continue? 

Given the lack of individual package selection in Anaconda, this would mean
that optional package inclusions there are solely for:
- kickstarting off the DVD
- using the DVD as a post-install locally mounted package source

There may be people doing the first. I'd have to think there are better ways
to handle the second.

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

Re: Intent to orphan Python 2

[Bill Nottingham]

Adam Williamson (adamw...@fedoraproject.org) said: 
> This rather begs the question of whether there are any modules which
> only work *with python 2*, though...

Given 1500+ modules, all of which can have their own python library
dependencies, the safe answer is 'yes'.

We're working to solve that, but it's a proces...

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

Re: F27 System Wide Change: Graphical Applications as Flatpaks

[Bill Nottingham]

Tom Hughes (t...@compton.nu) said: 
> > On a more general note I think a lot of people are assuming we're all
> > horrible evil people, trying to subvert the One True Fedora Way. This
> > is exceptionally poisonous and needs to stop, otherwise Fedora should
> > to drop both the "Friends", "Features" and the "First" in its motto.
> 
> I'm not necessarily concerned about subverting (or "changing" as I would
> prefer to think of it) the One True Fedora Way, if there are good reasons to
> do so and it improves things.
> 
> I'm more concerned that there will no longer be One True Fedora Way.
> 
> By which I mean that there will no longer be one way to update a Fedora
> system because workstations and servers have to be managed in completely
> different ways.
> 
> In other words that it's no longer possible to use clusterssh to run "dnf
> update" on twenty machines at once because each one is now a special
> snowflake that requires it's own approach to updating things - possibly even
> a mix of approaches if a developer's workstation needs "server updates" to
> update postgres and apache and "workstation updates" to update gcc and
> firefox.

Why clusterssh when you can Ansible? But I digress.

This situation already exists, though - each of these systems are already
snowflakes if they're user-maintained:
- some apps installed via RPMs connected to Fedora repos
- some from COPRS
- some from Random RPM Downloaded From Third-Party Website
- some from npm/pip
- containers from arbitrary registries.
- curlsh stuff
- things built from source

If the only answer Fedora has for this is "convince everyone to only build
RPMs using system reo components"... that's fighting a rear-guard battle
that has already been lost.  I don't think supporting Flatpak apps is
necessarily any worse than what already has to happen with all of the above.

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

Re: Proposal: Rethink Fedora multilib support (Take Two!)

[Bill Nottingham]

Stephen Gallagher (sgall...@redhat.com) said: 
> The main reason for this is trying to simplify the module-building process. We
> really don't want to attempt to build both arches within the same buildroot 
> for
> most of the reasons we've established in this extended conversation. My first
> proposal was one possible approach for this, but this second idea would solve
> the same problem, possibly with less jarring impact.

While I fully understand how our current multilib system is a mess for the
build and release process (being in certain respects responsible), I'm leery
of using that to make drastic changes.

The whole point of building an OS/module/etc for users is to keep the
complexity on the build side and out of the users hands - they don't care
whether half the packages switched from autoconf to meson, whether twenty
things are now written in Rust, or whether the entire python stack jumped
minor (or major!) versions.  They just want the system to upgrade and the
software they use to keep working.

If the multilib change only brings benefits to our build process and breaks
user cases without offering significant benefits to them, I can't see the
justification for it until we can offer end-user benefits (... ostree?).

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

Re: Fedora on Macs, removing the release criterion

[Bill Nottingham]

Josh Boyer (jwbo...@fedoraproject.org) said: 
> > If that is not the case anymore it would be good if that would be
> > communicated in advance so that all users on mac hw could either
> > switch distros or gang together to make a remix or something.
> 
> You are confusing Fedora with a company.  There is no top-down
> communication on what is or is not supported.  There is no hardware
> support list or hardware certification list.  It is literally what
> people show up and test.

In the past couple of weeks we have:

1) Fedora going out to survey HN about what they want, and 'seamless
hardware compatiblity' being a top response

2) This thread about how there's no institutional (for lack of a better
word) project commitment to any set of supportable hardware in particular

If #2 is the hard reality, there's not much point to even bothering with
the effort of inventorying items from surveys like #1.

If #1 is a serious effort, then that should lead to a discussion of how
we fix #2... but that's a discussion for a council or "please
$CORPORATE_SPONSOR, help us" list, rather than this tactical thread.

I do think that, for the sake of the project, the disconnect does
need to be resolved somehow.

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

Re: Please unpush FEDORA-2016-7776983633 on all releases or drop support for libjasper

[Bill Nottingham]

Matthew Miller (mat...@fedoraproject.org) said: 
> On Wed, Sep 14, 2016 at 08:50:49PM +0100, Richard Hughes wrote:
> > before pushing the next update? Three people gave the update positive
> > karma and I can't believe all three did so without actually opening a
> > JPEG-2000 image in any GTK-using or KDE-using app so there might be
> > something more subtle going on.
> 
> The update note says this fixes a bunch of CVEs, and there's no test
> plan (https://fedoraproject.org/wiki/QA:SOP_package_test_plan_creation),
> so testers have no guidance. The included conversion command works, and I
> can use `display` to verify that the converted file looks okay.
> 
> I'm not saying this update should have been pushed — but I don't think
> it's _necessarily_ that the testers were hitting +1 without doing
> anything.

I honestly think this is as much of a developer issue as a tester issue.  If
the CVE fix was to silently change the API/ABI of the library, that's on
either upstream or downstream, depending on where the fix came from.  Yes,
you'd like testers to catch that, but it's the sort of update that ideally
doesn't happen to begin with.

Bill
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Fedora development of Snap packages

[Bill Nottingham]

Neal Gompa (ngomp...@gmail.com) said: 
> And frankly, if you're trying to solve delivering software in a
> cross-distro fashion, you're doing it wrong. Take for example how RPMs
> "work": packages are generated with a set of generic dependencies
> based on the symbols of libraries and programs. There is literally no
> reason why I couldn't make a package on CentOS 7 and expect it to work
> on virtually every Linux distribution release from around that time.
> 
> To the best of my knowledge, the only significant breakage is with
> OpenSSL, where Fedora refused to set the same soversion that Debian,
> Mageia, Ubuntu, and other distros chose (1.0.0). This symbol break has
> led to it becoming impossible to ship something built on Fedora to
> work on a wide variety of distributions.
> 
> Much of the way RPM is designed is to *promote* cross-distro (and to
> some extent, cross-OS) packages. The fact that we don't is more of an
> artifact of the past than anything else. It continues to amaze me that
> we've given up on promoting our core technology in such a manner. In
> many, many, many ways, it is technically superior (in terms of
> flexibility and fitness for purpose) to the other alternatives out
> there, but everyone seems to have given up.

I would argue that the fact that very very very few upstreams even try to do
this puts the lie to the idea that RPM is a sufficient technology for this. 
Heck, Fedora doesn't even try to do this across Fedora versions in general
(MASS REBUILD THE WORLD!), and we control all of it.

Even those that do try for 'single' RPM builds accomplish this by
a) bundling the world outside of some really minimal LSB libs (for which
distros will yell at you... see this thread)
b) adding giant hacked shell scripts that includes a bunch of if statements
for distro-specific code (for which distros will yell at you... see this
thread)

Bill
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: introducing curl-minimal and libcurl-minimal RPM packages

[Bill Nottingham]

Kamil Dudka (kdu...@redhat.com) said: 
> Are you reading it from the specfile?
> 
> It is just an implementation detail of the packaging (the RemovePathPostfixes 
> feature of rpm).  The string you mentioned neither appears in the SONAME, nor 
> in any file installed by the RPMs in question.


... which means if the SONAME is the same, you either are dealing with
Conflicts:, or relying on the behavior of ldconfig to figure out which
library you happen to get at a particular time. Neither of those sounds
like a great idea.

Bill
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: introducing curl-minimal and libcurl-minimal RPM packages

[Bill Nottingham]

Kamil Dudka (kdu...@redhat.com) said: 
> On Wednesday, March 16, 2016 16:19:23 Bill Nottingham wrote:
> > Kamil Dudka (kdu...@redhat.com) said:
> > > Are you reading it from the specfile?
> > > 
> > > It is just an implementation detail of the packaging (the
> > > RemovePathPostfixes feature of rpm).  The string you mentioned neither
> > > appears in the SONAME, nor in any file installed by the RPMs in question.
> > 
> > ... which means if the SONAME is the same, you either are dealing with
> > Conflicts:
> 
> Exactly.  libcurl conflicts with libcurl-minimal, which means that exactly 
> one 
> of them will be installed on any Fedora system at a time.  On a regular 
> system 
> (server, desktop, etc.) it will always be libcurl.
> 
> On the other hand, if you need to create a minimal installation of Fedora 
> (e.g. a base image for Docker), you will pick libcurl-minimal instead of 
> libcurl, to make the set of installed packages really minimal.

That just seems an odd place to make a stand on size.

If you care about a consistent developer, user, and debugging experience
regardless of mechanism of delivery, you wouldn't do this in the first
place, or you'd change the global curl package. Either the features are
important, or they aren't.

If you care about minimizing size overall (neglecting the fact that
cutting out kerberos and to a lesser extent ldap dependencies don't really
save you anything due to their system library use), then might as well just
start -Os-ing random packages and throwing in busybox.

Bill
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: introducing curl-minimal and libcurl-minimal RPM packages

[Bill Nottingham]

Kamil Dudka (kdu...@redhat.com) said: 
> > - "Minimizing the fedora docker base image footprint" (by yanking dnf et.al.
> > into a seprate container, making size of it much more irrelevant) - "DNF
> > into C initiative started" (enabling a much larger depythoning that doesn't
> > require differing library buidls)
> > - "F24 Self Contained Change: System Python"
> > 
> > ... the fact that we now have four separate implementation details, all of
> > which could make different parts of the others irrelevant, makes me wonder
> > about the design behind it.
> 
> So what exactly are you proposing?

1) do nothing, don't worry as much about the size difference in this context
(and/or wait for the size thing to be solved by other container minimization
efforts)

2) decide that we're OK with differing functionality in things like docker
base images provided by different builds, and figure out the general
policies around this, how we document them for users, and standard ways
Fedora as a whole wants to handle this sort of packaging.

Bill
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: introducing curl-minimal and libcurl-minimal RPM packages

[Bill Nottingham]

Kamil Dudka (kdu...@redhat.com) said: 
> > If you care about a consistent developer, user, and debugging experience
> > regardless of mechanism of delivery, you wouldn't do this in the first
> > place, or you'd change the global curl package. Either the features are
> > important, or they aren't.
> 
> Are you implying that curl maintainers know better than users which features 
> are important for the users themselves?

... well, that's sort of what turning off features for this case implies.

> > If you care about minimizing size overall (neglecting the fact that
> > cutting out kerberos and to a lesser extent ldap dependencies don't really
> > save you anything due to their system library use), then might as well just
> > start -Os-ing random packages and throwing in busybox.
> 
> Micro-optimization is way to hell.  The system needs to optimized by design.

EXACTLY!  Maybe I'm not being clear in what I'm trying to say, but this is
the point - it needs to be designed.

1) Start with the design of who are we targeting - what jobs are then trying to
do?

2) Then, what do we produce? (Atomic, Server, Cloud, Workstation)

3) Do they have different needs? Do we build components with different features
for each? (This solution implies 'yes', but I don't recall seeing that
stated before)

4) If so, what are the differentiating features that require different
components with different feature sets? What's the job that someone is
trying to do that requires this? (The impliciation is 'download the base
image somewhat faster', but that's still very vague.)

5) Then, pick the targeted points and propose implementation of individual
features that serve the larger goal.

It's possible that, just poking my head up, I missed all the 1-4 discussion
that this is tied to. But given that the following has all popped up in
the past few months:

- "Minimizing the fedora docker base image footprint" (by yanking dnf et.al.
  into a seprate container, making size of it much more irrelevant)
- "DNF into C initiative started" (enabling a much larger depythoning that
  doesn't require differing library buidls)
- "F24 Self Contained Change: System Python"

... the fact that we now have four separate implementation details, all of which
could make different parts of the others irrelevant, makes me wonder about
the design behind it.

Bill
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: introducing curl-minimal and libcurl-minimal RPM packages

[Bill Nottingham]

Ville Skyttä (ville.sky...@iki.fi) said: 
> On Wed, Mar 16, 2016 at 6:36 PM, Kamil Dudka  wrote:
> > The curl and libcurl packages, which are both required by dnf,
> 
> Hm, does dnf really require curl? On my F-23 box:
> 
> $ rpm -e --test curl
> error: Failed dependencies:
> curl is needed by (installed) rpmdevtools-8.6-2.fc23.noarch
> curl is needed by (installed) pyrpkg-1.36-1.fc23.noarch
> curl is needed by (installed) dracut-live-043-63.git20151211.fc23.x86_64
> curl is needed by (installed) libreport-plugin-kerneloops-2.6.4-1.fc23.x86_64
> curl is needed by (installed) abrt-addon-kerneloops-2.8.0-3.fc23.x86_64
> curl is needed by (installed) abrt-addon-xorg-2.8.0-3.fc23.x86_64
> curl is needed by (installed) rpm-4.13.0-0.rc1.12.fc23.x86_64
> curl is needed by (installed) fedora-packager-0.5.10.7-1.fc23.noarch
> 
> Ah, rpm requires it (through %__urlhelpercmd). So I suppose there's
> the use case for curl-minimal I was wondering about.
> 
> > 
> > http://pkgs.fedoraproject.org/cgit/rpms/curl.git/log/?h=private-kdudka-libcurl-minimal
> 
> libcurl.so.x.y.z.minimal looks pretty weird to me, and wrong as well
> because it stuffs "minimal" into the version part, but the minimalism
> here is not really related to the version. Did you consider e.g.
> libcurl-minimal.so.x.y.z instead?

Shipping entirely non-standard, non-upstream SONAMEs (as appears to be what
is suggested) doesn't seem like a particularly good solution to me.

If it's just used by %__urlhelpercmd, why not make that a Suggests/Enhances?
It's not as if the normal DNF usage case requires RPM to be able to install
from a URL.

Bill
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Orphaning: xchat-gnome

[Bill Nottingham]

Reasons:
- it's effectively dead upstream (and has been for about 5 years...)
- it has a variety of crashers I haven't gotten around to finding time to fix
- I don't really use it any more anyways

Suggestions: use hexchat, or polari, or irccloud, or really anything else.
Or take it if you want.

Bill
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: three questions: f24 branch, python3 default, where to put /etc/rsyslog.d/gluster.conf.example

[Bill Nottingham]

Peter Robinson (pbrobin...@gmail.com) said: 
> > Yeah, this is because the Samba and FreeIPA packages didn't quite finish
> > their python 3 conversion in time. By F25, we should be able to avoid
> > shipping python 2 in the default installation of Fedora Server.
> 
> Except if you want to use ansible to managed that, although in theory
> support for that is on the nearish roadmap.

"near-ish" is relative, of course.. But it's in the works.

Bill
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Minimizing the fedora docker base image footprint

[Bill Nottingham]

Courtney Pacheco (cpach...@redhat.com) said: 
> Hi everyone,
> 
> I've spent some time trying to minimize the footprint of the Fedora docker
> base image. Overall, I managed to reduce its size by 39.9%.
> 
> A summary of the work I did can be found here:
> https://gist.github.com/iamcourtney/1a4af7c4289014f57080
> 
> If you're interested, you can find a more detailed version of the above work
> here: https://gist.github.com/iamcourtney/b8709ed897b7ecc9ac0f

May be a dumb question...

If we're excluding DNF, RPM, etc. for a slimmer base image during runtime,
how are we describing the best practices for build? Is the intention that
you should always be pulling in a separate tool container to assist with
the build process?

Bill
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: F24 Self Contained Change: System Python

[Bill Nottingham]

Miro Hrončok (mhron...@redhat.com) said: 
> I had this in mind as well, but currently, this is not the part of the
> change. Once we need this and we have system-python, we can propose a
> system wide change that system-python is a different version.

... is the goal that the system-python is outside of $PATH and has a
non-standard $PYTHONPATH as well?  That would seem to be where this is
heading.

Bill
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: On packager motivation

[Bill Nottingham]

Michael Schwendt (mschwe...@gmail.com) said: 
> > Sometimes a provenpackager will make a bad change, and that's
> > unfortunate, but it happens. Sometimes package owners make bad changes
> > too! :-)
> 
> You're taking it too lightly. Somebody who performs version upgrades really
> needs to take care of a package and incoming problem reports as well.

Is "you, as a provenpackager, are responsible for seeing any changes you
make to completion, and dealing with any fallout from them" not the current
policy?  If not, why wouldn't it be?

Bill
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: ZFS on linux

[Bill Nottingham]

Gerald B. Cox (gb...@bzb.us) said: 
> On Thu, Jan 14, 2016 at 9:25 AM, Stephen John Smoogen 
> wrote:
> 
> >
> > Here is a simple if then for figuring out how ZFS support may ever get
> > into Fedora:
> 
> 
> I originally believed it was simply a licensing issue that was preventing
> the inclusion in Fedora, but apparently that isn't true:
> http://warpmech.com/?news=myth-busting-series-zfs-on-linux-has-license-problems

As a rule, I try not to take legal licensing interpretations from a CTO
who's trying to sell me the thing they're talking about the licensing of.

We certainly could send that interpretation of CDDL/GPL and the kernel to the
legal team... but I'm not sure they'd agree with it.

Bill
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: ansible in Fedora 23+ (python3)

[Bill Nottingham]

Till Maas (opensou...@till.name) said: 
> On Wed, Nov 18, 2015 at 04:00:41PM -0800, Adam Williamson wrote:
> 
> > OK - so what's the clear and non-controversial definition of "modules
> > like 'file', 'template' and 'copy'"? What do those modules share in
> > common that we can define clearly and concisely and in a way there
> > won't be any serious dispute over?
> 
> Maybe "packages needed to be able to to use and configure the default
> package manager". For example one might need to be able to adjust the
> dnf repo config to be able to actually install pkgs, if there is a
> restrictive firewall for example and only local mirrors are accessible
> or a proxy has to be used.

I would say "packages needed to be able to install software and then do
basic configuration of the system" - this would be:

- $package_manager
- core modules from http://docs.ansible.com/ansible/list_of_system_modules.html
- core modules from http://docs.ansible.com/ansible/list_of_files_modules.html

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

Re: ansible in Fedora 23+ (python3)

[Bill Nottingham]

Adam Williamson (adamw...@fedoraproject.org) said: 
> On Tue, 2015-10-13 at 22:21 -0400, Dusty Mabe wrote:
> > 
> > Does anyone have a good solution for this? Obviously it would be nice
> > if ansible went to python3 but I think they have stated clearly that
> > they are sticking with python2 for backwards compat with systems that
> > still need 2.4.
> 
> FWIW, as this came up in the Server WG meeting this morning, we decided
> to Do Something About It:
> 
> https://git.fedorahosted.org/cgit/comps.git/commit/?id=4b9858ce8cabdec83bb78ab5f7af4c704278bdc2
> https://git.fedorahosted.org/cgit/spin-kickstarts.git/commit/?id=1d9ef5a9c1e148b979c68a1b510f6b007e652d93
> 
> I added a new package group - 'ansible-node' - which you can select to
> ensure the system can be managed via ansible. I decided that the
> definition of 'can be managed' is simply 'enough bits present that you
> can install any additional bits you need in the obvious way' - so for
> now the group simply includes 'python2-dnf'. But it means we have a
> 'result-based' mechanism for this so we can handle similar situations
> in future through this package group, and it makes it visible in the
> installer for interactive installs.
> 
> We *could* add a bunch of 'default' and/or 'optional' packages to the
> group for commonly-needed stuff like the selinux support packages
> needed for file operations, but I think for now I'd prefer to keep it
> simple and only include packages necessary for the 'dnf' module to
> work.

You really really want libselinux-python(2) for that as well - it's needed
for any file/copy/templating you'd do on the node to ensure proper SELinux
contexts. (In fact, Ansible will abort on the node without it if it detects
SELinux in use, as it doesn't want to misconfigure the node.)

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

Re: ansible in Fedora 23+ (python3)

[Bill Nottingham]

Adam Williamson (adamw...@fedoraproject.org) said: 
> > You really really want libselinux-python(2) for that as well - it's needed
> > for any file/copy/templating you'd do on the node to ensure proper SELinux
> > contexts. (In fact, Ansible will abort on the node without it if it detects
> > SELinux in use, as it doesn't want to misconfigure the node.)
> 
> Well, I explicitly addressed that above: I think as soon as you get
> into adding packages that are needed for some particular module, you're
> on a slippery slope which winds up with including docker...how do we
> decide which modules are 'essential' and which aren't?

I think that the slipperly slope argument is taking the easy way out here. 
Ensuring
that modules like 'file', 'template', and 'copy' work is not the same as 
including
docker in the minimal image.

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

Re: ansible in Fedora 23+ (python3)

[Bill Nottingham]

Kevin Kofler (kevin.kof...@chello.at) said: 
> Fabio Alessandro Locati wrote:
> > Also, the problem is that RedHat still supports RHEL5 systems which
> > for today standards are totally legacy and therefore it has to run on
> > Python 2.4.
> 
> The point of forking would be that the fork wouldn't have to care. Let the 
> upstream project deal with ancient legacy systems, the rest of the world can 
> and should move on.

I don't know how to say this other than your concept of what the "rest of
the world" wants being different from what the current upstream project works on
is entirely wrong.

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

Re: ansible in Fedora 23+ (python3)

[Bill Nottingham]

Robert Kuska (rku...@redhat.com) said: 
> > > Yes, DNF module works for ansible from the box. We worked at it for
> > > some time: https://github.com/ansible/ansible-modules-extras/pull/527
> > 
> > ...with the caveat from the first post in this thread: You will need to
> > have the python2 dnf bindings installed for it to work.
> > 
> > kevin
> 
> It seems to be python3 ready, isn't just changing shebang to /usr/bin/python3
> sufficient?

Not sure if you're referring to dnf, the dnf python bindings, or Ansible
here, but just to give background:

Ansible works by connecting to other machines and sending across small bits
of python to execute.  In Ansible parlance, these are called 'modules'.  What
this means is that the version of python that you're using on the control
machine needs to reasonably match the version of python on machines you're
controlling, and that all bindings you use in your modules need to be of the
same python version as the Ansible version you're using.  If Ansible were to
use python3, all module bindings would need to be python 3, and *all the
managed machines would need to have python3 installed*.

This is why as of now Ansible will always be somewhat 'trailing' in terms of
its python support - it needs to continue to work in a way congruent with
the overwhelming majority of the machines that Ansible is currently being
used to manage.  That means python 2, and that all the bindings used for
package managers (yum, dnf), bindings for modules that need to set file
attributes (libselinux), or even for talking to cloud things (shade, boto)
need to be python2.

It's great that Fedora is moving to python 3, and we're happy to to work
with the Fedora teams with their use of Ansible, but the percentage of
people using Ansible to manage Fedora (and other python3-using-distros)
doesn't justify moving Ansible to python3 at this time.

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

Re: comps packagereq items default to "mandatory"

[Bill Nottingham]

Orion Poplawski (or...@cora.nwra.com) said: 
> Almost none of those appear to be "Mandatory".
> 
> We think this is becoming an issue now because it appears that dnf perhaps now
> prevents kickstart installs from removing mandatory packages from the install
> set.  See https://bugzilla.redhat.com/show_bug.cgi?id=1199868 and the good
> detective work done by Adam Williamson for more background.
> 
> So, it seems we can either (perhaps) go back to the previous behavior, and/or
> fix comps.  We may want to fix comps anyways as I expect this has UI effects
> as well (perhaps cannot deselect packages after selecting a group?).

Unless something has changed (possible, haven't been playing close
attention), there's no individual package selection for groups, so there are
no UI effects.

Historical info:

This was generally intentional - the group is intended to define a specific set
of packages that would be ensured to be there if that group was installed.
Optional selections are for groups which only have optional packages, or
optional groups that would be selected for particular environments.

That can always be revisited, but the initial premise was that groups of
that form that are specified as they are in comps now weren't supposed to be
modifyable in that way. (Even if yum-based anaconda let you do it in
kickstart.)

Bill


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

Re: Proposal to reduce anti-bundling requirements

[Bill Nottingham]

Adam Williamson (adamw...@fedoraproject.org) said: 
> > Similarly, if I'm developing some piece of software that embeds/uses
> > PostgreSQL, I'm likely targeting multiple distributions, potentially
> > including Fedora, CentOS, RHEL, Ubuntu, and more. Even if Postgres
> > is a core
> > well maintained part of Fedora, I'm not going to care about that
> > version.
> > I'm going to pick a constant version and pull it from something like
> > software collections (or, you know, upstream postgresql.org.)
> 
> Things like pgsql, for me, are the ones that make this discussion
> complex, because they can clearly go either way. There are certainly,
> I think, also cases where you *want* a distro package for it.

Yes, I can certainly see where you'd have a Postgres package for Fedora
end users, but not have it as part of the platform that third-party
packages are expected to use, for example.

> > To allow or not allow bundling is the small side point here - the
> > questions
> > should be more of "Are we a distribution of packages?  Are we an OS?
> >   Where
> > do we see the distribution/OS fit in how software is consumed and
> > provided?
> > Is that different for a Workstation vs an Atomic host?" Answer those
> > big
> > questions, and the questions on what to do along Ring0->RingN, what
> > bundling
> > to allow, etc. should fall out.
> 
> Absolutely this. Can you please stand for election to something again?
> :)

Heh. While I appreciate the sentiment, as Josh says, it's not about standing
for office, it's about having time to acutally do the consensus building,
the proposals, & the work, and that is time I don't have at the moment.

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

Re: Proposal to reduce anti-bundling requirements

[Bill Nottingham]

Stephen Gallagher (sgall...@redhat.com) said: 
> Sorry, I was unclear. I do agree that once upon a time, this was
> absolutely effective. I probably should have said something more along
> the lines of what you did below; that the battlefield has changed and
> our former tactics are no longer sufficient.

(Aside: using war metaphors implicitly frames the conversation in a way
that isn't great for mutual understanding.)

It's definitely true, though - the landscape has changed and our policies
likely should change with it.  When the policies were created, all software
was complied from source, there wasn't much effort done for providing builds
of software from an upstream location, and the goal of having All The
Softwares in one place under a Red Hat Linux/Powertools/Fedora.us/Fedora tent
made sense in terms of providing what users need. But that's *not the case*
any more, and these policies don't make as much sense.

1) There is an implied goal of "package all the things". Our policies work
against that.

I'd hope this is self-explanatory, but in case it's not: we have a
cumbersome process for new package review, strict requirements on bundling,
versioning, etc., and a long process for sponsorship. If we really intend to
package all the things, we need to streamline the process and make it
easier.

2) Our policies *actively work against upstream goals*

https://gregdekspeaks.wordpress.com/2012/01/06/why-the-fedora-isv-sig-never-caught-fire/

(Yes, 2012. Nothing has changed here, other than 'even more so'.)

Upstream wants their complex software tested on a stable set of components
for replicability and reliability.  We don't provide that (we rev libraries
very fast, and still have arguably 'too much' accidental breakage), and we make 
it
*worse* by forced unbundling (by making their software use a different set
of dependencies).

3) Does "package all the things" really make sense, anyway?

What is the gain from 'conform Chromium to our package regulations' gain us? 
A few people who won't just install Chrome for F/OSS reasons?  If that's the
goal, we should be clear that that's the tiny set of users we're targeting. 
Maybe it makes sense if we're moving to Chromium as our main deployed
browser ala the Endless folks.  But if we're not, banging Chromium into our
guidelines in a way that Google themselves doesn't particularly care about
or support doesn't gain us much.

Similarly, if I'm developing some piece of software that embeds/uses
PostgreSQL, I'm likely targeting multiple distributions, potentially
including Fedora, CentOS, RHEL, Ubuntu, and more. Even if Postgres is a core
well maintained part of Fedora, I'm not going to care about that version.
I'm going to pick a constant version and pull it from something like
software collections (or, you know, upstream postgresql.org.)

And this doesn't even dig into the web develoment world (woo bundled
javascript, or even vendored python), where the *only* reasonable solution
is ship-your-own-vendored-stuff-with-your-app.

4) Combine 2+3: The world has moved beyond the distro as the distribution 
mechanism

Upstreams want to get their stuff out and make it available. They want to
control their distribution mechanism and supported platform list in a way
they can support, and that leads to tools like FPM that exist for a very
real reason.

Similarly, large ecosystems exist for language infrastructure - python, JS,
ruby, and more. If there's a compelling case for "package the entirety of
pip/rubygems/npm, including all versions, in the distro" I haven't heard
it. Just use the upstream sources, and build tools to work with that. That's
what they are there for.

And that doesn't even mention containers, which is where everything is
moving - small immutable 'apps' separate from their data.  Fedora's not
going to run a verified container registry (at least, I HOPE NOT), so as
people move their apps to containers, again, our policies are irrelevant. 
(Plus, those containers are very likely to be based on something CentOS-ish
anyways, see #2 above.)

...

To allow or not allow bundling is the small side point here - the questions
should be more of "Are we a distribution of packages?  Are we an OS?  Where
do we see the distribution/OS fit in how software is consumed and provided?
Is that different for a Workstation vs an Atomic host?" Answer those big
questions, and the questions on what to do along Ring0->RingN, what bundling
to allow, etc. should fall out.

Bill

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

Re: Rawhide plans

[Bill Nottingham]

Jonathan Wakely (jwak...@redhat.com) said: 
 Rawhide already *perfectly* implies rolling to me.
 
 Rollin' rollin' rollin' though the streams are swollen.

Nice to see tht some things survive, some 17 years on
  https://lwn.net/1998/0820/rawhide.html

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

Re: Rawhide plans

[Bill Nottingham]

Rex Dieter (rdie...@math.unl.edu) said: 
 Kevin Fenzi wrote:
 
  * Matt opened a thread on the marketing list about renaming rawhide. It
  sounds like most people would prefer us to make the changes first,
  then and only then look at renaming.
 
 s/renaming/rebranding/
 
 I personally would prefer the name be preserved if at all possible, but if 
 the marketing gurus feel otherwise, so be it.

Certainly agree with making the changes first - if a name has a bad
reputation because of how things have worked in the past, if you don't
fix those things, that reputation will just move right onto the new name...

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

Re: Is it time to allow Chromium in Fedora?

[Bill Nottingham]

Chris Murphy (li...@colorremedies.com) said: 
 On Tue, Aug 11, 2015 at 12:41 PM, Gerald B. Cox gb...@bzb.us wrote:
  https://fedoraproject.org/wiki/Packaging:No_Bundled_Libraries
 
 Meanwhile, on OS X I was already given notification of Firefox being
 updated to 40.0.0 just a bit ago. And while I see Firefox 40.0 in
 koji, there are no Bodhi entries for it, so it's not in any repo.

FWIW, I installed that build from koji a few days ago. It crashed every 15
minutes or so. Hence, I assumed the reason it's not in Bodhi was intentional.

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

Re: Validity of i686 as a release blocker

[Bill Nottingham]

Paul W. Frields (sticks...@gmail.com) said: 
 On Tue, Aug 04, 2015 at 09:47:27AM -0400, Josh Boyer wrote:
 [...snip...]
  Perhaps it is time that we evaluate where i686 stands in Fedora more
  closely.  For a starting suggestion, I would recommend that we do not
  treat it as a release blocking architecture.  This is not the same as
  demotion to secondary architecture status.  That has broader
  implications in both buildsys and ecosystem.  My suggestion is
  narrowly focused so that builds still proceed as today, but if there
  is something broken for i686 it does not block the release of whatever
  milestone we are pursuing.
  
  (To be clear, I would support a move to secondary arch status for
  i686, but I am not suggesting it at this time.)
 
 So to put a finer point on this, our shipping i686 images depends on a
 broader community effort beyond the kernel maintainers in the Fedora
 Engineering team.  That needs to precisely not mean more heroics on
 the part of e.g. QE, rel-eng, etc.  I have no idea what the pushback
 on this issue is, but I'm sure this thread will tell us.  But given
 that Fedora is supposed to encourage such community effort, it would
 be good to see what people are willing to do to build it.

Here's my perspective as an i686 Fedora user...

I have a box (2009-ish) that's in use as a file/backup server. As such, I don't
spend a lot of time futzing with it - it doesn't run rawhide, it rarely runs
the prereleases until beta or later time.  If something breaks, I'll look at
it, send some feedback, update it as necessary, and back off to a working
version.  And historically, it *hasn't* broken.

But, if it did break that hard... would I spend a month digging into the
kernel source and bisecting to try and find a fix? Or would I spend the
$100-120 to slap a new motherboard in it and install the x86_64 version?

I'd like to say I'd do the former. But realisitically it's the latter. And I
wonder how much of the i686 Fedora-using community is in the same boat.

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

Re: gross DNF bandwidth inefficiency if filesystem space limited

[Bill Nottingham]

Kevin Fenzi (ke...@scrye.com) said: 
 So, you are proposing we do things exactly as we are now, but also keep
 around all previous copies of the packages in the repos (but not in the
 repodata)? 
 
 I'm not sure if that setup would work with dnf. I think it requires
 whatever mirror(s) it uses to match the metadata. If you have a older
 metadata and the mirror you hit has been updated, I think dnf will say
 that the repodata doesn't match and try another. 

At some point, it might be worth doing cost/benefit analysis on continuing
down our existing mirroring strategy and designing for the limits of that
vs. the application of some sponsor funds towards the use of more standard
CDN service and methodology.

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

Re: Pushing the extra AppData files into Rawhide

[Bill Nottingham]

David Timms (dti...@iinet.net.au) said: 
 On 01/04/15 00:34, Richard Hughes wrote:
  On 31 March 2015 at 14:07, David Timms dti...@iinet.net.au wrote:
  I see my package was adjusted, but I can't get it to build:
  
  I only build the new-enough libappstream-glib into rawhide -- seeing
  as most of the f23 builds have succeeded I'll do the same for F22 and
  submit an update. F20 is much too old for that version of
  appstream-glib, and I'm not sure the gnome-software in f20 actually
  supported screenshots :/
  
 Thanks Richard.
 
 I would love to be able to keep the spec files same as possible.
 $ appstream-util --version
 Version:  0.2.5
 
 What is the minimum version ?
 
 Can someone give me a simple spec file conditional to achieve:
 
 if appstream-util --version = 0.2.5
 {
   appstream stuff
 }

I thought about trying to reliably parse major/minor/subminor versions in
bash, and track it against where things were implemented. But then just went
the lazy route:

if appstream-util --help | grep -q replace-screenshots ; then
  ... do stuff here ...
fi

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

Re: Why -mtune=atom?

[Bill Nottingham]

Florian Weimer (fwei...@redhat.com) said: 
 The default CFLAGS set by RPM include “-mtune-atom”.
 
 Why?  I doubt Atom CPUs are Fedora's primary target.  It's not even a
 documented GCC option.  There is such a wide variety of CPUs under this
 label that it's not even clear what it would mean.
 
 If it's better than “-mtune=generic” or the GCC default, shouldn't GCC
 be fixed?

https://www.redhat.com/archives/rhl-devel-list/2009-June/msg01506.html

(Yes, it's possible things have changed - benchmarks would be welcome.)

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

Re: Ramblings and questions regarding Fedora, but stemming from gnome-software and desktop environments

[Bill Nottingham]

Hedayat Vatankhah (hedayat@gmail.com) said: 
 
 /*Bill Nottingham nott...@splat.cc*/ wrote on Tue, 6 Jan 2015 11:39:27
 -0500:
 ...
 - Even searching for -devel packages implies a target == host build
sensibility that is relevant mostly to those developing Fedora, and
not to most of those developers that I run into on a day-to-day basis
(and likely not the developers we're targeting.) They're interested
in using mock along with system libraries for RHEL/CentOS, using
pip/npm/rubygems, etc.

 So you mean that Fedora target developers are either using dynamic
 languages, or they develop native software for RHEL/CentOS?! So you believe
 that target == rhel/centos? And native software developers for *modern*
 distros are not targets? This is really offending. RHEL/CentOS themselves
 should mainly target their developers. I guess that most of the developers
 you run into are working for RedHat.

... Not at Red Hat now, but what I'm saying is that the developers I
interact with are targeting mainly Ubuntu LTS and CentOS/RHEL, even if their
devel platform is Fedora.  It goes back to uses of Fedora in production -
while Fedora Server certainly wants to change this, most all of the
*deployed* server systems that people are targeting for their code aren't
Fedora.  Once you assume that you want to support the use case of developers
using Fedora to develop for things that aren't Fedora, I just feel
that worrying about a package tool for installing -devel packages pales in
trying to streamline the workflows the developers needs around using things
like mock and jenkins as build tools, and test environments that aren't even
local to the machine at all, whether they involve virtualization,
containers, or remote cloud services.

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

Re: Deleting f20-gnome-3-12 copr

[Bill Nottingham]

Pete Travis (li...@petetravis.com) said: 
 On Jan 7, 2015 6:00 AM, Richard Hughes hughsi...@gmail.com wrote:
 
  I'm planning to delete
  https://copr.fedoraproject.org/coprs/rhughes/f20-gnome-3-12/ this
  week. The original description always had This COPR will be updated
  until Fedora 21 has been released or until the entropy death of the
  universe, whichever happens first. so I don't altogether feel too
  guilty about abandoning it. Does anyone have any objections or wants
  to volunteer to take it over before I delete the repo?
 
  Richard
  --
 
 While recognizing the massive maintenance burden of this COPR, I suspect
 the majority of objections will come from the enthusiast end user type -
 you know, the ones that are so eager to try the new thing they read about
 that they blow right past the description.  This COPR received a lot of
 publicity; fedoramagazine articles, social media, blog posts, etc.

While I'm not volunteeering to maintain this, I do ask - what is the reason
for deleting it vs. just leaving it around in a EOL state where it's not being
updated? We don't remove EOL releases, for example.

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

Re: Ramblings and questions regarding Fedora, but stemming from gnome-software and desktop environments

[Bill Nottingham]

Andrew Lutomirski (l...@mit.edu) said: 
 On Mon, Jan 5, 2015 at 10:36 AM, Miloslav Trmač m...@redhat.com wrote:
  While I think you are right in some cases like cashier, isn't this
  discussion really about the Fedora Workstation?! Since for this the
  target user is a developer, can we just agree that in this case the user
  needs both CLI and GUI apps (although some developers certainly sticks
  to one of them).
 
  The gist is that
  * Nobody _should_ need to use a terminal: non-developers¹ don’t need it, 
  and developers deserve a better environment.  It’s “only” a matter of 
  writing lots of new software.  AFAICT Workstation would in some ideal 
  future want to get to this state.  (And non-Linux operating systems are 
  getting closer and closer to this ideal over time.)
 
 Having watched people develop under Mac OS X, they have really shiny
 things to play with.  Xcode is pretty, and there are whole pile of
 nice editors and such to use.  Heck, even Firefox and Chromium are
 gradually turning into developer tools as opposed to just being
 browsers and debuggers.
 
 Nonetheless, the productive Mac OS X developers I know all have
 something like an entire desktop devoted to just running terminals.
 
 Given that no one, on any OS I've ever seen*, has come up with
 something better than a terminal for running scripts, watching log
 messages scroll by, using fancy shell commands, etc., I think that
 expecting Fedora to magically solve all these problems is both overly
 optimistic and is an entirely inappropriate assumption to base the OS
 design on.

I'm not sure that GNOME Software is the right place to solve this, though -
if I'm using the terminal to build things:

- I shouldn't be searching for grep/sed/awk - those are part of the base
  operating system, and should be treated as such.
- I shouldn't be searching for gcc, gcc-c++, make, etc. as separate
  promoted to GNOME Software applications; those should be treated as part
  of a development kit that's installed and updated as a unit, any more than
  I should be searching for libgweather or libdrm as part of installing a
  desktop app.
- Even searching for -devel packages implies a target == host build
  sensibility that is relevant mostly to those developing Fedora, and
  not to most of those developers that I run into on a day-to-day basis
  (and likely not the developers we're targeting.) They're interested
  in using mock along with system libraries for RHEL/CentOS, using
  pip/npm/rubygems, etc. 

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

Re: How to handle upgrades to Fedora 21

[Bill Nottingham]

Stephen Gallagher (sgall...@redhat.com) said: 
 Rehashing the conversation elsewhere, the problem with DIY and similar
 is that it doesn't make much sense in the context of Spins, which are
 non-productized but not particularly do-it-yourself.

While they're not DIY in the context of the initial install, they're not
going to get the 'always get the latest version of the $PRODUCT features'
that fedup and the assocated infrastructure may enforce for actual products
(unless I missed something?).  This means that they're likely to have more
and more drift from the initial spin as time goes on, leaving them in a more
custom state.

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

Re: Comps fails to validate (patch inside!)

[Bill Nottingham]

As the guilty party in many cases for not updating the .rng file...

Kevin Fenzi (ke...@scrye.com) said: 
  The comps-el4.xml.in and comps-el5.xml.in changes remove a nearly
  empty group named editors.  The description claims that the group
  contains emacs and vi, but it doesn't.  All it contains is an XEmacs
  metapkg.  As an XEmacs developer, I am flattered that our product was
  included, but the current comps.rng knows nothing of metapkg.  This
  looks like it was mistakenly included, or mistakenly not removed all
  the way, hence the removal.
 
 Seems fine. 

As Kevin said, EPEL groups are additive to RHEL groups; the descriptions are
supposed to match what they are in RHEL/CentOS if they share the name of a
group in EL. Hence, you can remove an empty 'editors' group, but I wouldn't
change the description.

  In comps-epel7.xml.in, we currently have an environment prior to any
  group.  That is not allowed by comps.rng, which wants all groups
  first, then environments.  This patch moves the environment to
  satisfy that restriction.  But there is something odd here.  That is
  the one and only environment in the file.  Is this a mistake?
  Should there be environments in comps-epel7.xml.in at all?  If so,
  where are the rest of them?
 
 epel comps files are additive to rhel comps files. So, they will be
 much smaller in general and not have any of the base env stuff. 
 I don't know off hand if rhel7 uses env's, but I think so. 

It does.

  In addition to the dangling clustering reference that started this
  thread, comps-f18.xml.in, comps-f19.xml.in, comps-f20.xml.in,
  comps-f21.xml.in, and comps-f22.xml.in all have a libreoffice group
  that is missing default and uservisible elements.  i took my best
  guess at what the values of those elements should be.  In addition,
  all but comps-f18.xml.in have a group named 3d-printing.  However,
  that is not a valid ID, because it starts with a digit.  I changed it
  to three-d-printing, but somebody can probably come up with a better
  name than that.
 
 Fun. 

Please don't change group names in released releases - it's essentially an
ABI for kickstart files, and we don't want to break those. I suspect the fix
here is to change the definition to allow groups that start with a number -
yum handles this OK.


  There are quite a few packagereq elements that do not carry a type
  attribute.  It looks like comps.rng is supposed to support this, and
  that those elements are supposed to default to the type optional.
  However, the type attribute has to be optional for that to work.

It's not optional - having no type set makes the type 'mandatory'. From the
yum code:

genre = child.attrib.get('type')
if not genre:
genre = u'mandatory'

The logic is that for groups that are used as building blocks of
environments, they're not intended to be modified - so all packages are
mandatory, and there are no optional/defualt ones.


  In the core group, there is a package declared like this:
  
packagereq arch=armhfp
  type=mandatoryuboot-tools/packagereq
  
  but comps.rng doesn't know anything about an arch attribute.
  Assuming that this is actually correct, and that consuming tools know
  to expect such an attribute, I added support for this to comps.rng.
 
 No idea here. Dennis and/or other arm folks might know more.

yum doesn't use arch= here, but it's used by some tools that process comps
files to write new ones. It's fine to add it to comps.rng.

  Finally, in some environment's optionlist's groupids, a
  default attribute has appeared.  The current comps.rng does not
  allow that.  Once again, assuming that this is actually correct and
  that consuming tools expect that attribute, I added support for it.

Yes, that's correct.

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

Re: Cc: on dead packages

[Bill Nottingham]

Bastien Nocera (bnoc...@redhat.com) said: 
 Apparently, people can still file bugs for dead packages:
 https://bugzilla.redhat.com/show_bug.cgi?id=1114180
 
 And I (and many others) get CC:ed on those bugs files, with
 no possibility to remove ourselves from the CC: in pkgdb.
 
 Any idea where I should be filing a bug for this bug?

It's a combination of:

- we only have one Fedora 'product' with components per-package
- you can't disable filing against components
- you can't *remove* components unless they have no bugs against them

If we made each Fedora release a separate product, we could then
tailor the list for each release. If explicitly moved all the bugs (even old
closed ones) away from old components, we could then delete them. But we
haven't done either of those things.

It may be possible to have the enter_bug.cgi page filter the allowable
components by the release version.

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

Re: comps categories: are they any use to anyone any more?

[Bill Nottingham]

Adam Williamson (awill...@redhat.com) said: 
 Working on comps for the NetworkManager submodule change (see other
 email) made me wonder: are the comps 'categories' actually used for
 anything any more?
 
 I believe they were used in oldUI for presentation of the 'pick a
 package' UI. We don't have that UI any more, haven't since Fedora 18. I
 don't believe anaconda uses the categories any more. newUI shows
 environment groups down the left hand side of the screen. On the right
 hand side it shows the optional groups related to the current
 environment group at the top, and then all other user visible package
 groups at the bottom.
 
 So if I'm right that anaconda isn't using the categories any more, is
 anything else? Or can we just ditch them?

Check the post-install tools; I believe at least one of apper or yumex still
uses them.

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

Re: [RFC] plans for initscripts in F22

[Bill Nottingham]

Lukáš Nykrýn (lnyk...@redhat.com) said: 
 Also the sysctl stuff should be consumed by systemd:
 /usr/lib/sysctl.d/00-system.conf
 /etc/sysctl.conf
 /etc/sysctl.d/99-sysctl.conf
 
 Can we have a joint initscripts + systemd release in a few days to
 change ownership of those files?
 
 Sounds great. I will removed that from upstream and let you know.

Historically, configuration like these (aside from the placeholders) are in
initscripts because systemd didn't want to carry them - it's configuration
that wasn't covered or was different from the upstream 50-default.conf.  If
the systemd maintainers are willing to have the Fedora default config
different from upstream, then merging it makes sense. But shipping both
00-system.conf and 50-default.conf in one package doesn't make as much
sense.

 initscripts-doc
 initscripts-locale
 initscripts-man

 I too think that this split is a lot of work for small gain. Working
 out the full dependencies set of what needs what is going to take a
 while, but I think it would be better to simply shrink the package to
 nothing in small steps.

I really don't think we should do things like -locale, -doc, and -man
at the inidivdual package level. It should be done at the distribution level
automatically (vis-a-vis debuginfo), or not done at all. Doing it manually
just leads to a potential for errors and inconsistency.

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

Re: [RFC] plans for initscripts in F22

[Bill Nottingham]

Michael Scherer (m...@zarb.org) said: 
  For LSB, there is an explicit promise that if a vendor does what is
  specified, the package will be possible to install and will run
  correctly.  We do, of course, have the option to repudiate LSB and
  explicitly say we don't care for future releases.
 
 So shouldn't redhat-lsb or some subpackage be the one that pull that
 part ?

redhat-lsb-core packages the standardized lsb init script functions; these
source things from /etc/init.d/functions, but don't have an explicit
requirement on that file. That should be fixed; then things can be moved
wherever.

It, of course, does not solve the problem that most random Red
Hat/Fedora-specific SysV scripts out there source that file without any
particular requirements, even if they are started by systemd.

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

Re: F21 System Wide Change: Cockpit Management Console

[Bill Nottingham]

Jaroslav Reznik (jrez...@redhat.com) said: 
 I think this definitely better way - not being as strict regarding
 deadlines for Cockpit and get some test coverage during later Test
 Day.

I'd be fine with a later deadline for Cockpit if needed, especially since
(from the feature page description) it doesn't seem to have much of a
knock-on effect on other components. I'm actually a little curious how this
isn't a standalone addition, aside from just the 'installed by default in
Fedora Server' angle.

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

Re: F21 System Wide Change: Ruby193 in SCL

[Bill Nottingham]

Marcela Mašláňová (mmasl...@redhat.com) said: 
 On 04/14/2014 10:17 PM, Bill Nottingham wrote:
 Jaroslav Reznik (jrez...@redhat.com) said:
 = Proposed System Wide Change: Ruby193 in SCL =
 https://fedoraproject.org/wiki/Changes/Ruby193_in_SCL
 
 Change owner(s): Marcela Mašláňová mmasl...@redhat.com
 
 Ruby 1.9.3 with Rails 3.2.8 is still commonly used by many projects. Let's
 provide Ruby and Rails in SCL even for Fedora. Rails depends on exact v8
 version, which means v8 3.14 must have also their own SCL as part of the 
 SCL.
 
 Is the intent to only provide SCL versions of the older ruby  rails, or
 also the current versions (i.e., move to SCL as the rails delivery mechanism
 going forward)?

 I'm doing one collection. If there is someone who want to donate his free
 time to do also new version, I'm fine with it, but I don't see any use-case
 right now.

What I was thinking of was simply having a uniform way to access a rails
stack (or whatever) - not having to have the developer/admin keep track of
whether the version they want is packaged as an SCL or not, and having to
adjust their environment/setup accordingly.

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

Re: F21 System Wide Change: Workstation: Disable firewall

[Bill Nottingham]

Miloslav Trmač (m...@volny.cz) said: 
 AFAICS this discussion basically says applications can't depend on
 firewalld, therefore they can't use firewalld APIs, therefore they wouldn't
 know whether the firewall restircts them, therefore firewalld must be
 removed.
 
 The only given reason why the applications can't depend on firewalld is
 vague claims that the D-Bus API is somehow unusable, which is clearly false
 because firewall-cmd is using exactly the same API.

Well, just because an API *can* be coded to doesn't make it a good API. It
would be great to get more concrete descriptions of where the API fails.

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

Re: F21 Self Contained Change: Remote Journal Logging

[Bill Nottingham]

Zbigniew Jędrzejewski-Szmek (zbys...@in.waw.pl) said: 
 On Mon, Apr 14, 2014 at 04:20:16PM -0400, Bill Nottingham wrote:
  Jaroslav Reznik (jrez...@redhat.com) said: 
   = Proposed Self Contained Change: Remote Journal Logging = 
   https://fedoraproject.org/wiki/Changes/Remote_Journal_Logging
   
   Change owner(s): Zbigniew Jędrzejewski-Szmek zbys...@in.waw.pl
   
   Systemd journal can be configured to forward events to a remote server. 
   Entries are forwarded including full metadata, and are stored in normal 
   journal files, identically to locally generated logs. 
  
  What's the future of gatewayd if this becomes more widely used?

 gatewayd works in pull mode. Here I'm proposing a push model, where the
 client (i.e. machine generating the logs) pushes logs to the server
 at the time of its own chosing. gatewayd is probably better for some use
 cases, this for others.

I understand the pull vs push distinction ... I'm just not clear why pull
would ever be a model you'd want to use. (vs something like a local cockpit
agent.)

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

Summary/Minutes for Wednesday's FESCo meeting (2014-04-16)

[Bill Nottingham]

===
#fedora-meeting: FESCo (2014-04-16)
===


Meeting started by notting at 17:01:57 UTC. The full logs are available
at
http://meetbot.fedoraproject.org/fedora-meeting/2014-04-16/fesco.2014-04-16-17.01.log.html
.

Meeting summary
---
* init process  (notting, 17:02:08)

* #1221Product working group activity reports  (notting, 17:06:01)

* #1244F21 System Wide Change: cron to systemd time units -
  https://fedoraproject.org/wiki/Changes/cron-to-systemd-time-units
  (notting, 17:09:19)
  * AGREED: wait until next week (+:all)  (notting, 17:15:24)

* #1250F21 Self Contained Changes  (notting, 17:16:08)
  * LINK: https://fedoraproject.org/wiki/Changes/ApacheAmbari
(notting, 17:16:43)
  * LINK: https://fedoraproject.org/wiki/Changes/ApacheAccumulo
(notting, 17:16:50)
  * AGREED: Apache Accumulo, Ambari, and Pig changes approved (+:6, -:0)
(notting, 17:24:09)
  * suggest coalescing of Hadoop and Hadoop-related changes for
relnote/doc purposes  (notting, 17:24:33)
  * AGREED: Playground Repo should be promoted to a System-Wide Change.
Playground Repo change deferred for a week for more discussion (+:6,
-:0)  (notting, 17:26:41)

* #1280F21 System Wide Change: Framework for Server Role Deployment
  -
  https://fedoraproject.org/wiki/Changes/FrameworkForServerRoleDeployment
  (notting, 17:27:42)
  * AGREED: Framework for Server Role Deployment approved (+:5, -:0,
0:1)  (notting, 17:30:51)

* #1279F21 System Wide Change: Database Server Role -
  https://fedoraproject.org/wiki/Changes/DatabaseServerRole  (notting,
  17:31:18)
  * AGREED: Database Server Role approved (+:6, -:0)  (notting,
17:32:20)

* #1281F21 System Wide Change: Domain Controller Server Role -
  https://fedoraproject.org/wiki/Changes/DomainControllerServerRole
  (notting, 17:32:22)
  * AGREED: Domain Controller Server Role approved (+:6, -:0)  (notting,
17:34:36)

* #1282F21 System Wide Change: Fedora 21 Boost 1.56 Uplift -
  https://fedoraproject.org/wiki/Changes/F21Boost156  (notting,
  17:34:45)
  * AGREED: Boost 1.56 Uplift is approved (+:6, -:0)  (notting,
17:37:02)

* #1283F21 System Wide Change: GNOME 3.12 -
  https://fedoraproject.org/wiki/Changes/GNOME3.12  (notting, 17:37:15)
  * AGREED: GNOME 3.12 is approved (+:6, -:0)  (notting, 17:43:25)
  * if 3.14 is desired in the future, please raise separately  (notting,
17:43:46)

* #1284F21 System Wide Change: Mono 3.4 -
  https://fedoraproject.org/wiki/Changes/Mono_3.4  (notting, 17:44:11)
  * AGREED: Mono 3.4 feature approved (+:5, -:0, 0:0)  (notting,
17:53:55)
  * please talk to existing mono maintainers (laxathom, chkr)  (notting,
17:54:09)

* #1285F21 System Wide Change: PHP 5.6 -
  https://fedoraproject.org/wiki/Changes/Php56  (notting, 17:55:22)
  * AGREED: PHP 5.6 approved (+:6, -:0)  (notting, 17:57:10)

* #1273Policy interpretation on proprietary products in
  gnome-software, gnome overview search results  (notting, 17:58:46)
  * LINK: https://fedorahosted.org/fesco/ticket/1273#comment:56
(nirik, 18:18:56)
  * AGREED: Add kalev to ticket, point him at board request., note FESCo
does not generally think current proposal implements that request.
Work issue in ticket. (+:5, -:0)  (notting, 18:53:08)

* Next week's chair  (notting, 18:56:21)
  * nirik will chair next week's meeting  (notting, 18:57:44)

* Open Floor  (notting, 18:58:07)
  * please make sure to review and comment on change proposals before
they reach FESCo  (notting, 19:01:58)
  * releng plans to disallow deletion of bodhi updates (packages in
updates can still be removed)  (notting, 19:06:25)

Meeting ended at 19:09:29 UTC.


Action Items



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


People Present (lines said)
---
* notting (110)
* nirik (77)
* jwb (73)
* mitr (60)
* pjones (52)
* abadger1999 (50)
* dgilmore (32)
* t8m (21)
* zodbot (17)
* mjg59 (16)
* drago01_ (6)
* randomuser (5)
* drago01 (4)
* adamw (2)
* jreznik (2)
* zoglesby (1)
* sgallagh (0)
* mmaslano (0)
* mattdm (0)

Generated by `MeetBot`_ 0.1.4

.. _`MeetBot`: http://wiki.debian.org/MeetBot
17:01:57 notting #startmeeting FESCo (2014-04-16)
17:01:57 zodbot Meeting started Wed Apr 16 17:01:57 2014 UTC.  The chair is 
notting. Information about MeetBot at http://wiki.debian.org/MeetBot.
17:01:57 zodbot Useful Commands: #action #agreed #halp #info #idea #link 
#topic.
17:02:08 notting #meetingname fesco
17:02:08 zodbot The meeting name has been set to 'fesco'
17:02:08 notting #chair abadger1999 dgilmore mattdm mitr notting nirik pjones 
t8m sgallagh mmaslano jwb
17:02:08 notting #topic init process
17:02:08 zodbot Current chairs: abadger1999 dgilmore jwb mattdm mitr mmaslano 
nirik notting pjones sgallagh t8m
17:02:16 t8m hi
17:02:16 nirik morning
17:02:20 pjones hello, party people.
17:02:34 * jwb is 

Schedule for Wednesday's FESCo meeting (2014-04-16)

[Bill Nottingham]

Following is the list of topics that will be discussed in the FESCo
meeting Wednesday at 17:00UTC in #fedora-meeting on irc.freenode.net.

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

or run:
  date -d '2014-04-16 17:00 UTC'


Links to all tickets below can be found at: 
https://fedorahosted.org/fesco/report/9

= Followups =

#topic #1221Product working group activity reports
.fesco 1221
https://fedorahosted.org/fesco/ticket/1221

#topic #1244F21 System Wide Change: cron to systemd time units - 
https://fedoraproject.org/wiki/Changes/cron-to-systemd-time-units
.fesco 1244
https://fedorahosted.org/fesco/ticket/1244

= New business =

#topic #1250F21 Self Contained Changes
.fesco 1250
https://fedorahosted.org/fesco/ticket/1250

#topic #1280F21 System Wide Change: Framework for Server Role Deployment - 
https://fedoraproject.org/wiki/Changes/FrameworkForServerRoleDeployment
.fesco 1280
https://fedorahosted.org/fesco/ticket/1280

#topic #1279F21 System Wide Change: Database Server Role - 
https://fedoraproject.org/wiki/Changes/DatabaseServerRole
.fesco 1279
https://fedorahosted.org/fesco/ticket/1279

#topic #1281F21 System Wide Change: Domain Controller Server Role - 
https://fedoraproject.org/wiki/Changes/DomainControllerServerRole
.fesco 1281
https://fedorahosted.org/fesco/ticket/1281

#topic #1282F21 System Wide Change: Fedora 21 Boost 1.56 Uplift - 
https://fedoraproject.org/wiki/Changes/F21Boost156
.fesco 1282
https://fedorahosted.org/fesco/ticket/1282

#topic #1283F21 System Wide Change: GNOME 3.12 - 
https://fedoraproject.org/wiki/Changes/GNOME3.12
.fesco 1283
https://fedorahosted.org/fesco/ticket/1283

#topic #1284F21 System Wide Change: Mono 3.4 - 
https://fedoraproject.org/wiki/Changes/Mono_3.4
.fesco 1284
https://fedorahosted.org/fesco/ticket/1284

#topic #1285F21 System Wide Change: PHP 5.6 - 
https://fedoraproject.org/wiki/Changes/Php56
.fesco 1285
https://fedorahosted.org/fesco/ticket/1285

#topic #1273Policy interpretation on proprietary products in 
gnome-software, gnome overview search results
.fesco 1273
https://fedorahosted.org/fesco/ticket/1273

= Open Floor = 

For more complete details, please visit each individual ticket.  The
report of the agenda items can be found at
https://fedorahosted.org/fesco/report/9

If you would like to add something to this agenda, you can reply to
this e-mail, file a new ticket at https://fedorahosted.org/fesco,
e-mail me directly, or bring it up at the end of the meeting, during
the open floor topic. Note that added topics may be deferred until
the following meeting. 
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: F21 System Wide Change: The securetty file is empty by default

[Bill Nottingham]

Jóhann B. Guðmundsson (johan...@gmail.com) said: 
 So let's just clear this matter once and for all...
 
 Is the baseWG supposed to be responsible for the decisions and direction and
 the length of maintenance of those 1806 components they self defined as a
 part of the baseWG?

In the same way that I'd expect the WS, Server, or Cloud WGs to comment on
changes filed that affect their deliverables if they feel they aren't what
Fedora should be doing in those areas, I'd expect the Base WG to comment on
system-wide changes that affect the common base of the products if they
think there may be issues. It can be discussed where the border of what the
base WG might look at is, but I'm comfortable with the default PAM
configuration being inside it.

Bill

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

Re: appdata handling

[Bill Nottingham]

Richard Hughes (hughsi...@gmail.com) said: 
  - How long does it take that the new appdata is propagated to gnome-software
 
 I do new builds nearly every day, but the builds that are shipped in
 gnome-software and pushed to users is usually updated every month or
 so.

A FAQ related to this that's not on the upstream page:

How do I locally check changes to my appdata inside gnome-software, as
opposed to just appdata-validate?

I tried this once, and it seemed to be a rather convoluted process.
Wondering if I did it wrong?

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

Re: F21 System Wide Change: Fedora 21 Make 4.0 Update

[Bill Nottingham]

Jaroslav Reznik (jrez...@redhat.com) said: 
 == Scope ==
 * Proposal owners:
 ** Rebase to make-4.0
 ** 6 patches need to be updated to work with new sources
 ** 14 patches will be removed as they are already supported by the make-4.0 
 rebase
 ** make.spec will be updated
 ** local build and test (already completed for glibc and gcc)
 ** patch created and submitted
 ** build 
 
 * Other developers:  There are some minor error message changes that may show 
 up as log file differences.
 
 If a package's makefile requires a specific version of make, the makefiles may
 need editing to include make 4.0.

We'd want this available before the mass rebuild, so we can catch any issues
related to it. Has an out-of-band rebuild been done that sees if there are
common failures?

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

Re: F21 System Wide Change: Smaller Cloud Image Footprint

[Bill Nottingham]

Jaroslav Reznik (jrez...@redhat.com) said: 
 == Scope ==
 As mentioned, there's really various changes that are quite independent of 
 each other but share the common goal.
 
 * Proposal owners:
 ** Replace NetworkManager, etc. with systemd-networkd.
 ** Make sure only just kernel-core, not kernel and kernel-drivers, is 
 installed (see the related change: Modular Kernel Packaging for Cloud [1]).
 ** Make sure only the packages really required are installed.
 ** Use %packages --excludedocs to to skip installing docs.
 ** Use %packages --instLangs= to ship only just English.
 ** Tweak the locales (in %post) so that local-archive ships with only just 
 English instead of all languages. We might skip this one if it seems too much 
 tinkering. Work is going on to have proper support for this in the glibc 
 package (see rhbz#156477 [2] - also, c#30 shows the necessary tinkering).

How do these changes (especially the first two) work in terms of the
cattle-to-pets feature?

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

Re: F21 Self Contained Change: Remote Journal Logging

[Bill Nottingham]

Jaroslav Reznik (jrez...@redhat.com) said: 
 = Proposed Self Contained Change: Remote Journal Logging = 
 https://fedoraproject.org/wiki/Changes/Remote_Journal_Logging
 
 Change owner(s): Zbigniew Jędrzejewski-Szmek zbys...@in.waw.pl
 
 Systemd journal can be configured to forward events to a remote server. 
 Entries are forwarded including full metadata, and are stored in normal 
 journal files, identically to locally generated logs. 

What's the future of gatewayd if this becomes more widely used?

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

Re: F21 System Wide Change: Ruby193 in SCL

[Bill Nottingham]

Jaroslav Reznik (jrez...@redhat.com) said: 
 = Proposed System Wide Change: Ruby193 in SCL = 
 https://fedoraproject.org/wiki/Changes/Ruby193_in_SCL
 
 Change owner(s): Marcela Mašláňová mmasl...@redhat.com
 
 Ruby 1.9.3 with Rails 3.2.8 is still commonly used by many projects. Let's 
 provide Ruby and Rails in SCL even for Fedora. Rails depends on exact v8 
 version, which means v8 3.14 must have also their own SCL as part of the SCL. 

Is the intent to only provide SCL versions of the older ruby  rails, or
also the current versions (i.e., move to SCL as the rails delivery mechanism
going forward)?

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

Re: F21 System Wide Change: BerkeleyDB 6

[Bill Nottingham]

Jaroslav Reznik (jrez...@redhat.com) said: 
 == Scope ==
 * Proposal owners: Create new set of packages and introduce proper versioning 
 in order to not confuse the dynamic linker.

Is this symbol versioning intended to be upstream?

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

Re: trimming down Fedora installed size

[Bill Nottingham]

James Antill (ja...@fedoraproject.org) said: 
  Not that I assume splitting lanauges and docs. into sub packages would
 triple primary numbers, but if it did ... that would be bad.

To put it in perspective, if we split out 'langpacks' for apps per language,
something like gedit then grows *100* new subpackages.

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

Re: Schedule for Thursday's FPC Meeting (2014-04-10 16:00 UTC)

[Bill Nottingham]

James Antill (ja...@fedoraproject.org) said: 
  For more complete details, please visit each individual ticket.  The
 report of the agenda items can be found at:
 
 https://fedorahosted.org/fpc/report/12
 
 
  If you would like to add something to this agenda, you can reply to
 this e-mail, file a new ticket at https://fedorahosted.org/fpc,
 e-mail me directly, or bring it up at the end of the meeting, during
 the open floor topic. Note that added topics may be deferred until
 the following meeting. 

The systemd timer guideline came up at FESCo today, and we had concerns over
the changes from MUST to SHOULD in the proposed guidelines - FESCo would
like them to remain as MUST. I'd like to discuss that, and any concerns FPC
might have with that, tomorrow with FPC if at all possible.

Bill

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

Re: trimming down Fedora installed size

[Bill Nottingham]

Florian Festi (ffe...@redhat.com) said: 
 1) Normal weak dependencies. In a normal install all the docs (and all
 other bells and whistles) get installed by default. You can
 remove/deselect packages which are pulled in by weak dependencies. You
 can even switch off all weak dependencies to only get the core packages.
 
 2) Rich dependencies. Doc and language packages can be build as
 bridging packages that are only installed if two other packages are
 present. This can be done by adding e.g.
 
 Recommends: foo-langpack-hu if langsupport-hu
 
 to package foo or
 
 Supplements: foo and langsupport-hu
 
 to the foo-langpack-hu package. Similar things can be done for docs or
 any other set of packages that should be controlled by a single switch
 package.

Given the number of packages that ship localization, this seems like it
would have a pretty dramatic effect on metadata size. Is this a concern?

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

Re: F21 System Wide Change: Framework for Server Role Deployment

[Bill Nottingham]

Jaroslav Reznik (jrez...@redhat.com) said: 
 = Proposed System Wide Change:  Framework for Server Role Deployment =
 https://fedoraproject.org/wiki/Changes/FrameworkForServerRoleDeployment
 
 Change owner(s): Miloslav Trmač mitr AT volny DOT cz, Fedora Server Working 
 Group server AT lists DOT fedoraproject DOT org 
 Responsible WG: Server 
 
 A new D-Bus service, and associated command-line tools, to deploy and manage 
 Server Roles. 
 
 == Detailed Description ==
 A new D-Bus service will be made available, exposing available server roles, 
 making it possible to deploy, configure and manage them. Appropriate 
 functionality will also be exposed as a command-line utility. 
 
 == Scope ==
 * Proposal owners: Write, document, package and test the D-Bus API.
 * Other developers: Possibly use the framework for development of new server 
 roles.
 * Release engineering: Nothing
 * Policies and guidelines: Nothing

This Change, as written, is *extremely* vague, moreso that most other
changes that are filed for Fedora.  Is it intended to be updated with more
information when that becomes available?

Bill

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

Re: F21 System Wide Change: lbzip2 as default bzip2 implementation

[Bill Nottingham]

Jaroslav Reznik (jrez...@redhat.com) said: 
 = Proposed System Wide Change:  lbzip2 as default bzip2 implementation =
 https://fedoraproject.org/wiki/Changes/lbzip2
 
 Change owner(s): Mikolaj Izdebski mizde...@redhat.com
 
 This change aims at making lbzip2 [1] default bzip2 implementation used in 
 Fedora. 
 
 == Detailed Description ==
 lbzip2 is an independent implementation of bzip2 compression tool. It 
 provides 
 interface strictly compatible with bzip2, but also adds several new features 
 and improvements, such as:
 
 * multi-threaded operation for both compression and decompression, with 
 almost 
 linear scalability,
 * improved performance, even on single-core systems,
 * improved extra utilities (bzdiff, bzless, bzip2recover, etc.),
 * improved compatibility with gzip. 
 
 lbzip2 is a mature project and it has been used in production for years. It 
 is 
 already packaged for Fedora and it is also available in EPEL.

A quick check shows lbzip2 doesn't provide a library interface, much less
one compatible with libbz2. Is that ever intended?

If it's not, saying lbzip2 is the default bzip2 *implementation* may be a
bit of a stretch. Perhaps s/implementation/command/.

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

Re: F21 Self Contained Change: NFS Ganesha File Server

[Bill Nottingham]

Jaroslav Reznik (jrez...@redhat.com) said: 
 = Proposed Self Contained Change: NFS Ganesha File Server =
 https://fedoraproject.org/wiki/Changes/NFSGanesha
 
 Change owner(s): Jim Lieb l...@sea-troll.net
 
 NFS Ganesha is a user mode file server that supports NFSv3, NFSv4, and 
 NFSv4.1 
 including pNFS for distributed filesystems. It uses loadable filesystem 
 driver 
 modules to support its backend filesystems. It also integrates 9P.2000L file 
 service. 

What's the long term roadmap for this vs. the existing NFS server? Why would
someone choose one over the other, aside from ues with pNFS?

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

Re: Fedora Present and Future: a Fedora.next 2014 Update (Part II, “What’s Happening?”)

[Bill Nottingham]

Richard W.M. Jones (rjo...@redhat.com) said: 
 It wasn't about whether VLC could go into Fedora, but if there going
 to be a ring, with the Fedora name, where basically anything goes
 including software of insalubrious legality (in the US).  And I guess
 the answer is no.

Correct - the relaxing of requirements that might be considered on 'outer'
rings that still carry the Fedora name would be of a technical, not legal,
nature.

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

Re: Heads up: Mesa/LLVM rebase and OpenGTL retirement in F20

[Bill Nottingham]

Adam Jackson (a...@redhat.com) said: 
 On Fri, 2014-03-28 at 07:39 -0400, Jaroslav Reznik wrote:
 
  +1
  
  And yep, it should go to FESCo - this has much more bigger scope than 10.0.3
  due to LLVM update. You know I'm more than ok with updates to Fn-1 but this
  one should be coordinated very well.
 
 Can you (or anyone else) elaborate on the issues you're concerned with
 here?  If I'm going to have to play Simon Says about this I'd like some
 opportunity to address (or at least investigate) concerns ahead of time.

1) the removal of OpenGTL mid-stream breaking user or other apps
(and we can't truly remove it anyway - it stays in the F20 release repo)

This may be solvable by use of the patch mentioned elsewhere in this thread.

2) as the policy is to not update ABI on libraries, it requires an
exception. Concerns would be about the number of apps affected, coordinating
the release of all dependent apps, how likely user/other apps might be
broken by this ABI update.

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

Re: F21 Self Contained Change: Apache Mesos

[Bill Nottingham]

Jaroslav Reznik (jrez...@redhat.com) said: 
 - Original Message -
  Jaroslav Reznik (jrez...@redhat.com) said:
   = Proposed Self Contained Change: Apache Mesos =
   https://fedoraproject.org/wiki/Changes/ApacheMesos
   
   Change owner(s): Timothy St. Clair tstcl...@redhat.com
   
   Apache Mesos [1] is a cluster manager for sharing distributed application
   frameworks. This change brings Mesos to Fedora, which many have called a
   micro-kernel for the data center.
  
  Are we clustering Changes by products they may effect, or should be tied to
  in marketing? For example, this and Tachyon seem like natural marketing
  points for Fedora Cloud.
 
 And more are coming. But I added Product field (*) to the EmptyTemplate, it
 could be used to sort Changes to products and as heads up for marketing.
 Or another possibility is to create Wiki category. I can process both.
 We already touched it with Stephen on Server meeting.
 
 (*) it's optional.

Makes sense. Perhaps part of FESCo approval could be filling that field in
where necessary.

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

Re: Heads up: Mesa/LLVM rebase and OpenGTL retirement in F20

[Bill Nottingham]

Matthew Miller (mat...@fedoraproject.org) said: 
 On Fri, Mar 28, 2014 at 11:37:24AM -0400, Adam Jackson wrote:
  It might be nice if Fedora adopted the common practice (among other OSes
  with interface assurances) of at least attempting to define stability
  levels.  Whose action item would that be?
 
 Agreed, and, FESCo.

The fun part would be whether we start enforcing that *in* Fedora, or
whether we keep the current policy that anything in the Fedora repository is
an acceptable ABI to use for anything else in the Fedora repository.  (To be
clear, I don't think that scales in the long term.)

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

Re: F21 System Wide Change: PrivateDevices=yes and PrivateNetwork=yes For Long-Running Services

[Bill Nottingham]

Jaroslav Reznik (jrez...@redhat.com) said: 
 = Proposed System Wide Change: PrivateDevices=yes and PrivateNetwork=yes For 
 Long-Running Services =
 https://fedoraproject.org/wiki/Changes/PrivateDevicesAndPrivateNetwork
 
 Change owner(s): Lennart Poettering lennart at poettering dot net, Dan 
 Walsh, Kay Sievers
 
 Let's make Fedora more secure by default! Recent systemd versions provide two 
 per-service switches PrivateDevices=yes/no and PrivateNetwork=yes/no which 
 enable services to run without access to any physical devices in /dev, or 
 without access to kind of network sockets. So far this has seen little use in 
 Fedora, and with this Fedora Change we'd like to change this, and enable 
 these 
 for all long-running services that do not require device/network access. 

Can you define 'recent' here? While we wouldn't want to change the behavior
of existing F20 or earlier services, it would be worthwhile to know if
packages built for EPEL 7 could/should use this feature as well.

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

Re: F21 Self Contained Change: Apache Mesos

[Bill Nottingham]

Jaroslav Reznik (jrez...@redhat.com) said: 
 = Proposed Self Contained Change: Apache Mesos =
 https://fedoraproject.org/wiki/Changes/ApacheMesos
 
 Change owner(s): Timothy St. Clair tstcl...@redhat.com
 
 Apache Mesos [1] is a cluster manager for sharing distributed application 
 frameworks. This change brings Mesos to Fedora, which many have called a 
 micro-kernel for the data center. 

Are we clustering Changes by products they may effect, or should be tied to
in marketing? For example, this and Tachyon seem like natural marketing
points for Fedora Cloud.

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

Re: Maybe it's time to get rid of tcpwrappers/tcpd?

[Bill Nottingham]

Lennart Poettering (mzerq...@0pointer.de) said: 
 this through... I'd be happy though if somebody else would pick this
 up. Looking at the current FESCO members I am not entirely sure though
 whether a proposal to disable libwrap would have a chance in the current
 cycle though. (also, M. Miller kinda supported the proposal, which as
 history tells us means he probably is _not_ going to vote for it in the
 end...)
 
 It's a pity though that nobody in Fedora is actively working on getting
 rid of legacy cruft. I really wished we had some people who oversee
 deprecating things more proactively, figure out how to deprecate things,
 write stub code to provide smooth transitions, write release notes and
 so on.

Well, if you're going to passive-agressively shittalk anyone who tries to do
so in a way you disagree with (as you do above), I'm not sure why anyone
would willingly take you up on that offer. 

In any case, yes, concentrating on how to deprecate, providing smooth
transitions, release notes, etc. are all important things to think about
when discussing removing a feature, and framing the discussions in terms of
it's crap code, it doesn't really do what people are trying to use it for,
no one should use it accomplishes none of those items.

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

Re: F21 System Wide Change: Ruby on Rails 4.1

[Bill Nottingham]

Jaroslav Reznik (jrez...@redhat.com) said: 
 * Other developers: Update Rails dependent packages to be working with Ruby 
 on 
 Rails 4.1 

Looking at the repo, the only toplevel 'app' that this would appear to cover
would be OpenShift Origin, which is already called out on the feature page?

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

Re: F21 Self Contained Change: Security Policy In The Installer

[Bill Nottingham]

Vratislav Podzimek (vpodz...@redhat.com) said: 
 Thanks for your feedback, it definitely is constructive! I've recorded a
 video preview demostrating the feature's functionality. Hope that
 answers at least some of your and others' questions.
 
 https://vimeo.com/89243587

So, having watched the video, I think I'm pretty clearly against this from a
interactive install standpoint, given what is presented.

Here's what I see in that video. I'm not a UI/UX professional, so additional
review from someone more along those lines would be great (and info on where
I'm barking up the wrong tree - can always learn more.)

INTEGRATION
===

Current toplevel is localization, software, and system. 'Security policy'
doesn't fit as a toplevel along with that. If we wanted it as an additional
item under 'System', des that mean it can't be done as an addon?

INITIAL SCREEN
==

- You've got three active items:

  1 - 'Change content' (button)
  2 - 'Apply security policy' (toggle)
  3 - 'Select profile' (button)

If someone isn't familar with the specific terminology in use here, you're
using three separate nouns here which all can be similar in meaning (policy,
profile, content).  If the user isn't familiar with all three terms, all
three of these items could be seen as doing the same thing!  That's not
good.

If I were to whiteboard some proposed improvements of the screen you have
(note: not saying this is the way to go vs. a full rework), it would be
something like:


Apply a security policy [ YES | NO ] (1)



Policy 1 |  (if we want details on the selected
 description 1   |   policy, they go here on selection)
 |
Policy 2 |  
 description 2   |
...  |
-

[ Choose another policy source ... ] (2)

(1) If 'no' is selected, rest of screen is inactive
(2) If this is still desired

There would be no 'select profile' button - it would be selected by just
selecting the profile, similar to other anaconda actions.

URL SCREEN
==

- Why is 'Use SCAP Security Guide' (presumably a predefined URL) a selection,
  if it is not the normal source of the choices in the initial screen? If
  we're shipping with predefined content sources, it should be reflected on
  the initial screen; if we're not using that predefined data, I'm not sure
  why it's an option here.

- 'Enter data stream content or archive URL here'. Again, too jargon-y. 

  Is there a reason 'Enter URL to security policy' isn't good enough? (Or
  whatever terminology is used in the software spoke.)

PROFILE DETAILS
===

It's best when describing details (if we want to do so) that we don't use
different terminology or concepts than what is used in the rest of the
installer, if at all possible.

In your example, we have:
- 'logical volume'

This only shows up in custom partitioning, and even then not very
foregrounded (unless I'm missing something).

- 'mount options'

Not used anywhere.

- 'package', 'list of installed packages', 'list of excluded packages'

Packages are not exposed in the installer UI as user-interactable objects -
the only place they show up (outside of error messages) is as part of the
installation progress bar.

Above and beyond that:

- We should not be showing things as warnings. If the policy says a password
  must meet certain parameters, and we let the user later set it up in a way
  that violates that without additional warnings or automatic remediation,
  that's a bug.

- The error situation is even worse. It's really bad form to show them
  an error in spoke A *that they inherently have to know how to fix in spoke
  B*. Otherwise, you're giving them an easy way to break their system that
  they won't know how to get out of, with no indication of where they have
  to go to fix it.
  
  Selecting the error should take them to the screen where they can fix it,
  and it should be a 'normal' installer screen that they've seen and can get
  documentation on, not something 5 layers deep in a custom workflow that
  they wouldn't know how to get to again.

...

Given that, I think the interactive UI could use some significant rework
before we put it in Fedora's installation images by default.

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

Re: F21 Self Contained Change: Security Policy In The Installer

[Bill Nottingham]

Jan Lieskovsky (jlies...@redhat.com) said: 
  Is any Fedora 21 product targeted
  mainly for enterprise deployment?
 
 The vice versa view. Rather effort to use security configuration, 
 vulnerability and patch
 management also in Fedora product(s) (provide necessary tools to allow it). 
 The
 content itself will differ depending on the fact if it's used in 
 enterprise-level
 or academic / personal-level (enterprise-level companies required their 
 systems
 to meet the federal agencies standards for example etc.), but security 
 hardening guides / tips
 are applicable to Fedora OS instances too (IOW you don't need to be an 
 enterprise-level company
 to require / prefer system to be secured and have ways how to tune in various 
 aspects
 of system's security). So this proposal is to provide such tools.
 
  Is OpenSCAP being retargeted for general
  purpose level infrastructure.
 
 Not sure it was ever dedicated / restricted to be enterprise-level only. From 
 [3]:
 
 The Security Content Automation Protocol (SCAP), pronounced “ess-cap”, 
 combines
 a number of open standards that are used to enumerate software flaws and 
 configuration
 issues related to security ...  It is a method for using those open standards 
 for
 automated vulnerability management, measurement, and policy compliance 
 evaluation.
 
 There's nothing about it being exclusive just to enterprise-level 
 infrastructure
 (actually in contrast the open standards are highlighted couple of times 
 above). Of course
 writing the content requires time  resources. So it's more likely 
 enterprise-companies
 will have dedicated funds to support content creation of their needs. But the 
 standard
 itself (AFAICT) doesn't enforce / allows it to be used in enterprise-level 
 infrastructure only.
 
  If so, will (or should) at least a significant
  minority, say 33%, of GUI installer using end-users make use of this
  feature?
 
 The answer depends how many Fedora users care about security of their Fedora 
 systems and would
 be interested / willing to spend some time to harden it via the possibilities 
 provided
 by this proposal.

I'm looking at this from a different angle. Do we, out of the box in
anaconda, have a spoke for configuring SELinux policy specifics (or
downloading new policies)?  Do we, out of the box in anaconda, have a spoke
for setting the F21 crypto policy feature, or password encryption
algorithms, or the firewall?

I think a similar level works here - I see no issues with support of this in
anaconda that's exposed in kickstart, or post-install support for easily
applying a policy that an organization might have.

But for the interactive install case, I think we're probably better served by
just choosing secure defaults rather than having a specific screen in the
installer for every user.

Bill

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

Re: F21 Self Contained Change: Security Policy In The Installer

[Bill Nottingham]

Miloslav Trmač (m...@volny.cz) said: 
 There are two ways to avoid this limitation and get better security: either
 be a security expert or paranoid yourself (and in that case you don't need
 anaconda's handholding), or have an expert (that you trust or have to
 listen to) make an informed choice for you.

Sure. Leaving out the first case (IMO, those that can write their own SCAP
policy know how to apply it), let's look at the second.

By deferring to an expert, you're saying that the end user does not know
enough to make a coherent decision on the individual points.  This works in
a larger-scale enterprise use, because those users are expected to just
defer to the corporate policy where someone has decided what sort of machine
you have, and what the expected policy for that is.

Now take the general case of all interactive installs. If we accept that the
end user, in general, does not have the expertise to decide on the details
of the security policy, how does exposing it in the installer in this way
help?  You'd need a much more clearly defined description of the policies,
delination of them by use cases, and so on - speak to the user in terms that
they understand. Having it done by URLs (hey, are we checking the
ceritficate on that https server?), or by a low/medium/high distinction
doesn't appear to be the right paradigm.

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

Re: [Guidelines Change] Changes to the Packaging Guidelines

[Bill Nottingham]

Tom Callaway (tcall...@redhat.com) said: 
 As part of the ongoing effort to update the guidelines for an eventual
 change from python2 to python3 as the default python we're promoting use
 of %{python2}, %{python2_sitelib}, and %{python2_sitearch} instead of
 the unversioned %{python}, %{python_sitelib}, and %{python_sitearch}
 macros. These macros are not available for EPEL5 and EPEL6. We've
 updated the Python Guidelines to mention conditionally defining those
 macros for EPEL5 and EPEL6 builds.

Given that EPEL controls epel-release, and epel-release is in
@buildsys-build, does it make sense to put macros like this in epel-release
itself for build uniformity?

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

Re: Per-Product Config file divergence

[Bill Nottingham]

Toshio Kuratomi (a.bad...@gmail.com) said: 
 At last week's FESCo meeting, the fact that Products desired to have
 divergent configuration was briefly touched on.  On Thursday, a few FPC
 members had a brainstorming session about it and on Friday, sgallagh and
 that brainstorming continued with sgallagh, adamw, tflink, notting, and
 myself.  We came up with a tentative idea here:

Well, I read a couple hours of backscroll and made two comments; I don't
really think that qualifies me as a co-author. That being said...

 https://fedoraproject.org/wiki/User:Toshio/Product_Divergence_(config)
 
 The idea is to allow config file divergence via the alternatives system as
 that already provides us with a commandline tool and some structure to build
 on.  We'd still have to write a few pieces to complete the picture but it
 seemed to be a better starting point than using rpm Conflicts between
 config-packages.

... I'm not really convinced that alternatives is the way to go here. For
one, it's implemented as symlink farms; depending on how tools modify
configuration, that can cause problematic/unpredictable drift.

Stepping back, if you allow this, in general, you get the following
potential bifurcation for any one product:

a) the default config when in Server
b) the default config when in Cloud
c) the default config when in Workstation
d) the default config when in spin XYZ
...
z) the default config when in none of the above

etc.

I'm struggling to think of a viable case where we want users to be able to
pick any of the above for a package running on any other of the above. It
would seem simplest to me that for any package, you either get the config
for your particular product that you have installed, or you get z) if it
doesn't have one for your product. Among other things, this simplifies the
test matrix.

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

Summary/Minutes from today's FESCo Meeting (2014-03-05)

[Bill Nottingham]

===
#fedora-meeting: FESCO (2014-03-05)
===


Meeting started by sgallagh at 17:59:49 UTC. The full logs are available
at
http://meetbot.fedoraproject.org/fedora-meeting/2014-03-05/fesco.2014-03-05-17.59.log.html
.


Meeting summary
---
* init process  (sgallagh, 18:00:06)
  * mitr pjones nirik abadger1999 dgilmore sgallagh mattdm t8m present.
notting coming shortly  (sgallagh, 18:04:12)

* #1178 Fedora 21 scheduling strategy  (sgallagh, 18:04:31)
  * ACTION: jreznik to work up and provide a schedule proposal for Oct
14 target date for next week.  (sgallagh, 18:26:43)

* #1221 Product working group activity reports  (sgallagh,
  18:27:06)
  * The general consensus here seems to be: Everyone was working on
Tech Specs  (mattdm, 18:27:47)
  * https://fedoraproject.org/wiki/Workstation/Technical_Specification
(mattdm, 18:29:52)
  * https://fedoraproject.org/wiki/Cloud_Changelist  (mattdm, 18:29:58)
  * https://fedoraproject.org/wiki/Server/Technical_Specification
(mattdm, 18:30:19)
  * we're all pretty happy with the way the wg discussion about
filesystems went, providing a good example of how broader issues
should be dealt with in the fedora.nex structure  (mattdm, 18:37:58)

* #1230Requesting FESCo address Cherokee logo issue  (notting,
  18:48:47)
  * LINK: https://fedorahosted.org/fesco/ticket/1230   (notting,
18:48:47)
  * AGREED: FESCo decision reiterated. Package will be retired Monday if
not fixed. (+:7,-:0,0:0)  (notting, 18:54:42)

* #1219Contributor nationality  (notting, 18:57:23)
  * LINK: https://fedorahosted.org/fesco/ticket/1219   (notting,
18:57:24)
  * current countries that are export restricted are: cuba, iran, north
korea, sudan, and syria.  (pjones, 18:59:37)
  * Sponsors (or any other contributors) in Fedora should not make any
effort to determine a contributor's nationality, country of origin,
or area of residence.  (notting, 19:00:00)
  * If a potential contributor independently (and explicitly) reveals
their nationality, country of origin, or area of residence, and that
nationality, country of origin, or area of residence is in one of
the export restricted countries, then they are required to bring
that information to the attention of Fedora Legal  (notting,
19:00:25)
  * In the specific case that prompted this ticket, Fedora Legal has
deemed the contributor is OK.  (notting, 19:00:50)

* #1240taking ownership of packages fityk and sundials  (notting,
  19:02:34)
  * LINK: https://fedorahosted.org/fesco/ticket/1240   (notting,
19:02:34)
  * AGREED: nirk will request a direct ack from nonresponsive maintainer
via e-mail, and then proceed with reassigning (+:9, -:0, 0:0)
(notting, 19:06:01)

* #1241Cloud WG list of changes  (notting, 19:06:37)
  * LINK: https://fedorahsted.org/fesco/ticket/1241   (notting,
19:06:37)
  * Please discuss changes here on list for now; will be discussed more
in the FESCo meeting when they go through the change process.
(notting, 19:11:51)
  * People are specifically encouraged to read the 'External Changes'
section and discuss those with the Cloud SIG  (notting, 19:12:11)

* #1242Update policy proposal: disable autokarma on AutoQA fail
  (notting, 19:13:24)
  * LINK: https://fedorahosted.org/fesco/ticket/1242   (notting,
19:13:29)
  * AGREED: Proposal in ticket to disable autokarma if AutoQA fails
accepted (+:9,-:0,0:0)  (notting, 19:20:22)

* 1243 Consider release blocking status of KDE spin(?) for Fedora 21
  in .next decision-making  (notting, 19:21:57)
  * LINK: https://fedorahosted.org/fesco/ticket/1243   (notting,
19:21:57)
  * AGREED: defer this one week waiting for more feedback from both KDE
SIG and Workstation WG (+:7,-:0,0:0)  (notting, 19:25:45)

* Next week's chair  (notting, 19:28:20)
  * mattdm to chair next week's meeting  (notting, 19:29:15)

* Open Floor  (notting, 19:29:21)

Meeting ended at 19:36:07 UTC.


Action Items

* jreznik to work up and provide a schedule proposal for Oct 14 target
  date for next week.




Action Items, by person
---
* jreznik
  * jreznik to work up and provide a schedule proposal for Oct 14 target
date for next week.

People Present (lines said)
---
* sgallagh (93)
* notting (78)
* dgilmore (57)
* mattdm (56)
* nirik (40)
* mitr (34)
* abadger1999 (33)
* t8m (33)
* pjones (33)
* drago01 (22)
* zodbot (18)
* jwb (18)
* adamw (16)
* jreznik (16)
* EvilBob (2)
* tflink (1)
* masta (1)
* mmaslano (0)

Generated by `MeetBot`_ 0.1.4

.. _`MeetBot`: http://wiki.debian.org/MeetBot
17:59:49 sgallagh #startmeeting FESCO (2014-03-05)
17:59:49 zodbot Meeting started Wed Mar  5 17:59:49 2014 UTC.  The chair is 
sgallagh. Information about MeetBot at http://wiki.debian.org/MeetBot.
17:59:49 zodbot Useful Commands: #action #agreed 

Re: hierarchical comps groups proposal

[Bill Nottingham]

Jens Petersen (peter...@redhat.com) said: 
  (I'm not going to contribute actual work on this anyway, but) do we actually
  need that complexity?
 
 I am not sure how complex it is. As Ales pointed out
 it might allow us to remove environment groups for example
 so it might actually simplify comps, as well as eliminating some repetitions.
 Note that more modular comps would also be helpful for people
 writing kickstart files for example.
 
   The idea is make yum groups in comps more modular,
   ie groups could require other groups not just packages;
   at this time I don't think it would require any GUI changes.
 
  So the proposal is not to show them as really hierarchical, and not to add
  any structurally new user-visible features[1] just to avoid repetition in
  the comps file?
 
 To me current comps is quite messy because everything has to be flat
 which limits its flexibility in various ways.
 But right, *initially* I reckon hierarchical groups need not *require*
 any GUI changes to anaconda, etc.  In the first instance it would be
 about providing greater structure and more fine-grained groups in comps.
 Later these could also be used for more advanced selection of groups
 in the installer and package GUI.

My concern would be how deeply woven the current format is into our tools -
it's yum, PK, DNF, anaconda, and all the tools built on top of it. It's
exposed in kickstart. It's expected to be handled by older versions on
upgrade, or even by mock when constructing arbitrary build roots.

So care would need to be taken to figure out a good way to land this all at
once, in a way that's backwards compatible enough to not break other things.

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

Schedule for Wednesday's FESCo Meeting (2014-03-05)

[Bill Nottingham]

Following is the list of topics that will be discussed in the FESCo
meeting Wednesday at 18:00UTC in #fedora-meeting on irc.freenode.net.

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

or run:
  date -d '2014-03-05 18:00 UTC'

Links to all tickets below can be found at: 
https://fedorahosted.org/fesco/report/9

= Followups =

#topic #1178Fedora 21 scheduling strategy
.fesco 1178
https://fedorahosted.org/fesco/ticket/1178

#topic #1221Product working group activity reports
.fesco 1221
https://fedorahosted.org/fesco/ticket/1221

#topic #1230Requesting FESCo address Cherokee logo issue
.fesco 1230
https://fedorahosted.org/fesco/ticket/1230

= New business =

#topic #1219Contributor nationality
.fesco 1219
https://fedorahosted.org/fesco/ticket/1219

#topic #1240taking ownership of packages fityk and sundials
.fesco 1240
https://fedorahosted.org/fesco/ticket/1240

#topic #1241Cloud WG list of changes
.fesco 1241
https://fedorahsted.org/fesco/ticket/1241

#topic #1242Update policy proposal: disable autokarma on AutoQA fail
.fesco 1242
https://fedorahosted.org/fesco/ticket/1242

#topic 1243 Consider release blocking status of KDE spin(?) for Fedora 21 
in .next decision-making
.fesco 1243
https://fedorahosted.org/fesco/ticket/1243

= Open Floor = 

For more complete details, please visit each individual ticket.  The
report of the agenda items can be found at
https://fedorahosted.org/fesco/report/9

If you would like to add something to this agenda, you can reply to
this e-mail, file a new ticket at https://fedorahosted.org/fesco,
e-mail me directly, or bring it up at the end of the meeting, during
the open floor topic. Note that added topics may be deferred until
the following meeting. 
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: F21 System Wide Change: System-wide crypto policy

[Bill Nottingham]

Nikos Mavrogiannopoulos (n...@redhat.com) said: 
 On Thu, 2014-02-27 at 11:52 -0500, Bill Nottingham wrote:
   == Detailed Description ==
   The idea is to have some predefined security levels such as LEVEL-80, 
   LEVEL-128, LEVEL-256,
   or ENISA-LEGACY, ENISA-FUTURE, SUITEB-128, SUITEB-256. These will be the 
   security levels 
   that the administrator of the system will be able to configure by 
   modifying
   /usr/lib/crypto-profiles/config
   /etc/crypto-profiles/config
   and being applied after executing update-crypto-profiles.
   (Note: it would be better to have a daemon that watches those files and
   runs update-crypto-profiles automatically)
  How is an admin supposed to know what levels such as the above are, and why
  they might choose a particular one?
 
 They will be documented. They could be part of the configuration file
 that be edited. The policies above are a indicative, so if there are
 suggestions they will be considered.

Well, even if they're documented, I don't know if they're particularly
meaningful items.  For example although I 'know' what SUITEB might refer to,
it still amounts to 'a set of algorithms the NSA deems sufficient'; it does
not give me any meaningful knowledge to compare it to other settings.  And
for all I know I'm aobve the curve on understanding what some of these are;
your typical administrator is likely to know even less. If they're merely
described in terms of what they represent - is it going to make the choice
clearer, or not?

i.e., how do ensure that the configuration choices are meaningful and
explicable to the administrators such they can make an informed decision
outside of I checked the SUITEB-256 box because that's what the standard
243213 chapter 33 subsection 24 sentence 1 says.

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

Re: default file system, was: Comparison to Workstation Technical Specification

[Bill Nottingham]

Josh Boyer (jwbo...@fedoraproject.org) said: 
  Basically, what I'm saying is that if Desktop would be OK with using
  xfs-on-LVM as default with all choices demoted to custom partitioning
  (no dropdown), as Server has currently agreed on, that'd be great. Or if
  we could otherwise achieve agreement on something.
 
 I'll bring it up.  I believe the momentum on using ext4-on-LVM is that
 it's the existing default, it's a known quantity, and we have the most
 experience with it as a project.

So, we're combining momentum on using the existing default for a Fedora
deliverable and the existing default for a RHEL deliverable to get two
different defaults?

(I'd note that RHEL Workstation, at least in the beta, defaults to XFS as
well, although I think that's merely inheriting from the Server cases.)

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

Re: F21 System Wide Change: System-wide crypto policy

[Bill Nottingham]

Jaroslav Reznik (jrez...@redhat.com) said: 
 = Proposed System Wide Change: System-wide crypto policy =
 https://fedoraproject.org/wiki/Changes/CryptoPolicy
 
 Change owner(s): Nikos Mavrogiannopoulos n...@redhat.com
 
 Unify the crypto policies used by different applications and libraries. That 
 is 
 allow setting a consistent security level for crypto on all applications in a 
 Fedora system. 
 
 == Detailed Description ==
 The idea is to have some predefined security levels such as LEVEL-80, 
 LEVEL-128, LEVEL-256,
 or ENISA-LEGACY, ENISA-FUTURE, SUITEB-128, SUITEB-256. These will be the 
 security levels 
 that the administrator of the system will be able to configure by modifying
 /usr/lib/crypto-profiles/config
 /etc/crypto-profiles/config
 
 and being applied after executing update-crypto-profiles.
 (Note: it would be better to have a daemon that watches those files and
 runs update-crypto-profiles automatically)

How is an admin supposed to know what levels such as the above are, and why
they might choose a particular one?

 * Proposal owners: For GnuTLS and OpenSSL the SYSTEM cipher needs to be 
 understood and behave as described. For NSS the NSS_SetDomesticPolicy() can 
 be 
 overloaded to behave as above.
 
 After that a mechanism to specify crypto policies for Fedora has to be 
 devised, as well as the extraction to each libraries' settings.
 
 * Other developers: Packages that use SSL crypto libraries should, after the 
 previous change is complete, start replacing the default cipher strings with 
 SYSTEM.

This implies a potentially not insignificant local patch load. Am I
misunderstanding it?

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

Re: default file system, was: Comparison to Workstation Technical Specification

[Bill Nottingham]

Stephen Gallagher (sgall...@redhat.com) said: 
 Directed more broadly at all three products:
 
 Formal proposal (for discussion): All three products agree to use ext4
 for /boot and XFS-on-LVM for all other partitions in the guided
 mode. All is fair game in the custom mode.
 
 Also, for the sake of everyone's sanity, as we discuss this specific
 proposal, let's hold the conversation to devel@lists.fedoraproject.org
 (making this the last cross-posted message in the thread).

... I understand that synergy can help, but given we likely expect usage
of all(*) the local fileystems, is there a reason the three produces need to
share partitioning setup?

(*) well, not reiserfs

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

[perl-Finance-Quote/el6] Fix requires (#1069717)

[Bill Nottingham]

commit 4864a45a72317122a3467aace3d1b4e5f7e3aae7
Author: Bill Nottingham nott...@redhat.com
Date:   Tue Feb 25 10:11:35 2014 -0500

Fix requires (#1069717)

 FQ-requires.patch   |   25 +
 perl-Finance-Quote.spec |7 ++-
 2 files changed, 31 insertions(+), 1 deletions(-)
---
diff --git a/FQ-requires.patch b/FQ-requires.patch
new file mode 100644
index 000..2bdd4d0
--- /dev/null
+++ b/FQ-requires.patch
@@ -0,0 +1,25 @@
+diff -up Finance-Quote-1.20/lib/Finance/Quote/Tiaacref.pm.foo 
Finance-Quote-1.20/lib/Finance/Quote/Tiaacref.pm
+--- Finance-Quote-1.20/lib/Finance/Quote/Tiaacref.pm.foo   2014-02-25 
10:02:24.197647363 -0500
 Finance-Quote-1.20/lib/Finance/Quote/Tiaacref.pm   2014-02-25 
10:02:51.556884032 -0500
+@@ -28,8 +28,7 @@
+ 
+ package Finance::Quote::Tiaacref;
+ require 5.005;
+-require Crypt::SSLeay;
+-require Mozilla::CA;
++require LWP::Protocol::https;
+ 
+ use strict;
+ 
+diff -up Finance-Quote-1.20/META.yml.foo Finance-Quote-1.20/META.yml
+--- Finance-Quote-1.20/META.yml.foo2014-02-17 08:08:23.0 -0500
 Finance-Quote-1.20/META.yml2014-02-25 10:02:59.938956528 -0500
+@@ -30,7 +30,7 @@ requires:
+   HTTP::Request::Common: 0
+   JSON: 0
+   LWP::UserAgent: 0
+-  Mozilla::CA: 0
++  LWP::Protocol::https: 0
+   POSIX: 0
+   URI::Escape: 0
+   perl: 5.005
diff --git a/perl-Finance-Quote.spec b/perl-Finance-Quote.spec
index b27a366..59baee6 100644
--- a/perl-Finance-Quote.spec
+++ b/perl-Finance-Quote.spec
@@ -1,11 +1,12 @@
 Name:  perl-Finance-Quote
 Version:1.20
-Release:   2%{?dist}
+Release:   3%{?dist}
 Summary:A Perl module that retrieves stock and mutual fund quotes
 Group:  Development/Libraries
 License:GPLv2+
 URL:   http://finance-quote.sourceforge.net/
 Source0:   
http://prdownloads.sourceforge.net/finance-quote/Finance-Quote-%{version}.tar.gz
+Patch1:FQ-requires.patch
 BuildRoot:  %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
 BuildArch:  noarch
 Requires:  perl(:MODULE_COMPAT_%(eval `%{__perl} -V:version`; echo 
$version))
@@ -43,6 +44,7 @@ using various source.
 
 %prep
 %setup -q -n Finance-Quote-%{version} 
+%patch1 -p1
 find . -name *.pm | xargs %{__sed} -i -e '/^#!.*\/usr\/bin\/perl/d'
 
 %build
@@ -69,6 +71,9 @@ rm -rf $RPM_BUILD_ROOT
 %{_mandir}/man3/*.3*
 
 %changelog
+* Tue Feb 25 2014 Bill Nottingham nott...@redhat.com - 1.20-3
+- tweak requires (#1069717)
+
 * Tue Feb 18 2014 Bill Nottingham nott...@redhat.com - 1.20-2
 - add missing https requires (#859607)
 
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel

Re: Schedule for Wednesday's (today's) FESCo Meeting (2014-02-19)

[Bill Nottingham]

Tomas Mraz (tm...@redhat.com) said: 
 Following is the list of topics that will be discussed in the FESCo
 meeting Wednesday at 18:00UTC in #fedora-meeting on irc.freenode.net.
 
 To convert UTC to your local time, take a look at
   http://fedoraproject.org/wiki/UTCHowto
 
 or run:
   date -d '-MM-DD HH:MM UTC'
 
 Links to all tickets below can be found at: 
 https://fedorahosted.org/fesco/report/9

I may be unable to make the meeting on time due to some transportation
snafus. I've commented in tickets where practical.

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

[perl-Finance-Quote] Add missing requires that causes some quotes to fail. (#859607)

[Bill Nottingham]

commit aebdbe8bd39afc0cb8b67bc821ea87fd91198721
Author: Bill Nottingham nott...@redhat.com
Date:   Tue Feb 18 15:10:49 2014 -0500

Add missing requires that causes some quotes to fail. (#859607)

 perl-Finance-Quote.spec |   11 ---
 1 files changed, 8 insertions(+), 3 deletions(-)
---
diff --git a/perl-Finance-Quote.spec b/perl-Finance-Quote.spec
index 3c6bb1f..eab4dfa 100644
--- a/perl-Finance-Quote.spec
+++ b/perl-Finance-Quote.spec
@@ -1,6 +1,6 @@
 Name:  perl-Finance-Quote
 Version:1.20
-Release:   1%{?dist}
+Release:   2%{?dist}
 Summary:A Perl module that retrieves stock and mutual fund quotes
 Group:  Development/Libraries
 License:GPLv2+
@@ -9,8 +9,9 @@ Source0:
http://prdownloads.sourceforge.net/finance-quote/Finance-Quote-%{versio
 BuildRoot:  %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
 BuildArch:  noarch
 Requires:  perl(:MODULE_COMPAT_%(eval `%{__perl} -V:version`; echo 
$version))
+# because it doesn't get automatically added (#859607)
+Requires:   perl(LWP::Protocol::https)
 BuildRequires:  perl(inc::Module::Install)
-# Run-time
 BuildRequires:  perl(base)
 BuildRequires:  perl(Carp)
 BuildRequires:  perl(CGI)
@@ -23,11 +24,13 @@ BuildRequires:  perl(HTML::Parser)
 BuildRequires: perl(HTML::TableExtract)
 BuildRequires:  perl(HTML::TreeBuilder)
 BuildRequires:  perl(HTTP::Headers)
+BuildRequires:  perl(LWP::Protocol::https)
 BuildRequires:  perl(HTTP::Request::Common)
 BuildRequires:  perl(HTTP::Status)
 BuildRequires:  perl(JSON)
 BuildRequires:  perl(LWP::Simple)
 BuildRequires: perl(LWP::UserAgent)
+BuildRequires:  perl(Mozilla::CA)
 BuildRequires:  perl(URI)
 BuildRequires:  perl(URI::QueryParam)
 # Tests
@@ -60,7 +63,6 @@ make test
 %clean
 rm -rf $RPM_BUILD_ROOT
 
-
 %files
 %defattr(-,root,root,-)
 %doc ChangeLog* Documentation/*
@@ -68,6 +70,9 @@ rm -rf $RPM_BUILD_ROOT
 %{_mandir}/man3/*.3*
 
 %changelog
+* Tue Feb 18 2014 Bill Nottingham nott...@redhat.com - 1.20-2
+- add missing https requires (#859607)
+
 * Mon Feb 17 2014 Bill Nottingham nott...@redhat.com - 1.20-1
 - update to 1.20
 
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel

[perl-Finance-Quote] Remove old patch

[Bill Nottingham]

commit d8d19c8d8e5147171cc3cc5b47540f85ad2d5e3e
Author: Bill Nottingham nott...@redhat.com
Date:   Tue Feb 18 15:11:18 2014 -0500

Remove old patch

 tiaa-cref.patch |  520 ---
 1 files changed, 0 insertions(+), 520 deletions(-)
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel

[perl-Finance-Quote/epel7] (2 commits) ...Remove old patch

[Bill Nottingham]

Summary of changes:

  aebdbe8... Add missing requires that causes some quotes to fail. (#859 (*)
  d8d19c8... Remove old patch (*)

(*) This commit already existed in another branch; no separate mail sent
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel

[perl-Finance-Quote/el6] (3 commits) ...Merge branch 'master' into el6

[Bill Nottingham]

Summary of changes:

  aebdbe8... Add missing requires that causes some quotes to fail. (#859 (*)
  d8d19c8... Remove old patch (*)
  87b1f78... Merge branch 'master' into el6

(*) This commit already existed in another branch; no separate mail sent
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel

[perl-Finance-Quote/el6: 3/3] Merge branch 'master' into el6

[Bill Nottingham]

commit 87b1f785ddf95a60d7de13937d001e7acfc28d1e
Merge: bfccbc0 d8d19c8
Author: Bill Nottingham nott...@redhat.com
Date:   Tue Feb 18 15:13:42 2014 -0500

Merge branch 'master' into el6

 perl-Finance-Quote.spec |   11 +-
 tiaa-cref.patch |  520 ---
 2 files changed, 8 insertions(+), 523 deletions(-)
---
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel

[perl-Finance-Quote/f19] (2 commits) ...Remove old patch

[Bill Nottingham]

Summary of changes:

  aebdbe8... Add missing requires that causes some quotes to fail. (#859 (*)
  d8d19c8... Remove old patch (*)

(*) This commit already existed in another branch; no separate mail sent
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel

[perl-Finance-Quote/f20] (2 commits) ...Remove old patch

[Bill Nottingham]

Summary of changes:

  aebdbe8... Add missing requires that causes some quotes to fail. (#859 (*)
  d8d19c8... Remove old patch (*)

(*) This commit already existed in another branch; no separate mail sent
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel

[perl-Finance-Quote/el6] no perl-Mozilla-CA on el6

[Bill Nottingham]

commit d0f31458e701cd36d3248955935d1ce77323c4c6
Author: Bill Nottingham nott...@redhat.com
Date:   Tue Feb 18 15:28:17 2014 -0500

no perl-Mozilla-CA on el6

 perl-Finance-Quote.spec |1 -
 1 files changed, 0 insertions(+), 1 deletions(-)
---
diff --git a/perl-Finance-Quote.spec b/perl-Finance-Quote.spec
index eab4dfa..b27a366 100644
--- a/perl-Finance-Quote.spec
+++ b/perl-Finance-Quote.spec
@@ -30,7 +30,6 @@ BuildRequires:  perl(HTTP::Status)
 BuildRequires:  perl(JSON)
 BuildRequires:  perl(LWP::Simple)
 BuildRequires: perl(LWP::UserAgent)
-BuildRequires:  perl(Mozilla::CA)
 BuildRequires:  perl(URI)
 BuildRequires:  perl(URI::QueryParam)
 # Tests
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel