Notification of fork at libsixel/libsixel (libsixel/libsixelのフォークのお知らせ). This project is unmaintained. (管理者 @saitoha が不在です。)

[ctrlcctrlv]

※日本語版は下にスクロールしてください※

Hello, this project has been forked due to an absent maintainer who has remained absent for over a year.

Problem

This project has not been updated in a year. That is a problem for packagers and maintainers of downstream software. @saitoha has gone missing, and no longer posts even on Twitter. Their last action seems to be assigning an issue to themselves in March 2020. This makes them absent for around one year and three months.

Maintainers have a right to disappear without notice, of course. Work on open source is volunteer. However, when it happens, the community of users must decide what to do. I believe enough time has passed for a fork. I nominate myself as lead maintainer, and the fork is at libsixel/libsixel. libsixel is a new organization for this effort, and @saitoha has been added also as a maintainer should they ever reappear. @dankamongmen has been added as a maintainer due to his stewardship of notcurses.

Fork status as of announcement

The fork is already 8 commits ahead of this repository, I merged the following 6 PR's:

• 151 (libsixel#2, author: @johnnychen94) — Very minor change, just making sure every function in include/sixel.h appears in Windows dll;

• 147 (libsixel#1, author: @auppal) — I compiled and confirmed it indeed fixes #61. I found the loss of bgindex in certain functions somewhat troubling, but until there's an API for that I don't think it even matters. (cf. #149.)

• 142 (libsixel#3, author: @paulhfischer) — simple typo fix.

• 140 (libsixel#4, author: @dthadi3) — fixes for Travis CI. Might be unnecessary given future plans, but merged anyway pending discussion.

• 133 (libsixel#5, author: @arakiken) — Addition of so-called "ormode", referring to XOR. The name is indeed strange, but it seems to be the commonly accepted name. I read the Japanese blog post, and it seems to be a rare Sixel API extension supported on NetBSD. Since it's disabled by default, I didn't see a problem with merging it. I doubt most people will want to use it, but no reason to reject the work. The code seems fine and follows flow of the rest of it.

• 129 (libsixel#6, author: @ttdoda) — Very minor change in what's distributed, adding license files. Should help Linux distributions.

Future plans

• To maintain an updated version of libsixel, to respond to PR's in a timely manner, to consider PR's presented here as well as at libsixel/libsixel.
• To encourage the distribution of libsixel in more Linux distributions, by having a maintained fork that will respond to security patches and issues.
• To urgently fix #149 and #29, supporting transparent pixels in the API. This is a personal need of mine, and much of my reason for doing this.
• To urgently fix security issue #136, so as to have the designation on us in NixOS by @dotlambda and @danieldk overturned.

Far future

• Consider rewriting in Rust.

Justification of my self-nomination

I nominate myself as maintainer because:

• just like @saitoha, I speak both Japanese and English, and can respond to issues in both languages;
• I have a real, continuing need for this library as a result of my effort to add libsixel support to the kitty terminal emulator;
• I plan to contribute large patches to fix the transparency and security issues;

Others who think they have some justification for being maintainer or collaborator in the new organization are welcome to comment. I'll likely add anyone who asks and has any significant contribution.

On the event of @saitoha's return

The community should discuss what to do, and I would recommend that the new GitHub organization still be used, and @saitoha still nominate co-maintainers if they're going to want to remain as lead. I can transfer ownership of the libsixel organization to @saitoha should he request it. This situation is untenable and cannot be allowed to be repeated.

日本語版

こんにちは、このプロジェクトは、1年以上も管理者が不在のため、フォーク（派生）されました。

問題

このプロジェクトは1年以上更新されていません。これは、下流のソフトウェアや管理者にとって問題ですね。@saitoha は行方不明になり、Twitter にも投稿しなくなりました。@saitoha の最後の行動は、2020年3月に自分に GitHub issue を割り当てたことのようです。つまり、約1年3ヶ月間、不在だったことになります。

もちろん、管理者には予告なしに姿を消す権利があります。オープンソースでの作業はボランティアのことである。しかし、そうなった場合、ユーザーコミュニティが何をすべきかを決めなければなりません。僕は、@saitoha　の承認がなくても、フォークを正当化するのに十分な時間が経過していると信じています。僕は自分をリードメンテナに指名し、フォークはlibsixel/libsixelとします。libsixel はこの取り組みのための新しいGitHubの組織（Organization）で、@saitoha も管理者として追加されています（再び現れる場合）。また、notcurses の管理者である @dankamongmen も管理者として追加されました。

（発表時の時に）フォーク状況

フォークは既にこのリポジトリより8コミット進んでおり、以下の6つのPRをマージしました。

• 151 (libsixel#2, @johnnychen94 で) — 小さな変更で、include/sixel.h にあるすべての関数が Windows の dll に現れることを確認しただけです。

• 147 (libsixel#1, @auppal で) — コンパイルして、確かに#61を修正していることです。特定の関数で bgindex が失われているのがやや気になりますが、そのための API ができるまでは問題にならないと思います。(#149参照)

• 142 (libsixel#3, @paulhfischer で) - 一つの誤植の修正。

• 140 (libsixel#4, @tdhadi3 で) - Travis CI 用の修正。将来の計画を考えると必要ないかもしれませんが、議論を待ってとりあえずマージしました。

• 133 (libsixel#5, @arakiken で) - （XOR を参照する）いわゆる "ormode" の追加。確かに変な名前ですが、一般的に受け入れられている名前のようです。ブログ記事を読んでみると、どうやらNetBSDでサポートされている珍しい Sixel API の拡張機能のようです。デフォルトでは無効になっているので、マージしても問題はないと思いました。ほとんどの人が使いたいとは思わないでしょうが、この作業を拒否する理由はありません。コードに問題はなく、変更も自然に見えます。

• 129 (libsixel#6, @ttdoda で) - ライセンスファイルの追加。配布物に関する非常に小さな変更です。Linux ディストリビューションの管理者達に役立つはずです。

今後の予定

※ libsixel の最新版を維持。 ※ 不必要な遅延なく PR に対応。 ※ セキュリティパッチや問題に対応するメンテナンスされたフォークを持つことで、より多くの Linux ディストリビューションへの libsixel の配布を促進すること。 ※ #149 と #29 を緊急に修正し、API で透過色なピクセルをサポートします。これは僕が個人的に必要としていることであり、この作業を行う理由の多くはこれ。 ※ @dotlambda と @danieldk による NixOS での「不安定」指定を覆すために、セキュリティ問題 #136 を緊急に修正。

遠い未来

• Rustでの書き換えを検討。

自薦の理由

自分を管理者に推薦する理由は以下の通りです。

• @saitoha のように、日本語と英語などを話すできるので、日本語・英語で問題に対応できる。
• kitty 端末エミュレータに libsixel サポートを追加する努力の結果、このライブラリを本当に継続して必要としています。
• 透過色とセキュリティの問題を修正するために、大きなパッチを提供する予定です。

他にも、新しいGitHubの組織で管理者／協力者になる正当性があると思う人は、コメントを投稿してください。尋ねてきた人で、重要な貢献をした人は誰でも追加するつもりです。

@saitoha が戻ってきた場合について

@saitoha が自分で要求すれば、僕は libsixel の組織の所有権を @saitoha に譲渡することもできられます。

@saitoha がリード管理者として残りたい場合は、libsixel という GitHub の新組織を引き続き使用し、共同管理者を指名することをお勧めします。僕は共同管理者にボランティアするんです。

このようなどうしようもない困難な状況を繰り返さないためにも、共同管理者がいることを強くお勧めします。

[ctrlcctrlv]

I've fixed one CVE (libsixel#8) and followed up on the other (https://github.com/saitoha/libsixel/issues/134#issuecomment-857726044). Hopefully we can put that one to bed soon as well, pending reply by reporter or expiration (let's say 1 week without a reply and it expires and I try to get CVE to revoke the designation as bug irreproducible).

１つの CVE (libsixel#8) を修正しました。もう１つについては詳細な情報を要求しました。(https://github.com/saitoha/libsixel/issues/134#issuecomment-857726044) 申立人からの返答を待つか、期限切れになるかです。一週間に返事がない場合は、再現性がないので、CVE にバグを取り下げてもらおうと思います。この件もすぐに解決できると思います。

[ctrlcctrlv]

Both CVE security bugs are now remedied. (libsixel#8; libsixel#9)

I have made the first new libsixel release in a long time as well, 1.9.0.

CVEセキュリティバグをすべて修正しました。(libsixel#8; libsixel#9)

また、久しぶりにlibsixelの新規リリース1.9.0を作成しました。

[dankamongmen]

i eagerly support this move!

i have thus far refrained from using libsixel in Notcurses. if it's going to be actively maintained, i'm likely to revisit that decision.

Notcurses is seeing some significant pickup, and is the only solution i know of for people looking to work with portable bitmaps. it would probably benefit us both to design with the other in mind. if you'd like to make me a contributor, i'll happily join on; i can otherwise send PRs through you (but won't be able to review PRs, AFAIK). good luck, and godspeed!

[ctrlcctrlv]

@dankamongmen I thought of you immediately when creating the libsixel organization, you should have an invite already :-)

[ctrlcctrlv]

@dankamongmen Any luck?

[orbea]

A heads up for any distro maintainers, I have been banned from the new libsixel repo (https://github.com/libsixel/libsixel) for politely disagreeing with the choice of meson and being honest that their rude response was not appreciated. Not a good start for a new fork...

I hope @saitoha is well.

[ctrlcctrlv]

Project update

• Meson build system now in use in master, not yet packaged in a release. Build times much improved.
  • Meson ビルドシステムは現在 master で使用されています。まだリリースにされていません。コンパイル時間が大幅に改善されました。
• Due to recent trolling, a code of conduct is under consideration. (libsixel#21)
  • 最近の荒らしのため、行動規範を検討中です。
• Transparent decoder output is now supported, and is the default if an image has transparent pixels in img2sixel. High color image decoding is now supported, fixing libsixel#16 (#147). This is not yet merged, it awaits review as libsixel#23.
  • 透過色デコーディングの出力がサポートされ、img2sixel で画像に透過ピクセルがある場合のデフォルトになりました。高色画像のデコーディングがサポートされ、libsixel#16 (#147) を修正しました。これはまだマージされておらず、libsixel#23 としてレビューを待っています。

In re: @orbea's trolling / @orbea荒らしのコメントについて

Context at https://github.com/libsixel/libsixel/pull/20#issuecomment-862330345, comment @orbea was banned for.

Whether such is warranted, you may individually decide. I intend to keep maintaining this, @orbea's idea of "polite disagreement" is obvious trolling for trolling's sake. Obviously, no one can be banned from using a project, pulling, or compiling a repository, etc. @orbea claimed they were "scared away" anyway, yet here they are attempting to cause issues: more trolling. Their strong distaste for Meson only seldom kicks in it seems: they no doubt have Mesa installed, or one of the other many projects that requires it, such as irssi, GNOME, GIMP, HarfBuzz, Pango, systemd, soon probably Xorg itself. Rather than campaign there, they campaign here, deciding libsixel is unusable if it switches to Meson. Because here their trolling may have some effect, but there it will have none.

I've worked hard on this in past week or so, @orbea would apparently rather have it we all just sit around and do nothing and hope maintainer returns while CVE's stack up. Which, by the way, I even said I'd give him the organization account, and he could decide to fire either me or @dankamongmen at that point, or both of us. I don't view myself as "competition", just "continuation".

https://github.com/libsixel/libsixel/pull/20#issuecomment-862330345、@orbeaさんが禁止されたコメントの文脈です。

そのようなことが正当化されるかどうかは、個々に判断してください 私はこのプロジェクトを維持していくつもりです。

@orbeaさんの考える「礼儀正しい意見の相違」は、明らかに荒らしのための荒らしです。 明らかに、プロジェクトを使うこと、リポジトリを引き出すこと、コンパイルすることなどを禁止することはできません。 @orbeaは「libsixelを使う予定はもうない」と主張しましたが、ここでは問題を起こそうとしています：さらなる荒らしです。 @orbea の Meson に対する強い嫌悪感はめったに起こらないようです。彼はきっと Mesa をインストールしているか、または irssi、GNOME、GIMP、HarfBuzz、Pango、systemd等 そしておそらく Xorg 自体など、Meson を必要とする他の多くのプロジェクトの一つをインストールしているのでしょう。そこでキャンペーンしていません。彼はここだけでキャンペーンします。Mesonに切り替えるとlibsixelが使えなくなると判断します。なぜなら、ここでは彼の荒らしはいくらかの効果があるかもしれませんが、そこでは何の効果もないからです。

私はこの1週間ほど一生懸命取り組んできましたが、@orbeaは明らかに私たち全員が何もせずに座っていて、CVEが積み重なっている間にメンテナが戻ってくることを望んでいるようです。ところで、私は彼に組織のアカウントを渡すと言ったのですが、彼はその時点で私か@dankamongmenのどちらか、あるいは両方を解雇することを決めることができました。私は自分のことを「競争相手」ではなく、「継続」と考えています。

[eli-schwartz]

@orbea no comment on your "polite disagreeing with the choice of meson and being honest that their rude response was not appreciated".

However regarding the specifics of your objections against meson:

• "inherent problems with cross compile" -- this is presumably news to Void Linux, which cross-compiles the entire distro by default and has a number of times expressed satisfaction with meson --- "we find that its generally less broken than autohell" (I was unaware that slackware does cross-compile as a "big thing"? A quick google suggests that an unsupported ARM version is built using distcc farmed out to machines running a cross compiler, which is not actually at all the same)
• lacking support for --docdir and --datarootdir -- is this a strong technical reason to avoid meson for libsixel? Also even in the meson issues opened for these options the rationale seems rather that a meson core option is prettier than a custom project option, it's not like the "workaround" is remotely hard
• it adds a dependency on python -- https://mesonbuild.com/FAQ.html#but-i-really-want-a-version-of-meson-that-doesnt-use-python and I'm sure the muon project (pure C11) would be absolutely delighted to receive any contributions, this will be tremendously useful for more than just some frankly niche-if-interesting graphics library. For example xorg as already mentioned above, which on Tuesday announced rc1 of the first release which has mature meson support and will be the final release to have autotools support purely for migration compatibility.

Hopefully these points will help reassure you that the sky is not falling whenever someone uses meson. :)

[orbea]

@eli-schwartz

• Its been a while so I am not sure how or if it has changed, but check out midipix for cross-compile issues. They had to re-implement the entire python build system to even get python.
• Sure these are minor although very annoying nitpicks, but the real problem is that the complete refusal for any meson devs to actually spend time working on them. Are we supposed to wait years for basic and rudimentary features to even be seriously considered?
• I have not heard of these before, are any of them actually practical to use?

[eli-schwartz]

• I don't understand how "python is hard to cross compile for $PLATFORM" is intended to be an argument that "projects using meson are hard to cross compile for $PLATFORM because meson has inherent problems with cross compile". Meson is part of the host system, not the cross-compile target!
• It seems you cannot make up your mind whether it is a "minor nitpick" or "basic features". For my part, I don't see how it is very "open source community spirit" of you to tell me that as one of the meson devs I am blameful for having "completely refused to actually spend time working on them". PRs welcome... though IIRC docdir hit the snag of needing to somehow apply per-subproject and include the project name, and no one actually had an idea for resolving it! If you have ideas, I am all ears and will personally champion your PR to see it merged. If you have no ideas, only complaints, then I will focus on solving issues which actual meson users have
• muon can build simple projects, including itself. Not all functions are available, and install is not yet implemented, but it is getting better over time. Again, patches welcome. As a meson developer, I wrote that FAQ entry and I too am submitting patches to this competing implementation.

At any rate, it's not entirely clear to me that this fork is doing anything particularly wrong by using meson, and even the theoretical issues with "the large swathes of fundamental projects including all or most of of gnome and freedesktop" are being worked on.

[orbea]

• The argument is not that python is hard to cross-compile, it is that python uses an extremely broken build system that makes it hard to cross-compile. This is why they created sbpython. https://dev.midipix.org/python/sbpython3
• Its a crucial feature and I don't write python. Either you or someone else that does write python should support these crucial features or meson will continue to be a subpar build system. There are more issues beyond just that, but what's the point in talking about that if you (Meson devs) can't even do the basics?
• Sounds not practical and with feature compatibility with meson it will suffer as long as meson refuses to add crucial features.

Its very clear to me, its another project forcing a subpar build system because its being hyped by people that have no considerations for the people that actually have to live with your choices.

[eli-schwartz]

• You still seem to be hung up on somehow needing to cross-compile python from $BUILD_MACHINE to $TARGET in order to run meson on $BUILD_MACHINE using the $BUILD_MACHINE python and a cross-compiler via https://mesonbuild.com/Cross-compilation.html to generate binaries that run on $TARGET.
• your crucial features which no one other than you feels are missing, are not actually used by libsixel, and have trivial one-line meson_options.txt workarounds, are so issueful that you're not even willing to say what your other problems are

Considering the many people who, surprisingly, have to live with the project choice of "it switched to meson" across a wide variety of projects and bizarrely think that their living with it is actually an improvement, I believe that libsixel can safely have a clear conscience about this switch... unless you can come up with better persuasive arguments.

Meanwhile meson will continue its course of welcoming contributions, but only if they are actually contributed. If the single person anywhere ever who needs feature X, isn't willing to contribute, then it's unsurprising that feature X ends up a very low priority. Such is the peril of open source.

[WSLUser]

Some changes were made which may make python compilation better. It now explicitly uses python3 and if there's a problem with that, blame the python devs for deprecating it over a year ago. Meson did mess with python compilation but hopefully it can work more smoothly than before, which my experience was it was broken completely.

[TimB87]

I maintain a few (hundred) packages over at CRUX and have to say I love having more projects switch to meson (and to a lesser extend cmake too, in that regard that everything is better than autohell). Just my two cents.