[Test-Announce] 2012-01-23 @ 16:00 UTC - Fedora QA Meeting

2012-01-20 Thread Adam Williamson
# Fedora Quality Assurance Meeting
# Date: 2012-01-23
# Time: 16:00 UTC
(https://fedoraproject.org/wiki/Infrastructure/UTCHowto)
# Location: #fedora-meeting on irc.freenode.net

Greetings testers!

It's meeting time again. We have a bunch of action items from last week
to catch up on, and now Fedora 17 testing is starting to come online,
with RATS runs and the first blocker bug review meeting next Friday.

This is a reminder of the upcoming QA meeting.  Please add any topic
suggestions to the meeting wiki page:
https://fedoraproject.org/wiki/QA/Meetings/20120123

The current proposed agenda is include below.  If no topics beyond the
standard "Previous meeting follow-up" and "AutoQA update" topics are
present or proposed, the meeting will be canceled.

== Proposed Agenda Topics ==
1. Previous meeting follow-up
2. Requested change to BugStatusWorkFlow
3. Upcoming QA events
4. Open floor
-- 
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: [ACTION REQUIRED] Retiring packages for F-17

2012-01-20 Thread Chris Adams
Once upon a time, Kevin Fenzi  said:
> On Fri, 20 Jan 2012 17:15:57 -0600
> Chris Adams  wrote:
> > I would think that making it release based rather than time based
> > should be okay.  If there have been N released shipped without
> > package foo, then foo needs to be re-reviewed (with N being only 1 or
> > 2).
> 
> Possibly, but that info isn't super easy to find. You would need to
> look at the scm-commits list to see when it was retired. 

If it was release-1 or release-2, those are both current and still
getting updates; checking the current trees on a mirror would show if
the package was in either release.
-- 
Chris Adams 
Systems and Network Administrator - HiWAAY Internet Services
I don't speak for anybody but myself - that's enough trouble.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

mdadm: sending ioctl 1261 to a partition!

2012-01-20 Thread Reindl Harald
[root@srv-rhsoft:~]$ dmesg -c
mdadm: sending ioctl 1261 to a partition!
mdadm: sending ioctl 1261 to a partition!

what does the system want to tell me with this each time
"/sbin/mdadm --detail" is called to any raid-array? can
this be ignored or is there a possible bug in recent
kernel/mdadm which should be reported in bugzilla?

mdadm-3.2.3-3

[root@srv-rhsoft:~]$ uname -r
2.6.41.10-2.fc15.x86_64 #1 SMP Thu Jan 19 02:27:37 UTC 2012
___

[root@srv-rhsoft:~]$ cat /proc/mdstat
Personalities : [raid1] [raid10]
md2 : active raid10 sdc3[0] sdd3[3] sda3[4] sdb3[5]
  3875222528 blocks super 1.1 512K chunks 2 near-copies [4/4] []
  bitmap: 0/29 pages [0KB], 65536KB chunk

md1 : active raid10 sdc2[0] sdd2[3] sda2[4] sdb2[5]
  30716928 blocks super 1.1 512K chunks 2 near-copies [4/4] []
  bitmap: 1/1 pages [4KB], 65536KB chunk

md0 : active raid1 sdc1[0] sdd1[3] sda1[4] sdb1[5]
  511988 blocks super 1.0 [4/4] []

unused devices: 
___

[root@srv-rhsoft:~]$ /sbin/mdadm --detail /dev/md1
/dev/md1:
Version : 1.1
  Creation Time : Wed Jun  8 13:10:52 2011
 Raid Level : raid10
 Array Size : 30716928 (29.29 GiB 31.45 GB)
  Used Dev Size : 15358464 (14.65 GiB 15.73 GB)
   Raid Devices : 4
  Total Devices : 4
Persistence : Superblock is persistent

  Intent Bitmap : Internal

Update Time : Sat Jan 21 03:59:22 2012
  State : active
 Active Devices : 4
Working Devices : 4
 Failed Devices : 0
  Spare Devices : 0

 Layout : near=2
 Chunk Size : 512K

   Name : localhost.localdomain:1
   UUID : b7475879:c95d9a47:c5043c02:0c5ae720
 Events : 10563

Number   Major   Minor   RaidDevice State
   0   8   340  active sync   /dev/sdc2
   5   8   181  active sync   /dev/sdb2
   4   822  active sync   /dev/sda2
   3   8   503  active sync   /dev/sdd2



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

Re: An Easy But Serious Screensaver Security Problem In X.Org

2012-01-20 Thread Adam Williamson
On Fri, 2012-01-20 at 10:11 -0500, Neal Becker wrote:
> Hopefully this is being addressed:
> 
> http://www.phoronix.com/scan.php?page=news_item&px=MTA0NTA

It was fixed in Fedora 16 and Rawhide (the only releases it actually
affected) before Phoronix even posted their 'update', they just missed
the update.

https://admin.fedoraproject.org/updates/FEDORA-2012-0712/xkeyboard-config-2.3-3.fc16

Was submitted 2012-01-19 07:08:19 and pushed stable 2012-01-19 22:01:39.
-- 
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: Requesting a change to the BugStatusWorkFlow: Closed/UPSTREAM

2012-01-20 Thread Adam Williamson
On Fri, 2012-01-20 at 09:30 +, Tim Waugh wrote:
> On Fri, 2012-01-20 at 08:39 +0100, Marcela Mašláňová wrote:
> > I use closed/upstream, when I already fixed it in upstream. This bug 
> > should be closed with number of release, where it is fixed or with the 
> > link to the commit. I wouldn't blame this state for not fixing bug in 
> > some projects. I guess instead of closed/upstream we would see more 
> > closed/wontfix|cantfix.
> 
> I use POST for that.
> 
> "A patch or solution believed to resolve this matter has been proposed
> (POSTed) for inclusion in the package or kernel."
> 
> For non-kernel packages I read that as meaning that the patch is in-hand
> upstream, and not yet built in Fedora.

POST is kind of problematic as different groups use it for different
meanings. anaconda use it to mean 'a patch has been sent to
anaconda-devel-list for review', for e.g.
-- 
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: [ACTION REQUIRED] Retiring packages for F-17

2012-01-20 Thread Kevin Fenzi
On Fri, 20 Jan 2012 17:15:57 -0600
Chris Adams  wrote:

> Once upon a time, Kevin Fenzi  said:
> > b) unretirement
> > 
> > This could be pretty massive changes. If something was retired years
> > ago, the entire spec could be very different. Or it could have been
> > yesterday. But making the time variable for re-review makes it much
> > more complex. Last time we looked at this, it was an easy way to
> > tell if something needed re-review. Is it orphaned? then just take
> > it. Is it retired? then re-review it. 
> 
> I would think that making it release based rather than time based
> should be okay.  If there have been N released shipped without
> package foo, then foo needs to be re-reviewed (with N being only 1 or
> 2).

Possibly, but that info isn't super easy to find. You would need to
look at the scm-commits list to see when it was retired. 

kevin


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

Re: [ACTION REQUIRED] Retiring packages for F-17

2012-01-20 Thread Chris Adams
Once upon a time, Kevin Fenzi  said:
> b) unretirement
> 
> This could be pretty massive changes. If something was retired years
> ago, the entire spec could be very different. Or it could have been
> yesterday. But making the time variable for re-review makes it much
> more complex. Last time we looked at this, it was an easy way to tell
> if something needed re-review. Is it orphaned? then just take it. Is it
> retired? then re-review it. 

I would think that making it release based rather than time based should
be okay.  If there have been N released shipped without package foo,
then foo needs to be re-reviewed (with N being only 1 or 2).

-- 
Chris Adams 
Systems and Network Administrator - HiWAAY Internet Services
I don't speak for anybody but myself - that's enough trouble.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: [ACTION REQUIRED] Retiring packages for F-17

2012-01-20 Thread Kevin Fenzi
On Thu, 19 Jan 2012 18:50:50 -0500
Stephen Gallagher  wrote:

> On Thu, 2012-01-19 at 15:30 -0800, Adam Williamson wrote:
> > On Sat, 2012-01-14 at 19:12 +0100, Kevin Kofler wrote:

...snip...

> > >  (And now with my packager hat on, fixing and/or updating a
> > > package in the repo also requires less effort than unretiring a
> > > package which got removed.)
> > 
> > This is an important point: I think it would be much less of a
> > problem to retire packages if the process for unretiring them were
> > not so painful. I _do_ think the unretiring process is an excellent
> > example of unnecessary bureaucracy (as is the renaming process,
> > good lord, what a PITA). Those two things could stand to be trimmed
> > down. At least to 'if you're a provenpackager (or even just a
> > sponsored packager) you can unretire a package without any
> > obstacles'.
> 
> If you file a FESCo ticket to change this policy, this approach would
> have my support. There's no reason that a package rename or
> unretirement should need to go through a full review (although as I
> said in an earlier email, the side-effect here is that such things
> can help curb specrot).

There are two cases here: 

a) rename

The changes involved in a rename are pretty minor. Just usually adding
Obsoletes and Provides and changing the name in the spec file. That
said, it's amazing how easy it is to get this wrong. It happens ALL THE
TIME. ;) having a review to get another pair of eyes was decided to be
the best way to avoid that. I tried (and failed) to get a lower bar for
this. Perhaps current fesco would be interested. 

b) unretirement

This could be pretty massive changes. If something was retired years
ago, the entire spec could be very different. Or it could have been
yesterday. But making the time variable for re-review makes it much
more complex. Last time we looked at this, it was an easy way to tell
if something needed re-review. Is it orphaned? then just take it. Is it
retired? then re-review it. 

kevin





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

Re: Too much bureaucracy or not enough interest? (Re: [ACTION REQUIRED] Retiring packages for F-17)

2012-01-20 Thread Kevin Fenzi
On Tue, 17 Jan 2012 02:20:15 +0100
Kevin Kofler  wrote:

> Kevin Fenzi wrote:
> > We talked about, but never finished implementing a timeout on acl
> > requests.
> > 
> > The way this would work is that maintainer would have some time.. 3
> > weeks or something to reject a acl request. If they did not do so,
> > pkgdb would automatically approve it at the end of the time.
> > This would help in cases where the maintainer is overloaded or not
> > paying attention.
> 
> The question is of course why we need to allow the maintainer to
> reject comaintainership in the first place.

Sure. In an ideal world we never would. 

In the real world it might be that someone is a new maintainer and
wanting to work on a package that is very complex or sensitive without
much background, or someone who the current maintainers know they
differ on philosophy or something that would make working together
difficult, or a maintainer who doesn't get along with upstream and
would cause undue friction, or a maintainer who doesn't communicate
with existing maintainers well, etc. 

kevin


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

Re: Proposal for update to packaging guidelines for icon files

2012-01-20 Thread Björn Persson
Kevin Kofler wrote:
> Adam Williamson wrote:
> > Would it make sense just to put the hicolor directory into filesystem?
> > It seems silly to have every single graphical app in the distro depend
> > on a package simply for the provision of the directory...
> 
> There are also all the subdirectories such as
> /usr/share/icons/hicolor/24x24/apps/.
> 
> And the whole purpose of hicolor-icon-theme is to include those directories
> and the index.theme file.

I count two files and 339 directories (plus one directory and three file under 
/usr/share/doc/).

If that's not enough to justify a separate package, but it's undesirable to 
include these files even on a minimal server, then perhaps they could be added 
to some X package that all graphical programs depend on anyway? Just a 
thought.

Björn Persson


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: Changes coming for CUPS 1.6

2012-01-20 Thread Adam Williamson
On Fri, 2012-01-20 at 09:25 +, Tim Waugh wrote:
> On Thu, 2012-01-19 at 15:50 -0800, Adam Williamson wrote:
> > What a great idea! We could call one of them 'Postscript'...
> 
> Not likely. :-)
> 
> I think the current candidate for the optional vector format is PDF
> 1.4/1.5.

Everything old is new again...
-- 
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: Bundled part of code

2012-01-20 Thread Pavel Alexeev

19.01.2012 17:03, Kevin Kofler wrote:

Pavel Alexeev wrote:

But how I should then deal with licensing in my situation if its mismatch?

There is no mismatch, it's OK to include GPLv2+ code in a GPLv3+ program,
the result is just GPLv3+. (You can also declare "License: GPLv3+ and
GPLv2+", but if everything is getting linked into a single binary, what's
left is really just GPLv3+.)

Thank you very much for clarification!

 Kevin Kofler



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

orphaning blam: RSS feed reader

2012-01-20 Thread Alex Lancaster
Don't currently use, don't have time to maintain it, feel free
to take it (I kept myself as co-maintainer to help out the 
transition):

https://admin.fedoraproject.org/pkgdb/acls/name/blam
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Proposal for update to packaging guidelines for icon files

2012-01-20 Thread Rex Dieter
Adam Williamson wrote:


> Would it make sense just to put the hicolor directory into filesystem?
> It seems silly to have every single graphical app in the distro depend
> on a package simply for the provision of the directory...

I agree.

-- rex

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

Re: PHP 5.4 Fedora 17 feature - STATUS

2012-01-20 Thread Haïkel Guémar
Le 20/01/2012 19:51, Remi Collet a écrit :
> Pending
> ice (owner will take care of it)
>
 Done, thanks for your help on ice-php !

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

Re: Requesting a change to the BugStatusWorkFlow: Closed/UPSTREAM

2012-01-20 Thread Emmanuel Seyman
* Ralf Corsepius [20/01/2012 19:53] :
>
> Surely the bug is open: The product you are supposed to be
> responsible for (A Fedora package) suffers from an unfixed bug,
> documented in bugzilla.

Anyone looking in brc for the unfixed bugs of a package is going to be severely
disappointed. Bugs there will only be a minute of the bugs the upstream
bugtracker contains.

If you're looking for this type of information, using anything but upstream's
bugtracker is a waste of time.

> Surely, there are things to be done.
> 
> - Others might be able to fix it.
> - You can cross check if its fixed in the next upstream release

In both cases, it make more sense to do this work in upstream's context
rather than a Fedora context.

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

Re: PHP 5.4 Fedora 17 feature - STATUS

2012-01-20 Thread Reindl Harald


Am 20.01.2012 19:51, schrieb Remi Collet:
> Le 19/01/2012 19:57, Remi Collet a écrit :
>> Feature page : https://fedoraproject.org/wiki/Features/Php54
> 
> I just finish to rebuild
> 
> php-5.4.0-0.1.RC6.fc17
> 
> And dependant packages :
>
> php-facedetect-1.0.1-6.fc17
> php-idn-1.2c-5.fc17
> php-libvirt-0.4.5-1.fc17
> php-magickwand-1.0.9-2.fc17
> php-pecl-apc-3.1.9-4.svn316786.fc17
> php-pecl-geoip-1.0.8-1.fc17
> php-pecl-mailparse-2.1.5-6.fc17
> php-pecl-imagick-3.1.0-0.1.RC1.fc17
> php-pecl-ssh2-0.11.3-1.fc17
> php-pecl-xdebug-2.2.0-0.1.gitd076740.fc17

thank you for your great work, especially patches for
PHP/MySQL on recent fedora-versions or recent PHP/MySQL
packages on older fedora-releases in your private repo
all over the last years

this is a great base for normal users as also for people
like me building core-services in recent versions for
fedora version-1 on own environments!



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

[perl-Math-Round] Created tag perl-Math-Round-0.06-12.fc17

2012-01-20 Thread Paul Howarth
The lightweight tag 'perl-Math-Round-0.06-12.fc17' was created pointing to:

 528d464... Spec clean-up
--
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: PHP 5.4 Fedora 17 feature - STATUS

2012-01-20 Thread Itamar Reis Peixoto
On Fri, Jan 20, 2012 at 4:51 PM, Remi Collet  wrote:
> Le 19/01/2012 19:57, Remi Collet a écrit :
>> Feature page : https://fedoraproject.org/wiki/Features/Php54
>
> I just finish to rebuild
>
> php-5.4.0-0.1.RC6.fc17
>
> And dependant packages :
>
> cups-1.5.0-28.fc17
> graphviz-2.28.0-13.fc17
> libdigidocpp-0.3.0-13.fc17
> libpuzzle-0.11-12.fc17
> php-facedetect-1.0.1-6.fc17
> php-idn-1.2c-5.fc17
> php-libvirt-0.4.5-1.fc17
> php-magickwand-1.0.9-2.fc17
> php-pecl-apc-3.1.9-4.svn316786.fc17
> php-pecl-gearman-1.0.1-1.fc17
> php-pecl-geoip-1.0.8-1.fc17
> php-pecl-gmagick-1.0.10-0.1.b1.fc17
> php-pecl-igbinary-1.1.2-0.1.git3b8ab7e.fc17
> php-pecl-lzf-1.5.2-9.fc17
> php-pecl-mailparse-2.1.5-6.fc17
> php-pecl-imagick-3.1.0-0.1.RC1.fc17
> php-pecl-memcache-3.0.6-3.fc17
> php-pecl-memcached-2.0.0-0.1.git1736623.fc17
> php-pecl-mongo-1.2.7-1.fc17
> php-pecl-ncurses-1.0.1-5.fc17
> php-pecl-oauth-1.2.2-3.fc17
> php-pecl-radius-1.2.5-13.fc17
> php-pecl-rrd-1.0.5-3.fc17
> php-pecl-selinux-0.3.1-8.fc17
> php-pecl-solr-1.0.2-3.fc17
> php-pecl-sphinx-1.1.0-3.fc17
> php-pecl-ssh2-0.11.3-1.fc17
> php-pecl-xdebug-2.2.0-0.1.gitd076740.fc17
> php-pecl-yaml-1.0.1-6.fc17
> php-shout-0.9.2-10.fc17
> syck-0.61-16.fc17
> uuid-1.6.2-8.fc17
> zarafa-7.0.4-2.fc17
> zorba-2.1.0-3.fc17
>


very nice, thanks for great job and for  fixing php-pecl-ssh2



-- 


Itamar Reis Peixoto
msn, google talk: ita...@ispbrasil.com.br
+55 11 4063 5033 (FIXO SP)
+55 34 9158 9329 (TIM)
+55 34 8806 3989 (OI)
+55 34 3221 8599 (FIXO MG)
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

[perl-Math-Round] Spec clean-up

2012-01-20 Thread Paul Howarth
commit 528d46467717c60ac5c1ccd32752eedeed9ee4b9
Author: Paul Howarth 
Date:   Fri Jan 20 19:11:36 2012 +

Spec clean-up

- BR: perl(Exporter) and perl(POSIX)
- Make %files list more specific
- Don't use macros for commands
- Use DESTDIR rather than PERL_INSTALL_ROOT
- Recode README as UTF-8

 .gitignore |2 +-
 Math-Round-0.06-utf8.patch |   11 +
 perl-Math-Round.spec   |   54 +++
 3 files changed, 41 insertions(+), 26 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index 7a51b5d..d7bb130 100644
--- a/.gitignore
+++ b/.gitignore
@@ -1 +1 @@
-Math-Round-0.06.tar.gz
+/Math-Round-[0-9.]*.tar.gz
diff --git a/Math-Round-0.06-utf8.patch b/Math-Round-0.06-utf8.patch
new file mode 100644
index 000..be1cd2c
--- /dev/null
+++ b/Math-Round-0.06-utf8.patch
@@ -0,0 +1,11 @@
+--- Math-Round-0.06/README
 Math-Round-0.06/README
+@@ -37,7 +37,7 @@
+ make install
+ 
+ 
+-Copyright � 2002 Geoffrey Rommel.  All rights reserved.
++Copyright © 2002 Geoffrey Rommel.  All rights reserved.
+ This program is free software; you can redistribute it and/or modify
+ it under the same terms as Perl itself.
+ 
diff --git a/perl-Math-Round.spec b/perl-Math-Round.spec
index acc8c92..024ea15 100644
--- a/perl-Math-Round.spec
+++ b/perl-Math-Round.spec
@@ -1,61 +1,65 @@
 Name:   perl-Math-Round
-Version:0.06 
-Release:11%{?dist}
+Version:0.06
+Release:12%{?dist}
 Summary:Perl extension for rounding numbers
-
 Group:  Development/Libraries
-License:GPL+ or Artistic
-URL:http://search.cpan.org/dist/Math-Round
-Source0: 
http://search.cpan.org/CPAN/authors/id/G/GR/GROMMEL/Math-Round-%{version}.tar.gz
-BuildRoot:  %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
-
-BuildArch:  noarch 
+License:GPL+ or Artistic
+URL:http://search.cpan.org/dist/Math-Round
+Source0:
http://search.cpan.org/CPAN/authors/id/G/GR/GROMMEL/Math-Round-%{version}.tar.gz
+Patch0: Math-Round-0.06-utf8.patch
+BuildRoot:  %{_tmppath}/%{name}-%{version}-%{release}-root-%(id -nu)
+BuildArch:  noarch
+BuildRequires:  perl(Exporter)
 BuildRequires:  perl(ExtUtils::MakeMaker)
-Requires:  perl(:MODULE_COMPAT_%(eval "`%{__perl} -V:version`"; echo $version))
+BuildRequires:  perl(POSIX)
+Requires:   perl(:MODULE_COMPAT_%(eval "`perl -V:version`"; echo $version))
 
 %description
 Math::Round supplies functions that will round numbers in different ways. The
 functions round and nearest are exported by default; others are available as
 described below. "use ... qw(:all)" exports all functions.
 
-
 %prep
 %setup -q -n Math-Round-%{version}
 
+# Recode docs as UTF-8
+%patch0 -p1
+
 # remove errant execute bits
-find . -type f -exec chmod -x {} ';'
+find . -type f -exec chmod -c -x {} ';'
 
 %build
-%{__perl} Makefile.PL INSTALLDIRS=vendor
+perl Makefile.PL INSTALLDIRS=vendor
 make %{?_smp_mflags}
 
-
 %install
 rm -rf %{buildroot}
-
-make pure_install PERL_INSTALL_ROOT=%{buildroot}
+make pure_install DESTDIR=%{buildroot}
 find %{buildroot} -type f -name .packlist -exec rm -f {} ';'
 find %{buildroot} -type d -depth -exec rmdir {} 2>/dev/null ';'
-
-%{_fixperms} %{buildroot}/*
-
+%{_fixperms} %{buildroot}
 
 %check
 make test
 
-
 %clean
 rm -rf %{buildroot}
 
-
 %files
 %defattr(-,root,root,-)
 %doc Changes README
-%{perl_vendorlib}/*
-%{_mandir}/man3/*.3*
-
+%{perl_vendorlib}/auto/Math/
+%{perl_vendorlib}/Math/
+%{_mandir}/man3/Math::Round.3pm*
 
 %changelog
+* Fri Jan 20 2012 Paul Howarth  - 0.06-12
+- BR: perl(Exporter) and perl(POSIX)
+- Make %%files list more specific
+- Don't use macros for commands
+- Use DESTDIR rather than PERL_INSTALL_ROOT
+- Recode README as UTF-8
+
 * Fri Jan 13 2012 Fedora Release Engineering  
- 0.06-11
 - Rebuilt for https://fedoraproject.org/wiki/Fedora_17_Mass_Rebuild
 
@@ -69,7 +73,7 @@ rm -rf %{buildroot}
 - Rebuilt for https://fedoraproject.org/wiki/Fedora_15_Mass_Rebuild
 
 * Mon Dec 20 2010 Marcela Maslanova  - 0.06-7
-- 661697 rebuild for fixing problems with vendorach/lib
+- Rebuild to fix problems with vendorarch/lib (#661697)
 
 * Mon May 03 2010 Marcela Maslanova  - 0.06-6
 - Mass rebuild with perl-5.12.0
--
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: PHP 5.4 Fedora 17 feature - STATUS

2012-01-20 Thread Remi Collet
Le 19/01/2012 19:57, Remi Collet a écrit :
> Feature page : https://fedoraproject.org/wiki/Features/Php54

I just finish to rebuild

php-5.4.0-0.1.RC6.fc17

And dependant packages :

cups-1.5.0-28.fc17
graphviz-2.28.0-13.fc17
libdigidocpp-0.3.0-13.fc17
libpuzzle-0.11-12.fc17
php-facedetect-1.0.1-6.fc17
php-idn-1.2c-5.fc17
php-libvirt-0.4.5-1.fc17
php-magickwand-1.0.9-2.fc17
php-pecl-apc-3.1.9-4.svn316786.fc17
php-pecl-gearman-1.0.1-1.fc17
php-pecl-geoip-1.0.8-1.fc17
php-pecl-gmagick-1.0.10-0.1.b1.fc17
php-pecl-igbinary-1.1.2-0.1.git3b8ab7e.fc17
php-pecl-lzf-1.5.2-9.fc17
php-pecl-mailparse-2.1.5-6.fc17
php-pecl-imagick-3.1.0-0.1.RC1.fc17
php-pecl-memcache-3.0.6-3.fc17
php-pecl-memcached-2.0.0-0.1.git1736623.fc17
php-pecl-mongo-1.2.7-1.fc17
php-pecl-ncurses-1.0.1-5.fc17
php-pecl-oauth-1.2.2-3.fc17
php-pecl-radius-1.2.5-13.fc17
php-pecl-rrd-1.0.5-3.fc17
php-pecl-selinux-0.3.1-8.fc17
php-pecl-solr-1.0.2-3.fc17
php-pecl-sphinx-1.1.0-3.fc17
php-pecl-ssh2-0.11.3-1.fc17
php-pecl-xdebug-2.2.0-0.1.gitd076740.fc17
php-pecl-yaml-1.0.1-6.fc17
php-shout-0.9.2-10.fc17
syck-0.61-16.fc17
uuid-1.6.2-8.fc17
zarafa-7.0.4-2.fc17
zorba-2.1.0-3.fc17

Pending
ice (owner will take care of it)
maniadrive (tomorrow...)
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Package categorization and distribution construction

2012-01-20 Thread Kevin Kofler
Bill Nottingham wrote:
> These could be separate groups, (i.e., XFCE's 'Office Suite' group may not
> have LibreOffice). So there would be the ability to customize that.

Yes, that makes sense.

Right now, if you enable "Sound and Video", you get Totem forced in (and 
with it, plenty of GNOME dependencies such as Tracker) even if you chose 
only the KDE Plasma Workspaces instead of GNOME.

Kevin Kofler

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

Re: Proposal for update to packaging guidelines for icon files

2012-01-20 Thread Kevin Kofler
Adam Williamson wrote:
> Would it make sense just to put the hicolor directory into filesystem?
> It seems silly to have every single graphical app in the distro depend
> on a package simply for the provision of the directory...

There are also all the subdirectories such as 
/usr/share/icons/hicolor/24x24/apps/.

And the whole purpose of hicolor-icon-theme is to include those directories 
and the index.theme file.

Kevin Kofler

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

[SPAM] Re: Rawhide tree structure

2012-01-20 Thread seth vidal
On Fri, 20 Jan 2012 11:44:54 -0600
Mike Chambers  wrote:

> Did my eyes deceive me, or do the packages now get separated and put
> in their respected dir of their first letter, and not located in one
> dir now?  Did the tree change or is this an error?
> 


This did happen and it is not an error. It was an intentional change
since many web browsers and web servers do not cope well with 17K
entries in a single directory.

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

Re: Rawhide tree structure

2012-01-20 Thread Jason L Tibbitts III
> "MC" == Mike Chambers  writes:

MC> Did my eyes deceive me, or do the packages now get separated and put
MC> in their respected dir of their first letter, and not located in one
MC> dir now?

Yes.

MC> Did the tree change or is this an error?

The tree changed.

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

Re: Requesting a change to the BugStatusWorkFlow: Closed/UPSTREAM

2012-01-20 Thread Ralf Corsepius

On 01/20/2012 05:55 PM, Emmanuel Seyman wrote:

* Ralf Corsepius [20/01/2012 15:25] :


... and why no simply keep these BZs "open" and/or to add a note


Because the bug isn't open.
Surely the bug is open: The product you are supposed to be responsible 
for (A Fedora package) suffers from an unfixed bug, documented in bugzilla.


> There's nothing more to do on it in its present
> state
Surely, there are things to be done.

- Others might be able to fix it.
- You can cross check if its fixed in the next upstream release

> and having it show up in lists of open bugs is
> counter-productive
This logic escapes me - A reporter has reported a bug in your package 
and has are informed you about, so you know about it.


All you are doing by closing is to switch off a semi-automated checklist 
you'd better off checking your package for (== QA) when 
modifying/updating it.


Yes, this means effort, but it should be part of a packager's QA 
routine. People not doing so work careless.



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

Rawhide tree structure

2012-01-20 Thread Mike Chambers
Did my eyes deceive me, or do the packages now get separated and put in
their respected dir of their first letter, and not located in one dir
now?  Did the tree change or is this an error?

-- 
Mike Chambers
Madisonville, KY

"Best little town on Earth!"

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

Re: [389-devel] Please review: Remove redundant code - make a global into a static

2012-01-20 Thread Noriko Hosoi

Rich Megginson wrote:




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

ack.

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

Re: Requesting a change to the BugStatusWorkFlow: Closed/UPSTREAM

2012-01-20 Thread Stephen Gallagher
On Fri, 2012-01-20 at 11:24 -0500, Bill Nottingham wrote:
> Stephen Gallagher (sgall...@redhat.com) said: 
> > Essentially, when closing this bug as UPSTREAM, we are communicating to
> > our users "This will get fixed. Probably. And it will get pulled into
> > Fedora eventually. Probably." Most people, when they can actually be
> > convinced to file a real bug report (even through ABRT), are doing so
> > because they have an issue with the software and want to know when it's
> > fixed.
> > 
> > Closing things upstream requires that the reporters (who already likely
> > had to be coaxed to file a bug in the first place) now also have to
> > manually choose to go and create an account on an unrelated bug tracker
> > if they want to follow along on the resolution of the issue.
> 
> In some cases, this *is* the most appropriate resolution, though. For
> example, I get the occasional RFE, or request for a behavior/appearance
> change, or even for some bugfix that requires rewriting an entire subsystem
> of a package.
>  
> In that case, I will likely open up a bug upstream, and close the Fedora
> bug, because it is really not up to me at all when, or *if*, such a bug gets
> fixed; as a downstream maintainer, I'm not going to put changes of that sort
> into Fedora alone, and upstream may very well decide not to do it.
> 
> For the hypothetical bug I might get of 'port GnuCash to GTK 3', I don't see
> why a simple CLOSED->UPSTREAM is wrong. (Unless you'd prefer
> CLOSED->WONTFIX, as I'm not fixing that myself...)


I'm suggesting that I'd prefer opening the bug upstream, setting this
bug to ASSIGNED and then waiting to see what happens upstream. If
upstream says they won't fix it, close it WONTFIX. If upstream is going
to fix it, leave it open until a Fedora package is available that does
fix it, then you can list it in the Bodhi update.


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: Package categorization and distribution construction

2012-01-20 Thread Richard W.M. Jones
On Thu, Jan 19, 2012 at 11:48:38AM -0500, Przemek Klosowski wrote:
> On 01/19/2012 10:43 AM, Richard W.M. Jones wrote:
> 
> >I wrote a little graphical tool called rpmdepsize (it's in Fedora)
> >which may be useful.  Unfortunately it only works with a single
> >package, eg:
> >
> >   rpmdepsize kernel
> 
> Interesting--but I tried it on my F15 box and it froze. I tried
> 'rpdepsize kernel' and on a very simple (no deps) package 'setup':
> it prints an error:
> 
> (rpmdepsize:18625): LablGTK-CRITICAL **: GSourceFunc: callback
> raised an exception
> 
> and just sits there with gray screen and message 'Loading kernel ...'

It runs 'yum' at this point, so it's likely that yum is
just being slow.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
libguestfs lets you edit virtual machines.  Supports shell scripting,
bindings from many languages.  http://libguestfs.org
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

[389-devel] Please review: Remove redundant code - make a global into a static

2012-01-20 Thread Rich Megginson



From 1ddcc951eec9ede74ae6650de04a921198aec493 Mon Sep 17 00:00:00 2001
From: Rich Megginson 
Date: Fri, 20 Jan 2012 09:52:33 -0700
Subject: [PATCH] Remove redundant code - make a global into a static

Remove redundant code - make a global into a static
---
 ldap/servers/plugins/linkedattrs/fixup_task.c |7 ---
 ldap/servers/plugins/usn/usn.c|2 +-
 2 files changed, 1 insertions(+), 8 deletions(-)

diff --git a/ldap/servers/plugins/linkedattrs/fixup_task.c 
b/ldap/servers/plugins/linkedattrs/fixup_task.c
index b1c29d3..a698a6c 100644
--- a/ldap/servers/plugins/linkedattrs/fixup_task.c
+++ b/ldap/servers/plugins/linkedattrs/fixup_task.c
@@ -77,13 +77,6 @@ linked_attrs_fixup_task_add(Slapi_PBlock *pb, Slapi_Entry *e,
goto out;
}
 
-   /* make sure the plugin is not closed */
-   if(!linked_attrs_is_started()){
-   *returncode = LDAP_OPERATIONS_ERROR;
-   rv = SLAPI_DSE_CALLBACK_ERROR;
-   goto out;
-   }
-
/* get arg(s) */
linkdn = fetch_attr(e, "linkdn", 0);
 
diff --git a/ldap/servers/plugins/usn/usn.c b/ldap/servers/plugins/usn/usn.c
index dbae1d5..faa737c 100644
--- a/ldap/servers/plugins/usn/usn.c
+++ b/ldap/servers/plugins/usn/usn.c
@@ -68,7 +68,7 @@ static int usn_get_attr(Slapi_PBlock *pb, const char* type, 
void *value);
 static int usn_rootdse_search(Slapi_PBlock *pb, Slapi_Entry* e,
 Slapi_Entry* entryAfter, int *returncode, char *returntext, void *arg);
 
-int g_plugin_started = 0;
+static int g_plugin_started = 0;
 /*
  * Register USN plugin
  * Note: USN counter initialization is done in the backend (ldbm_usn_init).
-- 
1.7.1

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

Re: Requesting a change to the BugStatusWorkFlow: Closed/UPSTREAM

2012-01-20 Thread Emmanuel Seyman
* Ralf Corsepius [20/01/2012 15:25] :
>
> ... and why no simply keep these BZs "open" and/or to add a note

Because the bug isn't open. There's nothing more to do on it in its present
state and having it show up in lists of open bugs is counter-productive.

>  This would at least reflect the actual situation in Fedora:
>   Bug is still present.

Just like every open bug in upstream's bugtracker that hasn't been
reported in brc.

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

Re: Requesting a change to the BugStatusWorkFlow: Closed/UPSTREAM

2012-01-20 Thread Frank Murphy

On 20/01/12 16:24, Bill Nottingham wrote:


In that case, I will likely open up a bug upstream, and close the Fedora
bug, because it is really not up to me at all when, or *if*, such a bug gets
fixed; as a downstream maintainer, I'm not going to put changes of that sort
into Fedora alone, and upstream may very well decide not to do it.

For the hypothetical bug I might get of 'port GnuCash to GTK 3', I don't see
why a simple CLOSED->UPSTREAM is wrong. (Unless you'd prefer
CLOSED->WONTFIX, as I'm not fixing that myself...)

Bill


Maybe

Just comment:
//* Standard Comment */
bug #123 some.external.place
has been opened,
Please keep an eye on that bug for progress.
Closing this bug CLOSED->UPSTREAM


I believe you can look at external trackers,
without having to sign up.
I just tested with KDE, which is not installed.




--
Regards,

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

Re: Requesting a change to the BugStatusWorkFlow: Closed/UPSTREAM

2012-01-20 Thread Bill Nottingham
Stephen Gallagher (sgall...@redhat.com) said: 
> Essentially, when closing this bug as UPSTREAM, we are communicating to
> our users "This will get fixed. Probably. And it will get pulled into
> Fedora eventually. Probably." Most people, when they can actually be
> convinced to file a real bug report (even through ABRT), are doing so
> because they have an issue with the software and want to know when it's
> fixed.
> 
> Closing things upstream requires that the reporters (who already likely
> had to be coaxed to file a bug in the first place) now also have to
> manually choose to go and create an account on an unrelated bug tracker
> if they want to follow along on the resolution of the issue.

In some cases, this *is* the most appropriate resolution, though. For
example, I get the occasional RFE, or request for a behavior/appearance
change, or even for some bugfix that requires rewriting an entire subsystem
of a package.
 
In that case, I will likely open up a bug upstream, and close the Fedora
bug, because it is really not up to me at all when, or *if*, such a bug gets
fixed; as a downstream maintainer, I'm not going to put changes of that sort
into Fedora alone, and upstream may very well decide not to do it.

For the hypothetical bug I might get of 'port GnuCash to GTK 3', I don't see
why a simple CLOSED->UPSTREAM is wrong. (Unless you'd prefer
CLOSED->WONTFIX, as I'm not fixing that myself...)

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

Re: [ACTION REQUIRED] Retiring packages for F-17

2012-01-20 Thread Stephen John Smoogen
On 19 January 2012 23:23, David Tardon  wrote:
> On Thu, Jan 19, 2012 at 06:50:50PM -0500, Stephen Gallagher wrote:
>> On Thu, 2012-01-19 at 15:30 -0800, Adam Williamson wrote:
>> > On Sat, 2012-01-14 at 19:12 +0100, Kevin Kofler wrote:
>> > > Kevin Fenzi wrote:
>> > > > Keeping packages around with no maintainers or people handling their
>> > > > bugs is poor for everyone.
>> > >
>> > > Why? If I, as a user, really need a certain piece of software, I'd rather
>> > > have an unmaintained package than none at all! Worst case, I can't use 
>> > > the
>> > > package at all, in which case I'm still no worse off than with no 
>> > > package at
>> > > all!
>> >
>> > I disagree. The existence of a package triggers certain assumptions: the
>> > package will be maintained and keep working. That's the point of there
>> > *being* a package, after all. So if there's a package for something, I
>> > don't check for security updates for that 'something' myself. I figure
>> > the packager is doing that for me.
>> >
>> > So if I wind up with an unmaintained package installed, my security has
>> > just been reduced.
>> >
>>
>> Yes, I agree with this completely. If something is not being maintained
>> in Fedora, it's better to retire it. Then a user who wants that piece of
>> software will have two options:
>> 1) They can build it and maintain it themselves on their own system(s)
>> 2) They can choose to build and maintain it for Fedora by unretiring it.
>
> 3) They can choose another distro that contains the package(s).
>

That is not a bad thing though.
A) The user will be happier because they have support
B) Our developers will be happier because they can focus on what they
want to work on
C) That distros developers will be happier because they have enough
users that want what they are producing.

-- 
Stephen J Smoogen.
"The core skill of innovators is error recovery, not failure avoidance."
Randy Nelson, President of Pixar University.
"Years ago my mother used to say to me,... Elwood, you must be oh
so smart or oh so pleasant. Well, for years I was smart. I
recommend pleasant. You may quote me."  —James Stewart as Elwood P. Dowd
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

[Bug 781402] perl-POE-Component-Client-HTTP-0.944 is available

2012-01-20 Thread bugzilla
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=781402

Petr Šabata  changed:

   What|Removed |Added

 Status|ASSIGNED|CLOSED
   Fixed In Version||perl-POE-Component-Client-H
   ||TTP-0.944-1.fc17
 Resolution||RAWHIDE
Last Closed||2012-01-20 10:51:31

-- 
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: Retire rubygem-mongrel

2012-01-20 Thread Greg Swift
On Fri, Jan 20, 2012 at 09:27, Vít Ondruch  wrote:

> Hi,
>
> If nobody objects, I am going to retire *rubygem-mongrel* and its
> associated gems rubygem-gem_plugin, rubygem-fastthread and
> rubygem-mongrel_cluster.
>
> Mongrel is not maintained anymore [1]. It dos not support Ruby on Rails 3
> available in Fedora, the last supported Ruby on Rails version was 2.3.7.
> There are available more viable Ruby web servers such as rubygem-thin. I
> believe nobody will regret this loss.
>
>
I believe the rubygem-passenger package that is being worked on for
inclusion in fedora still requires rubygem-fastthread.

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

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

[perl-POE-Component-Client-HTTP] 0.944 bump

2012-01-20 Thread Petr Šabata
commit 1d961c830b2c6c7da38cc36d9fc032e14acb7cde
Author: Petr Šabata 
Date:   Fri Jan 20 16:36:06 2012 +0100

0.944 bump

 .gitignore  |1 +
 perl-POE-Component-Client-HTTP.spec |  101 --
 sources |2 +-
 3 files changed, 50 insertions(+), 54 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index 9c63dd0..6844628 100644
--- a/.gitignore
+++ b/.gitignore
@@ -1 +1,2 @@
 POE-Component-Client-HTTP-0.895.tar.gz
+/POE-Component-Client-HTTP-0.944.tar.gz
diff --git a/perl-POE-Component-Client-HTTP.spec 
b/perl-POE-Component-Client-HTTP.spec
index a0ffb21..a15e72e 100644
--- a/perl-POE-Component-Client-HTTP.spec
+++ b/perl-POE-Component-Client-HTTP.spec
@@ -5,58 +5,65 @@
 #   rpmbuild ... --define '_with_network_tests 1' ...
 #   rpmbuild ... --with network_tests ...
 #   define _with_network_tests 1 in your ~/.rpmmacros
-#
-# Note that right now, the only way to run tests locally from a cvs sandbox
-# "make noarch" type scenario is the third one.
 
 Name:   perl-POE-Component-Client-HTTP
-Version:0.895
-Release:5%{?dist}
+Version:0.944
+Release:1%{?dist}
 Summary:A non-blocking/parallel web requests engine for POE
-
 Group:  Development/Libraries
 License:GPL+ or Artistic
 URL:http://search.cpan.org/dist/POE-Component-Client-HTTP
 Source0:
http://search.cpan.org/CPAN/authors/id/R/RC/RCAPUTO/POE-Component-Client-HTTP-%{version}.tar.gz
-BuildRoot:  %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
-
 BuildArch:  noarch
+BuildRequires:  perl(base)
+BuildRequires:  perl(constant)
+BuildRequires:  perl(Carp)
+BuildRequires:  perl(Data::Dumper)
 BuildRequires:  perl(ExtUtils::MakeMaker)
-# Original perl(POE) >= 1.28 rounded to 3 digit precision
-BuildRequires:  perl(POE) >= 1.280
-BuildRequires:  perl(HTTP::Request) >= 1.3
-BuildRequires:  perl(HTTP::Response) >= 1.37
-BuildRequires:  perl(URI) >= 1.24
-# Original perl(POE::Component::Client::Keepalive) >= 0.261 rounded to
+BuildRequires:  perl(HTTP::Headers) >= 5.810
+BuildRequires:  perl(HTTP::Request) >= 5.811
+BuildRequires:  perl(HTTP::Request::Common) >= 5.811
+BuildRequires:  perl(HTTP::Response) >= 5.813
+BuildRequires:  perl(HTTP::Status) >= 5.811
+BuildRequires:  perl(IO::File)
+BuildRequires:  perl(IO::Handle)
+BuildRequires:  perl(IO::Socket::INET)
+BuildRequires:  perl(Net::HTTP::Methods) >= 5.812
+BuildRequires:  perl(POE) >= 1.312
+# Original perl(POE::Component::Client::Keepalive) >= 0.268 rounded to
 # 4 digit precision
-BuildRequires:  perl(POE::Component::Client::Keepalive) >= 0.2610
-
-# tests...
+BuildRequires:  perl(POE::Component::Client::Keepalive) >= 0.2680
+BuildRequires:  perl(POE::Driver::SysRW)
+BuildRequires:  perl(POE::Filter)
+BuildRequires:  perl(POE::Filter::HTTPChunk)
+BuildRequires:  perl(POE::Filter::HTTPHead)
+BuildRequires:  perl(POE::Filter::Line)
+BuildRequires:  perl(POE::Filter::Stackable)
+BuildRequires:  perl(POE::Filter::Stream)
+BuildRequires:  perl(POE::Session)
+BuildRequires:  perl(Scalar::Util)
+BuildRequires:  perl(Socket)
+BuildRequires:  perl(Socket::GetAddrInfo) >= 0.19
+BuildRequires:  perl(URI) >= 1.37
 BuildRequires:  perl(Test::Pod)
 BuildRequires:  perl(Test::Pod::Coverage)
-BuildRequires:  perl(Test::More)
-
-# use base...
-Requires:   perl(POE::Filter), perl(POE::Filter::Stackable)
-# use POE qw{ ... }
-# Original perl(POE::Component::Client::Keepalive) >= 0.261 rounded to
+BuildRequires:  perl(Test::POE::Server::TCP) >= 1.14
+BuildRequires:  perl(Test::More) > 0.96
+BuildRequires:  perl(Time::HiRes)
+Requires:   perl(HTTP::Headers) >= 5.810
+Requires:   perl(HTTP::Request) >= 5.811
+Requires:   perl(HTTP::Request::Common) >= 5.811
+Requires:   perl(HTTP::Response) >= 5.813
+Requires:   perl(HTTP::Status) >= 5.811
+Requires:   perl(Net::HTTP::Methods) >= 5.812
+Requires:   perl(POE) >= 1.312
+# Original perl(POE::Component::Client::Keepalive) >= 0.268 rounded to
 # 4 digit precision
-Requires:   perl(POE::Component::Client::Keepalive) >= 0.2610
-
+Requires:   perl(POE::Component::Client::Keepalive) >= 0.2680
+Requires:   perl(Socket::GetAddrInfo) >= 0.19
+Requires:   perl(URI) >= 1.37
 Requires:  perl(:MODULE_COMPAT_%(eval "`%{__perl} -V:version`"; echo $version))
 
-### auto-added brs!
-BuildRequires:  perl(Test::POE::Server::TCP)
-BuildRequires:  perl(Net::HTTP::Methods) >= 0.02
-
-### auto-added reqs!
-Requires:   perl(HTTP::Request) >= 1.3
-Requires:   perl(HTTP::Response) >= 1.37
-Requires:   perl(Net::HTTP::Methods) >= 0.02
-# Original perl(POE) >= 1.28 rounded to 3 digit precision
-Requires:   perl(POE) >= 1.280
-Requires:   perl(URI) >= 1.24
-
 %{?perl_default_filter}
 
 %description
@@ -64,50 +71,38 @@ POE::Component::Client::HTTP is an HTTP user-agent for POE. 
It lets other
 sessions run while HTTP transactions are being processed, 

File POE-Component-Client-HTTP-0.944.tar.gz uploaded to lookaside cache by psabata

2012-01-20 Thread Petr Šabata
A file has been added to the lookaside cache for perl-POE-Component-Client-HTTP:

79697fe8bf93bcc85ca7b32a94ca5906  POE-Component-Client-HTTP-0.944.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-URI] Created tag perl-URI-1.59-3.fc17

2012-01-20 Thread Paul Howarth
The lightweight tag 'perl-URI-1.59-3.fc17' was created pointing to:

 5d64e5c... Spec clean-up
--
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

Retire rubygem-mongrel

2012-01-20 Thread Vít Ondruch

Hi,

If nobody objects, I am going to retire *rubygem-mongrel* and its 
associated gems rubygem-gem_plugin, rubygem-fastthread and 
rubygem-mongrel_cluster.


Mongrel is not maintained anymore [1]. It dos not support Ruby on Rails 
3 available in Fedora, the last supported Ruby on Rails version was 
2.3.7. There are available more viable Ruby web servers such as 
rubygem-thin. I believe nobody will regret this loss.



Vit




[1] 
https://github.com/evan/mongrel/commit/12a06f658a5645e8ad0fa41c488a6f4a6508d740

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

Re: Requesting a change to the BugStatusWorkFlow: Closed/UPSTREAM

2012-01-20 Thread Matej Cepl

On 20.1.2012 13:20, Stephen Gallagher wrote:

That's a fantastic idea, and probably an ideal solution. Unfortunately,
we're also talking about a minimum of several months' work to get that
in place, just on the engineering side. Not including the deployment
testing period.


Sure. Just to note that the email (and bugs) is old couple of years.


   * BugZappers more or less failed to do any meaningful change in the
state of our Bugzilla (that's to the large part my failure, but that's
how it is) and there is just too few of them,


I'm not sure about what you meant here.


That what you want from package maintainers is basically to do manually 
what I have described above. Which is fine for a component with five 
bugs, but for components like kernel, Firefox, or some of major Gnome 
components with hundreds of open bugs (on the top of other problems 
components infested with ABRT bugs), it means hundreds of hours of work 
(I know what I am talking about, I was doing this work for couple of 
years). We hoped that those hundreds of hours could be provided by 
BugZappers, but it didn't happen.


Also, should developers spend those hours on cleaning bugzilla so that 
you will be happy, or should they work on fixing bugs? It is not popular 
to say, but bugzilla is here not for users, but it is primarily tool for 
developers to organize their work. And frankly, if developers find it 
useless, too bad for anybody else. Just saying.


Matěj
 ... the rest of this thread goes to /dev/null for me, except of 
questions which I can in my opinion usefully comment on.


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

Re: An Easy But Serious Screensaver Security Problem In X.Org

2012-01-20 Thread Stephen Gallagher
On Fri, 2012-01-20 at 10:11 -0500, Neal Becker wrote:
> Hopefully this is being addressed:
> 
> http://www.phoronix.com/scan.php?page=news_item&px=MTA0NTA
> 

https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2012-0064


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-URI] Spec clean-up

2012-01-20 Thread Paul Howarth
commit 5d64e5c56aace0d3158fd4777601c3316f168169
Author: Paul Howarth 
Date:   Fri Jan 20 14:22:57 2012 +

Spec clean-up

- Break build dependency loop by only using perl(Business::ISBN) if we're 
not
  bootstrapping
- BR: perl(Carp) and perl(Exporter)
- Make %files list more explicit
- Use DESTDIR rather than PERL_INSTALL_ROOT
- Use %{_fixperms} macro rather than our own chmod incantation
- Don't use macros for commands

 .gitignore|6 +-
 perl-URI.spec |   53 +++--
 2 files changed, 36 insertions(+), 23 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index 4d3f096..796820b 100644
--- a/.gitignore
+++ b/.gitignore
@@ -1,5 +1 @@
-URI-1.54.tar.gz
-/URI-1.55.tar.gz
-/URI-1.56.tar.gz
-/URI-1.58.tar.gz
-/URI-1.59.tar.gz
+/URI-[0-9.]*.tar.gz
diff --git a/perl-URI.spec b/perl-URI.spec
index 6d9c5e2..e57ad86 100644
--- a/perl-URI.spec
+++ b/perl-URI.spec
@@ -1,54 +1,71 @@
 Name:   perl-URI
 Version:1.59
-Release:2%{?dist}
+Release:3%{?dist}
 Summary:A Perl module implementing URI parsing and manipulation
-
 Group:  Development/Libraries
 License:GPL+ or Artistic
 URL:http://search.cpan.org/dist/URI/
 Source0:http://www.cpan.org/authors/id/G/GA/GAAS/URI-%{version}.tar.gz
-
 BuildArch:  noarch
-BuildRequires:  perl(MIME::Base64)
+BuildRequires:  perl(Carp)
+BuildRequires:  perl(Exporter)
 BuildRequires:  perl(ExtUtils::MakeMaker)
+BuildRequires:  perl(MIME::Base64)
 BuildRequires:  perl(Test::More)
+# Business::ISBN -> Test::Pod -> Pod::Simple -> HTML::Entities (HTML::Parser) 
-> URI
+%if 0%{!?perl_bootstrap:1}
 BuildRequires:  perl(Business::ISBN)
-Requires:   perl(:MODULE_COMPAT_%(eval "`%{__perl} -V:version`"; echo 
$version))
-
+%endif
+Requires:   perl(:MODULE_COMPAT_%(eval "`perl -V:version`"; echo $version))
 
 %description
 This module implements the URI class. Objects of this class represent
 "Uniform Resource Identifier references" as specified in RFC 2396 (and
 updated by RFC 2732).
 
-
 %prep
 %setup -q -n URI-%{version}
 chmod 644 uri-test
 
 %build
-%{__perl} Makefile.PL INSTALLDIRS=perl
+perl Makefile.PL INSTALLDIRS=perl
 make %{?_smp_mflags}
 
-
 %install
-make pure_install PERL_INSTALL_ROOT=$RPM_BUILD_ROOT
-find $RPM_BUILD_ROOT -type f -name .packlist -exec rm -f {} ';'
-find $RPM_BUILD_ROOT -type d -depth -exec rmdir {} 2>/dev/null ';'
-chmod -R u+w $RPM_BUILD_ROOT/*
-
+make pure_install DESTDIR=%{buildroot}
+find %{buildroot} -type f -name .packlist -exec rm -f {} ';'
+find %{buildroot} -type d -depth -exec rmdir {} ';' 2>/dev/null
+%{_fixperms} %{buildroot}
 
 %check
 make test
 
-
 %files
 %doc Changes README uri-test
-%{perl_privlib}/URI*
-%{_mandir}/man3/*.3*
-
+%{perl_privlib}/URI.pm
+%{perl_privlib}/URI/
+%{_mandir}/man3/URI.3pm*
+%{_mandir}/man3/URI::Escape.3pm*
+%{_mandir}/man3/URI::Heuristic.3pm*
+%{_mandir}/man3/URI::QueryParam.3pm*
+%{_mandir}/man3/URI::Split.3pm*
+%{_mandir}/man3/URI::URL.3pm*
+%{_mandir}/man3/URI::WithBase.3pm*
+%{_mandir}/man3/URI::_punycode.3pm*
+%{_mandir}/man3/URI::data.3pm*
+%{_mandir}/man3/URI::file.3pm*
+%{_mandir}/man3/URI::ldap.3pm*
 
 %changelog
+* Fri Jan 20 2012 Paul Howarth  - 1.59-3
+- Break build dependency loop by only using perl(Business::ISBN) if we're not
+  bootstrapping
+- BR: perl(Carp) and perl(Exporter)
+- Make %%files list more explicit
+- Use DESTDIR rather than PERL_INSTALL_ROOT
+- Use %%{_fixperms} macro rather than our own chmod incantation
+- Don't use macros for commands
+
 * Fri Jan 13 2012 Fedora Release Engineering  
- 1.59-2
 - Rebuilt for https://fedoraproject.org/wiki/Fedora_17_Mass_Rebuild
 
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel

An Easy But Serious Screensaver Security Problem In X.Org

2012-01-20 Thread Neal Becker
Hopefully this is being addressed:

http://www.phoronix.com/scan.php?page=news_item&px=MTA0NTA

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

Re: Bad coding practices in Fedora packages

2012-01-20 Thread Denys Vlasenko

On 01/04/2012 10:36 AM, Michal Hlavinka wrote:

On 01/03/2012 05:21 PM, Sérgio Basto wrote:

 I agree, at least for non-gnome users , tracker shouldn't be in

autostart.


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


Thank you Michal for opening a bug. I should learn from you:
less complaining, more work towards achieving actual improvement...

--
vda



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

Re: Requesting a change to the BugStatusWorkFlow: Closed/UPSTREAM

2012-01-20 Thread Stijn Hoop
On Fri, 20 Jan 2012 07:20:20 -0500
Stephen Gallagher  wrote:
> Well, the proposal I'm making is the one that I've been following
> personally in my own projects, which I feel is providing better
> service to my users.

Speaking as a (mostly) user: I agree with this statement. I would rather
have the bugs kept in the open state until a package with the fix is
released, so that I can see when they are fixed in Fedora.

Since I am not a package maintainer, I cannot estimate the impact of
such a policy on the workload of those busy people. I can live with the
current status quo.

Just my EUR 0.02,

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

kexec-tools: sync with the latest upstream release

2012-01-20 Thread Cong Wang

Hi, Neil and others,

I plan to sync kexec-tools and makedumpfile with upstream release,
IOW, move kexec-tools to 2.0.3 and makedumpfile to 1.4.1, for Fedora 17.

Do you have any objections?

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

Re: Requesting a change to the BugStatusWorkFlow: Closed/UPSTREAM

2012-01-20 Thread Ralf Corsepius

On 01/20/2012 02:04 PM, Jaroslav Reznik wrote:

- Original Message -

On Fri, 2012-01-20 at 09:30 +, Tim Waugh wrote:



We already had this discussion, I don't recall exactly - two years ago
and the resolution was similar - rename CLOSED UPSTREAM to HOLD UPSTREAM.
I can try to find it :) As it's usually used this way - bug is reported
to upstream (by reporter, us in case he does not have account or is not
willing to do it), then the bug can bounce between Fedora/upstream (you
know, everyone has to blame other side or sometimes it's not easy to
say who to blame ;-). And the bug is actually not fixed in Fedora until
we receive fix - then it can go to some CLOSED RAWHIDE/NEXTRELEASE state.

The biggest problem here is just - some people misuse this CLOSED UPSTREAM
as we don't care in Fedora. And they would use another CLOSED resolution
to close the bug :)
... and why no simply keep these BZs "open" and/or to add a note 
"Reported upstream" and keep abrt open to receive more of them

(This would at least provide an indicator for the severity of a bug)?

 This would at least reflect the actual situation in Fedora:
  Bug is still present.

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

Re: Requesting a change to the BugStatusWorkFlow: Closed/UPSTREAM

2012-01-20 Thread Stephen Gallagher
On Fri, 2012-01-20 at 08:04 -0500, Jaroslav Reznik wrote:
> - Original Message -
> > On Fri, 2012-01-20 at 09:30 +, Tim Waugh wrote:
> > > On Fri, 2012-01-20 at 08:39 +0100, Marcela Mašláňová wrote:
> > > > I use closed/upstream, when I already fixed it in upstream. This
> > > > bug
> > > > should be closed with number of release, where it is fixed or
> > > > with the
> > > > link to the commit. I wouldn't blame this state for not fixing
> > > > bug in
> > > > some projects. I guess instead of closed/upstream we would see
> > > > more
> > > > closed/wontfix|cantfix.
> > > 
> > > I use POST for that.
> > > 
> > > "A patch or solution believed to resolve this matter has been
> > > proposed
> > > (POSTed) for inclusion in the package or kernel."
> > > 
> > > For non-kernel packages I read that as meaning that the patch is
> > > in-hand
> > > upstream, and not yet built in Fedora.
> > 
> > 
> > That's certainly one reasonable approach to this specific case,
> > provided
> > that we
> > A) Document this interpretation more clearly.
> > B) Comment in the bug that the patch is committed upstream and will
> > be
> > available when the equivalent upstream release arrives.
> 
> We already had this discussion, I don't recall exactly - two years ago
> and the resolution was similar - rename CLOSED UPSTREAM to HOLD UPSTREAM.
> I can try to find it :) As it's usually used this way - bug is reported
> to upstream (by reporter, us in case he does not have account or is not
> willing to do it), then the bug can bounce between Fedora/upstream (you
> know, everyone has to blame other side or sometimes it's not easy to 
> say who to blame ;-). And the bug is actually not fixed in Fedora until
> we receive fix - then it can go to some CLOSED RAWHIDE/NEXTRELEASE state.
> 
> The biggest problem here is just - some people misuse this CLOSED UPSTREAM
> as we don't care in Fedora. And they would use another CLOSED resolution
> to close the bug :)


A bigger problem would be that this claimed approach is not documented
anywhere that anyone could find (short of digging through old mailing
list archives).

It seems to me that what we're looking at here is more of "NEEDSINFO:
upstream" than any kind of CLOSED status. I think the bug should stay
open as ASSIGNED and that the maintainer should be responsible for
occasionally reporting back progress made on the upstream bug.


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: Requesting a change to the BugStatusWorkFlow: Closed/UPSTREAM

2012-01-20 Thread Jaroslav Reznik
- Original Message -
> On Fri, 2012-01-20 at 09:30 +, Tim Waugh wrote:
> > On Fri, 2012-01-20 at 08:39 +0100, Marcela Mašláňová wrote:
> > > I use closed/upstream, when I already fixed it in upstream. This
> > > bug
> > > should be closed with number of release, where it is fixed or
> > > with the
> > > link to the commit. I wouldn't blame this state for not fixing
> > > bug in
> > > some projects. I guess instead of closed/upstream we would see
> > > more
> > > closed/wontfix|cantfix.
> > 
> > I use POST for that.
> > 
> > "A patch or solution believed to resolve this matter has been
> > proposed
> > (POSTed) for inclusion in the package or kernel."
> > 
> > For non-kernel packages I read that as meaning that the patch is
> > in-hand
> > upstream, and not yet built in Fedora.
> 
> 
> That's certainly one reasonable approach to this specific case,
> provided
> that we
> A) Document this interpretation more clearly.
> B) Comment in the bug that the patch is committed upstream and will
> be
> available when the equivalent upstream release arrives.

We already had this discussion, I don't recall exactly - two years ago
and the resolution was similar - rename CLOSED UPSTREAM to HOLD UPSTREAM.
I can try to find it :) As it's usually used this way - bug is reported
to upstream (by reporter, us in case he does not have account or is not
willing to do it), then the bug can bounce between Fedora/upstream (you
know, everyone has to blame other side or sometimes it's not easy to 
say who to blame ;-). And the bug is actually not fixed in Fedora until
we receive fix - then it can go to some CLOSED RAWHIDE/NEXTRELEASE state.

The biggest problem here is just - some people misuse this CLOSED UPSTREAM
as we don't care in Fedora. And they would use another CLOSED resolution
to close the bug :)

R.

> 
> I still think that the more ideal solution though is to keep the bug
> open until a package actually hits Fedora with that fix in it (be it
> an
> updated version or a cherry-picked patch). This way it's clear to the
> user exactly when they can expect a fix.
> 
> Bonus: it tells users when a Bodhi update is available that will
> address
> their issue. This encourages more users to test. I've certainly
> noticed
> a marked increase in bodhi karma activity on my updates that have
> more
> bugs marked as addressed vs. those updates that just pull in a new
> upstream version without any Fedora-specific bugs reported.
> 
> --
> devel mailing list
> devel@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/devel
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Requesting a change to the BugStatusWorkFlow: Closed/UPSTREAM

2012-01-20 Thread Stephen Gallagher
On Fri, 2012-01-20 at 09:30 +, Tim Waugh wrote:
> On Fri, 2012-01-20 at 08:39 +0100, Marcela Mašláňová wrote:
> > I use closed/upstream, when I already fixed it in upstream. This bug 
> > should be closed with number of release, where it is fixed or with the 
> > link to the commit. I wouldn't blame this state for not fixing bug in 
> > some projects. I guess instead of closed/upstream we would see more 
> > closed/wontfix|cantfix.
> 
> I use POST for that.
> 
> "A patch or solution believed to resolve this matter has been proposed
> (POSTed) for inclusion in the package or kernel."
> 
> For non-kernel packages I read that as meaning that the patch is in-hand
> upstream, and not yet built in Fedora.


That's certainly one reasonable approach to this specific case, provided
that we
A) Document this interpretation more clearly.
B) Comment in the bug that the patch is committed upstream and will be
available when the equivalent upstream release arrives.


I still think that the more ideal solution though is to keep the bug
open until a package actually hits Fedora with that fix in it (be it an
updated version or a cherry-picked patch). This way it's clear to the
user exactly when they can expect a fix.

Bonus: it tells users when a Bodhi update is available that will address
their issue. This encourages more users to test. I've certainly noticed
a marked increase in bodhi karma activity on my updates that have more
bugs marked as addressed vs. those updates that just pull in a new
upstream version without any Fedora-specific bugs reported.


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: Requesting a change to the BugStatusWorkFlow: Closed/UPSTREAM

2012-01-20 Thread Stephen Gallagher
On Fri, 2012-01-20 at 09:17 +0100, Matej Cepl wrote:
> On 20.1.2012 00:31, Stephen Gallagher wrote:
> > Currently, the official bug lifecycle includes the following phrase:
> > "The resolution UPSTREAM can be used by maintainers to denote a bug that
> > they expect to be fixed by upstream development and naturally rolled
> > back into Fedora as part of the update process. Ideally, a comment
> > should be added with a link to the upstream bug report."
> >
> > I've seen quite a few bugs lately closed with this resolution (mostly in
> > the Evolution and GNOME projects for me personally). It seems to me that
> > this is terribly useless in terms of informing users when their bugs are
> > fixed.
> 
> You are completely right, except:
> 
>   * since I wrote 
> http://article.gmane.org/gmane.linux.redhat.fedora.devel/79936/ nobody 
> did anything on numerous Bugzilla bugs like 
> https://bugzilla.mozilla.org/show_bug.cgi?id=123130, 
> https://bugzilla.mozilla.org/show_bug.cgi?id=380493 ... if you know 
> about any Perl hacker who would be willing to help, these bugs could be 
> a good place to start,

That's a fantastic idea, and probably an ideal solution. Unfortunately,
we're also talking about a minimum of several months' work to get that
in place, just on the engineering side. Not including the deployment
testing period.

>   * BugZappers more or less failed to do any meaningful change in the 
> state of our Bugzilla (that's to the large part my failure, but that's 
> how it is) and there is just too few of them,

I'm not sure about what you meant here.

>   * this really sounds like proverbial "somebody else should do 
> something" ...

Well, the proposal I'm making is the one that I've been following
personally in my own projects, which I feel is providing better service
to my users. I agree that if we had the solution you propose above
available, that would meet (or exceed) the same need.


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

rawhide report: 20120120 changes

2012-01-20 Thread Rawhide Report
Compose started at Fri Jan 20 08:15:13 UTC 2012

Broken deps for x86_64
--
[amsn]
amsn-0.98.4-4.fc16.x86_64 requires libgupnp-igd-1.0.so.3()(64bit)
[anerley]
1:anerley-0.3.0-7.fc17.i686 requires libcogl.so.6
1:anerley-0.3.0-7.fc17.x86_64 requires libcogl.so.6()(64bit)
[aunit]
aunit-2010-3.fc16.i686 requires libgnat-4.6.so
aunit-2010-3.fc16.x86_64 requires libgnat-4.6.so()(64bit)
[blender]
1:blender-2.61-1.fc17.x86_64 requires 
libOpenCOLLADAStreamWriter.so.svn863()(64bit)
1:blender-2.61-1.fc17.x86_64 requires 
libOpenCOLLADASaxFrameworkLoader.so.svn863()(64bit)
1:blender-2.61-1.fc17.x86_64 requires 
libOpenCOLLADAFramework.so.svn863()(64bit)
1:blender-2.61-1.fc17.x86_64 requires 
libOpenCOLLADABaseUtils.so.svn863()(64bit)
1:blender-2.61-1.fc17.x86_64 requires libMathMLSolver.so.svn863()(64bit)
1:blender-2.61-1.fc17.x86_64 requires 
libGeneratedSaxParser.so.svn863()(64bit)
1:blenderplayer-2.61-1.fc17.x86_64 requires 
libOpenCOLLADAStreamWriter.so.svn863()(64bit)
1:blenderplayer-2.61-1.fc17.x86_64 requires 
libOpenCOLLADASaxFrameworkLoader.so.svn863()(64bit)
1:blenderplayer-2.61-1.fc17.x86_64 requires 
libOpenCOLLADAFramework.so.svn863()(64bit)
1:blenderplayer-2.61-1.fc17.x86_64 requires 
libOpenCOLLADABaseUtils.so.svn863()(64bit)
1:blenderplayer-2.61-1.fc17.x86_64 requires 
libMathMLSolver.so.svn863()(64bit)
1:blenderplayer-2.61-1.fc17.x86_64 requires 
libGeneratedSaxParser.so.svn863()(64bit)
[clutter-gtk010]
clutter-gtk010-0.11.4-3.fc17.i686 requires libcogl.so.6
clutter-gtk010-0.11.4-3.fc17.x86_64 requires libcogl.so.6()(64bit)
[comoonics-cdsl-py]
comoonics-cdsl-py-0.2-19.noarch requires comoonics-base-py
[comoonics-cluster-py]
comoonics-cluster-py-0.1-25.noarch requires comoonics-base-py
[compat-gcc-34]
compat-gcc-34-c++-3.4.6-23.fc17.x86_64 requires libstdc++ < 0:4.7.0
[compiz]

compiz-0.9.5.92.1-0.1.gite676f1b12eb8db3a76978eed5bfc7c2cf9a0b6ce.fc17.i686 
requires libboost_serialization-mt.so.1.47.0

compiz-0.9.5.92.1-0.1.gite676f1b12eb8db3a76978eed5bfc7c2cf9a0b6ce.fc17.x86_64 
requires libboost_serialization-mt.so.1.47.0()(64bit)

compiz-gtk-0.9.5.92.1-0.1.gite676f1b12eb8db3a76978eed5bfc7c2cf9a0b6ce.fc17.x86_64
 requires libboost_serialization-mt.so.1.47.0()(64bit)

compiz-kde-0.9.5.92.1-0.1.gite676f1b12eb8db3a76978eed5bfc7c2cf9a0b6ce.fc17.x86_64
 requires libboost_serialization-mt.so.1.47.0()(64bit)
[compiz-fusion-extras]
compiz-fusion-extras-0.9.5.92-1.fc17.x86_64 requires 
libboost_serialization-mt.so.1.47.0()(64bit)
[compiz-fusion-unsupported]
compiz-fusion-unsupported-0.9.4-6.fc17.x86_64 requires 
libboost_serialization-mt.so.1.47.0()(64bit)
[compiz-plugins-main]
compiz-plugins-main-0.9.5.92-1.fc17.x86_64 requires 
libboost_serialization-mt.so.1.47.0()(64bit)
[contextkit]
contextkit-0.5.15-2.fc15.i686 requires libcdb.so.1
contextkit-0.5.15-2.fc15.x86_64 requires libcdb.so.1()(64bit)
[couchdb]
couchdb-1.0.3-2.fc16.x86_64 requires libicuuc.so.46()(64bit)
couchdb-1.0.3-2.fc16.x86_64 requires libicui18n.so.46()(64bit)
couchdb-1.0.3-2.fc16.x86_64 requires libicudata.so.46()(64bit)
[curry]
curry-0.9.11-7.fc12.x86_64 requires libgmp.so.3()(64bit)
[dh-make]
dh-make-0.55-4.fc17.noarch requires debhelper
[ease]
ease-0.4-14.fc17.i686 requires libcogl.so.6
ease-0.4-14.fc17.x86_64 requires libcogl.so.6()(64bit)
[ember]
ember-0.6.2-2.fc17.x86_64 requires ember-media = 0:0.6.2
[emerillon]
emerillon-0.1.90-5.fc17.x86_64 requires libcogl.so.6()(64bit)
[eog-plugins]
eog-plugins-3.2.2-3.fc17.x86_64 requires libcogl.so.6()(64bit)
[frysk]
frysk-0.4-32.fc17.x86_64 requires libgcj.so.12()(64bit)
frysk-devel-0.4-32.fc17.i386 requires libvtejava-0.12.so
frysk-devel-0.4-32.fc17.i386 requires libgtkjava-2.10.so
frysk-devel-0.4-32.fc17.i386 requires libglibjava-0.4.so
frysk-devel-0.4-32.fc17.i386 requires libgladejava-2.12.so
frysk-devel-0.4-32.fc17.i386 requires libgcj.so.12
frysk-devel-0.4-32.fc17.i386 requires libcairojava-1.0.so
frysk-devel-0.4-32.fc17.x86_64 requires libvtejava-0.12.so()(64bit)
frysk-devel-0.4-32.fc17.x86_64 requires libgtkjava-2.10.so()(64bit)
frysk-devel-0.4-32.fc17.x86_64 requires libglibjava-0.4.so()(64bit)
frysk-devel-0.4-32.fc17.x86_64 requires libgladejava-2.12.so()(64bit)
frysk-devel-0.4-32.fc17.x86_64 requires libgcj.so.12()(64bit)
frysk-devel-0.4-32.fc17.x86_64 requires libcairojava-1.0.so()(64bit)
frysk-gnome-0.4-32.fc17.x86_64 requires libvtejava-0.12.so()(64bit)
frysk-gnome-0.4-32.fc17.x86_64 requires libvte-java >= 0:0.12.0
frysk-gnome-0.4-32.fc17.x86_64 requires libgtkjava-2.10.so()(64bi

Re: Requesting a change to the BugStatusWorkFlow: Closed/UPSTREAM

2012-01-20 Thread Tim Waugh
On Fri, 2012-01-20 at 08:39 +0100, Marcela Mašláňová wrote:
> I use closed/upstream, when I already fixed it in upstream. This bug 
> should be closed with number of release, where it is fixed or with the 
> link to the commit. I wouldn't blame this state for not fixing bug in 
> some projects. I guess instead of closed/upstream we would see more 
> closed/wontfix|cantfix.

I use POST for that.

"A patch or solution believed to resolve this matter has been proposed
(POSTed) for inclusion in the package or kernel."

For non-kernel packages I read that as meaning that the patch is in-hand
upstream, and not yet built in Fedora.

Tim.
*/



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: Changes coming for CUPS 1.6

2012-01-20 Thread Tim Waugh
On Thu, 2012-01-19 at 15:50 -0800, Adam Williamson wrote:
> What a great idea! We could call one of them 'Postscript'...

Not likely. :-)

I think the current candidate for the optional vector format is PDF
1.4/1.5.

Tim.
*/



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: Requesting a change to the BugStatusWorkFlow: Closed/UPSTREAM

2012-01-20 Thread Ralf Corsepius

On 01/20/2012 08:39 AM, Marcela Mašláňová wrote:

On 01/20/2012 12:31 AM, Stephen Gallagher wrote:



I use closed/upstream, when I already fixed it in upstream. This bug
should be closed with number of release, where it is fixed or with the
link to the commit. I wouldn't blame this state for not fixing bug in
some projects.


Users do!

 To them, what you are doing is to "ignore them for now" and to 
"sit-out bugs", instead. Whether they will find this tolerable or 
consider you to be a non-collaborations jerk widely depend on the actual 
impact the bug they reported has on them.


> I guess instead of closed/upstream we would see more

closed/wontfix|cantfix.
Delegating bugs for fixing to upstream, because you can't  fix for 
whatever reasons isn't much of a problem.


The problem is the attitude "CLOSED UPSTEAM" communicates: Cheating 
about the current shape a package is in Fedora.


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

Re: Requesting a change to the BugStatusWorkFlow: Closed/UPSTREAM

2012-01-20 Thread Matej Cepl

On 20.1.2012 00:31, Stephen Gallagher wrote:

Currently, the official bug lifecycle includes the following phrase:
"The resolution UPSTREAM can be used by maintainers to denote a bug that
they expect to be fixed by upstream development and naturally rolled
back into Fedora as part of the update process. Ideally, a comment
should be added with a link to the upstream bug report."

I've seen quite a few bugs lately closed with this resolution (mostly in
the Evolution and GNOME projects for me personally). It seems to me that
this is terribly useless in terms of informing users when their bugs are
fixed.


You are completely right, except:

 * since I wrote 
http://article.gmane.org/gmane.linux.redhat.fedora.devel/79936/ nobody 
did anything on numerous Bugzilla bugs like 
https://bugzilla.mozilla.org/show_bug.cgi?id=123130, 
https://bugzilla.mozilla.org/show_bug.cgi?id=380493 ... if you know 
about any Perl hacker who would be willing to help, these bugs could be 
a good place to start,
 * BugZappers more or less failed to do any meaningful change in the 
state of our Bugzilla (that's to the large part my failure, but that's 
how it is) and there is just too few of them,
 * this really sounds like proverbial "somebody else should do 
something" ...


Best,

Matěj

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