Re: Video narration

[Laura Lazzati]

HI Paul!

I have realized that I have a typo and have to make a minor change in
04-packaging2, that will affect the audio and of course the
transcript. Just wanted to let you know. Will push it ASAP.

Regards :)
Laura

Re: Go build system updates and future work?

[Katherine Cox-Buday]

Leo Famulari  writes:

> I just pushed a revamped Go build system with commit
> e3900a4d64e4bf6f426809d6bff058e5a2ae9bc8.
>
> The main change is that instead of putting the list of Go-language
> dependencies store paths in the GOPATH environment variable, these store
> paths are union-symlinked into the build directory, and GOPATH points
> there.

There is a larger change coming that I think we need to account for. Go
modules are here (and in v1.13 will be on by default). This feature
allows Go code to be built outside of a $GOPATH. I'm unsure how this
information intersects with your work, so I'll just leave a link to the
wiki[1] on modules.

Thank you for your contributions!

[1] - https://github.com/golang/go/wiki/Modules

-- 
Katherine

Re: Improve package search

[mikadoZero]

Tobias Geerinckx-Rice writes:

> ...  Now all we
> need is someone to do the work, but that's the easy part, right?
> ...

I do not yet know enough about Guix or Guile to work on implementing
this.

Re: bug#25453: Keyboard layout configuration

[nee]

> And by the way, an unpleasent off-topic issue:

Hello, thank you for your considerate message. I'm using the my own
domain for email in the future.

Happy hacking!

Re: Status update on 1.0

[Gábor Boskovits]

Hello,

Thompson, David  ezt írta (időpont: 2019.
márc. 15., P, 19:32):
>

> Quick tangent: My memory is a bit fuzzy, but I think that netlink API
> wrappers would put us one step closer to being able to implement
> useful network isolation in our container implementation (right now
> you only have loopback, not so fun), like what Docker can do. Just
> something to consider. :)
>
> - Dave
>

Yes, that is correct. This is exactly one of the reasons I considered this.

Best regards,
g_bor

Re: Status update on 1.0

[Thompson, David]

On Fri, Mar 15, 2019 at 10:33 AM Ludovic Courtès  wrote:
>
> Hi,
>
> Gábor Boskovits  skribis:
>
> > Ludovic Courtès  ezt írta (időpont: 2019. márc. 13., Sze, 
> > 16:21):
> >>
> >> Hello Guix!
> >
> >>   • IPv6 support in ‘static-networking-service’: as discussed at the
> >> Guix Days, we’ll probably need to Linux Netlink sockets to do that
> >> rather than the old ioctls currently used in (guix build syscalls).
> >>
> >> The netlink interface for network config is vaguely documented at
> >> .
> >> Writing bindings for ‘sendmsg’ and the associated data structures
> >> looks reasonable… it just needs to be done.
> >>
> >
> > I am interested in doing this.
>
> Awesome!
>
> > However, there are a few points that needs to be clarified: 1. I came
> > to the same conclusion regarding the netlink stuff, but the old ioctl
> > cannot be fully dropped. (It still provides funcions that are needed
> > to get the netlink working)
>
> Yes, I think we can keep it.
>
> > 2. This might be linux specific. What do we do on other kernels?
> > (It might be reasonable to provide the abstractions in a module, and
> > from there select an available implementation, or signal an error that
> > the functionality is not yet implemented for this system...)
> > Wdyt?
>
> For now, we’ll have to ignore the other kernel.
>
> Longer-term, I suppose we should provide an abstraction over network
> configuration and have it translated to Netlink messages or Hurd RPCs.
>
> > Also a nice low level binding written in C is available as libmnl:
> > https://netfilter.org/projects/libmnl/index.html
>
> Or libnl also.  Though if it’s not too hard, I’d rather have us directly
> bind to ‘sendmsg’, ‘struct msghdr’, and so on.

Quick tangent: My memory is a bit fuzzy, but I think that netlink API
wrappers would put us one step closer to being able to implement
useful network isolation in our container implementation (right now
you only have loopback, not so fun), like what Docker can do. Just
something to consider. :)

- Dave

Re: Status update on 1.0

[Timothy Sample]

Hi,

Ludovic Courtès  writes:

>> GNOME Shell has a handful of silly references like “inkscape” and
>> “webkitgtk” that are huge and (I assume) unnecessary.
>
> Oh indeed.  Inkscape comes from
> 45fef894eb5b39029633cd0cd907e8ce8c5ab379, I’ll look into it.

I’m sure you’ll spot this quickly, but I’ll mention it anyway in case it
saves you a bit of time.

The reference comes in because of the “glib-or-gtk-build-system”.  It
includes Inkscape in “XDG_DATA_DIRS” when it wraps the GNOME Shell
programs.


-- Tim

Re: Guix on the ASUS C201PA

[Timothy Sample]

Hi,

Ludovic Courtès  writes:

> Hello!
>
> Timothy Sample  skribis:
>
>> I was able to get Guix to boot on an ASUS Chromebook C201PA.  This model
>> of computer is pretty neat.  It’s an ARMv7 (32-bit) machine that can be
>> run with entirely free software.  There is even a free graphics driver
>> in the works [1].
>>
>> I’ve attached a (messy) patch that adds a (hacky) bootloader definition
>> for Depthcharge and a Linux-Libre package that works on the machine
>> (using an unsupported version of Linux-Libre).  All those parenthetical
>> comments are supposed to suggest that this work is not really finished.
>> Now that the computer runs Guix, it should be straight-forward (if time
>> consuming) to fix some of these problems and arrive at something nice.
>
> Impressive work!

Thanks!

> The patch is really not what I expected given the qualifiers you gave
> above.  :-)  It could use more comments to explain what’s going on but
> apart from that it looks rather clean to my eyes.
>
> What do you think would be the best course of action to integrate it?
> Wait for Vagrant to test it and fix a couple of things?  ;-)  Or…?

On the bootloader side, if you are okay with the way it works, then it
is fine.  I would just add some comments.  Most importantly, I would
want to write somewhere that it is okay for the bootloader installer to
make use of the configuration file.  Beyond that, there are some
improvements that could be made, but they can come later.  For instance,
we could automatically roll-back one generation if booting fails.

For the kernel, the patch currently uses an unsupported version of
Linux-Libre, which is not great.  I checked that we can switch to the
4.19 version developed by the PrawnOS project.  However, they say that
Wi-Fi is broken on that branch (I don’t have a dongle yet, so I don’t
know).  Parabola has a working 5.0 kernel, but I’ve found that their
configuration is not as reliable as the PrawnOS one (it fails to boot
sometimes).  Ideally, we could figure out which configuration options
and patches are necessary and just augment what we already do, rather
than having a completely separate kernel package.  I’ve tried getting
there by trial and error, but that’s exhausting.  I’m hoping Vagrant’s
setup with the USB serial console will help, but I haven’t tried it yet.

In short, I would rather not rely so closely on what PrawnOS is doing.
It would be better to follow their approach loosely while using our own
kernel versions and configurations.  Does that make sense?


-- Tim

Re: Status update on 1.0

[Mathieu Othacehe]

Hello,

> Mathieu, any idea?  Do you think we could detect it when kmscon fails?
> Or simply avoid it?

For the record, I choose kmscon because it has a good unicode support
contrary to linux VT.

kmscon supports three renderers (on paper):
* fbdev
* drm2d
* drm3d

So I guess the AMD gpu does not provide support for any of those
renderers. If kmscon fails "nicely" by noticing that no renderer can be
use, we could:

Write an installer-vt-service-type service that would:
* Try to run kmscon
* Fallback to mingetty if kmscon start failed

Then the installer would detect on what type of vt it is running and
force "manual install" if it's running on mingetty.

If for any reason kmscon does not exit and hangs,
the installer-vt-service-type could:
* Read some files in sysfs to see if kmscon will be apt to run
* Run kmscon or mingetty

Pierre, could you try to run "kmscon" on your system, from a running
distribution, to see what happens ?

Mathieu

Re: Guix slide video creation

[Laura Lazzati]

Hi Brant!


> Thanks for sharing your git repo with your video assembly code, that was a fun
> read.  I'm working (very lightly) on helping build the occasional guix package
> as time permits and I'd be greatly interested to see your final generated
> videos - are they published anywhere yet?

What a surprise, I am very happy to have received this email :) I am
ccing it to the community so that they know about it  :)
No, they are not published yet, I wish they were, but I am a
perfectionist and have to discuss stuff with the community yet. i  Did
you like them? Getting feedback is very nice, even if there is
constructive criticism to know what to improve.

Thank you very much!
Regards :)
Laura

Re: Video narration

[Paul Garlick]

Hi Laura,

> If you want, you can build them by cloning
> git.savannah.gnu.org/git/guix/videos.git.

I have cloned the repository and built the first video with:

$ ./build-video.sh 03-help

This generates 03-help.webm which I can play with Parole, for example. 
Very nice work!

I can see that there is an 'audios' subdirectory with one audio file
per svg file.  So my task, if I understand correctly, is to move
'audios' to 'audios_laura' and create a new 'audios' subdirectory with
new audio files and then re-build.

On the question of total speaking time, 03-help.webm is about 4 minutes
long.  There are six videos, so is 6x4=24mins a reasonable estimate of
the total speaking time?

Also, are the transcripts available for all the videos?  I will need
these before I go in to do the recordings.

Best regards,

Paul.

Re: librsvg & Rust

[Ivan Petkov]

> On Mar 15, 2019, at 6:39 AM, Marius Bakke  wrote:
> 
>> 
>>> By the way, the next version of librsvg will require Rust 1.33 or
>>> thereabouts.
>> 
>> Oh so we’re lagging already?
> 
> I was referring to the 2.46 series, but indeed 2.44.13 also fails with
> Rust 1.27 (we're at 2.44.12).

I have a working patch ready for packaging 1.33, which I’ll submit after #34820
gets merged, so we won't be behind for long :)

—Ivan

Re: Video narration

[Laura Lazzati]

Hi Paul!

> This generates 03-help.webm which I can play with Parole, for example.
> Very nice work!
Thank you and great! We have another player that plays our videos fine :)

> I can see that there is an 'audios' subdirectory with one audio file
> per svg file.  So my task, if I understand correctly, is to move
> 'audios' to 'audios_laura' and create a new 'audios' subdirectory with
> new audio files and then re-build.
Exactly, The makefile will look for each audio in an audios subdir, so
moving my audios subdir to audios_laura or will make it look for your
audios instead of mine's. And Sth important is to have them named
1.mp3 (or the format that is better), 2.mp3 so that it matches the
slide name.
>
> On the question of total speaking time, 03-help.webm is about 4 minutes
> long.  There are six videos, so is 6x4=24mins a reasonable estimate of
> the total speaking time?
You mean the timing of the total number of final vidoes, right?  I
still have to upload the last part of the last one, will test sth and
do it in a minute.
But most videos are about 3-4 minutes length. So your estimate time
should be right. In fact you will see that some of them have the
number of video duplicated because if not they would last too long.
>
> Also, are the transcripts available for all the videos?  I will need
> these before I go in to do the recordings.
Yes :) if you go, to videos//, ie videos/03-help/ you
should find a file named transcriptHelp.txt with which is said. If
not, let me know because these transcripts should appear for each
video.

Regards :)
Laura

Re: DNS delegation

[Tobias Geerinckx-Rice]

Julien,

Julien Lepiller wrote:
Was it… DNS-01 challenges?  That doesn't even care about IPs at 
all.


Does it mean we need to manually update the zone?


I was about to write ‘no, ha ha, imagine that’, but then I 
remembered that you're using the Guix service configuration 
wrappers which do hard-code the zone data in the system 
configuration :-/


You can always delegate a subdomain just for the ACME challenges, 
though, and have that statefully updated by a certbot hook.  I'm 
being vague because I don't know the exact names, but it's 
completely supported.



How do you automate that process?


Me personally?  RFC-2136 (‘nsupdate’) dynamic updates, allowed 
only from localhost.  But I never use Guix's service configuration 
wrappers.


Kind regards,

T G-R

Re: DNS delegation

[Tobias Geerinckx-Rice]

Ludo', Guix,

Ludovic Courtès wrote:
I think gnu.org/s/guix would redirect to guix.gnu.org, which 
would be
bayfront+berlin.  The issue that remains to be addressed in this 
context
is how to get Certbot to properly renew the certificate given 
that
guix.gnu.org points to two different machines.  IIRC you and 
others had
found a solution, but I don’t remember what it was and it needs 
to be

actually implemented.  :-)


Was it… DNS-01 challenges?  That doesn't even care about IPs at 
all.


I could help set that up with Knot[0] — if Julien even needs help 
;-)


Kind regards,

T G-R

[0]: I also have a package for acme-dns[1] gathering dust, but 
IIRC we're using Knot already.

[1]: https://github.com/joohoi/acme-dns

Re: Status update on 1.0

[Ludovic Courtès]

Hi,

Gábor Boskovits  skribis:

> Ludovic Courtès  ezt írta (időpont: 2019. márc. 13., Sze, 
> 16:21):
>>
>> Hello Guix!
>
>>   • IPv6 support in ‘static-networking-service’: as discussed at the
>> Guix Days, we’ll probably need to Linux Netlink sockets to do that
>> rather than the old ioctls currently used in (guix build syscalls).
>>
>> The netlink interface for network config is vaguely documented at
>> .
>> Writing bindings for ‘sendmsg’ and the associated data structures
>> looks reasonable… it just needs to be done.
>>
>
> I am interested in doing this.

Awesome!

> However, there are a few points that needs to be clarified: 1. I came
> to the same conclusion regarding the netlink stuff, but the old ioctl
> cannot be fully dropped. (It still provides funcions that are needed
> to get the netlink working)

Yes, I think we can keep it.

> 2. This might be linux specific. What do we do on other kernels?
> (It might be reasonable to provide the abstractions in a module, and
> from there select an available implementation, or signal an error that
> the functionality is not yet implemented for this system...)
> Wdyt?

For now, we’ll have to ignore the other kernel.

Longer-term, I suppose we should provide an abstraction over network
configuration and have it translated to Netlink messages or Hurd RPCs.

> Also a nice low level binding written in C is available as libmnl:
> https://netfilter.org/projects/libmnl/index.html

Or libnl also.  Though if it’s not too hard, I’d rather have us directly
bind to ‘sendmsg’, ‘struct msghdr’, and so on.

Thanks,
Ludo’.

Re: Blog post on documentation video creation

[Laura Lazzati]

Bonjour Ludo (and Guix :))

> Thank you, Laura!
No, thank you for encouraging me to give the talk and publish my post :)

Regards :)
Laura

Re: librsvg & Rust

[Marius Bakke]

Ludovic Courtès  writes:

>>> Also, is the new librsvg API-compatible with the old one?  IIUC it still
>>> provides a C API, right?  Does guile-rsvg still work, for example?
>>
>> I have not noticed any regressions since the switch.  The guile-rsvg
>> tests pass, at least!
>
> One test would be to do ‘guix system vm-image --full-boot’ or something,
> to generate the derivation that builds the GRUB background image, which
> uses Guile-RSVG.

OK, good to know.  The background image is fine (I'm using this branch
on real hardware).

>>> What do other distros do?  Debian kept ‘librsvg-c’ around, primarily so
>>> that architectures where Rust isn’t supported yet could still work:
>>> .
>>
>> I wanted to ask about this: is Rust supported on all the platforms we
>> support at the moment?
>
> According to Efraim and Danny, we have a problem at the moment.
> Presumably that can be worked around?

Right, Rust currently only works on x86_64.  In order to get this branch
started, let us either:

* Revert back to 2.40.20, or
* Conditionally use the new version on supported platforms

For the latter, I imagine something along the lines of...

(define-public librsvg
  (if (string-prefix? "x86_64" (or (%current-target-system)
   (%current-system)))
  librsvg-2.44
  librsvg-2.40))

Preferences?

>> While depending on Rust for GTK/GNOME is unfortunate, I do think it's
>> inevitable.
>
> Yeah.
>
>> By the way, the next version of librsvg will require Rust 1.33 or
>> thereabouts.
>
> Oh so we’re lagging already?

I was referring to the 2.46 series, but indeed 2.44.13 also fails with
Rust 1.27 (we're at 2.44.12).


signature.asc
Description: PGP signature

Re: DNS delegation

[Julien Lepiller]

Le 2019-03-15 14:42, Tobias Geerinckx-Rice a écrit :

Ludo', Guix,

Ludovic Courtès wrote:

I think gnu.org/s/guix would redirect to guix.gnu.org, which would be
bayfront+berlin.  The issue that remains to be addressed in this 
context

is how to get Certbot to properly renew the certificate given that
guix.gnu.org points to two different machines.  IIRC you and others 
had

found a solution, but I don’t remember what it was and it needs to be
actually implemented.  :-)


Was it… DNS-01 challenges?  That doesn't even care about IPs at all.


Does it mean we need to manually update the zone? How do you automate
that process?



I could help set that up with Knot[0] — if Julien even needs help ;-)

Kind regards,

T G-R

[0]: I also have a package for acme-dns[1] gathering dust, but IIRC
we're using Knot already.
[1]: https://github.com/joohoi/acme-dns

Re: Status update on 1.0

[pelzflorian (Florian Pelz)]

On Fri, Mar 15, 2019 at 01:57:42PM +0100, Ludovic Courtès wrote:
> Hello,
> 
> "pelzflorian (Florian Pelz)"  skribis:
> 
> > When doing translations, should the English name be kept as a proper
> > name as with GuixSD?  I would prefer to translate it to a German
> > “Guix-System” (with hyphen) to avoid misunderstandings (many Germans
> > would read an English “Guix System” with German pronunciation anyway).
> > For other languages “Guix Système” or maybe “Guix 系统” or so of
> > course does not resemble the guix system command as much anymore.
> 
> When spelled as “Guix System”, it’s a proper noun that should not be
> translated IMO.
> 
> There are also places in the manual, I think, that read “the Guix
> system” or “the standalone Guix system”, etc., and these would of course
> have to be translated.
> 
> Ludo’.

So the proper noun changed from GuixSD to Guix System, but Guix used
as an OS still has its own proper noun distinct from “the Guix
system”.  OK, got it.  I will distinguish “Guix System” and “das
Guix-System“.

Thank you!

Regards,
Florian

Re: Status update on 1.0

[Ludovic Courtès]

Hi Timothy,

Timothy Sample  skribis:

> Ludovic Courtès  writes:

[...]

>>   • GDM works well for GNOME and WMs that provide a .session file.
>> However it still doesn’t honor ~/.xsession.  We discussed it before
>> and dropped the ball.  Timothy, what’s missing?  I’d really like to
>> make it the default.
>
> Nothing is missing!  As promised [1], in the last patch series I made
> GDM run our custom “xinitrc” script instead of the built-in one.  This
> happened in commit 41fa9f1815685ede0d3fdc1c561d2a9cf0ffb158.  :)
>
> (I tested this now to be absolutely sure, and it works like a charm.)

Oh, awesome!  I keep forgetting about all the good things that happen.
:-)

> Yes.  We should be working on “guix size gnome-shell”.  It more
> accurately reflects the size of GDM, and (I hope you’re sitting down) it
> weighs in at 2GiB!
>
> Fortunately, it looks like we could claw back ~400MiB by (somehow)
> dropping “hplip-minimal”.  It gets pulled in through the path
>
> gdm → gnome-settings-daemon → colord → sane-backends →
> hplip-minimal.
>
> We almost certainly don’t need it for GDM.  I guess removing it means
> making a version of “colord” without “sane-backends”.  It was introduced
> in commit 4c9287432824f396d5c614c3b2287f553cd9fb90.  I’ll look into
> this.

Cool!  That’d already be an improvement.

> GNOME Shell has a handful of silly references like “inkscape” and
> “webkitgtk” that are huge and (I assume) unnecessary.

Oh indeed.  Inkscape comes from
45fef894eb5b39029633cd0cd907e8ce8c5ab379, I’ll look into it.

> There seems to be a handful of easy wins.  I would be surprised if we
> could get the closure of “gnome-shell” below 1GiB, but we will see.
> Also, keep in mind that a lot of these bytes will be recycled.  For
> instance, GTK+ 3 is ~700MiB, and chances are there will be at least one
> GTK+ 3 application besides GDM.

Yes, sure.

Thanks,
Ludo’.

Re: Status update on 1.0

[Pierre Neidhardt]

> They should still support VESA, no?

Yes they do.

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


signature.asc
Description: PGP signature

Re: librsvg & Rust

[Ludovic Courtès]

Hello!

Danny Milosavljevic  skribis:

> http://hydra.gnu.org/build/3385267/nixlog/3/raw seems to be the latest
> armhf-linux build attempt on master and it says:
>
> building of `/gnu/store/xqwkq4hvc3wq7pvx4fcj3sws55zp64b7-rust-1.19.0.drv' 
> timed out after 3600 seconds of silence
>
> However, rust-1.19 on master has:
>
> (properties '((timeout . 72000)   ;20 hours
>   (max-silent-time . 18000))) ;5 hours (for armel)
>
> Why does it already time out after 3600 seconds of silence although it's 
> configured to stand 18000 seconds of silence?

Note that these properties are ignored by Cuirass, and I believe there
can be cases on Hydra where it’s not honored either (e.g., if
‘rust-1.19’ is built has a dependency of another job.)

Ludo’.

Re: librsvg & Rust

[Ludovic Courtès]

Hi!

Marius Bakke  skribis:

> Ludovic Courtès  writes:
>
>> Hello Guix!
>>
>> guix-comm...@gnu.org skribis:
>>
>>> mbakke pushed a commit to branch staging
>>> in repository guix.
>>>
>>> commit ec47c07d0690653be35a75b346f3c3548a3e71d4
>>> Author: Marius Bakke 
>>> Date:   Wed Oct 24 15:26:10 2018 +0200
>>>
>>> gnu: librsvg: Update to 2.44.12.
>>> 
>>> * gnu/packages/gnome.scm (librsvg): Update to 2.44.12.
>>> [arguments]: Replace patching phases with custom variants.  Delete five 
>>> new
>>> tests.
>>> [native-inputs]: Add RUST-1.27 and RUST-1.27:CARGO.
>>
>> This change was bound to happen since upstream switched to Rust, but
>> it creates a few issues.
>>
>> First, that adds Rust to the base graphical applications, which
>> significantly increases build times and size:
>>
>> --8<---cut here---start->8---
>> $ guix size librsvg | tail -1
>> total: 207.2 MiB
>> $ guix size librsvg rust | tail -1
>> total: 1052.9 MiB
>> --8<---cut here---end--->8---
>>
>> Perhaps the size issue can be somewhat mitigated by adding a “lib”
>> output to the Rust package, but even then it would probably still be an
>> issue.
>
> Librsvg does not depend on Rust at run-time, so the closure size should
> be similar.  However I notice it has a 129MiB (!!) librsvg-2.a, which
> should be removed.  I will do that later.

OK, good.

>> Also, is the new librsvg API-compatible with the old one?  IIUC it still
>> provides a C API, right?  Does guile-rsvg still work, for example?
>
> I have not noticed any regressions since the switch.  The guile-rsvg
> tests pass, at least!

One test would be to do ‘guix system vm-image --full-boot’ or something,
to generate the derivation that builds the GRUB background image, which
uses Guile-RSVG.

>> What do other distros do?  Debian kept ‘librsvg-c’ around, primarily so
>> that architectures where Rust isn’t supported yet could still work:
>> .
>
> I wanted to ask about this: is Rust supported on all the platforms we
> support at the moment?

According to Efraim and Danny, we have a problem at the moment.
Presumably that can be worked around?

> While depending on Rust for GTK/GNOME is unfortunate, I do think it's
> inevitable.

Yeah.

> By the way, the next version of librsvg will require Rust 1.33 or
> thereabouts.

Oh so we’re lagging already?

Thanks,
Ludo’.

Blog post on documentation video creation

[Ludovic Courtès]

Hello Guix!

Laura wrote about what she’s worked on as an Outreachy intern together
with Björn, Gábor, and Ricardo:

  https://gnu.org/software/guix/blog/2019/documentation-video-creation/

If you missed Laura’s talk at the Guix Days, here’s your chance to learn
more about it.

Thank you, Laura!

Ludo’.

Re: DNS delegation

[Ludovic Courtès]

Hi Julien,

Julien Lepiller  skribis:

> Le 2019-03-13 16:00, Ludovic Courtès a écrit :
>> Hi Julien,
>>
>> Julien Lepiller  skribis:
>>
>>> we've already discussed that multiple times, we'd like to have a DNS
>>> delegation for guix.gnu.org, so that we can manage the zone ourselves
>>> without having to rely too much on fsf sysadmins.
>>>
>>> Here is a patch (untested) that aims at doing that. I've configured
>>> bayfront and berlin to be DNS authoritative servers. bayfront is the
>>> master (it is the one that needs to be updated when a change
>>> happens in
>>> the zone), and berlin is set as slave (it will automatically follow
>>> changes in bayfront). I've enabled dnssec on bayfront, since it's the
>>> one that's going to sign the zone, and transfer signatures to its
>>> slave.
>>
>> Cool, thanks for working on it!
>>
>>> Currently the zone (in modules/sysadmin/dns.scm) is incomplete. What
>>> needs to be there?
>>
>> I guess we’d need to have roughly the same entries as we currently have
>> on guix.info, so what you wrote is a good start and we can always
>> adjust
>> later.
>>
>>> From 331a85e469579c02a3fc338a6fb0bade3916c666 Mon Sep 17 00:00:00 2001
>>> From: Julien Lepiller 
>>> Date: Mon, 4 Mar 2019 22:00:22 +0100
>>> Subject: [PATCH] hydra: Add dns services for guix.gnu.org.
>>>
>>> * hydra/bayfront.scm (services): Add knot-service.
>>> * hydra/berlin.scm (services): Add knot-service.
>>> * hydra/modules/sysadmin/dns.scm: New file.
>>
>> So it looks like this does the work on the Guix side.
>>
>> We now need to get the gnu.org admins to delegate to both bayfront and
>> berlin, is that correct?  Anything else we need to do?
>
> I didn't think too much about it, but we need to host the website
> (guix.gnu.org) somewhere and configure a vhost/server block accordingly,

Yes, but that’s once DNS is appropriately set up.  I was asking about
what needs to be done to complete the DNS setup.

> unless gnu.org/software/guix stays the official website?

I think gnu.org/s/guix would redirect to guix.gnu.org, which would be
bayfront+berlin.  The issue that remains to be addressed in this context
is how to get Certbot to properly renew the certificate given that
guix.gnu.org points to two different machines.  IIRC you and others had
found a solution, but I don’t remember what it was and it needs to be
actually implemented.  :-)

Thoughts?

Ludo’.

Re: Status update on 1.0

[Ludovic Courtès]

Hello!

Tobias Geerinckx-Rice  skribis:

> Ludovic Courtès wrote:
>>   • The graphical installer has been merged (yay!) but we still
>> need to
>> discuss it in the manual and to test it some more.
>
> The last time I tried the installer it didn't work on AMD(GPU) cards.
> I'll give it another go.

Was that because of kmscon?

In the meantime I worked a bit on the “System Installation” section to
have a new “Guided Graphical Installation” subsection and to move the
bits that were previously under “Manual Installation”:

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

>>  • “GuixSD” has been removed from the web site and from almost  all
>> of
>>the source code.  Still need to fix the file names thatappear
>> in
>>Makefile.am.
>
> Sounds trivial enough (hah) for me to do this evening, but then that's
> true for anybody.

I ended up doing that:

  
https://git.savannah.gnu.org/cgit/guix.git/commit/?id=13f62aef2d87dc888f89fea3260eaa39938e6640

Yeah I know, I picked the easy tasks.  :-)

>>   • I think we should add ‘guix install’, ‘guix remove’, and   ‘guix
>> upgrade’.
>
> Hmmm… m.  What would these do?

Basically aliases for ‘guix package -i’ etc.

Ludo’.

Re: Status update on 1.0

[Ludovic Courtès]

Pierre Neidhardt  skribis:

> Danny Milosavljevic  writes:
>
>> Or find out why on earth KMSCON needs the prorietary amdgpu kernel module.
>>
>> It's not exactly 3D graphics, so what is going on?  Furthermore, vesafb 
>> should
>> always work regardless (if slowly, but who cares).
>
> Simply because modern AMD cards don't support KMS without the
> proprietary kernel module (yet).

They should still support VESA, no?

Mathieu, any idea?  Do you think we could detect it when kmscon fails?
Or simply avoid it?

Ludo’.

Re: Status update on 1.0

[Ludovic Courtès]

Hello,

"pelzflorian (Florian Pelz)"  skribis:

> When doing translations, should the English name be kept as a proper
> name as with GuixSD?  I would prefer to translate it to a German
> “Guix-System” (with hyphen) to avoid misunderstandings (many Germans
> would read an English “Guix System” with German pronunciation anyway).
> For other languages “Guix Système” or maybe “Guix 系统” or so of
> course does not resemble the guix system command as much anymore.

When spelled as “Guix System”, it’s a proper noun that should not be
translated IMO.

There are also places in the manual, I think, that read “the Guix
system” or “the standalone Guix system”, etc., and these would of course
have to be translated.

Ludo’.

Re: Guix on the ASUS C201PA

[Ludovic Courtès]

Hello!

Timothy Sample  skribis:

> I was able to get Guix to boot on an ASUS Chromebook C201PA.  This model
> of computer is pretty neat.  It’s an ARMv7 (32-bit) machine that can be
> run with entirely free software.  There is even a free graphics driver
> in the works [1].
>
> I’ve attached a (messy) patch that adds a (hacky) bootloader definition
> for Depthcharge and a Linux-Libre package that works on the machine
> (using an unsupported version of Linux-Libre).  All those parenthetical
> comments are supposed to suggest that this work is not really finished.
> Now that the computer runs Guix, it should be straight-forward (if time
> consuming) to fix some of these problems and arrive at something nice.

Impressive work!

The patch is really not what I expected given the qualifiers you gave
above.  :-)  It could use more comments to explain what’s going on but
apart from that it looks rather clean to my eyes.

What do you think would be the best course of action to integrate it?
Wait for Vagrant to test it and fix a couple of things?  ;-)  Or…?

Thank you,
Ludo’.

Texlive: Asymptote error: Math formula deleted: Insufficient symbol fonts.

[Pierre Neidhardt]

Asymptote fails to build.  It used to be working on master 2-3 weeks ago
I think.

--8<---cut here---start->8---
starting phase `install'
...

(./asy-latex.dtx
! Math formula deleted: Insufficient symbol fonts.
\endtabular ->\crcr \egroup \egroup $
 \egroup 
l.60 % \maketitle
 
? 
! Emergency stop.
--8<---cut here---end--->8---

There has been some change in existing TeX packages recently, so I
suspect this has to do with it.  I gave it a quick try but couldn't
figure the issue yet.

Anyone?

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


signature.asc
Description: PGP signature

Re: Splitting mkvtoolnix outputs: cycle detected in the references

[Pierre Neidhardt]

Thanks for the explanation.

I looked into this again and realized I had missed the obvious: I had forgotten
to move the .desktop file! :)

Problem solved, mkvtoolnix is now down by 1.2 GB! :D

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


signature.asc
Description: PGP signature