gitsync master, then try option 13 again to upgrade.

Yes it is. Checked in without DEBUG

I can't get any email notification to work on 2.3-ALPHA. I have a config.xml section that looks like: <smtp><ipaddress>mail.company.co.uk</ipaddress> <port>465</port> <notifyemailaddress>phil.davis@company.co.uk</notifyemailaddress> <username>phil.davis@company.co.uk</username> <password>MyPasswordHere</password> <authentication_mechanism>PLAIN</authentication_mechanism> <fromaddress>phil.davis@company.co.uk</fromaddress></smtp> I have changed the FQDNs and password in the post above, of course. But the format is exactly as above. That works on a 2.2.5-DEVELOPMENT system (my home router). It does not work on my 2.3-ALPHA test system, using the same settings - the same errror in the system log as posted above. I switched slices on the 2.3-ALPHA test system back to 2.2.5-DEVELOPMENT and "Test SMTP" works fine - that is using the exact same config.xml from the 2.3-ALPHA system. I have compared /etc/inc/notices.inc on 2.2.5 and 2.3 and cannot see any functional difference. I don't think this is particularly about PLAIN and LOGIN authentication mechanism. Maybe something is not happy in the underlying SMTP library that is used? Does anyone else have working SMTP E-mail notification settings in 2.3-ALPHA?

It's also broken on AMD64. I have a bare metal box with 1 Realtec 8111 and a 4 port Broadcom.

Looks good Steve. I changed the thread subject to reflect the resolution. And thanks again for the all the quick work (I'll probably stop, or at least slow down, with all the thanks in my posts, but who knows).

Note: This may have been obvious to others, but since it wasn't obvious to me right away (and mostly in the case that it helps someone else): In order to upgrade via the console, you'll need to follow ariyako's directions and disable the extension. Console upgrades failed until I did that and then they worked as normal. Cheers.

Great ! Good luck with the dev. Up to now it's looking very promising… Thanks

@biggsy: There seems to be a collision between the parameter title and the checkbox in the first image. Maybe a wider space for the parameter title and less for the parameter would help.  many parameter areas do seem excessively wide. This seems to happen only in one of several viewport sizes. I'll look at it later today. @biggsy: The numeric increment/decrement scroll seems to be a bit pointless. Is anyone really going to scroll up/down rather than type most of the typical numbers?  Would the scroll even be usable on a mobile platform? Either way, it does seem that it's not applied consistently. This is a Bootstrap thing. When you make an input of type "number" the increment/decrement arrows automatically appear. In most cases they are not very useful, but the input validation provided is. They are not perfectly consistent because there are (mostly) numeric input fields that also need to accept text, and there it is not appropriate to use type = "number". @biggsy: This one has always made me wonder.  Is it not just IP version 6, rather than TCP/IP? Updated this morning via PR #1960 Thanks!

Tested and worked with : 2.3-ALPHA (amd64) built on Sat Oct 10 09:04:28 CDT 2015 FreeBSD 10.2-STABLE Thanks

Neither Snort nor Suricata will look good in the GUI (in fact they look awful since they don't have the proper Bootstrap CSS styles).  Also there are likely some other issues with the inclusion of JavaScript and other stuff.  In short, neither package is ready yet for use on pfSense 2.3.  I'm working on converting them to Bootstrap, but it is a slow process since I have some other commitments that are limiting the time I can spend on the packages. Bill

Thanks Steve, sounds good. And thanks for all the fast updates.

seems a lot more responsive also.

Fixed: pkg_mgr.php no longer displays packages that are already installed. Thanks for reporting this.

Merged. Thank you for the fix.

2.3-ALPHA (amd64) built on Thu Oct 08 19:06:50 CDT 2015 plus applying that change to /etc/inc/dyndns.class When I "Save & Force Update" it works, good entries are in the system log, no PHP errors or stack trace happens. Looks good, thanks.

We can add that as a feature request.

We are looking at going with d3.js and possibly one of it's frameworks. Overkill for a line chart, but leaves lot's of room for better data visualizations.

Ok cool. And as JimP said, it's easiest to save a lot of the big styling (finalizing colors, etc) for towards the end. We'll obviously be working towards cleaning things up, but it will be fairly easy with this new code structure to make big sweeping style changes with the css once it's done.