/srv/irclogs.ubuntu.com/2020/01/17/#ubuntustudio-devel.txt

studiobot<teward001> @Eickmeyer lv2vst rejected due to license mismatch.  which licensecheck and other license check systems missed.02:19
studiobot<teward001> freeze is in a few weeks fix the license issues please02:20
Eickmeyer[m]I'm aware, I've been working with RAOF on it.02:20
studiobot<Eickmeyer> I'm actually going in a different direction and dropping lv2vst from being a prereq of avldrums.lv2.02:21
studiobot<Eickmeyer> I'm just upset that it took a whole month to get to this piont.02:21
studiobot<Eickmeyer> @teward001 Go ahead with https://code.launchpad.net/~ubuntustudio-dev/+git/avldrums.lv202:23
studiobot<Eickmeyer> It now has the dropped lv2vst requirement.02:23
studiobot<teward001> ack02:24
studiobot<teward001> @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.)02:47
studiobot<teward001> the files themselves actually *say* LGPL-2.1+02:48
studiobot<Eickmeyer> Oof. My bad.02:48
studiobot<teward001> 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+02:49
studiobot<teward001> (those two individual files do differ from the rest of the fluidsynth source GPL)02:50
studiobot<Eickmeyer> 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.02:56
studiobot<Eickmeyer> @teward001 Fixed.02:57
studiobot<teward001> @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 ;)03:00
studiobot<teward001> it's how i caught it and was headscratching03:00
studiobot<teward001> checking the rest.03:00
studiobot<teward001> @Eickmeyer E:Unmatched d/copyright lines, {PKGROOT}/robtk is empty.03:02
studiobot<Eickmeyer> You didn't use quilt.03:05
studiobot<teward001> ... is there a reason I have to quilt these in?03:06
studiobot<teward001> and they're not included in the source pkg already?03:07
studiobot<teward001> directly?03:07
studiobot<teward001> or is this a package delta?03:07
tewardif this is added in via a git submodule, but not shipped directly in the package, that could be a problem03:11
tewardand should probably be packaged separately...03:11
tewardeither that or it's too late for me to be staring at this :/03:13
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:20
Eickmeyer[m]It's statically linked, afaict.03:21
tewardfor the record03:21
tewardi pulled in RAOF because i needed a second opinion / set of eyes on this03:22
tewardbecause i'm not entirely sure this package meets requirements for inclusion at the moment03:22
tewardand RAOF would be able to spotcheck my thinking03:22
tewardand ask questions I might not think about :p03:22
RAOFOr at least to rubber-duck to!03:23
tewardyep :P03:23
tewardalso, ewww, statically-linked03:23
RAOFWell, built in the source tree of, right?03:25
tewardRAOF 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 compliant03:25
teward(this takes after the nasty evil that nginx has with third party modules... but that's... kiiinda hacky and dirty)03:26
tewardIF the package won't build unless robtk is present in {ROOT}/robtk at build-time03:26
RAOFSounds like maybe you just need to repack the original tarball?03:26
studiobot<teward001> orig tarball's populated from debian/watch03:27
tewardat least, debian/watch is set to REFER to upstream for the tarball in GH03:27
RAOFOr: you *can* have multiple original tarballs, I think?03:27
RAOFYeah, but github clearly isn't providing the original tarball, because it doesn't build.03:28
tewardRAOF: correct, because GH won't populate the submodules03:28
RAOF(presumably because of submodules)03:28
tewardright03:28
tewardsooooooooo03:28
tewardif i'm reading this right it *can* be done03:28
tewardbut we'll need to populate the secondary robtk tarball at upload time03:28
RAOFSo you can't pull the tarball from github directly.03:28
RAOFSo you might as well repack.03:29
teward... unless... *checks*03:29
teward... there it is03:29
tewardhttps://github.com/x42/robtk/archive/v0.7.1.tar.gz  <-- we could just download this03:29
tewardand include @ upload time03:29
tewardwhich matches the rev the git submodule's referring ot03:29
studiobot<teward001> let me putter with this a moment03:30
studiobot<teward001> ... i think this worked, let me run this in an sbuild03:34
RAOFThe right thing to do here *might* be to package robtk separately and patch the build system to work?03:35
studiobot<teward001> that would make sense03:36
Eickmeyer[m]There you go, RAOF , now you're in with Matrix.03:36
studiobot<teward001> if it fails, i figured out how to package robtk in a separate .orig tarball as a supplementary tarball03:36
studiobot<teward001> and make sbuild and dpkg-source not whine03:36
studiobot<teward001> 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:37
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.03:38
studiobot<teward001> yeah i knew it could be done i just never had to do it.03:38
studiobot<teward001> Eickmeyer: the push back to git would just undo your patch, it wouldn't include the .orig tarball, I had to package that independently03:39
studiobot<teward001> which is why RAOF's initial suggestion is still valid, package robtk independently and patch the build system to work03:39
studiobot<teward001> because supplemental .orig tarballs need their own review03:40
studiobot<teward001> even if licensing matches up... it's a nasty NASTY hack03:40
studiobot<teward001> and it sounds like other things use robtk as well based on their upstream git data03:40
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
RAOFYup!03:41
studiobot<teward001> 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 root03:41
studiobot<teward001> unzipped the tarball into the package03:42
studiobot<teward001> and that was picked up automatically by dpkg-source because of the supplemental orig tarball03:42
studiobot<teward001> but it's a REAL nasty hack03:42
studiobot<teward001> 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* libraries03:43
Eickmeyer[m]Well, yes, but the static linking is the big problem. I'd have to sift through EVERYTHING to point somewhere else.03:44
RAOFDoes upstream not ship working tarballs?03:46
tewardthey ship a tarball, but no install afaict03:46
studiobot<teward001> yep, no makefile, no install runner, etc.  all statically linked it seems03:46
RAOFBut you can't build the tarball, because you need to separately check out robtk?03:46
studiobot<teward001> RAOF: correct, at least for avldrumls.lv203:47
RAOFOh. They don't ship a *source* tarball.03:47
studiobot<teward001> correct03:47
studiobot<teward001> Upstream does not ship a *source* tarball including robtk03:47
studiobot<teward001> because it's git submodule loaded03:47
studiobot<teward001> and i think different copyright (didn't check license)03:47
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
RAOFYou don't need debian/watch to work for that.03:48
studiobot<teward001> RAOF: which i just did... supplemental tarball03:48
RAOFManual work can be involved.03:48
studiobot<teward001> it's how i got it to build03:48
studiobot<teward001> Eickmeyer: do you have any intention of including any other packages that require robtk for a dep?03:49
studiobot<teward001> or is this the only one between now and Release date?03:49
Eickmeyer[m]teward: This is the only one.03:50
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:51
Eickmeyer[m]Manually repacking would actually be relatively easy.03:52
studiobot<teward001> we could do that03:52
studiobot<teward001> yep03:52
Eickmeyer[m]Then, what do we do about lintian when it warns about no debian/watch file?03:52
studiobot<teward001> ignore it03:52
studiobot<teward001> maybe?03:53
RAOFCorrect!03:53
Eickmeyer[m]An override then.03:53
studiobot<teward001> Eickmeyer: Or just ignore it, i don't think lack of a debian/watch is going to make a lintian failure03:53
RAOFOr you could have a debian/watch file that doesn't download a tarball.03:53
studiobot<teward001> debian/watch with just comments on the situation works03: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)03:54
studiobot<teward001> *shivers*03:54
Eickmeyer[m]Oof.03:55
studiobot<teward001> RAOF: i mean... it could be done... but that'd be... well, a headache to say the least XD03:56
studiobot<teward001> manually repacking would be easier XD03:57
Eickmeyer[m]I'm manually repacking right now. Because... oof.03:57
RAOFI don't think it'd be *that* hard, but as I said: stretch goal 😉03:58
Eickmeyer[m]teward001: I've got it repacked. You're gonna want to completely reclone the repo. The tarball is in pristine-tar.05:16
Eickmeyer[m](I had to redo the repo via --force)05:17
OvenWerksteward[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.08:27
astraljavaSo 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:10
astraljavaMaybe someone who's been an op recently could summarize (or point to some source) the standard operation procedures as of late?09:11
tewardOvenWerks: i hear ya, but we're going to have problems if `robtk` is needed in many different applications.15:12
tewardif 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 time15:13
tewardthat's the main issue there :P15: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 Basakl15:13
OvenWerksteward: if that can happen that would be ok. What gets used for x42 plugins which are also authored by RG?15:15
tewardnot sure, but i think you just gave yourselfa  research project :P15:15
tewardunless 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
tewardin which case it'll just add work :)15:16
OvenWerkshttps://packages.ubuntu.com/source/focal/x42-plugins15:17
tewardwell it looks to me like they're repacking the orig tarball themselves15:18
tewardwhich is what Eickmeyer just did for the latest headache we're working with :p15:18
tewardbut that'd make for an interesting discussion :p15:18
teward*yawns*15:18
tewardI need coffee15:18
tewardback in a while15:18
* OvenWerks is about halfway through his coffee15:18
OvenWerksteward: actually what makes more sense in this case is to add avldrums to x42-plugins (at the debian level)15:23
OvenWerksfor next cycle or whenever15:24
tewardyes, it does, you can take that up with the Debian Multimedia Team though15:27
tewardthey made a revision to the package 2 weeks ago15:27
tewardso it may be still within the sanity frame for them to get it included.15:27
tewardif they update the package in Debian we can request a sync to get it updated in Focal15:27
tewardwhich would then make my having to independently review avldrums a moot point15:27
tewardwould probably have more weight coming from you or Eickmeyer with the request rather than me though :p15:28
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:45
Eickmeyer[m]I'm uncomfortable with including the 1.0 beta with its warning dialog in an LTS; people will freak out.15:46
Eickmeyer[m]So, avldrums.lv2 is a fallback that, at this point, is likely to be used.15:47
tewardack15:47
tewardi'll look when i get enough spare cycles to peek15:47
tewardE:AtWork15:47
OvenWerksyet setbfree is a separate package. interesting.15:50
daxastraljava: 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:03
OvenWerksEickmeyer[m]: have you ever tried to logout and back in as another user while jack is running? https://bugs.launchpad.net/ubuntustudio-controls/+bug/186015216:28
ubottuLaunchpad bug 1860152 in ubuntustudio-controls "logout and login as another user gives no sound" [Undecided,New]16:28
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.16:50
Eickmeyer[m]^^^17:57
Eickmeyer[m]Oops, wrong window.17:58

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!