bug#35439: Transmission BitTorrent Client

2019-04-26 Thread ison
Did you choose the right output? Most packages only have a single output, but
transmission has 2: "out" and "gui".

For example to install the gui output you would run:
guix package -i transmission:gui

The gui output is the one that might add your GNOME Menu entries as it comes
with the GTK version of transmission. The normal "out" output is the CLI version
only.
This confused me the first time I used guix too, before I was aware of outputs.





bug#35610: Freshly installed IBus intput method is not listed as an input source

2019-05-06 Thread ison
I currently have ibus with anthy working, but I had this exact same problem at
first. I'm not 100% sure what I finally did to solve it, but I think it may have
been a missing environment variable. Here is what I have set:
export 
GTK_IM_MODULE_FILE="/run/current-system/profile/lib/gtk-3.0/3.0.0/immodules-gtk3.cache"
export GTK_IM_MODULE="xim"
export XMODIFIERS="@im=ibus"
export QT_IM_MODULE="xim"

I'm thinking the $GTK_IM_MODULE_FILE variable is the missing ingredient. 
However, while attempting to fix this I also installed the packages:
ibus, ibus-anthy, dbus, python-dbus, python2-dbus

If you need these packages too to make it work then perhaps its worth
investigating if the anthy package is missing some dependencies.





bug#35610: Freshly installed IBus intput method is not listed as an input source

2019-05-07 Thread ison
The only other thing I can think of right now which might be different is the
way I'm starting ibus. Instead of ibus-setup, what happens if you launch it with
ibus-daemon -drx
and then access the preferences by right clicking the tray icon (or perhaps
running ibus-setup _after_ the daemon is launched if you have no tray icon)

On Tue, May 07, 2019 at 04:26:29PM +0200, pelzflorian (Florian Pelz) wrote:
> What I said was incomplete.  I just tried again; ibus-anthy works fine
> for me only when e.g. entering text in GNOME Shell’s search bar, but
> not when entering text in the terminal.  Sorry.

If I recall correctly I had this issue as well, where input would not work in
the terminal even though it worked in other applications, until I changed some
of my environment variables to "xim" instead of "ibus".
According to the Arch Wiki here
https://wiki.archlinux.org/index.php/IBus
there are claims from some users that things don't work until they replace
"ibus" with "xim".





bug#36508: GDM files have incorrect owner after temporarily replacing with SDDM

2019-07-05 Thread ison
After replacing GDM with SDDM in my Guix System config (to test Wayland) and
then reverting back to my old config and reconfiguring GDM would crash
(printing out around 500 lines about creating a seat)
I also tried rolling back to the generation I had before using SDDM and it would
still crash.
In both instances I also tried "herd restart xorg-server" but same problem.

I then checked the log file /var/log/gdm/greeter.log which had errors such as:
---
Fatal server error:
(EE) Cannot open log file "/var/lib/gdm/.local/share/xorg/Xorg.pid-720.log"
---

And then I could verify that files inside of /var/lib/gdm had incorrect
ownership of 9##:gdm
where 9## was some 3-digit number I can't remember now.
(note: the directory itself /var/lib/gdm still had correct ownership gdm:gdm)

I then manually fixed the ownership with:
chown -R gdm:gdm /var/lib/gdm
and GDM successfully came up without crashing.

The relevant portion of my config when I replaced GDM with SDDM was:
---
(operating-system
  ...
  (services
(cons*
  ...
  (sddm-service
(sddm-configuration
  (display-server "wayland")))

  ;; Return %desktop-services with GDM removed
  (remove (lambda (service)
(eq? (service-kind service) gdm-service-type))
  %desktop-services
---





bug#36942: Reconfigure broke GRUB

2019-08-16 Thread ison
On Fri, Aug 16, 2019, Jakob L. Kreuze wrote:
> ison  writes:
> 
> > /boot/efi looks ok as far as I can tell at least. It's tree is:
> > /boot/efi/
> > └── EFI
> > ├── grub
> > │   └── grubx64.efi
> > ├── Guix
> > │   └── grubx64.efi
> > └── GuixSD
> > └── grubx64.efi
> > All 3 grubx64.efi files differ from each other and are around 120kb.
> 
> Interesting... I only have '/boot/efi/EFI/Guix'. Do you have a
> '/boot/grub'?

I do have a /boot/grub actually. Is that strange?
It looks like a normal /boot/grub to me, and contains a grub.cfg

> I think it may be indicative of a more serious problem, since you
> mentioned that this was fine up until the commit refactoring 'guix
> system reconfigure'. If you're willing to reinstall and see if you can
> reproduce it, that maywould be helpful -- you could send me the relevant
> 'install-bootloader.scm' store item if it breaks again.
> 
> Thank you very much, ison. I appreciate your cooperation here greatly.

Sounds good, I'll reinstall it over the weekend





bug#36942: Reconfigure broke GRUB

2019-08-15 Thread ison
On Wed, Aug 14, 2019 at 03:50:00PM -0400, Jakob L. Kreuze wrote:
> However, I still cannot seem to reproduce this issue with the most
> recent master. Everything boots fine. I've extracted the bootloader
> installation "script", and everything appears to be normal to me.

Sorry it took me so long to reply, I didn't have access to the
broken machine until now. As you requested here is the partitions as
listed by parted:

Number  Start   End SizeFile system NameFlags
 1  1049kB  3046kB  2097kB  grubbios_grub
 2  3146kB  540MB   537MB   fat32   efi boot, esp
 3  540MB   2588MB  2048MB  linux-swap(v1)  swap
 4  2588MB  750GB   748GB   ext4guixsd

/boot/efi looks ok as far as I can tell at least. It's tree is:
/boot/efi/
└── EFI
├── grub
│   └── grubx64.efi
├── Guix
│   └── grubx64.efi
└── GuixSD
└── grubx64.efi
All 3 grubx64.efi files differ from each other and are around 120kb.


But considering you can't reproduce the issue would it be a good
idea for me to reinstall and see if I can even reproduce it?
Although I think this time I would leave off the bios_grub partition
I'm willing to keep testing the current bug if it's important or
indicative of a more serious problem. But please don't feel
obligated to keep working on this just for me, I'm perfectly fine
just reinstalling. The issue doesn't seem to affect my desktop
anyway, I was able to upgrade it smoothly.

It's always possible the issue was caused by some strange
combination involving the patched bug, from earlier in the
discussion, and my weird partition layout. Might not even be worth
investigating unless it happens to someone else
(or me again after a fresh install).





bug#36942: Reconfigure broke GRUB

2019-08-20 Thread ison
On Tue, Aug 20, 2019, Jakob L. Kreuze wrote:
> This is perfect (I mean, not that it still doesn't work, but that we
> have some error output). I think I know what's going on. The new 'guix
> system reconfigure' uses G-Expressions, and it looks like Grub is being
> ungexp'd for the wrong architecture. To be sure, what's the architecture
> of this machine?
> 
> I'll investigate further and let you know what I find. Thanks again for
> doing this.
> 
> Regards,
> Jakob

That's great, thanks for investigating this.
Both the machine architecture and the liveUSB are x86_64.





bug#36942: Reconfigure broke GRUB

2019-08-20 Thread ison
On Sat, Aug 17, 2019, Jakob L. Kreuze wrote:
> ison  writes:
> 
> > Sounds good, I'll reinstall it over the weekend
> 
> Thank you :)

So I attempted a re-install and surprisingly it still fails.
I attempted 3 times. Using the graphical installer without efi,
manual install without efi, manual install with efi. All downloaded
and built everything successfully only to fail at the bootloader.
If the problem was my config then I'd think my first attempt would
have succeeded because the graphical installation automatically
built the config file.

At least it's giving an error this time:
error: '/gnu/store/drz35fc...-grub-efi-2.02/sbin/grub-install --boot-directory 
/mnt/boot --bootloader-id=Guix --efi-directory /boot/efi' exited with status 1: 
output follows:
  /gnu/store/drz35fc...-grub-efi-2.02/sbin/grub-install: error: 
/gnu/store/drz35fc...-grub-efi-2.02/lib/grub/i386-pc/modinfo.sh doesn't exist. 
Please specify --target or --directory.

My bootloader is section is still:
  (bootloader (bootloader-configuration
   (bootloader grub-efi-bootloader)
   (target "/boot/efi")))





bug#36942: Reconfigure broke GRUB

2019-08-26 Thread ison
On Mon, Aug 26, 2019 at 12:20:04PM +0200, Ludovic Courtès wrote:
> 
> Closing, because this is apparently the same as
> , which fortunately was fixed a
> while back!
> 
> Thanks,
> Ludo’.

For the record I attempted another install just now and it was
successful. I'm not sure exactly what caused the initial breakage or
what fixed it, but I'm glad it's working now.

Thanks again for the help.





bug#37244: Icecat Audio Issues

2019-09-03 Thread ison
On Sun, Sep 01, 2019, Tobias Geerinckx-Rice via Bug reports for GNU Guix wrote:
> 
> If by ‘robotic’ you mean (extremely) low-pitched then, yes, this has been
> the case for roughly the past half year.
> 
> I asked around on IRC, even sending URLs to innocent people who were unable
> to reproduce the problem, so I then assumed it wasn't in Guix proper.  I
> almost never watch videos on the Web so I didn't care much, but you might be
> happy to learn you're not alone.
> 
> Could you share a (free) example URL?

I believe the cause is "media sources", although I'm not sure
exactly what that is, if you disable it it seems to "fix" the issue.
I found this solution from some old firefox bug reports that seemed to describe
similar audio distortions.

A good site to test it on is nicovideo.jp, since on other sites if I
disable mediasources the videos just refuse to play altogether.
So for example here is a reference video, I simply clicked the first
video I saw and it reproduces the audio distortion:
https://www.nicovideo.jp/watch/sm35513757

When I play it the audio is very low pitch and crackly. However, if
I open about:config (just enter about:config into the address bar),
search for "mediasource", and then double click
"media.mediasource.enabled" so it shows false, then reload the video
and it plays perfectly without any distortion.

As I mentioned though, most sites seem to not like it when
mediasource is disabled, so it's not a perfect solution, but at
least it shows where the problem lies.





bug#36942: Reconfigure broke GRUB

2019-08-07 Thread ison
On Tue, Aug 06, 2019 at 02:18:15PM -0400, Jakob L. Kreuze wrote:
> Hi ison,
> 
> I wasn't able to reproduce with an OVMF virtual machine, but the
> symptoms you've described lead me to suspect that the issue concerns
> improper installation of a GC root for grub. Would you be willing to see
> if the patch provided by #36947 fixes your issue?

I'm sorry to report that it actually didn't fix the problem.

Also I don't know why it didn't occur to me to mention this detail
before, but the reason I previously thought the message mentioned
in bug#36878 was important is because it's actually the very last
thing I see on the command line after reconfiguring. The line I'm
talking about is of course:
shepherd: Evaluating user expression (let* ((services (map primitive-load (?))) 
# ?) ?)

I'm pretty sure even if that message is normal, it's not normal
for it to be the last line you see.
Perhaps the reconfigure is dying at that point, or some point
shortly after, without outputting any other errors.





bug#36878: guix system reconfigure broken

2019-08-05 Thread ison
On Fri, Aug 02, 2019 at 11:11:31AM -0400, Jakob L. Kreuze wrote:
> The patch made it into master as 1db6f137d; thanks to Danny for signing
> off on it. Should we close this?

I'm still experiencing this issue. "guix describe" shows that I'm using
commit 35600cd which should be newer than the fix.

I made the mistake of rebooting my machine after I first got this error, I
thought perhaps it was benign. But when it came back up I was dropped to a
GRUB rescue shell with some error about "grub_file_filters" being an unknown
symbol.

When running grub commands like "insmod normal" would just repeat the error
or say command not found.
The only way I could think to repair it was to run the Guix install disk,
mount my partitions, and do another "guix init" which allows me to boot into
my machine again. However, when I run "guix pull" and then perform a
reconfigure I still keep seeing the same line:
shepherd: Evaluating user expression (let* ((services (map primitive-load (?))) 
# ?) ?)

I've tried this on several occasions over the last few days with different
commits following the supposed fix, and it still keeps doing the same thing,
and every time I follow the reconfigure with a reboot GRUB is broken again.





bug#36942: Reconfigure broke GRUB

2019-08-05 Thread ison
Continuing this issue from https://issues.guix.gnu.org/issue/36878

guix reconfigure recently broke GRUB for me. When rebooting I get
dropped to a "grub rescue>" shell with an error about
"grub_file_filters" being an unknown symbol.
If I try doing the usual commands to tell GRUB how to boot I just
see the above error repeated, or "unknown command" when I run
things such as insmod or "configfile".

So to fix the problem I can boot to a Guix install disk and do
"guix init" which rebuilds the system using older package
definitions from the disk.
That allows me to get a working system, but if I do another
"guix pull" and reconfigure using the same config file it breaks
GRUB again when I reboot. "guix describe" shows that my latest
attempt was with commit 35600cd.

Here is the bootloader and filesystem sections of my config:
  (bootloader (bootloader-configuration
(bootloader grub-efi-bootloader)
(target "/boot/efi")))
  (file-systems (cons* (file-system
 (device "/dev/sda2")
 (mount-point "/boot/efi")
 (type "vfat"))
   (file-system
 (device (file-system-label "guixsd-root"))
 (mount-point "/")
 (type "ext4"))
   %base-file-systems))

I should make a note that I usually don't use efi, and I'm not
completely confident it's all set up properly. I do have a
"BIOS boot" partition on /dev/sda1 too, is that even needed with
efi? Although, I have been using this setup, and the above
definitions, for about 6 months now without any bootloader or
filesystem issues. And the same config is being used to fix the
system when GRUB breaks as well as to reconfigure afterward
(causing the breakage). So my guess is some new update is the
culprit.





bug#36878: guix system reconfigure broken

2019-08-05 Thread ison
On Mon, Aug 05, 2019 at 10:59:57AM -0400, Jakob L. Kreuze wrote:
> ison -- I'm very sorry that you've had this experience. Would you be
> willing to share the 'bootloader' field of your operating system
> configuration so I can look into this?

Thanks for taking an interest. Here is the new bug report:
https://issues.guix.gnu.org/issue/36942

Please let me know if there's any other information or testing I
can do to help figure it out.





bug#36991: spacefm segmentation fault

2019-08-09 Thread ison
On Fri, Aug 09, 2019, Bradley Haggerty wrote:
> Just adding some info, I'm using Sway on Wayland. I noticed another
> program, pcmanfm-qt was complaining about missing a plugin for wayland
> support, so perhaps spacefm needs to support wayland and doesn't
> currently.

I also couldn't get spacefm to launch a while ago when I tried
Wayland. However, I notice that the developer has a separate
"spacefm-wayland" repository with a link to an issue on why normal
spacefm doesn't work in Wayland.
It says it's a temporary branch so I suppose eventually spacefm will
support it, but if you want to get it working now you'd probably
have to build from here instead:
https://github.com/IgnorantGuru/spacefm-wayland





bug#37867: bug on x86_64-linux AMD box

2019-10-23 Thread ison
There is a known issue with AMD causing lockups:
https://bugzilla.kernel.org/show_bug.cgi?id=196683

It sounds like you might have that if you get multiple freezes every day.
I was also experiencing this problem after building a new AMD machine and
that link helped me.
To summarize the solution seems to be upgrading your BIOS. Some people don't
have luck with that in which case there are also several workarounds given
which reduce the problem.
Incompatible ram could also cause such freezing.
It might also help to check in dmesg for errors.





bug#37913: Aisleriot pt-br portuguese

2019-10-25 Thread ison
On Thu, Oct 24, 2019, Pablo Ferreira wrote:
> Olá equipe!
> 
> Eu instalei o Aisleriot em um Guix System usando o "guix install" mas ele
> não inicia. Quando uso o terminal ele retorna à mensagem "Non UTF-8 locale
> (ANSI_X3.4-1968) is not supported!".
> 
> Observação: Sempre que eu uso o comando "guix" ele avisa para instalar o
> glibc-utf8-locales e criar a variavel de ambiente GUIX_LOCPATH.

I get the same error with en_US.utf8 (set for all values listed by "locale")
I also have both glibc-locales and glibc-locales-2.28 installed.
However I do not see the error about installing glibc-utf8-locales, nor
the one about setting GUIX_LOCPATH when using guix commands, so that may be
unrelated.





bug#42995: Thunar not saving settings: fixed with xfconf

2020-08-23 Thread ison
I installed Thunar without xfce and it was incapable of saving any settings
changes. Once I installed xfconf then settings are saved.

Should xfconf be added as an input to Thunar?