python-pip 9.0.x had MIT as License (bundled deps were not mentioned)
python-pip 18.0 now has more enjoyable:
MIT and Python and ASL 2.0 and BSD and ISC and LGPLv2 and MPLv2.0 and
(ASL 2.0 or BSD)
License breakdown is in the specfile.
Dear Fedora developers,
I am Natnaree Asavaseri and currently undertaking a research internship at Nara Institute of Science and Technology, Japan. Note that we are not biased to either GitHub or Microsoft, and this is purely from an empirical research perspective.
As a part of my research in the field of Software Engineering (SE), my professors and I are analyzing the impact of Microsoft's acquisition of GitHub. The main purpose of my survey is understanding how developers perceive the Microsoft's acquisition of GitHub, especially from contributors to Linux distributions and BSD families. If the survey is successful, we will publish our findings at SE academic venues (journals or conference).
So please consider voicing your opinion by allowing us up to 5 minutes to complete my short survey.
We would like to remind you that participation in this survey is completely voluntary and your identity is hidden for anonymity. Thank you for your time in advance.
Natnaree (cc Shade, Raula, Hideaki)
Nara Institute of Science and Technology, Japan
I would like to request a change of the Packaging Guidelines, advising
packagers not to interpose malloc.
The reasons are:
* We have resources to support glibc malloc, but not for other mallocs.
* Other mallocs do not follow ABI and provide insufficient alignment.
* Choosing a malloc is workload-dependent and forcing a non-default
malloc takes options away from system administrators.
This does not concern other allocators, such as Boehm GC or APR, only
the standard malloc interfaces.
Hello devel list,
this is a request for comments for a recent proposal I filed at releng
In short, package managers on Rawhide would no longer replace $releasever
variable with a numerical value (like '29' at this moment, soon '30'), but
with 'rawhide' string instead. I hope this change will make life a bit
easier for third-party repos maintainers, for users, for developers and
sysadmins, and for release engineering. The technical implementation can be
seen in the ticket (it's the 'Proposed solution 1'), together with a long
To provide a longer explanation of the improvements I expect this to bring:
* Third-party repo maintainers will no longer need to provide two different
repo files, one for stable Fedora releases using $releasever in URLs, and
one for Rawhide hardcoding 'rawhide/' in URL and avoiding $releasever in
URL. (Technically, two repo files are not needed if you always use a
numbered dir even for Rawhide, but that's maintenance-heavy, because you
need to change the directory number precisely at Branching time). This
involves COPR as well.
* Users will be able to run commands like "dnf ... --releasever=28" even on
Rawhide. That doesn't work at the moment, because most repo files don't use
$releasever and instead have 'rawhide/' hardcoded.
* Developers and sysadmins will be able to use the same approach regarding
repositories for stable Fedora releases and Rawhide. Rawhide will no longer
be different, requiring special treatment. For example, the same repo URL
can be used to install a system, or the same URL can be used to add an
additional repository to an existing system. As an engineer working on
automation, I was always annoyed how I need to special-case Rawhide
everywhere (and of course, maintain a config file that states which release
number Rawhide currently maps to). That will hopefully be no longer
necessary, or very much reduced.
* Fedora release engineers should be able to get rid of
fedora-repos-rawhide (again, hardcoding 'rawhide/' in URL), and use the
standard repo files instead (making use of $releasever).
There might be other advantages, which I haven't tested or though of.
There are also disadvantages. The only one I know of at this moment, is
that PackageKit is currently incompatible with this change (it uses custom
logic for populating $releasever, different from dnf logic) and will need
Fedora releng has pre-approved this change in the ticket, and the point of
this email is to ask for more feedback from all of you. I'd appreciate if
you could help us identify edge cases we haven't thought of, or point out
which tools would be incompatible with this change, so that we can track
them and discuss it with their developers.
I was asked to bring this issue to the developer community before
FESCO makes a decision.
In several instances there exists packages in Fedora, in which
package-maintainers did not patch security issues, for multiple reasons
including 1. non-responsive maintainer 2. issue hard to patch 3. no one
This is a risk for the distribution, our users and community as a whole
and not to mentioned bad PR :)
I would like to propose the following:
1. If a CRITICAL or IMPORTANT security issue is open against a package
in Fedora-X and by the time X is EOL and the issue is not addressed,
proactively remove the package from X+1
2. If a MODERATE or LOW security issue is open against a package in
Fedora -X and by the time X+! is EOL, the issue is not addressed, remove
it from X+2
1. Once pkg is patches, it can be rebuild and re-introduced into the distro
2. X/X+1 is the best boundary to remove the insecure packages imo, since
inbetween removals are not possible due to the way mirrors work.
3. Maintain a list somewhere (automated maybe) of the list of packages
removed and why.
4. Have a list of critical pkg, which cannot be removed which will break
The above is not set in stone, but is open for discussion. Let me know
what you guys think!
In the end, i would like you leave you all with this parting link:
Huzaifa Sidhpurwala / Red Hat Product Security Team
This is a heads up about a bug which I hit Sunday, if you're
seeing any weird crashes with recently build packages then
this may very well be the cause.
I've filed a ticket with rel-eng to get affected packages
Here is the text of the ticket for those of you looking for
"As discovered last Sunday and discussed here:
A bug was introduced in binutils starting with version binutils-2.31.1-4.fc29 which causes it to put the sections in ELF binaries it produces in non incrementing order. This causes eu-strip to mangle the binary into a broken binary when eu-strip is ran on the ELF binary generated by binutils-2.31.1-4.fc29 or newer. This is a big problem since /usr/lib/rpm/find-debuginfo.sh runs eu-strip on all binaries.
The binutils bug causing this was fixed in binutils-2.31.1-8.fc29 which was build yesterday.
Since any binaries produced by binutils >= 2.31.1-4.fc29 && binutils < 2.31.1-8.fc29 and then processed by eu-strip are (potentially) broken this means that all builds done with a binutils version of 2.31.1-4.fc29 - 2.31.1-7.fc29 need to be rebuild."
I just tried a rebuild of a package in Rawhide, it worked on most
arches, but failed on armv7hl and i686 (our only 32-bit arches). On
both arches, cmake seems to have segfaulted:
+ /usr/bin/cmake -DCMAKE_C_FLAGS_RELEASE:STRING=-DNDEBUG
/var/tmp/rpm-tmp.0imLnb: line 47: 15870 Segmentation fault (core
dumped) /usr/bin/cmake -DCMAKE_C_FLAGS_RELEASE:STRING="-DNDEBUG"
Just wanted to flag this up. I haven't yet tried doing the build in a
mock to try and get the core out, or anything like that.
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net