Seems like Apple converted their phones over to using a new file format
to store pictures. I was copying some pictures from a phone and noticed
my linux box couldn't read them and they had an interesting extension .heic.
Looks like there is a new image format in town and we need the libheif and
libde265 libraries in order to read it according to the gimp plugin . The
plugin docs say it should be included by default now in gimp but the gimp on
my f29 system says it can't read the file. This is probably because we don't
have the underlying libraries in Fedora.
Anybody been down this road? Is it as simple as getting the libraries in or
is there much more pain involved that I haven't discovered yet?
A lot of discussion about improving the compose process seem to end up
with a "reality check" - that ideas have already been tried but don't
work because of requirements a) b) c) d). You can't have the pony, but
maybe if a lot of effort is put into it, you can have a faster rocking
If want to fundamentally improve the Fedora workflow we need compose
ponies, we can't just have rocking horses!
Perhaps it would make sense to leave the current 8-10 hour compose in
place for the forseeable future, and work on a new system in parallel
where the primary constraint is to be as fast as possible. Hopefully
most problems with the slow compose will get sorted out in the fast
composes, and the slow compose will become more reliable. Perhaps in a
distant future, we can make the new system do everything
I don't know what the system would look like exactly, but you could
imagine things like:
* Composed of several micro-composes (micro-compose-services?) to
avoid blocking on everything completing successfully.
* Able to do speculative composes for CI
* Either x86_64-only, or with decoupled architectures so that we can
throw x86_64 hardware (or cloud resources) at it, and make it super
* No IO /mnt/koji during the compose - having a big network share be
central to the process creates a performance bottleneck, makes it hard
to move to the cloud, and potentially adds a lot of "noise" to
figuring out what is going on where things are slow because of some
other entirely different thing is goin gon.
Add your own bullet points :-)
Hi fellow Fedorians,
I have been intending to orphan php-ZendFramework version 1 for over a
It is End-of-Life, unmaintained (no updates in over 2 years), has known
security issues and probably doesn't fully work with PHP 7.2 and up
Plus, I no longer use it and one of it's dependencies (dojo) is also
orphaned and to be retired by now.
There are two packages in Fedora that depend on php-ZendFramework:
Both packages seem to even rely on the old ZF upstream. So if the
maintainers wish they should either start bundling ZF in those packages
or also think about retiring them.
Bazaar Review recently release article about Intel's Clear Linux with some
cool graphs showing nice performance gain compared to Xubuntu.
I didn't have time to dig in and look how it's performing against Fedora,
but I'd assume Fedora can be compared to Xubuntu in terms of compiler
I think I'll be interesting to look into it and find out if Fedora can't
tweak compiler settings (eg use LTO for critical things like Mesa, Kernel,
...). I think it could be interesting for Fedora users to have this enabled
if there are not any disadvantages other than compile time, compile memory
usage and so on.
What do you think?