CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: rob...@cvs.openbsd.org 2021/01/24 00:15:04 Modified files: www/chromium : Makefile www/chromium/patches: patch-third_party_usrsctp_BUILD_gn Log message: unbreak usrsctp by taking the proper codepath on openbsd also makes google stadia work
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: rsadow...@cvs.openbsd.org 2021/01/23 23:46:08 Modified files: devel/quirks : Makefile devel/quirks/files: Quirks.pm Log message: x11/kde-applications/kdepim-apps-libs No longer part of KDE5
Re: [sparc64] Fix x11/spectrwm runtime
On Sat, Jan 23, 2021 at 09:04:22PM +0100, Stefan Hagen wrote: > Sebastien Marie wrote: > > On Sat, Jan 23, 2021 at 07:14:33PM +0100, Stefan Hagen wrote: > >> Hi, > >> > >> Spectrwm on Sparc64 wants the wpath pledge: > >> > >> 70801 spectrwm CALL open(0x7904d18380,0x10002) > >> 70801 spectrwm NAMI > >> "/var/cache/fontconfig//7908e75dfa020c169504380270e5263a-be64.cache-7" > >> 70801 spectrwm PLDG open, "wpath", errno 1 Operation not permitted > >> 70801 spectrwm PSIG SIGABRT SIG_DFL > >> > >> I've sent the fix upstream and it got merged already. > >> Meanwhile, here is the fixed port. > >> > >> Changes: > >> - added wpath pledge where needed > >> - added revision > > > > I am a bit unsure about adding "wpath" in promises. Usually when > > fontconfig write is involved, it means the cache is out of sync (and > > it is odd it is happening for the system cache). If I didn't mess > > myself, I recall about something like that previously. > > > > If adding "wpath" is really required, it would be interesting to use > > also unveil to restrict the promise added. > > You're right. I can reproduce it on amd64 now: > > If I fiddle with my font paths and then (re)start X, spectrwm crashes > with a wpath violation on amd64 too. > > This is something that can happen with any X application... > > Instead of allowing wpath and catching it again with unveil, wouldn't > it be worth thinking about a pledge promise that allows X font cache > updates? no. the kernel shouldn't have to know what all libraries could do :) the responsability is shared between the compoments: - it is the application responsability to pledge for what the application and all linked libraries will need (like sthen@ mentioned) - it is the library responsability to not doing silly things (regarding fontconfig, we patched out chmod(2) usage from it for example: https://marc.info/?l=openbsd-cvs=157229154821950=2). - it is the responsability of the kernel to enforce, in a generic way, what the application pledge for, without having a complex interface. you could compare pledge(2) usage in cat(1) (it was tame(2) in first ages) https://github.com/openbsd/src/commit/b7db428a8107ad20577d7c8416bf55a8f875e621 and capsicum https://cgit.freebsd.org/src/commit/bin/cat/cat.c?id=aefe30c5437159a5399bdbc1974d6fbf40f2ba0f . > There is still a difference. On amd64, I can start another WM or an > xterm and on the next start spectrwm works. The same does not work on > the sparc64 machine. I don't know what fontconfig is doing there. It > looks like the font cache is always out of sync here. in your ktrace extract, fontconfig is trying to revalidate the *system* cache (/var/cache/fontconfig). only root could do that (but fontconfig tries to do it, and will fail due to EPERM - and when pledged, the fact to try to use O_RDWR makes it to die). in "fiddle with my font paths", it should rewrite the user cache (usually ~/.cache/fontconfig), which is something it has permission to do (if not killed by pledge). I am suspecting some issue in the way your x11 sets were installed (did you use bsd.rd ? installing from source ?) system fontconfig cache comes from xbase68.tgz. Previously, we made some adjustements too keep it in sync with fonts directories (https://marc.info/?l=openbsd-cvs=153117126409370=2). Please note I am also unsure how fonts from ports are managed. A possible workaround would be to run `fc-cache -s' as root, but it will only correct the immediate problem (out-of-sync) and not the underline problem (why the cache is out-of-sync). Thanks. -- Sebastien Marie
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs
Module name:ports
Changes by: gkoeh...@cvs.openbsd.org2021/01/23 21:41:51
Modified files:
lang/gcc/8 : Makefile
lang/gcc/8/patches: patch-gcc_config_aarch64_openbsd_h
patch-gcc_config_alpha_openbsd_h
patch-gcc_config_arm_openbsd_h
patch-gcc_config_i386_openbsdelf_h
patch-gcc_config_mips_openbsd_h
patch-gcc_config_pa_pa-openbsd_h
patch-gcc_config_rs6000_openbsd_h
patch-gcc_config_sparc_openbsd64_h
Log message:
Edit LINK_SPEC, fix static linking with ports-gcc
egcc -static was broken on most arches; the static binary wrongly
requested ld.so(1), but /usr/lib/rcrt0.o wants to do the relocation
without ld.so(1). The fix is to drop ld.so,
%{!static:-dynamic-linker /usr/libexec/ld.so}
Remove "%{!dynamic-linker:...}" because gcc -dynamic-linker is not an
option. Correct "%{!r*:...}" to "%{!r:...}" because gcc -r doesn't
take an option argument. Use "%{!nostdlib:-L/usr/lib}" on lld
arches, like base-gcc.
Edit the powerpc LINK_SPEC in rs6000/openbsd.h to be like the others.
Add "%{!nostdlib:-L/usr/lib}" so I can try lld on powerpc. For now,
don't edit the powerpc64 LINK_SPEC.
ok pascal@ (maintainer)
Re: [update] www/uwebsockets to 18.19.0, purritobin to 0.4.0
On 1/13/21 2:03 PM, Aisha Tammy wrote: > Hi, > I've attached trivial updates for two packages. > The install data part for www/purritobin is now handled inside the upstream > Makefile > so we now have a very simple port. > > OK? > > Cheers, > Aisha bump
Re: [update] mail/mutt-wizard to v3.1.1
On 1/23/21 5:55 PM, Aisha Tammy wrote:
> Hi,
> I've attached update to mail/mutt-wizard from dated version to a
> proper release version (upstream was not making releases until recently).
> Also made a bump to EPOCH to 1.
>
> OK?
>
> Thanks,
> Aisha
Forgot to start EPOCH from 0.
Thanks,
Aisha
diff --git a/mail/mutt-wizard/Makefile b/mail/mutt-wizard/Makefile
index ad09b6dd15d..5f1aea3016c 100644
--- a/mail/mutt-wizard/Makefile
+++ b/mail/mutt-wizard/Makefile
@@ -1,13 +1,16 @@
# $OpenBSD: Makefile,v 1.2 2020/12/15 16:54:48 sthen Exp $
COMMENT = neomutt and isync configuration with good defaults
-# commit date 20201210
-DISTNAME = mutt-wizard-20201210
CATEGORIES = mail
+# moved from dated to versioned
+EPOCH =0
+
+VERSION = 3.1.1
+
GH_ACCOUNT = LukeSmithxyz
GH_PROJECT = mutt-wizard
-GH_COMMIT =456d02d1ee0ab196ac256b91c9ac86a01f3c0bb6
+GH_TAGNAME = v${VERSION}
MAINTAINER = Aisha Tammy
diff --git a/mail/mutt-wizard/distinfo b/mail/mutt-wizard/distinfo
index a718ea05b59..c7ba28ea0eb 100644
--- a/mail/mutt-wizard/distinfo
+++ b/mail/mutt-wizard/distinfo
@@ -1,2 +1,2 @@
-SHA256 (mutt-wizard-20201210-456d02d1.tar.gz) =
8LTdA8iIhPIuc9adHlJUJdP7pZTzBmBj5HHndT9mm84=
-SIZE (mutt-wizard-20201210-456d02d1.tar.gz) = 30962
+SHA256 (mutt-wizard-3.1.1.tar.gz) =
8H7/c2LfKQkxddAa8iwPQwk7aQK/U0P5KiWroO8ERuU=
+SIZE (mutt-wizard-3.1.1.tar.gz) = 33346
diff --git a/mail/mutt-wizard/pkg/PLIST b/mail/mutt-wizard/pkg/PLIST
index 35bd09504e4..346f7cbe3f5 100644
--- a/mail/mutt-wizard/pkg/PLIST
+++ b/mail/mutt-wizard/pkg/PLIST
@@ -1,4 +1,5 @@
@comment $OpenBSD: PLIST,v 1.1.1.1 2020/09/09 07:27:57 pamela Exp $
+bin/mailsync
bin/mw
bin/openfile
@man man/man1/mw.1
Re: Updating a port - moving from dated (20201210) to versioned (3.1.1)
On 1/23/21 6:00 PM, Daniel Jakots wrote: > On Sat, 23 Jan 2021 17:41:14 -0500, Aisha Tammy > wrote: > >> Awesome, thanks a lot! > > I hope you don't miss the "Defaults to empty (no need for numbering > changes), then numbering starts at 0." sentence ;) > > Cheers, > Daniel > Crap, I missed that it starts from 0 :P Thanks!! Aisha
Re: Updating a port - moving from dated (20201210) to versioned (3.1.1)
On 1/23/21 6:02 PM, Stuart Henderson wrote: > On 2021/01/23 17:37, Daniel Jakots wrote: >> On Sat, 23 Jan 2021 17:31:51 -0500, Aisha Tammy >> wrote: >> >>> what the method is to move from a versioned package >>> to a dated package, as the dated packages would look like its a >>> downgrade >> >> Set EPOCH https://man.openbsd.org/bsd.port.mk#EPOCH >> > > This, plus if you're writing a new port for something which just has a > dated version, you can set e.g. 0.0.20210123 so that nearly any "real" > version will be "newer". > > (EPOCH is there if it's absolutely needed, but it causes problems too: > it's easily removed by mistake later [once set EPOCH can never be removed, > but sometimes people confuse it with REVISION], and when another port > sets a pkgspec to depend on a certain version, that has to use the full > version number including EPOCH - so if you can avoid future requirement > to use it, that's better). > Will definitely keep in mind for future. Thanks! Aisha
[update] mail/mutt-wizard to v3.1.1
Hi,
I've attached update to mail/mutt-wizard from dated version to a
proper release version (upstream was not making releases until recently).
Also made a bump to EPOCH to 1.
OK?
Thanks,
Aisha
diff --git a/mail/mutt-wizard/Makefile b/mail/mutt-wizard/Makefile
index ad09b6dd15d..7f3e70d9c9c 100644
--- a/mail/mutt-wizard/Makefile
+++ b/mail/mutt-wizard/Makefile
@@ -1,13 +1,16 @@
# $OpenBSD: Makefile,v 1.2 2020/12/15 16:54:48 sthen Exp $
COMMENT = neomutt and isync configuration with good defaults
-# commit date 20201210
-DISTNAME = mutt-wizard-20201210
CATEGORIES = mail
+# moved from dated to versioned
+EPOCH =1
+
+VERSION = 3.1.1
+
GH_ACCOUNT = LukeSmithxyz
GH_PROJECT = mutt-wizard
-GH_COMMIT =456d02d1ee0ab196ac256b91c9ac86a01f3c0bb6
+GH_TAGNAME = v${VERSION}
MAINTAINER = Aisha Tammy
diff --git a/mail/mutt-wizard/distinfo b/mail/mutt-wizard/distinfo
index a718ea05b59..c7ba28ea0eb 100644
--- a/mail/mutt-wizard/distinfo
+++ b/mail/mutt-wizard/distinfo
@@ -1,2 +1,2 @@
-SHA256 (mutt-wizard-20201210-456d02d1.tar.gz) =
8LTdA8iIhPIuc9adHlJUJdP7pZTzBmBj5HHndT9mm84=
-SIZE (mutt-wizard-20201210-456d02d1.tar.gz) = 30962
+SHA256 (mutt-wizard-3.1.1.tar.gz) =
8H7/c2LfKQkxddAa8iwPQwk7aQK/U0P5KiWroO8ERuU=
+SIZE (mutt-wizard-3.1.1.tar.gz) = 33346
diff --git a/mail/mutt-wizard/pkg/PLIST b/mail/mutt-wizard/pkg/PLIST
index 35bd09504e4..346f7cbe3f5 100644
--- a/mail/mutt-wizard/pkg/PLIST
+++ b/mail/mutt-wizard/pkg/PLIST
@@ -1,4 +1,5 @@
@comment $OpenBSD: PLIST,v 1.1.1.1 2020/09/09 07:27:57 pamela Exp $
+bin/mailsync
bin/mw
bin/openfile
@man man/man1/mw.1
Re: Updating a port - moving from dated (20201210) to versioned (3.1.1)
On 1/23/21 5:37 PM, Daniel Jakots wrote: > On Sat, 23 Jan 2021 17:31:51 -0500, Aisha Tammy > wrote: > >> what the method is to move from a versioned package >> to a dated package, as the dated packages would look like its a >> downgrade > > Set EPOCH https://man.openbsd.org/bsd.port.mk#EPOCH > Awesome, thanks a lot! Also looked at package-specs with the rc/pre/etc. which was also very helpful! Best, Aisha
Updating a port - moving from dated (20201210) to versioned (3.1.1)
Hi, I'm wondering what the method is to move from a versioned package to a dated package, as the dated packages would look like its a downgrade. Upstream was very reluctant to make versions but has now started making versions available for people to use which creates a slight hiccup in updating the package. Thanks, Aisha PS: In Gentoo, the general consensus to keep dated packages as 0_p20201210 so that updates are easier in case upstream starts releasing versioned package. I think thats a simple enough approach to use here as well (in case of any of my future packages I submit here, and also for peoples local tree).
Re: Alpine mail client. Fresh install of 6.8. "Mail" works but Alpine problems
Stefan, A million thanks! Local host works! Too simple -- too logical! I would never have imagined that Alpine wouldn't have worked without that. Going to my mounted backup drive Look at how long I haven't needed to change one of the shell configuration files! ...: - pwd /home/... cd oldq3/ ls -l .cshrc -rw--- 1 ... ... 2707 Sep 23 2002 .cshrc -- Of course I regularly change certain minor features in pine/Alpine's .pinerc so last change was earlier this month. I am sure I never changed the smpt-server configuration, however. [not showing the .pinerc file date here since it changes often] Extract from old .pinerc -- smtp-server was always left blank up till now... --- # List of SMTP servers for sending mail. If blank: Unix Pine uses sendmail. smtp-server= # NNTP server for posting news. Also sets news-collections for news reading. nntp-server= Now going into the newly installed Alpine mail client Setup/Configure menu -- SMTP Server (for sending) = NNTP Server (for news)= I NOTE THAT FIRST USE AFTER NEW INSTALL, if there is no .pinerc file yet, it immediately tries to send a message back to the maintainers at U. of Washington, and obviously expects that to work, but instead, it immediately hangs. That probably means that something in how OpenBSD is configured these days, doesn't allow for that. But maybe it should, or rather, a small change in the patches for the Alpine port configuration, for OpenBSD, could allow for it to immediately send from the box where Alpine was just newly installed. Looking directly into the new .pinerc file: Extract follows: # List of SMTP servers for sending mail. If blank: Unix Alpine uses sendmail. smtp-server= # NNTP server for posting news. Also sets news-collections for news reading. nntp-server= /Extract i.e. same as ever Now after using the Setup/Configure menu in the latest version from 6.8 packages and setting the server to "localhost", as you suggested, the .pinerc looks like: Extract: # List of SMTP servers for sending mail. If blank: Unix Alpine uses sendmail. smtp-server=localhost # NNTP server for posting news. Also sets news-collections for news reading. nntp-server= /Extract AND THAT WORKS LIKE A CHARM! What's really curious is the statement in .pinerc that "If blank: Unix Alpine uses sendmail." Well to me that implies that it would use sendmail on the local host, so one wouldn't think that one would also have to specify it in the setup menu for first use. --- After one already had to deal with the initial "hang"! I note that the sendmail we now have is the pseudo Sendmail provided by the newer smpt/smptd system. I can't see that being the problem. Maybe some patch to Alpine was made for tighter OpenBSD security, or there is some additional system configuration I should have attended to these days. I'll put into my todo list to do a little more code digging, and look at the port if no one else gets to it. At the moment I have an incredible backlog of work and apologies to make for lost incoming emails after being down for a week, and also not replying even after incoming email was working and I had the awkward work-around of "Mail". I note that .calendar is not working for me. Wonder if it is a related kind of deeper problem in my system setup. Not critical though Most Alpine users (if any are still left), probably use an external mail server, and would have filled in something, so would never see this problem. Still would like to hear from any regular OpenBSD Alpine users. - Now to set up a new webserver too. And then maybe even do some crucial Year End company paperwork [Wish I had some time left for programming!] Stefan, again, thanks so much. Regards, Austin Hook Milk River, Canada On Sat, 23 Jan 2021, Stefan Hagen wrote: > Hi Austin, > > aus...@computershop.ca wrote: > > 2) Any reason why the new pseudo-Sendmail wouldn't handle Apline as > > well as the old one did? > > This mailing list is mostly for porting work and not for questions about > functionality or bugs that are not related to the porting process but > the software itself. > > That being said, I played around with alpine. You're right. If you leave > "smtp-server=" empty, sending an email gets stuck as you described. > > I've tried to set "smtp-server=" to localhost as well as to my > SMTP/SMTPs OpenSMTPd server. Those
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: k...@cvs.openbsd.org2021/01/23 16:17:48 Modified files: databases/tdb : Makefile net/netatalk3 : Makefile mail/neomutt : Makefile mail/fdm : Makefile audio/rhythmbox: Makefile audio/rhythmbox/pkg: PLIST audio/pulseaudio: Makefile Added files: databases/tdb/pkg: DESCR-main DESCR-python PLIST-main PLIST-python Removed files: databases/tdb/pkg: DESCR PLIST Log message: Split databases/tdb into -main and -python package net/samba is the only consumer requiring Python bindings, so this split enables all other consumers (netatalk3, neomutt, fdm, rhythmbox, pulseaudio) to avoid the dependency on Python 2. Bump all consumers due to tdb's PKGPATH change. Wanted by many Feedback OK jca sthen
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: st...@cvs.openbsd.org 2021/01/23 16:11:13 Modified files: mail/mutt-wizard: Makefile distinfo mail/mutt-wizard/pkg: PLIST Log message: update to mutt-wizard-3.1.1, from Aisha Tammy (maintainer), small tweak from me
Re: tdb: split py2 bindings into -python package
On 2021/01/23 23:54, Jeremie Courreges-Anglas wrote: > On Sat, Jan 23 2021, Klemens Nanni wrote: > > On Sat, Jan 23, 2021 at 08:24:23PM +, Stuart Henderson wrote: > >> hmm, shouldn't that just be called "py-tdb"? that will leave things > >> open to adding a py3 flavour too. > > Some ports go with the "-python" suffix such as security/sudo for > > example and that's in line with the suffix in MULTI_PACKAGES, so I went > > for that. > > > > But given that it'll go from Python 2 to 3 eventually, the py-/py3- > > prefix makes more sense, so new diff below with that. > > I had missed that before sending my earlier reply. Maybe sudo-python > isn't a regular python module, but py-tdb is, and the prefix is needed. yes.. sudo-python is a plugin for sudo providing the ability to write sudo plugins in Python. Compare with py-subversion which is python bindings to subversion. > >> > -@conflict samba-<3.5.0 > >> > >> I see that one was dropped, but it was from OpenBSD 4.8 and there have > >> been flag days since then so that's ok, there is no way somebody could > >> upgrade directly from there. > > I dropped it because it is so old, yes. > > Generally I'd rather keep old conflict markers around, to avoid wasintg > time discussing their usefulness. But fine, let's drop it. > > > Third time's the charm. > > Feedback? OK? > > Looks Great To Me. Thanks a lot for tackling this, it's low priority > for me but it seems to matter to a bunch of people. > > ok jca@ +1, OK here too.
Re: Updating a port - moving from dated (20201210) to versioned (3.1.1)
On 2021/01/23 17:37, Daniel Jakots wrote: > On Sat, 23 Jan 2021 17:31:51 -0500, Aisha Tammy > wrote: > > > what the method is to move from a versioned package > > to a dated package, as the dated packages would look like its a > > downgrade > > Set EPOCH https://man.openbsd.org/bsd.port.mk#EPOCH > This, plus if you're writing a new port for something which just has a dated version, you can set e.g. 0.0.20210123 so that nearly any "real" version will be "newer". (EPOCH is there if it's absolutely needed, but it causes problems too: it's easily removed by mistake later [once set EPOCH can never be removed, but sometimes people confuse it with REVISION], and when another port sets a pkgspec to depend on a certain version, that has to use the full version number including EPOCH - so if you can avoid future requirement to use it, that's better).
Re: Updating a port - moving from dated (20201210) to versioned (3.1.1)
On Sat, 23 Jan 2021 17:41:14 -0500, Aisha Tammy wrote: > Awesome, thanks a lot! I hope you don't miss the "Defaults to empty (no need for numbering changes), then numbering starts at 0." sentence ;) Cheers, Daniel
Re: tdb: split py2 bindings into -python package
On Sat, Jan 23 2021, Klemens Nanni wrote: > On Sat, Jan 23, 2021 at 08:24:23PM +, Stuart Henderson wrote: >> hmm, shouldn't that just be called "py-tdb"? that will leave things >> open to adding a py3 flavour too. > Some ports go with the "-python" suffix such as security/sudo for > example and that's in line with the suffix in MULTI_PACKAGES, so I went > for that. > > But given that it'll go from Python 2 to 3 eventually, the py-/py3- > prefix makes more sense, so new diff below with that. I had missed that before sending my earlier reply. Maybe sudo-python isn't a regular python module, but py-tdb is, and the prefix is needed. >> > -@conflict samba-<3.5.0 >> >> I see that one was dropped, but it was from OpenBSD 4.8 and there have >> been flag days since then so that's ok, there is no way somebody could >> upgrade directly from there. > I dropped it because it is so old, yes. Generally I'd rather keep old conflict markers around, to avoid wasintg time discussing their usefulness. But fine, let's drop it. > Third time's the charm. > Feedback? OK? Looks Great To Me. Thanks a lot for tackling this, it's low priority for me but it seems to matter to a bunch of people. ok jca@ -- jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF DDCC 0DFA 74AE 1524 E7EE
Re: Updating a port - moving from dated (20201210) to versioned (3.1.1)
On Sat, 23 Jan 2021 17:31:51 -0500, Aisha Tammy wrote: > what the method is to move from a versioned package > to a dated package, as the dated packages would look like its a > downgrade Set EPOCH https://man.openbsd.org/bsd.port.mk#EPOCH
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: na...@cvs.openbsd.org 2021/01/23 15:13:14 Modified files: audio/vorbis-tools: Makefile distinfo audio/vorbis-tools/patches: patch-configure patch-ogg123_Makefile_in patch-ogg123_ogg123_c patch-ogg123_vorbis_comments_c Added files: audio/vorbis-tools/patches: patch-ogginfo_codec_skeleton_c Removed files: audio/vorbis-tools/patches: patch-oggenc_audio_c patch-oggenc_oggenc_c Log message: audio/vorbis-tools: update to 1.4.2 This release fixes many bugs. Additional user-visible changes: * ogg123: Added support for Opus files * ogginfo: Added support for Opus, FLAC, and speex * ogg123, ogginfo: Added support to decode METADATA_BLOCK_PICTURE * ogginfo: Added support for decoding Skeleton * vorbiscomment: Added -d/--rm to allow removal of tags
Re: py-lxml update to fix cve-2020-27783
On Sun, 3 Jan 2021, Daniel Dickman wrote:
> Here's a diff to update py-lxml to version 4.6.2 which fixes
> CVE-2020-27783.
>
> I've compile tested the consumers on amd64 without any issues.
>
> ok?
>
Here's a regenerated diff following the python 3.8.7 update. still looking
for ok's to address this cve.
Index: Makefile
===
RCS file: /cvs/ports/textproc/py-lxml/Makefile,v
retrieving revision 1.35
diff -u -p -u -r1.35 Makefile
--- Makefile4 Jan 2021 14:06:38 - 1.35
+++ Makefile23 Jan 2021 21:52:11 -
@@ -4,10 +4,9 @@ BROKEN-hppa= OOM on src/lxml/lxml.etree.
COMMENT= Python binding for the libxml2 and libxslt libraries
-MODPY_EGG_VERSION= 4.3.3
+MODPY_EGG_VERSION= 4.6.2
DISTNAME= lxml-${MODPY_EGG_VERSION}
PKGNAME= py-lxml-${MODPY_EGG_VERSION}
-REVISION= 4
CATEGORIES=textproc devel
Index: distinfo
===
RCS file: /cvs/ports/textproc/py-lxml/distinfo,v
retrieving revision 1.11
diff -u -p -u -r1.11 distinfo
--- distinfo25 Apr 2019 19:37:23 - 1.11
+++ distinfo23 Jan 2021 21:52:11 -
@@ -1,2 +1,2 @@
-SHA256 (lxml-4.3.3.tar.gz) = SgPdaC+ONaECNJBOC5UI1wX/mM+WLFhR7QUuk0DfPZA=
-SIZE (lxml-4.3.3.tar.gz) = 4378439
+SHA256 (lxml-4.6.2.tar.gz) = zRHH6NIa+ZfugHkDf/+I8W/aGIqXdutLgcfkycCn1/w=
+SIZE (lxml-4.6.2.tar.gz) = 3177310
Index: pkg/PLIST
===
RCS file: /cvs/ports/textproc/py-lxml/pkg/PLIST,v
retrieving revision 1.11
diff -u -p -u -r1.11 PLIST
--- pkg/PLIST 4 Jan 2021 14:06:39 - 1.11
+++ pkg/PLIST 23 Jan 2021 21:52:11 -
@@ -106,7 +106,10 @@ lib/python${MODPY_VERSION}/site-packages
lib/python${MODPY_VERSION}/site-packages/lxml/usedoctest.py
share/doc/${MODPY_PY_PREFIX}lxml/
share/doc/${MODPY_PY_PREFIX}lxml/FAQ.txt
+share/doc/${MODPY_PY_PREFIX}lxml/api/
share/doc/${MODPY_PY_PREFIX}lxml/api.txt
+share/doc/${MODPY_PY_PREFIX}lxml/api/Makefile
+share/doc/${MODPY_PY_PREFIX}lxml/api/conf.py
share/doc/${MODPY_PY_PREFIX}lxml/build.txt
share/doc/${MODPY_PY_PREFIX}lxml/capi.txt
share/doc/${MODPY_PY_PREFIX}lxml/compatibility.txt
@@ -117,473 +120,77 @@ share/doc/${MODPY_PY_PREFIX}lxml/element
share/doc/${MODPY_PY_PREFIX}lxml/extensions.txt
share/doc/${MODPY_PY_PREFIX}lxml/html/
share/doc/${MODPY_PY_PREFIX}lxml/html/FAQ.html
-share/doc/${MODPY_PY_PREFIX}lxml/html/api/
share/doc/${MODPY_PY_PREFIX}lxml/html/api.html
-share/doc/${MODPY_PY_PREFIX}lxml/html/api/abc.ABCMeta-class.html
-share/doc/${MODPY_PY_PREFIX}lxml/html/api/api-objects.txt
-share/doc/${MODPY_PY_PREFIX}lxml/html/api/class-tree.html
-share/doc/${MODPY_PY_PREFIX}lxml/html/api/cssselect.parser.SelectorError-class.html
-share/doc/${MODPY_PY_PREFIX}lxml/html/api/cssselect.parser.SelectorSyntaxError-class.html
-share/doc/${MODPY_PY_PREFIX}lxml/html/api/cssselect.xpath.ExpressionError-class.html
-share/doc/${MODPY_PY_PREFIX}lxml/html/api/cssselect.xpath.XPathExpr-class.html
-share/doc/${MODPY_PY_PREFIX}lxml/html/api/deprecated-index.html
-share/doc/${MODPY_PY_PREFIX}lxml/html/api/epydoc.css
-share/doc/${MODPY_PY_PREFIX}lxml/html/api/exceptions.AssertionError-class.html
-share/doc/${MODPY_PY_PREFIX}lxml/html/api/frames.html
-share/doc/${MODPY_PY_PREFIX}lxml/html/api/help.html
-share/doc/${MODPY_PY_PREFIX}lxml/html/api/identifier-index-A.html
-share/doc/${MODPY_PY_PREFIX}lxml/html/api/identifier-index-B.html
-share/doc/${MODPY_PY_PREFIX}lxml/html/api/identifier-index-C.html
-share/doc/${MODPY_PY_PREFIX}lxml/html/api/identifier-index-D.html
-share/doc/${MODPY_PY_PREFIX}lxml/html/api/identifier-index-E.html
-share/doc/${MODPY_PY_PREFIX}lxml/html/api/identifier-index-F.html
-share/doc/${MODPY_PY_PREFIX}lxml/html/api/identifier-index-G.html
-share/doc/${MODPY_PY_PREFIX}lxml/html/api/identifier-index-H.html
-share/doc/${MODPY_PY_PREFIX}lxml/html/api/identifier-index-I.html
-share/doc/${MODPY_PY_PREFIX}lxml/html/api/identifier-index-J.html
-share/doc/${MODPY_PY_PREFIX}lxml/html/api/identifier-index-K.html
-share/doc/${MODPY_PY_PREFIX}lxml/html/api/identifier-index-L.html
-share/doc/${MODPY_PY_PREFIX}lxml/html/api/identifier-index-M.html
-share/doc/${MODPY_PY_PREFIX}lxml/html/api/identifier-index-N.html
-share/doc/${MODPY_PY_PREFIX}lxml/html/api/identifier-index-O.html
-share/doc/${MODPY_PY_PREFIX}lxml/html/api/identifier-index-P.html
-share/doc/${MODPY_PY_PREFIX}lxml/html/api/identifier-index-Q.html
-share/doc/${MODPY_PY_PREFIX}lxml/html/api/identifier-index-R.html
-share/doc/${MODPY_PY_PREFIX}lxml/html/api/identifier-index-S.html
-share/doc/${MODPY_PY_PREFIX}lxml/html/api/identifier-index-T.html
-share/doc/${MODPY_PY_PREFIX}lxml/html/api/identifier-index-U.html
-share/doc/${MODPY_PY_PREFIX}lxml/html/api/identifier-index-V.html
-share/doc/${MODPY_PY_PREFIX}lxml/html/api/identifier-index-W.html
-share/doc/${MODPY_PY_PREFIX}lxml/html/api/identifier-index-X.html
Re: update www/nginx-naxsi
On Fri, 22 Jan 2021 23:09:49 +0100 Solene Rapenne : > This diff updates the nginx naxsi module to its latest version. > The current version we have is from february 2017. > > A small patch is required to compile, I'll upstream it. > patch got upstreamed but I'm not sure they release often. https://github.com/nbs-system/naxsi/commit/0395b102b7e9b5165e89e99bb62e9ddaa0a74910 I'll include that link in the patch before committing it (if ok for update)
Re: tdb: split py2 bindings into -python package
On Sat, Jan 23, 2021 at 08:24:23PM +, Stuart Henderson wrote:
> hmm, shouldn't that just be called "py-tdb"? that will leave things
> open to adding a py3 flavour too.
Some ports go with the "-python" suffix such as security/sudo for
example and that's in line with the suffix in MULTI_PACKAGES, so I went
for that.
But given that it'll go from Python 2 to 3 eventually, the py-/py3-
prefix makes more sense, so new diff below with that.
> > -@conflict samba-<3.5.0
>
> I see that one was dropped, but it was from OpenBSD 4.8 and there have
> been flag days since then so that's ok, there is no way somebody could
> upgrade directly from there.
I dropped it because it is so old, yes.
Third time's the charm.
Feedback? OK?
Index: databases/tdb/Makefile
===
RCS file: /cvs/ports/databases/tdb/Makefile,v
retrieving revision 1.32
diff -u -p -r1.32 Makefile
--- databases/tdb/Makefile 14 Mar 2020 15:35:29 - 1.32
+++ databases/tdb/Makefile 23 Jan 2021 21:28:36 -
@@ -1,9 +1,14 @@
# $OpenBSD: Makefile,v 1.32 2020/03/14 15:35:29 kn Exp $
-COMMENT= trivial database library
+COMMENT-main= trivial database library
+COMMENT-python=Python ${MODPY_VERSION} bindings for tdb
# Keep in sync with the version bundled in net/samba
DISTNAME= tdb-1.3.18
+PKGNAME-main= ${DISTNAME}
+REVISION-main= 0
+PKGNAME-python=py-${DISTNAME}
+MULTI_PACKAGES=-main -python
# 0750 on Makefile and other files breaks update-patches with PORTS_PRIVSEP=Yes
FIX_EXTRACT_PERMISSIONS= Yes
@@ -19,7 +24,8 @@ MAINTAINER= Jeremie Courreges-Anglas https://download.samba.org/pub/tdb/
@@ -32,7 +38,8 @@ MODPY_ADJ_FILES= buildtools/bin/waf
BUILD_DEPENDS= textproc/docbook-xsl \
textproc/libxslt
-LIB_DEPENDS= ${MODPY_LIB_DEPENDS}
+LIB_DEPENDS-python=${BUILD_PKGPATH} \
+ ${MODPY_LIB_DEPENDS}
WAF_ARGS= -v -j ${MAKE_JOBS}
MAKE_FLAGS=WAF_ARGS="${WAF_ARGS}"
Index: databases/tdb/pkg/DESCR
===
RCS file: databases/tdb/pkg/DESCR
diff -N databases/tdb/pkg/DESCR
--- databases/tdb/pkg/DESCR 28 Jul 2007 21:37:26 - 1.1.1.1
+++ /dev/null 1 Jan 1970 00:00:00 -
@@ -1,4 +0,0 @@
-TDB is a Trivial Database. In concept, it is very much like GDBM, and
-BSD's DB except that it allows multiple simultaneous writers and uses
-locking internally to keep writers from trampling on each other. TDB is
-also extremely small.
Index: databases/tdb/pkg/DESCR-main
===
RCS file: databases/tdb/pkg/DESCR-main
diff -N databases/tdb/pkg/DESCR-main
--- /dev/null 1 Jan 1970 00:00:00 -
+++ databases/tdb/pkg/DESCR-main28 Jul 2007 21:37:26 -
@@ -0,0 +1,4 @@
+TDB is a Trivial Database. In concept, it is very much like GDBM, and
+BSD's DB except that it allows multiple simultaneous writers and uses
+locking internally to keep writers from trampling on each other. TDB is
+also extremely small.
Index: databases/tdb/pkg/DESCR-python
===
RCS file: databases/tdb/pkg/DESCR-python
diff -N databases/tdb/pkg/DESCR-python
--- /dev/null 1 Jan 1970 00:00:00 -
+++ databases/tdb/pkg/DESCR-python 23 Jan 2021 13:47:51 -
@@ -0,0 +1 @@
+Python ${MODPY_VERSION} bindings for tdb.
Index: databases/tdb/pkg/PLIST
===
RCS file: databases/tdb/pkg/PLIST
diff -N databases/tdb/pkg/PLIST
--- databases/tdb/pkg/PLIST 4 Dec 2019 00:14:45 - 1.10
+++ /dev/null 1 Jan 1970 00:00:00 -
@@ -1,16 +0,0 @@
-@comment $OpenBSD: PLIST,v 1.10 2019/12/04 00:14:45 jca Exp $
-@conflict samba-<3.5.0
-@bin bin/tdbbackup
-@bin bin/tdbdump
-@bin bin/tdbrestore
-@bin bin/tdbtool
-include/tdb.h
-@lib lib/libtdb.so.${LIBtdb_VERSION}
-lib/pkgconfig/tdb.pc
-lib/python${MODPY_VERSION}/site-packages/_tdb_text.py
-lib/python${MODPY_VERSION}/site-packages/_tdb_text.pyc
-@so lib/python${MODPY_VERSION}/site-packages/tdb.so
-@man man/man8/tdbbackup.8
-@man man/man8/tdbdump.8
-@man man/man8/tdbrestore.8
-@man man/man8/tdbtool.8
Index: databases/tdb/pkg/PLIST-main
===
RCS file: databases/tdb/pkg/PLIST-main
diff -N databases/tdb/pkg/PLIST-main
--- /dev/null 1 Jan 1970 00:00:00 -
+++ databases/tdb/pkg/PLIST-main23 Jan 2021 13:44:01 -
@@ -0,0 +1,13 @@
+@comment $OpenBSD: PLIST-main,v$
+@pkgpath databases/tdb
+@bin bin/tdbbackup
+@bin bin/tdbdump
+@bin bin/tdbrestore
+@bin bin/tdbtool
+include/tdb.h
+@lib lib/libtdb.so.${LIBtdb_VERSION}
+lib/pkgconfig/tdb.pc
+@man man/man8/tdbbackup.8
+@man man/man8/tdbdump.8
+@man man/man8/tdbrestore.8
+@man man/man8/tdbtool.8
Index: databases/tdb/pkg/PLIST-python
===
RCS file:
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: dan...@cvs.openbsd.org 2021/01/23 14:41:20 Modified files: www/jupyter-notebook: Makefile distinfo www/jupyter-notebook/pkg: PLIST Log message: update jupyter-notebook to 6.1.6 addressing cve-2020-26215 ok bket@
Re: Icewm update 2.1.0
Works for me, has fixed the bug. Thanks!!
John
On 1/23/21 12:50 AM, Timo Myyrä wrote:
John Batteen [2021-01-22, 18:52 -0600]:
Hi ports,
IceWM has released 2.1.0 to fix a bug introduced in 2.0.0, related to going
from a maximized window to fullscreen and back again. Making the new port
myself is beyond my abilities, sorry.
Thanks for making a great operating system.
John
Here's an patch for icewm, very lightly tested on amd64 so far. More
tests welcome.
timo
Index: Makefile
===
RCS file: /cvs/ports/x11/icewm/Makefile,v
retrieving revision 1.77
diff -u -p -u -p -r1.77 Makefile
--- Makefile29 Dec 2020 10:47:00 - 1.77
+++ Makefile23 Jan 2021 06:49:03 -
@@ -3,7 +3,7 @@
# unconditionally uses machine/apmvar.h and related structures/defines
ONLY_FOR_ARCHS= ${APM_ARCHS}
-V= 2.0.0
+V= 2.1.0
COMMENT= small and fast window manager
DISTNAME= icewm-${V}
EXTRACT_SUFX= .tar.lz
Index: distinfo
===
RCS file: /cvs/ports/x11/icewm/distinfo,v
retrieving revision 1.26
diff -u -p -u -p -r1.26 distinfo
--- distinfo29 Dec 2020 10:47:00 - 1.26
+++ distinfo23 Jan 2021 06:49:03 -
@@ -1,2 +1,2 @@
-SHA256 (icewm-2.0.0.tar.lz) = RHgXK5Nvf33PwhIL6NjxU/11WTO/mLjpjj6uUMQUk5w=
-SIZE (icewm-2.0.0.tar.lz) = 1694653
+SHA256 (icewm-2.1.0.tar.lz) = 6d4xXkb67Ic3mmC3LuXy2UBEF/yIhJ5XI195GnikC0o=
+SIZE (icewm-2.1.0.tar.lz) = 1696214
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: fcam...@cvs.openbsd.org 2021/01/23 13:35:02 Modified files: www/kore : Makefile distinfo www/kore/patches: patch-Makefile www/kore/pkg : PLIST Log message: Update kore to 4.1.0.
Re: [NEW] graphics/libspiro 20200505
On Sat, Jan 23, 2021 at 01:38:04AM -0700, Anthony J. Bentley wrote: > On Sun, Jan 17, 2021 at 4:46 AM Alessandro De Laurenzis > wrote: > > A year ago there has been an attempt to import this library (see [1]). > > At that time the port was put "on-hold" since there were 2 issues in the > > test suite; upstream has closed both as "resolved" (see [2] and [3]) and > > I can confirm that now all tests pass on amd64 (it would be better to > > double-check on spark64 too, since kurt@ reported similar issues there). > > > > W.r.t. Frederic's port, in the attached one I updated the version to > > 20200505, added PKGNAME and WRKDIST variables into the Makefile (plus a > > comment explaining the reason why gnu LIBTOOL is used) and changed a bit > > the formatting in DESCR (also making more evident the attribution to the > > original author). > > > > I need this port to update graphics/ipe to the latest release, since the > > distribution no more includes spiro's sources. > > > > Hope it can be imported now. > > ok bentley@ > > Frederic, do you still want to be MAINTAINER? OK fcambus@ to import, with the MAINTAINER line removed or modified in case Alessandro wants to take maintainership.
Re: tdb: split py2 bindings into -python package
On 2021/01/23 21:11, Klemens Nanni wrote: > Yes, `make update-plist package' gave me packages for all of them > without any PLIST changes when I had tdb-1.3.18p0 installed without > having tdb-python-1.3.18 installed. hmm, shouldn't that just be called "py-tdb"? that will leave things open to adding a py3 flavour too. > -@conflict samba-<3.5.0 I see that one was dropped, but it was from OpenBSD 4.8 and there have been flag days since then so that's ok, there is no way somebody could upgrade directly from there.
Re: [sparc64] Fix x11/spectrwm runtime
Someone who decides to use pledge in a program must evaluate the code paths that the program _and any libraries that it uses_ might take in various conditions, and set the pledge appropriately. Additionally they will need to review future updates to those libraries and adjust as needed.
Re: tdb: split py2 bindings into -python package
On Sat, Jan 23, 2021 at 05:58:14PM +0100, Jeremie Courreges-Anglas wrote:
> > net/netatalk3
> > mail/neomutt
> > mail/fdm
> > audio/rhythmbox
> > audio/pulseaudio
>
> Do those ports build and package without py-tdb installed? That's the
> main thing to check.
Yes, `make update-plist package' gave me packages for all of them
without any PLIST changes when I had tdb-1.3.18p0 installed without
having tdb-python-1.3.18 installed.
> LGTM so far, but consumers need a REVISION bump because of the pkgpath
> change.
Right, thanks.
I've also added a `@conflict tdb-<1.3.18p0' marker to PLIST-python since
old tdb and new tdb-python contain the same files.
Strangely enough, this doesn't seem to make a difference since with and
without the conflict marker, pkg_add always displays the same warning
(as if duplicate files are checked before conflict markers or so...):
$ pkg_info -m | grep tdb
tdb-1.3.18 trivial database library
$ doas pkg_add -Dunsigned ./tdb-python-1.3.18.tgz
Collision in tdb-python-1.3.18: the following files already exist
...
Feedback? OK?
Index: databases/tdb/Makefile
===
RCS file: /cvs/ports/databases/tdb/Makefile,v
retrieving revision 1.32
diff -u -p -r1.32 Makefile
--- databases/tdb/Makefile 14 Mar 2020 15:35:29 - 1.32
+++ databases/tdb/Makefile 23 Jan 2021 13:46:25 -
@@ -1,9 +1,15 @@
# $OpenBSD: Makefile,v 1.32 2020/03/14 15:35:29 kn Exp $
-COMMENT= trivial database library
+COMMENT-main= trivial database library
+COMMENT-python=Python ${MODPY_VERSION} bindings for tdb
# Keep in sync with the version bundled in net/samba
-DISTNAME= tdb-1.3.18
+V= 1.3.18
+DISTNAME= tdb-${V}
+PKGNAME-main= tdb-${V}
+REVISION-main= 0
+PKGNAME-python=tdb-python-${V}
+MULTI_PACKAGES=-main -python
# 0750 on Makefile and other files breaks update-patches with PORTS_PRIVSEP=Yes
FIX_EXTRACT_PERMISSIONS= Yes
@@ -19,7 +25,8 @@ MAINTAINER= Jeremie Courreges-Anglas https://download.samba.org/pub/tdb/
@@ -32,7 +39,8 @@ MODPY_ADJ_FILES= buildtools/bin/waf
BUILD_DEPENDS= textproc/docbook-xsl \
textproc/libxslt
-LIB_DEPENDS= ${MODPY_LIB_DEPENDS}
+LIB_DEPENDS-python=${BUILD_PKGPATH} \
+ ${MODPY_LIB_DEPENDS}
WAF_ARGS= -v -j ${MAKE_JOBS}
MAKE_FLAGS=WAF_ARGS="${WAF_ARGS}"
Index: databases/tdb/pkg/DESCR
===
RCS file: databases/tdb/pkg/DESCR
diff -N databases/tdb/pkg/DESCR
--- databases/tdb/pkg/DESCR 28 Jul 2007 21:37:26 - 1.1.1.1
+++ /dev/null 1 Jan 1970 00:00:00 -
@@ -1,4 +0,0 @@
-TDB is a Trivial Database. In concept, it is very much like GDBM, and
-BSD's DB except that it allows multiple simultaneous writers and uses
-locking internally to keep writers from trampling on each other. TDB is
-also extremely small.
Index: databases/tdb/pkg/DESCR-main
===
RCS file: databases/tdb/pkg/DESCR-main
diff -N databases/tdb/pkg/DESCR-main
--- /dev/null 1 Jan 1970 00:00:00 -
+++ databases/tdb/pkg/DESCR-main28 Jul 2007 21:37:26 -
@@ -0,0 +1,4 @@
+TDB is a Trivial Database. In concept, it is very much like GDBM, and
+BSD's DB except that it allows multiple simultaneous writers and uses
+locking internally to keep writers from trampling on each other. TDB is
+also extremely small.
Index: databases/tdb/pkg/DESCR-python
===
RCS file: databases/tdb/pkg/DESCR-python
diff -N databases/tdb/pkg/DESCR-python
--- /dev/null 1 Jan 1970 00:00:00 -
+++ databases/tdb/pkg/DESCR-python 23 Jan 2021 13:47:51 -
@@ -0,0 +1 @@
+Python ${MODPY_VERSION} bindings for tdb.
Index: databases/tdb/pkg/PLIST
===
RCS file: databases/tdb/pkg/PLIST
diff -N databases/tdb/pkg/PLIST
--- databases/tdb/pkg/PLIST 4 Dec 2019 00:14:45 - 1.10
+++ /dev/null 1 Jan 1970 00:00:00 -
@@ -1,16 +0,0 @@
-@comment $OpenBSD: PLIST,v 1.10 2019/12/04 00:14:45 jca Exp $
-@conflict samba-<3.5.0
-@bin bin/tdbbackup
-@bin bin/tdbdump
-@bin bin/tdbrestore
-@bin bin/tdbtool
-include/tdb.h
-@lib lib/libtdb.so.${LIBtdb_VERSION}
-lib/pkgconfig/tdb.pc
-lib/python${MODPY_VERSION}/site-packages/_tdb_text.py
-lib/python${MODPY_VERSION}/site-packages/_tdb_text.pyc
-@so lib/python${MODPY_VERSION}/site-packages/tdb.so
-@man man/man8/tdbbackup.8
-@man man/man8/tdbdump.8
-@man man/man8/tdbrestore.8
-@man man/man8/tdbtool.8
Index: databases/tdb/pkg/PLIST-main
===
RCS file: databases/tdb/pkg/PLIST-main
diff -N databases/tdb/pkg/PLIST-main
--- /dev/null 1 Jan 1970 00:00:00 -
+++ databases/tdb/pkg/PLIST-main23 Jan 2021 13:44:01 -
@@
Re: New: Ruby 3.0.0
El 2021-01-11 22:46, Jeremy Evans escribió: Install the package, but be aware you should be running -current, not 6.8. Running of -current packages on 6.8 is not supported. Thanks, Jeremy I tried on current on amd64, it compiled fine, and running `make test` produced 24 failing cases (I'm attaching a file with the result). Finally, I also could compile on 6.8 on amd64 --I had to remove other versions of ruby before. Running `make test` produces 24 failing cases (result attached). Thank you. -- Dios, gracias por tu amor infinito. -- Vladimir Támara Patiño. http://vtamara.pasosdeJesus.org/ http://www.pasosdejesus.org/dominio_publico_colombia.html===> Regression tests for ruby-3.0.0 cd /usr/ports/pobj/ruby-3.0.0/ruby-3.0.0 && make check BASERUBY = echo executable host ruby is required. use --with-baseruby option.; false CC = cc -fdeclspec LD = ld LDSHARED = cc -fdeclspec -shared CFLAGS = -O2 -pipe -g -fPIC XCFLAGS = -D_FORTIFY_SOURCE=2 -fstack-protector-strong -fno-strict-overflow -fvisibility=hidden -DRUBY_EXPORT -I. -I.ext/include/x86_64-openbsd -I./include -I. -I./enc/unicode/12.1.0 CPPFLAGS = -DOPENSSL_NO_STATIC_ENGINE -I/usr/local/include DLDFLAGS = -L/usr/local/lib -fstack-protector-strong SOLIBS = -lz -pthread -lgmp -lm LANG = es_CO.UTF-8 LC_ALL = LC_CTYPE = MFLAGS = OpenBSD clang version 10.0.1 Target: amd64-unknown-openbsd6.8 Thread model: posix InstalledDir: /usr/bin : > revision.tmp ./tool/ifchange "--timestamp=./.revision.time" "./revision.h" revision.tmp ./revision.h unchanged ./miniruby -I./lib -I. -I.ext/common ./enc/make_encmake.rb --builtin-encs="enc/ascii.o enc/us_ascii.o enc/unicode.o enc/utf_8.o" --builtin-transes="enc/trans/newline.o" --module enc.mk make -f enc.mk V="1" UNICODE_HDR_DIR="./enc/unicode/12.1.0" RUBY="./miniruby -I./lib -I. -I.ext/common " MINIRUBY="./miniruby -I./lib -I. -I.ext/common " srcs ./miniruby -I./lib -I. -I.ext/common ./tool/generic_erb.rb -c -o transdb.h ./template/transdb.h.tmpl ./enc/trans enc/trans transdb.h unchanged mkdir -p ext ./miniruby -I./lib -I. -I.ext/common ./tool/generic_erb.rb -o ext/configure-ext.mk -c ./template/configure-ext.mk.tmpl --srcdir="." --miniruby="./miniruby -I./lib -I. -I.ext/common " --script-args='--dest-dir="" --extout=".ext" --mflags=" " --make-flags=" "' ext/configure-ext.mk unchanged make -f ext/configure-ext.mkV=1 EXTSTATIC= gnumake= MINIRUBY="./miniruby -I./lib -I. -I.ext/common " EXTLDFLAGS="" srcdir="." ./miniruby -I./lib -I. -I.ext/common ./ext/extmk.rb --make='make' --command-output=ext/-test-/exts.mk --dest-dir="" --extout=".ext" --mflags=" " --make-flags=" " --gnumake= --extflags="" --make-flags="MINIRUBY='./miniruby -I./lib -I. -I.ext/common '" --extstatic -- configure ext/-test- ./miniruby -I./lib -I. -I.ext/common ./ext/extmk.rb --make='make' --command-output=ext/bigdecimal/exts.mk --dest-dir="" --extout=".ext" --mflags=" " --make-flags=" " --gnumake= --extflags="" --make-flags="MINIRUBY='./miniruby -I./lib -I. -I.ext/common '" --extstatic -- configure ext/bigdecimal ./miniruby -I./lib -I. -I.ext/common ./ext/extmk.rb --make='make' --command-output=ext/cgi/exts.mk --dest-dir="" --extout=".ext" --mflags=" " --make-flags=" " --gnumake= --extflags="" --make-flags="MINIRUBY='./miniruby -I./lib -I. -I.ext/common '" --extstatic -- configure ext/cgi ./miniruby -I./lib -I. -I.ext/common ./ext/extmk.rb --make='make' --command-output=ext/continuation/exts.mk --dest-dir="" --extout=".ext" --mflags=" " --make-flags=" " --gnumake= --extflags="" --make-flags="MINIRUBY='./miniruby -I./lib -I. -I.ext/common '" --extstatic -- configure ext/continuation ./miniruby -I./lib -I. -I.ext/common ./ext/extmk.rb --make='make' --command-output=ext/coverage/exts.mk --dest-dir="" --extout=".ext" --mflags=" " --make-flags=" " --gnumake= --extflags="" --make-flags="MINIRUBY='./miniruby -I./lib -I. -I.ext/common '" --extstatic -- configure ext/coverage ./miniruby -I./lib -I. -I.ext/common ./ext/extmk.rb --make='make' --command-output=ext/date/exts.mk --dest-dir="" --extout=".ext" --mflags=" " --make-flags=" " --gnumake= --extflags="" --make-flags="MINIRUBY='./miniruby -I./lib -I. -I.ext/common '" --extstatic -- configure ext/date ./miniruby -I./lib -I. -I.ext/common ./ext/extmk.rb --make='make' --command-output=ext/dbm/exts.mk --dest-dir="" --extout=".ext" --mflags=" " --make-flags=" " --gnumake= --extflags="" --make-flags="MINIRUBY='./miniruby -I./lib -I. -I.ext/common '" --extstatic -- configure ext/dbm ./miniruby -I./lib -I. -I.ext/common ./ext/extmk.rb --make='make' --command-output=ext/digest/exts.mk --dest-dir="" --extout=".ext" --mflags=" " --make-flags=" " --gnumake= --extflags="" --make-flags="MINIRUBY='./miniruby -I./lib -I. -I.ext/common '" --extstatic -- configure
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: st...@cvs.openbsd.org 2021/01/23 13:09:16 Modified files: x11/py-sip-qt5 : Makefile x11/py-sip-qt5/pkg: PLIST Log message: fix @conflict line
Re: [sparc64] Fix x11/spectrwm runtime
> Instead of allowing wpath and catching it again with unveil, wouldn't > it be worth thinking about a pledge promise that allows X font cache > updates? That is ridiculous.
Re: [sparc64] Fix x11/spectrwm runtime
Sebastien Marie wrote: > On Sat, Jan 23, 2021 at 07:14:33PM +0100, Stefan Hagen wrote: >> Hi, >> >> Spectrwm on Sparc64 wants the wpath pledge: >> >> 70801 spectrwm CALL open(0x7904d18380,0x10002) >> 70801 spectrwm NAMI >> "/var/cache/fontconfig//7908e75dfa020c169504380270e5263a-be64.cache-7" >> 70801 spectrwm PLDG open, "wpath", errno 1 Operation not permitted >> 70801 spectrwm PSIG SIGABRT SIG_DFL >> >> I've sent the fix upstream and it got merged already. >> Meanwhile, here is the fixed port. >> >> Changes: >> - added wpath pledge where needed >> - added revision > > I am a bit unsure about adding "wpath" in promises. Usually when > fontconfig write is involved, it means the cache is out of sync (and > it is odd it is happening for the system cache). If I didn't mess > myself, I recall about something like that previously. > > If adding "wpath" is really required, it would be interesting to use > also unveil to restrict the promise added. You're right. I can reproduce it on amd64 now: If I fiddle with my font paths and then (re)start X, spectrwm crashes with a wpath violation on amd64 too. This is something that can happen with any X application... Instead of allowing wpath and catching it again with unveil, wouldn't it be worth thinking about a pledge promise that allows X font cache updates? There is still a difference. On amd64, I can start another WM or an xterm and on the next start spectrwm works. The same does not work on the sparc64 machine. I don't know what fontconfig is doing there. It looks like the font cache is always out of sync here. Best Regards, Stefan
[NEW] multimedia/qnapi
hi, I've prepared a port for qnapi, it's an app for downloading movie subtitles. It depends on libmediainfo, which is not being installed by multimedia/mediainfo, so I needed to split multimedia/mediainfo into following: devel/libzen multimedia/libmediainfo multimedia/mediainfo Please let me know if anything needs to be corrected -- Adan Naismith libzen.tar.gz Description: Binary data qnapi.tar.gz Description: Binary data mediainfo.diff Description: Binary data libmediainfo.tar.gz Description: Binary data
Re: [sparc64] Fix x11/spectrwm runtime
On Sat, Jan 23, 2021 at 07:14:33PM +0100, Stefan Hagen wrote: > Hi, > > Spectrwm on Sparc64 wants the wpath pledge: > > 70801 spectrwm CALL open(0x7904d18380,0x10002) > 70801 spectrwm NAMI > "/var/cache/fontconfig//7908e75dfa020c169504380270e5263a-be64.cache-7" > 70801 spectrwm PLDG open, "wpath", errno 1 Operation not permitted > 70801 spectrwm PSIG SIGABRT SIG_DFL > > I've sent the fix upstream and it got merged already. > Meanwhile, here is the fixed port. > > Changes: > - added wpath pledge where needed > - added revision I am a bit unsure about adding "wpath" in promises. Usually when fontconfig write is involved, it means the cache is out of sync (and it is odd it is happening for the system cache). If I didn't mess myself, I recall about something like that previously. If adding "wpath" is really required, it would be interesting to use also unveil to restrict the promise added. Thanks. -- Sebastien Marie
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: b...@cvs.openbsd.org2021/01/23 11:34:17 Modified files: x11/spectrwm : Makefile x11/spectrwm/patches: patch-spectrwm_c Log message: Add wpath pledge Found and fixed by Stefan Hagen . I changed the comment in the patch.
Re: [sparc64] Fix x11/spectrwm runtime
On Sat 23/01/2021 19:14, Stefan Hagen wrote: > Hi, > > Spectrwm on Sparc64 wants the wpath pledge: > > 70801 spectrwm CALL open(0x7904d18380,0x10002) > 70801 spectrwm NAMI > "/var/cache/fontconfig//7908e75dfa020c169504380270e5263a-be64.cache-7" > 70801 spectrwm PLDG open, "wpath", errno 1 Operation not permitted > 70801 spectrwm PSIG SIGABRT SIG_DFL > > I've sent the fix upstream and it got merged already. > Meanwhile, here is the fixed port. > > Changes: > - added wpath pledge where needed > - added revision Thanks! I will commit in a bit. I'm using spectrwm (on amd64) on a daily basis for some time now without seeing this. I'm wondering what Sparc64 is doing differently than amd64...
[sparc64] Fix x11/spectrwm runtime
Hi,
Spectrwm on Sparc64 wants the wpath pledge:
70801 spectrwm CALL open(0x7904d18380,0x10002)
70801 spectrwm NAMI
"/var/cache/fontconfig//7908e75dfa020c169504380270e5263a-be64.cache-7"
70801 spectrwm PLDG open, "wpath", errno 1 Operation not permitted
70801 spectrwm PSIG SIGABRT SIG_DFL
I've sent the fix upstream and it got merged already.
Meanwhile, here is the fixed port.
Changes:
- added wpath pledge where needed
- added revision
Maintainer on CC.
Best Regards,
Stefan
Index: x11/spectrwm/Makefile
===
RCS file: /cvs/ports/x11/spectrwm/Makefile,v
retrieving revision 1.35
diff -u -p -u -p -r1.35 Makefile
--- x11/spectrwm/Makefile 25 Jun 2020 11:54:19 - 1.35
+++ x11/spectrwm/Makefile 23 Jan 2021 17:56:59 -
@@ -8,6 +8,8 @@ GH_PROJECT= spectrwm
GH_TAGNAME=SPECTRWM_${V:S/./_/g}
DISTNAME= ${GH_PROJECT}-${V}
+REVISION= 0
+
SHARED_LIBS= swmhack 1.0
CATEGORIES=x11
Index: x11/spectrwm/patches/patch-spectrwm_c
===
RCS file: /cvs/ports/x11/spectrwm/patches/patch-spectrwm_c,v
retrieving revision 1.15
diff -u -p -u -p -r1.15 patch-spectrwm_c
--- x11/spectrwm/patches/patch-spectrwm_c 18 Jun 2020 09:18:39 -
1.15
+++ x11/spectrwm/patches/patch-spectrwm_c 23 Jan 2021 17:56:59 -
@@ -1,5 +1,7 @@
$OpenBSD: patch-spectrwm_c,v 1.15 2020/06/18 09:18:39 gonzalo Exp $
+Fix runtime crash on sparc64 (needs wpath pledge)
+
Index: spectrwm.c
--- spectrwm.c.orig
+++ spectrwm.c
@@ -12,3 +14,30 @@ Index: spectrwm.c
#endif
char **start_argv;
+@@ -13605,7 +13605,7 @@ main(int argc, char *argv[])
+ if (setlocale(LC_CTYPE, "") == NULL || setlocale(LC_TIME, "") == NULL)
+ warnx("no locale support");
+
+- if (pledge("stdio proc exec rpath getpw dns inet unix", NULL) == -1)
++ if (pledge("stdio proc exec rpath getpw dns inet unix wpath", NULL) ==
-1)
+ err(1, "pledge");
+
+ /* handle some signals */
+@@ -13625,7 +13625,7 @@ main(int argc, char *argv[])
+ if ((display = XOpenDisplay(0)) == NULL)
+ errx(1, "unable to open display");
+
+- if (pledge("stdio proc exec rpath getpw", NULL) == -1)
++ if (pledge("stdio proc exec rpath getpw wpath", NULL) == -1)
+ err(1, "pledge");
+
+ conn = XGetXCBConnection(display);
+@@ -13680,7 +13680,7 @@ main(int argc, char *argv[])
+ else
+ scan_config();
+
+- if (pledge("stdio proc exec rpath", NULL) == -1)
++ if (pledge("stdio proc exec rpath wpath", NULL) == -1)
+ err(1, "pledge");
+
+ validate_spawns();
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: rsadow...@cvs.openbsd.org 2021/01/23 11:10:39 Modified files: net/kdsoap : Makefile distinfo net/kdsoap/pkg : PLIST Removed files: net/kdsoap/patches: patch-CMakeLists_txt Log message: Update kdsoap to 1.10.0
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: rsadow...@cvs.openbsd.org 2021/01/23 11:10:37 Modified files: devel/kdiff3 : Makefile distinfo devel/kdiff3/pkg: PLIST Log message: Update kdiff3 to 1.8.5
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: rsadow...@cvs.openbsd.org 2021/01/23 11:10:30 Modified files: x11/kde-applications: Makefile Makefile.inc x11/kde-applications/akonadi: Makefile distinfo x11/kde-applications/akonadi/patches: patch-src_server_storage_datastore_cpp x11/kde-applications/akonadi/pkg: PLIST x11/kde-applications/akonadi-calendar: Makefile distinfo x11/kde-applications/akonadi-calendar-tools: Makefile distinfo x11/kde-applications/akonadi-calendar-tools/pkg: PLIST x11/kde-applications/akonadi-contacts: Makefile distinfo x11/kde-applications/akonadi-contacts/pkg: PLIST x11/kde-applications/akonadi-import-wizard: Makefile distinfo x11/kde-applications/akonadi-import-wizard/pkg: PLIST x11/kde-applications/akonadi-mime: Makefile distinfo x11/kde-applications/akonadi-notes: distinfo x11/kde-applications/akonadi-notes/pkg: PLIST x11/kde-applications/akonadi-search: distinfo x11/kde-applications/akonadiconsole: Makefile distinfo x11/kde-applications/akregator: Makefile distinfo x11/kde-applications/analitza: Makefile distinfo x11/kde-applications/ark: Makefile distinfo x11/kde-applications/artikulate: Makefile distinfo x11/kde-applications/artikulate/pkg: PLIST x11/kde-applications/audiocd-kio: distinfo x11/kde-applications/audiocd-kio/pkg: PLIST x11/kde-applications/baloo-widgets: distinfo x11/kde-applications/blinken: distinfo x11/kde-applications/blinken/pkg: PLIST x11/kde-applications/bomber: Makefile distinfo x11/kde-applications/bovo: Makefile distinfo x11/kde-applications/calendarsupport: Makefile distinfo x11/kde-applications/cantor: Makefile distinfo x11/kde-applications/cantor/pkg: PLIST x11/kde-applications/cervisia: distinfo x11/kde-applications/dolphin: distinfo x11/kde-applications/dolphin/pkg: PLIST x11/kde-applications/dolphin-plugins: distinfo x11/kde-applications/dolphin-plugins/pkg: PLIST x11/kde-applications/dragon: distinfo x11/kde-applications/eventviews: Makefile distinfo x11/kde-applications/ffmpegthumbs: Makefile distinfo x11/kde-applications/ffmpegthumbs/pkg: PLIST x11/kde-applications/filelight: Makefile distinfo x11/kde-applications/granatier: Makefile distinfo x11/kde-applications/grantlee-editor: Makefile distinfo x11/kde-applications/grantleetheme: distinfo x11/kde-applications/gwenview: distinfo x11/kde-applications/incidenceeditor: Makefile distinfo x11/kde-applications/juk: distinfo x11/kde-applications/kaddressbook: Makefile distinfo x11/kde-applications/kaddressbook/pkg: PLIST x11/kde-applications/kajongg: distinfo x11/kde-applications/kajongg/pkg: PLIST x11/kde-applications/kalarm: Makefile distinfo x11/kde-applications/kalarm/pkg: PLIST x11/kde-applications/kalarmcal: Makefile distinfo x11/kde-applications/kalarmcal/pkg: PLIST x11/kde-applications/kalgebra: Makefile distinfo x11/kde-applications/kalgebra/pkg: PLIST x11/kde-applications/kalzium: distinfo x11/kde-applications/kalzium/pkg: PLIST x11/kde-applications/kamera: distinfo x11/kde-applications/kanagram: Makefile distinfo x11/kde-applications/kapman: Makefile distinfo x11/kde-applications/kapptemplate: distinfo x11/kde-applications/kate: distinfo x11/kde-applications/katomic: Makefile distinfo x11/kde-applications/katomic/pkg: PLIST x11/kde-applications/kbackup: distinfo x11/kde-applications/kbackup/pkg: PLIST x11/kde-applications/kblackbox: Makefile distinfo x11/kde-applications/kblocks: Makefile distinfo x11/kde-applications/kblocks/pkg: PLIST x11/kde-applications/kbounce: Makefile distinfo x11/kde-applications/kbreakout: Makefile distinfo x11/kde-applications/kbruch: distinfo x11/kde-applications/kcachegrind: distinfo x11/kde-applications/kcalc: distinfo x11/kde-applications/kcalutils: distinfo x11/kde-applications/kcharselect: distinfo x11/kde-applications/kcolorchooser: distinfo x11/kde-applications/kcron: distinfo x11/kde-applications/kde-dev-scripts: distinfo x11/kde-applications/kde-dev-utils: distinfo x11/kde-applications/kdebugsettings: distinfo x11/kde-applications/kdeedu-data: distinfo x11/kde-applications/kdegraphics-mobipocket: distinfo x11/kde-applications/kdegraphics-thumbnailers: distinfo x11/kde-applications/kdenetwork-filesharing: Makefile
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: rsadow...@cvs.openbsd.org 2021/01/23 11:09:56 Modified files: devel/kf5 : kf5.port.mk devel/kf5/attica: distinfo devel/kf5/baloo: Makefile distinfo devel/kf5/bluez-qt: distinfo devel/kf5/breeze-icons: distinfo devel/kf5/breeze-icons/pkg: PLIST devel/kf5/extra-cmake-modules: distinfo devel/kf5/extra-cmake-modules/patches: patch-kde-modules_KDECompilerSettings_cmake devel/kf5/extra-cmake-modules/pkg: PLIST devel/kf5/frameworkintegration: distinfo devel/kf5/kactivities: Makefile distinfo devel/kf5/kactivities-stats: Makefile distinfo devel/kf5/kapidox: distinfo devel/kf5/karchive: distinfo devel/kf5/kauth: distinfo devel/kf5/kbookmarks: distinfo devel/kf5/kcalendarcore: distinfo devel/kf5/kcmutils: Makefile distinfo devel/kf5/kcodecs: distinfo devel/kf5/kcompletion: Makefile distinfo devel/kf5/kconfig: Makefile distinfo devel/kf5/kconfigwidgets: Makefile distinfo devel/kf5/kconfigwidgets/pkg: PLIST devel/kf5/kcontacts: distinfo devel/kf5/kcoreaddons: distinfo devel/kf5/kcrash: distinfo devel/kf5/kdav : distinfo devel/kf5/kdbusaddons: distinfo devel/kf5/kdeclarative: Makefile distinfo devel/kf5/kded : distinfo devel/kf5/kdelibs4support: distinfo devel/kf5/kdesignerplugin: distinfo devel/kf5/kdesu: distinfo devel/kf5/kdewebkit: distinfo devel/kf5/kdnssd: distinfo devel/kf5/kdoctools: distinfo devel/kf5/kemoticons: distinfo devel/kf5/kfilemetadata: distinfo devel/kf5/kglobalaccel: distinfo devel/kf5/kguiaddons: distinfo devel/kf5/kholidays: distinfo devel/kf5/khtml: distinfo devel/kf5/ki18n: distinfo devel/kf5/kiconthemes: Makefile distinfo devel/kf5/kidletime: distinfo devel/kf5/kimageformats: distinfo devel/kf5/kimageformats/pkg: PLIST devel/kf5/kinit: distinfo devel/kf5/kio : Makefile distinfo devel/kf5/kio/pkg: PLIST devel/kf5/kirigami2: Makefile distinfo devel/kf5/kirigami2/pkg: PLIST devel/kf5/kitemmodels: distinfo devel/kf5/kitemviews: Makefile distinfo devel/kf5/kjobwidgets: distinfo devel/kf5/kjs : distinfo devel/kf5/kjsembed: distinfo devel/kf5/kmediaplayer: distinfo devel/kf5/knewstuff: Makefile distinfo devel/kf5/knewstuff/pkg: PLIST devel/kf5/knotifications: distinfo devel/kf5/knotifyconfig: distinfo devel/kf5/kpackage: distinfo devel/kf5/kparts: distinfo devel/kf5/kpeople: distinfo devel/kf5/kplotting: distinfo devel/kf5/kpty : distinfo devel/kf5/kross: distinfo devel/kf5/krunner: Makefile distinfo devel/kf5/kservice: distinfo devel/kf5/ktexteditor: Makefile distinfo devel/kf5/ktextwidgets: distinfo devel/kf5/kunitconversion: distinfo devel/kf5/kwallet: distinfo devel/kf5/kwidgetsaddons: Makefile distinfo devel/kf5/kwindowsystem: distinfo devel/kf5/kxmlgui: distinfo devel/kf5/kxmlrpcclient: distinfo devel/kf5/oxygen-icons: distinfo devel/kf5/oxygen-icons/pkg: PLIST devel/kf5/plasma-framework: Makefile distinfo devel/kf5/prison: Makefile distinfo devel/kf5/purpose: distinfo devel/kf5/purpose/pkg: PLIST devel/kf5/qqc2-desktop-style: Makefile distinfo devel/kf5/solid: distinfo devel/kf5/sonnet: distinfo devel/kf5/syndication: distinfo devel/kf5/syntax-highlighting: distinfo devel/kf5/threadweaver: distinfo Removed files: devel/kf5/knewstuff/patches: patch-src_core_cache_cpp patch-src_core_cache_h devel/kf5/plasma-framework/patches: patch-src_desktoptheme_breeze_opaque_widgets_panel-background_svg patch-tests_frames_qml devel/kf5/syntax-highlighting/patches: patch-src_indexer_katehighlightingindexer_cpp Log message: Update KDE Frameworks to 5.78.0 https://kde.org/announcements/kde-frameworks-5.78.0/
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: t...@cvs.openbsd.org2021/01/23 10:57:03 Modified files: games/vkquake : Makefile distinfo Log message: update to vkquake 1.05.2
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: t...@cvs.openbsd.org2021/01/23 10:56:27 Modified files: graphics/mojoshader: Makefile distinfo Log message: update to mojoshader commit 1320; tested with many FNA games
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: t...@cvs.openbsd.org2021/01/23 10:52:00 Modified files: devel/sdl : Makefile devel/sdl/patches: patch-src_joystick_bsd_SDL_sysjoystick_c devel/sdl/pkg : PLIST Log message: use ujoy(4) for joystick devices to unbreak joystick support tested with dxx-rebirth. Take MAINTAINER while here. ok mglocker@
Re: Add MODOCAML_RUNDEP to ocaml.port.mk
On Sat 23/01/2021 18:22, Jeremie Courreges-Anglas wrote:
> On Sat, Jan 23 2021, Stuart Henderson wrote:
> > On 2021/01/23 13:33, Jeremie Courreges-Anglas wrote:
> >> On Fri, Jan 22 2021, Bjorn Ketelaars wrote:
> >> >
> >> > Don't think so. If we are building on a non-native arch we want to make
> >> > sure that lang/ocaml is added as BDEP and RDEP, independent how
> >> > MODOCAML_RUNDEP or MODOCAML_BUILDDEP are used in a Makefile.
> >> > [...]
> >>
> >> An OCaml port probably needs lang/ocaml at build time on *all archs*,
> >> I don't see a reason to introduce a difference between native and
> >> non-native archs *at build time*, nor do I see a good reason to ignore
> >> what a port specifies.
> >
> > Agreed, variable build dependencies per-arch sounds like it's asking for
> > trouble.
> >
> >> | # Assume that we want to automatically add ocaml to BUILD_DEPENDS
> >> | -# and RUN_DEPENDS unless the port specifically requests not to.
> >> | +# unless the port specifically requests not to.
> >> | MODOCAML_BUILDDEP?= Yes
> >> | +# Same for RUN_DEPENDS, but MODOCAML_RUN_DEPENDS can take three values:
> >> | +# Yes, No or if-not-native (translates to Yes if native-code is
> >> unsupported)
> >> | MODOCAML_RUNDEP?= Yes
> >> |
> >> | .if ${NO_BUILD:L} == no && ${MODOCAML_BUILDDEP:L} == yes
> >> | BUILD_DEPENDS+= ${MODOCAML_BUILD_DEPENDS}
> >> | .endif
> >
> > I'm not totally objecting to MODOCAML_BUILDDEP=no but I'm not sure
> > there's a use for it. I'd be tempted to leave it out for now. If we
> > do that and someone does comes up with a port that wants to disable
> > build dep's later, they could just change ocaml.port.mk at the same
> > time, no need to hack around it.
> >
> > Apart from anything else port-modules(5) is already hard to read and
> > I'd be happy to avoid adding more :)
> >
> > I think MODGO_BUILDDEP can be removed from go.port.mk too, nothing
> > uses it and I don't really see how it could..
> >
> > It's used quite a lot for python, and a bit for PHP though possibly
> > not enough - this discussion made me wonder if I should change that to
> > No by default for PHP. But those are quite different to the case of
> > go or ocaml.
>
> By default I'd prefer to have all modules behave similarly, but I can
> understand how it doesn't make sense in some situations.
>
> >> | +.if ${MODOCAML_RUNDEP:L} == if-not-native && ${MODOCAML_NATIVE} == No
> >> | +MODOCAML_RUNDEP = Yes
> >> | +.endif
> >> | .if ${MODOCAML_RUNDEP:L} == yes
> >> | RUN_DEPENDS+= ${MODOCAML_RUN_DEPENDS}
> >> | .endif
> >>
> >> This implements the three choice logic suggested by sthen, doesn't
> >> affect current defaults, and only cares about the runtime dep.
> >> I hope that "if-not-native" is an improvement over "nonative".
> >
> > love the "if-not-native" wording, that's perfect :)
>
> Great. Here's the latest, simpler diff. No more MODOCAML_BUILDDEP, no
> more MODOCAML_*_DEPENDS either (after all, their content was obvious).
>
> Bjorn, still ok? Stuart, others?
Yes, still OK.
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: t...@cvs.openbsd.org2021/01/23 10:47:43 Modified files: devel/sdl2 : Makefile devel/sdl2/patches: patch-src_joystick_bsd_SDL_bsdjoystick_c Added files: devel/sdl2/patches: patch-src_joystick_SDL_gamecontrollerdb_h Removed files: devel/sdl2/patches: patch-src_joystick_SDL_gamecontroller_c Log message: enable gamecontroller GUID detection and GUID-based mapping this makes prior workaround in SDL_gamecontroller.c obsolete that used SDL_GAMECONTROLLERCONFIG environment variable and a fallback mapping; so this is removed now. tested with XBox 360/One, Logitech F310/Dual Action by me testing with NEXT SNES controller and ok brynet@
Re: Add MODOCAML_RUNDEP to ocaml.port.mk
On Sat, Jan 23 2021, Stuart Henderson wrote:
> On 2021/01/23 13:33, Jeremie Courreges-Anglas wrote:
>> On Fri, Jan 22 2021, Bjorn Ketelaars wrote:
>> >
>> > Don't think so. If we are building on a non-native arch we want to make
>> > sure that lang/ocaml is added as BDEP and RDEP, independent how
>> > MODOCAML_RUNDEP or MODOCAML_BUILDDEP are used in a Makefile.
>> > [...]
>>
>> An OCaml port probably needs lang/ocaml at build time on *all archs*,
>> I don't see a reason to introduce a difference between native and
>> non-native archs *at build time*, nor do I see a good reason to ignore
>> what a port specifies.
>
> Agreed, variable build dependencies per-arch sounds like it's asking for
> trouble.
>
>> | # Assume that we want to automatically add ocaml to BUILD_DEPENDS
>> | -# and RUN_DEPENDS unless the port specifically requests not to.
>> | +# unless the port specifically requests not to.
>> | MODOCAML_BUILDDEP?= Yes
>> | +# Same for RUN_DEPENDS, but MODOCAML_RUN_DEPENDS can take three values:
>> | +# Yes, No or if-not-native (translates to Yes if native-code is
>> unsupported)
>> | MODOCAML_RUNDEP?= Yes
>> |
>> | .if ${NO_BUILD:L} == no && ${MODOCAML_BUILDDEP:L} == yes
>> | BUILD_DEPENDS+= ${MODOCAML_BUILD_DEPENDS}
>> | .endif
>
> I'm not totally objecting to MODOCAML_BUILDDEP=no but I'm not sure
> there's a use for it. I'd be tempted to leave it out for now. If we
> do that and someone does comes up with a port that wants to disable
> build dep's later, they could just change ocaml.port.mk at the same
> time, no need to hack around it.
>
> Apart from anything else port-modules(5) is already hard to read and
> I'd be happy to avoid adding more :)
>
> I think MODGO_BUILDDEP can be removed from go.port.mk too, nothing
> uses it and I don't really see how it could..
>
> It's used quite a lot for python, and a bit for PHP though possibly
> not enough - this discussion made me wonder if I should change that to
> No by default for PHP. But those are quite different to the case of
> go or ocaml.
By default I'd prefer to have all modules behave similarly, but I can
understand how it doesn't make sense in some situations.
>> | +.if ${MODOCAML_RUNDEP:L} == if-not-native && ${MODOCAML_NATIVE} == No
>> | +MODOCAML_RUNDEP = Yes
>> | +.endif
>> | .if ${MODOCAML_RUNDEP:L} == yes
>> | RUN_DEPENDS+= ${MODOCAML_RUN_DEPENDS}
>> | .endif
>>
>> This implements the three choice logic suggested by sthen, doesn't
>> affect current defaults, and only cares about the runtime dep.
>> I hope that "if-not-native" is an improvement over "nonative".
>
> love the "if-not-native" wording, that's perfect :)
Great. Here's the latest, simpler diff. No more MODOCAML_BUILDDEP, no
more MODOCAML_*_DEPENDS either (after all, their content was obvious).
Bjorn, still ok? Stuart, others?
Index: ocaml.port.mk
===
RCS file: /cvs/ports/lang/ocaml/ocaml.port.mk,v
retrieving revision 1.32
diff -u -p -r1.32 ocaml.port.mk
--- ocaml.port.mk 3 Dec 2017 11:10:10 - 1.32
+++ ocaml.port.mk 23 Jan 2021 17:08:48 -
@@ -33,8 +33,20 @@ MODOCAML_OCAMLDOC?=ocamldoc
PKG_ARGS+=-Ddynlink=0
.endif
-RUN_DEPENDS += lang/ocaml
+# Assume that we want to automatically add ocaml to BUILD_DEPENDS.
BUILD_DEPENDS += lang/ocaml
+# Assume that we want to automatically add ocaml to RUN_DEPENDS.
+# Can take three values:
+# Yes, No or if-not-native (translates to Yes if native-code is unsupported)
+MODOCAML_RUNDEP?= Yes
+
+.if ${MODOCAML_RUNDEP:L} == if-not-native && ${MODOCAML_NATIVE} == No
+MODOCAML_RUNDEP = Yes
+.endif
+.if ${MODOCAML_RUNDEP:L} == yes
+RUN_DEPENDS+= lang/ocaml
+.endif
+
MAKE_ENV +=OCAMLFIND_DESTDIR=${DESTDIR}${TRUEPREFIX}/lib/ocaml \
OCAMLFIND_COMMANDS="ocamldoc=${MODOCAML_OCAMLDOC}"
--
jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF DDCC 0DFA 74AE 1524 E7EE
Re: [update] graphics/scrot 0.8 to 1.4
Stefan Hagen wrote:
> Stefan Hagen wrote:
>> Scrots new home:
>> https://github.com/resurrecting-open-source-projects/scrot
>
> It's probably relevant to say that this new upstream is also used
> by Debian, Arch and FreeBSD (I did not check others).
>
> Here is an updated patch with the following additions:
>
>+ added pledge similiar to solenes scrot update in 2019
>+ removed -g cflag
>+ subst /usr/X11R6 with ${X11BASE} in Makefile.am
I've sent a fix upstream to unbreak scrot on sparc64
https://github.com/resurrecting-open-source-projects/scrot/pull/64
The diff again with the fix included and sorry for the noise :/
Index: graphics/scrot/Makefile
===
RCS file: /cvs/ports/graphics/scrot/Makefile,v
retrieving revision 1.17
diff -u -p -u -p -r1.17 Makefile
--- graphics/scrot/Makefile 12 Jul 2019 20:47:10 - 1.17
+++ graphics/scrot/Makefile 23 Jan 2021 16:56:31 -
@@ -2,25 +2,29 @@
COMMENT= commandline screen capture util
-DISTNAME= scrot-0.8
-REVISION = 4
-CATEGORIES=graphics
+GH_ACCOUNT = resurrecting-open-source-projects
+GH_PROJECT = scrot
+GH_TAGNAME = 1.4
-HOMEPAGE= http://www.linuxbrit.co.uk/scrot/
+CATEGORIES = graphics
+
+HOMEPAGE=
https://github.com/resurrecting-open-source-projects/scrot
# BSD
PERMIT_PACKAGE=Yes
-WANTLIB= X11 Xext c freetype m z \
- giblib>=1 Imlib2>=1
-
-MASTER_SITES= http://www.linuxbrit.co.uk/downloads/
+# pledge
+WANTLIB = c m Imlib2 giblib X11 Xcomposite Xfixes
-LIB_DEPENDS=devel/giblib \
+LIB_DEPENDS = devel/giblib \
graphics/imlib2
-CONFIGURE_STYLE= gnu
+AUTOMAKE_VERSION = 1.16
+AUTOCONF_VERSION = 2.69
+
+AUTORECONF = sh autogen.sh
+CONFIGURE_STYLE= autoreconf
-FAKE_FLAGS+= docsdir=${PREFIX}/share/doc/scrot/
+BUILD_DEPENDS =devel/autoconf-archive
.include
Index: graphics/scrot/distinfo
===
RCS file: /cvs/ports/graphics/scrot/distinfo,v
retrieving revision 1.4
diff -u -p -u -p -r1.4 distinfo
--- graphics/scrot/distinfo 18 Jan 2015 03:14:14 - 1.4
+++ graphics/scrot/distinfo 23 Jan 2021 16:56:31 -
@@ -1,2 +1,2 @@
-SHA256 (scrot-0.8.tar.gz) = YT0c9STCtizjxl8SMupPBcfa8kjV6C/ypoksmAk5lPI=
-SIZE (scrot-0.8.tar.gz) = 74324
+SHA256 (scrot-1.4.tar.gz) = 4Z7sabzcJJkXxFInDhyPKBiAA7BSw1LiWZmygcsDUQw=
+SIZE (scrot-1.4.tar.gz) = 157779
Index: graphics/scrot/patches/patch-Makefile_am
===
RCS file: graphics/scrot/patches/patch-Makefile_am
diff -N graphics/scrot/patches/patch-Makefile_am
--- /dev/null 1 Jan 1970 00:00:00 -
+++ graphics/scrot/patches/patch-Makefile_am23 Jan 2021 16:56:31 -
@@ -0,0 +1,16 @@
+$OpenBSD$
+
+Index: Makefile.am
+--- Makefile.am.orig
Makefile.am
+@@ -31,8 +31,8 @@ AUTOMAKE_OPTIONS = 1.4 foreign
+ # A list of all the files in the current directory which can be regenerated
+ MAINTAINERCLEANFILES = Makefile.in
+
+-AM_LDFLAGS= -L/usr/X11R6/lib -L/usr/lib -L/usr/local/lib
+-AM_CPPFLAGS = -I/usr/X11R6/include \
++AM_LDFLAGS= -L${X11BASE}/lib -L/usr/lib -L/usr/local/lib
++AM_CPPFLAGS = -I${X11BASE}/include \
+ $(X_CFLAGS) -I$(prefix)/include -I$(includedir) -I.
+
+ man_MANS = man/scrot.1
Index: graphics/scrot/patches/patch-src_Makefile_am
===
RCS file: graphics/scrot/patches/patch-src_Makefile_am
diff -N graphics/scrot/patches/patch-src_Makefile_am
--- /dev/null 1 Jan 1970 00:00:00 -
+++ graphics/scrot/patches/patch-src_Makefile_am23 Jan 2021 16:56:31
-
@@ -0,0 +1,16 @@
+$OpenBSD$
+
+no need for debug symbols
+
+Index: src/Makefile.am
+--- src/Makefile.am.orig
src/Makefile.am
+@@ -28,7 +28,7 @@
+ MAINTAINERCLEANFILES = Makefile.in
+
+ AM_LDFLAGS= -L/usr/X11R6/lib
+-AM_CPPFLAGS = -g -O3 -Wall -I/usr/X11R6/include \
++AM_CPPFLAGS = -O3 -Wall -I/usr/X11R6/include \
+ $(X_CFLAGS) -I$(prefix)/include -I$(includedir) -I. \
+ -DPREFIX=\""$(prefix)"\" @GIBLIB_CFLAGS@
+ LIBOBJS = @LIBOBJS@
Index: graphics/scrot/patches/patch-src_Makefile_in
===
RCS file: graphics/scrot/patches/patch-src_Makefile_in
diff -N graphics/scrot/patches/patch-src_Makefile_in
--- graphics/scrot/patches/patch-src_Makefile_in8 Jul 2011 11:25:47
- 1.2
+++ /dev/null 1 Jan 1970 00:00:00 -
@@ -1,44 +0,0 @@
-$OpenBSD: patch-src_Makefile_in,v 1.2 2011/07/08 11:25:47 jasper Exp $
src/Makefile.in.orig Mon Jun 23 14:13:34 2003
-+++ src/Makefile.inFri Jul 8 13:22:30 2011
-@@ -73,13 +73,13 @@ VERSION = @VERSION@
-
-
Re: tdb: split py2 bindings into -python package
On Sat, Jan 23 2021, Klemens Nanni wrote:
> tdb depends on Python 2 for its bindings but the only port using them is
> net/samba; many other ports use tdb without Pyhton but still pull in
> Python 2.
>
> With -main and -python packages we can tell samba to also install the
> -python package to be happy such that all other ports depending on tdb
> can be installed without Python 2:
>
> net/netatalk3
> mail/neomutt
> mail/fdm
> audio/rhythmbox
> audio/pulseaudio
Do those ports build and package without py-tdb installed? That's the
main thing to check.
> I've added the `@pkgpath databases/tdb' marker to PLIST-main such that
> `pkg_add -U tdb' will happily upgrade, no quirks required here:
>
> Jan 23 14:48:52 eru pkg_add: Added tdb-1.3.18->1.3.18p0
>
> For samba I have not checked which of its subpackages actually uses the
> Python bindings do both of them now install the new subpackage, i.e.
> no effective change for them.
That's correct, -main and -ldb need it.
> Feedback? OK?
LGTM so far, but consumers need a REVISION bump because of the pkgpath
change.
--8<--
Create /usr/ports/packages/amd64/all/fdm-2.0p0.tgz
Creating package fdm-2.0p0
Error: change in plist
| Assuming the old and new builds were done correctly
| (fully up-to-date ports tree including relevant MODULES),
| then someone probably forgot to bump a REVISION.
| (see bsd.port.mk(5), PACKAGE_REPOSITORY)
--- /usr/ports/plist/amd64/fdm-2.0p0
+++ /usr/ports/plist/amd64/fdm-2.0p0-new
@@ -5,7 +5,7 @@
@arch amd64
+DESC
@sha lX1JyHmHesKNkHL6Od55WBveEuuLyYqvG+vHLtR1UrE=
-@depend databases/tdb:tdb->=1.2.7:tdb-1.3.18
+@depend databases/tdb,-main:tdb->=1.2.7:tdb-1.3.18p0
@depend devel/pcre:pcre-*:pcre-8.41p2
@wantlib c.96.0
@wantlib crypto.46.1
*** Error 1 in . (/usr/ports/infrastructure/mk/bsd.port.mk:2132
'/usr/ports/packages/amd64/all/fdm-2.0p0.tgz': @trap "cd /usr/ports/packages...)
*** Error 2 in . (/usr/ports/infrastructure/mk/bsd.port.mk:2613
'_internal-package': @case X${_DEPENDS_CACHE} in X) _DEPENDS_CACHE=$(/usr/b...)
*** Error 2 in . (/usr/ports/infrastructure/mk/bsd.port.mk:2592 'package':
@lock=fdm-2.0p0; export _LOCKS_HELD=" fdm-2.0p0"; /usr/bin/doas...)
*** Error 2 in /usr/ports/mail/fdm
(/usr/ports/infrastructure/mk/bsd.port.mk:3611 'repackage': @cd
/usr/ports/mail/fdm && PKGPATH=mail/fdm e...)
-->8--
> Index: databases/tdb/Makefile
> ===
> RCS file: /cvs/ports/databases/tdb/Makefile,v
> retrieving revision 1.32
> diff -u -p -r1.32 Makefile
> --- databases/tdb/Makefile14 Mar 2020 15:35:29 - 1.32
> +++ databases/tdb/Makefile23 Jan 2021 13:46:25 -
> @@ -1,9 +1,15 @@
> # $OpenBSD: Makefile,v 1.32 2020/03/14 15:35:29 kn Exp $
>
> -COMMENT= trivial database library
> +COMMENT-main=trivial database library
> +COMMENT-python= Python ${MODPY_VERSION} bindings for tdb
>
> # Keep in sync with the version bundled in net/samba
> -DISTNAME=tdb-1.3.18
> +V= 1.3.18
> +DISTNAME=tdb-${V}
> +PKGNAME-main=tdb-${V}
> +REVISION-main= 0
> +PKGNAME-python= tdb-python-${V}
> +MULTI_PACKAGES= -main -python
>
> # 0750 on Makefile and other files breaks update-patches with
> PORTS_PRIVSEP=Yes
> FIX_EXTRACT_PERMISSIONS= Yes
> @@ -19,7 +25,8 @@ MAINTAINER= Jeremie Courreges-Anglas # LGPLv3+
> PERMIT_PACKAGE= Yes
>
> -WANTLIB += c intl m pthread util ${MODPY_WANTLIB}
> +WANTLIB-main=c pthread
> +WANTLIB-python= intl m pthread tdb util ${MODPY_WANTLIB}
>
> MASTER_SITES=https://download.samba.org/pub/tdb/
>
> @@ -32,7 +39,8 @@ MODPY_ADJ_FILES= buildtools/bin/waf
> BUILD_DEPENDS= textproc/docbook-xsl \
> textproc/libxslt
>
> -LIB_DEPENDS= ${MODPY_LIB_DEPENDS}
> +LIB_DEPENDS-python= ${BUILD_PKGPATH} \
> + ${MODPY_LIB_DEPENDS}
>
> WAF_ARGS=-v -j ${MAKE_JOBS}
> MAKE_FLAGS= WAF_ARGS="${WAF_ARGS}"
> Index: databases/tdb/pkg/DESCR
> ===
> RCS file: databases/tdb/pkg/DESCR
> diff -N databases/tdb/pkg/DESCR
> --- databases/tdb/pkg/DESCR 28 Jul 2007 21:37:26 - 1.1.1.1
> +++ /dev/null 1 Jan 1970 00:00:00 -
> @@ -1,4 +0,0 @@
> -TDB is a Trivial Database. In concept, it is very much like GDBM, and
> -BSD's DB except that it allows multiple simultaneous writers and uses
> -locking internally to keep writers from trampling on each other. TDB is
> -also extremely small.
> Index: databases/tdb/pkg/DESCR-main
> ===
> RCS file: databases/tdb/pkg/DESCR-main
> diff -N databases/tdb/pkg/DESCR-main
> --- /dev/null 1 Jan 1970 00:00:00 -
> +++ databases/tdb/pkg/DESCR-main 28 Jul 2007 21:37:26 -
> @@ -0,0 +1,4 @@
> +TDB is a Trivial Database. In concept, it is very much like GDBM, and
> +BSD's DB except that it allows multiple simultaneous
Re: Collision in py-sip-4.19.19p0v0->4.19.24v0
On Sat Jan 23, 2021 at 05:39:06PM +0100, Florian Obser wrote: > I'm seeing this on -current amd64 Thanks Florian for the report. I am too stupid to unmaze such errors. > > [root@x1:~]# pkg_add -u > > quirks-3.517 signed on 2021-01-22T13:17:10Z > Collision in py-sip-4.19.19p0v0->4.19.24v0: the following files already exist > /usr/local/lib/python2.7/site-packages/PyQt5/sip.pyi > (py-sip-qt5-4.19.19p0 and py-sip-4.19.24v0) > /usr/local/lib/python2.7/site-packages/PyQt5/sip.so > (py-sip-qt5-4.19.19p0 and py-sip-4.19.24v0) This files no longer exist in py3-sip-qt5-5.5.0 so I added "@conflict py3-sip-qt5-<5.5.0" in my last update. That is obviously not enough. Any ideas? > Can't install py-qt5-5.13.2p1->5.15.2: can't resolve py-sip-4.19.24v0 > Couldn't find updates for py-qt5-5.13.2p1 py-sip-4.19.19p0v0 > py-sip-qt5-4.19.19p0 > Couldn't install py-qt5-5.15.2 py-sip-4.19.24v0 > > I think it ultimately gets dragged in because of calibre. Die py2 die! > > OpenBSD 6.8-current (GENERIC.MP) #288: Fri Jan 22 13:36:58 MST 2021 > dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP > real mem = 8233394176 (7851MB) > avail mem = 7968538624 (7599MB) > random: good seed from bootblocks > mpath0 at root > scsibus0 at mpath0: 256 targets > mainbus0 at root > bios0 at mainbus0: SMBIOS rev. 2.7 @ 0xdcd3d000 (61 entries) > bios0: vendor LENOVO version "GRET40WW (1.17 )" date 09/02/2014 > bios0: LENOVO 20A7006VUS > acpi0 at bios0: ACPI 5.0 > acpi0: sleep states S0 S3 S4 S5 > acpi0: tables DSDT FACP SLIC DBGP ECDT HPET APIC MCFG SSDT SSDT SSDT SSDT > SSDT SSDT SSDT PCCT SSDT UEFI MSDM ASF! BATB FPDT UEFI DMAR > acpi0: wakeup devices LID_(S4) SLPB(S3) IGBE(S4) EXP2(S4) XHCI(S3) EHC1(S3) > acpitimer0 at acpi0: 3579545 Hz, 24 bits > acpiec0 at acpi0 > acpihpet0 at acpi0: 14318179 Hz > acpimadt0 at acpi0 addr 0xfee0: PC-AT compat > cpu0 at mainbus0: apid 0 (boot processor) > cpu0: Intel(R) Core(TM) i7-4600U CPU @ 2.10GHz, 798.31 MHz, 06-45-01 > cpu0: > FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,PERF,ITSC,FSGSBASE,TSC_ADJUST,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,SRBDS_CTRL,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWN > cpu0: 256KB 64b/line 8-way L2 cache > cpu0: smt 0, core 0, package 0 > mtrr: Pentium Pro MTRR support, 10 var ranges, 88 fixed ranges > cpu0: apic clock running at 99MHz > cpu0: mwait min=64, max=64, C-substates=0.2.1.2.4.1.1.1, IBE > cpu1 at mainbus0: apid 1 (application processor) > cpu1: Intel(R) Core(TM) i7-4600U CPU @ 2.10GHz, 798.16 MHz, 06-45-01 > cpu1: > FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,PERF,ITSC,FSGSBASE,TSC_ADJUST,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,SRBDS_CTRL,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWN > cpu1: 256KB 64b/line 8-way L2 cache > cpu1: smt 1, core 0, package 0 > cpu2 at mainbus0: apid 2 (application processor) > cpu2: Intel(R) Core(TM) i7-4600U CPU @ 2.10GHz, 798.16 MHz, 06-45-01 > cpu2: > FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,PERF,ITSC,FSGSBASE,TSC_ADJUST,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,SRBDS_CTRL,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWN > cpu2: 256KB 64b/line 8-way L2 cache > cpu2: smt 0, core 1, package 0 > cpu3 at mainbus0: apid 3 (application processor) > cpu3: Intel(R) Core(TM) i7-4600U CPU @ 2.10GHz, 798.16 MHz, 06-45-01 > cpu3: > FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,PERF,ITSC,FSGSBASE,TSC_ADJUST,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,SRBDS_CTRL,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWN > cpu3: 256KB 64b/line 8-way L2 cache > cpu3: smt 1, core 1, package 0 > ioapic0 at mainbus0: apid 2 pa 0xfec0, version 20, 40 pins > acpimcfg0 at acpi0 > acpimcfg0: addr 0xf800, bus 0-63 > acpiprt0 at acpi0: bus 0 (PCI0) > acpiprt1 at acpi0: bus -1 (PEG_) > acpiprt2 at acpi0: bus 2 (EXP1) > acpiprt3 at acpi0: bus 3 (EXP2) > acpiprt4 at acpi0: bus -1 (EXP3) >
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: kette...@cvs.openbsd.org2021/01/23 09:52:12 Modified files: lang/gcc/8 : Makefile lang/gcc/8/patches: patch-gcc_configure Log message: Override another linker feature that isn't properly detected. ok jasper@
Collision in py-sip-4.19.19p0v0->4.19.24v0
I'm seeing this on -current amd64 [root@x1:~]# pkg_add -u quirks-3.517 signed on 2021-01-22T13:17:10Z Collision in py-sip-4.19.19p0v0->4.19.24v0: the following files already exist /usr/local/lib/python2.7/site-packages/PyQt5/sip.pyi (py-sip-qt5-4.19.19p0 and py-sip-4.19.24v0) /usr/local/lib/python2.7/site-packages/PyQt5/sip.so (py-sip-qt5-4.19.19p0 and py-sip-4.19.24v0) Can't install py-qt5-5.13.2p1->5.15.2: can't resolve py-sip-4.19.24v0 Couldn't find updates for py-qt5-5.13.2p1 py-sip-4.19.19p0v0 py-sip-qt5-4.19.19p0 Couldn't install py-qt5-5.15.2 py-sip-4.19.24v0 I think it ultimately gets dragged in because of calibre. OpenBSD 6.8-current (GENERIC.MP) #288: Fri Jan 22 13:36:58 MST 2021 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP real mem = 8233394176 (7851MB) avail mem = 7968538624 (7599MB) random: good seed from bootblocks mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.7 @ 0xdcd3d000 (61 entries) bios0: vendor LENOVO version "GRET40WW (1.17 )" date 09/02/2014 bios0: LENOVO 20A7006VUS acpi0 at bios0: ACPI 5.0 acpi0: sleep states S0 S3 S4 S5 acpi0: tables DSDT FACP SLIC DBGP ECDT HPET APIC MCFG SSDT SSDT SSDT SSDT SSDT SSDT SSDT PCCT SSDT UEFI MSDM ASF! BATB FPDT UEFI DMAR acpi0: wakeup devices LID_(S4) SLPB(S3) IGBE(S4) EXP2(S4) XHCI(S3) EHC1(S3) acpitimer0 at acpi0: 3579545 Hz, 24 bits acpiec0 at acpi0 acpihpet0 at acpi0: 14318179 Hz acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: Intel(R) Core(TM) i7-4600U CPU @ 2.10GHz, 798.31 MHz, 06-45-01 cpu0: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,PERF,ITSC,FSGSBASE,TSC_ADJUST,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,SRBDS_CTRL,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWN cpu0: 256KB 64b/line 8-way L2 cache cpu0: smt 0, core 0, package 0 mtrr: Pentium Pro MTRR support, 10 var ranges, 88 fixed ranges cpu0: apic clock running at 99MHz cpu0: mwait min=64, max=64, C-substates=0.2.1.2.4.1.1.1, IBE cpu1 at mainbus0: apid 1 (application processor) cpu1: Intel(R) Core(TM) i7-4600U CPU @ 2.10GHz, 798.16 MHz, 06-45-01 cpu1: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,PERF,ITSC,FSGSBASE,TSC_ADJUST,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,SRBDS_CTRL,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWN cpu1: 256KB 64b/line 8-way L2 cache cpu1: smt 1, core 0, package 0 cpu2 at mainbus0: apid 2 (application processor) cpu2: Intel(R) Core(TM) i7-4600U CPU @ 2.10GHz, 798.16 MHz, 06-45-01 cpu2: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,PERF,ITSC,FSGSBASE,TSC_ADJUST,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,SRBDS_CTRL,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWN cpu2: 256KB 64b/line 8-way L2 cache cpu2: smt 0, core 1, package 0 cpu3 at mainbus0: apid 3 (application processor) cpu3: Intel(R) Core(TM) i7-4600U CPU @ 2.10GHz, 798.16 MHz, 06-45-01 cpu3: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,PERF,ITSC,FSGSBASE,TSC_ADJUST,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,SRBDS_CTRL,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWN cpu3: 256KB 64b/line 8-way L2 cache cpu3: smt 1, core 1, package 0 ioapic0 at mainbus0: apid 2 pa 0xfec0, version 20, 40 pins acpimcfg0 at acpi0 acpimcfg0: addr 0xf800, bus 0-63 acpiprt0 at acpi0: bus 0 (PCI0) acpiprt1 at acpi0: bus -1 (PEG_) acpiprt2 at acpi0: bus 2 (EXP1) acpiprt3 at acpi0: bus 3 (EXP2) acpiprt4 at acpi0: bus -1 (EXP3) dwiic0 at acpi0 I2C1 addr 0xfe105000/0x1000 irq 7 iic0 at dwiic0 "CPLM3218" at iic0 addr 0x48 not configured acpibtn0 at acpi0: LID_ acpibtn1 at acpi0: SLPB acpipci0 at acpi0 PCI0: 0x 0x0011 0x0001 acpicmos0 at acpi0 acpibat0 at acpi0: BAT0 model "45N1703" serial 3191 type LiP oem "SMP" acpiac0 at acpi0: AC unit offline acpithinkpad0 at acpi0: version 2.0 "PNP0C14" at acpi0 not configured "PNP0C14" at acpi0 not configured "PNP0C14"
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: jas...@cvs.openbsd.org 2021/01/23 09:32:34 Modified files: converters/otf2bdf: Makefile Added files: converters/otf2bdf/patches: patch-otf2bdf_c Log message: Check return value of FT_Get_Sfnt_Table() to fix a NULL deref on invalid input.
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: jas...@cvs.openbsd.org 2021/01/23 09:31:58 ports/converters/otf2bdf/patches Update of /cvs/ports/converters/otf2bdf/patches In directory cvs.openbsd.org:/tmp/cvs-serv10213/patches Log Message: Directory /cvs/ports/converters/otf2bdf/patches added to the repository
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: ajacou...@cvs.openbsd.org 2021/01/23 09:24:06 Modified files: devel/py-lief : Makefile Log message: Missing BDEP on devel/cmake.
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: rsadow...@cvs.openbsd.org 2021/01/23 09:20:24 ports/x11/kde-applications/kdenetwork-filesharing/patches Update of /cvs/ports/x11/kde-applications/kdenetwork-filesharing/patches In directory cvs.openbsd.org:/tmp/cvs-serv54713/kdenetwork-filesharing/patches Log Message: Directory /cvs/ports/x11/kde-applications/kdenetwork-filesharing/patches added to the repository
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: jas...@cvs.openbsd.org 2021/01/23 08:19:54 Modified files: games/valyriatear: Makefile Log message: mark this broken for big endian arches. even if it builds the runtime has serious issues as pointed out by cwen@ ok bcallah@ (MAINTAINER)
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: st...@cvs.openbsd.org 2021/01/23 08:15:58 Modified files: www/chromium : Makefile Log message: reinstate BROKEN-i386 again, it will not run so it is useless to waste 30 hours building it
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: st...@cvs.openbsd.org 2021/01/23 08:10:41 Modified files: graphics/darktable: Makefile distinfo graphics/darktable/patches: patch-CMakeLists_txt Added files: graphics/darktable/patches: patch-src_common_imageio_avif_c Log message: oops, revert unintended parts of commit. (I had a local WIP update that was stalled because they want kern.proc.pathname or similar).
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: st...@cvs.openbsd.org 2021/01/23 08:06:28 Modified files: graphics/darktable: Makefile distinfo graphics/darktable/patches: patch-CMakeLists_txt Removed files: graphics/darktable/patches: patch-src_common_imageio_avif_c Log message: just set ONLY_FOR_ARCHS, this is no good on 32-bit LE either
Re: Add MODOCAML_RUNDEP to ocaml.port.mk
On Sat 23/01/2021 13:33, Jeremie Courreges-Anglas wrote:
> On Fri, Jan 22 2021, Bjorn Ketelaars wrote:
> > On Fri 22/01/2021 08:19, Jeremie Courreges-Anglas wrote:
> >> On Fri, Jan 22 2021, Bjorn Ketelaars wrote:
> >> > On Thu 21/01/2021 23:29, Jeremie Courreges-Anglas wrote:
> >> >> On Thu, Jan 21 2021, Stuart Henderson wrote:
> >> >> > On 2021/01/21 06:43, Bjorn Ketelaars wrote:
> >> >> >> On Wed 20/01/2021 21:42, Jeremie Courreges-Anglas wrote:
> >> >> >> > On Wed, Jan 20 2021, Bjorn Ketelaars wrote:
> >> >> >> > > (Maintainer timeout)
> >> >> >> > >
> >> >> >> > > ocaml is currently a RDEP for all ports that are build with it.
> >> >> >> > > This is
> >> >> >> > > unnecessary for a couple of them, i.e. net/unison.
> >> >> >> >
> >> >> >> > As far as I know, programs written in OCaml should run without the
> >> >> >> > OCaml
> >> >> >> > runtime installed on ${OCAML_NATIVE_ARCHS}, currently i386 and
> >> >> >> > amd64.
> >> >> >> > Except for OCaml programs that make direct use of the OCaml
> >> >> >> > runtime, of
> >> >> >> > course... But the rundep is still needed on non-native archs.
> >> >> >> >
> >> >> >> > > I would like to
> >> >> >> > > propose the addition of MODOCAML_RUNDEP and MODOCAML_BUILDDEP,
> >> >> >> > > which are
> >> >> >> > > modelled on python.port.mk.
> >> >> >> > >
> >> >> >> > > Default behaviour is not changed. Setting MODOCAML_RUNDEP=No in a
> >> >> >> > > Makefile excludes ocaml as RDEP.
> >> >> >> > >
> >> >> >> > > OK?
> >> >> >> >
> >> >> >> > Your diff makes sense I think, but you can't just use it to
> >> >> >> > disable the run-dep in net/unison: you'd break unison installs on
> >> >> >> > non-native archs.
> >> >> >>
> >> >> >> Oops, I didn't think about the above.
> >> >> >>
> >> >> >> I will look further for a fitting, clean solution that serves all
> >> >> >> arches.
> >> >> >>
> >> >> >
> >> >> > Maybe allow MODOCAML_RUNDEP=yes/no/nonative or some similar thing?
> >> >>
> >> >> Hmm, so "nonative" would be for ports that produce bytecode-only
> >> >> programs, even on native archs? (No idea how many ports are affected.)
> >> >> We could call it "bytecode" then, that would seem a bit more descriptive
> >> >> than a plain MODOCAML_RUNDEP=Yes in a port Makefile.
> >> >>
> >> >> And then MODOCAML_RUNDEP=Yes would be useful for ports that always
> >> >> use lang/ocaml programs/files at runtime?
> >> >>
> >> >> > It would be nice to handle the arch detection in ocaml.port.mk rather
> >> >> > than in any port using this.
> >> >>
> >> >> Here's the simple diff I had in mind yesterday, on top of Bjorn's diff.
> >> >> It probably helps Bjorn with unison but it would require testing all
> >> >> other OCaml programs, and bumping REVISION for a bunch of them.
> >> >> Maybe not the easiest or safest approach.
> >> >>
> >> >> I suspect that most people caring about OCaml in ports have thought
> >> >> about this before, hopefully they can share their ideas. :)
> >> >
> >> > I'm not particular fond of testing all other OCaml programs.
> >> >
> >> > What do you think of the diff below; lang/ocaml is added to
> >> > BUILD_DEPENDS and RUN_DEPENDS unless native-code compilation is possible
> >> > *and* the port specifically requests not to.
> >> >
> >> > lang/ocaml is always added in cases of ! ${OCAML_NATIVE_ARCHS}, and
> >> > 'make show=MODOCAML_RUNDEP' would show 'Ignored as native-code
> >> > compilation is not supported on this platform'.
> >> >
> >> >
> >> > diff --git ocaml.port.mk ocaml.port.mk
> >> > index bda7f1fc763..b5e9c863089 100644
> >> > --- ocaml.port.mk
> >> > +++ ocaml.port.mk
> >> > @@ -33,8 +33,27 @@ MODOCAML_OCAMLDOC?=ocamldoc
> >> > PKG_ARGS+=-Ddynlink=0
> >> > .endif
> >> >
> >> > -RUN_DEPENDS += lang/ocaml
> >> > -BUILD_DEPENDS +=lang/ocaml
> >> > +MODOCAML_RUN_DEPENDS= lang/ocaml
> >> > +MODOCAML_BUILD_DEPENDS= ${MODOCAML_RUN_DEPENDS}
> >> > +
> >> > +# Add lang/ocaml to BUILD_DEPENDS and RUN_DEPENDS unless native-code
> >> > +# compilation is possible (OCAML_NATIVE_ARCHS) and the port
> >> > +# specifically requests not to.
> >> > +.if ${PROPERTIES:Mocaml_native}
> >> > +MODOCAML_BUILDDEP?= Yes
> >> > +MODOCAML_RUNDEP?= Yes
> >> > +.else
> >> > +MODOCAML_BUILDDEP:= Ignored as native-code compilation is not
> >> > supported on this platform
> >>
> >> You still need ocaml at build time, to build the bytecode and other things.
> >
> > I agree!
> >
> > It is highly unlikely that one would want to use MODOCAML_BUILDDEP=No in
> > a Makefile. I can't think of any reason for offering this knob except
> > that it mimics erlang/go/lua/php/python/ruby.
>
> Unlikely but valid, just think of a port that would use OCaml scripts at
> runtime. (You can write OCaml scripts with a shebang line.)
>
> Anyway I think it's good to allow anything in a module to be disabled,
> else people tend to resort to hacks to work around hardcoded choices.
>
> > Usage of this knob will result in failure early on. BTW if you set
>
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: d...@cvs.openbsd.org2021/01/23 07:58:19 Modified files: databases/redis: Makefile distinfo databases/redis/patches: patch-src_networking_c Log message: Update to redis-6.0.10 If you used Redis on some Big Endian Arch (like sparc64) with previous 6.0.x versions, you should really have a look at https://github.com/redis/redis/pull/8270 to "consider the compatibility implications with RESTORE, replication and persistence". Tests pass on amd64 and sparc64 (with the usual occasional replica hiccup on sparc64). Positive feedback from Mark Patruck. Help from, and ok tb@
Re: Add MODOCAML_RUNDEP to ocaml.port.mk
On 2021/01/23 13:33, Jeremie Courreges-Anglas wrote:
> On Fri, Jan 22 2021, Bjorn Ketelaars wrote:
> >
> > Don't think so. If we are building on a non-native arch we want to make
> > sure that lang/ocaml is added as BDEP and RDEP, independent how
> > MODOCAML_RUNDEP or MODOCAML_BUILDDEP are used in a Makefile.
> > [...]
>
> An OCaml port probably needs lang/ocaml at build time on *all archs*,
> I don't see a reason to introduce a difference between native and
> non-native archs *at build time*, nor do I see a good reason to ignore
> what a port specifies.
Agreed, variable build dependencies per-arch sounds like it's asking for
trouble.
> | # Assume that we want to automatically add ocaml to BUILD_DEPENDS
> | -# and RUN_DEPENDS unless the port specifically requests not to.
> | +# unless the port specifically requests not to.
> | MODOCAML_BUILDDEP?=Yes
> | +# Same for RUN_DEPENDS, but MODOCAML_RUN_DEPENDS can take three values:
> | +# Yes, No or if-not-native (translates to Yes if native-code is
> unsupported)
> | MODOCAML_RUNDEP?= Yes
> |
> | .if ${NO_BUILD:L} == no && ${MODOCAML_BUILDDEP:L} == yes
> | BUILD_DEPENDS+=${MODOCAML_BUILD_DEPENDS}
> | .endif
I'm not totally objecting to MODOCAML_BUILDDEP=no but I'm not sure
there's a use for it. I'd be tempted to leave it out for now. If we
do that and someone does comes up with a port that wants to disable
build dep's later, they could just change ocaml.port.mk at the same
time, no need to hack around it.
Apart from anything else port-modules(5) is already hard to read and
I'd be happy to avoid adding more :)
I think MODGO_BUILDDEP can be removed from go.port.mk too, nothing
uses it and I don't really see how it could..
It's used quite a lot for python, and a bit for PHP though possibly
not enough - this discussion made me wonder if I should change that to
No by default for PHP. But those are quite different to the case of
go or ocaml.
> | +.if ${MODOCAML_RUNDEP:L} == if-not-native && ${MODOCAML_NATIVE} == No
> | +MODOCAML_RUNDEP = Yes
> | +.endif
> | .if ${MODOCAML_RUNDEP:L} == yes
> | RUN_DEPENDS+= ${MODOCAML_RUN_DEPENDS}
> | .endif
>
> This implements the three choice logic suggested by sthen, doesn't
> affect current defaults, and only cares about the runtime dep.
> I hope that "if-not-native" is an improvement over "nonative".
love the "if-not-native" wording, that's perfect :)
> Index: ocaml.port.mk
> ===
> RCS file: /cvs/ports/lang/ocaml/ocaml.port.mk,v
> retrieving revision 1.32
> diff -u -p -r1.32 ocaml.port.mk
> --- ocaml.port.mk 3 Dec 2017 11:10:10 - 1.32
> +++ ocaml.port.mk 23 Jan 2021 12:19:27 -
> @@ -33,8 +33,27 @@ MODOCAML_OCAMLDOC?=ocamldoc
> PKG_ARGS+=-Ddynlink=0
> .endif
>
> -RUN_DEPENDS += lang/ocaml
> -BUILD_DEPENDS += lang/ocaml
> +MODOCAML_RUN_DEPENDS=lang/ocaml
> +MODOCAML_BUILD_DEPENDS= lang/ocaml
> +
> +# Assume that we want to automatically add ocaml to BUILD_DEPENDS
> +# unless the port specifically requests not to.
> +MODOCAML_BUILDDEP?= Yes
> +# Same for RUN_DEPENDS, but MODOCAML_RUN_DEPENDS can take three values:
> +# Yes, No or if-not-native (translates to Yes if native-code is unsupported)
> +MODOCAML_RUNDEP?=Yes
> +
> +.if ${NO_BUILD:L} == no && ${MODOCAML_BUILDDEP:L} == yes
> +BUILD_DEPENDS+= ${MODOCAML_BUILD_DEPENDS}
> +.endif
> +
> +.if ${MODOCAML_RUNDEP:L} == if-not-native && ${MODOCAML_NATIVE} == No
> +MODOCAML_RUNDEP =Yes
> +.endif
> +.if ${MODOCAML_RUNDEP:L} == yes
> +RUN_DEPENDS+=${MODOCAML_RUN_DEPENDS}
> +.endif
> +
> MAKE_ENV += OCAMLFIND_DESTDIR=${DESTDIR}${TRUEPREFIX}/lib/ocaml \
> OCAMLFIND_COMMANDS="ocamldoc=${MODOCAML_OCAMLDOC}"
>
>
> --
> jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF DDCC 0DFA 74AE 1524 E7EE
>
Re: [update] haproxy to 2.3.4 (latest stable)
On Wed, 20 Jan 2021 12:17:00 -0500, Aisha Tammy
wrote:
>
> Hi,
> I've linked the release note highlights of 2.2
> https://www.mail-archive.com/haproxy@formilux.org/msg37852.html
> and the full changelog of 2.3
> https://www.haproxy.org/download/2.3/src/CHANGELOG
>
> An important highlight (which is why I updated haproxy)
> was that since 2.2 haproxy now supports keeping the private and
> public keys in separate files, while previously, they needed to be
> in the same file. This allows us to directly use the output of
> acme-client(1) without doing extra scripting.
>
> The latest stable is 2.3.4, the latest LTS is 2.2. Both of them
> have the acme-client compatibility so I am fine with either (though
> personally I'm partial to 2.3 just cuz its new and shiny).
>
> The libressl support seems to be doing fine. I have a test website
> running behind haproxy which is working (with ocsp as
> well) https://www.epsilonknot.xyz, so that seems OK. The logging
> is definitely something I have not looked into a lot so if someone
> can take a peek at that, that would be nice.
Alright, thanks!
Here's a patch based on yours. It looks good to me so I'll commit it in
a few days.
Index: Makefile
===
RCS file: /cvs/ports/net/haproxy/Makefile,v
retrieving revision 1.73
diff -u -p -r1.73 Makefile
--- Makefile17 Jan 2021 15:22:56 - 1.73
+++ Makefile23 Jan 2021 14:43:13 -
@@ -2,9 +2,9 @@
COMMENT = reliable, high performance TCP/HTTP load balancer
-DISTNAME = haproxy-2.0.20
+DISTNAME = haproxy-2.3.4
CATEGORIES = net www
-HOMEPAGE = http://www.haproxy.org/
+HOMEPAGE = https://www.haproxy.org/
MAINTAINER = Daniel Jakots
# GPLv2
@@ -12,7 +12,7 @@ PERMIT_PACKAGE = Yes
WANTLIB += c crypto pcre pcreposix pthread ssl z
-MASTER_SITES = ${HOMEPAGE}/download/2.0/src/
+MASTER_SITES = ${HOMEPAGE}/download/2.3/src/
HAPROXYCONF = ${SYSCONFDIR}/haproxy
HAPROXYSTATE = /var/haproxy
Index: distinfo
===
RCS file: /cvs/ports/net/haproxy/distinfo,v
retrieving revision 1.43
diff -u -p -r1.43 distinfo
--- distinfo17 Jan 2021 15:22:56 - 1.43
+++ distinfo23 Jan 2021 14:43:13 -
@@ -1,2 +1,2 @@
-SHA256 (haproxy-2.0.20.tar.gz) = ZRU8mJ50EvaBXTsEcYS7B+63PMsQ9cBedXNH6mwxfOE=
-SIZE (haproxy-2.0.20.tar.gz) = 2693943
+SHA256 (haproxy-2.3.4.tar.gz) = YBSM3+3WsZxAHbzXXM12pTwgvHbEkDK6Mq+YoKXEle0=
+SIZE (haproxy-2.3.4.tar.gz) = 2909672
Index: patches/patch-Makefile
===
RCS file: patches/patch-Makefile
diff -N patches/patch-Makefile
--- patches/patch-Makefile 14 Dec 2020 23:26:59 - 1.10
+++ /dev/null 1 Jan 1970 00:00:00 -
@@ -1,32 +0,0 @@
-$OpenBSD: patch-Makefile,v 1.10 2020/12/14 23:26:59 danj Exp $
-
-- BUILD: makefile: Update feature flags for OpenBSD (90c9d78)
-- BUILD: makefile: enable crypt(3) for OpenBSD (496374e)
-
-Index: Makefile
Makefile.orig
-+++ Makefile
-@@ -362,10 +362,11 @@ ifeq ($(TARGET),osx)
- EXPORT_SYMBOL = -export_dynamic
- endif
-
--# OpenBSD 5.7 and above
-+# OpenBSD 6.3 and above
- ifeq ($(TARGET),openbsd)
- set_target_defaults = $(call default_opts, \
--USE_POLL USE_TPROXY USE_THREAD USE_KQUEUE USE_ACCEPT4)
-+USE_POLL USE_TPROXY USE_LIBCRYPT USE_THREAD USE_KQUEUE USE_ACCEPT4
\
-+USE_CLOSEFROM USE_GETADDRINFO)
- endif
-
- # NetBSD
-@@ -455,7 +456,9 @@ BUILD_FEATURES := $(foreach opt,$(patsubst USE_%,%,$(u
- OPTIONS_CFLAGS += $(foreach opt,$(use_opts),$(if $($(opt)),-D$(opt),))
-
- ifneq ($(USE_LIBCRYPT),)
-+ifneq ($(TARGET),openbsd)
- OPTIONS_LDFLAGS += -lcrypt
-+endif
- endif
-
- ifneq ($(USE_SLZ),)
Index: patches/patch-doc_haproxy_1
===
RCS file: /cvs/ports/net/haproxy/patches/patch-doc_haproxy_1,v
retrieving revision 1.7
diff -u -p -r1.7 patch-doc_haproxy_1
--- patches/patch-doc_haproxy_1 9 Nov 2019 15:52:53 - 1.7
+++ patches/patch-doc_haproxy_1 23 Jan 2021 14:43:13 -
@@ -2,7 +2,7 @@ $OpenBSD: patch-doc_haproxy_1,v 1.7 2019
Index: doc/haproxy.1
--- doc/haproxy.1.orig
+++ doc/haproxy.1
-@@ -217,8 +217,7 @@ This signal is intercepted and ignored on systems with
+@@ -218,8 +218,7 @@ This signal is intercepted and ignored on systems with
.SH SEE ALSO
Index: patches/patch-src_log_c
===
RCS file: patches/patch-src_log_c
diff -N patches/patch-src_log_c
--- patches/patch-src_log_c 14 Dec 2020 23:26:59 - 1.2
+++ /dev/null 1 Jan 1970 00:00:00 -
@@ -1,21 +0,0 @@
-$OpenBSD: patch-src_log_c,v 1.2 2020/12/14 23:26:59 danj Exp $
-
-This fixes `haproxy: vfprintf %s NULL in ">%s %2d %02d:%02d:%02d %.*s%*s"`
-in syslog. It was never committed upstream and commit 5464885 shuffled the
-code.
-
-It was discussed on the mailing
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: jas...@cvs.openbsd.org 2021/01/23 07:44:02 Modified files: lang/gpc : Makefile Log message: add powerpc64 to NOT_FOR_ARCHS list. this port embeds a copy of gcc4 which lacks support for the elfv2 api on powerpc64 so backporting the gcc8 patches from our tree would probably get us nowhere anyway.
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: jas...@cvs.openbsd.org 2021/01/23 07:16:36 Modified files: shells/ksh93 : Makefile Log message: mark broken on powerpc64: libast fails to build on hashalloc.c/tokscan.c
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: c...@cvs.openbsd.org2021/01/23 07:05:51 Modified files: devel/liboil : Makefile devel/liboil/patches: patch-m4_as-host-defines_m4 Log message: liboil: extend the powerpc64 fix to powerpc This fixes liboil's runtime on this platform; building with -fno-integrated-as lead to sigabrt at runtime. While here remove the tentative arm fix, that we introduced with the initial powerpc fix, it does not fix the build. Tested again by jasper@ on powerpc64, thanks!
tdb: split py2 bindings into -python package
tdb depends on Python 2 for its bindings but the only port using them is
net/samba; many other ports use tdb without Pyhton but still pull in
Python 2.
With -main and -python packages we can tell samba to also install the
-python package to be happy such that all other ports depending on tdb
can be installed without Python 2:
net/netatalk3
mail/neomutt
mail/fdm
audio/rhythmbox
audio/pulseaudio
I've added the `@pkgpath databases/tdb' marker to PLIST-main such that
`pkg_add -U tdb' will happily upgrade, no quirks required here:
Jan 23 14:48:52 eru pkg_add: Added tdb-1.3.18->1.3.18p0
For samba I have not checked which of its subpackages actually uses the
Python bindings do both of them now install the new subpackage, i.e.
no effective change for them.
Feedback? OK?
Index: databases/tdb/Makefile
===
RCS file: /cvs/ports/databases/tdb/Makefile,v
retrieving revision 1.32
diff -u -p -r1.32 Makefile
--- databases/tdb/Makefile 14 Mar 2020 15:35:29 - 1.32
+++ databases/tdb/Makefile 23 Jan 2021 13:46:25 -
@@ -1,9 +1,15 @@
# $OpenBSD: Makefile,v 1.32 2020/03/14 15:35:29 kn Exp $
-COMMENT= trivial database library
+COMMENT-main= trivial database library
+COMMENT-python=Python ${MODPY_VERSION} bindings for tdb
# Keep in sync with the version bundled in net/samba
-DISTNAME= tdb-1.3.18
+V= 1.3.18
+DISTNAME= tdb-${V}
+PKGNAME-main= tdb-${V}
+REVISION-main= 0
+PKGNAME-python=tdb-python-${V}
+MULTI_PACKAGES=-main -python
# 0750 on Makefile and other files breaks update-patches with PORTS_PRIVSEP=Yes
FIX_EXTRACT_PERMISSIONS= Yes
@@ -19,7 +25,8 @@ MAINTAINER= Jeremie Courreges-Anglas https://download.samba.org/pub/tdb/
@@ -32,7 +39,8 @@ MODPY_ADJ_FILES= buildtools/bin/waf
BUILD_DEPENDS= textproc/docbook-xsl \
textproc/libxslt
-LIB_DEPENDS= ${MODPY_LIB_DEPENDS}
+LIB_DEPENDS-python=${BUILD_PKGPATH} \
+ ${MODPY_LIB_DEPENDS}
WAF_ARGS= -v -j ${MAKE_JOBS}
MAKE_FLAGS=WAF_ARGS="${WAF_ARGS}"
Index: databases/tdb/pkg/DESCR
===
RCS file: databases/tdb/pkg/DESCR
diff -N databases/tdb/pkg/DESCR
--- databases/tdb/pkg/DESCR 28 Jul 2007 21:37:26 - 1.1.1.1
+++ /dev/null 1 Jan 1970 00:00:00 -
@@ -1,4 +0,0 @@
-TDB is a Trivial Database. In concept, it is very much like GDBM, and
-BSD's DB except that it allows multiple simultaneous writers and uses
-locking internally to keep writers from trampling on each other. TDB is
-also extremely small.
Index: databases/tdb/pkg/DESCR-main
===
RCS file: databases/tdb/pkg/DESCR-main
diff -N databases/tdb/pkg/DESCR-main
--- /dev/null 1 Jan 1970 00:00:00 -
+++ databases/tdb/pkg/DESCR-main28 Jul 2007 21:37:26 -
@@ -0,0 +1,4 @@
+TDB is a Trivial Database. In concept, it is very much like GDBM, and
+BSD's DB except that it allows multiple simultaneous writers and uses
+locking internally to keep writers from trampling on each other. TDB is
+also extremely small.
Index: databases/tdb/pkg/DESCR-python
===
RCS file: databases/tdb/pkg/DESCR-python
diff -N databases/tdb/pkg/DESCR-python
--- /dev/null 1 Jan 1970 00:00:00 -
+++ databases/tdb/pkg/DESCR-python 23 Jan 2021 13:47:51 -
@@ -0,0 +1 @@
+Python ${MODPY_VERSION} bindings for tdb.
Index: databases/tdb/pkg/PLIST
===
RCS file: databases/tdb/pkg/PLIST
diff -N databases/tdb/pkg/PLIST
--- databases/tdb/pkg/PLIST 4 Dec 2019 00:14:45 - 1.10
+++ /dev/null 1 Jan 1970 00:00:00 -
@@ -1,16 +0,0 @@
-@comment $OpenBSD: PLIST,v 1.10 2019/12/04 00:14:45 jca Exp $
-@conflict samba-<3.5.0
-@bin bin/tdbbackup
-@bin bin/tdbdump
-@bin bin/tdbrestore
-@bin bin/tdbtool
-include/tdb.h
-@lib lib/libtdb.so.${LIBtdb_VERSION}
-lib/pkgconfig/tdb.pc
-lib/python${MODPY_VERSION}/site-packages/_tdb_text.py
-lib/python${MODPY_VERSION}/site-packages/_tdb_text.pyc
-@so lib/python${MODPY_VERSION}/site-packages/tdb.so
-@man man/man8/tdbbackup.8
-@man man/man8/tdbdump.8
-@man man/man8/tdbrestore.8
-@man man/man8/tdbtool.8
Index: databases/tdb/pkg/PLIST-main
===
RCS file: databases/tdb/pkg/PLIST-main
diff -N databases/tdb/pkg/PLIST-main
--- /dev/null 1 Jan 1970 00:00:00 -
+++ databases/tdb/pkg/PLIST-main23 Jan 2021 13:44:01 -
@@ -0,0 +1,13 @@
+@comment $OpenBSD: PLIST-main,v$
+@pkgpath databases/tdb
+@bin bin/tdbbackup
+@bin bin/tdbdump
+@bin bin/tdbrestore
+@bin bin/tdbtool
+include/tdb.h
+@lib lib/libtdb.so.${LIBtdb_VERSION}
+lib/pkgconfig/tdb.pc
+@man man/man8/tdbbackup.8
+@man man/man8/tdbdump.8
+@man man/man8/tdbrestore.8
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: jas...@cvs.openbsd.org 2021/01/23 06:54:09 Modified files: lang/pfe : Makefile Log message: mark pfe broken on powerpc64 (lacks proper ppc support in general)
UPDATE: libsndfile
Some further fixes for libsndfile..
- Improve handling of SMPL chunks in WAV files.
- Fix use of uninitialized value in endswap_int64_t_array.
https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=25366
Index: Makefile
===
RCS file: /home/cvs/ports/audio/libsndfile/Makefile,v
retrieving revision 1.34
diff -u -p -u -p -r1.34 Makefile
--- Makefile16 Jan 2021 12:53:12 - 1.34
+++ Makefile16 Jan 2021 17:51:34 -
@@ -3,6 +3,7 @@
COMMENT= library to handle various audio file formats
DISTNAME= libsndfile-1.0.30
+REVISION= 0
CATEGORIES=audio
GH_ACCOUNT=libsndfile
GH_PROJECT=libsndfile
Index: patches/patch-programs_sndfile-info_c
===
RCS file: patches/patch-programs_sndfile-info_c
diff -N patches/patch-programs_sndfile-info_c
--- patches/patch-programs_sndfile-info_c 16 Jan 2021 12:54:12 -
1.1
+++ /dev/null 1 Jan 1970 00:00:00 -
@@ -1,17 +0,0 @@
-$OpenBSD: patch-programs_sndfile-info_c,v 1.1 2021/01/16 12:54:12 sthen Exp $
-
-Fix stack buffer overflow in instrument_dump. When loop_count more than 16,
-it has a stack buffer overflow.
-
-Index: programs/sndfile-info.c
programs/sndfile-info.c.orig
-+++ programs/sndfile-info.c
-@@ -312,7 +312,7 @@ instrument_dump (const char *filename)
- printf (" Key : %d - %d\n", (int) inst.key_lo, (int)
inst.key_hi) ;
- printf (" Loop points : %d\n", inst.loop_count) ;
-
-- for (k = 0 ; k < inst.loop_count ; k++)
-+ for (k = 0 ; k < inst.loop_count && k < ARRAY_LEN (inst.loops) ; k++)
- printf (" %-2dMode : %sStart : %6d End : %6d Count
: %6d\n", k, str_of_type (inst.loops [k].mode), inst.loops [k].start,
inst.loops [k].end, inst.loops [k].count) ;
-
- putchar ('\n') ;
Index: patches/patch-src_double64_c
===
RCS file: patches/patch-src_double64_c
diff -N patches/patch-src_double64_c
--- /dev/null 1 Jan 1970 00:00:00 -
+++ patches/patch-src_double64_c23 Jan 2021 09:36:06 -
@@ -0,0 +1,16 @@
+$OpenBSD$
+
+Fix use of uninitialized value in endswap_int64_t_array.
+
+Index: src/double64.c
+--- src/double64.c.orig
src/double64.c
+@@ -631,7 +631,7 @@ host_read_d2f (SF_PRIVATE *psf, float *ptr, sf_count_t
+ readcount = psf_fread (ubuf.dbuf, sizeof (double), bufferlen,
psf) ;
+
+ if (psf->data_endswap == SF_TRUE)
+- endswap_double_array (ubuf.dbuf, bufferlen) ;
++ endswap_double_array (ubuf.dbuf, readcount) ;
+
+ d2f_array (ubuf.dbuf, readcount, ptr + total) ;
+ total += readcount ;
Index: patches/patch-src_wav_c
===
RCS file: /home/cvs/ports/audio/libsndfile/patches/patch-src_wav_c,v
retrieving revision 1.1
diff -u -p -u -p -r1.1 patch-src_wav_c
--- patches/patch-src_wav_c 16 Jan 2021 12:54:12 - 1.1
+++ patches/patch-src_wav_c 16 Jan 2021 17:59:35 -
@@ -3,6 +3,7 @@ $OpenBSD: patch-src_wav_c,v 1.1 2021/01/
- Fix memory leak in wav_read_smpl_chunk().
- Fix leak in wav_read_header.
- Fix memory leak in wav_read_acid_chunk.
+- Improve handling of SMPL chunks in WAV files.
Index: src/wav.c
--- src/wav.c.orig
@@ -19,6 +20,15 @@ Index: src/wav.c
if ((psf->cues = psf_cues_alloc
(cue_count)) == NULL)
return
SFE_MALLOC_FAILED ;
+@@ -1289,7 +1294,7 @@ wav_command (SF_PRIVATE *psf, int command, void * UNUS
+ static int
+ wav_read_smpl_chunk (SF_PRIVATE *psf, uint32_t chunklen)
+ { char buffer [512] ;
+- uint32_t thisread, bytesread = 0, dword, sampler_data, loop_count ;
++ uint32_t thisread, bytesread = 0, dword, sampler_data, loop_count,
actually_loop_count = 0 ;
+ uint32_t note, pitch, start, end, type = -1, count ;
+ int j, k ;
+
@@ -1335,6 +1340,11 @@ wav_read_smpl_chunk (SF_PRIVATE *psf, uint32_t chunkle
*/
bytesread += psf_binheader_readf (psf, "4", _data) ;
@@ -31,7 +41,26 @@ Index: src/wav.c
if ((psf->instrument = psf_instrument_alloc ()) == NULL)
return SFE_MALLOC_FAILED ;
-@@ -1486,6 +1496,11 @@ wav_read_acid_chunk (SF_PRIVATE *psf, uint32_t chunkle
+@@ -1381,8 +1391,17 @@ wav_read_smpl_chunk (SF_PRIVATE *psf, uint32_t chunkle
+ break ;
+ } ;
+ } ;
++ actually_loop_count ++ ;
++ } ;
+
+- loop_count -- ;
++ if (actually_loop_count > ARRAY_LEN (psf->instrument->loops))
++ {
++ psf_log_printf (psf, "*** Warning, actual Loop Points count
exceeds %u, changing Loop Count from %u to %u\n", ARRAY_LEN
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: k...@cvs.openbsd.org2021/01/23 05:48:37 Modified files: devel/quirks : Makefile devel/quirks/files: Quirks.pm sysutils/mcollective-plugins: Makefile Removed files: sysutils/mcollective-plugins/puppet-agent: Makefile distinfo sysutils/mcollective-plugins/puppet-agent/pkg: DESCR PLIST Log message: Remove mcollective puppet-agent plugin Puppet deprecated this over two years ago. OK sebastia
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: jas...@cvs.openbsd.org 2021/01/23 05:47:00 Modified files: devel/vte3 : Makefile distinfo Log message: update to vte3-0.62.2
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: jas...@cvs.openbsd.org 2021/01/23 05:46:26 Modified files: graphics/openimageio: Makefile Added files: graphics/openimageio/patches: patch-src_libutil_ustring_cpp Log message: fix build on powerpc64 by correcting a cpp expression for _LIBCPP_BIG_ENDIAN from brad
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: k...@cvs.openbsd.org2021/01/23 05:46:15 Modified files: sysutils/ruby-puppet/5: Makefile sysutils/ruby-puppet/6: Makefile Removed files: sysutils/ruby-puppet/pkg: README Log message: Remove obsolete README Mcollective support has been deprecated with Puppet 5.5.4, official documentation links in the README are dead. OK sebastia
Re: Add MODOCAML_RUNDEP to ocaml.port.mk
On Fri, Jan 22 2021, Bjorn Ketelaars wrote:
> On Fri 22/01/2021 08:19, Jeremie Courreges-Anglas wrote:
>> On Fri, Jan 22 2021, Bjorn Ketelaars wrote:
>> > On Thu 21/01/2021 23:29, Jeremie Courreges-Anglas wrote:
>> >> On Thu, Jan 21 2021, Stuart Henderson wrote:
>> >> > On 2021/01/21 06:43, Bjorn Ketelaars wrote:
>> >> >> On Wed 20/01/2021 21:42, Jeremie Courreges-Anglas wrote:
>> >> >> > On Wed, Jan 20 2021, Bjorn Ketelaars wrote:
>> >> >> > > (Maintainer timeout)
>> >> >> > >
>> >> >> > > ocaml is currently a RDEP for all ports that are build with it.
>> >> >> > > This is
>> >> >> > > unnecessary for a couple of them, i.e. net/unison.
>> >> >> >
>> >> >> > As far as I know, programs written in OCaml should run without the
>> >> >> > OCaml
>> >> >> > runtime installed on ${OCAML_NATIVE_ARCHS}, currently i386 and amd64.
>> >> >> > Except for OCaml programs that make direct use of the OCaml runtime,
>> >> >> > of
>> >> >> > course... But the rundep is still needed on non-native archs.
>> >> >> >
>> >> >> > > I would like to
>> >> >> > > propose the addition of MODOCAML_RUNDEP and MODOCAML_BUILDDEP,
>> >> >> > > which are
>> >> >> > > modelled on python.port.mk.
>> >> >> > >
>> >> >> > > Default behaviour is not changed. Setting MODOCAML_RUNDEP=No in a
>> >> >> > > Makefile excludes ocaml as RDEP.
>> >> >> > >
>> >> >> > > OK?
>> >> >> >
>> >> >> > Your diff makes sense I think, but you can't just use it to
>> >> >> > disable the run-dep in net/unison: you'd break unison installs on
>> >> >> > non-native archs.
>> >> >>
>> >> >> Oops, I didn't think about the above.
>> >> >>
>> >> >> I will look further for a fitting, clean solution that serves all
>> >> >> arches.
>> >> >>
>> >> >
>> >> > Maybe allow MODOCAML_RUNDEP=yes/no/nonative or some similar thing?
>> >>
>> >> Hmm, so "nonative" would be for ports that produce bytecode-only
>> >> programs, even on native archs? (No idea how many ports are affected.)
>> >> We could call it "bytecode" then, that would seem a bit more descriptive
>> >> than a plain MODOCAML_RUNDEP=Yes in a port Makefile.
>> >>
>> >> And then MODOCAML_RUNDEP=Yes would be useful for ports that always
>> >> use lang/ocaml programs/files at runtime?
>> >>
>> >> > It would be nice to handle the arch detection in ocaml.port.mk rather
>> >> > than in any port using this.
>> >>
>> >> Here's the simple diff I had in mind yesterday, on top of Bjorn's diff.
>> >> It probably helps Bjorn with unison but it would require testing all
>> >> other OCaml programs, and bumping REVISION for a bunch of them.
>> >> Maybe not the easiest or safest approach.
>> >>
>> >> I suspect that most people caring about OCaml in ports have thought
>> >> about this before, hopefully they can share their ideas. :)
>> >
>> > I'm not particular fond of testing all other OCaml programs.
>> >
>> > What do you think of the diff below; lang/ocaml is added to
>> > BUILD_DEPENDS and RUN_DEPENDS unless native-code compilation is possible
>> > *and* the port specifically requests not to.
>> >
>> > lang/ocaml is always added in cases of ! ${OCAML_NATIVE_ARCHS}, and
>> > 'make show=MODOCAML_RUNDEP' would show 'Ignored as native-code
>> > compilation is not supported on this platform'.
>> >
>> >
>> > diff --git ocaml.port.mk ocaml.port.mk
>> > index bda7f1fc763..b5e9c863089 100644
>> > --- ocaml.port.mk
>> > +++ ocaml.port.mk
>> > @@ -33,8 +33,27 @@ MODOCAML_OCAMLDOC?=ocamldoc
>> > PKG_ARGS+=-Ddynlink=0
>> > .endif
>> >
>> > -RUN_DEPENDS +=lang/ocaml
>> > -BUILD_DEPENDS += lang/ocaml
>> > +MODOCAML_RUN_DEPENDS= lang/ocaml
>> > +MODOCAML_BUILD_DEPENDS= ${MODOCAML_RUN_DEPENDS}
>> > +
>> > +# Add lang/ocaml to BUILD_DEPENDS and RUN_DEPENDS unless native-code
>> > +# compilation is possible (OCAML_NATIVE_ARCHS) and the port
>> > +# specifically requests not to.
>> > +.if ${PROPERTIES:Mocaml_native}
>> > +MODOCAML_BUILDDEP?= Yes
>> > +MODOCAML_RUNDEP?= Yes
>> > +.else
>> > +MODOCAML_BUILDDEP:= Ignored as native-code compilation is not
>> > supported on this platform
>>
>> You still need ocaml at build time, to build the bytecode and other things.
>
> I agree!
>
> It is highly unlikely that one would want to use MODOCAML_BUILDDEP=No in
> a Makefile. I can't think of any reason for offering this knob except
> that it mimics erlang/go/lua/php/python/ruby.
Unlikely but valid, just think of a port that would use OCaml scripts at
runtime. (You can write OCaml scripts with a shebang line.)
Anyway I think it's good to allow anything in a module to be disabled,
else people tend to resort to hacks to work around hardcoded choices.
> Usage of this knob will result in failure early on. BTW if you set
> MODOCAML_BUILDDEP=No in a Makefile *and* build on a non-native arch
> lang/ocaml will still be added to BUILD_DEPENDS.
Well I misunderstood the intent of your diff, I'll blame it on my coffee
depriveness. :)
>> > +MODOCAML_RUNDEP:= ${MODOCAML_BUILDDEP}
>>
>> Should still use ?= I think.
>
>
UPDATE: mail/imapfilter to 2.7.5
Find attached a diff that updates imapfilter to latest release 2.7.5.
Builds now with pcre2 and needs a patch for linking against libressl.
Nathanael, could you check it works for you?
feedback and OKs are welcome,
Thanks,
- gsoares
Index: Makefile
===
RCS file: /cvs/ports/mail/imapfilter/Makefile,v
retrieving revision 1.24
diff -u -p -r1.24 Makefile
--- Makefile12 Jul 2019 20:47:28 - 1.24
+++ Makefile23 Jan 2021 11:17:52 -
@@ -2,7 +2,7 @@
COMMENT= remote IMAP filtering utility
-V= 2.6.11
+V= 2.7.5
DISTNAME= imapfilter-${V}
GH_TAGNAME=v${V}
@@ -16,12 +16,12 @@ MAINTAINER= Gleydson Soares = 0x1010L
++#if OPENSSL_VERSION_NUMBER >= 0x1010L && !defined(LIBRESSL_VERSION_NUMBER)
+ SSL_set_hostflags(ssn->sslconn,
+ X509_CHECK_FLAG_NO_PARTIAL_WILDCARDS);
+ if (!SSL_set1_host(ssn->sslconn, ssn->server)) {
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: t...@cvs.openbsd.org2021/01/23 05:24:04 Modified files: net/py-tlslite-ng: Makefile distinfo net/py-tlslite-ng/pkg: PLIST Log message: update to py-tlslite-ng 0.8.0-alpha40 * fix wrong error message in AES implementation (Bernt Røskar Brenna) * fix API break caused by the workaround for Bleichenbacher; RSA keys generated in-memory with m2crypto wouldn't work for decryption/encryption * handle too short RSA ciphertexts for the key size consistently between backends
[macppc] Fix devel/liboil runtime
Hi,
This diff is a follow up for the very recent liboil fix for powerpc64.
While trying to fix the issue on powerpc64 through macppc, which was
experiencing the same issue without using gas(1), i've found out that
our current CVS version of liboil has 18 tests failures on macppc.
The below diff removes the powerpc optimisations also on macppc,
leaving out only one test failure [1].
Note that the arm part was a wild guess from jca@ and i, but it does
not fix the build [2].
Comments and feedback are welcome,
Charlène.
[1] https://bin.charlenew.xyz/liboil.log
[2] http://build-failures.rhaalovely.net/arm/2020-11-20/devel/liboil.log
Index: Makefile
===
RCS file: /cvs/ports/devel/liboil/Makefile,v
retrieving revision 1.24
diff -u -p -u -p -r1.24 Makefile
--- Makefile28 Apr 2020 18:38:41 - 1.24
+++ Makefile23 Jan 2021 11:26:52 -
@@ -3,7 +3,7 @@
COMMENT= library of optimized inner loops
DISTNAME= liboil-0.3.17
-REVISION= 3
+REVISION= 4
CATEGORIES=devel
MASTER_SITES= ${HOMEPAGE}/download/
@@ -18,10 +18,5 @@ WANTLIB= c m
CONFIGURE_STYLE= gnu
CONFIGURE_ARGS=--disable-glib
-
-# Workaround for invalid assembly code with clang
-.if ${MACHINE_ARCH:Mpowerpc} || ${MACHINE_ARCH:Marm}
-CFLAGS+= -fno-integrated-as
-.endif
.include
Index: patches/patch-configure
===
RCS file: patches/patch-configure
diff -N patches/patch-configure
--- /dev/null 1 Jan 1970 00:00:00 -
+++ patches/patch-configure 23 Jan 2021 11:26:52 -
@@ -0,0 +1,16 @@
+$OpenBSD$
+
+Disable all powerpc* optimisations, they're all full of gcc isms
+
+Index: configure
+--- configure.orig
configure
+@@ -11645,7 +11645,7 @@ $as_echo "#define HAVE_AMD64 1" >>confdefs.h
+
+ ;;
+ xpowerpc|xppc|xpowerpc64|xppc64)
+- HAVE_POWERPC=yes
++ HAVE_POWERPC=no
+
+ $as_echo "#define HAVE_POWERPC 1" >>confdefs.h
+
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs
Module name:ports
Changes by: jas...@cvs.openbsd.org 2021/01/23 05:04:10
Modified files:
graphics/darktable: Makefile
Log message:
set NOT_FOR_ARCHS=${BE_ARCHS}, darktable even advertises being little
endian-only
in is_supported_platform.h so there's little point in attempting to build this
anywhere else.
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: jas...@cvs.openbsd.org 2021/01/23 04:44:27 Modified files: devel/liboil : Makefile Added files: devel/liboil/patches: patch-m4_as-host-defines_m4 Log message: bypass the HAVE_POWERPC check for powerpc64 this prevents it from attempting (and failing) to compile the assembly code which clang isn't happy with. from brad
Re: Alpine mail client. Fresh install of 6.8. "Mail" works but Alpine problems
Hi Austin, aus...@computershop.ca wrote: > 2) Any reason why the new pseudo-Sendmail wouldn't handle Apline as > well as the old one did? This mailing list is mostly for porting work and not for questions about functionality or bugs that are not related to the porting process but the software itself. That being said, I played around with alpine. You're right. If you leave "smtp-server=" empty, sending an email gets stuck as you described. I've tried to set "smtp-server=" to localhost as well as to my SMTP/SMTPs OpenSMTPd server. Those configurations are working fine and maybe you can use one of these? Why it gets stuck when falling back to the sendmail binary, I don't know. Using the sendmail binary manually is working here. The correct list to address this would be: https://opensmtpd.org/list.html Best Regards, Stefan
Re: [update] graphics/scrot 0.8 to 1.4
Stefan Hagen wrote:
> Scrots new home:
> https://github.com/resurrecting-open-source-projects/scrot
It's probably relevant to say that this new upstream is also used
by Debian, Arch and FreeBSD (I did not check others).
Here is an updated patch with the following additions:
+ added pledge similiar to solenes scrot update in 2019
+ removed -g cflag
+ subst /usr/X11R6 with ${X11BASE} in Makefile.am
Note: I'm not super comfortable yet with selecting pledge promises.
I removed all promises and then ktraced the command below and added
pledge promises according to the trace output.
scrot '%Y-%m-%d_$wx$h-TEST.png' \
-e 'mv $f ~/work/' -s -d 2 -f -c -b -l style=dash,width=3,color="red" \
-p -o -n "-f '~/.fonts/AnonymiceNerdFontComplete.ttf/24'
I think this command should tick all boxes and I ended up with the same
set of promises as solene did. So I assume I did it right.
Best Regards,
Stefan
Index: graphics/scrot/Makefile
===
RCS file: /cvs/ports/graphics/scrot/Makefile,v
retrieving revision 1.17
diff -u -p -u -p -r1.17 Makefile
--- graphics/scrot/Makefile 12 Jul 2019 20:47:10 - 1.17
+++ graphics/scrot/Makefile 23 Jan 2021 10:01:58 -
@@ -2,25 +2,29 @@
COMMENT= commandline screen capture util
-DISTNAME= scrot-0.8
-REVISION = 4
-CATEGORIES=graphics
+GH_ACCOUNT = resurrecting-open-source-projects
+GH_PROJECT = scrot
+GH_TAGNAME = 1.4
-HOMEPAGE= http://www.linuxbrit.co.uk/scrot/
+CATEGORIES = graphics
+
+HOMEPAGE=
https://github.com/resurrecting-open-source-projects/scrot
# BSD
PERMIT_PACKAGE=Yes
-WANTLIB= X11 Xext c freetype m z \
- giblib>=1 Imlib2>=1
-
-MASTER_SITES= http://www.linuxbrit.co.uk/downloads/
+# pledge
+WANTLIB = c m Imlib2 giblib X11 Xcomposite Xfixes
-LIB_DEPENDS=devel/giblib \
+LIB_DEPENDS = devel/giblib \
graphics/imlib2
-CONFIGURE_STYLE= gnu
+AUTOMAKE_VERSION = 1.16
+AUTOCONF_VERSION = 2.69
+
+AUTORECONF = sh autogen.sh
+CONFIGURE_STYLE= autoreconf
-FAKE_FLAGS+= docsdir=${PREFIX}/share/doc/scrot/
+BUILD_DEPENDS =devel/autoconf-archive
.include
Index: graphics/scrot/distinfo
===
RCS file: /cvs/ports/graphics/scrot/distinfo,v
retrieving revision 1.4
diff -u -p -u -p -r1.4 distinfo
--- graphics/scrot/distinfo 18 Jan 2015 03:14:14 - 1.4
+++ graphics/scrot/distinfo 23 Jan 2021 10:01:58 -
@@ -1,2 +1,2 @@
-SHA256 (scrot-0.8.tar.gz) = YT0c9STCtizjxl8SMupPBcfa8kjV6C/ypoksmAk5lPI=
-SIZE (scrot-0.8.tar.gz) = 74324
+SHA256 (scrot-1.4.tar.gz) = 4Z7sabzcJJkXxFInDhyPKBiAA7BSw1LiWZmygcsDUQw=
+SIZE (scrot-1.4.tar.gz) = 157779
Index: graphics/scrot/patches/patch-Makefile_am
===
RCS file: graphics/scrot/patches/patch-Makefile_am
diff -N graphics/scrot/patches/patch-Makefile_am
--- /dev/null 1 Jan 1970 00:00:00 -
+++ graphics/scrot/patches/patch-Makefile_am23 Jan 2021 10:01:58 -
@@ -0,0 +1,16 @@
+$OpenBSD$
+
+Index: Makefile.am
+--- Makefile.am.orig
Makefile.am
+@@ -31,8 +31,8 @@ AUTOMAKE_OPTIONS = 1.4 foreign
+ # A list of all the files in the current directory which can be regenerated
+ MAINTAINERCLEANFILES = Makefile.in
+
+-AM_LDFLAGS= -L/usr/X11R6/lib -L/usr/lib -L/usr/local/lib
+-AM_CPPFLAGS = -I/usr/X11R6/include \
++AM_LDFLAGS= -L${X11BASE}/lib -L/usr/lib -L/usr/local/lib
++AM_CPPFLAGS = -I${X11BASE}/include \
+ $(X_CFLAGS) -I$(prefix)/include -I$(includedir) -I.
+
+ man_MANS = man/scrot.1
Index: graphics/scrot/patches/patch-src_Makefile_am
===
RCS file: graphics/scrot/patches/patch-src_Makefile_am
diff -N graphics/scrot/patches/patch-src_Makefile_am
--- /dev/null 1 Jan 1970 00:00:00 -
+++ graphics/scrot/patches/patch-src_Makefile_am23 Jan 2021 10:01:58
-
@@ -0,0 +1,16 @@
+$OpenBSD$
+
+no need for debug symbols
+
+Index: src/Makefile.am
+--- src/Makefile.am.orig
src/Makefile.am
+@@ -28,7 +28,7 @@
+ MAINTAINERCLEANFILES = Makefile.in
+
+ AM_LDFLAGS= -L/usr/X11R6/lib
+-AM_CPPFLAGS = -g -O3 -Wall -I/usr/X11R6/include \
++AM_CPPFLAGS = -O3 -Wall -I/usr/X11R6/include \
+ $(X_CFLAGS) -I$(prefix)/include -I$(includedir) -I. \
+ -DPREFIX=\""$(prefix)"\" @GIBLIB_CFLAGS@
+ LIBOBJS = @LIBOBJS@
Index: graphics/scrot/patches/patch-src_Makefile_in
===
RCS file: graphics/scrot/patches/patch-src_Makefile_in
diff -N graphics/scrot/patches/patch-src_Makefile_in
--- graphics/scrot/patches/patch-src_Makefile_in8 Jul 2011 11:25:47
- 1.2
+++
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: ajacou...@cvs.openbsd.org 2021/01/23 02:50:10 Modified files: x11/vlc: Makefile distinfo x11/vlc/pkg: PLIST-main Removed files: x11/vlc/patches: patch-modules_gui_qt_components_playlist_views_cpp patch-modules_gui_qt_dialogs_plugins_hpp patch-modules_gui_qt_util_timetooltip_hpp Log message: Update to vlc-3.0.12. from Brad (maintainer)
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: ajacou...@cvs.openbsd.org 2021/01/23 02:45:49 Modified files: sysutils/terraform: Makefile distinfo Log message: Update to terraform-0.14.5.
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: gonz...@cvs.openbsd.org 2021/01/23 02:41:00 Modified files: security : Makefile Log message: Hook Gobuster
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: gonz...@cvs.openbsd.org 2021/01/23 02:39:23 Log message: Looks good, OK abieber@ Status: Vendor Tag: gonzalo Release Tags: gonzalo_20212301 N ports/security/gobuster/Makefile N ports/security/gobuster/distinfo N ports/security/gobuster/pkg/DESCR N ports/security/gobuster/pkg/PLIST No conflicts created by this import
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: ajacou...@cvs.openbsd.org 2021/01/23 02:36:28 Modified files: sysutils/awscli: Makefile distinfo Log message: Update to awscli-1.18.219.
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: ajacou...@cvs.openbsd.org 2021/01/23 02:36:14 Modified files: net/py-boto3 : Makefile distinfo Log message: Update to py3-boto3-1.16.59.
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: ajacou...@cvs.openbsd.org 2021/01/23 02:36:04 Modified files: net/py-botocore: Makefile distinfo net/py-botocore/pkg: PLIST Log message: Update to py3-botocore-1.19.59.
Re: Update xine-lib to 1.2.11
On Sun, Jan 17, 2021 at 03:50:17PM -0500, Brad Smith wrote:
> On Thu, Jan 14, 2021 at 07:48:02PM -0500, Brad Smith wrote:
> > On Thu, Jan 14, 2021 at 12:31:34AM +, a...@sdf.org wrote:
> > > Hello,
> > >
> > > This update xine-lib to version 1.2.11.
> > > A lot of code from patches had been applied upstream.
> > >
> > > Tested in arm64.
> > >
> > > xine-lib/1.2.11/README.txt:
> > >
> > > xine-lib (1.2.11) 2020-12-06
> > > * Add gopher input plugin.
> > > * Add user settings for IPv6.
> > > * Split a52 spdif output to separate decoder.
> > > * Code cleanup.
> > > * More engine optimization.
> > > * Small optimizations (opengl2, dvb subtitles, png, mpeg-ts).
> > > * Better A/V sync.
> > > * Fix a few crashes.
> > > * Fix bluray playback.
> > > * Fix VAAPI picture jitter and green flashes.
> > > * Fix Opus and EAC3 audio playback.
> > > * Fix text subtitles.
> > > * Fix mpeg-ts (hdmv mode, detection of cut TV recordings).
> > > * Fix mpeg layer 1-4 audio timing.
> > > * Fix some VDR issues.
> > > * Fix HLS VOD mode.
> > > * Many small fixes.
> > > * Build fixes.
> > > * BSD fixes.
> > > * Update german translation.
> > > * Update internal libdca to upstream 0.0.7.
> > >
> > > Regards,
> > > adr.
> >
> > This is missing patch removals. Here is a more appropriate diff..
>
> I almost forgot. I do a major bump whenever the API rev is bumped.
Committed, thanks.
>
>
> Index: Makefile
> ===
> RCS file: /home/cvs/ports/multimedia/xine-lib/Makefile,v
> retrieving revision 1.145
> diff -u -p -u -p -r1.145 Makefile
> --- Makefile 20 Mar 2020 16:44:25 - 1.145
> +++ Makefile 17 Jan 2021 20:47:36 -
> @@ -2,12 +2,12 @@
>
> COMMENT= multimedia decoding library
>
> -DISTNAME=xine-lib-1.2.10
> +DISTNAME=xine-lib-1.2.11
> CATEGORIES= multimedia
> MASTER_SITES=${MASTER_SITE_SOURCEFORGE:=xine/}
> EXTRACT_SUFX=.tar.xz
>
> -SHARED_LIBS= xine35.0
> +SHARED_LIBS= xine36.0
>
> HOMEPAGE=https://www.xine-project.org/
>
> @@ -28,7 +28,7 @@ WANTLIB += xcb-dri2 xcb-dri3 xcb-glx xcb
> WANTLIB += xcb-sync xcb-xfixes xcb-xv xdg-basedir xml2 xshmfence
> WANTLIB += xvidcore z
>
> -XINEAPI_REV= 2.8
> +XINEAPI_REV= 2.9
> SUBST_VARS+= XINEAPI_REV
>
> COMPILER=base-clang ports-gcc
> Index: distinfo
> ===
> RCS file: /home/cvs/ports/multimedia/xine-lib/distinfo,v
> retrieving revision 1.31
> diff -u -p -u -p -r1.31 distinfo
> --- distinfo 25 Dec 2019 15:50:45 - 1.31
> +++ distinfo 14 Jan 2021 23:25:26 -
> @@ -1,2 +1,2 @@
> -SHA256 (xine-lib-1.2.10.tar.xz) =
> nLPwadPB/7dFbqkak2qFu7B6wqt74enQ0slP/kEQ3Fc=
> -SIZE (xine-lib-1.2.10.tar.xz) = 5226116
> +SHA256 (xine-lib-1.2.11.tar.xz) =
> 71GyHRDdoQRfp9cRvZFxz9rwpaKHQjO88W/98o7AcAU=
> +SIZE (xine-lib-1.2.11.tar.xz) = 5282204
> Index: patches/patch-configure_ac
> ===
> RCS file: /home/cvs/ports/multimedia/xine-lib/patches/patch-configure_ac,v
> retrieving revision 1.22
> diff -u -p -u -p -r1.22 patch-configure_ac
> --- patches/patch-configure_ac25 Dec 2019 15:50:45 - 1.22
> +++ patches/patch-configure_ac15 Jan 2021 00:05:22 -
> @@ -3,7 +3,7 @@ $OpenBSD: patch-configure_ac,v 1.22 2019
> Index: configure.ac
> --- configure.ac.orig
> +++ configure.ac
> -@@ -891,9 +891,7 @@ AC_ARG_ENABLE([optimizations],
> +@@ -888,9 +888,7 @@ AC_ARG_ENABLE([optimizations],
> [AS_HELP_STRING([--disable-optimizations], [Don't try to
> guess what optimization to enable])],
> [], [test x"$enable_debug" != x"no" &&
> enable_optimizations="no"])
> AM_CONDITIONAL([DISABLE_OPTIMIZATIONS], [test x"$enable_optimizations" =
> x"no"])
> @@ -14,7 +14,7 @@ Index: configure.ac
> dnl For multi-pass compilation: never when cross-compiling
> if test x"$cross_compiling" != x"yes"; then
> if test x"$GCC" = x"yes"; then
> -@@ -914,7 +912,7 @@ AC_SUBST(O0_CFLAGS)
> +@@ -911,7 +909,7 @@ AC_SUBST(O0_CFLAGS)
> AC_SUBST(PASS1_CFLAGS)
> AC_SUBST(PASS2_CFLAGS)
>
> @@ -23,7 +23,7 @@ Index: configure.ac
>
>
> dnl xineutils.h:dlist_*
> -@@ -1297,9 +1295,9 @@ t q
> +@@ -1324,9 +1322,9 @@ t q
> b
> :q
> q"
> Index: patches/patch-include_xine_buffer_h
> ===
> RCS file: patches/patch-include_xine_buffer_h
> diff -N patches/patch-include_xine_buffer_h
> --- patches/patch-include_xine_buffer_h 25 Dec 2019 15:50:45 -
> 1.3
> +++ /dev/null 1 Jan 1970 00:00:00 -
> @@ -1,15 +0,0 @@
> -$OpenBSD: patch-include_xine_buffer_h,v 1.3 2019/12/25 15:50:45 ajacoutot
> Exp $
> -
> -Include pthread.h (BSD fix).
> -
> -Index: include/xine/buffer.h
> include/xine/buffer.h.orig
> -+++ include/xine/buffer.h
> -@@ -37,6 +37,7 @@ extern "C"
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: ajacou...@cvs.openbsd.org 2021/01/23 02:27:50 Modified files: multimedia/xine-lib: Makefile distinfo multimedia/xine-lib/patches: patch-configure_ac patch-m4_decoders_m4 patch-m4_input_m4 patch-src_xine-utils_memcpy_c multimedia/xine-lib/pkg: PLIST Removed files: multimedia/xine-lib/patches: patch-include_xine_buffer_h patch-include_xine_xineutils_h patch-src_demuxers_demux_ts_c patch-src_input_http_helper_c patch-src_input_input_cdda_c patch-src_input_input_http_c patch-src_vdr_input_vdr_c patch-src_xine-engine_builtins_h patch-src_xine-engine_load_plugins_c patch-src_xine-utils_xmlparser_c Log message: Update to xine-lib-1.2.11. from adr at SDF.ORG with tweaks from Brad (maintainer)
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: ajacou...@cvs.openbsd.org 2021/01/23 02:23:08 Modified files: graphics/GraphicsMagick: Makefile distinfo graphics/GraphicsMagick/patches: patch-configure graphics/GraphicsMagick/pkg: PLIST Log message: Update to GraphicsMagick-1.3.36. from Brad (maintainer)
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: k...@cvs.openbsd.org2021/01/23 02:22:47 Modified files: audio/umurmur : Makefile distinfo audio/umurmur/patches: patch-src_CMakeLists_txt patch-src_client_c patch-src_conf_c patch-src_config_h_in patch-src_messagehandler_c patch-src_server_c audio/umurmur/pkg: PLIST Log message: update to umurmur 0.2.18 https://github.com/umurmur/umurmur/releases/tag/0.2.18 (no changelog, 7 minor commits/changes since last release) Diff from Jonathon Sisson (maintainer), thanks Tweaks from me
Re: [UPDATE] audio/umurmur 0.2.17 -> 0.2.18
On Fri, Jan 22, 2021 at 08:54:08PM -0600, J Sisson wrote: > Are there any modifications or adjustments that need to be made with this > patch? REVISION ought to go when bumping the version. It is not an error to leave it and stuff will work, but illogical. `make update-plist' reordered the rc(8) script; not an error, but that implies that you did not run the `update-plist' to check for new and/or removed files -- that should always be done when working on ports. I'll commit your diff with both "fixes", thanks.
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: ajacou...@cvs.openbsd.org 2021/01/23 01:55:21 Modified files: security/libgcrypt: Makefile Added files: security/libgcrypt/patches: patch-cipher_kdf_c Log message: Unbreak selftest (from upstream): - kdf: add missing null-terminator for self-test test-vector array - kdf: make self-test test-vector array read-only
Re: [NEW] graphics/libspiro 20200505
On Sun, Jan 17, 2021 at 4:46 AM Alessandro De Laurenzis wrote: > A year ago there has been an attempt to import this library (see [1]). > At that time the port was put "on-hold" since there were 2 issues in the > test suite; upstream has closed both as "resolved" (see [2] and [3]) and > I can confirm that now all tests pass on amd64 (it would be better to > double-check on spark64 too, since kurt@ reported similar issues there). > > W.r.t. Frederic's port, in the attached one I updated the version to > 20200505, added PKGNAME and WRKDIST variables into the Makefile (plus a > comment explaining the reason why gnu LIBTOOL is used) and changed a bit > the formatting in DESCR (also making more evident the attribution to the > original author). > > I need this port to update graphics/ipe to the latest release, since the > distribution no more includes spiro's sources. > > Hope it can be imported now. ok bentley@ Frederic, do you still want to be MAINTAINER?
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: dan...@cvs.openbsd.org 2021/01/23 01:08:55 Modified files: www/apertium-apy: Makefile Added files: www/apertium-apy/patches: patch-apertium_apy_gateway_py patch-apertium_apy_handlers_base_py patch-apertium_apy_handlers_list_modes_py patch-apertium_apy_handlers_stats_py patch-setup_py Log message: repair the apertium-apy build This port was missed during the tests for the py-tornado update. Fix the build of apertium-apy by backporting commit 15cfa135 from upstream. Breakage originally reported by naddy@, then by sthen@. bket@ had the same fix on ports@ ok bentley@ (MAINTAINER), sthen@
