Re: Proposal to reduce anti-bundling requirements

2015-10-11 Thread Kevin Kofler 
Haïkel wrote:
> And what happens if the library is consumed by other packages
> requiring the new API?

Of course you have to support both the new and the old one.

> Let's keep Ian example:
> You keep the deprecated function in the new library despite upstream's
> decision. Since we keep shipping it, developers will keep using it in
> their new software, making it incompatible with other distro.

Which is not our problem. (Developers should not use deprecated functions, 
no matter whether or when they get removed, so it's their fault, not ours. 
And in the end, it won't affect us at all if we ship the deprecated 
function, so why would we care?)

> We only had one problem, now we have more problems.

No. The other distro has a problem. Why would we care?

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: Query: %cmake not doing out-of-tree builds?

2015-10-11 Thread Ville Skyttä 
On Sun, Oct 11, 2015 at 5:42 AM, Orion Poplawski  wrote:
> FWIW - you can pass -m to rpmdev-newspec to get %{buildroot}.  That probably
> should be the default, but...

...https://bugzilla.redhat.com/show_bug.cgi?id=1256815#c3

You can make it the default with NEWSPEC_PREFER_MACROS, see the
rpmdev-newspec man page and /etc/rpmdevtools/newspec.conf.
-- 
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: Query: %cmake not doing out-of-tree builds?

2015-10-11 Thread Ville Skyttä 
On Sun, Oct 11, 2015 at 5:03 AM, Neal Gompa  wrote:

> We don't use %make_build,

https://git.fedorahosted.org/cgit/rpmdevtools.git/commit/?id=dcf1005d2cca7ce2a541718425f84d65fe8b8d00
-- 
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: Summary/Minutes from today's FESCo Meeting (2015-10-07)

2015-10-11 Thread Kevin Kofler 
Neal Gompa wrote:
> ​Then it sounds like it would make more sense to have a mechanism to
> automatically add the user-visible version number rather than the soname.
> Though, I don't quite understand what the purpose for sonames are in the
> first place, if they aren't really designed for supporting parallel
> installable stuff...

The main reason is to efficiently detect and reject incompatible 
combinations at runtime. With RPM AutoProvides and AutoRequires, they are 
also a means to ensure a package-level dependency on the correct version of 
the library.

> ​As far as I can tell, %autosetup patch application order is controlled by
> your PatchN declarations.

Which does not (necessarily) work if you are organizing your patches by some 
other criteria. E.g., in KDE packages, we typically use 0-99 for downstream 
patches and 100+ for backported upstream patches (sometimes further broken 
down into 1xx, 2xx, 3xx, … based on the branch the patch comes from). The 
numeric ordering is not always the correct one in which to apply the 
patches.

> The other criticisms are fair, but I think %autosetup comes in handy when
> you have lots and lots of patches, and you really don't need the
> conditional application.

Actually, the more patches you have, the less likely %autosetup is to do the 
right thing. And indeed, if you have few patches, it does not help much. 
Which is why I consider %autosetup to be entirely useless.

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

[Bug 1270090] perl-Unicode-Normalize-1.21 is available

2015-10-11 Thread bugzilla 
https://bugzilla.redhat.com/show_bug.cgi?id=1270090

Fedora Update System  changed:

   What|Removed |Added

 Status|MODIFIED|ON_QA



--- Comment #5 from Fedora Update System  ---
perl-Unicode-Normalize-1.21-1.fc23 has been pushed to the Fedora 23 testing
repository. If problems still persist, please make note of it in this bug
report.
If you want to test the update, you can install it with
$ su -c 'dnf --enablerepo=updates-testing update perl-Unicode-Normalize'
You can provide feedback for this update here:
https://bodhi.fedoraproject.org/updates/FEDORA-2015-c53bbb2c60

-- 
You are receiving this mail because:
You are on the CC list for the bug.
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel

[Bug 1270076] perl-Log-Report-1.08 is available

2015-10-11 Thread bugzilla 
https://bugzilla.redhat.com/show_bug.cgi?id=1270076



--- Comment #10 from Fedora Update System  ---
perl-Log-Report-1.08-1.fc23 has been pushed to the Fedora 23 testing
repository. If problems still persist, please make note of it in this bug
report.
If you want to test the update, you can install it with
$ su -c 'dnf --enablerepo=updates-testing update perl-Log-Report'
You can provide feedback for this update here:
https://bodhi.fedoraproject.org/updates/FEDORA-2015-60a13a9011

-- 
You are receiving this mail because:
You are on the CC list for the bug.
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel

Re: ebay-cors-filter's builds started to fail in f24

2015-10-11 Thread Peter Robinson 
Known issue, see threads [1] [2] plus possibly others.

[1] 
https://lists.fedoraproject.org/pipermail/devel-announce/2015-October/001685.html
[2] https://lists.fedoraproject.org/pipermail/devel/2015-October/215611.html


On Sun, Oct 11, 2015 at 7:14 AM, Sandro Bonazzola  wrote:
> Looks like DNF is failing on F24 / Rawhide.
>
>
> -- Forwarded message --
> From: 
> Date: Sun, Oct 11, 2015 at 4:12 AM
> Subject: ebay-cors-filter's builds started to fail in f24
> To: sbona...@redhat.com
>
>
> ebay-cors-filter's builds started to fail in f24
> https://apps.fedoraproject.org/koschei/package/ebay-cors-filter
>
> --
> You received this message due to your preference settings at
> https://apps.fedoraproject.org/notifications/sbonazzo.id.fedoraproject.org/email/29603
>
>
>
> --
> Sandro Bonazzola
> Better technology. Faster innovation. Powered by community collaboration.
> See how it works at redhat.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
-- 
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: Proposal: retire lesstif in f24 and beyond

2015-10-11 Thread Ralf Corsepius 

On 10/10/2015 07:39 PM, Zbigniew Jędrzejewski-Szmek wrote:

On Sat, Oct 10, 2015 at 07:20:22AM +0200, Ralf Corsepius wrote:



I know, we are late in the release schedule, but I am considering to
switching at least Inventor to motif on fc23, as well - It's
unimportant enough to most users, but is important to me ;)


I think that in a case of leaf package like that it totally makes
sense to switch even this late before release. Removal of
a dependency on lesstif seems important enough.


Rebuilding Inventor against motif requires switching
mesa-libGLw and Inventor to motif, i.e. a chain build consisting of
mesa-libGLw and Inventor.

As Inventor seems to be the only user of mesa-libGLw, this should be 
pretty harmless.


Unless somebody objects, I am going to rebuild these 2 packages for fc23 
tomorrow.


Ralf

PS.: derelict-GL3-devel also claims to require mesa-libGLw, but I can
not spot any actual source-code nor object dependency beween GLw nor
Xm. I therefore am inclined to believe this to be a packaging bug in
derelict.





--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Fwd: ebay-cors-filter's builds started to fail in f24

2015-10-11 Thread Sandro Bonazzola 
Looks like DNF is failing on F24 / Rawhide.


-- Forwarded message --
From: 
Date: Sun, Oct 11, 2015 at 4:12 AM
Subject: ebay-cors-filter's builds started to fail in f24
To: sbona...@redhat.com


ebay-cors-filter's builds started to fail in f24
https://apps.fedoraproject.org/koschei/package/ebay-cors-filter

--
You received this message due to your preference settings at
https://apps.fedoraproject.org/notifications/sbonazzo.id.fedoraproject.org/email/29603



-- 
Sandro Bonazzola
Better technology. Faster innovation. Powered by community collaboration.
See how it works at redhat.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

[Bug 1270575] perl-Math-PlanePath-121 is available

2015-10-11 Thread bugzilla 
https://bugzilla.redhat.com/show_bug.cgi?id=1270575



--- Comment #2 from Upstream Release Monitoring 
 ---
Scratch build completed
http://koji.fedoraproject.org/koji/taskinfo?taskID=11408793

-- 
You are receiving this mail because:
You are on the CC list for the bug.
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel

rawhide report: 20151011 changes

2015-10-11 Thread Fedora Rawhide Report 
Compose started at Sun Oct 11 05:15:03 UTC 2015
Broken deps for i386
--
[CableSwig]
CableSwig-3.20.0-13.fc23.i686 requires gccxml
[IQmol]
IQmol-2.3.0-9.fc24.i686 requires libboost_serialization.so.1.58.0
IQmol-2.3.0-9.fc24.i686 requires libboost_iostreams.so.1.58.0
IQmol-2.3.0-9.fc24.i686 requires libOpenMeshCore.so.3.2
[alliance]
alliance-5.0-40.20090901snap.fc22.i686 requires libXm.so.2
[bro]
bro-2.3.2-6.fc23.i686 requires libjemalloc.so.1
[bwm-ng]
bwm-ng-0.6-18.fc24.i686 requires libstatgrab.so.6
[fence-agents]
fence-agents-common-4.0.20-1.fc24.i686 requires pexpect
[gammaray]
gammaray-qt5-2.3.0-2.fc24.i686 requires qt5-qtbase(x86-32) = 0:5.5.0
[gnash]
1:gnash-0.8.10-19.fc24.i686 requires libboost_thread.so.1.58.0
1:gnash-0.8.10-19.fc24.i686 requires libboost_system.so.1.58.0
1:gnash-0.8.10-19.fc24.i686 requires libboost_serialization.so.1.58.0
1:gnash-0.8.10-19.fc24.i686 requires libboost_program_options.so.1.58.0
1:gnash-0.8.10-19.fc24.i686 requires libboost_iostreams.so.1.58.0
1:gnash-0.8.10-19.fc24.i686 requires libboost_date_time.so.1.58.0
1:gnash-cygnal-0.8.10-19.fc24.i686 requires libboost_thread.so.1.58.0
1:gnash-cygnal-0.8.10-19.fc24.i686 requires libboost_system.so.1.58.0
1:gnash-cygnal-0.8.10-19.fc24.i686 requires 
libboost_serialization.so.1.58.0
1:gnash-cygnal-0.8.10-19.fc24.i686 requires 
libboost_program_options.so.1.58.0
1:gnash-cygnal-0.8.10-19.fc24.i686 requires libboost_iostreams.so.1.58.0
1:gnash-cygnal-0.8.10-19.fc24.i686 requires libboost_date_time.so.1.58.0
1:gnash-extension-dejagnu-0.8.10-19.fc24.i686 requires 
libboost_thread.so.1.58.0
1:gnash-extension-dejagnu-0.8.10-19.fc24.i686 requires 
libboost_system.so.1.58.0
1:gnash-extension-dejagnu-0.8.10-19.fc24.i686 requires 
libboost_program_options.so.1.58.0
1:gnash-extension-dejagnu-0.8.10-19.fc24.i686 requires 
libboost_iostreams.so.1.58.0
1:gnash-extension-fileio-0.8.10-19.fc24.i686 requires 
libboost_thread.so.1.58.0
1:gnash-extension-fileio-0.8.10-19.fc24.i686 requires 
libboost_system.so.1.58.0
1:gnash-extension-fileio-0.8.10-19.fc24.i686 requires 
libboost_program_options.so.1.58.0
1:gnash-extension-fileio-0.8.10-19.fc24.i686 requires 
libboost_iostreams.so.1.58.0
1:gnash-extension-lirc-0.8.10-19.fc24.i686 requires 
libboost_thread.so.1.58.0
1:gnash-extension-lirc-0.8.10-19.fc24.i686 requires 
libboost_system.so.1.58.0
1:gnash-extension-lirc-0.8.10-19.fc24.i686 requires 
libboost_program_options.so.1.58.0
1:gnash-extension-lirc-0.8.10-19.fc24.i686 requires 
libboost_iostreams.so.1.58.0
1:gnash-extension-mysql-0.8.10-19.fc24.i686 requires 
libboost_thread.so.1.58.0
1:gnash-extension-mysql-0.8.10-19.fc24.i686 requires 
libboost_system.so.1.58.0
1:gnash-extension-mysql-0.8.10-19.fc24.i686 requires 
libboost_program_options.so.1.58.0
1:gnash-extension-mysql-0.8.10-19.fc24.i686 requires 
libboost_iostreams.so.1.58.0
1:gnash-klash-0.8.10-19.fc24.i686 requires libboost_system.so.1.58.0
1:gnash-klash-0.8.10-19.fc24.i686 requires 
libboost_program_options.so.1.58.0
1:gnash-plugin-0.8.10-19.fc24.i686 requires libboost_iostreams.so.1.58.0
1:python-gnash-0.8.10-19.fc24.i686 requires libboost_thread.so.1.58.0
1:python-gnash-0.8.10-19.fc24.i686 requires libboost_system.so.1.58.0
1:python-gnash-0.8.10-19.fc24.i686 requires 
libboost_program_options.so.1.58.0
1:python-gnash-0.8.10-19.fc24.i686 requires libboost_iostreams.so.1.58.0
[golang-github-kraman-libcontainer]
golang-github-kraman-libcontainer-devel-0-0.4.gitd700e5b.fc24.noarch 
requires golang(github.com/docker/docker/pkg/netlink)
[golang-github-prometheus-prometheus]
golang-github-prometheus-prometheus-devel-0.15.0-1.fc24.noarch requires 
golang(gopkg.in/fsnotify.v1)
[grace]
grace-5.1.25-2.fc23.i686 requires libXm.so.2
[hbase]
hbase-0.98.3-4.fc22.noarch requires mvn(com.sun.jersey:jersey-server)
hbase-0.98.3-4.fc22.noarch requires mvn(com.sun.jersey:jersey-json)
hbase-0.98.3-4.fc22.noarch requires mvn(com.sun.jersey:jersey-core)
hbase-tests-0.98.3-4.fc22.noarch requires 
mvn(com.sun.jersey:jersey-server)
hbase-tests-0.98.3-4.fc22.noarch requires 
mvn(com.sun.jersey:jersey-json)
hbase-tests-0.98.3-4.fc22.noarch requires 
mvn(com.sun.jersey:jersey-core)
[js-of-ocaml]
js-of-ocaml-2.4-8.fc23.i686 requires ocaml(runtime) = 0:4.02.2
js-of-ocaml-2.4-8.fc23.i686 requires ocaml(Lwt_list) = 
0:0ce891783d3177cd33ebd9ed60d4b62d
js-of-ocaml-2.4-8.fc23.i686 requires ocaml(Lwt) = 
0:6f62eda62952a3e464e9c34a825cf0de
[mintmenu]
mintmenu-5.6.4-1.fc24.noarch requires yumex
[netbeans-platform]

Re: "Unbundling SIG" was [Re: Summary/Minutes from today's FESCo Meeting (2015-10-07)]

2015-10-11 Thread Kevin Kofler 
Haïkel wrote:
> In short: packagers are not to be trusted, that's the bottom line of
> your argumentation.

Not at all! It is funny that you are accusing me of distrusting packagers 
when I have been arguing for years that packagers ARE to be trusted and thus 
the restrictions on updates need to go away.

What I am saying instead is that:
1. You have to acknowledge that there is an obvious conflict of interest
   between upstream and downstream on this issue.
2. Several packagers ARE upstream.
3. There is a common credo (which I do not adher to) in Fedora that upstream
   should be followed blindly ("upstream, upstream, upstream").
4. There is nothing in the new policy that states, even informally
   (= without enforcement), that unbundling is MORE IMPORTANT than following
   upstream.

And don't forget that the people who want libraries to be unbundled will in 
most cases ALSO be packagers, just not necessarily the maintainers of the 
particular package.

So there needs to be:
* a clear statement (an informal recommendation or a strict rule) that
  unbundling is the desired target state even if upstream is against it, and
* a way to deal with the potential conflicts of interest (where the packager
  is upstream and/or puts upstream's goals above ours).

I still think the old policy with its strict rule was the best way to 
address both.

If you think packagers will always do the right thing without any kind of 
guidance, then why do we have packaging guidelines at all?

> Being putting down stricter guidelines without any means of enforcing
> them, you're not solving anything.

There is a means of enforcing this guideline, just like all the other 
packaging guidelines: unsponsoring offenders! Of course, it should be done 
only as a last resort, but the possibility needs to be there.

> FESCo choose to trust contributors to do the right thing and being honest.

Then start by repealing the update stability policies.

> Wrong, it's even more "laxist" than our current one.
> https://www.debian.org/doc/debian-policy/ch-source.html#s-embeddedfiles
> https://fedoraproject.org/wiki/User:Tibbs/BundlingDraft2

It is actually not, if you read them closely.

Debian:
| Debian packages should not make use of these convenience copies unless the
| included package is explicitly intended to be used in this way.
i.e., the LIBRARY upstream decides whether it is a copylib or not. This is 
similar to the copylib exception in our old guidelines, except that they do 
not require any formal approval for copylibs.

Tibbs:
| All packages whose upstreams allow them to be built against system
| libraries must be built against system libraries.
i.e., the APPLICATION upstream decides whether it bundles its libraries or 
not. This is NOT the same thing. In most cases, they are NOT the same 
upstream, and the application upstream can bundle even libraries that DON'T 
want to be bundled.

> Besides, you're not answering the question, Matthew changed the topic
> to focus the discussion on the Unbundling SIG proposal.

I am answering some points Matthew was making, and they are within the topic 
of the thread as a whole.

> I think it's a better idea to have a focused group leading that effort
> and I hope closely with FPC.

I don't think it is fair to offload lazy packagers' work on the small group 
that cares about having Fedora done right. It is bad enough that we need to 
fix packages that are in violation of the guidelines, we should not let it 
become the norm by weakening or repealing the guidelines (but instead take 
steps to prevent this from happening to begin with).

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

jehane pushed to fusioninventory-agent (master). "new version (..more)"

2015-10-11 Thread notifications 
From c7493300b75beeed3980723ecddc68185438a0a8 Mon Sep 17 00:00:00 2001
From: jehane 
Date: Sun, 11 Oct 2015 17:01:09 +0200
Subject: new version

- Upstream switch to github, minor spec adaptation
---
 .gitignore |  1 +
 fusioninventory-agent.spec | 16 ++--
 sources|  2 +-
 3 files changed, 12 insertions(+), 7 deletions(-)

diff --git a/.gitignore b/.gitignore
index c55cab8..5bdc389 100644
--- a/.gitignore
+++ b/.gitignore
@@ -1,2 +1,3 @@
 /FusionInventory-Agent-2.3.15.tar.gz
 /FusionInventory-Agent-2.3.16.tar.gz
+/2.3.17.tar.gz
diff --git a/fusioninventory-agent.spec b/fusioninventory-agent.spec
index 75572f2..a8de963 100644
--- a/fusioninventory-agent.spec
+++ b/fusioninventory-agent.spec
@@ -9,11 +9,11 @@ Group:   Applications/System
 License: GPLv2+
 URL: http://fusioninventory.org/
 
-Version: 2.3.16
-Release: 5%{?dist}
+Version: 2.3.17
+Release: 1%{?dist}
 #BuildArch:   noarch
-Source0: 
http://search.cpan.org/CPAN/authors/id/G/GR/GROUSSE/FusionInventory-Agent-%{version}%{?prever}.tar.gz
-Source1:   %{name}.cron
+Source0: 
https://github.com/fusioninventory/fusioninventory-agent/archive/%{version}.tar.gz
+Source1: %{name}.cron
 #Source2:   %{name}.init
 #Source3:   %{name}.service
 
@@ -163,7 +163,7 @@ Requires:   perl(Parse::EDID)
 %description task-inventory
 fusioninventory-task-inventory
 %prep
-%setup -q -n FusionInventory-Agent-%{version}%{?prever}
+%setup -q -n %{name}-%{version}%{?prever}
 
 # This work only on older version, and is ignored on recent
 cat < - 2.3.17
+- new version
+- Upstream switch to github, minor spec adaptation
+
 * Wed Jul 8 2015 Marianne Lombard  - 2.3.16-5
 - fix for #1240964 
 
diff --git a/sources b/sources
index 5c32a15..5f048ba 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-89467ae101a89544a6fbade2e7a879fe  FusionInventory-Agent-2.3.16.tar.gz
+10a88ccc22d3ec0746147215eed6d3b2  2.3.17.tar.gz
-- 
cgit v0.11.2



http://pkgs.fedoraproject.org/cgit/fusioninventory-agent.git/commit/?h=master=c7493300b75beeed3980723ecddc68185438a0a8
--
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

jehane uploaded 2.3.17.tar.gz for fusioninventory-agent

2015-10-11 Thread notifications 
10a88ccc22d3ec0746147215eed6d3b2  2.3.17.tar.gz

http://pkgs.fedoraproject.org/lookaside/pkgs/fusioninventory-agent/2.3.17.tar.gz/md5/10a88ccc22d3ec0746147215eed6d3b2/2.3.17.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

Re: "Unbundling SIG" was [Re: Summary/Minutes from today's FESCo Meeting (2015-10-07)]

2015-10-11 Thread Kalev Lember 
Just replying to this one point:

On 10/11/2015 02:29 PM, Kevin Kofler wrote:
> 3. There is a common credo (which I do not adher to) in Fedora that upstream
>should be followed blindly ("upstream, upstream, upstream").

My interpretation of this is completely different than yours. :)

To me it is not at all about blindly following upstream. To me
"upstream, upstream, upstream" means that if we want to change
something in code, we should try and land our changes upstream first.
This is always not easy; sometimes it requires working with upstream and
fixing things that were discovered during code review; other times it
requires making fixes more generic than are needed for Fedora in order
to make them suitable for upstream inclusion. That all often leads to us
becoming part of upstream.

And that is a good thing, because the more involved we are with upstream
the more we are able to influence upstream so that changes that land
there work for Fedora.

I'll say it once more because it feels good to be ranting on a mailing
list. :) It is not at all about blindly following upstream. It is about
sharing the code following open source principles, and making sure we
don't effectively end up with downstream forks.

It's not easy, but it pays off in the end.

-- 
Kalev
-- 
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: Query: %cmake not doing out-of-tree builds?

2015-10-11 Thread Kevin Kofler 
Neal Gompa wrote:
> Over the last few weeks, I've been working on a number of packages that
> use CMake for the build system for various distros, and I've noticed
> something rather peculiar. Of all the distros I've built packages for
> (Fedora/CentOS, openSUSE, Mageia, Debian, and Ubuntu), only Fedora/CentOS
> does not automatically do CMake building in a subdirectory such that the
> build artifacts don't mix in with the source tree. Essentially, the %cmake
> macro doesn't enforce builds are out-of-tree.
> 
> Is there a particular reason for this?

Our %cmake macro does not pass the directory name at all. Instead, it is 
YOUR job to pass "%cmake ." or "%cmake ..". This is needed for flexibility, 
because some packages support only in-tree build and some only out-of-tree 
build. (IMHO, both sets of packages are broken, it is easy to support both 
with CMake. But it is easy to build the packages the way they want to be 
built.)

I don't believe in automagic macros that attempt to do everything for you, 
and then don't give you the flexibility to override things where needed. I 
prefer seeing in the specfile what is really going on. So I think %cmake is 
right the way it is now. (And anyway, we can't really change it now, it 
would require changing all specfiles in Fedora that use %cmake.)

And by the way, CMake does a lot more than just allowing out-of-tree builds, 
so that is not "the whole *point* of CMake". :-)

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

F-23 Branched report: 20151011 changes

2015-10-11 Thread Fedora Branched Report 
Compose started at Sun Oct 11 07:15:03 UTC 2015
Broken deps for armhfp
--
[389-ds-base]
389-ds-base-1.3.4.4-1.fc23.armv7hl requires librpmio.so.3
389-ds-base-1.3.4.4-1.fc23.armv7hl requires librpm.so.3
[CableSwig]
CableSwig-3.20.0-13.fc23.armv7hl requires gccxml
[apache-scout]
apache-scout-1.2.6-11.fc21.noarch requires mvn(org.apache.juddi:uddi-ws)
apache-scout-1.2.6-11.fc21.noarch requires 
mvn(org.apache.juddi:juddi-client)
[hbase]
hbase-0.98.3-4.fc22.noarch requires mvn(com.sun.jersey:jersey-server)
hbase-0.98.3-4.fc22.noarch requires mvn(com.sun.jersey:jersey-json)
hbase-0.98.3-4.fc22.noarch requires mvn(com.sun.jersey:jersey-core)
hbase-tests-0.98.3-4.fc22.noarch requires 
mvn(com.sun.jersey:jersey-server)
hbase-tests-0.98.3-4.fc22.noarch requires 
mvn(com.sun.jersey:jersey-json)
hbase-tests-0.98.3-4.fc22.noarch requires 
mvn(com.sun.jersey:jersey-core)
[moon-buggy]
moon-buggy-1.0.51-14.fc23.armv7hl requires libesd.so.0
[netbeans-platform]
1:netbeans-platform-harness-7.0.1-11.fc22.armv7hl requires cobertura >= 
0:1.9.3
[nodejs-grunt-contrib-copy]
nodejs-grunt-contrib-copy-0.8.0-2.fc23.noarch requires 
npm(file-sync-cmp) < 0:0.2
nodejs-grunt-contrib-copy-0.8.0-2.fc23.noarch requires 
npm(file-sync-cmp) >= 0:0.1.0
nodejs-grunt-contrib-copy-0.8.0-2.fc23.noarch requires npm(chalk) >= 
0:0.5.1
[oat]
oat-appraiser-1.6.0-16.fc22.armv7hl requires tomcat-servlet-3.0-api
oat-client-1.6.0-16.fc22.armv7hl requires tomcat-servlet-3.0-api
[oozie]
oozie-4.0.1-5.fc22.noarch requires mvn(org.apache.pig:pig)
oozie-4.0.1-5.fc22.noarch requires mvn(org.apache.hive:hive-serde)
oozie-4.0.1-5.fc22.noarch requires mvn(org.apache.hive:hive-metastore)
oozie-4.0.1-5.fc22.noarch requires mvn(org.apache.hive:hive-exec)
oozie-4.0.1-5.fc22.noarch requires mvn(org.apache.hive:hive-common)
oozie-4.0.1-5.fc22.noarch requires mvn(org.apache.hive:hive-cli)
oozie-4.0.1-5.fc22.noarch requires 
mvn(org.apache.hive.hcatalog:webhcat-java-client)
oozie-4.0.1-5.fc22.noarch requires 
mvn(org.apache.hive.hcatalog:hcatalog-server-extensions)
oozie-4.0.1-5.fc22.noarch requires 
mvn(org.apache.hive.hcatalog:hcatalog-pig-adapter)
oozie-4.0.1-5.fc22.noarch requires 
mvn(org.apache.hive.hcatalog:hcatalog-core)
[openstack-swift]
openstack-swift-2.3.0-2.fc23.noarch requires python-pyeclib
[pyjigdo]
pyjigdo-0.4.0.3-9.fc23.noarch requires fuseiso
[python-fiat]
python-fiat-1.5.0-2.fc23.noarch requires ScientificPython
[vdr-live]
vdr-live-0.3.0-21.20150213git6ea279a.fc23.armv7hl requires 
libtntnet.so.12
vdr-live-0.3.0-21.20150213git6ea279a.fc23.armv7hl requires 
libcxxtools.so.9
[vfrnav]
vfrnav-20141211-1.fc22.armv7hl requires libgps.so.21
vfrnav-utils-20141211-1.fc22.armv7hl requires libgdal.so.1



Broken deps for i386
--
[389-ds-base]
389-ds-base-1.3.4.4-1.fc23.i686 requires librpmio.so.3
389-ds-base-1.3.4.4-1.fc23.i686 requires librpm.so.3
[CableSwig]
CableSwig-3.20.0-13.fc23.i686 requires gccxml
[apache-scout]
apache-scout-1.2.6-11.fc21.noarch requires mvn(org.apache.juddi:uddi-ws)
apache-scout-1.2.6-11.fc21.noarch requires 
mvn(org.apache.juddi:juddi-client)
[hbase]
hbase-0.98.3-4.fc22.noarch requires mvn(com.sun.jersey:jersey-server)
hbase-0.98.3-4.fc22.noarch requires mvn(com.sun.jersey:jersey-json)
hbase-0.98.3-4.fc22.noarch requires mvn(com.sun.jersey:jersey-core)
hbase-tests-0.98.3-4.fc22.noarch requires 
mvn(com.sun.jersey:jersey-server)
hbase-tests-0.98.3-4.fc22.noarch requires 
mvn(com.sun.jersey:jersey-json)
hbase-tests-0.98.3-4.fc22.noarch requires 
mvn(com.sun.jersey:jersey-core)
[moon-buggy]
moon-buggy-1.0.51-14.fc23.i686 requires libesd.so.0
[netbeans-platform]
1:netbeans-platform-harness-7.0.1-11.fc22.i686 requires cobertura >= 
0:1.9.3
[nodejs-grunt-contrib-copy]
nodejs-grunt-contrib-copy-0.8.0-2.fc23.noarch requires 
npm(file-sync-cmp) < 0:0.2
nodejs-grunt-contrib-copy-0.8.0-2.fc23.noarch requires 
npm(file-sync-cmp) >= 0:0.1.0
nodejs-grunt-contrib-copy-0.8.0-2.fc23.noarch requires npm(chalk) >= 
0:0.5.1
[oat]
oat-appraiser-1.6.0-16.fc22.i686 requires tomcat-servlet-3.0-api
oat-client-1.6.0-16.fc22.i686 requires tomcat-servlet-3.0-api
[openstack-swift]
openstack-swift-2.3.0-2.fc23.noarch requires python-pyeclib
[pure]
pure-0.62-2.fc22.i686 requires libLLVM-3.5.so
[pyjigdo]
pyjigdo-0.4.0.3-9.fc23.noarch requires fuseiso
[python-fiat]
python-fiat-1.5.0-2.fc23.noarch requires ScientificPython
[spark]
spark-0.9.1-0.3.rc3.fc21.i686 requires

[Bug 1270575] perl-Math-PlanePath-121 is available

2015-10-11 Thread bugzilla 
https://bugzilla.redhat.com/show_bug.cgi?id=1270575



--- Comment #1 from Upstream Release Monitoring 
 ---
Created attachment 1081787
  --> https://bugzilla.redhat.com/attachment.cgi?id=1081787=edit
[patch] Update to 121 (#1270575)

-- 
You are receiving this mail because:
You are on the CC list for the bug.
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel

[Bug 1270575] New: perl-Math-PlanePath-121 is available

2015-10-11 Thread bugzilla 
https://bugzilla.redhat.com/show_bug.cgi?id=1270575

Bug ID: 1270575
   Summary: perl-Math-PlanePath-121 is available
   Product: Fedora
   Version: rawhide
 Component: perl-Math-PlanePath
  Keywords: FutureFeature, Triaged
  Assignee: mhron...@redhat.com
  Reporter: upstream-release-monitor...@fedoraproject.org
QA Contact: extras...@fedoraproject.org
CC: mhron...@redhat.com,
perl-devel@lists.fedoraproject.org



Latest upstream release: 121
Current version/release in rawhide: 120-1.fc24
URL: http://search.cpan.org/dist/Math-PlanePath/

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

Please keep in mind that with any upstream change, there may also be packaging
changes that need to be made. Specifically, please remember that it is your
responsibility to review the new version to ensure that the licensing is still
correct and that no non-free or legally problematic items have been added
upstream.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel

Re: Hi Guys !

2015-10-11 Thread Andrey Ponomarenko 

Jules Bashizi wrote:

I got admission into some British university and I am to buy a laptop .
wish to know a machine which is good with Linux . any advice on which and
where to get it  please !


Take a look at this list of laptops/notebooks tested with the Linux 
kernels from 3.14 to 4.1: 
http://hw.rosalinux.ru/index.php?show=machines=notebook


You can sort the list by the computer model and select a most popular one.

--
Andrey Ponomarenko

--
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: Proposal to reduce anti-bundling requirements

2015-10-11 Thread Ian Malone 
On 11 October 2015 at 12:43, Kevin Kofler  wrote:
> Haïkel wrote:
>> And what happens if the library is consumed by other packages
>> requiring the new API?
>
> Of course you have to support both the new and the old one.
>
>> Let's keep Ian example:
>> You keep the deprecated function in the new library despite upstream's
>> decision. Since we keep shipping it, developers will keep using it in
>> their new software, making it incompatible with other distro.
>
> Which is not our problem. (Developers should not use deprecated functions,
> no matter whether or when they get removed, so it's their fault, not ours.
> And in the end, it won't affect us at all if we ship the deprecated
> function, so why would we care?)
>
>> We only had one problem, now we have more problems.
>
> No. The other distro has a problem. Why would we care?

Maybe there's some confusion about the point I was making. I'm
referring to the case where the bundled library has functions that are
no longer present in the fedora version and the application requires
them.

An upstream may (or may not if abandoned) have their own schedule for
moving something to a newer version of a dependency, but if they're
bundling then that may be happening at a different speed to what
fedora is doing with that library. A maintainer who has unbundled
things independent of upstream will find themselves needing to
rebundle, fork and modify or just drop.

-- 
imalone
http://ibmalone.blogspot.co.uk
-- 
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 1267292] Upgrade perl-DBD-Firebird to 1.21

2015-10-11 Thread bugzilla 
https://bugzilla.redhat.com/show_bug.cgi?id=1267292



--- Comment #12 from Fedora Update System  ---
perl-DBD-Firebird-1.21-1.fc23 has been pushed to the Fedora 23 stable
repository. If problems still persist, please make note of it in this bug
report.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel

[Bug 1267292] Upgrade perl-DBD-Firebird to 1.21

2015-10-11 Thread bugzilla 
https://bugzilla.redhat.com/show_bug.cgi?id=1267292

Fedora Update System  changed:

   What|Removed |Added

 Status|ON_QA   |CLOSED
   Fixed In Version||perl-DBD-Firebird-1.21-1.fc
   ||23
 Resolution|--- |ERRATA
Last Closed||2015-10-11 12:04:58



-- 
You are receiving this mail because:
You are on the CC list for the bug.
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel

Fedora Rawhide 20151011 compose check report

2015-10-11 Thread Fedora compose checker 
No missing expected images.

No images in this compose but not Rawhide 20151010

No images in Rawhide 20151010 but not this.

Failed openQA tests: 12 of 52

ID: 5491Test: x86_64 universal server_multi_empty
ID: 5487Test: i386 workstation_live default_install
ID: 5486Test: x86_64 kde_live default_install
ID: 5478Test: i386 kde_live default_install
ID: 5470Test: i386 universal upgrade_desktop_32bit
ID: 5455Test: x86_64 universal server_simple_free_space@uefi
ID: 5453Test: x86_64 universal server_delete_partial@uefi
ID: 5450Test: x86_64 universal european_language_install
ID: 5446Test: x86_64 universal upgrade_desktop_64bit
ID: 5445Test: x86_64 universal upgrade_minimal_64bit
ID: 5442Test: x86_64 universal server_lvmthin
ID: 5433Test: x86_64 universal server_repository_http_graphical

Passed openQA tests: 40 of 52
-- 
Mail generated by check-compose:
https://git.fedorahosted.org/cgit/fedora-qa.git/tree/check-compose
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Fedora 23 Branched 20151011 compose check report

2015-10-11 Thread Fedora compose checker 
No missing expected images.

Images in this compose but not 23 Branched 20151010:

Cloud docker x86_64

No images in 23 Branched 20151010 but not this.

Failed openQA tests: 7 of 52

ID: 5479Test: i386 workstation_live default_install
ID: 5477Test: i386 kde_live default_install
ID: 5474Test: x86_64 kde_live default_install
ID: 5421Test: i386 universal upgrade_desktop_32bit
ID: 5406Test: x86_64 universal server_simple_free_space@uefi
ID: 5404Test: x86_64 universal server_delete_partial@uefi
ID: 5397Test: x86_64 universal upgrade_desktop_64bit

Passed openQA tests: 45 of 52
-- 
Mail generated by check-compose:
https://git.fedorahosted.org/cgit/fedora-qa.git/tree/check-compose
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

rebus set the monitor flag of perl-Number-Bytes-Human to True

2015-10-11 Thread notifications 
rebus set the monitor flag of perl-Number-Bytes-Human to True

--
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

unretiring valabind package

2015-10-11 Thread Michal Ambroz 
Hello,
I would like to unretire the package "valabind" and become the owner for the
orphaned package.
With the current release of valabind 0.9.2 it seems to build nicely with 
recent vala version in rawhide 
and recent versions of Fedora, so I would like to unretire it.

Koji scratch build:
http://koji.fedoraproject.org/koji/taskinfo?taskID=11410814

Spec URL: https://rebus.fedorapeople.org/SPECS/valabind.spec
SRPM URL: https://rebus.fedorapeople.org/SRPMS/valabind-0.9.2-1.fc21.src.rpm
Fedora Account System Username: rebus
Description: 
Valabind is a tool to parse vala[1] or vapi files to transform them
into swig[2] interface files, C++, NodeJS-ffi or GIR.  With swig, you
can create language bindings for any API written in vala or C with a
vapi interface.  It can also generate bindings for C++.

This emails is following the unretiring policy:
https://fedoraproject.org/wiki/Orphaned_package_that_need_new_maintainers#
Claiming_Ownership_of_a_Retired_Package

Best regards
Michal Ambroz






-- Původní zpráva --
Od: notificati...@fedoraproject.org
Komu: re...@seznam.cz
Datum: 12. 10. 2015 0:08:25
Předmět: rebus's scratch build of valabind-0.9.2-1.fc21.src.rpm for rawhide 
completed

"Task 11410814 on buildvm-14.phx2.fedoraproject.org
Task Type: build (noarch)
Link: https://koji.fedoraproject.org/koji/taskinfo?taskID=11410814

Task 11410817 on buildvm-27.phx2.fedoraproject.org
Task Type: buildArch (i386)
Link: https://koji.fedoraproject.org/koji/taskinfo?taskID=11410817
logs:
https://kojipkgs.fedoraproject.org/work/tasks/817/11410817/build.log
https://kojipkgs.fedoraproject.org/work/tasks/817/11410817/state.log
https://kojipkgs.fedoraproject.org/work/tasks/817/11410817/root.log
rpms:
https://kojipkgs.fedoraproject.org/work/tasks/817/11410817/valabind-0.9.2-1.
fc24.i686.rpm
https://kojipkgs.fedoraproject.org/work/tasks/817/11410817/valabind-
debuginfo-0.9.2-1.fc24.i686.rpm
srpms:

Task 11410816 on buildvm-10.phx2.fedoraproject.org
Task Type: buildArch (x86_64)
Link: https://koji.fedoraproject.org/koji/taskinfo?taskID=11410816
logs:
https://kojipkgs.fedoraproject.org/work/tasks/816/11410816/root.log
https://kojipkgs.fedoraproject.org/work/tasks/816/11410816/state.log
https://kojipkgs.fedoraproject.org/work/tasks/816/11410816/build.log
rpms:
https://kojipkgs.fedoraproject.org/work/tasks/816/11410816/valabind-
debuginfo-0.9.2-1.fc24.x86_64.rpm
https://kojipkgs.fedoraproject.org/work/tasks/816/11410816/valabind-0.9.2-1.
fc24.x86_64.rpm
srpms:

Task 11410815 on arm02-builder23.arm.fedoraproject.org
Task Type: buildArch (armhfp)
Link: https://koji.fedoraproject.org/koji/taskinfo?taskID=11410815
logs:
https://kojipkgs.fedoraproject.org/work/tasks/815/11410815/build.log
https://kojipkgs.fedoraproject.org/work/tasks/815/11410815/state.log
https://kojipkgs.fedoraproject.org/work/tasks/815/11410815/root.log
rpms:
https://kojipkgs.fedoraproject.org/work/tasks/815/11410815/valabind-0.9.2-1.
fc24.armv7hl.rpm
https://kojipkgs.fedoraproject.org/work/tasks/815/11410815/valabind-
debuginfo-0.9.2-1.fc24.armv7hl.rpm
srpms:
https://kojipkgs.fedoraproject.org/work/tasks/815/11410815/valabind-0.9.2-1.
fc24.src.rpm

http://koji.fedoraproject.org/koji/taskinfo?taskID=11410814

--
You received this message due to your preference settings at
https://apps.fedoraproject.org/notifications/rebus.id.fedoraproject.org/
email/20888"-- 
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: unretiring valabind package

2015-10-11 Thread gil 

Hi

1) maybe you should open a bug for review the package ... ?
2) you must use %license macro for LICENSE text file
3) maybe you could remove %{!?_pkgdocdir: %global 
%{_docdir}/%{name}-%{version}}

i do not understand why _pkgdocdir is versioned
4) you could remove also "Group: Applications/Engineering" is no more 
required


regards
gil
Il 12/10/2015 03:51, Michal Ambroz ha scritto:

Hello,
I would like to unretire the package "valabind" and become the owner 
for the orphaned package.
With the current release of valabind 0.9.2 it seems to build nicely 
with recent vala version in rawhide

and recent versions of Fedora, so I would like to unretire it.

Koji scratch build:
http://koji.fedoraproject.org/koji/taskinfo?taskID=11410814

Spec URL: https://rebus.fedorapeople.org/SPECS/valabind.spec
SRPM URL: 
https://rebus.fedorapeople.org/SRPMS/valabind-0.9.2-1.fc21.src.rpm

Fedora Account System Username: rebus
Description:
Valabind is a tool to parse vala[1] or vapi files to transform them
into swig[2] interface files, C++, NodeJS-ffi or GIR.  With swig, you
can create language bindings for any API written in vala or C with a
vapi interface.  It can also generate bindings for C++.

This emails is following the unretiring policy:
https://fedoraproject.org/wiki/Orphaned_package_that_need_new_maintainers#Claiming_Ownership_of_a_Retired_Package

Best regards
Michal Ambroz





-- Původní zpráva --
Od: notificati...@fedoraproject.org
Komu: re...@seznam.cz
Datum: 12. 10. 2015 0:08:25
Předmět: rebus's scratch build of valabind-0.9.2-1.fc21.src.rpm for 
rawhide completed



Task 11410814 on buildvm-14.phx2.fedoraproject.org
Task Type: build (noarch)
Link: https://koji.fedoraproject.org/koji/taskinfo?taskID=11410814

Task 11410817 on buildvm-27.phx2.fedoraproject.org
Task Type: buildArch (i386)
Link: https://koji.fedoraproject.org/koji/taskinfo?taskID=11410817
logs:
https://kojipkgs.fedoraproject.org/work/tasks/817/11410817/build.log
https://kojipkgs.fedoraproject.org/work/tasks/817/11410817/state.log
https://kojipkgs.fedoraproject.org/work/tasks/817/11410817/root.log
rpms:

https://kojipkgs.fedoraproject.org/work/tasks/817/11410817/valabind-0.9.2-1.fc24.i686.rpm

https://kojipkgs.fedoraproject.org/work/tasks/817/11410817/valabind-debuginfo-0.9.2-1.fc24.i686.rpm
srpms:

Task 11410816 on buildvm-10.phx2.fedoraproject.org
Task Type: buildArch (x86_64)
Link: https://koji.fedoraproject.org/koji/taskinfo?taskID=11410816
logs:
https://kojipkgs.fedoraproject.org/work/tasks/816/11410816/root.log
https://kojipkgs.fedoraproject.org/work/tasks/816/11410816/state.log
https://kojipkgs.fedoraproject.org/work/tasks/816/11410816/build.log
rpms:

https://kojipkgs.fedoraproject.org/work/tasks/816/11410816/valabind-debuginfo-0.9.2-1.fc24.x86_64.rpm

https://kojipkgs.fedoraproject.org/work/tasks/816/11410816/valabind-0.9.2-1.fc24.x86_64.rpm
srpms:

Task 11410815 on arm02-builder23.arm.fedoraproject.org
Task Type: buildArch (armhfp)
Link: https://koji.fedoraproject.org/koji/taskinfo?taskID=11410815
logs:
https://kojipkgs.fedoraproject.org/work/tasks/815/11410815/build.log
https://kojipkgs.fedoraproject.org/work/tasks/815/11410815/state.log
https://kojipkgs.fedoraproject.org/work/tasks/815/11410815/root.log
rpms:

https://kojipkgs.fedoraproject.org/work/tasks/815/11410815/valabind-0.9.2-1.fc24.armv7hl.rpm

https://kojipkgs.fedoraproject.org/work/tasks/815/11410815/valabind-debuginfo-0.9.2-1.fc24.armv7hl.rpm
srpms:

https://kojipkgs.fedoraproject.org/work/tasks/815/11410815/valabind-0.9.2-1.fc24.src.rpm

http://koji.fedoraproject.org/koji/taskinfo?taskID=11410814

--
You received this message due to your preference settings at

https://apps.fedoraproject.org/notifications/rebus.id.fedoraproject.org/email/20888





-- 
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 1267292] Upgrade perl-DBD-Firebird to 1.21

2015-10-11 Thread bugzilla 
https://bugzilla.redhat.com/show_bug.cgi?id=1267292

Fedora Update System  changed:

   What|Removed |Added

   Fixed In Version|perl-DBD-Firebird-1.21-1.fc |perl-DBD-Firebird-1.21-1.fc
   |23  |23
   ||perl-DBD-Firebird-1.21-1.fc
   ||22



-- 
You are receiving this mail because:
You are on the CC list for the bug.
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel

[Bug 1267292] Upgrade perl-DBD-Firebird to 1.21

2015-10-11 Thread bugzilla 
https://bugzilla.redhat.com/show_bug.cgi?id=1267292



--- Comment #13 from Fedora Update System  ---
perl-DBD-Firebird-1.21-1.fc22 has been pushed to the Fedora 22 stable
repository. If problems still persist, please make note of it in this bug
report.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel