Commit Graph

8 Commits

Author SHA1 Message Date
R. Ryantm
34657556d1 inspircd: 3.11.0 -> 3.12.0 2022-01-03 10:54:39 +01:00
sternenseemann
1d67a676d4 inspircd: 3.10.0 -> 3.11.0
https://docs.inspircd.org/3/change-log/#inspircd-3110
2021-09-13 15:00:45 +02:00
Domen Kožar
9e6417f2a4
fix tarball job evaluation for aarch64-darwin 2021-06-03 10:52:46 +02:00
sternenseemann
104af4aafa inspircd: run configure phase hooks 2021-05-14 23:02:20 +02:00
sternenseemann
abe7335e7e inspircd: 3.9.0 -> 3.10.0
https://docs.inspircd.org/3/change-log/#inspircd-3100
2021-05-14 23:02:20 +02:00
sternenseemann
19225b8690 !fixup add nixos tests to passthru.tests 2021-03-22 15:12:27 +01:00
Profpatsch
0fd939c6ea fixup! inspircd: init at 3.9.0 2021-03-21 14:14:32 +01:00
sternenseemann
b77f1bc48a inspircd: init at 3.9.0
Packaging inspircd is relatively straightforward, once we adapt to the
slightly strange Perl configure script and it's firm opinion that
$prefix/usr should exist.

Most complexity in this derivation stems from the following:

* inspircd has modules which users can load dynamically in the form of
  shared objects that link against other libraries for various tasks

* inspircd is licensed exclusively under the GPL version 2.

* Some of the libraries inspircd modules link against are GPL 2
  incompatible (GPL 3, ASL 2.0) and we therefore must not distribute
  these in binary form.

* Some modules combine GPL 2 code of inspircd and libc into a shared
  object and may not be redistributed in binary form depending on the
  license of the libc. Similarly for libc++.
  Open Question: Does the fact that we may build the inspircd binary, i.
  e. link against libc and libc++ imply that we can do this?
  https://docs.inspircd.org/packaging/ seems to imply this is not the
  case.

Thus we have some additional code which a) determines the set of modules
we should enable by default (the largest possible set as upstream
recommends it) and b) collects all applying licenses into meta.license.
2021-03-21 01:32:51 +01:00