On Mon, Jan 28, 2019 15:47:00 +0100, J. Scheurich wrote:
> > I'd like to get this package reviewed please:
> > - python-pyscaffold: https://bugzilla.redhat.com/show_bug.cgi?id=1669913#
> > Would anyone like to swap reviews?
> I would review it for wdune sponsoring.
Sorry---I'm not current with the wdune scenario. I assumed you meant
that you'd review it unofficially as part of the work to get sponsored
to the packagers group:
I'm not a sponsor yet so I cannot sponsor you to the group myself, but
once you've done a few reviews, a sponsor will be happy to take a look
at them and guide you through the sponsorship process.
If you've submitted a review ticket for wdune already, I will be happy
to review it and provide comments.
Time zone: Europe/London
I'm hoping that this one hasn't been dead for 8 weeks, because all it needs
to get it building again is to disable the gtk-doc generation...
I don't really want to own it, but I have dependent packages, so if no one
else does, I will claim it.
If you want it (or know of some reason it shouldn't be brought back),
please speak up.
we have decided that it is a time to go through Copr backend data and
clean it up a little. Due to several bugs forgetting to remove backend
data after removing their records from the database, _temporarily_
backing up some folder here and there, etc, we ended up with a lot of
unknown data, that should have been already deleted.
So, we wrote a script  to find data that should be deleted, and we
... haven't deleted it yet. Instead, we put it aside in a case there
were any false-positives by the script. If you want to be extra safe,
I am attaching a list of all of those files, you may check it.
If you find out, that we accidentally want to remove any of your data
that is still being used, please contact us immediately! Otherwise, we
are going to delete it once we are running out of disk space (which
may not take a lot of time)
Thank you for understanding,
I'm Anaconda developer and I'm also taking care about our
infrastructure and this Fedora release brought me a plenty of
"unnecessary" work thanks to the fact that compose for Fedora 31 was
not available until a week before beta freeze. That is too late.
I wasn't the only one who had these problems, copr had issues for
Fedora 31 and couldn't enable chroot so they had to do changes to
correct these broken things. And I'm not talking about Fedora QA team
which couldn't test almost anything before beta freeze.
The problem is that when we don't have a compose we don't have packages
for testing and then more and more changes are getting in but we are
not able to check if they are working. If we don't have packages the
mock can't properly work and you are not able to do a system upgrade.
The only test point is compose but that is just a small portion. Not
being able to test Fedora for a few weeks is situation which should not
To make things even worse there was a switch to python 3.8 on Rawhide
which wasn't really prepared (pylint did not worked). So for a few days
we were with broken Fedora 31 and Rawhide too, so most of our tests
were not working. I would really said that we were programming in the
dark. No tests, no check that changes are working. It took me almost a
week to make everything working again not talking about time spend
waiting for the compose to be available.
I want to ask for an improvement here. Ideal solution for me would be
to add rule that there have to be compose to do the branching and if
the compose fails then the branching won't happen. Not sure if this is
doable or how hard it would be to implement a similar rule, however, it
would be an ultimate solution. Then, the compose blocker bugs had to be
solved on Rawhide where they should be solved.
Please tell me what should I do next. Should I file a FESCO ticket to
add this rule?
Good Morning Everyone,
At Flock, a few of us met to discuss a future vision of the packager workflow.
This discussion was triggered by the realization that a number of initiatives
are happening around packaging in Fedora but there is no real shared vision on
what we want the packager UX/workflow to be.
The lack of vision on the packager workflow means we could deploy something
today, thinking it is the improvement over the current workflow but would
prevent us from (or make it harder to) doing other changes afterwords that would
be even more beneficial..
So once that concern was raised, we took some time during the Fedora
Infrastructure hackfest to gather the people interested around a white board and
brainstorm on what a future packager workflow could look like.
We tried not to link this process to any tool in particular as well as focus on
the what and why rather than any how.
Here is what the vision we came to and that we would like to discuss:
○ Every changes to dist-git is done via pull-requests
○ Pull-requests are automatically tested
○ Every commit to dist-git (ie: PR merged) is automatically built in koji
○ Every build in koji results automatically in an update in bodhi
○ Every update in bodhi is automatically tested
○ If the tests pass, the update is automatically pushed to the repository
For this workflow to work nicely we need to fix a few things first:
- We need to work on the change logs in the spec files, as otherwise
pull-requests are going to conflict more often than not
- We need to fine a place to insert the end-user information about an update (in
the PR description?)
- When a group of people want to collectively work on a change (involving one or
more packages), they’ll need a place to collaborate. This could be someone’s
fork or, preferably, a fork of the project collectively maintained by that
For example: the python SIG would have a group with forks of the different
python packages they are working on
- We need to figure out how to enable opening a pull-request again multiple
branches at one.
Why should we agree now on a long term vision?
A concrete example to this, I have been playing with the idea to get ride of git
branches in dist-git for a while now. Basically use git as it is meant to be
used: have one branch for development (most often master) and branch of master
when you need to, not simply because a new version of Fedora happened.
However, if we implemented this, we would break the workflow described above as
suddenly there would be no way to specify that a given PR is meant to land in a
certain version of Fedora or another (Is this PR for rawhide? F31? F30? All of
them? Some of them?).
Having this idea of where we want to go should give us a goal as well as way to
reflect if changes we think are good in isolation would actually help achieving
this vision or not.
This proposal was based on the brainstorming session a few of us had at flock,
but before we can see how to implement it we need more inputs and this is where
you come in :)
Do you like this vision? Would you change some pieces of it? Would you change it
In an ideal world, what would packaging software look like to you?
Looking forward to the discussion,
devel-announce mailing list -- devel-announce(a)lists.fedoraproject.org
To unsubscribe send an email to devel-announce-leave(a)lists.fedoraproject.org
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://email@example.com...
== Summary ==
Better thermal management and peak performance on Intel CPUs by
including thermald in the default install.
== Owner ==
* Name: [[User:benzea| Benjamin Berg]]
* Email: bberg(a)redhat.com
* Name: [[User:ckellner| Christian J. Kellner]]
* Email: ckellner(a)redhat.com
* Product: Workstation
* Responsible WG: Workstation
== Detailed Description ==
Modern Intel-based systems provide sensors and methods to monitor and
control temperature of its CPUs. The Thermal daemon will use those
sensors to monitor the temperature and use the best available method
to keep the CPU in the right temperature envelop. On certain systems
this is needed to reach the maximal performance. For optimal
performance a per-model thermald configuration should be created, this
can either be done by using dptfxtract (available from rpmfusion) or
we could ship static configuration files for a set of known models.
For a more details explanation please consult Intel's
introduction] to thermald.
== Benefit to Fedora ==
Better out-of-the-box experience due to improved cooling methods and
performance on Intel systems.
== Scope ==
* Proposal owners:
- Include the thermald package in the default Workstation install
- Optionally provide patches for thermald to be able to read hardware
specific configuration data
- Optionally collect hardware specific configuration data and ship it
* Other developers: N/A (not a System Wide Change)
* Release engineering:
* Policies and guidelines: N/A (not a System Wide Change)
* Trademark approval: N/A (not needed for this Change)
== Upgrade/compatibility impact ==
N/A (not a System Wide Change)
== How To Test ==
Install the packages and use e.g. turbostat to monitor the
performance. Improvements may only be visible if the non-free
dptfxtract package is also installed.
== User Experience ==
- Better performance on certain hardware
- Better cooling of CPUs on certain hardware
He / Him / His
Fedora Program Manager
A tool I am trying to package is failing only on PPC somehow:
> make: Leaving directory '/builddir/build/BUILD/MUSIC-a78a8e2c90b07274db94265db75c320dbb01f9fb/MUSIC-a78a8e2c90b07274db94265db75c320dbb01f9fb-openmpi/src'
> BUILDSTDERR: error.cc: In function 'void MUSIC::error()':
> BUILDSTDERR: error.cc:36:5: error: 'MPI' has not been declared
> BUILDSTDERR: 36 | MPI::COMM_WORLD.Abort (1);
> BUILDSTDERR: | ^~~
> BUILDSTDERR: error.cc: In function 'int MUSIC::getRank()':
> BUILDSTDERR: error.cc:70:9: error: 'MPI' has not been declared
> BUILDSTDERR: 70 | if (MPI::Is_initialized ())
> BUILDSTDERR: | ^~~
> BUILDSTDERR: error.cc:71:14: error: 'MPI' has not been declared
> BUILDSTDERR: 71 | return MPI::COMM_WORLD.Get_rank ();
> BUILDSTDERR: | ^~~
> BUILDSTDERR: make: *** [Makefile:739: libmusic_la-error.lo] Error 1
On all other arches, it builds just fine, so there's something different
with the openmpi package on ppc here. Any ideas?
Ankur Sinha "FranciscoD" (He / Him / His) | https://fedoraproject.org/wiki/User:Ankursinha
Time zone: Europe/London