Re: F21 System Wide Change: Wayland

[drago01]

On Wed, Apr 30, 2014 at 12:41 AM, Bojan Smojver  wrote:
> On Tue, 2014-04-29 at 14:04 +0200, Jaroslav Reznik wrote:
>> GNOME is being ported to Wayland. In particular GNOME shell is changed to run
>> as a Wayland compositor instead of an X11 compositor.
>
> Does that mean that the shell will stop working on things like xrdp
> (which runs Xvnc behind the scenes)?

There are no plans to drop X afaik (atleast upstream X keeps working)
so in your case you'd simply
start an X session instead of a wayland session.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: F21 Self Contained Change: LVM Cache Logical Volumes

[Jaroslav Reznik]

- Original Message -
> Hello,
> 2014-04-29 14:48 GMT+02:00 Jaroslav Reznik < jrez...@redhat.com > :
> 
> 
> = Proposed Self Contained Change: LVM Cache Logical Volumes =
> https://fedoraproject.org/wiki/Changes/Cache_Logical_Volumes
> 
> 
> * Other developers: N/A (not a System Wide Change)
>  ... so this might be a system-wide change after all?
> Anyway, this is mostly for dracut, and ...
> 

I was thinking about it and with Anaconda team signed for this change,
I decided to go with announcement this way. Feel free to raise it and
I will ask owners to change it. Yes, Dracut is not covered but from
description is not essential part of this change.

Jaroslav

> 
> The dracut team must provide boot support. If dracut does not provide
> support, cache LVs will not be usable as root devices.
> This implies a fairly significant feature impact, while...
> 
> 
> 
> 
> == Contingency Plan ==
> Dracut: There is already a hardcoded dm-cache installation. If the detection
> is not done in time, it will work as is.
> ... this seems to say nothing important will happen?
> 
> In any case, having someone sign up to do the dracut integration seems like a
> very desirable way to resolve these things.
> Mirek
> 
> --
> devel mailing list
> devel@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/devel
> Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
-- 
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: kernel packaging split up landing in Rawhide

[Steven Whitehouse]

Hi,

On 29/04/14 22:41, Josh Boyer wrote:

Hi All,

As part of the F21 "Modular Kernel Packaging for Cloud" Feature[1],
I've committed and pushed the kernel packaging split up into
kernel-core and kernel-drivers subpackages.  For those of you running
rawhide, this really shouldn't be a major impact at all.  When you do
a yum update, you will see "kernel", "kernel-core", and
"kernel-drivers" packages being installed.  The end result should be
in line with today's rawhide kernels.

Note: Unless you're using a typical VM or Cloud image, don't uninstall
the kernel or kernel-drivers packages.  The machine may boot with just
kernel-core, but it will lack drivers for a significant portion of
bare-metal hardware without kernel-drivers installed.

Despite best efforts in testing, it's always possible a bug or two
snuck through.  In the event that you do have an issue with this,
please file a bug against the kernel package.

josh

[1]https://fedoraproject.org/wiki/Changes/Modular_Kernel_Packaging_for_Cloud


Just wondering how this will (or will not) affect kernel-module-extras ?

Currently there is a dependency (largely for backwards compatibility 
purposes) on kernel-module-extras from gfs2-utils and I'm wondering if 
that will need to be changed (or dropped) as a result of this,


Steve.

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

[perl-PerlIO-via-Timeout/epel7] Initial import (#1080952).

[David Dick]

Summary of changes:

  5f602f7... Initial import (#1080952). (*)

(*) 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-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel

Python 3.4 to rawhide

[Matej Stuchlik]

Good day folks,
Python 3.4 is now [ready and tagged] in f21-python, so I'd like to ask you
to make whatever modifications that may be necessary and [rebuild] your
Python packages into the tag. Once we have sufficient fraction up and running,
we'll merge with rawhide.

Note that your spec file may require slight tweaks due to some file suffixes
changing:
* bytecode files from .cpython-33.py[co] to .cpython-34.py[co]
* extension modules from .cpython-33m.so to .cpython-34m.so and
  .cpython-33dm.so to .cpython-34dm.so

There's also an upstream guide to [porting to Python 3.4] you may find helpful.

Finally, should you need help with your package, feel free to contact me and
I'll do my best to help... :)

Matt

[ready and tagged] http://koji.fedoraproject.org/koji/taskinfo?taskID=6794120
[rebuild] with fedpkg build --target f21-python
[porting to Python 3.4] 
https://docs.python.org/dev/whatsnew/3.4.html#porting-to-python-3-4
-- 
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: We want to stop systemd from being added to docker images, because of rpm requiring systemctl.

[Lennart Poettering]

On Tue, 29.04.14 15:36, Marcelo Ricardo Leitner (marcelo.leit...@gmail.com) 
wrote:

> Em 29-04-2014 12:27, Lennart Poettering escreveu:
> >On Tue, 29.04.14 10:37, Daniel J Walsh (dwa...@redhat.com) wrote:
> >
> >>
> >>On 04/29/2014 06:33 AM, Lennart Poettering wrote:
> >>>On Mon, 28.04.14 17:01, Daniel J Walsh (dwa...@redhat.com) wrote:
> >>>
> The problem  is lots of services require systemd because they ship a
> unit file and want systemctl reload to happen.  Systemd then triggers a
> require for udev and kmod, which docker containers do not need.
> >>>If you discount the docs/man pages of the RPMs, how much does kmod,
> >>>udev, systemd actually contribtue in bytes to your docker images?
> >>>
> >>>Lennart
> >>>
> >>Shrinking the the docker image is more then just size.  We want to
> >>eliminate packages that are not used (Within reason) to eliminate
> >>problems like CVE's.  If udev/systemd/kmod had a CVE we would need to
> >>update all Container images.
> >
> >Well, if you are this principled maybe. But do note that we dont really
> >ship suid binaries (except one binary with fscaps which is
> >systemd-detect-virt), and hence by leaving systemd in the image without
> >running it should result in no increased attack surface that wasn't
> >there anyway... Dead code in the image, that cannot be use to acquire
> >new caps isn't much of a security threat...
> 
> You're considering only the escalation way to do it, but there are
> other ways to exploit code laying around, like when some web pages
> don't sanitize the URL enough and end up allowing executing
> something in the system, much like sql injection. In those cases,
> one could craft URLs to run wget or any other tool that may help the
> intruder get even more inside.
> 
> It's a pile of faults, yes, but the result isn't good and one good
> preventive step is keeping the dead/not needed stuff away.

This makes no sense. I mean, why would anyone bother with playing with
systemd's binaries which (with the exceptio of s-d-v, see above) do not
increase your set of capabilities when executed, if you have /bin/sh
anyway which allows you to do whatever you want? If an attacker managed
to inject code in your system, then systemd's tools won't allow him to
do anything he couldn't do anyway, either directly with injected code or
by invoking /bin/sh and then continuing from there. Hence the attack
surface is not increased.

A problem would be tons of suid bianries, or binaries with fscaps. But
otherwise dead code lying around is no real additional security
threat. I am mostly interested in actual security measures, not security
theatre.

Lennart

-- 
Lennart Poettering, Red Hat
-- 
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: Orphaning java-1.5.0-gcj

[Florian Weimer]

On 04/07/2014 07:29 PM, Andrew Haley wrote:


As of JDK8, OpenJDK can be cross-compiled.  Not before time, either.


It seems to me that support is fairly limited—you cannot compile Hotspot 
across different operating systems, but perhaps across CPU architectures.


In the context of GCJ obsolescence, it might be good enough, but it's 
still a bit disappointing.


--
Florian Weimer / Red Hat Product Security Team
--
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: Deprecate setjmp/longjmp? [was Re: Maybe it's time to get rid of tcpwrappers/tcpd?]

[Eric Smith]

On Mon, Apr 28, 2014 at 2:24 AM, Florian Weimer  wrote:

> On 04/28/2014 09:52 AM, Nikos Mavrogiannopoulos wrote:
>
>  setjmp and longjmp are tools, that one may use in a good or bad way.
>> Along the same lines one could argue for dropping programs that use goto
>> in Fedora (because everyone knows that goto is bad).
>>
>
> All compliant uses of setjmp/longjmp can be replaced with C++ exceptions.
>

That might be true in C++, but it certainly isn't in C.
-- 
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: kernel packaging split up landing in Rawhide

[Josh Boyer]

On Wed, Apr 30, 2014 at 5:41 AM, Steven Whitehouse  wrote:
> Hi,
>
>
> On 29/04/14 22:41, Josh Boyer wrote:
>>
>> Hi All,
>>
>> As part of the F21 "Modular Kernel Packaging for Cloud" Feature[1],
>> I've committed and pushed the kernel packaging split up into
>> kernel-core and kernel-drivers subpackages.  For those of you running
>> rawhide, this really shouldn't be a major impact at all.  When you do
>> a yum update, you will see "kernel", "kernel-core", and
>> "kernel-drivers" packages being installed.  The end result should be
>> in line with today's rawhide kernels.
>>
>> Note: Unless you're using a typical VM or Cloud image, don't uninstall
>> the kernel or kernel-drivers packages.  The machine may boot with just
>> kernel-core, but it will lack drivers for a significant portion of
>> bare-metal hardware without kernel-drivers installed.
>>
>> Despite best efforts in testing, it's always possible a bug or two
>> snuck through.  In the event that you do have an issue with this,
>> please file a bug against the kernel package.
>>
>> josh
>>
>>
>> [1]https://fedoraproject.org/wiki/Changes/Modular_Kernel_Packaging_for_Cloud
>
>
> Just wondering how this will (or will not) affect kernel-module-extras ?

Great question.  It won't affect it.

> Currently there is a dependency (largely for backwards compatibility
> purposes) on kernel-module-extras from gfs2-utils and I'm wondering if that
> will need to be changed (or dropped) as a result of this,

Nothing at the moment.  Later this week I'm going to look at enabling
auto-provides for kernel modules in the various kernel packages.  This
will make situations like this much more flexible, as gfs2-utils will
be able to Requires: gfs2.ko (or whatever it is) instead of the
package name.  That will allow us to move modules around without
breaking packages, and potentially get ride of k-m-e down the road.

Once the auto-provides are enabled, I'll go through the tracker bug
Bruno has open and fix up the userspace package requires.

josh
-- 
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: kernel packaging split up landing in Rawhide

[Reindl Harald]

Am 29.04.2014 23:41, schrieb Josh Boyer:
> As part of the F21 "Modular Kernel Packaging for Cloud" Feature[1],
> I've committed and pushed the kernel packaging split up into
> kernel-core and kernel-drivers subpackages.  For those of you running
> rawhide, this really shouldn't be a major impact at all.  When you do
> a yum update, you will see "kernel", "kernel-core", and
> "kernel-drivers" packages being installed.  The end result should be
> in line with today's rawhide kernels.
> 
> Note: Unless you're using a typical VM or Cloud image, don't uninstall
> the kernel or kernel-drivers packages.  The machine may boot with just
> kernel-core, but it will lack drivers for a significant portion of
> bare-metal hardware without kernel-drivers installed.
> 
> Despite best efforts in testing, it's always possible a bug or two
> snuck through.  In the event that you do have an issue with this,
> please file a bug against the kernel package.
> 
> josh
> 
> [1]https://fedoraproject.org/wiki/Changes/Modular_Kernel_Packaging_for_Cloud

thank you - looks pretty fine for VMware guests

[root@rawhide ~]# rpm -qa | grep kernel
kernel-core-3.15.0-0.rc3.git1.10.fc21.x86_64

[root@rawhide ~]# lsmod
Module  Size  Used by
zram   19948  2
crct10dif_pclmul   14268  0
crc32_pclmul   13133  0
crc32c_intel   22094  0
vmw_balloon13487  0
ghash_clmulni_intel13230  0
vmxnet353723  0
vmw_pvscsi 27370  2

[root@rawhide ~]# df
Filesystem Type  Size  Used Avail Use% Mounted on
/dev/sdb1  ext4   12G  682M   11G   6% /
/dev/sda1  ext4  487M   37M  447M   8% /boot



signature.asc
Description: OpenPGP digital signature
-- 
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: Python 3.4 to rawhide

[Kalev Lember]

On 04/30/2014 12:22 PM, Matej Stuchlik wrote:
> Good day folks,
> Python 3.4 is now [ready and tagged] in f21-python, so I'd like to ask you
> to make whatever modifications that may be necessary and [rebuild] your
> Python packages into the tag. Once we have sufficient fraction up and running,
> we'll merge with rawhide.

This never works. You should request provenpackager permissions and
rebuild all the python3 using packages yourself.

-- 
Kalev

-- 
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: kernel packaging split up landing in Rawhide

[Bruno Wolff III]

On Wed, Apr 30, 2014 at 07:56:29 -0400,
  Josh Boyer  wrote:


Nothing at the moment.  Later this week I'm going to look at enabling
auto-provides for kernel modules in the various kernel packages.  This
will make situations like this much more flexible, as gfs2-utils will
be able to Requires: gfs2.ko (or whatever it is) instead of the
package name.  That will allow us to move modules around without
breaking packages, and potentially get ride of k-m-e down the road.

Once the auto-provides are enabled, I'll go through the tracker bug
Bruno has open and fix up the userspace package requires.


Thanks for this update. I was going to nag about this soon, if someone 
else hadn't.

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

poppler soname bump in rawhide

[Marek Kasik]

Hi,

I plan to rebase poppler in rawhide to poppler-0.26.0 at 12th of May.
There are several API changes.

I've prepared a scratch build of poppler-0.26.0 against which you can
test your packages. You can find the build here:

http://koji.fedoraproject.org/koji/taskinfo?taskID=6798518

and here:

http://mkasik.fedorapeople.org/poppler/

Regards

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

F21 Self Contained Change: The Shogun Machine Learning Toolbox

[Jaroslav Reznik]

= Proposed Self Contained Change: The Shogun Machine Learning Toolbox = 
https://fedoraproject.org/wiki/Changes/shogun

Change owner(s): Björn Esser 

SHOGUN is a large Scale Machine Learning Toolbox, being implemented in C++ and 
offering interfaces to C#, Java, Lua, Octave, Perl, Python, R and Ruby. 

== Detailed Description ==
* Homepage: The SHOGUN Machine Learning Toolbox [1]
* SCM-repo: on GitHub [2]
* Documentation: is available here [3]
* further Information: on Wikipedia [4]

The machine learning toolbox's focus is on large scale kernel methods and 
especially on Support Vector Machines (SVM). It provides a generic SVM object 
interfacing to several different SVM implementations, among them the state of 
the art LibSVM. Each of the SVMs can be combined with a variety of kernels. 
The toolbox not only provides efficient implementations of the most common 
kernels, like the Linear, Polynomial, Gaussian and Sigmoid Kernel but also 
comes with a number of recent string kernels as e.g. the Locality Improved, 
Fischer, TOP, Spectrum, Weighted Degree Kernel (with shifts). For the latter 
the efficient LINADD optimizations are implemented. Also SHOGUN offers the 
freedom of working with custom pre-computed kernels. One of its key features 
is the "combined kernel" which can be constructed by a weighted linear 
combination of a number of sub-kernels, each of which not necessarily working 
on the same domain. An optimal sub-kernel weighting can be learned using 
Multiple Kernel Learning. Currently SVM 2-class classification and regression 
problems can be dealt with. However SHOGUN also implements a number of linear 
methods like Linear Discriminant Analysis (LDA), Linear Programming Machine 
(LPM), (Kernel) Perceptrons and features algorithms to train hidden Markov-
models. The input feature-objects can be dense, sparse or strings and of type 
int/short/double/char and can be converted into different feature types. 
Chains of "pre-processors" (e.g. subtracting the mean) can be attached to each 
feature object allowing for on-the-fly pre-processing. 

== Scope ==
* Proposal owners: Create the rpm-spec and file a review bug. Have the package 
build after review was granted.
* 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) 

[1] http://shogun-toolbox.org/
[2] https://github.com/shogun-toolbox/shogun
[3] http://shogun-toolbox.org/doc/en/current/
[4] http://en.wikipedia.org/wiki/Shogun_%28toolbox%29
___
devel-announce mailing list
devel-annou...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel-announce
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

F21 Self Contained Change: MariaDB 10.0

[Jaroslav Reznik]

= Proposed Self Contained Change: MariaDB 10.0 = 
https://fedoraproject.org/wiki/Changes/MariaDB10

Change owner(s): Jakub Dorňák 

Update MariaDB to version 10.0 

== Detailed Description ==
MariaDB 10.0 is the current stable (GA) release of MariaDB. It is built on the 
MariaDB 5.5 series with backported features from MySQL 5.6 and entirely new 
features not found anywhere else.

The libraries provided by MariaDB 10.0 packages remain compatible. There is no 
need to rebuild other packages. 

== Scope ==
* Proposal owners: rebase MariaDB to version 10.0.10
* 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) 

There is no need to rebuild other packages. 

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

Re: F21 System Wide Change: Default Local DNS Resolver

[Simo Sorce]

On Wed, 2014-04-30 at 08:49 +0200, Alexander Larsson wrote:
> On tis, 2014-04-29 at 11:24 -0400, Simo Sorce wrote:
> > On Tue, 2014-04-29 at 17:15 +0200, Alexander Larsson wrote:
> > > On tis, 2014-04-29 at 14:15 +0200, Jaroslav Reznik wrote:
> > > > = Proposed System Wide Change:  Default Local DNS Resolver = 
> > > > https://fedoraproject.org/wiki/Changes/Default_Local_DNS_Resolver
> > > > 
> > > > Change owner(s): P J P , Pavel Šimerda 
> > > > , Tomas Hozza 
> > > > 
> > > > 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.
> > > 
> > > This is gonna conflict a bit with docker, and other  users of network
> > > namespaces, like systemd-nspawn. When docker runs, it picks up the
> > > current /etc/resolv.conf and puts it in the container, but the container
> > > itself runs in a network namespace, so it gets its own loopback device.
> > > This will mean 127.0.0.1:53 points to the container itself, not the
> > > host, so dns resolving in the container will not work.
> > > 
> > > Not sure how to fix something like that though...
> > 
> > Any way we can redirect the connection to the host ?
> > 
> > On the host we cannot listen on 0.0.0.0 so we cannot make unbound
> > available through normal routing on a different interface.
> > 
> > However we can perhaps make it listen on a special virtual interface
> > dedicated to let containers talk to other processes on the host maybe ?
> > (could even be other privileged containers). There is a question of what
> > addresses to use though ...
> 
> I don't see any nice way to make this "just work" in docker (i.e.
> without changes to docker). Docker as well as the host sets up
> 127.0.0.1/8 for the loopback device, so any 127.0.0.* will get routed to
> the local loopback. 

Yep, seen that.

> The only ways to have a ip available to both the host and the container
> are to either have a ip not in the 127.0.0.x range (thus this will be
> forwarded to the default gw, i.e. the host) or to set up some kind of
> forwarding of a port in 127.0.0.x (i.e. use iptables). The later needs
> to be done by docker, as its what sets up the network interfaces for the
> container.

I thought as much, would it be rally bad to have docker forward via
iptables ? I guess the question really is, *how* do you do that ?
The local resolver listend on 127.0.0.1:53 *only* on the host, so it is
not like we can use iptables to forward to a routable address. Although
clearly we are on the same machine ... but I guess iptables is
namespaced so the one configured in the container has no way to see the
host's loopback ?

> So, without changes to docker the option seems to be to set up another
> local interface with address range different than 127.0.0.1 and have the
> dns server listen to that.

And here comes the problem (actually 2)
1. the local caching resolver is meant to listen exclusively on
127.0.0.1:53 in the normal case, although I guess docker could be
allowed to poke at the configuration.
2. what address are you going to steal ? Just pull one out of the hat
like libvirt does for the default VMs network and just take possession
of another address in 192.168.X.0/24 ?

Sounds like we should try to define some "standard" network address to
do things like this instead, would it make sense to use the IPv4 network
some times ago microsoft bought and made available as a local collision
domain for these kind of things ?
They reserved the network in 169.254.0.0 as a local collision domain
where clients can auto-assign themselves an IP address and try to
communicate with neighbours in the same collision domain. I wonder if we
should perhaps hijack a subnet of that network, so we can avoid stealing
another /24 from 192.168 ?

Simo.

-- 
Simo Sorce * Red Hat, Inc * New York

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

Re: fedora-atomic discussion point: /usr/lib/passwd

[Colin Walters]

On Tue, Apr 29, 2014 at 11:23 PM, Simo Sorce  wrote:


can you use an actual chroot ?


Calling chroot tends to imply running code from the target system.  I'd 
prefer to avoid that by default.  In practice some things are going to 
require it, but the more we can avoid it, the better.



I am not sure I understand the fdatasync() argument here ?
sssd uses a database, so it is indeed probably "heavy" on f(data)sync
for your standards (?).


It's not about how heavy the use of fsync is - it's whether to do it at 
all.  There are two cases where we *don't* want to fsync - mock chroots 
and initial installs in Anaconda.  For the other cases, like upgrading 
a running system, we do.




-- 
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: We want to stop systemd from being added to docker images, because of rpm requiring systemctl.

[Daniel J Walsh]

On 04/29/2014 05:47 PM, Marcelo Ricardo Leitner wrote:
> Em 29-04-2014 18:27, Martin Langhoff escreveu:
>> On Tue, Apr 29, 2014 at 5:12 PM, Reindl Harald > > wrote:
>>
>> defense in depth means limit the attack surface as much as you can
>>
>>
>> As folks are trying to point out to you, these principles are well
>> understood in this group.
>>
>> However, _any minimally usable environment will have a scripting engine_
>> -- /bin/sh, python, and having _any_ of those general purpose tools
>> available is enough for the attacker.
>>
>> On your own machines, you might gain some (limited) advantage removing
>> some of them.
>>
>> Fedora and its derivatives, OTOH, are a large enough target that it's
>> worth for attackers to tailor attacks to it. So removing some tools
>> won't do much, and removing _all_ tools will ruin everyone's day.
>
> Hm? Okay, thread got long, but I don't recall anybody saying to remove
> scripting engines & etc. The point always was being able to have
> docker images without systemd, just because it's just not needed in
> there, and the thread got drifted away on 'may or not be a security
> liability'.
>
> It's part of getting Fedora somewhat optimized for containers.
>
> Anyway, sounds like we have even already agreed to remove the
> Requires, if I'm reading the thread correctly. So yeah, nothing much
> left to discuss in here ;)
>
> Cheers,
> Marcelo
>
I agree, where do I open a bugzilla to make this happen?  rpm?  Distro?
Systemd?
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Headsup: Ruby 2.1, Rubygems 2.2, Ruby on Rails 4.1 and Minitest 5.x in Rawhide

[Vít Ondruch]

Hi All,

During the last few days, we've been preparing a rebase to Ruby 2.1 in 
f21-ruby sidetag and it was just merged back to Rawhide. This rebase 
involves libruby soname bump. Updated Ruby carries RubyGems 2.2.


We've tried to rebuilt all binary packages, but some remaining - which 
were either more complex or already FTBFS - will need your attention. 
For changes in packaging, see this [1] draft (which is more or less 
approved [2], but not yet merged with official Ruby guidelines).


We also used this side-tag to build Ruby on Rails 4.1 and because of 
this, we were forced to update rubygem-minitest package [3].


If you need more help with your package, try to search answer to your 
issue via ruby-sig ML or you can contact directly me.



Vít



[1] https://fedoraproject.org/wiki/PackagingDrafts/Ruby
[2] https://fedorahosted.org/fpc/ticket/409
[3] 
https://lists.fedoraproject.org/pipermail/ruby-sig/2014-March/001522.html

[4] https://lists.fedoraproject.org/pipermail/ruby-sig/
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

[389-devel] Build failed in Jenkins: 389-ds-base #348

[jenkins]

See 

--
Started by an SCM change
Building remotely on Fedora20 in workspace 

Wiping out workspace first.
Cloning the remote Git repository
Cloning repository http://git.fedorahosted.org/git/389/ds.git/
Fetching upstream changes from http://git.fedorahosted.org/git/389/ds.git/
ERROR: Timeout after 10 minutes
ERROR: Error cloning remote repo 'origin'
hudson.plugins.git.GitException: Command "git fetch --tags --progress 
http://git.fedorahosted.org/git/389/ds.git/ 
+refs/heads/*:refs/remotes/origin/*" returned status code 143:
stdout: 
stderr: 
at 
org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommandIn(CliGitAPIImpl.java:1276)
at 
org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommandWithCredentials(CliGitAPIImpl.java:1146)
at 
org.jenkinsci.plugins.gitclient.CliGitAPIImpl.access$200(CliGitAPIImpl.java:87)
at 
org.jenkinsci.plugins.gitclient.CliGitAPIImpl$1.execute(CliGitAPIImpl.java:254)
at 
org.jenkinsci.plugins.gitclient.CliGitAPIImpl$2.execute(CliGitAPIImpl.java:410)
at 
org.jenkinsci.plugins.gitclient.RemoteGitImpl$CommandInvocationHandler$1.call(RemoteGitImpl.java:153)
at 
org.jenkinsci.plugins.gitclient.RemoteGitImpl$CommandInvocationHandler$1.call(RemoteGitImpl.java:146)
at hudson.remoting.UserRequest.perform(UserRequest.java:118)
at hudson.remoting.UserRequest.perform(UserRequest.java:48)
at hudson.remoting.Request$2.run(Request.java:328)
at 
hudson.remoting.InterceptingExecutorService$1.call(InterceptingExecutorService.java:72)
at java.util.concurrent.FutureTask.run(FutureTask.java:262)
at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at java.lang.Thread.run(Thread.java:744)
ERROR: null

--
389-devel mailing list
389-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-devel

Re: We want to stop systemd from being added to docker images, because of rpm requiring systemctl.

[Jóhann B. Guðmundsson]

On 04/30/2014 01:44 PM, Daniel J Walsh wrote:

I agree, where do I open a bugzilla to make this happen?  rpm?  Distro?
Systemd?


Dont you need to first file a change with FPC to the packaging guideline 
then file bug against every component that has that Require, then 
provide patches that remove it?


JBG
--
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: EPEL RFC: Strategy for python3 versions

[Pat Riehecky]

I wonder if the softwarecollections.org repos might be a better choice 
for this.  All the userspace tools already exist in 5, 6 and 7.


Pat

On 04/29/2014 08:22 PM, Orion Poplawski wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 04/29/2014 05:54 PM, Toshio Kuratomi wrote:

Hi guys,

Orion has submitted a python34 package for EPEL and I'm going to
review them soon if no one beats me to it.  In parallel with
getting that approved I'd like to ask about the general strategy
we'd like to take with maintaining python3 in EPEL.

Python3 is an evolving language.  New 3.N releases bring new
features, bugfixes, and both backwards compatibility breaking and
backwards compatibility enhancing changes (For instance, 3.3
brought the ability to mark regular text strings with the "u"
prefix to match with python2.x.  3.5 will bring back formatting
methods for byte strings.)

...


I'd like to propose that we attempt to maintain 2 python3 releases
at any one time.  We'll create python3.4 now.  When python3.5 comes
out in 18 months (less since python3.4 has been out for several
months), we'll package that in addition.  When python3.6 comes out
(3 years), we'll package that and retire python3.4.

Pluses: * This gives users some time to verify that their homegrown
applications continue to work with the newer python3 package that
we produce before the old one goes EOL. * This means that we're
only working on 3 versions of python3 at a time (the two we expect
users to use and the next version that we're tracking as upstream
works on finishing it). * This gives us a chance to update
frameworks, libraries, and other stacks of software built on top of
python3 at the same time as we create the new interpreter package.
So you could get python3.4 with Django-1.6.x  and you could get
python3.5 with Django-1.8.x

Negatives: * Users will have to reverify and port apps written
against python3 to the new interpreter version sometime in the 3
year lifespan of the python3 package they originally wrote it
against. * Package maintainers who are creating packages that run
on python3 will need to submit new packages for python3.4,
python3.5, etc. * Users may have to port to both new versions of
python3 and to new versions of some libraries they depend on
(because we took the opportunity to update those libraries for the
new python3 interpreter stack).

So, I want to be explicit as to how we handle python3 modules in EPEL.
  Originally I was hoping we could simply have python3.4 provide
python3 and maintainers could branch their current Fedora python
modules for epel7 and build as is resulting in python3-module packages
as in Fedora.

However, I don't see how we transition easily to the next python3
release.  I suppose we could do a side tag and rebuild everything then
have a flag day release.  Does this seem workable (I don't think so)?

If we're going to require having python34-module packages are we going
to require new reviews, or can we simply have people name them with
%package -n python34-module in the epel7 branch?  Would we have people
maintain multiple versions at a time in a package?  This seems like
the workable version.  I'm afraid that requiring new review all the
time will be a serious impediment.

We'll have %{__python34} etc macros then too.


Alternatives: * Never retire the python3 packages.  This leaves us
trying to support the release once upstream stops support.  Since
new python3 releases are in demand, we'd probably end up trying to
maintain all of the python3 releases that came out between when
RHEL-N was released and when RHEL-N+1 releases (because maintainer
focus usually shifts to building packages for RHEL-N+1 then). *
Retire the python3 packages when upstream stops support.  This
defers the pain for users (They can use a python3.N version for
about 5 years instead of about 3 years).  However, it means that
we're maintaining 4-5 versions of python3 at a time instead of 2-3


What do people think?  Is this something we can do within the
policies of EPEL?  Does it make sense to go forward with this?  Is
it better to go with one of the alternatives?

I like the plan of supporting 2 versions at a time.  I'm willing to
defer deciding on what the next version should be till later.  Perhaps
3.5 won't be all that compelling and we'll want to wait for 3.6.

Finally:
python34-3.4
or python3.4-3.4
or python-3.4-3.4
or python3-3.4-3.4?

Keep provides python(abi) = 3.4?

- -- 
Orion Poplawski

Technical Manager 303-415-9701 x222
NWRA/CoRA DivisionFAX: 303-415-9702
3380 Mitchell Lane  or...@cora.nwra.com
Boulder, CO 80301  http://www.cora.nwra.com
-BEGIN PGP SIGNATURE-
Version: GnuPG v1
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iEYEARECAAYFAlNgUFwACgkQORnzrtFC2/ujzQCguem5bziFQQZzn1WfLPZaPbuy
adMAoMOmF2Al81HWqxCFGYJgBr5UZcjZ
=OMyV
-END PGP SIGNATURE-
___
epel-devel mai

Re: F21 System Wide Change: Wayland

[Thorsten Leemhuis]

Hi!

Jaroslav Reznik wrote on 29.04.2014 14:04:
>
> Port the GNOME desktop to Wayland. 

Sorry, but what is actually proposed here? The above sentence for me
doesn't make any sense(¹), as Gnome 3.12 is able to run on Wayland
already (not perfectly, but it works afaik), so it was ported already
I'd say.

Is this about integrating this work in Fedora? Or more porting work? Or
even make Wayland the default in F21? The section "How To Test" sounds
as if the later is the case, but it's not entirely clear to me.

CU
knurd

(¹) This is not the first change proposal where the summary or the
"Detailed Description" is more confusing then helpful to me (which makes
me write this mail). It afaics would help a lot if those areas would use
words that ordinary people (think of people that have only basic
computer skills here) would be able to understand.


-- 
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: We want to stop systemd from being added to docker images, because of rpm requiring systemctl.

[Kalev Lember]

On 04/29/2014 12:31 PM, Lennart Poettering wrote:
> On Mon, 28.04.14 15:11, Toshio Kuratomi (a.bad...@gmail.com) wrote:
> 
>> On Apr 28, 2014 5:01 PM, "Daniel J Walsh"  wrote:
>>>
>>> The problem  is lots of services require systemd because they ship a
>>> unit file and want systemctl reload to happen.
>>
>> Would removing the requires on systemd and doing:
>>
>> /usr/bin/systemctl reload ||:
>>
>> Work for these cases?
> 
> Note that all the invocations of systemctl done by the systemd rpm
> macros are suffixed with ">/dev/null 2>&1 || :", as it is customary for
> rpm scriplets. Hence there's little to do really, except dropping the
> deps, and leaving everything else in place...

I suspect just dropping the deps would break initial installations, e.g.
anaconda / livecd-creator. RPM uses the deps to order the transaction so
that systemd gets installed first, and the packages that ship service
files get installed later. Without the deps, rpm wouldn't know the order
in which it has to run the transaction.

For example, when a package bar has a postinstall script that does:

systemctl enable bar.service >/dev/null 2>&1 || :

... but if systemctl gets installed _after_ foo in the same transaction,
then the systemctl command never runs and service stays disabled.


-- 
Kalev

P.S. Yes, this should really be 'systemctl preset', but I felt using
'systemctl enable' made the example easier to understand :)
-- 
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: We want to stop systemd from being added to docker images, because of rpm requiring systemctl.

[Daniel J Walsh]

On 04/30/2014 10:05 AM, Kalev Lember wrote:
> On 04/29/2014 12:31 PM, Lennart Poettering wrote:
>> On Mon, 28.04.14 15:11, Toshio Kuratomi (a.bad...@gmail.com) wrote:
>>
>>> On Apr 28, 2014 5:01 PM, "Daniel J Walsh"  wrote:
 The problem  is lots of services require systemd because they ship a
 unit file and want systemctl reload to happen.
>>> Would removing the requires on systemd and doing:
>>>
>>> /usr/bin/systemctl reload ||:
>>>
>>> Work for these cases?
>> Note that all the invocations of systemctl done by the systemd rpm
>> macros are suffixed with ">/dev/null 2>&1 || :", as it is customary for
>> rpm scriplets. Hence there's little to do really, except dropping the
>> deps, and leaving everything else in place...
> I suspect just dropping the deps would break initial installations, e.g.
> anaconda / livecd-creator. RPM uses the deps to order the transaction so
> that systemd gets installed first, and the packages that ship service
> files get installed later. Without the deps, rpm wouldn't know the order
> in which it has to run the transaction.
>
> For example, when a package bar has a postinstall script that does:
>
> systemctl enable bar.service >/dev/null 2>&1 || :
>
> .. but if systemctl gets installed _after_ foo in the same transaction,
> then the systemctl command never runs and service stays disabled.
>
>
Well you are never supposed to do this.  You are only supposed to do a
systemctl reload bar in a post install.  Any package that does do an
enable, should require systemd, as they are probably not candidates to
run in a container.
-- 
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: We want to stop systemd from being added to docker images, because of rpm requiring systemctl.

[Bruno Wolff III]

On Wed, Apr 30, 2014 at 16:05:37 +0200,
  Kalev Lember  wrote:


I suspect just dropping the deps would break initial installations, e.g.
anaconda / livecd-creator. RPM uses the deps to order the transaction so
that systemd gets installed first, and the packages that ship service
files get installed later. Without the deps, rpm wouldn't know the order
in which it has to run the transaction.

For example, when a package bar has a postinstall script that does:

   systemctl enable bar.service >/dev/null 2>&1 || :

... but if systemctl gets installed _after_ foo in the same transaction,
then the systemctl command never runs and service stays disabled.


Couldn't that be done post transaction, instead of post install?

When this is figured out, it would be nice to see the correct pattern 
be documented somewhere in the packing pages, similar to the documentation 
for icon cache updating 
(https://fedoraproject.org/wiki/Packaging:ScriptletSnippets?rd=Packaging/ScriptletSnippets#Icon_Cache).

--
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: We want to stop systemd from being added to docker images, because of rpm requiring systemctl.

[Adam Jackson]

On Wed, 2014-04-30 at 16:05 +0200, Kalev Lember wrote:

> I suspect just dropping the deps would break initial installations, e.g.
> anaconda / livecd-creator. RPM uses the deps to order the transaction so
> that systemd gets installed first, and the packages that ship service
> files get installed later. Without the deps, rpm wouldn't know the order
> in which it has to run the transaction.
> 
> For example, when a package bar has a postinstall script that does:
> 
> systemctl enable bar.service >/dev/null 2>&1 || :
> 
> ... but if systemctl gets installed _after_ foo in the same transaction,
> then the systemctl command never runs and service stays disabled.

If you are right, this is an argument for rpm collections, which we've
had for ages now and should really start using.

- ajax

-- 
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: Headsup: Ruby 2.1, Rubygems 2.2, Ruby on Rails 4.1 and Minitest 5.x in Rawhide

[Vít Ondruch]

Dne 30.4.2014 15:46, Vít Ondruch napsal(a):

Hi All,

During the last few days, we've been preparing a rebase to Ruby 2.1 in 
f21-ruby sidetag and it was just merged back to Rawhide. This rebase 
involves libruby soname bump. Updated Ruby carries RubyGems 2.2.


We've tried to rebuilt all binary packages, but some remaining - which 
were either more complex or already FTBFS - will need your attention. 
For changes in packaging, see this [1] draft (which is more or less 
approved [2], but not yet merged with official Ruby guidelines).


We also used this side-tag to build Ruby on Rails 4.1 and because of 
this, we were forced to update rubygem-minitest package [3].


If you need more help with your package, try to search answer to your 
issue via ruby-sig ML or you can contact directly me.



Vít



[1] https://fedoraproject.org/wiki/PackagingDrafts/Ruby
[2] https://fedorahosted.org/fpc/ticket/409
[3] 
https://lists.fedoraproject.org/pipermail/ruby-sig/2014-March/001522.html

[4] https://lists.fedoraproject.org/pipermail/ruby-sig/


I could also attach list of what was rebuild and what is pending, 
possibly some notes what may be wrong with the package:


http://piratepad.net/NWw7WqbvTb


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

[perl-qpid_proton/f20] (8 commits) ...Merge branch 'f20'

[Darryl L . Pierce]

Summary of changes:

  a0427c5... Changed the qpid-proton dependency to qpid-proton-c. (*)
  8cb9c27... Rebased on Proton 0.5. (*)
  0481900... Added the specific Perl provides for Proton. (*)
  9c5b0f5... Rebased on Qpid Proton 0.6. (*)
  ca5acb9... Merge branch 'f20' into f19 (*)
  91ae5ef... Merge branch 'f20' into f19 (*)
  f8e2dec... Rebased on Proton 0.7. (*)
  b94220d... Merge branch 'f20'

(*) 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-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel

Re: F21 System Wide Change: Wayland

[Jaroslav Reznik]

- Original Message -
> Hi!
> 
> Jaroslav Reznik wrote on 29.04.2014 14:04:
> >
> > Port the GNOME desktop to Wayland.
> 
> Sorry, but what is actually proposed here? The above sentence for me
> doesn't make any sense(¹), as Gnome 3.12 is able to run on Wayland
> already (not perfectly, but it works afaik), so it was ported already
> I'd say.
> 
> Is this about integrating this work in Fedora? Or more porting work? Or
> even make Wayland the default in F21? The section "How To Test" sounds
> as if the later is the case, but it's not entirely clear to me.
> 
> CU
> knurd
> 
> (¹) This is not the first change proposal where the summary or the
> "Detailed Description" is more confusing then helpful to me (which makes
> me write this mail). It afaics would help a lot if those areas would use
> words that ordinary people (think of people that have only basic
> computer skills here) would be able to understand.

I usually try to work with change owners on clear wording, sometimes it
works better, sometimes worst but that's why we have announcements in
place.

For wording - Changes are *not* supposed to be read by general public,
it's internal planning tool and docs/marketing guys makes it consumable
in the end. But generally I agree - better wording, better understanding.

Jaroslav

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

[perl-qpid_proton/f20: 8/8] Merge branch 'f20'

[Darryl L . Pierce]

commit b94220d367838d49f66b4995ec422414f6b5ad7b
Merge: f8e2dec 91ae5ef
Author: Darryl L. Pierce 
Date:   Wed Apr 30 10:36:02 2014 -0400

Merge branch 'f20'

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

Re: We want to stop systemd from being added to docker images, because of rpm requiring systemctl.

[Daniel J Walsh]

On 04/30/2014 10:28 AM, Adam Jackson wrote:
> On Wed, 2014-04-30 at 16:05 +0200, Kalev Lember wrote:
>
>> I suspect just dropping the deps would break initial installations, e.g.
>> anaconda / livecd-creator. RPM uses the deps to order the transaction so
>> that systemd gets installed first, and the packages that ship service
>> files get installed later. Without the deps, rpm wouldn't know the order
>> in which it has to run the transaction.
>>
>> For example, when a package bar has a postinstall script that does:
>>
>> systemctl enable bar.service >/dev/null 2>&1 || :
>>
>> ... but if systemctl gets installed _after_ foo in the same transaction,
>> then the systemctl command never runs and service stays disabled.
> If you are right, this is an argument for rpm collections, which we've
> had for ages now and should really start using.
>
> - ajax
>
Created a ticket.

https://fedorahosted.org/fpc/ticket/425

Next I will create a change request if the ticket is approved.


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

Schedule for Wednesday's FESCo Meeting (2014-04-30)

[Dennis Gilmore]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

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

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

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


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

= Followups =

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

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

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

#topic #1291 F21 System Wide Change: BerkeleyDB 6 -
https://fedoraproject.org/wiki/Changes/BerkeleyDB_6
.fesco 1291
https://fedorahosted.org/fesco/ticket/1291


= Open Floor = 

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

If you would like to add something to this agenda, you can reply to
this e-mail, file a new ticket at https://fedorahosted.org/fesco,
e-mail me directly, or bring it up at the end of the meeting, during
the open floor topic. Note that added topics may be deferred until
the following meeting. 
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (GNU/Linux)

iQIcBAEBAgAGBQJTYQ05AAoJEH7ltONmPFDR2SIQAKr4T0vIPkBATWfjw32lIRKm
2fD4PMgogm1+iaRzY/fr061E1MFzXyT1/9Umd4qtoww3gJp82AAzmJtO0qN8b6Ae
s2OGrLbR9zpo3BrSAXttam1A7UEDdde0SH1qCAAN02BjsKj7lqwdtpn1STgf2xfE
N75ASdLdUsHoRm3y1bwXIRZnVElE62HKIEKEoTUyaI6eIu1TqQtEj8S0yqC/56Gb
NnROWbnOFrZ6xWMgFvlpXOuPDWgEo4kvzTiihvFIJ2bBrGKxcIFOhANmTg7KZqch
N33VpylvPD5XsbbUTYk/bQBPMDUwKQVnFjzbTmr912fFrQkdRtqjFBvWftEXXTuo
n1LwXlA/1lwRUUKhNMDD8zh32pACr9ihGKu/adWNa8erq61gA5kaeOcDpzijvO6j
N+kN7rDQYhH3yyNbsrvbA1shdwZITR1jnpsydX7fZR4DAJhwJFInJ8B3rtn3dqA8
eXeeu9q2o3AByeTfkq3pTZI9fsFG2lwBnmBFIc5nk0TImVI85CV8skqOtXIn6pcB
1vNWzw6je9t/X1eV4slRmXN7dBLhJ1z91tgbnuTLweIBcN05Wsz6SvVU3YDTJpwK
83NNlLVVvTnwGHC+pQjMil08wEZ2boeNUn6DMOYbcHxllDoGEyBY+mjO4IF43U8E
miLTN+9em84f/49f+SnE
=K7M8
-END PGP SIGNATURE-
-- 
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: We want to stop systemd from being added to docker images, because of rpm requiring systemctl.

[Kalev Lember]

On 04/30/2014 04:28 PM, Adam Jackson wrote:
> If you are right, this is an argument for rpm collections, which we've
> had for ages now and should really start using.

YES!

Getting rid of the copy-pasted rpm scriptlets would be a huge win. They
are error prone and require huge effort to get them right and up to date
across the whole distro.

dpkg has had support for triggers for quite some time and the rpm world
is really lagging behind here.

https://wiki.debian.org/DpkgTriggers

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

Re: fedora-atomic discussion point: /usr/lib/passwd

[Simo Sorce]

On Wed, 2014-04-30 at 13:25 +, Colin Walters wrote:
> On Tue, Apr 29, 2014 at 11:23 PM, Simo Sorce  wrote:
> > 
> > can you use an actual chroot ?
> 
> Calling chroot tends to imply running code from the target system.  I'd 
> prefer to avoid that by default.  In practice some things are going to 
> require it, but the more we can avoid it, the better.

ok so the point you are making is that you'd want a way to just write
out a file on your own and have whatever mechanism provides users to the
system load it at the next startup and blow away the previous data ?

> > I am not sure I understand the fdatasync() argument here ?
> > sssd uses a database, so it is indeed probably "heavy" on f(data)sync
> > for your standards (?).
> 
> It's not about how heavy the use of fsync is - it's whether to do it at 
> all.  There are two cases where we *don't* want to fsync - mock chroots 
> and initial installs in Anaconda.  For the other cases, like upgrading 
> a running system, we do.

Ok, understood, the above mechanism I described would be your favorite
way to avoid syncs ?

Simo.

-- 
Simo Sorce * Red Hat, Inc * New York

-- 
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: We want to stop systemd from being added to docker images, because of rpm requiring systemctl.

[Kalev Lember]

On 04/30/2014 04:24 PM, Daniel J Walsh wrote:
> On 04/30/2014 10:05 AM, Kalev Lember wrote:
>> For example, when a package bar has a postinstall script that does:
>>
>> systemctl enable bar.service >/dev/null 2>&1 || :
>>
>> .. but if systemctl gets installed _after_ foo in the same transaction,
>> then the systemctl command never runs and service stays disabled.
>>
>>
> Well you are never supposed to do this.  You are only supposed to do a
> systemctl reload bar in a post install.

No, pretty much all packages that install systemd unit files run either
'systemctl enable' or 'systemd preset' in %post. The latter is just
'systemd enable' wrapped in layer of indirection, that depending on
installed configuration either enables or disables the unit file.

The macro that systemd ships for postinstall and packages are supposed
to run, is %systemd_post. That expands to a 'systemctl enable' equivalent:

$ rpm -E %systemd_post

if [ $1 -eq 1 ] ; then
# Initial installation
/usr/bin/systemctl preset  >/dev/null 2>&1 || :
fi


> Any package that does do an enable, should require systemd, as they
> are probably not candidates to run in a container.

Right. And enable ~= %systemd_post, which is why packages that use this
macro currently have Requires(post) on systemd.

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

Re: F21 System Wide Change: Wayland

[Thorsten Leemhuis]

Hi!

Jaroslav Reznik wrote on 30.04.2014 16:27:
> - Original Message -
>> Jaroslav Reznik wrote on 29.04.2014 14:04:
>> > Port the GNOME desktop to Wayland.
>> 
>> Sorry, but what is actually proposed here? The above sentence for me
>> doesn't make any sense(¹), as Gnome 3.12 is able to run on Wayland
>> already (not perfectly, but it works afaik), so it was ported already
>> I'd say.
>> 
>> Is this about integrating this work in Fedora? Or more porting work? Or
>> even make Wayland the default in F21? The section "How To Test" sounds
>> as if the later is the case, but it's not entirely clear to me.
>>
>> (¹) This is not the first change proposal where the summary or the
>> "Detailed Description" is more confusing then helpful to me (which makes
>> me write this mail). It afaics would help a lot if those areas would use
>> words that ordinary people (think of people that have only basic
>> computer skills here) would be able to understand.
> 
> I usually try to work with change owners on clear wording,

I know. Many thanks for all your hard work.

> […]

> For wording - Changes are *not* supposed to be read by general public,

But we know the public reads them, as those that write websites, blogs
and sometimes even magazines articles will pick these things up --
especially in cases like this. Unclear words or statements thus could
lead to confusion or bad press.

Side note: "If you can't explain it simply, you don't understand it well
enough."

> it's internal planning tool and docs/marketing guys makes it consumable
> in the end.

Thus FESCo, ordinary developers like me (we get these change propose
mails for a reason) and docs/marketing should be able to properly
understand it -- which afaics to often is not the case :-/

> But generally I agree - better wording, better understanding.

+1

CU
knurd
-- 
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: We want to stop systemd from being added to docker images, because of rpm requiring systemctl.

[Jóhann B. Guðmundsson]

On 04/30/2014 02:52 PM, Kalev Lember wrote:

On 04/30/2014 04:28 PM, Adam Jackson wrote:

If you are right, this is an argument for rpm collections, which we've
had for ages now and should really start using.

YES!

Getting rid of the copy-pasted rpm scriptlets would be a huge win. They
are error prone and require huge effort to get them right and up to date
across the whole distro.

dpkg has had support for triggers for quite some time and the rpm world
is really lagging behind here.

https://wiki.debian.org/DpkgTriggers



Can packaging noobs get any doc reference on how to implement these 
collection and if the case is we have had them for a long time why did 
we never start using them?


JBG
--
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: We want to stop systemd from being added to docker images, because of rpm requiring systemctl.

[Richard Hughes]

On 30 April 2014 15:52, Kalev Lember  wrote:
> Getting rid of the copy-pasted rpm scriptlets would be a huge win.

Totally agree. We should make this happen. SUSE has been doing it for years.

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

Re: Schedule for Wednesday's FESCo Meeting (2014-04-30)

[Matthew Miller]

I've got a conflicting meeting and will probably show up late -- sorry for
the late notice.

-- 
Matthew Miller--   Fedora Project--
  "Tepid change for the somewhat better!"
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Schedule for Wednesday's FESCo Meeting (2014-04-30)

[Stephen Gallagher]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 04/30/2014 12:04 PM, Matthew Miller wrote:
> I've got a conflicting meeting and will probably show up late --
> sorry for the late notice.
> 

I also have a conflicting meeting and will be an hour late.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iEYEARECAAYFAlNhIiIACgkQeiVVYja6o6OiCwCdFdPAQ4F7wYoyErD+yWfULkfU
Kk0An1Ppe9a0dHYc9xKR/asbE+a8U4Rl
=OeEg
-END PGP SIGNATURE-
-- 
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: We want to stop systemd from being added to docker images, because of rpm requiring systemctl.

[Chuck Anderson]

On Wed, Apr 30, 2014 at 10:28:56AM -0400, Adam Jackson wrote:
> On Wed, 2014-04-30 at 16:05 +0200, Kalev Lember wrote:
> 
> > I suspect just dropping the deps would break initial installations, e.g.
> > anaconda / livecd-creator. RPM uses the deps to order the transaction so
> > that systemd gets installed first, and the packages that ship service
> > files get installed later. Without the deps, rpm wouldn't know the order
> > in which it has to run the transaction.
> > 
> > For example, when a package bar has a postinstall script that does:
> > 
> > systemctl enable bar.service >/dev/null 2>&1 || :
> > 
> > ... but if systemctl gets installed _after_ foo in the same transaction,
> > then the systemctl command never runs and service stays disabled.
> 
> If you are right, this is an argument for rpm collections, which we've
> had for ages now and should really start using.

What are "rpm collections" and how do they relate to "software
collections"?  How does this solve the package installation order
without dependencies?  It is hard to find anything useful by searching
for "rpm collections".
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: F21 System Wide Change: Default Local DNS Resolver

[Petr Spacek]

On 30.4.2014 15:29, Simo Sorce wrote:

On Wed, 2014-04-30 at 08:49 +0200, Alexander Larsson wrote:

On tis, 2014-04-29 at 11:24 -0400, Simo Sorce wrote:

On Tue, 2014-04-29 at 17:15 +0200, Alexander Larsson wrote:

On tis, 2014-04-29 at 14:15 +0200, Jaroslav Reznik wrote:

= Proposed System Wide Change:  Default Local DNS Resolver =
https://fedoraproject.org/wiki/Changes/Default_Local_DNS_Resolver

Change owner(s): P J P , Pavel Šimerda
,   Tomas Hozza 

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.


This is gonna conflict a bit with docker, and other  users of network
namespaces, like systemd-nspawn. When docker runs, it picks up the
current /etc/resolv.conf and puts it in the container, but the container
itself runs in a network namespace, so it gets its own loopback device.
This will mean 127.0.0.1:53 points to the container itself, not the
host, so dns resolving in the container will not work.

Not sure how to fix something like that though...


Any way we can redirect the connection to the host ?

On the host we cannot listen on 0.0.0.0 so we cannot make unbound
available through normal routing on a different interface.

However we can perhaps make it listen on a special virtual interface
dedicated to let containers talk to other processes on the host maybe ?
(could even be other privileged containers). There is a question of what
addresses to use though ...


I don't see any nice way to make this "just work" in docker (i.e.
without changes to docker). Docker as well as the host sets up
127.0.0.1/8 for the loopback device, so any 127.0.0.* will get routed to
the local loopback.


Yep, seen that.


The only ways to have a ip available to both the host and the container
are to either have a ip not in the 127.0.0.x range (thus this will be
forwarded to the default gw, i.e. the host) or to set up some kind of
forwarding of a port in 127.0.0.x (i.e. use iptables). The later needs
to be done by docker, as its what sets up the network interfaces for the
container.


I thought as much, would it be rally bad to have docker forward via
iptables ? I guess the question really is, *how* do you do that ?
The local resolver listend on 127.0.0.1:53 *only* on the host, so it is
not like we can use iptables to forward to a routable address. Although
clearly we are on the same machine ... but I guess iptables is
namespaced so the one configured in the container has no way to see the
host's loopback ?


So, without changes to docker the option seems to be to set up another
local interface with address range different than 127.0.0.1 and have the
dns server listen to that.


And here comes the problem (actually 2)
1. the local caching resolver is meant to listen exclusively on
127.0.0.1:53 in the normal case, although I guess docker could be
allowed to poke at the configuration.
2. what address are you going to steal ? Just pull one out of the hat
like libvirt does for the default VMs network and just take possession
of another address in 192.168.X.0/24 ?

Sounds like we should try to define some "standard" network address to
do things like this instead, would it make sense to use the IPv4 network
some times ago microsoft bought and made available as a local collision
domain for these kind of things ?
They reserved the network in 169.254.0.0 as a local collision domain
where clients can auto-assign themselves an IP address and try to
communicate with neighbours in the same collision domain. I wonder if we
should perhaps hijack a subnet of that network, so we can avoid stealing
another /24 from 192.168 ?


IMHO we should consider approaches including Docker modification.

There has to be an ability to allow communication between containers (Apache 
in one container and MySQL in second container).


Maybe with some slight modification it could route 127.255.255.254 to it's 
"hypervisor". It could be even optional...


Other obvious approach is to allow Docker to use different /etc/resolv.conf 
inside container (but still configured from outside of the container).


(Yes, it doesn't work today. It doesn't mean that it can't work in future.)

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

Re: F21 System Wide Change: Default Local DNS Resolver

[Robert Marcano]

On 04/30/2014 01:17 AM, P J P wrote:

On Wednesday, 30 April 2014 3:18 AM, Al Dunsmuir wrote:
On my home LAN, I run my own DNSSEC-enabled server using F20 & bind 9.
This  local server also is my DHCP and Samba server. As usual, dynamic
clients  receive  the  LAN  local  domain  ID  and  DNS  server  ID
automatically.

How  does  this  proposed  change  affect my clients, or especially my
server  (which  uses  NetworkManager  (not  Network),  and a static IP
address?


   This should work just fine. If you upgrade your F20 machine to say F22, it 
would have the default resolver running on 127.0.0.1:53 with its entry in 
'/etc/resolv.conf'. One change you would need to do is to make it listen on 
0.0.0.0:53 or the on static IP address of your server. Your clients won't know 
that they are talking to a different DNS resolver.

If your clients are upgraded to F22, NetworkManager there would make the local 
resolver talk to the one on your server, because it'll receive that name server 
configuration via DHCP.


I think the parent post is refering to the local domain name, I have 
read this thread and people talk about not touching ever the resolv.conf 
file. What about domain and search lines? If NetworkManager will always 
use 127.0.0.1, it should still modify resolv.conf with the domain name 
received from DHCP





As  nice  as  unbound  may  be,  documentation and configuration files
related to this change should not assume it is the only DNS server for
Fedora.


   Nope, we don't assume that. In fact it's been discussed earlier
here -> https://lists.fedoraproject.org/pipermail/devel/2014-April/198620.html

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



--
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: We want to stop systemd from being added to docker images, because of rpm requiring systemctl.

[Adam Jackson]

On Wed, 2014-04-30 at 12:34 -0400, Chuck Anderson wrote:
> On Wed, Apr 30, 2014 at 10:28:56AM -0400, Adam Jackson wrote:
> > On Wed, 2014-04-30 at 16:05 +0200, Kalev Lember wrote:
> > > For example, when a package bar has a postinstall script that does:
> > > 
> > > systemctl enable bar.service >/dev/null 2>&1 || :
> > > 
> > > ... but if systemctl gets installed _after_ foo in the same transaction,
> > > then the systemctl command never runs and service stays disabled.
> > 
> > If you are right, this is an argument for rpm collections, which we've
> > had for ages now and should really start using.
> 
> What are "rpm collections"

Scriptlets bound to a directory instead of a package's %post.

> and how do they relate to "software collections"?

They don't.

> How does this solve the package installation order without dependencies?

Since the collection action runs for any transaction element that
affects the collection directory, you just need to pile up touch files
that say to enable a service, and the action will eventually run once
systemctl exists.  (Roughly speaking; probably we could make it cleaner
than that.  Collections seem only to implement "every package" hooks
atm, but for things like fonts it might be reasonable to just run the
hook analogously to %posttrans rather than analogously to %post.)

> It is hard to find anything useful by searching for "rpm collections".

Yeah, they're not well documented yet.  Luckily I was able to track down
a copy of the rpm source so I could read how it works.

The other downside is they're new in rpm 4.9, and RHEL6 only has 4.8, so
there's a spec portability problem for EPEL6.

- ajax

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

Re: F21 System Wide Change: Default Local DNS Resolver

[Paul Wouters]

On Wed, 30 Apr 2014, Robert Marcano wrote:

What about domain and search lines? If NetworkManager will always use 
127.0.0.1, it should still modify resolv.conf with the domain name received 
from DHCP


That's actually not always correct from a security point of view.

If you set your system do have domain "nohats.ca", and you "ssh bofh"
and then some DHCP changes the domain/search list, you might not be
going where you think you are going.

IMHO, DHCP should never touch the domain or search list _unless_ you are
connecting to a trusted network - where trusted for practical reasons is
defined as "you plug in a wire or use a wifi WPA secret to connect".

No open wifi should ever modify your search list. If it does that now,
it is a security bug.

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

Summary/Minutes from today's FESCo Meeting (2014-04-30)

[Dennis Gilmore]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

===
#fedora-meeting: FESCO (2014-04-30)
===


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



Meeting summary
- ---
* init process  (dgilmore, 17:01:20)

* #1221 Product working group activity reports  (dgilmore, 17:03:55)
  * LINK: https://fedorahosted.org/fesco/ticket/1221   (dgilmore,
17:03:56)

* #1244 F21 System Wide Change: cron to systemd time units -
  https://fedoraproject.org/wiki/Changes/cron-to-systemd-time-units
  (dgilmore, 17:05:23)
  * LINK: https://fedorahosted.org/fesco/ticket/1244   (dgilmore,
17:05:28)

* #1250 F21 Self Contained Changes  (dgilmore, 17:06:43)
  * LINK: https://fedorahosted.org/fesco/ticket/1250   (dgilmore,
17:06:45)
  * ACTION: remote journal needs concerns/questions to be raised with
the change owner  (dgilmore, 17:09:12)
  * ACTION: nirik to follow up with change owner about
default/recommended  (dgilmore, 17:11:41)

* #1291 F21 System Wide Change: BerkeleyDB 6 -
  https://fedoraproject.org/wiki/Changes/BerkeleyDB_6  (dgilmore,
  17:12:15)
  * LINK: https://fedorahosted.org/fesco/ticket/1291   (dgilmore,
17:12:20)
  * ACCEPTED: BerkeleyDB 6 change is accepted (with the agreed plan to
ensure every package is reviewed) (+5,0,0)  (dgilmore, 17:18:49)

* open floor  (dgilmore, 17:19:59)

* Next week's chair  (dgilmore, 17:29:55)
  * ACTION: mitr to chair next week  (dgilmore, 17:35:14)

* Open Floor  (dgilmore, 17:35:52)

Meeting ended at 17:37:39 UTC.




Action Items
- 
* remote journal needs concerns/questions to be raised with the change
  owner
* nirik to follow up with change owner about default/recommended
* mitr to chair next week




Action Items, by person
- ---
* mitr
  * mitr to chair next week
* nirik
  * nirik to follow up with change owner about default/recommended
* **UNASSIGNED**
  * remote journal needs concerns/questions to be raised with the change
owner




People Present (lines said)
- ---
* dgilmore (60)
* nirik (25)
* Viking-Ice (24)
* abadger1999 (15)
* mitr (14)
* zodbot (10)
* pjones (2)
* notting (1)
* sgallagh (0)
* mattdm (0)
* t8m (0)
* jwb (0)
* mmaslano (0)




Generated by `MeetBot`_ 0.1.4

.. _`MeetBot`: http://wiki.debian.org/MeetBot
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (GNU/Linux)

iQIcBAEBAgAGBQJTYTVFAAoJEH7ltONmPFDRXuEP/1vs3d+OIUMt0k0j9JTPKIwW
tVx3/hWwbPWoiBxoDC/42k2PZ4BX5lnGFZVis5pxzD14sXKZBc7RrgD85mkJ3lMm
KjpDloFKFqwENMbv7u/ukfh6lriLvtU/rqDPUdPTRd6MKEB5Sd+HIgwY04J/D26M
7XEraw8Kr/SR85T7IgdVIrLMRYOw+GVmfcibMdZ07OdQG1QqiNyiuQz6Y+RZkOqV
mxD8ORfUNsXkSZCRCTkfpRNKftJ4OA7nrtHvDA0/99vdWi3N8e2isLnxBKwexB5x
AHYYircDaEaNpHQgatBtT6hL4zQnEhCmarb8XTqhhQaIc0EkqD7JKY9Q90YdCd4G
72ACmAZjMMr8i4Tn5KlLyKXXNXo7aijPt728aFewmABm4mda9BDui+bEkFRZ8JKw
tIUbajEYikWGEsDGkXKpH1CexxYaPZw2YKSfnMkf3JLaaWw35s68EQEtP4O+zHFw
1B9kjOjZxx0RAMZmyPC5HWs/B6BLTJ9scFW4yj+MyKEk5ECLw8TtLca3SKypf6zK
RLXs2GQT2vt3IUjBm+pJ/7J1DAhRSC2VlGATsWzw95nTLqemG1i5hTNP41vk7PmF
zqQbRsbNs8gdqbIpK3dKrLILqdR84RUjWnFzAl9faLkYGc0HCJ5WtPm4roWQfg5Q
yu+46QyOWV3u2WK/MC9x
=Y6n9
-END PGP SIGNATURE-
-- 
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: Mass bug: packages should not auto-enable systemd units

[Andrew Lutomirski]

Due to some confusion around how alternatives worked, I screwed up the
list of packages here.  I've updated it below.  I'll give it a few
more days before filing the actual bugs.

On Wed, Apr 23, 2014 at 4:59 PM, Andrew Lutomirski  wrote:
> Hi everyone-
>
> This is a notice in accordance with the mass bug filing procedure.
>
> A number of packages install systemd units and enable them
> automatically.  They should not.  Please update these packages to use the
> macroized scriptlet
> (https://fedoraproject.org/wiki/Packaging:ScriptletSnippets#Systemd).
>
> If your package has an exception from FESCo permitting it to enable
> itself, please make sure that the service in question is listed in the
> appropriate preset file.
>
> There is a general exception described here:
>
> https://fedoraproject.org/wiki/Starting_services_by_default
>
> If your package falls under the general exception, then it is possible
> that no change is required.  Nevertheless, if you are relying on the
> exception, please make sure that your rpm scripts are sensible.  The
> exception is:
>
> In addition, any service which does not remain persistent on the
> system (aka, it "runs once then goes away"), does not listen to
> incoming connections during initialization, and does not require
> configuration to be functional may be enabled by default (but is not
> required to do so). An example of "runs once then goes away" service
> is iptables.
>
> Given that this issue can affect Fedora 20 users who install your
> package as a dependency, these bugs should be fixed in Fedora 20 and
> Rawhide.
>
> The tracker bug is here:
>
> https://bugzilla.redhat.com/show_bug.cgi?id=1090684
>
> I created it early because three of the bugs are pre-existing.  Next
> week, I'll file bugs against the packages below.  If you fix your
> package in the mean time, please let me know.
>
> After three weeks, provenpackagers may step in and fix these issues.
>

abrt
acpid
aeolus-audrey-agent
aeolus-configserver
audit
avahi
bluez
bootchart
cherokee
cloud-init
deltacloud-core
dmapd
dnssec-trigger
glusterfs
gnome-initial-setup
gpsd
ipmiutil
iptables
kexec-tools
libstoragemgmt
libvirt
lttng-tools
monit
NetworkManager
nfs-utils
nss-pam-ldapd
olpc-kbdshim
olpc-powerd
openct
pcsc-lite
qemu
qpid-cpp
rootfs-resize
rpcbind
sendmail
soundmodem
spacenavd
subscription-manager
supervisor
systemd
targetcli
util-linux
vdsm
xen

--Andy
___
devel-announce mailing list
devel-annou...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel-announce
-- 
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: Mass bug: packages should not auto-enable systemd units

[Richard Shaw]

On Wed, Apr 30, 2014 at 11:02 AM, Andrew Lutomirski  wrote:

> spacenavd
>
> Right or wrong, the decision for enabling spacenavd by default is that you
would only install the package if you have one of these devices. Nothing
should be pulling it in so it needs to be explicitly installed by the user.

Richard
-- 
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: Mass bug: packages should not auto-enable systemd units

[Rahul Sundaram]

Hi


On Wed, Apr 30, 2014 at 1:53 PM, Richard Shaw wrote:

> On Wed, Apr 30, 2014 at 11:02 AM, Andrew Lutomirski wrote:
>
>> spacenavd
>>
>> Right or wrong, the decision for enabling spacenavd by default is that
> you would only install the package if you have one of these devices.
> Nothing should be pulling it in so it needs to be explicitly installed by
> the user.
>
> The control for enabling the service by default should be part of the
preset to allow for admin customization easily and it would need FESCo to
approve it.  Maintainers cannot decide that for themselves according to the
current Fedora policy

Rahul
-- 
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: We want to stop systemd from being added to docker images, because of rpm requiring systemctl.

[Colin Walters]

On Wed, Apr 30, 2014 at 1:14 PM, Adam Jackson  wrote:


 It is hard to find anything useful by searching for "rpm 
collections".


Yeah, they're not well documented yet.  Luckily I was able to track 
down

a copy of the rpm source so I could read how it works.


"In an industry wrought with broken promises and broken relationships, 
RPM provides a refreshing and intelligent alternative to our clients. 
We start by applying our intellectual capital and analytical insight to 
your entire receivables process..."


Oh!  Different RPM collections...
-- 
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: Mass bug: packages should not auto-enable systemd units

[Richard Shaw]

On Wed, Apr 30, 2014 at 12:58 PM, Rahul Sundaram  wrote:

> Hi
> On Wed, Apr 30, 2014 at 1:53 PM, Richard Shaw wrote:
>
> On Wed, Apr 30, 2014 at 11:02 AM, Andrew Lutomirski wrote:
>>
>>> spacenavd
>>>
>>> Right or wrong, the decision for enabling spacenavd by default is that
>> you would only install the package if you have one of these devices.
>> Nothing should be pulling it in so it needs to be explicitly installed by
>> the user.
>>
>> The control for enabling the service by default should be part of the
> preset to allow for admin customization easily and it would need FESCo to
> approve it.  Maintainers cannot decide that for themselves according to the
> current Fedora policy
>
> The guidelines still allow it as no direct configuration is required
except for legacy serial devices, USB devices work fine out of the box.

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

Re: F21 Self Contained Change: Remote Journal Logging

[Kevin Fenzi]

So, this change went to fesco last week, but there were some
questions/issues around it. Could change owners respond to: 

1) sgallagh wasn't sure this was a self contained change: 
see: https://fedorahosted.org/fesco/ticket/1250#comment:19

2) FESCo in general wondered if we advertised this as a change if
people would see it as the recommended/default way to handle remote
system logs. Is it planned to be that, or is it just a 'here's a
preview of how we hope to do this down the road'?

3) There were general concerns around the protocol/setup... but I think
those were raised before in this thread. Is there any revisiting of the
protocol/etc planned? Or things are pretty set at this point?

kevin


signature.asc
Description: PGP signature
-- 
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: Mass bug: packages should not auto-enable systemd units

[Andrew Lutomirski]

On Wed, Apr 30, 2014 at 11:06 AM, Richard Shaw  wrote:
> On Wed, Apr 30, 2014 at 12:58 PM, Rahul Sundaram  wrote:
>>
>> Hi
>> On Wed, Apr 30, 2014 at 1:53 PM, Richard Shaw wrote:
>>
>>> On Wed, Apr 30, 2014 at 11:02 AM, Andrew Lutomirski wrote:

 spacenavd

>>> Right or wrong, the decision for enabling spacenavd by default is that
>>> you would only install the package if you have one of these devices. Nothing
>>> should be pulling it in so it needs to be explicitly installed by the user.
>>>
>> The control for enabling the service by default should be part of the
>> preset to allow for admin customization easily and it would need FESCo to
>> approve it.  Maintainers cannot decide that for themselves according to the
>> current Fedora policy
>>
> The guidelines still allow it as no direct configuration is required except
> for legacy serial devices, USB devices work fine out of the box.

I think you're right as long as no network sockets are involved.

Does that exception include UNIX sockets?

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

Schedule for Thursday's FPC Meeting (2014-05-01 16:00 UTC)

[James Antill]

Following is the list of topics that will be discussed in the FPC
meeting Thursday at 2014-05-01 16:00 UTC in #fedora-meeting-1 on
irc.freenode.net.

 Local time information (via. rktime):

2014-05-01 09:00 Thu US/Pacific PDT
2014-05-01 12:00 Thu US/Eastern EDT
2014-05-01 16:00 Thu UTC <-
2014-05-01 17:00 Thu Europe/London  BST
2014-05-01 18:00 Thu Europe/Paris  CEST
2014-05-01 18:00 Thu Europe/Berlin CEST
2014-05-01 21:30 Thu Asia/Calcutta  IST
--new day--
2014-05-02 00:00 Fri Asia/Singapore SGT
2014-05-02 00:00 Fri Asia/Hong_Kong HKT
2014-05-02 01:00 Fri Asia/Tokyo JST
2014-05-02 02:00 Fri Australia/Brisbane EST

 Links to all tickets below can be found at: 

https://fedorahosted.org/fpc/report/12

= Followups =

(approval and retirement sections already passed, /opt exception passed)
#topic #339 software collections in Fedora
.fpc 339
https://fedorahosted.org/fpc/ticket/339

#topic #382 Go Packaging Guidelines Draft
.fpc 382
https://fedorahosted.org/fpc/ticket/382

#topic #400 Exception for bundled library FoX in exciting
.fpc 400
https://fedorahosted.org/fpc/ticket/400

(remaining votes needed)
#topic #407 Bundled lib exception request (copylibs) for sha1
bundled with apt-cacher-ng
.fpc 407
https://fedorahosted.org/fpc/ticket/407

(remaining votes needed)
#topic #408 Temporary jquery bundling exception for libserialport
.fpc 408
https://fedorahosted.org/fpc/ticket/408

(remaining votes needed)
#topic #416 Temporary bundling exception for ipython
.fpc 416
https://fedorahosted.org/fpc/ticket/416

(remaining votes needed)
#topic #420 PHP Guidelines change - numeric prefix
.fpc 420
https://fedorahosted.org/fpc/ticket/420

= New business =

#topic #411 proposal: migrate license files to %license instead of %doc
.fpc 411
https://fedorahosted.org/fpc/ticket/411

#topic #413 Bundling exception request for nodejs-shelljs
.fpc 413
https://fedorahosted.org/fpc/ticket/413

#topic #414 Please consider requiring AppData for all desktop applications
.fpc 414
https://fedorahosted.org/fpc/ticket/414

#topic #417 sha2 library bundling in clementine
.fpc 417
https://fedorahosted.org/fpc/ticket/417

#topic #418 Bundling exception for reaver-wps
.fpc 418
https://fedorahosted.org/fpc/ticket/418

#topic #419 ruby193 in SCL
.fpc 419
https://fedorahosted.org/fpc/ticket/419

#topic #421 Update environment modules guidelines
.fpc 421
https://fedorahosted.org/fpc/ticket/421

#topic #422 move an existing package to a different upstream fork
.fpc 422
https://fedorahosted.org/fpc/ticket/422

#topic #423 Bundling exception request (copylib) for TommyDS library
used in SnapRAID
.fpc 423
https://fedorahosted.org/fpc/ticket/423

#topic #424 Bundling exception request for nodejs-weak-map
.fpc 424
https://fedorahosted.org/fpc/ticket/424

#topic #425 systemd or systemd-units should not be required if a spec file 
does a %systemd_post command
.fpc 425
https://fedorahosted.org/fpc/ticket/425


= Open Floor = 

 For more complete details, please visit each individual ticket.  The
report of the agenda items can be found at:

https://fedorahosted.org/fpc/report/12


 If you would like to add something to this agenda, you can reply to
this e-mail, file a new ticket at https://fedorahosted.org/fpc,
e-mail me directly, or bring it up at the end of the meeting, during
the open floor topic. Note that added topics may be deferred until
the following meeting. 


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

Re: F21 System Wide Change: Default Local DNS Resolver

[Dan Williams]

On Wed, 2014-04-30 at 13:22 -0400, Paul Wouters wrote:
> On Wed, 30 Apr 2014, Robert Marcano wrote:
> 
> > What about domain and search lines? If NetworkManager will always use 
> > 127.0.0.1, it should still modify resolv.conf with the domain name received 
> > from DHCP
> 
> That's actually not always correct from a security point of view.
> 
> If you set your system do have domain "nohats.ca", and you "ssh bofh"
> and then some DHCP changes the domain/search list, you might not be
> going where you think you are going.
> 
> IMHO, DHCP should never touch the domain or search list _unless_ you are
> connecting to a trusted network - where trusted for practical reasons is
> defined as "you plug in a wire or use a wifi WPA secret to connect".

Untrusted networks use WPA too, like coffee shops that don't leave the
network open, but write the WPA key on the chalkboard menu or print it
on standup cards at the tables.  I've seen quite a few of these.

There's really no guessing what's trusted/not-trusted unless you're
using 802.1x/WPA Enterprise, or if the user has told you explicitly to
trust this network.

Dan

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

Re: F21 System Wide Change: Default Local DNS Resolver

[Reindl Harald]

Am 30.04.2014 20:38, schrieb Dan Williams:
> There's really no guessing what's trusted/not-trusted unless you're
> using 802.1x/WPA Enterprise, or if the user has told you explicitly to
> trust this network

thank you!



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

Re: F21 System Wide Change: Default Local DNS Resolver

[Paul Wouters]

On Wed, 30 Apr 2014, Dan Williams wrote:


Untrusted networks use WPA too, like coffee shops that don't leave the
network open, but write the WPA key on the chalkboard menu or print it
on standup cards at the tables.  I've seen quite a few of these.


You are at least consciously logging into that network - it is not that
your device accidentally roamed on to it.


There's really no guessing what's trusted/not-trusted unless you're
using 802.1x/WPA Enterprise, or if the user has told you explicitly to
trust this network.


I'm fine with marking anything untrusted unless otherwise signaled by
the user via the NM GUI. But others raised objections that it would
break too much. I argued changing the search list already breaks my
laptop security.

The problem is people have linked up the DHCP domain option with the
resolv.conf domain/search keywords to make "internal only" names
visible.

Between usability and security, where do we put the dial?

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

Re: F21 System Wide Change: Default Local DNS Resolver

[Simo Sorce]

On Wed, 2014-04-30 at 12:16 -0430, Robert Marcano wrote:
> On 04/30/2014 01:17 AM, P J P wrote:
> >> On Wednesday, 30 April 2014 3:18 AM, Al Dunsmuir wrote:
> >> On my home LAN, I run my own DNSSEC-enabled server using F20 & bind 9.
> >> This  local server also is my DHCP and Samba server. As usual, dynamic
> >> clients  receive  the  LAN  local  domain  ID  and  DNS  server  ID
> >> automatically.
> >>
> >> How  does  this  proposed  change  affect my clients, or especially my
> >> server  (which  uses  NetworkManager  (not  Network),  and a static IP
> >> address?
> >
> >This should work just fine. If you upgrade your F20 machine to say F22, 
> > it would have the default resolver running on 127.0.0.1:53 with its entry 
> > in '/etc/resolv.conf'. One change you would need to do is to make it listen 
> > on 0.0.0.0:53 or the on static IP address of your server. Your clients 
> > won't know that they are talking to a different DNS resolver.
> >
> > If your clients are upgraded to F22, NetworkManager there would make the 
> > local resolver talk to the one on your server, because it'll receive that 
> > name server configuration via DHCP.
> 
> I think the parent post is refering to the local domain name, I have 
> read this thread and people talk about not touching ever the resolv.conf 
> file. What about domain and search lines? If NetworkManager will always 
> use 127.0.0.1, it should still modify resolv.conf with the domain name 
> received from DHCP

Why would you care for the domain name as provided by dhcp ?

By default you wouldn't want that as you roam with a fedora laptop on
completely untrusted dhcp networks that can push whatever crap as a
search path.

Simo.

-- 
Simo Sorce * Red Hat, Inc * New York

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

Re: F21 System Wide Change: Default Local DNS Resolver

[Paul Wouters]

On Wed, 30 Apr 2014, Simo Sorce wrote:


Why would you care for the domain name as provided by dhcp ?


internal DNS views, eg server.internal.corp.com where the search domain
gets set to "internal.corp.com" and "server.corp.com" does not exist.


By default you wouldn't want that as you roam with a fedora laptop on
completely untrusted dhcp networks that can push whatever crap as a
search path.


Yes, which is why we tentatively came to the conclusion the best
compromise for this is "if the user authorizes to connect to this
network, allow it". Eg using physical cable or WPA secrets.

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

Re: F21 System Wide Change: Default Local DNS Resolver

[Dan Williams]

On Wed, 2014-04-30 at 15:36 -0400, Paul Wouters wrote:
> On Wed, 30 Apr 2014, Simo Sorce wrote:
> 
> > Why would you care for the domain name as provided by dhcp ?
> 
> internal DNS views, eg server.internal.corp.com where the search domain
> gets set to "internal.corp.com" and "server.corp.com" does not exist.
> 
> > By default you wouldn't want that as you roam with a fedora laptop on
> > completely untrusted dhcp networks that can push whatever crap as a
> > search path.
> 
> Yes, which is why we tentatively came to the conclusion the best
> compromise for this is "if the user authorizes to connect to this
> network, allow it". Eg using physical cable or WPA secrets.

Note that with NetworkManager, no WiFi connection is ever made (even
open) without the user explicitly requesting it.  If you have the
NetworkManager-config-server RPM installed, then no ethernet connection
is ever made without the user explicitly configuring it.  So I'm not
sure the description quite fits...

Dan

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

Re: F21 System Wide Change: Default Local DNS Resolver

[Andrew Lutomirski]

On Wed, Apr 30, 2014 at 1:02 PM, Dan Williams  wrote:
> On Wed, 2014-04-30 at 15:36 -0400, Paul Wouters wrote:
>> On Wed, 30 Apr 2014, Simo Sorce wrote:
>>
>> > Why would you care for the domain name as provided by dhcp ?
>>
>> internal DNS views, eg server.internal.corp.com where the search domain
>> gets set to "internal.corp.com" and "server.corp.com" does not exist.
>>
>> > By default you wouldn't want that as you roam with a fedora laptop on
>> > completely untrusted dhcp networks that can push whatever crap as a
>> > search path.
>>
>> Yes, which is why we tentatively came to the conclusion the best
>> compromise for this is "if the user authorizes to connect to this
>> network, allow it". Eg using physical cable or WPA secrets.
>
> Note that with NetworkManager, no WiFi connection is ever made (even
> open) without the user explicitly requesting it.  If you have the
> NetworkManager-config-server RPM installed, then no ethernet connection
> is ever made without the user explicitly configuring it.  So I'm not
> sure the description quite fits...

Except for that network called "linksys" that everyone has requested
at some point.

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

Re: F21 System Wide Change: Default Local DNS Resolver

[Chuck Anderson]

On Wed, Apr 30, 2014 at 01:06:51PM -0700, Andrew Lutomirski wrote:
> On Wed, Apr 30, 2014 at 1:02 PM, Dan Williams  wrote:
> > On Wed, 2014-04-30 at 15:36 -0400, Paul Wouters wrote:
> >> On Wed, 30 Apr 2014, Simo Sorce wrote:
> >>
> >> > Why would you care for the domain name as provided by dhcp ?
> >>
> >> internal DNS views, eg server.internal.corp.com where the search domain
> >> gets set to "internal.corp.com" and "server.corp.com" does not exist.
> >>
> >> > By default you wouldn't want that as you roam with a fedora laptop on
> >> > completely untrusted dhcp networks that can push whatever crap as a
> >> > search path.
> >>
> >> Yes, which is why we tentatively came to the conclusion the best
> >> compromise for this is "if the user authorizes to connect to this
> >> network, allow it". Eg using physical cable or WPA secrets.
> >
> > Note that with NetworkManager, no WiFi connection is ever made (even
> > open) without the user explicitly requesting it.  If you have the
> > NetworkManager-config-server RPM installed, then no ethernet connection
> > is ever made without the user explicitly configuring it.  So I'm not
> > sure the description quite fits...
> 
> Except for that network called "linksys" that everyone has requested
> at some point.

If I once connected to an open network called "MyFavoriteCoffeeShop"
then later on someone creates a network with the same name but with
malicous intent, will NetworkManager connect to it automatically?
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Dracut HostOnly two releases later

[Reindl Harald]

looks like https://fedoraproject.org/wiki/Features/DracutHostOnly over
the long has the opposite effect and more and more modules are included
in the hostonly-initrd because regressions right and left

people who used hostonly before the feature on machines where
it is fine where down below 5 MB, with F19 around 6 MB and
on a completly stripped down F21/Rahide we reahc 9 MB

5,9M 2014-04-27 11:47 initramfs-3.13.11-100.fc19.x86_64.img
8,9M 2014-04-30 21:47 initramfs-3.15.0-0.rc3.git1.10.fc21.x86_64.img

finally nobody won and the ones with stripped down systems lost



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

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

[Michael Cronenworth]

Lennart Poettering wrote:

Hmm, we should probably do our homework first from the systemd side, and
provide some RPM macros so that packages installing binfmt snippets can
actually register/unregister them on package installation/deinstallation
correctly. And when that's done we should probably ask FPC to propose
usage of these macros in the guidelines, and then make the changes to
the packages...


Ticket created: https://fedorahosted.org/fpc/ticket/426

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

Re: F21 System Wide Change: Default Local DNS Resolver

[Dan Williams]

On Wed, 2014-04-30 at 16:12 -0400, Chuck Anderson wrote:
> On Wed, Apr 30, 2014 at 01:06:51PM -0700, Andrew Lutomirski wrote:
> > On Wed, Apr 30, 2014 at 1:02 PM, Dan Williams  wrote:
> > > On Wed, 2014-04-30 at 15:36 -0400, Paul Wouters wrote:
> > >> On Wed, 30 Apr 2014, Simo Sorce wrote:
> > >>
> > >> > Why would you care for the domain name as provided by dhcp ?
> > >>
> > >> internal DNS views, eg server.internal.corp.com where the search domain
> > >> gets set to "internal.corp.com" and "server.corp.com" does not exist.
> > >>
> > >> > By default you wouldn't want that as you roam with a fedora laptop on
> > >> > completely untrusted dhcp networks that can push whatever crap as a
> > >> > search path.
> > >>
> > >> Yes, which is why we tentatively came to the conclusion the best
> > >> compromise for this is "if the user authorizes to connect to this
> > >> network, allow it". Eg using physical cable or WPA secrets.
> > >
> > > Note that with NetworkManager, no WiFi connection is ever made (even
> > > open) without the user explicitly requesting it.  If you have the
> > > NetworkManager-config-server RPM installed, then no ethernet connection
> > > is ever made without the user explicitly configuring it.  So I'm not
> > > sure the description quite fits...
> > 
> > Except for that network called "linksys" that everyone has requested
> > at some point.
> 
> If I once connected to an open network called "MyFavoriteCoffeeShop"
> then later on someone creates a network with the same name but with
> malicous intent, will NetworkManager connect to it automatically?

If it uses the same SSID and compatible security settings, then yes.
That's the nature of 802.11.  However, if the malicious user doesn't
know the password that you have saved on your machine, or the network's
CA certificate does not validate, then the attempt will fail.

Furthermore, if the user creates a network of a different type (eg,
Ad-Hoc but yours is infrastructure), NM will not attempt to connect to
it.

Yes, there are ways to game the system, so you are correct that there
are some cases where NetworkManager could automatically attempt to
connect to a malicious network that mimics a known network, the same as
with most other OSs and phones.

Dan

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

Re: F21 System Wide Change: Default Local DNS Resolver

[Chuck Anderson]

On Wed, Apr 30, 2014 at 03:55:59PM -0500, Dan Williams wrote:
> On Wed, 2014-04-30 at 16:12 -0400, Chuck Anderson wrote:
> > If I once connected to an open network called "MyFavoriteCoffeeShop"
> > then later on someone creates a network with the same name but with
> > malicous intent, will NetworkManager connect to it automatically?
> 
> If it uses the same SSID and compatible security settings, then yes.
> That's the nature of 802.11.  However, if the malicious user doesn't
> know the password that you have saved on your machine, or the network's
> CA certificate does not validate, then the attempt will fail.

Right, so NetworkManager shouldn't treat a WIFI network connection as
"trusted" by default unless it is using secure credentials.  For open
networks, it probably shouldn't connect automatically by default at
all.  It certainly shouldn't update resolv.conf with the domain from
DHCP on such a network, and it shouldn't assign such a network to the
"trust" zone of the firewall by default (to bring all these threads
together...)  I'd argue that even a WEP or WPA-PSK network /by
default/ should not do those things.

Probably the only networks where it MAY default to the following behavior:

- Connect automatically
- Use DHCP provided domain name
- Assign network to "trust" zone for firewall or network sharing settings

are these types of networks:

- Wired network
- Wi-Fi with WPA-Enterprise where there is mutual authentication going
  on (supplicant verifies server certificate as trusted)

For other Wi-Fi security types (open, WEP, WPA-PSK), you might be able
to remember the BSSID, IP subnet, router MAC address, or other
detectable things (like UPnP) to guess that you are on the same
network as before, and use that to decide if you should apply that
same "trust" settings as before.

> Furthermore, if the user creates a network of a different type (eg,
> Ad-Hoc but yours is infrastructure), NM will not attempt to connect to
> it.
> 
> Yes, there are ways to game the system, so you are correct that there
> are some cases where NetworkManager could automatically attempt to
> connect to a malicious network that mimics a known network, the same as
> with most other OSs and phones.

It seems like a useful concept to simplify the user experience by
lumping the above things together in a concept of "trust", while still
allowing a user to go in and override the settings if desired.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: F21 Self Contained Change: The Shogun Machine Learning Toolbox

[Ian Malone]

On 30 April 2014 14:10, Jaroslav Reznik  wrote:
> = Proposed Self Contained Change: The Shogun Machine Learning Toolbox =
> https://fedoraproject.org/wiki/Changes/shogun
>
> Change owner(s): Björn Esser 
>
> SHOGUN is a large Scale Machine Learning Toolbox, being implemented in C++ and
> offering interfaces to C#, Java, Lua, Octave, Perl, Python, R and Ruby.
>

Nice. :)

-- 
imalone
http://ibmalone.blogspot.co.uk
-- 
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: We want to stop systemd from being added to docker images, because of rpm requiring systemctl.

[Marcelo Ricardo Leitner]

Em 30-04-2014 07:57, Lennart Poettering escreveu:

On Tue, 29.04.14 15:36, Marcelo Ricardo Leitner (marcelo.leit...@gmail.com) 
wrote:


Em 29-04-2014 12:27, Lennart Poettering escreveu:

On Tue, 29.04.14 10:37, Daniel J Walsh (dwa...@redhat.com) wrote:



On 04/29/2014 06:33 AM, Lennart Poettering wrote:

On Mon, 28.04.14 17:01, Daniel J Walsh (dwa...@redhat.com) wrote:


The problem  is lots of services require systemd because they ship a
unit file and want systemctl reload to happen.  Systemd then triggers a
require for udev and kmod, which docker containers do not need.

If you discount the docs/man pages of the RPMs, how much does kmod,
udev, systemd actually contribtue in bytes to your docker images?

Lennart


Shrinking the the docker image is more then just size.  We want to
eliminate packages that are not used (Within reason) to eliminate
problems like CVE's.  If udev/systemd/kmod had a CVE we would need to
update all Container images.


Well, if you are this principled maybe. But do note that we dont really
ship suid binaries (except one binary with fscaps which is
systemd-detect-virt), and hence by leaving systemd in the image without
running it should result in no increased attack surface that wasn't
there anyway... Dead code in the image, that cannot be use to acquire
new caps isn't much of a security threat...


You're considering only the escalation way to do it, but there are
other ways to exploit code laying around, like when some web pages
don't sanitize the URL enough and end up allowing executing
something in the system, much like sql injection. In those cases,
one could craft URLs to run wget or any other tool that may help the
intruder get even more inside.

It's a pile of faults, yes, but the result isn't good and one good
preventive step is keeping the dead/not needed stuff away.


This makes no sense. I mean, why would anyone bother with playing with
systemd's binaries which (with the exceptio of s-d-v, see above) do not
increase your set of capabilities when executed, if you have /bin/sh
anyway which allows you to do whatever you want? If an attacker managed


Don't ask me, ask when it happens (again)/when the next CVE comes up. 
(and no, I'm not referring to systemd exclusively)



to inject code in your system, then systemd's tools won't allow him to
do anything he couldn't do anyway, either directly with injected code or
by invoking /bin/sh and then continuing from there. Hence the attack
surface is not increased.


That only if you assume that directly executing the wanted binary (being 
a file or not) is the only way to do it.


Please, seriously, I'm not saying (and also was not saying so before 
too, sorry if it wasn't clear) this is the case for systemd. I'm just 
saying that code that seems dead might not be dead on all circumstances, 
for whatever reason. That's my only point here.



A problem would be tons of suid bianries, or binaries with fscaps. But


Like tricking an application on sending (mass) emails to (unwanted) 
addresses or whatever is okay.



otherwise dead code lying around is no real additional security
threat. I am mostly interested in actual security measures, not security
theatre.


If that's what you think, okay. I do agree with you that suids & all are 
the worse thing. After all, it's like winning the lottery for hackers 
and that's probably where they focus most. But still fear something 
ending up executed via unwanted/unpredicted ways, specially when systems 
are getting more integrated, clever and smarter day after day.


Marcelo


--
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: We want to stop systemd from being added to docker images, because of rpm requiring systemctl.

[Andrew Lutomirski]

On Wed, Apr 30, 2014 at 3:56 PM, Marcelo Ricardo Leitner
 wrote:
> If that's what you think, okay. I do agree with you that suids & all are the
> worse thing. After all, it's like winning the lottery for hackers and that's
> probably where they focus most. But still fear something ending up executed
> via unwanted/unpredicted ways, specially when systems are getting more
> integrated, clever and smarter day after day.

If the goal is to close the giant attack surface that setuid things
provide, then there's almost an easy solution: use
PR_SET_NO_NEW_PRIVS.  It's integrated with systemd, but my effort to
get it into PAM [1] didn't seem to go anywhere.  I think that, for the
most part, most daemons should have no_new_privs set.

PAM integration would make it work for services like gitolite and for
ordinary shell users who are willing to tolerate minor regressions
like being unable to change passwords. :)

[1] http://www.redhat.com/archives/pam-list/2013-October/msg00012.html

--Andy
-- 
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: Mass bug: packages should not auto-enable systemd units

[Zbigniew Jędrzejewski-Szmek]

On Wed, Apr 30, 2014 at 09:02:30AM -0700, Andrew Lutomirski wrote:
> Due to some confusion around how alternatives worked, I screwed up the
> list of packages here.  I've updated it below.  I'll give it a few
> more days before filing the actual bugs.
> abrt
> acpid
> aeolus-audrey-agent
> aeolus-configserver
> audit
> avahi
> bluez
> bootchart
dead package

> cherokee
> cloud-init
> deltacloud-core
> dmapd
> dnssec-trigger
> glusterfs
> gnome-initial-setup
> gpsd
> ipmiutil
> iptables
> kexec-tools
> libstoragemgmt
> libvirt
> lttng-tools
> monit
> NetworkManager
> nfs-utils
> nss-pam-ldapd
> olpc-kbdshim
> olpc-powerd
> openct
> pcsc-lite
> qemu
> qpid-cpp
> rootfs-resize
> rpcbind
> sendmail
> soundmodem
> spacenavd
> subscription-manager
> supervisor
> systemd
This seems to be a false positive.

> targetcli
> util-linux
> vdsm
> xen

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

qt-mobility on a generic non-wireless KDE desktop PC?

[Felix Miata]

Is this wasteful new dependency on Nokia intentional?
--
"The wise are known for their understanding, and pleasant
words are persuasive." Proverbs 16:21 (New Living Translation)

 Team OS/2 ** Reg. Linux User #211409 ** a11y rocks!

Felix Miata  ***  http://fm.no-ip.com/
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct