Re: boost-md: build on sparc64
On Sat, Jun 06, 2020 at 08:29:38PM +0100, Stuart Henderson wrote: > +CC otto@, do you remember the status of context/coroutine on sparc64? > I think they were crashing weren't they? I think they were fixed with a compiler patch. -Otto > > On 2020/06/06 01:54, Brad Smith wrote: > > On 6/6/2020 1:32 AM, Rafael Sadowski wrote: > > > > > On Fri Jun 05, 2020 at 11:55:21PM +0200, Klemens Nanni wrote: > > > > I thought I had already sent out (or even committed) this diff... > > > > > > > > For another WIP port, boost-md is required is required. > > > > I've been building and linking against it just fine on sparc64. > > > > > > > > OK? > > > If it works on sparc64, sure! > > > > I was under the impression that this did not build with there being some > > missing MD code, but if it does then go ahead. > >
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: b...@cvs.openbsd.org2020/06/06 23:44:40 Modified files: audio/audacious: Makefile.inc audio/audacious/player: distinfo audio/audacious/plugins: distinfo meta/audacious : Makefile Log message: Update to audacious-4.0.4 Changes: https://audacious-media-player.org/news/49-audacious-4-0-4-released Take maintainer OK naddy@
mips64 bulk build report
bulk build on octeon.ports.openbsd.org started on Thu May 28 14:39:20 UTC 2020 finished at Sat Jun 6 17:06:52 UTC 2020 lasted 10D02h27m done with kern.version=OpenBSD 6.7-current (GENERIC.MP) #2: Fri May 29 13:37:58 UTC 2020 built packages:9151 May 28:2155 May 29:1080 May 30:696 May 31:712 Jun 1:1020 Jun 2:2786 Jun 3:285 Jun 4:91 Jun 5:248 Jun 6:77 build failures: 46 http://build-failures.rhaalovely.net/mips64/2020-05-28/audio/mscore.log http://build-failures.rhaalovely.net/mips64/2020-05-28/cad/netgen.log http://build-failures.rhaalovely.net/mips64/2020-05-28/chinese/libchewing.log http://build-failures.rhaalovely.net/mips64/2020-05-28/chinese/libpinyin.log http://build-failures.rhaalovely.net/mips64/2020-05-28/databases/postgresql-pllua.log http://build-failures.rhaalovely.net/mips64/2020-05-28/devel/cgdb.log http://build-failures.rhaalovely.net/mips64/2020-05-28/devel/coccinelle.log http://build-failures.rhaalovely.net/mips64/2020-05-28/devel/libpeas.log http://build-failures.rhaalovely.net/mips64/2020-05-28/devel/py-unicorn,python3.log http://build-failures.rhaalovely.net/mips64/2020-05-28/devel/sdcc.log http://build-failures.rhaalovely.net/mips64/2020-05-28/emulators/openmsx.log http://build-failures.rhaalovely.net/mips64/2020-05-28/games/astromenace.log http://build-failures.rhaalovely.net/mips64/2020-05-28/games/eduke32.log http://build-failures.rhaalovely.net/mips64/2020-05-28/games/hyperrogue.log http://build-failures.rhaalovely.net/mips64/2020-05-28/games/valyriatear.log http://build-failures.rhaalovely.net/mips64/2020-05-28/geo/gpstk.log http://build-failures.rhaalovely.net/mips64/2020-05-28/graphics/enblend-enfuse.log http://build-failures.rhaalovely.net/mips64/2020-05-28/graphics/evince,light.log http://build-failures.rhaalovely.net/mips64/2020-05-28/graphics/gimp/stable.log http://build-failures.rhaalovely.net/mips64/2020-05-28/graphics/openimageio.log http://build-failures.rhaalovely.net/mips64/2020-05-28/inputmethods/scim-fcitx.log http://build-failures.rhaalovely.net/mips64/2020-05-28/lang/STk.log http://build-failures.rhaalovely.net/mips64/2020-05-28/lang/gforth.log http://build-failures.rhaalovely.net/mips64/2020-05-28/lang/gpc.log http://build-failures.rhaalovely.net/mips64/2020-05-28/lang/janet.log http://build-failures.rhaalovely.net/mips64/2020-05-28/lang/pfe.log http://build-failures.rhaalovely.net/mips64/2020-05-28/lang/squeak/vm.log http://build-failures.rhaalovely.net/mips64/2020-05-28/mail/kopano/core.log http://build-failures.rhaalovely.net/mips64/2020-05-28/math/gbc.log http://build-failures.rhaalovely.net/mips64/2020-05-28/math/mlpack,-main.log http://build-failures.rhaalovely.net/mips64/2020-05-28/math/ntl.log http://build-failures.rhaalovely.net/mips64/2020-05-28/multimedia/assimp.log http://build-failures.rhaalovely.net/mips64/2020-05-28/multimedia/synfigstudio.log http://build-failures.rhaalovely.net/mips64/2020-05-28/net/utox.log http://build-failures.rhaalovely.net/mips64/2020-05-28/plan9/drawterm.log http://build-failures.rhaalovely.net/mips64/2020-05-28/security/botan2.log http://build-failures.rhaalovely.net/mips64/2020-05-28/shells/ksh93.log http://build-failures.rhaalovely.net/mips64/2020-05-28/sysutils/u-boot,aarch64.log http://build-failures.rhaalovely.net/mips64/2020-05-28/www/mozplugger.log http://build-failures.rhaalovely.net/mips64/2020-05-28/x11/gnome/gcr.log http://build-failures.rhaalovely.net/mips64/2020-05-28/x11/gnome/libdazzle.log http://build-failures.rhaalovely.net/mips64/2020-05-28/x11/gnome/libgweather.log http://build-failures.rhaalovely.net/mips64/2020-05-28/x11/gtk-vnc.log http://build-failures.rhaalovely.net/mips64/2020-05-28/x11/gtksourceview4.log http://build-failures.rhaalovely.net/mips64/2020-05-28/x11/qt5/qtscript.log http://build-failures.rhaalovely.net/mips64/2020-05-28/x11/qt5/qtwebengine.log
[NEW] devel/libarea
Howdy, For your porting pleasure see attached for a port of libarea, a small library for computer assisted machining, also required for FreeCAD. Best regards libarea.tar.gz Description: application/gzip
Re: [NEW] math/vtk8
I ported VTK8.2 because FreeBSD has that specified in their makefile, and
that if there was any weird issues porting from other platforms they
might’ve caught them already- I figured start from there since that’s
likely to work and then once we get FreeCAD fully functional we can bump it
up to VTK9? I’m about to work on libarea, and I’m compiling what paco’s git
had to check it out but then I’ll push the repository to GitHub once it
finishes!
On Sat, Jun 6, 2020 at 6:50 PM Justin Noor wrote:
> Are you sure FreeCAD requires VTK 8.2?
>
> https://wiki.freecadweb.org/Third_Party_Libraries
>
>
> On Sat, Jun 6, 2020 at 2:00 PM Charlie Burnett wrote:
>
>> Hi Stuart,
>>
>> Is this better? I believe I covered all the bases you mentioned, thanks
>> for the help!
>>
>> On 2020-06-05 4:27 PM, Stuart Henderson wrote:
>> > On 2020/06/05 14:44, Charlie Burnett wrote:
>> >> Howdy,
>> >>
>> >> I'm starting to work through and add the dependencies for FreeCAD,
>> attached
>> >> you'll find the patch adding the Visual Toolkit Library 8.2.0 to ports.
>> >> There's a version 9 available but 8.2 is what's required for FreeCAD.
>> >>
>> >> Development page is here: https://gitlab.kitware.com/vtk/vtk
>> >>
>> >> Let me know if there's anything I missed!
>> >>
>> > quick review, sorry for brevity:
>> >
>> > - send new ports as a tar.gz of the port directory, not of a diff
>> >
>> > - add the rcsid line at the top of the file
>> >
>> > # $OpenBSD$
>> >
>> > - PKG_ARCH=* means "the produced package works on all arches" which
>> isn't
>> > the case for anything with binaries
>> >
>> > - SHARED_LIBS version numbers should use the "major.minor" format and
>> start
>> > from 0.0, however with the huge number of libraries it's going to be
>> insane
>> > to analyse and figure out which individual ones need bumps in future I
>> think
>> > you can just do it like this, so all the versions can be updated in one
>> go
>> >
>> > LIBVER = 0.0
>> > SHARED_LIBS += vtkChartsCore ${LIBVER}
>> > SHARED_LIBS += vtkCommonColor ${LIBVER}
>> > SHARED_LIBS += vtkCommonComputationalGeometry ${LIBVER}
>> > SHARED_LIBS += vtkCommonCore ${LIBVER}
>> > etc.
>> >
>> > - the following are set by default when cmake is used, please drop the
>> lines:
>> > SEPARATE_BUILD
>> > USE_NINJA
>> >
>> > - PKGNAME=${DISTNAME} is set by default and normally should be dropped,
>> > though we generally prefer lowercase package names so for this I'd use
>> > PKGNAME=${DISTNAME:L} to do that
>> >
>> > - DESCR should be word-wrapped
>> >
>> > - was there a particular reason for the patches that rename the
>> libraries?
>> > e.g.
>> > +- qt5_wrap_cpp(PluginMocSrcs ${PluginMocHeaders} TARGET
>> QVTKWidgetPlugin)
>> > ++ qt5_wrap_cpp(PluginMocSrcs ${PluginMocHeaders} TARGET
>> QVTKWidgetPlugin-${VTK_MAJOR_VERSION}.${VTK_MINOR_VERSION})
>> >
>> > doing this usually causes problems (and causes the library names to not
>> match
>> > your SHARED_LIBS lines which results in the version numbers not being
>> set
>> > properly). Probably want to drop those patches and rerun "make plist"
>> which
>> > with the SHARED_LIBS changes should result in replacing
>> >
>> > lib/libvtkChartsCore-8.2.so.1
>> > lib/libvtkCommonColor-8.2.so.1
>> >
>> > with
>> >
>> > @so lib/libvtkChartsCore.so.${LIBvtkChartsCore_VERSION}
>> > @so lib/libvtkCommonColor.so.${LIBvtkCommonColor_VERSION}
>> >
>> > etc.
>> >
>> > There will be some other things but it will be easier to look at
>> > them with the above changed.
>> >
>>
>
Re: [NEW] math/vtk8
Are you sure FreeCAD requires VTK 8.2?
https://wiki.freecadweb.org/Third_Party_Libraries
On Sat, Jun 6, 2020 at 2:00 PM Charlie Burnett wrote:
> Hi Stuart,
>
> Is this better? I believe I covered all the bases you mentioned, thanks
> for the help!
>
> On 2020-06-05 4:27 PM, Stuart Henderson wrote:
> > On 2020/06/05 14:44, Charlie Burnett wrote:
> >> Howdy,
> >>
> >> I'm starting to work through and add the dependencies for FreeCAD,
> attached
> >> you'll find the patch adding the Visual Toolkit Library 8.2.0 to ports.
> >> There's a version 9 available but 8.2 is what's required for FreeCAD.
> >>
> >> Development page is here: https://gitlab.kitware.com/vtk/vtk
> >>
> >> Let me know if there's anything I missed!
> >>
> > quick review, sorry for brevity:
> >
> > - send new ports as a tar.gz of the port directory, not of a diff
> >
> > - add the rcsid line at the top of the file
> >
> > # $OpenBSD$
> >
> > - PKG_ARCH=* means "the produced package works on all arches" which isn't
> > the case for anything with binaries
> >
> > - SHARED_LIBS version numbers should use the "major.minor" format and
> start
> > from 0.0, however with the huge number of libraries it's going to be
> insane
> > to analyse and figure out which individual ones need bumps in future I
> think
> > you can just do it like this, so all the versions can be updated in one
> go
> >
> > LIBVER = 0.0
> > SHARED_LIBS += vtkChartsCore ${LIBVER}
> > SHARED_LIBS += vtkCommonColor ${LIBVER}
> > SHARED_LIBS += vtkCommonComputationalGeometry ${LIBVER}
> > SHARED_LIBS += vtkCommonCore ${LIBVER}
> > etc.
> >
> > - the following are set by default when cmake is used, please drop the
> lines:
> > SEPARATE_BUILD
> > USE_NINJA
> >
> > - PKGNAME=${DISTNAME} is set by default and normally should be dropped,
> > though we generally prefer lowercase package names so for this I'd use
> > PKGNAME=${DISTNAME:L} to do that
> >
> > - DESCR should be word-wrapped
> >
> > - was there a particular reason for the patches that rename the
> libraries?
> > e.g.
> > +- qt5_wrap_cpp(PluginMocSrcs ${PluginMocHeaders} TARGET
> QVTKWidgetPlugin)
> > ++ qt5_wrap_cpp(PluginMocSrcs ${PluginMocHeaders} TARGET
> QVTKWidgetPlugin-${VTK_MAJOR_VERSION}.${VTK_MINOR_VERSION})
> >
> > doing this usually causes problems (and causes the library names to not
> match
> > your SHARED_LIBS lines which results in the version numbers not being set
> > properly). Probably want to drop those patches and rerun "make plist"
> which
> > with the SHARED_LIBS changes should result in replacing
> >
> > lib/libvtkChartsCore-8.2.so.1
> > lib/libvtkCommonColor-8.2.so.1
> >
> > with
> >
> > @so lib/libvtkChartsCore.so.${LIBvtkChartsCore_VERSION}
> > @so lib/libvtkCommonColor.so.${LIBvtkCommonColor_VERSION}
> >
> > etc.
> >
> > There will be some other things but it will be easier to look at
> > them with the above changed.
> >
>
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: feine...@cvs.openbsd.org2020/06/06 15:57:17 Modified files: math/R : Makefile distinfo math/R/pkg : PLIST Log message: Update to R 4.0.1
NEW: net/termshark
OK to import? It's an older version ("portgen go" can't handle the current
version) but still seems useful.
-
Termshark is a terminal UI for tshark, inspired by Wireshark.
- Read pcap files or sniff live interfaces
- Use Wireshark's display filters
- Reassemble TCP and UDP streams
- View conversations by protocol
-
termshark.tgz
Description: application/tar-gz
NEW: textproc/codesearch
I haven't tried getting this to work in a while and seems it is now able to run on OpenBSD (it used to want UBC). I haven't tried it on any huge sets yet, but it works nicely on /usr/src and a few other things I've thrown at it. OK to import? Code Search is a tool for indexing and then performing regular expression searches over large bodies of source code. It is a set of command-line programs written in Go. For background and an overview of the commands, see http://swtch.com/~rsc/regexp/regexp4.html. codesearch.tgz Description: application/tar-gz
Re: [NEW] math/vtk8
Hi Stuart,
Is this better? I believe I covered all the bases you mentioned, thanks
for the help!
On 2020-06-05 4:27 PM, Stuart Henderson wrote:
On 2020/06/05 14:44, Charlie Burnett wrote:
Howdy,
I'm starting to work through and add the dependencies for FreeCAD, attached
you'll find the patch adding the Visual Toolkit Library 8.2.0 to ports.
There's a version 9 available but 8.2 is what's required for FreeCAD.
Development page is here: https://gitlab.kitware.com/vtk/vtk
Let me know if there's anything I missed!
quick review, sorry for brevity:
- send new ports as a tar.gz of the port directory, not of a diff
- add the rcsid line at the top of the file
# $OpenBSD$
- PKG_ARCH=* means "the produced package works on all arches" which isn't
the case for anything with binaries
- SHARED_LIBS version numbers should use the "major.minor" format and start
from 0.0, however with the huge number of libraries it's going to be insane
to analyse and figure out which individual ones need bumps in future I think
you can just do it like this, so all the versions can be updated in one go
LIBVER =0.0
SHARED_LIBS += vtkChartsCore ${LIBVER}
SHARED_LIBS += vtkCommonColor ${LIBVER}
SHARED_LIBS += vtkCommonComputationalGeometry ${LIBVER}
SHARED_LIBS += vtkCommonCore ${LIBVER}
etc.
- the following are set by default when cmake is used, please drop the lines:
SEPARATE_BUILD
USE_NINJA
- PKGNAME=${DISTNAME} is set by default and normally should be dropped,
though we generally prefer lowercase package names so for this I'd use
PKGNAME=${DISTNAME:L} to do that
- DESCR should be word-wrapped
- was there a particular reason for the patches that rename the libraries?
e.g.
+- qt5_wrap_cpp(PluginMocSrcs ${PluginMocHeaders} TARGET QVTKWidgetPlugin)
++ qt5_wrap_cpp(PluginMocSrcs ${PluginMocHeaders} TARGET
QVTKWidgetPlugin-${VTK_MAJOR_VERSION}.${VTK_MINOR_VERSION})
doing this usually causes problems (and causes the library names to not match
your SHARED_LIBS lines which results in the version numbers not being set
properly). Probably want to drop those patches and rerun "make plist" which
with the SHARED_LIBS changes should result in replacing
lib/libvtkChartsCore-8.2.so.1
lib/libvtkCommonColor-8.2.so.1
with
@so lib/libvtkChartsCore.so.${LIBvtkChartsCore_VERSION}
@so lib/libvtkCommonColor.so.${LIBvtkCommonColor_VERSION}
etc.
There will be some other things but it will be easier to look at
them with the above changed.
vtk8.tar.gz
Description: application/gzip
Re: sparc64 bulk build report
On Sat Jun 06, 2020 at 08:25:48PM +0100, Stuart Henderson wrote: > > http://build-failures.rhaalovely.net/sparc64/2020-06-04/devel/cpp-hocon.log > > http://build-failures.rhaalovely.net/sparc64/2020-06-04/devel/glog.log > > http://build-failures.rhaalovely.net/sparc64/2020-06-04/multimedia/libmatroska.log > > "ninja: error: manifest 'build.ninja' still dirty after 100 tries" > > I am glad I'm not the only one running into this. Your clocks are > probably not close enough on the build machines. ntpd isn't helping me > with this, clocks are close enough that it tries to skew them, even > with "trusted". I am currently running rdate -n on all my build > machines immediately before starting a build but it's too early to > know if that's really going to help. > > I had been thinking that maybe the machines swapping is resulting > in clocks getting out of whack. Not sure if that's the case but > I can't think of another explanation (and the i386 boxes are > heavily bogged down at times to the extent that BREAK isn't processed). It's probably a known bug: https://github.com/ninja-build/ninja/issues/1704
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: st...@cvs.openbsd.org 2020/06/06 14:40:49 Modified files: security/xca : Makefile distinfo security/xca/patches: patch-Makefile patch-configure patch-doc_Makefile patch-misc_Makefile security/xca/pkg: PLIST Removed files: security/xca/patches: patch-lib_ipvalidator_h Log message: update to xca-2.3.0
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: st...@cvs.openbsd.org 2020/06/06 14:30:49 Modified files: sysutils/freeipmi: Makefile distinfo sysutils/freeipmi/patches: patch-etc_Makefile_in patch-libfreeipmi_Makefile_in patch-libipmidetect_Makefile_in patch-man_Makefile_in sysutils/freeipmi/pkg: PLIST Log message: udpate to freeipmi-1.6.5
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: st...@cvs.openbsd.org 2020/06/06 14:23:48 Modified files: security/letsencrypt: Makefile.inc security/letsencrypt/client: distinfo security/letsencrypt/py-acme: distinfo Log message: update to certbot 1.5.0
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: st...@cvs.openbsd.org 2020/06/06 14:22:47 Modified files: devel/perltidy : Makefile distinfo devel/perltidy/pkg: PLIST Log message: update to perltidy-20200110
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: st...@cvs.openbsd.org 2020/06/06 14:21:30 Modified files: www/nghttp2: Makefile distinfo Log message: update to nghttp2-1.41.0
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: de...@cvs.openbsd.org 2020/06/06 14:14:01 Modified files: net/blaeu : Makefile distinfo Log message: update to 1.1.6 OK sthen@
Re: NEW: ipynb-py-convert - converter between Jupyter Notebooks and .py
On Sat 06/06/2020 13:25, Thomas Frohwein wrote: > [...] > > > > > - Maybe add HOMEPAGE=https://github.com/kiwi0fruit/ipynb-py-convert to > > > > > Makefile? > > > > > > You caught me there, thanks. Same for NO_TEST=Yes. > > I looked again - the pypi homepage is set by the lang/python module. > That's why I left it out when I submitted it. > This is probably a little bike shedding, but I'm wondering if it's > preferable to use the pypi homepage in this case? > > ipynb-py-convert$ make show=HOMEPAGE > https://pypi.python.org/pypi/ipynb-py-convert > I'm not sure what you mean: When MODPY_PI is set it indeed uses the pypi homepage *unless* HOMEPAGE is set. ipynb-py-convert does have a 'real' HOMEPAGE so it makes sense to use this. Your latest tarball does the right thing: $ make show=HOMEPAGE https://github.com/kiwi0fruit/ipynb-py-convert There are 460 other ports that use MODPY_PI and set HOMEPAGE. Have a look at one of 'cd /usr/ports; grep -l HOMEPAGE $(grep -lr MODPY_PI *)'
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: t...@cvs.openbsd.org2020/06/06 13:30:00 Modified files: security/py-tlsfuzzer: Makefile distinfo security/py-tlsfuzzer/patches: patch-scripts_test-openssl-3712_py Log message: Update to py-tlsfuzzer-20200604
Re: boost-md: build on sparc64
+CC otto@, do you remember the status of context/coroutine on sparc64? I think they were crashing weren't they? On 2020/06/06 01:54, Brad Smith wrote: > On 6/6/2020 1:32 AM, Rafael Sadowski wrote: > > > On Fri Jun 05, 2020 at 11:55:21PM +0200, Klemens Nanni wrote: > > > I thought I had already sent out (or even committed) this diff... > > > > > > For another WIP port, boost-md is required is required. > > > I've been building and linking against it just fine on sparc64. > > > > > > OK? > > If it works on sparc64, sure! > > I was under the impression that this did not build with there being some > missing MD code, but if it does then go ahead.
Re: NEW: ipynb-py-convert - converter between Jupyter Notebooks and .py
[...] > > > > - Maybe add HOMEPAGE=https://github.com/kiwi0fruit/ipynb-py-convert to > > > > Makefile? > > > > You caught me there, thanks. Same for NO_TEST=Yes. I looked again - the pypi homepage is set by the lang/python module. That's why I left it out when I submitted it. This is probably a little bike shedding, but I'm wondering if it's preferable to use the pypi homepage in this case? ipynb-py-convert$ make show=HOMEPAGE https://pypi.python.org/pypi/ipynb-py-convert > > > > I added these 3 changes to a fresh tarball which is attached. > > > > ok? > > OK bket@
Re: sparc64 bulk build report
> http://build-failures.rhaalovely.net/sparc64/2020-06-04/devel/cpp-hocon.log > http://build-failures.rhaalovely.net/sparc64/2020-06-04/devel/glog.log > http://build-failures.rhaalovely.net/sparc64/2020-06-04/multimedia/libmatroska.log "ninja: error: manifest 'build.ninja' still dirty after 100 tries" I am glad I'm not the only one running into this. Your clocks are probably not close enough on the build machines. ntpd isn't helping me with this, clocks are close enough that it tries to skew them, even with "trusted". I am currently running rdate -n on all my build machines immediately before starting a build but it's too early to know if that's really going to help. I had been thinking that maybe the machines swapping is resulting in clocks getting out of whack. Not sure if that's the case but I can't think of another explanation (and the i386 boxes are heavily bogged down at times to the extent that BREAK isn't processed). > http://build-failures.rhaalovely.net/sparc64/2020-06-04/x11/p5-Tk-ProgressBar-Mac.log "Makefile out-of-date with respect to /usr/local/libdata/perl5/site_perl/sparc64-openbsd/Tk/Config.pm" same. The actual problem is that a dep is built on one member of the cluster with a clock that is in-time, then it's installed on a machine with a clock that is running slow and some build infrastructure complains. autoconf/make doesn't usually care about times of installed files. it happens rarely with perl things, and all the damn time with cmake+ninja. > http://build-failures.rhaalovely.net/sparc64/2020-06-04/devel/libidn2.log this is the thing I run into sometimes, /usr/obj/ports/libidn2-2.3.0/libidn2-2.3.0/unistring/.libs/libunistring.a(c-ctype.o): In function `c_isalnum': c-ctype.c:(.text+0x0): multiple definition of `c_isalnum' /usr/obj/ports/libidn2-2.3.0/libidn2-2.3.0/unistring/.libs/libunistring.a(c-ctype.o):c-ctype.c:(.text+0x0): first defined here /usr/obj/ports/libidn2-2.3.0/libidn2-2.3.0/unistring/.libs/libunistring.a(c-ctype.o): In function `c_isalpha': c-ctype.c:(.text+0x60): multiple definition of `c_isalpha' > http://build-failures.rhaalovely.net/sparc64/2020-06-04/benchmarks/hyperfine.log > http://build-failures.rhaalovely.net/sparc64/2020-06-04/devel/snare.log rust > http://build-failures.rhaalovely.net/sparc64/2020-06-04/games/wrath.log was broken on !x86, I've fixed it > http://build-failures.rhaalovely.net/sparc64/2020-06-04/lang/hashlink.log src/hl.h:247:9: error: unknown type name 'char16_t' broken on sparc64 I guess
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: st...@cvs.openbsd.org 2020/06/06 13:14:15 Modified files: games/wrath: Makefile Log message: games/wrath: only try to build with SSE/SSE2 on x86
NEW: py-dotenv
OK to import this? LibreNMS wants it for some things. handle .env files Python module and command-line tool to write and read .env-like files, commonly used with Procfile-based applications. Maintainer: The OpenBSD ports mailing-list WWW: https://github.com/pedroburon/dotenv py-dotenv.tgz Description: application/tar-gz
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: st...@cvs.openbsd.org 2020/06/06 13:02:25 Modified files: net/librenms : Makefile distinfo net/librenms/pkg: PLIST README Log message: update to librenms-1.64.1
Re: NEW: ipynb-py-convert - converter between Jupyter Notebooks and .py
On Sat 06/06/2020 10:04, Thomas Frohwein wrote: > On Sat, Jun 06, 2020 at 09:25:42AM +0200, Rafael Sadowski wrote: > > On Sat Jun 06, 2020 at 08:10:37AM +0200, Bjorn Ketelaars wrote: > [...] > > > I think it is nice to have this tool in ports. Two comments/questions: > > > - I'm not sure that www is the right category, is devel not more > > > appropriate? > > > > IMHO devel is already too full. > > I chose www because that's where jupyter-notebook lives. The line in > www/jupyter-notebook is actually CATEGORIES=www devel. > Since this port is so closely tied to jupyter-notebook, I suggest using > the same line, that is both www and devel. > > > > - Maybe add HOMEPAGE=https://github.com/kiwi0fruit/ipynb-py-convert to > > > Makefile? > > You caught me there, thanks. Same for NO_TEST=Yes. > > I added these 3 changes to a fresh tarball which is attached. > > ok? OK bket@
Re: devel/cargo: change few default build options
On Fri, Jun 05, 2020 at 09:31:42AM +0200, Sebastien Marie wrote:
Hello Sebastien,
A few thoughts on default Cargo options for release compilation: take them
for what they're worth, which might not be very much!
> + echo "overflow-checks = false" >>${WRKDIR}/.cargo/config; \
Personally I wouldn't mind if we experimented with "overflow-checks = true"
since although overflow in Rust is not undefined behaviour, I've not yet
seen a use that wasn't a bug (since people should use the 'unchecked'
variants in such cases). I have heard various figures given for the
performance impact of this, none of them very recent. If it turns out to
make things horribly slow, I think we'd soon find out from users and could
turn the overflow checks off!
> + echo "lto = 'off'" >>${WRKDIR}/.cargo/config; \
My experience is that LTO gives around a 5% performance increase on average,
at the cost of noticeable increases in compilation time. I believe it once
used to trigger bugs in LLVM, although I have not seen this happen in the
couple of years that I've been using this in my projects. If we can bear the
compilation time hit (and I know that Rust ports are already slow to
compile), this might be worth turning on.
> + echo "panic = 'unwind'" >>${WRKDIR}/.cargo/config; \
Most Rust programs that I've seen don't make use of 'unwind' and can be
'abort', which leads to slightly smaller binaries. I'm not sure what to do
about those programs that really do require 'unwind' though: make them turn
it on via a flag?
> + echo "codegen-units = 4" >>${WRKDIR}/.cargo/config; \
This one is tricky, because you get better optimisation at codegen-units=1,
but less parallel compilation. However, that might not be a problem in the
main usecase of building with dpb, where restricting compilation to a single
core might even be thought an advantage?
Laurie
Re: NEW: ipynb-py-convert - converter between Jupyter Notebooks and .py
On Sat, Jun 06, 2020 at 09:25:42AM +0200, Rafael Sadowski wrote: > On Sat Jun 06, 2020 at 08:10:37AM +0200, Bjorn Ketelaars wrote: [...] > > I think it is nice to have this tool in ports. Two comments/questions: > > - I'm not sure that www is the right category, is devel not more > > appropriate? > > IMHO devel is already too full. I chose www because that's where jupyter-notebook lives. The line in www/jupyter-notebook is actually CATEGORIES=www devel. Since this port is so closely tied to jupyter-notebook, I suggest using the same line, that is both www and devel. > > - Maybe add HOMEPAGE=https://github.com/kiwi0fruit/ipynb-py-convert to > > Makefile? You caught me there, thanks. Same for NO_TEST=Yes. I added these 3 changes to a fresh tarball which is attached. ok? ipynb-py-convert.tgz Description: Binary data
Re: [NEW] lang/mercury
On Sat, Jun 06, 2020 at 07:51:56AM +, niamkik wrote: > Hi everyone, > > Please find in attachment the port for mercury-lang[1] stable version. Here > the package description: > > Mercury is a pure logic programming language intended for the creation > of large, fast, reliable programs. The syntax of Mercury is based on > the syntax of Prolog, but semantically the two languages are very > different due to Mercury's purity, its type, mode, determinism and > module systems. > > This package was tested on OpenBSD-6.6, OpenBSD-6.7 and OpenBSD-current. This > package was initially sent to openbsd-wip on github[2]. > > Regards, > Mathieu > > [1] mercurylang.org/ > [2] https://github.com/jasperla/openbsd-wip/pull/133 Hi Mathieu, A couple issues right off the bat. You don't need a REVISION marker since this would be the initial import. It also looks like 20.01.2 was release on May 3rd. pkg/PLIST seems to be empty, so not sure how this port/pkg would even install anything. You also have CONFIGURE_ENV set CC=egcc but don't depend on ports gcc anywhere. You might want to look into the COMPILER option if you really need to depend on ports gcc.
update to net/blaeu 1.1.6
Here is an update to net/blaeu
Index: Makefile
===
RCS file: /cvs/ports/net/blaeu/Makefile,v
retrieving revision 1.6
diff -u -p -r1.6 Makefile
--- Makefile12 Jul 2019 21:07:46 - 1.6
+++ Makefile6 Jun 2020 15:12:28 -
@@ -2,10 +2,9 @@
COMMENT = create measurements on RIPE Atlas probes.
-MODPY_EGG_VERSION = 1.1.4
+MODPY_EGG_VERSION = 1.1.6
DISTNAME = blaeu-${MODPY_EGG_VERSION}
CATEGORIES = net
-REVISION = 1
MAINTAINER = Denis Fondras
Index: distinfo
===
RCS file: /cvs/ports/net/blaeu/distinfo,v
retrieving revision 1.2
diff -u -p -r1.2 distinfo
--- distinfo28 Jun 2018 11:28:00 - 1.2
+++ distinfo6 Jun 2020 15:12:28 -
@@ -1,2 +1,2 @@
-SHA256 (blaeu-1.1.4.tar.gz) = vgPpVlF9ZyRgkfeyyxFzIRcXl9q4AragS5jzicvaPRc=
-SIZE (blaeu-1.1.4.tar.gz) = 19574
+SHA256 (blaeu-1.1.6.tar.gz) = FBJ4rsr/2UjBFRFtwxX4dsdWYa+jhGGEkrm6e5HXkLQ=
+SIZE (blaeu-1.1.6.tar.gz) = 21095
aarch64 bulk build report
bulk build on arm64.ports.openbsd.org started on Wed Jun 3 13:40:19 MDT 2020 finished at Sat Jun 6 08:07:58 MDT 2020 lasted 2D18h27m done with kern.version=OpenBSD 6.7-current (GENERIC.MP) #641: Tue Jun 2 20:58:46 MDT 2020 built packages:10942 Jun 3:3246 Jun 4:1249 Jun 5:2777 Jun 6:3669 critical path missing pkgs: http://build-failures.rhaalovely.net/aarch64/2020-06-03/summary.log build failures: 11 http://build-failures.rhaalovely.net/aarch64/2020-06-03/editors/xwpe.log http://build-failures.rhaalovely.net/aarch64/2020-06-03/graphics/vulkan-loader.log http://build-failures.rhaalovely.net/aarch64/2020-06-03/lang/pfe.log http://build-failures.rhaalovely.net/aarch64/2020-06-03/sysutils/krename.log http://build-failures.rhaalovely.net/aarch64/2020-06-03/sysutils/nomad.log http://build-failures.rhaalovely.net/aarch64/2020-06-03/sysutils/rclone.log http://build-failures.rhaalovely.net/aarch64/2020-06-03/sysutils/telegraf.log http://build-failures.rhaalovely.net/aarch64/2020-06-03/sysutils/terragrunt.log http://build-failures.rhaalovely.net/aarch64/2020-06-03/telephony/resiprocate,.log http://build-failures.rhaalovely.net/aarch64/2020-06-03/x11/e17/elementary.log http://build-failures.rhaalovely.net/aarch64/2020-06-03/x11/qt5/qtwebengine.log recurrent failures failures/editors/xwpe.log failures/graphics/vulkan-loader.log failures/lang/pfe.log failures/sysutils/nomad.log failures/sysutils/rclone.log failures/sysutils/telegraf.log failures/telephony/resiprocate,.log failures/x11/e17/elementary.log failures/x11/qt5/qtwebengine.log new failures +++ ls-failures Sat Jun 6 08:08:10 2020 +failures/sysutils/krename.log resolved failures --- ../old/aarch64/last//ls-failuresTue Jun 2 01:51:00 2020 -failures/net/gnugk.log -failures/x11/spice-gtk.log
Re: Making a FreeCAD Port
Stuart are referring to this WIP here? https://github.com/jasperla/openbsd-wip/tree/master/cad/freecad Paco your WIP seems like a better building block https://git.e1e0.net/openbsd-wip/ Charlie which dependencies have you built so far? Do you have a WIP repo as well? On Fri, Jun 5, 2020 at 4:04 AM Stuart Henderson wrote: > On 2020/06/04 21:04, Justin Noor wrote: > > Hi @ports, > > > > Is there anyone working on FreeCAD? It's not in /usr/ports/cad, and I > > searched the mailing list and did not find anything fruitful. If not, > would > > like to give it a shot if possible - this would be my first port. If > there > > is anyone working on it, please let me know how I can contribute. > > > > Thank you > > I haven't seen any indication that anyone's working on it. There is > a first attempt in openbsd-wip but it's nowhere near a working port > (just downloads the distfile and runs cmake which then fails due to > lack of dependencies) and hasn't been touched after the initial > addition in 2015. > > The starting point is to map out what's needed with the dependencies. > There's a list at https://wiki.freecadweb.org/Third_Party_Libraries > which is hopefully up-to-date enough to be useful. Some are available > in ports already (pkglocate will help find them) - may be a suitable > version already or may need updating. Others (including OpenCASCADE, > Coin3d, PySide) will need porting first (and some of these will have > their own chain of dependencies). > >
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: ajacou...@cvs.openbsd.org 2020/06/06 06:29:25 Modified files: net/gnugk : Makefile Log message: Explicitely --disable-redis to prevent picking up libhiredis. spotted by naddy@
[NEW] devel/rebar3
Hi everyone, Please find in attachment the port for rebar3[1] stable version. Here the package description: Rebar3 is an Erlang tool that makes it easy to create, develop, and release Erlang libraries, applications, and systems in a repeatable manner. This package was tested on OpenBSD-6.6, and OpenBSD-current. This package was initially sent to openbsd-wip on github[2]. Regards, Mathieu [1] https://www.rebar3.org/ [2] https://github.com/jasperla/openbsd-wip/pull/134 rebar3.tar.gz Description: application/gzip
[NEW] lang/mercury
Hi everyone, Please find in attachment the port for mercury-lang[1] stable version. Here the package description: Mercury is a pure logic programming language intended for the creation of large, fast, reliable programs. The syntax of Mercury is based on the syntax of Prolog, but semantically the two languages are very different due to Mercury's purity, its type, mode, determinism and module systems. This package was tested on OpenBSD-6.6, OpenBSD-6.7 and OpenBSD-current. This package was initially sent to openbsd-wip on github[2]. Regards, Mathieu [1] mercurylang.org/ [2] https://github.com/jasperla/openbsd-wip/pull/133 mercury.tar.gz Description: application/gzip
NEW: fonts/literata
Hi, Literata is a contemporary serif typeface family, intended for long-form reading especially in eBooks. It was commisioned for exclusive use by Google Play Books in 2014, and released under the SIL Open Font License for everyone in January 2019 with a Variable Font "Weight" axis. The Literata project was commissioned by Google from TypeTogether, an international type design foundry. ok? -- Anthony J. Bentley literata.tar.gz Description: literata.tar.gz
Re: NEW: math/gretl
Hi, On Mon, Mar 11, 2019 at 4:43 AM Anthony J. Bentley wrote: > Gretl (GNU regression, econometrics and time-series library) comprises > libgretl, a shared library which provides various functions relating to > econometric estimation, a command-line client program and a gui client, > using GTK+. > > Libgretl is based on the stand-alone command-line econometrics program > ESL, originally written by Ramu Ramanathan of the Department of Economics > at UC-San Diego. > > ok? Attached is an updated port. -- Anthony J. Bentley gretl.tar.gz Description: application/gzip
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: ajacou...@cvs.openbsd.org 2020/06/06 04:52:57 Modified files: sysutils/nomad : Makefile distinfo Log message: Update to nomad-0.11.3.
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: ajacou...@cvs.openbsd.org 2020/06/06 04:43:13 Modified files: sysutils/google-cloud-sdk: Makefile distinfo sysutils/google-cloud-sdk/pkg: PLIST Log message: Update to google-cloud-sdk-295.0.0.
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: ajacou...@cvs.openbsd.org 2020/06/06 04:41:26 Modified files: print/cups-filters: Makefile distinfo Removed files: print/cups-filters/patches: patch-filter_gstoraster_c patch-filter_rastertopdf_cpp Log message: Update to cups-filters-1.27.5.
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: ajacou...@cvs.openbsd.org 2020/06/06 04:37:02 Modified files: sysutils/amazon-ssm-agent: Makefile distinfo Log message: Update to amazon-ssm-agent-2.3.1319.0.
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: ajacou...@cvs.openbsd.org 2020/06/06 04:31:04 Modified files: sysutils/amazon-ecs-cli: Makefile distinfo Log message: Update to ecs-cli-1.19.1.
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: ajacou...@cvs.openbsd.org 2020/06/06 04:27:27 Modified files: multimedia/py-chromecast: Makefile distinfo Log message: Update to py3-chromecast-6.0.0.
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: ajacou...@cvs.openbsd.org 2020/06/06 04:28:09 Modified files: mail/sendmail : Makefile distinfo mail/sendmail/patches: patch-cf_cf_Makefile patch-cf_feature_msp_m4 patch-cf_m4_proto_m4 patch-libsm_ldap_c patch-mail_local_Makefile_m4 Log message: Update to sendmail-8.16.0.50.
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: ajacou...@cvs.openbsd.org 2020/06/06 04:25:53 Modified files: misc/hwdata: Makefile distinfo Log message: Update to hwdata-0.336.
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: ajacou...@cvs.openbsd.org 2020/06/06 04:21:20 Modified files: games/tuxpaint-config: Makefile distinfo games/tuxpaint-config/patches: patch-Makefile patch-src_tuxpaint-config_1 Log message: Update to tuxpaint-config-0.0.15.
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: ajacou...@cvs.openbsd.org 2020/06/06 04:21:42 Modified files: games/tuxpaint-stamps: Makefile distinfo games/tuxpaint-stamps/pkg: PLIST Log message: Update to tuxpaint-stamps-20200520.
Re: UPDATE x11/herbstluftwm 0.7.2 -> 0.8.2
On Tue 02/06/2020 12:54, Lucas wrote: > Hello ports@, > > Find an update for herbstluftwm, jointly done with Florian (in CC). > We'll take maintainership of the port while at it. > > Too many fixes and improvements to list. Find them in [0]. > > Portwise: > - Upstream changed build system to CMake. That allows us to get rid of > FAKE_FLAGS. > - Dist tarball includes compiled manpages. Use them instead of building > ourselves, saving a depend on asciidoc. > - We no longer install the HTML versions of manpages. We aren't sure if > this is the prefered way, given there are the manpages already, so let > us know if we should re-add them. IMHO addition of the HTML version has little to no value. I agree with your choice. > - Makefile aesthetics: reorder according to Makefile.template and align > values. That's a lot whitespace churn. > - Fixes for portcheck and make port-lib-depends-check. glib-2.0 and > intl are out of WANTLIB and glib-2.0 is not a dep. > - hlwm now ships tests! Sadly, they rely on pyewmh[1] and > pytest-xfvb[2]. Porting pyewmh was a piece of cake; didn't manage to > make pytest-xfvb run its own tests, as it seems it isn't running a new > Xvfb as a subprocess while executing internal pytest tests. Also I'm > not sure if importing 2 ports for being able to run tests is > desirable. So, for the time being, keep NO_TEST=Yes. > - We aren't sure if we should add x11/dmenu to RUN_DEPENDS. One of the > 4 scripts it installs to /etc/xdg/herbstluftwm needs it, but that > script isn't referenced by the others, unlike the case x11/dzen2. > Advice is welcome in here, too. After installation of this update I only see 3 scripts in /etc/xdg/herbstluftwm. None of them use dmenu. As such, I see no reason to add x11/dmenu as RDEP. $ ls -l /etc/xdg/herbstluftwm/ total 40 -rwxr-xr-x 1 root wheel 5365 Jun 6 11:44 autostart -rwxr-xr-x 1 root wheel 6210 Jun 6 11:44 panel.sh -rwxr-xr-x 1 root wheel 379 Jun 6 11:44 restartpanels.sh > - PLIST changes: > - HTML manuals are gone (as said, can be added back) > - share/examples/herbstluftwm/ -> share/doc/herbstluftwm/examples/, > which is what upstream ships as docs > - share/examples/herbstluftwm/xdg/herbstluftwm/ -> > share/examples/herbstluftwm/ > - dmenu_run_hlwm was being installed to bin/; now resides in > share/examples/herbstluftwm/ Odd, I would expect that having dmenu_run_hlwm in /usr/local/bin/ is a good reason for adding dmenu as RDEP. Guess this is not relevant as you propose to move this script. However, I have a question: is moving this script going to break existing installations? Other question: why is dmenu_run_hlwm moved in the post-install phase?
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: ajacou...@cvs.openbsd.org 2020/06/06 04:13:29 Modified files: games/tuxpaint : Makefile distinfo games/tuxpaint/patches: patch-Makefile patch-src_manpage_tuxpaint_1 games/tuxpaint/pkg: PLIST Removed files: games/tuxpaint/patches: patch-src_tuxpaint_c Log message: Update to tuxpaint-0.9.24.
Re: boost-md: build on sparc64
On 6/6/2020 1:54 AM, Brad Smith wrote: On 6/6/2020 1:32 AM, Rafael Sadowski wrote: On Fri Jun 05, 2020 at 11:55:21PM +0200, Klemens Nanni wrote: I thought I had already sent out (or even committed) this diff... For another WIP port, boost-md is required is required. I've been building and linking against it just fine on sparc64. OK? If it works on sparc64, sure! I was under the impression that this did not build with there being some missing MD code, but if it does then go ahead. Klemens, Please update the comment further down in the Makefile about the MD bits to remove SPARC.
Re: boost-md: build on sparc64
On 6/6/2020 1:32 AM, Rafael Sadowski wrote: On Fri Jun 05, 2020 at 11:55:21PM +0200, Klemens Nanni wrote: I thought I had already sent out (or even committed) this diff... For another WIP port, boost-md is required is required. I've been building and linking against it just fine on sparc64. OK? If it works on sparc64, sure! I was under the impression that this did not build with there being some missing MD code, but if it does then go ahead.
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: ajacou...@cvs.openbsd.org 2020/06/06 03:54:45 Modified files: devel/harfbuzz : Makefile distinfo Added files: devel/harfbuzz/patches: patch-src_check-symbols_py Log message: Update to harfbuzz-2.6.7.
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: ajacou...@cvs.openbsd.org 2020/06/06 03:46:12 Modified files: sysutils/awscli: Makefile distinfo Log message: Update to awscli-1.18.74.
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: ajacou...@cvs.openbsd.org 2020/06/06 03:45:49 Modified files: net/py-botocore: Makefile distinfo Log message: Update to py3-botocore-1.16.24.
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: ajacou...@cvs.openbsd.org 2020/06/06 03:45:59 Modified files: net/py-boto3 : Makefile distinfo Log message: Update to py3-boto3-1.13.24.
Re: NEW: devel/msbuild - build system for .NET
On Tue 02/06/2020 08:58, Thomas Frohwein wrote:
> ping
>
> On Tue, May 19, 2020 at 03:27:51PM -0600, Thomas Frohwein wrote:
> > Hi,
> >
> > This is a port of MSBuild, the build system for .NET. lang/mono ships with
> > xbuild which was an initial replacement for MSBuild, however since the more
> > official integration of mono into .NET, xbuild has been deprecated by mono
> > for
> > several years now. Of note, that happened without MSBuild actually shipping
> > with mono.
> >
> > At this point there is a growing list of .NET projects that only build with
> > MSBuild. That's the raison d'etre for this port.
> >
> > This port is heavily inspired by FreeBSD's port which helped me simplify
> > things
> > and find some solutions. It bootstraps itself with a bundled MSBuild
> > assembly
> > that is invoked with mono, and pulls in a gargantuan (1G after extraction)
> > amount of NuGet dependencies via a bundled NuGet assembly. I have created a
> > separate tar.xz of those dependencies, so that it builds without internet
> > connection.
> >
> > Passes make port-lib-depends-check and portcheck. I have built a few
> > projects
> > like the latest (upstream) version of games/openra which refuses to work
> > with
> > xbuild successfully. There are still a lot of projects that look for
> > non-existant components which are likely included with Microsoft's dotnet/
> > corefx/coreclr distributions.
> >
> > Other things of note about the port:
> >
> > - This is not the very latest version upstream, but newer ones seem to
> > require
> > dotnet CLI. It's the same as in FreeBSD's tree though.
> > - Versioning is confusing between mono's 0.06, and the MSBuild versioning. I
> > chose 15.8pre0 based on what FreeBSD does ("15.8-preview")
> > - The license is MIT. There are 137 NuGet packages in the build. These are a
> > mix of MIT, Apache-2.0, and Microsoft .NET library license [1]
> > - 'make test' doesn't work at this point, therefore is disabled (see
> > comment in
> > Makefile)
> >
> > Thanks to bcallah@ for hosting the NuGet dependencies.
> >
> > Comments, concerns, ok's are welcome.
> >
> > [1] https://dotnet.microsoft.com/en/dotnet_library_license.htm
Looks good, and builds for me on amd64. More important, this import
paves the way for a newer version of openra.
OK bket@
Re: NEW: ipynb-py-convert - converter between Jupyter Notebooks and .py
On Sat Jun 06, 2020 at 08:10:37AM +0200, Bjorn Ketelaars wrote: > On Fri 05/06/2020 12:38, Thomas Frohwein wrote: > > ping > > > > On Sat, May 23, 2020 at 03:33:48PM -0600, Thomas Frohwein wrote: > > > Hi, > > > > > > Jupyter Notebooks are a mess to version control, as they contain > > > encoded output data, like the images of graphs. > > > > > > The best way to version control that I have found is ipynb-py-convert > > > which converts the notebooks into .py files that only include input, as > > > well as comments '# %%' to indicate the cell separators. Markdown cells > > > are converted to python multiline strings. > > > > > > This is a very straightforward port from pypi.org. The syntax is: > > > > > > $ ipynb-py-convert [input] [output] > > > > > > I've tested it with a Jupyter Notebook that I'm working on and > > > successfully converted it to .py and back, with no issues in the > > > resulting .ipynb. > > > > > > ok? > > I think it is nice to have this tool in ports. Two comments/questions: > - I'm not sure that www is the right category, is devel not more > appropriate? IMHO devel is already too full. > - Maybe add HOMEPAGE=https://github.com/kiwi0fruit/ipynb-py-convert to > Makefile? >
UPDATE: www/minitube
Simple diff to update minitube to 3.4.1. minitube users around? diff --git a/www/minitube/Makefile b/www/minitube/Makefile index 302cdf0c91a..67c3893875b 100644 --- a/www/minitube/Makefile +++ b/www/minitube/Makefile @@ -2,10 +2,9 @@ COMMENT = standalone YouTube.com video browser/player -V =3.3 +V =3.4.1 DISTNAME = minitube-$V EXTRACT_SUFX = .tar.bz2 -REVISION = 1 CATEGORIES = www multimedia diff --git a/www/minitube/distinfo b/www/minitube/distinfo index 1009ff836ec..9ec5e75e822 100644 --- a/www/minitube/distinfo +++ b/www/minitube/distinfo @@ -1,2 +1,2 @@ -SHA256 (minitube-3.3.tar.bz2) = 03XJOTFq/9XO8Wy7xnn3Wx72PGCYxJnh/8LoqiF/AeE= -SIZE (minitube-3.3.tar.bz2) = 1054137 +SHA256 (minitube-3.4.1.tar.bz2) = R1mdBvv0yEhlx8FxuMY3btqSVDpub3a161bTmSZ1ysc= +SIZE (minitube-3.4.1.tar.bz2) = 1292615
Re: UPDATE: audio/musique
On Sat Jun 06, 2020 at 08:28:01AM +0200, Rafael Sadowski wrote:
> Update musique to 1.7
>
> - Switch to qt5
> - Self hosted tarball, see:
> https://github.com/flaviotordini/musique/issues/25
> - Remove patches. I see no icon issues outside of a Desktop env.
>
> Tested on amd64. Play music, download album pictures, adjust volume,
> everything works.
>
> OK?
>
Better diff with bz2 fix form minitube.
diff --git a/audio/musique/Makefile b/audio/musique/Makefile
index 814bb61260d..b268932c944 100644
--- a/audio/musique/Makefile
+++ b/audio/musique/Makefile
@@ -1,36 +1,46 @@
# $OpenBSD: Makefile,v 1.21 2019/07/12 20:43:37 sthen Exp $
COMMENT = graphical music player focused on a clean ui
-DISTNAME = musique-1.4
+V =1.7
+DISTNAME = musique-${V}
CATEGORIES = audio
-REVISION = 7
+EXTRACT_SUFX = .tar.bz2
HOMEPAGE = http://flavio.tordini.org/musique/
# GPLv3
PERMIT_PACKAGE = Yes
-MASTER_SITES = http://flavio.tordini.org/files/musique/
+WANTLIB += ${COMPILER_LIBCXX} GL Qt5Core Qt5DBus Qt5Gui Qt5Network
+WANTLIB += Qt5Sql Qt5Widgets c m tag
-WANTLIB += ICE QtDBus QtGui QtNetwork QtSql QtXml SM
-WANTLIB += X11 Xext Xi Xinerama Xrender c fontconfig
-WANTLIB += freetype m phonon pthread ${COMPILER_LIBCXX} tag
+# https://github.com/flaviotordini/musique/issues/25
+#MASTER_SITES =https://www.sizeofvoid.org/pub/OpenBSD/distfiles/
+MASTER_SITES = https://github.com/flaviotordini/musique/releases/download/$V/
-COMPILER = base-clang ports-gcc base-gcc
+# minitube-3.1.tar.bz2 is actually gzipped.
+# i would just use GH_* rather than EXTRACT_CASES, but the git tree uses
+# submodules (build fails with missing media.h) so this is easier.
+EXTRACT_CASES += musique*.tar.bz2) ${GZIP_CMD} -d <${FULLDISTDIR}/$$archive |
${TAR} xf -;;
-MODULES = devel/qmake x11/qt4
+MODULES = devel/qmake \
+ x11/qt5
LIB_DEPENDS = audio/taglib
+BUILD_DEPENDS =multimedia/qtav
+
RUN_DEPENDS = devel/desktop-file-utils \
- multimedia/gstreamer-0.10/plugins-good \
multimedia/gstreamer-0.10/plugins-ffmpeg \
+ multimedia/gstreamer-0.10/plugins-good \
+ multimedia/qtav \
x11/gtk+3,-guic
-WRKDIST = ${WRKDIR}/musique
NO_TEST = Yes
pre-configure:
perl -pi -e 's,/usr/include,${LOCALBASE}/include,' ${WRKSRC}/musique.pro
+ perl -pi -e 's,imagedownloader.h,../imagedownloader.h,' \
+ ${WRKSRC}/src/model/artist.cpp
.include
diff --git a/audio/musique/distinfo b/audio/musique/distinfo
index 34e59391e91..f88bfeebe25 100644
--- a/audio/musique/distinfo
+++ b/audio/musique/distinfo
@@ -1,2 +1,2 @@
-SHA256 (musique-1.4.tar.gz) = CN+0IBqg7cSz/k73eI5hj3VMOSHzp8HNzkDvOZl2BnA=
-SIZE (musique-1.4.tar.gz) = 390031
+SHA256 (musique-1.7.tar.bz2) = TjSnMhWAkJHULdQEd9cFLDP6T2cJE27P/yxGwUHtew0=
+SIZE (musique-1.7.tar.bz2) = 425143
diff --git a/audio/musique/patches/patch-src_iconutils_cpp
b/audio/musique/patches/patch-src_iconutils_cpp
deleted file mode 100644
index b393d17cc03..000
--- a/audio/musique/patches/patch-src_iconutils_cpp
+++ /dev/null
@@ -1,25 +0,0 @@
-$OpenBSD: patch-src_iconutils_cpp,v 1.1 2014/12/01 14:35:59 dcoppa Exp $
-
-Use the Adwaita icon theme unconditionally: fixes a problem with
-minitube GUI not having icons when executed outside of a Desktop
-Environment
-
-Do not use symbolic icons
-
src/iconutils.cpp.orig Mon Dec 1 05:23:52 2014
-+++ src/iconutils.cpp Mon Dec 1 05:25:00 2014
-@@ -21,12 +21,8 @@ $END_LICENSE */
- #include "iconutils.h"
-
- QIcon IconUtils::fromTheme(const QString ) {
--const QLatin1String symbolic("-symbolic");
--if (name.endsWith(symbolic)) return QIcon::fromTheme(name);
--QIcon icon;
--icon = QIcon::fromTheme(name + symbolic);
--if (icon.isNull()) return QIcon::fromTheme(name);
--return icon;
-+QIcon::setThemeName("Adwaita");
-+return QIcon::fromTheme(name);
- }
-
- QIcon IconUtils::fromResources(const QString ) {
diff --git a/audio/musique/patches/patch-src_mainwindow_cpp
b/audio/musique/patches/patch-src_mainwindow_cpp
deleted file mode 100644
index 9771385de8f..000
--- a/audio/musique/patches/patch-src_mainwindow_cpp
+++ /dev/null
@@ -1,15 +0,0 @@
-$OpenBSD: patch-src_mainwindow_cpp,v 1.2 2014/12/01 14:35:59 dcoppa Exp $
-
-Fix "Info" icon
-
src/mainwindow.cpp.origMon Dec 1 05:25:29 2014
-+++ src/mainwindow.cpp Mon Dec 1 05:26:10 2014
-@@ -192,7 +192,7 @@ void MainWindow::createActions() {
- actions->insert("back", backAct);
- connect(backAct, SIGNAL(triggered()), SLOT(goBack()));
-
--QIcon icon = IconUtils::icon(QStringList() << "audio-headphones" <<
"gtk-info" << "help-about");
-+QIcon icon = IconUtils::icon("help-about");
- contextualAct = new QAction(icon, tr(""), this);
- contextualAct->setStatusTip(tr("Show information about the current
track"));
-
UPDATE: audio/musique
Update musique to 1.7
- Switch to qt5
- Self hosted tarball, see:
https://github.com/flaviotordini/musique/issues/25
- Remove patches. I see no icon issues outside of a Desktop env.
Tested on amd64. Play music, download album pictures, adjust volume,
everything works.
OK?
diff --git a/audio/musique/Makefile b/audio/musique/Makefile
index 814bb61260d..698a925d77f 100644
--- a/audio/musique/Makefile
+++ b/audio/musique/Makefile
@@ -1,30 +1,31 @@
# $OpenBSD: Makefile,v 1.21 2019/07/12 20:43:37 sthen Exp $
COMMENT = graphical music player focused on a clean ui
-DISTNAME = musique-1.4
+DISTNAME = musique-1.7
CATEGORIES = audio
-REVISION = 7
HOMEPAGE = http://flavio.tordini.org/musique/
# GPLv3
PERMIT_PACKAGE = Yes
-MASTER_SITES = http://flavio.tordini.org/files/musique/
+WANTLIB += ${COMPILER_LIBCXX} GL Qt5Core Qt5DBus Qt5Gui Qt5Network
+WANTLIB += Qt5Sql Qt5Widgets c m tag
-WANTLIB += ICE QtDBus QtGui QtNetwork QtSql QtXml SM
-WANTLIB += X11 Xext Xi Xinerama Xrender c fontconfig
-WANTLIB += freetype m phonon pthread ${COMPILER_LIBCXX} tag
+# https://github.com/flaviotordini/musique/issues/25
+MASTER_SITES = https://www.sizeofvoid.org/pub/OpenBSD/distfiles/
-COMPILER = base-clang ports-gcc base-gcc
-
-MODULES = devel/qmake x11/qt4
+MODULES = devel/qmake \
+ x11/qt5
LIB_DEPENDS = audio/taglib
+BUILD_DEPENDS =multimedia/qtav
+
RUN_DEPENDS = devel/desktop-file-utils \
- multimedia/gstreamer-0.10/plugins-good \
multimedia/gstreamer-0.10/plugins-ffmpeg \
+ multimedia/gstreamer-0.10/plugins-good \
+ multimedia/qtav \
x11/gtk+3,-guic
WRKDIST = ${WRKDIR}/musique
@@ -32,5 +33,7 @@ NO_TEST = Yes
pre-configure:
perl -pi -e 's,/usr/include,${LOCALBASE}/include,' ${WRKSRC}/musique.pro
+ perl -pi -e 's,imagedownloader.h,../imagedownloader.h,' \
+ ${WRKSRC}/src/model/artist.cpp
.include
diff --git a/audio/musique/distinfo b/audio/musique/distinfo
index 34e59391e91..85f01753ac6 100644
--- a/audio/musique/distinfo
+++ b/audio/musique/distinfo
@@ -1,2 +1,2 @@
-SHA256 (musique-1.4.tar.gz) = CN+0IBqg7cSz/k73eI5hj3VMOSHzp8HNzkDvOZl2BnA=
-SIZE (musique-1.4.tar.gz) = 390031
+SHA256 (musique-1.7.tar.gz) = SQhlQyz9Y7QCoEppjJIbw+cQd+44CrCit1qUofEe//A=
+SIZE (musique-1.7.tar.gz) = 2493157
diff --git a/audio/musique/patches/patch-src_iconutils_cpp
b/audio/musique/patches/patch-src_iconutils_cpp
deleted file mode 100644
index b393d17cc03..000
--- a/audio/musique/patches/patch-src_iconutils_cpp
+++ /dev/null
@@ -1,25 +0,0 @@
-$OpenBSD: patch-src_iconutils_cpp,v 1.1 2014/12/01 14:35:59 dcoppa Exp $
-
-Use the Adwaita icon theme unconditionally: fixes a problem with
-minitube GUI not having icons when executed outside of a Desktop
-Environment
-
-Do not use symbolic icons
-
src/iconutils.cpp.orig Mon Dec 1 05:23:52 2014
-+++ src/iconutils.cpp Mon Dec 1 05:25:00 2014
-@@ -21,12 +21,8 @@ $END_LICENSE */
- #include "iconutils.h"
-
- QIcon IconUtils::fromTheme(const QString ) {
--const QLatin1String symbolic("-symbolic");
--if (name.endsWith(symbolic)) return QIcon::fromTheme(name);
--QIcon icon;
--icon = QIcon::fromTheme(name + symbolic);
--if (icon.isNull()) return QIcon::fromTheme(name);
--return icon;
-+QIcon::setThemeName("Adwaita");
-+return QIcon::fromTheme(name);
- }
-
- QIcon IconUtils::fromResources(const QString ) {
diff --git a/audio/musique/patches/patch-src_mainwindow_cpp
b/audio/musique/patches/patch-src_mainwindow_cpp
deleted file mode 100644
index 9771385de8f..000
--- a/audio/musique/patches/patch-src_mainwindow_cpp
+++ /dev/null
@@ -1,15 +0,0 @@
-$OpenBSD: patch-src_mainwindow_cpp,v 1.2 2014/12/01 14:35:59 dcoppa Exp $
-
-Fix "Info" icon
-
src/mainwindow.cpp.origMon Dec 1 05:25:29 2014
-+++ src/mainwindow.cpp Mon Dec 1 05:26:10 2014
-@@ -192,7 +192,7 @@ void MainWindow::createActions() {
- actions->insert("back", backAct);
- connect(backAct, SIGNAL(triggered()), SLOT(goBack()));
-
--QIcon icon = IconUtils::icon(QStringList() << "audio-headphones" <<
"gtk-info" << "help-about");
-+QIcon icon = IconUtils::icon("help-about");
- contextualAct = new QAction(icon, tr(""), this);
- contextualAct->setStatusTip(tr("Show information about the current
track"));
- contextualAct->setShortcut(QKeySequence(Qt::CTRL + Qt::Key_I));
diff --git a/audio/musique/pkg/PLIST b/audio/musique/pkg/PLIST
index 893c4194d8f..23fe636de44 100644
--- a/audio/musique/pkg/PLIST
+++ b/audio/musique/pkg/PLIST
@@ -15,6 +15,7 @@ share/musique/locale/
share/musique/locale/ast.qm
share/musique/locale/be.qm
share/musique/locale/bg.qm
+share/musique/locale/br.qm
share/musique/locale/ca.qm
share/musique/locale/ca_ES.qm
share/musique/locale/cs_CZ.qm
@@ -33,7 +34,9 @@ share/musique/locale/gl.qm
share/musique/locale/hu_HU.qm
Re: NEW: ipynb-py-convert - converter between Jupyter Notebooks and .py
On Sat 06/06/2020 08:10, Bjorn Ketelaars wrote: > On Fri 05/06/2020 12:38, Thomas Frohwein wrote: > > ping > > > > On Sat, May 23, 2020 at 03:33:48PM -0600, Thomas Frohwein wrote: > > > Hi, > > > > > > Jupyter Notebooks are a mess to version control, as they contain > > > encoded output data, like the images of graphs. > > > > > > The best way to version control that I have found is ipynb-py-convert > > > which converts the notebooks into .py files that only include input, as > > > well as comments '# %%' to indicate the cell separators. Markdown cells > > > are converted to python multiline strings. > > > > > > This is a very straightforward port from pypi.org. The syntax is: > > > > > > $ ipynb-py-convert [input] [output] > > > > > > I've tested it with a Jupyter Notebook that I'm working on and > > > successfully converted it to .py and back, with no issues in the > > > resulting .ipynb. > > > > > > ok? > > I think it is nice to have this tool in ports. Two comments/questions: > - I'm not sure that www is the right category, is devel not more > appropriate? > - Maybe add HOMEPAGE=https://github.com/kiwi0fruit/ipynb-py-convert to > Makefile? One more comment: NO_TEST=Yes can be set in Makefile as there is no test suite.
Re: NEW: ipynb-py-convert - converter between Jupyter Notebooks and .py
On Fri 05/06/2020 12:38, Thomas Frohwein wrote: > ping > > On Sat, May 23, 2020 at 03:33:48PM -0600, Thomas Frohwein wrote: > > Hi, > > > > Jupyter Notebooks are a mess to version control, as they contain > > encoded output data, like the images of graphs. > > > > The best way to version control that I have found is ipynb-py-convert > > which converts the notebooks into .py files that only include input, as > > well as comments '# %%' to indicate the cell separators. Markdown cells > > are converted to python multiline strings. > > > > This is a very straightforward port from pypi.org. The syntax is: > > > > $ ipynb-py-convert [input] [output] > > > > I've tested it with a Jupyter Notebook that I'm working on and > > successfully converted it to .py and back, with no issues in the > > resulting .ipynb. > > > > ok? I think it is nice to have this tool in ports. Two comments/questions: - I'm not sure that www is the right category, is devel not more appropriate? - Maybe add HOMEPAGE=https://github.com/kiwi0fruit/ipynb-py-convert to Makefile?
