<qrush>
gibsop1: this is due to some recent changes and perf issues with bundler-api
<qrush>
gibsop1: also that newrelic_rpm gem was yanked by the newrelic team
<qrush>
you should update it
jcaudle has quit [Client Quit]
<gibsop1>
Cheers qrush - that's the one with the db password bug in isn't it?
<indirect>
qrush: this is why I think bundler should install yanked gems if they're in the lockfile :\ or print a completely separate alert or something
<qrush>
gibsop1: not sure
<qrush>
indirect: also not sure. been a lot of grumbling about yanks lately but no action. i'm not sure what to do about it
<qrush>
the permadelete queue piles up like normal no matter what happens
<qrush>
i need to run through the support queue...:(
<indirect>
:(
<gibsop1>
it would be good if it could tell us the gem has been yanked, bit more informative
<indirect>
gibsop1: but how can bundler distinguish? all that yanking does right now is makes the gem act like it's not there :(
<gibsop1>
Ah okay - so it's not marked as yanked?
<gibsop1>
fair enough
<gibsop1>
tbh I'm not a dev, more a sysadmin, but it's down to us to deploy the code - so trying to get to the bottom of this
<gibsop1>
so, if I've got this right - the HTTP error is just a badly formatted error, and shouldn't stop the bundle install
<qrush>
yes
terceiro has quit [Ping timeout: 272 seconds]
cowboyd has joined #rubygems
nateberkopec has joined #rubygems
<raggi>
indirect: i think when the bundler api is up, bundler will install yanked gems, as it doesnt' rely on the spec .rz
<raggi>
indirect: c/d
nateberkopec has quit [Client Quit]
<gibsop1>
Okay - so forgive my question, but would bundle install stop if it came across a gem which didn't exist?
cowboyd has quit [Remote host closed the connection]
<indirect>
raggi: d
<indirect>
it only did that briefly because rg.org wasn't sending yanks
<raggi>
indirect: when you say briefly, how long do you mean?
<indirect>
the api has started syncing yanks from rg.org again, bundler can no longer see yanks
markstarkman has joined #rubygems
<indirect>
uhh… a week or two -_-
<indirect>
there were 890 yanked gems
<raggi>
indirect: something more than that changed
<indirect>
when bundler-api switched to updating via HTTP request from rg.org?
<indirect>
apparently rg.org just never notified about any yanks ever
<indirect>
and I had no idea
<raggi>
ok
<raggi>
right
<indirect>
so that was 890 yanked gems that bundler was still happily installing
<indirect>
:(
<raggi>
so a week or so ago, yanked gems stopped working, prior to that, everyone relied on it working
<indirect>
right
<indirect>
it works again as of last night
<indirect>
when I not only synced it back up, but cronned a job to keep it in ~1h sync
<indirect>
so IF the hooks work, sync is instant
<indirect>
if they don't, sync happens during the next job run
<raggi>
indirect: i mean, i have 3 teams hitting this today too, i imagine it's happening to a lot of people
huoxito has quit [Ping timeout: 244 seconds]
<indirect>
raggi: yes :'(
markstarkman has quit [Ping timeout: 256 seconds]
<indirect>
I would much prefer the yanks to be instant
<indirect>
but I don't have time to investigate rg.org's failures right now :\
<raggi>
indirect: so the design goal is, yanked gems shoudl not be installable via bundler?
<indirect>
raggi: the current reality is that they aren't… I have floated the idea of allowing yanked gems to be installed if they are already locked
<indirect>
haven't had time to implement it yet though
<raggi>
indirect: right, totally not meaning to put pressure on you - just wanting to understand where we're headed
<raggi>
indirect: if yanking is to become something that'll reguarly break things, that's something that I and many others are going to have to add steps to defend against
<indirect>
yes
<indirect>
it does and has
<indirect>
sadly
<indirect>
up until ~10 days ago, ever yanked gem suddenly was missing the next time someone tried to bundle install on a new machine
<indirect>
and now that things are in sync again, that is again the case
<indirect>
I would like bundles to not die because a gem got yanked
<raggi>
indirect: so, i have a quick solution to fix this, i could probably implement it relatively fast, it's not that pretty though
<gibsop1>
Sorry to butt in - but can you give me a time that you fixed the yanking issue? We were doing bundle installs ~12hours ago with this same version of newrelic without any errors
<gibsop1>
does that fit with your timings for "fixing" this?
<indirect>
gibsop1: yes
<indirect>
newrelic yanked the gem, which effectively says "stop admitting this version exists"
<gibsop1>
Okay that's fine - I can live with that then - at least I can assure my boss that our testing in preprod was sane today :)
<indirect>
and then bundler can't find it :(
<gibsop1>
Yeah - I could be wrong - but I don't think newrelic just yanked the gem today? I've seen the notice on their webpage for a few days now, so I guess we were just installing a gem that rubygems didn't know had been yanked?
<gibsop1>
or have I completely missed the point?
<indirect>
raggi: partly allowing yanked gems just opens up such a big can of worms
<indirect>
gibsop1: rubygems knew it was yanked, the bundler api didn't :\
<raggi>
indirect: d, on the basis people have been doing it for several years now
<raggi>
indirect: yank != peradelete
<gibsop1>
indirect - ah okay yes that's what I meant I guess - cheers for clarifying that
kentaro has quit [Ping timeout: 264 seconds]
_maes_ has quit [Ping timeout: 272 seconds]
<raggi>
indirect: i mean, maybe these things need to be redefined, but to most people yank means "you shouldn't use this anymore", and perma delete means "you won't be able to get this anymore"
<indirect>
right
<indirect>
so bundle update shouldn't pick yanked versions
<indirect>
bundle install should be okay installing locked yanks
<indirect>
…everything in between is fuzzy
<gibsop1>
if my opinion counts for anything - not allowing yanked gems could be a bit of a nightmare - we run in AWS using Rightscale for autoscaling our servers, if one day we get an influx of traffic and we want to autoscale and add 2 or 3 servers and our build scripts fail due to yanked gems that's a bit of a shitter
<indirect>
bundle install routinely changes the lock, etc etc
<gibsop1>
I guess it could be argued we could not be doing a bundle install though, and having a nice tarbull in s3 to dump on our box?
<indirect>
gibsop1: I agree, that's why I am interested in changing it. but your shitter situation is how it has been for years, so… :\
huoxito has joined #rubygems
<gibsop1>
Yip - I'm certainly not saying my way is the right way - we've only been running in production for around 2 or 3 weeks so we've not come across this issue until tonight
<gibsop1>
ultimately it's done it's job - it's forced us to look at our gems and not deploy a bad gem, and as you say - it's been the way for years
<gibsop1>
right bed time here - cheers for your help tonight guys, laters
workmad3 has quit [Ping timeout: 260 seconds]
yerhot has joined #rubygems
yerhot has quit [Ping timeout: 255 seconds]
yut148 has joined #rubygems
baburdick has joined #rubygems
yerhot has joined #rubygems
jasoares has joined #rubygems
bfleischer has joined #rubygems
huoxito has quit [Quit: Leaving]
mephux has quit [Excess Flood]
mephux has joined #rubygems
twoism has quit [Remote host closed the connection]
lsegal has joined #rubygems
Sophism has joined #rubygems
Sophism is now known as Guest54091
bfleischer has quit [Quit: bfleischer]
markstarkman has joined #rubygems
yerhot has quit [Remote host closed the connection]
<drbrain>
15670793 1.9.x User-Agents (not counting dev versions)
<drbrain>
175264 2.0.0 User-Agents
<drbrain>
there's just under 10k 1.9.xdev
<drbrain>
1.9.3 was recorded 12 million times
sn0wb1rd has quit [Quit: sn0wb1rd]
<raggi>
oh, that's good news
<raggi>
drbrain: so, i just spiked out a plain text index format (before giving that ticket some feedback)
bdrewery has quit [Ping timeout: 252 seconds]
<drbrain>
cool
<raggi>
drbrain: time to load is basically equivalent to marhsal
<raggi>
ruby read_marshal.rb 0.56s user 0.08s system 98% cpu 0.652 total
<raggi>
vs
<raggi>
ruby read_specs.rb 0.59s user 0.07s system 98% cpu 0.664 total
<drbrain>
I haven't read the code, but the description seems to take us back to the style of the original RubyGems index
<raggi>
it's actually within the realms of io jitter
<raggi>
and i haven't optimized yet
<raggi>
drbrain: yes, and that's not a totally bad thing
<drbrain>
everything in one file with (planned) incremental updates
<raggi>
drbrain: although i want not all in one file
<drbrain>
it just needs to be done better the second time around
<raggi>
yes
<raggi>
that's also why i'm just doing a bit of light checking before prividing feedback
<raggi>
i don't want to discourage at all
<raggi>
i'm really glad to see someone stepping up and having a go
<raggi>
omg, lol
<raggi>
the plain text format is less ram heavy too
<raggi>
and less disk heavy
<raggi>
2.2mb vs 3.9mb
<raggi>
o0
<raggi>
marshal :(
<raggi>
aight, home time
<drbrain>
you can get a bit of space back from marshal by de-duping strings
bdrewery has joined #rubygems
yerhot has quit [Remote host closed the connection]
<Defiler>
marshal is the devil
<drbrain>
YAML is the devil
<Defiler>
but it beats YAML
<Defiler>
yeah
sn0wb1rd has joined #rubygems
yerhot has joined #rubygems
<Defiler>
though if we accepted inbound marshal instead of yaml it would be just as bad
<drbrain>
yep
<drbrain>
although, thanks to rubinius, we can write a marshal filter
jasoares has quit [Quit: jasoares]
_maes_ has joined #rubygems
imajes has quit [Excess Flood]
imajes has joined #rubygems
peregrine81 has quit [Quit: Computer sleeping.]
yerhot has quit [Remote host closed the connection]
<raggi>
drbrain: oh, this is deduped
<raggi>
but yeah
<raggi>
i think the largest difference is that i'm using fewer structures, and to_s representations of versions, rather than objects
<raggi>
so, interestingly also, when run against 1.8, 1.8 is much slower at the plain text format
<raggi>
but that might just be acceptable these days
<raggi>
jruby is faster at the plain text format than the marshal format
namidark has quit [Quit: WeeChat 0.3.7]
jarib has quit [Excess Flood]
jarib has joined #rubygems
jarib has quit [Excess Flood]
jarib has joined #rubygems
<raggi>
(even on cold boot)
mockra has joined #rubygems
mockra has quit [Remote host closed the connection]
yerhot has joined #rubygems
yerhot has quit [Ping timeout: 260 seconds]
markstarkman has joined #rubygems
markstarkman has quit [Ping timeout: 260 seconds]
joewilliams has quit [Ping timeout: 256 seconds]
mockra has joined #rubygems
<drbrain>
raggi: less than 1/5 people are on 1.8 these days, I think it's acceptable
<raggi>
drbrain: :)
yerhot has joined #rubygems
mockra has quit [Ping timeout: 276 seconds]
yerhot has quit [Ping timeout: 252 seconds]
<qrush>
the yank situation is very fucked
<qrush>
i'm not happy with it at all
crandquist has joined #rubygems
<qrush>
i almost feel like we should put the foot down and say either no yanks/permadeletes
<qrush>
or try to properly understand the problem
crandquist has quit [Read error: Connection reset by peer]
<raggi>
qrush: my recommendation is yanks should remove from the top level indices, and ui, but not prevent fully pathed installations, and permadeletes shoudl remove everything
<raggi>
qrush: as far as making all the clients respect this properly, that's a different step
<indirect>
1.2.4 is out and also hides the fallback error message
<indirect>
so… phew :P
<qrush>
woot!
<indirect>
also it finally prints "Resolving dependencies…" before it hangs forever, now ;)
crankharder has quit [Read error: Connection reset by peer]
<qrush>
i'm wiped. thanks for helping out indirect
<indirect>
qrush: thanks for fielding all the freaking out people
ddv has quit [Ping timeout: 240 seconds]
yerhot has joined #rubygems
<raggi>
drbrain: well, i'm glad the canadians cleared that up
<drbrain>
:D
yerhot has quit [Remote host closed the connection]
caleb_io has joined #rubygems
kgrz has joined #rubygems
vertis has quit [Quit: Leaving.]
caleb_io has quit [Quit: caleb_io]
markstarkman has joined #rubygems
markstarkman has quit [Ping timeout: 260 seconds]
joewilliams has joined #rubygems
mockra has joined #rubygems
charliesome_ has joined #rubygems
charliesome_ is now known as charliesome
caleb_io has joined #rubygems
ddv has joined #rubygems
markstarkman has joined #rubygems
ddv has quit [Ping timeout: 240 seconds]
markstarkman has quit [Ping timeout: 260 seconds]
ddv has joined #rubygems
caleb_io has quit [Quit: caleb_io]
eighthbit has quit [Quit: Bye.]
caleb_io has joined #rubygems
lsegal has quit [Quit: Quit: Quit: Quit: Stack Overflow.]
roolo has quit [Quit: Leaving...]
fwaokda has quit []
Hypn has joined #rubygems
caleb_io has quit [Quit: caleb_io]
Elhu has joined #rubygems
markstarkman has joined #rubygems
mockra has quit [Remote host closed the connection]
markstarkman has quit [Ping timeout: 256 seconds]
guilleiguaran has quit [Ping timeout: 276 seconds]
guilleiguaran has joined #rubygems
teancom has quit [Remote host closed the connection]
workmad3 has joined #rubygems
<gibsop1>
back to my issue from last night - we had two deployment scripts, one incorrectly had "--without test development" missing in the bundle install command - and bundler didn't exit when it couldn't find the missing newrelic Gem - is that standard behaviour for bundling on test/dev?
stinnes has joined #rubygems
bradland_ has joined #rubygems
bradland has quit [Read error: Connection reset by peer]
bradland_ is now known as bradland
tbuehlmann has joined #rubygems
markstarkman has joined #rubygems
markstarkman has quit [Ping timeout: 260 seconds]
vertis has joined #rubygems
icco has quit [Read error: Operation timed out]
icco has joined #rubygems
aspiers has joined #rubygems
<gibsop1>
scrap that - figured it out - dodgy coding on our side :)
terceiro has joined #rubygems
yut148 has quit [Quit: Leaving...]
stevenharman has quit [Quit: Leaving...]
qmx|away is now known as qmx
stinnes has quit [Remote host closed the connection]
imperator has joined #rubygems
qmx is now known as qmx|brb
bfleischer has joined #rubygems
bfleischer has quit [Client Quit]
markstarkman has joined #rubygems
markstarkman has quit [Read error: Connection reset by peer]
<raggi>
imperator: which i'm studying, while everyone else absorbs the doc we put together describing the problem domain, here: http://goo.gl/ybFIO
<raggi>
i fear that TUF might be a little complex/heavy, but it depends really if we want a better trust model, or just to give the impression fo a better model
<raggi>
"just plain signing" is really the latter, if you study the content of the problem domain
the_mentat has quit [Quit: Computer has gone to sleep.]
vertis has joined #rubygems
jcaudle has quit [Quit: jcaudle]
_br_ has quit [Excess Flood]
<imperator>
thanks for the info and links, i'll take a look
the_mentat has joined #rubygems
ctracey has quit [Ping timeout: 248 seconds]
_br_ has joined #rubygems
vertis has quit [Read error: Connection reset by peer]
fromonesrc has quit [Quit: fromonesrc]
ctracey has joined #rubygems
teancom has joined #rubygems
vertis has joined #rubygems
stevenharman has quit [Ping timeout: 276 seconds]
vertis1 has joined #rubygems
vertis has quit [Ping timeout: 255 seconds]
cowboyd has joined #rubygems
markstarkman has quit [Remote host closed the connection]
Guest69243 has quit [Quit: Leaving...]
roolo has quit [Quit: Leaving...]
huoxito has quit [Ping timeout: 248 seconds]
huoxito has joined #rubygems
stevenharman has joined #rubygems
vertis has joined #rubygems
vertis1 has quit [Ping timeout: 252 seconds]
cowboyd has quit [Remote host closed the connection]