[bug#34044] Packaging Jami (ex GNU Ring)

[bug#34044] Packaging Jami (ex GNU Ring)

[Ricardo Wurmus]

Hi Pierre,

> But then the client fails:
>
> --8<---------------cut here---------------start------------->8---
>> /gnu/store/6q1ysbyki4v1zidbcndvyrchm3jncs58-ring-client-gnome-20190108.1.8659b2c/bin/gnome-ring --debug
> GLib-GIO-Message: 19:57:22.364: Using the 'memory' GSettings backend.  Your settings will not be saved or shared with other applications.
> ** (gnome-ring:12882): DEBUG: 19:57:22.365: debug enabled
> ** Message: 19:57:22.371: Jami GNOME client version: 32e606106920a21da416ef365fb654b5df721098
> ** Message: 19:57:22.371: git ref: unknown
> ** (gnome-ring:12882): DEBUG: 19:57:22.371: enabling autostart
> ** (gnome-ring:12882): DEBUG: 19:57:22.371: checking /usr/share/gnome-ring/gnome-ring.desktop
> ** (gnome-ring:12882): DEBUG: 19:57:22.371: checking /usr/local/share/gnome-ring/gnome-ring.desktop
> ** (gnome-ring:12882): DEBUG: 19:57:22.371: checking /gnu/store/6q1ysbyki4v1zidbcndvyrchm3jncs58-ring-client-gnome-20190108.1.8659b2c/share/gnome-ring/gnome-ring.desktop
> ** (gnome-ring:12882): DEBUG: 19:57:22.371: '/home/ambrevar/.config/autostart/gnome-ring.desktop' is already a symlink to '/gnu/store/6q1ysbyki4v1zidbcndvyrchm3jncs58-ring-client-gnome-20190108.1.8659b2c/share/gnome-ring/gnome-ring.desktop'
> (gnome-ring:12882): Gtk-DEBUG: 19:57:22.862: Connecting to session manager
> (gnome-ring:12882): Gtk-DEBUG: 19:57:22.862: Failed to get the GNOME session proxy: The name org.gnome.SessionManager is not owned
> (gnome-ring:12882): Gtk-DEBUG: 19:57:22.863: Failed to get the Xfce session proxy: The name org.xfce.SessionManager is not owned
> (gnome-ring:12882): Gtk-DEBUG: 19:57:22.863: Failed to get an inhibit portal proxy: The name org.freedesktop.portal.Desktop is not owned
> /gnu/store/6q1ysbyki4v1zidbcndvyrchm3jncs58-ring-client-gnome-20190108.1.8659b2c/bin/gnome-ring: symbol lookup error: /gnu/store/zng0ix6b6icm8f8r6cqr09ykiz6rgrpg-qtbase-5.11.2/lib/qt5/plugins/sqldrivers/libqsqlite.so: undefined symbol: sqlite3_column_table_name16
> --8<---------------cut here---------------end--------------->8---

We have a package “sqlite-with-column-metadata” which builds sqlite3
with the SQLITE_ENABLE_COLUMN_METADATA macro defined.  This enables
“sqlite3_column_table_name16”.  “qtbase” uses this variant of sqlite
since 2018.  This should be fine.

Are your packages linked with any other variant of sqlite?

--
Ricardo

[bug#34044] Packaging Jami (ex GNU Ring)

[Pierre Neidhardt]

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

Hi,

Thanks for the hint, Ricardo, you might be having a good clue here.

--8<---------------cut here---------------start------------->8---
$ ./pre-inst-env guix size ring-client-gnome
store item                                                       total    self
...
/gnu/store/z76zpxqj3aa0s9hv7dvcwp7ap65wjjj5-qtbase-5.11.3         1264.0    67.7   4.2%
...
/gnu/store/1r6qhwlynjv9l9iarbnr78p46h8ry7ls-sqlite-with-column-metadata-3.24.0    79.4     4.2   0.3%
/gnu/store/pba3xzrkq2k4wgh3arif4xpkblr5qz2n-sqlite-3.24.0           79.4     4.2   0.3%
...
total: 1628.4 MiB
--8<---------------cut here---------------end--------------->8---

So we've got 2 sqlite in the closure.  Looks like ring-client-gnome is confused
by that.

Looking more closely, the closure of qtbase contains both sqlite packages has
well.
I suspect a bug in the qtbase package.  Anyone?

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

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

[bug#34044] Packaging Jami (ex GNU Ring)

[Ricardo Wurmus]

Pierre Neidhardt <mail@ambrevar.xyz> writes:

> Looking more closely, the closure of qtbase contains both sqlite packages has
> well.
> I suspect a bug in the qtbase package.

That might be because dependencies of qtbase don’t use that same sqlite
variant.  Generally, we should make sure that we don’t have different
library variants in the closure.

What pulls in the vanilla sqlite package?  Can we use input rewriting to
ensure that all references to sqlite are replaced with
sqlite-with-column-metadata?  (This would require building package
variants.)

--
Ricardo

[bug#34044] Packaging Jami (ex GNU Ring)

[Pierre Neidhardt]

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

Here is the list of the direct dependencies in qtbase that draw sqlite:

- mesa
- libinput
- libwebp
- nss

I'll see if I can build package variants.  Do you have examples of where this
was done before?

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

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

[bug#34044] Packaging Jami (ex GNU Ring)

[Pierre Neidhardt]

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

Actually libwebp is not in the list.

I tried rewriting the inputs to no avail.

--8<---------------cut here---------------start------------->8---
(define-public with-sqlite-with-column-metadata
  (package-input-rewriting `((,sqlite . ,sqlite-with-column-metadata))
                           sqlite-variant-package-name))

(define-public libinput-minimal-qt
  (with-sqlite-with-column-metadata libinput-minimal))
  
; etc.
--8<---------------cut here---------------end--------------->8---

Building libinput-minimal-qt gives me a closure that still depends on sqlite.
I guess sqlite must be an implicit dependency then.

To see where it comes from, I produced a graph:

--8<---------------cut here---------------start------------->8---
./pre-inst-env guix graph libinput | dot -Tsvg > dag.svg
--8<---------------cut here---------------end--------------->8---

Sadly this is quite big and hard to read.

Is there a way to trim the graph so that it only display the relationships
between libinput and sqlite?  This would be a very convenient feature.

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

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

[bug#34044] Packaging Jami (ex GNU Ring)

[Pierre Neidhardt]

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

Forget it, the graph is pretty simple: only python2 and python3 depend on
sqlite.  I'll see if I can force them to use sqlite-with-column-metadata.

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

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

[bug#34044] Packaging Jami (ex GNU Ring)

[Ricardo Wurmus]

Pierre Neidhardt <mail@ambrevar.xyz> writes:

> Forget it, the graph is pretty simple: only python2 and python3 depend on
> sqlite.  I'll see if I can force them to use sqlite-with-column-metadata.

That would require a separate build of python2 and python3.  That’s
quite an expensive thing to do just for Jami.  Can you see another way
around this?  (E.g. LD_LIBRARY_PATH or … abusing grafts?)

-- 
Ricardo

[bug#34044] Packaging Jami (ex GNU Ring)

[Pierre Neidhardt]

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

LD_LIBRARY_PATH: Hmm, do you mean we could put sqlite-with-column-metadata
before sqlite so that it takes precedence?

What do you mean with abusing grafts?

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

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

[bug#34044] Packaging Jami (ex GNU Ring)

[Pierre Neidhardt]

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

By the way, why don't we build SQlite with column-metadata by default?  That
would solve it I think.

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

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

[bug#34044] Packaging Jami (ex GNU Ring)

[Ricardo Wurmus]

Pierre Neidhardt <mail@ambrevar.xyz> writes:

> By the way, why don't we build SQlite with column-metadata by default?  That
> would solve it I think.

Eventually, yes.  But we can’t do this on the master branch.

-- 
Ricardo

[bug#34044] Packaging Jami (ex GNU Ring)

[Ricardo Wurmus]

Pierre Neidhardt <mail@ambrevar.xyz> writes:

> LD_LIBRARY_PATH: Hmm, do you mean we could put sqlite-with-column-metadata
> before sqlite so that it takes precedence?
>
> What do you mean with abusing grafts?

I mean: rewriting references to sqlite (so that they are replaced with
references to sqlite-with-column-metadata) in the Pythons under the
assumption that the ABI is the same.

--
Ricardo

[bug#34044] Packaging Jami (ex GNU Ring)

[Pierre Neidhardt]

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

I could fix it manually with

--8<---------------cut here---------------start------------->8---
env LD_LIBRARY_PATH="/gnu/store/74i7r7qp1km0gw1i22fnq3szbgc9mpdx-sqlite-with-column-metadata-3.26.0/lib:$LD_LIBRARY_PATH" /gnu/store/2frbprf0qrqrk9v5wy0xfzkvmqk27wfk-ring-client-gnome-20190108.1.8659b2c/bin/gnome-ring
--8<---------------cut here---------------end--------------->8---

Something weird: the original error message

--8<---------------cut here---------------start------------->8---
/gnu/store/6q1ysbyki4v1zidbcndvyrchm3jncs58-ring-client-gnome-20190108.1.8659b2c/bin/gnome-ring:
symbol lookup error:
/gnu/store/zng0ix6b6icm8f8r6cqr09ykiz6rgrpg-qtbase-5.11.2/lib/qt5/plugins/sqldrivers/libqsqlite.so:
undefined symbol: sqlite3_column_table_name16
--8<---------------cut here---------------end--------------->8---

suggests that our build of qtbase lacks the symbol.  A "strings libqsqlite.so"
reveals that the symbol is there.  Besdies:

--8<---------------cut here---------------start------------->8---
> ldd /gnu/store/zng0ix6b6icm8f8r6cqr09ykiz6rgrpg-qtbase-5.11.2/lib/qt5/plugins/sqldrivers/libqsqlite.so
...
	libsqlite3.so.0 => /gnu/store/74i7r7qp1km0gw1i22fnq3szbgc9mpdx-sqlite-with-column-metadata-3.26.0/lib/libsqlite3.so.0 (0x00007ff81f146000)
--8<---------------cut here---------------end--------------->8---

So libqsqlite.so is linked against the right libsqlite3.so.0.  
This makes me wonder how the LD_LIBRARY_PATH trick above could work at all.

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

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

[bug#34044] Packaging Jami (ex GNU Ring)

[Pierre Neidhardt]

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

I've pushed the patch on the wip-ring branch, it seems to work.
Let me know if you think it's read to merge onto master.

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

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

[bug#34044] Packaging Jami (ex GNU Ring)

[Christopher Lemmer Webber]

Pierre Neidhardt writes:

> I've pushed the patch on the wip-ring branch, it seems to work.
> Let me know if you think it's read to merge onto master.

I've compiled and run this.  I was able to install ring-client-gnome and
get it up and running (I rebased against git master and it's fine) via
`ring.cx`.  However, when I run it, it complains that it can't find the
daemon and shuts down.  Any idea how to run that so I can test further?

Also, there's a few TODOs that I'm not sure are still relevant in the
ring-client-gnome definition:

  ;; TODO: Don't prompt for root password on build?

       ;; TODO: We must wrap ring-client-gnome to use
       ;; sqlite-with-column-metadata or else it will fail with:
       ;;
       ;;   /gnu/store/...-qtbase-5.11.2/lib/qt5/plugins/sqldrivers/libqsqlite.so:
       ;;   undefined symbol: sqlite3_column_table_name16
       ;;
       ;; qtbase is built against sqlite-with-column-metadata but somehow
       ;; ring-client-gnome ends up with both sqlite and
       ;; sqlite-with-column-metadata as inputs and it seems that
       ;; libqsqlite.so gets confused.

I haven't run into these alleged problems.  Are they still a concern?

[bug#34044] Packaging Jami (ex GNU Ring)

[Pierre Neidhardt]

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

Christopher Lemmer Webber <cwebber@dustycloud.org> writes:

> I've compiled and run this.  I was able to install ring-client-gnome and
> get it up and running (I rebased against git master and it's fine) via
> `ring.cx`.  However, when I run it, it complains that it can't find the
> daemon and shuts down.  Any idea how to run that so I can test further?

If you run Gnome or KDE, the daemon should be started for you.
Otherwise, you've got to start it manually:

/gnu/store/...-libring.../lib/dring -dcp

This is a bit involved for the casual user, but arguably this should be
fixed upstream in the ring.cx script: I don't see why you need a desktop
environment to automate this.

> Also, there's a few TODOs that I'm not sure are still relevant in the
> ring-client-gnome definition:
>
>   ;; TODO: Don't prompt for root password on build?

I had this once but could not reproduce, so I guess it's safe to remove now.

>        ;; TODO: We must wrap ring-client-gnome to use
>        ;; sqlite-with-column-metadata or else it will fail with:
>        ;;
>        ;;   /gnu/store/...-qtbase-5.11.2/lib/qt5/plugins/sqldrivers/libqsqlite.so:
>        ;;   undefined symbol: sqlite3_column_table_name16
>        ;;
>        ;; qtbase is built against sqlite-with-column-metadata but somehow
>        ;; ring-client-gnome ends up with both sqlite and
>        ;; sqlite-with-column-metadata as inputs and it seems that
>        ;; libqsqlite.so gets confused.

This is still valid, if you look at the LD_LIBRARY_PATH wrapper around gnome-ring.
The thing is, it seems that qtbase is loading it's libraries at runtime
and gets confused between which one to pick as opposed to the libraries
it was linked against.  This doesn't make much sense to me.  I'd like to
understand more what's going on.

The wrappers works, but I'd rather leave the TODO: (or at least the
comment) until this has been properly fixed.

Thanks for testing!

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

[bug#34044] Packaging Jami (ex GNU Ring)

[Pierre Neidhardt]

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

I've reported the issue with the daemon not starting automatically
upstream:

  https://git.jami.net/savoirfairelinux/ring-client-gnome/issues/999

Anyways, did anyone have time to test this package?

I think the package is in good enough shape at this point, I'll probably
merge tomorrow and should there be more issues, the rest of the
community will be able to test and report more easily.

Cheers!

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

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

[bug#34044] Packaging Jami (ex GNU Ring)

[Christopher Lemmer Webber]

Pierre Neidhardt writes:

> I've reported the issue with the daemon not starting automatically
> upstream:
>
>   https://git.jami.net/savoirfairelinux/ring-client-gnome/issues/999
>
> Anyways, did anyone have time to test this package?
>
> I think the package is in good enough shape at this point, I'll probably
> merge tomorrow and should there be more issues, the rest of the
> community will be able to test and report more easily.
>
> Cheers!

I got it open even though I didn't successfully make a call.  My
suspicion is that the package works fine and I was hitting some issue I
haven't yet debugged.  So, it has approval from me!

[bug#34044] Packaging Jami (ex GNU Ring)

[Pierre Neidhardt]

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

Merged, thank you all :)

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

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

[bug#34044] Packaging Jami (ex GNU Ring)

[Ricardo Wurmus]

Pierre Neidhardt <mail@ambrevar.xyz> writes:

> Merged, thank you all :)

Closing.

-- 
Ricardo

[bug#34044] Packaging Jami (ex GNU Ring)

[Brett Gilio]

Ricardo Wurmus writes:

> Pierre Neidhardt <mail@ambrevar.xyz> writes:
>
>> Merged, thank you all :)
>
> Closing.

What is the solution to the daemon not autostarting? I have it installed
on my end for testing, and I cant seem to find dring on my path to
manually start it.

[bug#34044] Packaging Jami (ex GNU Ring)

[Pierre Neidhardt]

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

Brett Gilio <brettg@posteo.net> writes:

> What is the solution to the daemon not autostarting? I have it installed
> on my end for testing, and I cant seem to find dring on my path to
> manually start it.

The daemon is started automatically with dbus, but for that you must install it
to your user profile.

You can also start the daemon manually:

  /gnu/store/...-libring-.../lib/dring -cdp

Hope that helps!

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

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