Project

General

Profile

機能 #1248

Flatpakレポジトリで配布する

Added by Yuto Tokunaga over 1 year ago. Updated 4 months ago.

Status:
新規
Priority:
通常
Assignee:
Target version:
Start date:
2018-05-18
Due date:
% Done:

0%

プラグイン名:

Description

mikutterをFlatpak 形式にビルドし,flatpakレポジトリで配布できるようにする.


Related issues

Related to 機能 #1189: XDG Base Directory Specification に従って、Environment定数で設定するディレクトリの位置を変える新規2018-03-08

Actions

History

#1

Updated by Yuto Tokunaga about 1 year ago

https://github.com/yuntan/flathub/tree/mikutter で作業してます.ビルド方法はREADMEに書いたので試したい方はどうぞ.PREREQUISITEのバージョンを上げたりする手順は不要です.

3.6.0をビルドする設定になってますがあとで3.7.1に上げます.

#2

Updated by Yuto Tokunaga about 1 year ago

3.7.1に更新しました.

#3

Updated by Yuto Tokunaga about 1 year ago

FlatpakアプリはXDG Base Directory Specificationに従うのが原則となっているので( http://docs.flatpak.org/en/latest/conventions.html#xdg-base-directories ), #1189 に関して改めて検討するのが良いかもしれないことを注記しておきます.

#4

Updated by toshi_a 初音 about 1 year ago

  • Related to 機能 #1189: XDG Base Directory Specification に従って、Environment定数で設定するディレクトリの位置を変える added
#5

Updated by toshi_a 初音 about 1 year ago

なるほど、 #1189 に着手する動機は増えましたね。

#6

Updated by Yuto Tokunaga about 1 year ago

TODOです

  • 適切なスクリーンショットを用意する
    Flatpakアプリをストア(Gnome Store, KDE Discover等)で公開するときにスクリーンショットがある方が見栄えが良いです.スクリーンショットは縦横比16:9,幅が620px以上である必要があります.日本語版と英語版の両方用意するのが望ましいです.スクリーンショットはWeb上にHTTP(S)で公開されている必要があります.
  • 適切な紹介文を用意する (日・英) #1251
  • 適切な説明を用意する (日・英)
    debian packageでは以下のように説明されていますが, #1251 に挙げた理由で修正する必要があります.
Mikutter is a multi-pane Twitter client with several advanced features:
  • different tweet views (flat list, threaded list, searches);
  • user profile and activity views;
  • lists of followers and followings (friends);
  • plugin extensibility.
  • appdata.xmlファイルのメンテナとメールアドレスは僕ので問題ないでしょうか
  • appdata.xmlファイルのライセンスはMITでよろしいでしょうか
#7

Updated by Yuto Tokunaga about 1 year ago

aplayコマンドが利用できず通知音が鳴らせない不具合があります.

#8

Updated by toshi_a 初音 about 1 year ago

appdata.xmlファイルのメンテナとメールアドレスは僕ので問題ないでしょうか
appdata.xmlファイルのライセンスはMITでよろしいでしょうか

再配布は、それぞれの裁量と責任で行ってもらってるので、それでお願いします。ライセンスはREADMEのとおりです

aplayコマンドが利用できず通知音が鳴らせない不具合があります.

WindowsやMacなど、aplayがない環境では、その環境でサウンドを再生できるプラグインがバンドルされているようなので、同じように対処すると良いと思います。例えば、pulseaudioなら行けるというのならサードパーティープラグインがあるので、サウンドサーバを教えてもらえば、あるかないかくらいは教えることができます

#9

Updated by Yuto Tokunaga about 1 year ago

再配布は、それぞれの裁量と責任で行ってもらってるので、それでお願いします。ライセンスはREADMEのとおりです

OKです.

例えば、pulseaudioなら行けるというのならサードパーティープラグインがあるので

pulseaudioプラグイン(pacmdコマンド)を試してみましたが,再生できませんでした.flatpakの不具合だと思うのでそちらに報告します.

#10

Updated by Yuto Tokunaga 12 months ago

TL; DR

  • jemalloc 3.6.0でメモリ消費量を60%程度に抑えられます.
  • flatpakではjemalloc 3.6.0を採用します.

rubyのmallocをjemallocに置き換える(rubyのビルド時に--with-jemallocを指定する)ことでメモリ消費量が抑えられるという情報があります.

mikutterでjemallocを利用したときのメモリ消費量を調べました.jemalloc 3.6.0 と jemalloc 5.1.0について調べました.

検証環境

  • Arch Linux
  • ruby 2.5.1
  • mikutter 3.7.1
  • worldon fc04159

検証方法

3つのmikutterインスタンスで設定内容を合わせ同時に起動する.その後worldonでHTLとFTLを受信し10時間放置した.psコマンドを10秒間隔でポーリングし物理メモリ使用量(RSS)を記録した.

結果


jemalloc 3.6.0では起動してから10時間後のメモリ消費量がglibc mallocの60%程度に抑えられています.jemalloc 5.1.0ではメモリ消費量を削減することはできていません.

以上の結果を踏まえ,flatpakではjemalloc 3.6.0を採用します.

#11

Updated by Yuto Tokunaga 12 months ago

上記の結果について,jemalloc 5.1.0で計測したと思っていたものが実は正しくビルド出来ておらずglibc mallocが用いられていたことが後で分かったため,計測し直しました.検証方法は同じで今度は20時間放置しました.結果が以下になります.

jemalloc 3.6.0, 5.1.0のどちらでもメモリ消費量はほぼ変わらないという結果になりました.どちらのバージョンを用いてもメモリ消費量を60-70%に抑えられます.

#12

Updated by Yuto Tokunaga 4 months ago

大分期間が空いてしまいましたが進捗です.

aplayコマンドが利用できず通知音が鳴らせない不具合があります.

paplayコマンド(pulseaudio)は利用できたので,paplayコマンドを使うためのプラグインを書いて( https://github.com/yuntan/mikutter-pulseaudio )flatpakにバンドルすることで対応しました.( https://github.com/yuntan/flathub/commit/4c69b6681acf7498384c259d34e25d1d95a50106

#13

Updated by Yuto Tokunaga 4 months ago

flatpakのメンテナの方から,「appdata.xmlファイルはupstreamに含めたほうが良い」というコメントをもらいました.

It should be maintained in upstream repo so other distributions can use it too.

https://github.com/flathub/flathub/pull/587#discussion_r213222878

appstream.xmlというのは,アプリの説明やスクリーンショットの情報を書いておくファイルのことです.Ubuntu等のディストリビューションがストアでアプリを表示する際に使われるようです.

AppStream allows upstream projects to define metadata about the components they provide using small XML files, metainfo files, which get installed into locations on the client system and are used by distribuors to enhance their metadata.

https://www.freedesktop.org/software/appstream/docs/chap-Metadata.html

有名所のプロジェクトだと,VLC,VS Code,neovim等はappdata.xmlをupstreamリポジトリで管理しているようです.

現時点では以下の内容のファイルを用意しています.
https://github.com/yuntan/flathub/blob/d90218dedc33f63c25aa1e4f6ef7972ac3ab1087/net.hachune.mikutter.appdata.xml

appdata.xmlをupstreamに含める際に,appdata.xmlに含まれる更新情報を誰が更新するのかが問題となると思います.appdata.xmlはflatpakのリポジトリで管理したほうが良いでしょうか?

#14

Updated by toshi_a 初音 4 months ago

appdata.xmlはflatpakのリポジトリで管理したほうが良いでしょうか?

mikutterのメインリポジトリに入れてしまうとお互い更新の負担が増えると思うので、upstreamに入れる必要があるならforkしたリポジトリに入れてもらうほうが良いと思います。

#15

Updated by Yuto Tokunaga 4 months ago

mikutterのメインリポジトリに入れてしまうとお互い更新の負担が増えると思うので、upstreamに入れる必要があるならforkしたリポジトリに入れてもらうほうが良いと思います。

了解です.ひとまずflatpakのレポジトリで管理することにします.

Also available in: Atom PDF