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

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

Open
ctrlcctrlv opened this issue Jun 9, 2021 · 15 comments
Open

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

ctrlcctrlv opened this issue Jun 9, 2021 · 15 comments

Comments

@ctrlcctrlv
Copy link

ctrlcctrlv commented Jun 9, 2021 •
edited
Loading

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

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:

Future plans

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をマージしました。

今後の予定

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

遠い未来

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

自薦の理由

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

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

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

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

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

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

このようなどうしようもない困難な状況を繰り返さないためにも、共同管理者がいることを強くお勧めします。
@ctrlcctrlv ctrlcctrlv changed the title Notification of fork (フォークのお知らせ) Notification of fork at libsixel/libsixel (libsixel/libsixelのフォークのお知らせ). This project is unmaintained. (管理者 @saitoha が不在です。) Jun 9, 2021
@johnnychen94 johnnychen94 mentioned this issue Jun 9, 2021
Open
This was referenced Jun 9, 2021
Open
Closed
@ctrlcctrlv
Copy link
Author

ctrlcctrlv commented Jun 9, 2021 •
edited
Loading

I've fixed one CVE (libsixel#8) and followed up on the other (#134 (comment)). 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) を修正しました。もう１つについては詳細な情報を要求しました。(#134 (comment)) 申立人からの返答を待つか、期限切れになるかです。一週間に返事がない場合は、再現性がないので、CVE にバグを取り下げてもらおうと思います。この件もすぐに解決できると思います。

This was referenced Jun 9, 2021
Open
Open
@ctrlcctrlv
Copy link
Author

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を作成しました。

@danieldk danieldk mentioned this issue Jun 9, 2021
Closed
@dankamongmen
Copy link

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
Copy link
Author

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

2021-06-09-162900_1881x870_scrot

@ctrlcctrlv ctrlcctrlv mentioned this issue Jun 9, 2021
Closed
@ctrlcctrlv
Copy link
Author

@dankamongmen Any luck?

@dnkl dnkl mentioned this issue Jun 12, 2021
Closed
ctrlcctrlv added a commit to ctrlcctrlv/w3m that referenced this issue Jun 13, 2021
@ctrlcctrlv
Use libsixel fork with CVE fixes
12eac50 
`img2sixel` had two CVE's, and its maintainer disappeared. See saitoha/libsixel#154.

Myself and @dankamongmen are maintaining it now at libsixel/libsixel. Link to new repository.

Arch Linux etc. are distributing this version (libsixel 1.9+) now.
This was referenced Jun 13, 2021
Closed
Open
@orbea
Copy link

orbea commented Jun 16, 2021 •
edited
Loading

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
Copy link
Author

Project update

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

Context at libsixel#20 (comment), 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
Copy link

@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
Copy link

orbea commented Sep 26, 2021

@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
Copy link

  • 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
Copy link

orbea commented Sep 28, 2021

  • 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
Copy link

  • 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
Copy link

WSLUser commented Oct 12, 2021

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
Copy link

TimB87 commented Oct 16, 2021

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.

@johnnychen94 johnnychen94 mentioned this issue Jan 1, 2022
Closed
johnnychen94 added a commit to JuliaIO/Sixel.jl that referenced this issue Jan 1, 2022
@johnnychen94
update libsixel url
07011d3 
New libsixel activities now happen on the fork repo, see also saitoha/libsixel#154
This was referenced Sep 5, 2022
Merged
Open
@t-bltg t-bltg mentioned this issue Sep 5, 2022
Merged
@GitMurf
Copy link

GitMurf commented Sep 6, 2024

If anyone else stumbles upon this thread and the fork that was created from this, unfortunately it looks like this fork has met the same fate of being no longer maintained. See here: libsixel#76

At this point I am unsure of what to do? Which repo to rely on since they are both unmaintained?

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
7 participants
@dankamongmen @ctrlcctrlv @orbea @eli-schwartz @TimB87 @WSLUser @GitMurf