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 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't use qtwayland or don't use
> qt-build-system).
>
> Because qt-build-system does the automatic wrapping of the programs in
> bin (and cmake-build-system doesn't).
> And qtwayland... supports wayland in qt.
>
> I also attached the output of the script run (qt-wayland-packages.txt).
>
> For all those packages, let's slowly add qtwayland-5 (or whatever is
> appropriate) as an input--and also switch them to qt-build-system if
> they use cmake-build-system now.
>
> Ideally, you would do that if you are using the package yourself. That
> way, you can also test it without undue burden to you (by setting the
> environment variable QT_QPA_PLATFORM=wayland you can make sure that qt
> tries to use wayland). I say that because in the case of vorta, adding
> qtwayland is not enough since the qt-wrap phase doesn't wrap
> already-wrapped files, so since python already wrapped a file, it won't
> be qt-enabled and thus will not work. So one has to test it.
>
> My script is not (yet) smart enough to only include packages that have
> something in /bin in the installation [1]. Nevertheless, I would
> suggest not to add qtwayland to library packages but only to packages
> which contain programs.
>
> I would like such a script to be a permanent feature in CI, checking
> periodically once a week or something. CI because (AFAIK) you have to
> build the packages so you know whether they have something in /bin, and
> because it includes KDE. We should also have a guix lint thing.
>
> (Alternatively, we could make qtbase propagate qtwayland or something.
> That would cause a cyclic dependency, so we would need a
> qtbase-bootstrap package or directly bundle qtwayland with qtbase or
> something)
>
> (Alternatively, we could add qtwayland to all the package as
> propagated-input. I'm against that since it will be bound to conflict if
> you nest environments and since it's an implementation detail)
>
> (Alternatively, we could make the user add qtwayland to their guix home
> configuration (or guix system configuration, hell no). I'm against that
> since it will be bound to conflict if you nest environments and since
> it's an implementation detail)
>
> WDYT?
>
> [1] I do have the equivalent of the following running... but it's gonna
> take a while:
>
> for s in $(guix build $(cat qtwayland-packages.txt))
> do
> if [ -d "${s}/bin" ]
> then
> echo "$s"
> fi
> done
[...]
