Re: Where does mock get %_smp_mflags?

[Ville Skyttä]

On 07/20/2011 11:17 PM, Bill Nottingham wrote:
 Richard Shaw (hobbes1...@gmail.com) said: 
 I don't know why I didn't notice before but I was reviewing a
 build.log from a package and noticed it was only using -j2 when I have
 -j4 in my .rpmmacros. If mock doesn't use .rpmmacros from the user
 running mock then where does it get it from?
 
From the system macro file:

You can override it in /etc/mock/site-defaults.cfg:

config_opts['macros']['%_smp_mflags'] = -j4
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

gpsbabel needs rebuild

[Jan Vcelak]

Hi,

gpsbabel needs to be rebuild to include USB support, see:
https://bugzilla.redhat.com/show_bug.cgi?id=715220

I have filled the bug a month ago and there is still no
response from the maintainer. Please, can some proven
packager rebuild the package and submit the update?

Thank you.

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

Re: thanks for F15 mdadm systemd unit

[Bryn M. Reeves]

On 07/20/2011 11:05 PM, Reindl Harald wrote:
 hopefully systemd will aslo live for 40 years as sysvinit
 did or the next replacement will be finished BEFORE release
 including the correspondending parts of the distribution

Just to be clear as this has been mentioned several times in recent threads:
System V style initialisation is _not_ 40 years old. SysV was only released in
1983 (and even after that time there were alternatives - the BSDs never adopted
this approach to system initialisation).

Regards,
Bryn.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: [ACTION REQUIRED] Retiring packages in F-16 (final warning)

[Michael J Gruber]

Bill Nottingham venit, vidit, dixit 20.07.2011 21:28:
 Each release, before branching, we block currently orphaned packages.
 It's that time again for Fedora 16.
 
 New this go-round is that we are also blocking packages that have
 failed to build since before Fedora 14.
 
 The following packages are currently orphaned, or fail to build. If
 you have a need for one of these packages, please pick them up.
 
 If not claimed, the packages will be blocked on Monday, July 25.
 

 Orphan xine-ui

I've taken master, f15 and f14 branches.

On master it did not build any more. This is fixed in
xine-ui-0.99.6-27.fc16 which I just pushed. (Due tu libcurl-devel changes.)

The same rpm builds on f15 and f14 but they don't need the fix.

Epel6 does not build with this, so I'm holding back taking that branch
until I see clearer.

I have no intention to take epel5.

Cheers,
Michael
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: F15: ugly behavior of df

[Genes MailLists]

On 07/21/2011 07:09 AM, Steve Clark wrote:

 Well what benefit(s) does the new 'df' provide, is it worth all the pain
 it brings?
 

  I concur - the current df behavior is well .. goofy :-) - however this
may be tricky to fix in the new world - but should be fixed.

  If this behavior is somehow desirable it would be preferable to  make
it an option (like df --full or whatever) and make the default something
more sensible.

  That said, it may be tricky in the new world;

   where can you retrieve the info about a mount being a bind mount ?
How can you push the chrooted bind mounts into being less obtrusive (or
even optional, --show-chrooted-mounts)

  /proc/mounts does not seem to distinguish bind mounts - so this may
have to be a kernel change and perhaps adding /proc/mounts/bind and
moving bind mounts 1 level down - this is not an area I know a lot about
however, so I'll leave this to the real experts.

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

[perl-Sys-Mmap] Perl mass rebuild

[Petr Sabata]

commit fc6e78d2bf7191c84f6251e2fcaa0d96a22d894d
Author: Petr Sabata con...@redhat.com
Date:   Thu Jul 21 14:24:18 2011 +0200

Perl mass rebuild

 perl-Sys-Mmap.spec |5 -
 1 files changed, 4 insertions(+), 1 deletions(-)
---
diff --git a/perl-Sys-Mmap.spec b/perl-Sys-Mmap.spec
index 6d511d1..b116d0c 100644
--- a/perl-Sys-Mmap.spec
+++ b/perl-Sys-Mmap.spec
@@ -1,6 +1,6 @@
 Name:   perl-Sys-Mmap
 Version:0.14
-Release:6%{?dist}
+Release:7%{?dist}
 Summary:Use mmap to map in a file as a Perl variable
 License:GPL+ or Artistic
 Group:  Development/Libraries
@@ -43,6 +43,9 @@ make test
 %{_mandir}/man3/*
 
 %changelog
+* Thu Jul 21 2011 Petr Sabata con...@redhat.com - 0.14-7
+- Perl mass rebuild
+
 * Thu Jul 21 2011 Petr Sabata con...@redhat.com - 0.14-6
 - Perl 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

[perl-Bio-Graphics] Perl mass rebuild

[Petr Sabata]

commit 5a07141e88fe3f7a60179e1b9118c5ec0d9fd321
Author: Petr Sabata con...@redhat.com
Date:   Thu Jul 21 14:24:18 2011 +0200

Perl mass rebuild

 perl-Bio-Graphics.spec |5 -
 1 files changed, 4 insertions(+), 1 deletions(-)
---
diff --git a/perl-Bio-Graphics.spec b/perl-Bio-Graphics.spec
index 3406f12..fcf2384 100644
--- a/perl-Bio-Graphics.spec
+++ b/perl-Bio-Graphics.spec
@@ -1,6 +1,6 @@
 Name:   perl-Bio-Graphics
 Version:2.14
-Release:3%{?dist}
+Release:4%{?dist}
 Summary:Generate GD images of Bio::Seq objects
 License:GPL+ or Artistic
 Group:  Development/Libraries
@@ -65,6 +65,9 @@ rm -rf $RPM_BUILD_ROOT
 %{_mandir}/man3/*
 
 %changelog
+* Thu Jul 21 2011 Petr Sabata con...@redhat.com - 2.14-4
+- Perl mass rebuild
+
 * Thu Jul 21 2011 Petr Sabata con...@redhat.com - 2.14-3
 - Perl 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

[perl-DateTime-Format-ISO8601] Perl mass rebuild

[Petr Sabata]

commit 663f01e4ae15a16fd9ca38248cdbdebc5351fea3
Author: Petr Sabata con...@redhat.com
Date:   Thu Jul 21 14:24:18 2011 +0200

Perl mass rebuild

 perl-DateTime-Format-ISO8601.spec |5 -
 1 files changed, 4 insertions(+), 1 deletions(-)
---
diff --git a/perl-DateTime-Format-ISO8601.spec 
b/perl-DateTime-Format-ISO8601.spec
index 3aa2c11..4285bbe 100644
--- a/perl-DateTime-Format-ISO8601.spec
+++ b/perl-DateTime-Format-ISO8601.spec
@@ -1,6 +1,6 @@
 Name:   perl-DateTime-Format-ISO8601 
 Version:0.07
-Release:6%{?dist}
+Release:7%{?dist}
 # LICENSE, lib/DateTime/Format/ISO8601.pod - GPL+ or Artistic
 License:GPL+ or Artistic 
 Group:  Development/Libraries
@@ -54,6 +54,9 @@ rm -rf %{buildroot}
 %{_mandir}/man3/*.3*
 
 %changelog
+* Thu Jul 21 2011 Petr Sabata con...@redhat.com - 0.07-7
+- Perl mass rebuild
+
 * Thu Jul 21 2011 Petr Sabata con...@redhat.com - 0.07-6
 - Perl 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

[perl-Test-Perl-Critic-Progressive] Perl mass rebuild

[Petr Sabata]

commit f71de33c7ec99f03082b7b37ab1a15cd308f613e
Author: Petr Sabata con...@redhat.com
Date:   Thu Jul 21 14:24:16 2011 +0200

Perl mass rebuild

 perl-Test-Perl-Critic-Progressive.spec |5 -
 1 files changed, 4 insertions(+), 1 deletions(-)
---
diff --git a/perl-Test-Perl-Critic-Progressive.spec 
b/perl-Test-Perl-Critic-Progressive.spec
index 43182d1..37e9bfb 100644
--- a/perl-Test-Perl-Critic-Progressive.spec
+++ b/perl-Test-Perl-Critic-Progressive.spec
@@ -1,6 +1,6 @@
 Name:   perl-Test-Perl-Critic-Progressive
 Version:0.03
-Release:3%{?dist}
+Release:4%{?dist}
 Summary:Gradually enforce coding standards
 License:GPL+ or Artistic
 Group:  Development/Libraries
@@ -57,6 +57,9 @@ find $RPM_BUILD_ROOT -depth -type d -exec rmdir {} 
2/dev/null \;
 %{_mandir}/man3/*
 
 %changelog
+* Thu Jul 21 2011 Petr Sabata con...@redhat.com - 0.03-4
+- Perl mass rebuild
+
 * Thu Jul 21 2011 Petr Sabata con...@redhat.com - 0.03-3
 - Perl 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

[perl-AppConfig] Perl mass rebuild

[Petr Sabata]

commit 1ae2f00535a16eaa51eaea5cf7837befd2ede956
Author: Petr Sabata con...@redhat.com
Date:   Thu Jul 21 14:24:18 2011 +0200

Perl mass rebuild

 perl-AppConfig.spec |5 -
 1 files changed, 4 insertions(+), 1 deletions(-)
---
diff --git a/perl-AppConfig.spec b/perl-AppConfig.spec
index 802543d..071d191 100644
--- a/perl-AppConfig.spec
+++ b/perl-AppConfig.spec
@@ -1,6 +1,6 @@
 Name:   perl-AppConfig
 Version:1.66
-Release:12%{?dist}
+Release:13%{?dist}
 Summary:Perl module for reading configuration files
 
 Group:  Development/Libraries
@@ -63,6 +63,9 @@ rm -rf $RPM_BUILD_ROOT
 
 
 %changelog
+* Thu Jul 21 2011 Petr Sabata con...@redhat.com - 1.66-13
+- Perl mass rebuild
+
 * Thu Jul 21 2011 Petr Sabata con...@redhat.com - 1.66-12
 - Perl 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

[perl-Perl-Critic-Swift] Perl mass rebuild

[Petr Sabata]

commit 6ae844b765ea7b451726da2da445b57dd5f9c7b0
Author: Petr Sabata con...@redhat.com
Date:   Thu Jul 21 14:24:16 2011 +0200

Perl mass rebuild

 perl-Perl-Critic-Swift.spec |5 -
 1 files changed, 4 insertions(+), 1 deletions(-)
---
diff --git a/perl-Perl-Critic-Swift.spec b/perl-Perl-Critic-Swift.spec
index 319b506..bac1cfd 100644
--- a/perl-Perl-Critic-Swift.spec
+++ b/perl-Perl-Critic-Swift.spec
@@ -1,6 +1,6 @@
 Name:   perl-Perl-Critic-Swift
 Version:1.0.3
-Release:3%{?dist}
+Release:4%{?dist}
 Summary:Set of additional policies for Perl::Critic
 License:GPL+ or Artistic
 Group:  Development/Libraries
@@ -61,6 +61,9 @@ find $RPM_BUILD_ROOT -depth -type d -exec rmdir {} 
2/dev/null \;
 %{_mandir}/man3/*
 
 %changelog
+* Thu Jul 21 2011 Petr Sabata con...@redhat.com - 1.0.3-4
+- Perl mass rebuild
+
 * Thu Jul 21 2011 Petr Sabata con...@redhat.com - 1.0.3-3
 - Perl 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

[Test-Announce] 2011-07-22 @ 17:00 UTC - F16 Alpha blocker bug review #2

[James Laska]

# F16 Alpha Blocker Review meeting #2
# Date: 2011-07-22
# Time: 17:00 UTC [1] (13:00 EDT, 10:00 PDT, 10:00 MST)
# Location: #fedora-bugzappers on irc.freenode.net

!!! ALL-CAPS RED-ALERT OMG LOL !!!

Fedora 16 Alpha test compose is less than *one* week away (Jul 26) and
F16 Alpha isn't far behind (Aug 10 for go/no_go meeting) [2].  This is
the difficult transition from the chaos of rawhide, to a releasable
Alpha.  To have any hope of shipping F16 Alpha on time ... we need to
identify as many Alpha criteria [3] blockers as possible, which means
rawhide test feedback is needed.

!!! ALL-CAPS RED-ALERT OMG LOL !!!

Mark your calendars ... the second Alpha blocker review meeting starts
at 17:00 UTC in #fedora-bugzappers.  We'll review proposed and accepted
F16 Alpha blocker bugs.  An updated list of blocker bugs is available at
https://fedoraproject.org/wiki/Current_Release_Blockers (also attached
to this mail).  We'll be reviewing the bugs to determine ... 
 1. whether they meet the Alpha release criteria [3] and should stay
on the list
 2. are getting the attention they need

For guidance on Blocker and Nice-to-have (NTH) bugs, refer to
https://fedoraproject.org/wiki/QA:SOP_blocker_bug_process and
https://fedoraproject.org/wiki/QA:SOP_nth_bug_process

== Suggested Meeting Preparation ==

Maintainers ...
  * If your bug is *not* MODIFIED ... this issue is at risk of
slipping the release date
  * If your bug is in MODIFIED ... please make sure a build with the
fix exists

Testers ...
  * If you REPORT a bug ... please be responsive to any requests for
additional information.
  * Help test rawhide ...
https://fedoraproject.org/wiki/Category:Fedora_16_Pre-Alpha_Test_Results

[1] https://fedoraproject.org/wiki/Infrastructure/UTCHowto
[2]
http://rbergero.fedorapeople.org/schedules/f-16/f-16-quality-tasks.html
[3] https://fedoraproject.org/wiki/Fedora_16_Alpha_Release_Criteria

Thanks,
James

== Approved Blockers ==
The following list of bugs are approved blockers that must be resolved.  There
are 2 bugs affecting 2 components.

 * glibc - http://bugzilla.redhat.com/show_bug.cgi?id=720034 (NEW) - Error: 
unsupported locale setting
 * kernel - http://bugzilla.redhat.com/show_bug.cgi?id=714478 (NEW) - CPU 
lockup during boot


== Proposed Blockers ==
The following list of bugs are not yet approved to block the release.  There
are 8 bugs affecting 5 components.  For guidance on reviewing the following
bugs, refer to https://fedoraproject.org/wiki/QA:SOP_blocker_bug_process

 * abrt - http://bugzilla.redhat.com/show_bug.cgi?id=723376 (NEW) - Package 
abrt-plugin-bugzilla is obsoleted by libreport-plugin-bugzilla, but obsoleting 
package does not provide for requirements
 * anaconda - http://bugzilla.redhat.com/show_bug.cgi?id=722963 (POST) - 
TypeError: %d format: a number is required, not str
 * anaconda - http://bugzilla.redhat.com/show_bug.cgi?id=723144 (ASSIGNED) - 
anaconda 16.12 crashed after the partition process
 * anaconda - http://bugzilla.redhat.com/show_bug.cgi?id=723345 (MODIFIED) - 
Rescue mode fails - TypeError: progressWindow() takes exactly 4 arguments (6 
given)
 * anaconda - http://bugzilla.redhat.com/show_bug.cgi?id=723475 (NEW) - 
anaconda-16.12 - Unable to activate networking in anaconda (stage2)
 * grub - http://bugzilla.redhat.com/show_bug.cgi?id=718722 (NEW) - Mismatched 
or corrupt version of stage1/stage2
 * microcode_ctl - http://bugzilla.redhat.com/show_bug.cgi?id=690930 (ASSIGNED) 
- microcode_ctl loops, impossible to boot
 * report - http://bugzilla.redhat.com/show_bug.cgi?id=723320 (NEW) - file 
conflicts: file /usr/lib64/python2.7/site-packages/report/__init__.py conflicts 
between attempted installs of report-0.23-0.fc16.x86_64 and 
libreport-python-2.0.5-1.fc16.x86_64


== Approved NICE-TO-HAVE ==
The following list of of bugs are approved nice-to-have.  Fixes for
nice-to-have bugs will be accepted during the freeze.  There are 0 bugs
affecting 0 components.


== Proposed NICE-TO-HAVE ==
The following list of bugs are not yet approved nice-to-have issues.  Only
fixes for approved nice-to-have bugs will be accepted during the freeze.  There
are 0 bugs affecting 0 components.  For guidance on reviewing the following
bugs, refer to https://fedoraproject.org/wiki/QA:SOP_nth_bug_process


signature.asc
Description: This is a digitally signed message part
___
test-announce mailing list
test-annou...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/test-announce-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: [ACTION REQUIRED] Retiring packages in F-16 (final warning)

[Pavel Zhukov]

I'll take slim. 

Regards, Pavel Zhukov.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: boost 1.47.0

[Jon Ciesla]

 Hi there,

 in accordance with the announced Fedora feature[1][2], we (the Boost
 maintainers) plan to rebase Boost to 1.47.0 really soon now.  Boost
 1.47.0 has been released recently and Denis Arnaud kindly did the
 packaging, so it is ready for scratch builds, smoke testing, and related
 fun.

 I'll do that in the next few days and if all comes out green-ish, I'll
 push the package into Fedora 16 and write a follow-up to this e-mail
 with guidelines on overcoming the obstacles, if any.

 Further plans: originally, we hoped that 1.48.0 would be about out by
 now, and we would manage to get beta into Fedora 16, much like we did
 with 1.46.0 for Fedora 15.  But the Boost schedule slipped, and made any
 such plans impossible to realize[2].  At the same time, the sentiment of
 Boost upstream seems to be to (gradually) get back to the original
 schedule, so we may end up with 1.50.0 in Fedora 17.  Handling +3 bump
 might end up being more interesting than is desirable, so to alleviate
 this, we will most probably want to do at least one larger rebase
 mid-Rawhide, either to 1.48.0, or 1.49.0.  I'll write more when I know
 more.

 Don't hesitate to ping me on irc (_petr) with any concerns that you
 have.

 [1] https://fedoraproject.org/wiki/Features/F16Boost147
 [2] https://bugzilla.redhat.com/show_bug.cgi?id=711845

Wesnoth seems not to like the new Boost all that well:

http://koji.fedoraproject.org/koji/getfile?taskID=3218720name=build.log

Is this a common sort of error?  My Boost-fu is weak, so there might be
something obvious I'm missing.

-J

 Thanks,
 Petr Machata
 --
 devel mailing list
 devel@lists.fedoraproject.org
 https://admin.fedoraproject.org/mailman/listinfo/devel



-- 
in your fear, seek only peace
in your fear, seek only love

-d. bowie

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

Re: Where does mock get %_smp_mflags?

[Richard Shaw]

On Thu, Jul 21, 2011 at 1:26 AM, Ville Skyttä ville.sky...@iki.fi wrote:
 You can override it in /etc/mock/site-defaults.cfg:

 config_opts['macros']['%_smp_mflags'] = -j4

Thanks! That's what I was looking for.

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

[perl-Spreadsheet-ParseExcel] Perl mass rebuild

[Petr Sabata]

commit c12b02b6a2339a832d52b1bf053448af47422331
Author: Petr Sabata con...@redhat.com
Date:   Thu Jul 21 15:15:58 2011 +0200

Perl mass rebuild

 perl-Spreadsheet-ParseExcel.spec |5 -
 1 files changed, 4 insertions(+), 1 deletions(-)
---
diff --git a/perl-Spreadsheet-ParseExcel.spec b/perl-Spreadsheet-ParseExcel.spec
index ca61cb7..7800051 100644
--- a/perl-Spreadsheet-ParseExcel.spec
+++ b/perl-Spreadsheet-ParseExcel.spec
@@ -6,7 +6,7 @@
 
 Name:   perl-Spreadsheet-ParseExcel
 Version:0.4900
-Release:8%{?dist}
+Release:9%{?dist}
 Summary:Extract information from an Excel file
 License:GPL+ or Artistic
 Group:  Development/Libraries
@@ -64,6 +64,9 @@ rm -rf $RPM_BUILD_ROOT
 %{_mandir}/man3/*
 
 %changelog
+* Thu Jul 21 2011 Petr Sabata con...@redhat.com - 0.4900-9
+- Perl mass rebuild
+
 * Tue Jul 19 2011 Petr Sabata con...@redhat.com - 0.4900-8
 - Perl 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

[perl-CGI-Application-Plugin-DBIC-Schema] Perl mass rebuild

[Petr Sabata]

commit 5c0a17f723f52ec14053503bd383622329df0dad
Author: Petr Sabata con...@redhat.com
Date:   Thu Jul 21 15:16:36 2011 +0200

Perl mass rebuild

 perl-CGI-Application-Plugin-DBIC-Schema.spec |5 -
 1 files changed, 4 insertions(+), 1 deletions(-)
---
diff --git a/perl-CGI-Application-Plugin-DBIC-Schema.spec 
b/perl-CGI-Application-Plugin-DBIC-Schema.spec
index 35479e3..426d7bd 100644
--- a/perl-CGI-Application-Plugin-DBIC-Schema.spec
+++ b/perl-CGI-Application-Plugin-DBIC-Schema.spec
@@ -1,6 +1,6 @@
 Name:   perl-CGI-Application-Plugin-DBIC-Schema
 Version:0.3
-Release:6%{?dist}
+Release:7%{?dist}
 Summary:Easy DBIx::Class access from CGI::Application
 License:GPL+ or Artistic
 Group:  Development/Libraries
@@ -53,6 +53,9 @@ rm -rf $RPM_BUILD_ROOT
 %{_mandir}/man3/*
 
 %changelog
+* Thu Jul 21 2011 Petr Sabata con...@redhat.com - 0.3-7
+- Perl mass rebuild
+
 * Wed Jul 20 2011 Petr Sabata con...@redhat.com - 0.3-6
 - Perl 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: UseSWIG.cmake is borked - need help with workaround

[Richard Shaw]

On Wed, Jul 20, 2011 at 9:29 PM, Ankur Sinha sanjay.an...@gmail.com wrote:
 Hello,

 In the cmake version residing in rawhide, the UseSWIG.cmake file is
 broken. Upstream is aware of this. I've also filed a bug with fedora
 here[1].

 I'd like to find a temporary solution to this. gdcm cannot build in
 rawhide, and a lot of fedora-medical related packages are failing to
 build in rawhide because of this.

 I have the fedora 15 version of the UseSWIG.cmake file, which worked
 correctly. How can I use this in my mock build? I need to *force* cmake
 to use this file instead of it's own module.

I can think of two possible solutions:

1. It will take a lot more steps but you can try to use the F15 file,
something like:
# mock -r fedora-rawhide-x86_64 --init
# mock -r fedora-rawhide-x86_64 --install cmake (or the correct
package that supplies that file)
# mock -r fedora-rawhide-x86_64 --copyin /path/to/F15/UseSWIG.cmake
# mock -r fedora-rawhide-x86_64 --shell (copy the file over the rawhide version)
# mock -r fedora-rawhide-x86_64 --no-clean /path/to/srpm

I may have missed something as I wrote that from memory, but it should
be close...

2. Use the whole F15 cmake package, similar to above but you can skip
--copyin and --shell

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

Re: F15: ugly behavior of df

[Reindl Harald]

Am 21.07.2011 01:19, schrieb Jeff Spaleta:

 But you really need to reset your expectations, and develop a roll out
 plan for your critical systems that anticipates unexpected changes in
 behavior between OS releases.

where did i say anything about critical systems?
getting dumb cron-mails about access denied si not critical

i need NOT to reset your expectations because if i would
start to expect that it is mordern everywhere to replace working
things with new stuff which is NOT READY i should throw
away all my computers and search a job in a church



signature.asc
Description: OpenPGP digital signature
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: thanks for F15 mdadm systemd unit

[Reindl Harald]

Am 21.07.2011 13:14, schrieb Bryn M. Reeves:
 On 07/20/2011 11:05 PM, Reindl Harald wrote:
 hopefully systemd will aslo live for 40 years as sysvinit
 did or the next replacement will be finished BEFORE release
 including the correspondending parts of the distribution
 
 Just to be clear as this has been mentioned several times in recent threads:
 System V style initialisation is _not_ 40 years old. SysV was only released in
 1983 (and even after that time there were alternatives - the BSDs never 
 adopted
 this approach to system initialisation).

so let it be 28 years now

the last ten years subsystems are coming and going every
incarnation/replacment is hyped as so much better, has
a lot of bugs which are fixed over some years and if most
of them are fixed the next guy thinks he has a better
replacement

in the past there were real developers which was able to
maintain and optimize code over a long time without
permanently break backward-compatible, these days people
start to throw away and begin from scratch in the hope
they will not make old mistakes and suboptimal software-design
again what is true, they all make a lot of new/other mistakes
and as d said - as soon as they fixed it is called outdated
and will be replaced again







signature.asc
Description: OpenPGP digital signature
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

[perl-Pugs-Compiler-Rule] Perl mass rebuild

[Petr Sabata]

commit 974eab6e95b5ba02b098d6648027cdb5cb9d4caf
Author: Petr Sabata con...@redhat.com
Date:   Thu Jul 21 16:17:26 2011 +0200

Perl mass rebuild

 perl-Pugs-Compiler-Rule.spec |5 -
 1 files changed, 4 insertions(+), 1 deletions(-)
---
diff --git a/perl-Pugs-Compiler-Rule.spec b/perl-Pugs-Compiler-Rule.spec
index daa00fc..174ab6a 100644
--- a/perl-Pugs-Compiler-Rule.spec
+++ b/perl-Pugs-Compiler-Rule.spec
@@ -1,6 +1,6 @@
 Name:   perl-Pugs-Compiler-Rule
 Version:0.37
-Release:10%{?dist}
+Release:11%{?dist}
 Summary:Compiler for Perl 6 regexes
 License:GPL+ or Artistic
 Group:  Development/Libraries
@@ -63,6 +63,9 @@ make test \
 %{_mandir}/man3/*
 
 %changelog
+* Thu Jul 21 2011 Petr Sabata con...@redhat.com - 0.37-11
+- Perl mass rebuild
+
 * Wed Jul 20 2011 Petr Sabata con...@redhat.com - 0.37-10
 - Perl 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: new cg-manager gui tool for managin cgroups

[Jason Baron]

Hi,

On Wed, Jul 20, 2011 at 10:28:32PM +0200, Lennart Poettering wrote:
 On Wed, 20.07.11 15:20, Jason Baron (jba...@redhat.com) wrote:
 
 Heya,
 
  The memory and cpu share controllers are currently supported (I simply 
  haven't
  gotten to supporting other controllers yet). One can add/delete cgroups, 
  change
  configuration parameters, and see which processes are currently associated
  with each cgroup. There is also a 'usage' view, which displays graphically 
  the
  real-time usage statistics. The cgroup configuration can then be saved
  into /etc/cgconfig.conf using the 'save' menubar button.
 
 How does it write that file? Does the UI run as root? That's not really
 desirable. It's not secure and it is cumbersome to mix applications
 running as differnt users on the same session and one the same X
 screen (since they cannot communicate with dbus, and so on).

Right, as Dan Walsh, mentioned I need to separate this into two parts -
the front end UI and a backend communicating via DBUS. This is had been
a todo item.

 
  Right now, the gui assumes that the various hierarchies are mounted 
  separately,
  but that the cpu and cpuacct are co-mounted. Its my understanding that this
  is consistent with how systemd is doing things. So that's great.
 
 In F15 we mount all controllers enabled in the kernel separately. In F16
 we'll optionally mount some of them together, and we'll probably ship a
 default of mounting cpu and cpuacct together if they are both enabled.
 
  Currently, the gui saves its state using cgconfig.conf, and cgrules.conf. It
  will display what libvirtd and systemd are doing, but will not save the 
  state
  for any of the cgroups that are created by libvirt or systemd. So, it
  basically ignores these directories as far as persistent configuration. 
  Thus,
  it should not conflict with what systemd or libvirtd are doing.
 
 Quite frankly, I think cgrulesd is a really bad idea, since it applies
 control group limits after a process is already running. This is
 necessarily racy (and adds quite a burden too, since you ask for
 notifications on each exec()). I'd claim that cgrulesd is broken by
 design and cannot be fixed.

I'm not going to claim that cgrulesd is perfect, but in the case where
you have untrusted users, you can start their login session in a
cgroup, and they can't break out of it. I agree it can be racy in the
case where you want to then further limit that user at run-time (fork
vs. re-assignment race). Another point, is that the current situation
can be no worse then the current unconstrained (no cgroup) case,
especially when you take into account the fact that system services or
'trusted services' are going to be properly assigned. Perhaps, the
authors of cgrulesd can further comment on this issue... 


 
  Thus, various privaleged consumers could make 'configuration requests' to a
  common API, basically asking what's my configuration data. If there is 
  already
  data the consumer can proceed assigning tasks to those cgroups. Otherwise, 
  it
  can create a new request, which may or may not be allowed based upon the
  available resources on the system. And each consumer can handle what it 
  wants
  to do in this case, which could potentially include tweaking the global
  configuration.
 
 systemd is the first process of the OS after the initrd finished. At
 that time no other process is running, and that means it is not
 practical to have systemd talk to any other daemon to get the most basic
 of its functionality working.
 
 systemd is and will always have to maintain its own hierarchy
 independently of everybody else.

My suggestion here was that systemd starts its own hierarchy in some
default way, and then once configuration info is available it can move
processes around as required (in most cases there would probably be no
movement since we don't expect most users to override the defaults). 
Doesn't it have to do this now, if the user requests some sort of
customized cgroup configuration?

 
 In fact I think running som arbitration daemon which clients talk to to
 get a group created is a bad idea anyway: this makes things needless
 complex and fragile. If the main reason to do such a thing is to get
 events when the cgroup configuration changes then I'd much rather see
 changes made to the kernel so that we can get notifications when groups
 are created or removed. That could be done via netlink. Another option
 would be to hook cgroupfs up with fanotify.
 

The main point of the arbitration daemon is to help users configure
their system in a consistent way. For example, if systemd wants to
use cpuset to assign certain service to say cpu 1, and libvirtd also
wants to assign a virtual machine to cpu 1, it would be nice to allow
the user to know there might be a conflict and either adjust his
settings or continue anyway. I think it would also be nice to see the
overall system configuration and performance in a single place - hence
this tool. I'm interested 

[perl-Template-GD] Perl mass rebuild

[Petr Sabata]

commit 46af0ba72b2ef9aafde3a2e22d0afa7ae9601409
Author: Petr Sabata con...@redhat.com
Date:   Thu Jul 21 16:21:04 2011 +0200

Perl mass rebuild

 perl-Template-GD.spec |5 -
 1 files changed, 4 insertions(+), 1 deletions(-)
---
diff --git a/perl-Template-GD.spec b/perl-Template-GD.spec
index 157c3da..1e5c840 100644
--- a/perl-Template-GD.spec
+++ b/perl-Template-GD.spec
@@ -1,6 +1,6 @@
 Name:   perl-Template-GD
 Version:2.66
-Release:11%{?dist}
+Release:12%{?dist}
 Summary:GD plugin(s) for the Template Toolkit
 Group:  Development/Libraries
 License:GPL+ or Artistic
@@ -50,6 +50,9 @@ rm -rf $RPM_BUILD_ROOT
 %{_mandir}/man3/*.3*
 
 %changelog
+* Thu Jul 21 2011 Petr Sabata con...@redhat.com - 2.66-12
+- Perl mass rebuild
+
 * Tue Jul 19 2011 Petr Sabata con...@redhat.com - 2.66-11
 - Perl 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

[perl-Data-Visitor] Perl mass rebuild

[Petr Sabata]

commit b319b78f10a905755cbb4b826f9d12d1463088b1
Author: Petr Sabata con...@redhat.com
Date:   Thu Jul 21 16:20:23 2011 +0200

Perl mass rebuild

 perl-Data-Visitor.spec |5 -
 1 files changed, 4 insertions(+), 1 deletions(-)
---
diff --git a/perl-Data-Visitor.spec b/perl-Data-Visitor.spec
index 4672d1b..977f026 100644
--- a/perl-Data-Visitor.spec
+++ b/perl-Data-Visitor.spec
@@ -1,6 +1,6 @@
 Name:   perl-Data-Visitor
 Version:0.27
-Release:4%{?dist}
+Release:5%{?dist}
 Summary:Visitor style traversal of Perl data structures
 License:GPL+ or Artistic
 Group:  Development/Libraries
@@ -57,6 +57,9 @@ rm -rf %{buildroot}
 %{_mandir}/man3/*
 
 %changelog
+* Thu Jul 21 2011 Petr Sabata con...@redhat.com - 0.27-5
+- Perl mass rebuild
+
 * Tue Jul 19 2011 Petr Sabata con...@redhat.com - 0.27-4
 - Perl 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

[perl-POE-Component-Server-SimpleHTTP] Perl mass rebuild

[Petr Sabata]

commit df10545708a4bf5fe954213e88ac2168a6f152b4
Author: Petr Sabata con...@redhat.com
Date:   Thu Jul 21 16:21:26 2011 +0200

Perl mass rebuild

 perl-POE-Component-Server-SimpleHTTP.spec |5 -
 1 files changed, 4 insertions(+), 1 deletions(-)
---
diff --git a/perl-POE-Component-Server-SimpleHTTP.spec 
b/perl-POE-Component-Server-SimpleHTTP.spec
index ee308a4..f1feda3 100644
--- a/perl-POE-Component-Server-SimpleHTTP.spec
+++ b/perl-POE-Component-Server-SimpleHTTP.spec
@@ -1,7 +1,7 @@
 Name:   perl-POE-Component-Server-SimpleHTTP
 # Use two digit pricision since 2.04 version
 Version:2.06
-Release:4%{?dist}
+Release:5%{?dist}
 Summary:Serve HTTP requests in POE
 License:GPL+ or Artistic
 Group:  Development/Libraries
@@ -81,6 +81,9 @@ make test
 
 
 %changelog
+* Thu Jul 21 2011 Petr Sabata con...@redhat.com - 2.06-5
+- Perl mass rebuild
+
 * Wed Jul 20 2011 Petr Sabata con...@redhat.com - 2.06-4
 - Perl 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

[perl-DateTime-Format-Oracle] Perl mass rebuild

[Petr Sabata]

commit f95045153884362fd0a69ded661cf60b5f1bca9b
Author: Petr Sabata con...@redhat.com
Date:   Thu Jul 21 16:22:59 2011 +0200

Perl mass rebuild

 perl-DateTime-Format-Oracle.spec |5 -
 1 files changed, 4 insertions(+), 1 deletions(-)
---
diff --git a/perl-DateTime-Format-Oracle.spec b/perl-DateTime-Format-Oracle.spec
index ea20daf..325cb7b 100644
--- a/perl-DateTime-Format-Oracle.spec
+++ b/perl-DateTime-Format-Oracle.spec
@@ -1,6 +1,6 @@
 Name:   perl-DateTime-Format-Oracle
 Version:0.05
-Release:8%{?dist}
+Release:9%{?dist}
 Summary:Parse and format Oracle dates and timestamps
 License:GPL+ or Artistic
 Group:  Development/Libraries
@@ -52,6 +52,9 @@ rm -rf %{buildroot}
 %{_mandir}/man3/*
 
 %changelog
+* Thu Jul 21 2011 Petr Sabata con...@redhat.com - 0.05-9
+- Perl mass rebuild
+
 * Tue Jul 19 2011 Petr Sabata con...@redhat.com - 0.05-8
 - Perl 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

[perl-Git-CPAN-Patch] Perl mass rebuild

[Petr Sabata]

commit aefb2310de424e91cd3071bb4106211f691bd456
Author: Petr Sabata con...@redhat.com
Date:   Thu Jul 21 16:23:08 2011 +0200

Perl mass rebuild

 perl-Git-CPAN-Patch.spec |5 -
 1 files changed, 4 insertions(+), 1 deletions(-)
---
diff --git a/perl-Git-CPAN-Patch.spec b/perl-Git-CPAN-Patch.spec
index bc36278..98ab417 100644
--- a/perl-Git-CPAN-Patch.spec
+++ b/perl-Git-CPAN-Patch.spec
@@ -1,7 +1,7 @@
 Name:   perl-Git-CPAN-Patch
 Summary:Patch CPAN modules using Git
 Version:0.4.6
-Release:4%{?dist}
+Release:5%{?dist}
 License:GPL+ or Artistic
 Group:  Development/Libraries
 Source0:
http://search.cpan.org/CPAN/authors/id/Y/YA/YANICK/Git-CPAN-Patch-%{version}.tar.gz
@@ -94,6 +94,9 @@ rm -rf %{buildroot}
 %{_mandir}/man1/*
 
 %changelog
+* Thu Jul 21 2011 Petr Sabata con...@redhat.com - 0.4.6-5
+- Perl mass rebuild
+
 * Tue Jul 19 2011 Petr Sabata con...@redhat.com - 0.4.6-4
 - Perl 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: Call for Test Days for Fedora 16

[Chris Tyler]

On Tue, 2011-07-19 at 10:28 -0700, Adam Williamson wrote:
 Hi, folks. The Test Day cycle for Fedora 16 will open shortly, and we're
 putting out the call for anyone who has an idea for a Test Day. There
 are many open slots on the schedule -
 https://fedoraproject.org/wiki/QA/Fedora_16_test_days - and if they all
 fill up or you would like to run a set of Test Days on related topics,
 we can organize events outside of the scheduled Thursday windows too.
 
 It's often a good idea to have a Test Day for a major change or new
 feature you're introducing to the distribution, but we can run a Test
 Day on just about any topic. There is a full guide to organizing Test
 Days available -
 https://fedoraproject.org/wiki/QA/SOP_Test_Day_management - and the QA
 team is happy both to help you run a Test Day and to butt out and let
 you run it yourself, whichever you prefer! If you're interested in
 running a Test Day, please contact QA via the test mailing list, file a
 ticket in QA trac - https://fedorahosted.org/fedora-qa - and/or pencil
 in your event on the schedule, create a Wiki page based on the template
 (see the SOP for details), and get down to work. Thanks!

Hi Adam,

On the week of Aug 7 David Shein and I will be at POSSE-RIT teaching
professors how open source communities work. On the Wednesay afternoon
and Thursday of that week, the participants are jumping in to a few open
source projects and getting their feet wet; if there was a test day on
August 11 you could have a small pool of enthusiastic labor with some
on-the-ground guidance. We might be able to do testing that would
require some set-up, e.g., we could bring in a switch and create a test
LAN.

Let me know if this would be useful and we'll set it up...

-Chris

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

[perl-DateTime-Format-W3CDTF] Perl mass rebuild

[Petr Sabata]

commit 1657c204bc7f69027af9eb230c31f137110f5d9e
Author: Petr Sabata con...@redhat.com
Date:   Thu Jul 21 16:26:28 2011 +0200

Perl mass rebuild

 perl-DateTime-Format-W3CDTF.spec |5 -
 1 files changed, 4 insertions(+), 1 deletions(-)
---
diff --git a/perl-DateTime-Format-W3CDTF.spec b/perl-DateTime-Format-W3CDTF.spec
index 0fe4950..7ee8b5d 100644
--- a/perl-DateTime-Format-W3CDTF.spec
+++ b/perl-DateTime-Format-W3CDTF.spec
@@ -1,6 +1,6 @@
 Name:   perl-DateTime-Format-W3CDTF
 Version:0.05
-Release:5%{?dist}
+Release:6%{?dist}
 Summary:Parse and format W3CDTF datetime strings
 License:GPL+ or Artistic
 Group:  Development/Libraries
@@ -46,6 +46,9 @@ rm -rf $RPM_BUILD_ROOT
 %{_mandir}/man3/*
 
 %changelog
+* Thu Jul 21 2011 Petr Sabata con...@redhat.com - 0.05-6
+- Perl mass rebuild
+
 * Wed Jul 20 2011 Petr Sabata con...@redhat.com - 0.05-5
 - Perl 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

[perl-Authen-OATH] Perl mass rebuild

[Petr Sabata]

commit 528bce4aa8cbaca10aee6cf6acb692414aa2ff96
Author: Petr Sabata con...@redhat.com
Date:   Thu Jul 21 16:26:53 2011 +0200

Perl mass rebuild

 perl-Authen-OATH.spec |5 -
 1 files changed, 4 insertions(+), 1 deletions(-)
---
diff --git a/perl-Authen-OATH.spec b/perl-Authen-OATH.spec
index b013b3a..9afb63b 100644
--- a/perl-Authen-OATH.spec
+++ b/perl-Authen-OATH.spec
@@ -1,6 +1,6 @@
 Name:   perl-Authen-OATH
 Version:1.0.0
-Release:2%{?dist}
+Release:3%{?dist}
 Summary:OATH One Time Passwords
 License:GPL+ or Artistic
 Group:  Development/Libraries
@@ -52,6 +52,9 @@ find $RPM_BUILD_ROOT -depth -type d -exec rmdir {} 
2/dev/null \;
 %{_mandir}/man3/*
 
 %changelog
+* Thu Jul 21 2011 Petr Sabata con...@redhat.com - 1.0.0-3
+- Perl mass rebuild
+
 * Wed Jul 20 2011 Petr Sabata con...@redhat.com - 1.0.0-2
 - Perl 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

[perl-Template-Provider-Encoding] Perl mass rebuild

[Petr Sabata]

commit ea5f6427c61c98e409bff8b8690821239b65edab
Author: Petr Sabata con...@redhat.com
Date:   Thu Jul 21 16:27:30 2011 +0200

Perl mass rebuild

 perl-Template-Provider-Encoding.spec |5 -
 1 files changed, 4 insertions(+), 1 deletions(-)
---
diff --git a/perl-Template-Provider-Encoding.spec 
b/perl-Template-Provider-Encoding.spec
index 2d3522e..b8a7237 100644
--- a/perl-Template-Provider-Encoding.spec
+++ b/perl-Template-Provider-Encoding.spec
@@ -1,6 +1,6 @@
 Name:   perl-Template-Provider-Encoding
 Version:0.10
-Release:9%{?dist}
+Release:10%{?dist}
 Summary:Explicitly declare encodings of your templates
 License:GPL+ or Artistic
 Group:  Development/Libraries
@@ -54,6 +54,9 @@ rm -rf %{buildroot}
 %{_mandir}/man3/*
 
 %changelog
+* Thu Jul 21 2011 Petr Sabata con...@redhat.com - 0.10-10
+- Perl mass rebuild
+
 * Tue Jul 19 2011 Petr Sabata con...@redhat.com - 0.10-9
 - Perl 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

[perl-Pod-Coverage-Moose] Perl mass rebuild

[Petr Sabata]

commit 8bccc3f1ac28891540e39cec7a7b65bdf18024ee
Author: Petr Sabata con...@redhat.com
Date:   Thu Jul 21 16:28:46 2011 +0200

Perl mass rebuild

 perl-Pod-Coverage-Moose.spec |5 -
 1 files changed, 4 insertions(+), 1 deletions(-)
---
diff --git a/perl-Pod-Coverage-Moose.spec b/perl-Pod-Coverage-Moose.spec
index 691410b..513ec40 100644
--- a/perl-Pod-Coverage-Moose.spec
+++ b/perl-Pod-Coverage-Moose.spec
@@ -1,6 +1,6 @@
 Name:   perl-Pod-Coverage-Moose
 Version:0.02
-Release:5%{?dist}
+Release:6%{?dist}
 Summary:Pod::Coverage extension for Moose
 License:GPL+ or Artistic
 Group:  Development/Libraries
@@ -56,6 +56,9 @@ rm -rf $RPM_BUILD_ROOT
 %{_mandir}/man3/*
 
 %changelog
+* Thu Jul 21 2011 Petr Sabata con...@redhat.com - 0.02-6
+- Perl mass rebuild
+
 * Tue Jul 19 2011 Petr Sabata con...@redhat.com - 0.02-5
 - Perl 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

[perl-DateTime-Format-Flexible] Perl mass rebuild

[Petr Sabata]

commit 721ab23939ad94b5aa2d77a676e973403c0c827f
Author: Petr Sabata con...@redhat.com
Date:   Thu Jul 21 16:29:13 2011 +0200

Perl mass rebuild

 perl-DateTime-Format-Flexible.spec |5 -
 1 files changed, 4 insertions(+), 1 deletions(-)
---
diff --git a/perl-DateTime-Format-Flexible.spec 
b/perl-DateTime-Format-Flexible.spec
index dc79284..bb512a4 100644
--- a/perl-DateTime-Format-Flexible.spec
+++ b/perl-DateTime-Format-Flexible.spec
@@ -1,6 +1,6 @@
 Name:   perl-DateTime-Format-Flexible
 Version:0.15
-Release:4%{?dist}
+Release:5%{?dist}
 # see LICENSE
 License:GPL+ or Artistic
 Group:  Development/Libraries
@@ -67,6 +67,9 @@ rm -rf %{buildroot}
 %{_mandir}/man3/*.3*
 
 %changelog
+* Thu Jul 21 2011 Petr Sabata con...@redhat.com - 0.15-5
+- Perl mass rebuild
+
 * Wed Jul 20 2011 Petr Sabata con...@redhat.com - 0.15-4
 - Perl 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

[perl-IO-Async] Perl mass rebuild

[Petr Sabata]

commit 78290274e6763fc7495ea3d406cf5c9ec9ac1562
Author: Petr Sabata con...@redhat.com
Date:   Thu Jul 21 16:30:12 2011 +0200

Perl mass rebuild

 perl-IO-Async.spec |5 -
 1 files changed, 4 insertions(+), 1 deletions(-)
---
diff --git a/perl-IO-Async.spec b/perl-IO-Async.spec
index 45d9b46..245aafa 100644
--- a/perl-IO-Async.spec
+++ b/perl-IO-Async.spec
@@ -1,6 +1,6 @@
 Name:   perl-IO-Async
 Version:0.29
-Release:5%{?dist}
+Release:6%{?dist}
 Summary:A collection of modules that implement asynchronous filehandle 
IO
 
 Group:  Development/Libraries
@@ -56,6 +56,9 @@ rm -rf $RPM_BUILD_ROOT
 
 
 %changelog
+* Thu Jul 21 2011 Petr Sabata con...@redhat.com - 0.29-6
+- Perl mass rebuild
+
 * Tue Jul 19 2011 Petr Sabata con...@redhat.com - 0.29-5
 - Perl 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

[perl-BackPAN-Index] update filtering for rpm 4.9

[Iain Arnell]

commit 7a94c35b0d8ebf681a113dac399a1b839078c0c4
Author: Iain Arnell iarn...@gmail.com
Date:   Thu Jul 21 16:31:32 2011 +0200

update filtering for rpm 4.9

 perl-BackPAN-Index.spec |6 +-
 1 files changed, 5 insertions(+), 1 deletions(-)
---
diff --git a/perl-BackPAN-Index.spec b/perl-BackPAN-Index.spec
index 05600f7..86b0a0b 100644
--- a/perl-BackPAN-Index.spec
+++ b/perl-BackPAN-Index.spec
@@ -1,6 +1,6 @@
 Name:   perl-BackPAN-Index
 Version:0.40
-Release:2%{?dist}
+Release:3%{?dist}
 Summary:Interface to the BackPAN index
 License:GPL+ or Artistic
 Group:  Development/Libraries
@@ -43,6 +43,7 @@ Obsoletes:  perl-Parse-BACKPAN-Packages = 0.35
 %filter_from_requires /perl(CLASS)$/d;/perl(Path::Class)$/d
 %perl_default_filter
 }
+%global __requires_exclude 
%{?__requires_exclude:%__requires_exclude|}perl\\((CLASS|Path::Class)\\)
 
 %description
 This downloads, caches and parses the BackPAN index into a local database
@@ -74,6 +75,9 @@ BACKPAN_INDEX_TEST_NO_INTERNET=1 ./Build test
 %{_mandir}/man3/*
 
 %changelog
+* Thu Jul 21 2011 Iain Arnell iarn...@gmail.com 0.40-3
+- update filtering for rpm 4.9
+
 * Tue Jul 19 2011 Petr Sabata con...@redhat.com - 0.40-2
 - Perl 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

[perl-HTML-FormFu-Model-DBIC] Perl mass rebuild

[Petr Sabata]

commit 3c5359b8f9d54b0d88397ea5376444f891b0a78e
Author: Petr Sabata con...@redhat.com
Date:   Thu Jul 21 16:32:02 2011 +0200

Perl mass rebuild

 perl-HTML-FormFu-Model-DBIC.spec |5 -
 1 files changed, 4 insertions(+), 1 deletions(-)
---
diff --git a/perl-HTML-FormFu-Model-DBIC.spec b/perl-HTML-FormFu-Model-DBIC.spec
index 8a67ef4..0e927f9 100644
--- a/perl-HTML-FormFu-Model-DBIC.spec
+++ b/perl-HTML-FormFu-Model-DBIC.spec
@@ -1,7 +1,7 @@
 Name:   perl-HTML-FormFu-Model-DBIC
 Summary:Integrate HTML::FormFu with DBIx::Class
 Version:0.09000
-Release:2%{?dist}
+Release:3%{?dist}
 License:GPL+ or Artistic
 Group:  Development/Libraries
 Source0:
http://search.cpan.org/CPAN/authors/id/C/CF/CFRANKS/HTML-FormFu-Model-DBIC-%{version}.tar.gz
 
@@ -56,6 +56,9 @@ make test
 %{_mandir}/man3/*.3*
 
 %changelog
+* Thu Jul 21 2011 Petr Sabata con...@redhat.com - 0.09000-3
+- Perl mass rebuild
+
 * Wed Jul 20 2011 Petr Sabata con...@redhat.com - 0.09000-2
 - Perl 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

[perl-Data-Stag] Perl mass rebuild

[Petr Sabata]

commit 66bc4b90fd2b0d3e544175dacd67bb48830a24ff
Author: Petr Sabata con...@redhat.com
Date:   Thu Jul 21 16:33:32 2011 +0200

Perl mass rebuild

 perl-Data-Stag.spec |5 -
 1 files changed, 4 insertions(+), 1 deletions(-)
---
diff --git a/perl-Data-Stag.spec b/perl-Data-Stag.spec
index 8e7dffa..0c878dd 100644
--- a/perl-Data-Stag.spec
+++ b/perl-Data-Stag.spec
@@ -1,6 +1,6 @@
 Name:   perl-Data-Stag
 Version:0.11
-Release:8%{?dist}
+Release:9%{?dist}
 Summary:Perl package for Structured Tags datastructures
 License:GPL+ or Artistic
 Group:  Development/Libraries
@@ -57,6 +57,9 @@ rm -rf $RPM_BUILD_ROOT
 %{_mandir}/man3/*
 
 %changelog
+* Thu Jul 21 2011 Petr Sabata con...@redhat.com - 0.11-9
+- Perl mass rebuild
+
 * Wed Jul 20 2011 Petr Sabata con...@redhat.com - 0.11-8
 - Perl 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

[perl-HTTP-DAV] Perl mass rebuild

[Petr Sabata]

commit 7cd2fbdc812c296e8cec2ee1605dd92df7ec9401
Author: Petr Sabata con...@redhat.com
Date:   Thu Jul 21 16:34:20 2011 +0200

Perl mass rebuild

 perl-HTTP-DAV.spec |5 -
 1 files changed, 4 insertions(+), 1 deletions(-)
---
diff --git a/perl-HTTP-DAV.spec b/perl-HTTP-DAV.spec
index 7e77286..8df8c2b 100644
--- a/perl-HTTP-DAV.spec
+++ b/perl-HTTP-DAV.spec
@@ -1,6 +1,6 @@
 Name:   perl-HTTP-DAV
 Version:0.42
-Release:3%{?dist}
+Release:4%{?dist}
 Summary:WebDAV client library for Perl5
 License:GPL+ or Artistic
 Group:  Development/Libraries
@@ -51,6 +51,9 @@ rm -rf $RPM_BUILD_ROOT
 %{_mandir}/man1/*
 
 %changelog
+* Thu Jul 21 2011 Petr Sabata con...@redhat.com - 0.42-4
+- Perl mass rebuild
+
 * Tue Jul 19 2011 Petr Sabata con...@redhat.com - 0.42-3
 - Perl 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

[perl-BZ-Client] Perl mass rebuild

[Petr Sabata]

commit 3c9ca056c5a140e10c90427051aa16daac708693
Author: Petr Sabata con...@redhat.com
Date:   Thu Jul 21 16:34:33 2011 +0200

Perl mass rebuild

 perl-BZ-Client.spec |5 -
 1 files changed, 4 insertions(+), 1 deletions(-)
---
diff --git a/perl-BZ-Client.spec b/perl-BZ-Client.spec
index 4e44ce4..a865dbf 100644
--- a/perl-BZ-Client.spec
+++ b/perl-BZ-Client.spec
@@ -1,6 +1,6 @@
 Name:   perl-BZ-Client
 Version:1.03
-Release:5%{?dist}
+Release:6%{?dist}
 Summary:A client for the Bugzilla web services API
 License:GPL+ or Artistic
 Group:  Development/Libraries
@@ -49,6 +49,9 @@ rm -rf $RPM_BUILD_ROOT
 %{_mandir}/man3/*
 
 %changelog
+* Thu Jul 21 2011 Petr Sabata con...@redhat.com - 1.03-6
+- Perl mass rebuild
+
 * Wed Jul 20 2011 Petr Sabata con...@redhat.com - 1.03-5
 - Perl 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: new cg-manager gui tool for managin cgroups

[Jason Baron]

Hi,

On Wed, Jul 20, 2011 at 07:01:30PM -0400, Matthias Clasen wrote:
 On Wed, 2011-07-20 at 15:20 -0400, Jason Baron wrote:
  Hi,
  
  I've been working on a new gui tool for managing and monitoring cgroups, 
  called
  'cg-manager'. I'm hoping to get people interested in contributing to this
  project, as well as to add to the conversation about how cgroups should
  be configured and incorporated into distros.
  
 
 As a high-level comment, I don't think 'cgroup management' is a very
 compelling rationale for an end-user graphical tool.
 
 For most people it will be much better to expose cgroup information in
 the normal process monitor. For people who want to use the specific
 cgroup functionality of systemd, it will be better to have that
 functionality available in a new service management frontend.

I've thought that displaying at least the cgroup that a process is part of would
be nice in the system monitor as well.

I think its a question of do we want to make users go to a bunch of
different front end tools, which don't communicate with each other to
configure the system? I think it makes sense to have libvirt or
virt-manager and systemd front-end be able to configure cgroups, but I
think it would be also nice if they could know when the step on each
other. I think it would also be nice if there was a way to help better
understand how the various system components are making use of cgroups
and interacting. I liked to see an integrated desktop approach - not one
where separate components aren't communicating with each other. 


 
 The only role I could see for this kind of dedicated cgroup UI would be
 as a cgroup debugging aid, but is that really worth the effort,
 considering most cgroup developers probably prefer to use cmdline tools
 for the that purpose ?
 
 

The reason I started looking at this was b/c there were requests to be
able to use a GUI to configure cgroups. Correct me if I'm wrong, but  the answer
is go to the virt-manager gui, then the systemd front end, and then hand edit
cgrules.conf for custom rules. And then hope you don't start services in
the wrong order.

thanks,

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

[perl-Date-Manip] Perl mass rebuild

[Petr Sabata]

commit 9b372625dab54943448bbfb2dbddcc3e379e28f8
Author: Petr Sabata con...@redhat.com
Date:   Thu Jul 21 16:37:19 2011 +0200

Perl mass rebuild

 perl-Date-Manip.spec |5 -
 1 files changed, 4 insertions(+), 1 deletions(-)
---
diff --git a/perl-Date-Manip.spec b/perl-Date-Manip.spec
index 983c103..86e8ba8 100644
--- a/perl-Date-Manip.spec
+++ b/perl-Date-Manip.spec
@@ -1,6 +1,6 @@
 Name:   perl-Date-Manip
 Version:6.24
-Release:2%{?dist}
+Release:3%{?dist}
 Summary:Date manipulation routines
 Group:  Development/Libraries
 License:GPL+ or Artistic
@@ -59,6 +59,9 @@ find $RPM_BUILD_ROOT -depth -type d -exec rmdir {} 
2/dev/null \;
 
 
 %changelog
+* Thu Jul 21 2011 Petr Sabata con...@redhat.com - 6.24-3
+- Perl mass rebuild
+
 * Tue Jul 19 2011 Petr Sabata con...@redhat.com - 6.24-2
 - Perl 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

[perl-AnyEvent-XMPP] Perl mass rebuild

[Petr Sabata]

commit b63d2e677934c6bfc6444008c4fea1d0182b6b8a
Author: Petr Sabata con...@redhat.com
Date:   Thu Jul 21 16:38:23 2011 +0200

Perl mass rebuild

 perl-AnyEvent-XMPP.spec |5 -
 1 files changed, 4 insertions(+), 1 deletions(-)
---
diff --git a/perl-AnyEvent-XMPP.spec b/perl-AnyEvent-XMPP.spec
index 2dae3d3..69404af 100644
--- a/perl-AnyEvent-XMPP.spec
+++ b/perl-AnyEvent-XMPP.spec
@@ -1,6 +1,6 @@
 Name:   perl-AnyEvent-XMPP
 Version:0.51
-Release:5%{?dist}
+Release:6%{?dist}
 Summary:Implementation of the XMPP Protocol
 License:GPL+ or Artistic
 Group:  Development/Libraries
@@ -105,6 +105,9 @@ rm -rf $RPM_BUILD_ROOT
 %{_mandir}/man3/*
 
 %changelog
+* Thu Jul 21 2011 Petr Sabata con...@redhat.com - 0.51-6
+- Perl mass rebuild
+
 * Tue Jul 19 2011 Petr Sabata con...@redhat.com - 0.51-5
 - Perl 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

[perl-DateTime-Calendar-Mayan] Perl mass rebuild

[Petr Sabata]

commit a0ab0bf2102ab43d18176218fe556e5cf4e3b878
Author: Petr Sabata con...@redhat.com
Date:   Thu Jul 21 16:40:16 2011 +0200

Perl mass rebuild

 perl-DateTime-Calendar-Mayan.spec |5 -
 1 files changed, 4 insertions(+), 1 deletions(-)
---
diff --git a/perl-DateTime-Calendar-Mayan.spec 
b/perl-DateTime-Calendar-Mayan.spec
index 36b140f..e5d1ba6 100644
--- a/perl-DateTime-Calendar-Mayan.spec
+++ b/perl-DateTime-Calendar-Mayan.spec
@@ -1,6 +1,6 @@
 Name:   perl-DateTime-Calendar-Mayan 
 Version:0.0601 
-Release:7%{?dist}
+Release:8%{?dist}
 # lib/DateTime/Calendar/Mayan.pod - GPL+ or Artistic
 License:GPL+ or Artistic 
 Group:  Development/Libraries
@@ -54,6 +54,9 @@ rm -rf %{buildroot}
 %{_mandir}/man3/*.3*
 
 %changelog
+* Thu Jul 21 2011 Petr Sabata con...@redhat.com - 0.0601-8
+- Perl mass rebuild
+
 * Tue Jul 19 2011 Petr Sabata con...@redhat.com - 0.0601-7
 - Perl 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

[perl-bioperl] Perl mass rebuild

[Petr Sabata]

commit 2f898c51c74bb91399960e08de58d12bf9910a8c
Author: Petr Sabata con...@redhat.com
Date:   Thu Jul 21 16:40:54 2011 +0200

Perl mass rebuild

 perl-bioperl.spec |5 -
 1 files changed, 4 insertions(+), 1 deletions(-)
---
diff --git a/perl-bioperl.spec b/perl-bioperl.spec
index 1831ba0..ba5ee74 100644
--- a/perl-bioperl.spec
+++ b/perl-bioperl.spec
@@ -1,6 +1,6 @@
 Name:   perl-bioperl
 Version:1.6.1
-Release:8%{?dist}
+Release:9%{?dist}
 Summary:Perl tools for computational molecular biology
 
 Group:  Development/Libraries
@@ -133,6 +133,9 @@ rm -rf $RPM_BUILD_ROOT
 %{_mandir}/man3/*.3*
 
 %changelog
+* Thu Jul 21 2011 Petr Sabata con...@redhat.com - 1.6.1-9
+- Perl mass rebuild
+
 * Tue Jul 19 2011 Petr Sabata con...@redhat.com - 1.6.1-8
 - Perl 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

[perl-Check-ISA] Perl mass rebuild

[Petr Sabata]

commit f8745ffed355b0f708bc0496cf0687a4bcd8b2a9
Author: Petr Sabata con...@redhat.com
Date:   Thu Jul 21 16:41:16 2011 +0200

Perl mass rebuild

 perl-Check-ISA.spec |5 -
 1 files changed, 4 insertions(+), 1 deletions(-)
---
diff --git a/perl-Check-ISA.spec b/perl-Check-ISA.spec
index bbcdda2..5cccd6a 100644
--- a/perl-Check-ISA.spec
+++ b/perl-Check-ISA.spec
@@ -1,7 +1,7 @@
 
 Name:   perl-Check-ISA 
 Version:0.04 
-Release:9%{?dist}
+Release:10%{?dist}
 # see lib/Check/ISA.pm
 License:GPL+ or Artistic
 Group:  Development/Libraries
@@ -54,6 +54,9 @@ rm -rf %{buildroot}
 %{_mandir}/man3/*.3*
 
 %changelog
+* Thu Jul 21 2011 Petr Sabata con...@redhat.com - 0.04-10
+- Perl mass rebuild
+
 * Wed Jul 20 2011 Petr Sabata con...@redhat.com - 0.04-9
 - Perl 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

[perl-Data-AsObject] Perl mass rebuild

[Petr Sabata]

commit c1d25c6773a180d30f15d6a7243d78cc26b484b9
Author: Petr Sabata con...@redhat.com
Date:   Thu Jul 21 16:41:46 2011 +0200

Perl mass rebuild

 perl-Data-AsObject.spec |5 -
 1 files changed, 4 insertions(+), 1 deletions(-)
---
diff --git a/perl-Data-AsObject.spec b/perl-Data-AsObject.spec
index da8933a..4f940a7 100644
--- a/perl-Data-AsObject.spec
+++ b/perl-Data-AsObject.spec
@@ -1,6 +1,6 @@
 Name:   perl-Data-AsObject
 Version:0.07
-Release:2%{?dist}
+Release:3%{?dist}
 Summary:Easy OO access to complex perl data structures
 License:GPL+ or Artistic
 Group:  Development/Libraries
@@ -53,6 +53,9 @@ rm -rf $RPM_BUILD_ROOT
 %{_mandir}/man3/*
 
 %changelog
+* Thu Jul 21 2011 Petr Sabata con...@redhat.com - 0.07-3
+- Perl mass rebuild
+
 * Tue Jul 19 2011 Petr Sabata con...@redhat.com - 0.07-2
 - Perl 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

[perl-SQL-Translator] update filtering for rpm 4.9

[Iain Arnell]

commit 3553463ffb1df811c0e16c992d8d80541baf48e3
Author: Iain Arnell iarn...@gmail.com
Date:   Thu Jul 21 16:45:32 2011 +0200

update filtering for rpm 4.9

 perl-SQL-Translator.spec |   13 ++---
 1 files changed, 10 insertions(+), 3 deletions(-)
---
diff --git a/perl-SQL-Translator.spec b/perl-SQL-Translator.spec
index c14fc82..dbf19b6 100644
--- a/perl-SQL-Translator.spec
+++ b/perl-SQL-Translator.spec
@@ -1,7 +1,7 @@
 Name:   perl-SQL-Translator
 Summary:Manipulate structured data definitions (SQL and more)
 Version:0.11006
-Release:5%{?dist}
+Release:6%{?dist}
 License:GPLv2
 Group:  Development/Libraries
 Source0:
http://search.cpan.org/CPAN/authors/id/R/RI/RIBASUSHI/SQL-Translator-%{version}.tar.gz
 
@@ -60,8 +60,12 @@ Requires:   perl(Pod::Usage)
 Requires:   perl(XML::Writer) = 0.5
 
 
-%{?filter_from_requires: %filter_from_requires /^perl(:)$/d }
-%{?perl_default_filter}
+%{?perl_default_filter:
+%filter_from_requires /^perl(:)$/d
+%perl_default_filter
+}
+%global __requires_exclude 
%{?__requires_exclude:%__requires_exclude|}perl\\(:\\)
+
 %{?perl_default_subpackage_tests}
 
 %description
@@ -113,6 +117,9 @@ rm -rf %{buildroot}
 %{_mandir}/man[13]/*
 
 %changelog
+* Thu Jul 21 2011 Iain Arnell iarn...@gmail.com 0.11006-6
+- update filtering for rpm 4.9
+
 * Thu Jul 21 2011 Petr Sabata con...@redhat.com - 0.11006-5
 - Perl 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

[perl-Syntax-Highlight-Perl6] Perl mass rebuild

[Petr Sabata]

commit 1197fdc2f1f303727fc7a2ed61fdfd611107fe5d
Author: Petr Sabata con...@redhat.com
Date:   Thu Jul 21 16:45:34 2011 +0200

Perl mass rebuild

 perl-Syntax-Highlight-Perl6.spec |5 -
 1 files changed, 4 insertions(+), 1 deletions(-)
---
diff --git a/perl-Syntax-Highlight-Perl6.spec b/perl-Syntax-Highlight-Perl6.spec
index 6ab3aed..1c73ff6 100644
--- a/perl-Syntax-Highlight-Perl6.spec
+++ b/perl-Syntax-Highlight-Perl6.spec
@@ -1,6 +1,6 @@
 Name:   perl-Syntax-Highlight-Perl6
 Version:0.88
-Release:3%{?dist}
+Release:4%{?dist}
 Summary:Perl 6 Syntax Highlighter
 License:(GPL+ or Artistic) and Artistic 2.0 and (MIT or GPLv2) 
 Group:  Development/Libraries
@@ -51,6 +51,9 @@ make test
 %{_mandir}/man3/*
 
 %changelog
+* Thu Jul 21 2011 Petr Sabata con...@redhat.com - 0.88-4
+- Perl mass rebuild
+
 * Wed Jul 20 2011 Petr Sabata con...@redhat.com - 0.88-3
 - Perl 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

[perl-Spreadsheet-ParseExcel-Simple] Perl mass rebuild

[Petr Sabata]

commit 099e7f3f051b7616814b9c59c8e01b408e039d63
Author: Petr Sabata con...@redhat.com
Date:   Thu Jul 21 16:45:48 2011 +0200

Perl mass rebuild

 perl-Spreadsheet-ParseExcel-Simple.spec |5 -
 1 files changed, 4 insertions(+), 1 deletions(-)
---
diff --git a/perl-Spreadsheet-ParseExcel-Simple.spec 
b/perl-Spreadsheet-ParseExcel-Simple.spec
index 06216af..d75d891 100644
--- a/perl-Spreadsheet-ParseExcel-Simple.spec
+++ b/perl-Spreadsheet-ParseExcel-Simple.spec
@@ -1,6 +1,6 @@
 Name:   perl-Spreadsheet-ParseExcel-Simple
 Version:1.04
-Release:10%{?dist}
+Release:11%{?dist}
 Summary:Simple interface to Excel data
 License:GPLv2+
 Group:  Development/Libraries
@@ -52,6 +52,9 @@ rm -rf %{buildroot}
 %{_mandir}/man3/*
 
 %changelog
+* Thu Jul 21 2011 Petr Sabata con...@redhat.com - 1.04-11
+- Perl mass rebuild
+
 * Wed Jul 20 2011 Petr Sabata con...@redhat.com - 1.04-10
 - Perl 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

[perl-Kwiki-RecentChanges] Perl mass rebuild

[Petr Sabata]

commit 1cc6cc259b99cdb72df7d7adc4ef4e114ef2d230
Author: Petr Sabata con...@redhat.com
Date:   Thu Jul 21 16:46:24 2011 +0200

Perl mass rebuild

 perl-Kwiki-RecentChanges.spec |5 -
 1 files changed, 4 insertions(+), 1 deletions(-)
---
diff --git a/perl-Kwiki-RecentChanges.spec b/perl-Kwiki-RecentChanges.spec
index 094b638..60d107a 100644
--- a/perl-Kwiki-RecentChanges.spec
+++ b/perl-Kwiki-RecentChanges.spec
@@ -1,6 +1,6 @@
 Name:   perl-Kwiki-RecentChanges
 Version:0.14
-Release:14%{?dist}
+Release:15%{?dist}
 Summary:Kwiki Recent Changes Plugin
 License:GPL+ or Artistic
 Group:  Development/Libraries
@@ -52,6 +52,9 @@ rm -rf $RPM_BUILD_ROOT
 %{_mandir}/man3/*
 
 %changelog
+* Thu Jul 21 2011 Petr Sabata con...@redhat.com - 0.14-15
+- Perl mass rebuild
+
 * Tue Jul 19 2011 Petr Sabata con...@redhat.com - 0.14-14
 - Perl 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

[perl-App-SVN-Bisect] Perl mass rebuild

[Petr Sabata]

commit 779f15e52835e03ba6167ea365e62612b53aabd2
Author: Petr Sabata con...@redhat.com
Date:   Thu Jul 21 16:46:42 2011 +0200

Perl mass rebuild

 perl-App-SVN-Bisect.spec |5 -
 1 files changed, 4 insertions(+), 1 deletions(-)
---
diff --git a/perl-App-SVN-Bisect.spec b/perl-App-SVN-Bisect.spec
index f66c1c3..a8ad1ed 100644
--- a/perl-App-SVN-Bisect.spec
+++ b/perl-App-SVN-Bisect.spec
@@ -1,6 +1,6 @@
 Name:   perl-App-SVN-Bisect
 Version:1.1
-Release:2%{?dist}
+Release:3%{?dist}
 Summary:Binary search through svn revisions
 License:Artistic 2.0
 Group:  Development/Libraries
@@ -78,6 +78,9 @@ rm -rf $RPM_BUILD_ROOT
 
 
 %changelog
+* Thu Jul 21 2011 Petr Sabata con...@redhat.com - 1.1-3
+- Perl mass rebuild
+
 * Wed Jul 20 2011 Petr Sabata con...@redhat.com - 1.1-2
 - Perl 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

[perl-BackPAN-Index] fix updated filter

[Iain Arnell]

commit 8a636d9cd7b06334697fa25ee29ad80b5216d1fc
Author: Iain Arnell iarn...@gmail.com
Date:   Thu Jul 21 16:42:09 2011 +0200

fix updated filter

 perl-BackPAN-Index.spec |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)
---
diff --git a/perl-BackPAN-Index.spec b/perl-BackPAN-Index.spec
index 86b0a0b..63b852f 100644
--- a/perl-BackPAN-Index.spec
+++ b/perl-BackPAN-Index.spec
@@ -43,7 +43,7 @@ Obsoletes:  perl-Parse-BACKPAN-Packages = 0.35
 %filter_from_requires /perl(CLASS)$/d;/perl(Path::Class)$/d
 %perl_default_filter
 }
-%global __requires_exclude 
%{?__requires_exclude:%__requires_exclude|}perl\\((CLASS|Path::Class)\\)
+%global __requires_exclude 
%{?__requires_exclude:%__requires_exclude|}perl\\((CLASS|Path::Class)$\\)
 
 %description
 This downloads, caches and parses the BackPAN index into a local database
--
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-YUM-RepoQuery] Perl mass rebuild

[Petr Sabata]

commit b569b075c71f50a6613f5622081171121e754787
Author: Petr Sabata con...@redhat.com
Date:   Thu Jul 21 16:48:23 2011 +0200

Perl mass rebuild

 perl-YUM-RepoQuery.spec |5 -
 1 files changed, 4 insertions(+), 1 deletions(-)
---
diff --git a/perl-YUM-RepoQuery.spec b/perl-YUM-RepoQuery.spec
index 0d2a6bd..86ed7fb 100644
--- a/perl-YUM-RepoQuery.spec
+++ b/perl-YUM-RepoQuery.spec
@@ -1,7 +1,7 @@
 %global enable_net_tests 0
 Name:   perl-YUM-RepoQuery
 Version:0.1.2
-Release:2%{?dist}
+Release:3%{?dist}
 Summary:Query a YUM repository for package information
 License:LGPLv2+
 Group:  Development/Libraries
@@ -81,6 +81,9 @@ make test
 %{_mandir}/man3/*
 
 %changelog
+* Thu Jul 21 2011 Petr Sabata con...@redhat.com - 0.1.2-3
+- Perl mass rebuild
+
 * Wed Jul 20 2011 Petr Sabata con...@redhat.com - 0.1.2-2
 - Perl 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: UseSWIG.cmake is borked - need help with workaround

[John5342]

On Thu, Jul 21, 2011 at 03:29, Ankur Sinha sanjay.an...@gmail.com wrote:
 Hello,

 In the cmake version residing in rawhide, the UseSWIG.cmake file is
 broken. Upstream is aware of this. I've also filed a bug with fedora
 here[1].

 I'd like to find a temporary solution to this. gdcm cannot build in
 rawhide, and a lot of fedora-medical related packages are failing to
 build in rawhide because of this.

 I have the fedora 15 version of the UseSWIG.cmake file, which worked
 correctly. How can I use this in my mock build? I need to *force* cmake
 to use this file instead of it's own module.

 I've placed the f15-UseSWIG.cmake in the project/CMake directory, but
 Cmake still finds its own broken module. What else does one need to do
 here?

 [1] https://bugzilla.redhat.com/show_bug.cgi?id=723652

If the problem is purely with the actual UseSWIG.cmake file and not
with the supporting tools then as a temporary workaround you can stick
the old UseSWIG.cmake file in a directory of it's own and somewhere in
the CMakeLists.txt before include(UseSWIG) (easiest somewhere near
the top of the root CMakeLists.txt file) put a line similar to the
following:

set(CMAKE_MODULE_PATH path ${CMAKE_MODULE_PATH})

where path could be the absolute path to the directory containing
the UseSWIG.cmake module or ${CMAKE_CURRENT_SOURCE_DIR}/relative/path.
The quotes are needed though i believe.

That way your file should be found before any others. The only
exception is if UseSWIG is included from another module in the
standard cmake modules directory. If that's the case then cmake will
always search there first. To return to the old behaviour where
CMAKE_MODULE_PATH is always used first add cmake_policy(SET CMP0017
OLD) to the CMakeLists.txt file.

All of this is based on the documentation at [1]. I haven't tested any
of it myself.

[1] http://www.cmake.org/cmake/help/cmake-2-8-docs.html

-- 
There are 10 kinds of people in the world: Those who understand binary
and those who don't...
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

[perl-DBI-Dumper] update filtering for rpm 4.9

[Iain Arnell]

commit 65991a4f4dcf3d7e0de8c0d60b997a8dfa0c87a6
Author: Iain Arnell iarn...@gmail.com
Date:   Thu Jul 21 16:49:43 2011 +0200

update filtering for rpm 4.9

 perl-DBI-Dumper.spec |6 +-
 1 files changed, 5 insertions(+), 1 deletions(-)
---
diff --git a/perl-DBI-Dumper.spec b/perl-DBI-Dumper.spec
index 8959552..57a78a7 100644
--- a/perl-DBI-Dumper.spec
+++ b/perl-DBI-Dumper.spec
@@ -1,6 +1,6 @@
 Name:   perl-DBI-Dumper
 Version:2.01
-Release:15%{?dist}
+Release:16%{?dist}
 Summary:Dump data from a DBI datasource to file
 # see http://rt.cpan.org/Public/Bug/Display.html?id=27269
 License:GPL+ or Artistic
@@ -22,6 +22,7 @@ BuildRequires:  perl(Term::ReadKey)
 %filter_from_provides /perl(Parse::RecDescent::DBI::Dumper::Grammar)/d
 %?perl_default_filter
 }
+%global __provides_exclude 
%{?__provides_exclude:%__provides_exclude|}perl\\(Parse::RecDescent::DBI::Dumper::Grammar\\)
 
 
 %description
@@ -81,6 +82,9 @@ make test
 %{_mandir}/man[13]/*
 
 %changelog
+* Thu Jul 21 2011 Iain Arnell iarn...@gmail.com 2.01-16
+- update filtering for rpm 4.9
+
 * Thu Jul 21 2011 Petr Sabata con...@redhat.com - 2.01-15
 - Perl 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

[perl-Perl-Critic] Perl mass rebuild

[Petr Sabata]

commit dcef624753f4ea36c69b401cbbfe9ac9b2fce307
Author: Petr Sabata con...@redhat.com
Date:   Thu Jul 21 16:50:43 2011 +0200

Perl mass rebuild

 perl-Perl-Critic.spec |5 -
 1 files changed, 4 insertions(+), 1 deletions(-)
---
diff --git a/perl-Perl-Critic.spec b/perl-Perl-Critic.spec
index cefe610..fafc7ee 100644
--- a/perl-Perl-Critic.spec
+++ b/perl-Perl-Critic.spec
@@ -1,6 +1,6 @@
 Name:   perl-Perl-Critic
 Version:1.116
-Release:3%{?dist}
+Release:4%{?dist}
 Summary:Critique Perl source code for best-practices
 
 Group:  Development/Libraries
@@ -151,6 +151,9 @@ LC_ALL=en_US ./Build %{!?perl_bootstrap:author}test
 
 
 %changelog
+* Thu Jul 21 2011 Petr Sabata con...@redhat.com - 1.116-4
+- Perl mass rebuild
+
 * Wed Jul 20 2011 Petr Sabata con...@redhat.com - 1.116-3
 - Perl 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: new cg-manager gui tool for managin cgroups

[Daniel P. Berrange]

On Thu, Jul 21, 2011 at 10:36:23AM -0400, Jason Baron wrote:
 Hi,
 
 On Wed, Jul 20, 2011 at 07:01:30PM -0400, Matthias Clasen wrote:
  On Wed, 2011-07-20 at 15:20 -0400, Jason Baron wrote:
   Hi,
   
   I've been working on a new gui tool for managing and monitoring cgroups, 
   called
   'cg-manager'. I'm hoping to get people interested in contributing to this
   project, as well as to add to the conversation about how cgroups should
   be configured and incorporated into distros.
   
  
  As a high-level comment, I don't think 'cgroup management' is a very
  compelling rationale for an end-user graphical tool.
  
  For most people it will be much better to expose cgroup information in
  the normal process monitor. For people who want to use the specific
  cgroup functionality of systemd, it will be better to have that
  functionality available in a new service management frontend.
 
 I've thought that displaying at least the cgroup that a process is part of 
 would
 be nice in the system monitor as well.
 
 I think its a question of do we want to make users go to a bunch of
 different front end tools, which don't communicate with each other to
 configure the system? I think it makes sense to have libvirt or
 virt-manager and systemd front-end be able to configure cgroups, but I
 think it would be also nice if they could know when the step on each
 other. I think it would also be nice if there was a way to help better
 understand how the various system components are making use of cgroups
 and interacting. I liked to see an integrated desktop approach - not one
 where separate components aren't communicating with each other. 

It is already possible for different applications to use cgroups
without stepping on each other, and without requiring every app
to communicate with each other.

As an example, when it starts libvirt will look at what cgroup
it has been placed in, and create the VM cgroups below this point.
So systemd can put libvirtd in an arbitrary location and set an
overall limits for the virtualization service, and it will cap
all VMs. No direct communication between systemd  libvirt is
required.

If applications similarly take care to honour the location in
which they were started, rather than just creating stuff directly
in the root cgroup, they too will interoperate nicely.

This is one of the nice aspects to the cgroups hierarchy, and
why having tools/daemons which try to arbitrarily re-arrange
cgroups systemwide are not very desirable IMHO.

  The only role I could see for this kind of dedicated cgroup UI would be
  as a cgroup debugging aid, but is that really worth the effort,
  considering most cgroup developers probably prefer to use cmdline tools
  for the that purpose ?
  
  
 
 The reason I started looking at this was b/c there were requests to be
 able to use a GUI to configure cgroups. Correct me if I'm wrong, but  the 
 answer
 is go to the virt-manager gui, then the systemd front end, and then hand edit
 cgrules.conf for custom rules. And then hope you don't start services in
 the wrong order.

My point is that 'configure cgroups' is not really a task users would
need to. Going to virt-manager GUI, then systemd GUI, and so on is not
likely to be a problem in the real world usage, because the users tasks
do not require that they go through touch every single cgroup on the
system at once.

People who are using virtualization, will already be using virt-manager
to configure their VMs, so of course they expect to be able to control
the VMs's resource utilization from there, rather than any external tool

People who are configuring system services and want to control the
resources of a service on their system, would expect todo so in the
same tool where they are enabling their service, along with changing
firewall rules for that service all in the same place. They again would
have no little to go off to separate tools for cgroups or firewalling
while enabling services.

Regards,
Daniel
-- 
|: http://berrange.com  -o-http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org  -o- http://virt-manager.org :|
|: http://autobuild.org   -o- http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org   -o-   http://live.gnome.org/gtk-vnc :|
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

[perl-XML-RSS] Perl mass rebuild

[Petr Sabata]

commit 2c169c2848463c2c4eafd3faff4e25815f2ead4f
Author: Petr Sabata con...@redhat.com
Date:   Thu Jul 21 16:53:57 2011 +0200

Perl mass rebuild

 perl-XML-RSS.spec |5 -
 1 files changed, 4 insertions(+), 1 deletions(-)
---
diff --git a/perl-XML-RSS.spec b/perl-XML-RSS.spec
index 4fff7ba..778fdb4 100644
--- a/perl-XML-RSS.spec
+++ b/perl-XML-RSS.spec
@@ -1,6 +1,6 @@
 Name:   perl-XML-RSS
 Version:1.45
-Release:6%{?dist}
+Release:7%{?dist}
 Summary:Perl module for managing RDF Site Summary (RSS) files
 
 Group:  Development/Libraries
@@ -60,6 +60,9 @@ rm -rf $RPM_BUILD_ROOT
 
 
 %changelog
+* Thu Jul 21 2011 Petr Sabata con...@redhat.com - 1.45-7
+- Perl mass rebuild
+
 * Wed Jul 20 2011 Petr Sabata con...@redhat.com - 1.45-6
 - Perl 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

[perl-DateTime-Format-MySQL] Perl mass rebuild

[Petr Sabata]

commit fdeea22d6f7b9a46547bb0a19bf1d79fe4c87bc1
Author: Petr Sabata con...@redhat.com
Date:   Thu Jul 21 16:52:16 2011 +0200

Perl mass rebuild

 perl-DateTime-Format-MySQL.spec |5 -
 1 files changed, 4 insertions(+), 1 deletions(-)
---
diff --git a/perl-DateTime-Format-MySQL.spec b/perl-DateTime-Format-MySQL.spec
index 6c63377..4e65a2d 100644
--- a/perl-DateTime-Format-MySQL.spec
+++ b/perl-DateTime-Format-MySQL.spec
@@ -12,7 +12,7 @@
 
 Name:   perl-DateTime-Format-MySQL
 Version:0.04
-Release:13%{?dist}
+Release:14%{?dist}
 Summary:Parse and format MySQL dates and times 
 
 Group:  Development/Libraries
@@ -79,6 +79,9 @@ rm -rf %{buildroot}
 
 
 %changelog
+* Thu Jul 21 2011 Petr Sabata con...@redhat.com - 0.04-14
+- Perl mass rebuild
+
 * Tue Jul 19 2011 Petr Sabata con...@redhat.com - 0.04-13
 - Perl 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

Strange package: fedora-icon-theme

[Dmitry Butskoy]

There is fedora-icon-theme package, which looks strange a little.

Since F13 it no more contains any files at all (just directories), ie. 
it looks like a meta-package.
OTOH its source rpm still has full tarball with png icons etc.

What is a reason for such design? (I'm just curious).


Regards,
Dmitry Butskoy
http://www.fedoraproject.org/wiki/DmitryButskoy
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: thanks for F15 mdadm systemd unit

[Steve Clark]

On 07/21/2011 07:38 AM, Reindl Harald wrote:


Am 21.07.2011 13:14, schrieb Bryn M. Reeves:

On 07/20/2011 11:05 PM, Reindl Harald wrote:

hopefully systemd will aslo live for 40 years as sysvinit
did or the next replacement will be finished BEFORE release
including the correspondending parts of the distribution

Just to be clear as this has been mentioned several times in recent threads:
System V style initialisation is _not_ 40 years old. SysV was only released in
1983 (and even after that time there were alternatives - the BSDs never adopted
this approach to system initialisation).

so let it be 28 years now

the last ten years subsystems are coming and going every
incarnation/replacment is hyped as so much better, has
a lot of bugs which are fixed over some years and if most
of them are fixed the next guy thinks he has a better
replacement

in the past there were real developers which was able to
maintain and optimize code over a long time without
permanently break backward-compatible, these days people
start to throw away and begin from scratch in the hope
they will not make old mistakes and suboptimal software-design
again what is true, they all make a lot of new/other mistakes
and as d said - as soon as they fixed it is called outdated
and will be replaced again






+100

--
Stephen Clark
*NetWolves*
Sr. Software Engineer III
Phone: 813-579-3200
Fax: 813-882-0209
Email: steve.cl...@netwolves.com
http://www.netwolves.com
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: new cg-manager gui tool for managin cgroups

[Daniel P. Berrange]

On Thu, Jul 21, 2011 at 11:28:45AM -0400, Vivek Goyal wrote:
 On Thu, Jul 21, 2011 at 03:52:03PM +0100, Daniel P. Berrange wrote:
  On Thu, Jul 21, 2011 at 10:36:23AM -0400, Jason Baron wrote:
   Hi,
   
   On Wed, Jul 20, 2011 at 07:01:30PM -0400, Matthias Clasen wrote:
On Wed, 2011-07-20 at 15:20 -0400, Jason Baron wrote:
 Hi,
 
 I've been working on a new gui tool for managing and monitoring 
 cgroups, called
 'cg-manager'. I'm hoping to get people interested in contributing to 
 this
 project, as well as to add to the conversation about how cgroups 
 should
 be configured and incorporated into distros.
 

As a high-level comment, I don't think 'cgroup management' is a very
compelling rationale for an end-user graphical tool.

For most people it will be much better to expose cgroup information in
the normal process monitor. For people who want to use the specific
cgroup functionality of systemd, it will be better to have that
functionality available in a new service management frontend.
   
   I've thought that displaying at least the cgroup that a process is part 
   of would
   be nice in the system monitor as well.
   
   I think its a question of do we want to make users go to a bunch of
   different front end tools, which don't communicate with each other to
   configure the system? I think it makes sense to have libvirt or
   virt-manager and systemd front-end be able to configure cgroups, but I
   think it would be also nice if they could know when the step on each
   other. I think it would also be nice if there was a way to help better
   understand how the various system components are making use of cgroups
   and interacting. I liked to see an integrated desktop approach - not one
   where separate components aren't communicating with each other. 
  
  It is already possible for different applications to use cgroups
  without stepping on each other, and without requiring every app
  to communicate with each other.
  
  As an example, when it starts libvirt will look at what cgroup
  it has been placed in, and create the VM cgroups below this point.
  So systemd can put libvirtd in an arbitrary location and set an
  overall limits for the virtualization service, and it will cap
  all VMs. No direct communication between systemd  libvirt is
  required.
  
  If applications similarly take care to honour the location in
  which they were started, rather than just creating stuff directly
  in the root cgroup, they too will interoperate nicely.
  
  This is one of the nice aspects to the cgroups hierarchy, and
  why having tools/daemons which try to arbitrarily re-arrange
  cgroups systemwide are not very desirable IMHO.
 
 This will work as long as somebody has done the top level setup and
 planning. For example, if somebody is running bunch of virtual machines
 and hosting some native applications and services also on the machine,
 then he might decide that all the virt machines can only use 8 out of
 10 cpus and keep 2 cpus free for native services.
 
 In that case an admin ought to be able to do this top level planning
 before handing out control of sub-hierarchies to respective applications.
 Does systemd allow that as of today?

IIRC, you can already set cgroups configuration in the service's
systemd unit file, using something like:

 ControlGroup=cpu:/foo/bar mem:/wizz

though I can't find the manpage right now.

Regards,
Daniel
-- 
|: http://berrange.com  -o-http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org  -o- http://virt-manager.org :|
|: http://autobuild.org   -o- http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org   -o-   http://live.gnome.org/gtk-vnc :|
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Failure to find ltdl.h in mockbuild

[Braden McDaniel]

I'm getting this configure failure when doing an F16 mockbuild (on my
F15 system):

checking ltdl.h usability... no
checking ltdl.h presence... no
checking for ltdl.h... no
configure: error: in `/builddir/build/BUILD/openvrml-0.18.8':
configure: error: ltdl.h not found

The package has:

BuildRequires:  libtool-ltdl-devel

Why might this be happening? Did ltdl.h get moved?

-- 
Braden McDaniel bra...@endoframe.com

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

Re: systemd vice SysV/LSB init systems - what next ?

[Adam Williamson]

On Tue, 2011-07-19 at 13:53 -0400, Fulko Hew wrote:

 I'd suggest something along the lines of 'sorry, but
 maintaining two
 officially-supported init systems side-by-side is an excessive
 burden on
 package maintainers and quality assurance, so we won't be
 doing it'.
 It's hard to go wrong by just politely saying what you mean.
 
 But as someone who is maintaining his own package...
 
 Won't I have to maintain two different init system support files
 for both systemd based distros and all the other Linux and Unix
 distros
 I also run on?

Well, yes. But when I say 'maintainer' I'm talking about Fedora project
package maintainers, not upstream developers.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw
http://www.happyassassin.net


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

Re: Poll: Does ACPI lid state work on your Linux laptop?

[Adam Williamson]

On Tue, 2011-07-19 at 23:14 +0300, Pasi Kärkkäinen wrote:
 On Tue, Jul 19, 2011 at 09:56:11AM -0700, Adam Williamson wrote:
  On Tue, 2011-07-19 at 13:46 +0300, Pasi Kärkkäinen wrote:
  
I think I recall discussing this with the anaconda team before; we
agreed in principle that it would make sense for anaconda to default to
clone mode, but the problem is X doesn't have any very easy mechanism
for overriding the default, there is no simple command line parameter
anaconda could pass to X to launch it in clone mode instead of span
mode. anaconda would have to include an X config stub to specify clone
mode and then ensure that stub wasn't installed. I think no-one got
around to getting that done yet. I'm not sure if there's a bug for it,
but you could have a look.
   
   
   Did you mean Redhat bugzilla or Freedesktop/Xorg bugzilla? 
   With some searching I couldn't find one.. should I file a bugreport/rfe? 
  
  I don't recall, it may well have been just an IRC conversation. A bug
  report would certainly be a good idea, then we won't lose track of it
  again =)
 
 
 Ok :)
 
 Should I file it against xorg or anaconda? 

The basic bug - 'anaconda should run in clone not span mode' - against
anaconda. Depending on how that bug goes, we may wind up filing some
kind of enhancement request for X, I guess.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw
http://www.happyassassin.net


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

Re: new cg-manager gui tool for managin cgroups

[Lennart Poettering]

On Thu, 21.07.11 16:36, Daniel P. Berrange (berra...@redhat.com) wrote:

 IIRC, you can already set cgroups configuration in the service's
 systemd unit file, using something like:
 
  ControlGroup=cpu:/foo/bar mem:/wizz
 
 though I can't find the manpage right now.

Yes, this is supported in systemd (though without the ).

It's (tersely) documented in systemd.exec(5).

My guess is that we'll cover about 90% or so of the usecases of cgroups
if we make it easy to assign cgroup-based limits to VMs, to system
services and to users, like we can do with libvirt and systemd. There's
still a big chunk of the 10% who want more complex setups with more
arbitrary groupings, but I have my doubts the folks doing that are the
ones who need a UI for that.

Lennart

-- 
Lennart Poettering - Red Hat, Inc.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: new cg-manager gui tool for managin cgroups

[Lennart Poettering]

On Thu, 21.07.11 10:20, Jason Baron (jba...@redhat.com) wrote:

  Quite frankly, I think cgrulesd is a really bad idea, since it applies
  control group limits after a process is already running. This is
  necessarily racy (and adds quite a burden too, since you ask for
  notifications on each exec()). I'd claim that cgrulesd is broken by
  design and cannot be fixed.
 
 I'm not going to claim that cgrulesd is perfect, but in the case where
 you have untrusted users, you can start their login session in a
 cgroup, and they can't break out of it. I agree it can be racy in the
 case where you want to then further limit that user at run-time (fork
 vs. re-assignment race). Another point, is that the current situation
 can be no worse then the current unconstrained (no cgroup) case,
 especially when you take into account the fact that system services or
 'trusted services' are going to be properly assigned. Perhaps, the
 authors of cgrulesd can further comment on this issue... 

placing users in cgroups is note done by cgrulesd afaik. The PAM module
does that. (and systemd can do that for you, too).

  systemd is and will always have to maintain its own hierarchy
  independently of everybody else.
 
 My suggestion here was that systemd starts its own hierarchy in some
 default way, and then once configuration info is available it can move
 processes around as required (in most cases there would probably be no
 movement since we don't expect most users to override the defaults). 
 Doesn't it have to do this now, if the user requests some sort of
 customized cgroup configuration?

I'd expect people to just tell systemd about their preferred grouping
(if the default of sticking each service into a group of its own is not
good enough) using the ControlGroup= setting in unit files. This is
trivial to do, and will put things right from the beginning with no
complex moving around.

Lennart

-- 
Lennart Poettering - Red Hat, Inc.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: new cg-manager gui tool for managin cgroups

[Lennart Poettering]

On Thu, 21.07.11 15:52, Daniel P. Berrange (berra...@redhat.com) wrote:

  I think its a question of do we want to make users go to a bunch of
  different front end tools, which don't communicate with each other to
  configure the system? I think it makes sense to have libvirt or
  virt-manager and systemd front-end be able to configure cgroups, but I
  think it would be also nice if they could know when the step on each
  other. I think it would also be nice if there was a way to help better
  understand how the various system components are making use of cgroups
  and interacting. I liked to see an integrated desktop approach - not one
  where separate components aren't communicating with each other. 
 
 It is already possible for different applications to use cgroups
 without stepping on each other, and without requiring every app
 to communicate with each other.
 
 As an example, when it starts libvirt will look at what cgroup
 it has been placed in, and create the VM cgroups below this point.
 So systemd can put libvirtd in an arbitrary location and set an
 overall limits for the virtualization service, and it will cap
 all VMs. No direct communication between systemd  libvirt is
 required.

systemd (when run as the user) does exactly the same thing btw. It will
discover the group it is urnning in, and will create all its groups
beneath that.

In fact, right now the cgroup hierarchy is not virtualized. To make sure
systemd works fine in a container we employ the very same logic here: if
the container manager started systemd in specific cgroup, then system
will do all its stuff below that, even if it is PID 1.

Lennart

-- 
Lennart Poettering - Red Hat, Inc.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: UseSWIG.cmake is borked - need help with workaround

[Ankur Sinha]

On Thu, 2011-07-21 at 08:17 -0500, Richard Shaw wrote:
 I can think of two possible solutions:
 
 1. It will take a lot more steps but you can try to use the F15 file,
 something like:
 # mock -r fedora-rawhide-x86_64 --init
 # mock -r fedora-rawhide-x86_64 --install cmake (or the correct
 package that supplies that file)
 # mock -r fedora-rawhide-x86_64 --copyin /path/to/F15/UseSWIG.cmake
 # mock -r fedora-rawhide-x86_64 --shell (copy the file over the
 rawhide version)
 # mock -r fedora-rawhide-x86_64 --no-clean /path/to/srpm
 
 I may have missed something as I wrote that from memory, but it should
 be close...
 
 2. Use the whole F15 cmake package, similar to above but you can skip
 --copyin and --shell
 
 Richard 

Hi Richard,

I can build it on my local machine already. I just had to grab the old
cmake package and place it in a local mock repo. This isn't the issue
however, I am looking for a way to get it to build correctly in koji,
the fedora build system. These hacks aren't applicable there :/

-- 
Thanks, 
Regards,
Ankur: FranciscoD

http://fedoraproject.org/wiki/User:Ankursinha
http://dodoincfedora.wordpress.com/


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

Re: new cg-manager gui tool for managin cgroups

[Lennart Poettering]

On Thu, 21.07.11 11:28, Vivek Goyal (vgo...@redhat.com) wrote:

  It is already possible for different applications to use cgroups
  without stepping on each other, and without requiring every app
  to communicate with each other.
  
  As an example, when it starts libvirt will look at what cgroup
  it has been placed in, and create the VM cgroups below this point.
  So systemd can put libvirtd in an arbitrary location and set an
  overall limits for the virtualization service, and it will cap
  all VMs. No direct communication between systemd  libvirt is
  required.
  
  If applications similarly take care to honour the location in
  which they were started, rather than just creating stuff directly
  in the root cgroup, they too will interoperate nicely.
  
  This is one of the nice aspects to the cgroups hierarchy, and
  why having tools/daemons which try to arbitrarily re-arrange
  cgroups systemwide are not very desirable IMHO.
 
 This will work as long as somebody has done the top level setup and
 planning. For example, if somebody is running bunch of virtual machines
 and hosting some native applications and services also on the machine,
 then he might decide that all the virt machines can only use 8 out of
 10 cpus and keep 2 cpus free for native services.
 
 In that case an admin ought to be able to do this top level planning
 before handing out control of sub-hierarchies to respective applications.
 Does systemd allow that as of today?

Right now, systemd only offers you to place services in the cgroups of
your choice, it will not configure any settings on those cgroups. (This
is very likely to change soon though as there is a patch pending that
makes a number of popular controls available as native config options in
systemd.)

For the controllers like cpuset or the RT part of cpu where you
assign resources from a limited pool we currently have no solution at
all to deal with conflicts. Neither in libcgroup and friends, not in
systemd, not in libvirt.

However, I do think that figuring out the conflicts here is something to
fix at the UI level -- and systemd itself (or libvirt) should not have to
deal with this at all. The UIs should figure that out between
themselves. I think it should be possible to come up with really simple
schemes to deal with this however. For example, have every UI drop in
some dir /var/lib or so a file encoding which resources have been taken
and should not available in the other UIs anymore, maybe with a
descriptive stirng, so that those UIs can show who took it away.

However, I believe that adding something like that should be the last
step to care for in a UI. So far systemd doesn't have any comprehensive
UI. How to deal with conflicts between resource assignments is not a
central problem that would justify moving all the consumers of cgroups
on some additional middleware.

 To allow that I think systemd should either provide native configuration
 capability or build on top of existing libcgroups constructs like
 cgconfig, cgrules.conf to decide how an admin has planned the resource
 management and in what cgroups services have to be launched, IMHO.

For the systemd case I'd assume that a UI which wants to enable the
admin to control cgroup limits would just place a unit file for the
respective service in /etc/systemd/system, use .include to pull in the
original unit file, and set the setting it wants to set.

Lennart

-- 
Lennart Poettering - Red Hat, Inc.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: UseSWIG.cmake is borked - need help with workaround

[Ankur Sinha]

On Thu, 2011-07-21 at 15:49 +0100, John5342 wrote:
 If the problem is purely with the actual UseSWIG.cmake file and not
 with the supporting tools then as a temporary workaround you can stick
 the old UseSWIG.cmake file in a directory of it's own and somewhere in
 the CMakeLists.txt before include(UseSWIG) (easiest somewhere near
 the top of the root CMakeLists.txt file) put a line similar to the
 following:
 
 set(CMAKE_MODULE_PATH path ${CMAKE_MODULE_PATH})
 
 where path could be the absolute path to the directory containing
 the UseSWIG.cmake module or ${CMAKE_CURRENT_SOURCE_DIR}/relative/path.
 The quotes are needed though i believe.
 
 That way your file should be found before any others. The only
 exception is if UseSWIG is included from another module in the
 standard cmake modules directory. If that's the case then cmake will
 always search there first. To return to the old behaviour where
 CMAKE_MODULE_PATH is always used first add cmake_policy(SET CMP0017
 OLD) to the CMakeLists.txt file.
 
 All of this is based on the documentation at [1]. I haven't tested any
 of it myself.
 
 [1] http://www.cmake.org/cmake/help/cmake-2-8-docs.html
 
 

Hi John,

I've been trying this already. I hadn't realized that the location of
inclusion of swig had to be kept in mind. I'll go retry. 

-- 
Thanks, 
Regards,
Ankur: FranciscoD

http://fedoraproject.org/wiki/User:Ankursinha
http://dodoincfedora.wordpress.com/


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

Re: new cg-manager gui tool for managin cgroups

[Jóhann B. Guðmundsson]

On 07/21/2011 03:36 PM, Daniel P. Berrange wrote:
 IIRC, you can already set cgroups configuration in the service's
 systemd unit file, using something like:

   ControlGroup=cpu:/foo/bar mem:/wizz

 though I can't find the manpage right now.


man systemd.exec

or

http://0pointer.de/public/systemd-man/systemd.exec.html

JBG


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

[perl-MIME-Charset] Perl mass rebuild

[Petr Sabata]

commit 82c2287d3a00fce34eba917afaed19446c64e772
Author: Petr Sabata con...@redhat.com
Date:   Thu Jul 21 18:21:23 2011 +0200

Perl mass rebuild

 perl-MIME-Charset.spec |5 -
 1 files changed, 4 insertions(+), 1 deletions(-)
---
diff --git a/perl-MIME-Charset.spec b/perl-MIME-Charset.spec
index f4f4242..0f2f74c 100644
--- a/perl-MIME-Charset.spec
+++ b/perl-MIME-Charset.spec
@@ -1,6 +1,6 @@
 Name:   perl-MIME-Charset
 Version:1.009.1
-Release:2%{?dist}
+Release:3%{?dist}
 Summary:Charset Informations for MIME
 License:GPL+ or Artistic
 Group:  Development/Libraries
@@ -63,6 +63,9 @@ rm -rf $RPM_BUILD_ROOT
 %{_mandir}/man3/*
 
 %changelog
+* Thu Jul 21 2011 Petr Sabata con...@redhat.com - 1.009.1-3
+- Perl mass rebuild
+
 * Wed Jul 20 2011 Petr Sabata con...@redhat.com - 1.009.1-2
 - Perl 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

[perl-CatalystX-LeakChecker] Perl mass rebuild

[Petr Sabata]

commit 52bad33f71f10efb43f1ff5c7d79f0870d61e26a
Author: Petr Sabata con...@redhat.com
Date:   Thu Jul 21 18:28:13 2011 +0200

Perl mass rebuild

 perl-CatalystX-LeakChecker.spec |5 -
 1 files changed, 4 insertions(+), 1 deletions(-)
---
diff --git a/perl-CatalystX-LeakChecker.spec b/perl-CatalystX-LeakChecker.spec
index 50f2a2f..1323328 100644
--- a/perl-CatalystX-LeakChecker.spec
+++ b/perl-CatalystX-LeakChecker.spec
@@ -1,7 +1,7 @@
 Name:   perl-CatalystX-LeakChecker
 Summary:Debug memory leaks in Catalyst applications
 Version:0.06
-Release:5%{?dist}
+Release:6%{?dist}
 License:GPL+ or Artistic
 Group:  Development/Libraries
 Source0:
http://search.cpan.org/CPAN/authors/id/F/FL/FLORA/CatalystX-LeakChecker-%{version}.tar.gz
 
@@ -66,6 +66,9 @@ make test
 %{_mandir}/man3/*.3*
 
 %changelog
+* Thu Jul 21 2011 Petr Sabata con...@redhat.com - 0.06-6
+- Perl mass rebuild
+
 * Thu Jul 21 2011 Petr Sabata con...@redhat.com - 0.06-5
 - Perl 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

[perl-Catalyst-Devel] Perl mass rebuild

[Petr Sabata]

commit 6011e575d2e0e7fa982c674b6247d8839fe9a38e
Author: Petr Sabata con...@redhat.com
Date:   Thu Jul 21 18:21:53 2011 +0200

Perl mass rebuild

 perl-Catalyst-Devel.spec |5 -
 1 files changed, 4 insertions(+), 1 deletions(-)
---
diff --git a/perl-Catalyst-Devel.spec b/perl-Catalyst-Devel.spec
index a0d1eb0..6e09248 100644
--- a/perl-Catalyst-Devel.spec
+++ b/perl-Catalyst-Devel.spec
@@ -1,7 +1,7 @@
 Name:   perl-Catalyst-Devel
 Summary:Catalyst Development Tools
 Version:1.31
-Release:3%{?dist}
+Release:4%{?dist}
 License:GPL+ or Artistic
 Group:  Development/Libraries
 Source0:
http://search.cpan.org/CPAN/authors/id/B/BO/BOBTFISH/Catalyst-Devel-%{version}.tar.gz
@@ -87,6 +87,9 @@ rm -rf %{buildroot}
 %exclude %{perl_vendorlib}/Catalyst/Restarter/Win32.pm
 
 %changelog
+* Thu Jul 21 2011 Petr Sabata con...@redhat.com - 1.31-4
+- Perl mass rebuild
+
 * Thu Jul 21 2011 Petr Sabata con...@redhat.com - 1.31-3
 - Perl 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

Broken abrt/ libreport dependencies

[Joshua C.]

The nightly builds for f16 are broken for the last 4-5 days because of
the abrt and libreport packages and the error is:

DEBUG util.py:247:  Package abrt-plugin-bugzilla is obsoleted by
libreport-plugin-bugzilla, but obsoleting package does not provide for
requirements
DEBUG util.py:247:  Package abrt-plugin-logger is obsoleted by
libreport-plugin-logger, but obsoleting package does not provide for
requirements

DEBUG util.py:247:  abrt-desktop-2.0.3-1.fc16.x86_64 requires abrt-plugin-logger

Can someone please look at the packages?
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: rpm builds failing with Installed (but unpackaged) file(s) found

[Rex Dieter]

Panu Matilainen wrote:

 But since being rebuilt yesterday with the new 4.9.1, some of those
 directories are now listed with the trailing slash:

 /etc/httpd/
 /etc/httpd/conf.d/
 /etc/httpd/conf.d/README
 /etc/httpd/conf.d/welcome.conf
 /etc/httpd/conf/
 /etc/httpd/conf/httpd.conf
 /etc/httpd/conf/magic
 /etc/httpd/logs

 Which has broken at least one package that requires /etc/httpd/conf.d

 Is listing the trailing slash intended behaviour and the dependent
 package(s) now needs fixing?
 
 Hmm, no that's not intended either. Appears to be one of those
 releases... sigh. Please just untag rpm-4.9.1-2.fc16 too, I'll try to
 have a look at it tomorrow.

untagged.

-- rex

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

Re: Broken abrt/ libreport dependencies

[Jiri Moskovcak]

On 07/21/2011 07:32 PM, Joshua C. wrote:
 The nightly builds for f16 are broken for the last 4-5 days because of
 the abrt and libreport packages and the error is:

 DEBUG util.py:247:  Package abrt-plugin-bugzilla is obsoleted by
 libreport-plugin-bugzilla, but obsoleting package does not provide for
 requirements
 DEBUG util.py:247:  Package abrt-plugin-logger is obsoleted by
 libreport-plugin-logger, but obsoleting package does not provide for
 requirements

 DEBUG util.py:247:  abrt-desktop-2.0.3-1.fc16.x86_64 requires 
 abrt-plugin-logger

 Can someone please look at the packages?

Hi,
fixing it right now. libreport-2.0.5-2 is building at the moment, new 
abrt will follow in a few minutes.

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

[perl-Image-ExifTool] Perl mass rebuild

[Petr Sabata]

commit 87799a7c7a8c69e2b66680ccc91db5d1219a765a
Author: Petr Sabata con...@redhat.com
Date:   Thu Jul 21 18:28:17 2011 +0200

Perl mass rebuild

 perl-Image-ExifTool.spec |5 -
 1 files changed, 4 insertions(+), 1 deletions(-)
---
diff --git a/perl-Image-ExifTool.spec b/perl-Image-ExifTool.spec
index 51652c7..a9948a4 100644
--- a/perl-Image-ExifTool.spec
+++ b/perl-Image-ExifTool.spec
@@ -1,6 +1,6 @@
 Name:  perl-Image-ExifTool
 Version:   8.60
-Release:   2%{?dist}
+Release:   3%{?dist}
 License:   GPL+ or Artistic
 Group: Applications/Multimedia
 Summary:   Utility for reading and writing image meta info
@@ -52,6 +52,9 @@ make test
 %{_mandir}/man3/*.3*
 
 %changelog
+* Thu Jul 21 2011 Petr Sabata con...@redhat.com - 8.60-3
+- Perl mass rebuild
+
 * Wed Jul 20 2011 Petr Sabata con...@redhat.com - 8.60-2
 - Perl 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: new cg-manager gui tool for managin cgroups

[Lennart Poettering]

On Thu, 21.07.11 19:23, Tomas Mraz (tm...@redhat.com) wrote:

 
 On Thu, 2011-07-21 at 10:20 -0400, Jason Baron wrote: 
  Hi,
  
  On Wed, Jul 20, 2011 at 10:28:32PM +0200, Lennart Poettering wrote:
   On Wed, 20.07.11 15:20, Jason Baron (jba...@redhat.com) wrote:
   
   Heya,
   
The memory and cpu share controllers are currently supported (I simply 
haven't
gotten to supporting other controllers yet). One can add/delete 
cgroups, change
configuration parameters, and see which processes are currently 
associated
with each cgroup. There is also a 'usage' view, which displays 
graphically the
real-time usage statistics. The cgroup configuration can then be saved
into /etc/cgconfig.conf using the 'save' menubar button.
   
   How does it write that file? Does the UI run as root? That's not really
   desirable. It's not secure and it is cumbersome to mix applications
   running as differnt users on the same session and one the same X
   screen (since they cannot communicate with dbus, and so on).
  
  Right, as Dan Walsh, mentioned I need to separate this into two parts -
  the front end UI and a backend communicating via DBUS. This is had been
  a todo item.
 
 Note that in case the services that the backend provides for the GUI are
 really powerful there is no real security benefit in separating the GUI
 and backend. 
 
 I am not sure that a cgroup manager would be such case though.
 
 For example if the backend service is interface to enable and configure
 various network based authentication services as it would be in case of
 authconfig if it was split into GUI and backend, then you can easily
 instruct the backend to authenticate against a network service that will
 give you root user with no password. So we would have to trust the user
 X session that is the authconfig frontend running in anyway.

There's quite a substantial security benefit here. If you use stuff like
PK you can ensure that UIs only ask for and get very specific privileges
when interacting with the mechanism. That means even if you cannot trust
your UI it will be able to do very few bad things only. If you entire UI
runs as roo however, it can do pretty much everything it wants.

Lennart

-- 
Lennart Poettering - Red Hat, Inc.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

RE: Broken abrt/ libreport dependencies

[Joshua C.]

2011/7/21 Jiri Moskovcak jmosk...@redhat.com:
 On 07/21/2011 07:32 PM, Joshua C. wrote:

 The nightly builds for f16 are broken for the last 4-5 days because of
 the abrt and libreport packages and the error is:

 DEBUG util.py:247:  Package abrt-plugin-bugzilla is obsoleted by
 libreport-plugin-bugzilla, but obsoleting package does not provide for
 requirements
 DEBUG util.py:247:  Package abrt-plugin-logger is obsoleted by
 libreport-plugin-logger, but obsoleting package does not provide for
 requirements

 DEBUG util.py:247:  abrt-desktop-2.0.3-1.fc16.x86_64 requires
 abrt-plugin-logger

 Can someone please look at the packages?

 Hi,
 fixing it right now. libreport-2.0.5-2 is building at the moment, new abrt
 will follow in a few minutes.

 J.


Thanks, I think this can also fix
https://bugzilla.redhat.com/show_bug.cgi?id=723376
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Starting user UIDs at 1000 - please check your packages

[seth vidal]

On Thu, 2011-07-21 at 12:57 -0400, James Antill wrote:
 On Wed, 2011-07-20 at 22:59 +0200, Miloslav Trmač wrote:
  On Wed, Jul 20, 2011 at 10:55 PM, James Antill ja...@fedoraproject.org 
  wrote:
Is it really necessary to change this in %pre ... can't you just copy
   your old login.defs file over the installed one during kickstart %post
   (or even do it by hand, post install)?
  
  Unfortunately it is necessary to do it in %pre because users and
  groups created in package scriptlets without specifiying an UID/GID
  explicitly get assigned 999, 998, ... .
 
  Doing it this way means it is guaranteed 100% incompatible between
 versions, NFS etc. will be a giant pain for a lot of users. Would it not
 be possible to change the behaviour to be more compatible (Eg. assign
 the first 99 from 499-400, and then move to 999)?
  It seems like a big price to pay to go from you may be affected to
 we guarantee we've it.

I agree. We KNOW that this will impact a number of users - many of them
in a position to have to support older machines and newer machines and
will be wedged with some awful solutions for a while.

If we can't go to 999 how about we go way up to the 2million+ range?

either way: +1 to what James wrote.

-sv


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

[perl-File-NFSLock] Perl mass rebuild

[Petr Sabata]

commit ef9ca92ef3ed1327e542f1f914cb8833f74bda1e
Author: Petr Sabata con...@redhat.com
Date:   Thu Jul 21 18:14:24 2011 +0200

Perl mass rebuild

 perl-File-NFSLock.spec |5 -
 1 files changed, 4 insertions(+), 1 deletions(-)
---
diff --git a/perl-File-NFSLock.spec b/perl-File-NFSLock.spec
index 6185bac..57ce521 100644
--- a/perl-File-NFSLock.spec
+++ b/perl-File-NFSLock.spec
@@ -1,6 +1,6 @@
 Name:   perl-File-NFSLock
 Version:1.21
-Release:2%{?dist}
+Release:3%{?dist}
 Summary:Perl module to do NFS (or not) locking
 Group:  Development/Libraries
 License:GPL+ or Artistic
@@ -50,6 +50,9 @@ make test
 %{_mandir}/man3/*.3*
 
 %changelog
+* Thu Jul 21 2011 Petr Sabata con...@redhat.com - 1.21-3
+- Perl mass rebuild
+
 * Wed Jul 20 2011 Petr Sabata con...@redhat.com - 1.21-2
 - Perl 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: Starting user UIDs at 1000 - please check your packages

[Miloslav Trmač]

On Thu, Jul 21, 2011 at 6:57 PM, James Antill ja...@fedoraproject.org wrote:
 On Wed, 2011-07-20 at 22:59 +0200, Miloslav Trmač wrote:
 On Wed, Jul 20, 2011 at 10:55 PM, James Antill ja...@fedoraproject.org 
 wrote:
   Is it really necessary to change this in %pre ... can't you just copy
  your old login.defs file over the installed one during kickstart %post
  (or even do it by hand, post install)?

 Unfortunately it is necessary to do it in %pre because users and
 groups created in package scriptlets without specifiying an UID/GID
 explicitly get assigned 999, 998, ... .

  Doing it this way means it is guaranteed 100% incompatible between
 versions, NFS etc. will be a giant pain for a lot of users. Would it not
 be possible to change the behaviour to be more compatible (Eg. assign
 the first 99 from 499-400, and then move to 999)?

No, applications expect system accounts and user accounts to have
non-overlapping ID intervals.  So this would be just a more broken
version of keeping the limit at 500.
   Mirek
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

[perl-MooseX-Types-Perl] Perl mass rebuild

[Petr Sabata]

commit 4904fcc67b1a7993260c589e55c78bd56591f94c
Author: Petr Sabata con...@redhat.com
Date:   Thu Jul 21 18:26:22 2011 +0200

Perl mass rebuild

 perl-MooseX-Types-Perl.spec |5 -
 1 files changed, 4 insertions(+), 1 deletions(-)
---
diff --git a/perl-MooseX-Types-Perl.spec b/perl-MooseX-Types-Perl.spec
index 927f88e..6abd1b4 100644
--- a/perl-MooseX-Types-Perl.spec
+++ b/perl-MooseX-Types-Perl.spec
@@ -1,6 +1,6 @@
 Name:   perl-MooseX-Types-Perl
 Version:0.101340
-Release:4%{?dist}
+Release:5%{?dist}
 Summary:Moose types that check against Perl syntax
 License:GPL+ or Artistic
 Group:  Development/Libraries
@@ -52,6 +52,9 @@ rm -rf $RPM_BUILD_ROOT
 %{_mandir}/man3/*
 
 %changelog
+* Thu Jul 21 2011 Petr Sabata con...@redhat.com - 0.101340-5
+- Perl mass rebuild
+
 * Thu Jul 21 2011 Petr Sabata con...@redhat.com - 0.101340-4
 - Perl 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: F15: ugly behavior of df

[Jeff Spaleta]

 i need NOT to reset your expectations because if i would
 start to expect that it is mordern everywhere to replace working
 things with new stuff which is NOT READY i should throw
 away all my computers and search a job in a church

Well you do what you feel is best for you. Working at a church can be
a rewarding experience, it may in fact help you develop a modicum of
empathy for other human beings in a way that living entirely through
electronic interaction cannot. I personally enjoy the time I volunteer
at my church


Anyways
I've tried to point you to a modicum of historical context to give you
some breadcrumbs to follow to gain some perspective on how long people
(not just our distribution) have been struggling to resolve the
problems associated with relying on /etc/mtab.  The reality is
mounting over the years in linux has seen a lot of changes in the
past 10 years with more and more kernel level fake filesystems that
are not attached to block devices show up.  Many people have come to
understand that the best solution to all the problems is to rely on
the kernel's own knowledge of the mount points and to stop relying on
/etc/mstab as constructed artificially which can get out of sync with
the kernel's mounting information.

Some of the historic problems with relying on mtab has been encoded in
the mount manpage for awhile now(well before Fedora even considered
moving away from mtab) and I've personally pointed you to an upstream
list discussion concerning the problems relying on mtab dating back to
2007.

And to be clear Fedora isn't the first distribution to turn /etc/mtab
into a symlink. Hell, even _historic_ linux from scratch manual has
instructions that tell people to turn mtab into a symlink into
/proc/mounts.

http://archive.linuxfromscratch.org/lfs-museum/3.3/LFS-BOOK-3.3-HTML/index.html

That dates from 2003!! 2003!!! There have been people out
there, smart do-it-yourselfers working with LFS to build up their own
linux distro from sources who have been making the very change that is
frustrating you in 2003.


is there a problem with bind mount handling? Yes  Was it caught in
testing? Seems like it wasn't.  Does Fedora make any effort to test
bind mounts as part of organized pre-release QA? I'm not aware that we
do as our pre-release QA is quite narrowly scoped to ensure default
install configs as we don't have the resources to test all possible
configurations and command options.  Did anyone who makes use of bind
mounts day to day in our userbase flag this ahead of release? I didn't
and I really can't lay the blame at the feet of developers for
shipping something not ready when I myself, who was actively testing
for breakage, didn't catch this.

And make no mistake the solution to bind mount handling and
representation moving forward will not depend on reverting to using
the constructed information in /etc/mtab and will have to depend on
the kernel's /proc/mounts.  Tools that relied on mtab's understanding
of what a bind mount was (and it seems also the user option if I'm
reading the mount manpage correctly.) There has been years of
discussion on the issue of mtab versus /proc/mounts outside of our
specific distribution channels, and there is no getting around it that
the long term solution is to rely on the kernel's own representation
of mounts.


Though I wonder, since /etc/mtab is just a symlink. is the mount
command we ship still able to write to /etc/mtab if a local admin
decided to revert and make /etc/mtab a normal file again.  Would our
mount command then update that file as per the legacy way? because
really that is exactly what you want to do on your system.   If our
mount command will still attempt to write to /etc/mtab once its a real
file again, maybe things will work for you as expected.

-jef









You've only taken notice because its finally impacted you.


I think its ready enough to ship


I believe your definition of ready is incompatible with the release
model Fedora has chosen.

Your expectation is that new things work exactly the same and have
detailed backwards compatability. That's hasn't been true _ever_ in
any system I've had the pleasure of doing upgrades across major
releases.

windows, qnx,vms,mac os, linux tons and tons and tons of subtle
syntax channges in shipped functionality that resulted in breakage in
my working code on all those systems in different places at
different times.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Broken abrt/ libreport dependencies

[Jiri Moskovcak]

On 07/21/2011 07:59 PM, Joshua C. wrote:
 2011/7/21 Jiri Moskovcakjmosk...@redhat.com:
 On 07/21/2011 07:32 PM, Joshua C. wrote:

 The nightly builds for f16 are broken for the last 4-5 days because of
 the abrt and libreport packages and the error is:

 DEBUG util.py:247:  Package abrt-plugin-bugzilla is obsoleted by
 libreport-plugin-bugzilla, but obsoleting package does not provide for
 requirements
 DEBUG util.py:247:  Package abrt-plugin-logger is obsoleted by
 libreport-plugin-logger, but obsoleting package does not provide for
 requirements

 DEBUG util.py:247:  abrt-desktop-2.0.3-1.fc16.x86_64 requires
 abrt-plugin-logger

 Can someone please look at the packages?

 Hi,
 fixing it right now. libreport-2.0.5-2 is building at the moment, new abrt
 will follow in a few minutes.

 J.


 Thanks, I think this can also fix
 https://bugzilla.redhat.com/show_bug.cgi?id=723376

should be fixed by:

abrt-2.0.4-1.fc16
libreport-2.0.5-2.fc16
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: boost 1.47.0

[Petr Machata]

Jon Ciesla l...@jcomserv.net writes:

 Wesnoth seems not to like the new Boost all that well:

 http://koji.fedoraproject.org/koji/getfile?taskID=3218720name=build.log

 Is this a common sort of error?  My Boost-fu is weak, so there might be
 something obvious I'm missing.

Yeah, all boost errors tend to spew lines and lines of error messages
like that.  That's the nature of them templetes.  I'm looking into this
one, and it seems to be some interplay between BOOST_FOREACH,
boost::ptr_vector and GCC version.  Not sure what exactly yet.

It can be worked around by replacing the foreach calls in
wesnoth-1.8.6/src/gui/widgets/tree_view_node.cpp in this manner:

-   foreach(const ttree_view_node node, children_) {
+   for (boost::ptr_vectorttree_view_node::const_iterator it
+  = children_.begin (); it != children_.end (); ++it) {
+   const ttree_view_node node = *it;

Thanks,
PM
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: new cg-manager gui tool for managin cgroups

[Daniel J Walsh]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 07/21/2011 12:36 PM, Lennart Poettering wrote:
 On Thu, 21.07.11 11:28, Vivek Goyal (vgo...@redhat.com) wrote:
 
 It is already possible for different applications to use cgroups 
 without stepping on each other, and without requiring every app 
 to communicate with each other.
 
 As an example, when it starts libvirt will look at what cgroup it
 has been placed in, and create the VM cgroups below this point. 
 So systemd can put libvirtd in an arbitrary location and set an 
 overall limits for the virtualization service, and it will cap 
 all VMs. No direct communication between systemd  libvirt is 
 required.
 
 If applications similarly take care to honour the location in 
 which they were started, rather than just creating stuff
 directly in the root cgroup, they too will interoperate nicely.
 
 This is one of the nice aspects to the cgroups hierarchy, and why
 having tools/daemons which try to arbitrarily re-arrange cgroups
 systemwide are not very desirable IMHO.
 
 This will work as long as somebody has done the top level setup
 and planning. For example, if somebody is running bunch of virtual
 machines and hosting some native applications and services also on
 the machine, then he might decide that all the virt machines can
 only use 8 out of 10 cpus and keep 2 cpus free for native
 services.
 
 In that case an admin ought to be able to do this top level
 planning before handing out control of sub-hierarchies to
 respective applications. Does systemd allow that as of today?
 
 Right now, systemd only offers you to place services in the cgroups
 of your choice, it will not configure any settings on those cgroups.
 (This is very likely to change soon though as there is a patch
 pending that makes a number of popular controls available as native
 config options in systemd.)
 
 For the controllers like cpuset or the RT part of cpu where you 
 assign resources from a limited pool we currently have no solution
 at all to deal with conflicts. Neither in libcgroup and friends, not
 in systemd, not in libvirt.
 
 However, I do think that figuring out the conflicts here is something
 to fix at the UI level -- and systemd itself (or libvirt) should not
 have to deal with this at all. The UIs should figure that out
 between themselves. I think it should be possible to come up with
 really simple schemes to deal with this however. For example, have
 every UI drop in some dir /var/lib or so a file encoding which
 resources have been taken and should not available in the other UIs
 anymore, maybe with a descriptive stirng, so that those UIs can show
 who took it away.
 
 However, I believe that adding something like that should be the
 last step to care for in a UI. So far systemd doesn't have any
 comprehensive UI. How to deal with conflicts between resource
 assignments is not a central problem that would justify moving all
 the consumers of cgroups on some additional middleware.
 
 To allow that I think systemd should either provide native
 configuration capability or build on top of existing libcgroups
 constructs like cgconfig, cgrules.conf to decide how an admin has
 planned the resource management and in what cgroups services have
 to be launched, IMHO.
 
 For the systemd case I'd assume that a UI which wants to enable the 
 admin to control cgroup limits would just place a unit file for the 
 respective service in /etc/systemd/system, use .include to pull in
 the original unit file, and set the setting it wants to set.
 
 Lennart
 


One goal I have for sandbox would be to allow it to plug into the
cgroups hiearchy also.  So a user could say I want to run all my
sandboxes in such a way that they can only use X% of my CPU and Y% of
memory.  Allowing a user to always be able to kill the sandbox.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk4ohGwACgkQrlYvE4MpobONCQCfSX64iqXWKCokiuG8/ehxfl3L
pTsAn3iRyJJNADkeY9O/osOrqcdPRL96
=aq0Q
-END PGP SIGNATURE-
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: boost 1.47.0

[Petr Machata]

Petr Machata pmach...@redhat.com writes:

 Jon Ciesla l...@jcomserv.net writes:

 Wesnoth seems not to like the new Boost all that well:

 http://koji.fedoraproject.org/koji/getfile?taskID=3218720name=build.log

 Is this a common sort of error?  My Boost-fu is weak, so there might be
 something obvious I'm missing.

 Yeah, all boost errors tend to spew lines and lines of error messages
 like that.  That's the nature of them templetes.  I'm looking into this
 one, and it seems to be some interplay between BOOST_FOREACH,
 boost::ptr_vector and GCC version.  Not sure what exactly yet.

... and boost::noncopyable.  Forgot about that one.

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

Re: new cg-manager gui tool for managin cgroups

[Jason Baron]

On Thu, Jul 21, 2011 at 05:53:13PM +0200, Lennart Poettering wrote:
 On Thu, 21.07.11 16:36, Daniel P. Berrange (berra...@redhat.com) wrote:
 
  IIRC, you can already set cgroups configuration in the service's
  systemd unit file, using something like:
  
   ControlGroup=cpu:/foo/bar mem:/wizz
  
  though I can't find the manpage right now.
 
 Yes, this is supported in systemd (though without the ).
 
 It's (tersely) documented in systemd.exec(5).
 
 My guess is that we'll cover about 90% or so of the usecases of cgroups
 if we make it easy to assign cgroup-based limits to VMs, to system
 services and to users, like we can do with libvirt and systemd. There's
 still a big chunk of the 10% who want more complex setups with more
 arbitrary groupings, but I have my doubts the folks doing that are the
 ones who need a UI for that.
 

Ok, if systemd is planning to add all these knobs and buttons to cover all of
these cgroups use cases, then yes, we probably don't need another management
layer nor the UI. I guess we could worry about the more complex setups when
we better understand what they are, once systemd has added more cgroup
support. (I only recently understood that systemd was adding all this
cgroups support). In fact, at that point we probably don't need
libcgroup either.

thanks,

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

Re: new cg-manager gui tool for managin cgroups

[Vivek Goyal]

On Thu, Jul 21, 2011 at 04:15:46PM -0400, Jason Baron wrote:
 On Thu, Jul 21, 2011 at 05:53:13PM +0200, Lennart Poettering wrote:
  On Thu, 21.07.11 16:36, Daniel P. Berrange (berra...@redhat.com) wrote:
  
   IIRC, you can already set cgroups configuration in the service's
   systemd unit file, using something like:
   
ControlGroup=cpu:/foo/bar mem:/wizz
   
   though I can't find the manpage right now.
  
  Yes, this is supported in systemd (though without the ).
  
  It's (tersely) documented in systemd.exec(5).
  
  My guess is that we'll cover about 90% or so of the usecases of cgroups
  if we make it easy to assign cgroup-based limits to VMs, to system
  services and to users, like we can do with libvirt and systemd. There's
  still a big chunk of the 10% who want more complex setups with more
  arbitrary groupings, but I have my doubts the folks doing that are the
  ones who need a UI for that.
  
 
 Ok, if systemd is planning to add all these knobs and buttons to cover all of
 these cgroups use cases, then yes, we probably don't need another management
 layer nor the UI. I guess we could worry about the more complex setups when
 we better understand what they are, once systemd has added more cgroup
 support. (I only recently understood that systemd was adding all this
 cgroups support). In fact, at that point we probably don't need
 libcgroup either.

So the model seems to be that there are various components which control
their own children. 

So at top level is systemd which controls users, services and libvirtd
and will provide interfaces/options to be able to configure cgroups
and resources for its children.

Similarly libvirtd will provide interfaces/options to be able to configure
cgroups/resources for its children (primary VMs and possibly containers at
some point of time).

And down the line if there is another significant component comes along
it does the same thing.

So every component defines its own sytax and interfaces to configure
cgroups and there is no global control. If somebody wants to mangage
the system remotely, it got to decide what it wants to control and then
use the API offered by respective manager (systemd, libvirt, xyz)?

Thanks
Vivek
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: F15: ugly behavior of df

[Karel Zak]

On Thu, Jul 21, 2011 at 10:51:59AM -0800, Jeff Spaleta wrote:
 Though I wonder, since /etc/mtab is just a symlink. is the mount
 command we ship still able to write to /etc/mtab if a local admin
 decided to revert and make /etc/mtab a normal file again.  Would our
 mount command then update that file as per the legacy way? 

 Yes.

 because
 really that is exactly what you want to do on your system.   If our
 mount command will still attempt to write to /etc/mtab once its a real
 file again, maybe things will work for you as expected.
 
 No. systemd is not compatible with /etc/mtab

Karel

-- 
 Karel Zak  k...@redhat.com
 http://karelzak.blogspot.com
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: new cg-manager gui tool for managin cgroups

[Vivek Goyal]

On Thu, Jul 21, 2011 at 06:17:03PM +0200, Lennart Poettering wrote:
 On Thu, 21.07.11 15:52, Daniel P. Berrange (berra...@redhat.com) wrote:
 
   I think its a question of do we want to make users go to a bunch of
   different front end tools, which don't communicate with each other to
   configure the system? I think it makes sense to have libvirt or
   virt-manager and systemd front-end be able to configure cgroups, but I
   think it would be also nice if they could know when the step on each
   other. I think it would also be nice if there was a way to help better
   understand how the various system components are making use of cgroups
   and interacting. I liked to see an integrated desktop approach - not one
   where separate components aren't communicating with each other. 
  
  It is already possible for different applications to use cgroups
  without stepping on each other, and without requiring every app
  to communicate with each other.
  
  As an example, when it starts libvirt will look at what cgroup
  it has been placed in, and create the VM cgroups below this point.
  So systemd can put libvirtd in an arbitrary location and set an
  overall limits for the virtualization service, and it will cap
  all VMs. No direct communication between systemd  libvirt is
  required.
 
 systemd (when run as the user) does exactly the same thing btw. It will
 discover the group it is urnning in, and will create all its groups
 beneath that.
 
 In fact, right now the cgroup hierarchy is not virtualized. To make sure
 systemd works fine in a container we employ the very same logic here: if
 the container manager started systemd in specific cgroup, then system
 will do all its stuff below that, even if it is PID 1.

How does the cgroup hierarchy look like in case of containers? I thought
libvirtd will do all container management and libvirtd is one of the services
started by systemd.

Thanks
Vivek
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Starting user UIDs at 1000 - please check your packages

[Simo Sorce]

On Thu, 2011-07-21 at 13:59 -0400, seth vidal wrote:
 On Thu, 2011-07-21 at 12:57 -0400, James Antill wrote:
  On Wed, 2011-07-20 at 22:59 +0200, Miloslav Trmač wrote:
   On Wed, Jul 20, 2011 at 10:55 PM, James Antill ja...@fedoraproject.org 
   wrote:
 Is it really necessary to change this in %pre ... can't you just copy
your old login.defs file over the installed one during kickstart %post
(or even do it by hand, post install)?
   
   Unfortunately it is necessary to do it in %pre because users and
   groups created in package scriptlets without specifiying an UID/GID
   explicitly get assigned 999, 998, ... .
  
   Doing it this way means it is guaranteed 100% incompatible between
  versions, NFS etc. will be a giant pain for a lot of users. Would it not
  be possible to change the behaviour to be more compatible (Eg. assign
  the first 99 from 499-400, and then move to 999)?
   It seems like a big price to pay to go from you may be affected to
  we guarantee we've it.

Sometimes you have to break some eggs, that said I would favor changing
the behavior to grow from 400 up to 999 instead of grown down from 999
to 400, sounds more sensible.

 I agree. We KNOW that this will impact a number of users - many of them
 in a position to have to support older machines and newer machines and
 will be wedged with some awful solutions for a while.
 
 If we can't go to 999 how about we go way up to the 2million+ range?

That would be *much* worse.

Simo.

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

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

Re: F15: ugly behavior of df

[Jeff Spaleta]

On Thu, Jul 21, 2011 at 12:45 PM, Karel Zak k...@redhat.com wrote:
 because
 really that is exactly what you want to do on your system.   If our
 mount command will still attempt to write to /etc/mtab once its a real
 file again, maybe things will work for you as expected.

  No. systemd is not compatible with /etc/mtab

To be clear, you are saying that systemd won't be updating /etc/mtab
like the mount command tries to do?

If so, I believe a sufficiently motivated admin would be able to
figure out a way to manually update /etc/mtab from /proc/mounts if
they wanted to see systemd mounted items in their site specific mtab
they are trying to maintain. I don't think its impossible, I've
seen(created) crazier site specific admin hacks to keep backwards
compatibility on an as needed basis.


Just for completely I've done some more historical searches and I'm
seeing this argument between mtab and /proc/*/mounts  going all the
way back to 2000.  And in all of the historic discussion I've seen
relying on ./proc/*/mount has been the recommendation due to it being
a canonical representation of what the mount points actually are at
any given point in time.

Ten+ years of trying to live with two slightly different ways of
accounting for mountpoints, each with their own limitations is more
than enough time. While the bind mount situation we have now is
somewhat unfortunate in that we didn't catch it in time to be
proactive about it in F15, the fact that we've been living with this
divergence for ten years speaks volumes about the necessity to bite
the bullet and cut over to the /proc/*/mount information in a release
and triage accordingly as the breakage reports come it.

Do you have a complete listing somewhere of the info thekernel does
not encode into /proc/mounts that mount has traditionally encodes into
/etc/mtab that existing tools might be making use of? I'm pretty sure
based on everything I've read its not just bind mount info, but also
perhaps user or group info concerning who has permission to mount and
umount? Moving foward such a list would probably help mitigate
frustration and give admins a starting point to adjusting their site
specific configs.

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

Re: F15: ugly behavior of df

[Karel Zak]

On Thu, Jul 21, 2011 at 08:09:08AM -0400, Genes MailLists wrote:
 On 07/21/2011 07:09 AM, Steve Clark wrote:
 
  Well what benefit(s) does the new 'df' provide, is it worth all the pain
  it brings?
  
 
   I concur - the current df behavior is well .. goofy :-) - however this
 may be tricky to fix in the new world - but should be fixed.
 
   If this behavior is somehow desirable it would be preferable to  make
 it an option (like df --full or whatever) and make the default something
 more sensible.
 
   That said, it may be tricky in the new world;
 
where can you retrieve the info about a mount being a bind mount ?
 How can you push the chrooted bind mounts into being less obtrusive (or
 even optional, --show-chrooted-mounts)
 
   /proc/mounts does not seem to distinguish bind mounts - so this may
 have to be a kernel change and perhaps adding /proc/mounts/bind and
 moving bind mounts 1 level down - this is not an area I know a lot about
 however, so I'll leave this to the real experts.

 I've already talked about it in this list... bind is operation, not
 state of any mountpoint. Something like /proc/mounts/bind does not
 make sense from kernel's point of view.

 On Linux arbitrary filesystem could be mounted to more than one place 
 in VFS -- our userspace utils have to accept this fact...

Karel

-- 
 Karel Zak  k...@redhat.com
 http://karelzak.blogspot.com
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Starting user UIDs at 1000 - please check your packages

[seth vidal]

On Thu, 2011-07-21 at 17:02 -0400, Simo Sorce wrote:
 On Thu, 2011-07-21 at 13:59 -0400, seth vidal wrote:
  On Thu, 2011-07-21 at 12:57 -0400, James Antill wrote:
   On Wed, 2011-07-20 at 22:59 +0200, Miloslav Trmač wrote:
On Wed, Jul 20, 2011 at 10:55 PM, James Antill 
ja...@fedoraproject.org wrote:
  Is it really necessary to change this in %pre ... can't you just copy
 your old login.defs file over the installed one during kickstart %post
 (or even do it by hand, post install)?

Unfortunately it is necessary to do it in %pre because users and
groups created in package scriptlets without specifiying an UID/GID
explicitly get assigned 999, 998, ... .
   
Doing it this way means it is guaranteed 100% incompatible between
   versions, NFS etc. will be a giant pain for a lot of users. Would it not
   be possible to change the behaviour to be more compatible (Eg. assign
   the first 99 from 499-400, and then move to 999)?
It seems like a big price to pay to go from you may be affected to
   we guarantee we've it.
 
 Sometimes you have to break some eggs, that said I would favor changing
 the behavior to grow from 400 up to 999 instead of grown down from 999
 to 400, sounds more sensible.
 
  I agree. We KNOW that this will impact a number of users - many of them
  in a position to have to support older machines and newer machines and
  will be wedged with some awful solutions for a while.
  
  If we can't go to 999 how about we go way up to the 2million+ range?
 
 That would be *much* worse.
 

Why?
-sv


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

[perl-Package-Stash-XS/el6] (3 commits) ...Update to 0.22

[Paul Howarth]

Summary of changes:

  4e95f4d... Update to 0.21 (*)
  a26f1d5... - Rebuilt for https://fedoraproject.org/wiki/Fedora_15_Mass (*)
  802846c... Update to 0.22 (*)

(*) 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: UseSWIG.cmake is borked - need help with workaround

[Orion Poplawski]

On 07/20/2011 08:29 PM, Ankur Sinha wrote:
 Hello,

 In the cmake version residing in rawhide, the UseSWIG.cmake file is
 broken. Upstream is aware of this. I've also filed a bug with fedora
 here[1].

 I'd like to find a temporary solution to this. gdcm cannot build in
 rawhide, and a lot of fedora-medical related packages are failing to
 build in rawhide because of this.

 I have the fedora 15 version of the UseSWIG.cmake file, which worked
 correctly. How can I use this in my mock build? I need to *force* cmake
 to use this file instead of it's own module.

 I've placed the f15-UseSWIG.cmake in the project/CMake directory, but
 Cmake still finds its own broken module. What else does one need to do
 here?

 [1] https://bugzilla.redhat.com/show_bug.cgi?id=723652


Updated cmake should now be in rawhide.

-- 
Orion Poplawski
Technical Manager 303-415-9701 x222
NWRA/CoRA DivisionFAX: 303-415-9702
3380 Mitchell Lane  or...@cora.nwra.com
Boulder, CO 80301  http://www.cora.nwra.com
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel