Le 28/09/2015 22:12, Maxime Gauduin a écrit :

On Mon, Sep 28, 2015 at 6:20 PM, Benjamin Robin <dev@benjarobin.fr> wrote:

...

Hello Giovanni Scafora,

I am trying to contact you about the bug reports opened about the mkvtoolnix package. Please see the email below posted on the mailing list.

Thank you, Benjamin

...

...

Hi,

We do have trouble with some bug reports [1], [2] and [3]. The maintainer (Giovanni Scafora) does not answer, nor update the PKGBUILD. In the last bug report [3] we kindly offer a working example of PKGBUILD which fix the problem : bring back the GUI (Qt5 instead of Gtk) The first bug report [1] is more than 4 years old without any respond...

What do we need to do to resolve this issue ?

[1] https://bugs.archlinux.org/task/24532 [2] https://bugs.archlinux.org/task/44948 [3] https://bugs.archlinux.org/task/45439

...

Antonio Rojas wrote: Have you tried directly emailing the maintainer? Hi all,

@Giovanni: being a somewhat heavy user of mkvtoolnix myself I'd like to co-maintain mkvtoolnix with you. I rewrote most of the PKGBUILD, here are the changes I'd iike to push [1], I chose to name the Qt-enabled mkvinfo binary mkvinfo-gui to mirror how the main GUI is named. Also, as Moritz Bunkus pointed out, it appears all current workarounds can be removed. Please let me know what you think.

@Benjamin: Feel free to give the diff a spin before we push it, it's working fine here, the only gripe I have with the new GUI is that the left toolbar is completely black, but that may just be because my desktop is powered by GNOME.

[1] https://paste.xinu.at/oX2o/

Cheers, -- Maxime

Tested here, build fine (although I was surprised by the amount of time required), but the left toolbar background is also completely black here under KDE/Plasma 5. Bruno

On Tue, Sep 29, 2015 at 12:01 AM, Benjamin Robin <dev@benjarobin.fr> wrote:

There is a problem with your PKGBUILD. The build performances set aside. The PKGBUILD [1] provided in the bug report is built much faster.

There's no difference here, and there shouldn't be anyway, drake can be multithreaded make-style with the -j flag or by setting the env variable like it's currently done. Make-style happens to look neater, and the number of threads is configured by the user instead of being hardcoded in the PKGBUILD.

You try to be able to install mkvtoolnix-qt alone without the mkvtoolnix-cli package, right ?

Hmm, no?

Well this cannot work since mkvtoolnix-qt needs the locale/translation.

You don't say. Read the depends array once more.

And since mkvtoolnix-cli *must* be a dependency of mkvtoolnix-qt, there is no point to have the manual mkvinfo-gui.1 which is identical to mkvinfo.1. You can if you want create a symbolic link.

Indeed, in that case I'd rather get rid of the duplicates. If it were up to me, I wouldn't even package the Qt-enabled mkvinfo, the GUI doesn't bring anyhting more compared to the CLI tool, and if people need a GUI, I would highly recommend MediaInfo instead.

[1] http://pastebin.com/rtguGrbR

...

@Benjamin: Feel free to give the diff a spin before we push it, it's working fine here, the only gripe I have with the new GUI is that the left toolbar is completely black, but that may just be because my desktop is powered by GNOME.

-- Maxime

On Tue, Sep 29, 2015, 9:52 PM Benjamin Robin <dev@benjarobin.fr> wrote:

There's no difference here, and there shouldn't be anyway

In the PKGBUILD the first "drake" doesn't build everything: ./drake apps:mkvinfo != ./drake

...

You try to be able to install mkvtoolnix-qt alone without the mkvtoolnix-cli package, right ?

Hmm, no? You don't say. Read the depends array once more.

Oops, sorry, I should have read the PKGBUILD more than once.

Indeed, in that case I'd rather get rid of the duplicates. If it were up to me, I wouldn't even package the Qt-enabled mkvinfo, the GUI doesn't bring anyhting more compared to the CLI tool, and if people need a GUI, I would highly recommend MediaInfo instead.

I cannot say that I am not agree :-) Benjamin Oh, I thought you were talking about the multithreading. I guess that trick can be used to do things the other way around and build only mkvtoolnix-gui in the second build folder. I'll have a look tomorrow and remove mkvinfo-gui, I guess most people will agree that it's unnecessary to package it. Cheers, -- Maxime

…and I screwed up the subject. Sorry for that; I wasn't subscribed and tried to stitch the reply to the thread properly. And I've failed, obviously :( Kind regards, mosu

On Wed, Sep 30, 2015 at 9:26 AM, Moritz Bunkus <moritz@bunkus.org> wrote:

Hey,

the MKVToolNix author here. First of all I appreciate all the effort of packaging MKVToolNix for Arch. Thanks for that.

The orignal PKGBUILD in the repositories builds the whole of MKVToolNix twice, once configured with GUI support, once configured without it. However, this is not really necessary.

Being configured with and without GUI support only affects two programs: mkvinfo and mkvtoolnix-gui. If configured with GUI support then mkvinfo will be built including a Qt-based GUI in addition to the always-included text mode interface, and mkvtoolnix-gui will be built in the first place. If configured without GUI support then mkvinfo will only include that text mode interface and mkvtoolnix-gui will not be built at all.

Therefore the PKGBUILD in the pastebin cuts down on compilation time by only compiling the whole of MKVToolNix once when it's configured with GUI support. For the text-mode only version of mkvinfo you only have to configure MKVToolNix and build mkvinfo (and then preserve that binary over the »drake clean«, of course); nothing else has to be built. Hence the pastebin'ed PKGBUILD being a lot faster.

There's only one version of mkvinfo's man page in my upstream MKVToolNix source, and the installed version is identical in both cases (configured with/without GUI). Therefore including it in each Arch package is indeed wasting space.

The mkvtoolnix-gui (and therefore the Arch mkvtoolnix-qt package) cannot work without the mkvmerge executable as the GUI uses the CLI-only mkvmerge for all of its actual work. Therefore the mkvtoolnix-qt package must depend on the mkvtoolnix package, and preferably of the same version: I only guarantee that mkvtoolnix-gui version a.b.c will work with mkvmerge version a.b.c, nothing else. The GUI will even emit warnings if the mkvmerge executable's version differs. Therefore upgrading the mkvtoolnix-qt package without upgrading the mkvtoolnix package should ideally not be possible.

If you don't want to include mkvinfo's Qt GUI then you still have to do both builds. Well, you could leave out mkvinfo during the with-GUI- configured build, but that wouldn't cut down on compilation time a lot as mkvinfo only consists of three source files on top of the common library.

I don't particularly care whether or not mkvinfo's GUI is included in the mkvtoolnix-qt package. I've created it mostly for Windows users as those are pretty resilient to the advice of using the command line version ;) On the other hand I can really understand them when I think of cmd.exe…

Kind regards, mosu

Hi Moritz, Thanks for the explanation. I keep thinking that we don't need the mkvinfo GUI. I tried to use apps:mkvtoolnix-gui to build only that one the second time around. While it works in build(), invoking drake install in install() seems to ignore the argument and goes on to build everything else before installing. Is that expected behavior or am I doing something wrong? Either way, my CPU has seen worse, building the whole thing twice isn't that big of a deal. Cheers, -- Maxime