rawhide report: 20151213 changes

[Fedora Rawhide Report]

Compose started at Sun Dec 13 05:15:02 UTC 2015
Broken deps for i386
--
[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
[bacula]
bacula-director-7.2.0-2.fc24.i686 requires libbaccats-7.2.0.so
bacula-storage-7.2.0-2.fc24.i686 requires libbaccats-7.2.0.so
[eclipse-jbosstools]
eclipse-jbosstools-as-4.2.2-1.fc22.noarch requires 
osgi(org.eclipse.tm.terminal)
[fawkes]
fawkes-core-0.5.0-26.fc24.i686 requires libmicrohttpd.so.10
fawkes-plugin-player-0.5.0-26.fc24.i686 requires libgeos-3.4.2.so
fawkes-plugin-xmlrpc-0.5.0-26.fc24.i686 requires libmicrohttpd.so.10
[gcc-python-plugin]
gcc-python2-debug-plugin-0.14-7.fc24.i686 requires gcc = 0:5.3.1-1.fc24
gcc-python2-plugin-0.14-7.fc24.i686 requires gcc = 0:5.3.1-1.fc24
gcc-python3-debug-plugin-0.14-7.fc24.i686 requires gcc = 0:5.3.1-1.fc24
gcc-python3-plugin-0.14-7.fc24.i686 requires gcc = 0:5.3.1-1.fc24
[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-kubernetes-heapster]
golang-github-kubernetes-heapster-devel-0.16.1-1.fc24.noarch requires 
golang(github.com/google/cadvisor/info/v1)
golang-github-kubernetes-heapster-devel-0.16.1-1.fc24.noarch requires 
golang(github.com/google/cadvisor/client)
golang-github-kubernetes-heapster-devel-0.16.1-1.fc24.noarch requires 
golang(github.com/coreos/fleet/schema)
golang-github-kubernetes-heapster-devel-0.16.1-1.fc24.noarch requires 
golang(github.com/coreos/fleet/registry)
golang-github-kubernetes-heapster-devel-0.16.1-1.fc24.noarch requires 

Re: Easier %config management?

[Jan Kratochvil]

On Sun, 13 Dec 2015 05:58:47 +0100, Christopher wrote:
> For example, I can see which %config files have changed with `rpm -V`, but
> I can't see what the changes actually are unless I do `dnf download
> $myrpm`, extract it, and diff them.

Using this script of mine.  It keeps original unchanged configuration files
from rpm in ~/rpmmerge/** so that you can diff local changes:
http://git.jankratochvil.net/?p=nethome.git;a=blob;f=bin/rpmmerge
One needs to run the command after OS install and best both before+after each
'yum/dnf upgrade'.


> rpmconf is nice, because it helps me easily compare configuration files
> whose user-changes and maintainer-changes conflict... but that's not quite
> the same thing.

Neither rpmconf nor anything else in Fedora keeps the original configuration
file of the installed NVRA.  Therefore after 'yum/dnf upgrade' you have:
  * old-NVRA modified config file
  * new-NVRA original config file
And there is no way to _automatically_ merge them to get the needed:
  * new-NVRA modified config file
Because for that 3-way merge you need also
  * old-NVRA original config file
which is kept (and merged) by my 'rpmmerge' tool above.


> rpmconf might also need modification to support tracking configuration
> management more fully, rather than just for updates.

It should be primarily a default behavior of the default package management
tools.


Jan
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

[Bug 1177819] systemd inside Parallels Virtuozzo VM: Failed at step NO_NEW_PRIVILEGES spawning /usr/sbin/amavisd: Invalid argument

[bugzilla]

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



--- Comment #13 from Peter Bieringer  ---
Meanwhile the underlying Virtuozzo platform got an update to
3.10.0-042stab111.12 and installing the amavisd-new update released last days
runs without any changes (while still having defined: NoNewPrivileges=true)

=> issue can be closed

-- 
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
http://lists.fedoraproject.org/admin/lists/perl-devel@lists.fedoraproject.org

Re: Can Koji handle a soname change and a self-dependency?

[Björn Persson]

Björn Persson wrote:
> Kevin Fenzi  wrote:
> > So, ideally here, there's a new gcc upgrade, the gcc maintainer
> > would build with a compat-libgnat subpackage that installs libgnat
> > in another place. Then they build the new gcc without it. You then
> > can buildrequire that compat-libgnat so you can rebuild other
> > things, then finally do another rebuild without compat-libgnat to
> > bring everything up on the current gcc.
> 
> If I understand this correctly, you mean that the compat-libgnat
> subpackage would remain in the buildroot even after the other
> subpackages were replaced with the later build. Is that right? I
> always thought that when packages are tagged into buildroots, side
> tags and stuff, then all the subpackages from a single source package
> are added or removed together. If it's done with subpackage
> granularity, then that makes things a bit easier.

I made an experiment to test this. I dropped a subpackage and rebuilt.
Once that build was available in Rawhide I tried to rebuild another
package that had a build-time dependency on the dropped subpackage. The
build failed because the subpackage wasn't found. So it is as I thought:
Each new build replaces all subpackages from the previous build, even
those that weren't produced in the new build.

Thus it seems that linking GPRbuild statically is the only solution that
is even close to practical, given the limitations of Koji. I'll
coordinate with Pavel and get to work on it.

Björn Persson


pgpkgsNysR2Bl.pgp
Description: OpenPGP digital signatur
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Can Koji handle a soname change and a self-dependency?

[Björn Persson]

Dan Horák wrote:
> On Mon, 7 Dec 2015 11:32:44 +0100
> Björn Persson  wrote:
> 
> > Kevin Fenzi  wrote:
> > > On Tue, 1 Dec 2015 15:46:26 +0100
> > > Björn Persson  wrote:
> > > > GPRbuild is
> > > > linked to XMLada, and both GPRbuild and XMLada are linked to
> > > > libgnat, as are all other Ada programs and libraries.
> > > >
> > > > With every major GCC upgrade the soname of libgnat changes, and
> > > > all the Ada packages stop working until they get rebuilt. But
> > > > rebuilding requires a working GPRbuild.
> > > >
> > > > Previously a catch-22 was avoided because XMLada and GPRbuild
> > > > were built with Gnatmake, which is built as a part of GCC. Now
> > > > they're both built with GPRbuild instead, and Gnatmake is
> > > > emitting warnings that it's going to lose support for the
> > > > project files that control the build. The next GCC upgrade will
> > > > make the problem acute.
> > >
> > > How are others supposed to handle this?
> > 
> > Other users of the GNAT toolchain? Well, if they don't use Koji then
> 
> maybe Kevin meant other distros - Debian, OpenSUSE - they all use a
> buildsystem

OK, if I read the question as "How does Adacore expect Free Software
distributions to handle this?", then the answer is that I think they
don't care much.

Adacore's paying customers are big corporations and institutions. Those
generally handle tools and libraries in the form of relocatable packages
that they unpack in some directory in their networked filesystem. They
can have multiple versions of each package available, and manipulate
environment variables to point to the one they want to run or link to.
That's the use case that Adacore care about.

Adacore do set their software free, but if you don't pay for a support
contract then you pretty much have to take it or leave it. They may
accept patches, but only if the proposed changes don't inconvenience
them too much. If they have decided that maintaining duplicated code
for project file support in both Gnatmake and GPRbuild is too much
trouble, then they won't change their minds just to make things easier
for Free Software distributions.

If I would complain, then they would probably say that they'll ensure
that each version of GPRbuild can be built by the previous version, and
if Fedora's build system can't handle that, then that's Fedora's
problem. And they would be right.

Björn Persson


pgpQHDqZRjw1Y.pgp
Description: OpenPGP digital signatur
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Easier %config management?

[J. Randall Owens]

On 12/13/2015 01:07 AM, Jan Kratochvil wrote:
> On Sun, 13 Dec 2015 05:58:47 +0100, Christopher wrote:
>> For example, I can see which %config files have changed with `rpm -V`, but
>> I can't see what the changes actually are unless I do `dnf download
>> $myrpm`, extract it, and diff them.
> 
> Using this script of mine.  It keeps original unchanged configuration files
> from rpm in ~/rpmmerge/** so that you can diff local changes:
> http://git.jankratochvil.net/?p=nethome.git;a=blob;f=bin/rpmmerge
> One needs to run the command after OS install and best both before+after each
> 'yum/dnf upgrade'.
> 
> 
>> rpmconf is nice, because it helps me easily compare configuration files
>> whose user-changes and maintainer-changes conflict... but that's not quite
>> the same thing.
> 
> Neither rpmconf nor anything else in Fedora keeps the original configuration
> file of the installed NVRA.  Therefore after 'yum/dnf upgrade' you have:
>   * old-NVRA modified config file
>   * new-NVRA original config file
> And there is no way to _automatically_ merge them to get the needed:
>   * new-NVRA modified config file
> Because for that 3-way merge you need also
>   * old-NVRA original config file
> which is kept (and merged) by my 'rpmmerge' tool above.
> 
> 
>> rpmconf might also need modification to support tracking configuration
>> management more fully, rather than just for updates.
> 
> It should be primarily a default behavior of the default package management
> tools.
> 
> 
> Jan
> 

etckeeper basically makes a git tree of the entire /etc directory, and
automagically commits before & after each yum or dnf transaction (been a
while since I did a raw rpm install or erase, I don't think it kicks in
then though). It's a bit disk-hungry compared to the /etc dir, e.g.
right now I have 89 MiB of actual /etc, plus 142 MiB in the /etc/.git,
but /etc is modest enough that it isn't much of a problem. It does slow
down the yum/dnf transactions a bit, certainly, while git checks for
changes. But yeah, it stores the new, the modified, and the old, and
while I'm not too handy with git yet, I'm pretty sure someone better
with it than I could do that kind of merging you're talking about.

Actually, I take a little of that back; it ignores *.rpm* files, so it
doesn't see the contents of the *.rpmnew. But you'll have that right
there, and can easily work with that.

-- 
J. Randall Owens | http://www.ghiapet.net/



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

[EPEL-devel] Re: Improving EPEL updates process

[Ken Dreyer]

On Sat, Dec 12, 2015 at 7:34 PM, Peter Robinson  wrote:
> 2) Automatic unpushing of updates that haven't gone stable after X
> time (I propose 3 months/90 days here). That should be ample time to
> know if it's good/bad.

Could we make it go the other way, and submit the update to stable if
it's received no feedback for 90 days?

Often I'll let my update sit in epel-testing for a long time because I
want to give users a large window of opportunity to test the update.
It's not that it's abandoned, it's just that it's not an urgent
update, so why rush it? If the update hits the karma threshold earlier
than I expected, so much the better.

- Ken
___
epel-devel mailing list
epel-devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/epel-devel@lists.fedoraproject.org

Re: REMINDER: FESCo, Council, FAmSCo elections

[Joseph Pesco]

On Fri, 2015-12-11 at 13:22 -0700, Chris Murphy wrote:
> On Fri, Dec 11, 2015 at 11:28 AM, Jiri Eischmann  m> wrote:
> > Chris Murphy píše v Pá 11. 12. 2015 v 11:11 -0700:
> > > On Fri, Dec 11, 2015 at 4:58 AM, Jan Kurik 
> > > wrote:
> > > > Hello everyone!
> > > > 
> > > > I just want to remind you about the running Elections for
> > > > FESCo,
> > > > Council, FAmSCo. The voting period in now open and you can vote
> > > > for
> > > > your favourite candidate. The voting period closes promptly at
> > > > 23:59:00 UTC on December 14th.
> > > > 
> > > > If you have not voted yet, please do so:
> > > 
> > > Should a reminder go to users@ and maybe on Fedora Forums?
> > 
> > Those are IMHO primarily for users and users cannot vote AFAIK. I
> > think
> > this messages should go to channels that are primarily for
> > contributors. Sending it to general audience would cause confusion.
> 
> I can't say how commonly contributors aren't on devel or
> devel-announce. But I know developers who are not subscribed to
> either. People who contribute to docs, QA, design/marketing,
> may  very
> well not be subscribe to either devel list, but are still
> contributors.
> 
> With voting participation low the last round, it's seems to me not
> unreasonable to hit more lists with at least a one time reminder.
> 
> Non-inclusive:
> anaconda-devel-l...@redhat.com, test@, docs@, desktop@, server@,
> cloud@, design-team@, security-team@, ambassadors@. This could be
> expanded, with the message phrased to remind that voting is a benefit
> for contributors.
> 

I Just Voted!

Thank you for the reminder!

Joe Pesco
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

[EPEL-devel] Re: Improving EPEL updates process

[Giovanni Tirloni]

On 12/13/2015 01:26 AM, Stephen John Smoogen wrote:

One part of this is that not a lot of people are using 7 compared to
6. This was sort of the case for EL-6 that didn't see a huge jump in
growth until CentOS had EL-6.3 .  Second of all there isn't a lot of
people active in packaging stuff in EPEL as have been in the past
versus the number of people wanting things. If people have ideas and
will be at FOSDEM I would love to talk with you.


I would like to help getting EPEL7 is a better shape because every now 
and them we consider not using it due to outdated packages missing 
security fixes.


I tried to go over the steps required to become a packager and was a bit 
surprised with the overhead (things not related to getting the creating 
the RPM), for a beginner. Do you have any tips to someone just starting 
out? Any updated docs that focus on the bare basics to get things moving?


If improving EPEL7 could be broken into smaller tasks that people can do 
whenever they have time, I think it'd make things move faster.


Thank you,
Giovanni
___
epel-devel mailing list
epel-devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/epel-devel@lists.fedoraproject.org

Fedora Rawhide 20151213 compose check report

[Fedora compose checker]

Missing expected images:

Cloud_atomic disk raw x86_64
Workstation live x86_64
Workstation live i386
Kde disk raw armhfp
Kde live i386
Kde live x86_64

No images in this compose but not Rawhide 20151212

Images in Rawhide 20151212 but not this:

Soas live i386
Lxde live x86_64

Failed openQA tests: 4 of 54

ID: 906 Test: i386 universal package_set_kde
URL: https://openqa.fedoraproject.org/tests/906
ID: 890 Test: x86_64 universal server_software_raid
URL: https://openqa.fedoraproject.org/tests/890
ID: 879 Test: x86_64 universal server_repository_http_graphical
URL: https://openqa.fedoraproject.org/tests/879
ID: 857 Test: x86_64 universal package_set_kde
URL: https://openqa.fedoraproject.org/tests/857

Passed openQA tests: 50 of 54
-- 
Mail generated by check-compose:
https://git.fedorahosted.org/cgit/fedora-qa.git/tree/check-compose
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

orion uploaded ExtUtils-F77-1.19.tar.gz for perl-ExtUtils-F77

[notifications]

5f9a0e1dbd6b322ad897a71d7424a32a  ExtUtils-F77-1.19.tar.gz

http://pkgs.fedoraproject.org/lookaside/pkgs/perl-ExtUtils-F77/ExtUtils-F77-1.19.tar.gz/md5/5f9a0e1dbd6b322ad897a71d7424a32a/ExtUtils-F77-1.19.tar.gz
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/perl-devel@lists.fedoraproject.org

orion pushed to perl-ExtUtils-F77 (master). "Update to 1.19"

[notifications]

>From 6b17ab815d9afff92a6ce0e7fc13a1c3c2d19e08 Mon Sep 17 00:00:00 2001
From: Orion Poplawski 
Date: Sun, 13 Dec 2015 08:22:56 -0700
Subject: Update to 1.19

---
 .gitignore | 1 +
 perl-ExtUtils-F77.spec | 5 -
 sources| 2 +-
 3 files changed, 6 insertions(+), 2 deletions(-)

diff --git a/.gitignore b/.gitignore
index c818431..24197d8 100644
--- a/.gitignore
+++ b/.gitignore
@@ -1,2 +1,3 @@
 ExtUtils-F77-1.16.tar.gz
 /ExtUtils-F77-1.18.tar.gz
+/ExtUtils-F77-1.19.tar.gz
diff --git a/perl-ExtUtils-F77.spec b/perl-ExtUtils-F77.spec
index 1939fe5..1f52524 100644
--- a/perl-ExtUtils-F77.spec
+++ b/perl-ExtUtils-F77.spec
@@ -1,5 +1,5 @@
 Name:   perl-ExtUtils-F77
-Version:1.18
+Version:1.19
 Release:1%{?dist}
 Summary:Simple interface to F77 libs
 License:GPL+ or Artistic
@@ -47,6 +47,9 @@ rm -rf $RPM_BUILD_ROOT
 %{_mandir}/man3/*
 
 %changelog
+* Sun Dec 13 2015 Orion Poplawski  - 1.19-1
+- Update to 1.19
+
 * Mon Jul 13 2015 Orion Poplawski  - 1.18-1
 - Update to 1.18
 
diff --git a/sources b/sources
index 9fb3ea3..8392c2b 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-7a9abbf3c68b96a44a2e0875a0663412  ExtUtils-F77-1.18.tar.gz
+5f9a0e1dbd6b322ad897a71d7424a32a  ExtUtils-F77-1.19.tar.gz
-- 
cgit v0.11.2



http://pkgs.fedoraproject.org/cgit/perl-ExtUtils-F77.git/commit/?h=master=6b17ab815d9afff92a6ce0e7fc13a1c3c2d19e08
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/perl-devel@lists.fedoraproject.org

[Bug 1291028] perl-ExtUtils-F77-1.19 is available

[bugzilla]

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

Orion Poplawski  changed:

   What|Removed |Added

 Status|NEW |CLOSED
 Resolution|--- |RAWHIDE
Last Closed||2015-12-13 10:31:07



-- 
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
http://lists.fedoraproject.org/admin/lists/perl-devel@lists.fedoraproject.org

[Bug 1291028] perl-ExtUtils-F77-1.19 is available

[bugzilla]

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



--- Comment #3 from Upstream Release Monitoring 
 ---
orion's perl-ExtUtils-F77-1.19-1.fc24 completed
http://koji.fedoraproject.org/koji/buildinfo?buildID=705146

-- 
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
http://lists.fedoraproject.org/admin/lists/perl-devel@lists.fedoraproject.org

Re: dnf behavior expected?

[Michael Schwendt]

On Tue, 8 Dec 2015 11:20:34 -0500, Zach Villers wrote:

> > Anything about that in /var/log/dnf*?
> >  
> 
> Yes - here is a grep of "kernel" from /var/log/dnf - you can see the
> kernels that were removed in the transaction -
> http://paste.fedoraproject.org/298642/

Don't use grep for tasks like that. It cuts off context.

There are multiple log files for "dnf". They would clearly show if
any kernel packages have been removed. I doubt that the behaviour for
an increased installonly_limit would be different. E.g /var/log/dnf.log:

| Removed:
|  kernel.x86_64 4.2.5-300.fc23 kernel-core.x86_64 4.2.5-300.fc23   
 
|  kernel-modules.x86_64 4.2.5-300.fc23
|
| Installed:
|  kernel.x86_64 4.2.7-300.fc23 kernel-core.x86_64 4.2.7-300.fc23   
 
|  kernel-modules.x86_64 4.2.7-300.fc23
|
|Upgraded:
[...]

In /var/log/dnf.rpm.log there are individual update status lines,
such as:

| Dec 13 13:52:35 INFO Erased: kernel-4.2.5-300.fc23.x86_64
| Dec 13 13:52:35 INFO Erased: kernel-4.2.5-300.fc23.x86_64

> What does "dnf history info NUMBER" tell about that transaction?
> >  
> 
> dnf history info doesn't warn about the removal of the kernels. Another
> fpaste;
> 
> http://paste.fedoraproject.org/298647/95915451/

That also sounds much like DNF did not install/erase your kernel packages
normally but treated them like ordinary packages. E.g.

Erasekernel-4.2.5-300.fc23.x86_64  @updates
Install  kernel-4.2.7-300.fc23.x86_64  
@updates-testing
Erasekernel-core-4.2.5-300.fc23.x86_64 @updates
Install  kernel-core-4.2.7-300.fc23.x86_64 
@updates-testing
Upgraded kernel-headers-4.2.6-301.fc23.x86_64  @updates
Upgrade 4.2.7-300.fc23.x86_64  
@updates-testing
Erasekernel-modules-4.2.5-300.fc23.x86_64  @updates
Install  kernel-modules-4.2.7-300.fc23.x86_64  
@updates-testing

> installonlypkgs=kernel.x86_64, kernel-core.x86_64, kernel-headers.x86_64,
> kernel-modules.x86_64

That could be the culprit. Why and when did you set this? If memory serves
correctly, the implicit default also covers kernel packages correctly. And
if changing it, it's supposed to be a space separated list, isn't it?
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

[Bug 1291095] Nonresponsive maintainer: jpo

[bugzilla]

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



--- Comment #1 from Denis Fateyev  ---
There are no related records in the vacation table:
https://apps.fedoraproject.org/calendar/list/vacation/

User's activity:
$ ./fedora_active_user.py --user jpo --email jose.p.oliveira@gmail.com
--all-comments --verbose
...
Last login in FAS:
   jpo 2015-09-19
Last action on koji:
   Mon, 07 Dec 2015 package list entry revoked: perl-Test-TCP in epel7 by pkgdb
Last package update on bodhi:
   2015-03-21 11:12:26 on package perl-NetPacket-1.6.0-1.fc22
Last actions performed according to fedmsg:
  - jpo's zeromq3-3.2.5-1.fc23 was deleted on 2015-12-11 20:56:51 ()
  - jpo's zeromq3-3.2.5-1.fc23 untagged from trashcan by oscar on 2015-12-11
20:56:50 ()
  - jpo's perl-ZMQ-LibZMQ3-1.19-1.fc23 was deleted on 2015-12-11 18:52:56 ()
  - jpo's perl-ZMQ-LibZMQ3-1.19-1.fc23 untagged from trashcan by oscar on
2015-12-11 18:52:55 ()
  - jpo's perl-NetPacket-1.6.0-1.fc23 was deleted on 2015-12-11 18:49:11 ()
  - jpo's perl-NetPacket-1.6.0-1.fc23 untagged from trashcan by oscar on
2015-12-11 18:49:10 ()
  - jpo's nagios-plugins-check-updates-1.6.9-1.fc22 was deleted on 2015-12-11
18:03:36 ()
  - jpo's nagios-plugins-check-updates-1.6.9-1.fc22 untagged from trashcan by
oscar on 2015-12-11 18:03:36 ()
  - jpo's nagios-plugins-check-updates-1.6.10-1.fc23 untagged from trashcan by
oscar on 2015-12-11 18:03:35 ()
  - jpo's nagios-plugins-check-updates-1.6.10-1.fc23 was deleted on 2015-12-11
18:03:35 ()
Last email on mailing list:
   No activity found on gmane.linux.redhat.fedora.devel
   No activity found on gmane.linux.redhat.fedora.artwork
   No activity found on gmane.linux.redhat.fedora.desktop
   No activity found on gmane.linux.redhat.fedora.epel.devel
   No activity found on gmane.linux.redhat.fedora.extras.packaging
   No activity found on gmane.linux.redhat.fedora.fonts
   No activity found on gmane.linux.redhat.fedora.general
   No activity found on gmane.linux.redhat.fedora.infrastructure
   No activity found on gmane.linux.redhat.fedora.kde
   No activity found on gmane.linux.redhat.fedora.perl
Bugzilla activity
   88 bugs assigned, cc or on which jose.p.oliveira@gmail.com commented
Last comment on the most recent ticket on bugzilla:
   #1234872 2015-06-27 Jose Pedro Oliveira

-- 
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
http://lists.fedoraproject.org/admin/lists/perl-devel@lists.fedoraproject.org

Re: Easier %config management?

[Reindl Harald]

Am 13.12.2015 um 21:50 schrieb Andrew Lutomirski:

On Dec 13, 2015 12:38 PM, "Reindl Harald" > wrote:
 >
 > Am 13.12.2015 um 21:22 schrieb Andrew Lutomirski:
 >>
 >> For the few cases that can't or won't comply, then having rpm
 >> (optionally?) make the originals available would be fantastic for
 >> system management
 >
 >
 > how many copies would you like to store in the rpm database and how
to access them in a useful manner

Exactly one, for the current installed version.


not terrible helpful


 > honestly:
 > that all violates the unix principles one tool for one task and there
are tools available for config file management many years, people
interested just need to use them, "etckeeper" is integrated in dnf/yum
and makes a versioned "snapshot" of /etc before and after updates are
applied

Since when is there a UNIX principle that, just because a mediocre
solution exists, a better solution shouldn't be added.


how can bloating the rpm-database in a very limited way be a better 
solution than having any changes below /etc versioned over years



In any case, most existing tools really struggle with "what has changed
on my configuration relative to what I'd have if I reinstalled?"


how is rpm here a solution?

how should it know which version is "if I reinstalled" after several 
dist-upgrades - keep the very first version of a config file makes no 
sense - how would a httpd.conf from 2008 help on a Fedora 23 with 
httpd-2.4 and the same for most other package over the time?




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

Re: Easier %config management?

[Andrew Lutomirski]

On Dec 13, 2015 12:38 PM, "Reindl Harald"  wrote:
>
>
>
> Am 13.12.2015 um 21:22 schrieb Andrew Lutomirski:
>>
>> For the few cases that can't or won't comply, then having rpm
>> (optionally?) make the originals available would be fantastic for
>> system management
>
>
> how many copies would you like to store in the rpm database and how to
access them in a useful manner

Exactly one, for the current installed version.

>
> honestly:
> that all violates the unix principles one tool for one task and there are
tools available for config file management many years, people interested
just need to use them, "etckeeper" is integrated in dnf/yum and makes a
versioned "snapshot" of /etc before and after updates are applied

Since when is there a UNIX principle that, just because a mediocre solution
exists, a better solution shouldn't be added.

In any case, most existing tools really struggle with "what has changed on
my configuration relative to what I'd have if I reinstalled?".

>
>
> --
> devel mailing list
> devel@lists.fedoraproject.org
> http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Easier %config management?

[Richard W.M. Jones]

On Sun, Dec 13, 2015 at 04:58:47AM +, Christopher wrote:
> For example, I can see which %config files have changed with `rpm -V`, but
> I can't see what the changes actually are unless I do `dnf download
> $myrpm`, extract it, and diff them. Alternatively, I could rename the
> configuration file, and do a `dnf reinstall $myrpm` to replace the
> original, and then diff them. Both of these methods are clunky, wasteful,
> and not without side-effects.
[...]
> rpm could track more than hashes of config files, and instead track the
> full file. This could be optional, as it uses more disk space, but disk
> space is cheap these days, and config files are relatively small. This
> would avoid having to re-download the rpm, and would make it easier to see
> what has been modified on their system. So, some users may find that a
> worthwhile trade-off.

Supermin has this problem too.  It solves it by downloading the
original RPMs ('dnf download', not 'dnf reinstall'), unpacking them
('rpm2cpio'), etc. but it's a pain in the rear.

  http://libguestfs.org/supermin.1.html

I'm guessing also this is something that Fedora Atomic has had to
solve.

Also, it would be better if packages by default never needed
configuration files.  You would only add a configuration file when you
need to change the default configuration.  A default installation of
Fedora would have an empty /etc (solving your problem ... in a
slightly different way).  Some packages have been heading in this
direction.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
libguestfs lets you edit virtual machines.  Supports shell scripting,
bindings from many languages.  http://libguestfs.org
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Easier %config management?

[Reindl Harald]

Am 13.12.2015 um 05:58 schrieb Christopher:

rpm could track more than hashes of config files, and instead track the
full file. This could be optional, as it uses more disk space, but disk
space is cheap these days, and config files are relatively small. This
would avoid having to re-download the rpm, and would make it easier to
see what has been modified on their system. So, some users may find that
a worthwhile trade-off


first:  disk space is *not* cheap these days *
second: etckeeper exists
third:  no need to re-invent the wheel

99% of all users don't care and the yone who cares using a VCS for /etc 
like "etckeeper" while i never ever would use that directly on 
production servers but on a admin-server pull from the infrastrcuture 
and fire etckepper there - works like a charme for many year


*
disk space maybe cheap for some fire-and-forget machines, but not on 
enterprise storage hosting hundrets of instances




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

[Bug 1291095] New: Nonresponsive maintainer: jpo

[bugzilla]

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

Bug ID: 1291095
   Summary: Nonresponsive maintainer: jpo
   Product: Fedora EPEL
   Version: epel7
 Component: perl-Test-CheckManifest
  Severity: high
  Assignee: jose.p.oliveira@gmail.com
  Reporter: de...@fateyev.com
QA Contact: extras...@fedoraproject.org
CC: jose.p.oliveira@gmail.com,
perl-devel@lists.fedoraproject.org



Description of problem:
As per
https://fedoraproject.org/wiki/Policy_for_nonresponsive_package_maintainers,
I'm initiating the process according the policy above.

There are several bugs in EPEL, namely these ones:

1) RHBZ#1285486: branch epel7 requested for perl-Test-CheckManifest, but never
built there; overall, a deprecated package which requires update.

2) RHBZ#1284623: perl-Test-SharedFork update request, with update details
provided.

3) RHBZ#1282828: perl-Test-TCP update request in epel7, depends on the previous
bug so cannot be sorted directly.

The current EPEL maintainer of the packages above is Jose Pedro Oliveira
("jose.p.oliveira@gmail.com", FAS login: jpo). I've been trying to contact
him since Nov 25, but there is no luck so far. I tried also another address:
"j...@di.uminho.pt", but it doesn't work anymore.

-- 
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
http://lists.fedoraproject.org/admin/lists/perl-devel@lists.fedoraproject.org

Re: Easier %config management?

[Reindl Harald]

Am 13.12.2015 um 21:22 schrieb Andrew Lutomirski:

For the few cases that can't or won't comply, then having rpm
(optionally?) make the originals available would be fantastic for
system management


how many copies would you like to store in the rpm database and how to 
access them in a useful manner


define "originals"

when the system was installed versus current state?
worthless - most of my Fedora setups are from 2008

the current and the previous version?
well, you need to handle cases where a config file is unchanged but the 
package is updated, that's the majority of all updates


honestly:
that all violates the unix principles one tool for one task and there 
are tools available for config file management many years, people 
interested just need to use them, "etckeeper" is integrated in dnf/yum 
and makes a versioned "snapshot" of /etc before and after updates are 
applied




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

Re: Easier %config management?

[Andrew Lutomirski]

On Sat, Dec 12, 2015 at 8:58 PM, Christopher  wrote:
> rpm could track more than hashes of config files, and instead track the full
> file. This could be optional, as it uses more disk space, but disk space is
> cheap these days, and config files are relatively small. This would avoid
> having to re-download the rpm, and would make it easier to see what has been
> modified on their system. So, some users may find that a worthwhile
> trade-off.
>

I rather like this idea.

My laptop has 35MB of /etc contents.  My laptop has 240M of conffiles.
I suspect it has rather less that that in stock conffiles (the
majority is the RPM DB itself, and most of that is presumably shipped
empty).

Doing this might add a considerable incentive for packages to fix the
fact that they have large conffiles.  For example:

106M/usr/lib/locale/locale-archive

excuse me?

80K/usr/share/ghostscript/9.16/Resource/Init/gs_init.ps

not that big, but that has to be a bug.

Buggy things aside, we really should move to a model in which pretty
much everything lives in /usr/share and /etc is just overrides.  For
example:

56K/etc/mime.types
58K/etc/mail/sendmail.cf
60K/etc/mono/2.0/DefaultWsdlHelpGenerator.aspx
60K/etc/mono/4.0/DefaultWsdlHelpGenerator.aspx
60K/etc/mono/4.5/DefaultWsdlHelpGenerator.aspx
64K/etc/pki/nssdb/cert8.db
70K/etc/jwhois.conf
81K/etc/lvm/lvm.conf

For the few cases that can't or won't comply, then having rpm
(optionally?) make the originals available would be fantastic for
system management.

--Andy
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Easier %config management?

[Colin Walters]

On Sun, Dec 13, 2015, at 02:41 PM, Richard W.M. Jones wrote:

> > rpm could track more than hashes of config files, and instead track the
> > full file. This could be optional, as it uses more disk space, but disk
> > space is cheap these days, and config files are relatively small. This
> > would avoid having to re-download the rpm, and would make it easier to see
> > what has been modified on their system. So, some users may find that a
> > worthwhile trade-off.

See below.

> I'm guessing also this is something that Fedora Atomic has had to
> solve.

Yes, OSTree mandates that the config defaults live in /usr/etc and are
immutable, then when creating a "deployment" a 3-way merge is
performed.  Just ls -al /usr/etc on a Fedora Atomic host.
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

2015-12-13 @ 15:00 UTC - Fedora QA Devel Meeting

[Tim Flink]

# Fedora QA Devel Meeting
# Date: 2015-12-13
# Time: 15:00 UTC
(https://fedoraproject.org/wiki/Infrastructure/UTCHowto)
# Location: #fedora-meeting-1 on irc.freenode.net


Please put announcements and information under the "Announcements
and Information" section of the wiki page for this meeting:

https://phab.qadevel.cloud.fedoraproject.org/w/meetings/20151207-fedoraqadevel/

Tim


Proposed Agenda
===

Announcements and Information
-
  - Please list announcements or significant information items below so
the meeting goes faster

Tasking
---
  - Does anyone need tasks to do?

Potential other topics
--
  - beaker
  - Taskotron release date

Open Floor
--
  - TBD


pgpnAIvonlAbl.pgp
Description: OpenPGP digital signature
___
qa-devel mailing list
qa-devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/qa-devel@lists.fedoraproject.org

[Test-Announce] Proposal to CANCEL: 2015-12-14 Fedora QA Meeting

[Adam Williamson]

Hi folks! I'm proposing we cancel Monday's QA meeting. I don't think
there's anything that needs discussion, but if anyone has a topic
for a meeting, please just reply to this mail and we can go ahead and
meet at the usual time. Thanks!
-- 
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
http://lists.fedoraproject.org/admin/lists/test-annou...@lists.fedoraproject.org
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

ppisar uploaded RT-Client-REST-0.50.tar.gz for perl-RT-Client-REST

[notifications]

347cdbffa39d0c57f3797f81cf7ef624  RT-Client-REST-0.50.tar.gz

http://pkgs.fedoraproject.org/lookaside/pkgs/perl-RT-Client-REST/RT-Client-REST-0.50.tar.gz/md5/347cdbffa39d0c57f3797f81cf7ef624/RT-Client-REST-0.50.tar.gz
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/perl-devel@lists.fedoraproject.org

ppisar pushed to perl-RT-Client-REST (master). "0.50 bump"

[notifications]

>From 5a7902f403d5c35e96fc5fbe7e9c00bde787b5b6 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Petr=20P=C3=ADsa=C5=99?= 
Date: Mon, 14 Dec 2015 08:46:29 +0100
Subject: 0.50 bump

---
 .gitignore   |  1 +
 perl-RT-Client-REST.spec | 13 ++---
 sources  |  2 +-
 3 files changed, 12 insertions(+), 4 deletions(-)

diff --git a/.gitignore b/.gitignore
index 32e919e..5cbc9c2 100644
--- a/.gitignore
+++ b/.gitignore
@@ -4,3 +4,4 @@ RT-Client-REST-0.37.tar.gz
 /RT-Client-REST-0.46.tar.gz
 /RT-Client-REST-0.48.tar.gz
 /RT-Client-REST-0.49.tar.gz
+/RT-Client-REST-0.50.tar.gz
diff --git a/perl-RT-Client-REST.spec b/perl-RT-Client-REST.spec
index 2ddbf37..6f32799 100644
--- a/perl-RT-Client-REST.spec
+++ b/perl-RT-Client-REST.spec
@@ -1,12 +1,16 @@
 Name:   perl-RT-Client-REST 
-Version:0.49
-Release:5%{?dist}
+Version:0.50
+Release:1%{?dist}
 License:GPL+ or Artistic
 Group:  Development/Libraries
 Summary:Talk to RT using REST protocol 
 Url:http://search.cpan.org/dist/RT-Client-REST
-Source: 
http://search.cpan.org/CPAN/authors/id/D/DM/DMITRI/RT-Client-REST-%{version}.tar.gz
 
+Source: 
http://search.cpan.org/CPAN/authors/id/S/SR/SRVSH/RT-Client-REST-%{version}.tar.gz
 BuildArch:  noarch
+BuildRequires:  coreutils
+BuildRequires:  glibc-common
+BuildRequires:  findutils
+BuildRequires:  make
 BuildRequires:  perl
 BuildRequires:  perl(inc::Module::Install) >= 0.91
 BuildRequires:  perl(strict)
@@ -76,6 +80,9 @@ make test
 %{_mandir}/man3/*.3*
 
 %changelog
+* Mon Dec 14 2015 Petr Pisar  - 0.50-1
+- 0.50 bump
+
 * Thu Jun 18 2015 Fedora Release Engineering  
- 0.49-5
 - Rebuilt for https://fedoraproject.org/wiki/Fedora_23_Mass_Rebuild
 
diff --git a/sources b/sources
index 0a815b3..4547fb5 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-bd6e101d9d629db09c5be60cbc551f65  RT-Client-REST-0.49.tar.gz
+347cdbffa39d0c57f3797f81cf7ef624  RT-Client-REST-0.50.tar.gz
-- 
cgit v0.11.2



http://pkgs.fedoraproject.org/cgit/perl-RT-Client-REST.git/commit/?h=master=5a7902f403d5c35e96fc5fbe7e9c00bde787b5b6
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/perl-devel@lists.fedoraproject.org

[Bug 1290982] perl-RT-Client-REST-0.50 is available

[bugzilla]

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

Petr Pisar  changed:

   What|Removed |Added

 Status|ASSIGNED|MODIFIED
   Fixed In Version||perl-RT-Client-REST-0.50-1.
   ||fc24



--- Comment #2 from Petr Pisar  ---
Bug fix release suitable for all Fedoras.

-- 
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
http://lists.fedoraproject.org/admin/lists/perl-devel@lists.fedoraproject.org

ppisar pushed to perl-RT-Client-REST (f23). "0.50 bump"

[notifications]

>From 5a7902f403d5c35e96fc5fbe7e9c00bde787b5b6 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Petr=20P=C3=ADsa=C5=99?= 
Date: Mon, 14 Dec 2015 08:46:29 +0100
Subject: 0.50 bump

---
 .gitignore   |  1 +
 perl-RT-Client-REST.spec | 13 ++---
 sources  |  2 +-
 3 files changed, 12 insertions(+), 4 deletions(-)

diff --git a/.gitignore b/.gitignore
index 32e919e..5cbc9c2 100644
--- a/.gitignore
+++ b/.gitignore
@@ -4,3 +4,4 @@ RT-Client-REST-0.37.tar.gz
 /RT-Client-REST-0.46.tar.gz
 /RT-Client-REST-0.48.tar.gz
 /RT-Client-REST-0.49.tar.gz
+/RT-Client-REST-0.50.tar.gz
diff --git a/perl-RT-Client-REST.spec b/perl-RT-Client-REST.spec
index 2ddbf37..6f32799 100644
--- a/perl-RT-Client-REST.spec
+++ b/perl-RT-Client-REST.spec
@@ -1,12 +1,16 @@
 Name:   perl-RT-Client-REST 
-Version:0.49
-Release:5%{?dist}
+Version:0.50
+Release:1%{?dist}
 License:GPL+ or Artistic
 Group:  Development/Libraries
 Summary:Talk to RT using REST protocol 
 Url:http://search.cpan.org/dist/RT-Client-REST
-Source: 
http://search.cpan.org/CPAN/authors/id/D/DM/DMITRI/RT-Client-REST-%{version}.tar.gz
 
+Source: 
http://search.cpan.org/CPAN/authors/id/S/SR/SRVSH/RT-Client-REST-%{version}.tar.gz
 BuildArch:  noarch
+BuildRequires:  coreutils
+BuildRequires:  glibc-common
+BuildRequires:  findutils
+BuildRequires:  make
 BuildRequires:  perl
 BuildRequires:  perl(inc::Module::Install) >= 0.91
 BuildRequires:  perl(strict)
@@ -76,6 +80,9 @@ make test
 %{_mandir}/man3/*.3*
 
 %changelog
+* Mon Dec 14 2015 Petr Pisar  - 0.50-1
+- 0.50 bump
+
 * Thu Jun 18 2015 Fedora Release Engineering  
- 0.49-5
 - Rebuilt for https://fedoraproject.org/wiki/Fedora_23_Mass_Rebuild
 
diff --git a/sources b/sources
index 0a815b3..4547fb5 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-bd6e101d9d629db09c5be60cbc551f65  RT-Client-REST-0.49.tar.gz
+347cdbffa39d0c57f3797f81cf7ef624  RT-Client-REST-0.50.tar.gz
-- 
cgit v0.11.2



http://pkgs.fedoraproject.org/cgit/perl-RT-Client-REST.git/commit/?h=f23=5a7902f403d5c35e96fc5fbe7e9c00bde787b5b6
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/perl-devel@lists.fedoraproject.org

ppisar pushed to perl-RT-Client-REST (f22). "0.50 bump"

[notifications]

>From 2641c319ffbecb774f0b2e0ab371952044353750 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Petr=20P=C3=ADsa=C5=99?= 
Date: Mon, 14 Dec 2015 08:46:29 +0100
Subject: 0.50 bump

---
 .gitignore   |  1 +
 perl-RT-Client-REST.spec | 13 ++---
 sources  |  2 +-
 3 files changed, 12 insertions(+), 4 deletions(-)

diff --git a/.gitignore b/.gitignore
index 32e919e..5cbc9c2 100644
--- a/.gitignore
+++ b/.gitignore
@@ -4,3 +4,4 @@ RT-Client-REST-0.37.tar.gz
 /RT-Client-REST-0.46.tar.gz
 /RT-Client-REST-0.48.tar.gz
 /RT-Client-REST-0.49.tar.gz
+/RT-Client-REST-0.50.tar.gz
diff --git a/perl-RT-Client-REST.spec b/perl-RT-Client-REST.spec
index 901cd1a..1cc7765 100644
--- a/perl-RT-Client-REST.spec
+++ b/perl-RT-Client-REST.spec
@@ -1,12 +1,16 @@
 Name:   perl-RT-Client-REST 
-Version:0.49
-Release:3%{?dist}
+Version:0.50
+Release:1%{?dist}
 License:GPL+ or Artistic
 Group:  Development/Libraries
 Summary:Talk to RT using REST protocol 
 Url:http://search.cpan.org/dist/RT-Client-REST
-Source: 
http://search.cpan.org/CPAN/authors/id/D/DM/DMITRI/RT-Client-REST-%{version}.tar.gz
 
+Source: 
http://search.cpan.org/CPAN/authors/id/S/SR/SRVSH/RT-Client-REST-%{version}.tar.gz
 BuildArch:  noarch
+BuildRequires:  coreutils
+BuildRequires:  glibc-common
+BuildRequires:  findutils
+BuildRequires:  make
 BuildRequires:  perl
 BuildRequires:  perl(inc::Module::Install) >= 0.91
 BuildRequires:  perl(strict)
@@ -76,6 +80,9 @@ make test
 %{_mandir}/man3/*.3*
 
 %changelog
+* Mon Dec 14 2015 Petr Pisar  - 0.50-1
+- 0.50 bump
+
 * Fri Aug 29 2014 Jitka Plesnikova  - 0.49-3
 - Perl 5.20 rebuild
 
diff --git a/sources b/sources
index 0a815b3..4547fb5 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-bd6e101d9d629db09c5be60cbc551f65  RT-Client-REST-0.49.tar.gz
+347cdbffa39d0c57f3797f81cf7ef624  RT-Client-REST-0.50.tar.gz
-- 
cgit v0.11.2



http://pkgs.fedoraproject.org/cgit/perl-RT-Client-REST.git/commit/?h=f22=2641c319ffbecb774f0b2e0ab371952044353750
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/perl-devel@lists.fedoraproject.org

[Bug 1290982] perl-RT-Client-REST-0.50 is available

[bugzilla]

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



--- Comment #3 from Upstream Release Monitoring 
 ---
ppisar's perl-RT-Client-REST-0.50-1.fc24 completed
http://koji.fedoraproject.org/koji/buildinfo?buildID=705322

-- 
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
http://lists.fedoraproject.org/admin/lists/perl-devel@lists.fedoraproject.org

[EPEL-devel] Re: Improving EPEL updates process

[Peter Robinson]

On Mon, Dec 14, 2015 at 3:16 AM, Ken Dreyer  wrote:
> On Sat, Dec 12, 2015 at 7:34 PM, Peter Robinson  wrote:
>> 2) Automatic unpushing of updates that haven't gone stable after X
>> time (I propose 3 months/90 days here). That should be ample time to
>> know if it's good/bad.
>
> Could we make it go the other way, and submit the update to stable if
> it's received no feedback for 90 days?

No, because on two of the 3 I referenced there was bad karma and no
response from the "maintainer" to the feedback.

> Often I'll let my update sit in epel-testing for a long time because I
> want to give users a large window of opportunity to test the update.
> It's not that it's abandoned, it's just that it's not an urgent
> update, so why rush it? If the update hits the karma threshold earlier
> than I expected, so much the better.

I think 90 days is enough to let people test it, ultimately the
maintainer should have done the testing and know the vast majority of
it is good, it should be more to get non standard use cases, corner
cases etc.
___
epel-devel mailing list
epel-devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/epel-devel@lists.fedoraproject.org