Re: Package request: ZFS

2019-04-22 Thread Mark H Weaver
Hi Pierre,

Pierre Neidhardt  writes:

> Now that we have support for linux module packages (thanks to Danny),
> can we get ZFS to work on Guix?
>
>   https://zfsonlinux.org/

Probably not, because ZFS and Linux use incompatible licenses.  IANAL,
but my understanding is that they impose conflicting requirements on
distributors of derived works.  Here are some relevant links to explain
the details:

  https://sfconservancy.org/blog/2016/feb/25/zfs-and-linux/
  https://sfconservancy.org/blog/2016/apr/11/fsf-zfs/
  https://www.fsf.org/licensing/zfs-and-linux

  Mark



[PATCH 0/2] Removal of generated files (was Re: Let’s translate!)

2019-04-22 Thread Miguel
Hello everybody!

I'm currently working on the Spanish translation for the manual,
although I will send the guix domain translation as soon as TP
coordinators change the assignation.

Regarding the translation process, I think we should remove, at least,
the generated files from the repository. AFAIK the only show-stopper is
automake. It reads the translated files before make invocation, so the
manual .texi files are needed for the bootstrap, even though they are
listed in BUILT_SOURCES. guix/self.scm scan their content too in order
to generate version-LL.texi. Stubs could be generated before calling
autoreconf inside bootstrap script.

After that change, adding the spanish (or any new) translation should be
only matter of applying a patch like the second one, but with more
translated content...

WDYT? Any ideas about automated synchronization with
translationproject.org as make update-po does?

Best regards,
Miguel



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

2019-04-22 Thread Miguel
>From c5ed65b04c412a97674dd9129a0cac10500fdf7a Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Miguel=20=C3=81ngel=20Arruga=20Vivas?=
 
Date: Tue, 23 Apr 2019 00:21:44 +0200
Subject: [PATCH 1/2] 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 | 12 
 1 file changed, 12 insertions(+)

diff --git a/bootstrap b/bootstrap
index cb774bc737..62f6cb0fab 100755
--- a/bootstrap
+++ b/bootstrap
@@ -2,4 +2,16 @@
 # 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"
+fi
+done
+
 exec autoreconf -vfi
-- 
2.21.0



Re: 01/05: build-self: Avoid deprecated bindings.

2019-04-22 Thread Mark H Weaver
Ludovic Courtès  writes:

> guix-comm...@gnu.org skribis:
>
>> commit fa9e6e8b676ca920a894cf3b48bfcb670077144f
>> Author: Mark H Weaver 
>> Date:   Sun Apr 21 13:58:08 2019 -0400
>>
>> build-self: Avoid deprecated bindings.
>> 
>> * build-aux/build-self.scm (build): Replace references to nix-server-*
>> with store-connection-*.
>
> I reverted this commit because by using the new bindings, we would
> prevent users of Guix prior to de9fbe9cdcf5f8deb08becfc54b523084fd67bda,
> such as version 0.16.0, to upgrade to current master.

Ah, okay, sorry for the mistake.  It might be worth adding a comment to
the code, explaining why the deprecated names must be used.

> Note that commit 3a8c4860fbccc840b28227dbe44cfffb128a91e0 took care of
> silencing deprecation warnings coming from build-self.scm for this
> reason.

Sounds good.  Thanks!

 Mark



Re: 01/05: build-self: Avoid deprecated bindings.

2019-04-22 Thread Ludovic Courtès
Hi Mark,

guix-comm...@gnu.org skribis:

> commit fa9e6e8b676ca920a894cf3b48bfcb670077144f
> Author: Mark H Weaver 
> Date:   Sun Apr 21 13:58:08 2019 -0400
>
> build-self: Avoid deprecated bindings.
> 
> * build-aux/build-self.scm (build): Replace references to nix-server-*
> with store-connection-*.

I reverted this commit because by using the new bindings, we would
prevent users of Guix prior to de9fbe9cdcf5f8deb08becfc54b523084fd67bda,
such as version 0.16.0, to upgrade to current master.

We will have to keep using the old names in this file for a while.

This file is a bit special in that we have to assume that it can be
evaluated by an old Guix.

Note that commit 3a8c4860fbccc840b28227dbe44cfffb128a91e0 took care of
silencing deprecation warnings coming from build-self.scm for this
reason.

Thanks,
Ludo’.



Re: Video narration

2019-04-22 Thread Paul Garlick
Hi Laura,

> I deleted all the videos and made them again
> and now I don't see that issue anymore.

Ah, good news!

> For this, what I could do is generate the cli sesison video with the
> "silence1.mp3" to have duration1, and then compare it with the
> duration of cli1.mp3 (for instance).  Then, run a script comparing
> the durations while duration2 < duration1 append silence1.mp3 to
> cli1.mp3.  And finally use the generated cli1.mp3 as the input
> matching the video stream.
> I find a little bit manual, but I don't mind doing it if you find it
> OK.
> WDYT?

We may have to experiment a little to solve the question of combining
the cli and nocli videos in a manner than can be replayed by
Firefox/Icecat.

One test I can try tomorrow is to concatenate the nocli videos on their
own.  Will the combined video play in Firefox?  If so, it would suggest
that the mismatch of the audio and video stream durations is the cause
of the stoppage.  

There is a way to concatenate audio files with ffmpeg.  So if we know
we need an extra  seconds of silence, say, we can generate the file
with the command I previously posted and join the silence to the end of
the narration.

This would be a script-free alternative method.

Best regards,

Paul.




QEmu image configuration

2019-04-22 Thread Vincent Legoll
Hello,

I've been trying to find the system config.scm used to
generate the QEmu image (0.16.0 from the download
page). I searched inside the booted VM, and tried to
get clues from the documentation. I couldn't find it.

What am I missing ?

Shouldn't it be put in the VM image at /etc/config.scm ?

I finally managed to get the image working, but had to
guess a bit how to do it, I think the doc could be enhanced,
so that newbies like me won't get lost.

I tried to have a look at where is the source for :
"6.2.14 Running GuixSD in a Virtual Machine"
But the guix/doc/guix.texi text I found in the git repo
looked different from what I read on the web site:
https://www.gnu.org/software/guix/manual/en/html_node/Running-GuixSD-in-a-VM.html

Are they out of sync ? Or is the web manual rendered
from an older version of that file ?

Thanks

-- 
Vincent Legoll



Re: Video narration

2019-04-22 Thread Laura Lazzati
Hi Paul!

> This plays at the right speed for me in Videos/Totem (version 3.26).
Don't know what happened. I deleted all the videos and made them again
and now I don't see that issue anymore.
>

> duration1 (video stream):  1 minute 29 seconds
> duration2 (audio stream):  1 minute 18 seconds
>
> This difference may be treated in a different manner by different
> players.  It may be necessary to add silence to the audio stream to
> equalize the durations and allow reliable concatenation without re-
> encoding.
For this, what I could do is generate the cli sesison video with the
"silence1.mp3" to have duration1, and then compare it with the
duration of cli1.mp3 (for instance).  Then, run a script comparing the
durations while duration2 < duration1 append silence1.mp3 to cli1.mp3.
And finally use the generated cli1.mp3 as the input matching the video
stream.
I find a little bit manual, but I don't mind doing it if you find it OK.
WDYT?

Regards :)
Laura



Re: KMScon vs. AMD Radeon

2019-04-22 Thread pelzflorian (Florian Pelz)
On Mon, Apr 22, 2019 at 01:48:52PM +0200, pelzflorian (Florian Pelz) wrote:
> As before, when I do not specify modprobe.blacklist=radeon, the
> display gets stuck with
> 
> [   8.679377] fb0: switching to radeondrmfb from EFI VGA
> 
> Before, I could add modprobe.blacklist=radeon to boot to a console.
> 

When I boot the Debian 9.8.0 live ISO, I get a working fbdev with
these messages in /var/log/Xorg.0.log

[11.795] (**) FBDEV(2): claimed PCI slot 1@0:0:0
[…]
[11.795] (II) FBDEV(0): hardware: EFI VGA (video memory: 1984kB)

These messages are missing on Guix (instead, I get
[45.884] (EE) Screen 0 deleted because of no matching config section.
where Debian has successfully found a screen.


Before these messages, I see on Guix:

[43.781] (--) PCI:*(1@0:0:0) 1002:6613:1043:0541 rev 0, Mem @ 
0xe000/268435456, 0xf7e0/262144, I/O @ 0xe000/256, BIOS @ 
0x/131072

On Debian, I see:

[11.702] (--) PCI:*(0:1:0:0) 1002:6613:1043:0541 rev 0, Mem @ 
0xe000/268435456, 0xf7e0/262144, I/O @ 0xe000/256, BIOS @ 
0x/131072


I wonder, where does this difference in the PCI message come from?



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

2019-04-22 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 Spanish team of translators.  The file is available at:

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

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

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

The following HTML page has been updated:

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

If any question arises, please contact the translation coordinator.

Thank you for all your work,

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





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

2019-04-22 Thread Translation Project Robot
Hello, gentle maintainer.

This is a message from the Translation Project robot.

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

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

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-manual.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: ISO installer image: GPT versus MBR partitions

2019-04-22 Thread Thomas Schmitt
Hi,

Ady Ady gave me a hint about why the EFI partition in Guix 0.16.0 ISO
has 1.4 MB of size, despite grub-mkrescue asks mformat for 2.8 MB.

Obviously Guix uses mtools 4.0.21 (image OEM-ID "MTOO4021") which is one
version before this bug fix:
  "Fixed -f flag for mformat (size is KBytes, rather than sectors)"
  http://lists.gnu.org/archive/html/info-gnu/2018-12/msg0.html

(Actually this size is quite some waste. Even 1.4 MB is generously
 oversized for the three directories and one or two boot*.efi.)


Have a nice day :)

Thomas




Re: Video narration

2019-04-22 Thread Paul Garlick
Hi Laura, 

> Now, as regards the colours, it works with totem too :)
> But the cli sessions are at kind of super speed now, it happens
> watching the full video, or the separate cli session videos. I've
> tried it with totem, mvp and vlc. Any clue about it?

I have not seen this effect on the playback speed.  I am using the
first video for testing.  I do:

$  make clean VIDEO=01-installation-from-script

then,

$ ./build-video.sh 01-installation-from-script

This plays at the right speed for me in Videos/Totem (version 3.26).

However, the concatenation question (for Firefox) may also be related
to the speed question.  Is super-speed very different from the expected
speed?  In the case of the first cli session for the first video there
is a difference between the duration of the audio and video streams:

duration1 (video stream):  1 minute 29 seconds
duration2 (audio stream):  1 minute 18 seconds

This difference may be treated in a different manner by different
players.  It may be necessary to add silence to the audio stream to
equalize the durations and allow reliable concatenation without re-
encoding.

Best regards,

Paul.




Package request: ZFS

2019-04-22 Thread Pierre Neidhardt
Hi,

Now that we have support for linux module packages (thanks to Danny),
can we get ZFS to work on Guix?

  https://zfsonlinux.org/

Any taker?

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


signature.asc
Description: PGP signature


Re: KMScon vs. AMD Radeon

2019-04-22 Thread pelzflorian (Florian Pelz)
On Sat, Apr 20, 2019 at 02:37:00PM +0200, Pierre Neidhardt wrote:
> OK, apparently it's possible to force AMDGPU onto Southern Island / Sea
> Island:
> 
> https://wiki.archlinux.org/index.php/AMDGPU#Enable_Southern_Islands_(SI)_and_Sea_Islands_(CIK)_support
> 

It seems like this does not help.


> We'd need to things:
> 
> - enable the following in linux-libre
> 
> --8<---cut here---start->8---
> # CONFIG_DRM_AMDGPU_SI is not set
> # CONFIG_DRM_AMDGPU_CIK is not set
> --8<---cut here---end--->8---
> 
> - Make sure amdgpu is loaded before radeon.  Can we do that in the
>   operating-system declaration?
> 

I added the above definitions

---
 gnu/packages/linux.scm | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/gnu/packages/linux.scm b/gnu/packages/linux.scm
index b562a23b2f..0173176be3 100644
--- a/gnu/packages/linux.scm
+++ b/gnu/packages/linux.scm
@@ -275,7 +275,9 @@ for ARCH and optionally VARIANT, or #f if there is no such 
configuration."
 ("CONFIG_VIRTIO_MMIO" . m)
 ("CONFIG_FUSE_FS" . m)
 ("CONFIG_CIFS" . m)
-("CONFIG_9P_FS" . m)))
+("CONFIG_9P_FS" . m)
+("CONFIG_DRM_AMDGPU_SI" . #t)
+("CONFIG_DRM_AMDGPU_CIK" . #t)))
 
 (define (config->string options)
   (string-join (map (match-lambda
-- 
2.21.0
 
and changed nothing about the modules and their ordering.  Then I
reconfigured.

As before, when I do not specify modprobe.blacklist=radeon, the
display gets stuck with

[   8.679377] fb0: switching to radeondrmfb from EFI VGA

Before, I could add modprobe.blacklist=radeon to boot to a console.

Now I add modprobe.blacklist=radeon and get

[   9.507629] fb0: switching to amdgpudrmfb from EFI VGA

It seems like now it is still broken just with amdgpu instead.

Regards,
Florian



Re: ‘staging’ and GNOME updates

2019-04-22 Thread Ludovic Courtès
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?

Thanks,
Ludo’.



Re: KMScon vs. AMD Radeon

2019-04-22 Thread Pierre Neidhardt
Ludovic Courtès  writes:

> Pierre Neidhardt  skribis:
>> https://wiki.archlinux.org/index.php/AMDGPU#Enable_Southern_Islands_(SI)_and_Sea_Islands_(CIK)_support
> ...
> No, how would you achieve that?

No clue, I just know that on Arch Linux there is a mechanism for loading modules
with a specific order (see previous link).

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


signature.asc
Description: PGP signature