[L2Ork-dev] Linux dependencies in README.md build guide

Jonathan Wilkes jon.w.wilkes at gmail.com
Sat Oct 10 15:52:24 EDT 2020 

On Sat, Oct 10, 2020 at 1:01 PM Albert Graef <aggraef at gmail.com> wrote:
>
> Yes, I understand. That's possible, and it's possible to create unsigned binary packages as well. But there's one place where an email address is needed (even if it's a fake one), and that's the creation of the changelog entry (which can't be avoided).

You can use one of the emails of the three current maintainers which
are already public knowledge. I'd be fine with that as a default.

>
> So I still need to massage the debuild stuff a bit to make it work the way you want, and test it.

No problem. And even if it's a separate step before calling `make` to
install the dependencies, that's fine. I just want to be able to use
the dep info that you've already tested inside the debbuild directory.
Copying and sync'ing that info with some other source just asks for
trouble as countless bug reports to the list and the issue tracker
prove.

> This may take a few days, since I'm currently busy with other things, sorry. I understand that you want to go ahead with your new build system in the meantime, but you can just continue to use the existing deb building process for now. You'll just have to do the trivial edits to the linux_make/debian/control file that I suggested earlier to make the resulting packages work on 20.04 for now. Once a proper solution is implemented, it should be a drop-in replacement for what we have now.

That's fine. I have a lot else to look at in the meantime, and the old
build system seem to be chugging along atm.

>
> And yes, I also resort to sarcasm when talking about Debian packaging. ;-) I readily admit that for end users it does the job, and for distro managers the static tests it provides may occasionally be helpful. But for developers and package maintainers, if you have to maintain a big and complicated package, IMHO it's just a big pita. Arch's pacman is *much* easier.

My problem is that it isn't doing its job for the end user. Stable is
already too out of date to use many of the extant tutorials for what
are now basic things like display scaling for 4k and gpu-accelerated
firefox. So using Buster gets you a flawed view of the state of
Gnu/Linux-- desktop scaling is actually available in both stable Gnome
*and* XFCE. If you use Buster you must resort to all the tedious
workarounds that have given Linux a bad name over the years.

There are many other such problems that create a twisted situation
where "stable" means "out of date" and "testing" means "probably
stable, but not officially supported as such."

Somewhat related-- have you taken a look at makeself before? It's a
clever route around a lot of the packaging problems which plague
Linux. Virtualbox actually ships a Linux version that leverages it,
and I used it to install virtualbox on Bullseye.

-Jonathan

>
> Best,
> Albert
>
>
>
> On Sat, Oct 10, 2020 at 6:30 PM Jonathan Wilkes <jon.w.wilkes at gmail.com> wrote:
>>
>> Albert-- as far as the toplevel makefile, I'm only interested in
>> producing the deb installer itself as potential default `make`
>> behavior. If you need convenience recipes for the source balls that
>> are stamped with the unforgeable GPG hologram stickers that come free
>> with purchase of 1990s-era security theater, that's fine. But the
>> *only* time I've ever seen one of those things get used was when
>> someone on the list complained after they erroneously downloaded it
>> off github before I started mirroring the gitlab code there.
>>
>> Also-- please, please tell me that Debian does *not* have a standard
>> tool to go into their standard directory structure, find the
>> dependencies listed in the control file, and install them on the host
>> machine. I'd like to continue making fun of Debian policy after
>> discovering that they don't ship Virtualbox with bullseye until
>> bullseye ships as stable-- because then, and *only* then can they ship
>> it as a backport and properly obey their increasingly unworkable set
>> of packaging policies. (Somewhere in there is a joke about a sheet
>> with a hole cut in the middle...)
>>
>> Ok, I'm now blatantly breaking rule #1 of the code of conduct. I will stop.
>>
>> -Jonathan
>>
>> On Sat, Oct 10, 2020 at 10:32 AM Ivica Bukvic <ico at vt.edu> wrote:
>> >
>> > So, I just checked the disis_wiimote on Linux Ubuntu 20.04 with a freshly built snapshot of the HEAD prior to the reverting of !579 and the disis_wiimote works as advertised. Please note it is designed to work only with genuine Wiimotes. Other knock off devices are not guaranteed to work and may or may not work. I don't believe anyone has yet successfully reverse-engineered the wireless nunchucks.
>> >
>> > Best,
>> >
>> > Ico
>> >
>> > --
>> > Ivica Ico Bukvic, D.M.A.
>> > Director, Creativity + Innovation
>> > Director, Human-Centered Design iPhD
>> > Institute for Creativity, Arts, and Technology
>> >
>> > Virginia Tech
>> > Creative Technologies in Music
>> > School of Performing Arts – 0141
>> > Blacksburg, VA 24061
>> > (540) 231-6139
>> > ico at vt.edu
>> >
>> > ci.icat.vt.edu
>> > hcd.icat.vt.edu
>> > www.icat.vt.edu
>> > www.performingarts.vt.edu
>> > l2ork.icat.vt.edu
>> > ico.bukvic.net
>> >
>> >
>> >
>> > On Fri, Oct 9, 2020 at 2:35 PM Ivica Bukvic <ico at vt.edu> wrote:
>> >>
>> >> Let me investigate first Albert's report and then I will propose the next steps. AFAIR libcwiid is Linux/OSX only. Last time I dabbled with the Windows BT stack I concluded it was worse than OSX's (at least at that point in time).
>> >>
>> >> Best,
>> >>
>> >> Ico
>> >>
>> >> --
>> >> Ivica Ico Bukvic, D.M.A.
>> >> Director, Creativity + Innovation
>> >> Institute for Creativity, Arts, and Technology
>> >>
>> >> Virginia Tech
>> >> Creative Technologies in Music
>> >> School of Performing Arts – 0141
>> >> Blacksburg, VA 24061
>> >> (540) 231-6139
>> >> ico at vt.edu
>> >>
>> >> www.icat.vt.edu
>> >> www.performingarts.vt.edu
>> >> l2ork.icat.vt.edu
>> >> ico.bukvic.net
>> >>
>> >> On Fri, Oct 9, 2020, 14:00 Jonathan Wilkes <jon.w.wilkes at gmail.com> wrote:
>> >>>
>> >>> > I think that it's the way to go if disis_wiimote is ever going to be rewritten.
>> >>>
>> >>> What about Windows support? I believe that external was written at a
>> >>> time when Pd-l2ork only ran under Linux. Is it even possible to
>> >>> support the same interface with whatever carnival of bluetooth animals
>> >>> Windows has on offer?
>> >>>
>> >>> Or, if we want to just restrict it to Linux, I'm happy to help get
>> >>> this ported if Albert is familiar with the relevant API to use.
>> >>>
>> >>> -Jonathan
>> >>>
>> >>> On Fri, Oct 9, 2020 at 1:56 PM Jonathan Wilkes <jon.w.wilkes at gmail.com> wrote:
>> >>> >
>> >>> > On Fri, Oct 9, 2020 at 1:54 PM Jonathan Wilkes <jon.w.wilkes at gmail.com> wrote:
>> >>> > >
>> >>> > > On Fri, Oct 9, 2020 at 1:39 PM Albert Graef <aggraef at gmail.com> wrote:
>> >>> > > >
>> >>> > > > No, make just invokes tar_em_up.sh, which then on Debian-based systems invokes dpkg-deb (using the packages/linux_make/debian/control file). The debuild stuff is completely separate and requires some additional tools to be installed (debuild et al). There are some (rather terse) instructions in debuild/Makefile, which probably won't make much sense unless you've used debuild before (or read the Ubuntu packaging guide).
>> >>> > > >
>> >>> > > > So the quick and dirty solution is to just fix the dependencies in the packages/linux_make/debian/control file. I see that there's a Depends: python line in there, maybe change that to something that will work on 20.04, such as Depends: python2. (That Depends: line *must* be there, however, because it will be replaced during the build, adding the remaining runtime dependencies which are figured out automagically in linux_make/Makefile. You ought to know this, because according to git blame you wrote that part of the Makefile yourself in 2017. ;-)
>> >>> > >
>> >>> > > I wholeheartedly admit I no longer understand the build system. :)
>> >>> > >
>> >>> > > I don't want two sources of truth for Debian dependencies. If a deb is
>> >>> > > to be built I want to use whatever system you are using with the
>> >>> > > dependency graph you've specified and tested. Otherwise I'll be
>> >>> > > hooking up new runners with an alternate, craggy build process, and
>> >>> > > users *will* magnetically become attracted to these nonstandard builds
>> >>> > > and complain about the crags on the list. (Not to mention the fact
>> >>> > > that I'm running test regressions on a different final product than
>> >>> > > you're releasing.)
>> >>> > >
>> >>> > > Is there a way we can hard-code `make` on debian to use your debbuild
>> >>> > > by default?
>> >>> >
>> >>> > Well, by hard-coded I mean: when the user does `make` and the build
>> >>> > system has decided it's going to build a deb, then it should *only* do
>> >>> > so using your debbuild process. Otherwise you get problems like what
>> >>> > we have currently where both Ico and I are reporting "bugs" that are
>> >>> > actually solved in a different directory of the repo.
>> >>> >
>> >>> > -Jonathan
>> >>> >
>> >>> > > I don't care what extra tools are needed-- if users want
>> >>> > > to build a deb it should be *exactly* the same process as what we use
>> >>> > > to release.
>> >>> > >
>> >>> > > -Jonathan
>> >>> > >
>> >>> > > >
>> >>> > > > Albert
>> >>> > > >
>> >>> > > >
>> >>> > > > On Fri, Oct 9, 2020 at 7:07 PM Jonathan Wilkes <jon.w.wilkes at gmail.com> wrote:
>> >>> > > >>
>> >>> > > >> I built using `make` in the main repository directory. Doesn't that
>> >>> > > >> leverage your control file from the debbuild directory?
>> >>> > > >>
>> >>> > > >> -Jonathan
>> >>> > > >>
>> >>> > > >> On Fri, Oct 9, 2020 at 12:28 PM Albert Graef <aggraef at gmail.com> wrote:
>> >>> > > >> >
>> >>> > > >> > On Fri, Oct 9, 2020 at 5:24 PM Jonathan Wilkes <jon.w.wilkes at gmail.com> wrote:
>> >>> > > >> >>
>> >>> > > >> >> But your control file has "python" under the "Suggests" heading.
>> >>> > > >> >>
>> >>> > > >> >> Does "Suggests" have an alternate meaning in the Debianese dialect of Vogon? :)
>> >>> > > >> >
>> >>> > > >> >
>> >>> > > >> > I don't think so. The dh-python dependency is a much more likely candidate, but that's a build dependency. But it's hard to say what the cause of the issue is without at least having a copy of the control file that you used. Better yet, send me the entire .deb you built in private mail so that I can have a look.
>> >>> > > >> >
>> >>> > > >> > Yeah, Debian packaging is a real nightmare. I have no doubts that it was actually invented by the Vogons. ;-) And it doesn't help that I have little to no experience with those low-level tools like dpkg-deb. I always use debuild instead.
>> >>> > > >> >
>> >>> > > >> > Albert
>> >>> > > >> >
>> >>> > > >> >
>> >>> > > >> >>
>> >>> > > >> >> -Jonathan
>> >>> > > >> >>
>> >>> > > >> >> On Fri, Oct 9, 2020 at 8:17 AM Ivica Bukvic <ico at vt.edu> wrote:
>> >>> > > >> >> >
>> >>> > > >> >> > Aaand, yet another reply. The python and gtk are needed for wmgui (or something like it) which is a front-end demo app, so it seems to me we would want to remove those as well if we are going to strip the python requirement.
>> >>> > > >> >> >
>> >>> > > >> >> > --
>> >>> > > >> >> > Ivica Ico Bukvic, D.M.A.
>> >>> > > >> >> > Director, Creativity + Innovation
>> >>> > > >> >> > Director, Human-Centered Design iPhD
>> >>> > > >> >> > Institute for Creativity, Arts, and Technology
>> >>> > > >> >> >
>> >>> > > >> >> > Virginia Tech
>> >>> > > >> >> > Creative Technologies in Music
>> >>> > > >> >> > School of Performing Arts – 0141
>> >>> > > >> >> > Blacksburg, VA 24061
>> >>> > > >> >> > (540) 231-6139
>> >>> > > >> >> > ico at vt.edu
>> >>> > > >> >> >
>> >>> > > >> >> > ci.icat.vt.edu
>> >>> > > >> >> > hcd.icat.vt.edu
>> >>> > > >> >> > www.icat.vt.edu
>> >>> > > >> >> > www.performingarts.vt.edu
>> >>> > > >> >> > l2ork.icat.vt.edu
>> >>> > > >> >> > ico.bukvic.net
>> >>> > > >> >> >
>> >>> > > >> >> >
>> >>> > > >> >> >
>> >>> > > >> >> > On Fri, Oct 9, 2020 at 8:12 AM Ivica Bukvic <ico at vt.edu> wrote:
>> >>> > > >> >> >>
>> >>> > > >> >> >> Forgot to add, since libcwiid we use is in-house, we could potentially consider removing the python requirement from it. I am, however, really rusty as far as makefiles are concerned and could use help with this one, should anyone feel inclined to assist. Not sure if purr-data is pulling from my github libcwiid repo or maintaining a local copy.
>> >>> > > >> >> >>
>> >>> > > >> >> >> Best,
>> >>> > > >> >> >>
>> >>> > > >> >> >> Ico
>> >>> > > >> >> >>
>> >>> > > >> >> >> --
>> >>> > > >> >> >> Ivica Ico Bukvic, D.M.A.
>> >>> > > >> >> >> Director, Creativity + Innovation
>> >>> > > >> >> >> Director, Human-Centered Design iPhD
>> >>> > > >> >> >> Institute for Creativity, Arts, and Technology
>> >>> > > >> >> >>
>> >>> > > >> >> >> Virginia Tech
>> >>> > > >> >> >> Creative Technologies in Music
>> >>> > > >> >> >> School of Performing Arts – 0141
>> >>> > > >> >> >> Blacksburg, VA 24061
>> >>> > > >> >> >> (540) 231-6139
>> >>> > > >> >> >> ico at vt.edu
>> >>> > > >> >> >>
>> >>> > > >> >> >> ci.icat.vt.edu
>> >>> > > >> >> >> hcd.icat.vt.edu
>> >>> > > >> >> >> www.icat.vt.edu
>> >>> > > >> >> >> www.performingarts.vt.edu
>> >>> > > >> >> >> l2ork.icat.vt.edu
>> >>> > > >> >> >> ico.bukvic.net
>> >>> > > >> >> >>
>> >>> > > >> >> >>
>> >>> > > >> >> >>
>> >>> > > >> >> >> On Fri, Oct 9, 2020 at 8:10 AM Ivica Bukvic <ico at vt.edu> wrote:
>> >>> > > >> >> >>>
>> >>> > > >> >> >>> I haven't tested the recent Bluez 5 version. If you are using newer wiimoteplus that has motion plus integrated, you will want to connect with the sync button found next to the battery. I haven't tested the xwiimote driver, but not so long ago, the in-house libcwiid I maintained was the only driver that allowed for complete access to Wiimote's functionality, including the interleaved mode that uses both plus and nunchuk. It is also rock solid. To this day, we still use it in L2Ork and have tested it with 24 simultaneous Wiimote connections in the same room without any issues.
>> >>> > > >> >> >>>
>> >>> > > >> >> >>> I just upgraded my Linux laptop to Ubuntu 20.04 and am happy to test all this. However, I am unable to even build the latest HEAD. Below are relevant errors:
>> >>> > > >> >> >>>
>> >>> > > >> >> >>> gcc -g -Wall -W -DHAVE_CONFIG_H -I/home/l2orkist/Downloads/purr-data-build/externals/disis/cwiid/common/include -I../libcwiid -DWMINPUT_CONFIG_DIR=\"/home/l2orkist/Downloads/purr-data-build/packages/linux_make/build/usr/etc/cwiid/wminput\" -DCWIID_PLUGINS_DIR=\"/home/l2orkist/Downloads/purr-data-build/packages/linux_make/build/usr/lib/cwiid/plugins\"    -c -o py_plugin.o py_plugin.c
>> >>> > > >> >> >>> Package python-2.7 was not found in the pkg-config search path.
>> >>> > > >> >> >>> Perhaps you should add the directory containing `python-2.7.pc'
>> >>> > > >> >> >>> to the PKG_CONFIG_PATH environment variable
>> >>> > > >> >> >>> No package 'python-2.7' found
>> >>> > > >> >> >>> py_plugin.c:38:10: fatal error: Python.h: No such file or directory
>> >>> > > >> >> >>>    38 | #include "Python.h"
>> >>> > > >> >> >>>       |          ^~~~~~~~~~
>> >>> > > >> >> >>> compilation terminated.
>> >>> > > >> >> >>>
>> >>> > > >> >> >>> In trying to install dependencies from the installation guide, I get:
>> >>> > > >> >> >>>
>> >>> > > >> >> >>> sudo apt-get install bison flex automake libasound2-dev \
>> >>> > > >> >> >>> >       libjack-jackd2-dev libtool libbluetooth-dev libgl1-mesa-dev \
>> >>> > > >> >> >>> >       libglu1-mesa-dev libglew-dev libmagick++-dev libftgl-dev \
>> >>> > > >> >> >>> >       libgmerlin-dev libgmerlin-avdec-dev libavifile-0.7-dev \
>> >>> > > >> >> >>> >       libmpeg3-dev libquicktime-dev libv4l-dev libraw1394-dev \
>> >>> > > >> >> >>> >       libdc1394-22-dev libfftw3-dev libvorbis-dev ladspa-sdk \
>> >>> > > >> >> >>> >       dssi-dev tap-plugins invada-studio-plugins-ladspa blepvco \
>> >>> > > >> >> >>> >       swh-plugins mcp-plugins cmt blop slv2-jack omins rev-plugins \
>> >>> > > >> >> >>> >       libslv2-dev dssi-utils vco-plugins wah-plugins fil-plugins \
>> >>> > > >> >> >>> >       mda-lv2 libmp3lame-dev libspeex-dev libgsl0-dev \
>> >>> > > >> >> >>> >       portaudio19-dev liblua5.3-dev python-dev libsmpeg0 libjpeg62-turbo \
>> >>> > > >> >> >>> >       flite1-dev libgsm1-dev libgtk2.0-dev git libstk0-dev \
>> >>> > > >> >> >>> >       libfluidsynth-dev fluid-soundfont-gm byacc
>> >>> > > >> >> >>> E: Package 'slv2-jack' has no installation candidate
>> >>> > > >> >> >>> E: Package 'libjpeg62-turbo' has no installation candidate
>> >>> > > >> >> >>>
>> >>> > > >> >> >>> Any thoughts on how to proceed?
>> >>> > > >> >> >>>
>> >>> > > >> >> >>> Best,
>> >>> > > >> >> >>>
>> >>> > > >> >> >>> Ico
>> >>> > > >> >> >>>
>> >>> > > >> >> >>> --
>> >>> > > >> >> >>> Ivica Ico Bukvic, D.M.A.
>> >>> > > >> >> >>> Director, Creativity + Innovation
>> >>> > > >> >> >>> Director, Human-Centered Design iPhD
>> >>> > > >> >> >>> Institute for Creativity, Arts, and Technology
>> >>> > > >> >> >>>
>> >>> > > >> >> >>> Virginia Tech
>> >>> > > >> >> >>> Creative Technologies in Music
>> >>> > > >> >> >>> School of Performing Arts – 0141
>> >>> > > >> >> >>> Blacksburg, VA 24061
>> >>> > > >> >> >>> (540) 231-6139
>> >>> > > >> >> >>> ico at vt.edu
>> >>> > > >> >> >>>
>> >>> > > >> >> >>> ci.icat.vt.edu
>> >>> > > >> >> >>> hcd.icat.vt.edu
>> >>> > > >> >> >>> www.icat.vt.edu
>> >>> > > >> >> >>> www.performingarts.vt.edu
>> >>> > > >> >> >>> l2ork.icat.vt.edu
>> >>> > > >> >> >>> ico.bukvic.net
>> >>> > > >> >> >>>
>> >>> > > >> >> >>>
>> >>> > > >> >> >>>
>> >>> > > >> >> >>> On Fri, Oct 9, 2020 at 12:15 AM Albert Graef <aggraef at gmail.com> wrote:
>> >>> > > >> >> >>>>
>> >>> > > >> >> >>>> Thanks, Ico.
>> >>> > > >> >> >>>>
>> >>> > > >> >> >>>> Yes, it seems that cwiid is the one which needs it. Looking at the source code in externals/disis/cwiid, there's a configure script there which checks for Python, and a septup.py script that gets run during the build. There's no actual Python C API code being linked there, as far as I can tell. But from unsuccessful OBS builds I know that it will fail with an error when running configure and Python is not installed, and I also seem to recall that Python3 didn't work either, it really needs Python2 for some reason. Unfortunately, the OBS doesn't keep logs of older builds, so all this is from the top of my head, but that's how I remember it.
>> >>> > > >> >> >>>>
>> >>> > > >> >> >>>> Talking about this external, can anyone running a *current* Linux system (Arch or Ubuntu 20.04+) with a recent Bluez 5 version confirm that disis_wiimote still works there? I'm asking because I could never make it work, it just doesn't find my Wiimote (which works fine with the xwiimote kernel driver). If I'm not mistaken, disis_wiimote still employs some user space drivers and utilities which aren't supported in Bluez 5 any more. But if anyone has it actually working on Bluez 5 then I'd really like to hear about it!
>> >>> > > >> >> >>>>
>> >>> > > >> >> >>>> Thanks,
>> >>> > > >> >> >>>> Albert
>> >>> > > >> >> >>>>
>> >>> > > >> >> >>>>
>> >>> > > >> >> >>>> On Fri, Oct 9, 2020 at 4:51 AM Ivica Bukvic <ico at vt.edu> wrote:
>> >>> > > >> >> >>>>>
>> >>> > > >> >> >>>>> I believe that is/was for pyext which requires flext. I thought we were not building flext externals anymore? There may be also a requirement for building the libcwiid since it has some gtk and/or python demo apps that get built with it and which we do not need.
>> >>> > > >> >> >>>>>
>> >>> > > >> >> >>>>> Best,
>> >>> > > >> >> >>>>>
>> >>> > > >> >> >>>>> Ico
>> >>> > > >> >> >>>>>
>> >>> > > >> >> >>>>> --
>> >>> > > >> >> >>>>> Ivica Ico Bukvic, D.M.A.
>> >>> > > >> >> >>>>> Director, Creativity + Innovation
>> >>> > > >> >> >>>>> Institute for Creativity, Arts, and Technology
>> >>> > > >> >> >>>>>
>> >>> > > >> >> >>>>> Virginia Tech
>> >>> > > >> >> >>>>> Creative Technologies in Music
>> >>> > > >> >> >>>>> School of Performing Arts – 0141
>> >>> > > >> >> >>>>> Blacksburg, VA 24061
>> >>> > > >> >> >>>>> (540) 231-6139
>> >>> > > >> >> >>>>> ico at vt.edu
>> >>> > > >> >> >>>>>
>> >>> > > >> >> >>>>> www.icat.vt.edu
>> >>> > > >> >> >>>>> www.performingarts.vt.edu
>> >>> > > >> >> >>>>> l2ork.icat.vt.edu
>> >>> > > >> >> >>>>> ico.bukvic.net
>> >>> > > >> >> >>>>>
>> >>> > > >> >> >>>>> On Thu, Oct 8, 2020, 18:26 Jonathan Wilkes <jon.w.wilkes at gmail.com> wrote:
>> >>> > > >> >> >>>>>>
>> >>> > > >> >> >>>>>> Also-- bullseye (testing) no longer has a "python" package, just
>> >>> > > >> >> >>>>>> python2 and python3.
>> >>> > > >> >> >>>>>>
>> >>> > > >> >> >>>>>> So if we can just get rid of the python dependency altogether that
>> >>> > > >> >> >>>>>> would be ideal. (Unless this is some kind of pdpython external...)
>> >>> > > >> >> >>>>>>
>> >>> > > >> >> >>>>>> -Jonathan
>> >>> > > >> >> >>>>>>
>> >>> > > >> >> >>>>>> On Thu, Oct 8, 2020 at 6:16 PM Jonathan Wilkes <jon.w.wilkes at gmail.com> wrote:
>> >>> > > >> >> >>>>>> >
>> >>> > > >> >> >>>>>> > On Thu, Oct 8, 2020 at 5:55 PM Albert Graef <aggraef at gmail.com> wrote:
>> >>> > > >> >> >>>>>> > >
>> >>> > > >> >> >>>>>> > > On Thu, Oct 8, 2020 at 11:12 PM Jonathan Wilkes <jon.w.wilkes at gmail.com> wrote:
>> >>> > > >> >> >>>>>> > >>
>> >>> > > >> >> >>>>>> > >> 1. Why are slv2-jack and libslv2-dev build dependencies of Purr Data?
>> >>> > > >> >> >>>>>> > >> What does LV2 support in Jack have to do with Purr Data?
>> >>> > > >> >> >>>>>> > >
>> >>> > > >> >> >>>>>> > >
>> >>> > > >> >> >>>>>> > > I assume that you're talking about the Debian packaging stuff in purr-data/packages/linux_make/debian, which is probably severely outdated (those slv2 deps certainly are). Maybe you want to have a look at my debuild control file (purr-data/debuild/debian/control) and update the control file in linux_make/debian accordingly. The debuild stuff is always up-to-date and known to work with every Debian/Ubuntu version younger than Stretch and Xenial, because I'm using it to build packages on the OBS.
>> >>> > > >> >> >>>>>> >
>> >>> > > >> >> >>>>>> > Ah, I see. Hm, rather than the old hard-coded deps I should just put a
>> >>> > > >> >> >>>>>> > line to fetch those deps from that file.
>> >>> > > >> >> >>>>>> >
>> >>> > > >> >> >>>>>> > >
>> >>> > > >> >> >>>>>> > >> 2. What is python-dev doing in there? If it is actually needed, is the
>> >>> > > >> >> >>>>>> > >> dependency on Python 2 or Python 3?
>> >>> > > >> >> >>>>>> > >
>> >>> > > >> >> >>>>>> > >
>> >>> > > >> >> >>>>>> > > That's needed to build one of the DISIS externals, I forgot which one it was, but Ico should know. And yes, that's really the Python2 version that it needs, which causes quite some headaches if you want to build Purr on both old and new Debian/Ubuntu versions. But you can have a look at purr-data/debuild/debian/control to see how I solved this in the OBS builds. It would be good if we could just get rid of that Python2 dependency, since Python2 is pretty much on its way out.
>> >>> > > >> >> >>>>>> >
>> >>> > > >> >> >>>>>> > Ok, my list vs. your "Build-Depends":
>> >>> > > >> >> >>>>>> >
>> >>> > > >> >> >>>>>> > 1. I've got libjack-jackd2-dev while you have libjack-dev. Any benefit
>> >>> > > >> >> >>>>>> > to one or the other?
>> >>> > > >> >> >>>>>> >
>> >>> > > >> >> >>>>>> > 2. I've got libglu1-mesa-dev while you do not. Any reason I still need that one?
>> >>> > > >> >> >>>>>> >
>> >>> > > >> >> >>>>>> > 3. I have libgmerlin-avdec-dev while you do not. But we both have
>> >>> > > >> >> >>>>>> > libgmerlin-avdec-dev.
>> >>> > > >> >> >>>>>> >
>> >>> > > >> >> >>>>>> > 4. I have dssi-dev while you do not. But you have dssi-utils under "Depends"
>> >>> > > >> >> >>>>>> >
>> >>> > > >> >> >>>>>> > 5. As mentioned I have slv2-jack and libslv2-dev, you don't.
>> >>> > > >> >> >>>>>> >
>> >>> > > >> >> >>>>>> > 6. I have libgsl0-dev, you have libgsl-dev
>> >>> > > >> >> >>>>>> >
>> >>> > > >> >> >>>>>> > 7. I have portaudio19-dev, you don't.
>> >>> > > >> >> >>>>>> >
>> >>> > > >> >> >>>>>> > 8. I have libsmpeg0, you don't.
>> >>> > > >> >> >>>>>> >
>> >>> > > >> >> >>>>>> > 9. I have libjpeg62-turbo, you have libjpeg-dev.
>> >>> > > >> >> >>>>>> >
>> >>> > > >> >> >>>>>> > 10. I have git, you don't
>> >>> > > >> >> >>>>>> >
>> >>> > > >> >> >>>>>> > 11. I have byacc, you don't.
>> >>> > > >> >> >>>>>> >
>> >>> > > >> >> >>>>>> > Hm... wonder why we have libgtk2.0-dev-- was that added for nw.js?
>> >>> > > >> >> >>>>>> >
>> >>> > > >> >> >>>>>> > -Jonathan
>> >>> > > >> >> >>>>>> >
>> >>> > > >> >> >>>>>> >
>> >>> > > >> >> >>>>>> > >
>> >>> > > >> >> >>>>>> > > Albert
>> >>> > > >> >> >>>>>> > >
>> >>> > > >> >> >>>>>> > >>
>> >>> > > >> >> >>>>>> > >> -Jonathan
>> >>> > > >> >> >>>>>> > >> _______________________________________________
>> >>> > > >> >> >>>>>> > >> L2Ork-dev mailing list
>> >>> > > >> >> >>>>>> > >> L2Ork-dev at disis.music.vt.edu
>> >>> > > >> >> >>>>>> > >> https://disis.music.vt.edu/listinfo/l2ork-dev
>> >>> > > >> >> >>>>>> > >
>> >>> > > >> >> >>>>>> > >
>> >>> > > >> >> >>>>>> > >
>> >>> > > >> >> >>>>>> > > --
>> >>> > > >> >> >>>>>> > > Dr. Albert Gr"af
>> >>> > > >> >> >>>>>> > > Computer Music Research Group, JGU Mainz, Germany
>> >>> > > >> >> >>>>>> > > Email: aggraef at gmail.com, web: https://agraef.github.io/
>> >>> > > >> >> >>>>>> > > _______________________________________________
>> >>> > > >> >> >>>>>> > > L2Ork-dev mailing list
>> >>> > > >> >> >>>>>> > > L2Ork-dev at disis.music.vt.edu
>> >>> > > >> >> >>>>>> > > https://disis.music.vt.edu/listinfo/l2ork-dev
>> >>> > > >> >> >>>>>> _______________________________________________
>> >>> > > >> >> >>>>>> L2Ork-dev mailing list
>> >>> > > >> >> >>>>>> L2Ork-dev at disis.music.vt.edu
>> >>> > > >> >> >>>>>> https://disis.music.vt.edu/listinfo/l2ork-dev
>> >>> > > >> >> >>>>>
>> >>> > > >> >> >>>>> _______________________________________________
>> >>> > > >> >> >>>>> L2Ork-dev mailing list
>> >>> > > >> >> >>>>> L2Ork-dev at disis.music.vt.edu
>> >>> > > >> >> >>>>> https://disis.music.vt.edu/listinfo/l2ork-dev
>> >>> > > >> >> >>>>
>> >>> > > >> >> >>>>
>> >>> > > >> >> >>>>
>> >>> > > >> >> >>>> --
>> >>> > > >> >> >>>> Dr. Albert Gr"af
>> >>> > > >> >> >>>> Computer Music Research Group, JGU Mainz, Germany
>> >>> > > >> >> >>>> Email: aggraef at gmail.com, web: https://agraef.github.io/
>> >>> > > >> >> >>>> _______________________________________________
>> >>> > > >> >> >>>> L2Ork-dev mailing list
>> >>> > > >> >> >>>> L2Ork-dev at disis.music.vt.edu
>> >>> > > >> >> >>>> https://disis.music.vt.edu/listinfo/l2ork-dev
>> >>> > > >> >> >
>> >>> > > >> >> > _______________________________________________
>> >>> > > >> >> > L2Ork-dev mailing list
>> >>> > > >> >> > L2Ork-dev at disis.music.vt.edu
>> >>> > > >> >> > https://disis.music.vt.edu/listinfo/l2ork-dev
>> >>> > > >> >> _______________________________________________
>> >>> > > >> >> L2Ork-dev mailing list
>> >>> > > >> >> L2Ork-dev at disis.music.vt.edu
>> >>> > > >> >> https://disis.music.vt.edu/listinfo/l2ork-dev
>> >>> > > >> >
>> >>> > > >> >
>> >>> > > >> >
>> >>> > > >> > --
>> >>> > > >> > Dr. Albert Gr"af
>> >>> > > >> > Computer Music Research Group, JGU Mainz, Germany
>> >>> > > >> > Email: aggraef at gmail.com, web: https://agraef.github.io/
>> >>> > > >> > _______________________________________________
>> >>> > > >> > L2Ork-dev mailing list
>> >>> > > >> > L2Ork-dev at disis.music.vt.edu
>> >>> > > >> > https://disis.music.vt.edu/listinfo/l2ork-dev
>> >>> > > >> _______________________________________________
>> >>> > > >> L2Ork-dev mailing list
>> >>> > > >> L2Ork-dev at disis.music.vt.edu
>> >>> > > >> https://disis.music.vt.edu/listinfo/l2ork-dev
>> >>> > > >
>> >>> > > >
>> >>> > > >
>> >>> > > > --
>> >>> > > > Dr. Albert Gr"af
>> >>> > > > Computer Music Research Group, JGU Mainz, Germany
>> >>> > > > Email: aggraef at gmail.com, web: https://agraef.github.io/
>> >>> > > > _______________________________________________
>> >>> > > > L2Ork-dev mailing list
>> >>> > > > L2Ork-dev at disis.music.vt.edu
>> >>> > > > https://disis.music.vt.edu/listinfo/l2ork-dev
>> >>> _______________________________________________
>> >>> L2Ork-dev mailing list
>> >>> L2Ork-dev at disis.music.vt.edu
>> >>> https://disis.music.vt.edu/listinfo/l2ork-dev
>> >
>> > _______________________________________________
>> > L2Ork-dev mailing list
>> > L2Ork-dev at disis.music.vt.edu
>> > https://disis.music.vt.edu/listinfo/l2ork-dev
>> _______________________________________________
>> L2Ork-dev mailing list
>> L2Ork-dev at disis.music.vt.edu
>> https://disis.music.vt.edu/listinfo/l2ork-dev
>
>
>
> --
> Dr. Albert Gr"af
> Computer Music Research Group, JGU Mainz, Germany
> Email: aggraef at gmail.com, web: https://agraef.github.io/
> _______________________________________________
> L2Ork-dev mailing list
> L2Ork-dev at disis.music.vt.edu
> https://disis.music.vt.edu/listinfo/l2ork-dev

More information about the L2Ork-dev mailing list