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 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.
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&m=152536942216710&w=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
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&m=152536942216710&w=2
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 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. > > >
Re: Dealing with a port that uses github submodules
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 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.
Re: Dealing with a port that uses github submodules
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.
