[12:27] <apw> @pilot out
[12:28] <infinity> @pilot out
[12:35] <xnox> barry: what is the "right" solution when unit-tests rely on dict ordering?
[12:36] <xnox> barry: use ordereddict in the unit-test or make the code use ordereddicts? or compare taking into account that it could be slightly "random"
[12:36] <xnox> ?
[12:38] <jtaylor> sort the result what is expected to be non-random?
[12:47] <barry> xnox: sort
[12:51] <xnox> barry: hmm... well looking into subunit build-failure it compares the final output which embeds pieces of random string. I'd rather not mangle that output but make subunit return sorted output in that field.
[12:52] <xnox> otherwise the tests that use subunit will have to change depending if it's 3.2 or 3.3
[12:53] <xnox> barry: also strangely we see hash ordering on 32 bit platforms, but not 64 bit...
[13:25] <xnox> barry: jtaylor: please review for sanity https://code.launchpad.net/~xnox/subunit/hash-ordering/+merge/131732
[14:13] <stedi> Hi, I need to "serialize" package versions version and revision parts (epoch is easy enough) so I can pick latest among several candidates using ordinary sort functionality (in databases). I have looked at verrevcmp function but am hesitant about just appending several order() results into a string of unsigned shorts. Or would this work?
[17:46] <alexbligh1> I have an apache module packaged for debian. It has a conf file /etc/apache2/mods-available/mymodule.load. When I remove it (but not purge it), it leaves the conffile there, which is as expected I guess. However, this variously breaks apache. How do I ensure it is removed on a package remove? I guess I'm asking for it either to be treated not as a conf file, or removed if it is unchanged. This is for Lucid.
[17:47] <alexbligh1> (if I rm it from my prerm script, it thinks the user has changed it, which in turn means reinstalling it won't reinstall the conf file)
[17:54] <jelmer> alexbligh1: it shouldn't be an issue if the file is just in /etc/apache2/mods-available if the module is not installed
[17:54] <jelmer> alexbligh1: only if the file is actually in /etc/apache2/mods-enabled (or symlinked there)
[17:57] <alexbligh1> jelmer, hmm, that makes sense. I wonder why it is causing issues.
[17:58] <jelmer> alexbligh1: the apache log should be of help - a directive in that file isn't understood by apache?
[18:00] <alexbligh1> jelmer, I think the problem was that it wasn't doing the a2dismod, but removing the .so, and I got confused by the .load being there.
[18:00] <alexbligh1> thanks for your help
[18:01] <alexbligh1> ... though I'm sort of intrigued why they are conffiles anyway. Are they intended to be user editable?
[18:09] <xnox> alexbligh1: hmm... well mods-enabled has symlinks to conffiles in mods-available. And apache reads conffiles to get the names & system settings for a particular loadable .so. Apache doesn't know where to find them and which onces to load and which onces not to load =)
[18:13] <alexbligh1> xnox, no I meant why is the .load file a conffile (or, if you prefer why is mods-available in /etc/ not a symlink to elsewhere, or the files copied in on postinst and removed in prerm), given they are not user editable as far as I can tell, unlike (e.g.) sites-avaialble.
[18:13] <alexbligh1> as the .load file hanging around makes no sense if the .so has gone.
[18:14] <xnox> alexbligh1: I don't see a reason to ever modify them, but maybe I am not advanced user.
[18:14] <xnox> no idea about handling.
[18:20] <alexbligh1> aaaah, for what it's worth the bug is that if you remove, but not purge, an apache module, then someone a2enmods it, then it successfully creates the link and a2enmod does not error, but reloading apache fails even if the module is not used :-/