So to make life a little easier, you now have to have an OpenID account to login to this site. Only users who have logged in can create/change tickets, wiki and post comments to my blog.
There are quite a few OpenID Providers, so it should be quite easy. You may already have an OpenID!
However, due to how the OpenID plugin works with Trac your username will look a little odd. This is because your OpenID is basically a FQDN, just like a web address. So it's best to use a provider like !http://
You can see from this post that my OpenID is roy.marples.name, which shows that having your own domain and OpenID server is important if you want to look good ;)
My Trac spam filters seem to have stopped working. So in an effort to tide the spam, this site now requires user registration to post tickets or edit the wiki's. One user account covers all trac projects, but you have preferences for each.
We'll see how it goes :)
A few programs in base system needed to be changed due to having their own getline function, most of which aren't anything like getline(3). Hopefully there won't be much fallout in pkgsrc as a result.
getline(3) is prefered over over functions such as fgetln(3) and fgets(3) because it's standards based and you get a dynamic buffer for really really long lines. However, POSIX did drop the ball on making it a standard from the GNU extension - it should return 0 on EOF and more importantly be called fgetline. Oh well.
I shall be rolling getline(3) support into dhcpcd later, but I'll have to do a link test in the Makefile to see if we can use it. I'm unsure if I want to have a mini configure for dhcpcd or to keep using just make extensions ....
So, I'm now finally natviely IPv6 enabled :)
This led to an interesting debtate about my internet connection. In a nutshell my Drayetk Vigor 100 is broken, but apparently by design. The problem is this - for IPv4 goes through my NAT whose public IP has an MTU of 1492 so Path MTU Discovery works fine. However IPv6 does not need NAT and the PPPoE interface does not have a public IPv6 and nor do the internal clients use it even it there was one. So the path MTU is 1500, which is too big for the PPPoE to handle.
The correct solution is to obviously terminate the IPv6 on a PPPoA connection, but only the Cisco 877 router does this and that's outside of my price range, even on eBay. One solution is to clamp the MSS on the router to 1430 so that all clients work. But this is a hack. The best solution with my hardware is to force the MTU to 1492 for all nodes inside my network, so they share the same MTU as the PPPoE so that Path MTU Discovery works.
You can see this working for yourself on IPv6 now, as this site is IPv6 enabled and sits behind the PPPoE link. You'll need to query IPv4 servers for the address though as I don't yet have a glue record for IPv6, but as I'm changing registrar that should change in a few weeks :)
Because of this, I've made the dhcpcd default to request and use the MTU value if offered by the DHCP server. You'll be seeing this in dhcpcd-5.0.5 (now out). dhcpcd-5.0.6 will feature restoring the MTU correctly between leases.