Re: ‘staging’ and GNOME updates

2019-04-23 Thread Timothy Sample 
Hi Ricardo,

Ricardo Wurmus  writes:

> Argh, it’s unfortunately incorrect.  The problem here is that
> “/home/bob” ends up being owned by root, which is the sole problem.
>
> I’m trying to find another reproducer.

I think I’ve found one.

(use-modules (gnu) (gnu system nss))
(use-service-modules desktop xorg)
(use-package-modules certs gdb gnome linux)

(operating-system
  (host-name "antelope")
  (timezone "Europe/Paris")
  (locale "en_US.utf8")
  (keyboard-layout (keyboard-layout "us" "altgr-intl"))
  (bootloader (bootloader-configuration
   (bootloader grub-efi-bootloader)
   (target "/boot/efi")
   (keyboard-layout keyboard-layout)))
  (file-systems (cons (file-system
(device (file-system-label "my-root"))
(mount-point "/")
(type "ext4"))
  %base-file-systems))
  (users (cons (user-account
(name "bob")
(comment "Alice's brother")
(group "users")
(supplementary-groups '("wheel" "netdev"
"audio" "video")))
   %base-user-accounts))
  (packages (append (list nss-certs gdb gvfs strace)
%base-packages))
  (services (append (list (service gnome-desktop-service-type)
  (set-xorg-configuration
   (xorg-configuration
(keyboard-layout keyboard-layout)))
  (service (service-type
(name 'break-gnome)
(extensions
 (list (service-extension
activation-service-type
(lambda _
  #~(let* ((pw (getpw "bob"))
   (uid (passwd:uid pw))
   (gid (passwd:gid pw)))
  (mkdir-p 
"/home/bob/.local/share/gnome-shell")
  (chown "/home/bob" uid gid)
  (chown "/home/bob/.local" uid 
gid)
  (chown 
"/home/bob/.local/share" uid gid)   
   
  (chown 
"/home/bob/.local/share/gnome-shell" uid gid)
  (copy-file #$(local-file 
"notifications")
 
"/home/bob/.local/share/gnome-shell/notifications")
  (chown 
"/home/bob/.local/share/gnome-shell/notifications" uid gid)
  )
(default-value #t
%desktop-services))
  (name-service-switch %mdns-host-lookup-nss))

The notification file is attached (it’s the one that was originally
causing me problems).



notifications
Description: Binary data

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.

I did get a backtrace of the crash.

#0  0x7f5b368666b6 in __strlen_sse2 () from 
/gnu/store/h90vnqw0nwd0hhm1l5dgxsdrigddfmq4-glibc-2.28/lib/libc.so.6
#1  0x7f5b37718318 in do_lookup.isra () from 
/gnu/store/cgy82g6yv8l1chawgch47zh23b0jll3l-glib-2.56.3/lib/libgio-2.0.so.0
#2  0x7f5b3771890b in g_resource_get_info () from 
/gnu/store/cgy82g6yv8l1chawgch47zh23b0jll3l-glib-2.56.3/lib/libgio-2.0.so.0
#3  0x7f5b37718e8d in g_resources_get_info () from 
/gnu/store/cgy82g6yv8l1chawgch47zh23b0jll3l-glib-2.56.3/lib/libgio-2.0.so.0
#4  0x7f5b36533e15 in _gdk_pixbuf_new_from_resource_try_pixdata ()
   from 
/gnu/store/fnna82d4mjfw8qmnr5l0g3rlr07jw134-gdk-pixbuf-2.38.1/lib/libgdk_pixbuf-2.0.so.0
#5  0x7f5b36533f64 in gdk_pixbuf_new_from_resource () from 
/gnu/store/fnna82d4mjfw8qmnr5l0g3rlr07jw134-gdk-pixbuf-2.38.1/lib/libgdk_pixbuf-2.0.so.0
#6  0x7f5b37012a99 in icon_info_ensure_scale_and_pixbuf () from 
/gnu/store/4ls7vk12bckr2d74492abg81am6nz3br-gtk+-3.24.7/lib/libgtk-3.so.0
#7  0x7f5b37012d4c in load_icon_thread () from 
/gnu/store/4ls7vk12bckr2d74492abg81am6nz3br-gtk+-3.24.7/lib/libgtk-3.so.0
#8  0x7f5b3772d4cd in g_task_thread_pool_thread () from 
/gnu/store/cgy82g6yv8l1chawgch47zh23b0jll3l-glib-2.56.3/lib/libgio-2.0.so.0
#9

Re: Translation of the Guix manual & node names

2019-04-23 Thread Ludovic Courtès 
Hello,

Julien Lepiller  skribis:

> Le Tue, 23 Apr 2019 15:33:32 +0200,
> Ludovic Courtès  a écrit :

[...]

>> What happens in your case is that there is no “Packaging Guidelines”
>> node—instead, it’s called “Guías de empaquetamiento” or “打包指导”.
>> Thus, Texinfo fails to build the translated manual.
>
> No, we have a small script that takes care of this. As long as the node
> name is translated somewhere near the beginning of the file, it is also
> automatically translated in the rest of the file. So that shouldn't
> cause an issue. Maybe there's an error in the script?

Oops indeed, I had misunderstood what was going on.

I applied the Spanish translation and everything went fine.

Then I looked more closely at the Simplified Chinese translation, and I
found a couple of minor issues that I modified locally for the sake of
being able to bootstrap things:

  
https://git.savannah.gnu.org/cgit/guix.git/commit/?id=3068509ac12df6f2fc6e500019a4d8bbf75d32a2

Meiyo, could you take these changes in the official PO file?

Anyway, after ‘guix pull’, “info guix.zh_CN” should also work.  :-)

Thank you, and sorry for the confusion, Julien!

Ludo’.

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

2019-04-23 Thread Miguel 
Hi,

El Tue, 23 Apr 2019 16:30:26 +0200
Ludovic Courtès  escribió:
> Hello,
> 
> Julien Lepiller  skribis:
> 
> > This is a very good idea, but I think it leaves a stub texi that
> > won't get rebuilt because it's younger than po files. What if we
> > add a toucgh invocation to reset the modification time of these
> > stubs, to ensure make will want to rebuild them?  
> 
> 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?

> Shouldn’t we instead replace the existing %.texi targets in
> doc/local.mk with a phony target like ‘update-texi’, and then add:
> 
>   dist-hook: update-texi
> 
> ?

The procedure needed currently to a new translation for the manual is:
  1. modify doc/local.mk, po/doc/local.mk and so on. 
  2. guix.LL.texi must be manually generated somehow even though it is
  listed in BUILT_SOURCES.
  3. automake can run without errors with the rules in order to generate
  the actual translated file.
  4. The resulting files are committed.

The problem is that automake parses .texi files for the @setfilename
tag. On the other hand, guix.LL.texi and contributing.LL.texi are
generated files, and they shouldn't be on the VCS, just like neither
configure nor Makefile.in are, though they are distributed. My patch
tries to avoid this issue creating stub files that will be overwritten
with the actual content. This has the advantage of keeping clean git
status from other modifications than .po files changes.

This may sound familiar to this community, it actually is a bootstrap
problem. Running autoreconf -fvi actually tells you that that file is
missing, so that part is easy to fix. On the other hand, as far as I
tested if it does not contain a line with version-LL.texi,
version-LL.texi won't be generated.

Happy hacking,
Miguel

Re: [PATCH 2/2] doc: Add Spanish translation. (was Re: Let’s translate!)

2019-04-23 Thread Ludovic Courtès 
¡Hola Miguel!

Miguel  skribis:

> From 1bb5dba99f87e3afefb4133617d71afc134e1ff1 Mon Sep 17 00:00:00 2001
> From: =?UTF-8?q?Miguel=20=C3=81ngel=20Arruga=20Vivas?=
>  
> Date: Tue, 23 Apr 2019 00:40:10 +0200
> Subject: [PATCH 2/2] doc: Add Spanish translation.
>
> * doc/local.mk (info_TEXINFOS): Add guix.es.texi.
> (TRANSLATED_INFO): Add guix.es.texi and contributing.es.texi.
> * po/doc/guix-manual.es.po: New file.
> * po/doc/local.mk: Add guix-manual.es.po.

Applied, thanks a lot!

If you ‘guix pull’ now, you should be able to run “info guix.es”.  \o/

According to the stats at
, Spanish debuts
at #2.  :-)

(Thanks also for the translation note about gender neutrality in
Spanish, which is indeed as tricky as in French.)

Ludo’.

Re: Translation of the Guix manual & node names

2019-04-23 Thread Julien Lepiller 
Le Tue, 23 Apr 2019 23:48:13 +0200,
Miguel  a écrit :

> El Tue, 23 Apr 2019 15:52:19 +0200
> Julien Lepiller  escribió:
> > Le Tue, 23 Apr 2019 15:33:32 +0200,
> > Ludovic Courtès  a écrit :
> >   
> > > Hello Miguel & Meiyo,  
> 
> Hi!
> 
> > > Thanks a lot for your translations of the Guix manual!  
> 
> Thank you too for your effort and kindness.
> 
> > > (...)
> > > If we look at these, you both translated, for example, the
> > > “Packaging Guidelines” string.  However, you also left, in your
> > > translations, things like “@pxref{Packaging Guidelines}”.
> > > (...)  
> > No, we have a small script that takes care of this. As long as the
> > node name is translated somewhere near the beginning of the file, it
> > is also automatically translated in the rest of the file. So that
> > shouldn't cause an issue. Maybe there's an error in the script?
> > 
> > Look at xref_command in doc/local.mk
> >
> > Also look at fr.po, I haven't translated most of the node names.  
> 
> It took me some time getting that, by example from fr.po, of course,
> but I think there are some errors or warnings related when you do it
> wrong. AFAIK the only problem are some @ref or @xref entries that
> contain the link and some text, that actually must be translated. I
> have to double check them this week on the translation.
> 
> > > Could you please translate all the node names, and make sure that
> > > all the cross-reference commands use the same names?  (The plan is
> > > to release Guix 1.0 in one week, so it would be great if you could
> > > send an updated PO file by then!)  
> 
> I hope having more than only the node names this week. Pretty sure it
> won't be the full translation, but I hope reaching 70% at least for
> 1.0. We'll see...

The attached python script (it requires python and python-polib) might
get you closer by automatically translating some very common strings.

So you have to change these lines:

regexps.append([re.compile('English regexp'), 'Translate string'])

#1, #2 etc. are replaced by the content of the matches in the English
regexp.

I don't know if you'll use it, but I hope it will be of some help to
you. Good luck with the translation!

> 
> Happy hacking,
> Miguel

#!/usr/bin/python3
# -*- coding: utf-8 -*-

#Template Translator v0.1
#Traduit automatiquement certaines chaine de caractères des paquets

#Publié par roptat  le 8 août 2016
#sous la licence gnu General Public License version 3 pubilée par la Free Software Foundation.
#Visitez  pour obtenir la licence.


import sys
import re
import polib

files = sys.argv
files.pop(0)

def convert(entry, regexp, template):
	m = regexp.match(entry.msgid)
	# do not modify anything if the translation is already correct
	if m and ("fuzzy" in entry.flags or not entry.msgstr):
		msgstr = template
		try:
			msgstr = msgstr.replace("#1", m.group(1))
			msgstr = msgstr.replace('#2', m.group(2))
			msgstr = msgstr.replace('#3', m.group(3))
			msgstr = msgstr.replace('#4', m.group(4))
		except:
			x=1
		entry.msgstr = msgstr
		if "fuzzy" in entry.flags:
			entry.flags.remove("fuzzy")


# regexps
regexps = []

regexps.append([re.compile('{Scheme Procedure} (.*)$'), '{Procédure Scheme} #1'])
regexps.append([re.compile('{Scheme Variable} (.*)$'), '{Variable Scheme} #1'])
regexps.append([re.compile('{Data Type} (.*)$'), '{Type de données} #1'])
regexps.append([re.compile('@code{([^}]*)} \\(default:? #t\\)$'),
'@code{#1} (par défaut : #t)'])
regexps.append([re.compile('@code{([^}]*)} \\(default:? ([0-9]*)\\)$'),
'@code{#1} (par défaut : #2)'])
regexps.append([re.compile('@code{([^}]*)} \\(default:? @code{([^}]*)}\\)$'),
'@code{#1} (par défaut : @code{#2})'])
regexps.append([re.compile('@code{([^}]*)} \\(default:? @var{([^}]*)}\\)$'),
'@code{#1} (par défaut : @var{#2})'])
regexps.append([re.compile('@code{([^}]*)} \\(default:? "([^"]*)"\\)$'),
'@code{#1} (par défaut : "#2")'])
regexps.append([re.compile('{@code{([^}]*)} parameter} ([^ ]*) ([^ ]*)$'), '{paramètre de @code{#1}} #2 #3'])
regexps.append([re.compile('The ([^ ]*) package to use.$'), 'Le paquet #1 à utiliser.'])
regexps.append([re.compile('Defaults to @samp{([^}]*)}.$'), 'La valeur par défaut est @samp{#1}.'])
regexps.append([re.compile('Available @code{(.*)} fields are:$'), 'Les champs de @code{#1} disponibles sont :'])


po = polib.pofile(files[0])

for entry in po:
	for reg in regexps:
		convert(entry, reg[0], reg[1])
po.save()

Re: Translation of the Guix manual & node names

2019-04-23 Thread Laura Lazzati 
Hi!

I'm always late :S
 Do you need help with the Spanish translations?

Kind regards :)
Laura

Re: Translation of the Guix manual & node names

2019-04-23 Thread Miguel 
El Tue, 23 Apr 2019 15:52:19 +0200
Julien Lepiller  escribió:
> Le Tue, 23 Apr 2019 15:33:32 +0200,
> Ludovic Courtès  a écrit :
> 
> > Hello Miguel & Meiyo,

Hi!

> > Thanks a lot for your translations of the Guix manual!

Thank you too for your effort and kindness.

> > (...)
> > If we look at these, you both translated, for example, the
> > “Packaging Guidelines” string.  However, you also left, in your
> > translations, things like “@pxref{Packaging Guidelines}”.
> > (...)
> No, we have a small script that takes care of this. As long as the
> node name is translated somewhere near the beginning of the file, it
> is also automatically translated in the rest of the file. So that
> shouldn't cause an issue. Maybe there's an error in the script?
> 
> Look at xref_command in doc/local.mk
>
> Also look at fr.po, I haven't translated most of the node names.

It took me some time getting that, by example from fr.po, of course, but
I think there are some errors or warnings related when you do it wrong.
AFAIK the only problem are some @ref or @xref entries that contain the
link and some text, that actually must be translated. I have to double
check them this week on the translation.

> > Could you please translate all the node names, and make sure that
> > all the cross-reference commands use the same names?  (The plan is
> > to release Guix 1.0 in one week, so it would be great if you could
> > send an updated PO file by then!)

I hope having more than only the node names this week. Pretty sure it
won't be the full translation, but I hope reaching 70% at least for
1.0. We'll see...

Happy hacking,
Miguel

Re: ISO installer image: GPT versus MBR partitions

2019-04-23 Thread pelzflorian (Florian Pelz) 
On Tue, Apr 23, 2019 at 10:18:10PM +0200, Thomas Schmitt wrote:
> Florian Pelz wrote:
> > florian@florianmacbook ~ [env]$ grub-mkrescue -o output.iso minimal
> > --xorriso=./grub-mkrescue-sed.sh
> > grub-mkrescue: warning: Your xorriso doesn't support `--grub2-boot-info'.
> > Some features are disabled. Please use xorriso 1.2.9 or later..
> >
> > and yields no output.iso for me.  Note that xorriso actually has
> > version 1.5.0.
> 
> Does the script offer x-permission ?
> (Shame on me for not thinking of this in my download instructions.)
> 

This was the error.  It works after `chmod +x grub-mkrescue-sed.sh`.


On Tue, Apr 23, 2019 at 08:14:48PM +0200, Thomas Schmitt wrote:
> It would be interesting to learn about EFIs which fail without MBR
> signature.
> […]
> - Put the resulting output.iso on USB stick and offer it to your firmware
>   at boot time.
>   Is it not found by the EFI boot manager ?
>   If you let it boot, does the machine not show a GRUB prompt in the end ?
> 

It shows up twice in the boot selection screen as “GRUB 2.02” and “EFI
Boot” just like the Guix USB drive before.  It is bootable and shows a
GRUB prompt on my Macbook.



> - Negative results with other mode settings in MKRESCUE_SED_MODE would be
>   interesting, too.
> 

I can try tomorrow.

By the way, someone I know has a most peculiar machine called Lenovo
Ideapad 100S which does not boot Guix, but apparently is very picky in
general (cf. ).
Its CPU is claimed to support 64-bit, but its boot firmware rejects
most 64-bit isos.  I wonder if we could get that machine to boot Guix
(at least it currently cannot boot
guixsd-install-0.15.0.i686-linux.iso), but that may well be a waste of
time.  It might just not be feasible to please every EFI system.



> I wrote:
> > > So programs like /sbin/isosize can tell the image size even when the
> > > ISO has already been copied to USB stick.
> 
> > Sounds like this could be used to get a checksum or maybe GPG
> > verification of a USB drive that supposedly contains the iso.
> 
> That's what this property is advised for in Debian's CD FAQ.
> One can read trailing garbage not only from USB sticks but also from
> most DVD types.
> (The layout with nested partitions obsoletes the cleanliness
>  considerations about partition start at LBA 0.)
>

So… GPT is wrong for some optical media too?

Regards,
Florian

Re: Problem with `direnv` package definition

2019-04-23 Thread Tanguy Le Carrour 
Le 04/21, Christopher Baines a écrit :
> Tanguy Le Carrour  writes:
> > Le 04/20, Christopher Baines a écrit :
> >> Tanguy Le Carrour  writes:
> >> > However, in the package definition [2], 3 Go packages are listed as
> >> > "inputs" whereas they should be listed as "native-inputs". Is this
> >> > correct?
> >> That sounds right to me, although there have been issues with binaries
> >> generated with Go […]
> […]
> So, in contrast to some other package management systems, the runtime
> dependencies, or references of the output(s) in the case of Guix are not
> explicitly set in the package definition.
> 
> This is still something I have a little difficulty understanding, but
> the inputs/native-inputs distinction is more about architecture than
> runtime references.

Ouch?! If you have difficulty understanding it, imagine for me! ^_^'


> I've just pushed a commit that pulls in the relevant phase, and makes
> the inputs, native-inputs [1]. With that change, the size of the package
> does drop [2].

Thank you so much for that!


> That's not to say that making the inputs, native-inputs in this case is
> wrong, quite the opposite. […] Currently the direnv package is using the
> gnu-build-system, as it's one of the older go packages in Guix, however
> it does now pull in some phases from the go-build-system.
> […]
> Anyway, while the size of direnv should now be improved, there's still
> more improvements to be made to the direnv package if you're interested!
> I think it would be better to switch to using the go build system, and
> the package in Guix is quite a few versions behind.

So this might be something I could be investigating in a near future!
But I guess I'll have to read some Go package definitions first…
Which won't be a waste of time, for `fzf` is also written in Go!


Regards


-- 
Tanguy

Re: ISO installer image: GPT versus MBR partitions

2019-04-23 Thread Thomas Schmitt 
Hi,

Florian Pelz wrote:
> florian@florianmacbook ~ [env]$ grub-mkrescue -o output.iso minimal
> --xorriso=./grub-mkrescue-sed.sh
> grub-mkrescue: warning: Your xorriso doesn't support `--grub2-boot-info'.
> Some features are disabled. Please use xorriso 1.2.9 or later..
>
> and yields no output.iso for me.  Note that xorriso actually has
> version 1.5.0.

Does the script offer x-permission ?
(Shame on me for not thinking of this in my download instructions.)

If so, what do you get from

  ./grub-mkrescue-sed.sh -as mkisofs -help 2>&1 | fgrep grub2-boot-info

If it says

  --grub2-boot-info   Patch boot image at byte 2548

then i wonder why grub-mkrescue is not satisfied in
  http://git.savannah.gnu.org/cgit/grub.git/tree/util/grub-mkrescue.c#n608


I wrote:
> > So programs like /sbin/isosize can tell the image size even when the
> > ISO has already been copied to USB stick.

> Sounds like this could be used to get a checksum or maybe GPG
> verification of a USB drive that supposedly contains the iso.

That's what this property is advised for in Debian's CD FAQ.
One can read trailing garbage not only from USB sticks but also from
most DVD types.
(The layout with nested partitions obsoletes the cleanliness
 considerations about partition start at LBA 0.)


Have a nice day :)

Thomas

Re: ‘staging’ and GNOME updates

2019-04-23 Thread Ricardo Wurmus 


Ludovic Courtès  writes:

> Ricardo Wurmus  skribis:
>
>>   (service (service-type
>> (name 'break-gnome)
>> (extensions
>>  (list (service-extension
>> activation-service-type
>> (lambda _
>>   #~(mkdir-p 
>> "/home/bob/.local/share/gnome-shell")
>> (default-value #t
>> %desktop-services))
>>   (name-service-switch %mdns-host-lookup-nss))
>>
>> Note the “break-gnome” service.  When the service does not exist,
>> everything is fine.  It seems to me that the contents of the directory
>> really do not matter after all.
>
> Nice reproducer!

Argh, it’s unfortunately incorrect.  The problem here is that
“/home/bob” ends up being owned by root, which is the sole problem.

I’m trying to find another reproducer.

--
Ricardo

Re: ISO installer image: GPT versus MBR partitions

2019-04-23 Thread pelzflorian (Florian Pelz) 
This sounds nice and clean.  Thank you!

On Tue, Apr 23, 2019 at 08:14:48PM +0200, Thomas Schmitt wrote:
> A disadvantage is that for best overall properties, this layout should
> have the ISO partition start at 512-byte block 64. This needs a second
> superblock and directory tree. About 17 MiB with Guix 0.16.0.
> 

The ISO files are offered on alpha.gnu.org only with xz compression.
I suppose most of the 17 MiB would disappear with compression.


> So programs like /sbin/isosize can tell the image size even when the
> ISO has already been copied to USB stick.
> 

Sounds like this could be used to get a checksum or maybe GPG
verification of a USB drive that supposedly contains the iso.



> Somewhat off topic:
> 
> The script also has a killer for the MBR signature in the EFI image
> file. It gets activated together with partition table erasure by
>   export MKRESCUE_SED_IN_EFI_NO_PT=extra
> It is meant for those users who are curious whether block 0 of an EFI
> partition really must look like an MBR to be accepted by EFI firmware.
> 
> It would be interesting to learn about EFIs which fail without MBR
> signature.
> 
> The specs say that there may be "compatibility code" in a EFI System
> Partition. They talk of "MBR" and understanding partitions in the EFI
> partition. I understand it as "may be there, but does not have to".
> 
> Minimal test outside of Guix ISO production:
> 
> - Install GRUB and configure it for EFI for 32 or 64 bit as your firmware
>   needs. (Both is combinable, as Debian GRUB packages demonstrate.)
> 
> - Create a minimal bootable ISO. It will not offer more than a GRUB
>   command prompt after it was successfully booted:
> 
> mkdir minimal
> touch minimal/empty-file.txt
> 
> export MKRESCUE_SED_MODE=original
> export MKRESCUE_SED_IN_EFI_NO_PT=extra
> 
> grub-mkrescue -o output.iso minimal \
>   --xorriso=./grub-mkrescue-sed.sh
>

This prints

florian@florianmacbook ~ [env]$ grub-mkrescue -o output.iso minimal 
--xorriso=./grub-mkrescue-sed.sh
grub-mkrescue: warning: Your xorriso doesn't support `--grub2-boot-info'. Some 
features are disabled. Please use xorriso 1.2.9 or later..

and yields no output.iso for me.  Note that xorriso actually has
version 1.5.0.

Regards,
Florian

Re: Translation of the Guix manual & node names

2019-04-23 Thread Meiyo Peng 
Hi Ludovic,

Ludovic Courtès writes:

> Hello Miguel & Meiyo,
>
> Thanks a lot for your translations of the Guix manual!
>
> I found an issue with the translations that prevents us from including
> them:
>
>   https://translationproject.org/latest/guix-manual/es.po
>   https://translationproject.org/latest/guix-manual/zh_CN.po
>
> If we look at these, you both translated, for example, the “Packaging
> Guidelines” string.  However, you also left, in your translations,
> things like “@pxref{Packaging Guidelines}”.
>
> Texinfo has a notion of “node” (roughly a node is a chapter, section, or
> sub-section.)  Each node has a name that can be used in cross-references
> commands @ref, @xref, or @pxref.  However, Texinfo errors out when a
> cross-reference command refers to a non-existent node name.
>
> What happens in your case is that there is no “Packaging Guidelines”
> node—instead, it’s called “Guías de empaquetamiento” or “打包指导”.
> Thus, Texinfo fails to build the translated manual.

The zh_CN version guix manual that I uploaded earlier is a test with the
TranslationProject.org robot.  It's not supposed to be used as a
suitable translation.  I should have notified you in the mailing list.

I will improve the manual gradually.  As I said before, I have no
experience with i18n.  I only learned the usage of @ref, @xref and
@pxref until yesterday.  And there are still many new things to learn.

> Could you please translate all the node names, and make sure that all
> the cross-reference commands use the same names?  (The plan is to
> release Guix 1.0 in one week, so it would be great if you could send an
> updated PO file by then!)
>
> I’m attaching the complete list of node names below; “Top” is an
> exception, it must _not_ be translated.

OK.  I will do my best.  However, my translation progress will be slow.
It's 02:00 in China now and I am still in my office working on my job!
I won't have much time recently, but I will do as much as I can.

I feel excited for the Guix 1.0 release and also regret that I cannot
translate the Guix manual before that date.  The translation work can be
finished in two or three months, I guess.  It's extremely difficult to
translate technical English manuals into Chinese.  Many technical
English words has no suitable Chinese translation.  Besides, I have
never ever used a Chinese version GNU/Linux distro or ever read the
Chinese version manuals, so I am unfamiliar with the corresponding
Chinese words.  This makes the translation work even harder for me.
However, I am sure a bundled Chinese manual in the Guix 1.0 release
tarball or ISO file won't matter much.  We can release an updated
Chinese manual on our website later.  The web version will be what most
people will use.

Thank you for your understanding.


--
Meiyo Peng
https://www.pengmeiyu.com/

Re: ISO installer image: GPT versus MBR partitions

2019-04-23 Thread Thomas Schmitt 
Hi,

after the adventure of diagnosing Macbook EFI and mformat, i want to
return to the original topic of this thread:
I deem it worthwhile to offer the opportunity to create the Guix ISO
with MBR partition table rather than with GPT.

If you just want to see my technical proposal, then hop to the next
section titled "How to do it".

The advantages of my proposal are:

- No GPT backup which needs to be relocated after the ISO was put
  onto USB stick.

- Mountable ISO 9660 partition. (The GPT of a pure grub-mkrescue ISO
  offers a HFS+ partition for mounting. But afaik, Linux hates the
  block size 2048.)

A disadvantage is that for best overall properties, this layout should
have the ISO partition start at 512-byte block 64. This needs a second
superblock and directory tree. About 17 MiB with Guix 0.16.0.

If the size increase matters, then i propose to sacrifice the HFS+
filesystem tree as compensation.
It is for Macs even older than Florian's.

Without that non-zero partition start, the ISO superblock (PVD) of the
overall image cannot claim the appended EFI partition 2 as part of its
filesystem. That's because the superblock is mountable as partition 1
and a partition filesystem should not be larger than its partition.

But with partition start at LBA 64, the overall superblock is not
mountable via a partition and thus free to claim as much space as it
wants.
So programs like /sbin/isosize can tell the image size even when the
ISO has already been copied to USB stick.

Partition editors, too, will love a partition start after the partition
table rather than at block 0.

--

How to do it:

We can achieve the MBR partition table based layout by a script which
is part of libisoburn. It acts as pseudo-xorriso between grub-mkrescue
and real xorriso.
Yesterday i improved it by a partition table killer for the EFI image:
  MKRESCUE_SED_IN_EFI_NO_PT=yes.

For experiments it is best to download it from upstream.
Currently the https certificate is not valid. So for now unsafe:

  wget --no-check-certificate \
   
https://dev.lovelyhq.com/libburnia/libisoburn/raw/master/frontend/grub-mkrescue-sed.sh

Size of today's version is 11077 bytes.
SHA512 is
  
23cbc25aac8e03de82bd6e76b00a6ad249629c19822728616d6144f075dbb78f69811648559846ba33319c38baa21515e4a3a0f7bb3ca86f2427e887592101cf
(Ask if you get a different checksum. Maybe i'll make more changes.)



In a shell script it would be used like this:

  export MKRESCUE_SED_MODE=mbr_hfs
  export MKRESCUE_SED_IN_EFI_NO_PT=yes

  grub-mkrescue --xorriso=./grub-mkrescue-sed.sh \
... the usual arguments for grub-mkrescue ... \
... with or without a -- switch to native command mode ... \
-- \
-boot_image any partition_offset=16 \
-boot_image any iso_mbr_part_type=0x83

The result (with nearly no payload) looks like

  $ /sbin/fdisk -l output.iso
  ...
  Disklabel type: dos
  ...
  Device  Boot Start   End Sectors  Size Id Type
  output.iso1 *   64 28695   28632   14M 83 Linux
  output.iso2  28696 344555760  2.8M ef EFI (FAT-12/16/32)

  $ expr $(/sbin/isosize output.iso) / 512
  34456

The HFS+ superblock and directory tree will be marked by a partition
in an Apple Partition Map. From xorriso -report_system_area :

  APM:   N  Info
  APM block size :  2048
  APM gap fillers:  1
  APM partition name :   1  Gap0
  APM partition type :   1  ISO9660_data
  APM start and size :   1  16  150
  APM partition name :   2  HFSPLUS_Hybrid
  APM partition type :   2  Apple_HFS
  APM start and size :   2  166  7008



If HFS+ shall be omitted for size reduction or other reasons, use
a different mode of grub-mkrescue-sed.sh :

  export MKRESCUE_SED_MODE="mbr_only"

rather than MKRESCUE_SED_MODE="mbr_hfs".
The result will be smaller by the size of the additional HFS+ tree.

  $ expr $(/sbin/isosize output.iso) / 512
  33864

(The true cost of HFS+ and second ISO directory tree will show up only
 with much more files in the trees.)



The original GPT layout with additionally zeroed inner EFI partition
table can be achieved by:

  export MKRESCUE_SED_MODE=original
  export MKRESCUE_SED_IN_EFI_NO_PT=yes

  grub-mkrescue --xorriso=./grub-mkrescue-sed.sh \
... the usual arguments for grub-mkrescue ...

(Partition offset and MBR partition type are of no use with "original".)

The result is

  $ /sbin/fdisk -l output.iso
  ...
  Disklabel type: gpt
  ...
  Device  Start   End Sectors  Size Type
  output.iso164   339 276  138K Microsoft basic data
  output.iso2   340  60995760  2.8M EFI System
  output.iso3  6100 34131   28032 13.7M Apple HFS/HFS+

Re: ISO installer image: GPT versus MBR partitions

2019-04-23 Thread Thomas Schmitt 
Hi,

Florian pelaz wrote:
> So the options are:
> · Update mtools and then somehow patch mformat to zero out this
>  region.

I will hopefully tonight post a proposal for

- Leave grub-mkrescue and mformat as they are. Rather do the partition
  entry removal in the course of Guix ISO production.

It will be windfall profit of my detailed proposal for creating ISOs
with MBR partition table and Linux mountable ISO partition.


Have a nice day :)

Thomas

Re: ISO installer image: GPT versus MBR partitions

2019-04-23 Thread pelzflorian (Florian Pelz) 
A friend’s “early 2014” MacBookAir6,2 does not have issues with the
old iso image.  It seems likely that only old Macbooks are affected.

On Sun, Apr 21, 2019 at 02:27:10PM +0200, Thomas Schmitt wrote:
> > I change it to
> >80  00  02  00  01  01  12  4f  01  00  00  00  3f  0b  00  00
> > I dd the changed mysdc2.img back to /dev/sdc2.
> >
> > Now it boots. :)
> > […]
> > Strangely, I now have only one entry “GRUB 2.02” in
> > the boot selection, but “EFI Boot” (or what it was called) is gone.
> 
> What do you see if the partition entry is zeroized entirely ?
>

I see both “GRUB 2.02” and “EFI Boot” when I zero it (I have not tried
on Guix 0.16.0 this time though).

So the options are:

· Update mtools and then somehow patch mformat to zero out this
  region.

· Patch grub-mkrescue instead to make it use mformat -k.  Vladimir
  Serbinenko on the grub-devel list said this removes only information
  that is “Probably” not useful anyway, see
  https://lists.gnu.org/archive/html/grub-devel/2019-04/msg00100.html

· Ignore the issue.  The only affected machines we know are old Macbooks.

Regards,
Florian

Status of 1.0

2019-04-23 Thread Ludovic Courtès 
Hello Guix!

Here’s the quick update on things that remain to be done for 1.0:

  - live image configuration ready (I’ve started looking into it)

  - guix.gnu.org set up—Julien, are we going to be able to make it?

  - zh_CN + es manuals added

  - 1.0.0-pre2 submitted to the TP: translations need one last update

  - ‘staging’ merged: that sounds feasible now that the GNOME upgrade
issue has been narrowed down

  - ‘static-networking’ support in the installer, hopefully!

  - improve handling of the initial passwords in the installer:


Things we may not be able to do:

  - grafts: that was one of the big items in the 1.0.org document, but
I’m willing to punt again on this one for now.

  - static-networking and IPv6: it looks like this will be for 1.0.1

  - new video uploaded on front page?

The April 30th deadline (+/- a couple of days) still sounds doable to
me, we’ll see how it goes, but let’s aim for that!

Thanks,
Ludo’.

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

2019-04-23 Thread Ludovic Courtès 
Hello,

Julien Lepiller  skribis:

> This is a very good idea, but I think it leaves a stub texi that won't get 
> rebuilt because it's younger than po files. What if we add a toucgh 
> invocation to reset the modification time of these stubs, to ensure make will 
> want to rebuild them?

Also, I don’t actually use the ./bootstrap script.  :-)

Shouldn’t we instead replace the existing %.texi targets in doc/local.mk
with a phony target like ‘update-texi’, and then add:

  dist-hook: update-texi

?

This would be similar to the ‘update-po’ rule generated by Gettext in
po/.

Thanks,
Ludo’.

Re: Translation of the Guix manual & node names

2019-04-23 Thread Julien Lepiller 
Le Tue, 23 Apr 2019 15:33:32 +0200,
Ludovic Courtès  a écrit :

> Hello Miguel & Meiyo,
> 
> Thanks a lot for your translations of the Guix manual!
> 
> I found an issue with the translations that prevents us from including
> them:
> 
>   https://translationproject.org/latest/guix-manual/es.po
>   https://translationproject.org/latest/guix-manual/zh_CN.po
> 
> If we look at these, you both translated, for example, the “Packaging
> Guidelines” string.  However, you also left, in your translations,
> things like “@pxref{Packaging Guidelines}”.
> 
> Texinfo has a notion of “node” (roughly a node is a chapter, section,
> or sub-section.)  Each node has a name that can be used in
> cross-references commands @ref, @xref, or @pxref.  However, Texinfo
> errors out when a cross-reference command refers to a non-existent
> node name.
> 
> What happens in your case is that there is no “Packaging Guidelines”
> node—instead, it’s called “Guías de empaquetamiento” or “打包指导”.
> Thus, Texinfo fails to build the translated manual.

No, we have a small script that takes care of this. As long as the node
name is translated somewhere near the beginning of the file, it is also
automatically translated in the rest of the file. So that shouldn't
cause an issue. Maybe there's an error in the script?

Look at xref_command in doc/local.mk

Also look at fr.po, I haven't translated most of the node names.

> 
> Could you please translate all the node names, and make sure that all
> the cross-reference commands use the same names?  (The plan is to
> release Guix 1.0 in one week, so it would be great if you could send
> an updated PO file by then!)
> 
> I’m attaching the complete list of node names below; “Top” is an
> exception, it must _not_ be translated.
> 
> Thanks in advance,
> Ludo’.

Translation of the Guix manual & node names

2019-04-23 Thread Ludovic Courtès 
Hello Miguel & Meiyo,

Thanks a lot for your translations of the Guix manual!

I found an issue with the translations that prevents us from including
them:

  https://translationproject.org/latest/guix-manual/es.po
  https://translationproject.org/latest/guix-manual/zh_CN.po

If we look at these, you both translated, for example, the “Packaging
Guidelines” string.  However, you also left, in your translations,
things like “@pxref{Packaging Guidelines}”.

Texinfo has a notion of “node” (roughly a node is a chapter, section, or
sub-section.)  Each node has a name that can be used in cross-references
commands @ref, @xref, or @pxref.  However, Texinfo errors out when a
cross-reference command refers to a non-existent node name.

What happens in your case is that there is no “Packaging Guidelines”
node—instead, it’s called “Guías de empaquetamiento” or “打包指导”.
Thus, Texinfo fails to build the translated manual.

Could you please translate all the node names, and make sure that all
the cross-reference commands use the same names?  (The plan is to
release Guix 1.0 in one week, so it would be great if you could send an
updated PO file by then!)

I’m attaching the complete list of node names below; “Top” is an
exception, it must _not_ be translated.

Thanks in advance,
Ludo’.

$ grep '^@node' doc/guix.texi doc/contributing.texi| sed -e's/.*@node //g'
Top
Introduction
Managing Software the Guix Way
GNU Distribution
Installation
Binary Installation
Requirements
Running the Test Suite
Setting Up the Daemon
Build Environment Setup
Daemon Offload Setup
SELinux Support
Invoking guix-daemon
Application Setup
System Installation
Limitations
Hardware Considerations
USB Stick and DVD Installation
Preparing for Installation
Guided Graphical Installation
Manual Installation
Keyboard Layout and Networking and Partitioning
Proceeding with the Installation
After System Installation
Installing Guix in a VM
Building the Installation Image
Package Management
Features
Invoking guix package
Substitutes
Official Substitute Server
Substitute Server Authorization
Substitute Authentication
Proxy Settings
Substitution Failure
On Trusting Binaries
Packages with Multiple Outputs
Invoking guix gc
Invoking guix pull
Channels
Inferiors
Invoking guix describe
Invoking guix archive
Development
Invoking guix environment
Invoking guix pack
Programming Interface
Package Modules
Defining Packages
package Reference
origin Reference
Build Systems
The Store
Derivations
The Store Monad
G-Expressions
Invoking guix repl
Utilities
Invoking guix build
Common Build Options
Package Transformation Options
Additional Build Options
Debugging Build Failures
Invoking guix edit
Invoking guix download
Invoking guix hash
Invoking guix import
Invoking guix refresh
Invoking guix lint
Invoking guix size
Invoking guix graph
Invoking guix publish
Invoking guix challenge
Invoking guix copy
Invoking guix container
Invoking guix weather
Invoking guix processes
System Configuration
Using the Configuration System
operating-system Reference
File Systems
Mapped Devices
User Accounts
Keyboard Layout
Locales
Services
Base Services
Scheduled Job Execution
Log Rotation
Networking Services
X Window
Printing Services
Desktop Services
Sound Services
Database Services
Mail Services
Messaging Services
Telephony Services
Monitoring Services
Kerberos Services
LDAP Services
Web Services
Certificate Services
DNS Services
VPN Services
Network File System
Continuous Integration
Power Management Services
Audio Services
Virtualization Services
Version Control Services
Game Services
Miscellaneous Services
Setuid Programs
X.509 Certificates
Name Service Switch
Initial RAM Disk
Bootloader Configuration
Invoking guix system
Running Guix in a VM
Defining Services
Service Composition
Service Types and Services
Service Reference
Shepherd Services
Documentation
Installing Debugging Files
Security Updates
Bootstrapping
Porting
Acknowledgments
GNU Free Documentation License
Concept Index
Programming Index
Contributing
Building from Git
Running Guix Before It Is Installed
The Perfect Setup
Packaging Guidelines
Software Freedom
Package Naming
Version Numbers
Synopses and Descriptions
Python Modules
Perl Modules
Java Packages
Fonts
Coding Style
Programming Paradigm
Modules
Data Types and Pattern Matching
Formatting Code
Submitting Patches

GNU Shepherd 0.6.0 released

2019-04-23 Thread Ludovic Courtès 
We are pleased to announce the GNU Shepherd version 0.6.0, a release
containing new features and bug fixes.

• About

  The GNU Daemon Shepherd or GNU Shepherd is a service manager written
  in Guile that looks after the herd of system services.  It provides a
  replacement for the service-managing capabilities of SysV-init (or any
  other init) with a dependency-based system with a convenient
  interface.  The GNU Shepherd may also be used by unprivileged users to
  manage per-user daemons (e.g., tor, privoxy, mcron, etc.)  It is
  written in Guile Scheme, and is configured and extended using Guile.

  The GNU Shepherd is developed jointly with the GNU Guix project; it is
  used as the init system of Guix, GNU’s advanced GNU/Linux distribution.

  https://www.gnu.org/software/shepherd/


• Download

  Here are the compressed sources and a GPG detached signature[*]:
https://ftp.gnu.org/gnu/shepherd/shepherd-0.6.0.tar.gz
https://ftp.gnu.org/gnu/shepherd/shepherd-0.6.0.tar.gz.sig

  Use a mirror for higher download bandwidth:
https://ftpmirror.gnu.org/shepherd/shepherd-0.6.0.tar.gz
https://ftpmirror.gnu.org/shepherd/shepherd-0.6.0.tar.gz.sig

  Here are the SHA1 and SHA256 checksums:

  9be871aff2c2d8ad8068714878eee6acee5cd35b  shepherd-0.6.0.tar.gz
  51a816cc145ec38866a9dc3b7e64c52ef9db1c631a8dbe50be5a98ba07e242fb  
shepherd-0.6.0.tar.gz

  [*] Use a .sig file to verify that the corresponding file (without the
  .sig suffix) is intact.  First, be sure to download both the .sig file
  and the corresponding tarball.  Then, run a command like this:

gpg --verify shepherd-0.6.0.tar.gz.sig

  If that command fails because you don't have the required public key,
  then run this command to import it:

gpg --keyserver pool.sks-keyservers.net \
--recv-keys 3CE464558A84FDC69DB40CFB090B11993D9AEBB5

  and rerun the 'gpg --verify' command.

  This release was bootstrapped with the following tools:
Autoconf 2.69
Automake 1.16.1
Makeinfo 6.5
Help2man 1.47.8


• Changes since version 0.5.0 (excerpt from the NEWS file)

  ** Services can now be “one-shot” (see the manual for details)
  ** ‘shepherd’ deletes its socket file upon termination
  ** ‘herd stop S’ is no longer an error when S is already stopped
  ** ‘herd’ exits with non-zero when executing an action that fails
  ** ‘shepherd’ ignores reboot(2) errors when running in a container
  ** Translation of error messages has been fixed
  ** New translation: ta (Tamil)
  ** Updated translations: da, es, fr, pt_BR, sv, ta, uk, zh_CN


Please report bugs to bug-g...@gnu.org.
Join guix-devel@gnu.org and gnu-system-disc...@gnu.org for discussions.

Ludovic, on behalf of the Shepherd herd.


signature.asc
Description: PGP signature

Re: ‘staging’ and GNOME updates

2019-04-23 Thread Ludovic Courtès 
Hello!

Ricardo Wurmus  skribis:

>   (service (service-type
> (name 'break-gnome)
> (extensions
>  (list (service-extension
> activation-service-type
> (lambda _
>   #~(mkdir-p 
> "/home/bob/.local/share/gnome-shell")
> (default-value #t
> %desktop-services))
>   (name-service-switch %mdns-host-lookup-nss))
>
> Note the “break-gnome” service.  When the service does not exist,
> everything is fine.  It seems to me that the contents of the directory
> really do not matter after all.

Nice reproducer!

> Now I wonder how this affects the gnome-shell startup, because once the
> upgrade is complete things do work fine.  I wonder if there may be a
> dconf setting that is flipped after initialization.

I see that ‘shell_global_init’ in gnome-shell fiddles with “userdatadir”
(aka. ~/.local/share/gnome-shell).  At first sight it looks like it
should be idempotent, but who knows…  Perhaps we could strace it to see
what happens.

Ludo’.

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

2019-04-23 Thread Miguel 
Hi Julien,

First of all, thank you for your work.

El Tue, 23 Apr 2019 09:28:19 +0200
Julien Lepiller  escribió:
> This is a very good idea, but I think it leaves a stub texi that
> won't get rebuilt because it's younger than po files. 

Yes, you are right indeed. I didn't noticed because I was updating
the .po file manually.

> What if we add a toucgh invocation to reset the modification time
> of these stubs, to ensure make will want to rebuild them?

What about the attached patch? I've just tested it with the other
patch that seems to be missing or blocked by its size, nothing up my
sleeves this time. 0:-)

Best regards,
Miguel
>From fe873d65dd5795bdafc9eed66888f7d2e9bf6b4c Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Miguel=20=C3=81ngel=20Arruga=20Vivas?=
 
Date: Tue, 23 Apr 2019 11:30:32 +0200
Subject: [PATCH 1/4] bootstrap: Break automake dependency on generated files.

* bootstrap: Generate stub files for the manual translations whose
generated files are not included in the VCS.
---
 bootstrap | 14 ++
 1 file changed, 14 insertions(+)

diff --git a/bootstrap b/bootstrap
index cb774bc737..c0b5af7677 100755
--- a/bootstrap
+++ b/bootstrap
@@ -2,4 +2,18 @@
 # Create the build system.
 
 set -e -x
+
+# Generate stubs for translations.
+langs=`find po/doc -type f -name '*.po' \
+| sed -e 's,guix-manual\.,,' \
+| xargs -n 1 -I{} basename {} .po`
+for lang in ${langs}; do
+if [ ! -e "doc/guix.${lang}.texi" ]; then
+	echo "@setfilename guix.${lang}.info" > "doc/guix.${lang}.texi"
+	echo "@include version-${lang}.texi" >> "doc/guix.${lang}.texi"
+	# Ensure .po file is newer.
+	touch "po/doc/guix-manual.${lang}.po"
+fi
+done
+
 exec autoreconf -vfi
-- 
2.21.0

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

2019-04-23 Thread 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: Package request: ZFS

2019-04-23 Thread Pierre Neidhardt 
Hmmm... Pity.
Thanks for the links!

-- 
Pierre Neidhardt
https://ambrevar.xyz/


signature.asc
Description: PGP signature

Re: Problem with `direnv` package definition

2019-04-23 Thread Christopher Baines 

Christopher Baines  writes:

> Tanguy Le Carrour  writes:
>
>> Le 04/20, Christopher Baines a écrit :
>>> Tanguy Le Carrour  writes:
>>> > As I said, I'm still learning. But I've tried, and here is what I've
>>> > done so far […]
>>>
>>> I tried changing the inputs to native-inputs, and the package built for
>>> me. Could you share the exact changes you made?
>>
>> I haven't done much:
>>
>> --- a/gnu/packages/shellutils.scm
>> +++ b/gnu/packages/shellutils.scm
>> @@ -129,12 +129,11 @@ are already there.")
>>   ;; Help the build scripts find the Go language dependencies.
>>   (add-before 'unpack 'setup-go-environment
>> (assoc-ref go:%standard-phases 'setup-go-environment)
>> -(inputs
>> - `(("go" ,go)
>> -   ("go-github-com-burntsushi-toml" ,go-github-com-burntsushi-toml)
>> -   ("go-github-com-direnv-go-dotenv" ,go-github-com-direnv-go-dotenv)))
>>  (native-inputs
>> -  `(("which" ,which)))
>> +  `(("go" ,go)
>> +("go-github-com-burntsushi-toml" ,go-github-com-burntsushi-toml)
>> +("go-github-com-direnv-go-dotenv" ,go-github-com-direnv-go-dotenv)
>> +("which" ,which)))
>>  (home-page "https://direnv.net/;)
>>  (synopsis "Environment switcher for the shell")
>>  (description
>>
>>
>> Thanks again for your time!
>
> What you've put above looks ok, I'm unsure why that wouldn't work...

Just to follow up, as I've learned some more.

So... last night I had this same failure on another machine. Turns out
there is a bigger issue with the direnv package. The particular
combination of the 'setup-go-environment phase from the go-build-system,
and the 'unpack phase from the gnu-build-system, leads to
non-deterministic behaviour, where dependent on the order in which the
filesystem returns two directories, the package either builds, or fails
to build.

> I think it would be better to switch to using the go build system, and
> the package in Guix is quite a few versions behind.

As far as I understand, switching entirely to the go-build-system will
avoid this issue we've both now encountered, so I've sent a patch up
about this [1]. I've also created an issue to track the problem in the
gnu-build-system, as I think it could check for this circumstance and
error, to avoid this issue happening in the future.

1: https://issues.guix.info/issue/35386
2: https://issues.guix.info/issue/35387


signature.asc
Description: PGP signature

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

2019-04-23 Thread Julien Lepiller 
Le 23 avril 2019 02:43:42 GMT+02:00, Miguel  a écrit :
>

This is a very good idea, but I think it leaves a stub texi that won't get 
rebuilt because it's younger than po files. What if we add a toucgh invocation 
to reset the modification time of these stubs, to ensure make will want to 
rebuild them?

Re: ‘staging’ and GNOME updates

2019-04-23 Thread Ricardo Wurmus 


Ricardo Wurmus  writes:

> With this system definition I cannot log into GNOME:
>
> --8<---cut here---start->8---
> (use-modules (gnu) (gnu system nss))
> (use-service-modules desktop xorg)
> (use-package-modules certs gnome)
>
> (operating-system
>   (host-name "antelope")
>   (timezone "Europe/Paris")
>   (locale "en_US.utf8")
>   (keyboard-layout (keyboard-layout "us" "altgr-intl"))
>   (bootloader (bootloader-configuration
> (bootloader grub-efi-bootloader)
> (target "/boot/efi")
> (keyboard-layout keyboard-layout)))
>   (file-systems (cons (file-system
>  (device (file-system-label "my-root"))
>  (mount-point "/")
>  (type "ext4"))
>   %base-file-systems))
>   (users (cons (user-account
> (name "bob")
> (comment "Alice's brother")
> (group "users")
> (supplementary-groups '("wheel" "netdev"
> "audio" "video")))
>%base-user-accounts))
>   (packages (append (list nss-certs gvfs)
> %base-packages))
>   (services (append (list (service gnome-desktop-service-type)
>   (set-xorg-configuration
>(xorg-configuration
> (keyboard-layout keyboard-layout)))
>   (service (service-type
> (name 'break-gnome)
> (extensions
>  (list (service-extension
> activation-service-type
> (lambda _
>   #~(mkdir-p 
> "/home/bob/.local/share/gnome-shell")
> (default-value #t
> %desktop-services))
>   (name-service-switch %mdns-host-lookup-nss))
> --8<---cut here---end--->8---

I used “./pre-inst-env guix system vm broken-gnome-vm.scm” on the
staging branch.  The resulting script needs to be run with “-m 1024” (or
higher) or else GNOME won’t work.

--
Ricardo

Re: ‘staging’ and GNOME updates

2019-04-23 Thread Ricardo Wurmus 


Ludovic Courtès  writes:

> Hello,
>
> Ludovic Courtès  skribis:
>
>> Timothy Sample  skribis:
>>
>>> Ricardo Wurmus  writes:
>>>
 Ludovic Courtès  writes:
> I removed pretty both .cache directories, moved .config sub-directories
> around, etc., and yet I am still unable to log in into the GNOME account
> (logging in to a non-GNOME account from GDM is fine.)
>
> I even tried upgrading the user’s profile just in case is contained
> incompatible schemas or who knows what, but that didn’t help.
>
> What extra bit of state am I missing?

 Do you have ~/.local?  In my earlier tests this contained binary
 notification data that when loaded would lead to a crash.
>>>
>>> I’m testing GNOME on ‘staging’ now, and had the same problem (GDM worked
>>> okay, but I could not login).  I fixed it by deleting
>>> “~/.local/share/gnome-shell/notifications”.  I left everything else in
>>> my home directory as it was.
>>
>> That’s the one!  I moved ~/.local/share/gnome-shell out of the way and
>> after that I could log in.  \o/
>
> So I’d really like to merge that branch, but this GNOME upgrade issue is
> holding us back.
>
> Does anyone have ideas on how to address it?

With this system definition I cannot log into GNOME:

--8<---cut here---start->8---
(use-modules (gnu) (gnu system nss))
(use-service-modules desktop xorg)
(use-package-modules certs gnome)

(operating-system
  (host-name "antelope")
  (timezone "Europe/Paris")
  (locale "en_US.utf8")
  (keyboard-layout (keyboard-layout "us" "altgr-intl"))
  (bootloader (bootloader-configuration
(bootloader grub-efi-bootloader)
(target "/boot/efi")
(keyboard-layout keyboard-layout)))
  (file-systems (cons (file-system
 (device (file-system-label "my-root"))
 (mount-point "/")
 (type "ext4"))
  %base-file-systems))
  (users (cons (user-account
(name "bob")
(comment "Alice's brother")
(group "users")
(supplementary-groups '("wheel" "netdev"
"audio" "video")))
   %base-user-accounts))
  (packages (append (list nss-certs gvfs)
%base-packages))
  (services (append (list (service gnome-desktop-service-type)
  (set-xorg-configuration
   (xorg-configuration
(keyboard-layout keyboard-layout)))
  (service (service-type
(name 'break-gnome)
(extensions
 (list (service-extension
activation-service-type
(lambda _
  #~(mkdir-p 
"/home/bob/.local/share/gnome-shell")
(default-value #t
%desktop-services))
  (name-service-switch %mdns-host-lookup-nss))
--8<---cut here---end--->8---

Note the “break-gnome” service.  When the service does not exist,
everything is fine.  It seems to me that the contents of the directory
really do not matter after all.

Now I wonder how this affects the gnome-shell startup, because once the
upgrade is complete things do work fine.  I wonder if there may be a
dconf setting that is flipped after initialization.

-- 
Ricardo