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" | |
+ ;; |