python-pip license changed (and clarified)
by Miro Hrončok
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.
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
5 years, 7 months
Research survey: Impact of Microsoft Acquisition of GitHub
by Asavaseri Natnaree
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.
https://goo.gl/forms/lbIL5qsinDRQyTaK2
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.
Best regards,
Natnaree (cc Shade, Raula, Hideaki)
Nara Institute of Science and Technology, Japan
5 years, 7 months
More math updates, with sonames bumps and license updates
by Jerry James
I've accumulated another set of package updates for the
sagemath/Macaulay2 set of packages. I would like to build these in
Rawhide in about a week. Here are the proposed changes. Please let
me know of any objections. I believe I have all dependent packages
for the soname bumps on the list to rebuild.
arb: update to 2.14.0
clisp: rebuild due to the pari update
cocoalib: update to 0.99595
eclib: update to 20180710. This is an soname bump (libec.so.3 -> libec.so.4)
flint: rebuild due to the ntl update
giac: rebuild due to the cocoalib, ntl, and pari updates
latte-integrale: rebuild due to the ntl update
linbox: rebuild due to the ntl update
Macaulay2: update to 1.12.0.1
normaliz: rebuild due to the cocoalib update
ntl: update to 11.2.1. This is an soname bump (libntl.so.37 -> libntl.so.38)
pari: update to 2.11.0 (which means that the backport of ellratpoints
is no longer needed). The license of the pari package will change
from GPL+ to GPLv2+. I believe that upstream intended GPLv2+ all
along, but they have now explicitly stated so.
pari-galpol: update to 20180625
pynac: rebuild due to the ntl update
python-cypari2: rebuild due to the pari update
python-cysignals: update to 1.7.2 due to the pari update
sagemath: rebuild due to the arb, eclib, and ntl updates
Singular: rebuild due to the ntl update
Regards,
--
Jerry James
http://www.jamezone.org/
5 years, 7 months
Request for joining LxQT SIG
by Zamir SUN
Hi all,
Sorry for cross-posting.
As I mentioned in this thread[1], I want to get libqtxdg updated in
Fedora. However this will affect LxQT.
$ sudo dnf repoquery --whatrequires libqtxdg
Failed to synchronize cache for repo 'fzug-free', disabling.
Last metadata expiration check: 1:31:27 ago on Fri 03 Aug 2018 07:44:54
PM HKT.
deepin-qt5integration-0:0.2.8.3-4.fc28.i686
deepin-qt5integration-0:0.2.8.3-4.fc28.x86_64
liblxqt-0:0.11.1-8.fc28.i686
liblxqt-0:0.11.1-8.fc28.x86_64
libqtxdg-devel-0:2.0.0-11.fc28.i686
libqtxdg-devel-0:2.0.0-11.fc28.x86_64
lxqt-about-0:0.11.1-6.fc27.x86_64
lxqt-admin-0:0.11.1-7.fc27.x86_64
lxqt-config-0:0.11.1-8.fc28.x86_64
lxqt-globalkeys-0:0.11.1-6.fc27.i686
lxqt-globalkeys-0:0.11.1-6.fc27.x86_64
lxqt-notificationd-0:0.11.1-6.fc27.x86_64
lxqt-openssh-askpass-0:0.11.1-6.fc27.x86_64
lxqt-panel-0:0.11.1-7.fc28.x86_64
lxqt-policykit-0:0.11.1-6.fc27.x86_64
lxqt-powermanagement-0:0.11.1-6.fc27.x86_64
lxqt-qtplugin-0:0.11.1-11.fc28.i686
lxqt-qtplugin-0:0.11.1-11.fc28.x86_64
lxqt-runner-0:0.11.1-6.fc27.x86_64
lxqt-session-0:0.11.1-6.fc27.x86_64
lxqt-sudo-0:0.11.1-6.fc27.x86_64
I see LxQT 0.13.0 has already released[2]. So I updated all the
aforementioned SPEC locally to 0.13.0
Although I know I can file PR one by one to LxQT packages like[3], but
it would be a huge amount of work. I am already a packager so I am
writing to ask for joining the LxQT SIG so that I can get these into
Fedora after the update of libqtxdg.
P.S. Other specs will be submitted to fork repos later today or tomorrow.
Thanks.
[1]
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.o...
[2] https://lxqt.org/release/2018/05/21/lxqt-0130/
[3] https://src.fedoraproject.org/fork/zsun/rpms/lxqt-build-tools
--
Ziqian SUN (Zamir)
GPG : 1D86 6D4A 49CE 4BBD 72CF FCF5 D856 6E11 F2A0 525E
Want to know more about Fedora?
Visit https://fedoraproject.org/wiki/
Ready to contribute? See https://whatcanidoforfedora.org/
5 years, 7 months
Guideline change: glibc malloc as the C/C++/Rust allocator
by Florian Weimer
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.
Comments?
Thanks,
Florian
5 years, 7 months
libsbw soname bump
by Antonio Trande
Hi all.
'libsbw' soname will change from 2.11 to 2.12
Just 'COPASI' will need a rebuild, probably.
Regards.
--
---
Antonio Trande
Fedora Project
mailto 'sagitter at fedoraproject dot org'
GPG key: 0x5E212EE1D35568BE
GPG key server: https://keys.fedoraproject.org/
5 years, 7 months
RFC: make $releasever return "rawhide" on Rawhide
by Kamil Paral
Hello devel list,
this is a request for comments for a recent proposal I filed at releng
tracker:
https://pagure.io/releng/issue/7445
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
discussion.
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
adjustments.
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.
Thanks,
Kamil
5 years, 7 months