bug#52029: wterm fails to start on core-updates-frozen

[Joshua Branson via Bug reports for GNU Guix]

Jack Hill  writes:

> Hi Guix,
>
> wterm fails to start on the core-updates-frozen branch (commit
> ddbc3a6f4ca2605d8102aa659389300f97d715ac) in both sway and gnome wayland
> sessions:
>
> ```
> $ wterm
> wl_registry@2: error 0: invalid interface for global 11: have xdg_wm_base, 
> wanted zxdg_shell_v6
> # wayland_create_context: No wl_drm global
> # wayland_create_context: No wl_shm global
> # wld_wayland_create_context: Could not initialize any of the specified 
> implementations
> Can't create wayland context
> ```
>
> However, wterm seems to be unmaintained upstream [0], so maybe this is not
> somethint that we want to fix in Guix.

I vote that we remove wterm from guix.  It is still unmaintained at the
github link below.  And it doesn't ever run properly.


> [0] https://github.com/majestrate/wterm/issues/24
>
> Best,
> Jack

bug#55657: libgccjit is unusable

[Andrew Whatson]

On Thu, 4 Aug 2022 at 16:52, Liliana Marie Prikler
 wrote:
>
> > The solution used in the package-definition in my channel is to patch
> > `comp.el` to directly reference the necessary gcc/glibc paths instead
> > of relying on the environment.  This occurs in the
> > "patch-driver-options" step immediately after the "set-libgccjit-
> > path" step mentioned earlier.  This makes gcc-toolchain part of emacs
> > closure, without requiring it to be propagated into the profile.
> >
> > If I understand the problem correctly, that should suffice?
>
> But if I read your recipe correctly, you're not resolving %host-type in
> those options.  Does that really suffice?

Ah, yes that is a little confusing.  This is a quirk of the different
behaviour of the LIBRARY_PATH environment variable and the -B flag to
gcc.

I recommend reading about "-Bprefix" in `man gcc`, but in short it
tries those paths with and without "machine/version" appended for the
target machine and compiler version.  We *could* hard-code those, but
it isn't necessary, and it seemed like that might cause problems if
someone's brave enough to attempt cross-compilation of native-comp
emacs.

A major benefit of patching "comp.el" directly is that it avoids
leaking gcc into the user's environment.  It's possible that someone
is running emacs in a profile with a specific version of gcc, maybe
without libgccjit support (eg. while hacking on some legacy code), so
having emacs insist on a libgccjit-compatible gcc present in the
environment at runtime would cause lots of problems.

The other important bit is the libgccjit package.  The one in guix
mainline works fine, it should be possible to get a working libgccjit
as-is.  I updated the package definition on my channel for the
following reasons:

a) Support newer gcc versions

While developing native-comp support for emacs, Andrea found and fixed
some libgccjit bugs which made their way into subsequent releases of
gcc.  The native-comp library includes work-arounds for these
problems, but produces faster/smaller code with a fresher libgccjit.

b) Reduce compilation time

The definition in guix is basically the standard gcc build, but with
libgccjit also enabled.  This results in an arduous double-bootstrap
and building a bunch of compilers and libraries that are completely
unnecessary and unused by libgccjit.  I've disabled all the
unnecessary stuff and depend on the main gcc package to build
libgccjit, relying on the fact that it's already properly
bootstrapped.  It's much quicker to build, which is important if you
don't have substitutes.

Hope this helps,
Andrew

bug#48393: Can't build installer on aarch64 / v86d fails to build on aarch64

[Pavel Shlyak]

This one is done with https://issues.guix.gnu.org/55806. I suggest closing it 
as resolved.

bug#41120: uvesafb service is unsupported on aarch64

[Pavel Shlyak]

This one is done with https://issues.guix.gnu.org/55806. I suggest closing it 
as resolved.

bug#56680: go-1.16.15 build fails in check phase on powerpc64le

[Efraim Flashner]

On Thu, Aug 04, 2022 at 11:02:53PM +0200, Marcel van der Boom wrote:
> 
> [Efraim Flashner]:
> > I'm currently working on bootstrapping go-1.17.11 directly from gccgo,
> > so we'd be able to skip 1.16 entirely. Currently it works on
> > x86_64-linux but not on riscv64-linux. If you want to test something
> > like that on powerpc64le that'd be great.
> 
> Sure, can you point me in the right direction and get me started on what
> would be useful for you?

Looking at the package definitions for go it looks like the inputs and
native-inputs need to be cleaned up some, but for our purposes I think
just removing the native-inputs field completely from 1.17 should try to
make go-1.17 build with gccgo. Then try to build go@1.17.

-- 
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#56680: go-1.16.15 build fails in check phase on powerpc64le

[Marcel van der Boom]

[Efraim Flashner]:
I'm currently working on bootstrapping go-1.17.11 directly from 
gccgo,

so we'd be able to skip 1.16 entirely. Currently it works on
x86_64-linux but not on riscv64-linux. If you want to test 
something

like that on powerpc64le that'd be great.


Sure, can you point me in the right direction and get me started 
on what would be useful for you?


signature.asc
Description: PGP signature

bug#56958: auto login to tty only works for tty1

[Joshua Allen Branson via Bug reports for GNU Guix]

Joshua Branson  writes:

> Hey guix family!

Hey Leo, you helped me create this cookbook guide initially.  I thought
you deserve to know that auto-login to tty is not working like it used
to.  I am not asking you to drop everything and fix this.  Instead I am
just letting other interested parties know.

Thanks!

Joshua

>
> The cookbook decribes a method of auto login to tty. I have noticed that since
> the latest shepherd upgrade (that's my best guess as to when the error 
> occured),
> I have been unable to auto login to any tty as the cookbook describes. I have
> created a minimal guix system vm, to test the auto-login to tty. I have set up
> ttys 2 - 4 to auto login my user joshua, but when I boot the vm only tty1 is
> auto logged in. The other tty's are not logged in.  Is auto login supposed to 
> be
> restricted to one partiular tty?
>
> Thanks,
>
> Joshua
>
> P.S.  Here is the test vm.
>
> #+BEGIN_SRC shell :dir ~/prog/gnu/guix/guix-config  :results verbatim 
> :exports both
> cat bare-bones-with-autologin.scm
> #+END_SRC
>
>
> #+RESULTS:
>
> #+begin_example
> ;; Copyright © 2021, 2022 Joshua Branson 
>
> (use-modules (gnu))
>
> (use-service-modules networking
>  ssh)
>
> (use-package-modules ssh)
>
> (define (auto-login-to-tty config tty user)
>   (if (string=? tty (mingetty-configuration-tty config))
>   (mingetty-configuration
>(inherit config)
>(auto-login user))
>   config))
>
> ;; add an autologin to tty for a tty 2 - 4.
> ;; When you run this vm, only one will be auto-logged in.
> (define %my-base-services
>(modify-services %base-services
> (mingetty-service-type config =>
>(auto-login-to-tty config "tty1" "joshua"))
> (mingetty-service-type config =>
>(auto-login-to-tty config "tty2" "joshua"))
> (mingetty-service-type config =>
>(auto-login-to-tty config "tty3" "joshua"))
> (mingetty-service-type config =>
>(auto-login-to-tty config "tty4" "joshua"
>
> (operating-system
>   (host-name "autologin")
>   (timezone "America/Indianapolis")
>   (locale "en_US.utf8")
>   (bootloader (bootloader-configuration
>(bootloader grub-bootloader)
>(targets (list "/dev/sda"
>   (file-systems
>(cons*
> (file-system
>  (mount-point "/")
>  (device "/dev/sda")
>  (type "ext4"))
> %base-file-systems))
>
>   (users (cons* (user-account
>  (name "joshua")
>  (comment "Joshua Branson")
>  (group "users")
>  (home-directory "/home/joshua")
>  (supplementary-groups
>   '("kvm" "netdev" "wheel")))
> %base-user-accounts))
>
>   (packages %base-packages)
>   ;; Add services to the baseline: a DHCP client and
>   ;; an SSH server.
>   (services
>(cons*
> (service dhcp-client-service-type)
> (service openssh-service-type
>  (openssh-configuration
>   (openssh openssh-sans-x)
>   (port-number )))
> %my-base-services)))
> #+end_example
>
>
> To try it for yourself:
>
> #+BEGIN_SRC shell
> $(guix system vm bare-bones-with-autologin.scm)
> #+END_SRC
>
> Ctrl-Alt-G (make sure Ctrl and Alt are the left most keys) to grab focus
> inside the vm. Alt-right to switch to a different console. Ctrl-Alt-G to
> ungrab focus from the vm.

bug#54691: fortune-mod propagates various non-nice things

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

Hi Liliana,

Liliana Marie Prikler 写道：

I'm not saying either option is worse than the other


I see; thanks for the clarification.

Then I *will* say that transparently upgrading to a package that 
does nothing is worse than simple removal.


In fact, all of the proposed hacks are…

Kind regards,

T G-R


signature.asc
Description: PGP signature

bug#56680: go-1.16.15 build fails in check phase on powerpc64le

[Efraim Flashner]

On Thu, Aug 04, 2022 at 06:24:47PM +0200, Marcel van der Boom wrote:
> 
> I see that the full build log expired on the paste site.
> 
> Is any additional info needed here, other than the excerpt of the log?
> 
> I suspect the check error is a safety precaution to ensure executables are
> of reasonable size, but reasonable is perhaps a bit different on the POWER9
> platform?

I'm currently working on bootstrapping go-1.17.11 directly from gccgo,
so we'd be able to skip 1.16 entirely. Currently it works on
x86_64-linux but not on riscv64-linux. If you want to test something
like that on powerpc64le that'd be great.

-- 
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#54691: fortune-mod propagates various non-nice things

[Liliana Marie Prikler]

Am Donnerstag, dem 04.08.2022 um 15:37 + schrieb Tobias Geerinckx-
Rice:
> > To me use of ‘deprecated-package’ in this case is just to ensure
> > that users who run ‘guix upgrade’ will transparently get
> > ‘fortune-jkirchartz’.  I don’t have a strong opinion though.
> 
> I believe what Liliana meant is that it's worse to 'transparently'
> upgrade to a data package that doesn't provide the 'fortune' command
> at all (or conversely, an implementation of the command that doesn't
> propagate the actual fortune data), than it is to signal to users
> through an error message that something's up and they need to stop
> and think.
> 
> (Er, that's a lot more words to put in someone's mouth than I
> intended to, sorry :-)
I'm not saying either option is worse than the other, just that we
can't pick both in a manner that provides a functioning package, and
that transparently upgrading to a package that does nothing is a pretty
bad option.  We could transparently upgrade to daikichi, but that'd
just say "no fortunes found" because FORTUNE_PATH will be empty.  Other
options would include a metapackage (also rejected by Maxime) or
providing a dummy fortune-mod package that fails at build with a
helpful message and is disabled in CI (came up as a shower thought).

Cheers

bug#55657: libgccjit is unusable

[Liliana Marie Prikler]

Am Donnerstag, dem 04.08.2022 um 04:48 + schrieb Andrew Whatson:
> Hi John, Liliana,
> 
> Sorry I haven't jumped in before now, I appreciate your efforts to
> bring emacs native-comp to guix!
> 
> On Thu, 4 Aug 2022 at 04:26, Liliana Marie Prikler
>  wrote:
> > 
> > while this does help insofar as I now know which snippet I forgot
> > to
> > copy, I do still think that this leaves us with two unreasonable
> > options if we want to use emacs to compile other packages:
> > 
> > 1. Propagate gcc-toolchain from emacs.
> > 2. Patch LIBRARY_PATH not just before configuration, but also via a
> > wrapper.
> > 
> > At the very least I don't see how Emacs would be able to compile
> > other
> > packages to native code without either of the above.
> > 
> > WDYT?
> 
> The solution used in the package-definition in my channel is to patch
> `comp.el` to directly reference the necessary gcc/glibc paths instead
> of relying on the environment.  This occurs in the
> "patch-driver-options" step immediately after the "set-libgccjit-
> path" step mentioned earlier.  This makes gcc-toolchain part of emacs
> closure, without requiring it to be propagated into the profile.
> 
> If I understand the problem correctly, that should suffice?
But if I read your recipe correctly, you're not resolving %host-type in
those options.  Does that really suffice?

bug#56680: go-1.16.15 build fails in check phase on powerpc64le

[Marcel van der Boom]

I see that the full build log expired on the paste site.

Is any additional info needed here, other than the excerpt of the 
log?


I suspect the check error is a safety precaution to ensure 
executables are of reasonable size, but reasonable is perhaps a 
bit different on the POWER9 platform?

bug#56005: [bug#56867] [PATCH] download: Do not wrap TLS port on GnuTLS >= 3.7.7.

[Ludovic Courtès]

Hi,

Thiago Jung Bauermann  skribis:

> Ludovic Courtès  writes:
>
>> First, I noticed that GnuTLS doesn’t implement ‘write_wait_fd’, only
>> ‘read_wait_fd’ (not sure how problematic that is):
>>
>> scheme@(guile-user)> ,use(web client)
>> scheme@(guile-user)> (define p (open-socket-for-uri "https://guix.gnu.org;))
>> scheme@(guile-user)> ((@@ (ice-9 suspendable-ports) wait-for-writable) p)
>> ice-9/boot-9.scm:1685:16: In procedure raise-exception:
>> In procedure write_wait_fd: unimplemented
>>
>> Entering a new prompt.  Type `,bt' for a backtrace or `,q' to continue.
>> scheme@(guile-user) [1]> ,q
>> scheme@(guile-user)> ,use(gnutls)
>> scheme@(guile-user)> (gnutls-version)
>> $1 = "3.7.7"
>> scheme@(guile-user)> ((@@ (ice-9 suspendable-ports) wait-for-readable) p)
>> $2 = 1
>
> This occasionally causes problems when fetching substitutes, as can be
> seen in bug #56005 (during substitution: write_wait_fd: unimplemented).

Oh, I have not seen it but it’s weird: (guix scripts substitute) doesn’t
use O_NONBLOCK sockets, so I don’t get how it can hit that.  Needs
investigation…

Thanks,
Ludo’.

bug#56980: "corrupt input while restoring [...] from [...]" when it's just a network timeout

[Maxime Devos]

X-Debbugs-CC: 55...@debbugs.gnu.org

Hi,

I recently got the following output:

substitutie van 
/gnu/store/yzswm5i0l0rvc01lfkb5z5lz4a85p6z8-rust-proc-macro-error-attr-1.0.4-lib 
is klaar
/gnu/store/zi1yc0fmq7yi564sv23h13qc97s445bb-rust-prost-derive-0.9.0-lib 
vervangen...
guix substitute: waarschuwing: tijdens het binnenhalen van 
https://ci.guix.gnu.org/nar/lzip/6p12gnwvfmqbfhdhcak71dcwkgd10ir7-rust-codespan-reporting-0.11.0-[..]
guix substitute: waarschuwing: probeer ‘--no-substitutes’ als het 
probleem hardnekkig is

guix substitute: fout: connect*: Verbinding is verlopen
vervanging van 
/gnu/store/6p12gnwvfmqbfhdhcak71dcwkgd10ir7-rust-codespan-reporting-0.11.0-lib 
mislukt
guix build: fout: beschadigde invoer tijdens het terugplaatsen van het 
archief uit #


i.e.:

guix substitute: warning: while fetching ~a: server is somewhat slow~%
guix substitute: warning: try `--no-substitutes' if the problem persists~%
guix substitute: error: connect*: Connection timed out
substitution of ~a failed
guix build: error: corrupt input while restoring archive from ~s~%"

Two remarks:

 * I don't think a timeout counts as "corrupted", "corrupted" sounds
   like a bit flip or such happened or that there is a bug in the nix
   archive code that causes the archive to be (non-deterministically?)
   misparsed.
 * The name of the procedure 'connect*' sounds like an implementation
   detail, could the error message be changed to plainly state it's
   just a timeout?

Maybe a duplicate of .

Possibly the same issue as ?

Greetings,
Maxime



OpenPGP_0x49E3EE22191725EE.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

bug#54691: fortune-mod propagates various non-nice things

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

>To me use of ‘deprecated-package’ in this case is just to ensure that
>users who run ‘guix upgrade’ will transparently get
>‘fortune-jkirchartz’.  I don’t have a strong opinion though.

I believe what Liliana meant is that it's worse to 'transparently' upgrade to a 
data package that doesn't provide the 'fortune' command at all (or conversely, 
an implementation of the command that doesn't propagate the actual fortune 
data), than it is to signal to users through an error message that something's 
up and they need to stop and think.

(Er, that's a lot more words to put in someone's mouth than I intended to, 
sorry :-)

I'd suggest a news item but I really don't think this warrants it.

Kind regards,

T G-R

Sent on the go.  Excuse or enjoy my brevity.

bug#56978: Website monitoring

[Csepp]

In light of 56954 and various similar issues, it might be a good idea so
set up monitoring for the website, so links that return errors are
caught early.  Since they are all static sites as far as I know, this
should be pretty easy with something like wget --spider.

bug#56005: [bug#56867] [PATCH] download: Do not wrap TLS port on GnuTLS >= 3.7.7.

[Thiago Jung Bauermann via Bug reports for GNU Guix]

Hello Ludo,

I don't have any comment/insight on what you're doing in general, except
about one of your points below:

Ludovic Courtès  writes:

> First, I noticed that GnuTLS doesn’t implement ‘write_wait_fd’, only
> ‘read_wait_fd’ (not sure how problematic that is):
>
> scheme@(guile-user)> ,use(web client)
> scheme@(guile-user)> (define p (open-socket-for-uri "https://guix.gnu.org;))
> scheme@(guile-user)> ((@@ (ice-9 suspendable-ports) wait-for-writable) p)
> ice-9/boot-9.scm:1685:16: In procedure raise-exception:
> In procedure write_wait_fd: unimplemented
>
> Entering a new prompt.  Type `,bt' for a backtrace or `,q' to continue.
> scheme@(guile-user) [1]> ,q
> scheme@(guile-user)> ,use(gnutls)
> scheme@(guile-user)> (gnutls-version)
> $1 = "3.7.7"
> scheme@(guile-user)> ((@@ (ice-9 suspendable-ports) wait-for-readable) p)
> $2 = 1

This occasionally causes problems when fetching substitutes, as can be
seen in bug #56005 (during substitution: write_wait_fd: unimplemented).

-- 
Thanks
Thiago

bug#56900: phoronix-test-suite downloads nonfree software (+ question on collaboration with Parabola on this package)

[Denis 'GNUtoo' Carikli]

On Tue, 02 Aug 2022 22:28:56 -0400
Maxim Cournoyer  wrote:

> Hi Denis,
Hi,

> Would you like to try preparing a snippet patch turning the above
> 'Free' into 'Proprietary' or the likes so that the Python script can
> remove them?  Otherwise I can look into it.
Since you wrote the python script you might be way faster if you do it.

By the way I've found new issues: 
- phoronix-test-suite test system/gnupg => This downloads
  linux-4.3.tar.gz, so it has the same issue.
- phoronix-test-suite test pts/gnupg => This downloads
  ubuntu-20.04-desktop-amd64.iso so it has the same issue because
  ubuntu-20.04-desktop-amd64.iso probably contains nonfree firmwares.

Denis.


pgpDMkZLVUMRN.pgp
Description: OpenPGP digital signature

bug#55657: libgccjit is unusable

[Andrew Whatson]

Hi John, Liliana,

Sorry I haven't jumped in before now, I appreciate your efforts to
bring emacs native-comp to guix!

On Thu, 4 Aug 2022 at 04:26, Liliana Marie Prikler
 wrote:
>
> while this does help insofar as I now know which snippet I forgot to
> copy, I do still think that this leaves us with two unreasonable
> options if we want to use emacs to compile other packages:
>
> 1. Propagate gcc-toolchain from emacs.
> 2. Patch LIBRARY_PATH not just before configuration, but also via a
> wrapper.
>
> At the very least I don't see how Emacs would be able to compile other
> packages to native code without either of the above.
>
> WDYT?

The solution used in the package-definition in my channel is to patch
`comp.el` to directly reference the necessary gcc/glibc paths instead
of relying on the environment.  This occurs in the
"patch-driver-options" step immediately after the "set-libgccjit-path"
step mentioned earlier.  This makes gcc-toolchain part of emacs
closure, without requiring it to be propagated into the profile.

If I understand the problem correctly, that should suffice?

Cheers,
Andrew

bug#56965: wterm does not work on sway

[Joshua Branson via Bug reports for GNU Guix]

wterm is said to be a simple terminal for wayland:

#+BEGIN_SRC shell  :results: raw
guix show wterm | recsel -p synopsis
#+END_SRC

#+RESULTS:
: synopsis: Terminal emulator for Wayland

Well, when I try to use it, I get the following error on sway.  wterm
does not start.

joshua@crazyhorse ~ (master)> wterm 
wl_drm@11: error 0: authenticate failed
# wayland_create_context: DRM authentication failed
# wayland_create_context: No wl_shm global
# wld_wayland_create_context: Could not initialize any of the specified 
implementations
Can't create wayland context


Thanks,

Joshua

bug#56958: auto login to tty only works for tty1

[Joshua Branson via Bug reports for GNU Guix]

Hey guix family!

The cookbook decribes a method of auto login to tty. I have noticed that since
the latest shepherd upgrade (that's my best guess as to when the error occured),
I have been unable to auto login to any tty as the cookbook describes. I have
created a minimal guix system vm, to test the auto-login to tty. I have set up
ttys 2 - 4 to auto login my user joshua, but when I boot the vm only tty1 is
auto logged in. The other tty's are not logged in.  Is auto login supposed to be
restricted to one partiular tty?

Thanks,

Joshua

P.S.  Here is the test vm.

#+BEGIN_SRC shell :dir ~/prog/gnu/guix/guix-config  :results verbatim :exports 
both
cat bare-bones-with-autologin.scm
#+END_SRC

#+RESULTS:
#+begin_example
;; Copyright © 2021, 2022 Joshua Branson 

(use-modules (gnu))

(use-service-modules networking
 ssh)

(use-package-modules ssh)

(define (auto-login-to-tty config tty user)
  (if (string=? tty (mingetty-configuration-tty config))
  (mingetty-configuration
   (inherit config)
   (auto-login user))
  config))

;; add an autologin to tty for a tty 2 - 4.
;; When you run this vm, only one will be auto-logged in.
(define %my-base-services
   (modify-services %base-services
(mingetty-service-type config =>
   (auto-login-to-tty config "tty1" "joshua"))
(mingetty-service-type config =>
   (auto-login-to-tty config "tty2" "joshua"))
(mingetty-service-type config =>
   (auto-login-to-tty config "tty3" "joshua"))
(mingetty-service-type config =>
   (auto-login-to-tty config "tty4" "joshua"

(operating-system
  (host-name "autologin")
  (timezone "America/Indianapolis")
  (locale "en_US.utf8")
  (bootloader (bootloader-configuration
   (bootloader grub-bootloader)
   (targets (list "/dev/sda"
  (file-systems
   (cons*
(file-system
 (mount-point "/")
 (device "/dev/sda")
 (type "ext4"))
%base-file-systems))

  (users (cons* (user-account
 (name "joshua")
 (comment "Joshua Branson")
 (group "users")
 (home-directory "/home/joshua")
 (supplementary-groups
  '("kvm" "netdev" "wheel")))
%base-user-accounts))

  (packages %base-packages)
  ;; Add services to the baseline: a DHCP client and
  ;; an SSH server.
  (services
   (cons*
(service dhcp-client-service-type)
(service openssh-service-type
 (openssh-configuration
  (openssh openssh-sans-x)
  (port-number )))
%my-base-services)))
#+end_example

To try it for yourself:

#+BEGIN_SRC shell
$(guix system vm bare-bones-with-autologin.scm)
#+END_SRC

Ctrl-Alt-G (make sure Ctrl and Alt are the left most keys) to grab focus
inside the vm. Alt-right to switch to a different console. Ctrl-Alt-G to
ungrab focus from the vm.

bug#56954: [Website] Getting 404 for Instructional videos

[Hosein Naghdbishi via Bug reports for GNU Guix]

  
  
Hi! 

I'm getting 404 error for all instructional videos on such as the
  file for https://guix.gnu.org/en/videos/2020/asking-for-help/
  which is https://guix.gnu.org/guix-videos/03-help.webm
Please fix.

  

bug#56958: auto login to tty only works for tty1

[Joshua Branson via Bug reports for GNU Guix]

And now I have a video bug report!

How cool is that?

https://video.hardlimit.com/w/e8fXXxmSv5mW3TJsT3ZkN3

Thanks,

Joshua

bug#56334: Should asdf-build-system/sbcl use load-system instead of compile-system?

[Pierre Neidhardt]

Excellent, thanks a lot! :)


signature.asc
Description: PGP signature

bug#56971: greeter user permissions are not enough to talk with seatd

[muradm]

Liliana Marie Prikler  writes:


block 56971 by 56690 56699
thanks

Hi muradm,

Hi Liliana,


Am Donnerstag, dem 04.08.2022 um 12:45 +0300 schrieb muradm:

[...] greeter (e.g. gtkgreet) requiring communication
with seatd is failing to start, causing "black screen"
behavior on active terminal (switching to the other non seatd
related terminal is possible, for manual permissions
adjustment as workaround).

To address this issue, we need more flexible control over
seatd user/group, which creates seatd.sock, and greeter user
which connects to seatd.sock.

Okay.


However, not all greeters require that, so I decided to make
more flexible.
Flexibility for its own sake is not always the right solution. 
On the
other hand, looking at the two patches, it appears they are to 
be used

in combination?


No, technically they are not strongly dependent on each other,
could be applied one after another in no particular order.
After both are applied, in cooperation they address this issue.


 Propsed solutions consists of:

* 56690 - gnu: seatd-service-type: Should use seat group.
With this change, if seatd-service-type is present in the
system configuration, "seat" group will be added, and seatd
will run as root/seat. Group is configurable, but default is
"seat".
Why just the group and no user?  Is it not possible to launch 
seatd as

non-root?
seatd provides a way for display servers to access input/output 
devices

without having to be root. So seatd it self has to run as root.
When seatd opening socket as root/seat, all members of seat would
be able to communicate with it. Also socket could be opened with
seat/seat for instance, but there is no specific point in doing 
so.

Will be one more unused system user around.
Arch seems to follow similar way, root/seat is ok for socket.
Also will signal that seatd is running as root.


* 56699 - gnu: greetd-service-type: Add greeter-extra-groups
  config field.
With this change, if user wants to use seatd-service-type with
greeter requiring seatd.sock, he can add "seat" group to
greeter-extra-groups field.

Note that you still have a TODO on that patch.

That TODO is from the initial commit, it is about cgroup file
system mounting, and totally out of scope of this issue.


Cheers

Thanks in advance



signature.asc
Description: PGP signature

bug#56799: (gnu services configuration) usage of *unspecified* is problematic

[Ludovic Courtès]

Howdy,

Maxim Cournoyer  skribis:

>>> Granted, few services outside of Jami probably made use of this, but it
>>> was nevertheless a useful property.
>>
>> I don’t know of any.
>
> I think mostly because few services make use of define-configuration.
> While attempting to write a new VNC service, it quickly became a visible
> annoyance:
>
> (define-configuration/no-serialization xvnc-configuration

[...]

>   (port
>maybe-port
>"The port on which to listen for connections from viewers.  When left
> unspecified, it defaults to 5900 plus the display number.")

[...]

> (define (xvnc-shepherd-service config)
>   "Return a  for Xvnc with CONFIG."
>   ;; XXX: Ensure all the *unspecified* values are handled outside of gexps, as
>   ;; they are not valid gexp input (they are not self-quoting/serializable).
>   ;; This would otherwise cause problem during 'guix deploy'.
>   (let* ((display-number (xvnc-configuration-display-number config))
>  (port (if (unspecified? (xvnc-configuration-port config))
>#f
>(xvnc-configuration-port config)))

OK, I see.  I guess most of the time, we just call
‘serialize-xyz-configuration’, which automatically handles *unspecified*
values.  In this case, ‘port’ is treated specially and instead passed as
a command-line argument.

Other ways to address that come to mind include: adding ‘port’ to the
config file instead of on the command line (if possible), or doing:

  (serialize-configuration config
   (find (lambda (field)
   (eq? (configuration-field-name field)
'port))
 xvnc-configuration-fields))

That’s a mouthful but maybe it could be abstracted.  It does sound less
convenient though.

That said, whether it’s ‘unspecified?’ or something else, you have to
have a check in place, right?  With the new interface it becomes:

 (if (eq? port 'unset) #f port)

Or you can provide an actual default value (an integer in this case),
but that’s possible whether or not *unspecified* is the default value.

WDYT?

>> In addition to these issues around the process, I think we should strive
>> for more stability.  One of the reasons it took time to review
>>  is that interface changes are a
>> commitment.  Now commit a2b89a3319dc1d621c546855f578acae5baaf6da
>> introduces a second interface change for reasons that are unclear to me
>> (if the conclusion had been to revert, I’d have favored an actual revert
>> rather than introducing 'unset).
>
> I like to think of *unspecified* or 'unset as an uninteresting
> implementation detail that shouldn't be part of the public API.

It is part of the API for people who write services (but it’s definitely
an implementation detail for someone who just uses services).

> It's an implementation detail of the 'maybe' types/predicates
> generator of the (gnu services configuration) machinery.  Perhaps we
> could introduce a 'maybe-set?' predicate to check them, to avoid
> leaking the implementation detail (the 'unset symbol).  Also, after
> reading more on the topic, it became clear to me that *unspecified* is
> not meant as a value to be actively used by programmers in Scheme; it
> seems it's rather a value meant to be returned when the behavior of a
> procedure is unspecified [0].  Why 'unspecified?' even exist in Guile
> I don't know, I suppose because of some disagreement on the matter, as
> hinted in the previous link.

Right, even cleaner would be to have a specific value for this, like:

  (define  (list 'default)) ;or something w/o read syntax
  (define (default? x) (eq? x ))

But IMO it’s OK.

> The reason I did not simply revert was because the change also
> introduced something useful in the same code change, which is to lift
> the requirement to specify a default value for maybe-* fields.

Right, that makes sense to me.

>> How should we move forward?
>
> Perhaps we can discuss any issues I may have missed that arise from the
> this change, or possible future directions that would improve things.

With the xvnc example, I better understand the kind of situation where
a field value might end up directly in a gexp, though I’m still unsure
whether use of *unspecified* really makes things worse.  At least,
because it lacks a read syntax, the problem is caught early on; whereas
with 'unset, you might end up stuffing 'unset in your config file
without noticing.

Thanks for taking the time to discuss!

Ludo’.

bug#56398: (guix git) fails to check out repos with nested submodules

[Ludovic Courtès]

Hello,

André Batista  skribis:

> Well, I guess ENOENT != GIT_ENOTFOUND and, in that case, I think we
> are better off gracefully failing to update it than trying to "branch"
> our local repo. The patch below tests for the directory's existence
> before proceding with the update. With this patch applied I've managed
> to refresh pytorch, its submodules and got the following code:

But you got a wrong hash I presume, because submodule weren’t actually
checked out, right?

> +(if (file-exists? directory)
> +((lambda ()
> +   (submodule-update submodule
> + #:fetch-options fetch-options)

The problem is that it papers over an actual libgit2 bug.

I think we should instead report it upstream.  Do you feel like doing
it?  I guess we’d need to give them the C version of the three-line
snippet I gave earlier.

WDYT?

Thanks,
Ludo’.

bug#54691: fortune-mod propagates various non-nice things

[Ludovic Courtès]

Hi,

Liliana Marie Prikler  skribis:

> Am Mittwoch, dem 03.08.2022 um 15:43 +0200 schrieb Ludovic Courtès:
>> [...]
>> > -(define-public fortune-mod
>> 
>> (Perhaps also make “fortune-mod” a deprecated name for
>> “fortune-jkirchartz”.)
> I'm getting mixed messages here.  On the one hand, Maxime suggests not
> propagating daikichi from fortune-jkirchartz (which makes it a plain
> data package lacking a `fortune' command), on the other we want to mark
> fortune-mod as deprecated.  These are mutually exclusive options.

To me use of ‘deprecated-package’ in this case is just to ensure that
users who run ‘guix upgrade’ will transparently get
‘fortune-jkirchartz’.  I don’t have a strong opinion though.

>> FWIW I’m fine with this change.  Note that there’s also another patch
>> that removes the ‘off’ database of ‘fortune-mod’¹, though I don’t
>> know whether that would fully address the issues raised in this
>> thread.  It will have to closed if/once this series is applied.
> IIRC, I responded to such a patch already, though perhaps not that
> thread in particular.  To summarize, fortune-mod also propagates non-
> nice things outside of ‘off’, so removing it is not enough.

Alright, let’s remove ‘fortune-mod’ then.

Thanks for taking care of it!

Ludo’.

bug#56398: (guix git) fails to check out repos with nested submodules

[André Batista]

Hi Bengt!

sex 08 jul 2022 às 12:17:59 (1657293479), b...@bokr.com enviou:
> Have you seen this[1] re nested git tricks? 
> 
> [1]:

No, I had missed that, thanks for pointing that out!

> i.e., are you sure not to be used by some such attack?

However I think this git issue is orthogonal to the current one.

First, inits, clones and checkouts are key git features, so it's
up to git to make sure its subcommands will not execute code by
mistake.

Second, to exploit it, the attacker would have to make themselves
very visible by maintaining a public malicious repo which would be
bound to be flagged.

And lastly, guile-git uses libgit2, which is a different beast that
actually auto initializes submodules when updating, contrary to my
mistaken assumption to which you've replied. I thought
initialization implied directory creation, but it actually doesn't.

Cheers!

bug#56398: (guix git) fails to check out repos with nested submodules

[André Batista]

Hi and I'm sorry for the delay..

sex 08 jul 2022 às 10:26:40 (1657286800), ludovic.cour...@inria.fr enviou:
> If we do this:
> 
> --8<---cut here---start->8---
> scheme@(guix git)> (define r (repository-open 
> "/home/ludo/.cache/guix/checkouts/4pe5bqkmsmcros5oviwzvmnjlie6jyhx2dciznz7shwawckb32sq/"))
> scheme@(guix git)> (define mod (submodule-lookup r "third-party/googletest"))
> scheme@(guix git)> mod
> $13 = #
> scheme@(guix git)> (submodule-update $13)
> ice-9/boot-9.scm:1685:16: In procedure raise-exception:
> Git error: failed to resolve path 
> '/home/ludo/.cache/guix/checkouts/4pe5bqkmsmcros5oviwzvmnjlie6jyhx2dciznz7shwawckb32sq/third-party/googletest/.git':
>  No such file or directory

Nice trick!

> (...)
> access("/home/ludo/.cache/guix/checkouts/4pe5bqkmsmcros5oviwzvmnjlie6jyhx2dciznz7shwawckb32sq/third-party/googletest/.git",
>  F_OK) = -1 ENOENT (No such file or directory)
> (...)
>
> Thus, looking at ‘git_submodule_update’ in libgit2, it looks as if this
> condition was true:
> 
>   (submodule_status & GIT_SUBMODULE_STATUS_WD_UNINITIALIZED)
> 
> Hmm, thoughts?

Well, I guess ENOENT != GIT_ENOTFOUND and, in that case, I think we
are better off gracefully failing to update it than trying to "branch"
our local repo. The patch below tests for the directory's existence
before proceding with the update. With this patch applied I've managed
to refresh pytorch, its submodules and got the following code:

--8<---cut here---start->8---
diff --git a/gnu/packages/machine-learning.scm 
b/gnu/packages/machine-learning.scm
index b19af8a1d5..174ba3d39b 100644
--- a/gnu/packages/machine-learning.scm
+++ b/gnu/packages/machine-learning.scm
@@ -2871,7 +2871,7 @@ (define-public xnnpack
 (define-public python-pytorch
   (package
 (name "python-pytorch")
-(version "1.12.0")
+(version "82782")
 (source (origin
   (method git-fetch)
   (uri (git-reference
@@ -2881,7 +2881,7 @@ (define-public python-pytorch
   (file-name (git-file-name name version))
   (sha256
(base32
-"0pdqi91qzgyx947zv4pw2fdj9vpqvdhfzw1ydjd4mpqm8g5njgnz"))
+"0zshqfqv3lcwyym3l8zx675chnhpxn14c4nr1c2b7ci1zis785va"))
   (patches (search-patches "python-pytorch-system-libraries.patch"
"python-pytorch-runpath.patch"))
   (modules '((guix build utils)))
--8<---cut here---end--->8---

Where "82782" is a ciflow/trunk reference to commit
700dba518be03ee0c0d6389162b5907a13838f49.

I've also thought of filtering the submodules list and passing the
resulting list instead, but came to conclude that it would clutter
the code instead of simplifying it.

I hope that helps!

---
>From 10bbb79f87f3728c347e33a101add8cb740e9469 Mon Sep 17 00:00:00 2001
In-Reply-To: <56...@debbugs.gnu.org>
References: <56...@debbugs.gnu.org>
From: =?UTF-8?q?Andr=C3=A9=20Batista?= 
Date: Thu, 4 Aug 2022 08:07:35 -0300
Subject: [PATCH] guix: git: Gracefully handle missing submodules when updating.
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
To: debb...@gnu.org

Fixes .
Reported by Ludovic Courtès .

* guix/git.scm (update-submodules): Check if submodule directory
exists before trying to update it.
---
 guix/git.scm | 26 ++
 1 file changed, 14 insertions(+), 12 deletions(-)

diff --git a/guix/git.scm b/guix/git.scm
index 631bf577d3..d6a82fb86c 100644
--- a/guix/git.scm
+++ b/guix/git.scm
@@ -320,20 +320,22 @@ (define* (update-submodules repository
 (fetch-options #f))
   "Update the submodules of REPOSITORY, a Git repository object."
   (for-each (lambda (name)
-  (let ((submodule (submodule-lookup repository name)))
+  (let* ((submodule (submodule-lookup repository name))
+ (directory (string-append
+  (repository-working-directory repository)
+  "/" (submodule-path submodule
 (format log-port (G_ "updating submodule '~a'...~%")
 name)
-(submodule-update submodule
-  #:fetch-options fetch-options)
-
-;; Recurse in SUBMODULE.
-(let ((directory (string-append
-  (repository-working-directory repository)
-  "/" (submodule-path submodule
-  (with-repository directory repository
-(update-submodules repository
-   #:fetch-options fetch-options
-   #:log-port log-port)
+(if (file-exists? directory)
+((lambda ()
+   

bug#56971: greeter user permissions are not enough to talk with seatd

[Liliana Marie Prikler]

block 56971 by 56690 56699
thanks

Hi muradm,

Am Donnerstag, dem 04.08.2022 um 12:45 +0300 schrieb muradm:
> [...] greeter (e.g. gtkgreet) requiring communication
> with seatd is failing to start, causing "black screen"
> behavior on active terminal (switching to the other non seatd
> related terminal is possible, for manual permissions
> adjustment as workaround).
> 
> To address this issue, we need more flexible control over
> seatd user/group, which creates seatd.sock, and greeter user
> which connects to seatd.sock.
Okay.

> However, not all greeters require that, so I decided to make
> more flexible.
Flexibility for its own sake is not always the right solution.  On the
other hand, looking at the two patches, it appears they are to be used
in combination?

>  Propsed solutions consists of:
> 
> * 56690 - gnu: seatd-service-type: Should use seat group.
> With this change, if seatd-service-type is present in the
> system configuration, "seat" group will be added, and seatd
> will run as root/seat. Group is configurable, but default is 
> "seat".
Why just the group and no user?  Is it not possible to launch seatd as
non-root?

> * 56699 - gnu: greetd-service-type: Add greeter-extra-groups 
>   config field.
> With this change, if user wants to use seatd-service-type with
> greeter requiring seatd.sock, he can add "seat" group to
> greeter-extra-groups field.
Note that you still have a TODO on that patch.

Cheers

bug#56971: greeter user permissions are not enough to talk with seatd

[muradm]

Hi,

As per discussion here:
https://lists.gnu.org/archive/html/guix-devel/2022-08/msg00020.html

Above change reduced permissions of greeter user.
While it is ok for greeters that do not talk to seatd,
greeters talking to seatd lost access to seatd socket.
As result, greeter (e.g. gtkgreet) requiring communication
with seatd is failing to start, causing "black screen"
behavior on active terminal (switching to the other non seatd
related terminal is possible, for manual permissions
adjustment as workaround).

To address this issue, we need more flexible control over
seatd user/group, which creates seatd.sock, and greeter user
which connects to seatd.sock.

Other distros (Arch for instance) introduced "seat" group.
So user which wants to login on system controlled by seatd
should be member of that group.

However, not all greeters require that, so I decided to make
more flexible. Propsed solutions consists of:

* 56690 - gnu: seatd-service-type: Should use seat group.
With this change, if seatd-service-type is present in the
system configuration, "seat" group will be added, and seatd
will run as root/seat. Group is configurable, but default is 
"seat".


* 56699 - gnu: greetd-service-type: Add greeter-extra-groups 
 config field.

With this change, if user wants to use seatd-service-type with
greeter requiring seatd.sock, he can add "seat" group to
greeter-extra-groups field.

Thanks in advance,
muradm



signature.asc
Description: PGP signature