# 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 Fedor
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 on
[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
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
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
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
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 l
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
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
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
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 i
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 e
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
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.
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
* 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
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
> ph
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
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
> l
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
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.
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 depen
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/hicol
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. I
> "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
d
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 unfi
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.fedorapr
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
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 peo
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 ker
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
* 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
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 upst
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 repo
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 wit
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
---
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
> ava
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
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://
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
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 wa
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 tha
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 mai
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
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
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 complai
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 th
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/listin
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
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
> >
- 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
> >
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
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 developme
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
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 g
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
--
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
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 pr
58 matches
Mail list logo
