Comments

54 Comments

There was no real reason for this update. I just needed to know if, as a packager, I can build packages where I do not have (co-)maintainer access, and used this package in my test. It turned out any packager can build any package, and as a side effect, this unnecessary but harmless update got created. I apologize for the noise.

Thanks, I can confirm that after installing qtwebengine-devtools-6.6.0 from updates-testing, eric starts.

karma

I tried to distro-sync myself back to just updates, to investigate more. But that did not work at all — a freeze this long is terrible. In any case, since with updates-testing fully enabled my original problem is gone. I seems to me that this update can be let through, and the remaining problem needs to be solved on the Qt 6 side.

That is different from what I see. When I got the error, I actually had Qt 6.5, and only installed this particular update from testing. I tried with testing repo enabled, core is still dumped, but at a different (later) point in startup:

$ eric7_ide --debug
DEBUG:root:Importing Preferences
DEBUG:root:Starting...
DEBUG:root:Generating Main Window...
DEBUG:root:Initializing Basic Services...
DEBUG:root:Creating Conda Interface...
DEBUG:root:Creating Pip Interface...
DEBUG:root:Creating Virtual Environments Manager...
DEBUG:root:Creating Project Manager...
DEBUG:root:Creating Multi-Project Manager...
DEBUG:root:Creating Debug Server...
Background Service listening on: 127.0.0.1:44593
DEBUG:root:Initializing Plugin Manager...
DEBUG:root:Generating Main User Interface...
DEBUG:root:Creating Application Objects...
DEBUG:root:Creating Viewmanager...
DEBUG:root:Creating Previewer...
DEBUG:root:Creating Python AST Viewer
DEBUG:root:Creating Python Disassembly Viewer
DEBUG:root:Creating Project Browser...
DEBUG:root:Creating Multiproject Browser...
DEBUG:root:Creating Task Viewer...
DEBUG:root:Creating Log Viewer...
DEBUG:root:Creating Debug Viewer...
DEBUG:root:Creating Shell...
DEBUG:root:Creating Template Viewer...
DEBUG:root:Creating File Browser...
DEBUG:root:Creating Symbols Viewer...
DEBUG:root:Creating Code Documentation Viewer...
[1027/085538.581299:FATAL:v8_initializer.cc(516)] Error loading V8 startup snapshot file
[1027/085538.582789:FATAL:v8_initializer.cc(516)] Error loading V8 startup snapshot file
Trace/breakpoint trap (core dumped)
karma

Now I get instead:

$ eric7_ide --debug
DEBUG:root:Importing Preferences
DEBUG:root:Starting...
DEBUG:root:Generating Main Window...
DEBUG:root:Initializing Basic Services...
DEBUG:root:Creating Conda Interface...
DEBUG:root:Creating Pip Interface...
DEBUG:root:Creating Virtual Environments Manager...
DEBUG:root:Creating Project Manager...
DEBUG:root:Creating Multi-Project Manager...
DEBUG:root:Creating Debug Server...
Background Service listening on: 127.0.0.1:42465
DEBUG:root:Initializing Plugin Manager...
DEBUG:root:Generating Main User Interface...
DEBUG:root:Creating Application Objects...
DEBUG:root:Creating Viewmanager...
Segmentation fault (core dumped)

This update has been unpushed.

I will unpush this update, because 0.80.0 does not accept config files valid for 0.79.1. For details, see: https://bodhi.fedoraproject.org/updates/FEDORA-2022-27b2c6bdb9#comment-2829597

This update has been unpushed.

Thank you for testing!

the -alpha in the version number is upstream issue #2158. They have an annoying habit of rewriting release tags, and this release was built from a stale 0.80.0 tag. I have updated the sources in the lookaside cache and issued new build and Bodhi update for Rawhide.

I cannot reproduce the glshader issue. My results are identical between 0.80.0 and 0.79.1, though I notice that shader ids have changed between releases, and I have to use the new ids instead, otherwise get a blurry result and the following warning in the log:

RENDER: Built-in shader 'scan3x' has been renamed; please use 'scaler/scan3x' instead.

I was not aware of this breaking change. I refrain from updating other branches than Rawhide because of this. It does not seem right to break user's configs within a Fedora release.

Meanwhile, Jekyll 4.3.0 and 4.3.1 were released. They use the relaxed Rouge version constaint, as that has been included upstream. I feel there is some risk of wrong update ordering here.

How to do you see this, do we just let things happen in order they do, or should we prevent any possible issues somehow? For example, unpushing the separate update for Jekyll 4.3.1 and instead including that build in this update?

This update has been unpushed.

This update has been unpushed.

This update has been unpushed.

This update has been unpushed.

This update has been unpushed.

This update has been unpushed.

karma

I can still download and upload torrents with this version. I tried transmission-gtk only.

BZ#2021895 transmission: FTBFS with OpenSSL 3.0.0
BZ#2075361 Transmission will not run after upgrade to Fedora 36 Beta because of missing shared libraries libssl.so.1.1 and libcrypto.so.1.1
BZ#2111382 Transmission rpm not available for Fedora 36

The two problems my system was suffering from are fixed.

BZ#2054759 SELinux is preventing dbus-daemon from read access on the lnk_file /var/lib/flatpak/exports/share/dbus-1/services/org.gnome.Music.Tracker3.Miner.Files.service.
BZ#2072740 SELinux is preventing gnome-session-b from 'map' accesses on the file /var/lib/flatpak/exports/share/mime/mime.cache.

This was a mistake due to me being careless with fbrnch. Update to 4.2.2 to follow right after.

Update for 0.78.1 should be the final part of this story.