Re: Nim/Nimble/Sugar
On Sat, Nov 10, 2018 at 09:59:22PM +0100, Juan Francisco Cantero Hurtado wrote: > > The Nim port needs an update but nobody want to take the maintainership > of the package. One of the tricky part is to deal with the use of gcc on > architectures where clang is the default compiler. > > Ok thank you for the info. I might take a look at updating the port myself, but no promises. Ken
Nim/Nimble/Sugar
I am wondering if anyone knows why the Nim package is missing the standard lib sugar modules. It prevents nimbl being installed to manage nim packages. Just wondering if there is a history regarding this that I am unaware of. Ken
Re: snapshot package problem for arm7
That is what I figured. Like I said it was a fresh install to current on a new machine, so that makes sense. Sent from my iPad > On Nov 5, 2018, at 6:36 AM, Stuart Henderson wrote: > >> On 2018/11/05 06:26, Ken M wrote: >> And side note, about 20 minutes later it all resolved. >> >> Sent from my iPad >> >>>> On Nov 5, 2018, at 6:14 AM, Stuart Henderson wrote: >>>> >>>> On 2018/11/04 16:56, Ken M wrote: >>>> Possibly not related but I am noticing unresolved packages for amd64 as >>>> well. >>>> Example x264 seems to not be there. Maybe not related, I don't know, but >>>> setting >>>> up a new machine I just noticed this as your email came in. >>> >>> Not related. >> > > Ah - in that case, you probably tried updating while the mirror was in > the middle of sync'ing. We try to change over atomically where possible > (though some especially 3rd-level mirrors might not do this) but if an > upstream switches to new files while a downstream is partway through > syncing, you can still get a mixture of files from two builds. > > Packages are rebuilt quite often so it's not hard to bump into this. >
Re: snapshot package problem for arm7
And side note, about 20 minutes later it all resolved. Sent from my iPad > On Nov 5, 2018, at 6:14 AM, Stuart Henderson wrote: > >> On 2018/11/04 16:56, Ken M wrote: >> Possibly not related but I am noticing unresolved packages for amd64 as well. >> Example x264 seems to not be there. Maybe not related, I don't know, but >> setting >> up a new machine I just noticed this as your email came in. > > Not related.
Re: snapshot package problem for arm7
On Sun, Nov 04, 2018 at 01:24:04PM -0800, s_g...@telus.net wrote: > I set up an arm system with the latest snapshot to try to test the php-fpm > problem but I could not even load php. I am not having fun! > > I get bad major errors even after I set PKG_PATH > > Before setting PKG_PATH > > Last login: Sun Nov 4 13:00:11 on console > OpenBSD 6.4-current (GENERIC) #79: Fri Nov 2 10:24:53 MDT 2018 > > Welcome to OpenBSD: The proactively secure Unix-like operating system. > > Please use the sendbug(1) utility to report bugs in the system. > Before reporting a bug, please try to reproduce it with the latest > version of the code. With bug reports, please try to ensure that > enough information to reproduce the problem is enclosed, and if a > known fix for it exists, include that as well. > > You have new mail. > op1bsdsnap1102$ su > Password: > op1bsdsnap1102# > op1bsdsnap1102# > op1bsdsnap1102# pkg_add php > quirks-3.16 signed on 2018-10-29T11:45:46Z > quirks-3.16: ok > Ambiguous: choose package for php > a 0: > 1: php-5.6.38p0 > 2: php-7.0.32p1 > 3: php-7.1.22 > 4: php-7.2.10 > Your choice: 2 > php-7.0.32p1:femail-1.0p1: ok > php-7.0.32p1:femail-chroot-1.0p3: ok > php-7.0.32p1:xz-5.2.4: ok > php-7.0.32p1:libiconv-1.14p3: ok > php-7.0.32p1:libxml-2.9.8p0: ok > php-7.0.32p1:oniguruma-6.9.0: ok > php-7.0.32p1:gettext-0.19.8.1p1: ok > Can't install php-7.0.32p1 because of libraries > |library crypto.44.1 not found > | /usr/lib/libcrypto.so.45.0 (system): bad major > |library ssl.46.1 not found > | /usr/lib/libssl.so.47.0 (system): bad major > Direct dependencies for php-7.0.32p1 resolve to oniguruma-6.9.0 > libxml-2.9.8p0 femail-chroot-1.0p3 gettext-0.19.8.1p1 > Full dependency tree is femail-chroot-1.0p3 gettext-0.19.8.1p1 > libiconv-1.14p3 oniguruma-6.9.0 libxml-2.9.8p0 xz-5.2.4 femail-1.0p1 > Running tags: ok > New and changed readme(s): > /usr/local/share/doc/pkg-readmes/femail-chroot > Couldn't install php-7.0.32p1 > > > After setting PKG_PATH > > op1bsdsnap1102# pkg_delete -X > oniguruma-6.9.0: ok > gettext-0.19.8.1p1: ok > libiconv-1.14p3:libxml-2.9.8p0: ok > libiconv-1.14p3: ok > xz-5.2.4: ok > femail-chroot-1.0p3: ok > femail-1.0p1: ok > quirks-3.16: ok > Running tags: ok > Read shared items: ok > --- -libxml-2.9.8p0 --- > You should also remove /var/db/xmlcatalog > op1bsdsnap1102# rm /var/db/xmlcatalog > op1bsdsnap1102# > op1bsdsnap1102# > op1bsdsnap1102# pkg_info > op1bsdsnap1102# pkg_add php > quirks-3.16 signed on 2018-10-29T11:45:46Z > quirks-3.16: ok > Ambiguous: choose package for php > a 0: > 1: php-5.6.38p0 > 2: php-7.0.32p1 > 3: php-7.1.22 > 4: php-7.2.10 > Your choice: 2 > php-7.0.32p1:femail-1.0p1: ok > php-7.0.32p1:femail-chroot-1.0p3: ok > php-7.0.32p1:xz-5.2.4: ok > php-7.0.32p1:libiconv-1.14p3: ok > php-7.0.32p1:libxml-2.9.8p0: ok > php-7.0.32p1:oniguruma-6.9.0: ok > php-7.0.32p1:gettext-0.19.8.1p1: ok > Can't install php-7.0.32p1 because of libraries > |library crypto.44.1 not found > | /usr/lib/libcrypto.so.45.0 (system): bad major > |library ssl.46.1 not found > | /usr/lib/libssl.so.47.0 (system): bad major > Direct dependencies for php-7.0.32p1 resolve to oniguruma-6.9.0 > libxml-2.9.8p0 femail-chroot-1.0p3 gettext-0.19.8.1p1 > Full dependency tree is oniguruma-6.9.0 libxml-2.9.8p0 femail-1.0p1 xz-5.2.4 > libiconv-1.14p3 femail-chroot-1.0p3 gettext-0.19.8.1p1 > Running tags: ok > New and changed readme(s): > /usr/local/share/doc/pkg-readmes/femail-chroot > Couldn't install php-7.0.32p1 > op1bsdsnap1102# echo $PKG_PATH > http://ftp3.usa.openbsd.org/pub/OpenBSD/snapshots/packages/arm/ > op1bsdsnap1102# > Possibly not related but I am noticing unresolved packages for amd64 as well. Example x264 seems to not be there. Maybe not related, I don't know, but setting up a new machine I just noticed this as your email came in. Ken
Re: lmms update
On Mon, Jun 04, 2018 at 02:05:34AM +0100, Stuart Henderson wrote: > > Did it not build, or did it build and not run (and if so, what happened)? > It did start for me and I was able to play demo tracks etc. > To rule out patching-related problems I'll attach a tar of my port directory > if you fancy giving that a spin (move the old directory out the way before > untarring as it removes some old files). I'll send the diff in-line as > well for anyone who wants to test in the usual way. I've updated it to > 1.2.0-rc6 and patched out zynaddsubfx build now. > Just built what you sent and everything went cleanly, installed, demos played all looks well. And now I have the example of your work to make my work look better. I guess we can hold it at this point for now till 1.2 is released instead of using an RC version. Thank you. Ken
Re: lmms update
On Mon, Jun 04, 2018 at 02:05:34AM +0100, Stuart Henderson wrote: > > Basically, fetch the -current ports tree > (http://www.openbsd.org/anoncvs.html), > make whatever changes, and run "cvs diff". > > For sending in mail, copy-and-paste from a terminal will likely mangle it > (whitespace may change e.g. tabs/spaces), some people use "xclip" > (cvs diff | xclip) and paste into mail, some people redirect to a file > (cvs diff > /tmp/lmms.diff) and include that instead. > I updated my ports tree but I have been working in a mystuff dir and perhaps that is not best for doing a diff > > Go to https://lmms.io/download/ or https://github.com/LMMS/lmms/releases > and you'll see that the latest is 1.2.0-rc6. > > The "stable-1.2" tree on github is actively being developed on the path > towards 1.2.0, rc6 was tagged from that tree a few days ago. > > I've just asked upstream if they'd mind rolling tarballs and adding them > to the release (https://github.com/LMMS/lmms/issues/4400) as that would > make life easier. > OK if we can use and rc that is better than rolling back to 1.1.3 which is less than desirable. > > Either of these: > > - build it as normal, but don't install it. Either patch in the port > Makefile to rm zyn-related files, or @comment in pkg/PLIST. > > - patch lmms to disable building it. > I have had issues with it building if Zyn is even included for the build. But I may be misremembering at what step it gave up. > Did it not build, or did it build and not run (and if so, what happened)? > It did start for me and I was able to play demo tracks etc. > To rule out patching-related problems I'll attach a tar of my port directory > if you fancy giving that a spin (move the old directory out the way before > untarring as it removes some old files). I'll send the diff in-line as > well for anyone who wants to test in the usual way. I've updated it to > 1.2.0-rc6 and patched out zynaddsubfx build now. > If I remember right it did not build, but I might not have had everything. I will try out what you attached to this email > > They seem pretty close to 1.2.0 so sometime after that would be a good > natural point to actually update it in ports. There doesn't seem to > be much point in looking at an older version than 1.2. Typically we > wait for a stable release (rather than updating to a release candidate) > though that's not a hard rule. > That seems sensible. I am not in a rush, I just want to be able to use it (which I can personaly building it) and also do what I can to contribute. > > It needs patching - libossaudio isn't used for audio io on OpenBSD, there are > a couple of remaining users in ports but I believe they're just for some > volume-control-related function. Certainly it shouldn't be added to anything > else. I have patched that in my update. > > I found it is easy enough to patch by editing the CMakelist.txt file. Ken P.S. Thanks for your guidance and patience with me as I try to get acclimated to the OpenBSD way of doing things.
Re: lmms update
On Mon, Jun 04, 2018 at 12:19:46AM +0100, Stuart Henderson wrote: > > > WANTLIB += ossaudio > > like I said before, ossaudio should not be used. > So to revisit this. The port-lib-depends-check is what pulled that up. The why, the -DWANT_OSS=OFF is not supported anymore on the 1.2 version. It basically checks for a soundcard.h and if it finds it is considers it oss. So I guess it could let stand in the wantlib or comment out that part of the Cmake with a patch. Ken
Re: lmms update
On Mon, Jun 04, 2018 at 12:19:46AM +0100, Stuart Henderson wrote: > > cvs diff -u please, this type of diff is pretty much unreadable > (and include the other files not just the Makefile). I'll do my best > though : > Kind of new to CVS but I will figure it out > > 1.2 is not released yet so lmms-1.2 is not appropriate. > To my understanding it is the current stable one, and also the one I found compiled the cleanest. > > if there's no way to disable *just* zynaddsubfx from being built without > listing all the plugins you *do* want, then the simplest way is probably > to build all the plugins and @comment or rm the unwanted one. Otherwise > this is going to be a pain to keep in sync with updates. > I don't like this much either. Are you suggesting a patch to the lmms make to stop zyn from building? Just making sure I understand correctly. > > I don't get it. I sent a 95% completed update with a fairly clean > Makefile that just needed an update to a newer version and maybe > tweaking to disable modules that don't work.. This rewrite from scratch > is going to take a bunch of work to get in suitable shape. > I was not able to get yours to run. I probably did something wrong there. Like I said new guy. I wasn't sure if you were going to take that further or not so I had this one that was working. Granted not in shape. Trying to do my part but if the learning curve is a problem I understand. As for other comments you put in there that I did not respond to, I am working to address those. Ken
lmms update
Diff for lmms update.
A couple of notes:
1. sndio support is now included by upstream so no need to patch for that
2. Zynaddsubfx support is dropped, it won't work effectively till someone ports
it standalone first, if even. I personally don't care about it so I dropped it.
3. Due to the use of submodules on git I have the tgz hosted on my webserver at
the moment but would prefer putting it somewhere else before this gets commited
to the ports tree.
I have tested on i386 and amd64. Everything works well. I would suggest
modifying ulimit -d up to at least 2GB or more is better for effective usage.
Diff below:
iff audio/lmms/Makefile mystuff/audio/lmms/Makefile
1c1,3
< # $OpenBSD: Makefile,v 1.14 2017/07/26 22:45:15 sthen Exp $
---
> # $OpenBSD: Makefile,v 1.77 2018/02/09 17:08:33 sthen Exp $
> #
> COMMENT = music studio with tracking, sampling and MIDI
3c5,6
< ONLY_FOR_ARCHS = ${GCC4_ARCHS} ${CLANG_ARCHS}
---
> DISTNAME =lmms-stable-1.2
> PKGNAME = lmms-1.2
5c8
< COMMENT = music studio with tracking, sampling and MIDI
---
> CATEGORIES = audio
7,9c10
< DISTNAME =lmms-0.4.8
< REVISION =4
< CATEGORIES = audio
---
> homepage =https://lmms.io/
11c12,18
< HOMEPAGE =http://lmms.sourceforge.net/
---
> # person who is responsible for the port. use a complete email address with
> # a real name, e.g., "maintainer = john doe ".
> # if you maintain several ports, use the same line each time.
> # if you no longer use the port, or are unwilling/unable to handle issues
> # in a timely manner, *leave the field blank*.
> # default value is ports@openbsd.org, no need to fill in
> #maintainer = ???
16,19c23
< WANTLIB = ICE SM QtGui QtXml X11 Xext Xft Xinerama c fltk jack \
< fftw3f fluidsynth fontconfig freetype m ncurses ogg \
< pthread readline samplerate sndfile sndio vorbis \
< vorbisenc vorbisfile z ${COMPILER_LIBCXX}
---
> COMPILER =base-clang ports-gcc
21,22c25,33
< MASTER_SITES =${MASTER_SITE_SOURCEFORGE:=lmms/}
< EXTRACT_SUFX =.tar.bz2
---
> WANTLIB += ${COMPILER_LIBCXX}
> WANTLIB += Qt5Core Qt5Gui Qt5Widgets Qt5Xml
> WANTLIB += c curses fftw3f fluidsynth
> WANTLIB += jack m mp3lame ogg portaudio readline
> WANTLIB += samplerate sndfile sndio vorbis vorbisenc vorbisfile
> WANTLIB += ossaudio
> # where the source files and patches can be fetched
> #
> MASTER_SITES =http://mack-z.com/downloads/OpenBSD/ports/lmms/
24c35
< MODULES = x11/qt4 devel/cmake
---
> DISTFILES = lmms-stable-1.2.tar.gz
26c37,40
< BUILD_DEPENDS = audio/portaudio-svn
---
> # Dependencies
> #
> MODULES = x11/qt5 devel/cmake
>
28c42,43
< misc/shared-mime-info
---
> misc/shared-mime-info \
> x11/gtk+3,-guic
34c49,51
< x11/fltk
---
> audio/lame \
> audio/libsndfile \
> audio/portaudio-svn
40,41c57,58
< LDFLAGS="${LDFLAGS} -L${X11BASE}/lib"
< CONFIGURE_ARGS = -DWANT_OSS=OFF -DWANT_SDL=OFF -DWANT_PULSEAUDIO=OFF
---
> LDFLAGS="${LDFLAGS} -L${X11BASE}/lib" \
> -DLMMS_HAVE_OSS=FALSE -DWANT_OSS=OFF
42a60,62
> CONFIGURE_ARGS = -DWANT_VST=OFF -DWANT_PULSEAUDIO=OFF -DWANT_ALSA=OFF \
>-DWANT_SDL=OFF
> -DCMAKE_PREFIX_PATH=${LOCALBASE}/lib/qt5/cmake
>
45c65,66
< -DWANT_SWH=OFF -DWANT_TAP=OFF
---
> -DWANT_SWH=OFF -DWANT_TAP=OFF -DWANT_GIG=OFF
> -DWANT_CARLA=OFF \
> -DWANT_QT5=ON
46a68,77
> CONFIGURE_ARGS += -DPLUGIN_LIST="Amplifier \
> BassBooster Bitcrush CrossoverEQ Delay DualFilter Eq Flanger \
> HydrogenImport LadspaEffect MidiExport \
> MidiImport MultitapEcho ReverbSC SpectrumAnalyzer \
> audio_file_processor bit_invader dynamics_processor \
> kicker ladspa_browser lb302 monstro nes organic patman \
> peak_controller_effect sf2_player sfxr sid \
> stereo_enhancer stereo_matrix triple_oscillator \
> vestige vibed watsyn waveshaper opl2"
>
49,55c80,82
< NO_TEST = Yes
<
< post-patch:
< cp ${FILESDIR}/FindSndio.cmake ${WRKSRC}/cmake/modules/
< cp ${FILESDIR}/{Audio,Midi}Sndio.h ${WRKSRC}/include/
< cp ${FILESDIR}/AudioSndio.cpp ${WRKSRC}/src/core/audio/
< cp ${FILESDIR}/MidiSndio.cpp ${WRKSRC}/src/core/midi/
---
> # uncompress man files
> post-install:
> gunzip ${PREFIX}/share/man/man1/lmms.1.gz
Re: New port - lv2 (LADSPA V2)
On Wed, May 30, 2018 at 01:22:31PM +0100, Stuart Henderson wrote:
> On 2018/05/30 08:03, Ken M wrote:
> > It is the lv2 port I sent previously. I can send it again or just send the
> > makefile if that makes it easier for posting this question.
>
> Ah - found it. Easier to include in the same mail especially if you are
> prodding for a response.
>
> : DISTNAME = lv2-1.14.0
> : PKGNAME = lv2-1.14.0
> ...
> : DISTFILES = lv2-1.14.0.tar.xz
> : EXTRACT_SUFX = .tar.xz
>
> Lots of duplication, this should just be
>
> DISTNAME =lv2-1.14.0
> EXTRACT_SUFX =.tar.xz
>
> : BUILD_DEPENDS = lang/gcc/4.9
>
> What does this need gcc for?
>
> It shouldn't be used on clang arches without an *exceptional* reason
> (and in those very few cases it should use e.g. "COMPILER=ports-gcc" and
> "${CC}" instead of hardcoding). Current exceptions are asterisk (needs
> either codeblocks or gcc's nested functions; codeblocks doesn't work yet)
> and "vmm-firwmare"/seabios and I think that's it.
>
> : do-configure:
> : cd ${WRKSRC} && PYTHON=${MODPY_BIN} ${MODPY_BIN} &&
> CC=${PREFIX}/bin/egcc \
> : ./waf configure --prefix=${PREFIX} \
> : --mandir=${PREFIX}/man
>
> splitting this line into pieces the second command doesn't make sense,
>
> cd ${WRKSRC}
>
> PYTHON=${MODPY_BIN} ${MODPY_BIN}
>
> CC=${PREFIX}/bin/egcc ./waf configure --prefix=${PREFIX}
> --mandir=${PREFIX}/man
>
> you'd want something like "${MODPY_BIN} ./waf configure [...]"
>
>
So to be doing things right I just switched my main laptop back to
openbsd so setting up and getting it on current before I continue.
Answering on the egcc requirement. lv2 puts out a lot of warnings for a
compiler less than gcc 4.6 I believe. Clang as the compiler does not
solve this. I could alter the warning supression code delivered from
upstream but I felt if upstream wanted that compiler specifically it was
best to give them that compiler.
You know the real problem with this is I have delivered nothing to
really test lv2 with. so
Let me spin this back around once I have some of the other tools that
need this ready. Now I got a main dev station back on line soon I can
work on that. Oh and I will also get the lmms port update wrapped up.
Ken
Re: New port - lv2 (LADSPA V2)
It is the lv2 port I sent previously. I can send it again or just send the
makefile if that makes it easier for posting this question.
Ken
On Wed, May 30, 2018 at 01:01:09PM +0100, Stuart Henderson wrote:
> It's easier to answer if you send the WIP port, but generally you can
> use one of these:
>
> - MODPY_ADJ_FILES= path/to/script
>
> - patch the file to use "${MODPY_BIN}" and then use
> "${SUBST_CMD} ${WRKSRC}/path/to/script" in a ports Makefile target
>
>
> On 2018/05/30 07:56, Ken M wrote:
Re: New port - lv2 (LADSPA V2)
Sorry to bump, but wanted to bump this question about this. On Mon, May 28, 2018 at 11:50:46AM -0400, Ken M wrote: > So in moving the port over to an i386 install to test I found a problem I am > not > sure how to fix. > > The port is looking for /usr/local/bin/python which on the machine I set up > is a > symlink to /usr/local/bin/python2. In short I need to tweak this to look for > python2 specifically and not count on that symlink. > > How can I make the MODPY_BIN look for that instead. Just hard code it earlier. > That seems fragile to me. > > Sorry I am a beginner at this but trying to get myself up to speed. > > Ken > > On Thu, May 24, 2018 at 11:04:29PM -0400, Ken M wrote: > > First time submitting a port, and pretty new to it all anyway. > > > > I have tested/built this on amd64 only. It is a pre-requisite to getting > > some > > other audio software ported over. So call it baby step #1. > > > > Ken > >
Re: New port - lv2 (LADSPA V2)
So in moving the port over to an i386 install to test I found a problem I am not sure how to fix. The port is looking for /usr/local/bin/python which on the machine I set up is a symlink to /usr/local/bin/python2. In short I need to tweak this to look for python2 specifically and not count on that symlink. How can I make the MODPY_BIN look for that instead. Just hard code it earlier. That seems fragile to me. Sorry I am a beginner at this but trying to get myself up to speed. Ken On Thu, May 24, 2018 at 11:04:29PM -0400, Ken M wrote: > First time submitting a port, and pretty new to it all anyway. > > I have tested/built this on amd64 only. It is a pre-requisite to getting some > other audio software ported over. So call it baby step #1. > > Ken
New port - lv2 (LADSPA V2)
First time submitting a port, and pretty new to it all anyway. I have tested/built this on amd64 only. It is a pre-requisite to getting some other audio software ported over. So call it baby step #1. Ken lv2.tgz Description: application/tar-gz
Re: Dealing with a port that uses github submodules
On Wed, May 23, 2018 at 07:58:47AM +0100, Stuart Henderson wrote: > On 2018/05/22 23:45, Ken M wrote: > > I started fresh in my own /usr/ports/me/audio/lmms area as I was not sure > > if it > > was best to start from the existing lmms port or start anew. I went for > > anew for > > now. > > Ports infrastructure handles /usr/ports/mystuff/(category)/(port) (exactly > the word "mystuff") specially, best to use that and save having to mess > around with PORTSDIR_PATH etc. > > For lmms it's probably best to start with the update to lmms that > I already sent because it's mostly fimished already, and if you're > starting from scratch there are a few things (@exec/unexec PLIST > entries, manpage shouldn't be compressed, ossaudio shouldn't be linked) > that are likely to be missed. > Just thought of something. When porting I did it against QT4, but the first time I just compiled it I did it against against QT5. Which should I target at this point. LMMS doesnt seem to care but for best compatibility is there an OpenBSD specific preference? Should qt4 vs qt5 perhaps be flavors? Should with or without Zynaddsubfx be flavors? Ken
Re: Dealing with a port that uses github submodules
On Wed, May 23, 2018 at 07:58:47AM +0100, Stuart Henderson wrote: > On 2018/05/22 23:45, Ken M wrote: > > I started fresh in my own /usr/ports/me/audio/lmms area as I was not sure > > if it > > was best to start from the existing lmms port or start anew. I went for > > anew for > > now. > > Ports infrastructure handles /usr/ports/mystuff/(category)/(port) (exactly > the word "mystuff") specially, best to use that and save having to mess > around with PORTSDIR_PATH etc. > > For lmms it's probably best to start with the update to lmms that > I already sent because it's mostly fimished already, and if you're > starting from scratch there are a few things (@exec/unexec PLIST > entries, manpage shouldn't be compressed, ossaudio shouldn't be linked) > that are likely to be missed. > Ok, so I took mystuff as a variable and instead used my username in that spot. Good to know. Since I had never done this before starting from scratch was a good exercise. I am going to however now take what you have, merge in what I sorted out for the 1.2 stable version and get that submitted. Hopefully I can get this all together before the weekend. Mostly squeezing this in at night where I can. Ken
Re: Dealing with a port that uses github submodules
On Tue, May 22, 2018 at 04:17:53PM +0100, Stuart Henderson wrote: > On 2018/05/22 09:48, Ken M wrote: > > So the port in question is lmms, since I got it to compile manually to the > > current version I figured might as well go with updating the port. > > > > They do have release tgz files hosted on github but those release tarballs > > don't > > actually include the submodule that is the problem. I will contact them, > > considering they added sndio support I imagine they might be responsive to > > this. > > In the interim for my own testing I will build a complete tarball to host > > myself. > > > > Thank you. > > That's exactly what I did for lmms: > > https://marc.info/?l=openbsd-ports=152536942216710=2 > Cool. Well stable 1.2 is almost there. Got some Depends to fix and a make uninstall error to figure out. I have literally never done this before, ported anything to any BSD. So far this one looks to have been low hanging fruit. I didn't really have to patch it at all as sndio support is now included upstream. I did however exclude Zynaddsubfx from the plugins, in my earlier testing it just doesn't work, I mean it plays but calling the gui to use it crashes. I think that will need to be ported standalone first to use it in lmms. The pkg will still include the pieces for it. The only downside to excluding it from the build as I see it is that demo pieces that call for it will error when the try to get to it. I will do some more testing and tweaking and hopefully get something up here soon. Hopefully for someone to guide me in doing this as correctly as possible. I started fresh in my own /usr/ports/me/audio/lmms area as I was not sure if it was best to start from the existing lmms port or start anew. I went for anew for now. Ken
Re: Dealing with a port that uses github submodules
So the port in question is lmms, since I got it to compile manually to the current version I figured might as well go with updating the port. They do have release tgz files hosted on github but those release tarballs don't actually include the submodule that is the problem. I will contact them, considering they added sndio support I imagine they might be responsive to this. In the interim for my own testing I will build a complete tarball to host myself. Thank you. Ken On Tue, May 22, 2018 at 07:36:36AM +0100, Stuart Henderson wrote: > The best choice where possible is for upstream to generate tarballs, they > can upload them to github as "release assets" for hosting, these show up in > the releases page if available. > > -- > Sent from a phone, apologies for poor formatting. > On 22 May 2018 04:58:53 Thomas Frohwein <tfrohw...@fastmail.com> wrote: > > > On Mon, May 21, 2018 at 11:32:32PM -0400, Ken M wrote: > > > Been trying to find a how to on this anywhere and I am not having any > > > luck. I > > > found FreeBSD documentation and I found some old emails about making it a > > > separate port. It seems cleaner to me to have a way to recursively load > > > so the > > > upstream make files work as expected. > > > > As far as I understand it, the current recommendation if no distfiles that > > include submodules are available from upstream is to host distfiles created > > from: > > > > git clone --recurse-submodules -b > > > > tar'd up without .git. There's opportunities to host distfiles for the > > project > > if you have a port draft. > > > > An alternative has been to pull in submodules via MASTER_SITES0 through 9, > > but > > that's limited in number, and usually pulls in a non-release commit from the > > submodules. Such distfiles from a commit hash can change their distfile > > hash/size at the drop of a hat, and this is therefore discouraged. > > > > An example of this approach has been emulators/ppsspp, but if I understand > > previous on and off list conversations correctly is now discouraged in favor > > of hosting stable distfiles in a different location as outlined above. > > >
Dealing with a port that uses github submodules
Been trying to find a how to on this anywhere and I am not having any luck. I found FreeBSD documentation and I found some old emails about making it a separate port. It seems cleaner to me to have a way to recursively load so the upstream make files work as expected.
LMMS working now
OK so the best solution I found is to be choosy about what plugins to compile. Everything but calling Zynaddsubfx's gui is working. Instructions after cloning the stable branch of lmms from git. mkdir build cd build cmake .. -DCMAKE_PREFIX_PATH=/usr/local/lib/qt5/cmake/Qt5 -DWANT_QT5=ON -DWANT_VST=OFF -DPLUGIN_LIST="Amplifier BassBooster Bitcrush CrossoverEQ Delay DualFilter Eq Flanger FreeBoy HydrogenImport LadspaEffect MidiExport MidiImport MultitapEcho OpulenZ ReverbSC SpectrumAnalyzer audio_file_processor bit_invader dynamics_processor kicker ladspa_browser lb302 monstro nes organic patman peak_controller_effect sf2_player sfxr sid stereo_enhancer stereo_matrix triple_oscillator vestige vibed watsyn waveshaper zynaddsubfx" find plugins/LadspaEffect/swh/CMakeFiles/ -name link.txt|xargs sed -i.bak "s/\-fPIC /\-fPIC \-L\/usr\/local\/lib/" find plugins/zynaddsubfx/CMakeFiles/ -name link.txt|xargs sed -i.bak "s/\-fPIC /\-fPIC \-L\/usr\/local\/lib/" make doas make install That will get you a shiny new lmms on Openbsd. Explanations, that cmake list basically takes all plugins except everything VST or Carla related. It also leaves of the GIG player. The find|sed combos are to fix linking problems in the swh and Zynaddsubfx plugins. So I guess this new guy needs to read the porters handbook to figure out what to do with this for others, and who the heck is the current maintainer of the lmms port? Ken
lmms - getting it more current
So noticing how old the current lmms port was I thought I would try to compile a newer version, and at that the 1.2 current. Hopefully this work can help get the port itself updated. Anyway after numerous fixes to the link.txt files and what not I am now stuck at this error and not sure what to do. I hope this isn't out of place here as a semi n00b but here it goes: [ 89%] Linking CXX shared module ../libxpressive.so OpenBSD clang version 5.0.1 (tags/RELEASE_501/final) (based on LLVM 5.0.1) Target: amd64-unknown-openbsd6.3 Thread model: posix InstalledDir: /usr/bin "/usr/bin/ld" --eh-frame-hdr -Bdynamic -shared -o ../libxpressive.so /usr/bin/../lib/crtbeginS.o -L/usr/local/lib/qt5/. -L/usr/bin/../lib -L/usr/lib CMakeFiles/xpressive.dir/Xpressive.cpp.o CMakeFiles/xpressive.dir/ExprSynth.cpp.o CMakeFiles/xpressive.dir/moc_Xpressive.cpp.o CMakeFiles/xpressive.dir/qrc_xpressive.cpp.o -rpath /usr/local/lib/qt5/.:/usr/X11R6/lib: -lQt5Widgets -lQt5Xml -lQt5Gui -lQt5Core -rpath-link /usr/X11R6/lib:/usr/local/lib -lc++ -lc++abi -lpthread -lm -lcompiler_rt -lcompiler_rt /usr/bin/../lib/crtendS.o CMakeFiles/xpressive.dir/ExprSynth.cpp.o: file not recognized: File format not recognized c++: error: linker command failed with exit code 1 (use -v to see invocation) *** Error 1 in . (plugins/Xpressive/CMakeFiles/xpressive.dir/build.make:191 'plugins/libxpressive.so') *** Error 1 in . (CMakeFiles/Makefile2:8034 'plugins/Xpressive/CMakeFiles/xpressive.dir/all') *** Error 1 in /home/superfly/git/lmms/build (Makefile:152 'all')
