Nothing amazing, just an update from 3.5.0 to 3.7.0, addressing a few Rails security bugs. Come bother us on #sourcemage on irc.freenode.net if you notice things not behaving well. Poke BeepDog specifically.
MySQL and this webapp weren't getting along terribly well. Perhaps it's because we were using the old mysql gem rather than the mysql2 gem.
Everything is now using mysql2 and we're running against a newer MySQL so hopefully things will be better now. Watching things happen, and they seem to mostly be in the ruby process space, not in the mysqld process space, so I suppose that's a good thing. I'd rather have ruby doing the work, than mysql clogging itself up.
MySQL didn't like it that we had a leap second a little while ago.
I remember hearing about a glitch in the linux kernel that caused things to bomb, but this is the first I'd heard about the same problem happening to mysql.
Solution found here: http://stackoverflow.com/a/11293475/423218
date -s "`date`"
Which I guess just forces the date to a point and gets it less freaked out. It's certainly made mysql a bit snappier, thankfully.
Source Mage General: Updated Chiliproject (1 comment)
Updating Chiliproject is easy! We're running the latest version now, and I haven't seen any problems.
Let BeepDog know on irc://irc.freenode.net/#sourcemage if there are any problems (Did I do an IRC url correctly?)
So a bit of ruby scripting fu later, and a rake task that I can re-run, and we've eliminated all the spam from the chiliproject site.
It completely destroys locked accounts and anything the locked account posted, files, comments issues, comments.
Then registered accounts that haven't been activated and are older than two weeks also get nuked.
Hooray for no spam.
A friendly internet denizen contacted me about epic buttons of spam on one of our news pages.
Sadly, the registration requiring email activation is no longer sufficient, as the spam bots have email accounts. Not surprising.
So the only solution for chiliproject, sadly (as well as most other things, including the wiki we're using) is to set up manual account activation.
Perhaps one day, I can work out a much better, much more integrated authentication framework using LDAP as the backend and tie in all the items into one account, and activate them more smarter.
Until then, sorry :(
See the release notes here: [[http://sourcemage.org/projects/sorcery/wiki/ReleaseNotes1150]]
Highlights from LynxLynxLynx:¶
- sorcery queue and queue-security are now much faster by avoiding disk IO (~10 times in my case) and optionally (default: VERBOSE_QUEUING=on) more verbose. It displays all the reasons why the particular spell is being put into the queue. For security updates it states if there was more than one.
- as a side effect, also cast -Z is much faster when searching for possible updates (look it up, it is very handy)
- partly improved resurrect: better resurrection and its integration into the casting process
- a new tool (called resurrect) specifically for dealing with resurrecting (downgrades, upgrades, cache manipulation)
- timing functionality. It can be accessed via gaze time, gaze time-system and their subcommands. The functions print various casting times. Especially gaze time --full can be useful for estimating future casting time.
- the spell's FINAL outputs are duplicated at the end of cast
- when a spell fails, a short reason for the failure is displayed in the summary
- improved cleanup algorithm when a spell fails in the dependency resolution part of cast
- conflicts and security questions are now asked during the dependency resolution phase
- the conflicts are then dispelled right before the spell is cast or resurrected
IMPORTANT: To get any of the benefits of staging, you need to install castfs.
IMPORTANT: Don't forget there is now a new cool tool called resurrect.
This release also marks a new development stream, so if you want to work on any (new) features, the time is right. Bugzilla, users and me are full of ideas. There are already a few projects submitted to bugzilla, but most need a bit more work and polish. In any case, there's plenty of fun or painful stuff to work on and I'd gladly help with any of it.
My plan for 1.16 is to work on (more or less) what is filed on bugzilla/chillizila, especially if it has attachments. And maybe the completion of improved resurrect.
Source Mage General: Big Fat Warning on Bugzilla (2 comments)
We need to get moved over from bugzilla to using the chiliproject based issue trackers to take advantage of the release planning. And in support of that, since I cannot simply make bugzilla read-only, I have added a Big Fat Warning(tm) to be displayed in bugzilla to remind people not to use it.
This is probably also a good time to review our process and make some improvements where necessary.
Thanks for your patience as we're all busy people, and we work to get this ironed out.
August seems like a good time for the next developer meeting. It will have been about 4 months since our last meeting, and we can check up on the status of things we decided to do that meeting, and plan on doing more new things.
I've created a wiki page here, that anyone in the Developer Group can edit and modify. Feel free to add items to the agenda that you feel need to be discussed by the entire project team.
Source Mage General: Chiliproject 2.0.0 (2 comments)
Our wonderful website/bugtracker/wiki contrapulator has gone through an upgrade!
As Chiliproject progresses and develops new features, I shall endeavor to keep it up to date, and that will require some down time. This most recent release was a major point change, and such took a long time to update.
The Chiliproject team is well on their way to bringing their project up to date with the latest Rails and Ruby technologies. This should result in a better, faster experience on the site for all of us.
Also available in: Atom