search

astroidmail / astroid

A graphical threads-with-tags style, lightweight and fast, e-mail client for Notmuch
http://astroidmail.github.io
Other
613 stars 65 forks source link

Get astroid as binary in distributions' repositories #410

Open mxmehl opened 7 years ago

mxmehl commented 7 years ago

Recently there were some changes in astroid which forced people to rebuild astroid and especially large dependencies like webkitgtk that take ages to compile. While this may be acceptable for developers and hardcore fans it will chase away "normal" users.

What would be necessary in order to get astroid as binaries in GNU/Linux distributions' repositories, e.g. Arch Linux, Debian or Fedora. Code changes? Package maintainers? Votes on the AUR package?

Is it even desired to get astroid there?

gauteh commented 7 years ago

Max writes on september 25, 2017 16:37:

Recently there were some changes in astroid which forced people to rebuild astroid and especially large dependencies like webkitgtk that take ages to compile. While this may be acceptable for developers and hardcore fans it will chase away "normal" users.

What would be necessary in order to get astroid as binaries in GNU/Linux distributions' repositories, e.g. Arch Linux, Debian or Fedora. Code changes? Package maintainers? Votes on the AUR package?

Is it even desired to get astroid there?

Definetely! I believe a Debian package is already underway (https://github.com/astroidmail/astroid/issues/388#issuecomment-325208491).

I think the dealbreaker is webkitgtk, unless we move to webkit2 we will not have binaries for that in any distros (understandably, since it is full of bugs and CVEs). Thanks to @ramblurr we're making progress towards webkit2, and a working implementation should not be too far away (#42, #408).

Ramblurr commented 7 years ago

Webkit1 is a dealbreaker for most distros. Migrating to webkit2 is therefore required.

Containerized packages (snaps or flatpaks) are the future, so IMHO its worth putting packaging efforts towards flatpak or snaps instead of distro specific packages.

The fact that this packages offer isolation security is a huge plus, since, of course, there is the lingering concern of security issues in a program that parses and displays emails.

I tend to lean towards flakpak myself, so I've also started work on a flatpak package that mostly works, but I'm not releasing it publicly until the webkit2 port is finished, because webkit1 takes ages to compile (and is insecure).

That said if anyone wants to work on a distro package, definitely wait for the webkit2 migration as @gauteh said.

mxmehl commented 7 years ago

Then I'm very much looking forward to the webkit2 version! Thanks for your work on that!

Containerized packages (snaps or flatpaks) are the future, so IMHO its worth putting packaging efforts towards flatpak or snaps instead of distro specific packages.

No dev here but I guess usual packages will persist for a whole while. Especially if we want to make astroid installation easy for most users, repo packages are still the way to go. Honestly I've never installed a flatpack or snap package and I'm not the most newbie Linux users...

Ramblurr commented 7 years ago

No dev here but I guess usual packages will persist for a whole while.

Fair enough, I concede having distro packages would be good for the astroid as a whole.

(And you're right, most users don't know about these formats yet. But know you know about it! Maybe astroid will be your first flatpak 😉 )

hugoroy commented 7 years ago

Looking forward to that :-D

Good luck with the webkit2 port!

jonassmedegaard commented 7 years ago

Yes, I can confirm that Astroid is being packaged for Debian (by me) and from there will trickle down to its derivatives like Ubuntu.

hugoroy commented 7 years ago

Thanks a lot for this, Jonas! Good luck :)

Ramblurr commented 7 years ago

gmime 3 dep status:

gauteh commented 7 years ago

will support both gmimes for at least a little bit, but it is cumbersome to test on both. tried to set up travis earlier (most gmime stuff would be caught at compile time), but deps were too far behind on the ubuntu vm. might have changed now.

gauteh commented 7 years ago

Jonas Smedegaard writes on september 28, 2017 21:54:

Yes, I can confirm that Astroid is being packaged for Debian (by me) and from there will trickle down to its derivatives like Ubuntu.

@jonassmedegaard: is mesonbuild and ninja available on Debian? (#412).

jonassmedegaard commented 7 years ago

Yes, the Debian package "meson" contains mesonbuild and pulls in ninja-build, so both should be usable on Debian and its derivatives with a simple "sudo apt install meson".

This apparently has been the case for quite some time: https://packages.debian.org/meson

teto commented 7 years ago

I was looking into bumping the astroid package for nixos too but the webkit dependancy is not cached because of the CVEs and thus take one day to compile here. So here are a few questions:

teto commented 7 years ago

As for debian, isn't having a manpage mandatory ?

gauteh commented 7 years ago

Matthieu Coudron writes on oktober 9, 2017 7:53:

I was looking into bumping the astroid package for nixos too but the webkit dependancy is not cached because of the CVEs and thus take one day to compile here. So here are a few questions:

  • is meson ready for compiling ? should we move the package compilation from scons to meson ?

Yes.

  • webkitgtk3 is listed as a dependancy . I haven't looked too deep but webkitgtk 2.28 seems to be the latest dep. What does webgitgtk3 refer to ?

WebKit is a mess. I am guessing that webkit1 might be gone, webkit2 (which sometimes is listed as webkit2gtk-4.0) work is under way (#408), but not yet ready. Version explanation here: https://stackoverflow.com/questions/19692818/webkitgtk-gtk2-gtk3

mjg commented 6 years ago

Just for the record: On Fedora 27 (no webkit), the webkit2 branch doesn't build, even after installing all dependencies and using LANG=C to work around some meson bug. Meson is unhappy:

The Meson build system
Version: 0.43.0
Source dir: /home/mjg/src/astroid
Build dir: /home/mjg/src/astroid/build
Build type: native build
Project name: astroid
Native C compiler: ccache cc (gcc 7.2.1)
Native C++ compiler: ccache c++ (gcc 7.2.1)
Build machine cpu family: x86_64
Build machine cpu: x86_64
Found pkg-config: /usr/bin/pkg-config (1.3.12)
Native dependency gmime-3.0 found: YES 3.0.5
Native dependency gmime-2.6 found: YES 2.6.23
Dependency Boost (thread, filesystem, log_setup, log, date_time, system) found: YES 1.64
Library boost_program_options found: YES
Native dependency gtk+-3.0 found: YES 3.22.26
Native dependency gtkmm-3.0 found: YES 3.22.2
Native dependency webkit2gtk-4.0 found: YES 2.18.4
Dependency threads found: YES
Library notmuch found: YES
Checking for function "notmuch_database_index_file": NO
Message: gmime version matches between astroid and notmuch: YES
Dependency vte-2.91 found: NO
Message: Embedded terminal is disabled.
Native dependency libsass found: YES 3.4.5
Has header "sass_context.h": NO
Has header "sass/context.h": YES
Configuring build_config.hh using configuration
Message: Building astroid: v0.10.2-72-g9c5fa4b6
Native dependency libpeas-1.0 found: YES 1.22.0
Program g-ir-scanner found: YES (/usr/bin/g-ir-scanner)
Program g-ir-compiler found: YES (/usr/bin/g-ir-compiler)
Native dependency gobject-introspection-1.0 found: YES 1.54.1

Meson encountered an error in file meson.build, line 206, column 0:
File ui/thread-view/dist/index.html does not exist.
mxmehl commented 6 years ago

File ui/thread-view/dist/index.html does not exist.

Same here on latest Arch. It seems the file paths are a little bit different and I wasn't able to figure out how it should be changed

gauteh commented 6 years ago

Yeah, the WebKit2 branch isn’t working yet. You would have to use yarn on the thread view UI. Also, cmake build hasn’t been ported yet.

tir. 2. jan. 2018 kl. 01:03 skrev Max notifications@github.com:

File ui/thread-view/dist/index.html does not exist.

Same here on latest Arch. It seems the file paths are a little bit different and I wasn't able to figure out how it should be changed

— You are receiving this because you were mentioned.

Reply to this email directly, view it on GitHub https://github.com/astroidmail/astroid/issues/410#issuecomment-354686454, or mute the thread https://github.com/notifications/unsubscribe-auth/AADd-2LTO8jMfza7nlSUsMwW0hwym-xHks5tGXJogaJpZM4Pi1jR .

gauteh commented 6 years ago

Hi, with the 0.13 release we have now moved to WebKit2 and there should be no deprecated dependencies anymore. Packaging and getting packages accepted should be easier now!

mxmehl commented 6 years ago

Cool! So for Arch the AUR already is simple to install. Debian and Fedora would be the next major platforms :)

hugoroy commented 6 years ago

Awesomeness in a nutshell :-)

Le 20 juillet 2018 11:16:28 GMT+02:00, Max notifications@github.com a écrit :

Cool! So for Arch the AUR already is simple to install. Debian and Fedora would be the next major platforms :)

-- Envoyé de mon appareil mobile Sent from my mobile device

Fnux commented 6 years ago

There is an ongoing review request for Fedora: https://bugzilla.redhat.com/show_bug.cgi?id=1438659

gauteh commented 6 years ago

Some hints for packagers here: #540

teto commented 6 years ago

btw astroid 0.13 got into nixos recently.

jonassmedegaard commented 6 years ago

After mysteriously falling out of Debian completely for some time, without any logs or indications why, it has now re-entered and should arrive in the "unstable" branch 5 hours from now, and (given no surprises) should enter "testing" in 10 days.

Status of its health in Debian: https://tracker.debian.org/pkg/astroidmail

hugoroy commented 6 years ago

Awesome, thanks Jonas!

gauteh commented 6 years ago

Thanks to @Fnux we now have a man page!

davvil commented 6 years ago

I took a go at creating a flatpak package and I got it running on an ubuntu 16.04 system (managed computer, not able to update). You can find it here. Note that this is my first flatpak package ever and there was a lot of guesswork involved, so probably it can be improved.

As astroid needs to call external tools (editor, mail sending, polling...) I included an additional script that allows to execute commands outside the container. You should download it from here before starting the flatpak build.

If there is interest in including this, I can create a PR and iterate on it.

gauteh commented 6 years ago

Absolutely, I think we should maintain it in a separate repo in the astroidmail org. I have no experience with flatpak's so if others have views please contribute!

On Fri, Nov 2, 2018 at 10:00 AM David Vilar notifications@github.com wrote:

I took a go at creating a flatpak package and I got it running on an ubuntu 16.04 system (managed computer, not able to update). You can find it here https://pastebin.com/JffUvsMD. Note that this is my first flatpak package ever and there was a lot of guesswork involved, so probably it can be improved.

As astroid needs to call external tools (editor, mail sending, polling...) I included an additional script that allows to execute commands outside the container. You should download it from here https://pastebin.com/hhvwFqkt before starting the flatpak build.

If there is interest in including this, I can create a PR and iterate on it.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/astroidmail/astroid/issues/410#issuecomment-435313711, or mute the thread https://github.com/notifications/unsubscribe-auth/AADd-xrikuIvYgaGzEdoNDfBIpKUTtSIks5urAmrgaJpZM4Pi1jR .

davvil commented 6 years ago

Feel free to create an (empty?) repo for packaging and I can send a PR for it.

I have been using the packaged version for a couple of days, and it seems to work mostly fine, with a couple of rough edges:

gauteh commented 6 years ago

David Vilar writes on November 5, 2018 14:14:

  • Because of the previous point, we could consider including more "utilities" in the package to ease usage. I see an argument for including sendmail, msmtp, offlineimap... But on the other hand this goes a bit against the modular approach of astroid.

Doesn't flatpak have a way to handle dependencies? I'd probably skip sendmail and only include msmtp by the way.

davvil commented 6 years ago

Flatpak packages include their dependencies, as defined in the package file. The difference here is that external programs are not dependencies, strictly speaking. msmtp is close to being one and I see the point of including it, but we will not include all possible editors in the package.

The issue here is that due to encapsulation it is not trivial to invoke binaries outside of the flatpak package e.g an editor installed in the base distribution. Starting them is easy enough, but I still don't have a good solution for detecting when they finish (although I have a workaround for that) or getting the exit status.

davvil commented 6 years ago

Ha! It turns out flatpak already provides a tool for executing external commands just the way we want (I hope this was better documented). So problems 2 and 3 of my previous post just disappear. The only thing needed is to prepend the commands with flatpak-spawn --host, e.g. in the config edit.command = "flatpak-spawn --host urxvt -e nvim %1.

gauteh commented 5 years ago

You should have admin access to flatpak-astroid repo

davvil commented 5 years ago

I just uploaded the manifest for building a v0.14 package. I have been using astroid in a flatpak package for ~2 weeks now and it seems to work reliably. Ideally someone else tries the package for having some additional testing and the we can apply for inclusion in flathub.

maitra commented 5 years ago

I have built on Fedora 30 and it works fine. I have asled for the review-request to be transferred to me since the original packager is no longer interested. I am myself new to astroid, however, and not having a sidepane view of folders is bothersome.