Ploum wrote:

> Thus, in offpunk, we use python-pil to extract the first frame
> of an animated gif if chafa is used and if chafa version < 1.10
> and if there’s no timg or if timg version <= 1.3.2.

I (AUR packager of offpunk-git) have removed the hard dependency on python-pil, and made versioned optional dependencies for chafa>=1.10 or timg>1.3.2 (Arch currently has chafa 1.14.1 and timg 1.6.0, so the versioned optional dependencies are not strictly needed, but I'll keep them for a little while).

> Also, I’ve seen that python-pil has been marked as a hard dependency
> for the Arch package. While this is not a big problem, I feed bad for
> having people installing a library and its dependency when it will
> probably never be used.

I agree.

Sotiris Papatheodorou wrote:

> I would argue that both client and server certificates are important to back up.

I agree with this.

Perhaps offpunk could use the $XDG_STATE_HOME (default: ~/.local/state) directory instead of $XDG_CACHE_HOME. I wouldn't object to XDG_DATA_HOME (~/.local/share) but the data is not really “shared” with anyone — they're for offpunk only — so I prefer the state directory.

Cheers,

-- 
Kʟᴀᴜꜱ Aʟᴇxᴀɴᴅᴇʀ Sᴇɪꜱᴛʀᴜᴘ
https://kas.bio.link/ 🇩🇰

ray.hubert wrote:

> works like a charm after adding `lxml-html-clean`. I also notified
> the packager (kseistrup) for the AUR version so they can add it as
> a dependency.

Yes, thank you so much for the notification.

In addition to adding `lxml-html-clean` I have made all importable python modules hard dependencies, and kept external programs like the clipboard stuff as optional dependencies, because even though offpunk is very liberal in its demands, the burden of sorting out inter-dependencies was placed on the shoulders of each individual user. This should now be a thing of the past.

If I may side-track the thread for a minute:

The pyperclip Python modules handles all the clipboard methods offpunk does, and then some (Qt and KDE clipboards), so if offpunk were using pyperclip we could drop the [optional] dependencies of xclip, xsel and wl-clipboard, and using it is as simple as `pyperclip.copy(f"{TEXT}")`.

Ploum wrote:

> I just added xclip in parallel to xsel. Could you please
> try if everything works fine in X11?

The `version` command says:

```
Nice to have:
- python-setproctitle       : Installed
- X11 clipboard (xsel or xclip)   : Installed
- Wayland clipboard (wl-clipboard): Not Installed
```

Ploum wrote:

>> [`fish_clipboard_(copy|paste)`]
>
> Do you think we should do the same in offpunk?

It seems like lightweight checks to do, so why not. It could even be implemented as two functions (e.g. `get_clipboard_copy()`) that is called upon first invocation and then memoized so that subsequent invocations already know what to do.

> Should it still be marked as a dependency or can we safely
> assume that at least one solution would work and throws a
> message in the rare case none of those work?

On AUR I have set these as optional dependencies: if people want e.g. image support, they should install this, if the want … they should install … and so on. And it should be visible in the version command if it works.

Ploum wrote:

> I’ve implemented support for both X11 clipboard (xsel) and Wayland 
> clipboard (wl-clipboard) in trunk.

Looks good.

The fish shell's `fish_clipboard_copy` and `fish_clipboard_paste` are using these heuristics to include Wayland, MacOS and Windows:

Copy:

```
if type -q pbcopy
  printf '%s' $cmdline | pbcopy

Ploum wrote:

> The only hypothesis I have for that kind of behaviour is offpunk
> being considered as a bot/spam/crawler.

How would the site know that? Offpunk doesn't set/send anything like HTTP's User-Agent, does it?

> Any other hypothesis to explain the problem?

I would assume that I had made an error, rather than thinking that the world is against me.

I can see in netcache.py that offpunk does all sorts of things in order to set up a TLS connection. Specifically I see that it attempts to set the ciphers

  "AESGCM+ECDHE:AESGCM+DHE:CHACHA20+ECDHE:CHACHA20+DHE:!DSS:!SHA1:!MD5:@STRENGTH"

Ploum wrote:

> Just pushed a new annotated tag, should be fine now

Thanks. I bumped the package “epoch” on AUR because the old “g765f8f6-1” > the new “g1bbd317”, so now we're going from “2:2.1.r0.g765f8f6-1” to “3:2.1.r0.g1bbd317-1”.

That should solve it.

Thanks.

-- 
Kʟᴀᴜꜱ Aʟᴇxᴀɴᴅᴇʀ Sᴇɪꜱᴛʀᴜᴘ 🇩🇰
https://magnetic-ink.dk/kas

Ploum wrote:

> How is it possible? How does it take its value?

It gets the value from the git blockchain. I guess the “amend” thing b0rked something.

Do you get something else when you run “git describe --long” in the repo?

The AUR package is using “git describe” to construct a unique package version for each commit:

🔗 https://wiki.archlinux.org/title/VCS_package_guidelines#Git

Cheers,

Ploum wrote:

> I amended the commit and forced the push.

Please note that “git describe” now says we have v2.0:

    $ git describe --long --abbrev=7
    v2.0-14-g1bbd317

So the ArchLinux package will seemingly downgrade from v2.1.* to v2.0.*. 

-- 
Kʟᴀᴜꜱ Aʟᴇxᴀɴᴅᴇʀ Sᴇɪꜱᴛʀᴜᴘ 🇩🇰
https://magnetic-ink.dk/kas