EPEL epel beta report: 20140430 changes
Compose started at Wed Apr 30 08:15:03 UTC 2014
New package: debootstrap-1.0.59-1.el7.2
Debian GNU/Linux bootstrapper
New package: dmenu-4.5-5.20140425git.el7
Generic menu for X
New package: linux_logo-5.11-7.el7
Show a logo with some system info on the console
New package: python-mccabe-0.2.1-4.el7
McCabe complexity checker
New package: rendercheck-1.4-1.0.2.20140402GIT589bb58.el7
Tool to verify correct operation of the XRENDER extension
New package: ttf2pt1-3.4.4-16.el7
TrueType to Adobe Type 1 font converter
Updated Packages:
R-3.1.0-4.el7
-
* Tue Apr 29 2014 Tom Callaway s...@fedoraproject.org - 3.1.0-3
- epel fixes
* Fri Apr 25 2014 Tom Callaway s...@fedoraproject.org - 3.1.0-2
- fix core-devel Requires
* Mon Apr 21 2014 Tom Callaway s...@fedoraproject.org - 3.1.0-1
- update to 3.1.0
* Mon Mar 24 2014 Brent Baude ba...@us.ibm.com - 3.0.3-2
- add ppc64le support
- rhbz #1077819
* Thu Mar 20 2014 Tom Callaway s...@fedoraproject.org - 3.0.3-1
- update to 3.0.3
- switch to java-headless
* Fri Feb 14 2014 David Tardon dtar...@redhat.com - 3.0.2-7
- rebuild for new ICU
* Sat Feb 08 2014 Ville Skyttä ville.sky...@iki.fi - 3.0.2-6
- Install macros to %{_rpmconfigdir}/macros.d where available.
- Fix rpmlint spaces vs tabs warnings.
* Fri Feb 07 2014 Tom Callaway s...@fedoraproject.org - 3.0.2-5
- add support for system tre (f21+, rhel 7+)
facter-2.0.1-1.el7
--
* Tue Apr 29 2014 Sam Kottler skott...@fedoraproject.org - 2.0.1-1
- Update to to 2.0.1
gtkwave-3.3.59-1.el7
* Tue Apr 29 2014 Paul Howarth p...@city-fan.org 3.3.59-1
- update to 3.3.59
- use Duff's Device for 8 byte - 1 byte binary value compression algorithm
in FST writer
- warnings fixes from cppcheck
- moved MinGW for FST to using different windows tempfile generation instead
of tmpfile()
- removed fflush() in FST for MinGW in places that can cause crashes with
read-only files
- updated man page for gtkwave.1 indicating that XID is in hex
- allow decimal conversions on popcnt filtered vectors that are greater than
64 bits (they will never overflow)
libserf-1.3.5-1.el7
---
* Wed Apr 30 2014 Christopher Meng r...@cicku.me - 1.3.5-1
- update to 1.3.5
openlmi-scripts-0.3.0-1.el7
---
* Tue Apr 29 2014 Michal Minar mimi...@redhat.com 0.3.0-1
- Updated to new upstream version 0.3.0.
- Added openlmi-tools source due to meta-command's absence in source tarball.
- Documentation package ships just documentation for meta-command.
- Each script sub-package now contains related documentation.
- Added journald sub-package.
openocd-0.8.0-1.el7
---
* Tue Apr 29 2014 Markus Mayer lotharl...@gmx.de - 0.8.0-1
- update to 0.8.0
- enable new targets
- add udev rule
perl-Config-Generator-0.7-1.el7
---
* Tue Apr 29 2014 Alexandre Beche alexandre.be...@gmail.com 0.7-1
- Added an example of a wrapper script in the eg directory.
- Config::Generator::Template: added ifdef() and ifndef() macros.
* Thu Mar 27 2014 Alexandre Beche alexandre.be...@gmail.com 0.5-2
- minor change to specfile: Summary and description changed.
perl-ExtUtils-Depends-0.307-1.el7
-
* Tue Apr 29 2014 Paul Howarth p...@city-fan.org - 0.307-1
- Update to 0.307
- $Data::Dumper::Terse set to 1 broke save_config
- Document API expected by ::load function
- Classify buildreqs by usage
- Make %files list more explicit
- Use DESTDIR rather than PERL_INSTALL_ROOT
- Don't use macros for commands
php-pecl-xdebug-2.2.5-1.el7
---
* Wed Apr 30 2014 Remi Collet r...@fedoraproject.org - 2.2.5-1
- Update to 2.2.5 (stable)
* Wed Apr 23 2014 Remi Collet r...@fedoraproject.org - 2.2.4-2
- add numerical prefix to extension configuration file
- drop uneeded full extension path
php-phpunit-DbUnit-1.3.1-2.el7
--
* Tue Apr 29 2014 Remi Collet r...@fedoraproject.org - 1.3.1-2
- sources from github
- run tests during build
php-phpunit-FinderFacade-1.1.0-3.el7
* Tue Apr 29 2014 Remi Collet r...@fedoraproject.org - 1.1.0-3
- sources from github
- run tests during build
* Sun Aug 04 2013 Fedora Release Engineering rel-...@lists.fedoraproject.org
- 1.1.0-2
- Rebuilt for https://fedoraproject.org/wiki/Fedora_20_Mass_Rebuild
php-phpunit-PHP-TokenStream-1.2.2-2.el7
---
* Tue Apr 29 2014 Remi Collet r...@fedoraproject.org - 1.2.2-2
- sources from github
php-phpunit-PHPUnit-Selenium-1.3.3-2.el7
* Tue Apr 29 2014 Remi Collet r...@fedoraproject.org - 1.3.3-2
- sources from github
php-phpunit-PHPUnit-SkeletonGenerator-1.2.1-3.el7
-
* Tue Apr 29 2014 Remi Collet r...@fedoraproject.org - 1.2.1-3
- sources from github
*
Re: EPEL RFC: Strategy for python3 versions
On 30 April 2014 07:51, Pat Riehecky riehe...@fnal.gov wrote: 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 I am thinking that softwarecollections and EPEL may have competing solutions to the same problems because of the different mechanisms and problems each are solving. -- Stephen J Smoogen. ___ epel-devel mailing list epel-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/epel-devel
Re: EPEL RFC: Strategy for python3 versions
On 30 April 2014 08:46, Toshio Kuratomi a.bad...@gmail.com wrote: On Tue, Apr 29, 2014 at 07:22:40PM -0600, Orion Poplawski wrote: Finally: python34-3.4 This has precedent. The main reason I chose this when doing the mediawiki packages was to avoid parsing problems due to the fact that people like to do ls -1 and then awk/cut out per the first - or . as the package name. I won't say that their approach is good but it was the most common one I ran into when looking at doing mediawiki117 or mediawiki1.17 (the other solution was an rpm aware ls like program.. just what everyone needs to add to ls .deb/.rpm/xxx parsing :).) or python3.4-3.4 When I create new compat packages, I like to put dots in the version so this works for me as well. or python-3.4-3.4 I dislike dashes in that position as it makes it hard to read. I agree. It makes it very hard to see if I am looking at -- Stephen J Smoogen. ___ epel-devel mailing list epel-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/epel-devel
Re: EPEL RFC: Strategy for python3 versions
On 04/30/2014 07:51 AM, Pat Riehecky wrote: 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 I think EL7 deserves to have a system integrated python3 version. -- 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 ___ epel-devel mailing list epel-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/epel-devel
Re: F21 System Wide Change: Default Local DNS Resolver
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 p...@fedoraproject.org, Pavel Šimerda pav...@pavlix.net, Tomas Hozza tho...@redhat.com To install a local DNS resolver trusted for the DNSSEC validation running on 127.0.0.1:53. This must be the only name server entry in /etc/resolv.conf. 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. 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. 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. -- 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
On Wed, Apr 30, 2014 at 12:41 AM, Bojan Smojver bo...@rexursive.com 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
- 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) non-empty content ... 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... snip == 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
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).
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
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.
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
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: kernel packaging split up landing in Rawhide
On Wed, Apr 30, 2014 at 5:41 AM, Steven Whitehouse swhit...@redhat.com 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
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
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
On Wed, Apr 30, 2014 at 07:56:29 -0400, Josh Boyer jwbo...@fedoraproject.org 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
F21 Self Contained Change: The Shogun Machine Learning Toolbox
= Proposed Self Contained Change: The Shogun Machine Learning Toolbox = https://fedoraproject.org/wiki/Changes/shogun Change owner(s): Björn Esser besse...@fedoraproject.org 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
= Proposed Self Contained Change: MariaDB 10.0 = https://fedoraproject.org/wiki/Changes/MariaDB10 Change owner(s): Jakub Dorňák jdor...@redhat.com 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
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 p...@fedoraproject.org, Pavel Šimerda pav...@pavlix.net, Tomas Hozza tho...@redhat.com To install a local DNS resolver trusted for the DNSSEC validation running on 127.0.0.1:53. This must be the only name server entry in /etc/resolv.conf. 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
On Tue, Apr 29, 2014 at 11:23 PM, Simo Sorce s...@redhat.com 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.
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 h.rei...@thelounge.net mailto:h.rei...@thelounge.net 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
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
See http://jenkins.cloud.fedoraproject.org/job/389-ds-base/348/ -- Started by an SCM change Building remotely on Fedora20 in workspace http://jenkins.cloud.fedoraproject.org/job/389-ds-base/ws/ 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.
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
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
Re: F21 System Wide Change: Wayland
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.
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 dwa...@redhat.com 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 21 || :, 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 21 || : ... 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.
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 dwa...@redhat.com 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 21 || :, 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 21 || : .. 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.
On Wed, Apr 30, 2014 at 16:05:37 +0200, Kalev Lember kalevlem...@gmail.com 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 21 || : ... 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.
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 21 || : ... 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
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'
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
- 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'
commit b94220d367838d49f66b4995ec422414f6b5ad7b Merge: f8e2dec 91ae5ef Author: Darryl L. Pierce mcpie...@gmail.com 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.
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 21 || : ... 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)
-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.
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
On Wed, 2014-04-30 at 13:25 +, Colin Walters wrote: On Tue, Apr 29, 2014 at 11:23 PM, Simo Sorce s...@redhat.com 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.
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 21 || : .. 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 21 || : 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
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.
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.
On 30 April 2014 15:52, Kalev Lember kalevlem...@gmail.com 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)
I've got a conflicting meeting and will probably show up late -- sorry for the late notice. -- Matthew Miller-- Fedora Project--mat...@fedoraproject.org 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)
-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.
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 21 || : ... 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
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 p...@fedoraproject.org, Pavel Šimerda pav...@pavlix.net, Tomas Hozza tho...@redhat.com To install a local DNS resolver trusted for the DNSSEC validation running on 127.0.0.1:53. This must be the only name server entry in /etc/resolv.conf. 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
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.
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 21 || : ... 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
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)
-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
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 l...@mit.edu 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
On Wed, Apr 30, 2014 at 11:02 AM, Andrew Lutomirski l...@mit.edu 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
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.
On Wed, Apr 30, 2014 at 1:14 PM, Adam Jackson a...@redhat.com 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
On Wed, Apr 30, 2014 at 12:58 PM, Rahul Sundaram methe...@gmail.com 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
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
On Wed, Apr 30, 2014 at 11:06 AM, Richard Shaw hobbes1...@gmail.com wrote: On Wed, Apr 30, 2014 at 12:58 PM, Rahul Sundaram methe...@gmail.com 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)
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
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
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
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
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
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
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
On Wed, Apr 30, 2014 at 1:02 PM, Dan Williams d...@redhat.com 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
On Wed, Apr 30, 2014 at 01:06:51PM -0700, Andrew Lutomirski wrote: On Wed, Apr 30, 2014 at 1:02 PM, Dan Williams d...@redhat.com 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
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)
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
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 d...@redhat.com 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
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
On 30 April 2014 14:10, Jaroslav Reznik jrez...@redhat.com wrote: = Proposed Self Contained Change: The Shogun Machine Learning Toolbox = https://fedoraproject.org/wiki/Changes/shogun Change owner(s): Björn Esser besse...@fedoraproject.org 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.
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.
On Wed, Apr 30, 2014 at 3:56 PM, Marcelo Ricardo Leitner marcelo.leit...@gmail.com 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
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
[perl-Try-Tiny] Created tag perl-Try-Tiny-0.22-1.fc21
The lightweight tag 'perl-Try-Tiny-0.22-1.fc21' was created pointing to: aacd888... Update to 0.22 -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-App-cpanminus] Update fatunpack to deal with FatPacker #line
commit 247db4a6d3d5bd732972043316f25d02b65046c0
Author: Petr Písař ppi...@redhat.com
Date: Wed Apr 30 08:04:56 2014 +0200
Update fatunpack to deal with FatPacker #line
App-cpanminus-1.7004 brings a new syntax:
$fatpacked{App/cpanminus.pm} = '#line '.(1+__LINE__).'
'.__FILE__.\\n.'APP_CPANMINUS';
fatunpack |6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
---
diff --git a/fatunpack b/fatunpack
index f13b107..0cc0652 100755
--- a/fatunpack
+++ b/fatunpack
@@ -20,7 +20,7 @@ eval { $filter = qr{$filter}; 1} or
my ($file, $filename, $delimiter);
while () {
-if (/^\$fatpacked\{\s*([^]*)\s*\}\s*=\s*\s*'([^']*)'\s*;/) {
+if (/^\$fatpacked\{\s*([^]*)\s*\}\s*=.*\s*'([^']*)'\s*;/) {
# Packed module beginning found
$filename = $1;
$delimiter = $2;
@@ -99,11 +99,11 @@ regular expression, i.e. to save all modules.
=head1 VERSION
-This is version 1.
+This is version 2.
=head1 COPYRIGHT
-Copyright © 2013 Petr Písař ppi...@redhat.com.
+Copyright © 2013, 2014 Petr Písař ppi...@redhat.com.
=head1 LICENSE
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-Language-Prolog-Yaswi] Rebuild against pl-6.6.5
commit 6232fdadf59048b3ea8f1a3bcdba94705a4ab60c
Author: Petr Písař ppi...@redhat.com
Date: Wed Apr 30 08:35:31 2014 +0200
Rebuild against pl-6.6.5
perl-Language-Prolog-Yaswi.spec |5 -
1 files changed, 4 insertions(+), 1 deletions(-)
---
diff --git a/perl-Language-Prolog-Yaswi.spec b/perl-Language-Prolog-Yaswi.spec
index b8d3781..9ac137d 100644
--- a/perl-Language-Prolog-Yaswi.spec
+++ b/perl-Language-Prolog-Yaswi.spec
@@ -1,6 +1,6 @@
Name: perl-Language-Prolog-Yaswi
Version:0.21
-Release:19%{?dist}
+Release:20%{?dist}
Summary:Yet another interface to SWI-Prolog
License:GPL+ or Artistic
Group: Development/Libraries
@@ -65,6 +65,9 @@ make test
%{_mandir}/man3/*
%changelog
+* Wed Apr 30 2014 Petr Pisar ppi...@redhat.com - 0.21-20
+- Rebuild against pl-6.6.5
+
* Mon Mar 24 2014 Petr Pisar ppi...@redhat.com - 0.21-19
- Rebuild against pl-6.6.4
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
File Encode-2.60.tar.gz uploaded to lookaside cache by ppisar
A file has been added to the lookaside cache for perl-Encode: 8ed11fafa9e3c9c1e0ee83d1f9d8bfdf Encode-2.60.tar.gz -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-Encode] 2.60 bump
commit 6aa4b656ed53a6aaaf64b9c7b2e1e26f0e73b519
Author: Petr Písař ppi...@redhat.com
Date: Wed Apr 30 08:56:22 2014 +0200
2.60 bump
.gitignore |1 +
perl-Encode.spec |5 -
sources |2 +-
3 files changed, 6 insertions(+), 2 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index abe40a1..ece56e2 100644
--- a/.gitignore
+++ b/.gitignore
@@ -9,3 +9,4 @@
/Encode-2.57.tar.gz
/Encode-2.58.tar.gz
/Encode-2.59.tar.gz
+/Encode-2.60.tar.gz
diff --git a/perl-Encode.spec b/perl-Encode.spec
index 9c93556..c767403 100644
--- a/perl-Encode.spec
+++ b/perl-Encode.spec
@@ -1,6 +1,6 @@
Name: perl-Encode
Epoch: 1
-Version:2.59
+Version:2.60
Release:1%{?dist}
Summary:Character encodings in Perl
License:GPL+ or Artistic
@@ -113,6 +113,9 @@ make test
%{perl_vendorarch}/Encode/encode.h
%changelog
+* Wed Apr 30 2014 Petr Pisar ppi...@redhat.com - 1:2.60-1
+- 2.60 bump
+
* Mon Apr 14 2014 Petr Pisar ppi...@redhat.com - 1:2.59-1
- 2.59 bump
diff --git a/sources b/sources
index 9293273..86a9d56 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-98afe078b82375c457b28b054be09aa3 Encode-2.59.tar.gz
+8ed11fafa9e3c9c1e0ee83d1f9d8bfdf Encode-2.60.tar.gz
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-XML-TreeBuilder] (3 commits) ...new upstream
Summary of changes: 4fd3323... new upstream: (*) c776793... new upstream (*) 7eeb8da... new upstream (*) (*) This commit already existed in another branch; no separate mail sent -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
File Module-Metadata-1.000022.tar.gz uploaded to lookaside cache by pghmcfc
A file has been added to the lookaside cache for perl-Module-Metadata: 48a1abd8565d6e1d6657b568786df008 Module-Metadata-1.22.tar.gz -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-Module-Metadata] Update to 1.000022
commit 2cd5b595c4d168e5bf9400d33acab708cdf6cc27
Author: Paul Howarth p...@city-fan.org
Date: Wed Apr 30 09:21:24 2014 +0100
Update to 1.22
- New upstream release 1.22
- New is_indexable() object method (CPAN RT#84357)
- Eliminated dependency on IO::File (and by virtue, XS)
- Removed cruft in test infrastructure left behind from separation from
Module::Build
- Repository moved to
https://github.com/Perl-Toolchain-Gang/Module-Metadata
- .pm file is now wholly ascii, for nicer fatpacking (CPAN RT#95086)
- Some code micro-optimizations
(https://github.com/Perl-Toolchain-Gang/Module-Metadata/pull/4)
- Fixed all out of date prereq declarations
- Work around change in comparison behaviour in Test::More 0.95_01 by
being
more explicit with our tests - now explicitly checking the string form
of
the extracted version, rather than the entire version object
- Ensure the extracted version is returned as a version object in all
cases
(CPAN RT#87782)
- Drop redundant Group: tag
perl-Module-Metadata.spec | 31 ---
sources |2 +-
2 files changed, 25 insertions(+), 8 deletions(-)
---
diff --git a/perl-Module-Metadata.spec b/perl-Module-Metadata.spec
index 809b762..89364e5 100644
--- a/perl-Module-Metadata.spec
+++ b/perl-Module-Metadata.spec
@@ -1,34 +1,32 @@
Name: perl-Module-Metadata
-Version: 1.19
+Version: 1.22
Release: 1%{?dist}
Summary: Gather package and POD information from perl module files
License: GPL+ or Artistic
-Group: Development/Libraries
URL: http://search.cpan.org/dist/Module-Metadata/
Source0:
http://search.cpan.org/CPAN/authors/id/E/ET/ETHER/Module-Metadata-%{version}.tar.gz
BuildArch: noarch
# Build
+BuildRequires: perl
BuildRequires: perl(ExtUtils::MakeMaker)
# Module
BuildRequires: perl(Carp)
+BuildRequires: perl(Fcntl)
BuildRequires: perl(File::Find)
BuildRequires: perl(File::Spec)
-BuildRequires: perl(IO::File)
BuildRequires: perl(strict)
-BuildRequires: perl(vars)
BuildRequires: perl(version) = 0.87
BuildRequires: perl(warnings)
# Regular test suite
-BuildRequires: perl(Config)
BuildRequires: perl(Cwd)
BuildRequires: perl(Data::Dumper)
-BuildRequires: perl(Exporter)
BuildRequires: perl(File::Basename)
BuildRequires: perl(File::Path)
BuildRequires: perl(File::Temp)
BuildRequires: perl(IO::File)
BuildRequires: perl(lib)
-BuildRequires: perl(Test::More)
+BuildRequires: perl(Test::More) = 0.90
+BuildRequires: perl(vars)
# Release tests
%if !%{defined perl_bootstrap}
BuildRequires: perl(Test::Pod)
@@ -36,6 +34,7 @@ BuildRequires:perl(Test::Pod::Coverage)
%endif
# Runtime
Requires: perl(:MODULE_COMPAT_%(eval `perl -V:version`; echo $version))
+Requires: perl(Fcntl)
%description
This module provides a standard way to gather metadata about a .pm file
@@ -65,6 +64,24 @@ make test TEST_FILES=xt/*.t
%{_mandir}/man3/Module::Metadata.3pm*
%changelog
+* Wed Apr 30 2014 Paul Howarth p...@city-fan.org - 1.22-1
+- Update to 1.22
+ - New is_indexable() object method (CPAN RT#84357)
+ - Eliminated dependency on IO::File (and by virtue, XS)
+ - Removed cruft in test infrastructure left behind from separation from
+Module::Build
+ - Repository moved to https://github.com/Perl-Toolchain-Gang/Module-Metadata
+ - .pm file is now wholly ascii, for nicer fatpacking (CPAN RT#95086)
+ - Some code micro-optimizations
+(https://github.com/Perl-Toolchain-Gang/Module-Metadata/pull/4)
+ - Fixed all out of date prereq declarations
+ - Work around change in comparison behaviour in Test::More 0.95_01 by being
+more explicit with our tests - now explicitly checking the string form of
+the extracted version, rather than the entire version object
+ - Ensure the extracted version is returned as a version object in all cases
+(CPAN RT#87782)
+- Drop redundant Group: tag
+
* Sun Oct 6 2013 Paul Howarth p...@city-fan.org - 1.19-1
- Update to 1.19
- Warnings now disabled inside during the evaluation of generated version sub
diff --git a/sources b/sources
index df414a8..807acbe 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-838ecf97f7daff79e0f81e104a6be823 Module-Metadata-1.19.tar.gz
+48a1abd8565d6e1d6657b568786df008 Module-Metadata-1.22.tar.gz
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
File App-cpanminus-1.7004.tar.gz uploaded to lookaside cache by jplesnik
A file has been added to the lookaside cache for perl-App-cpanminus: 83b0b8353be83b0e9f01e9227aea4e4f App-cpanminus-1.7004.tar.gz -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-App-cpanminus] 1.7004 bump
commit 1e667b666f7d848d20a8f05f8ee5fb0bff356cad
Author: Jitka Plesnikova jples...@redhat.com
Date: Wed Apr 30 10:34:02 2014 +0200
1.7004 bump
.gitignore |1 +
perl-App-cpanminus.spec |6 +-
sources |2 +-
3 files changed, 7 insertions(+), 2 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index 7c18f09..0ba891b 100644
--- a/.gitignore
+++ b/.gitignore
@@ -58,3 +58,4 @@ App-cpanminus-0.9935.tar.gz
/App-cpanminus-1.6922.tar.gz
/App-cpanminus-1.6927.tar.gz
/App-cpanminus-1.7001.tar.gz
+/App-cpanminus-1.7004.tar.gz
diff --git a/perl-App-cpanminus.spec b/perl-App-cpanminus.spec
index 20f3e9e..e2e87f5 100644
--- a/perl-App-cpanminus.spec
+++ b/perl-App-cpanminus.spec
@@ -1,5 +1,5 @@
Name: perl-App-cpanminus
-Version:1.7001
+Version:1.7004
Release:1%{?dist}
Summary:Get, unpack, build and install CPAN modules
License:GPL+ or Artistic
@@ -131,6 +131,10 @@ make test
%{_bindir}/cpanm
%changelog
+* Wed Apr 30 2014 Jitka Plesnikova jples...@redhat.com - 1.7004-1
+- 1.7004 bump
+- Updated the script fatunpack (ppisar)
+
* Wed Sep 11 2013 Petr Pisar ppi...@redhat.com - 1.7001-1
- 1.7001 bump
diff --git a/sources b/sources
index 0ab2ddf..e127079 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-4655c5903e2885085262cf5f15ff5ae3 App-cpanminus-1.7001.tar.gz
+83b0b8353be83b0e9f01e9227aea4e4f App-cpanminus-1.7004.tar.gz
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-Module-Metadata] Created tag perl-Module-Metadata-1.000022-1.fc21
The lightweight tag 'perl-Module-Metadata-1.22-1.fc21' was created pointing to: 2cd5b59... Update to 1.22 -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-Encode-DoubleEncodedUTF8/epel7] Initial import (#1066852).
Summary of changes: 79204dc... Initial import (#1066852). (*) (*) This commit already existed in another branch; no separate mail sent -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-Image-SubImageFind/epel7] Initial import (#1077956).
Summary of changes: 38d5a54... Initial import (#1077956). (*) (*) This commit already existed in another branch; no separate mail sent -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-HTTP-Soup/epel7] Initial import (#1064817).
Summary of changes: 73f220b... Initial import (#1064817). (*) (*) This commit already existed in another branch; no separate mail sent -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[pkgdb] perl-NOCpulse-Gritch ownership changed
Package perl-NOCpulse-Gritch in Fedora devel is now owned by ppisar To make changes to this package see: https://admin.fedoraproject.org/pkgdb/acls/name/perl-NOCpulse-Gritch -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[pkgdb] perl-NOCpulse-Gritch ownership changed
Package perl-NOCpulse-Gritch in Fedora devel was orphaned by ppisar To make changes to this package see: https://admin.fedoraproject.org/pkgdb/acls/name/perl-NOCpulse-Gritch -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[pkgdb] perl-NOCpulse-Gritch (un)retirement
Package perl-NOCpulse-Gritch in Fedora devel has been retired by ppisar To make changes to this package see: https://admin.fedoraproject.org/pkgdb/acls/name/perl-NOCpulse-Gritch -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 1092921] New: perl-Perl-Critic make check failing on ppc64le archi
https://bugzilla.redhat.com/show_bug.cgi?id=1092921 Bug ID: 1092921 Summary: perl-Perl-Critic make check failing on ppc64le archi Product: Fedora Version: rawhide Component: perl-Perl-Critic Severity: medium Assignee: p...@city-fan.org Reporter: norm...@linux.vnet.ibm.com QA Contact: extras...@fedoraproject.org CC: mmasl...@redhat.com, p...@city-fan.org, perl-devel@lists.fedoraproject.org Created attachment 891090 -- https://bugzilla.redhat.com/attachment.cgi?id=891090action=edit perl-Perl-Critic.build.failure.log Description of problem: perl-Perl-Critic make check failing on ppc64le archi Version-Release number of selected component (if applicable): perl-Perl-Critic-1.121-1.fc21 How reproducible: Steps to Reproduce: (on ppc64le archi) 1.fedpkg clone -a perl-Perl-Critic; export pkg='perl-Perl-Critic'; 2.cd $pkg; fedpkg srpm; mock --init --uniqueext=$pkg-XS 3.mock --no-clean --with=check --uniqueext=$pkg-XS ./$pkg*.src.rpm Actual results: === extract of the attached log # Failed test 'use Readonly::XS;' # at xt/author/82_optional_modules.t line 40. # Tried to use 'Readonly::XS'. # Error: Attempt to reload Readonly/XS.pm aborted. # Compilation failed in require at xt/author/82_optional_modules.t line 40. # BEGIN failed--compilation aborted at xt/author/82_optional_modules.t line 40. # Looks like you failed 1 test of 6. xt/author/82_optional_modules.t ... Dubious, test returned 1 (wstat 256, 0x100) Failed 1/6 subtests === Expected results: all tests should pass Additional info: There is no such problem if same build tried on a ppc64 archi. -- You are receiving this mail because: You are on the CC list for the bug. Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=9LK717Kr2da=cc_unsubscribe -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-Net-Twitter-Lite/epel7] Initial import (#1074482).
Summary of changes: 3f04fa4... Initial import (#1074482). (*) (*) This commit already existed in another branch; no separate mail sent -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 1092921] perl-Perl-Critic make check failing on ppc64le archi
https://bugzilla.redhat.com/show_bug.cgi?id=1092921 --- Comment #1 from Michel Normand norm...@linux.vnet.ibm.com --- I tried to investigate the reported error but with no success as detailed in http://www.mail-archive.com/perl-xs@perl.org/msg02580.html any suggestion are welcome. -- You are receiving this mail because: You are on the CC list for the bug. Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=hQajl7UuFoa=cc_unsubscribe -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-X11-GUITest/epel7] Initial import (#1074242).
Summary of changes: 94676ac... Initial import (#1074242). (*) (*) This commit already existed in another branch; no separate mail sent -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 1092921] perl-Perl-Critic make check failing on ppc64le archi
https://bugzilla.redhat.com/show_bug.cgi?id=1092921 Michel Normand norm...@linux.vnet.ibm.com changed: What|Removed |Added Blocks||1051573 (PPC64LETracker) Referenced Bugs: https://bugzilla.redhat.com/show_bug.cgi?id=1051573 [Bug 1051573] ppc64le tracker bug -- You are receiving this mail because: You are on the CC list for the bug. Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=kfFvN1zhp6a=cc_unsubscribe -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-Net-SMTPS/epel7] Initial import (#1066842).
Summary of changes: a8541a8... Initial import (#1066842). (*) (*) This commit already existed in another branch; no separate mail sent -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-Time-Out/epel7] Initial import (#1068842).
Summary of changes: d89d274... Initial import (#1068842). (*) (*) This commit already existed in another branch; no separate mail sent -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-Net-POP3S/epel7] Initial import (#1066843).
Summary of changes: ca5198c... Initial import (#1066843). (*) (*) This commit already existed in another branch; no separate mail sent -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-REST-Client/epel7] Initial import (#1079890).
Summary of changes: f059b63... Initial import (#1079890). (*) (*) This commit already existed in another branch; no separate mail sent -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
