Re: Fw: fedmsg notification

[Todd Zullinger]

Hi Pierre,

Pierre-Yves Chibon wrote:
> On Mon, Apr 09, 2018 at 01:28:02PM +0200, Dominik 'Rathann' Mierzejewski 
> wrote:
>> On Monday, 09 April 2018 at 13:20, Pierre-Yves Chibon wrote:
>> [...]
>>> Finally the reason this has not been correctly announced is that we are 
>>> still
>>> investigating the capacity of the system and the pipeline to check if it can
>>> handle the load of all the package in Fedora, but as said, the pipeline is
>>> already sending messages to the production bus, thus this behavior :(
>> 
>> The obvious thing to do is to stop sending these messages to the
>> production bus until fedmsg_meta is updated and the update pushed to
>> production. Why hasn't this been done already?
> 
> The basic answer is that I didn't have the hand to do it.
> So instead I released a new fedmsg-meta-fedora-infrastructure with support for
> these messages and deployed it in production.
> Messages about the allpackages pipeline should now make some sense :)

Is this deployed in production?  I just pushed some changes
to a fork on src.fedoraproject.org and recieved an email for
each commit that looked like this:

Subject: fedmsg notification

   

Notification time stamped 2018-04-12 04:23:01 UTC



https://jenkins-continuous-infra.apps.ci.centos.org/blue/organizations/jenkins/upstream-fedora-pipeline-trigger/detail/upstream-fedora-pipeline-trigger/11044/pipeline/

If there's a change from what Michael reported, I can't see
what it is. :)

I suspect this shouldn't be triggering at all for forks,
which I believe two open infrastructure tickets cover:

https://pagure.io/fedora-infrastructure/issue/6575
https://pagure.io/fedora-infrastructure/issue/6791

For non-forks, I think it would also be ideal to not fire
this off for each commit but rather once per push.

Thanks,

-- 
Todd
~~
I have never let my schooling interfere with my education.
-- Mark Twain (1835-1910)



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

Schedule for Thursday's FPC Meeting (2018-04-12 16:00 UTC)

[James Antill]

 Following is the list of topics that will be discussed in the FPC
meeting Thursday at 2018-04-12 16:00 UTC in #fedora-meeting-1 on
irc.freenode.net.

 Local time information (via. uitime):

= Day: Thursday ==
2018-04-12 09:00 PDT  US/Pacific
2018-04-12 12:00 EDT  --> US/Eastern <--
2018-04-12 16:00 UTC  UTC   
2018-04-12 17:00 BST  Europe/London 
2018-04-12 18:00 CEST Europe/Berlin 
2018-04-12 18:00 CEST Europe/Paris  
2018-04-12 21:30 IST  Asia/Calcutta 
 New Day: Friday -
2018-04-13 00:00 HKT  Asia/Hong_Kong
2018-04-13 00:00 +08  Asia/Singapore
2018-04-13 01:00 JST  Asia/Tokyo
2018-04-13 02:00 AEST Australia/Brisbane

 Links to all tickets below can be found at: 

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

= Followups =

#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

#topic #694 Packaging guidelines for application independence 
.fpc 694
https://pagure.io/packaging-committee/issue/694

#topic #702 C/C++ guidelines should say using clang needs an exception
.fpc 702
https://pagure.io/packaging-committee/issue/702

#topic #708 Allocating a static uid and gid for openvswitch
.fpc 708
https://pagure.io/packaging-committee/issue/708

#topic #710 Ruby packaging guidelines update
.fpc 710
https://pagure.io/packaging-committee/issue/710

#topic #713 Forward-looking conditionals by default
.fpc 713
https://pagure.io/packaging-committee/issue/713

#topic #714 let's kill file deps!
.fpc 714
https://pagure.io/packaging-committee/issue/714

#topic #715 Separately building package documentation
.fpc 715
https://pagure.io/packaging-committee/issue/715

#topic #719 Simplify packaging of forge-hosted projects 
.fpc 719
https://pagure.io/packaging-committee/issue/719

#topic #723 Guidelines for handling deprecated dependencies during
review 
.fpc 723
https://pagure.io/packaging-committee/issue/723

#topic #726 Review for SELinux Independent Policy packaging Draft   
.fpc 726
https://pagure.io/packaging-committee/issue/726

= New business =

#topic #761 Modernize R guidelines  
.fpc 761
https://pagure.io/packaging-committee/issue/761

= 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

Help with strict-aliasing warning

[Orion Poplawski]

I'm getting:

/builddir/build/BUILD/gdl-0.9.8/src/basic_pro_jmg.cpp: In function 'void 
lib::linkimage(EnvT*)':
/builddir/build/BUILD/gdl-0.9.8/src/basic_pro_jmg.cpp:159:36: warning: 
dereferencing type-punned pointer will break strict-aliasing rules 
[-Wstrict-aliasing]

   (BaseGDL* &) dynFun[count_fun] =
^
  (BaseGDL*) dlsym(module[count], entryName.c_str());


dynFun is defined as:

  BaseGDL*(*dynFun[MAXNDLL/2])( EnvT* e);

This is all beyond me.  Missing the function pointer argument specification?

Thanks.

--
Orion Poplawski
Manager of NWRA Technical Systems  720-772-5637
NWRA, Boulder/CoRA Office FAX: 303-415-9702
3380 Mitchell Lane   or...@nwra.com
Boulder, CO 80301 https://www.nwra.com/
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

[Bug 1401482] biber-2.11 is available

[bugzilla]

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



--- Comment #21 from Colin Macdonald  ---
Thanks!

I found a way to test on
https://fedoraproject.org/wiki/Test_Machine_Resources_For_Package_Maintainers

Unfortunately, build-in tests are disabled :(

I have pushed to rawhide, will do F28 later.

I forgot to check your copr for changes; will try to do that later too.

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

[EPEL-devel] Re: RHEL 7.5 fallout

[Kevin Fenzi]

On 04/11/2018 03:29 PM, Orion Poplawski wrote:
> These were koschei builds of my epel7 packages.  Seems to have cleared up now
> though so perhaps just an import issue.
> 
> On 04/10/2018 08:18 AM, Stephen John Smoogen wrote:
>> Do you have any information that htis is EPEL packages or just EL7.5 items?
>>
>> On 10 April 2018 at 09:57, Orion Poplawski  wrote:
>>> I'm seeing this in the root.log of some packages:
>>>
>>> DEBUG util.py:439:  Error: initscripts conflicts with
>>> 1:redhat-release-server-7.4-1.x86_64

This was caused by us not updating the local redhat-release-server
version we built in epel7. Why, you might ask did we do such a thing?
It's because aarch64 came in with a newer redhat-release-server that set
the dist tag to 'el7a'. Since we did not want all epel7 builds to be
el7a, we built a newer one in epel7-build with that set back.

Ideally we would come up with a better solution here, possibly in
epel-release so we don't need to rebuild this weird package every RHEL
release.

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

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

[updates]

The following Fedora EPEL 7 Security updates need testing:
 Age  URL
  19  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-1fbdf7f103   
chromium-65.0.3325.181-1.el7
  13  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-2074629ed3   
drupal7-7.58-1.el7
  12  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-e12bc7bed5   
nodejs-6.14.0-1.el7 libuv-1.19.2-1.el7
   8  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-7c95e7ac21   
libofx-0.9.9-2.el7
   7  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-13062a4d15   
wordpress-4.9.5-1.el7
   7  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-e56f478565   
koji-1.15.1-1.el7
   5  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-9f8e93d154   
python-jwt-1.6.1-1.el7
   4  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-2c81054303   
remctl-3.14-1.el7


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

bindfs-1.13.9-1.el7
fleet-commander-admin-0.10.7-1.el7
fleet-commander-client-0.10.2-2.el7
gsi-openssh-7.4p1-2.el7
js-jsroot-5.4.1-1.el7
knot-2.6.6-1.el7
perl-DateTime-Format-Strptime-1.5400-2.el7
python-fedmsg-meta-fedora-infrastructure-0.24.1-1.el7
rpkg-1.53-1.el7

Details about builds:



 bindfs-1.13.9-1.el7 (FEDORA-EPEL-2018-3ee539fee7)
 Fuse filesystem to mirror a directory

Update Information:

- update to new version 1.13.9 + spec cleanup / modernization




 fleet-commander-admin-0.10.7-1.el7 (FEDORA-EPEL-2018-fe7d422e12)
 Fleet Commander

Update Information:

Updated to release 0.10.7




 fleet-commander-client-0.10.2-2.el7 (FEDORA-EPEL-2018-ed3db39416)
 Fleet Commander Client

Update Information:

Fixed building dependencies




 gsi-openssh-7.4p1-2.el7 (FEDORA-EPEL-2018-4265d81756)
 An implementation of the SSH protocol with GSI authentication

Update Information:

Sync with openssh update.




 js-jsroot-5.4.1-1.el7 (FEDORA-EPEL-2018-7065dfe074)
 JavaScript ROOT - Interactive numerical data analysis graphics

Update Information:

## Changes in 5.4.1 1. Fix - monitoring mode in draw.htm page 2. Fix - zooming
in colz palette 3. Fix - support both 9.x and 10.x jsdom version in Node.js
(#149) 4. Fix - draw axis main line with appropriate attributes (#150) 5. Fix -
use axis color when drawing grids lines (#150) 6. Fix - when set pad logx/logy,
reset existing user ranges in pad 7. Fix - avoid too deep calling stack when
drawing many graphs or histos (#154) 8. Fix - correctly (re)draw tooltips on
canvas with many subpads




 knot-2.6.6-1.el7 (FEDORA-EPEL-2018-a356b81e75)
 High-performance authoritative DNS server

Update Information:

Knot DNS 2.6.6 (2018-04-11) ===  Features: -  -
New EDNS option counters in the statistics module  - New '+orphan' filter for
the 'zone-purge' operation  Improvements: -  - Reduced memory
consuption of disabled statistics metrics  - Some spelling fixes (Thanks to
Daniel Kahn Gillmor)  - Server no longer fails to start if MODULE_DIR doesn't
exist  - Configuration include doesn't fail if empty wildcard match  - Added a
configuration check for a problematical option combination  Bugfixes: -
- NSEC3 chain not re-created when SOA minimum TTL changed  - Failed to start
server if no template is configured  - Possibly incorrect SOA serial upon
changed zone reload with DNSSEC signing  - Inaccurate outgoing zone transfer
size in the log message  - Invalid dname compression if empty question section
- Missing EDNS in EMALF responses

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

[updates]

The following Fedora EPEL 6 Security updates need testing:
 Age  URL
  13  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-e4e96fbf3f   
drupal7-7.58-1.el6
   7  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-b5d9f8f571   
wordpress-4.9.5-1.el6
   7  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-870a92fcc5   
koji-1.15.1-1.el6
   4  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-5aca1d385d   
remctl-3.14-1.el6
   2  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-158680d651   
python-gunicorn-18.0-2.el6
   1  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-dd6e4a3f0b   
python34-3.4.8-1.el6


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

python-fedmsg-meta-fedora-infrastructure-0.24.1-1.el6
rpkg-1.53-1.el6
voms-clients-java-3.3.0-2.el6

Details about builds:



 python-fedmsg-meta-fedora-infrastructure-0.24.1-1.el6 
(FEDORA-EPEL-2018-527225181e)
 Metadata providers for Fedora Infrastructure's fedmsg deployment

Update Information:

Update to 0.24.1  Changelog is at: https://github.com/fedora-
infra/fedmsg_meta_fedora_infrastructure/blob/develop/CHANGELOG.rst#0241




 rpkg-1.53-1.el6 (FEDORA-EPEL-2018-7f16b8d5df)
 Python library for interacting with rpm+git

Update Information:

- Use NSVs and not build IDs with module-build-local --add-local-build (mprahl)
- Fix docstring of test_module_build_local_with_skiptests (mprahl) - Add
long_description to package (cqi) - Support local module builds when there are
uncommitted changes (mprahl) - Fix clarifying error that occurs when mbs-manager
is not installed (mprahl) - Add support for Module Stream Expansion (MBS API v2)
(mprahl) - Show errors when a module build fails (mprahl) - Move full download
url construction to separate method (frostyx) - Fix compose related params for
container-build (lucarval) - Avoid calling /usr/bin/python in tests (miro) -
Change default rpmlint configuration file (athoscr) - Use
koji.grab_session_options() rather than opencoding it (cfergeau)




 voms-clients-java-3.3.0-2.el6 (FEDORA-EPEL-2018-01eb003c2c)
 Virtual Organization Membership Service Java clients

Update Information:

Add trigger scriptlet to put back alternatives when UMD voms-clients3 is
removed.

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

[Bug 1401482] biber-2.11 is available

[bugzilla]

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



--- Comment #20 from Miro Hrončok  ---
Perl version problems on f28. Nevertheless:

nothing provides texlive-biblatex >= 7:2017 needed by biber-2.7-1.fc28.noarch

My texlive-biblatex is 7:svn42680-1.fc28

-- 
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 1401482] biber-2.11 is available

[bugzilla]

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



--- Comment #19 from Colin Macdonald  ---
Test on F28 would be fine? You can get the rpm file from the link I pasted
above

-- 
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 1551668] perl-Verilog-Perl-3.448-1.fc29 FTBFS: t/ 35_sigparser.t crashes

[bugzilla]

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

Filipe Rosset  changed:

   What|Removed |Added

 CC||rosset.fil...@gmail.com



--- Comment #2 from Filipe Rosset  ---
reported upstream
https://www.veripool.org/issues/1299-Verilog-Perl-perl-Verilog-Perl-3-448-fails-on-test-t-35_sigparser-t

-- 
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 1560182] Concurrent Gtk2::Unique execution causes shutter to crash

[bugzilla]

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



--- Comment #13 from Fedora Update System  ---
perl-Gtk2-Unique-0.05-23.fc28 has been pushed to the Fedora 28 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-2018-a7e8520db9

-- 
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 1560182] Concurrent Gtk2::Unique execution causes shutter to crash

[bugzilla]

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



--- Comment #12 from Fedora Update System  ---
perl-Gtk2-Unique-0.05-22.fc27 has been pushed to the Fedora 27 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-2018-93d73fbeb9

-- 
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 1401482] biber-2.11 is available

[bugzilla]

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



--- Comment #18 from Miro Hrončok  ---
Me neither. Building in
https://copr.fedorainfracloud.org/coprs/churchyard/texlive/

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

[EPEL-devel] Re: RHEL 7.5 fallout

[Orion Poplawski]

These were koschei builds of my epel7 packages.  Seems to have cleared up now
though so perhaps just an import issue.

On 04/10/2018 08:18 AM, Stephen John Smoogen wrote:
> Do you have any information that htis is EPEL packages or just EL7.5 items?
> 
> On 10 April 2018 at 09:57, Orion Poplawski  wrote:
>> I'm seeing this in the root.log of some packages:
>>
>> DEBUG util.py:439:  Error: initscripts conflicts with
>> 1:redhat-release-server-7.4-1.x86_64
>>
>> --
>> Orion Poplawski
>> Manager of NWRA Technical Systems  720-772-5637
>> NWRA, Boulder/CoRA Office FAX: 303-415-9702
>> 3380 Mitchell Lane   or...@nwra.com
>> Boulder, CO 80301 https://www.nwra.com/
>> ___
>> epel-devel mailing list -- epel-devel@lists.fedoraproject.org
>> To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org
> 
> 
> 


-- 
Orion Poplawski
Manager of NWRA Technical Systems  720-772-5637
NWRA, Boulder/CoRA Office FAX: 303-415-9702
3380 Mitchell Lane   or...@nwra.com
Boulder, CO 80301 https://www.nwra.com/
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org

Re: libqalculate soname change

[Mukundan Ragavan]

Since 2.4.0 is out, soname change will be to libqalculate.so.16. I will submit 
pull requests for the affected packages. I might miss F28.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: [EPEL-devel] Re: Ansible in EL7

[Nico Kadel-Garcia]

On Wed, Apr 11, 2018 at 11:07 AM, Stephen John Smoogen  wrote:
> On 11 April 2018 at 10:02, Nico Kadel-Garcia  wrote:
>> On Wed, Apr 11, 2018 at 4:43 AM, Alexander Bokovoy  
>> wrote:
>>
>>> I'm not in Ansible engineering or product management so take this with a
>>> grain of salt. My understanding is that cadence of Ansible releases and
>>> its aggressiveness in API changes makes it a bit less suitable to follow
>>> a traditional RHEL 7 release cadence. A separate product channel allows
>>> them to update packages at own cadence.
>>>
>>> I wonder how re-packaging for CentOS targets could happen with this
>>> approach and probably moving it back to EPEL7 is indeed something that
>>> makes more sense.
>>
>> Wouldn't a separate RHEL channel for a separate product, such as
>> ansible, mean a separate channel for CentOS to avoid precisely this
>> confusion? Mixing it into EPEL and having it on a separate RHEL
>> channel would be *bad* for anyone who activates that separate channel.
>> They'd have to filter it out of EPEL to ensure that the streams don't
>> get crossed on any updates from Red Hat. I understand that this is one
>> of the main reasons EPEL never carries packages that overlap with RHEL
>> published software.
>
> It is a lot more nuanced than that. EPEL builds packages that do not
> overlap with the following channels:
>
>
> rhel-7-server-extras-rpms/
> rhel-7-server-optional-rpms/
> rhel-7-server-rpms/
> rhel-ha-for-rhel-7-server-rpms/
> rhel-server-rhscl-7-rpms/
>
> These are chosen because they were the base set originally and other
> channels which might be available can have items which conflict with
> each other. This means that EPEL can conflict with somethings inside
> of "RHEL" but so can things are in "RHEL".

EPEL is a default, critical requirement for many tools, including Chef
and mock. Many environments running RHEL or CentOS 6 could not be used
without EPEL's plethora of useful tools. RHEL channels can conflict
with each other because they are enabled on an individual host, case
by case basis. I think, from old experiences, that having *anything*
in EPEL that overlaps with any RHEL published channel is begging for
pain.

It may cause pain to current RHEL ansible users, but I think that the
EPEL package needs to be renamed to something like "ansible25" to
avoid conflicts with the RHEL channel.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

[Bug 1560182] Concurrent Gtk2::Unique execution causes shutter to crash

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|MODIFIED|ON_QA



--- Comment #11 from Fedora Update System  ---
perl-Gtk2-Unique-0.05-19.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-2018-c6eb0045b6

-- 
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 1401482] biber-2.11 is available

[bugzilla]

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



--- Comment #17 from Colin Macdonald  ---
Here's a bump with tests disabled.  Can you test if its functional?  I don't
have  a rawhide system

https://koji.fedoraproject.org/koji/taskinfo?taskID=26313474

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

[EPEL-devel] Re: Ansible in EL7

[James Hogarth]

On 11 April 2018 at 20:32, Dylan Silva  wrote:
> I am very afraid I am jumping into a lion's den here... However, I am going 
> to try to alleviate some concerns.
>
> Our move from EPEL to Extras was actually to solve for the needs of RHEL and 
> the RHEL System Roles.  We needed to be in a channel that customers could 
> consume from that wasn't EPEL.
>
> Upon our move to Extras, we immediately identified a problem.  That problem 
> was, we Ansible, were not able to release as often as we preferred/needed for 
> our customers.  We also were facing confusion about what did support mean 
> once a package was inside of Extras.
>
> As such, we made the decision to two things.
>
> 1. Deprecate Ansible from Extras.
> 2. Provide access to Ansible via a Red Hat trusted delivery mechanism.
>
> For #2, EPEL obviously is not the route to take for some customers.  So, we 
> decided that all RHEL customers would have full access to the Subscription 
> channel.  We also specified that if a customer wanted support, they would 
> still need to purchase a subscription.
>
> We had a very delicate situation here.  There were a lot of check and 
> balances that had to be met before we could make any announcement. So that's 
> why it has been "a little quiet."
>
> The security advisory link posted above, and this link 
>  attempt to cover the bulk of the 
> possible questions that may arise.
>
> That being said, we still aim to provide our customers/users the ability to 
> obtain Ansible any way they choose.  So if the user does not want to use the 
> channel or cannot use it for any reason, they still have the ability to pull 
> from EPEL or our releases.ansible.com pages. As far as we're concerned, it is 
> functionally the same application no matter where it comes from.. If a 
> customer has a subscription; they will be supported.
>
> I, the Product Manager of Ansible Engine, am staying on top of these concerns 
> as they come by.  So far, no huge customer/user concerns have caused any 
> alarm.  Most users have embraced the moves, and have continued to automate.

Thank you very much for joining the conversation.

It's a significant relief that from your point of view it doesn't
matter where it comes from.

For what it is worth we (speaking somewhat on behalf of my team but
not as a spokesperson of the company I'm presently contracted at)
prefer it to come from EPEL, and are grateful to see it return there
from extras for a variety of reasons.

We are also very grateful for your preview/nightly repositories and
plan in our CI environment to take advantage of these in a more
aggressive fashion to catch regressions early that may affect us so we
can report them upstream ASAP in future.

It's useful and refreshing to get some of the background of the
decisions made, and though communication wasn't great, it's all nice
and plain for people to find in the archives and we can move forward
in a positive fashion as a community :)

Now ... time to go through a few dozen roles switching out 'with_*'
for 'loop' and fixing up 'when' conditionals ... got to hurry before
2.9 appears :)
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org

Re: New gdl segfaults with gcc 8 in antlr

[Orion Poplawski]

On 03/28/2018 12:56 PM, John Reiser wrote:
>> I've just discovered that gdl appears to be segfaulting a lot now deep in
>> the antlr c++ generated parser code with the switch to gcc 8.
> 
> A bugzilla report would be nice.  Run under gdb, report register contents
> and the instruction stream surrounding $pc, etc.  Also any clues
> about the corresponding location in the source code.
> 
> Is the SIGSEGV deterministic (reproducible every time) or random?
> Does memcheck (valgrind --track-origins=yes) complain?

It's entirely reproducible.  I've filed
https://bugzilla.redhat.com/show_bug.cgi?id=1566242 with what I can glean.

I don't understand the backtrace though.  Seems like a destructor is getting
called when initializing a class variable.  Very strange to me, but I'm no C++
expert.

-- 
Orion Poplawski
Manager of NWRA Technical Systems  720-772-5637
NWRA, Boulder/CoRA Office FAX: 303-415-9702
3380 Mitchell Lane   or...@nwra.com
Boulder, CO 80301 https://www.nwra.com/
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Fedora 28-20180411.n.0 compose check report

[Fedora compose checker]

No missing expected images.

Failed openQA tests: 4/137 (x86_64), 5/23 (i386), 1/2 (arm)

ID: 220589  Test: x86_64 Server-boot-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/220589
ID: 220592  Test: x86_64 Server-dvd-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/220592
ID: 220604  Test: x86_64 Server-dvd-iso base_update_cli
URL: https://openqa.fedoraproject.org/tests/220604
ID: 220634  Test: i386 Workstation-boot-iso memory_check
URL: https://openqa.fedoraproject.org/tests/220634
ID: 220635  Test: i386 Workstation-boot-iso install_default
URL: https://openqa.fedoraproject.org/tests/220635
ID: 220649  Test: arm Minimal-raw_xz-raw.xz 
install_arm_image_deployment_upload
URL: https://openqa.fedoraproject.org/tests/220649
ID: 220689  Test: x86_64 universal install_xfs@uefi
URL: https://openqa.fedoraproject.org/tests/220689
ID: 220734  Test: i386 universal install_simple_encrypted
URL: https://openqa.fedoraproject.org/tests/220734
ID: 220743  Test: i386 universal upgrade_desktop_32bit
URL: https://openqa.fedoraproject.org/tests/220743
ID: 220746  Test: i386 universal install_package_set_kde
URL: https://openqa.fedoraproject.org/tests/220746

Soft failed openQA tests: 8/137 (x86_64), 2/23 (i386)
(Tests completed, but using a workaround for a known bug)

ID: 220599  Test: x86_64 Server-dvd-iso server_realmd_join_kickstart
URL: https://openqa.fedoraproject.org/tests/220599
ID: 220612  Test: i386 Server-boot-iso install_default
URL: https://openqa.fedoraproject.org/tests/220612
ID: 220613  Test: i386 Server-dvd-iso install_default
URL: https://openqa.fedoraproject.org/tests/220613
ID: 220653  Test: x86_64 AtomicWorkstation-dvd_ostree-iso 
install_default_upload
URL: https://openqa.fedoraproject.org/tests/220653
ID: 220657  Test: x86_64 AtomicWorkstation-dvd_ostree-iso 
install_default@uefi
URL: https://openqa.fedoraproject.org/tests/220657
ID: 220659  Test: x86_64 AtomicWorkstation-dvd_ostree-iso install_no_user
URL: https://openqa.fedoraproject.org/tests/220659
ID: 220673  Test: x86_64 universal install_asian_language
URL: https://openqa.fedoraproject.org/tests/220673
ID: 220690  Test: x86_64 universal upgrade_server_domain_controller
URL: https://openqa.fedoraproject.org/tests/220690
ID: 220696  Test: x86_64 universal upgrade_realmd_client
URL: https://openqa.fedoraproject.org/tests/220696
ID: 220719  Test: x86_64 universal install_iscsi
URL: https://openqa.fedoraproject.org/tests/220719

Passed openQA tests: 125/137 (x86_64), 16/23 (i386)

Skipped openQA tests: 1 of 162
-- 
Mail generated by check-compose:
https://pagure.io/fedora-qa/check-compose
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Fedora-Atomic 27-20180411.1 compose check report

[Fedora compose checker]

No missing expected images.

Passed openQA tests: 2/2 (x86_64)
-- 
Mail generated by check-compose:
https://pagure.io/fedora-qa/check-compose
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Python 2 will be replaced with Python 3 in the next RHEL major release

[Jason L Tibbitts III]

> "RG" == Raphael Groner  writes:

RG> what to do with packages that can not be ported to python3?

Can anything really not be ported to python3?  I suppose if there was
something which messed with the internals of the python interpreter in
some way then that would potentially never be portable to python3, but
instances of that should be quite rare.

If the software is dead upstream, or upstream truly does not want to
port to python2, nobody wants to do the port or the Fedora maintainer
simply does not wish to carry patches to make things work with python3
and python2 is no longer in the distribution then... what else can be
done besides dropping the software?

Eventually all Linux distributions will have to do the same, or will
have to carry (or share) the burden of maintaining the python2
interpreter.  Software which requires python2 will become increasingly
difficult to use and I imagine that most authors would want to see their
software ported rather than have it become increasingly difficult to use
without the user having to build or obtain their own python2
interpreter.

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

Re: Python 2 will be replaced with Python 3 in the next RHEL major release

[Kevin Kofler]

Miro Hrončok wrote:
> This is important for those who like to maintain a single spec for
> everything. Previously, there have been messages on the devel list that
> encouraged people to change the python3 conditional from "if fedora" to
> "if fedora or rhel > 7" [5]. Please make a note that it will not be that
> simple, because you'll also need to add conditionals for python2, see
> for example already mentioned [3] or [4].

Well, python2 could simply be branched for EPEL.

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

[EPEL-devel] Re: Ansible in EL7

[Dylan Silva]

I am very afraid I am jumping into a lion's den here... However, I am going to 
try to alleviate some concerns.

Our move from EPEL to Extras was actually to solve for the needs of RHEL and 
the RHEL System Roles.  We needed to be in a channel that customers could 
consume from that wasn't EPEL. 

Upon our move to Extras, we immediately identified a problem.  That problem 
was, we Ansible, were not able to release as often as we preferred/needed for 
our customers.  We also were facing confusion about what did support mean once 
a package was inside of Extras.  

As such, we made the decision to two things. 

1. Deprecate Ansible from Extras.
2. Provide access to Ansible via a Red Hat trusted delivery mechanism. 

For #2, EPEL obviously is not the route to take for some customers.  So, we 
decided that all RHEL customers would have full access to the Subscription 
channel.  We also specified that if a customer wanted support, they would still 
need to purchase a subscription. 

We had a very delicate situation here.  There were a lot of check and balances 
that had to be met before we could make any announcement. So that's why it has 
been "a little quiet."

The security advisory link posted above, and this link 
 attempt to cover the bulk of the 
possible questions that may arise. 

That being said, we still aim to provide our customers/users the ability to 
obtain Ansible any way they choose.  So if the user does not want to use the 
channel or cannot use it for any reason, they still have the ability to pull 
from EPEL or our releases.ansible.com pages. As far as we're concerned, it is 
functionally the same application no matter where it comes from.. If a customer 
has a subscription; they will be supported. 

I, the Product Manager of Ansible Engine, am staying on top of these concerns 
as they come by.  So far, no huge customer/user concerns have caused any alarm. 
 Most users have embraced the moves, and have continued to automate. 
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org

Re: Python 2 will be replaced with Python 3 in the next RHEL major release

[Raphael Groner]

Hi Miro,

what to do with packages that can not be ported to python3?

For instance ecryptfs-utils … an orphan process will also orphan some 
dependencies like ecryptfs-simple etc.
And therefore sirikali is going to loose some of its features that are 
available by help from ecryptfs tools.

RFE ecryptfs-utils: Add a Python 3 subpackage - 
https://bugzilla.redhat.com/1458602

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

[Bug 1563022] perl-CPAN-Perl-Releases-3.52 is available

[bugzilla]

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



--- Comment #9 from Fedora Update System  ---
perl-CPAN-Perl-Releases-3.52-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

Fedora 28 compose report: 20180411.n.0 changes

[Fedora Branched Report]

OLD: Fedora-28-20180410.n.1
NEW: Fedora-28-20180411.n.0

= SUMMARY =
Added images:0
Dropped images:  3
Added packages:  5
Dropped packages:1
Upgraded packages:   93
Downgraded packages: 0

Size of added packages:  11.45 MiB
Size of dropped packages:9.25 MiB
Size of upgraded packages:   904.27 MiB
Size of downgraded packages: 0 B

Size change of upgraded packages:   -80.53 MiB
Size change of downgraded packages: 0 B

= ADDED IMAGES =

= DROPPED IMAGES =
Image: AtomicHost raw-xz ppc64le
Path: AtomicHost/ppc64le/images/Fedora-AtomicHost-28-20180410.n.1.ppc64le.raw.xz
Image: Container_Base docker s390x
Path: Container/s390x/images/Fedora-Container-Base-28-20180410.n.1.s390x.tar.xz
Image: AtomicHost qcow2 ppc64le
Path: AtomicHost/ppc64le/images/Fedora-AtomicHost-28-20180410.n.1.ppc64le.qcow2

= ADDED PACKAGES =
Package: R-deldir-0.1.14-1.fc28
Summary: Delaunay Triangulation and Dirichlet (Voronoi) Tessellation
RPMs:R-deldir
Size:1.39 MiB

Package: ghc-cabal-helper-0.8.0.2-1.fc28
Summary: Simple interface to some of Cabal's configuration state, mainly used 
by ghc-mod
RPMs:ghc-cabal-helper ghc-cabal-helper-devel
Size:4.14 MiB

Package: mypaint-brushes-1.3.0-1.fc28
Summary: Brushes to be used with the MyPaint library
RPMs:mypaint-brushes mypaint-brushes-devel
Size:2.32 MiB

Package: python-cookiecutter-1.6.0-2.fc28
Summary: CLI utility to create projects from templates
RPMs:python-cookiecutter-doc python2-cookiecutter python3-cookiecutter
Size:1.62 MiB

Package: python-pycares-2.3.0-2.fc28
Summary: Python interface for c-ares
RPMs:python-pycares-doc python2-pycares python3-pycares
Size:1.98 MiB


= DROPPED PACKAGES =
Package: mozjs17-17.0.0-22.fc28
Summary: JavaScript interpreter and libraries
RPMs:mozjs17 mozjs17-devel
Size:9.25 MiB


= UPGRADED PACKAGES =
Package:  Zim-0.68-1.fc28
Old package:  Zim-0.67-4.fc28
Summary:  Desktop wiki & notekeeper
RPMs: Zim
Size: 1.82 MiB
Size change:  4.43 KiB
Changelog:
  * Mon Apr 02 2018 Robin Lee <cheese...@fedoraproject.org> - 0.68-1
  - Update to 0.68


Package:  authselect-0.4-1.fc28
Old package:  authselect-0.3.2-1.fc28
Summary:  Configures authentication and identity sources from supported 
profiles
RPMs: authselect authselect-compat authselect-devel authselect-libs
Size: 808.26 KiB
Size change:  10.87 KiB
Changelog:
  * Mon Apr 09 2018 Pavel B??ezina <pbrez...@redhat.com> - 0.4-1
  - rebasing to 0.4


Package:  cargo-0.26.0-2.fc28
Old package:  cargo-0.25.0-1.fc28
Summary:  Rust's package manager and build tool
RPMs: cargo cargo-doc
Size: 15.70 MiB
Size change:  406.24 KiB
Changelog:
  * Mon Apr 02 2018 Josh Stone <jist...@redhat.com> - 0.26.0-1
  - Update to 0.26.0.

  * Mon Apr 02 2018 Josh Stone <jist...@redhat.com> - 0.26.0-2
  - Use an HTML redirect for docs instead of the dir-symlink replacement.


Package:  certbot-0.23.0-1.fc28
Old package:  certbot-0.22.2-1.fc28
Summary:  A free, automated certificate authority client
RPMs: certbot python2-certbot python3-certbot
Size: 994.80 KiB
Size change:  1.86 KiB
Changelog:
  * Thu Apr 05 2018 Eli Young <elysc...@gmail.com> - 0.23.0-1
  - Update to 0.23.0 (#1563899)


Package:  containerd-1.0.3-1.fc28
Old package:  containerd-1.0.1-1.fc28
Summary:  An industry-standard container runtime
RPMs: containerd
Size: 68.05 MiB
Size change:  132.57 KiB
Changelog:
  * Wed Feb 07 2018 Fedora Release Engineering <rel...@fedoraproject.org> - 
1.0.1-2
  - Rebuilt for https://fedoraproject.org/wiki/Fedora_28_Mass_Rebuild

  * Wed Apr 04 2018 Carl George <carl@george.computer> - 1.0.3-1
  - Latest upstream


Package:  criu-3.8.1-1.fc28
Old package:  criu-3.7-5.fc28
Summary:  Tool for Checkpoint/Restore in User-space
RPMs: crit criu criu-devel python2-criu
Size: 3.12 MiB
Size change:  47.42 KiB
Changelog:
  * Wed Mar 14 2018 Adrian Reber <adr...@lisas.de> - 3.8-1
  - Update to 3.8

  * Thu Mar 22 2018 Adrian Reber <adr...@lisas.de> - 3.8-2
  - Bump release for COPR

  * Tue Apr 03 2018 Adrian Reber <adr...@lisas.de> - 3.8.1-1
  - Update to 3.8.1


Package:  datagrepper-0.9.3-1.fc28
Old package:  datagrepper-0.9.1-2.fc28
Summary:  A webapp to query fedmsg history
RPMs: datagrepper
Size: 116.24 KiB
Size change:  24 B
Changelog:
  * Mon Mar 12 2018 Ralph Bean <rb...@redhat.com> - 0.9.3-1
  - new version


Package:  datanommer-commands-0.7.2-1.fc28
Old package:  datanommer-commands-0.7.0-3.fc28
Summary:  Console commands for datanommer
RPMs: datanommer-commands
Size: 30.40 KiB
Size change:  636 B
Changelog:
  * Thu Mar 01 2018 Iryna Shcherbina <ishch...@redhat.com> - 0.7.0-4
  - Update Python 2 dependency declarations to new packaging standards
(See 

Package Joplin - FLOSS todo/notes app with NextCloud integration

[rugk]

Hi,
I saw Joplin[1], which recently got NextCloud integration[2], is not packaged 
in Fedora. Maybe one could do so?

Best regards,
rugk

[1] https://joplin.cozic.net/
[2] 
https://nextcloud.com/blog/mobile-note-taking-with-your-private-cloud-announcing-joplinnextcloud-integration/
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

[Bug 1563022] perl-CPAN-Perl-Releases-3.52 is available

[bugzilla]

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



--- Comment #8 from Fedora Update System  ---
perl-CPAN-Perl-Releases-3.52-1.fc27 has been pushed to the Fedora 27 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

[EPEL-devel] Re: Ansible in EL7

[Stephen John Smoogen]

On 11 April 2018 at 10:02, Nico Kadel-Garcia  wrote:
> On Wed, Apr 11, 2018 at 4:43 AM, Alexander Bokovoy  
> wrote:
>
>> I'm not in Ansible engineering or product management so take this with a
>> grain of salt. My understanding is that cadence of Ansible releases and
>> its aggressiveness in API changes makes it a bit less suitable to follow
>> a traditional RHEL 7 release cadence. A separate product channel allows
>> them to update packages at own cadence.
>>
>> I wonder how re-packaging for CentOS targets could happen with this
>> approach and probably moving it back to EPEL7 is indeed something that
>> makes more sense.
>
> Wouldn't a separate RHEL channel for a separate product, such as
> ansible, mean a separate channel for CentOS to avoid precisely this
> confusion? Mixing it into EPEL and having it on a separate RHEL
> channel would be *bad* for anyone who activates that separate channel.
> They'd have to filter it out of EPEL to ensure that the streams don't
> get crossed on any updates from Red Hat. I understand that this is one
> of the main reasons EPEL never carries packages that overlap with RHEL
> published software.

It is a lot more nuanced than that. EPEL builds packages that do not
overlap with the following channels:


rhel-7-server-extras-rpms/
rhel-7-server-optional-rpms/
rhel-7-server-rpms/
rhel-ha-for-rhel-7-server-rpms/
rhel-server-rhscl-7-rpms/

These are chosen because they were the base set originally and other
channels which might be available can have items which conflict with
each other. This means that EPEL can conflict with somethings inside
of "RHEL" but so can things are in "RHEL".

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



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

Re: [EPEL-devel] Re: Ansible in EL7

[Stephen John Smoogen]

On 11 April 2018 at 10:02, Nico Kadel-Garcia  wrote:
> On Wed, Apr 11, 2018 at 4:43 AM, Alexander Bokovoy  
> wrote:
>
>> I'm not in Ansible engineering or product management so take this with a
>> grain of salt. My understanding is that cadence of Ansible releases and
>> its aggressiveness in API changes makes it a bit less suitable to follow
>> a traditional RHEL 7 release cadence. A separate product channel allows
>> them to update packages at own cadence.
>>
>> I wonder how re-packaging for CentOS targets could happen with this
>> approach and probably moving it back to EPEL7 is indeed something that
>> makes more sense.
>
> Wouldn't a separate RHEL channel for a separate product, such as
> ansible, mean a separate channel for CentOS to avoid precisely this
> confusion? Mixing it into EPEL and having it on a separate RHEL
> channel would be *bad* for anyone who activates that separate channel.
> They'd have to filter it out of EPEL to ensure that the streams don't
> get crossed on any updates from Red Hat. I understand that this is one
> of the main reasons EPEL never carries packages that overlap with RHEL
> published software.

It is a lot more nuanced than that. EPEL builds packages that do not
overlap with the following channels:


rhel-7-server-extras-rpms/
rhel-7-server-optional-rpms/
rhel-7-server-rpms/
rhel-ha-for-rhel-7-server-rpms/
rhel-server-rhscl-7-rpms/

These are chosen because they were the base set originally and other
channels which might be available can have items which conflict with
each other. This means that EPEL can conflict with somethings inside
of "RHEL" but so can things are in "RHEL".

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



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

Re: [EPEL-devel] Re: Ansible in EL7

[James Hogarth]

On 11 April 2018 at 15:02, Nico Kadel-Garcia  wrote:
> On Wed, Apr 11, 2018 at 4:43 AM, Alexander Bokovoy  
> wrote:
>
>> I'm not in Ansible engineering or product management so take this with a
>> grain of salt. My understanding is that cadence of Ansible releases and
>> its aggressiveness in API changes makes it a bit less suitable to follow
>> a traditional RHEL 7 release cadence. A separate product channel allows
>> them to update packages at own cadence.
>>
>> I wonder how re-packaging for CentOS targets could happen with this
>> approach and probably moving it back to EPEL7 is indeed something that
>> makes more sense.
>
> Wouldn't a separate RHEL channel for a separate product, such as
> ansible, mean a separate channel for CentOS to avoid precisely this
> confusion? Mixing it into EPEL and having it on a separate RHEL
> channel would be *bad* for anyone who activates that separate channel.
> They'd have to filter it out of EPEL to ensure that the streams don't
> get crossed on any updates from Red Hat. I understand that this is one
> of the main reasons EPEL never carries packages that overlap with RHEL
> published software.


The official EPEL policy with regards to conflicts is here:

https://fedoraproject.org/wiki/EPEL/FAQ#Does_EPEL_replace_packages_provided_within_Red_Hat_Enterprise_Linux_or_layered_products.3F

So technically, we aren't against policy here... it is a confusing
situation that will require careful config to get the "correct"
ansible for RHEL users though.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: [EPEL-devel] Re: Ansible in EL7

[Nico Kadel-Garcia]

On Wed, Apr 11, 2018 at 4:43 AM, Alexander Bokovoy  wrote:

> I'm not in Ansible engineering or product management so take this with a
> grain of salt. My understanding is that cadence of Ansible releases and
> its aggressiveness in API changes makes it a bit less suitable to follow
> a traditional RHEL 7 release cadence. A separate product channel allows
> them to update packages at own cadence.
>
> I wonder how re-packaging for CentOS targets could happen with this
> approach and probably moving it back to EPEL7 is indeed something that
> makes more sense.

Wouldn't a separate RHEL channel for a separate product, such as
ansible, mean a separate channel for CentOS to avoid precisely this
confusion? Mixing it into EPEL and having it on a separate RHEL
channel would be *bad* for anyone who activates that separate channel.
They'd have to filter it out of EPEL to ensure that the streams don't
get crossed on any updates from Red Hat. I understand that this is one
of the main reasons EPEL never carries packages that overlap with RHEL
published software.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

[EPEL-devel] Re: Ansible in EL7

[James Hogarth]

On 11 April 2018 at 14:30, Kevin Fenzi  wrote:
> On 04/11/2018 04:52 AM, James Hogarth wrote:
>
>>
>> Especially if EPEL7 now has a clash with an optional repo that is available
>> to all subscribers...
>>
>> There are priority or exclude filters people will need to add to their yum
>> repository configurations that they may not be otherwise aware of if they
>> want the "official Red Hat" build of it etc etc
>
> Well, it's available to all, but I would think you would have to enable
> it, but yes, an announcement would help people decide where to get
> ansible from.


Right ... but if someone wants to use the "supported" ansible as part
of their support contract, then given how common EPEL is on systems
they really do need to know that they must add an excludepkgs to their
EPEL yum configuration or alternatively alter priorities.

Otherwise it's going to be very "arbitrary" which ansible they get.
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org

[EPEL-devel] Re: Ansible in EL7

[Kevin Fenzi]

On 04/11/2018 04:52 AM, James Hogarth wrote:

> 
> Especially if EPEL7 now has a clash with an optional repo that is available
> to all subscribers...
> 
> There are priority or exclude filters people will need to add to their yum
> repository configurations that they may not be otherwise aware of if they
> want the "official Red Hat" build of it etc etc

Well, it's available to all, but I would think you would have to enable
it, but yes, an announcement would help people decide where to get
ansible from.

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

Re: [EPEL-devel] Re: Ansible in EL7

[Kevin Fenzi]

On 04/10/2018 11:05 PM, James Hogarth wrote:

> At this point, no offense to Nirik and the maintenance he does on the
> package, I'm actually tempted to just grab it from upstream directly at
> https://releases.ansible.com/ansible/rpm/

Feel free. Do whatever you feel is best for you.

> 
> At least then I can get consistency with selection of stable, preview or
> nightly ...

I don't really understand what you mean here... EPEL is going to pushing
stable releases... with 2 weeks in testing.

With 2.5.x upstream is going to try and do minor releases every 2-3weeks
with all bugfixes that are landed then. EPEL will package those.

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

[EPEL-devel] Re: Ansible in EL7

[Kevin Fenzi]

On 04/10/2018 11:05 PM, James Hogarth wrote:

> At this point, no offense to Nirik and the maintenance he does on the
> package, I'm actually tempted to just grab it from upstream directly at
> https://releases.ansible.com/ansible/rpm/

Feel free. Do whatever you feel is best for you.

> 
> At least then I can get consistency with selection of stable, preview or
> nightly ...

I don't really understand what you mean here... EPEL is going to pushing
stable releases... with 2 weeks in testing.

With 2.5.x upstream is going to try and do minor releases every 2-3weeks
with all bugfixes that are landed then. EPEL will package those.

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

[EPEL-devel] Re: Ansible in EL7

[Kevin Fenzi]

On 04/11/2018 02:04 AM, Peter Robinson wrote:
> There probably should be an announcement sent to the epel announce
> list then it gets to a wider audience so more people know this.

Yep. But the RH announcement only went out monday, and I am at a
hackfest this week. I'll try and get something out this week or early next.

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

F28 Self Contained Change: java-openjdk 10 - rolling release for Short Term Support releases of OpenJDK

[Jan Kurik]

This is a late proposal for F28 release, mostly to spread awareness of the
availability of java-openjdk 10 in Fedora. It is not closely tied to the
F28 release however it would be good to have this in the formal F28 scope.
That is the reason, why after a discussion with the Change owner, this is
announced as a Self Contained Change Proposal.

= Proposed Self Contained Change: java-openjdk 10 - rolling release for
Short Term Support  releases of OpenJDK =
https://fedoraproject.org/wiki/Changes/java-openjdk-10


Owner(s):
  * Jiri Vanek 


OpenJDK have release  cadence of 6 months. but 3/4 of them are Short Term
Supported for 6 months only.  This package is designed to harbore them.
Currently it is build on openJDK 10. LTSs (next is 11) will go as separate
packages.
See announcement:
http://mail.openjdk.java.net/pipermail/discuss/2017-September/004281.html
See java SIG plans:
https://jvanek.fedorapeople.org/devconf/2018/changesInjavaReleaseProcess.pdf



== Detailed description ==
JDK10 is next major release of Java platform.  It is bringing many cool
improvements - http://openjdk.java.net/projects/jdk/10/ and is landing to
your Fedora.  Where it will be maintained for f27 and newer.  Unluckily, it
is STS (short term support) version. Between individual LTS will be always
several STS. Again, please
See announcement:
http://mail.openjdk.java.net/pipermail/discuss/2017-September/004281.html
and See java SIG plans:
https://jvanek.fedorapeople.org/devconf/2018/changesInjavaReleaseProcess.pdf
.  So this is rolling release of all STSs to come. Its fate during the
release of fresh LTS is yet to be decided.
You will always be allowed to install  Used LTS in fedora build root,
alongside with latest  STS via alternatives.


== Scope ==
* Proposal owners:
This is isolated change. The maintainers of OpenJDK in Fedora must build
the binaries, and keep them working.  Still, to keep this rolling release
will be soem packaging challenge. Lets see this when JDK12  (or maybe
already 11) come out.

* Other developers:
Should slowly start to check theirs packages against JDK10

* Release engineering:
#7433 - https://pagure.io/releng/issue/7433

* List of deliverables:
N/A (not a System Wide Change)

* Policies and guidelines:
N/A (not a System Wide Change)

* Trademark approval:
N/A (not needed for this Change)
-- 
Jan Kuřík
Platform & Fedora Program Manager
Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

[Bug 1565607] perl-Class-Adapter-1.09 is available

[bugzilla]

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

Jitka Plesnikova  changed:

   What|Removed |Added

 Status|ASSIGNED|CLOSED
   Fixed In Version||perl-Class-Adapter-1.09-1.f
   ||c29
 Resolution|--- |RAWHIDE
Last Closed||2018-04-11 08:29:36



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

[EPEL-devel] Re: Ansible in EL7

[James Hogarth]

On Wed, 11 Apr 2018, 10:05 Peter Robinson,  wrote:

> On Wed, Apr 11, 2018 at 12:58 AM, Todd Zullinger  wrote:
> > James Hogarth wrote:
> >> I was under the impression that as of 2.4.0 in EL7 we removed ansible
> >> from EPEL7 since Red Hat included it in their extras repo, and EPEL
> >> policy is not to conflict.
> >>
> >> I was surprised just now to see ansible 2.5.0 on a test centos system,
> >> when it wasn't in extras, and on a little bit of a search found:
> >>
> >> https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-7ef392255b
> >>
> >> Of course this is a bit of an issue for CentOS/RHEL users that have
> >> need for the Red Hat ansible as they have been upgraded, and RH will
> >> need to epoch bump (or release 2.5.1 and we pull this from EPEL7 then)
> >> to ensure they get it from the right repo.
> >>
> >> With a branch retirement shouldn't this have been blocked in koji?
> >
> > Red Hat announced today that Ansible was being deprecated
> > from the extras channel.  Their advice is that those who
> > have "previously installed Ansible and its dependencies from
> > the Extras channel are advised to enable and update from the
> > Ansible Engine channel, or uninstall the packages as future
> > errata will not be provided from the Extras channel."
> >
> > https://access.redhat.com/errata/RHSA-2018:1075
> >
> > Given that, I believe it is reasonable to see ansible return
> > to EPEL.  This was discussed in previous EPEL meetings a
> > bit, so I'm sure it was known to at least some of the folks
> > involved.
>
> There probably should be an announcement sent to the epel announce
> list then it gets to a wider audience so more people know this.
>

Especially if EPEL7 now has a clash with an optional repo that is available
to all subscribers...

There are priority or exclude filters people will need to add to their yum
repository configurations that they may not be otherwise aware of if they
want the "official Red Hat" build of it etc etc

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

Re: [EPEL-devel] Re: Ansible in EL7

[James Hogarth]

On Wed, 11 Apr 2018, 10:05 Peter Robinson,  wrote:

> On Wed, Apr 11, 2018 at 12:58 AM, Todd Zullinger  wrote:
> > James Hogarth wrote:
> >> I was under the impression that as of 2.4.0 in EL7 we removed ansible
> >> from EPEL7 since Red Hat included it in their extras repo, and EPEL
> >> policy is not to conflict.
> >>
> >> I was surprised just now to see ansible 2.5.0 on a test centos system,
> >> when it wasn't in extras, and on a little bit of a search found:
> >>
> >> https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-7ef392255b
> >>
> >> Of course this is a bit of an issue for CentOS/RHEL users that have
> >> need for the Red Hat ansible as they have been upgraded, and RH will
> >> need to epoch bump (or release 2.5.1 and we pull this from EPEL7 then)
> >> to ensure they get it from the right repo.
> >>
> >> With a branch retirement shouldn't this have been blocked in koji?
> >
> > Red Hat announced today that Ansible was being deprecated
> > from the extras channel.  Their advice is that those who
> > have "previously installed Ansible and its dependencies from
> > the Extras channel are advised to enable and update from the
> > Ansible Engine channel, or uninstall the packages as future
> > errata will not be provided from the Extras channel."
> >
> > https://access.redhat.com/errata/RHSA-2018:1075
> >
> > Given that, I believe it is reasonable to see ansible return
> > to EPEL.  This was discussed in previous EPEL meetings a
> > bit, so I'm sure it was known to at least some of the folks
> > involved.
>
> There probably should be an announcement sent to the epel announce
> list then it gets to a wider audience so more people know this.
>

Especially if EPEL7 now has a clash with an optional repo that is available
to all subscribers...

There are priority or exclude filters people will need to add to their yum
repository configurations that they may not be otherwise aware of if they
want the "official Red Hat" build of it etc etc

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

[Bug 1565385] perl-HTML-FormFu-Model-DBIC-2.03 is available

[bugzilla]

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

Emmanuel Seyman  changed:

   What|Removed |Added

 Status|NEW |CLOSED
   Fixed In Version||perl-HTML-FormFu-Model-DBIC
   ||-2.03-2.fc29
 Resolution|--- |RAWHIDE
Last Closed||2018-04-11 07:45:04



--- Comment #1 from Emmanuel Seyman  ---
Okay, that was not fun...
https://koji.fedoraproject.org/koji/buildinfo?buildID=1068830

-- 
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: Fw: fedmsg notification

[Pierre-Yves Chibon]

On Mon, Apr 09, 2018 at 01:28:02PM +0200, Dominik 'Rathann' Mierzejewski wrote:
> On Monday, 09 April 2018 at 13:20, Pierre-Yves Chibon wrote:
> [...]
> > Finally the reason this has not been correctly announced is that we are 
> > still
> > investigating the capacity of the system and the pipeline to check if it can
> > handle the load of all the package in Fedora, but as said, the pipeline is
> > already sending messages to the production bus, thus this behavior :(
> 
> The obvious thing to do is to stop sending these messages to the
> production bus until fedmsg_meta is updated and the update pushed to
> production. Why hasn't this been done already?

The basic answer is that I didn't have the hand to do it.
So instead I released a new fedmsg-meta-fedora-infrastructure with support for
these messages and deployed it in production.
Messages about the allpackages pipeline should now make some sense :)


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

Re: Release rpkg-1.53

[Miroslav Suchý]

Dne 11.4.2018 v 04:34 Chenxiong Qi napsal(a):
> This is the first version delivering Python 3 package, which is
> python3-rpkg. Thanks Miro Hrončok for making the patch.

Is it possible to rename the source package to python-rpkg? (I will happily do 
the package review).

Because we have source package rpkg, which does have pythonX-rpkg, and no 
binary of /usr/bin/rpkg.

And then we have (currently under package review) source package rpkg-util, 
which create binary package rpkg, which
provides /usr/bin/rpkg
I guess that it can confuse some people.

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

[Bug 1560182] Concurrent Gtk2::Unique execution causes shutter to crash

[bugzilla]

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



--- Comment #10 from Fedora Update System  ---
perl-Gtk2-Unique-0.05-19.fc26 has been submitted as an update to Fedora 26.
https://bodhi.fedoraproject.org/updates/FEDORA-2018-c6eb0045b6

-- 
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 1560182] Concurrent Gtk2::Unique execution causes shutter to crash

[bugzilla]

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



--- Comment #9 from Fedora Update System  ---
perl-Gtk2-Unique-0.05-22.fc27 has been submitted as an update to Fedora 27.
https://bodhi.fedoraproject.org/updates/FEDORA-2018-93d73fbeb9

-- 
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 1560182] Concurrent Gtk2::Unique execution causes shutter to crash

[bugzilla]

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

Petr Pisar  changed:

   What|Removed |Added

   Fixed In Version||perl-Gtk2-Unique-0.05-23.fc
   ||29



-- 
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 1560182] Concurrent Gtk2::Unique execution causes shutter to crash

[bugzilla]

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



--- Comment #8 from Fedora Update System  ---
perl-Gtk2-Unique-0.05-23.fc28 has been submitted as an update to Fedora 28.
https://bodhi.fedoraproject.org/updates/FEDORA-2018-a7e8520db9

-- 
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 1565384] perl-HTML-FormFu-2.06 is available

[bugzilla]

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

Emmanuel Seyman  changed:

   What|Removed |Added

 Status|NEW |CLOSED
   Fixed In Version||perl-HTML-FormFu-2.06-1.fc2
   ||9
 Resolution|--- |RAWHIDE
Last Closed||2018-04-11 05:07:00



--- Comment #1 from Emmanuel Seyman  ---
Built for rawhide:
https://koji.fedoraproject.org/koji/buildinfo?buildID=1068764

-- 
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 1565864] perl-Mojolicious-7.75 is available

[bugzilla]

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

Emmanuel Seyman  changed:

   What|Removed |Added

 Status|NEW |CLOSED
   Fixed In Version||perl-Mojolicious-7.75-1.fc2
   ||9
 Resolution|--- |RAWHIDE
Last Closed||2018-04-11 05:06:15



--- Comment #1 from Emmanuel Seyman  ---
Built for rawhide:
https://koji.fedoraproject.org/koji/buildinfo?buildID=1068758

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

[EPEL-devel] Re: Ansible in EL7

[Peter Robinson]

On Wed, Apr 11, 2018 at 12:58 AM, Todd Zullinger  wrote:
> James Hogarth wrote:
>> I was under the impression that as of 2.4.0 in EL7 we removed ansible
>> from EPEL7 since Red Hat included it in their extras repo, and EPEL
>> policy is not to conflict.
>>
>> I was surprised just now to see ansible 2.5.0 on a test centos system,
>> when it wasn't in extras, and on a little bit of a search found:
>>
>> https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-7ef392255b
>>
>> Of course this is a bit of an issue for CentOS/RHEL users that have
>> need for the Red Hat ansible as they have been upgraded, and RH will
>> need to epoch bump (or release 2.5.1 and we pull this from EPEL7 then)
>> to ensure they get it from the right repo.
>>
>> With a branch retirement shouldn't this have been blocked in koji?
>
> Red Hat announced today that Ansible was being deprecated
> from the extras channel.  Their advice is that those who
> have "previously installed Ansible and its dependencies from
> the Extras channel are advised to enable and update from the
> Ansible Engine channel, or uninstall the packages as future
> errata will not be provided from the Extras channel."
>
> https://access.redhat.com/errata/RHSA-2018:1075
>
> Given that, I believe it is reasonable to see ansible return
> to EPEL.  This was discussed in previous EPEL meetings a
> bit, so I'm sure it was known to at least some of the folks
> involved.

There probably should be an announcement sent to the epel announce
list then it gets to a wider audience so more people know this.
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org

Re: [EPEL-devel] Ansible in EL7

[Peter Robinson]

On Wed, Apr 11, 2018 at 12:58 AM, Todd Zullinger  wrote:
> James Hogarth wrote:
>> I was under the impression that as of 2.4.0 in EL7 we removed ansible
>> from EPEL7 since Red Hat included it in their extras repo, and EPEL
>> policy is not to conflict.
>>
>> I was surprised just now to see ansible 2.5.0 on a test centos system,
>> when it wasn't in extras, and on a little bit of a search found:
>>
>> https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-7ef392255b
>>
>> Of course this is a bit of an issue for CentOS/RHEL users that have
>> need for the Red Hat ansible as they have been upgraded, and RH will
>> need to epoch bump (or release 2.5.1 and we pull this from EPEL7 then)
>> to ensure they get it from the right repo.
>>
>> With a branch retirement shouldn't this have been blocked in koji?
>
> Red Hat announced today that Ansible was being deprecated
> from the extras channel.  Their advice is that those who
> have "previously installed Ansible and its dependencies from
> the Extras channel are advised to enable and update from the
> Ansible Engine channel, or uninstall the packages as future
> errata will not be provided from the Extras channel."
>
> https://access.redhat.com/errata/RHSA-2018:1075
>
> Given that, I believe it is reasonable to see ansible return
> to EPEL.  This was discussed in previous EPEL meetings a
> bit, so I'm sure it was known to at least some of the folks
> involved.

There probably should be an announcement sent to the epel announce
list then it gets to a wider audience so more people know this.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: updates in stable branches introducing new dependencies

[Dominik 'Rathann' Mierzejewski]

On Wednesday, 11 April 2018 at 10:35, Michal Schorm wrote:
> For fetaures, that are optional, weak dependencies is the best solution I
> can think of.
> Even when "Recommends" is used, which means it will try to pull the
> dependency as well, if not said specifically opted-out.

That's fine. The optional dependency can be uninstalled afterwards or
not installed at all if you have install_weak_deps set to false.

> > 2 considerations:
> > * is the user experience significantly affected?
> > * is the size implications significant?
> > As far as I can tell, the answer to both is generally no.
> 
> For everything else, besides opt features, plugins, ... , I totally agree
> with the nice short answer from Rex.

So, you think the maintainers should be free to add any new dependencies
without any announcement or explanation as long as it doesn't "materially
affect the user or developer experience"?

I actually have nothing against adding new features, even in stable
branches, but I do object to lack of communication about those.

Regards,
Dominik
-- 
Fedora   https://getfedora.org  |  RPMFusion   http://rpmfusion.org
There should be a science of discontent. People need hard times and
oppression to develop psychic muscles.
-- from "Collected Sayings of Muad'Dib" by the Princess Irulan
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: [EPEL-devel] Re: Ansible in EL7

[Alexander Bokovoy]

On ti, 10 huhti 2018, Todd Zullinger wrote:

James Hogarth wrote:

On Wed, 11 Apr 2018, 00:59 Todd Zullinger,  wrote:

Red Hat announced today that Ansible was being deprecated
from the extras channel.  Their advice is that those who
have "previously installed Ansible and its dependencies from
the Extras channel are advised to enable and update from the
Ansible Engine channel, or uninstall the packages as future
errata will not be provided from the Extras channel."

https://access.redhat.com/errata/RHSA-2018:1075

Given that, I believe it is reasonable to see ansible return
to EPEL.  This was discussed in previous EPEL meetings a
bit, so I'm sure it was known to at least some of the folks
involved.


Cheers for the info.

It wasn't mentioned on the devel list, I didn't see it in the 7.5 release
notes and it was still in extras when I checked a short while ago.

In that case yes I agree it makes total sense to return to epel7

I wonder why they dropped it when the whole point of them bringing it in to
begin with was for Satellite and Tower to have it in the standard RHEL
repos.

Seems so pointless to have only had one release there!


Indeed, it was a bit strange.  Perhaps someone with more
insight into the rationale can comment.  I have no
particular knowledge of things, but maybe keeping a fast
moving project like ansible in even the RHEL extras channel
was a problem.

Maybe the plan with the move to the "Ansible Engine" channel
is to work closer with subscribers on migrating from version
to version.  And non-subscribers can just follow it in EPEL.

I'd be interested in hearing more about the change, though I
suspect those who know more either aren't on these lists or
can't say more than Red Hat's advisory has already.

I'm not in Ansible engineering or product management so take this with a
grain of salt. My understanding is that cadence of Ansible releases and
its aggressiveness in API changes makes it a bit less suitable to follow
a traditional RHEL 7 release cadence. A separate product channel allows
them to update packages at own cadence.

I wonder how re-packaging for CentOS targets could happen with this
approach and probably moving it back to EPEL7 is indeed something that
makes more sense.

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

Re: updates in stable branches introducing new dependencies

[Michal Schorm]

For fetaures, that are optional, weak dependencies is the best solution I
can think of.
Even when "Recommends" is used, which means it will try to pull the
dependency as well, if not said specifically opted-out.

> 2 considerations:
> * is the user experience significantly affected?
> * is the size implications significant?
> As far as I can tell, the answer to both is generally no.

For everything else, besides opt features, plugins, ... , I totally agree
with the nice short answer from Rex.

--

Michal Schorm
Associate Software Engineer
Core Services - Databases Team
Red Hat

On Tue, Apr 10, 2018 at 1:57 PM, Rex Dieter  wrote:

> Dominik 'Rathann' Mierzejewski wrote:
>
> > Arguably, the current stable updates policy is against this
> > https://fedoraproject.org/wiki/Updates_Policy#Stable_Releases :
> > [...] Updates should aim to fix bugs, and not introduce features, [...]
>
> you snipped off what I consider relevant here: "... particularly when those
> features would materially affect the user or developer experience"
>
> > Is this a legitimate issue or am I making storm in a teacup here?
> > Ever-increasing package sizes and dependency bloat do seem to be
> > a popular topic these days.
>
> 2 considerations:
> * is the user experience significantly affected?
> * is the size implications significant?
>
> As far as I can tell, the answer to both is generally no.
>
> -- rex
> ___
> 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 1560182] Concurrent Gtk2::Unique execution causes shutter to crash

[bugzilla]

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

Petr Pisar  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Assignee|liangsuil...@gmail.com  |ppi...@redhat.com



--- Comment #7 from Petr Pisar  ---
Two weeks and no word from Suilong. I will fix 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

Fedora-Atomic 27-20180411.0 compose check report

[Fedora compose checker]

No missing expected images.

Passed openQA tests: 2/2 (x86_64)
-- 
Mail generated by check-compose:
https://pagure.io/fedora-qa/check-compose
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

[Bug 1563208] perl-IO-Async-0.72 is available

[bugzilla]

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

Petr Pisar  changed:

   What|Removed |Added

External Bug ID||CPAN 114376



-- 
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 1563208] perl-IO-Async-0.72 is available

[bugzilla]

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

Emmanuel Seyman  changed:

   What|Removed |Added

 Status|NEW |CLOSED
   Fixed In Version||perl-IO-Async-0.72-2.fc29
 Resolution|--- |RAWHIDE
Last Closed||2018-04-11 03:47:06



--- Comment #7 from Emmanuel Seyman  ---
Built for rawhide:
https://koji.fedoraproject.org/koji/buildinfo?buildID=1068750

-- 
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 796143] perl-PAR-Packer-1.013 is available

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=796143
Bug 796143 depends on bug 796298, which changed state.

Bug 796298 Summary: Review Request: perl-Tk-EntryCheck - Interface to Tk::Entry 
for controlling its length and content
https://bugzilla.redhat.com/show_bug.cgi?id=796298

   What|Removed |Added

 Status|ON_QA   |CLOSED
 Resolution|--- |ERRATA



-- 
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] Please review: ns-deadlock

[William Brown]

https://pagure.io/389-ds-base/pull-request/49636

I'll write up a page for the wiki soon about the content of the patch.



-- 
Thanks,

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

[EPEL-devel] Re: Ansible in EL7

[James Hogarth]

On Wed, 11 Apr 2018, 01:26 Todd Zullinger,  wrote:

> James Hogarth wrote:
> > On Wed, 11 Apr 2018, 00:59 Todd Zullinger,  wrote:
> >> Red Hat announced today that Ansible was being deprecated
> >> from the extras channel.  Their advice is that those who
> >> have "previously installed Ansible and its dependencies from
> >> the Extras channel are advised to enable and update from the
> >> Ansible Engine channel, or uninstall the packages as future
> >> errata will not be provided from the Extras channel."
> >>
> >> https://access.redhat.com/errata/RHSA-2018:1075
> >>
> >> Given that, I believe it is reasonable to see ansible return
> >> to EPEL.  This was discussed in previous EPEL meetings a
> >> bit, so I'm sure it was known to at least some of the folks
> >> involved.
> >
> > Cheers for the info.
> >
> > It wasn't mentioned on the devel list, I didn't see it in the 7.5 release
> > notes and it was still in extras when I checked a short while ago.
> >
> > In that case yes I agree it makes total sense to return to epel7
> >
> > I wonder why they dropped it when the whole point of them bringing it in
> to
> > begin with was for Satellite and Tower to have it in the standard RHEL
> > repos.
> >
> > Seems so pointless to have only had one release there!
>
> Indeed, it was a bit strange.  Perhaps someone with more
> insight into the rationale can comment.  I have no
> particular knowledge of things, but maybe keeping a fast
> moving project like ansible in even the RHEL extras channel
> was a problem.
>
> Maybe the plan with the move to the "Ansible Engine" channel
> is to work closer with subscribers on migrating from version
> to version.  And non-subscribers can just follow it in EPEL.
>
> I'd be interested in hearing more about the change, though I
> suspect those who know more either aren't on these lists or
> can't say more than Red Hat's advisory has already.
>
>
At this point, no offense to Nirik and the maintenance he does on the
package, I'm actually tempted to just grab it from upstream directly at
https://releases.ansible.com/ansible/rpm/

At least then I can get consistency with selection of stable, preview or
nightly ...



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

Re: [EPEL-devel] Re: Ansible in EL7

[James Hogarth]

On Wed, 11 Apr 2018, 01:26 Todd Zullinger,  wrote:

> James Hogarth wrote:
> > On Wed, 11 Apr 2018, 00:59 Todd Zullinger,  wrote:
> >> Red Hat announced today that Ansible was being deprecated
> >> from the extras channel.  Their advice is that those who
> >> have "previously installed Ansible and its dependencies from
> >> the Extras channel are advised to enable and update from the
> >> Ansible Engine channel, or uninstall the packages as future
> >> errata will not be provided from the Extras channel."
> >>
> >> https://access.redhat.com/errata/RHSA-2018:1075
> >>
> >> Given that, I believe it is reasonable to see ansible return
> >> to EPEL.  This was discussed in previous EPEL meetings a
> >> bit, so I'm sure it was known to at least some of the folks
> >> involved.
> >
> > Cheers for the info.
> >
> > It wasn't mentioned on the devel list, I didn't see it in the 7.5 release
> > notes and it was still in extras when I checked a short while ago.
> >
> > In that case yes I agree it makes total sense to return to epel7
> >
> > I wonder why they dropped it when the whole point of them bringing it in
> to
> > begin with was for Satellite and Tower to have it in the standard RHEL
> > repos.
> >
> > Seems so pointless to have only had one release there!
>
> Indeed, it was a bit strange.  Perhaps someone with more
> insight into the rationale can comment.  I have no
> particular knowledge of things, but maybe keeping a fast
> moving project like ansible in even the RHEL extras channel
> was a problem.
>
> Maybe the plan with the move to the "Ansible Engine" channel
> is to work closer with subscribers on migrating from version
> to version.  And non-subscribers can just follow it in EPEL.
>
> I'd be interested in hearing more about the change, though I
> suspect those who know more either aren't on these lists or
> can't say more than Red Hat's advisory has already.
>
>
At this point, no offense to Nirik and the maintenance he does on the
package, I'm actually tempted to just grab it from upstream directly at
https://releases.ansible.com/ansible/rpm/

At least then I can get consistency with selection of stable, preview or
nightly ...



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