Fix some 404s in META.list

[JRaspass]

A few dists have switched from META.info to the modern META6.json but not been updated here, until now.

Obviously I don't own these modules but it's clear that at least some point the original authors wanted them to be here so we may as well make them work again :-)

• [X] I agree to the usage of the META file as listed here.

• [X] I have a license field listed in my META file that is one of https://spdx.org/licenses

  • [ ] My license is not one of those found on spdx.org but I do have a license field. In this case make sure you have a license URL listed under support. See this example.
  • [ ] I don't have a license field. Yes, I understand this is not recommended.

[JRaspass]

Looks like Travis fails because some of the META files have invalid versions, but invalid META files are infinitely better than unresolvable META files IMHO.

[JJ]

It's even better with no errors... Most of them are easily solvable via a PR. I would really appreciate if you (or someone) did that... In some cases, #324 might also need to be addressed.

[jjatria]

It looks like one of these (https://github.com/supernovus/PSpec) is now archived and read-only (which means it won't get fixed). I'd suggest we remove it from the list (since it currently 404s, and making it not throw that error breaks tests).

[JJ]

It looks like one of these (https://github.com/supernovus/PSpec) is now archived and read-only (which means it won't get fixed). I'd suggest we remove it from the list (since it currently 404s, and making it not throw that error breaks tests).

Removing something from the ecosystem is an extreme decision, and should be not taken lightly. For starters, it's much better if it's done in a separate statement. Then we'll have to check if there's any downstream dependency. It's probably not the case, but we need to check anyway. And then, of course, we'll have to notify the author just in case.

[lizmat]

I've forked PSpec into raku-community-modules

[jjatria]

I've forked PSpec into raku-community-modules

I tried searching for it, but couldn't find it. Could it be hidden for some reason? I expected to find it here: https://github.com/raku-community-modules/PSpec but that gives me a 404

[jjatria]

I've updated this PR to reflect some of the issues that were brought up. There are still some dists that are failing, but I think all of them have PRs now.

[lizmat]

Oops, I forked PSpec to perl6-community-modules by accident. It should be in raku-community-modules now.

[JJ]

@jjatria but now there seem to be some conflicts, and I can't quite figure out some of them. Can you please check?

[jjatria]

@jj Sure, I'll take a look. It's probably because I'm inserting the names where they ought to be if the list were sorted, but it's not.

Maybe the test can enforce it being kept sorted? Or is sorting not something we care about at all?

[JJ]

It might, but the problem here is that there seems to be a conflict, maybe because I've merged another PR in the meantime...

[jjatria]

@jj I've resolved the merge conflicts with this commit

[JJ]

And now there's a brand new conflict...

[jjatria]

@JJ Fixing the conflicts in this PR (again) will be of no use until the PRs that are blocking this one are merged. As far as I'm aware, they are:

• ~https://github.com/raku-community-modules/Web-App-Ballet/pull/8~
• ~https://github.com/supernovus/perl6-method-modifiers/pull/8~

Once those (or equivalent) PRs are merged, and this one is unblocked, I will happily deal with any new conflicts like I did in the past.

[JJ]

Trying to fix the first now, but it's got errors in some upstream modules too...

Thanks anyway.

[jjatria]

@JJ Incidentally, in one of your previous comments you wrote

Yep, all supernovus modules were moved to the community.

But I cannot find an equivalent for https://github.com/supernovus/perl6-method-modifiers. Does that one also need to be moved? If so, I can make the PR there instead, and update the META reference on this one.

[JJ]

I really have no idea. It might have been overlooked, or who knows. Please ping them, and if they don't answer, you can always adopt it.

[patrickbkr]

As far as I know, supernovus sorted through his modules and only transferred those that had some value. Things that had been superseded or broken beyond repair he left out.

[JJ]

We should probably then just eliminate that one.

[jjatria]

@JJ I'll go ahead and remove the change for that dist, then, and we can remove it in a separate PR

[JJ]

Inline::Scheme::Gambit is looking for Panda... Let's see what we can do there.

[jjatria]

I've opened a PR in p6-c-parser as well, that seems to use a no-longer-allowed (?) author field

[JJ]

Still a couple of modules to go:

• [x] Inline::Scheme::Gambit
• [ ] C::Parser

[2colours]

Is this PR still relevant? If so, what should be done about it?

[JJ]

Well, it's conflicting, so it would really need work if we want to go ahead with it. We will probably need to open it anew, because there might be many more places that 404

[jjatria]

I'm happy to resolve any conflicts on it, but it might be simpler to merge if we fix the 404s one by one rather than many in one go.

FWIW: Inline::Scheme::Gambit has merged the fix for that failing test

[JJ]

Please go ahead with whatever you think is best.

[jjatria]

There's nothing to resolve here in the end. Once the conflicts are fixed, the commit is empty. My guess is all of these have been fixed or added in previous commits (eg. bc5226ad53c48f5938680d9c24fbc8304eed52eb for C::Parser, 438b22d8ba97a18d5c85ff21c703d24756406350 for Web::App::Ballet, etc).

This can be closed :tada:

[lizmat]

Thanks for looking into it