Re: X/GDM fails on linux 5.0.7 AMD Radeon RX 580 after system reconfigure

[ison]

Sorry I neglected to mention that I actually tried upgrading mesa earlier and it
didn't resolve the problem. Neither upgrading mesa (I tried 18.3.6 and some 19.*
version) nor downgrading (back to 18.3.1) would fix it, all rebuilds still
resulted in artifacts. I suppose it's because the dependency on llvm 7 remained
fixed during all the rebuilds.

I also just tried llvm 8.0.0 and it still had the same issue.

Re: X/GDM fails on linux 5.0.7 AMD Radeon RX 580 after system reconfigure

[Danny Milosavljevic]

On Thu, 9 May 2019 19:59:17 -0600
ison  wrote:

> Thanks for helping to narrow down the issue. Although I'm not sure where to go
> from here.

Maybe try mesa 18.3.6, maybe someone fixed it there already.
Apparently there's also mesa 19.0.4.
If it can't be fixed otherwise, we can compile the old mesa with llvm 6.


pgpffMyldhC6m.pgp
Description: OpenPGP digital signature

Re: X/GDM fails on linux 5.0.7 AMD Radeon RX 580 after system reconfigure

[ison]

I think you're right. I just tried different versions of llvm with the game
minetest (testing with minetest now since it compiles much faster than mpv)

Trying with llvm@7.0.1 using the command:
guix environment --ad-hoc minetest --with-input=llvm=llvm@7.0.1
results in the same corrupt video issue

Trying with llvm@6.0.1 using the command:
guix environment --ad-hoc minetest --with-input=llvm=llvm@6.0.1
results in no corruption and a fully functioning game

Thanks for helping to narrow down the issue. Although I'm not sure where to go
from here.

Re: X/GDM fails on linux 5.0.7 AMD Radeon RX 580 after system reconfigure

[Danny Milosavljevic]

Might be related to LLVM because it's sometimes used by shader compilers.


pgpvxm1cinyET.pgp
Description: OpenPGP digital signature

Re: X/GDM fails on linux 5.0.7 AMD Radeon RX 580 after system reconfigure

[ison]

I can confirm this exact same issue with the same video card, RX 580, and my
last attempt to update pulled in kernel 5.0.13. When the login screen shows up
the screen is horribly corrupt, nothing is even recognizable as being a part of
the normal login screen, just random colored lines all over the screen.
I first experienced the issue at the release of Guix v1.0.0, but wasn't sure if
I should wait before reporting since I couldn't be sure if it was a guix
specific issue or something else.

Here is what I have discovered:
* I doubt the issue is either caused by GDM itself or the kernel, because after
  updating from a working generation (but without restarting my machine) if I
  attempt to play a video in mpv (or start a game) the same graphical artifacts
  appear, but only in that 1 window.
* I have attempted to upgrade individual applications while using
  "package-input-rewriting" to replace their dependencies on Mesa 18.3.5 with
  18.3.1 (the version they're using on my working generation) and I can confirm
  that the replacement succeeded with "ldd", however they still receive
  graphical artifacts.
* I have successfully managed to run an updated copy of mpv without artifacts by
  using LD_PRELOAD to force it to point to the exact copy of libGL.so.1 used by
  mpv on my working generation.

This leads me to believe that the problem lies somewhere in Mesa (which contains
libGL.so.1). However, the issue doesn't seem to be just the version of Mesa
since mpv still had corrupt video when built to use the older version of Mesa,
but had no corrupt video when forced to link to the exact copy of libGL.so.1
from a previously working generation.

Note: mpv was merely used as a test so I didn't have to constantly restart my
machine. However, generations which resulted in corrupt video in mpv (and games)
always resulted in corrupt video in GDM if I also rebooted into that generation.

Re: Video narration

[Paul Garlick]

Hi Laura,

> I see the only one that needs to be finished is 04-packaging3.
> Would you like me to adjust it? 

I can do the coarse adjustment on that one, to set the overall duration
and make sure that the audio streams are not truncated.

Could you re-build the other videos and check the internal timings? 
This is the fine adjustment that synchronizes the audio with the
command line output.  

I have briefly checked that this is sensible but there could be
improvements to be made.  The overall duration should stay the same. 
So if you remove 1000 ms of sleep from one section, for example, it
needs to be added back in elsewhere.

Best regards,

Paul.

Re: Update on 1.0.1

[Amin Bandali]

Hi Ludo’,

> Any other really important bit people would like to address?

Not critical, but it would be nice to update guix-install.sh to mention
“ci.guix.gnu.org” instead of “ci.guix.info” for clarity, similar to this
previous commit of yours [0] from a while back.

[0]: 
https://git.savannah.gnu.org/cgit/guix.git/commit/etc/guix-install.sh?id=4a0b87f0ec5b6c2dcf82b372dd20ca7ea6acdd9c

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

[Translation Project Robot]

Hello, gentle maintainer.

This is a message from the Translation Project robot.

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

https://translationproject.org/latest/shepherd/fr.po

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

All other PO files for your package are available in:

https://translationproject.org/latest/shepherd/

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

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

The following HTML page has been updated:

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

If any question arises, please contact the translation coordinator.

Thank you for all your work,

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

Re: Update on 1.0.1

[Giovanni Biscuolo]

Ludovic Courtès  writes:

[...]

> Any other really important bit people would like to address?

https://debbugs.gnu.org/cgi/bugreport.cgi?bug=35655
(Installer: mount error using btrfs on already formatted partition)

there are some others I'm testing (e.g. no terminal emulation program
when installing i3 only) and hope to report soon


Thanks! Gio'

-- 
Giovanni Biscuolo

Xelera IT Infrastructures

Re: Installer: howto remotely debug/report on bare-metal

[Giovanni Biscuolo]

sirgazil  writes:

[...]

> Would it be this same problem by chance?
>
> https://multimedialib.files.wordpress.com/2019/05/guix-1.0.0-installer-unexpected-problem.jpg

no, it's related to btrfs:
https://debbugs.gnu.org/cgi/bugreport.cgi?bug=35655

happy hacking! Gio'

[...]

-- 
Giovanni Biscuolo

Xelera IT Infrastructures

Re: Update on 1.0.1

[znavko]

Sorry for this, but "Graphical Installation" people can understand as graphical 
mode, but actually it is console mode with menus. It is kind of non-sense.

May 9, 2019 3:58 PM, "Ludovic Courtès"  wrote:

> Hello Guix!
> 
> It’s been one week since 1.0! We’ve been partying, but not as long as
> we’d like due to a couple of embarrassing bugs, in particular
> .
> 
> I’d like to release within a week because people installing Guix System
> from 1.0.0 have just too many issues.
> 
> Here are the remaining blockers as far as I’m concerned:
> 
> • Release the Shepherd 0.6.1 in a day or two, which will fix
> .
> 
> • Integration the Russian translation of the manual.
> 
> • Maybe do another round via the TP since there are a few new strings
> in the installer. Julien?
> 
> • Fix .
> 
> Any other really important bit people would like to address?
> 
> Thanks,
> Ludo’.

Update on 1.0.1

[Ludovic Courtès]

Hello Guix!

It’s been one week since 1.0!  We’ve been partying, but not as long as
we’d like due to a couple of embarrassing bugs, in particular
.

I’d like to release within a week because people installing Guix System
from 1.0.0 have just too many issues.

Here are the remaining blockers as far as I’m concerned:

  • Release the Shepherd 0.6.1 in a day or two, which will fix
.

  • Integration the Russian translation of the manual.

  • Maybe do another round via the TP since there are a few new strings
in the installer.  Julien?

  • Fix .

Any other really important bit people would like to address?

Thanks,
Ludo’.

Re: New Russian PO file for 'guix-manual' (version 1.0.0-pre3)

[Pavel Maryanov]

Znavko, please don't save your work in your storage. Send files to the
robot directly.
Because I started to fix errors and took original file PO-file from TP. And
now my work is useless.

чт, 9 мая 2019 г. в 17:42, :

> Hello, Ludvic! Thank you for your corrections. Pavel had added me (znavko)
> to TP translators team to guix-manual, guix, guix-packages packages. So, I
> can send updates, but I need your support.
> I do not understand how to translate  “contributing.texi” to
> “contributing.ru.texi” cause I did not touch it at all.
> The other corrections are made and my current po file is placed here
> https://gitgud.io/znavko/guix-manual-ru/blob/master/guix-manual-1.0.0-pre3.ru.po
> It was migrated from pre1 (when I translated pre1 and pre3 appeared) and
> also it was merged from Pavel's file sent to TP and my file that I had
> translated that moment when Pavel's file was published.
> So, now I have newly added translations, and need you to check if this
> file is correct.
> Let me know what to do exactly and then I'll send my translation.
>
>
> May 9, 2019 2:22 PM, "Ludovic Courtès"  wrote:
>
> > Hello Pavel,
> >
> > Thanks a lot for your translation work!
> >
> > While trying to integration the Russian translation of the manual into
> > Guix, I stumbled upon the following issues:
> >
> > • The “contributing.texi” string must translate to
> > “contributing.ru.texi”; failing to do that, the build system would
> > include the English version of that file, leading to various
> > failures.
> >
> > • “dfn{функциональный пакетный менеджер}” should be replaced by
> > “@dfn{функциональный пакетный менеджер}” (with an ‘@’).
> >
> > • There’s one typo: “@dnf” should be replaced by “@dfn”.
> >
> > • You translated node names “Using the Operating System” and “System
> > Configuration” by the same string, but Texinfo requires these two
> > strings to be different. Could you change one or the other?
> >
> > • The translation of node name “Keyboard Layout and Networking and
> > Partitioning” includes commas, I think, which are unfortunately not
> > allowed in this context. Is there a way you could work around that?
> >
> > Could you send an update of the translation to the Translation Project?
> >
> > The patch I used to build the Russian manual is attached below. You
> > need to first download ‘guix-manual.ru.po’ under ‘po/doc’.
> >
> > I’m Cc’ing Julien who knows these things better and can correct anything
> > I wrote above. :-)
> >
> > Thank you!
> >
> > Ludo’.
>

Re: New Russian PO file for 'guix-manual' (version 1.0.0-pre3)

[Pavel Maryanov]

Znavko, I uploaded file with fixes and some edits to TP. Now you have to
merge my work with your. Tha's why we have to use the same storage.

Ludovic, unfortunately Russian translation "Keyboard Layout and Networking
and Partitioning" have to contain comma because of two 'and'. It is a rule
of Russian language.

чт, 9 мая 2019 г. в 17:51, :

> I updated to
> https://gitgud.io/znavko/guix-manual-ru/blob/master/guix-manual-1.0.0-pre3.ru.po
> Ok. Now awaiting your publication and will continue to edit it. Hope my
> translations rests there.
>
> May 9, 2019 2:48 PM, "Pavel Maryanov"  >
> wrote:
>
> Znavko, please don't save your work in your storage. Send files to the
> robot directly.
> Because I started to fix errors and took original file PO-file from TP.
> And now my work is useless.
> чт, 9 мая 2019 г. в 17:42, :
>
> Hello, Ludvic! Thank you for your corrections. Pavel had added me (znavko)
> to TP translators team to guix-manual, guix, guix-packages packages. So, I
> can send updates, but I need your support.
> I do not understand how to translate “contributing.texi” to
> “contributing.ru.texi” cause I did not touch it at all.
> The other corrections are made and my current po file is placed here
> https://gitgud.io/znavko/guix-manual-ru/blob/master/guix-manual-1.0.0-pre3.ru.po
> It was migrated from pre1 (when I translated pre1 and pre3 appeared) and
> also it was merged from Pavel's file sent to TP and my file that I had
> translated that moment when Pavel's file was published.
> So, now I have newly added translations, and need you to check if this
> file is correct.
> Let me know what to do exactly and then I'll send my translation.
>
>
> May 9, 2019 2:22 PM, "Ludovic Courtès"  wrote:
>
> > Hello Pavel,
> >
> > Thanks a lot for your translation work!
> >
> > While trying to integration the Russian translation of the manual into
> > Guix, I stumbled upon the following issues:
> >
> > • The “contributing.texi” string must translate to
> > “contributing.ru.texi”; failing to do that, the build system would
> > include the English version of that file, leading to various
> > failures.
> >
> > • “dfn{функциональный пакетный менеджер}” should be replaced by
> > “@dfn{функциональный пакетный менеджер}” (with an ‘@’).
> >
> > • There’s one typo: “@dnf” should be replaced by “@dfn”.
> >
> > • You translated node names “Using the Operating System” and “System
> > Configuration” by the same string, but Texinfo requires these two
> > strings to be different. Could you change one or the other?
> >
> > • The translation of node name “Keyboard Layout and Networking and
> > Partitioning” includes commas, I think, which are unfortunately not
> > allowed in this context. Is there a way you could work around that?
> >
> > Could you send an update of the translation to the Translation Project?
> >
> > The patch I used to build the Russian manual is attached below. You
> > need to first download ‘guix-manual.ru.po’ under ‘po/doc’.
> >
> > I’m Cc’ing Julien who knows these things better and can correct anything
> > I wrote above. :-)
> >
> > Thank you!
> >
> > Ludo’.
>
>
>
>

Re: 01/01: guix: Simplify and robustify lzread!.

[Pierre Neidhardt]

 guix: Simplify and robustify lzread!.
>>>   ^
>>> Should be lzlib.
>>
>> Oops!
>> I must confess that I never really understood the whole logic behind
>> GNU-style commit message :p
>
> It’s really Guix-specific here, but the idea is that the word before
> colon indicates the part of the code being modified, to provide a bit of
> context.

That makes sense.  Where it makes less sense to me is when we prefix
with "gnu:" for packages.  Why GNU?  Why not "packages:"?

>>> Could you add a test for this corner case?  It’s corner cases like that
>>> that can spoil the whole experience, so it feels safer to add tests as
>>> soon as we encounter them.  :-)
>>
>> I would have, but I don't know how.  The problem is that I don't control
>> the chunk size passed to the read! callback of the custom port.  That's
>> all up to Guile's implementation of custom ports.
>>
>> In practice, it seems that the BV is always big enough so the potential
>> issue can never arise.  But the new code is better on all aspects.
>
> Didn’t you encounter the bug on an actual use case, though?  If you did,
> you could just write that use case in the test file.  If not, that’s
> okay.

No bug on an actual use case.  I kept discussing with Antonio and he
pointed out the potential issue.  The solution occurred to me on a fresh
sunny morning :D

> (I’m super cautious here but that’s because I spent countless hours
> debugging code that used zlib and libbz2 and lzo in the past.  :-))

Yup, tell me about it...  Took me weeks just to figure out basic
(de)compression ;)

But now that I have a better understanding of the library, I'm much more
confident about the robustness and debugability of the bindings.  Once
things start adding up in your head, it's much more straightforward to
see what goes wrong and how to fix it.  (Stating the obvious here, but
that's only true with good libraries, and lzlib is a good one.)

Well, time will tell :)

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


signature.asc
Description: PGP signature

New Russian PO file for 'guix-manual' (version 1.0.0-pre3)

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

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

[Laura Lazzati]

Hi Paul!

On Wed, May 8, 2019 at 8:14 PM Paul Garlick
 wrote:
>
> Hi Laura,
>
> > Now I am generating all the videos and will be pushing the changes
> > asap.
>
> Great stuff.
>
> I have made a start, setting the durations for the first three videos.
> If you pull the changes you can check the inner timings as well.  The
> sum of the sleep commands should now be correct for these videos.
>
> I plan to finish the coarse level sleep settings for the remaining
> videos in the next few days.
Oh, I was working on the timing of the cli session files too, after
pulling I see the only one that needs to be finished is 04-packaging3.
Would you like me to adjust it? I will be also testing the previous
ones to check everything is fine :)

Gábor, is your client still offering their storage to upload the
videos there so that the community can see them, give their opinion
and so on without having to spend time generating them?

Regards :)
Laura

Re: New Russian PO file for 'guix-manual' (version 1.0.0-pre3)

[znavko]

I updated to 
https://gitgud.io/znavko/guix-manual-ru/blob/master/guix-manual-1.0.0-pre3.ru.po
Ok. Now awaiting your publication and will continue to edit it. Hope my 
translations rests there.

May 9, 2019 2:48 PM, "Pavel Maryanov" mailto:a...@jack.kiev.ua?to=%22Pavel%20Maryanov%22%20)> 
wrote:
  Znavko, please don't save your work in your storage. Send files to the robot 
directly. Because I started to fix errors and took original file PO-file from 
TP. And now my work is useless.  
 чт, 9 мая 2019 г. в 17:42, mailto:zna...@disroot.org)>: 
Hello, Ludvic! Thank you for your corrections. Pavel had added me (znavko) to 
TP translators team to guix-manual, guix, guix-packages packages. So, I can 
send updates, but I need your support.
I do not understand how to translate “contributing.texi” to 
“contributing.ru.texi” cause I did not touch it at all.
The other corrections are made and my current po file is placed here 
https://gitgud.io/znavko/guix-manual-ru/blob/master/guix-manual-1.0.0-pre3.ru.po
 
(https://gitgud.io/znavko/guix-manual-ru/blob/master/guix-manual-1.0.0-pre3.ru.po)
It was migrated from pre1 (when I translated pre1 and pre3 appeared) and also 
it was merged from Pavel's file sent to TP and my file that I had translated 
that moment when Pavel's file was published.
So, now I have newly added translations, and need you to check if this file is 
correct.
Let me know what to do exactly and then I'll send my translation.
May 9, 2019 2:22 PM, "Ludovic Courtès" mailto:l...@gnu.org)> 
wrote:

> Hello Pavel,
>
> Thanks a lot for your translation work!
>
> While trying to integration the Russian translation of the manual into
> Guix, I stumbled upon the following issues:
>
> • The “contributing.texi” string must translate to
> “contributing.ru.texi”; failing to do that, the build system would
> include the English version of that file, leading to various
> failures.
>
> • “dfn{функциональный пакетный менеджер}” should be replaced by
> “@dfn{функциональный пакетный менеджер}” (with an ‘@’).
>
> • There’s one typo: “@dnf” should be replaced by “@dfn”.
>
> • You translated node names “Using the Operating System” and “System
> Configuration” by the same string, but Texinfo requires these two
> strings to be different. Could you change one or the other?
>
> • The translation of node name “Keyboard Layout and Networking and
> Partitioning” includes commas, I think, which are unfortunately not
> allowed in this context. Is there a way you could work around that?
>
> Could you send an update of the translation to the Translation Project?
>
> The patch I used to build the Russian manual is attached below. You
> need to first download ‘guix-manual.ru.po’ under ‘po/doc’.
>
> I’m Cc’ing Julien who knows these things better and can correct anything
> I wrote above. :-)
>
> Thank you!
>
> Ludo’.

Re: New Russian PO file for 'guix-manual' (version 1.0.0-pre3)

[znavko]

Hello, Ludvic! Thank you for your corrections. Pavel had added me (znavko) to 
TP translators team to guix-manual, guix, guix-packages packages. So, I can 
send updates, but I need your support.
I do not understand how to translate  “contributing.texi” to 
“contributing.ru.texi” cause I did not touch it at all.
The other corrections are made and my current po file is placed here 
https://gitgud.io/znavko/guix-manual-ru/blob/master/guix-manual-1.0.0-pre3.ru.po
It was migrated from pre1 (when I translated pre1 and pre3 appeared) and also 
it was merged from Pavel's file sent to TP and my file that I had translated 
that moment when Pavel's file was published.
So, now I have newly added translations, and need you to check if this file is 
correct.
Let me know what to do exactly and then I'll send my translation. 


May 9, 2019 2:22 PM, "Ludovic Courtès"  wrote:

> Hello Pavel,
> 
> Thanks a lot for your translation work!
> 
> While trying to integration the Russian translation of the manual into
> Guix, I stumbled upon the following issues:
> 
> • The “contributing.texi” string must translate to
> “contributing.ru.texi”; failing to do that, the build system would
> include the English version of that file, leading to various
> failures.
> 
> • “dfn{функциональный пакетный менеджер}” should be replaced by
> “@dfn{функциональный пакетный менеджер}” (with an ‘@’).
> 
> • There’s one typo: “@dnf” should be replaced by “@dfn”.
> 
> • You translated node names “Using the Operating System” and “System
> Configuration” by the same string, but Texinfo requires these two
> strings to be different. Could you change one or the other?
> 
> • The translation of node name “Keyboard Layout and Networking and
> Partitioning” includes commas, I think, which are unfortunately not
> allowed in this context. Is there a way you could work around that?
> 
> Could you send an update of the translation to the Translation Project?
> 
> The patch I used to build the Russian manual is attached below. You
> need to first download ‘guix-manual.ru.po’ under ‘po/doc’.
> 
> I’m Cc’ing Julien who knows these things better and can correct anything
> I wrote above. :-)
> 
> Thank you!
> 
> Ludo’.

Re: problem installing on RAID partition and hot to rescue

[Ludovic Courtès]

Hi Giovanni,

Giovanni Biscuolo  skribis:

> do you mean: it's inconvenient to manually edit /mnt/etc/config.scm once
> the graphical installer displayed it and before the "guix system init
> /mnt/etc/config.scm /mnt" by the installer?
>
> thinking twice I realize that mix-and-match guided (installer) and
> manual installation is not a great idea... it was a dirty hack :-)
>
> by the way, I'll try to rescue the system from the unbootable state:
> I'll re-assemble /dev/md0, chroot to it and try to grub-install and
> re-init Guix system with a fixed config.scm
>
> if the above fails, I'll re-install from scratch using the manual
> installation method

Yeah, what I mean is that, for now, you should use the manual
installation method entirely.  The guided method assumes it has control
over the whole process, so if you do things behind its back, it’s likely
to go awry.

It wouldn’t be That Hard™ to adjust the installer to so that it offers
RAID as an additional option, but right now the focus is on shipping
1.0.1 to address the more pressing issues.

Thanks,
Ludo’.

Re: Installer: howto remotely debug/report on bare-metal

[sirgazil]

 On Thu, 09 May 2019 09:01:28 -0500 Giovanni Biscuolo  
wrote 

 > Hello, 
 >  
 > I've bare-metal I'd like to use to stress test the installer before 
 > putting it in production 
 >  
 > I found a bug installing Guix using btrfs and I'd like to send the 
 > output of the "Unexpected problem" instead of a photo of the screen 
 > attached to the bug report: please is that output saved in some log file 
 > I can copy and send by email? 


Would it be this same problem by chance?

https://multimedialib.files.wordpress.com/2019/05/guix-1.0.0-installer-unexpected-problem.jpg

I haven't had the time to report this bug... I experienced it every time the 
graphical installation failed and I restarted it using the two options the 
installer offers to restart an installation (I don't remember the labels of the 
buttons). Unfortunately, I didn't write the steps to reproduce the problem.

Re: New Russian PO file for 'guix-manual' (version 1.0.0-pre3)

[Ludovic Courtès]

Hello Pavel,

Thanks a lot for your translation work!

While trying to integration the Russian translation of the manual into
Guix, I stumbled upon the following issues:

  • The “contributing.texi” string must translate to
“contributing.ru.texi”; failing to do that, the build system would
include the English version of that file, leading to various
failures.

  • “dfn{функциональный пакетный менеджер}” should be replaced by
“@dfn{функциональный пакетный менеджер}” (with an ‘@’).

  • There’s one typo: “@dnf” should be replaced by “@dfn”.

  • You translated node names “Using the Operating System” and “System
Configuration” by the same string, but Texinfo requires these two
strings to be different.  Could you change one or the other?

  • The translation of node name “Keyboard Layout and Networking and
Partitioning” includes commas, I think, which are unfortunately not
allowed in this context.  Is there a way you could work around that?

Could you send an update of the translation to the Translation Project?

The patch I used to build the Russian manual is attached below.  You
need to first download ‘guix-manual.ru.po’ under ‘po/doc’.

I’m Cc’ing Julien who knows these things better and can correct anything
I wrote above.  :-)

Thank you!

Ludo’.

diff --git a/doc/local.mk b/doc/local.mk
index ed87638a56..1427f8313b 100644
--- a/doc/local.mk
+++ b/doc/local.mk
@@ -25,6 +25,7 @@ info_TEXINFOS = %D%/guix.texi			\
   %D%/guix.es.texi\
   %D%/guix.fr.texi\
   %D%/guix.de.texi\
+  %D%/guix.ru.texi\
   %D%/guix.zh_CN.texi
 
 %C%_guix_TEXINFOS = \
@@ -60,10 +61,12 @@ TRANSLATED_INFO =\
   %D%/guix.de.texi\
   %D%/guix.es.texi\
   %D%/guix.fr.texi\
+  %D%/guix.ru.texi\
   %D%/guix.zh_CN.texi\
   %D%/contributing.de.texi			\
   %D%/contributing.es.texi			\
   %D%/contributing.fr.texi			\
+  %D%/contributing.ru.texi			\
   %D%/contributing.zh_CN.texi
 
 # Bundle this file so that makeinfo finds it in out-of-source-tree builds.
diff --git a/po/doc/local.mk b/po/doc/local.mk
index cb5266c623..fb3c5aee03 100644
--- a/po/doc/local.mk
+++ b/po/doc/local.mk
@@ -20,6 +20,7 @@ DOC_PO_FILES=	\
   %D%/guix-manual.es.po\
   %D%/guix-manual.de.po\
   %D%/guix-manual.fr.po\
+  %D%/guix-manual.ru.po\
   %D%/guix-manual.zh_CN.po
 
 EXTRA_DIST = \

Re: 01/01: guix: Simplify and robustify lzread!.

[Ludovic Courtès]

Hi Pierre,

Pierre Neidhardt  skribis:

> Ludovic Courtès  writes:
>
>> Hi Pierre!
>>
>> guix-comm...@gnu.org skribis:
>>
>>> commit ecfc54403e2a1934b4f6e84ddad429b7970091fa
>>> Author: Pierre Neidhardt 
>>> Date:   Tue May 7 18:40:40 2019 +0200
>>>
>>> guix: Simplify and robustify lzread!.
>>   ^
>> Should be lzlib.
>
> Oops!
> I must confess that I never really understood the whole logic behind
> GNU-style commit message :p

It’s really Guix-specific here, but the idea is that the word before
colon indicates the part of the code being modified, to provide a bit of
context.

>> Could you add a test for this corner case?  It’s corner cases like that
>> that can spoil the whole experience, so it feels safer to add tests as
>> soon as we encounter them.  :-)
>
> I would have, but I don't know how.  The problem is that I don't control
> the chunk size passed to the read! callback of the custom port.  That's
> all up to Guile's implementation of custom ports.
>
> In practice, it seems that the BV is always big enough so the potential
> issue can never arise.  But the new code is better on all aspects.

Didn’t you encounter the bug on an actual use case, though?  If you did,
you could just write that use case in the test file.  If not, that’s
okay.

(I’m super cautious here but that’s because I spent countless hours
debugging code that used zlib and libbz2 and lzo in the past.  :-))

Thanks,
Ludo’.

Re: Installer: howto remotely debug/report on bare-metal

[Giovanni Biscuolo]

Hello,

reply to myself:

Giovanni Biscuolo  writes:

[...]

> also: is there a way to start the Installer in a ssh remote session
> (once I manually set up networking) so I can stay away from bare
> metal?

of course there is: switch to a console (CTRL-ALT-F3..F5), start
ssh-daemon (herd start ssh-daemon), change the root password, remotely
connect via ssh to root@ and look for the command to
start the installer (ps auxww | grep installer)

in my case (using Guix 1.0.0 ISO on USB) is:

--8<---cut here---start->8---
  /gnu/store/9alic3caqhay3h8mx4iihpmyj6ymqpcx-guile-2.2.4/bin/guile 
--no-auto-compile /gnu/store/sdxzl5gxphl4pwjqshq6a8w230asklym-installer-real
--8<---cut here---end--->8---

using that command now I can remotely run the installer via ssh

HTH! Gio'

[...]

-- 
Giovanni Biscuolo

Xelera IT Infrastructures


signature.asc
Description: PGP signature

Installer: howto remotely debug/report on bare-metal

[Giovanni Biscuolo]

Hello,

I've bare-metal I'd like to use to stress test the installer before
putting it in production

I found a bug installing Guix using btrfs and I'd like to send the
output of the "Unexpected problem" instead of a photo of the screen
attached to the bug report: please is that output saved in some log file
I can copy and send by email?

also: is there a way to start the Installer in a ssh remote session
(once I manually set up networking) so I can stay away from bare metal?
:-)

thanks! Gio'

-- 
Giovanni Biscuolo

Xelera IT Infrastructures


signature.asc
Description: PGP signature

Re: Packaging FreeCAD

[John Soo]

Hello Guix,

I have a few updates on progress packaging FreeCAD.

  - Thanks to the PySide developers, I have a rough draft of PySide2,
PySide2-tools and Shiboken2 built.
  - FreeCAD gets through the build phase at version 0.18.1 (the current
release) thanks to the PySide2 dependency.
  - Pivy, an optional dependency, still does not build yet, though I have
been making some progress.
  - Coin has been undergoing a lot of development since I last defined the
package and the updates will require extra work to package.
  - I'm confused by some licenses and I will probably ask for help
clarifying them when I submit a patch,

Thanks for your help and guidance,

John

On Tue, Mar 12, 2019 at 3:15 PM John Soo  wrote:

> Thanks Efraim!
>
> That helped a lot. I Switched to version 5.11.3 and swapped qt for qtbase
> and some extra qt libraries and that moved me past the one blocker. Now I
> am faced with another challenge. I packaged Shiboken 1 previously when I
> did not realize freecad moved to pyside2; in that process I followed the
> nix packaging strategy of building all the bundled libraries separately.  I
> am now running into the same issues I had prior to splitting up Shiboken 1
> while building pyside2. The python build system in pyside2 shells out to
> cmake for most of the build process.  That means it does not use
> cmake-build-system. Does pyside2 need to be split into parts now? It is
> more challenging for pyside2 that Shiboken 1 because the sources for all
> the libraries are shipped together.  Here's the source, for reference:
> https://code.qt.io/cgit/pyside/pyside-setup.git/
>
> Thank you all,
>
> John
>
> On Sun, Mar 10, 2019 at 7:25 AM Efraim Flashner 
> wrote:
>
>> On Sun, Mar 10, 2019 at 02:14:15AM +, John Soo wrote:
>> > Hi guix,
>> >
>> > Just a quick update. I have little to report on freecad. I am still
>> stuck
>> > packaging pyside2. I have looked over the debian packaging rules but I
>> am
>> > unfamiliar with their packaging process. I did some research and it
>> looks
>> > as though they are using the normal pybuild process with some
>> alterations
>> > to some paths afterward.  The package completely fails to compile for me
>> > and I am no expert on python build tooling. Here's what I have tried so
>> far
>> > and the error: https://paste.debian.net/1072533. Any help would be very
>> > appreciated.
>> >
>> > Thanks,
>> >
>> > John
>> >
>> > On Fri, Feb 15, 2019 at 6:33 PM John Soo  wrote:
>> >
>> > > Thanks so much Paul! This is really helpful!
>> > >
>> > > > On Feb 15, 2019, at 9:20 AM, Paul Garlick <
>> > > pgarl...@tourbillion-technology.com> wrote:
>> > > >
>> > > > Hi John,
>> > > >
>> > > >> I have been getting a little stuck building the pyside2
>> dependencies
>> > > >
>> > > > There has been an effort to package pyside2 for Debian.  This has
>> been
>> > > > completed in the last six months.
>> > > >
>> > > > A good place to look for information is
>> > > > https://tracker.debian.org/pkg/pyside2
>> > > >
>> > > > You can browse the source code and follow the links to the 'debian'
>> > > > directory, which contains the files that govern the packaging
>> process.
>> > > > In general for Debian packages, the 'rules' file is worth reading
>> and
>> > > > the 'patches' directory has the changes to the upstream code.
>> > > >
>> > > > One element that could be important in Guix is an update of
>> patchelf to
>> > > > a recent commit (see 'update-patchelf.patch' in the patches
>> directory).
>> > > >
>> > > > Best regards,
>> > > >
>> > > > Paul.
>> > > >
>> > >
>>
>> I haven't tried building it myself yet, but two things come to mind:
>> Try using qtbase instead of qt, it has a much smaller footprint and will
>> likely be requested when it's time to include the package in Guix.
>>
>> You're using version 5.12.1, and in Guix we have qt 5.11.3. It's likely
>> the errors you're getting are because the version of Qt is different.
>>
>> --
>> Efraim Flashner  אפרים פלשנר
>> GPG key = A28B F40C 3E55 1372 662D  14F7 41AA E7DC CA3D 8351
>> Confidentiality cannot be guaranteed on emails sent or received
>> unencrypted
>>
>

Re: Setting up a Hurd build node

[Jonathan Brielmaier]

Am 08.05.19 um 00:12 schrieb Ricardo Wurmus> Weird!  This is all very
familiar, because that’s where I stopped when I
> last tried all of this.  I gave up when I couldn’t figure out why tar
> segfaulted.

Maybe you could include the bug-h...@gnu.org mailing list or ask Hurd
hackers directly :)

Re: Iridium Browser

[Giovanni Biscuolo]

Hello Dexter,

"Dexter Morgan"  writes:

> I like to use this in Guix.
> https://directory.fsf.org/wiki?title=Iridium_Browser=74816

Marius Bakke (thanks again!) packaged a *liberated* [1] version of
ungoogled-chromium [2], AFAIU it's a valid alternative to Iridium
Browser

HTH! Gio'


[1] removing all proprietary third party software

[2] https://github.com/Eloston/ungoogled-chromium

-- 
Giovanni Biscuolo

Xelera IT Infrastructures


signature.asc
Description: PGP signature