Bugs have been filed asking packagers to build with openblas instead
of atlas. But there are multiple openblas libraries. I can link with
any of the following:
If I understand correctly, the default is a library that cannot
tolerate multiple threads, uses 32-bit integers in the interface, and
does not use "a symbol name suffix", whatever that means. The various
o = use OpenMP (instead of serial)
p = use pthreads (instead of serial)
64 = use 64-bit integers in the interface
_ = use "a symbol name suffix"
The bugs that have been filed have not made any mention of how to
select which of these libraries to link against. I'm looking at how
to switch the sagemath stack over. Since suitesparse sits at the
bottom of the stack, I just followed that package's example at first
and linked with -lopenblas. But now sagemath says:
OpenBLAS : Program will terminate because you tried to start too many threads.
And kills it dead. I think this switch from atlas to openblas was not
planned well. The entire sagemath stack, for example, will need to be
linked with the *same* openblas library. The serial library with the
32-bit integer interface is not the right choice, and I'm going to
need suitesparse to make the same choice as the rest of the stack.
Some of the elements of that stack are OpenMP-enabled, so that may be
the right choice, but I'm not sure. Suitesparse, for example, uses
TBB, which suggests that the thread alternative may be the right
choice for that package. The serial option is definitely not right
for suitesparse, anyway.
How do we select which packages get linked against which openblas
library? That question should have been answered *before* filing all
of these bugs.
Also, I see this in /usr/include/openblas/openblas_config.h:
That suggests that SSE3 and SSSE3 instructions have been built into
one or more of the openblas libraries, which means that users with
machines that do not support those instruction sets will get illegal
instruction errors if they try to use anything linked with openblas.
# Fedora Quality Assurance Meeting
# Date: 2018-09-04 (NOTE: TUESDAY!)
# Time: 15:00 UTC
# Location: #fedora-meeting on irc.freenode.net
We're getting close to Fedora 29 Beta now, and I think there's
some stuff we could usefully discuss at a meeting. However, Monday is a
public holiday in the U.S. and Canada, so I suspect quite a few folks
wouldn't be available. Given that, I'm proposing we run the meeting on
*Tuesday* instead. I'm also gonna propose a blocker meeting for the
same day. If this is especially inconvenient for anyone, please do
reply and say so.
If anyone has any other items for the agenda, please reply to this
email and suggest them! Thanks.
== Proposed Agenda Topics ==
1. Previous meeting follow-up
2. Fedora 29 general status
3. Fedora 29 Change status
4. Test Day update
5. Open floor
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
test-announce mailing list -- test-announce(a)lists.fedoraproject.org
To unsubscribe send an email to test-announce-leave(a)lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://email@example.com...
== Summary ==
glibc-minimal-langpack is added to @Buildsystem group and installed
into the minimal buildroot instead of glibc-all-langpacks. Packages
which need more locales than plain C/C.UTF-8/POSIX need to pull them
in through BuildRequires.
== Owner ==
* Name: Zbigniew Jędrzejewski-Szmek (zbyszek)
* Email: zbyszek(a)in.waw.pl
== Detailed Description ==
Right now glibc-all-langpacks is installed in buildroots (mock, koji,
It is 24 MB, out of the total of 145 MB. Replacing it with
which has negligible size, decreases the buildroot size by 17%.
glibc Requires glibc-langpack, and Suggests glibc-all-langpacks, so it
gets installed automatically to satisfy that dependency. If a
package providing glibc-langpack is installed, glibc-all-langpacks is
This change is basically adding glibc-minimal-langpack to @Buildsystem
in comps and fixing any fallout in packages.
A quick grep over spec files reveals:
$ rg -l 'LC_CTYPE=[^C]' *.spec | wc -l
$ rg -l 'LC_ALL=[^C]' *.spec | wc -l
that there are at least ~50 packages which need adjustment. They can
be either switched over to C.UTF-8 or a BuildRequires can be added.
== Benefit to Fedora ==
The minimal buildroot becomes smaller, making builds slightly faster.
== Scope ==
* Proposal owners:
** adjust comps
** fix packages which can be identified without rebuilding (see grep
** fix fallout in the mass rebuild if anything is missed above
* Other developers: report breakage and/or fix their own packages
* Release engineering: [https://pagure.io/releng/issue/7610 #7610]
* Policies and guidelines: no changes needed
(The Packaging Guidelines already specify that all necessary
dependencies must be declared using BuildRequires.)
* Trademark approval: N/A (not needed for this Change)
== Upgrade/compatibility impact ==
This only affect package building process, so it has no end-user impact.
== How To Test ==
Verify that packages still build after the comps change.
== User Experience ==
Not visible to end-users.
== Dependencies ==
== Contingency Plan ==
Revert the comps change. Any changes in packages would be backwards
compatible, so there's no need to revert them. There is also no need
to rebuild any packages already successfully built.
* Contingency mechanism: remove glibc-minimal-langpack from @Buildsystem
* Blocks release? not directly, but if packages fail to build, it
would be problem
* Blocks product? no
== Documentation ==
Fedora Program Manager
is it possible to build packages like foo0.6 from dist-git repo with name
foo and not foo0.6?
Since in Rust ecosystem from time to time we need to build multiple
versions of a same package, it is much easier if it would be one repo with
branches 0.6, 0.7 instead of multiple separate git repos.
If not, what are the limitations?