On Mon, Aug 08, 2016 at 10:32:53AM +0000, Holger Levsen wrote: > while I do understand where you are coming from (or want to be) I wonder > how much these scripts deserve a package of their own and/or whether > they should be packaged seperatedly or not at all. I think I learned a bit now:
from #voctomix on irc.hackint.eu [12:22] < h01ger> | MaZderMind: derpeter: what do you think about https://github.com/carlfk/voctomix-outcasts ? [12:22] < h01ger> | via https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=833700 [12:33] < MaZderMind> | h01ger: i'm unsure. Up to now I've seen the scripts as part of the customizing and the scripts delivered with voctomix are therefor explicitly called 'examples'. I'm not sure about if it's wise to package scripts that are dependent on local system specifics (ie https://github.com/CarlFK/voctomix-outcasts/blob/master/setup/mk_voc_ln.sh, https://github.com/CarlFK/voctomix-outcasts/blob/master/tests/test [12:33] <@MaZderMind> 1.sh) into a .deb [12:36] * | h01ger nods [12:37] < h01ger> | mk_voc_ln.sh is indeed urgs [12:47] < CarlFK> | h01ger: I think it makes sense to keep my outcast stuff separate. we still don't have a good grip on where config stuff lives, and right now some of it is in the ingest.py sources (like mode=18.. the 18 should be in a config or something else [12:51] < h01ger> | CarlFK: if we dont have a good grip yet how things should work, i think we should wait with the packaging [12:52] < CarlFK> | h01ger: I agree. [12:52] < CarlFK> | h01ger: right now my deployment is: nice clean put everything in place... then edit here and there to make things work [12:54] * | h01ger nods… feels like we set up (complex) web servers 20y ago [12:55] <@MaZderMind> xfxf: we didn't use the audio plyout feature restart was because of the gui slowdown we fixed in february [12:56] < MaZderMind> | h01ger: the thing is: there is now default setup. c3voc uses blackmagic cards + mjpeg grabber, lca uses usb audio + hdmi2usb + other stuff [12:59] < h01ger> | MaZderMind: i hear there are 3 setups now: default (voc), lca + debconf. or am i missing something? ;-) [12:59] < h01ger> | joking aside… how can we make this most useful for everyone? [13:01] < atze> | h01ger: I think your comparison with web server was good. There is a big bunch of specific configuration necessary, it doesn't work out of the box [13:01] < MaZderMind> | h01ger: in my original vision, the core is the common piece, all the scripts around are "integration work" that needs to be done for each setup differently [13:01] <@atze> maybe make an voctomix-example-setup package that puts some scripts in place to just get it working with some dummy streams [13:01] <@MaZderMind> we supply examples but the specific integration is up tpo the team [13:03] < h01ger> | MaZderMind: i'd be happy to have (+maintain) those "scripts around" as seperate packages (source or binary…) eg voctomix-examples-default, vocotomix-examples-lca or probably better voctomix-examples-blackmagig, voctomix-examples-dvswitch, voctomix-examples-pulseaudio, foo bar [13:03] < h01ger> | and/or a example setup package, thats always a good idea [13:05] < CarlFK> | h01ger: even with dvswitch, didn't FAI take care of some of the bits? [13:06] < h01ger> | CarlFK: yes. but i suppose #833700 is not totally useless ;) [13:08] < MaZderMind> | h01ger: packing an example package would be a good idea. [13:09] <@MaZderMind> but thinking about "first user experience" is still a little out of scope [13:09] <@MaZderMind> at c3voc we're still not completly happy with our setup [13:16] < CarlFK> | h01ger: useful, but lets not rush it. I don't think it isn't stable yet. [13:21] <@atze> MaZderMind: being able to "just test it" by installing an example package is a big gain IMO [13:21] <@MaZderMind> atze: yes, absolutely [13:21] <@atze> like the "it works" page in apache [13:22] <@atze> I could commit to writing such example scripts, since I have "setup a vocto dev instance" on my agenda anyway [13:22] <@MaZderMind> atze: the scripts are mostly already done: https://github.com/voc/voctomix/blob/master/example-scripts/gstreamer/source-all-videotestsrces.sh [13:23] <@atze> MaZderMind: I excpected that :D but making a selection and pointing out which file must be placed where etc. [13:23] <@MaZderMind> atze: yes, that's what i was about to write. thinking of a user journey from first install to running system [13:24] <@MaZderMind> and a way to guide them from there [13:24] <@atze> the journey should be a bunch of "apt install" calls [13:24] <@MaZderMind> plus maybe install .desktop files on a desktop to allow users to start the pieces [13:25] <@atze> is there no gui for systemd ? [13:25] <@MaZderMind> but it would involve things like "you can't run the gui without the core" or "when you run the core, would you like to also start the test-sources?" [13:25] <@atze> I'd write a unit file "voctomix-example-setup" or similar that just depends on all pieces [13:26] <@MaZderMind> atze: an you start the gui from the unit-file? [13:26] <@atze> then you can start that with one command, but only as root of course :-/ [13:26] <@MaZderMind> ca [13:26] <@atze> ah no.. not the gui, but the rest [13:27] <@MaZderMind> there is actually no need to run that as root. maybe instead create a .desktop-file which starts all pieces including the gui? [13:40] < CarlFK> atze: https://github.com/carlfk/voctomix-outcasts#getting-started--demo [13:42] <@atze> CarlFK: yes, something like that, but no recording sinks, resp. just to dev/null or sth [13:42] < CarlFK> atze: why no sinks? [13:43] <@atze> no sinks that write on disk on a first start IMO. of course it should be in the files, e.g. commented out, but I would not expect from a starting example that it fills up my disk [13:44] < CarlFK> atze: meh, there are ways to deal with that. like sleep 30; kill pid [13:44] < CarlFK> which seems ... odd. [13:45] < CarlFK> it is a few g per hour, so if they let it run for a day.. they get a day of video files.. that is kinda the goal of vocto [13:46] < CarlFK> ! [15:11] < h01ger> | atze: those examples you'd write, would you put them into voctomix.git or elsewhere? [15:12] <@atze> of course [15:12] < h01ger> | cool [15:13] <@MaZderMind> atze: feel free to restructure what you find useful [15:13] * | h01ger would like to add http://paste.debian.net/hidden/e3cbb48c/ to https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=833700 assuming MaZderMind, atze and CarlFK are fine with that [15:14] < h01ger> | (including useful comments still incoming ;) [15:14] <@MaZderMind> ok for me [15:17] < atze> | h01ger: ok for me [15:18] < h01ger> | oki, waiting for carl then… [15:18] < h01ger> | (i've also added this one line: "<@MaZderMind> atze: feel free to restructure what you find useful") [15:46] < h01ger> | regarding these examples: instead of putting them into /usr/share/doc/voctomix/examples/ we can also put them into /usr/share/voctomix/(extra-)scripts/ - which i think i'd prefer over /usr/bin/voctomix-$scriptnames. and yet another idea would be /etc/voctomix/scripts/ and then use appropriate name (probabyl with the word skeleton or template or example in them) [15:46] < h01ger> | MaZderMind: atze: CarlFK: ^ [15:51] < atze> | h01ger: I'd put them in somewhere in etc, dont know how strict it should be handled to have actually no scripts there [15:53] <@atze> but have to dig into the structures first [15:53] < h01ger> | atze: there are scripts in /etc/munin/plugins/ too [15:53] <@atze> fine then [15:54] < h01ger> | so that would be another way… those munin plugins are links to the actual plugins in /usr/share/munin/plugins/ but you can replace the links with (modfied) file copies which wont get overwritten by package upgrades [15:55] < h01ger> | (so it achieves what we want here too and it keeps two important properties of good system design: changes in /etc are preserved and code is shipped in /usr) [15:56] < h01ger> | and hopefully one day these scripts/plugin are indeed static and accept configuration when+if needed [17:33] < CarlFK> | h01ger: please do. [17:34] < CarlFK> (copy this chat into the issue ) [17:37] < h01ger> | will, do thanks -- cheers, Holger
signature.asc
Description: Digital signature
