Hello, The Google Summer of Code 2014 is approaching, When will Fedora
publish the new idea list?
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
On Sat, Jan 25, 2014 at 7:41 AM, Adam Williamson
ad...@happyassassin.net wrote:
drago01 drag...@gmail.com wrote:
On Fri, Jan 24, 2014 at 12:16 AM, Adam Williamson awill...@redhat.com
wrote:
On Thu, 2014-01-23 at 16:56 -0500, Brian J. Murrell wrote:
As a side note, it also needs to be
On 24 January 2014 19:15, Przemek Klosowski przemek.klosow...@nist.gov wrote:
The term 'hiding' conveys a wrong implication that abandonware is
necessarily an embarrassment to be kept locked up in the attic.
I think that's the right implication.
I can think
of several programs that I use
Hi!
On 23.01.2014 19:26, Josh Boyer wrote:
On Thu, Jan 23, 2014 at 1:03 PM, Thorsten Leemhuis fed...@leemhuis.info
wrote:
[…]
Thx for your answer, just replying to some parts of it where I feel that
making additional statements bring the discussion forward.
What really gives me the
On Fri, Jan 24, 2014 at 11:14:50AM -0800, Adam Williamson wrote:
On Fri, 2014-01-24 at 19:26 +0100, Michael Schwendt wrote:
* That update made it out to the stable updates! In other words, the
draconian Update Policies that were enacted in a vain attempt to prevent
such issues from
On Sat, Jan 25, 2014 at 11:20 AM, Thorsten Leemhuis fed...@leemhuis.infowrote:
[cut]
The Fedoraproject once again chose to leave non-free out of Fedora. I
appreciate that. I even think a lot of users understand why the
Fedoraproject acts like this (now and earlier, too). But: it utterly
Hi!
On 23.01.2014 20:57, Matthew Miller wrote:
On Thu, Jan 23, 2014 at 07:03:02PM +0100, Thorsten Leemhuis wrote:
Okay, I'll bite (after thinking whether writing this mail is worth it):
Thanks. I hope that I can make you feel that it was.
Thx for your answer – yes, I think it was worth it.
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Hi!
On 23.01.2014 22:33, Kevin Fenzi wrote:
On Thu, 23 Jan 2014 19:03:02 +0100 Thorsten Leemhuis
fed...@leemhuis.info wrote:
On 03.01.2014 19:14, Matthew Miller wrote:
[…] So those are my things. What do you think about them? What
else should
Hi!
On 23.01.2014 22:45, Adam Williamson wrote:
On Thu, 2014-01-23 at 19:03 +0100, Thorsten Leemhuis wrote:
wikipedia page. Further: kororaproject.org, fedorautils-installer and
similar project show that there are people that want to make Fedora
better. But they do their work outside of
On Fri, Jan 24, 2014 at 20:40:28 -0800,
Josh Stone jist...@redhat.com wrote:
My point was not about what root can do. Suppose there's a vulnerable
'sudo' binary that gives everyone a root shell. If that binary is
available on any executable path, even readonly, that's trouble.
That isn't
Paolo Bonzini wrote:
From the BlueZ 5.0 release notes:
Remove internal support for telephony (HFP and HSP) profiles. They
should be implemented using the new Profile interface preferably by the
telephony subsystem of choice (e.g. oFono which already supports this)
For Fedora this means
On Sat, 2014-01-25 at 11:20 +0100, Thorsten Leemhuis wrote:
Debian, who has a similar stance on
non-free Software, does a way better job in that area than Fedora does.
Well, not really - they don't have a 'similar stance', they have an
official non-free repository. That's kind of a significant
Ralf, Harald, you both actually mean the same thing, you're just
misunderstanding each other due to inexact wording!
Yes, distro-sync will not remove packages which are not in the default-
enabled repositories at all (in any version) (nor will it downgrade them,
obviously, because there is no
On Sat, 2014-01-25 at 10:43 +, Richard W.M. Jones wrote:
I think that's being unnecessarily harsh on the testers. It's not at all
obvious to anyone that you ought to test update/install of another
package in order to validate an update to selinux-policy-targeted .
Hell, I don't do
On Fri, Jan 24, 2014 at 01:33:07AM +0100, Kevin Kofler wrote:
David Sommerseth wrote:
So, I wonder if it can be considered to enable a downgrade path for
bluez and depending packages, as described in the Contingency Plan:
https://fedoraproject.org/wiki/Changes/Bluez5
Officially
Chris Murphy wrote:
If there is a directory that contains update and non-update related file
changes, that's a problem. If there's segmentation, then this can be done.
Clearly /home needs to be separate (it's OK to take a snapshot but just
don't use it by default in a rollback) or we lose
Am 25.01.2014 17:40, schrieb Tomasz Torcz:
On Fri, Jan 24, 2014 at 01:33:07AM +0100, Kevin Kofler wrote:
David Sommerseth wrote:
So, I wonder if it can be considered to enable a downgrade path for
bluez and depending packages, as described in the Contingency Plan:
On Sat, 2014-01-25 at 12:04 +0100, Alec Leamas wrote:
After hacking a simple tool which provides a GUI for a repository file
it's possible to create repository packages complete with desktop and
appdata file. I have some 5-10 such repository packages under way, my
plan is to push them into
On Fri, Jan 24, 2014 at 03:10:04PM -0700, Chris Murphy wrote:
On Jan 24, 2014, at 11:19 AM, Kevin Fenzi ke...@scrye.com wrote:
On Fri, 24 Jan 2014 09:41:13 -0800
Adam Williamson awill...@redhat.com wrote:
AIUI there is/was a long-term plan to integrate this as core
functionality
On Fri, 24 Jan 2014 20:25:04 +0100
Eike Rathke er...@redhat.com wrote:
Hi,
If time permits I'd like to do an upgrade of ICU to 52.1 next week,
which leads to the usual soname bump.
As quite a lot of packages are affected by this, is anyone objecting
and can point out a better time for
On Sat, 2014-01-25 at 08:43 -0800, Adam Williamson wrote:
Guidelines is a link to
https://fedoraproject.org/wiki/Packaging:Guidelines :
Configuration for package managers in Fedora MUST ONLY reference the
official Fedora repositories in their default enabled and disabled state
(see the yum
Am 25.01.2014 17:46, schrieb Tomasz Torcz:
Note that this situation is perfectly handled by Offline Updates.
After reboot, there aren't collateral changes to filesystem, only
upgrade-related
ones. So if there's a need for revert, the previous state is clearly defined
says who?
UsrMove was
Sergio Pascual wrote:
The situation (a broken system that cannot be upgraded) could be
mitigated a little bit by using yum + system snapshots. You can rollback
to a previous sane system.
The big problem with that approach (other than the granularity issue already
pointed out) is disk space.
Adam Williamson wrote:
On Fri, 2014-01-24 at 13:36 +0100, Kevin Kofler wrote:
* If the package is already so screwed that it breaks the whole system,
it cannot realistically get any worse.
Sure it can. It can wipe all your data, or mail it to the NSA...
That's why I said realistically.
On Sat, 25 Jan 2014 12:16:40 +0100
Thorsten Leemhuis fed...@leemhuis.info wrote:
...snip...
Agreed. For example, +1/like-Buttons for a mailing list would be
good afaics, to get a rough impression how people think (just
wondering: will hyperkitty or something from that camp of developers
On Sat, 25 Jan 2014 09:59:12 -0700
Kevin Fenzi ke...@scrye.com wrote:
On Sat, 25 Jan 2014 12:16:40 +0100
Thorsten Leemhuis fed...@leemhuis.info wrote:
...snip...
Agreed. For example, +1/like-Buttons for a mailing list would be
good afaics, to get a rough impression how people think
Adam Williamson wrote:
The 'comment' field exists to allow people to express all these things,
but as it's just a completely free-form text field, it's intrinsically
impossible to really base any programmatic stuff or even policy on it.
In theory maintainers could submit updates without using
Dominick Grift wrote:
Sure, what i am saying is that this could have been prevented if the
team just put a little more passion into it and also did some proof
reading/coordination. The team knows whats going on. They know the
issues and they can quickly and effortlessly identify issues like
Michael Schwendt wrote:
By the time the first testers noticed the scriptlet errors it was too
late, since stable updates cannot be withdrawn.
That is also not a law of Physics. In the early days of Bodhi, one could
actually unpush stuff from stable. Having stable updates become immutable is
Adam Williamson wrote:
Yup, indeed. Of course, this is another area where we could improve the
tooling: it doesn't seem like it'd be difficult for maintainers to be
allowed to set a minimum timeframe before their update goes stable, but
at present this isn't possible.
Why do we need to keep
Michael Schwendt wrote:
More lessons to learn:
https://admin.fedoraproject.org/updates/FEDORA-2013-23627
Karma: 17
Stable karma: 16 (!)
It has reached the karma threshold 16 after ~5 days.
And those have not been all testers.
That can work for yum, but if I set the stable
Just replying to the subject, without going into the implementation details:
We've just hit two critical regressions, one in Fedora 20 (see the 2+
threads about it) and one in Rawhide
(https://bugzilla.redhat.com/show_bug.cgi?id=1052317, still open!), as a
result of SELinux checking being TOO
On 01/25/2014 06:03 AM, Bruno Wolff III wrote:
On Fri, Jan 24, 2014 at 20:40:28 -0800,
Josh Stone jist...@redhat.com wrote:
My point was not about what root can do. Suppose there's a vulnerable
'sudo' binary that gives everyone a root shell. If that binary is
available on any executable
On Sat, 2014-01-25 at 19:10 +0100, Kevin Kofler wrote:
Never the less, I think this issue could have been prevented even before
a package was spun.
Yes, by disabling SELinux by default. :-)
No, that is a different discussion. Disabling SELinux does nothing to
solve this. If anything, to
On Sat, 25 Jan 2014 19:29:12 +0100, Kevin Kofler wrote:
https://admin.fedoraproject.org/updates/FEDORA-2013-23627
Karma:17
Stable karma: 16 (!)
It has reached the karma threshold 16 after ~5 days.
And those have not been all testers.
That can work for yum, but if I set
On Sat, 25 Jan 2014 19:17:14 +0100, Kevin Kofler wrote:
By the time the first testers noticed the scriptlet errors it was too
late, since stable updates cannot be withdrawn.
That is also not a law of Physics. In the early days of Bodhi, one could
actually unpush stuff from stable.
On Sat, 2014-01-25 at 17:46 +0100, Tomasz Torcz wrote:
On Fri, Jan 24, 2014 at 03:10:04PM -0700, Chris Murphy wrote:
On Jan 24, 2014, at 11:19 AM, Kevin Fenzi ke...@scrye.com wrote:
On Fri, 24 Jan 2014 09:41:13 -0800
Adam Williamson awill...@redhat.com wrote:
AIUI there
On Sat, 2014-01-25 at 14:32 -0500, Colin Walters wrote:
On Sat, 2014-01-25 at 10:37 -0800, Josh Stone wrote:
Ok, sure, you can mount -o nosuid,noexec,nodev ... but this isn't the
default for btrfs subvolume paths AFAIK. It needs to be a conscious
decision in whatever snapshot design we
On Jan 24, 2014, at 9:40 PM, Josh Stone jist...@redhat.com wrote:
On 01/24/2014 05:27 PM, Chris Murphy wrote:
On Jan 24, 2014, at 4:16 PM, Josh Stone jist...@redhat.com wrote:
This concerns me especially in the case of security updates -- for
example, a vulnerable setuid-root binary should
Le 25/01/2014 20:40, Reindl Harald a écrit :
i think sometimes some nice words are worth
F19/F20 so far are great releases with nearly zero regressions
possibly because RHEL7 is cooked based on F19/F20 and partyl Rawhide
No, all the merit is due to Fedora contributors and our efforts to
first:
be sure after the style of replies like yours i will
hestitate try to make compilemts again in the public
because the aggresive way you react leads nowhere else
then flamewars
Am 25.01.2014 21:26, schrieb Haïkel Guémar:
Le 25/01/2014 20:40, Reindl Harald a écrit :
i think sometimes some
Dominick Grift wrote:
No, that is a different discussion.
Nonsense. That SELinux should be disabled is the whole point of this thread
(I know, I have started it!), all the suggestions (in the various
subthreads) of how to paper over the problem are off topic.
Disabling SELinux does nothing
Michael Schwendt wrote:
If the update doesn't refer to any bugzilla tickets, what does that mean?
In that particular case, it means that we are updating all the KDE software
compilation and so there's a new release of KFloppy too, which most likely
doesn't even contain any actual changes from
Le 25/01/2014 21:38, Reindl Harald a écrit :
first:
be sure after the style of replies like yours i will
hestitate try to make compilemts again in the public
because the aggresive way you react leads nowhere else
then flamewars
I'd rather have you stop starting or feeding flamewars as you
On Sat, 2014-01-25 at 21:51 +0100, Kevin Kofler wrote:
Dominick Grift wrote:
No, that is a different discussion.
Nonsense. That SELinux should be disabled is the whole point of this thread
(I know, I have started it!), all the suggestions (in the various
subthreads) of how to paper over
Am 25.01.2014 22:00, schrieb Kevin Kofler:
But then the right solution is to disable karma automatism entirely, not to
set it to some ridiculously high value.
Those meaningless thresholds need to go away (and really, the whole concept
of Bodhi karma and the policies that depend on it)
i
Am 25.01.2014 22:05, schrieb Haïkel Guémar:
Le 25/01/2014 21:38, Reindl Harald a écrit :
first:
be sure after the style of replies like yours i will
hestitate try to make compilemts again in the public
because the aggresive way you react leads nowhere else
then flamewars
I'd rather
On Sat, 25 Jan 2014 22:00:02 +0100, Kevin Kofler wrote:
Right, but you were proposing to wait until it reaches a karma of +16.
Certainly not. That Yum update is only a good example where a high
karma threshold has been reached in less than a week, and even without
a vote from all
Le 25/01/2014 22:22, Reindl Harald a écrit :
as you actively did this month - where?
As i'm not planning to go further, i'll answer this last one:
The very first flame of the year here has been the DNF vs yum thread
you started
which got us coverage from phoronix.
For the rest, just review
Hi all,
I'm sad to announce that a great free software (open source) contibutor is
dead...
My english is really too bad to say what is my feeling, so, I will speak french
instead of not speaking...
Every one can contribute here, this isn't mandatory :
Am 25.01.2014 22:34, schrieb Haïkel Guémar:
Le 25/01/2014 22:22, Reindl Harald a écrit :
as you actively did this month - where?
As i'm not planning to go further, i'll answer this last one:
The very first flame of the year here has been the DNF vs yum thread you
started
which got us
Le 25/01/2014 22:35, Alain Portal a écrit :
Hi all,
I'm sad to announce that a great free software (open source) contibutor is
dead...
My english is really too bad to say what is my feeling, so, I will speak french
instead of not speaking...
Every one can contribute here, this isn't
I'm also dogfooding Fedora for almost a decade and i always had
updates-testing enabled since it exists.
There were times when Fedora was very aggressive on updates and it had
an impact (a positive one overall, i hope)
There are two poles in our community: one wishing a more bleeding
Am 25.01.2014 23:01, schrieb Haïkel Guémar:
I'm also dogfooding Fedora for almost a decade and i always had
updates-testing enabled since it exists.
There were times when Fedora was very aggressive on updates and it had an
impact (a positive one overall, i hope)
There are two poles in
On Sat, Jan 25, 2014 at 02:55:32PM -0500, Simo Sorce wrote:
On Sat, 2014-01-25 at 17:46 +0100, Tomasz Torcz wrote:
If there is a directory that contains update and non-update related file
changes, that's a problem. If there's segmentation, then this can be
done.
Note that
Am 25.01.2014 23:26, schrieb Tomasz Torcz:
On Sat, Jan 25, 2014 at 02:55:32PM -0500, Simo Sorce wrote:
The ONLY way to do that is if you do not care at all about user's data
and simply accept that a rollback will also remove user data.
The reason is simple: lot's of software *changes* data
Le samedi 25 janvier 2014 22:43:32 Haïkel Guémar a écrit :
Le 25/01/2014 22:35, Alain Portal a écrit :
Hi all,
I'm sad to announce that a great free software (open source) contibutor is
dead...
My english is really too bad to say what is my feeling, so, I will speak
french instead
On Sat, 2014-01-25 at 23:26 +0100, Tomasz Torcz wrote:
On Sat, Jan 25, 2014 at 02:55:32PM -0500, Simo Sorce wrote:
On Sat, 2014-01-25 at 17:46 +0100, Tomasz Torcz wrote:
If there is a directory that contains update and non-update related file
changes, that's a problem. If there's
On Jan 25, 2014, at 9:41 AM, Kevin Kofler kevin.kof...@chello.at wrote:
Chris Murphy wrote:
If there is a directory that contains update and non-update related file
changes, that's a problem. If there's segmentation, then this can be done.
Clearly /home needs to be separate (it's OK to
On Jan 25, 2014, at 9:46 AM, Tomasz Torcz to...@pipebreaker.pl wrote:
On Fri, Jan 24, 2014 at 03:10:04PM -0700, Chris Murphy wrote:
Another possible case it's /etc/ where the either a package or the user could
make changes during the update. Btrfs allows per file snapshots with cp
On Jan 25, 2014, at 12:55 PM, Simo Sorce s...@redhat.com wrote:
The reason is simple: lot's of software *changes* data as part of its
normal functioning, including and often in rollback-incompatible ways.
You cannot assume that upgrading a program that uses a database X from
version A to B
Am 26.01.2014 01:28, schrieb Chris Murphy:
It is basically impossible to find applications that handle the case
where you downgrade, in any more graceful way than punting and failing
to start in the *good* case. In the bad case they start and trash the
database.
But important user data
On Jan 25, 2014, at 4:12 PM, Adam Williamson awill...@redhat.com wrote:
* Do an offline update that includes Foo v2.0
* Boot the updated system, run Foo, it migrates its configuration to
some new scheme
* Realize there was something wrong with the update, roll it back
* Run Foo again, find
Am 26.01.2014 01:54, schrieb Chris Murphy:
On Jan 25, 2014, at 4:12 PM, Adam Williamson awill...@redhat.com wrote:
* Do an offline update that includes Foo v2.0
* Boot the updated system, run Foo, it migrates its configuration to
some new scheme
* Realize there was something wrong with the
Le dimanche 26 janvier 2014 00:32:32 Haïkel Guémar a écrit :
I'll translate it for you, with some alterations as i don't consider
them very fitting:
Thank for the translation, but I don't agree with that...
And as you said « with some alterations as i don't consider them very
This thread is closed.
Please re-read the http://fedoraproject.org/code-of-conduct
(linked in every post)
kevin
signature.asc
Description: PGP signature
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct:
On Sat, Jan 25, 2014 at 4:40 PM, Tomasz Torcz to...@pipebreaker.pl wrote:
On Fri, Jan 24, 2014 at 01:33:07AM +0100, Kevin Kofler wrote:
David Sommerseth wrote:
So, I wonder if it can be considered to enable a downgrade path for
bluez and depending packages, as described in the Contingency
On 25.01.2014 17:35, Adam Williamson wrote:
On Sat, 2014-01-25 at 11:20 +0100, Thorsten Leemhuis wrote:
Debian, who has a similar stance on
non-free Software, does a way better job in that area than Fedora does.
Well, not really - they don't have a 'similar stance', they have an
official
perl-Language-Expr has broken dependencies in the rawhide tree:
On x86_64:
perl-Language-Expr-0.19-4.fc19.noarch requires
perl(:MODULE_COMPAT_5.16.2)
On i386:
perl-Language-Expr-0.19-4.fc19.noarch requires
perl(:MODULE_COMPAT_5.16.2)
On armhfp:
mojomojo has broken dependencies in the rawhide tree:
On x86_64:
mojomojo-1.10-1.fc20.noarch requires
perl(HTML::FormFu::Element::reCAPTCHA)
On i386:
mojomojo-1.10-1.fc20.noarch requires
perl(HTML::FormFu::Element::reCAPTCHA)
On armhfp:
mojomojo-1.10-1.fc20.noarch
perl-Catalyst-Controller-HTML-FormFu has broken dependencies in the rawhide
tree:
On x86_64:
perl-Catalyst-Controller-HTML-FormFu-0.09004-4.fc20.noarch requires
perl(HTML::FormFu::MultiForm)
On i386:
perl-Catalyst-Controller-HTML-FormFu-0.09004-4.fc20.noarch requires
perl-qpid_proton has broken dependencies in the rawhide tree:
On x86_64:
perl-qpid_proton-0.6-1.fc21.x86_64 requires perl(qpid_proton)
perl-qpid_proton-0.6-1.fc21.x86_64 requires
perl(qpid::proton::ExceptionHandling)
On i386:
perl-qpid_proton-0.6-1.fc21.i686 requires
perl-Catalyst-View-TT has broken dependencies in the epel-6 tree:
On ppc64:
perl-Catalyst-View-TT-0.34-1.el6.noarch requires perl(Class::Accessor)
Please resolve this as soon as possible.
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing
perl-DBIx-Class has broken dependencies in the epel-6 tree:
On ppc64:
perl-DBIx-Class-0.08123-2.el6.noarch requires perl(Class::Trigger)
Please resolve this as soon as possible.
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-Data-ICal has broken dependencies in the epel-6 tree:
On ppc64:
perl-Data-ICal-0.16-1.el6.noarch requires perl(Class::Accessor)
Please resolve this as soon as possible.
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-OpenOffice-UNO has broken dependencies in the epel-6 tree:
On x86_64:
perl-OpenOffice-UNO-0.07-4.el6.x86_64 requires
libsal_textenc.so.3()(64bit)
Please resolve this as soon as possible.
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel
perl-SGML-Parser-OpenSP has broken dependencies in the epel-6 tree:
On ppc64:
perl-SGML-Parser-OpenSP-0.994-4.el6.ppc64 requires perl(Class::Accessor)
Please resolve this as soon as possible.
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel
perl-Nagios-Plugin has broken dependencies in the epel-6 tree:
On ppc64:
perl-Nagios-Plugin-0.35-1.el6.noarch requires
perl(Class::Accessor::Fast)
perl-Nagios-Plugin-0.35-1.el6.noarch requires perl(Class::Accessor)
Please resolve this as soon as possible.
--
Fedora Extras Perl
perl-Catalyst-Plugin-Session-Store-FastMmap has broken dependencies in the
epel-6 tree:
On ppc64:
perl-Catalyst-Plugin-Session-Store-FastMmap-0.14-2.el6.noarch requires
perl(Class::Data::Inheritable)
perl-Catalyst-Plugin-Session-Store-FastMmap-0.14-2.el6.noarch requires
perl-Data-Visitor has broken dependencies in the epel-6 tree:
On ppc64:
perl-Data-Visitor-0.27-1.el6.noarch requires perl(Class::Accessor)
Please resolve this as soon as possible.
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-Class-Accessor-Chained has broken dependencies in the epel-6 tree:
On ppc64:
perl-Class-Accessor-Chained-0.01-9.el6.noarch requires
perl(Class::Accessor::Fast)
perl-Class-Accessor-Chained-0.01-9.el6.noarch requires
perl(Class::Accessor)
Please resolve this as soon as
perl-Exception-Class has broken dependencies in the epel-6 tree:
On ppc64:
perl-Exception-Class-1.29-1.1.el6.noarch requires
perl(Class::Data::Inheritable)
Please resolve this as soon as possible.
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel
perl-Text-RecordParser has broken dependencies in the epel-6 tree:
On ppc64:
perl-Text-RecordParser-1.3.0-2.el6.noarch requires perl(Class::Accessor)
Please resolve this as soon as possible.
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing
perl-File-Pid has broken dependencies in the epel-6 tree:
On ppc64:
perl-File-Pid-1.01-2.el6.noarch requires perl(Class::Accessor::Fast) =
0:0.19
Please resolve this as soon as possible.
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing
perl-HTTP-Request-AsCGI has broken dependencies in the epel-6 tree:
On ppc64:
perl-HTTP-Request-AsCGI-1.2-2.el6.noarch requires
perl(Class::Accessor::Fast)
perl-HTTP-Request-AsCGI-1.2-2.el6.noarch requires perl(Class::Accessor)
Please resolve this as soon as possible.
--
perl-Catalyst-Devel has broken dependencies in the epel-6 tree:
On ppc64:
perl-Catalyst-Devel-1.28-1.el6.1.noarch requires
perl(File::Copy::Recursive)
Please resolve this as soon as possible.
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel
perl-Class-DBI has broken dependencies in the epel-6 tree:
On ppc64:
perl-Class-DBI-3.0.17-5.el6.noarch requires perl(Class::Trigger) =
0:0.07
perl-Class-DBI-3.0.17-5.el6.noarch requires perl(Class::Accessor)
Please resolve this as soon as possible.
--
Fedora Extras Perl SIG
perl-SQL-Translator has broken dependencies in the epel-6 tree:
On ppc64:
perl-SQL-Translator-0.11006-1.el6.noarch requires
perl(Class::Data::Inheritable) = 0:0.02
perl-SQL-Translator-0.11006-1.el6.noarch requires
perl(Class::Accessor::Fast)
Please resolve this as soon as
perl-Array-Diff has broken dependencies in the epel-6 tree:
On ppc64:
1:perl-Array-Diff-0.07-7.el6.noarch requires perl(Class::Accessor::Fast)
Please resolve this as soon as possible.
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-Ima-DBI has broken dependencies in the epel-6 tree:
On ppc64:
perl-Ima-DBI-0.35-7.el6.noarch requires perl(Class::Data::Inheritable)
Please resolve this as soon as possible.
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-HTTP-Request-AsCGI has broken dependencies in the epel-6 tree:
On ppc64:
perl-HTTP-Request-AsCGI-1.2-2.el6.noarch requires
perl(Class::Accessor::Fast)
perl-HTTP-Request-AsCGI-1.2-2.el6.noarch requires perl(Class::Accessor)
Please resolve this as soon as possible.
--
perl-Nagios-Plugin has broken dependencies in the epel-6 tree:
On ppc64:
perl-Nagios-Plugin-0.35-1.el6.noarch requires
perl(Class::Accessor::Fast)
perl-Nagios-Plugin-0.35-1.el6.noarch requires perl(Class::Accessor)
Please resolve this as soon as possible.
--
Fedora Extras Perl
perl-SGML-Parser-OpenSP has broken dependencies in the epel-6 tree:
On ppc64:
perl-SGML-Parser-OpenSP-0.994-4.el6.ppc64 requires perl(Class::Accessor)
Please resolve this as soon as possible.
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel
perl-Catalyst-View-TT has broken dependencies in the epel-6 tree:
On ppc64:
perl-Catalyst-View-TT-0.34-1.el6.noarch requires perl(Class::Accessor)
Please resolve this as soon as possible.
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing
perl-Class-DBI has broken dependencies in the epel-6 tree:
On ppc64:
perl-Class-DBI-3.0.17-5.el6.noarch requires perl(Class::Trigger) =
0:0.07
perl-Class-DBI-3.0.17-5.el6.noarch requires perl(Class::Accessor)
Please resolve this as soon as possible.
--
Fedora Extras Perl SIG
perl-Authen-Simple has broken dependencies in the epel-6 tree:
On ppc64:
perl-Authen-Simple-0.4-5.el6.noarch requires perl(Crypt::PasswdMD5)
Please resolve this as soon as possible.
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-Catalyst-Devel has broken dependencies in the epel-6 tree:
On ppc64:
perl-Catalyst-Devel-1.28-1.el6.1.noarch requires
perl(File::Copy::Recursive)
Please resolve this as soon as possible.
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel
perl-Array-Diff has broken dependencies in the epel-6 tree:
On ppc64:
1:perl-Array-Diff-0.07-7.el6.noarch requires perl(Class::Accessor::Fast)
Please resolve this as soon as possible.
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-File-Pid has broken dependencies in the epel-6 tree:
On ppc64:
perl-File-Pid-1.01-2.el6.noarch requires perl(Class::Accessor::Fast) =
0:0.19
Please resolve this as soon as possible.
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing
perl-SQL-Translator has broken dependencies in the epel-6 tree:
On ppc64:
perl-SQL-Translator-0.11006-1.el6.noarch requires
perl(Class::Data::Inheritable) = 0:0.02
perl-SQL-Translator-0.11006-1.el6.noarch requires
perl(Class::Accessor::Fast)
Please resolve this as soon as
1 - 100 of 110 matches
Mail list logo
