We are happy to announce the availability of Packit-as-a-Service ,
a GitHub App, which utilizes the Packit project .
Using the Packit service in your upstream projects helps you
continuously ensure that your projects work in Fedora OS. Just add one
config file  to your repository, along with the RPM spec file and
you're almost there. We have started publishing docs for the service
over here .
In the next couple of months, Packit Service will run in an
invite-only mode, where we need to manually approve every user of the
app. Our initial target is Fedora contributors.
Packit service validates your pull requests by building your software
in Fedora OS. Once the builds are done, Packit lets you know how to
install the RPM with the change inside your environment.
Packit service helps you test the changes before merging them to the
main developer branch and shipping them to your users.
The packit team
I was starting to setup CI for one of my packages in Fedora (cscope),
which requires that I have access to the sources to run my test (cscope uses its
own source tree to search for various symbols to confirm that its working
properly). Getting the sources in the CI environment is a bit of a pain, so I
started working on trying to do this by creating a test subpackage (specifically
named -citest) to package up the sources solely for the purpose of getting them
installed and available during CI runs. It occured to me that this offers
several advantages, among them:
1) the ability to codify dependencies within the ame spec file, rather than
having to copy them to the test.yml file, and keep them in sync
2) The ability to use a file format (rpm spec files) that I'm more familiar with
3) Easy access to tests that are embedded in the source tree
4) minimizing the test harness setup in test.yml
For anyone interested, I've got a pull request started here:
If anyone wants to take a look at the changes I had to make to do this (fair
warning, its still very rough).
That all said, I was wondering if perhaps there was general interest in making
this kind of test model somewhat more formal (i.e. creating an rpm macro library
to make test package generation a bit easier, creating a standard entry point to
run tests, etc).
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)
I released new version of Mock and mock-core-configs. For full release notes see:
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
= 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
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
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
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...
* 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 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.
* Allowing creation of a new issue in the FESco Pagure repo directly
from the command line.
* 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.
* 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.
* 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
== 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.
He / Him / His
Fedora Program Manager
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.
> 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 ), push the switch to rawhide (Fedora 32)
> >>>> 2) See what happens, collect feedback.
> >>>> 3) Soon before F31 Beta Freeze (scheduled for 2019-08-29 ) decide whether this is worth pushing to F31 (probably not)
> >>>> 4) Soon before F32 mass Python 2 removal flag day (scheduled for mid November ), decide whether to revert and request and exception or not
> >>>>  https://fedoraproject.org/wiki/Releases/31/Schedule
> >>>>  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
I'm trying to contact the maintainer (Marek Skalický) of
mongo-cxx-driver, which has a pending update:
However, if I try to select "Need additional information", I get an error:
You can't ask Marek Skalický <mskalick(a)redhat.com> because that account
Should the package have been orphaned?
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 , 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,
# dnf copr enable pstodulk/mercurial
- it's just first attempt.
Here is the list of RPMs depending on mercurial: