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, On Tue, 2020-01-07 at 12:58 +0100, zimoun wrote: > Does the environment variable NO_OSC appears to you more meaningful > than INSIDE_EMACS? It is more meaningful, but this terminal does interpret other operating system codes, like OSC 12 for changing the cursor color. NO_OSC_8 would be specific to hyperlinks. > Where do you think this should be documented? Which part of the manual? Installation > Application setup > Terminals > Some Guix commands print hyperlinks by sending non-printing control > characters (\1b]8;;) > to the terminal display. In most cases, this works fine. But some older > terminals will > misinterpret hyperlinks and print the control characters. > If that happens, define the NO_OSC_8 variable to disable hyperlinks: > > $ export NO_OSC_8=1 > > If you later upgrade to a terminal with hyperlink support, unset this > variable to enable > hyperlinks. Sincerely, Calvin
bug#38821: Can't run guix from external drive.
Hi, Jan skribis: > On Thu, 02 Jan 2020 19:37:43 +0100 > Ludovic Courtès wrote: > >> >> It most likely means that the current working directory, >> /media/user/Backup, was unmounted or somehow disappeared in the >> meantime. >> >> Can you confirm that this is the case? >> >> Thanks, >> Ludo’. > > Yes, it only happens, if the disk is unmounted. Is that normal? If it > is, then a message telling what's wrong would be helpful. This issue is not specific to Guix: the ‘getcwd’ function fails if the current working directory has been unmounted behind the back of the calling process. IOW, another program would fail similar in these circumstances. I don’t think there’s much that can be done. Thanks, Ludo’.
bug#39023: binary installation manual doesn't work on Alpine Linux
Hello, ezt írta (időpont: 2020. jan. 7., K, 22:32): > > The commands in > https://guix.gnu.org/manual/en/guix.html#Build-Environment-Setup > do not work on busybox-based systems such as Alpine Linux by default. > This is because they do not have 'groupadd' or 'useradd' by default (from > 'shadow' package). > > # groupadd --system guixbuild > # for i in `seq -w 1 10`; > do > useradd -g guixbuild -G guixbuild \ > -d /var/empty -s `which nologin`\ > -c "Guix build user $i" --system\ > guixbuilder$i; > done > > I suggest adding another example which works by default on busybox. > Explanation: -S means 'add system group/user'; -h is 'home directory'; -g is > 'GECOS field' > Also, Alpine Linux fails to boot if /var/empty is not owned by root, so that > needs to be fixed afterward as well. > > addgroup -S guixbuild > for i in `seq -w 1 10`; > do > adduser -G guixbuild \ > -h /var/empty -s `which nologin` \ > -g "Guix build user $i" -S \ > guixbuilder$i; > done > chown root:root /var/empty # /var/empty must be owned by root, fix permission > after `adduser` modified it > > > I assume that the command you gave would work on non-busybox also. I would say we should replace the command we have with this more compatible one. I would wait for a few more responses, though. If that sounds good to you could you create a patch to that effect? Best regards, g_bor -- OpenPGP Key Fingerprint: 7988:3B9F:7D6A:4DBF:3719:0367:2506:A96C:CF63:0B21
bug#22883: Authenticating Git checkouts: step #1
Hello, Jakub Kądziołka skribis: > Ludovic Courtès wrote: [...] >>How do you ensure that you obtained a genuine copy of the repository? >> Guix itself provides a tool to “authenticate” your checkout, but you >> must first make sure this tool is genuine in order to “bootstrap” the >> trust chain. To do that, run: >> >> git verify-commit `git log --format=%H build-aux/git-authenticate.scm` >> >>The output must look something like: >> >> gpg: Signature made Fri 27 Dec 2019 01:27:41 PM CET >> gpg:using RSA key >> 3CE464558A84FDC69DB40CFB090B11993D9AEBB5 >> ... >> gpg: Signature made Fri 27 Dec 2019 01:25:22 PM CET >> gpg:using RSA key >> 3CE464558A84FDC69DB40CFB090B11993D9AEBB5 >> ... >> >> ... meaning that changes to this file are all signed with key >> ‘3CE464558A84FDC69DB40CFB090B11993D9AEBB5’ (you may need to fetch this >> key from a key server, if you have not done it yet). >> >>From there on, you can authenticate all the commits included in your >> checkout by running: >> >> make authenticate >> >>The first run takes a couple of minutes, but subsequent runs are >> faster. >> >> Note: You are advised to run ‘make authenticate’ after every ‘git >> pull’ invocation. This ensures you keep receiving valid changes to >> the repository >> --8<---cut here---end--->8--- > > Sadly, these instructions don't work from a fresh clone. There is only > Makefile.am and no Makefile itself, so you get > > $ make authenticate > make: *** No rule to make target 'authenticate'. Stop. Uh, good point. > Moreover, I don't think running 'make authenticate' after 'git pull' > would really work -- after you pulled, git-authenticate could've been > modified, so the verify-commit you did earlier doesn't apply anymore. It works as long as I’m the only one modifying it (the instructions above explicitly mention my OpenPGP key). This is obviously suboptimal though. In a comment in ‘contributing.texi’, I wrote: @c XXX: Adjust instructions when there's a known tag to start from. That would simplify things. > There's also the issue of trusting pre-inst-env, which is used to run > the verification. Should that be passed to 'git log --format=%H' next to > git-authenticate.scm? This also applies to any scripts you use to drive > this process, like the Makefile. Yes, this ./pre-inst-env thing and more generally the fact that we’re potentially running just-pulled code to authenticate the code is a problem. We can solve it by removing ./pre-inst-env from the command in ‘make authenticate’. It will require people to have a recent-enough Guix already installed (in particular with commit f94f9d67e65975724ee5b5cbc936c0895a258685), but I think that’s unavoidable: the assumption will be that we trust the already-installed host tools and use them to authenticate the new code. Thoughts? Ludo’.
bug#38887: sassc has a memory leak
Somehow this sent without the details I typed out. Sorry for that... When I try to build arc-theme and leave it to run, the entire system eventually freezes. When I monitor how much memory it takes, I see that it spawns a sassc process that eventually takes all 30 GB of the RAM not taken by GNOME and the other services. When I sent the initial bug report, I found an upstream github issue that this could be related to, but I lost it. What should be done? If someone tries to build arc-theme or other packages that use sassc without a timeout, their system will probably crash from memory usage. -Jesse
bug#39041: cargo-build-system expects build dependencies to be in #:cargo-inputs, but the importer places them to #:cargo-development-inputs
As the subject states, when you import a cargo package from crates.io, importer places build dependencies to #:cargo-development-inputs, but when you build the package, cargo fails to find such dependencies. It works well if you move build deps from #:cargo-development-inputs to #:cargo-inputs. One example of this behavior is terminfo package and its phf-codegen dependency. Another example is x11-dl package and its pkg-config dependency Regards, Valentin
bug#39019: psyclpc does not compile
sympho...@disroot.org writes: > The package psyclpc fails to compile because of errors relating to OpenSSL. > The word psyclpc is also mentioned in https://issues.guix.gnu.org/issue/34717 > which might be relevant. > Build log is attached. Thanks! Fixed in e7e315c02ec2165c31b250770b848fe37f358d9d. signature.asc Description: PGP signature
bug#37931: Cannot guix refresh -ru util-linux to get updated lsblk
Bengt Richter writes:
> Hi Marius,
>
> On +2019-11-03 18:28:40 +0100, Marius Bakke wrote:
>> Bengt Richter writes:
>>
>> > On +2019-10-28 23:29:16 +0100, Marius Bakke wrote:
>> >> The `lsblk` program requires root privileges in order to detect file
>> >> systems and UUIDs. I'm guessing your distribution makes it setuid root?
>> >>
>> >
>> > It doesn't look like it to me (the following snip is from TTY4, where I
>> > enabled guix paths and environment,
>> > so I can see ~/.guix-profile and /usr stuff at the same time):
>>
>> [...]
>>
>>
>> > $ which -a lsblk|xargs readlink -f|xargs stat
>> > File:
>> > /gnu/store/xymkwf57x988q8cny2is1dgzrbr9xdfi-util-linux-2.34/bin/lsblk
>> > Size: 135560 Blocks: 272IO Block: 4096 regular file
>> > Device: 10304h/66308d Inode: 1186253 Links: 2
>> > Access: (0555/-r-xr-xr-x) Uid: (0/root) Gid: (0/root)
>> > Access: 2019-11-01 02:38:11.782574923 -0700
>> > Modify: 1969-12-31 16:00:01.0 -0800
>> > Change: 2019-10-08 18:18:48.226579757 -0700
>> > Birth: -
>> > File: /usr/bin/lsblk
>> > Size: 124992 Blocks: 248IO Block: 4096 regular file
>> > Device: 10304h/66308d Inode: 264652 Links: 1
>> > Access: (0755/-rwxr-xr-x) Uid: (0/root) Gid: (0/root)
>> > Access: 2019-11-01 02:38:55.354524750 -0700
>> > Modify: 2019-06-27 03:04:01.0 -0700
>> > Change: 2019-07-06 00:59:13.620416635 -0700
>> > Birth: -
>> > $
>> > ┌───┐
>> > │ I see Access: is 0555 vs 0755, so doubt if that should be changed │
>> > └───┘
>>
>> Indeed, there are no setuid bits there.
>>
>> I had a look at the lsblkd source code, and found that it has an
>> optional dependency on udev:
>>
>> https://github.com/karelzak/util-linux/blob/ccafadb7c58865f73d209fcfc74483be96cdf64d/misc-utils/lsblk-properties.c
>>
>> I tried building util-linux with udev support, and got the same output
>> you expected without needing root privileges:
>>
>
> Sounds great ;-)
>
>> (define-public util-linux/udev
>> (package/inherit
>>util-linux
>>(name "util-linux-with-udev")
>>(inputs
>> `(("udev" ,eudev)
>> ,@(package-inputs util-linux)
>>
>> Now, eudev already depends on util-linux, so adding udev support to the
>> regular 'util-linux' package would introduce a circular dependency.
>>
>> I'm not sure what the best approach here is. We could add a
>> 'util-linux-minimal' for use in package inputs, and/or add a
>> udev-enabled variant to %base-packages.
>>
>> Thoughts?
This was finally committed in 71e0f1e9adbce4a6476a70bddabf13f6d7af2d40
and 01bb039e7b408893009d15f56cfcbdc8af70a4af.
>
> I'm a guix newbie :)
>
> I don't yet understand the internal dependency machinery of guix,
> so I'm wondering about the exact nature of the circularity.
>
> Is it really a kind of (let((... that needs to be a let*((...
> at some level? And which level of dependency are we talking about?
The circular dependency is straightforward: eudev *requires* util-linux
as part of its build process. Thus, eudev has util-linux as an input.
That version of util-linux can not depend on eudev, because we can not
build eudev without a working util-linux package.
Wrt the rest of the message, I share your sentiment, and think we will
get there. 'guix build --with-git-url' is pretty close already. :-)
signature.asc
Description: PGP signature
bug#39043: Channels error is too vague
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".
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 Heim skribis: > On Tue, 2020-01-07 at 12:58 +0100, zimoun wrote: >> Does the environment variable NO_OSC appears to you more meaningful >> than INSIDE_EMACS? > > It is more meaningful, but this terminal does interpret other operating > system codes, > like OSC 12 for changing the cursor color. NO_OSC_8 would be specific to > hyperlinks. 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. So I would say that this is a bug in this version of mate-terminal, or perhaps in the libvte version it’s using? I’ve just tried mate-terminal 1.22.0 on vte 0.58.3 from Guix, and it silently ignores those codes. Thanks, Ludo’.
bug#38958: Timestamp out of range; substituting 2514-05-30 01:53:03.999999999
Hi Roel, Roel Janssen skribis: > When inside a container produced with: > $ guix environment -CN --ad-hoc ... > > I encounter a problem when running "make" for some code base: > make[3]: /gnu/store/5hkc9q38w6afhrf7xyz5ybxidr87d1mq-profile/include/syslog.h: > Timestamp out of range; substituting 2514-05-30 01:53:03.9 Fun. :-) What does “uname -rm” return? What the value of the ‘TZ’ environment variable? Can it be easily reproduced? 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)
On Wed, 2020-01-08 at 22:28 +0100, Ludovic Courtès wrote: > Hi, > > Calvin Heim skribis: > > > > > On Tue, 2020-01-07 at 12:58 +0100, zimoun wrote: > > > > > > Does the environment variable NO_OSC appears to you more meaningful > > > than INSIDE_EMACS? > > It is more meaningful, but this terminal does interpret other operating > > system codes, > > like OSC 12 for changing the cursor color. NO_OSC_8 would be specific to > > hyperlinks. > 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. > I concur. > So I would say that this is a bug in this version of mate-terminal, or > perhaps in the libvte version it’s using? 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. > I’ve just tried mate-terminal 1.22.0 on vte 0.58.3 from Guix, and it > silently ignores those codes. > > Thanks, > Ludo’. Thanks, Calvin
bug#32247: HandBrake shows no icons
On Mon, 23 Jul 2018, Andreas Enge wrote: Hi Andreas, > On Mon, Jul 23, 2018 at 08:17:35AM -0500, Eric Bavier wrote: >> I think there's a version upgrade available. Might be a good time to visit >> that >> and these issues together. > > I had a look before, wondering whether this would be an option to make the > package compile again, but upgrading is more complicated than just changing > the source. So in the end I took the path of least resistance and downgraded > the ffmpeg input... I just ran the current version of Handbrake in Guix and can see icons, so it may be that this has been fixed elsewhere or through upgrades. Would you mind testing again please to see if this is fixed for you? Regards, Ben -- Ben Sturmfels Sturm Software Engineering www.sturm.com.au +61 3 9024 2467 signature.asc Description: PGP signature
bug#38172: WebkitGTK-based browsers: System volume suddenly maxed out when playing audio or video
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.
Regards,
Leo
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.
---
gnu/services/sound.scm | 47 --
1 file changed, 45 insertions(+), 2 deletions(-)
diff --git a/gnu/services/sound.scm b/gnu/services/sound.scm
index aaca733729..f01d958ce7 100644
--- a/gnu/services/sound.scm
+++ b/gnu/services/sound.scm
@@ -34,6 +34,7 @@
#:export (alsa-configuration
alsa-service-type
+pulseaudio-configuration
pulseaudio-service-type))
;;; Commentary:
@@ -106,19 +107,61 @@ ctl.!default {
;;; PulseAudio
;;;
+(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
+ (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")))
+
(define pulseaudio-service-type
(service-type
(name 'pulseaudio)
(extensions
(list (service-extension session-environment-service-type
- pulseaudio-environment)))
- (default-value #f)
+ pulseaudio-environment)
+ (service-extension etc-service-type pulseaudio-etc)))
+ (default-value (pulseaudio-configuration))
(description "Configure PulseAudio sound support.")))
;;; sound.scm ends here
--
2.24.1
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".
---
gnu/packages/pulseaudio.scm | 5 +
1 file changed, 5 insertions(+)
diff --git a/gnu/packages/pulseaudio.scm b/gnu/packages/pulseaudio.scm
index 671dcd1563..1fb5a2f578 100644
--- a/gnu/packages/pulseaudio.scm
+++ b/gnu/packages/pulseaudio.scm
@@ -161,6 +161,11 @@ rates.")
(assoc-ref %outputs "out")
"/lib/udev/rules.d"))
#:phases (modify-phases %standard-phases
+ (add-after 'configure 'hardcode-defau
