> It would be great if the automated update will only happen if 
> the page actually needs to be changed. Then we could run it in
> a cron job.

Thinking loudly (in the light of recent spam attacks):

I figure, we got to do something to prevent spammers abusing the site with XML-RPC, here is one solution I thought of:

• Maintain two copies of wikiconfig.py -- one with XML-RPC disabled & the other with XML-RPC enabled; the former is put to use & the latter kept somewhere else in the server.

And we can cook up a script to switch between the two wikiconfig.py files. Let us called this `xml-rpc-switch` script.

• If the cron job (to run the gns-deb-diff script) is run in the same server that hosts the wiki, then:

** The `xml-rpc-switch` script is run first to effectively enable XML-PRC (by switching to another wikiconfig.py)

** `gns-deb-diff` script is run.

** The `xml-rpc-switch` script is run to switch back to the old wikiconfig.py; effectively disabling XML-RPC again.

This way, we can enable XML-RPC only when the gns-deb-diff script is run. What do you think?

The xmlrpc frontend uses the same authorization process as the Web frontend, minus the textcha. I hoped that MoinMoin's plugin system could be of help, but that only allows creating new methods, not overriding xmlrpc to implement different authorization. So separate authorization would have to be implemented in MoinMoin itself. I suspect that's a bit of work.

Another option is setting up HTTP authentication for action=xmlrpc2 requests. I'll gladly take any Apache configuration hints you may have to that end. No sign of abuse so far, though.

There have been some more package updates. I've not tested your updated script, but the code makes sense. If you're up for it, do a live run of the script to see if it'll be friends with our wiki.

I had a closer look at xmlrpc again. I see that Debian have it disabled "to mitigate unspecified security issues" [1]. It's been disabled by default in MoinMoin since 1.9.1 for security reasons [2]. I didn't find any concrete reports of security issues. It at least lowers the barrier for spam attacks. It might also give some wiki editors adventurous ideas about massive editing.

I've enabled xmlrpc for now. Don't tell the spammers (though I hope the EditorGroup will remain a sufficient measure if they do find out). Use this feature sparingly and cautiously. And please help me look out for any suspicious activity on the wiki.

It would be great if the automated update will only happen if the page actually needs to be changed. Then we could run it in a cron job.

[1] http://anonscm.debian.org/gitweb/?p=collab-maint/wiki.debian.org.git;a=blob;f=etc/moin/wikiconfig.py;hb=HEAD
[2] http://moinmo.in/SecurityFixes

I remember I looked at XML-RPC for a bit as a potential aid in our wiki spam problem. I was concerned about security, but I don't remember if that was based on facts or just a feeling. I would have to delve into it again.

A MoinMacro would have to get it's data from Savannah's Loggerhead (Bazaar web interface). It can be very slow at times. I think this would make the page very slow to load.

I've updated the remaining packages, clarified a few others and added some which I apparently forgot to push to Savannah.

While I was helping someone to submit a patch to us, there was some confusion about the Changed-From-Debian field. It was not clear from the wiki page for this person if the field could be multiple lines or just one. I think it would be good if you could specify that and make the example line a bit shorter so that it doesn't wrap.

I added a README.gNewSense to bacula by way of test. I see that not all of them have been added/modified. Are you still working on them or should I do them? It's all the same to me.

Sorry, I must have misread. I thought the link field would be required in README.gNewSense.

I think you have write access to the bzr repo. If you're comfortable updating/creating the README.gNewSense files you can already start on it. Else I'll have a look at them in the weekend.

That looks good. The link is the same format for all packages, so you could just build that into the code. Then we won't need to maintain the More-Info-Link.

You should be able to infer the change type from the bzr checkouts, but adding the Change-Type to README.gNewSense is probably a quicker win.

Thanks for the feedback samgee.

The 'Name:Value' format makes sense.

So, we may follow a format like this:

Changed-From-Debian: A short one line description about how this package differs from the corresponding Debian package.
Change-Type: `Added', `Removed' or `Modified'.
More-Info-Link: http://bzr.savannah.gnu.org/lh/gnewsense/packages-parkes/packag-name/annotate/head:/debian/README.gNewSense

in the README.gNewSense file, which can then be converted to:

||Source Package||Change Type||Reason||
||package-name||[http://bzr.savannah.gnu.org/lh/gnewsense/packages-parkes/packag-name/annotate/head:/debian/README.gNewSense|Modified]||A short one line description abou\
t how this package differs from the corresponding Debian package.||

I'll keep you posted on this.

I've started writing a script to automate the documentation of the difference between gNewSense & Debian.

Take a look: https://gitorious.org/gns-deb-diff/gns-deb-diff

I've attached a file, which contains the MoinMoin marked up table (it is not clean though) produced by the script.

Please read the README.md file & I'd like to hear your feedback.

Thanks.

(file #29886)

I suggest using http://www.gnewsense.org/Documentation/3/DifferencesWithDebian.

I had thought about a simple format like the following, but you can use the Libreplanet one if you like.

||Package||Difference||
||GNOME Display Manager||Branding||
||XChat||Removed references to non-free software||

See Michał's answer for information about our modifications.

We should have a list of differences between Debian and gNewSense. It should show the reason for each removed or modified package, in a concise and user-readable way.

I would love for an automatic way to do this (i.e. from blacklist and README.gNewSense files), but I don't have a quick fix for that, so we'd better start with a manual list on the wiki.