Self Introduction
by Iñaki Úcar
Hi everyone,
My name is Iñaki Ucar, and I am based in Madrid, Spain. I have been a
happy Fedora user and advocate for many many years (since Fedora Core
2). Now I would love to start contributing to the project as a package
maintainer, so I am seeking a sponsor.
I am package maintainer for the R Project since 2015, so I am
primarily interested in this ecosystem, which has grown spectacularly
in recent years. To start with, I have submitted my first package,
'simmer', for which I am the upstream maintainer. It is a
discrete-event simulator, and you can find the review request here:
https://bugzilla.redhat.com/show_bug.cgi?id=1609800
For more information, please visit my GitHub profile
https://github.com/Enchufa2, and feel free to drop me an email. My GPG
key can be found in my Keybase profile: https://keybase.io/enchufa2.
Regards,
Iñaki
5 years, 8 months
Golang SIG for Fedora
by Jakub Cajka
Hello,
it seems that lately there has been more people maintaining Go package in the Fedora. I would like to propose to join up and form Go SIG so we could better co-ordinate and collaborate on the packaging issues and general developer experience.
There are few big outstanding issues that needs to be solved that need more than individual work, most notably the Go packaging guidelines and tooling. I think that should be one of the first tasks for the SIG.
To introduce myself. I'm for some while golang (co-)maintainer and recently started co-maintaining origin package. I'm mostly interested in the compiler and developer experience.
Please reply if you would like to participate.
JC
PS: Also I will be at Flock this year and would like to meet up with anyone interested there.
5 years, 8 months
F29 System Wide Change: uEFI for ARMv7
by Jan Kurik
= Proposed System Wide Change: uEFI for ARMv7 =
https://fedoraproject.org/wiki/Changes/uEFIforARMv7
Owner(s):
* Peter Robinson <pbrobinson at fedoraproject dot org>
Move to uEFI as the default boot mechanism for ARMv7 devices.
== Detailed description ==
Currently ARMv7 uses extlinux to boot the kernel on ARMv7. This has
served us very well and has allowed us to standardise the ARMv7 boot
process with the vast majority of devices booting this way OOTB due to
the support being in a wide variety of u-boot releases. Over recent
years there have been a number of improvement to uEFI including robust
support in u-boot. We've supported uEFI on aarch64 as the only way of
booting Fedora supporting both Tianocore, proprietary uEFI
implementations and since Fedora 27 we've supported uEFI via u-boot
too. The uEFI provided by u-boot is now stable enough that we can now
move ARMv7 to this method too allowing us to move ARMv7 to grub2-efi
and have a single standard booth path/stack for both ARMv7 and
aarch64.
== Scope ==
* Proposal owners:
Patches, updates to the process, testing
* Other developers:
System component owners will need to review and merge patches for
certain components.
* Release engineering:
#7606 [https://pagure.io/releng/issue/7606]
** List of deliverables:
N/A
* Policies and guidelines:
N/A I don't believe this changes any policies or guidelines
* Trademark approval:
N/A (not needed for this Change)
--
Jan Kuřík
JBoss EAP Program Manager
Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic
5 years, 8 months
Reliability test for hard drives and SSD
by Andrey Ponomarenko
Hi there!
Good news for all interested in hardware compatibility and reliability.
I've started a new project to estimate reliability of hard drives and SSD in real-life conditions based on the SMART data reports collected by Linux users in the Linux-Hardware.org database since 2014. The initial data (SMART reports), analysis methods and results are publicly shared in a new github repository: https://github.com/linuxhw/SMART. Everyone can contribute to the report by uploading probes of their computers by the hw-probe tool!
The primary aim of the project is to find drives with longest "power on hours" and minimal number of errors. The following formula is used to measure reliability: Power_On_Hours / (1 + Number_Of_Errors), i.e. time to the first error/between errors.
Please be careful when reading the results table. Pay attention not only to the rating, but also to the number of checked model samples. If rating is low, then look at the number of power-on days and number of errors occurred. New drive models will appear at the end of the rating table and will move to the top in the case of long error-free operation.
Thanks to ROSA, Fedora, Ubuntu, Debian, Mint, openSUSE, Arch, Gentoo users and others who had made this work possible by contribution to the database!
5 years, 8 months
Updates to mathematical software
by Jerry James
Hello everyone. Months ago, I started working on updates to a couple of
our mathematical packages. But they, in turn, required other packages to
be updated, and those updates required other packages to be updated, and
the whole thing kind of snowballed. I believe that I have finally reached
a point of closure, where I can update the whole pile and have everything
still work afterwards.
I propose to do the following updates and builds in Rawhide in about a
week. If maintainers of any of these packages object, please let me know
the nature of your objection.
The only explicit soname bump in these updates is libntl.so.35 to
libntl.so.36. However, there are a few other libraries that changed ABI
without a corresponding soname bump (typically with an soname of
libfoo.so.0, sigh), so I will rebuild all consumers.
Changes:
- arb: update from 2.11.1 to 2.13.0
- brial: update from 0.8.5 to 1.2.3. Build for both python 2 and 3.
Add a %check script.
- cbmc: rebuild for glpk 4.65
- coin-or-lemon: rebuild for glpk 4.65
- eclib: update from 20170815 to 20171002
- fflas-ffpack: update from 2.2.2 to 2.3.2. Drop all patches.
- flint: rebuild for ntl 11.0.0. Attempt to work around bz 1555151 on
arm.
- gap-pkg-float: rebuild for libfplll 5.2.1 and mpfi 1.5.3
- gfan: build libgfan as a shared library and distribute it in a new
subpackage, which obsoletes the erroneous gfanlib subpackage of Singular.
- giac: rebuild for libfplll 5.2.1 and mpfi 1.5.3
- givaro: update from 4.0.2 to 4.0.4
- glpk: update from 4.61 to 4.65. Add a patch slated for 4.66, needed
by sagemath. Build with ODBC and MariaDB support.
- latte-integrale: rebuild for ntl 11.0.0 and glpk 4.65
- libfplll: update from 5.1.0 to 5.2.1. Drop the rounding patch, fixed
upstream.
- libgap: require the GAP default packages (silences startup warnings
about missing packages).
- linbox: update from 1.4.2 to 1.5.2. Drop upstreamed fplll patch. Add
gcc8 patch as recommended by upstream to fix a C++ issue.
- Macaulay2: update from 1.9.2 to 1.11. Drop upstreamed verbose_build,
givaro, pari, and endian patches.
- mpfi: update from 1.5.1 to 1.5.3. Drop the aarch64 patch, fixed
upstream.
- normaliz: update from 3.4.0 to 3.5.4. Drop all patches.
- ntl: update from 10.5.0 to 11.0.0
- octave: rebuild for glpk 4.65
- openms: rebuild for glpk 4.65
- pari: backport ellratpoints and hyperellratpoints from pari 2.10
alpha, needed by sagemath. The alternative is to update pari to an alpha
version, which makes me very uncomfortable.
- polymake: update from 3.1 to 3.2r3. Drop upstreamed gcc7 patch.
- ppl: rebuild for glpk 4.65
- pynac: update from 0.7.8 to 0.7.16. Drop arch conditionals for giac,
which is now available on all supported arches.
- python-cvxopt: update from 1.1.9 to 1.2.0
- python-cypari2: update from 1.1.3 to 1.1.4. Drop upstreamed offbyone
patch.
- python-cysignals: update from 1.6.4 to 1.7.1
- python-flask-autoindex: update from 0.4.1 to 0.6. Drop upstreamed
tests patch. Build for both python 2 and 3. Build and package the
documentation.
- python-flask-silk: update from 0.1.2 to 0.2. Do not bundle
flask-sphinx-themes. Build for both python 2 and 3. Build and package the
documentation. Add a %check script.
- python-fpylll: update from 0.2.4dev to 0.4.0dev for libfplll 5.2.1.
- python-gmpy2: update from 2.0.8 to 2.1.0a2. The alpha version has
some functions required by the latest sagemath. Since the only consumers
of this package currently in Fedora are sagemath and sympy, which is
consumed by sagemath, I figure that if the sagemath team is going to
require an alpha version, they are only hurting themselves if something
goes wrong.
- sagemath: update from 8.0 to 8.2. Numerous changes were necessary to
make this work.
- shogun: rebuild for glpk 4.65. Add two patches to fix FTBFS. The
sources use some deprecated json-c macros, which are no longer defined by
default; the first patch includes the relevant header. The second patch
works around a bug in pybtex, which has already been reported to upstream
pybtex and fixed in git. If a new pybtex release is made soon, I will
build it and drop this patch.
- Singular: drop the mistakenly exposed gfanlib package; build with
libgfan instead. Rebuild for ntl 11.0.0 and polymake 3.2r2. Drop the
sequence-point patch, which patches the libgfan sources.
NOTE ON MPFR: There is an update to mpfr 4 in the works:
https://fedoraproject.org/wiki/Changes/mpfr-4.0.0. The above updates help
that effort in the following ways:
- The mpfi update brings in a version that is compatible with both mpfr
3 and 4, so when the time comes, simply rebuilding against mpfr 4 will work.
- The sagemath update brings in a version that wants mpfr 4. For now, I
will patch it to use the old mpfr 3 interface. Once we have mpfr 4
available, all we have to do is remove that patch and rebuild.
Let me know of any concerns you might have about this pile of updates. As
usual with this particular set of packages, some builds take many hours, so
the rebuilds will probably span multiple days. Expect broken deps reports
out of Rawhide while in the middle. They will disappear once the entire
stack has been built.
Regards,
--
Jerry James
http://www.jamezone.org/
5 years, 8 months
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, 8 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, 8 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, 8 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, 8 months
