Status update on 1.0

Status update on 1.0

[Ludovic Courtès]

Hello Guix!

When we said we’d try to release 1.0 for FOSDEM, we were talking about
FOSDEM *2019*, which is well over now, so I think we need to get our act
together and complete the remaining tasks for 1.0.  :-)

Looking at the
<https://git.savannah.gnu.org/cgit/guix/maintenance.git/tree/doc/1.0.org>
plus my own memories, here are work items that still need to be
addressed:

  • The graphical installer has been merged (yay!) but we still need to
    discuss it in the manual and to test it some more.

  • The installer should be changed to produce the right
    ‘initrd-modules’ field, using the same mechanism used by
    ‘check-device-initrd-modules’.

  • The story about grafts and displaying upfront what’s going to be
    built is not fixed yet.  I’ve been toying with the build
    continuations but nothing conclusive yet.  I’ve also thought about
    quick hacks instead but nothing concrete either.

  • 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
    <https://wiki.linuxfoundation.org/networking/generic_netlink_howto>.
    Writing bindings for ‘sendmsg’ and the associated data structures
    looks reasonable… it just needs to be done.

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

  • GDM’s closure is 1.3 GiB, we should do something about it.

  • I think we should add ‘guix install’, ‘guix remove’, and ‘guix
    upgrade’.

  • “GuixSD” has been removed from the web site and from almost all of
    the source code.  Still need to fix the file names that appear in
    Makefile.am.

  • Work for guix.gnu.org is on its way thanks to Julien, hopefully done
    soon.

If you’re interesting in tackling a specific issue, please share.  Let’s
all tackle these so we can finally reach that milestone and celebrate!

Ludo’.

Re: Status update on 1.0

[Tobias Geerinckx-Rice]

Ludo',

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.

>  • “GuixSD” has been removed from the web site and from almost 
>  all of
>    the source code.  Still need to fix the file names that 
>    appear in
>    Makefile.am.

Sounds trivial enough (hah) for me to do this evening, but then 
that's true for anybody.

>   • I think we should add ‘guix install’, ‘guix remove’, and 
>   ‘guix
>     upgrade’.

Hmmm… m.  What would these do?

Thanks for keeping this ball rolling in the air with your eye on 
it,

T G-R

Re: Status update on 1.0

[Pierre Neidhardt]

[-- Attachment #1: Type: text/plain, Size: 571 bytes --]


> The last time I tried the installer it didn't work on AMD(GPU) cards.  I'll give
> it another go.

I've experienced the same issue and I'm quite sure this is because the installer
uses KMSCON which only works with the proprietary amdgpu kernel module.  During
FOSDEM, Mathieu mentioned that KMSCON was chosen because it works better with
text/input encoding, if I recall correctly.  The solution would be to fallback
on something else with lesser encoding support, which is still better than a
black screen :p

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]

Re: Status update on 1.0

[Danny Milosavljevic]

[-- Attachment #1: Type: text/plain, Size: 703 bytes --]

On Wed, 13 Mar 2019 17:00:55 +0100
Pierre Neidhardt <mail@ambrevar.xyz> wrote:

> > The last time I tried the installer it didn't work on AMD(GPU) cards.  I'll give
> > it another go.  
> 
> I've experienced the same issue and I'm quite sure this is because the installer
> uses KMSCON which only works with the proprietary amdgpu kernel module.  During
> FOSDEM, Mathieu mentioned that KMSCON was chosen because it works better with
> text/input encoding, if I recall correctly. 

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

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: Status update on 1.0

[Pierre Neidhardt]

[-- Attachment #1: Type: text/plain, Size: 458 bytes --]


Danny Milosavljevic <dannym@scratchpost.org> 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).

Don't know if this can be fixed.

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]

Re: Status update on 1.0

[Ludovic Courtès]

Pierre Neidhardt <mail@ambrevar.xyz> skribis:

> Danny Milosavljevic <dannym@scratchpost.org> 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

[Pierre Neidhardt]

[-- Attachment #1: Type: text/plain, Size: 105 bytes --]


> They should still support VESA, no?

Yes they do.

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]

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: Status update on 1.0

[Maxim Cournoyer]

Danny Milosavljevic <dannym@scratchpost.org> writes:

> On Wed, 13 Mar 2019 17:00:55 +0100
> Pierre Neidhardt <mail@ambrevar.xyz> wrote:
>
>> > The last time I tried the installer it didn't work on AMD(GPU) cards.  I'll give
>> > it another go.  
>> 
>> I've experienced the same issue and I'm quite sure this is because the installer
>> uses KMSCON which only works with the proprietary amdgpu kernel module.  During
>> FOSDEM, Mathieu mentioned that KMSCON was chosen because it works better with
>> text/input encoding, if I recall correctly. 
>
> 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).

As Pierre hinted, your question should rather be as "Why on Earth does
the AMDGPU drivers needs a binary blob to provide basic features such as KMS
at all". I'm still appalled that this mammoth, 125 K lines of codes
driver got merged in the Linux kernel and is barely useful [0] when
the proprietary binary blobs are not installed.

Maxim

[0]  Booting an AMD R9 285 GPU without the binary blobs installed would
leave me to a black screen last time I tried, using Debian 9.

Re: Status update on 1.0

[Ludovic Courtès]

Hello!

Tobias Geerinckx-Rice <me@tobias.gr> 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 that    appear
>> 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

[mikadoZero]

Ludovic Courtès writes:

>   • The graphical installer has been merged (yay!) but we still need to
>     discuss it in the manual and to test it some more.

I was just going to install Guix SD on another system.  So I could try
the installer.  I could also try my hand at texinfo and do some
documentation of the graphical installer.

>   • “GuixSD” has been removed from the web site and from almost all of
>     the source code.  Still need to fix the file names that appear in
>     Makefile.am.

Is it to be changed to "Guix SD"?

Greping the Guix repo it looks like “GuixSD” is in documentation (in
different languages) and source code comments.

What should be done when it is part of something more important like
file paths, variable name or command line argument?

I can start with the doc directory.

Re: Status update on 1.0

[Ricardo Wurmus]

mikadoZero <mikadozero@yandex.com> writes:

>>   • “GuixSD” has been removed from the web site and from almost all of
>>     the source code.  Still need to fix the file names that appear in
>>     Makefile.am.
>
> Is it to be changed to "Guix SD"?

Just “Guix system”.

-- 
Ricardo

Re: Status update on 1.0

[pelzflorian (Florian Pelz)]

On Wed, Mar 13, 2019 at 06:08:38PM +0100, Ricardo Wurmus wrote:
> mikadoZero <mikadozero@yandex.com> writes:
> 
> >>   • “GuixSD” has been removed from the web site and from almost all of
> >>     the source code.  Still need to fix the file names that appear in
> >>     Makefile.am.
> >
> > Is it to be changed to "Guix SD"?
> 
> Just “Guix system”.
> 

In the manual I sometimes see “Guix System” with a capital S.  Which
is correct?

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.

Regards,
Florian

Re: Status update on 1.0

[L p R n d n]

"pelzflorian (Florian Pelz)" <pelzflorian@pelzflorian.de> writes:

> On Wed, Mar 13, 2019 at 06:08:38PM +0100, Ricardo Wurmus wrote:
>> mikadoZero <mikadozero@yandex.com> writes:
>> 
>> >>   • “GuixSD” has been removed from the web site and from almost all of
>> >>     the source code.  Still need to fix the file names that appear in
>> >>     Makefile.am.
>> >
>> > Is it to be changed to "Guix SD"?
>> 
>> Just “Guix system”.
>> 
>
> In the manual I sometimes see “Guix System” with a capital S.  Which
> is correct?
>
> 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.
>
> Regards,
> Florian

Re: Status update on 1.0

[L p R n d n]

Hello,

"pelzflorian (Florian Pelz)" <pelzflorian@pelzflorian.de> writes:

> On Wed, Mar 13, 2019 at 06:08:38PM +0100, Ricardo Wurmus wrote:
>> mikadoZero <mikadozero@yandex.com> writes:
>> 
>> >>   • “GuixSD” has been removed from the web site and from almost all of
>> >>     the source code.  Still need to fix the file names that appear in
>> >>     Makefile.am.
>> >
>> > Is it to be changed to "Guix SD"?
>> 
>> Just “Guix system”.
>> 
>
> In the manual I sometimes see “Guix System” with a capital S.  Which
> is correct?
>
> 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.
>
> Regards,
> Florian

Seems I sent an empty message. Sorry...
So I was just saying I was in favor of translating "system" in Guix
system and probably without capital "S" but not sure really.

Have a nice day,

Lprndn

Re: Status update on 1.0

[Ludovic Courtès]

Hello,

"pelzflorian (Florian Pelz)" <pelzflorian@pelzflorian.de> 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: 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)" <pelzflorian@pelzflorian.de> 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

[mikadoZero]

Ricardo Wurmus writes:

> mikadoZero <mikadozero@yandex.com> writes:
>
>>>   • “GuixSD” has been removed from the web site and from almost all of
>>>     the source code.  Still need to fix the file names that appear in
>>>     Makefile.am.
>>
>> Is it to be changed to "Guix SD"?
>
> Just “Guix system”.

I will wait for patch #34848 to be committed before looking at this.

Re: Status update on 1.0

[Timothy Sample]

Hi Ludo,

Ludovic Courtès <ludo@gnu.org> writes:

> Hello Guix!
>
> When we said we’d try to release 1.0 for FOSDEM, we were talking about
> FOSDEM *2019*, which is well over now, so I think we need to get our act
> together and complete the remaining tasks for 1.0.  :-)
>
> Looking at the
> <https://git.savannah.gnu.org/cgit/guix/maintenance.git/tree/doc/1.0.org>
> plus my own memories, here are work items that still need to be
> addressed:
>
> [...]
>
>   • 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.)

>   • GDM’s closure is 1.3 GiB, we should do something about it.

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.

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

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.


[1] https://lists.gnu.org/archive/html/guix-devel/2019-02/msg00198.html


-- Tim

Re: Status update on 1.0

[Ludovic Courtès]

Hi Timothy,

Timothy Sample <samplet@ngyro.com> skribis:

> Ludovic Courtès <ludo@gnu.org> 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

[Timothy Sample]

Hi,

Ludovic Courtès <ludo@gnu.org> 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: Status update on 1.0

[Ludovic Courtès]

Hi Timothy,

Timothy Sample <samplet@ngyro.com> skribis:

> Ludovic Courtès <ludo@gnu.org> 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.

Indeed, I eventually fixed it in
11e1df56e29e8e9f9dbe1beaf6afb902c33c9198.

I also removed dependencies from hplip-minimal in commit
c9b3a72b6792c8195b0cdd8e5d7809db29419c7d.

Ludo’.

Re: Status update on 1.0

[Timothy Sample]

Hi Ludo,

Ludovic Courtès <ludo@gnu.org> writes:

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

This didn’t work as well as I had hoped.  I was able to make a “lib”
output for “colord”, which gets rid of “hplip-minimal” and, in turn,
“gcc”.  However, it was supposed to also remove “llvm” and “python@3”,
but those are still in the closure because of other packages.  It looks
like breaking apart “mesa” (as Debian and Nix do) could cut out “llvm”
and maybe “python@2”.  The reason “python@3” is there is because of
“glib:bin”.  The “gnome-session” package brings it in so that it can
call “gsettings”.  Debian splits the GLib executables into “bin” and
“dev-bin”, and only the latter needs Python 3.  This is tricky because
“mesa” and “glib” have thousands of dependants, so changing them could
cause a lot of problems.  Splitting GLib is not so bad, but Mesa looks
to be quite complicated.

Another area that could be improved is NetworkManager.  GDM only needs
the “libnm” part, but it ends up bringing in everything.  NetworkManager
doesn’t have many dependants, so this could be done pretty quickly
(provided that splitting it is easy enough).

>> 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 managed to remove “webgitgtk” from the closure of “gnome-shell”.
Inkscape is still in there, though.  Maybe converting the SVG to a PNG
in a separate derivation would be an easy solution.

All told, GDM is down to 1.2GiB, and GNOME Shell is 1.64GiB.  That’s
better, but not great.  Plenty of GNOME software comes in big bundles
where you get a daemon, a low-level D-Bus library, a high-level library,
a GUI, and some utilities.  Being able to break these up would improve
the situation quite a bit, but it will be a lot of work.  I don’t know
how much of this we can solve before 1.0.  It all depends on how much of
a hurry we’re in.  :)

Right now, I have a bit testing to do with my current patches, and then
maybe I could break up NetworkManager and fix the dependency cycle with
GDM and GNOME Shell.  If it can go through a core-updates cycle, I could
split up GLib.  I don’t think I can split up Mesa, though.  I am not
very familiar with it.

I will be tied up for about a week, so I won’t be able to do any of it
before next weekend (Mar. 29).


-- Tim

Re: Status update on 1.0

[Ludovic Courtès]

Hello!

Timothy Sample <samplet@ngyro.com> skribis:

> This didn’t work as well as I had hoped.  I was able to make a “lib”
> output for “colord”, which gets rid of “hplip-minimal” and, in turn,
> “gcc”.  However, it was supposed to also remove “llvm” and “python@3”,
> but those are still in the closure because of other packages.  It looks
> like breaking apart “mesa” (as Debian and Nix do) could cut out “llvm”
> and maybe “python@2”.  The reason “python@3” is there is because of
> “glib:bin”.  The “gnome-session” package brings it in so that it can
> call “gsettings”.  Debian splits the GLib executables into “bin” and
> “dev-bin”, and only the latter needs Python 3.  This is tricky because
> “mesa” and “glib” have thousands of dependants, so changing them could
> cause a lot of problems.  Splitting GLib is not so bad, but Mesa looks
> to be quite complicated.

Yeah, splitting MESA and GLib are longer-term project I guess, but it’s
good that you’ve already analyzed the situation so we know what to do
next.

> Another area that could be improved is NetworkManager.  GDM only needs
> the “libnm” part, but it ends up bringing in everything.  NetworkManager
> doesn’t have many dependants, so this could be done pretty quickly
> (provided that splitting it is easy enough).

Indeed.

> I managed to remove “webgitgtk” from the closure of “gnome-shell”.

Neat!  Do you have that patch around?  :-)

> All told, GDM is down to 1.2GiB, and GNOME Shell is 1.64GiB.  That’s
> better, but not great.  Plenty of GNOME software comes in big bundles
> where you get a daemon, a low-level D-Bus library, a high-level library,
> a GUI, and some utilities.  Being able to break these up would improve
> the situation quite a bit, but it will be a lot of work.  I don’t know
> how much of this we can solve before 1.0.  It all depends on how much of
> a hurry we’re in.  :)

That will be post-1.0, let’s focus on the low-hanging fruits for now.
:-)

> Right now, I have a bit testing to do with my current patches, and then
> maybe I could break up NetworkManager and fix the dependency cycle with
> GDM and GNOME Shell.  If it can go through a core-updates cycle, I could
> split up GLib.  I don’t think I can split up Mesa, though.  I am not
> very familiar with it.
>
> I will be tied up for about a week, so I won’t be able to do any of it
> before next weekend (Mar. 29).

OK, thank you for your work!

Ludo’.

Re: Status update on 1.0

[Timothy Sample]

Hi Ludo,

Ludovic Courtès <ludo@gnu.org> writes:

> Timothy Sample <samplet@ngyro.com> skribis:
>
>> I managed to remove “webgitgtk” from the closure of “gnome-shell”.
>
> Neat!  Do you have that patch around?  :-)

Submitted with patch ID 35028.


-- Tim

Re: Status update on 1.0

[Gábor Boskovits]

Hello Ludo,

Ludovic Courtès <ludo@gnu.org> 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
>     <https://wiki.linuxfoundation.org/networking/generic_netlink_howto>.
>     Writing bindings for ‘sendmsg’ and the associated data structures
>     looks reasonable… it just needs to be done.
>

I am interested in doing this. 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)
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?

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

>
> Ludo’.
>

Best regards,
g_bor

Re: Status update on 1.0

[Ludovic Courtès]

Hi,

Gábor Boskovits <boskovits@gmail.com> skribis:

> Ludovic Courtès <ludo@gnu.org> 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
>>     <https://wiki.linuxfoundation.org/networking/generic_netlink_howto>.
>>     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: Status update on 1.0

[Thompson, David]

On Fri, Mar 15, 2019 at 10:33 AM Ludovic Courtès <ludo@gnu.org> wrote:
>
> Hi,
>
> Gábor Boskovits <boskovits@gmail.com> skribis:
>
> > Ludovic Courtès <ludo@gnu.org> 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
> >>     <https://wiki.linuxfoundation.org/networking/generic_netlink_howto>.
> >>     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

[Gábor Boskovits]

Hello,

Thompson, David <dthompson2@worcester.edu> 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

Fwd: Status update on 1.0

[Kristofer Buffington]

[-- Attachment #1: Type: text/plain, Size: 1764 bytes --]

Woops, I meant to send this message to the list

---------- Forwarded message ---------
From: Kristofer Buffington <kristoferbuffington@gmail.com>
Date: Wed, Mar 20, 2019 at 8:51 PM
Subject: Re: Status update on 1.0
To: Gábor Boskovits <boskovits@gmail.com>


I'm deep into this netlink/rtnetlink business currently. I'm trying to
decide if it's better to use guile-ffi or if it's just easier to use bash
scripts and iproute2. Then virtual network interfaces could map to specific
containerized services, which is my objective. Long-term, the netlink and
rtnetlink fii is the superior approach. But bash scripts could get us
something hacky, but running quickly.

My other curiosity is: would it make more sense for shepherd to generate
virtual network namespaces when services spawn, or is that something the
operating-system declaration should contain?

I'd love to help. I'm on the verge of putting some code down now that the
research is coalescing into a vision. If there's some guidance or
suggestions or otherwise, please try to get me involved!

Kristofer Buffington

On Fri, Mar 15, 2019 at 3:35 PM Gábor Boskovits <boskovits@gmail.com> wrote:

> Hello,
>
> Thompson, David <dthompson2@worcester.edu> 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
>
>

[-- Attachment #2: Type: text/html, Size: 2575 bytes --]

Re: Status update on 1.0

[Gábor Boskovits]

Hello,

Kristofer Buffington <kristoferbuffington@gmail.com> ezt írta
(időpont: 2019. márc. 21., Cs, 1:54):
>
> Woops, I meant to send this message to the list
>
> ---------- Forwarded message ---------
> From: Kristofer Buffington <kristoferbuffington@gmail.com>
> Date: Wed, Mar 20, 2019 at 8:51 PM
> Subject: Re: Status update on 1.0
> To: Gábor Boskovits <boskovits@gmail.com>
>
>
> I'm deep into this netlink/rtnetlink business currently. I'm trying to decide if it's better to use guile-ffi or if it's just easier to use bash scripts and iproute2. Then virtual network interfaces could map to specific containerized services, which is my objective. Long-term, the netlink and rtnetlink fii is the superior approach. But bash scripts could get us something hacky, but running quickly.
>
> My other curiosity is: would it make more sense for shepherd to generate virtual network namespaces when services spawn, or is that something the operating-system declaration should contain?
>
> I'd love to help. I'm on the verge of putting some code down now that the research is coalescing into a vision. If there's some guidance or suggestions or otherwise, please try to get me involved!
>

Ok, I will push my preliminary work on wip-netlink soon. It it a guile
ffi style binding, but currently I got only to the definitions of
structures mainly. Help is much appreciated.

> Kristofer Buffington
>
> On Fri, Mar 15, 2019 at 3:35 PM Gábor Boskovits <boskovits@gmail.com> wrote:
>>
>> Hello,
>>
>> Thompson, David <dthompson2@worcester.edu> 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
>>

Best regards,
g_bot

Re: Status update on 1.0

[Ludovic Courtès]

Hello!

Ludovic Courtès <ludo@gnu.org> skribis:

>   • The installer should be changed to produce the right
>     ‘initrd-modules’ field, using the same mechanism used by
>     ‘check-device-initrd-modules’.

I’ve done this in commit 50247be5f4633a4c3446cddbd3515d027853ec0d, and
also added a confirmation dialog before formatting disks in commit
c73e554c3fe609ee2d66628f7f09cf7fa6c8d4a6 (I think it was Pierre who
suggested it at the Guix Days.)

I’ve added keyboard layout configuration, except for Xorg, in commit
3191b5f6ba5ebbb59a7448facd999ad7f7aeae79.

Xorg keyboard layout configuration remains a bit too complicated so I
think we’d first need to simplify it, though I’m not sure how (introduce
an intermediate service?).

Anyway, you’re still very much welcome to test the installer!  See the
manual on how to build the installation image:

  https://gnu.org/software/guix/manual/en/html_node/Building-the-Installation-Image.html

Ludo’.

Re: Status update on 1.0

[znavko]

[-- Attachment #1: Type: text/plain, Size: 1248 bytes --]

Thank you! Nice work! 
Guile handbook wanted!


Mar 27, 2019, 3:26 PM by ludo@gnu.org:

> Hello!
>
> Ludovic Courtès <> ludo@gnu.org <mailto:ludo@gnu.org>> > skribis:
>
>> • The installer should be changed to produce the right
>>  ‘initrd-modules’ field, using the same mechanism used by
>>  ‘check-device-initrd-modules’.
>>
>
> I’ve done this in commit 50247be5f4633a4c3446cddbd3515d027853ec0d, and
> also added a confirmation dialog before formatting disks in commit
> c73e554c3fe609ee2d66628f7f09cf7fa6c8d4a6 (I think it was Pierre who
> suggested it at the Guix Days.)
>
> I’ve added keyboard layout configuration, except for Xorg, in commit
> 3191b5f6ba5ebbb59a7448facd999ad7f7aeae79.
>
> Xorg keyboard layout configuration remains a bit too complicated so I
> think we’d first need to simplify it, though I’m not sure how (introduce
> an intermediate service?).
>
> Anyway, you’re still very much welcome to test the installer!  See the
> manual on how to build the installation image:
>
>  > https://gnu.org/software/guix/manual/en/html_node/Building-the-Installation-Image.html <https://gnu.org/software/guix/manual/en/html_node/Building-the-Installation-Image.html>
>
> Ludo’.
>


[-- Attachment #2: Type: text/html, Size: 2945 bytes --]

Re: Status update on 1.0

[Danny Milosavljevic]

[-- Attachment #1: Type: text/plain, Size: 1541 bytes --]

Hi Ludo,

On Wed, 27 Mar 2019 16:26:55 +0100
Ludovic Courtès <ludo@gnu.org> wrote:

> Anyway, you’re still very much welcome to test the installer!  See the
> manual on how to build the installation image:
> 
>   https://gnu.org/software/guix/manual/en/html_node/Building-the-Installation-Image.html

I've tried this on qemu and had the infamous "waiting for udev" problem Mark
also saw on Hydra before.

After rebooting, the same image worked fine.
The installer also works fine and looks great!

Also, I used the non-iso9660 disk image because the iso9660 disk image (not documented
on the page above either) has 1.5 MB (not a typo).

$ file /gnu/store/lcx2w0y6pi6av4qhipmwc9xjzy4p7gbd-image.iso
/gnu/store/lcx2w0y6pi6av4qhipmwc9xjzy4p7gbd-image.iso: DOS/MBR boot sector; GRand Unified Bootloader, stage1 version 0x79, boot drive 0xbb, stage2 address 0x8e70, 1st sector stage2 0xb8db31c3, stage2 segment 0x201; partition 1 : ID=0xee, start-CHS (0x0,0,2), end-CHS (0x3f8,9,12), startsector 1, 3121451 sectors, extended partition table (last)

$ stat /gnu/store/lcx2w0y6pi6av4qhipmwc9xjzy4p7gbd-image.iso
  File: /gnu/store/lcx2w0y6pi6av4qhipmwc9xjzy4p7gbd-image.iso
  Size: 1495040         Blocks: 2920       IO Block: 4096   regular file
Device: 801h/2049d      Inode: 34661153    Links: 2
Access: (0444/-r--r--r--)  Uid: (    0/    root)   Gid: (    0/    root)
Access: 2019-03-27 23:25:26.240200749 +0100
Modify: 1970-01-01 01:00:01.000000000 +0100
Change: 2019-03-27 23:25:26.248200669 +0100
 Birth: -

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: Status update on 1.0

[Ludovic Courtès]

Hi Danny,

Danny Milosavljevic <dannym@scratchpost.org> skribis:

> On Wed, 27 Mar 2019 16:26:55 +0100
> Ludovic Courtès <ludo@gnu.org> wrote:
>
>> Anyway, you’re still very much welcome to test the installer!  See the
>> manual on how to build the installation image:
>> 
>>   https://gnu.org/software/guix/manual/en/html_node/Building-the-Installation-Image.html
>
> I've tried this on qemu and had the infamous "waiting for udev" problem Mark
> also saw on Hydra before.

Oh?!  We have an open bug report on this, right?

> After rebooting, the same image worked fine.
> The installer also works fine and looks great!

Cool.

> Also, I used the non-iso9660 disk image because the iso9660 disk image (not documented
> on the page above either) has 1.5 MB (not a typo).
>
> $ file /gnu/store/lcx2w0y6pi6av4qhipmwc9xjzy4p7gbd-image.iso
> /gnu/store/lcx2w0y6pi6av4qhipmwc9xjzy4p7gbd-image.iso: DOS/MBR boot sector; GRand Unified Bootloader, stage1 version 0x79, boot drive 0xbb, stage2 address 0x8e70, 1st sector stage2 0xb8db31c3, stage2 segment 0x201; partition 1 : ID=0xee, start-CHS (0x0,0,2), end-CHS (0x3f8,9,12), startsector 1, 3121451 sectors, extended partition table (last)
>
> $ stat /gnu/store/lcx2w0y6pi6av4qhipmwc9xjzy4p7gbd-image.iso
>   File: /gnu/store/lcx2w0y6pi6av4qhipmwc9xjzy4p7gbd-image.iso
>   Size: 1495040         Blocks: 2920       IO Block: 4096   regular file
> Device: 801h/2049d      Inode: 34661153    Links: 2
> Access: (0444/-r--r--r--)  Uid: (    0/    root)   Gid: (    0/    root)
> Access: 2019-03-27 23:25:26.240200749 +0100
> Modify: 1970-01-01 01:00:01.000000000 +0100
> Change: 2019-03-27 23:25:26.248200669 +0100
>  Birth: -

Weird.  I tested the ISO image as well and it did produce a valid ISO
image (more than 1 GiB).  What command did you type, from which commit?

Thanks,
Ludo’.

Re: Status update on 1.0

[pelzflorian (Florian Pelz)]

On Wed, Mar 27, 2019 at 04:26:55PM +0100, Ludovic Courtès wrote:
> Anyway, you’re still very much welcome to test the installer!  See the
> manual on how to build the installation image:
> 

I tested an old install image a few weeks old and the
locales/languages in the language selection at the beginning were
apparently not sorted by their English name, but the English name was
displayed, so the sorted order was wrong.  Also, will the locale
chosen at the beginning affect the installer’s locale and use
translations?  (I know there are no translated po files yet for the
installer, but would they get used?)  Would it be possible to first
select the locale in the installer and then select a manual
non-installer setup and be shown the info manual for the chosen locale
instead of the English info manual?

Also in my old install image the image cannot boot on my AMD Radeon
because it gets stuck at

[    9.334790] fb0: switching to radeondrmfb from EFI VGA

but I believe this issue is known and it was said to be due to KMScon
and maybe it is fixed in a current image.

KMScon vs. AMD Radeon

[Ludovic Courtès]

Hello,

"pelzflorian (Florian Pelz)" <pelzflorian@pelzflorian.de> skribis:

> Also in my old install image the image cannot boot on my AMD Radeon
> because it gets stuck at
>
> [    9.334790] fb0: switching to radeondrmfb from EFI VGA
>
> but I believe this issue is known and it was said to be due to KMScon
> and maybe it is fixed in a current image.

Mathieu, would you be available to sketch a solution to this problem
soonish?  I think you and others proposed possible workarounds already,
and I’d rather let someone knowledgeable look into it.

Thanks,
Ludo’.

Re: KMScon vs. AMD Radeon

[Mathieu Othacehe]

Hello,

> Mathieu, would you be available to sketch a solution to this problem
> soonish?  I think you and others proposed possible workarounds already,
> and I’d rather let someone knowledgeable look into it.

Ok, I'll try to propose a patch soon. Florian could you give me the
output of the following command on your machine with the AMD GPU:

--8<---------------cut here---------------start------------->8---
ls /sys/class/drm
--8<---------------cut here---------------end--------------->8---

Thanks,

Mathieu

Re: KMScon vs. AMD Radeon

[pelzflorian (Florian Pelz)]

On Fri, Mar 29, 2019 at 05:35:07PM +0100, Mathieu Othacehe wrote:
> 
> Hello,
> 
> > Mathieu, would you be available to sketch a solution to this problem
> > soonish?  I think you and others proposed possible workarounds already,
> > and I’d rather let someone knowledgeable look into it.
> 
> Ok, I'll try to propose a patch soon. Florian could you give me the
> output of the following command on your machine with the AMD GPU:
> 
> --8<---------------cut here---------------start------------->8---
> ls /sys/class/drm
> --8<---------------cut here---------------end--------------->8---
> 
> Thanks,
> 
> Mathieu

On Arch Linux it shows:

[florian@floriandesktoppc ~]$ ls /sys/class/drm                  
card0  card0-DVI-D-1  card0-HDMI-A-1  card0-VGA-1  renderD128  ttm  version
[florian@floriandesktoppc ~]$ 

Re: KMScon vs. AMD Radeon

[Mathieu Othacehe]

> On Arch Linux it shows:
>
> [florian@floriandesktoppc ~]$ ls /sys/class/drm                  
> card0  card0-DVI-D-1  card0-HDMI-A-1  card0-VGA-1  renderD128  ttm  version
> [florian@floriandesktoppc ~]$ 

That's strange I was expecting this folder to be almost empty. Could you
do the same test from a GuixSD iso image, the 0.16 would be fine?

For the record, here's the output that Pierre Neidhardt gave me:

Without amdgpu:

--8<---------------cut here---------------start------------->8---
/sys/class/drm/ttm
/sys/class/drm/version
--8<---------------cut here---------------end--------------->8---

With amdgpu:
--8<---------------cut here---------------start------------->8---
/sys/class/drm/card0
/sys/class/drm/card0-DP-1
/sys/class/drm/card0-DP-2
/sys/class/drm/card0-DVI-D-1
/sys/class/drm/card0-HDMI-A-1
/sys/class/drm/card0-HDMI-A-2
/sys/class/drm/renderD128
/sys/class/drm/ttm
/sys/class/drm/version

Thanks for your help,

Mathieu

Re: KMScon vs. AMD Radeon

[Pierre Neidhardt]

[-- Attachment #1: Type: text/plain, Size: 640 bytes --]

Mathieu Othacehe <m.othacehe@gmail.com> writes:

>> On Arch Linux it shows:
>>
>> [florian@floriandesktoppc ~]$ ls /sys/class/drm                  
>> card0  card0-DVI-D-1  card0-HDMI-A-1  card0-VGA-1  renderD128  ttm  version
>> [florian@floriandesktoppc ~]$ 
>
> That's strange I was expecting this folder to be almost empty.

Florian said this output came from Arch Linux, which by default ships
the nonfree amdgpu.

In my understanding, this matches my output.

To sum up, if /sys/class/drm/card* or /sys/class/drm/render* files are
found then KMS is probably supported.

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]

Re: KMScon vs. AMD Radeon

[pelzflorian (Florian Pelz)]

On Sat, Mar 30, 2019 at 09:40:19AM +0100, Pierre Neidhardt wrote:
> Mathieu Othacehe <m.othacehe@gmail.com> writes:
> 
> >> On Arch Linux it shows:
> >>
> >> [florian@floriandesktoppc ~]$ ls /sys/class/drm                  
> >> card0  card0-DVI-D-1  card0-HDMI-A-1  card0-VGA-1  renderD128  ttm  version
> >> [florian@floriandesktoppc ~]$ 
> >
> > That's strange I was expecting this folder to be almost empty.
> 
> Florian said this output came from Arch Linux, which by default ships
> the nonfree amdgpu.
> 

On Guix System 0.16 the directory /sys/class/drm contains only
ttm and version.

Re: KMScon vs. AMD Radeon

[Mathieu Othacehe]

[-- Attachment #1: Type: text/plain, Size: 329 bytes --]


Hello,

> On Guix System 0.16 the directory /sys/class/drm contains only
> ttm and version.

Ok, thanks for testing.

Here's a patch that fallback to mingetty if kmscon is not supported. I
don't have a machine with AMD GPU for testing so if Florian or Pierre
could test the patch that would be very helpful :)

Thanks,

Mathieu

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-wip-Fallback-to-mingetty-if-kmscon-is-not-supported.patch --]
[-- Type: text/x-diff, Size: 14598 bytes --]

From f728749dc02f8bb8a1870925547d96d8ce352f55 Mon Sep 17 00:00:00 2001
From: Mathieu Othacehe <m.othacehe@gmail.com>
Date: Mon, 1 Apr 2019 15:54:26 +0200
Subject: [PATCH] wip: Fallback to mingetty if kmscon is not supported.

---
 gnu/services/base.scm  |  29 +++--
 gnu/system/install.scm | 240 +++++++++++++++++++++++------------------
 2 files changed, 160 insertions(+), 109 deletions(-)

diff --git a/gnu/services/base.scm b/gnu/services/base.scm
index 04b123b833..fde2cdbcfb 100644
--- a/gnu/services/base.scm
+++ b/gnu/services/base.scm
@@ -1105,12 +1105,18 @@ the tty to run, among other things."
   (login-program  mingetty-login-program          ;gexp
                   (default #f))
   (login-pause?   mingetty-login-pause?           ;Boolean
-                  (default #f)))
+                  (default #f))
+  ;; Boolean
+  ;; XXX: This should really be handled in an orthogonal way, for instance as
+  ;; proposed in <https://bugs.gnu.org/27155>.  Keep it internal/undocumented
+  ;; for now.
+  (%auto-start?   mingetty-auto-start?
+                  (default #t)))
 
 (define mingetty-shepherd-service
   (match-lambda
     (($ <mingetty-configuration> mingetty tty auto-login login-program
-                                 login-pause?)
+                                 login-pause? %auto-start?)
      (list
       (shepherd-service
        (documentation "Run mingetty on an tty.")
@@ -1140,7 +1146,8 @@ the tty to run, among other things."
                         #$@(if login-pause?
                                #~("--loginpause")
                                #~()))))
-       (stop   #~(make-kill-destructor)))))))
+       (stop   #~(make-kill-destructor))
+       (auto-start? %auto-start?))))))
 
 (define mingetty-service-type
   (service-type (name 'mingetty)
@@ -2146,7 +2153,13 @@ This service is not part of @var{%base-services}."
   (auto-login              kmscon-configuration-auto-login
                            (default #f))
   (hardware-acceleration?  kmscon-configuration-hardware-acceleration?
-                           (default #f))) ; #t causes failure
+                           (default #f))  ; #t causes failure
+  ;; Boolean
+  ;; XXX: This should really be handled in an orthogonal way, for instance as
+  ;; proposed in <https://bugs.gnu.org/27155>.  Keep it internal/undocumented
+  ;; for now.
+  (%auto-start?            kmscon-configuration-auto-start?
+                           (default #t)))
 
 (define kmscon-service-type
   (shepherd-service-type
@@ -2157,7 +2170,8 @@ This service is not part of @var{%base-services}."
            (login-program (kmscon-configuration-login-program config))
            (login-arguments (kmscon-configuration-login-arguments config))
            (auto-login (kmscon-configuration-auto-login config))
-           (hardware-acceleration? (kmscon-configuration-hardware-acceleration? config)))
+           (hardware-acceleration? (kmscon-configuration-hardware-acceleration? config))
+           (auto-start? (kmscon-configuration-auto-start? config)))
 
        (define kmscon-command
          #~(list
@@ -2174,9 +2188,10 @@ This service is not part of @var{%base-services}."
        (shepherd-service
         (documentation "kmscon virtual terminal")
         (requirement '(user-processes udev dbus-system))
-        (provision (list (symbol-append 'term- (string->symbol virtual-terminal))))
+        (provision (list (symbol-append 'kmscon- (string->symbol virtual-terminal))))
         (start #~(make-forkexec-constructor #$kmscon-command))
-        (stop #~(make-kill-destructor)))))))
+        (stop #~(make-kill-destructor))
+        (auto-start? auto-start?))))))
 
 (define-record-type* <static-networking>
   static-networking make-static-networking
diff --git a/gnu/system/install.scm b/gnu/system/install.scm
index aad1deb913..b9c58691d4 100644
--- a/gnu/system/install.scm
+++ b/gnu/system/install.scm
@@ -209,6 +209,45 @@ the user's target storage device rather than on the RAM disk."
                     (persistent? #f)
                     (max-database-size (* 5 (expt 2 20)))))) ;5 MiB
 
+(define (installer-services)
+  (define is-kmscon-supported?
+    #~(let ((drm-regex (make-regexp "(card|render).*$")))
+        (not (null? (scandir "/sys/class/drm"
+                             (cut regexp-exec drm-regex <>))))))
+
+  (let ((mingetty
+         (service mingetty-service-type
+                  (mingetty-configuration
+                   (tty "tty1")
+                   (auto-login "root")
+                   (%auto-start? #f))))
+        (kmscon
+         (service kmscon-service-type
+                  (kmscon-configuration
+                   (virtual-terminal "tty1")
+                   (login-program (installer-program))
+                   (%auto-start? #f)))))
+    (list
+     mingetty
+     kmscon
+     (service
+      (shepherd-service-type
+       'installer-tty
+       (lambda _
+         (shepherd-service
+          (provision '(installer-tty))
+          (requirement '(user-processes host-name udev virtual-terminal))
+          (start #~(lambda _
+                     (if #$is-kmscon-supported?
+                         (start 'kmscon-tty1)
+                         (start 'term-tty1))))
+          (stop #~(make-kill-destructor))
+          (modules `((ice-9 ftw)
+                     (ice-9 regex)
+                     (srfi srfi-26)
+                     ,@%default-modules)))))
+      '()))))
+
 (define %installation-services
   ;; List of services of the installation system.
   (let ((motd (plain-file "motd" "
@@ -228,108 +267,105 @@ You have been warned.  Thanks for being so brave.\x1b[0m
     (define bare-bones-os
       (load "examples/bare-bones.tmpl"))
 
-    (list (service virtual-terminal-service-type)
-
-          (service kmscon-service-type
-                   (kmscon-configuration
-                    (virtual-terminal "tty1")
-                    (login-program (installer-program))))
-
-          (login-service (login-configuration
-                          (motd motd)))
-
-          ;; Documentation.  The manual is in UTF-8, but
-          ;; 'console-font-service' sets up Unicode support and loads a font
-          ;; with all the useful glyphs like em dash and quotation marks.
-          (mingetty-service (mingetty-configuration
-                             (tty "tty2")
-                             (auto-login "guest")
-                             (login-program (log-to-info))))
-
-          ;; Documentation add-on.
-          %configuration-template-service
-
-          ;; A bunch of 'root' ttys.
-          (normal-tty "tty3")
-          (normal-tty "tty4")
-          (normal-tty "tty5")
-          (normal-tty "tty6")
-
-          ;; The usual services.
-          (syslog-service)
-
-          ;; The build daemon.  Register the hydra.gnu.org key as trusted.
-          ;; This allows the installation process to use substitutes by
-          ;; default.
-          (service guix-service-type
-                   (guix-configuration (authorize-key? #t)))
-
-          ;; Start udev so that useful device nodes are available.
-          ;; Use device-mapper rules for cryptsetup & co; enable the CRDA for
-          ;; regulations-compliant WiFi access.
-          (udev-service #:rules (list lvm2 crda))
-
-          ;; Add the 'cow-store' service, which users have to start manually
-          ;; since it takes the installation directory as an argument.
-          (cow-store-service)
-
-          ;; Install Unicode support and a suitable font.  Use a font that
-          ;; doesn't have more than 256 glyphs so that we can use colors with
-          ;; varying brightness levels (see note in setfont(8)).
-          (service console-font-service-type
-                   (map (lambda (tty)
-                          (cons tty "lat9u-16"))
-                        '("tty1" "tty2" "tty3" "tty4" "tty5" "tty6")))
-
-          ;; To facilitate copy/paste.
-          (service gpm-service-type)
-
-          ;; Add an SSH server to facilitate remote installs.
-          (service openssh-service-type
-                   (openssh-configuration
-                    (port-number 22)
-                    (permit-root-login #t)
-                    ;; The root account is passwordless, so make sure
-                    ;; a password is set before allowing logins.
-                    (allow-empty-passwords? #f)
-                    (password-authentication? #t)
-
-                    ;; Don't start it upfront.
-                    (%auto-start? #f)))
-
-          ;; Since this is running on a USB stick with a overlayfs as the root
-          ;; file system, use an appropriate cache configuration.
-          (nscd-service (nscd-configuration
-                         (caches %nscd-minimal-caches)))
-
-          ;; Having /bin/sh is a good idea.  In particular it allows Tramp
-          ;; connections to this system to work.
-          (service special-files-service-type
-                   `(("/bin/sh" ,(file-append (canonical-package bash)
-                                              "/bin/sh"))))
-
-          ;; Loopback device, needed by OpenSSH notably.
-          (service static-networking-service-type
-                   (list (static-networking (interface "lo")
-                                            (ip "127.0.0.1")
-                                            (requirement '())
-                                            (provision '(loopback)))))
-
-          (service wpa-supplicant-service-type)
-          (dbus-service)
-          (service connman-service-type
-                   (connman-configuration
-                    (disable-vpn? #t)))
-
-          ;; Keep a reference to BARE-BONES-OS to make sure it can be
-          ;; installed without downloading/building anything.  Also keep the
-          ;; things needed by 'profile-derivation' to minimize the amount of
-          ;; download.
-          (service gc-root-service-type
-                   (list bare-bones-os
-                         glibc-utf8-locales
-                         texinfo
-                         (canonical-package guile-2.2))))))
+    (append
+     (installer-services)
+     (list (service virtual-terminal-service-type)
+
+           (login-service (login-configuration
+                           (motd motd)))
+
+           ;; Documentation.  The manual is in UTF-8, but
+           ;; 'console-font-service' sets up Unicode support and loads a font
+           ;; with all the useful glyphs like em dash and quotation marks.
+           (mingetty-service (mingetty-configuration
+                              (tty "tty2")
+                              (auto-login "guest")
+                              (login-program (log-to-info))))
+
+           ;; Documentation add-on.
+           %configuration-template-service
+
+           ;; A bunch of 'root' ttys.
+           (normal-tty "tty3")
+           (normal-tty "tty4")
+           (normal-tty "tty5")
+           (normal-tty "tty6")
+
+           ;; The usual services.
+           (syslog-service)
+
+           ;; The build daemon.  Register the hydra.gnu.org key as trusted.
+           ;; This allows the installation process to use substitutes by
+           ;; default.
+           (service guix-service-type
+                    (guix-configuration (authorize-key? #t)))
+
+           ;; Start udev so that useful device nodes are available.
+           ;; Use device-mapper rules for cryptsetup & co; enable the CRDA for
+           ;; regulations-compliant WiFi access.
+           (udev-service #:rules (list lvm2 crda))
+
+           ;; Add the 'cow-store' service, which users have to start manually
+           ;; since it takes the installation directory as an argument.
+           (cow-store-service)
+
+           ;; Install Unicode support and a suitable font.  Use a font that
+           ;; doesn't have more than 256 glyphs so that we can use colors with
+           ;; varying brightness levels (see note in setfont(8)).
+           (service console-font-service-type
+                    (map (lambda (tty)
+                           (cons tty "lat9u-16"))
+                         '("tty1" "tty2" "tty3" "tty4" "tty5" "tty6")))
+
+           ;; To facilitate copy/paste.
+           (service gpm-service-type)
+
+           ;; Add an SSH server to facilitate remote installs.
+           (service openssh-service-type
+                    (openssh-configuration
+                     (port-number 22)
+                     (permit-root-login #t)
+                     ;; The root account is passwordless, so make sure
+                     ;; a password is set before allowing logins.
+                     (allow-empty-passwords? #f)
+                     (password-authentication? #t)
+
+                     ;; Don't start it upfront.
+                     (%auto-start? #f)))
+
+           ;; Since this is running on a USB stick with a overlayfs as the root
+           ;; file system, use an appropriate cache configuration.
+           (nscd-service (nscd-configuration
+                          (caches %nscd-minimal-caches)))
+
+           ;; Having /bin/sh is a good idea.  In particular it allows Tramp
+           ;; connections to this system to work.
+           (service special-files-service-type
+                    `(("/bin/sh" ,(file-append (canonical-package bash)
+                                               "/bin/sh"))))
+
+           ;; Loopback device, needed by OpenSSH notably.
+           (service static-networking-service-type
+                    (list (static-networking (interface "lo")
+                                             (ip "127.0.0.1")
+                                             (requirement '())
+                                             (provision '(loopback)))))
+
+           (service wpa-supplicant-service-type)
+           (dbus-service)
+           (service connman-service-type
+                    (connman-configuration
+                     (disable-vpn? #t)))
+
+           ;; Keep a reference to BARE-BONES-OS to make sure it can be
+           ;; installed without downloading/building anything.  Also keep the
+           ;; things needed by 'profile-derivation' to minimize the amount of
+           ;; download.
+           (service gc-root-service-type
+                    (list bare-bones-os
+                          glibc-utf8-locales
+                          texinfo
+                          (canonical-package guile-2.2)))))))
 
 (define %issue
   ;; Greeting.
-- 
2.17.1

Re: KMScon vs. AMD Radeon

[Ludovic Courtès]

Hi Mathieu,

Mathieu Othacehe <m.othacehe@gmail.com> skribis:

> Here's a patch that fallback to mingetty if kmscon is not supported. I
> don't have a machine with AMD GPU for testing so if Florian or Pierre
> could test the patch that would be very helpful :)

That was fast, thanks!

We’ll wait for your feedback Florian & Pierre.  :-)

> From f728749dc02f8bb8a1870925547d96d8ce352f55 Mon Sep 17 00:00:00 2001
> From: Mathieu Othacehe <m.othacehe@gmail.com>
> Date: Mon, 1 Apr 2019 15:54:26 +0200
> Subject: [PATCH] wip: Fallback to mingetty if kmscon is not supported.

[...]

> +  (define is-kmscon-supported?
> +    #~(let ((drm-regex (make-regexp "(card|render).*$")))
> +        (not (null? (scandir "/sys/class/drm"
> +                             (cut regexp-exec drm-regex <>))))))

No need for “is-”.  :-)

> +  (let ((mingetty
> +         (service mingetty-service-type
> +                  (mingetty-configuration
> +                   (tty "tty1")
> +                   (auto-login "root")
> +                   (%auto-start? #f))))
> +        (kmscon
> +         (service kmscon-service-type
> +                  (kmscon-configuration
> +                   (virtual-terminal "tty1")
> +                   (login-program (installer-program))
> +                   (%auto-start? #f)))))
> +    (list
> +     mingetty
> +     kmscon
> +     (service
> +      (shepherd-service-type
> +       'installer-tty
> +       (lambda _
> +         (shepherd-service
> +          (provision '(installer-tty))
> +          (requirement '(user-processes host-name udev virtual-terminal))
> +          (start #~(lambda _
> +                     (if #$is-kmscon-supported?
> +                         (start 'kmscon-tty1)
> +                         (start 'term-tty1))))
> +          (stop #~(make-kill-destructor))
> +          (modules `((ice-9 ftw)
> +                     (ice-9 regex)
> +                     (srfi srfi-26)
> +                     ,@%default-modules)))))
> +      '()))))

Should we instead build this functionality into ‘kmscon-service-type’,
possibly with a flag to turn it off?

Thank you!

Ludo’.

Re: KMScon vs. AMD Radeon

[Mathieu Othacehe]

Hey Ludo,

Thanks for reviewing :)

> Should we instead build this functionality into ‘kmscon-service-type’,
> possibly with a flag to turn it off?

Well I thought about it, but if kmscon-service-type does the DRM support detection
and exits "cleanly", how could we fallback to mingetty?

Thanks,

Mathieu

Re: KMScon vs. AMD Radeon

[Danny Milosavljevic]

[-- Attachment #1: Type: text/plain, Size: 701 bytes --]

Hi Mathieu,

I would prefer if we just passed "nomodeset" to the Linux kernel in the installer image (in the installer image only) in order to disable all those funny drivers in the first place.

Then, grub would use vesa in order to initialize graphics - which should have seen testing for... forever... years.

We could use "set gfxmode=..." in grub in order to set a specific graphics mode.

(The Linux kernel module is called uvesafb--but it should be picked up automatically)

(Use "vbeinfo" in the grub prompt in order to find out whether it's using VESA)

I don't think it's wise to complicate bootup when we could just use vesa.  There's nothing wrong with it as far as I know...

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: KMScon vs. AMD Radeon

[pelzflorian (Florian Pelz)]

On Tue, Apr 02, 2019 at 06:31:40PM +0200, Danny Milosavljevic wrote:
> Hi Mathieu,
> 
> I would prefer if we just passed "nomodeset" to the Linux kernel in the installer image (in the installer image only) in order to disable all those funny drivers in the first place.
> 
> Then, grub would use vesa in order to initialize graphics - which should have seen testing for... forever... years.
> 
> We could use "set gfxmode=..." in grub in order to set a specific graphics mode.
> 
> (The Linux kernel module is called uvesafb--but it should be picked up automatically)
> 
> (Use "vbeinfo" in the grub prompt in order to find out whether it's using VESA)
> 
> I don't think it's wise to complicate bootup when we could just use vesa.  There's nothing wrong with it as far as I know...


Not using KMScon would prevent support for the Chinese and Japanese
language during install, would it not?

Currently there is no support because

· the Chinese and Japanese locales are not added to the installer, it
  only includes glibc-utf8-locales,

· there is no translated PO file for the installer yet anyway,

but otherwise it would work, would it not?

However, this means in particular that

· when using KMScon, the installer should change the locale that gets
  used once it is selected,

· when using mingetty, the locale should only be changed for languages
  other than Chinese and Japanese,

· the console font should be changed to match the locale similar to
  console-setup on Debian.

Maybe some of this is already supported, I don’t know.

Regards,
Florian

Re: KMScon vs. AMD Radeon

[Mathieu Othacehe]

Hello Florian,

> Not using KMScon would prevent support for the Chinese and Japanese
> language during install, would it not?

Yes and for other languages too.

> Currently there is no support because
>
> · the Chinese and Japanese locales are not added to the installer, it
>   only includes glibc-utf8-locales,
>
> · there is no translated PO file for the installer yet anyway,
>
> but otherwise it would work, would it not?

Yes, I tried to add Japanese translations into an existing PO and it
worked fine with the installer.

>
> However, this means in particular that
>
> · when using KMScon, the installer should change the locale that gets
>   used once it is selected,

It's done :)

>
> · when using mingetty, the locale should only be changed for languages
>   other than Chinese and Japanese,

When using mingetty, the logic with the patch you tested is to fallback
to a raw terminal and force a "manual" install.

>
> · the console font should be changed to match the locale similar to
>   console-setup on Debian.

The installer uses GNU Unifont so that most unicode characters are
covered.

Mathieu

Re: KMScon vs. AMD Radeon

[pelzflorian (Florian Pelz)]

On Wed, Apr 03, 2019 at 09:19:01AM +0200, Mathieu Othacehe wrote:
> 
> Hello Florian,
> 
> > Not using KMScon would prevent support for the Chinese and Japanese
> > language during install, would it not?
> 
> Yes and for other languages too.
> 

Other languages could work with a console font appropriate for the
language, I think.  Only a limited number of characters can be
supported, but the limited number is sufficient for other languages
once the appropriate subset of characters is selected.  Nevertheless
Chinese characters are important and too many.




> > Currently there is no support because
> >
> > · the Chinese and Japanese locales are not added to the installer, it
> >   only includes glibc-utf8-locales,
> >
> > · there is no translated PO file for the installer yet anyway,
> >
> > but otherwise it would work, would it not?
> 
> Yes, I tried to add Japanese translations into an existing PO and it
> worked fine with the installer.
> 
> >
> > However, this means in particular that
> >
> > · when using KMScon, the installer should change the locale that gets
> >   used once it is selected,
> 
> It's done :)
> 
> >
> > · when using mingetty, the locale should only be changed for languages
> >   other than Chinese and Japanese,
> 
> When using mingetty, the logic with the patch you tested is to fallback
> to a raw terminal and force a "manual" install.
> 
> >
> > · the console font should be changed to match the locale similar to
> >   console-setup on Debian.
> 
> The installer uses GNU Unifont so that most unicode characters are
> covered.
> 
> Mathieu

OK, thank you!

Re: KMScon vs. AMD Radeon

[Danny Milosavljevic]

[-- Attachment #1: Type: text/plain, Size: 541 bytes --]

On Wed, 03 Apr 2019 09:19:01 +0200
Mathieu Othacehe <m.othacehe@gmail.com> wrote:

> Hello Florian,
> 
> > Not using KMScon would prevent support for the Chinese and Japanese
> > language during install, would it not?  
> 
> Yes and for other languages too.

Yeah, but doesn't kmscon support vesa?  I mean I know the name kinda implies
kernel modesetting, but doesn't it have a framebuffer fallback?

I do mean we keep graphics terminal, but just use vesa instead of kms in order
to set the graphics mode up.  (If that works)

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: KMScon vs. AMD Radeon

[Ludovic Courtès]

Danny Milosavljevic <dannym@scratchpost.org> skribis:

> On Wed, 03 Apr 2019 09:19:01 +0200
> Mathieu Othacehe <m.othacehe@gmail.com> wrote:
>
>> Hello Florian,
>> 
>> > Not using KMScon would prevent support for the Chinese and Japanese
>> > language during install, would it not?  
>> 
>> Yes and for other languages too.
>
> Yeah, but doesn't kmscon support vesa?  I mean I know the name kinda implies
> kernel modesetting, but doesn't it have a framebuffer fallback?
>
> I do mean we keep graphics terminal, but just use vesa instead of kms in order
> to set the graphics mode up.  (If that works)

I agree that this would be the best option, if it’s possible.  (I’m
surprised kmscon doesn’t automatically fall back to the framebuffer on
these AMD things.)

Ludo’.

Re: KMScon vs. AMD Radeon

[Mathieu Othacehe]

Hey Danny,

I don't get very well the Linux graphics stack but my understanding is
that passing "nomodeset" to Linux will disable KMS and thus kmscon won't
work. Is that correct ?

I'm going to try it on my hardware today to see how it goes anyway.

Thank you,

Mathieu

Re: KMScon vs. AMD Radeon

[Danny Milosavljevic]

[-- Attachment #1: Type: text/plain, Size: 848 bytes --]

Hi Mathieu,

> I don't get very well the Linux graphics stack but my understanding is
> that passing "nomodeset" to Linux will disable KMS and thus kmscon won't
> work. Is that correct ?

I don't know.  It might be the case but I doubt it.  Why would kmscon remove
a perfectly fine fallback that's pretty similar to use anyway?

There's an example in kmscon's README that has:

    $ ./configure --with-video=fbdev,drm2d [...]

Reading configure.ac, I get the impression that this means that there are two
backends then, fbdev and drm2d, and the user can select one.

I suggest that we use fbdev (maybe at runtime, but maybe just disable everything
else :P).

I'm very much minimalist especially in system installers.  So many things can
go wrong and it's much better to have *some* system than to have no system
installed :)

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: KMScon vs. AMD Radeon

[Danny Milosavljevic]

[-- Attachment #1: Type: text/plain, Size: 606 bytes --]

> I suggest that we use fbdev (maybe at runtime, but maybe just disable everything
> else :P).

Selecting it at runtime should work well.

I've read kmscon source now and they wait for udev events in order to choose backends.

Once an udev event arrives, they check the result of udev_device_get_subsystem().
If it's "drm", they'll use [drm3d or] drm2d.
If it's "graphics", they'll use fbdev.

So it supports fbdev just fine and will select it when drm is unavailable.

(Note that on ARM, drm is required, otherwise you won't have video.  VESA
BIOS setup doesn't exist there--and never did)

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: KMScon vs. AMD Radeon

[Ludovic Courtès]

Danny Milosavljevic <dannym@scratchpost.org> skribis:

>> I suggest that we use fbdev (maybe at runtime, but maybe just disable everything
>> else :P).
>
> Selecting it at runtime should work well.
>
> I've read kmscon source now and they wait for udev events in order to choose backends.
>
> Once an udev event arrives, they check the result of udev_device_get_subsystem().
> If it's "drm", they'll use [drm3d or] drm2d.
> If it's "graphics", they'll use fbdev.
>
> So it supports fbdev just fine and will select it when drm is unavailable.

To summarize, we’re just missing ‘--with-video=fbdev,drm2d’ and then
we’re done, right?

That’d be sweet.

Ludo’.

Re: KMScon vs. AMD Radeon

[Danny Milosavljevic]

[-- Attachment #1: Type: text/plain, Size: 473 bytes --]

> To summarize, we’re just missing ‘--with-video=fbdev,drm2d’ and then
> we’re done, right?

Reading the kmscon source code (configure.ac), it seems that the default
is "fbdev,drm2d,drm3d".

I suspect that the drm hangs the kernel in Florian's case.

It indeed might make sense to try whether "--with-video=fbdev,drm2d"
(i.e. without "drm3d") improves things, and if not, just disable drm
modesetting at bootup.  If it's not there then it can't break :P

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: KMScon vs. AMD Radeon

[pelzflorian (Florian Pelz)]

On Wed, Apr 03, 2019 at 11:02:44PM +0200, Danny Milosavljevic wrote:
> > To summarize, we’re just missing ‘--with-video=fbdev,drm2d’ and then
> > we’re done, right?
> 
> Reading the kmscon source code (configure.ac), it seems that the default
> is "fbdev,drm2d,drm3d".
> 
> I suspect that the drm hangs the kernel in Florian's case.
> 

Maybe, the message was this:

On Thu, Mar 28, 2019 at 01:09:35AM +0100, pelzflorian (Florian Pelz) wrote:
> Also in my old install image the image cannot boot on my AMD Radeon
> because it gets stuck at
> 
> [    9.334790] fb0: switching to radeondrmfb from EFI VGA
> 

Re: KMScon vs. AMD Radeon

[Mathieu Othacehe]

[-- Attachment #1: Type: text/plain, Size: 244 bytes --]


Hi all,

Thanks for your investigation Danny. Florian and Pierre, could you try
this new patch :) ?

If it fails, you can also try to press 'e' in GRUB and add 'nomodeset'
to the kernel command line arguments.

Thanks for your help,

Mathieu


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-wip-Disable-drm-backend-for-install-kmscon.patch --]
[-- Type: text/x-diff, Size: 2040 bytes --]

From f90ea22ee4af2db11587b6195c3726f9bab9ec78 Mon Sep 17 00:00:00 2001
From: Mathieu Othacehe <m.othacehe@gmail.com>
Date: Thu, 4 Apr 2019 09:31:31 +0200
Subject: [PATCH] wip: Disable drm backend for install kmscon.

---
 gnu/packages/terminals.scm | 9 +++++++++
 gnu/system/install.scm     | 2 ++
 2 files changed, 11 insertions(+)

diff --git a/gnu/packages/terminals.scm b/gnu/packages/terminals.scm
index 2d46585865..740443aab1 100644
--- a/gnu/packages/terminals.scm
+++ b/gnu/packages/terminals.scm
@@ -40,6 +40,7 @@
   #:use-module (guix download)
   #:use-module (guix git-download)
   #:use-module (guix packages)
+  #:use-module (guix utils)
   #:use-module (gnu packages)
   #:use-module (gnu packages autotools)
   #:use-module (gnu packages check)
@@ -308,6 +309,14 @@ multi-seat support, a replacement for @command{mingetty}, and more.")
       (supported-systems (filter (cut string-suffix? "-linux" <>)
                                  %supported-systems)))))
 
+(define-public kmscon-fbdev-only
+  (package
+    (inherit kmscon)
+    (name "kmscon-fbdev-only")
+    (arguments
+     `(#:configure-flags '("--with-video=fbdev")
+       ,@(package-arguments kmscon)))))
+
 (define-public libtermkey
   (package
     (name "libtermkey")
diff --git a/gnu/system/install.scm b/gnu/system/install.scm
index aad1deb913..6d0d7cfd48 100644
--- a/gnu/system/install.scm
+++ b/gnu/system/install.scm
@@ -45,6 +45,7 @@
   #:use-module (gnu packages cryptsetup)
   #:use-module (gnu packages package-management)
   #:use-module (gnu packages disk)
+  #:use-module (gnu packages terminals)
   #:use-module (gnu packages texinfo)
   #:use-module (gnu packages compression)
   #:use-module (gnu packages nvi)
@@ -232,6 +233,7 @@ You have been warned.  Thanks for being so brave.\x1b[0m
 
           (service kmscon-service-type
                    (kmscon-configuration
+                    (kmscon kmscon-fbdev-only)
                     (virtual-terminal "tty1")
                     (login-program (installer-program))))
 
-- 
2.17.1


[-- Attachment #3: Type: text/plain, Size: 695 bytes --]


pelzflorian (Florian Pelz) writes:

> On Wed, Apr 03, 2019 at 11:02:44PM +0200, Danny Milosavljevic wrote:
>> > To summarize, we’re just missing ‘--with-video=fbdev,drm2d’ and then
>> > we’re done, right?
>> 
>> Reading the kmscon source code (configure.ac), it seems that the default
>> is "fbdev,drm2d,drm3d".
>> 
>> I suspect that the drm hangs the kernel in Florian's case.
>> 
>
> Maybe, the message was this:
>
> On Thu, Mar 28, 2019 at 01:09:35AM +0100, pelzflorian (Florian Pelz) wrote:
>> Also in my old install image the image cannot boot on my AMD Radeon
>> because it gets stuck at
>> 
>> [    9.334790] fb0: switching to radeondrmfb from EFI VGA
>> 

Re: KMScon vs. AMD Radeon

[Mathieu Othacehe]

I did test the patch on my hardware (kmscon with forced fbdev backend):

* By default, kmscon is loaded, everything seems ok.
* Passing nomodeset to the kernel, kmscon hangs with a black screen, but
I'm able to switch to other mingetty terminals.

Not sure what is going wrong, but I fear it won't be much better on your
AMD GPUs :(

Mathieu

Mathieu Othacehe writes:

> Hi all,
>
> Thanks for your investigation Danny. Florian and Pierre, could you try
> this new patch :) ?
>
> If it fails, you can also try to press 'e' in GRUB and add 'nomodeset'
> to the kernel command line arguments.
>
> Thanks for your help,
>
> Mathieu
>
> From f90ea22ee4af2db11587b6195c3726f9bab9ec78 Mon Sep 17 00:00:00 2001
> From: Mathieu Othacehe <m.othacehe@gmail.com>
> Date: Thu, 4 Apr 2019 09:31:31 +0200
> Subject: [PATCH] wip: Disable drm backend for install kmscon.
>
> ---
>  gnu/packages/terminals.scm | 9 +++++++++
>  gnu/system/install.scm     | 2 ++
>  2 files changed, 11 insertions(+)
>
> diff --git a/gnu/packages/terminals.scm b/gnu/packages/terminals.scm
> index 2d46585865..740443aab1 100644
> --- a/gnu/packages/terminals.scm
> +++ b/gnu/packages/terminals.scm
> @@ -40,6 +40,7 @@
>    #:use-module (guix download)
>    #:use-module (guix git-download)
>    #:use-module (guix packages)
> +  #:use-module (guix utils)
>    #:use-module (gnu packages)
>    #:use-module (gnu packages autotools)
>    #:use-module (gnu packages check)
> @@ -308,6 +309,14 @@ multi-seat support, a replacement for @command{mingetty}, and more.")
>        (supported-systems (filter (cut string-suffix? "-linux" <>)
>                                   %supported-systems)))))
>  
> +(define-public kmscon-fbdev-only
> +  (package
> +    (inherit kmscon)
> +    (name "kmscon-fbdev-only")
> +    (arguments
> +     `(#:configure-flags '("--with-video=fbdev")
> +       ,@(package-arguments kmscon)))))
> +
>  (define-public libtermkey
>    (package
>      (name "libtermkey")
> diff --git a/gnu/system/install.scm b/gnu/system/install.scm
> index aad1deb913..6d0d7cfd48 100644
> --- a/gnu/system/install.scm
> +++ b/gnu/system/install.scm
> @@ -45,6 +45,7 @@
>    #:use-module (gnu packages cryptsetup)
>    #:use-module (gnu packages package-management)
>    #:use-module (gnu packages disk)
> +  #:use-module (gnu packages terminals)
>    #:use-module (gnu packages texinfo)
>    #:use-module (gnu packages compression)
>    #:use-module (gnu packages nvi)
> @@ -232,6 +233,7 @@ You have been warned.  Thanks for being so brave.\x1b[0m
>  
>            (service kmscon-service-type
>                     (kmscon-configuration
> +                    (kmscon kmscon-fbdev-only)
>                      (virtual-terminal "tty1")
>                      (login-program (installer-program))))

Re: KMScon vs. AMD Radeon

[pelzflorian (Florian Pelz)]

On Thu, Apr 04, 2019 at 03:49:35PM +0200, Mathieu Othacehe wrote:
> 
> I did test the patch on my hardware (kmscon with forced fbdev backend):
> 
> * By default, kmscon is loaded, everything seems ok.
> * Passing nomodeset to the kernel, kmscon hangs with a black screen, but
> I'm able to switch to other mingetty terminals.
> 
> Not sure what is going wrong, but I fear it won't be much better on your
> AMD GPUs :(
> 
> Mathieu
> 

I got exactly the same result on my grandma’s 10-years-old laptop.  I
just found out it is using an old AMD GPU too (AMD RS780M).

Re: KMScon vs. AMD Radeon

[Danny Milosavljevic]

[-- Attachment #1: Type: text/plain, Size: 487 bytes --]

Hi,

On Thu, 4 Apr 2019 18:07:48 +0200
"pelzflorian (Florian Pelz)" <pelzflorian@pelzflorian.de> wrote:

> I got exactly the same result on my grandma’s 10-years-old laptop.  I
> just found out it is using an old AMD GPU too (AMD RS780M).

:(

What does

  readlink /sys/class/drm/card0/subsystem

say after passing "nomodeset" to the kernel ?

Does it still say "drm" ?


Other than that, it might help to update the system bios, but that's a shitty workaround.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: KMScon vs. AMD Radeon

[pelzflorian (Florian Pelz)]

On Sat, Apr 06, 2019 at 11:05:43AM +0200, Danny Milosavljevic wrote:
> Hi,
> 
> On Thu, 4 Apr 2019 18:07:48 +0200
> "pelzflorian (Florian Pelz)" <pelzflorian@pelzflorian.de> wrote:
> 
> > I got exactly the same result on my grandma’s 10-years-old laptop.  I
> > just found out it is using an old AMD GPU too (AMD RS780M).
> 
> :(
> 
> What does
> 
>   readlink /sys/class/drm/card0/subsystem
> 
> say after passing "nomodeset" to the kernel ?
> 
> Does it still say "drm" ?
> 
> 

There is no card0.  There is only ttm and version.

readlink /sys/class/drm/card0/subsystem

gives no output at all.

readlink /sys/class/drm/ttm/subsystem

gives

../../../../class/drm



> Other than that, it might help to update the system bios, but that's a shitty workaround.
> 


That would not be an acceptable workaround IMO.

Thank you for all your work!

Re: KMScon vs. AMD Radeon

[pelzflorian (Florian Pelz)]

On Thu, Apr 04, 2019 at 06:07:48PM +0200, pelzflorian (Florian Pelz) wrote:
> On Thu, Apr 04, 2019 at 03:49:35PM +0200, Mathieu Othacehe wrote:
> > 
> > I did test the patch on my hardware (kmscon with forced fbdev backend):
> > 
> > * By default, kmscon is loaded, everything seems ok.
> > * Passing nomodeset to the kernel, kmscon hangs with a black screen, but
> > I'm able to switch to other mingetty terminals.
> > 
> > Not sure what is going wrong, but I fear it won't be much better on your
> > AMD GPUs :(
> > 
> > Mathieu
> > 
> 
> I got exactly the same result on my grandma’s 10-years-old laptop.  I
> just found out it is using an old AMD GPU too (AMD RS780M).
> 

The installer starts when specifying modprobe.blacklist=radeon on the
kernel commandline.

Re: KMScon vs. AMD Radeon

[pelzflorian (Florian Pelz)]

On Sun, Apr 14, 2019 at 11:48:59AM +0200, pelzflorian (Florian Pelz) wrote:
> The installer starts when specifying modprobe.blacklist=radeon on the
> kernel commandline.
> 

This applies to the Guix System installer in git master *without*
patches.

Deniz at Parabola GNU/Linux-libre discussed a similar issue for
Parabola today:

  Here what would need to be publicized would be how to blacklist the
radeon driver at boot, in the case something goes wrong and the user
is left with a black screen during the boot of linux-libre.

  On Parabola adding "modprobe.blacklist=radeon" to the kernel command
line does that at boot. This enables users to easily use the
installation medias.

<https://lists.parabola.nu/pipermail/assist/2019-April/001366.html>

Deniz also wrote that this would break HDMI, but HDMI does not work
for me in the Guix installer anyway (but possibly it worked for
others?)

Regards,
Florian

Re: KMScon vs. AMD Radeon

[Ludovic Courtès]

[-- Attachment #1: Type: text/plain, Size: 834 bytes --]

Hello,

"pelzflorian (Florian Pelz)" <pelzflorian@pelzflorian.de> skribis:

> Deniz at Parabola GNU/Linux-libre discussed a similar issue for
> Parabola today:
>
>   Here what would need to be publicized would be how to blacklist the
> radeon driver at boot, in the case something goes wrong and the user
> is left with a black screen during the boot of linux-libre.
>
>   On Parabola adding "modprobe.blacklist=radeon" to the kernel command
> line does that at boot. This enables users to easily use the
> installation medias.
>
> <https://lists.parabola.nu/pipermail/assist/2019-April/001366.html>
>
> Deniz also wrote that this would break HDMI, but HDMI does not work
> for me in the Guix installer anyway (but possibly it worked for
> others?)

If that’s the best option we have so far, we can do this:


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: Type: text/x-patch, Size: 533 bytes --]

diff --git a/gnu/system/install.scm b/gnu/system/install.scm
index d887313132..5776938f10 100644
--- a/gnu/system/install.scm
+++ b/gnu/system/install.scm
@@ -426,6 +426,7 @@ Access documentation at any time by pressing Alt-F2.\x1b[0m
                  (target "/dev/sda")))
     (label (string-append "GNU Guix installation "
                           (package-version guix)))
+    (kernel-arguments '("modprobe.blacklist=radeon"))
 
     (file-systems
      ;; Note: the disk image build code overrides this root file system with

[-- Attachment #3: Type: text/plain, Size: 25 bytes --]


Thoughts?

Ludo’.

Re: KMScon vs. AMD Radeon

[pelzflorian (Florian Pelz)]

On Mon, Apr 15, 2019 at 02:09:57PM +0200, Ludovic Courtès wrote:
> If that’s the best option we have so far, we can do this:
> 

The patch works fine, but:

The resolution is slightly too small to read all text boxes in the
installer’s disk partitioning dialog though.  The screen height is
only about 35 lines.  I don’t know how to fix this, but it is not that
important.

The installer got stuck in a bash prompt at the end (which is probably
unrelated to AMD).  I exited the bash prompt and got an installer
dialog message with a button to Reboot, but it did not reboot.

Then the installed system has no graphics too (graphics freeze at the
same message

[   51.910992] fb0: switching to radeondrmfb from EFI VGA

but I cannot add modprobe.blacklist=radeon because GRUB does not
recognize my USB keyboard now (in the installer’s GRUB the USB
keyboard was recognized).

Regards,
Florian

Re: KMScon vs. AMD Radeon

[pelzflorian (Florian Pelz)]

On Wed, Apr 17, 2019 at 07:26:27PM +0200, pelzflorian (Florian Pelz) wrote:
> Then the installed system has no graphics too (graphics freeze at the
> same message
> 
> [   51.910992] fb0: switching to radeondrmfb from EFI VGA
> 
> but I cannot add modprobe.blacklist=radeon because GRUB does not
> recognize my USB keyboard now (in the installer’s GRUB the USB
> keyboard was recognized).
> 

I dug out a PS/2 keyboard which works.  When adding
modprobe.blacklist=radeon then GDM does not start.
/var/log/gdm/greeter.log contains beside various expected errors for
fbdev:

(EE) open /dev/fb0: Permission denied


So i did

chmod 777 /dev/fb0
herd restart xorg-server

but it still says permission denied on /dev/fb0.

Regards,
Florian

Re: KMScon vs. AMD Radeon

[pelzflorian (Florian Pelz)]

On Thu, Apr 18, 2019 at 09:05:39AM +0200, pelzflorian (Florian Pelz) wrote:
> I dug out a PS/2 keyboard which works.  When adding
> modprobe.blacklist=radeon then GDM does not start.
> /var/log/gdm/greeter.log contains beside various expected errors for
> fbdev:
> 
> (EE) open /dev/fb0: Permission denied
> 
> 
> So i did
> 
> chmod 777 /dev/fb0
> herd restart xorg-server
> 
> but it still says permission denied on /dev/fb0.
> 
> Regards,
> Florian
> 

No the error is gone.  I checked the wrong log file.  It just finds no
screen.

Re: KMScon vs. AMD Radeon

[Ludovic Courtès]

[-- Attachment #1: Type: text/plain, Size: 1429 bytes --]

Hi,

"pelzflorian (Florian Pelz)" <pelzflorian@pelzflorian.de> skribis:

> On Mon, Apr 15, 2019 at 02:09:57PM +0200, Ludovic Courtès wrote:
>> If that’s the best option we have so far, we can do this:
>> 
>
> The patch works fine, but:
>
> The resolution is slightly too small to read all text boxes in the
> installer’s disk partitioning dialog though.  The screen height is
> only about 35 lines.  I don’t know how to fix this, but it is not that
> important.

Do you mean the resolution is too low?  Are there fewer lines that in
the QEMU screenshot below?

> The installer got stuck in a bash prompt at the end (which is probably
> unrelated to AMD).  I exited the bash prompt and got an installer
> dialog message with a button to Reboot, but it did not reboot.

It got stuck after ‘guix system init’ had completed, right?

Were there any hints in /var/log/messages or tty12?

> Then the installed system has no graphics too (graphics freeze at the
> same message
>
> [   51.910992] fb0: switching to radeondrmfb from EFI VGA
>
> but I cannot add modprobe.blacklist=radeon because GRUB does not
> recognize my USB keyboard now (in the installer’s GRUB the USB
> keyboard was recognized).

Weird.  What keyboard layout had you selected?

Is it UEFI or “BIOS”?

(Also, I gather dd’ing to a USB key worked this time, right?)

Thanks a lot for testing!

Ludo’.


[-- Attachment #2: screenshot --]
[-- Type: image/png, Size: 45290 bytes --]

Re: KMScon vs. AMD Radeon

[pelzflorian (Florian Pelz)]

On Thu, Apr 18, 2019 at 11:47:04PM +0200, Ludovic Courtès wrote:
> "pelzflorian (Florian Pelz)" <pelzflorian@pelzflorian.de> skribis:
> > On Mon, Apr 15, 2019 at 02:09:57PM +0200, Ludovic Courtès wrote:
> > The resolution is slightly too small to read all text boxes in the
> > installer’s disk partitioning dialog though.  The screen height is
> > only about 35 lines.  I don’t know how to fix this, but it is not that
> > important.
> 
> Do you mean the resolution is too low?  Are there fewer lines that in
> the QEMU screenshot below?
> 

Yes, there are fewer lines.  The line above “Choose the language” is
the first visible line.  The header -| Locale language |- is
invisible.  The bottom of the window with ----------------- is the
last visible line.  That makes for 31 lines in total.



> > The installer got stuck in a bash prompt at the end (which is probably
> > unrelated to AMD).  I exited the bash prompt and got an installer
> > dialog message with a button to Reboot, but it did not reboot.
>
> It got stuck after ‘guix system init’ had completed, right?
> 

Yes.  I just installed anew.  Right after “bootloader successfully
installed on '/boot/efi'”, a bash prompt is shown and accepts input:

bash-4.4#



> Were there any hints in /var/log/messages or tty12?
> 



The last messages in tty12 as well as in /var/log/messages are

Apr 19 13:11:18 localhost shepherd[1]: Service cow-store has been started.
Apr 19 13:25:51 localhost connmand[483]: ntp: adjust (slew): -0.014120 sec

so presumably the only thing that was logged after installation
started is a boring NTP adjust.

An approximate transcription of what pstree shows:

|
|-kmscon---8kj92lqap405nfs---9xd24lv3gpp5qgh---bash---pstree
|                          |                 \-9*[{9xd24lv3gpp5qgh}]
|                           \-7&[{8kj92lqap405nfs}]

According to ps output, 8kj is installer and 9xd is installer-real.

I do not know how to attach to 9xd with gdb.

Either way, once I quit bash I get an -| Installation complete |-
message.




> > Then the installed system has no graphics too (graphics freeze at the
> > same message
> >
> > [   51.910992] fb0: switching to radeondrmfb from EFI VGA
> >
> > but I cannot add modprobe.blacklist=radeon because GRUB does not
> > recognize my USB keyboard now (in the installer’s GRUB the USB
> > keyboard was recognized).
> 
> Weird.  What keyboard layout had you selected?
> 

English (US) intl. with AltGr dead keys.




> Is it UEFI or “BIOS”?
> 

UEFI.




> (Also, I gather dd’ing to a USB key worked this time, right?)
> 

Yes.  This machine boots Guix git master fine, the ISO 9p cache issue
is fixed, other issues with booting on my Macbook are not an issue on
this machine.

Regards,
Florian

Re: KMScon vs. AMD Radeon

[Ludovic Courtès]

Hi Florian,

"pelzflorian (Florian Pelz)" <pelzflorian@pelzflorian.de> skribis:

> On Thu, Apr 18, 2019 at 11:47:04PM +0200, Ludovic Courtès wrote:
>> "pelzflorian (Florian Pelz)" <pelzflorian@pelzflorian.de> skribis:
>> > On Mon, Apr 15, 2019 at 02:09:57PM +0200, Ludovic Courtès wrote:
>> > The resolution is slightly too small to read all text boxes in the
>> > installer’s disk partitioning dialog though.  The screen height is
>> > only about 35 lines.  I don’t know how to fix this, but it is not that
>> > important.
>> 
>> Do you mean the resolution is too low?  Are there fewer lines that in
>> the QEMU screenshot below?
>> 
>
> Yes, there are fewer lines.  The line above “Choose the language” is
> the first visible line.  The header -| Locale language |- is
> invisible.  The bottom of the window with ----------------- is the
> last visible line.  That makes for 31 lines in total.

OK, so that’s suboptimal, but do you still consider it usable
nonetheless?

(I’m trying to see if we can simply use the modprobe.blacklist patch or
if we need to work on a more elaborate solution.)

> Yes.  This machine boots Guix git master fine, the ISO 9p cache issue
> is fixed, other issues with booting on my Macbook are not an issue on
> this machine.

OK, so I take this as a mostly-successful experience.  I’m willing to
ignore the MacBook issue for now, at least not blocking 1.0 for that.

Thanks a lot for testing and reporting back!

Ludo’.

Re: KMScon vs. AMD Radeon

[pelzflorian (Florian Pelz)]

On Fri, Apr 19, 2019 at 05:17:31PM +0200, Ludovic Courtès wrote:
> OK, so that’s suboptimal, but do you still consider it usable
> nonetheless?
> 

Yes, the installer is usable.  Its just when using Manual partitioning
that the message

You can change a disk's partition table by \
selecting it and pressing ENTER. You can also edit a partition by selecting it \
and pressing ENTER, or remove it by pressing DELETE. To create a new \
partition, select a free space area and press ENTER.


is clipped to

ENTER. You can also edit a partition by selecting it \
and pressing ENTER, or remove it by pressing DELETE. To create a new \
partition, select a free space area and press ENTER.

It is not very important.  But:




> (I’m trying to see if we can simply use the modprobe.blacklist patch or
> if we need to work on a more elaborate solution.)
> 

The important remaining issue is that Xorg does not start on this
computer.  Neither the radeon nor fbdev and not even vesa works, for
whatever reason.  fbdev apparently is not supported.  VESA might be a
fixable bug (it displays “(EE) VESA(0): Cannot read int vect” like
<https://bugs.launchpad.net/xserver-xorg-driver-vesa/+bug/1432899>).
On other AMD GPUs the results may be more successful.  I have not
tried other free distributions on this PC yet.

I believe issues with (some?) AMD GPUs should be mentioned in the
manual.  Also, on the downloads page perhaps it should be mentioned
that there may be issues with some hardware, referring users to the
Hardware Considerations in the Guix manual.

Regards,
Florian

Re: KMScon vs. AMD Radeon

[pelzflorian (Florian Pelz)]

On Fri, Apr 19, 2019 at 07:11:17PM +0200, pelzflorian (Florian Pelz) wrote:
> The important remaining issue is that Xorg does not start on this
> computer.  Neither the radeon nor fbdev and not even vesa works, for
> whatever reason.  fbdev apparently is not supported.  VESA might be a
> fixable bug (it displays “(EE) VESA(0): Cannot read int vect” like
> <https://bugs.launchpad.net/xserver-xorg-driver-vesa/+bug/1432899>).
> On other AMD GPUs the results may be more successful.  I have not
> tried other free distributions on this PC yet.
> 

fbdev works for Xorg on the AMD GPU on Trisquel and Debian with
800x600 resolution at 75 Hz refresh rate.  It displays: “(==) Depth 24
pixmap format is 32 bpp”.

Perhaps the Guix config for fbdev is wrong.  I do not find a fbdev
configuration in xorg.conf.d, but I find none on Debian either.  This
is strange.

Regards,
Florian

Re: KMScon vs. AMD Radeon

[Ludovic Courtès]

Hi,

"pelzflorian (Florian Pelz)" <pelzflorian@pelzflorian.de> skribis:

> On Fri, Apr 19, 2019 at 05:17:31PM +0200, Ludovic Courtès wrote:
>> OK, so that’s suboptimal, but do you still consider it usable
>> nonetheless?
>> 
>
> Yes, the installer is usable.  Its just when using Manual partitioning
> that the message
>
> You can change a disk's partition table by \
> selecting it and pressing ENTER. You can also edit a partition by selecting it \
> and pressing ENTER, or remove it by pressing DELETE. To create a new \
> partition, select a free space area and press ENTER.
>
>
> is clipped to
>
> ENTER. You can also edit a partition by selecting it \
> and pressing ENTER, or remove it by pressing DELETE. To create a new \
> partition, select a free space area and press ENTER.
>
> It is not very important.

OK, so I’ll push the “modprobe.blacklist=radeon” trick.

> The important remaining issue is that Xorg does not start on this
> computer.  Neither the radeon nor fbdev and not even vesa works, for
> whatever reason.  fbdev apparently is not supported.  VESA might be a
> fixable bug (it displays “(EE) VESA(0): Cannot read int vect” like
> <https://bugs.launchpad.net/xserver-xorg-driver-vesa/+bug/1432899>).
> On other AMD GPUs the results may be more successful.  I have not
> tried other free distributions on this PC yet.

So basically GNU/Linux distros in general fail to work on machines with
these GPUs?

> I believe issues with (some?) AMD GPUs should be mentioned in the
> manual.  Also, on the downloads page perhaps it should be mentioned
> that there may be issues with some hardware, referring users to the
> Hardware Considerations in the Guix manual.

We could do that, but these kind of kernel-side issues tend to appear
and vanish quickly, no?  But I don’t know much about these AMD GPU
issues, so I’m happy to do what people consider appropriate.

Thanks,
Ludo’.

Re: KMScon vs. AMD Radeon

[pelzflorian (Florian Pelz)]

On Sat, Apr 20, 2019 at 11:47:56AM +0200, Ludovic Courtès wrote:
> So basically GNU/Linux distros in general fail to work on machines with
> these GPUs?
> 

The radeon driver requires nonfree firmware.  This is the core issue
which is not going to get fixed anytime soon.  There appear to be
partial fixes for some cards, for example I see mailing list threads
like https://www.fsfla.org/pipermail/linux-libre/2015-July/003080.html

Xorg on fbdev fails on Guix but works on other distros with 800×600
resolution at 75 Hz for my AMD GPU.

Regards,
Florian

Re: KMScon vs. AMD Radeon

[Pierre Neidhardt]

[-- Attachment #1: Type: text/plain, Size: 1160 bytes --]

Ludovic Courtès <ludo@gnu.org> writes:

>> The important remaining issue is that Xorg does not start on this
>> computer.  Neither the radeon nor fbdev and not even vesa works, for
>> whatever reason.  fbdev apparently is not supported.  VESA might be a
>> fixable bug (it displays “(EE) VESA(0): Cannot read int vect” like
>> <https://bugs.launchpad.net/xserver-xorg-driver-vesa/+bug/1432899>).
>> On other AMD GPUs the results may be more successful.  I have not
>> tried other free distributions on this PC yet.
>
> So basically GNU/Linux distros in general fail to work on machines with
> these GPUs?

No, many AMD GPUs work well I think.  My AMD Radeon RX 580 works very
well out of the box (minus a few things like hibernation), except with
KMSCON, apparently.

If I understand correctly, there are 3 drivers:

- radeon
- ati
- amdgpu

The latter seems to work fine on recent cards, but it won't work with
older chipsets.
I'm not too sure about the difference between radeon and ati.  

Maybe Florian's issue is with an older card that does not support
"ati" or "amdgpu".

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]

Re: KMScon vs. AMD Radeon

[pelzflorian (Florian Pelz)]

This is interesting.  I presume if you add modprobe.blacklist=radeon
to the kernel commandline, your system is degraded, e.g. the
resolution is lower?  The installer probably would have a lower
resolution, too, when booting it with modprobe.blacklist=radeon?  Or
maybe the radeon kernel module is not used at all?

Are you using current linux-libre or are you using an old kernel?

On Sat, Apr 20, 2019 at 12:16:43PM +0200, Pierre Neidhardt wrote:
> Maybe Florian's issue is with an older card that does not support
> "ati" or "amdgpu".
> 

lspci reports my card as Radeon R7 240/340.  According to Wikipedia
this GPU was released in 2013.  Xorg attempted to load the radeon
driver and not amdgpu.

Regards,
Florian

Re: KMScon vs. AMD Radeon

[Félicien Pillot]

[-- Attachment #1: Type: text/plain, Size: 1022 bytes --]

Le Sat, 20 Apr 2019 12:39:57 +0200,
"pelzflorian (Florian Pelz)" <pelzflorian@pelzflorian.de> a écrit :

> lspci reports my card as Radeon R7 240/340.  According to Wikipedia
> this GPU was released in 2013.  Xorg attempted to load the radeon
> driver and not amdgpu.
> 
> Regards,
> Florian

I also have a Radeon R7 240/340. lspci -k outputs these lines:

> 01:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] Oland PRO [Radeon R7 240/340] (rev 87)
>         Subsystem: ASUSTeK Computer Inc. Oland PRO [Radeon R7 240/340]
>         Kernel driver in use: radeon
>         Kernel modules: radeon, amdgpu

I tried a lot, but couldn't manage to start Xorg with amdgpu. Actually I can't either use linux-libre if I want a good resolution (1920x1080), I have to inject binary firmwares, as explained at https://wiki.gentoo.org/wiki/Amdgpu#Incorporating_firmware

-- 
Félicien Pillot
2C7C ACC0 FBDB ADBA E7BC  50D9 043C D143 6C87 9372
felicien@gnu.org - felicien.pillot@riseup.net

[-- Attachment #2: Signature digitale OpenPGP --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: KMScon vs. AMD Radeon

[Pierre Neidhardt]

[-- Attachment #1: Type: text/plain, Size: 1321 bytes --]


Félicien Pillot <felicien@gnu.org> writes:

> Le Sat, 20 Apr 2019 12:39:57 +0200,
> "pelzflorian (Florian Pelz)" <pelzflorian@pelzflorian.de> a écrit :
>
>> lspci reports my card as Radeon R7 240/340.  According to Wikipedia
>> this GPU was released in 2013.  Xorg attempted to load the radeon
>> driver and not amdgpu.
>> 
>> Regards,
>> Florian
>
> I also have a Radeon R7 240/340. lspci -k outputs these lines:
>
>> 01:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] Oland PRO [Radeon R7 240/340] (rev 87)
>>         Subsystem: ASUSTeK Computer Inc. Oland PRO [Radeon R7 240/340]
>>         Kernel driver in use: radeon
>>         Kernel modules: radeon, amdgpu
>
> I tried a lot, but couldn't manage to start Xorg with amdgpu. Actually I can't either use linux-libre if I want a good resolution (1920x1080), I have to inject binary firmwares, as explained at https://wiki.gentoo.org/wiki/Amdgpu#Incorporating_firmware

Both Florian and Félicien's reports are to be expected according to
https://en.wikipedia.org/wiki/AMD_Radeon_Rx_300_series#Radeon_Feature_Matrix.

"amdgpu" mostly supports Volcanic Islands and later.
The 240/340 Southern Island / Sea Island, so it can only use radeon if I
understand correctly.

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]

Re: KMScon vs. AMD Radeon

[Pierre Neidhardt]

[-- Attachment #1: Type: text/plain, Size: 611 bytes --]

OK, apparently it's possible to force AMDGPU onto Southern Island / Sea
Island:

https://wiki.archlinux.org/index.php/AMDGPU#Enable_Southern_Islands_(SI)_and_Sea_Islands_(CIK)_support

We'd need to things:

- enable the following in linux-libre

--8<---------------cut here---------------start------------->8---
# CONFIG_DRM_AMDGPU_SI is not set
# CONFIG_DRM_AMDGPU_CIK is not set
--8<---------------cut here---------------end--------------->8---

- Make sure amdgpu is loaded before radeon.  Can we do that in the
  operating-system declaration?

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]

Re: KMScon vs. AMD Radeon

[Ludovic Courtès]

Pierre Neidhardt <mail@ambrevar.xyz> skribis:

> OK, apparently it's possible to force AMDGPU onto Southern Island / Sea
> Island:
>
> https://wiki.archlinux.org/index.php/AMDGPU#Enable_Southern_Islands_(SI)_and_Sea_Islands_(CIK)_support
>
> We'd need to things:
>
> - enable the following in linux-libre
>
> # CONFIG_DRM_AMDGPU_SI is not set
> # CONFIG_DRM_AMDGPU_CIK is not set

OK, sounds easy.

> - Make sure amdgpu is loaded before radeon.  Can we do that in the
>   operating-system declaration?

No, how would you achieve that?

Thanks,
Ludo’.

Re: KMScon vs. AMD Radeon

[Pierre Neidhardt]

[-- Attachment #1: Type: text/plain, Size: 417 bytes --]

Ludovic Courtès <ludo@gnu.org> writes:

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

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

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]

Re: KMScon vs. AMD Radeon

[pelzflorian (Florian Pelz)]

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

It seems like this does not help.


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

I added the above definitions

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

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

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

[   8.679377] fb0: switching to radeondrmfb from EFI VGA

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

Now I add modprobe.blacklist=radeon and get

[   9.507629] fb0: switching to amdgpudrmfb from EFI VGA

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

Regards,
Florian

Re: KMScon vs. AMD Radeon

[pelzflorian (Florian Pelz)]

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

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

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

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


Before these messages, I see on Guix:

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

On Debian, I see:

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


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

Re: KMScon vs. AMD Radeon

[pelzflorian (Florian Pelz)]

On Sat, Apr 20, 2019 at 11:47:56AM +0200, Ludovic Courtès wrote:
> "pelzflorian (Florian Pelz)" <pelzflorian@pelzflorian.de> skribis:
> > I believe issues with (some?) AMD GPUs should be mentioned in the
> > manual.  Also, on the downloads page perhaps it should be mentioned
> > that there may be issues with some hardware, referring users to the
> > Hardware Considerations in the Guix manual.
> 
> We could do that, but these kind of kernel-side issues tend to appear
> and vanish quickly, no?  But I don’t know much about these AMD GPU
> issues, so I’m happy to do what people consider appropriate.
> 

My AMD GPU machine started working with VESA Xorg drivers at full resolution.
I reconfigured a while ago but did not test back then.

Regards,
Florian

Re: KMScon vs. AMD Radeon

[pelzflorian (Florian Pelz)]

On Mon, Apr 01, 2019 at 10:01:58PM +0200, Ludovic Courtès wrote:
> Hi Mathieu,
> 
> Mathieu Othacehe <m.othacehe@gmail.com> skribis:
> 
> > Here's a patch that fallback to mingetty if kmscon is not supported. I
> > don't have a machine with AMD GPU for testing so if Florian or Pierre
> > could test the patch that would be very helpful :)
> 
> That was fast, thanks!
> 
> We’ll wait for your feedback Florian & Pierre.  :-)
> 

I applied Mathieu’s patch to current Guix, but the kernel panics on
QEMU and on non-AMD Radeon hardware.  I have not tried on AMD Radeon
yet.  I will first try again an older Guix without the patch but it
will take a few hours.

Regards,
Florian

Re: KMScon vs. AMD Radeon

[pelzflorian (Florian Pelz)]

On Tue, Apr 02, 2019 at 11:26:05AM +0200, pelzflorian (Florian Pelz) wrote:
> On Mon, Apr 01, 2019 at 10:01:58PM +0200, Ludovic Courtès wrote:
> > Hi Mathieu,
> > 
> > Mathieu Othacehe <m.othacehe@gmail.com> skribis:
> > 
> > > Here's a patch that fallback to mingetty if kmscon is not supported. I
> > > don't have a machine with AMD GPU for testing so if Florian or Pierre
> > > could test the patch that would be very helpful :)
> > 
> > That was fast, thanks!
> > 
> > We’ll wait for your feedback Florian & Pierre.  :-)
> > 
> 
> I applied Mathieu’s patch to current Guix, but the kernel panics on
> QEMU and on non-AMD Radeon hardware.  I have not tried on AMD Radeon
> yet.  I will first try again an older Guix without the patch but it
> will take a few hours.
> 

So guix pulling the old Guix commit
37099f58442419ebd847616ffe21b19c4b655a41 without the patch boots fine
on QEMU and my grandma’s 10-years-old non-AMD BIOS laptop.

The more current commit 0e558640361b6ab4aac0f424cb587b21a642bab8
without the patch runs into a Guile prompt because of an error in
resolve-variable of something with setuid-binaries on grandma’s laptop
and into a different error and a Guile prompt on QEMU with
[   9.426604] random: dbus-uuidgen: uninitialized urandom read (12 bytes read)
[   9.518845] attempt to access beyond end of device
[   9.519037] sda: rw=524288, want=3194596, limit=3184000
ERROR: In procedure primitive-load:
In procedure fport_read: Input/output error

0e558640361b6ab4aac0f424cb587b21a642bab8 with the AMD Radeon patch
runs into a kernel panic on QEMU and grandma’s laptop.  I have not
tested AMD Radeon.

Regards,
Florian

Re: KMScon vs. AMD Radeon

[pelzflorian (Florian Pelz)]

On Tue, Apr 02, 2019 at 01:42:38PM +0200, pelzflorian (Florian Pelz) wrote:
> The more current commit 0e558640361b6ab4aac0f424cb587b21a642bab8
> without the patch runs into a Guile prompt because of an error in
> resolve-variable of something with setuid-binaries on grandma’s laptop
> and into a different error and a Guile prompt on QEMU with
> [   9.426604] random: dbus-uuidgen: uninitialized urandom read (12 bytes read)
> [   9.518845] attempt to access beyond end of device
> [   9.519037] sda: rw=524288, want=3194596, limit=3184000
> ERROR: In procedure primitive-load:
> In procedure fport_read: Input/output error
> 
> 0e558640361b6ab4aac0f424cb587b21a642bab8 with the AMD Radeon patch
> runs into a kernel panic on QEMU and grandma’s laptop.  I have not
> tested AMD Radeon.
> 
> Regards,
> Florian
> 

I am still bisecting.  Will report back.

Re: KMScon vs. AMD Radeon

[pelzflorian (Florian Pelz)]

On Wed, Apr 03, 2019 at 06:17:25AM +0200, pelzflorian (Florian Pelz) wrote:
> On Tue, Apr 02, 2019 at 01:42:38PM +0200, pelzflorian (Florian Pelz) wrote:
> > The more current commit 0e558640361b6ab4aac0f424cb587b21a642bab8
> > without the patch runs into a Guile prompt because of an error in
> > resolve-variable of something with setuid-binaries on grandma’s laptop
> > and into a different error and a Guile prompt on QEMU with
> > [   9.426604] random: dbus-uuidgen: uninitialized urandom read (12 bytes read)
> > [   9.518845] attempt to access beyond end of device
> > [   9.519037] sda: rw=524288, want=3194596, limit=3184000
> > ERROR: In procedure primitive-load:
> > In procedure fport_read: Input/output error
> > 
> > 0e558640361b6ab4aac0f424cb587b21a642bab8 with the AMD Radeon patch
> > runs into a kernel panic on QEMU and grandma’s laptop.  I have not
> > tested AMD Radeon.
> > 
> > Regards,
> > Florian
> > 
> 
> I am still bisecting.  Will report back.
> 

For me QEMU does not work since commit
45c0d1d790f01ebc020fc4b2787a6abcdaa3f383

But reverting it means creating the ISO runs out of memory, so I
cannot currently test if Mathieu’s patch works on my AMD GPU PC.

Re: KMScon vs. AMD Radeon

[Pierre Neidhardt]

[-- Attachment #1: Type: text/plain, Size: 877 bytes --]

Ludovic Courtès <ludo@gnu.org> writes:

> Mathieu Othacehe <m.othacehe@gmail.com> skribis:
>
>> Here's a patch that fallback to mingetty if kmscon is not supported. I
>> don't have a machine with AMD GPU for testing so if Florian or Pierre
>> could test the patch that would be very helpful :)
>
> That was fast, thanks!
>
> We’ll wait for your feedback Florian & Pierre.  :-)

Sadly it didn't work for me.
Commit 44e06f9cf39e50f91ba61f3e66981b8d10ad545c, linux 5.0.5.
The kernel boots until those 2 messages:

--8<---------------cut here---------------start------------->8---
[drm amdgpu kernel modesetting enabled
fb0: switching to amdgpudrmfb from EFI VGA
--8<---------------cut here---------------end--------------->8---

From there it hangs, Alt-f2 does not do anything.
Only Ctrl-Alt-Del works :/

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]

Installer & locales

[Ludovic Courtès]

Hello Florian,

"pelzflorian (Florian Pelz)" <pelzflorian@pelzflorian.de> skribis:

> I tested an old install image a few weeks old and the
> locales/languages in the language selection at the beginning were
> apparently not sorted by their English name, but the English name was
> displayed, so the sorted order was wrong.  Also, will the locale
> chosen at the beginning affect the installer’s locale and use
> translations?  (I know there are no translated po files yet for the
> installer, but would they get used?)  Would it be possible to first
> select the locale in the installer and then select a manual
> non-installer setup and be shown the info manual for the chosen locale
> instead of the English info manual?

Lots of questions.  :-)

I moved the language selection dialog to be the very first thing in
commit 850ddf94e86a1711328e39872c7830ad6d5020b4.

It would be nice to show the translated manual according to the chosen
locale (when it exists).

It’d also be nice to display the name of languages natively, rather than
their English name, but I’m not sure if we have data from libc to do
that.

Help welcome!

Ludo’.

Installer & services

[Ludovic Courtès]

Hello Guix!

In commit 7d1030a63592aa2f94f6617786f22cfa83fb346f I added a dialog to
select networking services, currently sshd and Tor.

I realized that for a server kind of installation, it’d be nice to
have NetworkManager or connman in there.  I’ll see if I can add it.

Anything else we could offer there?

Thanks,
Ludo’.

Re: Installer & services

[Ludovic Courtès]

Ludovic Courtès <ludo@gnu.org> skribis:

> In commit 7d1030a63592aa2f94f6617786f22cfa83fb346f I added a dialog to
> select networking services, currently sshd and Tor.
>
> I realized that for a server kind of installation, it’d be nice to
> have NetworkManager or connman in there.  I’ll see if I can add it.

Done in 2e55f37c0c8fdfbc413edff61490161648a78dcc.

Ludo'.

Re: Status update on 1.0

[mikadoZero]

Ludovic Courtès writes:

> ...
> Anyway, you’re still very much welcome to test the installer!  See the
> manual on how to build the installation image:
>
>   https://gnu.org/software/guix/manual/en/html_node/Building-the-Installation-Image.html
> ...

`git describe`
v0.16.0-4215-g1aa662b309

Following the instructions in "3.9 Building the Installation Image" of
the manual, I can create an iso with this command:
`guix system disk-image --file-system-type=iso9660 gnu/system/install.scm`

After booting the iso I see:

* Grub welcome message
* Grub menu with one option
* blinking underscore with no prompt

Once the blinking underscore starts nothing else happens and it does not
respond to keyboard input.

I created the iso on a x86_64 Guix System.

I am trying to use the iso to install Guix System on a i686 computer.
It is nice that Guix System can run on i686.

I think I may need a flag or argument for the above command that to
create an iso for i686.  However looking at "8.14 Invoking ‘guix
system’" and "8.14 Invoking ‘guix system’" of the manual it is not clear
what it would be.

Re: Status update on 1.0

[Ludovic Courtès]

Hello mikadoZero,

mikadoZero <mikadozero@yandex.com> skribis:

> I created the iso on a x86_64 Guix System.
>
> I am trying to use the iso to install Guix System on a i686 computer.

Then the ISO you created cannot run on the i686 machine.

To create an i686 ISO on your x86_64 machine, you need to run:

  guix system disk-image --file-system-type=iso9660 -s i686-linux \
    gnu/system/install.scm

Notice the ‘-s’ flag.

HTH, and thanks for testing!

Ludo’.

Re: Status update on 1.0

[Marius Bakke]

[-- Attachment #1: Type: text/plain, Size: 739 bytes --]

Ludovic Courtès <ludo@gnu.org> writes:

> Hello Guix!
>
> When we said we’d try to release 1.0 for FOSDEM, we were talking about
> FOSDEM *2019*, which is well over now, so I think we need to get our act
> together and complete the remaining tasks for 1.0.  :-)

On the plus side, we still have a lot of time left for FOSDEM 2020...

I don't think we should release 1.0 until at least
<https://bugs.gnu.org/34454> and <https://bugs.gnu.org/34528> are
fixed.  Trying a new distribution only to find your favourite programs
are crashing would be a _terrible_ first impression.

Personally I would like to include the latest GNOME as well as the GCC7
branch for bells *and* whistles.  But that's still a few months off...

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]

Re: Status update on 1.0

[Ludovic Courtès]

Hi!

Marius Bakke <mbakke@fastmail.com> skribis:

> I don't think we should release 1.0 until at least
> <https://bugs.gnu.org/34454> and <https://bugs.gnu.org/34528> are
> fixed.  Trying a new distribution only to find your favourite programs
> are crashing would be a _terrible_ first impression.

Do we have any leads on this IceCat issue?  I use IceCat daily and never
have any problems of this sort, FWIW.

> Personally I would like to include the latest GNOME as well as the GCC7
> branch for bells *and* whistles.  But that's still a few months off...

Ideally I’d like to release by the end of April.  It’d take more time if
we were to wait for the ‘core-updates’ merge; but that’s OK: there’ll be
a 1.0.1 or 1.1 release, too.  :-)

The GNOME branch may be mergeable on time, along with ‘staging’.
Ricardo?

Thanks,
Ludo’.

Re: Status update on 1.0

[Ricardo Wurmus]

Ludovic Courtès <ludo@gnu.org> writes:

>> I don't think we should release 1.0 until at least
>> <https://bugs.gnu.org/34454> and <https://bugs.gnu.org/34528> are
>> fixed.  Trying a new distribution only to find your favourite programs
>> are crashing would be a _terrible_ first impression.
>
> Do we have any leads on this IceCat issue?  I use IceCat daily and never
> have any problems of this sort, FWIW.

I’ve seen something like this before, but *only* on i686 machines.  I
never managed to figure out why.

Can we be sure that this is not due to stale configuration files?  (This
is a medium-sized problem affecting a number of packages that won’t go
away soon.)

> The GNOME branch may be mergeable on time, along with ‘staging’.
> Ricardo?

One of the GNOME update branches (for 2.28?) has already been merged
into staging.  There are rumours of crashes, though, so this will
require testing by more people.

The other GNOME upgrade that I worked on months ago still awaits a
rebase onto staging.  I’ll try to get it into good shape to have the
build farm build it out, so that more people can test it and provide
fixes where needed.

--
Ricardo

‘staging’ and GNOME updates

[Ludovic Courtès]

Hi!

Ricardo Wurmus <rekado@elephly.net> skribis:

> Ludovic Courtès <ludo@gnu.org> writes:
>
>>> I don't think we should release 1.0 until at least
>>> <https://bugs.gnu.org/34454> and <https://bugs.gnu.org/34528> are
>>> fixed.  Trying a new distribution only to find your favourite programs
>>> are crashing would be a _terrible_ first impression.
>>
>> Do we have any leads on this IceCat issue?  I use IceCat daily and never
>> have any problems of this sort, FWIW.
>
> I’ve seen something like this before, but *only* on i686 machines.  I
> never managed to figure out why.

It looks like Mark fixed this in
bc91562939ee002e84c95d13c907482b6d1e9339.  \o/

> One of the GNOME update branches (for 2.28?) has already been merged
> into staging.  There are rumours of crashes, though, so this will
> require testing by more people.

OK, so I guess we should first focus on getting ‘staging’ tested and
merged.

x86_64 substitutes on ci.guix.info cover 60% of the packages right now.
The main issue is that libdrm has one test failure (see
<https://ci.guix.info/log/n3hrfx0yvz6g3xm0zkixahn227lispim-libdrm-2.4.97>):

--8<---------------cut here---------------start------------->8---
starting phase `check'
[0/1] Running all tests.
 1/16 kms-symbol-check                        OK       0.12 s 
 2/16 gen4-3d.batch                           OK       0.04 s 
 3/16 gen45-3d.batch                          OK       0.04 s 
 4/16 gen5-3d.batch                           OK       0.04 s 
 5/16 gen6-3d.batch                           OK       0.04 s 
 6/16 gen7-3d.batch                           OK       0.04 s 
 7/16 gen7-2d-copy.batch                      OK       0.02 s 
 8/16 intel-symbol-check                      OK       0.67 s 
 9/16 nouveau-symbol-check                    OK       0.32 s 
10/16 radeon-symbol-check                     OK       0.37 s 
11/16 amdgpu-symbol-check                     OK       0.52 s 
12/16 threaded                                SKIP     0.01 s 
13/16 random                                  TIMEOUT 240.01 s 
14/16 hash                                    OK       0.02 s 
15/16 drmsl                                   OK       1.23 s 
16/16 drmdevice                               SKIP     0.01 s 

Ok:                   13
Expected Fail:         0
Fail:                  1
Unexpected Pass:       0
Skipped:               2
Timeout:               1


The output from the failed tests:

13/16 random                                  TIMEOUT 240.01 s 
--8<---------------cut here---------------end--------------->8---

> The other GNOME upgrade that I worked on months ago still awaits a
> rebase onto staging.  I’ll try to get it into good shape to have the
> build farm build it out, so that more people can test it and provide
> fixes where needed.

Perhaps we can first merge ‘staging’ in its current form, then make this
branch the new ‘staging’ and aim for a merge as is (with only fixes
committed there.)  How does that sound?

Ludo’.

Re: ‘staging’ and GNOME updates

[Efraim Flashner]

[-- Attachment #1: Type: text/plain, Size: 3713 bytes --]

On Sun, Mar 31, 2019 at 10:52:49PM +0200, Ludovic Courtès wrote:
> Hi!
> 
> Ricardo Wurmus <rekado@elephly.net> skribis:
> 
> > Ludovic Courtès <ludo@gnu.org> writes:
> >
> >>> I don't think we should release 1.0 until at least
> >>> <https://bugs.gnu.org/34454> and <https://bugs.gnu.org/34528> are
> >>> fixed.  Trying a new distribution only to find your favourite programs
> >>> are crashing would be a _terrible_ first impression.
> >>
> >> Do we have any leads on this IceCat issue?  I use IceCat daily and never
> >> have any problems of this sort, FWIW.
> >
> > I’ve seen something like this before, but *only* on i686 machines.  I
> > never managed to figure out why.
> 
> It looks like Mark fixed this in
> bc91562939ee002e84c95d13c907482b6d1e9339.  \o/
> 
> > One of the GNOME update branches (for 2.28?) has already been merged
> > into staging.  There are rumours of crashes, though, so this will
> > require testing by more people.
> 
> OK, so I guess we should first focus on getting ‘staging’ tested and
> merged.
> 
> x86_64 substitutes on ci.guix.info cover 60% of the packages right now.
> The main issue is that libdrm has one test failure (see
> <https://ci.guix.info/log/n3hrfx0yvz6g3xm0zkixahn227lispim-libdrm-2.4.97>):
> 
> --8<---------------cut here---------------start------------->8---
> starting phase `check'
> [0/1] Running all tests.
>  1/16 kms-symbol-check                        OK       0.12 s 
>  2/16 gen4-3d.batch                           OK       0.04 s 
>  3/16 gen45-3d.batch                          OK       0.04 s 
>  4/16 gen5-3d.batch                           OK       0.04 s 
>  5/16 gen6-3d.batch                           OK       0.04 s 
>  6/16 gen7-3d.batch                           OK       0.04 s 
>  7/16 gen7-2d-copy.batch                      OK       0.02 s 
>  8/16 intel-symbol-check                      OK       0.67 s 
>  9/16 nouveau-symbol-check                    OK       0.32 s 
> 10/16 radeon-symbol-check                     OK       0.37 s 
> 11/16 amdgpu-symbol-check                     OK       0.52 s 
> 12/16 threaded                                SKIP     0.01 s 
> 13/16 random                                  TIMEOUT 240.01 s 
> 14/16 hash                                    OK       0.02 s 
> 15/16 drmsl                                   OK       1.23 s 
> 16/16 drmdevice                               SKIP     0.01 s 
> 
> Ok:                   13
> Expected Fail:         0
> Fail:                  1
> Unexpected Pass:       0
> Skipped:               2
> Timeout:               1
> 
> 
> The output from the failed tests:
> 
> 13/16 random                                  TIMEOUT 240.01 s 
> --8<---------------cut here---------------end--------------->8---
> 
> > The other GNOME upgrade that I worked on months ago still awaits a
> > rebase onto staging.  I’ll try to get it into good shape to have the
> > build farm build it out, so that more people can test it and provide
> > fixes where needed.
> 
> Perhaps we can first merge ‘staging’ in its current form, then make this
> branch the new ‘staging’ and aim for a merge as is (with only fixes
> committed there.)  How does that sound?
> 
> Ludo’.
> 

This libdrm test suite timeout looks a lot like the error I was having
in the past on armhf. For armhf it's fixed on staging in fe7c6f91dda,
but it can easily be extended to other/all architectures.

-- 
Efraim Flashner   <efraim@flashner.co.il>   אפרים פלשנר
GPG key = A28B F40C 3E55 1372 662D  14F7 41AA E7DC CA3D 8351
Confidentiality cannot be guaranteed on emails sent or received unencrypted

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: ‘staging’ and GNOME updates

[Ludovic Courtès]

Hi,

Efraim Flashner <efraim@flashner.co.il> skribis:

> This libdrm test suite timeout looks a lot like the error I was having
> in the past on armhf. For armhf it's fixed on staging in fe7c6f91dda,
> but it can easily be extended to other/all architectures.

That looks like the right thing to do.  Marius?

Ludo’.

Re: ‘staging’ and GNOME updates

[Ricardo Wurmus]

Ludovic Courtès <ludo@gnu.org> writes:

>> The other GNOME upgrade that I worked on months ago still awaits a
>> rebase onto staging.  I’ll try to get it into good shape to have the
>> build farm build it out, so that more people can test it and provide
>> fixes where needed.
>
> Perhaps we can first merge ‘staging’ in its current form, then make this
> branch the new ‘staging’ and aim for a merge as is (with only fixes
> committed there.)  How does that sound?

Sounds good.

I just tested the new(er) GNOME on staging and unfortunately it is *not*
working.  I reconfigured my workstation which previously also used
GNOME.

I see a mouse pointer appearing, but gnome-shell never seems to properly
start.  (I’m using auto-login, so I don’t see the GDM login prompt first.)

It would be good to see if this can be reproduced in a stateless system,
e.g. a virtual machine.

I already removed ~/.config/gnome-* and ~/.local/share/gnome-shell*, but
this did not change the behaviour.

Help is very welcome!

--
Ricardo

Re: ‘staging’ and GNOME updates

[Ludovic Courtès]

Hello,

Ricardo Wurmus <rekado@elephly.net> skribis:

> I just tested the new(er) GNOME on staging and unfortunately it is *not*
> working.  I reconfigured my workstation which previously also used
> GNOME.
>
> I see a mouse pointer appearing, but gnome-shell never seems to properly
> start.  (I’m using auto-login, so I don’t see the GDM login prompt first.)
>
> It would be good to see if this can be reproduced in a stateless system,
> e.g. a virtual machine.

Yesterday I did:

  guix pull -p test-staging --branch=staging

and then tested:

  ./test-staging/bin/guix system vm gnu/system/examples/desktop.tmpl

with:

--8<---------------cut here---------------start------------->8---
$ ./test-staging/bin/guix describe
Generacio 3     09 Apr 2019 17:19:31    (nuna)
  guix 0eb01ff
    URL du dépôt : https://git.savannah.gnu.org/git/guix.git
    branche: staging
    commit : 0eb01ff5bbb69944c89d86b1612f5f057dede023
--8<---------------cut here---------------end--------------->8---

Everything in the VM seems to work, as discussed on IRC.

So this suggests that the problem may have to do with state kept
somewhere in GSettings or who knows what.

Could you share logs from /var/log/messages, /var/log/gdm/greeter.log,
and anything that may be relevant?

Thanks,
Ludo’.

Re: ‘staging’ and GNOME updates

[Ludovic Courtès]

Hello,

Ricardo Wurmus <rekado@elephly.net> skribis:

> I just tested the new(er) GNOME on staging and unfortunately it is *not*
> working.  I reconfigured my workstation which previously also used
> GNOME.
>
> I see a mouse pointer appearing, but gnome-shell never seems to properly
> start.  (I’m using auto-login, so I don’t see the GDM login prompt first.)
>
> It would be good to see if this can be reproduced in a stateless system,
> e.g. a virtual machine.

Yesterday I did:

  guix pull -p test-staging --branch=staging

and then tested:

  ./test-staging/bin/guix system vm gnu/system/examples/desktop.tmpl

with:

--8<---------------cut here---------------start------------->8---
$ ./test-staging/bin/guix describe
Generacio 3     09 Apr 2019 17:19:31    (nuna)
  guix 0eb01ff
    URL du dépôt : https://git.savannah.gnu.org/git/guix.git
    branche: staging
    commit : 0eb01ff5bbb69944c89d86b1612f5f057dede023
--8<---------------cut here---------------end--------------->8---

Everything in the VM seems to work, as discussed on IRC.

So this suggests that the problem may have to do with state kept
somewhere in GSettings or who knows what.

Could you share logs from /var/log/messages, /var/log/gdm/greeter.log,
and anything that may be relevant?

Thanks,
Ludo’.

Re: ‘staging’ and GNOME updates

[Ricardo Wurmus]

Ludovic Courtès <ludo@gnu.org> writes:

> Ricardo Wurmus <rekado@elephly.net> skribis:
>
>> I just tested the new(er) GNOME on staging and unfortunately it is *not*
>> working.  I reconfigured my workstation which previously also used
>> GNOME.
>>
>> I see a mouse pointer appearing, but gnome-shell never seems to properly
>> start.  (I’m using auto-login, so I don’t see the GDM login prompt first.)
[…]
> Everything in the VM seems to work, as discussed on IRC.
>
> So this suggests that the problem may have to do with state kept
> somewhere in GSettings or who knows what.
>
> Could you share logs from /var/log/messages, /var/log/gdm/greeter.log,
> and anything that may be relevant?

The logs are not helpful at all.  I even went through an strace of gdm
and couldn’t find anything interesting amidst all the noise.

Turns out that the problem was with a stale /var/lib/gdm – which makes
me wonder: we do we have this at all?  “/var/lib/gdm” is the “gdm” user
account’s home directory.  But it’s not like this really needs to be
persistent, I think.

I moved it out of the way and the gdm login prompt appeared within a few
seconds.  After restarting xorg-server the directory was recreated.

Now, I *still* cannot actually log in, but the problem is likely very
similar.

[two minutes pass]

Yup, after moving /home/rekado/.cache out of the way, everything is fine
and I can log in.

What should we do about this?  For gdm I think it would make sense to
add an activation service extension that clears the gdm user’s home
directory.  And more generally, maybe we should offer a generic cache
cleaner service.

Thoughts?

--
Ricardo

Re: ‘staging’ and GNOME updates

[Timothy Sample]

Hi Ricardo,

Ricardo Wurmus <rekado@elephly.net> writes:

> Turns out that the problem was with a stale /var/lib/gdm – which makes
> me wonder: we do we have this at all?  “/var/lib/gdm” is the “gdm” user
> account’s home directory.  But it’s not like this really needs to be
> persistent, I think.
>
> I moved it out of the way and the gdm login prompt appeared within a few
> seconds.  After restarting xorg-server the directory was recreated.
>
> Now, I *still* cannot actually log in, but the problem is likely very
> similar.
>
> [two minutes pass]
>
> Yup, after moving /home/rekado/.cache out of the way, everything is fine
> and I can log in.
>
> What should we do about this?  For gdm I think it would make sense to
> add an activation service extension that clears the gdm user’s home
> directory.  And more generally, maybe we should offer a generic cache
> cleaner service.
>
> Thoughts?

I had a similar issue where the UID of the “gdm” user had changed
between reconfigures.  I think it happened because I removed the GDM
service for a while and then brought it back.  It took me a while to
figure it out, because of course everything looks fine at first glance.
However, GDM could no longer access “/var/lib/gdm”, and I had to remove
it to fix the problem.

The X.org logs all end up in that directory, so it might a little
frustrating for someone having X.org issues if we delete that directory
all the time.  I don’t remember if they get copied anywhere else.
Taking a closer look, I see that stuff like whether the on-screen
keyboard should be displayed gets saved there, too.

Maybe it would make more sense to delete the “/var/lib/gdm/.cache”
folder and ensure the permissions of the rest of it in an activation
script.  WDYT?


-- Tim

Re: ‘staging’ and GNOME updates

[Ricardo Wurmus]

Hey Tim,

>> Turns out that the problem was with a stale /var/lib/gdm – which makes
>> me wonder: we do we have this at all?  “/var/lib/gdm” is the “gdm” user
>> account’s home directory.  But it’s not like this really needs to be
>> persistent, I think.
>>
>> I moved it out of the way and the gdm login prompt appeared within a few
>> seconds.  After restarting xorg-server the directory was recreated.
>>
>> Now, I *still* cannot actually log in, but the problem is likely very
>> similar.
>>
>> [two minutes pass]
>>
>> Yup, after moving /home/rekado/.cache out of the way, everything is fine
>> and I can log in.
>>
>> What should we do about this?  For gdm I think it would make sense to
>> add an activation service extension that clears the gdm user’s home
>> directory.  And more generally, maybe we should offer a generic cache
>> cleaner service.
>>
>> Thoughts?
>
> I had a similar issue where the UID of the “gdm” user had changed
> between reconfigures.  I think it happened because I removed the GDM
> service for a while and then brought it back.  It took me a while to
> figure it out, because of course everything looks fine at first glance.
> However, GDM could no longer access “/var/lib/gdm”, and I had to remove
> it to fix the problem.
>
> The X.org logs all end up in that directory, so it might a little
> frustrating for someone having X.org issues if we delete that directory
> all the time.  I don’t remember if they get copied anywhere else.

Can we cause the logs to be put in /var/log with all the other logs?

> Maybe it would make more sense to delete the “/var/lib/gdm/.cache”
> folder and ensure the permissions of the rest of it in an activation
> script.  WDYT?

That would work, too, though the .local directory (this time in my own
user’s home directory) has proven to be harmful in my past work on GNOME
upgrades.

--
Ricardo

Re: ‘staging’ and GNOME updates

[Ludovic Courtès]

Heya!

Ricardo Wurmus <rekado@elephly.net> skribis:

>> The X.org logs all end up in that directory, so it might a little
>> frustrating for someone having X.org issues if we delete that directory
>> all the time.  I don’t remember if they get copied anywhere else.
>
> Can we cause the logs to be put in /var/log with all the other logs?

I’m not sure because GDM X logs are fundamentally per-user: GDM spawns X
as a normal user, not as root (which is pretty cool!).

Ludo’.

Re: ‘staging’ and GNOME updates

[Ludovic Courtès]

Hello,

Ricardo Wurmus <rekado@elephly.net> skribis:

> Turns out that the problem was with a stale /var/lib/gdm – which makes
> me wonder: we do we have this at all?  “/var/lib/gdm” is the “gdm” user
> account’s home directory.  But it’s not like this really needs to be
> persistent, I think.

Yes, I wonder if it’s supposed to be persistent in the first place.  I
guess ~gdm/.cache can help speed things up maybe, and perhaps there are
persistent settings too, like the a18n stuff?

> I moved it out of the way and the gdm login prompt appeared within a few
> seconds.  After restarting xorg-server the directory was recreated.

So I moved ~gdm/.cache and ~/.cache out of the way and restarted
‘xorg-server’.  After that, I was still unable to log in

You removed all of ~gdm, right?

~/.cache/gdm/session.log shows this (the important bit is “killed by
signal 11” :-)):

--8<---------------cut here---------------start------------->8---
dbus-daemon[2867]: [session uid=30011 pid=2867] Activating service name='org.gtk.vfs.Daemon' requested by ':1.1' (uid=3
0011 pid=2878 comm="gsettings get org.gnome.system.locale region ")
dbus-daemon[2867]: [session uid=30011 pid=2867] Successfully activated service 'org.gtk.vfs.Daemon'

(process:2887): GLib-GObject-CRITICAL **: 13:46:37.032: g_object_new_with_properties: assertion 'G_TYPE_IS_OBJECT (obje
ct_type)' failed

(process:2887): GLib-GIO-CRITICAL **: 13:46:37.036: g_volume_monitor_get_mounts: assertion 'G_IS_VOLUME_MONITOR (volume
_monitor)' failed

(process:2887): GLib-GObject-WARNING **: 13:46:37.036: invalid (NULL) pointer instance

(process:2887): GLib-GObject-CRITICAL **: 13:46:37.036: g_signal_connect_data: assertion 'G_TYPE_CHECK_INSTANCE (instan
ce)' failed

(process:2887): GLib-GObject-WARNING **: 13:46:37.036: invalid (NULL) pointer instance

(process:2887): GLib-GObject-CRITICAL **: 13:46:37.036: g_signal_connect_data: assertion 'G_TYPE_CHECK_INSTANCE (instan
ce)' failed

[...]

dbus-daemon[2867]: [session uid=30011 pid=2867] Successfully activated service 'org.gtk.vfs.AfcVolumeMonitor'
GNOME Shell-Message: 13:46:38.700: No permission to trigger offline updates: Polkit.Error: GDBus.Error:org.freedesktop.PolicyKit1.Error.Failed: Action org.freedesktop.packagekit.trigger-offline-update is not registered

(.gnome-shell-real:2928): mutter-WARNING **: 13:46:38.911: Failed to load background 'file:///gnu/store/ga4arkrdndyv52cs062n2l9hgnqfjyaq-gsettings-desktop-schemas-3.28.0/share/backgrounds/gnome/adwaita-lock.jpg': Erreur lors de l’ouverture du fichier /gnu/store/ga4arkrdndyv52cs062n2l9hgnqfjyaq-gsettings-desktop-schemas-3.28.0/share/backgrounds/gnome/adwaita-lock.jpg : Aucun fichier ou dossier de ce type
GNOME Shell-Message: 13:46:38.917: Error loading calendars: Erreur lors de l’appel de StartServiceByName pour org.gnome.Shell.CalendarServer : GDBus.Error:org.freedesktop.DBus.Error.Spawn.ChildExited: Process org.gnome.Shell.CalendarServer exited with status 1

(gsd-rfkill:3033): rfkill-plugin-WARNING **: 13:46:38.951: Error setting up rfkill: Could not open RFKILL control device, please verify your installation

(gsd-rfkill:3033): rfkill-plugin-WARNING **: 13:46:38.974: Could not open RFKILL control device, please verify your installation

(gsd-sharing:3036): sharing-plugin-WARNING **: 13:46:39.063: Failed to StopUnit service: GDBus.Error:org.freedesktop.DBus.Error.ServiceUnknown: The name org.freedesktop.systemd1 was not provided by any .service files

(gsd-sharing:3036): sharing-plugin-WARNING **: 13:46:39.063: Failed to StopUnit service: GDBus.Error:org.freedesktop.DBus.Error.ServiceUnknown: The name org.freedesktop.systemd1 was not provided by any .service files

(gsd-sharing:3036): sharing-plugin-WARNING **: 13:46:39.063: Failed to StopUnit service: GDBus.Error:org.freedesktop.DBus.Error.ServiceUnknown: The name org.freedesktop.systemd1 was not provided by any .service files

(gsd-sharing:3036): sharing-plugin-WARNING **: 13:46:39.070: Failed to StopUnit service: GDBus.Error:org.freedesktop.DBus.Error.ServiceUnknown: The name org.freedesktop.systemd1 was not provided by any .service files
gnome-session-binary[2872]: WARNING: Application 'org.gnome.Shell.desktop' killed by signal 11

(gsd-xsettings:3007): xsettings-plugin-WARNING **: 13:46:39.193: Failed to get current display configuration state: GDBus.Error:org.freedesktop.DBus.Error.NoReply: Message recipient disconnected from message bus without replying

(gsd-power:3026): power-plugin-WARNING **: 13:46:39.193: Could not create GnomeRRScreen: GDBus.Error:org.freedesktop.DBus.Error.ServiceUnknown: The name org.gnome.Mutter.DisplayConfig was not provided by any .service files


(gsd-media-keys:3022): GLib-CRITICAL **: 13:46:39.199: g_variant_get_va: assertion 'value != NULL' failed

(gsd-media-keys:3022): GLib-CRITICAL **: 13:46:39.199: g_variant_unref: assertion 'value != NULL' failed
--8<---------------cut here---------------end--------------->8---

> Yup, after moving /home/rekado/.cache out of the way, everything is fine
> and I can log in.

Weird.  It would be nice to find out what the relevant bits are.  If
it’s not ~gdm/.cache, then the only things I can see are:

  .config/ibus/bus/*-unix-0
  .config/dconf/user (a binary file, not modified in a while)
  .config/pulse (unlikely?)
  .local/share/icc

I’ll try again later to selectively remove these files on that machine
that runs GNOME.

Ludo’.

Re: ‘staging’ and GNOME updates

[Ludovic Courtès]

Hello,

Ludovic Courtès <ludo@gnu.org> skribis:

> Ricardo Wurmus <rekado@elephly.net> skribis:
>
>> Turns out that the problem was with a stale /var/lib/gdm – which makes
>> me wonder: we do we have this at all?  “/var/lib/gdm” is the “gdm” user
>> account’s home directory.  But it’s not like this really needs to be
>> persistent, I think.
>
> Yes, I wonder if it’s supposed to be persistent in the first place.  I
> guess ~gdm/.cache can help speed things up maybe, and perhaps there are
> persistent settings too, like the a18n stuff?
>
>> I moved it out of the way and the gdm login prompt appeared within a few
>> seconds.  After restarting xorg-server the directory was recreated.
>
> So I moved ~gdm/.cache and ~/.cache out of the way and restarted
> ‘xorg-server’.  After that, I was still unable to log in

I removed pretty both .cache directories, moved .config sub-directories
around, etc., and yet I am still unable to log in into the GNOME account
(logging in to a non-GNOME account from GDM is fine.)

I even tried upgrading the user’s profile just in case is contained
incompatible schemas or who knows what, but that didn’t help.

What extra bit of state am I missing?

Thanks,
Ludo’.

Re: ‘staging’ and GNOME updates

[Ricardo Wurmus]

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

Do you have ~/.local?  In my earlier tests this contained binary
notification data that when loaded would lead to a crash.

-- 
Ricardo

Re: ‘staging’ and GNOME updates

[Timothy Sample]

Hi Ricardo and Ludo,

Ricardo Wurmus <rekado@elephly.net> writes:

> Ludovic Courtès <ludo@gnu.org> writes:
>> I removed pretty both .cache directories, moved .config sub-directories
>> around, etc., and yet I am still unable to log in into the GNOME account
>> (logging in to a non-GNOME account from GDM is fine.)
>>
>> I even tried upgrading the user’s profile just in case is contained
>> incompatible schemas or who knows what, but that didn’t help.
>>
>> What extra bit of state am I missing?
>
> Do you have ~/.local?  In my earlier tests this contained binary
> notification data that when loaded would lead to a crash.

I’m testing GNOME on ‘staging’ now, and had the same problem (GDM worked
okay, but I could not login).  I fixed it by deleting
“~/.local/share/gnome-shell/notifications”.  I left everything else in
my home directory as it was.

The newer GNOME seems much nicer, so this is pretty cool.  The only
problems I see so far are that I lost my background picture, there’s no
icons or text for NetworkManager on the status bar, and icons aren’t
working for applications in my user profile.  I haven’t updated my
profile yet, so that might help the icons.  We’ll see.

Thanks Ricardo for doing the update!


-- Tim

Re: ‘staging’ and GNOME updates

[Ricardo Wurmus]

Timothy Sample <samplet@ngyro.com> writes:

> Ricardo Wurmus <rekado@elephly.net> writes:
[…]
>> Do you have ~/.local?  In my earlier tests this contained binary
>> notification data that when loaded would lead to a crash.
>
> I’m testing GNOME on ‘staging’ now, and had the same problem (GDM worked
> okay, but I could not login).  I fixed it by deleting
> “~/.local/share/gnome-shell/notifications”.

Yes, that’s the file that caused me trouble in the past.  I cannot be
100% certain, though, that other files also needed removing.  (At least
for the GDM user it worked fine to delete the whole directory.)

> The newer GNOME seems much nicer, so this is pretty cool.  The only
> problems I see so far are that I lost my background picture,

This appears to expected when using “guix gc”.  I get this also without
a major upgrade to GNOME.  The background picture then reverts to white.

> there’s no
> icons or text for NetworkManager on the status bar

Oh, hadn’t seen this one before.

> and icons aren’t
> working for applications in my user profile.

Are these icons refered to by absolute file name?  Might they have been
garbage collected?

> Thanks Ricardo for doing the update!

Thanks for testing it!  We still have the other GNOME upgrade that’s
waiting for a rebase, which would also require some testing.

--
Ricardo

Re: ‘staging’ and GNOME updates

[Ludovic Courtès]

Howdy,

Timothy Sample <samplet@ngyro.com> skribis:

> Ricardo Wurmus <rekado@elephly.net> writes:
>
>> Ludovic Courtès <ludo@gnu.org> writes:
>>> I removed pretty both .cache directories, moved .config sub-directories
>>> around, etc., and yet I am still unable to log in into the GNOME account
>>> (logging in to a non-GNOME account from GDM is fine.)
>>>
>>> I even tried upgrading the user’s profile just in case is contained
>>> incompatible schemas or who knows what, but that didn’t help.
>>>
>>> What extra bit of state am I missing?
>>
>> Do you have ~/.local?  In my earlier tests this contained binary
>> notification data that when loaded would lead to a crash.
>
> I’m testing GNOME on ‘staging’ now, and had the same problem (GDM worked
> okay, but I could not login).  I fixed it by deleting
> “~/.local/share/gnome-shell/notifications”.  I left everything else in
> my home directory as it was.

That’s the one!  I moved ~/.local/share/gnome-shell out of the way and
after that I could log in.  \o/

~/.local/share/gnome-shell contained a single file, “application_state”.
It’s an XML file that looks exactly like the one created by the newer
GNOME: same schema, same attributes, etc.

The weird thing: if after successfully logging in, I log out, move the
old ~/.local/share/gnome-shell into place, and log in again, it works.

Perhaps the mere presence of ~/.local/share/gnome-shell causes it to
take a different path?

Thoughts?

Thank you!

Ludo’.

Re: ‘staging’ and GNOME updates

[Ludovic Courtès]

Hello,

Ludovic Courtès <ludo@gnu.org> skribis:

> Timothy Sample <samplet@ngyro.com> skribis:
>
>> Ricardo Wurmus <rekado@elephly.net> writes:
>>
>>> Ludovic Courtès <ludo@gnu.org> writes:
>>>> I removed pretty both .cache directories, moved .config sub-directories
>>>> around, etc., and yet I am still unable to log in into the GNOME account
>>>> (logging in to a non-GNOME account from GDM is fine.)
>>>>
>>>> I even tried upgrading the user’s profile just in case is contained
>>>> incompatible schemas or who knows what, but that didn’t help.
>>>>
>>>> What extra bit of state am I missing?
>>>
>>> Do you have ~/.local?  In my earlier tests this contained binary
>>> notification data that when loaded would lead to a crash.
>>
>> I’m testing GNOME on ‘staging’ now, and had the same problem (GDM worked
>> okay, but I could not login).  I fixed it by deleting
>> “~/.local/share/gnome-shell/notifications”.  I left everything else in
>> my home directory as it was.
>
> That’s the one!  I moved ~/.local/share/gnome-shell out of the way and
> after that I could log in.  \o/

So I’d really like to merge that branch, but this GNOME upgrade issue is
holding us back.

Does anyone have ideas on how to address it?

Thanks,
Ludo’.

Re: ‘staging’ and GNOME updates

[Ricardo Wurmus]

Ludovic Courtès <ludo@gnu.org> writes:

> Hello,
>
> Ludovic Courtès <ludo@gnu.org> skribis:
>
>> Timothy Sample <samplet@ngyro.com> skribis:
>>
>>> Ricardo Wurmus <rekado@elephly.net> writes:
>>>
>>>> Ludovic Courtès <ludo@gnu.org> writes:
>>>>> I removed pretty both .cache directories, moved .config sub-directories
>>>>> around, etc., and yet I am still unable to log in into the GNOME account
>>>>> (logging in to a non-GNOME account from GDM is fine.)
>>>>>
>>>>> I even tried upgrading the user’s profile just in case is contained
>>>>> incompatible schemas or who knows what, but that didn’t help.
>>>>>
>>>>> What extra bit of state am I missing?
>>>>
>>>> Do you have ~/.local?  In my earlier tests this contained binary
>>>> notification data that when loaded would lead to a crash.
>>>
>>> I’m testing GNOME on ‘staging’ now, and had the same problem (GDM worked
>>> okay, but I could not login).  I fixed it by deleting
>>> “~/.local/share/gnome-shell/notifications”.  I left everything else in
>>> my home directory as it was.
>>
>> That’s the one!  I moved ~/.local/share/gnome-shell out of the way and
>> after that I could log in.  \o/
>
> So I’d really like to merge that branch, but this GNOME upgrade issue is
> holding us back.
>
> Does anyone have ideas on how to address it?

With this system definition I cannot log into GNOME:

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

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

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

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

-- 
Ricardo

Re: ‘staging’ and GNOME updates

[Ricardo Wurmus]

Ricardo Wurmus <rekado@elephly.net> writes:

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

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

--
Ricardo

Re: ‘staging’ and GNOME updates

[Ludovic Courtès]

Hello!

Ricardo Wurmus <rekado@elephly.net> skribis:

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

Nice reproducer!

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

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

Ludo’.

Re: ‘staging’ and GNOME updates

[Ricardo Wurmus]

Ludovic Courtès <ludo@gnu.org> writes:

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

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

I’m trying to find another reproducer.

--
Ricardo

Re: ‘staging’ and GNOME updates

[Timothy Sample]

[-- Attachment #1: Type: text/plain, Size: 282 bytes --]

Hi Ricardo,

Ricardo Wurmus <rekado@elephly.net> writes:

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

I think I’ve found one.


[-- Attachment #2: rdesktop.scm --]
[-- Type: text/plain, Size: 2859 bytes --]

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

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

[-- Attachment #3: Type: text/plain, Size: 98 bytes --]


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


[-- Attachment #4: notifications --]
[-- Type: application/octet-stream, Size: 276 bytes --]

[-- Attachment #5: Type: text/plain, Size: 523 bytes --]


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
<https://bbs.archlinux.org/viewtopic.php?pid=1778640>.  I’m not sure if
there’s anything useful for us in there, though.

I did get a backtrace of the crash.


[-- Attachment #6: gnome-shell-bt.log --]
[-- Type: text/plain, Size: 1887 bytes --]

#0  0x00007f5b368666b6 in __strlen_sse2 () from /gnu/store/h90vnqw0nwd0hhm1l5dgxsdrigddfmq4-glibc-2.28/lib/libc.so.6
#1  0x00007f5b37718318 in do_lookup.isra () from /gnu/store/cgy82g6yv8l1chawgch47zh23b0jll3l-glib-2.56.3/lib/libgio-2.0.so.0
#2  0x00007f5b3771890b in g_resource_get_info () from /gnu/store/cgy82g6yv8l1chawgch47zh23b0jll3l-glib-2.56.3/lib/libgio-2.0.so.0
#3  0x00007f5b37718e8d in g_resources_get_info () from /gnu/store/cgy82g6yv8l1chawgch47zh23b0jll3l-glib-2.56.3/lib/libgio-2.0.so.0
#4  0x00007f5b36533e15 in _gdk_pixbuf_new_from_resource_try_pixdata ()
   from /gnu/store/fnna82d4mjfw8qmnr5l0g3rlr07jw134-gdk-pixbuf-2.38.1/lib/libgdk_pixbuf-2.0.so.0
#5  0x00007f5b36533f64 in gdk_pixbuf_new_from_resource () from /gnu/store/fnna82d4mjfw8qmnr5l0g3rlr07jw134-gdk-pixbuf-2.38.1/lib/libgdk_pixbuf-2.0.so.0
#6  0x00007f5b37012a99 in icon_info_ensure_scale_and_pixbuf () from /gnu/store/4ls7vk12bckr2d74492abg81am6nz3br-gtk+-3.24.7/lib/libgtk-3.so.0
#7  0x00007f5b37012d4c in load_icon_thread () from /gnu/store/4ls7vk12bckr2d74492abg81am6nz3br-gtk+-3.24.7/lib/libgtk-3.so.0
#8  0x00007f5b3772d4cd in g_task_thread_pool_thread () from /gnu/store/cgy82g6yv8l1chawgch47zh23b0jll3l-glib-2.56.3/lib/libgio-2.0.so.0
#9  0x00007f5b375a20ee in g_thread_pool_thread_proxy () from /gnu/store/cgy82g6yv8l1chawgch47zh23b0jll3l-glib-2.56.3/lib/libglib-2.0.so.0
#10 0x00007f5b375a1765 in g_thread_proxy () from /gnu/store/cgy82g6yv8l1chawgch47zh23b0jll3l-glib-2.56.3/lib/libglib-2.0.so.0
#11 0x00007f5b36994019 in start_thread () from /gnu/store/h90vnqw0nwd0hhm1l5dgxsdrigddfmq4-glibc-2.28/lib/libpthread.so.0
#12 0x00007f5b368c492f in clone () from /gnu/store/h90vnqw0nwd0hhm1l5dgxsdrigddfmq4-glibc-2.28/lib/libc.so.6
Detaching from program: /gnu/store/lv4bxsnjnc9d5bgpsz358bn8l63z6972-gnome-shell-3.28.2/bin/..gnome-shell-real-real, process 3673
[Inferior 1 (process 3673) detached]

[-- Attachment #7: Type: text/plain, Size: 644 bytes --]


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.


-- Tim

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
> <https://bbs.archlinux.org/viewtopic.php?pid=1778640>.  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

Re: ‘staging’ and GNOME updates

[Timothy Sample]

Ricardo Wurmus <rekado@elephly.net> 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
>> <https://bbs.archlinux.org/viewtopic.php?pid=1778640>.  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 <https://issues.guix.info/issue/33693>.

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

Re: ‘staging’ and GNOME updates

[Ricardo Wurmus]

Timothy Sample <samplet@ngyro.com> writes:

> Ricardo Wurmus <rekado@elephly.net> 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
>>> <https://bbs.archlinux.org/viewtopic.php?pid=1778640>.  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 <https://issues.guix.info/issue/33693>.
>
>>> 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.

I built the VM with this diff:

--8<---------------cut here---------------start------------->8---
diff --git a/gnu/packages/gnome.scm b/gnu/packages/gnome.scm
index 5583af576b..98e2a75777 100644
--- a/gnu/packages/gnome.scm
+++ b/gnu/packages/gnome.scm
@@ -2189,7 +2189,7 @@ engineering.")
     (inputs
      `(("gtk+" ,gtk+)
        ("gtk+-2" ,gtk+-2)
-       ("librsvg" ,librsvg)
+       ("librsvg" ,librsvg-next)
        ("libxml2" ,libxml2)
        ("glib" ,glib)))
     (native-inputs
@@ -3278,7 +3278,7 @@ services for numerous locations.")
        ("cups" ,cups)
        ("gsettings-desktop-schemas" ,gsettings-desktop-schemas)
        ("libwacom" ,libwacom)
-       ("librsvg" ,librsvg)
+       ("librsvg" ,librsvg-next)
        ("xf86-input-wacom" ,xf86-input-wacom)
        ("wayland" ,wayland)
        ("network-manager" ,network-manager)))
@@ -3864,7 +3864,7 @@ for application developers.")
        ("libxml2" ,libxml2)
        ("libsoup" ,libsoup)
        ("libpeas" ,libpeas)
-       ("librsvg" ,librsvg)
+       ("librsvg" ,librsvg-next)
        ("lirc" ,lirc)
        ("gnome-desktop" ,gnome-desktop)
        ("gstreamer" ,gstreamer)
@@ -4072,7 +4072,7 @@ supports playlists, song ratings, and any codecs installed through gstreamer.")
       ("libexif" ,libexif)
       ("libpeas" ,libpeas)
       ("libjpeg" ,libjpeg)
-      ("librsvg" ,librsvg)
+      ("librsvg" ,librsvg-next)
       ("gsettings-desktop-schemas" ,gsettings-desktop-schemas)
       ("gtk+" ,gtk+)))
    (home-page "https://wiki.gnome.org/Apps/EyeOfGnome")
@@ -5991,7 +5991,7 @@ properties, screen resolution, and other GNOME parameters.")
        ("upower" ,upower)
        ;; XXX: These requirements were added in 3.24, but no mention in NEWS.
        ;; Missing propagation? See also: <https://bugs.gnu.org/27264>
-       ("librsvg" ,librsvg)
+       ("librsvg" ,librsvg-next)
        ("geoclue" ,geoclue)))
     (synopsis "Desktop shell for GNOME")
     (home-page "https://wiki.gnome.org/Projects/GnomeShell")
@@ -6397,7 +6397,7 @@ associations for GNOME.")
        ("dconf"                     ,dconf)
        ("desktop-file-utils"        ,desktop-file-utils)
        ("eog"                       ,eog)
-       ("epiphany"                  ,epiphany)
+       ;("epiphany"                  ,epiphany)
        ("evince"                    ,evince)
        ("file-roller"               ,file-roller)
        ("gedit"                     ,gedit)
@@ -7267,7 +7267,7 @@ Bluefish supports many programming and markup languages.")
      `(("gdk-pixbuf" ,gdk-pixbuf) ; for loading SVG files.
        ("gtk+" ,gtk+)
        ("gtkmm" ,gtkmm)
-       ("librsvg" ,librsvg)
+       ("librsvg" ,librsvg-next)
        ("libxml2" ,libxml2)
        ("libwnck" ,libwnck)))
     (home-page "https://wiki.gnome.org/Apps/SystemMonitor")
diff --git a/gnu/packages/gtk.scm b/gnu/packages/gtk.scm
index 6e63ca6614..b87b3649c3 100644
--- a/gnu/packages/gtk.scm
+++ b/gnu/packages/gtk.scm
@@ -528,7 +528,7 @@ in the GNOME project.")
   (package (inherit gdk-pixbuf)
     (name "gdk-pixbuf+svg")
     (inputs
-     `(("librsvg" ,librsvg)
+     `(("librsvg" ,librsvg-next)
        ,@(package-inputs gdk-pixbuf)))
     (arguments
      '(#:configure-flags '("-Dinstalled-tests=false")
--8<---------------cut here---------------end--------------->8---

GDM shows up but the GNOME shell cannot be started after log in.

It also did not fix the icon problem.

But!  Wrapping gnome-shell in LD_LIBRARY_PATH for gdk-pixbuf does fix
both problems!  With this diff I could log in fine and see the closing
icon in the window overview after starting an application.

--8<---------------cut here---------------start------------->8---
diff --git a/gnu/packages/gnome.scm b/gnu/packages/gnome.scm
index 5583af576b..0be09a8b4f 100644
--- a/gnu/packages/gnome.scm
+++ b/gnu/packages/gnome.scm
@@ -2189,7 +2189,7 @@ engineering.")
     (inputs
      `(("gtk+" ,gtk+)
        ("gtk+-2" ,gtk+-2)
-       ("librsvg" ,librsvg)
+       ("librsvg" ,librsvg-next)
        ("libxml2" ,libxml2)
        ("glib" ,glib)))
     (native-inputs
@@ -3278,7 +3278,7 @@ services for numerous locations.")
        ("cups" ,cups)
        ("gsettings-desktop-schemas" ,gsettings-desktop-schemas)
        ("libwacom" ,libwacom)
-       ("librsvg" ,librsvg)
+       ("librsvg" ,librsvg-next)
        ("xf86-input-wacom" ,xf86-input-wacom)
        ("wayland" ,wayland)
        ("network-manager" ,network-manager)))
@@ -3864,7 +3864,7 @@ for application developers.")
        ("libxml2" ,libxml2)
        ("libsoup" ,libsoup)
        ("libpeas" ,libpeas)
-       ("librsvg" ,librsvg)
+       ("librsvg" ,librsvg-next)
        ("lirc" ,lirc)
        ("gnome-desktop" ,gnome-desktop)
        ("gstreamer" ,gstreamer)
@@ -4072,7 +4072,7 @@ supports playlists, song ratings, and any codecs installed through gstreamer.")
       ("libexif" ,libexif)
       ("libpeas" ,libpeas)
       ("libjpeg" ,libjpeg)
-      ("librsvg" ,librsvg)
+      ("librsvg" ,librsvg-next)
       ("gsettings-desktop-schemas" ,gsettings-desktop-schemas)
       ("gtk+" ,gtk+)))
    (home-page "https://wiki.gnome.org/Apps/EyeOfGnome")
@@ -5932,7 +5932,8 @@ properties, screen resolution, and other GNOME parameters.")
                  `("LD_LIBRARY_PATH" ":" prefix
                    ,(map (lambda (pkg)
                            (string-append (assoc-ref inputs pkg) "/lib"))
-                         '("gnome-bluetooth" "librsvg" "libgweather"))))
+                         '("gdk-pixbuf"
+                           "gnome-bluetooth" "librsvg" "libgweather"))))
                (for-each
                 (lambda (prog)
                   (wrap-program (string-append out "/bin/" prog)
@@ -5969,6 +5970,7 @@ properties, screen resolution, and other GNOME parameters.")
        ("evolution-data-server" ,evolution-data-server)
        ("gcr" ,gcr)
        ("gdm" ,gdm)
+       ("gdk-pixbuf" ,gdk-pixbuf+svg)
        ("gjs" ,gjs)
        ("gnome-bluetooth" ,gnome-bluetooth)
        ("gnome-desktop" ,gnome-desktop)
@@ -5991,7 +5993,7 @@ properties, screen resolution, and other GNOME parameters.")
        ("upower" ,upower)
        ;; XXX: These requirements were added in 3.24, but no mention in NEWS.
        ;; Missing propagation? See also: <https://bugs.gnu.org/27264>
-       ("librsvg" ,librsvg)
+       ("librsvg" ,librsvg-next)
        ("geoclue" ,geoclue)))
     (synopsis "Desktop shell for GNOME")
     (home-page "https://wiki.gnome.org/Projects/GnomeShell")
@@ -6397,7 +6399,7 @@ associations for GNOME.")
        ("dconf"                     ,dconf)
        ("desktop-file-utils"        ,desktop-file-utils)
        ("eog"                       ,eog)
-       ("epiphany"                  ,epiphany)
+       ;("epiphany"                  ,epiphany)
        ("evince"                    ,evince)
        ("file-roller"               ,file-roller)
        ("gedit"                     ,gedit)
@@ -7267,7 +7269,7 @@ Bluefish supports many programming and markup languages.")
      `(("gdk-pixbuf" ,gdk-pixbuf) ; for loading SVG files.
        ("gtk+" ,gtk+)
        ("gtkmm" ,gtkmm)
-       ("librsvg" ,librsvg)
+       ("librsvg" ,librsvg-next)
        ("libxml2" ,libxml2)
        ("libwnck" ,libwnck)))
     (home-page "https://wiki.gnome.org/Apps/SystemMonitor")
diff --git a/gnu/packages/gtk.scm b/gnu/packages/gtk.scm
index 6e63ca6614..b87b3649c3 100644
--- a/gnu/packages/gtk.scm
+++ b/gnu/packages/gtk.scm
@@ -528,7 +528,7 @@ in the GNOME project.")
   (package (inherit gdk-pixbuf)
     (name "gdk-pixbuf+svg")
     (inputs
-     `(("librsvg" ,librsvg)
+     `(("librsvg" ,librsvg-next)
        ,@(package-inputs gdk-pixbuf)))
     (arguments
      '(#:configure-flags '("-Dinstalled-tests=false")
--8<---------------cut here---------------end--------------->8---

We could skip the librsvg-next changes and only push the LD_LIBRARY_PATH
fix.  If that alone fixes the problems we can do the librsvg stuff on
core-updates later.

Sound good?<

--
Ricardo

Re: ‘staging’ and GNOME updates

[Giovanni Biscuolo]

[-- Attachment #1: Type: text/plain, Size: 393 bytes --]

Hello Timothy and Ricardo,

Timothy Sample <samplet@ngyro.com> writes:

[...]

> Or, maybe I could pull Epiphany out of our GNOME package, and avoid
> WebKitGTK (now that GNOME Shell doesn’t need it).

this will not fix any problem but please do it anyway before merging to
master :-)

thanks for working on this!

[...]

-- 
Giovanni Biscuolo

Xelera IT Infrastructures

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]

Re: Status update on 1.0

[Jonathan Brielmaier]

[-- Attachment #1: Type: text/plain, Size: 1919 bytes --]

Am 29.03.19 um 19:56 schrieb Ricardo Wurmus:> One of the GNOME update
branches (for 2.28?) has already been merged
> into staging.  There are rumours of crashes, though, so this will
> require testing by more people.

I checked out staging and built a slightly adjusted desktop.tmpl image
with "guix system vm-image", because the default desktop.tmpl fails to
build.

My observations:
- the settings icon in the application menu is not as sharp as all the
 other icons
- settings->search list the applications twice (files, calculator, web)
- is settings supposed to work in general? Because if you change a
parameter like the time zone, it get immediately reset to the default
- when running "guix package -i" there is a backtrace
--------------------------------------------------------------------
bash-4.4$ guix package -i vim
guix package: warning: Consider running 'guix pull' followed by
'guix package -u' to get up-to-date packages and security updates.

substitute: Backtrace:
substitute:            6 (apply-smob/1 #<catch-closure 1672640>)
substitute: In ice-9/boot-9.scm:
substitute:     705:2  5 (call-with-prompt _ _ #<procedure
default-prompt-handle…>)
substitute: In ice-9/eval.scm:
substitute:     619:8  4 (_ #(#(#<directory (guile-user) 16f5140>)))
substitute: In guix/ui.scm:
substitute:   1660:12  3 (run-guix-command _ . _)
substitute: In guix/scripts/substitute.scm:
substitute:    1100:2  2 (guix-substitute "--query")
substitute:   1026:13  1 (check-acl-initialized)
substitute: In unknown file:
substitute:            0 (scm-error misc-error #f "~A ~S" ("invalid
access-c…" …) …)
substitute:
substitute: ERROR: In procedure scm-error:
substitute: invalid access-control list ()
---------------------------------------------------------------------
- at somepoint Gnome crashes, a screenshot of the error message is
attached (gnome_freeze.png)

[-- Attachment #2: gnome_freeze.png --]
[-- Type: image/png, Size: 24456 bytes --]

Re: Status update on 1.0

[Ricardo Wurmus]

Hi Jonathan,

thank you for testing this!

> - at somepoint Gnome crashes, a screenshot of the error message is
> attached (gnome_freeze.png)

I see OOM killer is mentioned.  How much RAM did you allocate to the VM?

--
Ricardo

Re: Status update on 1.0

[Jonathan Brielmaier]

On 4/10/19 6:56 PM, Ricardo Wurmus wrote:
>
> Hi Jonathan,
>
> thank you for testing this!
>
>> - at somepoint Gnome crashes, a screenshot of the error message is
>> attached (gnome_freeze.png)
>
> I see OOM killer is mentioned.  How much RAM did you allocate to the VM?

4GiB

Re: Status update on 1.0

[Ricardo Wurmus]

Jonathan Brielmaier <jonathan.brielmaier@web.de> writes:

> On 4/10/19 6:56 PM, Ricardo Wurmus wrote:
>>
>> Hi Jonathan,
>>
>> thank you for testing this!
>>
>>> - at somepoint Gnome crashes, a screenshot of the error message is
>>> attached (gnome_freeze.png)
>>
>> I see OOM killer is mentioned.  How much RAM did you allocate to the VM?
>
> 4GiB

Oof.  That certainly should be enough.  It would be good to see what
process caused the OOM killer to kill the session.

--
Ricardo

Re: Status update on 1.0

[Pierre Neidhardt]

[-- Attachment #1: Type: text/plain, Size: 662 bytes --]

Hi!

About 1.0 release date set to April the 30th, I can think of one big
obstacle still in the way: texlive.  Currently I cannot compile a
standard LaTeX document with a table (can anyone reproduce?).

The big TeXlive revamp is on its way on the "wip-texlive" branch, but I
won't realistically have time to work on it before the end of the month.
I don't know if anyone else has got the time.  Jelle?  Ricardo?

Whether it's a blocker or not for 1.0 is debatable I guess.  It looks a
bit bad.  Maybe show a disclaimer on the download page / manual that
this broken part is currently being addressed?

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]

TeX Live

[Ludovic Courtès]

Hi Pierre,

Pierre Neidhardt <mail@ambrevar.xyz> skribis:

> About 1.0 release date set to April the 30th, I can think of one big
> obstacle still in the way: texlive.  Currently I cannot compile a
> standard LaTeX document with a table (can anyone reproduce?).
>
> The big TeXlive revamp is on its way on the "wip-texlive" branch, but I
> won't realistically have time to work on it before the end of the month.
> I don't know if anyone else has got the time.  Jelle?  Ricardo?

To me this doesn’t have to be done on 1.0.  The current TeX Live
situation is not as good as what will come after, but it’s better than
what we had before :-), and I’d say it’s good enough.

For the specific usability issue you mention (what’s the right package
to install when one wants tables?), I think we should add a section in
the manual, as has been discussed before.

> Whether it's a blocker or not for 1.0 is debatable I guess.  It looks a
> bit bad.  Maybe show a disclaimer on the download page / manual that
> this broken part is currently being addressed?

Definitely not a blocker IMO, though I agree that this is important
work.

Thanks,
Ludo’.

Re: TeX Live

[Pierre Neidhardt]

[-- Attachment #1: Type: text/plain, Size: 426 bytes --]

Ludovic Courtès <ludo@gnu.org> writes:

> For the specific usability issue you mention (what’s the right package
> to install when one wants tables?), I think we should add a section in
> the manual, as has been discussed before.

No package, this is default LaTeX.  Because of that, most documentation
depending on LaTeX breaks.  E.g. asymptote won't build anymore.

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]

Re: TeX Live

[Ricardo Wurmus]

Pierre Neidhardt <mail@ambrevar.xyz> writes:

> Ludovic Courtès <ludo@gnu.org> writes:
>
>> For the specific usability issue you mention (what’s the right package
>> to install when one wants tables?), I think we should add a section in
>> the manual, as has been discussed before.
>
> No package, this is default LaTeX.

I think this is one and the same thing.  When I wrote the first modular
package definitions I just looked at the LaTeX base packages, tried to
build them, failed, added package definitions to address the failure,
and repeated until things wouldn’t fail any more.

This means that the set of packages that gives us a “default LaTeX”
experience are incomplete.

I suggest taking a closer look at the ingredients of texlive-latex-base.
Many of the packages that contribute to it may actually be woefully
incomplete.  For each of the packages we should compare the expected
output (according to the texlive database) with the actual output.  Some
cases may be a little tricky, but overall I think the problem is not too
difficult to solve with systematic work.

With some luck I may be able to take a look at this next week, but I’d
be happy if someone with a clear head took the lead instead.

--
Ricardo