Re: modularity: (my) expectations vs. reality

[Michal Novotny]

Hello Langdon,

On Tue, Aug 22, 2017 at 11:42 PM, Langdon White 
wrote:

>
>
> On Tue, Aug 22, 2017 at 2:40 PM Michal Novotny  wrote:
>
>> I would like to publicly note that I had completely different idea about
>> this project first time I have encountered it at the last Flock.
>>
>> My idea was that the project will target runtime rather than build-time
>> and will try to provide a set of packages that would be able to
>> e.g. spawn and run an httpd stack almost at one command.
>>
>> So that we will basically have e.g. this functionality:
>> https://hub.docker.com/r/p0bailey/docker-flask/ but integrated directly
>> in
>> distribution.
>>
>> This would make lots of sense to me because it would work similarly to
>> how upstream projects get
>> into Fedora (and RHEL) eventually. They need to pass certain criteria for
>> being accepted and then
>> there is is a group of people that maintains it in the given operating
>> system.
>>
>> Similarly for the modularity (as I saw it), there would be e.g. a docker
>> image that would slowly make
>> it into being a full-fledged system component that can be run in a
>> container or even natively on the host.
>>
>> The concrete implementation would probably include ansible where the
>> modules (being standard rpms)
>> would together make a big ansible playbook archive (e.g. placed under
>> /etc/playbook) that would include
>> default templates describing default sysadmin use-cases (like importing
>> db and web application start)
>> that could be overridden by a custom user template being placed at the
>> same subpath under e.g. /etc/custom-playbook.
>>
>> This would be a killer tool for sysadmins that could script their common
>> use-cases in a simple manner and completely
>> avoid any nerve-wrecking direct config manipulations on a running system
>> that (almost) each of us is familiar with. It would actually be
>> a common sysadmin (and power-user) language on RHEL based distros and I
>> think you can imagine this can be pretty cool.
>>
>> This approach would be also very flexible because you could define your
>> resources that you want to launch individual module
>> components on by altering a default resource setup and switch from
>> spawning everything natively to spawning everything in docker
>> containers locally to spawning everything in docker containers in
>> OpenShift staging instance to spawning everything in OpenShift production
>> instance.
>>
>> This also makes lots of sense from the human-effort point of view. We
>> could apply very well our sysadmin expertise in a certain
>> areas and transmit it directly to our users through code that we would
>> have written. Packagers would be config masters and they
>> would maintain default configuration to provide user with the most
>> effortless way to make something run (e.g. dovecot + postfix combo).
>>
>> And we could then also maintain custom playbooks for specific customers
>> meaning we would be able to create system cut directly to
>> their needs and have means to maintain it at large scales. And this would
>> basically mean having an rpm somewhere being named after
>> our customer e.g. mailserver-intel with a set of specific intel
>> mailserver ansible playbooks.
>>
>> After time I started to understand that the focus of modularity is
>> different and it rather focuses on having tight control over
>> the build process and lifecycle syncing across different system
>> components.
>>
>> I am not saying this is wrong or anything. It probably just means I was
>> mislead in my expectations but still I would like to share this
>> particular point of view as it makes lots of sense to me and it is
>> something that makes me excited.
>>
>> Sorry for not being technical or anything. You can consider this to be a
>> short story that doesn't deserve much attention.
>> clime
>>
>> ...Oh yeah, I started very basic PoC at https://pagure.io/lamp and
>> needed to postpone it a bit. It might be worth continuing
>>
>
> So.. in short, I think this is a cool idea. Also, I think this is the kind
> of thing that modularity could enable.
>

The question is if this isn't already enabled.


> We had in the game plan, way back, allowing super sophisticated "post
> install scripts" as part of the install profile concept. Basically, we had
> the idea that you could have an ansible playbook as part of the install
> profile. However, it is just on the "someday" list right now.
>

I think that having ansible-playbook as part of installation process is
quite demanding at the packaging guidelines.
Putting configuration files in the right places could be certainly alright
during installation but systemctl
starting services or creating db users and databases would probably not be
ok as it might interfere with user setup.
For that I think it would be good to have certain control component for
each module - basically just a command-line app
(lamp, django, flask, mailserver, ...) with man pages etc. 

[389-devel] Re: future of lib389 - seperate or merged?

[William Brown]

> 
> -- Merging lib389 to 389-ds-base
> 
> One proposal is to merge them. We would mix in lib389 and the
> dirsrvtests into lib389 tests. It is often the case that lib389's
> features are bound tightly to a version of directory server.

Hi all,

This seems to be the most popular answer right now (and I support it
too, but I'm biased :) )

I'm going to open a ticket to 389-ds-base to suggest this is the course
of action we take.

https://pagure.io/389-ds-base/issue/49363

-- 
Sincerely,

William Brown
Software Engineer
Red Hat, Australia/Brisbane



signature.asc
Description: This is a digitally signed message part
___
389-devel mailing list -- 389-devel@lists.fedoraproject.org
To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org

Platform Python changes and python3dist tags

[Scott Talbert]

Hi,

I was just trying to build a new package in Rawhide that built fine a few 
days ago.  The failure seems to be occurring because the python3 
setuptools_scm module isn't being found.  I'm using the new pythonXdist 
tags:


BuildRequires:  %{py2_dist py pytest setuptools_scm}
BuildRequires:  %{py3_dist py pytest setuptools_scm}

It seems this is causing several of the recently added platform-python
packages to be pulled in:
Installing:
 platform-python-pytestnoarch3.2.1-2.fc28   fedora 
438 k
 platform-python-setuptools_scmnoarch1.15.6-4.fc28  fedora 
36 k


Both the python3-setuptools_scm and platform-python-setuptools_scm 
packages have the python3dist tag:


$ rpm -q --provides -p platform-python-setuptools_scm-1.15.6-4.fc28.noarch.rpm
warning: platform-python-setuptools_scm-1.15.6-4.fc28.noarch.rpm: Header V3 
RSA/SHA256 Signature, key ID 9db62fb1: NOKEY
platform-python-setuptools_scm = 1.15.6-4.fc28
python3.6dist(setuptools-scm) = 1.15.6
python3dist(setuptools-scm) = 1.15.6

$ rpm -q --provides -p python3-setuptools_scm-1.15.6-4.fc28.noarch.rpm
warning: python3-setuptools_scm-1.15.6-4.fc28.noarch.rpm: Header V3 RSA/SHA256 
Signature, key ID 9db62fb1: NOKEY
python3-setuptools_scm = 1.15.6-4.fc28
python3.6dist(setuptools-scm) = 1.15.6
python3dist(setuptools-scm) = 1.15.6
[swt2c@rawhide-test ~][PROD]$

It seems that probably the platform-python packages shouldn't have these 
tags?


Scott
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Schedule for Wednesday's FPC Meeting (2017-08-23 17:00 UTC)

[James Antill]

On Tue, 2017-08-22 at 21:41 -0400, James Antill wrote:
>  Following is the list of topics that will be discussed in the FPC
> meeting Thursday at 2017-08-23 17:00 UTC in #fedora-meeting-2 on
 
 Wednesday, even.

> irc.freenode.net.
> 
>  Local time information (via. uitime):
> 
> = Day: Wednesday =
> 2017-08-23 10:00 PDT  US/Pacific
> 2017-08-23 13:00 EDT  --> US/Eastern <--
> 2017-08-23 17:00 UTC  UTC   
> 2017-08-23 18:00 BST  Europe/London 
> 2017-08-23 19:00 CEST Europe/Berlin 
> 2017-08-23 19:00 CEST Europe/Paris  
> 2017-08-23 22:30 IST  Asia/Calcutta 
> --- New Day: Thursday 
> 2017-08-24 01:00 HKT  Asia/Hong_Kong
> 2017-08-24 01:00 +08  Asia/Singapore
> 2017-08-24 02:00 JST  Asia/Tokyo
> 2017-08-24 03:00 AEST Australia/Brisbane
> 
>  Links to all tickets below can be found at: 
> 
> https://pagure.io/packaging-committee/issues?status=Open=meeting
> 
> = Followups =
> 
> 
> #topic #654 glibc file triggers
> .fpc 654
> https://pagure.io/packaging-committee/issue/654
> 
> #topic #691 noarch *sub*packages with arch-specific dependencies
> .fpc 691
> https://pagure.io/packaging-committee/issue/691
> 
> #topic #693 Wiki:Packaging:RPMMacros
> .fpc 693
> https://pagure.io/packaging-committee/issue/693
> 
> = Open Floor = 
> 
>  For more complete details, please visit each individual ticket.  The
> report of the agenda items can be found at:
> 
> https://pagure.io/packaging-committee/issues?status=Open=meeting
> 
>  If you would like to add something to this agenda, you can reply to
> this e-mail, file a new ticket at https://pagure.io/packaging-committee,
> e-mail me directly, or bring it up at the end of the meeting, during
> the open floor topic. Note that added topics may be deferred until
> the following meeting. 

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Schedule for Thursday's FPC Meeting (2017-08-23 17:00 UTC)

[James Antill]

 Following is the list of topics that will be discussed in the FPC
meeting Thursday at 2017-08-23 17:00 UTC in #fedora-meeting-2 on
irc.freenode.net.

 Local time information (via. uitime):

= Day: Wednesday =
2017-08-23 10:00 PDT  US/Pacific
2017-08-23 13:00 EDT  --> US/Eastern <--
2017-08-23 17:00 UTC  UTC   
2017-08-23 18:00 BST  Europe/London 
2017-08-23 19:00 CEST Europe/Berlin 
2017-08-23 19:00 CEST Europe/Paris  
2017-08-23 22:30 IST  Asia/Calcutta 
--- New Day: Thursday 
2017-08-24 01:00 HKT  Asia/Hong_Kong
2017-08-24 01:00 +08  Asia/Singapore
2017-08-24 02:00 JST  Asia/Tokyo
2017-08-24 03:00 AEST Australia/Brisbane

 Links to all tickets below can be found at: 

https://pagure.io/packaging-committee/issues?status=Open=meeting

= Followups =


#topic #654 glibc file triggers
.fpc 654
https://pagure.io/packaging-committee/issue/654

#topic #691 noarch *sub*packages with arch-specific dependencies
.fpc 691
https://pagure.io/packaging-committee/issue/691

#topic #693 Wiki:Packaging:RPMMacros
.fpc 693
https://pagure.io/packaging-committee/issue/693

= Open Floor = 

 For more complete details, please visit each individual ticket.  The
report of the agenda items can be found at:

https://pagure.io/packaging-committee/issues?status=Open=meeting

 If you would like to add something to this agenda, you can reply to
this e-mail, file a new ticket at https://pagure.io/packaging-committee,
e-mail me directly, or bring it up at the end of the meeting, during
the open floor topic. Note that added topics may be deferred until
the following meeting. 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: [modularity] Guidelines & Process

[Kevin Kofler]

Owen Taylor wrote:
> My particular interest is in what I consider the simplest use case -
> taking an existing leaf-node application (desktop or otherwise), creating
> a module that only includes that application and is not meant for building
> on top of, and creating a container or flatpak out of the module.
> 
> If we want to encourage maintainers of existing leaf-node applications do
> this - to move into the modularized world - then having to go through this
> process and also the container review process:
> 
>  https://fedoraproject.org/wiki/Container:Review_Process
> 
> Seems like a pretty large barrier and discouragement - and getting
> software into Fedora is already hard compared to the alternatives!

The complexity is inherent in Modularity. Instead of doing a simple RPM, you 
are now doing 3 separate deliverables:
1. the RPM
2. the module, and 
3. the container,
which can all contain errors, so they all need reviews.

> I'm wondering how we can streamline this case. Can we define some subset
> of modules that are simple enough that we can do all the checks that need
> to be done automatically? Does it make sense that in some cases we should
> skip the rpms/modules/containers structure in dist-git and just add
> module/container metadata along the RPM?

Oh dear, no! There is room for mistakes in each deliverable. Even an 
apparently "simple" module or container can contain conflicting packages 
(probably pulled in from different dependency modules) that breaks it.

If you want to avoid having to get 3 items reviewed, then you should only 
produce 1 item (the RPM) to begin with!

You have to realize that by introducing modules and containers, you are 
adding a huge amount of complexity that eats up our manpower, manpower that 
we are already lacking. I am particularly worried about the combinatorial 
explosion of module combinations (since the plan is even to allow 
mixing arbitrary module versions willy-nilly) which are just plain 
impossible to test exhaustively.

Modules and containers are a mistake.

Kevin Kofler
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

[Bug 1483566] perl-MooX-Options-4.103 is available

[bugzilla]

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



--- Comment #5 from Upstream Release Monitoring 
 ---
hotness's scratch build of perl-MooX-Options-4.103-1.el7.src.rpm for rawhide
completed http://koji.fedoraproject.org/koji/taskinfo?taskID=21410225

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

[Bug 1483566] perl-MooX-Options-4.103 is available

[bugzilla]

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

Upstream Release Monitoring  
changed:

   What|Removed |Added

Summary|perl-MooX-Options-4.102 is  |perl-MooX-Options-4.103 is
   |available   |available



--- Comment #3 from Upstream Release Monitoring 
 ---
Latest upstream release: 4.103
Current version/release in rawhide: 4.101-1.fc27
URL: http://search.cpan.org/dist/MooX-Options/

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.

Based on the information from anitya: 
https://release-monitoring.org/project/5969/

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

[Bug 1483566] perl-MooX-Options-4.103 is available

[bugzilla]

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



--- Comment #4 from Upstream Release Monitoring 
 ---
Created attachment 1316887
  --> https://bugzilla.redhat.com/attachment.cgi?id=1316887=edit
[patch] Update to 4.103 (#1483566)

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

[Bug 1484170] New: perl-Config-Model-Tester-3.002 is available

[bugzilla]

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

Bug ID: 1484170
   Summary: perl-Config-Model-Tester-3.002 is available
   Product: Fedora
   Version: rawhide
 Component: perl-Config-Model-Tester
  Keywords: FutureFeature, Triaged
  Assignee: jples...@redhat.com
  Reporter: upstream-release-monitor...@fedoraproject.org
QA Contact: extras...@fedoraproject.org
CC: jples...@redhat.com,
perl-devel@lists.fedoraproject.org, ppi...@redhat.com



Latest upstream release: 3.002
Current version/release in rawhide: 3.001-2.fc27
URL: http://search.cpan.org/dist/Config-Model-Tester/

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.

Based on the information from anitya: 
https://release-monitoring.org/project/6859/

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

Re: [DONE] Mass package change (python2- binary package renaming)

[Kevin Fenzi]

python-basemap seems wrong...

There's now a python3-basemap and a python2-basemap-examples but no
python2-basemap. ;(

Also, I'd like to very much thank you for doing this work. :)
It's great to get done, it's great to do it quickly and I know it's a
lot of hard work to script and build things.

kevin




signature.asc
Description: OpenPGP digital signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Fedora Rawhide-20170822.n.0 compose check report

[Fedora compose checker]

Missing expected images:

Server dvd i386
Workstation live i386
Server boot i386
Kde live i386

Failed openQA tests: 27/126 (x86_64), 1/2 (arm)

New failures (same test did not fail in Rawhide-20170821.n.0):

ID: 133158  Test: x86_64 Workstation-live-iso base_services_start
URL: https://openqa.fedoraproject.org/tests/133158
ID: 133175  Test: x86_64 KDE-live-iso base_services_start
URL: https://openqa.fedoraproject.org/tests/133175
ID: 133179  Test: x86_64 KDE-live-iso desktop_update_graphical
URL: https://openqa.fedoraproject.org/tests/133179
ID: 133183  Test: x86_64 KDE-live-iso desktop_notifications_postinstall
URL: https://openqa.fedoraproject.org/tests/133183
ID: 133185  Test: arm Minimal-raw_xz-raw.xz base_services_start_arm
URL: https://openqa.fedoraproject.org/tests/133185

Old failures (same test failed in Rawhide-20170821.n.0):

ID: 133135  Test: x86_64 Server-dvd-iso base_services_start
URL: https://openqa.fedoraproject.org/tests/133135
ID: 133139  Test: x86_64 Server-dvd-iso support_server
URL: https://openqa.fedoraproject.org/tests/133139
ID: 133142  Test: x86_64 Server-dvd-iso server_role_deploy_domain_controller
URL: https://openqa.fedoraproject.org/tests/133142
ID: 133144  Test: x86_64 Server-dvd-iso server_cockpit_default
URL: https://openqa.fedoraproject.org/tests/133144
ID: 133148  Test: x86_64 Server-dvd-iso server_role_deploy_database_server
URL: https://openqa.fedoraproject.org/tests/133148
ID: 133156  Test: x86_64 Workstation-live-iso install_no_user
URL: https://openqa.fedoraproject.org/tests/133156
ID: 133182  Test: x86_64 KDE-live-iso desktop_notifications_live
URL: https://openqa.fedoraproject.org/tests/133182
ID: 133188  Test: x86_64 universal upgrade_desktop_64bit
URL: https://openqa.fedoraproject.org/tests/133188
ID: 133189  Test: x86_64 universal upgrade_server_64bit
URL: https://openqa.fedoraproject.org/tests/133189
ID: 133190  Test: x86_64 universal upgrade_server_domain_controller
URL: https://openqa.fedoraproject.org/tests/133190
ID: 133192  Test: x86_64 universal upgrade_kde_64bit
URL: https://openqa.fedoraproject.org/tests/133192
ID: 133193  Test: x86_64 universal upgrade_desktop_encrypted_64bit
URL: https://openqa.fedoraproject.org/tests/133193
ID: 133194  Test: x86_64 universal upgrade_2_minimal_64bit
URL: https://openqa.fedoraproject.org/tests/133194
ID: 133195  Test: x86_64 universal upgrade_2_desktop_64bit
URL: https://openqa.fedoraproject.org/tests/133195
ID: 133196  Test: x86_64 universal upgrade_2_server_64bit
URL: https://openqa.fedoraproject.org/tests/133196
ID: 133197  Test: x86_64 universal upgrade_2_kde_64bit
URL: https://openqa.fedoraproject.org/tests/133197
ID: 133198  Test: x86_64 universal upgrade_2_desktop_encrypted_64bit
URL: https://openqa.fedoraproject.org/tests/133198
ID: 133200  Test: x86_64 universal install_shrink_ext4
URL: https://openqa.fedoraproject.org/tests/133200
ID: 133201  Test: x86_64 universal install_shrink_ntfs
URL: https://openqa.fedoraproject.org/tests/133201
ID: 133206  Test: x86_64 universal support_server
URL: https://openqa.fedoraproject.org/tests/133206
ID: 133255  Test: x86_64 universal upgrade_minimal_64bit
URL: https://openqa.fedoraproject.org/tests/133255
ID: 133256  Test: x86_64 universal install_rescue_encrypted
URL: https://openqa.fedoraproject.org/tests/133256
ID: 133257  Test: x86_64 universal install_rescue_encrypted@uefi
URL: https://openqa.fedoraproject.org/tests/133257

Soft failed openQA tests: 53/126 (x86_64)
(Tests completed, but using a workaround for a known bug)

New soft failures (same test did not soft fail in Rawhide-20170821.n.0):

ID: 133208  Test: x86_64 universal install_repository_http_graphical
URL: https://openqa.fedoraproject.org/tests/133208
ID: 133233  Test: x86_64 universal install_blivet_no_swap
URL: https://openqa.fedoraproject.org/tests/133233

Old soft failures (same test soft failed in Rawhide-20170821.n.0):

ID: 133130  Test: x86_64 Server-boot-iso install_default
URL: https://openqa.fedoraproject.org/tests/133130
ID: 133131  Test: x86_64 Server-boot-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/133131
ID: 133132  Test: x86_64 Server-dvd-iso install_default_upload
URL: https://openqa.fedoraproject.org/tests/133132
ID: 133133  Test: x86_64 Server-dvd-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/133133
ID: 133152  Test: x86_64 Everything-boot-iso install_default
URL: https://openqa.fedoraproject.org/tests/133152
ID: 133153  Test: x86_64 Everything-boot-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/133153
ID: 133186  Test: x86_64 universal install_package_set_minimal
URL: https://openqa.fedoraproject.org/tests/133186
ID: 133187  Test: x86_64 universal install_anaconda_text
URL: https://openqa.fedoraproject.org/tests/133187
ID: 133199  Test: x86_64 universal 

Re: modularity: (my) expectations vs. reality

[Matthew Miller]

On Tue, Aug 22, 2017 at 08:37:59PM +0200, Michal Novotny wrote:
> My idea was that the project will target runtime rather than
> build-time and will try to provide a set of packages that would be
> able to e.g. spawn and run an httpd stack almost at one command.

I think what you describe is something we can help enable with
modularity, and it's kind of like what I expect the future path of
Fedora Server and ansible-based roles to be.



-- 
Matthew Miller

Fedora Project Leader
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: modularity: (my) expectations vs. reality

[Langdon White]

On Tue, Aug 22, 2017 at 2:40 PM Michal Novotny  wrote:

> I would like to publicly note that I had completely different idea about
> this project first time I have encountered it at the last Flock.
>
> My idea was that the project will target runtime rather than build-time
> and will try to provide a set of packages that would be able to
> e.g. spawn and run an httpd stack almost at one command.
>
> So that we will basically have e.g. this functionality:
> https://hub.docker.com/r/p0bailey/docker-flask/ but integrated directly in
> distribution.
>
> This would make lots of sense to me because it would work similarly to how
> upstream projects get
> into Fedora (and RHEL) eventually. They need to pass certain criteria for
> being accepted and then
> there is is a group of people that maintains it in the given operating
> system.
>
> Similarly for the modularity (as I saw it), there would be e.g. a docker
> image that would slowly make
> it into being a full-fledged system component that can be run in a
> container or even natively on the host.
>
> The concrete implementation would probably include ansible where the
> modules (being standard rpms)
> would together make a big ansible playbook archive (e.g. placed under
> /etc/playbook) that would include
> default templates describing default sysadmin use-cases (like importing db
> and web application start)
> that could be overridden by a custom user template being placed at the
> same subpath under e.g. /etc/custom-playbook.
>
> This would be a killer tool for sysadmins that could script their common
> use-cases in a simple manner and completely
> avoid any nerve-wrecking direct config manipulations on a running system
> that (almost) each of us is familiar with. It would actually be
> a common sysadmin (and power-user) language on RHEL based distros and I
> think you can imagine this can be pretty cool.
>
> This approach would be also very flexible because you could define your
> resources that you want to launch individual module
> components on by altering a default resource setup and switch from
> spawning everything natively to spawning everything in docker
> containers locally to spawning everything in docker containers in
> OpenShift staging instance to spawning everything in OpenShift production
> instance.
>
> This also makes lots of sense from the human-effort point of view. We
> could apply very well our sysadmin expertise in a certain
> areas and transmit it directly to our users through code that we would
> have written. Packagers would be config masters and they
> would maintain default configuration to provide user with the most
> effortless way to make something run (e.g. dovecot + postfix combo).
>
> And we could then also maintain custom playbooks for specific customers
> meaning we would be able to create system cut directly to
> their needs and have means to maintain it at large scales. And this would
> basically mean having an rpm somewhere being named after
> our customer e.g. mailserver-intel with a set of specific intel mailserver
> ansible playbooks.
>
> After time I started to understand that the focus of modularity is
> different and it rather focuses on having tight control over
> the build process and lifecycle syncing across different system
> components.
>
> I am not saying this is wrong or anything. It probably just means I was
> mislead in my expectations but still I would like to share this
> particular point of view as it makes lots of sense to me and it is
> something that makes me excited.
>
> Sorry for not being technical or anything. You can consider this to be a
> short story that doesn't deserve much attention.
> clime
>
> ...Oh yeah, I started very basic PoC at https://pagure.io/lamp and needed
> to postpone it a bit. It might be worth continuing
>

So.. in short, I think this is a cool idea. Also, I think this is the kind
of thing that modularity could enable.

We had in the game plan, way back, allowing super sophisticated "post
install scripts" as part of the install profile concept. Basically, we had
the idea that you could have an ansible playbook as part of the install
profile. However, it is just on the "someday" list right now.

You could, very easily, have streams or install profiles per target
audience, you can (in theory) do this now, but, we don't want to have the
branching and the like get out of control until we actually understand how
this stuff is all going to come together. So, you could do it in COPR, once
module builds come online, but perhaps not in dist-git.

We (fedora, not just modularity) also have been looking/implementing
"system containers[1]" which are kind of like a "native feeling
containerized application". Containers are already being built (sorta, need
the infra to be finished) from modules providing more flexibility by
allowing simple stream changing without modifying the dockerfiles.

So, I think your idea is exactly what we want the modularity flexibility
for. 

Re: [modularity] Guidelines & Process

[Langdon White]

On Tue, Aug 22, 2017 at 9:53 AM Owen Taylor  wrote:

> Hi Langdon,
>
> Thanks for all the work that went into the process and guidelines!
>
> My particular interest is in what I consider the simplest use case -
> taking an existing leaf-node application (desktop or otherwise), creating a
> module that only includes that application and is not meant for building on
> top of, and creating a container or flatpak out of the module.
>
> If we want to encourage maintainers of existing leaf-node applications do
> this - to move into the modularized world - then having to go through this
> process and also the container review process:
>
>  https://fedoraproject.org/wiki/Container:Review_Process
>
> Seems like a pretty large barrier and discouragement - and getting
> software into Fedora is already hard compared to the alternatives!
>
> I'm wondering how we can streamline this case. Can we define some subset
> of modules that are simple enough that we can do all the checks that need
> to be done automatically? Does it make sense that in some cases we should
> skip the rpms/modules/containers structure in dist-git and just add
> module/container metadata along the RPM?
>
>
We want to do exactly this and I would like the "trivial status" to evolve
to this (before f27). We have already been struggling with how the
guidelines talk a lot about "so there is this field but you really
shouldn't fill it in because infra will do it for you." Specifically, Nick
(cc'd) had some thoughts on this I know. However, right now, we have a
couple problems:
a) the modules are mostly still the complex ones
b) not all the automation tooling is done yet

I regularly half-joke that the user-modifiable component of the modulemd
should just be the srpm and the branch to follow and everything else is
just automatic.

I assume you meant "metadata along the RPM" -> "metadata alongside the RPM"
vs something else. If so, I think our further goal is that we have a tool
that just takes an srpm as input and just generates the modulemd and then
generates "container metadata" (at least dockerfiles for now) and then
sticks it in the correct repository. We have some of these tools already.
Ultimately, we could re-gen on updates to the rpms automatically.

However, I do think we want some separation so that if we want to base
modules or containers on something other than rpms some day, we aren't
tightly coupled. This may be a trivial consideration but it was the
original thinking and if the tools above come to fruition it should be moot
anyway.


> I'd love to discuss with people at Flock.
>

yes, please, but, I think you are perfectly correct.. so :)


>
> Thanks,
> Owen
>
> P.S. - I don't mean to discourage adoption of these guidelines for more
> complex cases, and as a way we can get started creating simpler modules.
> I'm just wondering how we can lighten the load on packagers.
>
> - Original Message -
> > The Modularity WG has proposed a set of guidelines[1] and a process[2]
> for
> > adding modules to Fedora and we would love your feedback. Our general
> docs
> > are on Pagure[3] if you need more background/further information.
> > Please share your feedback here or directly on the wiki page(s). You can
> also
> > file issues/PRs on pagure[4] if you have other comments/edits/etc.
> >
> > thanks
> > Langdon
> >
> > [1]:
> >
> https://fedoraproject.org/wiki/Module:Guidelines?rd=Fedora_Packaging_Guidelines_for_Modules
> > [2]: https://fedoraproject.org/wiki/Module:Review_Process
> > [3]: https://docs.pagure.org/modularity/
> > [4]: https://pagure.io/modularity
> >
> > ___
> > devel mailing list -- devel@lists.fedoraproject.org
> > To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> >
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

[Bug 1481915] perl-Text-Fuzzy-0.27 is available

[bugzilla]

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



--- Comment #4 from Fedora Update System  ---
perl-Text-Fuzzy-0.27-1.fc25 has been submitted as an update to Fedora 25.
https://bodhi.fedoraproject.org/updates/FEDORA-2017-76a36d95cf

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

[Bug 1481915] perl-Text-Fuzzy-0.27 is available

[bugzilla]

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



--- Comment #5 from Fedora Update System  ---
perl-Text-Fuzzy-0.27-1.fc26 has been submitted as an update to Fedora 26.
https://bodhi.fedoraproject.org/updates/FEDORA-2017-4fc72f83be

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

[Bug 1469110] perl-Text-Fuzzy-0.26 is available

[bugzilla]

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



--- Comment #15 from Fedora Update System  ---
perl-Text-Fuzzy-0.27-1.fc25 has been submitted as an update to Fedora 25.
https://bodhi.fedoraproject.org/updates/FEDORA-2017-76a36d95cf

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

Re: [modularity] Guidelines & Process

[Langdon White]

On Tue, Aug 22, 2017 at 5:23 AM Petr Pisar  wrote:

> On 2017-08-21, Langdon White  wrote:
> > [2]: https://fedoraproject.org/wiki/Module:Review_Process
>
> I don't understand purpose of this paragraph:
>
> > As a Contributor, you should only be creating modules out of
> > pre-existing software in the Fedora RPM repositories which adheres to
> > the Package Naming Guidelines and Packaging Guidelines. Make note that
> > the only software allowed in official Fedora Modules must be sourced
> > from Fedora official RPMs. The Module Build Service will reject
> > attempts to build from sources not provided by Fedora's dist-git.
>
> This wording accepts modules that refer to non Fedora RPM components
> (i.e. different git repositories than Fedora's dist-git). It
> only notes it will be impossible to build such module in Koji.
>
> Is it on purpose to allow people to host modulemd files in Fedora's
> dist-git without building modules in Fedora infrastracture and instead
> building them somewhere else?
>
> If not, then a simple fix is s/you should only/you must only/.
>
>
Nope, I just struggled with writing this part. Good catch and fixed.

thanks
Langdon


> -- Petr
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

[Bug 1479680] perl-Time-OlsonTZ-Download-0.006 is available

[bugzilla]

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



--- Comment #12 from Fedora Update System  ---
perl-Time-OlsonTZ-Download-0.006-2.fc26 has been pushed to the Fedora 26 stable
repository. If problems still persist, please make note of it in this bug
report.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

[Bug 1477175] fusioninventory-agent-2.3.21 is available

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|ON_QA   |CLOSED
   Fixed In Version||fusioninventory-agent-2.3.2
   ||1-2.fc26
 Resolution|--- |ERRATA
Last Closed||2017-08-22 16:41:08



--- Comment #22 from Fedora Update System  ---
fusioninventory-agent-2.3.21-2.fc26 has been pushed to the Fedora 26 stable
repository. If problems still persist, please make note of it in this bug
report.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

[Bug 1477136] perl-No-Worries-1.5 is available

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|ON_QA   |CLOSED
   Fixed In Version||perl-No-Worries-1.5-1.fc26
 Resolution|--- |ERRATA
Last Closed||2017-08-22 16:40:25



--- Comment #7 from Fedora Update System  ---
perl-No-Worries-1.5-1.fc26 has been pushed to the Fedora 26 stable repository.
If problems still persist, please make note of it in this bug report.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

Re: Old updates in F26 testing

[Rex Dieter]

Bojan Smojver wrote:

> Was just curious, anyone understands why there are so many obsolete
> updates in F26 testing repository? For example, there is firefox 54.0
> from June, other stuff back from April etc.

I think one intention of keeping stuff in testing (for at least little 
while) is to allow mirrors that utilize hard-linking to save on bandwidth, 
when things move from testing->stable updates

-- Rex
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

modularity: (my) expectations vs. reality

[Michal Novotny]

I would like to publicly note that I had completely different idea about
this project first time I have encountered it at the last Flock.

My idea was that the project will target runtime rather than build-time and
will try to provide a set of packages that would be able to
e.g. spawn and run an httpd stack almost at one command.

So that we will basically have e.g. this functionality:
https://hub.docker.com/r/p0bailey/docker-flask/ but integrated directly in
distribution.

This would make lots of sense to me because it would work similarly to how
upstream projects get
into Fedora (and RHEL) eventually. They need to pass certain criteria for
being accepted and then
there is is a group of people that maintains it in the given operating
system.

Similarly for the modularity (as I saw it), there would be e.g. a docker
image that would slowly make
it into being a full-fledged system component that can be run in a
container or even natively on the host.

The concrete implementation would probably include ansible where the
modules (being standard rpms)
would together make a big ansible playbook archive (e.g. placed under
/etc/playbook) that would include
default templates describing default sysadmin use-cases (like importing db
and web application start)
that could be overridden by a custom user template being placed at the same
subpath under e.g. /etc/custom-playbook.

This would be a killer tool for sysadmins that could script their common
use-cases in a simple manner and completely
avoid any nerve-wrecking direct config manipulations on a running system
that (almost) each of us is familiar with. It would actually be
a common sysadmin (and power-user) language on RHEL based distros and I
think you can imagine this can be pretty cool.

This approach would be also very flexible because you could define your
resources that you want to launch individual module
components on by altering a default resource setup and switch from spawning
everything natively to spawning everything in docker
containers locally to spawning everything in docker containers in OpenShift
staging instance to spawning everything in OpenShift production instance.

This also makes lots of sense from the human-effort point of view. We could
apply very well our sysadmin expertise in a certain
areas and transmit it directly to our users through code that we would have
written. Packagers would be config masters and they
would maintain default configuration to provide user with the most
effortless way to make something run (e.g. dovecot + postfix combo).

And we could then also maintain custom playbooks for specific customers
meaning we would be able to create system cut directly to
their needs and have means to maintain it at large scales. And this would
basically mean having an rpm somewhere being named after
our customer e.g. mailserver-intel with a set of specific intel mailserver
ansible playbooks.

After time I started to understand that the focus of modularity is
different and it rather focuses on having tight control over
the build process and lifecycle syncing across different system components.

I am not saying this is wrong or anything. It probably just means I was
mislead in my expectations but still I would like to share this
particular point of view as it makes lots of sense to me and it is
something that makes me excited.

Sorry for not being technical or anything. You can consider this to be a
short story that doesn't deserve much attention.
clime

...Oh yeah, I started very basic PoC at https://pagure.io/lamp and needed
to postpone it a bit. It might be worth continuing
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Old updates in F26 testing

[Bojan Smojver]

Was just curious, anyone understands why there are so many obsolete
updates in F26 testing repository? For example, there is firefox 54.0
from June, other stuff back from April etc.

-- 
Bojan
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

[Bug 1482299] perl-SOAP-Lite-1.22 is available

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|MODIFIED|ON_QA



--- Comment #5 from Fedora Update System  ---
perl-SOAP-Lite-1.22-1.fc26 has been pushed to the Fedora 26 testing repository.
If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here:
https://bodhi.fedoraproject.org/updates/FEDORA-2017-abeedd517d

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

[Bug 1484066] $daemon_group in /etc/amavisd/amavisd.conf doesn' t set the daemon group

[bugzilla]

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



--- Comment #1 from Juan Orti  ---
That will be because the user and group is enforced in the service unit. I'll
check it.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

[389-devel] [Review Request] - Setup Test

[Amita Sharma]

Hello,

I have made changes in setup test suit and uploaded patch on ticket [1].
Please review.

Thanks,
Amita

[1]. https://pagure.io/389-ds-base/issue/47840
___
389-devel mailing list -- 389-devel@lists.fedoraproject.org
To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org

Re: retired packages in rawhide/f27

[Kevin Fenzi]

On 08/22/2017 02:30 AM, Petr Pisar wrote:
> On 2017-08-22, Honggang LI  wrote:
>> hi,
>>
>> https://bugzilla.redhat.com/show_bug.cgi?id=1404043#c41
>> libibcm, libibumad, libibverbs, librdmacm and ibacm had been replaced by
>> the new rdma-core package. Those five packages are sub-packages of the
>> new rdma-core package.
>>
>> I had retired the f27 and rawhide branches of those five packages in
>> last week. But the build...@fedoraproject.org keep sending messages to
>> complain broken dependencies for those five packages.
>>
> The "fedgkg retire" tool is/was broken and could not perform a retirement
> .
> 
> Koji reports for ibacm source package:
> 
> $ koji list-pkgs --show-blocked --package=ibacm
> Package Tag Extra Arches Owner
>   
> --- ---  
> ---
> [...]
> ibacm   f27  releng   
>[BLOCKED]
> ibacm   f26-Alphahonli
>   
> ibacm   f26-Beta honli
>   
> ibacm   f28  releng   
>   
> 
> It means the package was not removed from Rawhide (f28) repositories.
> 
> If rerunning "fedpkg retire" does not help, you should file a ticket to
>  or
> .

Yeah, the retirement here seems to have only happened in f27.

I suspect this was right around branching time when you did this and
something wasn't happy.

In any case, due to the rdma-core not building on armv7, blocking these
packages currently breaks composes. (Thats one reason why we have not
had a branched compose in a while).

So, I would appreciate it if you could leave f28/rawhide for now (since
we do get composes there) until we get lorax set to handle things.

kevin




signature.asc
Description: OpenPGP digital signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

[Bug 1483775] perl-DateTime-1.44 is available

[bugzilla]

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

Paul Howarth  changed:

   What|Removed |Added

 Status|NEW |CLOSED
   Fixed In Version||perl-DateTime-1.44-1.fc27
   ||perl-DateTime-1.44-1.fc28
 Resolution|--- |RAWHIDE
Last Closed||2017-08-22 11:51:33



--- Comment #4 from Paul Howarth  ---
Rawhide build: https://koji.fedoraproject.org/koji/taskinfo?taskID=21402555

F27 build: https://koji.fedoraproject.org/koji/taskinfo?taskID=21402832

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

[Bug 1483775] perl-DateTime-1.44 is available

[bugzilla]

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



--- Comment #3 from Upstream Release Monitoring 
 ---
pghmcfc's perl-DateTime-1.44-1.fc27 completed
http://koji.fedoraproject.org/koji/buildinfo?buildID=960037

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

pghmcfc pushed to perl-DateTime (f27). "Update to 1.44 (..more)"

[notifications]

From f164fe190f68af4f49c59721956789ab9da1e796 Mon Sep 17 00:00:00 2001
From: Paul Howarth 
Date: Aug 22 2017 15:19:39 +
Subject: Update to 1.44


- New upstream release 1.44
  - Added a stringify() method, which does exactly the same thing as
stringification overloading does (GH#58)
  - Added an is_last_day_of_month() method to indicate whether or not an object
falls on the last day of its month (GH#60)

---

diff --git a/perl-DateTime.spec b/perl-DateTime.spec
index a2d8027..ccd6c18 100644
--- a/perl-DateTime.spec
+++ b/perl-DateTime.spec
@@ -1,7 +1,7 @@
 Name:   perl-DateTime
 Epoch:  2
-Version:1.43
-Release:4%{?dist}
+Version:1.44
+Release:1%{?dist}
 Summary:Date and time object for Perl
 License:Artistic 2.0
 URL:http://search.cpan.org/dist/DateTime/
@@ -105,6 +105,13 @@ make test
 %{_mandir}/man3/DateTime::Types.3*
 
 %changelog
+* Tue Aug 22 2017 Paul Howarth  - 2:1.44-1
+- Update to 1.44
+  - Added a stringify() method, which does exactly the same thing as
+stringification overloading does (GH#58)
+  - Added an is_last_day_of_month() method to indicate whether or not an object
+falls on the last day of its month (GH#60)
+
 * Thu Aug 03 2017 Fedora Release Engineering  - 
2:1.43-4
 - Rebuilt for https://fedoraproject.org/wiki/Fedora_27_Binutils_Mass_Rebuild
 
diff --git a/sources b/sources
index a11c616..0d07848 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-SHA512 (DateTime-1.43.tar.gz) = 
53714bb82561180d8a945e22ad708d0ae64649c2e99f35fe35a8dcdd0553744d1f1ab2a0f16696edd270d5307707a8eda398eb45c2c418fb30b0e82571a67c61
+SHA512 (DateTime-1.44.tar.gz) = 
a256efc26ad1f2859f3371b70e5edd0d962d2c19c54b746178e3945b1dc665621d09b7ac6be279c7e92b8aa91763c5df2d8ccbca1832ba69ac810feb8533ca71



https://src.fedoraproject.org/rpms/perl-DateTime/c/f164fe190f68af4f49c59721956789ab9da1e796?branch=f27
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

pghmcfc pushed to perl-List-MoreUtils (f27). "Update to 0.423 (..more)"

[notifications]

From 75fd7441074b6dafce1cd8b952f3b75db1425579 Mon Sep 17 00:00:00 2001
From: Paul Howarth 
Date: Aug 22 2017 15:06:17 +
Subject: Update to 0.423


- New upstream release 0.423
  - Sync version with List::MoreUtils::XS
  - Add some new functions: qsort (XS only), binsert, bremove, listcmp,
arrayify (CPAN RT#17230), samples (CPAN RT#77562), minmaxstr
(CPAN RT#106401), lower_bound, upper_bound, equal_range, frequencies
occurrences, mode (CPAN RT#91991), zip6 (CPAN RT#42921), reduce_0,
reduce_1, reduce_u
  - Add examples for binsert/bremove (LMU::XS GH#1)
  - Improve tests
  - Make List::MoreUtils::XS independent from List::MoreUtils
  - Improve Makefile.PL regarding some build artifacts
  - Update tests to latest List::MoreUtils::XS
  - Recommend List::MoreUtils::XS 0.423
- BR:/R: LMU::XS ≥ 0.423 as there is no longer a bootstrapping issue

---

diff --git a/perl-List-MoreUtils.spec b/perl-List-MoreUtils.spec
index 5fdb099..acdcb1d 100644
--- a/perl-List-MoreUtils.spec
+++ b/perl-List-MoreUtils.spec
@@ -1,6 +1,6 @@
 Name:  perl-List-MoreUtils
-Version:   0.419
-Release:   3%{?dist}
+Version:   0.423
+Release:   1%{?dist}
 Summary:   Provide the stuff missing in List::Util
 License:   (GPL+ or Artistic) and ASL 2.0
 URL:   http://search.cpan.org/dist/List-MoreUtils/
@@ -10,20 +10,23 @@ BuildArch:  noarch
 BuildRequires: coreutils
 BuildRequires: findutils
 BuildRequires: make
-BuildRequires: perl-interpreter >= 4:5.16.0
 BuildRequires: perl-generators
+BuildRequires: perl-interpreter
 BuildRequires: perl(Config)
 BuildRequires: perl(ExtUtils::MakeMaker) >= 6.75
 BuildRequires: perl(lib)
 # Module Runtime
 BuildRequires: perl(Carp)
 BuildRequires: perl(Exporter::Tiny) >= 0.038
+BuildRequires: perl(List::MoreUtils::XS) >= 0.423
 BuildRequires: perl(strict)
 BuildRequires: perl(vars)
 BuildRequires: perl(warnings)
 # Test Suite
 BuildRequires: perl(base)
 BuildRequires: perl(Exporter)
+BuildRequires: perl(List::Util)
+BuildRequires: perl(Math::Trig)
 BuildRequires: perl(overload)
 BuildRequires: perl(Scalar::Util)
 BuildRequires: perl(Storable)
@@ -37,7 +40,7 @@ BuildRequires:perl(Test::LeakTrace)
 # Runtime
 Requires:  perl(:MODULE_COMPAT_%(eval "`perl -V:version`"; echo $version))
 Requires:  perl(Carp)
-Recommends:perl(List::MoreUtils::XS) >= 0.418
+Requires:  perl(List::MoreUtils::XS) >= 0.423
 
 %description
 List::MoreUtils provides some trivial but commonly needed functionality
@@ -70,6 +73,22 @@ make test
 %{_mandir}/man3/List::MoreUtils::PP.3*
 
 %changelog
+* Tue Aug 22 2017 Paul Howarth  - 0.423-1
+- Update to 0.423
+  - Sync version with List::MoreUtils::XS
+  - Add some new functions: qsort (XS only), binsert, bremove, listcmp,
+arrayify (CPAN RT#17230), samples (CPAN RT#77562), minmaxstr
+(CPAN RT#106401), lower_bound, upper_bound, equal_range, frequencies
+occurrences, mode (CPAN RT#91991), zip6 (CPAN RT#42921), reduce_0,
+reduce_1, reduce_u
+  - Add examples for binsert/bremove (LMU::XS GH#1)
+  - Improve tests
+  - Make List::MoreUtils::XS independent from List::MoreUtils
+  - Improve Makefile.PL regarding some build artifacts
+  - Update tests to latest List::MoreUtils::XS
+  - Recommend List::MoreUtils::XS 0.423
+- BR:/R: LMU::XS ≥ 0.423 as there is no longer a bootstrapping issue
+
 * Thu Jul 27 2017 Fedora Release Engineering  - 
0.419-3
 - Rebuilt for https://fedoraproject.org/wiki/Fedora_27_Mass_Rebuild
 
diff --git a/sources b/sources
index 9771b9b..04b0787 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-SHA512 (List-MoreUtils-0.419.tar.gz) = 
d13beb5031d1559c2ec4cb93826e86f0f314c4f10c4fdcac6910de0cb039199599911838eadd499e81cb41025aae2a52d69a259653a9637679a1705c7adcd37a
+SHA512 (List-MoreUtils-0.423.tar.gz) = 
f88e683ce50c4e0e0df9731af9ace3be7ddfd7477292ec14ae4d013d99408c87073f3abdd893e8a90638db936da2d58d6fa588e55d89b8087b2005909154d686



https://src.fedoraproject.org/rpms/perl-List-MoreUtils/c/75fd7441074b6dafce1cd8b952f3b75db1425579?branch=f27
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

pghmcfc pushed to perl-DateTime (master). "Update to 1.44 (..more)"

[notifications]

From f164fe190f68af4f49c59721956789ab9da1e796 Mon Sep 17 00:00:00 2001
From: Paul Howarth 
Date: Aug 22 2017 15:19:39 +
Subject: Update to 1.44


- New upstream release 1.44
  - Added a stringify() method, which does exactly the same thing as
stringification overloading does (GH#58)
  - Added an is_last_day_of_month() method to indicate whether or not an object
falls on the last day of its month (GH#60)

---

diff --git a/perl-DateTime.spec b/perl-DateTime.spec
index a2d8027..ccd6c18 100644
--- a/perl-DateTime.spec
+++ b/perl-DateTime.spec
@@ -1,7 +1,7 @@
 Name:   perl-DateTime
 Epoch:  2
-Version:1.43
-Release:4%{?dist}
+Version:1.44
+Release:1%{?dist}
 Summary:Date and time object for Perl
 License:Artistic 2.0
 URL:http://search.cpan.org/dist/DateTime/
@@ -105,6 +105,13 @@ make test
 %{_mandir}/man3/DateTime::Types.3*
 
 %changelog
+* Tue Aug 22 2017 Paul Howarth  - 2:1.44-1
+- Update to 1.44
+  - Added a stringify() method, which does exactly the same thing as
+stringification overloading does (GH#58)
+  - Added an is_last_day_of_month() method to indicate whether or not an object
+falls on the last day of its month (GH#60)
+
 * Thu Aug 03 2017 Fedora Release Engineering  - 
2:1.43-4
 - Rebuilt for https://fedoraproject.org/wiki/Fedora_27_Binutils_Mass_Rebuild
 
diff --git a/sources b/sources
index a11c616..0d07848 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-SHA512 (DateTime-1.43.tar.gz) = 
53714bb82561180d8a945e22ad708d0ae64649c2e99f35fe35a8dcdd0553744d1f1ab2a0f16696edd270d5307707a8eda398eb45c2c418fb30b0e82571a67c61
+SHA512 (DateTime-1.44.tar.gz) = 
a256efc26ad1f2859f3371b70e5edd0d962d2c19c54b746178e3945b1dc665621d09b7ac6be279c7e92b8aa91763c5df2d8ccbca1832ba69ac810feb8533ca71



https://src.fedoraproject.org/rpms/perl-DateTime/c/f164fe190f68af4f49c59721956789ab9da1e796?branch=master
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

pghmcfc pushed to perl-List-MoreUtils (master). "Update to 0.423 (..more)"

[notifications]

From 75fd7441074b6dafce1cd8b952f3b75db1425579 Mon Sep 17 00:00:00 2001
From: Paul Howarth 
Date: Aug 22 2017 15:06:17 +
Subject: Update to 0.423


- New upstream release 0.423
  - Sync version with List::MoreUtils::XS
  - Add some new functions: qsort (XS only), binsert, bremove, listcmp,
arrayify (CPAN RT#17230), samples (CPAN RT#77562), minmaxstr
(CPAN RT#106401), lower_bound, upper_bound, equal_range, frequencies
occurrences, mode (CPAN RT#91991), zip6 (CPAN RT#42921), reduce_0,
reduce_1, reduce_u
  - Add examples for binsert/bremove (LMU::XS GH#1)
  - Improve tests
  - Make List::MoreUtils::XS independent from List::MoreUtils
  - Improve Makefile.PL regarding some build artifacts
  - Update tests to latest List::MoreUtils::XS
  - Recommend List::MoreUtils::XS 0.423
- BR:/R: LMU::XS ≥ 0.423 as there is no longer a bootstrapping issue

---

diff --git a/perl-List-MoreUtils.spec b/perl-List-MoreUtils.spec
index 5fdb099..acdcb1d 100644
--- a/perl-List-MoreUtils.spec
+++ b/perl-List-MoreUtils.spec
@@ -1,6 +1,6 @@
 Name:  perl-List-MoreUtils
-Version:   0.419
-Release:   3%{?dist}
+Version:   0.423
+Release:   1%{?dist}
 Summary:   Provide the stuff missing in List::Util
 License:   (GPL+ or Artistic) and ASL 2.0
 URL:   http://search.cpan.org/dist/List-MoreUtils/
@@ -10,20 +10,23 @@ BuildArch:  noarch
 BuildRequires: coreutils
 BuildRequires: findutils
 BuildRequires: make
-BuildRequires: perl-interpreter >= 4:5.16.0
 BuildRequires: perl-generators
+BuildRequires: perl-interpreter
 BuildRequires: perl(Config)
 BuildRequires: perl(ExtUtils::MakeMaker) >= 6.75
 BuildRequires: perl(lib)
 # Module Runtime
 BuildRequires: perl(Carp)
 BuildRequires: perl(Exporter::Tiny) >= 0.038
+BuildRequires: perl(List::MoreUtils::XS) >= 0.423
 BuildRequires: perl(strict)
 BuildRequires: perl(vars)
 BuildRequires: perl(warnings)
 # Test Suite
 BuildRequires: perl(base)
 BuildRequires: perl(Exporter)
+BuildRequires: perl(List::Util)
+BuildRequires: perl(Math::Trig)
 BuildRequires: perl(overload)
 BuildRequires: perl(Scalar::Util)
 BuildRequires: perl(Storable)
@@ -37,7 +40,7 @@ BuildRequires:perl(Test::LeakTrace)
 # Runtime
 Requires:  perl(:MODULE_COMPAT_%(eval "`perl -V:version`"; echo $version))
 Requires:  perl(Carp)
-Recommends:perl(List::MoreUtils::XS) >= 0.418
+Requires:  perl(List::MoreUtils::XS) >= 0.423
 
 %description
 List::MoreUtils provides some trivial but commonly needed functionality
@@ -70,6 +73,22 @@ make test
 %{_mandir}/man3/List::MoreUtils::PP.3*
 
 %changelog
+* Tue Aug 22 2017 Paul Howarth  - 0.423-1
+- Update to 0.423
+  - Sync version with List::MoreUtils::XS
+  - Add some new functions: qsort (XS only), binsert, bremove, listcmp,
+arrayify (CPAN RT#17230), samples (CPAN RT#77562), minmaxstr
+(CPAN RT#106401), lower_bound, upper_bound, equal_range, frequencies
+occurrences, mode (CPAN RT#91991), zip6 (CPAN RT#42921), reduce_0,
+reduce_1, reduce_u
+  - Add examples for binsert/bremove (LMU::XS GH#1)
+  - Improve tests
+  - Make List::MoreUtils::XS independent from List::MoreUtils
+  - Improve Makefile.PL regarding some build artifacts
+  - Update tests to latest List::MoreUtils::XS
+  - Recommend List::MoreUtils::XS 0.423
+- BR:/R: LMU::XS ≥ 0.423 as there is no longer a bootstrapping issue
+
 * Thu Jul 27 2017 Fedora Release Engineering  - 
0.419-3
 - Rebuilt for https://fedoraproject.org/wiki/Fedora_27_Mass_Rebuild
 
diff --git a/sources b/sources
index 9771b9b..04b0787 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-SHA512 (List-MoreUtils-0.419.tar.gz) = 
d13beb5031d1559c2ec4cb93826e86f0f314c4f10c4fdcac6910de0cb039199599911838eadd499e81cb41025aae2a52d69a259653a9637679a1705c7adcd37a
+SHA512 (List-MoreUtils-0.423.tar.gz) = 
f88e683ce50c4e0e0df9731af9ace3be7ddfd7477292ec14ae4d013d99408c87073f3abdd893e8a90638db936da2d58d6fa588e55d89b8087b2005909154d686



https://src.fedoraproject.org/rpms/perl-List-MoreUtils/c/75fd7441074b6dafce1cd8b952f3b75db1425579?branch=master
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

[Bug 1484066] New: $daemon_group in /etc/amavisd/amavisd.conf doesn' t set the daemon group

[bugzilla]

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

Bug ID: 1484066
   Summary: $daemon_group in /etc/amavisd/amavisd.conf doesn't set
the daemon group
   Product: Fedora
   Version: rawhide
 Component: amavisd-new
  Severity: low
  Priority: low
  Assignee: j.orti.alca...@gmail.com
  Reporter: dh...@redhat.com
QA Contact: extras...@fedoraproject.org
CC: j.orti.alca...@gmail.com,
perl-devel@lists.fedoraproject.org, st...@silug.org,
vanmeeuwen+fed...@kolabsys.com



Description of problem:
$daemon_group in /etc/amavisd/amavisd.conf doesn't set the daemon group

Version-Release number of selected component (if applicable):


How reproducible:
Always

Steps to Reproduce:
1. Change $daemon_group to virusgroup
2. Restart the daemon
3.

Actual results:
The process is still using the amavis group

Expected results:
The process should be using virusgroup group

Additional info:
If I change it in the systemd unit file, it works as expected.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

pghmcfc uploaded DateTime-1.44.tar.gz for perl-DateTime

[notifications]

a256efc26ad1f2859f3371b70e5edd0d962d2c19c54b746178e3945b1dc665621d09b7ac6be279c7e92b8aa91763c5df2d8ccbca1832ba69ac810feb8533ca71
  DateTime-1.44.tar.gz

https://src.fedoraproject.org/lookaside/pkgs/perl-DateTime/DateTime-1.44.tar.gz/sha512/a256efc26ad1f2859f3371b70e5edd0d962d2c19c54b746178e3945b1dc665621d09b7ac6be279c7e92b8aa91763c5df2d8ccbca1832ba69ac810feb8533ca71/DateTime-1.44.tar.gz
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

Re: COPR strategy

[Kamil Dudka]

On Tuesday, August 22, 2017 5:03:06 PM CEST Michal Novotny wrote:
> On Tue, Aug 22, 2017 at 4:40 PM, Kamil Dudka  wrote:
> > On Tuesday, August 22, 2017 1:51:44 PM CEST Michal Novotny wrote:
> > > Hey Kamil,
> > > 
> > > On Tue, Aug 22, 2017 at 12:07 PM, Kamil Dudka  wrote:
> > > > On Tuesday, August 22, 2017 9:04:24 AM CEST Matthias Runge wrote:
> > > > > - the ability to directly upload srpms; that is, one can store spec
> > > > > 
> > > > >   files etc. on the local machine. I'm undecided, if integrating a
> > > > >   distgit on copr would solve any issues or would introduce more,
> > 
> > like
> > 
> > > > >   diverging specs.
> > > > 
> > > > Building packages from dist-git is already possible via 'copr
> > > > buildfedpkg'.
> > > > The problem is that the last time I tried, it only worked for the
> > 
> > official
> > 
> > > > Fedora branches.  All attempts to build something from a
> > 
> > private-kdudka-*
> > 
> > > > branch failed with the well known "Could not find the dist from branch
> > > > name"
> > > > failure of fedpkg.  Unless arbitrary dist-git branches are suported,
> > 
> > the
> > 
> > > > 'copr buildfedpkg' command is pretty useless.
> > > 
> > > Actually, we already support arbitrary dist-git branches in COPR
> > 
> > Sounds good.  I wanted to check this:
> > 
> > % copr buildfedpkg --branch private-kdudka-libcurl-nss --clone-url
> > https://src.fedoraproject.org/rpms/curl.git kdudka/tmp
> > 
> > Build was added to tmp:
> >   https://copr.fedorainfracloud.org/coprs/build/592748/
> > 
> > Created builds: 592748
> > Watching build(s): (this may be safely interrupted)
> > 
> >   16:20:56 Build 592748: importing
> > 
> > But the task hangs indefinitely in the "importing" state.  You can see
> > that
> > http://copr-dist-git.fedorainfracloud.org/per-task-logs/592748.log still
> > grows with obvious periodicity.
> > 
> > Am I doing anything wrong?
> 
> Uh, not really. fedpkg was not installed on the production machine thus the
> import was failing.
> Note that this is still slightly under development but it should definitely
> work as a feature in
> any case.

OK.  Thank you for working on it!  I am looking forward to use it one day...

> > Kamil
> > 
> > > and we also aim
> > > to be able to build from any dist-git (at least being based on
> > > https://src.fedoraproject.org/rpms/dist-git).
> > > 
> > > Currently we also support building from copr-dist-git in addition to
> > 
> > Fedora
> > 
> > > DistGit but
> > > we need to reflect that in our API and in copr-cli interface by renaming
> > > the subcommand.
> > > (or providing the new generic one while keeping the old one for some
> > 
> > time)
> > 
> > > Then there is actually also the new rpkg client (based on pyrpkg lib):
> > > https://src.fedoraproject.org/rpms/rpkg-client
> > > that you can use for launching COPR builds from any dist-git repo being
> > > locally checked out.
> > > 
> > > > Kamil
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: COPR strategy

[Michal Novotny]

On Tue, Aug 22, 2017 at 4:40 PM, Kamil Dudka  wrote:

> On Tuesday, August 22, 2017 1:51:44 PM CEST Michal Novotny wrote:
> > Hey Kamil,
> >
> > On Tue, Aug 22, 2017 at 12:07 PM, Kamil Dudka  wrote:
> > > On Tuesday, August 22, 2017 9:04:24 AM CEST Matthias Runge wrote:
> > > > - the ability to directly upload srpms; that is, one can store spec
> > > >
> > > >   files etc. on the local machine. I'm undecided, if integrating a
> > > >   distgit on copr would solve any issues or would introduce more,
> like
> > > >   diverging specs.
> > >
> > > Building packages from dist-git is already possible via 'copr
> > > buildfedpkg'.
> > > The problem is that the last time I tried, it only worked for the
> official
> > > Fedora branches.  All attempts to build something from a
> private-kdudka-*
> > > branch failed with the well known "Could not find the dist from branch
> > > name"
> > > failure of fedpkg.  Unless arbitrary dist-git branches are suported,
> the
> > > 'copr buildfedpkg' command is pretty useless.
> >
> > Actually, we already support arbitrary dist-git branches in COPR
>
> Sounds good.  I wanted to check this:
>
> % copr buildfedpkg --branch private-kdudka-libcurl-nss --clone-url
> https://src.fedoraproject.org/rpms/curl.git kdudka/tmp
> Build was added to tmp:
>   https://copr.fedorainfracloud.org/coprs/build/592748/
> Created builds: 592748
> Watching build(s): (this may be safely interrupted)
>   16:20:56 Build 592748: importing
>
> But the task hangs indefinitely in the "importing" state.  You can see that
> http://copr-dist-git.fedorainfracloud.org/per-task-logs/592748.log still
> grows with obvious periodicity.
>
> Am I doing anything wrong?
>


Uh, not really. fedpkg was not installed on the production machine thus the
import was failing.
Note that this is still slightly under development but it should definitely
work as a feature in
any case.



>
> Kamil
>
> > and we also aim
> > to be able to build from any dist-git (at least being based on
> > https://src.fedoraproject.org/rpms/dist-git).
> >
> > Currently we also support building from copr-dist-git in addition to
> Fedora
> > DistGit but
> > we need to reflect that in our API and in copr-cli interface by renaming
> > the subcommand.
> > (or providing the new generic one while keeping the old one for some
> time)
> >
> > Then there is actually also the new rpkg client (based on pyrpkg lib):
> > https://src.fedoraproject.org/rpms/rpkg-client
> > that you can use for launching COPR builds from any dist-git repo being
> > locally checked out.
> >
> > > Kamil
> > > ___
> > > devel mailing list -- devel@lists.fedoraproject.org
> > > To unsubscribe send an email to devel-le...@lists.fedoraproject.org
>
>
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

pghmcfc uploaded List-MoreUtils-0.423.tar.gz for perl-List-MoreUtils

[notifications]

f88e683ce50c4e0e0df9731af9ace3be7ddfd7477292ec14ae4d013d99408c87073f3abdd893e8a90638db936da2d58d6fa588e55d89b8087b2005909154d686
  List-MoreUtils-0.423.tar.gz

https://src.fedoraproject.org/lookaside/pkgs/perl-List-MoreUtils/List-MoreUtils-0.423.tar.gz/sha512/f88e683ce50c4e0e0df9731af9ace3be7ddfd7477292ec14ae4d013d99408c87073f3abdd893e8a90638db936da2d58d6fa588e55d89b8087b2005909154d686/List-MoreUtils-0.423.tar.gz
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

Re: 'No More Alphas': wiki revision drafts

[Sudhir D]

On 08/22/2017 07:34 PM, Matthew Miller wrote:

On Tue, Aug 22, 2017 at 07:18:04PM +0530, Sudhir D wrote:

On a slightly different thought, if we run all existing Alpha
criteria tests in rawhide, we can then probably look at existing
Alpha blocker as Branch blocker.. i.e, we don't branch unless the
blockers are fixed and thereby keeping rawhide at Alpha quality all
the time. We might want to call 'Basic Release Criteria' as 'Basic
Branch Criteria'.

H. I guess this would avoid needing to fix problems on both the
branch and rawhide. But, sometimes the fix should be different (e.g.
backport or quick fix on branch, update to new version or other long
term solution on rawhide).



Such fix must then be tracked separately for branched version.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Modularity Working Group IRC Meeting Minutes (2017-08-22)

[Nils Philippsen]

===
==
#fedora-meeting-3: Meeting of the Modularity Working Group (once every
two weeks)
===
==


Meeting started by nils at 14:00:19 UTC.

Minutes: 
https://meetbot.fedoraproject.org/fedora-meeting-3/2017-08-22/modularity_wg.2017-08-22-14.00.html
Minutes (text): 
https://meetbot.fedoraproject.org/fedora-meeting-3/2017-08-22/modularity_wg.2017-08-22-14.00.txt
Log: 
https://meetbot.fedoraproject.org/fedora-meeting-3/2017-08-22/modularity_wg.2017-08-22-14.00.log.html


Meeting summary
---
* Roll Call  (nils, 14:00:31)

* Agenda  (nils, 14:02:58)

* Open Floor  (nils, 14:04:48)

Meeting ended at 14:39:07 UTC.




Action Items






Action Items, by person
---
* **UNASSIGNED**
  * (none)




People Present (lines said)
---
* langdon (41)
* asamalik (34)
* nils (21)
* zodbot (11)
* jkurik (8)
* karsten (7)
* geppetto (6)
* ttomecek (3)
* tflink (1)
* dgilmore (1)
* mikedep333 (0)




Generated by `MeetBot`_ 0.1.4

.. _`MeetBot`: http://wiki.debian.org/MeetBot
-- 
Nils Philippsen"Those who would give up Essential Liberty to
Software Engineer   purchase a little Temporary Safety, deserve neither
Red Hat Liberty nor Safety."  --  Benjamin Franklin, 1759
PGP fingerprint:C4A8 9474 5C4C ADE3 2B8F  656D 47D8 9B65 6951 3011
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: COPR strategy

[Kamil Dudka]

On Tuesday, August 22, 2017 1:51:44 PM CEST Michal Novotny wrote:
> Hey Kamil,
> 
> On Tue, Aug 22, 2017 at 12:07 PM, Kamil Dudka  wrote:
> > On Tuesday, August 22, 2017 9:04:24 AM CEST Matthias Runge wrote:
> > > - the ability to directly upload srpms; that is, one can store spec
> > > 
> > >   files etc. on the local machine. I'm undecided, if integrating a
> > >   distgit on copr would solve any issues or would introduce more, like
> > >   diverging specs.
> > 
> > Building packages from dist-git is already possible via 'copr
> > buildfedpkg'.
> > The problem is that the last time I tried, it only worked for the official
> > Fedora branches.  All attempts to build something from a private-kdudka-*
> > branch failed with the well known "Could not find the dist from branch
> > name"
> > failure of fedpkg.  Unless arbitrary dist-git branches are suported, the
> > 'copr buildfedpkg' command is pretty useless.
> 
> Actually, we already support arbitrary dist-git branches in COPR

Sounds good.  I wanted to check this:

% copr buildfedpkg --branch private-kdudka-libcurl-nss --clone-url 
https://src.fedoraproject.org/rpms/curl.git kdudka/tmp
Build was added to tmp:
  https://copr.fedorainfracloud.org/coprs/build/592748/
Created builds: 592748
Watching build(s): (this may be safely interrupted)
  16:20:56 Build 592748: importing

But the task hangs indefinitely in the "importing" state.  You can see that
http://copr-dist-git.fedorainfracloud.org/per-task-logs/592748.log still
grows with obvious periodicity.

Am I doing anything wrong?

Kamil

> and we also aim
> to be able to build from any dist-git (at least being based on
> https://src.fedoraproject.org/rpms/dist-git).
> 
> Currently we also support building from copr-dist-git in addition to Fedora
> DistGit but
> we need to reflect that in our API and in copr-cli interface by renaming
> the subcommand.
> (or providing the new generic one while keeping the old one for some time)
> 
> Then there is actually also the new rpkg client (based on pyrpkg lib):
> https://src.fedoraproject.org/rpms/rpkg-client
> that you can use for launching COPR builds from any dist-git repo being
> locally checked out.
> 
> > Kamil
> > ___
> > devel mailing list -- devel@lists.fedoraproject.org
> > To unsubscribe send an email to devel-le...@lists.fedoraproject.org

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: 'No More Alphas': wiki revision drafts

[Matthew Miller]

On Tue, Aug 22, 2017 at 07:18:04PM +0530, Sudhir D wrote:
> On a slightly different thought, if we run all existing Alpha
> criteria tests in rawhide, we can then probably look at existing
> Alpha blocker as Branch blocker.. i.e, we don't branch unless the
> blockers are fixed and thereby keeping rawhide at Alpha quality all
> the time. We might want to call 'Basic Release Criteria' as 'Basic
> Branch Criteria'.

H. I guess this would avoid needing to fix problems on both the
branch and rawhide. But, sometimes the fix should be different (e.g.
backport or quick fix on branch, update to new version or other long
term solution on rawhide).

-- 
Matthew Miller

Fedora Project Leader
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: [modularity] Guidelines & Process

[Owen Taylor]

Hi Langdon,

Thanks for all the work that went into the process and guidelines! 

My particular interest is in what I consider the simplest use case - taking an 
existing leaf-node application (desktop or otherwise), creating a module that 
only includes that application and is not meant for building on top of, and 
creating a container or flatpak out of the module. 

If we want to encourage maintainers of existing leaf-node applications do this 
- to move into the modularized world - then having to go through this process 
and also the container review process:

 https://fedoraproject.org/wiki/Container:Review_Process

Seems like a pretty large barrier and discouragement - and getting software 
into Fedora is already hard compared to the alternatives!

I'm wondering how we can streamline this case. Can we define some subset of 
modules that are simple enough that we can do all the checks that need to be 
done automatically? Does it make sense that in some cases we should skip the 
rpms/modules/containers structure in dist-git and just add module/container 
metadata along the RPM?

I'd love to discuss with people at Flock.

Thanks,
Owen

P.S. - I don't mean to discourage adoption of these guidelines for more complex 
cases, and as a way we can get started creating simpler modules. I'm just 
wondering how we can lighten the load on packagers.

- Original Message -
> The Modularity WG has proposed a set of guidelines[1] and a process[2] for
> adding modules to Fedora and we would love your feedback. Our general docs
> are on Pagure[3] if you need more background/further information.
> Please share your feedback here or directly on the wiki page(s). You can also
> file issues/PRs on pagure[4] if you have other comments/edits/etc.
> 
> thanks
> Langdon
> 
> [1]:
> https://fedoraproject.org/wiki/Module:Guidelines?rd=Fedora_Packaging_Guidelines_for_Modules
> [2]: https://fedoraproject.org/wiki/Module:Review_Process
> [3]: https://docs.pagure.org/modularity/
> [4]: https://pagure.io/modularity
> 
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: 'No More Alphas': wiki revision drafts

[Sudhir D]

On 08/03/2017 05:46 AM, Adam Williamson wrote:

* My proposal for 'what do we do about release criteria / validation'
is basically: the 'Fedora 27 Alpha Release Criteria' page gets renamed
'Basic Release Criteria' (note: not versioned, I don't think it should
be), and we document that *all* composes - not just Beta and Final
candidate composes, but also Rawhide and Branched nightlies - will be
automatically tested for (and release of them gated on) compliance with
them. Which is more or less what's proposed in the Change. All external
references to the 'Alpha' criteria get changed to 'Basic' (e.g. this is
what changed on the other criteria pages, and on the test matrix
template pages). Practically speaking, we currently have automated
testing for *most* of the existing Alpha criteria, but a few items
aren't covered. We can choose to move these to the Beta criteria, or
leave them on Basic and just accept that *actual* coverage doesn't
quite meet what we aspire to. I do *NOT* propose to have any kind of
blocker tracking bug for the Basic release criteria; it doesn't seem to
fit in the process, there is no Alpha release to block, and we can't
realistically block nightly composes on manual test results. So a
tracker bug wouldn't really have any reason to exist. In the case where
a violation of the Basic criteria makes it into composes despite the
automated testing, it should be marked as a Beta blocker.




On a slightly different thought, if we run all existing Alpha criteria 
tests in rawhide, we can then probably look at existing Alpha blocker as 
Branch blocker.. i.e, we don't branch unless the blockers are fixed and 
thereby keeping rawhide at Alpha quality all the time. We might want to 
call 'Basic Release Criteria' as 'Basic Branch Criteria'.


Regards,
Sudhir
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: f27 builds in COPR fail without logs

[Alexander Ploumistos]

On Tue, Aug 22, 2017 at 3:53 PM, Michal Novotny  wrote:
> Eventually, a new version should pop up here:
> https://bodhi.fedoraproject.org/updates/?packages=mock
>
> You can give it Karma when it appears so that it reaches Fedora repos a bit
> faster.

Oh, I had never given much thought to what happens to build tools like
mock during branching, I was sure they were automagically cloned from
the master branch.
Thanks again, I will be waiting for that update.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Outdated clamav database in Taskotron

[Kamil Paral]

>
> > > So maybe the ClamAV definitions should be treated similarly? In
> > > a separate package which gets updated on a regular interval to pull in
> > > the latest data?
> > >
> >
> > That would be the best solution here, yes. Could someone please file an
> RFE
> > against clamav?
> Done:
>
> https://bugzilla.redhat.com/show_bug.cgi?id=147



The clamav maintainer doesn't seem to have the time needed to provide a
regularly updated clamav-data package. So today I tried to update the
rpmgrill task with running freshclam before running rpmgrill, using
clamav.upjs.sk mirror. That mirror is very fast when I try it (as opposed
to the default mirror). However, when running it in our infra, I hit
"WARNING: Mirror 158.197.16.70 is not synchronized." errors with
clamav.upjs.sk mirror [1] and extremely long times with the default mirror
(my patience ran out after 5 minutes).

So, sorry, I give up. Unless we can convince someone to maintain a
regularly updated clamav-data package, or provide a reliable and fast
clamav mirror (that is willing to be hit very often from our infra), I'm
afraid we can't offer an updated clamav database for our tests.

[1] https://paste.fedoraproject.org/paste/hqewIGsDK8XFn9O6B0bPPQ/raw
___
qa-devel mailing list -- qa-devel@lists.fedoraproject.org
To unsubscribe send an email to qa-devel-le...@lists.fedoraproject.org

mock or dnf or fedora-review tries to install a binary of a package it is test-building

[Richard W.M. Jones]

I don't know what component to file this bug under ...

When running ‘fedora-review -b 1477363’, it fails to test build the
package in mock.  The errors in root.log are peculiar:

> DEBUG util.py:450:  Package ocaml-4.04.2-4.fc27.x86_64 is already installed, 
> skipping.
> DEBUG util.py:450:  Error: 
> DEBUG util.py:450:   Problem 1: cannot install both 
> ocaml-runtime-4.05.0-2.fc27.x86_64 and ocaml-runtime-4.04.2-4.fc27.x86_64
> DEBUG util.py:450:- package ocaml-4.05.0-2.fc27.x86_64 requires 
> ocaml-runtime = 4.05.0-2.fc27, but none of the providers can be installed

Installing the higher version would be correct here, but ...

> DEBUG util.py:450:- package ocaml-cmdliner-1.0.2-1.fc27.x86_64 requires 
> ocaml(Array) = 83626447aa49c1fc006c752026de61fb, but none of the providers 
> can be installed

... this dependency is wrong.  But on the other hand mock is supposed
to be *building* ocaml-cmdliner at this point, so there shouldn't even
be a binary package of this.

> DEBUG util.py:450:- cannot install the best candidate for the job
> DEBUG util.py:450:- problem with installed package 
> ocaml-cmdliner-1.0.2-1.fc27.x86_64
> DEBUG util.py:450:   Problem 2: cannot install both 
> ocaml-runtime-4.05.0-2.fc27.x86_64 and ocaml-runtime-4.04.2-4.fc27.x86_64
> DEBUG util.py:450:- package ocaml-cmdliner-1.0.2-1.fc27.x86_64 requires 
> ocaml(Array) = 83626447aa49c1fc006c752026de61fb, but none of the providers 
> can be installed
> DEBUG util.py:450:- package ocaml-ocamlbuild-0.11.0-9.fc27.x86_64 
> requires ocaml(Pervasives) = 07ea9e20ae94d62c35cfecbe7d66d3ea, but none of 
> the providers can be installed

ocaml(Pervasives) = 07ea... is provided by
ocaml-runtime-4.05.0-2.fc27.x86_64

> DEBUG util.py:450:- package ocaml-cmdliner-devel-1.0.2-1.fc27.x86_64 
> requires ocaml-cmdliner = 1.0.2-1.fc27, but none of the providers can be 
> installed
> DEBUG util.py:450:- cannot install the best candidate for the job
> DEBUG util.py:450:- problem with installed package 
> ocaml-cmdliner-devel-1.0.2-1.fc27.x86_64

It seems as if a binary ocaml-cmdliner with incorrect dependencies is
appearing from somewhere ...

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
libguestfs lets you edit virtual machines.  Supports shell scripting,
bindings from many languages.  http://libguestfs.org
INFO buildroot.py:347:  Mock Version: 1.4.3
DEBUG util.py:109:  ensuring that dir exists: 
/var/lib/mock/fedora-rawhide-x86_64/root/dev/pts
DEBUG util.py:112:  creating dir: 
/var/lib/mock/fedora-rawhide-x86_64/root/dev/pts
DEBUG util.py:109:  ensuring that dir exists: 
/var/lib/mock/fedora-rawhide-x86_64/root/dev/shm
DEBUG util.py:112:  creating dir: 
/var/lib/mock/fedora-rawhide-x86_64/root/dev/shm
DEBUG buildroot.py:478:  kernel version == 4.13.0-0.rc2.git3.1.fc27.x86_64
DEBUG util.py:122:  touching file: 
/var/lib/mock/fedora-rawhide-x86_64/root/etc/fstab
DEBUG util.py:122:  touching file: 
/var/lib/mock/fedora-rawhide-x86_64/root/etc/yum/yum.conf
DEBUG util.py:122:  touching file: 
/var/lib/mock/fedora-rawhide-x86_64/root/etc/dnf.conf
DEBUG util.py:122:  touching file: 
/var/lib/mock/fedora-rawhide-x86_64/root/var/log/yum.log
DEBUG util.py:109:  ensuring that dir exists: 
/var/lib/mock/fedora-rawhide-x86_64/root/var/cache/dnf/
DEBUG util.py:606:  child environment: None
DEBUG util.py:533:  Executing command: ['/bin/mount', '-n', '--bind', 
'/var/cache/mock/fedora-rawhide-x86_64/dnf_cache/', 
'/var/lib/mock/fedora-rawhide-x86_64/root/var/cache/dnf/'] with env {'TERM': 
'vt100', 'SHELL': '/bin/sh', 'HOME': '/builddir', 'HOSTNAME': 'mock', 'PATH': 
'/usr/bin:/bin:/usr/sbin:/sbin', 'LANG': 'en_GB.UTF-8'} and shell False
DEBUG util.py:588:  Child return code was: 0
DEBUG buildroot.py:142:  rootdir = /var/lib/mock/fedora-rawhide-x86_64/root
DEBUG buildroot.py:143:  resultdir = 
/var/tmp/review/1477363-ocaml-cmdliner/results
DEBUG util.py:109:  ensuring that dir exists: 
/var/lib/mock/fedora-rawhide-x86_64/root/etc/pki/mock
DEBUG util.py:109:  ensuring that dir exists: 
/var/lib/mock/fedora-rawhide-x86_64/root/etc/dnf
DEBUG util.py:606:  child environment: None
DEBUG util.py:533:  Executing command: ['/usr/bin/systemd-nspawn', '-q', '-M', 
'6025d007029749c092d720279e3dd81b', '-D', 
'/var/lib/mock/fedora-rawhide-x86_64/root', '-a', '--setenv=TERM=vt100', 
'--setenv=SHELL=/bin/bash', '--setenv=HOME=/builddir', 
'--setenv=HOSTNAME=mock', '--setenv=PATH=/usr/bin:/bin:/usr/sbin:/sbin', 
'--setenv=PROMPT_COMMAND=printf "\\033]0;\\007"', 
'--setenv=PS1= \\s-\\v\\$ ', '--setenv=LANG=en_GB.UTF-8', 
'/usr/sbin/usermod', '-u', '1000', 'mockbuild'] with env {'TERM': 'vt100', 
'SHELL': '/bin/bash', 'HOME': '/builddir', 'HOSTNAME': 'mock', 'PATH': 
'/usr/bin:/bin:/usr/sbin:/sbin', 'PROMPT_COMMAND': 'printf 
"\\033]0;\\007"', 'PS1': ' \\s-\\v\\$ ', 'LANG': 
'en_GB.UTF-8'} and shell False
DEBUG util.py:307:  Unsharing. 

ppisar pushed to perl-PDL-Graphics-PLplot (master). "Does not work with hardended Perl 5.26.0 (bug #1459590)"

[notifications]

From fffcf65337d85605142c8ad543537734fe64e196 Mon Sep 17 00:00:00 2001
From: Petr Písař 
Date: Aug 22 2017 13:00:18 +
Subject: Does not work with hardended Perl 5.26.0 (bug #1459590)


---

diff --git a/.gitignore b/.gitignore
deleted file mode 100644
index cfd7ef8..000
--- a/.gitignore
+++ /dev/null
@@ -1,7 +0,0 @@
-PDL-Graphics-PLplot-0.52.tar.gz
-/PDL-Graphics-PLplot-0.56.tar.gz
-/PDL-Graphics-PLplot-0.59.tar.gz
-/PDL-Graphics-PLplot-0.62.tar.gz
-/PDL-Graphics-PLplot-0.66.tar.gz
-/PDL-Graphics-PLplot-0.67.tar.gz
-/PDL-Graphics-PLplot-0.71.tar.gz
diff --git a/.rpmlint b/.rpmlint
deleted file mode 100644
index 4a51156..000
--- a/.rpmlint
+++ /dev/null
@@ -1,2 +0,0 @@
-from Config import *
-addFilter("spelling-error .* perlish");
diff --git a/PDL-Graphics-PLplot-0.67-hardening.patch 
b/PDL-Graphics-PLplot-0.67-hardening.patch
deleted file mode 100644
index 9460302..000
--- a/PDL-Graphics-PLplot-0.67-hardening.patch
+++ /dev/null
@@ -1,12 +0,0 @@
-diff -Naur PDL-Graphics-PLplot-0.67.orig/plplot.pd 
PDL-Graphics-PLplot-0.67/plplot.pd
 PDL-Graphics-PLplot-0.67.orig/plplot.pd2013-11-15 16:51:28.0 
+0100
-+++ PDL-Graphics-PLplot-0.67/plplot.pd 2014-07-13 12:48:48.757782297 +0200
-@@ -3944,7 +3944,7 @@
- croak ("labelfunc: must return one perl scalar");
- 
-   // Copy label into output string
--  snprintf( label_text, length, (char *)SvPV_nolen(ST(0)) );
-+  snprintf( label_text, length, "%s", (char *)SvPV_nolen(ST(0)) );
- 
-   PUTBACK;
-   FREETMPS;
diff --git a/dead.package b/dead.package
new file mode 100644
index 000..435bdc8
--- /dev/null
+++ b/dead.package
@@ -0,0 +1 @@
+Does not work with hardended Perl 5.26.0 (bug #1459590)
diff --git a/perl-PDL-Graphics-PLplot.spec b/perl-PDL-Graphics-PLplot.spec
deleted file mode 100644
index 2587eb8..000
--- a/perl-PDL-Graphics-PLplot.spec
+++ /dev/null
@@ -1,200 +0,0 @@
-%global pkgname PDL-Graphics-PLplot
-
-Name:   perl-PDL-Graphics-PLplot
-Version:0.71
-Release:10%{?dist}
-Summary:Object-oriented interface from perl/PDL to the PLPLOT plotting 
library
-License:GPL+ or Artistic
-URL:http://search.cpan.org/dist/PDL-Graphics-PLplot/
-Source0:
http://search.cpan.org/CPAN/authors/id/D/DH/DHUNT/%{pkgname}-%{version}.tar.gz
-# Work around to FTBFS triggered by -Werror=format-security
-Patch0: PDL-Graphics-PLplot-0.67-hardening.patch
-# Tests crash in plplot on 64-bit PowerPC, bug #1410774, CPAN RT#119740
-ExcludeArch:ppc64 ppc64le
-BuildRequires:  make
-BuildRequires:  perl-interpreter
-BuildRequires:  perl-devel
-BuildRequires:  perl-generators
-BuildRequires:  perl(Config)
-BuildRequires:  perl(Data::Dumper)
-BuildRequires:  perl(ExtUtils::MakeMaker) >= 6.76
-BuildRequires:  perl(File::Spec)
-BuildRequires:  perl(PDL::Core::Dev)
-BuildRequires:  plplot-devel
-# Run-time:
-BuildRequires:  perl(DynaLoader)
-BuildRequires:  perl(PDL::Core)
-BuildRequires:  perl(PDL::Exporter)
-BuildRequires:  perl(vars)
-# Tests:
-BuildRequires:  perl(constant)
-BuildRequires:  perl(Getopt::Long)
-BuildRequires:  perl(List::Util)
-BuildRequires:  perl(Math::Trig)
-BuildRequires:  perl(PDL)
-BuildRequires:  perl(PDL::Config)
-# PDL::IO::Pnm not used
-BuildRequires:  perl(PDL::NiceSlice)
-BuildRequires:  perl(POSIX)
-BuildRequires:  perl(Test::More)
-BuildRequires:  perl(Text::Wrap)
-BuildRequires:  perl(Time::HiRes)
-BuildRequires:  perl(Time::Local)
-Requires:   perl(:MODULE_COMPAT_%(eval "`perl -V:version`"; echo $version))
-
-%description
-This is the PDL interface to the PLplot graphics library. It is designed
-to be simple and light weight with a familiar 'perlish' Object Oriented
-interface.
-
-The interface consists of two levels.  A low level interface which maps
-closely to the PLplot C interface, and a high level, object-oriented
-interface which is easier to use.
-
-%prep
-%setup -qn %{pkgname}-%{version}
-%patch0 -p1
-
-%build
-perl Makefile.PL INSTALLDIRS=vendor NO_PACKLIST=1 OPTIMIZE="${RPM_OPT_FLAGS}"
-make %{?_smp_mflags}
-
-%install
-make pure_install PERL_INSTALL_ROOT=%{buildroot}
-%{_fixperms} %{buildroot}/*
-
-%check
-make test
-
-%files
-%doc Changes README
-%{perl_vendorarch}/PDL
-%{perl_vendorarch}/auto/PDL
-%{_mandir}/man3/*
-
-%changelog
-* Thu Aug 03 2017 Fedora Release Engineering  - 
0.71-10
-- Rebuilt for https://fedoraproject.org/wiki/Fedora_27_Binutils_Mass_Rebuild
-
-* Thu Jul 27 2017 Fedora Release Engineering  - 
0.71-9
-- Rebuilt for https://fedoraproject.org/wiki/Fedora_27_Mass_Rebuild
-
-* Fri Jun 23 2017 Tom Callaway  - 0.71-8
-- rebuild for new plplot 5.12.0
-
-* Wed Jun 07 2017 Jitka Plesnikova  - 0.71-7
-- Perl 5.26 rebuild
-
-* Fri May 05 2017 Petr Pisar  - 0.71-6
-- Build on s390x
-- Modernize spec file
-
-* Thu Feb 23 2017 Petr Pisar  - 0.71-5
-- Disable building for 64-bit 

[Bug 1459590] perl-PDL-Graphics-PLplot FTBFS with Perl 5.26.0

[bugzilla]

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



--- Comment #3 from Petr Pisar  ---
Retiring suffers from this server flaw
.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

ppisar pushed to perl-PDL-Graphics-PLplot (f27). "Does not work with hardended Perl 5.26.0 (bug #1459590)"

[notifications]

From fffcf65337d85605142c8ad543537734fe64e196 Mon Sep 17 00:00:00 2001
From: Petr Písař 
Date: Aug 22 2017 13:00:18 +
Subject: Does not work with hardended Perl 5.26.0 (bug #1459590)


---

diff --git a/.gitignore b/.gitignore
deleted file mode 100644
index cfd7ef8..000
--- a/.gitignore
+++ /dev/null
@@ -1,7 +0,0 @@
-PDL-Graphics-PLplot-0.52.tar.gz
-/PDL-Graphics-PLplot-0.56.tar.gz
-/PDL-Graphics-PLplot-0.59.tar.gz
-/PDL-Graphics-PLplot-0.62.tar.gz
-/PDL-Graphics-PLplot-0.66.tar.gz
-/PDL-Graphics-PLplot-0.67.tar.gz
-/PDL-Graphics-PLplot-0.71.tar.gz
diff --git a/.rpmlint b/.rpmlint
deleted file mode 100644
index 4a51156..000
--- a/.rpmlint
+++ /dev/null
@@ -1,2 +0,0 @@
-from Config import *
-addFilter("spelling-error .* perlish");
diff --git a/PDL-Graphics-PLplot-0.67-hardening.patch 
b/PDL-Graphics-PLplot-0.67-hardening.patch
deleted file mode 100644
index 9460302..000
--- a/PDL-Graphics-PLplot-0.67-hardening.patch
+++ /dev/null
@@ -1,12 +0,0 @@
-diff -Naur PDL-Graphics-PLplot-0.67.orig/plplot.pd 
PDL-Graphics-PLplot-0.67/plplot.pd
 PDL-Graphics-PLplot-0.67.orig/plplot.pd2013-11-15 16:51:28.0 
+0100
-+++ PDL-Graphics-PLplot-0.67/plplot.pd 2014-07-13 12:48:48.757782297 +0200
-@@ -3944,7 +3944,7 @@
- croak ("labelfunc: must return one perl scalar");
- 
-   // Copy label into output string
--  snprintf( label_text, length, (char *)SvPV_nolen(ST(0)) );
-+  snprintf( label_text, length, "%s", (char *)SvPV_nolen(ST(0)) );
- 
-   PUTBACK;
-   FREETMPS;
diff --git a/dead.package b/dead.package
new file mode 100644
index 000..435bdc8
--- /dev/null
+++ b/dead.package
@@ -0,0 +1 @@
+Does not work with hardended Perl 5.26.0 (bug #1459590)
diff --git a/perl-PDL-Graphics-PLplot.spec b/perl-PDL-Graphics-PLplot.spec
deleted file mode 100644
index 2587eb8..000
--- a/perl-PDL-Graphics-PLplot.spec
+++ /dev/null
@@ -1,200 +0,0 @@
-%global pkgname PDL-Graphics-PLplot
-
-Name:   perl-PDL-Graphics-PLplot
-Version:0.71
-Release:10%{?dist}
-Summary:Object-oriented interface from perl/PDL to the PLPLOT plotting 
library
-License:GPL+ or Artistic
-URL:http://search.cpan.org/dist/PDL-Graphics-PLplot/
-Source0:
http://search.cpan.org/CPAN/authors/id/D/DH/DHUNT/%{pkgname}-%{version}.tar.gz
-# Work around to FTBFS triggered by -Werror=format-security
-Patch0: PDL-Graphics-PLplot-0.67-hardening.patch
-# Tests crash in plplot on 64-bit PowerPC, bug #1410774, CPAN RT#119740
-ExcludeArch:ppc64 ppc64le
-BuildRequires:  make
-BuildRequires:  perl-interpreter
-BuildRequires:  perl-devel
-BuildRequires:  perl-generators
-BuildRequires:  perl(Config)
-BuildRequires:  perl(Data::Dumper)
-BuildRequires:  perl(ExtUtils::MakeMaker) >= 6.76
-BuildRequires:  perl(File::Spec)
-BuildRequires:  perl(PDL::Core::Dev)
-BuildRequires:  plplot-devel
-# Run-time:
-BuildRequires:  perl(DynaLoader)
-BuildRequires:  perl(PDL::Core)
-BuildRequires:  perl(PDL::Exporter)
-BuildRequires:  perl(vars)
-# Tests:
-BuildRequires:  perl(constant)
-BuildRequires:  perl(Getopt::Long)
-BuildRequires:  perl(List::Util)
-BuildRequires:  perl(Math::Trig)
-BuildRequires:  perl(PDL)
-BuildRequires:  perl(PDL::Config)
-# PDL::IO::Pnm not used
-BuildRequires:  perl(PDL::NiceSlice)
-BuildRequires:  perl(POSIX)
-BuildRequires:  perl(Test::More)
-BuildRequires:  perl(Text::Wrap)
-BuildRequires:  perl(Time::HiRes)
-BuildRequires:  perl(Time::Local)
-Requires:   perl(:MODULE_COMPAT_%(eval "`perl -V:version`"; echo $version))
-
-%description
-This is the PDL interface to the PLplot graphics library. It is designed
-to be simple and light weight with a familiar 'perlish' Object Oriented
-interface.
-
-The interface consists of two levels.  A low level interface which maps
-closely to the PLplot C interface, and a high level, object-oriented
-interface which is easier to use.
-
-%prep
-%setup -qn %{pkgname}-%{version}
-%patch0 -p1
-
-%build
-perl Makefile.PL INSTALLDIRS=vendor NO_PACKLIST=1 OPTIMIZE="${RPM_OPT_FLAGS}"
-make %{?_smp_mflags}
-
-%install
-make pure_install PERL_INSTALL_ROOT=%{buildroot}
-%{_fixperms} %{buildroot}/*
-
-%check
-make test
-
-%files
-%doc Changes README
-%{perl_vendorarch}/PDL
-%{perl_vendorarch}/auto/PDL
-%{_mandir}/man3/*
-
-%changelog
-* Thu Aug 03 2017 Fedora Release Engineering  - 
0.71-10
-- Rebuilt for https://fedoraproject.org/wiki/Fedora_27_Binutils_Mass_Rebuild
-
-* Thu Jul 27 2017 Fedora Release Engineering  - 
0.71-9
-- Rebuilt for https://fedoraproject.org/wiki/Fedora_27_Mass_Rebuild
-
-* Fri Jun 23 2017 Tom Callaway  - 0.71-8
-- rebuild for new plplot 5.12.0
-
-* Wed Jun 07 2017 Jitka Plesnikova  - 0.71-7
-- Perl 5.26 rebuild
-
-* Fri May 05 2017 Petr Pisar  - 0.71-6
-- Build on s390x
-- Modernize spec file
-
-* Thu Feb 23 2017 Petr Pisar  - 0.71-5
-- Disable building for 64-bit 

[Bug 1459590] perl-PDL-Graphics-PLplot FTBFS with Perl 5.26.0

[bugzilla]

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



--- Comment #2 from Petr Pisar  ---
There was help from upstream and I don't know where the problem is and how to
fix it. This package will be removed from Fedora distribution.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

Re: f27 builds in COPR fail without logs

[Michal Novotny]

Eventually, a new version should pop up here:
https://bodhi.fedoraproject.org/updates/?packages=mock

You can give it Karma when it appears so that it reaches Fedora repos a bit
faster.

On Tue, Aug 22, 2017 at 2:41 PM, Alexander Ploumistos <
alex.ploumis...@gmail.com> wrote:

> Thanks Michal. Is there someplace I should monitor to know when the
> f27 mock will be available?
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: New copr-frontend release

[Michal Novotny]

Hey Kevin,

On Tue, Aug 22, 2017 at 2:03 PM, Kevin Kofler 
wrote:

> Michal Novotny wrote:
> >   - Batch package rebuilding ("Rebuild all" button in Packages view) so
> > that you can rebuild all your packages in the new chroots.
>
> Unfortunately, this feature is less useful than I had expected, it does not
> work for uploaded SRPMs or SRPMs fetched from URLs. In that case, I would
> have expected it to just copy the dist-git contents from the build that is
> being rebuilt (even for the URL case, I would not expect it to try to
> refetch the URL, which may no longer be valid). Instead, I got an error
> message that it does not have any sources to fetch.
>

It actually works like you expect for uploaded SRPMs and URL SRPMs.
For both these build types, imported copr-dist-git sources are being used.
This will be a bug somewhere else. You can contact me personally or here
with the details.

I ended up passing the output SRPMs of the Copr builds as the SRPM URLs for
> new builds as a workaround.
>
> (I prefer the automatic forking option, but unfortunately, the F26
> branching
> happened before it was introduced, so it used the old model, where rawhide
> was renamed to f26 and the rawhide chroot started up empty. So I had to do
> rebuilds for Rawhide.)
>
> Kevin Kofler
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: f27 builds in COPR fail without logs

[Alexander Ploumistos]

Thanks Michal. Is there someplace I should monitor to know when the
f27 mock will be available?
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: autoconf-archive suddenly gone in EPEL 7

[Benjamin Kircher]

> On 22. Aug 2017, at 12:53, Vascom  wrote:
> 
> As you can see here 
> https://src.fedoraproject.org/rpms/autoconf-archive/commits/epel7
> autoconf-archive removed from EPEL7 because it must be included in main 
> CentOS repos.


Thanks for the pointer.

Unfortunately this new RHEL package is not yet in current Vagrant images 
(1707.01) nor available in copr making builds that depend on those Autoconf 
macros fail.

BK
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: New copr-frontend release

[Kevin Kofler]

Michal Novotny wrote:
>   - Batch package rebuilding ("Rebuild all" button in Packages view) so
> that you can rebuild all your packages in the new chroots.

Unfortunately, this feature is less useful than I had expected, it does not 
work for uploaded SRPMs or SRPMs fetched from URLs. In that case, I would 
have expected it to just copy the dist-git contents from the build that is 
being rebuilt (even for the URL case, I would not expect it to try to 
refetch the URL, which may no longer be valid). Instead, I got an error 
message that it does not have any sources to fetch.

I ended up passing the output SRPMs of the Copr builds as the SRPM URLs for 
new builds as a workaround.

(I prefer the automatic forking option, but unfortunately, the F26 branching 
happened before it was introduced, so it used the old model, where rawhide 
was renamed to f26 and the rawhide chroot started up empty. So I had to do 
rebuilds for Rawhide.)

Kevin Kofler
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: rdma -devel packages missing (?) on f27/armv7hl, builds failing

[Yanko Kaneti]

Ahem..

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

-Yanko
On Tue, 2017-08-22 at 13:55 +0200, Vít Ondruch wrote:
> 
> Dne 22.8.2017 v 13:45 Kaleb S. KEITHLEY napsal(a):
> > Also rdma-core hasn't been built for f28 yet!
> 
> It was build prior branching, wasn't it?
> 
> V.
> 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: rdma -devel packages missing (?) on f27/armv7hl, builds failing

[Vít Ondruch]

Dne 22.8.2017 v 13:45 Kaleb S. KEITHLEY napsal(a):
> Also rdma-core hasn't been built for f28 yet!

It was build prior branching, wasn't it?

V.


___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: COPR strategy

[Michal Novotny]

Hey Kamil,

On Tue, Aug 22, 2017 at 12:07 PM, Kamil Dudka  wrote:

> On Tuesday, August 22, 2017 9:04:24 AM CEST Matthias Runge wrote:
> > - the ability to directly upload srpms; that is, one can store spec
> >   files etc. on the local machine. I'm undecided, if integrating a
> >   distgit on copr would solve any issues or would introduce more, like
> >   diverging specs.
>
> Building packages from dist-git is already possible via 'copr buildfedpkg'.
> The problem is that the last time I tried, it only worked for the official
> Fedora branches.  All attempts to build something from a private-kdudka-*
> branch failed with the well known "Could not find the dist from branch
> name"
> failure of fedpkg.  Unless arbitrary dist-git branches are suported, the
> 'copr buildfedpkg' command is pretty useless.
>

Actually, we already support arbitrary dist-git branches in COPR and we
also aim
to be able to build from any dist-git (at least being based on
https://src.fedoraproject.org/rpms/dist-git).

Currently we also support building from copr-dist-git in addition to Fedora
DistGit but
we need to reflect that in our API and in copr-cli interface by renaming
the subcommand.
(or providing the new generic one while keeping the old one for some time)

Then there is actually also the new rpkg client (based on pyrpkg lib):
https://src.fedoraproject.org/rpms/rpkg-client
that you can use for launching COPR builds from any dist-git repo being
locally checked out.


>
> Kamil
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: rdma -devel packages missing (?) on f27/armv7hl, builds failing

[Kaleb S. KEITHLEY]

switching to rdma-core-devel also fails.

because according to 
https://koji.fedoraproject.org/koji/buildinfo?buildID=953605 there are 
no armv7hl rpms built.


Probably due to the
  # 32-bit arm is missing required arch-specific memory barriers,
  ExcludeArch: %{arm}
in its .spec file

Which seems odd considering we've had IB/RDMA on armv7hl thus far. But 
if that's really the case then the solution is clear.


Also rdma-core hasn't been built for f28 yet!




On 08/22/2017 07:12 AM, Vít Ondruch wrote:



Dne 22.8.2017 v 12:48 Peter Robinson napsal(a):

On Tue, Aug 22, 2017 at 11:36 AM, Kaleb S. KEITHLEY  wrote:

I've built glusterfs previously on F27 with these same Build-Requires. Same
package & same .spec build on F28 and F26.

While trying to build a new version for the last 24 hours I keep hitting
this:

...
DEBUG util.py:439:  No matching package to install: 'libibverbs-devel'
DEBUG util.py:439:  No matching package to install: 'librdmacm-devel >=
1.0.15'

For some reason the owner in f27 tag was switched to releng and then
has been blocked:

Sat Aug 19 03:43:40 2017 package list entry for librdmacm in
module-package-list updated by pkgdb
 owner.name: dledford -> releng
Sat Aug 19 06:20:14 2017 librdmacm-1.1.0-4.fc26 untagged from f27 by releng
Sat Aug 19 06:20:14 2017 librdmacm-1.1.0-6.fc27 untagged from f27 by releng
Sat Aug 19 06:20:31 2017 package list entry for librdmacm in f27
updated by releng
 blocked: False -> True

Sat Aug 19 06:20:17 2017 libibverbs-1.2.1-4.fc26 untagged from f27 by releng
Sat Aug 19 06:20:17 2017 libibverbs-1.2.1-6.fc27 untagged from f27 by releng
Sat Aug 19 06:20:31 2017 package list entry for libibverbs in f27
updated by releng
 blocked: False -> True

I'm not sure why that is because it wasn't blocked for f28 because
both of those packages look to be replaced by rdma-core looking at one
of the commit logs

https://src.fedoraproject.org/rpms/libibverbs/c/bd306d2c33fadaf21dafb1351730a0c59052aed1?branch=master

It looks like the maintainer or the person that retired those packages
hasn't added the proper retires/provides into the rdma-core* packages
to ensure the upgrade path is smooth.


See the other thread:

https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/WJHXQ3G6H7UMVERDCMUXBYDJTFABTGW3/

V.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org


___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: COPR strategy

[Michal Novotny]

Hello Mikolaj,

On Tue, Aug 22, 2017 at 11:29 AM, Mikolaj Izdebski 
wrote:

> On 08/22/2017 11:17 AM, Michal Novotny wrote:
> >> - it would be great, if there is a possibility to trigger rebuilds on
> >>   dependent packages, like rebuild required packages after ABI bump.
> >>
> >
> > Right, this would be a nice option. I could imagine this being
> implemented
> > as a configurable fedmsg listener that would launch rebuilds on certain
> > events
> > like bumps of certain packages, branching event, and possibly others.
>
> This is implemented by Koschei. Not enabled until at least Copr frontend
> completes RFR process. I can enable it in staging sooner, provided that
> Koschei can get Copr credentials for authenticating through its API.
>
>
This would be cool! I am looking forward to exploring this.


>
> --
> Mikolaj Izdebski
> Software Engineer, Red Hat
> IRC: mizdebsk
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: one concrete idea for fedora

[Sérgio Basto]

On Mon, 2017-08-21 at 19:41 -0700, stan wrote:
> On Mon, 21 Aug 2017 18:19:09 +0100
> Sérgio Basto  wrote:
> 
> > and How I create one boot.iso (or netinstall iso ) ? 
> 
> I haven't actually done this, and you will probably get better
> responses on the users or test lists, but here are some links that
> might help you.
> 
> https://fedoraproject.org/wiki/How_to_create_and_use_a_Live_CD
> 
> https://www.watters.ws/mediawiki/index.php/Build_a_custom_Fedora_inst
> all_CD
> 
> https://forums.fedoraforum.org/showthread.php?t=303200
> 
> http://everyday-tech.com/create-a-custom-centos-iso/
> 
> https://superuser.com/questions/699709/how-to-create-a-modified-fedor
> a-iso

if we add boot.iso to http://dl.fedoraproject.org/pub/alt/live-respins/
 
we near to have a stable release ... (boot.iso can have a later kernel
and more stable core packages ) 

Thanks
-- 
Sérgio M. B.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: f27 builds in COPR fail without logs

[Michal Novotny]

Hello Alexander,

you haven't missed anything. It is just that there hasn't been mock release
yet
with f27 configs added. It is in upstream already but not yet released. If
it is
not in Fedora until the end of the week, then we can probably temporarily
provide
our own substitute repo configs.

clime

On Tue, Aug 22, 2017 at 12:33 PM, Alexander Ploumistos <
alex.ploumis...@gmail.com> wrote:

> Hello,
>
> For the past hour or so, I've been trying to rebuild my copr packages
> for f27 and rawhide. While there were some hiccups with rawhide, e.g.
> not finding mirrors to download packages, after resubmitting them a
> couple of times, all builds were successful. On the other hand, f27
> builds fail as soon as the source rpm gets imported and there are no
> logs to give a clue as to what is happening.
>
> For example, take a look at this attempt:
> https://copr.fedorainfracloud.org/coprs/alexpl/scidavis/build/592629/
>
> There aren't many recent f27 builds listed in copr at the moment, but
> those that are listed, have also failed without any logs:
> https://copr.fedorainfracloud.org/coprs/g/dnsoarc/dnscap-pr/build/592604/
> https://copr.fedorainfracloud.org/coprs/g/dnsoarc/drool-pr/build/592607/
>
> Have I missed something?
>
> Regards
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: rdma -devel packages missing (?) on f27/armv7hl, builds failing

[Vít Ondruch]

Dne 22.8.2017 v 12:48 Peter Robinson napsal(a):
> On Tue, Aug 22, 2017 at 11:36 AM, Kaleb S. KEITHLEY  
> wrote:
>> I've built glusterfs previously on F27 with these same Build-Requires. Same
>> package & same .spec build on F28 and F26.
>>
>> While trying to build a new version for the last 24 hours I keep hitting
>> this:
>>
>> ...
>> DEBUG util.py:439:  No matching package to install: 'libibverbs-devel'
>> DEBUG util.py:439:  No matching package to install: 'librdmacm-devel >=
>> 1.0.15'
> For some reason the owner in f27 tag was switched to releng and then
> has been blocked:
>
> Sat Aug 19 03:43:40 2017 package list entry for librdmacm in
> module-package-list updated by pkgdb
> owner.name: dledford -> releng
> Sat Aug 19 06:20:14 2017 librdmacm-1.1.0-4.fc26 untagged from f27 by releng
> Sat Aug 19 06:20:14 2017 librdmacm-1.1.0-6.fc27 untagged from f27 by releng
> Sat Aug 19 06:20:31 2017 package list entry for librdmacm in f27
> updated by releng
> blocked: False -> True
>
> Sat Aug 19 06:20:17 2017 libibverbs-1.2.1-4.fc26 untagged from f27 by releng
> Sat Aug 19 06:20:17 2017 libibverbs-1.2.1-6.fc27 untagged from f27 by releng
> Sat Aug 19 06:20:31 2017 package list entry for libibverbs in f27
> updated by releng
> blocked: False -> True
>
> I'm not sure why that is because it wasn't blocked for f28 because
> both of those packages look to be replaced by rdma-core looking at one
> of the commit logs
>
> https://src.fedoraproject.org/rpms/libibverbs/c/bd306d2c33fadaf21dafb1351730a0c59052aed1?branch=master
>
> It looks like the maintainer or the person that retired those packages
> hasn't added the proper retires/provides into the rdma-core* packages
> to ensure the upgrade path is smooth.

See the other thread:

https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/WJHXQ3G6H7UMVERDCMUXBYDJTFABTGW3/

V.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: autoconf-archive suddenly gone in EPEL 7

[Vascom]

As you can see here
https://src.fedoraproject.org/rpms/autoconf-archive/commits/epel7
autoconf-archive removed from EPEL7 because it must be included in main
CentOS repos.

вт, 22 авг. 2017 г. в 13:43, Benjamin Kircher :

> Hi,
>
> please correct me if I am wrong or if this isn't the right list.
>
> One of my packages needs autoconf-archive.noarch for building on CentOS 7
> but the build fails because autoconf-archive is not available in EPEL 7
> anymore.
>
> yum search autoconf-archive
>
> reveals nothing. Have I missed something?
>
> BK
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: rdma -devel packages missing (?) on f27/armv7hl, builds failing

[Peter Robinson]

On Tue, Aug 22, 2017 at 11:36 AM, Kaleb S. KEITHLEY  wrote:
>
> I've built glusterfs previously on F27 with these same Build-Requires. Same
> package & same .spec build on F28 and F26.
>
> While trying to build a new version for the last 24 hours I keep hitting
> this:
>
> ...
> DEBUG util.py:439:  No matching package to install: 'libibverbs-devel'
> DEBUG util.py:439:  No matching package to install: 'librdmacm-devel >=
> 1.0.15'

For some reason the owner in f27 tag was switched to releng and then
has been blocked:

Sat Aug 19 03:43:40 2017 package list entry for librdmacm in
module-package-list updated by pkgdb
owner.name: dledford -> releng
Sat Aug 19 06:20:14 2017 librdmacm-1.1.0-4.fc26 untagged from f27 by releng
Sat Aug 19 06:20:14 2017 librdmacm-1.1.0-6.fc27 untagged from f27 by releng
Sat Aug 19 06:20:31 2017 package list entry for librdmacm in f27
updated by releng
blocked: False -> True

Sat Aug 19 06:20:17 2017 libibverbs-1.2.1-4.fc26 untagged from f27 by releng
Sat Aug 19 06:20:17 2017 libibverbs-1.2.1-6.fc27 untagged from f27 by releng
Sat Aug 19 06:20:31 2017 package list entry for libibverbs in f27
updated by releng
blocked: False -> True

I'm not sure why that is because it wasn't blocked for f28 because
both of those packages look to be replaced by rdma-core looking at one
of the commit logs

https://src.fedoraproject.org/rpms/libibverbs/c/bd306d2c33fadaf21dafb1351730a0c59052aed1?branch=master

It looks like the maintainer or the person that retired those packages
hasn't added the proper retires/provides into the rdma-core* packages
to ensure the upgrade path is smooth.

Peter
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

autoconf-archive suddenly gone in EPEL 7

[Benjamin Kircher]

Hi,

please correct me if I am wrong or if this isn't the right list.

One of my packages needs autoconf-archive.noarch for building on CentOS 7
but the build fails because autoconf-archive is not available in EPEL 7
anymore.

yum search autoconf-archive

reveals nothing. Have I missed something?

BK
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

rdma -devel packages missing (?) on f27/armv7hl, builds failing

[Kaleb S. KEITHLEY]

I've built glusterfs previously on F27 with these same Build-Requires. 
Same package & same .spec build on F28 and F26.


While trying to build a new version for the last 24 hours I keep hitting 
this:


...
DEBUG util.py:439:  No matching package to install: 'libibverbs-devel'
DEBUG util.py:439:  No matching package to install: 'librdmacm-devel >= 
1.0.15'

...

Thanks,

--

Kaleb
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

f27 builds in COPR fail without logs

[Alexander Ploumistos]

Hello,

For the past hour or so, I've been trying to rebuild my copr packages
for f27 and rawhide. While there were some hiccups with rawhide, e.g.
not finding mirrors to download packages, after resubmitting them a
couple of times, all builds were successful. On the other hand, f27
builds fail as soon as the source rpm gets imported and there are no
logs to give a clue as to what is happening.

For example, take a look at this attempt:
https://copr.fedorainfracloud.org/coprs/alexpl/scidavis/build/592629/

There aren't many recent f27 builds listed in copr at the moment, but
those that are listed, have also failed without any logs:
https://copr.fedorainfracloud.org/coprs/g/dnsoarc/dnscap-pr/build/592604/
https://copr.fedorainfracloud.org/coprs/g/dnsoarc/drool-pr/build/592607/

Have I missed something?

Regards
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: COPR strategy

[Kamil Dudka]

On Tuesday, August 22, 2017 9:04:24 AM CEST Matthias Runge wrote:
> - the ability to directly upload srpms; that is, one can store spec
>   files etc. on the local machine. I'm undecided, if integrating a
>   distgit on copr would solve any issues or would introduce more, like
>   diverging specs.

Building packages from dist-git is already possible via 'copr buildfedpkg'.  
The problem is that the last time I tried, it only worked for the official 
Fedora branches.  All attempts to build something from a private-kdudka-* 
branch failed with the well known "Could not find the dist from branch name" 
failure of fedpkg.  Unless arbitrary dist-git branches are suported, the
'copr buildfedpkg' command is pretty useless.

Kamil
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: retired packages in rawhide/f27

[Petr Pisar]

On 2017-08-22, Honggang LI  wrote:
> hi,
>
> https://bugzilla.redhat.com/show_bug.cgi?id=1404043#c41
> libibcm, libibumad, libibverbs, librdmacm and ibacm had been replaced by
> the new rdma-core package. Those five packages are sub-packages of the
> new rdma-core package.
>
> I had retired the f27 and rawhide branches of those five packages in
> last week. But the build...@fedoraproject.org keep sending messages to
> complain broken dependencies for those five packages.
>
The "fedgkg retire" tool is/was broken and could not perform a retirement
.

Koji reports for ibacm source package:

$ koji list-pkgs --show-blocked --package=ibacm
Package Tag Extra Arches Owner  
--- ---  ---
[...]
ibacm   f27  releng 
 [BLOCKED]
ibacm   f26-Alphahonli  
ibacm   f26-Beta honli  
ibacm   f28  releng 

It means the package was not removed from Rawhide (f28) repositories.

If rerunning "fedpkg retire" does not help, you should file a ticket to
 or
.

-- Petr
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: COPR strategy

[Mikolaj Izdebski]

On 08/22/2017 11:17 AM, Michal Novotny wrote:
>> - it would be great, if there is a possibility to trigger rebuilds on
>>   dependent packages, like rebuild required packages after ABI bump.
>>
> 
> Right, this would be a nice option. I could imagine this being implemented
> as a configurable fedmsg listener that would launch rebuilds on certain
> events
> like bumps of certain packages, branching event, and possibly others.

This is implemented by Koschei. Not enabled until at least Copr frontend
completes RFR process. I can enable it in staging sooner, provided that
Koschei can get Copr credentials for authenticating through its API.


-- 
Mikolaj Izdebski
Software Engineer, Red Hat
IRC: mizdebsk
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

[Bug 1481324] devel subpackage: dependencies correction

[bugzilla]

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



--- Comment #23 from Tomasz Kłoczko  ---
Thank you :)

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

Re: Nonresponsive maintainer: attempting to contact kanarip

[James Hogarth]

On 27 June 2017 at 12:40, Vít Ondruch  wrote:

>
>
> Dne 27.6.2017 v 10:41 Jeroen van Meeuwen (Kolab Systems) napsal(a):
> > On Fri, 2017-06-23 at 11:39 +0100, James Hogarth wrote:
> >> Hi,
> >>
> >> Has anyone heard from kanarip or able to contact him?
> >>
> > Most people do hear from kanarip at undetermined intervals -- and my
> > @fedoraproject.org address works just fine -- I have no messages from
> > you.
> >
> > I'm also on IRC, where people occasionally contact me, albeit it be
> > about phabricator/arcanist for QA.
> >
> >> For ruby maintainers please note that this has a significant impact
> >> on you, if you want to keep track of this, as he owns puppet,
> >> rubygems and ruby ...
> >>
> > To be honest, ruby and a plethora of related packages are maintained by
> > Vit Ondruch and members of the Ruby SIG, much more so then they are
> > maintained by "the owner".
>
> But honestly, I'd be glad if you reconsidered being POC of packages you
> don't maintain. It would help to avoid this annual "non-responsive
> kanarip" emails.
>
>
>
>
Hmm okay it's been a couple of months now and the facter bug that lead
me to this is still unaddressed...

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

It remains at 2.4.3 in all branches whilst the current is 3.8.0

Unless you respond with a specific reason that this is being ignored by
August 31st I'll be updating this in the first week of September.

I urge you to listen to your colleagues in the Ruby SIG and change the POC
so that bug reports will go where they are going to be reviewed and so that
key packages like this get updated.

I'm genuinely surprised the very old facter hasn't hit the puppet or
similar guys before now.

James
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: [modularity] Guidelines & Process

[Petr Pisar]

On 2017-08-21, Langdon White  wrote:
> [2]: https://fedoraproject.org/wiki/Module:Review_Process

I don't understand purpose of this paragraph:

> As a Contributor, you should only be creating modules out of
> pre-existing software in the Fedora RPM repositories which adheres to
> the Package Naming Guidelines and Packaging Guidelines. Make note that
> the only software allowed in official Fedora Modules must be sourced
> from Fedora official RPMs. The Module Build Service will reject
> attempts to build from sources not provided by Fedora's dist-git.

This wording accepts modules that refer to non Fedora RPM components
(i.e. different git repositories than Fedora's dist-git). It
only notes it will be impossible to build such module in Koji.

Is it on purpose to allow people to host modulemd files in Fedora's
dist-git without building modules in Fedora infrastracture and instead
building them somewhere else?

If not, then a simple fix is s/you should only/you must only/.

-- Petr
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: COPR strategy

[Michal Novotny]

Hello Matthias,

On Tue, Aug 22, 2017 at 9:04 AM, Matthias Runge 
wrote:

> On Tue, Aug 22, 2017 at 05:17:56AM +0200, Michal Novotny wrote:
> > Hello,
> >
> > we will have soon a planning meeting that should determine a more
> long-term
> > strategy and bring us to a team agreement on what COPR currently is and
> > what it should be in half a year or so.
> >
> > I would like to kindly ask for some input here on the devel list to find
> > out what the actual expectations of COPR are and if there are any ideas
> > about what could COPR bring to the game.
>
> So, as a starter, what I really like about copr is:
>
> - it is actually a incubator, a tool to get packages or collections of
>   packages built. One can easily experiment without actually disturbing
>   other users. Copr lowers the entry barrier for new pacakgers.
>
> - the ability to directly upload srpms; that is, one can store spec
>   files etc. on the local machine. I'm undecided, if integrating a
>   distgit on copr would solve any issues or would introduce more, like
>   diverging specs.
>
> - the ability to include external repositories, like the one from CentOS
>   project.
>
>
Thanks! Good to hear what features are appreciated.



> What I would like to see:
>
> - maybe a easy possibility to build packages triggered by upstream
>   source changes. This is comparable to delorean[1]. I'm not sure if it
>   needs to be re-implemented.
>

We actually have this possibility implemented through SCM-1 and SCM-2
source types and webhook mechanism.


> - prioritization of manually uploaded tasks vs. automatic builds. If
>   that really lowers the waiting time for builds it to be discussed.
>   Maybe adding a "bulk" flag to tag builds as: build it, when a builder
>   is available, but it's not a priority. Send a message once the build
>   is done.
>

We have added --background tag which is very similar to --bulk tag you
are suggesting. It's a user option (choice) to tag a build like this if he
or she
wants to.


>
> - it would be great, if there is a possibility to trigger rebuilds on
>   dependent packages, like rebuild required packages after ABI bump.
>

Right, this would be a nice option. I could imagine this being implemented
as a configurable fedmsg listener that would launch rebuilds on certain
events
like bumps of certain packages, branching event, and possibly others.


>
>
> Thanks,
> Matthias
>
> [1] https://www.rdoproject.org/what/dlrn/
> --
> Matthias Runge 
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

ppisar pushed to perl (master). "Formalize profile descriptions"

[notifications]

From f2f23e0d98951fa5ad1b20927ba8de0f4e567116 Mon Sep 17 00:00:00 2001
From: Petr Písař 
Date: Aug 22 2017 08:56:40 +
Subject: Formalize profile descriptions


---

diff --git a/perl.yaml b/perl.yaml
index f83059a..d80b274 100644
--- a/perl.yaml
+++ b/perl.yaml
@@ -26,12 +26,12 @@ data:
 documentation: https://github.com/modularity-modules/perl
 tracker: https://github.com/modularity-modules/perl/issues
 profiles:
-# Interpreter and all Perl modules bundled within upstream Perl
 default:
+description: Interpreter and all Perl modules bundled within 
upstream Perl.
 rpms:
 - perl
-# Only the interpreter as standalone executable
 minimal:
+description: Only the interpreter as a standalone executable.
 rpms:
 - perl-interpreter
 api:



https://src.fedoraproject.org/modules/perl/c/f2f23e0d98951fa5ad1b20927ba8de0f4e567116?branch=master
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

[Bug 1481324] devel subpackage: dependencies correction

[bugzilla]

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

Petr Pisar  changed:

   What|Removed |Added

 Status|ASSIGNED|CLOSED
   Fixed In Version||perl-5.26.0-399.fc27
 Resolution|--- |NEXTRELEASE
Last Closed||2017-08-22 04:53:21



--- Comment #22 from Petr Pisar  ---
There was one upstream's answer that use the the values for linking XS modules
is wrong. Therefore I'm removing the dependencies now.

Thank you for this discussion. It makes Fedora's Perl better.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

ppisar pushed to perl-Module-CoreList (f25). "5.20170821 bump"

[notifications]

From 27cc5ebd69a4b9b6acdf47f4816479d830bd2cce Mon Sep 17 00:00:00 2001
From: Petr Písař 
Date: Aug 22 2017 08:22:51 +
Subject: 5.20170821 bump


---

diff --git a/.gitignore b/.gitignore
index b747c7b..c6418c5 100644
--- a/.gitignore
+++ b/.gitignore
@@ -42,3 +42,4 @@ Module-CoreList-2.13.tar.gz
 /Module-CoreList-5.20170621.tar.gz
 /Module-CoreList-5.20170715.tar.gz
 /Module-CoreList-5.20170720.tar.gz
+/Module-CoreList-5.20170821.tar.gz
diff --git a/perl-Module-CoreList.spec b/perl-Module-CoreList.spec
index 9f39e8e..a8df9e9 100644
--- a/perl-Module-CoreList.spec
+++ b/perl-Module-CoreList.spec
@@ -1,7 +1,7 @@
 Name:   perl-Module-CoreList
 # Epoch to compete with perl.spec
 Epoch:  1
-Version:5.20170720
+Version:5.20170821
 Release:1%{?dist}
 Summary:What modules are shipped with versions of perl
 License:GPL+ or Artistic
@@ -79,6 +79,9 @@ make test
 %{_mandir}/man1/corelist.*
 
 %changelog
+* Tue Aug 22 2017 Petr Pisar  - 1:5.20170821-1
+- 5.20170821 bump
+
 * Fri Jul 21 2017 Petr Pisar  - 1:5.20170720-1
 - 5.20170720 bump
 
diff --git a/sources b/sources
index 01da145..2b92327 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-SHA512 (Module-CoreList-5.20170720.tar.gz) = 
38b2b3287d8495ed7c64295ec92dc2e814f00f10644f4ee5d97e19fb41fc50f6024aadccf3cdeb752fdf429ba127bdd93db3dddccaffae32996efe1768768847
+SHA512 (Module-CoreList-5.20170821.tar.gz) = 
e5b1eb3bee5cc7d50f3bf21699c840c7b1fbea283affac5c79c8c31167b226d7fa76e3b885810e427ea976633ec0c223320f2b57e9a1bcd1fdc6d8256d6a551f



https://src.fedoraproject.org/rpms/perl-Module-CoreList/c/27cc5ebd69a4b9b6acdf47f4816479d830bd2cce?branch=f25
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

ppisar pushed to perl-Module-CoreList (f26). "5.20170821 bump"

[notifications]

From 30ffbc5d7c22e3d68f8cfd590500858210d4d8b3 Mon Sep 17 00:00:00 2001
From: Petr Písař 
Date: Aug 22 2017 08:22:10 +
Subject: 5.20170821 bump


---

diff --git a/.gitignore b/.gitignore
index b747c7b..c6418c5 100644
--- a/.gitignore
+++ b/.gitignore
@@ -42,3 +42,4 @@ Module-CoreList-2.13.tar.gz
 /Module-CoreList-5.20170621.tar.gz
 /Module-CoreList-5.20170715.tar.gz
 /Module-CoreList-5.20170720.tar.gz
+/Module-CoreList-5.20170821.tar.gz
diff --git a/perl-Module-CoreList.spec b/perl-Module-CoreList.spec
index a2f22de..288d272 100644
--- a/perl-Module-CoreList.spec
+++ b/perl-Module-CoreList.spec
@@ -1,7 +1,7 @@
 Name:   perl-Module-CoreList
 # Epoch to compete with perl.spec
 Epoch:  1
-Version:5.20170720
+Version:5.20170821
 Release:1%{?dist}
 Summary:What modules are shipped with versions of perl
 License:GPL+ or Artistic
@@ -79,6 +79,9 @@ make test
 %{_mandir}/man1/corelist.*
 
 %changelog
+* Tue Aug 22 2017 Petr Pisar  - 1:5.20170821-1
+- 5.20170821 bump
+
 * Fri Jul 21 2017 Petr Pisar  - 1:5.20170720-1
 - 5.20170720 bump
 
diff --git a/sources b/sources
index 01da145..2b92327 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-SHA512 (Module-CoreList-5.20170720.tar.gz) = 
38b2b3287d8495ed7c64295ec92dc2e814f00f10644f4ee5d97e19fb41fc50f6024aadccf3cdeb752fdf429ba127bdd93db3dddccaffae32996efe1768768847
+SHA512 (Module-CoreList-5.20170821.tar.gz) = 
e5b1eb3bee5cc7d50f3bf21699c840c7b1fbea283affac5c79c8c31167b226d7fa76e3b885810e427ea976633ec0c223320f2b57e9a1bcd1fdc6d8256d6a551f



https://src.fedoraproject.org/rpms/perl-Module-CoreList/c/30ffbc5d7c22e3d68f8cfd590500858210d4d8b3?branch=f26
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

ppisar pushed to perl-Module-CoreList (f27). "5.20170821 bump"

[notifications]

From 7e696792bbf5369c045e1d5af383bd830679c75e Mon Sep 17 00:00:00 2001
From: Petr Písař 
Date: Aug 22 2017 08:19:19 +
Subject: 5.20170821 bump


---

diff --git a/.gitignore b/.gitignore
index b747c7b..c6418c5 100644
--- a/.gitignore
+++ b/.gitignore
@@ -42,3 +42,4 @@ Module-CoreList-2.13.tar.gz
 /Module-CoreList-5.20170621.tar.gz
 /Module-CoreList-5.20170715.tar.gz
 /Module-CoreList-5.20170720.tar.gz
+/Module-CoreList-5.20170821.tar.gz
diff --git a/perl-Module-CoreList.spec b/perl-Module-CoreList.spec
index cffbfa1..b9a968a 100644
--- a/perl-Module-CoreList.spec
+++ b/perl-Module-CoreList.spec
@@ -1,8 +1,8 @@
 Name:   perl-Module-CoreList
 # Epoch to compete with perl.spec
 Epoch:  1
-Version:5.20170720
-Release:2%{?dist}
+Version:5.20170821
+Release:1%{?dist}
 Summary:What modules are shipped with versions of perl
 License:GPL+ or Artistic
 URL:http://search.cpan.org/dist/Module-CoreList/
@@ -79,6 +79,9 @@ make test
 %{_mandir}/man1/corelist.*
 
 %changelog
+* Tue Aug 22 2017 Petr Pisar  - 1:5.20170821-1
+- 5.20170821 bump
+
 * Thu Jul 27 2017 Fedora Release Engineering  - 
1:5.20170720-2
 - Rebuilt for https://fedoraproject.org/wiki/Fedora_27_Mass_Rebuild
 
diff --git a/sources b/sources
index 01da145..2b92327 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-SHA512 (Module-CoreList-5.20170720.tar.gz) = 
38b2b3287d8495ed7c64295ec92dc2e814f00f10644f4ee5d97e19fb41fc50f6024aadccf3cdeb752fdf429ba127bdd93db3dddccaffae32996efe1768768847
+SHA512 (Module-CoreList-5.20170821.tar.gz) = 
e5b1eb3bee5cc7d50f3bf21699c840c7b1fbea283affac5c79c8c31167b226d7fa76e3b885810e427ea976633ec0c223320f2b57e9a1bcd1fdc6d8256d6a551f



https://src.fedoraproject.org/rpms/perl-Module-CoreList/c/7e696792bbf5369c045e1d5af383bd830679c75e?branch=f27
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

ppisar pushed to perl-Module-CoreList (master). "5.20170821 bump"

[notifications]

From 7e696792bbf5369c045e1d5af383bd830679c75e Mon Sep 17 00:00:00 2001
From: Petr Písař 
Date: Aug 22 2017 08:19:19 +
Subject: 5.20170821 bump


---

diff --git a/.gitignore b/.gitignore
index b747c7b..c6418c5 100644
--- a/.gitignore
+++ b/.gitignore
@@ -42,3 +42,4 @@ Module-CoreList-2.13.tar.gz
 /Module-CoreList-5.20170621.tar.gz
 /Module-CoreList-5.20170715.tar.gz
 /Module-CoreList-5.20170720.tar.gz
+/Module-CoreList-5.20170821.tar.gz
diff --git a/perl-Module-CoreList.spec b/perl-Module-CoreList.spec
index cffbfa1..b9a968a 100644
--- a/perl-Module-CoreList.spec
+++ b/perl-Module-CoreList.spec
@@ -1,8 +1,8 @@
 Name:   perl-Module-CoreList
 # Epoch to compete with perl.spec
 Epoch:  1
-Version:5.20170720
-Release:2%{?dist}
+Version:5.20170821
+Release:1%{?dist}
 Summary:What modules are shipped with versions of perl
 License:GPL+ or Artistic
 URL:http://search.cpan.org/dist/Module-CoreList/
@@ -79,6 +79,9 @@ make test
 %{_mandir}/man1/corelist.*
 
 %changelog
+* Tue Aug 22 2017 Petr Pisar  - 1:5.20170821-1
+- 5.20170821 bump
+
 * Thu Jul 27 2017 Fedora Release Engineering  - 
1:5.20170720-2
 - Rebuilt for https://fedoraproject.org/wiki/Fedora_27_Mass_Rebuild
 
diff --git a/sources b/sources
index 01da145..2b92327 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-SHA512 (Module-CoreList-5.20170720.tar.gz) = 
38b2b3287d8495ed7c64295ec92dc2e814f00f10644f4ee5d97e19fb41fc50f6024aadccf3cdeb752fdf429ba127bdd93db3dddccaffae32996efe1768768847
+SHA512 (Module-CoreList-5.20170821.tar.gz) = 
e5b1eb3bee5cc7d50f3bf21699c840c7b1fbea283affac5c79c8c31167b226d7fa76e3b885810e427ea976633ec0c223320f2b57e9a1bcd1fdc6d8256d6a551f



https://src.fedoraproject.org/rpms/perl-Module-CoreList/c/7e696792bbf5369c045e1d5af383bd830679c75e?branch=master
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

ppisar uploaded Module-CoreList-5.20170821.tar.gz for perl-Module-CoreList

[notifications]

e5b1eb3bee5cc7d50f3bf21699c840c7b1fbea283affac5c79c8c31167b226d7fa76e3b885810e427ea976633ec0c223320f2b57e9a1bcd1fdc6d8256d6a551f
  Module-CoreList-5.20170821.tar.gz

https://src.fedoraproject.org/lookaside/pkgs/perl-Module-CoreList/Module-CoreList-5.20170821.tar.gz/sha512/e5b1eb3bee5cc7d50f3bf21699c840c7b1fbea283affac5c79c8c31167b226d7fa76e3b885810e427ea976633ec0c223320f2b57e9a1bcd1fdc6d8256d6a551f/Module-CoreList-5.20170821.tar.gz
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

ppisar pushed to perl (f27). "Fix unreliable Time-HiRes tests"

[notifications]

From 2510e877e65e7a207b2d3b692896b9e3231c0737 Mon Sep 17 00:00:00 2001
From: Petr Písař 
Date: Aug 22 2017 07:54:15 +
Subject: Fix unreliable Time-HiRes tests


---

diff --git 
a/perl-5.26.0-Time-HiRes-Fix-unreliable-t-usleep.t-and-t-utime.t.patch 
b/perl-5.26.0-Time-HiRes-Fix-unreliable-t-usleep.t-and-t-utime.t.patch
new file mode 100644
index 000..206aeea
--- /dev/null
+++ b/perl-5.26.0-Time-HiRes-Fix-unreliable-t-usleep.t-and-t-utime.t.patch
@@ -0,0 +1,73 @@
+From 8985b12868f07d9ef501580d600e49fe8f230eb4 Mon Sep 17 00:00:00 2001
+From: =?UTF-8?q?Petr=20P=C3=ADsa=C5=99?= 
+Date: Tue, 22 Aug 2017 09:49:42 +0200
+Subject: [PATCH] Time-HiRes: Fix unreliable t/usleep.t and t/utime.t
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+Ported from Time-HiRes-1.9746.
+
+The tests randomly failed on loaded machines because a CPU scheduler
+could add unpredictable delays.
+
+CPAN RT#122819
+
+Signed-off-by: Petr Písař 
+---
+ dist/Time-HiRes/t/usleep.t | 4 ++--
+ dist/Time-HiRes/t/utime.t  | 9 +
+ 2 files changed, 7 insertions(+), 6 deletions(-)
+
+diff --git a/dist/Time-HiRes/t/usleep.t b/dist/Time-HiRes/t/usleep.t
+index 9322458..bb66cbe 100644
+--- a/dist/Time-HiRes/t/usleep.t
 b/dist/Time-HiRes/t/usleep.t
+@@ -32,7 +32,7 @@ SKIP: {
+ Time::HiRes::usleep(500_000);
+ my $f2 = Time::HiRes::time();
+ my $d = $f2 - $f;
+-ok $d > 0.4 && $d < 0.9 or print("# slept $d secs $f to $f2\n");
++ok $d > 0.49 or print("# slept $d secs $f to $f2\n");
+ }
+ 
+ SKIP: {
+@@ -40,7 +40,7 @@ SKIP: {
+ my $r = [ Time::HiRes::gettimeofday() ];
+ Time::HiRes::sleep( 0.5 );
+ my $f = Time::HiRes::tv_interval $r;
+-ok $f > 0.4 && $f < 0.9 or print("# slept $f instead of 0.5 secs.\n");
++ok $f > 0.49 or print("# slept $f instead of 0.5 secs.\n");
+ }
+ 
+ SKIP: {
+diff --git a/dist/Time-HiRes/t/utime.t b/dist/Time-HiRes/t/utime.t
+index 22fd48e..c5c7e55 100644
+--- a/dist/Time-HiRes/t/utime.t
 b/dist/Time-HiRes/t/utime.t
+@@ -106,17 +106,18 @@ print "# utime undef sets time to now\n";
+   my ($fh2, $filename2) = tempfile( "Time-HiRes-utime-X", UNLINK 
=> 1 );
+ 
+   my $now = Time::HiRes::time;
++   sleep(1);
+   is Time::HiRes::utime(undef, undef, $filename1, $fh2), 2, "Two files 
changed";
+ 
+   {
+   my ($got_atime, $got_mtime) = ( Time::HiRes::stat($fh1) )[8, 9];
+-  cmp_ok abs( $got_atime - $now), '<', 0.1, "File 1 atime set 
correctly";
+-  cmp_ok abs( $got_mtime - $now), '<', 0.1, "File 1 mtime set 
correctly";
++  cmp_ok $got_atime, '>=', $now, "File 1 atime set correctly";
++  cmp_ok $got_mtime, '>=', $now, "File 1 mtime set correctly";
+   }
+   {
+   my ($got_atime, $got_mtime) = ( Time::HiRes::stat($filename2) 
)[8, 9];
+-  cmp_ok abs( $got_atime - $now), '<', 0.1, "File 2 atime set 
correctly";
+-  cmp_ok abs( $got_mtime - $now), '<', 0.1, "File 2 mtime set 
correctly";
++  cmp_ok $got_atime, '>=', $now, "File 2 atime set correctly";
++  cmp_ok $got_mtime, '>=', $now, "File 2 mtime set correctly";
+   }
+ };
+ 
+-- 
+2.9.5
+
diff --git a/perl.spec b/perl.spec
index 28ab3a9..d62e515 100644
--- a/perl.spec
+++ b/perl.spec
@@ -79,7 +79,7 @@ License:GPL+ or Artistic
 Epoch:  %{perl_epoch}
 Version:%{perl_version}
 # release number must be even higher, because dual-lived modules will be 
broken otherwise
-Release:398%{?dist}
+Release:399%{?dist}
 Summary:Practical Extraction and Report Language
 Url:http://www.perl.org/
 Source0:http://www.cpan.org/src/5.0/perl-%{perl_version}.tar.bz2
@@ -228,6 +228,9 @@ Patch56:
perl-5.27.2-EU-Constant-avoid-uninit-warning.patch
 # in upstream after 5.27.2
 Patch57:perl-5.27.2-Configure-check-for-GCC-6-and-7.patch
 
+# Fix unreliable Time-HiRes tests, CPAN RT#122819, in Time-HiRes-1.9746
+Patch58:
perl-5.26.0-Time-HiRes-Fix-unreliable-t-usleep.t-and-t-utime.t.patch
+
 # Link XS modules to libperl.so with EU::CBuilder on Linux, bug #960048
 Patch200:   
perl-5.16.3-Link-XS-modules-to-libperl.so-with-EU-CBuilder-on-Li.patch
 
@@ -2815,6 +2818,7 @@ Perl extension for Version Objects
 %patch55 -p1
 %patch56 -p1
 %patch57 -p1
+%patch58 -p1
 %patch200 -p1
 %patch201 -p1
 
@@ -2857,6 +2861,7 @@ perl -x patchlevel.h \
 'Fedora Patch55: Fix compiler warnings in code generated by 
ExtUtils::Constant (CPAN RT#63832)' \
 'Fedora Patch56: Fix compiler warnings in code generated by 
ExtUtils::Constant (CPAN RT#101487)' \
 'Fedora Patch57: Fix GCC version detection for -D_FORTIFY_SOURCE override 
(RT#131809)' \
+'Fedora Patch58: Fix unreliable Time-HiRes tests (CPAN RT#122819)' \
 'Fedora Patch200: Link XS modules to libperl.so with EU::CBuilder on 
Linux' \
 'Fedora 

ppisar pushed to perl (f27). "Do not require $Config{libs} providers by perl-devel package (..more)"

[notifications]

From 5fbdf1697c92caf5eea8b51fd294773c6c76767f Mon Sep 17 00:00:00 2001
From: Petr Písař 
Date: Aug 22 2017 08:01:03 +
Subject: Do not require $Config{libs} providers by perl-devel package


This reverts:

commit f2346c87463c84069c6b5c5887edd0c8987736dd
Author: Petr Písař 
Date:   Thu Jun 6 16:17:26 2013 +0200

Require $Config{libs} providers

$Config{libs} and $Config{perlibs} documents how perl was built. Not how
another XS modules should be built
.

---

diff --git a/perl.spec b/perl.spec
index d62e515..2a7e85c 100644
--- a/perl.spec
+++ b/perl.spec
@@ -470,12 +470,6 @@ directories).
 Summary:Header #files for use in perl development
 # l1_char_class_tab.h is generated from lib/unicore sources:UCD
 License:(GPL+ or Artistic) and UCD
-# Require $Config{libs} providers, bug #905482
-Requires:   libdb-devel
-%if %{with gdbm}
-Requires:   gdbm-devel
-%endif
-Requires:   glibc-devel
 %if %{with perl_enables_systemtap}
 Requires:   systemtap-sdt-devel
 %endif
@@ -5147,6 +5141,7 @@ popd
 %changelog
 * Tue Aug 22 2017 Petr Pisar  - 4:5.26.0-399
 - Fix unreliable Time-HiRes tests (CPAN RT#122819)
+- Do not require $Config{libs} providers by perl-devel package (bug #1481324)
 
 * Tue Aug 08 2017 Petr Pisar  - 4:5.26.0-398
 - Fix reporting malformed UTF-8 character (RT#131646)



https://src.fedoraproject.org/rpms/perl/c/5fbdf1697c92caf5eea8b51fd294773c6c76767f?branch=f27
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

ppisar pushed to perl (f27). "Link libresolv.patch to a bug report"

[notifications]

From b2681c65784f6027c98ac86e74e14d5f855f8110 Mon Sep 17 00:00:00 2001
From: Petr Písař 
Date: Aug 17 2017 06:07:10 +
Subject: Link libresolv.patch to a bug report


---

diff --git a/perl.spec b/perl.spec
index 94b042d..28ab3a9 100644
--- a/perl.spec
+++ b/perl.spec
@@ -105,7 +105,7 @@ Patch1: perl-perlbug-tag.patch
 # Fedora/RHEL only (64bit only)
 Patch3: perl-5.8.0-libdir64.patch
 
-# Fedora/RHEL specific (use libresolv instead of libbind)
+# Fedora/RHEL specific (use libresolv instead of libbind), bug #151127
 Patch4: perl-5.10.0-libresolv.patch
 
 # FIXME: May need the "Fedora" references removed before upstreaming



https://src.fedoraproject.org/rpms/perl/c/b2681c65784f6027c98ac86e74e14d5f855f8110?branch=f27
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

ppisar pushed to perl (master). "Fix unreliable Time-HiRes tests"

[notifications]

From 2510e877e65e7a207b2d3b692896b9e3231c0737 Mon Sep 17 00:00:00 2001
From: Petr Písař 
Date: Aug 22 2017 07:54:15 +
Subject: Fix unreliable Time-HiRes tests


---

diff --git 
a/perl-5.26.0-Time-HiRes-Fix-unreliable-t-usleep.t-and-t-utime.t.patch 
b/perl-5.26.0-Time-HiRes-Fix-unreliable-t-usleep.t-and-t-utime.t.patch
new file mode 100644
index 000..206aeea
--- /dev/null
+++ b/perl-5.26.0-Time-HiRes-Fix-unreliable-t-usleep.t-and-t-utime.t.patch
@@ -0,0 +1,73 @@
+From 8985b12868f07d9ef501580d600e49fe8f230eb4 Mon Sep 17 00:00:00 2001
+From: =?UTF-8?q?Petr=20P=C3=ADsa=C5=99?= 
+Date: Tue, 22 Aug 2017 09:49:42 +0200
+Subject: [PATCH] Time-HiRes: Fix unreliable t/usleep.t and t/utime.t
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+Ported from Time-HiRes-1.9746.
+
+The tests randomly failed on loaded machines because a CPU scheduler
+could add unpredictable delays.
+
+CPAN RT#122819
+
+Signed-off-by: Petr Písař 
+---
+ dist/Time-HiRes/t/usleep.t | 4 ++--
+ dist/Time-HiRes/t/utime.t  | 9 +
+ 2 files changed, 7 insertions(+), 6 deletions(-)
+
+diff --git a/dist/Time-HiRes/t/usleep.t b/dist/Time-HiRes/t/usleep.t
+index 9322458..bb66cbe 100644
+--- a/dist/Time-HiRes/t/usleep.t
 b/dist/Time-HiRes/t/usleep.t
+@@ -32,7 +32,7 @@ SKIP: {
+ Time::HiRes::usleep(500_000);
+ my $f2 = Time::HiRes::time();
+ my $d = $f2 - $f;
+-ok $d > 0.4 && $d < 0.9 or print("# slept $d secs $f to $f2\n");
++ok $d > 0.49 or print("# slept $d secs $f to $f2\n");
+ }
+ 
+ SKIP: {
+@@ -40,7 +40,7 @@ SKIP: {
+ my $r = [ Time::HiRes::gettimeofday() ];
+ Time::HiRes::sleep( 0.5 );
+ my $f = Time::HiRes::tv_interval $r;
+-ok $f > 0.4 && $f < 0.9 or print("# slept $f instead of 0.5 secs.\n");
++ok $f > 0.49 or print("# slept $f instead of 0.5 secs.\n");
+ }
+ 
+ SKIP: {
+diff --git a/dist/Time-HiRes/t/utime.t b/dist/Time-HiRes/t/utime.t
+index 22fd48e..c5c7e55 100644
+--- a/dist/Time-HiRes/t/utime.t
 b/dist/Time-HiRes/t/utime.t
+@@ -106,17 +106,18 @@ print "# utime undef sets time to now\n";
+   my ($fh2, $filename2) = tempfile( "Time-HiRes-utime-X", UNLINK 
=> 1 );
+ 
+   my $now = Time::HiRes::time;
++   sleep(1);
+   is Time::HiRes::utime(undef, undef, $filename1, $fh2), 2, "Two files 
changed";
+ 
+   {
+   my ($got_atime, $got_mtime) = ( Time::HiRes::stat($fh1) )[8, 9];
+-  cmp_ok abs( $got_atime - $now), '<', 0.1, "File 1 atime set 
correctly";
+-  cmp_ok abs( $got_mtime - $now), '<', 0.1, "File 1 mtime set 
correctly";
++  cmp_ok $got_atime, '>=', $now, "File 1 atime set correctly";
++  cmp_ok $got_mtime, '>=', $now, "File 1 mtime set correctly";
+   }
+   {
+   my ($got_atime, $got_mtime) = ( Time::HiRes::stat($filename2) 
)[8, 9];
+-  cmp_ok abs( $got_atime - $now), '<', 0.1, "File 2 atime set 
correctly";
+-  cmp_ok abs( $got_mtime - $now), '<', 0.1, "File 2 mtime set 
correctly";
++  cmp_ok $got_atime, '>=', $now, "File 2 atime set correctly";
++  cmp_ok $got_mtime, '>=', $now, "File 2 mtime set correctly";
+   }
+ };
+ 
+-- 
+2.9.5
+
diff --git a/perl.spec b/perl.spec
index 28ab3a9..d62e515 100644
--- a/perl.spec
+++ b/perl.spec
@@ -79,7 +79,7 @@ License:GPL+ or Artistic
 Epoch:  %{perl_epoch}
 Version:%{perl_version}
 # release number must be even higher, because dual-lived modules will be 
broken otherwise
-Release:398%{?dist}
+Release:399%{?dist}
 Summary:Practical Extraction and Report Language
 Url:http://www.perl.org/
 Source0:http://www.cpan.org/src/5.0/perl-%{perl_version}.tar.bz2
@@ -228,6 +228,9 @@ Patch56:
perl-5.27.2-EU-Constant-avoid-uninit-warning.patch
 # in upstream after 5.27.2
 Patch57:perl-5.27.2-Configure-check-for-GCC-6-and-7.patch
 
+# Fix unreliable Time-HiRes tests, CPAN RT#122819, in Time-HiRes-1.9746
+Patch58:
perl-5.26.0-Time-HiRes-Fix-unreliable-t-usleep.t-and-t-utime.t.patch
+
 # Link XS modules to libperl.so with EU::CBuilder on Linux, bug #960048
 Patch200:   
perl-5.16.3-Link-XS-modules-to-libperl.so-with-EU-CBuilder-on-Li.patch
 
@@ -2815,6 +2818,7 @@ Perl extension for Version Objects
 %patch55 -p1
 %patch56 -p1
 %patch57 -p1
+%patch58 -p1
 %patch200 -p1
 %patch201 -p1
 
@@ -2857,6 +2861,7 @@ perl -x patchlevel.h \
 'Fedora Patch55: Fix compiler warnings in code generated by 
ExtUtils::Constant (CPAN RT#63832)' \
 'Fedora Patch56: Fix compiler warnings in code generated by 
ExtUtils::Constant (CPAN RT#101487)' \
 'Fedora Patch57: Fix GCC version detection for -D_FORTIFY_SOURCE override 
(RT#131809)' \
+'Fedora Patch58: Fix unreliable Time-HiRes tests (CPAN RT#122819)' \
 'Fedora Patch200: Link XS modules to libperl.so with EU::CBuilder on 
Linux' \
 'Fedora 

ppisar pushed to perl (master). "Do not require $Config{libs} providers by perl-devel package (..more)"

[notifications]

From 5fbdf1697c92caf5eea8b51fd294773c6c76767f Mon Sep 17 00:00:00 2001
From: Petr Písař 
Date: Aug 22 2017 08:01:03 +
Subject: Do not require $Config{libs} providers by perl-devel package


This reverts:

commit f2346c87463c84069c6b5c5887edd0c8987736dd
Author: Petr Písař 
Date:   Thu Jun 6 16:17:26 2013 +0200

Require $Config{libs} providers

$Config{libs} and $Config{perlibs} documents how perl was built. Not how
another XS modules should be built
.

---

diff --git a/perl.spec b/perl.spec
index d62e515..2a7e85c 100644
--- a/perl.spec
+++ b/perl.spec
@@ -470,12 +470,6 @@ directories).
 Summary:Header #files for use in perl development
 # l1_char_class_tab.h is generated from lib/unicore sources:UCD
 License:(GPL+ or Artistic) and UCD
-# Require $Config{libs} providers, bug #905482
-Requires:   libdb-devel
-%if %{with gdbm}
-Requires:   gdbm-devel
-%endif
-Requires:   glibc-devel
 %if %{with perl_enables_systemtap}
 Requires:   systemtap-sdt-devel
 %endif
@@ -5147,6 +5141,7 @@ popd
 %changelog
 * Tue Aug 22 2017 Petr Pisar  - 4:5.26.0-399
 - Fix unreliable Time-HiRes tests (CPAN RT#122819)
+- Do not require $Config{libs} providers by perl-devel package (bug #1481324)
 
 * Tue Aug 08 2017 Petr Pisar  - 4:5.26.0-398
 - Fix reporting malformed UTF-8 character (RT#131646)



https://src.fedoraproject.org/rpms/perl/c/5fbdf1697c92caf5eea8b51fd294773c6c76767f?branch=master
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

[Bug 1483773] perl-CPAN-Perl-Releases-3.32 is available

[bugzilla]

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



--- Comment #2 from Fedora Update System  ---
perl-CPAN-Perl-Releases-3.32-1.fc25 has been submitted as an update to Fedora
25. https://bodhi.fedoraproject.org/updates/FEDORA-2017-8b4b3e1443

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

[Bug 1483773] perl-CPAN-Perl-Releases-3.32 is available

[bugzilla]

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



--- Comment #1 from Fedora Update System  ---
perl-CPAN-Perl-Releases-3.32-1.fc26 has been submitted as an update to Fedora
26. https://bodhi.fedoraproject.org/updates/FEDORA-2017-059c90f4f7

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

jplesnik pushed to perl-CPAN-Perl-Releases (f25). "3.32 bump"

[notifications]

From b1032172f310b3b2e1755d6cbf0bfc967cc564f2 Mon Sep 17 00:00:00 2001
From: Jitka Plesnikova 
Date: Aug 22 2017 07:45:54 +
Subject: 3.32 bump


---

diff --git a/.gitignore b/.gitignore
index 4ca7a50..f24fb25 100644
--- a/.gitignore
+++ b/.gitignore
@@ -73,3 +73,4 @@
 /CPAN-Perl-Releases-3.26.tar.gz
 /CPAN-Perl-Releases-3.28.tar.gz
 /CPAN-Perl-Releases-3.30.tar.gz
+/CPAN-Perl-Releases-3.32.tar.gz
diff --git a/perl-CPAN-Perl-Releases.spec b/perl-CPAN-Perl-Releases.spec
index a998529..8d62c38 100644
--- a/perl-CPAN-Perl-Releases.spec
+++ b/perl-CPAN-Perl-Releases.spec
@@ -1,5 +1,5 @@
 Name:   perl-CPAN-Perl-Releases
-Version:3.30
+Version:3.32
 Release:1%{?dist}
 Summary:Mapping Perl releases on CPAN to the location of the tarballs
 License:GPL+ or Artistic
@@ -53,6 +53,9 @@ make test
 %{_mandir}/man3/*
 
 %changelog
+* Tue Aug 22 2017 Jitka Plesnikova  - 3.32-1
+- 3.32 bump
+
 * Fri Jul 21 2017 Jitka Plesnikova  - 3.30-1
 - 3.30 bump
 
diff --git a/sources b/sources
index fde7e52..3d0b2fe 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-SHA512 (CPAN-Perl-Releases-3.30.tar.gz) = 
cc45838ed40cbdfd11def843a5be1881bffb2c724d382b010db2be5a549efc54bc6ff02c6f5c0883c9e40b12e99fbc09e9abb4582ffce19f4c221209b12956e9
+SHA512 (CPAN-Perl-Releases-3.32.tar.gz) = 
7e4525bb15a2609093d819c64f58851d26a91376b5cefe47b35eb96e4b8ea59bee393d984b15431a929f2f93fd34da84e3bf7ddc2890ec6457013527009ebff5



https://src.fedoraproject.org/rpms/perl-CPAN-Perl-Releases/c/b1032172f310b3b2e1755d6cbf0bfc967cc564f2?branch=f25
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

[Bug 1483773] perl-CPAN-Perl-Releases-3.32 is available

[bugzilla]

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

Jitka Plesnikova  changed:

   What|Removed |Added

 Status|NEW |MODIFIED
   Fixed In Version||perl-CPAN-Perl-Releases-3.3
   ||2-1.fc28
   ||perl-CPAN-Perl-Releases-3.3
   ||2-1.fc27



-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

jplesnik pushed to perl-CPAN-Perl-Releases (f26). "3.32 bump"

[notifications]

From 889c1bcdc21d69142b62b3d7faeefcc4c029f7ea Mon Sep 17 00:00:00 2001
From: Jitka Plesnikova 
Date: Aug 22 2017 07:42:37 +
Subject: 3.32 bump


---

diff --git a/.gitignore b/.gitignore
index 4ca7a50..f24fb25 100644
--- a/.gitignore
+++ b/.gitignore
@@ -73,3 +73,4 @@
 /CPAN-Perl-Releases-3.26.tar.gz
 /CPAN-Perl-Releases-3.28.tar.gz
 /CPAN-Perl-Releases-3.30.tar.gz
+/CPAN-Perl-Releases-3.32.tar.gz
diff --git a/perl-CPAN-Perl-Releases.spec b/perl-CPAN-Perl-Releases.spec
index 5f49cbf..9129c24 100644
--- a/perl-CPAN-Perl-Releases.spec
+++ b/perl-CPAN-Perl-Releases.spec
@@ -1,5 +1,5 @@
 Name:   perl-CPAN-Perl-Releases
-Version:3.30
+Version:3.32
 Release:1%{?dist}
 Summary:Mapping Perl releases on CPAN to the location of the tarballs
 License:GPL+ or Artistic
@@ -53,6 +53,9 @@ make test
 %{_mandir}/man3/*
 
 %changelog
+* Tue Aug 22 2017 Jitka Plesnikova  - 3.32-1
+- 3.32 bump
+
 * Fri Jul 21 2017 Jitka Plesnikova  - 3.30-1
 - 3.30 bump
 
diff --git a/sources b/sources
index fde7e52..3d0b2fe 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-SHA512 (CPAN-Perl-Releases-3.30.tar.gz) = 
cc45838ed40cbdfd11def843a5be1881bffb2c724d382b010db2be5a549efc54bc6ff02c6f5c0883c9e40b12e99fbc09e9abb4582ffce19f4c221209b12956e9
+SHA512 (CPAN-Perl-Releases-3.32.tar.gz) = 
7e4525bb15a2609093d819c64f58851d26a91376b5cefe47b35eb96e4b8ea59bee393d984b15431a929f2f93fd34da84e3bf7ddc2890ec6457013527009ebff5



https://src.fedoraproject.org/rpms/perl-CPAN-Perl-Releases/c/889c1bcdc21d69142b62b3d7faeefcc4c029f7ea?branch=f26
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

jplesnik pushed to perl-CPAN-Perl-Releases (f27). "3.32 bump"

[notifications]

From cacf0645570a89db180571261d640ebdac96a662 Mon Sep 17 00:00:00 2001
From: Jitka Plesnikova 
Date: Aug 22 2017 07:33:38 +
Subject: 3.32 bump


---

diff --git a/.gitignore b/.gitignore
index 4ca7a50..f24fb25 100644
--- a/.gitignore
+++ b/.gitignore
@@ -73,3 +73,4 @@
 /CPAN-Perl-Releases-3.26.tar.gz
 /CPAN-Perl-Releases-3.28.tar.gz
 /CPAN-Perl-Releases-3.30.tar.gz
+/CPAN-Perl-Releases-3.32.tar.gz
diff --git a/perl-CPAN-Perl-Releases.spec b/perl-CPAN-Perl-Releases.spec
index b42b308..0073ba5 100644
--- a/perl-CPAN-Perl-Releases.spec
+++ b/perl-CPAN-Perl-Releases.spec
@@ -1,6 +1,6 @@
 Name:   perl-CPAN-Perl-Releases
-Version:3.30
-Release:2%{?dist}
+Version:3.32
+Release:1%{?dist}
 Summary:Mapping Perl releases on CPAN to the location of the tarballs
 License:GPL+ or Artistic
 Group:  Development/Libraries
@@ -53,6 +53,9 @@ make test
 %{_mandir}/man3/*
 
 %changelog
+* Tue Aug 22 2017 Jitka Plesnikova  - 3.32-1
+- 3.32 bump
+
 * Thu Jul 27 2017 Fedora Release Engineering  - 
3.30-2
 - Rebuilt for https://fedoraproject.org/wiki/Fedora_27_Mass_Rebuild
 
diff --git a/sources b/sources
index fde7e52..3d0b2fe 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-SHA512 (CPAN-Perl-Releases-3.30.tar.gz) = 
cc45838ed40cbdfd11def843a5be1881bffb2c724d382b010db2be5a549efc54bc6ff02c6f5c0883c9e40b12e99fbc09e9abb4582ffce19f4c221209b12956e9
+SHA512 (CPAN-Perl-Releases-3.32.tar.gz) = 
7e4525bb15a2609093d819c64f58851d26a91376b5cefe47b35eb96e4b8ea59bee393d984b15431a929f2f93fd34da84e3bf7ddc2890ec6457013527009ebff5



https://src.fedoraproject.org/rpms/perl-CPAN-Perl-Releases/c/cacf0645570a89db180571261d640ebdac96a662?branch=f27
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

[Bug 1483762] Rebase from upstream required

[bugzilla]

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



--- Comment #2 from maria...@tuxette.fr  ---
Updates are avalaible in testing repository 
https://bodhi.fedoraproject.org/updates/?packages=fusioninventory-agent 
https://bugzilla.redhat.com/show_bug.cgi?id=1477175

If you can test and add feedback, it will be great

Petr, thanks for the fix

-- 
You are receiving this mail because:
You are on the CC list for the bug.
You are the assignee for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

jplesnik pushed to perl-CPAN-Perl-Releases (master). "3.32 bump"

[notifications]

From cacf0645570a89db180571261d640ebdac96a662 Mon Sep 17 00:00:00 2001
From: Jitka Plesnikova 
Date: Aug 22 2017 07:33:38 +
Subject: 3.32 bump


---

diff --git a/.gitignore b/.gitignore
index 4ca7a50..f24fb25 100644
--- a/.gitignore
+++ b/.gitignore
@@ -73,3 +73,4 @@
 /CPAN-Perl-Releases-3.26.tar.gz
 /CPAN-Perl-Releases-3.28.tar.gz
 /CPAN-Perl-Releases-3.30.tar.gz
+/CPAN-Perl-Releases-3.32.tar.gz
diff --git a/perl-CPAN-Perl-Releases.spec b/perl-CPAN-Perl-Releases.spec
index b42b308..0073ba5 100644
--- a/perl-CPAN-Perl-Releases.spec
+++ b/perl-CPAN-Perl-Releases.spec
@@ -1,6 +1,6 @@
 Name:   perl-CPAN-Perl-Releases
-Version:3.30
-Release:2%{?dist}
+Version:3.32
+Release:1%{?dist}
 Summary:Mapping Perl releases on CPAN to the location of the tarballs
 License:GPL+ or Artistic
 Group:  Development/Libraries
@@ -53,6 +53,9 @@ make test
 %{_mandir}/man3/*
 
 %changelog
+* Tue Aug 22 2017 Jitka Plesnikova  - 3.32-1
+- 3.32 bump
+
 * Thu Jul 27 2017 Fedora Release Engineering  - 
3.30-2
 - Rebuilt for https://fedoraproject.org/wiki/Fedora_27_Mass_Rebuild
 
diff --git a/sources b/sources
index fde7e52..3d0b2fe 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-SHA512 (CPAN-Perl-Releases-3.30.tar.gz) = 
cc45838ed40cbdfd11def843a5be1881bffb2c724d382b010db2be5a549efc54bc6ff02c6f5c0883c9e40b12e99fbc09e9abb4582ffce19f4c221209b12956e9
+SHA512 (CPAN-Perl-Releases-3.32.tar.gz) = 
7e4525bb15a2609093d819c64f58851d26a91376b5cefe47b35eb96e4b8ea59bee393d984b15431a929f2f93fd34da84e3bf7ddc2890ec6457013527009ebff5



https://src.fedoraproject.org/rpms/perl-CPAN-Perl-Releases/c/cacf0645570a89db180571261d640ebdac96a662?branch=master
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

jplesnik uploaded CPAN-Perl-Releases-3.32.tar.gz for perl-CPAN-Perl-Releases

[notifications]

7e4525bb15a2609093d819c64f58851d26a91376b5cefe47b35eb96e4b8ea59bee393d984b15431a929f2f93fd34da84e3bf7ddc2890ec6457013527009ebff5
  CPAN-Perl-Releases-3.32.tar.gz

https://src.fedoraproject.org/lookaside/pkgs/perl-CPAN-Perl-Releases/CPAN-Perl-Releases-3.32.tar.gz/sha512/7e4525bb15a2609093d819c64f58851d26a91376b5cefe47b35eb96e4b8ea59bee393d984b15431a929f2f93fd34da84e3bf7ddc2890ec6457013527009ebff5/CPAN-Perl-Releases-3.32.tar.gz
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

[Bug 1483762] Rebase from upstream required

[bugzilla]

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

Petr Pisar  changed:

   What|Removed |Added

 CC||ppi...@redhat.com



--- Comment #1 from Petr Pisar  ---
jehan, this bug report should be assigned to you, not perl-sig. I requested
fixing the default assignee in


-- 
You are receiving this mail because:
You are on the CC list for the bug.
You are the assignee for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org