CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: bcal...@cvs.openbsd.org 2018/08/02 23:47:35 Modified files: lang/flang : Makefile.inc lang/flang/flang: Makefile distinfo lang/flang/libpgmath: Makefile distinfo Log message: Update to latest flang code, fixes for Fortran 2008 SUBMODULES. While here, temporarily mark flang as BROKEN-arm64 to not waste the build-bot's time. See: https://github.com/flang-compiler/flang/issues/557 for more information.
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: rsadow...@cvs.openbsd.org 2018/08/02 23:14:53 Modified files: textproc : Makefile Log message: hook cmark
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: rsadow...@cvs.openbsd.org 2018/08/02 23:13:37 Log message: Import cmark-0.28.3 Information for inst:cmark-0.28.3 Comment: CommonMark parsing and rendering library and program in C Description: cmark is the C reference implementation of CommonMark, a rationalized version of Markdown syntax with a spec. Maintainer: Jan Klemkow WWW: https://commonmark.org/ Initial port from me, with tweaks from Jan Klemkow (maintainer) based on sthen@'s feedback. OK sthen@ Status: Vendor Tag: rsadowski Release Tags: rsadowski_20180803 N ports/textproc/cmark/Makefile N ports/textproc/cmark/distinfo N ports/textproc/cmark/pkg/DESCR N ports/textproc/cmark/pkg/PLIST No conflicts created by this import
Re: [NEW] gzdoom-3.5.0
Solene Rapenne writes: > timo.my...@bittivirhe.fi (Timo Myyrä) wrote: > >> Hi, >> >> Here's a updated port for latest gzdoom version. >> Merged the stuff from Solene's port into my old gzdoom port and bumped it to >> latest version. Tested on amd64 and quick gameplay test seems to work and >> installing soundfont and tuning the ini file, the fluidsynth playback works. >> >> - added patch to fix the fluidsynth library name >> >> - dropped old linker args from Makefile, these don't seem to be needed at all >> >> - Added flag to disable GTK dialogs from building so no need for Gtk >> dependency >> >> - fluidsynth is detected at build time so add it as build_depends. At run >> time >> it needs to be installed but gzdoom can use other midi players as well so I >> didn't add it to run_depends. >> >> - Dropped previous gxmessage dependy, the game tries kdialog, gxmessage and >> finally xmessage to show crash log. >> >> - OpenAL needs to be installed to have audio. >> >> >> Timo > > Your port is way better than the one I submitted last month, good work! Still > when using mods, I only have music and no other sound, do you have the same > issue? Doom1 and Doom2 runs fine, so it may be related to the mods... I tested Doom One mod and only got sound in menu and no gameplay sounds or music at all. Got bunch of errors in console so I guess the mods are to blame. Timo
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: j...@cvs.openbsd.org2018/08/02 20:57:33 Modified files: sysutils/u-boot: Makefile Added files: sysutils/u-boot/patches: patch-include_efi_loader_h patch-lib_efi_loader_efi_boottime_c Log message: revert 4182a129ef735bfd6c54788affe1b649ab85b851 efi_loader: allocate configuration table array After this commit, the ConfigurationTable field of the system table was no longer translated from a physical address into a virtual address when the SerVirtualAddressMap() runtime service got called. Broke boot on Orange Pi PC 2 as reported by kevlo@ and tracked down by kettenis@.
Re: [NEW] devel/libdivecomputer-subsurface
Hi Kristaps,
based on your latest version, i worked through most of my questions
regarding subsurface, and here is an updated port incorporating
what i found:
* CATEGORIES = misc as discussed with sthen@.
* Checked the accuracy of the license markers.
Added a comment regarding the none-free icons in mobile-widgets/qml/icons.
* WANTLIB += Qt5PrintSupport Grantlee_Templates -= bz z.
* Remove x11/qt5 from MODULES; it works just fine without.
* Add x11/grantlee-qt5 dependency and disable NO_PRINTING.
Now i can use File >> Print to generate PDF files.
* Sort LIB_DEPENDS such that dependencies precede dependent packages.
* Drop DOPENBSD_LOCALBASE from CONFIGURE_ARGS.
* Remove the non-free files libdivecomputer/src/aes.{c,h}.
Add the same AES patches as for libdivecomputer.
* Use auto-version variables when calling autoreconf.
* Split pre-configure and pre-build.
* Add post-build target for the documentation, update the PLIST.
Do not comment Documentation/images and ${DOCFILES} in patch-CMakeLists_txt.
* Let subsurface.debug install normally and comment it out in the PLIST.
* Remove the worst spyware features, in particular the UpdateManager,
the UserSurvey, and Facebook.
I'm planning to commit when you confirm that everything is fine
and when i get an OK from a porter.
Yours,
Ingo
P.S.
I didn't look at your update of libdivecomputer yet.
subsurface.tgz
Description: application/tar-gz
Re: aarch64 bulk build report
On Thu, Aug 02, 2018 at 05:33:09PM -0600, phess...@openbsd.org wrote: > bulk build on arm64.ports.openbsd.org > started on Tue Jul 31 03:03:08 MDT 2018 > finished at Thu Aug 2 17:30:25 MDT 2018 > lasted 03D07h27m > done with kern.version=OpenBSD 6.3-current (GENERIC.MP) #86: Mon Jul 30 > 18:57:10 MDT 2018 > > built packages:8235 > Jul 31:3169 > Aug 1:1486 > Aug 2:3579 > > > > build failures: 47 dtb, u-boot-aarch64 and py-cryptography logs show they didn't fail to build. > http://build-failures.rhaalovely.net//aarch64/2018-07-31/comms/hylafax,a4.log > http://build-failures.rhaalovely.net//aarch64/2018-07-31/comms/lcdproc.log > http://build-failures.rhaalovely.net//aarch64/2018-07-31/devel/avr/gdb.log > http://build-failures.rhaalovely.net//aarch64/2018-07-31/devel/bullet.log > http://build-failures.rhaalovely.net//aarch64/2018-07-31/devel/ode.log > http://build-failures.rhaalovely.net//aarch64/2018-07-31/devel/tbb.log > http://build-failures.rhaalovely.net//aarch64/2018-07-31/editors/xwpe.log > http://build-failures.rhaalovely.net//aarch64/2018-07-31/emulators/dynamips.log > http://build-failures.rhaalovely.net//aarch64/2018-07-31/emulators/higan.log > http://build-failures.rhaalovely.net//aarch64/2018-07-31/emulators/vbam.log > http://build-failures.rhaalovely.net//aarch64/2018-07-31/games/dungeon-crawl.log > http://build-failures.rhaalovely.net//aarch64/2018-07-31/games/dxx-rebirth.log > http://build-failures.rhaalovely.net//aarch64/2018-07-31/games/frozen-bubble,-main.log > http://build-failures.rhaalovely.net//aarch64/2018-07-31/games/nethack/3.6,qt.log > http://build-failures.rhaalovely.net//aarch64/2018-07-31/games/spacehulk.log > http://build-failures.rhaalovely.net//aarch64/2018-07-31/games/vacuum.log > http://build-failures.rhaalovely.net//aarch64/2018-07-31/graphics/freeimage.log > http://build-failures.rhaalovely.net//aarch64/2018-07-31/graphics/shotwell.log > http://build-failures.rhaalovely.net//aarch64/2018-07-31/inputmethods/uim.log > http://build-failures.rhaalovely.net//aarch64/2018-07-31/japanese/mecab,-ipadic.log > http://build-failures.rhaalovely.net//aarch64/2018-07-31/lang/flang/libpgmath.log > http://build-failures.rhaalovely.net//aarch64/2018-07-31/lang/pfe.log > http://build-failures.rhaalovely.net//aarch64/2018-07-31/mail/mozilla-thunderbird,-lightning.log > http://build-failures.rhaalovely.net//aarch64/2018-07-31/meta/kde4,-admin.log > http://build-failures.rhaalovely.net//aarch64/2018-07-31/misc/rocrail,-gui.log > http://build-failures.rhaalovely.net//aarch64/2018-07-31/multimedia/mediainfo.log > http://build-failures.rhaalovely.net//aarch64/2018-07-31/multimedia/xine-lib.log > http://build-failures.rhaalovely.net//aarch64/2018-07-31/net/castget.log > http://build-failures.rhaalovely.net//aarch64/2018-07-31/net/telepathy/folks.log > http://build-failures.rhaalovely.net//aarch64/2018-07-31/net/utox.log > http://build-failures.rhaalovely.net//aarch64/2018-07-31/productivity/aqbanking.log > http://build-failures.rhaalovely.net//aarch64/2018-07-31/security/libnipper.log > http://build-failures.rhaalovely.net//aarch64/2018-07-31/security/py-cryptography.log > http://build-failures.rhaalovely.net//aarch64/2018-07-31/security/softhsm.log > http://build-failures.rhaalovely.net//aarch64/2018-07-31/sysutils/dtb.log > http://build-failures.rhaalovely.net//aarch64/2018-07-31/sysutils/exa.log > http://build-failures.rhaalovely.net//aarch64/2018-07-31/sysutils/sleuthkit.log > http://build-failures.rhaalovely.net//aarch64/2018-07-31/sysutils/u-boot,aarch64.log > http://build-failures.rhaalovely.net//aarch64/2018-07-31/textproc/link-grammar,-main.log > http://build-failures.rhaalovely.net//aarch64/2018-07-31/www/chromium.log > http://build-failures.rhaalovely.net//aarch64/2018-07-31/www/iridium.log > http://build-failures.rhaalovely.net//aarch64/2018-07-31/www/mozilla-firefox.log > http://build-failures.rhaalovely.net//aarch64/2018-07-31/www/mozplugger.log > http://build-failures.rhaalovely.net//aarch64/2018-07-31/x11/eterm.log > http://build-failures.rhaalovely.net//aarch64/2018-07-31/x11/kde/base3,-en_US.log > http://build-failures.rhaalovely.net//aarch64/2018-07-31/x11/nx/opennx.log > http://build-failures.rhaalovely.net//aarch64/2018-07-31/x11/p5-Wx.log > > recurrent failures > failures/comms/lcdproc.log > failures/devel/avr/gdb.log > failures/devel/bullet.log > failures/devel/ode.log > failures/devel/tbb.log > failures/editors/xwpe.log > failures/lang/flang/libpgmath.log > failures/lang/pfe.log > failures/mail/mozilla-thunderbird,-lightning.log > failures/misc/rocrail,-gui.log > failures/multimedia/mediainfo.log > failures/multimedia/xine-lib.log > failures/net/castget.log > failures/net/telepathy/folks.log > failures/net/utox.log > failures/productivity/aqbanking.log > failures/security/libnipper.log > failures/security/softhsm.log > failures/sysutils/exa.log > failures/sysutils/sleuthkit.log > failures/textproc/link-grammar,-main.log >
Re: Fix for vitetris desktop file
On Thu, Aug 02, 2018 at 02:53:17PM -0800, Micah Muer wrote: > The desktop file that ships with vitetris > (/usr/local/share/applications/vitetris.desktop) has the line > `Exec=tetris -w 80`. > > Not only is tetris the wrong binary, but it doesn't work anyway since > /usr/games/tetris doesn't have the -w option. > > The solution is to use `Exec=vitetris -w 80`, which I have attempted to > create a patch for. Nice catch! I am unable to verify this at this time but the patch reads okay to me, and okay from me if someone wants to confirm it patches cleanly + can commit. Alternatively we might want to just do an in-place 'sed -i' of that line instead of introducing a patch to the port. something like: @sed -i 's,Exec=tetris,Exec=vitetris,' $WRKSRC/vitetris.desktop in a post-extract or so? Thanks for finding this. -Ryan > > Many thanks, > Micah > > Index: patches/patch-vitetris_desktop > === > RCS file: patches/patch-vitetris_desktop > diff -N patches/patch-vitetris_desktop > --- /dev/null 1 Jan 1970 00:00:00 - > +++ patches/patch-vitetris_desktop25 July 2018 17:07:38 - > @@ -0,0 +1,14 @@ > +$OpenBSD$ > + > +Index: vitetris.desktop > +--- vitetris.desktop.orig > vitetris.desktop > +@@ -3,7 +3,7 @@ Type=Application > + Encoding=UTF-8 > + Name=vitetris > + GenericName=Text-mode Tetris > +-Exec=tetris -w 80 > ++Exec=vitetris -w 80 > + Icon=vitetris > + Categories=Game;BlocksGame; > + Terminal=true >
Re: [NEW] devel/libdivecomputer-subsurface
>> Hi Stuart and Kristaps, >> >> Stuart Henderson wrote on Wed, Aug 01, 2018 at 07:57:25PM +0100: >> >>> I'd never expect to find this in multimedia... misc seems >>> perfect? >> >> I don't object to misc either and trust Stuart's judgement on this >> one. >> >> But i think libdivecomputer should have the same main category as >> subsurface, keeping all the diving ports close together. No >> objection to keeping them all in misc. I understand that even >> though it installs a shared library (which is not yet used by any >> other port), libdivecomputer can also be used standalone via the >> dctool(1) command line program included in the libdivecomputer >> port. > > I very much agree. Enclosed are both subsurface.tgz and libdivecomputer.tgz, which have the noted change. (Both are now in misc.) Both tested on amd64. (I do have a utility that uses libdivecomputer and will submit it soon.) Thank you! libdivecomputer.tgz Description: Binary data subsurface.tgz Description: Binary data
aarch64 bulk build report
bulk build on arm64.ports.openbsd.org started on Tue Jul 31 03:03:08 MDT 2018 finished at Thu Aug 2 17:30:25 MDT 2018 lasted 03D07h27m done with kern.version=OpenBSD 6.3-current (GENERIC.MP) #86: Mon Jul 30 18:57:10 MDT 2018 built packages:8235 Jul 31:3169 Aug 1:1486 Aug 2:3579 build failures: 47 http://build-failures.rhaalovely.net//aarch64/2018-07-31/comms/hylafax,a4.log http://build-failures.rhaalovely.net//aarch64/2018-07-31/comms/lcdproc.log http://build-failures.rhaalovely.net//aarch64/2018-07-31/devel/avr/gdb.log http://build-failures.rhaalovely.net//aarch64/2018-07-31/devel/bullet.log http://build-failures.rhaalovely.net//aarch64/2018-07-31/devel/ode.log http://build-failures.rhaalovely.net//aarch64/2018-07-31/devel/tbb.log http://build-failures.rhaalovely.net//aarch64/2018-07-31/editors/xwpe.log http://build-failures.rhaalovely.net//aarch64/2018-07-31/emulators/dynamips.log http://build-failures.rhaalovely.net//aarch64/2018-07-31/emulators/higan.log http://build-failures.rhaalovely.net//aarch64/2018-07-31/emulators/vbam.log http://build-failures.rhaalovely.net//aarch64/2018-07-31/games/dungeon-crawl.log http://build-failures.rhaalovely.net//aarch64/2018-07-31/games/dxx-rebirth.log http://build-failures.rhaalovely.net//aarch64/2018-07-31/games/frozen-bubble,-main.log http://build-failures.rhaalovely.net//aarch64/2018-07-31/games/nethack/3.6,qt.log http://build-failures.rhaalovely.net//aarch64/2018-07-31/games/spacehulk.log http://build-failures.rhaalovely.net//aarch64/2018-07-31/games/vacuum.log http://build-failures.rhaalovely.net//aarch64/2018-07-31/graphics/freeimage.log http://build-failures.rhaalovely.net//aarch64/2018-07-31/graphics/shotwell.log http://build-failures.rhaalovely.net//aarch64/2018-07-31/inputmethods/uim.log http://build-failures.rhaalovely.net//aarch64/2018-07-31/japanese/mecab,-ipadic.log http://build-failures.rhaalovely.net//aarch64/2018-07-31/lang/flang/libpgmath.log http://build-failures.rhaalovely.net//aarch64/2018-07-31/lang/pfe.log http://build-failures.rhaalovely.net//aarch64/2018-07-31/mail/mozilla-thunderbird,-lightning.log http://build-failures.rhaalovely.net//aarch64/2018-07-31/meta/kde4,-admin.log http://build-failures.rhaalovely.net//aarch64/2018-07-31/misc/rocrail,-gui.log http://build-failures.rhaalovely.net//aarch64/2018-07-31/multimedia/mediainfo.log http://build-failures.rhaalovely.net//aarch64/2018-07-31/multimedia/xine-lib.log http://build-failures.rhaalovely.net//aarch64/2018-07-31/net/castget.log http://build-failures.rhaalovely.net//aarch64/2018-07-31/net/telepathy/folks.log http://build-failures.rhaalovely.net//aarch64/2018-07-31/net/utox.log http://build-failures.rhaalovely.net//aarch64/2018-07-31/productivity/aqbanking.log http://build-failures.rhaalovely.net//aarch64/2018-07-31/security/libnipper.log http://build-failures.rhaalovely.net//aarch64/2018-07-31/security/py-cryptography.log http://build-failures.rhaalovely.net//aarch64/2018-07-31/security/softhsm.log http://build-failures.rhaalovely.net//aarch64/2018-07-31/sysutils/dtb.log http://build-failures.rhaalovely.net//aarch64/2018-07-31/sysutils/exa.log http://build-failures.rhaalovely.net//aarch64/2018-07-31/sysutils/sleuthkit.log http://build-failures.rhaalovely.net//aarch64/2018-07-31/sysutils/u-boot,aarch64.log http://build-failures.rhaalovely.net//aarch64/2018-07-31/textproc/link-grammar,-main.log http://build-failures.rhaalovely.net//aarch64/2018-07-31/www/chromium.log http://build-failures.rhaalovely.net//aarch64/2018-07-31/www/iridium.log http://build-failures.rhaalovely.net//aarch64/2018-07-31/www/mozilla-firefox.log http://build-failures.rhaalovely.net//aarch64/2018-07-31/www/mozplugger.log http://build-failures.rhaalovely.net//aarch64/2018-07-31/x11/eterm.log http://build-failures.rhaalovely.net//aarch64/2018-07-31/x11/kde/base3,-en_US.log http://build-failures.rhaalovely.net//aarch64/2018-07-31/x11/nx/opennx.log http://build-failures.rhaalovely.net//aarch64/2018-07-31/x11/p5-Wx.log recurrent failures failures/comms/lcdproc.log failures/devel/avr/gdb.log failures/devel/bullet.log failures/devel/ode.log failures/devel/tbb.log failures/editors/xwpe.log failures/lang/flang/libpgmath.log failures/lang/pfe.log failures/mail/mozilla-thunderbird,-lightning.log failures/misc/rocrail,-gui.log failures/multimedia/mediainfo.log failures/multimedia/xine-lib.log failures/net/castget.log failures/net/telepathy/folks.log failures/net/utox.log failures/productivity/aqbanking.log failures/security/libnipper.log failures/security/softhsm.log failures/sysutils/exa.log failures/sysutils/sleuthkit.log failures/textproc/link-grammar,-main.log failures/www/chromium.log failures/www/iridium.log failures/www/mozilla-firefox.log failures/www/mozplugger.log failures/x11/kde/base3,-en_US.log failures/x11/nx/opennx.log failures/x11/p5-Wx.log new failures +++ ls-failures Thu Aug 2 17:33:06 2018 +failures/meta/kde4,-admin.log +failures/security/py-cryptography.log
Fix for vitetris desktop file
The desktop file that ships with vitetris (/usr/local/share/applications/vitetris.desktop) has the line `Exec=tetris -w 80`. Not only is tetris the wrong binary, but it doesn't work anyway since /usr/games/tetris doesn't have the -w option. The solution is to use `Exec=vitetris -w 80`, which I have attempted to create a patch for. Many thanks, Micah Index: patches/patch-vitetris_desktop === RCS file: patches/patch-vitetris_desktop diff -N patches/patch-vitetris_desktop --- /dev/null 1 Jan 1970 00:00:00 - +++ patches/patch-vitetris_desktop 25 July 2018 17:07:38 - @@ -0,0 +1,14 @@ +$OpenBSD$ + +Index: vitetris.desktop +--- vitetris.desktop.orig vitetris.desktop +@@ -3,7 +3,7 @@ Type=Application + Encoding=UTF-8 + Name=vitetris + GenericName=Text-mode Tetris +-Exec=tetris -w 80 ++Exec=vitetris -w 80 + Icon=vitetris + Categories=Game;BlocksGame; + Terminal=true
Re: NEW: devel/cmark
On 2018/08/02 20:34, Jan Klemkow wrote: > Hi Rafael, > > On Thu, Aug 02, 2018 at 06:31:53PM +0200, Rafael Sadowski wrote: > > On Thu Aug 02, 2018 at 05:36:13PM +0200, Jan Klemkow wrote: > > > Hi Rafael, > > > > > > I also worked on an cmark port. I took your tar ball and fixed all > > > comments Stuart pointed out. Just, the MAINTAINER field is still unset, > > > But, a portscheck run does not require this field. > > > > > > I replaced the manual DISTFILE and MASTER_SITE handling by the GH_* > > > variables, moved it to category "textproc" and correct some spacing. > > > > That wasn't the way to go and the spacing was fine -- trust me or use > > vim. Please see my traball. > > You are right, I missed some spaces. But, I already used vim ;-) > > > > > > > Hopefully that helps you. I also need this tool for a private project > > > of mine. > > > > Would you like to take MAINTAINER? > > Yes, I can do that. See my attached tar ball. I removed a useless line > and replaced some spaces by tabs. And it uses the GH_* variables. > > Hope that's fine for all so far. > > Thanks, > Jan DISTNAME isn't needed here, the one generated from GH_PROJECT and GH_TAGNAME is good anyway. OK sthen@
Re: [PATCH] sysutils/screenfetch
Hi Charlène --
On 08/01/18 16:06, Charlène wrote:
Hi,
I'm joining a new diff after Brian's comments.
On Wed, 1 Aug 2018 02:17:37 -0400
Brian Callahan wrote:
Hi Charlène --
On 07/30/18 14:22, Charlène wrote:
Hi,
I'm proposing several changes to this port:
Makefile:
* cleaned extra tabs after '='
* use INSTALL_MAN instead of INSTALL_SCRIPT for the manpage
* added myself as MAINTAINER, currently it's "orphaned"
* incremented REVISION
* added braces for variables
Some of these I'm OK with, some I'm not super sure about.
Yes, I think it's worthwhile to use INSTALL_MAN.
Glad to see you taking MAINTAINER.
Glad to see the updated patches.
Braces around variables are not strictly needed in this case; it
becomes a matter of style in this particular instance. But it might
be even better to change PKGNAME to ${DISTNAME:L} and change
GH_TAGNAME to v3.8.0 -- that would completely eliminate the need for
a V variable in the first place.
I changed to what you recommend. You made me finally understand
that bsd.port.mk is a great source of documentation by itself,
thanks!
Since it looks like we're going this route, Makefile.template says
CATEGORIES comes after PKGNAME.
So the first block should be:
COMMENT
PKGNAME
REVISION
Makefile.template also says that CATEGORIES comes after the GH_*
variables, though I see plenty of ports that put CATEGORIES directly
under DISTNAME/PKGNAME, as it would be if there were no GH_* variables.
According to your diff, CATEGORIES was placed according to
Makefile.template and be kept there.
~Brian
I'm more inclined to leave extra tabs in once a port has been
imported, unless you're otherwise changing the line anyway, which
you're not here. Especially in this case, where things are aligned
anyway, I'm not sure removing the extra tabs improves readability.
But I guess if you're going to do this, now would be the time.
I was advised to do so for sysutils/neofetch, so i applied the same
thing for this port. I entirely agree about the fact that it doesn't
improve (or worsen) readability here. I've let it as-is for this time,
but i take note for future works.
Charlène.
~Brian
patches, already in upstream's master branch but not in a release:
* fixed "awk: cannot open /proc/fb" [1]
* fixed "unary operator expected" when no GPU is detected
[2]
Testing:
It has been successfully tested using proot, but you'll need to
copy /var/run/dmesg.boot in your chroot to check the output of the
program, as it uses this file for OS detection.
Comments and OK are welcome!
Charlène.
[1]
https://github.com/KittyKatt/screenFetch/commit/dc72b5932e86ba9c4e36110408690abeb2004070
[2]
https://github.com/KittyKatt/screenFetch/commit/8346a75068323692243805fa702d02ec7538f3b9
www/chromium build time
With the update from Chromium 67 to 68, the build time of www/chromium has exploded and it now determines the overall duration of an amd64 bulk build. In my latest bulk build, www/chromium took almost 27 hours to build. >From the start of the bulk build, it took over 5 hours before www/chromium could be scheduled, due to the dependency chain www/gtk+3 < x11/gnome/librsvg < lang/rust < devel/llvm. The total bulk build time was 32 hours. Everything other than chromium had finished after 21 hours from the start of the build. These numbers may vary somewhat depending on which jobs get scheduled on a faster or slower machine, but the overall picture shouldn't change. I'll try a build with dpb -p instead of the default of -p. This is crazy. -- Christian "naddy" Weisgerber na...@mips.inka.de
Re: [NEW] gzdoom-3.5.0
timo.my...@bittivirhe.fi (Timo Myyrä) wrote: > Hi, > > Here's a updated port for latest gzdoom version. > Merged the stuff from Solene's port into my old gzdoom port and bumped it to > latest version. Tested on amd64 and quick gameplay test seems to work and > installing soundfont and tuning the ini file, the fluidsynth playback works. > > - added patch to fix the fluidsynth library name > > - dropped old linker args from Makefile, these don't seem to be needed at all > > - Added flag to disable GTK dialogs from building so no need for Gtk > dependency > > - fluidsynth is detected at build time so add it as build_depends. At run time > it needs to be installed but gzdoom can use other midi players as well so I > didn't add it to run_depends. > > - Dropped previous gxmessage dependy, the game tries kdialog, gxmessage and > finally xmessage to show crash log. > > - OpenAL needs to be installed to have audio. > > > Timo Your port is way better than the one I submitted last month, good work! Still when using mods, I only have music and no other sound, do you have the same issue? Doom1 and Doom2 runs fine, so it may be related to the mods...
Re: NEW: devel/cmark
Hi Rafael, On Thu, Aug 02, 2018 at 06:31:53PM +0200, Rafael Sadowski wrote: > On Thu Aug 02, 2018 at 05:36:13PM +0200, Jan Klemkow wrote: > > Hi Rafael, > > > > I also worked on an cmark port. I took your tar ball and fixed all > > comments Stuart pointed out. Just, the MAINTAINER field is still unset, > > But, a portscheck run does not require this field. > > > > I replaced the manual DISTFILE and MASTER_SITE handling by the GH_* > > variables, moved it to category "textproc" and correct some spacing. > > That wasn't the way to go and the spacing was fine -- trust me or use > vim. Please see my traball. You are right, I missed some spaces. But, I already used vim ;-) > > > > Hopefully that helps you. I also need this tool for a private project > > of mine. > > Would you like to take MAINTAINER? Yes, I can do that. See my attached tar ball. I removed a useless line and replaced some spaces by tabs. And it uses the GH_* variables. Hope that's fine for all so far. Thanks, Jan cmark.tar.gz Description: Binary data
Re: UPDATE: devel/py-test suite update [was: Updating several ports]
I manually tested all the pytest consumers and if there is more to check that I dont see, I can report back more testing. The thing is that as times goes by, the tests already made become insubstantial because for example I tested all for pytest 3.6.3, now we are in pytest 3.6.4. I commit to have the pytest suite up to date and check the changelogs to warn and foresee any possible problems. Thanks for the comment and the explanation about why this is not been committed. I'll wait then. Elias. 2018-08-02 13:41 GMT-03:00 Stuart Henderson : > On 2018/08/02 11:11, Elias M. Mariani wrote: >> Stuart, Remi, >> Could you help me with this ? >> I dont want the updates to get any bigger as times goes by and the >> changes were extensively tested. > > This is a wanted update but between py2 and py3 dep's there are 200+ > fullpkgpaths involved, so it is likely to take a while for a developer to > have time to fit in enough testing to gain confidence to commit it. > > >> Cheers. >> Elias. >> >> >> 2018-07-30 20:20 GMT-03:00 Elias M. Mariani : >> > Updating the update. >> > All the following changes were tested again, this time against >> > databases/py-sqlalchemy,python3 >> > 1 failed, 7809 passed, 888 skipped >> > >> > The same result as the current, version, the previous update and the >> > current update. >> > (The test uses py-test-xdist, and is very complete) >> > >> > added also >> > devel/py-pluggy >> > Update from 0.6.0 to 0.7.1 >> > https://github.com/pytest-dev/pluggy/blob/master/CHANGELOG.rst >> > Not a single function removed, only deprecated. (the only real >> > consumer is devel/py-test). >> > >> > 2018-07-26 15:13 GMT-03:00 Elias M. Mariani : >> >> Moving the thread just to change the title to something more descriptive. >> >> >> >> Hi, >> >> I have the following list of ports, all share interdependencies >> >> between them, thats why I think that the best would be to commit the >> >> hole thing together. >> >> I'm talking about py-test. >> >> I have the diff ready to update: >> >> devel/py-hypothesis >> > Further update from 3.66.1 to 3.66.14 >> > https://hypothesis.readthedocs.io/en/master/changes.html >> > Mostly performance upgrades and bugfixes. >> > >> >> devel/py-py >> >> devel/py-test >> > Further update from 3.6.3 to 3.6.4 >> > https://github.com/pytest-dev/pytest/blob/master/CHANGELOG.rst >> > No potential problem with the changes. >> > >> >> devel/py-test-httpbin >> >> devel/py-test-localserver >> >> devel/py-test-mock >> >> devel/py-test-runner >> >> devel/py-test-xdist >> > Further update from 1.22.2 to 1.22.5 >> > https://github.com/pytest-dev/pytest-xdist/blob/master/CHANGELOG.rst >> > No potential problem with the changes. >> > >> >> >> >> And a tarball with: >> >> devel/py-test-forked (new dependency of devel/py-test-xdist). >> >> >> >> To check for the possibility of this updates affecting other ports I >> >> checked every port using the current versions vs the updated versions, >> >> the results are attached. >> >> The format is: >> >> FULLPKGPATH >> >> Result using current version >> >> Result using new version (if differences exist, none if equals) >> >> >> >> The only ones giving a different result are: >> >> www/py-httpie >> >> 4 failed, 223 passed, 4 skipped, 13 warnings >> >> Error: fixture is being applied more than once to the same function >> >> >> >> devel/py-doit >> >> 2 failed, 731 passed, 21 skipped >> >> Error: fixture is being applied more than once to the same function >> >> >> >> According to the pytest changelog: >> >> "Now when @pytest.fixture is applied more than once to the same >> >> function a ValueError is raised. This buggy behavior would cause >> >> surprising problems and if was working for a test suite it was mostly >> >> by accident." >> >> https://docs.pytest.org/en/latest/changelog.html#pytest-3-6-0-2018-05-23 >> >> >> >> So I think that with this we can rest assure that the updates work fine. >> >> With that I propose to update the versions with the unified diff that >> >> I attached as well, and the new dependency on py-test-xdist: >> >> py-test-forked (also attached...). >> >> Doing the change at once seems to me reasonable given the >> >> interdependency and also the way in witch I made the tests. >> >> >> >> Cheers. >> >> Elias. >>
Re: NEW: devel/cmark
Hi Rafael,
I also worked on an cmark port. I took your tar ball and fixed all
comments Stuart pointed out. Just, the MAINTAINER field is still unset,
But, a portscheck run does not require this field.
I replaced the manual DISTFILE and MASTER_SITE handling by the GH_*
variables, moved it to category "textproc" and correct some spacing.
Hopefully that helps you. I also need this tool for a private project
of mine.
bye,
Jan
On Thu, Aug 02, 2018 at 10:41:30AM +0100, Stuart Henderson wrote:
> On 2018/08/02 11:03, Rafael Sadowski wrote:
> > please find attached a small dependency for the upcoming
> > multimedia/mkvtoolnix update. All tests are passed on amd64.
> >
> > pkg_info:
> > Information for inst:cmark-0.28.3
> >
> > Comment:
> > CommonMark parsing and rendering library and program in C
> >
> > Required by:
> > mkvtoolnix-25.0.0-no_x11
> >
> > Description:
> > cmark is the C reference implementation of CommonMark, a rationalized
> > version
> > of Markdown syntax with a spec.
> >
> > Maintainer: The OpenBSD ports mailing-list
> >
> > WWW: https://commonmark.org/
> >
> > Ok? Comments?
>
> textproc or converters would seem better than devel?
Fixed.
> $ cat distinfo
> SHA256 (0.28.3.tar.gz) = rMmGhdPBtRX/eHrHyZQYja2vKKLXAMEMEiHaQZm64fw=
> SIZE (0.28.3.tar.gz) = 229391
>
> Please rename that to something sensible via the DISTFILES=...{...} mechanism.
This is also fixed.
cmark.tar.gz
Description: Binary data
Re: UPDATE: devel/py-test suite update [was: Updating several ports]
On 2018/08/02 11:11, Elias M. Mariani wrote: > Stuart, Remi, > Could you help me with this ? > I dont want the updates to get any bigger as times goes by and the > changes were extensively tested. This is a wanted update but between py2 and py3 dep's there are 200+ fullpkgpaths involved, so it is likely to take a while for a developer to have time to fit in enough testing to gain confidence to commit it. > Cheers. > Elias. > > > 2018-07-30 20:20 GMT-03:00 Elias M. Mariani : > > Updating the update. > > All the following changes were tested again, this time against > > databases/py-sqlalchemy,python3 > > 1 failed, 7809 passed, 888 skipped > > > > The same result as the current, version, the previous update and the > > current update. > > (The test uses py-test-xdist, and is very complete) > > > > added also > > devel/py-pluggy > > Update from 0.6.0 to 0.7.1 > > https://github.com/pytest-dev/pluggy/blob/master/CHANGELOG.rst > > Not a single function removed, only deprecated. (the only real > > consumer is devel/py-test). > > > > 2018-07-26 15:13 GMT-03:00 Elias M. Mariani : > >> Moving the thread just to change the title to something more descriptive. > >> > >> Hi, > >> I have the following list of ports, all share interdependencies > >> between them, thats why I think that the best would be to commit the > >> hole thing together. > >> I'm talking about py-test. > >> I have the diff ready to update: > >> devel/py-hypothesis > > Further update from 3.66.1 to 3.66.14 > > https://hypothesis.readthedocs.io/en/master/changes.html > > Mostly performance upgrades and bugfixes. > > > >> devel/py-py > >> devel/py-test > > Further update from 3.6.3 to 3.6.4 > > https://github.com/pytest-dev/pytest/blob/master/CHANGELOG.rst > > No potential problem with the changes. > > > >> devel/py-test-httpbin > >> devel/py-test-localserver > >> devel/py-test-mock > >> devel/py-test-runner > >> devel/py-test-xdist > > Further update from 1.22.2 to 1.22.5 > > https://github.com/pytest-dev/pytest-xdist/blob/master/CHANGELOG.rst > > No potential problem with the changes. > > > >> > >> And a tarball with: > >> devel/py-test-forked (new dependency of devel/py-test-xdist). > >> > >> To check for the possibility of this updates affecting other ports I > >> checked every port using the current versions vs the updated versions, > >> the results are attached. > >> The format is: > >> FULLPKGPATH > >> Result using current version > >> Result using new version (if differences exist, none if equals) > >> > >> The only ones giving a different result are: > >> www/py-httpie > >> 4 failed, 223 passed, 4 skipped, 13 warnings > >> Error: fixture is being applied more than once to the same function > >> > >> devel/py-doit > >> 2 failed, 731 passed, 21 skipped > >> Error: fixture is being applied more than once to the same function > >> > >> According to the pytest changelog: > >> "Now when @pytest.fixture is applied more than once to the same > >> function a ValueError is raised. This buggy behavior would cause > >> surprising problems and if was working for a test suite it was mostly > >> by accident." > >> https://docs.pytest.org/en/latest/changelog.html#pytest-3-6-0-2018-05-23 > >> > >> So I think that with this we can rest assure that the updates work fine. > >> With that I propose to update the versions with the unified diff that > >> I attached as well, and the new dependency on py-test-xdist: > >> py-test-forked (also attached...). > >> Doing the change at once seems to me reasonable given the > >> interdependency and also the way in witch I made the tests. > >> > >> Cheers. > >> Elias. >
[NEW] gzdoom-3.5.0
Hi, Here's a updated port for latest gzdoom version. Merged the stuff from Solene's port into my old gzdoom port and bumped it to latest version. Tested on amd64 and quick gameplay test seems to work and installing soundfont and tuning the ini file, the fluidsynth playback works. - added patch to fix the fluidsynth library name - dropped old linker args from Makefile, these don't seem to be needed at all - Added flag to disable GTK dialogs from building so no need for Gtk dependency - fluidsynth is detected at build time so add it as build_depends. At run time it needs to be installed but gzdoom can use other midi players as well so I didn't add it to run_depends. - Dropped previous gxmessage dependy, the game tries kdialog, gxmessage and finally xmessage to show crash log. - OpenAL needs to be installed to have audio. Timo gzdoom.tar.gz Description: Binary data
Re: NEW: devel/cmark
On 2018/08/02 18:31, Rafael Sadowski wrote: > On Thu Aug 02, 2018 at 05:36:13PM +0200, Jan Klemkow wrote: > > Hi Rafael, > > > > I also worked on an cmark port. I took your tar ball and fixed all > > comments Stuart pointed out. Just, the MAINTAINER field is still unset, > > But, a portscheck run does not require this field. > > > > I replaced the manual DISTFILE and MASTER_SITE handling by the GH_* > > variables, moved it to category "textproc" and correct some spacing. > > That wasn't the way to go and the spacing was fine -- trust me or use > vim. Please see my traball. Oh I missed the /archive/ URL, I thought it was in /releases/ (assumed you would have just used GH_* if it was /archive/). GH_* _is_ the way to go for /archive/.
Re: [NEW] textproc/miller
On Thu, Aug 02, 2018 at 01:17:26PM +0200, Solene Rapenne wrote: > Stuart Henderson wrote: > > > > DESCR doesn't do a great job of selling it - it seems something akin to jq > > but handles more input formats, but that DESCR doesn't really show it. How > > about a bit more borrowed from http://johnkerl.org/miller/doc/? > > > > > > Miller (mlr) is like awk, sed, cut, join, and sort for name-indexed data > > such as CSV, TSV, and tabular JSON. You get to work with your data using > > named fields, without needing to count positional column indices. It is > > pipe-friendly and interoperates with the Unix toolkit. > > > > It operates on key-value-pair data while the familiar Unix tools operate > > on integer-indexed fields. This encompasses a variety of data formats, > > including but not limited to the familiar CSV, TSV, and JSON. (Miller > > can handle positionally-indexed data as a special case.) > > > > > > OK either way. > > I agree that this DESCR is more explanative about the software than the > current one. I also agree, and I imported miller with the DESCR suggested by sthen@. Thanks to both of you for testing.
Re: NEW: devel/cmark
On Thu Aug 02, 2018 at 05:36:13PM +0200, Jan Klemkow wrote:
> Hi Rafael,
>
> I also worked on an cmark port. I took your tar ball and fixed all
> comments Stuart pointed out. Just, the MAINTAINER field is still unset,
> But, a portscheck run does not require this field.
>
> I replaced the manual DISTFILE and MASTER_SITE handling by the GH_*
> variables, moved it to category "textproc" and correct some spacing.
That wasn't the way to go and the spacing was fine -- trust me or use
vim. Please see my traball.
>
> Hopefully that helps you. I also need this tool for a private project
> of mine.
Would you like to take MAINTAINER?
>
> bye,
> Jan
>
> On Thu, Aug 02, 2018 at 10:41:30AM +0100, Stuart Henderson wrote:
> > On 2018/08/02 11:03, Rafael Sadowski wrote:
> > > please find attached a small dependency for the upcoming
> > > multimedia/mkvtoolnix update. All tests are passed on amd64.
> > >
> > > pkg_info:
> > > Information for inst:cmark-0.28.3
> > >
> > > Comment:
> > > CommonMark parsing and rendering library and program in C
> > >
> > > Required by:
> > > mkvtoolnix-25.0.0-no_x11
> > >
> > > Description:
> > > cmark is the C reference implementation of CommonMark, a rationalized
> > > version
> > > of Markdown syntax with a spec.
> > >
> > > Maintainer: The OpenBSD ports mailing-list
> > >
> > > WWW: https://commonmark.org/
> > >
> > > Ok? Comments?
> >
> > textproc or converters would seem better than devel?
>
> Fixed.
Yes, I'm fine with textproc makes more sense then devel.
>
> > $ cat distinfo
> > SHA256 (0.28.3.tar.gz) = rMmGhdPBtRX/eHrHyZQYja2vKKLXAMEMEiHaQZm64fw=
> > SIZE (0.28.3.tar.gz) = 229391
> >
> > Please rename that to something sensible via the DISTFILES=...{...}
> > mechanism.
>
> This is also fixed.
All comments packed in the new tarball.
cmark-0.28.3p0.tar.gz
Description: Binary data
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: fcam...@cvs.openbsd.org 2018/08/02 10:30:40 Modified files: textproc : Makefile Log message: Add miller.
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: fcam...@cvs.openbsd.org 2018/08/02 10:29:48 Log message: Import textproc/miller. Miller (mlr) is like awk, sed, cut, join, and sort for name-indexed data such as CSV, TSV, and tabular JSON. You get to work with your data using named fields, without needing to count positional column indices. It is pipe-friendly and interoperates with the Unix toolkit. It operates on key-value-pair data while the familiar Unix tools operate on integer-indexed fields. This encompasses a variety of data formats, including but not limited to the familiar CSV, TSV, and JSON. (Miller can handle positionally-indexed data as a special case.) OK sthen@, solene@ Status: Vendor Tag: fcambus Release Tags: fcambus_20180802 N ports/textproc/miller/Makefile N ports/textproc/miller/distinfo N ports/textproc/miller/pkg/PLIST N ports/textproc/miller/pkg/DESCR No conflicts created by this import
Re: UPDATE: devel/py-test suite update [was: Updating several ports]
Stuart, Remi, Could you help me with this ? I dont want the updates to get any bigger as times goes by and the changes were extensively tested. Cheers. Elias. 2018-07-30 20:20 GMT-03:00 Elias M. Mariani : > Updating the update. > All the following changes were tested again, this time against > databases/py-sqlalchemy,python3 > 1 failed, 7809 passed, 888 skipped > > The same result as the current, version, the previous update and the > current update. > (The test uses py-test-xdist, and is very complete) > > added also > devel/py-pluggy > Update from 0.6.0 to 0.7.1 > https://github.com/pytest-dev/pluggy/blob/master/CHANGELOG.rst > Not a single function removed, only deprecated. (the only real > consumer is devel/py-test). > > 2018-07-26 15:13 GMT-03:00 Elias M. Mariani : >> Moving the thread just to change the title to something more descriptive. >> >> Hi, >> I have the following list of ports, all share interdependencies >> between them, thats why I think that the best would be to commit the >> hole thing together. >> I'm talking about py-test. >> I have the diff ready to update: >> devel/py-hypothesis > Further update from 3.66.1 to 3.66.14 > https://hypothesis.readthedocs.io/en/master/changes.html > Mostly performance upgrades and bugfixes. > >> devel/py-py >> devel/py-test > Further update from 3.6.3 to 3.6.4 > https://github.com/pytest-dev/pytest/blob/master/CHANGELOG.rst > No potential problem with the changes. > >> devel/py-test-httpbin >> devel/py-test-localserver >> devel/py-test-mock >> devel/py-test-runner >> devel/py-test-xdist > Further update from 1.22.2 to 1.22.5 > https://github.com/pytest-dev/pytest-xdist/blob/master/CHANGELOG.rst > No potential problem with the changes. > >> >> And a tarball with: >> devel/py-test-forked (new dependency of devel/py-test-xdist). >> >> To check for the possibility of this updates affecting other ports I >> checked every port using the current versions vs the updated versions, >> the results are attached. >> The format is: >> FULLPKGPATH >> Result using current version >> Result using new version (if differences exist, none if equals) >> >> The only ones giving a different result are: >> www/py-httpie >> 4 failed, 223 passed, 4 skipped, 13 warnings >> Error: fixture is being applied more than once to the same function >> >> devel/py-doit >> 2 failed, 731 passed, 21 skipped >> Error: fixture is being applied more than once to the same function >> >> According to the pytest changelog: >> "Now when @pytest.fixture is applied more than once to the same >> function a ValueError is raised. This buggy behavior would cause >> surprising problems and if was working for a test suite it was mostly >> by accident." >> https://docs.pytest.org/en/latest/changelog.html#pytest-3-6-0-2018-05-23 >> >> So I think that with this we can rest assure that the updates work fine. >> With that I propose to update the versions with the unified diff that >> I attached as well, and the new dependency on py-test-xdist: >> py-test-forked (also attached...). >> Doing the change at once seems to me reasonable given the >> interdependency and also the way in witch I made the tests. >> >> Cheers. >> Elias.
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: juan...@cvs.openbsd.org 2018/08/02 07:43:05 Modified files: sysutils/borgbackup: Makefile Log message: Remove Os from the source. OK bket@ (MAINTAINER).
Re: [update] samba-4.8.3
On Wed, Aug 01 2018, Ian McWilliam wrote: > I do see this weirdness in logs. > > > Aug 2 09:47:31 ianm-openbsd nmbd[23825]: daemon_ready: STATUS=daemon > 'nmbd' finished starting up and ready to serve connections > > Aug 2 09:47:36 ianm-openbsd smbd: vfprintf %s NULL in "Auth: [%s,%s] user > [%s]\\[%s] at [%s] with [%s] status [%s] workstation [%s] remote host [%s]%s > local host [%s] %s " The behavior is the same on Linux, except that the glibc doesn't add a warning to syslog in this case. So that's low priority as far as I'm concerned. > Aug 2 09:47:49 ianm-openbsd smbd: vfprintf %s NULL in "sys_get_%s_quota() > failed for mntpath[%s] bdev[%s] qtype[%d] id[%d]: %s " I'll have a look. > Other than that and not having time to look at the virus-filter stuff. My use > case is running fine. ack, thanks to both of you. I have committed this update. -- jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF DDCC 0DFA 74AE 1524 E7EE
update devel/protobuf to 3.6.1
This is a very small update addressing the following: C++ Introduced workaround for Windows issue with std::atomic and std::once_flag initialization (#4777, #4773) PHP Added compatibility with PHP 7.3 (#4898) RubyFixed Ruby crash involving Any encoding (#4718) Of these only the Ruby thing seems to be of direct relevance to us. I build tested all consumers on amd64 and ran the test suites of the libraries with no visible change to before the update. For the record, audio/clementine and x11/kde4/marble error on running 'make test'. Index: Makefile === RCS file: /var/cvs/ports/devel/protobuf/Makefile,v retrieving revision 1.20 diff -u -p -r1.20 Makefile --- Makefile10 Jul 2018 10:47:42 - 1.20 +++ Makefile2 Aug 2018 06:56:24 - @@ -2,7 +2,7 @@ COMMENT = c++ protocol buffers -V =3.6.0 +V =3.6.1 DISTNAME = protobuf-cpp-$V PKGNAME = protobuf-$V Index: distinfo === RCS file: /var/cvs/ports/devel/protobuf/distinfo,v retrieving revision 1.4 diff -u -p -r1.4 distinfo --- distinfo10 Jul 2018 10:47:42 - 1.4 +++ distinfo2 Aug 2018 06:57:03 - @@ -1,2 +1,2 @@ -SHA256 (protobuf-cpp-3.6.0.tar.gz) = w8qwVZZNVU5P2FBn/j6etFyZFc689Tfpf6+qJFN2vOE= -SIZE (protobuf-cpp-3.6.0.tar.gz) = 4454101 +SHA256 (protobuf-cpp-3.6.1.tar.gz) = s3MuRxqbt5UPCQ/QRX69JTapugiRt/N4WRnGVP4qJSk= +SIZE (protobuf-cpp-3.6.1.tar.gz) = 4450975
Re: remove sysutils/snapdl
On Thu, Aug 02 2018, Stuart Henderson wrote: > On 2018/08/02 13:02, Solene Rapenne wrote: >> Hello >> >> It turns out that sysutils/snapdl isn't maintained anymore. The maintainer is >> not reachable, his mail domain is abandoned, the MASTER_SITES doesn't provide >> the tarballs. >> >> snapdl is a tool to retrieve the last snapshots of OpenBSD, but it only gives >> http or ftp protocol choice and doesn't use signify. > > yes, that's not useful unless it's maintained. OK with me to remove, > for quirks I think "no longer maintained upstream", #3 in $obsolete_reason > would make sense. Seconded, ok jca@ -- jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF DDCC 0DFA 74AE 1524 E7EE
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: j...@cvs.openbsd.org2018/08/02 05:39:33 Modified files: net/samba : Makefile distinfo net/samba/pkg : PLIST-main Log message: Update to samba-4.8.3 Tested by Ian McWilliam and Vijay Sankar.
Re: remove sysutils/snapdl
On 2018/08/02 13:02, Solene Rapenne wrote: > Hello > > It turns out that sysutils/snapdl isn't maintained anymore. The maintainer is > not reachable, his mail domain is abandoned, the MASTER_SITES doesn't provide > the tarballs. > > snapdl is a tool to retrieve the last snapshots of OpenBSD, but it only gives > http or ftp protocol choice and doesn't use signify. yes, that's not useful unless it's maintained. OK with me to remove, for quirks I think "no longer maintained upstream", #3 in $obsolete_reason would make sense.
Re: [NEW] textproc/miller
Stuart Henderson wrote: > On 2018/08/02 12:26, Frederic Cambus wrote: > > On Wed, Jul 25, 2018 at 08:30:59PM +0200, Frederic Cambus wrote: > > > > > Here is a new port: textproc/miller. > > > > > > From DESCR: > > > > > > Miller operates on key-value-pair data while the familiar Unix tools > > > operate > > > on integer-indexed fields: if the natural data structure for the latter > > > is the > > > array, then Miller's natural data structure is the insertion-ordered hash > > > map. > > > This encompasses a variety of data formats, including but not limited to > > > the > > > familiar CSV, TSV, and JSON. Miller can handle positionally-indexed data > > > as > > > a special case. > > > > > > Comments? OK? > > > > Ping. Anyone willing to look at this? > > > > DESCR doesn't do a great job of selling it - it seems something akin to jq > but handles more input formats, but that DESCR doesn't really show it. How > about a bit more borrowed from http://johnkerl.org/miller/doc/? > > > Miller (mlr) is like awk, sed, cut, join, and sort for name-indexed data > such as CSV, TSV, and tabular JSON. You get to work with your data using > named fields, without needing to count positional column indices. It is > pipe-friendly and interoperates with the Unix toolkit. > > It operates on key-value-pair data while the familiar Unix tools operate > on integer-indexed fields. This encompasses a variety of data formats, > including but not limited to the familiar CSV, TSV, and JSON. (Miller > can handle positionally-indexed data as a special case.) > > > OK either way. I agree that this DESCR is more explanative about the software than the current one.
Re: [NEW] textproc/miller
Frederic Cambus wrote: > On Wed, Jul 25, 2018 at 08:30:59PM +0200, Frederic Cambus wrote: > > > Here is a new port: textproc/miller. > > > > From DESCR: > > > > Miller operates on key-value-pair data while the familiar Unix tools operate > > on integer-indexed fields: if the natural data structure for the latter is > > the > > array, then Miller's natural data structure is the insertion-ordered hash > > map. > > This encompasses a variety of data formats, including but not limited to the > > familiar CSV, TSV, and JSON. Miller can handle positionally-indexed data as > > a special case. > > > > Comments? OK? > > Ping. Anyone willing to look at this? I overlooked it last week. The port compiles fine and miller is awesome! The port seems right to me. ok solene@
Re: [NEW] textproc/miller
On 2018/08/02 12:26, Frederic Cambus wrote: > On Wed, Jul 25, 2018 at 08:30:59PM +0200, Frederic Cambus wrote: > > > Here is a new port: textproc/miller. > > > > From DESCR: > > > > Miller operates on key-value-pair data while the familiar Unix tools operate > > on integer-indexed fields: if the natural data structure for the latter is > > the > > array, then Miller's natural data structure is the insertion-ordered hash > > map. > > This encompasses a variety of data formats, including but not limited to the > > familiar CSV, TSV, and JSON. Miller can handle positionally-indexed data as > > a special case. > > > > Comments? OK? > > Ping. Anyone willing to look at this? > DESCR doesn't do a great job of selling it - it seems something akin to jq but handles more input formats, but that DESCR doesn't really show it. How about a bit more borrowed from http://johnkerl.org/miller/doc/? Miller (mlr) is like awk, sed, cut, join, and sort for name-indexed data such as CSV, TSV, and tabular JSON. You get to work with your data using named fields, without needing to count positional column indices. It is pipe-friendly and interoperates with the Unix toolkit. It operates on key-value-pair data while the familiar Unix tools operate on integer-indexed fields. This encompasses a variety of data formats, including but not limited to the familiar CSV, TSV, and JSON. (Miller can handle positionally-indexed data as a special case.) OK either way.
remove sysutils/snapdl
Hello It turns out that sysutils/snapdl isn't maintained anymore. The maintainer is not reachable, his mail domain is abandoned, the MASTER_SITES doesn't provide the tarballs. snapdl is a tool to retrieve the last snapshots of OpenBSD, but it only gives http or ftp protocol choice and doesn't use signify. This can be easily replaced by 2 lines using rsync. rsync -av --exclude=*fs --exclude=*iso \ rsync://mirrors.ircam.fr/pub/OpenBSD/snapshots/amd64/ dest cd dest && signify -C -p /etc/signify/openbsd-63-base.pub -x SHA256.sig *
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: na...@cvs.openbsd.org 2018/08/02 04:43:01 Modified files: archivers/unrar: Makefile distinfo archivers/unrar/patches: patch-makefile patch-os_hpp Log message: update to 5.60
Re: [NEW] textproc/miller
On Wed, Jul 25, 2018 at 08:30:59PM +0200, Frederic Cambus wrote: > Here is a new port: textproc/miller. > > From DESCR: > > Miller operates on key-value-pair data while the familiar Unix tools operate > on integer-indexed fields: if the natural data structure for the latter is the > array, then Miller's natural data structure is the insertion-ordered hash map. > This encompasses a variety of data formats, including but not limited to the > familiar CSV, TSV, and JSON. Miller can handle positionally-indexed data as > a special case. > > Comments? OK? Ping. Anyone willing to look at this?
Re: Qt5Webkit -> USE_WXNEEDED
On Thu, Aug 2, 2018 at 11:38 AM, Stuart Henderson wrote: > On 2018/08/02 07:17, Rafael Sadowski wrote: >> If no concerns I would like to commit the patch. > > I'm a bit confused about this because: > > 1. we have a patch described as "Enable W^X in QtWebkit's JIT" > in x11/qt5/qtwebkit/patches/patch-Source_JavaScriptCore_jsc_pro > > 2. these programs (at least the ones I tested, which isn't all of > them) already work - I see they are somehow getting the OPENBSD_WXNEEDED > section added despite not having USE_WXNEEDED > > Any idea what's going on? cmake "automagically" adds "-Wl,-z,wxneeded", see devel/cmake/patches/patch-Source_cmComputeLinkInformation_cxx Ciao! David
Re: [NEW] py-mini-amf-0.9.1
On 2018/07/27 12:14, Stuart Henderson wrote: > On 2018/07/27 13:56, Timo Myyrä wrote: > > Hi, > > > > Here's new port for python Mini-AMF library. Seems the py-amf isn't > > maintained > > anymore and this is the somewhat maintained library providing amf support. > > Mainly noticed as this is required for yle-dl update. > > > > Timo > > > > Tweaked to add py3 support and fixed TEST_DEPENDS. Any OKs to import? or > if someone else would like to import it's OK with me. > > Anyone? tgz reattached for convenience. py-mini-amf.tar.gz,2 Description: Binary data
Re: boost with ICU support
On 2018/08/02 07:08, Rafael Sadowski wrote: > Hi Kirill, > > I really really like it! My terms for an okay are simple: > > - Step #1: All consumers build fine. > - AMD64 and !AMD64 bulk More like clang and !clang, an i386 bulk isn't going to tell you much. But you'll be waiting a long time if you want a full bulk on one of those...
Re: NEW: devel/cmark
On 2018/08/02 11:03, Rafael Sadowski wrote:
> Hi All.
>
> please find attached a small dependency for the upcoming
> multimedia/mkvtoolnix update. All tests are passed on amd64.
>
> pkg_info:
> Information for inst:cmark-0.28.3
>
> Comment:
> CommonMark parsing and rendering library and program in C
>
> Required by:
> mkvtoolnix-25.0.0-no_x11
>
> Description:
> cmark is the C reference implementation of CommonMark, a rationalized version
> of Markdown syntax with a spec.
>
> Maintainer: The OpenBSD ports mailing-list
>
> WWW: https://commonmark.org/
>
>
> Ok? Comments?
textproc or converters would seem better than devel?
$ cat distinfo
SHA256 (0.28.3.tar.gz) = rMmGhdPBtRX/eHrHyZQYja2vKKLXAMEMEiHaQZm64fw=
SIZE (0.28.3.tar.gz) = 229391
Please rename that to something sensible via the DISTFILES=...{...} mechanism.
Re: Qt5Webkit -> USE_WXNEEDED
On 2018/08/02 07:17, Rafael Sadowski wrote:
> If no concerns I would like to commit the patch.
I'm a bit confused about this because:
1. we have a patch described as "Enable W^X in QtWebkit's JIT"
in x11/qt5/qtwebkit/patches/patch-Source_JavaScriptCore_jsc_pro
2. these programs (at least the ones I tested, which isn't all of
them) already work - I see they are somehow getting the OPENBSD_WXNEEDED
section added despite not having USE_WXNEEDED
Any idea what's going on?
> On Fri Jul 27, 2018 at 08:52:11PM +0200, Rafael Sadowski wrote:
> > Hi All,
> >
> > If we link against Qt5WebKit, we must also set USE_WXNEEDED.
> >
> > Ok? Comments?
> >
> > Rafael Sadowski
> >
> > Index: audio/mscore/Makefile
> > ===
> > RCS file: /cvs/ports/audio/mscore/Makefile,v
> > retrieving revision 1.35
> > diff -u -p -u -p -r1.35 Makefile
> > --- audio/mscore/Makefile 29 Jun 2018 22:16:09 - 1.35
> > +++ audio/mscore/Makefile 27 Jul 2018 18:47:02 -
> > @@ -1,5 +1,8 @@
> > # $OpenBSD: Makefile,v 1.35 2018/06/29 22:16:09 espie Exp $
> >
> > +# Qt5Webkit
> > +USE_WXNEEDED = Yes
> > +
> > BROKEN-hppa = ICE on moc_qtsingleapplication.cxx
> >
> > V =2.2.1
> > @@ -8,7 +11,7 @@ DISTNAME = MuseScore-${V}
> > PKGNAME = musescore-${V}
> > EXTRACT_SUFX = .zip
> > CATEGORIES = audio x11
> > -REVISION = 1
> > +REVISION = 2
> >
> > HOMEPAGE = http://musescore.org/
> > MAINTAINER = Brian Callahan
> > Index: devel/kf5/kdesignerplugin/Makefile
> > ===
> > RCS file: /cvs/ports/devel/kf5/kdesignerplugin/Makefile,v
> > retrieving revision 1.7
> > diff -u -p -u -p -r1.7 Makefile
> > --- devel/kf5/kdesignerplugin/Makefile 4 Jun 2018 20:25:32 -
> > 1.7
> > +++ devel/kf5/kdesignerplugin/Makefile 27 Jul 2018 18:47:08 -
> > @@ -1,7 +1,11 @@
> > # $OpenBSD: Makefile,v 1.7 2018/06/04 20:25:32 rsadowski Exp $
> >
> > +# Qt5Webkit
> > +USE_WXNEEDED = Yes
> > +
> > COMMENT = integrating KDE 5 widgets with Qt Designer
> > DISTNAME = kdesignerplugin-${VERSION}
> > +REVISION = 0
> >
> > WANTLIB += ${COMPILER_LIBCXX} KF5Auth KF5Bookmarks KF5Codecs KF5Completion
> > WANTLIB += KF5ConfigCore KF5ConfigGui KF5ConfigWidgets KF5CoreAddons
> > Index: devel/kf5/kdewebkit/Makefile
> > ===
> > RCS file: /cvs/ports/devel/kf5/kdewebkit/Makefile,v
> > retrieving revision 1.9
> > diff -u -p -u -p -r1.9 Makefile
> > --- devel/kf5/kdewebkit/Makefile4 Jun 2018 20:25:32 - 1.9
> > +++ devel/kf5/kdewebkit/Makefile27 Jul 2018 18:47:08 -
> > @@ -1,7 +1,11 @@
> > # $OpenBSD: Makefile,v 1.9 2018/06/04 20:25:32 rsadowski Exp $
> >
> > +# Qt5Webkit
> > +USE_WXNEEDED = Yes
> > +
> > COMMENT = integration of the HTML rendering engine WebKit into KDE
> > DISTNAME = kdewebkit-${VERSION}
> > +REVISION = 0
> >
> > SHARED_LIBS = KF5WebKit 4.1
> >
> > Index: devel/kreport/Makefile
> > ===
> > RCS file: /cvs/ports/devel/kreport/Makefile,v
> > retrieving revision 1.4
> > diff -u -p -u -p -r1.4 Makefile
> > --- devel/kreport/Makefile 21 May 2018 10:51:55 - 1.4
> > +++ devel/kreport/Makefile 27 Jul 2018 18:47:08 -
> > @@ -1,9 +1,13 @@
> > # $OpenBSD: Makefile,v 1.4 2018/05/21 10:51:55 rsadowski Exp $
> >
> > +# Qt5Webkit
> > +USE_WXNEEDED = Yes
> > +
> > COMMENT = framework for generation of reports in multiple formats
> >
> > VERSION = 3.1.0
> > DISTNAME = kreport-${VERSION}
> > +REVISION = 0
> >
> > CATEGORIES = devel
> >
> > Index: geo/qgis/Makefile
> > ===
> > RCS file: /cvs/ports/geo/qgis/Makefile,v
> > retrieving revision 1.91
> > diff -u -p -u -p -r1.91 Makefile
> > --- geo/qgis/Makefile 23 Jul 2018 07:05:32 - 1.91
> > +++ geo/qgis/Makefile 27 Jul 2018 18:47:16 -
> > @@ -1,8 +1,12 @@
> > # $OpenBSD: Makefile,v 1.91 2018/07/23 07:05:32 landry Exp $
> >
> > +# Qt5Webkit
> > +USE_WXNEEDED = Yes
> > +
> > COMMENT = desktop geographical information system
> >
> > DISTNAME = qgis-3.2.1
> > +REVISION = 0
> > EXTRACT_SUFX = .tar.bz2
> > CATEGORIES = geo x11
> >
> > Index: mail/trojita/Makefile
> > ===
> > RCS file: /cvs/ports/mail/trojita/Makefile,v
> > retrieving revision 1.28
> > diff -u -p -u -p -r1.28 Makefile
> > --- mail/trojita/Makefile 29 Jun 2018 22:16:17 - 1.28
> > +++ mail/trojita/Makefile 27 Jul 2018 18:47:19 -
> > @@ -1,10 +1,12 @@
> > # $OpenBSD: Makefile,v 1.28 2018/06/29 22:16:17 espie Exp $
> >
> > +# Qt5Webkit
> > +USE_WXNEEDED = Yes
> > +
> > COMMENT = fast Qt IMAP e-mail client
>
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: rpoin...@cvs.openbsd.org2018/08/02 03:37:37 Modified files: devel/py-olefile: Makefile distinfo devel/py-olefile/pkg: PLIST Log message: update olefile to 0.45.1.
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: rpoin...@cvs.openbsd.org2018/08/02 03:15:17 Modified files: www/py-django : Makefile Makefile.inc www/py-django/lts: Makefile distinfo www/py-django/lts/pkg: PLIST README www/py-django/stable: Makefile distinfo www/py-django/stable/pkg: PLIST README Log message: update LTS version to 1.11.15 and stable version to 2.1. ok jasper@.
UPDATE: multimedia/mkvtoolnix
Hi ports@, Hi Brad,
please find below an overdue mkvtoolnix update to the latest stable
version. All tests passed on amd64. mkvtoolnix-gui also works for my
jobs.
As a hint, you need cmark (separate email) as LIB_DEPENDS.
Brad, are you still interested in that maintenance?
Feedback? Ok?
Index: Makefile
===
RCS file: /cvs/ports/multimedia/mkvtoolnix/Makefile,v
retrieving revision 1.75
diff -u -p -u -p -r1.75 Makefile
--- Makefile1 Jul 2018 18:33:37 - 1.75
+++ Makefile2 Aug 2018 09:04:06 -
@@ -1,9 +1,8 @@
-# $OpenBSD: Makefile,v 1.75 2018/07/01 18:33:37 espie Exp $
+
COMMENT= create, alter and inspect Matroska files
-DISTNAME= mkvtoolnix-9.7.1
-REVISION= 5
+DISTNAME= mkvtoolnix-25.0.0
CATEGORIES=multimedia x11
MASTER_SITES= ${HOMEPAGE}sources/
EXTRACT_SUFX= .tar.xz
@@ -15,22 +14,28 @@ MAINTAINER= Brad Smith =1.4.5 \
@@ -41,12 +46,14 @@ MAKE_ENV+= V=1
CONFIGURE_STYLE= autoconf
AUTOCONF_VERSION= 2.69
CONFIGURE_ARGS=--disable-optimization \
+ --disable-update-check \
--with-boost-date-time=boost_date_time-mt \
--with-boost-filesystem=boost_filesystem-mt \
--with-boost-libdir=${LOCALBASE}/lib \
--with-boost-regex=boost_regex-mt \
--with-boost-system=boost_system-mt \
- --without-curl
+ --with-docbook-xsl-root=${LOCALBASE}/share/xsl/docbook
+
CPPFLAGS= -I${LOCALBASE}/include
LDFLAGS= -L${LOCALBASE}/lib
@@ -57,33 +64,34 @@ FLAVOR?=
CONFIGURE_ARGS+= --disable-gui
.else
MODULES+= x11/qt5
-WANTLIB+= Qt5Concurrent Qt5Core Qt5Gui Qt5Network Qt5Widgets
+WANTLIB+= Qt5Concurrent Qt5Core Qt5Gui Qt5Network Qt5Widgets Qt5Multimedia
+LIB_DEPENDS += x11/qt5/qtmultimedia
RUN_DEPENDS+= devel/desktop-file-utils \
misc/shared-mime-info \
x11/gtk+3,-guic
CPPFLAGS+= -I${X11BASE}/include
LDFLAGS+= -L${X11BASE}/lib -L${MODQT5_LIBDIR}
+CONFIGURE_ENV+=LCONVERT="${LOCALBASE}/lib/qt5/bin/lconvert"
.endif
-CONFIGURE_ENV= CPPFLAGS="${CPPFLAGS}" \
+CONFIGURE_ENV+=CPPFLAGS="${CPPFLAGS}" \
LDFLAGS="${LDFLAGS}"
-# XXX does not build with our pugixml (it's too new)
-CONFIGURE_ENV +=ac_cv_header_pugixml_hpp=no
-
-# avoid hidden build dep on gtest
-CONFIGURE_ENV +=ac_cv_lib_gtest_main_main=no
-
-NO_TEST= Yes
+pre-patch:
+ @cd ${WRKSRC}/src/mkvtoolnix-gui/jobs/program_runner/ && \
+ cp linux_program_runner.cpp unix_program_runner.cpp && \
+ cp linux_program_runner.h unix_program_runner.h
do-build:
@cd ${WRKSRC} && \
- env -i ${MAKE_ENV} ${RUBY} ./drake -j${MAKE_JOBS} \
- ${MAKE_FLAGS}
+ env -i ${MAKE_ENV} ${RAKE} -j${MAKE_JOBS} ${MAKE_FLAGS}
do-install:
@cd ${WRKSRC} && \
- env -i ${MAKE_ENV} ${RUBY} ./drake \
- DESTDIR=${WRKINST} install
+ env -i ${MAKE_ENV} ${RAKE} DESTDIR=${WRKINST} install
+
+do-test:
+ @cd ${WRKSRC} && \
+ env -i ${MAKE_ENV} ${RAKE} tests:run_unit
.include
Index: distinfo
===
RCS file: /cvs/ports/multimedia/mkvtoolnix/distinfo,v
retrieving revision 1.37
diff -u -p -u -p -r1.37 distinfo
--- distinfo31 Dec 2016 08:11:59 - 1.37
+++ distinfo2 Aug 2018 09:04:06 -
@@ -1,2 +1,2 @@
-SHA256 (mkvtoolnix-9.7.1.tar.xz) = sriCHi103w92XJf5Pd0dv7Bi88Irlpz6BNG7XLY4qI4=
-SIZE (mkvtoolnix-9.7.1.tar.xz) = 3824684
+SHA256 (mkvtoolnix-25.0.0.tar.xz) =
g0y3q92ISdo6aGQFXIIHzqRNFHaBR4MJGM0acjxAvDM=
+SIZE (mkvtoolnix-25.0.0.tar.xz) = 4797476
Index: patches/patch-ac_qt5_m4
===
RCS file: /cvs/ports/multimedia/mkvtoolnix/patches/patch-ac_qt5_m4,v
retrieving revision 1.5
diff -u -p -u -p -r1.5 patch-ac_qt5_m4
--- patches/patch-ac_qt5_m4 31 Dec 2016 08:11:59 - 1.5
+++ patches/patch-ac_qt5_m4 2 Aug 2018 09:04:06 -
@@ -2,9 +2,10 @@ $OpenBSD: patch-ac_qt5_m4,v 1.5 2016/12/
Workaround for OpenBSD's pkg-config.
ac/qt5.m4.orig Tue Dec 27 17:01:56 2016
-+++ ac/qt5.m4 Fri Dec 30 02:34:26 2016
-@@ -127,25 +127,23 @@ if test x"$enable_qt" = "xyes" -a \
+Index: ac/qt5.m4
+--- ac/qt5.m4.orig
ac/qt5.m4
+@@ -151,20 +151,18 @@ if test x"$enable_qt" = "xyes" -a \
fi
if test $ok = 1 -a "x$with_qt_pkg_config" = xyes; then
@@ -14,8 +15,8 @@ Workaround for OpenBSD's pkg-config.
+ with_qt_pkg_config_modules="$with_qt_pkg_config_modules"
fi
--
with_qt_pkg_config_modules="$with_qt_pkg_config_modules,Qt5Core,Qt5Gui,Qt5Widgets,Qt5Network,Qt5Concurrent"
-+with_qt_pkg_config_modules="$with_qt_pkg_config_modules Qt5Core Qt5Gui
Qt5Widgets Qt5Network Qt5Concurrent"
+-
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: es...@cvs.openbsd.org 2018/08/02 03:09:22 Modified files: infrastructure/mk: bsd.port.mk Log message: extra fragment that got in... as noticed by semarie@
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: st...@cvs.openbsd.org 2018/08/02 03:07:47 Modified files: net/fping : Makefile Log message: more notes so I remember which programs need changes for fping 4.0+
NEW: devel/cmark
Hi All. please find attached a small dependency for the upcoming multimedia/mkvtoolnix update. All tests are passed on amd64. pkg_info: Information for inst:cmark-0.28.3 Comment: CommonMark parsing and rendering library and program in C Required by: mkvtoolnix-25.0.0-no_x11 Description: cmark is the C reference implementation of CommonMark, a rationalized version of Markdown syntax with a spec. Maintainer: The OpenBSD ports mailing-list WWW: https://commonmark.org/ Ok? Comments? cmark-0.28.3.tar.gz Description: Binary data
