On Sat, 2025-07-26 at 13:48 +0100, Andrew Sayers wrote:
> On Sat, Jul 26, 2025 at 11:56:30AM +0800, Maytham Alsudany wrote:
> > On Fri, 2025-07-25 at 15:21 +0100, Andrew Sayers wrote:
> [...]
> > > ## DebianBug links
> > >
> > > https://wiki.debian.org/htdocs/bugstatus.js seems to handle [[DebianBug:]],
> > > [[https://bugs.debian.org/]], and apparently launchpad as well.
> > > The obvious MediaWiki equivalent is a gadget[2].
> > [...]
> >
> > The easiest way I found to do this (where this = adding a strikethrough
> > to closed bugs) is to run a very small service[9] to check the BTS and
> > render the necessary HTML, then add an InterWiki connection for that
> > service with "scary transclusion"[10] enabled. I've tested it on my
> > local MW instance and it works perfectly. MW also caches it, so it
> > doesn't contact the server on every page load.
> >
> > This also opens up new opportunities for things like incorporating
> > dynamic package data -- who knows?
>
> That's a really interesting approach. Some thoughts...
>
> https://wiki.debian.org/htdocs/bugstatus.js calls
> https://wiki.debian.org/cgi-bin/bugstatus?bug=<number>
> I'm not sure where to look for the source of that script, but I assume it
> uses the Debbugs SOAP interface[11], and presumably caches results?
https://salsa.debian.org/debian/wiki.debian.org/-/blob/master/bin/bugstatus
You are correct in that it uses the SOAP interface, but it doesn't cache
results.
> Speaking of caching, it would be nice to have a solution that's updated
> regularly without spamming the BTS server, but I don't see a
> "bugs updated since <date>" request in the SOAP interface.
> Anyone object to me submitting a wishlist bug against debbugs?
> Or am I better off asking on #debbugs instead?
>
> maytham explained on IRC that scary transclusion has a setting to control
> how often MW polls the service[12]. That seems like a good plan if we have
> to use the existing debbugs API, but if debbugs is upgraded to list recent
> changes, it would be nice to push those to the site a bit faster.
> How about a solution like this:
>
> 1. when the service is queried, it returns the result then edits
> Template:Debbugs/<number> with the same result
> 2. the service polls debbugs every 60 seconds for recent updates,
> and updates any existing Template:Debbugs/<number>
> 3. Template:DebianBug uses Template:Debbugs/<number> if it exists,
> or else scary-transcludes the service
>
> ... which would update links within a minute, without putting much load
> on either the BTS or wiki servers.
Wouldn't that just push caching away from the wiki's builtin system to
the wiki pages? Also seems like it would cause *more* traffic by
checking debbugs every 60 seconds, when MediaWiki only fetches
information on demand and caches information for up to 1 hour (by
default).
The BTS handles high traffic well, so I don't think this is an issue
that needs to be handled, as well as the fact caching already happens.
The caching period can be decreased, and InterWiki comes with a
maintenance script to clear all of its cache if needed.
> Finally, how about making the template returned by the service look like:
>
> {{
> {{{1}}}
> |summary=...
> |pending=...
> |id=...
> |severity=...
> ...
> }}}
>
> You could then call it like `{{raw:wiki:debbugs|<number>|MyHandler}}`,
> which would in turn call Template:MyHandler with the relevant parameters.
Do you mean add the ability to fetch different parameters from the bug
system? I don't think this is necessary since no wiki pages currently do
this and it would only duplicate information. Except maybe the bug title
can be in the link text when an option is passed?
Yet another interesting possibility that doesn't require running another
service is the External Data[13] extension, which can pretty much
achieve the same thing by accessing the BTS SOAP API directly and
fetching information. It also supports caching[14] and allows for
different caching expiry times for different URLs and hosts.
It can even fetch data from databases[15], which opens the possibility
for querying the UDD mirror (which is a PostreSQL database).
We can do some really cool stuff with this :)
--
Maytham
> > > [1] https://www.mediawiki.org/wiki/Manual:Interwiki
> > > [2] https://www.mediawiki.org/wiki/Extension:Gadgets
> > > [3] https://www.mediawiki.org/wiki/Extension:Emoticons
> > > [4] https://www.mediawiki.org/wiki/Manual:Table_of_contents#Depth
> > > [5] https://www.mediawiki.org/wiki/Extension:SyntaxHighlight
> > > [6] https://www.mediawiki.org/wiki/Template:Hint
> > [7] https://wiki2025.debian.org/wiki/Template:DebianIRC
> > [8] https://wiki2025.debian.org/wiki/User:Maytha8
> > [9] https://salsa.debian.org/Maytha8/iwservice
> > [10] https://www.mediawiki.org/wiki/Manual:$wgEnableScaryTranscluding
> [11] https://wiki.debian.org/DebbugsSoapInterface
> [12] https://www.mediawiki.org/wiki/Manual:$wgTranscludeCacheExpiry
[13] https://www.mediawiki.org/wiki/Extension:External_Data
[14] https://www.mediawiki.org/wiki/Extension:External_Data/Caching_data
[15] https://www.mediawiki.org/wiki/Extension:External_Data/Databases
Attachment:
signature.asc
Description: This is a digitally signed message part