The question a lot of people were asking was: What about stable (or Wheezy). After way too much time due to other pressing issues, I have just uploaded the patched WordPress debian package for stable. The fixed version has the catchy number of 3.6.1~deb7u5. This package has all of the relevant patches that went in from WordPress 3.7.4 to 3.7.5 and there are even CVE IDs for this package (and 4.0.1 which all this stems from).
The Debian package of WordPress version 3.9.1 was uploaded to the ftp master recently. While the update was pretty simple, the upload took a lot more doing. I’m not sure why the Debian ftp-master server didn’t like me, but it was so slow. Strangely, even dcut uploads were slow and they are only a few lines of text.
Apologies for the delay too, I’m not sure why I didn’t notice the update from 3.9 to 3.9.1 but there you go.
The other change is that the package uses the system CA certificates rather than the ones pre-shipped with wordpress. This is done so that if the administrator makes decisions on what certificates to trust, then the wordpress client http libraries will follow that decision.
Well if you can read this then you know it’s working. After way too many weeks, Debian will have WordPress version 3.8. Thanks to Raphaël for his kind assistance and answering my questions about how it was built. The upload is still gurgling along and will make it there in its own time. He said Handing over packages is hard, I’d agree but say taking over them is too.
So, what does WordPress 3.8 look like? From the “frontend” I didn’t really notice much. The big changes, at least cosmetically, seem to be for the admin backend. It just look slicker and cleaner.
Hopefully Debian users find the update useful and I’ve not broken anything. There’s always the BTS if there is. I’ve deliberately tried to minimise the changes for this version to limit the breakage.
Debian sysvint-utils package will continue to have that file. That stops any messy procps splits and putting one part into Essential etc.
This may mean that one distributions pidof doesn’t quite work like anothers, but that has been like that already; which is why when I discussed the change as upstream I wondered where they found some of those flags I don’t have.
There are plans to move all utilities that use the proc filesystem under one package which will make the maintenance of them simpler, which in effect means moving pidof from sysvinit-tools to procps. The short-term bump should make it better in the long term.
Now as I wear two hats (Debian maintainer and procps upstream) there are two very important things I/we need to know.
- If your Debian package depends on pidof being present, then we need to discuss dependencies. procps is generally installed on most systems but there might be corner cases. Possibly just depending on a specific version of procps will do it
- If you, your Debian package or anything else (including other distributions) need the non-LSB options of pidof (ie they use -c -n or -m) then we (upstream) need to know about it. There are provisional plans not to support these options but they’re needed, or a subset is, then that could change.