<d1b2>
<jone9048> Hi, I've had a go at adding support for the SDS800X HD series to the Siglent driver here - https://github.com/dresco/scopehal/tree/SDS800X_HD. All seems to basically work, but I'm a bit unsure how to handle the variable memory depth and sample rate..
<d1b2>
<fredzo_72653> Nice @jone9048 ! I was about to get back at working on Siglent driver, seems like I should wait for Adrew to merge your code befor that ! 😉
<d1b2>
<azonenberg> yep i have a couple of PRs to look at
<d1b2>
<fredzo_72653> Yeah same thing on recent Rigol scopes, I handled that with dynamic calculation of value list based on the number of enabled channels. I'll do the same on Siglent driver when I'll get back to it
<d1b2>
<azonenberg> yeah, the Pico driver does similar for the 6000e series
<d1b2>
<johnsel> @azonenberg want to chat about packaging?
<d1b2>
<azonenberg> since it doesnt fit our classic interleaving model
<d1b2>
<johnsel> I need to repay the favor you did
<d1b2>
<johnsel> and I have taken a few days off to work on things non-work related
<d1b2>
<azonenberg> Sure, although my availability will be intermittent, i leave for $dayjob in half an hour and will be on a bus/ferry/bicycle for the next 2ish hours after that
<d1b2>
<azonenberg> tl;dr the first step is to make "make install" work reliably if it does not already, i.e. make sure all files needed for proper functionality on osx/windows/linux are installed to the target location
<d1b2>
<azonenberg> second is to set up CPack to generate install packages in deb, rpm, etc formats, plus doing some updating/testing on the windows msi generation we already have, so we can get installable packages for all of our platforms in CI builds
<d1b2>
<jone9048> Cool, if you are happy with it as a starting point, then I'll make a PR from my branch? Obviously happy to test the dynamic calculations when available..
<d1b2>
<azonenberg> at which point when we're ready to cut a release we can simply grab the CI artifacts from the commit we tag as the release
<d1b2>
<azonenberg> (I'll try to review the pending PRs on the bus/ferry if i get a chance)
<d1b2>
<fredzo_72653> @jone9048 if you're done with your modifications and testing is OK on SDS800, just create an PR for Andrew to review
<d1b2>
<fredzo_72653> I'll take it from there once merged on Andrew's repo
<d1b2>
<azonenberg> Also, a few other business items: at some point in the not too distant future i want to set up a wiki page or something listing official maintainers for each driver
<d1b2>
<azonenberg> And we're long overdue for another developer zoom to sync on longer term planning
<d1b2>
<azonenberg> i've just been so busy, yay parenting and full time job and lots of other stuff :p
<d1b2>
<fredzo_72653> I was planning on adding SDS3000X HD and 7000 support too (which use the same protocol as SDS800/2000 X HD)
<d1b2>
<azonenberg> Awesome
<d1b2>
<johnsel> @bvernoux @david.rysk it might make sense to chat between us to discuss what work you already done on make install for Windows and Mac (and Linux). I think setting up CPack is easiest actually since we have a fairly good linux build output generated. Thoughts? @azonenberg
<d1b2>
<azonenberg> CPack depends on make install
<d1b2>
<johnsel> okay
<d1b2>
<johnsel> so make install on all the linux versions we want is prio 1
<d1b2>
<azonenberg> it basically takes the install artifacts and packages them, then you add some extra metadata for package name, version, dependencies on external distro packages, etc
<d1b2>
<johnsel> do we have a list of those?
<d1b2>
<azonenberg> Most distros will not upstream packages not generated by their official tooling, i.e. debian will not accept a deb generated by CPack (only their official flow)
<d1b2>
<johnsel> or a issue or WIP PR somewhere?
<d1b2>
<azonenberg> but the goal here isn't upstreaming yet
<d1b2>
<johnsel> No I remember all that
<d1b2>
<azonenberg> it's getting nightly builds people can install without compiling themself
<d1b2>
<johnsel> we just want our own flow
<d1b2>
<johnsel> right
<d1b2>
<azonenberg> exactly
<d1b2>
<azonenberg> There are a handful of generic issues for packaging IIRC but no wip pr
<d1b2>
<fredzo_72653> Yeah.. parenting is a full-time job ! 🙂
<d1b2>
<azonenberg> all work to date is merged
<d1b2>
<johnsel> do you have a list of issues for me?
<d1b2>
<jone9048> @fredzo_72653 Something I noticed in testing (just using a SCPI terminal). When selecting a memory depth, it only works when a 'valid' number of channels are active. For instance, on the 200MHz model, ACQUIRE:MDEPTH 50M does nothing unless exactly two channels are active. Also, once the deepest memory depth has been selected, the MDEPTH? response does vary to suit the number of channels selected after that. Just FYI...
<d1b2>
<johnsel> that are relevant?
<d1b2>
<azonenberg> There's not a lot, just search packaging on tickets
<d1b2>
<johnsel> I can dig myself, but maybe your super memory has it somewhere
<d1b2>
<johnsel> or your notes
<d1b2>
<azonenberg> for the most part it's 'i dont even know where we are"
<d1b2>
<azonenberg> we may well be all ready to go except the cpack integration
<d1b2>
<johnsel> ok so step 1 is inventarizing that
<d1b2>
<azonenberg> if you wanna identify a list of holes and file tickets for them as a starting point, go for it
<d1b2>
<johnsel> I'll make a generic issue and start filling that
<d1b2>
<johnsel> with the state is for platform X
<d1b2>
<johnsel> do we do this under scopehal-apps? or scopehal?
<d1b2>
<azonenberg> apps, yes. Long term the plan is going to be (and one of the reasons for the separate repo) to have scopehal, scopeprotocols, and ngscopeclient as three separate packages
<d1b2>
<azonenberg> so you can install just scopehal to get the drivers with minimal disk usage, protocols to get all the filters, and then ngscopeclient to get the gui too
<d1b2>
<azonenberg> to start, we will want to have a single package since we don't yet have a stable API for the libs
<d1b2>
<azonenberg> and i feel like packaging them separately at this phase would send the wrong message
<d1b2>
<johnsel> am I crazy or does scopehal-apps not have issues?
<d1b2>
<johnsel> @here - CentOS/AlmaLinux/Rocky Linux (RHEL is used a lot by pro EDA, having compatibility with rhel through an open source distro would likely be useful)
<d1b2>
<johnsel> but which of the three
<d1b2>
<johnsel> sorry for the tag
<d1b2>
<johnsel> if it tagged a lot of people
<d1b2>
<johnsel> I hope not
<d1b2>
<johnsel> I hope just scopehal people
<d1b2>
<johnsel> if not I will put myself on the shame list
<d1b2>
<johnsel> well, nobody flamed me so I guess I'm either ignored by everyone or the tag didn't hit too many people
<d1b2>
<johnsel> 🙂
<d1b2>
<david.rysk> does it make sense to do cpack if distros don't do it upstream?
<d1b2>
<david.rysk> I think I'd rather do "normal" debian scripts / rpm scripts, but also appimage/snap?
<d1b2>
<david.rysk> idk
<d1b2>
<johnsel> I think getting to the point where we can CPack at least means we have clean packages and scripts
<d1b2>
<johnsel> moving from CPack to other packaging methods should be fairly easy
<d1b2>
<azonenberg> Yeah the point of cpack is to get installable nightly build
<d1b2>
<azonenberg> not to upstream them
<_whitenotifier-1>
[scopehal-apps] Johnsel opened issue #744: Documentation: Ubuntu and Debian HTML pages have double line breaks so apt-get install x \ ... (next line) is treated as a new command, which fails - https://github.com/ngscopeclient/scopehal-apps/issues/744
<d1b2>
<johnsel> I spoke a bit with David and his pov is it's better to get cairo out of the dependencies first as it will make packaging much easier. He also said that he would work on it
<d1b2>
<johnsel> So I'm finishing inventarizing the state of things, and then moving to removing cairo
<d1b2>
<johnsel> we have a plan of approach
<d1b2>
<johnsel> I agree it's a shit dependency that needs to go