F28 Self Contained Change: Enabling Python Generators
by Jan Kurik
= Proposed Self Contained Change: Enabling Python Generators =
https://fedoraproject.org/wiki/Changes/EnablingPythonGenerators
Change owner(s):
* Igor Gnatenko <ignatenkobrain(a)fedoraproject.org,>
* Neal Gompa <ngompa13(a)gmail.com>
This change enables the ability to choose to use the Python module
dependency generator for packages that provide Python Egg/Wheel
metadata.
== Detailed Description ==
There is RPM dependency generator which is able to automatically add
Requires/Provides and other types of dependencies based on egg/wheel
metadata. The part which is generating Provides has been used in
Fedora since Jun 2016 which means by now all packages which provide
egg/wheel metadata have Provides: pythonX.Ydist(xyz) added
automatically. With this change proposal we allow people to opt-in for
using automatic generation of Requires.
All dependencies which are added are generated out of metadata which
means in order to fix them - you need to fix metadata (usually
setup.py or requirements.txt).
Other distributions (such as Mageia, OpenMandriva, and PLD) have been
using this dependency generator for long time already.
In F29 we plan to propose to make generator opt-out.
== Scope ==
* Proposal owners:
Add macros to python-rpm-macros package which enables dependency generator.
* Other developers:
Packagers are advised to replace their hand-crafted list of
dependencies on python libraries with simple macros.
* Release engineering:
#7276: https://pagure.io/releng/issue/7276
* List of deliverables:
N/A (not a System Wide Change)
* Policies and guidelines:
Packaging:Python Guidelines need to reference how to turn on the
feature (simple variable override). #740:
https://pagure.io/packaging-committee/issue/740 .
* Trademark approval:
N/A (not needed for this Change)
--
Jan Kuřík
Platform & Fedora Program Manager
Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic
6 years, 5 months
EPEL analyse/observation, some question, PR proposals/questions and
more ..
by Tomasz Kłoczko
As preface some oneliner result:
[tkloczko@domek SPECS.fedora]$ for i in el4 el5 el6 el7 rhel centos epel;
do echo -n "$i "; grep '%{?'$i * | wc -l; done
el4 10
el5 243
el6 265
el7 281
rhel 5428
centos 239
epel 45
1) Shortly I'm going to create PR with mass change request to remove all
EL4 and EL5 conditional builds as EL{5,6} are no longer supported.
2) Looks like in recent months number of new/updated EPEL EL6/EL7 packages
dropped down to between few to about 20 a month with sometimes tents
thousands a month Fedora updates on master weight/cost of all EPEL %ifings
is few magnitudes higher than real outcome.
FTR: I'm going to add this to final list of arguments/facts why all EPEL
maintenance should be moved to branches when I'll be sending email with
list of arguments about why EPEL support should be removed from master.
3) When PR with request to remove from master EL{4,5} support will be
finished I'm going to raise next mass change request will be about remove
all <= F25 as all those Fedora versions as well should be no longer
supported on master.
4) I think that Fedora procedures should be updated when some older
version passes EOS. Just after this automatically should be dome mass
update removing support such EOSed version.
5) kind of proposal about change general policy
In many specs I found some commented lines with notes like "Remove before
F<number>".
[tkloczko@domek SPECS.fedora]$ grep -i "remove before f" * | wc -l
161
I think that making such notes should be forbidden and exact set of lines
should be wrapped by %ifing (without addition comments),
This will make cyclic all legacy stuff cleanups easier/possible to perform
using very simple script/oneliner.
Q: is it enough to raise next PR about update Fedora doc about above?
6) I think that all %{rhel} %ifings should be removed or replaced by %{el6}
and %{el7}.
Reason: it duplicated description of the same things.
Q: PR?
7) Like in 6) the same is with %{epel} %ifings
8) Why we have %{centos} %ifings? Theoretically Centos is EL derivate up to
ABI level so all this should be:
a) removed
b) replaced by %{el6} and %{el7} (and if it is anything older .. remove)
c) if ContOS guys are using Fedora gir repos to preserve some CentOS
specific changes they should move all this stuff to own git (create project
on github it is not rocket science). IMO definitely %{centos} is next
candidate to remove from master branch.
Next will try to have closer look on %{rhel}, %{epel} and %{centos} %ifings
to form more and/or more precise conclusions/observations.
kloczek
--
Tomasz Kłoczko | LinkedIn: *http://lnkd.in/FXPWxH <http://lnkd.in/FXPWxH>*
6 years, 5 months
[HEADS UP] rust-pest changes license from MPLv2.0 to MIT or ASL 2.0
by Igor Gnatenko
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Thanks for attention.
- --
- -Igor Gnatenko
-----BEGIN PGP SIGNATURE-----
iQIzBAEBCAAdFiEEhLFO09aHZVqO+CM6aVcUvRu8X0wFAlpl8mAACgkQaVcUvRu8
X0zq+w//fSiqqAkXyQtnKuGyMAkc9VwbROgyu0LVmToAZZ9VDhvj9gbX4wP7Gz4P
qmf5cBEFHnkl37t0WFmvEoZheR5GX0hepPuTNVbWaY8+N8z+4oqGqNQydgbNsLZC
OCnF5ho9+oUB/bNwN7Lc2hZT/LpZVNZtifN3n9vFqrNBsSXoWZirstITsUv2Oef8
kZ2eVEmzhF84eE6fALfuQWNMPyNhL18poG+Gl9fJvlAvYYNzWKhL/JhlB73wpYXq
GhTnFCowwzGpUJ3mBHKrg4qLcgqulKesxKsJeG9UUWwdkd0eZHG5KXPVvitXtpe3
ZyeZEETOtGUgdV3Bedvz0/SftpcO4OIzxv4ignNuERmVteCwJq0WRZ+SpJLBh8rj
mQuvd72Uxp/qfpUQe/1dYKlmOuFBEzjXgkUqh1vStrlOFsc0hHmAMaFhS7+90eBT
PTLHPJ5hvpnSMhHWA1W/wa7HXBmKh2HqCD+Erv8TT2zdNMWmaRpBvjS/Al2ifsVn
OiQ5Dc6HzXFK8cCxw+D9lrwThucE8+09rSwoDWDwQZsmifoUZUznoGWgZo9I/C07
dHVuyVF7lXX9CtbVI3O3JY9UA+R6g/9m17A+HMRpDD+k5Lc0q3NJkryAtSlnEsJl
Q9BUAJi25b761yThXY56loeaZocGMkHhAoF1GwwuiTZ7+N1LUWE=
=XcMN
-----END PGP SIGNATURE-----
6 years, 5 months
GSoC Ideas Time
by Brian Exelbierd
Our Application for GSoC is ready and we will make the submission deadline tomorrow. Therefore we should start working on ideas.
See https://docs.stg.fedoraproject.org/mentored-projects/gsoc/2018/#mentor-in... for details. Text is also below.
regards,
bex
How to Propose a Project
If you want to mentor a specific project, think carefully about several things:
Do you have enough time to work on this with the student during the entire project. You will be helping someone else when they get stuck. You don’t want to become a blocker because you’re busy.
It is harder to find success when you are completely certain of how an idea needs to be implemented; finding a student with the skills and interest to implement a specific solution is a lot harder than finding a student with enough skills to respond to a use case need. Also, students learn more when they help design and guide the project. In other words, provide guidance and direction but let the student do some of the "driving."
Where you can have looser ideas, you may be able to find a student who works as a sort-of intern who can implement a solution to a use case you have. In past experiences, students going after a use case are more likely to get somewhere with self-direction and support from you.
Who can help you? Try to find a second mentor for the project.
If you’re interested in working with a student on a specific project you should post your idea to the Mentored Projects Issue Tracker[1]. Your issue should be tagged GSoC and use the Google Summer of Code template. We strongly encourage you to find a second person to help with mentoring and to solicit feedback on your proposal
Can I be a Mentor Without a Project?
Yes! You can either:
Work with a student who brings an idea to your sub-project. This requires a different level of communication throughout the project, but can be the most rewarding.
Be a general mentor. This is a person who works with all students regardless of their project. To become a general mentor please open an issue in the Mentored Projects Issue Tracker[1] offering your help. Please tag the issue with the GSoC tag.
1: https://pagure.io/mentored-projects/issues
6 years, 5 months
Fedora Infrastructure manager change
by Jim Perrin
Hello Fedora developers,
I know some of you may not be familiar with me[1] unless you’re also
working with CentOS or EPEL, but I’d like to take this opportunity to
introduce myself a bit more formally on the list.
As of 1 February, I’ll be the reporting manager for the Fedora
Infrastructure Administration team, and the Fedora Infrastructure
Applications team[2], as well as the CentOS engineering team internal to
Red Hat. For the most part, this is a Red Hat internal organizational
change that doesn’t really impact anything in the community. Paul
Frields set a good example of being transparent with the community, and
I want to continue that with this transition. Paul won’t be going too
far as part of this transition, as he’s taking a promotion of his own,
and I’ll be reporting to him as part of the new structure.
This is a fantastic group of people, and I’m excited to be working with
them. There will be a bit of transition time as Paul and I work through
the team organization and update the wiki to reflect the changes, but
you’ll probably be seeing a bit more of me around here.
You may now return to your regularly scheduled mailing list.
1. https://fedoraproject.org/wiki/User:Jperrin
2. https://fedoraproject.org/wiki/Fedora_Engineering
6 years, 5 months
Things which are on collision course between Fedora and RHEL/EPEL on
master branch
by Tomasz Kłoczko
Just for the record list of things which are now on crash course with
EPEL/RHEL Fedora which are widely used in Fedora specs:
On EPEL/RHEL in spec must be present in spec:
- BuildRoot
- %clean
- %defattr() in %files
NO ONE adds now any %ifings around those parts of the specs (just please do
not propose start doing this 😀)
Especially remove %defattr() breaks RHEL/EPEL compatibility causing that in
case of many packages files no longer will be owned by root:root but by
user on which package is built.
Then .. just behind the corner we have:
- dropping icons themes caches updates
- drop update desktop files cache
- drop update glib schema index
The number of specs are now having some %ifings or will need to add new
%ifings:
- icons cache update
$ grep gtk-update-icon-cache * | awk -F\. '{print $1}' | uniq | wc -l
411
(it is not only about hiicolor theme
hicolor affects:
$ grep 'gtk-update-icon-cache' * | grep hicolor | awk -F\. '{print $1}' |
uniq | wc -l
303
specs)
- desktop files cache updates:
$ grep update-desktop-database * | awk -F\. '{print $1}' | uniq | wc -l
290
- glib schema index updates
$ grep glib-compile-schemas * | awk -F\. '{print $1}' | uniq | wc -l
107
Not to mention that already in many spec files above has been removed
without the care about RHEL/EPEL. In other words, EPEL/RHEL compatibility
in case of many specs ALREADY gone!!!!
If someone will say that what is on the master branch is RHEL/EPEL
compliant is is not even close to the REAL truth.
Things which we can do:
- remove all /sbin/ldconfig in %post/%postun
- remove all install-info single pages (de)registration and replace it by
file triggers which regenerates /usr/share/info/dir out of all files in
/usr/share/info/*info* files
BTW (de)registration of the single info files is not working now.
Why? Because if anyone will try to regenerate info dir file by regenerate
this file out of *info* files suddenly will find that after this main index
is way longer!!!
As well .. because if many packages with info pages are installed with
--excludedoc some non-zero number of those installations will fail because
this is not working.
in Fedora already general policy is to separate documentation into doc
subpackage because it is ONLY WAY to deal with systems installations with
not at all or limited documentation installed.
As result anaconda installer does not support in interactive mode system
installation without documentation which in many cases makes sense.
Fixing info pages handling will open gates to remove all doc sub packages
and integrate back all this stuff into proper packages.
Effectively this may cause significant reduction number of the packages.
All those things which are possible to remove/improve will need careful
%ifings if anyone really wants to keep RHEL/EPEL compatibility.
The scale of the changes related to ldconfig will be even bigger because we
are talking about:
$ grep /sbin/ldconfig * | awk -F\. '{print $1}' | uniq | wc -l
3080
packages. In case install-info simplifications it is:
$ grep install-info * | awk -F\. '{print $1}' | uniq | wc -l
289
specs.
If we really want to keep on master RHEL/EPEL compatibility EVERY such mass
simplification effectively will cause DRAMATIC INCREASE IN THE COMPLEXITY
of all affected specs!!!
Calling all those Fedora changes as "improvements" will be **100% LIE**.
IMO critical mass has been already reached even if for the very long time
it was not a big deal.
And last argument.
If RHEL/EPEL compatibility is so valuable why no other distributions are
trying to archive such goal to keep all possible specs in simplest possible
form?
And yet another Linux kernel code analogy.
In the past many times I saw new device drivers source code written in the
way which allowed compile kernel module on the wide range of kernel
versions. Using some number of #ifdef it is quite easy.
However, on integration, such code with Linus branch, all this kind of code
have been refused to ask to make module code clean first only for Linus
master branch.
What was handy for kernel driver developer is UNACCEPTABLE on the scale
whole kernel code. Why? One reason is obvious that in many cases it makes
this code unreadable by average kernel developer however it is not the only
issue.
Now kernel policy is that kernel code needs to be indented in an exact way
making this code easy to read for everyone. Problem is that even indent
tool trashes formatting of the C code if there is to many (especially many
levels nested) #ifdefs.
Exactly the same issue is with Fedora specs. Specs with some critical
number especially many times nested %ifings will be impossible to
automatically format or effort on prepare such tool will be tenths times if
not bigger than writing simple awk script which can do this if it will be
no %ifings.
kloczek
--
Tomasz Kłoczko | LinkedIn: http://lnkd.in/FXPWxH
6 years, 5 months
[Test-Announce] Proposal to CANCEL: 2018-01-22 Fedora QA Meeting
by Adam Williamson
Hi folks! I'm proposing we cancel the QA meeting on Monday. It's been a
couple of weeks, but I don't have anything super urgent for discussion,
and at the time of the meeting I'm likely to be trying to take a shower
after 16 hours of traveling from the West Coast to Czechia, so possibly
not in shape to run a meeting!
If anyone would like to have a meeting, and is willing to run it in my
place, please just go ahead and send an announcement mail (and, of
course, show up to run the meeting on Monday). Thanks!
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net
_______________________________________________
test-announce mailing list -- test-announce(a)lists.fedoraproject.org
To unsubscribe send an email to test-announce-leave(a)lists.fedoraproject.org
6 years, 5 months
