Add Archlinux support

[PrzemekSkw]

It will be great if someone make AUR package.

Regards.

[rhysperry111]

Just working on a PKGBUILD right now (the one in the makedeb dir confused me until I realised that makedeb was a weird debian tool :P, and also debian dependencies look like hell lmao).

In the deb version, libayatana-appindicator is used, but there's also libappindicator-gtk3 which was already installed on my system. Does @hwittenborn have a preference over which is used?

Another point is that currently I cannot build because of a module called file-lock, so I am currently waiting on alfiedotwtf/file-lock#6 (this is why I'm personally fan of the traditional distribution-managed dependency systems rather than the huge dep trees that get pulled with tools like cargo, pip and npm :P)

---

Got the file-lock error fixed with the help of upstream, now I'm waiting on help with a build error in sea-orm.

[yochananmarqos]

I have a PKGBUILD in progress, but it's currently failing to build due to something with sqlx:

Log

``` Compiling sqlx v0.6.2 error: /build/celeste/src/celeste-0.3.5/target/release/deps/libsqlx_macros-5093f6dbb26cf4ea.so: undefined symbol: sqlite3_unlock_notify --> /build/.cargo/registry/src/github.com-1ecc6299db9ec823/sqlx-0.6.2/src/lib.rs:67:1 | 67 | pub extern crate sqlx_macros; | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ error[E0432]: unresolved imports `self::encode::Encode`, `self::decode::Decode`, `super::Decode`, `super::Encode`, `super::FromRow`, `super::Type` --> /build/.cargo/registry/src/github.com-1ecc6299db9ec823/sqlx-0.6.2/src/lib.rs:126:9 | 126 | pub use self::encode::Encode; | ^^^^^^^^^^^^^^^^^^^^ ... 137 | pub use self::decode::Decode; | ^^^^^^^^^^^^^^^^^^^^ ... 151 | pub use super::Decode; | ^^^^^^^^^^^^^ 152 | pub use super::Encode; | ^^^^^^^^^^^^^ 153 | pub use super::Executor; 154 | pub use super::FromRow; | ^^^^^^^^^^^^^^ ... 158 | pub use super::Type; | ^^^^^^^^^^^ For more information about this error, try `rustc --explain E0432`. error: could not compile `sqlx` due to 2 previous errors warning: build failed, waiting for other jobs to finish... error: Recipe `build` failed on line 3 with exit code 101 ```

[hwittenborn]

@rhysperry111 I was looking at that issue you linked - do you need Celeste to update the version of it's dependencies?

In the deb version, libayatana-appindicator is used, but there's also libappindicator-gtk3 which was already installed on my system. Does @hwittenborn have a preference over which is used?

No you should be able to use either, I might add to makedeb's PKGBUILD to allow either too.

[rhysperry111]

@rhysperry111 I was looking at that issue you linked - do you need Celeste to update the version of it's dependencies?

It would probably help. I'm not too familiar with cargo, but it was being awfully stubborn about changing versions.

No you should be able to use either, I might add to makedeb's PKGBUILD to allow either too.

Cool.

I'm still having trouble getting sea-orm to compile though.

``` Compiling sea-orm v0.10.7 error[E0658]: generic associated types are unstable --> /home/rhys/.cargo/registry/src/github.com-1ecc6299db9ec823/sea-orm-0.10.7/src/database/connection.rs:39:5 | 39 | / type Stream<'a>: Stream> + Send 40 | | where 41 | | Self: 'a; | |_________________^ | = note: see issue #44265 for more information = help: add `#![feature(generic_associated_types)]` to the crate attributes to enable error[E0658]: where clauses on associated types are unstable --> /home/rhys/.cargo/registry/src/github.com-1ecc6299db9ec823/sea-orm-0.10.7/src/database/connection.rs:39:5 | 39 | / type Stream<'a>: Stream> + Send 40 | | where 41 | | Self: 'a; | |_________________^ | = note: see issue #44265 for more information = help: add `#![feature(generic_associated_types)]` to the crate attributes to enable error[E0658]: generic associated types are unstable --> /home/rhys/.cargo/registry/src/github.com-1ecc6299db9ec823/sea-orm-0.10.7/src/database/db_connection.rs:169:5 | 169 | type Stream<'a> = crate::QueryStream; | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ | = note: see issue #44265 for more information = help: add `#![feature(generic_associated_types)]` to the crate attributes to enable error[E0658]: generic associated types are unstable --> /home/rhys/.cargo/registry/src/github.com-1ecc6299db9ec823/sea-orm-0.10.7/src/database/transaction.rs:421:5 | 421 | type Stream<'a> = TransactionStream<'a>; | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ | = note: see issue #44265 for more information = help: add `#![feature(generic_associated_types)]` to the crate attributes to enable error: internal compiler error: compiler/rustc_middle/src/ty/subst.rs:554:13: Region parameter out of range when substituting in region 'b (index=5) ```

---

Guessing part of the problem is that cargo-nightly in the Arch repos hasn't been updated since 01 Nov 2022 (seems to be a mirror issue - working on it :P)

[hwittenborn]

do you need Celeste to update the version of it's dependencies?

It would probably help.

I can get that done when I push some other changes tonight.

Guessing part of the problem is that cargo-nightly in the Arch repos hasn't been updated since 01 Nov 2022 (seems to be a mirror issue - working on it :P)

You should be able to just require rustup as a dependency, is there any reason that wouldn't work?

[yochananmarqos]

@rhysperry111 @hwittenborn cargo-nightly isn't a package, rustup provides it.

[rhysperry111]

I've got a working PKGBUILD now, just need to finish up a few things. I saw rclone was included as a dep but it seems to run fine on my side without it. Should I just include it as an optional dep?

[hwittenborn]

I saw rclone was included as a dep but it seems to run fine on my side without it.

It's needed to log in to Google Drive and Dropbox servers, and more in the future once they get added, so I'd make it required.

[hwittenborn]

Any idea what changed for the thing @yochananmarqos mentioned @rhysperry111?

[rhysperry111]

Not too sure. A bunch of my issues came from the fact I had an outdated rustc. I had to delete ~/.rustup to get it to pull a new version.

[yochananmarqos]

@rhysperry111 Build in a clean chroot.

[yochananmarqos]

@gilvbp Everyone subscribed to this issue received an email just for your +1 reply. Instead, react to the post you like with the appropriate emoji using the emoji selection button.

Notice I've shown you an example with a :+1: on the first post and a :-1: on your post. :stuck_out_tongue_winking_eye:

[yochananmarqos]

I've got a working PKGBUILD now

@rhysperry111

Show me, don't tell me

-- Show Don't Tell, Rush

:stuck_out_tongue_winking_eye:

[rhysperry111]

pkgname=celeste-git
_name=celeste
pkgver=0.3.5.r2.gb87b8a0
pkgrel=1
pkgdesc='GUI file synchronization client that can sync with any cloud provider'
arch=('any')
url='https://github.com/hwittenborn/celeste.git'
license=('GPL3')
depends=('rclone' 'gtk4' 'libadwaita')
makedepends=('cargo-nightly' 'just' 'go' 'gtk3' 'libappindicator-gtk3' 'clang')
provides=('celeste')
source=('git+https://github.com/hwittenborn/celeste.git')
sha256sums=('SKIP')

pkgver() {
    cd "${_name}"
    git describe --long --tags | sed 's/^v//;s/\([^-]*-g\)/r\1/;s/-/./g'
}

build() {
    cd "${_name}"
    just build
}

package() {
    cd "${_name}"
    DESTDIR="${pkgdir}/" just install
}

On my system, it seemed that gtk4 was a run-time dep whereas gtk3 was only needed at compile time (which is the opposite of the makedeb package), and it also seemed that libappindicator-gtk3 wasn't needed at runtime at all, but since I currently don't have a chroot setup it's a little hard to verify the deps properly.

Other than that though, this works for me

[yochananmarqos]

I have no idea how it's working for you as I'm still receiving the same build error for sqlx as I mentioned above. I tried the latest commit just in case, but the last two commits since the release tag are not related to the build process.

Are you using the latest nightly toolchain?

info: syncing channel updates for 'nightly-x86_64-unknown-linux-gnu'
info: latest update on 2023-02-08, rust version 1.69.0-nightly (bd39bbb4b 2023-02-07)

It really makes no sense to need both gtk3 and gtk4. It's one or the other. Since I cannot complete the build, I can't verify the final runtime dependencies.

Also, only one tray icon implementation should be chosen. Neither Ayatana nor Appindicator are required to build as far as I've noticed so far.

[rhysperry111]

Yeah I'm on the latest toolchain (cargo 1.69.0-nightly, rustup 1.25.2, rustc 1.69.0-nightly)

[hwittenborn]

On my system, it seemed that gtk4 was a run-time dep whereas gtk3 was only needed at compile time

I know the header files for both are needed at least to compile, though I don't know if arch splits development packages and normal packages like Debian/Ubuntu based distros do. The tray application (mentioned below) is embedded into the celeste binary, so you probably won't get any missing library errors from any linting tools, if that's how you're finding out. The tray application does use GTK3 library material though, so it shouldn't be able to run without it. If you can get it working without it though feel free to leave it out for now, it can always be added later if users complain or anything like that.

It really makes no sense to need both gtk3 and gtk4.

The main application is written in GTK4/Libadwaita, but GTK4 doesn't have appindicator support, so it's a separate application written in GTK3.

[hwittenborn]

Also:

it seemed that gtk4 was a run-time dep whereas gtk3 was only needed at compile time (which is the opposite of the makedeb package)

gtk4 is also a runtime dependency in the makedeb package, libadwaita-1-0 just also depends on gtk4 so it ends up installing it if it isn't already in the process.

I don't know what tools you guys are familiar with, but the way I found missing dependencies was to do a fresh build in a Docker container, and then as missing dependencies popped up I just searched for the missing files with apt-file. I think there exists a similar tool for Arch Linux to find what packages contain certain files, but I don't remember the name of it off the top of my head.

[yochananmarqos]

The main application is written in GTK4/Libadwaita, but GTK4 doesn't have appindicator support, so it's a separate application written in GTK3.

I see. Nicotine+ has a tray icon with GTK4. I can't remember what the implementation is called now, but I noticed they just removed some old GtkStatusIcon code yesterday.

As far as finding dependencies, I build in a clean chroot and use trial and error like you mentioned.

On Arch, one would use pacman -Fx <search term>; i.e.,

❯ pacman -Fx gdk-3.0
extra/gtk3 1:3.24.36-1 [installed]
    usr/lib/girepository-1.0/Gdk-3.0.typelib
    usr/lib/pkgconfig/gdk-3.0.pc
    usr/share/gir-1.0/Gdk-3.0.gir
extra/vala 0.56.3-1
    usr/share/vala-0.56/vapi/gdk-3.0.deps
    usr/share/vala-0.56/vapi/gdk-3.0.vapi
community/haskell-gi-gdk3 3.0.25-44
    usr/lib/libHSgi-gdk-3.0.25-3fIqjFN8DPPGmFJgc178N1-ghc9.0.2.so
multilib/lib32-gtk3 1:3.24.36-1 [installed]
    usr/lib32/pkgconfig/gdk-3.0.pc

[hwittenborn]

Nicotine++ has a tray icon with GTK4.

Wow, that's definitely something I'll look into. Currently the main application and the tray application communicate over a DBus connection, but it's been a pain to manage, so I'll see what I can find out from there a bit later.

[yochananmarqos]

You replied before I was finished editing my post. :stuck_out_tongue_closed_eyes: I'm done now.

I'm still a bit jet lagged from flying across the pond to FOSDEM and back this weekend. :zombie_man:

[hwittenborn]

Lol you're all good. Yeah, that looks like the right way to find the dependencies then, I guess it's just a matter of finding the right ones then.

I'm not quite sure what's up with your sqlx error - I don't have the latest version of rust installed from Rustup on my machine, but the CI always does and it's been doing fine the past few days. I'm about to publish a new release after I get an issue fixed, of which it'll run again though, so I'll be able to see if something's up then.

[yochananmarqos]

I was able to build 0.4.0 fine today. Turns out I needed to disable LTO, for one.

The dependencies appear to be:

depends=('cairo' 'gdk-pixbuf2' 'libadwaita' 'pango' 'rclone')
makedepends=('cargo-nightly' 'clang' 'go' 'gtk3' 'just')
optdepends=('libayatana-appindicator: option for tray icon'
            'libappindicator-gtk3: option for tray icon')

See my updated PKGBUILD.

I think we may be ready to add it to the AUR.

[rhysperry111]

I don't believe that gdk-pixbuf2, cairo, or pango need to be specified as deps, as they are already pulled in by libadwaita (pactree libadwaita).

Other than that, it seems a little bit more complicated than mine, but I'm sure you have your reasons :P

[yochananmarqos]

Ah, good point. Just libadwaita and rclone should be enough then.

I've added it to the AUR: celeste. If anyone wants to help maintain it, let me know your username and I'll add you as a Co-Maintainer.

[rhysperry111]

I wouldn't mind being added as a co-maintainer (same username here as I have everywhere). I won't be using it though until #9 comes through, as that's what I use for school.

[FabioLolix]

Hello people, celeste as package name already exist in some other repos and is a game

https://aur.archlinux.org/packages?O=0&SeB=n&K=celeste&outdated=&SB=p&SO=d&PP=50&submit=Go

https://repology.org/project/celeste/versions

Would you consider changing the package and bin to celeste-client or something else or no?

[yochananmarqos]

Well, celeste didn't already exist and the game may not be able to be built from source. If ever someone wants to claim celeste for the game, then we could change the package name at that time.

[FabioLolix]

While celeste for the game was not already used on the AUR having celeste and celeste-bin as 2 differents program will cause confusion

[yochananmarqos]

The package descriptions are different so it's obvious they are different things. This is not the first occurrence of projects with the same name in the AUR.

[hwittenborn]

I'd rather just take celeste for this project since it's available on the AUR. That's how the Snap and MPR packages already do it, so I don't see much of a problem with it.

[yochananmarqos]

@hwittenborn Well, that was my initial reasoning. Now that I look a little closer, I see that celeste-bin provides and conflicts with celeste. @FabioLolix has now added the binary release of this program as celeste-client-bin which unpacks the Snap. It also provides and conflicts with celeste. That will create an issue as folks will not be able to install the game and this program at the same time.

I could create celeste-client and submit a request to merge celeste into it. Then celeste-client-bin would no longer provide and conflict with celeste and the game and this program could be installed at the same time.

[hwittenborn]

That will create an issue as folks will not be able to install the game and this program at the same time.

It looks like they're always just going to conflict with each other - celeste-bin installs a file at /usr/bin/celeste, which this application also uses.

I could create celeste-client and submit a request to merge celeste into it.

Would that result in the final package being called celeste-client or celeste? I'd definitely prefer celeste but if you have to use something else, I'd probably go with celeste-sync just for the sake of clarity.

[yochananmarqos]

If I created celeste-client / celeste-sync, I could rename the binary to the same name as not to conflict with the game.

[hwittenborn]

That could work, the application probably wouldn't be launched from a CLI much anyway.

It looks like the AUR packages for the Celeste game aren't too popular yet though, so I think if we could use celeste that we should definitely take up the opportunity. There weren't really packages for the game on Repology either, and even those that are weren't using the celeste package name (they were under the namespace games-rpg/ for the Gentoo and LiGurOS packages, and everything else was just named differently).

[rhysperry111]

It might be worth just asking the people packaging the game if the could change the binary name. It's obviously up to them since they got the name first, but I feel like there shouldn't be too much of a problem, especially considering the potential for this program in the future.

[hwittenborn]

What's the status of this? I'd love to add instructions to the README for installing Celeste from the AUR if y'all would be down with it.

[yochananmarqos]

You said you were fine with the package being called celeste, so I haven't done anything.

[PrzemekSkw]

Great @rhysperry111 . Thank You very much. I'm very grateful and wish I could help but I don't know much about packing in AUR.

[hwittenborn]

Is there anything that still needs to be done @yochananmarqos, at least for the source package?

[yochananmarqos]

Nope. I think we're fine for now. @FabioLolix took it upon himself to add the binary package as celeste-client-bin, so that might be confusing. Reason being celeste-bin already exists for the game. :man_shrugging:

[hwittenborn]

That's fine for the binary package for now, it's not too big of a deal. At least for celeste do you think it's at a good state to add installation instructions to the README for it?

[yochananmarqos]

Well, Scott @ OMG!LINUX already posted about it, so you might as well update the README to let users know it's in the AUR.

[PrzemekSkw]

Sorry I don't mention You all who make thisAUR package. Thank You very much.

[PrzemekSkw]

I just build from AUR but have the sam issue as from flatpak. Cannot add remote folder.

[yochananmarqos]

@PrzemekSkw Please create a new issue if you need support.

[PrzemekSkw]

@PrzemekSkw Please create a new issue if you need support.

Hi, I already have the same issue with flatpak: https://github.com/hwittenborn/celeste/issues/24

[hwittenborn]

@yochananmarqos: I don't recall where we left off, but was there anything inhibiting adding the celeste AUR package as an installation option in the README?

[yochananmarqos]

@hwittenborn No, I think we're good.

[hwittenborn]

Cool, I'll get that added in a bit then - I'd like to add a note that it's community maintained by you just so everyone knows it's not maintained directly by me, is that fine with you?