smuxi builds stalled
by Antonio Trande
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi all.
Rawhide smuxi builds seem blocked on Koji; this is my third attempt:
http://koji.fedoraproject.org/koji/taskinfo?taskID=8541548
No errors, but stopped.
This is SPEC that generates Smuxi's RPMs:
http://pkgs.fedoraproject.org/cgit/smuxi.git/tree/smuxi.spec
- --
Antonio Trande
mailto: sagitter 'at' fedoraproject 'dot' org
http://fedoraos.wordpress.com/
https://fedoraproject.org/wiki/User:Sagitter
GPG Key: 0x66E15D00
Check on https://keys.fedoraproject.org/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQIcBAEBAgAGBQJUrS2wAAoJEFyovWBm4V0Ah+cP/jFXNpKxiutUoXs62BE3/r5L
WQBrk0YMXH7cdvij+wC5PT3S6KQ+bW7YpozSErCIiYN4K4ychYEAq/f1zXcpojOS
LgtMipgKSUZ7ovBVmuOELKojfYdncvDEB2fqALDiAxmvK0UijTsyYNwOggDQ2W2A
bM/4Le6743I6PWRqEtHYnykuCs11VT13KDapluYDRluAzxdEW7YLZM0nJyL0+E2D
T1+CeZ0s67hWnFMMXHccRmyqvtHNKWljbqmYr5q0Tm69KAqhdPQFxu73uOZLoV64
SJ4Y9Yxkh1qirq17dwxkGxYyw5cizvHKH0WPx3DnnrgeVBQijijcCVJxv/xey5tU
9aaXv0izJjzvy9cYD0Q9ub3tqWaH1sjcQNEIciIt164iC/yqzGRFKAGACwWP0war
Iz4uDFhApzZi3IKQozyKVlBHg0OMtEsWI+cugDOGDYxPMVsWZOfHFa1WYUmENhtn
XYgORpN/PxlyVwXKROvAvAngRh8aie+Rlghfa6imJYIK8IIMM33czqSctRKAmJsJ
ib7kcw7RMOzeKWekeSj2YMHHwNQ7M5a7T6pgq4g4cFE4P2dLWmep4Fu6+1j504OT
pXOWF0I3UEeRnZHxBbB4OnjHIg3GQCIwLNL5+W/Zy6AUNRCUf5gyfUVivkh40ry1
6WzMtbKKKNqd7Wj3Qeo6
=dyeM
-----END PGP SIGNATURE-----
9 years, 3 months
systemd in F21 breaks namespaces for units
by Reindl Harald
https://bugzilla.redhat.com/show_bug.cgi?id=1184016
most, if not all of my systemd-units on a dozen of servers using
constructs like below to make the whole tree /var/lib readonly and the
needed subfolder RW which is now broken in Fedora 21 and kills all my setups
that is a *major regression* because this affects a lot of customized,
non-packaged systemd units all over the place
____________________________
ReadOnlyDirectories=/var/lib
ReadWriteDirectories=/var/lib/mysql
150120 13:44:01 [ERROR] Can't start server : Bind on unix socket:
Read-only file system
150120 13:44:01 [ERROR] Do you already have another mysqld server
running on socket: /var/lib/mysql/mysqld_dbmail.sock ?
9 years, 3 months
F22 Self Contained Change: Gradle 2.x
by Jaroslav Reznik
= Proposed Self Contained Change: Gradle 2.x =
https://fedoraproject.org/wiki/Changes/Gradle
Change owner(s): Mikolaj Izdebski <mizdebsk(a)redhat.com>
This change aims at making latest version of Gradle available in Fedora and
making it possible to easily build Fedora packages using Gradle.
== Detailed Description ==
Gradle [1] is a popular Java build automation tool, which can automate
building, testing, publishing, deployment and more of software packages or
other types of projects such as generated static websites, generated
documentation or indeed anything else.
This change brings latest upstream version of Gradle to Fedora, which enables
Fedora users to use Gradle to work with software projects.
This change also implements integration with software used for Java packaging
in Fedora (XMvn and Javapackages), which makes it possible to use standard
Fedora pagkaging techniques to build RPM packages with Gradle with all
features, such as automatic artifact installation or auto-requires/provides.
== Scope ==
* Proposal owners:
** Package latest Gradle 2.x
** Implement local Gradle resolver so that RPM packages can be built with
Gradle
** Update Java Packaging HOWTO to include information about Gradle packaging
* Other developers:
** Maintainers of packages not built with Gradle and which upstreams are using
Gradle as build system can optionally update their packages to be built with
Gradle, but that's not absolutely required as existing ways of building Java
packages will continue to work.
* Release engineering: N/A
* Policies and guidelines: N/A
[1] http://gradle.org/
_______________________________________________
devel-announce mailing list
devel-announce(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel-announce
9 years, 3 months
F22 System Wide Change: Glibc Unicode 7.0
by Jaroslav Reznik
= Proposed System Wide Change: Glibc Unicode 7.0 =
https://fedoraproject.org/wiki/Changes/Glibc_Unicode_7
Change owner(s): Mike Fabian <mfabian At redhat DOT com>, Pravin Satpute
<pravins At fedoraproject DOT org>, Siddhesh Poyarekar<spoyarek AT redhat DOT
com>
We are updating Glibc Unicode data from Unicode 5.1 to Unicode 7.0 version. It
took long time since there was not much documentation on how to update Unicode
data and also there was chance of loosing backward compatibility. Most of the
issues are resolved now and patches are ready for inclusion. This update adds
around 8000 number of character support in Glibc and also correcting the
Unicode data of many characters as per latest Unicode standard.
== Detailed Description ==
In this update we are planning to update Glibc's the Unicode locale data -
character map and LC_CTYPE information to Unicode 7.0 version. This data is
used almost in all locales and going to affect all applications using these
locales. It is system wide change since it impacting glibc and application
dependent on it. Glibc provides two files for Unicode data, UTF-8 and i18n.
UTF-8 file provides information about CHARMAP and WIDTH for Unicode characters.
i18n file provides CTYPE (uppercase, lowercase, punct etc.) information for all
Unicode characters. It has been long time this is not updated due to
incomplete documentation and also possible chances of loosing backward
compatibility. Work has been started on this 5-6 months back and now most of
the issues are resolved.
Respective bugs in upstream for more information.
* Update locale data to Unicode 7.0.0 [1]
* Update UTF-8 charmap and width to Unicode 7.0.0 [2]
Github repo for scripts. [3]
== Scope ==
* Proposal owners:
1. Writing scripts for generating UTF-8 and i18n files from Unicode character
database.
2. Preparing patch for UTF-8 and i18n files.
3. Preparing backward compatibility report.
4. Applying patches to Fedora.
5. Testing whether does it breaks anything around.
* Other developers: This change impacting glibc and all applications that
using locales. Other Developers do not need to do any changes from there end
but they need to watch how there application behave with improved localedata.
We need proper testing to see it does not break any application.
* Release engineering: No work required from Release engineering.
* Policies and guidelines: No, this change does not required any updates to
Policies or packaging guideline updates.
== Contingency Plan ==
* Contingency mechanism: Will drop patches from Glibc build.
* Contingency deadline: Before F22 Beta release eg. Beta freeze.
* Blocks release? No
* Blocks product? product No
[1] https://sourceware.org/bugzilla/show_bug.cgi?id=14094
[2] https://sourceware.org/bugzilla/show_bug.cgi?id=17588
[3] https://github.com/pravins/lohit
_______________________________________________
devel-announce mailing list
devel-announce(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel-announce
9 years, 3 months
F22 Self Contained Change: Domain Controller Set Up Through Cockpit
by Jaroslav Reznik
= Proposed Self Contained Change: Domain Controller Set Up Through Cockpit =
https://fedoraproject.org/wiki/Changes/CockpitDomainController
Change owner(s): Stephen Gallagher <sgallagh(a)redhat.com>
With Fedora 21, the rolekit project now provides a public D-BUS interface for
creating a Domain Controller based on the FreeIPA project. This Change will
track adding this capability to the Cockpit management console of Fedora
Server.
== Detailed Description ==
Providing users with a simple graphical user interface to set up a FreeIPA
Domain Controller will provide a fast way to bootstrap an enterprise-grade
Linux environment. Once the Domain Controller is made available, it becomes
easy to manage single-sign-on between systems (and Cockpit instances), control
user authentication and authorization centrally and manage DNS entries (among
other things).
== Scope ==
* Proposal owners: The Cockpit user experience needs to be written and added
to that upstream project. It needs to be connected to the local rolekit
daemon.
* Other developers: N/A (not a System Wide Change)
* Release engineering: N/A (not a System Wide Change)
* Policies and guidelines: N/A (not a System Wide Change)
_______________________________________________
devel-announce mailing list
devel-announce(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel-announce
9 years, 3 months
F22 System Wide Change: Default Local DNS Resolver
by Jaroslav Reznik
= Proposed System Wide Change: Default Local DNS Resolver =
https://fedoraproject.org/wiki/Changes/Default_Local_DNS_Resolver
This Change was already proposed as Fedora 21 Change but moved to Fedora 22
(and discussed as Fedora 22 Change), re-announcing it as more details were
provided as requested by FESCo [0].
Change owner(s): P J P <pjp(a)fedoraproject.org>, Pavel Šimerda
<pavlix(a)pavlix.net>, Tomas Hozza <thozza(a)redhat.com>
To install a local DNS resolver trusted for the DNSSEC validation running on
127.0.0.1:53. This must be the only name server entry in /etc/resolv.conf.
The automatic name server entries received via dhcp/vpn/wireless configurations
should be stored separately, as transitory name servers to be used by the
trusted local resolver. In all cases, DNSSEC validation will be done locally.
== Detailed Description ==
There are growing instances of discussions and debates about the need for a
trusted DNSSEC validating local resolver running on 127.0.0.1:53. There are
multiple reasons for having such a resolver, importantly security & usability.
Security & protection of user's privacy becomes paramount with the backdrop of
the increasingly snooping governments and service providers world wide.
People use Fedora on portable/mobile devices which are connected to diverse
networks as and when required. The automatic DNS configurations provided by
these networks are never trustworthy for DNSSEC validation. As currently there
is no way to establish such trust.
Apart from trust, these name servers are often known to be flaky and
unreliable. Which only adds to the overall bad and at times even frustrating
user experience. In such a situation, having a trusted local DNS resolver not
only makes sense but is in fact badly needed. It has become a need of the
hour. (See: [1], [2], [3])
Going forward, as DNSSEC and IPv6 networks become more and more ubiquitous,
having a trusted local DNS resolver will not only be imperative but be
unavoidable. Because it will perform the most important operation of
establishing trust between two parties.
All DNS literature strongly recommends it. And amongst all discussions and
debates about issues involved in establishing such trust, it is unanimously
agreed upon and accepted that having a trusted local DNS resolver is the best
solution possible. It'll simplify and facilitate lot of other design decisions
and application development in future. (See: [1], [2], [3])
People:
* Petr Spacek
* Paul Wouters
* Simo Sorce
* Dmitri Pal
* Carlos O'Donell
== Scope ==
Proposal owners: Proposal owners shall have to
* define the syntax and semantics for new configuration parameters/files.
* persuade and coordinate with the other package owners to incorporate new
changes/workflow in their applications.
Other developers: (especially NetworkManager and the likes)
* would have to implement the new features/workflow for their applications
adhering to the new configurations and assuming the availability of the trusted
local DNS resolver.
* NetworkManager already has features & capability to support local DNS
resolvers. Though few details are still under development, but are expected to
realize in near future. Please see ->
https://lists.fedoraproject.org/pipermail/devel/2014-April/197848.html
Release engineering:
* would have to ensure that trusted local DNS resolver is available throughout
the installation stage and the same is installed on all installations
including LiveCDs etc.
Policies and guidelines:
* the chosen trusted DNS resolver package(ex dnsmasq or dnssec-trigger etc.)
would have to ensure that their DNS resolver starts at boot time and works out
of the box without any user intervention.
* NetworkManager and others would have to be told to not tamper with the local
nameserver entries in '/etc/resolv.conf' and save the dynamic nameserver
entries in a separate configuration file.
[0] https://fedorahosted.org/fesco/ticket/1307
[1] https://www.ietf.org/mail-archive/web/dane/current/msg06469.html
[2] https://www.ietf.org/mail-archive/web/dane/current/msg06658.html
[3] https://lists.fedoraproject.org/pipermail/devel/2014-April/197755.html
_______________________________________________
devel-announce mailing list
devel-announce(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel-announce
9 years, 3 months
F22 System Wide Change: GCC5
by Jaroslav Reznik
= Proposed System Wide Change: GCC5 =
https://fedoraproject.org/wiki/Changes/GCC5
Change owner(s): Jakub Jelínek <jakub(a)redhat.com>
Switch GCC in Fedora 22 to 5.x.y, rebuild all packages with it.
== Detailed Description ==
GCC 5 is currently in stage3, but in 3 days will move to stage4, in prerelease
state with only regression bugfixes and documentation fixes allowed. The release
will happen probably in the first half of April. We are working on scratch gcc
rpms and will perform a test mass rebuild. Other distributions have performed
test mass rebuilds already.
== Scope ==
All packages should be rebuilt with the new gcc once it hits f22.
* Proposal owners: Build gcc in f22, rebuild packages that have direct
dependencies on exact gcc version (libtool, llvm, gcc-python-plugin).
* Other developers: First few days/weeks just voluntary rebuilds using the new
system gcc, if things fail, look at http://gcc.gnu.org/gcc-5/porting_to.html
and fix bugs in packages or, if there is a gcc bug or suspected gcc bug,
analyze and report.
* Release engineering: Organize a mass rebuild
* Policies and guidelines: No policies need to be changed
== Contingency Plan ==
If bugs are discovered, I'd appreciate help from the package owners in
preparing self-contained testcases to speed up analysis and fixing the bugs.
Don't have time to debug issues in 12000+ packages, especially when in many
cases it could be caused by undefined code in the packages etc. I don't expect
we'll have to fall back to the older gcc, we've never had to do it in the
past, but worst case we can mass rebuild everything with older gcc again.
* Contingency mechanism: Revert to older gcc, mass rebuild everything again
* Contingency deadline: Before release
* Blocks release? Yes
* Blocks product? No
_______________________________________________
devel-announce mailing list
devel-announce(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel-announce
9 years, 3 months
Re: python-dateutil update
by Zbigniew Jędrzejewski-Szmek
On Mon, Dec 08, 2014 at 09:10:59AM -0700, Pete Travis wrote:
> On Dec 8, 2014 8:51 AM, "Zbigniew Jędrzejewski-Szmek" <zbyszek(a)in.waw.pl>
> wrote:
> >
> > On Sun, Dec 07, 2014 at 04:45:12PM -0700, Pete Travis wrote:
> > > python-dateutil is old[0]. Fedora is carrying version 1.5, and upstream
> > > is up to 2.3 . If you're receiving this mail directly, you are a
> > > maintainer of a package that depends on python-dateutil, and we need
> > > your help.
> > It seems that calibre is fine with the new version. I wanted to update
> > pyton-dateutil to check if calibre works, and it seems that I
> > installed python-dateutil-2.3 with pip --user couple of months ago and
> > calibre didn't seem to mind. There's some dateutil usage in the installer,
> > which I didn't test but which we probably don't care about.
> > https://github.com/dateutil/dateutil/blob/master/NEWS also doesn't seem
> > scary.
> >
> > So I think it's fine it python-dateutil is updated as a calibre dep.
> >
> > Zbyszek
>
> Great, thanks for responding. I'm a *light* calibre user, but I'd be
> happy to help test with a newer dateutil when it becomes available if
> that's the direction you are going.
You can just install the python-dateutil-2.* package and test away ;)
Looking at the list and your annoucement mail again, I wonder if it
might be better to bump python-dateutil to 2.2 again as soon as the
updated python-dateutil15 is available, and simply modify packages
which either explicitly depend on dateutil < 2 or exhibit problems to
depend on python-dateutil15. Proven packagers can do that trivially if
necessary. Otherwise this could drag on for months.
fedocal and python-django-tastypie are the only packages which
explicitly require python-dateutil < 2. If you wish, I can volunteer
file bugs to change the dependency for F21 and rawhide for those two
packages and do it myself after a week if the maintainers don't
respond or are fine with the change (got to use those provenpackager
privs for something :)).
Zbyszek
9 years, 3 months