bug#70663: nss@3.99 is really hard to build

[Joshua Branson via Bug reports for GNU Guix]

Perhaps we could disable the test suite for power9 ?  At the moment guix
pull fails on power9...I believe due to this bug.

Just a thought.

Joshua

bug#70475: updating my guix system linode server troubles

[Joshua Branson via Bug reports for GNU Guix]

So my server that runs https://gnucode.me is a guix system linode server!  Woo
hoo!

Well lately the server is being a right pain, and it refuses to update.  Most
likely my server is lonely and just wants a hug.

#+BEGIN_SRC shell
jos...@gnucode.me $ guix system describe

Generation 20   Aug 17 2023 07:45:06(current)
  file name: /var/guix/profiles/system-20-link
  canonical file name: /gnu/store/g10d07ab2hfspvj0wglwlicmphi9ly07-system
  label: GNU with Linux-Libre 6.3.13
  bootloader: grub
  root device: /dev/sda
  kernel: /gnu/store/224j20diq0qgxqzmh1hgsp35zi3qn9jc-linux-libre-6.3.13/bzImage
  channels:
guix:
  repository URL: https://git.savannah.gnu.org/git/guix.git
  branch: master
  commit: 210bbf9c59355218fec1484a686cc2ecdc218506
guixrus:
  repository URL: https://git.sr.ht/~whereiseveryone/guixrus
  branch: master
  commit: d70a9ea65eba43aba3ec7560d797452c01171b85
nonguix:
  repository URL: https://gitlab.com/nonguix/nonguix
  branch: master
  commit: 1a3082c574077aaf6771ff927e725fc390a2d531
  configuration file: 
/gnu/store/8xi1rqijhlafnrvzrgla7k3qlkl9jsfw-configuration.scm

jos...@gnucode.me $ guix describe

Generation 2Aug 17 2023 07:11:45(current)
  guix 1b2d43f
repository URL: https://git.savannah.gnu.org/git/guix.git
branch: master
commit: 1b2d43fe016848ea2ec16ff18cbc14340944fc4e

#+END_SRC

I have used guix deploy in the past to update my linode server, which works
super awesomely well! But lately, guix deploy no longer updates my linode
server.

#+BEGIN_SRC shell
joshua@laptopT400 $ guix deploy gnucode.me-current-config.scm -x -- sudo herd 
restart nginx
guix deploy: sending 12 store items (133 MiB) to '45.56.66.20'...
guix deploy: copertino: command succeeded
guix deploy: command output on copertino:
Service user-homes has been started.
Service nginx has been started.
#+END_SRC

Let's see if gnucode.me has been updated:

#+BEGIN_SRC shell
jos...@gnucode.me $ guix describe
Aug 2023  # (the same date as before)
jos...@gnucode.me $ guix system describe
Aug 2023  # (the same date as before)
#+END_SRC

/run/current-system/configuration.scm is the old configuration and not the new
one. What gives?

So it appears that guix deploy is not updating my server. That's annoying.  I've
been guix deploying my server happily for a while now, and I didn't even realize
that the server was failing to update.

Well, I had a similar issue, where my laptop was really outdated...guix pull was
failing. To update my laptop I built guix from source. I described that here:

https://issues.guix.gnu.org/68760

Well, since guix deploy fails to update my linode server, I tried running guix
pull: First I powered down the linode and updated the vm so that it had 4GB of
RAM.

Then at 2pm today, I ran guix pull.  It started building stuff, and I let it 
sit.
#+BEGIN_SRC shell
jos...@gnucode.me $ guix pull
  # more output above
building /gnu/store/lb5b7svdmfj1ijnzrripsjcv0bhqzpwb-Python-3.5.9.tar.xz.drv...
building 
/gnu/store/z8kqgsx6yh2mpm0n2jhzk1phihdscazf-datefudge_1.23.tar.xz.drv...
building /gnu/store/9cl9w041lwjz607f5l6pzjzgixdl1jjm-Python-3.5.9.tar.xz.drv...
building 
/gnu/store/8r73jwy621pvmbfyk34w0gqf65sff9di-elfutils-0.187.tar.bz2.drv...
building /gnu/store/0innk69jqi1zadpwyi8p9szdl95l2lk0-expat-2.5.0.tar.xz.drv...
building /gnu/store/3zysg963rlp01rpkjwsi8qzfr84kwd9d-gcc-11.3.0.tar.xz.drv...
building 
/gnu/store/lpkc0wsvgbfz0qwxn1nckh88n4xrg1kg-gettext-0.19.8.1.tar.gz.drv...
building /gnu/store/g6qb58plai65zdps620ny2rfif1z42s0-gettext-0.21.tar.gz.drv...
building /gnu/store/dc2y0rldz6wadknqz4jl6zjb7l4xsay5-glibc-2.35.tar.xz.drv...
building /gnu/store/gb6lfdzqprh1fmw91kpkclywg8sbrwg3-glibc-mesboot0-2.2.5.drv...
/ 'install' 
phase^[[A^[[A^[[A^[[A^[[A^[[A^[[A^[[A^[[A^[[A^[[A^[[A^[[A^[[A^[[A^[[A^[[A^[[A^[[A^[[|

building /gnu/store/5s4cfyc3w6jn958jn1i09g6my4g7l9l4-glibc-2.35.tar.xz.drv...
building /gnu/store/qm63mzpmzriksa9vi0gl977h7qhcmgkg-gcc-mesboot0-2.95.3.drv...
building /gnu/store/1hrskysmxkyblhw8mpkkz1m2jn4g0f8s-gmp-6.0.0a.tar.xz.drv...
building 
/gnu/store/cfbs6ysgyrqwfgbkd15gkbf7brgfgvk3-binutils-mesboot1-2.20.1a.drv...
building /gnu/store/b4xy58rqb3cqw2wiip8l0ibf9crk13zd-gmp-6.0.0a.tar.xz.drv...
building /gnu/store/1vp4cjnwxr55basnbjr4vfd5l5pmf41c-gnutls-3.8.3.tar.xz.drv...
building 
/gnu/store/j9vzm9yrkzfsgjpliab737fllq6kkm7q-guile-lib-0.2.8.tar.gz.drv...
building /gnu/store/wh7yqmqk07p7xby179razdbp6ysgqygl-isl-0.24.tar.xz.drv...
building /gnu/store/c3ds6y32xq9xck076apm525qqvp649ia-libffi-3.4.4.tar.gz.drv...
building 
/gnu/store/nn8hm6242hfwv906v1dy2m7sq3yv3hsh-libunistring-1.0.tar.xz.drv...
building /gnu/store/05nznjzl8qfsdps7wd51852babfvrndw-m4-1.4.19.tar.xz.drv...
building /gnu/store/6hqxh7hlcarn7l3y32pn4l3gkjbpkjia-make-mesboot-3.82.drv...
building 
/gnu/store/jxg62mw1619fznmnq3b7if5nv08s5q1i-module-import-compiled.drv...
building /gnu/store/gmw2a5zxc6liilr8jwpdw51isfrbrkis-gcc-mesboot1-4.6.

bug#68760: I guess I found a bug in "guix pull" ?

[Joshua Branson via Bug reports for GNU Guix]

Josselin Poiret  writes:

> Hi,
>
> jbranso--- via Bug reports for GNU Guix  writes:
>
>>  message: "error parsing derivation 
>> `/gnu/store/3nppfdxy9vgg9ls6qi8j8pkzw2khi98h-git-minimal-2.41.0.drv': 
>> expected string `Derive(['"
>>  status: 1
>> guix pull: error: You found a bug: the program 
>> '/gnu/store/m9z876jpmpbslc6qaikbp9fk5dv01y3n-compute-guix-derivation'
>
> Looks like the elusive "empty drv" bug (maybe caused by fs corruption?).
> Can you `guix gc -D` that drv and retry?
>
> Best,

Thanks for the quick reply.  I was able to fix the issues that I had by
the following:

# guix system delete-generations
$ guix package -d
$ guix gc


Then I git cloned guix source, compiled from source, and

# sudo -E ./pre-inst-env guix system reconfigure \
../../guix-config/bare-bones-sway.scm

I was able to update guix pretty smoothly after that!

Thanks,

Joshua

P.S.  I'll close this bug report as well.

bug#63738: [PATCH glibc] Stop checking if MiG supports retcode.

[Joshua Branson via Bug reports for GNU Guix]

Hey guix people!  The Hurd developers having a 64 bit Hurd that can run
/bin/sh.  The below are some tips for how to set up such a thing if you
were so inclined.  The Debian people are providing 64-bit hurd
applications here for now:

https://people.debian.org/~sthibault/tmp/hurd-amd64

Flávio Cruz  writes:

> Hi Sergey
>
> On Fri, May 19, 2023 at 4:02 AM Sergey Bugaev  wrote:
>
>  Hi,
>
>  On Fri, May 19, 2023 at 9:43 AM Flávio Cruz 
>  wrote:
>  > I have made changes so that it does daily builds and I'm able to boot
>  small programs. However, I haven't had the time to boot programs built
>  against Glibc. How do you package and boot the static binaries using a
>  ramdisk? I've been reading the other threads about the Guix/rumpkernel
>  so I might be able to piece something together and try it this weekend.
>
>  You just put the entirety of the root filesystem (containing /usr,
>  /bin, /lib, /hurd, and so on) as an ext2 image into a *file* that you
>  place onto the actual drive (a CD disk in my case), and then you ask
>  GRUB to load the file from the drive into memory, tell gnumach to make
>  a ramdisk device out of it (you'll need to apply [0]), and tell ext2fs
>  to use that device. Here's the relevant piece of my grub config
>  script:
>
>  [0]:
>  
> https://salsa.debian.org/hurd-team/gnumach/-/blob/master/debian/patches/50_initrd.patch
>  
>
>  multiboot /boot/gnumach console=com0
>  module /boot/initrd.ext2 initrd.ext2 '$(ramdisk-create)'
>  module /sbin/ext2fs.static ext2fs
>  --multiboot-command-line='${kernel-command-line}' --readonly
>  --host-priv-port='${host-port}' --device-master-port='${device-port}'
>  --exec-server-task='${exec-task}' --kernel-task='${kernel-task}' -T
>  device rd0 '$(fs-task=task-create)' '$(prompt-task-resume)'
>  module /lib/ld.so.1 ld.so.1 /hurd/exec
>  --device-master-port='${device-port}' '$(exec-task=task-create)'
>  boot
>
>  (I should probably change it to not hardcode 'rd0', but whatever).
>  Note that /boot/gnumach, /boot/initrd.ext2, /sbin/ext2fs.static, and
>  /lib/ld.so.1 are all paths inside the CD image (those are going to be
>  loaded by GRUB), and /boot/initrd.ext2 is the ext2 filesystem image
>  containing the actual Hurd root. /hurd/exec however is already a path
>  inside the fs image -- this is where ld.so (not grub) is going to load
>  the exec server from. The only static binary here is ext2fs.static,
>  the rest are all dynamically linked.
>
>  Then in /libexec/console-run (inside the filesystem image), I have
>  written the following:
>
>  #! /bin/sh
>
>  settrans -ac /dev/mach-console /hurd/streamio console
>  exec <>/dev/mach-console >&0 2>&0
>  echo Hello from /bin/sh!
>  exec /bin/sh -i
>
>  (If you're going to do the same, don't forget to create the
>  /dev/mach-console node beforehand, since the fs is read-only.) I also
>  had to patch streamio a little to do the \r -> \n conversion like
>  glibc already does in devstream:
>
>  diff --git a/trans/streamio.c b/trans/streamio.c
>  index 272a002c..0af1aea3 100644
>  --- a/trans/streamio.c
>  +++ b/trans/streamio.c
>  @@ -500,6 +500,9 @@ trivfs_S_io_read (struct trivfs_protid *cred,
>cred->po->openmodes & O_NONBLOCK);
> pthread_mutex_unlock (&global_lock);
> *data_len = data_size;
>  +  for (size_t i = 0; i < data_size; i++)
>  +if ((*data)[i] == '\r')
>  +  (*data)[i] = '\n';
> return err;
>   }
>
>  (maybe I should also add echoing of input characters in the same way,
>  which is also what glibc's devstream does -- otherwise currently I
>  don't see what I'm typing on the console).
>
>  Make sure to use the very latest glibc (Samuel has already pushed all
>  of my patches upstream!) + the BRK_START hack.
>
> Thanks for the instructions. I was able to make it work and pushed my
> changes to Github.
>
> For people that might want to try out the new port using
> https://github.com/flavioc/cross-hurd,
> the following will download the packages and build a disk image with the ram
> disk:
>
> $ export CPU=x86_64
> $ bash download.sh && bash bootstrap.sh && bash compile.sh && bash
> create-initrd.sh
>
> Then, to run qemu:
>
> $ bash start-qemu-debug.sh
>
>  Sergey
>

-- 

Joshua Branson
Sent from the Hurd

bug#48636: Gajim does not load the "close" icon on the chat window

[Joshua Branson via Bug reports for GNU Guix]

"bdju"  writes:

> On Mon May 24, 2021 at 6:48 PM CDT, Joshua Branson via Bug reports for GNU 
> Guix wrote:
>>
>> Other clues that the chat on irc disclosed:
>> (org.gajim.Gajim:6250): Gtk-WARNING **: 14:31:46.574: Could not find the
>> icon 'org.gajim.Gajim'. The 'hicolor' theme
>> was not found either, perhaps you need to install it.
>> 05/21/2021 14:31:46 (W) gajim.plugin_system Error while loading module:
>> gtk-icon-theme-error-quark: Icon 'preferences-system' not present in
>> theme Adwaita (0)
> I have adwaita-icon-theme and hicolor-icon-theme in my system profile,
> which I think makes some gtk stuff play nicer. I would suggest
> installing them if you don't have them. Especially hicolor, since it's
> mentioned in your error output. I also have gnome-themes-standard and
> gnome-themes-extra, so those may also be worth installing if the other
> things don't do the trick. IIRC some gtk themes don't stand completely
> on their own, and so they'll have missing bits if you don't have some of
> the basic ones like adwaita. It's also possible you don't have any icon
> themes at all.
> Perhaps the hicolor icons should be made a dependency so users don't
> have to figure this out on their own. I recall another package getting
> that treatment a while back.


I have stopped using gajim.  I find dino to be 2x as stable.  I am
closing this bug report.

Joshua

bug#60205: Dino lacks some icons

[Joshua Branson via Bug reports for GNU Guix]

Liliana Marie Prikler  writes:

> Am Montag, dem 19.12.2022 um 16:14 + schrieb Tirifto:
>>   ** (dino:17647): CRITICAL **: 17:06:11.642: file /tmp/guix-build-
>> dino-0.3.1.drv-0/dino-0.3.1/main/src/ui/main_window.vala: line 68:
>> uncaught 
>> error: Unrecognized image file format (gdk-pixbuf-error-quark, 3)
>>   
>>   (dino:17647): Gtk-WARNING **: 17:06:11.676: Found an icon but could
>> not load 
>> it. Most likely gdk-pixbuf does not provide SVG support.
>>   
>>   (dino:17647): Gtk-WARNING **: 17:06:11.680: Could not load a pixbuf
>> from 
>> icon theme.
>>   This may indicate that pixbuf loaders or the mime database could
>> not be found.
> These two lines appear to mark the most likely culprit.  Now, normally
> our gdk-pixbuf packages do support svg, but there's some strings
> attached.  Most of our GNOME related programs are tested in a GNOME
> environment rather than a pure one, which means that things that
> shouldn't work happen to do.  Compare the output of
>
>   guix shell --pure -E DISPLAY dino librsvg adwaita-icon-theme -- dino
>
> to
>
>   guix shell --pure -E DISPLAY dino -- dino
>
> Note that librsvg is a regular input to dino and should thus be
> available as a pixbuf loader.  I'm not sure what exactly is wrong here
> (perhaps dino should swap its librsvg input for gdk-pixbuf), but
> another caveat is that on non-x86_64 systems we are forced to use a
> pre-Rust version of librsvg, which barfs on some particular input
> files.
>

Just quoting bug 48636:

I have adwaita-icon-theme and hicolor-icon-theme in my system profile,
which I think makes some gtk stuff play nicer. I would suggest
installing them if you don't have them. I also have
gnome-themes-standard and gnome-themes-extra, so those may also be worth
installing if the other things don't do the trick.

Perhaps the hicolor icons should be made a dependency so users don't
have to figure this out on their own. I recall another package getting
that treatment a while back.

End quote

Perhaps dino should have hicolor-icon-theme as a dependency.



>
> Hope that helps.
>
> Cheers

bug#58606: Emacs next pgtk crashes when pasting to other app

[Joshua Branson via Bug reports for GNU Guix]

Andrew Tropin  writes:

> On 2022-11-16 10:34, Joshua Branson wrote:
>
>> Declan Tsien  writes:
>>
>>> Andrew Tropin  writes:
>>>
>>>> Recently discovered a problem, which reproduces this way:
>>>> - Open a new emacs instance.
>>>> - Yank anything with M-w or select with mouse.
>>>> - Paste yanked text to chromium/icecat.
>>>>
>>>> Both browser and emacs are hanging up for a while and after that Emacs
>>>> crashes with:
>>>
>>
>> I just discovered today, that I can copy text from emacs and paste that
>> text into firefox.  It seems to no longer be an issue for me.  :)
>
> I built a latest emacs from master:
> https://git.sr.ht/~abcdw/rde/commit/b03373920c1cc7d8d4b2d64c96f72eed9bb3651a
>
> And it is affected by this issue, so I made a quick and dirty workaround:
> https://git.sr.ht/~abcdw/rde/commit/b6aef2d8b34d1166f33629b4b3a1a0f5751f90f9
>
> Unfortunately, I don't see an easy way to backport this fix to Guix.
>
> Probably, this issues should be reported to bug-gnu-emacs.
>

I will let one of you do the reporting, since this issue no longer
affects me.  :)

bug#58606: Emacs next pgtk crashes when pasting to other app

[Joshua Branson via Bug reports for GNU Guix]

Declan Tsien  writes:

> Andrew Tropin  writes:
>
>> Recently discovered a problem, which reproduces this way:
>> - Open a new emacs instance.
>> - Yank anything with M-w or select with mouse.
>> - Paste yanked text to chromium/icecat.
>>
>> Both browser and emacs are hanging up for a while and after that Emacs
>> crashes with:
>

I just discovered today, that I can copy text from emacs and paste that
text into firefox.  It seems to no longer be an issue for me.  :)

bug#58606: Emacs next pgtk crashes when pasting to other app

[Joshua Branson via Bug reports for GNU Guix]

Andrew Tropin  writes:

> On 2022-10-18 10:52, Andrew Tropin wrote:
>
>> Recently discovered a problem, which reproduces this way:
>> - Open a new emacs instance.
>> - Yank anything with M-w or select with mouse.
>> - Paste yanked text to chromium/icecat.
>>

I sometimes run two instances of Emacs.  I discovered today, that Emacs
cannot yank from one and paste to another.  When I try to paste I get this
mysterious warning message in Emacs:

"waiting for reply from selection owner."

bug#58606: Emacs next pgtk crashes when pasting to other app

[Joshua Branson via Bug reports for GNU Guix]

Joshua Branson via Bug reports for GNU Guix  writes:

> Andrew Tropin  writes:
>
>> Recently discovered a problem, which reproduces this way:
>> - Open a new emacs instance.
>> - Yank anything with M-w or select with mouse.
>> - Paste yanked text to chromium/icecat.
>>
>> Both browser and emacs are hanging up for a while and after that Emacs
>> crashes with:
>>
>> Fatal error 11: Segmentation fault
>>
>>
>> sway, emacs-next-pgtk, ungoogled-chromium
>
> I was unable to reproduce this bug.  I am also using sway.  Also thanks
> for the tip about emacs-next-pgtk.  I didn't know that was packaged!
>

So I did just reconfigure, and I am now running a wayland only sway
session.

I did notice that I cannot seem to copy text from inside emacs and paste
into chromium or icecat... Chromium seemed to lock up after I tried to
paste into its url bar.  Icecat did not accept the paste, but continued
working...

bug#58631: [Shepherd] Indefinite heap growth (memory leak)

[Joshua Branson via Bug reports for GNU Guix]

Ludovic Courtès  writes:

> Indeed, the core dump weighs 13 GiB, so it looks like a memory leak (too
> bad ‘info proc stat’ in GDB doesn’t work).
>
> I have not observed it on any other machine.  The difference between
> berlin and machines I have access to is that berlin is being hammered on
> port 22, which means it gets to spawn sshd processes very often.  This
> could be where the leak is.
>

So, this is a hack, but perhaps berlin could start to use endlessh on
port 22, and then the real ssh port could be on another standard port.

https://issues.guix.gnu.org/39136

It would change most guix developers work loads.  But it's a thought.  :)

> Ludo’.

bug#58606: Emacs next pgtk crashes when pasting to other app

[Joshua Branson via Bug reports for GNU Guix]

Andrew Tropin  writes:

> Recently discovered a problem, which reproduces this way:
> - Open a new emacs instance.
> - Yank anything with M-w or select with mouse.
> - Paste yanked text to chromium/icecat.
>
> Both browser and emacs are hanging up for a while and after that Emacs
> crashes with:
>
> Fatal error 11: Segmentation fault
>
>
> sway, emacs-next-pgtk, ungoogled-chromium

I was unable to reproduce this bug.  I am also using sway.  Also thanks
for the tip about emacs-next-pgtk.  I didn't know that was packaged!

joshua@crazyhorse ~ (master)> guix describe
Generation 45   Oct 20 2022 12:44:46(current)
  guix 00ff6f7
repository URL: https://git.savannah.gnu.org/git/guix.git
branch: master
commit: 00ff6f7c399670a76efffb91276dea2633cc130c
  guixrus 762841a
repository URL: https://git.sr.ht/~whereiseveryone/guixrus
branch: master
commit: 762841aa3fc5140597dd09a8082cf2ad71539f66
  nonguix 2a368a2
repository URL: https://gitlab.com/nonguix/nonguix
branch: master
commit: 2a368a20cc0bc9de566316978749f7bc7f021627


joshua@crazyhorse ~ (master)> guix system describe
Generation 27   Oct 13 2022 12:21:15(current)
  file name: /var/guix/profiles/system-27-link
  canonical file name: /gnu/store/xjdqzg2np46c1ks0qwcyv77wgyf3p184-system
  label: GNU with Linux-Libre 5.19.14
  bootloader: grub
  root device: /dev/mapper/cryptroot
  kernel: 
/gnu/store/8s41d36dgb700p3g5jbgl5vy7wi7lbsw-linux-libre-5.19.14/bzImage
  channels:
guix:
  repository URL: https://git.savannah.gnu.org/git/guix.git
  branch: master
  commit: 56915dc275994336efd15199769d78ae295e2339
  configuration file: 
/gnu/store/rgw0i1qg29nq5jxk2mcpmvdigrwk4h3i-configuration.scm

>
> Generation 75 Oct 17 2022 15:54:07(current)
>   rde 05225a3
> repository URL: https://git.sr.ht/~abcdw/rde
> branch: master
> commit: 05225a3a20e2f3eba9ebaa3df4cdce3e8b0c33c1
>   guix 3ab1438
> repository URL: file:///home/bob/work/gnu/guix
> branch: master
> commit: 3ab14386cd2a3fc4bacf2291ee585a0685aceb17

bug#58321: make issues.guix.gnu.org a little easier in the desktop

[Joshua Branson via Bug reports for GNU Guix]

zimoun  writes:

> Hi,
>
> On mer., 05 oct. 2022 at 21:20, jbranso--- via Bug reports for GNU Guix 
>  wrote:
>
>> We could perhaps:
>>
>> 1 number each message and sidebar link
>>
>> 2 highlight which link in the sidebar that corresponds to the currently 
>> viewed message.
>
> I agree it could be helpful.  Just a minor workaround while waiting a
> fix. :-)
>
> For complex thread, what I do (when I do not use the Emacs front-end of
> Debbugs :-)) is to read them using a Web frontend of some public-inbox
> instance.  For instance,
>
>  1. I click to the icon download [1],
>  2. search Message-ID (here line 43),
>  3. copy/stash it (here 87fulrsqxx@gnu.org),
>  4. paste it to the navigation bar appending the public-inbox URL (here
>  https://yhetil.org/guix/).
>
> Last, I am usually interested by the thread overview so I add ’/#r’ to
> the URL, as in [2].
>
>
> 1: 
> 2: 
>
>
> Cheers,
> simon
>

Thanks for sharing your workflow!

bug#57110: home: services: Broken openssh service.

[Joshua Branson via Bug reports for GNU Guix]

Maxim Cournoyer  writes:

> Hi,
>
> Oleg Pykhalov  writes:
>
>> home ssh service is broken on:
>>
>> $ guix describe
>> Generation 33Aug 10 2022 10:50:55(current)
>>   guix b72459a
>> repository URL: https://git.savannah.gnu.org/git/guix.git
>> branch: master
>> commit: b72459a861d7029d69e9e3ffe3dd411b452e26de
>>
>>
>
> Fixed with d9a0ccf13f.  Sorry for the breakage!
>
>
> Maxim


Wow a fix provided in one day!  Maxim how!?  I am having a hard time
just cleaning my room!  :)

bug#56866: [Shepherd] inetd connections not correctly counted?

[Joshua Branson via Bug reports for GNU Guix]

Ludovic Courtès  writes:

> Hi,
>
> Ludovic Courtès  skribis:
>
>> We recently experienced a bug on berlin.guix where we’d be locked out of
>> SSH access because shepherd (0.9.1) would say that the maximum
>> connection number on the sshd inetd service had been reached.


Perhaps we could merge bug

https://issues.guix.gnu.org/39136

And use endlessh on berlin.  That might help.


>
> On berlin.guix, which is getting hammered, we see things like this:
>
> Aug  9 23:32:13 localhost shepherd[1]: Service sshd-4183 (PID 55570) exited 
> with 255.
> Aug  9 23:32:13 localhost shepherd[1]: Service sshd-4183 has been disabled.
> Aug  9 23:32:13 localhost shepherd[1]: Transient service sshd-4183 
> terminated, now unregistered.
> Aug  9 23:32:15 localhost shepherd[1]: Accepted connection on 0.0.0.0:22 from 
> X.X.X.104:39528.
> Aug  9 23:32:15 localhost shepherd[1]: Service sshd-4189 has been started.
> Aug  9 23:32:20 localhost shepherd[1]: Accepted connection on 0.0.0.0:22 from 
> X.X.X.104:40378.
> Aug  9 23:32:21 localhost shepherd[1]: Service sshd-4190 has been started.
> Aug  9 23:32:25 localhost shepherd[1]: Accepted connection on 0.0.0.0:22 from 
> X.X.X.104:41190.
> Aug  9 23:32:25 localhost sshd[55635]: error: kex_exchange_identification: 
> Connection closed by remote host
> Aug  9 23:32:25 localhost sshd[55635]: Connection closed by X.X.X.167 port 
> 50938
> Aug  9 23:32:26 localhost shepherd[1]: Service sshd-4191 has been started.
> Aug  9 23:32:26 localhost shepherd[1]: 7 connections still in use after 
> sshd-4185 termination.
> Aug  9 23:32:26 localhost shepherd[1]: Service sshd-4185 (PID 55635) exited 
> with 255.
> Aug  9 23:32:26 localhost shepherd[1]: Service sshd-4185 has been disabled.
> Aug  9 23:32:26 localhost shepherd[1]: Transient service sshd-4185 
> terminated, now unregistered.
> Aug  9 23:32:30 localhost shepherd[1]: Accepted connection on 0.0.0.0:22 from 
> X.X.X.104:41918.
> Aug  9 23:32:31 localhost shepherd[1]: Service sshd-4192 has been started.
> Aug  9 23:32:34 localhost sshd[55632]: error: kex_exchange_identification: 
> Connection closed by remote host
> Aug  9 23:32:34 localhost sshd[55632]: Connection closed by X.X.X.167 port 
> 50966
> Aug  9 23:32:34 localhost shepherd[1]: 7 connections still in use after 
> sshd-4184 termination.
> Aug  9 23:32:34 localhost shepherd[1]: Service sshd-4184 (PID 55632) exited 
> with 255.
> Aug  9 23:32:34 localhost shepherd[1]: Service sshd-4184 has been disabled.
> Aug  9 23:32:34 localhost shepherd[1]: Transient service sshd-4184 
> terminated, now unregistered.
> Aug  9 23:32:35 localhost shepherd[1]: Accepted connection on 0.0.0.0:22 from 
> X.X.X.104:42736.
> Aug  9 23:32:36 localhost shepherd[1]: Service sshd-4193 has been started.
> Aug  9 23:32:40 localhost shepherd[1]: Accepted connection on 0.0.0.0:22 from 
> X.X.X.104:43492.
> Aug  9 23:32:41 localhost shepherd[1]: Service sshd-4194 has been started.
> Aug  9 23:32:44 localhost sshd[56155]: error: kex_exchange_identification: 
> Connection closed by remote host
> Aug  9 23:32:44 localhost sshd[56155]: Connection closed by X.X.X.80 port 
> 52450
> Aug  9 23:32:44 localhost shepherd[1]: 8 connections still in use after 
> sshd-4186 termination.
> Aug  9 23:32:44 localhost shepherd[1]: Service sshd-4186 (PID 56155) exited 
> with 255.
> Aug  9 23:32:44 localhost shepherd[1]: Service sshd-4186 has been disabled.
> Aug  9 23:32:44 localhost shepherd[1]: Transient service sshd-4186 
> terminated, now unregistered.
> Aug  9 23:32:45 localhost shepherd[1]: Accepted connection on 0.0.0.0:22 from 
> X.X.X.104:44194.
> Aug  9 23:32:46 localhost shepherd[1]: Service sshd-4195 has been started.
> Aug  9 23:32:53 localhost shepherd[1]: Accepted connection on 0.0.0.0:22 from 
> X.X.X.104:45170.
> Aug  9 23:32:53 localhost shepherd[1]: Service sshd-4196 has been started.
> Aug  9 23:32:56 localhost ntpd[1706]: Soliciting pool server X.X.X.107
> Aug  9 23:32:58 localhost shepherd[1]: Accepted connection on 0.0.0.0:22 from 
> X.X.X.104:45846.
> Aug  9 23:32:58 localhost shepherd[1]: Service sshd-4197 has been started.
> Aug  9 23:33:03 localhost shepherd[1]: Accepted connection on 0.0.0.0:22 from 
> X.X.X.104:46514.
> Aug  9 23:33:03 localhost shepherd[1]: Service sshd-4198 has been started.
> Aug  9 23:33:08 localhost shepherd[1]: Accepted connection on 0.0.0.0:22 from 
> X.X.X.104:47230.
> Aug  9 23:33:08 localhost shepherd[1]: Service sshd-4199 has been started.
> Aug  9 23:33:13 localhost shepherd[1]: Accepted connection on 0.0.0.0:22 from 
> X.X.X.104:47940.
> Aug  9 23:33:13 localhost shepherd[1]: Service sshd-4200 has been started.
> Aug  9 23:33:17 localhost sshd[56715]: error: kex_exchange_identification: 
> client sent invalid protocol identifier ""
> Aug  9 23:33:17 localhost sshd[56715]: banner exchange: Connection from 
> X.X.X.104 port 37546: invalid format
> Aug  9 23:33:17 localhost shepherd[1]: 13 connections still in use after 
> sshd-4188 termination.
> Aug  9 23:33:17 localhos

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

[Joshua Branson via Bug reports for GNU Guix]

"("  writes:

> On Sat Aug 6, 2022 at 2:38 AM BST, Tobias Geerinckx-Rice wrote:
>> Either of you feel like practicing a 'simple deprecation'?  ;-)
> Done at #57014 :)
>

I am going to try to close this bug report.  All further bug reports
should look at 57014.  If I cannot close the bug report.  Will someone
else please close this bug?

Thanks,
Joshua

>
> -- (

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#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#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#56114: Guix does not have a documented general and practical procedure for lowering a single lowerable object to the /gnu/store/... string.

[Joshua Branson via Bug reports for GNU Guix]

Whoops.  I sent my original message to the list, not directly to ya'll.

,build and ,lower are awesome!  I reccomend that we add ludo's proposed
patch into guix.  It's awesome!

Thanks,

Joshua

bug#51383: (no subject)

[Joshua Branson]

Bug will not be fixed.

bug#51383: noobie way of incorrectly using (guix records)

[Joshua Branson via Bug reports for GNU Guix]

zimoun  writes:

> Hi,
>
> On Mon, 25 Oct 2021 at 02:15, Joshua Branson via Bug reports for GNU Guix 
>  wrote:
>
>> So I made a pretty noobie-like mistake a few minutes ago.  When one
>> tries to make a (record-configuration), he invariably create an
>> infinite number of records.  The guile compiler eventually runs out
>> of memory and stops compiling.
>>
>> (use-modules (guix records))
>>
>> (define-record-type* 
>>   record-configuration make-record-configuration
>>   record-configuration?
>>   (command record-configuration-command
>>;; the error is here is on the next line
>>(default (record-configuration  
>>
>> (record-configuration)
>
> This  is defined by creating recursively another
> instance.  Thus, It is expected that it does not work, no?

Yes that is correct.  I am only slightly annoyed at the lack of a
helpful error message.  Thanks for helping me clarify my point.  I was
working on a rather large collection of guix records for an opensmtpd
service configuration.  The file is about 1,000 lines long.  Trying to
find that error without a helpful error message was slightly annoying.

I agree that the fault was mine and I do not believe the bug can be
fixed.  Rather it would be nice to have a more helpful error message.

It could be possible that guile offers such flexibility in general that
the compiler is unable to provide good error messages in all situations.
I am just hoping for a better error message somewhere, ether in the
compiler or something in the (define-syntax-record* macro.  Is it
possible to get a better error message?  Is that a thing worth pursuing?
Or is the fix worse than the present condition?

> Reading the doc,
>
>   1. what do you want to achieve?
>   2. what does it appear to you buggy?  Or what do you think the
>  “correct” behaviour should be?
>
> (define-syntax define-record-type*
>   (lambda (s)
> "Define the given record type such that an additional \"syntactic
> constructor\" is defined, which allows instances to be constructed with named
> field initializers, à la SRFI-35, as well as default values.  An example use
> may look like this:
>
>   (define-record-type*  thing make-thing
> thing?
> this-thing
> (name  thing-name (default \"chbouib\"))
> (port  thing-port
>(default (current-output-port)) (thunked))
> (loc   thing-location (innate) (default (current-source-location
>
> This example defines a macro 'thing' that can be used to instantiate records
> of this type:
>
>   (thing
> (name \"foo\")
> (port (current-error-port)))
>
> The value of 'name' or 'port' could as well be omitted, in which case the
> default value specified in the 'define-record-type*' form is used:
>
>   (thing)
>
> The 'port' field is \"thunked\", meaning that calls like '(thing-port x)' will
> actually compute the field's value in the current dynamic extent, which is
> useful when referring to fluids in a field's value.  Furthermore, that thunk
> can access the record it belongs to via the 'this-thing' identifier.
>
> A field can also be marked as \"delayed\" instead of \"thunked\", in which
> case its value is effectively wrapped in a (delay …) form.
>
> A field can also have an associated \"sanitizer\", which is a procedure that
> takes a user-supplied field value and returns a \"sanitized\" value for the
> field:
>
>   (define-record-type*  thing make-thing
> thing?
> this-thing
> (name  thing-name
>(sanitize (lambda (value)
>(cond ((string? value) value)
>  ((symbol? value) (symbol->string value))
>  (else (throw 'bad! value)))
>
> It is possible to copy an object 'x' created with 'thing' like this:
>
>   (thing (inherit x) (name \"bar\"))
>
> This expression returns a new object equal to 'x' except for its 'name'
> field and its 'loc' field---the latter is marked as \"innate\", so it is not
> inherited."
>
>
> (Argh, I do not know how to read/display the docstring from the REPL,
> another annoying* story. :-))

Do you know if the above guix records are in the guix manual?  If not,
I'll probably add them.

>
>> This is not possible with (srfi sfri-9)
>>
>> (use-modules (srfi srfi-9))
>>
>> (define-record-type 
>>   (make-employee name age (make-employeee 5 5 5))
>>   employee?
>>   (name 

bug#51383: noobie way of incorrectly using (guix records)

[Joshua Branson via Bug reports for GNU Guix]

So I made a pretty noobie-like mistake a few minutes ago.  When one
tries to make a (record-configuration), he invariably create an
infinite number of records.  The guile compiler eventually runs out
of memory and stops compiling.

(use-modules (guix records))

(define-record-type* 
  record-configuration make-record-configuration
  record-configuration?
  (command record-configuration-command
   ;; the error is here is on the next line
   (default (record-configuration  

(record-configuration)


This is not possible with (srfi sfri-9)


(use-modules (srfi srfi-9))

(define-record-type 
  (make-employee name age (make-employeee 5 5 5))
  employee?
  (nameemployee-name)
  (age employee-ageset-employee-age!)
  (salary  employee-salary set-employee-salary!))

(make-employee)


The above results in a syntax error.


Is this a "feature" and not a bug?  I feel like this is a trivial bug,
and I am certain that other bugs are of greater importance.

Thanks,

Joshua

bug#50478: No network on GNU/Hurd, not even localhost

[Joshua Branson via Bug reports for GNU Guix]

Akib Azmain Turja  writes:

> I've downloaded latest QEMU image from build servers (build details:
> https://ci.guix.gnu.org/build/618573/details).  Then I booted it with
> libvirtd on my Guix System on GNU/Linux.  It booted and the login shell

Is this the same as booting it with qemu?  I know I've had issues with
no internet access with the Hurd too, but I'm not a very technical user,
so it's most likely operator error.

> Can someone help me with this issue?  The QEMU image is almost unusable
> without networking.
>
> Note: all commands and their outputs are copied by hand.

I wish I had more knowledge to help you out.  

-- 
Joshua Branson (jab in #guix)
Sent from Emacs and Gnus
  https://gnucode.me
  https://video.hardlimit.com/accounts/joshua_branson/video-channels
  https://propernaming.org
  "You can have whatever you want, as long as you help
enough other people get what they want." - Zig Ziglar
  

bug#48974: A possible shepherd bug (it's very minor)

[Joshua Branson via Bug reports for GNU Guix]

Leo Prikler  writes:

> Hi,
>
> Am Freitag, den 02.07.2021, 18:57 -0400 schrieb Joshua Branson:
>> Leo Prikler  writes:
>> 
>> > Am Freitag, den 25.06.2021, 14:06 -0400 schrieb Joshua Branson:
>> > > Leo Prikler  writes:
>> > > 
>> > > > Hi,
>> > > > 
>> > > > Am Freitag, den 25.06.2021, 05:31 -0400 schrieb Joshua Branson:
>> > > > > Leo Prikler  writes:
>> > > 
>> > > Thanks again!  The current code doesn't quite work for me
>> > > yet.  I'll
>> > > try using match-lambda to define it.  I'll post again when I have
>> > > a
>> > > free moment.  When i get it working, I'll send a patch to the
>> > > manual
>> > > via guix-patches and CC you.  Is that ok?  Or would you rather
>> > > that
>> > > documentation be in the cookbook?
>> > Did I make a mistake or does it do the job only in a somewhat
>> > inelegant
>> > way?  I'm perfectly fine with the latter as I'm not the one using
>> > the
>> > code :P
>> 
>> I've got some code now that works!
>> 
>> #+BEGIN_SRC scheme
>> (define (auto-login-to-tty tty user config)
>>   (if (string=? tty (mingetty-configuration-tty config))
>> (mingetty-configuration
>>  (inherit config)
>>  (auto-login user))
> Why do you need to inherit the config, when it doesn't change?  Seems
> like a pointless allocation to me.
>> (mingetty-configuration
>>  (inherit config
>> 
>> ;; allegedly %desktop-services now contains network-manager-
>> applet...?  Can I remove that?
> Not with modify-services, but there's some filter example in the manual
> as well.
>> (define %my-desktop-services
>>   (modify-services %desktop-services ;;end of remove services
>> (mingetty-service-type config =>
>>(auto-login-to-tty "3" "joshua" config
>> 
>> #+END_SRC
>> 
>> > I think the cookbook is a better destination for stuff like this.
>> 
>> I agree, but we should also probably fix the manual:
>> 
>> 10.1 Using the Configuration System
>> ===
>> 
>> System Services
>> 
>>For example, suppose you want to modify ‘guix-daemon’ and Mingetty
>> (the console log-in) in the ‘%base-services’ list (*note
>> ‘%base-services’: Base Services.).  To do that, you can write the
>> following in your operating system declaration:
>> 
>> 
>>  (define %my-services
>>;; My very own list of services.
>>(modify-services %base-services
>>  (guix-service-type config =>
>> (guix-configuration
>>  (inherit config)
>>  ;; Fetch substitutes from example.org.
>>  (substitute-urls
>>(list "https://example.org/guix";
>>  "https://ci.guix.gnu.org";
>> ;; it looks like the manual is telling you to set up
>> ;; auto login on ALL ttys.
>>  (mingetty-service-type config =>
>> (mingetty-configuration
>>  (inherit config)
>>  ;; Automatially log in as "guest".
>>  (auto-login "guest")
>> 
>>  (operating-system
>>;; ...
>>(services %my-services))
>> 
>> How about I delete that section in the manual about automatic login
>> and
>> instead add this to the cookbook?
> No.  Read on, the manual clearly states that this affects *all* TTYs. 
> Presumably the guest user only has access to su and logout, maybe guix,
> but in any case they ought not to have access to anyone's $HOME, not
> even their own.
>
> The thing we've coded up here is a more involved process to solve a
> particular problem rather than a general demo of what services can do
> and thus belongs to the cookbook.
>
> Regards,
> Leo
>

-- 
Joshua Branson (joshuaBPMan in #guix)
Sent from Emacs and Gnus
  https://gnucode.me
  https://video.hardlimit.com/accounts/joshua_branson/video-channels
  https://propernaming.org
  "You can have whatever you want, as long as you help
enough other people get what they want." - Zig Ziglar
  

bug#48974: A possible shepherd bug (it's very minor)

[Joshua Branson via Bug reports for GNU Guix]

Leo Prikler  writes:

> Am Freitag, den 25.06.2021, 14:06 -0400 schrieb Joshua Branson:
>> Leo Prikler  writes:
>>
>> > Hi,
>> >
>> > Am Freitag, den 25.06.2021, 05:31 -0400 schrieb Joshua Branson:
>> > > Leo Prikler  writes:
>>
>> Thanks again!  The current code doesn't quite work for me yet.  I'll
>> try using match-lambda to define it.  I'll post again when I have a
>> free moment.  When i get it working, I'll send a patch to the manual
>> via guix-patches and CC you.  Is that ok?  Or would you rather that
>> documentation be in the cookbook?
> Did I make a mistake or does it do the job only in a somewhat inelegant
> way?  I'm perfectly fine with the latter as I'm not the one using the
> code :P

I've got some code now that works!

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

;; allegedly %desktop-services now contains network-manager-applet...?  Can I 
remove that?
(define %my-desktop-services
  (modify-services %desktop-services ;;end of remove services
(mingetty-service-type config =>
   (auto-login-to-tty "3" "joshua" config

#+END_SRC

> I think the cookbook is a better destination for stuff like this.

I agree, but we should also probably fix the manual:

10.1 Using the Configuration System
===

System Services

   For example, suppose you want to modify ‘guix-daemon’ and Mingetty
(the console log-in) in the ‘%base-services’ list (*note
‘%base-services’: Base Services.).  To do that, you can write the
following in your operating system declaration:


 (define %my-services
   ;; My very own list of services.
   (modify-services %base-services
 (guix-service-type config =>
(guix-configuration
 (inherit config)
 ;; Fetch substitutes from example.org.
 (substitute-urls
   (list "https://example.org/guix";
 "https://ci.guix.gnu.org";
;; it looks like the manual is telling you to set up
;; auto login on ALL ttys.
 (mingetty-service-type config =>
(mingetty-configuration
 (inherit config)
 ;; Automatially log in as "guest".
 (auto-login "guest")

 (operating-system
   ;; ...
   (services %my-services))

How about I delete that section in the manual about automatic login and
instead add this to the cookbook?

Section Title:  Setting up automatic login for one tty 

The interested hacker, who wishes to set up automatic login to tty three
can use the following code snippet:

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

(operating-system
  (host-name "dobby")
  ...
  (services
(cons*
  (modify-services %base-services
(mingetty-service-type config =>
   (auto-login-to-tty "3" "joshua" config
#+END_SRC

>
> Regards,
> Leo
>

--
Joshua Branson (joshuaBPMan in #guix)
Sent from Emacs and Gnus
  https://gnucode.me
  https://video.hardlimit.com/accounts/joshua_branson/video-channels
  https://propernaming.org
  "You can have whatever you want, as long as you help
enough other people get what they want." - Zig Ziglar

bug#48974: A possible shepherd bug (it's very minor)

[Joshua Branson via Bug reports for GNU Guix]

Leo Prikler  writes:

> Hi,
>
> Am Freitag, den 25.06.2021, 05:31 -0400 schrieb Joshua Branson:
>> Leo Prikler  writes:
>>
>> > Hi,
>> >
>> > Am Samstag, den 12.06.2021, 20:09 + schrieb jbra...@dismail.de:
>> > > June 12, 2021 3:39 PM, "Leo Prikler" <
>> > > leo.prik...@student.tugraz.at>
>> > > wrote:
>> > >
>> > > > Am Samstag, den 12.06.2021, 09:26 -0400 schrieb Joshua Branson:
>> > > >
>> > > > > Hello!
>> > > > >
>> > > I'll tell you what, why don't we leave this "bug" open for a
>> > > week...I'll try to write
>> > > the code that does what I want, and I'll email the answer.
>> > >
>> > > Then I'll edit the manual to provide an example!
>> Well, it's been about a week. Here is my current code that doesn't
>> work.
>> haha.
>>
>> #+BEGIN_SRC scheme
>> (define %my-desktop-services
>>   (modify-services %desktop-services ;;end of remove services
>> (mingetty-service-type config =>
>>(mingetty-configuration
>> (inherit config)
>> ;; ERROR at the NEXT LINE
>> (auto-login-to-tty-3 config)
>> 
>>
>> (define (auto-login-to-tty-3 config)
>>   (if (string=? "3" (mingetty-configuration-tty config))
>>   '(auto-login "joshua")
>>   '(auto-login #f)))
>> #+END_SRC
>>
>> It obviously doesn't work because I am treating modify-services as if
>> it were a procedure.  In fact, it is a macro.  :)
> That's not the issue here, the issue is that you're treating mingetty-
> configuration as… I'm not really sure what exactly, when it is in fact
> a record constructor.

Oh Light bulb!  I knew that!  I've made quite a few record
constructors for endlessh and my almost complete sway service:

http://issues.guix.gnu.org/39136
https://notabug.org/jbranso/guix-config/src/master/sway-service.scm

>
> Try the following:
>
> #+BEGIN_SRC scheme
> (define (auto-login-to-tty tty user)
>   ;; TODO: you might want to implement this as match-lambda instead

I will try that!

>   (lambda (config)
> (if (string=? tty (mingetty-configuration-tty mingetty-config))
> (mingetty-configuration
>   (inherit config)
>   (auto-login user))
> config)))
>
> (define %my-desktop-services
>   (modify-services %desktop-services
>
> (mingetty-service-type config =>
>   (auto-login-
> to-tty "3" "joshua"
> #+END_SRC
>

Hmmm.  Is that (define (auto-login-to-tty tty user) ...) a closure?  I
wonder why you need that lambda inside of it...Probably to pass the
config variable into the function...hmmm.  I still don't understand why
it is necessary.  I'll think about that a bit later on.

>
>> #+BEGIN_SRC scheme
>> (define (auto-login-to-tty-3 mingetty-service)
>>   (if (string=? "3" (mingetty-configuration-tty config))
>>   '(mingetty-configuration
>>  (auto-login "joshua")
>>  (tty "3"))
>>   mingetty-service))
> Don't quote mingetty-configuration et al.  They're first-class syntax,
> not just weird lists.

Yeah that's true.  I do actually like (guix records)!  I feel like that
file should be upstreamed into guile!

>
>> (define (my-modify-%desktop-services-to-auto-login-on-tty-3 %desktop-
>> services)
>>;; to be written
>>;; though I think fold, or map, may be useful functions here.
>>
>>;;somehow I will use this function...
>> (auto-login-to-tty-3 mingetty-service)
>> )
>>
>> (define %my-desktop-services
>> (my-modify-%desktop-services-to-auto-login-on-tty-3 %desktop-
>> services))
> I don't think you need to implement modify-services on your own, rather
> just use the existing thing in the "correct" way – i.e. adhering to the
> expectations given by the already existing procedure (or macro).

Thanks again!  The current code doesn't quite work for me yet.  I'll try
using match-lambda to define it.  I'll post again when I have a free
moment.  When i get it working, I'll send a patch to the manual via
guix-patches and CC you.  Is that ok?  Or would you rather that
documentation be in the cookbook?

>> #+END_SRC
> Regards,
> Leo
>

--
Joshua Branson (joshuaBPMan in #guix)
Sent from Emacs and Gnus
  https://gnucode.me
  https://video.hardlimit.com/accounts/joshua_branson/video-channels
  https://propernaming.org
  "You can have whatever you want, as long as you help
enough other people get what they want." - Zig Ziglar

bug#48974: A possible shepherd bug (it's very minor)

[Joshua Branson via Bug reports for GNU Guix]

Leo Prikler  writes:

> Hi,
>
> Am Samstag, den 12.06.2021, 20:09 + schrieb jbra...@dismail.de:
>> June 12, 2021 3:39 PM, "Leo Prikler" 
>> wrote:
>>
>> > Am Samstag, den 12.06.2021, 09:26 -0400 schrieb Joshua Branson:
>> >
>> > > Hello!
>> > >
>> I'll tell you what, why don't we leave this "bug" open for a
>> week...I'll try to write
>> the code that does what I want, and I'll email the answer.
>>
>> Then I'll edit the manual to provide an example!
> I'm pretty sure that the actual bug also exists, just not sure whether
> that's on your config or on shepherd.  Using TTY1 for graphical stuff
> is also somewhat rare in Guix land, I presume.  (Or rather, I can't
> think of it as anything but a container for debug output spam :D)
>
> As for getting this to work only on TTY1, you do get the config object,
> so you can do stuff like
>   (if (is-tty1? config) (inherit+autologin config) config)
> Note of course, that is-tty1? is not a procedure that's ready-made, but
> one that you'd need to build from primitives such as record accessors.
>

Well, it's been about a week. Here is my current code that doesn't work.
haha.

#+BEGIN_SRC scheme
(define %my-desktop-services
  (modify-services %desktop-services ;;end of remove services
(mingetty-service-type config =>
   (mingetty-configuration
(inherit config)
;; ERROR at the NEXT LINE
(auto-login-to-tty-3 config)


(define (auto-login-to-tty-3 config)
  (if (string=? "3" (mingetty-configuration-tty config))
  '(auto-login "joshua")
  '(auto-login #f)))
#+END_SRC

It obviously doesn't work because I am treating modify-services as if it
were a procedure.  In fact, it is a macro.  :)

I'm just popping in to give you an update on my progress.  I've probably
spent less than 20 minutes working on this.  The good news is I did find
the record accessor for tty is mingetty-configuration-tty.

My goal for the next week is to do something like this:

#+BEGIN_SRC scheme
(define (auto-login-to-tty-3 mingetty-service)
  (if (string=? "3" (mingetty-configuration-tty config))
  '(mingetty-configuration
 (auto-login "joshua")
 (tty "3"))
  mingetty-service))

(define (my-modify-%desktop-services-to-auto-login-on-tty-3 %desktop-services)
   ;; to be written
   ;; though I think fold, or map, may be useful functions here.

   ;;somehow I will use this function...
(auto-login-to-tty-3 mingetty-service)
)

(define %my-desktop-services
(my-modify-%desktop-services-to-auto-login-on-tty-3 %desktop-services))
#+END_SRC


I'll post again in about a week to tell you about my progress!

--
Joshua Branson (joshuaBPMan in #guix)
Sent from Emacs and Gnus
  https://gnucode.me
  https://video.hardlimit.com/accounts/joshua_branson/video-channels
  https://propernaming.org
  "You can have whatever you want, as long as you help
enough other people get what they want." - Zig Ziglar

bug#48974: A possible shepherd bug (it's very minor)

[Joshua Branson via Bug reports for GNU Guix]

Hello!

I've had this issue every since I enabled automatic login on my guix
system like so:

#+BEGIN_SRC scheme
(define %my-desktop-services
  (modify-services
  %desktop-services 
(mingetty-service-type config =>
   (mingetty-configuration
(inherit config)
;;auto login as joshua
(auto-login "joshua")

(operating-system
   ...
   (services (list %my-desktop-services)))
#+END_SRC

This is the "error message"

#+BEGIN_SRC sh
This is the GNU system.  Welcome
dobby login: joshua (automatic login)
This is the GNU operating system, welcome!

Cannot make/remove an entry for the specified session
#+END_SRC

Essentially, mingetty tries to auto log me in, but I am using desktop
services.  So mingetty tries to log me in, before many of the desktop
services are started.  However, I guess this doesn't work.  Meaning,
my autostart sway script is NOT run, until AFTER all of the desktop
services are started.  WHICH IS PROBABLY A GOOD IDEA.  I would rather
log in, when my desktop services have started, not before.

BUT the minor issue is that after I log in, =users= reports:

#+BEGIN_SRC sh
joshua@dobby ~> users
joshua joshua joshua joshua joshua joshua
#+END_SRC

So it looks like 6 versions of myself are logged in by the time I am
officially logged in and I auto start sway via .bash_profile:

#+BEGING_SRC sh
# Honor per-interactive-shell startup file
if [ -f ~/.bashrc ]; then . ~/.bashrc; fi

# shepherd

if [[ -z $DISPLAY ]] && [[ $(tty) = /dev/tty1 ]]; then
export MOZ_ENABLE_WAYLAND=1
export GUIX_PACKAGE_PATH=/home/joshua/prog/gnu/guix/guix-packages/

XDG_DATA_DIRS=/var/lib/flatpak/exports/share:/home/joshua/.local/share/flatpak/exports/share:$XDG_DATA_DIRS
# this may fix a bug that I have with termite confusing backspace as space 
in guix environment
# export TERM=linux
shepherd -c /home/joshua/.config/shepherd/init.scm &
exec dbus-run-session sway
fi
#+END_SRC 


I'm guessing the root cause is that the shepherd starts most services
sequentially at the moment.  Anyway, I thought I'd share a minor issue
with you all!


Thanks!

Joshua Branson

bug#48973: An early booting warning message

[Joshua Branson via Bug reports for GNU Guix]

Hello!

I've seen this warning message from my boot screen pretty much every
time I boot guix system on my T400.

[ 36.909489] Error: Driver 'pcspkr' is already registered, aborting...



The system boots just fine, but I figured I'd report this error
message.

Thanks!


Joshua

bug#48972: Early guile repl is giving me some GC Warnings

[Joshua Branson via Bug reports for GNU Guix]

Hello!

My librebooted Thinkpad T400 has been giving me the same GC warning
for about 2 years now:

GC: Warning: pthread_getattr_np or pthread_attr_getstack failed for
main thread
GC Warning: Couldn't read /proc/stat
Welcome, this is GNU's early boot guile
Use --repl for an initrd REPL.

Loading kernel modules...


I system boots just fine, but I figured that I should mention this!

Thanks,

Joshua

bug#48636: Gajim does not load the "close" icon on the chat window

[Joshua Branson via Bug reports for GNU Guix]

"bdju"  writes:

> On Mon May 24, 2021 at 6:19 PM CDT, Joshua Branson via Bug reports for GNU 
> Guix wrote:
>> It also doesn't remember my password. I have to type it in again
>> everytime I open Gajim.
>
> You can work around this part by going to Gajim menu -> Preferences ->
> Advanced and toggling "Use System Keyring" to off. In theory setting up
> something like gnome keyring or similar should also work with the
> default setting and then save/access passwords that way. I could not
> figure it out after hours of trying stuff, but if you toggle that
> setting, it will save your passwords without relying on a keyring. I'm
> not sure if it's less secure or something in exchange.
>

Thanks!  That worked!


--
Joshua Branson (joshuaBPMan in #guix)
Sent from Emacs and Gnus
  https://gnucode.me
  https://video.hardlimit.com/accounts/joshua_branson/video-channels
  https://propernaming.org
  "You can have whatever you want, as long as you help
enough other people get what they want." - Zig Ziglar

bug#48636: Gajim does not load the "close" icon on the chat window

[Joshua Branson via Bug reports for GNU Guix]

Other clues that the chat on irc disclosed:

#+BEGIN_SRC sh
joshua@dobby ~> env | grep XDG
XDG_SEAT=seat0
XDG_RUNTIME_DIR=/run/user/1000
XDG_DATA_DIRS=/var/lib/flatpak/exports/share:/home/joshua/.local/share/flatpak/exports/share:/home/joshua/.guix-profile/share:/run/current-system/profile/share:/home/joshua/.guix-profile/share:/run/current-system/profile/share
XDG_SESSION_CLASS=user
XDG_DESKTOP_PORTAL_DIR=/home/joshua/.guix-profile/share/xdg-desktop-portal/portals
XDG_CONFIG_DIRS=/home/joshua/.guix-profile/etc/xdg:/run/current-system/profile/etc/xdg
XDG_SESSION_ID=c3
XDG_VTNR=1
XDG_SESSION_TYPE=tty
#+END_SRC

#BEGIN_SRC sh
joshua@dobby ~> gajim
No translations found
Dirs searched: [PosixPath('/home/joshua/.local/share'), 
PosixPath('/gnu/store/5rzslgvj7ql028ifaqar7gyr5ggwps9s-shared-mime-info-1.15/share'),
 PosixPath('/gnu/store/3dfq8a6cqsvgqswy8d6crb7q2mrps8yh-gtk+-3.24.24/share'), 
PosixPath('/gnu/store/kksi41cjrrabsxsmpk8asj5grinlnd23-gsettings-desktop-schemas-3.34.0/share'),
 PosixPath('/gnu/store/gjqq86zakkwvvaz37zljhydfm728g0a7-glib-2.62.6/share'), 
PosixPath('/gnu/store/zpvvkz257anyn1wiabnzvgsayi3yx04d-gajim-1.3.2/share'), 
PosixPath('/gnu/store/5rzslgvj7ql028ifaqar7gyr5ggwps9s-shared-mime-info-1.15/share'),
 PosixPath('/gnu/store/3dfq8a6cqsvgqswy8d6crb7q2mrps8yh-gtk+-3.24.24/share'), 
PosixPath('/gnu/store/kksi41cjrrabsxsmpk8asj5grinlnd23-gsettings-desktop-schemas-3.34.0/share'),
 PosixPath('/gnu/store/gjqq86zakkwvvaz37zljhydfm728g0a7-glib-2.62.6/share'), 
PosixPath('/gnu/store/zpvvkz257anyn1wiabnzvgsayi3yx04d-gajim-1.3.2/share'), 
PosixPath('/var/lib/flatpak/exports/share'), 
PosixPath('/home/joshua/.local/share/flatpak/exports/share'), 
PosixPath('/home/joshua/.guix-profile/share'), 
PosixPath('/run/current-system/profile/share'), 
PosixPath('/home/joshua/.guix-profile/share'), 
PosixPath('/run/current-system/profile/share')]

(org.gajim.Gajim:6250): Gtk-WARNING **: 14:31:46.574: Could not find the icon 
'org.gajim.Gajim'. The 'hicolor' theme
was not found either, perhaps you need to install it.
You can get a copy from:
http://icon-theme.freedesktop.org/releases
05/21/2021 14:31:46 (W) gajim.plugin_systemError while loading module: 
gtk-icon-theme-error-quark: Icon 'preferences-system' not present in theme 
Adwaita (0)
05/21/2021 14:31:58 (W) gajim.c.storage.archiveExecution time for _commit: 
106 ms
05/21/2021 14:31:59 (W) gajim.c.storage.cache  Execution time for _commit: 
90 ms
#END_SRC

--
Joshua Branson (joshuaBPMan in #guix)
Sent from Emacs and Gnus
  https://gnucode.me
  https://video.hardlimit.com/accounts/joshua_branson/video-channels
  https://propernaming.org
  "You can have whatever you want, as long as you help
enough other people get what they want." - Zig Ziglar

bug#48636: Gajim does not load the "close" icon on the chat window

[Joshua Branson via Bug reports for GNU Guix]

Hello!

So Gajim does not load the close icon in the chat window under sway.
It also doesn't remember my password.  I have to type it in again
everytime I open Gajim.  Some people in #guix said that I should file
a bug report.  I am using a T400 laptop running osboot.

Obligatory screen shot is attached.

#BEGIN_SRC sh
joshua@dobby ~> guix describe
Generation 71   May 16 2021 02:18:09(current)
  guix 7c4c781
repository URL: https://git.savannah.gnu.org/git/guix.git
branch: master
commit: 7c4c781aa40c42d4cd10b8d9482199f3db345e1b

GUIX_PACKAGE_PATH="/home/joshua/prog/gnu/guix/guix-packages/"
joshua@dobby ~> guix system describe
Generation 90   May 16 2021 03:24:15(current)
  file name: /var/guix/profiles/system-90-link
  canonical file name: /gnu/store/8707xqvmv0mg8ix5flj2dqawk1ykzkvl-system
  label: GNU with Linux-Libre 5.11.21
  bootloader: grub
  root device: UUID: 0542cf20-9f62-49cf-992f-54a75186f2b2
  kernel: 
/gnu/store/53r3pzj18jshhkvm2ggiiy6gxqx5y2cr-linux-libre-5.11.21/bzImage
  channels:
guix:
  repository URL: https://git.savannah.gnu.org/git/guix.git
  branch: master
  commit: 7c4c781aa40c42d4cd10b8d9482199f3db345e1b
  configuration file: 
/gnu/store/092f6932hh3ci9r2kyhszh8ins5a8ygj-configuration.scm
#+END_SRC sh

bug#47192: issues.guix.org not showing patch series?

[Joshua Branson via Bug reports for GNU Guix]

I gather that this is not a very common bug.  So I suppose we'll close
this bug.

Thanks for your quick response Tobias!

-- 
Joshua Branson (joshuaBPMan in #guix)
Sent from Emacs and Gnus
  https://gnucode.me
  https://video.hardlimit.com/accounts/joshua_branson/video-channels
  https://propernaming.org
  "You can have whatever you want, as long as you help
enough other people get what they want." - Zig Ziglar
  

bug#47192: issues.guix.org not showing patch series?

[Joshua Branson via Bug reports for GNU Guix]

Hello!

I just submitted a patch series for an endlessh service!

However, issues.guix.gnu.org/39136 does not properly show the patch
series.  :( Maybe I just submitted the patch series incorrectly.  :)

You can see the patch series here:

https://lists.gnu.org/archive/html/guix-patches/2021-03/msg00672.html

And via

 M-x debbugs-gnu-bugs RET 39136 RET

I'm not certain what the issue is...

This is the command that I used to send the patch series.

#+BEGIN_SRC sh
git send-email --to=39...@debbugs.gnu.org HEAD~2
#+END_SRC

Thanks!

Your friend,

Joshua

bug#44053: ‘xdg-mime-database’ profile hook is slow

[Joshua Branson via Bug reports for GNU Guix]

 out 
/gnu/store/k8lnv9cqk6m15k18hhzg7w696r1vxx1v-openssh-8.4p1
grim1.3.1   out /gnu/store/9v5i9q7kwcmq1q31qri0icjkhh3csh9r-grim-1.3.1
evince  3.36.5  out 
/gnu/store/arwvpbrzsch4w6afkpqln6625dfl0bz8-evince-3.36.5
pulseaudio  13.0out 
/gnu/store/19wcjfwdr3hzq1a4wcpld1zdrjichck0-pulseaudio-13.0
libreoffice 6.4.6.2 out 
/gnu/store/7rbk52nzqmakd5whds5a6f07xrd2k870-libreoffice-6.4.6.2
termite 15  out /gnu/store/8lqfy0mxqnq3xg24gwsxvzpxnvv6firh-termite-15
mpv 0.32.0  out /gnu/store/2i2gzn7fa8qq0f1jkqhiyl0xw63fjr4w-mpv-0.32.0
pinentry1.1.0   out 
/gnu/store/bdsk9yq48lx1f7y7xr9sv4yrmm4ync9b-pinentry-1.1.0
glib2.62.6  doc 
/gnu/store/ql2226knbh4q04bbdiqcppvs5rjyl3ga-glib-2.62.6-doc
pidgin  2.13.0  out 
/gnu/store/fd06njmc5maid7b474v224iazy7bc20h-pidgin-2.13.0
gimp2.10.20 out /gnu/store/m397hvwhsd0l6v5d0vqxxkm4iyp0p9w3-gimp-2.10.20
sway1.4 out /gnu/store/27ggd92in0hpgmkgk79n2iy4angjxwvl-sway-1.4
wf-recorder 0.2.1   out 
/gnu/store/glc6y75l4czpfyrgbrbgxg38ig004v1p-wf-recorder-0.2.1
wofi1.1.2   out /gnu/store/qaylx0k6wg3awsamn2rqr41q9c8iwypg-wofi-1.1.2
linphoneqt  4.1.1   out 
/gnu/store/wlcviacpagxqnw1737x131if0fj7kzjv-linphoneqt-4.1.1
qbittorrent 4.2.5   out 
/gnu/store/29cjbdmz809pdvmylbx307l2p7zv0ma9-qbittorrent-4.2.5
pavucontrol 4.0 out 
/gnu/store/0ilm4lncr6gpg4h3zdvaxg1pibkm6934-pavucontrol-4.0
git 2.28.0  send-email  
/gnu/store/g5x559qk5yxs19jcxqplqv8b9y32vak2-git-2.28.0-send-email
flatpak 1.8.2   out 
/gnu/store/ywfsnccvlr0j6afb5vnl3z4ismvcfbz6-flatpak-1.8.2
xdg-desktop-portal  1.7.2   out 
/gnu/store/jkjx5dd7s3dp58p2hwsm8n2rm15z90ys-xdg-desktop-portal-1.7.2
xdg-desktop-portal-gtk  1.7.1   out 
/gnu/store/zhssisyp66vggjnqi5y8nb1xnk55vnw1-xdg-desktop-portal-gtk-1.7.1
xeyes   1.1.2   out /gnu/store/4jx8i19xd94d421n4acy2c1p0nn9h6d0-xeyes-1.1.2
emacs-polymode  0.2 out 
/gnu/store/gmm1y1xahg44yw9ghsf0kwd40w86q7mf-emacs-polymode-0.2
notmuch 0.31out /gnu/store/0js5dwj8nxj0x0hxfllgzz4zxlsmyrz4-notmuch-0.31
msmtp   1.8.12  out /gnu/store/s1g4nskvnsx9ww0032xg23548h7mnwvq-msmtp-1.8.12
youtube-viewer  3.7.9   out 
/gnu/store/jm7q53lpda3a4rs2z7xv7cgig7adpncb-youtube-viewer-3.7.9
guile-curl  0.6 out 
/gnu/store/9nnclxjxakwx9yc381arqrk1nhld21b5-guile-curl-0.6
qemu5.1.0   out /gnu/store/qzi36f60d2zlrdj9mg6b5y4i00w1fzfq-qemu-5.1.0
icecat  78.3.1-guix0-preview1   out 
/gnu/store/71fkykdajhkshsvzwrnqm4lsc6qgycg2-icecat-78.3.1-guix0-preview1
git 2.28.0  out /gnu/store/j66k3x1wz0bc6nh09dwa6i4jwahqcabi-git-2.28.0
guix1.1.0-29.4e3ed9bout 
/gnu/store/irirj169rncank4y7i6n8qyiiqbs76qr-guix-1.1.0-29.4e3ed9b
ffmpeg  4.3.1   out /gnu/store/sg4yq9i0v1lphvs1vx33dw9mn801adrd-ffmpeg-4.3.1
pavucontrol-qt  0.15.0  out 
/gnu/store/9d0zp4wps5kpbqsl4yvjb96spb5xwz9b-pavucontrol-qt-0.15.0
clementine  1.3.1-2.4619a4c out 
/gnu/store/5392fysgmmi2jmn98maz9ihzn9ahzhw9-clementine-1.3.1-2.4619a4c
mako1.4 out /gnu/store/k83v9wz6szf6k2p2sz1amvwqm687j3h2-mako-1.4
ungoogled-chromium  86.0.4240.75-0.c34a56d  out 
/gnu/store/m0s9mrbirbssis5nn9agx8k4sl2ck0y9-ungoogled-chromium-86.0.4240.75-0.c34a56d
#+end_example


Thanks,

--
Joshua Branson
Sent from Emacs and Gnus
https://gnucode.me
https://video.hardlimit.com/accounts/joshua_branson/video-channels
"You can have whatever you want, as long as you help enough other people get 
what they want." - Zig Ziglar

bug#39660: (no subject)

[Joshua Branson]

>>
>>- [ ] "persist-key"
>>- [ ] "persist-tun"
>We already have both of them. Are they not documented? They should be 
>persist-key? and persist-tun? respectively.

That was my mistake.  Please ignore that.  They are documented sir.
(sorry Military school).

>>- [ ] "remote-random"
>>- [ ] "pull"
>>- [X] "comp-lzo no"
>>- [ ] "tls-client"  does tls-auth provide this option???
>tls-auth and tls-client are different options. tls-client replaces the client 
>directive we currently generate for all openvpn-client-configuration.

When I look at my currently generated openvpn configuration file I see:
#+BEGIN_SRC
joshua@dobby ~/prog/guile/guix-config$ cat 
/gnu/store/nm4dvmsffrghdxjlqj712qhrv6w4fd4m-openvpn.conf
client
proto udp
dev tun
ca /home/joshua/prog/guile/guix-config/vpn/ca2.crt
cert /home/joshua/prog/guile/guix-config/vpn/client.crt
key /home/joshua/prog/guile/guix-config/vpn/client.key
persist-key 
persist-tun 
fast-io 
verb 3
auth-user-pass /home/joshua/prog/guile/guix-config/vpn/login.conf
remote-cert-tls server
nobind
resolv-retry infinite
remote asecretremote.com 1195
#+END_SRC

I do not see the "tls-client" option, but my working vpn client configuration 
file has "tls-client" in it.

My current vpn configuration is:

   (openvpn-client-service
#:config
(let ([base-dir "/home/joshua/prog/guile/guix-config/vpn/"])
  (openvpn-client-configuration
   (auth-user-pass (string-append base-dir "login.conf"))
   (ca (string-append base-dir "ca2.crt"))
   (cert (string-append base-dir "client.crt"))
   (key (string-append base-dir "client.key"))
   ;; the expressvpn file I use disables lzo compression
   (comp-lzo? #f)
   (fast-io? #t)
   (remote
(list
 (openvpn-remote-configuration
  (name "asecretremote.com")
  (port 1195)))


Also, I can confirm that your auth-user-pass does work.

Thanks,

Joshua

bug#39660: openvpn-client-service does not support auth-user-pass

[Joshua Branson via Bug reports for GNU Guix]

Julien and I discussed on irc that guix currently does not have a
method of generating my config file.  Here is just an updated list of
the options that I (and possibly others) may need or want.

#+BEGIN_SRC org
These are all the options that my config file has.  If the box does
not have an X, then we should add this in the service definition.

- [ ] "persist-key"
- [ ] "persist-tun"
- [ ] "remote-random"
- [ ] "pull"
- [X] "comp-lzo no"
- [ ] "tls-client"  does tls-auth provide this option???
- [ ] "verify-x509-name Server name-prefix"
- [ ] "ns-cert-type server"  This is possibly deprecated?
- [ ] "key-direction 1" This is another way of specifying tls-auth?
- [X] "route-method exe" This is only useful on Windows.
- [ ] "route-delay 2"
- [X] "tun-mtu 1500" The documentation says most cases...I should
  leave this to it's default parameter.  So unless needed, we probably
  shouldn't need to add it to guix.
  
- The next two options only make sense when we are using the protocol
  udp.  We should probably specify them someway that you can only use
  them if protocol is upd.  Something like:

   #+BEGIN_SRC scheme
   (proto udp
 (upd-options
   (fragment 1300)
   (mssfix 1200))
   #+END_SRC

- [X] "fragment 1300"
- [X] "mssfix 1200"


- [ ] "cipher AES-256-CBC"
- [X] keysize 256 deprecated.  Do not need. and my key size is the
  cipher size anyway.  The documentation does not reccommend manually changing 
your keysize.
- [X] auth SHA512  I have no idea where this is in the documentation
- [X] sndbuf 524288  The documentation says that the default should work.
- [X] rcvbuf 524288  as above
- [X] auth-user-pass login.conf
#+END_SRC

We should also probably allow a file option.  Some users may have a
working file.  Perhaps we should support this:

#+BEGIN_SRC scheme
(openvpn-client-service
  #:file  "/path/to/openvpn.conf")
#+END_SRC

Joshua

bug#39671: Something appears to disable linux kernel modules from loading.

[Joshua Branson via Bug reports for GNU Guix]

So I just ran guix pull & reconfigure.

joshua@dobby /run/booted-system/kernel/lib/modules$ guix describe
Generation 36   Feb 20 2020 10:11:40(current)
  jmacs 65b1737
repository URL: https://notabug.org/jbranso/guix-packages.git
branch: master
commit: 65b17377136095935ef6da3a836142d56fecce2b
  guix bf8dfe3
repository URL: https://git.savannah.gnu.org/git/guix.git
branch: master
commit: bf8dfe3df025e4ac80cccb87497b4f072ba10e2a


So I feel like Jack beat me to it,
but the contents of /proc/sys/kernel/modprobe are:

#+BEGIN_SRC sh
$ cat /proc/sys/kernel/modprobe
/gnu/store/daq5zs7ni529zh3xxgyhidna52wa17js-modprobe
#+END_SRC


#+BEGIN_SRC sh
cat /gnu/store/daq5zs7ni529zh3xxgyhidna52wa17js-modprobe
#!/gnu/store/1mkkv2caiqbdbbd256c4dirfi4kwsacv-guile-2.2.6/bin/guile 
--no-auto-compile
!#
(begin (setenv "LINUX_MODULE_DIRECTORY" 
"/run/booted-system/kernel/lib/modules") (apply execl 
"/run/current-system/profile/bin/modprobe" (cons 
"/run/current-system/profile/bin/modprobe" (cdr (command-line)~ $
#+END_SRC

Then I was just poking around.

#+BEGIN_SRC sh
~ $ cat /run/booted-system/kernel/lib/modules
Read error: Is a directory, /run/booted-system/kernel/lib/modules
~ $ cd /run/booted-system/kernel/lib/modules
/run/booted-system/kernel/lib/modules $ ls
5.4.21-gnu
/run/booted-system/kernel/lib/modules $ cd 5.4.21-gnu/
/run/booted-system/kernel/lib/modules/5.4.21-gnu $ ls
build   modules.alias  modules.builtin  modules.builtin.modinfo  
modules.dep.bin  modules.ordermodules.symbols  source
kernel  modules.alias.bin  modules.builtin.bin  modules.dep  
modules.devname  modules.softdep  modules.symbols.bin
/run/booted-system/kernel/lib/modules/5.4.21-gnu $ cat modules.order
kernel/arch/x86/events/amd/power.ko
kernel/arch/x86/kernel/msr.ko
kernel/arch/x86/kernel/cpuid.ko
kernel/arch/x86/crypto/glue_helper.ko
kernel/arch/x86/crypto/des3_ede-x86_64.ko
kernel/arch/x86/crypto/camellia-x86_64.ko
kernel/arch/x86/crypto/blowfish-x86_64.ko
kernel/arch/x86/crypto/twofish-x86_64.ko
kernel/arch/x86/crypto/twofish-x86_64-3way.ko
... tons more modules...
kernel/drivers/gpu/drm/i915/i915.ko
kernel/drivers/net/ethernet/intel/e1000e/e1000e.ko
#+END_SRC

You'll notice that my i915 graphics and e1000e (ethernet) driver is
listed in that directory.

On my working system, these were the modules that lspci -v showed I was
using:

#+BEGIN_SRC sh :results output :exports both
lspci -v | grep "Kernel driver in"
#+END_SRC

#+RESULTS:
#+begin_example
Kernel driver in use: i915
Kernel driver in use: e1000e
Kernel driver in use: uhci_hcd
Kernel driver in use: uhci_hcd
Kernel driver in use: uhci_hcd
Kernel driver in use: ehci-pci
Kernel driver in use: snd_hda_intel
Kernel driver in use: pcieport
Kernel driver in use: pcieport
Kernel driver in use: pcieport
Kernel driver in use: pcieport
Kernel driver in use: pcieport
Kernel driver in use: uhci_hcd
Kernel driver in use: uhci_hcd
Kernel driver in use: uhci_hcd
Kernel driver in use: ehci-pci
Kernel driver in use: lpc_ich
Kernel driver in use: ata_piix
Kernel driver in use: i801_smbus
Kernel driver in use: yenta_cardbus
Kernel driver in use: firewire_ohci
#+end_example

On the broken system, I am able to load my i915 and e1000e driver, but I
am not able to load yenta_cardbus.

#+BEGIN_SRC sh
$ sudo modprobe yenta_cardbus
modprobe: FATAL: Module yenta_cardbus not found in directory 
/run/booted-system/kernel/lib/modules/5.4.21-gnu
#+END_SRC

Sorry if I'm being repetitive.  I am just wanting to help.  :)

--
Joshua Branson
Sent from Emacs and Gnus

bug#39671: Something appears to disable linux kernel modules from loading.

[Joshua Branson via Bug reports for GNU Guix]

Hello!

tl;dr

Something is causing linux 5.4.20 not to load kernel modules at boot.
Perhaps the culprit is the shepherd 0.7.0.

So I recently reconfigured guix on my ThinkPad T400.

#+BEGIN_SRC sh
$ guix describe
Generation 32   Feb 18 2020 16:53:46(current)
  jmacs 1a401c8
repository URL: https://notabug.org/jbranso/guix-packages.git
branch: master
commit: 1a401c81ed0617e2ca2fa37ec8caa9ca96032b7a
  guix 97c6670
repository URL: https://git.savannah.gnu.org/git/guix.git
branch: master
commit: 97c6670ef79bbf5e82dece2e837ed73b6462da01
#+END_SRC

After I rebooted sway refused to start.  The sway error message said
#+BEGIN_SRC sh
$ sway

[backend/backend.c:339] Failed to open any DRM device.
[sway/server.c] Unable to create backend.
#+END_SRC

So sway is not starting.  I believe this is because my i915 intel
driver is not loaded.  I know this is the case, because the text on my
virtual console is LARGE.  $ sudo modprobe i915 loads the required
driver. And I can now log into sway.

However, my ethernet driver is not loaded.

#+BEGIN_SRC sh
$ lsmod | grep e1000e

#+END_SRC

#+BEGIN_SRC sh
$ sudo modprobe e1000e
#+END_SRC

Then I ran ifconfig, and indeed I now have an ethernet device.

#+BEGIN_SRC sh :results output :exports both
$ ifconfig
enp0s25   Link encap:Ethernet  HWaddr 00:1C:25:9A:37:BA
  inet addr:172.16.113.199  Bcast:172.16.115.255  Mask:255.255.252.0
  UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
  RX packets:505 errors:0 dropped:0 overruns:0 frame:0
  TX packets:570 errors:0 dropped:0 overruns:0 carrier:0
  collisions:0 txqueuelen:1000
  RX bytes:143838  TX bytes:60886
  Interrupt:20 Memory:fc10-fc12

loLink encap:Local Loopback
  inet addr:127.0.0.1  Bcast:0.0.0.0  Mask:255.0.0.0
  UP LOOPBACK RUNNING  MTU:65536  Metric:1
  RX packets:0 errors:0 dropped:0 overruns:0 frame:0
  TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
  collisions:0 txqueuelen:1000
  RX bytes:0  TX bytes:0

#+END_SRC

And I now have an internet connection.

#+BEGIN_SRC sh :results output :exports both
joshua@dobby ~/prog/org$ ping -c 3 gnu.org
PING gnu.org (209.51.188.148): 56 data bytes
64 bytes from 209.51.188.148: icmp_seq=0 ttl=56 time=35.610 ms
64 bytes from 209.51.188.148: icmp_seq=1 ttl=56 time=35.635 ms
64 bytes from 209.51.188.148: icmp_seq=2 ttl=56 time=35.501 ms
--- gnu.org ping statistics ---
3 packets transmitted, 3 packets received, 0% packet loss
round-trip min/avg/max/stddev = 35.501/35.582/35.635/0.058 ms
#+END_SRC

But I do not have a working touchpad.  I guess my touchpad driver is
not loaded.  I'm not certain what driver my touchpad uses, so for now
I am doing with out.

I then went and asked for some tips on irc.  HappyEnt claimed the
problem for him was commit 205c1e0.

janneke was also having issues with kernel modules not being
automatically booted.  He said that this commit worked for him:
ef2b1d2c8b60776bf66573b0c810474e9e1a4abd. He then said that commit
d39885a8a9e0e03c2bf6277d475d384168bba642 also worked, which implied
the problem was not the linux version 5.4.20, but possibly the
shepherd.

I tried reconfiguring with commit
d39885a8a9e0e03c2bf6277d475d384168bba642, to see if that solved my issue.

#+BEGIN_SRC sh :results output :exports both
 guix time-machine --commit=d39885a8a9e0e03c2bf6277d475d384168bba642 -- system 
reconfigure
#+END_SRC

#+BEGIN_SRC sh
$ uname -r
5.4.20-gnu
#+END_SRC

janneke's commit did solve my issue.  After rebooting, sway starts, I
have internet, and my touchpad and sound work.

Man I love guix system.  It really does work smoothly, even when you
have problems.  So thanks for making a great GNU/Linux distro!


Thanks Joshua

bug#39660: openvpn-client-service does not support auth-user-pass

[Joshua Branson via Bug reports for GNU Guix]

Hello,

I recently bought a vpn service from expressvpn.  They have a closed
source app to connect, but of course we do not want to use that.
Luckily, they allow a manual connection via openvpn.  I downloaded
their script to manually connect.  It looks like they require all
manual connections to authenticate via a username and password.

Their support team told me that the manually connection must
authenticate via a username and password.  They do not support any
other manual connection.  Guix's openvpn-client-service does not
support authenticating via a username and password.

According to this forum thread
(https://forums.openvpn.net/viewtopic.php?t=11342), I was able to
manually connect to expressvpn.  via "sudo expressvpn
my_expressvpn_.ovpn". by changing

"auth-user-pass" to "auth-user-pass login.conf".

login.conf looks like

#+BEGIN_SRC text
username
password
#+END_SRC

The express vpn file that I downloaded looks like this:

#+BEGIN_SRC text
dev tun
fast-io
persist-key
persist-tun
nobind
remote someaddress.expressnetw.com 1195

remote-random
pull
comp-lzo no
tls-client
verify-x509-name Server name-prefix
ns-cert-type server
key-direction 1
route-method exe
route-delay 2
tun-mtu 1500
fragment 1300
mssfix 1200
verb 3
cipher AES-256-CBC
keysize 256
auth SHA512
sndbuf 524288
rcvbuf 524288
auth-user-pass login.conf


-BEGIN CERTIFICATE-
secret info
-END CERTIFICATE-


-BEGIN RSA PRIVATE KEY-
secret info
-END RSA PRIVATE KEY-


#
# 2048 bit OpenVPN static key
#
-BEGIN OpenVPN Static key V1-
secret info
-END OpenVPN Static key V1-


-BEGIN CERTIFICATE-
secret info
-END CERTIFICATE-

#+END_SRC

A solution would be to modify our current openvpn-client-service to
allow authentication via a username and password, or to supply a
configuration file.

Also it looks like expressvpn may one day move to wireguard:

https://www.expressvpn.com/blog/expressvpn-wireguard-update/


I hope this helps!

Thanks,

Joshua

bug#37387: reconfigure does not recreate ~/.guix-profile

[Joshua Branson via Bug reports for GNU Guix]

Hey guix,

;tldr guix system reconfigure does not create a ~/.guix-profile, if
 the file was deleted, nor does it change the symlink if the username
 changed.

This seems like 2 tiny bugs.  I recently installed guix on my Thinkpad
T400.  (Thanks by the way!  Sway works wonderfully!)  When I first
created my user my user line looked like

#+BEGIN_SRC scheme
 (user-account
  (name "Joshua Branson")
  (comment "Joshua Branson")
  (group "users")
  (home-directory "/home/joshua")
  (supplementary-groups
   '("wheel" "netdev" "audio" "video")))
#+END_SRC scheme

Later I changed the user name to '(name "joshua")' and reconfigured.
Guix was smart enough to create a new profile for me, but
.guix-profile still pointed to user account "Joshua Branson" not
"joshua".


$ cd ~/; ls -lha .guix-profile
.guix-profile -> /var/guix/profiles/per-user/Joshua Branson/guix-profile

So I removed .guix-profile and reconfigured.

$ rm ~/.guix-profile

# sudo guix system reconfigure sway.scm

I thought that guix is declarative, so it will recreate .guix-profile,
but it did not.

Thanks,

Joshua

bug#35669: Mesa is failing an assertion

[Joshua Branson]

This did indeed solve my problem.  Thanks!

-- 
Joshua Branson
Sent from Emacs and Gnus

bug#35669: Mesa is failing an assertion

[Joshua Branson]

Hello I am getting a weird mesa assertion when I try to start sway.

sway: ../mesa-18.3.5/src/mesa/program/prog_parameter.c:247:
_mesa_add_parameter: Assertion `0 < size && size <=4' failed.
Aborted.

Is anyone else getting this issue?

Thanks,

--
Joshua Branson
Sent from Emacs and Gnus

bug#34528: Icecat is crashing on search

[Joshua Branson]

Hello!

So I recently ran "guix pull && guix package -u && guix system
reconfigure awesome.scm".

And now Icecat hardly use able.

#+BEGIN_SRC bash
guix --version
#+END_SRC

guix (GNU Guix) af5ead8b346f11105c964726101618116af13426
Copyright (C) 2019 the Guix authors
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.


I am using a Macbook 7,1.

I started Icecat from a terminal.  When Icecat opened, I tried to search
for "hello" in the omnibar.  Icecat immediately crashed.


#+BEGIN_SRC bash
icecat --version
#+END_SRC

GNU IceCat 60.5.1


Here is a copy of what the terminal said:


joshua@dobby ~$ icecat
1550505405166   addons.webextension.{d10d0bf8-f5b5-c8b4-a8b2-2b9879e08c5d}  
WARNLoading extension '{d10d0bf8-f5b5-c8b4-a8b2-2b9879e08c5d}': Reading 
manifest: Error processing background.persistent: Event pages are not currently 
supported. This will run as a persistent background page.
1550505405178   addons.webextension.{d10d0bf8-f5b5-c8b4-a8b2-2b9879e08c5d}  
WARNLoading extension '{d10d0bf8-f5b5-c8b4-a8b2-2b9879e08c5d}': Reading 
manifest: Error processing storage: An unexpected property was found in the 
WebExtension manifest.
1550505406402   addons.webextension.{d10d0bf8-f5b5-c8b4-a8b2-2b9879e08c5d}  
WARNPlease specify whether you want browser_style or not in your 
browser_action options.

(icecat:3394): Gtk-WARNING **: 15:56:46.419: Could not find the icon 
'dialog-warning'. The 'hicolor' theme
was not found either, perhaps you need to install it.
You can get a copy from:
http://icon-theme.freedesktop.org/releases

(icecat:3394): Gtk-WARNING **: 15:56:46.420: Error loading theme icon 
'dialog-warning' for stock: Icon 'dialog-warning' not present in theme Adwaita
JavaScript error: resource://activity-stream/lib/Screenshots.jsm, line 102: 
TypeError: cache is undefined
JavaScript error: resource://activity-stream/lib/Screenshots.jsm, line 102: 
TypeError: cache is undefined
JavaScript warning: 
moz-extension://54be0cf6-40e6-4986-a89b-b0498cedcd5c/lib/adblockplus.js, line 
0: Successfully compiled asm.js code (total compilation time 1ms; not stored in 
cache (too small to benefit))
1550505407804   addons.webextension.tortm-browser-button@jeremybenthum  WARN
Please specify whether you want browser_style or not in your browser_action 
options.
1550505411872   addons.webextension.https-everywh...@eff.orgWARNPlease 
specify whether you want browser_style or not in your browser_action options.

(icecat:3394): Gdk-ERROR **: 15:56:53.656: The program 'icecat' received an X 
Window System error.
This probably reflects a bug in the program.
The error was 'BadMatch (invalid parameter attributes)'.
  (Details: serial 1635 error_code 8 request_code 2 (core protocol) minor_code 
0)
  (Note to programmers: normally, X errors are reported asynchronously;
   that is, you will receive the error a while after causing it.
   To debug your program, run it with the GDK_SYNCHRONIZE environment
   variable to change this behavior. You can then get a meaningful
   backtrace from your debugger if you break on the gdk_x_error() function.)
Crash Annotation GraphicsCriticalError: |[C0][GFX1-]: Receive IPC close with 
reason=AbnormalShutdown (t=2.72252) [GFX1-]: Receive IPC close with 
reason=AbnormalShutdown
[Child 3489, Chrome_ChildThread] WARNING: pipe error (3): Connection reset by 
peer: file 
/tmp/guix-build-icecat-60.5.1-guix1.drv-0/icecat-60.5.1-guix1/ipc/chromium/src/chrome/common/ipc_channel_posix.cc,
 line 342
Crash Annotation GraphicsCriticalError: |[C0][GFX1-]: Receive IPC close with 
reason=AbnormalShutdown (t=2.04331) [GFX1-]: Receive IPC close with 
reason=AbnormalShutdown
[Child 3514, Chrome_ChildThread] WARNING: pipe error (3): Connection reset by 
peer: file 
/tmp/guix-build-icecat-60.5.1-guix1.drv-0/icecat-60.5.1-guix1/ipc/chromium/src/chrome/common/ipc_channel_posix.cc,
 line 342
Trace/breakpoint trap



Thanks!

P.S.  It is nice that I am just able to --roll-back and have a working
IceCat again!

--
Joshua Branson
Sent from Emacs and Gnus

bug#34085: autoscan reports a warning

[Joshua Branson]

Danny Milosavljevic  writes:

> Hi,
>
> On Tue, 15 Jan 2019 10:43:49 -0500
> Joshua Branson  wrote:
>
>> I'm not certain if this is the right list to report this to, but I just
>> installed autoscan version 2.21, and it gave me this warning:
>> 
>> #BEGIN_SRC sh
>>   autoscan
>> #END_SRC
>> 
>> Unescaped left brace in regex is deprecated here (and will be fatal
>> in Perl 5.30), passed through in regex; marked by <-- HERE in m/\${
>> <-- HERE [^\}]*}/ at /home/joshua/.guix-profile/bin/autoscan line
>> 361.
>> 
>> 
>> Should I report this upstream instead?
>
> I think so, yes.
>
> autoscan is part of autoconf 2.21, so the bug report should go to the 
> autoconf package.
>
> The regexp in question is
>
>   s/\${[^\}]*}//g;
>
> Perl is complaining because perl regexp use curly braces to specify a range 
> of valid repeats.
> Maybe the easiest way to understand it is that the following equivalences 
> hold in regexps:
>
> ? is equivalent to {0,1}
> + is equivalent to {1,}
> * is equivalent to {0,}
>
> The above (at the end of the regexp "\${[^\}]*}") probably means a literal 
> curly
> brace--but they don't escape it - hence the warning.
>
> It's only a warning because no valid repeat range can start with a closing 
> curly
> brace.
> So perl can still figure out what you meant.
>
> But it's obviously not recommended to use unescaped closing curly braces to
> match a literal closing curly brace regardless.
>


Ok, I'll report this upstream.  Thanks for flushing out the main issue!

-- 
Joshua Branson
Sent from Emacs and Gnus

bug#34085: autoscan reports a warning

[Joshua Branson]

Hello,

I'm not certain if this is the right list to report this to, but I just
installed autoscan version 2.21, and it gave me this warning:

#BEGIN_SRC sh
  autoscan
#END_SRC

Unescaped left brace in regex is deprecated here (and will be fatal in Perl 
5.30), passed through in regex; marked by <-- HERE in m/\${ <-- HERE [^\}]*}/ 
at /home/joshua/.guix-profile/bin/autoscan line 361.


Should I report this upstream instead?

Thanks

--
Joshua Branson
Sent from Emacs and Gnus

bug#33953: reconfigure not working tl; dr : EFI not mounted to /boot/efi

[Joshua Branson]

Timothy Sample  writes:

> Hi Joshua,
>
> Joshua Branson  writes:
>
>
> I agree with you that the manual could be more clear.  In the
> installation section, it mentions needing an EFI partition that is
> mounted, but it never spells out that this needs to be included in the
> operating system configuration.  I am not sure how exactly to fix it
> though.  If you were willing propose something, that would be very
> helpful!

Perhaps for now, I'll just throw in this patch that modifies an
guix/system/examples desktop file.  The "full blown" desktop has a UEFI
boot, but it does not show the (file-system (type "vfat") ...) example.
This patch should fix that.

The "light weight window manager" in the manual does have a
(file-system (type "vfat") ...).

>From 0d35f5c6a73dc97959779f727c25e81de9192680 Mon Sep 17 00:00:00 2001
From: Joshua Branson 
Date: Thu, 3 Jan 2019 05:47:23 -0500
Subject: [PATCH] I modified the UEFI desktop example to include the
 (file-system (type "vfat") ...)

---
 gnu/system/examples/desktop.tmpl | 4 
 1 file changed, 4 insertions(+)

diff --git a/gnu/system/examples/desktop.tmpl b/gnu/system/examples/desktop.tmpl
index 1b8d46afa..9c36a2692 100644
--- a/gnu/system/examples/desktop.tmpl
+++ b/gnu/system/examples/desktop.tmpl
@@ -30,6 +30,10 @@
 (mount-point "/")
 (type "ext4")
 (dependencies mapped-devices))
+(file-system
+ (device (uuid "1234-ABCD" 'fat))
+ (mount-point "/boot/efi")
+         (type "vfat"))
   %base-file-systems))
 
   (users (cons (user-account
-- 
2.20.1



--
Joshua Branson
Sent from Emacs and Gnus

bug#33953: reconfigure not working tl; dr : EFI not mounted to /boot/efi

[Joshua Branson]

 (home-directory "/home/joshua"))
  %base-user-accounts))

 ;; Globally-installed packages.
 (packages (cons* awesome nss-certs %base-packages))

 ;; add my configured desktop-services
 (services (cons* (console-keymap-service "dvorak")
  ;; make linux use RAM more than it uses swap.
  (service sysctl-service-type
   (sysctl-configuration
(settings  '(("vm.swappiness" . "30")
  %my-desktop-services))

 (name-service-switch %mdns-host-lookup-nss))

#+END_SRC

Did I just make a silly mistake?

--
Joshua Branson
Sent from Emacs and Gnus

bug#33661: A recent Guix pull failed

[Joshua Branson]

cat .config/guix/channels.scm

;; Add my personal packages to those Guix provides.
(cons (channel
   (name 'my-personal-packages)
   (url "https://notabug.org/jbranso/guix-packages.git";))
  %default-channels)

My channel is probably not correct.  I'm not certain if I am specifying
packages correctly.

Thanks,

Joshua

bug#33661: A recent Guix pull failed

[Joshua Branson]

Hello,

I'm tried looking to see if someone else was experiencing this bug, but
I couldn't find a easy way to search the guix bug database, so I'm sorry
if I am making a duplicate bug report.

Anyway, I'm using a Macbook 7,1.  guix version reports this:

guix (GNU Guix) 17cfb7aeffaaba70e67e9afb50d7100614ffca7f
Copyright (C) 2018 the Guix authors
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.


And guix pull shows this:

Updating channel 'my-personal-packages' from Git repository at 
'https://notabug.org/jbranso/guix-packages.git'...
Updating channel 'guix' from Git repository at 
'https://git.savannah.gnu.org/git/guix.git'...
Building from these channels:
  my-personal-packageshttps://notabug.org/jbranso/guix-packages.git a6784b7
  guix  https://git.savannah.gnu.org/git/guix.git   6ddc63e
;;; compiling 
/gnu/store/nnawlikz0n644rh05p9fyggq30qk5lis-my-personal-packages/share/guile/site/2.2/myemacs.scm
;;; compiled 
/home/joshua/.cache/guile/ccache/2.2-LE-8-3.A/gnu/store/xgd83571ijj6karrs8sykk0f5i4kqa39-guix-packages-862909a/myemacs.scm.go
guix pull: warning: failed to load '(myemacs)':
no code for module (myemacs)
Computing Guix derivation for 'x86_64-linux'... -@ build-started 
/gnu/store/4s6w1cz1srv9vh1bj5wim71sr4v8y22a-guix-0.16.0-2.5227d93-checkout.drv 
- x86_64-linux 
/var/log/guix/drvs/4s//6w1cz1srv9vh1bj5wim71sr4v8y22a-guix-0.16.0-2.5227d93-checkout.drv.bz2
environment variable `PATH' set to 
`/gnu/store/q09sy224qnxrp982z4xfaxi19721mjx8-gzip-1.9/bin:/gnu/store/ipx79bfj2mrc8npj7s3qi3zri11jfhaw-tar-1.30/bin'
Initialized empty Git repository in 
/gnu/store/yj0ly310dvzc4bxbvpa9d44wx93r7jql-guix-0.16.0-2.5227d93-checkout/.git/
\error: Server does not allow request for unadvertised object 
5227d938e2b7bda22e2a7aa733e1e09a6c726f18
Failed to do a shallow fetch; retrying a full fetch...
\From https://git.savannah.gnu.org/r/guix
 * [new branch]  core-updates-next   -> origin/core-updates-next
 * [new branch]  guile-daemon-> origin/guile-daemon
 * [new branch]  imagemagick-updates -> origin/imagemagick-updates
 * [new branch]  master  -> origin/master
 * [new branch]  nix -> origin/nix
 * [new branch]  python-updates  -> origin/python-updates
 * [new branch]  qt-updates  -> origin/qt-updates
 * [new branch]  reproduce-bug-29774 -> origin/reproduce-bug-29774
 * [new branch]  rhel6   -> origin/rhel6
 * [new branch]  staging -> origin/staging
 * [new branch]  version-0.10.0  -> origin/version-0.10.0
 * [new branch]  version-0.11.0  -> origin/version-0.11.0
 * [new branch]  version-0.12.0  -> origin/version-0.12.0
 * [new branch]  version-0.13.0  -> origin/version-0.13.0
 * [new branch]  version-0.14.0  -> origin/version-0.14.0
 * [new branch]  version-0.15.0  -> origin/version-0.15.0
 * [new branch]  version-0.16.0  -> origin/version-0.16.0
 * [new branch]  version-0.8.3   -> origin/version-0.8.3
 * [new branch]  version-0.9.0   -> origin/version-0.9.0
 * [new branch]  wip-bootstrap   -> origin/wip-bootstrap
 * [new branch]  wip-build-systems-gexp  -> origin/wip-build-systems-gexp
 * [new branch]  wip-check   -> origin/wip-check
 * [new branch]  wip-container   -> origin/wip-container
 * [new branch]  wip-deploy  -> origin/wip-deploy
 * [new branch]  wip-gcc7-> origin/wip-gcc7
 * [new branch]  wip-gexp-grafts -> origin/wip-gexp-grafts
 * [new branch]  wip-gexp-hygiene-> origin/wip-gexp-hygiene
 * [new branch]  wip-git-https   -> origin/wip-git-https
 * [new branch]  wip-gnome-upgrades  -> origin/wip-gnome-upgrades
 * [new branch]  wip-grafts  -> origin/wip-grafts
 * [new branch]  wip-haskell -> origin/wip-haskell
 * [new branch]  wip-hurd-> origin/wip-hurd
 * [new branch]  wip-installer   -> origin/wip-installer
 * [new branch]  wip-installer-2 -> origin/wip-installer-2
 * [new branch]  wip-ipfs-> origin/wip-ipfs
 * [new branch]  wip-ipfs2   -> origin/wip-ipfs2
 * [new branch]  wip-kde-frameworks-update -> 
origin/wip-kde-frameworks-update
 * [new branch]  wip-loongson2f  -> origin/wip-loongson2f
 * [new branch]  wip-mediagoblin -> origin/wip-mediagoblin
 * [new branch]  wip-newt-installer  -> origin/wip-newt-installer
 * [new branch]  wip-next-browser-> origin/wip-next-browser
 * [new branch]  wip-next-browser2   -> origin/wip-next-browser2
 * [new branch]  wip-next-browser3   -> origin/wip-next-browser3
 

bug#33330: Hurd failing to build

[Joshua Branson]

Manolis Ragkousis  writes:

> Hello Brett,
>
> I imagine you run `guix build hurd`?

I didn't know there was always a build log...cool.  That might help me
spot some of the compiler errors.

>
> Can you share the build log?
>
> Thank you,
> Manolis
> On 11/10/18 1:47 AM, Brett Gilio wrote:
>> 
>> Hi all,
>> 
>> I know that the hurd is not supported on Guix at the moment. I was
>> trying to give it a try in spite of that, and it is failing to build.
>> 
>> I am sure that this is a known issue, but I could not find any
>> referencing issues of recent on debbugs.
>> 
>> building /gnu/store/83vrxqm3xcwj9sn0kkbgaar4g7ac21ck-hurd-0.9.drv...
>> builder for `/gnu/store/83vrxqm3xcwj9sn0kkbgaar4g7ac21ck-hurd-0.9.drv' 
>> failed with exit code 1
>> build of /gnu/store/83vrxqm3xcwj9sn0kkbgaar4g7ac21ck-hurd-0.9.drv failed
>> View build log at 
>> '/var/log/guix/drvs/83/vrxqm3xcwj9sn0kkbgaar4g7ac21ck-hurd-0.9.drv.bz2'.
>> guix system: error: build failed: build of 
>> `/gnu/store/83vrxqm3xcwj9sn0kkbgaar4g7ac21ck-hurd-0.9.drv' failed
>> 
>> 
>>   guix 03a4153
>> repository URL: https://git.savannah.gnu.org/git/guix.git
>> branch: master
>> commit: 03a415365a1cfcc263f56d309f33a1a581790ca7
>> 
>> Best,
>> Brett Gilio
>> 
>> 
>> 

bug#33082: guix pull resulted in an error: compute-guix-derivation

[Joshua Branson]

Gábor Boskovits  writes:

> Hello Joshua,
>
> Joshua Branson  ezt írta (időpont: 2018. okt.
> 30., K, 16:10):
>>
>> Gábor Boskovits  writes:
>>
>> > Hello Joshua,
>> >
>> > Joshua Branson  ezt írta (időpont: 2018. okt.
>> > 30., K, 13:44):
>> >>
>> >> Gábor Boskovits  writes:
>> >>
>> >> > Joshua Branson  ezt írta (időpont: 2018. okt. 
>> >> > 29., H 15:54):
>> >> >
>> >> >  l...@gnu.org (Ludovic Courtès) writes:
>> >> >
>> >> >  > Hello,
>> >> >  >
>> >> >
>> >> >  I was able to update successfully.  This bug seems like a duplicate of
>> >> >  python 2 not deterministic.  Someone ought to close this bug report.
>> >> >
>> >> > I believe this is not the case, usually non deterministic means the 
>> >> > build is not reproducible, while this is a
>> >> > non-deterministic test failure. I would suggest
>> >> > keeping this bug open, if I am right, maybe renaming to 
>> >> > non-deterministic test failure in python2. What do you think?
>> >>
>> >> Fair enough.  Since I made the bug report, then I should try to build it
>> >> again and see what happens.
>> >>
>> >
>> > Thanks for having a look, please make sure to use guix build -K, so
>> > that the failed build results are retained.
>> > If you can't trigger the failure, then I will try to do this later.
>>
>> I was able to build this successfully:
>>
>> guix build -K /gnu/store/qpvqn6ff2lmfq74ff3i9pz5hrb01p9hw-python2-2.7.14.drv
>>
>>
>> Collecting setuptools
>> Collecting pip
>> Installing collected packages: setuptools, pip
>> Successfully installed pip-9.0.1 setuptools-28.8.0
>> phase `install' succeeded after 32.6 seconds
>> starting phase `move-tk-inter'
>> phase `move-tk-inter' succeeded after 0.2 seconds
>> starting phase `remove-tests'
>> phase `remove-tests' succeeded after 0.8 seconds
>> starting phase `patch-shebangs'
>> phase `patch-shebangs' succeeded after 0.0 seconds
>> starting phase `make-libraries-writable'
>> phase `make-libraries-writable' succeeded after 0.1 seconds
>> starting phase `strip'
>> stripping binaries in 
>> "/gnu/store/l7164sj4k77c4bwy9mrqq9d96bxiz4kw-python2-2.7.14/lib" with 
>> "strip" and flags ("--strip-debug"
>> "--enable-deterministic-archives")
>> stripping binaries in 
>> "/gnu/store/l7164sj4k77c4bwy9mrqq9d96bxiz4kw-python2-2.7.14/bin" with 
>> "strip" and flags ("--strip-debug"
>> "--enable-deterministic-archives")
>> stripping binaries in 
>> "/gnu/store/z0r8jiimjgdg2sl3h9ad9z1v1i95752v-python2-2.7.14-tk/lib" with 
>> "strip" and flags
>> ("--strip-debug" "--enable-deterministic-archives")
>> phase `strip' succeeded after 2.9 seconds
>> starting phase `validate-runpath'
>> validating RUNPATH of 64 binaries in 
>> "/gnu/store/l7164sj4k77c4bwy9mrqq9d96bxiz4kw-python2-2.7.14/lib"...
>> validating RUNPATH of 1 binaries in 
>> "/gnu/store/l7164sj4k77c4bwy9mrqq9d96bxiz4kw-python2-2.7.14/bin"...
>> validating RUNPATH of 1 binaries in 
>> "/gnu/store/z0r8jiimjgdg2sl3h9ad9z1v1i95752v-python2-2.7.14-tk/lib"...
>> phase `validate-runpath' succeeded after 1.1 seconds
>> starting phase `validate-documentation-location'
>> phase `validate-documentation-location' succeeded after 0.0 seconds
>> starting phase `delete-info-dir-file'
>> phase `delete-info-dir-file' succeeded after 0.0 seconds
>> starting phase `patch-dot-desktop-files'
>> phase `patch-dot-desktop-files' succeeded after 0.0 seconds
>> starting phase `install-license-files'
>> installing 1 license files
>> phase `install-license-files' succeeded after 0.0 seconds
>> starting phase `reset-gzip-timestamps'
>> phase `reset-gzip-timestamps' succeeded after 0.1 seconds
>> starting phase `compress-documentation'
>> compressing documentation in 
>> '/gnu/store/l7164sj4k77c4bwy9mrqq9d96bxiz4kw-python2-2.7.14/share/man' with 
>> "gzip" and flags
>> ("--best" "--no-name")
>> phase `compress-documentation' succeeded after 0.1 seconds
>> successfully built 
>> /gnu/store/qpvqn6ff2lmfq74ff3i9pz5hrb01p9hw-python2-2.7.14.drv
>> /gnu/store/l7164sj4k77c4bwy9mrqq9d96bxiz4kw-python2-2.7.14
>> /gnu/store/z0r8jiimjgdg2sl3h9ad9z1v1i95752v-python2-2.7.14-tk
>>
>>
>> I suppose now we can close this bug report, since I can't reproduce the
>> error?
>>
>
> Please leave this open, until I can have a closer look. I will take
> ownership of this bug.
>

Sounds like a plan.  I wouldn't know how to close it anyway.

>> Thanks
>>
>> >
>> > Best regards,
>> > g_bor
>>
>>
>>
>
> Best regards,
> g_bor

bug#33082: guix pull resulted in an error: compute-guix-derivation

[Joshua Branson]

Gábor Boskovits  writes:

> Hello Joshua,
>
> Joshua Branson  ezt írta (időpont: 2018. okt.
> 30., K, 13:44):
>>
>> Gábor Boskovits  writes:
>>
>> > Joshua Branson  ezt írta (időpont: 2018. okt. 29., H 
>> > 15:54):
>> >
>> >  l...@gnu.org (Ludovic Courtès) writes:
>> >
>> >  > Hello,
>> >  >
>> >
>> >  I was able to update successfully.  This bug seems like a duplicate of
>> >  python 2 not deterministic.  Someone ought to close this bug report.
>> >
>> > I believe this is not the case, usually non deterministic means the build 
>> > is not reproducible, while this is a
>> > non-deterministic test failure. I would suggest
>> > keeping this bug open, if I am right, maybe renaming to non-deterministic 
>> > test failure in python2. What do you think?
>>
>> Fair enough.  Since I made the bug report, then I should try to build it
>> again and see what happens.
>>
>
> Thanks for having a look, please make sure to use guix build -K, so
> that the failed build results are retained.
> If you can't trigger the failure, then I will try to do this later.

I was able to build this successfully:

guix build -K /gnu/store/qpvqn6ff2lmfq74ff3i9pz5hrb01p9hw-python2-2.7.14.drv


Collecting setuptools
Collecting pip
Installing collected packages: setuptools, pip
Successfully installed pip-9.0.1 setuptools-28.8.0
phase `install' succeeded after 32.6 seconds
starting phase `move-tk-inter'
phase `move-tk-inter' succeeded after 0.2 seconds
starting phase `remove-tests'
phase `remove-tests' succeeded after 0.8 seconds
starting phase `patch-shebangs'
phase `patch-shebangs' succeeded after 0.0 seconds
starting phase `make-libraries-writable'
phase `make-libraries-writable' succeeded after 0.1 seconds
starting phase `strip'
stripping binaries in 
"/gnu/store/l7164sj4k77c4bwy9mrqq9d96bxiz4kw-python2-2.7.14/lib" with "strip" 
and flags ("--strip-debug" "--enable-deterministic-archives")
stripping binaries in 
"/gnu/store/l7164sj4k77c4bwy9mrqq9d96bxiz4kw-python2-2.7.14/bin" with "strip" 
and flags ("--strip-debug" "--enable-deterministic-archives")
stripping binaries in 
"/gnu/store/z0r8jiimjgdg2sl3h9ad9z1v1i95752v-python2-2.7.14-tk/lib" with 
"strip" and flags ("--strip-debug" "--enable-deterministic-archives")
phase `strip' succeeded after 2.9 seconds
starting phase `validate-runpath'
validating RUNPATH of 64 binaries in 
"/gnu/store/l7164sj4k77c4bwy9mrqq9d96bxiz4kw-python2-2.7.14/lib"...
validating RUNPATH of 1 binaries in 
"/gnu/store/l7164sj4k77c4bwy9mrqq9d96bxiz4kw-python2-2.7.14/bin"...
validating RUNPATH of 1 binaries in 
"/gnu/store/z0r8jiimjgdg2sl3h9ad9z1v1i95752v-python2-2.7.14-tk/lib"...
phase `validate-runpath' succeeded after 1.1 seconds
starting phase `validate-documentation-location'
phase `validate-documentation-location' succeeded after 0.0 seconds
starting phase `delete-info-dir-file'
phase `delete-info-dir-file' succeeded after 0.0 seconds
starting phase `patch-dot-desktop-files'
phase `patch-dot-desktop-files' succeeded after 0.0 seconds
starting phase `install-license-files'
installing 1 license files
phase `install-license-files' succeeded after 0.0 seconds
starting phase `reset-gzip-timestamps'
phase `reset-gzip-timestamps' succeeded after 0.1 seconds
starting phase `compress-documentation'
compressing documentation in 
'/gnu/store/l7164sj4k77c4bwy9mrqq9d96bxiz4kw-python2-2.7.14/share/man' with 
"gzip" and flags ("--best" "--no-name")
phase `compress-documentation' succeeded after 0.1 seconds
successfully built 
/gnu/store/qpvqn6ff2lmfq74ff3i9pz5hrb01p9hw-python2-2.7.14.drv
/gnu/store/l7164sj4k77c4bwy9mrqq9d96bxiz4kw-python2-2.7.14
/gnu/store/z0r8jiimjgdg2sl3h9ad9z1v1i95752v-python2-2.7.14-tk


I suppose now we can close this bug report, since I can't reproduce the
error?

Thanks

>
> Best regards,
> g_bor

bug#33082: guix pull resulted in an error: compute-guix-derivation

[Joshua Branson]

Gábor Boskovits  writes:

> Joshua Branson  ezt írta (időpont: 2018. okt. 29., H 
> 15:54):
>
>  l...@gnu.org (Ludovic Courtès) writes:
>
>  > Hello,
>  >
>
>  I was able to update successfully.  This bug seems like a duplicate of
>  python 2 not deterministic.  Someone ought to close this bug report.
>
> I believe this is not the case, usually non deterministic means the build is 
> not reproducible, while this is a non-deterministic test failure. I would 
> suggest
> keeping this bug open, if I am right, maybe renaming to non-deterministic 
> test failure in python2. What do you think?

Fair enough.  Since I made the bug report, then I should try to build it
again and see what happens.

>
>  > Joshua Branson  skribis:
>  >
>  >> Joshua Branson  writes:
>  >>
>  >>> Well,  I thought I'd try to enable substitutes...
>  >>>
>  >>> [root@dobby guix]# pwd
>  >>> /var/guix/profiles/per-user/root/guix-profile/share/guix
>  >>>
>  >>> guix archive --authorize berlin.guixsd.org.pub 
>  >>>
>  >>> This commands has been hanging (doing nothing, as far I can tell) for 5+ 
> minutes.  That sounds non-normal.
>  >>
>  >> Ahh I forgot the "<".
>  >>
>  >>  guix archive --authorize < berlin.guixsd.org.pub 
>  >
>  > Note that this authorizes the use of substitutes coming from
>  > berlin.guixsd.org, but you also need to tell guix-daemon or your guix
>  > command to actually fetch substitutes from https://berlin.guixsd.org.
>  > You can do that with the --substitute-urls option:
>  >
>  >   https://www.gnu.org/software/guix/manual/en/html_node/Substitutes.html
>  >
>  > Let us know how it goes!
>  >
>  > Ludo’.

bug#33082: guix pull resulted in an error: compute-guix-derivation

[Joshua Branson]

l...@gnu.org (Ludovic Courtès) writes:

> Hello,
>

I was able to update successfully.  This bug seems like a duplicate of
python 2 not deterministic.  Someone ought to close this bug report.

> Joshua Branson  skribis:
>
>> Joshua Branson  writes:
>>
>>> Well,  I thought I'd try to enable substitutes...
>>>
>>> [root@dobby guix]# pwd
>>> /var/guix/profiles/per-user/root/guix-profile/share/guix
>>>
>>> guix archive --authorize berlin.guixsd.org.pub 
>>>
>>> This commands has been hanging (doing nothing, as far I can tell) for 5+ 
>>> minutes.  That sounds non-normal.
>>
>> Ahh I forgot the "<".
>>
>>  guix archive --authorize < berlin.guixsd.org.pub 
>
> Note that this authorizes the use of substitutes coming from
> berlin.guixsd.org, but you also need to tell guix-daemon or your guix
> command to actually fetch substitutes from https://berlin.guixsd.org.
> You can do that with the --substitute-urls option:
>
>   https://www.gnu.org/software/guix/manual/en/html_node/Substitutes.html
>
> Let us know how it goes!
>
> Ludo’.

bug#33082: guix pull resulted in an error: compute-guix-derivation

[Joshua Branson]

Joshua Branson  writes:

> Well,  I thought I'd try to enable substitutes...
>
> [root@dobby guix]# pwd
> /var/guix/profiles/per-user/root/guix-profile/share/guix
>
> guix archive --authorize berlin.guixsd.org.pub 
>
> This commands has been hanging (doing nothing, as far I can tell) for 5+ 
> minutes.  That sounds non-normal.

Ahh I forgot the "<".

 guix archive --authorize < berlin.guixsd.org.pub 


So now I am definitely using substitutes.  I only have a few minutes
before I need to go to work, so I don't think "guix pull" will have
enough time to finish.  I'll have to try again tomorrow.



>
> On Fri, Oct 19, 2018, at 2:11 AM, Ludovic Courtès wrote:
>> Hello,
>> 
>> Gábor Boskovits  skribis:
>> 
>> > Joshua Branson  ezt írta (időpont: 2018. okt.
>> > 18., Cs, 16:51):
>> 
>> [...]
>> 
>> >> Total duration: 8 min 47 sec
>> >> Tests result: FAILURE
>> >> make: *** [Makefile:869: test] Error 2
>> >>
>> >> Test suite failed, dumping logs.
>> >> Backtrace:
>> >> \   4 (primitive-load "/gnu/store/nh1m265kg7ddar7jgwd7dh8f8y7���")
>> >> In ice-9/eval.scm:
>> >>191:35  3 (_ _)
>> >> In srfi/srfi-1.scm:
>> >> 640:9  2 (for-each # 
>> >> ���)
>> >> In 
>> >> /gnu/store/f95ghy8mx00fc22nrvswvnpqlfdkf2nk-module-import/guix/build/gnu-build-system.scm:
>> >>799:31  1 (_ _)
>> >> 369:6  0 (check #:target _ #:make-flags _ #:tests? _ # _ # _ # _)
>> >>
>> >> /gnu/store/f95ghy8mx00fc22nrvswvnpqlfdkf2nk-module-import/guix/build/gnu-build-system.scm:369:6:
>> >>  In procedure check:
>> >> Throw to key `srfi-34' with args `(#> >> "make" arguments: ("test" "-j" "2") exit-status: 2 term-signal: #f 
>> >> stop-signal: #f] b8a840>)'.
>> >> builder for 
>> >> `/gnu/store/qpvqn6ff2lmfq74ff3i9pz5hrb01p9hw-python2-2.7.14.drv' failed 
>> >> with exit code 1
>> >> @ build-failed 
>> >> /gnu/store/qpvqn6ff2lmfq74ff3i9pz5hrb01p9hw-python2-2.7.14.drv - 1 
>> >> builder for 
>> >> `/gnu/store/qpvqn6ff2lmfq74ff3i9pz5hrb01p9hw-python2-2.7.14.drv' failed 
>> >> with exit code 1
>> >
>> > It was trying to build python2, and tests failed.
>> > Could you retry this to see if it is a persistent failure, or the
>> > tests are failing indeterministically?
>> 
>> Specifically, could you try running:
>> 
>>   guix build /gnu/store/qpvqn6ff2lmfq74ff3i9pz5hrb01p9hw-python2-2.7.14.drv
>> 
>> ?
>> 
>> If you enabled substitutes (pre-built binaries) you should now be
>> getting substitutes for this.
>> 
>> If that is the case, you can go ahead and rerun ‘guix pull’.
>> 
>> (This doesn’t tell us why you were getting test failures in the first
>> place, but that’s a separate issue.)
>> 
>> HTH,
>> Ludo’.
>> 
>> 
>> 

bug#33082: guix pull resulted in an error: compute-guix-derivation

[Joshua Branson]

Well,  I thought I'd try to enable substitutes...

[root@dobby guix]# pwd
/var/guix/profiles/per-user/root/guix-profile/share/guix

guix archive --authorize berlin.guixsd.org.pub 

This commands has been hanging (doing nothing, as far I can tell) for 5+ 
minutes.  That sounds non-normal.

On Fri, Oct 19, 2018, at 2:11 AM, Ludovic Courtès wrote:
> Hello,
> 
> Gábor Boskovits  skribis:
> 
> > Joshua Branson  ezt írta (időpont: 2018. okt.
> > 18., Cs, 16:51):
> 
> [...]
> 
> >> Total duration: 8 min 47 sec
> >> Tests result: FAILURE
> >> make: *** [Makefile:869: test] Error 2
> >>
> >> Test suite failed, dumping logs.
> >> Backtrace:
> >> \   4 (primitive-load "/gnu/store/nh1m265kg7ddar7jgwd7dh8f8y7���")
> >> In ice-9/eval.scm:
> >>191:35  3 (_ _)
> >> In srfi/srfi-1.scm:
> >> 640:9  2 (for-each # 
> >> ���)
> >> In 
> >> /gnu/store/f95ghy8mx00fc22nrvswvnpqlfdkf2nk-module-import/guix/build/gnu-build-system.scm:
> >>799:31  1 (_ _)
> >> 369:6  0 (check #:target _ #:make-flags _ #:tests? _ # _ # _ # _)
> >>
> >> /gnu/store/f95ghy8mx00fc22nrvswvnpqlfdkf2nk-module-import/guix/build/gnu-build-system.scm:369:6:
> >>  In procedure check:
> >> Throw to key `srfi-34' with args `(# >> "make" arguments: ("test" "-j" "2") exit-status: 2 term-signal: #f 
> >> stop-signal: #f] b8a840>)'.
> >> builder for 
> >> `/gnu/store/qpvqn6ff2lmfq74ff3i9pz5hrb01p9hw-python2-2.7.14.drv' failed 
> >> with exit code 1
> >> @ build-failed 
> >> /gnu/store/qpvqn6ff2lmfq74ff3i9pz5hrb01p9hw-python2-2.7.14.drv - 1 builder 
> >> for `/gnu/store/qpvqn6ff2lmfq74ff3i9pz5hrb01p9hw-python2-2.7.14.drv' 
> >> failed with exit code 1
> >
> > It was trying to build python2, and tests failed.
> > Could you retry this to see if it is a persistent failure, or the
> > tests are failing indeterministically?
> 
> Specifically, could you try running:
> 
>   guix build /gnu/store/qpvqn6ff2lmfq74ff3i9pz5hrb01p9hw-python2-2.7.14.drv
> 
> ?
> 
> If you enabled substitutes (pre-built binaries) you should now be
> getting substitutes for this.
> 
> If that is the case, you can go ahead and rerun ‘guix pull’.
> 
> (This doesn’t tell us why you were getting test failures in the first
> place, but that’s a separate issue.)
> 
> HTH,
> Ludo’.
> 
> 
> 

bug#33082: guix pull resulted in an error: compute-guix-derivation

[Joshua Branson]

Here is a copy of the failed guix pull command.  It's just the tail end
of the error message.  Some details about my machine.  I'm running
Parabola GNU/Linux.  I installed guix via the install guix script.  I
have a Macbook 7,1 (2010).  I did notice many warning messages that
said, "Cannot find python3".

However,

$ pacman -Q python3
python 3.7.0-4

$ which python3
/usr/bin/python3


Anyway, here's the error messages.  It seemed like guix was trying to
build python3, and failed.


Total duration: 8 min 47 sec
Tests result: FAILURE
make: *** [Makefile:869: test] Error 2

Test suite failed, dumping logs.
Backtrace:
\   4 (primitive-load "/gnu/store/nh1m265kg7ddar7jgwd7dh8f8y7���")
In ice-9/eval.scm:
   191:35  3 (_ _)
In srfi/srfi-1.scm:
640:9  2 (for-each # ���)
In 
/gnu/store/f95ghy8mx00fc22nrvswvnpqlfdkf2nk-module-import/guix/build/gnu-build-system.scm:
   799:31  1 (_ _)
369:6  0 (check #:target _ #:make-flags _ #:tests? _ # _ # _ # _)

/gnu/store/f95ghy8mx00fc22nrvswvnpqlfdkf2nk-module-import/guix/build/gnu-build-system.scm:369:6:
 In procedure check:
Throw to key `srfi-34' with args `(#)'.
builder for `/gnu/store/qpvqn6ff2lmfq74ff3i9pz5hrb01p9hw-python2-2.7.14.drv' 
failed with exit code 1
@ build-failed /gnu/store/qpvqn6ff2lmfq74ff3i9pz5hrb01p9hw-python2-2.7.14.drv - 
1 builder for `/gnu/store/qpvqn6ff2lmfq74ff3i9pz5hrb01p9hw-python2-2.7.14.drv' 
failed with exit code 1
Backtrace:
  18 (primitive-load "/gnu/store/5ns8ygdfzr0rzsiy92qw3im2lga���")
In ice-9/eval.scm:
155:9 17 (_ _)
159:9 16 (_ #(#(#(#(#(#(#(#(#(#(#(���) ���) ���) ���) ���) ���) ���) ���) 
���) ���) ���))
In guix/store.scm:
  1605:24 15 (run-with-store _ _ #:guile-for-build _ #:system _ # _)
In guix/gexp.scm:
684:2 14 (_ _)
In guix/monads.scm:
485:9 13 (_ _)
In guix/gexp.scm:
   550:22 12 (_ _)
684:2 11 (_ _)
In guix/monads.scm:
485:9 10 (_ _)
In guix/gexp.scm:
   550:22  9 (_ _)
684:2  8 (_ _)
In guix/monads.scm:
485:9  7 (_ _)
In guix/gexp.scm:
   550:22  6 (_ _)
In guix/store.scm:
  1501:38  5 (_ #)
In guix/packages.scm:
   881:14  4 (cache! # # ���)
In unknown file:
   3 (_ # # #)
In guix/packages.scm:
  1205:22  2 (thunk)
  1138:25  1 (bag->derivation # #<���> ���)
In srfi/srfi-1.scm:
   592:17  0 (map1 (("source" # url: "���>) ���))

srfi/srfi-1.scm:592:17: In procedure map1:
Throw to key `srfi-34' with args `(#)'.
guix pull: error: You found a bug: the program 
'/gnu/store/5ns8ygdfzr0rzsiy92qw3im2lgakq802-compute-guix-derivation'
failed to compute the derivation for Guix (version: 
"39d7fdce453b0ca23ecbed72048647debbaa58a6"; system: "x86_64-linux";
host version: "82402f76bebfa3bb563a58227eb4081f9bdb6142"; pull-version: 1).
Please report it by email to .

bug#32575: [Cuirass] Filter results by architecture

[Joshua Branson]

Ricardo Wurmus  writes:

> The Cuirass web interface shows the number of successful, failed, and
> pending builds for each evaluation.  Looking at just these numbers it is
> impossible to tell, how each of the supported architectures is affected.
>
> It would be good if we could separate the view by architecture.  Then we
> could more easily determine that a change broke many builds for one
> architecture while fixing builds on another.
>
> One way to do this would be to accept an optional query variable, e.g.
>
> http://ci.guix.info/jobset/guix-master?system=x86_64-linux

That is an option.  Another one is using a REST API.  It seems to have
all the hype these days.  So the URL would turn into:

 http://ci.guix.info/jobset/guix-master/system/x86_64-linux

Though I freely admit, I don't completely understand the benefits of REST.

>
> This could be selected from a drop-down on the page or exposed through a
> number of links.
>
> --
> Ricardo

bug#31814: setuid programs are not first in PATH

[Joshua Branson]

Clément Lassieur  writes:

> Joshua Branson  writes:
>
>> Clément Lassieur  writes:
>>
>>> Hi,
>>>
>>> sourcing /etc/profile
>>>
>>> - prepends /run/setuid-programs to $PATH
>>> - then sources $HOME/.guix-profile/etc/profile
>>>
>>> and sourcing $HOME/.guix-profile/etc/profile
>>>
>>> - prepends $HOME/.guix-profile/bin to $PATH
>>> - prepends $HOME/.guix-profile/sbin to $PATH
>>>
>>> so in the end, $PATH looks like:
>>>
>>> ~/.config/guix/current/bin:~/.guix-profile/bin:~/.guix-profile/sbin:/run/setuid-programs:...
>>>
>>> and a command like 'ping' is found in ~/.guix-profile/bin, which makes
>>> it unusable.
>>
>> I'm probably being really silly, but shouldn't it still work?  I mean
>> ~/.guix-profile/bin is still in your path right?
>
> Yes, but ~/.guix-profile/bin/ping (which is the one being chosen)
> doesn't have the setuid flag, so it doesn't work.

Oh.  I didn't realize that the ping command was a setuid program.  cool.

bug#31814: setuid programs are not first in PATH

[Joshua Branson]

Clément Lassieur  writes:

> Hi,
>
> sourcing /etc/profile
>
> - prepends /run/setuid-programs to $PATH
> - then sources $HOME/.guix-profile/etc/profile
>
> and sourcing $HOME/.guix-profile/etc/profile
>
> - prepends $HOME/.guix-profile/bin to $PATH
> - prepends $HOME/.guix-profile/sbin to $PATH
>
> so in the end, $PATH looks like:
>
> ~/.config/guix/current/bin:~/.guix-profile/bin:~/.guix-profile/sbin:/run/setuid-programs:...
>
> and a command like 'ping' is found in ~/.guix-profile/bin, which makes
> it unusable.

I'm probably being really silly, but shouldn't it still work?  I mean
~/.guix-profile/bin is still in your path right?

>
> Clément

bug#31159: Reverse order for old grub.cfg entries

[Joshua Branson]

That's actually a pretty good idea!

Vagrant Cascadian  writes:

> Hi!
>
> This is a pretty minor issue, but I've found that the "GNU system, old
> configurations..." part of the menu would be nicer if the most recent
> generations were listed at the top, rather than the oldest generations.
>
> Currently it lists generation 1 as the first entry in the list, and if
> I've got 50+ generations installed and I don't want to boot the current
> generation, I'm most likely going to want to revert to one of the more
> recent generations rather than the very oldest.
>
> live well,
>   vagrant

bug#30312: documentation: misleading EFI partitioning instructions

[Joshua Branson]

By no means am I a developer, but that sounds like a good idea.


On Thu, Feb 1, 2018, at 3:01 AM, Gábor Boskovits wrote:
> 2018-02-01 10:13 GMT+01:00 Gábor Boskovits :
>> 2018-01-31 20:01 GMT+01:00 Ricardo Wurmus > berlin.de>:>>> The manual section “Preparing for Installation: Disk
>>> Partitioning” says>>>  this:
>>> 
>>>  --8<---cut here---start->8---
>>> If your disk uses the GUID Partition Table (GPT) format and you
>>> plan>>>  to install BIOS-based GRUB (which is the default), make sure a
>>>  BIOS Boot>>>  Partition is available (*note (grub)BIOS installation::).
>>> 
>>> If you instead wish to use EFI-based GRUB, a FAT32 “EFI System
>>>  Partition” (ESP) is required.  This partition should be mounted at>>>  
>>> ‘/boot/efi’ and must have the ‘esp’ flag set.  E.g., for ‘parted’:>>> 
>>>   parted /dev/sda set 1 esp on
>>> 
>>> Once you are done partitioning the target hard disk drive, you
>>> have>>>  to create a file system on the relevant partition(s)(1).  For
>>>  the ESP,>>>  if you have one and assuming it is ‘/dev/sda2’, run:
>>> 
>>>   mkfs.fat -F32 /dev/sda2
>>>  --8<---cut here---end--->8---
>>> 
>>>  First, this sounds like it’s up to the user to pick either EFI-
>>>  based>>>  GRUB or BIOS-based GRUB.  It is not clear that this is
>>>  determined by>>>  whether the machine has a {BIOS, EFI in legacy mode} or 
>>> EFI.  It’s>>>  really not much of a choice.
>>> 
>>>  Second, the “parted” command operates on the first partition
>>>  (“1”), yet>>>  for the second command the second partition (“/dev/sda2”) is
>>>  used.  It’s>>>  better to be consistent here, i.e. to change “set 1 esp 
>>> on” to
>>>  “set 2>>>  esp on” and to state that this would modify “/dev/sda2”.
>>> 
>>>  Finally, it is not clear where the efi partition should be mounted.>>>  
>>> Should it be /mnt/boot/efi?  If so, should the configuration file
>>>  specify “/mnt/boot/efi” as the target?  Or should it be
>>>  “/boot/efi”?>>> 
>>>  An example would be useful here.
>>> 
>> I agree an example would be nice.
>> I will have a look at this when I have time.
>> I guess I had done something similar.
>> 
> I've just looked around and found that we have ovmf in our repository.> It 
> would be nice if we could create a system test and use an ovmf qemu
> to test installation.> Once we have that we could get the documentation 
> consistent with a
> working testcase.> WDYT? 
>>  
>> 
>>> --
>>>  Ricardo
>>> 
>>> 
>> 

bug#29662: bug#24194: GUIX gc - add warning

[Joshua Branson]

Hey,
Sorry to bother you guys, but I'm having trouble leaving this email list...

I've tried logging into the web interface, and that failed.

I tried emailing guix-devel-le...@gnu.org, and that didn't seam to work.

Can someone help me leave this email list?

Thanks,

Joshua

From: bug-Guix  on 
behalf of Ludovic Courtès 
Sent: Friday, December 22, 2017 4:46 AM
To: Quiliro Ordonez Baca
Cc: 29...@debbugs.gnu.org
Subject: bug#29662: bug#24194: GUIX gc - add warning

Hi Quiliro,

Quiliro Ordonez Baca  skribis:

>>> menuentry "GNU with Linux-Libre 4.12.9 (beta)"
>>> Kernel panic
>>
>> Could you paste (or take a picture) what’s on the screen?  Without this
>> we can’t draw any conclusions.
>
> I attach one photo. There are different messages. But, wouldn't it be
> rude to attach 6MB to the whole mailing list?

Please try to compress them more.  A few 100KiB is OK.

The picture you posted roughly shows:

  deleting group 'sshd'
  groupdel: existing lock file /etc/group.lock
  groupdel: cannot lock /etc/group
  …
  ERROR: no code for module (ice-9 popen)

The group.lock error above suggests it’s an old generation before commit
aad8a143000600abec5c8ebfadec4c09f34f1b73 (see
, 12 Oct. 2017).

The (ice-9 popen) issue that ensues, I don’t know; you should type “,bt”
at the prompt when that happens and report the backtrace.

But let’s ignore this one because it looks like an old generation.

>>> menuentry "GNU with Linux-Libre 4.11.6 (beta) (#1, 2017-06-21 18:01)"
>>> No GUI. Lost keyboad configuration on tty's. Logged in as user. The
>>> output of 'sudo herd status' was 'error: connect:
>>> /var/run/shepherd/socket: No existe el fichero o el directorio'.
>>
>> Sounds like the root file system is missing files.
>>
>> Can you send the content of /var/log/shepherd.log and the last ~100
>> lines of /var/log/messages for that config?
>
> /var/log/shepherd.log:
> 2017-12-19 20:40:53 Service console-font-tty2 has been started.

[...]

> 2017-12-19 20:41:44 Service ssh-daemon could not be started.

Apart from that last line I don’t see anything to worry about.

Are you sure you paste the log of this very generation where “sudo herd
status” fails?

> I understand you doubt that this happens because guix is not supposed to
> do it. I know I could have missed something, but I doubt it. Please give me 
> the
> benefit of the doubt. It is important for me to confirm that guix does
> not have this bug. I can try to reproduce the problem with another 
> installation.

I don’t doubt you’ve stumbled upon a bug!  I’m just trying to isolate
the various issues, and here it’s just too fuzzy for me to draw any
conclusion.

Do you have a working GuixSD configuration based on a recent-ish master?
Or a clear failure with a recent GuixSD configuration?

We should focus on just one issue at a time.

Thank you,
Ludo’.

bug#23197:

[Joshua Branson]

I notice the same issue.  I believe I am using Gnome on X.  I have a Macbook 
7,1.

guix —version

0.12.0

bug#22952: Macbook2,1 brightness control requires root privileges

[Joshua Branson]

I use a Macbook 7,1 and I do not have this issue.

Perhaps this issue is resolved?

bug#26158: I can only start an X server in guix as root

[Joshua Branson]

Hello,

I've responded to this email on the guix-bugs emailing list located 
here: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=26158

I did try a guix system vm /path/to/config-file.scm;  and I could still 
not log into guixSD.

I think I might create another guix user.  If I can't login as joshua, 
perhaps I'll try logging in as "rupert" and see if that works (I'll do 
this via editing my config file and running guix system reconfigure).


Thanks,


Joshua


On 03/19/2017 05:04 PM, Ludovic Courtès wrote:
> Hi!
>
> "pelzflorian (Florian Pelz)"  skribis:
>
>> So I’m not going to be of much help, but I want to rule out the obvious:
>> For me most of the time GNOME starts only on the second log-in attempt
>> on GuixSD. I assume you have tried logging in multiple times in a row?
> That is weird.  Does ~/.xsession-errors contain any hints after a failed
> attempt?
>
> Also, did you try to reproduce it in a VM as produced by ‘guix system
> vm’?  If it’s reproducible in a VM, we could start debugging in
> parallel.  :-)
>
> Thanks,
> Ludo’.
>

bug#26158: Gnome starts unreliably

[Joshua Branson]

So I’ve gotten responses for this on the help-guix mailing list and in the 
guix-bugs list.  I’ll try to just respond to the bug mailing list so the 
conversation is in one place.

I did login as root, run guix system vm /etc/gnome-xfce.scm;   A vm popped up.  
I could not login as joshua, but I could also not login as root either.   When 
I tried to login as joshua, after I typed in my password, it prompted me for a 
user name.  So I can’t login as joshua in the vm.  Outside the vm, when I try 
logging in as joshua I see Logging in, I see lots of text, and then I’m back at 
the login screen.   In the vm, I tried logging in a root, and it tries to log 
me in, but inevitably I end up at the login screen again.   Outside the vm, 
when I try logging in as root, it works fine.

I tried looking for the x-session errors file and couldn’t find anything.

cat /home/joshua/.xsession-errors;

No file.


cat /root/.xsession-errors;

No file. 

cat / .xsession-errors;

no file.


Also it looks like Parabola X errors are listed in ~/.local/share/xorg/, 
because X is rootless in Parabola.   Does X start as root in guixSD?

If so,

pwd;  -> /var/log


grep -e Log -e tty Xorg.0.log ->  March 22  16:22:29(today about an hour 
ago)

grep EE Xorg.0.log

43.680  (EE) NOUVEAU (0):  [COPY] failed to allocate class.

grep WW Xorg.0.log

(WW)  Open ACPI failed (/var/run/aspid.socket)  (No such file or directory)
(WW)  Falling back to old probe method for mode setting
(WW)  Falling back to old probe method for fbdev
(WW) Falling back to old probe method vesa


I feel like if someone tries to make a vm of my scheme file, they’re going to 
be able to log in just fine….Wait I didn’t set my normal user password in the 
vm….  So I probably could login to the vm, because my normal user password was 
not set right?  BUT I can’t get a tty in a vm?  I tried, and I was in outside 
the vm in a normal tty.

IDK.  

Joshua

P.S.  Most of the time when I login to gnome my mouse cannot move left to 
right.  It’s probably a different issue, but I felt I should probably mention 
it.

bug#26158: Gnome starts unreliably

[Joshua Branson]

I ran as "joshua"

guix package -I xf86-video-intel

and

guix package -I xf86-video-nouveau


Guix had no output on either of those commands, which means neither is 
installed for my user joshua right?  BUT I can login to gnome as root.  So 
obviously one of those xf86-video-* is installed in my root user profile right?


I did go ahead and login to a virtual console and run as "joshua":

guix package -i xf86-video-nouveau;


So now my non-root user "joshua" has xf86-video-nouveau installed.  I tried 
logging into Gnome, gnome on X, and xfce several times as "joshua".  It did not 
work.  I rebooted and tried again.  I still cannot login.

Joshua

P.S.  I originally posted this to help-guix, so I'm not sure how it came to be 
on the guix-bugs mailing list.  But when I look at the bug online ( 
https://debbugs.gnu.org/cgi/bugreport.cgi?bug=26158 )  my original email is not 
present.  So I'm attaching the original email as well, which has my config.scm 
and some relevant errors that I can find.  Thanks for the rapid responses.  
Essentially I am dual booting guixSD and Parabola and both share the same 
/home.  I'm assuming that is part of the problem.


 Forwarded Message 
Subject:I can only start an X server in guix as root
Date:   Fri, 17 Mar 2017 20:50:07 -0400
From:   Joshua Branson <mailto:bran...@hotmail.com>
To: help-g...@gnu.org<mailto:help-g...@gnu.org>





Hello,


I currently dual boot guixSD and Parabola.  I use a macbook 7,1, and I
am unable to start an X server in guix as my normal user.  I can login
to gnome via my root user, but obviously this is not ideal.  I can login
to a virtual console as my normal user and access Emacs (yeah), but it
would be nice to be able to start gnome as my normal user.  Just today I ran

guix pull; sudo guix pull; guix system reconfigure /etc/gnome-xfce.scm


It updated fine.  I rebooted and the problem still persists.  Parabola
and guix have seperate / partitions, but they share the same /home.
I've set up guix to create my normal user (joshua) with a uid of 2000,
because that is the uid that the user joshua has on parabola.

I'm attaching my config.scm file and some errors that I've found that
are probably relevant.  Any help would be nice.





grep WW Xorg.0.log
[  6357.578] (WW) xf86CloseConsole: VT_ACTIVATE failed: Input/output error
(WW) warning, (EE) error, (NI) not implemented, (??) unknown.
[47.212] (WW) `fonts.dir' not found (or not valid) in 
"/usr/share/fonts/100dpi/".
[47.212] (WW) `fonts.dir' not found (or not valid) in 
"/usr/share/fonts/75dpi/".
[47.237] (WW) Open ACPI failed (/var/run/acpid.socket) (No such file or 
directory)
[47.385] (WW) Warning, couldn't open module nv
[47.393] (WW) Warning, couldn't open module fbdev
[47.393] (WW) Warning, couldn't open module vesa
[47.394] (WW) Falling back to old probe method for modesetting
[47.395] (WW) VGA arbiter: cannot open kernel arbiter, no multi-card support
[  6357.578] (WW) xf86CloseConsole: KDSETMODE failed: Input/output error
[  6357.578] (WW) xf86CloseConsole: VT_GETMODE failed: Input/output error
[  6357.578] (WW) xf86CloseConsole: VT_ACTIVATE failed: Input/output error


grep EE Xorg.1.log
[47.080] Current Operating System: Linux parabola 4.10.1-gnu-1 #1 SMP 
PREEMPT Mon Feb 27 17:40:02 UYT 2017 x86_64
(WW) warning, (EE) error, (NI) not implemented, (??) unknown.
[47.385] (EE) Failed to load module "nv" (module does not exist, 0)
[47.393] (EE) Failed to load module "fbdev" (module does not exist, 0)
[47.393] (EE) Failed to load module "vesa" (module does not exist, 0)
[47.580] (EE) NOUVEAU(0): [COPY] failed to allocate class.
[  6357.259] (EE) systemd-logind: failed to release device: Connection is closed
[  6357.284] (EE) systemd-logind: failed to release device: Connection is closed
[  6357.309] (EE) systemd-logind: failed to release device: Connection is closed
[  6357.346] (EE) systemd-logind: failed to release device: Connection is closed
[  6357.366] (EE) systemd-logind: failed to release device: Connection is closed
[  6357.379] (EE) systemd-logind: failed to release device: Connection is closed
[  6357.393] (EE) systemd-logind: failed to release device: Connection is closed
[  6357.578] (EE) systemd-logind: ReleaseControl failed: Connection is closed

tail -n 1 /var/log/messages | grep WARNING -m 5 -n

223:Jan  3 15:14:42 localhost avahi-daemon[326]: WARNING: No NSS support for 
mDNS detected, consider installing nss-mdns!
691:Feb  4 10:27:09 localhost avahi-daemon[326]: WARNING: No NSS support for 
mDNS detected, consider installing nss-mdns!
1694:Feb  4 11:07:13 localhost avahi-daemon[324]: WARNING: No NSS support for 
mDNS detected, consider installing nss-mdns!
2626:Feb  4 11:12:58 localhost avahi-daemon[326]: WARNING: 

bug#18700: GNU lightening fails to build on all platforms

[Joshua Branson]

Oh wow.  Thanks for the tip.  haha.  I'm such a crappy speller.


Joshua

bug#26158: Gnome starts unreliably

[Joshua Branson]

Yes sir.  I've tried logging in multiple times.  I did it just now to be
sure.  I tried logging in 3 times for each of the desktops I have
installed: Gnome on X, Gnome (which I assume is on wayland), and on
xfce.I could not log in.  But when I tried logging in as root, it
worked just fine.  :)   Just to reiterate, I can login to a virtual
console. 


If I could get Emacs' erc to work on a virtual console, I'd complain a
little less perhaps. 


P.S.


Herein follows a slightly related rant, in which I think out loud.  I've
heard about Guix developers logging into a virtual console and working
from that, which sounds totally B.A.  The reason that doesn't work for
me at the moment, is that I've told erc to store my irc passwords in
.authinfo.gpg.  AND emacs from a virtual console does not properly
decrypt the file, so I can't use erc on emacs in a virtual console.  The
error I get says pinentry not installed, but I know I have installed it
before.  I did just reconfigure, so maybe I should have to install it
again.  I suppose that I could write some elisp, to check if the current
system is guix.  If yes, then don't use .authinfo.gpg.   Then I would
have to figure out how to mail via emacs, which I've done before.  That
way I could contribute to guix whilst inside guix.


Joshua

bug#18838: zsh test suite failures, possible due to 'noatime' mount flag

[Joshua Branson]

This is still an issue.  The last two builds for i686 and arm appear to have 
been built fine.

But MIPS and x86_64 both have recent failures.

Joshua

bug#18742: gunner intermittently fails its test suit on all platforms

[Joshua Branson]

This seems to be partially resolved.  gnunet is now at version 0.10.1.  And 
both i686 and X86_64 normally build correctly.  Though there were two recent 
fails on both builds.  

mips64el is failing a lot.  I don’t see a correct build yet.

Joshua

bug#18700: GNU Lightening fails to build on all platforms

[Joshua Branson]

This still seems to be an issue.  The latest builds are from January of 
2015.  

guix package -s lightening produces no output.

And I cannot find lightening on the packages list on the guixSD website, which 
I suppose is obvious.  If the package fails to build, then it wouldn’t be 
included with guix yet.

Joshua

bug#18542: gnome-vfs intermittent test failures

[Joshua Branson]

I don’t see any recent issues of a build failure at these links.  Since april 
of 2015 both packages seem to be building fine.  Unless I’m missing something 
this bug can be closed.

Joshua

bug#25762: trailing slash breaks "guix package"

[Joshua Branson]

I can confirm this error.  I’m dual booting guixSD on a macbook 7,1.  

guix —version

20170317.18

Joshua

bug#15549: hydra.gnu.org needs to declare its javascript licenses for

[Joshua Branson]

This is still an issue.  There are a couple of eval issues and some inline code 
that raises flags for LibreJs.

Joshua

bug#17117: Not all downloaded files are printed

[Joshua Branson]

I think that these “extra” packages are just dependancies.  So if I understand 
the original email correctly, there are 5 files that need to be downloaded 
first “openconnect”, “zlib”, “openssl”, “libxml”, and “vpnc”.

BUT later on guix downloads perl.  BUT openssl as it turns out depends on perl. 
  Another example is that libgcrypt is also downloaded.  BUT vpnc depends on 
libgcrypt.  


BUT when I ran “guix build openconnect”  (I’m running guix 0.12.0-5.1162)

I had different output.  It said

The following derivations will be built:

open connect
iproute2
libgcrypt
libgpg-error
perl
xz
vpnc
gnutls
libxml2


At that point, I C-c C-c and stopped the build, so I didn’t check to see if 
guix would later try to install dependancies that it did not initially mention.

This bug might be fixed.

Joshua