Qt6::Multimedia unavailable on some architectures #13
Comments
|
Would it be good enough to make it optional at build time? Would that
cause the Debian build system to try to get the dependencies? If so,
that's an easy fix.
Let's not cause needless regression.
Version 1.5.2 updates the CMakeLists and a few source files to make the
QMultiMedia dependency optional.
On 7/28/23 06:10, Barak A. Pearlmutter wrote:
There's a problem with the Debian package, because
|qt6-multimedia-dev| is not available on all architectures. This issue
is causing a build failure due to unavailable dependencies on
everything except |amd64|, |arm64|, |armhf|, and |i386|. I've
restricted the build to these architectures, but have yet to go
through the rigamarole of getting the release managers to allow the
package into the upcoming distribution despite this apparent regression.
A better (from my perspective) solution would be to make this build
dependency optional, so the library is detected at build time and used
iff available. Not sure how hard that would be...
—
Reply to this email directly, view it on GitHub
<#13>, or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ACZHS6ZOQPOHHWXOEDMFLZLXSO25JANCNFSM6AAAAAA23PPV2M>.
You are receiving this because you are subscribed to this
thread.Message ID: ***@***.***>
--------------8WWioR5PS0MherSBZK6z9OMk
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 8bit
<html><head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body>
<p>Would it be good enough to make it optional at build time? Would
that cause the Debian build system to try to get the dependencies?
If so, that's an easy fix.</p>
<p>Let's not cause needless regression.</p>
<p>Version 1.5.2 updates the CMakeLists and a few source files to
make the QMultiMedia dependency optional.</p>
<p></p>
<div class="moz-cite-prefix">On 7/28/23 06:10, Barak A. Pearlmutter
wrote:<br>
</div>
<blockquote type="cite" ***@***.***">
<p dir="auto">There's a problem with the Debian package, because <code class="notranslate">qt6-multimedia-dev</code> is not available
on all architectures. This issue is causing a build failure due
to unavailable dependencies on everything except <code class="notranslate">amd64</code>, <code class="notranslate">arm64</code>,
<code class="notranslate">armhf</code>, and <code class="notranslate">i386</code>. I've restricted the build to
these architectures, but have yet to go through the rigamarole
of getting the release managers to allow the package into the
upcoming distribution despite this apparent regression.</p>
<p dir="auto">A better (from my perspective) solution would be to
make this build dependency optional, so the library is detected
at build time and used iff available. Not sure how hard that
would be...</p>
<p style="font-size:small;-webkit-text-size-adjust:none;color:#666;">—<br>
Reply to this email directly, <a href="#13" moz-do-not-send="true">view it on GitHub</a>, or <a href="https://github.com/notifications/unsubscribe-auth/ACZHS6ZOQPOHHWXOEDMFLZLXSO25JANCNFSM6AAAAAA23PPV2M" moz-do-not-send="true">unsubscribe</a>.<br>
You are receiving this because you are subscribed to this
thread.<img src="https://github.com/notifications/beacon/ACZHS66YLEOUWQJALSYUTZDXSO25JA5CNFSM6AAAAAA23PPV2OWGG33NNVSW45C7OR4XAZNFJFZXG5LFVJRW63LNMVXHIX3JMTHGZXFASY.gif" alt="" moz-do-not-send="true" width="1" height="1"><span style="color: transparent; font-size: 0; display: none;
visibility: hidden; overflow: hidden; opacity: 0; width: 0;
height: 0; max-width: 0; max-height: 0; mso-hide: all">Message
ID: <span><wagenadl/notedeln/issues/13</span><span>@</span><span>github</span><span>.</span><span>com></span></span></p>
<script type="application/ld+json">[
{
***@***.***": "http://schema.org",
***@***.***": "EmailMessage",
"potentialAction": {
***@***.***": "ViewAction",
"target": "#13",
"url": "#13",
"name": "View Issue"
},
"description": "View this Issue on GitHub",
"publisher": {
***@***.***": "Organization",
"name": "GitHub",
"url": "https://github.com"
}
}
]</script>
</blockquote>
</body>
</html>
…--------------8WWioR5PS0MherSBZK6z9OMk--
|
|
That absolutely solves this. I can put hard dependencies on the library where it's known available, and use a sleazy trick to try to get the autobuild boxes to install it only if available on other architectures. But ... a very similar issue is cropping up for so I guess I'll just wait for those architectures to get their act together. |
|
Very good.
QtWebEngine is worth considering separately. It is only used by the
"webgrab" executable that NotedELN uses to download webpages and convert
them to pdf for archiving. Although webgrab has shipped as part of
NotedELN since its inception, it could easily be spun off into a
separate package. (NotedELN depends on it, but not vice versa, and there
are no shared source files.)
With webgrab as a separate package and as an optional dependency,
NotedELN could run on architectures where QtWebEngine is not available,
even though it could not incorporate downloaded webpages on those
architectures. Since NotedELN already handles temporary lack of internet
connectivity transparently, for users who switch between architectures,
this would mean that webpages that could not be downloaded while on a
WE-less architecture would be downloaded once the user access the
notebook page on an architecture with WE.
Thoughts?
On 8/2/23 04:04, Barak A. Pearlmutter wrote:
That absolutely solves this. I can put hard dependencies on the
library where it's known available, and use a sleazy trick to try to
get the autobuild boxes to install it only if available on other
architectures.
But ... a very similar issue is cropping up for |qt6-webengine-dev|
which I think is not so easy to use conditionally, since the file
|Qt6Config.cmake| from outside this package requires it to consider
Qt6 itself to be available.
|Failed to find required Qt component "WebEngineCore". |
so I guess I'll just wait for those architectures to get their act
together.
—
Reply to this email directly, view it on GitHub
<#13 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ACZHS6ZFQB7EH66NVIJG2JLXTIX25ANCNFSM6AAAAAA23PPV2M>.
You are receiving this because you commented.Message ID:
***@***.***>
--------------qhJioU0WNBkn4LTrIE3nzELv
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 8bit
<html><head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body>
<p>Very good. <br>
</p>
<p>QtWebEngine is worth considering separately. It is only used by
the "webgrab" executable that NotedELN uses to download webpages
and convert them to pdf for archiving. Although webgrab has
shipped as part of NotedELN since its inception, it could easily
be spun off into a separate package. (NotedELN depends on it, but
not vice versa, and there are no shared source files.) <br>
</p>
<p>With webgrab as a separate package and as an optional dependency,
NotedELN could run on architectures where QtWebEngine is not
available, even though it could not incorporate downloaded
webpages on those architectures. Since NotedELN already handles
temporary lack of internet connectivity transparently, for users
who switch between architectures, this would mean that webpages
that could not be downloaded while on a WE-less architecture would
be downloaded once the user access the notebook page on an
architecture with WE.<br>
</p>
<p>Thoughts?<br>
</p>
<div class="moz-cite-prefix">On 8/2/23 04:04, Barak A. Pearlmutter
wrote:<br>
</div>
<blockquote type="cite" ***@***.***">
<p dir="auto">That absolutely solves this. I can put hard
dependencies on the library where it's known available, and use
a sleazy trick to try to get the autobuild boxes to install it
only if available on other architectures.</p>
<p dir="auto">But ... a very similar issue is cropping up for <code class="notranslate">qt6-webengine-dev</code> which I think is
not so easy to use conditionally, since the file <code class="notranslate">Qt6Config.cmake</code> from outside this
package requires it to consider Qt6 itself to be available.</p>
<pre class="notranslate"><code class="notranslate"> Failed to find required Qt component "WebEngineCore".
</code></pre>
<p dir="auto">so I guess I'll just wait for those architectures to
get their act together.</p>
<p style="font-size:small;-webkit-text-size-adjust:none;color:#666;">—<br>
Reply to this email directly, <a href="#13 (comment)" moz-do-not-send="true">view it on GitHub</a>, or <a href="https://github.com/notifications/unsubscribe-auth/ACZHS6ZFQB7EH66NVIJG2JLXTIX25ANCNFSM6AAAAAA23PPV2M" moz-do-not-send="true">unsubscribe</a>.<br>
You are receiving this because you commented.<img src="https://github.com/notifications/beacon/ACZHS66S5EQ6JJQXFY73QM3XTIX25A5CNFSM6AAAAAA23PPV2OWGG33NNVSW45C7OR4XAZNMJFZXG5LFINXW23LFNZ2KUY3PNVWWK3TUL5UWJTTDCA3AA.gif" alt="" moz-do-not-send="true" width="1" height="1"><span style="color: transparent; font-size: 0; display: none;
visibility: hidden; overflow: hidden; opacity: 0; width: 0;
height: 0; max-width: 0; max-height: 0; mso-hide: all">Message
ID: <span><wagenadl/notedeln/issues/13/1662006784</span><span>@</span><span>github</span><span>.</span><span>com></span></span></p>
<script type="application/ld+json">[
{
***@***.***": "http://schema.org",
***@***.***": "EmailMessage",
"potentialAction": {
***@***.***": "ViewAction",
"target": "#13 (comment)",
"url": "#13 (comment)",
"name": "View Issue"
},
"description": "View this Issue on GitHub",
"publisher": {
***@***.***": "Organization",
"name": "GitHub",
"url": "https://github.com"
}
}
]</script>
</blockquote>
</body>
</html>
…--------------qhJioU0WNBkn4LTrIE3nzELv--
|
|
Version 1.5.2 make Qt6::Multimedia optional at build time, so NotedELN can at least build and be used on architectures that do not offer Qt6::Multimedia |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
There's a problem with the Debian package, because
qt6-multimedia-devis not available on all architectures. This issue is causing a build failure due to unavailable dependencies on everything exceptamd64,arm64,armhf, andi386. I've restricted the build to these architectures, but have yet to go through the rigamarole of getting the release managers to allow the package into the upcoming distribution despite this apparent regression.A better (from my perspective) solution would be to make this build dependency optional, so the library is detected at build time and used iff available. Not sure how hard that would be...
The text was updated successfully, but these errors were encountered: