bug#47655: QML2_IMPORT_PATH does not work in a profile

[Maxim Cournoyer]

Hello,

Maxim Cournoyer  writes:

> Hello Guix,
>
> When setting up a profile (via 'guix environment', for example) to
> develop a Qt application, the search paths set by qtbase point to the
> environment profile, which is a forest of symbolic links.  Apparently
> this doesn't play well with at least QML2_IMPORT_PATH: the Qt
> application built in the profile will not run, and Qt crashes in an
> inscrutable way.

This seems to have been resolved using Qt 6.

Closing.

Maxim

bug#56799: (gnu services configuration) usage of *unspecified* is problematic

[Maxim Cournoyer]

Hi,

Tobias Geerinckx-Rice  writes:

> Hi Maxim,
>
> Maxim Cournoyer 写道：
>> For some background reading, see [0].
>
> Thanks for the well-thought-out reply, and sharing this interesting
> link!
>
> Now, it's just the musings of one person, but now I think I do agree
> with (what I think is) the underlying vision: to hush up *unspecified*
> and sneakily replace it with true nothingness.  OK, I can live with
> that.  :-)
>
>> I think the semantic of the language is that it is to be used as the
>> lack of a return value from a procedure or syntax, e.g.:
>>
>> (unspecified? (if #f 'one-arm-if)) -> #t
>
> Well… in the above context I'd hesitate to even imply
> ‘semantics’. It's like undefined behaviour in C.  Ascribe it meaning
> at your peril.  Otherwise, point taken.
>
>> Having 'unspecified?' even defined in Guile seems to go against that
>> idea; perhaps because Wingo themselves seems to disagree in [0].
>
> Agreed.  *This* was one of my reasons for supporting (field
> *unspecified*), so it's nice to have it validated, even if it is
> rejected.
>
>> I'm also thinking 'unspecified being too close to *unspecified* is
>> probably going to cause confusion down the line.  Reverting to the
>> originally used 'disabled may be the lesser evil.
>
> Ah, here I can concentrate all my previous disagreement: hell no :-)
>
> It is the worstest evil; literally anything is better than
> (enable-foo? 'disabled) defaulting to #t.
>
> Bikeshed this all y'all want, but 'default or 'unset or 'whatever are
> miles better.

OK.  The v2 and v3 idea ended up not working, among lesser issues :-).

So I went with v1, renaming the default value to 'unset; see commit
a2b89a3319dc1d621c546855f578acae5baaf6da.  Thanks for the naming
suggestions.

I also added a 'jami-provisioning-partial' system test to ensure it
doesn't regress again if we decide to revisit this.

Thanks,

Closing.

Maxim

bug#56799: (gnu services configuration) usage of *unspecified* is problematic

[Maxim Cournoyer]

Hi Ludo,

Ludovic Courtès  writes:

> Hi!
>
> Maxim Cournoyer  skribis:
>
>> Since commit 8cb1a49a3998c39f315a4199b7d4a121a6d66449, the
>> define-configuration machinery in (gnu services configuration) uses
>> *unspecified* instead of 'disabled for an unspecified field value.
>
> As Attila wrote, the rationale as discussed in
>  was to specifically use a “special”
> value without a read syntax in lieu of a symbol like 'disabled.
>
>> While this is indeed an improvement in readability, it introduces an
>> extra complication: because this new value is not self-quoting, it
>> cannot be used as is in G-Exps, and values using it must be carefully
>> expanded outside the gexp context, which is error prone.
>
> Could you give a simple example of how this can happen?
>
> In my experience, one would use ‘define-maybe’ and appropriate field
> serializers such that *unspecified* never goes through.  Previously
> you’d check for (eq? x 'disabled) and now you just check for
> (unspecified? x).

Yes, I understand that.  What changed is that previously you could have
the configuration serialized and used on the service side, which is what
using *unspecified* made impossible.

Granted, few services outside of Jami probably made use of this, but it
was nevertheless a useful property.

Thanks,

Maxim

bug#56864: qutebrowser: wrap-qt-process-path phase wrong type to string-append

[Maxim Cournoyer]

Hi,

"("  writes:

> This issue affects the following packages as well as qute:
>
>   twinkle, lyx, nheko, quaternion, kcrash, likely many KDE packages
>   (possibly kdenlive, kdevelop, and others), kguiaddons, psi, sonnet.

Proposed fix at:
https://debbugs.gnu.org/cgi/bugreport.cgi?bug=56771#124.  If nobody
objects I'll push it soon.

Thanks,

Maxim

bug#56864: qutebrowser: wrap-qt-process-path phase wrong type to string-append

[paren--- via Bug reports for GNU Guix]

This issue affects the following packages as well as qute:

  twinkle, lyx, nheko, quaternion, kcrash, likely many KDE packages
  (possibly kdenlive, kdevelop, and others), kguiaddons, psi, sonnet.

(Not a complete list, of course.)

-- (

bug#56864: qutebrowser: wrap-qt-process-path phase wrong type to string-append

[paren--- via Bug reports for GNU Guix]

On Mon Aug 1, 2022 at 3:10 PM BST, Lars-Dominik Braun wrote:
> Maybe a different incarnation of the same issue?
The fix is on the package side, so other affected packages won't have
been fixed by that commit.

-- (

bug#56864: qutebrowser: wrap-qt-process-path phase wrong type to string-append

[Lars-Dominik Braun]

Hi Maxim,

> Yep, that did it.
> 
> Fixed in aea756ea3312ba7e8229804492ba12001c8de568.

this does not fix the build of lyx and twinkle for me, which both fail at 
'qt-wrap:

---snip---
starting phase `qt-wrap'
error: in phase 'qt-wrap': uncaught exception:
wrong-type-arg "substring" "Wrong type argument in position ~A (expecting ~A): 
~S" (1 "string" #f) (#f)
phase `qt-wrap' failed after 0.0 seconds
Backtrace:
   9 (primitive-load "/gnu/store/gm47sv2ndfg906vkdr68nbv7zsi…")
In guix/build/gnu-build-system.scm:
906:2  8 (gnu-build #:source _ #:outputs _ #:inputs _ #:phases . #)
In ice-9/boot-9.scm:
  1752:10  7 (with-exception-handler _ _ #:unwind? _ # _)
In srfi/srfi-1.scm:
634:9  6 (for-each # …)
In ice-9/boot-9.scm:
  1752:10  5 (with-exception-handler _ _ #:unwind? _ # _)
In guix/build/gnu-build-system.scm:
   927:23  4 (_)
In guix/build/qt-utils.scm:
   148:22  3 (wrap-all-qt-programs #:inputs _ #:outputs _ #:qtbase _ …)
In unknown file:
   2 (string-drop #f 44)
In ice-9/boot-9.scm:
  1685:16  1 (raise-exception _ #:continuable? _)
  1685:16  0 (raise-exception _ #:continuable? _)

ice-9/boot-9.scm:1685:16: In procedure raise-exception:
In procedure substring: Wrong type argument in position 1 (expecting string): #f
---snap---

Maybe a different incarnation of the same issue?

Lars

bug#56799: (gnu services configuration) usage of *unspecified* is problematic

[Ludovic Courtès]

Hi!

Maxim Cournoyer  skribis:

> Since commit 8cb1a49a3998c39f315a4199b7d4a121a6d66449, the
> define-configuration machinery in (gnu services configuration) uses
> *unspecified* instead of 'disabled for an unspecified field value.

As Attila wrote, the rationale as discussed in
 was to specifically use a “special”
value without a read syntax in lieu of a symbol like 'disabled.

> While this is indeed an improvement in readability, it introduces an
> extra complication: because this new value is not self-quoting, it
> cannot be used as is in G-Exps, and values using it must be carefully
> expanded outside the gexp context, which is error prone.

Could you give a simple example of how this can happen?

In my experience, one would use ‘define-maybe’ and appropriate field
serializers such that *unspecified* never goes through.  Previously
you’d check for (eq? x 'disabled) and now you just check for
(unspecified? x).

Thanks,
Ludo’.

bug#56519: Shepherd non-deterministically fails to load the "guix-daemon" service after the "user-processes" service has been started

[Ludovic Courtès]

Hi Markus,

Markus Nilsson  skribis:

> I checked other services that depend on "user-processes" (see the attached
> shepherd dependency graph for my system). The "mcron" service and "ntpd"
> successfully start (lines 20 and 23). This still leaves the mystery of why
> "guix-daemon" and "nscd" won't start even though "user-processes" HAS been
> started.

Could you check what /var/log/messages says for this specific
occurrence?

It will shed some light as to what services were started, in what order,
how they failed, etc.

Thanks,
Ludo’.

bug#56799: (gnu services configuration) usage of *unspecified* is problematic

[Ludovic Courtès]

Hi!

Maxim Cournoyer  skribis:

> Fixes .
>
> * guix/gexp.scm (gexp->sexp)[*unspecified*]: Quote value when encountering it.

I think we need to take a step back.  Overall, I’m reluctant to
modifying a core primitive like ‘gexp->sexp’ “just” to address this
higher-level problem that we have.

> +(($  (? unspecified?))
> + (return '*unspecified*))

Incidentally, this is “unhygienic”, meaning that it relies on
‘*unspecified*’ being bound to what we want.  For example, if I do this:

  #~(let ((*unspecified* 'hi!))
  #$*unspecified*)

… I won’t get the desired output.

Ludo’, who now goes back to the beginning of the thread.  :-)

bug#56864: qutebrowser: wrap-qt-process-path phase wrong type to string-append

[Maxim Cournoyer]

Hi,

Maxim Cournoyer  writes:

> Hello Jack,
>
> Jack Hill  writes:
>
>> X-Debbugs-CC: maxim.courno...@gmail.com
>>
>> With Guix 3a656ea836f87f30f1b34852cb4efc911363d2b4, qutebrowser's
>> wrap-qt-process-path phase fails. Maybe related to the recent Qt work
>> in ? Build log attatched.
>
> Uh, this was unexpected.  I believe it's because label-less inputs are
> auto-generated via the package *name* rather than their variable name...
> Since qtwebengine-5 (the variable) still has the name "qtwebengine", the
> following code:
>
> (qt-process-path (string-append (assoc-ref inputs "qtwebengine-5")
>   "/lib/qt5/libexec/QtWebEngineProcess"))
>
> Doesn't actually find "qtwebengine-5" and it fails attempting to append
> #f to "/lib/qt5/libexec/QtWebEngineProcess.  The solution that comes to
> mind would be using:
>
> (file-input-search inputs "lib/qt5/libexec/QtWebEngineProcess").

Yep, that did it.

Fixed in aea756ea3312ba7e8229804492ba12001c8de568.

Closing.

Thanks for the report!

Maxim

bug#56864: qutebrowser

[Maxim Cournoyer]

Hello Jack,

Jack Hill  writes:

> X-Debbugs-CC: maxim.courno...@gmail.com
>
> With Guix 3a656ea836f87f30f1b34852cb4efc911363d2b4, qutebrowser's
> wrap-qt-process-path phase fails. Maybe related to the recent Qt work
> in ? Build log attatched.

Uh, this was unexpected.  I believe it's because label-less inputs are
auto-generated via the package *name* rather than their variable name...
Since qtwebengine-5 (the variable) still has the name "qtwebengine", the
following code:

--8<---cut here---start->8---
(qt-process-path (string-append (assoc-ref inputs "qtwebengine-5")
  "/lib/qt5/libexec/QtWebEngineProcess"))
--8<---cut here---end--->8---

Doesn't actually find "qtwebengine-5" and it fails attempting to append
#f to "/lib/qt5/libexec/QtWebEngineProcess.  The solution that comes to
mind would be using:

(file-input-search inputs "lib/qt5/libexec/QtWebEngineProcess").

Thanks,

Maxim

bug#56799: (gnu services configuration) usage of *unspecified* is problematic

[Maxim Cournoyer]

Hi,

Maxime Devos  writes:

> On 01-08-2022 07:08, Maxim Cournoyer wrote:
>> (quote
>>  
>> ("/gnu/store/14flr53fr0hs7mzfwn93kmyzrnb3fhjz-dummy-jami-account.gz"))
>> (quote
>>  (*unspecified*))
>> (quote
>>  (*unspecified*))
>
> These lines look suspicious to me -- should they have done (list
> *unspecified*) instead of '(*unspecified*)?
>
> The former uses the actual unspecified object, the latter uses the
> symbol '*unspecified*' that merely happens to be the name of a
> variable the unspecified object is bound to.

Indeed; '*unspecified ain't the same as *unspecified, and it isn't
magically evaluated after being lowered in a G-exp:

--8<---cut here---start->8---
(map unspecified?
 (quote (*unspecified* *unspecified* *unspecified*
 *unspecified* *unspecified*)))
$1 = (#f #f #f #f #f) 
--8<---cut here---end--->8---

So in essence the idea to simply quote *unspecified* from patch v3 is
flawed.

v1 works though (using a symbol), so unless someone has a better idea
right now I'm thinking that using 'unset instead of *unspecified* may be
the simplest working solution.

Thanks,

Maxim

bug#56799: (gnu services configuration) usage of *unspecified* is problematic

[Maxime Devos]

On 01-08-2022 07:08, Maxim Cournoyer wrote:

(quote
 ("/gnu/store/14flr53fr0hs7mzfwn93kmyzrnb3fhjz-dummy-jami-account.gz"))
(quote
 (*unspecified*))
(quote
 (*unspecified*))


These lines look suspicious to me -- should they have done (list 
*unspecified*) instead of '(*unspecified*)?


The former uses the actual unspecified object, the latter uses the 
symbol '*unspecified*' that merely happens to be the name of a variable 
the unspecified object is bound to.


Greetings,
Maxime.



OpenPGP_0x49E3EE22191725EE.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

bug#56866: [Shepherd] inetd connections not correctly counted?

[Ludovic Courtès]

Hi,

We recently experienced a bug on berlin.guix where we’d be locked out of
SSH access because shepherd (0.9.1) would say that the maximum
connection number on the sshd inetd service had been reached.

That threshold is a feature (see ‘max-connections’ in
) but there’s a possibility in this case that a
bug in ‘make-inetd-constructor’ or thereabout led it to get a wrong idea
of the number of active connections.  Unfortunately, we lack syslogs
that would give us info about the time where inetd connections started
accumulating¹.

I tried to come up with a scenario that could lead to that problem with
the test below, to no avail.  If you’ve experienced something similar,
or if you noticed that ‘sshd-*’ services have accumulated on a server of
yours, please let us know!

Thanks,
Ludo’.

¹ That, in turn, was a bug in the rottlog default config, fixed in
  e5a6900baf758a12024283171bf45f2fe90121ee.

diff --git a/tests/inetd.sh b/tests/inetd.sh
index 0301b68..894ce98 100644
--- a/tests/inetd.sh
+++ b/tests/inetd.sh
@@ -77,6 +77,15 @@ cat > "$conf" <
+   #:provides '(test-inetd-fail)
+   #:start (make-inetd-constructor '("$(type -P false)")
+   (list
+(endpoint (make-socket-address
+   AF_INET
+   INADDR_LOOPBACK
+   $PORT
#:stop  (make-inetd-destructor)))
 
 (start 'test-inetd)
@@ -95,6 +104,11 @@ file_descriptor_count ()
 ls -l /proc/$shepherd_pid/fd/[0-9]* | wc -l
 }
 
+# Trigger startup of the finalizer thread, which creates a couple of pipes.
+# That way, those extra file descriptors won't influence the comparison with
+# INITIAL_FD_COUNT done at the end.
+$herd eval root '(gc)'
+
 initial_fd_count=$(file_descriptor_count)
 
 $herd status test-inetd | grep started
@@ -203,3 +217,16 @@ $herd status
 # At this point, shepherd should have INITIAL_FD_COUNT - 1 file descriptors
 # opened.
 test $(file_descriptor_count) -lt $initial_fd_count
+
+# Now test a service that fails as soon as it's passed an incoming connection.
+$herd start test-inetd-fail
+for i in $(seq 1 10)
+do
+$herd status
+test $($herd status | grep '\+' | wc -l) -eq 2
+! converse_with_echo_server \
+	"(make-socket-address AF_INET INADDR_LOOPBACK $PORT)"
+done
+
+$herd stop test-inetd-unix
+test $(file_descriptor_count) -lt $initial_fd_count