[Bug 1282782] perl-Business-Stripe-0.05 is available

[bugzilla]

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



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

-- 
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: Some analysis on the size of the minimal and Server installs, of Fedora 23

[Michael Hampton]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 11/16/2015 08:39 PM, Stephen Gallagher wrote:
> With these two goals in mind, the most obvious approach to improving
> this situation would be by reducing the number of packages installed
> by default on the Minimal and Fedora Server installs. As a specific
> goal of the Server Working Group, we want to aim for a world wherein
> administrators will no longer desire to install the Minimal install
> and instead will rely on the platform provided by the default Fedora
> Server install. They do not do this today because the Fedora Server
> installation is considerably larger. I postulate that this is due
> primarily to dependency bloat, which is where we should focus our
> efforts during the Fedora 24 timeframe. I postulate (but have not yet
> confirmed) that there are likely many places where we could replace
> Requires: with Recommends: (or even Suggests:) dependencies. In my
> ideal world, the difference between a Minimal and Server install would
> be identical to installing the same set of packages with Recommends:
> on or off.

As someone who is using Fedora extensively for both physical and virtual 
servers, I can tell you that dependency bloat _per se_ is not why I use Minimal 
rather than Server as a base for server and virtual machine installs.

Rather, the issue for me is that Server installs many things I simply do not 
need or want.

For instance, while I have Docker container hosts, they are only a small 
percentage of my hosts, and so I do not want Docker installed on every server. 
But Server includes docker out of the box.

And, Server installs things which are only useful for physical machines (or at 
least, virtual machines bridged to the network) such as lldpad, openhpi, etc.

Finally, I'm installing necessary software for each server via Ansible anyway, 
so having something preinstalled, even if I wanted it, isn't very beneficial to 
me.

What I would like to see out of a Server looks a whole lot like Minimal does 
today, with the possible addition of cockpit and rolekit, and _anything_ else 
added either during installation as an optional choice, or after installation 
via rolekit, Ansible, Puppet, or whoever.

Along those lines, I would like to see Anaconda detect whether the system is a 
virtual machine, and automatically select for installation the _appropriate_ 
guest agents for the detected hypervisor, rather than _all_ of them, but this 
doesn't affect Server exclusively.

> Some specific observations I can make:
> * The largest difference in the Fedora Server install vs. the minimal
> install is due to the FreeIPA and Samba packages requiring the
> inclusion of the Python 2 stack; focusing on eliminating this
> requirement in Fedora 24 would have the largest impact on both the
> number of packages and the space on disk.

See above; my recommendation is to cut it to the bare bones, and install 
packages and groups of packages only on demand.

> * The largest individual package in both deployments is the
> glibc-common package. This is primarily due to the 106MiB
> locale-archive. I'd really like to hear from glibc folks if there is
> something we can do to break this up into smaller pieces contained in
> different sub-packages with Suggests: dependencies.

Can these not be split into separate packages per language, and then installed 
only if that language is requested?
-BEGIN PGP SIGNATURE-
Version: GnuPG v2
Comment: GPGTools - http://gpgtools.org

iQIcBAEBCAAGBQJWSwXcAAoJEJICkBIKCqxc8HIP/0W7Si9SB+B9fkBrNYKJ55Na
VUD5h9+UfV8KJPSI/p9fkljHsLait78yMtFGas5bQIDVGwUFaFoDy2FfKj2gAAMQ
FajpEzh6ANaZlKrCi7jle5ZkXP6tNnlbnQ8QnIC855ILbPrB3cfZwnaL1UV0BlF2
u9QwXV6fHJqEdVm4wnJp+Ew0YB0K2dRhY4+dKBkn0ArNzs7lGZyzmCynrQTbk8kP
KlZeVeBKquXP2wI9bNwqfWTnmfXjvulXShB6WgYng1bFmty9Kwp2MjfAm6UfUkza
a72inN0JWR/tTMzlJh+bcDtrzv1G4JENYfemTd5GYuTA25Hk531+0Ir9wbMtiHXG
nzNRY7vow+if4vtPNeUko5BQqgUnRTTe1oVqLGUUmHzm3EOQtw0xC5jOC6lJ80kx
6PadjEb3/g/CVnBoNCYHGabIJKB2xXK7ssw0woaXuVSMHyJ6gt6pM9fvicy3Ejoz
BLFtjE0r3vjjV79P8xo2jSk1unrRzQeD4dN7Wx3TS6ruf0TCv2I/6WY3tT+xu/ry
m5gY41yrkUI6PAzyfBy+0QEpFLfjGtnOVdVyNvd3ZEjJKgiOzUCaTHYmQTIbcHrl
uul6zZC5Xo/HfS0tFVq7GpsmH7P47NNo5eg60YDgXDnUc3zlIXxviIWIw5PEzXo7
fb8Tz/sLwclFvSdvpd5Z
=d7f1
-END PGP SIGNATURE-
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

[Bug 1282782] perl-Business-Stripe-0.05 is available

[bugzilla]

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



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

-- 
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 1282782] New: perl-Business-Stripe-0.05 is available

[bugzilla]

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

Bug ID: 1282782
   Summary: perl-Business-Stripe-0.05 is available
   Product: Fedora
   Version: rawhide
 Component: perl-Business-Stripe
  Keywords: FutureFeature, Triaged
  Assignee: dd...@cpan.org
  Reporter: upstream-release-monitor...@fedoraproject.org
QA Contact: extras...@fedoraproject.org
CC: dd...@cpan.org, perl-devel@lists.fedoraproject.org



Latest upstream release: 0.05
Current version/release in rawhide: 0.04-5.fc23
URL: http://search.cpan.org/dist/Business-Stripe/

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: New (optional) python egg dependency generator for RPM

[Donald Stufft]

> On Nov 17, 2015, at 7:54 AM, Nick Coghlan  wrote:
> 
> On 17 November 2015 at 22:05, Neal Gompa  wrote:
>> On Tue, Nov 17, 2015 at 3:26 AM, Nick Coghlan  wrote:
>>> I'm not clear on what you mean by depending on an egg. Eggs are a
>>> binary format that isn't compatible with Linux distro packaging
>>> policies, since they lose too much structural information regarding
>>> where files should be installed for policy compliance - that's one of
>>> the major reasons we defined the wheel format as a next generation
>>> replacement: https://www.python.org/dev/peps/pep-0427/.
>> 
>> I don't think I've ever heard of this, much less seen it in use. And
>> it looks like the format was approved well over two years ago, so I'm
>> *really* surprised nothing has happened since then.
> 
> We don't currently have real-time stats, but when Donald Stufft ran
> PyPI's download stats back in April, wheels represented about 20% of
> all downloads, while eggs had dropped to 2-3% (from ~5% a year
> earlier): https://caremad.io/2015/04/a-year-of-pypi-downloads/

Another stat that I just computed, Eggs have had.. what 15 years? or so
as a format and in that time they have accumulated 41,060 eggs uploaded
to PyPI. In the uh, 2 or 3 years that Wheels have been around they have
accumulated 38,720 total files on PyPI. We’re close to having Wheels
beat Eggs in both the download counts and the number of files available.


> 
>> Variants of this generator are in use in both Mandriva and Mageia,
> 
> Ah, that's likely to have an impact. The upstream distutils-sig and
> python-dev lists don't include any Mageia/Mandriva users that I'm
> aware of, so that's likely to delay downstream community awareness of
> changes in upstream recommendations. We currently only have close
> collaborations with Debian, Ubuntu, Fedora and RHEL/CentOS due to
> overlapping developer communities.
> 
>> and
>> I wanted to give the Python SIG in Fedora the opportunity to try it
>> out and see if we might want to enable it in Fedora.
>> 
>> Essentially, for things that have egg info that includes the
>> requirements and the name of the module, it makes it simpler to figure
>> out what how to install Python packages in a more cross-distro manner.
> 
> Having a plugin to automatically generate appropriate upstream
> Provides/Requires to allow installation based on PyPI distribution
> names definitely has the potential to be useful. It was only the
> choice of "python2egg" and "python3egg" as the name that threw me,
> since that doesn't align with the upstream community terminology (the
> egg format is specific to setuptools and easy_install)

This sounds like it’s actually use the “other” Egg (because for maximum
confusion setuptools eggs are actually like 3 different things). Right now
both distutils and setuptools will generate an egg-info metadata when
installing projects (though distutils generates a file and setuptools a
directory). However wheels install a dist-info directory.

I don’t have a better suggestion for name other than I’d prefer not to bake
more things onto the “egg” terminology since we (Python packaging upstream)
are trying to phase it out.

-
Donald Stufft
PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
python-devel mailing list
python-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/python-devel

Re: New (optional) python egg dependency generator for RPM

[Donald Stufft]

> On Nov 17, 2015, at 8:25 AM, Neal Gompa  wrote:
> 
> On Tue, Nov 17, 2015 at 8:05 AM, Donald Stufft  wrote:
>> 
>>> On Nov 17, 2015, at 7:54 AM, Nick Coghlan  wrote:
>>> 
>>> On 17 November 2015 at 22:05, Neal Gompa  wrote:
 and
 I wanted to give the Python SIG in Fedora the opportunity to try it
 out and see if we might want to enable it in Fedora.
 
 Essentially, for things that have egg info that includes the
 requirements and the name of the module, it makes it simpler to figure
 out what how to install Python packages in a more cross-distro manner.
>>> 
>>> Having a plugin to automatically generate appropriate upstream
>>> Provides/Requires to allow installation based on PyPI distribution
>>> names definitely has the potential to be useful. It was only the
>>> choice of "python2egg" and "python3egg" as the name that threw me,
>>> since that doesn't align with the upstream community terminology (the
>>> egg format is specific to setuptools and easy_install)
>> 
>> This sounds like it’s actually use the “other” Egg (because for maximum
>> confusion setuptools eggs are actually like 3 different things). Right now
>> both distutils and setuptools will generate an egg-info metadata when
>> installing projects (though distutils generates a file and setuptools a
>> directory). However wheels install a dist-info directory.
>> 
>> I don’t have a better suggestion for name other than I’d prefer not to bake
>> more things onto the “egg” terminology since we (Python packaging upstream)
>> are trying to phase it out.
>> 
> 
> Is the format inside of the .dist-info directory the same as the older
> .egg-info and .egg-link directories? If so, it should be easy to add
> to read that information too.

Currently yes. In the future we’ll probably evolve it and then they’ll drift
apart. Part of doing that though will be defining a way to determine what
“version” of standard the directory is currently using (with the current version
being a not very well defined version 0 or something).

> 
> As for naming, I'm all ears for a better name, because if the "egg"
> name is going away, I'd rather it not continue to say that.
> 
> 
> 
> --
> 真実はいつも一つ！/ Always, there's only one truth!
> ___
> python-devel mailing list
> python-devel@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/python-devel


-
Donald Stufft
PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
python-devel mailing list
python-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/python-devel

Self Introduction: Oyvind Albrigtsen

[Oyvind Albrigtsen]

Hi,

I am the new resource-agents maintainer at Red Hat taking over for David 
Vossel.


I am looking for a sponsor, so I can maintain the Fedora version as well.

My Review Request can be found at:
https://bugzilla.redhat.com/show_bug.cgi?id=1268228


Regards
Oyvind Albrigtsen
Software Engineer
Red Hat
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

spot requested branch epel7 for package perl-File-Copy-Recursive

[notifications]

spot requested branch epel7 for package perl-File-Copy-Recursive
https://admin.fedoraproject.org/pkgdb/package/perl-File-Copy-Recursive/
--
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: Some analysis on the size of the minimal and Server installs of Fedora 23

[Adam Jackson]

On Mon, 2015-11-16 at 20:39 -0500, Stephen Gallagher wrote:

>  10 Longest dependency chains 
> b'abrt-addon-python3': 170
> b'abrt-retrace-client': 171
> b'abrt-addon-pstoreoops': 171
> b'abrt-addon-ccpp': 183
> b'abrt-addon-vmcore': 190
> b'rolekit': 196
> b'abrt-cli': 214
> b'cockpit': 216
> b'freeipa-client': 249
> b'fedora-release-server': 252

I'm not sure what you mean by "dependency chain" here, I honestly doubt
we have any A->B->C->... chains between packages exceeding, I dunno, 30
in length. Perhaps this means "installing this package installs a graph
with this many package nodes"?  Or more succinctly, "10 largest
dependency subtrees"?

> * server-hardware-support
>  - lm_sensors: chain 139

A bunch of that is perl.  The old desktop live images fought pretty
hard to keep perl out, I suspect the sysadmin heritage of the stuff in
the server image will make that a bit harder to accomplish.

One other thing the desktop live image had going for it was a concrete
numeric goal to aim for.  Since we're considering disk space in the
context of cloud images, would it make sense to define a target in
terms of (say) dollar cost of storage in Amazon EBS for a year?

> * The largest difference in the Fedora Server install vs. the minimal
> install is due to the FreeIPA and Samba packages requiring the
> inclusion of the Python 2 stack; focusing on eliminating this
> requirement in Fedora 24 would have the largest impact on both the
> number of packages and the space on disk.

Tsk, another instance of "python3 by default" not implying what we
might have hoped.

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

nb pushed to perl-Mail-IMAPClient (epel7). "- Rebuilt for https://fedoraproject.org/wiki/Fedora_21_Mass_Rebuild"

[notifications]

From b53cca25d40be43c9b67ac2e8ae65b3109b2483e Mon Sep 17 00:00:00 2001
From: Dennis Gilmore 
Date: Sat, 7 Jun 2014 01:39:39 -0500
Subject: - Rebuilt for https://fedoraproject.org/wiki/Fedora_21_Mass_Rebuild

---
 perl-Mail-IMAPClient.spec | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/perl-Mail-IMAPClient.spec b/perl-Mail-IMAPClient.spec
index bd516e9..29ff321 100644
--- a/perl-Mail-IMAPClient.spec
+++ b/perl-Mail-IMAPClient.spec
@@ -1,6 +1,6 @@
 Name:   perl-Mail-IMAPClient
 Version:3.35
-Release:1%{?dist}
+Release:2%{?dist}
 Summary:An IMAP Client API
 Group:  Development/Libraries
 License:GPL+ or Artistic
@@ -52,6 +52,9 @@ rm -rf $RPM_BUILD_ROOT
 %{_mandir}/man3/*.3*
 
 %changelog
+* Sat Jun 07 2014 Fedora Release Engineering  
- 3.35-2
+- Rebuilt for https://fedoraproject.org/wiki/Fedora_21_Mass_Rebuild
+
 * Thu Mar 13 2014 Nick Bebout  - 3.35-1
 - Upgrade to 3.35
 
-- 
cgit v0.11.2



http://pkgs.fedoraproject.org/cgit/perl-Mail-IMAPClient.git/commit/?h=epel7=b53cca25d40be43c9b67ac2e8ae65b3109b2483e
--
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

nb pushed to perl-Mail-IMAPClient (f21). "3.37"

[notifications]

From 7b916e79e0f8837a9249bbb05d3bc385e2d8f8f7 Mon Sep 17 00:00:00 2001
From: Tom Callaway 
Date: Thu, 24 Sep 2015 15:32:00 -0400
Subject: 3.37

---
 .gitignore| 1 +
 perl-Mail-IMAPClient.spec | 8 ++--
 sources   | 2 +-
 3 files changed, 8 insertions(+), 3 deletions(-)

diff --git a/.gitignore b/.gitignore
index dc3947b..4b3bc52 100644
--- a/.gitignore
+++ b/.gitignore
@@ -7,3 +7,4 @@ Mail-IMAPClient-3.25.tar.gz
 /Mail-IMAPClient-3.33.tar.gz
 /Mail-IMAPClient-3.34.tar.gz
 /Mail-IMAPClient-3.35.tar.gz
+/Mail-IMAPClient-3.37.tar.gz
diff --git a/perl-Mail-IMAPClient.spec b/perl-Mail-IMAPClient.spec
index a794264..9d5e5c6 100644
--- a/perl-Mail-IMAPClient.spec
+++ b/perl-Mail-IMAPClient.spec
@@ -1,6 +1,6 @@
 Name:   perl-Mail-IMAPClient
-Version:3.35
-Release:5%{?dist}
+Version:3.37
+Release:1%{?dist}
 Summary:An IMAP Client API
 Group:  Development/Libraries
 License:GPL+ or Artistic
@@ -10,6 +10,7 @@ BuildRoot:  
%{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
 BuildRequires:  perl(ExtUtils::MakeMaker), perl(IO::Socket), perl(constant), 
perl(Socket)
 BuildRequires:  perl(IO::File), perl(IO::Select), perl(Fcntl), perl(Errno), 
perl(Carp)
 BuildRequires:  perl(Data::Dumper), perl(Parse::RecDescent), perl(Test::More)
+BuildRequires: perl(Authen::SASL)
 BuildArch:  noarch
 Requires:  perl(:MODULE_COMPAT_%(eval "`%{__perl} -V:version`"; echo $version))
 
@@ -52,6 +53,9 @@ rm -rf $RPM_BUILD_ROOT
 %{_mandir}/man3/*.3*
 
 %changelog
+* Thu Sep 24 2015 Tom Callaway  - 3.37-1
+- update to 3.37
+
 * Thu Jun 18 2015 Fedora Release Engineering  
- 3.35-5
 - Rebuilt for https://fedoraproject.org/wiki/Fedora_23_Mass_Rebuild
 
diff --git a/sources b/sources
index 24bdd1a..967a7ee 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-b1d79827aeb28ba5f73a03eed5c540e6  Mail-IMAPClient-3.35.tar.gz
+123b36cbfcfc136b59611aa87782a4cc  Mail-IMAPClient-3.37.tar.gz
-- 
cgit v0.11.2



http://pkgs.fedoraproject.org/cgit/perl-Mail-IMAPClient.git/commit/?h=f21=7b916e79e0f8837a9249bbb05d3bc385e2d8f8f7
--
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

nb pushed to perl-Mail-IMAPClient (epel7). "Perl 5.20 rebuild"

[notifications]

From 0012040e63d7b1ac023a5beefbe1e27ac70fe7ca Mon Sep 17 00:00:00 2001
From: Jitka Plesnikova 
Date: Thu, 28 Aug 2014 04:51:12 +0200
Subject: Perl 5.20 rebuild

---
 perl-Mail-IMAPClient.spec | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/perl-Mail-IMAPClient.spec b/perl-Mail-IMAPClient.spec
index 29ff321..018eb93 100644
--- a/perl-Mail-IMAPClient.spec
+++ b/perl-Mail-IMAPClient.spec
@@ -1,6 +1,6 @@
 Name:   perl-Mail-IMAPClient
 Version:3.35
-Release:2%{?dist}
+Release:3%{?dist}
 Summary:An IMAP Client API
 Group:  Development/Libraries
 License:GPL+ or Artistic
@@ -52,6 +52,9 @@ rm -rf $RPM_BUILD_ROOT
 %{_mandir}/man3/*.3*
 
 %changelog
+* Thu Aug 28 2014 Jitka Plesnikova  - 3.35-3
+- Perl 5.20 rebuild
+
 * Sat Jun 07 2014 Fedora Release Engineering  
- 3.35-2
 - Rebuilt for https://fedoraproject.org/wiki/Fedora_21_Mass_Rebuild
 
-- 
cgit v0.11.2



http://pkgs.fedoraproject.org/cgit/perl-Mail-IMAPClient.git/commit/?h=epel7=0012040e63d7b1ac023a5beefbe1e27ac70fe7ca
--
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

nb pushed to perl-Mail-IMAPClient (f21). "- Rebuilt for https://fedoraproject.org/wiki/Fedora_23_Mass_Rebuild"

[notifications]

From d00c72975c1bd9251fce9a5b81fac697aed17e80 Mon Sep 17 00:00:00 2001
From: Dennis Gilmore 
Date: Thu, 18 Jun 2015 04:17:10 +
Subject: - Rebuilt for https://fedoraproject.org/wiki/Fedora_23_Mass_Rebuild

---
 perl-Mail-IMAPClient.spec | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/perl-Mail-IMAPClient.spec b/perl-Mail-IMAPClient.spec
index ee3a6bf..a794264 100644
--- a/perl-Mail-IMAPClient.spec
+++ b/perl-Mail-IMAPClient.spec
@@ -1,6 +1,6 @@
 Name:   perl-Mail-IMAPClient
 Version:3.35
-Release:4%{?dist}
+Release:5%{?dist}
 Summary:An IMAP Client API
 Group:  Development/Libraries
 License:GPL+ or Artistic
@@ -52,6 +52,9 @@ rm -rf $RPM_BUILD_ROOT
 %{_mandir}/man3/*.3*
 
 %changelog
+* Thu Jun 18 2015 Fedora Release Engineering  
- 3.35-5
+- Rebuilt for https://fedoraproject.org/wiki/Fedora_23_Mass_Rebuild
+
 * Fri Jun 05 2015 Jitka Plesnikova  - 3.35-4
 - Perl 5.22 rebuild
 
-- 
cgit v0.11.2



http://pkgs.fedoraproject.org/cgit/perl-Mail-IMAPClient.git/commit/?h=f21=d00c72975c1bd9251fce9a5b81fac697aed17e80
--
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

nb pushed to perl-Mail-IMAPClient (f21). "Perl 5.20 rebuild"

[notifications]

From 0012040e63d7b1ac023a5beefbe1e27ac70fe7ca Mon Sep 17 00:00:00 2001
From: Jitka Plesnikova 
Date: Thu, 28 Aug 2014 04:51:12 +0200
Subject: Perl 5.20 rebuild

---
 perl-Mail-IMAPClient.spec | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/perl-Mail-IMAPClient.spec b/perl-Mail-IMAPClient.spec
index 29ff321..018eb93 100644
--- a/perl-Mail-IMAPClient.spec
+++ b/perl-Mail-IMAPClient.spec
@@ -1,6 +1,6 @@
 Name:   perl-Mail-IMAPClient
 Version:3.35
-Release:2%{?dist}
+Release:3%{?dist}
 Summary:An IMAP Client API
 Group:  Development/Libraries
 License:GPL+ or Artistic
@@ -52,6 +52,9 @@ rm -rf $RPM_BUILD_ROOT
 %{_mandir}/man3/*.3*
 
 %changelog
+* Thu Aug 28 2014 Jitka Plesnikova  - 3.35-3
+- Perl 5.20 rebuild
+
 * Sat Jun 07 2014 Fedora Release Engineering  
- 3.35-2
 - Rebuilt for https://fedoraproject.org/wiki/Fedora_21_Mass_Rebuild
 
-- 
cgit v0.11.2



http://pkgs.fedoraproject.org/cgit/perl-Mail-IMAPClient.git/commit/?h=f21=0012040e63d7b1ac023a5beefbe1e27ac70fe7ca
--
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

nb pushed to perl-Mail-IMAPClient (f21). "Perl 5.22 rebuild"

[notifications]

From c5911fab3e4d1a4a611c0c3d5f3f6296609b8c55 Mon Sep 17 00:00:00 2001
From: Jitka Plesnikova 
Date: Fri, 5 Jun 2015 15:04:44 +0200
Subject: Perl 5.22 rebuild

---
 perl-Mail-IMAPClient.spec | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/perl-Mail-IMAPClient.spec b/perl-Mail-IMAPClient.spec
index 018eb93..ee3a6bf 100644
--- a/perl-Mail-IMAPClient.spec
+++ b/perl-Mail-IMAPClient.spec
@@ -1,6 +1,6 @@
 Name:   perl-Mail-IMAPClient
 Version:3.35
-Release:3%{?dist}
+Release:4%{?dist}
 Summary:An IMAP Client API
 Group:  Development/Libraries
 License:GPL+ or Artistic
@@ -52,6 +52,9 @@ rm -rf $RPM_BUILD_ROOT
 %{_mandir}/man3/*.3*
 
 %changelog
+* Fri Jun 05 2015 Jitka Plesnikova  - 3.35-4
+- Perl 5.22 rebuild
+
 * Thu Aug 28 2014 Jitka Plesnikova  - 3.35-3
 - Perl 5.20 rebuild
 
-- 
cgit v0.11.2



http://pkgs.fedoraproject.org/cgit/perl-Mail-IMAPClient.git/commit/?h=f21=c5911fab3e4d1a4a611c0c3d5f3f6296609b8c55
--
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

nb pushed to perl-Mail-IMAPClient (epel7). "Update to 3.35"

[notifications]

From 25b3e783363f53f4f63d871d1ca2765ab8fb81f8 Mon Sep 17 00:00:00 2001
From: Nick Bebout 
Date: Thu, 13 Mar 2014 18:30:41 -0500
Subject: Update to 3.35

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

diff --git a/.gitignore b/.gitignore
index c120b19..dc3947b 100644
--- a/.gitignore
+++ b/.gitignore
@@ -6,3 +6,4 @@ Mail-IMAPClient-3.25.tar.gz
 /Mail-IMAPClient-3.32.tar.gz
 /Mail-IMAPClient-3.33.tar.gz
 /Mail-IMAPClient-3.34.tar.gz
+/Mail-IMAPClient-3.35.tar.gz
diff --git a/perl-Mail-IMAPClient.spec b/perl-Mail-IMAPClient.spec
index e06f206..bd516e9 100644
--- a/perl-Mail-IMAPClient.spec
+++ b/perl-Mail-IMAPClient.spec
@@ -1,5 +1,5 @@
 Name:   perl-Mail-IMAPClient
-Version:3.34
+Version:3.35
 Release:1%{?dist}
 Summary:An IMAP Client API
 Group:  Development/Libraries
@@ -52,6 +52,9 @@ rm -rf $RPM_BUILD_ROOT
 %{_mandir}/man3/*.3*
 
 %changelog
+* Thu Mar 13 2014 Nick Bebout  - 3.35-1
+- Upgrade to 3.35
+
 * Thu Oct 17 2013 Nick Bebout  - 3.34-1
 - Upgrade to 3.34
 
diff --git a/sources b/sources
index afda7a7..24bdd1a 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-163427d32f5fd7f53f1bd8adf1b639f2  Mail-IMAPClient-3.34.tar.gz
+b1d79827aeb28ba5f73a03eed5c540e6  Mail-IMAPClient-3.35.tar.gz
-- 
cgit v0.11.2



http://pkgs.fedoraproject.org/cgit/perl-Mail-IMAPClient.git/commit/?h=epel7=25b3e783363f53f4f63d871d1ca2765ab8fb81f8
--
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

nb pushed to perl-Mail-IMAPClient (epel7). "Perl 5.22 rebuild"

[notifications]

From c5911fab3e4d1a4a611c0c3d5f3f6296609b8c55 Mon Sep 17 00:00:00 2001
From: Jitka Plesnikova 
Date: Fri, 5 Jun 2015 15:04:44 +0200
Subject: Perl 5.22 rebuild

---
 perl-Mail-IMAPClient.spec | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/perl-Mail-IMAPClient.spec b/perl-Mail-IMAPClient.spec
index 018eb93..ee3a6bf 100644
--- a/perl-Mail-IMAPClient.spec
+++ b/perl-Mail-IMAPClient.spec
@@ -1,6 +1,6 @@
 Name:   perl-Mail-IMAPClient
 Version:3.35
-Release:3%{?dist}
+Release:4%{?dist}
 Summary:An IMAP Client API
 Group:  Development/Libraries
 License:GPL+ or Artistic
@@ -52,6 +52,9 @@ rm -rf $RPM_BUILD_ROOT
 %{_mandir}/man3/*.3*
 
 %changelog
+* Fri Jun 05 2015 Jitka Plesnikova  - 3.35-4
+- Perl 5.22 rebuild
+
 * Thu Aug 28 2014 Jitka Plesnikova  - 3.35-3
 - Perl 5.20 rebuild
 
-- 
cgit v0.11.2



http://pkgs.fedoraproject.org/cgit/perl-Mail-IMAPClient.git/commit/?h=epel7=c5911fab3e4d1a4a611c0c3d5f3f6296609b8c55
--
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

nb pushed to perl-Mail-IMAPClient (el5). "Perl 5.18 rebuild"

[notifications]

From f0da96ed198f3f835a1628ff836099cb854e7eb6 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Petr=20P=C3=ADsa=C5=99?= 
Date: Mon, 22 Jul 2013 21:53:47 +0200
Subject: Perl 5.18 rebuild

---
 perl-Mail-IMAPClient.spec | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/perl-Mail-IMAPClient.spec b/perl-Mail-IMAPClient.spec
index 44a68ad..bc1c436 100644
--- a/perl-Mail-IMAPClient.spec
+++ b/perl-Mail-IMAPClient.spec
@@ -1,6 +1,6 @@
 Name:   perl-Mail-IMAPClient
 Version:3.33
-Release:1%{?dist}
+Release:2%{?dist}
 Summary:An IMAP Client API
 Group:  Development/Libraries
 License:GPL+ or Artistic
@@ -52,6 +52,9 @@ rm -rf $RPM_BUILD_ROOT
 %{_mandir}/man3/*.3*
 
 %changelog
+* Mon Jul 22 2013 Petr Pisar  - 3.33-2
+- Perl 5.18 rebuild
+
 * Tue May 21 2013 Nick Bebout  - 3.33-1
 - Upgrade to 3.33
 
-- 
cgit v0.11.2



http://pkgs.fedoraproject.org/cgit/perl-Mail-IMAPClient.git/commit/?h=el5=f0da96ed198f3f835a1628ff836099cb854e7eb6
--
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

nb pushed to perl-Mail-IMAPClient (el6). "3.37"

[notifications]

From 7b916e79e0f8837a9249bbb05d3bc385e2d8f8f7 Mon Sep 17 00:00:00 2001
From: Tom Callaway 
Date: Thu, 24 Sep 2015 15:32:00 -0400
Subject: 3.37

---
 .gitignore| 1 +
 perl-Mail-IMAPClient.spec | 8 ++--
 sources   | 2 +-
 3 files changed, 8 insertions(+), 3 deletions(-)

diff --git a/.gitignore b/.gitignore
index dc3947b..4b3bc52 100644
--- a/.gitignore
+++ b/.gitignore
@@ -7,3 +7,4 @@ Mail-IMAPClient-3.25.tar.gz
 /Mail-IMAPClient-3.33.tar.gz
 /Mail-IMAPClient-3.34.tar.gz
 /Mail-IMAPClient-3.35.tar.gz
+/Mail-IMAPClient-3.37.tar.gz
diff --git a/perl-Mail-IMAPClient.spec b/perl-Mail-IMAPClient.spec
index a794264..9d5e5c6 100644
--- a/perl-Mail-IMAPClient.spec
+++ b/perl-Mail-IMAPClient.spec
@@ -1,6 +1,6 @@
 Name:   perl-Mail-IMAPClient
-Version:3.35
-Release:5%{?dist}
+Version:3.37
+Release:1%{?dist}
 Summary:An IMAP Client API
 Group:  Development/Libraries
 License:GPL+ or Artistic
@@ -10,6 +10,7 @@ BuildRoot:  
%{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
 BuildRequires:  perl(ExtUtils::MakeMaker), perl(IO::Socket), perl(constant), 
perl(Socket)
 BuildRequires:  perl(IO::File), perl(IO::Select), perl(Fcntl), perl(Errno), 
perl(Carp)
 BuildRequires:  perl(Data::Dumper), perl(Parse::RecDescent), perl(Test::More)
+BuildRequires: perl(Authen::SASL)
 BuildArch:  noarch
 Requires:  perl(:MODULE_COMPAT_%(eval "`%{__perl} -V:version`"; echo $version))
 
@@ -52,6 +53,9 @@ rm -rf $RPM_BUILD_ROOT
 %{_mandir}/man3/*.3*
 
 %changelog
+* Thu Sep 24 2015 Tom Callaway  - 3.37-1
+- update to 3.37
+
 * Thu Jun 18 2015 Fedora Release Engineering  
- 3.35-5
 - Rebuilt for https://fedoraproject.org/wiki/Fedora_23_Mass_Rebuild
 
diff --git a/sources b/sources
index 24bdd1a..967a7ee 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-b1d79827aeb28ba5f73a03eed5c540e6  Mail-IMAPClient-3.35.tar.gz
+123b36cbfcfc136b59611aa87782a4cc  Mail-IMAPClient-3.37.tar.gz
-- 
cgit v0.11.2



http://pkgs.fedoraproject.org/cgit/perl-Mail-IMAPClient.git/commit/?h=el6=7b916e79e0f8837a9249bbb05d3bc385e2d8f8f7
--
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

nb pushed to perl-Mail-IMAPClient (el6). "Perl 5.20 rebuild"

[notifications]

From 0012040e63d7b1ac023a5beefbe1e27ac70fe7ca Mon Sep 17 00:00:00 2001
From: Jitka Plesnikova 
Date: Thu, 28 Aug 2014 04:51:12 +0200
Subject: Perl 5.20 rebuild

---
 perl-Mail-IMAPClient.spec | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/perl-Mail-IMAPClient.spec b/perl-Mail-IMAPClient.spec
index 29ff321..018eb93 100644
--- a/perl-Mail-IMAPClient.spec
+++ b/perl-Mail-IMAPClient.spec
@@ -1,6 +1,6 @@
 Name:   perl-Mail-IMAPClient
 Version:3.35
-Release:2%{?dist}
+Release:3%{?dist}
 Summary:An IMAP Client API
 Group:  Development/Libraries
 License:GPL+ or Artistic
@@ -52,6 +52,9 @@ rm -rf $RPM_BUILD_ROOT
 %{_mandir}/man3/*.3*
 
 %changelog
+* Thu Aug 28 2014 Jitka Plesnikova  - 3.35-3
+- Perl 5.20 rebuild
+
 * Sat Jun 07 2014 Fedora Release Engineering  
- 3.35-2
 - Rebuilt for https://fedoraproject.org/wiki/Fedora_21_Mass_Rebuild
 
-- 
cgit v0.11.2



http://pkgs.fedoraproject.org/cgit/perl-Mail-IMAPClient.git/commit/?h=el6=0012040e63d7b1ac023a5beefbe1e27ac70fe7ca
--
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

nb pushed to perl-Mail-IMAPClient (el6). "- Rebuilt for https://fedoraproject.org/wiki/Fedora_23_Mass_Rebuild"

[notifications]

From d00c72975c1bd9251fce9a5b81fac697aed17e80 Mon Sep 17 00:00:00 2001
From: Dennis Gilmore 
Date: Thu, 18 Jun 2015 04:17:10 +
Subject: - Rebuilt for https://fedoraproject.org/wiki/Fedora_23_Mass_Rebuild

---
 perl-Mail-IMAPClient.spec | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/perl-Mail-IMAPClient.spec b/perl-Mail-IMAPClient.spec
index ee3a6bf..a794264 100644
--- a/perl-Mail-IMAPClient.spec
+++ b/perl-Mail-IMAPClient.spec
@@ -1,6 +1,6 @@
 Name:   perl-Mail-IMAPClient
 Version:3.35
-Release:4%{?dist}
+Release:5%{?dist}
 Summary:An IMAP Client API
 Group:  Development/Libraries
 License:GPL+ or Artistic
@@ -52,6 +52,9 @@ rm -rf $RPM_BUILD_ROOT
 %{_mandir}/man3/*.3*
 
 %changelog
+* Thu Jun 18 2015 Fedora Release Engineering  
- 3.35-5
+- Rebuilt for https://fedoraproject.org/wiki/Fedora_23_Mass_Rebuild
+
 * Fri Jun 05 2015 Jitka Plesnikova  - 3.35-4
 - Perl 5.22 rebuild
 
-- 
cgit v0.11.2



http://pkgs.fedoraproject.org/cgit/perl-Mail-IMAPClient.git/commit/?h=el6=d00c72975c1bd9251fce9a5b81fac697aed17e80
--
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

nb pushed to perl-Mail-IMAPClient (el6). "Perl 5.22 rebuild"

[notifications]

From c5911fab3e4d1a4a611c0c3d5f3f6296609b8c55 Mon Sep 17 00:00:00 2001
From: Jitka Plesnikova 
Date: Fri, 5 Jun 2015 15:04:44 +0200
Subject: Perl 5.22 rebuild

---
 perl-Mail-IMAPClient.spec | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/perl-Mail-IMAPClient.spec b/perl-Mail-IMAPClient.spec
index 018eb93..ee3a6bf 100644
--- a/perl-Mail-IMAPClient.spec
+++ b/perl-Mail-IMAPClient.spec
@@ -1,6 +1,6 @@
 Name:   perl-Mail-IMAPClient
 Version:3.35
-Release:3%{?dist}
+Release:4%{?dist}
 Summary:An IMAP Client API
 Group:  Development/Libraries
 License:GPL+ or Artistic
@@ -52,6 +52,9 @@ rm -rf $RPM_BUILD_ROOT
 %{_mandir}/man3/*.3*
 
 %changelog
+* Fri Jun 05 2015 Jitka Plesnikova  - 3.35-4
+- Perl 5.22 rebuild
+
 * Thu Aug 28 2014 Jitka Plesnikova  - 3.35-3
 - Perl 5.20 rebuild
 
-- 
cgit v0.11.2



http://pkgs.fedoraproject.org/cgit/perl-Mail-IMAPClient.git/commit/?h=el6=c5911fab3e4d1a4a611c0c3d5f3f6296609b8c55
--
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

nb pushed to perl-Mail-IMAPClient (el5). "- Rebuilt for https://fedoraproject.org/wiki/Fedora_21_Mass_Rebuild"

[notifications]

From b53cca25d40be43c9b67ac2e8ae65b3109b2483e Mon Sep 17 00:00:00 2001
From: Dennis Gilmore 
Date: Sat, 7 Jun 2014 01:39:39 -0500
Subject: - Rebuilt for https://fedoraproject.org/wiki/Fedora_21_Mass_Rebuild

---
 perl-Mail-IMAPClient.spec | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/perl-Mail-IMAPClient.spec b/perl-Mail-IMAPClient.spec
index bd516e9..29ff321 100644
--- a/perl-Mail-IMAPClient.spec
+++ b/perl-Mail-IMAPClient.spec
@@ -1,6 +1,6 @@
 Name:   perl-Mail-IMAPClient
 Version:3.35
-Release:1%{?dist}
+Release:2%{?dist}
 Summary:An IMAP Client API
 Group:  Development/Libraries
 License:GPL+ or Artistic
@@ -52,6 +52,9 @@ rm -rf $RPM_BUILD_ROOT
 %{_mandir}/man3/*.3*
 
 %changelog
+* Sat Jun 07 2014 Fedora Release Engineering  
- 3.35-2
+- Rebuilt for https://fedoraproject.org/wiki/Fedora_21_Mass_Rebuild
+
 * Thu Mar 13 2014 Nick Bebout  - 3.35-1
 - Upgrade to 3.35
 
-- 
cgit v0.11.2



http://pkgs.fedoraproject.org/cgit/perl-Mail-IMAPClient.git/commit/?h=el5=b53cca25d40be43c9b67ac2e8ae65b3109b2483e
--
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

nb pushed to perl-Mail-IMAPClient (el5). "3.37"

[notifications]

From 7b916e79e0f8837a9249bbb05d3bc385e2d8f8f7 Mon Sep 17 00:00:00 2001
From: Tom Callaway 
Date: Thu, 24 Sep 2015 15:32:00 -0400
Subject: 3.37

---
 .gitignore| 1 +
 perl-Mail-IMAPClient.spec | 8 ++--
 sources   | 2 +-
 3 files changed, 8 insertions(+), 3 deletions(-)

diff --git a/.gitignore b/.gitignore
index dc3947b..4b3bc52 100644
--- a/.gitignore
+++ b/.gitignore
@@ -7,3 +7,4 @@ Mail-IMAPClient-3.25.tar.gz
 /Mail-IMAPClient-3.33.tar.gz
 /Mail-IMAPClient-3.34.tar.gz
 /Mail-IMAPClient-3.35.tar.gz
+/Mail-IMAPClient-3.37.tar.gz
diff --git a/perl-Mail-IMAPClient.spec b/perl-Mail-IMAPClient.spec
index a794264..9d5e5c6 100644
--- a/perl-Mail-IMAPClient.spec
+++ b/perl-Mail-IMAPClient.spec
@@ -1,6 +1,6 @@
 Name:   perl-Mail-IMAPClient
-Version:3.35
-Release:5%{?dist}
+Version:3.37
+Release:1%{?dist}
 Summary:An IMAP Client API
 Group:  Development/Libraries
 License:GPL+ or Artistic
@@ -10,6 +10,7 @@ BuildRoot:  
%{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
 BuildRequires:  perl(ExtUtils::MakeMaker), perl(IO::Socket), perl(constant), 
perl(Socket)
 BuildRequires:  perl(IO::File), perl(IO::Select), perl(Fcntl), perl(Errno), 
perl(Carp)
 BuildRequires:  perl(Data::Dumper), perl(Parse::RecDescent), perl(Test::More)
+BuildRequires: perl(Authen::SASL)
 BuildArch:  noarch
 Requires:  perl(:MODULE_COMPAT_%(eval "`%{__perl} -V:version`"; echo $version))
 
@@ -52,6 +53,9 @@ rm -rf $RPM_BUILD_ROOT
 %{_mandir}/man3/*.3*
 
 %changelog
+* Thu Sep 24 2015 Tom Callaway  - 3.37-1
+- update to 3.37
+
 * Thu Jun 18 2015 Fedora Release Engineering  
- 3.35-5
 - Rebuilt for https://fedoraproject.org/wiki/Fedora_23_Mass_Rebuild
 
diff --git a/sources b/sources
index 24bdd1a..967a7ee 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-b1d79827aeb28ba5f73a03eed5c540e6  Mail-IMAPClient-3.35.tar.gz
+123b36cbfcfc136b59611aa87782a4cc  Mail-IMAPClient-3.37.tar.gz
-- 
cgit v0.11.2



http://pkgs.fedoraproject.org/cgit/perl-Mail-IMAPClient.git/commit/?h=el5=7b916e79e0f8837a9249bbb05d3bc385e2d8f8f7
--
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

nb pushed to perl-Mail-IMAPClient (el5). "- Rebuilt for https://fedoraproject.org/wiki/Fedora_23_Mass_Rebuild"

[notifications]

From d00c72975c1bd9251fce9a5b81fac697aed17e80 Mon Sep 17 00:00:00 2001
From: Dennis Gilmore 
Date: Thu, 18 Jun 2015 04:17:10 +
Subject: - Rebuilt for https://fedoraproject.org/wiki/Fedora_23_Mass_Rebuild

---
 perl-Mail-IMAPClient.spec | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/perl-Mail-IMAPClient.spec b/perl-Mail-IMAPClient.spec
index ee3a6bf..a794264 100644
--- a/perl-Mail-IMAPClient.spec
+++ b/perl-Mail-IMAPClient.spec
@@ -1,6 +1,6 @@
 Name:   perl-Mail-IMAPClient
 Version:3.35
-Release:4%{?dist}
+Release:5%{?dist}
 Summary:An IMAP Client API
 Group:  Development/Libraries
 License:GPL+ or Artistic
@@ -52,6 +52,9 @@ rm -rf $RPM_BUILD_ROOT
 %{_mandir}/man3/*.3*
 
 %changelog
+* Thu Jun 18 2015 Fedora Release Engineering  
- 3.35-5
+- Rebuilt for https://fedoraproject.org/wiki/Fedora_23_Mass_Rebuild
+
 * Fri Jun 05 2015 Jitka Plesnikova  - 3.35-4
 - Perl 5.22 rebuild
 
-- 
cgit v0.11.2



http://pkgs.fedoraproject.org/cgit/perl-Mail-IMAPClient.git/commit/?h=el5=d00c72975c1bd9251fce9a5b81fac697aed17e80
--
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

nb pushed to perl-Mail-IMAPClient (el5). "Update to 3.35"

[notifications]

From 25b3e783363f53f4f63d871d1ca2765ab8fb81f8 Mon Sep 17 00:00:00 2001
From: Nick Bebout 
Date: Thu, 13 Mar 2014 18:30:41 -0500
Subject: Update to 3.35

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

diff --git a/.gitignore b/.gitignore
index c120b19..dc3947b 100644
--- a/.gitignore
+++ b/.gitignore
@@ -6,3 +6,4 @@ Mail-IMAPClient-3.25.tar.gz
 /Mail-IMAPClient-3.32.tar.gz
 /Mail-IMAPClient-3.33.tar.gz
 /Mail-IMAPClient-3.34.tar.gz
+/Mail-IMAPClient-3.35.tar.gz
diff --git a/perl-Mail-IMAPClient.spec b/perl-Mail-IMAPClient.spec
index e06f206..bd516e9 100644
--- a/perl-Mail-IMAPClient.spec
+++ b/perl-Mail-IMAPClient.spec
@@ -1,5 +1,5 @@
 Name:   perl-Mail-IMAPClient
-Version:3.34
+Version:3.35
 Release:1%{?dist}
 Summary:An IMAP Client API
 Group:  Development/Libraries
@@ -52,6 +52,9 @@ rm -rf $RPM_BUILD_ROOT
 %{_mandir}/man3/*.3*
 
 %changelog
+* Thu Mar 13 2014 Nick Bebout  - 3.35-1
+- Upgrade to 3.35
+
 * Thu Oct 17 2013 Nick Bebout  - 3.34-1
 - Upgrade to 3.34
 
diff --git a/sources b/sources
index afda7a7..24bdd1a 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-163427d32f5fd7f53f1bd8adf1b639f2  Mail-IMAPClient-3.34.tar.gz
+b1d79827aeb28ba5f73a03eed5c540e6  Mail-IMAPClient-3.35.tar.gz
-- 
cgit v0.11.2



http://pkgs.fedoraproject.org/cgit/perl-Mail-IMAPClient.git/commit/?h=el5=25b3e783363f53f4f63d871d1ca2765ab8fb81f8
--
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

nb pushed to perl-Mail-IMAPClient (el6). "Merge branch 'master' into el6"

[notifications]

From 25b3e783363f53f4f63d871d1ca2765ab8fb81f8 Mon Sep 17 00:00:00 2001
From: Nick Bebout 
Date: Thu, 13 Mar 2014 18:30:41 -0500
Subject: Update to 3.35

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

diff --git a/.gitignore b/.gitignore
index c120b19..dc3947b 100644
--- a/.gitignore
+++ b/.gitignore
@@ -6,3 +6,4 @@ Mail-IMAPClient-3.25.tar.gz
 /Mail-IMAPClient-3.32.tar.gz
 /Mail-IMAPClient-3.33.tar.gz
 /Mail-IMAPClient-3.34.tar.gz
+/Mail-IMAPClient-3.35.tar.gz
diff --git a/perl-Mail-IMAPClient.spec b/perl-Mail-IMAPClient.spec
index e06f206..bd516e9 100644
--- a/perl-Mail-IMAPClient.spec
+++ b/perl-Mail-IMAPClient.spec
@@ -1,5 +1,5 @@
 Name:   perl-Mail-IMAPClient
-Version:3.34
+Version:3.35
 Release:1%{?dist}
 Summary:An IMAP Client API
 Group:  Development/Libraries
@@ -52,6 +52,9 @@ rm -rf $RPM_BUILD_ROOT
 %{_mandir}/man3/*.3*
 
 %changelog
+* Thu Mar 13 2014 Nick Bebout  - 3.35-1
+- Upgrade to 3.35
+
 * Thu Oct 17 2013 Nick Bebout  - 3.34-1
 - Upgrade to 3.34
 
diff --git a/sources b/sources
index afda7a7..24bdd1a 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-163427d32f5fd7f53f1bd8adf1b639f2  Mail-IMAPClient-3.34.tar.gz
+b1d79827aeb28ba5f73a03eed5c540e6  Mail-IMAPClient-3.35.tar.gz
-- 
cgit v0.11.2


From b53cca25d40be43c9b67ac2e8ae65b3109b2483e Mon Sep 17 00:00:00 2001
From: Dennis Gilmore 
Date: Sat, 7 Jun 2014 01:39:39 -0500
Subject: - Rebuilt for https://fedoraproject.org/wiki/Fedora_21_Mass_Rebuild

---
 perl-Mail-IMAPClient.spec | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/perl-Mail-IMAPClient.spec b/perl-Mail-IMAPClient.spec
index bd516e9..29ff321 100644
--- a/perl-Mail-IMAPClient.spec
+++ b/perl-Mail-IMAPClient.spec
@@ -1,6 +1,6 @@
 Name:   perl-Mail-IMAPClient
 Version:3.35
-Release:1%{?dist}
+Release:2%{?dist}
 Summary:An IMAP Client API
 Group:  Development/Libraries
 License:GPL+ or Artistic
@@ -52,6 +52,9 @@ rm -rf $RPM_BUILD_ROOT
 %{_mandir}/man3/*.3*
 
 %changelog
+* Sat Jun 07 2014 Fedora Release Engineering  
- 3.35-2
+- Rebuilt for https://fedoraproject.org/wiki/Fedora_21_Mass_Rebuild
+
 * Thu Mar 13 2014 Nick Bebout  - 3.35-1
 - Upgrade to 3.35
 
-- 
cgit v0.11.2


From 0012040e63d7b1ac023a5beefbe1e27ac70fe7ca Mon Sep 17 00:00:00 2001
From: Jitka Plesnikova 
Date: Thu, 28 Aug 2014 04:51:12 +0200
Subject: Perl 5.20 rebuild

---
 perl-Mail-IMAPClient.spec | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/perl-Mail-IMAPClient.spec b/perl-Mail-IMAPClient.spec
index 29ff321..018eb93 100644
--- a/perl-Mail-IMAPClient.spec
+++ b/perl-Mail-IMAPClient.spec
@@ -1,6 +1,6 @@
 Name:   perl-Mail-IMAPClient
 Version:3.35
-Release:2%{?dist}
+Release:3%{?dist}
 Summary:An IMAP Client API
 Group:  Development/Libraries
 License:GPL+ or Artistic
@@ -52,6 +52,9 @@ rm -rf $RPM_BUILD_ROOT
 %{_mandir}/man3/*.3*
 
 %changelog
+* Thu Aug 28 2014 Jitka Plesnikova  - 3.35-3
+- Perl 5.20 rebuild
+
 * Sat Jun 07 2014 Fedora Release Engineering  
- 3.35-2
 - Rebuilt for https://fedoraproject.org/wiki/Fedora_21_Mass_Rebuild
 
-- 
cgit v0.11.2


From c5911fab3e4d1a4a611c0c3d5f3f6296609b8c55 Mon Sep 17 00:00:00 2001
From: Jitka Plesnikova 
Date: Fri, 5 Jun 2015 15:04:44 +0200
Subject: Perl 5.22 rebuild

---
 perl-Mail-IMAPClient.spec | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/perl-Mail-IMAPClient.spec b/perl-Mail-IMAPClient.spec
index 018eb93..ee3a6bf 100644
--- a/perl-Mail-IMAPClient.spec
+++ b/perl-Mail-IMAPClient.spec
@@ -1,6 +1,6 @@
 Name:   perl-Mail-IMAPClient
 Version:3.35
-Release:3%{?dist}
+Release:4%{?dist}
 Summary:An IMAP Client API
 Group:  Development/Libraries
 License:GPL+ or Artistic
@@ -52,6 +52,9 @@ rm -rf $RPM_BUILD_ROOT
 %{_mandir}/man3/*.3*
 
 %changelog
+* Fri Jun 05 2015 Jitka Plesnikova  - 3.35-4
+- Perl 5.22 rebuild
+
 * Thu Aug 28 2014 Jitka Plesnikova  - 3.35-3
 - Perl 5.20 rebuild
 
-- 
cgit v0.11.2


From d00c72975c1bd9251fce9a5b81fac697aed17e80 Mon Sep 17 00:00:00 2001
From: Dennis Gilmore 
Date: Thu, 18 Jun 2015 04:17:10 +
Subject: - Rebuilt for https://fedoraproject.org/wiki/Fedora_23_Mass_Rebuild

---
 perl-Mail-IMAPClient.spec | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/perl-Mail-IMAPClient.spec b/perl-Mail-IMAPClient.spec
index ee3a6bf..a794264 100644
--- a/perl-Mail-IMAPClient.spec
+++ b/perl-Mail-IMAPClient.spec
@@ -1,6 +1,6 @@
 Name:   

nb pushed to perl-Mail-IMAPClient (el5). "- Rebuilt for https://fedoraproject.org/wiki/Fedora_20_Mass_Rebuild"

[notifications]

From fa12adadbf634d4652a664e7fc2e50500ed30257 Mon Sep 17 00:00:00 2001
From: Dennis Gilmore 
Date: Sat, 3 Aug 2013 18:02:24 -0500
Subject: - Rebuilt for https://fedoraproject.org/wiki/Fedora_20_Mass_Rebuild

---
 perl-Mail-IMAPClient.spec | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/perl-Mail-IMAPClient.spec b/perl-Mail-IMAPClient.spec
index bc1c436..b5dd9ae 100644
--- a/perl-Mail-IMAPClient.spec
+++ b/perl-Mail-IMAPClient.spec
@@ -1,6 +1,6 @@
 Name:   perl-Mail-IMAPClient
 Version:3.33
-Release:2%{?dist}
+Release:3%{?dist}
 Summary:An IMAP Client API
 Group:  Development/Libraries
 License:GPL+ or Artistic
@@ -52,6 +52,9 @@ rm -rf $RPM_BUILD_ROOT
 %{_mandir}/man3/*.3*
 
 %changelog
+* Sat Aug 03 2013 Fedora Release Engineering  
- 3.33-3
+- Rebuilt for https://fedoraproject.org/wiki/Fedora_20_Mass_Rebuild
+
 * Mon Jul 22 2013 Petr Pisar  - 3.33-2
 - Perl 5.18 rebuild
 
-- 
cgit v0.11.2



http://pkgs.fedoraproject.org/cgit/perl-Mail-IMAPClient.git/commit/?h=el5=fa12adadbf634d4652a664e7fc2e50500ed30257
--
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

nb pushed to perl-Mail-IMAPClient (el5). "Perl 5.22 rebuild"

[notifications]

From c5911fab3e4d1a4a611c0c3d5f3f6296609b8c55 Mon Sep 17 00:00:00 2001
From: Jitka Plesnikova 
Date: Fri, 5 Jun 2015 15:04:44 +0200
Subject: Perl 5.22 rebuild

---
 perl-Mail-IMAPClient.spec | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/perl-Mail-IMAPClient.spec b/perl-Mail-IMAPClient.spec
index 018eb93..ee3a6bf 100644
--- a/perl-Mail-IMAPClient.spec
+++ b/perl-Mail-IMAPClient.spec
@@ -1,6 +1,6 @@
 Name:   perl-Mail-IMAPClient
 Version:3.35
-Release:3%{?dist}
+Release:4%{?dist}
 Summary:An IMAP Client API
 Group:  Development/Libraries
 License:GPL+ or Artistic
@@ -52,6 +52,9 @@ rm -rf $RPM_BUILD_ROOT
 %{_mandir}/man3/*.3*
 
 %changelog
+* Fri Jun 05 2015 Jitka Plesnikova  - 3.35-4
+- Perl 5.22 rebuild
+
 * Thu Aug 28 2014 Jitka Plesnikova  - 3.35-3
 - Perl 5.20 rebuild
 
-- 
cgit v0.11.2



http://pkgs.fedoraproject.org/cgit/perl-Mail-IMAPClient.git/commit/?h=el5=c5911fab3e4d1a4a611c0c3d5f3f6296609b8c55
--
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: Guidelines unclear for unretire of a branch

[Haïkel]

2015-11-17 15:02 GMT+01:00 Richard Shaw :
> I would like to unretire the epel7 branch of LibRaw, per the guidelines[1]
> this woudl require a re-review, but that would only make sense if the whole
> package was retired, not an epel branch.
>
> Why would we re-review something that still have active branches
> (specifically rawhide)?
>
> Thanks,
> Richard
>
> [1] https://fedoraproject.org/wiki/PackageDB_admin_requests#Other_requests
>


It has been retired because it's in RHEL7, hence it can't be shipped
in EPEL (cf. pkgdb)

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

nb pushed to perl-Mail-IMAPClient (f22). "3.37"

[notifications]

From 7b916e79e0f8837a9249bbb05d3bc385e2d8f8f7 Mon Sep 17 00:00:00 2001
From: Tom Callaway 
Date: Thu, 24 Sep 2015 15:32:00 -0400
Subject: 3.37

---
 .gitignore| 1 +
 perl-Mail-IMAPClient.spec | 8 ++--
 sources   | 2 +-
 3 files changed, 8 insertions(+), 3 deletions(-)

diff --git a/.gitignore b/.gitignore
index dc3947b..4b3bc52 100644
--- a/.gitignore
+++ b/.gitignore
@@ -7,3 +7,4 @@ Mail-IMAPClient-3.25.tar.gz
 /Mail-IMAPClient-3.33.tar.gz
 /Mail-IMAPClient-3.34.tar.gz
 /Mail-IMAPClient-3.35.tar.gz
+/Mail-IMAPClient-3.37.tar.gz
diff --git a/perl-Mail-IMAPClient.spec b/perl-Mail-IMAPClient.spec
index a794264..9d5e5c6 100644
--- a/perl-Mail-IMAPClient.spec
+++ b/perl-Mail-IMAPClient.spec
@@ -1,6 +1,6 @@
 Name:   perl-Mail-IMAPClient
-Version:3.35
-Release:5%{?dist}
+Version:3.37
+Release:1%{?dist}
 Summary:An IMAP Client API
 Group:  Development/Libraries
 License:GPL+ or Artistic
@@ -10,6 +10,7 @@ BuildRoot:  
%{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
 BuildRequires:  perl(ExtUtils::MakeMaker), perl(IO::Socket), perl(constant), 
perl(Socket)
 BuildRequires:  perl(IO::File), perl(IO::Select), perl(Fcntl), perl(Errno), 
perl(Carp)
 BuildRequires:  perl(Data::Dumper), perl(Parse::RecDescent), perl(Test::More)
+BuildRequires: perl(Authen::SASL)
 BuildArch:  noarch
 Requires:  perl(:MODULE_COMPAT_%(eval "`%{__perl} -V:version`"; echo $version))
 
@@ -52,6 +53,9 @@ rm -rf $RPM_BUILD_ROOT
 %{_mandir}/man3/*.3*
 
 %changelog
+* Thu Sep 24 2015 Tom Callaway  - 3.37-1
+- update to 3.37
+
 * Thu Jun 18 2015 Fedora Release Engineering  
- 3.35-5
 - Rebuilt for https://fedoraproject.org/wiki/Fedora_23_Mass_Rebuild
 
diff --git a/sources b/sources
index 24bdd1a..967a7ee 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-b1d79827aeb28ba5f73a03eed5c540e6  Mail-IMAPClient-3.35.tar.gz
+123b36cbfcfc136b59611aa87782a4cc  Mail-IMAPClient-3.37.tar.gz
-- 
cgit v0.11.2



http://pkgs.fedoraproject.org/cgit/perl-Mail-IMAPClient.git/commit/?h=f22=7b916e79e0f8837a9249bbb05d3bc385e2d8f8f7
--
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: Guidelines unclear for unretire of a branch

[Richard Shaw]

On Tue, Nov 17, 2015 at 8:54 AM, Haïkel  wrote:

>
> It has been retired because it's in RHEL7, hence it can't be shipped
> in EPEL (cf. pkgdb)


Ahh, I've mostly been concentrating on el6 trying to unbundle as much as I
can from freeimage while addressing the CVE on it. So I can cancel that
request.

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

nb pushed to perl-Mail-IMAPClient (f22). "Perl 5.22 rebuild"

[notifications]

From c5911fab3e4d1a4a611c0c3d5f3f6296609b8c55 Mon Sep 17 00:00:00 2001
From: Jitka Plesnikova 
Date: Fri, 5 Jun 2015 15:04:44 +0200
Subject: Perl 5.22 rebuild

---
 perl-Mail-IMAPClient.spec | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/perl-Mail-IMAPClient.spec b/perl-Mail-IMAPClient.spec
index 018eb93..ee3a6bf 100644
--- a/perl-Mail-IMAPClient.spec
+++ b/perl-Mail-IMAPClient.spec
@@ -1,6 +1,6 @@
 Name:   perl-Mail-IMAPClient
 Version:3.35
-Release:3%{?dist}
+Release:4%{?dist}
 Summary:An IMAP Client API
 Group:  Development/Libraries
 License:GPL+ or Artistic
@@ -52,6 +52,9 @@ rm -rf $RPM_BUILD_ROOT
 %{_mandir}/man3/*.3*
 
 %changelog
+* Fri Jun 05 2015 Jitka Plesnikova  - 3.35-4
+- Perl 5.22 rebuild
+
 * Thu Aug 28 2014 Jitka Plesnikova  - 3.35-3
 - Perl 5.20 rebuild
 
-- 
cgit v0.11.2



http://pkgs.fedoraproject.org/cgit/perl-Mail-IMAPClient.git/commit/?h=f22=c5911fab3e4d1a4a611c0c3d5f3f6296609b8c55
--
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

nb pushed to perl-Mail-IMAPClient (f22). "- Rebuilt for https://fedoraproject.org/wiki/Fedora_23_Mass_Rebuild"

[notifications]

From d00c72975c1bd9251fce9a5b81fac697aed17e80 Mon Sep 17 00:00:00 2001
From: Dennis Gilmore 
Date: Thu, 18 Jun 2015 04:17:10 +
Subject: - Rebuilt for https://fedoraproject.org/wiki/Fedora_23_Mass_Rebuild

---
 perl-Mail-IMAPClient.spec | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/perl-Mail-IMAPClient.spec b/perl-Mail-IMAPClient.spec
index ee3a6bf..a794264 100644
--- a/perl-Mail-IMAPClient.spec
+++ b/perl-Mail-IMAPClient.spec
@@ -1,6 +1,6 @@
 Name:   perl-Mail-IMAPClient
 Version:3.35
-Release:4%{?dist}
+Release:5%{?dist}
 Summary:An IMAP Client API
 Group:  Development/Libraries
 License:GPL+ or Artistic
@@ -52,6 +52,9 @@ rm -rf $RPM_BUILD_ROOT
 %{_mandir}/man3/*.3*
 
 %changelog
+* Thu Jun 18 2015 Fedora Release Engineering  
- 3.35-5
+- Rebuilt for https://fedoraproject.org/wiki/Fedora_23_Mass_Rebuild
+
 * Fri Jun 05 2015 Jitka Plesnikova  - 3.35-4
 - Perl 5.22 rebuild
 
-- 
cgit v0.11.2



http://pkgs.fedoraproject.org/cgit/perl-Mail-IMAPClient.git/commit/?h=f22=d00c72975c1bd9251fce9a5b81fac697aed17e80
--
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

nb pushed to perl-Mail-IMAPClient (el5). "Upgrade to 3.34"

[notifications]

From 99505473d3a7bda0d730ff36dd445acc90635950 Mon Sep 17 00:00:00 2001
From: Nick Bebout 
Date: Thu, 17 Oct 2013 21:00:55 -0500
Subject: Upgrade to 3.34

---
 .gitignore| 1 +
 perl-Mail-IMAPClient.spec | 7 +--
 sources   | 2 +-
 3 files changed, 7 insertions(+), 3 deletions(-)

diff --git a/.gitignore b/.gitignore
index fad3fec..c120b19 100644
--- a/.gitignore
+++ b/.gitignore
@@ -5,3 +5,4 @@ Mail-IMAPClient-3.25.tar.gz
 /Mail-IMAPClient-3.31.tar.gz
 /Mail-IMAPClient-3.32.tar.gz
 /Mail-IMAPClient-3.33.tar.gz
+/Mail-IMAPClient-3.34.tar.gz
diff --git a/perl-Mail-IMAPClient.spec b/perl-Mail-IMAPClient.spec
index b5dd9ae..e06f206 100644
--- a/perl-Mail-IMAPClient.spec
+++ b/perl-Mail-IMAPClient.spec
@@ -1,6 +1,6 @@
 Name:   perl-Mail-IMAPClient
-Version:3.33
-Release:3%{?dist}
+Version:3.34
+Release:1%{?dist}
 Summary:An IMAP Client API
 Group:  Development/Libraries
 License:GPL+ or Artistic
@@ -52,6 +52,9 @@ rm -rf $RPM_BUILD_ROOT
 %{_mandir}/man3/*.3*
 
 %changelog
+* Thu Oct 17 2013 Nick Bebout  - 3.34-1
+- Upgrade to 3.34
+
 * Sat Aug 03 2013 Fedora Release Engineering  
- 3.33-3
 - Rebuilt for https://fedoraproject.org/wiki/Fedora_20_Mass_Rebuild
 
diff --git a/sources b/sources
index d6a7072..afda7a7 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-d29c3dce4fdfbe35b847f2bf9002ef83  Mail-IMAPClient-3.33.tar.gz
+163427d32f5fd7f53f1bd8adf1b639f2  Mail-IMAPClient-3.34.tar.gz
-- 
cgit v0.11.2



http://pkgs.fedoraproject.org/cgit/perl-Mail-IMAPClient.git/commit/?h=el5=99505473d3a7bda0d730ff36dd445acc90635950
--
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

nb pushed to perl-Mail-IMAPClient (el5). "Perl 5.20 rebuild"

[notifications]

From 0012040e63d7b1ac023a5beefbe1e27ac70fe7ca Mon Sep 17 00:00:00 2001
From: Jitka Plesnikova 
Date: Thu, 28 Aug 2014 04:51:12 +0200
Subject: Perl 5.20 rebuild

---
 perl-Mail-IMAPClient.spec | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/perl-Mail-IMAPClient.spec b/perl-Mail-IMAPClient.spec
index 29ff321..018eb93 100644
--- a/perl-Mail-IMAPClient.spec
+++ b/perl-Mail-IMAPClient.spec
@@ -1,6 +1,6 @@
 Name:   perl-Mail-IMAPClient
 Version:3.35
-Release:2%{?dist}
+Release:3%{?dist}
 Summary:An IMAP Client API
 Group:  Development/Libraries
 License:GPL+ or Artistic
@@ -52,6 +52,9 @@ rm -rf $RPM_BUILD_ROOT
 %{_mandir}/man3/*.3*
 
 %changelog
+* Thu Aug 28 2014 Jitka Plesnikova  - 3.35-3
+- Perl 5.20 rebuild
+
 * Sat Jun 07 2014 Fedora Release Engineering  
- 3.35-2
 - Rebuilt for https://fedoraproject.org/wiki/Fedora_21_Mass_Rebuild
 
-- 
cgit v0.11.2



http://pkgs.fedoraproject.org/cgit/perl-Mail-IMAPClient.git/commit/?h=el5=0012040e63d7b1ac023a5beefbe1e27ac70fe7ca
--
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 1282842] New: perl-Test-PostgreSQL: please add epel7 branch

[bugzilla]

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

Bug ID: 1282842
   Summary: perl-Test-PostgreSQL: please add epel7 branch
   Product: Fedora
   Version: rawhide
 Component: perl-Test-PostgreSQL
  Assignee: ppi...@redhat.com
  Reporter: de...@fateyev.com
QA Contact: extras...@fedoraproject.org
CC: perl-devel@lists.fedoraproject.org, ppi...@redhat.com,
psab...@redhat.com



Please add epel7 branch for `perl-Test-PostgreSQL` package.

Although if nobody interested in maintaining it, I can step in and support it.
Thanks.

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

nb pushed to perl-Mail-IMAPClient (epel7). "3.37"

[notifications]

From 7b916e79e0f8837a9249bbb05d3bc385e2d8f8f7 Mon Sep 17 00:00:00 2001
From: Tom Callaway 
Date: Thu, 24 Sep 2015 15:32:00 -0400
Subject: 3.37

---
 .gitignore| 1 +
 perl-Mail-IMAPClient.spec | 8 ++--
 sources   | 2 +-
 3 files changed, 8 insertions(+), 3 deletions(-)

diff --git a/.gitignore b/.gitignore
index dc3947b..4b3bc52 100644
--- a/.gitignore
+++ b/.gitignore
@@ -7,3 +7,4 @@ Mail-IMAPClient-3.25.tar.gz
 /Mail-IMAPClient-3.33.tar.gz
 /Mail-IMAPClient-3.34.tar.gz
 /Mail-IMAPClient-3.35.tar.gz
+/Mail-IMAPClient-3.37.tar.gz
diff --git a/perl-Mail-IMAPClient.spec b/perl-Mail-IMAPClient.spec
index a794264..9d5e5c6 100644
--- a/perl-Mail-IMAPClient.spec
+++ b/perl-Mail-IMAPClient.spec
@@ -1,6 +1,6 @@
 Name:   perl-Mail-IMAPClient
-Version:3.35
-Release:5%{?dist}
+Version:3.37
+Release:1%{?dist}
 Summary:An IMAP Client API
 Group:  Development/Libraries
 License:GPL+ or Artistic
@@ -10,6 +10,7 @@ BuildRoot:  
%{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
 BuildRequires:  perl(ExtUtils::MakeMaker), perl(IO::Socket), perl(constant), 
perl(Socket)
 BuildRequires:  perl(IO::File), perl(IO::Select), perl(Fcntl), perl(Errno), 
perl(Carp)
 BuildRequires:  perl(Data::Dumper), perl(Parse::RecDescent), perl(Test::More)
+BuildRequires: perl(Authen::SASL)
 BuildArch:  noarch
 Requires:  perl(:MODULE_COMPAT_%(eval "`%{__perl} -V:version`"; echo $version))
 
@@ -52,6 +53,9 @@ rm -rf $RPM_BUILD_ROOT
 %{_mandir}/man3/*.3*
 
 %changelog
+* Thu Sep 24 2015 Tom Callaway  - 3.37-1
+- update to 3.37
+
 * Thu Jun 18 2015 Fedora Release Engineering  
- 3.35-5
 - Rebuilt for https://fedoraproject.org/wiki/Fedora_23_Mass_Rebuild
 
diff --git a/sources b/sources
index 24bdd1a..967a7ee 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-b1d79827aeb28ba5f73a03eed5c540e6  Mail-IMAPClient-3.35.tar.gz
+123b36cbfcfc136b59611aa87782a4cc  Mail-IMAPClient-3.37.tar.gz
-- 
cgit v0.11.2



http://pkgs.fedoraproject.org/cgit/perl-Mail-IMAPClient.git/commit/?h=epel7=7b916e79e0f8837a9249bbb05d3bc385e2d8f8f7
--
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

nb pushed to perl-Mail-IMAPClient (el6). "Update to 3.35"

[notifications]

From 25b3e783363f53f4f63d871d1ca2765ab8fb81f8 Mon Sep 17 00:00:00 2001
From: Nick Bebout 
Date: Thu, 13 Mar 2014 18:30:41 -0500
Subject: Update to 3.35

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

diff --git a/.gitignore b/.gitignore
index c120b19..dc3947b 100644
--- a/.gitignore
+++ b/.gitignore
@@ -6,3 +6,4 @@ Mail-IMAPClient-3.25.tar.gz
 /Mail-IMAPClient-3.32.tar.gz
 /Mail-IMAPClient-3.33.tar.gz
 /Mail-IMAPClient-3.34.tar.gz
+/Mail-IMAPClient-3.35.tar.gz
diff --git a/perl-Mail-IMAPClient.spec b/perl-Mail-IMAPClient.spec
index e06f206..bd516e9 100644
--- a/perl-Mail-IMAPClient.spec
+++ b/perl-Mail-IMAPClient.spec
@@ -1,5 +1,5 @@
 Name:   perl-Mail-IMAPClient
-Version:3.34
+Version:3.35
 Release:1%{?dist}
 Summary:An IMAP Client API
 Group:  Development/Libraries
@@ -52,6 +52,9 @@ rm -rf $RPM_BUILD_ROOT
 %{_mandir}/man3/*.3*
 
 %changelog
+* Thu Mar 13 2014 Nick Bebout  - 3.35-1
+- Upgrade to 3.35
+
 * Thu Oct 17 2013 Nick Bebout  - 3.34-1
 - Upgrade to 3.34
 
diff --git a/sources b/sources
index afda7a7..24bdd1a 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-163427d32f5fd7f53f1bd8adf1b639f2  Mail-IMAPClient-3.34.tar.gz
+b1d79827aeb28ba5f73a03eed5c540e6  Mail-IMAPClient-3.35.tar.gz
-- 
cgit v0.11.2



http://pkgs.fedoraproject.org/cgit/perl-Mail-IMAPClient.git/commit/?h=el6=25b3e783363f53f4f63d871d1ca2765ab8fb81f8
--
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

nb pushed to perl-Mail-IMAPClient (epel7). "- Rebuilt for https://fedoraproject.org/wiki/Fedora_23_Mass_Rebuild"

[notifications]

From d00c72975c1bd9251fce9a5b81fac697aed17e80 Mon Sep 17 00:00:00 2001
From: Dennis Gilmore 
Date: Thu, 18 Jun 2015 04:17:10 +
Subject: - Rebuilt for https://fedoraproject.org/wiki/Fedora_23_Mass_Rebuild

---
 perl-Mail-IMAPClient.spec | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/perl-Mail-IMAPClient.spec b/perl-Mail-IMAPClient.spec
index ee3a6bf..a794264 100644
--- a/perl-Mail-IMAPClient.spec
+++ b/perl-Mail-IMAPClient.spec
@@ -1,6 +1,6 @@
 Name:   perl-Mail-IMAPClient
 Version:3.35
-Release:4%{?dist}
+Release:5%{?dist}
 Summary:An IMAP Client API
 Group:  Development/Libraries
 License:GPL+ or Artistic
@@ -52,6 +52,9 @@ rm -rf $RPM_BUILD_ROOT
 %{_mandir}/man3/*.3*
 
 %changelog
+* Thu Jun 18 2015 Fedora Release Engineering  
- 3.35-5
+- Rebuilt for https://fedoraproject.org/wiki/Fedora_23_Mass_Rebuild
+
 * Fri Jun 05 2015 Jitka Plesnikova  - 3.35-4
 - Perl 5.22 rebuild
 
-- 
cgit v0.11.2



http://pkgs.fedoraproject.org/cgit/perl-Mail-IMAPClient.git/commit/?h=epel7=d00c72975c1bd9251fce9a5b81fac697aed17e80
--
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

nb pushed to perl-Mail-IMAPClient (el6). "- Rebuilt for https://fedoraproject.org/wiki/Fedora_21_Mass_Rebuild"

[notifications]

From b53cca25d40be43c9b67ac2e8ae65b3109b2483e Mon Sep 17 00:00:00 2001
From: Dennis Gilmore 
Date: Sat, 7 Jun 2014 01:39:39 -0500
Subject: - Rebuilt for https://fedoraproject.org/wiki/Fedora_21_Mass_Rebuild

---
 perl-Mail-IMAPClient.spec | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/perl-Mail-IMAPClient.spec b/perl-Mail-IMAPClient.spec
index bd516e9..29ff321 100644
--- a/perl-Mail-IMAPClient.spec
+++ b/perl-Mail-IMAPClient.spec
@@ -1,6 +1,6 @@
 Name:   perl-Mail-IMAPClient
 Version:3.35
-Release:1%{?dist}
+Release:2%{?dist}
 Summary:An IMAP Client API
 Group:  Development/Libraries
 License:GPL+ or Artistic
@@ -52,6 +52,9 @@ rm -rf $RPM_BUILD_ROOT
 %{_mandir}/man3/*.3*
 
 %changelog
+* Sat Jun 07 2014 Fedora Release Engineering  
- 3.35-2
+- Rebuilt for https://fedoraproject.org/wiki/Fedora_21_Mass_Rebuild
+
 * Thu Mar 13 2014 Nick Bebout  - 3.35-1
 - Upgrade to 3.35
 
-- 
cgit v0.11.2



http://pkgs.fedoraproject.org/cgit/perl-Mail-IMAPClient.git/commit/?h=el6=b53cca25d40be43c9b67ac2e8ae65b3109b2483e
--
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

nb pushed to perl-Mail-IMAPClient (el5). "Merge branch 'master' into el5"

[notifications]

From f0da96ed198f3f835a1628ff836099cb854e7eb6 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Petr=20P=C3=ADsa=C5=99?= 
Date: Mon, 22 Jul 2013 21:53:47 +0200
Subject: Perl 5.18 rebuild

---
 perl-Mail-IMAPClient.spec | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/perl-Mail-IMAPClient.spec b/perl-Mail-IMAPClient.spec
index 44a68ad..bc1c436 100644
--- a/perl-Mail-IMAPClient.spec
+++ b/perl-Mail-IMAPClient.spec
@@ -1,6 +1,6 @@
 Name:   perl-Mail-IMAPClient
 Version:3.33
-Release:1%{?dist}
+Release:2%{?dist}
 Summary:An IMAP Client API
 Group:  Development/Libraries
 License:GPL+ or Artistic
@@ -52,6 +52,9 @@ rm -rf $RPM_BUILD_ROOT
 %{_mandir}/man3/*.3*
 
 %changelog
+* Mon Jul 22 2013 Petr Pisar  - 3.33-2
+- Perl 5.18 rebuild
+
 * Tue May 21 2013 Nick Bebout  - 3.33-1
 - Upgrade to 3.33
 
-- 
cgit v0.11.2


From fa12adadbf634d4652a664e7fc2e50500ed30257 Mon Sep 17 00:00:00 2001
From: Dennis Gilmore 
Date: Sat, 3 Aug 2013 18:02:24 -0500
Subject: - Rebuilt for https://fedoraproject.org/wiki/Fedora_20_Mass_Rebuild

---
 perl-Mail-IMAPClient.spec | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/perl-Mail-IMAPClient.spec b/perl-Mail-IMAPClient.spec
index bc1c436..b5dd9ae 100644
--- a/perl-Mail-IMAPClient.spec
+++ b/perl-Mail-IMAPClient.spec
@@ -1,6 +1,6 @@
 Name:   perl-Mail-IMAPClient
 Version:3.33
-Release:2%{?dist}
+Release:3%{?dist}
 Summary:An IMAP Client API
 Group:  Development/Libraries
 License:GPL+ or Artistic
@@ -52,6 +52,9 @@ rm -rf $RPM_BUILD_ROOT
 %{_mandir}/man3/*.3*
 
 %changelog
+* Sat Aug 03 2013 Fedora Release Engineering  
- 3.33-3
+- Rebuilt for https://fedoraproject.org/wiki/Fedora_20_Mass_Rebuild
+
 * Mon Jul 22 2013 Petr Pisar  - 3.33-2
 - Perl 5.18 rebuild
 
-- 
cgit v0.11.2


From 99505473d3a7bda0d730ff36dd445acc90635950 Mon Sep 17 00:00:00 2001
From: Nick Bebout 
Date: Thu, 17 Oct 2013 21:00:55 -0500
Subject: Upgrade to 3.34

---
 .gitignore| 1 +
 perl-Mail-IMAPClient.spec | 7 +--
 sources   | 2 +-
 3 files changed, 7 insertions(+), 3 deletions(-)

diff --git a/.gitignore b/.gitignore
index fad3fec..c120b19 100644
--- a/.gitignore
+++ b/.gitignore
@@ -5,3 +5,4 @@ Mail-IMAPClient-3.25.tar.gz
 /Mail-IMAPClient-3.31.tar.gz
 /Mail-IMAPClient-3.32.tar.gz
 /Mail-IMAPClient-3.33.tar.gz
+/Mail-IMAPClient-3.34.tar.gz
diff --git a/perl-Mail-IMAPClient.spec b/perl-Mail-IMAPClient.spec
index b5dd9ae..e06f206 100644
--- a/perl-Mail-IMAPClient.spec
+++ b/perl-Mail-IMAPClient.spec
@@ -1,6 +1,6 @@
 Name:   perl-Mail-IMAPClient
-Version:3.33
-Release:3%{?dist}
+Version:3.34
+Release:1%{?dist}
 Summary:An IMAP Client API
 Group:  Development/Libraries
 License:GPL+ or Artistic
@@ -52,6 +52,9 @@ rm -rf $RPM_BUILD_ROOT
 %{_mandir}/man3/*.3*
 
 %changelog
+* Thu Oct 17 2013 Nick Bebout  - 3.34-1
+- Upgrade to 3.34
+
 * Sat Aug 03 2013 Fedora Release Engineering  
- 3.33-3
 - Rebuilt for https://fedoraproject.org/wiki/Fedora_20_Mass_Rebuild
 
diff --git a/sources b/sources
index d6a7072..afda7a7 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-d29c3dce4fdfbe35b847f2bf9002ef83  Mail-IMAPClient-3.33.tar.gz
+163427d32f5fd7f53f1bd8adf1b639f2  Mail-IMAPClient-3.34.tar.gz
-- 
cgit v0.11.2


From 25b3e783363f53f4f63d871d1ca2765ab8fb81f8 Mon Sep 17 00:00:00 2001
From: Nick Bebout 
Date: Thu, 13 Mar 2014 18:30:41 -0500
Subject: Update to 3.35

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

diff --git a/.gitignore b/.gitignore
index c120b19..dc3947b 100644
--- a/.gitignore
+++ b/.gitignore
@@ -6,3 +6,4 @@ Mail-IMAPClient-3.25.tar.gz
 /Mail-IMAPClient-3.32.tar.gz
 /Mail-IMAPClient-3.33.tar.gz
 /Mail-IMAPClient-3.34.tar.gz
+/Mail-IMAPClient-3.35.tar.gz
diff --git a/perl-Mail-IMAPClient.spec b/perl-Mail-IMAPClient.spec
index e06f206..bd516e9 100644
--- a/perl-Mail-IMAPClient.spec
+++ b/perl-Mail-IMAPClient.spec
@@ -1,5 +1,5 @@
 Name:   perl-Mail-IMAPClient
-Version:3.34
+Version:3.35
 Release:1%{?dist}
 Summary:An IMAP Client API
 Group:  Development/Libraries
@@ -52,6 +52,9 @@ rm -rf $RPM_BUILD_ROOT
 %{_mandir}/man3/*.3*
 
 %changelog
+* Thu Mar 13 2014 Nick Bebout  - 3.35-1
+- Upgrade to 3.35
+
 * Thu Oct 17 2013 Nick Bebout  - 3.34-1
 - Upgrade to 3.34
 
diff --git a/sources b/sources
index afda7a7..24bdd1a 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-163427d32f5fd7f53f1bd8adf1b639f2  Mail-IMAPClient-3.34.tar.gz

Re: Some analysis on the size of the minimal and Server installs of Fedora 23

[Stephen John Smoogen]

On Nov 17, 2015 01:25, "Martijn Ras"  wrote:
>
> What i've been doing on a number of small devices lately is strip all
comments from all files, which frees up a lot of disk space.
>
> I know, this strips copyright headers.
>
> Maybe the minimal packages can be split in two, by moving the comments to
a separate package?
>

That would be illegal in many places so I don't think so

> --
> 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: Some analysis on the size of the minimal and Server installs of Fedora 23

[Zbigniew Jędrzejewski-Szmek]

On Mon, Nov 16, 2015 at 08:39:24PM -0500, Stephen Gallagher wrote:
>  Largest 10 packages 
> 14288083: coreutils
> 14486819: glibc
> 18024040: kernel-modules
> 27253403: systemd

I've been working on making systemd packaging slightly more modular:
https://fedoraproject.org/wiki/Changes/systemd_package_split

This has been discussed during the recent systemd.conf2015 and
also on the mailing list
(http://lists.freedesktop.org/archives/systemd-devel/2015-November/034917.html).

For server this is unlikely to have a significant impact,
but for container cases it can save about ~15MB of disk space.

--

> 16648994: grub2
> 36004297: grub2-tools
> b'grub2-tools': 125
> b'grub2': 131

This is fairly big... It also pulls in fedora-logos, bringing the total
up to 60MB. systemd-boot and other minimalists look really nice in
comparison.

--

> * The largest individual package in both deployments is the
> glibc-common package. This is primarily due to the 106MiB
> locale-archive. I'd really like to hear from glibc folks if there is
> something we can do to break this up into smaller pieces contained in
> different sub-packages with Suggests: dependencies.

Is there any progress on
https://fedoraproject.org/wiki/Changes/Glibc_locale_subpackaging
?

Zbyszek
-- 
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: New (optional) python egg dependency generator for RPM

[Nick Coghlan]

On 17 November 2015 at 23:25, Neal Gompa  wrote:
> As for naming, I'm all ears for a better name, because if the "egg"
> name is going away, I'd rather it not continue to say that.

My suggestions would be either:

python2dist(name)/python3dist(name)

or:

python2(name)/python3(name)

The "dist" suffix comes from:

* "distutils", the standard library's software distribution utilities
* the "sdist" name used for uploading source archives to PyPI
* the "-Dist" suffix used in the never-really-adopted metadata 1.2 spec [1]

While dropping the suffix entirely seems like a potentially attractive
option to me, it may also be ambiguous as to whether it's referring to
import package names (eg. "python2(pkg_resources)") or distribution
package names (e.g. "python2(setuptools)").

Cheers,
Nick.

[1] https://www.python.org/dev/peps/pep-0345/

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
___
python-devel mailing list
python-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/python-devel

[Bug 1282828] New: Bump perl-Test-TCP version in epel7

[bugzilla]

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

Bug ID: 1282828
   Summary: Bump perl-Test-TCP version in epel7
   Product: Fedora EPEL
   Version: epel7
 Component: perl-Test-TCP
  Assignee: jose.p.oliveira@gmail.com
  Reporter: de...@fateyev.com
QA Contact: extras...@fedoraproject.org
CC: jose.p.oliveira@gmail.com, mmasl...@redhat.com,
perl-devel@lists.fedoraproject.org, psab...@redhat.com



Is it possible to bump `perl-Test-TCP` version in epel7 branch to more recent?

Some of modules by TOKUHIROM require 2.11 and above while testing, and it's a
bit annoying to build them in rhel7 with the current 2.01 there.

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

Guidelines unclear for unretire of a branch

[Richard Shaw]

I would like to unretire the epel7 branch of LibRaw, per the guidelines[1]
this woudl require a re-review, but that would only make sense if the whole
package was retired, not an epel branch.

Why would we re-review something that still have active branches
(specifically rawhide)?

Thanks,
Richard

[1] https://fedoraproject.org/wiki/PackageDB_admin_requests#Other_requests
-- 
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: Some analysis on the size of the minimal and Server installs of Fedora 23

[Stephen Gallagher]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 11/17/2015 11:16 AM, Adam Jackson wrote:
> On Mon, 2015-11-16 at 20:39 -0500, Stephen Gallagher wrote:
> 
>>  10 Longest dependency chains  b'abrt-addon-python3':
>> 170 b'abrt-retrace-client': 171 b'abrt-addon-pstoreoops': 171 
>> b'abrt-addon-ccpp': 183 b'abrt-addon-vmcore': 190 b'rolekit':
>> 196 b'abrt-cli': 214 b'cockpit': 216 b'freeipa-client': 249 
>> b'fedora-release-server': 252
> 
> I'm not sure what you mean by "dependency chain" here, I honestly
> doubt we have any A->B->C->... chains between packages exceeding, I
> dunno, 30 in length. Perhaps this means "installing this package
> installs a graph with this many package nodes"?  Or more
> succinctly, "10 largest dependency subtrees"?
> 

Right, maybe "dependency chains" is the wrong term. What it means is
that this is the total number of packages (which are probably shared
with others) necessary to support this package.

>> * server-hardware-support - lm_sensors: chain 139
> 
> A bunch of that is perl.  The old desktop live images fought
> pretty hard to keep perl out, I suspect the sysadmin heritage of
> the stuff in the server image will make that a bit harder to
> accomplish.
> 

I'm pretty willing to consider making lm_sensors an optional
component, but it will need to be discussed in terms of the Personas
we work against.


> One other thing the desktop live image had going for it was a
> concrete numeric goal to aim for.  Since we're considering disk
> space in the context of cloud images, would it make sense to define
> a target in terms of (say) dollar cost of storage in Amazon EBS for
> a year?
> 

That's an interesting approach. I'll have to look into that.


>> * The largest difference in the Fedora Server install vs. the
>> minimal install is due to the FreeIPA and Samba packages
>> requiring the inclusion of the Python 2 stack; focusing on
>> eliminating this requirement in Fedora 24 would have the largest
>> impact on both the number of packages and the space on disk.
> 
> Tsk, another instance of "python3 by default" not implying what we 
> might have hoped.
> 

In today's Server WG meeting[1], we came up with an approach to
removing these packages from the default install while not losing the
functionality they provide (hooray for auto-installation).



[1]
https://lists.fedoraproject.org/pipermail/server/2015-November/002135.html
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iEYEARECAAYFAlZLYL0ACgkQeiVVYja6o6OAswCgnD20zdvf7Bb28Q4j9ZC/HYQx
wS0AnAq7cT/Y61CpjakQznufX64mR+vV
=Pa3M
-END PGP SIGNATURE-
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Fedora Rawhide 20151116 compose check report

[Fedora compose checker]

Missing expected images:

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

Images in this compose but not Rawhide 20151115:

Games live x86_64
Lxde live x86_64

Images in Rawhide 20151115 but not this:

Security live i386
Security live x86_64

Failed openQA tests: 16 of 49

ID: 8448Test: x86_64 kde_live default_install
ID: 8447Test: i386 kde_live default_install
ID: 8437Test: i386 universal server_repository_http_graphical
ID: 8433Test: x86_64 universal server_lvmthin@uefi
ID: 8430Test: x86_64 universal server_software_raid@uefi
ID: 8427Test: x86_64 universal server_simple_encrypted@uefi
ID: 8426Test: x86_64 universal server_delete_partial@uefi
ID: 8423Test: x86_64 universal european_language_install
ID: 8422Test: x86_64 universal server_shrink_ntfs
ID: 8415Test: x86_64 universal server_lvmthin
ID: 8414Test: x86_64 universal server_ext3
ID: 8412Test: x86_64 universal server_software_raid
ID: 8409Test: x86_64 universal server_simple_encrypted
ID: 8407Test: x86_64 universal server_repository_http_variation
ID: 8406Test: x86_64 universal server_repository_http_graphical
ID: 8405Test: x86_64 universal server_mirrorlist_graphical

Passed openQA tests: 31 of 49
2 openQA tests may be still running or broken!
-- 
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

Re: Some analysis on the size of the minimal and Server installs of Fedora 23

[Pádraig Brady]

On 17/11/15 01:39, Stephen Gallagher wrote:
> (Please keep responses on the devel@ list; I've set it in the Reply-To.)
> 
> To jump right to the premise: The default Fedora Server install is Way
> Too Big(TM) and the minimal install (also available on the Fedora
> Server install media) is also Too Big.
> 
> I've been trying to do some quick-and-dirty analysis of what is in
> these default installations in order to figure out where we should be
> focusing our efforts. I'll point out that there are two goals that we
> need to keep in mind (and the reasons behind them) in order of
> increasing importance:
> 
> 1) Reduce disk space usage. While disk space on physical devices is
> becoming trivially cheap, disk space on Cloud deployments and rented
> virtual servers is still comparatively very expensive. We really want
> to minimize the amount of space that we use for Fedora so that users
> can fit their applications (the stuff they actually care about) into
> the remaining space without being forced to buy a larger storage
> allotment.
> 
> 2) Reduce maintenance efforts. Every additional piece of software on
> the system (referred to hereafter as "packages") increases the
> maintenance burden on an administrator. Universally, administrators
> prefer to have the smallest number of packages to maintain for a
> variety of reasons:
>  * Limiting update churn. The more packages on the system, the more
>often that one will need to run updates.
>  * Limiting security exposure. Every package on the system is another
>potential privilege-escalation point. Keeping this number under
>control means a reduced likelihood of a catastrophic breach. (The
>actual risk here is impossible to quantify, but it can be assumed
>that less code == less potential vulnerabilities.
>  * Non-expert administrators do not always know what is installed on
>their systems. This can lead to unintentional breaches as an
>admin doesn't realize that one or more services needs to be limited
>(such as in the firewall or via SELinux).
> 
> With these two goals in mind, the most obvious approach to improving
> this situation would be by reducing the number of packages installed
> by default on the Minimal and Fedora Server installs. As a specific
> goal of the Server Working Group, we want to aim for a world wherein
> administrators will no longer desire to install the Minimal install
> and instead will rely on the platform provided by the default Fedora
> Server install. They do not do this today because the Fedora Server
> installation is considerably larger. I postulate that this is due
> primarily to dependency bloat, which is where we should focus our
> efforts during the Fedora 24 timeframe. I postulate (but have not yet
> confirmed) that there are likely many places where we could replace
> Requires: with Recommends: (or even Suggests:) dependencies. In my
> ideal world, the difference between a Minimal and Server install would
> be identical to installing the same set of packages with Recommends:
> on or off.
> 
> 
> Some highlights of my initial research (with a lot of my raw data in
> the tarball attached to this email):
> 
> 
> == Minimal ==
> 
> === Disk Usage ===
> /boot: 79MB
> /: 755MB
> 
> 
> === Packages ===
> Total count: 270
> 
>  Largest 10 packages 
> 14288083: coreutils

We might create a coreutils-singlebin package that is built with
  ./configure --enable-single-binary
which would include only the single binary and stubs.
I think chromium is using this setup.
coreutils-singlebin could Recommends: coreutils-doc, while the
standard coreutils package would require coreutils-doc.
That would save about 13MB in the install.
Caveat is that the single binary would dynamically link
all shared libs, which associated startup and mem overhead.

cheers,
Pádraig
-- 
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: On running gui applications as root

[Andrew Haley]

On 11/02/2015 03:05 PM, Adam Jackson wrote:
> But, why take the risk exposure, when you could simply not?

How else would I edit root-owned files?  I don't get it.  I mean,
I guess I could run an editor in a text window, but I don't want to
do that.

And I have no idea how to run things like virt-manager without root.

And finally, it's *my computer*, dammit.

Andrew.

-- 
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: On running gui applications as root

[Joonas Sarajärvi]

2015-11-17 20:07 GMT+02:00 Reindl Harald :
> depends on what the application is supposed to do and if you want a global
> setup instead only in the userhome for every user
>
> installing in your userhome has another disadvantage: you are running all
> day long a application writeable by your user and so there is a risk that
> another arbitary process modifies it
>
> installing the application as root is a one time risk but after that the
> binaries are protected against modifying

Sure, there are also installers which really require root privileges
to function at all.

The writability of installed files by your normal user is easy to
address by e.g. this:
- make directory /opt/foo owned by alice
- have alice run the installer of foo, installing to /opt/foo
- chown -R root:root /opt/foo
- adjust system-wide default PATH to include /opt/foo/bin

Of course if you trust the installer to be well written and benign,
you might just as well not bother. But this is a fairly easy option.

- Joonas
-- 
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: On running gui applications as root

[Tom Hughes]

On 17/11/15 18:11, Andrew Haley wrote:

On 11/17/2015 05:55 PM, Joonas Sarajärvi wrote:

My impression is that by default in fedora, virt-manager runs as
non-root. I guess it might ask for the root password in order to
manage the libvirtd that runs as privileged mode, but even in that
case the user interface would run as your normal user.


Sure, but even that is a UI regression: applications which ask for
the root password discourage long root passwords and train people
to type the root password whenever it's asked for.  I should not
even need to know the root password.


Well you'll be pleased to know then that virt-manager doesn't normally 
ask for the root password. If you're in the libvirt group then I don't 
think it will ask at all, otherwise if you're an administrative user 
then it will ask for your password.


If you weren't an admin user then it might ask for the root password but 
I don't think I've ever tried that. It does whatever polkit does for 
auth_admin basically.


Certainly there is no good reason to run virt-manager as root.

Tom

--
Tom Hughes (t...@compton.nu)
http://compton.nu/
--
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: On running gui applications as root

[Florian Weimer]

On 10/30/2015 10:48 PM, Adam Jackson wrote:
> Anyone running any X (or wayland) application as root in their desktop
> session is completely bonkers and deserves every consequence of their
> poor decision.

Doesn't most proprietary software come with GUI installers?

Florian
-- 
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: On running gui applications as root

[Joonas Sarajärvi]

Hi,

2015-11-17 19:30 GMT+02:00 Andrew Haley :
> And I have no idea how to run things like virt-manager without root.

My impression is that by default in fedora, virt-manager runs as
non-root. I guess it might ask for the root password in order to
manage the libvirtd that runs as privileged mode, but even in that
case the user interface would run as your normal user.

My system has been set up to allow my user to manage VMs in the
system-wide libvirtd instance by adding this content to a file named
/etc/polkit-1/rules.d/20-libvirt-polkit.rules:

polkit.addRule(function(action, subject) {
if (action.id == "org.libvirt.unix.manage") {
if (subject.user == "muep") {
return polkit.Result.YES;
}
}
});

Of course this does not necessarily let you avoid all cases where
you'd run an X11 application as root. But virt-manager seems to be
written with the intent that it does not require to be run as root.

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

limb changed spot's branch request for perl-File-Copy-Recursive in epel7 from Awaiting Review to Denied with message: perl-File-Copy-Recursive` is present in RHEL 7 with version: 0.38 on arch: noarch

[notifications]

limb changed spot's branch request for perl-File-Copy-Recursive in epel7 from 
Awaiting Review to Denied with message: perl-File-Copy-Recursive` is present in 
RHEL 7 with version: 0.38 on arch: noarch
https://admin.fedoraproject.org/pkgdb/package/perl-File-Copy-Recursive/
--
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: On running gui applications as root

[Joonas Sarajärvi]

2015-11-17 19:56 GMT+02:00 Florian Weimer :
> Doesn't most proprietary software come with GUI installers?

No idea if "most" are, but at least I have seen many proprietary
programs that do not require a GUI in installation.

Also in many cases where there is a GUI installer, it works just fine
as a normal user and running it without root privileges could be
considered somewhat safer. You would at least know if it tries to
clobber your config files under /etc or your libraries and programs
under /usr.

- Joonas
-- 
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: On running gui applications as root

[Reindl Harald]

Am 17.11.2015 um 19:04 schrieb Joonas Sarajärvi:

2015-11-17 19:56 GMT+02:00 Florian Weimer :

Doesn't most proprietary software come with GUI installers?


No idea if "most" are, but at least I have seen many proprietary
programs that do not require a GUI in installation.

Also in many cases where there is a GUI installer, it works just fine
as a normal user and running it without root privileges could be
considered somewhat safer. You would at least know if it tries to
clobber your config files under /etc or your libraries and programs
under /usr


depends on what the application is supposed to do and if you want a 
global setup instead only in the userhome for every user


installing in your userhome has another disadvantage: you are running 
all day long a application writeable by your user and so there is a risk 
that another arbitary process modifies it


installing the application as root is a one time risk but after that the 
binaries are protected against modifying




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

Re: On running gui applications as root

[Reindl Harald]

Am 17.11.2015 um 18:56 schrieb Florian Weimer:

On 10/30/2015 10:48 PM, Adam Jackson wrote:

Anyone running any X (or wayland) application as root in their desktop
session is completely bonkers and deserves every consequence of their
poor decision.


Doesn't most proprietary software come with GUI installers?


at least VMware and ZendStudio does - if i don't trust the vendor 
starting the installer local or remote with x-forwarding is the smallest 
of my problems!




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

Re: On running gui applications as root

[Andrew Haley]

On 11/17/2015 05:55 PM, Joonas Sarajärvi wrote:
> My impression is that by default in fedora, virt-manager runs as
> non-root. I guess it might ask for the root password in order to
> manage the libvirtd that runs as privileged mode, but even in that
> case the user interface would run as your normal user.

Sure, but even that is a UI regression: applications which ask for
the root password discourage long root passwords and train people
to type the root password whenever it's asked for.  I should not
even need to know the root password.

Andrew.

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

Attempting to contact unresponsive maintainer - oschreib

[Kevin Fenzi]

Greetings, we've been told that the email addresses
for this package maintainer is no longer valid.  I'm starting the
unresponsive maintainer policy to find out if they are still interested
in maintaining their packages (and if so, have them update their email
addresses in FAS).  If they're not interested in maintaining or we
can't locate them I'll have FESCo orphan the packages so that others
can take them over.

If you have a way to contact this maintainer, please let them
know that we'd appreciate knowing what to do with their packages.
Thanks!

* oschreib - former email: oschr...@redhat.com

Point of contact:

ovirt-engine-cli -- oVirt Engine Command Line Interface ( master f23
f22 f21 epel7 el6 ) 

Co-maintainer:

ovirt-engine-sdk-python -- oVirt Engine Software Development Kit
(Python) ( master f23 f22 f21 epel7 el6 )


pgp8MKR1tLOc0.pgp
Description: OpenPGP digital signature
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: On running gui applications as root

[Andrew Haley]

On 11/17/2015 06:25 PM, Tom Hughes wrote:
> On 17/11/15 18:11, Andrew Haley wrote:
>> On 11/17/2015 05:55 PM, Joonas Sarajärvi wrote:
>>> My impression is that by default in fedora, virt-manager runs as
>>> non-root. I guess it might ask for the root password in order to
>>> manage the libvirtd that runs as privileged mode, but even in that
>>> case the user interface would run as your normal user.
>>
>> Sure, but even that is a UI regression: applications which ask for
>> the root password discourage long root passwords and train people
>> to type the root password whenever it's asked for.  I should not
>> even need to know the root password.
> 
> Well you'll be pleased to know then that virt-manager doesn't normally 
> ask for the root password. If you're in the libvirt group then I don't 
> think it will ask at all, otherwise if you're an administrative user 
> then it will ask for your password.

OK, fair enough.  That must be more recent than the host system I use.


Andrew.


-- 
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: Reminder: Fedora 21 end of life on 2015-12-01

[Kevin Fenzi]

On Mon, 16 Nov 2015 08:48:12 -0500
Josh Boyer  wrote:

> On Tue, Nov 10, 2015 at 10:24 AM, Kevin Fenzi  wrote:
> > Greetings.
> >
> > This is a reminder email about the end of life process for Fedora
> > 21.
> >
> > Fedora 21 will reach end of life on 2015-12-01, and no further
> > updates will be pushed out after that time. Additionally, with the
> > recent release of Fedora 23, no new packages will be added to the
> > Fedora 21 collection.  
> 
> What is the realistic last date that maintainers can submit an update
> to stable to get it pushed out before F21 goes EOL?  Particularly with
> Nov 27 being a holiday for many people and pushes taking quite some
> time, it might be earlier than some expect.

Thats a good question. I would think you would want to make sure your
update to submitted for stable by 2015-11-30 (ie, the day before EOL). 

So, for folks in North america, you would want to make sure it's
submitted sunday night (2015-11-29) so it's ready for monday's last
push. 

kevin


pgpkKlFwWKb0A.pgp
Description: OpenPGP digital signature
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: What's the current status of mp3-licensing issues?

[Thomas Daede]

On 11/15/2015 10:34 AM, Gerald B. Cox wrote:
> My understand is that Opus excels at lower bitrates; above 100 Vorbis is
> better.

Opus is always better - but at high bitrates, artifacts become so
imperceptible that it doesn't matter too much which codec you pick, so
you might still pick Vorbis for greater compatibility.

> In any event, are the same FUD tactics that were used against
> Vorbis applying to Opus - and with the expiration of the MP3 patents I
> would think those arguments would now be moot... but I'm sure there will
> always be some excuse.

As has been seen, the threats against Vorbis were all hollow. If your
claims are baseless, it doesn't matter if the unspecified patents are
expired or not :)

In general, Opus adoption has been very fast compared to Vorbis because
it is vastly better than other options in the low-delay niche, and is
mandatory for WebRTC.
-- 
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: Some analysis on the size of the minimal and Server installs of Fedora 23

[Dan Williams]

On Mon, 2015-11-16 at 20:39 -0500, Stephen Gallagher wrote:
> b'NetworkManager': 138

NM does have a larger dep-chain than we'd like, however we did split
the package apart a couple releases ago and made sure that WWAN, WiFi,
and Bluetooth were no longer required for the server cases.  Could you
confirm what NetworkManager-* packages are installed on F23 server?

The largest deps should be mostly glib2, systemd/udev, NSS, and D-Bus,
all of which should already be on a server install.  We'd love to see
if anything unexpected snuck into the dep chain.

Dan
-- 
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: Some analysis on the size of the minimal and Server installs of Fedora 23

[Jason L Tibbitts III]

> "DW" == Dan Williams  writes:

DW> Could you confirm what NetworkManager-* packages are installed on
DW> F23 server?

On my custom install (which just lists the packages I need in my
kickstart file) I have:

NetworkManager-glib-1.0.6-8.fc22.x86_64
NetworkManager-1.0.6-8.fc22.x86_64
NetworkManager-libnm-1.0.6-8.fc22.x86_64
NetworkManager-config-connectivity-fedora-1.0.6-8.fc22.x86_64
NetworkManager-tui-1.0.6-8.fc22.x86_64

I didn't realize the connectivity-fedora thing had snuck in there; I
certainly didn't ask for it so it must be part of a default group.
Nothing depends upon it so I'll have to exclude it manually.

 - J<
-- 
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: Attempting to contact unresponsive maintainer - oschreib

[Douglas Schilling Landgraf]

Adding Juan into the loop. He might be interested.

On 11/17/2015 01:40 PM, Kevin Fenzi wrote:

Greetings, we've been told that the email addresses
for this package maintainer is no longer valid.  I'm starting the
unresponsive maintainer policy to find out if they are still interested
in maintaining their packages (and if so, have them update their email
addresses in FAS).  If they're not interested in maintaining or we
can't locate them I'll have FESCo orphan the packages so that others
can take them over.

If you have a way to contact this maintainer, please let them
know that we'd appreciate knowing what to do with their packages.
Thanks!

* oschreib - former email: oschr...@redhat.com

Point of contact:

ovirt-engine-cli -- oVirt Engine Command Line Interface ( master f23
f22 f21 epel7 el6 )

Co-maintainer:

ovirt-engine-sdk-python -- oVirt Engine Software Development Kit
(Python) ( master f23 f22 f21 epel7 el6 )




-- 
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: Building Images for Taskotron Disposable Clients

[Tim Flink]

On Fri, 13 Nov 2015 09:23:43 -0700
Tim Flink  wrote:



> > If we intended to mostly build those images on dev's computers, I'd
> > probably prefer virt-builder. But my current impression is that
> > local building will be a secondary option, and we'll primarily offer
> > pre-created images for download (even downloading them
> > automatically). Which makes sense, it's easier for the dev, and less
> > error-prone. So in that light (assuming no one has different plans
> > in mind), it doesn't really matter which technology we choose to
> > build it. Image size is a factor here, though. I don't have any real
> > numbers here, it would be very interesting to see the same image
> > (same package set, same filesystem size) built by both tools and
> > compare the output size (ideally even after running zerofree on them
> > and compressing them). My guess is that they should have the same
> > size (what would cause a difference?), but we might be surprised. Do
> > we have a volunteer to test this? :)
> 
> I can give this a try later today - I have both tools installed on a
> machine here.

I've created images for taskotron using both taskotron-vmbuilder and
imagefactory. They're similar but not identical - I based the
imagefactory off the F22 cloud images instead of specifying the server
group install and virt-builder has some restrictions on what you can do
with disk space which imagefactory does not have.

I've put all the files up for review: the kickstart for imagefactory,
the yaml file for vmbuilder and both created images, gzipped.

https://tflink.fedorapeople.org/taskotron/testimages/

Time of creation operation
--
  imagefactory: 16m6.596s
  vmbuilder:7m19.273s

Image sizes
---
  20151113-taskotron_server-22.qcow2.gz   818M
  20151113-taskotron_server-22.qcow2  11G
  20151113-imagebuilder-taskotron.qcow3.0G
  20151113-imagebuilder-taskotron.qcow.gz 358M


pgpQfAbVRFnCu.pgp
Description: OpenPGP digital signature
___
qa-devel mailing list
qa-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/qa-devel

Dealing with the "my packages" problem

[Jason L Tibbitts III]

tl; dr: I have submitted the following RFE for pkgdb:
  https://github.com/fedora-infra/pkgdb2/issues/274
Please add comments there if you have any.

I know I'm not the only provenpackager to have applied a bugfix to
someone's package only to be yelled at it for it.  Some maintainers are
more prickly about having others touch the packages they maintain for
the community than others, and unfortunately there's currently just no
way to know whether you'll be thanked or flamed for helping out with a
package.

After some IRC discussion I've come to the following proposal: that
maintainers have some way to easily indicate how open they are to
external contributions.  Basically this would take the form of a few
options in pkgdb where maintainers can indicate their willingness to
have provenpackagers carry out a few actions.  Please read the github
ticket for details:
  https://github.com/fedora-infra/pkgdb2/issues/274

This would be purely advisory, with hopefully reasonable defaults.  I
believe it has the potential to eliminate quite a bit of friction that
provenpackagers must handle, as well as eliminate the hesitation some of
us feel for fear of being flamed.

 - J<
-- 
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: Some analysis on the size of the minimal and Server installs of Fedora 23

[Matthew Miller]

On Mon, Nov 16, 2015 at 08:39:24PM -0500, Stephen Gallagher wrote:
> 1) Reduce disk space usage. While disk space on physical devices is
> becoming trivially cheap, disk space on Cloud deployments and rented
> virtual servers is still comparatively very expensive. We really want
> to minimize the amount of space that we use for Fedora so that users
> can fit their applications (the stuff they actually care about) into
> the remaining space without being forced to buy a larger storage
> allotment.

I want to add to this that smaller image size _also_ means less network
traffic and faster deployment time, which I also hear from people as an
importand factor.

>  * Limiting security exposure. Every package on the system is another
>potential privilege-escalation point. Keeping this number under
>control means a reduced likelihood of a catastrophic breach. (The
>actual risk here is impossible to quantify, but it can be assumed
>that less code == less potential vulnerabilities.

And to this: in the large institutions that I've been a part of,
protesting that known vulnerabilities in code that isn't run because
the daemon is off, or because there's a firewall, or whatever, gets you
nowhere with the compliance people.

> * The largest individual package in both deployments is the
> glibc-common package. This is primarily due to the 106MiB
> locale-archive. I'd really like to hear from glibc folks if there is
> something we can do to break this up into smaller pieces contained in
> different sub-packages with Suggests: dependencies.

Yes, there's work on this.
https://fedoraproject.org/wiki/Changes/Glibc_locale_subpackaging


-- 
Matthew Miller

Fedora Project Leader
-- 
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: Dealing with the "my packages" problem

[David Airlie]

> 
> tl; dr: I have submitted the following RFE for pkgdb:
>   https://github.com/fedora-infra/pkgdb2/issues/274
> Please add comments there if you have any.
> 
> I know I'm not the only provenpackager to have applied a bugfix to
> someone's package only to be yelled at it for it.  Some maintainers are
> more prickly about having others touch the packages they maintain for
> the community than others, and unfortunately there's currently just no
> way to know whether you'll be thanked or flamed for helping out with a
> package.
> 
> After some IRC discussion I've come to the following proposal: that
> maintainers have some way to easily indicate how open they are to
> external contributions.  Basically this would take the form of a few
> options in pkgdb where maintainers can indicate their willingness to
> have provenpackagers carry out a few actions.  Please read the github
> ticket for details:
>   https://github.com/fedora-infra/pkgdb2/issues/274
> 
> This would be purely advisory, with hopefully reasonable defaults.  I
> believe it has the potential to eliminate quite a bit of friction that
> provenpackagers must handle, as well as eliminate the hesitation some of
> us feel for fear of being flamed.
> 

This seems like a crappy technical solution to a social problem.

Maybe by renaming package maintainers to something like caretakers we could
start changing the way people who maintain packages view their positions.

You don't own a package in Fedora. You are taking care of it on behalf
of the Fedora community, other people in the community can touch your package.

The other option is to just open all packages to everyone, I've no idea
why we still have ACLs in the land of git.

Dave.
-- 
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: Some analysis on the size of the minimal and Server installs, of Fedora 23

[Adam Williamson]

On Tue, 2015-11-17 at 11:14 -0800, Brian C. Lane wrote:
> On Tue, Nov 17, 2015 at 10:48:08AM +, Michael Hampton wrote:
> > Along those lines, I would like to see Anaconda detect whether the
> > system is a virtual machine, and automatically select for installation
> > the _appropriate_ guest agents for the detected hypervisor, rather
> > than _all_ of them, but this doesn't affect Server exclusively.
> 
> We actually do this already. Anaconda runs systemd-detect-virt and then
> adds a group named platform- if it is running inside a
> detected hypervisor. Packages for the group are controlled by comps. eg.
> kvm will add a 'platform-kvm' group to the installation automatically.

Hm - perhaps that is only really working in RHEL?

In Fedora, there don't seem to be any 'platform-foo' groups in comps, and
there's a guest-desktop-agents group which is included in all the desktop
environment groups and pulls in all the agents.

So I guess there's room for improvement there? We could implement the
platform-* groups for anaconda installs, then not include the 'all
agents' group in the desktop environment groups, but instead pull it in
via kickstarts for the live image cases (and any other cases where
anaconda can't intelligently pull in just the correct group)?
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net


-- 
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: Some analysis on the size of the minimal and Server installs, of Fedora 23

[Brian C. Lane]

On Tue, Nov 17, 2015 at 10:48:08AM +, Michael Hampton wrote:
> Along those lines, I would like to see Anaconda detect whether the
> system is a virtual machine, and automatically select for installation
> the _appropriate_ guest agents for the detected hypervisor, rather
> than _all_ of them, but this doesn't affect Server exclusively.

We actually do this already. Anaconda runs systemd-detect-virt and then
adds a group named platform- if it is running inside a
detected hypervisor. Packages for the group are controlled by comps. eg.
kvm will add a 'platform-kvm' group to the installation automatically.

-- 
Brian C. Lane | Anaconda Team | IRC: bcl #anaconda | Port Orchard, WA (PST8PDT)
-- 
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: Some analysis on the size of the minimal and Server installs, of Fedora 23

[Stephen Gallagher]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 11/17/2015 03:09 PM, Adam Williamson wrote:
> On Tue, 2015-11-17 at 11:14 -0800, Brian C. Lane wrote:
>> On Tue, Nov 17, 2015 at 10:48:08AM +, Michael Hampton wrote:
>>> Along those lines, I would like to see Anaconda detect whether
>>> the system is a virtual machine, and automatically select for
>>> installation the _appropriate_ guest agents for the detected
>>> hypervisor, rather than _all_ of them, but this doesn't affect
>>> Server exclusively.
>> 
>> We actually do this already. Anaconda runs systemd-detect-virt
>> and then adds a group named platform- if it is running
>> inside a detected hypervisor. Packages for the group are
>> controlled by comps. eg. kvm will add a 'platform-kvm' group to
>> the installation automatically.
> 
> Hm - perhaps that is only really working in RHEL?
> 
> In Fedora, there don't seem to be any 'platform-foo' groups in
> comps, and there's a guest-desktop-agents group which is included
> in all the desktop environment groups and pulls in all the agents.
> 
> So I guess there's room for improvement there? We could implement
> the platform-* groups for anaconda installs, then not include the
> 'all agents' group in the desktop environment groups, but instead
> pull it in via kickstarts for the live image cases (and any other
> cases where anaconda can't intelligently pull in just the correct
> group)?
> 

Yeah, I was just investigating this as well. The "platform-foo"
support in Anaconda is news to me. Is there some documentation on
this? For the case of Fedora Server, this sounds like a great thing to
have available, so I'd like to know precisely how it works.
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iEYEARECAAYFAlZLkGgACgkQeiVVYja6o6P/kQCbBZXErwA10f83MDJc4YId5p1J
tVcAoKQcN500fdIaLOHdKWSur485DgaK
=QOVs
-END PGP SIGNATURE-
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Quick proposal for making packager sponsorship slightly easier

[Jason L Tibbitts III]

> "H" == Haïkel   writes:

H> It's all the more important then to formalize requirements from new
H> packagers like having done two quality reviews and link them back to
H> their first package tickets.

That's sort of an orthogonal issues, but honestly I don't believe
anything should be required of a packager besides the proper maintenance
of a single high-quality package.  That's all many contributors,
particularly upstreams, care about.  And we want those contributors
too (quite a bit, I'd think).

If the community says a package submission is good, and a sponsor is
willing to make themselves available as to help the packager through the
process of getting the package onto end user machines and providing
direct support (in addition to the community which should always be
there for assistance) then I don't see what else we should make a
packager do.  The practice of demanding practice reviews is just
something that some sponsors would like to see, but it's never been a
hard requirement.  And it would be really unfortunate if it was, because
nothing like that is required for sponsorship via the comaintainer
route.

H> Though the main bottleneck is time to properly mentor new packagers.

I find that I have time to do that while not having time to actually do
package reviews.  I do really thorough reviews and they take a while.

 - J<
-- 
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: Building Images for Taskotron Disposable Clients

[Adam Williamson]

On Tue, 2015-11-17 at 17:23 -0700, Tim Flink wrote:
> Requirements:
>   - make post-install changes to the images before distribution
>   - specify partition table type
>   - create users on the image
> 
> Are there other requirements for openqa images?

For some of the images what we primarily need is some specific
partition table / layout, not any particular contents; as you say it
may not make sense to do that with the same tool, but that is one of
the openQA requirements.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net


___
qa-devel mailing list
qa-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/qa-devel

[Bug 1277233] Please branch and build for EPEL 7

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|MODIFIED|ON_QA



--- Comment #4 from Fedora Update System  ---
perl-BZ-Client-1.04-12.el7 has been pushed to the Fedora EPEL 7 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 'yum --enablerepo=epel-testing update perl-BZ-Client'
You can provide feedback for this update here:
https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2015-2e6e8e31a7

-- 
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: Building Images for Taskotron Disposable Clients

[Tim Flink]

On Tue, 17 Nov 2015 17:50:13 -0800
Adam Williamson  wrote:

> On Tue, 2015-11-17 at 17:23 -0700, Tim Flink wrote:
> > Requirements:
> >   - make post-install changes to the images before distribution
> >   - specify partition table type
> >   - create users on the image
> > 
> > Are there other requirements for openqa images?
> 
> For some of the images what we primarily need is some specific
> partition table / layout, not any particular contents; as you say it
> may not make sense to do that with the same tool, but that is one of
> the openQA requirements.

Just to make sure I was being clear - I was referring to the empty disk
images (embedded updates.img, embedded ks, freespace etc. - the
stuff that's only using guestfish) that are made with createhdds.sh, not
the installed image. If I'm understanding correctly, it's the installed
images (minimal, desktop) that would be most useful to rebuild on a
regular basis - did I misunderstand something? Do all the images for
openqa need to come from the same tool? I suspect that the guestfish
"(mostly) empty disk" methods could be run just about anywhere at most
once a release.

That being said, it sounds like precise partitioning is another
requirement.

Tim


pgplmzk8qZtXy.pgp
Description: OpenPGP digital signature
___
qa-devel mailing list
qa-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/qa-devel

Re: Dealing with the "my packages" problem

[Jason L Tibbitts III]

> "DA" == David Airlie  writes:

DA> This seems like a crappy technical solution to a social problem.

I don't know; it seems to be more discoverable than the current state,
where either you just commit and hope.  And yeah, I'm relatively thick
skinned but I still don't like to get flamed by a maintainer that I
might run into at Flock.

Plus, it's not entirely a social problem.  Some packages really do need
extra care and it's not always obvious.  Currently the best you can do
is a comment in the specfile.  Maybe that's sufficient, I'm not sure.

Finally, I don't think having a flag to distinguish between "please ask
me first" and "fire at will" (with different possible answers for
rawhide vs. release and committing vs. actually building or pushing
updates) falls within the realm of the social problem that you mention.

DA> Maybe by renaming package maintainers to something like caretakers
DA> we could start changing the way people who maintain packages view
DA> their positions.

That's true, but I think there's more nuance than that and in any case
I'm trying to approach it from a different angle.  I certainly wouldn't
argue if you made a proposal to that effect but I still think I'm trying
to solve a slightly different problem.  Heck, if my proposal were
implemented (which is easy from a coding standpoint) then we might be
able to collect some stats on how many maintainers feel a certain way.

DA> The other option is to just open all packages to everyone, I've no
DA> idea why we still have ACLs in the land of git.

Because it still takes nonzero time to undo or merge things, and because
I really don't like the idea of giving every single packager (or,
depending on what you actually meant, everyone with a Fedora account)
root access to my rawhide machines.  Or were you proposing removing ACLs
only for committing to packages but keeping them for actually doing
builds?  What about updates?  It's not quite so simple.  (And yes, I've
been a part of several big discussions about this over the lifetime of
the project.)

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

[EPEL-devel] Fedora EPEL 7 updates-testing report

[updates]

The following Fedora EPEL 7 Security updates need testing:
 Age  URL
 254  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2015-1087   
dokuwiki-0-0.24.20140929c.el7
 150  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2015-6813   
chicken-4.9.0.1-4.el7
  57  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2015-8155   
nagios-4.0.8-1.el7
  46  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2015-925e9374c9   
python-pymongo-3.0.3-1.el7
  22  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2015-234553a060   
mediawiki123-1.23.11-1.el7
  22  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2015-ad1b660a4d   
php-ZendFramework-1.12.16-1.el7
  16  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2015-dac7ed832f   
mcollective-2.8.4-1.el7
  16  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2015-97e247eb19   
perl-HTML-Scrubber-0.15-1.el7
  14  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2015-22f9be240b   
qemu-2.0.0-1.el7.6
  12  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2015-f5273e10c1   
rabbitmq-server-3.3.5-12.el7
  10  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2015-f75cdd1774   
metis-5.1.0-7.el7
  10  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2015-4b33ee7c84   
wildmagic5-5.13-12.el7
  10  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2015-e1379fc854   
owncloud-8.0.9-1.el7
   9  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2015-693544258f   
telegram-cli-1.3.1-7.20150730git2052f4.el7
   9  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2015-7b2b7d02df   
quassel-0.11.1-1.el7
   9  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2015-8a26d71e56   
pdns-3.4.7-1.el7
   6  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2015-da5a65c143   
zarafa-7.1.14-1.el7
   4  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2015-c399ccf199   
sundials-2.6.2-11.el7
   2  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2015-914de61c66   
potrace-1.13-2.el7
   1  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2015-987c5b1ead   
monitorix-3.8.1-1.el7


The following builds have been pushed to Fedora EPEL 7 updates-testing

ari-backup-1.0.10-3.el7
java-dirq-1.6-3.el7
libabigail-1.0-0.6.rc0.el7
nodejs-on-headers-1.0.1-2.el7
ovirt-engine-cli-3.6.0.2-1.el7
ovirt-engine-sdk-java-3.6.0.3-1.el7
ovirt-engine-sdk-python-3.6.0.3-1.el7
pagila-0.10.1-3.el7
perl-BZ-Client-1.04-12.el7
php-apigen-theme-bootstrap-1.1.3-1.el7
php-apigen-theme-default-1.0.2-1.el7
php-nette-component-model-2.2.4-2.el7
php-nette-finder-2.3.1-1.el7
php-nette-php-generator-2.3.4-1.el7
php-pear-CAS-1.3.4-1.el7
python-fedmsg-meta-fedora-infrastructure-0.15.5-6.el7
python-fmn-lib-0.7.7-1.el7
python-fmn-rules-0.7.4-1.el7
python-fmn-web-0.7.7-1.el7
python-sphinx_rtd_theme-0.1.8-4.el7
znc-1.6.2-1.el7

Details about builds:



 ari-backup-1.0.10-3.el7 (FEDORA-EPEL-2015-120a2062db)
 A helpful wrapper around rdiff-backup

Update Information:

New package.

References:

  [ 1 ] Bug #1269609 - Review Request: ari-backup - A wrapper around 
rdiff-backup
https://bugzilla.redhat.com/show_bug.cgi?id=1269609




 java-dirq-1.6-3.el7 (FEDORA-EPEL-2015-7c841160e6)
 Directory based queue

Update Information:

The java-dirq-1.6-3.el7 package fixes the problems found on ARM and is now again
a noarch rpm.    Updated to latest version from upstream.

References:

  [ 1 ] Bug #1270012 - [epel7s390x] java-dirq SRPM does not build correctly on 
s390x
https://bugzilla.redhat.com/show_bug.cgi?id=1270012
  [ 2 ] Bug #1240637 - java-dirq-debuginfo-1.4-7 is empty
https://bugzilla.redhat.com/show_bug.cgi?id=1240637




 libabigail-1.0-0.6.rc0.el7 (FEDORA-EPEL-2015-908d077afb)
 Set of ABI analysis tools

Update Information:

Update to upstream release 1.0.rc0    Update to upstream git commit hash
164d17e




 nodejs-on-headers-1.0.1-2.el7 (FEDORA-EPEL-2015-59e3d7dd96)
 Execute a listener when a response is about to write headers

Re: building conflicting packages from a single spec

[Jason L Tibbitts III]

> "PB" == Pádraig Brady  writes:

PB> Is $subject possible?

I don't think so, since at the end of %install you have exactly one set
of files in one buildroot.  Still, I don't see a reason for the
subpackages to actually conflict.

PB> Are any other techniques possible?

Install the binaries under separate names and use simple scripts to
decide which to run (or use alternatives, but ugh.)  Install libraries
into separate paths and use the scripts to set the library path.

If the software uses dlopen, just fix it to open the proper library
based on the capabilities of the machine.

 - J<
-- 
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: Building Images for Taskotron Disposable Clients

[Adam Williamson]

On Tue, 2015-11-17 at 19:33 -0700, Tim Flink wrote:
> On Tue, 17 Nov 2015 17:50:13 -0800
> Adam Williamson  wrote:
> 
> > On Tue, 2015-11-17 at 17:23 -0700, Tim Flink wrote:
> > > Requirements:
> > >   - make post-install changes to the images before distribution
> > >   - specify partition table type
> > >   - create users on the image
> > > 
> > > Are there other requirements for openqa images?
> > 
> > For some of the images what we primarily need is some specific
> > partition table / layout, not any particular contents; as you say it
> > may not make sense to do that with the same tool, but that is one of
> > the openQA requirements.
> 
> Just to make sure I was being clear - I was referring to the empty disk
> images (embedded updates.img, embedded ks, freespace etc. - the
> stuff that's only using guestfish) that are made with createhdds.sh, not
> the installed image. If I'm understanding correctly, it's the installed
> images (minimal, desktop) that would be most useful to rebuild on a
> regular basis - did I misunderstand something? Do all the images for
> openqa need to come from the same tool? I suspect that the guestfish
> "(mostly) empty disk" methods could be run just about anywhere at most
> once a release.

That all sounds accurate. No, they don't need to come out of the same
tool, though of course it's a bit more complex if we have to handle two
different image creation processes.

> That being said, it sounds like precise partitioning is another
> requirement.

Yeah, and it's at least feasible we might need to combine the two,
though I don't think that's the case for any of the current images.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net


___
qa-devel mailing list
qa-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/qa-devel

[Test-Announce] Fedora 24 Rawhide 20151117 nightly compose nominated for testing

[adamwill]

Announcing the creation of a new nightly release validation test event
for Fedora 24 Rawhide 20151117. Please help run some tests for this
nightly compose if you have time. For more information on nightly
release validation testing, see:
https://fedoraproject.org/wiki/QA:Release_validation_test_plan

Test coverage information for the current release can be seen at:
https://www.happyassassin.net/testcase_stats/24

You can see all results, find testing instructions and image download
locations, and enter results on the Summary page:

https://fedoraproject.org/wiki/Test_Results:Fedora_24_Rawhide_20151117_Summary

The individual test result pages are:

https://fedoraproject.org/wiki/Test_Results:Fedora_24_Rawhide_20151117_Installation
https://fedoraproject.org/wiki/Test_Results:Fedora_24_Rawhide_20151117_Base
https://fedoraproject.org/wiki/Test_Results:Fedora_24_Rawhide_20151117_Server
https://fedoraproject.org/wiki/Test_Results:Fedora_24_Rawhide_20151117_Cloud
https://fedoraproject.org/wiki/Test_Results:Fedora_24_Rawhide_20151117_Desktop
https://fedoraproject.org/wiki/Test_Results:Fedora_24_Rawhide_20151117_Security_Lab
https://fedoraproject.org/wiki/Template:Fedora_24_Rawhide_20151117_Download

Thank you for testing!
-- 
Mail generated by relval: https://www.happyassassin.net/wikitcms/
On behalf of: adamwill
___
test-announce mailing list
test-annou...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/test-announce
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Variable expansion in COPR external URL?

[Dave Johansen]

On Mon, Oct 19, 2015 at 3:54 AM, Miroslav Suchý  wrote:

> Dne 17.10.2015 v 23:55 Dave Johansen napsal(a):
> > How can I do a variable expansion that doesn't have - before and after?
> I tried "slc${releasever}X" [1] and
> > "slc$releaseverX" [2] but neither worked.
> > Thanks,
> > Dave
> >
> > [1]:
> https://copr-be.cloud.fedoraproject.org/results/daveisfera/odb_2.3_cern/epel-5-i386/00128584-odb/root.log.gz
> > [2]:
> https://copr-be.cloud.fedoraproject.org/results/daveisfera/odb_2.3_cern/epel-5-i386/00128585-odb/root.log.gz
> >
> >
>
> There is nothing special in Copr about this. Copr (or mock to be precise)
> just pass --releasever to dnf/yum.
>
> Looking at dnf code - and I assume yum will have similar code... There is
> in dnf/conf/parser.py the regular expression:
>   _KEYCRE = re.compile(r"\$(\w+)")
> which eat everything until first non word character.
> If you want smarter substitution, then please file RFE against DNF. Or
> even better send patch. :)


I opened a bugzilla ( https://bugzilla.redhat.com/show_bug.cgi?id=1283017
).
-- 
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: Dealing with the "my packages" problem

[Adam Williamson]

On Tue, 2015-11-17 at 19:21 -0500, David Airlie wrote:
> > 
> Maybe by renaming package maintainers to something like caretakers we could
> start changing the way people who maintain packages view their positions.

We actually already did that, but people haven't taken much notice. If
you look in pkgdb, there is no 'package owner' or 'package maintainer',
but 'main contact'(s) and 'package administrator(s)'.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net


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

building conflicting packages from a single spec

[Pádraig Brady]

Is $subject possible?

For example generating subpackages like:
  %{name}-small-but-slow-binaries
  %{name}-fast-but-big-binaries

I can %prep and %install into separate areas,
though was then wondering how to adjust
the buildroot for subpackages?

Are any other techniques possible?
I suppose I could manually set conflicts,
and then move binaries post install,
though what happens if mv is one of the
binaries for example?

cheers,
Pádraig.
-- 
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: building conflicting packages from a single spec

[Sérgio Basto]

On Qua, 2015-11-18 at 03:26 +, Pádraig Brady wrote:
> Is $subject possible?

Name:   VirtualBox
Conflicts:  %{name}-guest <= %{version}-%{release}

%package guest
Conflicts:  %{name} <= %{version}-%{release}

so you can't install VirtualBox and VirtualBox-guest at same time
because the packages Conflicts


> For example generating subpackages like:
>   %{name}-small-but-slow-binaries
>   %{name}-fast-but-big-binaries
> 
> I can %prep and %install into separate areas,
> though was then wondering how to adjust
> the buildroot for subpackages?

> Are any other techniques possible?
> I suppose I could manually set conflicts,
> and then move binaries post install,
> though what happens if mv is one of the
> binaries for example?
> 
> cheers,
> Pádraig.
-- 
Sérgio M. B.


-- 
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: Some analysis on the size of the minimal and Server installs of Fedora 23

[Martijn Ras]

What i've been doing on a number of small devices lately is strip all
comments from all files, which frees up a lot of disk space.

I know, this strips copyright headers.

Maybe the minimal packages can be split in two, by moving the comments to a
separate package?
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

rawhide report: 20151117 changes

[Fedora Rawhide Report]

Compose started at Tue Nov 17 05:15:03 UTC 2015
Broken deps for i386
--
[APLpy]
python3-APLpy-1.0-2.fc23.noarch requires python(abi) = 0:3.4
[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
[bandit]
bandit-0.13.2-1.fc24.noarch requires python-stevedore
[bitlyclip]
bitlyclip-0.2.2-6.fc23.noarch requires python-bitlyapi
[bugwarrior]
bugwarrior-1.3.0-1.fc24.noarch requires python-twiggy
bugwarrior-1.3.0-1.fc24.noarch requires python-bitlyapi
[copr-keygen]
copr-keygen-1.60-2.fc23.noarch requires python(abi) = 0:3.4
[devassistant]
devassistant-cli-0.11.2-1.fc24.noarch requires python(abi) = 0:3.4
devassistant-core-0.11.2-1.fc24.noarch requires python(abi) = 0:3.4
devassistant-gui-0.11.2-1.fc24.noarch requires python(abi) = 0:3.4
[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
[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)
  

Re: Quick proposal for making packager sponsorship slightly easier

[Haïkel]

2015-11-17 2:42 GMT+01:00 Jason L Tibbitts III :
> I recently filed https://fedorahosted.org/fesco/ticket/1499 with the
> goal of making the process just a bit simpler for new packagers.  The text of
> my proposal follows.  Please make sure that substantial comments are
> made on the ticket to ensure that FESCo sees them.
>
> -
> tl;dr: Relax the requirement that sponsors be directly involved in the
> package review process.
>
> Sponsors are responsible (but not solely responsible) for shepherding
> people through the packaging process. They should know how to do
> reviews, but there is nothing so special about a packager's first review
> that it cannot be handled by the regular packager community. We trust
> packagers to do every other package review, after all. We also allow new
> packagers to be sponsored without actually going through the package
> review process at all via the comaintainer process so what we appear to
> be emphasizing is that someone is there to assist and monitor the new
> contributor and not that the contributor make it through the arduous
> process of a package review with a highly restricted pool of reviewers.
>
> Proposal: Decouple sponsorship from the review process.
>
> Allow the community to do reviews as normal. Remove the requirement that
> the first review be done by a sponsor.
>

agreed

> Emphasize that sponsors can sponsor anyone separate from the review
> process. They can sponsor them before the review has been done, after it
> has been done, in the middle of the process, whatever. (This is all
> currently true in any case, but the process documents link most
> everything to the completion of a review.)
>
> Notes: Obviously sponsorship should still be tied to package maintenance
> in some way; sponsoring someone without any intention of having them
> work on a package in some way is pointless.
>
> Note that I do not intend to imply that sponsors need not know how to do
> proper package reviews. The guidelines for becoming a sponsor currently
> and should continue to specify that having done some package reviews is
> important to the process. The same goes for actually maintaining
> packages. Sponsors should know both the mechanics of maintaining
> packages and the standards for package quality.
>
> Hopefully this will open up the actual reviewing to the community as a
> whole, eliminating one bottleneck.
>
> We could potentially end up with people who have completed package
> reviews but who cannot yet actually import their packages. This would be
> worse than having people waiting in the sponsorship queue, because they
> actually did more work and someone from the community actually did some
> work as well. This could be mitigated through vigilance coupled with
> some scripting, or additional process in the packager-sponsor trac for
> requests that happen to fall through the cracks.
>

It's all the more important then to formalize requirements from new
packagers like having done two quality reviews and link them back to
their first package tickets.

Though the main bottleneck is time to properly mentor new packagers.

Regards,
H.

> Searching bugzilla for NEEDSPONSOR tickets still open with
> fedora-review+ set should be a reasonable first-pass report for those
> waiting. Mailing a filtered version of that to the sponsors would
> probably be effective but annoying.
>
>  - J<
> --
> 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: Some analysis on the size of the minimal and Server installs of Fedora 23

[Stef Walter]

On 17.11.2015 02:39, Stephen Gallagher wrote:
> (Please keep responses on the devel@ list; I've set it in the Reply-To.)
> 
> To jump right to the premise: The default Fedora Server install is Way
> Too Big(TM) and the minimal install (also available on the Fedora
> Server install media) is also Too Big.
> 
> I've been trying to do some quick-and-dirty analysis of what is in
> these default installations in order to figure out where we should be
> focusing our efforts. I'll point out that there are two goals that we
> need to keep in mind (and the reasons behind them) in order of
> increasing importance:
> 
> 1) Reduce disk space usage. While disk space on physical devices is
> becoming trivially cheap, disk space on Cloud deployments and rented
> virtual servers is still comparatively very expensive. We really want
> to minimize the amount of space that we use for Fedora so that users
> can fit their applications (the stuff they actually care about) into
> the remaining space without being forced to buy a larger storage
> allotment.
> 
> 2) Reduce maintenance efforts. Every additional piece of software on
> the system (referred to hereafter as "packages") increases the
> maintenance burden on an administrator. Universally, administrators
> prefer to have the smallest number of packages to maintain for a
> variety of reasons:
>  * Limiting update churn. The more packages on the system, the more
>often that one will need to run updates.
>  * Limiting security exposure. Every package on the system is another
>potential privilege-escalation point. Keeping this number under
>control means a reduced likelihood of a catastrophic breach. (The
>actual risk here is impossible to quantify, but it can be assumed
>that less code == less potential vulnerabilities.
>  * Non-expert administrators do not always know what is installed on
>their systems. This can lead to unintentional breaches as an
>admin doesn't realize that one or more services needs to be limited
>(such as in the firewall or via SELinux).
> 
> With these two goals in mind, the most obvious approach to improving
> this situation would be by reducing the number of packages installed
> by default on the Minimal and Fedora Server installs. As a specific
> goal of the Server Working Group, we want to aim for a world wherein
> administrators will no longer desire to install the Minimal install
> and instead will rely on the platform provided by the default Fedora
> Server install. They do not do this today because the Fedora Server
> installation is considerably larger. I postulate that this is due
> primarily to dependency bloat, which is where we should focus our
> efforts during the Fedora 24 timeframe. I postulate (but have not yet
> confirmed) that there are likely many places where we could replace
> Requires: with Recommends: (or even Suggests:) dependencies. In my
> ideal world, the difference between a Minimal and Server install would
> be identical to installing the same set of packages with Recommends:
> on or off.
> 
> 
> Some highlights of my initial research (with a lot of my raw data in
> the tarball attached to this email):
> 
> 
> == Minimal ==
> 
> === Disk Usage ===
> /boot: 79MB
> /: 755MB
> 
> 
> === Packages ===
> Total count: 270
> 
>  Largest 10 packages 
> 14288083: coreutils
> 14486819: glibc
> 16648994: grub2
> 18024040: kernel-modules
> 27253403: systemd
> 28453336: python3-libs
> 36004297: grub2-tools
> 53295853: kernel-core
> 86298752: linux-firmware
> 125178630: glibc-common
> 
>  10 Longest dependency chains 
> b'kbd': 116
> b'dnf-plugins-core': 117
> b'plymouth-scripts': 121
> b'plymouth': 121
> b'firewalld': 122
> b'grub2-tools': 125
> b'grub2': 131
> b'NetworkManager': 138
> b'dnf': 144
> b'dnf-yum': 145
> 
> 
> 
> 
> 
> 
> 
> 
> == Server ==
> 
> == Disk Usage ==
> /boot: 97MB [1]
> /: 1.2GB
> 
> 
> === Packages ===
> Total count: 603
> 
>  Largest 10 packages 
> 18590064: samba-client-libs
> 22484896: docker
> 25209005: python-libs
> 27253403: systemd
> 28453336: python3-libs
> 30242477: libicu
> 36004297: grub2-tools
> 53295853: kernel-core
> 86298752: linux-firmware
> 125178630: glibc-common
> 
>  10 Longest dependency chains 
> b'abrt-addon-python3': 170
> b'abrt-retrace-client': 171
> b'abrt-addon-pstoreoops': 171
> b'abrt-addon-ccpp': 183
> b'abrt-addon-vmcore': 190
> b'rolekit': 196
> b'abrt-cli': 214
> b'cockpit': 216
> b'freeipa-client': 249
> b'fedora-release-server': 252
> 
> 
>  Additional Package Groups 
> (These are the package groups we include above and beyond "Minimal
> Install")[2]
> 
> I'm not including package sizes here since most of the space comes
> from their dependencies.
> 
> * server-product
>  - fedora-release-server: dependency chain length: 252
>- cockpit: see below
>- rolekit: see below
>- systemd: chain 104
>  - chrony: 468KiB, chain 111
> * server-hardware-support
>  - lm_sensors: chain 139
>  - 

Packaging:NamingGuidelines Re: DNF is completly unable to act with local packages

[Sérgio Basto]

On Sáb, 2015-11-07 at 17:07 +0100, Michael Schwendt wrote:
> On Sat, 7 Nov 2015 17:18:14 +0200, Panu Matilainen wrote:
> 
> > Frankly I didn't even realize the 0.rc1.X scheme was against the 
> > guidelines since to me this is the (obviously) correct way to do it
> > with 
> > predictable pre-release names (its predictable when you're the one
> > doing 
> > the upstream tarballs), where the versioning goes like this:
> > 
> > 0.beta1.1
> > 0.beta1.2
> > 0.beta1.3
> > 0.beta2.1
> > 0.beta2.2
> > 0.rc1.1
> > 0.rc1.2
> > [...]
> > 0.rc1.5
> > 0.rc2.1
> > 1 (for the final)
> 
> And if you wanted to package a git snapshot somewhere on the middle
> of
> that road, you would need to be creative (and e.g. avoid going from
> "rc1"
> to "git").
> 
> No doubt -- there are versioning schemes where the alpha/beta/rc tags
> can even be part of %{version}, especially if upstream is aware of
> the
> pitfalls related to RPM version comparison. That has been a topic in
> the review queue just recently.
> 
> The guidelines aren't bullet-proof either. It's just that incidents
> like
> this raise my concerns with regard to this growing maze of packaging
> guidelines and the package review process.

I think the current numbering can be improved and 0.rc1.X doesn't look
bad to me , I agree should be 0.1.rc1.x but since rc is last state
before a release, the version 0.rc looks (even) better than 0.1.rc .

Anyway what I like in this approach is distinguish when we change
source and when bump the .spec, reading the guidelines [1] the example
of kismet pre-release svn checkout should use left and right versioning
:
 
kismet-0-0.1.20040110svn%{?dist}  
kismet-0-0.1.20040110svn.1%{?dist}
kismet-0-0.2.20040204svn%{?dist}

When we fix the .spec and don't change the source, we bump rightmost
version, when we change the source, we bump the left version, so we can
distinguish when we update the source and when we updated the .spec,
this contrast for me is important.  

[1] https://fedoraproject.org/wiki/Packaging:NamingGuidelines#Pre-Relea
se_packages

Best regards,
-- 
Sérgio M. B.


-- 
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 1282914] Review Request: perl-Lingua-Translit - Transliterates text between writing systems

[bugzilla]

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

Denis Fateyev  changed:

   What|Removed |Added

 CC||perl-devel@lists.fedoraproj
   ||ect.org



-- 
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 1282911] Review Request: perl-Crypt-Salsa20 - Encrypt data with the Salsa20 cipher

[bugzilla]

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

Denis Fateyev  changed:

   What|Removed |Added

 CC||perl-devel@lists.fedoraproj
   ||ect.org



-- 
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 1282917] Review Request: perl-Test-mysqld - Mysqld runner for tests

[bugzilla]

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

Denis Fateyev  changed:

   What|Removed |Added

 CC||perl-devel@lists.fedoraproj
   ||ect.org



-- 
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 1282917] Review Request: perl-Test-mysqld - Mysqld runner for tests

[bugzilla]

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



--- Comment #1 from Upstream Release Monitoring 
 ---
dfateyev's scratch build of perl-Test-mysqld-0.17-1.fc20.denf.src.rpm for epel7
failed http://koji.fedoraproject.org/koji/taskinfo?taskID=11886489

-- 
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 1282917] Review Request: perl-Test-mysqld - Mysqld runner for tests

[bugzilla]

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



--- Comment #2 from Upstream Release Monitoring 
 ---
dfateyev's scratch build of perl-Test-mysqld-0.17-1.fc20.denf.src.rpm for
rawhide completed http://koji.fedoraproject.org/koji/taskinfo?taskID=11886768

-- 
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 20151117 compose check report

[Fedora compose checker]

Missing expected images:

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

No images in this compose but not Rawhide 20151116

Images in Rawhide 20151116 but not this:

Games live i386
-- 
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

Re: Some analysis on the size of the minimal and Server installs of Fedora 23

[Stephen Gallagher]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 11/17/2015 05:00 AM, Stef Walter wrote:
> On 17.11.2015 02:39, Stephen Gallagher wrote:
>> (Please keep responses on the devel@ list; I've set it in the
>> Reply-To.)
>> 
>> To jump right to the premise: The default Fedora Server install
>> is Way Too Big(TM) and the minimal install (also available on the
>> Fedora Server install media) is also Too Big.
>> 
>> I've been trying to do some quick-and-dirty analysis of what is
>> in these default installations in order to figure out where we
>> should be focusing our efforts. I'll point out that there are two
>> goals that we need to keep in mind (and the reasons behind them)
>> in order of increasing importance:
>> 
>> 1) Reduce disk space usage. While disk space on physical devices
>> is becoming trivially cheap, disk space on Cloud deployments and
>> rented virtual servers is still comparatively very expensive. We
>> really want to minimize the amount of space that we use for
>> Fedora so that users can fit their applications (the stuff they
>> actually care about) into the remaining space without being
>> forced to buy a larger storage allotment.
>> 
>> 2) Reduce maintenance efforts. Every additional piece of software
>> on the system (referred to hereafter as "packages") increases
>> the maintenance burden on an administrator. Universally,
>> administrators prefer to have the smallest number of packages to
>> maintain for a variety of reasons: * Limiting update churn. The
>> more packages on the system, the more often that one will need to
>> run updates. * Limiting security exposure. Every package on the
>> system is another potential privilege-escalation point. Keeping
>> this number under control means a reduced likelihood of a
>> catastrophic breach. (The actual risk here is impossible to
>> quantify, but it can be assumed that less code == less potential
>> vulnerabilities. * Non-expert administrators do not always know
>> what is installed on their systems. This can lead to
>> unintentional breaches as an admin doesn't realize that one or
>> more services needs to be limited (such as in the firewall or via
>> SELinux).
>> 
>> With these two goals in mind, the most obvious approach to
>> improving this situation would be by reducing the number of
>> packages installed by default on the Minimal and Fedora Server
>> installs. As a specific goal of the Server Working Group, we want
>> to aim for a world wherein administrators will no longer desire
>> to install the Minimal install and instead will rely on the
>> platform provided by the default Fedora Server install. They do
>> not do this today because the Fedora Server installation is
>> considerably larger. I postulate that this is due primarily to
>> dependency bloat, which is where we should focus our efforts
>> during the Fedora 24 timeframe. I postulate (but have not yet 
>> confirmed) that there are likely many places where we could
>> replace Requires: with Recommends: (or even Suggests:)
>> dependencies. In my ideal world, the difference between a Minimal
>> and Server install would be identical to installing the same set
>> of packages with Recommends: on or off.
>> 
>> 
>> Some highlights of my initial research (with a lot of my raw data
>> in the tarball attached to this email):
>> 
>> 
>> == Minimal ==
>> 
>> === Disk Usage === /boot: 79MB /: 755MB
>> 
>> 
>> === Packages === Total count: 270
>> 
>>  Largest 10 packages  14288083: coreutils 14486819:
>> glibc 16648994: grub2 18024040: kernel-modules 27253403: systemd 
>> 28453336: python3-libs 36004297: grub2-tools 53295853:
>> kernel-core 86298752: linux-firmware 125178630: glibc-common
>> 
>>  10 Longest dependency chains  b'kbd': 116 
>> b'dnf-plugins-core': 117 b'plymouth-scripts': 121 b'plymouth':
>> 121 b'firewalld': 122 b'grub2-tools': 125 b'grub2': 131 
>> b'NetworkManager': 138 b'dnf': 144 b'dnf-yum': 145
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> == Server ==
>> 
>> == Disk Usage == /boot: 97MB [1] /: 1.2GB
>> 
>> 
>> === Packages === Total count: 603
>> 
>>  Largest 10 packages  18590064: samba-client-libs 
>> 22484896: docker 25209005: python-libs 27253403: systemd 
>> 28453336: python3-libs 30242477: libicu 36004297: grub2-tools 
>> 53295853: kernel-core 86298752: linux-firmware 125178630:
>> glibc-common
>> 
>>  10 Longest dependency chains  b'abrt-addon-python3':
>> 170 b'abrt-retrace-client': 171 b'abrt-addon-pstoreoops': 171 
>> b'abrt-addon-ccpp': 183 b'abrt-addon-vmcore': 190 b'rolekit':
>> 196 b'abrt-cli': 214 b'cockpit': 216 b'freeipa-client': 249 
>> b'fedora-release-server': 252
>> 
>> 
>>  Additional Package Groups  (These are the package groups
>> we include above and beyond "Minimal Install")[2]
>> 
>> I'm not including package sizes here since most of the space
>> comes from their dependencies.
>> 
>> * server-product - fedora-release-server: dependency chain
>> length: 252 - cockpit: see below - rolekit: see below - 

Re: FedRTC.org SIP and XMPP service - help needed

[Nikos Roussos]

On Fri, Nov 13, 2015 at 10:19 AM, Daniel Pocock  
wrote:

Fedora Talk was based on Asterisk.
https://fedoraproject.org/wiki/Infrastructure/Asterisk
Asterisk has lots of great features (voicemail, queues, etc) but it is
mainly for voice, it emphasizes SIP and at the time it was also quite
bad with IPv6, TLS and NAT.  FedRTC.org is based on a SIP proxy, not
Asterisk.  SIP proxies (and XMPP servers) tend to have a much bigger
emphasis on connectivity and they also tend to have less features, so
they are easier to support.  The repro SIP proxy has exceptionally 
good

TLS and IPv6 support.  Asterisk is not really optimized for federation
but federation is quite easy with a SIP proxy because of the emphasis 
on

connectivity.


One thing that is not clear to me from the website, is it just for 1:1 
calls or can be used for video calls with more than two participants?



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