fortune-mod propagates various non-nice things

Hi guix,

fortune-mod currently propagates (in the non-technical sense) various

non-nice things like objectification, misogeny, religious intolerance,

anti-mathematician-ism (?) and date rape. That is not an exhaustive

list, these are just the first few things I encountered with "fortune

off".

To reproduce the issue, run "fortune off" a few times. Or just

"fortune", though then it can take a bit longer.

There are also a few non-nice things in the non-off set. E.g.:

$ fortune

# ^ from 'definitions'

As such, just removing 'off' doesn't seem sufficient. Unless Someone™

volunteers to remove the anti-fortunes (*), I would just remove

'fortune-mod', given that it seems to serve no practical purpose byond

being non-nice. WDYT?

(*) Fortunes don't have to be positive, but that doesn't mean they need

to be sexist (genderist?) or insulting either (e.g.:

Hence, anti-fortunes instead of fortunes.

Greeting,

Maxime

Hi Maxime,

Am Sonntag, dem 03.04.2022 um 15:09 +0200 schrieb Maxime Devos:

Well, the purpose of "fortune off" is to provide offensive "jokes". As

such, if you're offended by them, you're kinda getting what you've

asked for. If removing them falls under what our CoC states, though,

then so be it, I have no horse in this race.

More importantly...

I think this should be reported upstream. From what I could gather in

a short time, upstream appears both active (last commit 18 days ago)

and willing to make adjustments for "political correctness" (some two

years ago, they removed a lot of blonde jokes, though some simply got

demoted to still sexist jokes about women instead, and off is still

fair game for those, so...), so I think talking will get us further

than one-sided deletion here.

I don't think practical purpose is a bar we can set. What should we do

with all of the Rust ecosystem otherwise?

(For Rust fans, who were offended by the above, consider collecting

this and other quotes from yours truly in a new offensive/rust file and

we can both be happy.)

As for being non-nice on purpose, I disagree. It's rather a shame if

the supposedly inoffensive set is still offensive. And if lack of

humor is a concern, "A nuclear war can ruin your whole day." from

politics sounds just about fine to me :)

Cheers

Liliana Marie Prikler schreef op zo 03-04-2022 om 19:26 [+0200]:

Replace cargo with something else, then it can become more practical.

See, e.g., the ‘Compiling rust things without cargo (super WIP POC)’

thread on guix-devel@gnu.org. Once it is complete, rust would have a

build system that works well within Guix, so then we could benefit from

Rust's safety features (and macros, generic types, etc.) without the

downsides of cargo-build-system. Doesn't change the Rust bootstrap

length though ...

Greetings,

Maaxime.

Maxime Devos schreef op zo 03-04-2022 om 15:09 [+0200]:

Correction: looks like just running "fortune" without "off" doesn't

include the things from 'off'.

Greetings,

Maxime.

Liliana Marie Prikler schreef op zo 03-04-2022 om 19:26 [+0200]:

Done: https://github.com/shlomif/fortune-mod/issues/65

Greetings,

Maxime.

Liliana Marie Prikler schreef op zo 03-04-2022 om 19:26 [+0200]:

Looks like upstream disagrees:

https://github.com/shlomif/fortune-mod/issues/65#issuecomment-1087300204.

Greetings,

Maxime.

Hi Maxime,

Maxime Devos <maximedevos@telenet.be> writes:

'off' here apparently means the 'offensive' database, as explained by

Liliana; seems it offends alright :-).

The GNU FSDG has says nothing about what programs may or may not

contain, for a good reason: the line to draw could get very subjective

(similar to how the GPL ).

I don't think we should judge our software on terms falling outside of

the Free Software Distribution Guidelines, but a simple thing we could

add here would be a note in the description to caution the user that

running

@example

fortune off

@end example

is intended to be offensive.

What do you think?

Thanks,

Maxim

Maxim Cournoyer <maxim.cournoyer@gmail.com> writes:

Honestly this is dumb, it's not even practically useful software. We

have no obligation to package something that jokes about date rape and

contributes nothing of practical value.

This is very different to the reasoning behind the lack of moral clauses

in the GPL. And again, just because something is free software, we don't have to

package it.

It's a ticking PR timebomb and nothing of value would be lost if we got

rid of that file. If some snowflake gets triggered because we removed

their favorite date rape joke, they self identified as someone whose

opinion we should ignore. :P

Hi Csepp,

Csepp <raingloom@riseup.net> writes:

Thanks for the criticism. I admit I hadn't run 'fortune off' myself or

researched much on what it contains; after reading more about it,

especially considering these notes about the 'Offensive' database [0]:

But the most explicit recommendation is:

I now think we should act on it :-)

Would you like to prepare a patch stripping out the offensive database

file?

Thanks,

Maxim

[0] https://github.com/shlomif/fortune-mod/blob/master/fortune-mod/Offensive

---

gnu/packages/games.scm | 5 ++++-

1 file changed, 4 insertions(+), 1 deletion(-)

Liliana Marie Prikler <liliana.prikler@student.tugraz.at> writes:

That's probably better done as a fork of upstream. If no one wants to do

that, I wouldn't miss the package if it got yeeted. :shrug:

Am Samstag, dem 16.07.2022 um 15:40 +0200 schrieb Csepp:

I'm not necessarily asking you to go over joke for joke; that would

need to be a collective decision of Guix folk anyway. Right now I just

want to (1) make that a snippet and (2) also take a critical look at

the files not labeled "offensive".

Cheers

merge 56599 54691

thanks

Am Samstag, dem 16.07.2022 um 14:21 +0200 schrieb raingloom:

Truly offensive files should be removed with a snippet rather than a

funnily named phase. I'm not sure if this applies to all of off, but

let it be said, that there's plenty of fortunes that'd violate the CoC

in files not labeled as such. Some files could probably be salvaged if

we only removed some quotes – for example limericks about numbers are

probably fine, but other limericks aren't. Furthermore, we should also

revise the list of fortunes not in off, men-women is just an alternate

spelling of sexism.

Cheers

Liliana Marie Prikler <liliana.prikler@gmail.com> writes:

Doing it before the install phase requires also patching the build

scripts. There are a bunch of other bugs calling me sadly, so I'm not

super keen on putting more energy into this one.

On 14-07-2022 16:55, Maxim Cournoyer wrote:

Unfortunately, these kind 'fortunes' are not limited to the 'off'

section, so this is not sufficient -- they also appear outside. I also

already provided a patch for removing some of the bad fortunes, but it

was rejected upstream. Even then, that was for only one of the fortunes,

most likely there are a lot more bad fortunes that aren't contained in

the 'off' section. I am not interested in going through every fortune to

filter out the bad ones, so I will not prepare a patch.

Greetings,

Maxime

On 03-04-2022 19:26, Liliana Marie Prikler wrote:

My point wasn't that some individual could accidentally install a

package that offends them.  My point was that:

More concretely, consider the target audience for such "jokes" instead

of some random individual.

By including such jokes:

* we implicitly validate that such views are reasonable (people

holding those views get validation, unknowing people are nudged into

considering such views and people rejecting these views are invalidated)

* As such, we contribute to keeping those vile -isms intact and making

them more common.

I do not believe this to be a good course of action.

Something can be said about the individuals too, w.r.t. internalised

$BAD-isms, negative impact on mental health, possibly some other things

too?). I don't believe inflicting those to be a good idea either.

Csepp <raingloom@riseup.net>

Exactly, though myself I prefer to reason in terms of "what is / what

changes / consequences / ..." instead of "how are our actions perceived".

(/me catches up on other responses, haven't read them all yet)

Greetings,

Maxime.

On 14-07-2022 03:30, Maxim Cournoyer wrote:

I believe criteria like the FSDG to be important, but not the only

important criteria -- free software does not live in a vacuum. In this

case, I believe the absence of misogeny, etc., to be important and

choosing to further those (*) to be straight-out unethical.

Also, it is already policy to take such things in account, e.g. it has

been codified in CODE-OF-CONDUCT to some degree, though I want to be

clear that even if it wasn't codified, it should be policy anyways.  So

far, the principles behind things like CODE-OF-CONDUCT haven't been

applied to the contents of package but I see no reason they shouldn't be.

(*) here I consider choosing to take no action to be a choice.

Also, I would like to note that nobody here seems to actually want the

fortune-mod or disagrees that those "jokes" are vile and serve no useful

purpose, so it's not like removing it would cause fragmentation, so that

potential issue you seem to be referring to (or maybe I'm reading to

much in your response?) does not seem to apply here.

Greetings,

Maxime.

Am Dienstag, dem 19.07.2022 um 21:20 +0200 schrieb Maxime Devos:

I do get where you're coming from. However, I'd argue that the issue

with the current fortune-mod is that it doesn't really have a code of

conduct, or at best a poorly conceived one. Even if we removed

obviously bad stuff like misogyny, religious intolerance and date rape,

there are other points of contention. For example, the user one you

mentioned was not even listed in off, even though it might be

classified as offensive (a harmless offense, if you ask me, but

anyway). All sorts of "punching up" jokes against incompetent

politicians would also be offensive to those politicians and their

followers even if propagating them towards greater society would be a

good thing. There's probably more to add here.

Thus, my point is that we ought to consider a code of conduct while

we're choosing which themes fortune-mod is allowed to propagate and

which not (in particular our own might be a starting point). If we

find that patching fortune-mod is too hard as raingloom implied, we

might instead use a more CoC-friendly fork.

Cheers

On 20-07-2022 06:31, Liliana Marie Prikler wrote:

Like I wrote in my previous reply, I never based my reasoning on why

things are bad here on offense (and also not on the CoC itself but on

the principles behind those things), though it seems you are arriving at

about the same conclusion via a different method?

Moving to a friendly fork would be an option, but we need a fork for

that, and I'm not finding a clear choice -- I only found those on

https://www.shlomifish.org/humour/fortunes/, but most of the time they

are often rather specific (e.g.: 'The #kernelnewbies fortune file', not

an unified collection with lots of quotes on lots of things, so no clear

fork springs out.

There's maybe https://github.com/JKirchartz/fortunes, which at first

sight doesn't seem bad and seems to have lots of things, so if someone

wants to preserve fortune, they can write a patch to switch to that

fortunes database?

Greetings,

Maxime.

Am Mittwoch, dem 20.07.2022 um 10:45 +0200 schrieb Maxime Devos:

I think there's two problems to tackle here. First, fortune-mod does

not support an environment like FORTUNE_PATH and it'd be difficult to

patch it to do so (trust me, I've looked at the code and it's

horrible). Second, we need quotes replacements – once FORTUNE_PATH is

implemented, we could even have separate packages, provided that all of

them pass our QA.

In order to solve the first problem, I'll clear my mind and come up

with an alternative set of fortune tools (ideally once to which we can

apply the GPL3 rather than the BSD4).

Would you be willing to do a complete evaluation of this database? If

you find that it is indeed better than the one packaged by shlomifish,

replacing them would be easy. First, add a snippet to the origin of

fortune-mod to delete the datfiles, second add a phase to install

JKirchartz'.

Cheers

On 20-07-2022 18:57, Liliana Marie Prikler wrote:

I looked diagonally through the files, and almost all of them seem fine.

The rest seems to be more a manner of difference in opinion and context

(e.g., see Bakunin on the State and on religion). The closest thing to

something like 'stupid users' seems to be in ComputerDictionary, but it

seems rather mild and doesn't hint at some kind of superiority.

FerengiRulesOfAcquisition is ... nothing I would recommend, but mild and

doesn't really target anyone and also, context.

There's also some 'my programming language is better than your

language', but those aren't serious IIUC.

It's not an exhaustive check, but so far the JKirchartz fortunes seem to

be well so far, so I'm not expecting large problems with the rest, maybe

tiny ones at worst.

Greetings,

Maxime

---

gnu/packages/toys.scm | 32 +++++++++++++++++++++++++++++++-

1 file changed, 31 insertions(+), 1 deletion(-)

---

gnu/packages/toys.scm | 49 +++++++++++++++++++++++++++++++++++++++++++

1 file changed, 49 insertions(+)

---

gnu/packages/games.scm | 73 ------------------------------------------

gnu/packages/toys.scm | 3 ++

2 files changed, 3 insertions(+), 73 deletions(-)

This origin was added for the now removed fortune-mod, so let's remove it

as well.

---

gnu/packages/games.scm | 10 ----------

1 file changed, 10 deletions(-)

This package was introduced as native input to the now removed fortune-mod,

so let's remove it as well.

---

gnu/packages/games.scm | 59 ------------------------------------------

1 file changed, 59 deletions(-)

On 23-07-2022 17:11, Liliana Marie Prikler wrote:

It's used in the Makefile, so I'd have expected native-inputs here --

does "guix build fortunes-jkirchartz --target=aarch64-linux-gnu" or such

work?

For the people who don't know yet what fortunes are yet, I'd recommend

adding that these fortunes can be read with the package 'daikichi'.

Greetings,

Maxime.

On 23-07-2022 17:11, Liliana Marie Prikler wrote:

This is a technically a possibility, but currently the convention is to

use numbers and the number convention is expected by (guix upstream) and

the (not yet merged, needs some finishing touches IIRC) latest-git

updater, and AFAIK there hasn't been any discussion on switching to dates.

Greetings,

Maxime.

On 23-07-2022 17:13, Liliana Marie Prikler wrote:

For future readers, I believe a link to the bug report to be in order.

Likewise.

Greetings,

Maxime.

Am Samstag, dem 23.07.2022 um 21:54 +0200 schrieb Maxime Devos:

That's what I tried to explain in the comment above. Because I'm using

native size and endianness, cross compilation only works if the two are

the same. For example, you could theoretically cross-compile from

x86_64 to aarch64 little endian, but not from aarch64 little endian to

aarch64 big endian. IMHO that restriction is big enough to practically

make it "not cross-compilable".

That said, one of my first goals is to make it not so, particularly to

always store integers in network order (big endian), so that afterwards

only size is a concern.

Well, the command to read those fortunes remains "fortune" even if the

package we use is daikichi. I'm not sure if "Fortunes can be read by

the fortune command" are helpful, but perhaps "a large collection of

quotes to display with @command{fortune}" is?

Am Samstag, dem 23.07.2022 um 21:56 +0200 schrieb Maxime Devos:

In this case I am departing from the usual convention because I think

calendar versioning is more useful for this type of content. Given the

issue that lead to this patch at all, I'm not sure if support for

automatic updates would be a good idea with this package. IMHO, it's a

feature rather than a bug that you can't accidentally pull a third of

BSD's offensive database, were it to ever land in this repo.

Should I explain this thought more clearly in the package or do

automatic updates trump ethical concerns?

Am Samstag, dem 23.07.2022 um 21:58 +0200 schrieb Maxime Devos:

Will do.

On 23-07-2022 22:43, Liliana Marie Prikler wrote:

OK, I read over the the comment that it's not cross-compilable. But now

you are writing it is cross-compilable in restricted contexts. So "guix

build --target=aarch64-linux-gnu --system=x86_64-linux-gnu" should work

(IIUC they have the same sizes and endianness, though not 100% sure).

(Unfortunately there is currently not a method to specify that packages

are not cross-compilable in restricted contexts ...)

However, that's was I was trying to say -- what I tried to say, is that

by sorting the inputs incorrectly it _becomes_ not cross-compilable, so

once daikichi supports cross-compilation you (generic you, not you in

particular) will have to modify the package to move daikichi to

native-inputs, and in the mean time people are misled by this package

definition on how native / non-native works. Actually, this not only

applies to the future, but to the present, because IIUC aarch64 and

x86_64 are sufficiently similar for "guix build

--target=aarch64-linux-gnu --system=x86_64-linux-gnu" to be able to work

except for daikichi being compiled for the wrong architecture currently.

Even better would be if daikichi had a cross-compiler mode, where you

can compile to another endianness or size. (Or simpler, work with a

fixed endianness and integer size such that cross-compilation concerns

disappear entirely, but there's more than one way to do it.)

Another problem is that currently it is propagated, but daikichi is not

a dependency of fortunes-jkirchartz.

Greetings,

Maxime.

Hi,

Am Samstag, dem 23.07.2022 um 23:41 +0200 schrieb Maxime Devos:

Fair enough, I'll include it in the native-inputs.

We're speaking of a hack job done in a few evenings here, but I think a

cross-compiler mode will be more feasible than fixed sizes (assuming

that we won't cross-compile to larger integer sizes than supported by

the host, which I think is a fair assumption to make).

Well, it is a dependency in that you need a fortune program to read the

quotes. Should I instead add a meta-package that propagates both?

On 23-07-2022 22:53, Liliana Marie Prikler wrote:

OK, but Guix seems to have decided on numbering in the past, I don't

think a package patch is a place to change that policy. If you want to

change things to calendar versioning for some kinds of git stuff, this

sounds like something to be discussed and approved or disapproved on

guix-devel@gnu.org, not here.

As mentioned later, "guix refresh -u" != automatic updates. I expect

that a person manually updating the package would prefer the aid of

"guix refresh -u" instead of having to clone the git repo by theirselves

and do "guix hash -r", maybe forget the "-x", then remembering that "-r"

is deprecated then having to look in the manual for --serializer=nix.

Guix does not have automatic updates, it does not decide by itself to

update some packaes without any review. The updaters are only run when

done so manually, e.g. with "guix refresh -u fortunes-jkirchartz". In

that case, as always though it seems to be neglected due to limited

resources currently, the diff between the previous version and the new

version should be verified for malware.  There's no X trumps Y here, AFAICT.

Also, if Guix decides on CalVer for some packages, then in the context

of the latest-git updater, the latest-git updater will have to be

modified to support CalVer -- latest-git has no idea about how

individual packages work, so it cannot decide to block updates. As such,

going for CalVer to prevent generic-git from updating (with guix refresh

-u or --with-latest) does not seem robust to me, as it will just be

updated anyway with future improvements to latest-git.

If you want to block updates to some degree for some packages, then you

could look into, say, adding a (updatable? . #false) flag or such for

the 'properties' field or maybe add a comment next to the package

definition to ask people updating the package to look out for

fortunes-mod-style badness.

Greetings,

Maxime.

On 23-07-2022 23:52, Liliana Marie Prikler wrote:

I think it's a situation like 'man-pages' and 'man-db'. 'man-pages' has

lots of man pages and 'man-db' has a reader for man pages, but this does

not make man-db a dependency of man-pages. (Similarly, IceCat is not a

dependency of the web page https://guix.gnu.org). OTOH, daikichi is the

only reader for the fortunes so the situation becomes a bit incomparable.

I suppose there's some convenience in propagating daikichi, but

currently AFAICT the policy for those situations appears to be to not

propagate it (and neither create a meta package reader+information), so

unless there's some agreement on guix-devel@gnu.org to change that

policy to go for meta packages or propagation, I don't think the

individual fortunes-jkirchartz package should do that.

Greetings,

Maxime.

---

gnu/packages/toys.scm | 32 +++++++++++++++++++++++++++++++-

1 file changed, 31 insertions(+), 1 deletion(-)

---

gnu/packages/toys.scm | 51 +++++++++++++++++++++++++++++++++++++++++++

1 file changed, 51 insertions(+)

This package was introduced as native input to the now removed fortune-mod,

so let's remove it as well.

---

gnu/packages/games.scm | 59 ------------------------------------------

1 file changed, 59 deletions(-)

Since the addition of fortune-jkirchartz, it is no longer necessary to

keep around a package that propagates various non-nice things.

For a complete list, see https://bugs.gnu.org/54691.

---

gnu/packages/games.scm | 73 ------------------------------------------

1 file changed, 73 deletions(-)

This origin was added for the now removed fortune-mod, so let's remove it

as well.

---

gnu/packages/games.scm | 10 ----------

1 file changed, 10 deletions(-)

Hi,

On +2022-07-23 22:53:59 +0200, Liliana Marie Prikler wrote:

I like the YYYY.MM.DD format to tag data with a version

cookie, but I sometimes (not often) wind up with more than

one version in a day, so I like to allow at least an optional

single lower case [a-z] suffix, e.g., (revision "2022.05.23b")

just 2¢ :)

--

Regards,

Bengt Richter

On Sat Jul 23, 2022 at 4:16 PM BST, Liliana Marie Prikler wrote:

This package seems potentially useful by itself; should we really be

removing libraries just because they're leaves?

-- (

Am Sonntag, dem 24.07.2022 um 11:33 +0100 schrieb (:

Normally, I'd argue "no", but in this case I'm not really sure if

they're that useful. Both this package and the one after were IIUC

unbundled git submodules, so my guess is they're not.

Hi,

Liliana Marie Prikler <liliana.prikler@gmail.com> skribis:

[...]

(Perhaps also make “fortune-mod” a deprecated name for

“fortune-jkirchartz”.)

FWIW I’m fine with this change. Note that there’s also another patch

that removes the ‘off’ database of ‘fortune-mod’¹, though I don’t know

whether that would fully address the issues raised in this thread. It

will have to closed if/once this series is applied.

Thanks,

Ludo’.

¹ https://issues.guix.gnu.org/56599

Hi Ludo,

Am Mittwoch, dem 03.08.2022 um 15:43 +0200 schrieb Ludovic Courtès:

I'm getting mixed messages here. On the one hand, Maxime suggests not

propagating daikichi from fortune-jkirchartz (which makes it a plain

data package lacking a `fortune' command), on the other we want to mark

fortune-mod as deprecated. These are mutually exclusive options.

IIRC, I responded to such a patch already, though perhaps not that

thread in particular. To summarize, fortune-mod also propagates non-

nice things outside of ‘off’, so removing it is not enough.

Cheers

Hi,

Liliana Marie Prikler <liliana.prikler@gmail.com> skribis:

To me use of ‘deprecated-package’ in this case is just to ensure that

users who run ‘guix upgrade’ will transparently get

‘fortune-jkirchartz’. I don’t have a strong opinion though.

Alright, let’s remove ‘fortune-mod’ then.

Thanks for taking care of it!

Ludo’.

I believe what Liliana meant is that it's worse to 'transparently' upgrade to a data package that doesn't provide the 'fortune' command at all (or conversely, an implementation of the command that doesn't propagate the actual fortune data), than it is to signal to users through an error message that something's up and they need to stop and think.

(Er, that's a lot more words to put in someone's mouth than I intended to, sorry :-)

I'd suggest a news item but I really don't think this warrants it.

Kind regards,

T G-R

Sent on the go. Excuse or enjoy my brevity.

Am Donnerstag, dem 04.08.2022 um 15:37 +0000 schrieb Tobias Geerinckx-

Rice:

I'm not saying either option is worse than the other, just that we

can't pick both in a manner that provides a functioning package, and

that transparently upgrading to a package that does nothing is a pretty

bad option. We could transparently upgrade to daikichi, but that'd

just say "no fortunes found" because FORTUNE_PATH will be empty. Other

options would include a metapackage (also rejected by Maxime) or

providing a dummy fortune-mod package that fails at build with a

helpful message and is disabled in CI (came up as a shower thought).

Cheers

Hi Liliana,

Liliana Marie Prikler ???

I see; thanks for the clarification.

Then I *will* say that transparently upgrading to a package that

does nothing is worse than simple removal.

In fact, all of the proposed hacks are…

Kind regards,

T G-R

Hi,

On +2022-08-04 21:58:16 +0200, Tobias Geerinckx-Rice via Bug reports for GNU Guix wrote:

I hope the original is preserved somewhere for history's sake.

So where can I get a copy to see what all the fuss is about? :)

--

Regards,

Bengt Richter

It ain't what they call you, it's what you answer to.

-- W. C. Fields

Start every day off with a smile and get it over with.

-- W. C. Fields

On 07-08-2022 01:01, bokr@bokr.com wrote:

It's not merged yet IIUC, so you can just use the Guix package manager

to install the original.

For the history thing: we have "guix time-machine" and the SWH fallback.

Greetings,

Maxime.

---

guix/build-system/copy.scm | 2 ++

1 file changed, 2 insertions(+)

---

gnu/packages/toys.scm | 45 ++++++++++++++++++++++++++++++++++++++++++-

1 file changed, 44 insertions(+), 1 deletion(-)

Since the addition of fortune-jkirchartz, it is no longer necessary to

keep around a package that propagates various non-nice things.

For a complete list, see https://bugs.gnu.org/54691.

---

gnu/packages/games.scm | 73 ------------------------------------------

1 file changed, 73 deletions(-)

---

gnu/packages/toys.scm | 54 +++++++++++++++++++++++++++++++++++++++++++

1 file changed, 54 insertions(+)

This origin was added for the now removed fortune-mod, so let's remove it

as well.

---

gnu/packages/games.scm | 10 ----------

1 file changed, 10 deletions(-)

This package was introduced as native input to the now removed fortune-mod,

so let's remove it as well.

---

gnu/packages/games.scm | 59 ------------------------------------------

1 file changed, 59 deletions(-)

Am Samstag, dem 13.08.2022 um 11:26 +0200 schrieb Liliana Marie

Prikler:

I pushed this patch to core-updates and the rest to master; fortune-mod

is now removed and the replacement build (albeit with tests disabled

until the next c-u merge).

Cheers