azonenberg changed the topic of #scopehal to: libscopehal, libscopeprotocols, and glscopeclient development and testing | | Logs:
xzcvczx has quit [Ping timeout: 260 seconds]
Degi_ has joined #scopehal
Degi has quit [Ping timeout: 265 seconds]
Degi_ is now known as Degi
xzcvczx has joined #scopehal
<azonenberg> Status update, Pico MSO channels are mostly working but occasionally seems to desync and crash, not yet sure why
<azonenberg> Cannot yet be used for triggering
<noopwafel> this isn't pushed I guess?
<noopwafel> (no way to test but I thought I could look at code)
<azonenberg> Not yet pushed. Still debugging
<azonenberg> Also related, pico wastes half their memory/bandwidth in digital mode
<azonenberg> by using 16 bits for each MSO pod but only storing stuff in the low 8
<noopwafel> so they also have this problem for the analog channels right?
<noopwafel> the lower-end scopes always get 16 bits from api even though it could fit in 8
<noopwafel> but I kind of hoped that it wasn't stored like this internally
<azonenberg> well i havnet looekd at the usb or on chip represnetation
<azonenberg> but i get the feeling it's probably just memcpy's the whole way
<azonenberg> and yes, the 6000E series is 16 bits all the time even in 8 bit resolution mode
<_whitenotifier-1> [scopehal-pico-bridge] azonenberg pushed 1 commit to master [+0/-0/±4]
<_whitenotifier-1> [scopehal-pico-bridge] azonenberg 1c2bf22 - Initial support for digital channels. Cannot yet be used for trigger. Fixes #5.
<_whitenotifier-1> [scopehal-pico-bridge] azonenberg closed issue #5: Support for digital channels -
<_whitenotifier-1> [scopehal] azonenberg pushed 1 commit to master [+0/-0/±2]
<_whitenotifier-1> [scopehal] azonenberg 288f33f - Initial Pico digital channel support. Fixes #457.
<_whitenotifier-1> [scopehal] azonenberg closed issue #457: Pico: Support for digital channels -
juli9611 has joined #scopehal
<azonenberg> So i can't quite decode 1000base-X with the pico LA
<_whitenotifier-1> [scopehal] azonenberg pushed 1 commit to master [+0/-0/±1]
<_whitenotifier-1> [scopehal] azonenberg 79f9cd4 - ClockRecoveryFilter: added support for doing CDR on digital input channels
<azonenberg> Might be possible with some PLL adjustments
<azonenberg> i suspect the current CDR is unable to track the high jitter from only oversampling the data 4x
<azonenberg> noopwafel: anyway i pushed what i have now on the pico driver. it still seems a bit buggy but i havent found the root cause yet
<azonenberg> i think i need to stress test it a bit more to figure out where it's going wrong
<azonenberg> it intermittently seems to read garbage
<azonenberg> then die with a std::bad_alloc from trying to create an rx buffer of an absurd size
<azonenberg> But so far i havent found any obvious root cause
<azonenberg> or way to reproduce it
<_whitenotifier-1> [scopehal-apps] azonenberg labeled issue #350: Add "scopehal-server" utility for bridging an arbitrary Oscilloscope to a socket -
<_whitenotifier-1> [scopehal-apps] azonenberg opened issue #350: Add "scopehal-server" utility for bridging an arbitrary Oscilloscope to a socket -
<noopwafel> when calculating numchans, you check g_msoPodEnabled and not g_msoPodEnabledDuringArm
<noopwafel> (I also see that my ps3000 code doesn't actually do 'numSamples = numSamples_int' after calling GetValues which is another bug in this code..)
<noopwafel> It looks okay to me otherwise, but the enabled thing would cause a dsync.
<azonenberg> Yeah ok that might be it
<_whitenotifier-1> [scopehal-pico-bridge] azonenberg pushed 1 commit to master [+0/-0/±1]
<_whitenotifier-1> [scopehal-pico-bridge] azonenberg 996a02b - Fixed using msoPodEnabled instead of msoPodEnableDuringArm
<azonenberg> It's a bug so i'll fix it regardless, will need to hammer on it a bit more to be sure if this is the actual bug
<azonenberg> Then i need to do a bit of cleanup and start figuring out how to do triggers on mso channels
<azonenberg> Now i just need to find a nice test subject in my lab to demo the MSO on
<azonenberg> all of my recent MSO stuff has been on client boards for work
<azonenberg> so i gotta find something i can actually show
bvernoux has joined #scopehal
<bvernoux> hello
<bvernoux> I have just rebuilt latest glscopeclient and something amazing
<bvernoux> the bug with 64b66b.scopesession has disappeared ...
<bvernoux> very very strange ...
<bvernoux> I can load it with success without any crash
<bvernoux> It seems it is clearly a buffer overflow somewhere which is probably in an other area without direct/visible impact ...
<bvernoux> buffer overflow of something corrupted in memory
<bvernoux> or maybe it is fixed ...
<azonenberg> bvernoux: try valgrind or asan and see if you can shed any light on it
<bvernoux> they are not supported with windows :(
<azonenberg> asan isn/t?
<bvernoux> valgrind works only with Linux
<azonenberg> isn't*
<bvernoux> I shall check asan
<azonenberg> i think we even have config in cmake for it
<azonenberg> just add -DANALYZE=ON to the cmake command line iirc?
<bvernoux> Asan is supported with MSVC ;)
<azonenberg> if it is a race condition, small changes to how long some stuff takes to run might make or break it
<azonenberg> bvernoux: also mso support for picoscope 6000e is now pushed. unsure how similar 3000 series MSO is
<azonenberg> as of now you cannot trigger on the mso channels
<azonenberg> attempts to do so are likely to end badly
<azonenberg> but you can trigger off an analog channel and acquire waveforms
<azonenberg> I'm still testing and debugging but it mostly seems to be working
<bvernoux> yes I have not tried so far
<bvernoux> I was just doing my standard test after build loading demo, and spi, 6466 ;)
<bvernoux> even if it is limited test so far it showed lot of issue when there was ;)
<bvernoux> it will be great to push a test with all decoders ;)
<bvernoux> everything ;)
<bvernoux> just for robustness and perf test
<bvernoux> and why not non regression test if we have a way to compare what is displayed vs what is expected but it is not easy with GUI stuff ...
<azonenberg> Yes, it's tricky on the GUI side, but the decodes are all just data structures in ram
<azonenberg> there's absolutely nothing stopping us from making unit tests for decodes
<azonenberg> in fact, we have one already. i think for the "frequency" measurement
<azonenberg> it's just a matter of putting in the effort to thoroughly test *all* of the decodes, collecting corpuses of test data
<azonenberg> preferably without excessive volumes of data or sample rate, because my current collection of test waveforms is something like a hundred GB
<azonenberg> I can't put that on github and expect everyone to run tests against it
<bvernoux> unfortunately asan seems not available for MSYS2 mingw64
<bvernoux> I have an error to build with the option
<azonenberg> And there's at least a few protocols where my only available waveform data at the moment is from work, and thus not shareable
<bvernoux> ha yes not good
<bvernoux> I think we just need small test with all type of data to display all type of decoders/features all at same time ;)
<azonenberg> So yes, probably in the gear-up for v0.2 i want to put a lot more effort into creating open, small test datasets we can use
<azonenberg> Not going to happen before 0.1
<bvernoux> yes there is no hurry for v0.1 it is mainly for mid/long term
<azonenberg> for 0.1 i'm focused on taking everything we have and finishing the rough edges, documenting things, fixing the file format, etc
<bvernoux> yes such things shall not block v0.1 I'm 1000% agree
<bvernoux> especially actual version is already very mature for a v0.1 even if you want to finish some cleanup ...
<bvernoux> lot of dataset could be converted from sigrok data maybe too
<bvernoux> for protocols
<bvernoux> when I have MSO working with my Pico3000 I could push some "open" capture for different protocols like I2C, SPI, UART ...
<bvernoux> I'm not those are the most interesting but it is always good to have more and more dataset for test ...
<azonenberg> Yeah the challenge will be in minimizing the data
<azonenberg> I might try to create some tools for that
<azonenberg> deleting unnecessary waveforms from history
<azonenberg> downsampling waveforms
<azonenberg> deleting channels not in use
<bvernoux> yes it will be great on future version to have a "selector" to remove data before / after
<azonenberg> So we can create a file with specific data that's not bloated more than it needs to be
<bvernoux> such feature is not available on any PC scope tool like pulseview, DSView ...
<bvernoux> sigrok can do it with cli version IIRC
<bvernoux> what I hate in sigrok is the dependency on Python 3.x path
<bvernoux> it is bloated ;)
<bvernoux> I must rename my Python 3.8 dir as it is in path and PulseView does not start ;)
<bvernoux> even if PulseView have python34.dll in same dir as the exe it seems it try to use the one from path before ...
<bvernoux> anyway it is not related to glscopeclient but it is annoying I really start to hate all those python bloated stuff which are uncompatible between version ...
<bvernoux> in Python 3.9 they have also broken support to Win7 ...
<bvernoux> and so they force people to move to Win10 it is a "dictature"
<bvernoux> they have broken the installer in fact with intentionally remove support for Win7 ...
<bvernoux> Just for info my WIndows 7 Entreprise N receive updates
<bvernoux> as there is extension for that special version so it is dead ;)
<bvernoux> +not ;)
Stephie has quit [Quit: Fuck this shit, I'm out!]
Stephanie has joined #scopehal
Tost has joined #scopehal
<_whitenotifier-1> [scopehal] azonenberg pushed 1 commit to master [+0/-0/±1]
<_whitenotifier-1> [scopehal] azonenberg d3ae64d - PicoOscilloscope: added attenuation scaling to triggers. Fixes #456.
<_whitenotifier-1> [scopehal] azonenberg closed issue #456: Pico: Support for channel attenuation -
<_whitenotifier-1> [scopehal] azonenberg opened issue #480: Add MSO channel threshold/hysteresis to scopesession files -
<azonenberg> So it looks like the pile of things that have to be added to / fixed in the file format are stacking up fast
<azonenberg> it's probably the #1 thing i have left to do on the project now
<azonenberg> before v0.1
<azonenberg> Having to manually reconfigure MSO thresholds for each channel every time i recompile code for the pico driver is seriously annoying
<bvernoux> yes nice feature
<bvernoux> woo there is something annoying
<bvernoux> LP filter 1MHz is ultra slow
<bvernoux> my Pico drop from 11WFM/s to 2WFM/s when I do a LP filter with 1MHz on a chan
<bvernoux> if I remove this filter it come back to 11WFM/s
<bvernoux> with 1MS per chan
<azonenberg> What's your sample rate?
<azonenberg> It's a FIR filter, if you are trying to filter say 1 Gsps (500 MHz nyquist BW) down to 1 MHz you're gonna need a crazy number of taps
<azonenberg> the filter properties lets you control the number of taps, if blank or zero it will pick what it considers reasonable
<azonenberg> this number can be quite large for low frequencies
<azonenberg> For large levels of downconversion it's typically more efficient to do a small LPF then decimate then another
<bvernoux> it is 1MS
<azonenberg> No, sample *rate* not memory depth
<bvernoux> doing a downsample with 200 factor is clearly better here
<azonenberg> Higher nyquist BW means you need more FIR taps for the same cutoff frequency
<bvernoux> even if it is not very clean when checking the FFT as it miss a filter ;)
<bvernoux> ha yes it is 625MS/s
<azonenberg> So in that case i would do say a 30 MHz LPF then a 10: decimation then a 1 MHz LPF
<azonenberg> 10:1*
<bvernoux> but I doubt it is correct for Pico3000 as it is 2GSPS for 1 chan, 1GSPS 2chan and 250MSPS 4chan IIRC
<azonenberg> The default sample rate for the pico driver right now is 625 Msps as that's what a 6000 series will do on all channels
<azonenberg> including digital
<azonenberg> That default should probably change for lower end ones
<bvernoux> I think a moving average shall be enough to filter my signal
<bvernoux> it is a basic prob compensation signal ;)
<bvernoux> oups MovingAvg does not work I cannot change the ms it is always 0 ms
<bvernoux> for the depth
<azonenberg> you're trying to put millisamples
<azonenberg> just put a number there
<azonenberg> Another quirk of the unit system, 0 is always printed as the smallest available unit
<bvernoux> ok
<azonenberg> On the list to improve
<bvernoux> yes it works when we remove the unit ;)
<bvernoux> maybe just never put a unit by default
<bvernoux> as anyway for a movingavg we want a number of sample
<bvernoux> glurps crashed ;)
<bvernoux> my GFX card smell bad ;)
<bvernoux> on those laptop it is crap and that overheat quickly ;)
<azonenberg> bvernoux: well the thing is, if you have larger values
<bvernoux> when AMD will deliver the latest Ryzen 9 !!
<azonenberg> it needs to accept, and print, things like "2 kS"
<azonenberg> no, what needs to happen is the unit system has to be smarter
<azonenberg> and know that, for example, millisamples isn't a valid unit
<bvernoux> yes here it was wrong it was in ms
<bvernoux> when we expect Samples kS ...
<azonenberg> thats the thing, it's not wrong per se
<bvernoux> ha i was thinking it was milliseconds ;)
<azonenberg> "ms" can be interpreted as milliseconds or millisamples depending on context
<bvernoux> so it was converting the X time from ms to samples internally ;)
<azonenberg> No
<bvernoux> very strange to use ms for millisamples anyway
<azonenberg> When parsing a parameter it knows what units to expect
<bvernoux> ok
<azonenberg> and it's not something i exactly implemented
<azonenberg> The unit system knows SI prefixes
<azonenberg> and it knows names of units
<azonenberg> "s" can be either seconds or samples depending on context
<bvernoux> ok anyway it is logical 10ms is 0 in that case
<azonenberg> Generally there's not confusion because you're configuring, say, memory depth
<azonenberg> Exactly
<bvernoux> maybe rename it for clarity if you can
<azonenberg> File a ticket against scopehal to make the units framework not use millisamples ever
<bvernoux> like sps or something like that to describe it is samples
<azonenberg> no, that's Sa/s for sample rate
<bvernoux> so msps Msps ...
<azonenberg> very different unit :)
<bvernoux> in that case just Sa ;)
<bvernoux> anyway it is minor issue just to clarify unit to avoid confusion
<bvernoux> I do not see MSO stuff on Pico3000 anyway
<bvernoux> it show only 4 Analog Chan does there is something in progress in actual code ?
<bvernoux> or maybe it support only Pico6000 ?
<azonenberg> Nobody has done any MSO work on 3000 series yet
<azonenberg> all of the code i pushed is 6000 only
<bvernoux> on Pico3000 I doubt MSO is same that Pico6000 as I have only option D0-D15 in fact or it can be probably in 2 groups of 8 bits
<azonenberg> i still have to implement triggering for MSO channels
<azonenberg> otherwise i think it's done
<bvernoux> ha ok
<d1b2> <mubes> While on units, can we have ∞ rather than 'inf' or is there a concern it may not be in all charsets?
<azonenberg> GTK should handle UTF8 just fine
<azonenberg> heck, you can put emoji in channel names if you're so inclined
<azonenberg> yes i am serious
<GenTooMan> I wonder if Mycenaean symbols work with GTK
<azonenberg> GenTooMan: if your font has it, anything in unicode should work
<azonenberg> all text rendering is done via Cairo
<azonenberg> mubes: anyway, ultimately it comes down to what std::to_string() or snprintf() does, depending on the part of the code in question
<azonenberg> we could string replace inf with the infinity sign in post if you want
<bvernoux> haha fun Emoji in chan name ;)
<d1b2> <mubes> I noticed it on the vertical cursors when you don't set a second one, so the delta is inf GHz. I'll have a grep through the code at some point.
<azonenberg> mubes: it's going to mostly be in the Unit class
<azonenberg> For v0.2 and later i have a bunch of improvements planned for it
<azonenberg> Among other things, I want to add support for units created via arbitrary linear combinations of units
<azonenberg> Like V/s for the output of a differentiation filter
<d1b2> <mubes> I dread to think what effect an Emoji channel name will have when sent to the scope, but I feel an unnatural desire to find out
<azonenberg> Lol
<azonenberg> I have yet to try that lol
<azonenberg> My guess is the utf8 sequence will be rendered as separate ascii bytes
<d1b2> <mubes> Should happen automatically on Siglent. Ill try it later
<azonenberg> or the command will fail to parse
<azonenberg> I should try on a lecroy too and see
<azonenberg> this demo i did offline so it didnt send a command to the scope
<bvernoux> on Pico3000 also the frequency is wrong
<bvernoux> 5x too big
<bvernoux> I think it is clearly related to SMPS which is wrong like explained before
<bvernoux> with 4 Chan it is 250MSPS instead of 625MSPS in actual code where it is hard coded
<azonenberg> No
<azonenberg> I think what's happening is that when i try to set the sample rate too high in the constructor
<azonenberg> the bridge code just clamps to whatever it wants
<bvernoux> anyway such things will be to be checked when we could configure sample rate and nb samples
<azonenberg> but the bridge is generally write only
<azonenberg> So any validation of parameters has to happen clientside because if you give it invalid config the bridge won't say anything
<bvernoux> yes
<bvernoux> I need to check if Pico3000 have those DigitalPods too
<bvernoux> probably yes in that case it will have 2 DigitalPods for 16IO
<bvernoux> yes I confirm that in the API
<bvernoux> up to 4 DIGITAL_PORT each is 8bits
<azonenberg> great, so the 6000 series driver should be easy to adapt
<bvernoux> yes
<bvernoux> I can hard code it for fast test ;)
<bvernoux> I'm checking what is the API to return the capabilities number of DigitalPods ...
<azonenberg> I apologize for nothing
<azonenberg> bvernoux: AFAIK there isn't one. I just detect based on the model number how many pod ports are present
<bvernoux> ha ok it's bad ;)
<azonenberg> If it's a design using detachable pods like the 6000 series i can detect if they're present
<azonenberg> But you can't tell how many possible pods are on the scope AFAIK
<bvernoux> no here it is just basic GPIO7
<bvernoux> nothing detachable ;)
<bvernoux> just 2.54mm pin
<bvernoux> and anyway on Pico3000 it is easy either you have nothing or 2 ports ;)
<bvernoux> mine if the max version with all options
<bvernoux> and only 2 pods 16bits
<bvernoux> I do not even know why they say it can be up to 32bits (4pods) in the API ;)
<azonenberg> Maybe it's a hint that a future scope planned will have 4
<bvernoux> yes but it does not exist so far for Pico3000
<bvernoux> 16 channel logic analyzer (MSO models)
<bvernoux> so let's hack the code to support MSO on Pico3000 ;)
<bvernoux> good news to detect MSO it is exactly like for Pico6000
<bvernoux> Variant info: 3406DMSO
<bvernoux> I imagine you have 6xxxxMSO or something similar
<azonenberg> Mine is just 6824E
<azonenberg> I don't think there's any 6000 series without MSO
<bvernoux> ha yes
<d1b2> <mubes> Pleased to report Siglent just ignores unicode....or more specifically, doesn't render it, which might not be the same thing from the perspective of overflows etc.
<bvernoux> so we have the same logic to detect the bandwidth and number of chan
<bvernoux> so far the BW is not used but it could be to provide a list of sample rates supported
<bvernoux> even if it seems there is an API for that
<GenTooMan> I believe the 6000 series Siglent is still china exclusive no?
<d1b2> <mubes> Yes. Not tales about in the west, but the software between the 2000X+, 5000 and 6000 is understood to be largely common.
<d1b2> <mubes> 6000 has deep sample memory and high resolution sampling, as well as extended bandwidth.
<_whitenotifier-1> [scopehal-apps] azonenberg opened issue #351: Saving a session while cionnected to a PicoScope 6000 series scope, and trigger in run state, crashes -
<_whitenotifier-1> [scopehal-apps] azonenberg labeled issue #351: Saving a session while cionnected to a PicoScope 6000 series scope, and trigger in run state, crashes -
<_whitenotifier-1> [scopehal] azonenberg pushed 1 commit to master [+0/-0/±1]
<_whitenotifier-1> [scopehal] azonenberg 6ec2673 - Added MSO channel threshold and hysteresis settings to scopesession file format. Fixes #480.
<_whitenotifier-1> [scopehal] azonenberg closed issue #480: Add MSO channel threshold/hysteresis to scopesession files -
<bvernoux> I have a remark about => void PicoOscilloscope::IdentifyHardware()
<bvernoux> the code inside will be better to be moved in pico-bridge
<bvernoux> to have all things specifics to PicoXXXX in pico-bridge when possible to avoid modifying 2 parts of code
<azonenberg> The thing is, some stuff has to be known clientside
<azonenberg> i'm trying to avoid excessive round trips
<azonenberg> that adds latency
<azonenberg> look at all of the code for things like which channels can be enabled, or which sample rates are allowed, in particular configs
<azonenberg> the FlexRes scopes have quite complex configurations
<azonenberg> and it would be crazy to hit up the bridge for all of that
<bvernoux> yes
<bvernoux> just to find a good compromise
bvernoux has quit [Quit: Leaving]
<_whitenotifier-1> [scopehal-pico-bridge] azonenberg pushed 2 commits to master [+0/-0/±5]
<_whitenotifier-1> [scopehal-pico-bridge] azonenberg bc03657 - Refactored Stop() out to its own function. "capturing call stop" error handling can now handle repeated cases.
<_whitenotifier-1> [scopehal-pico-bridge] azonenberg af0d63b - Refactored psXXXXRunBlock() into StartInternal()
<_whitenotifier-1> [scopehal] azonenberg pushed 2 commits to master [+0/-0/±2]
<_whitenotifier-1> [scopehal] azonenberg e62cd6d - Oscilloscope: save timebase configuration. Fixes #116.
<_whitenotifier-1> [scopehal] azonenberg 520d149 - Added channel interleaving and ADC mode configuration to scopesession file format
<_whitenotifier-1> [scopehal] azonenberg closed issue #116: Add timebase configuration to save files -
<azonenberg> Woo, down to 17 tickets for v0.1 on scopehal
<azonenberg> R&S driver - fsedano, how's that going?
<azonenberg> Serializing trigger config - I plan to work on that tonight
<azonenberg> Equivalent time sampling, force trigger, auto trigger - no blockers, but i'll be doing other stuff first
<azonenberg> VCD import - if anybody is looking for a project that's a good self-contained one. If not, I'll probably bang it out next weekend or something
<azonenberg> LeCroy serial trigger - the hard part on this is the UI glue for handling all of the control characters and such in a pretty fashion
<azonenberg> fx2lafw driver: xzcvczx did you say you were going to work on that?
<azonenberg> i forget
<azonenberg> I2S decode: another good starter ticket, we have test data ready to go
<azonenberg> mjgerm has a closed PR with code that parses i2s but outputs it as sample objects, i think an analog waveform makes a lot more sense. But his code might be a good building block
<azonenberg> LeCroy WaveSurfer 3000 channel interleaving: this is blocked on me getting into the lab at work where the WaveSurfer is. I'll be there some time in June and plan to work on it then
<azonenberg> MIPI DSI ECC: another good small/starter ticket for somebody
<azonenberg> MSO5000 timebase: Degi, you were working on that right?
<azonenberg> Digilent SDK driver: on deck, I plan to work on that as soon as I've finished a few more rough edges on the Pico driver
<azonenberg> Siglent 1000x-e: GenTooMan, any status updates on that?
<azonenberg> CSV import timestamp: another good easy ticket for somebody
<azonenberg> then finally, #433 will require going through all drivers and making them sanity check the *IDN? and complain if you try to use the driver on an incompatible instrument
<azonenberg> and #383 i'm thinking of turning into a bit of a refactoring around the amplitude/peak to peak filter to make it selectable mode or something
<GenTooMan> azonenberg, Still very much a work in progress nothing exciting like it working correctly.
<azonenberg> Ok, no worries
<azonenberg> considering i havent even started the digilent driver and i wanted that for v0.1, you're far from the bottleneck :)
<d1b2> <mubes> Hmmm...I'd like to have digital channels on the SDS2000X+ working, but that needs Siglent to ship the probe. Hopefully this week we can move forward with that. I think the majority of the code is already in, but pretty untested.
<azonenberg> mubes: yeah well considering i havent even started the digilent SDK stuff, i think you've got a fair bit of time
<azonenberg> mainly i'm hoping to find someone to take on the "easy" tickets like the mipi ecc
<d1b2> <mubes> It would be nice to test against SDS5K too (I have someone with one who can test) let's see how the time progresses. Did I see there was talk of a 'doze installer? That would really help him, he's not super-comfy building from scratch.
<azonenberg> There is talk of that. As well as a msys2 package
<azonenberg> Not sure how far any of that has gone
<azonenberg> I know GyrosGeier was working on debian packaging (speaking of which, anything you need from me at this point? status?)
Tost has quit [Ping timeout: 245 seconds]
juli9611 has quit [Quit: Nettalk6 -]
<GenTooMan> azonenberg, I thought the install process still had yet to be worked out?
<azonenberg> GenTooMan: If the packaging doesn't rely on "make install" then there's nothing blocking it
<azonenberg> Finishing "make install" still has to happen
<azonenberg> that's one of the 20 pending tickets on scopehal-apps
<azonenberg> The ones i mentioned above were just the ones for scopehal