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

[Translation Project Robot]

Hello, gentle maintainer.

This is a message from the Translation Project robot.

A revised PO file for textual domain 'guix-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.

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

[Translation Project Robot]

Hello, gentle maintainer.

This is a message from the Translation Project robot.

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

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

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

All other PO files for your package are available in:

https://translationproject.org/latest/guix/

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

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

The following HTML page has been updated:

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

If any question arises, please contact the translation coordinator.

Thank you for all your work,

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

Re: ISO installer image: GPT versus MBR partitions

[Danny Milosavljevic]

Hi Thomas,

thanks for the investigative work you are doing.

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

FWIW, I'm all for having a MBR-only Guix installer disk as you suggest.
But I'd rather not do the hack the others are doing.  It's hard enough to
debug this stuff when everyone is playing nice.

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

(I'm surprised that it needs so much manual intervention to make grub-mkrescue
do the right thing.  One of the reasons I chose grub-mkrescue was that I
assumed that its output would boot fine on many different system types--
it being a rescue disk creator and all.  I guess there are tradeoffs to be
made...)


pgpvWAs996Cf8.pgp
Description: OpenPGP digital signature

Re: Trouble getting 'fprintd-service-type' to work

[Danny Milosavljevic]

Hi,

Wed, 24 Apr 2019 20:41:16 +0200
Tobias Geerinckx-Rice  wrote:

> What do you mean?  We don't force GDM on anyone.

My config has slim-service-type and no mention of "gdm" anywhere (unchanged
for more than a year).
I suddenly got gdm when I did "guix system reconfigure"--and it didn't work
to login.  Slim was gone on reboot.
That's why I was fixing gdm in the last few days (bug# 35377).

> I'm still unable to use fprintd at all (I think, I've never used 
> it before):
> 
>   ~ λ fprintd-enroll nckx
>   Using device /net/reactivated/Fprint/Device/0
>   failed to claim device: Not Authorized:
> GDBus.Error:org.freedesktop.PolicyKit1.Error.Failed:
> Action net.reactivated.fprint.device.enroll is not registered
>   ~ λ sudo fprintd-enroll nckx
>   Using device /net/reactivated/Fprint/Device/0
>   failed to claim device: Not Authorized:
> GDBus.Error:org.freedesktop.PolicyKit1.Error.Failed:
> Action net.reactivated.fprint.device.setusername is not 
> registered

Yeah, seems that it also needs a polkit extension.
I've added it to guix master now, as
commit 9374cbd1fb29395a5e849e95e8a249e5f9f944c0.


pgpHtdSoONA8E.pgp
Description: OpenPGP digital signature

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

[Translation Project Robot]

Hello, gentle maintainer.

This is a message from the Translation Project robot.

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

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

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

[Translation Project Robot]

Hello, gentle maintainer.

This is a message from the Translation Project robot.

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

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

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

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

The following HTML page has been updated:

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

If any question arises, please contact the translation coordinator.

Thank you for all your work,

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

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

[Translation Project Robot]

Hello, gentle maintainer.

This is a message from the Translation Project robot.

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

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

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-packages.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 French PO file for 'guix-manual' (version 1.0.0-pre2)

[Translation Project Robot]

Hello, gentle maintainer.

This is a message from the Translation Project robot.

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

https://translationproject.org/latest/guix-manual/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/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: ‘staging’ and GNOME updates

[Timothy Sample]

Ricardo Wurmus  writes:

>> After running GNOME 3.28 for a while, I’ve had several crashes.  It used
>> to crash whenever I opened a URL from Emacs, but fiddling with dconf has
>> fixed that.  It currently crashes every time I run ERC (I’ve turned on
>> notifications there), and I can’t seem to fix it.
>>
>> Interestingly, there is a discussion about this on the Arch Linux forums
>> .  I’m not sure if
>> there’s anything useful for us in there, though.
>
> This message seems relevant:
>
> https://bbs.archlinux.org/viewtopic.php?pid=1778640#p1778640
>
> My issue was caused by using ubuntu-cairo. It was incompatible with
> librsvg 2.42.3, which caused a crash when gnome attempted to load an
> SVG when trying to display the notification. It also caused the
> close window button to not appear in the overview.

I did see this, but I couldn’t really connect it to the problem at hand.
It is interesting that the close window buttons in the overview are a
problem for us, too .

>> It looks like GNOME Shell passes some bad icon data into GTK+, which
>> results in a null filename that gets dereferenced.  (GNOME Shell is not
>> in the backtrace – it tells GTK+ to run this thread from the
>> “load_texture_async” function in “st-texture-cache.c”.
>>
>> I think the “bad” user files are not the root cause here.  There’s
>> definitely something wrong with notifications.  (I just plugged in a USB
>> drive and, sure enough, GNOME Shell crashed.)  The notification daemon
>> code is written in JavaScript (“js/ui/notificationDaemon.js”).  I
>> glanced at it and its Git history, but couldn’t find anything.
>
> I don’t think it’s notifications per se, but rendering SVGs.  When
> application_state exists, GNOME shell tries to restore application
> windows and their icons are likely SVG files that should be rendered.
>
> Chris reported elsewhere that GNOME sometimes crashes when the Activity
> tab is accessed — that’s where the application starter is, which
> displays icons.
>
> I believe we should be using librsvg-next in the closure of gnome-shell.
> We may also want to use gdk-pixbuf+svg instead of just gdk-pixbuf, but
> again replacing librsvg with librsvg-next throughout.  I’m guessing that
> the problem is entirely due to using an outdated variant of librsvg.
>
> What do you think?

To be honest, I don’t know.  From my side, I haven’t seen anything that
suggests SVGs might be the problem.  I just checked an application that
no longer has an icon since the update, and it doesn’t provide an SVG.
On the other hand, Emacs, which does provide an SVG, is fine.  I can’t
find anything in the backtrace that suggests SVG problems either.

That said, software is complicated and this is best lead we have.  Maybe
the crash I’m seeing is fallback code that gets called when SVGs aren’t
quite working.  I did try patching GTK+ the other day (for testing
something else), but gave up when I realized that it means recompiling
WebKitGTK, which takes forever.  I’ll try and patch everything later and
leave my computer to compile overnight.  Or, maybe I could pull Epiphany
out of our GNOME package, and avoid WebKitGTK (now that GNOME Shell
doesn’t need it).  Either way, I will try and test this.  If nothing
else, it might fix the bug linked above.


-- Tim

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

[Translation Project Robot]

Hello, gentle maintainer.

This is a message from the Translation Project robot.

A revised PO file for textual domain 'guix-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: Trouble getting 'fprintd-service-type' to work

[Tobias Geerinckx-Rice]

Danny, all,

Danny Milosavljevic wrote:

I strongly suspect that it still won't work.  According to
, the 
'pam_fprintd.so'

module needs to be added to the PAM configuration.


That is only required if not using gdm.  I think since we force 
gdm now it

should work as-is.


What do you mean?  We don't force GDM on anyone.

I'm still unable to use fprintd at all (I think, I've never used 
it before):


 ~ λ fprintd-enroll nckx
 Using device /net/reactivated/Fprint/Device/0
 failed to claim device: Not Authorized:
   GDBus.Error:org.freedesktop.PolicyKit1.Error.Failed:
   Action net.reactivated.fprint.device.enroll is not registered
 ~ λ sudo fprintd-enroll nckx
 Using device /net/reactivated/Fprint/Device/0
 failed to claim device: Not Authorized:
   GDBus.Error:org.freedesktop.PolicyKit1.Error.Failed:
   Action net.reactivated.fprint.device.setusername is not 
   registered


I'm not using GDM.

Kind regards,

T G-R


signature.asc
Description: PGP signature

Re: bug#35417: Tor Service

[Raghav Gururajan]

Hi,

I think there commands to interact with tor in real-time. The list of commands 
should be available via command "tor --help". :)On 24 Apr 2019 13:02, Julien 
Lepiller  wrote:
>
> Le 24 avril 2019 18:34:22 GMT+02:00, Raghav Gururajan  a 
> écrit : 
> >Hello Guix! 
> > 
> >Including "tor-service-type" does not invoke and add "tor" package into 
> >the system. Without "tor" package, tor commands cannot be used. 
> >Therefore, "tor-service-type" is of little or no use, if it does not 
> >invoke and add "tor" package into the system. 
> > 
> >Regards, 
> >RG. 
>
> Hi, 
>
> What kind of command do you want to run? The tor service runs tor and you can 
> configure, eg. your browser to use it through a socks proxy. So it is of some 
> use :) 

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

[Translation Project Robot]

Hello, gentle maintainer.

This is a message from the Translation Project robot.

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

https://translationproject.org/latest/guix/es.po

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

All other PO files for your package are available in:

https://translationproject.org/latest/guix/

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

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

The following HTML page has been updated:

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

If any question arises, please contact the translation coordinator.

Thank you for all your work,

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

New template for 'guix-packages' made available

[Translation Project Robot]

Hello, gentle maintainer.

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

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

https://translationproject.org/POT-files/guix-packages-1.0.0-pre2.pot

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

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

https://lepiller.eu/files/guix-1.0.0-pre2.tar.gz

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

Thank you for all your work,

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

New template for 'guix-manual' made available

[Translation Project Robot]

Hello, gentle maintainer.

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

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

https://translationproject.org/POT-files/guix-manual-1.0.0-pre2.pot

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

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

https://lepiller.eu/files/guix-1.0.0-pre2.tar.gz

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

Thank you for all your work,

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

Re: Alternative VPN Clients

[Danny Milosavljevic]

Hi,

if you want to package bitmask, you can try:

$ guix import pypi leap.bitmask

This will print a package definition.

You can put it into a file "bitmask.scm" inside the directory 
$GUIX_PACKAGE_PATH (you may have to set that environment variable first) with 
the following header:

(define-module (bitmask)
  #:use-module ((guix licenses) #:prefix license:)
  #:use-module (guix packages)
  #:use-module (guix download)
  #:use-module (guix utils)
  #:use-module (guix build-system python)
  #:use-module (guix gexp)
  #:use-module (gnu packages)
  #:use-module (gnu packages base)
  #:use-module (gnu packages cross-base)
  #:use-module (gnu packages pkg-config)
  #:use-module (gnu packages python)
  #:use-module (gnu packages python-xyz))
(define-public python-leap.bitmask

Then you can try it out with

$ guix build --rounds=2 -K python-leap.bitmask

If there are more packages missing, you can generate them all via:

$ guix import pypi -r leap.bitmask

and also put them in the file, adding "(define-public ..." before each block.

For netsplice, it's very similar--but for some reason their package is not
available on PyPI, so you'd have to write the package definition yourself
(just copy the python-leap.bitmask one and modify it - especially the name,
URL and expected checksum - until it works).

If there are any problems please ask on this list.


pgpeuliV6j9rV.pgp
Description: OpenPGP digital signature

New template for 'guix' made available

[Translation Project Robot]

Hello, gentle maintainer.

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

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

https://translationproject.org/POT-files/guix-1.0.0-pre2.pot

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

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

https://lepiller.eu/files/guix-1.0.0-pre2.tar.gz

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

Thank you for all your work,

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

Re: bug#35417: Tor Service

[Julien Lepiller]

Le 24 avril 2019 18:34:22 GMT+02:00, Raghav Gururajan  a 
écrit :
>Hello Guix!
>
>Including "tor-service-type" does not invoke and add "tor" package into
>the system. Without "tor" package, tor commands cannot be used.
>Therefore, "tor-service-type" is of little or no use, if it does not
>invoke and add "tor" package into the system.
>
>Regards,
>RG.

Hi,

What kind of command do you want to run? The tor service runs tor and you can 
configure, eg. your browser to use it through a socks proxy. So it is of some 
use :)

Re: Trouble getting 'fprintd-service-type' to work

[Danny Milosavljevic]

Hi Mark,

On Sat, 20 Apr 2019 16:21:44 -0400
Mark H Weaver  wrote:

> Thanks, but did you test that it actually works in practice?
> 
> I strongly suspect that it still won't work.  According to
> , the 'pam_fprintd.so'
> module needs to be added to the PAM configuration.

That is only required if not using gdm.  I think since we force gdm now it
should work as-is.

> So, I guess we also need something along the lines of the following,
> which is used in 'elogind-service-type' in (gnu services desktop):
> 
>;; Extend PAM with pam_fprintd.so.
>(service-extension pam-root-service-type
>   pam-extension-procedure)

Yes, but we'd have to amend the etc/pam.d/login file and that
would mean we'd have to add an entire authentication configuration
mechanism to guix (where to allow fingerprint authentication
and where not to allow it is a policy decision done by the
system administrator and should not be hard-coded).

I've found one comment "./sddm.scm: ;; should be factored out into
system-auth" that maybe suggests such a guix configuration already
exists somewhere, but I can't find it.

I'm not sure how to proceed.


pgpHrr80U4zvD.pgp
Description: OpenPGP digital signature

Tor Service

[Raghav Gururajan]

Hello Guix!

Including "tor-service-type" does not invoke and add "tor" package into
the system. Without "tor" package, tor commands cannot be used.
Therefore, "tor-service-type" is of little or no use, if it does not
invoke and add "tor" package into the system.

Regards,
RG.

OpenVPN Client Service

[Raghav Gururajan]

Hello Guix!

Including "openvpn-client-service-type" does not invoke and add
"openvpn" package into the system. Without "openvpn" package, openvpn
client commands cannot be used. Therefore, "openvpn-client-service-
type" is of no use, if it does not invoke and add "openvpn" package
into the system.

Regards,
RG.

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

[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: Alternative VPN Clients

[Joshua Branson]

"Dexter Morgan"  writes:

> Hi All,
>
> My friend introduced me to GNU/Linux and installed GuixSD on my laptop. I am 
> just
> getting started on Bash. I find that there is absence of VPN clients as an 
> alternative to
> OpenVPN. Can some one please package the following alternative VPN clients:

Thanks for mentioning this.

>
> 1) Bitmask: https://bitmask.net/en
>
> 2) Netsplice: https://www.ipredator.se/netsplice
>
> They will also be very useful to other users. :)

Can you try packaging them?  Packaging programs can be a little easier
than you think.  :)  Why don't you give it a try, and if you run into
any issues, you could ask for help?

>
> Thank you.
>

-- 
Joshua Branson
Sent from Emacs and Gnus

Alternative VPN Clients

[Dexter Morgan]

Hi All,

 

My friend introduced me to GNU/Linux and installed GuixSD on my laptop. I am just getting started on Bash. I find that there is absence of VPN clients as an alternative to OpenVPN. Can some one please package the following alternative VPN clients:

 

1) Bitmask: https://bitmask.net/en

 

2) Netsplice: https://www.ipredator.se/netsplice

 

They will also be very useful to other users. :)

 

Thank you.

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

[Julien Lepiller]

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

> 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

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

Also Miguel's solution looks a lot more clean in the bootstrapping
point of view, and I think this is a strong argument in this
community :)

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

Re: Translation of the Guix manual & node names

[pelzflorian (Florian Pelz)]

On Wed, Apr 24, 2019 at 11:24:52AM +0200, Julien Lepiller wrote:
> that only tp/Texinfo/Convert/HTML.pm seems to have translations

I will stop using @ref for everything once info works.  (I only
yesterday learned that translation of HTML works.)

Regards,
Florian

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

[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 French team of translators.  The file is available at:

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

[Thomas Schmitt]

Hi,

Florian Pelz wrote:
> Sorry, I meant to quote this aspect:

I wrote:
> > > One can read trailing garbage not only from USB sticks but also from
> > > most DVD types.

Florian Pelz wrote:
> > So… GPT is wrong for some optical media too?

I wrote:
> Not in this aspect. GPT partitions must not start at block 0.
> So the overall ISO superblock is not mountable as partition and thus
> free to claim the full image size as filesystem size.

I already understood you correctly ... i think. :))

GPT partitioned ISO are not hampered from telling the full image
size as size of the ISO 9660 filesystem.

  $ /sbin/gdisk -l guixsd-install-0.15.0.i686-linux.iso
  ...
  Number  Start (sector)End (sector)  Size   Code  Name
 1  64   34107   16.6 MiB0700  Gap0
 2   34108   39867   2.8 MiB EF00  EFI boot partition
 3   39868 1815727   867.1 MiB   AF00  HFSPLUS
 4 1815728 1816327   300.0 KiB   0700  Gap1

  $ expr $(/sbin/isosize guixsd-install-0.15.0.i686-linux.iso) / 512
  1816376

The isosize is a bit larger than the end of partition 4, because after
this partition comes the GPT backup.
The isosize matches the image file size:

  $ expr $(ls -l guixsd-install-0.15.0.i686-linux.iso | awk '{print $5}') / 512
  1816376


But an MBR partition which begins by block 0 and is mountable as ISO 9660
filesystem keeps its ISO superblock from telling a size larger than the
partition. So it cannot claim an appended partition 2 as part of its range.

  $ export MKRESCUE_SED_MODE=mbr_hfs
  $ grub-mkrescue --xorriso=./grub-mkrescue-sed.sh -o output.iso minimal \
  --iso_mbr_part_type 0x83
  ...

  $ /sbin/fdisk -l output.iso
  ...
  Disklabel type: dos
  ...
  Device  Boot Start   End Sectors  Size Id Type
  output.iso1 *0 28371   28372 13.9M 83 Linux
  output.iso2  28372 341315760  2.8M ef EFI (FAT-12/16/32)

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

This discrepancy of image file size and isosize is undesirable when the
image file itself cannot say its size any more, because it is on USB
stick or a DVD which delivers more bytes than were written as image.

So i propose partition offset 16 to get the partition superblock away
from being mountable by the base device.

  $ export MKRESCUE_SED_MODE=mbr_hfs
  $ grub-mkrescue --xorriso=./grub-mkrescue-sed.sh -o output.iso minimal \
  -partition_offset 16 --iso_mbr_part_type 0x83

This yields

  $ /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)

The ISO filesystem of the overall image then claims the image file size

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

With the partition's ISO filesystem we only get the partition size:

  $ dd if=output.iso bs=512 skip=64 of=partition1.iso

  $ expr $(/sbin/isosize partition1.iso) / 512
  28632

This is how it should be.


The ISOs of Fedora, Debian, Ubuntu, and others are MBR partitioned and
most of them have no partition offset 16. But despite that fact they can
claim the full image size as ISO 9660 filesystem size.

This is possible because partition 1 covers the whole image and partition 2
is located inside partition 1. Strictly illegal in UEFI specs, unless
the outer partition has MBR partition type 0x00 and thus does not exist
for EFI and some partition editors. (I.e. this is a really dirty hack.)

  $ /sbin/fdisk -l debian-live-9.8.0-amd64-xfce.iso
  ...
  Disklabel type: dos
  ...
  DeviceBoot Start End Sectors  Size Id Type
  debian-live-9.8.0-amd64-xfce.iso1 *0 3811391 3811392  1.8G  0 Empty
  debian-live-9.8.0-amd64-xfce.iso2   14322263 832  416K ef EFI 
(FAT-1

  $ expr $(/sbin/isosize debian-live-9.8.0-amd64-xfce.iso) / 512
  3811392

Old /sbin/gdisk only reports partition 2:

  $ /sbin/gdisk -l debian-live-9.8.0-amd64-xfce.iso
  ...
  Found valid MBR and GPT. Which do you want to use?
  ...
  Your answer: 1
  ...
  Number  Start (sector)End (sector)  Size   Code  Name
 214322263   416.0 KiB   EF00  EFI System



Have a nice day :)

Thomas

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

[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 French team of translators.  The file is available at:

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

[pelzflorian (Florian Pelz)]

On Wed, Apr 24, 2019 at 08:56:57AM +0200, Thomas Schmitt wrote:
> Florian Pelz wrote
> > So… GPT is wrong for some optical media too?
> 
> Not in this aspect. GPT partitions must not start at block 0.
> So the overall ISO superblock is not mountable as partition and thus
> free to claim the full image size as filesystem size.
>

Sorry, I meant to quote this aspect:

> > One can read trailing garbage not only from USB sticks but also from
> > most DVD types.
> > […]
> >
> 
> So… GPT is wrong for some optical media too?
> 


> > By the way, someone I know has a most peculiar machine called Lenovo
> > Ideapad 100S which does not boot Guix, […]
> 
> If Guix does not show up in the boot manager, try a plain grub-mkrescue
> image that was made when GRUB was configured for both EFI variations:
> 32 bit x86 and 64 x86.
> My experiments are made when it is configured for those two plus PC-BIOS.
> The EFI partition then has bootx64.efi and bootia32.efi in /efi/boot/.
> 

Will do.

Regards,
Florian

Re: Translation of the Guix manual & node names

[Julien Lepiller]

Le Wed, 24 Apr 2019 10:51:55 +0200,
"pelzflorian (Florian Pelz)"  a écrit :

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

Indeed, you're right. I think it's an issue in texinfo. If you take a
look at po files in po_document in texinfo's sources, you'll notice
that only tp/Texinfo/Convert/HTML.pm seems to have translations
available, but the info manual is generated with
tp/Texinfo/Convert/Info.pm. You'll also notice the Up:, Next: and Prev:
links for instance.

The *Note seems to come from tp/Texinfo/Convert/Plaintext.pm but I'm
not entirely sure.

Re: Translation of the Guix manual & node names

[pelzflorian (Florian Pelz)]

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

Regards,
Florian

Re: ‘staging’ and GNOME updates

[Ricardo Wurmus]

Hey Tim,

>   (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

I have almost exactly the same, except that I used a generated
notifications file (a text file containing the string “garbage”) —
without problems.

> After running GNOME 3.28 for a while, I’ve had several crashes.  It used
> to crash whenever I opened a URL from Emacs, but fiddling with dconf has
> fixed that.  It currently crashes every time I run ERC (I’ve turned on
> notifications there), and I can’t seem to fix it.
>
> Interestingly, there is a discussion about this on the Arch Linux forums
> .  I’m not sure if
> there’s anything useful for us in there, though.

This message seems relevant:

https://bbs.archlinux.org/viewtopic.php?pid=1778640#p1778640

My issue was caused by using ubuntu-cairo. It was incompatible with
librsvg 2.42.3, which caused a crash when gnome attempted to load an
SVG when trying to display the notification. It also caused the
close window button to not appear in the overview.

> It looks like GNOME Shell passes some bad icon data into GTK+, which
> results in a null filename that gets dereferenced.  (GNOME Shell is not
> in the backtrace – it tells GTK+ to run this thread from the
> “load_texture_async” function in “st-texture-cache.c”.
>
> I think the “bad” user files are not the root cause here.  There’s
> definitely something wrong with notifications.  (I just plugged in a USB
> drive and, sure enough, GNOME Shell crashed.)  The notification daemon
> code is written in JavaScript (“js/ui/notificationDaemon.js”).  I
> glanced at it and its Git history, but couldn’t find anything.

I don’t think it’s notifications per se, but rendering SVGs.  When
application_state exists, GNOME shell tries to restore application
windows and their icons are likely SVG files that should be rendered.

Chris reported elsewhere that GNOME sometimes crashes when the Activity
tab is accessed — that’s where the application starter is, which
displays icons.

I believe we should be using librsvg-next in the closure of gnome-shell.
We may also want to use gdk-pixbuf+svg instead of just gdk-pixbuf, but
again replacing librsvg with librsvg-next throughout.  I’m guessing that
the problem is entirely due to using an outdated variant of librsvg.

What do you think?

--
Ricardo

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

[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 French team of translators.  The file is available at:

https://translationproject.org/latest/guix-manual/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/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: Translation of the Guix manual & node names

[Julien Lepiller]

Le Wed, 24 Apr 2019 08:44:14 +0200,
"pelzflorian (Florian Pelz)"  a écrit :

> On Wed, Apr 24, 2019 at 02:11:23AM +0800, Meiyo Peng wrote:
> > 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. 
> 
> I wonder what is correct.  @xref is for “*Note Some section”, @pxref
> is for “*note: Some section“ and @ref is for … “*note: Some section”
> as well?  I started to translate all @xref and @pxref with @ref but it
> still produces the English word “note” in the Info reader.

That's probably because the language is still declared as English. As
soon as you declare the language as something else, these generated
texts should be OK too. If you look at the French po, you will find
this:

#. type: Plain text
#: doc/guix.texi:7
msgid "@documentencoding UTF-8"
msgstr ""
"@documentencoding UTF-8\n"
"@documentlanguage fr\n"
"@frenchspacing on"

@documentlanguage … is what you want to add. @frenchspacing is for
displaying only one space between sentences in generated files which is
the correct way to do it in French.

Maybe we could automate that a bit?

> 
> Regards,
> Florian
> 

Re: Translation of the Guix manual & node names

[Julien Lepiller]

Le 24 avril 2019 09:08:34 GMT+02:00, Meiyo Peng  a écrit :
>Hi Julien,
>
>Julien Lepiller writes:
>
>> 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
>
>The xref_command is too complex for me to understand.  Do you mean we
>don't need to translate all the reference strings in @ref{}, @xref{}
>and
>@pxref{} as long as the target node name after "@node" is translated?
>That will be a good news.

Yes exactly! What this command does is to look for any ref, xref and pxref 
command and look for the translation of its content in the po file for the 
language.

>
>> Also look at fr.po, I haven't translated most of the node names.
>
>By saying "most of the node names" have not been translated, do you
>mean
>some of the reference strings in @ref{}, @xref{} and @pxref{} should be
>translated?

No, sorry for the confusion. At the very beginning we didn't have that command 
so some of the strings have translated references in them, but you shouldn't do 
that anymore.

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

Hi,

Re: Translation of the Guix manual & node names

[Meiyo Peng]

Hi Julien,

Julien Lepiller writes:

> 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

The xref_command is too complex for me to understand.  Do you mean we
don't need to translate all the reference strings in @ref{}, @xref{} and
@pxref{} as long as the target node name after "@node" is translated?
That will be a good news.

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

By saying "most of the node names" have not been translated, do you mean
some of the reference strings in @ref{}, @xref{} and @pxref{} should be
translated?


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

Re: ISO installer image: GPT versus MBR partitions

[Thomas Schmitt]

Hi,

i wrote:
> > > > So programs like /sbin/isosize can tell the image size

> > (The [Debian] layout with nested partitions obsoletes the cleanliness
> >  considerations about partition start at LBA 0.)

Florian Pelz wrote
> So… GPT is wrong for some optical media too?

Not in this aspect. GPT partitions must not start at block 0.
So the overall ISO superblock is not mountable as partition and thus
free to claim the full image size as filesystem size.

The problem of restriction to partition size arises with MBR and
start block 0 of partition 1, when the nested partition mess of
"isohybrid -u" is untangled.


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

If Guix does not show up in the boot manager, try a plain grub-mkrescue
image that was made when GRUB was configured for both EFI variations:
32 bit x86 and 64 x86.
My experiments are made when it is configured for those two plus PC-BIOS.
The EFI partition then has bootx64.efi and bootia32.efi in /efi/boot/.


> It might just not be feasible to please every EFI system.

Let's see how far we get. This research not only helps Guix but also
GRUB. (And it has a tendency to reveal my bugs in xorriso.)


Have a nice day :)

Thomas

Re: Translation of the Guix manual & node names

[pelzflorian (Florian Pelz)]

On Wed, Apr 24, 2019 at 02:11:23AM +0800, Meiyo Peng wrote:
> 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.
>

I wonder what is correct.  @xref is for “*Note Some section”, @pxref
is for “*note: Some section“ and @ref is for … “*note: Some section”
as well?  I started to translate all @xref and @pxref with @ref but it
still produces the English word “note” in the Info reader.

Regards,
Florian