Jaroslav Reznik | 14 Apr 15:40 2014
X-Face
Picon

F21 Self Contained Change: SDDM as the default KDE display manager instead of KDM

= Proposed Self Contained Change: SDDM as the default KDE display manager 
instead of KDM = 
https://fedoraproject.org/wiki/Changes/SDDMinsteadOfKDM

Change owner(s): Martin Briza <mbriza <at> redhat.com> & KDE SIG

Retire KDM as the default display manager of the KDE Fedora Spin in favor of 
SDDM.

== Detailed Description ==
As described in many articles and discussions, KDM is nearing its end of life 
and it's time we decided upon the successor.

I'm proposing to switch to SDDM, which is a new project that suits our needs 
perfectly despite its immaturity:

As of July 2013, KDM's maintenance consists of bugfixes for the most painful 
bugs, consisting of only about 20 actual commits to the repository in last two 
years (excluding translation, themes and merges), adding many new features 
would require major changes to a lot of the code and there is no active 
maintainer.

SDDM is written in C++11/Qt5 (compared to the bits of XDM in KDM), compilable 
against Qt4, supports QtQuick theming and its upstream is quite active.

Compared to the current DM, KDM, it currently lacks a few features (such as 
XDMCP) but adds some other ones (QtQuick themes) or is currently adding them 
(Keyboard layout switching in the greeter). 

== Scope ==
(Continue reading)

Jaroslav Reznik | 14 Apr 16:16 2014
X-Face
Picon

F21 System Wide Change: Ruby193 in SCL

= Proposed System Wide Change: Ruby193 in SCL = 
https://fedoraproject.org/wiki/Changes/Ruby193_in_SCL

Change owner(s): Marcela Mašláňová <mmaslano <at> redhat.com>

Ruby 1.9.3 with Rails 3.2.8 is still commonly used by many projects. Let's 
provide Ruby and Rails in SCL even for Fedora. Rails depends on exact v8 
version, which means v8 3.14 must have also their own SCL as part of the SCL. 

== Detailed Description ==
Ruby 1.9.3 with Rails 3.2.8 is still commonly used by many projects. This 
change aims to provide Ruby 1.9.3 and Rails 3.2.8. Rails depends on exact v8 
version, which means v8 3.14 must have also their own SCL as part of this 
change. 

== Scope ==
* Proposal owners: Marcela
** create the actual collections, at start in Copr and on SCL upstream [1]

* Other developers: Cloud WG
** test SCL with their apps

* Release engineering:
** create branches in dist-git
** add Ruby193 packages into compose

[1] https://www.softwarecollections.org/en/
_______________________________________________
devel-announce mailing list
devel-announce <at> lists.fedoraproject.org
(Continue reading)

Jaroslav Reznik | 14 Apr 15:07 2014
X-Face
Picon

F21 Self Contained Change: Remote Journal Logging

= Proposed Self Contained Change: Remote Journal Logging = 
https://fedoraproject.org/wiki/Changes/Remote_Journal_Logging

Change owner(s): Zbigniew Jędrzejewski-Szmek <zbyszek <at> in.waw.pl>

Systemd journal can be configured to forward events to a remote server. 
Entries are forwarded including full metadata, and are stored in normal 
journal files, identically to locally generated logs. 

== Detailed Description ==
Systemd's journal currently provides a replacement for most functionality 
offered by traditional syslog daemons,
with two notable exceptions: arbitrary filtering of messages and forwarding of 
messages over the network. This Change targets the latter.

The high-level goal is to have a mechanism where journal logging can be 
extended
to keep a copy of logs on a remote server, without requiring any maintenance, 
done
fairly efficiently and in a secure way.

Two new daemons are added as part of the systemd package:
* on the receiver side systemd-journal-remote accepts messages in the Journal 
Export Format [1]. The export format is a simple serialization of journal 
entries, supporting both text and binary fields. This means that the messages 
are transferred intact, apart from the "cursors", which specify the location 
in the journal file. Received entries are stored in local journal files 
underneath /var/log/journal. Those files are subject to normal journald rules 
for rotation, and the older ones will be removed as necessary to stay within 
disk usage limits. Once entries have been written to the journal file, they 
(Continue reading)

Jaroslav Reznik | 14 Apr 14:57 2014
X-Face
Picon

F21 Self Contained Change: Move to ImageFactory For Cloud Image Creation

= Proposed Self Contained Change: Move to ImageFactory For Cloud Image 
Creation = 
https://fedoraproject.org/wiki/Changes/Move_to_ImageFactory_For_Cloud_Image_Creation

Change owner(s):  Ian McLeod <imcleod <at> redhat.com>, Dennis Gilmore 
dgilmore <at> fedoraproject.org 

Create images using Anaconda in Koji rather than appliance-creator. Allows 
non-scratch builds with fedmsg integration for upload service, and also could 
produce official Docker images. 

== Detailed Description ==
Jay Greguske recently added a feature to koji that allows it to create full 
system disk images using Image Factory. These images can be output both as raw 
and qcow2 disk images, as well as OVA/OVF bundles compatible with OVirt, 
VMWare and RHEV-M. They are created by running Anaconda kickstart installs in 
virt containers and then packaging/encapsulating the results. 

== Scope ==
* Proposal owners: The Image Factory support in Fedora koji has already landed 
and images are already being built using this technique.  The work for F21 
should mainly involve making sure that the existing cloud kickstart files work 
when run directly by Anaconda and making any chances needed to ensure that 
they do.
* 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 <at> lists.fedoraproject.org
(Continue reading)

Jaroslav Reznik | 14 Apr 14:29 2014
X-Face
Picon

F21 System Wide Change: Fedora 21 Make 4.0 Update

= Proposed System Wide Change: Fedora 21 Make 4.0 Update = 
https://fedoraproject.org/wiki/Changes/F21Make40

Change owner(s): Patsy Franklin <pfrankli <at> redhat.com>

This change brings Make 4.0 to Fedora 21. 

== Detailed Description ==
The purpose of this update is to synchronize Fedora with the most recent Make 
release.

Several new features, new command line options, new variables, and bug fixes 
have been implemented in Make 4.0.

Improved error reporting may result in log file differences. If a recipe 
fails, the makefile name and linenumber of the recipe are shown.

There is one backwards-incompatibility regarding the use of .POSIX. Make 4.0 
will adhere to POSIX requirements for backshlash/newline handling. See the 
link included under Documentation for more details.

A new subpackage make-devel will be created containing gnumake.h,a new file 
containing externally-visible content. 

== Scope ==
* Proposal owners:
** Rebase to make-4.0
** 6 patches need to be updated to work with new sources
** 14 patches will be removed as they are already supported by the make-4.0 
rebase
(Continue reading)

Jaroslav Reznik | 14 Apr 14:13 2014
X-Face
Picon

F21 System Wide Change: SCL

= Proposed System Wide Change: SCL = 
https://fedoraproject.org/wiki/Changes/SCL

Change owner(s): Marcela Mašláňová <mmaslano <at> redhat.com>

SCL - Software Collections - are popular packaging format above rpm. Let's 
enable them for Fedora. More details on upstream page [1]. 

== Detailed Description ==
My first draft [2] is obsoleted by current state of SCL, Copr... I would keep 
the SCL workflow simple as possible.

Playground repo

1. Build SCL in Copr
2. Add SCL into Playground repo

Fedora main repo

0. Build SCL in Copr (or use existing SCL)
1. Do standard package review
2. Upload packages into git - specific branch based on Fedora version and name 
of collection. For stable repo we must be able to replicate builds from git 
repo, which Fedora own.
3. Build SCL in koji or magically add SCL builds from Copr (depends on 
preference of releng)

SCL living on Copr can be good candidates for inclusion in Fedora. Maintainer 
of such SCL must be able create Change proposal for his collection. Review of 
packages in the collection should depend on repository (Playground - almost no 
(Continue reading)

Petr Pisar | 14 Apr 08:44 2014
Picon

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

On 2014-04-11, Jaroslav Reznik <jreznik <at> redhat.com> wrote:
>= Proposed System Wide Change:  The securetty file is empty by default = 
> https://fedoraproject.org/wiki/Changes/securetty_file_is_empty_by_default
>
[...]
> Disabling root access via any console device (tty). 
>
This is silly. If a system has been broken very badly, then one goes to
the machine and fix if from the local TTY.

With local access, there is no way how to prevent from rooting the
machine. (Let's forget on TPM-guarded or on-line-audited systems now.)
So preventing from logging as root on Linux virtual terminal is
pointless.

Hiding a root access behind two passwords does not bring any better
security than using one strong root password.

You are making simple things over-complicated.

-- Petr

--

-- 
devel mailing list
devel <at> lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
P J P | 13 Apr 21:23 2014
Picon

New configurations in /etc/resolv.conf

  Hello,

Please see:
  -> http://www.ietf.org/mail-archive/web/dane/current/msg06469.html
  -> https://www.ietf.org/mail-archive/web/dane/current/msg06658.html

These two threads are about handling of Authenticated Data(AD) bit by the stub resolvers. There two
proposed solutions for this problem:

 1) To install a 'trusted' local resolver running on 127.0.0.1:53.
    A system wide change request has been filed for this.
    -> https://fedoraproject.org/wiki/Changes/Default_Local_DNS_Resolver

 2) To strip the AD bit in stub resolvers by default. This requires new configuration
    parameter(s) to be defined in '/etc/resolv.conf'.

This is required because, till the time 'trusted' local resolver becomes a norm, applications need some
way to know whether the listed name servers in '/etc/resolv.conf' are trustworthy or not.

The discussion is open for ways to convey 'trustworthyness' of the listed name servers to the requesting
applications and ways to enable/disable AD bit stripping in the stub resolver.

Your inputs/comments about syntax & semantics of the new configurations in '/etc/resolv.conf' are most welcome.

Thank you.
---
Regards
   -Prasad
http://feedmug.com
--

-- 
(Continue reading)

Fedora Rawhide Report | 13 Apr 17:01 2014

rawhide report: 20140413 changes


Broken deps for i386
----------------------------------------------------------
[MegaMek]
	MegaMek-0.30.11-13.fc20.i686 requires java-gcj-compat
	MegaMek-0.30.11-13.fc20.i686 requires java-gcj-compat
[PyKDE]
	PyKDE-3.16.6-14.fc20.i686 requires sip-api(10) >= 0:10.0
[ale]
	ale-0.9.0.3-13.fc20.i686 requires libMagickCore-6.Q16.so.1
[aunit]
	aunit-2013-2.fc21.i686 requires libgnat-4.8.so
[aws]
	aws-3.1.0-4.fc21.i686 requires libgnat-4.8.so
	aws-3.1.0-4.fc21.i686 requires libgnarl-4.8.so
	aws-devel-3.1.0-4.fc21.i686 requires libgnat-4.8.so
	aws-devel-3.1.0-4.fc21.i686 requires libgnarl-4.8.so
[compat-gcc-34]
	compat-gcc-34-c++-3.4.6-29.fc19.i686 requires libstdc++ < 0:4.9.0
[csound]
	csound-java-5.19.01-1.fc20.i686 requires java-gcj-compat
	csound-java-5.19.01-1.fc20.i686 requires java-gcj-compat
	csound-java-5.19.01-1.fc20.i686 requires java-1.5.0-gcj
[deltacloud-core]
	deltacloud-core-rackspace-1.1.3-1.fc20.noarch requires rubygem(cloudfiles)
[derelict]
	derelict-tcod-3-26.201410303git9570453.fc21.i686 requires tcod
	derelict-tcod-devel-3-26.201410303git9570453.fc21.i686 requires tcod
[devtodo2]
	devtodo2-2.1-8.20120711git8dee6.fc21.i686 requires libgo.so.4
(Continue reading)

Markus Mayer | 13 Apr 14:21 2014
Picon
Picon

appdata handling

A new version of a package I maintain added an appdata.xml. As I haven't 
handled such files before, I looked up the internet for some 
information. The only helpful hint I found, was a commit adding appdata 
support to the qt-creator package in fedora git. [1]

As more packages will add appdata file upstream, packagers will need 
information how to handle this within fedora. I suggest to these 
information to the Packaging Guidelines.

What I'm interested in is:
- Directory, Name, ownership and permissions for appdata.xml files
- %post/%postun scriptlets (if needed)
- If appdata-validate must be run during package build
- How long does it take that the new appdata is propagated to gnome-software

As a side note: build.log contains the following error:
error: Couldn't exec /usr/lib/rpm/appdata.prov: No such file or directory

[1] 
http://pkgs.fedoraproject.org/cgit/qt-creator.git/commit/?h=epel7&id=812bac7be961483c992a3337fc8a35c524c73079
--

-- 
devel mailing list
devel <at> lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Reindl Harald | 13 Apr 06:35 2014
Picon

Re: default local DNS caching name server


Am 13.04.2014 03:07, schrieb Paul Wouters:
> On Sun, 13 Apr 2014, William Brown wrote:
>> When they change records in their local zones, they don't want
>> to have to flush caches etc. If their ISP is unreliable, or their own
>> DNS is unreliable, a DNS cache will potentially mask this issue delaying
>> them from noticing / solving the problem.
> 
> This is becoming really contrived. Again, if you think this is a real
> scenario (I don't think it is) than you could run unbound with ttl=0

i would run BIND and not unbound in any case
and now?
would you pull me unbound as dependency?

> But a requirement of automagically understanding what a local zone is
> and automagically understanding when a remote authoritative dns server
> changes data, and not willing to enforce that with ttl=0, and using
> that as argument why any solution of unbound to provide a security
> feature (DNSSEC) is getting a little unrealistic. If you want your
> laptop to start validating TLSA and SSHP and OPENPGPKEY records, you
> need DNSSEC validation on the device. The question should be "how do you
> change your network requirements to meet that goal". Yes, enforcing
> security comes at a price.

boah it is *not* a security feature having a local resolver
which may bypass my DHCP provided DNS which may be the only
one with the correct DNS view

if you ask him anyways the result can't be more secure than
(Continue reading)


Gmane