bug#39051: nginx caching headers are broken due to epoch store timestamps
I’ve been having hard-to-debug caching issues serving up static files with nginx. It turns out this is due to nginx computing e-tag headers from file timestamps, which are all epoch in the guix store. I’ve fixed this on my server by applying a patch from Nix: https://github.com/robx/guix/commit/4b406f5bc608b3c0e18e15795d8fe61d3477a3e2
bug#39051: nginx caching headers are broken due to epoch store timestamps
Hello, Robert Vollmert ezt írta (időpont: 2020. jan. 9., Cs, 11:54): > > I’ve been having hard-to-debug caching issues serving up static files > with nginx. It turns out this is due to nginx computing e-tag headers > from file timestamps, which are all epoch in the guix store. > > I’ve fixed this on my server by applying a patch from Nix: > https://github.com/robx/guix/commit/4b406f5bc608b3c0e18e15795d8fe61d3477a3e2 this is a known issue. Could you look around the tracker and merge? > > > > Also, on the long run it would be nice to contribute a working etags computation to nginx, that is based on the file content hash, or something like that. Does that make sense? Best regards, g_bor -- OpenPGP Key Fingerprint: 7988:3B9F:7D6A:4DBF:3719:0367:2506:A96C:CF63:0B21
bug#38940: \x1b]8; ; OSC character displayed on hyperlinks shown after calls to `guix describe` or `guix show` on mate-terminal 1.12.1 (Trisquel 8)
Hi Calvin. On Wed, 8 Jan 2020 at 23:54, Calvin Heim wrote: > This bug will be resolved eventually by Trisquel following the upstream > sources in > Ubuntu, so barring objections I will close this issue. Please close by sending an email to 38940-d...@debbugs.gnu.org with some explanations when you judge it is resolved; even if it is *not* a bug of Guix but a _bug of Trisquel_. ;-) All the best, simon
bug#39051: nginx caching headers are broken due to epoch store timestamps
I don’t see anything here: https://debbugs.gnu.org/cgi/pkgreport.cgi?package=guix;include=subject%3Anginx > On 9. Jan 2020, at 12:00, Gábor Boskovits wrote: > > Hello, > > Robert Vollmert ezt írta (időpont: 2020. jan. 9., Cs, > 11:54): >> >> I’ve been having hard-to-debug caching issues serving up static files >> with nginx. It turns out this is due to nginx computing e-tag headers >> from file timestamps, which are all epoch in the guix store. >> >> I’ve fixed this on my server by applying a patch from Nix: >> https://github.com/robx/guix/commit/4b406f5bc608b3c0e18e15795d8fe61d3477a3e2 > > this is a known issue. Could you look around the tracker and merge? >> >> >> >> > > Also, on the long run it would be nice to contribute a working etags > computation to nginx, that > is based on the file content hash, or something like that. Does that make > sense? > > Best regards, > g_bor > -- > OpenPGP Key Fingerprint: 7988:3B9F:7D6A:4DBF:3719:0367:2506:A96C:CF63:0B21
bug#38940: \x1b]8; ; OSC character displayed on hyperlinks shown after calls to `guix describe` or `guix show` on mate-terminal 1.12.1 (Trisquel 8)
Hi Ludo, On Wed, 8 Jan 2020 at 22:28, Ludovic Courtès wrote: > The theory is that terminals should ignore OSC codes that they do not > support. Good’ol xterm, for instance, silently ignores those hyperlink > codes, whereas GNOME Terminal interprets them nicely. Héhé! It is what the comment you wrote in `supports-hyperlinks?' says. :-) 1. Instead of INSIDE_EMACS, the variable name NO_SUPPORT_HYPERLINK or other seems more meaningful. Maybe? 2. The comment should go in the docstring. What do you think? All the best, simon
bug#38829: XmlListModel QML missing from qtdeclarative 5.12.x
Guillaume Le Vaillant skribis:
> Guillaume Le Vaillant skribis:
>
>> In version 5.12.6 of the 'qtdeclarative' package, the
>> 'lib/qt5/qml/QtQuick/XmlListModel' directory is missing (qtdeclarative
>> 5.11.3 had it).
>>
>> It causes run time issues; for example the 'monero-gui'
>> package builds fine but it fails to run:
>>
>> --8<---cut here---start->8---
>> 2019-12-31 12:50:42.076 W app startd (log:
>> /home/guillaume/.bitmonero/monero-wallet-gui.log)
>> 2019-12-31 12:50:42.077 W Qt:5.12.6 GUI:- | screen: 1920x1080 - dpi:
>> 96.1263 - ratio:0.997092
>> 2019-12-31 12:50:42.179 W QQmlApplicationEngine failed to load component
>> 2019-12-31 12:50:42.179 W qrc:/main.qml:1693 Type WizardLang unavailable
>> 2019-12-31 12:50:42.179 W qrc:/wizard/WizardLang.qml:32 module
>> "QtQuick.XmlListModel" is not installed
>> 2019-12-31 12:50:42.179 E Error: no root objects
>> --8<---cut here---end--->8---
>
> I was able to build the QML for 'XmlListModel' by making 'qtdeclarative'
> a dependency of 'qtxmlpatterns' instead of the opposite (and the QML is in
> the 'qtxmlpatterns' package).
>
> Rebuilding the required Qt packages and 'monero-gui' and running it
> worked fine. However I'm not too familiar with the Qt packages, so does
> someone think this approach could cause problems in some of them?
>
>
> Here's the patch I used:
>
> --8<---cut here---start->8---
> From 2f0befe2e183d65a731e616b7b55808d27d8af8e Mon Sep 17 00:00:00 2001
> From: Guillaume Le Vaillant
> Date: Sun, 5 Jan 2020 19:27:17 +0100
> Subject: [PATCH] gnu: qtxmlpatterns: Build QML plugin for XmlListModel.
>
> * gnu/packages/qt.scm (qtdeclarative)[native-inputs]: Remove qtxmlpatterns.
> (qtxmlpatterns)[native-inputs]: Add qtdeclarative.
> ---
> gnu/packages/qt.scm | 7 ---
> 1 file changed, 4 insertions(+), 3 deletions(-)
>
> diff --git a/gnu/packages/qt.scm b/gnu/packages/qt.scm
> index 795b5e9d2b..daa35c77cb 100644
> --- a/gnu/packages/qt.scm
> +++ b/gnu/packages/qt.scm
> @@ -723,6 +723,7 @@ from within Qt 5.")))
> "1l44476ibb8rv4rf80vbjdc3712lmrl1xcxswa513ip66k47p5vn"
> (arguments
> (substitute-keyword-arguments (package-arguments qtsvg)
> + ((#:tests? _ #f) #f) ; TODO: Enable the tests
> ((#:phases phases)
> `(modify-phases ,phases
> (add-after 'unpack 'disable-network-tests
> @@ -730,7 +731,8 @@ from within Qt 5.")))
> (("qxmlquery") "# qxmlquery")
> (("xmlpatterns ") "# xmlpatterns"))
> #t))
> -(native-inputs `(("perl" ,perl)))
> +(native-inputs `(("perl" ,perl)
> + ("qtdeclarative" ,qtdeclarative)))
> (inputs `(("qtbase" ,qtbase)))
> (synopsis "Qt XML patterns module")
> (description "The QtXmlPatterns module is a XQuery and XPath engine for
> @@ -758,8 +760,7 @@ xmlpatternsvalidator.")))
> ("pkg-config" ,pkg-config)
> ("python" ,python)
> ("python-wrapper" ,python-wrapper)
> - ("qtsvg" ,qtsvg)
> - ("qtxmlpatterns" ,qtxmlpatterns)))
> + ("qtsvg" ,qtsvg)))
> (inputs
> `(("mesa" ,mesa)
> ("qtbase" ,qtbase)))
I built some other packages depending on 'qtdeclarative' and/or
'qtxmlpatterns' and I haven't seen any failure, so I pushed the patch as
3e10b2418dc0952c16053ccced4baba405facb6b.
signature.asc
Description: PGP signature
bug#38172: WebkitGTK-based browsers: System volume suddenly maxed out when playing audio or video
Leo,
Leo Prikler writes:
> Hi Guix,
>
> After looking at my older patch (which no longer cleanly applies), I've
> noticed, that pulseaudio doesn't even read the files from /etc. This
> is troublesome in multiple ways. For one, pulseaudio causes >500
> rebuilds (with >900 dependent packages) and is therefore staging
> material, for the other, hardcoding /etc in such a way breaks
> pulseaudio without the service.
>
> So far, I've only tested containers via `guix environment --container`,
> but from what I can gather with strace, the config file is indeed read
> and hence flat-volumes are eliminated. Other ways of making pulseaudio
> accept /etc are very welcome. Looking at Nix, they configure
> pulseaudio with "--sysconfdir=/etc", but then override sysconfdir and
> pulseconfdir during install. I'm not quite sure which solution is
> "better", but neither is going to read the config shipped with the
> package.
>
> Note: before this can be applied on staging,
> a66ee82a05d8ff1ef7c5ff9ac7723cb32fc4e22a needs to be applied.
Thank you for these patches. Overall it LGTM.
[...]
> From bf4708923d14356c87daec69209b30aa0427d64f Mon Sep 17 00:00:00 2001
> From: Leo Prikler
> Date: Wed, 8 Jan 2020 19:50:51 +0100
> Subject: [PATCH 1/3] services: Add pulseaudio-configuration.
>
> * gnu/services/sound (): New record.
> (pulseaudio-etc): New procedure.
> (pulseaudio-service-type): Update accordingly.
[...]
> +(define-record-type*
> + pulseaudio-configuration make-pulseaudio-configuration
> + pulseaudio-configuration?
> + (package pulseaudio-package (default pulseaudio))
> + (client-conf pulseaudio-client-conf (default '()))
> + (daemon-conf pulseaudio-daemon-conf (default '((flat-volumes no
I have a preference for making this field empty initially to have a 1:1
compatibility with the current PA client and daemon configuration
(i.e. nothing). Then a follow-up patch can add this new configuration,
perhaps with an explaining comment.
> + (default-script pulseaudio-default-script (default #f))
> + (system-script pulseaudio-system-script (default #f)))
> +
> (define (pulseaudio-environment config)
>;; Define this variable in the global environment such that
>;; pulseaudio swh-plugins works.
>`(("LADSPA_PATH"
> . ,(file-append swh-plugins "/lib/ladspa"
>
> +(define (pulseaudio-conf-entry arg)
> + (match arg
> +((key value)
> + (format #f "~a = ~s~%" key value))
> +((? string? _)
> + (string-append arg "\n"
> +
> +(define pulseaudio-etc
> + (match-lambda
> +(($ package client-conf daemon-conf
> + default-script system-script)
> + (let ((default.pa (if default-script
> + (apply mixed-text-file "default.pa"
> + default-script)
> + (file-append package "/etc/pulse/default.pa"
> + `(("pulse"
> + ,(file-union
> +"pulse"
> +`(("client.conf"
> + ,(apply mixed-text-file "client.conf"
> + (map pulseaudio-conf-entry client-conf)))
> + ("daemon.conf"
> + ,(apply mixed-text-file "daemon.conf"
> + "default-script-file = " default.pa "\n"
> + (map pulseaudio-conf-entry daemon-conf)))
> + ("default.pa" ,default.pa)
> + ("system.pa"
> + ,(if system-script
> +(apply mixed-text-file "system.pa"
> + system-script)
> +(file-append package "/etc/pulse/system.pa")))
> +
Does it make sense to have default-script and system-script default to
(file-append pulseaudio "...") and avoid the conditional altogether?
[...]
> From 843d3968db990b5b7ff3f618db5847f83b999cb8 Mon Sep 17 00:00:00 2001
> From: Leo Prikler
> Date: Thu, 9 Jan 2020 01:24:09 +0100
> Subject: [PATCH 2/3] gnu: pulseaudio: Honor /etc.
>
> * gnu/packages/pulseaudio.scm (pulseaudio) [phases]:
> Set PA_DEFAULT_CONFIG_DIR to "/etc/pulse".
This means pulseaudio will start looking in /etc/pulse for configuration
files on foreign distributions too, right?
I wonder if there is better way to give it configuration files. Perhaps
by patching the D-Bus service files? Not a blocker for this series, but
something to consider in case /etc/pulse causes trouble.
[...]
> + (add-after 'configure 'hardcode-default-config-dir
> + (lambda _
> + (substitute* "config.h"
> + (("(#define PA_DEFAULT_CONFIG_DIR).*$" all prefix)
> +(string-append prefix " \"/etc/pulse\"")
End on #t.
[...]
> From e24016f9a44a113847dd937ac47ab4bdb960236d Mon Sep 17 00:00:00 2001
> From: Leo Prikler
> Date: Thu, 9 Jan 2020 01:29:13 +0100
> Subject: [PATCH 3/3] services: Add pulseaudio to %desktop-services.
>
> * gnu/services/desktop.scm (%desktop-services): Add puls
bug#38940: \x1b]8; ; OSC character displayed on hyperlinks shown after calls to `guix describe` or `guix show` on mate-terminal 1.12.1 (Trisquel 8)
Hi! zimoun skribis: > On Wed, 8 Jan 2020 at 22:28, Ludovic Courtès wrote: > >> The theory is that terminals should ignore OSC codes that they do not >> support. Good’ol xterm, for instance, silently ignores those hyperlink >> codes, whereas GNOME Terminal interprets them nicely. > > Héhé! It is what the comment you wrote in `supports-hyperlinks?' says. :-) > > 1. Instead of INSIDE_EMACS, the variable name NO_SUPPORT_HYPERLINK or > other seems more meaningful. Maybe? Actually the goal was to remove ‘INSIDE_EMACS’ from there once a widespread-enough Emacs version supports it, which could be within a year. And since other terminals are supposed to ignore it altogether, I would rather not add a special environment variable. WDYT? > 2. The comment should go in the docstring. I tend to write “implementation details” as comments, while keeping pure descriptions of the interface as docstrings; I think it’s OK. :-) Ludo’.
bug#38940: \x1b]8; ; OSC character displayed on hyperlinks shown after calls to `guix describe` or `guix show` on mate-terminal 1.12.1 (Trisquel 8)
Hi Calvin, Calvin Heim skribis: > Yes, the bug is in libvte 0.28.2 as distributed with Trisquel 8's software > updater. > I misspoke earlier when I mentioned mate-terminal. > > This bug will be resolved eventually by Trisquel following the upstream > sources in > Ubuntu, so barring objections I will close this issue. Sure, closing! Thanks, Ludo’.
bug#38940: \x1b]8; ; OSC character displayed on hyperlinks shown after calls to `guix describe` or `guix show` on mate-terminal 1.12.1 (Trisquel 8)
Hi Ludo, On Thu, 9 Jan 2020 at 22:23, Ludovic Courtès wrote: > > 1. Instead of INSIDE_EMACS, the variable name NO_SUPPORT_HYPERLINK or > > other seems more meaningful. Maybe? > > Actually the goal was to remove ‘INSIDE_EMACS’ from there once a > widespread-enough Emacs version supports it, which could be within a > year. And since other terminals are supposed to ignore it altogether, I > would rather not add a special environment variable. Sound reasonable. :-) > > 2. The comment should go in the docstring. > > I tend to write “implementation details” as comments, while keeping pure > descriptions of the interface as docstrings; I think it’s OK. :-) I fully trust your experience. ;-) Cheers, simon
bug#39043: Channels error is too vague
Hi, Jesse Gibbons skribis: > When I create a channel and leave out %default-channels, it gives me an > error. "error: 'guix' channel is lacking". This is unclear. > I asked about it on IRC, and was told it refers to a channel called > guix. The error message should elaborate that guix expects a channel > with the name "guix". Commit f75243e17e3ff88582314bcb8450e654bb0b556b fixes it. Thanks, Ludo’.
bug#35589: Scribus and GIMP: Clipped, non-resizable windows and pixelated icons
After a Guix System reconfigure and upgrading packages, Scribus 1.5.5 and Pencil2D 0.6.4 work alright now (these are Qt-based applications). However, the problem persists in the GIMP 2.10.14. $ LANG=C guix describe Generation 7Jan 08 2020 13:53:10(current) guix f98c050 repository URL: https://git.savannah.gnu.org/git/guix.git branch: master commit: f98c050c2017be06cff54abf965a8234f6998f76 I don't know what fixed the issue for Qt-based applications. --- https://sirgazil.bitbucket.io/
bug#38172: WebkitGTK-based browsers: System volume suddenly maxed out when playing audio or video
Am Donnerstag, den 09.01.2020, 21:48 +0100 schrieb Marius Bakke: > > I have a preference for making this field empty initially to have a > 1:1 > compatibility with the current PA client and daemon configuration > (i.e. nothing). Then a follow-up patch can add this new > configuration, > perhaps with an explaining comment. Fair enough. This would mean I'd have to split 0001 into two, but okay. > Does it make sense to have default-script and system-script default > to > (file-append pulseaudio "...") and avoid the conditional altogether? The idea behind it was to have the script itself in the code rather than asking users to construct a mixed-text-file, but I'm fine either way. > This means pulseaudio will start looking in /etc/pulse for > configuration > files on foreign distributions too, right? > > I wonder if there is better way to give it configuration > files. Perhaps > by patching the D-Bus service files? Not a blocker for this series, > but > something to consider in case /etc/pulse causes trouble. This is already addressed by the renewed series I sent to guix-patches. I know you already found that, but I'd like to repeat it for those who thus far have only read this thread. > End on #t. As above, but thanks for the hint, I missed the warning it seems. > [...] > > > From e24016f9a44a113847dd937ac47ab4bdb960236d Mon Sep 17 00:00:00 > > 2001 > > From: Leo Prikler > > Date: Thu, 9 Jan 2020 01:29:13 +0100 > > Subject: [PATCH 3/3] services: Add pulseaudio to %desktop-services. > > > > * gnu/services/desktop.scm (%desktop-services): Add pulseaudio > > service. > > This will pull in "swh-plugins" which was the original intention > behind > pulseaudio-service before this patch series. Before adding it to > %desktop-services, I would prefer if the pulseaudio environment > configuration could be made modular, so that there are no > configuration > differences for end users, i.e. they'd have to actively enable the > LADSPA plugin. I think adding a field ladspa-plugins, which accepts a list of packages and adds their "lib/ladspa" would be the right approach here, but I also feel, that this perhaps deserves its own service unrelated to pulseaudio. WDYT? Either way, I agree on the "having to actively enable" part. > As a final note, can you also update doc/guix.texi accordingly? I will once I've figured out how to best handle these fields. Regards, Leo
bug#39060: Broken emacs-guix link in the Web manual
Guix,
sameerynho/lxsameer on #guix helpfully reported that ‘The
Emacs-Guix Reference Manual’ here[0] points to the wrong domain
(guix.gnu.org). The source is
@pxref{Top,,, emacs-guix, The Emacs-Guix Reference Manual}
so I thought this would be a trivial fix but lo:
EMACS_GUIX = https://emacs-guix.gitlab.io/website/manual/latest
emacs-guix mono${EMACS_GUIX}/emacs-guix.html
emacs-guix node${EMACS_GUIX}/html_node/
is already present in doc/htmlxref.cnf!
And that's where my Texinfo knowledge ends.
Cluebat me,
T G-R
[0]:
https://guix.gnu.org/manual/en/html_node/Package-Management.html#Package-Management
signature.asc
Description: PGP signature
bug#38940: \x1b]8; ; OSC character displayed on hyperlinks shown after calls to `guix describe` or `guix show` on mate-terminal 1.12.1 (Trisquel 8)
Hi Ludo' On Thu, 9 Jan 2020, Ludovic Courtès wrote: 1. Instead of INSIDE_EMACS, the variable name NO_SUPPORT_HYPERLINK or other seems more meaningful. Maybe? Actually the goal was to remove ‘INSIDE_EMACS’ from there once a widespread-enough Emacs version supports it, which could be within a year. And since other terminals are supposed to ignore it altogether, I would rather not add a special environment variable. Which Emacs version support it? I'm using Emacs 26.3 from master, and see the escape sequences in eshell. They seem to be correctly ignored in M-x shell. Thanks, Jack
