Mods loadeded with MagicLauncher
Core Mods, and the order they're loaded in:
| jQuery(function($){ | |
| // This is a script to manipulate the source of a PhotoBucket album so that it can be easily mass-downloaded. | |
| // change the settings as per your requirements. | |
| // copy-paste this source into your WebConsole ( in the WebDeveloper tools menu ) and run it, for great success. | |
| var settings = { | |
| images: false, | |
| links: true, | |
| description: true, | |
| delete_original: true, | |
| }; |
Mods loadeded with MagicLauncher
Core Mods, and the order they're loaded in:
| use v5.14; | |
| use strict; | |
| use warnings; | |
| use Win32::Job; | |
| use File::Which qw( which ); | |
| sub _win32_escape_command_token { | |
| my $token = shift; |
The upstream module in question has dual-build, so its not a show-stopper, however, our eclass situation is such that gentoo will:
In the presence of a Build.PL file, always used Module::Build style invocation, regardless of truth.
In the scenario where Build.PL is Not Module::Build, erroneously complain about a dependency on Module::Build, which is not necessary
Also entirely fail to QA check on the appropriate dependency when Build.PL requires some other things.
Essentially, the QA check we have in place is a bit wonky, and the mechanism that triggers it is wonky and unreliable too.
| --- /usr/portage/eclass/perl-module.eclass 2013-12-30 11:01:16.000000000 +1300 | |
| +++ /tmp/perl-module-r1.eclass 2014-01-12 02:30:27.526844896 +1300 | |
| @@ -52,6 +52,22 @@ | |
| ;; | |
| esac | |
| +case "${PERL_MODULE_TOOLKIT//[[:space:]]/}" in | |
| + mb) | |
| + DEPEND="${DEPEND} virtual/perl-Module-Build" | |
| + ;; |