#metabrainz

I always used the rabbitmq management plugin to inspect messages, but I don't know if that's provided by the docker container

we are using rabbitmq:3.6.5-management

oh, great - if you access the web interface it provides, you should be able to click your way to all the messages in a specific queue

bitmap: ^ do we have a way to do that

if the port is exposed you should be able to use an ssh tunnel

alternatively, the caa-indexer also has a retry and failed queue, you should be able to use the same commands you use for inspecting those to look at the messages

s/exposed/published/

looks like it is 65414 on serge

Mineo: with messages https://www.irccloud.com/pastebin/qXHjnOdq/

looks like it's just empty

bitmap: is it ok to just leave it growing like that https://stats.metabrainz.org/dashboard/db/rabbi...

or should I remove the triggers?

they're not being consumed?

no

need to fix the bug first :)

depends on how fast you can fix the bug then :)

I'll just remove them for now

can fall asleep any minute

zas: I don't see anything wrong on our side, I'm not sure what's going on

caa-indexer is working fine but archive.org isn't generated thumbnails for some reason

generating*

can that be related to me messing with rabbitmq?

ok, search triggers dropped

this looks like a problem at the IA, I don't observe any problem with the caa-indexer or rabbitmq

alright, just checking

a completely empty message looks weird - the triggers hardcode at least the entity type in the message, so that should be there

can you do grep "PERFORM amqp.publish(.*, 'search', '.*', ''" * in the sql/ directory you're using?

(that is, grep for amqp.publish calls on any exchange where even the entity type is not set)

are you talking about this directory https://github.com/metabrainz/sir/tree/master/sql?

the one I currently use is at https://github.com/gentlecat/sir/tree/docker/sql

I connected to the management interface btw

I've added the saving import status to redis and showing message to user on import page stuff to the PR. :)

Mineo: there's nothing

guess I'll just skip them for now

zas Mineo bitmap, a proposal for picard plugins, can we include a compatibility list for all plugins?

so that only plugins that are tested by plugin authors to run in a particular os are included

I am willing to make a PR for all the existing plugins and include the code in plugins.py to process this

+1 from me, but I'd say it's too late for 1.4.

Freso: I think we can make it

not much changes

I have a windows, linux and osx machine

I can test the plugins on all 3 and make a compatibilty list

the code wont be large enough to cause errors, just an if while loading

please don't put any more things into 1.4. a lot of the pull requests this last month have been fixes for obviously easy things from the last 2 months already

^

There are plenty of things that individually "wont be large enough to cause errors".

1.4 is in feature freeze. This would be a feature.

hmmm, what should we do about the inclusion of non compatible windows plugins then?

leave it for 1.4.1?

samj1912: I'd say so, yes.

they cause import errors in the log which makes people wary that something is wrong with picard

Sure.

I can't find the reason right now, why were plugins put back into the windows installer?

Mineo: Backwards compatibility I think.

so that the required imports can be included by py2exe

Ah. Right.

Could that be written so py2exe includes the required imports, but doesn't actually bundle all the plugins?

we can, well either have to write a script of some sort to figure out all the includes and add them to py2exe includes

(Also, it still won't help if a plugin changes dependencies between releases.)

or if there is a built in functionality like that for py2exe that I am not aware of, then I am not sure

(Or if a new plugin is added with new dependencies.)

(So maybe another approach entirely should be sought.)

Freso: yeah, that is why we need a more permanent solution so that picard doesn't load any plugins not marked tested for that OS

the plugin author can include a COMPATIBLE_OS list in which the plugins run and are tested and picard loads only those

I was thinking more like making bundled and unbundled packages.

So the script that currently creates the plugin .zip's would include script dependencies.

hmmmm

Because your COMPATIBLE_OS list still won't solve plugin dependency changes between versions.

how so?

when a plugin author updates his plugins he can simply update the COMPATIBLE_OS list

I may have tested a given plugin in a virtualenv on both Mac and Windows and concluded that it worked fine.

But that doesn't mean that the additional PyPi packages in the virtualenv now exist on all Picard installations.

hmm, we have to figure out some way to deal with pip packages and plugins

Anyway. This whole thing is too involved to make it into 1.4 in any shape or form.

yeah I suppose

but we need to provide some sort of fix for the errors?

Don't even bother. Direct your energy towards maybe getting it into 1.4.1 or 1.4.2 or just keep it for 2.0.

Naw. Just get it out there. Make a fix to some degree for 1.4.1.

hmmm

do we know if there are any plugins that are compatible with windows and which have a dependency only added via py2exe?

videotools I suppose, however even that is broken

We can remove sockets from the excludes and it should work though

wait, why would videotools need the socket module?

somewhere in enzyme I think

We can only give hints about compatible envs and requirements, but we have no way to ensure a certain plugin will work or not, because we only have control over Picard, not plugin code nor the env Picard runs in. So the best we can do is to use safeguards (exception handling) and alert the user (error messages).

Do any plugin break Picard ? Or they just don't load/work ?

they just dont load

and throw an error in the debug log

which makes people think something is wrong with picard

also the way picard handles erroneous plugins is not at all correct

Well, something is wrong with Picard ;)

it just gives a dialog box saying the plugin will be updated

in case there are plugin errors on load

ok, musixmatch is another plugin that depends on urllib and therefore on socket

[picard] samj1912 opened pull request #610: Remove sockets from py2exe exclude list (master...patch-9) https://git.io/vDYai

If a dialog appears, and it is unrelated, then it is a bug. But in which exact conditions does it happen ? Is there an easy way to reproduce on linux ?

zas, trying now

but here's the thing: if there's not a single plugin that works by being included in the installer, I don't see any reason to include plugins in the installer at all

The plugin UI lacks of testing imho ;)

the only thing we seem to be gaining are errors in the logs right after installing picard

Mineo: true

if this continues, we can just remove the bundling code from setup.py and win packaging script making it like how it was before

We can improve messages in log if they are confusing

zas, can you merge that PR? I want to test if any of the currently unsupported plugins work after including sockets

if not we will remove the bundling code

Anyone knows why we don't have tests anymore on Picard PRs ??

also I think picard testing has been disabled in travis CI?

yeah ^^

Who changed what .... that is the question...

changing metabrainz's travis config seems to be the likely cause

https://travis-ci.org/metabrainz/picard/pull_re... has builds for pull requests

github's CI acting up then?

It would never!1321l

[picard] samj1912 opened pull request #611: Add travis build status to README (master...patch-10) https://git.io/vDYwX

Sup peeps! Can I wildcard moth/day in a release search if I only know the year?

*month

sure, like date:2017*

hmm github didnt even post an irc message on new picard merge

or like type:Heterocera

Mineo, thanks, just tried YYYY-*-* which also appears to work, will use your way though...

Gentlecat: what was the purpose of the change on github third parties apps you asked to mayhen yesterday ? Can it be related to that ?

s/mayhen/mayhem/ (sorry Master. I will not do it again, please noo nooo noooo...)

lol :)

XD

I kinda like that. If I had a female alter ego...

*r_dunn has exited channel. In disgust.*