[HEADS UP] Retiring python2 and introducing python27 later this week
by Miro Hrončok
We are retiring python2 and introducing python27 later this week. Rawhide only.
As for now, nothing should break, except python2-debug will exist no more.
Packages (build)requiring python2 or python2-devel should continue to work for
now. If not, let us know.
If you plan to keep a Python 2 package in Fedora 32+, talk to me, I can help you
draft an exception request.
Will post a reply here once it is done.
The following packages build subpackages for python2-debug (and should stop
doing it in Fedora 32+):
- gcc-python-plugin (FTBFS)
- python-mysql (PR exists)
- python-psycopg2 (notified in an existing bugzilla)
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
4 years, 7 months
New release of Mock (fixes and subscription-manager support)
by Miroslav Suchý
Hi,
I released new version of Mock and mock-core-configs. For full release notes see:
https://github.com/rpm-software-management/mock/wiki/Release-Notes-1.4.18
I just submitted packages to Bodhi.
I would like to point two things here:
1) It should fixes all those issues you reported in past days (selinux, rprivate, groupadd).
2) Mock now supports subscription-manager, which allows you to build packages for RHEL with cost-free developer license.
No need to wait for CentOS 8.
Big thanks to Pavel Raiskup who done those two things.
--
Miroslav Suchy, RHCA
Red Hat, Associate Manager ABRT/Copr, #brno, #fedora-buildsys
4 years, 7 months
Fedora 32 Self-Contained Change proposal: Track Changes in Taiga
by Ben Cotton
https://fedoraproject.org/wiki/Changes/fedora-change-wrangler
= Track Changes in Taiga =
The Motivation for this proposal is to propose using the Taiga
instance at teams.fedoraproject.org for Change processing.
[[User:Bcotton/UsePagureForChanges|Using Pagure]] was previously
proposed for this. The new Change Processing workflow aims to simplify
the process to improve visibility and ease of management.
== Summary ==
The current process allows contributors to propose changes in upcoming
Fedora releases. However, the management of those feature proposals is
cumbersome and requires several manual steps. This introduces more
opportunity for error and reduces the time available to the Change
Wrangler for more valuable contributions to Fedora. In particular, the
current process includes artifacts and discussion in the Fedora Wiki,
on mailing lists, FESCo tickets, Bugzilla tickets, and Docs tickets.
The current process is cumbersome with several manual steps,this
introduces more opportunity for error and reduces the time available
for the Change Wrangler.
A Cli Tool Written in Python that interacts with Taiga,Pagure and
Bugzilla.Functionality includes
Promoting,announcing,submitting,accepting and updating the changes
across the three platforms and over mailing list.
The new process will consolidate much of the information in
Taiga.Proposed Changes will be submitted as an issue in Taiga. The
description of the Issue will include the content with few exceptions:
* System-Wide or Self-Contained change will be indicated by a binary
in the issue metadata
* Fedora release will be indicated by a milestone in the issue metadata
* Change status will be indicated by a list selection in the issue metadata
== Owner ==
* Name: [[User:Pac23| Manas Mangaonkar]]
* Email: manasmangaonkar(a)gmail.com || pac23(a)fedoraproject.org
* Name: [[User:Bcotton | Ben Cotton]]
* Email: bcotton(a)redhat.com
== Detailed Description ==
As Part of GSoC 2019 the fedora-change-wrangler tool will be developed
to smooth out the workflow,reduce Manual Work involved for both the
Contributors and the Change-Wrangler(FPgm). The tool makes it easy by
covering all the functionality required for the process of moving
forward proposals.
The tool will be developed using Python 3.6+ and will interact with
Taiga/Pagure/Bugzilla via their API and the Mailing List via SMTP.
The General Workflow would be :
1. Change Owner opens an issue and fills in the fields. When they are
ready to submit the Change proposal, they set the status to "Ready
for Wrangler".
2. The Change Wrangler (FPgM) reviews the proposal. If it is
incomplete, they set the status back to "New" and inform the Change
Owner of what's needed. If it is ready to process, then...
Functionality covered
1. Promote
* The issue will be promoted to a user story in taiga,copies the
contents of the custom fields from the issue to the user story. Closes
the issue.
2. Announce
* The tool would have the functionality to enable announcing the
change proposal to devel and devel-announce lists using smtp. It will
also automatically change the story status to announced.
3. fesco-submit
* Allowing creation of a new issue in the FESco Pagure repo directly
from the command line.
4. Accept
* Once the changes are accepted the change-wrangler can create a
tracking bug in Bugzilla along with release notes on Pagure.THe status
of the user story is updated to accepted aswell.
5. Update
* Status can be changed to testable if BZ is "Modified" and to
Complete is BZ is "ON_QA"
6. Creation of Report
* The user can create a report to provide quick view of changes and
their status. It can be in wiki or Html form.
Techstack:
* Python3.6+
* SMTP
* Taiga/Pagure/Bugzilla API's
* Nano/Gedit/Vi ( Inbuilt support to edit text)
* Kerberos(For authentication)
The current sample arg created looks like this [ change-tool convert
--taiga <issue no> <issue no> ] . The advantage of this the Manager
would be able to specify unlimited no of issues to change at once in a
single command using the issue no in taiga to convert to user story.
== Benefit to Fedora ==
The proposed change will make the change-process easier for
everyone.Everyone would be able to see them in one place with
status,id filters. The current wiki process can be bit difficult for
formatting,having defined fields would mean easy access without the
cumbersome wiki edits.
Since changes would be submitted in Issue format on
Taiga,pre-submission discussions would be available thus getting
suggestions/feedback at the first stage itself would be easy for
everyone involved.
== Scope ==
* Proposal owners:
I will be working with the Change-Wrangler(Ben Cotton) throughout the
summer to create this tool from scratch.
* Other developers: N/A (not a System Wide Change)
* Release engineering:(no release engineering impact is expected)
* Trademark approval: N/A (not needed for this Change)
== Upgrade/compatibility impact ==
N/A (not a System Wide Change)
== How To Test ==
N/A (not a System Wide Change)
== User Experience ==
No visible Impact is expected.
== Dependencies ==
No other packages depend on this.
== Contingency Plan ==
* Contingency mechanism: (What to do? Who will do it?) N/A (not a
System Wide Change)
Enough buffer time has been allocated to complete this during the GSoC period.
--
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat
TZ=America/Indiana/Indianapolis
4 years, 7 months
Re: [HEADS-UP]: Mercurial with Python3 on rawhide?
by Neal Becker
I agree that subpackages for py2 and py3 seems best, but I'll have to
see if mercurial can be parallel installed without too much effort.
I don't expect to have time to work on this for the next 2 weeks.
On Sun, Aug 18, 2019 at 9:16 PM Mads Kiilerich <mads(a)kiilerich.com> wrote:
>
> You are giving many good reasons why we need Mercurial packages for
> Python 2 and Python 3, side by side.
>
> That will make it possible for other packages to jump to Python 3. Your
> package will no longer be blocking, and it doesn't have to be your concern.
>
> It will also put the Mercurial package in the good position where it has
> done all the work of transitioning, and the python2 part will be
> entirely optional, only kept alive for benefit of other packages that
> still depend on it.
>
> I am working upstream with tortoisehg. While late, I don't expect any
> problems. The current blocker for Fedora packaging of tortoisehg is the
> lack of Python 3 Mercurial, and the biggest risk is that the Python 2
> Mercurial package goes away before I had time to transition the
> tortoisehg package to depend on Python 3 Mercurial.
>
> /Mads
>
>
>
> On 8/16/19 3:53 PM, Neal Becker wrote:
> > I think tortoisehg is not ported to python3
> >
> > On Wed, Aug 14, 2019 at 1:39 PM Neal Becker <ndbecker2(a)gmail.com> wrote:
> >> I just tested hg-5.1.0 with the latest git version of hg-evolve on
> >> python3 and at least some basic things seem to be working. One
> >> problem:
> >> hg
> >> *** failed to import extension hggit: No module named 'compat'
> >>
> >> That's with the latest pip version of hg-git (0.8.12).
> >>
> >> hg-git is a supported fedora package, so I think we need this to work.
> >>
> >> On Tue, Aug 13, 2019 at 9:35 AM Petr Stodulka <pstodulk(a)redhat.com> wrote:
> >>>
> >>>
> >>> On 12. 08. 19 22:36, Miro Hrončok wrote:
> >>>> On 12. 08. 19 20:37, Petr Stodulka wrote:
> >>>>> Can you explain better what do you mean by that? I am little lost
> >>>>> here.
> >>>> Sure. The idea was:
> >>>>
> >>>> 1) When Fedora 31 is branched (scheduled for tomorrow [1]), push the switch to rawhide (Fedora 32)
> >>>>
> >>>> 2) See what happens, collect feedback.
> >>>>
> >>>> 3) Soon before F31 Beta Freeze (scheduled for 2019-08-29 [1]) decide whether this is worth pushing to F31 (probably not)
> >>>>
> >>>> 4) Soon before F32 mass Python 2 removal flag day (scheduled for mid November [2]), decide whether to revert and request and exception or not
> >>>>
> >>>> [1] https://fedoraproject.org/wiki/Releases/31/Schedule
> >>>> [2] https://fedoraproject.org/wiki/Changes/RetirePython2#Detailed_Description
> >>>>
> >>> Thanks Miro for explanation. That sounds asi the best idea now probably. From that point, I will not create new subpackages for Py2 / Py3 and I will just do the switch tomorrow.
> >>>
> >>> @mercurial-maintainers: if anyone have something against or better solution, answer here guys, otherwise I will do the rebase.
> >>> Just FYI, I will be kinda offline between 2019-08-15 - 2019-08-25 because of PTO. So in case of troubles, I will not be able to do anything during that time. From that point, I could postpone the rebase if needed, but I hope that someone else will be able to help around instead of me in case of troubles.
> >>>
> >>> --
> >>> Petr Stodulka
> >>> OS & Application Modernization
> >>> IRC nicks: pstodulk, skytak
> >>> Software Engineer
> >>> Red Hat Czech s.r.o.
> >>
> >>
> >> --
> >> Those who don't understand recursion are doomed to repeat it
> >
> >
>
--
Those who don't understand recursion are doomed to repeat it
4 years, 7 months
Please fix the aarch64 g++ pic problems in f32 rawhide
by Philip Kovacs
Several of us are getting errors in our c++ packages related to missing PIC flags in aarch64.
Something is amiss there. A small snippet from openmpi:
make[2]: Entering directory '/builddir/build/BUILD/openmpi-4.0.2rc1/ompi/mpi/cxx'
/bin/sh ../../../libtool --tag=CXX --mode=link g++ -DNDEBUG -O2 -g -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS -fexceptions -fstack-protector-strong -grecord-gcc-switches -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -fasynchronous-unwind-tables -fstack-clash-protection -finline-functions -pthread -version-info 60:1:20 -Wl,-z,relro -Wl,--as-needed -Wl,-z,now -specs=/usr/lib/rpm/redhat/redhat-hardened-ld -o libmpi_cxx.la -rpath /usr/lib64/openmpi/lib mpicxx.lo intercepts.lo comm.lo datatype.lo file.lo win.lo cxx_glue.lo ../../../ompi/libmpi.la -lrt -lm -lutil -lz -lhwloc -levent -levent_pthreads
libtool: link: g++ -shared -nostdlib /usr/lib/gcc/aarch64-redhat-linux/9/../../../../lib64/crti.o /usr/lib/gcc/aarch64-redhat-linux/9/crtbeginS.o .libs/mpicxx.o .libs/intercepts.o .libs/comm.o .libs/datatype.o .libs/file.o .libs/win.o .libs/cxx_glue.o -Wl,-rpath -Wl,/builddir/build/BUILD/openmpi-4.0.2rc1/ompi/.libs -Wl,-rpath -Wl,/builddir/build/BUILD/openmpi-4.0.2rc1/orte/.libs -Wl,-rpath -Wl,/builddir/build/BUILD/openmpi-4.0.2rc1/opal/.libs -Wl,-rpath -Wl,/usr/lib64/openmpi/lib -L/builddir/build/BUILD/openmpi-4.0.2rc1/orte/.libs -L/builddir/build/BUILD/openmpi-4.0.2rc1/opal/.libs ../../../ompi/.libs/libmpi.so /builddir/build/BUILD/openmpi-4.0.2rc1/orte/.libs/libopen-rte.so /builddir/build/BUILD/openmpi-4.0.2rc1/opal/.libs/libopen-pal.so -ldl -lrt -lutil -lz -lhwloc -levent -levent_pthreads -L/usr/lib/gcc/aarch64-redhat-linux/9 -L/usr/lib/gcc/aarch64-redhat-linux/9/../../../../lib64 -L/lib/../lib64 -L/usr/lib/../lib64 -L/usr/lib/gcc/aarch64-redhat-linux/9/../../.. -lstdc++ -lm -lpthread -lc -lgcc_s /usr/lib/gcc/aarch64-redhat-linux/9/crtendS.o /usr/lib/gcc/aarch64-redhat-linux/9/../../../../lib64/crtn.o -O2 -g -fstack-protector-strong -grecord-gcc-switches -pthread -Wl,-z -Wl,relro -Wl,--as-needed -Wl,-z -Wl,now -pthread -Wl,-soname -Wl,libmpi_cxx.so.40 -o .libs/libmpi_cxx.so.40.20.1
make[2]: Leaving directory '/builddir/build/BUILD/openmpi-4.0.2rc1/ompi/mpi/cxx'
BUILDSTDERR: /usr/bin/ld: .libs/mpicxx.o: relocation R_AARCH64_ADR_PREL_PG_HI21 against symbol `_ZTVN3MPI5GroupE' which may bind externally can not be used when making a shared object; recompile with -fPIC
BUILDSTDERR: .libs/mpicxx.o: in function `MPI::Group::Group(ompi_group_t*)':
BUILDSTDERR: /builddir/build/BUILD/openmpi-4.0.2rc1/ompi/mpi/cxx/../../../ompi/mpi/cxx/group.h:62:(.text._ZNK3MPI3Win9Get_groupEv[_ZNK3MPI3Win9Get_groupEv]+0x34): dangerous relocation: unsupported relocation
BUILDSTDERR: /usr/bin/ld: .libs/mpicxx.o: relocation R_AARCH64_ADR_PREL_PG_HI21 against symbol `_ZTVN3MPI10ErrhandlerE' which may bind externally can not be used when making a shared object; recompile with -fPIC
BUILDSTDERR: .libs/mpicxx.o: in function `MPI::Errhandler::Errhandler(ompi_errhandler_t*)':
BUILDSTDERR: /builddir/build/BUILD/openmpi-4.0.2rc1/ompi/mpi/cxx/../../../ompi/mpi/cxx/errhandler.h:30:(.text._ZNK3MPI3Win14Get_errhandlerEv[_ZNK3MPI3Win14Get_errhandlerEv]+0x34): dangerous relocation: unsupported relocation
4 years, 7 months
[HEADS-UP]: Mercurial with Python3 on rawhide?
by Petr Stodulka
Hi guys,
as discussion was started week ago, Python2 is dying. As that, some
dependencies of mercurial will be orphaned soon (or they are already)
and mercurial as it is has to move in weeks on Python3. As I wrote
in [0], I already started some testing and investigation.
Currently it seems that with ugly hacky fix, we are able to run
somi-working mercurial with Python3. I did just simple testing
that worked for me and in the latest copr-build (below), it seems
that hgk extension is workin as well. But many of you extensions
will be probably broken. So, I guess the most probably mercurial
will be broken for the others who use it.
So it's question, should I rebase it in rawhide and setup for Python3
already even when it is so broken, or should I wait several weeks yet
for additional fixes?
If anyone is interested about testing before it will be done,
just try:
# dnf copr enable pstodulk/mercurial
- it's just first attempt.
Here is the list of RPMs depending on mercurial:
git-cinnabar
gitifyhg
git-remote-hg
gwsmhg
hg-git
hgsvn
hgview-common
python2-anyvc
python2-wstool
python3-hgapi
python3-wstool
qct-mercurial
rabbitvcs-core
rbm
tortoisehg
trac-mercurial-plugin
Cheers,
Petr
4 years, 7 months
Duplicate speedtest-cli packages in the repo.
by Leigh Scott
speedtest-cli and python3-speedtest-cli appear to be the same package.
Downloading Packages:
python3-speedtest-cli-1.0.2-7.fc30.noarch.rpm 364 kB/s | 44 kB 00:00
--------------------------------------------------------------------------------
Total 64 kB/s | 44 kB 00:00
Running transaction check
Transaction check succeeded.
Running transaction test
The downloaded packages were saved in cache until the next successful transaction.
You can remove cached packages by executing 'dnf clean packages'.
Error: Transaction check error:
file /usr/lib/python3.7/site-packages/speedtest.py from install of python3-speedtest-cli-1.0.2-7.fc30.noarch conflicts with file from package speedtest-cli-1.0.2-6.fc30.noarch
file /usr/lib/python3.7/site-packages/speedtest_cli.py from install of python3-speedtest-cli-1.0.2-7.fc30.noarch conflicts with file from package speedtest-cli-1.0.2-6.fc30.noarch
file /usr/share/man/man1/speedtest-cli.1.gz from install of python3-speedtest-cli-1.0.2-7.fc30.noarch conflicts with file from package speedtest-cli-1.0.2-6.fc30.noarch
Error Summary
4 years, 7 months
CharLS update to 2.0.0 required (soname bump) (rhbz 1744789)
by Ankur Sinha
(Re-sending, got the e-mail address wrong)
Hi!
A new version of CharLS is out and needs to be updated in Fedora. It
contains changes in API/ABI so the following will need to be rebuilt:
dnf repoquery --disablerepo= --enablerepo=-source --arch=src --whatrequires CharLS-devel
dcm2niix-0:1.0.20180622-3.fc30.src
dcmtk-0:3.6.2-4.fc29.src
dcmtk-0:3.6.4-1.fc31.src
gdcm-0:2.8.8-4.fc30.src
gdcm-0:2.8.8-5.fc31.src
I can rebuild all of these as they are maintained by NeuroFedora, but I
do not have commit rights to CharLS. A bug and PR for CharLS have been
pending for >3 weeks now but we've not had a response from the
maintenance team yet:
https://bugzilla.redhat.com/show_bug.cgi?id=1733789
https://src.fedoraproject.org/rpms/CharLS/pull-request/1
Could the maintenance team please take a look at this ASAP? Otherwise,
could you please:
- give the neuro-sig access to the package so we can help maintain it
(all its deps are maintained by us anyway)?
- or: indicate that it would OK for us to request a proven-packager to
accept these changes?
Either would work, but we'd really like to build the dependent packages
ASAP.
--
Thanks,
Regards,
Ankur Sinha "FranciscoD" (He / Him / His) | https://fedoraproject.org/wiki/User:Ankursinha
Time zone: Europe/London
4 years, 7 months