First try at porting to Mac, and a linker error
by Tobbi
Post via forum by Tobbi <tobbi@xxxxxxxxxx>:
Hello everyone,
I am trying to get TSC running on Mac (without Wine), and have started porting it. Whether it works or not, I cannot tell yet. However, you can find my changes here:
https://github.com/Secretchronicles/TSC/compare/devel...tobbi:fix_mac_com...
In any case: I keep getting a linker error, that looks like this:
[ 1%] Linking CXX executable tsc
ld: library not found for -lSDLmain
clang: error: linker command failed with exit code 1 (use -v to see invocation)
make[2]: *** [tsc] Error 1
make[1]: *** [CMakeFiles/tsc.dir/all] Error 2
make: *** [all] Error 2
--
Sent by Chessboard.
3 years, 10 months
Self-hosting the project
by Quintus
Hi everyone,
I. Overview
as has been disussed before in IRC for months, we want to switch our
project infrastructure completely over to alexandria, because GitHub
1) asks people to censor stuff
2) is not an open platform
3) tries to get a monopoly
4) may change their business model affecting all depandent projects
5) more reasons we mentioned in IRC I can’t think of right now.
For this to happen, we’re going to have to choose a project management
software setup. There will be quite some stuff for sydney to learn
during that course :-)
II. Requirements
It is fairly obvious that we’re going to host a Git daemon (see
git-daemon(1)) for read-only access to our repositories, but apart from
that we need to select the software we want. Before making suggestions
for that, we need to determine what we actually need. Looking at the
project, I think I derived the following requirements:
1. Repository source browser, including Git revision history. Best if it
contains syntax highlighting.
2. Ticket system, for bugs, feature requests, pull requests.
There are more requirements, but our existing infrastructure already
satisfies them:
3. Wiki for community content (Moinmoin).
4. Mailing lists and forum, best interconnected (mlmmj, Chessboard)
5. Main website including news posts with RSS (static HTML).
6. File upload/download facility for releases and for every team member
(project FTP and SFTP services).
I think points 4-6 work well enough that there’s no need to replace
them. If the software we chose has such facilities, they’d thus have to
be disabled; on the other hand, if it doesn’t have such facilities, this
is fine.
Point 3 is an eternal source of frustration currently. The old Moinmoin
wiki version we have wreaks havoc every now and then, requiring a hard
restart of the apache httpd daemon each time. Newer versions of Moinmoin
may not have that issue, so we shouldn’t ditch it without further
thought.
Regarding the tickets, GitHub appears to have a fairly good API that
allows to programmatically retrieve these[1]. The ticket system we use
should thus allow for automated import of existing tickets of some kind;
a quick one-time hack suffices. We won’t do that more often than once,
and can then forget about that. Writing a little script that fetches the
tickets from GitHub’s API and importing them into the new system
shouldn’t be too much effort.
Since our server sponsor extended our server’ſ capabilities a lot
(thanks for that again), we will have no resource shortage.
III. Software
I will not use Mantis.
Okay, that being said, the following software comes to mind. This list
is neither meant to be exhaustive, nor exclusive; there is more
software out there, and we may run some of these in parallel. Please
discuss.
1) Redmine: http://www.redmine.org/
2) Bugzilla: https://www.bugzilla.org/
3) Git’s builtin-repository browser, Gitweb.
4) Trac: http://trac.edgewall.org/
5) Flyspray: http://www.flyspray.org/
6) Selfhosted Gitlab: https://gitlab.com
I have experience with Redmine, and can say that it has some nice
features (like customisable ticket statuses, subprojects, private
projects and a milestone system. It is written in Ruby and licensed as
GPL, which is why I have a slight preference towards this.
Bugzilla (written in Perl, licensed as MPL) is known to very nicely
integrate with mailinglists for discussion and with bugzilla.mozilla.org
there is a really large power-user of this software that guarantees it
is rock-solid. I’d absolutely be fine with this one; Bugzilla to my
knowledge only provides the ticket system, though, so no builtin
repository browser (but there are separate ones like Gitweb). AFAIK
RedHat also uses Bugzilla for their bugtrackers.
Gitweb recently got syntax highlighting, so don’t say we can’t use it
because it has none. This should be considered if we use a tickets-only
software like Bugzilla or Flyspray. Gitweb is written in C and comes
with Git itself.
Trac is similar to Redmine, but I have never used it. It’ſ Python
software under the BSD license. Can someone elaborate?
Flyspray like Bugzilla is only a ticket system. It was used by our
server sponsor (now replaced by their own solution) and by the ArchLinux
development team. No stable release since 2012, though. PHP software,
but I was unable to determine the license.
Gitlab is basically like GitHub. It even looks similar. The software is
written in Ruby and licensed under BSD; you must sign a CLA to
contribute. Note Gitlab is a commercial company (not necessaryly bad),
and the version one can selfhost is a stripped-down “community
version”. Gitlab recently bought and shut down the popular Gitorious
service, which was a free (GPL!) alternative to GitHub. This generated a
lot of critical comments on their announcement, which they appear to
have simply deleted by now. I don’t want to work with a company with
such an attitude.
These are the things that come to my mind; Bugzilla and Flyspray are
lightweight solutions that only solve one problem and nothing more; the
others are fully-fledeged project management software programs that try
to be the one-size-fits-all solution. I have a preference towards
Redmine or Bugzilla, but please feel free to discuss the issue. Also
please mention more software, even if it is not directly related to the
core infrastructure.
Valete,
Quintus
[1]: https://developer.github.com/
--
#!/sbin/quintus
Blog: http://www.guelkerdev.de
GnuPG key: F1D8799FBCC8BC4F
3 years, 10 months
Web site accessibility in text broswer.
by Brian Allen Vanderburg II
I realize that this isn't a typical use case now-a-days. I have
installed links2 and accessed the website. On the main page, many of
the navigation links are not accessible. In fact, the only links in the
navigation that seem accessible are Home, and Language Finish. Looking
at the source HTML:
Instead of:
<a href="/en"><li>Home</li></a>
Shouldn't it be?
<li><a href="/en">Home</a></li>
I think this may be what is causing Links to display odd. It is showing
as a link the first link it finds under each list.
Brian Allen Vanderburg II
3 years, 11 months
Server resources upgrade
by Quintus
Hi everyone (and especially sydney),
our server sponsor asked me wether the resources they provide us with
are still sufficient or if we need an upgrade. I find that a very nice
attitude and it definitely makes me feel good that we chose them as our
server sponsor. Nice folks!
I thought about it, and I think the most important thing to ask them for
is more disk space that will allow us to keep more backups on the server
which can then be mirrored by multiple team members. If you don’t think
this is a good idea for whatever reason, please object (and explain).
I also think that I will ask them for a KVM machine. That would allow us
to use the OS of our own choice on the server, and will probably ease
upgrade pathes when new versions of our chosen distro are released
(rather then recurring to them every single time this situation
arises). This is a rather large demand given that they price their KVM
machines a lot more expensive than their OpenVZ ones. I cannot guarantee
they will grant us one, but I think we ought to ask. If not, please
object and explain.
Are there any further resource upgrades to approach them with? Do you
think the current specs are sufficient to host our bugtracking
etc. ourselves as has been discussed in IRC?
Vale,
Quintus
--
#!/sbin/quintus
Blog: http://www.guelkerdev.de
GnuPG key: F1D8799FBCC8BC4F
3 years, 11 months
Re: [tsc-devel] Server resources upgrade
by Sydney
Current amount of ram is 512mb, and we use roughly 250mb to 300mb of that.
Yes, i would definately ask for more disk space. It shouldnt be hard or expensive for them to fulfill.
If we can keep our ram usage as it is now we wont have much of an issue. But if we start using more, we may have an issue.
Maybe they could give us a couple hundred more MB of ram.
If we want to our own git hosting eventually we may have issues if we dont have more ram though.
I would definately ask for a KVM machine, even if they cannot fulfill it.
I cannot think of anything else. The bandwidth more than suffices.
Im impressed with FirstRoot. Thanks for being so kind and generous FirstRoot!!!!
-Sydney
3 years, 11 months
GPG keys for the core team
by Quintus
Hi everyone,
it just occured to me that a large part from the “core team” has a GnuPG
key:
- brianvanderburg2
- Luiji
- Quintus
- sydneyjd
- xet7
Wouldn’t it be nice if I collected these into a GnuPG keyring file, and
upload that one to our website? Then everybody can import all the keys
of the TSC team just by importing that keyring file.
If now datahead generated a keypair, we’d have covered the most involved
persons. I also encourage Bugsbane, DarkAceZ, and sauer2 to generate
GnuPG keys, then the entire core team is reachable by encrypted email
:-)
Valete,
Quintus
--
#!/sbin/quintus
Blog: http://www.guelkerdev.de
GnuPG key: F1D8799FBCC8BC4F
3 years, 11 months
CALL FOR VOTES: Voting rules document
by Quintus
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
C A L L F O R V O T E S
1st vote September 1st, 2015
Hi everyone,
this is the formal call for votes (CfV) for the voting rules
document. The voting period is now open!
For your information again, this is the voting rules document draft we
want to accept or reject:
http://team.secretchronicles.de/~quintus/votingrules/votingrules-2015-08-...
Proponent
°°°°°°°°°
The voting was proposed by me, Quintus <quintus(a)quintilianus.eu>.
Vote subject
°°°°°°°°°°°°
This vote is aimed at the ratification of the voting rules document
itself.
Vote options
°°°°°°°°°°°°
These are the possible voting options:
Option 1: Accept the voting rules document
Option 2: Reject the voting rules document
Voting period
°°°°°°°°°°°°°
The voting period is now open, and lasts until 2015-09-30 23:59
UTC.
Procedure
°°°°°°°°°
As nobody (thankfully) requested a covert vote, this vote will be held
as an open vote. Please vote by sending an email indicating the option
you voted for to the mailinglist or make an according post to the forum
topic corresponding to this message. Everybody has only one vote. If you
have a GPG keypair, please use it to sign the message (this is optional,
but recommended).
As per §1 of the voting rules, these are the people who are allowed to
vote:
* brianvanderburg2
* DarkAceZ
* datahead8888
* Luiji
* Quintus
* sauer2
* sydneyjd
* xet7
Note this is a special vote as it has a specific majority requirement as
per §21 of the voting rules document: At least two thirds of the team
members must choose the acceptance option, otherwise the vote is
failed. Conversely, if more than one third votes for the rejection
option, the vote is also failed. In any case, we’ll have to revise the
document then. If not enough people participate, we may vote on the same
document without changes again.
- From the above list you can surmise that eight people are allowed to
vote, which means that 5 ⅓ people have to be in favour of the voting
document. Since a third of a person is a little problematic, but 5
persons are not the required majority, at least 6 people must be in
favour of it. In turn, if at least 3 people vote against the document,
it is rejected.
Quintus
TSC project lead.
- --
#!/sbin/quintus
Blog: http://www.guelkerdev.de
GnuPG key: F1D8799FBCC8BC4F
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
iQEcBAEBCAAGBQJV5U67AAoJEPHYeZ+8yLxPyxYH/3+oTIk5DttKfmKKJTs1x82l
N1DSImHsLpQKqhF3zNTd0LjR59fqNcJiaykU09VlD/AdKt2Z4bjyM3t1gHyDlXbV
TcFNgFJQnGGdtm+RX/wn20tZTdXwvC0vli981tnL/XdtzhfiZyg9BBJ286WmCAKo
1VRCsIMNF4FshQbjKExBZTOO/7b36EZHt2IamwDGsnFWxyUOxl9NcaCtIdz7fig5
IpsT6nhcePwfzKIMYs3EF3tZiN248D6Sx08VCI9ODVQRcnSRwNVZBiYgN/NFoeQz
lRTIwlYku1IjhGNYa89Vu7ElugJ30zm8C3iFLWbRJXwXz3TsS2xsT6Y4AV114Rw=
=MYBV
-----END PGP SIGNATURE-----
3 years, 11 months
Travis CI
by Quintus
Hi,
I noticed in the chatlogs you were talking about Travis CI
builds. Before you start your own endevour, please review the existing
Pull Request by carstene1ns regarding that:
https://github.com/Secretchronicles/TSC/pull/129
It was never merged, carsten1ens closed it himself. Still it might be
worth a look.
Valete,
Quintus
--
#!/sbin/quintus
Blog: http://www.guelkerdev.de
GnuPG key: F1D8799FBCC8BC4F
3 years, 11 months
Re: [tsc-devel] CALL FOR VOTES: Voting rules document
by Lauri Ojansivu
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
--- VOTING BALLOT ---
I vote Option 1: Accept the voting rules document.
BR,
xet7
--- END OF VOTING BALLOT ---
-----BEGIN PGP SIGNATURE-----
Version: Mailvelope v1.0.2
Comment: https://www.mailvelope.com
wsFcBAEBCAAQBQJV5VHSCRBUkbRHnw13OQAAIb4P/jU/aiOnGjsxOPKhqxte
0TcR7HhwU4zrpMjA/WgEIzzczP86qj2stoAgjzKw8VYBcsTu9r5DIHnAB/3p
oHj3r8/qMnjTiKeRmYZpaV6fpS4fOcTkjVFoVX/OzBxo5uep8qjgAMLjZtZx
I2I4rR56cXVcxaYT/Hv4SGKgwfHo+h6wlwkZQ7EqUarMnzI5CUPUsITp9mEa
E0u5uL0UQZpwntIh9GaLgxKa5/VIUqqu9zyGSqjc7xBbANNCwcct3VjNrJx3
oGftduZHzgykHf77mkslqryloR9jZjk8wY4tioZhvW3JzgMRwHuPfMLq+GGq
qEUn0AaUepCxmny2O1j+ziWeLFKXmsjaVdsIhMacbHgGZWRkFoBy+CJSFsP6
SCo+aQctagnSupwl5rCyctNBV+/HdtYL/ZmtYHKW3qehDJPVblEd9vSc7z30
YEalTdjndmCWOT8XqCk8m5a2sR/i0SnzeLnId3wzxQ/RjJsrXKZqQywNVonn
5IAJJ/GYTbw8FvBvZ/ZTDMPhWDLJEutmeSplFso4wHOBaStMBQnqUakb2a9J
30SJ9yc5e0SqlX4nDL+Jxf/z4fABViWWCBqFxMcJhCk6oQNeWXaM5E8RQQiZ
JTGfBKtx8LwIQBn6FCj98SZJ1bLWyeewaQMoPCtKp63ONgXPn8XoOZfGq4fu
IasE
=6DqI
-----END PGP SIGNATURE-----
3 years, 11 months
