Re: Waylandify all the qt-using packages - need help

Hi Noé, Noé Lopez via "Development of GNU Guix and the GNU System distribution." writes: > Hi dannym, > > Would it make sense to add qt-wayland to the qt-build-system directly? I think that would make sense yes, in this Wayland era. -- Thanks, Maxim

Re: Waylandify all the qt-using packages - need help

Hi dannym, Would it make sense to add qt-wayland to the qt-build-system directly? Thanks, Noé dan...@friendly-machines.com writes: > Hi, > > So I've noticed that my backups haven't been run for several weeks > because vorta didn't start up because wayland. (I

Waylandify all the qt-using packages - need help

Hi, So I've noticed that my backups haven't been run for several weeks because vorta didn't start up because wayland. (I should make an automated check for that...) Therefore, I made a script to find all similarly broken packages, which are: Packages that use qt but (don&

Re: Add transmission-qt to the transmission package?

> Interesting, does this mean the existing "gui" output of transmission > installs transmission-qt.desktop even though it doesn't include > transmission-qt? If so, that seems like a bug to me. > No, no, the default transmission package doesn't create a transmiss

Re: Add transmission-qt to the transmission package?

Hi Bodertz, On Sat, Dec 21, 2024, at 5:39 PM, Bodertz wrote: > The transmission package (the transmission:gui output specifically) has > transmission-gtk, but I personally prefer transmission-qt. By including > qtbase, qttools, and qtsvg, transmission-qt will also be built. > &

Add transmission-qt to the transmission package?

The transmission package (the transmission:gui output specifically) has transmission-gtk, but I personally prefer transmission-qt. By including qtbase, qttools, and qtsvg, transmission-qt will also be built. I've made a simple package that inherits from transmission to do this: (d

Re: [PATCH 0/1] qt-build-system: Wrap with build variables to allow %outputs in arguments

erhaps you are getting at that you'd expect the older way to > still work? Perhaps qt-build purposefully left the older procedure > behind as it should have much fewer dependents (which may rely on the > old assoc-ref)? Yes, exactly, I wanted to know if this is purposefully left out,

Re: [PATCH 0/1] qt-build-system: Wrap with build variables to allow %outputs in arguments

83e34fe1>. > I think the issue is in qt using different system than build systems such > as cmake or gnu. Since I am unsure about the reason for qt not having > the same structure, I am submitting this to guix devel for discussion, > as well as opening a patch in case this is fi

[PATCH 0/1] qt-build-system: Wrap with build variables to allow %outputs in arguments

It is impossible to refer to %outputs in arguments like #:configure-flags (ie. `(assoc-ref %outputs "out")` leads to unbound-variable %outputs). I think the issue is in qt using different system than build systems such as cmake or gnu. Since I am unsure about the reason for qt not havin

On updating anki to latest Qt version

Hello Robert and others, Checking the logs, I found that you added Anki in Feb (8534c94). As a regular user of anki, I found that the one provided by Guix is simply too old, almost 5 years old. The index of the downloads doesn’t even show 2.1.16. The comment in /gnu/packages/education.scm sho

libexec dir and Qt / qtwebengine fails finding QtWebEngineProcess

Hi, I just built XRview https://codeberg.org/openKMU/xrechnung/ a QT viewer for German electronic invoices. This uses qtwebengine to display convert and the data. This fails finding the QtWebEngineProcess executable. The following paths were searched for Qt WebEngine Process:   /gnu/store

Re: (Lx)Qt team in Guix

Hello, 宋文武 writes: [...] > Hello, I have just pushed 2 commits to remove qt.scm from the scope of > lxqt and add myself to the qt team. > > Happy weekend! Yay! Thank you, and happy weekend to you as well! -- Thanks, Maxim

Re: (Lx)Qt team in Guix

Hi, On Fri, 08 Mar 2024 19:05:57 +0800, Andreas Enge wrote: > > Hello, > > Am Thu, Mar 07, 2024 at 08:46:12PM -0500 schrieb Maxim Cournoyer: > > I think the reason qt.scm is part of the lxqt team is historical; lxqt-team > > predates qt-team. We should probably just rem

Re: (Lx)Qt team in Guix

Maxim Cournoyer writes: > Hi Andreas, > > +guix-devel > > Andreas Enge writes: > >> Hello, >> >> I am reaching out since I am receiving in cc patches for Qt, and realise >> that I do not feel quite confident about them; I added myself because I >&

Re: (Lx)Qt team in Guix

Hello, Am Thu, Mar 07, 2024 at 08:46:12PM -0500 schrieb Maxim Cournoyer: > I think the reason qt.scm is part of the lxqt team is historical; lxqt-team > predates qt-team. We should probably just remove qt.scm from > lxqt-team's scope. What do you think? > > I'd keep

Re: (Lx)Qt team in Guix

Hi Andreas, +guix-devel Andreas Enge writes: > Hello, > > I am reaching out since I am receiving in cc patches for Qt, and realise > that I do not feel quite confident about them; I added myself because I > feel able to work on C code, but I think you are much more involved and

Adding Qt and Telephony teams

Hello Guix! To get this a bit more broadcasted (as suggested by Liliana), I'm reaching out with adding a Qt and Telephony teams (see: #64634 and #64635); you are welcome to join them if these are of interest to you and you would be happy to conduct reviews on relevant patches. Happy ha

[PATCH] WIP upgrade qt 6 to 6.5.0

packages qt) #:use-module (gnu packages cmake) #:use-module (gnu packages compression) #:use-module (gnu packages cpp) + #:use-module (gnu packages crypto) #:use-module (gnu packages cups) #:use-module (gnu packages curl) #:use-module (gnu packages databases) @@ -593,29 +594,28

Re: gstreamer 2.22, webkitgtk 2.40.0, qt 5.15.8 and ffmpeg 6 on staging

Hi Andreas, Andreas Enge writes: > Am Fri, Apr 07, 2023 at 05:24:41PM -0400 schrieb Maxim Cournoyer: >> Reviewing the list of newly broken things, there was a flaky test spot >> in python-pyopenssl (IIRC!) that led me to attempt to upgrade >> python-cryptography, which is a bit more involved tha

Re: gstreamer 2.22, webkitgtk 2.40.0, qt 5.15.8 and ffmpeg 6 on staging

Am Fri, Apr 07, 2023 at 05:24:41PM -0400 schrieb Maxim Cournoyer: > Reviewing the list of newly broken things, there was a flaky test spot > in python-pyopenssl (IIRC!) that led me to attempt to upgrade > python-cryptography, which is a bit more involved than I'd like. Okay, so I cherry-picked you

Re: gstreamer 2.22, webkitgtk 2.40.0, qt 5.15.8 and ffmpeg 6 on staging

Hi Andreas, Andreas Enge writes: > Hello Maxim, > > Am Tue, Mar 28, 2023 at 11:10:01PM -0400 schrieb Maxim Cournoyer: >> It'd be useful if people tested it by reconfiguring their systems with >> it or updating their profiles, and report any issues, as I'd like to >> merge this branch into master

Re: gstreamer 2.22, webkitgtk 2.40.0, qt 5.15.8 and ffmpeg 6 on staging

Hello Maxim, Am Tue, Mar 28, 2023 at 11:10:01PM -0400 schrieb Maxim Cournoyer: > It'd be useful if people tested it by reconfiguring their systems with > it or updating their profiles, and report any issues, as I'd like to > merge this branch into master in about a week time, if there are no > blo

Re: gstreamer 2.22, webkitgtk 2.40.0, qt 5.15.8 and ffmpeg 6 on staging

d a merge once and do not feel confident about it. Concerning kcodecs, attached is a patch that disables the test (but keeps the class in that is supposed to work around the fixed Qt bug; so it is quite possible that this class is wrong currently). However I did compile a KDE program with it a

Re: gstreamer 2.22, webkitgtk 2.40.0, qt 5.15.8 and ffmpeg 6 on staging

is the ordering > between packages in master, staging and core-updates - it may well be > possible that some packages are newer in staging, others in core-updates. > Or that they are the same in both, but with different patches. > For instance, I also updated qt to 5.15.8 on core-updates, b

Re: gstreamer 2.22, webkitgtk 2.40.0, qt 5.15.8 and ffmpeg 6 on staging

Am Wed, Mar 29, 2023 at 11:53:22AM +0200 schrieb Andreas Enge: > The file was removed in commit > commit 2e7dc813c2b4672f34d135755e928c52c15a1c3a > Author: Volker Krause > Date: Sun Feb 19 20:15:29 2023 +0100 > Remove QTextCodec leftovers > This is all unused internal API now. > of kcode

Re: gstreamer 2.22, webkitgtk 2.40.0, qt 5.15.8 and ffmpeg 6 on staging

; [/tmp/guix-build-kcodecs-5.98.0.drv-0/kcodecs-5.98.0/autotests/kusasciitextcodectest.cpp(56)] > 86% tests passed, 1 tests failed out of 7 Looking at the file, it is a workaround for this Qt bug: https://bugreports.qt.io/browse/QTBUG-83081 which was fixed in 5.17.0. The file was rem

Re: gstreamer 2.22, webkitgtk 2.40.0, qt 5.15.8 and ffmpeg 6 on staging

Am Wed, Mar 29, 2023 at 11:35:24AM +0200 schrieb Andreas Enge: > FAIL! : KUsAsciiTextCodecTest::testBrokenBuiltinEncoding() Compared values > are not the same We are not the only ones: https://bugs.gentoo.org/885615 for version 5.99, but there is no patch. Andreas

Re: gstreamer 2.22, webkitgtk 2.40.0, qt 5.15.8 and ffmpeg 6 on staging

Am Tue, Mar 28, 2023 at 11:10:01PM -0400 schrieb Maxim Cournoyer: > It'd be useful if people tested it by reconfiguring their systems with > it or updating their profiles, and report any issues Supposedly the Qt update breaks kcodecs, which in turn breaks most of KDE. This issue is a

Re: gstreamer 2.22, webkitgtk 2.40.0, qt 5.15.8 and ffmpeg 6 on staging

with different patches. For instance, I also updated qt to 5.15.8 on core-updates, but differently, using a global version variable for making sure to update everything at once. I think this is preferable. In any case, merging this will be a bit difficult to sort out without mixing bits from the tw

gstreamer 2.22, webkitgtk 2.40.0, qt 5.15.8 and ffmpeg 6 on staging

Hi, I've updated the following dependencies in a group (to try to make things a bit more efficient) on the staging branch; the motivation originally stemmed from the latest Jami now requiring FFmpeg 6. It'd be useful if people tested it by reconfiguring their systems with it or updating their pro

Re: Qt in core-updates

lse figure it out... I am too afraid of making security relevant wrong choices here or incidentally downgrading packages by choosing the wrong version. Anyway, I still think it would be good to merge master into core-updates, to get rid of (qt)webkit, and thus to advance on pyqt and consorts. Tha

Re: Qt in core-updates

Am Tue, Feb 28, 2023 at 09:55:28PM +0100 schrieb Andreas Enge: > Am Tue, Feb 28, 2023 at 09:51:49PM +0100 schrieb Andreas Enge: > > Maybe it is time to merge master back into core-updates? > Where the vague "it is time to" could be read as "could you please?". > It is something I have never done, s

Re: Qt in core-updates

Am Tue, Feb 28, 2023 at 09:51:49PM +0100 schrieb Andreas Enge: > Maybe it is time to merge master back into core-updates? Where the vague "it is time to" could be read as "could you please?". It is something I have never done, so it makes me nervous. Well, I suppose I could just merge and try to f

Re: Qt in core-updates

Am Tue, Feb 28, 2023 at 01:20:08PM -0500 schrieb Leo Famulari: > Qtwebkit has been removed from the master branch. Oh right, I even remember now that you sent messages about it. Maybe it is time to merge master back into core-updates? (Although the problem here seems to be unrelated to webkit, it

Re: Qt in core-updates

Qtwebkit has been removed from the master branch. On Tue, Feb 28, 2023, at 13:09, Andreas Enge wrote: > Am Tue, Feb 28, 2023 at 04:13:52PM +0100 schrieb Andreas Enge: >> Now I am trying to build all >> the Qt packages before applying the patch to core-updates; it looks good >>

Re: Qt in core-updates

Am Tue, Feb 28, 2023 at 04:13:52PM +0100 schrieb Andreas Enge: > Now I am trying to build all > the Qt packages before applying the patch to core-updates; it looks good > so far. It went well with all the qt* packages. Then python-pyqt-without-qtwebkit fails already in its config

Re: Qt in core-updates

In the context of security problems and package removal, I just noticed (by "./pre-inst-env guix package -A ^qt") that we still have a qtwebkit package. The latest release dates from 2020, and this also the last release, if I understand correctly that the project has been abandoned

Re: Qt in core-updates (was: KDE in core-updates)

Hello Philip, Kiasoc5, Efraim, thanks a lot for your input! Indeed I got my information that Qt 5 was phased out from Wikipedia, which mentioned May 2021 as the end of support. I did not expect there to be more versions! But then discovered the 5.15.8 version, probably related to the commercial

Re: Qt in core-updates (was: KDE in core-updates)

On Sun, Feb 26, 2023 at 09:38:43PM -0500, kiasoc5 wrote: > On 2/26/23 18:43, Philip McGrath wrote: > > Hi, > > > > On Sunday, February 26, 2023 7:44:20 AM EST Andreas Enge wrote: > > > > > > In any case, I realised that we are still compiling most packages

Re: Qt in core-updates (was: KDE in core-updates)

On 2/26/23 18:43, Philip McGrath wrote: Hi, On Sunday, February 26, 2023 7:44:20 AM EST Andreas Enge wrote: In any case, I realised that we are still compiling most packages (including KDE) with Qt 5, which is seriously outdated (not maintained any more in the free version since May 2021). Qt

Re: Qt in core-updates (was: KDE in core-updates)

Hi, On Sunday, February 26, 2023 7:44:20 AM EST Andreas Enge wrote: > > In any case, I realised that we are still compiling most packages (including > KDE) with Qt 5, which is seriously outdated (not maintained any more in the > free version since May 2021). Qt 6.3 support will end i

Re: Qt in core-updates (was: KDE in core-updates)

should be skipped. I may have found a solution that entails switching from Qt 6.3.1 to 6.3.2 and applying a patch. Does anyone know whether it is possible to just increase the version of qtbase, while keeping all others at 6.3.1? Or do we need to keep in lockstep even with patch level versions?

Re: Status of Qt build system patches on 'staging' branch.

Leo Prikler writes: > It appears that back in the day they were reverted with > 918a099e7422fe8ad3464dc5a1b4f60843297742 before a staging merge on > February 1st. If nothing else happened on staging since, someone will > need to revert the revert or apply the patches themselves once more. These

Re: Status of Qt build system patches on 'staging' branch.

Am Samstag, den 19.06.2021, 13:59 +0800 schrieb Zhu Zihao: > Hello Guix! > > In January I'm following up a series of patches( > https://issues.guix.gnu.org/45784) that fixes Qt build > system to honor user's environment variable. It has been six months > now, >

Status of Qt build system patches on 'staging' branch.

Hello Guix! In January I'm following up a series of patches(https://issues.guix.gnu.org/45784) that fixes Qt build system to honor user's environment variable. It has been six months now, but these patches are still in 'staging' branch. Tho these patches will trigger rebu

Re: Xpdf with or without Qt

Thank you, Vincent, Leo and Simon for all your suggestions! I note that they differ in whether xpdf gets recompiled when dependencies change (keeping a package around in a scheme file or channel) or not (using inferiors or a separate, not updated profile); probably both may have their advantages a

Re: Xpdf with or without Qt

Hi Andreas, On Fri, 26 Feb 2021 at 18:02, Andreas Enge wrote: > How can I personally keep the old variant? I would go with inferior. --8<---cut here---start->8--- (use-modules (guix inferior) (gui

Re: Xpdf with or without Qt

navailable version 4.04-alpha-we-got-back- motif), that would conflict with Guix if a version 5 shipped, that had Qt as an optional input with a Motif fallback. Another would be to use inferiors from a manifest. Inferiors basically work like time-machine, but expressed in terms of Scheme code. A third o

Re: Xpdf with or without Qt

In retrospect, I should probably have added a note in the commit message that it would be a somewhat major change. With an emphasis on the X -> QT migration. On Fri, Feb 26, 2021 at 6:02 PM Andreas Enge wrote: > How can I personally keep the old variant? > Should I create a custom cha

Re: Xpdf with or without Qt

Hello Vincent, thanks for your quick reply! Am Fri, Feb 26, 2021 at 05:27:47PM +0100 schrieb Vincent Legoll: > If Qt isn't found, the GUI viewer (xpdf) won't be built, but the > command line tools will still be built. Okay, I see. So they changed the program, and we should

Re: Xpdf with or without Qt

Hello Andreas, On Fri, Feb 26, 2021 at 4:43 PM Andreas Enge wrote: > commit 35089dca4053bf5888441d1648086cdadb6eb1e4 adds Qt to the xpdf package > and removes most X libraries. The result is quite different and does not > correspond to the synopsis "...based on the Motif toolkit&

Xpdf with or without Qt

Hello, commit 35089dca4053bf5888441d1648086cdadb6eb1e4 adds Qt to the xpdf package and removes most X libraries. The result is quite different and does not correspond to the synopsis "...based on the Motif toolkit" any more, and we get closer to more modern pdf readers such as evince

Re: Qt 5.11 tarballs anyone?

Hi, zimoun skribis: > After 5 unexpected failures with, > > guix build --sources=all $(guix package -A | cut -f1) --fallback What failures did you get? Thanks for giving it a try, Ludo’.

Re: Qt 5.11 tarballs anyone?

Hi, On Mon, 25 Jan 2021 at 20:43, zimoun wrote: > On Mon, 25 Jan 2021 at 17:52, Ludovic Courtès > wrote: > >>> How could I list all the tarballs that ci.guix.gnu.org has? >> >> I suppose you could simply run something like: >> >> guix build -n --sources=all $(guix package -A | cut -f1) > > Th

Re: Qt 5.11 tarballs anyone?

Hi! Christopher Baines skribis: > Kind of, there's this page [1] which tells you about fixed output > derivations for packages, as well as the latest build. > > 1: > https://data.guix-patches.cbaines.net/repository/2/branch/master/latest-processed-revision/fixed-output-package-derivations?syste

Re: Qt 5.11 tarballs anyone?

On Mon, 25 Jan 2021 at 20:12, Christopher Baines wrote: >>> 1: >>> https://data.guix-patches.cbaines.net/repository/2/branch/master/latest-processed-revision/fixed-output-package-derivations?system=x86_64-linux&target=none&latest_build_status=&after_name=&limit_results=&all_results=on >> >> I am

Re: Qt 5.11 tarballs anyone?

zimoun writes: > On Mon, 25 Jan 2021 at 18:49, Christopher Baines wrote: > >> Kind of, there's this page [1] which tells you about fixed output >> derivations for packages, as well as the latest build. >> >> 1: >> https://data.guix-patches.cbaines.net/repository/2/branch/master/latest-processe

Re: Qt 5.11 tarballs anyone?

Hi Chris, On Mon, 25 Jan 2021 at 18:49, Christopher Baines wrote: > Kind of, there's this page [1] which tells you about fixed output > derivations for packages, as well as the latest build. > > 1: > https://data.guix-patches.cbaines.net/repository/2/branch/master/latest-processed-revision/fixe

Re: Qt 5.11 tarballs anyone?

Hi Ludo, On Mon, 25 Jan 2021 at 17:52, Ludovic Courtès wrote: >> How could I list all the tarballs that ci.guix.gnu.org has? > > I suppose you could simply run something like: > > guix build -n --sources=all $(guix package -A | cut -f1) This will download only the source at the current Guix.

Re: Qt 5.11 tarballs anyone?

Ludovic Courtès writes: > Hi, > > zimoun skribis: > >> How could I list all the tarballs that ci.guix.gnu.org has? > > I suppose you could simply run something like: > > guix build -n --sources=all $(guix package -A | cut -f1) > > and see what happens. > > That said, I think Chris Baines rece

Re: Qt 5.11 tarballs anyone?

Hi, zimoun skribis: > How could I list all the tarballs that ci.guix.gnu.org has? I suppose you could simply run something like: guix build -n --sources=all $(guix package -A | cut -f1) and see what happens. That said, I think Chris Baines recently added something to the Guix Data Service

Re: Qt 5.11 tarballs anyone?

Hi Ludo, On Sun, 24 Jan 2021 at 12:46, Ludovic Courtès wrote: > It’s been two years since commit > 0791437f972caa7e48de91ad5cb150a614f617c2 but we lost key tarballs from [...] > This is a reminder of how important Disarchive is! > (See .) Yeah! Definitively

Re: Qt 5.11 tarballs anyone?

Hi Tobias, Tobias Geerinckx-Rice skribis: > There's also what looks like a comprehensive archive at > , although I didn't check the > hashes. Yup, I’ve added that and sources.buildroot in commit 9d01749feaa1586b1caf449712116e7518bb2303 for posterity. Than

Re: Qt 5.11 tarballs anyone?

Ludovic Courtès skribis: > It’s been two years since commit > 0791437f972caa7e48de91ad5cb150a614f617c2 but we lost key tarballs from > that time, in particular Qt 5.11.2 tarballs, which are no longer > available at <https://download.qt.io/archive/>. Right after sending this m

Re: Qt 5.11 tarballs anyone?

Ludovic Courtès 写道： Does anyone happen to have these tarballs? I’d like to re-inject them on ci.guix. I see you(?)'ve found them and done so already: --8<---cut here---start->8--- ~ λ guix build /gnu/store/sx529mnxcdy3amgyhri2w72328m8l98w-qtmultimedia-eve

Qt 5.11 tarballs anyone?

Hi Guix! It’s been two years since commit 0791437f972caa7e48de91ad5cb150a614f617c2 but we lost key tarballs from that time, in particular Qt 5.11.2 tarballs, which are no longer available at <https://download.qt.io/archive/>. You can try for instance with: guix build \ /gnu

Re: updating Jami to "Together", Qt update?

Dnia 2020-12-08, o godz. 00:03:31 Marius Bakke napisał(a): > Jan Wielkiewicz skriver: > > > Hello everyone, > > > > I managed to compile the latest release of Jami and I'll be sending > > patches soon. > > Is anyone planning to update Qt to 5.15.

Re: updating Jami to "Together", Qt update?

Jan Wielkiewicz skriver: > Hello everyone, > > I managed to compile the latest release of Jami and I'll be sending > patches soon. > Is anyone planning to update Qt to 5.15.1? It would be nice if Jami > used this version to stay close to upstream. > I can update it if

Help Wanted: Issues when packaging QT plugins.

Hi, Guix users! I'm planning to package https://github.com/fcitx/fcitx-qt5. A QT plugin to support Fcitx input method. I found 2 issues during the packaging. 1. This is an old issue mentioned in https://lists.gnu.org/archive/html/guix-devel/2019-12/msg00117.html. qt wrapper doesn't

Re: updating Jami to "Together", Qt update?

On 11/18/20 2:17 PM, Pierre Neidhardt wrote: > There must always be a first user ;) that is not cute.

Re: updating Jami to "Together", Qt update?

Dnia 2020-11-18, o godz. 20:17:54 Ryan Prior napisał(a): > On November 18, 2020, Pierre Neidhardt wrote: > > aviva writes: > > > > > nobody i know uses it.  without a community of users, it has no > > purpose > > > > There must always be a first user ;) > > I use Jami regularly with a few adve

Re: updating Jami to "Together", Qt update?

On November 18, 2020, Pierre Neidhardt wrote: > aviva writes: > > > nobody i know uses it.  without a community of users, it has no > purpose > > There must always be a first user ;) I use Jami regularly with a few adventurous friends who like peer-to- peer things. We often have to fall back to

Re: updating Jami to "Together", Qt update?

On 11/18/20 1:11 PM, Jan Wielkiewicz wrote: >> I wish I could find a reason to use it >> >> > Works without a server, full p2p, can run in LAN without the Internet > access, allows sending files p2p, allows audio/video calls, > multi-platform, etc. nobody i know uses it.  without a community of u

Re: updating Jami to "Together", Qt update?

Dnia 2020-11-17, o godz. 21:06:44 aviva napisał(a): > On 11/17/20 8:45 PM, Jan Wielkiewicz wrote: > > Hello everyone, > > > > I managed to compile the latest release of Jami and I'll be sending > > patches soon. > > Is anyone planning to update Qt to 5.1

Re: updating Jami to "Together", Qt update?

Thanks. > > Is anyone planning to update Qt to 5.15.1? > > Not that I know of, Qt support is always welcome! Well, I wouldn't call it a support because I have no idea about Qt development/packaging nor I know how to fully test it, but I can bump the version numbers and hope it compil

Re: updating Jami to "Together", Qt update?

Hi Jan! Jan Wielkiewicz writes: > I managed to compile the latest release of Jami and I'll be sending > patches soon. Congrats and thanks again for your continuous effort! > Is anyone planning to update Qt to 5.15.1? Not that I know of, Qt support is always welcome! -- Pi

Re: updating Jami to "Together", Qt update?

On 11/17/20 8:45 PM, Jan Wielkiewicz wrote: > Hello everyone, > > I managed to compile the latest release of Jami and I'll be sending > patches soon. > Is anyone planning to update Qt to 5.15.1? It would be nice if Jami > used this version to stay close to upstream. >

updating Jami to "Together", Qt update?

Hello everyone, I managed to compile the latest release of Jami and I'll be sending patches soon. Is anyone planning to update Qt to 5.15.1? It would be nice if Jami used this version to stay close to upstream. I can update it if no one plans that. Jan Wielkiewicz

Re: Reproducibility of Qt packages

gnu: linphoneqt: Fix reproducibility issue and improve description. >> >> * gnu/packages/linphone.scm (linphoneqt)[phases]: Rename the 'patch >> phase to >> 'set-version-string, and use the version variable of the package in the >>

Reproducibility of Qt packages

t; * gnu/packages/linphone.scm (linphoneqt)[phases]: Rename the 'patch phase > to > 'set-version-string, and use the version variable of the package in the > replacement. > {set-qt-rcc-source-date-override, fix-cmake-error}: Add phases. > [synopsis]: Ex

Re: Qt build problems after bump to 5.12.7

Submitted qtbase-patched in bug #39758.

Re: Qt build problems after bump to 5.12.7

Pardon me, guix refresh qtbase --list-dependents actually says 668 packages would be rebuild

Re: Qt build problems after bump to 5.12.7

fix[0] to a separate qtbase/fixed package, and use it (on > master) in all packages that currently fail to build because of > this bug. Once Qt 5.12.8 comes out in April (or we upgrade > everything to 5.14), the /fixed variant can be removed on the > staging branch. My only problem is

Re: Qt build problems after bump to 5.12.7

Hi T G-R, I think that makes sense. I am not sure when I can find the time to do it but I will try. - John

Re: Qt build problems after bump to 5.12.7

John Soo 写道： I was looking into the failing freecad build and I found the following bug from the qt 5.12.7 known bugs page (https://wiki.qt.io/Qt_5.12.7_Known_Issues). - Qt-based CMake projects might fail if their build directories contain dots: https://bugreports.qt.io/browse/QTBUG-81715

Qt build problems after bump to 5.12.7

Hi Guix, I was looking into the failing freecad build and I found the following bug from the qt 5.12.7 known bugs page (https://wiki.qt.io/Qt_5.12.7_Known_Issues). - Qt-based CMake projects might fail if their build directories contain dots: https://bugreports.qt.io/browse/QTBUG-81715 I

Re: qt-build-system: Add QT_QPA_PLATFORM=offscreen?

eck-setup > >> + (lambda _ > >> + (setenv "QT_QPA_PLATFORM" "offscreen") > >> + #t) > > Hmm, would it make sense to do that automatically in qt-build-system ? > I was about to suggest this. (ins)efraim@E5400 ~/workspace/guix$

Re: [bug#39229] qt-build-system: Add QT_QPA_PLATFORM=offscreen?

; + (setenv "QT_QPA_PLATFORM" "offscreen") >>> + #t) >> Hmm, would it make sense to do that automatically in qt-build-system ? > > I would be fine with this, since I find myself adding this snippet quite > often when building Qt/KDE

qt-build-system: Add QT_QPA_PLATFORM=offscreen?

") >> + #t) > Hmm, would it make sense to do that automatically in qt-build-system ? I would be fine with this, since I find myself adding this snippet quite often when building Qt/KDE applications. But there *might* be cases, where tests fail due to this setting. (Whi

Re: qt-build-system: prefix or suffix env-variables in wrap-program

Sorry for the late reply. Hartmut Goebel writes: > Am 11.12.19 um 21:25 schrieb Mikhail Kryshen: >> So the correct way to extend XDG_DATA_DIRS would be >> >> export >> XDG_DATA_DIRS="${XDG_DATA_DIRS:-/usr/local/share/:/usr/share/}:/gnu/store/…-kate-…" > > I'm quite confident, adding /usr/shar

Re: qt-build-system: prefix or suffix env-variables in wrap-program

Am 11.12.19 um 21:25 schrieb Mikhail Kryshen: > So the correct way to extend XDG_DATA_DIRS would be > > export > XDG_DATA_DIRS="${XDG_DATA_DIRS:-/usr/local/share/:/usr/share/}:/gnu/store/…-kate-…" I'm quite confident, adding /usr/share etc. here as default would be wrong from a guix point of vi

Re: qt-build-system: prefix or suffix env-variables in wrap-program

Hartmut Goebel writes: > Hi, > > it came to my mind that currently the qt-build-system wraps the program > without passing along any environment variables. Thus e.g. > XDG_CONFIG_DIRS will be overwritten, instead of not extended. Furtunatly > ((guix build utils) wrap-program)

qt-build-system: prefix or suffix env-variables in wrap-program

Hi, it came to my mind that currently the qt-build-system wraps the program without passing along any environment variables. Thus e.g. XDG_CONFIG_DIRS will be overwritten, instead of not extended. Furtunatly ((guix build utils) wrap-program) supports prefixing or suffixing an existing variable

Re: Qt/KDE build system?

Hi, Ludo wrote: > I think you could come up with a ‘qt-build-system’ (is that an > appropriate name?) that simply adds the things above on top of > ‘gnu-build-system’, similar to what ‘glib-or-gtk-build-system’ does. Many thanks for this valuable hint! I've build a prototype

Re: Qt/KDE build system?

Hi! Hartmut Goebel skribis: > I'm currently packaging some KDE applications and find myself adding > this to each of the package descriptions: > >     (arguments > `(#:modules ((guix build cmake-build-system) >       (guix build qt-utils) >  

Qt/KDE build system?

Hi, I'm currently packaging some KDE applications and find myself adding this to each of the package descriptions:     (arguments `(#:modules ((guix build cmake-build-system)   (guix build qt-utils)   (guix build utils))    #:imported-modules (,@%

Re: Need help for updating Qt to 5.12 - cmake link issue

Am 31.10.19 um 17:34 schrieb Efraim Flashner: > Qt is upgraded to 5.12 on staging :) Good to know, so I can save my time on this. I should have had a look at staging :-) -- Regards Hartmut Goebel | Hartmut Goebel | h.goe...@crazy-compilers.com | | www.crazy-compilers.

Re: Need help for updating Qt to 5.12 - cmake link issue

On Wed, Oct 30, 2019 at 04:56:21PM +0100, Hartmut Goebel wrote: > Hi, > > I'm stuck on updating QT to 5.12, which is q prerequisite for updating > KDE Framworks to a recent version. > Qt is upgraded to 5.12 on staging :) > For some of the packages - most of which seem

Need help for updating Qt to 5.12 - cmake link issue

Hi, I'm stuck on updating QT to 5.12, which is q prerequisite for updating KDE Framworks to a recent version. For some of the packages - most of which seem to be rather new to Qt - build fails since the linker does not find some libraries, e.g when building qtgamepad: g++: error: /gnu/

Re: %desktop-services now depends on Qt 5, via colord

Efraim Flashner writes: > On Thu, Jul 19, 2018 at 04:54:39PM +0200, Ludovic Courtès wrote: >> Hello, >> >> Mark H Weaver skribis: >> >> > Efraim Flashner writes: >> >> It sounds like adding Qt to hplip adds plenty of GUI goodies. Could we >&

  1   2   3   4   >