Re: remove polkit from core?
On 11/12/2012 08:00 PM, Steve Grubb wrote: except that most admins will never be able to do this. The only people that get any flexibility are people who manage their own system. Everyone else likely has some compliance issues and they have to be verifiably in configuration. What will happen is the generic js file will be SHA256 hashed and we'll check the file's hash in SCAP and report the system as out of configuration. This isn't completely sufficient—you also have to make sure that there isn't another Javascript snippet which overrides the operation of the valid script. -- Florian Weimer / Red Hat Product Security Team -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: remove polkit from core?
Hi Steve, On 12.11.2012 21:00, Steve Grubb wrote: I think its a bad idea to have too much flexibility for access control systems. They have to be verifiable. If you have to comply to PCI-DSS or the DISA STIG or any other standard, you have to be able to demonstrate you are in the approved config. No one can write a test that can tell if the rules really are sound. So, what will happen is one set will be chosen for better or worse, it will be SHA256 hashed. And no one can change anything in it without being out of compliance. The benefit of the name=value setup is that we can pick out the things that matter and skip everything else which truly gives flexibility when needing to demonstrate compliance. My question is: Whether be acceptable the required compliance analysis to be performed on rules written in simplified rule language like Datalog instead of imperative scripted evaluation in some future version of polkit ... ? (It seems to me that e.g. Datalog is good enough both as flexibility and static analysis (symbolic evaluation), furthermore IMO declarative rules are less error prone for sysadmins than scripting) Kind Regards, Alek -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
File Compress-Raw-Lzma-2.058.tar.gz uploaded to lookaside cache by pghmcfc
A file has been added to the lookaside cache for perl-Compress-Raw-Lzma: f43045dfb1701d161027dd8d2031975c Compress-Raw-Lzma-2.058.tar.gz -- 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: raising warning flag on firewalld-default feature
On 11/12/2012 08:53 PM, Matthew Miller wrote: On Sat, Nov 10, 2012 at 09:53:13PM +0100, Kevin Kofler wrote: I really don't understand why a core system component such as firewalld is implemented in Python! Here, I mostly don't see the reason for it to be running all the time. Couldn't it be dbus activated, and then go away when it's not needed? Then, it would matter less what it was written in. It would loose internal state if it would be D-BUS activated. Also each call would take a lot longer, which is bad for example for libvirt. And for reducing space use: I think it might also be nice to break python 2to3 and idle out of the python-libs package. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
The GNOME 3.6.2 Megaupdate
Hi, It's time for the last big GNOME update for F18 to bring bug fixes and translation updates to users! If anybody wants to add builds to the GNOME 3.6.2 update, now is the time to do it. Like usual, please use the spreadsheet: https://docs.google.com/spreadsheet/ccc?key=0AtzJKpbiGX1zdGJzeU9waFJFZmgyQzBuN2VxU0lxbHcpli=1 Thanks, Kalev -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[perl-Compress-Raw-Bzip2] Created tag perl-Compress-Raw-Bzip2-2.058-1.fc18
The lightweight tag 'perl-Compress-Raw-Bzip2-2.058-1.fc18' was created pointing to: 3e356c4... Update to 2.058 -- 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
[perl-Compress-Raw-Bzip2] Created tag perl-Compress-Raw-Bzip2-2.058-1.fc19
The lightweight tag 'perl-Compress-Raw-Bzip2-2.058-1.fc19' was created pointing to: 3e356c4... Update to 2.058 -- 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
F-18 Branched report: 20121113 changes
Compose started at Tue Nov 13 09:15:33 UTC 2012 Broken deps for x86_64 -- [dhcp-forwarder] dhcp-forwarder-upstart-0.10-1801.fc18.noarch requires /sbin/initctl [dvisvgm] dvisvgm-1.0.12-1.fc18.x86_64 requires libkpathsea.so.4()(64bit) [libsyncml] 1:libsyncml-0.4.6-4.fc17.i686 requires libsoup-2.2.so.8 1:libsyncml-0.4.6-4.fc17.x86_64 requires libsoup-2.2.so.8()(64bit) [mftrace] mftrace-1.2.15-8.fc18.x86_64 requires texlive-fonts [mod_pubcookie] mod_pubcookie-3.3.4a-7.fc18.x86_64 requires httpd-mmn = 0:20051115-x86-64 [openvrml] libopenvrml-0.18.9-3.fc18.i686 requires libboost_thread-mt.so.1.48.0 libopenvrml-0.18.9-3.fc18.i686 requires libboost_system-mt.so.1.48.0 libopenvrml-0.18.9-3.fc18.i686 requires libboost_filesystem-mt.so.1.48.0 libopenvrml-0.18.9-3.fc18.x86_64 requires libboost_thread-mt.so.1.48.0()(64bit) libopenvrml-0.18.9-3.fc18.x86_64 requires libboost_system-mt.so.1.48.0()(64bit) libopenvrml-0.18.9-3.fc18.x86_64 requires libboost_filesystem-mt.so.1.48.0()(64bit) libopenvrml-gl-0.18.9-3.fc18.i686 requires libboost_thread-mt.so.1.48.0 libopenvrml-gl-0.18.9-3.fc18.i686 requires libboost_system-mt.so.1.48.0 libopenvrml-gl-0.18.9-3.fc18.i686 requires libboost_filesystem-mt.so.1.48.0 libopenvrml-gl-0.18.9-3.fc18.x86_64 requires libboost_thread-mt.so.1.48.0()(64bit) libopenvrml-gl-0.18.9-3.fc18.x86_64 requires libboost_system-mt.so.1.48.0()(64bit) libopenvrml-gl-0.18.9-3.fc18.x86_64 requires libboost_filesystem-mt.so.1.48.0()(64bit) openvrml-java-0.18.9-3.fc18.x86_64 requires libboost_thread-mt.so.1.48.0()(64bit) openvrml-java-0.18.9-3.fc18.x86_64 requires libboost_system-mt.so.1.48.0()(64bit) openvrml-java-0.18.9-3.fc18.x86_64 requires libboost_filesystem-mt.so.1.48.0()(64bit) openvrml-javascript-0.18.9-3.fc18.x86_64 requires libboost_thread-mt.so.1.48.0()(64bit) openvrml-javascript-0.18.9-3.fc18.x86_64 requires libboost_system-mt.so.1.48.0()(64bit) openvrml-javascript-0.18.9-3.fc18.x86_64 requires libboost_filesystem-mt.so.1.48.0()(64bit) openvrml-nodes-0.18.9-3.fc18.x86_64 requires libboost_thread-mt.so.1.48.0()(64bit) openvrml-nodes-0.18.9-3.fc18.x86_64 requires libboost_system-mt.so.1.48.0()(64bit) openvrml-nodes-0.18.9-3.fc18.x86_64 requires libboost_filesystem-mt.so.1.48.0()(64bit) openvrml-xembed-0.18.9-3.fc18.x86_64 requires libboost_thread-mt.so.1.48.0()(64bit) openvrml-xembed-0.18.9-3.fc18.x86_64 requires libboost_system-mt.so.1.48.0()(64bit) openvrml-xembed-0.18.9-3.fc18.x86_64 requires libboost_filesystem-mt.so.1.48.0()(64bit) [perl-OpenOffice-UNO] perl-OpenOffice-UNO-0.07-3.fc17.x86_64 requires perl(:MODULE_COMPAT_5.14.2) [pyfuzzy] pyfuzzy-0.1.0-5.fc18.noarch requires antlr3-python [python-flask] 1:python-flask-doc-0.9-1.fc18.noarch requires python-flask = 0:0.9-1.fc18 [reciteword] reciteword-0.8.4-10.fc18.x86_64 requires esound [resource-agents] resource-agents-3.9.2-3.fc18.5.x86_64 requires libplumbgpl.so.2()(64bit) resource-agents-3.9.2-3.fc18.5.x86_64 requires libplumb.so.2()(64bit) [ruby-revolution] ruby-revolution-0.5-4.svn210.fc18.15.x86_64 requires libedataserver-1.2.so.16()(64bit) ruby-revolution-0.5-4.svn210.fc18.15.x86_64 requires libecal-1.2.so.12()(64bit) ruby-revolution-0.5-4.svn210.fc18.15.x86_64 requires libebook-1.2.so.13()(64bit) [rubygem-calendar_date_select] rubygem-calendar_date_select-1.15-6.fc17.noarch requires ruby(abi) = 0:1.8 [rubygem-linecache] rubygem-linecache-0.43-5.fc17.x86_64 requires ruby(abi) = 0:1.8 rubygem-linecache-0.43-5.fc17.x86_64 requires libruby.so.1.8()(64bit) [rubygem-ruby-debug] rubygem-ruby-debug-0.10.5-0.3.rc1.fc17.1.noarch requires ruby(abi) = 0:1.8 [rubygem-ruby-debug-base] rubygem-ruby-debug-base-0.10.5-0.1.rc1.fc17.1.x86_64 requires ruby(abi) = 0:1.8 rubygem-ruby-debug-base-0.10.5-0.1.rc1.fc17.1.x86_64 requires libruby.so.1.8()(64bit) [tetex-tex4ht] tetex-tex4ht-1.0.2008_09_16_1413-10.fc18.x86_64 requires libkpathsea.so.4()(64bit) [znc-infobot] znc-infobot-0.206-2.fc18.x86_64 requires znc = 0:0.206 Broken deps for i386 -- [dhcp-forwarder] dhcp-forwarder-upstart-0.10-1801.fc18.noarch requires /sbin/initctl [dvisvgm] dvisvgm-1.0.12-1.fc18.i686 requires libkpathsea.so.4 [libsyncml] 1:libsyncml-0.4.6-4.fc17.i686 requires libsoup-2.2.so.8 [mftrace] mftrace-1.2.15-8.fc18.i686 requires texlive-fonts [mod_pubcookie] mod_pubcookie-3.3.4a-7.fc18.i686 requires httpd-mmn = 0:20051115-x86-32 [openvrml] libopenvrml-0.18.9-3.fc18.i686 requires libboost_thread-mt.so.1.48.0
Re: raising warning flag on firewalld-default feature
On Tue, Nov 13, 2012 at 12:53:10PM +0100, Thomas Woerner wrote: On 11/12/2012 08:53 PM, Matthew Miller wrote: On Sat, Nov 10, 2012 at 09:53:13PM +0100, Kevin Kofler wrote: I really don't understand why a core system component such as firewalld is implemented in Python! Here, I mostly don't see the reason for it to be running all the time. Couldn't it be dbus activated, and then go away when it's not needed? Then, it would matter less what it was written in. It would loose internal state if it would be D-BUS activated. Surely it could persist it somewhere? However I doubt that changing firewalld to be dbus activated would make any actual difference to memory usage. We do have a thing called swap ... The reason I object to firewalld being written in Python are the excessive dependencies this adds for a component that should be included in a minimal/core set of packages. OCaml, you see ... Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones virt-df lists disk usage of guests without needing to install any software inside the virtual machine. Supports Linux and Windows. http://et.redhat.com/~rjones/virt-df/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: raising warning flag on firewalld-default feature
On Tue, Nov 13, 2012 at 01:19:36PM +, Richard W.M. Jones wrote: Here, I mostly don't see the reason for it to be running all the time. Couldn't it be dbus activated, and then go away when it's not needed? Then, it would matter less what it was written in. It would loose internal state if it would be D-BUS activated. Surely it could persist it somewhere? Like in the actual netfilter rules? -- Tomasz Torcz God, root, what's the difference? xmpp: zdzich...@chrome.pl God is more forgiving. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: iprutils -- should this be pulled in by anaconda instead of in core?
On Mon, Nov 12, 2012 at 10:23:28PM -0500, Matthew Miller wrote: The iprutils package provides utilities for IBM Power Linux RAID adapters. Up until current rawhide, this was exclusive to that architecture. However, now it's built on all archs (because these devices _may_ be found there). I know anaconda currently does some magic to install storage-related packages; should this be included there rather than on the minimal list? It's not a big package, but unless it's necessary I don't think we want to force it on every system everywhere, do we? anaconda would only need to do that if those utilities are required to activate or otherwise make the device available. If they are required, then we also need to know how these RAID devices differ from other RAID devices. If it's substantially different, a new device should be created so that the device can be represented properly and iprutils included. -- David Cantrell dcantr...@redhat.com Manager, Installer Engineering Team Red Hat, Inc. | Westford, MA | EST5EDT -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: macros.cmake: set -DCMAKE_BUILD_TYPE=ReleaseWithDebInfo by default
On Mon, Nov 12, 2012 at 11:14 PM, Ralf Corsepius rc040...@freenet.dewrote: On 11/13/2012 05:05 AM, Richard Shaw wrote: I own several packages that use cmake and I've taken to setting the release type to RelWithDebugInfo like you suggest. One question I've had but never gotten around to asking is: Regardless of whether you use Release or RelWithDebugInfo, should we be building with -O3? It seems odd that the rpm macro defaults to doing something that is explicitly against the packaging guidelines. Your sentence confuses me or I am missing somthing. The FPG intention is to mandate using RPM_OPT_FLAGS. These so far have contained -O2. So, unless something has recently been changed, using -O3 would qualify as a bug somewhere. I'd have to go back and look but the last flag wins, right? I've had cmake projects where RPM_OPT_FLAGS was used but the cmake options were appended, so I ended up with -O3... Richard -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: macros.cmake: set -DCMAKE_BUILD_TYPE=ReleaseWithDebInfo by default
On Mon, Nov 12, 2012 at 11:14 PM, Ralf Corsepius rc040...@freenet.dewrote: On 11/13/2012 05:05 AM, Richard Shaw wrote: I own several packages that use cmake and I've taken to setting the release type to RelWithDebugInfo like you suggest. One question I've had but never gotten around to asking is: Regardless of whether you use Release or RelWithDebugInfo, should we be building with -O3? It seems odd that the rpm macro defaults to doing something that is explicitly against the packaging guidelines. Your sentence confuses me or I am missing somthing. The FPG intention is to mandate using RPM_OPT_FLAGS. These so far have contained -O2. So, unless something has recently been changed, using -O3 would qualify as a bug somewhere. And regardless, the question is if -O3 is explicitly against the guidelines, why is it in the rpm macros file at all. Richard -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Anything changed on rawhide builders recently? Can't build ladvd
On Wed, Nov 7, 2012 at 12:21 PM, David Howells dhowe...@redhat.com wrote:
David Howells dhowe...@redhat.com wrote:
A better way to do this might be to make the header installation discard the
_UAPI prefix that got added.
As the attached patch.
David
---
commit 75a88e14a97d239a47cbd0fc55fc23416007d733
Author: David Howells dhowe...@redhat.com
Date: Wed Nov 7 17:14:14 2012 +
UAPI: Strip the _UAPI prefix from header guards during header installation
Strip the _UAPI prefix from header guards during header installation so
that
any userspace dependencies aren't affected. glibc, for example, checks
for
linux/types.h, linux/kernel.h, linux/compiler.h and linux/list.h - though
the
last two aren't actually exported.
Signed-off-by: David Howells dhowe...@redhat.com
I tested this locally by applying this to the latest 3.7 tree and doing
make headers_install pointing to a throw-away dir. When comparing the
headers installed there with those from a 3.6 kernel installed in /usr,
there were no differences in the include guards. That seems to produce
the consistent results we'd want. So:
Acked-by: Josh Boyer jwbo...@redhat.com
josh
diff --git a/scripts/headers_install.pl b/scripts/headers_install.pl
index 239d22d..6c353ae 100644
--- a/scripts/headers_install.pl
+++ b/scripts/headers_install.pl
@@ -42,6 +42,9 @@ foreach my $filename (@files) {
$line =~ s/(^|\s)(inline)\b/$1__$2__/g;
$line =~ s/(^|\s)(asm)\b(\s|[(]|$)/$1__$2__$3/g;
$line =~ s/(^|\s|[(])(volatile)\b(\s|[(]|$)/$1__$2__$3/g;
+ $line =~ s/#ifndef _UAPI/#ifndef /;
+ $line =~ s/#define _UAPI/#define /;
+ $line =~ s!#endif /[*] _UAPI!#endif /* !;
printf {$out} %s, $line;
}
close $out;
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [X-post] Reminder: FESCo, FAmSCo, Board election nomination period and questionnaire collection ends in about 10 hours!
Hi folks, Another gentle reminder. There are about 10 more hours to go. Please complete your nominations ASAP! I apologise for the spam, but we'd like to have enough candidates to make it a fruitful election. :) On Tue, 2012-11-13 at 10:16 +1100, Ankur Sinha wrote: Attention all fedorians! This is an urgent but gentle reminder that the nomination period for the elections ends today (November 13 at 2359 UTC). Please update the wiki page with your nominations before the nominations period ends later today if you'd like to be considered and voted for! All the best! Fedora Project Board (two seats) FESCo (Engineering) (four seats) FAmSCo (Ambassadors) (three seats) I'd also like to remind you that that the questionnaire will close today as well: https://fedoraproject.org/wiki/F19_elections_questionnaire Please regard this as critical: - We currently have ONE nomination for FAmSCo (to fill 3 seats?), THREE for FESCo (to fill 4 seats?) and *NONE* for the Fedora Board (to fill 2 seats!). - We have no questions in the questionnaire at all. :( -- Thanks, Warm regards, Ankur: FranciscoD Please only print if necessary. Looking to contribute to Fedora? Look here: https://fedoraproject.org/wiki/Fedora_Join_SIG http://fedoraproject.org/wiki/User:Ankursinha http://dodoincfedora.wordpress.com/ signature.asc Description: This is a digitally signed message part -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: macros.cmake: set -DCMAKE_BUILD_TYPE=ReleaseWithDebInfo by default
On 11/13/2012 02:48 PM, Richard Shaw wrote: On Mon, Nov 12, 2012 at 11:14 PM, Ralf Corsepius rc040...@freenet.de mailto:rc040...@freenet.de wrote: On 11/13/2012 05:05 AM, Richard Shaw wrote: I own several packages that use cmake and I've taken to setting the release type to RelWithDebugInfo like you suggest. One question I've had but never gotten around to asking is: Regardless of whether you use Release or RelWithDebugInfo, should we be building with -O3? It seems odd that the rpm macro defaults to doing something that is explicitly against the packaging guidelines. Your sentence confuses me or I am missing somthing. The FPG intention is to mandate using RPM_OPT_FLAGS. These so far have contained -O2. So, unless something has recently been changed, using -O3 would qualify as a bug somewhere. And regardless, the question is if -O3 is explicitly against the guidelines, why is it in the rpm macros file at all. -03 isn't directly against the guidelines. Not using or overriding vital parts of RPM_OPT_FLAGS is against the guidelines. Overriding optimization levels (here: -O3) would be amongst these prohibited items. Ralf -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [@core] working definition for the minimal package set
2012/11/12 Matthew Miller mat...@fedoraproject.org [...] Yeah: if we get to the point where every real install has to add the same subset of packages to core, I don't think we've succeeded in doing anything except make more work for the whole world. A cron daemon and (at least basic) MTA fall in the same area, I think. But what about ssh-clients? Is there a reasonable yardstick rule we can make, or is it pragmatically best to just make per-package decisions? Depends on the scope. I think that the B definition plus ssh-server goes into the right direction. The minimal system should have networking in place and ssh ready to interact with the fresh installation. More stuff is not necessary. If you need more, invoke yum and install whatever you need (so yum should also be in the core definition). Things like cron, MTA and other stuff should from my point of view not be in the core installation, this is more something like core plus lsb. Regards Thomas -- Linux ... enjoy the ride! -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[perl-IO-Compress-Lzma/f18] Update to 2.058 (general performance improvements)
Summary of changes: ad0694c... Update to 2.058 (general performance improvements) (*) (*) 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: [@core] working definition for the minimal package set
2012/11/13 Christopher Meng cicku...@gmail.com I don't know Fedora minimal looks like...FOR SERVER USE the Minimal includes: [...] BUT FOR DESKTOP USE,I think it should also have a desktop based on server version...That's what is troubling me...If it [...] This is something we shouldn't mix. When we are talking about core I would assume it is the core for everything, regardless if it is a server or a desktop. So if we talk about server minimal or desktop minimal, we talk about core + X for server minimal and core + Y for desktop minimal. So from my point of view, core is not minimal, it is the base for every later taste, regardless if server, desktop, mobile or whatever. Regards, Thomas -- Linux ... enjoy the ride! -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[perl-DateTime-Locale] Add BR, fix whitespaces.
commit 124c66a6f5074e0142eda8caa78e6789e137fbf3
Author: Marcela Mašláňová mmasl...@redhat.com
Date: Tue Nov 13 15:34:58 2012 +0100
Add BR, fix whitespaces.
perl-DateTime-Locale.spec | 10 --
1 files changed, 8 insertions(+), 2 deletions(-)
---
diff --git a/perl-DateTime-Locale.spec b/perl-DateTime-Locale.spec
index 2e7c12c..7a9f72a 100644
--- a/perl-DateTime-Locale.spec
+++ b/perl-DateTime-Locale.spec
@@ -1,6 +1,6 @@
Name: perl-DateTime-Locale
Version:0.45
-Release:4%{?dist}
+Release:5%{?dist}
Summary:Localization support for DateTime.pm
# package itself is 'same terms as Perl'
# modules under DateTime/Locale/ are generated from data provided by the CLDR
project
@@ -11,6 +11,9 @@ URL:http://search.cpan.org/dist/DateTime-Locale/
Source0:
http://www.cpan.org/authors/id/D/DR/DROLSKY/DateTime-Locale-%{version}.tar.gz
BuildArch: noarch
BuildRequires: perl = 0:5.006
+BuildRequires: perl(base)
+BuildRequires: perl(Carp)
+BuildRequires: perl(File::Spec)
BuildRequires: perl(List::MoreUtils)
BuildRequires: perl(Module::Build)
BuildRequires: perl(Params::Validate) = 0.91
@@ -23,7 +26,7 @@ Requires: perl(:MODULE_COMPAT_%(eval `%{__perl}
-V:version`; echo $versi
# Requires: perl-DateTime = 2:0.70-1
# but DateTime::Locale doesn't strictly require DateTime
# and this would introduce circular build dependencies
-Conflicts: perl-DateTime = 1:0.7000-3.fc16
+Conflicts: perl-DateTime = 1:0.7000-3.fc16
%{?perl_default_filter}
@@ -58,6 +61,9 @@ find %{buildroot} -depth -type d -exec rmdir {} 2/dev/null \;
%{_mandir}/man3/*
%changelog
+* Tue Nov 13 2012 Marcela Mašláňová mmasl...@redhat.com - 0.45-5
+- Add BR, fix whitespaces
+
* Fri Jul 20 2012 Fedora Release Engineering rel-...@lists.fedoraproject.org
- 0.45-4
- Rebuilt for https://fedoraproject.org/wiki/Fedora_18_Mass_Rebuild
--
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: remove polkit from core?
On Tuesday, November 13, 2012 12:50:11 PM Alek Paunov wrote: Hi Steve, On 12.11.2012 21:00, Steve Grubb wrote: I think its a bad idea to have too much flexibility for access control systems. They have to be verifiable. If you have to comply to PCI-DSS or the DISA STIG or any other standard, you have to be able to demonstrate you are in the approved config. No one can write a test that can tell if the rules really are sound. So, what will happen is one set will be chosen for better or worse, it will be SHA256 hashed. And no one can change anything in it without being out of compliance. The benefit of the name=value setup is that we can pick out the things that matter and skip everything else which truly gives flexibility when needing to demonstrate compliance. My question is: Whether be acceptable the required compliance analysis to be performed on rules written in simplified rule language like Datalog instead of imperative scripted evaluation in some future version of polkit ... ? The standard that everyone is embracing for compliance checking is called SCAP. Parts of it are also being looked at by the IETF for standardization, too. I did a presentation on SCAP for the aqueduct project here: https://fedorahosted.org/aqueduct/attachment/wiki/Call/intro-SCAP-tech- talk.pdf XCCDF represents the policy that you wish to enforce. It is abstract in that it does not know exactly what file to access or how to perform the check. That is the job of OVAL, which is concrete in that it has the exact tests and knows which file to look at. The OVAL language has a number of checking mechanisms: http://oval.mitre.org/language/version5.10.1/OVAL_Language_Specification_01-20-2012.pdf For anything with name=value, we normally use the textfilecontent54 which we can define a regex to pick out the items of interest. However, with a language, you have multiple ways of expressing the same idea. for example, if (foo() 500) and uid = foo(); if (uid 500) and start = 500; uid = foo(); if (uid start) do the same thing. Then throw in comments and indentation and it you have lots of possibilities. This is also not considering whether the code actually meets the intent or allows unintended functionality (exploits). The only thing I can think of, using what's currently available in SCAP is to use filehash58 and call it a day. This has the drawback of notifying the admin that the hash doesn't match instead of a useful, actionable, message. They will be left wondering why the hash doesn't match and what they can do to fix it. This is not going to help security. This should be a lesson to anyone wanting to adopt a languge for system configuration and policy decision. (It seems to me that e.g. Datalog is good enough both as flexibility and static analysis (symbolic evaluation), furthermore IMO declarative rules are less error prone for sysadmins than scripting) Do you have a reference for it? I would almost think that you would want to specify system access rights in a Formal Language which supports the notion of proofs if anything like this were done. In that event, standards work would have to be done in preparation for this. I sit on the OVAL editorial Board, so I could raise the issue to the Board. But javascript for access control policy is a train wreck for anyone needing to demonstrate compliance. -Steve -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: MariaDB: Packagers needed
On Mon, Nov 12, 2012 at 8:45 PM, Christopher Meng cicku...@gmail.com wrote: So IMO I think now that we can accept different database tools into repo,it's available for us to include mariadb.Official says they will try to become a independent software but not a mod based on MySQL... Maybe easy for review? I don't know exactly... Thank you for that. I will try to contact upstream today in order to seek guidance for the future and present. -- It's hard to be free... but I love to struggle. Love isn't asked for; it's just given. Respect isn't asked for; it's earned! Renich Bon Ciric http://www.woralelandia.com/ http://www.introbella.com/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: livemedia-creator and the fedora build system [was Re: appliance-creator: how can I ...]
On Mon, Nov 12, 2012 at 07:20:52PM -0800, Brian C. Lane wrote: Yes. I haven't focused on getting it working for Beta since they decided to continue to use livecd-creator, but I will have it working for Final. With that timeline, I think it's going to be hard to *use* it for F18 Final, but I can certainily start testing it. Then, we can look at adopting it for F19. -- Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ mat...@fedoraproject.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: raising warning flag on firewalld-default feature
On 11/12/2012 07:53 PM, Matthew Miller wrote: On Sat, Nov 10, 2012 at 09:53:13PM +0100, Kevin Kofler wrote: I really don't understand why a core system component such as firewalld is implemented in Python! Here, I mostly don't see the reason for it to be running all the time. Couldn't it be dbus activated, and then go away when it's not needed? Then, it would matter less what it was written in. It could be argued that python is more suited to long lived programs: $ time /bin/true real0m0.002s $ time python -c True real0m0.049s $ time python3 -c True real0m0.165s And for reducing space use: I think it might also be nice to break python 2to3 and idle out of the python-libs package. splitting python-libs (25MB here), seems worthwhile. python-libs can bb changed to a subpackage that just depends on various split subpackages, and then as needed various packages like yum etc. can adjust dependencies to require just the subpackages they need. I remember doing a dist of python for an embedded system that was 2.1MB in total and was enough to support cherrypy. cheers, Pádraig. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: raising warning flag on firewalld-default feature
On Tue, Nov 13, 2012 at 02:28:17PM +0100, Tomasz Torcz wrote: Here, I mostly don't see the reason for it to be running all the time. Couldn't it be dbus activated, and then go away when it's not needed? Then, it would matter less what it was written in. It would loose internal state if it would be D-BUS activated. Surely it could persist it somewhere? Like in the actual netfilter rules? Yes. It has to be able to save internal state *somehow*, because if restarting the service breaks everything, we're not gaining much over the old way, are we? Plus, for a critical service like this, the service needs to be designed to be as robust as possible in situations where it might crash or get killed arbitrarily. And for things like the ten-second-temporary rule, it could hang around for a while. -- Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ mat...@fedoraproject.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: raising warning flag on firewalld-default feature
On Tue, Nov 13, 2012 at 02:41:44PM +, Pádraig Brady wrote: And for reducing space use: I think it might also be nice to break python 2to3 and idle out of the python-libs package. splitting python-libs (25MB here), seems worthwhile. python-libs can bb changed to a subpackage that just depends on various split subpackages, and then as needed various packages like yum etc. can adjust dependencies to require just the subpackages they need. Yep. I pick those two because they're both big and both the kind of lib where if your package needs them, you probably know it. -- Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ mat...@fedoraproject.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: raising warning flag on firewalld-default feature
Once upon a time, Pádraig Brady p...@draigbrady.com said: It could be argued that python is more suited to long lived programs: $ time /bin/true real 0m0.002s $ time python -c True real 0m0.049s Aside from that being a meaningless, worst case example, an overhead of .047 seconds is hardly worth worrying about unless the command in question is run multiple times per minute, all the time. And besides: $ time perl -e 1 real0m0.008s Perl is 6 times faster than Python! :) -- Chris Adams cmad...@hiwaay.net Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[perl-DateTime-TimeZone/f18] update to latest upstream version - Olson 2012j
Summary of changes: f03e597... update to latest upstream version - Olson 2012j (*) (*) 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
[perl-DateTime-TimeZone/f17] update to latest upstream version - Olson 2012j
Summary of changes: f03e597... update to latest upstream version - Olson 2012j (*) (*) 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
[perl-DateTime-TimeZone/f16] update to latest upstream version - Olson 2012j
Summary of changes: f03e597... update to latest upstream version - Olson 2012j (*) (*) 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: iprutils -- should this be pulled in by anaconda instead of in core?
On Tue, Nov 13, 2012 at 08:41:00AM -0500, David Cantrell wrote: I know anaconda currently does some magic to install storage-related packages; should this be included there rather than on the minimal list? It's not a big package, but unless it's necessary I don't think we want to force it on every system everywhere, do we? anaconda would only need to do that if those utilities are required to activate or otherwise make the device available. If that's _not_ the case, I don't see why they'd be in core either. If one of the package maintainers doesn't respond I'll ping them and ask. -- Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ mat...@fedoraproject.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: raising warning flag on firewalld-default feature
On Tue, Nov 13, 2012 at 08:51:59AM -0600, Chris Adams wrote: $ time /bin/true real0m0.002s $ time python -c True real0m0.049s Aside from that being a meaningless, worst case example, an overhead of .047 seconds is hardly worth worrying about unless the command in question is run multiple times per minute, all the time. And in that case I assume it would stay active. -- Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ mat...@fedoraproject.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: raising warning flag on firewalld-default feature
On Fri, Nov 09, 2012 at 11:57:12AM -0500, Matthew Miller wrote: - no way to run once and exit for cloud guests with *non-dynamic* firewall needs, and it's a non-trivial user of system resources You can use the old firewall environment for static firewall use cases. Everything is still there. Can I use them *both together*? If so, okay. If not, we should keep entirely with the old one until this is really ready to take over. This is still unclear to me. Anaconda is pulling in firewalld for post-install configuration. Do we still _really_ have the option of the old firewall? -- Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ mat...@fedoraproject.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: raising warning flag on firewalld-default feature
On Fri, Nov 09, 2012 at 11:57:12AM -0500, Matthew Miller wrote: - no way to run once and exit for cloud guests with *non-dynamic* firewall needs, and it's a non-trivial user of system resources You can use the old firewall environment for static firewall use cases. Everything is still there. Can I use them *both together*? If so, okay. If not, we should keep entirely with the old one until this is really ready to take over. This is still unclear to me. Anaconda is pulling in firewalld for post-install configuration. Do we still _really_ have the option of the old firewall? -- Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ mat...@fedoraproject.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[perl-IO-Compress-Lzma] Created tag perl-IO-Compress-Lzma-2.058-1.fc18
The lightweight tag 'perl-IO-Compress-Lzma-2.058-1.fc18' was created pointing to: ad0694c... Update to 2.058 (general performance improvements) -- 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
[perl-IO-Compress-Lzma] Created tag perl-IO-Compress-Lzma-2.058-1.fc19
The lightweight tag 'perl-IO-Compress-Lzma-2.058-1.fc19' was created pointing to: ad0694c... Update to 2.058 (general performance improvements) -- 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
[Bug 875791] perl-Net-SSH2-0.46 is available
https://bugzilla.redhat.com/show_bug.cgi?id=875791 Petr Šabata psab...@redhat.com changed: What|Removed |Added Status|ASSIGNED|CLOSED Fixed In Version||perl-Net-SSH2-0.46-1.fc19 Resolution|--- |RAWHIDE Last Closed||2012-11-13 09:09:52 -- You are receiving this mail because: You are on the CC list for the bug. -- 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
[perl-Data-OptList] Fix wrong script interpreter
commit 43f728027aff916af535519b7e0f1124d64497d0
Author: Jitka Plesnikova jples...@redhat.com
Date: Tue Nov 13 16:09:41 2012 +0100
Fix wrong script interpreter
perl-Data-OptList.spec |7 ++-
1 files changed, 6 insertions(+), 1 deletions(-)
---
diff --git a/perl-Data-OptList.spec b/perl-Data-OptList.spec
index 8d822d4..b0c7c4e 100644
--- a/perl-Data-OptList.spec
+++ b/perl-Data-OptList.spec
@@ -1,7 +1,7 @@
Name: perl-Data-OptList
Summary:Parse and validate simple name/value option pairs
Version:0.107
-Release:7%{?dist}
+Release:8%{?dist}
License:GPL+ or Artistic
Group: Development/Libraries
URL:http://search.cpan.org/dist/Data-OptList/
@@ -44,6 +44,8 @@ following a name is its value.
%prep
%setup -q -n Data-OptList-%{version}
+perl -pi -e 's|^#!perl|#!/usr/bin/perl|' t/*
+
%build
perl Makefile.PL INSTALLDIRS=vendor
make %{?_smp_mflags}
@@ -63,6 +65,9 @@ make test RELEASE_TESTING=1
%{_mandir}/man3/Data::OptList.3pm*
%changelog
+* Tue Nov 13 2012 Jitka Plesnikova jples...@redhat.com - 0.107-8
+- Fix wrong script interpreter
+
* Fri Jul 20 2012 Fedora Release Engineering rel-...@lists.fedoraproject.org
- 0.107-7
- Rebuilt for https://fedoraproject.org/wiki/Fedora_18_Mass_Rebuild
--
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: remove polkit from core?
On Tuesday, November 13, 2012 09:37:07 AM Steve Grubb wrote: For anything with name=value, we normally use the textfilecontent54 which we can define a regex to pick out the items of interest. However, with a language, you have multiple ways of expressing the same idea. for example, if (foo() 500) and uid = foo(); if (uid 500) and start = 500; uid = foo(); if (uid start) do the same thing. Then throw in comments and indentation and it you have lots of possibilities. This is also not considering whether the code actually meets the intent or allows unintended functionality (exploits). The only thing I can think of, using what's currently available in SCAP is to use filehash58 and call it a day. This has the drawback of notifying the admin that the hash doesn't match instead of a useful, actionable, message. They will be left wondering why the hash doesn't match and what they can do to fix it. And then if the javascript was found to have a vulnerability in it and it got fixed or perhaps updated to allow smartcard functionality or something...now the hash doesn't match. The old vulnerable hash will be forever encoded into guidance with almost no way to get a standards body to change it. With name = value, the vulnerability would likely be in the compiled code and the compliance check would pass. In this case the settings are verifiably correct because the config file is not changed and part of the compliance check usually involves running the OVAL content the Red Hat security response team generates which checks the rpm version. -Steve This is not going to help security. This should be a lesson to anyone wanting to adopt a languge for system configuration and policy decision. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [Test-Announce] Fedora 18 Beta Test Compose 8 (TC8) Available Now!
On Sun, 11 Nov 2012 18:39:29 +0100, Reindl Harald wrote: please no - O2 is a performance improvement while minidebuginfo is the opposite, not only bloating the size, also bloadting the data to laod from disk FYI minidebuginfo does not affect loading from disk (mostly) in any way. See 'readelf -WSl', '.gnu_debugdata' is in Section Headers but it is not covered in any way by Program Headers so it is ignored during runtime. There are sure just some minor issues of more data load fragmentation etc. just .gnu_debugdata itself is not loaded during execution. Jan -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[perl-HTTP-Daemon] Modernize the spec, fix dependencies, and drop command macros
commit 0976bf010875df653bd9aeed2580b756bb9b49af
Author: Petr Šabata con...@redhat.com
Date: Tue Nov 13 16:33:25 2012 +0100
Modernize the spec, fix dependencies, and drop command macros
perl-HTTP-Daemon.spec | 19 +++
1 files changed, 11 insertions(+), 8 deletions(-)
---
diff --git a/perl-HTTP-Daemon.spec b/perl-HTTP-Daemon.spec
index 030f624..5c8f166 100644
--- a/perl-HTTP-Daemon.spec
+++ b/perl-HTTP-Daemon.spec
@@ -1,12 +1,13 @@
Name: perl-HTTP-Daemon
Version:6.01
-Release:3%{?dist}
+Release:4%{?dist}
Summary:Simple HTTP server class
License:GPL+ or Artistic
Group: Development/Libraries
URL:http://search.cpan.org/dist/HTTP-Daemon/
Source0:
http://www.cpan.org/authors/id/G/GA/GAAS/HTTP-Daemon-%{version}.tar.gz
BuildArch: noarch
+BuildRequires: perl(Carp)
BuildRequires: perl(ExtUtils::MakeMaker)
BuildRequires: perl(HTTP::Date) = 6
BuildRequires: perl(HTTP::Request) = 6
@@ -22,7 +23,7 @@ BuildRequires: perl(Config)
BuildRequires: perl(Test::More)
BuildRequires: perl(Socket)
BuildRequires: perl(IO::Socket::INET)
-Requires: perl(:MODULE_COMPAT_%(eval `%{__perl} -V:version`; echo
$version))
+Requires: perl(:MODULE_COMPAT_%(eval `perl -V:version`; echo $version))
Requires: perl(HTTP::Date) = 6
Requires: perl(HTTP::Request) = 6
Requires: perl(HTTP::Response) = 6
@@ -50,25 +51,27 @@ IO::Socket::INET, so you can perform socket operations
directly on it too.
%setup -q -n HTTP-Daemon-%{version}
%build
-%{__perl} Makefile.PL INSTALLDIRS=vendor
+perl Makefile.PL INSTALLDIRS=vendor
make %{?_smp_mflags}
%install
-make pure_install PERL_INSTALL_ROOT=$RPM_BUILD_ROOT
-find $RPM_BUILD_ROOT -type f -name .packlist -exec rm -f {} \;
-find $RPM_BUILD_ROOT -depth -type d -exec rmdir {} 2/dev/null \;
-%{_fixperms} $RPM_BUILD_ROOT/*
+make pure_install DESTDIR=%{buildroot}
+find %{buildroot} -type f -name .packlist -exec rm -f {} \;
+find %{buildroot} -depth -type d -exec rmdir {} 2/dev/null \;
+%{_fixperms} %{buildroot}/*
%check
make test
%files
-%defattr(-,root,root,-)
%doc Changes README
%{perl_vendorlib}/*
%{_mandir}/man3/*
%changelog
+* Tue Nov 13 2012 Petr Šabata con...@redhat.com - 6.01-4
+- Modernize the spec, fix dependencies, and drop command macros
+
* Fri Jul 20 2012 Fedora Release Engineering rel-...@lists.fedoraproject.org
- 6.01-3
- Rebuilt for https://fedoraproject.org/wiki/Fedora_18_Mass_Rebuild
--
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: remove polkit from core?
On Tue, Nov 13, 2012 at 10:26:28AM -0500, Steve Grubb wrote: With name = value, the vulnerability would likely be in the compiled code and the compliance check would pass. In this case the settings are verifiably correct because the config file is not changed and part of the compliance check usually involves running the OVAL content the Red Hat security response team generates which checks the rpm version. This discussion seems significantly beyond remove polkit from core. I had seen the announcement about Javascript in Polkit and kinda shrugged -- not my ideal as a sysadmin, but, I thought, whatever. The concerns you raise go beyond the preferences of sysadmins (who, I think as a rule prefer key-value config files to complex ones). Of course, Fedora isn't (at least, not right now) targetted at the high-security situations you describe, but our major downstream consumer sure is. What (if anything) should Fedora do here? What are our options? -- Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ mat...@fedoraproject.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[perl-Devel-Cover] Bump the release to 0.94
commit ad2a26e2e7d5eb055f205db5eb31b762bfc7ffaf
Author: Marcela Mašláňová mmasl...@redhat.com
Date: Tue Nov 13 16:46:32 2012 +0100
Bump the release to 0.94
perl-Devel-Cover.spec | 27 ++-
1 files changed, 18 insertions(+), 9 deletions(-)
---
diff --git a/perl-Devel-Cover.spec b/perl-Devel-Cover.spec
index 38c633e..2b05234 100644
--- a/perl-Devel-Cover.spec
+++ b/perl-Devel-Cover.spec
@@ -1,6 +1,6 @@
Name: perl-Devel-Cover
-Version:0.89
-Release:5%{?dist}
+Version:0.97
+Release:1%{?dist}
Summary:Code coverage metrics for Perl
Group: Development/Libraries
@@ -19,6 +19,7 @@ BuildRequires: perl(Data::Dumper)
BuildRequires: perl(Digest::MD5)
BuildRequires: perl(DynaLoader)
BuildRequires: perl(Exporter)
+BuildRequires: perl(ExtUtils::MakeMaker)
BuildRequires: perl(File::Path)
BuildRequires: perl(File::Spec)
BuildRequires: perl(JSON::PP)
@@ -29,6 +30,7 @@ BuildRequires: perl(Perl::Tidy) = 20060719
BuildRequires: perl(Pod::Coverage) = 0.06
BuildRequires: perl(Pod::Coverage::CountParents)
BuildRequires: perl(Pod::Usage)
+BuildRequires: perl(PPI::HTML) = 1.07
BuildRequires: perl(Template::Provider)
BuildRequires: perl(Test)
BuildRequires: perl(Test::Differences)
@@ -48,8 +50,11 @@ Requires: perl(Test::Differences)
%global __requires_exclude
%{?__requires_exclude:%__requires_exclude|}^perl\\(Devel::Cover::Dumper\\)
%description
-This module provides code coverage metrics for Perl.
-
+This module provides code coverage metrics for Perl. Code coverage metrics
+describe how thoroughly tests exercise code. By using Devel::Cover you can
+discover areas of code not exercised by your tests and determine which
+tests to create to increase coverage. Code coverage can be considered as an
+indirect measure of quality.
%prep
%setup -q -n Devel-Cover-%{version}
@@ -62,12 +67,13 @@ make %{?_smp_mflags}
%install
-make pure_install DESTDIR=$RPM_BUILD_ROOT
-find $RPM_BUILD_ROOT -type f -name .packlist -exec rm -f {} ';'
-find $RPM_BUILD_ROOT -type f -name '*.bs' -empty -exec rm -f {} ';'
-find $RPM_BUILD_ROOT -depth -type d -exec rmdir {} 2/dev/null ';'
-chmod -R u+w $RPM_BUILD_ROOT/*
+make pure_install PERL_INSTALL_ROOT=$RPM_BUILD_ROOT
+find $RPM_BUILD_ROOT -type f -name .packlist -exec rm -f {} \;
+find $RPM_BUILD_ROOT -type f -name '*.bs' -size 0 -exec rm -f {} \;
+find $RPM_BUILD_ROOT -depth -type d -exec rmdir {} 2/dev/null \;
+
+%{_fixperms} $RPM_BUILD_ROOT/*
%check
make test
@@ -83,6 +89,9 @@ make test
%changelog
+* Tue Nov 13 2012 Marcela Mašláňová mmasl...@redhat.com 0.97-1
+- Bump the release.
+
* Fri Jul 20 2012 Fedora Release Engineering rel-...@lists.fedoraproject.org
- 0.89-5
- Rebuilt for https://fedoraproject.org/wiki/Fedora_18_Mass_Rebuild
--
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
A minimal subset of python (was Re: [@core] working definition for the minimal package set)
On Mon, 2012-11-12 at 11:28 -0500, Matthew Miller wrote: Okay, cool -- there's a lot of enthusiasm for a SIG for the core package set. So, first up on the SIG goals: clarifying our target. It's been suggested before that there's so many possibilities that this is useless, but the point here is to *pick* a reasonable choice as a group and to work with that (even if we can't get complete consensus). Then, later, when someone says but minimal could mean so many differen things! we simply say sure, but *this* is what we mean. I see three basic options for the target: A) kernel + init system and we're done B) boot to yum (with network): a text-mode bootstrap environment on which other things can be added by hand (or by kickstart) C) a traditional Unix command line environment with the expected basic tools available To me, 'C' is too wide for two reasons. First, it's too open for continual debate, because different people might expect different tools. Second, it's not necessarily the right base for the rest of the distribution, because many use cases might not really need that traditional Unix environment. I think 'A' is interesting and useful, but I don't think it should be our target, because it's not *useful enough*. We may want to eventually define a sub-group which covers just this tiny base (maybe with busybox?), but I think that's a different project. So that leaves me at *mostly B*, although I have some sympathy to the idea that we should include a few other things like a man page reader, since we're installing man pages, and a way to deliver e-mail to root, since we're installing things that send such mail. And I think the core environment should include ssh, but I'm open to the idea that even that should be an add-on. If we're targeting yum as core functionality, that implies a subset of Python: enough to run yum at least, but probably not much more. This ties into https://bugzilla.redhat.com/show_bug.cgi?id=867962 which I'd prefer to solve by introducing a python-core package. I've heard complaints from upstream that no-one can know what the python package means on any given distribution (everyone splits it out in slightly different ways). Fixing that suggests that the python package should become a metapackage that brings in everything built from the python tarball. If we go down this route, say in Fedora 19, then let's introduce a python-core or somesuch, and define it loosely to be whatever yum needs in the minimal environment. Does this sound sane? (especially from the POV of yum developers) What does yum need? Dave -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: livemedia-creator and the fedora build system [was Re: appliance-creator: how can I ...]
On Tue, Nov 13, 2012 at 09:40:06AM -0500, Matthew Miller wrote: On Mon, Nov 12, 2012 at 07:20:52PM -0800, Brian C. Lane wrote: Yes. I haven't focused on getting it working for Beta since they decided to continue to use livecd-creator, but I will have it working for Final. With that timeline, I think it's going to be hard to *use* it for F18 Final, but I can certainily start testing it. Then, we can look at adopting it for F19. Right, that decision was already made. -- Brian C. Lane | Anaconda Team | IRC: bcl #anaconda | Port Orchard, WA (PST8PDT) pgpMcA9MEOuQa.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: remove polkit from core?
On Tue, Nov 13, 2012 at 4:40 PM, Matthew Miller mat...@fedoraproject.org wrote: The concerns you raise go beyond the preferences of sysadmins (who, I think as a rule prefer key-value config files to complex ones). Of course, Fedora isn't (at least, not right now) targetted at the high-security situations you describe, but our major downstream consumer sure is. What (if anything) should Fedora do here? What are our options? So, talking about specific actions... I have recently had to search all existing polkit policies. This is no longer possible to automate because various packages ship the JavaScript policy, so I had to review those by hand. It seems that (perhaps with the exception of polkit itself) any use of JavaScript could be converted into the old format, which remains supported. So, as soon I find some free time (probably next week), I intend to ask FPC to prohibit using JavaScript if the functionality can be represented in the old .pkla, and to prepare patches to convert the 6 JS-using packages. Mirek -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: raising warning flag on firewalld-default feature
On 11/13/2012 03:46 PM, Matthew Miller wrote: On Tue, Nov 13, 2012 at 02:28:17PM +0100, Tomasz Torcz wrote: Here, I mostly don't see the reason for it to be running all the time. Couldn't it be dbus activated, and then go away when it's not needed? Then, it would matter less what it was written in. It would loose internal state if it would be D-BUS activated. Surely it could persist it somewhere? Like in the actual netfilter rules? Yes. It has to be able to save internal state *somehow*, because if restarting the service breaks everything, we're not gaining much over the old way, are we? Plus, for a critical service like this, the service needs to be designed to be as robust as possible in situations where it might crash or get killed arbitrarily. With the old static firewall model every firewall change was a complete firewall recreate with conntrack loss. With firewalld changes to the firewall are done dynamically and conntrack is preserved. If you want to recreate rules, use reload. If you restart the service with systemd, the servce gets stopped and started again, so you will loose internal state. This is how services are working. And for things like the ten-second-temporary rule, it could hang around for a while. It is using glib timeouts for this, it is not hanging around and blocking. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: raising warning flag on firewalld-default feature
On 11/13/2012 04:02 PM, Matthew Miller wrote: On Fri, Nov 09, 2012 at 11:57:12AM -0500, Matthew Miller wrote: - no way to run once and exit for cloud guests with *non-dynamic* firewall needs, and it's a non-trivial user of system resources You can use the old firewall environment for static firewall use cases. Everything is still there. Can I use them *both together*? If so, okay. If not, we should keep entirely with the old one until this is really ready to take over. This is still unclear to me. Anaconda is pulling in firewalld for post-install configuration. Do we still _really_ have the option of the old firewall? You can not use both at the same time, as they are doing things completely different. The static firewall stuff is not active by default, but everything is available. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: raising warning flag on firewalld-default feature
On Tue, Nov 13, 2012 at 02:41:44PM +, Pádraig Brady wrote: On 11/12/2012 07:53 PM, Matthew Miller wrote: On Sat, Nov 10, 2012 at 09:53:13PM +0100, Kevin Kofler wrote: I really don't understand why a core system component such as firewalld is implemented in Python! Here, I mostly don't see the reason for it to be running all the time. Couldn't it be dbus activated, and then go away when it's not needed? Then, it would matter less what it was written in. It could be argued that python is more suited to long lived programs: $ time /bin/true real 0m0.002s Hmmm: $ echo '' true.ml $ ocamlopt.opt true.ml -o true $ time ./true real 0m0.002s user 0m0.000s sys0m0.001s $ time /bin/true real 0m0.001s user 0m0.000s sys0m0.001s This seems about right to me: Both ocamlopt gcc generate native x86-64 programs, but there's a small amount of overhead in the OCaml binary (initializing the minor heap of the GC). Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones libguestfs lets you edit virtual machines. Supports shell scripting, bindings from many languages. http://libguestfs.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: raising warning flag on firewalld-default feature
On Tue, Nov 13, 2012 at 05:28:42PM +0100, Thomas Woerner wrote: If you want to recreate rules, use reload. If you restart the service with systemd, the servce gets stopped and started again, so you will loose internal state. This is how services are working. I understand that some services work that way. However, I don't think that this is the best design for a firewall service. Is there some way to force the internal state to be recorded? Let's say there is a security fix for the firewall service which needs to be applied. The daemon will need to be reloaded. Is this now not possible? And for things like the ten-second-temporary rule, it could hang around for a while. It is using glib timeouts for this, it is not hanging around and blocking. Sorry, this comment lost context: I didn't mean that the timeout implementation was poor. I meant that if the service were dbus activated, it could stay running if it continued to have things to do, and exit (maybe after a brief wait) if not. -- Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ mat...@fedoraproject.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora 18 Re-entering Beta Freeze tomorrow
Just a reminder to all, that barring any last minute issues Fedora 18 branched will enter freeze (again) starting tomorrow. There will be one more stable push late tonight that will appear in tomorrows branched compose, after that only updates fixing accepted Beta Blockers or accepted Beta Nice to Have bugs will be allowed stable until Beta is released. kevin signature.asc Description: PGP signature ___ 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
[Bug 872994] perl-DateTime-TimeZone-1.54 is available
https://bugzilla.redhat.com/show_bug.cgi?id=872994 Petr Pisar ppi...@redhat.com changed: What|Removed |Added Status|NEW |ASSIGNED CC||ppi...@redhat.com Assignee|iarn...@gmail.com |ppi...@redhat.com -- You are receiving this mail because: You are on the CC list for the bug. -- 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: Fedora 18 Beta to slip by two weeks, Beta release date is now Nov 27
On Mon, 2012-11-12 at 19:19 -0800, Adam Williamson wrote: This thread continues to get more absurd. Everyone agrees it would be good to make the installer as efficient as possible. It is open source code. Check it out from git and go to work. Patches to anaconda-devel-list. The anaconda team is aware that memory usage could be optimized; however, you may have noticed they're a _tad_ busy with other things too. Is there anything more to say in this thread? Given that no silly usage / historical comparisons anyone can make are going to magically result in a halving of the RAM use of the installer? One more thing Adam, is that people just need to *chill out*, continue to help test and find bugs as much as possible *before* the final release, to help make it as pleasant as possible when it does go Gold. Who the hell cares if it slips a little or we take a tad longer to fix something up cause it's a major deal? Not like we can't run it *now* as is and use it currently as we wait. If you can't handle things as done now, go find something else more stable, or just use gold releases and don't worry bout testing and dealing with stuff. Wait for official releases and quit complaining about this or that. Hell this stuff is all free, why the hell am I gonna complain? SMH...Just my $.02, am done. Ok more coffee now :) -- Mike Chambers Madisonville, KY Best little town on Earth! -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: raising warning flag on firewalld-default feature
On 11/13/2012 05:36 PM, Matthew Miller wrote: On Tue, Nov 13, 2012 at 05:28:42PM +0100, Thomas Woerner wrote: If you want to recreate rules, use reload. If you restart the service with systemd, the servce gets stopped and started again, so you will loose internal state. This is how services are working. I understand that some services work that way. However, I don't think that this is the best design for a firewall service. Is there some way to force the internal state to be recorded? Let's say there is a security fix for the firewall service which needs to be applied. The daemon will need to be reloaded. Is this now not possible? Some services work that way? Only some? If you have a security fix, you have to restart every service to get the new code. Firewalld is not able to save the state for a later start. And for things like the ten-second-temporary rule, it could hang around for a while. It is using glib timeouts for this, it is not hanging around and blocking. Sorry, this comment lost context: I didn't mean that the timeout implementation was poor. I meant that if the service were dbus activated, it could stay running if it continued to have things to do, and exit (maybe after a brief wait) if not. The security team asked me not to make firewalld a D-BUS driven mechanism, because of security concerns and also because of SELinux. Additionally every load of the mechanism could have to load modified or removed configuration files. So how should it get to the same state then again? How should it react on and reflect configuration changes? So it would have to write out everything - the state and all configuration files. I am sorry, but this is overkill and a most likely a source of big problems. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: raising warning flag on firewalld-default feature
On 11/13/2012 05:28 PM, Thomas Woerner wrote: On 11/13/2012 03:46 PM, Matthew Miller wrote: On Tue, Nov 13, 2012 at 02:28:17PM +0100, Tomasz Torcz wrote: Here, I mostly don't see the reason for it to be running all the time. Couldn't it be dbus activated, and then go away when it's not needed? Then, it would matter less what it was written in. It would loose internal state if it would be D-BUS activated. Surely it could persist it somewhere? Like in the actual netfilter rules? Yes. It has to be able to save internal state *somehow*, because if restarting the service breaks everything, we're not gaining much over the old way, are we? Plus, for a critical service like this, the service needs to be designed to be as robust as possible in situations where it might crash or get killed arbitrarily. With the old static firewall model every firewall change was a complete firewall recreate with conntrack loss. With firewalld changes to the firewall are done dynamically and conntrack is preserved. That's not correct. You can modify the firewall just fine without restarting it. Regards, Dennis -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: raising warning flag on firewalld-default feature
On Tue, Nov 13, 2012 at 06:03:18PM +0100, Thomas Woerner wrote: I understand that some services work that way. However, I don't think that this is the best design for a firewall service. Is there some way to force the internal state to be recorded? Let's say there is a security fix for the firewall service which needs to be applied. The daemon will need to be reloaded. Is this now not possible? Some services work that way? Only some? If you have a security fix, you have to restart every service to get the new code. Correct. Some services save their state immediately to disk when there is a critical change, and others do so on shutdown. Firewalld is not able to save the state for a later start. Okay. I think it needs to be able to, before it's ready for prime-time. Sorry, this comment lost context: I didn't mean that the timeout implementation was poor. I meant that if the service were dbus activated, it could stay running if it continued to have things to do, and exit (maybe after a brief wait) if not. The security team asked me not to make firewalld a D-BUS driven mechanism, because of security concerns and also because of SELinux. SELinux and D-Bus can work together. Can you elaborate on the security concerns? Additionally every load of the mechanism could have to load modified or removed configuration files. So how should it get to the same state then again? How should it react on and reflect configuration changes? So it would have to write out everything - the state and all configuration files. I am sorry, but this is overkill and a most likely a source of big problems. Any firewall service clearly needs to do these things whether or not it is D-Bus activated. Given that, doing it all the time is not significantly more work, and actually likely to be more robust, because the code will be the normal path and exercised all the time, not a special case. -- Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ mat...@fedoraproject.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Retiring packages due to broken deps
Since the following packages seem to be unmaintained and have broken deps in Fedora 18, I propose that they be retired and blocked before release: libsyncml mod_pubcookie openvrml perl-OpenOffice-UNO pyfuzzy reciteword ruby-revolution rubygem-calendar_date_select znc-infobot These retirements would result in the following broken dependency: libopensync-plugin-syncml However, since nothing depends on libopensync-plugin-syncml, I propose that it also be retired and blocked. Additionally, these packages are already retired in Rawhide, I propose that they also be blocked in Fedora 18: rubygem-linecache rubygem-ruby-debug rubygem-ruby-debug-base tetex-tex4ht Blocking these in Fedora 18 will not result in any broken dependencies. Speak now, maintainers, or I'll process these as retired/blocked on Wednesday. (these packages have been broken a long time) ~tom == Fedora Project -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: A minimal subset of python (was Re: [@core] working definition for the minimal package set)
Did a quick scan and removed internals random : ['import random : (cli.py)'] subprocess : ['from subprocess import Popen, PIPE : (yum/packages.py)'] gettext : ['import gettext : (output.py)'] fnmatch : ['import fnmatch : (completion-helper.py)'] tempfile : ['import tempfile : (yum/misc.py)'] base64 : ['import base64 : (yum/misc.py)'] imp : ['import imp : (yum/plugins.py)'] logging.config : ['import logging.config : (yum/__init__.py)'] string : ['import string : (yum/__init__.py)'] textwrap : ['from textwrap import fill : (yum/plugins.py)'] urlgrabber.grabber : ['from urlgrabber.grabber import URLGrabError : (output.py)'] iniparse.compat : ['from iniparse.compat import NoSectionError, NoOptionError, ParsingError : (yum/config.py)'] ConfigParser : ['from ConfigParser import ConfigParser, ParsingError : (yum-updatesd.py)'] cmd : ['import cmd : (shell.py)'] uuid : ['from uuid import uuid4 : (yum/misc.py)'] logging.handlers : ['import logging.handlers : (yum/logginglevels.py)'] threading: ['import threading : (yum-updatesd.py)'] shlex: ['import shlex : (completion-helper.py)'] signal : ['import signal : (cli.py)'] cStringIO: ['from cStringIO import StringIO : (yum/mdparser.py)'] locale : ['import locale : (output.py)'] xml.sax.saxutils : ['import xml.sax.saxutils : (yum/misc.py)'] lzma : ['import lzma : (yum/misc.py)'] sha : ['import sha : (yum/misc.py)'] urllib : ['import urllib : (yum/misc.py)'] re : ['import re # For YumTerm : (output.py)'] gpgme: ['import gpgme : (yum/misc.py)'] fcntl: ['import fcntl : (yum/rpmtrans.py)'] optparse : ['from optparse import OptionParser : (yum-updatesd.py)'] xml.etree: ['from xml.etree import cElementTree : (yum/mdparser.py)'] struct : ['import struct : (yum/packages.py)'] logging : ['import logging : (output.py)'] socket : ['import socket : (yum/logginglevels.py)'] weakref : ['from weakref import proxy as weakref : (output.py)'] sqlitecachec : ['import sqlitecachec : (yum/yumRepo.py)'] os : ['import os : (yum-updatesd.py)'] pdb : ['import pdb : (yummain.py)'] struct, time, cStringIO, base64, types curses : ['import curses : (output.py)'] __builtin__ : ['import __builtin__ : (shell.py)'] operator : ['import operator : (yumcommands.py)'] rpm : ['import rpm : (output.py)'] errno: ['import errno : (yummain.py)'] binascii : ['import binascii : (yum/misc.py)'] types: ['import types : (output.py)'] md5 : ['import md5 : (yum/misc.py)'] pwd : ['import pwd : (output.py)'] gpgme.editutil : ['import gpgme.editutil : (yum/misc.py)'] copy : ['import copy : (yum/config.py)'] hashlib : ['import hashlib : (yum/misc.py)'] atexit : ['import atexit : (yum/plugins.py)'] StringIO : ['import StringIO : (yum/__init__.py)'] exceptions : ['import exceptions : (utils.py)'] sqlutils : ['from sqlutils import sqlite, executeSQL, sql_esc : (yum/pkgtag_db.py)'] urlgrabber : ['import urlgrabber : (yum/__init__.py)'] sqlite : ['import sqlite : (yum/sqlutils.py)'] urlgrabber.progress : ['from urlgrabber.progress import TextMeter, TextMultiFileMeter : (output.py)'] shutil : ['import shutil : (yum/misc.py)'] xattr: ['import xattr : (yum/packages.py)'] bz2 : ['import bz2 : (yum/misc.py)'] grp : ['import grp : (yum/packages.py)'] sqlite3 : ['import sqlite3 as sqlite : (yum/sqlutils.py)'] stat : ['import stat : (yum/packages.py)'] warnings : ['import warnings : (yum/config.py)'] glob urlgrabber.mirror: ['import urlgrabber.mirror : (yum/yumRepo.py)'] iniparse : ['from iniparse import INIConfig : (yum/config.py)'] sys : ['import sys : (yum-updatesd.py)'] cElementTree : ['import cElementTree : (yum/mdparser.py)'] os.path : ['import os.path : (yummain.py)'] urlparse : ['import urlparse : (yum/config.py)'] Tim On Tue, Nov 13, 2012 at 5:09 PM, David Malcolm dmalc...@redhat.com wrote: On Mon, 2012-11-12 at 11:28 -0500, Matthew Miller wrote: Okay, cool -- there's a lot of enthusiasm for a SIG for the core package set. So, first up on the SIG goals: clarifying our target. It's been suggested before that there's so many possibilities that this is useless, but the point here is to *pick* a reasonable choice as a group and to work with that
Re: raising warning flag on firewalld-default feature
On 11/13/2012 06:16 PM, Dennis Jacobfeuerborn wrote: On 11/13/2012 05:28 PM, Thomas Woerner wrote: On 11/13/2012 03:46 PM, Matthew Miller wrote: On Tue, Nov 13, 2012 at 02:28:17PM +0100, Tomasz Torcz wrote: Here, I mostly don't see the reason for it to be running all the time. Couldn't it be dbus activated, and then go away when it's not needed? Then, it would matter less what it was written in. It would loose internal state if it would be D-BUS activated. Surely it could persist it somewhere? Like in the actual netfilter rules? Yes. It has to be able to save internal state *somehow*, because if restarting the service breaks everything, we're not gaining much over the old way, are we? Plus, for a critical service like this, the service needs to be designed to be as robust as possible in situations where it might crash or get killed arbitrarily. With the old static firewall model every firewall change was a complete firewall recreate with conntrack loss. With firewalld changes to the firewall are done dynamically and conntrack is preserved. That's not correct. You can modify the firewall just fine without restarting it. This is related to system-config-firewall/lokkit. You are right, if you are using iptables directly then you do not have this limitation. firewalld is a replacement for s-c-fw/lokkit. Regards, Dennis -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: raising warning flag on firewalld-default feature
On Tue, Nov 13, 2012 at 06:37:37PM +0100, Thomas Woerner wrote: That's not correct. You can modify the firewall just fine without restarting it. This is related to system-config-firewall/lokkit. You are right, if you are using iptables directly then you do not have this limitation. firewalld is a replacement for s-c-fw/lokkit. This is not what it says in the feature page at https://fedoraproject.org/wiki/Features/firewalld-default#Detailed_Description That says: The services iptables, iptables-ipv6 and ebtables will be replaced by firewalld. system-config-firewall in it's [sic] current form will also be replaced. -- Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ mat...@fedoraproject.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Anything changed on rawhide builders recently? Can't build ladvd
On Tue, Nov 13, 2012 at 8:54 AM, Josh Boyer jwbo...@gmail.com wrote:
diff --git a/scripts/headers_install.pl b/scripts/headers_install.pl
index 239d22d..6c353ae 100644
--- a/scripts/headers_install.pl
+++ b/scripts/headers_install.pl
@@ -42,6 +42,9 @@ foreach my $filename (@files) {
$line =~ s/(^|\s)(inline)\b/$1__$2__/g;
$line =~ s/(^|\s)(asm)\b(\s|[(]|$)/$1__$2__$3/g;
$line =~ s/(^|\s|[(])(volatile)\b(\s|[(]|$)/$1__$2__$3/g;
+ $line =~ s/#ifndef _UAPI/#ifndef /;
+ $line =~ s/#define _UAPI/#define /;
+ $line =~ s!#endif /[*] _UAPI!#endif /* !;
printf {$out} %s, $line;
}
close $out;
This will be included in tomorrow's rawhide kernel.
josh
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
[Bug 872994] perl-DateTime-TimeZone-1.54 is available
https://bugzilla.redhat.com/show_bug.cgi?id=872994 --- Comment #2 from Fedora Update System upda...@fedoraproject.org --- perl-DateTime-TimeZone-1.54-1.fc18 has been submitted as an update for Fedora 18. https://admin.fedoraproject.org/updates/perl-DateTime-TimeZone-1.54-1.fc18 -- You are receiving this mail because: You are on the CC list for the bug. -- 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
[Bug 872994] perl-DateTime-TimeZone-1.54 is available
https://bugzilla.redhat.com/show_bug.cgi?id=872994 --- Comment #3 from Fedora Update System upda...@fedoraproject.org --- perl-DateTime-TimeZone-1.54-1.fc17 has been submitted as an update for Fedora 17. https://admin.fedoraproject.org/updates/perl-DateTime-TimeZone-1.54-1.fc17 -- You are receiving this mail because: You are on the CC list for the bug. -- 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: raising warning flag on firewalld-default feature
On Tue, 2012-11-13 at 10:03 -0500, Matthew Miller wrote: On Fri, Nov 09, 2012 at 11:57:12AM -0500, Matthew Miller wrote: - no way to run once and exit for cloud guests with *non-dynamic* firewall needs, and it's a non-trivial user of system resources You can use the old firewall environment for static firewall use cases. Everything is still there. Can I use them *both together*? If so, okay. If not, we should keep entirely with the old one until this is really ready to take over. This is still unclear to me. Anaconda is pulling in firewalld for post-install configuration. Do we still _really_ have the option of the old firewall? We can in fact stop pulling in firewalld for post-install configuration in most cases, I think, I'm talking to twoerner/anaconda team about that. You can certainly remove it post-install and go back to using iptables / s-c-f, all the packages and services still exist, there is no dependency problem, and it still works, I've tested that. Actually, if you have an F18 system you 'yum update'd from F17 you already probably have this config, as there is no magic to do the switch to firewalld on upgrade, you just carry on with iptables. That's what I have here. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[Bug 872994] perl-DateTime-TimeZone-1.54 is available
https://bugzilla.redhat.com/show_bug.cgi?id=872994 --- Comment #4 from Fedora Update System upda...@fedoraproject.org --- perl-DateTime-TimeZone-1.54-1.fc16 has been submitted as an update for Fedora 16. https://admin.fedoraproject.org/updates/perl-DateTime-TimeZone-1.54-1.fc16 -- You are receiving this mail because: You are on the CC list for the bug. -- 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: Retiring packages due to broken deps
Tom Callaway píše v Út 13. 11. 2012 v 12:26 -0500: Since the following packages seem to be unmaintained and have broken deps in Fedora 18, I propose that they be retired and blocked before release: perl-OpenOffice-UNO ^^^ was rebuilt recently Dan -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Retiring packages due to broken deps
On 11/13/2012 12:55 PM, Dan Horák wrote: Tom Callaway píše v Út 13. 11. 2012 v 12:26 -0500: Since the following packages seem to be unmaintained and have broken deps in Fedora 18, I propose that they be retired and blocked before release: perl-OpenOffice-UNO ^^^ was rebuilt recently Aha, missed that. I will let it live... for now. ;) ~tom == Fedora Project -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: remove polkit from core?
- Original Message - So, talking about specific actions... I have recently had to search all existing polkit policies. This is no longer possible to automate because various packages ship the JavaScript policy, so I had to review those by hand. It seems that (perhaps with the exception of polkit itself) any use of JavaScript could be converted into the old format, which remains supported. So, as soon I find some free time (probably next week), I intend to ask FPC to prohibit using JavaScript if the functionality can be represented in the old .pkla, and to prepare patches to convert the 6 JS-using packages. Not sure where you got that information. pkla files are not supported anymore. So, converting JavaScript rules to pkla syntax won't do any good. What is worthwhile doing though, is to review all existing packages that ship such rules, and stop them from doing that, if possible. JavaScript rules are only meant for admin use, no OS-provided package should install them. We only look in /usr/share to allow for the possibility of site-local configuration that is distributed in packages. A concrete action that we are going to take is to split the polkit daemon into its own subpackage. Then minimal / certifiable installs can contain clients that are using the polkit libraries, without pulling in the daemon. Polkit clients are already expected to handle this situation and fall back to allow only uid 0. All of this is documented in http://www.freedesktop.org/software/polkit/docs/latest/polkit-apps.html Matthias -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: remove polkit from core?
On Tue, Nov 13, 2012 at 02:07:53PM -0500, Matthias Clasen wrote: A concrete action that we are going to take is to split the polkit daemon into its own subpackage. Then minimal / certifiable installs can contain clients that are using the polkit libraries, without pulling in the daemon. Polkit clients are already expected to handle this situation and fall back to allow only uid 0. All of this is documented in So, is it fair to say that this allows the choice of: * auditable but with root-only access * configurable policy that doesn't meet the requirements for some secure enterprise uses ? I'm not going to spend a lot of time to oppose that, but I will note that it's sad to lose the middle ground provided by key-value configuration, when that covers a lot of cases. -- Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ mat...@fedoraproject.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: remove polkit from core?
On Tuesday, November 13, 2012 02:07:53 PM Matthias Clasen wrote: - Original Message - So, talking about specific actions... I have recently had to search all existing polkit policies. This is no longer possible to automate because various packages ship the JavaScript policy, so I had to review those by hand. It seems that (perhaps with the exception of polkit itself) any use of JavaScript could be converted into the old format, which remains supported. So, as soon I find some free time (probably next week), I intend to ask FPC to prohibit using JavaScript if the functionality can be represented in the old .pkla, and to prepare patches to convert the 6 JS-using packages. Not sure where you got that information. pkla files are not supported anymore. So, converting JavaScript rules to pkla syntax won't do any good. What is worthwhile doing though, is to review all existing packages that ship such rules, and stop them from doing that, if possible. JavaScript rules are only meant for admin use, no OS-provided package should install them. We only look in /usr/share to allow for the possibility of site-local configuration that is distributed in packages. Turning system configuration into a scriptable language is like going back in time to the 70's and early 80's where you modified the source to have a different behavior. Remember Basic programs where if you wanted it to do something new, you change your copy so its better that the one people were sharing? It was decided a long time ago that its better to just have a parser that looks for the things that people would commonly like to change. This way, you have some assurance that the main binary has some integrity and you didn't make some kind of typo that opens access for the world. As a matter of fact, the better way to do this is via some kind of daemon that keeps all this information in one giant database. This way its possible to audit any change to the database and know who did it, what they changed, and what the old and new values are. This level of service was asked for by government agencies. We pointed to the sshd config file and said its impossible. I canplace a watch on the file and I can tell you who changed it and I can tell you when they changed it, but I cannot tell you what in it changed. This is the direction I'd rather see the OS go instead of going back to what amounts to changing the source code. We need to improve the verifiablity rather than the flexibility. A concrete action that we are going to take is to split the polkit daemon into its own subpackage. Then minimal / certifiable installs can contain clients that are using the polkit libraries, without pulling in the daemon. Polkit clients are already expected to handle this situation and fall back to allow only uid 0. All of this is documented in http://www.freedesktop.org/software/polkit/docs/latest/polkit-apps.html We have security configurations for desktop systems. This proposal fixes the minimal install issue but does not address the compliance issue. -Steve http://en.wikipedia.org/wiki/Configuration_file -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: remove polkit from core?
On Tue, Nov 13, 2012 at 02:32:28PM -0500, Steve Grubb wrote: It was decided a long time ago that its better to just have a parser that looks for the things that people would commonly like to change. This way, you have some assurance that the main binary has some integrity and you didn't make some kind of typo that opens access for the world. It occurs to me this is the exact _opposite_ of the change from init scripts to systemd service files. -- Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ mat...@fedoraproject.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: remove polkit from core?
On Tue, Nov 13, 2012 at 8:07 PM, Matthias Clasen mcla...@redhat.com wrote: - Original Message - So, talking about specific actions... I have recently had to search all existing polkit policies. This is no longer possible to automate because various packages ship the JavaScript policy, so I had to review those by hand. It seems that (perhaps with the exception of polkit itself) any use of JavaScript could be converted into the old format, which remains supported. So, as soon I find some free time (probably next week), I intend to ask FPC to prohibit using JavaScript if the functionality can be represented in the old .pkla, and to prepare patches to convert the 6 JS-using packages. Not sure where you got that information. pkla files are not supported anymore. My mistake - I meant the *.policy files in /usr/share/polkit-1/actions , which definitely do affect system behavior. What is worthwhile doing though, is to review all existing packages that ship such rules, and stop them from doing that, if possible. JavaScript rules are only meant for admin use, no OS-provided package should install them. Good, so we seem to agree on this part. That would resolve my concerns (ability to ability to analyze configuration shipped in Fedora by a program), but not Steve's (ability to analyze admin's customized configuration). A concrete action that we are going to take is to split the polkit daemon into its own subpackage. Then minimal / certifiable installs can contain clients that are using the polkit libraries, without pulling in the daemon. Polkit clients are already expected to handle this situation and fall back to allow only uid 0. All of this is documented in Hm, I don't like that much. Having two completely separate authorization code paths in many software components makes it very likely that the less frequently used code path will be buggy at least in some components. Mirek -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: raising warning flag on firewalld-default feature
Matthew Miller (mat...@fedoraproject.org) said: On Tue, Nov 13, 2012 at 06:37:37PM +0100, Thomas Woerner wrote: That's not correct. You can modify the firewall just fine without restarting it. This is related to system-config-firewall/lokkit. You are right, if you are using iptables directly then you do not have this limitation. firewalld is a replacement for s-c-fw/lokkit. This is not what it says in the feature page at https://fedoraproject.org/wiki/Features/firewalld-default#Detailed_Description That says: The services iptables, iptables-ipv6 and ebtables will be replaced by firewalld. system-config-firewall in it's [sic] current form will also be replaced. Replaced in the default configuration - you obviously shouldn't be running firewalld and the static firewall scripts at the same time, so enabling them in combination would be a bad idea. Bill -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: remove polkit from core?
Miloslav Trmač (m...@volny.cz) said: A concrete action that we are going to take is to split the polkit daemon into its own subpackage. Then minimal / certifiable installs can contain clients that are using the polkit libraries, without pulling in the daemon. Polkit clients are already expected to handle this situation and fall back to allow only uid 0. All of this is documented in Hm, I don't like that much. Having two completely separate authorization code paths in many software components makes it very likely that the less frequently used code path will be buggy at least in some components. Applications are already supposed to be able to cope with polkitd not being present; it's not really an authorization code path as much as it is just good defensive coding. Bill -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: remove polkit from core?
Steve Grubb (sgr...@redhat.com) said: So, converting JavaScript rules to pkla syntax won't do any good. What is worthwhile doing though, is to review all existing packages that ship such rules, and stop them from doing that, if possible. JavaScript rules are only meant for admin use, no OS-provided package should install them. We only look in /usr/share to allow for the possibility of site-local configuration that is distributed in packages. Turning system configuration into a scriptable language is like going back in time to the 70's and early 80's where you modified the source to have a different behavior. Remember Basic programs where if you wanted it to do something new, you change your copy so its better that the one people were sharing? It was decided a long time ago that its better to just have a parser that looks for the things that people would commonly like to change. This way, you have some assurance that the main binary has some integrity and you didn't make some kind of typo that opens access for the world. Given the move of most system configuration at a large scale to things such as puppet and chef, I suspect that this argument has already lost in the marketplace. Obviously, we should still support more locked down configurations for the sites that need it, but programmatic application of system configuration is likely to stay. At least in the puppet/chef/etc cases you can tell when the system has fallen out of the config, but other than a diff/hash you're not going to be able to programmatically determine what it being out of configuration means for the system operation itself. Bill -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: raising warning flag on firewalld-default feature
On Tue, Nov 13, 2012 at 06:16:49PM +0100, Dennis Jacobfeuerborn wrote: On 11/13/2012 05:28 PM, Thomas Woerner wrote: On 11/13/2012 03:46 PM, Matthew Miller wrote: On Tue, Nov 13, 2012 at 02:28:17PM +0100, Tomasz Torcz wrote: Here, I mostly don't see the reason for it to be running all the time. Couldn't it be dbus activated, and then go away when it's not needed? Then, it would matter less what it was written in. It would loose internal state if it would be D-BUS activated. Surely it could persist it somewhere? Like in the actual netfilter rules? Yes. It has to be able to save internal state *somehow*, because if restarting the service breaks everything, we're not gaining much over the old way, are we? Plus, for a critical service like this, the service needs to be designed to be as robust as possible in situations where it might crash or get killed arbitrarily. With the old static firewall model every firewall change was a complete firewall recreate with conntrack loss. With firewalld changes to the firewall are done dynamically and conntrack is preserved. That's not correct. You can modify the firewall just fine without restarting it. We are drifting away from the question. We are trying to understand what is the blocker for firewalld going away when not needed. There is some “state” to be preserved. Apart from timers for “temporary” rules, what kind of state firewalld has? State that cannot be expressed by netfiler rules in kernel, of course. -- Tomasz TorczTo co nierealne -- tutaj jest normalne. xmpp: zdzich...@chrome.pl Ziomale na życie mają tu patenty specjalne. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: remove polkit from core?
On Tue, Nov 13, 2012 at 03:47:25PM -0500, Bill Nottingham wrote: Given the move of most system configuration at a large scale to things such as puppet and chef, I suspect that this argument has already lost in the marketplace. Obviously, we should still support more locked down configurations for the sites that need it, but programmatic application of system configuration is likely to stay. At least in the puppet/chef/etc cases you can tell when the system has fallen out of the config, but other than a diff/hash you're not going to be able to programmatically determine what it being out of configuration means for the system operation itself. Doesn't this make things _worse_ for puppet and chef and friends? When using those systems, it's nice to do the programmatic config and that level, and have easily-tweaked key value (or single value per file!) configuration. -- Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ mat...@fedoraproject.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Retiring packages due to broken deps
Tom Callaway wrote, at 11/14/2012 02:26 AM +9:00: Since the following packages seem to be unmaintained and have broken deps in Fedora 18, I propose that they be retired and blocked before release: ruby-revolution Currently waiting for the upstream reply. Additionally, these packages are already retired in Rawhide, I propose that they also be blocked in Fedora 18: rubygem-linecache rubygem-ruby-debug rubygem-ruby-debug-base https://fedorahosted.org/rel-eng/ticket/5388 Regards, Mamoru -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: remove polkit from core?
Miloslav Trmač wrote: I have recently had to search all existing polkit policies. This is no longer possible to automate because various packages ship the JavaScript policy, so I had to review those by hand. It seems that (perhaps with the exception of polkit itself) any use of JavaScript could be converted into the old format, which remains supported. Actually, we were told multiple times that .pkla is no longer supported and no longer works and that we all have to use JavaScript .rules in F18+. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [@core] working definition for the minimal package set
Matthew Miller (mat...@fedoraproject.org) said: On Mon, Nov 12, 2012 at 08:07:39PM -0800, Jesse Keating wrote: Yeah, that's a thing that probably could be done. Bug again I'd like some input from people who have made the switch to these packages being mandatory. Well, I think it's just that the policy for a long time that since core isn't visible, default or optional are pointless. Specifically: http://fedoraproject.org/wiki/How_to_use_and_edit_comps.xml_for_package_groups#Core says (right now, but maybe not for long): Core is not visible, so adding 'default' or 'optional' packages to it isn't needed. Boot loaders are listed as 'default' in the group so that they're pulled in by compose tools. That last part isn't even right. There's not too many packages in core, so I don't think it'll be that difficult of an excercise to find the reasoning for each. So, what it is bascially designed for now is: - Boot to a normal prompt basesystem bash coreutils filesystem glibc initscripts plymouth (was for boot logs encrypted partitions; could be dropped) rootfiles setup systemd util-linux (plus implicit kernel) - Support basic networking biosdevname (consistent naming policy) initscripts dhclient hostname iproute iputils NetworkManager - Connect to remote systems curl openssh-clients - Allow remote systems to connect to us openssh-server - Store forward logs audit rsyslog - Install other software rpm yum - SELinux policycoreutils selinux-policy-targeted - Add/remove/configure local users, and allow them to admin if necessary passwd shadow-utils sudo - Minimal tools for admins less man-db procps-ng vim-minimal - Scheduled tasks cronie - Get mail off the box (and define a default for doing so) sendmail - Support a local console kbd ncurses - Configure additional partitions for the simple case e2fsprogs parted - Probably legacy and can be dropped from explicit listing iprutils ppc64-utils Bill -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [Test-Announce] Fedora 18 Beta Test Compose 8 (TC8) Available Now!
Kevin Kofler (kevin.kof...@chello.at) said: Andre Robatino wrote: *IMPORTANT*: Both TC8 install DVDs are oversized and will not fit on single-layer DVDs. See https://en.wikipedia.org/wiki/DVD#Capacity for DVD size limits. See what damage MiniDebugInfo is doing? Nobody (other than me) cared about CD size for the live CDs, but surely DVD size for the install DVD matters! It's time to revert MiniDebugInfo which isn't actually Mini at all! (It increases compressed size, i.e. the live image size and the size of the RPMs on the DVD, by over 10%! The smaller installed percentages the feature advertises are only achieved through compression, which obviously doesn't help after compression, if it was even implemented at all.) Stop the creeping biggerism! Not to let silly things like facts get in the way of a good rant, but the images went over size because MATE texlive are now getting pulled in via deps when they weren't before, not because of incremental minidebuginfo changes. Carry on... Bill -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [Test-Announce] Fedora 18 Beta Test Compose 8 (TC8) Available Now!
Jóhann B. Guðmundsson wrote: On 11/12/2012 09:36 PM, Kevin Fenzi wrote: FESCo decided the benefit to always having mini-debuginfo available outweighed the downside of increased space. I see done to making abrt atleast somewhat usable The ABRT developers have said very clearly that that debugging information is not useful to them because it's insufficient and that they'll be downloading the full debuginfo anyway. MiniDebugInfo contains only symbols, no line numbers (those would be much worse bloat!), no way to get function arguments etc. You get very crappy backtraces with only MiniDebugInfo. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [@core] working definition for the minimal package set
On Tuesday, November 13, 2012 04:41:12 PM Bill Nottingham wrote: Matthew Miller (mat...@fedoraproject.org) said: On Mon, Nov 12, 2012 at 08:07:39PM -0800, Jesse Keating wrote: Yeah, that's a thing that probably could be done. Bug again I'd like some input from people who have made the switch to these packages being mandatory. Well, I think it's just that the policy for a long time that since core isn't visible, default or optional are pointless. Specifically: http://fedoraproject.org/wiki/How_to_use_and_edit_comps.xml_for_package_gr oups#Core says (right now, but maybe not for long): Core is not visible, so adding 'default' or 'optional' packages to it isn't needed. Boot loaders are listed as 'default' in the group so that they're pulled in by compose tools. That last part isn't even right. There's not too many packages in core, so I don't think it'll be that difficult of an excercise to find the reasoning for each. So, what it is bascially designed for now is: - Boot to a normal prompt basesystem bash coreutils filesystem glibc initscripts plymouth (was for boot logs encrypted partitions; could be dropped) rootfiles setup systemd util-linux (plus implicit kernel) - Support basic networking biosdevname (consistent naming policy) initscripts dhclient hostname iproute iputils NetworkManager Shouldn't iptables be here too? - Connect to remote systems curl openssh-clients - Allow remote systems to connect to us openssh-server - Store forward logs audit rsyslog As soon as you have logs, you need to be able to rotate them. So, I'd add logrotate and cronie at this point. Failure to rotate logs can fill the /var partition and then bad things happen. Thanks, -Steve - Install other software rpm yum - SELinux policycoreutils selinux-policy-targeted - Add/remove/configure local users, and allow them to admin if necessary passwd shadow-utils sudo - Minimal tools for admins less man-db procps-ng vim-minimal - Scheduled tasks cronie - Get mail off the box (and define a default for doing so) sendmail - Support a local console kbd ncurses - Configure additional partitions for the simple case e2fsprogs parted - Probably legacy and can be dropped from explicit listing iprutils ppc64-utils Bill -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
bodhi 0.9.3 deployed to production
A new bugfix release of Bodhi has just been deployed to production. https://admin.fedoraproject.org/updates Bugs and enhancement requests can be filed here: http://bodhi.fedorahosted.org Major user-facing changes in 0.9.3 -- - Bodhi will no longer alter the bug status if it is already VERIFIED or ON_QA - Fixed grid pagination (Mathieu Bridon) - Allow CLI users to enable automatic bug closing (Ralph Bean) - Automatically submit updates that are edited with new builds back to testing - Fixed Message-ID and X-Bodhi message headers (Till Maas) - Publish messages upon buildroot override tag/untag (Ralph Bean) - Don't trigger fedmsg notifications for internal bodhi or autoqa comments Full list of changes Luke Macken (25): Sync up our specfic with rawhides Fix an out of order changelog entry Suppress tgmochikit, and include it in the one place that we actually need it. Revert Suppress tgmochikit, and include it in the one place that we actually need it. The tooltip.css was merged into our main stylesheet Require python-tgcaptcha2 Move the deployment message to master.kid, and tweak the style Don't send messages for internal bodhi comments Don't send messages for autoqa comments Fix the deployment status in the genshi template as well Avoid calling fedmsg from our MashTask until it is thread-safe. Don't add email headers for buildroot overrides Reference the update in the Comment.__json__ for fedmsg Revert Reference the update in the Comment.__json__ for fedmsg Cast our SQLObject results set to a list Revert Avoid calling fedmsg from our MashTask until it is thread-safe. import fedmsg helps Require fedmsg 0.3.3+ for thread safety Add the update_title to our Comment.__json__ Fix fedmsg requirement Submit updates that are edited with new builds back to testing (#678) Fix a typo Handle cookielib.LoadErrors when initializing python-bugzilla. Don't change the bug status if it is already VERIFIED (#698) Bump version to 0.9.3 Mathieu Bridon (8): Improved message after new Buildroot override Prettify an error message Fix unit test Use the new TurboGears pagination parameter The Fedora infrastructure moved to cgit Make the 'Administration' button more useful Only suggest candidate builds Remove unused parameter Patrick Uiterwijk (1): Add different headers for different deployment types Ralph Bean (8): s/send_message/publish/ Some more fedmsg notifications. Publish messages on buildroot_override tag and untag. Merging. Agent information for fedmsg. Allow CLI users to enable automatic bug closing. Removed tools/fedmsg-watch.py (it was from *way* back in the day). Change fedmsg topic from done to complete (for consistency). fedmsg config values required for zeromq3. Remi Collet (1): Fix config for Apache = 2.4 Till Maas (3): Use a string for X-Bodhi-Update-Builds mail header Fix generated message IDs model: fix closing of bugs using bz._update_bug ___ 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
Re: [@core] working definition for the minimal package set
Once upon a time, Bill Nottingham nott...@redhat.com said: So, what it is bascially designed for now is: - Boot to a normal prompt basesystem bash coreutils filesystem glibc initscripts plymouth (was for boot logs encrypted partitions; could be dropped) rootfiles setup systemd util-linux (plus implicit kernel) Plus a bootloader, which may be implicit (and I guess isn't absolutely required for at least some virtualization setups). What makes rootfiles essential? That's just overriding the defaults from /etc/skel with annoying aliases. - Support basic networking biosdevname (consistent naming policy) initscripts dhclient hostname iproute iputils NetworkManager Is NM really required for basic networking? If so, you probably don't need to specify some of the rest (such as dhclient) manually. NM brings a bunch of deps I believe. Also, I'd include ethtool, since you need it to configure NICs (although it may be pulled in as a dep). IIRC it got dropped from a default install for one release (and that was annoying for me anyway). - Configure additional partitions for the simple case e2fsprogs parted LVM? I know it is a can of worms, but it has been the default for a long time now. -- Chris Adams cmad...@hiwaay.net Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [Test-Announce] Fedora 18 Beta Test Compose 8 (TC8) Available Now!
Kevin Fenzi wrote: FESCo decided the benefit to always having mini-debuginfo available outweighed the downside of increased space. What benefit? * MiniDebugInfo contains only basically the same information already present in the dynamic symbol table of shared objects! (GDB can already use the dynamic symbol tables, it doesn't need a redundant copy of the data.) The only additional information you get is the location of hidden symbols and of symbols in executables. This is a huge penalty for that small additional information. * MiniDebugInfo does not contain necessary information for good backtraces, inluding line numbers (which were proposed as an option by the feature owners, but which would have made the bloat almost an order of magnitude worse!), locations of function arguments etc. The ABRT folks said they were going to treat MiniDebugInfo the same as none at all. * For people who really do not want to download debugging information, there's the ABRT retrace server. WHERE is the benefit of MiniDebugInfo? I don't recall anyone saying Make your image larger then, we don't care. Maybe not these exact words, but that's the essence of what the people voting for the feature said. I've read several comments of the Who cares about CDs anymore? type. Your possible options are: a) target a larger size (which is what you have done?) As I said, we were basically told to do so. b) ask FESCo to reconsider, but you probibly want some kind of NEW data for that, because without that it's just likely to end the same way. That's what we did: * I pointed out that the relative numbers given on the feature page are misleading because they compare compressed debugging information with uncompressed stripped binaries, whereas after compression (i.e. on the images, i.e. where we actually care about size), what matters is compressed vs. compressed (or uncompressed vs. uncompressed), compressed vs. uncompressed is entirely irrelevant. In particular, the statement on the feature page To minimize space use (on the installed system but also on the installer medium) we've decided to only go with the compressed symbols. is incorrect and deceptive, compressed symbols do NOT help the size on the installer media at all because both the live images and the RPMs on the DVD are already xz-compressed (in fact, compression is likely making things much WORSE because the redundancy between the MiniDebugInfo and the dynamic symbol tables cannot be exploited for compression that way). That was ignored (and the false advertising was not held against the feature owner and is still on the feature page). * The OLPC maintainers pointed out that the size hit was also a big issue for them and that they had no way to increase their target size without desupporting all the XO 1.0 devices. * The ABRT developers made clear that the MiniDebugInfo was of no use for them. * Jan Kratochvil, the expert in matters of debugging information, also expressed doubts about the usefulness of MiniDebugInfo on this list. None of this was given sufficient consideration. c) Drop some more stuff from the live to get it back under 700mb. That'd be A LOT of stuff to drop given the 10% (!) bloat from this feature. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: macros.cmake: set -DCMAKE_BUILD_TYPE=ReleaseWithDebInfo by default
On 2012-11-13 00:46, Rex Dieter wrote: 2. building with -DNDEBUG by default? Is NDEBUG something commonly found/used in projecets built with cmake? If so, I think building with it would be generally more desirable than building without it, because doing the latter might enable extra debugging code that isn't welcome in non-developer builds. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [@core] working definition for the minimal package set
On Tue, Nov 13, 2012 at 04:07:16PM -0600, Chris Adams wrote: What makes rootfiles essential? That's just overriding the defaults from /etc/skel with annoying aliases. I think it should be at least default instead of mandatory. Is NM really required for basic networking? If so, you probably don't need to specify some of the rest (such as dhclient) manually. NM brings a bunch of deps I believe. So far everything works without, and I think we should endevor to keep that true. Also, I'd include ethtool, since you need it to configure NICs (although it may be pulled in as a dep). IIRC it got dropped from a default install for one release (and that was annoying for me anyway). Seems like a possible candidate to have default but not mandatory in core. Nothing pulls it in. - Configure additional partitions for the simple case e2fsprogs parted LVM? I know it is a can of worms, but it has been the default for a long time now. Automatically added by anaconda when the system has LVM. -- Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ mat...@fedoraproject.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [@core] working definition for the minimal package set
Matthew Miller (mat...@fedoraproject.org) said: On Tue, Nov 13, 2012 at 04:07:16PM -0600, Chris Adams wrote: What makes rootfiles essential? That's just overriding the defaults from /etc/skel with annoying aliases. I think it should be at least default instead of mandatory. Consistency of environment. Root's environment should always be the same no matter how you install. Also, I'd include ethtool, since you need it to configure NICs (although it may be pulled in as a dep). IIRC it got dropped from a default install for one release (and that was annoying for me anyway). Seems like a possible candidate to have default but not mandatory in core. Nothing pulls it in. It's in standard, not core. - Configure additional partitions for the simple case e2fsprogs parted LVM? I know it is a can of worms, but it has been the default for a long time now. Automatically added by anaconda when the system has LVM. If we want to rely on anaconda to add the filesystem tools for whatever FS you install, we could drop e2fsprogs. But we'd still want parted. (And I think leaving e2fsprogs in the minimal install likely makes sense anyway.) Bill -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [@core] working definition for the minimal package set
On Tue, Nov 13, 2012 at 05:20:43PM -0500, Bill Nottingham wrote: On Tue, Nov 13, 2012 at 04:07:16PM -0600, Chris Adams wrote: What makes rootfiles essential? That's just overriding the defaults from /etc/skel with annoying aliases. I think it should be at least default instead of mandatory. Consistency of environment. Root's environment should always be the same no matter how you install. I hear that, but if you're in a big environment and you want root's dotfiles to be different, maybe you should be able to deselect the package? Automatically added by anaconda when the system has LVM. If we want to rely on anaconda to add the filesystem tools for whatever FS you install, we could drop e2fsprogs. But we'd still want parted. (And I think leaving e2fsprogs in the minimal install likely makes sense anyway.) I think it needs to be there for fsck. -- Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ mat...@fedoraproject.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [Test-Announce] Fedora 18 Beta Test Compose 8 (TC8) Available Now!
Kevin Fenzi wrote: Sometimes things aren't ideal for one group in favor of another. WHAT group is actually in favor of MiniDebugInfo? It has one single person as the feature owner. ABRT developers consider it useless. Who actually wants it? And are you sure those who think they want it realize what it really means? Let's take a simple example: $ gdb --args sleep 10 (gdb) r (press Ctrl-C) (gdb) bt #0 0xb7fdc424 in __kernel_vsyscall () #1 0xb7eb94f0 in __nanosleep_nocancel () from /lib/libc.so.6 #2 0x0804b232 in ?? () #3 0x08048f99 in ?? () #4 0xb7e166b3 in __libc_start_main () from /lib/libc.so.6 #5 0x08049085 in ?? () What MiniDebugInfo will give you (not tested): #0 0xb7fdc424 in __kernel_vsyscall () #1 0xb7eb94f0 in __nanosleep_nocancel () from /lib/libc.so.6 #2 0x0804b232 in xnanosleep () from /usr/bin/sleep #3 0x08048f99 in main () from /usr/bin/sleep #4 0xb7e166b3 in __libc_start_main () from /lib/libc.so.6 #5 0x08049085 in ?? () With coreutils-debuginfo, glibc-debuginfo and glibc-debuginfo-common installed: #0 0xb7fdc424 in __kernel_vsyscall () #1 0xb7eb94f0 in __nanosleep_nocancel () at ../sysdeps/unix/syscall-template.S:82 #2 0x0804b232 in xnanosleep (seconds=10) at xnanosleep.c:111 #3 0x08048f99 in main (argc=2, argv=0xbfffef24) at sleep.c:147 Spot the difference… Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: macros.cmake: set -DCMAKE_BUILD_TYPE=ReleaseWithDebInfo by default
Richard Shaw wrote: I'd have to go back and look but the last flag wins, right? I've had cmake projects where RPM_OPT_FLAGS was used but the cmake options were appended, so I ended up with -O3... Then these packages are faulty and need to be fixed (patch CMakeLists.txt). Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [@core] working definition for the minimal package set
On 13 November 2012 15:22, Matthew Miller mat...@fedoraproject.org wrote: On Tue, Nov 13, 2012 at 05:20:43PM -0500, Bill Nottingham wrote: On Tue, Nov 13, 2012 at 04:07:16PM -0600, Chris Adams wrote: What makes rootfiles essential? That's just overriding the defaults from /etc/skel with annoying aliases. I think it should be at least default instead of mandatory. Consistency of environment. Root's environment should always be the same no matter how you install. I hear that, but if you're in a big environment and you want root's dotfiles to be different, maybe you should be able to deselect the package? I think this seems to be a bike shed issue. If I want different stuff I am going to be overlaying other stuff myself but if I don't have some sort of defaults starting out.. I end up in various pain. -- Stephen J Smoogen. Don't derail a useful feature for the 99% because you're not in it. Linus Torvalds Years ago my mother used to say to me,... Elwood, you must be oh so smart or oh so pleasant. Well, for years I was smart. I recommend pleasant. You may quote me. —James Stewart as Elwood P. Dowd -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [Test-Announce] Fedora 18 Beta Test Compose 8 (TC8) Available Now!
On Tue, 13 Nov 2012 23:12:57 +0100 Kevin Kofler kevin.kof...@chello.at wrote: Kevin Fenzi wrote: FESCo decided the benefit to always having mini-debuginfo available outweighed the downside of increased space. What benefit? ...snip... The problem here is that you are making the same arguments you made before. FESCo didn't find them compelling, so thats unfortunate. A vote was taken, it did not go the way you wanted, you need to move on now. For the record, I voted against mini-debuginfo personally, but since FESCo has voted and decided I've moved on with life. Repeating the arguments made before over and over again doesn't get anywhere. I suppose you could ask candidates for FESCo their feelings on this matter and vote accordingly and then ask the next FESCo to revist this, but just repeating now isn't doing anyone any good. kevin signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[Bug 875785] perl-Compress-Raw-Bzip2-2.057 is available
https://bugzilla.redhat.com/show_bug.cgi?id=875785 --- Comment #2 from Fedora Update System upda...@fedoraproject.org --- Package perl-Compress-Raw-Zlib-2.058-1.fc18, perl-Compress-Raw-Lzma-2.058-1.fc18, perl-Compress-Raw-Bzip2-2.058-1.fc18, perl-IO-Compress-2.058-1.fc18, perl-IO-Compress-Lzma-2.058-1.fc18: * should fix your issue, * was pushed to the Fedora 18 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing perl-Compress-Raw-Zlib-2.058-1.fc18 perl-Compress-Raw-Lzma-2.058-1.fc18 perl-Compress-Raw-Bzip2-2.058-1.fc18 perl-IO-Compress-2.058-1.fc18 perl-IO-Compress-Lzma-2.058-1.fc18' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2012-18089/perl-Compress-Raw-Zlib-2.058-1.fc18,perl-Compress-Raw-Lzma-2.058-1.fc18,perl-Compress-Raw-Bzip2-2.058-1.fc18,perl-IO-Compress-2.058-1.fc18,perl-IO-Compress-Lzma-2.058-1.fc18 then log in and leave karma (feedback). -- You are receiving this mail because: You are on the CC list for the bug. -- 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
[Bug 875786] perl-Compress-Raw-Zlib-2.057 is available
https://bugzilla.redhat.com/show_bug.cgi?id=875786 --- Comment #2 from Fedora Update System upda...@fedoraproject.org --- Package perl-Compress-Raw-Zlib-2.058-1.fc18, perl-Compress-Raw-Lzma-2.058-1.fc18, perl-Compress-Raw-Bzip2-2.058-1.fc18, perl-IO-Compress-2.058-1.fc18, perl-IO-Compress-Lzma-2.058-1.fc18: * should fix your issue, * was pushed to the Fedora 18 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing perl-Compress-Raw-Zlib-2.058-1.fc18 perl-Compress-Raw-Lzma-2.058-1.fc18 perl-Compress-Raw-Bzip2-2.058-1.fc18 perl-IO-Compress-2.058-1.fc18 perl-IO-Compress-Lzma-2.058-1.fc18' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2012-18089/perl-Compress-Raw-Zlib-2.058-1.fc18,perl-Compress-Raw-Lzma-2.058-1.fc18,perl-Compress-Raw-Bzip2-2.058-1.fc18,perl-IO-Compress-2.058-1.fc18,perl-IO-Compress-Lzma-2.058-1.fc18 then log in and leave karma (feedback). -- You are receiving this mail because: You are on the CC list for the bug. -- 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: [Test-Announce] Fedora 18 Beta Test Compose 8 (TC8) Available Now!
Bill Nottingham wrote: Not to let silly things like facts get in the way of a good rant, but the images went over size because MATE texlive are now getting pulled in via deps when they weren't before, not because of incremental minidebuginfo changes. MiniDebugInfo definitely DID increase the DVD ISO size and dropping it might be enough to get it either below the limit or at least much closer to it. The ISOs are only ~10% above DVD size, that's about the amount of bloat MiniDebugInfo causes. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: macros.cmake: set -DCMAKE_BUILD_TYPE=ReleaseWithDebInfo by default
I wrote: Richard Shaw wrote: I'd have to go back and look but the last flag wins, right? I've had cmake projects where RPM_OPT_FLAGS was used but the cmake options were appended, so I ended up with -O3... Then these packages are faulty and need to be fixed (patch CMakeLists.txt). PS: And/or the systemwide default in CMake needs to be fixed: https://bugzilla.redhat.com/show_bug.cgi?id=875954#c2 Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[Bug 872994] perl-DateTime-TimeZone-1.54 is available
https://bugzilla.redhat.com/show_bug.cgi?id=872994 --- Comment #5 from Fedora Update System upda...@fedoraproject.org --- Package perl-DateTime-TimeZone-1.54-1.fc18: * should fix your issue, * was pushed to the Fedora 18 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing perl-DateTime-TimeZone-1.54-1.fc18' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2012-18131/perl-DateTime-TimeZone-1.54-1.fc18 then log in and leave karma (feedback). -- You are receiving this mail because: You are on the CC list for the bug. -- 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: macros.cmake: set -DCMAKE_BUILD_TYPE=ReleaseWithDebInfo by default
On 11/13/2012 06:48 AM, Richard Shaw wrote: On Mon, Nov 12, 2012 at 11:14 PM, Ralf Corsepius rc040...@freenet.de mailto:rc040...@freenet.de wrote: On 11/13/2012 05:05 AM, Richard Shaw wrote: I own several packages that use cmake and I've taken to setting the release type to RelWithDebugInfo like you suggest. One question I've had but never gotten around to asking is: Regardless of whether you use Release or RelWithDebugInfo, should we be building with -O3? It seems odd that the rpm macro defaults to doing something that is explicitly against the packaging guidelines. Your sentence confuses me or I am missing somthing. The FPG intention is to mandate using RPM_OPT_FLAGS. These so far have contained -O2. So, unless something has recently been changed, using -O3 would qualify as a bug somewhere. And regardless, the question is if -O3 is explicitly against the guidelines, why is it in the rpm macros file at all. Richard It's not in any rpm macros. It is in cmake's definition of the default flags for doing a Release build. -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA, Boulder Office FAX: 303-415-9702 3380 Mitchell Lane or...@nwra.com Boulder, CO 80301 http://www.nwra.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
