#apertus IRC Channel Logs

BAndiT1983: ok so possibly removing the systemd specific code should be no problem

http://0pointer.de/blog/projects/journal-submit.html

if you have examples about your proposed way, then i wouldl ike to read more into it, as most systemd docs are wall of texts

ah right

should we do the merge?

please check the underscores in front of vars, like _main_menu

will work on underscores now, good idea

se6astian, let us create some basic code guidelines, this would prevent most merge conflicts, e.g. avoid underscores in front of vars, braces on new line, C lower-case naming for methods and vars like set_white_balance()

why leave them?

very good, yes, let's place them there, but we should move it to wiki later

braces on new line - I dont do that

is E1_rot now E1_pos?

the change is not mine, i suppose its yours, that's why i'm asking what we should use, as the code is using E1_rot, but globals.h contains E1_pos

must have been a mix up then, both names are descriptive

will commit my merge, afterwards you can check it and start to complain ;)

I manually added it

ah, probably gitmodules is conflicting, as it was already in my repo

seems to be merged now, will check what the pull requests against master repo will show

11 commits are in my fork

great, lets do it

could you check if it switches the menus now?

merging my own changes now

BAndiT1983:

may I suggest you install mplabx so you can also verify this

will continue tomorrow

se6astian|away, will check it

se6astian|away, please paste the build command from your IDE

That will also probably help the gsoc students

BAndiT1983: regarding the systemd changes: i have unfortunately not found any simple tutorial / example, i am just extrapolating from the way inetd works and StandardInput=socket being the option that should make the systemd way work with inetd

i can disable journal functions and check if stdout will land in journalctl

http://0pointer.de/blog/projects/inetd.html

this is also helpful (adding as reference for later) -> https://unix.stackexchange.com/questions/313513/detect-if-program-should-log-to-systemd-journal-or-stdout

but i doubt there is a possibility to run clang-format on github, maybe before CI and on successful build upload formatted version, if there are changes

Yeah running clang-format in ci and commiting a formatted version from the ci should be possible, but probably unnecessary if we find a way to reliably share the git hooks

systemd logging to journal is fine, but maybe we should go the way of outputting through systemd to log files, one for acces and one for errors, like nginx

oh sorry that wasn't clear on my part, is wasn't talking about something like github webhooks, but about the local git hooks, git support running a local file on some actions like before a commit by just placing it unter .git/hooks/pre-commit

ah, you mean while adding a commit locally, it would also work, although i prefer to execute formatting often manually on the whole directory, at least in intellij i use the shortcut very often

oh i also prefer running the formatting myself, but i think the git hooks would help other people (and also prevent someone from forgetting to run the formatting)

ok so rsyslog seems to have systemd integration, interesting

but i mainly brought up the topic of systemd because i want to get rid of any systemd dependency :)

yes, but we are thinking of moving away from archlinux

really?

my only problem with it, is the constant update flood, rather problematic when developing and building on camera

while i like archlinux, archlinuxarm seems to regularly have strange problems and is really that well maintained

if there are no objections from anybody i think it would also make sense for the beta

as long as the scripts and apps are working

found docker container, if i will find some time, then i would test daemon build there

that is one reason i think void is better than for example alpine, void still uses glibc as opposed to musl with alpine uses, with could couse some troubles

using alpine mostly for docker or virtualbox, till now everything worked, but i can't say anything about bare metal support

s/if you//

apline has most of the stuff patched, but the even the control daemon does not compile on musl at the moment (because flatbuffers doesn't compile)

yeah i also have nothing againts glibc, but i thought it would be fun to test musl a bit

yeah i can image more interesting / fun things than java web development :)

flatbuffers is also included in void packages -> https://voidlinux.org/packages/

(which is what alpine uses)

at least for most tasks

yes i also really like alpine, but i think using something which uses glibc could save some unnecessary troubles

good point about distro packages, will check how to use cmake to do the job for daemon