Rawhide broken: crypto-policies
by Jerry James
Trying to build a package just now failed
(https://koji.fedoraproject.org/koji/taskinfo?taskID=45145531):
Running transaction check
Transaction check succeeded.
Running transaction test
Transaction test succeeded.
Running transaction
error: lua script failed: [string
"%prein(crypto-policies-20200527-3.gitb234a47.fc33.noarch)"]:19:
attempt to call a nil value
Error in PREIN scriptlet in rpm package crypto-policies
error: crypto-policies-20200527-3.gitb234a47.fc33.noarch: install failed
--
Jerry James
http://www.jamezone.org/
3 years, 11 months
nauty 2.7 rebuilds
by Jerry James
I plan to update nauty from the 2.6 series to the 2.7 series soon.
The new version is *almost* backwards compatible with 2.6. However,
one member of the optionstruct structure changed size (from 32 bits to
64 bits), so out of an abundance of caution I am going to rebuild all
consumers. The packages to be rebuilt are:
coin-or-Cbc
coin-or-Couenne
gap-pkg-nautytracesinterface
giac
Macaulay2
normaliz
polymake
I have done successful mock builds of all except Macaulay2, which
appears to be suffering from a garbage collector issue. I'm looking
at how to fix that. Once I figure it out, I will start these builds,
with the goal of completing them before the datacenter move starts.
--
Jerry James
http://www.jamezone.org/
3 years, 11 months
late generation of assemble code
by Paul Dufresne
I sometime ask myself what have happened to the "LLVM dream"?
The idea of LLVM was not to be *just* an intermediate language for the
compiler. The idea was to push code generation as near as possible of
code execution. Because at execution time, you know what are the
specific features of the CPU, and what is used to most often by the user
of the program.
But it seems CLANG have become a plain replacement of gcc. Just an
alternative compiler. But as I remember the LLVM whitepaper, the idea
was that LLVM generated code was the way programs would be distributed.
It would be possible to generate the assembler at install time. But I
don't think this is the right time because when you install packages...
you have a lot of work to be done. No I think the best time to generate
assembler code is when the CPUs are idle... as a background service.
Sure, you have to optimize the full program because you don't know yet
what features of the program the user will use the most, but this don't
seems such a big problem... because hey... the CPU would not been doing
much useful things anyway. There is the problem of the user trying to
launch the program just after installation... I think it would be
reasonable to show a "finishing compiler of <Foo> program", generate the
assembler code with low optimization, then launch the generated code. It
will still be time later to do a greater level of optimization.
Is there some technical problems for not packaging LLVM code rather than
CPU specific code?
3 years, 11 months
Soname bump of libb2 on F31/EPEL7
by Antonio Trande
Hi all.
`libb2-0.98.1` has been required on F31 [1] and EPEL7 [2]; it expects a
soname bump, so all dependent packages need to be rebuilt:
$ repoquery --whatrequires libb2-devel --disablerepo=*
--enablerepo=*-source
R-argon2-0:0.2.0-8.fc32.src
borgbackup-0:1.1.11-1.fc32.src
gtkhash-0:1.2-2.fc32.src
--
---
Antonio Trande
Fedora Project
mailto 'sagitter at fedoraproject dot org'
GPG key: 0x7B30EE04E576AA84
GPG key server: https://keys.openpgp.org/
3 years, 11 months
Package Review for Mudita24
by erich@ericheickmeyer.com
Hi everyone,
A week ago I requested a package review for Mudita24 (https://bugzilla.redhat.com/show_bug.cgi?id=1836540), and Artur Iwicki stepped-up and did a little bit of review. However, I have not heard from him for a week now.
If anyone else can step-in, I’d be grateful. For a little background on the package:
envy24control is included with alsa-tools, but is known for being very buggy. Mudita24 is a modification of that tool which provides some better features and helps people with certain audio interfaces be able to utilize their hardware better.
Thanks,
Erich
----
Erich Eickmeyer
Fedora Jam
3 years, 11 months