EPEL [HEADS UP] Mongodb 2.4.6 upgrade - Nov 7
Hello, This is just a heads up that we will be updating mongodb from 2.2.6 to 2.4.6 on November 7. All of our tests on test and production machines have shown updates without any problems. But I want to give enough lead time so people can try it out for themselves if they wish. Thank You Troy Dawson ___ epel-devel mailing list epel-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/epel-devel
Re: EPEL Need help regarding of a broken dependency notification
On 09/22/2013 07:27 AM, Jochen Schmitt wrote: Hello, I have got the following notification message from the buildsystem. Because I'm wondering about this message, I would ask, which action is required to avoid this message. Best Regards: Jochen Schmitt - Forwarded message from build...@fedoraproject.org - pgp-tools has broken dependencies in the epel-6 tree: On i386: pgp-tools-1.1.4-3.el6.i686 requires perl(Locale::Recode) On ppc64: pgp-tools-1.1.4-3.el6.ppc64 requires perl(Locale::Recode) Please resolve this as soon as possible. ___ epel-devel mailing list epel-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/epel-devel perl-libintl provides perl(Locale::Recode) Why? I don't know. Doesn't seem to follow the normal perl naming convention. Anyway, it looks like this was put into EPEL5, but never EPEL6. http://koji.fedoraproject.org/koji/packageinfo?packageID=3358 Troy ___ epel-devel mailing list epel-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/epel-devel
Re: EPEL Need help regarding of a broken dependency notification
On Mon, 23 Sep 2013 10:08:23 -0500 Troy Dawson tdaw...@redhat.com wrote: perl-libintl provides perl(Locale::Recode) Why? I don't know. Doesn't seem to follow the normal perl naming convention. Anyway, it looks like this was put into EPEL5, but never EPEL6. http://koji.fedoraproject.org/koji/packageinfo?packageID=3358 It seems to be in RHEL for 6... but I'm not sure why it's not providing the needed dependency. kevin signature.asc Description: PGP signature ___ epel-devel mailing list epel-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/epel-devel
mc alternative: Double Commander
Dne 22.9.2013 10:32, Martin Sourada napsal(a): Point me to such graphical filemanager. I fail to see even a decent gui alternative to mc under linux. You can try Double Commander if you like. http://doublecmd.sourceforge.net/ http://vondruch.fedorapeople.org/doublecmd/doublecmd.repo Vít -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
[Test-Announce] 2013-09-23 @ 15:00 UTC - Fedora QA Meeting
# Fedora Quality Assurance Meeting # Date: 2013-09-23 # Time: 15:00 UTC (https://fedoraproject.org/wiki/Infrastructure/UTCHowto) # Location: #fedora-meeting on irc.freenode.net Greetings testers! It's meeting time again on Monday! Alpha is now done and ready to go, but we may have a few more things to do to prepare for it, and it's time to look ahead to Beta as well. 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/20130923 The current proposed agenda is included below. == Proposed Agenda Topics == 1. Previous meeting follow-up 2. Fedora 20 Alpha final work and retrospective 3. Fedora 20 Beta planning 4. Open floor -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net 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 Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: mc alternative: Double Commander
Side note: I've also sent review request to the BZ. If someone can give me a better solution of gtk/qt widgetset, which means keeping these 2 in 1 package, welcome. https://bugzilla.redhat.com/show_bug.cgi?id=989791 https://bugzilla.redhat.com/show_bug.cgi?id=989792 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
[Bug 1010915] New: perl-IO-TieCombine-1.003 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1010915 Bug ID: 1010915 Summary: perl-IO-TieCombine-1.003 is available Product: Fedora Version: rawhide Component: perl-IO-TieCombine Keywords: FutureFeature, Triaged Assignee: ppi...@redhat.com Reporter: upstream-release-monitor...@fedoraproject.org QA Contact: extras...@fedoraproject.org CC: mmasl...@redhat.com, perl-de...@lists.fedoraproject.org, ppi...@redhat.com, psab...@redhat.com Latest upstream release: 1.003 Current version/release in Fedora Rawhide: 1.002-6.fc20 URL: http://search.cpan.org/dist/IO-TieCombine/ Please consult the package updates policy before you issue an update to a stable branch: https://fedoraproject.org/wiki/Updates_Policy More information about the service that created this bug can be found at: https://fedoraproject.org/wiki/Upstream_release_monitoring -- You are receiving this mail because: You are on the CC list for the bug. Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=CtjjtlL7Mta=cc_unsubscribe -- 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: Need some help writing gitlab and gitlab-shell specs
Dne 19.9.2013 20:42, Axilleas Pipinellis napsal(a):
I have asked in #fedora-infra what FHS they use with the git repos in
fedorahosted and we concluded that the rails apps would go to
/usr/share/ and git repos and satellites to /usr/lib/.
Git repos in /usr/lib? That does not sound right. Later, you mention on
same places /var/lib, that is more appropriate IMO. You might want to
link to specific section of FHS and elaborate on such decision.
So the current structure is:
|-- /usr/share/gitlab/
| |-- gitlab/
| |-- gitlab-shell/
|
|-- /var/lib/gitlab/
| |-- satellites/
| |-- repositories/
| |-- .ssh/authorized_keys
|
|-- /etc/gitlab/
||-- gitlab.yml
||-- shell.yml
||-- database.yml
||-- unicorn.rb
In /etc there will be configuration files with symlinks in the rails
app dirs. What are your thoughts on the directory locations? Do you
agree?
That looks good. However, I am not sure about the /etc/gitlab. Why there
should be linked all the configuration? Current trend (which I support)
is keep default configuration somewhere by the application, e.g. in
/usr/{lib,share} and into /etc/gitlab place just configuration
overrides, i.e. if you need to differ, you place configuration file into
/etc/gitlab, otherwise the defaults are taken.
And now my questions about the specs.
FYI I have seen the katello.spec and took some info from there[1].
gitlab-shell.spec
-
This is kinda finished.
SPEC:
https://github.com/axilleas/fedora/blob/master/packages/gitlab-shell/gitlab-shell.spec
I tested the package and the appropriate user and group are created
when install/upgrade but when uninstalling, the homedir doesn't get
removed. I suspect this has something to do with useradd and
protecting the homedir of the user?
gitlab.spec
---
This is a draft, I didn't test to install yet.
SPEC:
https://github.com/axilleas/fedora/blob/master/packages/gitlab/gitlab.spec
## Ruby specific
- rake tasks
Many jobs, like the backup, initial database seed, etc. are done with
rake tasks. How do we invoke them without getting in the app root dir
every time? Is there some sort of mechanism for that?
You can call rake -f /path/to/your/Rakefile, but it depends how the
task is written.
## Generic
- symlink logs to /var/log/gitlab/
Not all logs' directory is configurable.
They should be. Logging somewhere into /usr/share makes no sense.
- pids: move to /var/run/gitlab/ (?)
GitLab is practically running using unicorn and sidekiq. These two
create each its own pid file in app_dir/tmp/pids/ by default. Luckily
this is configurable via their configs or systemd services. Also
unicorn creates a gitlab.socket which uses to speak with the app. If
we use apache this isn't needed, but with nginx we can use it. I was
thinking it could go under /var/run/gitlab/ too.
Sounds right.
- how to support both databases. Is it feasible?
GitLab supports mysql(mariadb for us) and postgres. How do we deal
with these cases inside a spec file? For now, I have added a comment
about the postgres config and made mariadb the default one.
I would go with something like 'gitlab-mariadb' and 'gitlab-postgres',
which would provide appropriate configurations, but some could argue,
that configuring system by installation of package is wrong.
- ownership of directories
In upstream installation guide, gitlab and gitlab-shell reside in the
same location that's why I decided to have them both under
/usr/share/gitlab/. And my question is, which package owns
/usr/share/gitlab/? Both?
Both, if they are independent. Or you can create some -filesystem
package, which would own the directory.
Vít
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: does mc really require perl*?
On 2013-09-11, Bill Nottingham nott...@redhat.com wrote: The problem with soft dependencies has always been the semantics and the workflow, not the implementation. Even as you describe here with defined semantics, that makes assumptions about the workflow, namely that to make use of them: - the installers are interactive in ways that most of our frontends aren't False. You can decide soft dependencies on preconfigured base. See Gentoo portage tool. It's hell of soft dependencies and it's not interactive. - that we're designing for the case where the person handling software installation is interested in this level of platform micromanagement Again you can leave the decision to a default, if you worry a user gets confused. -- Petr -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Screen blackened
On Sat, Sep 7, 2013 at 6:49 AM, David Beveridge d...@bevhost.com wrote: On Sat, Sep 7, 2013 at 12:18 AM, Richard Vickery richard.vicker...@gmail.com wrote: On Sep 5, 2013 7:12 PM, David Beveridge d...@bevhost.com wrote: nor me. But I can just adjust the brightness on each boot with a 2 finger keypress. Seemed to appear when the kernel went to 3.10.x Which keys? fn - F6 (more brightness symbol) FWIW looks like the kernel 3.11.1 update fixed this for me (ASUS N56VZ). -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: [HEADSUP] Atlas changed libraries
Susi Lehtola wrote:
... huh?
ATLAS, OpenBLAS and (netlib reference) LAPACK are all mutually
incompatible packages.
If you linked with -L%{_libdir}/atlas -llapack -lf77blas -latlas, what
you ended up with is the ATLAS version (*not* the same as netlib
lapack!) of LAPACK and the ATLAS blas library, which reside in
%{_libdir}/atlas/liblapack.so
%{_libdir}/atlas/libf77blas.so
%{_libdir}/atlas/libatlas.so
Alternatively, instead of -lf77blas you could use -lptf77blas which is
the threaded version. Now the packaging is just saner, so you only
need to link -latlas or -lsatlas to get all symbols.
If you linked with -lopenblas (or -lopenblaso or -lopenblasp), you get
the OpenBLAS lapack and blas libraries.
If you linked with -llapack -lblas, you get the reference netlib lapack
and blas libraries.
The way things worked in the past, if you built your programs against
lapack-devel and/or blas-devel, they would pick up the ATLAS libraries if
available at runtime (due to the ld.so.conf.d overrides), and the reference
libraries otherwise. You only had to BR atlas-devel if you tried to use
stuff such as cblas which we weren't packaging separately.
Now with the differently-named ATLAS libraries, only programs built against
atlas-devel will pick up ATLAS at runtime.
As those libraries all export the same symbols, this also sounds like a
surefire recipe for symbol conflicts to me! Imagine an app built against
OpenBLAS using a library A linked against ATLAS and a library B linked
against reference BLAS/LAPACK. You get 3 implementations of some symbols,
who knows which will get picked by the linker, and you could end up with
some mix of symbols which doesn't work at all.
I think we need to enforce ONE implementation of BLAS and LAPACK and ship
that as libblas.so and liblapack.so (even if those are just symlinks or
linker scripts pointing to libopenblas.so or libsatlas.so or whatever).
Kevin Kofler
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
[perl-Devel-CallChecker/f19] 0.006 bump
commit 4aa1dd4f3f52815775a6586f5d89a9d8fa5285dd
Author: Petr Písař ppi...@redhat.com
Date: Mon Sep 23 14:13:05 2013 +0200
0.006 bump
.gitignore |1 +
perl-Devel-CallChecker.spec | 24 ++--
sources |2 +-
3 files changed, 16 insertions(+), 11 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index 4ad46f6..5f6c663 100644
--- a/.gitignore
+++ b/.gitignore
@@ -1,3 +1,4 @@
/Devel-CallChecker-0.003.tar.gz
/Devel-CallChecker-0.004.tar.gz
/Devel-CallChecker-0.005.tar.gz
+/Devel-CallChecker-0.006.tar.gz
diff --git a/perl-Devel-CallChecker.spec b/perl-Devel-CallChecker.spec
index b70c9bd..1dcf446 100644
--- a/perl-Devel-CallChecker.spec
+++ b/perl-Devel-CallChecker.spec
@@ -1,36 +1,36 @@
# This file is licensed under the terms of GNU GPLv2+.
Name: perl-Devel-CallChecker
-Version:0.005
-Release:4%{?dist}
+Version:0.006
+Release:1%{?dist}
Summary:Custom op checking attached to subroutines
License:GPL+ or Artistic
Group: Development/Libraries
URL:http://search.cpan.org/dist/Devel-CallChecker/
Source0:
http://www.cpan.org/authors/id/Z/ZE/ZEFRAM/Devel-CallChecker-%{version}.tar.gz
+BuildRequires: perl
BuildRequires: perl(Module::Build)
+BuildRequires: perl(strict)
+BuildRequires: perl(warnings)
# Run-time
BuildRequires: perl(DynaLoader)
BuildRequires: perl(DynaLoader::Functions) = 0.001
BuildRequires: perl(Exporter)
-BuildRequires: perl(IO::File) = 1.03
BuildRequires: perl(parent)
# Tests
BuildRequires: perl(ExtUtils::CBuilder) = 0.15
BuildRequires: perl(ExtUtils::ParseXS)
BuildRequires: perl(File::Spec)
+BuildRequires: perl(IO::File) = 1.03
BuildRequires: perl(Test::More)
# Optional tests
BuildRequires: perl(Test::Pod) = 1.00
BuildRequires: perl(Test::Pod::Coverage)
BuildRequires: perl(threads)
+BuildRequires: perl(threads::shared)
BuildRequires: perl(Thread::Semaphore)
-# XXX: This package stores build-time Perl version and checks it at run-time.
-# This package must be recompiled on each Perl upgrade. See bug #754159.
-Requires: perl(:MODULE_COMPAT_%(eval `%{__perl} -V:version`; echo
$version))
+Requires: perl(:MODULE_COMPAT_%(eval `perl -V:version`; echo $version))
Requires: perl(DynaLoader)
Requires: perl(DynaLoader::Functions) = 0.001
-Requires: perl(Exporter)
-Requires: perl(IO::File) = 1.03
%{?perl_default_filter}
@@ -49,13 +49,12 @@ without the centralized facility.)
%setup -q -n Devel-CallChecker-%{version}
%build
-%{__perl} Build.PL installdirs=vendor optimize=$RPM_OPT_FLAGS
+perl Build.PL installdirs=vendor optimize=$RPM_OPT_FLAGS
./Build
%install
./Build install destdir=$RPM_BUILD_ROOT create_packlist=0
find $RPM_BUILD_ROOT -type f -name '*.bs' -size 0 -exec rm -f {} \;
-find $RPM_BUILD_ROOT -depth -type d -exec rmdir {} 2/dev/null \;
%{_fixperms} $RPM_BUILD_ROOT/*
%check
@@ -68,6 +67,11 @@ find $RPM_BUILD_ROOT -depth -type d -exec rmdir {}
2/dev/null \;
%{_mandir}/man3/*
%changelog
+* Mon Sep 23 2013 Petr Pisar ppi...@redhat.com - 0.006-1
+- 0.006 bump
+- This version should be compatible with any binary compatible perl version
+ (bug #754159)
+
* Thu Feb 14 2013 Fedora Release Engineering rel-...@lists.fedoraproject.org
- 0.005-4
- Rebuilt for https://fedoraproject.org/wiki/Fedora_19_Mass_Rebuild
diff --git a/sources b/sources
index 15fe5fb..f81a727 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-2e55804221eaa5fdf2e32749b72e74f2 Devel-CallChecker-0.005.tar.gz
+4e8fc69527f2d80e4873f2264c8a0830 Devel-CallChecker-0.006.tar.gz
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Re: [HEADSUP] Atlas changed libraries
Matthew Miller wrote: Actually, what ATLAS upstream intends is for the program to be recompiled on every installation (or boot, even). I think we used to have packages that did that; this is a compromise. Yes, ATLAS upstream has always been smoking deep crack. It looks like OpenBLAS is the much better option, now that it is available. (ATLAS used to be the best available as Free Software back when GotoBLAS was still proprietary, but now that the Goto code has been freed, ATLAS is not looking so great anymore.) Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: [HEADSUP] Atlas changed libraries
On Mon, 23 Sep 2013 14:20:03 +0200
Kevin Kofler kevin.kof...@chello.at wrote:
Susi Lehtola wrote:
... huh?
ATLAS, OpenBLAS and (netlib reference) LAPACK are all mutually
incompatible packages.
If you linked with -L%{_libdir}/atlas -llapack -lf77blas -latlas,
what you ended up with is the ATLAS version (*not* the same as
netlib lapack!) of LAPACK and the ATLAS blas library, which reside
in %{_libdir}/atlas/liblapack.so
%{_libdir}/atlas/libf77blas.so
%{_libdir}/atlas/libatlas.so
Alternatively, instead of -lf77blas you could use -lptf77blas which
is the threaded version. Now the packaging is just saner, so you
only need to link -latlas or -lsatlas to get all symbols.
If you linked with -lopenblas (or -lopenblaso or -lopenblasp), you
get the OpenBLAS lapack and blas libraries.
If you linked with -llapack -lblas, you get the reference netlib
lapack and blas libraries.
The way things worked in the past, if you built your programs against
lapack-devel and/or blas-devel, they would pick up the ATLAS
libraries if available at runtime (due to the ld.so.conf.d
overrides), and the reference libraries otherwise. You only had to BR
atlas-devel if you tried to use stuff such as cblas which we weren't
packaging separately.
Yes, maybe when you use LAPACK since ATLAS used to piggyback the same
name.
Now with the differently-named ATLAS libraries, only programs built
against atlas-devel will pick up ATLAS at runtime.
... and this is a problem why?
There's a big bunch of BLAS/LAPACK libraries out there, ACML, MKL,
ATLAS, GotoBLAS, OpenBLAS, just to name a few.
As those libraries all export the same symbols, this also sounds like
a surefire recipe for symbol conflicts to me! Imagine an app built
against OpenBLAS using a library A linked against ATLAS and a library
B linked against reference BLAS/LAPACK. You get 3 implementations of
some symbols, who knows which will get picked by the linker, and you
could end up with some mix of symbols which doesn't work at all.
Yes, this might be a problem if you use libraries that also link to
some blas library. But these cases can be handled as in GSL: even
though the GSL library has ties to CBLAS, you can pick the CBLAS
library you want to use at compile time.
I think we need to enforce ONE implementation of BLAS and LAPACK and
ship that as libblas.so and liblapack.so (even if those are just
symlinks or linker scripts pointing to libopenblas.so or libsatlas.so
or whatever).
OpenBLAS, ATLAS, ACML and MKL only ship one monolitchic library, so this
is not really an option.
--
Susi Lehtola
Fedora Project Contributor
jussileht...@fedoraproject.org
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
[perl-IO-TieCombine/f19] 1.003 bump
commit 222a1415bc34424fd77398521ad22fb3bd2232a3
Author: Petr Písař ppi...@redhat.com
Date: Mon Sep 23 14:38:41 2013 +0200
1.003 bump
.gitignore |1 +
perl-IO-TieCombine.spec | 19 +--
sources |2 +-
3 files changed, 15 insertions(+), 7 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index e9bf859..33f5ba3 100644
--- a/.gitignore
+++ b/.gitignore
@@ -1,3 +1,4 @@
IO-TieCombine-1.000.tar.gz
/IO-TieCombine-1.001.tar.gz
/IO-TieCombine-1.002.tar.gz
+/IO-TieCombine-1.003.tar.gz
diff --git a/perl-IO-TieCombine.spec b/perl-IO-TieCombine.spec
index 0b72960..15735d6 100644
--- a/perl-IO-TieCombine.spec
+++ b/perl-IO-TieCombine.spec
@@ -1,19 +1,24 @@
Name: perl-IO-TieCombine
-Version:1.002
-Release:4%{?dist}
+Version:1.003
+Release:1%{?dist}
License:GPL+ or Artistic
Group: Development/Libraries
Summary:Produce tied (and other) separate but combined variables
Url:http://search.cpan.org/dist/IO-TieCombine
Source:
http://search.cpan.org/CPAN/authors/id/R/RJ/RJBS/IO-TieCombine-%{version}.tar.gz
BuildArch: noarch
-BuildRequires: perl(ExtUtils::MakeMaker)
+BuildRequires: perl
+BuildRequires: perl(ExtUtils::MakeMaker) = 6.30
+BuildRequires: perl(strict)
+BuildRequires: perl(warnings)
# Run-time
BuildRequires: perl(Carp)
BuildRequires: perl(Symbol)
# Tests
+BuildRequires: perl(File::Find)
+BuildRequires: perl(File::Temp)
BuildRequires: perl(Test::More)
-Requires: perl(:MODULE_COMPAT_%(eval `%{__perl} -V:version`; echo
$version))
+Requires: perl(:MODULE_COMPAT_%(eval `perl -V:version`; echo $version))
%description
This package allows you to tie separate variables into a combined whole, using
@@ -25,13 +30,12 @@ output from various different things that return data in
different ways
%setup -q -n IO-TieCombine-%{version}
%build
-%{__perl} Makefile.PL INSTALLDIRS=vendor
+perl Makefile.PL INSTALLDIRS=vendor
make %{?_smp_mflags}
%install
make pure_install PERL_INSTALL_ROOT=%{buildroot}
find %{buildroot} -type f -name .packlist -exec rm -f {} ';'
-find %{buildroot} -depth -type d -exec rmdir {} 2/dev/null ';'
%{_fixperms} %{buildroot}/*
%check
@@ -43,6 +47,9 @@ make test
%{_mandir}/man3/*.3*
%changelog
+* Mon Sep 23 2013 Petr Pisar ppi...@redhat.com - 1.003-1
+- 1.003 bump
+
* Thu Feb 14 2013 Fedora Release Engineering rel-...@lists.fedoraproject.org
- 1.002-4
- Rebuilt for https://fedoraproject.org/wiki/Fedora_19_Mass_Rebuild
diff --git a/sources b/sources
index 442dc83..776a0d5 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-3f0508284dafe9f674237e99868ba3d2 IO-TieCombine-1.002.tar.gz
+ea4ffa890b1ec4215b5dc65e45f7511f IO-TieCombine-1.003.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-IO-TieCombine/f18] 1.003 bump
commit 8c5f0ea94e88707d920350fe1a3549ae2289083f
Author: Petr Písař ppi...@redhat.com
Date: Mon Sep 23 14:38:41 2013 +0200
1.003 bump
.gitignore |1 +
perl-IO-TieCombine.spec | 19 +--
sources |2 +-
3 files changed, 15 insertions(+), 7 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index e9bf859..33f5ba3 100644
--- a/.gitignore
+++ b/.gitignore
@@ -1,3 +1,4 @@
IO-TieCombine-1.000.tar.gz
/IO-TieCombine-1.001.tar.gz
/IO-TieCombine-1.002.tar.gz
+/IO-TieCombine-1.003.tar.gz
diff --git a/perl-IO-TieCombine.spec b/perl-IO-TieCombine.spec
index 5722433..57680c8 100644
--- a/perl-IO-TieCombine.spec
+++ b/perl-IO-TieCombine.spec
@@ -1,19 +1,24 @@
Name: perl-IO-TieCombine
-Version:1.002
-Release:3%{?dist}
+Version:1.003
+Release:1%{?dist}
License:GPL+ or Artistic
Group: Development/Libraries
Summary:Produce tied (and other) separate but combined variables
Url:http://search.cpan.org/dist/IO-TieCombine
Source:
http://search.cpan.org/CPAN/authors/id/R/RJ/RJBS/IO-TieCombine-%{version}.tar.gz
BuildArch: noarch
-BuildRequires: perl(ExtUtils::MakeMaker)
+BuildRequires: perl
+BuildRequires: perl(ExtUtils::MakeMaker) = 6.30
+BuildRequires: perl(strict)
+BuildRequires: perl(warnings)
# Run-time
BuildRequires: perl(Carp)
BuildRequires: perl(Symbol)
# Tests
+BuildRequires: perl(File::Find)
+BuildRequires: perl(File::Temp)
BuildRequires: perl(Test::More)
-Requires: perl(:MODULE_COMPAT_%(eval `%{__perl} -V:version`; echo
$version))
+Requires: perl(:MODULE_COMPAT_%(eval `perl -V:version`; echo $version))
%description
This package allows you to tie separate variables into a combined whole, using
@@ -25,13 +30,12 @@ output from various different things that return data in
different ways
%setup -q -n IO-TieCombine-%{version}
%build
-%{__perl} Makefile.PL INSTALLDIRS=vendor
+perl Makefile.PL INSTALLDIRS=vendor
make %{?_smp_mflags}
%install
make pure_install PERL_INSTALL_ROOT=%{buildroot}
find %{buildroot} -type f -name .packlist -exec rm -f {} ';'
-find %{buildroot} -depth -type d -exec rmdir {} 2/dev/null ';'
%{_fixperms} %{buildroot}/*
%check
@@ -43,6 +47,9 @@ make test
%{_mandir}/man3/*.3*
%changelog
+* Mon Sep 23 2013 Petr Pisar ppi...@redhat.com - 1.003-1
+- 1.003 bump
+
* Fri Jul 20 2012 Fedora Release Engineering rel-...@lists.fedoraproject.org
- 1.002-3
- Rebuilt for https://fedoraproject.org/wiki/Fedora_18_Mass_Rebuild
diff --git a/sources b/sources
index 442dc83..776a0d5 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-3f0508284dafe9f674237e99868ba3d2 IO-TieCombine-1.002.tar.gz
+ea4ffa890b1ec4215b5dc65e45f7511f IO-TieCombine-1.003.tar.gz
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Re: [HEADSUP] Atlas changed libraries
On Mon, 23 Sep 2013 14:34:50 +0200 Kevin Kofler kevin.kof...@chello.at wrote: Matthew Miller wrote: Actually, what ATLAS upstream intends is for the program to be recompiled on every installation (or boot, even). I think we used to have packages that did that; this is a compromise. Yes, ATLAS upstream has always been smoking deep crack. It looks like OpenBLAS is the much better option, now that it is available. (ATLAS used to be the best available as Free Software back when GotoBLAS was still proprietary, but now that the Goto code has been freed, ATLAS is not looking so great anymore.) Well, it's not too hard to understand why ATLAS does things the way it does. It's already in the acronym: Automatically Tuned Linear Algebra Software. You generate a library that is optimal for your processor. In comparison, GotoBLAS (OpenBLAS) has been hand-tuned in assembly for every supported CPU. On the other hand, I'm not sure why they don't just take their tool and pregenerate lists of optimal parameters for every available CPU. That way you could compile everything in the same package and do runtime CPU detection. Currently binary distributions have to do some hackaround to generate a reasonably efficient one-size-fits-all library. -- Susi Lehtola Fedora Project Contributor jussileht...@fedoraproject.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
How to properly depreciate a package that will be provided by another (trustedqsl/tqsllib)
After seeing many emails on packages that have not been properly retired/depreciated I wanted to make sure I get this right. Currently there is trustedqsl 1.13 and tqsllib 2.2 in Fedora. For whatever reason these were developed seprately in the past even though they are closely tied together and trustedqsl is the only user of tqsllib. Now upstream has a new single archive that contains both trustedqsl 1.14.3 and tqsllib 2.3 and I have a package that properly builds both. The question is, since a tqsllib package will still be produced, what is the proper steps to replace the existing tqsllib and do I need Obsolete/Provides? I don't think so because the package name is the same but I wanted to be sure. Thanks, Richard -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: [HEADSUP] Atlas changed libraries
On 09/23/2013 02:46 PM, Susi Lehtola wrote: Well, it's not too hard to understand why ATLAS does things the way it does. It's already in the acronym: Automatically Tuned Linear Algebra Software. You generate a library that is optimal for your processor. In comparison, GotoBLAS (OpenBLAS) has been hand-tuned in assembly for every supported CPU. On the other hand, I'm not sure why they don't just take their tool and pregenerate lists of optimal parameters for every available CPU. That way you could compile everything in the same package and do runtime CPU detection. Currently binary distributions have to do some hackaround to generate a reasonably efficient one-size-fits-all library. Atlas has hand-tuned assembler kernels as well. Build-time tuning searches mainly for optimal block size to minimize cache misses. How does OpenBlas handle blocking? -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: [HEADSUP] Atlas changed libraries
Susi Lehtola wrote: OpenBLAS, ATLAS, ACML and MKL only ship one monolitchic library, so this is not really an option. That sucks (and at least ATLAS used not to do that), though linker scripts could easily point both libblas.so and liblapack.so to a single monolithic library at compile/link time. (Of course, the programs would have to be rebuilt, and third-party binary-only stuff would not pick that up.) Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: [HEADSUP] Atlas changed libraries
On 09/22/2013 05:33 AM, Orion Poplawski wrote: Any guidelines or suggestions as to whether to link to the serial or threaded library? For some not yet known reason, threaded library built in koji does not work (fails at pthread_create). My local mockbuild works without any problem. Use serial for now. In the future: If your app does the parallelization, use serial. In single-process single-threaded apps use parallel Atlas. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: [HEADSUP] Atlas changed libraries
Susi Lehtola wrote: I might mention that OpenBLAS (successor to GotoBLAS) is in Fedora, which is often 2x faster than ATLAS. But, it's only available on ix86 and x86_64. Looks like armv7 is now being worked on (started Sep 14): https://groups.google.com/forum/#!topic/openblas-dev/_tY90FOlkbU but right now nothing has been imported into their armv7 branch yet, they expect to need a couple more weeks to have something that at least compiles and produces correct results. They also support some other architectures which may be interesting for our secondary arch teams. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: [HEADSUP] Atlas changed libraries
On Mon, 23 Sep 2013 15:26:16 +0200 Frantisek Kluknavsky fkluk...@redhat.com wrote: On 09/22/2013 05:33 AM, Orion Poplawski wrote: Any guidelines or suggestions as to whether to link to the serial or threaded library? For some not yet known reason, threaded library built in koji does not work (fails at pthread_create). My local mockbuild works without any problem. Use serial for now. In the future: If your app does the parallelization, use serial. In single-process single-threaded apps use parallel Atlas. Well, this depends somewhat on the use-case. If individual threads call BLAS functions, then you should use the sequential library. But if the calls are in sequential parts, then you can use the parallel library. OpenBLAS also has an OpenMP flavored variant that can be safely used inside OpenMP parallellized programs. The OpenMP runtime picks up if there is parallellism already in place; this doesn't happen with pthreads. -- Susi Lehtola Fedora Project Contributor jussileht...@fedoraproject.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: [HEADSUP] Atlas changed libraries
On 09/22/2013 09:32 PM, Susi Lehtola wrote: I might mention that OpenBLAS (successor to GotoBLAS) is in Fedora, which is often 2x faster than ATLAS. But, it's only available on ix86 and x86_64. It does have runtime CPU detection, though for the 20-odd CPUs supported. Could you please add more details? I can hardly imagine a situation where properly tuned Atlas is below 50% of maximum possible floating point performance. Packaged Atlas tuned on a completely different machine can of course be slow. The theory goes that if you are into serious high-performance computing, you are willing and able to rebuild a few packages. Plus there is a high chance that you are using some more exotic architecture than those power-hungry x86_64. On the other hand pre-packaged Atlas is probably the second worst alternative for desktop use cases (the worst being canonical Blas). For the record: atlas-3.10.1-1.fc21.armv7hl.rpm is available. I do not have any Arm machine to test except the Fedora builders, any feedback is welcome. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: [HEADSUP] Atlas changed libraries
On 09/22/2013 09:27 PM, Richard W.M. Jones wrote: G. Please don't [to ATLAS upstream, not Susi] do this. It breaks all sorts of scenarios, especially virtual machine migration or simply moving hard disks from one physical machine to another. Arrange your code so it chooses the best available routines when the program starts up, and compile every feasible alternative into the binary. Or use kernel vdso/user-helper functions when that is applicable. Rich. Atlas aims for a relatively narrow set of use cases. No virtualization. No migration. Just the best possible performance on one given machine. Virtual machines are notoriously known for varying performance. One can not tune without exact benchmarking. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: [HEADSUP] Atlas changed libraries
On Mon, 23 Sep 2013 16:15:16 +0200 Frantisek Kluknavsky fkluk...@redhat.com wrote: On 09/22/2013 09:32 PM, Susi Lehtola wrote: I might mention that OpenBLAS (successor to GotoBLAS) is in Fedora, which is often 2x faster than ATLAS. But, it's only available on ix86 and x86_64. It does have runtime CPU detection, though for the 20-odd CPUs supported. Could you please add more details? I can hardly imagine a situation where properly tuned Atlas is below 50% of maximum possible floating point performance. Packaged Atlas tuned on a completely different machine can of course be slow. The theory goes that if you are into serious high-performance computing, you are willing and able to rebuild a few packages. Plus there is a high chance that you are using some more exotic architecture than those power-hungry x86_64. On the other hand pre-packaged Atlas is probably the second worst alternative for desktop use cases (the worst being canonical Blas). Yes, this is regarding pre-packaged Atlas. The cluster guys at my university did some benchmarks of ACML, MKL, OpenBLAS, ATLAS and reference BLAS. The first three are pretty much equal, then came prepackaged ATLAS with 50% less performance and then last came reference BLAS with an order of magnitude or two less speed. But yes, you are right that ATLAS should be recompiled if you really want performance. But then again, you can just use libraries that already give optimal performance. -- Susi Lehtola Fedora Project Contributor jussileht...@fedoraproject.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Retiring libeio
On Sat, Sep 7, 2013 at 6:03 PM, T.C. Hollingsworth tchollingswo...@gmail.com wrote: Please shout if you need it for anything and would like to take it over, otherwise I'll retire it in a week or so. Nobody even so much as whispered, except to say not me either!, so libeio is now retired. -T.C. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
[Owner-change] Fedora packages ownership change
Change in ownership over the last 168 hours === 4 packages were orphaned gnome-backgrounds [devel,f18,f19,f20] was orphaned by vicodan Desktop backgrounds packaged with the GNOME desktop https://admin.fedoraproject.org/pkgdb/acls/name/gnome-backgrounds plone [EL-5,EL-6] was orphaned by jsteffan User friendly and powerful open source Content Management System https://admin.fedoraproject.org/pkgdb/acls/name/plone zope [EL-5,EL-6] was orphaned by jsteffan Web application server for flexible content management applications https://admin.fedoraproject.org/pkgdb/acls/name/zope gnome-icon-theme [devel,f18,f19,f20] was orphaned by vicodan GNOME icon theme https://admin.fedoraproject.org/pkgdb/acls/name/gnome-icon-theme 8 packages unorphaned - remiunorphaned : ckeditor [EL-5,EL-6,devel,f18,f19,f20] chkrunorphaned : gpx-viewer [devel] asrob unorphaned : drupal7-ckeditor [EL-6,devel,f18,f19,f20] smani unorphaned : avl [devel] jhernandunorphaned : ovirt-engine [devel] mizdebskunorphaned : regexp [devel] fab unorphaned : pystatgrab [devel,f19,f20] cicku unorphaned : libgme [devel,f19,f20] 15 packages were retired - ovirt-engine-sdk [EL-6,devel,f18,f19,f20] was retired by oschreib SDK for oVirt-Engine platform https://admin.fedoraproject.org/pkgdb/acls/name/ovirt-engine-sdk obex-data-server [devel,f20] was retired by hadess D-Bus service for Obex access https://admin.fedoraproject.org/pkgdb/acls/name/obex-data-server ql2200-firmware [devel,f20] was retired by jwboyer Firmware for qlogic 2200 devices https://admin.fedoraproject.org/pkgdb/acls/name/ql2200-firmware perl-Bio-ASN1-EntrezGene [devel,f19,f20] was retired by alexlan Regular expression-based Perl Parser for NCBI Entrez Gene https://admin.fedoraproject.org/pkgdb/acls/name/perl-Bio-ASN1-EntrezGene aeolus-audrey-agent [devel] was retired by joev The Aeolus Audrey Startup Agent https://admin.fedoraproject.org/pkgdb/acls/name/aeolus-audrey-agent libbtctl [devel,f20] was retired by thozza Library for the GNOME Bluetooth Subsystem https://admin.fedoraproject.org/pkgdb/acls/name/libbtctl ql23xx-firmware [devel,f20] was retired by jwboyer Firmware for qlogic 23xx devices https://admin.fedoraproject.org/pkgdb/acls/name/ql23xx-firmware python-psycopg [devel,f18,f19,f20] was retired by devrim PostgreSQL database adapter for Python https://admin.fedoraproject.org/pkgdb/acls/name/python-psycopg evas_generic_loaders [devel,f19,f20] was retired by vicodan Extra loaders for GPL loaders and unstable libraries https://admin.fedoraproject.org/pkgdb/acls/name/evas_generic_loaders aeolus-configserver [devel] was retired by joev The Aeolus Audrey Config Server https://admin.fedoraproject.org/pkgdb/acls/name/aeolus-configserver ql2100-firmware [devel,f20] was retired by jwboyer Firmware for qlogic 2100 devices https://admin.fedoraproject.org/pkgdb/acls/name/ql2100-firmware wimax [devel,f20] was retired by notting WiMAX Network Service for the Intel 2400m https://admin.fedoraproject.org/pkgdb/acls/name/wimax wimax-tools [devel,f20] was retired by notting Low level user space tools for the Linux WiMAX stack https://admin.fedoraproject.org/pkgdb/acls/name/wimax-tools libgme [devel,f19,f20] was retired by cicku Video game music file emulation/playback library https://admin.fedoraproject.org/pkgdb/acls/name/libgme libircclient-qt [f20] was retired by jkaluza Cross-platform IRC client library written with Qt 4 https://admin.fedoraproject.org/pkgdb/acls/name/libircclient-qt 9 packages changed owner limbgave to yograterol : python-mongoengine [EL-6] limbgave to maxamillion: golang [EL-6] notting gave to pnemade: yum-langpacks [devel,f18,f19,f20] limbgave to chkr : gpx-viewer [f18,f19,f20] limbgave to jplesnik : perl-Path-FindDev [f20] limbgave to robert : pdfgrep [EL-6] limbgave to smani : avl [f19,f20] limbgave to athmane: hydra [EL-6] limbgave to rdieter: qt5-qtscript [EL-6] Sources: https://github.com/pypingou/fedora-owner-change -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Ananconda
On 09/21/2013 02:53 PM, Chris Murphy wrote: On Sep 21, 2013, at 12:12 PM, Phil Dobbin bukowskis...@gmail.com wrote: Hi, all. I was wondering as to why Ananconda has no facility to overwrite a distro already present on the target machine. It may not be able to identify the partitions making up a distro installation. But it does have multiple ways to either reformat existing partitions, or destroy individual partitions, or destroy all partitions. Chris Murphy How about the reuse of btrfs subvolumes? It seems to me that the only way to do that is to delete the subvolume and then reallocate it which is precisely what I do in my KVM kickstart installs. I first bootup in rescue mode and delete the old root subvolume and then reboot to do the install. I probably need to figure out out a pre-install script which will do that. Is this worth an RFE? I am thinking of an RFE for kickstart. I assume (I have not tried it) that I can reuse an subvolume by first deleting and reclaiming the space from a regular install. Gene -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Ananconda
On 09/23/2013 11:44 AM, Gene Czarcinski wrote: On 09/21/2013 02:53 PM, Chris Murphy wrote: On Sep 21, 2013, at 12:12 PM, Phil Dobbin bukowskis...@gmail.com wrote: Hi, all. I was wondering as to why Ananconda has no facility to overwrite a distro already present on the target machine. It may not be able to identify the partitions making up a distro installation. But it does have multiple ways to either reformat existing partitions, or destroy individual partitions, or destroy all partitions. Chris Murphy How about the reuse of btrfs subvolumes? It seems to me that the only way to do that is to delete the subvolume and then reallocate it which is precisely what I do in my KVM kickstart installs. I first bootup in rescue mode and delete the old root subvolume and then reboot to do the install. I probably need to figure out out a pre-install script which will do that. Is this worth an RFE? I am thinking of an RFE for kickstart. I assume (I have not tried it) that I can reuse an subvolume by first deleting and reclaiming the space from a regular install. Gene https://bugzilla.redhat.com/show_bug.cgi?id=1011137 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
mupdf maintainer non-responsive, any interested co-maintainers?
Hi, the mupdf maintainer seems to be non-responsive and there seem to be users requesting a new update: https://bugzilla.redhat.com/show_bug.cgi?id=848904 Is someone interested in helping here? I only noticed this looking through the upstream release monitoring mails. Regards Till -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: [HEADSUP] Atlas changed libraries
Frantisek Kluknavsky wrote: Atlas aims for a relatively narrow set of use cases. No virtualization. No migration. Just the best possible performance on one given machine. Virtual machines are notoriously known for varying performance. One can not tune without exact benchmarking. Of course, this means that it is a very poor choice for our de-facto default LAPACK/BLAS. (Only the reference implementation is worse. Yet, we build some stuff even against that!) I'd suggest filing a Change to make OpenBLAS the default for F21 (when hopefully the armv7 port will also be usable, so all our primary architectures, even the silly one, will be covered) and working on building everything in the distribution that uses LAPACK and/or BLAS against it. Even if we keep the other BLAS/LAPACK implementations around, the target should be that everything in the distro uses OpenBLAS, similarly to how we made spellchecking use Hunspell throughout the distro (see https://fedoraproject.org/wiki/Releases/FeatureDictionary). (I take it that in this case, the application code should normally not need adjustments, so this should be even easier than FeatureDictionary, and not end in a fiasco such as the failed attempt at standardizing cryptography on NSS.) Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Ananconda
On Sat, Sep 21, 2013 at 8:12 PM, Phil Dobbin bukowskis...@gmail.com wrote: Hi, all. I was wondering as to why Ananconda has no facility to overwrite a distro already present on the target machine. I've studied it apart from destroying the existing partition with GParted there seems to be no other way (this happens on 18 19). Most painful it is. If anybody can show me a workaround I'd be most grateful. In %pre you can do anything, for example preserving the ssh keys. Using cobbler https://fedorahosted.org/cobbler/wiki/KickstartSnippets or in satellite using kickstart profile https://access.redhat.com/site/documentation/en-US/Red_Hat_Network_Satellite/5.3/html/Deployment_Guide/s1-provisioning-templates.html Best Cheers, Phil... -- currently (ab)using Arch Linux, CentOS 5.9 6.4, Debian Squeeze Wheezy, Fedora Beefy, Spherical That Damn Cat, Lubuntu 12.10, OS X Snow Leopard Tiger, Ubuntu Precise, Quantal Raring GnuGPG Key : http://phildobbin.org/**publickey.aschttp://phildobbin.org/publickey.asc -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.**org/mailman/listinfo/develhttps://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-**of-conducthttp://fedoraproject.org/code-of-conduct -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: mupdf maintainer non-responsive, any interested co-maintainers?
CC Pavel. 2013/9/23 Till Maas opensou...@till.name: Hi, the mupdf maintainer seems to be non-responsive and there seem to be users requesting a new update: https://bugzilla.redhat.com/show_bug.cgi?id=848904 -- With best regards, Peter Lemenkov. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: EPEL Need help regarding of a broken dependency notification
On Mon, 23 Sep 2013 10:00:51 -0600 Kevin Fenzi ke...@scrye.com wrote: On Mon, 23 Sep 2013 10:08:23 -0500 Troy Dawson tdaw...@redhat.com wrote: perl-libintl provides perl(Locale::Recode) Why? I don't know. Doesn't seem to follow the normal perl naming convention. Anyway, it looks like this was put into EPEL5, but never EPEL6. http://koji.fedoraproject.org/koji/packageinfo?packageID=3358 It seems to be in RHEL for 6... Could it be that perl-libintl is only built for x86_64 in RHEL 6? If that's the case, we could rebuild the same package (with a lower release number) in EPEL to provide the dependency on other architectures, which is something that's been done before. Paul. ___ epel-devel mailing list epel-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/epel-devel
Re: How to properly depreciate a package that will be provided by another (trustedqsl/tqsllib)
Richard Shaw wrote: The question is, since a tqsllib package will still be produced, what is the proper steps to replace the existing tqsllib and do I need Obsolete/Provides? I don't think so because the package name is the same but I wanted to be sure. * dist-git and pkgdb work on SRPMs, so you commit a dead.package and retire the package as normal (I think fedpkg retire will work fine even in this case), BUT * Obsoletes and Provides are NOT needed. Just make sure the new subpackage has an EVR higher than the previous standalone package. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Ananconda
On Sep 23, 2013, at 9:44 AM, Gene Czarcinski g...@czarc.net wrote: How about the reuse of btrfs subvolumes? It is possible to reuse btrfs subvolumes for mount points other than root. Root requires a new subvolume. It seems to me that the only way to do that is to delete the subvolume and then reallocate it which is precisely what I do in my KVM kickstart installs. I first bootup in rescue mode and delete the old root subvolume and then reboot to do the install. I probably need to figure out out a pre-install script which will do that. No need to delete the previous subvolume unless you want to delete the installation contained on it. Is this worth an RFE? I am thinking of an RFE for kickstart. I assume (I have not tried it) that I can reuse an subvolume by first deleting and reclaiming the space from a regular install. Reuse is inconsistent with delete, but yes you can't reuse an existing subvolume for rootfs for a new install. Chris Murphy -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: mupdf maintainer non-responsive, any interested co-maintainers?
On Mon, Sep 23, 2013 at 12:15 PM, Till Maas opensou...@till.name wrote: Hi, the mupdf maintainer seems to be non-responsive and there seem to be users requesting a new update: https://bugzilla.redhat.com/show_bug.cgi?id=848904 Is someone interested in helping here? I only noticed this looking through the upstream release monitoring mails. I'll have a go. -J Regards Till -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct -- http://cecinestpasunefromage.wordpress.com/ in your fear, seek only peace in your fear, seek only love -d. bowie -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Ananconda
On 09/23/2013 01:39 PM, Chris Murphy wrote: On Sep 23, 2013, at 9:44 AM, Gene Czarcinski g...@czarc.net wrote: How about the reuse of btrfs subvolumes? It is possible to reuse btrfs subvolumes for mount points other than root. Root requires a new subvolume. It seems to me that the only way to do that is to delete the subvolume and then reallocate it which is precisely what I do in my KVM kickstart installs. I first bootup in rescue mode and delete the old root subvolume and then reboot to do the install. I probably need to figure out out a pre-install script which will do that. No need to delete the previous subvolume unless you want to delete the installation contained on it. Is this worth an RFE? I am thinking of an RFE for kickstart. I assume (I have not tried it) that I can reuse an subvolume by first deleting and reclaiming the space from a regular install. Reuse is inconsistent with delete, but yes you can't reuse an existing subvolume for rootfs for a new install. Chris Murphy As a matter of fact, my use of BTRFS in production does use this. I have a pair of SSD's that I use for BTRFS with root and home on them. Data is striped and metadata is mirrored. subvol root18 is ... Fedora 18 and subvol root19 is ... Fedora 19. One of the nice things about using BTRFS is that the free space is shared by all. When I get around to installing Fedora 20, I will delete subvol root18 and then install Fedora 20 on subvol root20. Over the many years I have been dealing with operating systems (and I have been doing it well before linux came along) is to NOT destroy a working system when you install a new version of a system. Therefor, each one of my hardware boxes is multi-boot with space allocated for at least three versions of systems: current, old/new, and test. Oh yes, and the software and (user data) are also kept separate. This was learned (as good things usually are) the hard way. Gene -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Broken autodeps for selinux subpackages in rawhide
Hi, all: Looks like building SELinux subpackages in rawhide results in the following dependency notification. Is that something I should be fixing, or is that a larger problem? I certainly don't have any manual deps on file:///usr/share/doc/selinux-policy/html/index.html, so this must be something that's done by rpmbuild. Best, -- Konstantin Ryabitsev LinuxFoundation.org Montréal, Québec -- Forwarded message -- From: build...@fedoraproject.org Date: Mon, Sep 23, 2013 at 8:30 AM Subject: Broken dependencies: totpcgi To: totpcgi-ow...@fedoraproject.org totpcgi has broken dependencies in the rawhide tree: On x86_64: totpcgi-selinux-0.5.5-1.fc21.noarch requires file:///usr/share/doc/selinux-policy/html/index.html On i386: totpcgi-selinux-0.5.5-1.fc21.noarch requires file:///usr/share/doc/selinux-policy/html/index.html On armhfp: totpcgi-selinux-0.5.5-1.fc21.noarch requires file:///usr/share/doc/selinux-policy/html/index.html Please resolve this as soon as possible. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: How to properly depreciate a package that will be provided by another (trustedqsl/tqsllib)
On Mon, Sep 23, 2013 at 1:07 PM, Kevin Kofler kevin.kof...@chello.atwrote: Richard Shaw wrote: The question is, since a tqsllib package will still be produced, what is the proper steps to replace the existing tqsllib and do I need Obsolete/Provides? I don't think so because the package name is the same but I wanted to be sure. * dist-git and pkgdb work on SRPMs, so you commit a dead.package and retire the package as normal (I think fedpkg retire will work fine even in this case), BUT * Obsoletes and Provides are NOT needed. Just make sure the new subpackage has an EVR higher than the previous standalone package. Thanks for the clarification Kevin... On a related note, the guidelines say I should only retire a package that's not released since the package can not get removed from released versions, so in this case I'm thinking that would be f20 and rawhide. As to the order, I would think I need the new packages in stable before retiring so we have a continuity of update path? Thanks, Richard -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Non-responsive maintainer: Dodji Seketeli
On Tue, Jul 23, 2013 at 09:01:37PM +0200, Dodji Seketeli wrote: Darryl L. Pierce mcpie...@gmail.com a écrit: BZ#848774 This bug is nearly a year old, requesting that package offlineimap be upgraded to what was then the latest release (6.5.4, now it is 6.5.5-rc2). There has been no response from the maintainer. I posted a bug comment on 01 July asking for something from the package maintainer and received no word. I don't want to take over the package, but would like either the primary or else a co-maintainer to upgrade the package as it has bugs that have been fixed since 6.5.2 (the currently packaged release). Hello, Yes, I have been distracted by other duties recently. I'll welcome any help with this package, of course. In the mean time, I was planning to test the latest version of this package on the side, in the coming days, before pushing it to rawhide. Sorry for the inconvenience. Hi, Dodji. It's now been two months since you said you were planning to test the latest version. Since then another version has been promoted to RC. Will you be possibly updating the package anytime soon? -- Darryl L. Pierce mcpie...@gmail.com http://mcpierce.fedorapeople.org/ What do you care what people think, Mr. Feynman? pgp_1f0RE82X2.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: mupdf maintainer non-responsive, any interested co-maintainers?
Thank you, Peter I'll update the package soon. -- Pavel On Mon, 23 Sep 2013, Peter Lemenkov wrote: | CC Pavel. | | 2013/9/23 Till Maas opensou...@till.name: | Hi, | | the mupdf maintainer seems to be non-responsive and there seem to be | users requesting a new update: | https://bugzilla.redhat.com/show_bug.cgi?id=848904 | | -- | With best regards, Peter Lemenkov. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: mc alternative: Double Commander
Hi, On 09/23/2013 11:44 AM, Christopher Meng wrote: Side note: I've also sent review request to the BZ. If someone can give me a better solution of gtk/qt widgetset, which means keeping these 2 in 1 package, welcome. Yes, do the build twice, including running %configure twice with a make distclean in between. IE something like %configure --with-qt4 make mv doublecmd doublecmd-qt4 make distclean %configure --with-gtk2 make And then in %install manually install the binary you saved from getting nuked by make distclean by moving it out of the way. This way you can have one srpm, named simply doublecmd, with -qt4 and -gtk2 sub-packages. You can then use the main package to store common files and make both require it, or simple don't have a %files only a %files qt4 and %files gtk2 and then rpmbuild won't create a main binary package, only the 2 subpackages (while still creating a single src rpm named after the main package). This seems like the best way to deal with this to me (and is how things like this are done in numerous other packages). Please try this, if you get stuck, send me a link to an srpm with your attempts and I'll try to fix it, I might even review this :) Regards, Hans -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Review Request 46: New admin interface and builds support
--- This is an automatically generated e-mail. To reply, visit: http://reviewboard-tflink.rhcloud.com/r/46/ --- (Updated Sept. 23, 2013, 7:26 p.m.) Review request for blockerbugs. Changes --- fixes Repository: blockerbugs Description --- Implement new admin interface with flask-admin Add build support Diffs (updated) - testing/testfunc_update_sync.py 70c600515ccc5e97ed17b4cadd40d76277794b67 testing/testfunc_bugsync.py 496f2994dda81bc82f2e270944a3fb2b391d9d91 testing/testfunc_bugmodel.py a50f3458b2154f13736ab1f93cb3d1a86a48fcb1 testing/test_spinmodel.py PRE-CREATION testing/test_controllers.py 702d2a5390e42910176d327461ef628e6bf8b849 testing/test_api.py e92dda539117f94f3283f6ce262d65295a5e32c1 setup.py 89621b0debb5d368a027a4801de7da62fa961eab sass/admin_layout.scss PRE-CREATION requirements.txt 98eab5da9306a101a41dd13708df1900e9fd1018 blockerbugs/util/koji_interface.py PRE-CREATION blockerbugs/templates/spin_list.html c455ff4edec0991a453a94cd0e38d959e1757672 blockerbugs/templates/admin_layout.html PRE-CREATION blockerbugs/templates/admin/spin_edit.html PRE-CREATION blockerbugs/templates/admin/spin_create.html PRE-CREATION blockerbugs/templates/admin/modify_release.html a3bb0d95c49414ff977e82f828ffdd111e105cc6 blockerbugs/templates/admin/main.html 251b1df1647e307e89bcda365422f1cee59b9a35 blockerbugs/templates/admin/generate_api_key.html PRE-CREATION blockerbugs/templates/admin/edit_userinfo.html PRE-CREATION blockerbugs/templates/admin/admin_nav.html 34a0c2a966c265ab66166b3170f5f6d507014149 blockerbugs/templates/admin/add_spin.html be44830da436e4e87700fe940a7c5197b32d1e82 blockerbugs/templates/admin/add_release.html 931001b23f52dd1b75fe0feb8d0311b76fcc907e blockerbugs/static/js/admin.js PRE-CREATION blockerbugs/models/userinfo.py 069ca9406d6d0e301a2a3a8d9703a940301db0bc blockerbugs/models/update.py 9660d038720bcecae8e4f7401e09e26bd6589189 blockerbugs/models/spin.py fa8e0e9a887f269cf31e850baa90678ff7055b78 blockerbugs/models/release.py cca27cff41875528c1ee13d95194de5f237f31d4 blockerbugs/models/milestone.py 31667f6467ed111c3594cdd86d1c933f73b7dfc2 blockerbugs/models/build.py PRE-CREATION blockerbugs/models/__init__.py 0223fff2996290005bd50412c844979304ce38a2 blockerbugs/controllers/users.py f05ea6b7e0af260545ff3cf340b73d15f55138d1 blockerbugs/controllers/main.py a41627485a77daecc07c8d33f41dc5a17e2ebb97 blockerbugs/controllers/api/utils.py 38144dd48f3190f709a9bafa3a5a425dfdfffbdf blockerbugs/controllers/api/errors.py aaab9107521873100043e9026d1a4b4ea9705983 blockerbugs/controllers/api/api.py d6df7d34170da05bd817b12545596f34b43b9da6 blockerbugs/controllers/admin/spin.py PRE-CREATION blockerbugs/controllers/admin/build.py PRE-CREATION blockerbugs/controllers/admin/auth.py PRE-CREATION blockerbugs/controllers/admin/__init__.py PRE-CREATION blockerbugs/controllers/admin.py 4ce6c9f58b5513c280312c8d1dd92c341d259d0a blockerbugs/config.py e9b2fbc83c98a66ce963eec596e0cb90b66f87b0 blockerbugs/cli.py 7151337aa1e16e571d0cf165c87c3c6f50276b90 blockerbugs/__init__.py bf0daed0c198868e8d56f444bf9a320c85d65362 blockerbugs.spec c5c2409e5ad5fe96c145cf3ec65c8c1778681b6c alembic/versions/f9e369bf00d_added_spin_type_cons.py PRE-CREATION alembic/versions/3b0500a49ea7_added_api_key_hash_t.py PRE-CREATION alembic/versions/1162fb4d4358_added_build_table.py PRE-CREATION Diff: http://reviewboard-tflink.rhcloud.com/r/46/diff/ Testing --- I've tested on my develop instance. Thanks, Ilgiz Islamgulov ___ qa-devel mailing list qa-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/qa-devel
Re: Broken autodeps for selinux subpackages in rawhide
On Mon, 23 Sep 2013 14:40:13 -0400 Konstantin Ryabitsev i...@fedoraproject.org wrote: Hi, all: Looks like building SELinux subpackages in rawhide results in the following dependency notification. Is that something I should be fixing, or is that a larger problem? I certainly don't have any manual deps on file:///usr/share/doc/selinux-policy/html/index.html, so this must be something that's done by rpmbuild. See https://fedoraproject.org/wiki/SELinux_Policy_Modules_Packaging_Draft#Runtime_Dependencies Paul. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: mupdf maintainer non-responsive, any interested co-maintainers?
Excellent! On Mon, Sep 23, 2013 at 11:28 AM, Pavel Zhukov pzhu...@redhat.com wrote: Thank you, Peter I'll update the package soon. -- Pavel On Mon, 23 Sep 2013, Peter Lemenkov wrote: | CC Pavel. | | 2013/9/23 Till Maas opensou...@till.name: | Hi, | | the mupdf maintainer seems to be non-responsive and there seem to be | users requesting a new update: | https://bugzilla.redhat.com/show_bug.cgi?id=848904 | | -- | With best regards, Peter Lemenkov. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct -- http://cecinestpasunefromage.wordpress.com/ in your fear, seek only peace in your fear, seek only love -d. bowie -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Review Request 46: New admin interface and builds support
--- This is an automatically generated e-mail. To reply, visit: http://reviewboard-tflink.rhcloud.com/r/46/ --- (Updated Sept. 23, 2013, 8:02 p.m.) Review request for blockerbugs. Changes --- add builds information to spin API endpoint Repository: blockerbugs Description --- Implement new admin interface with flask-admin Add build support Diffs (updated) - testing/testfunc_update_sync.py 70c600515ccc5e97ed17b4cadd40d76277794b67 testing/testfunc_bugsync.py 496f2994dda81bc82f2e270944a3fb2b391d9d91 testing/testfunc_bugmodel.py a50f3458b2154f13736ab1f93cb3d1a86a48fcb1 testing/test_spinmodel.py PRE-CREATION testing/test_controllers.py 702d2a5390e42910176d327461ef628e6bf8b849 testing/test_api.py e92dda539117f94f3283f6ce262d65295a5e32c1 setup.py 89621b0debb5d368a027a4801de7da62fa961eab sass/admin_layout.scss PRE-CREATION requirements.txt 98eab5da9306a101a41dd13708df1900e9fd1018 blockerbugs/util/koji_interface.py PRE-CREATION blockerbugs/templates/spin_list.html c455ff4edec0991a453a94cd0e38d959e1757672 blockerbugs/templates/admin_layout.html PRE-CREATION blockerbugs/templates/admin/spin_edit.html PRE-CREATION blockerbugs/templates/admin/spin_create.html PRE-CREATION blockerbugs/templates/admin/modify_release.html a3bb0d95c49414ff977e82f828ffdd111e105cc6 blockerbugs/templates/admin/main.html 251b1df1647e307e89bcda365422f1cee59b9a35 blockerbugs/templates/admin/generate_api_key.html PRE-CREATION blockerbugs/templates/admin/edit_userinfo.html PRE-CREATION blockerbugs/templates/admin/admin_nav.html 34a0c2a966c265ab66166b3170f5f6d507014149 blockerbugs/templates/admin/add_spin.html be44830da436e4e87700fe940a7c5197b32d1e82 blockerbugs/templates/admin/add_release.html 931001b23f52dd1b75fe0feb8d0311b76fcc907e blockerbugs/static/js/admin.js PRE-CREATION blockerbugs/models/userinfo.py 069ca9406d6d0e301a2a3a8d9703a940301db0bc blockerbugs/models/update.py 9660d038720bcecae8e4f7401e09e26bd6589189 blockerbugs/models/spin.py fa8e0e9a887f269cf31e850baa90678ff7055b78 blockerbugs/models/release.py cca27cff41875528c1ee13d95194de5f237f31d4 blockerbugs/models/milestone.py 31667f6467ed111c3594cdd86d1c933f73b7dfc2 blockerbugs/models/build.py PRE-CREATION blockerbugs/models/__init__.py 0223fff2996290005bd50412c844979304ce38a2 blockerbugs/controllers/users.py f05ea6b7e0af260545ff3cf340b73d15f55138d1 blockerbugs/controllers/main.py a41627485a77daecc07c8d33f41dc5a17e2ebb97 blockerbugs/controllers/api/utils.py 38144dd48f3190f709a9bafa3a5a425dfdfffbdf blockerbugs/controllers/api/errors.py aaab9107521873100043e9026d1a4b4ea9705983 blockerbugs/controllers/api/api.py d6df7d34170da05bd817b12545596f34b43b9da6 blockerbugs/controllers/admin/spin.py PRE-CREATION blockerbugs/controllers/admin/build.py PRE-CREATION blockerbugs/controllers/admin/auth.py PRE-CREATION blockerbugs/controllers/admin/__init__.py PRE-CREATION blockerbugs/controllers/admin.py 4ce6c9f58b5513c280312c8d1dd92c341d259d0a blockerbugs/config.py e9b2fbc83c98a66ce963eec596e0cb90b66f87b0 blockerbugs/cli.py 7151337aa1e16e571d0cf165c87c3c6f50276b90 blockerbugs/__init__.py bf0daed0c198868e8d56f444bf9a320c85d65362 blockerbugs.spec c5c2409e5ad5fe96c145cf3ec65c8c1778681b6c alembic/versions/f9e369bf00d_added_spin_type_cons.py PRE-CREATION alembic/versions/3b0500a49ea7_added_api_key_hash_t.py PRE-CREATION alembic/versions/1162fb4d4358_added_build_table.py PRE-CREATION Diff: http://reviewboard-tflink.rhcloud.com/r/46/diff/ Testing --- I've tested on my develop instance. Thanks, Ilgiz Islamgulov ___ qa-devel mailing list qa-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/qa-devel
Re: Project take up:Infrastructure-Search
On Sun, 22 Sep 2013 22:33:35 +0300 Frankie Onuonga frankie.onuo...@gmail.com wrote: Hi guys, hey. I am looking to take up a project that i saw had been left idle for sometime. The project URL is:https://fedoraproject.org/wiki/Infrastructure/Search I said in sometime because of what is listed at:https://fedorahosted.org/fedora-infrastructure/ticket/1055 If this is possible, kindly do advice. I am sure I can make sometime for it as I am only currently involved actively in one other project withing the whole eco-system. Well, this would be more for the infrastructure list rather than the devel list, but yes, you can absolutely help. Probably the best way forward would be to spin you up a cloud instance and get dpsearch setup on it and crawl one part of our infrastructure, say docs or wiki. Then, we could see how resources work out and if the search is effective. Of course if you want to go with a different search engine, we should discuss that on the infrastructure list. kevin signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: [HEADSUP] Atlas changed libraries - arm failures
On 09/23/2013 08:15 AM, Frantisek Kluknavsky wrote: For the record: atlas-3.10.1-1.fc21.armv7hl.rpm is available. I do not have any Arm machine to test except the Fedora builders, any feedback is welcome. All of my atlas using packages are segfaulting on arm. I added a %check section to the atlas package to run the atlas sanity checks and they are segfaulting on arm as well. New build running here: http://koji.fedoraproject.org/koji/taskinfo?taskID=5973628 which should fail shortly. -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA, Boulder/CoRA Office FAX: 303-415-9702 3380 Mitchell Lane or...@nwra.com Boulder, CO 80301 http://www.nwra.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Intent to retire python-jinja
Hi, On Tue, Sep 17, 2013 at 11:10 AM, Thomas Moschny thomas.mosc...@gmail.com wrote: I'd like to retire the python-jinja package, containing the Jinja1 template engine, which has been superseded by Jinja2 for a very long time. Jinja2 is packaged as python-jinja2 in Fedora. However, there's one package left that depends on it: olpc-library. Can anyone comment on the status of that package, and if it would be possible to switch over to Jinja2? olpc-library just got obsoleted (nothing uses it now, the functionality got moved elsewhere), so if you could point me at how to drop this package from rawhide I will get it out of your way. Thanks Daniel -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: [HEADSUP] Atlas changed libraries
On 09/23/2013 08:46 AM, Susi Lehtola wrote: On Mon, 23 Sep 2013 14:34:50 +0200 Kevin Kofler kevin.kof...@chello.at wrote: Matthew Miller wrote: Actually, what ATLAS upstream intends is for the program to be recompiled on every installation (or boot, even). I think we used to have packages that did that; this is a compromise. Yes, ATLAS upstream has always been smoking deep crack. It looks like OpenBLAS is the much better option, now that it is available. (ATLAS used to be the best available as Free Software back when GotoBLAS was still proprietary, but now that the Goto code has been freed, ATLAS is not looking so great anymore.) Well, it's not too hard to understand why ATLAS does things the way it does. It's already in the acronym: Automatically Tuned Linear Algebra Software. You generate a library that is optimal for your processor. In comparison, GotoBLAS (OpenBLAS) has been hand-tuned in assembly for every supported CPU. On the other hand, I'm not sure why they don't just take their tool and pregenerate lists of optimal parameters for every available CPU. That way you could compile everything in the same package and do runtime CPU detection. Currently binary distributions have to do some hackaround to generate a reasonably efficient one-size-fits-all library. They can't cover every combination of CPU microarchitecture/cache sizes and main memory configuration and speed. It can't even be a per-motherboard configuration, because one could put in different speed DIMMs. and in principle that could change the optimal ATLAS setup. Recompiling it at every boot is a little extreme, though, albeit in principle someone could change the memory between boots. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: mc alternative: Double Commander
On Mon, 23 Sep 2013 10:59:55 +0200 Vít Ondruch wrote: Dne 22.9.2013 10:32, Martin Sourada napsal(a): Point me to such graphical filemanager. I fail to see even a decent gui alternative to mc under linux. You can try Double Commander if you like. I'd expect much less wasted space in a good mc alternative, but thanks for the pointer, I'll give it a spin when I have some spare time :) Martin signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
File CPAN-Meta-YAML-0.010.tar.gz uploaded to lookaside cache by pghmcfc
A file has been added to the lookaside cache for perl-CPAN-Meta-YAML: 5e2efc852f9ad3d01496fa9ccdc9dc3a CPAN-Meta-YAML-0.010.tar.gz -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Re: [HEADSUP] Atlas changed libraries
On 09/23/2013 08:02 PM, Kevin Kofler wrote: Of course, this means that it is a very poor choice for our de-facto default LAPACK/BLAS. (Only the reference implementation is worse. Yet, we build some stuff even against that!) I'd suggest filing a Change to make OpenBLAS the default for F21 (when hopefully the armv7 port will also be usable, so all our primary architectures, even the silly one, will be covered) and working on building everything in the distribution that uses LAPACK and/or BLAS against it. Even if we keep the other BLAS/LAPACK implementations around, the target should be that everything in the distro uses OpenBLAS, similarly to how we made spellchecking use Hunspell throughout the distro (see https://fedoraproject.org/wiki/Releases/FeatureDictionary). (I take it that in this case, the application code should normally not need adjustments, so this should be even easier than FeatureDictionary, and not end in a fiasco such as the failed attempt at standardizing cryptography on NSS.) Kevin Kofler People with interest in secondary architectures might oppose that. Perhabs if we ensure binary compatibility then we can make them freely interchangeable. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
[perl-CPAN-Meta-YAML] Update to 0.010
commit 0d23f9b5b3b0e50bdfb58ab6ccda108c47810e52
Author: Paul Howarth p...@city-fan.org
Date: Mon Sep 23 22:02:17 2013 +0100
Update to 0.010
- New upstream release 0.010:
- Generated from ETHER/YAML-Tiny-1.55.tar.gz
- Makefile.PL will use UNINST=1 on old perls that might have an old
version
incorrectly installed into the core library path
- Updated Makefile.PL logic to support PERL_NO_HIGHLANDER
- Drop redundant BRs: perl(Pod::Wordlist::hanekomu), perl(Test::Requires),
perl(Test::Spelling) and aspell-en
- Add new test dependencies perl(IO::Handle) and perl(IPC::Open3)
- Build with UNINST=0 to avoid build failures as we can't remove the system
version of the package when building an rpm for a new version
- Update patch for building with old Test::More, and add new patch to
support
building with Test::More 0.94
- Don't run the extra tests in EPEL as we don't have Test::Version there
CPAN-Meta-YAML-0.006-old-Test::More.patch | 10 -
CPAN-Meta-YAML-0.009-TM094.patch | 16 +
CPAN-Meta-YAML-0.009-old-Test::More.patch | 10 +
perl-CPAN-Meta-YAML.spec | 53 ++---
sources |2 +-
5 files changed, 60 insertions(+), 31 deletions(-)
---
diff --git a/CPAN-Meta-YAML-0.009-TM094.patch b/CPAN-Meta-YAML-0.009-TM094.patch
new file mode 100644
index 000..0a4c425
--- /dev/null
+++ b/CPAN-Meta-YAML-0.009-TM094.patch
@@ -0,0 +1,16 @@
+--- t/00-compile.t
t/00-compile.t
+@@ -3,7 +3,7 @@
+
+ # this test was generated with Dist::Zilla::Plugin::Test::Compile 2.030
+
+-use Test::More 0.94 tests = 1 + ($ENV{AUTHOR_TESTING} ? 1 : 0);
++use Test::More 0.47 tests = 1 + ($ENV{AUTHOR_TESTING} ? 1 : 0);
+
+
+
+@@ -41,4 +41,3 @@
+
+ is(scalar(@warnings), 0, 'no warnings found') if $ENV{AUTHOR_TESTING};
+
+-BAIL_OUT(Compilation problems) if !Test::More-builder-is_passing;
diff --git a/CPAN-Meta-YAML-0.009-old-Test::More.patch
b/CPAN-Meta-YAML-0.009-old-Test::More.patch
new file mode 100644
index 000..18add0e
--- /dev/null
+++ b/CPAN-Meta-YAML-0.009-old-Test::More.patch
@@ -0,0 +1,10 @@
+--- xt/release/test-version.t
xt/release/test-version.t
+@@ -18,5 +18,5 @@ push @imports, $params
+
+ Test::Version-import(@imports);
+
+-version_all_ok;
+-done_testing;
++plan tests = 2;
++version_all_ok();
diff --git a/perl-CPAN-Meta-YAML.spec b/perl-CPAN-Meta-YAML.spec
index d3fa3fc..85adb4d 100644
--- a/perl-CPAN-Meta-YAML.spec
+++ b/perl-CPAN-Meta-YAML.spec
@@ -1,15 +1,17 @@
-# We need to patch the test suite if we have Test::More 0.88
+# We need to patch the test suite if we have Test::More 0.94
+%global quite_old_test_more %(perl -MTest::More -e 'print
(($Test::More::VERSION 0.94) ? 1 : 0);' 2/dev/null || echo 0)
%global old_test_more %(perl -MTest::More -e 'print (($Test::More::VERSION
0.88) ? 1 : 0);' 2/dev/null || echo 0)
Name: perl-CPAN-Meta-YAML
-Version: 0.008
-Release: 292%{?dist}
+Version: 0.010
+Release: 1%{?dist}
Summary: Read and write a subset of YAML for CPAN Meta files
License: GPL+ or Artistic
Group: Development/Libraries
URL: http://search.cpan.org/dist/CPAN-Meta-YAML/
Source0:
http://search.cpan.org/CPAN/authors/id/D/DA/DAGOLDEN/CPAN-Meta-YAML-%{version}.tar.gz
-Patch1:CPAN-Meta-YAML-0.006-old-Test::More.patch
+Patch0:CPAN-Meta-YAML-0.009-TM094.patch
+Patch1:CPAN-Meta-YAML-0.009-old-Test::More.patch
BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(id -nu)
BuildArch: noarch
BuildRequires: perl(Carp)
@@ -17,29 +19,20 @@ BuildRequires: perl(Exporter)
BuildRequires: perl(ExtUtils::MakeMaker)
BuildRequires: perl(File::Spec)
# Tests:
+BuildRequires: perl(IO::Handle)
+BuildRequires: perl(IPC::Open3)
BuildRequires: perl(File::Spec::Functions)
BuildRequires: perl(File::Temp)
BuildRequires: perl(Test::More)
BuildRequires: perl(YAML)
# Don't run extra tests when bootstrapping as many of those
# tests' dependencies build-require this package
-%if 0%{!?perl_bootstrap:1}
-# RHEL-7 package cannot have buildreqs from EPEL-7 (aspell-en,
Pod::Wordlist::hanekomu),
-# so skip the spell check there
-%if 0%{?rhel} 7
-# Version 1.113620 needed for UTF
-BuildRequires: perl(Pod::Wordlist::hanekomu) = 1.113620
-BuildRequires: perl(Test::Spelling), aspell-en
-%endif
+%if 0%{?fedora} 0%{!?perl_bootstrap:1}
BuildRequires: perl(Test::CPAN::Meta)
BuildRequires: perl(Test::Pod)
BuildRequires: perl(Test::Requires)
-# RHEL ≤ 6 doesn't have a recent enough perl(version) for perl(Test::Version)
in EPEL
-# RHEL ≥ 7 includes this package but does not have perl(Test::Version)
-%if 0%{?fedora}
BuildRequires: perl(Test::Version)
%endif
-%endif
Requires: perl(:MODULE_COMPAT_%(eval `perl -V:version`; echo $version))
Requires: perl(Carp)
Requires: perl(Exporter)
@@
Re: devel Digest, Vol 115, Issue 94
Greetings testers! It's meeting time again on Monday! Alpha is now done and ready to go, but we may have a few more things to do to prepare for it, and it's time to look ahead to Beta as well. 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/20130923 The current proposed agenda is included below. == Proposed Agenda Topics == 1. Previous meeting follow-up 2. Fedora 20 Alpha final work and retrospective 3. Fedora 20 Beta planning 4. Open floor I would like to propose a more guided partitioning gui for anaconda. One that warns you if deleting a partition may damage the current OS on the box, not just a generic warning. This is because many inexperienced people who I recommend fedora to tend to delete their windows partitions unknowingly. I believe I will be not be able to make the meeting. Regards -Absal0m -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Screen blackened
On Sep 23, 2013 5:19 AM, Ville Skyttä ville.sky...@iki.fi wrote: On Sat, Sep 7, 2013 at 6:49 AM, David Beveridge d...@bevhost.com wrote: On Sat, Sep 7, 2013 at 12:18 AM, Richard Vickery richard.vicker...@gmail.com wrote: On Sep 5, 2013 7:12 PM, David Beveridge d...@bevhost.com wrote: nor me. But I can just adjust the brightness on each boot with a 2 finger keypress. Seemed to appear when the kernel went to 3.10.x Which keys? fn - F6 (more brightness symbol) FWIW looks like the kernel 3.11.1 update fixed this for me (ASUS N56VZ). -- When going to update via fed up, it's asking me to specify an --instrepo: what does it want? Which one / how do I specify one? -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Screen blackened
On Sep 23, 2013 7:52 PM, Richard Vickery richard.vicker...@gmail.com wrote: On Sep 23, 2013 5:19 AM, Ville Skyttä ville.sky...@iki.fi wrote: On Sat, Sep 7, 2013 at 6:49 AM, David Beveridge d...@bevhost.com wrote: On Sat, Sep 7, 2013 at 12:18 AM, Richard Vickery richard.vicker...@gmail.com wrote: On Sep 5, 2013 7:12 PM, David Beveridge d...@bevhost.com wrote: nor me. But I can just adjust the brightness on each boot with a 2 finger keypress. Seemed to appear when the kernel went to 3.10.x Which keys? fn - F6 (more brightness symbol) FWIW looks like the kernel 3.11.1 update fixed this for me (ASUS N56VZ). -- When going to update via fed up, it's asking me to specify an --instrepo: what does it want? Which one / how do I specify one? I still have a blackened screen, but have an external monitor plugged in. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Screen blackened
On 09/23/2013 06:18 AM, Ville Skyttä wrote: FWIW looks like the kernel 3.11.1 update fixed this for me (ASUS N56VZ). I think it fixed it for me as well. Asus K56CA. It flickers but at least I don't have to adjust the brightness to unlock the screen. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
[Bug 1010057] `perldoc perldoc`: No documentation found for perldoc.
https://bugzilla.redhat.com/show_bug.cgi?id=1010057 Petr Pisar ppi...@redhat.com changed: What|Removed |Added External Bug ID||CPAN 88898 --- Comment #1 from Petr Pisar ppi...@redhat.com --- You can use `perldoc Pod::perldoc'. This is upstream change since version 3.17. I raised a question if this is intended behaviour https://rt.cpan.org/Public/Bug/Display.html?id=88898. -- You are receiving this mail because: You are on the CC list for the bug. Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=IEbDDsnFjVa=cc_unsubscribe -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 1010057] `perldoc perldoc`: No documentation found for perldoc.
https://bugzilla.redhat.com/show_bug.cgi?id=1010057 --- Comment #2 from Petr Pisar ppi...@redhat.com --- And of course the classic `man perldoc' works. -- You are receiving this mail because: You are on the CC list for the bug. Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=slA3zQYRDQa=cc_unsubscribe -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 1010911] New: perl-autodie-2.22 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1010911 Bug ID: 1010911 Summary: perl-autodie-2.22 is available Product: Fedora Version: rawhide Component: perl-autodie Keywords: FutureFeature, Triaged Assignee: ppi...@redhat.com Reporter: upstream-release-monitor...@fedoraproject.org QA Contact: extras...@fedoraproject.org CC: perl-devel@lists.fedoraproject.org, ppi...@redhat.com Latest upstream release: 2.22 Current version/release in Fedora Rawhide: 2.21-1.fc21 URL: http://search.cpan.org/dist/autodie/ Please consult the package updates policy before you issue an update to a stable branch: https://fedoraproject.org/wiki/Updates_Policy More information about the service that created this bug can be found at: https://fedoraproject.org/wiki/Upstream_release_monitoring -- You are receiving this mail because: You are on the CC list for the bug. Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=j7o1mxmh1qa=cc_unsubscribe -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 1010912] New: perl-DateTime-TimeZone-1.61 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1010912 Bug ID: 1010912 Summary: perl-DateTime-TimeZone-1.61 is available Product: Fedora Version: rawhide Component: perl-DateTime-TimeZone Keywords: FutureFeature, Triaged Assignee: iarn...@gmail.com Reporter: upstream-release-monitor...@fedoraproject.org QA Contact: extras...@fedoraproject.org CC: iarn...@gmail.com, perl-devel@lists.fedoraproject.org Latest upstream release: 1.61 Current version/release in Fedora Rawhide: 1.60-2.fc20 URL: http://search.cpan.org/dist/DateTime-TimeZone/ Please consult the package updates policy before you issue an update to a stable branch: https://fedoraproject.org/wiki/Updates_Policy More information about the service that created this bug can be found at: https://fedoraproject.org/wiki/Upstream_release_monitoring -- You are receiving this mail because: You are on the CC list for the bug. Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=TJshpJqOF1a=cc_unsubscribe -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 1010914] New: perl-Devel-CallParser-0.002 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1010914 Bug ID: 1010914 Summary: perl-Devel-CallParser-0.002 is available Product: Fedora Version: rawhide Component: perl-Devel-CallParser Keywords: FutureFeature, Triaged Assignee: jples...@redhat.com Reporter: upstream-release-monitor...@fedoraproject.org QA Contact: extras...@fedoraproject.org CC: jples...@redhat.com, mmasl...@redhat.com, perl-devel@lists.fedoraproject.org Latest upstream release: 0.002 Current version/release in Fedora Rawhide: 0.001-6.fc20 URL: http://search.cpan.org/dist/Devel-CallParser/ Please consult the package updates policy before you issue an update to a stable branch: https://fedoraproject.org/wiki/Updates_Policy More information about the service that created this bug can be found at: https://fedoraproject.org/wiki/Upstream_release_monitoring -- You are receiving this mail because: You are on the CC list for the bug. Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=vc2Hg2j71Na=cc_unsubscribe -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 1010913] New: perl-Devel-CallChecker-0.006 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1010913 Bug ID: 1010913 Summary: perl-Devel-CallChecker-0.006 is available Product: Fedora Version: rawhide Component: perl-Devel-CallChecker Keywords: FutureFeature, Triaged Assignee: ppi...@redhat.com Reporter: upstream-release-monitor...@fedoraproject.org QA Contact: extras...@fedoraproject.org CC: mmasl...@redhat.com, perl-devel@lists.fedoraproject.org, ppi...@redhat.com Latest upstream release: 0.006 Current version/release in Fedora Rawhide: 0.005-6.fc20 URL: http://search.cpan.org/dist/Devel-CallChecker/ Please consult the package updates policy before you issue an update to a stable branch: https://fedoraproject.org/wiki/Updates_Policy More information about the service that created this bug can be found at: https://fedoraproject.org/wiki/Upstream_release_monitoring -- You are receiving this mail because: You are on the CC list for the bug. Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=3EJKbjsWZJa=cc_unsubscribe -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 1010918] New: perl-Pod-Checker-1.70 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1010918 Bug ID: 1010918 Summary: perl-Pod-Checker-1.70 is available Product: Fedora Version: rawhide Component: perl-Pod-Checker Keywords: FutureFeature, Triaged Assignee: ppi...@redhat.com Reporter: upstream-release-monitor...@fedoraproject.org QA Contact: extras...@fedoraproject.org CC: perl-devel@lists.fedoraproject.org, ppi...@redhat.com Latest upstream release: 1.70 Current version/release in Fedora Rawhide: 1.60-291.fc20 URL: http://search.cpan.org/dist/Pod-Checker/ Please consult the package updates policy before you issue an update to a stable branch: https://fedoraproject.org/wiki/Updates_Policy More information about the service that created this bug can be found at: https://fedoraproject.org/wiki/Upstream_release_monitoring -- You are receiving this mail because: You are on the CC list for the bug. Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=VLKqDiwAo0a=cc_unsubscribe -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 1010919] New: perl-podlators-2.5.2 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1010919 Bug ID: 1010919 Summary: perl-podlators-2.5.2 is available Product: Fedora Version: rawhide Component: perl-podlators Keywords: FutureFeature, Triaged Assignee: ppi...@redhat.com Reporter: upstream-release-monitor...@fedoraproject.org QA Contact: extras...@fedoraproject.org CC: perl-devel@lists.fedoraproject.org, ppi...@redhat.com Latest upstream release: 2.5.2 Current version/release in Fedora Rawhide: 2.5.1-291.fc20 URL: http://search.cpan.org/dist/podlators/ Please consult the package updates policy before you issue an update to a stable branch: https://fedoraproject.org/wiki/Updates_Policy More information about the service that created this bug can be found at: https://fedoraproject.org/wiki/Upstream_release_monitoring -- You are receiving this mail because: You are on the CC list for the bug. Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=uGOqzSsHyRa=cc_unsubscribe -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
File podlators-2.5.2.tar.gz uploaded to lookaside cache by ppisar
A file has been added to the lookaside cache for perl-podlators: debcce4412596dc1301c0df8c86415cf podlators-2.5.2.tar.gz -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 1010921] New: perl-Template-Alloy-1.020 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1010921 Bug ID: 1010921 Summary: perl-Template-Alloy-1.020 is available Product: Fedora Version: rawhide Component: perl-Template-Alloy Keywords: FutureFeature, Triaged Assignee: ppi...@redhat.com Reporter: upstream-release-monitor...@fedoraproject.org QA Contact: extras...@fedoraproject.org CC: mmasl...@redhat.com, perl-devel@lists.fedoraproject.org, ppi...@redhat.com, psab...@redhat.com Latest upstream release: 1.020 Current version/release in Fedora Rawhide: 1.019-1.fc21 URL: http://search.cpan.org/dist/Template-Alloy/ Please consult the package updates policy before you issue an update to a stable branch: https://fedoraproject.org/wiki/Updates_Policy More information about the service that created this bug can be found at: https://fedoraproject.org/wiki/Upstream_release_monitoring -- You are receiving this mail because: You are on the CC list for the bug. Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=Ol5M7lgjM1a=cc_unsubscribe -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 1010057] `perldoc perldoc`: No documentation found for perldoc.
https://bugzilla.redhat.com/show_bug.cgi?id=1010057 --- Comment #3 from Vadim Raskhozhev iamde...@gmail.com --- I raised a question if this is intended behaviour https://rt.cpan.org/Public/Bug/Display.html?id=88898. Thanks. IMHO if this is intended then the line 'Also try perldoc perldoc to get acquainted with the system.' in output of `perldoc' should somehow point to `perldoc Pod::perldoc', `man perldoc' or so. -- You are receiving this mail because: You are on the CC list for the bug. Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=5wZDqZrTeGa=cc_unsubscribe -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Broken dependencies: perl-MooseX-TrackDirty-Attributes
perl-MooseX-TrackDirty-Attributes has broken dependencies in the F-20 tree: On x86_64: perl-MooseX-TrackDirty-Attributes-2.002-2.fc19.noarch requires perl(:MODULE_COMPAT_5.16.2) On i386: perl-MooseX-TrackDirty-Attributes-2.002-2.fc19.noarch requires perl(:MODULE_COMPAT_5.16.2) On armhfp: perl-MooseX-TrackDirty-Attributes-2.002-2.fc19.noarch requires perl(:MODULE_COMPAT_5.16.2) Please resolve this as soon as possible. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Broken dependencies: perl-MIME-Lite-HTML
perl-MIME-Lite-HTML has broken dependencies in the F-20 tree: On x86_64: perl-MIME-Lite-HTML-1.24-4.fc18.noarch requires perl(:MODULE_COMPAT_5.16.0) On i386: perl-MIME-Lite-HTML-1.24-4.fc18.noarch requires perl(:MODULE_COMPAT_5.16.0) On armhfp: perl-MIME-Lite-HTML-1.24-4.fc18.noarch requires perl(:MODULE_COMPAT_5.16.0) Please resolve this as soon as possible. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Broken dependencies: perl-Unix-Statgrab
perl-Unix-Statgrab has broken dependencies in the F-20 tree: On x86_64: perl-Unix-Statgrab-0.04-20.fc20.x86_64 requires libstatgrab.so.6()(64bit) On i386: perl-Unix-Statgrab-0.04-20.fc20.i686 requires libstatgrab.so.6 On armhfp: perl-Unix-Statgrab-0.04-20.fc20.armv7hl requires libstatgrab.so.6 Please resolve this as soon as possible. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Broken dependencies: perl-Padre
perl-Padre has broken dependencies in the F-20 tree: On x86_64: perl-Padre-0.90-6.fc18.noarch requires perl(:MODULE_COMPAT_5.16.0) On i386: perl-Padre-0.90-6.fc18.noarch requires perl(:MODULE_COMPAT_5.16.0) On armhfp: perl-Padre-0.90-6.fc18.noarch requires perl(:MODULE_COMPAT_5.16.0) Please resolve this as soon as possible. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Broken dependencies: slic3r
slic3r has broken dependencies in the F-20 tree: On x86_64: slic3r-0.9.10b-2.fc20.noarch requires perl(:MODULE_COMPAT_5.16.3) On i386: slic3r-0.9.10b-2.fc20.noarch requires perl(:MODULE_COMPAT_5.16.3) On armhfp: slic3r-0.9.10b-2.fc20.noarch requires perl(:MODULE_COMPAT_5.16.3) Please resolve this as soon as possible. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Broken dependencies: perl-PDL
perl-PDL has broken dependencies in the F-20 tree: On x86_64: perl-PDL-2.4.10-6.fc19.x86_64 requires perl(:MODULE_COMPAT_5.16.2) perl-PDL-2.4.10-6.fc19.x86_64 requires libgd.so.2()(64bit) On i386: perl-PDL-2.4.10-6.fc19.i686 requires perl(:MODULE_COMPAT_5.16.2) perl-PDL-2.4.10-6.fc19.i686 requires libgd.so.2 Please resolve this as soon as possible. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Broken dependencies: perl-Language-Expr
perl-Language-Expr has broken dependencies in the F-20 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: perl-Language-Expr-0.19-4.fc19.noarch requires perl(:MODULE_COMPAT_5.16.2) Please resolve this as soon as possible. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
File autodie-2.22.tar.gz uploaded to lookaside cache by ppisar
A file has been added to the lookaside cache for perl-autodie: 2930d449fb94b0f8743cf689c7fa1752 autodie-2.22.tar.gz -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-autodie] 2.22 bump
commit 06daae030a49df891f8b64fe0642734dcfb8d934
Author: Petr Písař ppi...@redhat.com
Date: Mon Sep 23 13:53:48 2013 +0200
2.22 bump
.gitignore|1 +
perl-autodie.spec |5 -
sources |2 +-
3 files changed, 6 insertions(+), 2 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index d3deac5..64d507c 100644
--- a/.gitignore
+++ b/.gitignore
@@ -2,3 +2,4 @@
/autodie-2.16.tar.gz
/autodie-2.20.tar.gz
/autodie-2.21.tar.gz
+/autodie-2.22.tar.gz
diff --git a/perl-autodie.spec b/perl-autodie.spec
index cd2ba07..2f162fc 100644
--- a/perl-autodie.spec
+++ b/perl-autodie.spec
@@ -1,5 +1,5 @@
Name: perl-autodie
-Version:2.21
+Version:2.22
Release:1%{?dist}
Summary:Replace functions with ones that succeed or die
License:GPL+ or Artistic
@@ -82,6 +82,9 @@ make test
%{_mandir}/man3/*
%changelog
+* Mon Sep 23 2013 Petr Pisar ppi...@redhat.com - 2.22-1
+- 2.22 bump
+
* Thu Sep 12 2013 Petr Pisar ppi...@redhat.com - 2.21-1
- 2.21 bump
diff --git a/sources b/sources
index 010633b..6c2c14f 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-144b6f8335e98ecbb14267ebd59f69b1 autodie-2.21.tar.gz
+2930d449fb94b0f8743cf689c7fa1752 autodie-2.22.tar.gz
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 1010911] perl-autodie-2.22 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1010911 Petr Pisar ppi...@redhat.com changed: What|Removed |Added Status|ASSIGNED|CLOSED Fixed In Version||perl-autodie-2.22-1.fc21 Resolution|--- |RAWHIDE Last Closed||2013-09-23 08:05:23 -- You are receiving this mail because: You are on the CC list for the bug. Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=3GEh2aVs18a=cc_unsubscribe -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
File Devel-CallChecker-0.006.tar.gz uploaded to lookaside cache by ppisar
A file has been added to the lookaside cache for perl-Devel-CallChecker: 4e8fc69527f2d80e4873f2264c8a0830 Devel-CallChecker-0.006.tar.gz -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-Devel-CallChecker] 0.006 bump
commit f0de3940d6bbd289756ab6eefc75d62d1c571aee
Author: Petr Písař ppi...@redhat.com
Date: Mon Sep 23 14:13:05 2013 +0200
0.006 bump
.gitignore |1 +
perl-Devel-CallChecker.spec | 24 ++--
sources |2 +-
3 files changed, 16 insertions(+), 11 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index 4ad46f6..5f6c663 100644
--- a/.gitignore
+++ b/.gitignore
@@ -1,3 +1,4 @@
/Devel-CallChecker-0.003.tar.gz
/Devel-CallChecker-0.004.tar.gz
/Devel-CallChecker-0.005.tar.gz
+/Devel-CallChecker-0.006.tar.gz
diff --git a/perl-Devel-CallChecker.spec b/perl-Devel-CallChecker.spec
index 7e88a6d..b6ca485 100644
--- a/perl-Devel-CallChecker.spec
+++ b/perl-Devel-CallChecker.spec
@@ -1,36 +1,36 @@
# This file is licensed under the terms of GNU GPLv2+.
Name: perl-Devel-CallChecker
-Version:0.005
-Release:6%{?dist}
+Version:0.006
+Release:1%{?dist}
Summary:Custom op checking attached to subroutines
License:GPL+ or Artistic
Group: Development/Libraries
URL:http://search.cpan.org/dist/Devel-CallChecker/
Source0:
http://www.cpan.org/authors/id/Z/ZE/ZEFRAM/Devel-CallChecker-%{version}.tar.gz
+BuildRequires: perl
BuildRequires: perl(Module::Build)
+BuildRequires: perl(strict)
+BuildRequires: perl(warnings)
# Run-time
BuildRequires: perl(DynaLoader)
BuildRequires: perl(DynaLoader::Functions) = 0.001
BuildRequires: perl(Exporter)
-BuildRequires: perl(IO::File) = 1.03
BuildRequires: perl(parent)
# Tests
BuildRequires: perl(ExtUtils::CBuilder) = 0.15
BuildRequires: perl(ExtUtils::ParseXS)
BuildRequires: perl(File::Spec)
+BuildRequires: perl(IO::File) = 1.03
BuildRequires: perl(Test::More)
# Optional tests
BuildRequires: perl(Test::Pod) = 1.00
BuildRequires: perl(Test::Pod::Coverage)
BuildRequires: perl(threads)
+BuildRequires: perl(threads::shared)
BuildRequires: perl(Thread::Semaphore)
-# XXX: This package stores build-time Perl version and checks it at run-time.
-# This package must be recompiled on each Perl upgrade. See bug #754159.
-Requires: perl(:MODULE_COMPAT_%(eval `%{__perl} -V:version`; echo
$version))
+Requires: perl(:MODULE_COMPAT_%(eval `perl -V:version`; echo $version))
Requires: perl(DynaLoader)
Requires: perl(DynaLoader::Functions) = 0.001
-Requires: perl(Exporter)
-Requires: perl(IO::File) = 1.03
%{?perl_default_filter}
@@ -49,13 +49,12 @@ without the centralized facility.)
%setup -q -n Devel-CallChecker-%{version}
%build
-%{__perl} Build.PL installdirs=vendor optimize=$RPM_OPT_FLAGS
+perl Build.PL installdirs=vendor optimize=$RPM_OPT_FLAGS
./Build
%install
./Build install destdir=$RPM_BUILD_ROOT create_packlist=0
find $RPM_BUILD_ROOT -type f -name '*.bs' -size 0 -exec rm -f {} \;
-find $RPM_BUILD_ROOT -depth -type d -exec rmdir {} 2/dev/null \;
%{_fixperms} $RPM_BUILD_ROOT/*
%check
@@ -68,6 +67,11 @@ find $RPM_BUILD_ROOT -depth -type d -exec rmdir {}
2/dev/null \;
%{_mandir}/man3/*
%changelog
+* Mon Sep 23 2013 Petr Pisar ppi...@redhat.com - 0.006-1
+- 0.006 bump
+- This version should be compatible with any binary compatible perl version
+ (bug #754159)
+
* Sat Aug 03 2013 Fedora Release Engineering rel-...@lists.fedoraproject.org
- 0.005-6
- Rebuilt for https://fedoraproject.org/wiki/Fedora_20_Mass_Rebuild
diff --git a/sources b/sources
index 15fe5fb..f81a727 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-2e55804221eaa5fdf2e32749b72e74f2 Devel-CallChecker-0.005.tar.gz
+4e8fc69527f2d80e4873f2264c8a0830 Devel-CallChecker-0.006.tar.gz
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-Devel-CallChecker/f20] 0.006 bump
Summary of changes: f0de394... 0.006 bump (*) (*) This commit already existed in another branch; no separate mail sent -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 1010913] perl-Devel-CallChecker-0.006 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1010913 --- Comment #1 from Petr Pisar ppi...@redhat.com --- This is a bug-fix release suitable for all Fedoras. -- You are receiving this mail because: You are on the CC list for the bug. Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=Six43yuLG2a=cc_unsubscribe -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-Devel-CallChecker/f18] 0.006 bump
commit b5e087688821fefd3375bdd59fcb33619f9fc887
Author: Petr Písař ppi...@redhat.com
Date: Mon Sep 23 14:13:05 2013 +0200
0.006 bump
.gitignore |1 +
perl-Devel-CallChecker.spec | 24 ++--
sources |2 +-
3 files changed, 16 insertions(+), 11 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index 4ad46f6..5f6c663 100644
--- a/.gitignore
+++ b/.gitignore
@@ -1,3 +1,4 @@
/Devel-CallChecker-0.003.tar.gz
/Devel-CallChecker-0.004.tar.gz
/Devel-CallChecker-0.005.tar.gz
+/Devel-CallChecker-0.006.tar.gz
diff --git a/perl-Devel-CallChecker.spec b/perl-Devel-CallChecker.spec
index fc0095c..0049cc7 100644
--- a/perl-Devel-CallChecker.spec
+++ b/perl-Devel-CallChecker.spec
@@ -1,36 +1,36 @@
# This file is licensed under the terms of GNU GPLv2+.
Name: perl-Devel-CallChecker
-Version:0.005
-Release:3%{?dist}
+Version:0.006
+Release:1%{?dist}
Summary:Custom op checking attached to subroutines
License:GPL+ or Artistic
Group: Development/Libraries
URL:http://search.cpan.org/dist/Devel-CallChecker/
Source0:
http://www.cpan.org/authors/id/Z/ZE/ZEFRAM/Devel-CallChecker-%{version}.tar.gz
+BuildRequires: perl
BuildRequires: perl(Module::Build)
+BuildRequires: perl(strict)
+BuildRequires: perl(warnings)
# Run-time
BuildRequires: perl(DynaLoader)
BuildRequires: perl(DynaLoader::Functions) = 0.001
BuildRequires: perl(Exporter)
-BuildRequires: perl(IO::File) = 1.03
BuildRequires: perl(parent)
# Tests
BuildRequires: perl(ExtUtils::CBuilder) = 0.15
BuildRequires: perl(ExtUtils::ParseXS)
BuildRequires: perl(File::Spec)
+BuildRequires: perl(IO::File) = 1.03
BuildRequires: perl(Test::More)
# Optional tests
BuildRequires: perl(Test::Pod) = 1.00
BuildRequires: perl(Test::Pod::Coverage)
BuildRequires: perl(threads)
+BuildRequires: perl(threads::shared)
BuildRequires: perl(Thread::Semaphore)
-# XXX: This package stores build-time Perl version and checks it at run-time.
-# This package must be recompiled on each Perl upgrade. See bug #754159.
-Requires: perl(:MODULE_COMPAT_%(eval `%{__perl} -V:version`; echo
$version))
+Requires: perl(:MODULE_COMPAT_%(eval `perl -V:version`; echo $version))
Requires: perl(DynaLoader)
Requires: perl(DynaLoader::Functions) = 0.001
-Requires: perl(Exporter)
-Requires: perl(IO::File) = 1.03
%{?perl_default_filter}
@@ -49,13 +49,12 @@ without the centralized facility.)
%setup -q -n Devel-CallChecker-%{version}
%build
-%{__perl} Build.PL installdirs=vendor optimize=$RPM_OPT_FLAGS
+perl Build.PL installdirs=vendor optimize=$RPM_OPT_FLAGS
./Build
%install
./Build install destdir=$RPM_BUILD_ROOT create_packlist=0
find $RPM_BUILD_ROOT -type f -name '*.bs' -size 0 -exec rm -f {} \;
-find $RPM_BUILD_ROOT -depth -type d -exec rmdir {} 2/dev/null \;
%{_fixperms} $RPM_BUILD_ROOT/*
%check
@@ -68,6 +67,11 @@ find $RPM_BUILD_ROOT -depth -type d -exec rmdir {}
2/dev/null \;
%{_mandir}/man3/*
%changelog
+* Mon Sep 23 2013 Petr Pisar ppi...@redhat.com - 0.006-1
+- 0.006 bump
+- This version should be compatible with any binary compatible perl version
+ (bug #754159)
+
* Fri Jul 20 2012 Fedora Release Engineering rel-...@lists.fedoraproject.org
- 0.005-3
- Rebuilt for https://fedoraproject.org/wiki/Fedora_18_Mass_Rebuild
diff --git a/sources b/sources
index 15fe5fb..f81a727 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-2e55804221eaa5fdf2e32749b72e74f2 Devel-CallChecker-0.005.tar.gz
+4e8fc69527f2d80e4873f2264c8a0830 Devel-CallChecker-0.006.tar.gz
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 1010913] perl-Devel-CallChecker-0.006 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1010913 Petr Pisar ppi...@redhat.com changed: What|Removed |Added Status|ASSIGNED|MODIFIED Fixed In Version||perl-Devel-CallChecker-0.00 ||6-1.fc21 -- You are receiving this mail because: You are on the CC list for the bug. Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=k34JsP2eOBa=cc_unsubscribe -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 1010913] perl-Devel-CallChecker-0.006 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1010913 --- Comment #2 from Fedora Update System upda...@fedoraproject.org --- perl-Devel-CallChecker-0.006-1.fc20 has been submitted as an update for Fedora 20. https://admin.fedoraproject.org/updates/perl-Devel-CallChecker-0.006-1.fc20 -- You are receiving this mail because: You are on the CC list for the bug. Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=tavLhJuJFua=cc_unsubscribe -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 1010913] perl-Devel-CallChecker-0.006 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1010913 --- Comment #3 from Fedora Update System upda...@fedoraproject.org --- perl-Devel-CallChecker-0.006-1.fc19 has been submitted as an update for Fedora 19. https://admin.fedoraproject.org/updates/perl-Devel-CallChecker-0.006-1.fc19 -- You are receiving this mail because: You are on the CC list for the bug. Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=j5A5zSQfwma=cc_unsubscribe -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 1010913] perl-Devel-CallChecker-0.006 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1010913 --- Comment #4 from Fedora Update System upda...@fedoraproject.org --- perl-Devel-CallChecker-0.006-1.fc18 has been submitted as an update for Fedora 18. https://admin.fedoraproject.org/updates/perl-Devel-CallChecker-0.006-1.fc18 -- You are receiving this mail because: You are on the CC list for the bug. Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=1FTt6w0Nyha=cc_unsubscribe -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Broken dependencies: perl-PDL
perl-PDL has broken dependencies in the rawhide tree: On x86_64: perl-PDL-2.4.10-6.fc19.x86_64 requires perl(:MODULE_COMPAT_5.16.2) perl-PDL-2.4.10-6.fc19.x86_64 requires libgd.so.2()(64bit) On i386: perl-PDL-2.4.10-6.fc19.i686 requires perl(:MODULE_COMPAT_5.16.2) perl-PDL-2.4.10-6.fc19.i686 requires libgd.so.2 Please resolve this as soon as possible. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Broken dependencies: perl-MIME-Lite-HTML
perl-MIME-Lite-HTML has broken dependencies in the rawhide tree: On x86_64: perl-MIME-Lite-HTML-1.24-4.fc18.noarch requires perl(:MODULE_COMPAT_5.16.0) On i386: perl-MIME-Lite-HTML-1.24-4.fc18.noarch requires perl(:MODULE_COMPAT_5.16.0) On armhfp: perl-MIME-Lite-HTML-1.24-4.fc18.noarch requires perl(:MODULE_COMPAT_5.16.0) Please resolve this as soon as possible. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Broken dependencies: slic3r
slic3r has broken dependencies in the rawhide tree: On x86_64: slic3r-0.9.10b-2.fc20.noarch requires perl(:MODULE_COMPAT_5.16.3) On i386: slic3r-0.9.10b-2.fc20.noarch requires perl(:MODULE_COMPAT_5.16.3) On armhfp: slic3r-0.9.10b-2.fc20.noarch requires perl(:MODULE_COMPAT_5.16.3) Please resolve this as soon as possible. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Broken dependencies: perl-MooseX-TrackDirty-Attributes
perl-MooseX-TrackDirty-Attributes has broken dependencies in the rawhide tree: On x86_64: perl-MooseX-TrackDirty-Attributes-2.002-2.fc19.noarch requires perl(:MODULE_COMPAT_5.16.2) On i386: perl-MooseX-TrackDirty-Attributes-2.002-2.fc19.noarch requires perl(:MODULE_COMPAT_5.16.2) On armhfp: perl-MooseX-TrackDirty-Attributes-2.002-2.fc19.noarch requires perl(:MODULE_COMPAT_5.16.2) Please resolve this as soon as possible. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Broken dependencies: perl-Language-Expr
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: perl-Language-Expr-0.19-4.fc19.noarch requires perl(:MODULE_COMPAT_5.16.2) Please resolve this as soon as possible. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Broken dependencies: perl-Unix-Statgrab
perl-Unix-Statgrab has broken dependencies in the rawhide tree: On x86_64: perl-Unix-Statgrab-0.04-20.fc20.x86_64 requires libstatgrab.so.6()(64bit) On i386: perl-Unix-Statgrab-0.04-20.fc20.i686 requires libstatgrab.so.6 On armhfp: perl-Unix-Statgrab-0.04-20.fc20.armv7hl requires libstatgrab.so.6 Please resolve this as soon as possible. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Broken dependencies: perl-Padre
perl-Padre has broken dependencies in the rawhide tree: On x86_64: perl-Padre-0.90-6.fc18.noarch requires perl(:MODULE_COMPAT_5.16.0) On i386: perl-Padre-0.90-6.fc18.noarch requires perl(:MODULE_COMPAT_5.16.0) On armhfp: perl-Padre-0.90-6.fc18.noarch requires perl(:MODULE_COMPAT_5.16.0) Please resolve this as soon as possible. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
File IO-TieCombine-1.003.tar.gz uploaded to lookaside cache by ppisar
A file has been added to the lookaside cache for perl-IO-TieCombine: ea4ffa890b1ec4215b5dc65e45f7511f IO-TieCombine-1.003.tar.gz -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-IO-TieCombine] 1.003 bump
commit 057ceb0c069a1a612087f5048bab6a51f57fc080
Author: Petr Písař ppi...@redhat.com
Date: Mon Sep 23 14:38:41 2013 +0200
1.003 bump
.gitignore |1 +
perl-IO-TieCombine.spec | 19 +--
sources |2 +-
3 files changed, 15 insertions(+), 7 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index e9bf859..33f5ba3 100644
--- a/.gitignore
+++ b/.gitignore
@@ -1,3 +1,4 @@
IO-TieCombine-1.000.tar.gz
/IO-TieCombine-1.001.tar.gz
/IO-TieCombine-1.002.tar.gz
+/IO-TieCombine-1.003.tar.gz
diff --git a/perl-IO-TieCombine.spec b/perl-IO-TieCombine.spec
index 8f50883..4d634b6 100644
--- a/perl-IO-TieCombine.spec
+++ b/perl-IO-TieCombine.spec
@@ -1,19 +1,24 @@
Name: perl-IO-TieCombine
-Version:1.002
-Release:6%{?dist}
+Version:1.003
+Release:1%{?dist}
License:GPL+ or Artistic
Group: Development/Libraries
Summary:Produce tied (and other) separate but combined variables
Url:http://search.cpan.org/dist/IO-TieCombine
Source:
http://search.cpan.org/CPAN/authors/id/R/RJ/RJBS/IO-TieCombine-%{version}.tar.gz
BuildArch: noarch
-BuildRequires: perl(ExtUtils::MakeMaker)
+BuildRequires: perl
+BuildRequires: perl(ExtUtils::MakeMaker) = 6.30
+BuildRequires: perl(strict)
+BuildRequires: perl(warnings)
# Run-time
BuildRequires: perl(Carp)
BuildRequires: perl(Symbol)
# Tests
+BuildRequires: perl(File::Find)
+BuildRequires: perl(File::Temp)
BuildRequires: perl(Test::More)
-Requires: perl(:MODULE_COMPAT_%(eval `%{__perl} -V:version`; echo
$version))
+Requires: perl(:MODULE_COMPAT_%(eval `perl -V:version`; echo $version))
%description
This package allows you to tie separate variables into a combined whole, using
@@ -25,13 +30,12 @@ output from various different things that return data in
different ways
%setup -q -n IO-TieCombine-%{version}
%build
-%{__perl} Makefile.PL INSTALLDIRS=vendor
+perl Makefile.PL INSTALLDIRS=vendor
make %{?_smp_mflags}
%install
make pure_install PERL_INSTALL_ROOT=%{buildroot}
find %{buildroot} -type f -name .packlist -exec rm -f {} ';'
-find %{buildroot} -depth -type d -exec rmdir {} 2/dev/null ';'
%{_fixperms} %{buildroot}/*
%check
@@ -43,6 +47,9 @@ make test
%{_mandir}/man3/*.3*
%changelog
+* Mon Sep 23 2013 Petr Pisar ppi...@redhat.com - 1.003-1
+- 1.003 bump
+
* Sat Aug 03 2013 Fedora Release Engineering rel-...@lists.fedoraproject.org
- 1.002-6
- Rebuilt for https://fedoraproject.org/wiki/Fedora_20_Mass_Rebuild
diff --git a/sources b/sources
index 442dc83..776a0d5 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-3f0508284dafe9f674237e99868ba3d2 IO-TieCombine-1.002.tar.gz
+ea4ffa890b1ec4215b5dc65e45f7511f IO-TieCombine-1.003.tar.gz
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 1010915] perl-IO-TieCombine-1.003 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1010915 --- Comment #1 from Petr Pisar ppi...@redhat.com --- This bug-fixing release is suitable for all Fedoras. -- You are receiving this mail because: You are on the CC list for the bug. Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=fVmZ0pScAua=cc_unsubscribe -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
