date:20120227

A file has been added to the lookaside cache for perl-PPIx-Regexp:

931e98dc04fce70918839760132a537f  PPIx-Regexp-0.026.tar.gz
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel

[perl-PPIx-Regexp] 0.026 bump

commit 7cd7e60b53ad3f33097a905c864a94fe850a5e6e
Author: Petr Písař 
Date:   Mon Feb 27 13:14:02 2012 +0100

0.026 bump

 .gitignore|1 +
 perl-PPIx-Regexp.spec |5 -
 sources   |2 +-
 3 files changed, 6 insertions(+), 2 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index 0491ac3..c269d6d 100644
--- a/.gitignore
+++ b/.gitignore
@@ -14,3 +14,4 @@ PPIx-Regexp-0.007.tar.gz
 /PPIx-Regexp-0.023.tar.gz
 /PPIx-Regexp-0.024.tar.gz
 /PPIx-Regexp-0.025.tar.gz
+/PPIx-Regexp-0.026.tar.gz
diff --git a/perl-PPIx-Regexp.spec b/perl-PPIx-Regexp.spec
index 0ffb2fc..c094bfc 100644
--- a/perl-PPIx-Regexp.spec
+++ b/perl-PPIx-Regexp.spec
@@ -1,5 +1,5 @@
 Name:   perl-PPIx-Regexp
-Version:0.025
+Version:0.026
 Release:1%{?dist}
 Summary:Represent a regular expression of some sort
 License:GPL+ or Artistic
@@ -46,6 +46,9 @@ find $RPM_BUILD_ROOT -depth -type d -exec rmdir {} 
2>/dev/null \;
 %{_mandir}/man3/*
 
 %changelog
+* Mon Feb 27 2012 Petr Pisar  - 0.026-1
+- 0.026 bump
+
 * Mon Jan 23 2012 Petr Pisar  - 0.025-1
 - 0.025 bump
 
diff --git a/sources b/sources
index 3ca8981..6d08e7b 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-ae7ea4f2996598a046e73055fc54dcac  PPIx-Regexp-0.025.tar.gz
+931e98dc04fce70918839760132a537f  PPIx-Regexp-0.026.tar.gz
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel

[Bug 797862] perl-IO-TieCombine-1.002 is available

Please do not reply directly to this email. All additional
comments should be made in the comments box of this bug.


https://bugzilla.redhat.com/show_bug.cgi?id=797862

Petr Pisar  changed:

   What|Removed |Added

 Status|ASSIGNED|CLOSED
   Fixed In Version||perl-IO-TieCombine-1.002-1.
   ||fc18
 Resolution||RAWHIDE
Last Closed||2012-02-27 07:11:38

-- 
Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug.
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel

Re: How to determine FAS from BZ email?

2012-02-27 Thread Miroslav Suchý


On 02/23/2012 04:48 PM, Ken Dreyer wrote:

I'm in agreement with this. Do we need to open a ticket with the FPC?


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

--
Miroslav Suchy
Red Hat Satellite Engineering
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

[Bug 797867] perl-XML-LibXML-1.93 is available

Please do not reply directly to this email. All additional
comments should be made in the comments box of this bug.


https://bugzilla.redhat.com/show_bug.cgi?id=797867

Petr Šabata  changed:

   What|Removed |Added

 Status|ASSIGNED|CLOSED
   Fixed In Version||perl-XML-LibXML-1.93-1.fc18
 Resolution||RAWHIDE
Last Closed||2012-02-27 07:54:54

-- 
Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug.
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel

Re: Clarify our position on forks (was: Re: Plan for tomorrow's FESCo meeting (2012-02-27 at 18UTC))

2012-02-27 Thread Stephen Gallagher

On Mon, 2012-02-27 at 08:07 +0100, Thorsten Leemhuis wrote:
> Kevin Fenzi wrote on 27.02.2012 04:21:
> > 
> > #topic #810 Clarify our position on forks .fesco 810
> 
> It's just a statement that is asked for in the ticket, but nevertheless:
> Shouldn't issues like this be discussed on this list first, so FESCo
> members can get a impression from the flamewar ^w discussion what the
> developer community thinks about the issue raised?
> 

Personally, my stance on this is that, provided that the forks are
properly renamed such that they will not conflict with other forks of
the same codebase, there's no reason to disallow them. As mentioned by
Toshio in the ticket, carrying forks provides a much better alternative
to bundled libraries in the situations where the primary codebase is
lacking certain features.

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

Re: Issues with yum

2012-02-27 Thread elison.ni...@gmail.com

On Mon, Feb 27 12:13:07 UTC 2012, Josh Boyer jwboyer at gmail.com wrote

>> On Mon, Feb 27, 2012 at 1:44 AM, elison.niven at gmail.com:
>> I forgot to add:
>> 8) Yum cannot use an iso image as a repo without mounting it.
>> Yast in suse allows to directly use iso images as repos.

> You also forgot to add:

> 1) A proposed alternative
I am more than happy to propose alternatives.
Alternative 1 : Use a totally different package management system : apt-get
It is mature enough. I know this is going to be rejected totally even
without consideration.

Alternative 2 :
Make the following changes to yum to make yum better:
1) yum should maintain status of installed packages locally. And it
should not need to fetch repository information when user tries
yum info 
Reason to have this feature : It seems logical to have information
about an installed package locally.

2) yum is currently downloading repository information separately for each user.
It can use the same downloaded repository information for all users.
For example : root did yum install  followed by
Non root user did : yum info .
yum will currently fetch repo information again for the non root user.
Reason to have this feature : Save time, bandwidth.

3) Show progress in "Setting up update process" or "Setting up install process".
At present, users cannot know that is it working or sleeping.
Reason to have this feature : Better user experience

4) Quit on single CTRL-C. Users expect an application to quit on
pressing CTRL-C.
Reason to have this feature : Better user experience

5) Allow to use iso image as a repo.
baseurl=file:///path/to/iso rather than baseurl=file:///path/to/mounted/iso
Reason to have this feature : Small feature but good to have.

> 2)  Patches to fix any of the issues you pointed out
I am not a yum developer at present nor am acquainted with the source.

> 3) Anything constructive at all in your ramblings.
Does the above count now as constructive?

> Seriously, if you want yum replaced with something then you need to
> show up with an
> alternate proposal, how it would work, and people willing to do that
> work.  Without
> those things, this is at best going to be ignored and at works just
> turn into a huge "ME
> TOO" thread that still winds up generating no change.

Your comments on the above proposals?

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

collectd & usrmove (iptables)

2012-02-27 Thread Andrew Elwell

Hi folks,

I've been working on packaging collectd 5.x for work purposes and I
notice there's been no movement on
https://bugzilla.redhat.com/show_bug.cgi?id=743894 since its request.
There were 2 things preventing me from building directly using the
existing spec file - one was autoconf related (since debugged and
patch submitted upstream -
https://github.com/collectd/collectd/pull/35 and the second was that
this patch then didn't work on rawhide - due to broken iptables-devel
since usr move.

I notice that harald already has patches for this, (AFTER doing pretty
much the same thing. Grr)

So

1) is there a master bugzilla ticket to link all usrmove bugs to?

2) [mutterings about maintainer non-responsiveness for collectd
removed as I've just seen him update BZ #797773 ]

3) Given that this is a major version bump (even if there's a
backwards compat step possible) - how likely can I get it into EPEL6
which is my target for work (I can use our internal repo if necessary)

4) given the broken dependency in rawhide, how do I submit an update?


Many thanks

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

[Bug 797864] perl-ORLite-1.96 is available

Please do not reply directly to this email. All additional
comments should be made in the comments box of this bug.


https://bugzilla.redhat.com/show_bug.cgi?id=797864

Petr Pisar  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
 CC|mmasl...@redhat.com,|
   |ppi...@redhat.com   |
 AssignedTo|mmasl...@redhat.com |ppi...@redhat.com

-- 
Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug.
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel

[Bug 796143] perl-PAR-Packer-1.013 is available

Please do not reply directly to this email. All additional
comments should be made in the comments box of this bug.


https://bugzilla.redhat.com/show_bug.cgi?id=796143

Bug 796143 depends on bug 796298, which changed state.

Bug 796298 Summary: Review Request: perl-Tk-EntryCheck - Interface to Tk::Entry 
for controlling its length and content
https://bugzilla.redhat.com/show_bug.cgi?id=796298

   What|Old Value   |New Value

 Status|NEW |ASSIGNED
 Status|ASSIGNED|CLOSED
 Resolution||RAWHIDE

-- 
Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug.
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel

Re: Issues with yum

2012-02-27 Thread Frank Murphy


On 27/02/12 13:52, elison.ni...@gmail.com wrote:


Alternative 2 :
Make the following changes to yum to make yum better:
1) yum should maintain status of installed packages locally. And it
should not need to fetch repository information when user tries
yum info
Reason to have this feature : It seems logical to have information
about an installed package locally.


try:
yumdb --help



2) yum is currently downloading repository information separately for each user.
It can use the same downloaded repository information for all users.
For example : root did yum install  followed by
Non root user did : yum info.
yum will currently fetch repo information again for the non root user.
Reason to have this feature : Save time, bandwidth.


As above.



3) Show progress in "Setting up update process" or "Setting up install process".
At present, users cannot know that is it working or sleeping.
Reason to have this feature : Better user experience


yum --verbose



4) Quit on single CTRL-C. Users expect an application to quit on
pressing CTRL-C.
Reason to have this feature : Better user experience


never used ctrl-c, normally use "killall yum"
if required.

--
Regards,
Frank
"Jack of all, fubars"
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Issues with yum

2012-02-27 Thread Pierre-Yves Chibon

On Mon, 2012-02-27 at 19:22 +0530, elison.ni...@gmail.com wrote:
> 1) yum should maintain status of installed packages locally. And it
> should not need to fetch repository information when user tries
> yum info 
> Reason to have this feature : It seems logical to have information
> about an installed package locally.

yum -C info 
from --help:
  -C, --cacheonly   run entirely from system cache, don't update
cache


> 2) yum is currently downloading repository information separately for
> each user.
> It can use the same downloaded repository information for all users.
> For example : root did yum install  followed by
> Non root user did : yum info .
> yum will currently fetch repo information again for the non root user.
> Reason to have this feature : Save time, bandwidth.

Wrong, information are cached in /var/lib/yum.

> 4) Quit on single CTRL-C. Users expect an application to quit on
> pressing CTRL-C.
> Reason to have this feature : Better user experience 

Do you really want the option to ^c in the middle of an update ?
Allowing the user to end-up with a half-updated system ?

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

Don't be afraid to ask for help

I am sending this because, we have a lot of FTBFS packages which I have
see at least one blog griping about, I accidentally fixed something that
was blocking other work (in the sense that I didn't know that other work
that I wouldn't have to do was waiting for this problem to be solved) and
I fixed something for someone that asked for help in a roundabout way.

We are all not experts in everything and it isn't a problem to ask for
help if you are stuck on something for a package. Someone else on the
devl list (or one of the programming language specific lists) may be able
to easily solve a problem that you could spend hours on without making
a lot of progress.

For those that can help, doing so is a good idea. By removing a blocker
you let someone else do work they can do on Fedora. By showing them
the resolution, they may be able to resolve similar situations when they
see them again, including cases when other developers run across the
problem. It's nice to help your fellow contributors. Fixing things makes
Fedora better for everyone.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

File ORLite-1.96.tar.gz uploaded to lookaside cache by ppisar

A file has been added to the lookaside cache for perl-ORLite:

0d2ce1679e7da739780dc4a22f47317b  ORLite-1.96.tar.gz
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel

Re: Don't be afraid to ask for help

2012-02-27 Thread Jon Ciesla

On Mon, Feb 27, 2012 at 8:05 AM, Bruno Wolff III  wrote:
> I am sending this because, we have a lot of FTBFS packages which I have
> see at least one blog griping about, I accidentally fixed something that
> was blocking other work (in the sense that I didn't know that other work
> that I wouldn't have to do was waiting for this problem to be solved) and
> I fixed something for someone that asked for help in a roundabout way.
>
> We are all not experts in everything and it isn't a problem to ask for
> help if you are stuck on something for a package. Someone else on the
> devl list (or one of the programming language specific lists) may be able
> to easily solve a problem that you could spend hours on without making
> a lot of progress.
>
> For those that can help, doing so is a good idea. By removing a blocker
> you let someone else do work they can do on Fedora. By showing them
> the resolution, they may be able to resolve similar situations when they
> see them again, including cases when other developers run across the
> problem. It's nice to help your fellow contributors. Fixing things makes
> Fedora better for everyone.

Seconded.

And if anyone has gcc47 or libpng FTBFS issues, this is a great place
to ask for help on them.

-J

> --
> 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: collectd & usrmove (iptables)

2012-02-27 Thread Alan Pevec

On Mon, Feb 27, 2012 at 2:54 PM, Andrew Elwell  wrote:
> 2) [mutterings about maintainer non-responsiveness for collectd
> removed as I've just seen him update BZ #797773 ]

Feel free to apply as a co-maintainer :)

> 3) Given that this is a major version bump (even if there's a
> backwards compat step possible) - how likely can I get it into EPEL6
> which is my target for work (I can use our internal repo if necessary)

Ideally, "yum update" should just work for existing collectd 4.10
users, but looking at
http://collectd.org/wiki/index.php/V4_to_v5_migration_guide that might
be a challenge.
Kevin, you last touched el6 branch, do you have collectd 4.10 in
production and if so, could you confirm if automatic migration in
%post is doable?
Or would you prefer to keep 4.10 in el6 ?

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

Re: Issues with yum

On Mon, 2012-02-27 at 19:22 +0530, elison.ni...@gmail.com wrote:
> On Mon, Feb 27 12:13:07 UTC 2012, Josh Boyer jwboyer at gmail.com wrote
> 
> >> On Mon, Feb 27, 2012 at 1:44 AM, elison.niven at gmail.com:
> >> I forgot to add:
> >> 8) Yum cannot use an iso image as a repo without mounting it.
> >> Yast in suse allows to directly use iso images as repos.
> 
> > You also forgot to add:
> 
> > 1) A proposed alternative
> I am more than happy to propose alternatives.
> Alternative 1 : Use a totally different package management system : apt-get
> It is mature enough. I know this is going to be rejected totally even
> without consideration.

 Have you actually used apt on Fedora?
 The main benefit apt on Debian/Ubuntu has is that the repodata is very
different, making repodata updates much faster. It also helps that only
Debian unstable updates as much as Fedora stable.

> Alternative 2 :
> Make the following changes to yum to make yum better:
> 1) yum should maintain status of installed packages locally. And it
> should not need to fetch repository information when user tries
> yum info 
> Reason to have this feature : It seems logical to have information
> about an installed package locally.

 AFAIK the following will only look at the local data:

 yum --nocolor info installed blah

> 2) yum is currently downloading repository information separately for each 
> user.
> It can use the same downloaded repository information for all users.

 Kind of, we used to have non-root users use root's cache ... but that
caused lots of annoying problems.
 I "have a plan" for Fedora 18, that should make things better. We'll
see.

> 3) Show progress in "Setting up update process" or "Setting up install 
> process".
> At present, users cannot know that is it working or sleeping.
> Reason to have this feature : Better user experience

 There is a significant delay between these two pieces:

Setting up Upgrade Process
Resolving Dependencies

...is this when you are doing a full "yum upgrade" or upgrading a
specific package too? How long is the delay?

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

Re: Clarify our position on forks (was: Re: Plan for tomorrow's FESCo meeting (2012-02-27 at 18UTC))

2012-02-27 Thread Matthew Garrett

On Mon, Feb 27, 2012 at 08:14:13AM -0500, Stephen Gallagher wrote:

> Personally, my stance on this is that, provided that the forks are
> properly renamed such that they will not conflict with other forks of
> the same codebase, there's no reason to disallow them. As mentioned by
> Toshio in the ticket, carrying forks provides a much better alternative
> to bundled libraries in the situations where the primary codebase is
> lacking certain features.

There's exactly the same reason to avoid closely-related forks as there 
is to avoid embedded libraries - if you have a security issue you now 
have more places to fix the same bug. The question is whether that cost 
is larger or smaller than the gain from carrying the forked code.

Simple thought experiment: memcpy() has always obviously had destination 
and source the wrong way round. I can easily fix that in a forked glibc, 
but then I need to rebuild the entire stack on top of that to fix up all 
the callers. I think everyone would agree that that was unreasonable. 

There's a continuum here, rather than a bright-line test. Any decision 
we make (other than "accept everything" or "reject everything") is 
going to be somewhat arbitrary.

-- 
Matthew Garrett | mj...@srcf.ucam.org
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Issues with yum

On Mon, Feb 27, 2012 at 14:00:51 +,
  Frank Murphy  wrote:
> On 27/02/12 13:52, elison.ni...@gmail.com wrote:
> >
> >4) Quit on single CTRL-C. Users expect an application to quit on
> >pressing CTRL-C.
> >Reason to have this feature : Better user experience
> 
> never used ctrl-c, normally use "killall yum"
> if required.

Control C works, but it needs to reach a break point. And once you start
actually doing a transaction you don't normally want control C to work
since it will leave your system in a state where manual cleanup is likely
required.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Clarify our position on forks (was: Re: Plan for tomorrow's FESCo meeting (2012-02-27 at 18UTC))

2012-02-27 Thread Miloslav Trmač

On Mon, Feb 27, 2012 at 4:18 PM, Matthew Garrett  wrote:
> On Mon, Feb 27, 2012 at 08:14:13AM -0500, Stephen Gallagher wrote:
>
>> Personally, my stance on this is that, provided that the forks are
>> properly renamed such that they will not conflict with other forks of
>> the same codebase, there's no reason to disallow them. As mentioned by
>> Toshio in the ticket, carrying forks provides a much better alternative
>> to bundled libraries in the situations where the primary codebase is
>> lacking certain features.
>
> There's exactly the same reason to avoid closely-related forks as there
> is to avoid embedded libraries - if you have a security issue you now
> have more places to fix the same bug. The question is whether that cost
> is larger or smaller than the gain from carrying the forked code.

There is one crucial difference: A maintainer of a forked code base
explicitly knows he is maintaining it; a maintainer of a software
package that happens to embed a library may not think about
maintaining the embedded library at all.
   Mirek
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: collectd & usrmove (iptables)

On Mon, 27 Feb 2012 15:59:50 +0100
Alan Pevec  wrote:

> On Mon, Feb 27, 2012 at 2:54 PM, Andrew Elwell
>  wrote:
> > 2) [mutterings about maintainer non-responsiveness for collectd
> > removed as I've just seen him update BZ #797773 ]
> 
> Feel free to apply as a co-maintainer :)
> 
> > 3) Given that this is a major version bump (even if there's a
> > backwards compat step possible) - how likely can I get it into EPEL6
> > which is my target for work (I can use our internal repo if
> > necessary)
> 
> Ideally, "yum update" should just work for existing collectd 4.10
> users, but looking at
> http://collectd.org/wiki/index.php/V4_to_v5_migration_guide that might
> be a challenge.

Yeah, there's a lot of things there that might not go so well in a 4.x
to 5.x update. ;( 

> Kevin, you last touched el6 branch, do you have collectd 4.10 in
> production and if so, could you confirm if automatic migration in
> %post is doable?
> Or would you prefer to keep 4.10 in el6 ?

I'd love to have 5 in el6, but I'm not sure how practical it is. If
someone would like to try and migration setup in %post for the changes,
I'd be happy to test, but I'm not sure it's going to be very easy. 
The rrd changes don't seem like something we want to do to people's
data without their consent. 

What we might want to do is package up a parallel installable
'collectd5' for epel6. This would allow people to migrate to it as
desired. I'm not sure how difficult it will be to parallel install it
however. 

kevin

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

File Marpa-XS-1.004000.tar.gz uploaded to lookaside cache by ppisar

A file has been added to the lookaside cache for perl-Marpa-XS:

a603d2a626da672c8b293b1207f65570  Marpa-XS-1.004000.tar.gz
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel

[perl-Marpa-XS] 1.004000 bump

commit 2bfefc34133e742a3fe8d40ca925fb81d9828239
Author: Petr Písař 
Date:   Mon Feb 27 16:39:05 2012 +0100

1.004000 bump

 .gitignore |1 +
 perl-Marpa-XS.spec |   68 +--
 sources|2 +-
 3 files changed, 41 insertions(+), 30 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index 6e2b82f..c34090b 100644
--- a/.gitignore
+++ b/.gitignore
@@ -1 +1,2 @@
 /Marpa-XS-1.002000.tar.gz
+/Marpa-XS-1.004000.tar.gz
diff --git a/perl-Marpa-XS.spec b/perl-Marpa-XS.spec
index e0cb8c4..928cdc9 100644
--- a/perl-Marpa-XS.spec
+++ b/perl-Marpa-XS.spec
@@ -1,39 +1,52 @@
 Name:   perl-Marpa-XS
-Version:1.002000
-Release:2%{?dist}.1
+Version:1.004000
+Release:1%{?dist}
 Summary:Language grammar parser module for Perl
 License:LGPLv3+
 Group:  Development/Libraries
 URL:http://search.cpan.org/dist/Marpa-XS/
 Source0:
http://www.cpan.org/authors/id/J/JK/JKEGL/Marpa-XS-%{version}.tar.gz
 Patch1: 0001-Require-2.124-Data-Dumper.patch
-BuildRoot:  %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
-BuildRequires:  perl >= 5.10
 BuildRequires:  perl(ExtUtils::CBuilder) >= 0.27
-BuildRequires:  perl(ExtUtils::PkgConfig) >= 1.12
-BuildRequires:  perl(Glib) >= 1.223
-BuildRequires:  perl(Module::Build)
-BuildRequires:  perl(PPI) >= 1.206
-BuildRequires:  perl(Test::More)
+BuildRequires:  perl(Fatal)
+BuildRequires:  perl(File::Spec) >= 0.82
 BuildRequires:  perl-Glib-devel
+BuildRequires:  perl(Glib::Install::Files)
+BuildRequires:  perl(IPC::Cmd)
+BuildRequires:  perl(lib)
+BuildRequires:  perl(Module::Build)
 BuildRequires:  perl(Time::Piece)
+# Run-time
+BuildRequires:  perl >= 4:5.10
+BuildRequires:  perl(Carp) >= 1.08
+BuildRequires:  perl(constant)
+BuildRequires:  perl(Data::Dumper) >= 2.125
+BuildRequires:  perl(ExtUtils::PkgConfig) >= 1.12
+BuildRequires:  perl(Glib) >= 1.223
+# Bareword Glib::Log exported from Glib probably
+BuildRequires:  perl(List::Util) >= 1.21
+BuildRequires:  perl(Scalar::Util) >= 1.21
+# Using ExtUtils::PkgConfig instead of perl(XSLoader)
 BuildRequires:  pkgconfig(glib-2.0)
-BuildRequires:  perl(IPC::Cmd)
-Requires:   perl >= 5.10
-Requires:   perl(ExtUtils::PkgConfig) >= 1.12
-Requires:   perl(Glib) >= 1.223
-Requires:   perl(PPI) >= 1.206
-Requires:   perl(Data::Dumper) >= 2.124
+# Tests
+BuildRequires:  perl(Getopt::Long)
+BuildRequires:  perl(Test::More) >= 0.94
+BuildRequires:  perl(YAML::XS)
+# Optional tests
+BuildRequires:  perl(PPI) >= 1.206
+BuildRequires:  perl(PPI::Document)
+BuildRequires:  perl(Task::Weaken)
+# perl(Test::Weaken) >= 3.004000 not packaged yet
 Requires:   perl(:MODULE_COMPAT_%(eval "`%{__perl} -V:version`"; echo 
$version))
+# AFAIK the PPI is used at test-time only. Do not require it?
+Requires:   perl(PPI) >= 1.206
 Provides:   perl(Marpa::XS::Version) = %{version}
 
-# RPM 4.8 style
-%{?filter_from_requires: %filter_from_requires /perl(Carp)$/d; }
-%{?filter_from_provides: %filter_from_provides /perl(Marpa::XS)$/d; }
 %{?perl_default_filter}
-# RPM 4.9 style
-%global __requires_exclude perl\\(Carp\\)$
-%global __provides_exclude perl\\(Marpa::XS\\)$
+
+# Remove under-specified dependencies
+%global __requires_exclude 
%{?__requires_exclude:%__requires_exclude|}^perl\\(Carp\\)$
+%global __provides_exclude 
%{?__provides_exclude:%__provides_exclude|}^perl\\(Marpa::XS\\)$
   
 
 %description
@@ -55,12 +68,9 @@ grammars and grammars with useless or empty productions.
 
 
 %install
-rm -rf $RPM_BUILD_ROOT
-
 ./Build install destdir=$RPM_BUILD_ROOT create_packlist=0
 find $RPM_BUILD_ROOT -type f -name '*.bs' -size 0 -exec rm -f {} \;
 find $RPM_BUILD_ROOT -depth -type d -exec rmdir {} 2>/dev/null \;
-
 %{_fixperms} $RPM_BUILD_ROOT/*
 
 
@@ -68,12 +78,7 @@ find $RPM_BUILD_ROOT -depth -type d -exec rmdir {} 
2>/dev/null \;
 ./Build test
 
 
-%clean
-rm -rf $RPM_BUILD_ROOT
-
-
 %files
-%defattr(-,root,root,-)
 %{perl_vendorarch}/auto/*
 %{perl_vendorarch}/Marpa*
 %{_mandir}/man3/*
@@ -81,6 +86,11 @@ rm -rf $RPM_BUILD_ROOT
 
 
 %changelog
+* Mon Feb 27 2012 Petr Pisar  - 1.004000-1
+- 1.004000 bump
+- Clean spec file
+- Declare all dependencies
+
 * Mon Feb 13 2012 Lubomir Rintel (GoodData)  
1.002000-2.1
 - BR IPC::Cmd
 
diff --git a/sources b/sources
index e4f7f5b..8d83c3b 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-28a378db21881957df71cacb9a348adb  Marpa-XS-1.002000.tar.gz
+a603d2a626da672c8b293b1207f65570  Marpa-XS-1.004000.tar.gz
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel

Re: collectd & usrmove (iptables)

2012-02-27 Thread Andrew Elwell

> Feel free to apply as a co-maintainer :)

OK I may just do that if these patches look OK.

> What we might want to do is package up a parallel installable
> 'collectd5' for epel6. This would allow people to migrate to it as
> desired. I'm not sure how difficult it will be to parallel install it
> however.

would collectd5 then obsolete collectd on epel6 then?
(not sure how the logistics of paralell (or not) installs work
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: collectd & usrmove (iptables)

On Mon, Feb 27, 2012 at 16:40:10 +0100,
  Andrew Elwell  wrote:
> 
> would collectd5 then obsolete collectd on epel6 then?
> (not sure how the logistics of paralell (or not) installs work

No, that can't be right. If it obsoleted it, you wouldn't be able to
install the older version or do updates with yum. (You'd need to use
rpm and block yum from touching it.)
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: collectd & usrmove (iptables)

On Mon, 27 Feb 2012 16:40:10 +0100
Andrew Elwell  wrote:

> > Feel free to apply as a co-maintainer :)
> 
> OK I may just do that if these patches look OK.
> 
> > What we might want to do is package up a parallel installable
> > 'collectd5' for epel6. This would allow people to migrate to it as
> > desired. I'm not sure how difficult it will be to parallel install
> > it however.
> 
> would collectd5 then obsolete collectd on epel6 then?
> (not sure how the logistics of paralell (or not) installs work

No. 

Users would be able to user either collectd (4.x) or install collectd5
and switch to that. Updates should be available to both streams. 

If at some point down the road upstream stops supporting 4.x and
maintainers are unable to backport all the fixes, at that point they
could look at dropping support for it, or migrating users to 5. 

kevin

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

Re: Issues with yum

2012-02-27 Thread John Reiser

On 02/27/2012 07:29 AM, Bruno Wolff III wrote:
> On Mon, Feb 27, 2012 at 14:00:51 +,
>   Frank Murphy  wrote:
>> On 27/02/12 13:52, elison.ni...@gmail.com wrote:
>>>
>>> 4) Quit on single CTRL-C. Users expect an application to quit on
>>> pressing CTRL-C.
>>> Reason to have this feature : Better user experience
>>
>> never used ctrl-c, normally use "killall yum"
>> if required.
> 
> Control C works, but it needs to reach a break point. And once you start
> actually doing a transaction you don't normally want control C to work
> since it will leave your system in a state where manual cleanup is likely
> required.

That behavior (no response to ^C [SIGINT] within 5 seconds) is a bug.
It's a _transaction_, right?  So either it completes successfully,
or fails with no apparent lasting effects (except log files, delay, etc.)
So yum should: respond immediately on stderr, abort the transaction
(roll back everything to the state before the transaction began),
and terminate with failure status.  Because the original request
is for a transaction, then yum *must* be able to abort and rollback
anyway, to recover from I/O errors [and such errors _do_ happen.]
So, act as if ^C [SIGINT] is an I/O error.

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

Re: Issues with yum

On Mon, Feb 27, 2012 at 08:00:56 -0800,
  John Reiser  wrote:
> 
> That behavior (no response to ^C [SIGINT] within 5 seconds) is a bug.
> It's a _transaction_, right?  So either it completes successfully,
> or fails with no apparent lasting effects (except log files, delay, etc.)
> So yum should: respond immediately on stderr, abort the transaction
> (roll back everything to the state before the transaction began),
> and terminate with failure status.  Because the original request
> is for a transaction, then yum *must* be able to abort and rollback
> anyway, to recover from I/O errors [and such errors _do_ happen.]
> So, act as if ^C [SIGINT] is an I/O error.

I don't believe yum has a way to roll back transactions reliably.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

"master" branch still invokes build in f17-candidate??

2012-02-27 Thread Tom Lane

I'm definitely checked out in the master branch:

[tgl@rh3 master]$ git push
Counting objects: 11, done.
Delta compression using up to 4 threads.
Compressing objects: 100% (6/6), done.
Writing objects: 100% (6/6), 1.13 KiB, done.
Total 6 (delta 3), reused 0 (delta 0)
To ssh://t...@pkgs.fedoraproject.org/postgresql
   d44dce3..2e73ff7  master -> master

but:

[tgl@rh3 master]$ fedpkg build
Building postgresql-9.1.3-1.fc17 for f17-candidate
Created task: 3822862
Task info: http://koji.fedoraproject.org/koji/taskinfo?taskID=3822862
Watching tasks (this may be safely interrupted)...
3822862 build (f17-candidate, 
/postgresql:2e73ff757cfdd20a708fc783e09ff23f3d8644e0): free
3822862 build (f17-candidate, 
/postgresql:2e73ff757cfdd20a708fc783e09ff23f3d8644e0): free -> open 
(x86-02.phx2.fedoraproject.org)

WTF?  Do I need to fix this, and if so how?

regards, tom lane
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Issues with yum

2012-02-27 Thread Panu Matilainen


On 02/27/2012 06:00 PM, John Reiser wrote:

On 02/27/2012 07:29 AM, Bruno Wolff III wrote:

On Mon, Feb 27, 2012 at 14:00:51 +,
   Frank Murphy  wrote:

On 27/02/12 13:52, elison.ni...@gmail.com wrote:


4) Quit on single CTRL-C. Users expect an application to quit on
pressing CTRL-C.
Reason to have this feature : Better user experience


never used ctrl-c, normally use "killall yum"
if required.


Control C works, but it needs to reach a break point. And once you start
actually doing a transaction you don't normally want control C to work
since it will leave your system in a state where manual cleanup is likely
required.


That behavior (no response to ^C [SIGINT] within 5 seconds) is a bug.
It's a _transaction_, right?  So either it completes successfully,
or fails with no apparent lasting effects (except log files, delay, etc.)
So yum should: respond immediately on stderr, abort the transaction
(roll back everything to the state before the transaction began),
and terminate with failure status.  Because the original request
is for a transaction, then yum *must* be able to abort and rollback
anyway, to recover from I/O errors [and such errors _do_ happen.]
So, act as if ^C [SIGINT] is an I/O error.


Rpm's so-called transactions aren't ACID by any stretch of imagination, 
it's just a rather common misunderstanding to expect them to be.


- Panu -

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

Re: Clarify our position on forks (was: Re: Plan for tomorrow's FESCo meeting (2012-02-27 at 18UTC))

2012-02-27 Thread Stephen Gallagher

On Mon, 2012-02-27 at 15:18 +, Matthew Garrett wrote:
> On Mon, Feb 27, 2012 at 08:14:13AM -0500, Stephen Gallagher wrote:
> 
> > Personally, my stance on this is that, provided that the forks are
> > properly renamed such that they will not conflict with other forks of
> > the same codebase, there's no reason to disallow them. As mentioned by
> > Toshio in the ticket, carrying forks provides a much better alternative
> > to bundled libraries in the situations where the primary codebase is
> > lacking certain features.
> 
> There's exactly the same reason to avoid closely-related forks as there 
> is to avoid embedded libraries - if you have a security issue you now 
> have more places to fix the same bug. The question is whether that cost 
> is larger or smaller than the gain from carrying the forked code.
> 

This is true, but it's also much more visible that the bug needs to be
fixed. With a static library, the community as a whole may be unaware
that the library is even in use under the hood.

> Simple thought experiment: memcpy() has always obviously had destination 
> and source the wrong way round. I can easily fix that in a forked glibc, 
> but then I need to rebuild the entire stack on top of that to fix up all 
> the callers. I think everyone would agree that that was unreasonable. 
> 

I think this is a bit of a straw-man. As I mentioned in my earlier email
(maybe I was ambiguous), I think that forks should be permitted so long
as they are parallel-installable. This means that they should not rely
on any of the same headers or use the same shared library name.

With this caveat, it becomes possible to have two parallel glibc stacks
on the system (ridiculous though that may be). You would have to choose
to build against libc-fixedmemcpy.so instead of libc.so.

> There's a continuum here, rather than a bright-line test. Any decision 
> we make (other than "accept everything" or "reject everything") is 
> going to be somewhat arbitrary.

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

Re: Clarify our position on forks (was: Re: Plan for tomorrow's FESCo meeting (2012-02-27 at 18UTC))

2012-02-27 Thread Bill Nottingham

Miloslav Trmač (m...@volny.cz) said: 
> On Mon, Feb 27, 2012 at 4:18 PM, Matthew Garrett  wrote:
> > On Mon, Feb 27, 2012 at 08:14:13AM -0500, Stephen Gallagher wrote:
> >> Personally, my stance on this is that, provided that the forks are
> >> properly renamed such that they will not conflict with other forks of
> >> the same codebase, there's no reason to disallow them. As mentioned by
> >> Toshio in the ticket, carrying forks provides a much better alternative
> >> to bundled libraries in the situations where the primary codebase is
> >> lacking certain features.
> >
> > There's exactly the same reason to avoid closely-related forks as there
> > is to avoid embedded libraries - if you have a security issue you now
> > have more places to fix the same bug. The question is whether that cost
> > is larger or smaller than the gain from carrying the forked code.
> 
> There is one crucial difference: A maintainer of a forked code base
> explicitly knows he is maintaining it; a maintainer of a software
> package that happens to embed a library may not think about
> maintaining the embedded library at all.

Right - we should make it clear to people packaging things like
cinnamon/muffin that it may not be the most healthy long-term alternative, and 
may
cause them pain in the long run. (Hey, name-based metaphors!) But as long as
they're aware of that pain, I don't see why we should deny them the
opportunity, or force them to try and port software away from the fork.

Bill

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

Re: "master" branch still invokes build in f17-candidate??

2012-02-27 Thread Orion Poplawski


On 02/27/2012 09:09 AM, Tom Lane wrote:

I'm definitely checked out in the master branch:

[tgl@rh3 master]$ git push
Counting objects: 11, done.
Delta compression using up to 4 threads.
Compressing objects: 100% (6/6), done.
Writing objects: 100% (6/6), 1.13 KiB, done.
Total 6 (delta 3), reused 0 (delta 0)
To ssh://t...@pkgs.fedoraproject.org/postgresql
d44dce3..2e73ff7  master ->  master

but:

[tgl@rh3 master]$ fedpkg build
Building postgresql-9.1.3-1.fc17 for f17-candidate
Created task: 3822862
Task info: http://koji.fedoraproject.org/koji/taskinfo?taskID=3822862
Watching tasks (this may be safely interrupted)...
3822862 build (f17-candidate, 
/postgresql:2e73ff757cfdd20a708fc783e09ff23f3d8644e0): free
3822862 build (f17-candidate, 
/postgresql:2e73ff757cfdd20a708fc783e09ff23f3d8644e0): free ->  open 
(x86-02.phx2.fedoraproject.org)

WTF?  Do I need to fix this, and if so how?

regards, tom lane


git pull

(to bring in the f17 branch and mark devel as f18)

--
Orion Poplawski
Technical Manager 303-415-9701 x222
NWRA, Boulder Office  FAX: 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

File Tk-ToolBar-0.10.zip uploaded to lookaside cache by iarnell

A file has been added to the lookaside cache for perl-Tk-ToolBar:

c21f0f0320651eac05c5c6071f87df35  Tk-ToolBar-0.10.zip
--
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: "master" branch still invokes build in f17-candidate??

2012-02-27 Thread Tom Lane

Orion Poplawski  writes:
> On 02/27/2012 09:09 AM, Tom Lane wrote:
>> WTF?  Do I need to fix this, and if so how?

> git pull
> (to bring in the f17 branch and mark devel as f18)

Hmm, that package indeed hadn't had f17 git pull'd yet.  (I had scripted
a git pull in all my package directories after the branch, but I think
that it failed in this one due to uncommitted changes.)

So you're saying that fedpkg's behavior depends on the existence of
other, un-checked-out, branches in my local repo?  This seems a
tad ... unreliable.  Not to say surprising.

regards, tom lane
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Issues with yum

2012-02-27 Thread Sandro Mani




On 02/27/2012 04:29 PM, Bruno Wolff III wrote:

On Mon, Feb 27, 2012 at 14:00:51 +,
   Frank Murphy  wrote:

On 27/02/12 13:52, elison.ni...@gmail.com wrote:

4) Quit on single CTRL-C. Users expect an application to quit on
pressing CTRL-C.
Reason to have this feature : Better user experience

never used ctrl-c, normally use "killall yum"
if required.

Control C works, but it needs to reach a break point. And once you start
actually doing a transaction you don't normally want control C to work
since it will leave your system in a state where manual cleanup is likely
required.
One scenario which I often hit is forgetting to change the proxy 
settings in yum.conf and then trying to update. Yum will clearly fail to 
download repodata, but it will keep trying for all mirrors it knows. 
Pressing ctrl+c there almost never works since yum only reacts to the 
signal when it is sent exactely in the instant between when it gave up 
downloading from one mirror due to timeout and beginning attempting to 
download from the next.

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

Re: Building and exporting libgbm from the mesa package

2012-02-27 Thread Adam Jackson

On Fri, 2012-02-24 at 22:29 +0100, Ilyes Gouta wrote:
> Cool! That's what I want to be part of, too :)
> 
> Could these be installed on a Fedora 16?

F16 is still on Mesa 7.11.x because Mesa 8.0 drops the DRI1 drivers.
Which means I don't intend to do any work on F16 beyond keeping up with
the 7.11 branch.

That said, Mesa 8 should build and install fine on F16 (I think, you
might need new libdrm too), and if someone really wanted to adapt the
Mesa packaging for F16 to install what wayland needs I guess that's a
thing they can do.

- ajax

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

[perl-Tk-ToolBar] initial import (rhbz#795605)

commit 8c046a4affe288395d5dfebcfe9f3ce29bad8a91
Author: Iain Arnell 
Date:   Mon Feb 27 09:27:10 2012 -0700

initial import (rhbz#795605)

 .gitignore |1 +
 perl-Tk-ToolBar-no-demos.patch |   14 +
 perl-Tk-ToolBar.spec   |   62 
 sources|1 +
 4 files changed, 78 insertions(+), 0 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index e69de29..9fa83e9 100644
--- a/.gitignore
+++ b/.gitignore
@@ -0,0 +1 @@
+/Tk-ToolBar-0.10.zip
diff --git a/perl-Tk-ToolBar-no-demos.patch b/perl-Tk-ToolBar-no-demos.patch
new file mode 100644
index 000..c36eeef
--- /dev/null
+++ b/perl-Tk-ToolBar-no-demos.patch
@@ -0,0 +1,14 @@
+diff -up Tk-ToolBar-0.10/Makefile.PL.orig Tk-ToolBar-0.10/Makefile.PL
+--- Tk-ToolBar-0.10/Makefile.PL.orig   2010-02-27 16:11:44.0 -0700
 Tk-ToolBar-0.10/Makefile.PL2012-02-20 17:16:18.012721646 -0700
+@@ -23,10 +23,6 @@ WriteMakefile1(
+ },
+ PM   => {
+  'ToolBar.pm'   => 
'$(INST_LIB)/Tk/ToolBar.pm',
+- 'toolbar.pl'   => ($] >= 5.005 ?
+-'$(INST_ARCHLIB)' :
+-'$(INST_LIB)') .
+- '/Tk/demos/widtrib/toolbar.pl',
+  'ToolBar/tkIcons'  => 
'$(INST_LIB)/Tk/ToolBar/tkIcons',
+ },
+);
diff --git a/perl-Tk-ToolBar.spec b/perl-Tk-ToolBar.spec
new file mode 100644
index 000..fe965bf
--- /dev/null
+++ b/perl-Tk-ToolBar.spec
@@ -0,0 +1,62 @@
+Name:   perl-Tk-ToolBar
+Version:0.10
+Release:2%{?dist}
+Summary:Toolbar widget for Perl/Tk
+License:GPL+ or Artistic
+Group:  Development/Libraries
+URL:http://search.cpan.org/dist/Tk-ToolBar/
+Source0:
http://www.cpan.org/authors/id/C/CH/CHORNY/Tk-ToolBar-%{version}.zip
+# don't install toolbar.pl demo - add to docs instead
+Patch0: perl-Tk-ToolBar-no-demos.patch
+BuildArch:  noarch
+BuildRequires:  perl >= 0:5.005
+BuildRequires:  perl(ExtUtils::MakeMaker)
+BuildRequires:  perl(Test)
+BuildRequires:  perl(Test::More)
+BuildRequires:  perl(Test::Pod)
+BuildRequires:  perl(Tk)
+BuildRequires:  perl(Tk::CursorControl)
+Requires:   perl(Tk::CursorControl)
+Requires:   perl(:MODULE_COMPAT_%(eval "`%{__perl} -V:version`"; echo 
$version))
+
+%{?perl_default_filter}
+
+%description
+This module implements a dockable toolbar. It is in the same spirit as the
+"short-cut" toolbars found in most major applications, such as most web
+browsers and text editors (where you find the "back" or "save" and other
+shortcut buttons).
+
+%prep
+%setup -q -n Tk-ToolBar-%{version}
+%patch0 -p1
+
+# strip CRLF
+find -type f -print0 | xargs -0 sed -i 's/\r$//'
+
+%build
+%{__perl} Makefile.PL INSTALLDIRS=vendor
+make %{?_smp_mflags}
+
+%install
+make pure_install DESTDIR=%{buildroot}
+
+find %{buildroot} -type f -name .packlist -exec rm -f {} \;
+find %{buildroot} -depth -type d -exec rmdir {} 2>/dev/null \;
+
+%{_fixperms} %{buildroot}/*
+
+%check
+make test
+
+%files
+%doc Changes README toolbar.pl
+%{perl_vendorlib}/*
+%{_mandir}/man3/*
+
+%changelog
+* Wed Feb 22 2012 Iain Arnell  0.10-2
+- R/BR perl(Tk::CursorControl) now that it's available
+
+* Mon Feb 20 2012 Iain Arnell  0.10-1
+- Specfile autogenerated by cpanspec 1.79.
diff --git a/sources b/sources
index e69de29..dd3d6ba 100644
--- a/sources
+++ b/sources
@@ -0,0 +1 @@
+c21f0f0320651eac05c5c6071f87df35  Tk-ToolBar-0.10.zip
--
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-Tk-ToolBar] additional (build-)dependencies following review

commit c4d60adc617607d1e0093f82913d842b7d44e3a7
Author: Iain Arnell 
Date:   Mon Feb 27 09:29:32 2012 -0700

additional (build-)dependencies following review

 perl-Tk-ToolBar.spec |   12 +++-
 1 files changed, 11 insertions(+), 1 deletions(-)
---
diff --git a/perl-Tk-ToolBar.spec b/perl-Tk-ToolBar.spec
index fe965bf..8b61ddc 100644
--- a/perl-Tk-ToolBar.spec
+++ b/perl-Tk-ToolBar.spec
@@ -1,6 +1,6 @@
 Name:   perl-Tk-ToolBar
 Version:0.10
-Release:2%{?dist}
+Release:3%{?dist}
 Summary:Toolbar widget for Perl/Tk
 License:GPL+ or Artistic
 Group:  Development/Libraries
@@ -10,13 +10,20 @@ Source0:
http://www.cpan.org/authors/id/C/CH/CHORNY/Tk-ToolBar-%{version}
 Patch0: perl-Tk-ToolBar-no-demos.patch
 BuildArch:  noarch
 BuildRequires:  perl >= 0:5.005
+BuildRequires:  perl(base)
+BuildRequires:  perl(Carp)
 BuildRequires:  perl(ExtUtils::MakeMaker)
 BuildRequires:  perl(Test)
 BuildRequires:  perl(Test::More)
 BuildRequires:  perl(Test::Pod)
 BuildRequires:  perl(Tk)
+BuildRequires:  perl(Tk::Balloon)
 BuildRequires:  perl(Tk::CursorControl)
+BuildRequires:  perl(Tk::Frame)
+BuildRequires:  perl(Tk::LabEntry)
+BuildRequires:  perl(Tk::widgets)
 Requires:   perl(Tk::CursorControl)
+Requires:   perl(Tk::LabEntry)
 Requires:   perl(:MODULE_COMPAT_%(eval "`%{__perl} -V:version`"; echo 
$version))
 
 %{?perl_default_filter}
@@ -55,6 +62,9 @@ make test
 %{_mandir}/man3/*
 
 %changelog
+* Mon Feb 27 2012 Iain Arnell  0.10-3
+- additional (build-)dependencies following review
+
 * Wed Feb 22 2012 Iain Arnell  0.10-2
 - R/BR perl(Tk::CursorControl) now that it's available
 
--
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-Tk-ToolBar/f17] (2 commits) ...additional (build-)dependencies following review

Summary of changes:

  8c046a4... initial import (rhbz#795605) (*)
  c4d60ad... additional (build-)dependencies following review (*)

(*) 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: Xaw3d 1.6.1 soname bump

2012-02-27 Thread Adam Jackson

On Sun, 2012-02-26 at 09:53 -0700, Orion Poplawski wrote:
> I'm going to be building Xaw3d 1.6.1 in rawhide shortly.  This includes 
> a soname bump.  The following packages are affected:
> 
> gv
> xdvik
> xfig
> xvkbd
> 
> I will be rebuilding them as well.   If all goes well, we may push to 
> F17 in a couple days.

Hmph.  I'm not entirely sure the soname bump was necessary upstream, I'm
investigating.  Go ahead and rebuild if you want, but Xaw's the kind of
thing that really shouldn't ABI-break anymore.

- ajax


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

Re: Issues with yum

2012-02-27 Thread Genes MailLists

On 02/27/2012 11:44 AM, Sandro Mani wrote:
> 
will leave your system in a state where manual cleanup is likely
>> required.
> One scenario which I often hit is forgetting to change the proxy
> settings in yum.conf and then trying to update. Yum will clearly fail to
> download repodata, but it will keep trying for all mirrors it knows.
> Pressing ctrl+c there almost never works since yum only reacts to the
> signal when it is sent exactely in the instant between when it gave up
> downloading from one mirror due to timeout and beginning attempting to
> download from the next.

 Control-Z
 bg
 kill -9 %1

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

Re: Issues with yum

2012-02-27 Thread drago01

On Mon, Feb 27, 2012 at 5:11 PM, Panu Matilainen
 wrote:
>
>
> Rpm's so-called transactions aren't ACID by any stretch of imagination, it's
> just a rather common misunderstanding to expect them to be.

They should be though (yeah I know way easier said then done).
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

[389-devel] please review ticket #74 - Create schema for DNA plugin - revised Makefile changes

2012-02-27 Thread Mark Reynolds


Revised the Makefile changes(didn't run autogen previously)

 Original Message 
Subject: 	[389-devel] please review ticket #74 - Create schema for DNA 
plugin

Date:   Sat, 25 Feb 2012 16:05:57 -0500
From:   Mark Reynolds 
Reply-To: 	389 Directory server developer discussion. 
<389-de...@lists.fedoraproject.org>
To: 	389 Directory server developer discussion. 
<389-de...@lists.fedoraproject.org>




https://fedorahosted.org/389/ticket/74

https://fedorahosted.org/389/attachment/ticket/74/0001-Ticket-74-Add-schema-for-DNA-plugin-RFE.patch

Thanks,
Mark


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

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

Re: "master" branch still invokes build in f17-candidate??

2012-02-27 Thread Vít Ondruch


Dne 27.2.2012 17:09, Tom Lane napsal(a):

I'm definitely checked out in the master branch:

[tgl@rh3 master]$ git push
Counting objects: 11, done.
Delta compression using up to 4 threads.
Compressing objects: 100% (6/6), done.
Writing objects: 100% (6/6), 1.13 KiB, done.
Total 6 (delta 3), reused 0 (delta 0)
To ssh://t...@pkgs.fedoraproject.org/postgresql
d44dce3..2e73ff7  master ->  master

but:

[tgl@rh3 master]$ fedpkg build
Building postgresql-9.1.3-1.fc17 for f17-candidate
Created task: 3822862
Task info: http://koji.fedoraproject.org/koji/taskinfo?taskID=3822862
Watching tasks (this may be safely interrupted)...
3822862 build (f17-candidate, 
/postgresql:2e73ff757cfdd20a708fc783e09ff23f3d8644e0): free
3822862 build (f17-candidate, 
/postgresql:2e73ff757cfdd20a708fc783e09ff23f3d8644e0): free ->  open 
(x86-02.phx2.fedoraproject.org)

WTF?  Do I need to fix this, and if so how?

regards, tom lane


Have you tried git pull before?

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

Re: Issues with yum

2012-02-27 Thread Richard W.M. Jones

On Mon, Feb 27, 2012 at 11:56:12AM -0500, Genes MailLists wrote:
> On 02/27/2012 11:44 AM, Sandro Mani wrote:
> > 
> will leave your system in a state where manual cleanup is likely
> >> required.
> > One scenario which I often hit is forgetting to change the proxy
> > settings in yum.conf and then trying to update. Yum will clearly fail to
> > download repodata, but it will keep trying for all mirrors it knows.
> > Pressing ctrl+c there almost never works since yum only reacts to the
> > signal when it is sent exactely in the instant between when it gave up
> > downloading from one mirror due to timeout and beginning attempting to
> > download from the next.
> 
>  Control-Z
>  bg
>  kill -9 %1

That's what I frequently have to do.  It *is* a bug in yum (and a very
very long-standing one at that):

https://encrypted.google.com/search?q=yum+ctrl+c
("About 137,000 results")

https://bugzilla.redhat.com/show_bug.cgi?id=519233
(open since 2009-08-25, and that is a regression on an earlier
bug that was opened in 2004)

And yes, I know I haven't submitted the patch yet.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
virt-top is 'top' for virtual machines.  Tiny program with many
powerful monitoring features, net stats, disk stats, logging, etc.
http://et.redhat.com/~rjones/virt-top
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Issues with yum

2012-02-27 Thread elison.ni...@gmail.com

I got many replies to my mail that answer many of my questions. Thanks to all.

>  There is a significant delay between these two pieces:

> Setting up Upgrade Process
> Resolving Dependencies

>...is this when you are doing a full "yum upgrade" or upgrading a
> specific package too? How long is the delay?

I get the delay in doing a full "yum upgrade". Even when not
specifying --verbose, a percentage status similar to downloading
repodata can be used for "Setting up Upgrade/Install Process".

> Control C works, but it needs to reach a break point. And once you start
> actually doing a transaction you don't normally want control C to work
> since it will leave your system in a state where manual cleanup is likely
> required.

> Do you really want the option to ^c in the middle of an update ?
> Allowing the user to end-up with a half-updated system ?
IMHO, Using ctrl-c to quit should work instantaneously when yum is
still fetching repodata or downloading packages.

> yum -C info 
> from --help:
>  -C, --cacheonly   run entirely from system cache, don't update
> cache
If there is a way for yum to know that the package is installed by
looking up its name, it can eliminate the need for even specifying -C
here.

> Kind of, we used to have non-root users use root's cache ... but that
> caused lots of annoying problems.
> I "have a plan" for Fedora 18, that should make things better. We'll
> see.
Looks promising.

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

Re: Issues with yum


On Feb 27, 2012, at 9:08 AM, Bruno Wolff III wrote:

> I don't believe yum has a way to roll back transactions reliably.

http://fedoraproject.org/wiki/Features/SystemRollbackWithBtrfs


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

Re: libglfw orphaned, but it has dependancies still in fedora ? (fwd)

2012-02-27 Thread Paul Wouters


On Mon, 27 Feb 2012, Peter Robinson wrote:


I was asked to look into this. libglfw is retired, but has dependancies
that need it. It was added to Fedora on Nov 16, and retured by notting
on July 25th, but it does not say why.

Can this package be revived? If needed, I'll take it on. This is
apparently the next generation glut, and used by people, and other
fedora packages as the logs below here show,


Yes it can be revived. The process is basically the same as a new
package review process except you reference the original review as
well.


Well, I understand it can be revived. I guess what I was really asking
was why was it orphaned? There might have been a legal reason or
something I'm not aware of.

I located the original review at
https://bugzilla.redhat.com/show_bug.cgi?id=469972

Currently filed bugs against it:

https://bugzilla.redhat.com/show_bug.cgi?id=674380
https://bugzilla.redhat.com/show_bug.cgi?id=754658

Paul (Johnson): Did you want to revive/maintain the package? Or should I
or Chrisopher Olah take it over?

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

Re: libglfw orphaned, but it has dependancies still in fedora ? (fwd)

On Mon, 27 Feb 2012 13:35:47 -0500 (EST)
Paul Wouters  wrote:

> Well, I understand it can be revived. I guess what I was really asking
> was why was it orphaned? There might have been a legal reason or
> something I'm not aware of.

pfj's account was marked inactive (proibibly by not changing
password/ssh key recently). His packages were then marked orphaned and
then later (a month or so) depreciated. 

...snip...

> Paul (Johnson): Did you want to revive/maintain the package? Or
> should I or Chrisopher Olah take it over?

He would need to change his pass/upload a new ssh to reactivate his
account. 

kevin

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

Re: Issues with yum

On Mon, Feb 27, 2012 at 11:24:55 -0700,
  Chris Murphy  wrote:
> 
> On Feb 27, 2012, at 9:08 AM, Bruno Wolff III wrote:
> 
> > I don't believe yum has a way to roll back transactions reliably.
> 
> http://fedoraproject.org/wiki/Features/SystemRollbackWithBtrfs

Yeah being able to rollback file systems will help in some cases. It
isn't a complete answer for the case where you are using the machine
for other things at the time you are doing the updates, since you amy
want to rollback the updates without rolling back other changes (logfiles
newly delivered email messages and the like).
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Issues with yum

2012-02-27 Thread drago01

On Mon, Feb 27, 2012 at 8:18 PM, Bruno Wolff III  wrote:
> On Mon, Feb 27, 2012 at 11:24:55 -0700,
>  Chris Murphy  wrote:
>>
>> On Feb 27, 2012, at 9:08 AM, Bruno Wolff III wrote:
>>
>> > I don't believe yum has a way to roll back transactions reliably.
>>
>> http://fedoraproject.org/wiki/Features/SystemRollbackWithBtrfs
>
> Yeah being able to rollback file systems will help in some cases. It
> isn't a complete answer for the case where you are using the machine
> for other things at the time you are doing the updates, since you amy
> want to rollback the updates without rolling back other changes (logfiles
> newly delivered email messages and the like).

This fixable by taking the system "down" during the update (close all
apps and services) similar like what windows and os x do.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Issues with yum

On Feb 27, 2012, at 12:18 PM, Bruno Wolff III wrote:

> On Mon, Feb 27, 2012 at 11:24:55 -0700,
>  Chris Murphy  wrote:
>> 
>> http://fedoraproject.org/wiki/Features/SystemRollbackWithBtrfs
> 
> Yeah being able to rollback file systems will help in some cases. It
> isn't a complete answer for the case where you are using the machine
> for other things at the time you are doing the updates, since you amy
> want to rollback the updates without rolling back other changes (logfiles
> newly delivered email messages and the like).

It's a very broad rollback implementation. I think an eventual goal for the yum 
plugin, once btrfs is stable, is to make it more flexible. Maybe where /home is 
exempt from rollback.

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

Re: Issues with yum



On Feb 27, 2012, at 12:22 PM, drago01 wrote:
>> 
> 
> This fixable by taking the system "down" during the update (close all
> apps and services) similar like what windows and os x do.

At least on OS X this behavior depends on what's being updated. Most things are 
updated in place.

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

Summary/Minutes from today's FESCo meeting (2012-02-27 at 18UTC)

===
#fedora-meeting: FESCO (2012-02-27)
===


Meeting started by nirik at 18:00:01 UTC. The full logs are available at
http://meetbot.fedoraproject.org/fedora-meeting/2012-02-27/fesco.2012-02-27-18.00.log.html
.



Meeting summary
---
* init process  (nirik, 18:00:01)

* #799 Issues with maintainer responsiveness (clamav)  (nirik, 18:02:30)
  * LINK: https://bugzilla.redhat.com/show_bug.cgi?id=787434#c23 seems
like a good reason not to rush changing things  (mitr, 18:04:32)
  * AGREED: close ticket and ask for reporter to reopen with a real
violation, or with a specific use case (as opposed to a single
configuration item) that is broken by this packaging  (nirik,
18:16:06)

* #802 F17 Features - progress at Feature Freeze  (nirik, 18:16:25)
  * LINK: http://gcc.gnu.org/ml/gcc-patches/2012-02/msg01219.html
(nirik, 18:23:14)
  * ACTION: check on RealHotSpot / NMEnterprisenetworking and close
ticket.  (nirik, 18:24:56)

* #803 Add johannbg to provenpackager explicitly to work on sysv2systemd
  conversion  (nirik, 18:25:32)
  * AGREED: The proposal doesn't pass.  (nirik, 18:44:22)
  * LINK:
https://fedoraproject.org/wiki/User:Johannbg/Features/SysVtoSystemd-F17
(nirik, 18:45:55)

* #806 Request for exception for iptables and ip6tables to provide a
  small init script  (nirik, 18:47:25)
  * AGREED: ask FPC if we can add to systemd guidelines to allow for non
standard service commands to continue to work in a systemd world.
(nirik, 19:05:29)
  * ACTION: nirik to file a FPC ticket asking for them to look into
this.  (nirik, 19:06:22)

* #810 Clarify our position on forks  (nirik, 19:06:51)
  * AGREED: forks are allowed provided they do not conflict or interfere
with other packages. FPC may add additional guidelines to forks as
they see fit"  (nirik, 19:21:38)

* Open Floor  (nirik, 19:21:47)
  * ACTION: limburgher will announce systemd migrations for f17 accepted
until Beta, include link to BZ list and invite PP assistance.
(limburgher, 19:27:57)
  * AGREED: for ibus (ticket 798): treat other cases (e.g. ibus running
in en_US) as bugs, no FESCo decission necessary  (nirik, 19:36:12)
  * ACTION: notting to chair next week.  (nirik, 19:41:13)

Meeting ended at 19:41:22 UTC.




Action Items

* check on RealHotSpot / NMEnterprisenetworking and close ticket.
* nirik to file a FPC ticket asking for them to look into this.
* limburgher will announce systemd migrations for f17 accepted until
  Beta, include link to BZ list and invite PP assistance.
* notting to chair next week.




Action Items, by person
---
* limburgher
  * limburgher will announce systemd migrations for f17 accepted until
Beta, include link to BZ list and invite PP assistance.
* nirik
  * nirik to file a FPC ticket asking for them to look into this.
* notting
  * notting to chair next week.
* **UNASSIGNED**
  * check on RealHotSpot / NMEnterprisenetworking and close ticket.




People Present (lines said)
---
* nirik (135)
* mitr (61)
* mjg59 (51)
* sgallagh (51)
* pjones (36)
* notting (36)
* Viking-Ice (30)
* limburgher (25)
* t8m (19)
* zodbot (10)
* rbergeron (7)
* tibbs (4)
* drago01 (2)
* OzBorne (1)
* mmaslano (0)
--
18:00:01  #startmeeting FESCO (2012-02-27)
18:00:01  Meeting started Mon Feb 27 18:00:01 2012 UTC.  The chair is 
nirik. Information about MeetBot at http://wiki.debian.org/MeetBot.
18:00:01  Useful Commands: #action #agreed #halp #info #idea #link 
#topic.
18:00:01  #meetingname fesco
18:00:01  The meeting name has been set to 'fesco'
18:00:01  #chair notting nirik mjg59 mmaslano t8m pjones sgallagh mitr 
limburgher
18:00:01  #topic init process
18:00:01  Current chairs: limburgher mitr mjg59 mmaslano nirik notting 
pjones sgallagh t8m
18:00:09  who all is around for a fesco meeting?
18:00:12 * notting is here
18:00:13  Hi
18:00:15  I am here this time.
18:00:16 * sgallagh waves
18:00:24  (sorry about last week; was busy saving the world.)
18:00:24  Hello all
18:00:54  Hi
18:01:13  pjones: cool. I like the world...
18:01:50  I'd rather we gave up on this one and started exploring 
other worlds
18:02:25  sgallagh: noted.
18:02:27  ok, shall we go ahead and get started?
18:02:30  #topic #799 Issues with maintainer responsiveness (clamav)
18:02:30  .fesco 799
18:02:32  nirik: #799 (Issues with maintainer responsiveness (clamav)) 
– FESCo - https://fedorahosted.org/fesco/ticket/799
18:02:48 * limburgher here
18:03:05  So it does look like there are actual packaging violations 
at play here, if I read it correctly
18:03:07  so, I don't see any comment from the maintainer... which is 
sad.
18:03:25  sgallagh: also the bullshit watermark is pretty high
18:03:46  pjones: Sorry, ambiguous. Whose bullshit are you referring 
to?
18:03:58  oh wait, was looking at the wrong ticket.  sorry.
18:04:04  sgallagh: If you are referring to comment#9, I

Re: /usrmove? -> about the future

2012-02-27 Thread Jesse Keating


On 2/24/12 12:10 PM, Ville Skyttä wrote:

On 2012-02-23 20:06, Jesse Keating wrote:


Could you help me figure out why path completion with ~/ isn't working
in fedpkg, but with full paths it is?  I assume there is something wrong
in the (contributed) bash completion file.


https://fedorahosted.org/fedpkg/ticket/3


Thanks.  That just further confirms that bash completion syntax is 
strange and complicated, and I know very little about it :)


--
Jesse Keating
Fedora -- Freedom² is a feature!
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: "master" branch still invokes build in f17-candidate??

2012-02-27 Thread Jesse Keating


On 2/27/12 8:37 AM, Tom Lane wrote:

Orion Poplawski  writes:

On 02/27/2012 09:09 AM, Tom Lane wrote:

WTF?  Do I need to fix this, and if so how?



git pull
(to bring in the f17 branch and mark devel as f18)


Hmm, that package indeed hadn't had f17 git pull'd yet.  (I had scripted
a git pull in all my package directories after the branch, but I think
that it failed in this one due to uncommitted changes.)

So you're saying that fedpkg's behavior depends on the existence of
other, un-checked-out, branches in my local repo?  This seems a
tad ... unreliable.  Not to say surprising.

regards, tom lane


I was looking for a way to determine the behavior of the master branch 
(for the sake of dist values) without hitting the network, as that would 
break git's ability to work offline.  The best I could come up with at 
the time this code was written was to check and see what other branches 
existed, and just increment the biggest one by one.  I welcome 
suggestions for better ways to manage this.


--
Jesse Keating
Fedora -- Freedom² is a feature!
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Fedora 18 Development - orphaned & retired packages

2012-02-27 Thread Bill Nottingham

Just a quick note - now that Fedora 18 development is open, we encourage
mantainers who are planning on orphaning or retiring their packages to do so
as early in the process as possible. That gives other maintainers a longer
runway to fix dependencies and possibly pick up maintenance if they so
desire.

Bill
___
devel-announce mailing list
devel-annou...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel-announce
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Provenpackager? Want to help out?

2012-02-27 Thread Jon Ciesla

Hey!

As you're aware, as of F15 we changed our default init system from
sysvinit to systemd.  But we have lots and lots of packages with
daemons, and not all have thus far been migrated.  Some maintainers
haven't responded, some are too busy, some aren't sure how to go about
it.  In many cases, unit files have been posted by helpful individuals
(Thanks Jóhann B. Guðmundsson!) but they're not yet in the packages.

If you're a Provenpackager, check out these two tracking bugs:

https://bugzilla.redhat.com/show_bug.cgi?id=713562
https://bugzilla.redhat.com/show_bug.cgi?id=751869 (mostly this one)

And have a look at:

https://fedoraproject.org/wiki/Packaging:ScriptletSnippets#Systemd

Look through, find something that looks manageable, and volunteer.
Most maintainers will be receptive, I think, but remember, offer/ask
before jumping in.  If they're not responsive, we'll cross that bridge
separately.

Thanks in advance!

-J

-- 
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: Issues with yum

On Mon, 2012-02-27 at 12:25 -0700, Chris Murphy wrote:
> On Feb 27, 2012, at 12:18 PM, Bruno Wolff III wrote:
> 
> > On Mon, Feb 27, 2012 at 11:24:55 -0700,
> >  Chris Murphy  wrote:
> >> 
> >> http://fedoraproject.org/wiki/Features/SystemRollbackWithBtrfs
> > 
> > Yeah being able to rollback file systems will help in some cases. It
> > isn't a complete answer for the case where you are using the machine
> > for other things at the time you are doing the updates, since you amy
> > want to rollback the updates without rolling back other changes (logfiles
> > newly delivered email messages and the like).
> 
> It's a very broad rollback implementation. I think an eventual goal for the 
> yum plugin, once btrfs is stable, is to make it more flexible. Maybe where 
> /home is exempt from rollback.

 It's already usable with LVM and BtrFS, and you can exclude arbitrary
mount points.
 However creating mount points in a way that makes it only "rollback"
those things you want is ... non-trivial.

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

Re: Provenpackager? Want to help out?

2012-02-27 Thread Jóhann B. Guðmundsson


On 02/27/2012 08:42 PM, Jon Ciesla wrote:

Hey!

As you're aware, as of F15 we changed our default init system from
sysvinit to systemd.  But we have lots and lots of packages with
daemons, and not all have thus far been migrated.  Some maintainers
haven't responded, some are too busy, some aren't sure how to go about
it.  In many cases, unit files have been posted by helpful individuals
(Thanks Jóhann B. Guðmundsson!) but they're not yet in the packages.

If you're a Provenpackager, check out these two tracking bugs:

https://bugzilla.redhat.com/show_bug.cgi?id=713562
https://bugzilla.redhat.com/show_bug.cgi?id=751869 (mostly this one)

And have a look at:

https://fedoraproject.org/wiki/Packaging:ScriptletSnippets#Systemd

Look through, find something that looks manageable, and volunteer.
Most maintainers will be receptive, I think, but remember, offer/ask
before jumping in.  If they're not responsive, we'll cross that bridge
separately.


It would be better to walk through this list [1] which was designed 
specifically with PP participation in mind as discussed with Toshio 
during the F16 development cycle.


Just add your name to Proven Packager and flag it passed when you have 
packaged the relevant component.


JBG

1. https://fedoraproject.org/wiki/User:Johannbg/Features/SysVtoSystemd-F17
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Issues with yum

On Mon, 2012-02-27 at 17:45 +, Richard W.M. Jones wrote:
> On Mon, Feb 27, 2012 at 11:56:12AM -0500, Genes MailLists wrote:
> > On 02/27/2012 11:44 AM, Sandro Mani wrote:
> > > 
> > will leave your system in a state where manual cleanup is likely
> > >> required.
> > > One scenario which I often hit is forgetting to change the proxy
> > > settings in yum.conf and then trying to update. Yum will clearly fail to
> > > download repodata, but it will keep trying for all mirrors it knows.
> > > Pressing ctrl+c there almost never works since yum only reacts to the
> > > signal when it is sent exactely in the instant between when it gave up
> > > downloading from one mirror due to timeout and beginning attempting to
> > > download from the next.
> > 
> >  Control-Z
> >  bg
> >  kill -9 %1
> 
> That's what I frequently have to do.  It *is* a bug in yum (and a very
> very long-standing one at that):

 Yeh, much like Fedora repodata is a yum bug.

 There are at least 3 classes of bugs here:

1. rpm overrides C-c handling when you do various rpm operations, so
sometimes what look like "simple" changes mean C-c stops working for
parts of yum.

2. DNS handing in Glibc eats C-c, so various network related things
sometimes mean you have a non-C-c working yum (just like "ping blah"
C-c). AFAIK the only fixes are "don't ever call anything in proc. that
can do a glibc DNS lookup" or "add threads".

3. pycurl/curl/nss also eat C-c ... at least sometimes, and maybe only
when using rpm as well.

...before #3 we generally did the debugging and fixed things as best we
could, and there were a few yum's that people could use where C-c worked
really well (IIRC the latest el5 one was one).
 But after #3 we had a lot of other problems in the same vein, so we
mostly gave up and are waiting for the downloads to not be in proc.
anymore. At which point it should mostly go away (hopefully we can get
rid of #2 as well ... so just need to be really careful about #1
problems).

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

Re: Issues with yum


On Feb 27, 2012, at 1:56 PM, James Antill wrote:

> On Mon, 2012-02-27 at 12:25 -0700, Chris Murphy wrote:
>> 
>> It's a very broad rollback implementation. I think an eventual goal for the 
>> yum plugin, once btrfs is stable, is to make it more flexible. Maybe where 
>> /home is exempt from rollback.
> 
> It's already usable with LVM and BtrFS, and you can exclude arbitrary
> mount points.
> However creating mount points in a way that makes it only "rollback"
> those things you want is ... non-trivial.
> 

Pretty sure it works without a dependency on LVM, rather uses btrfs snapshots.


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

Re: Issues with yum

2012-02-27 Thread John Reiser

On 02/27/2012 08:11 AM, Panu Matilainen wrote:

> Rpm's so-called transactions aren't ACID by any stretch of imagination, it's 
> just a rather common misunderstanding to expect them to be.

OK, so both rpm and yum could do better: at the first mention of 'transaction',
then the documentation (manual page, ...) should specify "not ACID".
There is a database involved, and the word 'transaction' had a decade
of precedence in the database world before rpm was written.

Because rpm does not support ACID transactions, then yum should act
to minimize the adverse impact.  Do not process the packages in
alphabetical order; instead sort the packages topologically: the
ones with no remaining dependencies go first, etc.  Then responding
immediately to ^C [SIGINT] can leave at most one package in an
inconsistent state (assuming no circular dependencies.)
Or, it might be reasonable to finish processing that one package
before not starting the rest of the work.

Additionally, sorting each topological tier by descending size
tends to minimize the number of packages changed before any SIGINT,
so this is an inexpensive way give the interactive user more control.
However, sorting by ascending size tends to enable earlier detection
of systematic problems across packages.  On average for a DVD, sorting
by size (and processing in the same direction) is significantly better
than random by size because the linear caching of most drives (2MB typical)
becomes much more effective on average for adjacent small files
if not all are selected.

-- 

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

Re: Issues with yum

2012-02-27 Thread Richard W.M. Jones

On Mon, Feb 27, 2012 at 04:08:53PM -0500, James Antill wrote:
>  There are at least 3 classes of bugs here:
> 
> 1. rpm overrides C-c handling when you do various rpm operations, so
> sometimes what look like "simple" changes mean C-c stops working for
> parts of yum.
> 
> 2. DNS handing in Glibc eats C-c, so various network related things
> sometimes mean you have a non-C-c working yum (just like "ping blah"
> C-c). AFAIK the only fixes are "don't ever call anything in proc. that
> can do a glibc DNS lookup" or "add threads".
> 
> 3. pycurl/curl/nss also eat C-c ... at least sometimes, and maybe only
> when using rpm as well.
> 
> ...before #3 we generally did the debugging and fixed things as best we
> could, and there were a few yum's that people could use where C-c worked
> really well (IIRC the latest el5 one was one).
>  But after #3 we had a lot of other problems in the same vein, so we
> mostly gave up and are waiting for the downloads to not be in proc.
> anymore. At which point it should mostly go away (hopefully we can get
> rid of #2 as well ... so just need to be really careful about #1
> problems).

How much of this is to do with %post scripts?

IMHO we should reduce and remove the use of scripts as far as possible
over the whole of Fedora.  RPM upstream too, but that may be harder.

We should replace %post scripts with more intelligence in RPM, so it
can, for example, create (and _delete_) user accounts on demand, or
run ldconfig when required.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
virt-df lists disk usage of guests without needing to install any
software inside the virtual machine.  Supports Linux and Windows.
http://et.redhat.com/~rjones/virt-df/
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Issues with yum

On Mon, 2012-02-27 at 21:22 +, Richard W.M. Jones wrote:
> On Mon, Feb 27, 2012 at 04:08:53PM -0500, James Antill wrote:
> >  There are at least 3 classes of bugs here:
>
> How much of this is to do with %post scripts?

 Not much, in that scripts run in a separate process. Everything, in
that while in the middle of a transaction rpm is in control of
everything and thus. anything above rpm can't catch C-c.

> IMHO we should reduce and remove the use of scripts as far as possible
> over the whole of Fedora.  RPM upstream too, but that may be harder.
> 
> We should replace %post scripts with more intelligence in RPM, so it
> can, for example, create (and _delete_) user accounts on demand, or
> run ldconfig when required.

 rpm upstream agrees:

http://lists.rpm.org/pipermail/rpm-maint/2010-June/002812.html
http://www.rpm.org/wiki/Releases/4.9.0#Collections

...any help would be appreciated, I'm sure.

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

Self Introduction

2012-02-27 Thread Bas van den Dikkenberg

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hello,


I am Bas van den Dikkenberg,


I'm just a new comer, for fedora but use linux for many years now and Dutch is 
my first language. I'm Dutch, love Linux. And I've used some versions of Linux: 
Fedora, Ubuntu, Opensuse, and so on. First Linux I used is slackware, so 
classic.

Open Source is the future, and my live.

In personal live i am one of the orginaisers of the linux theme day in the 
neterlands

I want to be a package maintainer for fedora, because I notised like to package 
software and see it as a challenge.
I currently the maintairen for ptop en burp in fedora.

As my first project I want to add burb to fedoraproject.



Contact info

Bas van den Dikkenberg
email: b...@dikkenberg.net
msn: b...@dikkenberg.net
irc: nick basd82
GPG info:
KEY id : C9710323
FIngerprint: B7F2 A4B4 4758 A08D 6594  F776 2270 C518 C971 0323
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.17 (MingW32)

iEYEARECAAYFAk9L+8QACgkQInDFGMlxAyMU5gCeOSAmJSRU6OKhY9zvpvl0OTCf
bFkAni82yRB8kXvr8dJIbUzT6GKk8HAH
=Asc7
-END PGP SIGNATURE-
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Issues with yum

2012-02-27 Thread Emmanuel Seyman

* John Reiser [27/02/2012 22:50] :
>
> OK, so both rpm and yum could do better: at the first mention of 
> 'transaction',
> then the documentation (manual page, ...) should specify "not ACID".

It would help if you filed a bug (preferably with a patch attached).

> There is a database involved, and the word 'transaction' had a decade
> of precedence in the database world before rpm was written.

a) Databases have been around since the late-60s and rpm was written
   in the early-90s.

b) I just did a quick poll around my office and the consensus is that
   'transaction' does not imply 'ACID'.

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

Re: Self Introduction

2012-02-27 Thread Michael Cronenworth


Bas van den Dikkenberg wrote:

As my first project I want to add burb to fedoraproject.


Hello!

To get started you should read the Fedora wiki.

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

Re: "master" branch still invokes build in f17-candidate??

2012-02-27 Thread Kevin Kofler

Jesse Keating wrote:
> I was looking for a way to determine the behavior of the master branch
> (for the sake of dist values) without hitting the network, as that would
> break git's ability to work offline.  The best I could come up with at
> the time this code was written was to check and see what other branches
> existed, and just increment the biggest one by one.  I welcome
> suggestions for better ways to manage this.

What was wrong with the good old dist-rawhide target? Making master always 
use a rawhide target obviates the need of having to check out what n in
fn-candidate to build for.

Kevin Kofler

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

Re: "master" branch still invokes build in f17-candidate??

2012-02-27 Thread Jesse Keating


On 2/27/12 5:53 PM, Kevin Kofler wrote:

Jesse Keating wrote:

I was looking for a way to determine the behavior of the master branch
(for the sake of dist values) without hitting the network, as that would
break git's ability to work offline.  The best I could come up with at
the time this code was written was to check and see what other branches
existed, and just increment the biggest one by one.  I welcome
suggestions for better ways to manage this.


What was wrong with the good old dist-rawhide target? Making master always
use a rawhide target obviates the need of having to check out what n in
fn-candidate to build for.

 Kevin Kofler



Because you still don't know what %{?dist} (and others) should be.  What 
does "dist-rawhide" mean?  Well it could be .fc17, or it could mean 
.fc18, which could make a big difference to conditionals within the spec 
file.


Although the plan was at one time to make use of the dist-rawhide 
target, I'm not sure what derailed that plan, and if possible we should 
go through with that plan, but the above problem remains (it'd just come 
into play less often).


--
Jesse Keating
Fedora -- Freedom² is a feature!
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Provenpackager? Want to help out?

2012-02-27 Thread Sérgio Basto

On Mon, 2012-02-27 at 14:42 -0600, Jon Ciesla wrote: 
> Hey!
> 
> As you're aware, as of F15 we changed our default init system from
> sysvinit to systemd.  But we have lots and lots of packages with
> daemons, and not all have thus far been migrated. 

Hi, 
3 things 
1- I like have help on convert:
vboxweb-service from VirtualBox on rpmfusion.
"http://cvs.rpmfusion.org/viewvc/*checkout*/rpms/VirtualBox-OSE/F-17/vboxweb-service?revision=1.1&root=free";
off-list 

2- how I do ? with systemd : 
service iptables status 
service iptables save 

3 - we got this message on /var/log/message systemd[1]: PID
file /run/sendmail.pid not readable (yet?) after start.

I thing we want read /var/run/sendmail.pid , are we missing /var ? 

Thanks in advance,   
-- 
Sérgio M. B.

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

[perl-Tk-ToolBar/f16] (2 commits) ...additional (build-)dependencies following review

Summary of changes:

  8c046a4... initial import (rhbz#795605) (*)
  c4d60ad... additional (build-)dependencies following review (*)

(*) 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: Issues with yum

On Mon, 2012-02-27 at 15:04 +0100, Pierre-Yves Chibon wrote:

> > 2) yum is currently downloading repository information separately for
> > each user.
> > It can use the same downloaded repository information for all users.
> > For example : root did yum install  followed by
> > Non root user did : yum info .
> > yum will currently fetch repo information again for the non root user.
> > Reason to have this feature : Save time, bandwidth.
> 
> Wrong, information are cached in /var/lib/yum.

I don't know the technical background, but I certainly see the 'user
experience' side of the complaint. Running 'yum info foobar' as user on
my system takes much longer than running it as root. The logical
conclusion is root has access to some cache that my user doesn't.

-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net

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

Re: Don't be afraid to ask for help

On Mon, 2012-02-27 at 08:42 -0600, Jon Ciesla wrote:

> Seconded.
> 
> And if anyone has gcc47 or libpng FTBFS issues, this is a great place
> to ask for help on them.

Well, pulseaudio doesn't currently build, and that's preventing us from
fixing the bug that audio doesn't work in F17. The problem is apparently
in assembler code, though, so fixing it is unlikely to be trivial.

Lennart was working on it, but I've not heard from him on that for a few
days.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net

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

DHCPv6 still broken for F17 alpha

2012-02-27 Thread Paul Wouters



Can we please address the following bug that is almsot two years old.
This bug causes long delays for people enabling IPV6, and causes
Fedora to not get any connectivity on IPv6 only networks, unless you
disable/reconfigure ip6tables manually

https://bugzilla.redhat.com/show_bug.cgi?id=552099
https://bugzilla.redhat.com/show_bug.cgi?id=591630

Please, just add the following rules to the default ip6tables:

-A INPUT -m state --state NEW -m udp -p udp --dport 546 --sport 547 -s 
fe80::/10 -d fe80::/10 -j ACCEPT

It would be REALLY nice if we can get this into F17 this time.

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

Re: Issues with yum

On Mon, 2012-02-27 at 11:24 -0700, Chris Murphy wrote:
> On Feb 27, 2012, at 9:08 AM, Bruno Wolff III wrote:
> 
> > I don't believe yum has a way to roll back transactions reliably.
> 
> http://fedoraproject.org/wiki/Features/SystemRollbackWithBtrfs

Yeah...you might want to remember the context of the conversation.

I don't think you're *seriously* suggesting that hitting ctrl-c while
using yum should result in a btrfs snapshot restoration, are you?
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net

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

Help needed for virtualbox ( Was Provenpackager? Want to help out? )

2012-02-27 Thread Jóhann B. Guðmundsson

On 02/28/2012 02:09 AM, Sérgio Basto wrote:

Hi,
3 things
1- I like have help on convert:
vboxweb-service from VirtualBox on rpmfusion.
"http://cvs.rpmfusion.org/viewvc/*checkout*/rpms/VirtualBox-OSE/F-17/vboxweb-service?revision=1.1&root=free";
off-list

First of all this is for the rpmfusion list and was off topic for this
thread that said...

Here is a vboxweb.service that should work for if not you can read the
systemd man pages and figure out the rest.

### vboxweb.service ###

[Unit]
Description=VirtualBox OSE Web Service
After=network.target

[Service]
Type=forking
PIDFile=/run/vboxweb.pid
ExecStart=/usr/bin/vboxwebsrv --pidfile /run/vboxweb.pid --background

[Install]
WantedBy=multi-user.target

"/etc/sysconfig/$SERVICE" was dropped since...

a) it does not exist in the package spec file

b) upstream wont accept submitted units with /etc/sysconfig/ files which
means those that still want to do this will need start carrying patches
in the form of EnvironmentFile=-/etc/sysconfig/$SERVICE against upstream
units to add this behaviour to units.

Doing so would go against our upstream mantra I believe

c) This is no longer necessary since users really should be following [1]

2- how I do ? with systemd :
service iptables status

systemctl status iptables.service

iptables -L or for the exact initscript command that was used, run
/usr/libexec/iptables.init status

service iptables save

iptables-save

or for the exact initscript command that was used, run
/usr/libexec/iptables.init save

3 - we got this message on /var/log/message systemd[1]: PID
file /run/sendmail.pid not readable (yet?) after start.

What's happening here is that sendmail is daemonizes itself in a racy way.

It exits the original process before the child writes the PID file which
means that when systemd attempts to read the service's PID file, it is
not there yet.

The proper steps to daemonize a process are described and can be found
in [2]

I thing we want read /var/run/sendmail.pid , are we missing /var ?

No we are not however since [3] all path should really be pointing to
/run at this point instead of that symlink...

JBG

1.
http://fedoraproject.org/wiki/Systemd#How_do_I_customize_a_unit_file.2F_add_a_custom_unit_file.3F

2. http://0pointer.de/public/systemd-man/daemon.html
3. http://lists.fedoraproject.org/pipermail/devel/2011-March/150031.html
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

[Test-Announce] livecd-tools testing request

Hey, folks. There's a new livecd-tools build which needs testing:

https://admin.fedoraproject.org/updates/FEDORA-2012-2313/livecd-tools-17.6-1.fc17

It should fix two bugs I came across in Alpha testing:

https://bugzilla.redhat.com/show_bug.cgi?id=796419 - "F17 Alpha RC4 DVD
written to USB with livecd-iso-to-disk --efi does not boot"

Also the bug where, if you write a DVD ISO to USB stick with l-i-t-d,
only the anaconda stuff gets written, not the packages - so the stick is
effectively just a boot.iso, you need another source of packages. That
one I didn't file yet, but it should be fixed.

bcl says it's a fairly big change, so he wants it to get some testing
before applying the change to f15 and f16. please test whatever you
usually use livecd-iso-to-disk for and make sure it didn't break
anything. Ideally we should re-run all the USB validation tests that use
anything from livecd-tools - the 'USB Stick' section on the installation
matrix - and make sure nothing got worse, at least. If it all goes well,
file positive karma. thanks! it'd be great to get this approved and
f15/f16 builds done ASAP so as to help people get Alpha written.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net

___
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: DHCPv6 still broken for F17 alpha

2012-02-27 Thread Dan Williams

On Mon, 2012-02-27 at 23:27 -0500, Paul Wouters wrote:
> Can we please address the following bug that is almsot two years old.
> This bug causes long delays for people enabling IPV6, and causes
> Fedora to not get any connectivity on IPv6 only networks, unless you
> disable/reconfigure ip6tables manually
> 
> https://bugzilla.redhat.com/show_bug.cgi?id=552099
> https://bugzilla.redhat.com/show_bug.cgi?id=591630
> 
> Please, just add the following rules to the default ip6tables:
> 
> -A INPUT -m state --state NEW -m udp -p udp --dport 546 --sport 547 -s 
> fe80::/10 -d fe80::/10 -j ACCEPT
> 
> It would be REALLY nice if we can get this into F17 this time.

At least for NM I suppose I could hack this in, but it would be really
nice to get the IPv6 rules as default somewhere.

Dan

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

Re: Issues with yum