Questions about managing user accounts

[sirgazil]

I know that you can create new user accounts by specifying them in the 
operating system configuration as indicated in the manual 
(https://guix.gnu.org/manual/en/html_node/User-Accounts.html#User-Accounts). 
But I can't find answers to the following questions in the manual:

1. How do I delete users completely?
2. How can I create users that use different languages?

Regarding (1), when I remove users from the system configuration, their home 
directories are left behind, and this seems to create conflicts when I create a 
new user with the same credentials and home directory as a previous user. With 
conflicts I mean that I can't login with those kinds of users (even if I reset 
passwords with passwd).

Regarding (2), I mean users whose desktop interface should be displayed in a 
different language than the that of the locale specified in the operating 
system configuration file.


---
https://sirgazil.bitbucket.io/

Re: core-updates call for testing

[Jack Hill]

On Sat, 25 Apr 2020, sirgazil wrote:


 On Sat, 25 Apr 2020 21:19:26 + Jack Hill  wrote 

> Does GNOME-Web work for you? I'm wondering if others can reproduce the
> problem I'm seeing: https://issues.guix.gnu.org/40837

No it doesn't.


Hi all,

Unfortunately, I think I'm current stuck on fixing this bug. Any help of 
ideas would be appreciated.


Best,
Jack

Re: Thunar does not launch: Failed to execute child process 'gio-launch-desktop'

[Marius Bakke]

zna...@disroot.org writes:

> Hello! I use pcmanfm and everything works fine.
> But when I open Downloads folder from IceCat it is opening in Thunar that has 
> ugly behavior.
> When I click on any file it cannot run an Application with this error:
>
> Failed to open filename.csv
> Failed to execute child process 'gio-launch-desktop' (No such file or 
> directory).
>
> Screen:
> http://0x0.st/iezi.png (http://0x0.st/iezi.png)
>
> I use Xfce4 desktop.
> How can I fix it?

This problem has been fixed on the soon-to-be-merged 'core-updates'
branch.  Pulling that branch should be safe as no big rebuilds are
scheduled at this point, and you get to help out Guix development by
testing it!

To get it, use 'guix pull --branch=core-updates' or adjust your
channels.scm.

If using "core-updates" is impractical, you can work around this issue
in the meantime by adding (list glib "bin") in the 'packages' field of
your operating-system declaration.

HTH!
Marius


signature.asc
Description: PGP signature

Re: Building installation image for ROCK64

[Vagrant Cascadian]

On 2020-04-27, Simon South wrote:
> Vagrant Cascadian  writes:
>> With your current layout, parts of the bootloader may be written to the
>> same offsets as files in your first partition...
>
> Yes, my mistake. Thanks for pointing that out.
>
>> You really want to have the loader1 (start sector 64, 2.5MB size) and
>> loader2 (start sector 16384, 4MB size) partitions...
>
> I'm not sure how literally you meant this to be interpreted, but after a
> bit of experimentation it seems the most sensible arrangement for now is
> just to have a single partition starting at sector 32,768 for the root
> filesystem. This is because

That also should work fine.


> - If real partitions are created for the bootloader stages and the
>   trusted firmware, U-Boot will fail to start the OS (with "Unrecognized
>   filesystem type") when it scans for bootable partitions. (It probably
>   ought to just skip over partitions without a recognizable filesystem,
>   but it doesn't seem to behave that way.)

It's possible to mark the partition as bootable (I think "ESP Boot" or
something like that).


> - It seems Guix System does not yet support having /boot on a separate
>   partition and will fail at startup if the store isn't available on the
>   same filesystem as extlinux.conf. Consequently reserving 112 MB for a
>   separate boot partition accomplishes nothing.

Right; I wouldn't suggest using such a tiny boot partition anyways (I
think they suggest a 112MB /boot ?).


> At least this way the root filesystem is safe from being overwritten by
> the bootloader, and as Guix's support for multiple partitions improves
> over time it'll be possible to more closely follow Rockchip's
> conventions.

Yeah, anything after sector 32768 is, in my opinion, fair game to do
whatever you want with. :)


>> It would be nice to eventually be able to create installer images for
>> aarch64/armhf...
>
> Yes, absolutely. In the meantime just making available a
> minimal-but-complete image for writing to a microSD card would be a big
> help to people looking to get started quickly with Guix on the ROCK64.

I'm tempted to make armhf and aarch64 one-off images using
linux-image-arm64-generic and linux-image-arm-generic kernels, and
include instructions for updating the bootloader, to support an
arbitrary number of different systems... this should be doable.


live well,
  vagrant


signature.asc
Description: PGP signature

--> PINEBOOK PRO USERS <-- Patches to add Panfrost Graphics Acceleration XFCE4

[Brian Woodcox]

I just thought I should mention that I was able to add the necessary plumbing 
to add graphics acceleration to the Pinebook Pro.

The patch subject that I used was not the best as Pinebook Pro users might miss 
it.

Here is the link —> 
https://lists.gnu.org/archive/html/guix-patches/2020-04/msg01101.html 


Also my apologies, I sent these patches in using OSX, and apparently it makes 
the patch files into binary files, but they can still be read.

Brian C. Woodcox

Xfce4-panel launchers are breaking after updates

[znavko]

Hello! I think I've already posted this issue, but did not get answer.
I use Xfce4 and have some Applications launchers on Xfce4 Panel, that I've 
added usual way.
After updates the directories of software binaries are changing and this causes 
the errors in Xfce4 Panel's work:
it cannot find application I run from the panel item. This makes me need to 
delete old items and add them again.
I think this is Guix architecture traits make this kind of issue.
The items that I add as 'run command' with my own bash script launcher (for 
ungoogled-chromium with tor here was such thread)
them run perfectly and do not break.

How to work with it?
Should I require xfce4 developers to make 'which application' before run 
application from panel items??

Thunar does not launch: Failed to execute child process 'gio-launch-desktop'

[znavko]

Hello! I use pcmanfm and everything works fine.
But when I open Downloads folder from IceCat it is opening in Thunar that has 
ugly behavior.
When I click on any file it cannot run an Application with this error:

Failed to open filename.csv
Failed to execute child process 'gio-launch-desktop' (No such file or 
directory).

Screen:
http://0x0.st/iezi.png (http://0x0.st/iezi.png)

I use Xfce4 desktop.
How can I fix it?

Re: Building installation image for ROCK64

[Simon South]

Vagrant Cascadian  writes:
> With your current layout, parts of the bootloader may be written to the
> same offsets as files in your first partition...

Yes, my mistake. Thanks for pointing that out.

> You really want to have the loader1 (start sector 64, 2.5MB size) and
> loader2 (start sector 16384, 4MB size) partitions...

I'm not sure how literally you meant this to be interpreted, but after a
bit of experimentation it seems the most sensible arrangement for now is
just to have a single partition starting at sector 32,768 for the root
filesystem. This is because

- If real partitions are created for the bootloader stages and the
  trusted firmware, U-Boot will fail to start the OS (with "Unrecognized
  filesystem type") when it scans for bootable partitions. (It probably
  ought to just skip over partitions without a recognizable filesystem,
  but it doesn't seem to behave that way.)

- It seems Guix System does not yet support having /boot on a separate
  partition and will fail at startup if the store isn't available on the
  same filesystem as extlinux.conf. Consequently reserving 112 MB for a
  separate boot partition accomplishes nothing.

At least this way the root filesystem is safe from being overwritten by
the bootloader, and as Guix's support for multiple partitions improves
over time it'll be possible to more closely follow Rockchip's
conventions.

> It would be nice to eventually be able to create installer images for
> aarch64/armhf...

Yes, absolutely. In the meantime just making available a
minimal-but-complete image for writing to a microSD card would be a big
help to people looking to get started quickly with Guix on the ROCK64.

-- 
Simon South
si...@simonsouth.net