unofficial mirror of guix-patches@gnu.org 
 help / color / mirror / code / Atom feed
From: Marius Bakke <mbakke@fastmail.com>
To: "Jakub Kądziołka" <kuba@kadziolka.net>,
	39102-done@debbugs.gnu.org, efraim@flashner.co.il
Subject: bug#39102: [PATCH v2 2/2 staging] gnu: qtbase: Open links properly without xdg-utils in profile
Date: Mon, 13 Jan 2020 22:43:01 +0100	[thread overview]
Message-ID: <87ftgjvxqy.fsf@devup.no> (raw)
In-Reply-To: <20200113113945.xrozaipgq65yxwbz@zdrowyportier.kadziolka.net>

[-- Attachment #1: Type: text/plain, Size: 3174 bytes --]

Jakub Kądziołka <kuba@kadziolka.net> writes:

> * gnu/packages/qt.scm (qtbase)[inputs]: Add XDG-UTILS.
>   [arguments](patch-xdg-open): New phase.
> ---
>
> On Sun, Jan 12, 2020 at 08:44:43PM +0100, Marius Bakke wrote:
>> Jakub Kądziołka <kuba@kadziolka.net> writes:
>> 
>> > * gnu/packages/patches/qtbase-use-xdg-open-in-store.patch: New file.
>> > * gnu/packages/qt.scm (qtbase)[source][patches]: Apply the patch.
>> >   [inputs]: Add a dependency on xdg-utils to get its store path.
>> >   [arguments]: Add a new phase to patch the path into the source code.
>> 
>> This patch does a lot.  :-)
>
> Yeah, for some reason I thought a patch like this might as well not
> leave any dead code behind.
>
>> With this patch, BROWSER and DEFAULT_BROWSER would no longer be
>> consulted, right?
>
> BROWSER is checked by xdg-open anyway. DEFAULT_BROWSER would indeed be
> no longer consulted.
>
>> Does checkExecutable work with absolute file names?  I.e. could we get
>> away by simply patching "xdg-open" with its store file name?
>
> That's what I considered doing at first, but when I drilled a few
> methods into the code, I decided that it's very unlikely to work and I
> don't want to check it empirically due to the painfully long
> compile-times.
>
>> Probably should change the default browsers while at it, though.  :-)
>
> I don't think there's much point, as that code becomes dead when
> xdg-open is always found.

Right, thanks for clarifying.

>> Wrt the easy substitution, I think we should try and avoid introducing
>> changes to source code that depend on magic from #:phases.  That way
>> people will still be (mostly) able to build Qt manually using the Guix
>> source.  In this case, maybe defaulting to just "xdg-open" is enough?
>
> Perhaps applying the patch in a phase instead of (source _) would help?
>
>> In short, I'm looking for an easier way to achieve the same goal,
>> without the rather intrusive patch.
>
> See PATCHv2, which uses a much more minimal approach, but leaves some
> dead stuff that isn't likely to be optimized by the compiler. Caring
> about this might not be rational, now that I think about it...

Heh.  Considering possible side effects is good, even if the effects are
not very worrying.  :-)

> On Mon, Jan 13, 2020 at 09:53:12AM +0200, Efraim Flashner wrote:
> | Looking at the patch, I'm not in love with how there's a default list of
> | browsers to look for. Looking at the code, it seems that if there's
> | xdg-open available then open browser from the pre-defined list.
>
> You seem to be misreading the code. If xdg-open is available, it is
> used, the browser list is only used when xdg-open isn't found.
>
> | I think our best bet would be to [...] change the list of *browsers[] to
> | ones we actually have in Guix.
>
> As mentioned above, the list would never be read, since xdg-open would
> always be found.

OK.  The new patch is much less intimidating, I will apply it shortly.

(by the way, please attach full patches instead of plain diffs, so we
can 'git am' straight from our MUA instead of having to mangle it)

Thank you!

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]

  reply	other threads:[~2020-01-13 21:44 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-01-12 15:43 [bug#39102] [PATCH 1/2] gnu: xdg-utils: Don't use propagated inputs Jakub Kądziołka
2020-01-12 15:47 ` [bug#39102] [PATCH 2/2 staging] gnu: qtbase: Open links properly without xdg-utils in profile Jakub Kądziołka
2020-01-12 19:44   ` Marius Bakke
2020-01-13  7:53     ` Efraim Flashner
2020-01-12 17:03 ` [bug#39102] [PATCH v2 1/2] gnu: xdg-utils: Don't use propagated inputs Jakub Kądziołka
2020-01-12 19:29   ` Marius Bakke
2020-01-13 11:39 ` [bug#39102] [PATCH v2 2/2 staging] gnu: qtbase: Open links properly without xdg-utils in profile Jakub Kądziołka
2020-01-13 21:43   ` Marius Bakke [this message]
     [not found]     ` <20200113215130.3afsnbsq2efiovhy@zdrowyportier.kadziolka.net>
2020-01-13 22:31       ` Marius Bakke

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://guix.gnu.org/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87ftgjvxqy.fsf@devup.no \
    --to=mbakke@fastmail.com \
    --cc=39102-done@debbugs.gnu.org \
    --cc=efraim@flashner.co.il \
    --cc=kuba@kadziolka.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/guix.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).