-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
For the sake of keeping people in the loop, here's a first pass at the
Fedora Server technical specification that we will be discussing in a
meeting in #fedora-meeting-1 in about 75 minutes.
If you can't attend, please make comments on the
server(a)lists.fedoraproject.org mailing list, so they're all in one place.
- -------- Original Message --------
Subject: Server Technical Specification: Agenda and First Draft
Date: Fri, 28 Feb 2014 08:40:02 -0500
From: Stephen Gallagher <sgallagh(a)redhat.com>
Reply-To: server(a)lists.fedoraproject.org
To: server(a)lists.fedoraproject.org
I've created a wiki page[1] for the Technical Specification that we
are working on. I've copied much of the structure from the Workstation
tech spec, as it was well organized.
There are quite a few sections in it that I have tagged as UNAPPROVED.
I believe we need to make these the agenda for the Tech Spec Working
Session today. What we will do is quickly go through each of them.
We'll mark any that are uncontested as "Approved" and then go back and
discuss any that need discussion.
[1] https://fedoraproject.org/wiki/Server/Technical_Specification
_______________________________________________
server mailing list
server(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/server
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iEYEARECAAYFAlMQkpgACgkQeiVVYja6o6Md/wCgj67FPhsrHa/VxtuBfsCjJU4/
aUIAnRzu/lmm//qxRO0WTRogoTt44H7d
=apt3
-----END PGP SIGNATURE-----

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
So, I have an interesting problem to solve. I have a package that
installs a web application[1] that is run automatically with
httpd.service. The package can be deployed for one or more "sites" on
the system (which may be different apache virtual hosts or just
different paths on the same virtual host).
On version upgrades, there is a helper script that needs to be run for
each "site" of this package on the system to make sure that its
database is updated with the latest schema changes.
Originally, this helper script would have to be run manually for each
site after the package was upgraded (and if you forgot, the
application might not function correctly until you did so).
I worked with upstream and added a new feature that allows updating
all sites on the current system from a single command (getting the
list of installed sites from a data file in a known location). I added
this script to the %post of the RPM package so it would be run
automatically on package upgrade.
One problem with this approach is that it will force the database
upgrade for all sites on the system, regardless of whether the httpd
service is running (or currently serving that site), which could lead
to unexpected behavior. The other issue with this approach is that it
doesn't necessarily play nice with OSTree, since %post only gets
executed on the OSTree host and not on the clients.
I'd much rather be able to add the database upgrade script to a
per-site service unit, so that it would only be invoked as an
ExecStartPre command. This way, it would only be invoked if the
service was actually being launched on the system.
There are actually two pieces to this that I'd like to see (and
hopefully have someone tell me are already possible):
1. The ability to add new ExecStartPre commands to the httpd service
when installing new sites.
2. The ability to enable and disable specific apache sites from
systemctl. Basically, I'd like to have a symlink added or removed
from /etc/httpd/conf.d based on whether httpd-mysite.service was
enabled or disabled.
The ultimate goal here would be for me to be able to install a
reviewboard-sitename.conf file to e.g. /etc/systemd/httpd/ and have it
symlinked into /etc/httpd.conf.d when the service was enabled. This
service file could then be PartOf=httpd.service and run ExecStartPre
to invoke the upgrade script.
So, am I on track here, and if so: how can I do this?
[1] The package is Review Board, a Django application.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iEYEARECAAYFAlMM9R8ACgkQeiVVYja6o6NWLwCeM54Uc0gJKPFsprmvbwKoYQ0G
2nYAn0vSLoeHDlIWwCYeotXPYydiQ+7H
=W5Y9
-----END PGP SIGNATURE-----

Hi,
PHP 5.6.0 will be soon in "beta" stage.
(5.6.0alpha3 is available and should be the last alpha)
So I start working on PHP 5.6 packaging.
For those interested, for now, this happens in my personal repository
(remi-dev).
Fedora 20: http://rpms.famillecollet.com/fedora/20/devs/x86_64/repoview/
Fedora 19: http://rpms.famillecollet.com/fedora/19/devs/x86_64/repoview/
For now, 5.6.0 final is planed for June.
So should be possible for Fedora 21 (change proposal not yet submitted)
I will try to build most extensions to check is eveything is ok.
If you have some libraries, with test suite, or some webapps, I
encourage you to test again this new version (upgrade should be smooth).
Remi.

I've updated rawhide to cmake 3.0.0-rc1. That's a good place to look first if
your cmake build start failing suddenly.
- Orion
-------- Original Message --------
Subject: [CMake] CMake 3.0-rc1 now ready for testing!
Date: Fri, 28 Feb 2014 14:28:55 -0500
From: Robert Maynard <robert.maynard(a)kitware.com>
To: CMake Developers <cmake-developers(a)cmake.org>, CMake MailingList
<cmake(a)cmake.org>, kde-devel(a)kde.org
I am proud to announce that CMake 3.0 has entered the release candidate stage.
Sources and binaries are available at:
http://www.cmake.org/files/v3.0/?C=M;O=D
Documentation is available at:
http://www.cmake.org/cmake/help/v3.0
Release notes appear below and are also published at
http://www.cmake.org/cmake/help/v3.0/release/3.0.0.html
Some of the more significant features of CMake 3.0 are:
* Compatibility options supporting code written for CMake versions
prior to 2.4 have been removed.
* The CMake language has been extended with *Bracket Argument* and
*Bracket Comment* syntax inspired by Lua long brackets.
* The CMake documentation has been converted to reStructuredText and
uses Sphix generation.
* Generators for Visual Studio 10 (2010) and later were renamed to
include the product year like generators for older VS versions:
* "Visual Studio 10" -> "Visual Studio 10 2010"
* "Visual Studio 11" -> "Visual Studio 11 2012"
* "Visual Studio 12" -> "Visual Studio 12 2013"
This clarifies which generator goes with each Visual Studio version.
The old names are recognized for compatibility.
* A new "CodeLite" extra generator is available for use with the
Makefile or Ninja generators.
* A new "Kate" extra generator is available for use with the
Makefile or Ninja generators.
* The "add_library()" command learned a new "INTERFACE" library
type. Interface libraries have no build rules but may have
properties defining "usage requirements" and may be installed,
exported, and imported. This is useful to create header-only
libraries that have concrete link dependencies on other libraries.
* The "export()" command learned a new "EXPORT" mode that retrieves
the list of targets to export from an export set configured by the
"install(TARGETS)" command "EXPORT" option. This makes it easy to
export from the build tree the same targets that are exported from
the install tree.
* The "project()" command learned to set some version variables to
values specified by the new "VERSION" option or to empty strings.
See policy "CMP0048".
* Several long-outdated commands that should no longer be called
have been disallowed in new code by policies:
* Policy "CMP0029" disallows "subdir_depends()"
* Policy "CMP0030" disallows "use_mangled_mesa()"
* Policy "CMP0031" disallows "load_command()"
* Policy "CMP0032" disallows "output_required_files()"
* Policy "CMP0033" disallows "export_library_dependencies()"
* Policy "CMP0034" disallows "utility_source()"
* Policy "CMP0035" disallows "variable_requires()"
* Policy "CMP0036" disallows "build_name()"

Hi folks,
thanks for your feedback in the last few days. I've created two wiki pages about
packages which don't execute their tests in %check:
https://fedoraproject.org/wiki/QA/Testing_in_check
and another one for packages which don't seem to have test suites at all:
https://fedoraproject.org/wiki/QA/Missing_upstream_test_suites
My intent is for these pages to serve as a source of working material for Fedora
volunteers.
Note: there are some false negatives which I still haven't filtered out - work
in progress.
Please forward this to anyone who may be interested to work on these items as we
need lots of hands to make any significant improvements!
(In particular I will soon teach to students and will point them here).
Any comments and proposals are welcome!
Thanks,
Alex

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Apologies for the slightly alarmist $SUBJECT, but I want to make sure
that this gets read by the appropriate groups.
During today's FESCo meeting, there was the start of a discussion on
how to approve new Products into the Fedora family. As part of this,
it naturally strayed into discussion of what we do about Spins as they
currently exist.
Several ideas were raised (which I'll go through below), but we didn't
feel that this was something that FESCo should answer on its own. We'd
prefer community input on how to handle spins going forward.
So, in no particular order (because it's difficult to say which
questions are the most important):
1) Are Spins useful as they currently exist? There are many problems
that have been noted in the Spins process, most notably that it is
very difficult to get a Spin approved and then has no ongoing
maintenance requiring it to remain functional. We've had Spins at
times go through entire Fedora release cycles without ever being
functional.
2) Should Spins be eliminated entirely in favor of Fedora Remixes[1].
The effect here would be that Spins are no longer an official part of
The Fedora Project but are instead projects unto themselves which are
permitted to consume (possibly large) portions of our tools, packages
and ecosystem. Maintenance and upkeep of these spins then becomes
entirely the responsibility of the downstream community that
constructs them and has no mandatory draw on Fedora's marketing,
ambassadors or quality assurance resources.
3) Should Spins be considered Products-in-development? In other words,
should we only approve Spins that are targeted or destined for
"promotion" to a fully-supported Fedora Product? This is a nuanced
question, as it means different things for different Spins, for
example Spins focusing on a target-audience (Security Spin, Design
Suite Spin) vs. Spins focusing on a technology (LXDE Spin, MATE-Compiz
Spin).
3b) If we treat Spins as Products-in-development, what do we do with
those Spins that don't fit that criteria?
I'm sure there are other questions that people will come up with on
this thread, but this should provide a good framework for the discussion.
[1] https://fedoraproject.org/wiki/Remix
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iEYEARECAAYFAlLpZMwACgkQeiVVYja6o6NOIwCeP6Kr6FGVYLCdU9Uofv7Xrqm1
e3oAoIEky2/IjoGBF9MqVlEbkG0jd4vv
=KDoO
-----END PGP SIGNATURE-----