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

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

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

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

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

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

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

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

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

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

rpms/perl-HTML-TableExtract/EL-6 perl-HTML-TableExtract.spec, 1.9, 1.10

[Bill Nottingham]

Author: notting

Update of /cvs/extras/rpms/perl-HTML-TableExtract/EL-6
In directory cvs01.phx2.fedoraproject.org:/tmp/cvs-serv6474

Modified Files:
perl-HTML-TableExtract.spec 
Log Message:
nuke rhel macro, not needed



Index: perl-HTML-TableExtract.spec
===
RCS file: 
/cvs/extras/rpms/perl-HTML-TableExtract/EL-6/perl-HTML-TableExtract.spec,v
retrieving revision 1.9
retrieving revision 1.10
diff -u -p -r1.9 -r1.10
--- perl-HTML-TableExtract.spec 26 Jul 2009 06:29:39 -  1.9
+++ perl-HTML-TableExtract.spec 8 Jul 2010 20:24:33 -   1.10
@@ -1,6 +1,6 @@
 Name:   perl-HTML-TableExtract
 Version:2.10
-Release:   5%{?dist}
+Release:   7%{?dist}
 Summary:A Perl module for extracting content in HTML tables
 Group:  Development/Libraries
 License:GPL+ or Artistic
@@ -9,11 +9,7 @@ Source0:http://search.cpan.org/C
 BuildRoot:  %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
 BuildArch:  noarch
 Requires:  perl(:MODULE_COMPAT_%(eval `%{__perl} -V:version`; echo 
$version))
-%if 0%{?rhel}
-BuildRequires:  perl(HTML::Parser)
-%else
 BuildRequires: perl(HTML::TreeBuilder) perl(Test::Pod) 
perl(Test::Pod::Coverage)
-%endif
 
 %description
 HTML::TableExtract is a module that simplifies the extraction of
@@ -52,6 +48,12 @@ rm -rf $RPM_BUILD_ROOT
 
 
 %changelog
+* Sun May 02 2010 Marcela Maslanova mmasl...@redhat.com - 2.10-7
+- Mass rebuild with perl-5.12.0
+
+* Mon Dec  7 2009 Stepan Kasal ska...@redhat.com - 2.10-6
+- rebuild against perl 5.10.1
+
 * Sat Jul 25 2009 Fedora Release Engineering rel-...@lists.fedoraproject.org 
- 2.10-5
 - Rebuilt for https://fedoraproject.org/wiki/Fedora_12_Mass_Rebuild
 

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

rpms/perl-HTML-TableExtract/devel perl-HTML-TableExtract.spec, 1.11, 1.12

[Bill Nottingham]

Author: notting

Update of /cvs/extras/rpms/perl-HTML-TableExtract/devel
In directory cvs01.phx2.fedoraproject.org:/tmp/cvs-serv6741

Modified Files:
perl-HTML-TableExtract.spec 
Log Message:
perl requires are OK in newer RHEL.



Index: perl-HTML-TableExtract.spec
===
RCS file: 
/cvs/extras/rpms/perl-HTML-TableExtract/devel/perl-HTML-TableExtract.spec,v
retrieving revision 1.11
retrieving revision 1.12
diff -u -p -r1.11 -r1.12
--- perl-HTML-TableExtract.spec 2 May 2010 14:19:00 -   1.11
+++ perl-HTML-TableExtract.spec 8 Jul 2010 20:25:07 -   1.12
@@ -9,11 +9,7 @@ Source0:http://search.cpan.org/C
 BuildRoot:  %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
 BuildArch:  noarch
 Requires:  perl(:MODULE_COMPAT_%(eval `%{__perl} -V:version`; echo 
$version))
-%if 0%{?rhel}
-BuildRequires:  perl(HTML::Parser)
-%else
 BuildRequires: perl(HTML::TreeBuilder) perl(Test::Pod) 
perl(Test::Pod::Coverage)
-%endif
 
 %description
 HTML::TableExtract is a module that simplifies the extraction of

--
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] - fix TIAA-CREF (#668935, amess...@messinet.com)

[Bill Nottingham]

commit 33ec38d4fec4e9032c08f0ee05e0ca746ac1b83b
Author: Bill Nottingham nott...@redhat.com
Date:   Wed Jan 12 12:29:39 2011 -0500

- fix TIAA-CREF (#668935, amess...@messinet.com)

 perl-Finance-Quote.spec |7 +-
 tiaa-cref.patch |  520 +++
 2 files changed, 526 insertions(+), 1 deletions(-)
---
diff --git a/perl-Finance-Quote.spec b/perl-Finance-Quote.spec
index 259c7a9..f5e1615 100644
--- a/perl-Finance-Quote.spec
+++ b/perl-Finance-Quote.spec
@@ -1,11 +1,12 @@
 Name:  perl-Finance-Quote
 Version:1.17
-Release:   4%{?dist}
+Release:   5%{?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
+Patch0:tiaa-cref.patch
 BuildRoot:  %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
 BuildArch:  noarch
 Requires:  perl(:MODULE_COMPAT_%(eval `%{__perl} -V:version`; echo 
$version))
@@ -22,6 +23,7 @@ using various source.
 
 %prep
 %setup -q -n Finance-Quote-%{version} 
+%patch0 -p2
 find . -name *.pm | xargs %{__sed} -i -e '/^#!.*\/usr\/bin\/perl/d'
 
 %build
@@ -49,6 +51,9 @@ rm -rf $RPM_BUILD_ROOT
 %{_mandir}/man3/*.3*
 
 %changelog
+* Wed Jan 12 2011 Bill Nottingham nott...@redhat.com - 1.17-5
+- fix TIAA-CREF (#668935, amess...@messinet.com)
+
 * Mon Dec 06 2010 Bill Nottingham nott...@redhat.com - 1.17-4
 - fix buildrequires for F-15
 
diff --git a/tiaa-cref.patch b/tiaa-cref.patch
new file mode 100644
index 000..387ef16
--- /dev/null
+++ b/tiaa-cref.patch
@@ -0,0 +1,520 @@
+diff --git a/Finance-Quote-1.17/lib/Finance/Quote/Tiaacref.pm 
b/Finance-Quote-1.17/lib/Finance/Quote/Tiaacref.pm
+index 5e1c8a1..5650ef7 100644
+--- a/Finance-Quote-1.17/lib/Finance/Quote/Tiaacref.pm
 b/Finance-Quote-1.17/lib/Finance/Quote/Tiaacref.pm
+@@ -33,7 +33,7 @@ require Crypt::SSLeay;
+ 
+ use strict;
+ 
+-use vars qw($VERSION $CREF_URL $TIAA_URL
++use vars qw($VERSION $CREF_URL $CREF_URL_INST $TIAA_URL
+ %tiaacref_ids %tiaacref_locs %tiaacref_vals);
+ 
+ use LWP::UserAgent;
+@@ -44,7 +44,9 @@ $VERSION = '1.17';
+ 
+ # URLs of where to obtain information.
+ # This used to be different for the CREF and TIAA annuities, but this changed.
+-$CREF_URL = (https://www3.tiaa-cref.org/ddata/DownloadData?;);
++$CREF_URL = 
(http://www.tiaa-cref.org/public/performance/retirement/data/results?;);
++$CREF_URL_INST = 
(http://www.tiaa-cref.org/public/performance/institutional/data/results?;);
++#https://www3.tiaa-cref.org/ddata/DownloadData?;);
+ 
+ sub methods { return (tiaacref=\tiaacref); }
+ 
+@@ -96,6 +98,82 @@ sub labels { return (tiaacref = [qw/method symbol exchange 
name date isodate na
+ # TIAA-CREF Social Choice Equity: TCSCX
+ # TIAA-CREF Managed Allocation:   TIMAX
+ 
++# TIAA-CREF Retirement Fund - Bond:TIDRX
++# TIAA-CREF Retirement Fund - Bond Index:  TBIRX
++# TIAA-CREF Retirement Fund - Bond Plus:   TCBRX
++# TIAA-CREF Retirement Fund - Emerging Markets Equity: TEMSX
++# TIAA-CREF Retirement Fund - Emerging Markets Equity Index: TEQSX
++# TIAA-CREF Retirement Fund - Equity Index:TIQRX
++# TIAA-CREF Retirement Fund - Growth  Income: TRGIX
++# TIAA-CREF Retirement Fund - High-Yield:  TIHRX
++# TIAA-CREF Retirement Fund - Inflation-Linked Bond:   TIKRX
++# TIAA-CREF Retirement Fund - International Equity:TRERX
++# TIAA-CREF Retirement Fund - International Equity Index: TRIEX
++# TIAA-CREF Retirement Fund - Large-Cap Growth:TILRX
++# TIAA-CREF Retirement Fund - Large-Cap Growth Index:  TRIRX
++# TIAA-CREF Retirement Fund - Large-Cap Value: TRLCX
++# TIAA-CREF Retirement Fund - Large-Cap Value Index:   TRCVX
++# TIAA-CREF Retirement Fund - Lifecycle 2010:  TCLEX
++# TIAA-CREF Retirement Fund - Lifecycle 2015:  TCLIX
++# TIAA-CREF Retirement Fund - Lifecycle 2020:  TCLTX
++# TIAA-CREF Retirement Fund - Lifecycle 2025:  TCLFX
++# TIAA-CREF Retirement Fund - Lifecycle 2030:  TCLNX
++# TIAA-CREF Retirement Fund - Lifecycle 2035:  TCLRX
++# TIAA-CREF Retirement Fund - Lifecycle 2040:  TCLOX
++# TIAA-CREF Retirement Fund - Lifecycle 2045:  TTFRX
++# TIAA-CREF Retirement Fund - Lifecycle 2050:  TLFRX
++# TIAA-CREF Retirement Fund - Lifecycle Retirement Income: TLIRX
++# TIAA-CREF Retirement Fund - Managed Allocation:  TITRX
++# TIAA-CREF Retirement Fund - Mid-Cap Growth:  TRGMX
++# TIAA-CREF Retirement Fund - Mid-Cap Value:   TRVRX
++# TIAA-CREF Retirement Fund - Money Market:TIEXX
++# TIAA-CREF Retirement Fund - Real Estate Securities

[perl-Finance-Quote/f14/master] (2 commits) ...- fix TIAA-CREF (#668935, amess...@messinet.com)

[Bill Nottingham]

Summary of changes:

  34e0fd7... fix rawhide build. (*)
  33ec38d... - fix TIAA-CREF (#668935, amess...@messinet.com) (*)

(*) 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-HTML-Tree/el6] Retire - actually in RHEL

[Bill Nottingham]

commit 8e17d38aa241ed3d59e0171c4107126bc20da113
Author: Bill Nottingham nott...@redhat.com
Date:   Tue Jan 21 20:43:00 2014 -0500

Retire - actually in RHEL

 dead.package|1 +
 perl-HTML-Tree.spec |  189 ---
 sources |1 -
 3 files changed, 1 insertions(+), 190 deletions(-)
---
diff --git a/dead.package b/dead.package
new file mode 100644
index 000..5028d24
--- /dev/null
+++ b/dead.package
@@ -0,0 +1 @@
+This package was retired because notting asked for it to be branched without 
checking the optional repo.
--
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-HTML-Tree/epel7] Retire - actually in RHEL

[Bill Nottingham]

Summary of changes:

  8e17d38... Retire - actually in RHEL (*)

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

Re: [perl-HTML-Tree/epel7] Retire - actually in RHEL

[Bill Nottingham]

Paul Howarth (p...@city-fan.org) said: 
 On 22/01/14 01:43, Bill Nottingham wrote:
  Summary of changes:
  
 8e17d38... Retire - actually in RHEL (*)
 
 Might the retirement process have blocked perl-HTML-Tree from being pulled in 
 from RHEL in koji? That's what it looks like from this scratch build:
 
 http://kojipkgs.fedoraproject.org//work/tasks/9537/6439537/root.log

I think I've fixed this. Please test?

Bill
--
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-HTML-TableExtract/epel7: 3/3] Fix requires.

[Bill Nottingham]

commit f5efb4b57dcd8d50fc2fddca1106db4316bd9d4d
Author: Bill Nottingham nott...@redhat.com
Date:   Thu Jan 23 14:25:42 2014 -0500

Fix requires.

 perl-HTML-TableExtract.spec |8 +++-
 1 files changed, 7 insertions(+), 1 deletions(-)
---
diff --git a/perl-HTML-TableExtract.spec b/perl-HTML-TableExtract.spec
index c39d1b6..0fb6a66 100644
--- a/perl-HTML-TableExtract.spec
+++ b/perl-HTML-TableExtract.spec
@@ -1,6 +1,6 @@
 Name:   perl-HTML-TableExtract
 Version:2.11
-Release:   3%{?dist}
+Release:   4%{?dist}
 Summary:A Perl module for extracting content in HTML tables
 Group:  Development/Libraries
 License:GPL+ or Artistic
@@ -24,6 +24,9 @@ BuildRequires:perl(Test::More)
 BuildRequires: perl(Test::Pod)
 BuildRequires: perl(Test::Pod::Coverage)
 BuildRequires: perl(vars)
+Requires:  perl(HTML::ElementTable)
+Requires:  perl(HTML::TreeBuilder)
+
 
 %description
 HTML::TableExtract is a module that simplifies the extraction of
@@ -54,6 +57,9 @@ make test
 %{_mandir}/man3/*.3*
 
 %changelog
+* Thu Jan 23 2014 Bill Nottingham nott...@redhat.com - 2.11-4
+- fix requires to be more correct (#1056804)
+
 * Sat Aug 03 2013 Fedora Release Engineering rel-...@lists.fedoraproject.org 
- 2.11-3
 - Rebuilt for https://fedoraproject.org/wiki/Fedora_20_Mass_Rebuild
 
--
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

File Finance-Quote-1.20.tar.gz uploaded to lookaside cache by notting

[Bill Nottingham]

A file has been added to the lookaside cache for perl-Finance-Quote:

1cc20330f383a780685ed72e1b286606  Finance-Quote-1.20.tar.gz
--
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] update to 1.20

[Bill Nottingham]

commit 024d03a472ec7ab76dca25bcf1d3866d0cc4439a
Author: Bill Nottingham nott...@redhat.com
Date:   Mon Feb 17 11:35:39 2014 -0500

update to 1.20

 .gitignore  |2 +-
 perl-Finance-Quote.spec |   11 +++
 sources |2 +-
 3 files changed, 9 insertions(+), 6 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index 1dc5d34..0fe8b55 100644
--- a/.gitignore
+++ b/.gitignore
@@ -1 +1 @@
-Finance-Quote-1.17.tar.gz
+/Finance-Quote-1.20.tar.gz
diff --git a/perl-Finance-Quote.spec b/perl-Finance-Quote.spec
index 1ab5556..3c6bb1f 100644
--- a/perl-Finance-Quote.spec
+++ b/perl-Finance-Quote.spec
@@ -1,12 +1,11 @@
 Name:  perl-Finance-Quote
-Version:1.17
-Release:   13%{?dist}
+Version:1.20
+Release:   1%{?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
-Patch0:tiaa-cref.patch
 BuildRoot:  %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
 BuildArch:  noarch
 Requires:  perl(:MODULE_COMPAT_%(eval `%{__perl} -V:version`; echo 
$version))
@@ -17,6 +16,7 @@ BuildRequires:  perl(Carp)
 BuildRequires:  perl(CGI)
 BuildRequires: perl(Crypt::SSLeay)
 BuildRequires:  perl(Data::Dumper)
+BuildRequires:  perl(Date::Calc)
 BuildRequires:  perl(Encode)
 BuildRequires:  perl(Exporter)
 BuildRequires:  perl(HTML::Parser)
@@ -25,6 +25,7 @@ BuildRequires:  perl(HTML::TreeBuilder)
 BuildRequires:  perl(HTTP::Headers)
 BuildRequires:  perl(HTTP::Request::Common)
 BuildRequires:  perl(HTTP::Status)
+BuildRequires:  perl(JSON)
 BuildRequires:  perl(LWP::Simple)
 BuildRequires: perl(LWP::UserAgent)
 BuildRequires:  perl(URI)
@@ -40,7 +41,6 @@ using various source.
 
 %prep
 %setup -q -n Finance-Quote-%{version} 
-%patch0 -p2
 find . -name *.pm | xargs %{__sed} -i -e '/^#!.*\/usr\/bin\/perl/d'
 
 %build
@@ -68,6 +68,9 @@ rm -rf $RPM_BUILD_ROOT
 %{_mandir}/man3/*.3*
 
 %changelog
+* Mon Feb 17 2014 Bill Nottingham nott...@redhat.com - 1.20-1
+- update to 1.20
+
 * Sun Aug 04 2013 Petr Pisar ppi...@redhat.com - 1.17-13
 - Perl 5.18 rebuild
 
diff --git a/sources b/sources
index 054e80f..95d0015 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-446dba3837ffa395bffdea268824e0c1  Finance-Quote-1.17.tar.gz
+1cc20330f383a780685ed72e1b286606  Finance-Quote-1.20.tar.gz
--
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] (3 commits) ...update to 1.20

[Bill Nottingham]

Summary of changes:

  8dd6c6e... - Rebuilt for https://fedoraproject.org/wiki/Fedora_20_Mass (*)
  a18423e... Perl 5.18 rebuild (*)
  024d03a... update to 1.20 (*)

(*) 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] update to 1.20

[Bill Nottingham]

Summary of changes:

  024d03a... update to 1.20 (*)

(*) 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/f19] (3 commits) ...update to 1.20

[Bill Nottingham]

Summary of changes:

  8dd6c6e... - Rebuilt for https://fedoraproject.org/wiki/Fedora_20_Mass (*)
  a18423e... Perl 5.18 rebuild (*)
  024d03a... update to 1.20 (*)

(*) 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: 18/18] Merge branch 'master' into el6

[Bill Nottingham]

commit bfccbc061723925971a8f4ede6fc738491871e3f
Merge: 4a7c1b1 024d03a
Author: Bill Nottingham nott...@redhat.com
Date:   Mon Feb 17 12:07:23 2014 -0500

Merge branch 'master' into el6

 .gitignore  |2 +-
 perl-Finance-Quote.spec |   68 ++-
 sources |2 +-
 tiaa-cref.patch |  520 +++
 4 files changed, 586 insertions(+), 6 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/el6] (18 commits) ...Merge branch 'master' into el6

[Bill Nottingham]

Summary of changes:

  a111900... update to 1.17 (#540340, bba...@gmail.com) (*)
  e908a64... Fix typo that causes a failure to update the common directo (*)
  5dc734c... - rebuild against perl 5.10.1 (*)
  f2dfa16... - Mass rebuild with perl-5.12.0 (*)
  8bf9220... dist-git conversion (*)
  34e0fd7... fix rawhide build. (*)
  33ec38d... - fix TIAA-CREF (#668935, amess...@messinet.com) (*)
  00d8285... - Rebuilt for https://fedoraproject.org/wiki/Fedora_15_Mass (*)
  57533ff... Perl mass rebuild (*)
  5f09e88... - Rebuilt for https://fedoraproject.org/wiki/Fedora_17_Mass (*)
  a284b70... Perl 5.16 rebuild (*)
  5871272... Specify all dependencies (*)
  f3837c6... - Rebuilt for https://fedoraproject.org/wiki/Fedora_18_Mass (*)
  788d0be... - Rebuilt for https://fedoraproject.org/wiki/Fedora_19_Mass (*)
  8dd6c6e... - Rebuilt for https://fedoraproject.org/wiki/Fedora_20_Mass (*)
  a18423e... Perl 5.18 rebuild (*)
  024d03a... update to 1.20 (*)
  bfccbc0... 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] 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

[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

Change to the orphan and deprecation policy

[Bill Nottingham]

FESCo today approved a change to how orphan and deprecated packages are
handled in Fedora.

The prior policy was:
- Packages that have been orphaned for more than three months require
  a re-review, regardless of whether or not they have been blocked.

The new policy is:
- Any package that is deprecated (i.e., blocked) requires a re-review
  before it can return to Fedora. Orphaned packages do not require
  a re-review.

Note that orphaned packages will be deprecated once per release cycle.

For more information, see:
 https://fedoraproject.org/wiki/Orphaned_package_that_need_new_maintainers

Bill, on behalf of FESCo
___
devel-announce mailing list
devel-announce@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel-announce

An update on critical path packages

[Bill Nottingham]

As of this week, bodhi is using the Fedora Package Database to determine the
critical path package list.

As part of this effort, the critical path package lists have been
regenerated for Fedora 15, Fedora 16, and rawhide. Various errors in the
generation process have been fixed, causing the critical path package list
to change.

If you have any questions about why a package you maintain is or isn't
in the critical path, feel free to open a ticket with rel-eng at:
https://fedorahosted.org/rel-eng/

Bill, on behalf of rel-eng  FESCo
___
devel-announce mailing list
devel-announce@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel-announce

Fedora 18 Development - orphaned retired packages

[Bill Nottingham]

Just a quick note - now that Fedora 18 development is open, we encourage
mantainers who are planning on orphaning or retiring their packages to do so
as early in the process as possible. That gives other maintainers a longer
runway to fix dependencies and possibly pick up maintenance if they so
desire.

Bill
___
devel-announce mailing list
devel-announce@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel-announce

[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

[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