Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.bugs.dist > #1177124 > unrolled thread

Bug#1057359: qmake: use qmake6 when QT_SELECT=qt6

Back to article view | Back to linux.debian.bugs.dist

Contents

  Bug#1057359: qmake: use qmake6 when QT_SELECT=qt6 Alexandre Detiste <alexandre.detiste@gmail.com> - 2023-12-04 00:10 +0100
    Bug#1057359: qmake: use qmake6 when QT_SELECT=qt6 Salvo Tomaselli <tiposchi@tiscali.it> - 2023-12-04 11:10 +0100
      Bug#1057359: qmake: use qmake6 when QT_SELECT=qt6 Alexandre Detiste <alexandre.detiste@gmail.com> - 2023-12-07 12:40 +0100
      Bug#1057359: qmake: use qmake6 when QT_SELECT=qt6 Helmut Grohne <helmut@subdivi.de> - 2023-12-11 16:40 +0100
        Bug#1057359: qmake: use qmake6 when QT_SELECT=qt6 Lisandro Damián Nicanor Pérez Meyer <perezmeyer@gmail.com> - 2023-12-11 17:30 +0100
          Bug#1057359: qmake: use qmake6 when QT_SELECT=qt6 Lisandro Damián Nicanor Pérez Meyer <perezmeyer@gmail.com> - 2023-12-11 17:30 +0100
            Bug#1057359: qmake: use qmake6 when QT_SELECT=qt6 Sune Stolborg Vuorela <sune@debian.org> - 2023-12-11 18:20 +0100
              Bug#1057359: qmake: use qmake6 when QT_SELECT=qt6 Alexandre Detiste <alexandre.detiste@gmail.com> - 2023-12-12 10:00 +0100
        Bug#1057359: qmake: use qmake6 when QT_SELECT=qt6 Salvo Tomaselli <tiposchi@tiscali.it> - 2023-12-13 19:10 +0100
          Bug#1057359: qmake: use qmake6 when QT_SELECT=qt6 Lisandro Damián Nicanor Pérez Meyer <perezmeyer@gmail.com> - 2023-12-16 15:50 +0100
            Bug#1057359: qmake: use qmake6 when QT_SELECT=qt6 Alexandre Detiste <alexandre.detiste@gmail.com> - 2023-12-17 23:30 +0100
        Bug#1057359: qmake: use qmake6 when QT_SELECT=qt6 Patrick Franz <deltaone@debian.org> - 2023-12-13 19:40 +0100

#1177124 — Bug#1057359: qmake: use qmake6 when QT_SELECT=qt6

Package: debhelper
Version: 13.11.8
Severity: normal
X-Debbugs-Cc: debian-devel-games@lists.debian.org

Hi,

While packaging "xaos" I found out Qt6 integration in debhelper
is not yet quite ready.

The debian/rules is absolute barebones:

> export DEB_BUILD_MAINT_OPTIONS = hardening=+all
> export QT_SELECT=qt6
> 
> %:
>        dh $@

Yet it fails, when patching qmake.pm by adding a single "6",
it justs works.

Could qmake.pm be made to use "qmake6" when QT_SELECT=qt6 ?

Greetings,


    --- /tmp/qmake.pm       2023-12-03 23:45:47.649530519 +0100
    +++ /usr/share/perl5/Debian/Debhelper/Buildsystem/qmake.pm      2023-12-03 23:44:10.180965057 +0100
    @@ -97,7 +97,7 @@
            if (is_cross_compiling()) {
                    return dpkg_architecture_value("DEB_HOST_GNU_TYPE") . "-qmake";
            }
    -       return 'qmake';
    +       return 'qmake6';
     }

     1

-- System Information:
Debian Release: trixie/sid
  APT prefers testing
  APT policy: (501, 'testing'), (450, 'unstable'), (400, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 6.5.0-4-amd64 (SMP w/2 CPU threads; PREEMPT)
Kernel taint flags: TAINT_USER
Locale: LANG=fr_BE.UTF-8, LC_CTYPE=fr_BE.UTF-8 (charmap=UTF-8), LANGUAGE=fr_BE:fr
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages debhelper depends on:
ii  autotools-dev            20220109.1
ii  dh-autoreconf            20
ii  dh-strip-nondeterminism  1.13.1-1
ii  dpkg                     1.22.1
ii  dpkg-dev                 1.22.1
ii  dwz                      0.15-1
ii  file                     1:5.45-2
ii  libdebhelper-perl        13.11.8
ii  libdpkg-perl             1.22.1
ii  man-db                   2.12.0-1
ii  perl                     5.36.0-10
ii  po-debconf               1.0.21+nmu1

debhelper recommends no packages.

Versions of packages debhelper suggests:
pn  dh-make  <none>

-- no debconf information

[toc] | [next] | [standalone]

#1177163

[Multipart message — attachments visible in raw view] — view raw

I use this in my rules when using qt6


%:
        dh $@

override_dh_auto_configure:
        ln -s /usr/bin/qmake6 ./qmake
        PATH=`pwd`:$(PATH) dh_auto_configure

override_dh_auto_clean:
        $(RM) qmake
        dh_auto_clean



-- 
Salvo Tomaselli

"Io non mi sento obbligato a credere che lo stesso Dio che ci ha dotato di
senso, ragione ed intelletto intendesse che noi ne facessimo a meno."
                -- Galileo Galilei

https://ltworf.codeberg.page/

[toc] | [prev] | [next] | [standalone]

#1177627

Thanks you


It did the work for one game but I'm now stuck further with two other games:
qmake6 complains it can't parse the parameters it get
and install newer qmake6 from experimental remove other needed stuff.

I want to give it a try to build this with the new debputy,
and see what it takes to get it working.

deputy is a new debhelper remake / replacement.


I think these games are good candidates
because they will likely never need a backport to bookworm.

The games:
 - xaos: ok
 - hexalate: ko
 - icebreaker: ko
 - peg-e: ko

Le lun. 4 déc. 2023 à 10:58, Salvo Tomaselli <tiposchi@tiscali.it> a écrit :
>
> I use this in my rules when using qt6
>
>
> %:
>         dh $@
>
> override_dh_auto_configure:
>         ln -s /usr/bin/qmake6 ./qmake
>         PATH=`pwd`:$(PATH) dh_auto_configure
>
> override_dh_auto_clean:
>         $(RM) qmake
>         dh_auto_clean

[toc] | [prev] | [next] | [standalone]

#1178150

[Multipart message — attachments visible in raw view] — view raw

Hi,

On Mon, Dec 04, 2023 at 10:58:44AM +0100, Salvo Tomaselli wrote:
> I use this in my rules when using qt6
> 
> 
> %:
>         dh $@
> 
> override_dh_auto_configure:
>         ln -s /usr/bin/qmake6 ./qmake
>         PATH=`pwd`:$(PATH) dh_auto_configure
> 
> override_dh_auto_clean:
>         $(RM) qmake
>         dh_auto_clean

This is also being used in src:explosive-c4 now and the approach breaks
cross compilation. Please stop doing this, we'll have to touch all of
these.

Still the use case is real and we need a better way to build packages
with qmake6. I was talking with Sune and Lisandro on IRC and their
consensus seems to have been that qtchooser and QT_SELECT are dead and
should not be used for Qt6. They suggested that we add add a new
--buildsystem to debhelper. We already have qmake_qt4 and qmake, why not
have qmake6? While changing QT_SELECT from qt5 to qt6 would be
convenient, changing it to "dh $@ --buildsystem qmake6" is easy enough,
no? The qmake6 build system can reuse qmake just like qmake_qt4 and
doing it that way immediately makes cross compilation just work (since
we already have <triplet>-qmake6). Lisandro requested naming it qmake6
rather than qmake_qt6. Even though this breaks consistency with earlier
use in debhelper, the similarity to how upstream calls it more
important.

Salvo and Alexandre, do you second this?

Can I also get some ack from Qt maintainers such that we can move
forward in consensus?

Helmut

[toc] | [prev] | [next] | [standalone]

#1178157

Hi,

On Mon, 11 Dec 2023 at 12:30, Helmut Grohne <helmut@subdivi.de> wrote:
>
> Hi,
>
> On Mon, Dec 04, 2023 at 10:58:44AM +0100, Salvo Tomaselli wrote:
> > I use this in my rules when using qt6
> >
> >
> > %:
> >         dh $@
> >
> > override_dh_auto_configure:
> >         ln -s /usr/bin/qmake6 ./qmake
> >         PATH=`pwd`:$(PATH) dh_auto_configure
> >
> > override_dh_auto_clean:
> >         $(RM) qmake
> >         dh_auto_clean
>
> This is also being used in src:explosive-c4 now and the approach breaks
> cross compilation. Please stop doing this, we'll have to touch all of
> these.
>
> Still the use case is real and we need a better way to build packages
> with qmake6. I was talking with Sune and Lisandro on IRC and their
> consensus seems to have been that qtchooser and QT_SELECT are dead and
> should not be used for Qt6. They suggested that we add add a new
> --buildsystem to debhelper. We already have qmake_qt4 and qmake, why not
> have qmake6? While changing QT_SELECT from qt5 to qt6 would be
> convenient, changing it to "dh $@ --buildsystem qmake6" is easy enough,
> no? The qmake6 build system can reuse qmake just like qmake_qt4 and
> doing it that way immediately makes cross compilation just work (since
> we already have <triplet>-qmake6). Lisandro requested naming it qmake6
> rather than qmake_qt6. Even though this breaks consistency with earlier
> use in debhelper, the similarity to how upstream calls it more
> important.
>
> Salvo and Alexandre, do you second this?
>
> Can I also get some ack from Qt maintainers such that we can move
> forward in consensus?


+1 from me. qtchooser is no longer supported for Qt >= 6, so going
this way is just awesome.



-- 
Lisandro Damián Nicanor Pérez Meyer
https://perezmeyer.com.ar/

[toc] | [prev] | [next] | [standalone]

#1178159

Hi again,

On Mon, 11 Dec 2023 at 13:20, Lisandro Damián Nicanor Pérez Meyer
<perezmeyer@gmail.com> wrote:
>
[snip]
> > Can I also get some ack from Qt maintainers such that we can move
> > forward in consensus?
>
>
> +1 from me. qtchooser is no longer supported for Qt >= 6, so going
> this way is just awesome.

Also worth to mention: this is something I should have done myself,
but I currently lack the needed time, so Helmut took over. Many thanks
to Helmut for this.


-- 
Lisandro Damián Nicanor Pérez Meyer
https://perezmeyer.com.ar/

[toc] | [prev] | [next] | [standalone]

#1178166

On Monday, December 11, 2023 5:26:14 PM CET Lisandro Damián Nicanor Pérez 
Meyer wrote:

> > +1 from me. qtchooser is no longer supported for Qt >= 6, so going
> > this way is just awesome.
> 
> Also worth to mention: this is something I should have done myself,
> but I currently lack the needed time, so Helmut took over. Many thanks
> to Helmut for this.

Agreed. Both to approach and to thanks to Helmut

/Sune

-- 
I didn’t stop pretending when I became an adult, it’s just that when I was a 
kid I was pretending that I fit into the rules and structures of this world. 
And now that I’m an adult, I pretend that those rules and structures exist.
   - zefrank

[toc] | [prev] | [next] | [standalone]

#1178316

--buildsystem=qmake6 is perfect

Le lun. 11 déc. 2023, 18:32, Sune Stolborg Vuorela <sune@debian.org> a écrit :
> > > +1 from me. qtchooser is no longer supported for Qt >= 6, so going
> > > this way is just awesome.
> >
> > Many thanks
> > to Helmut for this.
>
> Agreed. Both to approach and to thanks to Helmut

Thanks for coming up with this solution

[toc] | [prev] | [next] | [standalone]

#1178588

[Multipart message — attachments visible in raw view] — view raw

> This is also being used in src:explosive-c4 now and the approach breaks
> cross compilation. Please stop doing this, we'll have to touch all of
> these.
> 
> Still the use case is real and we need a better way to build packages
> with qmake6. I was talking with Sune and Lisandro on IRC and their
> consensus seems to have been that qtchooser and QT_SELECT are dead and
> should not be used for Qt6. They suggested that we add add a new
> --buildsystem to debhelper. We already have qmake_qt4 and qmake, why not
> have qmake6? While changing QT_SELECT from qt5 to qt6 would be
> convenient, changing it to "dh $@ --buildsystem qmake6" is easy enough,
> no? The qmake6 build system can reuse qmake just like qmake_qt4 and
> doing it that way immediately makes cross compilation just work (since
> we already have <triplet>-qmake6). Lisandro requested naming it qmake6
> rather than qmake_qt6. Even though this breaks consistency with earlier
> use in debhelper, the similarity to how upstream calls it more
> important.
> 
> Salvo and Alexandre, do you second this?

It would be fine by me, I hope it should be cleaner than how it was to go from 
4 to 5.




-- 
Salvo Tomaselli

"Io non mi sento obbligato a credere che lo stesso Dio che ci ha dotato di
senso, ragione ed intelletto intendesse che noi ne facessimo a meno."
                -- Galileo Galilei

https://ltworf.codeberg.page/

[toc] | [prev] | [next] | [standalone]

#1178916

Hi,

On Wed, 13 Dec 2023 at 15:04, Salvo Tomaselli <tiposchi@tiscali.it> wrote:
>
> > This is also being used in src:explosive-c4 now and the approach breaks
> > cross compilation. Please stop doing this, we'll have to touch all of
> > these.
> >
> > Still the use case is real and we need a better way to build packages
> > with qmake6. I was talking with Sune and Lisandro on IRC and their
> > consensus seems to have been that qtchooser and QT_SELECT are dead and
> > should not be used for Qt6. They suggested that we add add a new
> > --buildsystem to debhelper. We already have qmake_qt4 and qmake, why not
> > have qmake6? While changing QT_SELECT from qt5 to qt6 would be
> > convenient, changing it to "dh $@ --buildsystem qmake6" is easy enough,
> > no? The qmake6 build system can reuse qmake just like qmake_qt4 and
> > doing it that way immediately makes cross compilation just work (since
> > we already have <triplet>-qmake6). Lisandro requested naming it qmake6
> > rather than qmake_qt6. Even though this breaks consistency with earlier
> > use in debhelper, the similarity to how upstream calls it more
> > important.
> >
> > Salvo and Alexandre, do you second this?
>
> It would be fine by me, I hope it should be cleaner than how it was to go from
> 4 to 5.

The cleanest way is to use CMake, as it can handle this directly in
code. And I guess qmake will probably not be a thing for Qt 7.

-- 
Lisandro Damián Nicanor Pérez Meyer
https://perezmeyer.com.ar/

[toc] | [prev] | [next] | [standalone]

#1179092

Le sam. 16 déc. 2023 à 15:46, Lisandro Damián Nicanor Pérez Meyer
<perezmeyer@gmail.com> a écrit :
> The cleanest way is to use CMake, as it can handle this directly in
> code. And I guess qmake will probably not be a thing for Qt 7.
>

Thanks. This just works(TM) for two packages.

[toc] | [prev] | [next] | [standalone]

#1178592

Hej,

Am Montag, 11. Dezember 2023, 16:30:14 CET schrieb Helmut Grohne:
[...]
> Can I also get some ack from Qt maintainers such that we can move
> forward in consensus?
 
+1

And thanks for all the work you put in.


-- 
Med vänliga hälsningar

Patrick Franz

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.bugs.dist

csiph-web