bug#63198: cups-service-type uses PAM-enabled 'cups' by default which prevents authentication

[muradm]

Hello,

Maxim Cournoyer  writes:


Hi,

muradm  writes:


Fixes .

Makes CUPS service to extend pam-root-service-type providing 
minimal
configuration to authenticate users. Since PAM authentication 
is

provided, cups package can be used as default.

* gnu/services/cups.scm (cups-configuration) [cups]: Use cups.


I'd write 'Replace cups-minimal with cups'.



Sure you may change this.

[allow-empty-password?]: PAM service configuration permitting 
empty passwords.


I'd write 'New field', but I think we'd want to add proper PAM 
support
here not a 'bypass PAM authentication' hack.  It should also be 
enabled
out of the box, otherwise users won't be able to authenticate 
until they

figure out they need to set that switch to #t.



Who ever touches PAM configuration knows that by default PAM does 
not
allow to authenticate users with empty passwords. This flag allows 
such
users. Just grep guix for allow-empty-password?, you will see that 
it

is all over the places.


(opaque-cups-configuration): Likewise.
(cups-pam-service): cups PAM service.


Not descriptive :-)  What is the change here?



I used simlilar strategy as in your commit 6bc3e3f9ba :-) You are 
free

to reword as you wish.

Could you look into adding "regular" login PAM support instead 
of a
bypass disabled by default?  The user should still be prompted 
for its

password, and it should go through the PAM auth module.

I'm not very PAM-aware, but I believe there are examples spread 
in the

code base.


This patch provides necessary configuration for proper PAM 
support.

I decided to take screen-locker-service-type's configuration as
basis, since it is was most simpliest and adequate enough for this 
case.

This patch does not disables, baypasses or cheats PAM in any way.
User may navigate to CUPS portal. In the event of administrative
actions taken by user, CUPS portal asks user to authenticate.
With this configuration, it will attempt to authenticate as local
system user. In the event of proper system user/password supplied
and positively authenticated against PAM using "cups" service 
name,
user allowed to take administrative action. In the event of 
invalid

system user/password supplied, CUPS portal will keep looping
begging for password (just as in your original case). If user 
decides

to Cancel the authentication dialog, CUPS portal is navigated to
Unauthorized access informing page.

Why would I submit something that it is not working?


signature.asc
Description: PGP signature

bug#63530: Missing library in package procps

[Csepp]

Gabriel Wicki  writes:

> Hi
>
> Trying to upgrade a somewhat outdated system (from March 23) I noticed
> igt-gpu-tools failed to build.  Investigating a bit the build fails due
> to some "proc/readproc.h" include missing.  I think i managed to fix the
> failure in procps's Makefile, but testing the patched build results in a
> rather huge rebuild.  `guix refresh -l procps` results in 5328
> packages.  Are there any other approaches one could take to a) fix the
> broken package without b) triggering a world-rebuild?
>
> I'm not sure if this is an upstream bug and whether other packages are
> affected, neither do I know whether the other header files that aren't
> being copied to the install dir should be.
>
>
> Thanks for your input in advance!  I'll update this issue with a patch
> as soon as I manage to verify that my attempt actually works.
>
> gabber

You could test it as a graft, then dependents won't get rebuilt.  If the
public ABI exported by the package doesn't change, it Should Be Fine TM.

bug#63530: Missing library in package procps

[Gabriel Wicki]

Hi

Trying to upgrade a somewhat outdated system (from March 23) I noticed
igt-gpu-tools failed to build.  Investigating a bit the build fails due
to some "proc/readproc.h" include missing.  I think i managed to fix the
failure in procps's Makefile, but testing the patched build results in a
rather huge rebuild.  `guix refresh -l procps` results in 5328
packages.  Are there any other approaches one could take to a) fix the
broken package without b) triggering a world-rebuild?

I'm not sure if this is an upstream bug and whether other packages are
affected, neither do I know whether the other header files that aren't
being copied to the install dir should be.


Thanks for your input in advance!  I'll update this issue with a patch
as soon as I manage to verify that my attempt actually works.

gabber

bug#63529: awscli doesn’t use global certificate store on foreign distro

[Ricardo Wurmus]

On a foreign distro, awscli does not use the global certificate store.
It seems to only use certifi.pem from the python-certifi package.  There
seems to be no way to override the certificate store.

This makes awscli unusable on foreign distros.

-- 
Ricardo

bug#63526: hubbub build failure when doing guix package -u

[Andy Tai]

key lines:

COMPILE: test/tokeniser2.c
 COMPILE: test/tokeniser3.c
 COMPILE: test/tree.c
 COMPILE: test/tree2.c
 COMPILE: test/tree-buf.c
test/tokeniser2.c: In function ‘token_handler’:
test/tokeniser2.c:444:46: error: ‘t.data.character.ptr’ may be used
uninitialized [-Werror=maybe-uninitialized]
  444 | t.data.character.ptr += len;
  |  ^~
test/tokeniser2.c:441:38: note: ‘t’ declared here
  441 | hubbub_token t;
  |  ^
test/tokeniser2.c:445:46: error: ‘t.data.character.len’ may be used
uninitialized [-Werror=maybe-uninitialized]
  445 | t.data.character.len -= len;
  |  ^~
test/tokeniser2.c:441:38: note: ‘t’ declared here
  441 | hubbub_token t;
  |  ^
test/tokeniser3.c: In function ‘token_handler’:
test/tokeniser3.c:453:46: error: ‘t.data.character.ptr’ may be used
uninitialized [-Werror=maybe-uninitialized]
  453 | t.data.character.ptr += len;
  |  ^~
test/tokeniser3.c:450:38: note: ‘t’ declared here
  450 | hubbub_token t;
  |  ^
test/tokeniser3.c:454:46: error: ‘t.data.character.len’ may be used
uninitialized [-Werror=maybe-uninitialized]
  454 | t.data.character.len -= len;
  |  ^~
test/tokeniser3.c:450:38: note: ‘t’ declared here
  450 | hubbub_token t;
  |  ^
LINK: 
build-x86_64-unknown-linux-gnu-x86_64-unknown-linux-gnu-release-lib-shared/test_entities
LINK: 
build-x86_64-unknown-linux-gnu-x86_64-unknown-linux-gnu-release-lib-shared/test_csdetect
LINK: 
build-x86_64-unknown-linux-gnu-x86_64-unknown-linux-gnu-release-lib-shared/test_tokeniser
LINK: 
build-x86_64-unknown-linux-gnu-x86_64-unknown-linux-gnu-release-lib-shared/test_parser
cc1: all warnings being treated as errors
make: *** 
[/gnu/store/3jqaqf59ra550lk7hvpgpg8l5krxizra-netsurf-buildsystem-1.9/share/netsurf-buildsystem/makefiles/Makefile.top:631:
build-x86_64-unknown-linux-gnu-x86_64-unknown-linux-gnu-release-lib-shared/test_tokeniser2.o]
Error 1
make: *** Waiting for unfinished jobs
cc1: all warnings being treated as errors
make: *** 
[/gnu/store/3jqaqf59ra550lk7hvpgpg8l5krxizra-netsurf-buildsystem-1.9/share/netsurf-buildsystem/makefiles/Makefile.top:631:
build-x86_64-unknown-linux-gnu-x86_64-unknown-linux-gnu-release-lib-shared/test_tokeniser3.o]
Error 1

Test suite failed, dumping logs.
error: in phase 'check': uncaught exception:
%exception #< program: "make" arguments: ("test" "-j"
"31" "COMPONENT_TYPE=lib-shared" "CC=gcc" "BUILD_CC=gcc"
"PREFIX=/gnu/store/7fn6jxg1vpadm8rpa8rzbwqgipxlwync-hubbub-0.3.7"
"NSSHARED=/gnu/store/3jqaqf59ra550lk7hvpgpg8l5krxizra-netsurf-buildsystem-1.9/share/netsurf-buildsystem")
exit-status: 2 term-signal: #f stop-signal: #f>
phase `check' failed after 0.2 seconds
command "make" "test" "-j" "31" "COMPONENT_TYPE=lib-shared" "CC=gcc"
"BUILD_CC=gcc" "PREFIX=/gnu/store/7fn6jxg1vpadm8rpa8rzbwqgipxlwync-hubbub-0.3.7"
"NSSHARED=/gnu/store/3jqaqf59ra550lk7hvpgpg8l5krxizra-netsurf-buildsystem-1.9/share/netsurf-buildsystem"
failed with status 2

bug#59278: gcc@7 and higher are not hidden packages

[zimoun]

Hi,

On Tue, 15 Nov 2022 at 00:53, bbb ee  wrote:

> in version c81457a5883ea43950eb2ecdcbb58a5b144bcd11 of guix, gcc-toolchain 
> depends gcc:
> ```
> $ DEFAULT_CHANNELS=/tmp/default_channels.scm
> $ echo "%default-channels" > $DEFAULT_CHANNELS
> # I force guix to use only %default-channels here
> $ guix time-machine --commit=c81457a5883ea43950eb2ecdcbb58a5b144bcd11  -C 
> $DEFAULT_CHANNELS -- search gcc-toolchain
> guile: warning: failed to install locale
> name: gcc-toolchain
> version: 9.3.0
> outputs: out debug static
> systems: x86_64-linux i686-linux
> dependencies: binutils@2.32 gcc@9.3.0 glibc@2.29 ld-wrapper@0
> ```
>
> However, I can't find gcc package in this version of guix
> ```
> $ guix time-machine --commit=c81457a5883ea43950eb2ecdcbb58a5b144bcd11  -C 
> $DEFAULT_CHANNELS -- search gcc
> # no found gcc
>
> # guix install failure message confirm that gcc doesn't exist in commit c81457
> $ guix time-machine --commit=c81457a5883ea43950eb2ecdcbb58a5b144bcd11 -C 
> $DEFAULT_CHANNELS -- install gcc -p
> ~/opt/python-dev_3_7
> guile: warning: failed to install locale
> guix install: error: gcc: unknown package
> ```
>
> in commit c81457, how gcc-toolchain can depends a package who doesn't exists?

Aside a minor point about documenting ’hidden-packages’ although
’hidden?’ is mentioned in section “9.3 Defining Package Variants“ [1],
the main issue is fixed by e1bf3c6b5a06b6dbbe4f5a8692ea638a0ce43511.

Moreover, please note the section “8.4 The GCC toolchain” [2] in the
manual explaining the confusion.

Closing?

1: https://guix.gnu.org/manual/devel/en/guix.html#Defining-Package-Variants
2: https://guix.gnu.org/manual/devel/en/guix.html#The-GCC-toolchain

Cheers,
simon

bug#20255: 'search-paths' should respect both user and system profile.

[Maxim Cournoyer]

Hi,

Josselin Poiret  writes:

> Hi,
>
> 宋文武 via Bug reports for GNU Guix  writes:
>
>> Hello, commit 40310efde9b4a4f2cf98081d6cd10f843685ebb6 fix this by merge
>> search-paths from multiple profiles by `guix package --search-paths`, in
>> ~/.bashrc and ~/.zprofile (skeletons, so existed systems need manual
>> update).  
>>
>>
>> Close now!
>
> I just checked and zsh does load /etc/profile by default on login, and
> on guix system that also loads the user's profile by default.  Should we
> remove this so that profiles are only loaded once?

Just to make sure, remove what exactly?

-- 
Thanks,
Maxim

bug#20255: 'search-paths' should respect both user and system profile.

[Josselin Poiret via Bug reports for GNU Guix]

Hi,

宋文武 via Bug reports for GNU Guix  writes:

> Hello, commit 40310efde9b4a4f2cf98081d6cd10f843685ebb6 fix this by merge
> search-paths from multiple profiles by `guix package --search-paths`, in
> ~/.bashrc and ~/.zprofile (skeletons, so existed systems need manual
> update).  
>
>
> Close now!

I just checked and zsh does load /etc/profile by default on login, and
on guix system that also loads the user's profile by default.  Should we
remove this so that profiles are only loaded once?

Best,
-- 
Josselin Poiret


signature.asc
Description: PGP signature

bug#63451: Guix pull not successful

[a]

sure. I just did a btrfs scrub which didnt find anything (not sure if
things have fixed themselves day to day though). i also did guix gc
--verify which did not report anything.

if the error is possibly filesystem related - i did disable my btrfs
compression earlier that day since it was performing badly.

On Sun, May 14, 2023 at 9:03 AM Csepp  wrote:

>
> a  writes:
>
> > first, i i ran guix pull and this happened.
> > i don't see anything in my kernel logs around this time
> >
> > λ ~ guix pull
> [1259]
> > Updating channel 'guix' from Git repository at '
> https://git.savannah.gnu.org/git/guix.git'...
> > Authenticating channel 'guix', commits 9edb3f6 to d6f6b57 (667 new
> commits)...
> > Building from this channel:
> >   guix  https://git.savannah.gnu.org/git/guix.git   d6f6b57
> > substitute: updating substitutes from 'https://ci.guix.gnu.org'...
> 100.0%
> > substitute: updating substitutes from 'https://bordeaux.guix.gnu.org'...
> 100.0%
> > building
> /gnu/store/kxhxsxmann4jv6z62z0ssh011sahk88k-compute-guix-derivation.drv...
> > Computing Guix derivation for 'x86_64-linux'... /warning:
> 'texlive-latex-tools' is deprecated, use 'texlive-tools' instead
> > warning: 'texlive-latex-graphics' is deprecated, use 'texlive-graphics'
> instead
> > warning: 'texlive-generic-etexcmds' is deprecated, use
> 'texlive-etexcmds' instead
> > warning: 'texlive-generic-infwarerr' is deprecated, use
> 'texlive-infwarerr' instead
> > warning: 'texlive-latex-graphics' is deprecated, use 'texlive-graphics'
> instead
> > warning: 'texlive-latex-graphics' is deprecated, use 'texlive-graphics'
> instead
> > warning: 'texlive-generic-atbegshi' is deprecated, use
> 'texlive-atbegshi' instead
> > warning: 'texlive-latex-atveryend' is deprecated, use
> 'texlive-atveryend' instead
> > \Backtrace:
> > In ice-9/boot-9.scm:
> >222:29 19 (map1 (# (#) # x>) # ?))
> >222:29 18 (map1 (# (#) # x>) (# ()))> # ?))
> >222:17 17 (map1 (# sanitize-location> (# ?))
> > In ice-9/psyntax.scm:
> > Exception thrown while printing backtrace:
> > Wrong type to apply: 129
> >
> > ice-9/boot-9.scm:3165:6: In procedure module-gensym:
> > Invalid read access of chars of wide string: "m-1bcbf699e1749862-28a08"
>
> This looks very weird, could you run a disk check and a guix store check
> just to be safe?
>

bug#63198: cups-service-type uses PAM-enabled 'cups' by default which prevents authentication

[Maxim Cournoyer]

Hi,

muradm  writes:

> Fixes .
>
> Makes CUPS service to extend pam-root-service-type providing minimal
> configuration to authenticate users. Since PAM authentication is
> provided, cups package can be used as default.
>
> * gnu/services/cups.scm (cups-configuration) [cups]: Use cups.

I'd write 'Replace cups-minimal with cups'.

> [allow-empty-password?]: PAM service configuration permitting empty passwords.

I'd write 'New field', but I think we'd want to add proper PAM support
here not a 'bypass PAM authentication' hack.  It should also be enabled
out of the box, otherwise users won't be able to authenticate until they
figure out they need to set that switch to #t.

> (opaque-cups-configuration): Likewise.
> (cups-pam-service): cups PAM service.

Not descriptive :-)  What is the change here?

Could you look into adding "regular" login PAM support instead of a
bypass disabled by default?  The user should still be prompted for its
password, and it should go through the PAM auth module.

I'm not very PAM-aware, but I believe there are examples spread in the
code base.

-- 
Thanks,
Maxim

bug#63198: cups-service-type uses PAM-enabled 'cups' by default which prevents authentication

[Maxim Cournoyer]

Hi,

muradm  writes:

> This change broke cups for me like this:
>
> I [13/May/2023:16:14:27 +0300] [Client 16] Started 
> "/gnu/store/9kdm8k84j2xqlax4zaarchw00cfs62zz-cups-server-bin/lib/cups/daemon/cups-deviced"
>  
> (pid=21409, file=14)
> E [13/May/2023:16:14:27 +0300] [CGI] cups-brf must be called as 
> root
> E [13/May/2023:16:14:27 +0300] [cups-deviced] PID 21419 (cups-brf) 
> stopped with status 1!
> E [13/May/2023:16:14:27 +0300] [CGI] Unable to execute ippfind 
> utility: No such file or directory
> E [13/May/2023:16:14:27 +0300] [cups-deviced] PID 21421 
> (driverless-fax) stopped with status 127!
>
> cups-minimal does not include ippfind utility.
>
> Normally, user whishing to use cups, should be in lp group, isn't 
> it?
> Maybe that was your original issue?

No, as I tested adding my user to the lpr group without success.

-- 
Thanks,
Maxim

bug#63198: cups-service-type uses PAM-enabled 'cups' by default which prevents authentication

[Maxim Cournoyer]

Hi,

muradm  writes:

> Could you please elaborate more on "loop on authenticating my user"
> from above and "prevents users from authenticating" from commit
> message? Does it mean that you could not authenticate as your user
> at all, or does it relates to authentication at http://localhost:631
> for managing printers?

The later (could not authenticate with CUPS for say, adding a printer).

-- 
Thanks,
Maxim

bug#63274: [PATCH] gnu: dia: Update to 0.97.3-4.b903dd8

[Giovanni Biscuolo]

Hello,

gentle ping (and I forgot to Cc: the gnome team)

Thanks! Gio'

Giovanni Biscuolo  writes:

[...]

-- 
Giovanni Biscuolo

Xelera IT Infrastructures


signature.asc
Description: PGP signature

bug#20255: 'search-paths' should respect both user and system profile.

[Maxim Cournoyer]

Hi,

宋文武  writes:

> Hello, commit 40310efde9b4a4f2cf98081d6cd10f843685ebb6 fix this by merge
> search-paths from multiple profiles by `guix package --search-paths`, in
> ~/.bashrc and ~/.zprofile (skeletons, so existed systems need manual
> update).  
>
>
> Close now!

Cool, thanks for the update.  Perhaps a NEWS entry would be useful to
keep Guix System existing users in the loop?  Until we have a better
mechanism/approach to these stateful files that don't change past the
original installation.

-- 
Thanks,
Maxim

bug#63261: Recent changes to git config cause errors for non-committers

[Maxim Cournoyer]

Hi Leo,

Leo Famulari  writes:

> Can someone help me by pointing to the original discussion of this
> change?

It was the team.scm issue in https://issues.guix.gnu.org/58813 that led
to this change.

-- 
Thanks,
Maxim

bug#63514: alacritty>=0.12.0 does not work with Wayland

[Efraim Flashner]

On Mon, May 15, 2023 at 09:18:01AM +0200, Lars-Dominik Braun wrote:
> Hi Efraim,
> 
> since the upgrade from alacritty 0.9 to 0.12 it does not work any more
> with the DISPLAY environment variable unset (i.e. without xwayland). The
> error message is:
> 
> thread 'main' panicked at 'Failed to initialize any backend! Wayland status: 
> NoWaylandLib X11 status: XOpenDisplayFailed', 
> /tmp/guix-build-alacritty-0.12.0.drv-0/source/guix-vendor/rust-winit-0.28.3.tar.gz/src/platform_impl/linux/mod.rs:757:9
> 
> Could you have a look?

This should now be fixed, feel free to re-open if its still not working
for you.

(ins)efraim@3900XT ~/workspace/guix$ ./pre-inst-env guix shell alacritty
(ins)efraim@3900XT ~/workspace/guix [env]$ DISPLAY="" alacritty
warning: queue 0x7f40bcc0 destroyed while proxies still attached:
  zwp_primary_selection_offer_v1@4278190081 still attached
  wl_data_offer@4278190080 still attached
  zwp_primary_selection_device_v1@29 still attached
  zwp_primary_selection_device_manager_v1@21 still attached
  wl_data_device@28 still attached
  wl_seat@27 still attached
  wl_data_device_manager@25 still attached
  wl_registry@20 still attached
warning: queue 0x55d2489cbe70 destroyed while proxies still attached:
  wl_shm_pool@40 still attached
  xdg_wm_base@32 still attached
  wl_output@15 still attached
  wl_output@14 still attached
  wl_seat@13 still attached
  xdg_activation_v1@12 still attached
  wp_viewporter@11 still attached
  zwp_text_input_manager_v3@10 still attached
  zwp_pointer_constraints_v1@9 still attached
  zwp_relative_pointer_manager_v1@8 still attached
  zxdg_decoration_manager_v1@7 still attached
  wl_subcompositor@6 still attached
  wl_compositor@5 still attached
  wl_shm@4 still attached
  wl_registry@2 still attached
warning: queue 0x55d2489fbe80 destroyed while proxies still attached:
  wl_callback@45 still attached


-- 
Efraim Flashner  פלשנר אפרים
GPG key = A28B F40C 3E55 1372 662D  14F7 41AA E7DC CA3D 8351
Confidentiality cannot be guaranteed on emails sent or received unencrypted


signature.asc
Description: PGP signature

bug#63516: Static networking should wait for interfaces to be up

[Ludovic Courtès]

Hi!

With shepherd 0.10.0 starting services in parallel, I observed
‘networking’ (from ‘static-networking-service-type’) starting too early,
before the corresponding interfaces were available:

--8<---cut here---start->8---
[   21.863249] shepherd[1]: Service udev started.
[   21.863414] shepherd[1]: Service udev running with value 196.
[   21.865686] shepherd[1]: Starting service networking...
[   21.865822] shepherd[1]: Starting service file-system-/boot/efi...
[   21.986025] shepherd[1]: Exception caught while starting #< 
7f9bf08434e0>: (no-such-device "eno1"
[   22.738237] udevd[196]: starting eudev-3.2.11
[   22.767830] udevd[196]: no sender credentials received, message ignored

[...]

[   23.562275] tg3 :05:00.0 eth0: Tigon3 [partno(BCM95720) rev 572] 
(PCI Express) MAC address b8:cb:2
[   23.562290] tg3 :05:00.0 eth0: attached PHY is 5720C (10/100/1000Base-T 
Ethernet) (WireSpeed[1], EEE[1
[   23.562298] tg3 :05:00.0 eth0: RXcsums[1] LinkChgREG[0] MIirq[0] ASF[1] 
TSOcap[1]
[   23.562305] tg3 :05:00.0 eth0: dma_rwctrl[0001] dma_mask[64-bit]
[   23.596221] tg3 :05:00.1 eth1: Tigon3 [partno(BCM95720) rev 572] 
(PCI Express) MAC address b8:cb:2
[   23.596234] tg3 :05:00.1 eth1: attached PHY is 5720C (10/100/1000Base-T 
Ethernet) (WireSpeed[1], EEE[1
[   23.596242] tg3 :05:00.1 eth1: RXcsums[1] LinkChgREG[0] MIirq[0] ASF[1] 
TSOcap[1]
[   23.596249] tg3 :05:00.1 eth1: dma_rwctrl[0001] dma_mask[64-bit]
[   23.599725] tg3 :05:00.0 eno1: renamed from eth0
[   23.613468] iTCO_vendor_support: vendor-support=0
[   23.619114] iTCO_wdt iTCO_wdt: Found a Intel PCH TCO device (Version=6, 
TCOBASE=0x0400)
[   23.619327] iTCO_wdt iTCO_wdt: initialized. heartbeat=30 sec (nowayout=0)
[   23.645196] tg3 :05:00.1 eno2: renamed from eth1
[   23.727153] Error: Driver 'pcspkr' is already registered, aborting...
[   23.738237] ipmi_si dmi-ipmi-si.0: Removing SMBIOS-specified kcs state 
machine in favor of ACPI
[   23.738239] ipmi_si: Adding ACPI-specified kcs state machine
[   23.738273] ipmi_si: Trying ACPI-specified kcs state machine at i/o address 
0xca8, slave address 0x20, irq
[   23.926348] shepherd[1]: Service file-system-/boot/efi has been started.
[   23.927164] shepherd[1]: Service networking failed to start.
--8<---cut here---end--->8---

Before doing ‘addr-add’ in ‘network-set-up/linux’, should we wait for
the interface to show up, by calling ‘get-links’ from Guile-Netlink or
something like that?

Ludo’.

bug#63514: alacritty>=0.12.0 does not work with Wayland

[Efraim Flashner]

On Mon, May 15, 2023 at 11:07:50AM +0200, Lars-Dominik Braun wrote:
> Hi,
> 
> > easy reproducer: 'DISPLAY="" alacritty' gives the same error.
> 
> that’s exactly what I used under Wayland, otherwise it’ll fall back
> to XWayland with ugly font rendering (because of my hidpi monitor).
> 
> > Do you know if the X11 error is also a problem?
> 
> Not sure what you mean. As I wrote it works with XWayland, so I’m
> guessing X11 is not broken.

I parsed the error like this:

(ins)efraim@3900XT ~$ DISPLAY="" alacritty
thread 'main' panicked at 'Failed to initialize any backend! Wayland status: 
NoWaylandLib X11 status: XOpenDisplayFailed', 
/tmp/guix-build-alacritty-0.12.0.drv-0/source/guix-vendor/rust-winit-0.28.3.tar.gz/src/platform_impl/linux/mod.rs:757:9
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace


(ins)efraim@3900XT ~$ DISPLAY="" alacritty
thread 'main' panicked at 'Failed to initialize any backend! Wayland status: 
NoWaylandLib
(no wayland library found!)

X11 status: XOpenDisplayFailed', 
/tmp/guix-build-alacritty-0.12.0.drv-0/source/guix-vendor/rust-winit-0.28.3.tar.gz/src/platform_impl/linux/mod.rs:757:9
(something something XOpenDislay failed! with that source location)

note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

> Thank you,
> Lars
> 

One bug per bug report :)

> PS: What *is* entirely broken is swaylock, which also got updated
> recently:
> 
> wl_registry@2: error 0: invalid version for global wl_output (39): have 3, 
> wanted 4
> 



-- 
Efraim Flashner  פלשנר אפרים
GPG key = A28B F40C 3E55 1372 662D  14F7 41AA E7DC CA3D 8351
Confidentiality cannot be guaranteed on emails sent or received unencrypted


signature.asc
Description: PGP signature

bug#63514: alacritty>=0.12.0 does not work with Wayland

[Lars-Dominik Braun]

Hi,

> easy reproducer: 'DISPLAY="" alacritty' gives the same error.

that’s exactly what I used under Wayland, otherwise it’ll fall back
to XWayland with ugly font rendering (because of my hidpi monitor).

> Do you know if the X11 error is also a problem?

Not sure what you mean. As I wrote it works with XWayland, so I’m
guessing X11 is not broken.

Thank you,
Lars

PS: What *is* entirely broken is swaylock, which also got updated
recently:

wl_registry@2: error 0: invalid version for global wl_output (39): have 3, 
wanted 4



signature.asc
Description: PGP signature

bug#63514: alacritty>=0.12.0 does not work with Wayland

[Efraim Flashner]

On Mon, May 15, 2023 at 09:18:01AM +0200, Lars-Dominik Braun wrote:
> Hi Efraim,
> 
> since the upgrade from alacritty 0.9 to 0.12 it does not work any more
> with the DISPLAY environment variable unset (i.e. without xwayland). The
> error message is:
> 
> thread 'main' panicked at 'Failed to initialize any backend! Wayland status: 
> NoWaylandLib X11 status: XOpenDisplayFailed', 
> /tmp/guix-build-alacritty-0.12.0.drv-0/source/guix-vendor/rust-winit-0.28.3.tar.gz/src/platform_impl/linux/mod.rs:757:9
> 
> Could you have a look?

That's certainly annoying. I'll take a look and see if I can find a good
way to fix that.

easy reproducer: 'DISPLAY="" alacritty' gives the same error.

Do you know if the X11 error is also a problem?

-- 
Efraim Flashner  פלשנר אפרים
GPG key = A28B F40C 3E55 1372 662D  14F7 41AA E7DC CA3D 8351
Confidentiality cannot be guaranteed on emails sent or received unencrypted


signature.asc
Description: PGP signature

bug#63514: alacritty>=0.12.0 does not work with Wayland

[Lars-Dominik Braun]

Hi Efraim,

since the upgrade from alacritty 0.9 to 0.12 it does not work any more
with the DISPLAY environment variable unset (i.e. without xwayland). The
error message is:

thread 'main' panicked at 'Failed to initialize any backend! Wayland status: 
NoWaylandLib X11 status: XOpenDisplayFailed', 
/tmp/guix-build-alacritty-0.12.0.drv-0/source/guix-vendor/rust-winit-0.28.3.tar.gz/src/platform_impl/linux/mod.rs:757:9

Could you have a look?

Thanks,
Lars



signature.asc
Description: PGP signature