weechat / weechat.org Goto Github PK

Currently WeeChat's policy on new asks contributors to check "that no script (or pending script) does exactly same thing as your script" lest the script is rejected. I propose that this policy is lifted.

As I see it, the policy brings the following benefits

• It's easier for user to choose a script that does what he wants as he's not baffled by the number of options

And has the following downsides

• It, like, uh, simply doesn't work. Try /script search url

• It prevernts developers from participating in script development. Let me explain this a bit. A while ago I noticed that the script colorize_lines.pl does not display mIRC colors, so I attemped to fix it. The script looked like this. It was almost 700 lines long, it lacked useful comments and (at least to my mind) contained a lot of weird code. I don't know what you might have done, but it's painful to me to correct such code, so rewrote the script from scratch. Now the script is less than 300 lines long, which makes it more than 3 times smaller if you don't count the code. And the script works fine with mIRC colors now. The script is now in the main repository.

  Now you may say that there's no problem with that. But colorize_lines.pl is used by a handful of people and doesn't exactly provide many options, so it was pretty much OK to release it without much testing. On the other hand, if I were to rewrite buffers.pl from scratch, I'd be facing the following problems:

  • this script is used by most weechat users, so it must be extensively tested before releasing
  • it provides a great number of options, which would be hard to reimplement
  • I cannot change options and other behavior in a way that would break current setup of the users of the script, even if it makes sense

  All this makes me discouraged from contributing to the existing script.

• As a result of the previous point, scripts become series of patches with no major rewrites. I partly blame the policy for the following code in buffers.pl:

    for my $buffer (@buffers)
        {
        if (weechat::config_integer( $options{"sort"} ) eq 1)
            {

  Not only this code breaks style guidelines for perl, but it results in a call to config_integer for each iteration of the loop on the list, which happen on every hotlist change, while it is a rather expensive operation and could be called once per script launch.

• It limits users' choice as well as contributors' competition

• It forces users to use specific plugins if they want specific functionality

I suggest:

• lifting the policy. Scripts can be rejected on project owner's discretion, but this policy just doesn't help
• creating a setting such as "show dev scripts" which would allow installing of developing scripts from /script repository, promoting testing of new scripts

P.S. Some of the scripts are really broken;
P.P.S. I don't believe this will result in a huge flood of amateur scripts;
P.P.P.S. If at some point there are a lot of scripts that do te same thing, we can just remove the worst of them or the abandoned ones from the repository

It might be obvious for people who have been using IRC, but a total newbie like me is quite confused by this line in the quick start guide:

/server add <server> <hostname>[/<port>]

I spent 15 minutes wondering and searching the internet to understand the meanings of server versus hostname. When I see <server>, I think "hostname of a server". So, why enter the server name twice?

Later, it dawned to me that <server> is not an attribute of the IRC server, and that I can replace it with any string I want. E.g. after /server alberteinstein chat.freenode.net, I can access the freenode IRC server with /connect alberteinstein.

Would be nice if this were documented somewhere, especially in the quickstart document.

Currently in the devel docs the topic bar is always there. See here - http://i.imgur.com/2OqdWoB.png

I personally (and I think lots of other people) enjoy it when the documentation can be read in full width, so could there please be a method to otherwise collapse that left bar?

With Ubuntu 16.04 Xenial I get the following warning every time I use "apt-get update".

W: https://weechat.org/ubuntu/dists/xenial/InRelease: Signature by key 11E9DE8848F2B65222AA75B8D1820DB22A11534E uses weak digest algorithm (SHA1)

PS! This is NOT a duplicate. The problem still exists and instead of opening it again in the wrong repository I created a new issue here.

When running /ban for a user that has been in the channel before you, the $host variable in the setting irc.network.ban_mask_default is unknown to weechat which results in a fallback banmask $nick!@.
Weechat should run /who before /ban automatically.

At this time there are only MD5 sums of the scripts and themese available. It would be nice to have something newer like sha256/sha512/… there as well.

The reasoning behind this is that I am transforming the XML files into NixOS packages. Solely trusting the md5 hashes (and potentially transport crypto) isn't ideal. I'd rather have a better hash of the content.

What probably has to be done:

• Add a field for the newer hash sum with the appropirate length to the models:

  weechat.org/weechat/scripts/models.py

  Line 94 in 1fb7c29

  md5sum = models.CharField(max_length=MAX_LENGTH_MD5SUM, blank=True)

  and

  weechat.org/weechat/themes/models.py

  Line 66 in 1fb7c29

  md5sum = models.CharField(max_length=MAX_LENGTH_MD5SUM, blank=True)

• Create a new database migration
• Update the hash calculation to (additionally; for backwards compatibility) to also calculate and store the new hash:
  

  weechat.org/weechat/scripts/models.py

  Lines 206 to 214 in 1fb7c29

  	def md5(self):
  	"""Return MD5 checksum of script."""
  	try:
  	with open(self.filename(), 'rb') as _file:
  	filemd5 = md5()
  	filemd5.update(_file.read())
  	return filemd5.hexdigest()
  	except: # noqa: E722
  	return ''

  and

  weechat.org/weechat/themes/models.py

  Lines 317 to 322 in 1fb7c29

  	with open(files_path_join(theme.path(),
  	theme.name),
  	'rb') as _file:
  	filemd5 = md5()
  	filemd5.update(_file.read())
  	value = filemd5.hexdigest()

• Output the new hash in the JSON/XML exports:

  weechat.org/weechat/scripts/models.py

  Lines 432 to 433 in 1fb7c29

  	elif key == 'md5sum':
  	value = script.md5()

Disclaimer: I tried writing that patch a while ago but never got to the point where I could test it due to difficulties setting it up locally. :/ I ran into undocumented settings that were missing in the example documentation and eventually ran out of time.

Hi,

The weechat signing key is being spammed, the instructions on https://weechat.org/download/ should not use the SKS network, users attempting the instruction to import the key will break their gnupg installation.

Currently the signing key on SKS is 180MB.

Background:

• https://dkg.fifthhorseman.net/blog/openpgp-certificate-flooding.html
• https://dkg.fifthhorseman.net/blog/community-impact-openpgp-cert-flooding.html
• https://gist.github.com/rjhansen/67ab921ffb4084c865b3618d6955275f
• https://lists.gnupg.org/pipermail/gnupg-announce/2019q3/000439.html

The plural of "Skript" is "Skripte", NOT "Skripten". It's eyecancer-inducing.

On Feb 2, Raspberry Pi OS 64 bit was officially released: https://www.raspberrypi.com/news/raspberry-pi-os-64-bit/
It would be nice if WeeChat could supply official builds for arm64.
Right now when I add the raspbian repository, I get the following error:

W: Skipping acquire of configured file 'main/binary-arm64/Packages' as repository 'https://weechat.org/raspbian bullseye InRelease' does not seem to provide it (sources.list entry misspelt?)

Several people have expressed desire to donate via Bitcoins.

While this may take some setup, with exchanges and how popular BTC is these days, I think this is a good idea, and shouldn't be that troublesome.

If it is somewhere, robots.txt doesn't tell where it is. It should contain e.g. Sitemap: https://weechat.org/. It looks like django can automatically generate it, but I don't understand ddged instructions.

• sitemaps.org - protocol

Having sitemap.xml would help search engines.

At the main page there's a text:
"Najnowsza stabilna wersja WeeChat to 1.1.1, wydano 25 Sty 2015."
There should be:
"Najnowsza stabilna wersja WeeChat to 1.1.1, którą wydano 25 Sty 2015. "
The current version contains a grammatical error.

Hi!

http://weechat.org/ contains these typos:

* a free software released under GPLv3 license

should be "A free program released under the GPLv3 license".

Regards,

-- Shlomi Fish

Feature description

Right now, the official Debian/Ubuntu repositories only have ARM builds for Raspbian.

I would like to see this expanded to Ubuntu as well, at least for LTS releases. While I cannot speak for all, I and a few of my peers run WeeChat from servers. ARM has become a pretty compelling option in that space.

Recently I was looking to move my WeeChat install to an arm64 server running 22.04 LTS when I realized that there are no official packages for it.

Bug summary

Installation instructions at https://weechat.org/download/debian/ fail on Debian 11 "Bullseye" at least.

Issue starts with the required packages installation command provided sudo apt-get install dirmngr gpg-agent apt-transport-https as it doesn't install gpg itself.

Then the use of --no-default-keyring in the sudo gpg ... command that follows causes other errors due to it not allowing for the /root/.gnupg/ directory to be created.

(Couldn't have identified the issues without the help of the kind folks on #weechat IRC channel.)

Steps to reproduce

(Simply following instructions at https://weechat.org/download/debian/ for Debian 11 "Bullseye" and applying fixes as necessary. Output of the commands is shown indented after each command—where necessary, for clarity.)

Install required packages as per the documentation:

$ sudo apt-get install dirmngr gpg-agent apt-transport-https

Import the GPG key used to sign the repositories:

$ sudo mkdir -p /usr/local/share/keyrings

$ sudo gpg --no-default-keyring --keyring /usr/local/share/keyrings/weechat-archive-keyring.gpg --keyserver hkps://keys.openpgp.org --recv-keys 11E9DE8848F2B65222AA75B8D1820DB22A11534E

    sudo: gpg: command not found

Install gpg to fix the issue of missing package:

$ sudo apt-get install gpg

Run the command to import the GPG key used to sign the repositories — again:

$ sudo gpg --no-default-keyring --keyring /usr/local/share/keyrings/weechat-archive-keyring.gpg --keyserver hkps://keys.openpgp.org --recv-keys 11E9DE8848F2B65222AA75B8D1820DB22A11534E

    gpg: keybox '/usr/local/share/keyrings/weechat-archive-keyring.gpg' created
    gpg: failed to create temporary file '/root/.gnupg/.#lk0x000055ad529dc160.temp2.14929': No such file or directory
    gpg: connecting dirmngr at '/root/.gnupg/S.dirmngr' failed: No such file or directory
    gpg: keyserver receive failed: No dirmngr

It appears the /root/.gnupg/ directory isn't being created automatically by gpg due to use of the --no-default-keyring flag.

Current behavior

(See above. It's clearer if the output is shown with the commands so I added it above.)

Expected behavior

Installation should be possible by simply following the instructions in the documentation.

Suggested solutions

1. Include gpg among the packages to install, along with any other recommended packages.

2. Remove --no-default-keyring from the sudo gpg command.

   Alternatively, user should simply run gpg and exit it (Ctrl + C) for /root/.gnupg/ directory to be created. Then the sudo gpg command, with the --no-default-keyring flag, should run without issues.

   User could, of course, also create it manually, like so:

   sudo mkdir /root/.gnupg
   sudo chown -R root:root /root/.gnupg/
   sudo chmod 700 /root/.gnupg/
   

Additional information

N/A

• WeeChat version: N/A
• OS, distribution and version: Debian 11 "Bullseye"
• Terminal: N/A
• Terminal multiplexer (screen/tmux/…/none): N/A

I was having issues importing the gpg key using the instructions so I tried to find the GPG key separately and finally found it from https://weechat.org/dev/info/ after going to open a duplicate of #87 and #97.

I wish it was linked directly from https://weechat.org/download/debian/.

I've noticed that often in #weechat even when linked to https://weechat.org/download/debian/ fail to understand what they're supposed to do in order to get newer versions on debian/ubuntu. The step-by-step instructions on that page are on the bottom. When newbies are hit with that page starting with the long list of distros they are shocked and don't realize there's any instructions at the bottom.

Therefore I suggest moving the instructions to the top of the page or somehow else making them easily found for someone looking at the page for the first time. It is not very often that someone needs to see the list first thing on the page as only experienced enough users will have any use for it.

for example with: https://weechat.org/dev/info/signing_key

initial task is to use it with Travis

The longest script name gnome_screensaver_away.py causes weird wrapping in the scripts table name column. If that row didn't exist, the same issue would happen with whatever other longest script name there is, etc. See screenshot:

I think popular stars should be in a separate column, not a float because that non-existent popular icon is causing it to wrap like that.

Availability of Version 1.9 has been announced in weechat.org.
But article text of the news is not exists in this repository.
We can not translate the news...

Running the site on debian unstable or archlinux gives

Internal Server Error: /
Traceback (most recent call last):
  File "/usr/lib/python2.7/dist-packages/django/core/handlers/exception.py", line 42, in inner
    response = get_response(request)
  File "/usr/lib/python2.7/dist-packages/django/core/handlers/base.py", line 249, in _legacy_get_response
    response = self._get_response(request)
  File "/usr/lib/python2.7/dist-packages/django/core/handlers/base.py", line 187, in _get_response
    response = self.process_exception_by_middleware(e, request)
  File "/usr/lib/python2.7/dist-packages/django/core/handlers/base.py", line 185, in _get_response
    response = wrapped_callback(request, *callback_args, **callback_kwargs)
  File "/weechat.org/weechat/news/views.py", line 57, in home
    return render_homepage(request, info_list, max_info, event_list, max_event)
  File "/weechat.org/weechat/news/views.py", line 37, in render_homepage
    'release_stable': Release.objects.get(version='stable'),
  File "/usr/lib/python2.7/dist-packages/django/db/models/manager.py", line 85, in manager_method
    return getattr(self.get_queryset(), name)(*args, **kwargs)
  File "/usr/lib/python2.7/dist-packages/django/db/models/query.py", line 385, in get
    self.model._meta.object_name
DoesNotExist: Release matching query does not exist.
[21/Mar/2017 14:45:46] "GET / HTTP/1.1" 500 77885

No issue in debian jessie, and replacing weechat.db with the one from fresh install in debian jessie the site works normally.

Most nice websites that contain extensive information have their own means to search the site.
Lots of drop in solutions exist:

• htdig
• hyperestraier
• etc., etc.

It seems like directory listings are disabled, returning 403s, on:

• https://weechat.org/files/src/
• https://weechat.org/files/src/devel/

The weechat port uses these URLs to check when a new version is released, and the second URL is linked to on the development tab in the download section.

Is disabling the directory listings intentional? Not a big issue if it is–I can look into other methods for version checks for MacPorts.

Since there are scripts like this that have 21 chars name, I assume the "max 20 chars" text is the incorrect one. This minor inconsistency might confuse new script authors.

EDIT: Ah, just tried submitting and there's server side checking that does check if script name is longer than 20 chars. How did bitlbee_typing_notice.py and correction_completion.py get accepted then?

I think the limit should be increased to 32 chars. 20 is too short.

So I guess this is both bug report (inconsistency between server side check and client side check) and feature request (increase limit to 32 chars).