Bug 1184922

In Tumbleweed is version 5.16.0.
Wherefrom do you have 5.14.0?
Please update first and then report your result.

(In reply to Eric Schirra from comment #1)
> In Tumbleweed is version 5.16.0.

Not until a snapshot is released that contains it.

(In reply to Andreas Stieger from comment #2)
> (In reply to Eric Schirra from comment #1)
> > In Tumbleweed is version 5.16.0.
> 
> Not until a snapshot is released that contains it.

Can you not update calibre alone?
How should something tested, after Tumbleweed snapshot update.
Don't understand this.

Is your errors simulary to?:
https://forums.gentoo.org/viewtopic-t-1123597-start-0.html
And https://archlinuxarm.org/forum/viewtopic.php?f=15&t=15055

Can you test it with QTWEBENGINE_DISABLE_SANDBOX?

But best will be to test it with 5.16.0

Have now install 5.16.1 in tumbleweed vm.
Also done zypper dup

Calibre runs without error.
I can add epubs and can read it.

So.
It seams you have a problem with your installation or use some 3party addons.

> Please update first and then report your result.

The system has just been updated:

# rpm -q calibre 
calibre-5.16.1-1.1.i586

# grep -Eo 'openSUSE-release-ftp\|[^|]+' /var/log/zypp/history | sed -r 's/openSUSE-release-ftp\|//g' | tail -1
20210420-947.1

Unfortunately the issue remains.

> Is your errors simulary to?:

They look similar, yes. However I don't understand how exactly this is related to chromium, considering openSUSE no longer provides a 32-bit chromium browser. Or am I missing something?

> Can you test it with QTWEBENGINE_DISABLE_SANDBOX?

I don't know how to do this. If this is still a suggestion, please provide clear steps. However considering I have a some knowledge about what a sandbox is, is it not dangerous to disable such?

> It seams you have a problem with your installation or use some 3party addons.

I don't see how. Also I don't have any 3rd party addons for calibre. Actually this is the first time I read there are such. Before this bug report everything just worked. Also please note: calibre itself does start, however any attempt to open (ebook-viewer) or convert an EPUB file results in the crashes explained initially.

One more thing: Please note that this is a bug report for the 32-bit distribution. I suppose if you test on a 64-bit one you may see different results.

I just wanted to install Tumbleweed 32bit in a KVM because of you. But that doesn't work. Several packages are defective and cannot be installed. Scriptlet errors appear. I think the iso and thus the entire 32bit Tumbleweed is defective and does not work. So I can't help you any further.
Sorry.
Can i close this bug?

This is baffling.

1. This is a bug report which is of critical severity as per your own documentation:

https://bugzilla.opensuse.org/page.cgi?id=importance_matrix.html

You downgraded it to major. I don't know why but either the docs are wrong or the action. Anyway... not the central issue here.

2. I understand that it may be unintentional overlooking to miss the specs of the bug report in section hardware and that's why it was closed prematurely. Anyway... we clarified that, no problem.

But after all that you find out that the whole openSUSE's product (the 32-bit version of the distro) is so broken that it can't even be installed.

I don't understand why should the bug report should be closed because of that?

The whole history here reveals that there are actually more issues which need fixing. Why should the "resolution" to this be to close it? In a community project it would make sense to invite others to look into it, rather than propose to ignore it and leave it broken for good.

Forgive me but this is quite confusing. I hope you understand.

Who is actually "Suse user"?
If you want an answer, you should also reveal your name here.
The package is not critical. The system itself runs. Just not an application.
In addition, the package runs in a 64-bit environment. And that for several versions. Both yourself and tumbleweed.
And I can't test it because I can't install Tumbleweed 32bit in a VM.
The problem / error is not in the package but in another place. So the package is fine here.
Please open an extra bug report if you have further problems with Tumbleweed 32bit.

(In reply to Suse User from comment #6)
> > Can you test it with QTWEBENGINE_DISABLE_SANDBOX?
> 
> I don't know how to do this.

Open a terminal and run the following:
QTWEBENGINE_DISABLE_SANDBOX=1 calibre

This temporarily disables the sandbox filtering for this execution. This is a security feature but seems to be failing for you here.

> Who is actually "Suse user"?

The name the bug reporter choose to use here.

> If you want an answer, you should also reveal your name here.

Sir, if I may point out most kindly and respectfully: I can tell you any name and this won't change (or mean) anything. It will neither make you install a 32-bit version of the distro, nor it will provide any info actually necessary for the real resolution of this issue. So please, don't become aggressive. Also please do not close the bug as "worksforme" because it does not work for you, since you have not even made an actual test as per your own words.

> The package is not critical. The system itself runs. Just not an application.

The documentation (https://bugzilla.opensuse.org/page.cgi?id=importance_matrix.html) says: "Critical: Crash, data loss or corruption, severe memory leak, etc." It says nothing about "the system itself". Here there is an actual crash and a serious problem. If you think the documentation is wrong, I would be glad to read the updated version, so please provide a link if there is one.

> Open a terminal and run the following:
> QTWEBENGINE_DISABLE_SANDBOX=1 calibre

Thank you for explaining. This workaround works, but what about an actual fix without compromising security? Also - what actual security features are disabled by disabling the sandbox?

Reporter, if the bugowner chooses to close the bug that may be the not be the final word on the technical issue. But his decision is at last as valid as you still seeing the issue. The openSUSE community used bugs to track technical defects, not their representation of user issues (a bug tracker, not a helpdesk). Let's not play the reopening game, this defaults towards the bugowner who may drop work at any time.
Instead let's try to work on the reproduction. On the technical side you both seem to be struggling a bit getting the problem reproduced and communicated, and I am aware of your past bug report.
Anyway we seem to have just fixed that. We now know that the QtWebengine Sandbox seems to, at least on your configuration and what seems to be 32 bit systems.

> Thank you for explaining. This workaround works, but what about an actual
> fix without compromising security?

If so inclined either the maintainer or you may report the details to upstream.

> Also - what actual security features are disabled by disabling the sandbox?

Not sure what the ask is. The scope is escapes from possibly malicious books you are converting. Read about it I guess.

Eric, this seems to be related with a chromium interaction with glibc and libsecomp. Something to involve upstream in? Why are we bundling chromium btw?

DAFUQ? You already reported this in bug 1169394

*** This bug has been marked as a duplicate of bug 1169394 ***

> DAFUQ? You already reported this in bug 1169394

Is cynicism required? Yes, that is a report by me (1 year ago) and nobody paid attention to it. Some time after that one of the next system updates resolved the issue and the problem was no more. I opened a new bug report because a lot of packages (perhaps all) have been updated since then. Is that wrong?

> Reporter, if the bugowner chooses to close the bug that may be the not be the final word on the technical issue. But his decision is at last as valid as you still seeing the issue.

I wasn't arguing about the rights of the bugowner. I simply said that it makes no sense to say "this works for me" while saying at the same time "I wasn't even able to test it". How can this be valid? He asked if he could close it - I answered what I think. That's all. Forgive me if I have done wrong.

> The openSUSE community used bugs to track technical defects, not their representation of user issues (a bug tracker, not a helpdesk). Let's not play the reopening game, this defaults towards the bugowner who may drop work at any time.

Right. Please note however: I wasn't asking for help in the sense you are implying. To my mind reporting a bug is an action which helps the whole community (if the bug is fixed). So while I am not being paid to spend time to test a product and report bugs about it, I would appreciate if at least I am not being attacked personally about it. I came in peace.

> Instead let's try to work on the reproduction.

I have done everything which was asked of me. If anything else is needed, please let me know.

> Anyway we seem to have just fixed that. We now know that the QtWebengine Sandbox seems to, at least on your configuration and what seems to be 32 bit systems.

Good. So if I should update and test again, please let me know.

Thank you, sirs.

(In reply to Suse User from comment #14)
> > DAFUQ? You already reported this in bug 1169394
> 
> Is cynicism required? Yes, that is a report by me (1 year ago) and nobody
> paid attention to it. Some time after that one of the next system updates
> resolved the issue and the problem was no more.

Yes, you never updated or closed the original report when the problem went away, thus leaving it laying around along with many other bugs that nobody gets around to look at due to lack of reproducibility.

> I opened a new bug report
> because a lot of packages (perhaps all) have been updated since then. Is
> that wrong?

It would have been better to reference the original, identical report. You left it to someone else to discover it.

> To my mind reporting a bug is an action which helps the whole
> community (if the bug is fixed). So while I am not being paid to spend time
> to test a product and report bugs about it, I would appreciate if at least I
> am not being attacked personally about it. I came in peace.

You seem to be looking very hard for personal attacks.

Reporter, for the current problem, considering the history of reported bugs: Are you running a kernel or glibc that is not the default package, either by means of locking it to an older version, using a different flavor or repository (e.g. Kernel:HEAD)?

Eric, beyond reproducing you can involve the maintainer of qtwebengine. This is where the bug is ultimately.

So. I have now installed Tumbleweed 32 bit in a kvm VM 64bit.
And i can open, read and import epubs in calibre without any error.

So I have no reason or opportunity to change anything.
Because it runs without any problems.

I think he has 3party addons or a problematic graphics card. The problem with the graphics card is dealt with in the calibre FAQS.

He could start calibre in the console with the following:

calibre --ignore-plugins

or:

QTWEBENGINE_CHROMIUM_FLAGS = "- disable-gpu" calibre

I don't think it's a good idea to deactivate the sandbox.

Can we close it now?

(In reply to Andreas Stieger from comment #17)
> Eric, beyond reproducing you can involve the maintainer of qtwebengine. This
> is where the bug is ultimately.

But it works without any errors.
Why should we use the maintainer from qtwebengine?
See my last post.

(In reply to Eric Schirra from comment #18)
> So. I have now installed Tumbleweed 32 bit in a kvm VM 64bit.
> And i can open, read and import epubs in calibre without any error.
> 
> So I have no reason or opportunity to change anything.
> Because it runs without any problems.
> 
> I think he has 3party addons or a problematic graphics card. The problem
> with the graphics card is dealt with in the calibre FAQS.
> 
> He could start calibre in the console with the following:
> 
> calibre --ignore-plugins
> 
> or:
> 
> QTWEBENGINE_CHROMIUM_FLAGS = "- disable-gpu" calibre
> 
> I don't think it's a good idea to deactivate the sandbox.
> 
> Can we close it now?

Sorry call is:

QTWEBENGINE_CHROMIUM_FLAGS="--disable-gpu" calibre

> Yes, you never updated or closed the original report when the problem went away, thus leaving it laying around along with many other bugs that nobody gets around to look at due to lack of reproducibility.

There was no feedback about lack of reproducibility for that particular bug. I have not updated it because... well, quite a lot of time passed after filing it and having it "self resolved" through updates. So I have forgotten.

> It would have been better to reference the original, identical report. You left it to someone else to discover it.

I couldn't find it and didn't have it bookmarked. Sorry. Noted for future reference that I will have to do as you say.

> Reporter, for the current problem, considering the history of reported bugs: Are you running a kernel or glibc that is not the default package, either by means of locking it to an older version, using a different flavor or repository (e.g. Kernel:HEAD)?

I don't think so. I am using only the official repos and Packman.

$ rpm -q kernel-pae glibc
kernel-pae-5.11.12-1.1.i686
kernel-pae-5.11.15-1.2.i686
glibc-2.33-5.2.i686

The 2 proposals:

> calibre --ignore-plugins
> QTWEBENGINE_CHROMIUM_FLAGS="--disable-gpu" calibre

do not fix the problem. The issue remains in both cases.

Is this exclusive to kernel-pae - does this happen with kernel-default?

(In reply to Eric Schirra from comment #18)
> Can we close it now?

(In reply to Eric Schirra from comment #19)
> But it works without any errors.

If you made reasonable attempts to reproduce (which I think you did at this point), give the reporter some time (a week or two) to add some details or provide reliable reproduction steps. Those steps need to create this problem from scratch on another machine. If he sees it and you don't we are still missing something, but cannot proceed.

> Is this exclusive to kernel-pae - does this happen with kernel-default?

Bug#1169394 was reported at the time when I was still using kernel-default. As explained, after it got "self fixed" (through some update) calibre worked without issues wit kernel-default.

I started using kernel-pae in late Dec.2020. There have been no issues with calibre with it until the date the current bug was reported. (yes, I have been updating the system regularly)

Looking at these facts it doesn't seem kernel is related in any way.

I don't know what other details to provide. Please let me know if you need any other specific info.

> I have now installed Tumbleweed 32 bit in a kvm VM 64bit.

The actual hardware here is 32-bit. I don't know if installing 32-bit TW in 64-bit VM would give the same result. Please see:

https://bugzilla.opensuse.org/show_bug.cgi?id=1169394#c8

Fresh info:

I have updated the system to 20210427-956.1.
calibre was NOT updated:

$ rpm -q calibre
calibre-5.16.1-1.1.i586

However calibre now works and the problem with crashes and errors is no more. 

Considering the errors relating to Qt it seems logical to look for the actual issue in relation to Qt. I looked at the qt packages which got an update:

# grep '2021-04-29' /var/log/zypp/history | grep -Eio '\|[^\|]+qt[^\|]+\|[^\|]+' | sed -r 's/^\|//g'
yast2-qt-branding-openSUSE|84.87.20200106-2.2
libqt5-linguist|5.15.2-1.7
libQtQuick5|5.15.2-4.1
libQt5Help5|5.15.2-1.7
libQt5Designer5|5.15.2-1.7
libqt5-linguist-devel|5.15.2-1.7
libqt5-qtdeclarative-tools|5.15.2-4.1
libqt5-qttools-qhelpgenerator|5.15.2-1.7
libQt5DesignerComponents5|5.15.2-1.7
libyui-qt15|4.2.5-1.1
libqt5-qtdeclarative-devel|5.15.2-4.1
libqt5-qttools-devel|5.15.2-1.7
libyui-qt-pkg15|4.2.5-1.1
libqt5-qtwebengine|5.15.3-2.1
libqt5-qtwebengine-devel|5.15.3-2.1
libmarblewidget-qt5-28|21.04.0-1.1

Considering also that this issue obviously did reappear (at least once since bug#1169394) and again did "self resolve", and to avoid further time consuming discussions like this one, it would be good to check what the reason for the issue is (although it is no longer an issue). I hope you can do this.

It runs now and it has nothing to do with calibre itself.
Perhaps in other libs.
Please open a new entry if the error still exists.