ABI and emacs-guix

[Brett Gilio]

Hi all,

Was there another ABI change to Guix? The last time this happened
emacs-guix began behaving improperly and spitting out unresolvable error
messages in the *Messages* buffer. This is happening again, and Ludo
fixed it by rebuilding it I think?

If this is the case, is there a consistent way to have emacs-guix be
rebuilt after these changes?

Best,
Brett Gilio

Re: ISO installer image: GPT versus MBR partitions

[Danny Milosavljevic]

> How deep shall this go ? dd, awk, od, head, find, test, mv, rm, ...

Ideally everything.  That's why we don't use shell scripts that much:  They
are annoying to make behave.  Compare with C which will link a library and
with option "-Wl,-rpath" (which we use everywhere) will embed the absolute
path to the library in the executable and NEVER use another one than the
one it was compiled with.

Usually, we just wrap the entire shell script in a wrapper that sets
up PATH first.  As long as there are no naming conflicts in the
dependencies, it should be fine (since PATH just lists directories, not
regular files, it could still be bad).

I'm thinking of doing this PATH wrapper here, too.  It's easily automated on
the Guix side.

The end goal (for the most part reached) is to have a package be a
module that doesn't affect the rest of the system except when it is
supposed to.  Other distributions are spectacularily bad at this--to
say nothing about Windows where it's normal that installing one
application can break a totally unrelated application that had already
been there.

> But do all reasonable shells support -e ?
> (I must dig in man ksh down to builtin command -set to get confirmation.)

I don't know.

> > For now, let's try the shell script and make it more paranoid.  
> 
> Please report all changes (and be ready to motivate them).

Okay!


pgpLRcM8hsvsa.pgp
Description: OpenPGP digital signature

Re: ISO installer image: GPT versus MBR partitions

[Thomas Schmitt]

Hi,

i wrote:
> >   --file-system-type=iso9660[_$variation]

Danny Milosavljevic wrote:
> I'm not sure yet.  We have a lot of special-casing for iso9660
> already.  If anything, at that point, we could pass an arbitrary list
> of options or something (an "environment" if you will.  Hah).

How ever the options are brought to the grub-mkrescue run and the script,
i strongly urge not to expose all possible combinations of MKRESCUE_SED*
variables to the ISO production process.
Four consistent variations will be enough and avoid riddling failures.


> The problem is that there were horrible security problems in bash and that
> made a lot of distributions switch to a more minimal shell ("dash") for
> scripts.

It is supposed to run on dash, ksh, and BSD sh versions.


> we patch grub-mkrescue to use an absolute path for mformat and mcopy
> in order to make them predictable.

How deep shall this go ? dd, awk, od, head, find, test, mv, rm, ...


> > > For example in grub-mkrescue-sed.sh there's no "-e" in the shebang

> > Is it conservative enough to add it ?

> It will exit the shell when one of the toplevel commands has an
> exit status != 0.

But do all reasonable shells support -e ?
(I must dig in man ksh down to builtin command -set to get confirmation.)


> > That's why i brought a Guile re-write into consideration.
> > Firstly it would be the language of choice and secondly it would make
> > Guix independent of my ideas how it should be done.

> We're not trying to become iso bootloader experts ourselves :)

Currently Guix ISO production is not enough boss over what gets into the
ISO image. Neither with EFI partition properties nor with partition table
type.


> For now, let's try the shell script and make it more paranoid.

Please report all changes (and be ready to motivate them).


Have a nice day :)

Thomas

Re: Alternative VPN Clients

[Leo Famulari]

On Wed, Apr 24, 2019 at 06:01:49AM +0200, Dexter Morgan wrote:
> My friend introduced me to GNU/Linux and installed GuixSD on my laptop. I am
> just getting started on Bash. I find that there is absence of VPN clients as 
> an
> alternative to OpenVPN. Can some one please package the following alternative
> VPN clients:

Just FYI, we have a WireGuard package that works well. You may find it
superior to traditional VPN systems.


signature.asc
Description: PGP signature

Re: User shell: state or config?

[Tobias Geerinckx-Rice]

Ludo', all,

mikadoZero wrote:

Ludovic Courtès writes:


[…]

However, thinking more about it, I’m not sure if considering 
shells as

state is such a good idea, for several reasons:

  1. It’s surprising that ‘guix system reconfigure’ doesn’t 
  actually

 change the shell, as Tanguy reported.


As a new user of Guix System I was recently surprised by this as 
well.

I was expecting the shell to be managed by configuration.


As an old user, I agree ;-)

It's so surprising because we don't set ‘user-overridable 
defaults’ for state anywhere else.  You can't reason about your 
system the way you used to.  The config is a lie.


All in all, I’m in favor of switching back to the previous 
behavior:
considering user shells as system config.  That’s a one-line 
change in

(gnu build accounts).


+1!

Kind regards,

T G-R


signature.asc
Description: PGP signature

Re: ISO installer image: GPT versus MBR partitions

[Danny Milosavljevic]

Hi Thomas,

On Thu, 25 Apr 2019 18:22:11 +0200
"Thomas Schmitt"  wrote:

> Then do if you can make use of those two git commits.
> They are the only ones to that file since release 1.5.0.

Okay, I've picked them up.

> > I'm not sure about amending "guix system disk-image" by options that
> > aren't really end user options, but I guess it can't be helped.  
> 
> How about
> 
>   --file-system-type=iso9660[_$variation]
> 
> with $variation being "gpt_hfs" (= "original"), "mbr_hfs", "mbr_only",
> and "gpt_appended", defaulting to "gpt_hfs" ?

I'm not sure yet.  We have a lot of special-casing for iso9660
already.  If anything, at that point, we could pass an arbitrary list
of options or something (an "environment" if you will.  Hah).

> This translates quite straightforward to the proposed variations of
> grub-mkrescue-sed.sh in
>   http://lists.gnu.org/archive/html/guix-devel/2019-04/msg00420.html
> 
> The partition offset 16 and MBR partition type 0x83 would be ordered
> only with "mbr_*" variations.
> 
> The setting
>   export MKRESCUE_SED_IN_EFI_NO_PT=yes
> should be used unconditionally. It gets applied to the EFI partition
> block 0, only if it is marked with an MBR signature 55 aa. Then we may
> safely assume that bytes 446 to 509 are MBR partition table, which is
> of no use and maybe harmfull. Only then they get zeroed.

Okay, that makes sense.

> If the Guix download servers can afford two more ISOs, how about offering
> "gpt_hfs" and "mbr_hfs" ISOs with the explanation that both should work
> for booting and installing, but that "mbr_hfs" is more convenient when
> the remaining capacity of a Guix ISO USB stick shall be used as partition
> for a read-write filesystem.
> (Moving the backup GPT is an expert option in fdisk. But without moving
>  it there is no room for a new partition.)

I don't know these things.  But someone on the list will know.

> On the long run and if no negative results arise, i propose to switch the
> default to "mbr_hfs".

Yeah, I agree.

> I tried hard to keep it conservative and am open for proposals to
> make it more portable to older shells.

The problem is that there were horrible security problems in bash and that
made a lot of distributions switch to a more minimal shell ("dash") for
scripts.  I agree that that was a good move, but error handling is even
worse there.

> > But then grub-mkrescue will invoke
> > grub-mkrescue-sed.sh at runtime, and who knows what the latter will pick up
> > as the sed to use?  
> 
> grub-mkrescue runs the mformat program and the mcopy program before
> it runs xorriso.

Yeah, we patch grub-mkrescue to use an absolute path for mformat and mcopy
in order to make them predictable.

> > For example in grub-mkrescue-sed.sh there's no "-e" in the shebang  
> 
> Is it conservative enough to add it ?

It will exit the shell when one of the toplevel commands has an
exit status != 0.
So as long as your script doesn't have toplevel commands return error status
in normal operation it should be fine.

Toplevel:

$ grep foo bar

Not toplevel:

$ if grep foo bar

(that won't fail the script even with "-e")

Questionable:

$ foo | bar

If foo fails, should the script fail?  Spoiler: It won't fail the script even 
with "-e".
If bar fails, should the script fail?  Spoiler: It will fail the script with 
"-e".

But:

$ set -e
$ set -o pipefail
$ foo | bar

Now if foo or bar fails, the script will fail.

> > Guile, on the other hand, will just fail the script on error (usually).  
> 
> That's why i brought a Guile re-write into consideration.
> Firstly it would be the language of choice and secondly it would make
> Guix independent of my ideas how it should be done. 

We're not trying to become iso bootloader experts ourselves :)

>As said, the
> script-in-the-middle gives substantial control over the stage of
> grub-mkrescue when the prepared files are still not packed up in the ISO.
> 
> (Or maybe it's time to re-write the script in C ... as was done with
>  grub-mkrescue when it became too complicated.)

Yeah, we'll see.  For now, let's try the shell script and make it more
paranoid.


pgpUwzeob2jEw.pgp
Description: OpenPGP digital signature

Re: New VM image

[Leo Famulari]

On Thu, Apr 25, 2019 at 06:44:07PM +0200, Ludovic Courtès wrote:
> The attached config file can be used to produce a 2.9G QCOW image
> (uncompressed) that internally appears to have a 20G file system:

A little big but I don't think we can shrink it any more unfortunately.

> What do people think?

It looks good to me, thank you!

>   (file-systems (cons (file-system
> (mount-point "/")
> (device "/dev/vda")
> (type "ext4"))
>   %base-file-systems))
> 
>   (users (cons (user-account
> (name "guest")
> (comment "GNU Guix Live")
> (password "") ;no password
> (group "users")
> (supplementary-groups '("wheel" "netdev"
> "audio" "video")))
>%base-user-accounts))

We will probably get some cons / cons* confusion in #guix but that's
okay.


signature.asc
Description: PGP signature

New VM image

[Ludovic Courtès]

Hello Guix!

The attached config file can be used to produce a 2.9G QCOW image
(uncompressed) that internally appears to have a 20G file system:

  guix system vm-image --image-size=20G vm-live.tmpl

The image logs into Xfce and from there people can spawn a terminal, run
‘guix package -i icecat’, etc.

I think it would fill the need of those who want to see what Guix is
like, and also the need of developers who want to test their software on
Guix without installing it (I’d argue that installing Guix on top of
their distro is simpler, but some people will use the VM image for that
purpose anyway.)

What do people think?

If that’s fine with you I can commit it and update the doc & makefiles.

Thanks,
Ludo’.

;; This is an operating system configuration for a VM image.
;; Modify it as you see fit and instantiate the changes by running:
;;
;;   guix system reconfigure /etc/config.scm
;;

(use-modules (gnu) (srfi srfi-1))
(use-service-modules xorg desktop)
(use-package-modules bootloaders nvi wget xorg)

(define vm-image-motd (plain-file "motd" "
\x1b[1;37mThis is the GNU system.  Welcome!\x1b[0m

This instance of Guix is a template for virtualized environments.
You can reconfigure the whole system by adjusting /etc/config.scm
and running:

  guix system reconfigure /etc/config.scm

\x1b[1;33mConsider setting a password for the 'root' and 'guest' \
accounts.\x1b[0m
"))

(define this-file
  (local-file "./vm-live.tmpl" "config.scm"))


(operating-system
  (host-name "gnu")
  (timezone "Etc/UTC")
  (locale "en_US.utf8")
  (keyboard-layout (keyboard-layout "us" "altgr-intl"))

  (bootloader (bootloader-configuration
   (bootloader grub-bootloader)
   (target "/dev/sda")
   (terminal-outputs '(console
  (file-systems (cons (file-system
(mount-point "/")
(device "/dev/vda")
(type "ext4"))
  %base-file-systems))

  (users (cons (user-account
(name "guest")
(comment "GNU Guix Live")
(password "") ;no password
(group "users")
(supplementary-groups '("wheel" "netdev"
"audio" "video")))
   %base-user-accounts))

  (packages (cons* nvi wget %base-packages))

  (services (cons* (service xfce-desktop-service-type)

   ;; Copy this file to /etc/config.scm in the OS.
   (simple-service 'config-file etc-service-type
   `(("config.scm" ,this-file)))

   ;; Choose SLiM, which is lighter than the default GDM.
   (service slim-service-type
(slim-configuration
 (auto-login? #t)
 (default-user "guest")
 (xorg-configuration
  (xorg-configuration
   (keyboard-layout keyboard-layout)

   (remove (lambda (service)
 (eq? gdm-service-type (service-kind service)))
   (modify-services %desktop-services
 (login-service-type config =>
 (login-configuration
  (inherit config)
  (motd vm-image-motd)))

  ;; Allow resolution of '.local' host names with mDNS.
  (name-service-switch %mdns-host-lookup-nss))

Re: ISO installer image: GPT versus MBR partitions

[Thomas Schmitt]

Hi,

i worte:
> > (My other sport besides ISO 9660 is burning flat round things.)

Florian Pelz wrote:
> :D Burning is not the problem. ;)

We could let xorriso put some read load on it and watch out for error
messages.


> With the USB flash drive booting was not stuck, it just did not appear
> in the boot device selection.

Then it is undecided yet. Either it dislikes the EFI partition's content
or it avoided the endless loop by discarding the iwhole partition.


Have a nice day :)

Thomas

Re: ISO installer image: GPT versus MBR partitions

[Ludovic Courtès]

Hello,

"pelzflorian (Florian Pelz)"  skribis:

> So what’s the plan?
>
> Wait for another responce from the grub-devel mailing list?
>
> Package grub-mkrescue-sed.sh and use
> --xorriso=/path/to/grub-mkrescue-sed.sh when calling grub-mkrescue?
>
> Add an option to “guix system disk-image” to select which
> grub-mkrescue-sed.sh environment variables to enable?

I lost track of the discussion.  You’re looking at a MacBook-specific
issue, right?

(The underlying question being: can this wait after 1.0 is out?  :-)
If it’s MacBook-specific, I would answer “yes.”)

Ludo’.

Re: ISO installer image: GPT versus MBR partitions

[Thomas Schmitt]

Hi,

Danny Milosavljevic wrote:
> you *are* upstream so
> it's really up to you whether we should patch xorriso or not.

Then do if you can make use of those two git commits.
They are the only ones to that file since release 1.5.0.


> I'm not sure about amending "guix system disk-image" by options that
> aren't really end user options, but I guess it can't be helped.

How about

  --file-system-type=iso9660[_$variation]

with $variation being "gpt_hfs" (= "original"), "mbr_hfs", "mbr_only",
and "gpt_appended", defaulting to "gpt_hfs" ?

This translates quite straightforward to the proposed variations of
grub-mkrescue-sed.sh in
  http://lists.gnu.org/archive/html/guix-devel/2019-04/msg00420.html

The partition offset 16 and MBR partition type 0x83 would be ordered
only with "mbr_*" variations.

The setting
  export MKRESCUE_SED_IN_EFI_NO_PT=yes
should be used unconditionally. It gets applied to the EFI partition
block 0, only if it is marked with an MBR signature 55 aa. Then we may
safely assume that bytes 446 to 509 are MBR partition table, which is
of no use and maybe harmfull. Only then they get zeroed.

The experimental setting
  export MKRESCUE_SED_IN_EFI_NO_PT=extra
is not yet sufficiently motivatable for production ISOs. It exists for
getting an impression whether mformat option -k would be safe in
grub-mkrescue. (I.e. it is research for general GRUB enlightenment.)


> Basically they would just be something that we'd tell users which
> have problems booting the Guix iso to use.

If the Guix download servers can afford two more ISOs, how about offering
"gpt_hfs" and "mbr_hfs" ISOs with the explanation that both should work
for booting and installing, but that "mbr_hfs" is more convenient when
the remaining capacity of a Guix ISO USB stick shall be used as partition
for a read-write filesystem.
(Moving the backup GPT is an expert option in fdisk. But without moving
 it there is no room for a new partition.)

On the long run and if no negative results arise, i propose to switch the
default to "mbr_hfs".


> But if no care is taken, shell scripts take stuff from the global
> environment and thus are very difficult to predict and isolate for
> modularity.

I tried hard to keep it conservative and am open for proposals to
make it more portable to older shells.


> But then grub-mkrescue will invoke
> grub-mkrescue-sed.sh at runtime, and who knows what the latter will pick up
> as the sed to use?

grub-mkrescue runs the mformat program and the mcopy program before
it runs xorriso.


> (For that matter, think of what happens when another xorriso is somewhere
> in $PATH and we use --xorriso=.../grub-mkrescue-sed.sh).

Should not matter much, as long as this xorriso is young enough.
grub-mkrescue will ask by running effectively
  ./grub-mkrescue-sed.sh -as mkisofs -help 2>&1
and inspecting the options list of the real xorriso involved.

The only difference will be two message lines (one empty)
  frontend/grub-mkrescue-sed.sh manipulating xorriso arguments

but then it will say
  xorriso 1.5.0 : RockRidge filesystem manipulator, libburnia project.

  Usage: xorriso -as mkisofs [options] file...
  ...

If you can tell the absolute path to a good xorriso, then set

  export MKRESCUE_SED_XORRISO=...path.to.real.xorriso.binary...


> For example in grub-mkrescue-sed.sh there's no "-e" in the shebang

Is it conservative enough to add it ?


> Guile, on the other hand, will just fail the script on error (usually).

That's why i brought a Guile re-write into consideration.
Firstly it would be the language of choice and secondly it would make
Guix independent of my ideas how it should be done. As said, the
script-in-the-middle gives substantial control over the stage of
grub-mkrescue when the prepared files are still not packed up in the ISO.

(Or maybe it's time to re-write the script in C ... as was done with
 grub-mkrescue when it became too complicated.)


Have a nice day :)

Thomas

Re: ISO installer image: GPT versus MBR partitions

[pelzflorian (Florian Pelz)]

On Thu, Apr 25, 2019 at 05:09:05PM +0200, Thomas Schmitt wrote:
> Hi,
> 
> Florian Pelz wrote:
> > I do not know and did not try yet how to configure GRUB to produce
> > both 32-bit and 64-bit EFI.
> […]
> Some digging in the source of grub-mkrescue and util/grub-install-common.c
> reveils that it is about the existence of $cpu-$firmware directories
> with lots of .mod files in them:
> 

This is interesting, but I am not familiar enough to try to quickly
change the guix package and I am not going to invest time in that.
The reason I was interested is that the CPU supposedly can run 64-bit
code, it is apparently just the UEFI that refuses 64-bit.  But one can
install 32-bit and then reconfigure Guix later on to use 64-bit, so it
is not important.



> > a DVD with an untreated Guix
> > git master could not be booted but very likely due to an error with my
> > external DVD drive (it often does not work)
> 
> We could start a separate endeavor in private for diagnosing that.
> (My other sport besides ISO 9660 is burning flat round things.)
> 
>

:D Burning is not the problem. ;)  This slim laptop has no DVD drive
itself and my external USB DVD drive works only sometimes and might
have required even more patience.  Booting got stuck waiting for the
DVD drive which continued to make noises, as it often does on other
machines when it has a bad day.  This was not a problem with the DVD
or the image, but with that DVD drive of mine.

I will test Danny’s patches on my Macbook and on the Ideapad.


> > I will try a current git master Guix iso built for 32-bit next.  If it
> > does not work (guixsd-install-0.15.0.i686-linux.iso did not work), I
> > will try the same with
> > dd if=/dev/zero bs=1 count=16 seek=446 of=/dev/sdc2
> 
> Was the machine similarly stuck as the Macbook ?
> That would probably be the partition problem, indeed.
> 

With the USB flash drive booting was not stuck, it just did not appear
in the boot device selection.

Regards,
Florian

Re: ‘staging’ and GNOME updates

[Giovanni Biscuolo]

Hello Timothy and Ricardo,

Timothy Sample  writes:

[...]

> Or, maybe I could pull Epiphany out of our GNOME package, and avoid
> WebKitGTK (now that GNOME Shell doesn’t need it).

this will not fix any problem but please do it anyway before merging to
master :-)

thanks for working on this!

[...]

-- 
Giovanni Biscuolo

Xelera IT Infrastructures


signature.asc
Description: PGP signature

Re: ISO installer image: GPT versus MBR partitions

[Thomas Schmitt]

Hi,

Florian Pelz wrote:
> I do not know and did not try yet how to configure GRUB to produce
> both 32-bit and 64-bit EFI.

As Debian user i am in the comfortable position to install the
three binary packages for BIOS, x86 EFI 32 bit, and x86 EFI 64 bit.
Then grub-mkrescue knows what to do.

Some digging in the source of grub-mkrescue and util/grub-install-common.c
reveils that it is about the existence of $cpu-$firmware directories
with lots of .mod files in them:

  $ ls /usr/lib/grub
  grub-mkconfig_lib  i386-efi  i386-pc  x86_64-efi

The binary Debian packages nearly entirely consist of one of these
directories, each:
  https://packages.debian.org/sid/amd64/grub-efi-amd64-bin/filelist
  https://packages.debian.org/sid/amd64/grub-efi-ia32-bin/filelist
  https://packages.debian.org/sid/amd64/grub-pc-bin/filelist

But i don't know the tool which is to be used for creating those
directories and for filling them with .mod files.

Maybe you find some GRUB tool usage in the Guix ISO production which
uses parameters like "x86_64" "efi".
Or the name "grub-mkconfig_lib" gives a hint ? man grub-mkconfig and
info chapter are quite sparse.


> (Would putting both 32-bit and 64-bit
> bootefi files in EFI/Boot/ be a good idea for Guix ISOs in general, or
> could this lead to problems with 64-bit machines or lead to confusing
> boot selection screens?)

It should be perfectly ok to combine several EFI start programs in
one EFI partition. The firmware is supposed to pick what it deems
suitable.
UEFI 2.4 3.4.1.1 "Removable Media Boot Behavior":

  "[...] the system firmware will attempt to boot from a removable media
   FilePathList[0] by adding a default file name in the form
 \EFI\BOOT\BOOT{machine type short-name}.EFI.
   Each file only contains one UEFI image type, and a system may
   support booting from one or more images types."

You could even combine "IA32", "X64", "ARM", and "AA64" programs if you
manage to keep all CPU specific files apart in the course of the further
operating system run.


> The Lenovo Ideapad 100S’s owner tried a USB drive prepared with a
> purely 32-bit GRUB [...]
>   export MKRESCUE_SED_MODE=mbr_hfs
>   export MKRESCUE_SED_IN_EFI_NO_PT=yes
>   grub-mkrescue --xorriso=./grub-mkrescue-sed.sh  \
> -iso_mbr_part_type 0x83 -partition_offset 16 \

> and it boots fine.

So that's not the mad EFI which hates all MBR partitions except one 0xef.


> a DVD with an untreated Guix
> git master could not be booted but very likely due to an error with my
> external DVD drive (it often does not work)

We could start a separate endeavor in private for diagnosing that.
(My other sport besides ISO 9660 is burning flat round things.)


> I will try a current git master Guix iso built for 32-bit next.  If it
> does not work (guixsd-install-0.15.0.i686-linux.iso did not work), I
> will try the same with
> dd if=/dev/zero bs=1 count=16 seek=446 of=/dev/sdc2

Was the machine similarly stuck as the Macbook ?
That would probably be the partition problem, indeed.

But failure when GRUB or a Linux kernel have taken over would be a
different problem. The minimal grub-mkrescue ISO would then possibly
work because it prompts the user before the problem can occur.
Or maybe because it has a .mod file that is needed for that machine ?


Have a nice day :)

Thomas

Re: ISO installer image: GPT versus MBR partitions

[Danny Milosavljevic]

> How comfortable is the Guix patching system ? :))

Very comfortable.  But we'd like not to diverge from upstream too much.
We are all in this together, so I'd like upstream to eventually converge on
a solution.  I'm fine with carrying a patch if it's coordinated by people with
knowledge about the matter at hand.  For multiple projects, we already carry
patches while they are being actively reviewed upstream in order to fix bugs.

If the problem is not too bad, I'd like the change to take the normal path
instead of us interfering with upstream.  But here, you *are* upstream so
it's really up to you whether we should patch xorriso or not.

As for people testing possible avenues by patches in Guix, that's easy to do.

> This is quite contrary to the expectations of partition editors, though.
> I deem this EFI's behavior a much clearer bug than the Macbook EFI's.
> So i stay with my proposal of native xorriso command
>   -boot_image any iso_mbr_part_type=0x83
> or mkisofs emulation option
>   -iso_mbr_part_type 0x83
> 
> (To my knowledge, the Guix xorriso run switches from mkisofs emulation
>  to native commands by "--". So -boot_image would be the one to use
>  if it gets appended to the other arguments.)
> 
> 
> > Add an option to “guix system disk-image” to select which
> > grub-mkrescue-sed.sh environment variables to enable?  
> 
> This would be great.

Since grub-mkrescue-sed.sh is part of xorriso, it's easy to get it
to where it needs to be (gnu/build/vm.scm) from where xorriso is
refererred to (gnu/system/vm.scm).  (Just pass the package as argument)
I can do that part.

The patches would then go into the xorriso package definition we carry
(gnu/packages/cdrom.scm) and modify grub-mkrescue-sed.sh in its output
(the patching part would require no Guile knowledge, they are just
".patch" files we distribute and automatically apply).

I'm not sure about amending "guix system disk-image" by options that
aren't really end user options, but I guess it can't be helped.

Basically they would just be something that we'd tell users which
have problems booting the Guix iso to use.  Even that is a lot to ask
from normal users--building a new installer ISO for the sake of
installing Guix.

> (I was brought up with HP BASIC and never was able to solve the Lisp
>  puzzles in german magazine Bild der Wissenschaft of the 1980s.
>  So i cannot help much with translating the usage gestures or even
>  the script itself from shell to Guile.)

Oh, I see.  It's fine if it's in a shell script.

We aren't opposed to shell scripts--sometimes (in initrd etc) we already have
Guile there and don't want to bloat the image by shells and shell utils.

But in this case, we would be patching the iso generator which requires
a lot of the system anyway, so who cares if we pull in the shell and 20
small utils?

Also, we try very hard to keep packages modular.

But if no care is taken, shell scripts take stuff from the global environment
and thus are very difficult to predict and isolate for modularity.

Think of what happens when someone replaces the "test" binary
in $PATH, or "sed".  It will unintentionally potentially completely
change the output depending on what the user has installed (it's definitely
not what the user intended to happen).

As a first countermeasure, we build inside isolated build containers, which
makes the problem less bad.  But then grub-mkrescue will invoke
grub-mkrescue-sed.sh at runtime, and who knows what the latter will pick up
as the sed to use?

(For that matter, think of what happens when another xorriso is somewhere
in $PATH and we use --xorriso=.../grub-mkrescue-sed.sh).  (I see that
you already take care to use a "closer" xorriso--but these kind of problems
pop up in shell scripts for almost every term used in there.  It's kinda
difficult to get them to behave)

What's more, shell scripts don't fail on error.  For example in
grub-mkrescue-sed.sh there's no "-e" in the shebang, which means that if
some command in there has an error, the shell will happily continue anyway.
I'm not blaming you, that's just the culture with shell scripts.

Even with "-e", if a command in a pipeline fails, it will sometimes still
not fail the shell script.  For that, you need "set -o pipefail" which is
a bash feature and not necessarily available on other shells (dash etc).

Guile, on the other hand, will just fail the script on error (usually).


pgpscZhD2VKpF.pgp
Description: OpenPGP digital signature

Re: ISO installer image: GPT versus MBR partitions

[Thomas Schmitt]

Hi,

Florian Pelz wrote:
> So what’s the plan?
> Wait for another responce from the grub-devel mailing list?

They need time to to make up their mind. Maybe other incidents are needed to
push towards some change in grub-mkrescue.
We have a halfways positive response from the old owner and a somewhat
uninformed response from the new manager, indicating between the lines
that he is too busy with other things currently.


> Package grub-mkrescue-sed.sh and use
> --xorriso=/path/to/grub-mkrescue-sed.sh when calling grub-mkrescue?

It is part of the libisoburn release tarball, from where Guix gets its
xorriso, afaik. It is also part of the GNU xorriso tarball, which builds
a static compilation of libburn, libisofs, libisoburn, and libjte.

Problem is that for the EFI partition fix, you need the current development
version. The partition definitions should be ok with the released version
1.5.0.
I plan a new release this year, but not right now.

How comfortable is the Guix patching system ? :))

  "New control variable for grub-mkrescue-sed.sh: MKRESCUE_SED_IN_EFI_NO_PT"
  
https://dev.lovelyhq.com/libburnia/libisoburn/commit/3a2a3ba737a06162c22ace0ae09d33ba97aa2673

  "grub-mkrescue-sed.sh: MKRESCUE_SED_IN_EFI_NO_PT="extra"
   to erase MBR signature"
  
https://dev.lovelyhq.com/libburnia/libisoburn/commit/1eb51f44dadb8b6c5f87533ca357186cdc1ac625

(The holidays are over. Our certificate works again.)


Looking at a commit from 2 years ago (i.e. in released version)
  "Made -iso_mbr_part_type 0x00 default of grub-mkrescue-sed.sh
   mode "mbr_only""
i remember that there was an EFI reported on grub-devel which strictly
refused on anything but a single MBR partition for EFI. So the camouflage
trick of partition type 0x0 was necessary for the ISO partition.

This is quite contrary to the expectations of partition editors, though.
I deem this EFI's behavior a much clearer bug than the Macbook EFI's.
So i stay with my proposal of native xorriso command
  -boot_image any iso_mbr_part_type=0x83
or mkisofs emulation option
  -iso_mbr_part_type 0x83

(To my knowledge, the Guix xorriso run switches from mkisofs emulation
 to native commands by "--". So -boot_image would be the one to use
 if it gets appended to the other arguments.)


> Add an option to “guix system disk-image” to select which
> grub-mkrescue-sed.sh environment variables to enable?

This would be great.
(I was brought up with HP BASIC and never was able to solve the Lisp
 puzzles in german magazine Bild der Wissenschaft of the 1980s.
 So i cannot help much with translating the usage gestures or even
 the script itself from shell to Guile.)


Have a nice day :)

Thomas

Re: ‘staging’ and GNOME updates

[Ricardo Wurmus]

Timothy Sample  writes:

> Ricardo Wurmus  writes:
>
>>> After running GNOME 3.28 for a while, I’ve had several crashes.  It used
>>> to crash whenever I opened a URL from Emacs, but fiddling with dconf has
>>> fixed that.  It currently crashes every time I run ERC (I’ve turned on
>>> notifications there), and I can’t seem to fix it.
>>>
>>> Interestingly, there is a discussion about this on the Arch Linux forums
>>> .  I’m not sure if
>>> there’s anything useful for us in there, though.
>>
>> This message seems relevant:
>>
>> https://bbs.archlinux.org/viewtopic.php?pid=1778640#p1778640
>>
>> My issue was caused by using ubuntu-cairo. It was incompatible with
>> librsvg 2.42.3, which caused a crash when gnome attempted to load an
>> SVG when trying to display the notification. It also caused the
>> close window button to not appear in the overview.
>
> I did see this, but I couldn’t really connect it to the problem at hand.
> It is interesting that the close window buttons in the overview are a
> problem for us, too .
>
>>> It looks like GNOME Shell passes some bad icon data into GTK+, which
>>> results in a null filename that gets dereferenced.  (GNOME Shell is not
>>> in the backtrace – it tells GTK+ to run this thread from the
>>> “load_texture_async” function in “st-texture-cache.c”.
>>>
>>> I think the “bad” user files are not the root cause here.  There’s
>>> definitely something wrong with notifications.  (I just plugged in a USB
>>> drive and, sure enough, GNOME Shell crashed.)  The notification daemon
>>> code is written in JavaScript (“js/ui/notificationDaemon.js”).  I
>>> glanced at it and its Git history, but couldn’t find anything.
>>
>> I don’t think it’s notifications per se, but rendering SVGs.  When
>> application_state exists, GNOME shell tries to restore application
>> windows and their icons are likely SVG files that should be rendered.
>>
>> Chris reported elsewhere that GNOME sometimes crashes when the Activity
>> tab is accessed — that’s where the application starter is, which
>> displays icons.
>>
>> I believe we should be using librsvg-next in the closure of gnome-shell.
>> We may also want to use gdk-pixbuf+svg instead of just gdk-pixbuf, but
>> again replacing librsvg with librsvg-next throughout.  I’m guessing that
>> the problem is entirely due to using an outdated variant of librsvg.
>>
>> What do you think?
>
> To be honest, I don’t know.  From my side, I haven’t seen anything that
> suggests SVGs might be the problem.  I just checked an application that
> no longer has an icon since the update, and it doesn’t provide an SVG.
> On the other hand, Emacs, which does provide an SVG, is fine.  I can’t
> find anything in the backtrace that suggests SVG problems either.
>
> That said, software is complicated and this is best lead we have.  Maybe
> the crash I’m seeing is fallback code that gets called when SVGs aren’t
> quite working.  I did try patching GTK+ the other day (for testing
> something else), but gave up when I realized that it means recompiling
> WebKitGTK, which takes forever.  I’ll try and patch everything later and
> leave my computer to compile overnight.  Or, maybe I could pull Epiphany
> out of our GNOME package, and avoid WebKitGTK (now that GNOME Shell
> doesn’t need it).  Either way, I will try and test this.  If nothing
> else, it might fix the bug linked above.

I built the VM with this diff:

--8<---cut here---start->8---
diff --git a/gnu/packages/gnome.scm b/gnu/packages/gnome.scm
index 5583af576b..98e2a75777 100644
--- a/gnu/packages/gnome.scm
+++ b/gnu/packages/gnome.scm
@@ -2189,7 +2189,7 @@ engineering.")
 (inputs
  `(("gtk+" ,gtk+)
("gtk+-2" ,gtk+-2)
-   ("librsvg" ,librsvg)
+   ("librsvg" ,librsvg-next)
("libxml2" ,libxml2)
("glib" ,glib)))
 (native-inputs
@@ -3278,7 +3278,7 @@ services for numerous locations.")
("cups" ,cups)
("gsettings-desktop-schemas" ,gsettings-desktop-schemas)
("libwacom" ,libwacom)
-   ("librsvg" ,librsvg)
+   ("librsvg" ,librsvg-next)
("xf86-input-wacom" ,xf86-input-wacom)
("wayland" ,wayland)
("network-manager" ,network-manager)))
@@ -3864,7 +3864,7 @@ for application developers.")
("libxml2" ,libxml2)
("libsoup" ,libsoup)
("libpeas" ,libpeas)
-   ("librsvg" ,librsvg)
+   ("librsvg" ,librsvg-next)
("lirc" ,lirc)
("gnome-desktop" ,gnome-desktop)
("gstreamer" ,gstreamer)
@@ -4072,7 +4072,7 @@ supports playlists, song ratings, and any codecs 
installed through gstreamer.")
   ("libexif" ,libexif)
   ("libpeas" ,libpeas)
   ("libjpeg" ,libjpeg)
-  ("librsvg" ,librsvg)
+  ("librsvg" ,librsvg-next)
   ("gsettings-desktop-schemas" ,gsettings-desktop-schemas)
   ("gtk+" ,gtk+)))
(home-page 

Re: User shell: state or config?

[mikadoZero]

Ludovic Courtès writes:

> Hello Guix!
>
> We recently discussed handling of the ‘shell’ field of ‘user-account’:
>
>   https://lists.gnu.org/archive/html/help-guix/2019-04/msg00171.html
>
> As I wrote there, starting with the switch to (gnu build accounts) in
> 0ae735bcc8ff7fdc89d67b492bdee9091ee19e86, user shells are considered
> “state”.  Before they were “config”: ‘guix system reconfigure’ would
> always reset the user shells.
>
> Considering user shells as state seemed like a good idea because, on a
> multi-user system, you’d rather let user invoke ‘chsh’ than have root
> reconfigure the system just to change the user’s shell.  The patches
> below document that.
>
> However, thinking more about it, I’m not sure if considering shells as
> state is such a good idea, for several reasons:
>
>   1. It’s surprising that ‘guix system reconfigure’ doesn’t actually
>  change the shell, as Tanguy reported.

As a new user of Guix System I was recently surprised by this as well.
I was expecting the shell to be managed by configuration.

https://lists.gnu.org/archive/html/help-guix/2019-03/msg00089.html

>   2. ‘chsh’ restricts users to the shells listed in /etc/shells anyway,
>  which is the combination of all the ‘shell’ fields, currently.
>
>  Given this restriction, you might just as well ask the admin to
>  change the shell for you.
>
>   3. It’s easy to end up with a shell that’s eventually GC’d.
>
>  Scenario #1: your shell is initially set to
>  /gnu/store/…-bash/bin/bash, which at the time is GC-protected
>  (listed in /etc/shells, etc.).  However, later, this specific Bash
>  variant is GC’d, and boom, you’re left with nothing.
>
>  Scenario #2: you set your shell to
>  /run/current-system/profile/bin/zsh, which is GC-protected, but
>  eventually the admin removes zsh for the global profile.
>
> All in all, I’m in favor of switching back to the previous behavior:
> considering user shells as system config.  That’s a one-line change in
> (gnu build accounts).
>
> Thoughts?
>
> Ludo’.
>
> From d1586f0c77cf63d0259cca9fc50c210c584529b3 Mon Sep 17 00:00:00 2001
> From: =?UTF-8?q?Ludovic=20Court=C3=A8s?= 
> Date: Thu, 25 Apr 2019 12:10:06 +0200
> Subject: [PATCH 1/2] system: Add 'chsh' to %SETUID-PROGRAMS.
>
> * gnu/system/pam.scm (base-pam-services): Add "chsh".
> * gnu/system.scm (%setuid-programs): Add chsh.
> ---
>  gnu/system.scm | 1 +
>  gnu/system/pam.scm | 4 ++--
>  2 files changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/gnu/system.scm b/gnu/system.scm
> index b00d384fee..a85ec109ac 100644
> --- a/gnu/system.scm
> +++ b/gnu/system.scm
> @@ -794,6 +794,7 @@ use 'plain-file' instead~%")
>;; Default set of setuid-root programs.
>(let ((shadow (@ (gnu packages admin) shadow)))
>  (list (file-append shadow "/bin/passwd")
> +  (file-append shadow "/bin/chsh")
>(file-append shadow "/bin/su")
>(file-append shadow "/bin/newuidmap")
>(file-append shadow "/bin/newgidmap")
> diff --git a/gnu/system/pam.scm b/gnu/system/pam.scm
> index 13f76a50ed..27239c5621 100644
> --- a/gnu/system/pam.scm
> +++ b/gnu/system/pam.scm
> @@ -1,5 +1,5 @@
>  ;;; GNU Guix --- Functional package management for GNU
> -;;; Copyright © 2013, 2014, 2015, 2016, 2017 Ludovic Courtès 
> +;;; Copyright © 2013, 2014, 2015, 2016, 2017, 2019 Ludovic Courtès 
> 
>  ;;;
>  ;;; This file is part of GNU Guix.
>  ;;;
> @@ -265,7 +265,7 @@ authenticate to run COMMAND."
>;; These programs are setuid-root.
>(map (cut unix-pam-service <>
>  #:allow-empty-passwords? allow-empty-passwords?)
> -   '("passwd" "sudo"))
> +   '("passwd" "chsh" "sudo"))
>;; This is setuid-root, as well.  Allow root to run "su" without
>;; authenticating.
>(list (unix-pam-service "su"
> -- 
> 2.21.0
>
> From 6ab1ecd628f13829e31e4bcbe7bf0ff53951eedd Mon Sep 17 00:00:00 2001
> From: =?UTF-8?q?Ludovic=20Court=C3=A8s?= 
> Date: Thu, 25 Apr 2019 12:23:11 +0200
> Subject: [PATCH 2/2] doc: Document 'chsh'.
>
> * doc/guix.texi (User Accounts): Document 'chsh'.
> ---
>  doc/guix.texi | 9 +
>  1 file changed, 9 insertions(+)
>
> diff --git a/doc/guix.texi b/doc/guix.texi
> index 879cb562e9..b5048f7269 100644
> --- a/doc/guix.texi
> +++ b/doc/guix.texi
> @@ -11000,6 +11000,15 @@ if it does not exist yet.
>  This is a G-expression denoting the file name of a program to be used as
>  the shell (@pxref{G-Expressions}).
>  
> +Users may change their shell at any time by running the @command{chsh}
> +command---run @command{man chsh} for more info.  The list of allowed shells
> +can be found in the @file{/etc/shells} file, which is itself the combination
> +of the @code{shell} fields of all the user accounts.
> +
> +Because the account's shell is user-modifiable system state---just like
> +passwords---it is preserved across reboots and reconfiguration, even if the
> 

Re: bug#35417: Tor Service

[ng0]

Julien Lepiller transcribed 565 bytes:
> Le 24 avril 2019 18:34:22 GMT+02:00, Raghav Gururajan  a 
> écrit :
> >Hello Guix!
> >
> >Including "tor-service-type" does not invoke and add "tor" package into
> >the system. Without "tor" package, tor commands cannot be used.
> >Therefore, "tor-service-type" is of little or no use, if it does not
> >invoke and add "tor" package into the system.
> >
> >Regards,
> >RG.
> 
> Hi,
> 
> What kind of command do you want to run? The tor service runs tor and you can 
> configure, eg. your browser to use it through a socks proxy. So it is of some 
> use :)

My guess is that this is about torsocks.

Re: ISO installer image: GPT versus MBR partitions

[pelzflorian (Florian Pelz)]

On Wed, Apr 24, 2019 at 11:13:23AM +0200, pelzflorian (Florian Pelz) wrote:
> On Wed, Apr 24, 2019 at 08:56:57AM +0200, Thomas Schmitt wrote:
> > Florian Pelz wrote
> > > By the way, someone I know has a most peculiar machine called Lenovo
> > > Ideapad 100S which does not boot Guix, […]
> > 
> > If Guix does not show up in the boot manager, try a plain grub-mkrescue
> > image that was made when GRUB was configured for both EFI variations:
> > 32 bit x86 and 64 x86.
> > My experiments are made when it is configured for those two plus PC-BIOS.
> > The EFI partition then has bootx64.efi and bootia32.efi in /efi/boot/.
> > 
> 
> Will do.
> 

The Lenovo Ideapad 100S’s owner tried a USB drive prepared with a
purely 32-bit GRUB as per

On Thu, Apr 25, 2019 at 10:18:08AM +0200, Thomas Schmitt wrote:
>   wget 
> https://dev.lovelyhq.com/libburnia/libisoburn/raw/master/frontend/grub-mkrescue-sed.sh
>   chmod u+x grub-mkrescue-sed.sh
> 
>   export MKRESCUE_SED_MODE=mbr_hfs
>   export MKRESCUE_SED_IN_EFI_NO_PT=yes
> 
>   grub-mkrescue --xorriso=./grub-mkrescue-sed.sh  \
> -iso_mbr_part_type 0x83 -partition_offset 16 \

-o mbrhfs.iso

and it boots fine.

I do not know and did not try yet how to configure GRUB to produce
both 32-bit and 64-bit EFI.  (Would putting both 32-bit and 64-bit
bootefi files in EFI/Boot/ be a good idea for Guix ISOs in general, or
could this lead to problems with 64-bit machines or lead to confusing
boot selection screens?)

A Debian 9.8.0 32-bit also boots fine and a DVD with an untreated Guix
git master could not be booted but very likely due to an error with my
external DVD drive (it often does not work) and not due to an error
with the DVD.

I will try a current git master Guix iso built for 32-bit next.  If it
does not work (guixsd-install-0.15.0.i686-linux.iso did not work), I
will try the same with

dd if=/dev/zero bs=1 count=16 seek=446 of=/dev/sdc2

Regards,
Florian

New Spanish PO file for 'guix' (version 1.0.0-pre2)

[Translation Project Robot]

Hello, gentle maintainer.

This is a message from the Translation Project robot.

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

https://translationproject.org/latest/guix/es.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/guix/

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/guix.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 Spanish PO file for 'guix' (version 1.0.0-pre2)

[Translation Project Robot]

Hello, gentle maintainer.

This is a message from the Translation Project robot.

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

https://translationproject.org/latest/guix/es.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/guix/

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/guix.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.

User shell: state or config?

[Ludovic Courtès]

Hello Guix!

We recently discussed handling of the ‘shell’ field of ‘user-account’:

  https://lists.gnu.org/archive/html/help-guix/2019-04/msg00171.html

As I wrote there, starting with the switch to (gnu build accounts) in
0ae735bcc8ff7fdc89d67b492bdee9091ee19e86, user shells are considered
“state”.  Before they were “config”: ‘guix system reconfigure’ would
always reset the user shells.

Considering user shells as state seemed like a good idea because, on a
multi-user system, you’d rather let user invoke ‘chsh’ than have root
reconfigure the system just to change the user’s shell.  The patches
below document that.

However, thinking more about it, I’m not sure if considering shells as
state is such a good idea, for several reasons:

  1. It’s surprising that ‘guix system reconfigure’ doesn’t actually
 change the shell, as Tanguy reported.

  2. ‘chsh’ restricts users to the shells listed in /etc/shells anyway,
 which is the combination of all the ‘shell’ fields, currently.

 Given this restriction, you might just as well ask the admin to
 change the shell for you.

  3. It’s easy to end up with a shell that’s eventually GC’d.

 Scenario #1: your shell is initially set to
 /gnu/store/…-bash/bin/bash, which at the time is GC-protected
 (listed in /etc/shells, etc.).  However, later, this specific Bash
 variant is GC’d, and boom, you’re left with nothing.

 Scenario #2: you set your shell to
 /run/current-system/profile/bin/zsh, which is GC-protected, but
 eventually the admin removes zsh for the global profile.

All in all, I’m in favor of switching back to the previous behavior:
considering user shells as system config.  That’s a one-line change in
(gnu build accounts).

Thoughts?

Ludo’.

>From d1586f0c77cf63d0259cca9fc50c210c584529b3 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Ludovic=20Court=C3=A8s?= 
Date: Thu, 25 Apr 2019 12:10:06 +0200
Subject: [PATCH 1/2] system: Add 'chsh' to %SETUID-PROGRAMS.

* gnu/system/pam.scm (base-pam-services): Add "chsh".
* gnu/system.scm (%setuid-programs): Add chsh.
---
 gnu/system.scm | 1 +
 gnu/system/pam.scm | 4 ++--
 2 files changed, 3 insertions(+), 2 deletions(-)

diff --git a/gnu/system.scm b/gnu/system.scm
index b00d384fee..a85ec109ac 100644
--- a/gnu/system.scm
+++ b/gnu/system.scm
@@ -794,6 +794,7 @@ use 'plain-file' instead~%")
   ;; Default set of setuid-root programs.
   (let ((shadow (@ (gnu packages admin) shadow)))
 (list (file-append shadow "/bin/passwd")
+  (file-append shadow "/bin/chsh")
   (file-append shadow "/bin/su")
   (file-append shadow "/bin/newuidmap")
   (file-append shadow "/bin/newgidmap")
diff --git a/gnu/system/pam.scm b/gnu/system/pam.scm
index 13f76a50ed..27239c5621 100644
--- a/gnu/system/pam.scm
+++ b/gnu/system/pam.scm
@@ -1,5 +1,5 @@
 ;;; GNU Guix --- Functional package management for GNU
-;;; Copyright © 2013, 2014, 2015, 2016, 2017 Ludovic Courtès 
+;;; Copyright © 2013, 2014, 2015, 2016, 2017, 2019 Ludovic Courtès 
 ;;;
 ;;; This file is part of GNU Guix.
 ;;;
@@ -265,7 +265,7 @@ authenticate to run COMMAND."
   ;; These programs are setuid-root.
   (map (cut unix-pam-service <>
 #:allow-empty-passwords? allow-empty-passwords?)
-   '("passwd" "sudo"))
+   '("passwd" "chsh" "sudo"))
   ;; This is setuid-root, as well.  Allow root to run "su" without
   ;; authenticating.
   (list (unix-pam-service "su"
-- 
2.21.0

>From 6ab1ecd628f13829e31e4bcbe7bf0ff53951eedd Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Ludovic=20Court=C3=A8s?= 
Date: Thu, 25 Apr 2019 12:23:11 +0200
Subject: [PATCH 2/2] doc: Document 'chsh'.

* doc/guix.texi (User Accounts): Document 'chsh'.
---
 doc/guix.texi | 9 +
 1 file changed, 9 insertions(+)

diff --git a/doc/guix.texi b/doc/guix.texi
index 879cb562e9..b5048f7269 100644
--- a/doc/guix.texi
+++ b/doc/guix.texi
@@ -11000,6 +11000,15 @@ if it does not exist yet.
 This is a G-expression denoting the file name of a program to be used as
 the shell (@pxref{G-Expressions}).
 
+Users may change their shell at any time by running the @command{chsh}
+command---run @command{man chsh} for more info.  The list of allowed shells
+can be found in the @file{/etc/shells} file, which is itself the combination
+of the @code{shell} fields of all the user accounts.
+
+Because the account's shell is user-modifiable system state---just like
+passwords---it is preserved across reboots and reconfiguration, even if the
+administrator changes the value of the @code{shell} field.
+
 @item @code{system?} (default: @code{#f})
 This Boolean value indicates whether the account is a ``system''
 account.  System accounts are sometimes treated specially; for instance,
-- 
2.21.0

Re: [PATCH 1/2] bootstrap: Break automake dependency on generated files. (was Re: Let’s translate!)

[Julien Lepiller]

Le 25 avril 2019 10:50:16 GMT+02:00, "Ludovic Courtès"  a écrit :
>Hello,
>
>Julien Lepiller  skribis:
>
>> Le Wed, 24 Apr 2019 00:51:37 +0200,
>> Miguel  a écrit :
>
>[...]
>
>>> El Tue, 23 Apr 2019 16:30:26 +0200
>>> Ludovic Courtès  escribió:
>
>>> > Also, I don’t actually use the ./bootstrap script.  :-)  
>>> 
>>> Currently it is only a call to autoreconf -fvi, but it's there for a
>>> reason, isn't it?
>
>It’s there mostly because people are used to having such a file, but I
>like the fact that it does nothing magical.
>
>> I actually agree with Miguel here. The phony target would not allow
>us
>> to update the manual. It's probably a matter of preferences, but I
>> prefer an up to date manual with some English sentences than a fully
>> translated but outdated manual. I wouldn't use a manual that could
>> refer to an older version.
>
>I agree that up-to-date is preferable.
>
>> You will only be bothered when new translations appear, in which case
>> you'll have to run ./bootstrap again, but on the other hand, you will
>> never be bothered by *.texi files being changed all the time.
>
>So what would one have to do when preparing a new release?  Presumably
>nothing because the up-to-date texi files would be checked in?
>
>IOW, running ./bootstrap is something what would matter primarily to
>translators, is that correct?

It would be needed to build the translated manuals, so I think it would be 
needed to successfuly run make from the git checkout. Translators should not 
even care about the source. Or maybe running only autoreconf will simply not 
build the translated manuals, I'm not sure.

But once you run ./bootstrap once, you should not have to run it again until a 
new language is available for the manual.

>
>Thanks,
>Ludo’.

Re: ISO installer image: GPT versus MBR partitions

[pelzflorian (Florian Pelz)]

So what’s the plan?

Wait for another responce from the grub-devel mailing list?

Package grub-mkrescue-sed.sh and use
--xorriso=/path/to/grub-mkrescue-sed.sh when calling grub-mkrescue?

Add an option to “guix system disk-image” to select which
grub-mkrescue-sed.sh environment variables to enable?

Regards,
Florian

Re: [PATCH 1/2] bootstrap: Break automake dependency on generated files. (was Re: Let’s translate!)

[Ludovic Courtès]

Hello,

Julien Lepiller  skribis:

> Le Wed, 24 Apr 2019 00:51:37 +0200,
> Miguel  a écrit :

[...]

>> El Tue, 23 Apr 2019 16:30:26 +0200
>> Ludovic Courtès  escribió:

>> > Also, I don’t actually use the ./bootstrap script.  :-)  
>> 
>> Currently it is only a call to autoreconf -fvi, but it's there for a
>> reason, isn't it?

It’s there mostly because people are used to having such a file, but I
like the fact that it does nothing magical.

> I actually agree with Miguel here. The phony target would not allow us
> to update the manual. It's probably a matter of preferences, but I
> prefer an up to date manual with some English sentences than a fully
> translated but outdated manual. I wouldn't use a manual that could
> refer to an older version.

I agree that up-to-date is preferable.

> You will only be bothered when new translations appear, in which case
> you'll have to run ./bootstrap again, but on the other hand, you will
> never be bothered by *.texi files being changed all the time.

So what would one have to do when preparing a new release?  Presumably
nothing because the up-to-date texi files would be checked in?

IOW, running ./bootstrap is something what would matter primarily to
translators, is that correct?

Thanks,
Ludo’.

Re: Translation of the Guix manual & node names

[Ludovic Courtès]

"pelzflorian (Florian Pelz)"  skribis:

> On Wed, Apr 24, 2019 at 09:31:59AM +0200, Julien Lepiller wrote:
>> #. type: Plain text
>> #: doc/guix.texi:7
>> msgid "@documentencoding UTF-8"
>> msgstr ""
>> "@documentencoding UTF-8\n"
>> "@documentlanguage fr\n"
>> "@frenchspacing on"
>> 
> I already use this.  The French manual is affected too.  When you do
> `info guix.fr` or use emacs to open the manual, do you see French
> “voir: Quelque section” or English “note: Quelque section”?

My understanding is that the Info format expects a literal “Note:”
regardless of the language.  It wasn’t designed with i18n in mind I
guess.

Ludo’.

Re: ISO installer image: GPT versus MBR partitions

[Thomas Schmitt]

Hi,

Danny Milosavljevic wrte:
> If someone is testing this with Guix, make sure to actually try to boot Guix
> with it (until the root is mounted). Back in the day I changed the root
> discovery of Guix to make it also consider using the entire disk (as opposed
> to a partition on it) as a viable root device (see guix master,
> commit 9833bcfc08ef009b9e8b4398baa481ef65c80ad7).
> That could maybe make it choke if there are multiple partitions/disks with
> equal labels (or whatever field it's searching for) on it (though probably
> not--
> as long as its immaterial which of the partitions/disks with the equal field
> values is mounted).

Volume Id and other superblock properties of the two possible ISO 9660 mount
candidates are supposed to be identical. So on USB stick there is indeed
an ambiguity, which superblock to choose (/dev/sdc versus /dev/sdc1).

But both candidates offer identical directory trees with identical file
properties and content. So it should make no difference which one gets
mounted.
The difference is in the block addresses by which superblock and directory
tree refer to file objects. They have to differ by 16. (Block size 2048.)

Unaware interpreters of hard disk partitioning will hardly consider
the base device for mounting but rather resort to the partitions.
Aware readers, like software in the ISO's initrd, will normally ignore
the partition table and act like on DVD.
But as said, in the end it does not matter which ISO gets mounted.


> FWIW, I'm all for having a MBR-only Guix installer disk as you suggest.

It should at least be tested.
Best with an option of the build process by which the user can choose
between "original", "mbr_hfs" + partition offset 16, "mbr_only" + offset,
and "gpt_appended".

Default should be "original" for now, but with the goal to switch to
"mbr_hfs" or "mbr_only" when enough courageous testers have reported
success.


> But I'd rather not do the hack the others are doing.

I am nagging against the Fedora-inspired layout since years. :))


> How should we mount the root when the right way (with two non-overlapping
> partitions) boots from DVD ?

On DVD there is no public offer of the partition's filesystem.
At least the Linux kernel is not supposed to look for partition tables
on optical media.
(Actually ioctl BLKRRPART is so CD-phobic that it does not even refresh
 the size perception of the medium but simply bails out.
 Else it would be a nice gesture after DVD burning to do
   hdparm -z /dev/sr0
 growisofs emulates this by putting out the tray and pulling it in again,
 if there is a tray motor. Watch your fingers.)


> I'm surprised that it needs so much manual intervention to make
> grub-mkrescue do the right thing.

It does the right thing for the main purpose of creating a widely bootable
ISO image. (The fact that Florian's Macbook takes offense from the EFI
partition image is independent of the partition layout.)

The complaints of Linux at partition assessment time are ugly but harmless.
The lack of a Linux-mountable ISO partition among the four GPT partitions
is ugly, too. But the user can at any time mount the base device of the
USB stick.

grub-mkrescue's partition layout becomes really suboptimal when the user
wants to use the remaining capacity of the USB stick for one or more
read-write data partitions.
Partition editors righteously complain about the misplaced GPT backup,
which cannot be avoided because the image does not get produced for a
storage device of a particular size.

Similarly suboptimal for partition editors is the Fedora-inspired layout
as produced by "isohybrid -u" or "xorrisofs ... -isohybrid-gpt-basdat".
Other than grub-mkrescue's GPT, this layout is barely legal.


Have a nice day :)

Thomas