Re: One-shot Shepherd services

[znavko]

Is there possibility to define dependencies? F.e. networking will depend on my 
on-eshot service?
Also what is service 'networking' really is, and can I use wpa-supplicant + 
dhcp-client without meta-service networking?

April 18, 2019 9:39 PM, "Ludovic Courtès"  wrote:

> Hello Guix!
> 
> Today I added support for “one-shot” services in the Shepherd:
> 
> https://git.savannah.gnu.org/cgit/shepherd.git/commit/?id=c121eedfff7a50feddcf08e173d2b0dd807e8804
> 
> One-shot services start, perform a short action, and are immediately
> marked as “stopped.” (systemd has something similar:
> .)
> 
> The use case is initialization or cleanup actions like the ‘user-homes’
> service. So far ‘user-homes’ is a regular service whose ‘start’ method
> always fails; as a result, we always see this message:
> 
> Service user-homes could not be started.
> 
> From there on, we’ll be able to mark this service as one-shot (patch
> below), and thus shepherd will notice that it successfully started (or
> not) and yet mark it as stopped, which was always the intent.
> 
> There are other cases where this could be useful. For instance, we
> could turn service activation snippets into one-shot services.
> 
> Since this augments the Shepherd API, I plan to release it as 0.6.0
> in time for Guix 1.0. It contains other rather minor changes compared
> to 0.5.0.
> 
> Feedback welcome!
> 
> Ludo’.

Re: Video narration

[Paul Garlick]

Hi Laura and Ludo,

> the colours are changed. Ie: the dark gray turns
> green, and the white turns somewhat pink.

Commit 4bd2e78b893fef5ce1f12bec895ee8234cabaf1f fixes the colors. 
ffmpeg needed a different pixel format to set the chroma subsampling
correctly [1].

I have been able to play the newly built cli and nocli videos in
Firefox.  Also, the combined video now starts in Firefox but stops just
before the first transition.  I think the concatenation step in the
Makefile could be the cause.

Best regards,

Paul.

1. https://trac.ffmpeg.org/wiki/Encode/VP9

Re: Introducing myself

[John Soo]

Hi Tanguy,

I just realized you said you wanted an fzf replacement. I recommend fzy. It’s 
not quite as full featured as fzf but it gets the job done. 

- John

> On Apr 18, 2019, at 1:19 PM, Tanguy Le Carrour  wrote:
> 
> (I've just realised that there was a typo in the subject… shame on me!
> … fixed… unfortunately the Internet never forgets!!)
> 
> 
> Le 04/17, Pierre Neidhardt a écrit :
>> Tanguy Le Carrour  writes:
>>> I'll try to package my favourite tools that
>>> are currently missing: ack, fd, fzf, udiskie, poetry, pyenv…
>> 
>> Suggested alternatives:
>> 
>> - ack -> the-silver-searcher (ag)
> 
> Thanks! I came across this one some time ago. This might be the
> perfect time to evaluate/adopt it!
> 
> 
>> - fzf -> Emacs with Ivy or Helm
> 
> arg… this is the much feared moment when I have to confess that I'm…
> a faithful Vim user! ^_^'
> 
> 
>> - udiskie -> See discussion here:
>>  https://lists.gnu.org/archive/html/help-guix/2018-03/msg00331.html.
>>  At some point, we could supersede both udiskie or home-baked scripts
>>  with Guix/Shepherd user services.
> 
> I'm really happy with my Bspwm [1] setup, even if it comes with absolutely no
> removable media management! I used to use `udiskctl`, but I have to
> admit that one quickly gets attached to `udiskie`.
> 
> [1]: https://github.com/baskerville/bspwm
> 
> 
> I guess the real struggle will be replacing dependency management
> in my Python projects. But that's a totally different topic!
> 
> Regards
> 
> -- 
> Tanguy
> 

Re: KMScon vs. AMD Radeon

[Ludovic Courtès]

Hi,

"pelzflorian (Florian Pelz)"  skribis:

> On Mon, Apr 15, 2019 at 02:09:57PM +0200, Ludovic Courtès wrote:
>> If that’s the best option we have so far, we can do this:
>> 
>
> The patch works fine, but:
>
> The resolution is slightly too small to read all text boxes in the
> installer’s disk partitioning dialog though.  The screen height is
> only about 35 lines.  I don’t know how to fix this, but it is not that
> important.

Do you mean the resolution is too low?  Are there fewer lines that in
the QEMU screenshot below?

> The installer got stuck in a bash prompt at the end (which is probably
> unrelated to AMD).  I exited the bash prompt and got an installer
> dialog message with a button to Reboot, but it did not reboot.

It got stuck after ‘guix system init’ had completed, right?

Were there any hints in /var/log/messages or tty12?

> Then the installed system has no graphics too (graphics freeze at the
> same message
>
> [   51.910992] fb0: switching to radeondrmfb from EFI VGA
>
> but I cannot add modprobe.blacklist=radeon because GRUB does not
> recognize my USB keyboard now (in the installer’s GRUB the USB
> keyboard was recognized).

Weird.  What keyboard layout had you selected?

Is it UEFI or “BIOS”?

(Also, I gather dd’ing to a USB key worked this time, right?)

Thanks a lot for testing!

Ludo’.

One-shot Shepherd services

[Ludovic Courtès]

Hello Guix!

Today I added support for “one-shot” services in the Shepherd:

  
https://git.savannah.gnu.org/cgit/shepherd.git/commit/?id=c121eedfff7a50feddcf08e173d2b0dd807e8804

One-shot services start, perform a short action, and are immediately
marked as “stopped.”  (systemd has something similar:
.)

The use case is initialization or cleanup actions like the ‘user-homes’
service.  So far ‘user-homes’ is a regular service whose ‘start’ method
always fails; as a result, we always see this message:

  Service user-homes could not be started.

>From there on, we’ll be able to mark this service as one-shot (patch
below), and thus shepherd will notice that it successfully started (or
not) and yet mark it as stopped, which was always the intent.

There are other cases where this could be useful.  For instance, we
could turn service activation snippets into one-shot services.

Since this augments the Shepherd API, I plan to release it as 0.6.0
in time for Guix 1.0.  It contains other rather minor changes compared
to 0.5.0.

Feedback welcome!

Ludo’.

diff --git a/gnu/packages/admin.scm b/gnu/packages/admin.scm
index 3a250eeaa8..6b26da7316 100644
--- a/gnu/packages/admin.scm
+++ b/gnu/packages/admin.scm
@@ -45,6 +45,7 @@
   #:use-module (guix packages)
   #:use-module (guix utils)
   #:use-module (guix download)
+  #:use-module ((guix gexp) #:select (local-file))
   #:use-module (guix git-download)
   #:use-module (guix build-system cmake)
   #:use-module (guix build-system emacs)
@@ -192,6 +193,7 @@ and provides a \"top-like\" mode (monitoring).")
 (build-system gnu-build-system)
 (arguments
  '(#:configure-flags '("--localstatedir=/var")))
+(replacement shepherd-next)
 (native-inputs
  `(("pkg-config" ,pkg-config)
 
@@ -214,6 +216,12 @@ interface and is based on GNU Guile.")
 (home-page "https://www.gnu.org/software/shepherd/;)
 (properties '((ftp-server . "alpha.gnu.org")
 
+(define-public shepherd-next
+  (package
+(inherit shepherd)
+(version "0.5.1")
+(source (local-file "/data/src/shepherd/shepherd-0.6.0-pre1.tar.gz"
+
 (define-public daemontools
   (package
 (name "daemontools")
diff --git a/gnu/services/shepherd.scm b/gnu/services/shepherd.scm
index 12d649f542..cf7e64a783 100644
--- a/gnu/services/shepherd.scm
+++ b/gnu/services/shepherd.scm
@@ -1,5 +1,5 @@
 ;;; GNU Guix --- Functional package management for GNU
-;;; Copyright © 2013, 2014, 2015, 2016, 2018 Ludovic Courtès 
+;;; Copyright © 2013, 2014, 2015, 2016, 2018, 2019 Ludovic Courtès 
 ;;; Copyright © 2017 Clément Lassieur 
 ;;; Copyright © 2018 Carlo Zancanaro 
 ;;;
@@ -44,6 +44,7 @@
 shepherd-service-provision
 shepherd-service-canonical-name
 shepherd-service-requirement
+shepherd-service-one-shot?
 shepherd-service-respawn?
 shepherd-service-start
 shepherd-service-stop
@@ -149,6 +150,8 @@ DEFAULT is given, use it as the service's default value."
   (provision shepherd-service-provision)   ;list of symbols
   (requirement   shepherd-service-requirement  ;list of symbols
  (default '()))
+  (one-shot? shepherd-service-one-shot?;Boolean
+ (default #f))
   (respawn?  shepherd-service-respawn? ;Boolean
  (default #t))
   (start shepherd-service-start)   ;g-expression (procedure)
@@ -238,6 +241,7 @@ stored."
#:docstring '#$(shepherd-service-documentation service)
#:provides '#$(shepherd-service-provision service)
#:requires '#$(shepherd-service-requirement service)
+   #:one-shot? '#$(shepherd-service-one-shot? service)
#:respawn? '#$(shepherd-service-respawn? service)
#:start #$(shepherd-service-start service)
#:stop #$(shepherd-service-stop service)
diff --git a/gnu/system/shadow.scm b/gnu/system/shadow.scm
index 7dc36f4a45..13b8b14095 100644
--- a/gnu/system/shadow.scm
+++ b/gnu/system/shadow.scm
@@ -323,6 +323,7 @@ accounts among ACCOUNTS+GROUPS."
   (list (shepherd-service
  (requirement '(file-systems))
  (provision '(user-homes))
+ (one-shot? #t)
  (modules '((gnu build activation)
 (gnu system accounts)))
  (start (with-imported-modules (source-module-closure
@@ -332,9 +333,7 @@ accounts among ACCOUNTS+GROUPS."
   (activate-user-home
(map sexp->user-account
 (list #$@(map user-account->gexp accounts
-  #f)))   ;stop
- (stop #~(const #f))
- (respawn? #f)
+  #t)))   ;success
  (documentation "Create user home 

Re: ISO installer image: GPT versus MBR partitions

[Thomas Schmitt]

Hi,

this is the xorriso run for producing a layout like "isohybrid --uefi"
with GRUB equipment for BIOS instead of ISOLINUX.

I prepended command -stdio_sync "off" in order to make use of my generous
amount of RAM for write buffering. The default syncs to disk every 16 MiB.
Good with low RAM or fast SSD.

xorriso treats its output as an optical drive.
Without sync, the speed reports on image files are rather funny:
  xorriso : UPDATE : Writing:   262432s  43.6%  fifo 88%  buf  50%  1169.9xD

===

# Layout of isohybrid --uefi. Invented by Matthew J. Garrett for Fedora.
# The EFI partition is a file inside the ISO. The BIOS equipment is ISOLINUX
# instead of GRUB. But the EFI equipment is GRUB.
# Used by Fedora, Debian, Ubuntu, Mint, Arch, and more.
# (SuSE is different by using a pure MBR partition table.)

# Additionally to a Guix ISO, we need one of those isohybrid ISOs.
# The result will not be usable for booting via BIOS, because only the first
# stages of ISOLINUX are extracted. The rest would not fit Guix anyways.
ISOHYBRID_ISO=debian-live-9.8.0-amd64-xfce.iso
ISOLINUX_BIN_ISO=/isolinux/isolinux.bin
EXTRACTED_ISOLINUX_BIN=isolinux.bin
EXTRACTED_MBR_IMG=isohybrid_mbr.img

# Guix ISO related names
BASE_ISO=guixsd-install-0.16.0.x86_64-linux.iso
MOUNT_POINT=/mnt/iso
REPACKED_ISO=guix-0.16.0.x86_64-mjg.iso

PRIV_CMD=sudo

# Extract the ISOLINUX isohybrid MBR x86 code part from the Debian ISO
dd if="$ISOHYBRID_ISO" bs=1 count=446 of="$EXTRACTED_MBR_IMG"

# Extract the ISOLINUX boot image for El Torito
xorriso \
  -report_about warning \
  -osirrox on \
  -indev "$ISOHYBRID_ISO" \
  -report_about note \
  -extract "$ISOLINUX_BIN_ISO" "$EXTRACTED_ISOLINUX_BIN"

# The mounted original ISO will donate all its files to the repacked one
$PRIV_CMD mount -o loop "$BASE_ISO" "$MOUNT_POINT"

# Pack it all up
xorriso \
   -stdio_sync off \
   -outdev "$REPACKED_ISO" \
   -volid 'GUIXSD_IMAGE' \
   \
   -map "$MOUNT_POINT" "/" \
   -map "$EXTRACTED_ISOLINUX_BIN" /isolinux/isolinux.bin \
   \
   -boot_image isolinux system_area="$EXTRACTED_MBR_IMG" \
   -boot_image any mbr_force_bootable=on \
   -boot_image any partition_offset=0 \
   \
   -boot_image any cat_path='/isolinux/boot.cat' \
   -boot_image isolinux bin_path='/isolinux/isolinux.bin'  \
   -boot_image any emul_type=no_emulation \
   -boot_image any load_size=2048 \
   -boot_image any boot_info_table=on \
   \
   -boot_image any next \
   \
   -boot_image any efi_path=/efi.img \
   -boot_image any emul_type=no_emulation \
   -boot_image isolinux partition_entry=gpt_basdat

#Clean up disk
rm "$EXTRACTED_MBR_IMG" "$EXTRACTED_ISOLINUX_BIN"

===

Expected inspection result:

  $ xorriso -indev "$REPACKED_ISO" -report_system_area plain
  ...
  Volume id: 'GUIXSD_IMAGE'
  System area options: 0x0102
  System area summary: MBR isohybrid cyl-align-on GPT
  ISO image size/512 : 2405888
  Partition offset   : 0
  MBR heads per cyl  : 74
  MBR secs per head  : 32
  MBR partition table:   N Status  TypeStart   Blocks
  MBR partition  :   1   0x80  0x000  2405888
  MBR partition  :   2   0x00  0xef35132 2880
  MBR partition path :   2  /efi.img
  GPT:   N  Info
  GPT disk GUID  :  451fe71ed0ff5d48a1c144a0316dd901
  GPT entry array:  2  248  overlapping
  GPT lba range  :  64  2405824  2405887
  GPT partition name :   1  490053004f00480079006200720069006400
  GPT partname local :   1  ISOHybrid
  GPT partition GUID :   1  451fe71ed0ff5d48a1c044a0316dd901
  GPT type GUID  :   1  a2a0d0ebe5b9334487c068b6b72699c7
  GPT partition flags:   1  0x1001
  GPT start and size :   1  0  2405824
  GPT partition name :   2  490053004f004800790062007200690064003100
  GPT partname local :   2  ISOHybrid1
  GPT partition GUID :   2  451fe71ed0ff5d48a1c344a0316dd901
  GPT type GUID  :   2  a2a0d0ebe5b9334487c068b6b72699c7
  GPT partition flags:   2  0x1001
  GPT start and size :   2  35132  2880
  GPT partition path :   2  /efi.img

For comparison, the output with debian-live-9.8.0-amd64-xfce.iso :

  Volume id: 'd-live 9.8.0 xf amd64'
  System area options: 0x0102
  System area summary: MBR isohybrid cyl-align-on GPT
  ISO image size/512 : 3811392
  Partition offset   : 0
  MBR heads per cyl  : 117
  MBR secs per head  : 32
  MBR partition table:   N Status  TypeStart   Blocks
  MBR partition  :   1   0x80  0x000  3811392
  MBR partition  :   2   0x00  0xef 1432  832
  MBR partition path :   2  /boot/grub/efi.img
  GPT:   N  Info
  GPT disk GUID  :  f2925bc0164b9245ba53a2025e420b60
  GPT entry array:  2  248  overlapping
  GPT lba range  :  64  3811328  3811391
  GPT partition name :   1  

New French PO file for 'shepherd' (version 0.6.0-pre1)

[Translation Project Robot]

Hello, gentle maintainer.

This is a message from the Translation Project robot.

A revised PO file for textual domain 'shepherd' has been submitted
by the French team of translators.  The file is available at:

https://translationproject.org/latest/shepherd/fr.po

(We can arrange things so that in the future such files are automatically
e-mailed to you when they arrive.  Ask at the address below if you want this.)

All other PO files for your package are available in:

https://translationproject.org/latest/shepherd/

Please consider including all of these in your next release, whether
official or a pretest.

Whenever you have a new distribution with a new version number ready,
containing a newer POT file, please send the URL of that distribution
tarball to the address below.  The tarball may be just a pretest or a
snapshot, it does not even have to compile.  It is just used by the
translators when they need some extra translation context.

The following HTML page has been updated:

https://translationproject.org/domain/shepherd.html

If any question arises, please contact the translation coordinator.

Thank you for all your work,

The Translation Project robot, in the
name of your translation coordinator.

Re: Introducing myself

[Tanguy Le Carrour]

(I've just realised that there was a typo in the subject… shame on me!
… fixed… unfortunately the Internet never forgets!!)


Le 04/17, Pierre Neidhardt a écrit :
> Tanguy Le Carrour  writes:
> > I'll try to package my favourite tools that
> > are currently missing: ack, fd, fzf, udiskie, poetry, pyenv…
> 
> Suggested alternatives:
> 
> - ack -> the-silver-searcher (ag)

Thanks! I came across this one some time ago. This might be the
perfect time to evaluate/adopt it!


> - fzf -> Emacs with Ivy or Helm

arg… this is the much feared moment when I have to confess that I'm…
a faithful Vim user! ^_^'


> - udiskie -> See discussion here:
>   https://lists.gnu.org/archive/html/help-guix/2018-03/msg00331.html.
>   At some point, we could supersede both udiskie or home-baked scripts
>   with Guix/Shepherd user services.

I'm really happy with my Bspwm [1] setup, even if it comes with absolutely no
removable media management! I used to use `udiskctl`, but I have to
admit that one quickly gets attached to `udiskie`.

[1]: https://github.com/baskerville/bspwm


I guess the real struggle will be replacing dependency management
in my Python projects. But that's a totally different topic!

Regards

-- 
Tanguy

New German PO file for 'shepherd' (version 0.6.0-pre1)

[Translation Project Robot]

Hello, gentle maintainer.

This is a message from the Translation Project robot.

A revised PO file for textual domain 'shepherd' has been submitted
by the German team of translators.  The file is available at:

https://translationproject.org/latest/shepherd/de.po

(We can arrange things so that in the future such files are automatically
e-mailed to you when they arrive.  Ask at the address below if you want this.)

All other PO files for your package are available in:

https://translationproject.org/latest/shepherd/

Please consider including all of these in your next release, whether
official or a pretest.

Whenever you have a new distribution with a new version number ready,
containing a newer POT file, please send the URL of that distribution
tarball to the address below.  The tarball may be just a pretest or a
snapshot, it does not even have to compile.  It is just used by the
translators when they need some extra translation context.

The following HTML page has been updated:

https://translationproject.org/domain/shepherd.html

If any question arises, please contact the translation coordinator.

Thank you for all your work,

The Translation Project robot, in the
name of your translation coordinator.

Re: Video narration

[Laura Lazzati]

Hi Paul!
Sorry, I've got up to date with this.

> Is Firefox the browser you are testing with?
Yes, I tested both with Firefox and Icecat and get the same message,
that it is corrupt :/
You mentioned you tried totem, right? In my case it runs and I can
watch the video but the colours are changed. Ie: the dark gray turns
green, and the white turns somewhat pink.
I only tested the first video.
I have a question about the Makefile. Why are we having an if in the
ffmpeg rule regarding the soundname being empty?
> What I was thinking was that the cli sessions should end with a short
> pause.  This will be the case as long as either duration1 is greater
> than duration2 or the audio file has a silent section at the end.
>
> If any of the transitions are too abrupt we can add some silence to the
> relevant audio file.  The command I used for the silent slide in 02-
> daily-use2 was:
>
> $ ffmpeg -f lavfi -i anullsrc=r=4800:cl=mono -t  -q:a 9 -c:a
> libmp3lame .mp3
>
> This creates an mp3 file with  seconds of silence.
>
> So a one second pause, say, could be concatenated (with ffmpeg) at the
> beginning or end of an audio file to improve the transition.
I see, then we can create a script for this, that runs before the
script for creating the cli session videos, WDYT?
I am really amazed about how much you know about audio and video creation :)
I have a question, what happens when duration2 > duration1?
>
> Best regards,
>
> Paul.
>
>
>

Re: Should we upgrade openssl?

[Ludovic Courtès]

Hi Gábor,

Gábor Boskovits  skribis:

> Ludovic Courtès  ezt írta (időpont: 2019. ápr. 17., Sze

[...]

>> Likewise, I don’t think the OpenSSL upgrade can be merged on time.  But
>> that’s OK: we can start working on it and have it merged as soon as
>> possible, possibly with all of ‘core-updates’.
>>
> Do we have a list of actionable items we can work on to help?

‘core-updates’ currently fails to build Python 2, which prevents
evaluations from happening in Cuirass.

That said, I’d encourage you to focus on 1.0 first in the short term.
:-)

Thanks,
Ludo’.

Re: Video narration

[Ludovic Courtès]

Hi Paul,

Paul Garlick  skribis:

>> Can you tell me which players work for you? I tried with my browser
>> and it still tells me that the file is corrupt :/
>
> I have tested Parole and Videos media players and Firefox and Midori
> browsers.  All work except Firefox, which gives the message:
>
> 'Video can't be played because the file is corrupt'

Ricardo and I encountered that problem before… but I don’t remember how
Ricardo solved it.  I think it had to do with the choice of codecs and
all.

Ludo’.

Re: Software Heritage & Guix

[Ludovic Courtès]

Hello,

Ludovic Courtès  skribis:

> I’ve written a post on the Software Heritage support in Guix:
>
>   
> https://gnu.org/s/guix/blog/2019/connecting-reproducible-deployment-to-a-long-term-source-code-archive/

As a followup, the Software Heritage folks posted an article on their
blog:

  
https://www.softwareheritage.org/2019/04/18/software-heritage-and-gnu-guix-join-forces-to-enable-long-term-reproducibility/

Notice the neat logo blend.  :-)

Ludo’.

New Ukrainian PO file for 'shepherd' (version 0.6.0-pre1)

[Translation Project Robot]

Hello, gentle maintainer.

This is a message from the Translation Project robot.

A revised PO file for textual domain 'shepherd' has been submitted
by the Ukrainian team of translators.  The file is available at:

https://translationproject.org/latest/shepherd/uk.po

(We can arrange things so that in the future such files are automatically
e-mailed to you when they arrive.  Ask at the address below if you want this.)

All other PO files for your package are available in:

https://translationproject.org/latest/shepherd/

Please consider including all of these in your next release, whether
official or a pretest.

Whenever you have a new distribution with a new version number ready,
containing a newer POT file, please send the URL of that distribution
tarball to the address below.  The tarball may be just a pretest or a
snapshot, it does not even have to compile.  It is just used by the
translators when they need some extra translation context.

The following HTML page has been updated:

https://translationproject.org/domain/shepherd.html

If any question arises, please contact the translation coordinator.

Thank you for all your work,

The Translation Project robot, in the
name of your translation coordinator.

New Brazilian Portuguese PO file for 'shepherd' (version 0.6.0-pre1)

[Translation Project Robot]

Hello, gentle maintainer.

This is a message from the Translation Project robot.

A revised PO file for textual domain 'shepherd' has been submitted
by the Brazilian Portuguese team of translators.  The file is available at:

https://translationproject.org/latest/shepherd/pt_BR.po

(We can arrange things so that in the future such files are automatically
e-mailed to you when they arrive.  Ask at the address below if you want this.)

All other PO files for your package are available in:

https://translationproject.org/latest/shepherd/

Please consider including all of these in your next release, whether
official or a pretest.

Whenever you have a new distribution with a new version number ready,
containing a newer POT file, please send the URL of that distribution
tarball to the address below.  The tarball may be just a pretest or a
snapshot, it does not even have to compile.  It is just used by the
translators when they need some extra translation context.

The following HTML page has been updated:

https://translationproject.org/domain/shepherd.html

If any question arises, please contact the translation coordinator.

Thank you for all your work,

The Translation Project robot, in the
name of your translation coordinator.

New Swedish PO file for 'shepherd' (version 0.6.0-pre1)

[Translation Project Robot]

Hello, gentle maintainer.

This is a message from the Translation Project robot.

A revised PO file for textual domain 'shepherd' has been submitted
by the Swedish team of translators.  The file is available at:

https://translationproject.org/latest/shepherd/sv.po

(We can arrange things so that in the future such files are automatically
e-mailed to you when they arrive.  Ask at the address below if you want this.)

All other PO files for your package are available in:

https://translationproject.org/latest/shepherd/

Please consider including all of these in your next release, whether
official or a pretest.

Whenever you have a new distribution with a new version number ready,
containing a newer POT file, please send the URL of that distribution
tarball to the address below.  The tarball may be just a pretest or a
snapshot, it does not even have to compile.  It is just used by the
translators when they need some extra translation context.

The following HTML page has been updated:

https://translationproject.org/domain/shepherd.html

If any question arises, please contact the translation coordinator.

Thank you for all your work,

The Translation Project robot, in the
name of your translation coordinator.

Re: Guix on Purism's Librems?

[Katherine Cox-Buday]

Christopher Lemmer Webber  writes:

> I have a LibreM laptop.  I'm not using it at the moment because I need
> to send it in for repairs (and keep procrastinating on that) but I'll
> say that GuixSD worked just fine out of the box.

Is the boot process as secure as the so-called "Pure Boot" process with
Pure OS? It's not clear to me how to use the TPM or head with Guix.

>> Also, would it make sense for us to have a package specifically for
>> hardware like this to make it easier to build install images for the
>> machines? Even if the packages don't do much, there is still value in
>> declaring that the specific configuration of hardware has been
>> investigated, and is supported.
>
> I'm happy to publish my guix configuration if it helps, though I think
> it isn't anything particularly special for the laptop to work.
>
> That said I think I'd love more reports about what laptops/machines
> people have gotten to work with GuixSD and what challenges they've run
> into in general.  It would be nice to collect that.

Yes! And I think a great way to collect those responses would be
programatically. For example, you say that there wasn't "anything
particularly sspecial for the laptop to work". I still think there's
value in programatically declaring support for the Librem -- even if
there's nothing much there. It allows future users to have confidence
that the hardware configuration is supported. And should something come
up, we already have somewhere to hang our hat :)

-- 
Katherine

New template for 'shepherd' made available

[Translation Project Robot]

Hello, gentle maintainer.

This is a message from the Translation Project robot.  (If you have
any questions, send them to .)

A new POT file for textual domain 'shepherd' has been made available
to the language teams for translation.  It is archived as:

https://translationproject.org/POT-files/shepherd-0.6.0-pre1.pot

Whenever you have a new distribution with a new version number ready,
containing a newer POT file, please send the URL of that distribution
tarball to the address below.  The tarball may be just a pretest or a
snapshot, it does not even have to compile.  It is just used by the
translators when they need some extra translation context.

Below is the URL which has been provided to the translators of your
package.  Please inform the translation coordinator, at the address
at the bottom, if this information is not current:

http://web.fdn.fr/~lcourtes/tmp/shepherd-0.6.0-pre1.tar.gz

We can arrange things so that translated PO files are automatically e-mailed
to you when they arrive.  Ask at the address below if you want this.

Thank you for all your work,

The Translation Project robot, in the
name of your translation coordinator.

Re: TeX Live

[Ricardo Wurmus]

Pierre Neidhardt  writes:

> Ludovic Courtès  writes:
>
>> For the specific usability issue you mention (what’s the right package
>> to install when one wants tables?), I think we should add a section in
>> the manual, as has been discussed before.
>
> No package, this is default LaTeX.

I think this is one and the same thing.  When I wrote the first modular
package definitions I just looked at the LaTeX base packages, tried to
build them, failed, added package definitions to address the failure,
and repeated until things wouldn’t fail any more.

This means that the set of packages that gives us a “default LaTeX”
experience are incomplete.

I suggest taking a closer look at the ingredients of texlive-latex-base.
Many of the packages that contribute to it may actually be woefully
incomplete.  For each of the packages we should compare the expected
output (according to the texlive database) with the actual output.  Some
cases may be a little tricky, but overall I think the problem is not too
difficult to solve with systematic work.

With some luck I may be able to take a look at this next week, but I’d
be happy if someone with a clear head took the lead instead.

--
Ricardo

Re: ISO installer image: GPT versus MBR partitions

[Thomas Schmitt]

Hi,

Florian Pelz wrote:
> I find a efi/boot/bootx64.efi PE executable inside efi.img on the Guix
> ISO. On Debian the long name is EFI/boot/bootx64.iso in capital letters

(I assume s/bootx64.iso/bootx64.efi/)

It's FAT filesystem. Upper case or lower case does not matter.
Most probably it is a matter of mount options whether you see capital
or small letters.
The image files seem to contain the names in capital letters:

  # mount guixsd-install-0.16.0.x86_64-linux.iso /mnt/iso

  $ strings /mnt/iso/efi.img | head -9
  MTOO4021
  Hf3NO NAMEFAT12
  EFI
  .
  ..
  BOOT
  .
  ..
  BOOTX64 EFI

  # umount /mnt/iso
  # mount debian-live-9.8.0-amd64-xfce.iso /mnt/iso

  $ strings /mnt/iso/boot/grub/efi.img | head -17
  mkfs.fat
  dNO NAMEFAT12
  This is not a bootable disk.  Please insert a bootable floppy and
  press any key to try again ...
  EFI
  KNKN
  .
  KNKN
  ..
  KNKN
  BOOT
  KNKN
  .
  KNKN
  ..
  KNKN
  BOOTX64 EFI


> How would I check if it gets run?

Interesting question. If it says "GRUB" or "Guix", then it runs. But up
to then it may start and fail silently.


> the Guix USB drive
> merely does not show up (for Debian, it shows up as an EFI partition
> in the boot menu).

So probably it is not run.

I'll develop a xorriso repack run for the layout of Debian ISOs, as
strange as it is.


Have a nice day :)

Thomas

Re: Guix on Purism's Librems?

[Christopher Lemmer Webber]

Katherine Cox-Buday writes:

> Hey all,

Hi Katherine!

> I brought this up in IRC tonight, and I thought I'd cast a net on the
> mailing list to collect experiences. I am considering purchasing a
> Librem laptop, and I was curious how Guix runs on it. Would anyone who
> has these laptops (especially if you have a version with the TPM and
> head) care to write up an experience-report?

I have a LibreM laptop.  I'm not using it at the moment because I need
to send it in for repairs (and keep procrastinating on that) but I'll
say that GuixSD worked just fine out of the box.

> Also, would it make sense for us to have a package specifically for
> hardware like this to make it easier to build install images for the
> machines? Even if the packages don't do much, there is still value in
> declaring that the specific configuration of hardware has been
> investigated, and is supported.

I'm happy to publish my guix configuration if it helps, though I think
it isn't anything particularly special for the laptop to work.

That said I think I'd love more reports about what laptops/machines
people have gotten to work with GuixSD and what challenges they've run
into in general.  It would be nice to collect that.

 - Chris

Re: ISO installer image: GPT versus MBR partitions

[pelzflorian (Florian Pelz)]

On Thu, Apr 18, 2019 at 10:13:33AM +0200, Thomas Schmitt wrote:
> Florian Pelz wrote:
> > ... > On the 2011 Macbook I am using
> 
> The rumors rather talk of the years up to 2010. But well ...
> 
> 

Next week I can ask others who own newer Macbooks to try out the ISO.
If this only affects old Macbooks, fixing it might not be that
important.



> I am nearly out of ideas if not by surprise a test with Guix "i686" ISO
> works.
> 

I just tried guix-0.15.0.i686-mbr-only.iso and boot gets stuck too.
Remarkably, when using the original
guixsd-install-0.15.0.i686-linux.iso on the same x86_64 2011 Macbook,
I can at least still boot from other partitions, the Guix USB drive
merely does not show up (for Debian, it shows up as an EFI partition
in the boot menu).





> The last resort would be to try the weird "isohybrid --uefi" layout of
> questionable MBR partition table and invalid GPT.
> (This might answer the riddle why Matthew Garrett kept the GPT data
>  after he obviously decided for MBR partitioning.)
> 
> But before we do that, we should make absolutely sure that EFI does
> not start the bootx64.efi of the Guix ISO. Only then, the partitioning
> is to blame. After bootx64.efi was started, GRUB is in charge.
> So its modules in both ISOs might make the difference.
> 
> 

I find a efi/boot/bootx64.efi PE executable inside efi.img on the Guix
ISO.  On Debian the long name is EFI/boot/bootx64.iso in capital
letters; I do not know if this can make a difference.  How would I
check if it gets run?

Regards,
Florian

Re: [WIP] Lightdm service

[L p R n d n]

Hello again again,

Just to tell you, the problem has been fixed.
For information, to start a xsession, it needed a correct wrapper.
'xinitrc' located in gnu/services/xorg.scm seems to provide just that.
Adding it to the lightdm.conf under 'session-wrapper' makes the magic
happen! :D

Have a nice day,

L  p R n  d n

Re: [WIP] Lightdm service

[L p R n d n]

Hello again!

Just sharing some logsthat might be usefull.
And everything is tested in a simple vm.

Thanks,

L  p R n  d n



secure
Description: Binary data


lightdm.log
Description: Binary data


seat0-greeter.log
Description: Binary data

Re: ISO installer image: GPT versus MBR partitions

[Thomas Schmitt]

Hi,

i wrote:
> > From Florian's reports i cannot tell which ISO he used

Florian Pelz wrote:
> The current git master for x86_64.

I begin to remember discussions about 64-bit Macs having 32-bit EFI
firmware.
Googling brought me to
  
https://everymac.com/mac-answers/snow-leopard-mac-os-x-faq/mac-os-x-snow-leopard-64-bit-macs-64-bit-efi-boot-in-64-bit-mode.html
Note the combinations of "Processor 64" and "EFI 32".
(I think the "Boot" column is about MacOS, not the firmware.)


> ... > On the 2011 Macbook I am using

The rumors rather talk of the years up to 2010. But well ...


Yesterday:
> The Debian ISO works fine
> $ gdisk Downloads/debian-live-9.8.0-amd64-xfce.iso

Let's see what's in there ...

  drwxr-xr-x 3 root root 16384 Jan  1  1970 /mnt/fat
  drwxr-xr-x 3 root root 2048 Feb 11 20:17 /mnt/fat/efi
  drwxr-xr-x 2 root root 2048 Feb 11 20:17 /mnt/fat/efi/boot
  -rwxr-xr-x 1 root root 390656 Feb 11 20:17 /mnt/fat/efi/boot/bootx64.efi

No 32-bit start program. Grrr.


> I can try another one this weekend.

I am nearly out of ideas if not by surprise a test with Guix "i686" ISO
works.

The last resort would be to try the weird "isohybrid --uefi" layout of
questionable MBR partition table and invalid GPT.
(This might answer the riddle why Matthew Garrett kept the GPT data
 after he obviously decided for MBR partitioning.)

But before we do that, we should make absolutely sure that EFI does
not start the bootx64.efi of the Guix ISO. Only then, the partitioning
is to blame. After bootx64.efi was started, GRUB is in charge.
So its modules in both ISOs might make the difference.


Have a nice day :)

Thomas

Re: ISO installer image: GPT versus MBR partitions

[pelzflorian (Florian Pelz)]

On Thu, Apr 18, 2019 at 09:00:23AM +0200, Thomas Schmitt wrote:
> From Florian's reports i cannot tell which ISO he used as base for
> repacking. Maybe one should distinguish the ISOs by their Volume Id. Like:
>   GUIXSD_IMAGE_I686
>   GUIXSD_IMAGE_X86_64

The current git master for x86_64.  I can try another one this weekend.

Re: KMScon vs. AMD Radeon

[pelzflorian (Florian Pelz)]

On Wed, Apr 17, 2019 at 07:26:27PM +0200, pelzflorian (Florian Pelz) wrote:
> Then the installed system has no graphics too (graphics freeze at the
> same message
> 
> [   51.910992] fb0: switching to radeondrmfb from EFI VGA
> 
> but I cannot add modprobe.blacklist=radeon because GRUB does not
> recognize my USB keyboard now (in the installer’s GRUB the USB
> keyboard was recognized).
> 

I dug out a PS/2 keyboard which works.  When adding
modprobe.blacklist=radeon then GDM does not start.
/var/log/gdm/greeter.log contains beside various expected errors for
fbdev:

(EE) open /dev/fb0: Permission denied


So i did

chmod 777 /dev/fb0
herd restart xorg-server

but it still says permission denied on /dev/fb0.

Regards,
Florian

Re: ISO installer image: GPT versus MBR partitions

[Thomas Schmitt]

Hi,

meanwhile i learned that "i686" means 32 bit.

So i downloaded
  guixsd-install-0.16.0.x86_64-linux.iso
and see indeed the boot program for 64 bit x86 in the EFI partition:

  -rwxr-xr-x 1 root root 132608 Dec  5 16:59 /mnt/fat/efi/boot/bootx64.efi

>From Florian's reports i cannot tell which ISO he used as base for
repacking. Maybe one should distinguish the ISOs by their Volume Id. Like:
  GUIXSD_IMAGE_I686
  GUIXSD_IMAGE_X86_64


Have a nice day :)

Thomas

Re: ISO installer image: GPT versus MBR partitions

[Thomas Schmitt]

Hi,

Florian Pelz wrote:
> my Macbook still does not like it.

The content of the EFI partition of guixsd-install-0.15.0.i686-linux.iso
does not look like it is ready for 64-bit x86:

  $ mount guixsd-install-0.15.0.i686-linux.iso /mnt/iso
  $ mount /mnt/iso/efi.img /mnt/fat
  $ find /mnt/fat -exec ls -ld '{}' ';'
  drwxr-xr-x 3 root root 7680 Jan  1  1970 /mnt/fat
  drwxr-xr-x 3 root root 1024 Jul  6  2018 /mnt/fat/efi
  drwxr-xr-x 2 root root 1024 Jul  6  2018 /mnt/fat/efi/boot
  -rwxr-xr-x 1 root root 96256 Jul  6  2018 /mnt/fat/efi/boot/boot.efi
  -rwxr-xr-x 1 root root 96256 Jul  6  2018 /mnt/fat/efi/boot/bootia32.efi

According to UEFI specs, bootia32.efi is the start program for 32-bit x86
systems.
The name for 64-bit x86 systems would be bootx64.efi like in the EFI
partition of debian-9.3.0-amd64-netinst.iso :

  drwxr-xr-x 3 root root 16384 Jan  1  1970 /mnt/fat
  drwxr-xr-x 3 root root 2048 Dec  9  2017 /mnt/fat/efi
  drwxr-xr-x 2 root root 2048 Dec  9  2017 /mnt/fat/efi/boot
  -rwxr-xr-x 1 root root 390656 Dec  9  2017 /mnt/fat/efi/boot/bootx64.efi

(Afaik, the EFI partition image is created by grub-mkimage. But i may
 be wrong. Better check source of debian-cd or ask Steve McIntyre.)

Was GRUB configured to produce 64-bit x86 code ?


I only know how to do it with Debian. There i have to install the
packages "grub-pc" for BIOS, "grub-efi-ia32-bin" for 32 bit x86 EFI,
"grub-efi-amd64-bin" for 64 bit x86 EFI.

The EFI partition then has:

  drwxr-xr-x 3 root root 7680 Jan  1  1970 /mnt/fat
  drwxr-xr-x 3 root root 1024 Feb  6  2016 /mnt/fat/efi
  drwxr-xr-x 2 root root 1024 Feb  6  2016 /mnt/fat/efi/boot
  -rwxr-xr-x 1 root root 132608 Feb  6  2016 /mnt/fat/efi/boot/bootx64.efi
  -rwxr-xr-x 1 root root 95744 Feb  6  2016 /mnt/fat/efi/boot/bootia32.efi
  -rwxr-xr-x 1 root root 95744 Feb  6  2016 /mnt/fat/efi/boot/boot.efi
  -rwxr-xr-x 1 root root 1759 Dec 10  2017 /mnt/fat/NvVars

("grub-pc" caused bootable MBR x85 code.)


Have a nice day :)

Thomas