bug#26430: xlockmore on xfce4 with non-fatal font issues

[zimoun]

Hi,

On Tue, 09 Feb 2021 at 02:13, zimoun  wrote:

> If someone using Xfce could provide moreinfo about:
>
>
>
> Because I am missing what could be the next actionable step.  And,
> except the submission on 2017 and my 2 emails asking the status, there
> is no comment, so I conclude, maybe too fast, that it is not worth to
> let open it.
>
> On Mon, 11 Jan 2021 at 13:57, zimoun  wrote:
>> On Fri, 18 Dec 2020 at 21:05, zimoun  wrote:
>>> On Mon, 10 Apr 2017 at 09:50, ng0  wrote:

>>> If someone using xfce4 could provide moreinfo about this bug.
>>> Otherwise, I will close it after the usual 3 weeks delay.
>>
>> If no objection, I will close it in the coming days.
>
> Let close it?

After waiting for more than 2 months about moreinfo and not receiving
it, I am closing.

Feel free to reopen if I misread something.


All the best,
simon

bug#46938: ruby-memory-profiler test-failure on x86

[Christopher Howard]

I'm trying to install mate desktop on a 32 bit x86 laptop. This
evidently is dependent on gnome-shell building, which in turn is
dependent on ruby-memory-profiler, which does not build due to three
test failures.
"""   /gnu/store/v3zgvwa1c0w44skld09iminwrg5j93c9-ruby-memory-profiler-
1.0.0.drv
building /gnu/store/v3zgvwa1c0w44skld09iminwrg5j93c9-ruby-memory-
profiler-1.0.0.drv...builder for
`/gnu/store/v3zgvwa1c0w44skld09iminwrg5j93c9-ruby-memory-profiler-
1.0.0.drv' failed with exit code 1build of
/gnu/store/v3zgvwa1c0w44skld09iminwrg5j93c9-ruby-memory-profiler-
1.0.0.drv failedView build log at
'/var/log/guix/drvs/v3/zgvwa1c0w44skld09iminwrg5j93c9-ruby-memory-
profiler-1.0.0.drv.bz2'.cannot build derivation
`/gnu/store/q8l4d3qxz8vghv5i526zckqa31xrx11n-ruby-rubocop-1.10.0.drv':
1 dependencies couldn't be builtbuilding
/gnu/store/vynlki5k7r2y3950xdihxr3cdi9rn47p-ruby-rubocop-ast-1.4.1-
checkout.drv...cannot build derivation
`/gnu/store/2yy6q52ximcm8zxyw9xdpiayc7b0mnlx-ruby-rdoc-6.2.0.drv': 1
dependencies couldn't be builtcannot build derivation
`/gnu/store/jxg83183dmms1w5id7kqbi1alvpyyf64-ruby-terminfo-0.1.1.drv':
1 dependencies couldn't be builtcannot build derivation
`/gnu/store/nsq3ydsz5rpqjg2qbpq2zggmxvxf3xbg-ruby-sass-3.6.0.drv': 1
dependencies couldn't be builtcannot build derivation
`/gnu/store/k25lm8nxsiba262y92ps802n79f8x5dz-gnome-shell-3.34.2.drv': 1
dependencies couldn't be builtguix system: error: build of
`/gnu/store/k25lm8nxsiba262y92ps802n79f8x5dz-gnome-shell-3.34.2.drv'
failed"""
My system info:"""$ neofetch --stdoutroot@mithril  OS: Guix
System 1.2.0-8.7624ebb i686 Host: CF-30CTQAZBM 001 Kernel: 5.10.2-
gnu Uptime: 2 hours, 43 mins Packages: 66 (guix-system) Shell: bash
5.0.16 Resolution: 1024x768 Terminal: .emacs-27.1-rea CPU: Genuine
Intel L2400 (2) @ 1.667GHz GPU: Intel Mobile 945GM/GMS/GME, 943/940GML
Express Memory: 72MiB / 3013MiB
$ guix describeGeneration 2 Mar 04 2021 05:58:22(current)  guix
bc10203repository URL: https://git.savannah.gnu.org/git/guix.git   
 branch: mastercommit: bc10203475ede3f88416a7614b7e9343fca8de75"""
Build log attached.




zgvwa1c0w44skld09iminwrg5j93c9-ruby-memory-profiler-1.0.0.drv.bz2
Description: application/bzip

bug#46269: first guix-pull on foreign distro doesn't create directories

[Edgar Vincent]

Hello everyone,

I've encountered this issue with a fresh installation of Guix System, 
from the following ISO: `gk3mcnyallckwvi8f33idv2klj3lj8nw-image.iso`.


Thanks for your great work,

Edgar Vincent

bug#46905: Add a note about ext4's dir_index to the manual

[Tobias Geerinckx-Rice via Bug reports for GNU Guix]

Hi Ludo'!

I should note that later in the IRC convo I corrected my sloppy 
‘full’ to ‘hash collision’.  Unfortunately it just returns an 
already overloaded -ENOSPC to user space.


Ludovic Courtès 写道：
IIRC store accesses were much slower before [dir_index] was a 
thing


Yes, it's a (t)horny dilemma :-/


I don’t think we can claim there’s a design flaw.  WDYT?


Fine; implementation flaw, then?  Problem is, it's not like there 
are other implementations than the one we're stuck with, so it 
matters little what we call it.


Kind regards,

T G-R


signature.asc
Description: PGP signature

bug#46905: Add a note about ext4's dir_index to the manual

[Tobias Geerinckx-Rice via Bug reports for GNU Guix]

Tobias Geerinckx-Rice 写道：

Mainly a reminder to myself to do so.


Update: I did a tiny bit of reading and came across the 
‘large_dir’ feature, which (as described) mitigates this problem 
somewhat.


Kind regards,

T G-R


signature.asc
Description: PGP signature

bug#46879: Non-deterministic failures while building Guix with Guile 3.0.5

[Ludovic Courtès]

Ludovic Courtès  skribis:

> In gnu/services/mcron.scm:
>132:13  0 (mcron-shepherd-services _)
>
> gnu/services/mcron.scm:132:13: In procedure mcron-shepherd-services:
> In procedure allocate-struct: Wrong type argument in position 1 (expecting 
> struct): #
> builder for 
> `/gnu/store/kp01hrirz40h7p7aim4dspajjv3yyvda-guix-system-tests.drv' failed 
> with exit code 1

Turns out this is not the first time such things are reported:

  https://issues.guix.gnu.org/28858
  https://issues.guix.gnu.org/44402

Ludo’.

bug#46905: Add a note about ext4's dir_index to the manual

[Ludovic Courtès]

Hi!

Tobias Geerinckx-Rice  skribis:

> Mainly a reminder to myself to do so.
>
> Guix can break ext4, and more than once has, with a inscrutable error
> message.  We should document it explicitly.
>
> See .

You wrote:

--8<---cut here---start->8---
OK, that's the culprit (it's common: ext4 has a design flaw in that it 
hashes directory entries and... just
dies when the hash table gets ‘full’). Try ‘tune2fs -E "hash_alg=tea" /dev/foo’ 
to select a different hash algo, or
‘tune2fs -O "^dir_index" /dev/foo’ to disable it completely if that doesn't 
help.
--8<---cut here---end--->8---

Really?  I’ve almost always used ‘dir_index’ in my Guix + NixOS days,
and IIRC store accesses were much slower before that was a thing.

On berlin, /gnu is a 37 TiB file system with ‘dir_index’ turned on and
it works well.

I don’t think we can claim there’s a design flaw.  WDYT?

Ludo’.

bug#46934: emacsy-minimal fails to build

[Xinglu Chen]

Hi,

While trying to install Nomad, the emacsy-minimal packages fails to
build.

--8<---cut here---start->8---
[...]

phase `unpack' succeeded after 0.0 seconds
starting phase `bootstrap'
patch-shebang: build-aux/git-version-gen: changing `/bin/sh' to
`/gnu/store/pwcp239kjf7lnj5i4lkdzcfcxwcfyk72-bash-minimal-5.0.16/bin/sh'
running './autogen.sh'
patch-shebang: ./autogen.sh: changing `/bin/sh' to
`/gnu/store/pwcp239kjf7lnj5i4lkdzcfcxwcfyk72-bash-minimal-5.0.16/bin/sh'
./autogen.sh: line 2: autoreconf: command not found
command "./autogen.sh" failed with status 127
builder for
`/gnu/store/1xz2q90jcv10g24jgv4lkcdvi7qv5wd4-emacsy-minimal-0.4.1-37-g5f91ee6.drv'
failed with exit code 1
build of
/gnu/store/1xz2q90jcv10g24jgv4lkcdvi7qv5wd4-emacsy-minimal-0.4.1-37-g5f91ee6.drv
failed
View build log at
'/var/log/guix/drvs/1x/z2q90jcv10g24jgv4lkcdvi7qv5wd4-emacsy-minimal-0.4.1-37-g5f91ee6.drv.bz2'.
guix build: error: build of
`/gnu/store/1xz2q90jcv10g24jgv4lkcdvi7qv5wd4-emacsy-minimal-0.4.1-37-g5f91ee6.drv'
failed
--8<---cut here---end--->8---

Since emacsy-minimal uses the gnu-build-system, I thought that
`autoreconf` would already be available in the build environment, no?

I was able to reproduce this with:

$ guix time-machine --commit=bc10203 -- build emacsy-minimal

Any help would be appreciated!

bug#46925: Ripgrep tests failures due to bstr update

[Nicolas Goaziou]

Hello,

John Soo  writes:

> I just talked to burntsushi on github about the failing ripgrep tests.
> It looks like the version of bstr we are now using changed the
> representation of bstrs and caused us test failures.  Changing the
> version of bstr used in ripgrep@12.1.1 to 0.2.12 should fix the
> problem.

I disabled tests in ripgrep a few hours ago for the same reason. This is
not great, but I couldn't find another solution. In particular,
replacing rust-bstr-0.2 with a special rust-bstr-0.2.12 did not work
because regular rust-bstr-0.2 is still used as a transitive dependency.

Do you think of a better way to solve this?

Regards,
-- 
Nicolas Goaziou

bug#40456: Invalid keyboard layouts pass through

[Brice Waegeneire via web]

We could listen from the WARNING: string on stderr of ckbcomp, or that dirty 
pipeline return 1 with an incorrect variant « setxkbmap -print fr foo | xkbcomp 
- -C »

bug#45962: ‘binutils-mesboot0’ includes non-zero timestamps in ar archives

[Maxim Cournoyer]

Jan Nieuwenhuizen  writes:

> Ludovic Courtès writes:
>
> Hello!
>
>> Ludovic Courtès  skribis:
>>
>>> On #bootstrappable, mid-kid reported that ‘binutils-mesboot0’ in
>>> commencement.scm lacks ‘--enable-deterministic-archives’.  So I checked
>>> if this had an effect by running:
>
>> [...]
>>
>>> Apparently Binutils 2.14 didn’t have ‘--enable-deterministic-archives’
>>> so we’ll have to patch it.
>>
>> Sikonas on #bootstrappable provided a patch for that (thanks!) so I went
>> ahead and gave it a try on ‘core-updates’ (Guix patch attached).
>
> Great!
>
>> The binutils source gets patched and repacked, but then decompressing it
>> fails:
>
> [..]
>
>> Maxime, does that ring a bell?  Could it be that this bootstrap ‘xz’ is
>> less capable, or could it be a Gash-Utils bug?
>
> Currently, we avoid using non-bootstrapped binaries in the bootstrap,
> that includes 'xz'; earlier in the bootstrap that includes also 'patch'.
>
> See also gcc-core-mesboot0: it applies the patch in a manual phase.  So
> I'm not sure if we want to start depending on 'xz' an this stage?

I see; so what Ludovic got surprised by is the fact that when adding
patches or a snippet to an origin it gets repacked as an xz tarball.
That's nothing new (it's how it is on the master branch too); but it can
indeed be surprising.

Maxim

bug#46925: Ripgrep tests failures due to bstr update

[John Soo]

Hi Guix,

I just talked to burntsushi on github about the failing ripgrep tests.
It looks like the version of bstr we are now using changed the
representation of bstrs and caused us test failures.  Changing the
version of bstr used in ripgrep@12.1.1 to 0.2.12 should fix the problem.

See https://github.com/BurntSushi/ripgrep/discussions/1813

Thanks!

John

bug#45962: ‘binutils-mesboot0’ includes non-zero timestamps in ar archives

[Maxim Cournoyer]

Hi,

Ludovic Courtès  writes:

[...]

> ERROR: In procedure scm-error:
> ERROR: decompressed-port failure (7)
> error: in phase 'unpack': uncaught exception:
> srfi-34 # "/gnu/store/ywf5j03423yiawix3z21xa14hyyvd83z-binutils-2.14.tar.xz") 
> exit-status: 1 term-signal: #f stop-signal: #f] 1215400> 
> phase `unpack' failed after 0.3 seconds
> command "tar" "xvf" 
> "/gnu/store/ywf5j03423yiawix3z21xa14hyyvd83z-binutils-2.14.tar.xz" failed 
> with status 1
> builder for 
> `/gnu/store/fwz150xjaqbh8n02z6gsmpm9w8lxckak-binutils-mesboot0-2.14.drv' 
> failed with exit code 1
>
> Maxime, does that ring a bell?  Could it be that this bootstrap ‘xz’ is
> less capable, or could it be a Gash-Utils bug?

>From my IRC logs:

2020-09-20 22:32:01 apteryx janneke: haha! the xz-bootstrap supports
--memlimit with % after all, my mistake was really silly... forgetting a
space between the args passed as XZ_DEFAULTS

I recall a similar error I had hit when working on adding multi-core
compression support to xz, but it ended up being just a mistake on my
part; the xz-bootstrap supported the required arguments just fine after
all.

HTH,

Maxim

bug#46807: [website] return 404 with HTTP header 'Accept-Language: zh-CN, zh'

[pelzflorian (Florian Pelz)]

On Sat, Feb 27, 2021 at 01:31:40PM +0100, Tobias Geerinckx-Rice via Bug reports 
for GNU Guix wrote:
> I expect that adding it and changing ietf-tags.scm to use "zh-CN" will fix
> both 404s, but need to check that it doesn't break anything else.

I made the tiny change to guix-artwork’s ietf-tags.scm as
04c96a370b8cae48ed162e4414b8950cc65c513b now (sorry for taking so
long):

diff --git a/website/po/ietf-tags.scm b/website/po/ietf-tags.scm
index 32b81ef..5bd22f4 100644
--- a/website/po/ietf-tags.scm
+++ b/website/po/ietf-tags.scm
@@ -10,4 +10,4 @@
  ("de_DE" . "de")
  ("es_ES" . "es")
  ("fr_FR" . "fr")
- ("zh_CN" . "zh-cn"))
+ ("zh_CN" . "zh-CN"))

Note that the prior zh-cn URLs will be broken.

I will play around with nginx’ map directive to make zh-cn and zh
Accept-Language settings direct to the proper URL later, afterwards I
will close this bug.  zh-cn URLs remain invalid.  Links to the manual
continue to use zh-cn.

For testing I dug out the VM code

where I had removed parts of berlin that are not relevant to the
website.  The change breaks neither website nor manual.

Thanks ylc991 for the report!

Regards,
Florian

bug#45599: using guix to install packages from inside a container that runs on foreign distro breaks guix and the foreign distro

[Ludovic Courtès]

Hi David,

Looks like this bug report fell through the cracks of the turn of year…

david larsson  skribis:

> upon starting it with sudo /gnu/store/asdfasdfasdf-run-container
>
>
> and connecting to it with
>
> sudo guix container exec 8625 /run/current-system/profile/bin/bash
> --login
> [sudo] password for david:
> root@MinimalSSH /#
> root@MinimalSSH /#
> root@MinimalSSH /# guix package -i hello

[...]

> error: executing
> `/gnu/store/qyjhy4bkz51jyspi63llfznsnz7vibzy-guix-1.1.0-30.875c01f/bin/guix 
> substitute': No such file or directory
> guix package: error: unexpected EOF reading a line
> root@MinimalSSH /#
> root@MinimalSSH /# exit
> logout
> guix container: error: exec failed with status 1
> david@l560:~/VirtualHome/src$ guix package -i hello
> bash: /usr/local/bin/guix:
> /gnu/store/b7rixb64yp00znz0d5rwd5zzklwzlzmv-guile-wrapper/bin/guile:
> bad interpreter: No such file or directory

It looks as though the store item for Guix or Guile used on the host had
been suddenly wiped, even though we don’t see any GC activity or
similar.

> As you can see, guix is now broken on both the host and guest system.

Were you able to better see what was broken?  Is it that store items
were removed?  Are there issues with non-Guix files?  It would be great
if you could gather more details as to what’s wrong.  I’ll also see if I
can try that in a VM.

Thanks,
Ludo’.