upstream is dead

[eylles]

upstream ueberzug is archived to not be maintained anymore and seems the package was removed from pip.

as for distribution debian now has the main patch from this repo in their package for ueberzug, few people got their forks with issues open so i'm using this one to tag some of the ones that have been working on their forks rather recently.

@zsmeyer @arturxedex128 @pfr-dev @alb3rt4n @jstkdng

and those who have produced useful patches that would be nice to merge.

@jpalus @Stefantb @stefanbjarna

ueberzug on debian sid with tabbed support: https://tracker.debian.org/pkg/ueberzug

[jstkdng]

hello, I've been using this patch for a while on arch.

https://patch-diff.githubusercontent.com/raw/seebye/ueberzug/pull/149.patch

Arch's package should probably switch as well.

[eylles]

okay, time to dirty this up more, but looking at how there is more people who are starting forks or trying to continue where seebye last left off before archiving i propose to start a unified repo for maintenance and development of ueberzug, perhaps in an organization.

@glowfi @offgrid88 @doctorfree @cr1315 @Rizhiy @ABapps

[gokberkgunes]

I am not sure I have enough knowledge about Ueberzug to develop it or anything, I just hack it based on my needs at most. I find that having a community behind the project might help to keep the program alive rather than one or two people.

[jstkdng]

indeed, ueberzug is quite the complex piece of software and help from ppl with python c extensions experience would be nice.
Then again, ueberzug could be considered complete software so a lot of maintenance would not be required.

[arturxedex128]

i forked ueberzug just for viewing video's (using opencv), also the images are now loaded with opencv, (more dirty then a good hack ... i would contribute to a maintained repo of ueberzug

[eylles]

The biggest hurdle of maintenance needed for ueberzug now would be just to have a unified upstream that has the important patches, say the patch for tabbed, the patches for terminals with a daemon process (mate, urxvt, etc...) and the per user lock file patch.

Then it would be matter of seeing if some impirtant bug shiws and to fix it, other than that just make sure that ueberzug can be built against the latest python release should be enough maintenance long term.

[jstkdng]

I've been thinking of adding other features, like using cmake for the build of the python extension, mainly for the creation of a compile_commands.json file.

[eylles]

Welp, that is a more secondary thing i say, the important thing now would be to have a unified upstream that collects and merges all currently available patches in a sensible manner.

[offgrid88]

I would be more than happy to help, If I can, I am using ueberzug and when I need a new feature or spot a bug I'll try to fix it

[eylles]

Welp, i'm tempted to create an org and a community repo for the continuation of ueberzug, but i kinda want more people to answer here before that.

[Rizhiy]

@eylles I will be happy to help with python-related tasks

[eylles]

Welp, looking at the numbers i'd say we got enough people to start an ueberzug organization to create a unified repo, wot do u guys propose we name the org?

[Rizhiy]

Just name it ueberzug for now, no need to complicate things.

[jstkdng]

yeah, just a simple name

[N-R-K]

There are two good reasons not to use the ueberzug name:

1. Confusion: having the same name will make it that users will be confused between which repo is the "real" one (and thus not knowing where to file bugs etc).
2. Respect for the original author: The original readme had the following statement:

Actually I think it's not fine that they call it ueberzug after changing the code.
As bugs introduced by them look like they are part of my work.

So it's clear that the author doesn't want other people to use that name - and I think that wish should be respected.

[Rizhiy]

@N-R-K

1. The original repo clearly says deprecated, so I don't see how there can be any confusion.
2. After the stunt that they pulled with removing the package from indices I don't see why we should respect their wishes.
   Also, it doesn't say so in the current readme, so might as well disregard that.

Keeping the name has two benefits:

1. It will be clear what the project is supposed to do. I just want to have old functionality back. Unless people want major changes, keeping the name makes sense.
2. People won't have to change their requirements, so nicer user experience. IMHO user experience comes before dev experience.

Anyway, debating the name is pointless, if you want a different name, use something like newberzug.
The goal should be to restore functionality, not debate over minutia.

[eylles]

I think for now keeping the name, since the OG author archived and pulled the packages is okay, however the organization for development of ueberzug shouldn't simply be named "ueberzug" or "ueberzug-dev"

[jstkdng]

ueberzug reborn is a good name

[eylles]

Okay, once my shift is over i will create an org with an ueberzug repo, what i'm thinking now is to use a fork of seebye's original repo so that everyone can just PR their commits to the new master of that repo, i will end my shift in about 3 hours.

[eylles]

ah sorry, i was tired yesterday but today i will create the organization.

[eylles]

the organization and repo are up, i will set up a new master branch and we can discuss how to go about some changes.

[jstkdng]

@eylles can you enable issues in the new repo?

also, rollback to a commit before the archiving

[eylles]

yeh, i gotta do that, i've been busy running some tests for a nsxiv PR so i will set up the repo properly in a moment.

also i've been thinking that the first real work to do is to merge the tabbed and daemon terminals patch into a single PR since those are related.

[jstkdng]

yeah, I'll make the 2 PRs I opened here on the new repo.

[eylles]

yeh, just gib me some time before that, i want to have everything tidy before opening issues and pull requests.

[eylles]

k, i was doing some other stuff, anyway i figured out how to have a "clean" master branch to work from so here's the repo.

https://github.com/ueber-devel/ueberzug

[N-R-K]

Anyway, debating the name is pointless, if you want a different name, use something like newberzug. The goal should be to restore functionality, not debate over minutia.

I just noticed that ueberzug is actually licensed under GPL (I was thinking it was BSD/MIT) and GPL has a this term:

requiring that modified versions of such material be marked in
reasonable ways as different from the original version

Which, to me (not a lawyer), seems like a new name should be the safest thing to do in order to legally comply with the license.

newberzug seems fine to me.

[eylles]

Ah that section.

Notwithstanding any other provision of this License, for material you
add to a covered work, you may (if authorized by the copyright holders of
that material) supplement the terms of this License with terms:

    a) Disclaiming warranty or limiting liability differently from the
    terms of sections 15 and 16 of this License; or

    b) Requiring preservation of specified reasonable legal notices or
    author attributions in that material or in the Appropriate Legal
    Notices displayed by works containing it; or

    c) Prohibiting misrepresentation of the origin of that material, or
    requiring that modified versions of such material be marked in
    reasonable ways as different from the original version; or

    d) Limiting the use for publicity purposes of names of licensors or
    authors of the material; or

    e) Declining to grant rights under trademark law for use of some
    trade names, trademarks, or service marks; or

    f) Requiring indemnification of licensors and authors of that
    material by anyone who conveys the material (or modified versions of
    it) with contractual assumptions of liability to the recipient, for
    any liability that these contractual assumptions directly impose on
    those licensors and authors.

Those are supplements, additions and further restrictions that maybe added on top of the gpl v3, not inherent to it, and even if right now seebye was to add those restrictions they cannot be applied retroactively, so using the old name is okay.

[ghost]

I'm glad this version still works. Using it with lf works great. Thanks!