Perl 6 - the future is here, just unevenly distributed

IRC log for #metacpan, 2014-06-12

| Channels | #metacpan index | Today | | Search | Google Search | Plain-Text | summary

All times shown according to UTC.

Time Nick Message
00:49 oiami joined #metacpan
01:10 oiami left #metacpan
01:14 oiami joined #metacpan
01:20 FROGGS_ joined #metacpan
01:29 klapperl joined #metacpan
02:49 ribasushi ranguard: moar fail: http://paste.scsys.co.uk/393264
02:49 dipsy [ magnet_web paste from Someone at 217.168.150.38... ]
02:49 ribasushi ranguard: do you want me to keep reporting these and/or do you want me to start a ticket and keep adding logs there or something?
03:25 tokuhirom is metacpan unavailable?
03:25 tokuhirom https://www.dropbox.com/s/ajll2oqxzzp9pks/Screenshot%202014-06-12%2012.25.08.png
03:26 dipsy [ Dropbox - Screenshot 2014-06-12 12.25.08.png ]
03:28 haarg working for me
03:32 oalders those varnish messages must be coming from fastly
03:32 oalders https://twitter.com/lestrrat/status/476929565491601408
03:32 dipsy [ twitter - Twitter / lestrrat: .@metacpan seems unstable. ... ]
03:33 oalders but maybe not from all of their data centres
04:26 oiami joined #metacpan
04:26 oiami left #metacpan
04:55 omega do we know how the fastly healthchecks works?
04:55 omega could it be timing out too fast from some of their service locations?
05:04 ribasushi oalders: is there a general reason you are serving the cpan mirror via fastly?
05:05 ribasushi it seems to be rather finicky, and ew care how many milliseconds will it take to download modules
05:05 ribasushi *few
05:05 ribasushi yet all clients (cpanm included) do not properly retry on transient network fails
05:07 oiami joined #metacpan
05:35 oiami1 joined #metacpan
06:13 vanstyn joined #metacpan
06:33 dpetrov_ joined #metacpan
06:40 neilb joined #metacpan
07:02 FROGGS_ joined #metacpan
07:09 neilb_ joined #metacpan
07:34 * kentnl put the IP he was given a few weeks back back in his hosts file and it works >_>
07:35 oiami1 left #metacpan
07:35 oiami1 joined #metacpan
07:35 oiami1 left #metacpan
07:39 kentnl as in, without that hosts file change, MetaCPAN is currently hard-down for me.
07:40 mst same here
07:40 oiami joined #metacpan
07:41 neilb joined #metacpan
07:53 omega works from Bangkok at least, so I guess some fastly-node is having problems
08:13 neilb joined #metacpan
08:26 DerAlex joined #metacpan
08:28 ranguard still having problems?
08:28 ranguard http://status.fastly.com/ - suggests only uS West might have some issues
08:28 dipsy [ Fastly Status ]
08:29 ranguard http://debug.fastly.com/ - please put that info in a ticket on metacpan
08:29 dipsy [ Fastly Debug App ]
08:31 ranguard ribasushi: it offloads load from our server and if/when that host gets popular that will be important - and a few milliseconds can be quite a lot of milliseconds depending where you are in the world
08:32 ranguard I see Fastly getting a spike of errors/timeouts from our server for https://metacpan.org/ - I'll increase the timeout even further
08:32 dipsy [ Search the CPAN - metacpan.org ]
08:32 kentnl ranguard: I seem to have it working again now
08:36 kentnl This page took 2057 ms to load # is that big for the debug page?
08:38 ranguard I think that's ok (I see 1460ms) and seem to remember it always being high
08:41 omega ilmari: https://github.com/CPAN-API/metacpan-web/pull/1223 took a bit longer than I had hoped, got side-tracked :)
08:41 dipsy [ Add anchors to news, FAQ (and other about pages) by omega · Pull Request #1223 · CPAN-API/metacpan-web · GitHub ]
08:42 kentnl ranguard: should I just tack a comment on 1194, or should I open a bug for a problem I'm no longer seeing? :)
08:50 ilmari omega: header_ids is actually on by default in T:MM
08:50 ilmari omega++ # header fix
08:50 omega ilmari: oh, I didn't read docs that carefully I guess :P but better safe than sorry and all that :D
08:51 ilmari omega: yeah, no harm in being explicit
08:58 kentnl lol. You won't beleive this, but for some reason I can't understand, performing a scroll query sorted is *faster* than unsorted+scan
08:59 kentnl well, at least it is when all results return in the first request
09:00 ranguard kentnl: umm, tack a commen ton 1194 - then if you actually get problems again we have a 'good' value to compare to
09:35 ribasushi ranguard: I meant the CPAN mirror itself
09:36 ranguard ribasushi: I've increased the timeouts on that as well
09:37 ranguard it still offloads load from our server
09:37 ribasushi ranguard: I am replying to "a few milliseconds can be quite a lot of milliseconds depending where you are in the world"
09:37 ribasushi but yeah I suppose load is a good point
09:37 ranguard :)
09:38 ribasushi the downside is of course clients expect proper tcp (slow but workable), and fastly is geared towards browsing (where failures are nonfatal)
09:39 ranguard yea, though changing the config seemed to have made a big difference before, it's been a while since we had these errors, hopefully tweaking even more will stop it
09:40 ranguard that and we're trying to get some more servers
09:41 ranguard so hopefully be able to split things out a bit more
09:44 ribasushi unrelated: I noticed that numbers on https://metacpan.org/favorite/leaderboard more or less froze
09:44 dipsy [ Popular Distributions - metacpan.org ]
09:44 ribasushi is this because no new clicks, or because no new accounts altogether?
09:47 rashi joined #metacpan
10:19 kentnl ranguard: its not frozen, I just +1'd File::ShareDir and it moved up from last place
10:19 kentnl er, ribasushi
10:19 ribasushi I meant relatively frozen - i.e. perl has not moved in a month or so
10:20 kentnl I just +1'd perl, 206 -> 207
10:21 ribasushi kentnl: I am not reporting a technical issue, I am wondering if there is a social issue is all ;)
10:24 * kentnl files a bug with parliament
10:24 kentnl expect to see that issue resolved in ~100 years.
10:59 alnewkirk joined #metacpan
11:42 neilb_ joined #metacpan
12:22 DerAlex joined #metacpan
12:35 FROGGS joined #metacpan
13:27 rwstauner joined #metacpan
13:35 kentnl I just found a fun thing. For some reason cpan --dev Log::Any::Adapter downgrades Log::Any to 0.14, but *without* --dev installs Log-Any-Adapter-0.11
13:36 oalders :)
13:36 * kentnl is not sure if indexing is to blame or if cpanms metacpan code is wrong
13:37 kentnl guessing cpanm at this point
13:41 oalders probably worth opening an issue on cpanm for that
15:19 ether kentnl: because Log::Any::Adapter 0.14 appears in the Log-Any dist (but not indexed)
15:19 ether and because 0.14 > 0.11, cpanm thinks that it's the latest dev version
15:20 ether so you need to get jswartz to nuke Log-Any-0.14 from cpan so it's not visible anymore
15:20 ether and kids, this is what happens when we move a module between distributions. You've got to take the highest version across all dists
15:21 ether (hypothetical kids; not you) :D
15:21 * ether pictures little children sitting at the hearth when she says this, with me in a great old rocking chair telling stories of life as a programmer before neural implants.
15:51 kentnl ether: he didn't even move a module between dists. He just used "::Adapter" somewehere in his source file and PAUSE unintentionally indexed it :/
15:51 kentnl and because he's owner of both dists, he had the permission to make that mistake have side effects
15:52 kentnl ether: https://metacpan.org/source/JSWARTZ/Log-Any-0.14/lib/Log/Any/Test.pm#L1
15:52 dipsy [ lib/Log/Any/Test.pm - metacpan.org ]
15:52 ether ugh, yeah.
15:53 ether I see he's added a \n # hide from PAUSE in 0.15
15:53 ether but cpanm will still see 0.14 as "latest version" until it gets deleted
15:53 kentnl it doesn't though, in normal conditions where it uses the official index its fine
15:54 kentnl add --dev to the picture and things get messy
15:54 ether I'm not sure what mechanism cpanm is using to find this in --dev
15:54 ether as there's no index to query
15:54 kentnl because "what is a dev version" =~ 'unindexed latest version'
15:54 ether oh, I think it's using a metacpan query :)
15:54 kentnl Yep.
15:56 kentnl I think for the normal indexes to even work the way they do, jswartz would have had to do a manual trigger of ::Adapter being indexed
15:56 kentnl its just the queries we're going to use with metacpan, I'm not sure if they can differentiate between "latest but no longer indexed" vs "latest and not indexed"
15:57 ether Module::Metadata has an is_indexable() method
15:57 ether i.e. "ignoring what else is in PAUSE, is this eligible for entering the index?"
15:58 ether so --dev queries could always ignore anything where is_indexable() is true
15:59 kentnl How are you going to use is_indexable() on metacpan?
16:04 ether the elasticsearch index is apparently building up a list of found modules -> dists
16:05 ether so, we'd need another flag in there indicating whether the dist was indexable (not marked _001, -TRIAL, release status != stable in metadata) and what modules are found inside that are indexable or not
16:06 ether I don't know what exact query cpanm is doing, but it needs to ask for unindexable dists explicitly
16:06 ether unindexable modules that is, since it's querying on a module name
16:06 ether so if you're saying cpanm --dev Log::Any::Adapter, cpanm wants the latest version of Log::Any::Adapter that *isn't* eligible for indexing
16:07 ether and there isn't one, so it would fall back to the indexed version, from Log-Any-0.11
16:07 ether and at no time would you get Log::Any::Adapter 0.14 from the other dist
16:07 haarg --dev doesn't exclude indexed modules afaik
16:08 ether does it just look for the latest version, hang its indexed status?
16:08 haarg i believe so
16:08 ether in that case Log::Any::Adapter in the other dist should never have a version attached to it then, so it can never override the official version
16:08 ether what a mess :)
16:24 invalid_packet joined #metacpan
16:40 rashi joined #metacpan
16:48 rwstauner joined #metacpan
16:52 neilb joined #metacpan
17:36 rwstauner joined #metacpan
17:58 rwstauner joined #metacpan
18:55 DerAlex joined #metacpan
18:56 rwstauner joined #metacpan
18:57 neilb joined #metacpan
19:18 GumbyNET5 joined #metacpan
19:43 kentnl yeah. Pretty much.
19:45 kentnl the fun thing that happens is you install Log::Any 0.15 "yep, thats fine", then it goes to install "Log::Any::Adapter" which downgrades "Log::Any", cpanm goes "well, we upgraded", but the module still doesn't exist on disk.
19:47 kentnl https://gist.github.com/kentfredric/f076561a5b28d82701c7 # performing this query gives interesting output, the perl filename is randomly swapping between .tar.gz and .tar.bz2 it seems.
19:47 dipsy [ gist:f076561a5b28d82701c7 ]
19:48 kentnl that's slightly less consistent than s.c.o which always does .tar.gz
20:13 GumbyNET7 joined #metacpan
22:24 rashi joined #metacpan
22:29 b_jonas joined #metacpan

| Channels | #metacpan index | Today | | Search | Google Search | Plain-Text | summary