 @Eickmeyer lv2vst rejected due to license mismatch.  which licensecheck and other license check systems missed.
 freeze is in a few weeks fix the license issues please
[02:20] <Eickmeyer[m]> I'm aware, I've been working with RAOF on it.
 I'm actually going in a different direction and dropping lv2vst from being a prereq of avldrums.lv2.
 I'm just upset that it took a whole month to get to this piont.
 @teward001 Go ahead with https://code.launchpad.net/~ubuntustudio-dev/+git/avldrums.lv2
 It now has the dropped lv2vst requirement.
 ack
 @Eickmeyer had to ask RAOF to double-check my brain, but NACKed.  License mismatch. LGPL-2+ != LGPL-2.1+, fluidsynth files in the source are LGPL-2.1+  (LGPL-2 is Library GPL, LGPL-2.1+ is Lesser GPL.)
 the files themselves actually *say* LGPL-2.1+
 Oof. My bad.
 now, except for the two specific files you pointed at in fluidsync's license data which are LGPL-2+ (License GPL), the rest are Lesser GPL 2.1+
 (those two individual files do differ from the rest of the fluidsynth source GPL)
 I must've glossed-over that. I was trying to be thorough, but I must've missed it. It was over a month ago, so I don't quite remember.
 @teward001 Fixed.
 @Eickmeyer looking again.  Just a heads up, run `licensecheck` on the package root as well, it'll give you a bunch of insights like this too ;)
 it's how i caught it and was headscratching
 checking the rest.
 @Eickmeyer E:Unmatched d/copyright lines, {PKGROOT}/robtk is empty.
 You didn't use quilt.
 ... is there a reason I have to quilt these in?
 and they're not included in the source pkg already?
 directly?
 or is this a package delta?
[03:11] <teward> if this is added in via a git submodule, but not shipped directly in the package, that could be a problem
[03:11] <teward> and should probably be packaged separately...
[03:13] <teward> either that or it's too late for me to be staring at this :/
[03:20] <Eickmeyer[m]> teward: It's a git submodule, but everything is expecting it to be in the robtk directory. I tried including it directly, but then it whined about that not matching the upstream and failed. Using a patch was the only way to get it to work, and to provide the correct version of robtk.
[03:21] <Eickmeyer[m]> It's statically linked, afaict.
[03:21] <teward> for the record
[03:22] <teward> i pulled in RAOF because i needed a second opinion / set of eyes on this
[03:22] <teward> because i'm not entirely sure this package meets requirements for inclusion at the moment
[03:22] <teward> and RAOF would be able to spotcheck my thinking
[03:22] <teward> and ask questions I might not think about :p
[03:23] <RAOF> Or at least to rubber-duck to!
[03:23] <teward> yep :P
[03:23] <teward> also, ewww, statically-linked
[03:25] <RAOF> Well, built in the source tree of, right?
[03:25] <teward> RAOF i think the robtk/ dir was populated via a quilt patch to work around dpkg whining about the data not being included.  I can *maybe* think that a debian/rules override could be done, store robtk inside debian/robtk and then copy it into {PACKAGEROOT}/robtk but... not sure if that's package compliant
[03:26] <teward> (this takes after the nasty evil that nginx has with third party modules... but that's... kiiinda hacky and dirty)
[03:26] <teward> IF the package won't build unless robtk is present in {ROOT}/robtk at build-time
[03:26] <RAOF> Sounds like maybe you just need to repack the original tarball?
 orig tarball's populated from debian/watch
[03:27] <teward> at least, debian/watch is set to REFER to upstream for the tarball in GH
[03:27] <RAOF> Or: you *can* have multiple original tarballs, I think?
[03:28] <RAOF> Yeah, but github clearly isn't providing the original tarball, because it doesn't build.
[03:28] <teward> RAOF: correct, because GH won't populate the submodules
[03:28] <RAOF> (presumably because of submodules)
[03:28] <teward> right
[03:28] <teward> sooooooooo
[03:28] <teward> if i'm reading this right it *can* be done
[03:28] <teward> but we'll need to populate the secondary robtk tarball at upload time
[03:28] <RAOF> So you can't pull the tarball from github directly.
[03:29] <RAOF> So you might as well repack.
[03:29] <teward> ... unless... *checks*
[03:29] <teward> ... there it is
[03:29] <teward> https://github.com/x42/robtk/archive/v0.7.1.tar.gz  <-- we could just download this
[03:29] <teward> and include @ upload time
[03:29] <teward> which matches the rev the git submodule's referring ot
 let me putter with this a moment
 ... i think this worked, let me run this in an sbuild
[03:35] <RAOF> The right thing to do here *might* be to package robtk separately and patch the build system to work?
 that would make sense
[03:36] <Eickmeyer[m]> There you go, RAOF , now you're in with Matrix.
 if it fails, i figured out how to package robtk in a separate .orig tarball as a supplementary tarball
 and make sbuild and dpkg-source not whine
 but i'd like to *avoid* that if we cna.
[03:37] <RAOF> <Eickmeyer[m] "There you go, RAOF , now you're "> Ta! It did look like that was bridged!
[03:38] <Eickmeyer[m]> teward001: Yeah, I had no idea how to do that. Are you going to push that back to the git repo?
[03:38] <Eickmeyer[m]> And, I didn't even know if it could be done.
[03:38] <Eickmeyer[m]> I just went with what debuild wanted to do.
 yeah i knew it could be done i just never had to do it.
 Eickmeyer: the push back to git would just undo your patch, it wouldn't include the .orig tarball, I had to package that independently
 which is why RAOF's initial suggestion is still valid, package robtk independently and patch the build system to work
 because supplemental .orig tarballs need their own review
 even if licensing matches up... it's a nasty NASTY hack
 and it sounds like other things use robtk as well based on their upstream git data
[03:41] <Eickmeyer[m]> That's true. So now, instead of needing lv2vst as a prereq, I need robtk.
[03:41] <Eickmeyer[m]> I'm not even sure how to package it, tbh. I'll have to mess around with it.
[03:41] <RAOF> Yup!
 Eickmeyer: short form of what I did?  Downloaded the upstream robtk tarball (the submodule diff matches the tarball I pulled), stored that as avldrums.lv2_0.4.1.orig-robtk.tar.gz outside the package root
 unzipped the tarball into the package
 and that was picked up automatically by dpkg-source because of the supplemental orig tarball
 but it's a REAL nasty hack
 wonder if it'd be something like the linux headers package where all it has is the libraries, since it looks like robtk is *just* libraries
[03:44] <Eickmeyer[m]> Well, yes, but the static linking is the big problem. I'd have to sift through EVERYTHING to point somewhere else.
[03:46] <RAOF> Does upstream not ship working tarballs?
[03:46] <teward> they ship a tarball, but no install afaict
 yep, no makefile, no install runner, etc.  all statically linked it seems
[03:46] <RAOF> But you can't build the tarball, because you need to separately check out robtk?
 RAOF: correct, at least for avldrumls.lv2
[03:47] <RAOF> Oh. They don't ship a *source* tarball.
 correct
 Upstream does not ship a *source* tarball including robtk
 because it's git submodule loaded
 and i think different copyright (didn't check license)
[03:48] <RAOF> *If* this is the only place that wants robtk (for now) then you can just create a source tarball with robtk in it.
[03:48] <RAOF> You don't need debian/watch to work for that.
 RAOF: which i just did... supplemental tarball
[03:48] <RAOF> Manual work can be involved.
 it's how i got it to build
 Eickmeyer: do you have any intention of including any other packages that require robtk for a dep?
 or is this the only one between now and Release date?
[03:50] <Eickmeyer[m]> teward: This is the only one.
[03:51] <RAOF> <studiobot "<teward001> RAOF: which i just d"> I'd vaguely prefer a manually repacked tarball, because supplemental tarballs are super rare and hence weird.
[03:52] <Eickmeyer[m]> Manually repacking would actually be relatively easy.
 we could do that
 yep
[03:52] <Eickmeyer[m]> Then, what do we do about lintian when it warns about no debian/watch file?
 ignore it
 maybe?
[03:53] <RAOF> Correct!
[03:53] <Eickmeyer[m]> An override then.
 Eickmeyer: Or just ignore it, i don't think lack of a debian/watch is going to make a lintian failure
[03:53] <RAOF> Or you could have a debian/watch file that doesn't download a tarball.
 debian/watch with just comments on the situation works
[03:54] <Eickmeyer[m]> That sounds messy, but doable.
[03:54] <RAOF> (or, from memory, you could *script* tarball creation in debian/watch, but that'd be a stretch goal)
 *shivers*
[03:55] <Eickmeyer[m]> Oof.
 RAOF: i mean... it could be done... but that'd be... well, a headache to say the least XD
 manually repacking would be easier XD
[03:57] <Eickmeyer[m]> I'm manually repacking right now. Because... oof.
[03:58] <RAOF> I don't think it'd be *that* hard, but as I said: stretch goal 😉
[05:16] <Eickmeyer[m]> teward001: I've got it repacked. You're gonna want to completely reclone the repo. The tarball is in pristine-tar.
[05:17] <Eickmeyer[m]> (I had to redo the repo via --force)
[08:27] <OvenWerks> teward[m]: using system libs is a wonderful idea.... but never, please, never never ever build an audio plugin (LV1, LV2, VST) any other way but static. Anything else is a crash waiting to happen... generally as part of the best take of the day.
[09:10] <astraljava> So I just learned I was added as an op here a bit more than a week ago by rww. Cool, cheers! I suppose I should reactivate my presence here better, then. :) 
[09:11] <astraljava> Maybe someone who's been an op recently could summarize (or point to some source) the standard operation procedures as of late?
[15:12] <teward> OvenWerks: i hear ya, but we're going to have problems if `robtk` is needed in many different applications.
[15:13] <teward> if we start getting to that point pretty sure RAOF and others will start questioning why it isn't packaged separately and then just static compiled in at compile time
[15:13] <teward> that's the main issue there :P
[15:13] <teward> @Eickmeyer[m] I'll take a look in a bit, i'm in the middle of kicking things at home and bothering Robie Basakl
[15:15] <OvenWerks> teward: if that can happen that would be ok. What gets used for x42 plugins which are also authored by RG?
[15:15] <teward> not sure, but i think you just gave yourselfa  research project :P
[15:16] <teward> unless we want to manually repackage every tarball every time to include robtk BEFORE asking for sponsoring/upload (and thereby requiring you to alter pristine upstream tarball and not have a debian/watch before I get to the package for review/upload), though.
[15:16] <teward> in which case it'll just add work :)
[15:17] <OvenWerks> https://packages.ubuntu.com/source/focal/x42-plugins
[15:18] <teward> well it looks to me like they're repacking the orig tarball themselves
[15:18] <teward> which is what Eickmeyer just did for the latest headache we're working with :p
[15:18] <teward> but that'd make for an interesting discussion :p
[15:18] <teward> *yawns*
[15:18] <teward> I need coffee
[15:18] <teward> back in a while
[15:18]  * OvenWerks is about halfway through his coffee
[15:23] <OvenWerks> teward: actually what makes more sense in this case is to add avldrums to x42-plugins (at the debian level)
[15:24] <OvenWerks> for next cycle or whenever
[15:27] <teward> yes, it does, you can take that up with the Debian Multimedia Team though
[15:27] <teward> they made a revision to the package 2 weeks ago
[15:27] <teward> so it may be still within the sanity frame for them to get it included.
[15:27] <teward> if they update the package in Debian we can request a sync to get it updated in Focal
[15:27] <teward> which would then make my having to independently review avldrums a moot point
[15:28] <teward> would probably have more weight coming from you or Eickmeyer with the request rather than me though :p
[15:45] <Eickmeyer[m]> Actually, teward and OvenWerks , that would be a Ross Gammon thing.
[15:45] <Eickmeyer[m]>  BUT, this is a more time-sensitive issue than that since this is a backup plan for in the likely event the hydrogen team doesn't get off their butts and release their 1.0 version which is Qt5 as opposed to the current Qt4 version.
[15:46] <Eickmeyer[m]> I'm uncomfortable with including the 1.0 beta with its warning dialog in an LTS; people will freak out.
[15:47] <Eickmeyer[m]> So, avldrums.lv2 is a fallback that, at this point, is likely to be used.
[15:47] <teward> ack
[15:47] <teward> i'll look when i get enough spare cycles to peek
[15:47] <teward> E:AtWork
[15:50] <OvenWerks> yet setbfree is a separate package. interesting.
[16:03] <dax> astraljava: to clarify: you already had op here, you got an email because core channels (including this one) are supposed to have matching Launchpad groups for their channel ops, but this one didn't, and I needed one for something, so I created it and added y'all :)
[16:28] <OvenWerks> Eickmeyer[m]: have you ever tried to logout and back in as another user while jack is running? https://bugs.launchpad.net/ubuntustudio-controls/+bug/1860152
[16:50] <Eickmeyer[m]> No, never tried that.
[16:50] <Eickmeyer[m]> ﻿teward, OvenWerks, tsimonq2  : I just prodded the Hydrogen team via github, we'll see what happens. I don't expect much.
[17:57] <Eickmeyer[m]> ^^^
[17:58] <Eickmeyer[m]> Oops, wrong window.