bug#38568: Org Mode (as a dependency) is borked

[Jelle Licht]

Hey Guix, 

Org-mode seems to still have some byte compilation issues when used as a
dependency for other packages. The specific symptom is extremely similar
to the one reported and fixed at [http://issues.guix.info/issue/38479].

To reproduce:
 1) Install emacs-org-jira in your profile, and set it up (lots of
annoying steps with API tokens, authinfo etc etc)
 2) Run `M-x org-jira-get-boards':
--8<---cut here---start->8---
org-jira--render-board: Symbol’s function definition is void: 
org-outline-overlay-data
--8<---cut here---end--->8---

To see the issue without reproducing it (using bash):
--8<---cut here---start->8---
$ grep -rni 'org-outline-overlay-data' $(guix build emacs-org-jira)
--8<---cut here---end--->8---

This gives:
--8<---cut here---start->8---
Binary file org-jira.elc matches
--8<---cut here---end--->8---

Byte-compiling the org-jira.el file manually gives an .elc file without
a reference to `org-outline-overlay-data'. This leads me to believe that
the previously posted fix for #38479 could be extended to make sure
Emacs' built-in packages are at the trailing end of EMACSLOADPATH, so
after any other packages. 

Regards,
Jelle



 

bug#38521: Acknowledgement (perl-gtk2 check fails: Failed test 'Don't crash on partial pixmap data')

[Pierre Neidhardt]

CC-ing Alex since he is the original author of the package.

Cheers!

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


signature.asc
Description: PGP signature

bug#38447: Guix Stand-alone OS installation Error - T410 - x86 - intel - lenova

[Pon Arun Kumar R]

Hi Mathieu,

When you get a chance, could you please share the details or suggestions to
proceed further with my GUIX installation on the lenova T410 x86 Intel?

Appreciate your help!

Regards,
Pon ArunKumar Ramalingam

On Mon, Dec 2, 2019 at 9:18 AM Pon Arun Kumar R 
wrote:

> I downloaded the 1.0.1 image from the guix webpage and wrote a bootable
> DVD and used the graphical installer on a machine (lenova thinkpad t410
> 64bit)
>
> On Mon, Dec 2, 2019 at 9:14 AM Mathieu Othacehe 
> wrote:
>
>>
>> Ok thanks. Did you use 1.0.1 image from http://guix.gnu.org/download/?
>>
>> Mathieu
>>
>> Pon Arun Kumar R writes:
>>
>> > Hi Mathieu,
>> >
>> > I tried selecting two different locale/keymap config in two different
>> > attempts, 1. on the regular US english intl and 2. regular US eng,intl
>> with
>> > dead keys,
>> >
>> > I tried several attempts, and I doubt whether it is something to do with
>> > the BIOS settings update as a pre-requite for the installation.
>> >
>> > Thanks,
>> > Pon ArunKumar R
>> >
>> > On Mon, Dec 2, 2019 at 8:54 AM Mathieu Othacehe 
>> > wrote:
>> >
>> >>
>> >> Hello!
>> >>
>> >> > Could you please help in resolving this issue?
>> >> >
>> >> > “Unable to locate key map update file”
>> >>
>> >> Thanks for your report. Which locale/keymap did you choose before this
>> >> error occured?
>> >>
>> >> Mathieu
>> >>
>>
>>

bug#33639: Fixing the GPT errors from an installer on a USB stick

[Brice Waegeneire]

I have the same issue as pelzflorian about the GPT errors.

To fix the  GPT mismatch you just need to execute the following command,
where device is something like "/dev/sdc":
sudo fdisk "$device" <

bug#38447: Instructions to reproduce the issue

[Brice Waegeneire]

I had the same issue on a Hystou P04 and managed to reproduce it several 
times.

Attached to this email is the dump of the installer.

Start the installation process but try to make it fail,
for example by removing the EFI partition during the guided partition,
and when the "Installation failed" menu appear choose "Retrysystem 
install",

on the right. Then restart the installation process with the
same choices and the installer will crash after selecting the keyboard 
layout

variant.

Some time, if you wait for a few minutes before retrying the 
installation, the
crash won't be triggered but then the disk you partitioned during the 
first
installation process won't be available anymore in the disk selection 
menu.


The choices I entered in the installation wizard was:
1. English
2. United States
3. Graphical install
4. Europe
5. Paris
6. English (US)
7. English (intl., with AltGr dead keys)
In ice-9/eval.scm:
619:8 19 (_ #(#(# #< name: newt 
init: # exit: # exit-error: # final-…>) #))
In ice-9/boot-9.scm:
829:9 18 (catch #t # 
# _)
In ice-9/eval.scm:
619:8 17 (_ #(#(#(# #< name: 
newt init: # exit: # exit-error: 
# fi…> …)) …))
   626:19 16 (_ #(#(#(# #< name: 
newt init: # exit: # exit-error: 
# fi…> …)) …))
In ./gnu/installer/steps.scm:
189:6 15 (run-installer-steps #:steps _ #:rewind-strategy _ #:menu-proc _)
In ice-9/boot-9.scm:
829:9 14 (catch srfi-34 # # _)
829:9 13 (catch srfi-34 # # _)
829:9 12 (catch srfi-34 # # _)
829:9 11 (catch srfi-34 # # _)
In ./gnu/installer/steps.scm:
   182:21 10 (_)
In ice-9/eval.scm:
619:8  9 (_ #(#(#(#) #< name: 
newt init: # exit: # exit-error: 
# fin…>) #))
In ./gnu/installer/keymap.scm:
163:7  8 (_ _)
In unknown file:
   7 (scm-error misc-error #f "~A" ("Unable to locate keymap update 
file") #f)
In ice-9/boot-9.scm:
   751:25  6 (dispatch-exception 4 misc-error (#f "~A" ("Unable to locate 
keymap update file") #f))
In ice-9/eval.scm:
619:8  5 (_ #(#(# #< name: newt 
init: # exit: # exit-error: # final-…>) …))
619:8  4 (_ #(#(#(# #< name: 
newt init: # exit: # exit-error: 
# f…>) …) #))
In ice-9/ports.scm:
   462:17  3 (call-with-output-file _ _ #:binary _ #:encoding _)
In ice-9/eval.scm:
619:8  2 (_ #(#(# misc-error (#f "~A" 
("Unable to locate keymap update file") #f)) #))
159:9  1 (_ #(#(# misc-error (#f "~A" 
("Unable to locate keymap update file") #f)) #))
In unknown file:
   0 (make-stack #t)
ice-9/eval.scm:159:9: Unable to locate keymap update file

bug#38565: Cannot run pre-compiled Firefox

[Arne Babenhauserheide]

Arne Babenhauserheide  writes:

>> Not an immediate solution, but it would be nice if they provided a
>> flatpack image.
>
> Looks like this already exists:
> https://firefox-flatpak.mojefedora.cz/
>
> Thank you!
>
> … but it segfaults:
>
> $ guix install flatpak

I now have a working setup:

# sudo flatpak install --from 
https://firefox-flatpak.mojefedora.cz/org.mozilla.FirefoxDevEdition.flatpakref
# sudo flatpak install flathub org.freedesktop.Platform.ffmpeg

flatpak run org.mozilla.FirefoxDevEdition

Thank you!

Best wishes,
Arne
-- 
Unpolitisch sein
heißt politisch sein
ohne es zu merken


signature.asc
Description: PGP signature

bug#38565: Cannot run pre-compiled Firefox

[Arne Babenhauserheide]

Efraim Flashner  writes:

> If it worked until about 2 months ago it might be related to the glibc
> bump. One thing you could do is create a profile from before the
> core-updates merge and LD_PRELOAD from there.

How can I do that? Can I simply specify the commit to use?

> Not an immediate solution, but it would be nice if they provided a
> flatpack image.

Looks like this already exists:
https://firefox-flatpak.mojefedora.cz/

Thank you!

… but it segfaults:

$ guix install flatpak
$ gdb --args 
/gnu/store/x7gab23a49z1fnyikj6gbrz6hl0widv4-flatpak-1.4.3/bin/.flatpak-real 
remote-add --from org.mozilla.FirefoxRepo 
https://firefox-flatpak.mojefedora.cz/org.mozilla.FirefoxRepo.flatpakrepo
GNU gdb (GDB) 8.3.1
Copyright (C) 2019 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "x86_64-unknown-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
.
Find the GDB manual and other documentation resources online at:
.

For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from 
/gnu/store/x7gab23a49z1fnyikj6gbrz6hl0widv4-flatpak-1.4.3/bin/.flatpak-real...
(No debugging symbols found in 
/gnu/store/x7gab23a49z1fnyikj6gbrz6hl0widv4-flatpak-1.4.3/bin/.flatpak-real)
(gdb) run
Starting program: 
/gnu/store/x7gab23a49z1fnyikj6gbrz6hl0widv4-flatpak-1.4.3/bin/.flatpak-real 
remote-add --from org.mozilla.FirefoxRepo 
https://firefox-flatpak.mojefedora.cz/org.mozilla.FirefoxRepo.flatpakrepo
[Thread debugging using libthread_db enabled]
Using host libthread_db library 
"/gnu/store/ahqgl4h89xqj695lgqvsaf6zh2nhy4pj-glibc-2.29/lib/libthread_db.so.1".
[New Thread 0x768a0700 (LWP 20416)]
[New Thread 0x7609f700 (LWP 20417)]

Note that the directories 

'/var/lib/flatpak/exports/share'
'/home/arne/.local/share/flatpak/exports/share'

are not in the search path set by the XDG_DATA_DIRS environment variable, so
applications installed by Flatpak may not appear on your desktop until the
session is restarted.

[New Thread 0x7550e700 (LWP 20418)]
[New Thread 0x74d0d700 (LWP 20419)]

Thread 1 ".flatpak-real" received signal SIGSEGV, Segmentation fault.
0x773bc9e5 in g_mutex_lock () from 
/gnu/store/b8pr2k0i2zd07zmb7kpffmcimqi337if-glib-2.60.6/lib/libglib-2.0.so.0
(gdb) bt
#0  0x773bc9e5 in g_mutex_lock () from 
/gnu/store/b8pr2k0i2zd07zmb7kpffmcimqi337if-glib-2.60.6/lib/libglib-2.0.so.0
#1  0x77eba137 in _ostree_repo_get_remote () from 
/gnu/store/w7gmjf76wi66k60jwzxd9nd1s32bp9bq-libostree-2019.3/lib/libostree-1.so.1
#2  0x77eba6f3 in ostree_repo_get_remote_option () from 
/gnu/store/w7gmjf76wi66k60jwzxd9nd1s32bp9bq-libostree-2019.3/lib/libostree-1.so.1
#3  0x77ebbecc in ostree_repo_remote_get_url () from 
/gnu/store/w7gmjf76wi66k60jwzxd9nd1s32bp9bq-libostree-2019.3/lib/libostree-1.so.1
#4  0x0045d426 in flatpak_dir_cleanup_remote_for_url_change ()
#5  0x0046c778 in flatpak_dir_modify_remote ()
#6  0x0041b00f in flatpak_builtin_remote_add ()
#7  0x00419755 in main ()


Best wishes,
Arne


signature.asc
Description: PGP signature

bug#38565: Cannot run pre-compiled Firefox

[Arne Babenhauserheide]

Ricardo Wurmus  writes:

> Arne Babenhauserheide  writes:
>
>> Previously I got it working with the following setup:
>>
>> cd $HOME/Downloads/firefox
>> export 
>> LD_LIBRARY_PATH="${LD_LIBRARY_PATH}:/run/current-system/profile/lib/:$HOME/.guix-profile/lib/:$HOME/.guix-profile/lib/nss/:$HOME/.guix-profile/lib/lib/:/gnu/store/69x60a1pn0mf5jv68al8awjfkyp1miwi-gcc-8.3.0-lib/lib/:./browser:."
>> ./firefox-bin
>
> LD_LIBRARY_PATH forces firefox-bin to use libraries from the given
> directories.  These might not be ABI compatible, so a segfault is one of
> the expected outcomes.

Yes — I’m looking for a way to get it working again.

>> This used to work with only minor limitations.
>
> I’m surprised it worked before, because often it doesn’t.  Do you happen
> to know what libraries and their exact versions this firefox binary
> expects?

$ ldd firefox-bin
linux-vdso.so.1 (0x7ffed00b5000)
libpthread.so.0 => 
/gnu/store/jdfs3xvlnj272475yja6bjrprfsgnkdd-glibc-2.29/lib/libpthread.so.0 
(0x7f23d000)
libdl.so.2 => 
/gnu/store/jdfs3xvlnj272475yja6bjrprfsgnkdd-glibc-2.29/lib/libdl.so.2 
(0x7f238000)
librt.so.1 => 
/gnu/store/jdfs3xvlnj272475yja6bjrprfsgnkdd-glibc-2.29/lib/librt.so.1 
(0x7f238887e000)
libstdc++.so.6 => not found
libm.so.6 => 
/gnu/store/jdfs3xvlnj272475yja6bjrprfsgnkdd-glibc-2.29/lib/libm.so.6 
(0x7f238873e000)
libgcc_s.so.1 => not found
libc.so.6 => 
/gnu/store/jdfs3xvlnj272475yja6bjrprfsgnkdd-glibc-2.29/lib/libc.so.6 
(0x7f2388582000)
/lib64/ld-linux-x86-64.so.2 => 
/gnu/store/jdfs3xvlnj272475yja6bjrprfsgnkdd-glibc-2.29/lib/ld-linux-x86-64.so.2 
(0x7f2388916000)

The shipped libraries:

$ ldd *so | cut -d ' ' -f 1  | sort -u | grep -e "^[^l]"
libatk-1.0.so.0
libblkid.so.1
libcairo-gobject.so.2
libcairo.so.2
libc.so.6
libdbus-1.so.3
libdbus-glib-1.so.2
libdl.so.2
libffi.so.6
libfontconfig.so.1
libfreetype.so.6
libgcc_s.so.1
libgdk-3.so.0
libgdk_pixbuf-2.0.so.0
libgio-2.0.so.0
libglib-2.0.so.0
libgmodule-2.0.so.0
libgobject-2.0.so.0
libgthread-2.0.so.0
libgtk-3.so.0
liblgpllibs.so
libmount.so.1
libmozavutil.so
libmozgtk.so
libmozsandbox.so
libmozsqlite3.so
libmozwayland.so
libm.so.6
libnspr4.so
libnss3.so
libnssutil3.so
libpango-1.0.so.0
libpangocairo-1.0.so.0
libpangoft2-1.0.so.0
libpcre.so.1
libplc4.so
libplds4.so
libpthread.so.0
libresolv.so.2
librt.so.1
libselinux.so.1
libsmime3.so
libssl3.so
libstdc++.so.6
libX11.so.6
libX11-xcb.so.1
libxcb-shm.so.0
libxcb.so.1
libXcomposite.so.1
libXcursor.so.1
libXdamage.so.1
libXext.so.6
libXfixes.so.3
libXi.so.6
libXrender.so.1
libXt.so.6
libz.so.1
linux-vdso.so.1

Best wishes,
Arne
-- 
Unpolitisch sein
heißt politisch sein
ohne es zu merken


signature.asc
Description: PGP signature

bug#38320: Cuirass: Allow to use authenticated Git repositories as inputs

[Clément Lassieur]

Hi everyone,

Whoo, nice, thank you so much Mathieu!  I'll test everything this
week-end probably, and start working on the (guix git) / Cuirass
counterpart (which is 1% of the work :D).

Mathieu Othacehe  writes:

> Now regarding (guix git) integration, I have a question. It would be nice
> to have "guix pull" and Cuirass support ssh authenticated
> directories.

Indeed :)  Almost there!

> So "latest-repository-commit" could be call with ssh authentication
> parameters. However, the guix-daemon won't be able to communicate with the
> user ssh-agent, and storing an unencrypted private ssh key in the store
> doesn't feel great to me.
>
> Do you see any workaround?

As far as I understand, LATEST-REPOSITORY-COMMIT is never called by the
daemon, it downloads stuff first and then calls ADD-TO-STORE.  So both
using the SSH agent or passing a private SSH key should be
straightforward.

Clément

bug#38565: Cannot run pre-compiled Firefox

[Efraim Flashner]

If it worked until about 2 months ago it might be related to the glibc
bump. One thing you could do is create a profile from before the
core-updates merge and LD_PRELOAD from there.

Not an immediate solution, but it would be nice if they provided a
flatpack image.

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


signature.asc
Description: PGP signature

bug#38565: Cannot run pre-compiled Firefox

[Ricardo Wurmus]

Arne Babenhauserheide  writes:

> Previously I got it working with the following setup:
>
> cd $HOME/Downloads/firefox
> export 
> LD_LIBRARY_PATH="${LD_LIBRARY_PATH}:/run/current-system/profile/lib/:$HOME/.guix-profile/lib/:$HOME/.guix-profile/lib/nss/:$HOME/.guix-profile/lib/lib/:/gnu/store/69x60a1pn0mf5jv68al8awjfkyp1miwi-gcc-8.3.0-lib/lib/:./browser:."
> ./firefox-bin

LD_LIBRARY_PATH forces firefox-bin to use libraries from the given
directories.  These might not be ABI compatible, so a segfault is one of
the expected outcomes.

> This used to work with only minor limitations.

I’m surprised it worked before, because often it doesn’t.  Do you happen
to know what libraries and their exact versions this firefox binary
expects?

--
Ricardo

bug#38565: Cannot run pre-compiled Firefox

[Arne Babenhauserheide]

Hi,


Until about two months ago I could run firefox binaries downloaded via
https://download.mozilla.org/?product=firefox-latest-ssl&os=linux64&lang=en-US

For about two months now I’m seeing segfaults when I try to run it.

Previously I got it working with the following setup:

cd $HOME/Downloads/firefox
export 
LD_LIBRARY_PATH="${LD_LIBRARY_PATH}:/run/current-system/profile/lib/:$HOME/.guix-profile/lib/:$HOME/.guix-profile/lib/nss/:$HOME/.guix-profile/lib/lib/:/gnu/store/69x60a1pn0mf5jv68al8awjfkyp1miwi-gcc-8.3.0-lib/lib/:./browser:."
./firefox-bin

This used to work with only minor limitations.


Now what I get is

./firefox-bin
Speicherzugriffsfehler (segmentation fault)


With gdb I get the following:

$ gdb ./firefox-bin
…
Reading symbols from ./firefox-bin...
(No debugging symbols found in ./firefox-bin)
(gdb) run
Starting program: /home/arne/Downloads/firefox/firefox-bin

Program received signal SIGSEGV, Segmentation fault.
0x in ?? ()
(gdb) bt
#0  0x in ?? ()
#1  0x77c28d38 in ?? ()
#2  0x in ?? ()


Do you know a way to fix this? I need a way to test different firefox
versions, because I use Guix in homeoffice which includes web
development. If I can’t get these to run, I might have to switch away to
a different distribution. There’s so much going for Guix that I want to
keep it, but being able to run binaries compiled for Linux X86_64 is a
hard requirement for work.


Best wishes,
Arne
--
Unpolitisch sein
heißt politisch sein
ohne es zu merken


signature.asc
Description: PGP signature

bug#38320: Cuirass: Allow to use authenticated Git repositories as inputs

[Mathieu Othacehe]

Hey!

> Apart from this detail, it looks great to me!
>
> You have push access, right?
>
> Speaking of which, we really need to push a release at some point.
> Erik, would you be available to do that, or would you like to delegate?

Great, thanks for reviewing :). I couldn't get it to work with a generated
client rsa key for an unknown reason, but pushed anyway.

Now regarding (guix git) integration, I have a question. It would be nice
to have "guix pull" and Cuirass support ssh authenticated
directories.

So "latest-repository-commit" could be call with ssh authentication
parameters. However, the guix-daemon won't be able to communicate with the
user ssh-agent, and storing an unencrypted private ssh key in the store
doesn't feel great to me.

Do you see any workaround?

Thanks,

Mathieu