Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Linux用実行バイナリの動作検証 #106

Closed
aoirint opened this issue Sep 19, 2021 · 11 comments
Closed

Linux用実行バイナリの動作検証 #106

aoirint opened this issue Sep 19, 2021 · 11 comments

Comments

@aoirint
Copy link
Member

aoirint commented Sep 19, 2021 •
edited
Loading

ref: #96
ref: #95

VOICEVOX ENGINEのLinux用実行バイナリを試した方がおられましたら、動作環境を返信で教えてくださるとうれしいです！

Linux用実行バイナリは、 masterブランチにコミットが追加されたときに自動実行されるWorkflowの実行結果（Summary）から、zipファイルとしてダウンロードすることができます。

展開すると、実行バイナリ run を含むファイル群を取り出せます。
zip内にディレクトリがないため、カレントディレクトリに直接中身が展開されるおそれがあるので注意してください（あらかじめディレクトリを作ってから、unzip -d dest/ file.zip）。

GitHub Artifactの仕様（zipの仕様）により、run ファイルに実行権限が付与されていないため、手動でchmod +x runする必要があります（ actions/upload-artifact#38 ）。

想定動作環境における、ある程度の調査ができた段階で、このIssueはいったんCloseし、個別のIssueを立てる形に移行するのがいいかな、と思っています。

想定している動作環境

想定環境以外で動作した・動作しなかったときも、（動かした・動かそうとした方法を含めて）ぜひ教えてください！

詳細な動作環境

以下は、 #116 以前の動作環境になります。#116 以降については、未調査です。

  • glibc >= 2.29
    • Ubuntu/Debian: /lib/x86_64-linux-gnu/libc.so.6 を実行
    • Fedora: /lib64/libc.so.6 を実行
  • libstdc++ GLIBCXX_3.4.26
    • Ubuntu/Debian: apt update && apt install binutils、strings /usr/lib/x86_64-linux-gnu/libstdc++.so.6 | grep GLIBCXX_ を実行
    • Fedora: yum install binutils、strings /lib64/libstdc++.so.6 | grep GLIBCXX_ を実行

知りたいこと

  • 使用した実行バイナリのバージョン（コミットハッシュ、WorkflowのURL）
  • CPUの種類
    • amd64/x86_64
  • OS
    • ネイティブ（PCに直接インストール）
      • OSの種類・バージョン
        • cat /etc/os-release
    • WSL
      • （Windowsのバージョン）
      • WSL側のOSの種類・バージョン
        • cat /etc/os-release
    • WSL2
      • （Windowsのバージョン）
      • WSL2側のOSの種類・バージョン
        • cat /etc/os-release
    • Docker
      • ホスト側OSの種類・バージョン
        • cat /etc/os-release
        • （Windows/macOSのバージョン・Docker Desktopのバージョン）
      • イメージ名・タグ名（イメージのダイジェスト）
      • 自作イメージの場合
        • ベースイメージ名
        • Dockerfile
  • glibcのバージョン
    • Ubuntu/Debian: /lib/x86_64-linux-gnu/libc.so.6 を実行
    • Fedora: /lib64/libc.so.6 を実行
  • libstdc++
    • バージョン
      • Ubuntu/Debian: apt list --installed libstdc++* を実行
      • Fedora: rpm -q libstdc++ を実行
    • GLIBCXX_ 対応バージョン
      • Ubuntu/Debian: apt update && apt install binutils、strings /usr/lib/x86_64-linux-gnu/libstdc++.so.6 | grep GLIBCXX_ を実行
      • Fedora: yum install binutils、strings /lib64/libstdc++.so.6 | grep GLIBCXX_ を実行
  • 音声合成に使用したプロセッサの種類（CPUか、GPUか＝--use_gpu）
    • CPU
    • NVIDIA GPU
      • NVIDIA Driverのバージョン（e.g. 470.57.02）
      • CUDAのバージョン（e.g. 11.4.1）
  • 実行コマンド（実行までの流れ）
  • 実際に音声合成はできたか?
    • エラーが起きていないか?
    • mockが使われていないか?

動かし方

libsndfile（VOICEVOX ENGINEのAPIが返す、wavファイルの作成に使用）をインストール。

# Ubuntu 20.04, Debian 11
apt update
apt install libsndfile1

# Fedora 34
yum install libsndfile

CUDA/cuDNNをインストール（GPU実行の場合）。

実行バイナリをGithub ActionsのSummaryからダウンロード、展開、実行。

chmod +x ./run

# ネイティブ環境の場合
./run

# Dockerコンテナの場合（-p '127.0.0.1:50021:50021'）
./run --host 0.0.0.0

既知の問題

libcore側のwarning表示

[W BinaryOps.cpp:467] Warning: floor_divide is deprecated, and will be removed in a future version of pytorch. It currently rounds toward 0 (like the 'trunc' function NOT 'floor'). This results in incorrect rounding for negative values.
To keep the current behavior, use torch.div(a, b, rounding_mode='trunc'), or for actual floor division, use torch.div(a, b, rounding_mode='floor'). (function operator())
@aoirint aoirint mentioned this issue Sep 19, 2021
Merged
20 tasks
@aoirint aoirint changed the title Ubuntu 20.04、Debian 11、Fedora 34でのLinux用実行バイナリの動作検証 Ubuntu 20.04、Debian 11、Fedora 34でのLinux用実行バイナリの動作報告募集 Sep 19, 2021
@aoirint aoirint changed the title Ubuntu 20.04、Debian 11、Fedora 34でのLinux用実行バイナリの動作報告募集 Ubuntu 20.04、Debian 11、Fedora 34でのLinux用実行バイナリの動作検証 Sep 19, 2021
@Hiroshiba Hiroshiba added the 要議論 実行する前に議論が必要そうなもの label Sep 19, 2021
@aoirint aoirint mentioned this issue Sep 19, 2021
Closed
@YTJVDCM
Copy link

YTJVDCM commented Sep 24, 2021

想定環境ではありませんが、以下環境にて、おそらくSSL証明書周りが原因と思われるエラーで動きませんでした。

  • CPU

    • amd64 (Ryzen 2400G)

  • OS

    • Arch Linux x86_64
      (ローリングリリースモデルのOSのためバージョンなし)

  • glibcバージョン

    • 2.33

  • libstdc++

    • バージョン
      • 3.3.5-7
    • GLIBCXX_ 対応バージョン
コマンド実行結果 
strings /lib64/libstdc++.so.6 | grep GLIBCXX_
GLIBCXX_3.4
GLIBCXX_3.4.1
GLIBCXX_3.4.2
GLIBCXX_3.4.3
GLIBCXX_3.4.4
GLIBCXX_3.4.5
GLIBCXX_3.4.6
GLIBCXX_3.4.7
GLIBCXX_3.4.8
GLIBCXX_3.4.9
GLIBCXX_3.4.10
GLIBCXX_3.4.11
GLIBCXX_3.4.12
GLIBCXX_3.4.13
GLIBCXX_3.4.14
GLIBCXX_3.4.15
GLIBCXX_3.4.16
GLIBCXX_3.4.17
GLIBCXX_3.4.18
GLIBCXX_3.4.19
GLIBCXX_3.4.20
GLIBCXX_3.4.21
GLIBCXX_3.4.22
GLIBCXX_3.4.23
GLIBCXX_3.4.24
GLIBCXX_3.4.25
GLIBCXX_3.4.26
GLIBCXX_3.4.27
GLIBCXX_3.4.28
GLIBCXX_3.4.29
GLIBCXX_DEBUG_MESSAGE_LENGTH
_ZNKSt14basic_ifstreamIcSt11char_traitsIcEE7is_openEv@GLIBCXX_3.4
_ZNSt13basic_istreamIwSt11char_traitsIwEE6ignoreEv@@GLIBCXX_3.4.5
_ZNKSbIwSt11char_traitsIwESaIwEE11_M_disjunctEPKw@GLIBCXX_3.4
_ZNKSt14basic_ifstreamIwSt11char_traitsIwEE7is_openEv@@GLIBCXX_3.4.5
GLIBCXX_3.4.21
GLIBCXX_3.4.9
_ZSt10adopt_lock@@GLIBCXX_3.4.11
GLIBCXX_3.4.10
GLIBCXX_3.4.16
GLIBCXX_3.4.1
_ZNSt19istreambuf_iteratorIcSt11char_traitsIcEEppEv@GLIBCXX_3.4
GLIBCXX_3.4.28
_ZNSs7_M_copyEPcPKcm@GLIBCXX_3.4
GLIBCXX_3.4.25
_ZNSt19istreambuf_iteratorIcSt11char_traitsIcEEppEv@@GLIBCXX_3.4.5
_ZNSs7_M_moveEPcPKcm@@GLIBCXX_3.4.5
_ZNKSt13basic_fstreamIwSt11char_traitsIwEE7is_openEv@GLIBCXX_3.4
_ZNKSt13basic_fstreamIcSt11char_traitsIcEE7is_openEv@GLIBCXX_3.4
_ZNSbIwSt11char_traitsIwESaIwEE4_Rep26_M_set_length_and_sharableEm@@GLIBCXX_3.4.5
_ZNSs4_Rep26_M_set_length_and_sharableEm@GLIBCXX_3.4
_ZSt10defer_lock@@GLIBCXX_3.4.11
_ZN10__gnu_norm15_List_node_base4swapERS0_S1_@@GLIBCXX_3.4
_ZNSs9_M_assignEPcmc@@GLIBCXX_3.4.5
_ZNKSbIwSt11char_traitsIwESaIwEE15_M_check_lengthEmmPKc@@GLIBCXX_3.4.5
_ZNKSt14basic_ifstreamIcSt11char_traitsIcEE7is_openEv@@GLIBCXX_3.4.5
_ZNSbIwSt11char_traitsIwESaIwEE7_M_moveEPwPKwm@GLIBCXX_3.4
GLIBCXX_3.4.24
_ZNVSt9__atomic011atomic_flag12test_and_setESt12memory_order@@GLIBCXX_3.4.11
GLIBCXX_3.4.20
_ZNSt11char_traitsIwE2eqERKwS2_@@GLIBCXX_3.4.5
GLIBCXX_3.4.12
_ZNSi6ignoreEv@@GLIBCXX_3.4.5
GLIBCXX_3.4.2
_ZNSt11char_traitsIcE2eqERKcS2_@@GLIBCXX_3.4.5
GLIBCXX_3.4.6
GLIBCXX_3.4.15
_ZNKSt13basic_fstreamIcSt11char_traitsIcEE7is_openEv@@GLIBCXX_3.4.5
_ZNSs9_M_assignEPcmc@GLIBCXX_3.4
GLIBCXX_3.4.19
_ZNKSt14basic_ofstreamIwSt11char_traitsIwEE7is_openEv@GLIBCXX_3.4
_ZNSt19istreambuf_iteratorIwSt11char_traitsIwEEppEv@GLIBCXX_3.4
GLIBCXX_3.4.27
_ZN10__gnu_norm15_List_node_base7reverseEv@@GLIBCXX_3.4
_ZN10__gnu_norm15_List_node_base4hookEPS0_@@GLIBCXX_3.4
_ZNSt11char_traitsIwE2eqERKwS2_@GLIBCXX_3.4
_ZNSbIwSt11char_traitsIwESaIwEE7_M_copyEPwPKwm@GLIBCXX_3.4
_ZNSbIwSt11char_traitsIwESaIwEE7_M_copyEPwPKwm@@GLIBCXX_3.4.5
GLIBCXX_3.4.23
GLIBCXX_3.4.3
GLIBCXX_3.4.7
_ZNSi6ignoreEl@@GLIBCXX_3.4.5
_ZNKSbIwSt11char_traitsIwESaIwEE11_M_disjunctEPKw@@GLIBCXX_3.4.5
_ZNSt13basic_istreamIwSt11char_traitsIwEE6ignoreEv@GLIBCXX_3.4
_ZNKSt13basic_fstreamIwSt11char_traitsIwEE7is_openEv@@GLIBCXX_3.4.5
_ZNSbIwSt11char_traitsIwESaIwEE7_M_moveEPwPKwm@@GLIBCXX_3.4.5
GLIBCXX_3.4.18
_ZNSbIwSt11char_traitsIwESaIwEE4_Rep26_M_set_length_and_sharableEm@GLIBCXX_3.4
_ZNSt13basic_istreamIwSt11char_traitsIwEE6ignoreEl@@GLIBCXX_3.4.5
_ZSt15future_category@@GLIBCXX_3.4.14
_ZNSi6ignoreEl@GLIBCXX_3.4
GLIBCXX_3.4.29
_ZNSt11char_traitsIcE2eqERKcS2_@GLIBCXX_3.4
_ZNKSs15_M_check_lengthEmmPKc@GLIBCXX_3.4
_ZN10__gnu_norm15_List_node_base8transferEPS0_S1_@@GLIBCXX_3.4
_ZNSbIwSt11char_traitsIwESaIwEE9_M_assignEPwmw@GLIBCXX_3.4
_ZNVSt9__atomic011atomic_flag5clearESt12memory_order@@GLIBCXX_3.4.11
_ZNKSt14basic_ofstreamIcSt11char_traitsIcEE7is_openEv@@GLIBCXX_3.4.5
_ZNKSt14basic_ofstreamIcSt11char_traitsIcEE7is_openEv@GLIBCXX_3.4
_ZNSs7_M_moveEPcPKcm@GLIBCXX_3.4
_ZNSt13basic_istreamIwSt11char_traitsIwEE6ignoreEl@GLIBCXX_3.4
_ZNSbIwSt11char_traitsIwESaIwEE9_M_assignEPwmw@@GLIBCXX_3.4.5
_ZNKSbIwSt11char_traitsIwESaIwEE15_M_check_lengthEmmPKc@GLIBCXX_3.4
_ZNKSs11_M_disjunctEPKc@@GLIBCXX_3.4.5
_ZN10__gnu_norm15_List_node_base6unhookEv@@GLIBCXX_3.4
GLIBCXX_3.4.22
_ZNSt19istreambuf_iteratorIwSt11char_traitsIwEEppEv@@GLIBCXX_3.4.5
_ZNSi6ignoreEv@GLIBCXX_3.4
_ZNSs7_M_copyEPcPKcm@@GLIBCXX_3.4.5
GLIBCXX_3.4.8
GLIBCXX_3.4.13
_ZSt11try_to_lock@@GLIBCXX_3.4.11
_ZNKSt14basic_ofstreamIwSt11char_traitsIwEE7is_openEv@@GLIBCXX_3.4.5
GLIBCXX_3.4.17
GLIBCXX_3.4.4
_ZNKSs15_M_check_lengthEmmPKc@@GLIBCXX_3.4.5
_ZNKSt14basic_ifstreamIwSt11char_traitsIwEE7is_openEv@GLIBCXX_3.4
_ZNSs4_Rep26_M_set_length_and_sharableEm@@GLIBCXX_3.4.5
GLIBCXX_3.4.26

  • 音声合成に使ったプロセッサ

    • CPU
    • NVIDIA GPU(GTX 1070)
      • CUDAバージョン
        • 11.4.2-1
      • nvidiaバージョン
        • 470.74-1

  • 実行コマンド

バイナリ側

$ ./run

リクエスト側

$ text=`ruby -e "require('uri')" -e "puts URI.encode_www_form_component('Linux上でのバイナリ動作テスト')"`
$ curl -s \
    -X POST \
    "localhost:50021/audio_query?text=$text&speaker=1"\
    > query.json

curl -s \
    -H "Content-Type: application/json" \
    -X POST \
    -d @query.json \
    localhost:50021/synthesis?speaker=1 \
    > audio.wav
  • 実行結果

以下エラーで正常動作せず
(おそらく証明書関連のエラー?)

CPU

$ ./run
INFO:     Started server process [73672]
INFO:     Waiting for application startup.
INFO:     Application startup complete.
INFO:     Uvicorn running on http://127.0.0.1:50021 (Press CTRL+C to quit)
Downloading: "https://downloads.sourceforge.net/open-jtalk/open_jtalk_dic_utf_8-1.11.tar.gz"
INFO:     127.0.0.1:53516 - "POST /audio_query?text=Linux%E4%B8%8A%E3%81%A7%E3%81%AE%E3%83%90%E3%82%A4%E3%83%8A%E3%83%AA%E5%8B%95%E4%BD%9C%E3%83%86%E3%82%B9%E3%83%88&speaker=1 HTTP/1.1" 500 Internal Server Error
ERROR:    Exception in ASGI application
Traceback (most recent call last):
  File "/home/ytjvdcm/Downloads/linux-cpu/uvicorn/protocols/http/h11_impl.py", line 373, in run_asgi
  File "/home/ytjvdcm/Downloads/linux-cpu/uvicorn/middleware/proxy_headers.py", line 75, in __call__
  File "/home/ytjvdcm/Downloads/linux-cpu/fastapi/applications.py", line 208, in __call__
  File "/home/ytjvdcm/Downloads/linux-cpu/starlette/applications.py", line 112, in __call__
  File "/home/ytjvdcm/Downloads/linux-cpu/starlette/middleware/errors.py", line 181, in __call__
urllib.error.URLError: <urlopen error [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed: unable to get local issuer certificate (_ssl.c:1091)>
INFO:     127.0.0.1:53518 - "POST /synthesis?speaker=1 HTTP/1.1" 422 Unprocessable Entity

GPU

$ ./run --use_gpu
INFO:     Started server process [73891]
INFO:     Waiting for application startup.
INFO:     Application startup complete.
INFO:     Uvicorn running on http://127.0.0.1:50021 (Press CTRL+C to quit)
Downloading: "https://downloads.sourceforge.net/open-jtalk/open_jtalk_dic_utf_8-1.11.tar.gz"
INFO:     127.0.0.1:53524 - "POST /audio_query?text=Linux%E4%B8%8A%E3%81%A7%E3%81%AE%E3%83%90%E3%82%A4%E3%83%8A%E3%83%AA%E5%8B%95%E4%BD%9C%E3%83%86%E3%82%B9%E3%83%88&speaker=1 HTTP/1.1" 500 Internal Server Error
ERROR:    Exception in ASGI application
Traceback (most recent call last):
  File "/home/ytjvdcm/Downloads/linux-nvidia/uvicorn/protocols/http/h11_impl.py", line 373, in run_asgi
  File "/home/ytjvdcm/Downloads/linux-nvidia/uvicorn/middleware/proxy_headers.py", line 75, in __call__
  File "/home/ytjvdcm/Downloads/linux-nvidia/fastapi/applications.py", line 208, in __call__
  File "/home/ytjvdcm/Downloads/linux-nvidia/starlette/applications.py", line 112, in __call__
  File "/home/ytjvdcm/Downloads/linux-nvidia/starlette/middleware/errors.py", line 181, in __call__
urllib.error.URLError: <urlopen error [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed: unable to get local issuer certificate (_ssl.c:1091)>
INFO:     127.0.0.1:53526 - "POST /synthesis?speaker=1 HTTP/1.1" 422 Unprocessable Entity

@aoirint
Copy link
Member Author

aoirint commented Sep 24, 2021 •
edited
Loading

@YTJVDCM

Downloading: "https://downloads.sourceforge.net/open-jtalk/open_jtalk_dic_utf_8-1.11.tar.gz"

これが想定している挙動ではないですね..
本来は、OpenJTalkの辞書を同梱しているので、ダウンロードは走らないのです。

もしかすると、自動ビルドの方に問題があるかもと思いました。

#100 ( b8c1c78 ) で自動ビルド時の辞書ダウンロード機能を修正して、一応の対策を施しているので、もし、それ以前のバイナリを使っているようであれば、新しいバイナリを試してみてほしいです。

ちなみに、#100 の開発時にUbuntu 20.04で検証していた限りでは、同様の問題（SSL検証エラー）は起きませんでした。ArchLinux特有かもしれません。

Issue本文のダウンロード用URLは、以下の古いバイナリになっていましたが、新しいもの bb681d0 に置き換えておきました。

3eed8e0: https://github.com/Hiroshiba/voicevox_engine/actions/runs/1250933554

bb681d0 を手元でArchLinuxのDockerイメージ archlinux:base-20210829.0.32635 を使って試したところ、以下のようなエラーが出ました。ArchLinuxのことを詳しく知らないので、特有の現象なのか、パッケージが不足しているのかなど、よくわかりません。Ubuntu 18.04（Dockerイメージ ubuntu:bionic-20210827）では正常起動しました。

# docker run --rm -it -p '127.0.0.1:50021:50021' -v "$(pwd):/work" -w /work archlinux:base-20210829.0.32635

# pacman -Sy

# pacman -S libsndfile
...
libsndfile-1.0.31-1
...

# ./run 
Traceback (most recent call last):
  File "/work/run.py", line 424, in <module>
  File "/work/run.py", line 84, in make_synthesis_engine
  File "core.pyx", line 16, in core.metas
  File "core.pyx", line 17, in core.metas
UnicodeDecodeError: 'utf-8' codec can't decode bytes in position 1-2: invalid continuation byte

@aoirint aoirint changed the title Ubuntu 20.04、Debian 11、Fedora 34でのLinux用実行バイナリの動作検証 Linux用実行バイナリの動作検証 Sep 24, 2021
@YTJVDCM
Copy link

YTJVDCM commented Sep 24, 2021 •
edited
Loading

新しいビルド(bb681d0)で同様に実行したところ、ArchLinux上でもCPUでは正常に動作したことを確認しました。
(GPUでは上記と同じutf-8' codec can't decode byteのエラーが出ます)
CPUではエラーの発生はなく、ボイスについてもspeaker=0,speaker=1両方とも動作しました。

その後いろいろ確認してみたのですが、どうやら特定箇所のデコードに失敗するのではなく、毎回別の位置のデコード(具体的な規則性があるかは不明)に失敗するらしく、CPUもGPUも、何度も起動するとまれに起動することがあるようです。

@aoirint aoirint mentioned this issue Oct 12, 2021
Closed
@Hiroshiba
Copy link
Member

utf-8エラーが出る問題は0.7.4で解決されたと思います。
https://github.com/Hiroshiba/voicevox_engine/releases/tag/0.7.4

@HyodaKazuaki
Copy link
Contributor

libsndfile（VOICEVOX ENGINEのAPIが返す、wavファイルの作成に使用）をインストール。

Windows向けビルドにはlibsndfile(_soundfile_data/libsndfile64bit.dll)が同梱されていますが、Linux向けビルドには同梱されていません。
そのため、libsndfileを要求されているのだと思います。
この件について @aoirint にお伺いしたいのですが、libsndfileを同梱していない理由はなんでしょうか？

@aoirint
Copy link
Member Author

aoirint commented Nov 13, 2021 •
edited
Loading

@HyodaKazuaki

同梱していない理由は、bastibe/python-soundfileの配布パッケージにlibsndfileが含まれていなかったため、 #88, #95, #96 ではLinux上でのENGINE動作を優先して先送りしたというものです。

個人的には、少なくともVOICEVOXソフトウェアにはWindows版と同様にlibsndfileを同梱するのがいいように思います。

python-soundfileにおいて、Windowsと同じように共有ライブラリを読み込ませるには、詳しい仕様をよくわかっていないですが、いくらか検討が必要そうに思っていました。

検討事項

  • libsndfileのビルド済みバイナリを用意する方法
    • Dockerfileでビルドする
      • libsndfileが依存するライブラリ（libflac、libvorbis）のビルドも必要?
      • waveの機能だけ使えればいいのであれば、libflacやlibvorbisとのリンクは不要?
      • python-soundfile同梱のDLLでは、libflacやlibvorbisは静的リンクされている?
    • OSのパッケージリポジトリから取得したものを再配布する
      • 互換性・ライセンスの確認
      • libsndfileが依存するライブラリ（libflac、libvorbis）の同梱
  • python-soundfileの共有ライブラリ読み込み部の実装に変更が必要かもしれない

@HyodaKazuaki
Copy link
Contributor

そうですね、おそらくSoundFileの実装面については十分対応可能だと思います。

依存ライブラリの点については、一旦すべて入れておいたほうが良さそうな気がします。
もしくは、bastibe
/
libsndfile-binaries
のMac向けビルドに従って同じ酒類の依存ライブラリをリンクしても良いかもしれません。

互換性の点については、x64/aarch64などで分けてビルド処理することになると思います。
そうなると、利用者が誤って異なるアーキテクチャのエンジンをダウンロードしない限りは問題ないのかなと思いました。

ライセンスの点については、libsndfileや依存関係のライブラリの多くがLGPL v2.1になっています。
この場合、LGPL v2.1のSection 6(ex. ライセンスやリンクの表示など)がエンジンに適用されることになります。
現時点でWindowsやMac向けビルドにはSoundFileが同梱しているbastibe
/
libsndfile-binaries
が含まれていますが、licenses.jsonには特に記載がなかったように思いました。

@Hiroshiba
Copy link
Member

Hiroshiba commented Nov 14, 2021 •
edited
Loading

なるほどです！
Linuxパッケージ版へlibsndfileを追加するのは、優先度は低めですがやったほうが良いなと感じました。
licenses.jsonにライセンスの記載がないのは良くないので、優先度高めで解決したいかもです。こちらはissue化したいと思います。

2021/11/14 18:52　追記　後者のissue作りました！

@HyodaKazuaki 依存パッケージは何か、どうやって調べたかなどをコメントいただけるととても助かります・・・！！

@Hiroshiba Hiroshiba mentioned this issue Nov 14, 2021
Closed
@HyodaKazuaki
Copy link
Contributor

依存パッケージは何か、どうやって調べたかなどをコメントいただけるととても助かります・・・！！

そうですね、失念していました。
これはUbuntu focalの場合です。

  1. Ubuntu パッケージ検索でlibsndfile1を検索する
  2. focal向けのlibsndfile1を選ぶ
  3. libsndfile1及び関連パッケージの中の依存パッケージのそれぞれにある著作権ファイルを見る
    ex. libsndfile1の著作権ファイル: http://changelogs.ubuntu.com/changelogs/pool/main/libs/libsndfile/libsndfile_1.0.28-7ubuntu0.1/copyright

libsndfile1はlibc6に依存していますが、殆どの環境でlibc6は入っているかと思います。
ですので、気にする必要がある依存パッケージは以下の4つになります。

  • libflac8
  • libogg0
  • libvorbis0a
  • libvorbisenc2

Windows/Mac向けビルドに同梱されているlibsndfileの情報は、bastibe/libsndfile-binariesにあります。
ここで使われるFLACやOggの共有ライブラリは、Linuxのものと異なるライセンスが適用されます。
ref. https://github.com/bastibe/libsndfile-binaries/blob/84cb164928f17c7ca0c1e5c40342c20ce2b90e8c/README.md#copyright

@Hiroshiba
Copy link
Member

詳細をありがとうございます！
これはなかなか大変そうですね･･･　続きは https://github.com/Hiroshiba/voicevox_engine/issues/187 でするのが良いかなと思いました！

@HyodaKazuaki HyodaKazuaki mentioned this issue Nov 18, 2021
Merged
@aoirint aoirint mentioned this issue Dec 1, 2021
Closed
@aoirint
Copy link
Member Author

aoirint commented Dec 1, 2021 •
edited
Loading

libsndfileの同梱については、別にIssueを立ててみました。

そろそろこのIssue（Discussion）はクローズしてもいいかなと思ったので、クローズしておきます。

このIssueは、十分な検証ができていなかった、自動ビルドされたLinux用バイナリの、主に開発者からの動作報告を募集するためのものでした。
すでに製品版のLinux用ビルドは10月末の0.7.5でリリースされていて、Linux用ソフトウェアのユーザも見かけるので、ある程度の動作確認はできたのかなと思います。

今後は個別にIssueを立ててもらう形でいいかなと思いました。

検証など、ありがとうございます！

CloseしてもSubscribeは残ると思うので、何かこちらに投稿されれば気づけるとは思います。

もしIssue化のハードルが高いかもというのがあれば、ソフトウェアの方にDiscussionを作るとかでしょうか...

当初の目的は達成されたと思うのでいったんクローズしましたが、Discussion Issueを作り直したりしてもいいのかもです。

@aoirint aoirint closed this as completed Dec 1, 2021
@aoirint aoirint mentioned this issue Mar 8, 2022
Closed
@aoirint aoirint mentioned this issue Aug 23, 2022
Closed
@tarepan tarepan removed the 要議論 実行する前に議論が必要そうなもの label Mar 17, 2024
@Hiroshiba Hiroshiba mentioned this issue May 2, 2024
Merged
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
5 participants
@Hiroshiba @HyodaKazuaki @tarepan @aoirint @YTJVDCM