CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: giova...@cvs.openbsd.org2021/12/14 00:53:57 Modified files: mail/maildrop : Makefile distinfo mail/maildrop/patches: patch-libs_maildir_Makefile_am patch-libs_maildir_Makefile_in patch-libs_maildrop_configure patch-libs_maildrop_deliver_C patch-libs_maildrop_maildropfilter_7_in patch-libs_rfc2045_reformime_1 Log message: bugfix update to 3.0.3
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: giova...@cvs.openbsd.org2021/12/14 00:51:25 Modified files: mail/courier-imap: Makefile distinfo mail/courier-imap/patches: patch-libs_maildir_Makefile_in patch-libs_maildir_configure Log message: update to 5.1.4
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: giova...@cvs.openbsd.org2021/12/14 00:49:40 Modified files: mail/courier-authlib/pkg: PLIST-main mail/courier-authlib/patches: patch-Makefile_in mail/courier-authlib: Makefile distinfo Log message: update to 0.71.3
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: giova...@cvs.openbsd.org2021/12/14 00:47:36 Modified files: mail/courier-unicode: Makefile distinfo mail/courier-unicode/pkg: PLIST Log message: update to 2.2.3
Re: lang/racket-minimal: update to v8.3
On Sun, Nov 28, 2021 at 10:46:28AM +0100, Denis Fondras wrote: > Straightforward update to v8.3 It looks like the update to 8.3 broke the "raco exe" command. angel ~ $ raco exe /usr/local/bin/raco: Unrecognized command: exe -- James
security/ghidra - replace log4j
The latest Ghidra release 10.1 has a fix for the log4j vulnerability;
however, updating the port to that version is very complex and
unfortunately I do not have enough time to work on it at the moment.
As a workaround, this diff updates the log4j jar files in
security/ghidra to 2.15.0. I was about to fetch the log4j jar files
from https://logging.apache.org/log4j/2.x/download.html when I noticed
sthen's net/unifi update which fetches them from spacehopper.org
instead. This diff uses the latter approach.
ok?
Index: Makefile
===
RCS file: /cvs/ports/security/ghidra/Makefile,v
retrieving revision 1.8
diff -u -p -r1.8 Makefile
--- Makefile19 Jul 2020 01:29:23 - 1.8
+++ Makefile14 Dec 2021 04:43:32 -
@@ -7,6 +7,7 @@ COMMENT = software reverse engineering (
VERSION = 9.1.2
GHIDRA_DATE = 20200212
+REVISION = 0
GH_ACCOUNT = NationalSecurityAgency
GH_PROJECT = ghidra
@@ -27,6 +28,7 @@ WANTLIB +=c m ${COMPILER_LIBCXX}
MASTER_SITES0 =${HOMEPAGE}
MASTER_SITES1 =
https://sourceforge.net/projects/yajsw/files/yajsw/yajsw-stable-${YAJSW_VER}/
MASTER_SITES2 =https://repo.maven.apache.org/maven2/
+MASTER_SITES3 =https://spacehopper.org/mirrors/
EXTRACT_SUFX = .zip
@@ -37,6 +39,7 @@ JMOCKIT_VER = 1.44
JSON_SIMPLE_VER = 1.1.1
JUNIT_VER =4.12
YAJSW_VER =12.12
+LOG4J_VER =2.15.0
# Note that ST4-${ST4_VER}.jar is only needed during build for antlr; it is not
# needed at runtime and therefore does not need to be packed.
@@ -51,6 +54,8 @@ DISTFILES = ${DISTNAME}.tar.gz
DISTFILES += ghidra_${VERSION}_PUBLIC_${GHIDRA_DATE}${EXTRACT_SUFX}:0
DISTFILES += yajsw-stable-${YAJSW_VER}${EXTRACT_SUFX}:1
DISTFILES += ${JAR_DISTFILES:C/$/:2/}
+DISTFILES += log4j-api-${LOG4J_VER}.jar:3
+DISTFILES += log4j-core-${LOG4J_VER}.jar:3
EXTRACT_ONLY = ${DISTNAME}.tar.gz
@@ -138,5 +143,10 @@ do-install:
ln -s ${TRUEPREFIX}/share/java/ghidra/ghidraRun ${PREFIX}/bin/ghidraRun
${INSTALL_SCRIPT}
${WRKSRC}/Ghidra/RuntimeScripts/Linux/support/launch.sh \
${PREFIX}/share/java/ghidra/support/launch.sh
+ rm -f
${PREFIX}/share/java/ghidra/Ghidra/Framework/Generic/lib/log4j-{api,core}-*.jar
+ ${INSTALL_DATA} ${FULLDISTDIR}/log4j-api-${LOG4J_VER}.jar \
+ ${PREFIX}/share/java/ghidra/Ghidra/Framework/Generic/lib/
+ ${INSTALL_DATA} ${FULLDISTDIR}/log4j-core-${LOG4J_VER}.jar \
+ ${PREFIX}/share/java/ghidra/Ghidra/Framework/Generic/lib/
.include
Index: distinfo
===
RCS file: /cvs/ports/security/ghidra/distinfo,v
retrieving revision 1.4
diff -u -p -r1.4 distinfo
--- distinfo19 Jul 2020 01:29:23 - 1.4
+++ distinfo14 Dec 2021 04:43:32 -
@@ -6,6 +6,8 @@ SHA256 (javacc-5.0.jar) = cRExYbyM9mQVFV
SHA256 (jmockit-1.44.jar) = GXSZN1EzMkhCbdusNwpgSUTt9mXBPUakxelz5N2PqUo=
SHA256 (json-simple-1.1.1.jar) = TmlpaJK4i0HFXUmrL9zCHurZK/VKzFiMAFBZbDt1GZw=
SHA256 (junit-4.12.jar) = WXIfCAXiI9hLkGd4h9n/Vn3FNNfFAsqQPAwrF/BcEWo=
+SHA256 (log4j-api-2.15.0.jar) = yMM+fo4FSW2uac8MqsjDCSz/2TehZFJukpItLVZtClU=
+SHA256 (log4j-core-2.15.0.jar) = QZqFEolZcbe09PM+Yg02ElTlyVUrkEsEdLCd3UpqIgs=
SHA256 (yajsw-stable-12.12.zip) = E5j8sek6uxmZLE+gbX/ldYqrtMRXgdfvMGxvV8p6cyE=
SIZE (ST4-4.1.jar) = 253043
SIZE (ghidra-9.1.2.tar.gz) = 59623429
@@ -15,4 +17,6 @@ SIZE (javacc-5.0.jar) = 298569
SIZE (jmockit-1.44.jar) = 757982
SIZE (json-simple-1.1.1.jar) = 23931
SIZE (junit-4.12.jar) = 314932
+SIZE (log4j-api-2.15.0.jar) = 301804
+SIZE (log4j-core-2.15.0.jar) = 1789769
SIZE (yajsw-stable-12.12.zip) = 25051676
Index: pkg/PLIST
===
RCS file: /cvs/ports/security/ghidra/pkg/PLIST,v
retrieving revision 1.4
diff -u -p -r1.4 PLIST
--- pkg/PLIST 19 Jul 2020 01:29:23 - 1.4
+++ pkg/PLIST 14 Dec 2021 04:43:34 -
@@ -2304,8 +2304,8 @@ share/java/ghidra/Ghidra/Framework/Gener
share/java/ghidra/Ghidra/Framework/Generic/lib/commons-lang3-3.9.jar
share/java/ghidra/Ghidra/Framework/Generic/lib/guava-19.0.jar
share/java/ghidra/Ghidra/Framework/Generic/lib/jdom-legacy-1.1.3.jar
-share/java/ghidra/Ghidra/Framework/Generic/lib/log4j-api-2.8.2.jar
-share/java/ghidra/Ghidra/Framework/Generic/lib/log4j-core-2.8.2.jar
+share/java/ghidra/Ghidra/Framework/Generic/lib/log4j-api-2.15.0.jar
+share/java/ghidra/Ghidra/Framework/Generic/lib/log4j-core-2.15.0.jar
share/java/ghidra/Ghidra/Framework/Graph/
share/java/ghidra/Ghidra/Framework/Graph/LICENSE.txt
share/java/ghidra/Ghidra/Framework/Graph/Module.manifest
Update msmtp 1.8.19 and remove from maintainer
Hi, Please find in the attached diff updates mail/msmtp to 1.8.19. Also as my involvement in maintaining this port has become more and more infrequent it doesn't serve a good example of maintainership so I'm removing myself as well. Thanks. Index: Makefile === RCS file: /cvs/ports/mail/msmtp/Makefile,v retrieving revision 1.49 diff -u -p -r1.49 Makefile --- Makefile 8 Jul 2021 10:05:11 - 1.49 +++ Makefile 14 Dec 2021 04:32:36 - @@ -2,12 +2,10 @@ COMMENT = SMTP plugin for MUAs -DISTNAME = msmtp-1.8.15 +DISTNAME = msmtp-1.8.19 CATEGORIES = mail HOMEPAGE = https://marlam.de/msmtp/ - -MAINTAINER = Xiyue Deng # GPLv3+ PERMIT_PACKAGE = Yes Index: distinfo === RCS file: /cvs/ports/mail/msmtp/distinfo,v retrieving revision 1.32 diff -u -p -r1.32 distinfo --- distinfo 8 Jul 2021 10:05:11 - 1.32 +++ distinfo 14 Dec 2021 04:32:36 - @@ -1,2 +1,2 @@ -SHA256 (msmtp-1.8.15.tar.xz) = ImXcY56/Lt8waf/+CjvXZ0n4tY9AAdXN6uGYc5SQmc4= -SIZE (msmtp-1.8.15.tar.xz) = 370736 +SHA256 (msmtp-1.8.19.tar.xz) = NKHhmBF2h02+TuZu4NkQPJCYmqTc3Ehh5N4Fzn5EUms= +SIZE (msmtp-1.8.19.tar.xz) = 383100 signature.asc Description: PGP signature
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: st...@cvs.openbsd.org 2021/12/13 17:52:00 Modified files: security/letsencrypt: Makefile.inc security/letsencrypt/client: distinfo security/letsencrypt/py-acme: distinfo Log message: update to certbot/py3-acme-1.22.0
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: st...@cvs.openbsd.org 2021/12/13 17:27:20 Modified files: lang/cython: Makefile distinfo Log message: update to py-cython-0.29.25, attempt #2
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: st...@cvs.openbsd.org 2021/12/13 17:26:46 Modified files: devel/py-gevent: Makefile distinfo devel/py-gevent/pkg: PLIST Added files: devel/py-gevent/patches: patch-_setuputils_py Log message: update to py-gevent-21.12.0, and patch to avoid picking up cython (there are pregenerated files anyway, but if present at build time they will be rebuilt, and some extra files are generated with different hashes than the bundled ones)
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: st...@cvs.openbsd.org 2021/12/13 15:44:02 Modified files: net/wireshark : Makefile distinfo net/wireshark/patches: patch-CMakeLists_txt patch-rawshark_c net/wireshark/pkg: PLIST-main PLIST-text Added files: net/wireshark/patches: patch-capture_capture-pcap-util_c Removed files: net/wireshark/patches: patch-caputils_capture-pcap-util_c Log message: update to wireshark-3.6.0
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: st...@cvs.openbsd.org 2021/12/13 15:15:00 Modified files: net/unifi : Makefile.inc net/unifi/5.14 : Makefile distinfo net/unifi/5.14/pkg: PLIST net/unifi/5.6 : Makefile net/unifi/6.0 : Makefile distinfo net/unifi/6.0/pkg: PLIST net/unifi/main : Makefile net/unifi/main/files: unifi.sh net/unifi/main/pkg: PLIST Log message: unifi: replace log4j install on 5.14 / 6.0 with the fixed version (5.6 has too old a version to replace and has had no security updates since 2018 anyway) adjust how symlinks are done to make it clearer that .jars are replaced
Re: Please read. Another try at a complex new port. Problems I have and hope against.
> I really don't understand at all how the postgresql-mod.mk works. > I know what it accomplishes, but I would love to actually "get it". > Most of what I do besides porting uses postgresql. It is only useful if you are running regression tests that need to access a postgresql database. It runs a server listening on a unix socket with a temporary database in the port work directory, and sets up environment variables so that most software using it in tests can access it, without interfering with any real database running on the machine. Outside of tests it does nothing. Most software that uses postgresql does not use the module.
Re: Please read. Another try at a complex new port. Problems I have and hope against.
On Mon, Dec 13, 2021 at 08:00:02PM +, Stuart Henderson wrote: > On 2021/12/13 11:18, Chris Bennett wrote: > > cpan: > > p5-CPAN-DistnameInfo > > p5-Crypt-URandom > > p5-Data-Binary > > cpan is not a valid category, it is just where portgen puts things that it > has just built, they need moving to whichever real category is most > appropriate. > I know, I just really wanted to point out on the list with this thread that there are a lot of ports involved with this. I ran this just to put up a sorta right list so that others could see that I'm not whining about having to do just a couple of ports. > > p5-DateTime-Format-Duration-ISO8601, > > p5-Email-Stuffer > > p5-Feature-Compat-Try > > p5-File-PathList > > p5-Locale-CLDR > > p5-Locale-CLDR-Locales-Ar, > > p5-Locale-CLDR-Locales-Bg > > p5-Locale-CLDR-Locales-Ca > > I explained what to do with the CLDR-Locales ports and subdirectories before > I haven't forgotten that. I lost access to -current before I could get to them. I have re-read those older emails recently. > btw, from your mail from October > > : So, I found bringing in Core::Thingy a problem I didn't see a reasonable > way to > : accomplish. > : Who wants to review 12 new ports a once just to bring in p5-Core-Thingy? > : Submitting such a ridiculous email chain was preposterous! > : > : I never did get any advice on this aspect of the problem. Depressing. > > That is unfair, this is one of the things I explained about in my > mail from 2019, "So for the smaller perl ports I'd try to group them > with a chunk of say 3-5 closely related ports (one port plus required > dep's, or a couple of similar ports" > What I didn't see was to work outwards to inwards. It just didn't occur to me. There were some difficult problems to work out with postgresql database interactions with the p5-PGOject* ports that required a lot of work on my part and with some help. I really don't understand at all how the postgresql-mod.mk works. I know what it accomplishes, but I would love to actually "get it". Most of what I do besides porting uses postgresql. I am also working on a project for myself that I intend to release that works with neomutt and postgresql to pull out configuration files on the fly from the database. I'm using it right now to run my neomutt with different email addresses within a perl wrapper. Still very WIP. Life hands us whatever it hands us. Fair/unfair/earned/unearned/deserve/don't deserve in my opinion is all BS. Working hard or hardly working doesn't really have any effect in life. Both can produce success or failure. I think that luck runs on some kind of Bell curve. Nobody would be called lucky unless there was somebody unlucky. >From my point of view, submitting ports and watching many others getting new ports and updating existing ports committed is... I will look in the ports archives to see if any of the ports I'm working on already had work by someone else. That's a very good idea. I do listen, maybe I'm just not as bright as I used to be. }-) > Date: Mon, 4 Nov 2019 11:50:23 + > From: Stuart Henderson > To: Chris Bennett > Subject: Re: I'm starting to port LedgerSMB and it's dependencies > > On 2019/11/03 16:18, Chris Bennett wrote: > > Hi, > > LedgerSMB is accounting software. I started porting the dependencies in > > a good while back, got most in and developed about 2-ish others on the > > side which let me provide an installation guide and the software extras > > on an informal basis to get up a working system. I never managed to get > > it all in the ports tree. Life moved on and LedgerSMB has developed > > extensively since then. https://github.com/ledgersmb/LedgerSMB and > > https://ledgersmb.org/ > > > > It works on PostgreSQL and multiple web servers. I would like to include > > a guide on using base httpd, but I don't think I would be a good source > > for coming up with that help. > > Don't get hung up on making it work with httpd. The normal LedgerSMB > installation runs it from Starman with a reverse proxy in front of it > handling HTTPS etc - nginx/apache can do this easily, httpd cannot act > as a reverse proxy at all, it might be possible to get it working with > relayd but it's often a complete pain to work with! Better to get it > committed first, it's easy to add further notes in a pkg-readme later. > > > Any help bringing in the new ports would be welcome, but since everyone > > is so busy, I'll happily settle for good criticism! > > There's a ports hackathon starting *tomorrow* so if you can get some > things sent out fairly quickly there's a good chance of getting a decent > chunk of this committed quite soon. > > Information-dense mail follows, if you can follow it, it will greatly > improve chances of getting things in :) > > Looking at https://github.com/ledgersmb/LedgerSMB/blob/master/cpanfile > and the ports tree, we have many of the dependencies and in the right > versions already. Some new ones are needed; > > core -
Re: [maintainer update]: textproc/tree-sitter 0.19.4 --> 0.20.1
> -SHARED_LIBS += tree-sitter 0.0 # 0.0 > +SHARED_LIBS += tree-sitter 1.0 # 0.20.1 Since upstream sets SO_MAJOR and SO_MINOR to 0, this should be SHARED_LIBS += tree-sitter 1.0 # 0.0 'make test' looks a bit sad, but that isn't new and is at least partly due to missing fixtures in the crate tarballs. If no-one has a better idea than the SUBST_VARS approach for the shared lib version and this works in your daily neovim usage, this is ok tb
Re: [UPDATE] editors/neovim 0.5.1->0.6.0
On Sat, Dec 11, 2021 at 07:06:46PM -0700, Evan Fiddes wrote: Hello Evan, > This bumps the neovim version to 0.6.0 the most current release. See patch > notes[0] for a detailed breakdown. > > [0] https://github.com/neovim/neovim/releases/tag/v0.6.0 I had a small leading whitespace issue with your patch, which might be a MIME encoding thing. Otherwise, the update looks good, applies, and neovim 0.6.0 so far seems to be working well! Laurie
Re: Please read. Another try at a complex new port. Problems I have and hope against.
On 2021/12/13 11:18, Chris Bennett wrote: > cpan: > p5-CPAN-DistnameInfo > p5-Crypt-URandom > p5-Data-Binary cpan is not a valid category, it is just where portgen puts things that it has just built, they need moving to whichever real category is most appropriate. > p5-DateTime-Format-Duration-ISO8601, > p5-Email-Stuffer > p5-Feature-Compat-Try > p5-File-PathList > p5-Locale-CLDR > p5-Locale-CLDR-Locales-Ar, > p5-Locale-CLDR-Locales-Bg > p5-Locale-CLDR-Locales-Ca I explained what to do with the CLDR-Locales ports and subdirectories before btw, from your mail from October : So, I found bringing in Core::Thingy a problem I didn't see a reasonable way to : accomplish. : Who wants to review 12 new ports a once just to bring in p5-Core-Thingy? : Submitting such a ridiculous email chain was preposterous! : : I never did get any advice on this aspect of the problem. Depressing. That is unfair, this is one of the things I explained about in my mail from 2019, "So for the smaller perl ports I'd try to group them with a chunk of say 3-5 closely related ports (one port plus required dep's, or a couple of similar ports" Date: Mon, 4 Nov 2019 11:50:23 + From: Stuart Henderson To: Chris Bennett Subject: Re: I'm starting to port LedgerSMB and it's dependencies On 2019/11/03 16:18, Chris Bennett wrote: > Hi, > LedgerSMB is accounting software. I started porting the dependencies in > a good while back, got most in and developed about 2-ish others on the > side which let me provide an installation guide and the software extras > on an informal basis to get up a working system. I never managed to get > it all in the ports tree. Life moved on and LedgerSMB has developed > extensively since then. https://github.com/ledgersmb/LedgerSMB and > https://ledgersmb.org/ > > It works on PostgreSQL and multiple web servers. I would like to include > a guide on using base httpd, but I don't think I would be a good source > for coming up with that help. Don't get hung up on making it work with httpd. The normal LedgerSMB installation runs it from Starman with a reverse proxy in front of it handling HTTPS etc - nginx/apache can do this easily, httpd cannot act as a reverse proxy at all, it might be possible to get it working with relayd but it's often a complete pain to work with! Better to get it committed first, it's easy to add further notes in a pkg-readme later. > Any help bringing in the new ports would be welcome, but since everyone > is so busy, I'll happily settle for good criticism! There's a ports hackathon starting *tomorrow* so if you can get some things sent out fairly quickly there's a good chance of getting a decent chunk of this committed quite soon. Information-dense mail follows, if you can follow it, it will greatly improve chances of getting things in :) Looking at https://github.com/ledgersmb/LedgerSMB/blob/master/cpanfile and the ports tree, we have many of the dependencies and in the right versions already. Some new ones are needed; core - HTML::Escape PGObject PGObject::Simple PGObject::Simple::Role PGObject::Type::BigFloat PGObject::Type::DateTime PGObject::Type::ByteString PGObject::Util::DBMethod PGObject::Util::DBAdmin Plack::Builder::Conditionals Plack::Request::WithEncoding Version::Compare X12 EDI Support - X12::Parser PDF and PostScript output - Template::Latex Template::Plugin::Latex TeX::Encode OpenOffice - OpenOffice::OODoc OpenOffice::OODoc::Styles Excel - Excel::Writer::XLSX (I have ignored "develop" for now). Don't try to do everything in one go, concentrate on 'core' first. Search ports@ archives for past attempts, review feedback if any. Create fresh ports with "portgen p5 $modulename", this will usually get you 80% of the way (you'll need to replace the default "cpan" category and adjust paths to use a proper category and review COMMENT and DESCR as the generated ones are usually a bit poor). If there was a previous attempt, compare that with the new portgen'd one and decide which is better to go with. For mailing out proposed ports, you want to give porters a chunk that's enough to work on without too much back-and-forth (especially as you're in a different timezone to most active ports devs) but without flooding them. Avoid having separate active email threads because nobody will remember which have been reviewed/committed and which need more work - usual result of this is that people will tend to ignore the whole lot. So for the smaller perl ports I'd try to group them with a chunk of say 3-5 closely related ports (one port plus required dep's, or a couple of similar ports - using an example from here with PGObject you'd want to start with the core + required deps, then once they're reviewed and committed send out some of the other PGObject::foo ports). Send them in a single tar so a reviewer doesn't have to
Re: [maintainer update]: textproc/tree-sitter 0.19.4 --> 0.20.1
On Mon, 13 Dec 2021, Paco Esteban wrote: > Hi ports@, > > This is an update for textproc/tree-sitter to its latest version. > I could not find any changelog for it, so here's the github list of > changes between versions: > > https://github.com/tree-sitter/tree-sitter/compare/v0.19.4...v0.20.1 > > The only consumer for now is editors/neovim. I wanted to have this > updated as I'm working on a neovim update that will hit the list soon > hopefully. > > I bumped SHARED_LIBS as I saw that there are changes on the function > signatures for the C library. Thanks to tb@ for the help and tips on > making this build correctly. > > I also moved the cargo crates definition to a separate file. > > comments ? > ok to commit ? As tb@ points out, I forgot to add the new crates file. This should be better: diff 234135364fd9eff064d2b361e4079f5f3f61cb1d /usr/ports blob - 793e82f184d9dbd3c109921aaf7ff996011dce85 file + textproc/tree-sitter/Makefile --- textproc/tree-sitter/Makefile +++ textproc/tree-sitter/Makefile @@ -4,10 +4,12 @@ COMMENT = parser generator tool and incremental parsin GH_ACCOUNT = tree-sitter GH_PROJECT = tree-sitter -GH_TAGNAME = v0.19.4 +GH_TAGNAME = v0.20.1 -SHARED_LIBS += tree-sitter 0.0 # 0.0 +SHARED_LIBS += tree-sitter 1.0 # 0.20.1 +SUBST_VARS += LIBtree-sitter_VERSION + CATEGORIES = textproc MAINTAINER = Paco Esteban @@ -24,101 +26,7 @@ COMPILER = base-clang ports-gcc MODULES = devel/cargo -MODCARGO_CRATES += aho-corasick0.7.15 # Unlicense/MIT -MODCARGO_CRATES += ansi_term 0.11.0 # MIT -MODCARGO_CRATES += ansi_term 0.12.1 # MIT -MODCARGO_CRATES += arrayref0.3.6 # BSD-2-Clause -MODCARGO_CRATES += arrayvec0.5.2 # MIT/Apache-2.0 -MODCARGO_CRATES += ascii 1.0.0 # Apache-2.0 / MIT -MODCARGO_CRATES += atty0.2.14 # MIT -MODCARGO_CRATES += autocfg 1.0.1 # Apache-2.0 OR MIT -MODCARGO_CRATES += base64 0.13.0 # MIT/Apache-2.0 -MODCARGO_CRATES += bitflags1.2.1 # MIT/Apache-2.0 -MODCARGO_CRATES += blake2b_simd0.5.11 # MIT -MODCARGO_CRATES += bumpalo 3.6.1 # MIT/Apache-2.0 -MODCARGO_CRATES += cc 1.0.67 # MIT/Apache-2.0 -MODCARGO_CRATES += cfg-if 1.0.0 # MIT/Apache-2.0 -MODCARGO_CRATES += chrono 0.4.19 # MIT/Apache-2.0 -MODCARGO_CRATES += chunked_transfer1.4.0 # Apache-2.0 -MODCARGO_CRATES += clap2.33.3 # MIT -MODCARGO_CRATES += constant_time_eq0.1.5 # CC0-1.0 -MODCARGO_CRATES += crossbeam-utils 0.8.3 # MIT OR Apache-2.0 -MODCARGO_CRATES += difference 2.0.0 # MIT -MODCARGO_CRATES += dirs3.0.1 # MIT OR Apache-2.0 -MODCARGO_CRATES += dirs-sys0.3.5 # MIT OR Apache-2.0 -MODCARGO_CRATES += form_urlencoded 1.0.1 # MIT/Apache-2.0 -MODCARGO_CRATES += getrandom 0.1.16 # MIT OR Apache-2.0 -MODCARGO_CRATES += getrandom 0.2.2 # MIT OR Apache-2.0 -MODCARGO_CRATES += glob0.3.0 # MIT/Apache-2.0 -MODCARGO_CRATES += hashbrown 0.9.1 # Apache-2.0/MIT -MODCARGO_CRATES += hermit-abi 0.1.18 # MIT/Apache-2.0 -MODCARGO_CRATES += html-escape 0.2.6 # MIT -MODCARGO_CRATES += idna0.2.2 # MIT/Apache-2.0 -MODCARGO_CRATES += indexmap1.6.1 # Apache-2.0/MIT -MODCARGO_CRATES += itoa0.4.7 # MIT OR Apache-2.0 -MODCARGO_CRATES += js-sys 0.3.48 # MIT/Apache-2.0 -MODCARGO_CRATES += lazy_static 1.4.0 # MIT/Apache-2.0 -MODCARGO_CRATES += libc0.2.86 # MIT OR Apache-2.0 -MODCARGO_CRATES += libloading 0.7.0 # ISC -MODCARGO_CRATES += log 0.4.14 # MIT OR Apache-2.0 -MODCARGO_CRATES += matches 0.1.8 # MIT -MODCARGO_CRATES += memchr 2.3.4 # Unlicense/MIT -MODCARGO_CRATES += num-integer 0.1.44 # MIT OR Apache-2.0 -MODCARGO_CRATES += num-traits 0.2.14 # MIT OR Apache-2.0 -MODCARGO_CRATES += once_cell 1.7.0 # MIT OR Apache-2.0 -MODCARGO_CRATES += percent-encoding2.1.0 # MIT/Apache-2.0 -MODCARGO_CRATES += ppv-lite86 0.2.10 # MIT/Apache-2.0 -MODCARGO_CRATES += proc-macro2 1.0.24 # MIT OR Apache-2.0 -MODCARGO_CRATES += quote 1.0.9 # MIT OR Apache-2.0 -MODCARGO_CRATES += rand0.8.3 # MIT OR Apache-2.0 -MODCARGO_CRATES += rand_chacha 0.3.0 # MIT OR Apache-2.0 -MODCARGO_CRATES += rand_core 0.6.2 # MIT OR Apache-2.0 -MODCARGO_CRATES += rand_hc 0.3.0 # MIT OR Apache-2.0 -MODCARGO_CRATES += redox_syscall 0.1.57 # MIT -MODCARGO_CRATES += redox_syscall 0.2.5 # MIT -MODCARGO_CRATES += redox_users 0.3.5 # MIT -MODCARGO_CRATES += regex 1.4.3 # MIT OR Apache-2.0 -MODCARGO_CRATES += regex-syntax0.6.22 # MIT/Apache-2.0 -MODCARGO_CRATES += remove_dir_all 0.5.3 # MIT/Apache-2.0 -MODCARGO_CRATES +=
[maintainer update]: textproc/tree-sitter 0.19.4 --> 0.20.1
Hi ports@, This is an update for textproc/tree-sitter to its latest version. I could not find any changelog for it, so here's the github list of changes between versions: https://github.com/tree-sitter/tree-sitter/compare/v0.19.4...v0.20.1 The only consumer for now is editors/neovim. I wanted to have this updated as I'm working on a neovim update that will hit the list soon hopefully. I bumped SHARED_LIBS as I saw that there are changes on the function signatures for the C library. Thanks to tb@ for the help and tips on making this build correctly. I also moved the cargo crates definition to a separate file. comments ? ok to commit ? diff 234135364fd9eff064d2b361e4079f5f3f61cb1d /usr/ports blob - 793e82f184d9dbd3c109921aaf7ff996011dce85 file + textproc/tree-sitter/Makefile --- textproc/tree-sitter/Makefile +++ textproc/tree-sitter/Makefile @@ -4,10 +4,12 @@ COMMENT = parser generator tool and incremental parsin GH_ACCOUNT = tree-sitter GH_PROJECT = tree-sitter -GH_TAGNAME = v0.19.4 +GH_TAGNAME = v0.20.1 -SHARED_LIBS += tree-sitter 0.0 # 0.0 +SHARED_LIBS += tree-sitter 1.0 # 0.20.1 +SUBST_VARS += LIBtree-sitter_VERSION + CATEGORIES = textproc MAINTAINER = Paco Esteban @@ -24,101 +26,7 @@ COMPILER = base-clang ports-gcc MODULES = devel/cargo -MODCARGO_CRATES += aho-corasick0.7.15 # Unlicense/MIT -MODCARGO_CRATES += ansi_term 0.11.0 # MIT -MODCARGO_CRATES += ansi_term 0.12.1 # MIT -MODCARGO_CRATES += arrayref0.3.6 # BSD-2-Clause -MODCARGO_CRATES += arrayvec0.5.2 # MIT/Apache-2.0 -MODCARGO_CRATES += ascii 1.0.0 # Apache-2.0 / MIT -MODCARGO_CRATES += atty0.2.14 # MIT -MODCARGO_CRATES += autocfg 1.0.1 # Apache-2.0 OR MIT -MODCARGO_CRATES += base64 0.13.0 # MIT/Apache-2.0 -MODCARGO_CRATES += bitflags1.2.1 # MIT/Apache-2.0 -MODCARGO_CRATES += blake2b_simd0.5.11 # MIT -MODCARGO_CRATES += bumpalo 3.6.1 # MIT/Apache-2.0 -MODCARGO_CRATES += cc 1.0.67 # MIT/Apache-2.0 -MODCARGO_CRATES += cfg-if 1.0.0 # MIT/Apache-2.0 -MODCARGO_CRATES += chrono 0.4.19 # MIT/Apache-2.0 -MODCARGO_CRATES += chunked_transfer1.4.0 # Apache-2.0 -MODCARGO_CRATES += clap2.33.3 # MIT -MODCARGO_CRATES += constant_time_eq0.1.5 # CC0-1.0 -MODCARGO_CRATES += crossbeam-utils 0.8.3 # MIT OR Apache-2.0 -MODCARGO_CRATES += difference 2.0.0 # MIT -MODCARGO_CRATES += dirs3.0.1 # MIT OR Apache-2.0 -MODCARGO_CRATES += dirs-sys0.3.5 # MIT OR Apache-2.0 -MODCARGO_CRATES += form_urlencoded 1.0.1 # MIT/Apache-2.0 -MODCARGO_CRATES += getrandom 0.1.16 # MIT OR Apache-2.0 -MODCARGO_CRATES += getrandom 0.2.2 # MIT OR Apache-2.0 -MODCARGO_CRATES += glob0.3.0 # MIT/Apache-2.0 -MODCARGO_CRATES += hashbrown 0.9.1 # Apache-2.0/MIT -MODCARGO_CRATES += hermit-abi 0.1.18 # MIT/Apache-2.0 -MODCARGO_CRATES += html-escape 0.2.6 # MIT -MODCARGO_CRATES += idna0.2.2 # MIT/Apache-2.0 -MODCARGO_CRATES += indexmap1.6.1 # Apache-2.0/MIT -MODCARGO_CRATES += itoa0.4.7 # MIT OR Apache-2.0 -MODCARGO_CRATES += js-sys 0.3.48 # MIT/Apache-2.0 -MODCARGO_CRATES += lazy_static 1.4.0 # MIT/Apache-2.0 -MODCARGO_CRATES += libc0.2.86 # MIT OR Apache-2.0 -MODCARGO_CRATES += libloading 0.7.0 # ISC -MODCARGO_CRATES += log 0.4.14 # MIT OR Apache-2.0 -MODCARGO_CRATES += matches 0.1.8 # MIT -MODCARGO_CRATES += memchr 2.3.4 # Unlicense/MIT -MODCARGO_CRATES += num-integer 0.1.44 # MIT OR Apache-2.0 -MODCARGO_CRATES += num-traits 0.2.14 # MIT OR Apache-2.0 -MODCARGO_CRATES += once_cell 1.7.0 # MIT OR Apache-2.0 -MODCARGO_CRATES += percent-encoding2.1.0 # MIT/Apache-2.0 -MODCARGO_CRATES += ppv-lite86 0.2.10 # MIT/Apache-2.0 -MODCARGO_CRATES += proc-macro2 1.0.24 # MIT OR Apache-2.0 -MODCARGO_CRATES += quote 1.0.9 # MIT OR Apache-2.0 -MODCARGO_CRATES += rand0.8.3 # MIT OR Apache-2.0 -MODCARGO_CRATES += rand_chacha 0.3.0 # MIT OR Apache-2.0 -MODCARGO_CRATES += rand_core 0.6.2 # MIT OR Apache-2.0 -MODCARGO_CRATES += rand_hc 0.3.0 # MIT OR Apache-2.0 -MODCARGO_CRATES += redox_syscall 0.1.57 # MIT -MODCARGO_CRATES += redox_syscall 0.2.5 # MIT -MODCARGO_CRATES += redox_users 0.3.5 # MIT -MODCARGO_CRATES += regex 1.4.3 # MIT OR Apache-2.0 -MODCARGO_CRATES += regex-syntax0.6.22 # MIT/Apache-2.0 -MODCARGO_CRATES += remove_dir_all 0.5.3 # MIT/Apache-2.0 -MODCARGO_CRATES += rust-argon2 0.8.3 # MIT/Apache-2.0 -MODCARGO_CRATES += ryu 1.0.5 # Apache-2.0 OR BSL-1.0 -MODCARGO_CRATES += same-file 1.0.6 #
Re: Please read. Another try at a complex new port. Problems I have and hope against.
On Mon, Dec 13, 2021 at 06:58:42PM +, Zé Loff wrote: > On Mon, Dec 13, 2021 at 07:45:26AM -0800, Chris Bennett wrote: > > On Mon, Dec 13, 2021 at 10:05:21AM +0100, Solene Rapenne wrote: > > > Sending new ports is really hazardous, even for people with commit > > > rights. Reviewing a port take time because the OpenBSD project has a > > > high quality standard and it's preferred to correctly work on the ports > > > before they get included. This is sometimes discouraging, but there are > > > only volunteers here doing reviews on their free time and there are no > > > performance obligation. People review what they use or enjoy, we can't > > > force anyone to review something they don't like. This doesn't mean > > > we shouldn't send new ports, but sometimes, when we send a port, it's > > > either missed or the person who may have interest in it is busy and > > > will forget. That's why a ping can be very useful from time to time. > > > > > > If you make a port, at least you can use it for yourself before it get > > > included, which is quite useful for keeping your system clean. > > > > > > > Except that others are requesting this be ported into OpenBSD for years. > > This is accounting software. It needs to be thoroughly tested or > > companies may fail. SMB stands for small to medium sized businesses. > > > > As an interesting note. During the 1.2 and 1.3 stages, a long time ago, > > I almost got this into the tree. FreeBSD did. Then both here and at > > FreeBSD, the work was abandoned. > > > > I see a ton of new ports and updates that never get reviewed. I see many > > posts to this list and other lists about these. They get > > mentioned, but the port is lost. > > I hate to see this work hopelessly lost. So much work for nothing. It > > hurts OpenBSD. > > > > I have a big proposal. It would require some tough rules to avoid being > > a disaster tree. But it would leave these ports visible. > > > > Something like this: > > > > /usr/dirty_ports/ with a category tree in it that only has categories > > with ports inside of them. > > It could only be run by -current. > > The size of the tree would need some method of regulation to not grow > > hopelessly large. > > But the size would show how many ports need reviews and it would let > > someone review ports whenever they have some free time. > > > > /usr/dirty_ports/devel/myport/review_problems/notes to tell what the > > problems are. Maybe just a ping, maybe what can't be figured out with > > that port or a dependency it needs. > > > > pkg_add LedgerSMB > > This port is found under /usr/dirty_ports/. > > No packages are ever built for these ports. > > Please help the project and review these ports. > > These ports require running -current. > > You will need to build these ports yourself. > > No support will be provided for systems running these ports as they > > may cause stability and security problems. > > Please add USE_DIRTY_PORTS=Yes to /etc/mk.conf > > > > This would be good enough for me and extremely satisfying that my work > > isn't lost for all time when I disappear, which also includes unpleasant > > things like death. > > It also means that some people won't wander off into using an OS that > > they don't really want to change to, but supports the software they > > need. > > After a certain time period, these ports could be removed if never > > approved. > > > > -- > > Maybe? > > Chris Bennett > > > > Are you aware of https://github.com/jasperla/openbsd-wip? Yes. I asked about using that, but I was advised that it really wouldn't be appropriate. These are a quickly run port generator of core deps that I just ran to post here right now. It lacks many TEST_DEPENDS, BUILD and RUN_DEPENDS The short list of just core depends, but not complete. p5-ExtUtils-CChecker->=0.11 needs updating cpan: p5-CPAN-DistnameInfo p5-Crypt-URandom p5-Data-Binary p5-DateTime-Format-Duration-ISO8601, p5-Email-Stuffer p5-Feature-Compat-Try p5-File-PathList p5-Locale-CLDR p5-Locale-CLDR-Locales-Ar, p5-Locale-CLDR-Locales-Bg p5-Locale-CLDR-Locales-Ca p5-Locale-CLDR-Locales-Cs p5-Locale-CLDR-Locales-Da, p5-Locale-CLDR-Locales-De p5-Locale-CLDR-Locales-El p5-Locale-CLDR-Locales-En p5-Locale-CLDR-Locales-Es, p5-Locale-CLDR-Locales-Et p5-Locale-CLDR-Locales-Fi p5-Locale-CLDR-Locales-Fr p5-Locale-CLDR-Locales-Hu, p5-Locale-CLDR-Locales-Id p5-Locale-CLDR-Locales-Is p5-Locale-CLDR-Locales-It p5-Locale-CLDR-Locales-Lt, p5-Locale-CLDR-Locales-Ms p5-Locale-CLDR-Locales-Nb p5-Locale-CLDR-Locales-Nl p5-Locale-CLDR-Locales-Pl, p5-Locale-CLDR-Locales-Pt p5-Locale-CLDR-Locales-Ru p5-Locale-CLDR-Locales-Sv p5-Locale-CLDR-Locales-Tr, p5-Locale-CLDR-Locales-Uk p5-Locale-CLDR-Locales-Zh p5-Math-Random-ISAAC-XS p5-Module-CPANTS-Analyse, p5-Module-CPANfile p5-MooX-ClassAttribute p5-MooseX-ClassAttribute p5-Number-Tolerant p5-PGObject, p5-PGObject-Simple p5-PGObject-Simple-Role p5-PGObject-Type-BigFloat p5-PGObject-Type-ByteString, p5-PGObject-Type-DateTime
Re: Please read. Another try at a complex new port. Problems I have and hope against.
On Mon, Dec 13, 2021 at 07:45:26AM -0800, Chris Bennett wrote: > On Mon, Dec 13, 2021 at 10:05:21AM +0100, Solene Rapenne wrote: > > Sending new ports is really hazardous, even for people with commit > > rights. Reviewing a port take time because the OpenBSD project has a > > high quality standard and it's preferred to correctly work on the ports > > before they get included. This is sometimes discouraging, but there are > > only volunteers here doing reviews on their free time and there are no > > performance obligation. People review what they use or enjoy, we can't > > force anyone to review something they don't like. This doesn't mean > > we shouldn't send new ports, but sometimes, when we send a port, it's > > either missed or the person who may have interest in it is busy and > > will forget. That's why a ping can be very useful from time to time. > > > > If you make a port, at least you can use it for yourself before it get > > included, which is quite useful for keeping your system clean. > > > > Except that others are requesting this be ported into OpenBSD for years. > This is accounting software. It needs to be thoroughly tested or > companies may fail. SMB stands for small to medium sized businesses. > > As an interesting note. During the 1.2 and 1.3 stages, a long time ago, > I almost got this into the tree. FreeBSD did. Then both here and at > FreeBSD, the work was abandoned. > > I see a ton of new ports and updates that never get reviewed. I see many > posts to this list and other lists about these. They get > mentioned, but the port is lost. > I hate to see this work hopelessly lost. So much work for nothing. It > hurts OpenBSD. > > I have a big proposal. It would require some tough rules to avoid being > a disaster tree. But it would leave these ports visible. > > Something like this: > > /usr/dirty_ports/ with a category tree in it that only has categories > with ports inside of them. > It could only be run by -current. > The size of the tree would need some method of regulation to not grow > hopelessly large. > But the size would show how many ports need reviews and it would let > someone review ports whenever they have some free time. > > /usr/dirty_ports/devel/myport/review_problems/notes to tell what the > problems are. Maybe just a ping, maybe what can't be figured out with > that port or a dependency it needs. > > pkg_add LedgerSMB > This port is found under /usr/dirty_ports/. > No packages are ever built for these ports. > Please help the project and review these ports. > These ports require running -current. > You will need to build these ports yourself. > No support will be provided for systems running these ports as they > may cause stability and security problems. > Please add USE_DIRTY_PORTS=Yes to /etc/mk.conf > > This would be good enough for me and extremely satisfying that my work > isn't lost for all time when I disappear, which also includes unpleasant > things like death. > It also means that some people won't wander off into using an OS that > they don't really want to change to, but supports the software they > need. > After a certain time period, these ports could be removed if never > approved. > > -- > Maybe? > Chris Bennett > Are you aware of https://github.com/jasperla/openbsd-wip? --
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: rsadow...@cvs.openbsd.org 2021/12/13 11:23:58 Modified files: graphics/opencsg: Makefile Log message: Remove unneeded x11/qt5/qtbase,-main dependency by set MODQT_DEPS to No
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: rsadow...@cvs.openbsd.org 2021/12/13 11:21:35 Modified files: editors/calligra: Makefile Log message: Move dependencies from LDEP to RUN/BUILD, remove unneeded openexr,libwpd spotted by sthen@
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: lan...@cvs.openbsd.org 2021/12/13 10:19:54 Modified files: security/nss/patches: patch-nss_lib_certhigh_certvfypkix_c patch-nss_lib_freebl_shvfy_c Log message: security/nss: add link to upstream commit fixing build with llvm13
Re: Please read. Another try at a complex new port. Problems I have and hope against.
On Mon, Dec 13, 2021 at 08:52:48AM -0700, Theo de Raadt wrote: > Chris Bennett wrote: > > > Except that others are requesting this be ported into OpenBSD for years. > > This is accounting software. It needs to be thoroughly tested or > > companies may fail. SMB stands for small to medium sized businesses. > > The "No warranty" clauses on so much open source software isn't a joke. > > It is completely serious. Beyond "best effort" noone is responsible if > companies run software where they didn't fully assess their BoM and as a > result get damaged by what they don't know. The failure mode you describe > is NOT OUR PROBLEM. Beyond best effort, that is. > > > I have a big proposal. It would require some tough rules to avoid being > > a disaster tree. But it would leave these ports visible. > > You have a really big mouth. Why don't you have hard working hands to > match? It might be surprising, but the usual way of handling defective > software is to FIX IT, rather than writing more hand-wringing text about it > which noone will read. > Have you looked at my p5-PGObject* ports I submitted? Probably not. They all worked. One required a modification to postgresql.port.mk done by someone else who had the knowledge to do this. Then those ports worked perfectly. Another one of those required asking upstream to modify that port on CPAN. They did that after my request, and then that port worked fine. One reviewer pointed out problems, and also gave a single OK to several of my submitted ports. One person actually told me a required port by the project was silly and I shouldn't submit such ports. I thought that the whole point of requiring TWO OK's was to do an excellent job of seeking problems that the port submitter missed. I quietly asked privately several people if perhaps my work was blacklisted. They assured me that that was not the case. Your response seems to be exactly the opposite. Do I really have to do what I was forced to do a long time ago? Submit ports off the list for an OK. Add the approved ones to a non-OpenBSD repository. Then tell people that sure, LedgerSMB is available for OpenBSD, but I had to secretly get approvals? Please stop acting like a bully. You requested in the past that I never ever send you a private email. I have honored that request. So I now request something. Please leave me alone. Let me work. Nobody is required to ever examine my work. But I will submit it anyway. Filter me off the list as you threatened me before. I can submit off-list. Someone requested to keep replies on the list. This is the sort of reply to me that prevents that from happening. Many people reply to me off-list from both ports and especially misc. They request privacy because they also hate this type of mean replies. A couple of years ago, a user of LedgerSMB donated small amount to people helping out. That bought me a much needed piece of hardware sitting next to my laptop. People want to have this. Why are you working against me trying to accomplish it? Why? Thank you for starting OpenBSD and making a wonderful OS. That's why I'm here. -- Puzzled, Chris Bennett
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: t...@cvs.openbsd.org2021/12/13 09:32:23 Modified files: sysutils/czkawka: Makefile crates.inc distinfo Log message: sysutils/czkawka: update to 3.3.1
Re: Please read. Another try at a complex new port. Problems I have and hope against.
Chris Bennett wrote: > Except that others are requesting this be ported into OpenBSD for years. > This is accounting software. It needs to be thoroughly tested or > companies may fail. SMB stands for small to medium sized businesses. The "No warranty" clauses on so much open source software isn't a joke. It is completely serious. Beyond "best effort" noone is responsible if companies run software where they didn't fully assess their BoM and as a result get damaged by what they don't know. The failure mode you describe is NOT OUR PROBLEM. Beyond best effort, that is. > I have a big proposal. It would require some tough rules to avoid being > a disaster tree. But it would leave these ports visible. You have a really big mouth. Why don't you have hard working hands to match? It might be surprising, but the usual way of handling defective software is to FIX IT, rather than writing more hand-wringing text about it which noone will read.
Re: Please read. Another try at a complex new port. Problems I have and hope against.
On Mon, Dec 13, 2021 at 10:05:21AM +0100, Solene Rapenne wrote: > Sending new ports is really hazardous, even for people with commit > rights. Reviewing a port take time because the OpenBSD project has a > high quality standard and it's preferred to correctly work on the ports > before they get included. This is sometimes discouraging, but there are > only volunteers here doing reviews on their free time and there are no > performance obligation. People review what they use or enjoy, we can't > force anyone to review something they don't like. This doesn't mean > we shouldn't send new ports, but sometimes, when we send a port, it's > either missed or the person who may have interest in it is busy and > will forget. That's why a ping can be very useful from time to time. > > If you make a port, at least you can use it for yourself before it get > included, which is quite useful for keeping your system clean. > Except that others are requesting this be ported into OpenBSD for years. This is accounting software. It needs to be thoroughly tested or companies may fail. SMB stands for small to medium sized businesses. As an interesting note. During the 1.2 and 1.3 stages, a long time ago, I almost got this into the tree. FreeBSD did. Then both here and at FreeBSD, the work was abandoned. I see a ton of new ports and updates that never get reviewed. I see many posts to this list and other lists about these. They get mentioned, but the port is lost. I hate to see this work hopelessly lost. So much work for nothing. It hurts OpenBSD. I have a big proposal. It would require some tough rules to avoid being a disaster tree. But it would leave these ports visible. Something like this: /usr/dirty_ports/ with a category tree in it that only has categories with ports inside of them. It could only be run by -current. The size of the tree would need some method of regulation to not grow hopelessly large. But the size would show how many ports need reviews and it would let someone review ports whenever they have some free time. /usr/dirty_ports/devel/myport/review_problems/notes to tell what the problems are. Maybe just a ping, maybe what can't be figured out with that port or a dependency it needs. pkg_add LedgerSMB This port is found under /usr/dirty_ports/. No packages are ever built for these ports. Please help the project and review these ports. These ports require running -current. You will need to build these ports yourself. No support will be provided for systems running these ports as they may cause stability and security problems. Please add USE_DIRTY_PORTS=Yes to /etc/mk.conf This would be good enough for me and extremely satisfying that my work isn't lost for all time when I disappear, which also includes unpleasant things like death. It also means that some people won't wander off into using an OS that they don't really want to change to, but supports the software they need. After a certain time period, these ports could be removed if never approved. -- Maybe? Chris Bennett
Re: lang/sbcl update
quick followup
> [...]
>
>> Failure:unicode-misc.pure.lisp / (CL-CASE-INVERTIBILITY)
>
> (loop for i from 0 below char-code-limit
> for char = (code-char i)
> do
>(when (upper-case-p char)
> (assert (char= char (char-upcase (char-downcase char)
>(when (lower-case-p char)
> (assert (char= char (char-downcase (char-upcase char))
>
> This fails with char being #\WARANG_CITI_CAPITAL_LETTER_VIYO, or
> U+118BF. I asked a friend on linux to test and there:
>
> (char= #\WARANG_CITI_CAPITAL_LETTER_VIYO
>(char-upcase (char-downcase #\WARANG_CITI_CAPITAL_LETTER_VIYO)))
> ; => t
>
> This could be a real bug, probably in the unicode data.
iswupper(3) and iswlower(3) return the correct thing (0) for that
character so it isn't a problem in base. sbcl' UPPER/LOWER-CASE-P works
by inspecting a database of unicode data produced during the build in
${WRKDIR}/output/ucd* so the bug must be there, but I'm still not sure
how it's generated.
It'd be nice to report this and the other failure upstream. I don't
have an account at launchpad, but if nobody else wants to report them I
guess I can create one and try to.
> [...]
>
>> Expected failure: float.impure.lisp / (RANGE-REDUCTION PRECISE-PI)
>
> this is actually an improvement: it's expected to fail openbsd but it
> works now :)
nope, I mis-interpreted the regress suite output, this is still broken.
> Inaccurate result for (SIN 4.611686018427388d18):
> expected -0.7029224436192089d0,
> got -0.7071329274527789d0
FWIW it's been broken for eight years:
https://bugs.launchpad.net/sbcl/+bug/1137924
Re: [wip] net/tdlib-purple v8.0
Hello, op@ found out that the port would not compile when devel/fmt is installed. This update fixes this situation. Stefan Hagen wrote: > 1) telegram-purple and tdlib-purple could coexist, if they would not > install the same pixmap files. I'm not sure if I want a conflict marker > here or if I can rename the pixmaps. For now, just don't install both. In this update, I rename the pixmaps to telegram-tdlib.png. > 2) the port needs a registered telegram application and the API_ID and > API_HASH needs to be passed at build time. You can do so in the port > Makefile. OpenBSD devs can use my key in cvs:~sdk/tdlib_api to test. Please don't use it for anything else. I'll invalidate it at some point. Best Regards, Stefan tdlib-purple.tgz Description: application/tar-gz
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: j...@cvs.openbsd.org2021/12/13 05:58:06 Modified files: net/samba : Makefile distinfo net/samba/pkg : PLIST-main Log message: Update to samba-4.15.3 Tested by Ian (co-maintainer)
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: ajacou...@cvs.openbsd.org 2021/12/13 05:06:07 Modified files: x11/gnome/shell-extensions: Makefile distinfo Log message: Update to gnome-shell-extensions-41.1.
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: ajacou...@cvs.openbsd.org 2021/12/13 05:05:56 Modified files: x11/gnome/shell: Makefile distinfo Log message: Update to gnome-shell-41.2.
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: ajacou...@cvs.openbsd.org 2021/12/13 05:05:39 Modified files: x11/gnome/mutter: Makefile distinfo Log message: Update to mutter-41.2.
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: lan...@cvs.openbsd.org 2021/12/13 04:10:52 Modified files: www/seamonkey : Makefile distinfo www/seamonkey-i18n: Makefile.inc distinfo Added files: www/seamonkey/patches: patch-third__party_rust_packed__simd_src_lib.rs Log message: www/seamonkey: update to 2.53.10.1 and unbreak. see https://www.seamonkey-project.org/releases/seamonkey2.53.10.1/#new unbreak build with rust 1.56 by taking a patch from netbsd/pkgsrc, cf http://cvsweb.netbsd.org/bsdweb.cgi/pkgsrc/www/seamonkey/patches/patch-third__party_rust_packed__simd_src_lib.rs
UPDATE mail/mblaze 1.2 from MAINTAINER
Hi, Find an update to mblaze 1.2. Release notes: * Caution! The tools mdeliver and mexport were buggy in handling and generation of trailing empty lines in MBOX-RD. Do not import mbox files generated by mexport >=1.2 with mdeliver <1.2 if you require verbatim message delivery. * mshow: add "-A all" to render all attachments * msed: match header names case insensitively * mless: prefer setting LESSKEYIN and using .mlesskey * mcom: take Delivered-To into account for choosing From address * Many bug fixes. No PLIST changes, portcheck is happy, all tests pass. Works in my machine(tm). -Lucas diff b85a4f60d9e6fa3c92626a4dcd36982a8bffcf82 /usr/ports blob - fee634d343ffa63e2648282ac2838bb8dab84477 file + mail/mblaze/Makefile --- mail/mblaze/Makefile +++ mail/mblaze/Makefile @@ -2,7 +2,7 @@ COMMENT = set of Maildir utilities -DISTNAME = mblaze-1.1 +DISTNAME = mblaze-1.2 CATEGORIES = mail HOMEPAGE = https://git.vuxu.org/mblaze/ blob - 2ed4e31c9a15d1bd65db618c8e8a51088b404105 file + mail/mblaze/distinfo --- mail/mblaze/distinfo +++ mail/mblaze/distinfo @@ -1,2 +1,2 @@ -SHA256 (mblaze-1.1.tar.gz) = 7djLhvZnVD5wPe5YJjuBx+R3RDOdI+u7akPnUFm6k7E= -SIZE (mblaze-1.1.tar.gz) = 97041 +SHA256 (mblaze-1.2.tar.gz) = UMFkyIzIO09SaRNB7hQGDaWm8YWehqpz/1ld5LQQA38= +SIZE (mblaze-1.2.tar.gz) = 99578
Re: "LIB_DEPENDS not needed for"
On Sun, Dec 12, 2021 at 11:52:40AM +, Stuart Henderson wrote: > Related to the "policy for dlopen'd libraries etc" mail I just posted but > worth a separate thread I think .. > > When you see "LIB_DEPENDS not needed for " when "make package" > runs, it means that the LIB_DEPENDS entry is *ignored* as a run dependency > and is equivalent to BUILD_DEPENDS. > > : LIB_DEPENDS not needed for There doesn't seem to > be > : any WANTLIB to match the given LIB_DEPENDS. Thus, the LIB_DEPENDS won't > : turn into a @depends line in the created package. > > This is nearly always an error - bsd.port.mk(5) lists some "might be > intentional" but those cases are rare and could be handled with conditionals > instead (perhaps it would be better if we do turn it into an actual error). > > I think all current cases in ports *are* an error: > > audio/moc LIB_DEPENDS devel/gettext,-runtime not needed for > audio/moc ? > audio/cantata LIB_DEPENDS audio/libebur128 not needed for > audio/cantata ? > x11/kde-applications/kcronLIB_DEPENDS devel/kf5/kiconthemes not needed > for x11/kde-applications/kcron ? > x11/pidgin-libnotify LIB_DEPENDS net/pidgin,-libpurple not needed for > x11/pidgin-libnotify ? > graphics/opencsg LIB_DEPENDS x11/qt5/qtbase,-main not needed for > graphics/opencsg ? > graphics/piglit LIB_DEPENDS graphics/vulkan-loader not needed > for graphics/piglit ? > net/pidginLIB_DEPENDS lang/python/3.9 not needed for > net/pidgin,-finch ? > editors/calligra LIB_DEPENDS devel/kf5/kcalendarcore not needed for > editors/calligra ? > editors/calligra LIB_DEPENDS devel/kf5/kcontacts not needed for > editors/calligra ? > editors/calligra LIB_DEPENDS textproc/libwpd not needed for > editors/calligra ? > games/f1spiritLIB_DEPENDS devel/libidn not needed for > games/f1spirit ? > math/nonogram LIB_DEPENDS math/nonolib not needed for math/nonogram ? > sysutils/libfsapfsLIB_DEPENDS sysutils/libfwnt not needed for > sysutils/libfsapfs ? > > > Considering how few there are left, I concur. Once they're fixed, we can turn these into errors.
Re: NEW: sysutils/bpytop
Omar Polo wrote:
> Stefan Hagen writes:
> > Lewis ingraham wrote:
> >> Also I for some reason cannot get the program to launch when it is built
> >> and installed. It comes up as "command not found" when I type in bpytop.
> >>
> >> Project I am currently trying to port properly:
> >> https://github.com/aristocratos/bpytop
> >
> > There is an easier way to get started with python ports. We have
> > portgen(1) which can give you a head start with perl, python, ruby
> > and go ports.
> >
> > Try "portgen bpytop". It will generate as much of a port it can in
> > /usr/ports/mystuff/pypi. Then examine what it did and fix it up.
> >
> > The port you're trying to create is not using the usual setup.py build
> > script. Instead it has a Makefile, which copies files around. Portgen
> > is not prepared for that and it needs fixing.
> >
> > I added NO_BUILD=Yes to the port system from trying to invoke setup.py.
> > Next I added a do-install: target with will be execute as "make install"
> > command.
> >
> > The (quickly) fixed port is attached. It works here.
> >
> > Best regards,
> > Stefan
>
> Port looks fine and works, even thought it's a bit too "flashy" for my
> taste :)
>
> The distinfo wasn't right, it complained that "Size does not match for
> bpytop-1.0.67.tar.gz" and had to makesum again. pypi releases are
> mutable?
>
> % make makesum
> ===> Checking files for bpytop-1.0.67
> >> Fetch https://pypi.io/packages/source/b/bpytop/bpytop-1.0.67.tar.gz
> bpytop-1.0.67.tar.gz 100% |*| 77732 00:00
> --- old
> +++ new
> @@ -1,2 +1,2 @@
> -SHA256 (bpytop-1.0.67.tar.gz) = 4/Ame9QKWAFrWsge1kJPHI2VOzOlN1RrIt0aKwGwepc=
> -SIZE (bpytop-1.0.67.tar.gz) = 628491
> +SHA256 (bpytop-1.0.67.tar.gz) = izOONif6bpkeg2vuYe84mI9qejo33AXHV6krpDePlbs=
> +SIZE (bpytop-1.0.67.tar.gz) = 77732
Hmm, strange. But I get the same updated checksum now. But where else
should I have gotten it from?
bpytop is starting, but it's not without issues. For example:
- start bpytop
- select any process with arrow up/down keys
- hit enter
- Poof!
12/12/21 (19:04:34) | ERROR: Exception while getting cpu frequency!
12/12/21 (19:04:34) | ERROR: module 'psutil' has no attribute 'cpu_freq'
Traceback (most recent call last):
File "/usr/local/bin/bpytop", line 3060, in _collect
if CONFIG.show_cpu_freq and hasattr(psutil.cpu_freq(), "current"):
AttributeError: module 'psutil' has no attribute 'cpu_freq'
12/12/21 (19:04:53) | ERROR: Exception while getting cpu frequency!
12/12/21 (19:04:53) | ERROR: module 'psutil' has no attribute 'cpu_freq'
Traceback (most recent call last):
File "/usr/local/bin/bpytop", line 3060, in _collect
if CONFIG.show_cpu_freq and hasattr(psutil.cpu_freq(), "current"):
AttributeError: module 'psutil' has no attribute 'cpu_freq'
12/12/21 (19:05:28) | ERROR: Exception when sending signal 2 to pid 15942
12/12/21 (19:05:28) | ERROR: [Errno 1] Operation not permitted
Traceback (most recent call last):
File "/usr/local/bin/bpytop", line 5459, in process_keys
os.kill(pid, sig)
PermissionError: [Errno 1] Operation not permitted
12/12/21 (19:05:29) | ERROR: Exception when sending signal 2 to pid 15942
12/12/21 (19:05:29) | ERROR: [Errno 1] Operation not permitted
Traceback (most recent call last):
File "/usr/local/bin/bpytop", line 5459, in process_keys
os.kill(pid, sig)
PermissionError: [Errno 1] Operation not permitted
12/12/21 (19:05:32) | ERROR: Exception when sending signal 2 to pid 58422
12/12/21 (19:05:32) | ERROR: [Errno 1] Operation not permitted
Traceback (most recent call last):
File "/usr/local/bin/bpytop", line 5459, in process_keys
os.kill(pid, sig)
PermissionError: [Errno 1] Operation not permitted
13/12/21 (11:46:12) | ERROR: Exception while getting cpu frequency!
13/12/21 (11:46:12) | ERROR: module 'psutil' has no attribute 'cpu_freq'
Traceback (most recent call last):
File "/usr/local/bin/bpytop", line 3060, in _collect
if CONFIG.show_cpu_freq and hasattr(psutil.cpu_freq(), "current"):
AttributeError: module 'psutil' has no attribute 'cpu_freq'
13/12/21 (11:46:15) | ERROR: Data collection thread failed with exception:
invalid attr name 'cpu_num'
Traceback (most recent call last):
File "/usr/local/bin/bpytop", line 2938, in _runner
collector._collect()
File "/usr/local/bin/bpytop", line 3775, in _collect
cls.details = det.as_dict(attrs=attrs, ad_value="")
File "/usr/local/lib/python3.9/site-packages/psutil/__init__.py", line 512,
in as_dict
raise ValueError("invalid attr name%s %s" % (
ValueError: invalid attr name 'cpu_num'
13/12/21 (11:46:16) | WARNING: Exiting with errorcode (1). Runtime 0:00:04
And if you're very brave and run it as root...
12/12/21 (18:52:20) | ERROR: Data collection thread failed with exception:
can't allocate enough space for KERN_PROC_ARGV
Traceback (most recent call last):
File "/usr/local/bin/bpytop", line 2938, in _runner
collector._collect()
File "/usr/local/bin/bpytop", line 3708, in
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: rob...@cvs.openbsd.org 2021/12/13 03:53:56 Modified files: devel/imake: Makefile Log message: make sure that RUN_DEPENDS is not overwritten
Re: Error on make update plist
On Sun, Dec 12, 2021 at 11:25:46AM -0800, Andrew Hewus Fresh wrote:
> On Sun, Dec 12, 2021 at 11:01:36AM -0800, Andrew Hewus Fresh wrote:
> > On Sun, Dec 12, 2021 at 11:42:42AM +, Stuart Henderson wrote:
> > > On 2021/12/12 11:29, Omar Polo wrote:
> > > > > Stripping directories from mail/p5-Email-Address
> > > > > Can't put into any plist (no applicable prefix):
> > > > > /auto
>
> > > It was introduced by this change
> > >
> > > -
> > > PatchSet 1943
> > > Date: 2021/11/23 01:12:38
> > > Author: afresh1
> >
> > Oops, I'm not sure how I missed that.
> > I'll look and see what's going on.
>
> Oops, missed a spot where the variable name changed. Fixed now.
>
> Index: infrastructure/mk/perl.port.mk
> ===
> RCS file: /cvs/ports/infrastructure/mk/perl.port.mk,v
> retrieving revision 1.31
> diff -u -p -r1.31 perl.port.mk
> --- infrastructure/mk/perl.port.mk23 Nov 2021 01:12:38 - 1.31
> +++ infrastructure/mk/perl.port.mk12 Dec 2021 19:23:14 -
> @@ -82,7 +82,7 @@ _MODPERL_preconfig = :
> . endif
> .endif
>
> -MODPERL_pre-fake = mkdir -p ${WRKINST}${PERL_ARCH}/auto
> +MODPERL_pre-fake = mkdir -p ${WRKINST}${P5ARCH}/auto
>
> .if ${CONFIGURE_STYLE:L:Mmodbuild}
> . if ${CONFIGURE_STYLE:L:Mtiny}
>
>
Happy that update-plist catches this kind of error :)
[wip] net/tdlib-purple v8.0
Hello, This is a new port "tdlib-purple" which is the successor to the now more and more defunct telegram-purple. The port works and thus I want to share it here for people that want to use it due to a broken telegram-purple. There is a problem which prevents the import for now. But it's perfectly usable in the current state. 1) telegram-purple and tdlib-purple could coexist, if they would not install the same pixmap files. I'm not sure if I want a conflict marker here or if I can rename the pixmaps. For now, just don't install both. 2) the port needs a registered telegram application and the API_ID and API_KEY needs to be passed at build time. You can do so in the port Makefile. I asked upstream to provide a way to pass this information via config file (or any other way that works at runtime). https://github.com/ars3niy/tdlib-purple/issues/140 Once this is resolved, I'll finalize the port. Best Regards, Stefan tdlib-purple.tgz Description: application/tar-gz
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: ajacou...@cvs.openbsd.org 2021/12/13 03:42:58 Modified files: devel/harfbuzz : Makefile distinfo Log message: Update to harfbuzz-3.2.0.
Re: NEW: sysutils/bpytop
Stefan Hagen writes: > Hi Lewis, > > Lewis ingraham wrote: >> Also I for some reason cannot get the program to launch when it is built >> and installed. It comes up as "command not found" when I type in bpytop. >> >> Project I am currently trying to port properly: >> https://github.com/aristocratos/bpytop > > There is an easier way to get started with python ports. We have > portgen(1) which can give you a head start with perl, python, ruby > and go ports. > > Try "portgen bpytop". It will generate as much of a port it can in > /usr/ports/mystuff/pypi. Then examine what it did and fix it up. > > The port you're trying to create is not using the usual setup.py build > script. Instead it has a Makefile, which copies files around. Portgen > is not prepared for that and it needs fixing. > > I added NO_BUILD=Yes to the port system from trying to invoke setup.py. > Next I added a do-install: target with will be execute as "make install" > command. > > The (quickly) fixed port is attached. It works here. > > Best regards, > Stefan Port looks fine and works, even thought it's a bit too "flashy" for my taste :) The distinfo wasn't right, it complained that "Size does not match for bpytop-1.0.67.tar.gz" and had to makesum again. pypi releases are mutable? % make makesum ===> Checking files for bpytop-1.0.67 >> Fetch https://pypi.io/packages/source/b/bpytop/bpytop-1.0.67.tar.gz bpytop-1.0.67.tar.gz 100% |*| 77732 00:00 --- old +++ new @@ -1,2 +1,2 @@ -SHA256 (bpytop-1.0.67.tar.gz) = 4/Ame9QKWAFrWsge1kJPHI2VOzOlN1RrIt0aKwGwepc= -SIZE (bpytop-1.0.67.tar.gz) = 628491 +SHA256 (bpytop-1.0.67.tar.gz) = izOONif6bpkeg2vuYe84mI9qejo33AXHV6krpDePlbs= +SIZE (bpytop-1.0.67.tar.gz) = 77732
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: lan...@cvs.openbsd.org 2021/12/13 02:59:45 Modified files: audio/cantata : Makefile Log message: audio/cantata: drop unneeded audio/libebur128 from LDEP spotted by sthen@
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: lan...@cvs.openbsd.org 2021/12/13 02:57:06 Modified files: x11/xfce4/xfce4-whiskermenu: Makefile distinfo Log message: x11/xfce4/xfce4-whiskermenu: update to 2.7.1
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: lan...@cvs.openbsd.org 2021/12/13 02:07:05 Modified files: games/f1spirit : Makefile Log message: games/f1spirit: fix WANTLIB and drop unneeded libidn from LDEP spotted by sthen@
Re: UPDATE: www/stagit 0.9.6 -> 1.0
On Thu, Dec 09, 2021 at 09:31:28AM +0100, Hiltjo Posthuma wrote: > Hi, > > Bump, can it be updated? It has now been committed, thanks!
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: fcam...@cvs.openbsd.org 2021/12/13 01:14:28 Modified files: www/stagit : Makefile distinfo Log message: Update stagit to 1.0. >From maintainer Hiltjo Posthuma, thanks! OK sdk@
