Kooha icon indicating copy to clipboard operation
Kooha copied to clipboard

Unable to build Arch package due to libadwaita version

Open orhun opened this issue 3 years ago • 3 comments

System Info Unable to run Kooha.

Describe the bug

Kooha-2.1.1/meson.build:17:0: ERROR: Invalid version of dependency, need 'libadwaita-1' ['>= 1.2'] found '1.1.4'.

To Reproduce Steps to reproduce the behavior:

  1. Fetch PKGBUILD from https://github.com/archlinux/svntogit-community/blob/packages/kooha/trunk/PKGBUILD
  2. Update version to 2.1.1
  3. Build via extra-x86_64-build
  4. See error

Expected behavior Successful build.

Screenshots -

Additional context -

orhun avatar Aug 31 '22 18:08 orhun

Kooha requires libadwaita 1.2 to build, it won't work with 1.1

SeaDve avatar Aug 31 '22 21:08 SeaDve

Libadwaita 1.2 has not been released yet. Both the upstream project and Rust library used in this project are marked as pre-releases. This means most distros will be stuck on an old version until this is resolved. Generally speaking releasing software with stable tags that depends on other project's unreleased code is not a great plan. Given the depth of places libadwaita is tied into Gnome I wouldn't expect most distros to get updated until stable releases are cut upstream.

alerque avatar Sep 07 '22 19:09 alerque

I have to agree with alerque here, I too was unable to build and help with issues on systems other than gnome. I even went as far as trying to get some dependencies to build libadwaita from source, but it proved to be quite a nuisance....

But there is also good news, as libadwaita 1.2 is now officially released building now also works on arch. For other distros the entire problem with it only really being viable in gnome builder persists.

DashieTM avatar Sep 15 '22 19:09 DashieTM

My bad for using unreleased software. But, at least on Flatpak, I tested it to ensure that things work as expected, so users would not notice any problem at all by using a pre-released libadwaita.

Since 1.2 is now released, I'm closing this as resolved. You could also use 2.0.1 or patch out AdwAboutWindow in 2.1.* to make Kooha build on older libadwaita versions.

SeaDve avatar Sep 16 '22 11:09 SeaDve

Also, I noticed from https://github.com/archlinux/svntogit-community/blob/packages/kooha/trunk/PKGBUILD, it seems to be still depending on python-gobject. I think that can be removed.

SeaDve avatar Sep 16 '22 11:09 SeaDve

Thanks. I'm trying to build against libadwaita 1.2 now and ran into this ... perhaps related perhaps not. Pinging @orhun the other Arch Linux packager on this app since I'm on my way out the door for some travel and may or may not get around to debugging this in a timely manner.

   Compiling kooha v2.1.0 (/build/kooha/src/Kooha-2.1.0)
    Finished test [unoptimized + debuginfo] target(s) in 1m 23s
     Running unittests src/main.rs (src/debug/deps/kooha-0cf1d0added7fdc2)
thread '<unnamed>' panicked at 'Tests failed to initialize gtk: BoolError { message: "Failed to initialize GTK", filename: "/build/kooha/src/build/cargo-home/registry/src/github.com-1ecc6299db
9ec823/gtk4-0.4.8/src/rt.rs", function: "gtk4::rt", line: 145 }', /build/kooha/src/build/cargo-home/registry/src/github.com-1ecc6299db9ec823/gtk4-0.4.8/src/lib.rs:88:27
stack backtrace:
   0: rust_begin_unwind
             at /rustc/1.63.0/library/std/src/panicking.rs:584:5
   1: core::panicking::panic_fmt
             at /rustc/1.63.0/library/core/src/panicking.rs:142:14
   2: core::result::unwrap_failed
             at /rustc/1.63.0/library/core/src/result.rs:1805:5
   3: core::result::Result<T,E>::expect
             at /rustc/1.63.0/library/core/src/result.rs:1055:23
   4: gtk4::TEST_THREAD_WORKER::{{closure}}::{{closure}}
             at /build/kooha/src/build/cargo-home/registry/src/github.com-1ecc6299db9ec823/gtk4-0.4.8/src/lib.rs:88:13
   5: core::ops::function::FnOnce::call_once{{vtable.shim}}
             at /rustc/1.63.0/library/core/src/ops/function.rs:248:5
   6: <alloc::boxed::Box<F,A> as core::ops::function::FnOnce<Args>>::call_once
             at /rustc/1.63.0/library/alloc/src/boxed.rs:1951:9
   7: <alloc::boxed::Box<F,A> as core::ops::function::FnOnce<Args>>::call_once
             at /rustc/1.63.0/library/alloc/src/boxed.rs:1951:9
   8: glib::thread_pool::spawn_func
             at /build/kooha/src/build/cargo-home/registry/src/github.com-1ecc6299db9ec823/glib-0.15.12/src/thread_pool.rs:187:5
   9: <unknown>
  10: <unknown>
  11: <unknown>
  12: <unknown>
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.
fatal runtime error: failed to initiate panic, error 5
error: test failed, to rerun pass '--bin kooha'

alerque avatar Sep 16 '22 11:09 alerque

Thanks. I'm trying to build against libadwaita 1.2 now and ran into this ... perhaps related perhaps not. Pinging @orhun the other Arch Linux packager on this app since I'm on my way out the door for some travel and may or may not get around to debugging this in a timely manner.

   Compiling kooha v2.1.0 (/build/kooha/src/Kooha-2.1.0)
    Finished test [unoptimized + debuginfo] target(s) in 1m 23s
     Running unittests src/main.rs (src/debug/deps/kooha-0cf1d0added7fdc2)
thread '<unnamed>' panicked at 'Tests failed to initialize gtk: BoolError { message: "Failed to initialize GTK", filename: "/build/kooha/src/build/cargo-home/registry/src/github.com-1ecc6299db
9ec823/gtk4-0.4.8/src/rt.rs", function: "gtk4::rt", line: 145 }', /build/kooha/src/build/cargo-home/registry/src/github.com-1ecc6299db9ec823/gtk4-0.4.8/src/lib.rs:88:27
stack backtrace:
   0: rust_begin_unwind
             at /rustc/1.63.0/library/std/src/panicking.rs:584:5
   1: core::panicking::panic_fmt
             at /rustc/1.63.0/library/core/src/panicking.rs:142:14
   2: core::result::unwrap_failed
             at /rustc/1.63.0/library/core/src/result.rs:1805:5
   3: core::result::Result<T,E>::expect
             at /rustc/1.63.0/library/core/src/result.rs:1055:23
   4: gtk4::TEST_THREAD_WORKER::{{closure}}::{{closure}}
             at /build/kooha/src/build/cargo-home/registry/src/github.com-1ecc6299db9ec823/gtk4-0.4.8/src/lib.rs:88:13
   5: core::ops::function::FnOnce::call_once{{vtable.shim}}
             at /rustc/1.63.0/library/core/src/ops/function.rs:248:5
   6: <alloc::boxed::Box<F,A> as core::ops::function::FnOnce<Args>>::call_once
             at /rustc/1.63.0/library/alloc/src/boxed.rs:1951:9
   7: <alloc::boxed::Box<F,A> as core::ops::function::FnOnce<Args>>::call_once
             at /rustc/1.63.0/library/alloc/src/boxed.rs:1951:9
   8: glib::thread_pool::spawn_func
             at /build/kooha/src/build/cargo-home/registry/src/github.com-1ecc6299db9ec823/glib-0.15.12/src/thread_pool.rs:187:5
   9: <unknown>
  10: <unknown>
  11: <unknown>
  12: <unknown>
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.
fatal runtime error: failed to initiate panic, error 5
error: test failed, to rerun pass '--bin kooha'

GTK seems not to be initialized due to a lack of display. Maybe try to run build with xvfb-run

SeaDve avatar Sep 16 '22 11:09 SeaDve

Why would it need to be initialized? One should not need to be in an active GUI environment to build an app. The libraries it needs to build against are there and since we're building distribution packages there is no telling if what we build in would be what people are running in. We build in special chroot environments anyway, each package with it's exact dependencies.

Spawning in xvfb-run might be doable but it is also a ridiculous stunt to have to pull to build anything.There are only 9 other packages in the entire distro that require a stunt like that to build, including dozens of different desktop environments and hundreds and hundreds of GUI apps.

alerque avatar Sep 16 '22 17:09 alerque

Why would it need to be initialized? One should not need to be in an active GUI environment to build an app. The libraries it needs to build against are there and since we're building distribution packages there is no telling if what we build in would be what people are running in. We build in special chroot environments anyway, each package with it's exact dependencies.

Spawning in xvfb-run might be doable but it is also a ridiculous stunt to have to pull to build anything.There are only 9 other packages in the entire distro that require a stunt like that to build, including dozens of different desktop environments and hundreds and hundreds of GUI apps.

It's only required for the tests, you can run build without tests, and you'll be fine without initializing gtk.

If you checked the panic message while running your build, that is also what is it trying to say

SeaDve avatar Sep 16 '22 22:09 SeaDve

I have used xvfb-run for tests (as checkdepends) and updated Kooha to 2.1.1. (commit)

orhun avatar Sep 17 '22 13:09 orhun

It's only required for the tests

Thanks for clarifying. I did miss that our error moved from the build stage to the test stage. Sure requiring it to be initialized is totally fair for testing purposes.

alerque avatar Sep 27 '22 09:09 alerque