bug#61965: Commands like "guix system search KEYWORD" don't work with locale it_IT.utf8

[Julien Lepiller]

Le Mon, 06 Mar 2023 23:46:57 +0100,
Ludovic Courtès  a écrit :

> Hi Luigi,
> 
> Luigi Salamone  skribis:
> 
> > I'm unable to use guix commands like "guix system search KEYWORD".
> > No problem if I run the commend with LANG=LC_ALL.  
> 
> [...]
> 
> > ice-9/boot-9.scm:1685:16: In procedure raise-exception:
> > Throw to key `parser-error' with args `(#f "Unknown command" dnf)'.
> >  
> 
> I believe Tobias (Cc’d) fixed this and related issues a couple of days
> ago in 0609ae7897b025f46822779d0c5c36509cb0180f and
> 4775460ba9a60c3c09966216da10686a70b8fadb.
> 
> Julien: We’ll have to make sure these changes reach Weblate.  :-)
> 
> Thanks,
> Ludo’.

I believe it did already reach Weblate :)

bug#61570: Backward incompatible changes in mpd-service-type

[Liliana Marie Prikler]

Am Montag, dem 06.03.2023 um 20:13 -0500 schrieb Maxim Cournoyer:
> > Am Freitag, dem 17.02.2023 um 07:53 -0500 schrieb Maxim Cournoyer:
> > > Else an error rather than a warning when multiple same-name users
> > > are defined would be more appropriate, I think.
> > Guess what, it used to be a formatted message (i.e. an actual
> > error).  However, that broke some configs as reported in [1], so I
> > demoted it to a warning.
> 
> Interesting.  I didn't know we were usefully (?) abusing duplicate
> users and group.
As far as I'm aware, we aren't.  Even if such uses exist, they raise
said warning and probably cause more issues down the line, like with
your bug report.

> Perhaps we should try to isolate the most common offenders
> (services?), fix them up, and then re-introduce the check, perhaps
> gradually (e.g. "in 6 months time, duplicated users or groups will
> become a configuration error").
The only instance known to me (cups creating a duplicate lp group) was
fixed back in 2021.

Cheers

bug#61987: 'current-guix' uses configure flags of Git checkout

[Winter via Bug reports for GNU Guix]

After looking through some of the code in (guix self), this may not be a bug at 
all? If something wants the current Guix, it'd definitely want that to include 
all the configuration values of the current Guix, too.

Due to this, I'm leaning towards closing this issue, but I'll let someone more 
knowledgable in this area make the final call.

Thanks,
Winter

bug#46782: guix environment --expose options cannot be layered onto $PWD

[Maxim Cournoyer]

Hello Josselin,

Josselin Poiret  writes:

> Hello everyone,
>
> A quick strace shows that it's actually an ordering issue: /home/user is
> mounted in the container after /home/user/tmp.  The fix is pretty
> simple, moving the cwd first, before the explicit --expose arguments.

Thanks for the troubleshooting and patch!  I've now applied it.

> I'm noticing that the --expose option creates an empty tmp folder in the
> user's home in that case though, which I don't like, however I don't
> think there's any better option.  Patch following.

At least it's better to be left with an empty directory than with
mysteriously nothing happening and the use case not working as expected
:-).

-- 
Thanks,
Maxim

bug#62021: Failed to Build docker 20.10.17

[Edison Ibáñez]

=== SKIP: pkg/fsutils TestSupportsDTypeWithFType0XFS (0.04s)
fsutils_linux_test.go:48: Executing `mkfs.xfs [-m crc=0 -n ftype=0
/tmp/guix-build-docker-20.10.17.drv-0/fsutils-image3647692651]`
fsutils_linux_test.go:51:
meta-data=/tmp/guix-build-docker-20.10.17.drv-0/fsutils-image3647692651
isize=256agcount=2, agsize=4096 blks
 =   sectsz=512   attr=2,
projid32bit=1
 =   crc=0finobt=0,
sparse=0, rmapbt=0
 =   reflink=0
data =   bsize=4096   blocks=8192,
imaxpct=25
 =   sunit=0  swidth=0 blks
naming   =version 2  bsize=4096   ascii-ci=0,
ftype=0
log  =internal log   bsize=4096   blocks=853,
version=2
 =   sectsz=512   sunit=0 blks,
lazy-count=1
realtime =none   extsz=4096   blocks=0,
rtextents=0

fsutils_linux_test.go:61: mount:
/tmp/guix-build-docker-20.10.17.drv-0/fsutils-mountpoint900600792: mount
failed: Operation not permitted.

fsutils_linux_test.go:64: skipping the test because mount failed

=== SKIP: pkg/fsutils TestSupportsDTypeWithFType1XFS (0.03s)
fsutils_linux_test.go:48: Executing `mkfs.xfs [-m crc=0 -n ftype=1
/tmp/guix-build-docker-20.10.17.drv-0/fsutils-image3216051184]`
fsutils_linux_test.go:51:
meta-data=/tmp/guix-build-docker-20.10.17.drv-0/fsutils-image3216051184
isize=256agcount=2, agsize=4096 blks
 =   sectsz=512   attr=2,
projid32bit=1
 =   crc=0finobt=0,
sparse=0, rmapbt=0
 =   reflink=0
data =   bsize=4096   blocks=8192,
imaxpct=25
 =   sunit=0  swidth=0 blks
naming   =version 2  bsize=4096   ascii-ci=0,
ftype=1
log  =internal log   bsize=4096   blocks=853,
version=2
 =   sectsz=512   sunit=0 blks,
lazy-count=1
realtime =none   extsz=4096   blocks=0,
rtextents=0

fsutils_linux_test.go:61: mount:
/tmp/guix-build-docker-20.10.17.drv-0/fsutils-mountpoint2335159853:
mount failed: Operation not permitted.

fsutils_linux_test.go:64: skipping the test because mount failed

=== SKIP: pkg/fsutils TestSupportsDTypeWithExt4 (0.04s)
fsutils_linux_test.go:48: Executing `mkfs.ext4
[/tmp/guix-build-docker-20.10.17.drv-0/fsutils-image1523553822]`
fsutils_linux_test.go:51: mke2fs 1.46.4 (18-Aug-2021)
Discarding device blocks: done
Creating filesystem with 32768 1k blocks and 8192 inodes
Filesystem UUID: 13605075-3b8d-4460-b621-2924ba775050
Superblock backups stored on blocks:
8193, 24577

Allocating group tables: done
Writing inode tables: done
Creating journal (4096 blocks): done
Writing superblocks and filesystem accounting information: done


fsutils_linux_test.go:61: mount:
/tmp/guix-build-docker-20.10.17.drv-0/fsutils-mountpoint2204178808:
mount failed: Operation not permitted.

fsutils_linux_test.go:64: skipping the test because mount failed

=== SKIP: pkg/idtools TestMkdirAllAndChown (0.00s)
idtools_unix_test.go:392: os.Getuid() != 0: skipping test that
requires root

=== SKIP: pkg/idtools TestMkdirAllAndChownNew (0.00s)
idtools_unix_test.go:392: os.Getuid() != 0: skipping test that
requires root

=== SKIP: pkg/idtools TestMkdirAndChown (0.00s)
idtools_unix_test.go:392: os.Getuid() != 0: skipping test that
requires root

=== SKIP: pkg/idtools TestNewIDMappings (0.00s)
idtools_unix_test.go:392: os.Getuid() != 0: skipping test that
requires root

=== SKIP: pkg/idtools TestLookupUserAndGroup (0.00s)
idtools_unix_test.go:392: os.Getuid() != 0: skipping test that
requires root

=== SKIP: pkg/system TestEnsureRemoveAllWithMount (0.00s)
rm_test.go:18: os.Getuid() != 0: skipping test that requires root

=== SKIP: quota TestBlockDev (0.00s)
projectquota_test.go:22: requires mounts

=== SKIP: registry TestPingRegistryEndpoint (0.00s)
registry_test.go:47: os.Getuid() != 0: skipping test that requires
root

=== SKIP: registry TestEndpoint (0.00s)
registry_test.go:67: os.Getuid() != 0: skipping test that requires
root

=== SKIP: registry TestMirrorEndpointLookup (0.00s)
registry_test.go:510: os.Getuid() != 0: skipping test that requires
root

=== SKIP: volume/local TestQuota (0.00s)
local_linux_test.go:23: requires mounts

=== SKIP: volume/local TestCreateWithOpts (0.00s)
local_test.go:182: os.Getuid() != 0: requires mounts


=== Failed
=== FAIL: pkg/system TestChtimesLinux (0.00s)
chtimes_linux_test.go:87: Expected: 2262-04-11 23:47:16 + UTC,
got: 2038-01-19 03:14:07 + UTC

=== FAIL: pkg/system TestChtimes (0.00s)
chtimes_test.go:92: Expected: 

bug#61570: Backward incompatible changes in mpd-service-type

[Maxim Cournoyer]

Hi Liliana,

Liliana Marie Prikler  writes:

[...]

>> This is an unfortunate situation arising from a bug before the
>> service was refactored.
>> Before d7fd9ec209f72e9cfff04a48bf16e092f258d8ff (actually
>> 5c5f0fc1135ff15f9c4adfc5f27eadd9a592b5d1)
>> mpd-service-type contained a service-extension for %mpd-accounts
>> where the values for both group and user were hardcoded to "mpd"
>> but this was actually never used since shepherd would launch the
>> service using root and mpd would downgrade its permissions and switch
>> to the user specified in the mpd-configuration record since this
>> field is serialized to the configuration file.
> It would be quite weird if someone had already pointed out how to
> properly handle the accounts and groups only for that to be ignored
> later in the review.
>
> Am Samstag, dem 24.12.2022 um 18:20 +0100 schrieb eine leichtsinnige
> Person, die ihre eigenen Anmerkungen vergisst:
>> I think you should make it so that you can pass a user-account and
>> user-group to the mpd service so that they can be reused (with a
>> sanitizer that creates a user/group from string).
> Never mind then.

I think Bruno has been reworking that, I think they must be about ready.

> Am Freitag, dem 17.02.2023 um 07:53 -0500 schrieb Maxim Cournoyer:
>> Else an error rather than a warning when multiple same-name users are
>> defined would be more appropriate, I think.
> Guess what, it used to be a formatted message (i.e. an actual error). 
> However, that broke some configs as reported in [1], so I demoted it to
> a warning.

Interesting.  I didn't know we were usefully (?) abusing duplicate users
and group.  Perhaps we should try to isolate the most common offenders
(services?), fix them up, and then re-introduce the check, perhaps
gradually (e.g. "in 6 months time, duplicated users or groups will
become a configuration error").

-- 
Thanks,
Maxim

bug#58813: [PATCH] doc: Document how to use Patman for patches submission.

[Maxim Cournoyer]

Hi Ludovic,

Ludovic Courtès  writes:

> Hi,
>
> Maxim Cournoyer  skribis:
>
>> Fixes .
>
> It’s only tangentially related, no?

It's not totally a tangent, because it removes examples which do not
work, and replace them with ones that do work, and recommend a tool that
can do what the previous shell command substitution failed to do
correctly (due to shell parsing rules).

>> * doc/contributing.texi (Sending a Patch Series): Mention Patman.  Adjust the
>> examples to no longer showcase broken command substitutions.  Add a section
>> about how to use Patman, with examples.
>
> I’m not convinced we’d want to advocate for yet another tool.  I feel
> like this would make patch submission guidelines even more complex, or
> at least look more complex.
>
> Also, how many of the ~40 committers would be able to provide guidance
> with patman?  That shouldn’t be the only criterion, but it certainly is
> an important one.

Since it's just documented as another tool on top, I don't think this
matters too much (it can be adopted or not).  It's also a very simple
tool, which is more often than not invoked as simply 'patman' or 'patman
-n' (for dry-run).

I've also discovered about '--cc-cmd', which could be used with the
recently introduced get-maintainer mode (which was added for patman
support); it can be used like this:

--8<---cut here---start->8---
git send-email --cc-cmd='etc/teams.scm get-maintainer' --dry-run -1
--8<---cut here---end--->8---

It does the same thing as the copy/pasting of the output of

--8<---cut here---start->8---
etc/teams.scm cc-members HEAD^ HEAD
--8<---cut here---end--->8---

To the git send-email command, but with one difference: it uses '--cc'
for the email addresses instead of the nicer --add-header="X-Debbugs-Cc:
m...@example.org" ones.  The later is best because when initially
sending the message to Debbugs, there's no bug # known yet, and the
receivers would be left to guess and perhaps even reply erroneously to
guix-patc...@gnu.org and create a new ticket.

For this reason, I'm toying with the idea of contributing a "--x-cmd"
option to git send-email, which would be a script that outputs arbitrary
git send-email options to add to its command line.

To be continued...

-- 
Thanks,
Maxim

bug#57742: QT plugins from profile not found (QT_PLUGIN_PATH)

[Maxim Cournoyer]

Hi,

Marek Paśnikowski  writes:

> Hello.
>
> I found a piece of QT documentation on handling of plugins [1].
>
> Is it helpful to achieving working Plasma Desktop on Guix?
>
> Maxim - I was able to only find your email address; I don't think the
> other participants of this Debbugs issue will receive a copy of this
> message.
>
> Best Regards,
> Marek Paśnikowski
>
> [1]: 
> https://doc.qt.io/qt-6.2/deployment-plugins.html#loading-and-verifying-plugins-dynamically

Thanks for the link.  According to it, there shouldn't be a problem a
problem mixing various Qt versions on the same QT_PLUGIN_PATH, as Qt is
supposed to not load plugins that were linked against a newer version,
or older major version.

If this was so, then it seems like the problem/concern I reported
upstream https://bugreports.qt.io/browse/QTBUG-107459 could be
acknowledged and closed, but I'd like to have confirmation.  I've sent a
comment to the above ticket, hopefully we can get such confirmation.

-- 
Thanks,
Maxim

bug#61911: error: mate-polkit: unbound variable

[Ludovic Courtès]

Hi Josselin & Maxime,

Josselin Poiret  skribis:

> Maxime Devos  writes:
>
>> In unknown file:
>> 3 (primitive-load-path "gnu/packages/xfce" #)
>> In gnu/packages/xfce.scm:
>>1156:19  2 (_)
>> 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:
>> error: mate-polkit: unbound variable
>
> This is the same kind of issue as [1]: both xfce and mate require each
> other (the second through mate -> freedesktop -> kde-frameworks ->
> kde-plasma -> display-managers -> xfce), and depending on the order in
> which they're loaded, mate-polkit-for-xfce might get defined before
> mate-polkit is.  The solution I suggested there was to define the
> variant in the same file as the original package, but here I'm not sure
> if this is the right call.

It is the right call.  The (unwritten?) rule is to always define
variants in the same module as the original module, to avoid top-level
circular references.

I pushed it as 0d963875278d585eb86bc87127efa20a8d627595 as I think it
should be considered a rather serious issue.

Thanks,
Ludo’.

bug#61881: Failed install with 1.4.0 installer-dump-2464c73a

[Ludovic Courtès]

Vagrant Cascadian  skribis:

> On 2023-03-01, Josselin Poiret wrote:
>> Vagrant Cascadian  writes:

[...]

>> I can't find the installer dump on dump.guix.gnu.org unfortunately
>> :(.
>
> It is possible I typoed it somehow, as I filed the report on another
> machine and eyeballed the name...

I used my superpowers and found the typo:

  https://dump.guix.gnu.org/download/installer-dump-2464c83a

:-)

Ludo’.

bug#61965: Commands like "guix system search KEYWORD" don't work with locale it_IT.utf8

[Ludovic Courtès]

Hi Luigi,

Luigi Salamone  skribis:

> I'm unable to use guix commands like "guix system search KEYWORD".
> No problem if I run the commend with LANG=LC_ALL.

[...]

> ice-9/boot-9.scm:1685:16: In procedure raise-exception:
> Throw to key `parser-error' with args `(#f "Unknown command" dnf)'.

I believe Tobias (Cc’d) fixed this and related issues a couple of days
ago in 0609ae7897b025f46822779d0c5c36509cb0180f and
4775460ba9a60c3c09966216da10686a70b8fadb.

Julien: We’ll have to make sure these changes reach Weblate.  :-)

Thanks,
Ludo’.

bug#61971: guix pack "cross-compilation not implemented here"

[Ludovic Courtès]

Hi,

Nathan Dehnel  skribis:

> This command fails with guix 6a1464b:
>
> guix pack -RR --target=aarch64-linux-gnu -S /bin=bin btrfs-progs
> hint: Consider installing the `glibc-locales' package and defining
> `GUIX_LOCPATH', along these lines:
>
> guix install glibc-locales
> export GUIX_LOCPATH="$HOME/.guix-profile/lib/locale"
>
> See the "Application Setup" section in the manual, for more info.
>
> guix pack: error: cross-compilation not implemented here;
> please email 'bug-guix@gnu.org'

Specifically, ‘-R’ (relocatable packs) does not support
cross-compilation (see guix/scripts/pack.scm if you’re curious).

If that’s an option for you, you can omit ‘-RR’ from the command line.

Anyhow, we take note that someone hit this limitation and that we now
have to do something about it.  :-)

Thanks,
Ludo’.

bug#44776: SIGSEGV in Brasero

[Christopher Howard]

Hello, I'm am also getting a segfault.

To reproduce: It happens when I attempt to burn an ISO file to a CD-RW. It 
happens the moment I click the "Burn" on the Image Burning Setup dialog window.

My system:

```
christopher@theoden ~$ neofetch --stdout
christopher@theoden 
--- 
OS: Guix System x86_64 
Host: OptiPlex 9020 00 
Kernel: 5.15.96-gnu 
Uptime: 31 mins 
Packages: 94 (guix-system), 184 (guix-user) 
Shell: bash 5.1.8 
Resolution: 1920x1080 
DE: GNOME 
Theme: Adwaita [GTK2/3] 
Icons: Adwaita [GTK2/3] 
Terminal: .gnome-terminal 
CPU: Intel i5-4570 (4) @ 3.600GHz 
GPU: Intel HD Graphics 
GPU: AMD ATI Radeon HD 8490 / R5 235X OEM 
Memory: 1552MiB / 7867MiB 
```

I rebuilt Brasero with the following command, with the aim to get debug 
symbols, though I don't seem to be getting them...

```
guix build brasero --with-debug-info=brasero --with-debug-info=glib
```

Then here is the backtrace I got. My gdb skills are a bit rusty... if somebody 
can suggest better commands I can provide additional output.

```
Thread 1 ".brasero-real" received signal SIGSEGV, Segmentation fault.
0x766896c0 in g_dbus_proxy_call_finish_internal () from 
/gnu/store/ginkhx2irsi4qwkpnnwg4r30h7jwhi62-glib-2.70.2/lib/libgio-2.0.so.0
(gdb) bt
#0  0x766896c0 in g_dbus_proxy_call_finish_internal () from 
/gnu/store/ginkhx2irsi4qwkpnnwg4r30h7jwhi62-glib-2.70.2/lib/libgio-2.0.so.0
#1  0x77ef441c in brasero_pk_finalize () from 
/gnu/store/937pqmb8y6gnkvnlby7kgyjd8cms43g8-brasero-3.12.3/lib/libbrasero-utils3.so.1
#2  0x7652a272 in g_object_unref () from 
/gnu/store/ginkhx2irsi4qwkpnnwg4r30h7jwhi62-glib-2.70.2/lib/libgobject-2.0.so.0
#3  0x77f3fd85 in brasero_burn_options_install_missing () from 
/gnu/store/937pqmb8y6gnkvnlby7kgyjd8cms43g8-brasero-3.12.3/lib/libbrasero-burn3.so.1
#4  0x77f52ae4 in brasero_caps_report_plugin_error () from 
/gnu/store/937pqmb8y6gnkvnlby7kgyjd8cms43g8-brasero-3.12.3/lib/libbrasero-burn3.so.1
#5  0x77f53c82 in brasero_caps_try_output_with_blanking () from 
/gnu/store/937pqmb8y6gnkvnlby7kgyjd8cms43g8-brasero-3.12.3/lib/libbrasero-burn3.so.1
#6  0x77f53df7 in brasero_burn_session_supported () from 
/gnu/store/937pqmb8y6gnkvnlby7kgyjd8cms43g8-brasero-3.12.3/lib/libbrasero-burn3.so.1
#7  0x77f5437f in brasero_session_foreach_plugin_error () from 
/gnu/store/937pqmb8y6gnkvnlby7kgyjd8cms43g8-brasero-3.12.3/lib/libbrasero-burn3.so.1
#8  0x77f3fc24 in brasero_burn_options_response () from 
/gnu/store/937pqmb8y6gnkvnlby7kgyjd8cms43g8-brasero-3.12.3/lib/libbrasero-burn3.so.1
#9  0x765254af in g_closure_invoke () from 
/gnu/store/ginkhx2irsi4qwkpnnwg4r30h7jwhi62-glib-2.70.2/lib/libgobject-2.0.so.0
#10 0x765369e9 in signal_emit_unlocked_R.isra.0 () from 
/gnu/store/ginkhx2irsi4qwkpnnwg4r30h7jwhi62-glib-2.70.2/lib/libgobject-2.0.so.0
#11 0x7653d21b in g_signal_emit_valist () from 
/gnu/store/ginkhx2irsi4qwkpnnwg4r30h7jwhi62-glib-2.70.2/lib/libgobject-2.0.so.0
#12 0x7653d722 in g_signal_emit () from 
/gnu/store/ginkhx2irsi4qwkpnnwg4r30h7jwhi62-glib-2.70.2/lib/libgobject-2.0.so.0
#13 0x765256d9 in _g_closure_invoke_va () from 
/gnu/store/ginkhx2irsi4qwkpnnwg4r30h7jwhi62-glib-2.70.2/lib/libgobject-2.0.so.0
#14 0x7653d548 in g_signal_emit_valist () from 
/gnu/store/ginkhx2irsi4qwkpnnwg4r30h7jwhi62-glib-2.70.2/lib/libgobject-2.0.so.0
#15 0x7653d722 in g_signal_emit () from 
/gnu/store/ginkhx2irsi4qwkpnnwg4r30h7jwhi62-glib-2.70.2/lib/libgobject-2.0.so.0
#16 0x773ae898 in ?? () from 
/gnu/store/6nxm0gslsll9z3ry84hxg5ri3bl8s779-gtk+-3.24.30/lib/libgtk-3.so.0
#17 0x76525607 in _g_closure_invoke_va () from 
/gnu/store/ginkhx2irsi4qwkpnnwg4r30h7jwhi62-glib-2.70.2/lib/libgobject-2.0.so.0
#18 0x7653d548 in g_signal_emit_valist () from 
/gnu/store/ginkhx2irsi4qwkpnnwg4r30h7jwhi62-glib-2.70.2/lib/libgobject-2.0.so.0
#19 0x7653d722 in g_signal_emit () from 
/gnu/store/ginkhx2irsi4qwkpnnwg4r30h7jwhi62-glib-2.70.2/lib/libgobject-2.0.so.0
#20 0x773acc40 in ?? () from 
/gnu/store/6nxm0gslsll9z3ry84hxg5ri3bl8s779-gtk+-3.24.30/lib/libgtk-3.so.0
#21 0x776530a2 in ?? () from 
/gnu/store/6nxm0gslsll9z3ry84hxg5ri3bl8s779-gtk+-3.24.30/lib/libgtk-3.so.0
#22 0x765256d9 in _g_closure_invoke_va () from 
/gnu/store/ginkhx2irsi4qwkpnnwg4r30h7jwhi62-glib-2.70.2/lib/libgobject-2.0.so.0
#23 0x7653d548 in g_signal_emit_valist () from 
/gnu/store/ginkhx2irsi4qwkpnnwg4r30h7jwhi62-glib-2.70.2/lib/libgobject-2.0.so.0
#24 0x7653d722 in g_signal_emit () from 
/gnu/store/ginkhx2irsi4qwkpnnwg4r30h7jwhi62-glib-2.70.2/lib/libgobject-2.0.so.0
#25 0x77472133 in ?? () from 
/gnu/store/6nxm0gslsll9z3ry84hxg5ri3bl8s779-gtk+-3.24.30/lib/libgtk-3.so.0
#26 0x765282ab in g_cclosure_marshal_VOID__BOXEDv () from 
/gnu/store/ginkhx2irsi4qwkpnnwg4r30h7jwhi62-glib-2.70.2/lib/libgobject-2.0.so.0
#27 0x76525607 in _g_closure_invoke_va () 

bug#58813: ‘guix style’ flaws

[Maxim Cournoyer]

Hi Ludo,

Ludovic Courtès  writes:

> Liliana Marie Prikler  skribis:
>
>> Compare and contrast
>> 'guix style', where committers often have to point out its flaws.
>
> Hi!  Drifting off-topic, but: I’d really like people to report specific
> issues to bug-guix so we can act on them and reach the point where the
> tool’s output is good 99% of the time.

See #61013 :-).

-- 
Thanks,
Maxim

bug#61914: IceCat does not start with en_GB.utf8 locale

[Timo Wilken]

I cannot start IceCat with a non-C locale. It opens an almost-blank
window, and I cannot open new tabs or navigate to any URL.

If I run `LANG=C icecat', then it works fine.

I use `guix system' and `guix home', and have IceCat installed in my
`guix home' profile.

I have my operating-system configured with the following locales:

(locale "en_GB.utf8")
(locale-definitions
 (list (locale-definition (name "en_GB.utf8") (source "en_GB"))
   (locale-definition (name "en_US.utf8") (source "en_US"))
   (locale-definition (name "fr_FR.utf8") (source "fr_FR"

This is the output when running IceCat in my terminal (without
explicitly setting LANG, so that it retains its value of
"en_GB.utf8"):

$ icecat
ATTENTION: default value of option mesa_glthread overridden by environment.
ATTENTION: default value of option mesa_glthread overridden by environment.
ATTENTION: default value of option mesa_glthread overridden by environment.
JavaScript error: chrome://pocket/content/SaveToPocket.jsm, line 130: 
NS_ERROR_FAILURE: Component returned failure code: 0x80004005 
(NS_ERROR_FAILURE) [nsIStringBundle.formatStringFromName]
JavaScript error: chrome://browser/content/tabbrowser.js, line 7004: 
NS_ERROR_FAILURE: Component returned failure code: 0x80004005 
(NS_ERROR_FAILURE) [nsIStringBundle.GetStringFromName]
JavaScript error: chrome://browser/content/tabbrowser-tabs.js, line 64: 
NS_ERROR_UNEXPECTED: Component returned failure code: 0x8000 
(NS_ERROR_UNEXPECTED) [nsIStringBundle.GetStringFromName]
JavaScript error: resource:///modules/sessionstore/SessionStore.jsm, line 2458: 
TypeError: browser is undefined
JavaScript error: resource:///modules/UrlbarInput.jsm, line 2641: 
NS_ERROR_FAILURE: Component returned failure code: 0x80004005 
(NS_ERROR_FAILURE) [nsIStringBundle.GetStringFromName]
JavaScript error: chrome://browser/content/browser.js, line 8052: TypeError: 
browser is undefined
JavaScript error: resource:///modules/sessionstore/TabStateFlusher.jsm, line 
230: TypeError: browser is undefined
Missing chrome or resource URL: resource://gre/modules/UpdateListener.jsm
Missing chrome or resource URL: resource://gre/modules/UpdateListener.sys.mjs
console.error: "Error during quit-application-granted: [Exception... \"File 
error: Not found\"  nsresult: \"0x80520012 (NS_ERROR_FILE_NOT_FOUND)\"  
location: \"JS frame :: resource:///modules/BrowserGlue.jsm :: 
_onQuitApplicationGranted/tasks< :: line 1996\"  data: no]"
$ guix shell glibc -- locale
LANG=en_GB.utf8
LC_CTYPE="en_GB.utf8"
LC_NUMERIC="en_GB.utf8"
LC_TIME="en_GB.utf8"
LC_COLLATE="en_GB.utf8"
LC_MONETARY="en_GB.utf8"
LC_MESSAGES="en_GB.utf8"
LC_PAPER="en_GB.utf8"
LC_NAME="en_GB.utf8"
LC_ADDRESS="en_GB.utf8"
LC_TELEPHONE="en_GB.utf8"
LC_MEASUREMENT="en_GB.utf8"
LC_IDENTIFICATION="en_GB.utf8"
LC_ALL=
$ guix shell glibc -- locale -a
C
en_GB.utf8
en_US.utf8
fr_FR.utf8
POSIX
$ guix describe
Generation 2Mar 02 2023 13:25:29(current)
  [one non-free channel omitted]
  guix a7763e0
repository URL: https://git.savannah.gnu.org/git/guix.git
branch: master
commit: a7763e067d86908210758aab80d33e4f8b815b1c

GUIX_PACKAGE_PATH="/home/twilken/src/guix-decls"
$ ls -l "$(which icecat)"
lrwxrwxrwx 1 root root 84 Jan  1  1970 
/home/twilken/.guix-home/profile/bin/icecat -> 
/gnu/store/bwcrfgfrri9bpglgb5raih167jaxibkv-icecat-102.8.0-guix0-preview1/bin/icecat

bug#61914: IceCat does not start with en_GB.utf8 locale

[Timo Wilken]

Hi Maxim,

Thanks for your reply!

What finally worked for me was the following:

$ sed -i.bak 
's|/gnu/store/hhfcn8viysyz2qz9rvvqkj91i5nxzd9s|/gnu/store/bwcrfgfrri9bpglgb5raih167jaxibkv|g'
 \
  ~/.mozilla/icecat/vfc41hol.default/extensions.json \
  ~/.mozilla/icecat/vfc41hol.default/addonStartup.json.lz4

After running that, IceCat suddenly worked fine.

No directory starting with /gnu/store/hhfcn8viysyz2qz9rvvqkj91i5nxzd9s
exists on my system.

I guess that means the "guix gc" I did yesterday is to blame!

There were lots of entries like the following in my extensions.json:

"rootURI":"jar:file:///gnu/store/hhfcn8viysyz2qz9rvvqkj91i5nxzd9s-icecat-102.8.0-guix0-preview1/lib/icecat/browser/extensions/langpack...@icecat.mozilla.org.xpi!/",

...and then when guix gc deleted an old IceCat directory, these files
were gone.

Is there some way of forcing IceCat not to embed the /gnu/store path
in the user's profile at runtime?

On Thu Mar 2, 2023 at 3:54 PM CET, Maxim Cournoyer wrote:
> Could you try running with a fresh profile?  E.g., 'icecat
> --ProfileManager', create a new profile, and start it from there?

This works, as does using icecat --safe-mode (which presumably avoids
loading all extensions and language packs). The new profile has the
right /gnu/store paths embedded in extensions.json (i.e. those
pointing to the "current" IceCat). I suppose this will blow up as well
on the next guix gc...

> It should work.  I suspect the problem may be caused by
> 'intl.locale.requested' being set to something.  It needs to be unset
> for the system locale to be honored, so if that's the problem with your
> current profile, you could try clearing it by visiting "about:config" in
> the URL bar.

This setting was already cleared.

Cheers,
Timo

bug#61955: Code snippets do not show in Firefox reader mode

[無]

When opening the documentation in Firefox's reader mode, code snippets
do not appear.

Talking about pages such as these:

https://guix.gnu.org/en/manual/en/html_node/Getting-Started.html

Thank you,
Yuval Langer.

bug#61883: evince no longer opens comics

[Yovan Naumovski via Bug reports for GNU Guix]

Probably the comics support in the Evince Guix package is disabled. The 
Evince version that's currently available in Guix (42.3) requires 
libarchive >= 3.6.0 as per the meson.build file [1], but the currently 
available libarchive version in Guix is 3.5.1.


[1] https://gitlab.gnome.org/GNOME/evince/-/blob/42.3/meson.build#L352

Best regards,

Yovan.

bug#61697: Chromium with guix shell container from the manual doesn't work.

[em...@msavoritias.me]

The problem was that in xorg you need the specific option:

```

--share=/tmp

```

So the command would look like:

```

guix shell --container --network --share=/tmp --no-cwd icecat 
--preserve='^DISPLAY$' -- icecat


```


While in wayland it works as is.

Next step would be documenting this in the manual.

bug#52257: Patch

[Sarthak Shah]

I've sent a patch to guix-patc...@gnu.org that should fix this.
This is my first commit to the project, so please let me know if I've made
any mistakes.

bug#61852: ‘scheme48-prescheme’ is not reproducible

[Andrew Whatson via Bug reports for GNU Guix]

Ludovic Courtès wrote:

Hi,

Andrew Whatson  skribis:


Comparing hex dumps of the files, there are significant differences,
and a quick dive through the image dumping code leads into VM and
garbage collector details which are over my head.

I guess patching Scheme 48 to build deterministic images is
out-of-scope and maybe an issue for upstream.


Yes, probably!  Would you mind reporting it upstream?


No worries, I've emailed the Scheme 48 list about the issue.

Cheers,
Andrew

bug#58813: ‘guix style’ flaws

[Ludovic Courtès]

Liliana Marie Prikler  skribis:

> Compare and contrast
> 'guix style', where committers often have to point out its flaws.

Hi!  Drifting off-topic, but: I’d really like people to report specific
issues to bug-guix so we can act on them and reach the point where the
tool’s output is good 99% of the time.

Ludo’.

bug#61914: IceCat does not start with en_GB.utf8 locale

[Maxim Cournoyer]

Hi Timo,

Maxim Cournoyer  writes:

> Hi,
>
> Maxim Cournoyer  writes:
>
> [...]
>
>> Browsing about:config, I see:
>>
>> extensions.systemAddon.update.enabledfalse
>>
>> I wonder if this could make a different to be set to true instead.  It's
>> set to false by the makeicecat.sh script we run to transform the Firefox
>> source into GNU IceCat.  I guess we'll have to look at the source for
>> more clues as to how language pack updates are handled exactly.
>
> I have the same problem, where the French language pack I used with a
> previous version of IceCat (102.7.0) is not updating to the
> system-provided one.  Setting 'extensions.systemAddon.update.enabled' to
> 'true' does not help.
>
> I've now reported the issue upstream:
> https://bugzilla.mozilla.org/show_bug.cgi?id=1820196.

Trying to reproduce the above, I'm not sure if I still can!  One
hypothesis, is that perhaps I had installed the french language pack
(the .xpi file produced by Guix) manually while testing.  I also
remember testing other languages, such as with LC_ALL=es_ES.utf8, and I
don't see the problem where that one "stuck".  It could be because I
hadn't tried with an older version, but not having a clear reproducers
make things muddy.

Could it be that you had previously installed the language packs
manually?

-- 
Thanks,
Maxim

bug#61497: emacs-lsp-treemacs unused leftover icons in sources

[Jelle Licht]

Liliana Marie Prikler  writes:

> Am Dienstag, dem 14.02.2023 um 02:06 +0100 schrieb Jelle Licht:
>> Commit e0d2ec418bb on master removed icons that are unclearly
>> licensed
>> from the sources of emacs-lsp-treemacs. Quoted here: 
>> 
>> --8<---cut here---start->8---
>> gnu: emacs-lsp-treemacs: Remove unclearly licensed icons.
>> 
>> emacs-lsp-treemacs bundles icons with unclear licenses.
>> See also .
>> --8<---cut here---end--->8---
>> 
>> Some icons are still left in the sources, in the 'icons/vscode'
>> directory' of the source tarball one builds by running `guix build
>> --source emacs-lsp-treemacs'. I have never used vscode, and am
>> unfamiliar with the licensing situation of it and its related icons.
>> 
>> In case these icons are also unclearly licensed, I propose we follow
>> the same strategy as done earlier by Liliana, and remove the vscode
>> icons entirely.  If the icons are actually licensed under an
>> unproblematic license, it would be nice if they were installed when
>> running `guix install emacs-lsp-treemacs', and the license property
>> of the package updated to reflect this fact.
> From what I could gather, vscode-icons [1] are actually CC-BY, but used
> without proper attribution in this package.  As for why they're unused,
> I mostly forgot to whitelist them.
>
> Cheers
>
> [1] https://github.com/microsoft/vscode-icons

Fixed + pushed to master in #61649 / 3f222cd5ad,
closing this issue.

- Jelle

bug#62000: Inconsistent indentation rules for define-configuration

[Bruno Victal]

Suspected file: .dir-locals.el


Using 'package' as a field in define-configuration results in inconsistent 
indentation:

--8<---cut here---start->8---
(define-configuration/no-serialization mympd-configuration
  (package
(file-like mympd) < notice how it's 
indented with 2 spaces
"The package object of the myMPD server."
empty-serializer)

  (shepherd-requirement
   (list-of-symbol '())   < vs 1 space
   "This is a list of symbols naming Shepherd services that this service
will depend on."
   empty-serializer)

;; ...
)
--8<---cut here---end--->8---