#apertus IRC Channel Logs

hi

morning folks!

hi everyone, if you are here to join the general assembly please go to the channel as described in invitation email

hi bluez

as the association is currently holding its general assembly

bluez: now we are here :)

I will give a brief status update of progress since last week

so bluez and metal_dent[m] have finished their internship this week, dont leave us :)

other progress

hurray

it will go to Bertl soon to replace the french research group one loaned to us for evaluation

the Sensor boards have been handed back to tele with the image sensor sockets inserted for soldering

so next time we can just let Tele do the insertion

Chairman: me, Vice chairman: Oscar (Cscar)

regarding GSoC we have now requested slots for students but Google does not allow us to share the allocation yet

May 17 18:00 UTC Accepted student projects announced

metal_dent[m]: & eppisai please share your very shot report/summary

that's it

great

Have just been improving code for keyboard screen (after going through it again,I saw some things can be improved upon and can be made less confusing by following SOLID Principle)

Other than that, for my current draft pull requests,

2. Will see if I can make some progress in stack analysis again(been more than 2 weeks since I last tried). So, any changes I make in firmware will actually be useful, and finally can open/create pull requests for all my firmware/UI changes. Hoping to collaborate in this regard with Andrej and Sebastian, if they have some free time :)

Week has just started! :D

*have

many thanks!

yup

for some reason it required tweaking a weird option, as mentioned by someone in the XIlinx forum, but it works thankfully

and more importantly: by combining all other scripts, i wronte the main interface script

this demonstrates the whole process

will write the value to the specified register instance... and the specified register index (0 here out of [0-31])

so the final implementation is (kinda) complete!

currently it takes too much time for it to be usable... almost 2 minuites to write and 1 minuite to read ':D

so all that can be optimized a lot

so that's it from me!

well, it's a great proof of concept and I'm glad you finished it just in time for the internship! congrats!

looking forward to the final report and the future optimizations!

yup, me too!

vup/anuejn any news?

I have a little

this week I mostly focused on the RPC part

each entry in a directory can either be another directory, a function which can be called, or a hook, which causes the daemon to notify you if the hook triggers

Furthermore each entry can only be accessed with the proper authentication

I am still not sure on the authentication part, maybe we can defer this completely to something like network authentication (you can only access the daemon via network, so if you cannot access the network the camera lives in, you obviously also don't have access to the daemon)

Finally I also filled out how I currently envision using the daemon from bash / python / etc would look like: https://codimd.niemo.de/Jv9uOS8pTeufU0_MwUsDjA?both#usage-vision

Bertl: having authentication in the daemon itself?

we could defer the authentication to pam

which might allow configuring the level required on an individual basis

you want high security, go crazy!

ah, hmm, good point

wifi networks are notoriously weak regarding security

so that might not be sufficient for those folks relying on security

sure, that is kind of my view aswell, I would like to be able to just make the camera accessible on the internet and still be able to restrict who can access it

indeed, but if you plan to implement fine granularity for the on-camera case, you likely want to do the same for the 'network' case as well

thanks for the update! maybe more to discuss after meeting

nothing to report from my side for this week

so if nobody has anything else, we can conclude the meeting

yes MEETING CONCLUDED!

thanks for moderating!