date:20170728

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



--- Comment #8 from Upstream Release Monitoring 
 ---
releng's perl-Text-Fuzzy-0.26-2.fc27 completed
http://koji.fedoraproject.org/koji/buildinfo?buildID=937420

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

Review swap: gimp-luminosity-masks

2017-07-28 Thread Luya Tshimbalanga

Hello team,

I am looking for a review swap for gimp-luminosity-masks:

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

The package is very simple and easy to review.

Thanks in advance,

-- 
Luya Tshimbalanga
Graphic & Web Designer
E: l...@fedoraproject.org
W: http://www.coolest-storm.net
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

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

2017-07-28 Thread updates

The following Fedora EPEL 6 Security updates need testing:
 Age  URL
 751  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2015-7031   
python-virtualenv-12.0.7-1.el6
 745  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2015-7168   
rubygem-crack-0.3.2-2.el6
 635  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2015-e2b4b5b2fb   
mcollective-2.8.4-1.el6
 607  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2015-35e240edd9   
thttpd-2.25b-24.el6
 217  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-e3e50897ac   
libbsd-0.8.3-2.el6
 113  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-c0d33ae70f   
tnef-1.4.14-1.el6
  47  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-23f4cb5d02   
lxc-1.0.10-2.el6
  21  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-b1d8b4aed9   
globus-ftp-client-8.36-1.el6 globus-gass-cache-program-6.7-1.el6 
globus-gass-copy-9.27-1.el6 globus-gram-client-13.18-1.el6 
globus-gram-job-manager-14.36-1.el6 globus-gram-job-manager-condor-2.6-5.el6 
globus-gridftp-server-12.2-1.el6 globus-gssapi-gsi-12.17-1.el6 
globus-io-11.9-1.el6 globus-net-manager-0.17-1.el6 globus-xio-5.16-1.el6 
globus-xio-gsi-driver-3.11-1.el6 globus-xio-pipe-driver-3.10-1.el6 
globus-xio-udt-driver-1.28-1.el6 myproxy-6.1.28-1.el6
  15  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-e8124f23c8   
heimdal-7.4.0-1.el6
  13  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-428858445a   
jabberd-2.6.1-2.el6
  13  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-f7d737f93d   
phpldapadmin-1.2.3-10.el6
  12  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-0ca79e82a3   
yara-3.6.3-1.el6
   5  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-515cca9a02   
GraphicsMagick-1.3.26-3.el6
   5  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-99fb0d61b0   
chicken-4.12.0-3.el6
   5  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-ab5ed7f894   
python-tablib-0.11.5-1.el6
   4  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-70562ba4d2   
python-django-ckeditor-5.3.0-1.el6
   4  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-f4a2132f26   
seamonkey-2.48-1.el6


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

cmake-fedora-2.9.1-1.el6
hitch-1.4.6-1.el6
ptpython-0.41-1.el6
python-lmdb-0.92-2.el6

Details about builds:



 cmake-fedora-2.9.1-1.el6 (FEDORA-EPEL-2017-ce2307a8b7)
 CMake helper modules for fedora developers

Update Information:

Fixed the cmake-fedora-fedpkg related path SRPM bug  - Bugs:+ Fixed
RHBZ#1475682 - ChangeLog failed to update after doing the git reset --hard HEAD
  Migrate changes like fedorahosted to pagure. And move from pkgdb to
product definition center (PDC). - Enhancement:   + cmake-fedora-pkgdb new sub-
commands: - git-branch package: List the git-branches of package -
newest-nvr: Return NVR of master branch - newest-changelog: Return the
latest ChangeLog in master branch. - Changes:   + koji-build-scratch is now back
to use koji build --scratch   + MANAGE_UPLOAD_FEDORAHOSTED is marked as
depreciated But MANAGE_UPLOAD_PAGURE is not implemented yet, as pagure does
not support scp upload yet - Bugs:   + Fixed RHBZ#1424757 - cmake-fedora:
failed to handle f26-pending   + Fixed RHBZ#1425263 - cmake-fedora: migrate from
fedorahosted to pagure   + Fixed fedpkg --dist depreciate warning

References:

  [ 1 ] Bug #1475682 - ChangeLog failed to update after doing the git reset 
--hard HEAD
https://bugzilla.redhat.com/show_bug.cgi?id=1475682




 hitch-1.4.6-1.el6 (FEDORA-EPEL-2017-abc5311228)
 Network proxy that terminates TLS/SSL connections

Update Information:

New upstream release. This is a minor release fixing build bugs.

References:

  [ 1 ] Bug #1459362 - hitch-1.4.6 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1459362




 ptpython-0.41-1.el6 (FEDORA-EPEL-2017-e39bda5e02)
 Python REPL build on top of prompt_toolkit

Update Information:

https://github.com/jonathanslenders/ptpython/blob/da2c5281f60c2d8a92749709219771
ffaa84220f/CHANGELOG#L4-L20

[Bug 1468401] perl-Log-Dispatch-FileRotate-1.29 is available

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



--- Comment #6 from Upstream Release Monitoring 
 ---
One or more of the new sources for this package are identical to the old
sources. It's likely this package does not use the version macro in its Source
URLs. If possible, please update the specfile to include the version macro in
the Source URLs

-- 
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 1468401] perl-Log-Dispatch-FileRotate-1.29 is available

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

Upstream Release Monitoring  
changed:

   What|Removed |Added

Summary|perl-Log-Dispatch-FileRotat |perl-Log-Dispatch-FileRotat
   |e-1.28 is available |e-1.29 is available



--- Comment #5 from Upstream Release Monitoring 
 ---
Latest upstream release: 1.29
Current version/release in rawhide: 1.26-2.fc27
URL: http://search.cpan.org/dist/Log-Dispatch-FileRotate/

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

-- 
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: ImageMagick Unresponsive Maintainer process - hubbitus (Pavel Alexeev)

2017-07-28 Thread Kevin Fenzi

On 07/28/2017 04:43 PM, Kevin Fenzi wrote:
> On 07/28/2017 07:20 AM, Michael Cronenworth wrote:
>> On 07/27/2017 09:29 PM, Kevin Fenzi wrote:
>>> ok. I have pushed 6.9.9-3 to rawhide.
>>>
>>> Hopefully I got all the CVE's right in the changelog.
>>> If someone wants to check over and make sure I didn't miss any that were
>>> fixed in the 6.x branch that would be great.
>>>
>>> I'd like to let it run a few days in rawhide before updating stable
>>> branches, just in case I missed something.;)
>>
>> First off, thanks, Kevin.
>>
>> The update will require rebuilds. It introduces a SONAME change.
>>
>> libMagickCore-6.Q16.so.2 -> libMagickCore-6.Q16.so.5
> 
> Yeah, luckily there's very few things that actually link against it.
> Most everything using it calls out to it's command line binaries.
> 
> Looks like the list is:
> 
> vips
> autotrace
> 
> if I got my query right.

Which I did not. ;)

Thats the -devel package ones, there's also -c++-devel:

synfig

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

Re: ImageMagick Unresponsive Maintainer process - hubbitus (Pavel Alexeev)

2017-07-28 Thread Kevin Fenzi

On 07/28/2017 07:20 AM, Michael Cronenworth wrote:
> On 07/27/2017 09:29 PM, Kevin Fenzi wrote:
>> ok. I have pushed 6.9.9-3 to rawhide.
>>
>> Hopefully I got all the CVE's right in the changelog.
>> If someone wants to check over and make sure I didn't miss any that were
>> fixed in the 6.x branch that would be great.
>>
>> I'd like to let it run a few days in rawhide before updating stable
>> branches, just in case I missed something.;)
> 
> First off, thanks, Kevin.
> 
> The update will require rebuilds. It introduces a SONAME change.
> 
> libMagickCore-6.Q16.so.2 -> libMagickCore-6.Q16.so.5

Yeah, luckily there's very few things that actually link against it.
Most everything using it calls out to it's command line binaries.

Looks like the list is:

vips
autotrace

if I got my query right.

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

Re: Finalizing Fedora's Switch to Python 3

On Fri, Jul 28, 2017 at 11:11:05PM +0200, Miro Hrončok wrote:
> On 28.7.2017 22:44, Zbigniew Jędrzejewski-Szmek wrote:
> >On Fri, Jul 28, 2017 at 05:51:39PM +1000, Nick Coghlan wrote:
> >>On 28 July 2017 at 03:15, Zbigniew Jędrzejewski-Szmek  
> >>wrote:
> >>>Do you think it'd be possible to script the python-foo to python2-foo
> >>>renaming? If yes, then maybe it'd make sense to just get some pps to
> >>>do it in rawhide now and get the "easy" part done with? That should
> >>>significantly cut down on the number of misnamed packages and let
> >>>packagers spend their times on the ones where the automatic way is not
> >>>obvious.
> >>
> >>I was going to ask whether it might be possible to tweak
> >>http://fedora.portingdb.xyz/ to also report on compliance with the
> >>naming policy, but then I went and saw that it *does* already report
> >>on that: http://fedora.portingdb.xyz/namingpolicy/
> >>
> >>While it also turns out the wiki page already links to that page, it
> >>may be good to call it out a second time in a "How can I help?"
> >>section.
> >>
> >>Checking an initial sampling of spec files (python-d2to1,
> >>python-BeautfulSoup, python-amqplib) suggests to me that a script
> >>implementing the following rules might offer a reasonably start point,
> >>at least for Python-2-only modules that are remaining Python-2-only:
> >>
> >>- immediately before the first BuildRequires or Requires entry, add a
> >>%package section header for "-n python2-" (where "" is the
> >>lowercased package source name with any "python-" prefix stripped)
> >>- add a %python_provides entry after the new package header in
> >>accordance with the current guidelines
> >>- if the original package provided a non-lowercase "python-*"
> >>provides, remote it and add a second %python_provides with the
> >>original capitalisation
> >>- if the source package lacks the "python-" prefix, add a virtual
> >>provides for the unqualified package name
> >>- add a "-n python2-" qualifier to any currently unqualified
> >>description and files sections
> >>
> >>A script like that may even do a tolerable job for packages that *do*
> >>offer Python 3 subpackages (since those will already have qualifiers,
> >>and will necessarily appear after any unqualified runtime and build
> >>requirements for the default subpackage).
> >
> >I hacked up a script, it's on pagure now [1].
> >See logs [2] and the diff [3] (unfortunately no highlighting on paste.fp.o.).
> >This does 561 python-* packages, out of 645.
> 
> Wow, nice job!
> 
> >I took the list from portingdb, but it seems partially outdated, 32
> >packages already have %python_provide python2-*.
> >One more by hand (patch in repo).
> >That leaves 51 packages to convert by hand (mostly because of conditionals
> >which are too complicated to do automatically).
> >
> >So, please take a look at the diff [3]. If you want to adapt the
> >script, ping me, and I'll add you to the repo.
> >
> >After I started working on this, I limited it to python-* packages,
> >because those are easiest. There's 237 other packages on the portingdb
> >list. I *would* be possible to make the script work for those packages
> >which are pure python and just have an old name. I don't think it makes
> >sense to do other packages which just have a python subpackage this way.
> >
> >This would be a good start, I think. Before being pushed anywhere,
> >it'd need to be checked carefully of course and extended to some of
> >the remaining packages. I'd apply this as one step, and rebuild everything.
> >After that, it'd be easier to convert *dependencies*, because all or most
> >python2- names should be available. Some time after current mass rebuild
> >is done?
> 
> That sounds like something that would need to be approved by FESCo,
> isn't it?

Yes. That's what I said before too. I would like to see buy-in from
you and Nick and other python gurus before submitting it anywhere else
though.

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

Re: Finalizing Fedora's Switch to Python 3

On Fri, Jul 28, 2017 at 11:11:05PM +0200, Miro Hrončok wrote:
> On 28.7.2017 22:44, Zbigniew Jędrzejewski-Szmek wrote:
> >On Fri, Jul 28, 2017 at 05:51:39PM +1000, Nick Coghlan wrote:
> >>On 28 July 2017 at 03:15, Zbigniew Jędrzejewski-Szmek  
> >>wrote:
> >>>Do you think it'd be possible to script the python-foo to python2-foo
> >>>renaming? If yes, then maybe it'd make sense to just get some pps to
> >>>do it in rawhide now and get the "easy" part done with? That should
> >>>significantly cut down on the number of misnamed packages and let
> >>>packagers spend their times on the ones where the automatic way is not
> >>>obvious.
> >>
> >>I was going to ask whether it might be possible to tweak
> >>http://fedora.portingdb.xyz/ to also report on compliance with the
> >>naming policy, but then I went and saw that it *does* already report
> >>on that: http://fedora.portingdb.xyz/namingpolicy/
> >>
> >>While it also turns out the wiki page already links to that page, it
> >>may be good to call it out a second time in a "How can I help?"
> >>section.
> >>
> >>Checking an initial sampling of spec files (python-d2to1,
> >>python-BeautfulSoup, python-amqplib) suggests to me that a script
> >>implementing the following rules might offer a reasonably start point,
> >>at least for Python-2-only modules that are remaining Python-2-only:
> >>
> >>- immediately before the first BuildRequires or Requires entry, add a
> >>%package section header for "-n python2-" (where "" is the
> >>lowercased package source name with any "python-" prefix stripped)
> >>- add a %python_provides entry after the new package header in
> >>accordance with the current guidelines
> >>- if the original package provided a non-lowercase "python-*"
> >>provides, remote it and add a second %python_provides with the
> >>original capitalisation
> >>- if the source package lacks the "python-" prefix, add a virtual
> >>provides for the unqualified package name
> >>- add a "-n python2-" qualifier to any currently unqualified
> >>description and files sections
> >>
> >>A script like that may even do a tolerable job for packages that *do*
> >>offer Python 3 subpackages (since those will already have qualifiers,
> >>and will necessarily appear after any unqualified runtime and build
> >>requirements for the default subpackage).
> >
> >I hacked up a script, it's on pagure now [1].
> >See logs [2] and the diff [3] (unfortunately no highlighting on paste.fp.o.).
> >This does 561 python-* packages, out of 645.
> 
> Wow, nice job!
> 
> >I took the list from portingdb, but it seems partially outdated, 32
> >packages already have %python_provide python2-*.
> >One more by hand (patch in repo).
> >That leaves 51 packages to convert by hand (mostly because of conditionals
> >which are too complicated to do automatically).
> >
> >So, please take a look at the diff [3]. If you want to adapt the
> >script, ping me, and I'll add you to the repo.
> >
> >After I started working on this, I limited it to python-* packages,
> >because those are easiest. There's 237 other packages on the portingdb
> >list. I *would* be possible to make the script work for those packages
> >which are pure python and just have an old name. I don't think it makes
> >sense to do other packages which just have a python subpackage this way.
> >
> >This would be a good start, I think. Before being pushed anywhere,
> >it'd need to be checked carefully of course and extended to some of
> >the remaining packages. I'd apply this as one step, and rebuild everything.
> >After that, it'd be easier to convert *dependencies*, because all or most
> >python2- names should be available. Some time after current mass rebuild
> >is done?
> 
> That sounds like something that would need to be approved by FESCo,
> isn't it?

Yes. That's what I said before too. I would like to see buy-in from
you and Nick and other python gurus before submitting it anywhere else
though.

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

[Bug 1476247] perl-DBM-Deep-2.0014 is available

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



--- Comment #2 from Upstream Release Monitoring 
 ---
hotness's scratch build of perl-DBM-Deep-2.0014-1.el7.src.rpm for rawhide
failed http://koji.fedoraproject.org/koji/taskinfo?taskID=20853835

-- 
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: Finalizing Fedora's Switch to Python 3

2017-07-28 Thread Mathieu Bridon

On Fri, 2017-07-28 at 21:06 +0200, Till Maas wrote:
> On Fri, Jul 28, 2017 at 10:29:12PM +1000, Nick Coghlan wrote:
> 
> > It's only /usr/bin/python itself that still presents an unsolved
> > problem, since the status quo (not providing it at all) is even
> > more user hostile than pointing it at a modern version of Python 3
> > that
> 
> Why is not providing /usr/bin/python more use hostile? Why is it
> better for any script to use /usr/bin/python instead of
> /usr/bin/python3?

Exactly.

By default, any script using `#!/usr/bin/zsh` won't work on Fedora,
until the admin installs zsh.

We could very well consider that /usr/bin/python remains python2, and
not have it installed by default.

To be honest, given how much energy is spent on this migration for a
very low gain, it makes me feel like having an unversioned "python"
(whether as package or executable names) was a mistake we should let
disappear with Python 2.

If everything is a versioned pythonX in the future, moving to a
hypothetical Python 4 would only imply building new python4-* packages
and changing the (Build)Requires, no gymnastic with unversioned things.

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

Re: armv7hl builds running out of memory

2017-07-28 Thread Al Stone

On 07/27/2017 09:16 AM, Kaleb S. KEITHLEY wrote:
> On 07/26/2017 06:25 PM, Al Stone wrote:
>> I've been experimenting in a slightly different environment (RHEL vs Fedora)
>> but have been seeing oddly similar results.  The use or not of the "-pipe" in
>> GCC didn't seem to help.  If I forced the make in the %build step to be just
>> "make" (aka, "make -j1"), I could always get a build to work, albeit slowly.
>>
>> It turns out there is a typo in the spec file; look for the string
>> "WTIH_BABELTRACE" -- that should be "WITH_BABELTRACE".  In the environment 
>> I'm
>> using, "make -j32" is the default state.  If I leave the typo alone and do 
>> not
>> change the "make -j32", I can pretty consistently get the ceph build to fail;
>> the failure moves around a bit but generally seems to hang around with where
>> the babeltrace headers are being used (somewhere in RBD code, usually).  If I
>> fix the typo -- and change nothing else -- the build succeeds.
>>
>> Would you mind trying this one change -- fixing the typo *only* -- and see if
>> you get the same results?
> 
> If by same result you mean the build still fails, then yes. I get the same 
> result.
> 
> It's still running out of memory. Not the same way as the prior builds though.
> 
> ...
> [100%] Building CXX object src/rgw/CMakeFiles/radosgw.dir/rgw_main.cc.o
> /usr/include/c++/7/bits/stl_map.h: In static member function 'static void
> pg_missing_set::generate_test_instances(std::__cxx11::list&)
> [with bool TrackChanges = false]':
> /usr/include/c++/7/bits/stl_map.h:493:4: note: parameter passing for argument 
> of
> type 'std::_Rb_tree std::_Select1st,
> std::less, std::allocator
>> >::const_iterator {aka std::_Rb_tree_const_iterator >hobject_t,
> pg_missing_item> >}' changed in GCC 7.1
> __i = _M_t._M_emplace_hint_unique(__i, std::piecewise_construct,
> ^~~
> virtual memory exhausted: Operation not permitted
> ...
> make: *** [Makefile:141: all] Error 2
> RPM build errors:
> error: Bad exit status from /var/tmp/rpm-tmp.RgosXb (%build)
> Bad exit status from /var/tmp/rpm-tmp.RgosXb (%build)
> Child return code was: 1
> ...
> 
> See https://koji.fedoraproject.org/koji/taskinfo?taskID=20797264 for full 
> logs.
> 
> -- 
> 
> Kaleb

Rats.  Thought I had a clue or a pointer; thanks for trying, though.  When a
colleague double checked my results, we discovered that what I was seeing was
not a change in behavior from fixing the typo, but just a fluke, pure random
chance -- we've probably got a race condition in the build somehow where if
exactly the right combination of compiles tries to occur in parallel, the OOM
killer gets invoked and compilation fails.

You may have to force the %build section to use "make -j1", as well as remove
the use of "-pipe" as you have done.

In the meantime, I'm following up on a g++ bug that may or may not be relevant;
it definitely stresses memory horribly but I need to prove that something in the
compile is actually hitting the bug.  As a workaround, something like this might
help:


diff --git a/ceph.spec b/ceph.spec
index b321a1b..f15171e 100644
--- a/ceph.spec
+++ b/ceph.spec
@@ -811,8 +811,11 @@ cmake .. \
 %endif
 -DBOOST_J=%{_smp_ncpus}

+%ifarch aarch64
+make
+%else
 make %{?_smp_mflags}
-
+%endif

 %if 0%{with make_check}
 %check


-- 
ciao,
al
---
Al Stone
Software Engineer
Red Hat, Inc.
a...@redhat.com
---
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Finalizing Fedora's Switch to Python 3

2017-07-28 Thread Kus

So excited to see this coming along so well! 

o/

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

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

2017-07-28 Thread updates

The following Fedora EPEL 7 Security updates need testing:
 Age  URL
 872  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2015-1087   
dokuwiki-0-0.24.20140929c.el7
 635  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2015-dac7ed832f   
mcollective-2.8.4-1.el7
 217  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-04bc9dd81d   
libbsd-0.8.3-1.el7
 115  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-d241156dfe   
mod_cluster-1.3.3-10.el7
 113  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-5f9a6163b4   
tnef-1.4.14-1.el7
 112  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-7ecb12e378   
python-XStatic-jquery-ui-1.12.0.1-1.el7
  46  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-4aae1e22f1   
lxc-1.0.10-2.el7
  21  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-52b6bc17c1   
globus-ftp-client-8.36-1.el7 globus-gass-cache-program-6.7-1.el7 
globus-gass-copy-9.27-1.el7 globus-gram-client-13.18-1.el7 
globus-gram-job-manager-14.36-1.el7 globus-gram-job-manager-condor-2.6-5.el7 
globus-gridftp-server-12.2-1.el7 globus-gssapi-gsi-12.17-1.el7 
globus-io-11.9-1.el7 globus-net-manager-0.17-1.el7 globus-xio-5.16-1.el7 
globus-xio-gsi-driver-3.11-1.el7 globus-xio-pipe-driver-3.10-1.el7 
globus-xio-udt-driver-1.28-1.el7 myproxy-6.1.28-1.el7
  15  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-47be021843   
heimdal-7.4.0-1.el7
  14  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-a8886eb42e   
cross-binutils-2.27-9.el7.1 cross-gcc-4.8.5-16.el7.1
  13  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-93f422baa0   
nodejs-6.11.1-1.el7
  13  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-491dd51db6   
phpldapadmin-1.2.3-10.el7
  11  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-64c36b5282   
rubygem-rack-cors-0.4.1-1.el7
  11  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-0e0fd785bc   
yara-3.6.3-1.el7
   5  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-c39b9065fa   
GraphicsMagick-1.3.26-3.el7
   5  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-c4e53cc90d   
chicken-4.12.0-3.el7
   5  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-1024674dfb   
moodle-3.1.7-1.el7
   3  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-b39314b704   
mingw-c-ares-1.13.0-1.el7
   3  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-2c3a1062a0   
seamonkey-2.48-1.el7
   1  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-b50572c103   
sscep-0.6.1-5.20160525git2052ee1.el7
   0  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-4908d32c3c   
python-dbusmock-0.11.1-6.el7


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

cmake-fedora-2.9.1-1.el7
ptpython-0.41-1.el7
python-dbusmock-0.11.1-6.el7
python-pygments2-2.2.0-1.el7
rpkg-client-0.8-1.el7
yamllint-1.8.1-1.el7

Details about builds:



 cmake-fedora-2.9.1-1.el7 (FEDORA-EPEL-2017-99fccbb8f3)
 CMake helper modules for fedora developers

Update Information:

Fixed the cmake-fedora-fedpkg related path SRPM bug  - Bugs:+ Fixed
RHBZ#1475682 - ChangeLog failed to update after doing the git reset --hard HEAD
  Migrate changes like fedorahosted to pagure. And move from pkgdb to
product definition center (PDC). - Enhancement:   + cmake-fedora-pkgdb new sub-
commands: - git-branch package: List the git-branches of package -
newest-nvr: Return NVR of master branch - newest-changelog: Return the
latest ChangeLog in master branch. - Changes:   + koji-build-scratch is now back
to use koji build --scratch   + MANAGE_UPLOAD_FEDORAHOSTED is marked as
depreciated But MANAGE_UPLOAD_PAGURE is not implemented yet, as pagure does
not support scp upload yet - Bugs:   + Fixed RHBZ#1424757 - cmake-fedora:
failed to handle f26-pending   + Fixed RHBZ#1425263 - cmake-fedora: migrate from
fedorahosted to pagure   + Fixed fedpkg --dist depreciate warning

References:

  [ 1 ] Bug #1475682 - ChangeLog failed to update after doing the git reset 
--hard HEAD
https://bugzilla.redhat.com/show_bug.cgi?id=1475682




 ptpython-0.41-1.el7 (FEDORA-EPEL-2017-f3002cf100)
 Python REPL build on top of prompt_toolkit

Update Information:

https://github.com/jonathanslenders/ptpython/blob/da2c5281f60c2d8a92749709219771
ffaa84220f/CHANGELOG#L4-L20

References:

  [ 1 ] Bug #1475813 - ptpython-0.41 is available

Re: Finalizing Fedora's Switch to Python 3


On 28.7.2017 22:44, Zbigniew Jędrzejewski-Szmek wrote:

On Fri, Jul 28, 2017 at 05:51:39PM +1000, Nick Coghlan wrote:

On 28 July 2017 at 03:15, Zbigniew Jędrzejewski-Szmek  wrote:

Do you think it'd be possible to script the python-foo to python2-foo
renaming? If yes, then maybe it'd make sense to just get some pps to
do it in rawhide now and get the "easy" part done with? That should
significantly cut down on the number of misnamed packages and let
packagers spend their times on the ones where the automatic way is not
obvious.


I was going to ask whether it might be possible to tweak
http://fedora.portingdb.xyz/ to also report on compliance with the
naming policy, but then I went and saw that it *does* already report
on that: http://fedora.portingdb.xyz/namingpolicy/

While it also turns out the wiki page already links to that page, it
may be good to call it out a second time in a "How can I help?"
section.

Checking an initial sampling of spec files (python-d2to1,
python-BeautfulSoup, python-amqplib) suggests to me that a script
implementing the following rules might offer a reasonably start point,
at least for Python-2-only modules that are remaining Python-2-only:

- immediately before the first BuildRequires or Requires entry, add a
%package section header for "-n python2-" (where "" is the
lowercased package source name with any "python-" prefix stripped)
- add a %python_provides entry after the new package header in
accordance with the current guidelines
- if the original package provided a non-lowercase "python-*"
provides, remote it and add a second %python_provides with the
original capitalisation
- if the source package lacks the "python-" prefix, add a virtual
provides for the unqualified package name
- add a "-n python2-" qualifier to any currently unqualified
description and files sections

A script like that may even do a tolerable job for packages that *do*
offer Python 3 subpackages (since those will already have qualifiers,
and will necessarily appear after any unqualified runtime and build
requirements for the default subpackage).


I hacked up a script, it's on pagure now [1].
See logs [2] and the diff [3] (unfortunately no highlighting on paste.fp.o.).
This does 561 python-* packages, out of 645.


Wow, nice job!


I took the list from portingdb, but it seems partially outdated, 32
packages already have %python_provide python2-*.
One more by hand (patch in repo).
That leaves 51 packages to convert by hand (mostly because of conditionals
which are too complicated to do automatically).

So, please take a look at the diff [3]. If you want to adapt the
script, ping me, and I'll add you to the repo.

After I started working on this, I limited it to python-* packages,
because those are easiest. There's 237 other packages on the portingdb
list. I *would* be possible to make the script work for those packages
which are pure python and just have an old name. I don't think it makes
sense to do other packages which just have a python subpackage this way.

This would be a good start, I think. Before being pushed anywhere,
it'd need to be checked carefully of course and extended to some of
the remaining packages. I'd apply this as one step, and rebuild everything.
After that, it'd be easier to convert *dependencies*, because all or most
python2- names should be available. Some time after current mass rebuild
is done?


That sounds like something that would need to be approved by FESCo, 
isn't it?


--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
___
python-devel mailing list -- python-devel@lists.fedoraproject.org
To unsubscribe send an email to python-devel-le...@lists.fedoraproject.org

Re: Finalizing Fedora's Switch to Python 3


On 28.7.2017 22:44, Zbigniew Jędrzejewski-Szmek wrote:

On Fri, Jul 28, 2017 at 05:51:39PM +1000, Nick Coghlan wrote:

On 28 July 2017 at 03:15, Zbigniew Jędrzejewski-Szmek  wrote:

Do you think it'd be possible to script the python-foo to python2-foo
renaming? If yes, then maybe it'd make sense to just get some pps to
do it in rawhide now and get the "easy" part done with? That should
significantly cut down on the number of misnamed packages and let
packagers spend their times on the ones where the automatic way is not
obvious.


I was going to ask whether it might be possible to tweak
http://fedora.portingdb.xyz/ to also report on compliance with the
naming policy, but then I went and saw that it *does* already report
on that: http://fedora.portingdb.xyz/namingpolicy/

While it also turns out the wiki page already links to that page, it
may be good to call it out a second time in a "How can I help?"
section.

Checking an initial sampling of spec files (python-d2to1,
python-BeautfulSoup, python-amqplib) suggests to me that a script
implementing the following rules might offer a reasonably start point,
at least for Python-2-only modules that are remaining Python-2-only:

- immediately before the first BuildRequires or Requires entry, add a
%package section header for "-n python2-" (where "" is the
lowercased package source name with any "python-" prefix stripped)
- add a %python_provides entry after the new package header in
accordance with the current guidelines
- if the original package provided a non-lowercase "python-*"
provides, remote it and add a second %python_provides with the
original capitalisation
- if the source package lacks the "python-" prefix, add a virtual
provides for the unqualified package name
- add a "-n python2-" qualifier to any currently unqualified
description and files sections

A script like that may even do a tolerable job for packages that *do*
offer Python 3 subpackages (since those will already have qualifiers,
and will necessarily appear after any unqualified runtime and build
requirements for the default subpackage).


I hacked up a script, it's on pagure now [1].
See logs [2] and the diff [3] (unfortunately no highlighting on paste.fp.o.).
This does 561 python-* packages, out of 645.


Wow, nice job!


I took the list from portingdb, but it seems partially outdated, 32
packages already have %python_provide python2-*.
One more by hand (patch in repo).
That leaves 51 packages to convert by hand (mostly because of conditionals
which are too complicated to do automatically).

So, please take a look at the diff [3]. If you want to adapt the
script, ping me, and I'll add you to the repo.

After I started working on this, I limited it to python-* packages,
because those are easiest. There's 237 other packages on the portingdb
list. I *would* be possible to make the script work for those packages
which are pure python and just have an old name. I don't think it makes
sense to do other packages which just have a python subpackage this way.

This would be a good start, I think. Before being pushed anywhere,
it'd need to be checked carefully of course and extended to some of
the remaining packages. I'd apply this as one step, and rebuild everything.
After that, it'd be easier to convert *dependencies*, because all or most
python2- names should be available. Some time after current mass rebuild
is done?


That sounds like something that would need to be approved by FESCo, 
isn't it?


--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Mass rebuild failures only on ppc64le: glibc problem?

Status update:

Nick has pushed binutils-2.29-3.fc27, which disables the binutils change
by default.  (There is still an ld option to enable it.  Hopefully, no
packages use that yet.)

Just rebuilding glibc is insufficient as a fix.  The localentry
optimization is so sensitive to changes that glibc-using packages which
have been linked in a particular way have to be rebuilt.

I have patched symboldb to record the bits which ld uses to mark symbols
as localentry symbol references (which is the same information that the
glibc dynamic linker uses to generate those pesky errors).  A new Fedora
important is currently running.  Afterwards, I will use this data to do
targeted manual rebuilds of core packages which are affected by the
internal localentry optimization incompatibility of glibc.

Rebuilds are currently blocked on a new buildroot with some RPM
debuginfo generation fixes.  Rumor has it that there is an unrelated
issue which prevents buildroot updates.

releng has agreed to a second mass rebuild (for non-noarch packages),
but Paul Frields asked for it to be delayed, due to other tasks, such as
the pagure dist-git migration.  I think we can accommodate this as long
as there is not too much update churn in rawhide before the new mass
rebuild, triggering the new ABI incompatibilities.

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

Re: Finalizing Fedora's Switch to Python 3

On Fri, Jul 28, 2017 at 05:51:39PM +1000, Nick Coghlan wrote:
> On 28 July 2017 at 03:15, Zbigniew Jędrzejewski-Szmek  
> wrote:
> > Do you think it'd be possible to script the python-foo to python2-foo
> > renaming? If yes, then maybe it'd make sense to just get some pps to
> > do it in rawhide now and get the "easy" part done with? That should
> > significantly cut down on the number of misnamed packages and let
> > packagers spend their times on the ones where the automatic way is not
> > obvious.
> 
> I was going to ask whether it might be possible to tweak
> http://fedora.portingdb.xyz/ to also report on compliance with the
> naming policy, but then I went and saw that it *does* already report
> on that: http://fedora.portingdb.xyz/namingpolicy/
> 
> While it also turns out the wiki page already links to that page, it
> may be good to call it out a second time in a "How can I help?"
> section.
> 
> Checking an initial sampling of spec files (python-d2to1,
> python-BeautfulSoup, python-amqplib) suggests to me that a script
> implementing the following rules might offer a reasonably start point,
> at least for Python-2-only modules that are remaining Python-2-only:
> 
> - immediately before the first BuildRequires or Requires entry, add a
> %package section header for "-n python2-" (where "" is the
> lowercased package source name with any "python-" prefix stripped)
> - add a %python_provides entry after the new package header in
> accordance with the current guidelines
> - if the original package provided a non-lowercase "python-*"
> provides, remote it and add a second %python_provides with the
> original capitalisation
> - if the source package lacks the "python-" prefix, add a virtual
> provides for the unqualified package name
> - add a "-n python2-" qualifier to any currently unqualified
> description and files sections
> 
> A script like that may even do a tolerable job for packages that *do*
> offer Python 3 subpackages (since those will already have qualifiers,
> and will necessarily appear after any unqualified runtime and build
> requirements for the default subpackage).

I hacked up a script, it's on pagure now [1].
See logs [2] and the diff [3] (unfortunately no highlighting on paste.fp.o.).
This does 561 python-* packages, out of 645.
I took the list from portingdb, but it seems partially outdated, 32
packages already have %python_provide python2-*.
One more by hand (patch in repo). 
That leaves 51 packages to convert by hand (mostly because of conditionals
which are too complicated to do automatically).

So, please take a look at the diff [3]. If you want to adapt the
script, ping me, and I'll add you to the repo.

After I started working on this, I limited it to python-* packages,
because those are easiest. There's 237 other packages on the portingdb
list. I *would* be possible to make the script work for those packages
which are pure python and just have an old name. I don't think it makes
sense to do other packages which just have a python subpackage this way.

This would be a good start, I think. Before being pushed anywhere,
it'd need to be checked carefully of course and extended to some of
the remaining packages. I'd apply this as one step, and rebuild everything.
After that, it'd be easier to convert *dependencies*, because all or most
python2- names should be available. Some time after current mass rebuild
is done?

Zbyszek

[1] https://pagure.io/pyrenamer/tree/master
[2] https://pagure.io/pyrenamer/blob/master/f/results.txt
[3] https://paste.fedoraproject.org/paste/57oqggmOwvZFQjDbndRfcg
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Finalizing Fedora's Switch to Python 3

On Fri, Jul 28, 2017 at 05:51:39PM +1000, Nick Coghlan wrote:
> On 28 July 2017 at 03:15, Zbigniew Jędrzejewski-Szmek  
> wrote:
> > Do you think it'd be possible to script the python-foo to python2-foo
> > renaming? If yes, then maybe it'd make sense to just get some pps to
> > do it in rawhide now and get the "easy" part done with? That should
> > significantly cut down on the number of misnamed packages and let
> > packagers spend their times on the ones where the automatic way is not
> > obvious.
> 
> I was going to ask whether it might be possible to tweak
> http://fedora.portingdb.xyz/ to also report on compliance with the
> naming policy, but then I went and saw that it *does* already report
> on that: http://fedora.portingdb.xyz/namingpolicy/
> 
> While it also turns out the wiki page already links to that page, it
> may be good to call it out a second time in a "How can I help?"
> section.
> 
> Checking an initial sampling of spec files (python-d2to1,
> python-BeautfulSoup, python-amqplib) suggests to me that a script
> implementing the following rules might offer a reasonably start point,
> at least for Python-2-only modules that are remaining Python-2-only:
> 
> - immediately before the first BuildRequires or Requires entry, add a
> %package section header for "-n python2-" (where "" is the
> lowercased package source name with any "python-" prefix stripped)
> - add a %python_provides entry after the new package header in
> accordance with the current guidelines
> - if the original package provided a non-lowercase "python-*"
> provides, remote it and add a second %python_provides with the
> original capitalisation
> - if the source package lacks the "python-" prefix, add a virtual
> provides for the unqualified package name
> - add a "-n python2-" qualifier to any currently unqualified
> description and files sections
> 
> A script like that may even do a tolerable job for packages that *do*
> offer Python 3 subpackages (since those will already have qualifiers,
> and will necessarily appear after any unqualified runtime and build
> requirements for the default subpackage).

I hacked up a script, it's on pagure now [1].
See logs [2] and the diff [3] (unfortunately no highlighting on paste.fp.o.).
This does 561 python-* packages, out of 645.
I took the list from portingdb, but it seems partially outdated, 32
packages already have %python_provide python2-*.
One more by hand (patch in repo). 
That leaves 51 packages to convert by hand (mostly because of conditionals
which are too complicated to do automatically).

So, please take a look at the diff [3]. If you want to adapt the
script, ping me, and I'll add you to the repo.

After I started working on this, I limited it to python-* packages,
because those are easiest. There's 237 other packages on the portingdb
list. I *would* be possible to make the script work for those packages
which are pure python and just have an old name. I don't think it makes
sense to do other packages which just have a python subpackage this way.

This would be a good start, I think. Before being pushed anywhere,
it'd need to be checked carefully of course and extended to some of
the remaining packages. I'd apply this as one step, and rebuild everything.
After that, it'd be easier to convert *dependencies*, because all or most
python2- names should be available. Some time after current mass rebuild
is done?

Zbyszek

[1] https://pagure.io/pyrenamer/tree/master
[2] https://pagure.io/pyrenamer/blob/master/f/results.txt
[3] https://paste.fedoraproject.org/paste/57oqggmOwvZFQjDbndRfcg
___
python-devel mailing list -- python-devel@lists.fedoraproject.org
To unsubscribe send an email to python-devel-le...@lists.fedoraproject.org

Re: ImageMagick Unresponsive Maintainer process - hubbitus (Pavel Alexeev)

2017-07-28 Thread Björn 'besser82' Esser


Am 28.07.2017 um 16:20 schrieb Michael Cronenworth:

On 07/27/2017 09:29 PM, Kevin Fenzi wrote:

ok. I have pushed 6.9.9-3 to rawhide.

Hopefully I got all the CVE's right in the changelog.
If someone wants to check over and make sure I didn't miss any that were
fixed in the 6.x branch that would be great.

I'd like to let it run a few days in rawhide before updating stable
branches, just in case I missed something.;)


First off, thanks, Kevin.

The update will require rebuilds. It introduces a SONAME change.

libMagickCore-6.Q16.so.2 -> libMagickCore-6.Q16.so.5


I've rebuilt Emacs in Rawhide, but it's still waiting to get signed.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

[Bug 1475590] perl-Mail-Message-3.001 is available

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

Tom "spot" Callaway  changed:

   What|Removed |Added

 Status|NEW |CLOSED
 Resolution|--- |RAWHIDE
Last Closed||2017-07-28 15:25:24



-- 
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: Finalizing Fedora's Switch to Python 3

2017-07-28 Thread Randy Barlow

On Fri, 2017-07-28 at 14:11 -0400, Colin Walters wrote:
> First, I don't see a need for even mild pejoratives; instead of
> "normal" you could say
> for example "other editions".

My apologies - I was just struggling with terminology. No offense
intended.

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

Re: Finalizing Fedora's Switch to Python 3

2017-07-28 Thread Till Maas

On Fri, Jul 28, 2017 at 10:29:12PM +1000, Nick Coghlan wrote:

> It's only /usr/bin/python itself that still presents an unsolved
> problem, since the status quo (not providing it at all) is even more
> user hostile than pointing it at a modern version of Python 3 that

Why is not providing /usr/bin/python more use hostile? Why is it better
for any script to use /usr/bin/python instead of /usr/bin/python3?

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

[Bug 1475590] perl-Mail-Message-3.001 is available

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



--- Comment #2 from Upstream Release Monitoring 
 ---
spot's perl-Mail-Message-3.001-1.fc27 completed
http://koji.fedoraproject.org/koji/buildinfo?buildID=941120

-- 
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: Recompiling/relinking dependent applications/libraries on DSO change

2017-07-28 Thread Richard W.M. Jones

On Fri, Jul 28, 2017 at 01:39:50PM +0200, Florian Weimer wrote:
> binutils 2.29 introduced an optimization which requires that in the
> general case, applications and libraries linking against a DSO will have
> to be rebuilt when the DSO change the implementation of functions (i.e.,
> changes to a function body can change ABI).  This is how many native
> programming languages (such as Ada, Haskell/GHC, Go, Rust) handle DSOs,
> but it's a material change for C and C++.
> 
> The question is: Do we want to move into that direction, or do we need
> to ask binutils upstream to back out this change?

I think you summed up the proper response in your reply here:

  https://sourceware.org/ml/libc-alpha/2017-07/msg00974.html

"Ugh."

OCaml does cross-module function inlining.  It's a nice feature for
getting fast code, but from a packaging perspective it means you have
to rebuild the world every time a dependent library changes even
internally, and that's not nice.  It's only really possible for Fedora
because there are fewer than 100 packages.

Also as Dan mentioned, libvirt.so offers a stable ABI so existing
binaries must continue to work.  Avoiding use of globals in any future
libvirt (transitively if functions are called or inlined within the
DSO?) doesn't sound like it would be possible in general, or pleasant
if it is possible.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-df lists disk usage of guests without needing to install any
software inside the virtual machine.  Supports Linux and Windows.
http://people.redhat.com/~rjones/virt-df/
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Finalizing Fedora's Switch to Python 3


On 28.7.2017 20:11, Colin Walters wrote:



On Fri, Jul 28, 2017, at 01:53 PM, Randy Barlow wrote:

On Fri, 2017-07-28 at 12:41 -0400, Colin Walters wrote:

I'm opposed to switching the meaning of `/usr/bin/python` for AH
anytime soon.  It's just going to break stuff, and to me the gain is
quite
low.


One of Fedora's stated goals is to remain close to the upstream.
Upstream Python is going to change /usr/bin/python to mean Python 3. If
AH keeps it on Python 2, it will be confusing for Python programmers
using AH. It will be especially confusing for programmers who want to
write software that works on "normal" Fedora and AH.


First, I don't see a need for even mild pejoratives; instead of "normal" you 
could say
for example "other editions".

Now, we don't really expect people "program" AH directly in that sense;
most development should go in containers, except for development of
the various Python things we carry in the host, but that's not a huge set.


Also, as software
begins to switch AH will have to patch its Python packages, diverging
from the rest of Fedora.


That's actually something I hadn't even considered; is it proposed
here to actually have a flag day where all (or even some) of the python3 
executables
start using /usr/bin/python and everything else is /usr/bin/python2?


No. We'd like to keep it the way that everything in Fedora either uses 
/usr/bin/python3 or /usr/bin/python2. To keep the possibility for the 
sysadmins to change /usr/bin/python to whatever crazy target they want.


Patching packages would not be required here.


The scope of that would appear to me to be quite staggering.

Are we really at the point even where everything that's python2 only
explicitly references /usr/bin/python2?  I'm doubtful.


I don't see a practical advantage to divergence. I believe the
divergence will break stuff in a more confusing manner than the change
will.


I don't want to break Ansible users or in general random sysadmin scripts;
the value of replacing the meaning of /usr/bin/python feels quite low relative
to that.
___
devel mailing list -- de...@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org



--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
___
python-devel mailing list -- python-devel@lists.fedoraproject.org
To unsubscribe send an email to python-devel-le...@lists.fedoraproject.org

Re: Finalizing Fedora's Switch to Python 3


On 28.7.2017 20:11, Colin Walters wrote:



On Fri, Jul 28, 2017, at 01:53 PM, Randy Barlow wrote:

On Fri, 2017-07-28 at 12:41 -0400, Colin Walters wrote:

I'm opposed to switching the meaning of `/usr/bin/python` for AH
anytime soon.  It's just going to break stuff, and to me the gain is
quite
low.


One of Fedora's stated goals is to remain close to the upstream.
Upstream Python is going to change /usr/bin/python to mean Python 3. If
AH keeps it on Python 2, it will be confusing for Python programmers
using AH. It will be especially confusing for programmers who want to
write software that works on "normal" Fedora and AH.


First, I don't see a need for even mild pejoratives; instead of "normal" you 
could say
for example "other editions".

Now, we don't really expect people "program" AH directly in that sense;
most development should go in containers, except for development of
the various Python things we carry in the host, but that's not a huge set.


Also, as software
begins to switch AH will have to patch its Python packages, diverging
from the rest of Fedora.


That's actually something I hadn't even considered; is it proposed
here to actually have a flag day where all (or even some) of the python3 
executables
start using /usr/bin/python and everything else is /usr/bin/python2?


No. We'd like to keep it the way that everything in Fedora either uses 
/usr/bin/python3 or /usr/bin/python2. To keep the possibility for the 
sysadmins to change /usr/bin/python to whatever crazy target they want.


Patching packages would not be required here.


The scope of that would appear to me to be quite staggering.

Are we really at the point even where everything that's python2 only
explicitly references /usr/bin/python2?  I'm doubtful.


I don't see a practical advantage to divergence. I believe the
divergence will break stuff in a more confusing manner than the change
will.


I don't want to break Ansible users or in general random sysadmin scripts;
the value of replacing the meaning of /usr/bin/python feels quite low relative
to that.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org



--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Finalizing Fedora's Switch to Python 3

On Fri, Jul 28, 2017, at 01:53 PM, Randy Barlow wrote:
> On Fri, 2017-07-28 at 12:41 -0400, Colin Walters wrote:
> > I'm opposed to switching the meaning of `/usr/bin/python` for AH
> > anytime soon.  It's just going to break stuff, and to me the gain is
> > quite
> > low.
> 
> One of Fedora's stated goals is to remain close to the upstream.
> Upstream Python is going to change /usr/bin/python to mean Python 3. If
> AH keeps it on Python 2, it will be confusing for Python programmers
> using AH. It will be especially confusing for programmers who want to
> write software that works on "normal" Fedora and AH.

First, I don't see a need for even mild pejoratives; instead of "normal" you 
could say
for example "other editions".

Now, we don't really expect people "program" AH directly in that sense;
most development should go in containers, except for development of
the various Python things we carry in the host, but that's not a huge set.

> Also, as software
> begins to switch AH will have to patch its Python packages, diverging
> from the rest of Fedora.

That's actually something I hadn't even considered; is it proposed
here to actually have a flag day where all (or even some) of the python3 
executables
start using /usr/bin/python and everything else is /usr/bin/python2?
The scope of that would appear to me to be quite staggering.

Are we really at the point even where everything that's python2 only
explicitly references /usr/bin/python2?  I'm doubtful.

> I don't see a practical advantage to divergence. I believe the
> divergence will break stuff in a more confusing manner than the change
> will.

I don't want to break Ansible users or in general random sysadmin scripts;
the value of replacing the meaning of /usr/bin/python feels quite low relative
to that.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Finalizing Fedora's Switch to Python 3


On 28.7.2017 18:38, Stephen John Smoogen wrote:



On 28 July 2017 at 11:42, Miro Hrončok > wrote:


On 28.7.2017 16:25, John Dennis wrote:

I made this comment previously but because I think it's
important I'm going to repeat it.


Yes, we hear you.

Fedora's Python version migration needs to be coordinated with RHEL.


It is. However it is hard to coordinate a future change with RHEL7
that is kinda designed not to change much.


It isn't with just RHEL7. Customers of RHEL are probably going to want 
to run their python2 code for years after it is EOL. If something has 
been written as part of a regulatory compliance (say a plane/car/rocket 
simulation).. that code is locked for 20 years whether the language 
below is alive or not. If the code was written for infrastructure it 
might be 60 years. So as Python became the goto language for science and 
engineering.. it has also become the language of regulations and other 
things. RHELn may still need to have python be able to point to python2 
because customers need it for reasons we in Fedora or the Python 
community do not care about.


 From the conversations, this is the part that seems less explored.


Because we discuss those things trough Red Hat channels.

--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Finalizing Fedora's Switch to Python 3


On 28.7.2017 18:41, Colin Walters wrote:

On Fri, Jul 28, 2017, at 12:16 PM, Miro Hrončok wrote:


It's up to the maintainers of Atomic Host to decide what's there. I
don't see how that relates to this thread. We have never said anything
about what is supposed to be or not to be in the Atomic Host.


I'm opposed to switching the meaning of `/usr/bin/python` for AH
anytime soon.  It's just going to break stuff, and to me the gain is quite
low.  If you still propose to make that change for other editions and in the 
Everything repository,
we'll likely need to override it.

Regardless, I can certainly take care of updating the Change proposal to mention
that the `/usr/bin/python` portion doesn't apply to AH, and we'll continue
to have `python2` installed by default, if that's OK with you?


As long as you figure out how to do it properly and as long as you 
represent the AH maintainers and can make that decision for AH, I think 
it's probably OK to put it there (I still don't like it personally, but 
that's not good enough reason to not do it).


What about this:

Note that after Phase 1, nothing in Fedora uses /usr/bin/python any 
more, so it should be safe for sysadmins to flip the symblink back to 
python2 and we should provide a documented and supported way of doing 
so. In the same way, the Atomic Host will keep /usr/bin/python pointing 
to Python 2 regardless of rest of Fedora and possibly against upstream 
recommendation in PEP 394, because of [reasons].


--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
___
python-devel mailing list -- python-devel@lists.fedoraproject.org
To unsubscribe send an email to python-devel-le...@lists.fedoraproject.org

Re: Finalizing Fedora's Switch to Python 3


On 28.7.2017 18:41, Colin Walters wrote:

On Fri, Jul 28, 2017, at 12:16 PM, Miro Hrončok wrote:


It's up to the maintainers of Atomic Host to decide what's there. I
don't see how that relates to this thread. We have never said anything
about what is supposed to be or not to be in the Atomic Host.


I'm opposed to switching the meaning of `/usr/bin/python` for AH
anytime soon.  It's just going to break stuff, and to me the gain is quite
low.  If you still propose to make that change for other editions and in the 
Everything repository,
we'll likely need to override it.

Regardless, I can certainly take care of updating the Change proposal to mention
that the `/usr/bin/python` portion doesn't apply to AH, and we'll continue
to have `python2` installed by default, if that's OK with you?


As long as you figure out how to do it properly and as long as you 
represent the AH maintainers and can make that decision for AH, I think 
it's probably OK to put it there (I still don't like it personally, but 
that's not good enough reason to not do it).


What about this:

Note that after Phase 1, nothing in Fedora uses /usr/bin/python any 
more, so it should be safe for sysadmins to flip the symblink back to 
python2 and we should provide a documented and supported way of doing 
so. In the same way, the Atomic Host will keep /usr/bin/python pointing 
to Python 2 regardless of rest of Fedora and possibly against upstream 
recommendation in PEP 394, because of [reasons].


--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Finalizing Fedora's Switch to Python 3

2017-07-28 Thread Randy Barlow

On Fri, 2017-07-28 at 12:41 -0400, Colin Walters wrote:
> I'm opposed to switching the meaning of `/usr/bin/python` for AH
> anytime soon.  It's just going to break stuff, and to me the gain is
> quite
> low.

One of Fedora's stated goals is to remain close to the upstream.
Upstream Python is going to change /usr/bin/python to mean Python 3. If
AH keeps it on Python 2, it will be confusing for Python programmers
using AH. It will be especially confusing for programmers who want to
write software that works on "normal" Fedora and AH. Also, as software
begins to switch AH will have to patch its Python packages, diverging
from the rest of Fedora.

> Regardless, I can certainly take care of updating the Change proposal
> to mention
> that the `/usr/bin/python` portion doesn't apply to AH, and we'll
> continue
> to have `python2` installed by default, if that's OK with you?

I think this will cause a poor experience for Fedora users. Python
packages would work one way in AH, but work differently in the rest of
the Fedora editions.

I don't see a practical advantage to divergence. I believe the
divergence will break stuff in a more confusing manner than the change
will.

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

Re: ppc64le build failure, does it look familiar?

2017-07-28 Thread Antonio Trande

Yes, https://bugzilla.redhat.com/show_bug.cgi?id=1475636

On 07/28/2017 07:06 PM, Kaleb S. KEITHLEY wrote:
> 
> More ceph-12.1.1
> 
> This has built successfully previously, including the recent mass
> rebuild. Today the other associated builds have either finished or
> passed this point, but on the ppc64le build today I got this:
> 
> ...
> Executing command: ['bash', '--login', '-c', '/usr/bin/rpmbuild -bb
> --target ppc64le --nodeps /builddir/build/SPECS/ceph.spec'] with env
> {'SHELL': '/bin/bash', 'PROMPT_COMMAND': 'printf
> "\\033]0;\\007"', 'HOME': '/builddir', 'HOSTNAME': 'mock',
> 'PS1': ' \\s-\\v\\$ ', 'LANG': 'en_US.UTF-8', 'TERM':
> 'vt100', 'PATH': '/usr/bin:/bin:/usr/sbin:/sbin'} and shell False
> /usr/bin/lua: error loading module 'posix.ctype' from file
> '/usr/lib64/lua/5.3/posix.so':
>   /lib64/librt.so.1: expected localentry:0 `pthread_attr_setdetachstate'
> stack traceback:
>   [C]: in ?
>   [C]: in function 'require'
>   /usr/share/lua/5.3/posix/init.lua:29: in main chunk
>   [C]: in function 'require'
>   /usr/share/lmod/lmod/libexec/addto:64: in main chunk
>   [C]: in ?
> /usr/bin/lua: error loading module 'posix.ctype' from file
> '/usr/lib64/lua/5.3/posix.so':
>   /lib64/librt.so.1: expected localentry:0 `pthread_attr_setdetachstate'
> stack traceback:
>   [C]: in ?
>   [C]: in function 'require'
>   /usr/share/lua/5.3/posix/init.lua:29: in main chunk
>   [C]: in function 'require'
>   /usr/share/lmod/lmod/libexec/addto:64: in main chunk
>   [C]: in ?
> /usr/bin/lua: error loading module 'posix.ctype' from file
> '/usr/lib64/lua/5.3/posix.so':
>   /lib64/librt.so.1: expected localentry:0 `pthread_attr_setdetachstate'
> stack traceback:
>   [C]: in ?
>   [C]: in function 'require'
>   /usr/share/lua/5.3/posix/init.lua:29: in main chunk
>   [C]: in function 'require'
>   /usr/share/lmod/lmod/libexec/addto:64: in main chunk
>   [C]: in ?
> /usr/bin/ps: error while loading shared libraries: /lib64/librt.so.1:
> expected localentry:0 `pthread_attr_setdetachstate'
> /usr/bin/basename: missing operand
> Try '/usr/bin/basename --help' for more information.
> Building target platforms: ppc64le
> ...
> 
> Full build log at
> https://kojipkgs.fedoraproject.org//work/tasks/6424/20856424/build.log
> 
> Look familiar to anyone?
> 
> Thanks,
> 

-- 
--
Antonio Trande
sagitter AT fedoraproject dot org
See my vCard.
<>

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

Summary/Minutes from today's FESCo Meeting (2017-07-28)

2017-07-28 Thread Jared K. Smith

We had a short meeting today because we lost quorum part-way through
the meeting.


===
#fedora-meeting: FESCO (2017-07-28)
===


Meeting started by jsmith at 16:01:24 UTC. The full logs are available
athttps://meetbot.fedoraproject.org/fedora-meeting/2017-07-28/fesco.2017-07-28-16.01.log.html
.



Meeting summary
---
* init process  (jsmith, 16:01:25)

* Follow-ups  (jsmith, 16:13:28)

* #1736 - Don't automatically close security bugs on Fedora EOL
  (jsmith, 16:13:28)
  * LINK: https://pagure.io/fesco/issue/1736   (jsmith, 16:13:28)
  * AGREED: #1736 Enumerate various ideas i nthe ticket and on the list,
and revist next week (+1:5, +0:0, -1:0)  (jsmith, 16:23:25)

* #1737 - Proposal: i686 SIG needs to be functional by F27 release date
  (jsmith, 16:23:41)
  * LINK: https://pagure.io/fesco/issue/1737   (jsmith, 16:23:41)
  * AGREED: #1737 Defer to next week due to lack of quorum.  (jsmith,
16:39:06)

* Next week's chair  (jsmith, 16:41:29)

* Election reminder  (jsmith, 16:43:04)
  * 16:43 < jsmith> Just a reminder of the upcoming elections -- do you
part -- nominate yourself or a friend, and participate in the
elections.  (dgilmore, 16:43:57)

* Open Floor  (jsmith, 16:44:15)
  * LINK: https://pagure.io/releng/issue/6898#comment-450892
(dgilmore, 16:48:38)

Meeting ended at 16:58:20 UTC.




Action Items






Action Items, by person
---
* **UNASSIGNED**
  * (none)
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: ppc64le build failure, does it look familiar?

2017-07-28 Thread Tomasz Torcz

On Fri, Jul 28, 2017 at 01:06:18PM -0400, Kaleb S. KEITHLEY wrote:
> 
>   /lib64/librt.so.1: expected localentry:0 `pthread_attr_setdetachstate'

See the thread “Mass rebuild failures only on ppc64le: glibc problem?” by Tibbs.

> Look familiar to anyone?

-- 
Tomasz Torcz   "Never underestimate the bandwidth of a station
xmpp: zdzich...@chrome.plwagon filled with backup tapes." -- Jim Gray
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

ppc64le build failure, does it look familiar?

2017-07-28 Thread Kaleb S. KEITHLEY


More ceph-12.1.1

This has built successfully previously, including the recent mass
rebuild. Today the other associated builds have either finished or
passed this point, but on the ppc64le build today I got this:

...
Executing command: ['bash', '--login', '-c', '/usr/bin/rpmbuild -bb
--target ppc64le --nodeps /builddir/build/SPECS/ceph.spec'] with env
{'SHELL': '/bin/bash', 'PROMPT_COMMAND': 'printf
"\\033]0;\\007"', 'HOME': '/builddir', 'HOSTNAME': 'mock',
'PS1': ' \\s-\\v\\$ ', 'LANG': 'en_US.UTF-8', 'TERM':
'vt100', 'PATH': '/usr/bin:/bin:/usr/sbin:/sbin'} and shell False
/usr/bin/lua: error loading module 'posix.ctype' from file
'/usr/lib64/lua/5.3/posix.so':
/lib64/librt.so.1: expected localentry:0 `pthread_attr_setdetachstate'
stack traceback:
[C]: in ?
[C]: in function 'require'
/usr/share/lua/5.3/posix/init.lua:29: in main chunk
[C]: in function 'require'
/usr/share/lmod/lmod/libexec/addto:64: in main chunk
[C]: in ?
/usr/bin/lua: error loading module 'posix.ctype' from file
'/usr/lib64/lua/5.3/posix.so':
/lib64/librt.so.1: expected localentry:0 `pthread_attr_setdetachstate'
stack traceback:
[C]: in ?
[C]: in function 'require'
/usr/share/lua/5.3/posix/init.lua:29: in main chunk
[C]: in function 'require'
/usr/share/lmod/lmod/libexec/addto:64: in main chunk
[C]: in ?
/usr/bin/lua: error loading module 'posix.ctype' from file
'/usr/lib64/lua/5.3/posix.so':
/lib64/librt.so.1: expected localentry:0 `pthread_attr_setdetachstate'
stack traceback:
[C]: in ?
[C]: in function 'require'
/usr/share/lua/5.3/posix/init.lua:29: in main chunk
[C]: in function 'require'
/usr/share/lmod/lmod/libexec/addto:64: in main chunk
[C]: in ?
/usr/bin/ps: error while loading shared libraries: /lib64/librt.so.1:
expected localentry:0 `pthread_attr_setdetachstate'
/usr/bin/basename: missing operand
Try '/usr/bin/basename --help' for more information.
Building target platforms: ppc64le
...

Full build log at
https://kojipkgs.fedoraproject.org//work/tasks/6424/20856424/build.log

Look familiar to anyone?

Thanks,

-- 

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

Re: Finalizing Fedora's Switch to Python 3

On Fri, Jul 28, 2017, at 12:16 PM, Miro Hrončok wrote:

> It's up to the maintainers of Atomic Host to decide what's there. I 
> don't see how that relates to this thread. We have never said anything 
> about what is supposed to be or not to be in the Atomic Host.

I'm opposed to switching the meaning of `/usr/bin/python` for AH
anytime soon.  It's just going to break stuff, and to me the gain is quite
low.  If you still propose to make that change for other editions and in the 
Everything repository,
we'll likely need to override it.

Regardless, I can certainly take care of updating the Change proposal to mention
that the `/usr/bin/python` portion doesn't apply to AH, and we'll continue
to have `python2` installed by default, if that's OK with you?
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Finalizing Fedora's Switch to Python 3

2017-07-28 Thread Stephen John Smoogen

On 28 July 2017 at 11:42, Miro Hrončok  wrote:

> On 28.7.2017 16:25, John Dennis wrote:
>
>> I made this comment previously but because I think it's important I'm
>> going to repeat it.
>>
>
> Yes, we hear you.
>
> Fedora's Python version migration needs to be coordinated with RHEL.
>>
>
> It is. However it is hard to coordinate a future change with RHEL7 that is
> kinda designed not to change much.
>
>
It isn't with just RHEL7. Customers of RHEL are probably going to want to
run their python2 code for years after it is EOL. If something has been
written as part of a regulatory compliance (say a plane/car/rocket
simulation).. that code is locked for 20 years whether the language below
is alive or not. If the code was written for infrastructure it might be 60
years. So as Python became the goto language for science and engineering..
it has also become the language of regulations and other things. RHELn may
still need to have python be able to point to python2 because customers
need it for reasons we in Fedora or the Python community do not care about.

>From the conversations, this is the part that seems less explored.


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

Re: Finalizing Fedora's Switch to Python 3

2017-07-28 Thread Stephen John Smoogen

On 28 July 2017 at 11:42, Miro Hrončok  wrote:

> On 28.7.2017 16:25, John Dennis wrote:
>
>> I made this comment previously but because I think it's important I'm
>> going to repeat it.
>>
>
> Yes, we hear you.
>
> Fedora's Python version migration needs to be coordinated with RHEL.
>>
>
> It is. However it is hard to coordinate a future change with RHEL7 that is
> kinda designed not to change much.
>
>
It isn't with just RHEL7. Customers of RHEL are probably going to want to
run their python2 code for years after it is EOL. If something has been
written as part of a regulatory compliance (say a plane/car/rocket
simulation).. that code is locked for 20 years whether the language below
is alive or not. If the code was written for infrastructure it might be 60
years. So as Python became the goto language for science and engineering..
it has also become the language of regulations and other things. RHELn may
still need to have python be able to point to python2 because customers
need it for reasons we in Fedora or the Python community do not care about.

>From the conversations, this is the part that seems less explored.


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

Re: Finalizing Fedora's Switch to Python 3

2017-07-28 Thread Stephen John Smoogen

On 28 July 2017 at 08:29, Nick Coghlan  wrote:

> On 28 July 2017 at 20:48, Colin Walters  wrote:
> > On Thu, Jul 27, 2017, at 12:07 PM, Miro Hrončok wrote:
> >
> >>   * Switch /usr/bin/python to Python 3 in cooperation with Python
> upstream.
> >
> > That again?  That really seems like a nonstarter; previous
> > discussion specifically around Atomic Host + Ansible:
> > https://lists.fedoraproject.org/archives/list/devel@lists.
> fedoraproject.org/thread/T4PGIEUYXWXSDRVWYQ2BJXCECL45XWVW/
> >
> > Plus just breaking everyone's random old scripts.
>
> Option 1: *guarantee* breaking old scripts by removing
> "/usr/bin/python" entirely (current status quo on Py3-only Fedora
> systems)
>

>From having dealt with this from a support side during the python1 ->
python2 changes .. this is probably preferable. There are going to be the
scripts which work well enough but not the same. And there are the scripts
which won't work until it hits a part that isn't python3 compatible.

Having python set up as an alternatives would probably be the Debian-ish
like solution in that if you want to have your box running python3 only you
can switch using that.. and if not you can switch it to the other. And if
for some reason we decided that Jython was better than the Cpython.. you
can do that.

>
>

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

Re: Finalizing Fedora's Switch to Python 3


On 28.7.2017 17:51, Colin Walters wrote:



On Fri, Jul 28, 2017, at 11:34 AM, Miro Hrončok wrote:

The change has to
start somewhere and even though I cannot really speak about RHEL,
I would think that changing it in Fedora first makes more sense.


There hasn't been a single "Fedora" since we landed the editions,
although that's somewhat superficial.  With Modularity there will
*really* no longer be one "Fedora".  Want to drop python2 out of
the container base image?   Actually, that's done already!  I'm
all for that.  Anyone who wants python2 in their containers
is probably going to be choosing centos/rhel anyways.

Dropping python2 from Workstation?  Sure, sounds fine to me, I
don't care much personally.   I'm just pushing back against that change
landing for Atomic Host.


It's up to the maintainers of Atomic Host to decide what's there. I 
don't see how that relates to this thread. We have never said anything 
about what is supposed to be or not to be in the Atomic Host.


--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Finalizing Fedora's Switch to Python 3


On 28.7.2017 17:51, Colin Walters wrote:



On Fri, Jul 28, 2017, at 11:34 AM, Miro Hrončok wrote:

The change has to
start somewhere and even though I cannot really speak about RHEL,
I would think that changing it in Fedora first makes more sense.


There hasn't been a single "Fedora" since we landed the editions,
although that's somewhat superficial.  With Modularity there will
*really* no longer be one "Fedora".  Want to drop python2 out of
the container base image?   Actually, that's done already!  I'm
all for that.  Anyone who wants python2 in their containers
is probably going to be choosing centos/rhel anyways.

Dropping python2 from Workstation?  Sure, sounds fine to me, I
don't care much personally.   I'm just pushing back against that change
landing for Atomic Host.


It's up to the maintainers of Atomic Host to decide what's there. I 
don't see how that relates to this thread. We have never said anything 
about what is supposed to be or not to be in the Atomic Host.


--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
___
python-devel mailing list -- python-devel@lists.fedoraproject.org
To unsubscribe send an email to python-devel-le...@lists.fedoraproject.org

[389-devel] Please review: ticket 49334: backup fails if changelog is enabled

2017-07-28 Thread Ludwig Krispenz


https://pagure.io/389-ds-base/issue/49334
https://pagure.io/389-ds-base/issue/raw/files/ce2d76220df07c7142ec745496ebb763f28e174f5a698f4948f770b6417c1ae8-0001-Ticket-49334-fix-backup-restore-if-changelog-exists.patch

--
Red Hat GmbH, http://www.de.redhat.com/, Registered seat: Grasbrunn,
Commercial register: Amtsgericht Muenchen, HRB 153243,
Managing Directors: Charles Cachera, Michael Cunningham, Michael O'Neill, Eric 
Shander
___
389-devel mailing list -- 389-devel@lists.fedoraproject.org
To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org

Re: Finalizing Fedora's Switch to Python 3

On Fri, Jul 28, 2017, at 11:34 AM, Miro Hrončok wrote:
> The change has to 
> start somewhere and even though I cannot really speak about RHEL,
> I would think that changing it in Fedora first makes more sense.

There hasn't been a single "Fedora" since we landed the editions,
although that's somewhat superficial.  With Modularity there will
*really* no longer be one "Fedora".  Want to drop python2 out of
the container base image?   Actually, that's done already!  I'm
all for that.  Anyone who wants python2 in their containers
is probably going to be choosing centos/rhel anyways.

Dropping python2 from Workstation?  Sure, sounds fine to me, I
don't care much personally.   I'm just pushing back against that change
landing for Atomic Host.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Finalizing Fedora's Switch to Python 3


On 28.7.2017 16:25, John Dennis wrote:
I made this comment previously but because I think it's important I'm 
going to repeat it.


Yes, we hear you.


Fedora's Python version migration needs to be coordinated with RHEL.


It is. However it is hard to coordinate a future change with RHEL7 that 
is kinda designed not to change much.


Yes I know Fedora is independent of both Red Hat and RHEL but the real 
world reality is spec files are shared between both. At the moment you 
cannot easily share a spec file between the two, this leads to 
maintaining two independent spec files for something that ought to be 
nearly identical and increases the burden on package maintainers and 
increases the opportunity for errors.


We added a Q section that says something about sharing a specfile 
across Fedora and EPEL [1].


It doesn't speak about RHEL, because AFAIK adding macros to RHEL7 (or 
even RHEL6) may be a bit complicated. However changing one's packages 
form RHEL to use those new macros might be as complicated as that.
If you have packages in RHEL and Fedora that have identical spec files 
and you update them in RHEL regularly when you update them in Fedora, 
please contact us trough Red Hat channels so we can craft a solution 
that works for you.


If you share specfiles across EPEL and Fedora, use the proposed solution 
from the Q section.


[1] https://fedoraproject.org/wiki/FinalizingFedoraSwitchtoPython3#Q.26A


The transition is already going to be painful, let's not make it more 
painful than it needs to be.


Believe me, we are trying hard not to.

At a minimum the set of RPM macros to manage the difference between 
Python versions needs to be identically supported in both Fedora and 
RHEL. I'd like to see this as an explicit goal of the transition strategy.


I don't want to discuss RHEL related strategies on a public ML, again 
feel free to contact us trough Red Hat channels, if you want to hear more.

--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
___
python-devel mailing list -- python-devel@lists.fedoraproject.org
To unsubscribe send an email to python-devel-le...@lists.fedoraproject.org

Re: Finalizing Fedora's Switch to Python 3


On 28.7.2017 16:25, John Dennis wrote:
I made this comment previously but because I think it's important I'm 
going to repeat it.


Yes, we hear you.


Fedora's Python version migration needs to be coordinated with RHEL.


It is. However it is hard to coordinate a future change with RHEL7 that 
is kinda designed not to change much.


Yes I know Fedora is independent of both Red Hat and RHEL but the real 
world reality is spec files are shared between both. At the moment you 
cannot easily share a spec file between the two, this leads to 
maintaining two independent spec files for something that ought to be 
nearly identical and increases the burden on package maintainers and 
increases the opportunity for errors.


We added a Q section that says something about sharing a specfile 
across Fedora and EPEL [1].


It doesn't speak about RHEL, because AFAIK adding macros to RHEL7 (or 
even RHEL6) may be a bit complicated. However changing one's packages 
form RHEL to use those new macros might be as complicated as that.
If you have packages in RHEL and Fedora that have identical spec files 
and you update them in RHEL regularly when you update them in Fedora, 
please contact us trough Red Hat channels so we can craft a solution 
that works for you.


If you share specfiles across EPEL and Fedora, use the proposed solution 
from the Q section.


[1] https://fedoraproject.org/wiki/FinalizingFedoraSwitchtoPython3#Q.26A


The transition is already going to be painful, let's not make it more 
painful than it needs to be.


Believe me, we are trying hard not to.

At a minimum the set of RPM macros to manage the difference between 
Python versions needs to be identically supported in both Fedora and 
RHEL. I'd like to see this as an explicit goal of the transition strategy.


I don't want to discuss RHEL related strategies on a public ML, again 
feel free to contact us trough Red Hat channels, if you want to hear more.

--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Finalizing Fedora's Switch to Python 3

On 28.7.2017 16:17, Colin Walters wrote:

On Fri, Jul 28, 2017, at 07:47 AM, Peter Robinson wrote:

On Fri, Jul 28, 2017 at 11:48 AM, Colin Walters wrote:

On Thu, Jul 27, 2017, at 12:07 PM, Miro Hrončok wrote:

* Switch /usr/bin/python to Python 3 in cooperation with Python upstream.

That again? That really seems like a nonstarter; previous
discussion specifically around Atomic Host + Ansible:
https://lists.fedoraproject.org/archives/list/de...@lists.fedoraproject.org/thread/T4PGIEUYXWXSDRVWYQ2BJXCECL45XWVW/

Ansible now supports clients that are py3 only and there's active work
[1] to enable py3 for the controller as well.

Yes. But basically, I don't think we can rely on everyone porting their Ansible
code to Python3 anytime soon. Among other reasons, many, many organizations
will need their Ansible (and in general, "config mgmt/scripting") to work across
RHEL7 and Fedora hosts. For Fedora Atomic Host (which may be different from
Workstation!) I don't see dropping /usr/bin/python as python2 until RHEL7 is
near EOL. Maybe we don't do security updates for it etc., but still.

If we don't switch it in Fedora until RHEL7 is near EOL, it will neither
be changed in any hypothetical future versions of RHEL, because RHEL
tends to be based on Fedora. And than you can say that we cannot do the
switch in Fedora until that hypothetical future version of RHEL is near
EOL and you will end up never changing it at all. The change has to
start somewhere and even though I cannot really speak about RHEL,

I would think that changing it in Fedora first makes more sense.

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

--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
___
python-devel mailing list -- python-devel@lists.fedoraproject.org
To unsubscribe send an email to python-devel-le...@lists.fedoraproject.org

Re: Finalizing Fedora's Switch to Python 3

On 28.7.2017 16:17, Colin Walters wrote:

On Fri, Jul 28, 2017, at 07:47 AM, Peter Robinson wrote:

On Fri, Jul 28, 2017 at 11:48 AM, Colin Walters wrote:

On Thu, Jul 27, 2017, at 12:07 PM, Miro Hrončok wrote:

* Switch /usr/bin/python to Python 3 in cooperation with Python upstream.

That again? That really seems like a nonstarter; previous
discussion specifically around Atomic Host + Ansible:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/T4PGIEUYXWXSDRVWYQ2BJXCECL45XWVW/

Ansible now supports clients that are py3 only and there's active work
[1] to enable py3 for the controller as well.

I would think that changing it in Fedora first makes more sense.

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

--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Finalizing Fedora's Switch to Python 3


On 28.7.2017 14:29, Brian Exelbierd wrote:

On Fri, Jul 28, 2017, at 12:48 PM, Colin Walters wrote:

On Thu, Jul 27, 2017, at 12:07 PM, Miro Hrončok wrote:


   * Switch /usr/bin/python to Python 3 in cooperation with Python upstream.


That again?  That really seems like a nonstarter; previous
discussion specifically around Atomic Host + Ansible:
https://lists.fedoraproject.org/archives/list/de...@lists.fedoraproject.org/thread/T4PGIEUYXWXSDRVWYQ2BJXCECL45XWVW/

Plus just breaking everyone's random old scripts.  Now, I
don't know if this has been discussed upstream


This is a statement born of ignorance, but ...

Would it be possible to switch the default from python2 to python3 and
provide an RPM that would switch it back?  This way people who needed to
stay on python2 for some time period to clean up legacy components
before teh 2020 EOL could.


Not yet sure about the actual technical solution here, but we are 
planning for this use case, see [1]:


"Note that after Phase 1, nothing in Fedora uses /usr/bin/python any 
more, so it should be safe for sysadmins to flip the symblink back to 
python2 and we should provide a documented and supported way of doing so."


[1] 
https://fedoraproject.org/wiki/FinalizingFedoraSwitchtoPython3#Phase_2:_Switch_python_to_refer_to_python3




I realize that package renaming and things like that will move forward
regardless and should.

regards,

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



--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
___
python-devel mailing list -- python-devel@lists.fedoraproject.org
To unsubscribe send an email to python-devel-le...@lists.fedoraproject.org

Re: Finalizing Fedora's Switch to Python 3


On 28.7.2017 14:29, Brian Exelbierd wrote:

On Fri, Jul 28, 2017, at 12:48 PM, Colin Walters wrote:

On Thu, Jul 27, 2017, at 12:07 PM, Miro Hrončok wrote:


   * Switch /usr/bin/python to Python 3 in cooperation with Python upstream.


That again?  That really seems like a nonstarter; previous
discussion specifically around Atomic Host + Ansible:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/T4PGIEUYXWXSDRVWYQ2BJXCECL45XWVW/

Plus just breaking everyone's random old scripts.  Now, I
don't know if this has been discussed upstream


This is a statement born of ignorance, but ...

Would it be possible to switch the default from python2 to python3 and
provide an RPM that would switch it back?  This way people who needed to
stay on python2 for some time period to clean up legacy components
before teh 2020 EOL could.


Not yet sure about the actual technical solution here, but we are 
planning for this use case, see [1]:


"Note that after Phase 1, nothing in Fedora uses /usr/bin/python any 
more, so it should be safe for sysadmins to flip the symblink back to 
python2 and we should provide a documented and supported way of doing so."


[1] 
https://fedoraproject.org/wiki/FinalizingFedoraSwitchtoPython3#Phase_2:_Switch_python_to_refer_to_python3




I realize that package renaming and things like that will move forward
regardless and should.

regards,

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



--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Finalizing Fedora's Switch to Python 3

On 28.7.2017 12:48, Colin Walters wrote:

On Thu, Jul 27, 2017, at 12:07 PM, Miro Hrončok wrote:

   * Switch /usr/bin/python to Python 3 in cooperation with Python upstream.

That again?

Seems like a never ending story, right? :(

> That really seems like a nonstarter; previous> discussion 
specifically around Atomic Host + Ansible:

https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/T4PGIEUYXWXSDRVWYQ2BJXCECL45XWVW/

Plus just breaking everyone's random old scripts.

Actually, we are trying to avoid that. In the corresponding part of the 
document [1], we actually say:

"Note that after Phase 1, nothing in Fedora uses /usr/bin/python any 
more, so it should be safe for sysadmins to flip the symblink back to 
python2 and we should provide a documented and supported way of doing so."

> Now, I> don't know if this has been discussed upstream,

It is being discussed upstream right now and the discussion is linked 
from the relevant part of the document [2][3].

> but one> thing to do possibly would be to have an interactive shell

alias for `python` = `ipython3` or something like that, and
switch `ipython` to `ipython3`.

[1] 
https://fedoraproject.org/wiki/FinalizingFedoraSwitchtoPython3#Phase_2:_Switch_python_to_refer_to_python3
[2] 
https://fedoraproject.org/wiki/FinalizingFedoraSwitchtoPython3#Interlude:_Update_PEP_394_.28not_a_Fedora_Change.29

[3] https://mail.python.org/pipermail/linux-sig/2017-July/29.html

--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Finalizing Fedora's Switch to Python 3

On 28.7.2017 12:48, Colin Walters wrote:

On Thu, Jul 27, 2017, at 12:07 PM, Miro Hrončok wrote:

   * Switch /usr/bin/python to Python 3 in cooperation with Python upstream.

That again?

Seems like a never ending story, right? :(

> That really seems like a nonstarter; previous> discussion 
specifically around Atomic Host + Ansible:

https://lists.fedoraproject.org/archives/list/de...@lists.fedoraproject.org/thread/T4PGIEUYXWXSDRVWYQ2BJXCECL45XWVW/

Plus just breaking everyone's random old scripts.

Actually, we are trying to avoid that. In the corresponding part of the 
document [1], we actually say:

"Note that after Phase 1, nothing in Fedora uses /usr/bin/python any 
more, so it should be safe for sysadmins to flip the symblink back to 
python2 and we should provide a documented and supported way of doing so."

> Now, I> don't know if this has been discussed upstream,

It is being discussed upstream right now and the discussion is linked 
from the relevant part of the document [2][3].

> but one> thing to do possibly would be to have an interactive shell

alias for `python` = `ipython3` or something like that, and
switch `ipython` to `ipython3`.

[1] 
https://fedoraproject.org/wiki/FinalizingFedoraSwitchtoPython3#Phase_2:_Switch_python_to_refer_to_python3
[2] 
https://fedoraproject.org/wiki/FinalizingFedoraSwitchtoPython3#Interlude:_Update_PEP_394_.28not_a_Fedora_Change.29

[3] https://mail.python.org/pipermail/linux-sig/2017-July/29.html

--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
___
python-devel mailing list -- python-devel@lists.fedoraproject.org
To unsubscribe send an email to python-devel-le...@lists.fedoraproject.org

Re: Finalizing Fedora's Switch to Python 3


On 28.7.2017 12:01, Zbigniew Jędrzejewski-Szmek wrote:

On Fri, Jul 28, 2017 at 09:49:42AM +0200, Miro Hrončok wrote:

On 27.7.2017 19:15, Zbigniew Jędrzejewski-Szmek wrote:

Do you think it'd be possible to script the python-foo to python2-foo
renaming?


May be possible but given the variety in the spec files, we didn't
think it would be easy. IMHO taking a bunch of provenpackagers and
updating the packages manually without asking the owners will be
less time consuming than creating an automated tool.

However, in both scenarios (people or tools), I consider that
approach aggressive and would rather only do it when the deadlines
are close.
We'd rather not change other people packages and make them mad about
what have we done. The transition to Python 3 is unfortunately
considered a failure in eyes of some Fedora contributors.

[My original comment here has been deleted to protect the innocent ;) ]


I consider communicating our efforts with the package owners and
explaining them what and how to do as more friendly approach.
However, definitively more time expensive.


On the other hand, maybe we can start updating the packages co-owned
by python-sig, as I would say those are considered to be maintained
by the group rather than a person. In case you'd like to try to
write an automated tool for that, please go ahead (but please let us
know).


I don't know if delaying this will help. Actually stretching out the
transition might make things more painful, because it'll increase the
window where you don't know if any given python package has python2-
or python- prefix, so you need to check all deps. I'm sure getting rid
of this ambiguity would be welcome.

So instead of taking this slowly, I'd rather go through FESCo
and public announcement on fedora-devel, and then just apply the change
to as many packages as possible at once. Technically, I think it would
be reasonable to try to script this, w/o pushing to dist git, then put
up the diffs for review somewhere, and then finally push at once, at get
a few pps to do the rebuilds (some stuff is bound to fail for related
or unrelated reasons, so some debugging is expected).

In the other mail Nick Coghlan listed various steps: it's far from
trivial, but OTOH doing 800+ packages by hand ain't gonna be fun either.
I'll try to look into this over the weekend, it sounds like a fun
challenge.


Thanks, feel free to reach out any time for help.



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



--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Finalizing Fedora's Switch to Python 3


On 28.7.2017 09:51, Nick Coghlan wrote:

On 28 July 2017 at 03:15, Zbigniew Jędrzejewski-Szmek  wrote:

Do you think it'd be possible to script the python-foo to python2-foo
renaming? If yes, then maybe it'd make sense to just get some pps to
do it in rawhide now and get the "easy" part done with? That should
significantly cut down on the number of misnamed packages and let
packagers spend their times on the ones where the automatic way is not
obvious.


I was going to ask whether it might be possible to tweak
http://fedora.portingdb.xyz/ to also report on compliance with the
naming policy, but then I went and saw that it *does* already report
on that: http://fedora.portingdb.xyz/namingpolicy/

While it also turns out the wiki page already links to that page, it
may be good to call it out a second time in a "How can I help?"
section.


I've just added that section. However, feel free to reword it or add 
stuff. Thanks for the suggestion.



Checking an initial sampling of spec files (python-d2to1,
python-BeautfulSoup, python-amqplib) suggests to me that a script
implementing the following rules might offer a reasonably start point,
at least for Python-2-only modules that are remaining Python-2-only:

- immediately before the first BuildRequires or Requires entry, add a
%package section header for "-n python2-" (where "" is the
lowercased package source name with any "python-" prefix stripped)
- add a %python_provides entry after the new package header in
accordance with the current guidelines
- if the original package provided a non-lowercase "python-*"
provides, remote it and add a second %python_provides with the
original capitalisation
- if the source package lacks the "python-" prefix, add a virtual
provides for the unqualified package name
- add a "-n python2-" qualifier to any currently unqualified
description and files sections


This get's problematic once there spec files are full of macros.
However, feel free to work with Zbyszek, maybe you'll find it less 
complicating than we did.



A script like that may even do a tolerable job for packages that *do*
offer Python 3 subpackages (since those will already have qualifiers,
and will necessarily appear after any unqualified runtime and build
requirements for the default subpackage).

Cheers,
Nick.



--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
___
python-devel mailing list -- python-devel@lists.fedoraproject.org
To unsubscribe send an email to python-devel-le...@lists.fedoraproject.org

Re: Finalizing Fedora's Switch to Python 3


On 28.7.2017 09:51, Nick Coghlan wrote:

On 28 July 2017 at 03:15, Zbigniew Jędrzejewski-Szmek  wrote:

Do you think it'd be possible to script the python-foo to python2-foo
renaming? If yes, then maybe it'd make sense to just get some pps to
do it in rawhide now and get the "easy" part done with? That should
significantly cut down on the number of misnamed packages and let
packagers spend their times on the ones where the automatic way is not
obvious.


I was going to ask whether it might be possible to tweak
http://fedora.portingdb.xyz/ to also report on compliance with the
naming policy, but then I went and saw that it *does* already report
on that: http://fedora.portingdb.xyz/namingpolicy/

While it also turns out the wiki page already links to that page, it
may be good to call it out a second time in a "How can I help?"
section.


I've just added that section. However, feel free to reword it or add 
stuff. Thanks for the suggestion.



Checking an initial sampling of spec files (python-d2to1,
python-BeautfulSoup, python-amqplib) suggests to me that a script
implementing the following rules might offer a reasonably start point,
at least for Python-2-only modules that are remaining Python-2-only:

- immediately before the first BuildRequires or Requires entry, add a
%package section header for "-n python2-" (where "" is the
lowercased package source name with any "python-" prefix stripped)
- add a %python_provides entry after the new package header in
accordance with the current guidelines
- if the original package provided a non-lowercase "python-*"
provides, remote it and add a second %python_provides with the
original capitalisation
- if the source package lacks the "python-" prefix, add a virtual
provides for the unqualified package name
- add a "-n python2-" qualifier to any currently unqualified
description and files sections


This get's problematic once there spec files are full of macros.
However, feel free to work with Zbyszek, maybe you'll find it less 
complicating than we did.



A script like that may even do a tolerable job for packages that *do*
offer Python 3 subpackages (since those will already have qualifiers,
and will necessarily appear after any unqualified runtime and build
requirements for the default subpackage).

Cheers,
Nick.



--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Finalizing Fedora's Switch to Python 3

On 29 July 2017 at 00:25, John Dennis  wrote:
> I made this comment previously but because I think it's important I'm going
> to repeat it.
>
> Fedora's Python version migration needs to be coordinated with RHEL.
>
> Yes I know Fedora is independent of both Red Hat and RHEL but the real world
> reality is spec files are shared between both. At the moment you cannot
> easily share a spec file between the two, this leads to maintaining two
> independent spec files for something that ought to be nearly identical and
> increases the burden on package maintainers and increases the opportunity
> for errors.

Aye, I agree we should be actively seeking to make single-spec
feasible across Fedora/RHEL/CentOS, at least in combination with EPEL
(without the EPEL dependency, it's hard to consistently make new
Fedora level macro definitions available to older EL releases).

Cheers,
Nick.

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
___
python-devel mailing list -- python-devel@lists.fedoraproject.org
To unsubscribe send an email to python-devel-le...@lists.fedoraproject.org

Re: Finalizing Fedora's Switch to Python 3

On 29 July 2017 at 00:25, John Dennis  wrote:
> I made this comment previously but because I think it's important I'm going
> to repeat it.
>
> Fedora's Python version migration needs to be coordinated with RHEL.
>
> Yes I know Fedora is independent of both Red Hat and RHEL but the real world
> reality is spec files are shared between both. At the moment you cannot
> easily share a spec file between the two, this leads to maintaining two
> independent spec files for something that ought to be nearly identical and
> increases the burden on package maintainers and increases the opportunity
> for errors.

Aye, I agree we should be actively seeking to make single-spec
feasible across Fedora/RHEL/CentOS, at least in combination with EPEL
(without the EPEL dependency, it's hard to consistently make new
Fedora level macro definitions available to older EL releases).

Cheers,
Nick.

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Schedule for Friday's FESCo Meeting (2017-07-28)

2017-07-28 Thread Jared K. Smith

On Fri, Jul 28, 2017 at 10:21 AM, Jared K. Smith 
wrote:

> Following is the list of topics that will be discussed in the
> FESCo meeting Friday at 16:00UTC in #fedora-meeting on
> irc.freenode.net.
>
>
There was one additional late-breaking ticket that will also be discussed:

#topic #1751 - Request to accept a Self Contained Change after deadline
.fesco 1751
#link https://pagure.io/fesco/issue/1751


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

Re: Finalizing Fedora's Switch to Python 3

2017-07-28 Thread John Dennis

I made this comment previously but because I think it's important I'm 
going to repeat it.


Fedora's Python version migration needs to be coordinated with RHEL.

Yes I know Fedora is independent of both Red Hat and RHEL but the real 
world reality is spec files are shared between both. At the moment you 
cannot easily share a spec file between the two, this leads to 
maintaining two independent spec files for something that ought to be 
nearly identical and increases the burden on package maintainers and 
increases the opportunity for errors.


The transition is already going to be painful, let's not make it more 
painful than it needs to be.


At a minimum the set of RPM macros to manage the difference between 
Python versions needs to be identically supported in both Fedora and 
RHEL. I'd like to see this as an explicit goal of the transition strategy.


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

Re: Finalizing Fedora's Switch to Python 3

2017-07-28 Thread John Dennis

I made this comment previously but because I think it's important I'm 
going to repeat it.


Fedora's Python version migration needs to be coordinated with RHEL.

Yes I know Fedora is independent of both Red Hat and RHEL but the real 
world reality is spec files are shared between both. At the moment you 
cannot easily share a spec file between the two, this leads to 
maintaining two independent spec files for something that ought to be 
nearly identical and increases the burden on package maintainers and 
increases the opportunity for errors.


The transition is already going to be painful, let's not make it more 
painful than it needs to be.


At a minimum the set of RPM macros to manage the difference between 
Python versions needs to be identically supported in both Fedora and 
RHEL. I'd like to see this as an explicit goal of the transition strategy.


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

Schedule for Friday's FESCo Meeting (2017-07-28)

2017-07-28 Thread Jared K. Smith

Following is the list of topics that will be discussed in the
FESCo meeting Friday at 16:00UTC in #fedora-meeting on
irc.freenode.net.

To convert UTC to your local time, take a look at
  http://fedoraproject.org/wiki/UTCHowto

or run:
  date -d '2017-07-28 16:00 UTC'


Links to all issues below can be found at:
https://pagure.io/fesco/report/meeting_agenda

= Followups =
#topic #1736 - Don't automatically close security bugs on Fedora EOL
.fesco 1736
https://pagure.io/fesco/issue/1736

#topic #1737 - Proposal: i686 SIG needs to be functional by F27 release date
.fesco 1737
https://pagure.io/fesco/issue/1737

#topic #1744 - F27 System Wide Change: NSS signtool deprecation
.fesco 1744
https://pagure.io/fesco/issue/1744

#topic #1745 - F27 System Wide Change: Switch OpenLDAP from NSS to OpenSSL
.fesco 1745
https://pagure.io/fesco/issue/1745

#topic #1747 - F27 System Wide Change: RPM 4.14
.fesco 1747
https://pagure.io/fesco/issue/1747

#topic #1749 - F27 Self Contained Change: VirtualBox Guest Integration
.fesco 1749
https://pagure.io/fesco/issue/1749

#topic #1750 - Decide if EOL is one month after release, four weeks,
or something else
.fesco 1750
https://pagure.io/fesco/issue/1750

= New business =

#topic #1690 - F27 Self Contained Changes
.fesco 1690
https://pagure.io/fesco/issue/1690

#topic Unified database for DNF
#link https://fedoraproject.org/wiki/Changes/Unified_database_for_DNF

#topic Authselect: new toold to replace authconfig
#link https://fedoraproject.org/wiki/Changes/Authselect

#topic New default cipher in OpenVPN
#link https://fedoraproject.org/wiki/Changes/New_default_cipher_in_OpenVPN

#topic Chinese Serif Fonts
#link https://fedoraproject.org/wiki/Changes/ChineseSerifFonts

#topic libpinyin 2.1
#link https://fedoraproject.org/wiki/Changes/libpinyin2.1

#topic Next week's chair

= Open Floor =

For more complete details, please visit each individual
issue.  The report of the agenda items can be found at
https://pagure.io/fesco/report/meeting_agenda

If you would like to add something to this agenda, you can
reply to this e-mail, file a new issue at
https://pagure.io/fesco, 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: ImageMagick Unresponsive Maintainer process - hubbitus (Pavel Alexeev)

2017-07-28 Thread Michael Cronenworth


On 07/27/2017 09:29 PM, Kevin Fenzi wrote:

ok. I have pushed 6.9.9-3 to rawhide.

Hopefully I got all the CVE's right in the changelog.
If someone wants to check over and make sure I didn't miss any that were
fixed in the 6.x branch that would be great.

I'd like to let it run a few days in rawhide before updating stable
branches, just in case I missed something.;)


First off, thanks, Kevin.

The update will require rebuilds. It introduces a SONAME change.

libMagickCore-6.Q16.so.2 -> libMagickCore-6.Q16.so.5
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Finalizing Fedora's Switch to Python 3

On Fri, Jul 28, 2017, at 07:47 AM, Peter Robinson wrote:
> On Fri, Jul 28, 2017 at 11:48 AM, Colin Walters  wrote:
> > On Thu, Jul 27, 2017, at 12:07 PM, Miro Hrončok wrote:
> >
> >>   * Switch /usr/bin/python to Python 3 in cooperation with Python upstream.
> >
> > That again?  That really seems like a nonstarter; previous
> > discussion specifically around Atomic Host + Ansible:
> > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/T4PGIEUYXWXSDRVWYQ2BJXCECL45XWVW/
> 
> Ansible now supports clients that are py3 only and there's active work
> [1] to enable py3 for the controller as well.

Yes.  But basically, I don't think we can rely on everyone porting their Ansible
code to Python3 anytime soon.  Among other reasons, many, many organizations
will need their Ansible (and in general, "config mgmt/scripting") to work across
RHEL7 and Fedora hosts.  For Fedora Atomic Host (which may be different from
Workstation!) I don't see dropping /usr/bin/python as python2 until RHEL7 is
near EOL.  Maybe we don't do security updates for it etc., but still.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Finalizing Fedora's Switch to Python 3

On 28 July 2017 at 22:29, Brian Exelbierd  wrote:
> On Fri, Jul 28, 2017, at 12:48 PM, Colin Walters wrote:
>> Plus just breaking everyone's random old scripts.  Now, I
>> don't know if this has been discussed upstream
>
> This is a statement born of ignorance, but ...
>
> Would it be possible to switch the default from python2 to python3 and
> provide an RPM that would switch it back?  This way people who needed to
> stay on python2 for some time period to clean up legacy components
> before teh 2020 EOL could.

Aye, while it's still a bit "and then some magic happens" at this
point, I actually think it may be possible to do something like this
through a combination of:

1. All Fedora packages switching to explicitly depending on either the
Python 2 stack or the Python 3 stack
2. Using the modularity tooling to make at least the target of
/usr/bin/python and potentially even the "python-*" dependency
resolution switchable

It's part 2 that counts as hand-wavey right now, since Boltron was
only just released, and we haven't even defined what we think the
Python 2 & Python 3 modules for the F27 Modular Server should look
like yet, let alone a "default-python" module that controls what
"/usr/bin/python" refers to. However, it seems to me that an approach
like that *should* work, so it's an idea I'm going to pursue until we
either having a working "Change it back!" switch, or else I've been
persuaded that it isn't feasible after all :)

Cheers,
Nick.

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Finalizing Fedora's Switch to Python 3

2017-07-28 Thread Kalev Lember

On 07/28/2017 11:01 AM, Zbigniew Jędrzejewski-Szmek wrote:
> So instead of taking this slowly, I'd rather go through FESCo
> and public announcement on fedora-devel, and then just apply the change
> to as many packages as possible at once.
I concur. I think this is one of the cases where we should use
provenpackagers / scripting and get all packages updated as quickly as
possible.

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

[Bug 1465702] perl-Net-HL7-0.82 is available

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

Bill Pemberton  changed:

   What|Removed |Added

 Status|NEW |CLOSED
 Resolution|--- |RAWHIDE
Last Closed||2017-07-28 09:30:14



-- 
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: Recompiling/relinking dependent applications/libraries on DSO change

On 07/28/2017 03:20 PM, Jakub Jelinek wrote:
> I think it is seriously flawed optimization that should be at least turned
> off by default.  If people are willing to do this mess on ppc64le for some
> libraries, they should request it explicitly, but we certainly shouldn't
> make the implementation details part of exported ABI for all shared
> libraries.  Then the ABI depends even on compiler flags used to compile the
> routines etc., you recompile with -O0 and suddenly you've changed ABI.
> Furthermore, how does it work with symbol interposition?  Say if malloc
> happened to not clobber/use r2 and does not use r12, you suddenly couldn't
> use ElectricFence or valgrind or AddressSanitizer where the implementation
> would need to do that.

All the things you list are potentially broken.  As I said, it's not
worth discussing this.  It's not supportable.

I don't even want to ship this as an optional feature.

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

Re: Recompiling/relinking dependent applications/libraries on DSO change

2017-07-28 Thread Jakub Jelinek

On Fri, Jul 28, 2017 at 03:20:49PM +0200, Jakub Jelinek wrote:
> > Conceptually, this optimization inlines aspects of the called function
> > into the caller, across DSO boundaries.  In particular, as implemented
> > now on ppc64le, the net effect is that the ABI changes if you add a
> > global variable access to a function which previously did not have one.
> > 
> > I posted a more technical summary here:
> > 
> >   

Note link to the implementation and rationale is
https://sourceware.org/ml/binutils/2017-06/msg7.html

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

Re: Recompiling/relinking dependent applications/libraries on DSO change

2017-07-28 Thread Jakub Jelinek

On Fri, Jul 28, 2017 at 03:06:29PM +0200, Florian Weimer wrote:
> On 07/28/2017 02:22 PM, Mark Wielaard wrote:
> > On Fri, 2017-07-28 at 13:39 +0200, Florian Weimer wrote:
> >> binutils 2.29 introduced an optimization which requires that in the
> >> general case, applications and libraries linking against a DSO will have
> >> to be rebuilt when the DSO change the implementation of functions (i.e.,
> >> changes to a function body can change ABI).  This is how many native
> >> programming languages (such as Ada, Haskell/GHC, Go, Rust) handle DSOs,
> >> but it's a material change for C and C++.
> >>
> >> The question is: Do we want to move into that direction, or do we need
> >> to ask binutils upstream to back out this change?
> > 
> > Could you be a bit more specific? Normally that is why you use symbol
> > versioning isn't it? Does binutils now warn when it detects such an ABI
> > change? How does it know?
> 
> Conceptually, this optimization inlines aspects of the called function
> into the caller, across DSO boundaries.  In particular, as implemented
> now on ppc64le, the net effect is that the ABI changes if you add a
> global variable access to a function which previously did not have one.
> 
> I posted a more technical summary here:
> 
>   
> 
> It is theoretical possible to make this work with symbol versions, but
> we don't have any tools for that right now.
> 
> Writing this message I realized that it's not worth to have a serious
> discussion about this binutils change.  It's just wrong and breaks ELF
> dynamic linking.  Sorry about the noise.

I think it is seriously flawed optimization that should be at least turned
off by default.  If people are willing to do this mess on ppc64le for some
libraries, they should request it explicitly, but we certainly shouldn't
make the implementation details part of exported ABI for all shared
libraries.  Then the ABI depends even on compiler flags used to compile the
routines etc., you recompile with -O0 and suddenly you've changed ABI.
Furthermore, how does it work with symbol interposition?  Say if malloc
happened to not clobber/use r2 and does not use r12, you suddenly couldn't
use ElectricFence or valgrind or AddressSanitizer where the implementation
would need to do that.

Can the decision if this braindamange should be used or not be done on a
per-shared library basis, then it might be useful for shared libraries
solely used by binaries in the same package where nothing else uses them.
But otherwise, just say no to this.  Ugh.

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

Re: Recompiling/relinking dependent applications/libraries on DSO change

On 07/28/2017 02:22 PM, Mark Wielaard wrote:
> Hi Florian,
> 
> On Fri, 2017-07-28 at 13:39 +0200, Florian Weimer wrote:
>> binutils 2.29 introduced an optimization which requires that in the
>> general case, applications and libraries linking against a DSO will have
>> to be rebuilt when the DSO change the implementation of functions (i.e.,
>> changes to a function body can change ABI).  This is how many native
>> programming languages (such as Ada, Haskell/GHC, Go, Rust) handle DSOs,
>> but it's a material change for C and C++.
>>
>> The question is: Do we want to move into that direction, or do we need
>> to ask binutils upstream to back out this change?
> 
> Could you be a bit more specific? Normally that is why you use symbol
> versioning isn't it? Does binutils now warn when it detects such an ABI
> change? How does it know?

Conceptually, this optimization inlines aspects of the called function
into the caller, across DSO boundaries.  In particular, as implemented
now on ppc64le, the net effect is that the ABI changes if you add a
global variable access to a function which previously did not have one.

I posted a more technical summary here:

It is theoretical possible to make this work with symbol versions, but
we don't have any tools for that right now.

Writing this message I realized that it's not worth to have a serious
discussion about this binutils change.  It's just wrong and breaks ELF
dynamic linking.  Sorry about the noise.

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

[Bug 1476262] perl-XML-XPath-1.41 is available

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



--- Comment #2 from Fedora Update System  ---
perl-XML-XPath-1.41-1.fc26 has been submitted as an update to Fedora 26.
https://bodhi.fedoraproject.org/updates/FEDORA-2017-89a5c8afd3

-- 
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 1476262] perl-XML-XPath-1.41 is available

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

Petr Pisar  changed:

   What|Removed |Added

 Status|ASSIGNED|MODIFIED
   Fixed In Version||perl-XML-XPath-1.41-1.fc27



--- Comment #1 from Petr Pisar  ---
A bug-fix release suitable for Fedora ≥ 26.

-- 
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: Recompiling/relinking dependent applications/libraries on DSO change

2017-07-28 Thread Daniel P. Berrange

On Fri, Jul 28, 2017 at 01:39:50PM +0200, Florian Weimer wrote:
> binutils 2.29 introduced an optimization which requires that in the
> general case, applications and libraries linking against a DSO will have
> to be rebuilt when the DSO change the implementation of functions (i.e.,
> changes to a function body can change ABI).  This is how many native
> programming languages (such as Ada, Haskell/GHC, Go, Rust) handle DSOs,
> but it's a material change for C and C++.

Can you elaborate on what sort of change in the function body would
affect the ABI and thus require relinking ?  Having to relink every
time the internal impl of an ABI changes would seem to throw away one
of the main benefits of using shared libs, over static libs and be
pretty unpleasant as a result.

Libvirt, for example, has never changed any existing public API contract
or definition in 10 years of releases, but we do often change the internal
impl of these APIs. Apps have never had to relink against libvirt.so upon
new release, so I would not want that to see that change.

Regards,
Daniel
-- 
|: https://berrange.com  -o-https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o-https://fstop138.berrange.com :|
|: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

[Bug 1476262] perl-XML-XPath-1.41 is available

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

Petr Pisar  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
 CC|jples...@redhat.com |ppi...@redhat.com
   Assignee|jples...@redhat.com |ppi...@redhat.com



-- 
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 1476262] New: perl-XML-XPath-1.41 is available

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

Bug ID: 1476262
   Summary: perl-XML-XPath-1.41 is available
   Product: Fedora
   Version: rawhide
 Component: perl-XML-XPath
  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



Latest upstream release: 1.41
Current version/release in rawhide: 1.40-3.fc27
URL: http://search.cpan.org/dist/XML-XPath/

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

-- 
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: Finalizing Fedora's Switch to Python 3

On 28 July 2017 at 20:48, Colin Walters  wrote:
> On Thu, Jul 27, 2017, at 12:07 PM, Miro Hrončok wrote:
>
>>   * Switch /usr/bin/python to Python 3 in cooperation with Python upstream.
>
> That again?  That really seems like a nonstarter; previous
> discussion specifically around Atomic Host + Ansible:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/T4PGIEUYXWXSDRVWYQ2BJXCECL45XWVW/
>
> Plus just breaking everyone's random old scripts.

Option 1: *guarantee* breaking old scripts by removing
"/usr/bin/python" entirely (current status quo on Py3-only Fedora
systems)
Option 2: keep such scripts working *if* somewhere in the *decade*
since Python 3 was released, folks accepted that Python 2 really was
going to go away, and modernised their code to run in the common
subset of Python 2.7 and 3.6+ (which covers a *lot* of Python 2.7's
capabilities, especially if you do "from __future__ import
print_function" rather than relying on the old print statement syntax)

Corollary to option 2: for as long Fedora ships a Python 2.7 stack, we
should provide a supported mechanism (building on either modularity,
xdg-alternatives, or both) that makes it straightforward for system
administrators to switch "/usr/bin/python" back to referring to Python
2.7

> Now, I
> don't know if this has been discussed upstream, but one
> thing to do possibly would be to have an interactive shell
> alias for `python` = `ipython3` or something like that, and
> switch `ipython` to `ipython3`.

User level aliasing isn't the issue - there are already several
solutions for that, and users are free to pick whichever one works
best for them.

It's only /usr/bin/python itself that still presents an unsolved
problem, since the status quo (not providing it at all) is even more
user hostile than pointing it at a modern version of Python 3 that
includes the various changes aimed at increasing the size of the
common subset of Python 2 & 3 (e.g. explicit unicode literals in 3.3,
binary codecs in 3.4, binary mod-formatting in 3.5, Fedora's backport
of implicit locale coercion to 3.6).

The most common Py2-induced syntax errors (print without parentheses,
print redirects using the old syntax) have also gained or are gaining
much improved error messages in 3.6.x (such that the error also
suggests directly how to fix it), and there are various other things
we can consider to help smooth the transition (like providing the
"six" and "future" compatibility modules by default in both our Python
2 and Python 3 stacks in order to make portable hybrid code easier to
write).

Cheers,
Nick.

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Finalizing Fedora's Switch to Python 3

2017-07-28 Thread Brian Exelbierd

On Fri, Jul 28, 2017, at 12:48 PM, Colin Walters wrote:
> On Thu, Jul 27, 2017, at 12:07 PM, Miro Hrončok wrote:
> 
> >   * Switch /usr/bin/python to Python 3 in cooperation with Python upstream.
> 
> That again?  That really seems like a nonstarter; previous
> discussion specifically around Atomic Host + Ansible:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/T4PGIEUYXWXSDRVWYQ2BJXCECL45XWVW/
> 
> Plus just breaking everyone's random old scripts.  Now, I
> don't know if this has been discussed upstream

This is a statement born of ignorance, but ...

Would it be possible to switch the default from python2 to python3 and
provide an RPM that would switch it back?  This way people who needed to
stay on python2 for some time period to clean up legacy components
before teh 2020 EOL could.

I realize that package renaming and things like that will move forward
regardless and should.

regards,

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

Re: Recompiling/relinking dependent applications/libraries on DSO change

2017-07-28 Thread Mark Wielaard

Hi Florian,

On Fri, 2017-07-28 at 13:39 +0200, Florian Weimer wrote:
> binutils 2.29 introduced an optimization which requires that in the
> general case, applications and libraries linking against a DSO will have
> to be rebuilt when the DSO change the implementation of functions (i.e.,
> changes to a function body can change ABI).  This is how many native
> programming languages (such as Ada, Haskell/GHC, Go, Rust) handle DSOs,
> but it's a material change for C and C++.
> 
> The question is: Do we want to move into that direction, or do we need
> to ask binutils upstream to back out this change?

Could you be a bit more specific? Normally that is why you use symbol
versioning isn't it? Does binutils now warn when it detects such an ABI
change? How does it know?

Thanks,

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

[Bug 1378895] 8-bpp TIFF images are broken in the resulting PDF document

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



--- Comment #5 from Petr Pisar  ---
Created attachment 1305926
  --> https://bugzilla.redhat.com/attachment.cgi?id=1305926=edit
Fix as a dist-git patch

This adds the proposed upstream fix. It requires the new dependency.

-- 
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 1476247] New: perl-DBM-Deep-2.0014 is available

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

Bug ID: 1476247
   Summary: perl-DBM-Deep-2.0014 is available
   Product: Fedora
   Version: rawhide
 Component: perl-DBM-Deep
  Keywords: FutureFeature, Triaged
  Assignee: andr...@bawue.net
  Reporter: upstream-release-monitor...@fedoraproject.org
QA Contact: extras...@fedoraproject.org
CC: andr...@bawue.net, p...@city-fan.org,
perl-devel@lists.fedoraproject.org



Latest upstream release: 2.0014
Current version/release in rawhide: 2.0013-5.fc27
URL: http://search.cpan.org/dist/DBM-Deep/

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

-- 
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 1476247] perl-DBM-Deep-2.0014 is available

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



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

-- 
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-MooX-Types-MooseLike (master). "Do not depend on Moose modules (..more)"

From 83f54071e2602df8c12b264e0ca0a176caf7fac0 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Petr=20P=C3=ADsa=C5=99?= 
Date: Thu, 27 Jul 2017 16:09:40 +0200
Subject: Do not depend on Moose modules

Depending on Moose::Util::TypeConstraints and similar was a mistake
because it pulls in Moose. This package should work with any
Moose-like implementation.
---
 perl-MooX-Types-MooseLike.spec | 27 ++-
 1 file changed, 14 insertions(+), 13 deletions(-)

diff --git a/perl-MooX-Types-MooseLike.spec b/perl-MooX-Types-MooseLike.spec
index b36fc5f..4ab863d 100644
--- a/perl-MooX-Types-MooseLike.spec
+++ b/perl-MooX-Types-MooseLike.spec
@@ -1,6 +1,6 @@
 Name:   perl-MooX-Types-MooseLike
 Version:0.29
-Release:6%{?dist}
+Release:7%{?dist}
 Summary:Some Moosish types and a type builder
 License:GPL+ or Artistic
 URL:http://search.cpan.org/dist/MooX-Types-MooseLike/
@@ -19,12 +19,16 @@ BuildRequires:  perl(Carp)
 BuildRequires:  perl(Exporter) >= 5.57
 BuildRequires:  perl(List::Util)
 BuildRequires:  perl(Module::Runtime) >= 0.014
-# Moose::Meta::TypeConstraint::Class not used at tests
-BuildRequires:  perl(Moose::Meta::TypeConstraint::DuckType)
-BuildRequires:  perl(Moose::Meta::TypeConstraint::Enum)
-# Moose::Meta::TypeConstraint::Role not used at tests
-BuildRequires:  perl(Moose::Meta::TypeConstraint::Union)
-BuildRequires:  perl(Moose::Util::TypeConstraints)
+# If Moose-like implementation is used, Moose::* modules required in the
+# code are not real Moose packages. Those are reimplementations mimicking
+# them. Depending on them would defeat the purpose of an altertnative
+# Moose-like implementation that replaces Moose. Those are:
+# Moose::Meta::TypeConstraint::Class
+# Moose::Meta::TypeConstraint::DuckType
+# Moose::Meta::TypeConstraint::Enum
+# Moose::Meta::TypeConstraint::Role
+# Moose::Meta::TypeConstraint::Union
+# Moose::Util::TypeConstraints
 BuildRequires:  perl(Scalar::Util)
 # Tests:
 BuildRequires:  perl(IO::Handle)
@@ -36,12 +40,6 @@ BuildRequires:  perl(Test::Fatal) >= 0.003
 BuildRequires:  perl(Test::More) >= 0.96
 Requires:   perl(:MODULE_COMPAT_%(eval "`perl -V:version`"; echo $version))
 Requires:   perl(Module::Runtime) >= 0.014
-Requires:   perl(Moose::Meta::TypeConstraint::Class)
-Requires:   perl(Moose::Meta::TypeConstraint::DuckType)
-Requires:   perl(Moose::Meta::TypeConstraint::Enum)
-Requires:   perl(Moose::Meta::TypeConstraint::Role)
-Requires:   perl(Moose::Meta::TypeConstraint::Union)
-Requires:   perl(Moose::Util::TypeConstraints)
 
 # Remove under-specified dependencies
 %global __requires_exclude 
%{?__requires_exclude:%{__requires_exclude}|}^perl\\(Module::Runtime\\)$
@@ -72,6 +70,9 @@ make test
 %{_mandir}/man3/*
 
 %changelog
+* Thu Jul 27 2017 Petr Pisar  - 0.29-7
+- Do not depend on Moose modules
+
 * Thu Jul 27 2017 Fedora Release Engineering  - 
0.29-6
 - Rebuilt for https://fedoraproject.org/wiki/Fedora_27_Mass_Rebuild
 
-- 
cgit v1.1



https://src.fedoraproject.org/cgit/perl-MooX-Types-MooseLike.git/commit/?h=master=83f54071e2602df8c12b264e0ca0a176caf7fac0
___
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-Moo (master). "Sub::Defer and Sub::Quote are always required"

From 77297317d3d97f1e8c1c507fd79611a95e99c549 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Petr=20P=C3=ADsa=C5=99?= 
Date: Thu, 27 Jul 2017 15:32:57 +0200
Subject: Sub::Defer and Sub::Quote are always required

---
 perl-Moo.spec | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/perl-Moo.spec b/perl-Moo.spec
index f8a17f5..08472dd 100644
--- a/perl-Moo.spec
+++ b/perl-Moo.spec
@@ -31,12 +31,12 @@ BuildRequires:  perl(overload)
 BuildRequires:  perl(Role::Tiny) >= 1.003003
 BuildRequires:  perl(Scalar::Util)
 BuildRequires:  perl(strictures) >= 1.004003
+BuildRequires:  perl(Sub::Defer)
+BuildRequires:  perl(Sub::Quote)
 # Text::Balanced not used at test-time
 # Optional run-time:
 BuildRequires:  perl(Class::XSAccessor) >= 1.18
-BuildRequires:  perl(Sub::Defer)
 BuildRequires:  perl(Sub::Name)
-BuildRequires:  perl(Sub::Quote)
 # lib/Moo/HandleMoose.pm requires Moose modules. Moo::HandleMoose is used only
 # if Moose has been loaded. So this is circular optional dependency definitly
 # not suitable for Moo because Moo is reimplementation of Moose:
-- 
cgit v1.1



https://src.fedoraproject.org/cgit/perl-Moo.git/commit/?h=master=77297317d3d97f1e8c1c507fd79611a95e99c549
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

[Bug 1378895] 8-bpp TIFF images are broken in the resulting PDF document

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

Petr Pisar  changed:

   What|Removed |Added

 Depends On||1476237



--- Comment #4 from Petr Pisar  ---
Upstream proposes a new TIFF support based on Graphics::TIFF that has not yet
been packaged.


Referenced Bugs:

https://bugzilla.redhat.com/show_bug.cgi?id=1476237
[Bug 1476237] Review Request: perl-Graphics-TIFF - Perl extension for the
LibTIFF library
-- 
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: Finalizing Fedora's Switch to Python 3

2017-07-28 Thread Peter Robinson

On Fri, Jul 28, 2017 at 11:48 AM, Colin Walters  wrote:
> On Thu, Jul 27, 2017, at 12:07 PM, Miro Hrončok wrote:
>
>>   * Switch /usr/bin/python to Python 3 in cooperation with Python upstream.
>
> That again?  That really seems like a nonstarter; previous
> discussion specifically around Atomic Host + Ansible:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/T4PGIEUYXWXSDRVWYQ2BJXCECL45XWVW/

Ansible now supports clients that are py3 only and there's active work
[1] to enable py3 for the controller as well.

[1] http://docs.ansible.com/ansible/latest/python_3_support.html
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Recompiling/relinking dependent applications/libraries on DSO change

binutils 2.29 introduced an optimization which requires that in the
general case, applications and libraries linking against a DSO will have
to be rebuilt when the DSO change the implementation of functions (i.e.,
changes to a function body can change ABI).  This is how many native
programming languages (such as Ada, Haskell/GHC, Go, Rust) handle DSOs,
but it's a material change for C and C++.

The question is: Do we want to move into that direction, or do we need
to ask binutils upstream to back out this change?

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

[Bug 1468829] perl-XML-Tidy-1.20 is available

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



--- Comment #7 from Upstream Release Monitoring 
 ---
releng's perl-XML-Tidy-1.20-2.fc27 completed
http://koji.fedoraproject.org/koji/buildinfo?buildID=937727

-- 
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: Mass rebuild failures only on ppc64le: glibc problem?

2017-07-28 Thread Paul Howarth


On 2017-07-27 10:15, Antonio Trande wrote:

On 07/27/2017 01:21 AM, Jason L Tibbitts III wrote:

I noticed one of my packages failed to build because the test suite
failed, but only on ppc64le.

builddir/build/BUILD/cyrus-imapd-3.0.2/cunit/.libs/lt-unit: error 
while

loading shared libraries:
/builddir/build/BUILD/cyrus-imapd-3.0.2/imap/.libs/libcyrus_imap.so.0:
expected localentry:0 `sasl_client_new'

I have no idea what that means, and a search for "expected 
localentry:0"

turned up only the patch where that message was added to glibc.

I did some other random checks and found a few other packages with
ppc64le-only build failures: freeipa, gammu, gap-pkg-float, gambas3,
getdp (and I stopped looking after that).  These all failed in their
test suites with an error from the linker containing "expected
localentry:0".

Does anyone have any idea what's going wrong?

 - J<
___


Same problem with MPI libraries of MUMPS just on PPC64le:

+ export
LD_LIBRARY_PATH=/builddir/build/BUILD/MUMPS_5.1.1/MUMPS-5.1.1-openmpi/examples:../lib:/usr/lib64/openmpi/lib
+
LD_LIBRARY_PATH=/builddir/build/BUILD/MUMPS_5.1.1/MUMPS-5.1.1-openmpi/examples:../lib:/usr/lib64/openmpi/lib
+ ./dsimpletest
./dsimpletest: error while loading shared libraries:
../lib/libmumps_common-5.1.1.so: expected localentry:0 
`pthread_cond_init'


Same problem with appstream-util:

Executing(%check): /bin/sh -e /var/tmp/rpm-tmp.3sh3cm
+ umask 022
+ cd /builddir/build/BUILD
+ cd gtkwave-3.3.82
+ appstream-util validate-relax --nonet 
/builddir/build/BUILDROOT/gtkwave-3.3.82-2.fc27.ppc64le/usr/share/appdata/gtkwave.appdata.xml
appstream-util: error while loading shared libraries: /lib64/librt.so.1: 
expected localentry:0 `pthread_attr_setdetachstate'

error: Bad exit status from /var/tmp/rpm-tmp.3sh3cm (%check)

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

[Bug 1468928] perl-Tie-Cycle-1.225 is available

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



--- Comment #4 from Upstream Release Monitoring 
 ---
releng's perl-Tie-Cycle-1.225-2.fc27 completed
http://koji.fedoraproject.org/koji/buildinfo?buildID=937478

-- 
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: Finalizing Fedora's Switch to Python 3

On Thu, Jul 27, 2017, at 12:07 PM, Miro Hrončok wrote:

>   * Switch /usr/bin/python to Python 3 in cooperation with Python upstream.

That again?  That really seems like a nonstarter; previous
discussion specifically around Atomic Host + Ansible:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/T4PGIEUYXWXSDRVWYQ2BJXCECL45XWVW/

Plus just breaking everyone's random old scripts.  Now, I
don't know if this has been discussed upstream, but one
thing to do possibly would be to have an interactive shell
alias for `python` = `ipython3` or something like that, and
switch `ipython` to `ipython3`.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Coming soon: Pagure service for dist-git

2017-07-28 Thread Pierre-Yves Chibon

On Fri, Jul 28, 2017 at 11:01:35AM +0200, Vít Ondruch wrote:
> 
> 
> Dne 28.7.2017 v 10:11 Pierre-Yves Chibon napsal(a):
> >
> > As far as I can see this is looking all good but you know the more eyes the
> > better :)
> 
> https://src.stg.fedoraproject.org/pagure/group/ruby-packagers-sig
> 
> releng is ruby-packagers-sig group member? How so?

releng is the bot account used by releng for things like mass-rebuild.
In this case I needed an account to create the group and since the group creator
cannot be removed from the group, I used releng. So it is present in all groups
and is the one creating them on the pagure side.

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

Re: Finalizing Fedora's Switch to Python 3

On Fri, Jul 28, 2017 at 09:49:42AM +0200, Miro Hrončok wrote:
> On 27.7.2017 19:15, Zbigniew Jędrzejewski-Szmek wrote:
> >Do you think it'd be possible to script the python-foo to python2-foo
> >renaming?
> 
> May be possible but given the variety in the spec files, we didn't
> think it would be easy. IMHO taking a bunch of provenpackagers and
> updating the packages manually without asking the owners will be
> less time consuming than creating an automated tool.
> 
> However, in both scenarios (people or tools), I consider that
> approach aggressive and would rather only do it when the deadlines
> are close.
> We'd rather not change other people packages and make them mad about
> what have we done. The transition to Python 3 is unfortunately
> considered a failure in eyes of some Fedora contributors.
[My original comment here has been deleted to protect the innocent ;) ]

> I consider communicating our efforts with the package owners and
> explaining them what and how to do as more friendly approach.
> However, definitively more time expensive.
>
> 
> On the other hand, maybe we can start updating the packages co-owned
> by python-sig, as I would say those are considered to be maintained
> by the group rather than a person. In case you'd like to try to
> write an automated tool for that, please go ahead (but please let us
> know).

I don't know if delaying this will help. Actually stretching out the
transition might make things more painful, because it'll increase the
window where you don't know if any given python package has python2-
or python- prefix, so you need to check all deps. I'm sure getting rid
of this ambiguity would be welcome.

So instead of taking this slowly, I'd rather go through FESCo
and public announcement on fedora-devel, and then just apply the change
to as many packages as possible at once. Technically, I think it would
be reasonable to try to script this, w/o pushing to dist git, then put
up the diffs for review somewhere, and then finally push at once, at get
a few pps to do the rebuilds (some stuff is bound to fail for related
or unrelated reasons, so some debugging is expected).

In the other mail Nick Coghlan listed various steps: it's far from
trivial, but OTOH doing 800+ packages by hand ain't gonna be fun either.
I'll try to look into this over the weekend, it sounds like a fun
challenge.

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

Re: Finalizing Fedora's Switch to Python 3

On Fri, Jul 28, 2017 at 09:49:42AM +0200, Miro Hrončok wrote:
> On 27.7.2017 19:15, Zbigniew Jędrzejewski-Szmek wrote:
> >Do you think it'd be possible to script the python-foo to python2-foo
> >renaming?
> 
> May be possible but given the variety in the spec files, we didn't
> think it would be easy. IMHO taking a bunch of provenpackagers and
> updating the packages manually without asking the owners will be
> less time consuming than creating an automated tool.
> 
> However, in both scenarios (people or tools), I consider that
> approach aggressive and would rather only do it when the deadlines
> are close.
> We'd rather not change other people packages and make them mad about
> what have we done. The transition to Python 3 is unfortunately
> considered a failure in eyes of some Fedora contributors.
[My original comment here has been deleted to protect the innocent ;) ]

> I consider communicating our efforts with the package owners and
> explaining them what and how to do as more friendly approach.
> However, definitively more time expensive.
>
> 
> On the other hand, maybe we can start updating the packages co-owned
> by python-sig, as I would say those are considered to be maintained
> by the group rather than a person. In case you'd like to try to
> write an automated tool for that, please go ahead (but please let us
> know).

I don't know if delaying this will help. Actually stretching out the
transition might make things more painful, because it'll increase the
window where you don't know if any given python package has python2-
or python- prefix, so you need to check all deps. I'm sure getting rid
of this ambiguity would be welcome.

So instead of taking this slowly, I'd rather go through FESCo
and public announcement on fedora-devel, and then just apply the change
to as many packages as possible at once. Technically, I think it would
be reasonable to try to script this, w/o pushing to dist git, then put
up the diffs for review somewhere, and then finally push at once, at get
a few pps to do the rebuilds (some stuff is bound to fail for related
or unrelated reasons, so some debugging is expected).

In the other mail Nick Coghlan listed various steps: it's far from
trivial, but OTOH doing 800+ packages by hand ain't gonna be fun either.
I'll try to look into this over the weekend, it sounds like a fun
challenge.

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

[Bug 1465702] perl-Net-HL7-0.82 is available

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



--- Comment #4 from Upstream Release Monitoring 
 ---
releng's perl-Net-HL7-0.82-2.fc27 completed
http://koji.fedoraproject.org/koji/buildinfo?buildID=936466

-- 
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: Coming soon: Pagure service for dist-git

2017-07-28 Thread Vít Ondruch



Dne 28.7.2017 v 10:11 Pierre-Yves Chibon napsal(a):
>
> As far as I can see this is looking all good but you know the more eyes the
> better :)

https://src.stg.fedoraproject.org/pagure/group/ruby-packagers-sig

releng is ruby-packagers-sig group member? How so?

https://admin.fedoraproject.org/accounts/group/view/ruby-packagers-sig


> Thanks for finding this out!

Thank you for polishing this out :)

Vít

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

ppisar pushed to perl (master). "Fix profile's RPM list definitions (..more)"

ppisar pushed to perl (master).  "Fix profile's RPM list definitions (..more)"

https://src.fedoraproject.org/cgit/perl.git/commit/?h=master=2168f141c31311f5663f089b07ae86ffa4b85419
___
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 (f26). "Fix profile's RPM list definitions (..more)"

ppisar pushed to perl (f26).  "Fix profile's RPM list definitions (..more)"

https://src.fedoraproject.org/cgit/perl.git/commit/?h=f26=b198b660e121423c0d9ae50cc4a23456689f2d9a
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

Re: F27 Self Contained Change: Samba AD

2017-07-28 Thread Dario Lesca

Il giorno gio, 27/07/2017 alle 15.16 +0200, Dario Lesca ha scritto:
> 
> But the folder is not accessible from bind user:
> # ll -ld /var/lib/samba/private/
> drwx--. 6 root root 4096 27 lug 13.46 /var/lib/samba/private/
> 
> then I have change it with:
> # chmod g+rx /var/lib/samba/private/
> # chgrp named /var/lib/samba/private/
> 
> 

I have fill this bug
https://bugzilla.redhat.com/show_bug.cgi?id=1476175

> # systemctl start named
> 
> I get this error:
> 
> lug 27 14:39:53 server-addc.dom.loc named[2418]: samba_dlz: Failed to
> connect to /var/lib/samba/private/dns/sam.ldb
> lug 27 14:39:53 server-addc.dom.loc named[2418]: dlz_dlopen of 'AD
> DNS Zone' failed
> lug 27 14:39:53 server-addc.dom.loc named[2418]: SDLZ driver failed
> to load.
> lug 27 14:39:53 server-addc.dom.loc named[2418]: DLZ driver failed to
> load.
> lug 27 14:39:53 server-addc.dom.loc named[2418]: loading
> configuration: failure
> lug 27 14:39:53 server-addc.dom.loc named[2418]: exiting (due to
> fatal error)
> lug 27 14:39:53 server-addc.dom.loc systemd[1]: named.service:
> Control process exited, code=exited status=1
> lug 27 14:39:53 server-addc.dom.loc systemd[1]: Failed to start
> Berkeley Internet Name Domain (DNS).
> lug 27 14:39:53 server-addc.dom.loc systemd[1]: named.service: Unit
> entered failed state.
> lug 27 14:39:53 server-addc.dom.loc systemd[1]: named.service: Failed
> with result 'exit-code'.
> 
> 

And this:
https://bugzilla.redhat.com/show_bug.cgi?id=1476187

-- 
Dario Lesca
(inviato dal mio Linux Fedora 26 Workstation)
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Coming soon: Pagure service for dist-git

2017-07-28 Thread Pierre-Yves Chibon

On Thu, Jul 27, 2017 at 10:50:13AM +0200, Pierre-Yves Chibon wrote:
> On Thu, Jul 27, 2017 at 10:36:29AM +0200, Vít Ondruch wrote:
> > Dne 27.7.2017 v 10:05 Pierre-Yves Chibon napsal(a):
> > >> 2) The "contributors" list does not appear to be correct. Looking at
> > >> "ruby", there is listed "tagoh" user, who is in pkgdb "Obsolete" on all
> > >> branches. Is it old data on staging? Not sure when he was obsoleted in
> > >> pkgdb 
> > > The timeline shows he was obsoleted in December 2016,
> > 
> > Ah, I knew the information must be visible somewhere. This leads me to
> > question is similar information accessible in pagure somewhere? ;)
> > 
> > But anyway, I was not sure about the age of the data in staging, since
> > for example the ruby repo says it was "created 19h ago" and the "recent
> > commit in master committed 8 months ago". This does not corresponds with
> > the official dist-git (actually neither the repo age nor the recent commit).
> 
> This make sense, the date created is the date of the creation of the project 
> on
> pagure so independent from the git repo history.
> 
> > Looking at f26 branch [1], the last commit is from 12 years ago? The
> > branch was created around 1st of March, so what is the content?
> 
> The content of the git repo is probably an old snapshot of prod. I honestly
> don't remember when we last sync ited, I'm less worried about this part as 
> pagure
> doesn't touch it, while about the sync from pkgdb is new.
> 
> 
> Pkgdb in stg is now in sync with prod, let's reload the data in pagure :)

Ok so in addition to the source of data being out-dated I ran into a bug in
pkgdb2 yesterday that was returning invalid data in a specific case. I managed
to go around this bug and re-sync everything to pagure in stg.

This is how it looks now:
https://src.stg.fedoraproject.org/pagure/rpms/ruby
https://src.stg.fedoraproject.org/pagure/rpms/rubygem-puma


As far as I can see this is looking all good but you know the more eyes the
better :)


Thanks for finding this out!

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

Re: Finalizing Fedora's Switch to Python 3