ur5us has joined #jruby
enebo[m] has quit [Ping timeout: 246 seconds]
enebo[m]1 has joined #jruby
ur5us has quit [Ping timeout: 264 seconds]
ur5us has joined #jruby
ur5us has quit [Ping timeout: 264 seconds]
ur5us has joined #jruby
ur5us has quit [Ping timeout: 264 seconds]
jeremyevans has quit [Ping timeout: 256 seconds]
jeremyevans has joined #jruby
victori has quit [Ping timeout: 240 seconds]
victori has joined #jruby
<headius[m]> Release day!
<headius[m]> enebo: how are we looking
<enebo[m]1> I don't know yet
<headius[m]> How are you feeling about the kwargs fix now
<enebo[m]1> I just merged it
<enebo[m]1> I cannot think of any thing this could break based on notion that arity 1 in the presence of required kwargs would have an arity of 1
<enebo[m]1> I also do not fully grok if removing that line altogether would actually break anything
<enebo[m]1> It seems passing in extra arguments is ok already. I only half believe that though since procs which only actually contain one argument may expand BUT it is arity 1 and if it did expand then the extra arguments would be that
<enebo[m]1> My money is on this making a semantic difference in case of expecting one argument but it is a weird thing to do
<enebo[m]1> I mean it is still boxed and we are making a new array out of an old one when we could just pass the old one along
<enebo[m]1> I might remove that line after release is out to see what happens
<headius[m]> Yeah better safe there for now
<enebo[m]1> ok I was able to deploy to sonatype
<enebo[m]1> So not really sure what is different with travis and snapshot deploys
<enebo[m]1> Assuming it is only snapshot deploys for travis since we do not release from travis
<headius[m]> Yeah that is just a snapshot deploy and it is not failing for any logical reason
<headius[m]> And sometimes it succeeds
travis-ci has joined #jruby
<travis-ci> jruby/jruby (jruby-9.2:aa05fda by Thomas E. Enebo): The build was broken. https://travis-ci.com/jruby/jruby/builds/218140825 [169 min 1 sec]
travis-ci has left #jruby [#jruby]
<Freaky> hmm, FreeBSD port is rotting
<Freaky> still on 9.2.5.0, which doesn't even work on 12
<headius[m]> Oh wow
<headius[m]> enebo: I am having trouble finding things for release notes that aren't one-off fixes... there weren't really any big ticket items that deserve a separate note
<headius[m]> ok, I took the approach of adding notes for things we know multiple people saw or that broke significant usage like rails
<enebo[m]1> we can maybe just have the issue list plus a mention of rails find_by issue
<headius[m]> I am just adding links now
<enebo[m]1> ok
<headius[m]> oops
<headius[m]> will have links in place shortly
<enebo[m]1> ok
<enebo[m]1> Everything else I think is done other than github release and pushing site + emails + tweet
<enebo[m]1> If you can handle tweet and GH release that would be great
<enebo[m]1> maven has propped which is usually why this drags out :)
<headius[m]> links are all there now
<headius[m]> I will handle GH release and social media
<enebo[m]1> This renders nicely. I will push site and emails and then let heroku know
<headius[m]> let me know when side is pushed
<headius[m]> site
<enebo[m]1> ok
<enebo[m]1> site is live to me
<headius[m]> ok
enebo has joined #jruby
enebo has left #jruby [#jruby]
enebo has joined #jruby
<enebo> lol
<enebo> meh why you hate me nickserv
ChanServ changed the topic of #jruby to: Get 9.2.15.0! http://jruby.org/ | http://wiki.jruby.org | http://logs.jruby.org/jruby/ | http://bugs.jruby.org | Paste at http://gist.github.com
enebo has left #jruby [#jruby]
<enebo[m]1> too bad monkstone is not on here
<enebo[m]1> I untar jruby-bin and I see a bin/jruby
<headius[m]> yeah I am not sure what he is talking about
<headius[m]> probably unrelated to releaes
<headius[m]> release
<headius[m]> like and subscribe
<enebo[m]1> oh this is your pre-release tweet
<enebo[m]1> I can say our build scripts have not changed in a long time so I would be surprised if he is noticing a change vs something which has always been however he is noticing it
<headius[m]> link must be wrong at least on banner
<enebo[m]1> oh heh ok. That is weird. I did a global replace
<headius[m]> both exe links are wrong
<enebo[m]1> fixed
<enebo[m]1> cool
<headius[m]> I think that is everything
<enebo[m]1> I already updated to 16-SNAPSHOT too
<headius[m]> ok
<headius[m]> enebo: could you try to scrub those bad tags from your repos?
<enebo[m]1> you have a script since you have done it n times
<headius[m]> no, did not expect to have to do it on a quarterly basis
<headius[m]> git tag -d tagname ; git push origin :tagname
<enebo[m]1> I mean git is sort of designed around not losing data
<enebo[m]1> but just the graal-vm tags?
<headius[m]> or in your case push enebo
<headius[m]> no the other old ones came back too
<enebo[m]1> I have no idea what ones you don't want
<headius[m]> hudson-whatever
<headius[m]> pretty much everything except the JRuby and jossl tags
<enebo[m]1> did kares remove them?
<headius[m]> not sure but they came back after your PR merge
<enebo[m]1> I am making a bigger point :)
<enebo[m]1> I mean if I remove them and you remove them and anyone else has them won't we all have to remove them agina?
<headius[m]> possible that he has them too kares please remove non-JRuby or jossl tags from your JRuby fork
<headius[m]> potentially yeah
<headius[m]> I don't have a good solution here
<enebo[m]1> we could just ignore them
<headius[m]> I could ignore the dirt on my floor too
<enebo[m]1> hahah
<enebo[m]1> well I don't think I can argue with that analogy
<enebo[m]1> If I have to keep sweeping these tags forever more I will decide I dislike that metaphor
<headius[m]> yeah I do not like how infectious tags are
<enebo[m]1> The -d works but pushing to enebo failed
<headius[m]> maybe they were only in your local?
<headius[m]> make sure you have the `:`
<enebo[m]1> I see them on github
<headius[m]> that is git for remove this tag or branch
<enebo[m]1> ok I missed the : but now it says enebo is not a git repo
<headius[m]> I am checking other forks
<headius[m]> oh well what is your remote called
<enebo[m]1> lol never mind
<headius[m]> I just call mine headius
<enebo[m]1> I was in a shallow clone for release and not my main repo
<enebo[m]1> which was a bit confusing because I could delete the tag :)
<enebo[m]1> ok worked
<headius[m]> another one that was on remote: Dirty-hackish-mkmf
<headius[m]> main repo is clean
<headius[m]> my repo is clean (looks like I have not even pushed tags there in a long time so newest was 9.1.0.0)
subbu is now known as subbu|lunch
<enebo[m]1> how about Dirty-hackish-mkmf?
<headius[m]> kill that one
<headius[m]> I did not have it locally but it was on jruby/jruby
<headius[m]> kares: you only have one bad tag in your repo: https://github.com/kares/jruby/releases/tag/hudson-whatever
<headius[m]> enebo: do you have an alias to push tags or something?
<headius[m]> I guess if you have the tags in yours and then need to push tags for a release or whatever it will get them
<headius[m]> still confused how they keep getting back into main
<enebo[m]1> I just did the worlds ugliest sh script just now
<enebo[m]1> b
<headius[m]> nice
<enebo[m]1> not even a loop
<enebo[m]1> but I will verify these are gone
<enebo[m]1> but I manually make and push release tags
<headius[m]> loop schmoop
<Freaky> Finished lang/jruby | jruby-9.2.15.0: Success
<enebo[m]1> looks like they are gone now
<headius[m]> oh we need to do docker
<headius[m]> Freaky: nice!
<headius[m]> we had someone maintaining some BSD jruby package but I think it was openbsd
<headius[m]> jeremyevans I believe maintains that one
<headius[m]> docker update is testing now
<headius[m]> that should do it
<headius[m]> I would love to automate all this more but automation is bad at error handling
ur5us has joined #jruby
<enebo[m]1> yay
<headius[m]> time to get 9.3 finished now
<enebo[m]1> I removed that line from BlockBody and spec:ruby:fast ran
<jeremyevans> headius[m]: Currently testing 9.2.15.0 on OpenBSD. The OpenBSD port should be committed this week if no problems occur.
<enebo[m]1> If this runs the guantlet I think I will make the change to master
<headius[m]> jeremyevans: great thank you... should we add you to the contact list for release day?
<headius[m]> Freaky: we could also ping you with release notification if you will continue updating the freebsd port
<headius[m]> I wonder how long docker hub takes to update after PR gets merged
<headius[m]> still points at 9.2.14 images
<headius[m]> aha I just realized it still points at cpuguy98 repo for issues, will fix
<enebo[m]1> merging jruby-9.2 into master...will be done soon
<enebo[m]1> headius: did you add encoding kwarg stuff to each_child_spec on jruby-9.2?
<headius[m]> enebo: yes
<enebo[m]1> ok
<Freaky> headius[m]: sure
<headius[m]> Freaky: jeremyevans: could you both add yourselves here? https://github.com/jruby/jruby/wiki/JRubyDistributions
<headius[m]> enebo: the release steps link to this page, are you actually contacting these peeps?
<headius[m]> most of these maintainers don't have contact links ☹️
<headius[m]> Wayne doesn't maintain RVM anymore either
<enebo[m]1> no
<headius[m]> I am going to send out a call to action on this list
<enebo[m]1> I contact terence so heroku is updated
<enebo[m]1> rvm magically happens
<enebo[m]1> Interestingly I have never edited that page
<Freaky> technically the maintainer is just ruby@FreeBSD.org, I'm just some guy submitting a patch
<jeremyevans> headius[m]: Sure, you can add me to the contact list
<headius[m]> enebo: maybe make a release@jruby.org mailing list we can maintain?
<enebo[m]1> headius: yeah it would be simpler than a markdown table where half the entries are not actionable
<headius[m]> I'm going to remove latest version from that table at least
<headius[m]> and most of the text above
<headius[m]> this will mostly be informational for others if we set up our own list, so just knowing someone maintains these packages is enough
<enebo[m]1> Part of me wonders if I have ever even viewed that page
<enebo[m]1> yeah having the info is great
<travis-ci> jruby/jruby (revert-6517-racc_gem_in_9.2:9ddcefa by Charles Oliver Nutter): The build has errored. https://travis-ci.com/jruby/jruby/builds/218167028 [22 min 37 sec]
travis-ci has joined #jruby
travis-ci has left #jruby [#jruby]
<jeremyevans> headius[m]: I edited the wiki page
<headius[m]> jeremyevans: thanks! Message enebo a preferred email address and we can put you on the release announcement list
<headius[m]> Freaky: ditto for you if you want to be on that list
<enebo[m]1> headius: so I did a merge but IOChannel was a little messy as there was another fix on master for read
<enebo[m]1> but now I see your new spec failing from an eof
<enebo[m]1> oh wait perhaps not
<enebo[m]1> this is each_child for dir
<enebo[m]1> ok cool
<headius[m]> you sorted it out?
<enebo[m]1> well I will try quickly
<enebo[m]1> It was not even a conflict so I will compare and see if it is obvious
<headius[m]> weird that that racc gem build ran... all I did was undelete and delete the old branch
<headius[m]> guess that counts as a travis trigger
subbu|lunch is now known as subbu
<enebo[m]1> lol. So diff on conflict seemingly excludes whitespace
<enebo[m]1> Or master version of specs has extra indentation
<enebo[m]1> ok merge had a couple of wrinkles but spec:ruby:fast completed locally so I think it is ok
<headius[m]> I am cleaning up some post-release items on 9.2 so I will be doing another merge when you are satisfied
<enebo[m]1> headius: if it passes I am satisfied. Only problems would be IOChannel/each_child for Dir but since fast completed I don't expect issues
<headius[m]> ok
travis-ci has joined #jruby
travis-ci has left #jruby [#jruby]
<travis-ci> jruby/jruby (master:b79d640 by Thomas E. Enebo): The build was broken. https://travis-ci.com/jruby/jruby/builds/218169773 [46 min 33 sec]
<enebo[m]1> lol
<enebo[m]1> I will fix that. I am confused how I passed tests
<enebo[m]1> I guess tabbing back and forth and typing 'oh' in intellij is not Java syntax
<enebo[m]1> The only time I dislike the autosave feature
<headius[m]> haha
<headius[m]> the only time I dislike it is when it doesn't crop trailing whitespace before saving
travis-ci has joined #jruby
travis-ci has left #jruby [#jruby]
<travis-ci> jruby/jruby (jruby-9.2:642378f by Charles Oliver Nutter): The build is still failing. https://travis-ci.com/jruby/jruby/builds/218169774 [181 min 23 sec]
<enebo[m]1> do those make sense to you? Were some unit tests added/removed in java?
<enebo[m]1> It appears on master we deleted some stuff that kares added as new unit tests on jruby-9.2?
<enebo[m]1> aha
<enebo[m]1> ok I think I can fix this quick
<enebo[m]1> appears to be a one word fix
travis-ci has joined #jruby
<travis-ci> jruby/jruby (master:0e6e5e5 by Thomas E. Enebo): The build is still failing. https://travis-ci.com/jruby/jruby/builds/218170729 [206 min 2 sec]
travis-ci has left #jruby [#jruby]
<headius[m]> so close
<enebo[m]1> lol
<enebo[m]1> now GHA still has a single failure with that new test on windows
<enebo[m]1> still waiting on travis
travis-ci has joined #jruby
travis-ci has left #jruby [#jruby]
<travis-ci> jruby/jruby (master:c9a1573 by Thomas E. Enebo): The build was fixed. https://travis-ci.com/jruby/jruby/builds/218173092 [207 min 38 sec]
<headius[m]> enebo: my merge is in now as well
<enebo[m]1> yeah I think we will be full green at this point...just waiting on travis but it passed last build
<enebo[m]1> I opened an up an issue on process spawn work of kares not running on windows CI
<headius[m]> ah which we didn't see because we are not running windows builds on 9.2 branch
<enebo[m]1> yeah
<enebo[m]1> so hooray for windows ci :)
travis-ci has joined #jruby
<travis-ci> jruby/jruby (master:380d249 by Thomas E. Enebo): The build was fixed. https://travis-ci.com/jruby/jruby/builds/218175194 [210 min 42 sec]
travis-ci has left #jruby [#jruby]
<enebo[m]1> hmm wish fixed test was green
travis-ci has joined #jruby
travis-ci has left #jruby [#jruby]
<travis-ci> jruby/jruby (master:d5e4f85 by Charles Oliver Nutter): The build was broken. https://travis-ci.com/jruby/jruby/builds/218176671 [206 min 35 sec]
<headius[m]> docker hub appears to be updated now
<headius[m]> sonuva, how are these json tests getting reverted again
ur5us_ has joined #jruby
ur5us has quit [Ping timeout: 264 seconds]
<headius[m]> those tests pass fine from json repo
<headius[m]> hmm
<headius[m]> ohhh wow I didn't notice those are psych failures
ur5us_ has quit [Ping timeout: 264 seconds]
ur5us has joined #jruby