CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: k...@cvs.openbsd.org2022/01/24 23:44:56 Modified files: devel/git : Makefile distinfo devel/git/patches: patch-config_mak_uname Log message: Update to git 2.35.0 https://raw.githubusercontent.com/git/git/master/Documentation/RelNotes/2.35.0.txt
Re: devel/cargo: Support fetching crates as GitHub archive tarballs
On Mon, Jan 24, 2022 at 03:01:41PM -0500, Aisha Tammy wrote: > Thanks a lot for the response, it helped the get off the ground and start > compiling at least. > But turns out it needs rust nightly so it doesn't want to build. ah, it is another set of potential dragons here. lang/rust is stable (currently 1.58.1 in -current tree), so requirements for vaultwarden aren't meet. if you want to play with 1.58.1 with some nightly features, you could try to pass RUSTC_BOOTSTRAP=1 environment variable in the build. $ rustc -Z help error: the option `Z` is only accepted on the nightly compiler $ RUSTC_BOOTSTRAP=1 rustc -Z help Available options: -Z allow-features=val -- only allow the listed language features to be enabled in code (space separated) ... But keep in mind that the provided features are from 1.58.1, and vaultwarden could need others features or features silghtly differents (nightly is unstable by nature). Thanks. -- Sebastien Marie
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: gne...@cvs.openbsd.org 2022/01/24 21:11:10 Modified files: productivity/hledger: Makefile distinfo Log message: Upgrade productivity/hledger 1.23->1.24.1 OK kili@
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: dan...@cvs.openbsd.org 2022/01/24 20:13:41 Modified files: geo/foxtrotgps : Makefile Log message: switch to python3 foxtrotgps has supported python3 since version 1.2.1 ok kirby@ (MAINTAINER)
Re: UPDATE net/prosody 0.11.13 from MAINTAINER
Lucas wrote: > Hello ports, > > A quite simple release for prosody to fix a vulnerability in websockets > handling, disabled by default but quite common, at least acording to > Prosody's devs. Nevertheless, it might be good to merge into 7.0, if > possible. Details of the vuln in [0]. > > [0]: https://prosody.im/securit/advisory_20220113/ > > -Lucas Release 0.11.12 introduced a memory leak in the fix, so now there is a 0.11.13 plugging that leak. Summary: * 0.11.12: - util.xml: Do not allow doctypes, comments or processing instructions * 0.11.13: - util.xml: Break reference to help the GC (fixes #1711) - util.xml: Deduplicate handlers for restricted XML -Lucas diff fc43682d4d073143eca1f985644b06c896e848b7 /usr/ports blob - b1dd6e4ac34df90ab7dc9455a66b898126ac13e0 file + net/prosody/Makefile --- net/prosody/Makefile +++ net/prosody/Makefile @@ -1,7 +1,7 @@ # $OpenBSD: Makefile,v 1.65 2022/01/07 20:26:38 rsadowski Exp $ COMMENT = communications server for Jabber/XMPP written in Lua -DISTNAME = prosody-0.11.11 +DISTNAME = prosody-0.11.13 CATEGORIES = net HOMEPAGE = https://prosody.im/ blob - 9ea70c30e4fe50e3d5903b718acd0975779f file + net/prosody/distinfo --- net/prosody/distinfo +++ net/prosody/distinfo @@ -1,2 +1,2 @@ -SHA256 (prosody-0.11.11.tar.gz) = oa+Q4tSsL3z4GzhUdRQOzuYL7B64MAPvta64l2WxN3Q= -SIZE (prosody-0.11.11.tar.gz) = 439395 +SHA256 (prosody-0.11.13.tar.gz) = OcYbNGoJtRJbYEy5aeFCBsu8uGyBFW/8a6LWJSfPBDI= +SIZE (prosody-0.11.13.tar.gz) = 439816
Re: FYI - On the subject of non-OpenBSD developers asking "ok?"
Hi all, Re: fresh blood Can name you quite a few contributors that can be committers today, because they are demoin'g constant input to the project: 1) Caspar Schutijser 2) Wen Heping 3) Dimitri Karamazov There will be still some others I missed but the regular port committers will know, because you commit their contributions. There is nobody to propose for them. Thanks On Fri, Jan 21, 2022 at 11:31 AM Marc Espie wrote: > > In my opinion, our main issue is the lack of new blood. > > We have chronically fewer people who can give okays than ports waiting. > > One big "meta" stuff that needs doing is pointing out (especially from > new guys) what can be improved in the documentation of the porting process... > sometimes pointing people in the right direction. > > Informal poll: what thing weirded you guys out the first time you touched > OpenBSD ports coming from other platforms. > > What kind of gotcha can we get rid of, so that "new ports" will tend to > be squeaky clean, infrastructure-wise, and ready for import. > > Maybe we'd need an FAQ from people coming from elsewhere explaining the > main differences to (say) deb, rpm, freebsd ?... >
Re: llvm 13 memcpy optimiser breaks lang/node
On Mon, Jan 24, 2022 at 10:03:19AM -0700, Theo de Raadt wrote: > Stuart Henderson wrote: > > > On 2022/01/24 22:17, Jonathan Matthew wrote: > > > The proposed update to lang/node makes this irrelevant, but I thought I'd > > > send > > > it anyway since it may come up elsewhere too. > > > > > > I noticed that on one system, 'npm install less' would abort, logging > > > 'node: backwards memcpy', but on another it worked fine. Eventually I > > > figured out this was because the working one had packages built with llvm > > > 11, > > > the other with llvm 13 packages, and llvm 13's memcpy optimiser was > > > turning > > > a series of small memcpys in node's bundled zlib into one larger one, > > > without > > > identifying that the src and dest of the larger memcpy could overlap. > > > > > > Compiling the bundled zlib with -fno-builtin-memcpy prevents it from doing > > > that, which fixes npm. > > > > If we can't trust the compiler's builtin memcpy to do the right thing then > > it probably needs disabling completely... > > Right. We cannot conclude this is only in one specific piece of software. > > Has anyone reached opened a bug report with clang? I'll extract the memcpy loop out and try to turn it into something I can include in a bug report.
Re: new net/tdesktop 3.4.8
On Mon, Jan 24, 2022 at 07:16:42PM +0100, Omar Polo wrote:
> Hello,
>
> Klemens Nanni writes:
>
> > This has been working great so far on amd64 (arm64 I've also tested a
> > few weeks ago, with an older version).
> >
> > Audio and video calls work, with both IPv4 and IPv6.
> > We can send files, viewing media works, etc.
> >
> > There is one rare crash when ending calls in a specific way, but we're
> > on it.
> >
> > All our patches are communicated towards upstream, some need further
> > changes to not break other systems, so that'll take some time.
> >
> > As with tg_owt, I've been using PATCHFILES heavily so we don't carry
> > local patch files unless needed.
>
> maybe I'm blind, but I don't see any PATCHFILES ;)
>
> % grep -i patch Makefile
> PATCHORIG = .pat.orig
> # disable use of unported dispatch library
My bad, mixed things up in writing the mails. tdesktop used to have
PATCHFILES, now we're carrying patches which haven't beaten into
possibly acceptable PRs. Other PRs have been merged already!
> > Feedback? OK?
>
> thanks for working on this port :)
>
> I can log-in, see previous messages, and even make calls. so far,
> everything seems to work fine!
>
> The port and the patches looks fine, just a couple of things:
>
> - I'd drop the @echoes and the `ls -x' in post-extract (same story for
>tg_owt.)
Those are helpful to me at least, especially when updating, to notice
new dependencies and get an insight into what is being deleted before
deleting it (without maintaining a static list of 3rdparty directories
like i used to to before).
> - Does it really need PATCHORIG? ThirdParty/hunspell is removed as per
>post-extract, so it shouldn't cause any issue with update-patches.
Good catch, then it can go in case there are no other offenders left.
> Otherwise it's ok for me, but I prefer if someone else could take a look
> too. I'll continue to test it and will report any issue found :)
>
>
> However, if possible I'd like if the dbus integration could be enabled.
> It's needed to route the notifications through for e.g. dunst (see
> settings -> notifications -> use native notifications.) It needs
> x11/dbusmenu-qt and to "whitelist" statusnotifieritem, but doesn't grow
> the build time significantly. Something like this:
This is on the list, but can we handle this in-tree, please?
Testing has been without dbus integration, builds do take time and it is
a lot of patching already, not to mention the work that went into (new)
dependencies, e.g. updates, cleanups, test policies (who know what fun
glib2mm, libsigc++-2 and dbusmenu-qt bring in).
Once our telegram ports settled, we can polish, upstream, test, etc.
See the libyuv for another side-quest that came out of this.
> --- /tmp/tdesktop/MakefileMon Jan 24 15:54:38 2022
> +++ Makefile Mon Jan 24 19:15:44 2022
> @@ -23,14 +23,15 @@
> # rlottie: LGPL 2.1 with freetype, LGPL, MIT, BSD dependencies
> PERMIT_PACKAGE = Yes
>
> -WANTLIB += ${COMPILER_LIBCXX} Qt5Core Qt5Gui Qt5Network Qt5Svg
> -WANTLIB += Qt5Widgets X11 absl_base absl_int128 absl_log_severity
> +WANTLIB += ${COMPILER_LIBCXX} Qt5Core Qt5DBus Qt5Gui Qt5Network
> +WANTLIB += Qt5Svg Qt5Widgets X11 absl_base absl_int128 absl_log_severity
> WANTLIB += absl_raw_logging_internal absl_spinlock_wait absl_strings
> WANTLIB += absl_strings_internal absl_throw_delegate avcodec avformat
> -WANTLIB += avutil c crypto event_core event_extra hunspell-1.7
> -WANTLIB += lz4 m openal qrcodegencpp rnnoise swresample swscale
> -WANTLIB += tg_owt usrsctp vpx xcb xcb-keysyms xcb-record xcb-screensaver
> -WANTLIB += xxhash z
> +WANTLIB += avutil c crypto dbusmenu-qt5 event_core event_extra
> +WANTLIB += gio-2.0 giomm-2.4 glib-2.0 glibmm-2.4 gobject-2.0 hunspell-1.7
> +WANTLIB += lz4 m openal qrcodegencpp rnnoise sigc-2.0 swresample
> +WANTLIB += swscale tg_owt usrsctp vpx xcb xcb-keysyms xcb-record
> +WANTLIB += xcb-screensaver xxhash z
>
> # C++17 set below
> COMPILER = base-clang ports-gcc
> @@ -48,13 +49,16 @@
> audio/rnnoise \
> audio/openal \
> devel/abseil-cpp \
> + devel/glib2mm \
> devel/libevent2 \
> + devel/libsigc++-2 \
> graphics/ffmpeg \
> graphics/qr-code-generator>=1.7.0p1 \
> net/tg_owt \
> net/usrsctp>=0.9.5.0p2 \
> sysutils/xxhash \
> textproc/hunspell \
> + x11/dbusmenu-qt \
> x11/qt5/qtsvg
>
> RUN_DEPENDS =devel/desktop-file-utils \
> @@ -73,7 +77,6 @@
>
> # disable unported/unwanted components
> CONFIGURE_ARGS +=-DDESKTOP_APP_DISABLE_WAYLAND_INTEGRATION=ON \
> - -DDESKTOP_APP_DISABLE_DBUS_INTEGRATION=ON \
> -DDESKTOP_APP_QT6=OFF
>
> # match standard version
Re: new net/tdesktop 3.4.8
Hello,
Klemens Nanni writes:
> This has been working great so far on amd64 (arm64 I've also tested a
> few weeks ago, with an older version).
>
> Audio and video calls work, with both IPv4 and IPv6.
> We can send files, viewing media works, etc.
>
> There is one rare crash when ending calls in a specific way, but we're
> on it.
>
> All our patches are communicated towards upstream, some need further
> changes to not break other systems, so that'll take some time.
>
> As with tg_owt, I've been using PATCHFILES heavily so we don't carry
> local patch files unless needed.
maybe I'm blind, but I don't see any PATCHFILES ;)
% grep -i patch Makefile
PATCHORIG = .pat.orig
# disable use of unported dispatch library
> Feedback? OK?
thanks for working on this port :)
I can log-in, see previous messages, and even make calls. so far,
everything seems to work fine!
The port and the patches looks fine, just a couple of things:
- I'd drop the @echoes and the `ls -x' in post-extract (same story for
tg_owt.)
- Does it really need PATCHORIG? ThirdParty/hunspell is removed as per
post-extract, so it shouldn't cause any issue with update-patches.
Otherwise it's ok for me, but I prefer if someone else could take a look
too. I'll continue to test it and will report any issue found :)
However, if possible I'd like if the dbus integration could be enabled.
It's needed to route the notifications through for e.g. dunst (see
settings -> notifications -> use native notifications.) It needs
x11/dbusmenu-qt and to "whitelist" statusnotifieritem, but doesn't grow
the build time significantly. Something like this:
--- /tmp/tdesktop/Makefile Mon Jan 24 15:54:38 2022
+++ MakefileMon Jan 24 19:15:44 2022
@@ -23,14 +23,15 @@
# rlottie: LGPL 2.1 with freetype, LGPL, MIT, BSD dependencies
PERMIT_PACKAGE = Yes
-WANTLIB += ${COMPILER_LIBCXX} Qt5Core Qt5Gui Qt5Network Qt5Svg
-WANTLIB += Qt5Widgets X11 absl_base absl_int128 absl_log_severity
+WANTLIB += ${COMPILER_LIBCXX} Qt5Core Qt5DBus Qt5Gui Qt5Network
+WANTLIB += Qt5Svg Qt5Widgets X11 absl_base absl_int128 absl_log_severity
WANTLIB += absl_raw_logging_internal absl_spinlock_wait absl_strings
WANTLIB += absl_strings_internal absl_throw_delegate avcodec avformat
-WANTLIB += avutil c crypto event_core event_extra hunspell-1.7
-WANTLIB += lz4 m openal qrcodegencpp rnnoise swresample swscale
-WANTLIB += tg_owt usrsctp vpx xcb xcb-keysyms xcb-record xcb-screensaver
-WANTLIB += xxhash z
+WANTLIB += avutil c crypto dbusmenu-qt5 event_core event_extra
+WANTLIB += gio-2.0 giomm-2.4 glib-2.0 glibmm-2.4 gobject-2.0 hunspell-1.7
+WANTLIB += lz4 m openal qrcodegencpp rnnoise sigc-2.0 swresample
+WANTLIB += swscale tg_owt usrsctp vpx xcb xcb-keysyms xcb-record
+WANTLIB += xcb-screensaver xxhash z
# C++17 set below
COMPILER = base-clang ports-gcc
@@ -48,13 +49,16 @@
audio/rnnoise \
audio/openal \
devel/abseil-cpp \
+ devel/glib2mm \
devel/libevent2 \
+ devel/libsigc++-2 \
graphics/ffmpeg \
graphics/qr-code-generator>=1.7.0p1 \
net/tg_owt \
net/usrsctp>=0.9.5.0p2 \
sysutils/xxhash \
textproc/hunspell \
+ x11/dbusmenu-qt \
x11/qt5/qtsvg
RUN_DEPENDS = devel/desktop-file-utils \
@@ -73,7 +77,6 @@
# disable unported/unwanted components
CONFIGURE_ARGS += -DDESKTOP_APP_DISABLE_WAYLAND_INTEGRATION=ON \
- -DDESKTOP_APP_DISABLE_DBUS_INTEGRATION=ON \
-DDESKTOP_APP_QT6=OFF
# match standard version with abseil
@@ -87,6 +90,8 @@
# archivers/minizip is minizip-ng, telegram requires incompatible original zlib
NEEDED_BUNDLES += minizip
+# statusnotifieritem is not available in the port tree
+NEEDED_BUNDLES += statusnotifieritem
# unported and required
NEEDED_BUNDLES += rlottie tgcalls
Re: FYI - On the subject of non-OpenBSD developers asking "ok?"
Dima Pasechnik writes: > On Mon, Jan 24, 2022 at 04:57:49PM +, Stuart Henderson wrote: >> On 2022/01/24 15:51, Dima Pasechnik wrote: >> > Would a git-generated email with a diff be acceptable? >> > https://git-send-email.io/ >> >> Yes as long as it's not one of those big [1/n] sequences of separate >> emails that would be better dealt with in a single mail :) >> >> > In principle, such a patch would be very easy to apply (with git) >> > to your local git repo - and it can be bounced to appropriately configured >> > CI... >> >> Applying it with git isn't useful for someone who is going to commit >> it to cvs because (even if they use a mixture of git/got+cvs themselves) >> it still needs to get into their cvs checkout. > > I'm guessing here, but can't you overlay CVS and git trees? > If it's possible then merging with git will produce a CVS diff. > >> >> > > At the moment it's hidden in a page named 'Building the System from >> > > Source', not very clear. Maybe put in on porter's handbook? >> > > >> > > - Some kind of automated pre-submission sanity test would be nice. >> > > Should be simpler than a full CI setup. (is my diff mangled? is my >> > > tree outdated?) >> > The OpenBSD-supporting CI I mentioned in my other email >> > https://man.sr.ht/builds.sr.ht/compatibility.md#openbsd >> > would be very easy to set up for this. >> >> What would you propose a CI to do for ports submissions? > > building (maybe testing too) the new/updated port only, just on amd64, as a > start. > > Dima My thought on this is basically: cd /usr/ports/thing/thatchanged && \ portcheck && \ make FETHC_PACKAGES= Also as far as CI "runners" go, this one looks promising: https://github.com/mario-campos/emulate Obviously 7.0 wouldn't be sufficient to do ports testing, but maybe current could be added without much hassle. Another issue is having a ports tree in the "runner".. a git checkout is large, but maybe since it would be "local" to github it wouldn't be _that_ bad?.. but a cvs checkout would be way to slow. > >> >> Identifying and building ports that depend on a particular port and >> doing a build of all of them on a clean -current OpenBSD system could >> be useful in some cases, though complete overkill in most, and would >> take long enough that it would be silly to do before a basic review. >> >> There's another consideration with this. In a way it's good if a diff >> from a less-experienced porter has some easier-to-spot issues (i.e. >> the sort of issues that an automated check would be likely to identify) >> because it's a bit of a flag that other, harder to spot, issues are >> likely to be present too. >>
Re: Upgrade productivity/hledger 1.23->1.24.1
Hi, On Wed, Jan 19, 2022 at 10:29:41PM -0800, Greg Steuck wrote: > I'm running this locally. Works fine so far. OK? Looks and builds fine to me, so ok. Ciao, Kili
Re: [UPDATE] print/ghostscript/gnu 9.55.0
Hi, and sorry for the delay, On Mon, Jan 24, 2022 at 05:56:21PM +0100, Volker Schlecht wrote: > Sorry to bother you about it, but did you get around to having a look at the > patch? Looks good so far, I also ran dpb -uR to rebuild any packages depending on it, without any problems. I'll do some additional testing tomorrow but I don't expect any problems. Ciao, Kili
Re: FYI - On the subject of non-OpenBSD developers asking "ok?"
On Mon, Jan 24, 2022 at 04:57:49PM +, Stuart Henderson wrote: > On 2022/01/24 15:51, Dima Pasechnik wrote: > > Would a git-generated email with a diff be acceptable? > > https://git-send-email.io/ > > Yes as long as it's not one of those big [1/n] sequences of separate > emails that would be better dealt with in a single mail :) > > > In principle, such a patch would be very easy to apply (with git) > > to your local git repo - and it can be bounced to appropriately configured > > CI... > > Applying it with git isn't useful for someone who is going to commit > it to cvs because (even if they use a mixture of git/got+cvs themselves) > it still needs to get into their cvs checkout. I'm guessing here, but can't you overlay CVS and git trees? If it's possible then merging with git will produce a CVS diff. > > > > At the moment it's hidden in a page named 'Building the System from > > > Source', not very clear. Maybe put in on porter's handbook? > > > > > > - Some kind of automated pre-submission sanity test would be nice. > > > Should be simpler than a full CI setup. (is my diff mangled? is my > > > tree outdated?) > > The OpenBSD-supporting CI I mentioned in my other email > > https://man.sr.ht/builds.sr.ht/compatibility.md#openbsd > > would be very easy to set up for this. > > What would you propose a CI to do for ports submissions? building (maybe testing too) the new/updated port only, just on amd64, as a start. Dima > > Identifying and building ports that depend on a particular port and > doing a build of all of them on a clean -current OpenBSD system could > be useful in some cases, though complete overkill in most, and would > take long enough that it would be silly to do before a basic review. > > There's another consideration with this. In a way it's good if a diff > from a less-experienced porter has some easier-to-spot issues (i.e. > the sort of issues that an automated check would be likely to identify) > because it's a bit of a flag that other, harder to spot, issues are > likely to be present too. >
Re: llvm 13 memcpy optimiser breaks lang/node
Stuart Henderson wrote: > On 2022/01/24 22:17, Jonathan Matthew wrote: > > The proposed update to lang/node makes this irrelevant, but I thought I'd > > send > > it anyway since it may come up elsewhere too. > > > > I noticed that on one system, 'npm install less' would abort, logging > > 'node: backwards memcpy', but on another it worked fine. Eventually I > > figured out this was because the working one had packages built with llvm > > 11, > > the other with llvm 13 packages, and llvm 13's memcpy optimiser was turning > > a series of small memcpys in node's bundled zlib into one larger one, > > without > > identifying that the src and dest of the larger memcpy could overlap. > > > > Compiling the bundled zlib with -fno-builtin-memcpy prevents it from doing > > that, which fixes npm. > > If we can't trust the compiler's builtin memcpy to do the right thing then > it probably needs disabling completely... Right. We cannot conclude this is only in one specific piece of software. Has anyone reached opened a bug report with clang?
Re: llvm 13 memcpy optimiser breaks lang/node
On 2022/01/24 22:17, Jonathan Matthew wrote: > The proposed update to lang/node makes this irrelevant, but I thought I'd send > it anyway since it may come up elsewhere too. > > I noticed that on one system, 'npm install less' would abort, logging > 'node: backwards memcpy', but on another it worked fine. Eventually I > figured out this was because the working one had packages built with llvm 11, > the other with llvm 13 packages, and llvm 13's memcpy optimiser was turning > a series of small memcpys in node's bundled zlib into one larger one, without > identifying that the src and dest of the larger memcpy could overlap. > > Compiling the bundled zlib with -fno-builtin-memcpy prevents it from doing > that, which fixes npm. If we can't trust the compiler's builtin memcpy to do the right thing then it probably needs disabling completely...
Re: FYI - On the subject of non-OpenBSD developers asking "ok?"
On 2022/01/24 15:51, Dima Pasechnik wrote: > Would a git-generated email with a diff be acceptable? > https://git-send-email.io/ Yes as long as it's not one of those big [1/n] sequences of separate emails that would be better dealt with in a single mail :) > In principle, such a patch would be very easy to apply (with git) > to your local git repo - and it can be bounced to appropriately configured > CI... Applying it with git isn't useful for someone who is going to commit it to cvs because (even if they use a mixture of git/got+cvs themselves) it still needs to get into their cvs checkout. > > At the moment it's hidden in a page named 'Building the System from > > Source', not very clear. Maybe put in on porter's handbook? > > > > - Some kind of automated pre-submission sanity test would be nice. > > Should be simpler than a full CI setup. (is my diff mangled? is my > > tree outdated?) > The OpenBSD-supporting CI I mentioned in my other email > https://man.sr.ht/builds.sr.ht/compatibility.md#openbsd > would be very easy to set up for this. What would you propose a CI to do for ports submissions? Identifying and building ports that depend on a particular port and doing a build of all of them on a clean -current OpenBSD system could be useful in some cases, though complete overkill in most, and would take long enough that it would be silly to do before a basic review. There's another consideration with this. In a way it's good if a diff from a less-experienced porter has some easier-to-spot issues (i.e. the sort of issues that an automated check would be likely to identify) because it's a bit of a flag that other, harder to spot, issues are likely to be present too.
Re: update: net/msoak
On 2022/01/24 09:18, Jan-Piet Mens wrote: > Hello! > > This is an update for msoak(1), a utility with which to simultaneously > subscribe to an arbitrary number of topics on any number of MQTT brokers and > optionally modify or normalize received payloads with Lua functions before > printing them out. thanks, committed.
Re: [UPDATE] print/ghostscript/gnu 9.55.0
Sorry to bother you about it, but did you get around to having a look at
the patch?
On 1/17/22 20:51, Matthias Kilian wrote:
Hi,
On Sun, Jan 16, 2022 at 05:12:25PM +0100, Volker Schlecht wrote:
Update with Makefile in the same order as the current port, I hope this
makes reviewing easier.
Thanks! I'll have a look and do some tests during this week.
Ciao,
Kili
Index: Makefile
===
RCS file: /cvs/ports/print/ghostscript/gnu/Makefile,v
retrieving revision 1.117
diff -u -p -u -p -r1.117 Makefile
--- Makefile28 Feb 2021 12:40:28 - 1.117
+++ Makefile16 Jan 2022 16:10:46 -
@@ -1,161 +1,111 @@
-# $OpenBSD: Makefile,v 1.117 2021/02/28 12:40:28 sthen Exp $
+# $OpenBSD$
-COMMENT= GNU PostScript interpreter
+COMMENT =PostScript and PDF interpreter
-VERSION= 9.07
-DISTNAME= ghostscript-${VERSION}
-CATEGORIES=print lang
-SHARED_LIBS= gs 15.0
-REVISION= 7
+VERSION =9.55.0
+DISTNAME = ghostscript-${VERSION}
+CATEGORIES = lang print
+SHARED_LIBS =gs 16.0
-MASTER_SITES= ${MASTER_SITE_SOURCEFORGE:=ghostscript/}
+MASTER_SITES =
https://github.com/ArtifexSoftware/ghostpdl-downloads/releases/download/gs${VERSION:S/.//g}/
-PORTROACH= site:https://github.com/ArtifexSoftware/ghostpdl-downloads/releases/
+PORTROACH =
site:https://github.com/ArtifexSoftware/ghostpdl-downloads/releases/
-HOMEPAGE= http://www.cs.wisc.edu/~ghost/
+HOMEPAGE = https://ghostscript.com/
-MAINTAINER= Matthias Kilian
+MAINTAINER = Matthias Kilian
-FLAVORS= a4 gtk no_x11
+FLAVORS =a4 gtk no_x11
FLAVOR?=
-FLAVOR_STRING= ${FLAVOR_EXT:S/-/,/g}
+FLAVOR_STRING =${FLAVOR_EXT:S/-/,/g}
-SUBST_VARS= VERSION FLAVOR_STRING
+SUBST_VARS = VERSION FLAVOR_STRING
# AGPLv3, except for the included CMap files from Adobe, which may
# only be redistributed without modifications.
-PERMIT_PACKAGE=Yes
+PERMIT_PACKAGE= Yes
-WANTLIB= c iconv ijs m jbig2dec jpeg>=62 lcms2 png>=6 pthread tiff z
+WANTLIB = c m pthread z cups fontconfig freetype iconv idn ijs jpeg jbig2dec \
+openjp2 paper png tiff
-RUN_DEPENDS= print/ghostscript/gnu-fonts>=8.11p3
-LIB_DEPENDS= converters/libiconv \
- graphics/jbig2dec \
- graphics/jpeg \
- graphics/lcms2 \
- graphics/png\
- graphics/tiff \
- print/ijs
-
-CFLAGS+= -DSYS_TYPES_HAS_STDINT_TYPES\
- -I${LOCALBASE}/include \
- -I${LOCALBASE}/include/ijs
-
-STDLIBS= -pthread -lm -liconv
-
-# Note: all the device definitions are at the very end of this makefile.
-
-MAKE_FLAGS=BINDIR=./obj\
- CFLAGS_STANDARD='${CFLAGS} -fPIC' \
- COMPILE_INITS=0 \
- DEVICE_DEVS='${DEVICES:C/.*/\$(DD)&.dev/}' \
- EXTRALIBS="${EXTRALIBS}" \
- FT_BRIDGE=${FT_BRIDGE} \
- GLGENDIR=./obj \
- GLOBJDIR=./obj \
- GLSRCDIR=./base \
- ICCSRCDIR=./icclib \
- INSTALL='${INSTALL}'\
- INSTALL_DATA='${INSTALL_DATA}' \
- INSTALL_PROGRAM='${INSTALL_PROGRAM}'\
- LIBgs_VERSION=${LIBgs_VERSION} \
- PSGENDIR=./obj \
- PSLIBDIR=./lib \
- PSOBJDIR=./obj \
- PSSRCDIR=./psi \
- SHARE_FT=1 \
- SHARE_IJS=1 \
- SHARE_JBIG2=1 \
- SHARE_JPEG=1\
- SHARE_LCMS=1\
- SHARE_LIBPNG=1 \
- SHARE_LIBTIFF=1 \
- SHARE_ZLIB=1\
- SOBINRELDIR=../obj \
- SOOBJRELDIR=../obj \
- SOC_CFLAGS="${SOC_CFLAGS}"\
- SOC_LIBS="${SOC_LIBS}"\
- STDLIBS='${STDLIBS}'\
- SYNC=posync \
- TRUE_PREFIX='${LOCALBASE}' \
- USE_GTK=${USE_GTK} \
- XLDFLAGS=-L${LOCALBASE}/lib \
- prefix='${PREFIX}'
-
-USE_GMAKE= Yes
-
-ALL_TARGET = so all ${ALL_TARGET_CUPS}
-INSTALL_TARGET = install install-so
-
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: st...@cvs.openbsd.org 2022/01/24 09:40:17 Modified files: net/msoak : Makefile distinfo Log message: update to msoak-0.8, from Jan-Piet Mens
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: st...@cvs.openbsd.org 2022/01/24 09:36:31 Modified files: net/unifi : Tag: OPENBSD_7_0 Makefile.inc net/unifi/5.14 : Tag: OPENBSD_7_0 Makefile distinfo net/unifi/5.14/pkg: Tag: OPENBSD_7_0 PLIST net/unifi/5.6 : Tag: OPENBSD_7_0 Makefile net/unifi/6.0 : Tag: OPENBSD_7_0 Makefile distinfo net/unifi/6.0/pkg: Tag: OPENBSD_7_0 PLIST net/unifi/6.1 : Tag: OPENBSD_7_0 Makefile distinfo net/unifi/6.1/pkg: Tag: OPENBSD_7_0 PLIST net/unifi/6.2 : Tag: OPENBSD_7_0 Makefile distinfo net/unifi/6.2/pkg: Tag: OPENBSD_7_0 PLIST Log message: -stable net/unifi, update log4j versions, requested by Steven Surdock
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: st...@cvs.openbsd.org 2022/01/24 09:35:54 Modified files: net/unifi/5.14 : Makefile net/unifi/6.0 : Makefile net/unifi/main : Makefile Log message: bump, missed in previous
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: st...@cvs.openbsd.org 2022/01/24 09:35:12 Modified files: net/unifi : Makefile.inc net/unifi/5.14 : distinfo net/unifi/6.0 : distinfo net/unifi/main : distinfo Log message: net/unifi/*: update log4j versions
[update] x11/alacritty
hello, New release(0.10.0) of alacritty. attached is the x11/alacritty port diff. Please let me know if anything needs to be changed. hth, cheers, Eric. alacritty.diff Description: Binary data
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: es...@cvs.openbsd.org 2022/01/24 08:17:08 Modified files: databases/ports-readmes-dancer: Makefile distinfo Log message: hopefully this is the final fix for valid characters in paths and categories
new net/tdesktop 3.4.8
This has been working great so far on amd64 (arm64 I've also tested a few weeks ago, with an older version). Audio and video calls work, with both IPv4 and IPv6. We can send files, viewing media works, etc. There is one rare crash when ending calls in a specific way, but we're on it. All our patches are communicated towards upstream, some need further changes to not break other systems, so that'll take some time. As with tg_owt, I've been using PATCHFILES heavily so we don't carry local patch files unless needed. Feedback? OK? --- Information for inst:tdesktop-3.4.8 Comment: Telegram Desktop messenger Description: Telegram Desktop is the official desktop client for the Telegram messenger, based on the Telegram API and the MTProto secure protocol. Maintainer: Andrew Krasavin , Klemens Nanni WWW: https://desktop.telegram.org tdesktop.tgz Description: Binary data
Re: new net/tg_owt 0.0.0.20220123
On Sat, Dec 25, 2021 at 11:16:40AM +, Klemens Nanni wrote: > Here is the first of two ports for telegram's official desktop > application port, their library required behind the qt gui. > > This builds and works fine on amd64 and arm64. > Audio and video calls, sending files, viewing media... it all works. > > It still builds a few (unported) dependencies as bundles, but we are > actively working on those to be split out into proper ports. > > At this point in time it seems to be more work juggling even more > patches and port more stuff, so my plan is to get it in now and improve > things over time. > > I have submitted all required patches upstream; they are fetched via > PATCHFILES so patches/ only contains a trivial CMakeLists.txt patch wrt. > bundles/ports. > > This is a joint effort with Andew. > > Information for inst:tg_owt-0.0.0.20211214 > > Comment: > WebRTC build for Telegram > > Required by: > tdesktop-3.3.0 > > Description: > tg_owt is a WebRTC build for Telegram Desktop (net/tdesktop). > > WebRTC is an open source project that enables web browsers with > Real-Time > Communications (RTC) capabilities via simple Javascript APIs. > The WebRTC components have been optimized to best serve this purpose. > WebRTC implements the W3C's proposal for video conferencing on the web. > > Maintainer: Andrew Krasavin , Klemens Nanni > > > WWW: https://github.com/desktop-app/tg_owt > > Feedback? OK? New version. Upstream isn't very responsive which is why none of the PRs have been merged yet, but we've upstreamed everything we could so far. I'll send net/tdesktop to ports@ now as well. This has been tested by a wider community already on amd64 without any problems so far. I've also tested it on arm64 a few weeks ago. tg_owt.tgz Description: Binary data
update: net/msoak
Hello! This is an update for msoak(1), a utility with which to simultaneously subscribe to an arbitrary number of topics on any number of MQTT brokers and optionally modify or normalize received payloads with Lua functions before printing them out. Regards, -JP diff --git a/net/msoak/Makefile b/net/msoak/Makefile index 692f3d152e9..db23c960078 100644 --- a/net/msoak/Makefile +++ b/net/msoak/Makefile @@ -4,7 +4,7 @@ COMMENT = subscribe to multiple MQTT brokers and topics simultaneously GH_ACCOUNT = jpmens GH_PROJECT = msoak -GH_TAGNAME = 0.6 +GH_TAGNAME = 0.8 CATEGORIES = net diff --git a/net/msoak/distinfo b/net/msoak/distinfo index 61da59e4dff..b17b36e1e17 100644 --- a/net/msoak/distinfo +++ b/net/msoak/distinfo @@ -1,2 +1,2 @@ -SHA256 (msoak-0.6.tar.gz) = 4TlvM+QSpaNPLiPsQVC+tNflSeBLPOLI/nDFWukm6Z4= -SIZE (msoak-0.6.tar.gz) = 140523 +SHA256 (msoak-0.8.tar.gz) = udfSXrUgOnxfK2+i7Bm8og71iUiFYqyJAfVPPKkFas4= +SIZE (msoak-0.8.tar.gz) = 141831
Re: FYI - On the subject of non-OpenBSD developers asking "ok?"
On Mon, Jan 24, 2022 at 01:49:26PM +, Yifei Zhan wrote: > On 22/01/22 02:30AM, Marc Espie wrote: > > On Fri, Jan 21, 2022 at 02:07:10PM -0700, Anthony J. Bentley wrote: > > > Volker Schlecht writes: > > > > > What kind of gotcha can we get rid of, so that "new ports" will tend > > > > > to > > > > > be squeaky clean, infrastructure-wise, and ready for import. > > > > An FAQ of sorts might *help*, particularly one addressing the more > > > > typical beginner mistakes. What are the things that you guys > > > > immediately > > > > look out for when a new name offers up a diff because they're usually > > > > done wrong? > > > > > > There's https://www.openbsd.org/faq/ports/ ; it's wide open for > > > suggestions and improvements including possibly large-scale rewriting... > > > Feel free to send a diff for it to ports@. > > > > > > > > Any kind of pointers (including diffs to manpages or whatever) that > > would make it easier for newcomers to find that > > would be a great addition to the system. > > > > Especially from "newer" people who have been figuring it out. > > > > Us old-timers have about ZERO idea what's actually needed. > > > > Some ideas: > > - How to find LIBDEP: > https://marc.info/?l=openbsd-ports=164089356505525=2 > > - A simple CVS quick start guide would be nice, I spent way too long > to learn it and I'm still not totally sure how it works. (e.g. how to > generate a diff properly/how to apply an inline patch/how to handle > new directory...etc) > > yes there are countless guides alrealy on the internet, but most of > them are confusing and not really suitable for OpenBSD's workflow. > > and since we are here, what's your workflow of testing/generating > diff? often I would corrupt my ports tree while testing/generating > diff and have to check out a fresh copy) > > - Make it more clear that git generated diff is acceptable Would a git-generated email with a diff be acceptable? https://git-send-email.io/ In principle, such a patch would be very easy to apply (with git) to your local git repo - and it can be bounced to appropriately configured CI... > > At the moment it's hidden in a page named 'Building the System from > Source', not very clear. Maybe put in on porter's handbook? > > - Some kind of automated pre-submission sanity test would be nice. > Should be simpler than a full CI setup. (is my diff mangled? is my > tree outdated?) The OpenBSD-supporting CI I mentioned in my other email https://man.sr.ht/builds.sr.ht/compatibility.md#openbsd would be very easy to set up for this. Dima
infrastructure: tighten checks for CATEGORIES, FULLPKGPATH
So that they match what ports-readmes-dancer will do.
I checked that I got every currently used character in both variables.
Any objection ?
Index: bsd.port.mk
===
RCS file: /cvs/ports/infrastructure/mk/bsd.port.mk,v
retrieving revision 1.1566
diff -u -p -r1.1566 bsd.port.mk
--- bsd.port.mk 20 Jan 2022 09:35:50 - 1.1566
+++ bsd.port.mk 24 Jan 2022 14:25:01 -
@@ -1003,6 +1003,7 @@ DEBUG ?= -g
CONFIGURE_ARGS += ${DEBUG_CONFIGURE_ARGS}
.endif
+_authorized_chars = -a-zA-Z0-9_./+
.if empty(SUBPACKAGE) || ${SUBPACKAGE} == "-"
FULLPKGPATH ?= ${PKGPATH}${FLAVOR_EXT:S/-/,/g}
FULLPKGPATH- = ${FULLPKGPATH}
@@ -1013,10 +1014,22 @@ _ALLPKGPATHS = ${PKGPATH}${FLAVOR_EXT:S/
. for _S in ${MULTI_PACKAGES}
FULLPKGPATH${_S} ?= ${PKGPATH},${_S}${FLAVOR_EXT:S/-/,/g}
_ALLPKGPATHS += ${FULLPKGPATH${_S}}
+.for _a in ${_authorized_chars},
+. if ${FULLPKGPATH${_S}:M*[^${_a}]*}
+ERRORS += "Fatal: FULLPKGPATH${_S}=${FULLPKGPATH${_S}} uses forbidden
characters '${FULLPKGPATH${_S}:C@[${_a}]@@g}'"
+. endif
+.endfor
. endfor
FULLPKGPATH = ${FULLPKGPATH${SUBPACKAGE}}
_FULLPKGPATH = ${PKGPATH},${SUBPACKAGE}${_FLAVOR_EXT2:S/-/,/g}
.endif
+
+
+.for _a in ${_authorized_chars}
+. if ${CATEGORIES:M*[^${_a}]*}
+ERRORS += "Fatal: CATEGORIES=${CATEGORIES} uses forbidden characters
'${CATEGORIES:C@[${_a}]@@g}'"
+. endif
+.endfor
_INSTALL ?= ${WRKDIR}/bin/install
Re: FYI - On the subject of non-OpenBSD developers asking "ok?"
On Mon, Jan 24, 2022 at 01:49:26PM +, Yifei Zhan wrote: > On 22/01/22 02:30AM, Marc Espie wrote: > > On Fri, Jan 21, 2022 at 02:07:10PM -0700, Anthony J. Bentley wrote: > > > Volker Schlecht writes: > > > > > What kind of gotcha can we get rid of, so that "new ports" will tend > > > > > to > > > > > be squeaky clean, infrastructure-wise, and ready for import. > > > > An FAQ of sorts might *help*, particularly one addressing the more > > > > typical beginner mistakes. What are the things that you guys > > > > immediately > > > > look out for when a new name offers up a diff because they're usually > > > > done wrong? > > > > > > There's https://www.openbsd.org/faq/ports/ ; it's wide open for > > > suggestions and improvements including possibly large-scale rewriting... > > > Feel free to send a diff for it to ports@. > > > > > > > > Any kind of pointers (including diffs to manpages or whatever) that > > would make it easier for newcomers to find that > > would be a great addition to the system. > > > > Especially from "newer" people who have been figuring it out. > > > > Us old-timers have about ZERO idea what's actually needed. > > > > Some ideas: > > - How to find LIBDEP: > https://marc.info/?l=openbsd-ports=164089356505525=2 > There's some supplementary work I need to do in port-lib-depends, namely interface it with the pkglocatedb so that missing dependencies can be located more easily. Also, yeah, that code is rather hard to read, I know. > - A simple CVS quick start guide would be nice, I spent way too long > to learn it and I'm still not totally sure how it works. (e.g. how to > generate a diff properly/how to apply an inline patch/how to handle > new directory...etc) It's a complete pain in the ass in any case. > yes there are countless guides alrealy on the internet, but most of > them are confusing and not really suitable for OpenBSD's workflow. > > and since we are here, what's your workflow of testing/generating > diff? often I would corrupt my ports tree while testing/generating > diff and have to check out a fresh copy) > > - Make it more clear that git generated diff is acceptable Yeah, that's a really good point. > At the moment it's hidden in a page named 'Building the System from > Source', not very clear. Maybe put in on porter's handbook? > > - Some kind of automated pre-submission sanity test would be nice. > Should be simpler than a full CI setup. (is my diff mangled? is my > tree outdated?) > You got portcheck for that one. It does validate new ports and ports after diff. Notice that https://www.openbsd.org/faq/index.html contains a Porter's handbook and a Port Testing guide. If those are not apparent enough, diffs are welcome. If things are missing in there, again, diffs are welcome.
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: st...@cvs.openbsd.org 2022/01/24 06:56:51 Modified files: net/librenms : Makefile distinfo net/librenms/pkg: PLIST Log message: update to librenms-22.1.0
Re: sysutils/ssh-copy-id: use EXTRACT_FILES, do not strip
EXTRACT_FILES is going a bit far isn't it? It's not like it's a large
distfile. If you really must then please at least add Changelog to the
extracted files.
--
Sent from a phone, apologies for poor formatting.
On 24 January 2022 11:23:49 Klemens Nanni wrote:
No need to extract all of ssh.
Fix
strip:
/usr/ports/pobj/ssh-copy-id-8.8pl1/fake-amd64/usr/local/bin/INS@Ja1VJB5n7N:
File format not recognized
in `make fake' while here.
OK?
Index: Makefile
===
RCS file: /cvs/ports/sysutils/ssh-copy-id/Makefile,v
retrieving revision 1.1.1.1
diff -u -p -r1.1.1.1 Makefile
--- Makefile6 Feb 2020 14:10:05 - 1.1.1.1
+++ Makefile24 Jan 2022 11:21:00 -
@@ -6,6 +6,8 @@ DISTNAME= openssh-${V}
PKGNAME=ssh-copy-id-${V:S/p/pl/}
CATEGORIES= sysutils
+EXTRACT_FILES= ${DISTNAME}/contrib/ssh-copy-id{,.1}
+
HOMEPAGE= http://git.hands.com/ssh-copy-id
MAINTAINER= Jan-Piet Mens
@@ -19,8 +21,7 @@ NO_TEST= Yes
PKG_ARCH= *
do-install:
- ${INSTALL_PROGRAM} ${WRKSRC}/contrib/ssh-copy-id ${PREFIX}/bin
- ${INSTALL_MAN_DIR} ${PREFIX}/man/man1
- ${INSTALL_MAN} ${WRKSRC}/contrib/ssh-copy-id.1 ${PREFIX}/man/man1
+ ${INSTALL_SCRIPT} ${WRKSRC}/contrib/ssh-copy-id ${PREFIX}/bin/
+ ${INSTALL_MAN} ${WRKSRC}/contrib/ssh-copy-id.1 ${PREFIX}/man/man1/
.include
Re: devel/cargo: Support fetching crates as GitHub archive tarballs
On Sun, Jan 23, 2022 at 07:32:13PM -0500, aisha wrote:
>
> Did this ever get developed further?
> Many folks have tried to make a vaultwarden port (and failed) and I believe
> this would help with that.
> Currently while trying to create the port I get the following error -
>
> ===> Building for vaultwarden-1.23.1
>
> error: failed to resolve patches for
> `https://github.com/rust-lang/crates.io-index`
>
> Caused by:
> failed to load source for dependency `job_scheduler`
>
> Caused by:
> Unable to update
> https://github.com/jjlin/job_scheduler?rev=ee023418dbba2bfe1e30a5fd7d937f9e33739806#ee023418
>
> Caused by:
> can't checkout from 'https://github.com/jjlin/job_scheduler': you are in
> the offline mode (--offline)
> *** Error 101 in . (/usr/ports/devel/cargo/cargo.port.mk:319 'do-build': @cd
> /usr/ports/pobj/vaultwarden-1.23.1/vaultwarden-1.23.1 && /usr/b...)
> *** Error 2 in . (/usr/ports/infrastructure/mk/bsd.port.mk:2944
> '/usr/ports/pobj/vaultwarden-1.23.1/build-amd64/.build_done': @cd
> /usr/ports...)
> *** Error 2 in /usr/ports/security/vaultwarden
> (/usr/ports/infrastructure/mk/bsd.port.mk:2594 'build':
> @lock=vaultwarden-1.23.1; export _LO...)
>
Module devel/cargo tries to provide some magic to help porting rust
programs. But git dependencies are hard to copte with.
Regarding vaultwarden, you need to get the following git repositories:
- https://github.com/SergioBenitez/Devise
- https://github.com/SergioBenitez/Rocket
- https://github.com/jjlin/job_scheduler
which expand to the following crates:
- devise
- devise_codegen
- devise_core
- rocket
- rocket_codegen
- rocket_contrib
- rocket_http
- job_scheduler
The fact that a repository could expand to more than one crate makes the
download process to not be doable simply inside devel/cargo port.
For now, such port should be ported using the "old" method which is to
vendor all dependencies in one tarball, and put it somewhere on the
internet.
cargo has the right command to do it for you:
$ cd vaultwarden-1.23.1
$ cargo vendor myvendordir
Vendoring addr2line v0.17.0
(/home/semarie/.cargo/registry/src/github.com-1ecc6299db9ec823/addr2line-0.17.0)
to myvendordir/addr2line
Vendoring adler v1.0.2
(/home/semarie/.cargo/registry/src/github.com-1ecc6299db9ec823/adler-1.0.2) to
myvendordir/adler
...
Vendoring yansi v0.5.0
(/home/semarie/.cargo/registry/src/github.com-1ecc6299db9ec823/yansi-0.5.0) to
myvendordir/yansi
Vendoring yubico v0.10.0
(/home/semarie/.cargo/registry/src/github.com-1ecc6299db9ec823/yubico-0.10.0)
to myvendordir/yubico
To use vendored sources, add this to your .cargo/config.toml for this project:
[source.crates-io]
replace-with = "vendored-sources"
[source."https://github.com/SergioBenitez/Devise.git;]
git = "https://github.com/SergioBenitez/Devise.git;
rev = "e58b3ac9a"
replace-with = "vendored-sources"
[source."https://github.com/SergioBenitez/Rocket;]
git = "https://github.com/SergioBenitez/Rocket;
rev = "263e39b5b429de1913ce7e3036575a7b4d88b6d7"
replace-with = "vendored-sources"
[source."https://github.com/jjlin/job_scheduler;]
git = "https://github.com/jjlin/job_scheduler;
rev = "ee023418dbba2bfe1e30a5fd7d937f9e33739806"
replace-with = "vendored-sources"
[source.vendored-sources]
directory = "myvendordir"
Next, create a tarball for myvendordir directory, and add a configure
step to create the .cargo/config.toml file (it could be a file copied
from security/vaultwarden/files/ to ${WRKDIR}/.cargo).
The hard part should be done.
Thanks.
--
Sebastien Marie
Re: FYI - On the subject of non-OpenBSD developers asking "ok?"
On Mon, Jan 24, 2022 at 01:39:50PM +0100, Dima Pasechnik wrote: > On Fri, Jan 21, 2022 at 11:42:08AM -0600, joshua stein wrote: > > On Fri, 21 Jan 2022 at 18:29:27 +0100, Marc Espie wrote: > > > In my opinion, our main issue is the lack of new blood. > > > > > > We have chronically fewer people who can give okays than ports waiting. > > > > > > One big "meta" stuff that needs doing is pointing out (especially from > > > new guys) what can be improved in the documentation of the porting > > > process... > > > sometimes pointing people in the right direction. > > > > > > Informal poll: what thing weirded you guys out the first time you touched > > > OpenBSD ports coming from other platforms. > > > > > > What kind of gotcha can we get rid of, so that "new ports" will tend to > > > be squeaky clean, infrastructure-wise, and ready for import. > > > > > > Maybe we'd need an FAQ from people coming from elsewhere explaining the > > > main differences to (say) deb, rpm, freebsd ?... > > > > Using CVS and dealing with tarballs is probably pretty > > ancient-feeling for many outsiders. I don't know that more > > documentation is really the problem. > > > > I personally tend to ignore most ports@ emails that aren't diffs I > > can easily view in my e-mail client because it's a hassle to save > > the attachment, tar -t it to see what its directory structure is, > > untar it in the proper place, try to build it, then provide feedback > > by copying parts of the Makefile to an e-mail or doing some other > > work to produce a diff. > > > > Maybe we can do something radical like enable GitHub pull requests > > to let people submit changes against the ports repo on GitHub, do > > review and feedback on those on GitHub, and once it's been approved > > by a developer, that developer can do the final legwork of > > committing it to CVS and closing the pull request (since we can't > > commit directly to the Git repo). > > > I read this, and the whole following thread, and noone mentioned CI > (continuous integration) > - something that made GitHub much more useful than merely a git server > hosting service. > > In a CI-enabled world, one could usually see the results of applying a diff, > and > building+testing, it's there, done for you, automatically. > Indeed, using GitHub's CI with OpenBSD is tricky (if possible at all), but > fortunately We got a framework for bulk-building ports: dpb(1) That's the whole integration we get... the full ports tree is generally rebuilt every few days (or weeks) or supported architectures. Good luck getting a proper infrastructure off the ground, especially on lesser known architectures. We do frown on cross-compilation for various reasons.
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: es...@cvs.openbsd.org 2022/01/24 05:44:08 Modified files: databases/ports-readmes-dancer: Makefile distinfo Log message: fix urls regexps, as noticed by afresh1@
Re: FYI - On the subject of non-OpenBSD developers asking "ok?"
On Fri, Jan 21, 2022 at 11:42:08AM -0600, joshua stein wrote: > On Fri, 21 Jan 2022 at 18:29:27 +0100, Marc Espie wrote: > > In my opinion, our main issue is the lack of new blood. > > > > We have chronically fewer people who can give okays than ports waiting. > > > > One big "meta" stuff that needs doing is pointing out (especially from > > new guys) what can be improved in the documentation of the porting > > process... > > sometimes pointing people in the right direction. > > > > Informal poll: what thing weirded you guys out the first time you touched > > OpenBSD ports coming from other platforms. > > > > What kind of gotcha can we get rid of, so that "new ports" will tend to > > be squeaky clean, infrastructure-wise, and ready for import. > > > > Maybe we'd need an FAQ from people coming from elsewhere explaining the > > main differences to (say) deb, rpm, freebsd ?... > > Using CVS and dealing with tarballs is probably pretty > ancient-feeling for many outsiders. I don't know that more > documentation is really the problem. > > I personally tend to ignore most ports@ emails that aren't diffs I > can easily view in my e-mail client because it's a hassle to save > the attachment, tar -t it to see what its directory structure is, > untar it in the proper place, try to build it, then provide feedback > by copying parts of the Makefile to an e-mail or doing some other > work to produce a diff. > > Maybe we can do something radical like enable GitHub pull requests > to let people submit changes against the ports repo on GitHub, do > review and feedback on those on GitHub, and once it's been approved > by a developer, that developer can do the final legwork of > committing it to CVS and closing the pull request (since we can't > commit directly to the Git repo). I read this, and the whole following thread, and noone mentioned CI (continuous integration) - something that made GitHub much more useful than merely a git server hosting service. In a CI-enabled world, one could usually see the results of applying a diff, and building+testing, it's there, done for you, automatically. Indeed, using GitHub's CI with OpenBSD is tricky (if possible at all), but fortunately there are other similar free services, such as one by Sourcehut: https://man.sr.ht/builds.sr.ht/compatibility.md#openbsd Second point: I'd agree that GitHub is far from an ideal solution here, but the underlying tool, git, is certainly way more powerful than CVS. Hey, I used CVS a bit in 1999, and fogot all about it. Yes, CVS can be helped with extra tooling, but this kind of tooling is made largely obsolete by git. (The theme CVS vs Subversion vs git has certainly been explored in all the details on the net, I don't want to repeat it here.) Switching to git would certainly be very welcoming for newcomers. HTH Dima users.ox.ac.uk/~coml0531/ > > I believe that the GitHub repo can be configured to also email > ports@openbsd.org on any submissions/comments there, so the mailing > list would still be in the loop on everything for anyone that > doesn't want to use GitHub. >
llvm 13 memcpy optimiser breaks lang/node
The proposed update to lang/node makes this irrelevant, but I thought I'd send
it anyway since it may come up elsewhere too.
I noticed that on one system, 'npm install less' would abort, logging
'node: backwards memcpy', but on another it worked fine. Eventually I
figured out this was because the working one had packages built with llvm 11,
the other with llvm 13 packages, and llvm 13's memcpy optimiser was turning
a series of small memcpys in node's bundled zlib into one larger one, without
identifying that the src and dest of the larger memcpy could overlap.
Compiling the bundled zlib with -fno-builtin-memcpy prevents it from doing
that, which fixes npm.
This should only affect the zlib bundled in node and chromium (and possibly
elsewhere?). The version in node and chromium has a supposedly optimised
inner loop using memcpy, while other versions use simpler byte copy loops,
which get turned into inline unrolled loops rather than memcpy calls.
The proposed update to node 16.13.2 also switches to using the system zlib,
so we probably don't need the diff below.
Index: Makefile
===
RCS file: /cvs/ports/lang/node/Makefile,v
retrieving revision 1.93
diff -u -p -u -p -r1.93 Makefile
--- Makefile2 Nov 2021 00:01:17 - 1.93
+++ Makefile24 Jan 2022 10:17:02 -
@@ -19,7 +19,7 @@ DISTFILES = node-pledge-{}${PLEDGE_VER}
DISTNAME = node-${NODE_VERSION}
PKGNAME = ${DISTNAME:S/v//g}
-REVISION = 0
+REVISION = 1
MASTER_SITES0 =https://github.com/qbit/node-pledge/archive/
Index: patches/patch-deps_zlib_zlib_gyp
===
RCS file: /cvs/ports/lang/node/patches/patch-deps_zlib_zlib_gyp,v
retrieving revision 1.2
diff -u -p -u -p -r1.2 patch-deps_zlib_zlib_gyp
--- patches/patch-deps_zlib_zlib_gyp6 Sep 2021 13:49:44 - 1.2
+++ patches/patch-deps_zlib_zlib_gyp24 Jan 2022 10:17:02 -
@@ -4,19 +4,24 @@ node has a patch to add SIMD etc optimiz
disable on i386, it breaks build. it uses cpuid to detect features so
_should_ work on amd64.
+clang 13 does not safely optimise the memcpy calls in the optimized
+zlib code, resulting in backwards memcpys and node processes aborting,
+so disable memcpy optimization for now.
+
Index: deps/zlib/zlib.gyp
--- deps/zlib/zlib.gyp.orig
+++ deps/zlib/zlib.gyp
-@@ -64,7 +64,7 @@
+@@ -64,7 +64,8 @@
'USE_FILE32API'
],
}],
-['(target_arch in "ia32 x64 x32" and OS!="ios") or
arm_fpu=="neon"', {
+['(target_arch in "x64" and OS!="ios") or arm_fpu=="neon"', {
++ 'cflags': [ '-fno-builtin-memcpy' ],
'sources': [
'adler32_simd.c',
'adler32_simd.h',
-@@ -77,7 +77,7 @@
+@@ -77,7 +78,7 @@
'sources': [ 'inflate.c', ],
}],
# Incorporate optimizations where possible
sysutils/ssh-copy-id: use EXTRACT_FILES, do not strip
No need to extract all of ssh.
Fix
strip:
/usr/ports/pobj/ssh-copy-id-8.8pl1/fake-amd64/usr/local/bin/INS@Ja1VJB5n7N:
File format not recognized
in `make fake' while here.
OK?
Index: Makefile
===
RCS file: /cvs/ports/sysutils/ssh-copy-id/Makefile,v
retrieving revision 1.1.1.1
diff -u -p -r1.1.1.1 Makefile
--- Makefile6 Feb 2020 14:10:05 - 1.1.1.1
+++ Makefile24 Jan 2022 11:21:00 -
@@ -6,6 +6,8 @@ DISTNAME= openssh-${V}
PKGNAME=ssh-copy-id-${V:S/p/pl/}
CATEGORIES= sysutils
+EXTRACT_FILES= ${DISTNAME}/contrib/ssh-copy-id{,.1}
+
HOMEPAGE= http://git.hands.com/ssh-copy-id
MAINTAINER= Jan-Piet Mens
@@ -19,8 +21,7 @@ NO_TEST= Yes
PKG_ARCH= *
do-install:
- ${INSTALL_PROGRAM} ${WRKSRC}/contrib/ssh-copy-id ${PREFIX}/bin
- ${INSTALL_MAN_DIR} ${PREFIX}/man/man1
- ${INSTALL_MAN} ${WRKSRC}/contrib/ssh-copy-id.1 ${PREFIX}/man/man1
+ ${INSTALL_SCRIPT} ${WRKSRC}/contrib/ssh-copy-id ${PREFIX}/bin/
+ ${INSTALL_MAN} ${WRKSRC}/contrib/ssh-copy-id.1 ${PREFIX}/man/man1/
.include
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: o...@cvs.openbsd.org2022/01/24 04:21:28 Modified files: sysutils/cmdseq: Makefile Log message: fix broken RCS marker in makefile reminded by Laurie, thanks! no bump needed.
Re: [NEW] sysutils/alertmanager v0.23.0
Le Mon, Jan 24, 2022 at 09:29:54AM +, Stuart Henderson a écrit : > On 2022/01/22 17:52, Denis Fondras wrote: > > The Alertmanager handles alerts sent by client applications such > > as the Prometheus server. It takes care of deduplicating, grouping, > > and routing them to the correct receiver integration such as email, > > PagerDuty, or OpsGenie. It also takes care of silencing and inhibition > > of alerts. > > > > https://prometheus.io/ > > > > OK ? > > please zap . at end of COMMENT. > > I haven't tested runtime but does it really need to share a uid with > Prometheus? It does not. As they are from the same developper, I thought I can reuse it. But I see node_exporter and snmp_exporter use their own users. Here is an updated .tgz + user.list diff (using 873, because 872 will eventually be _vmetrics). Index: user.list === RCS file: /cvs/ports/infrastructure/db/user.list,v retrieving revision 1.392 diff -u -p -r1.392 user.list --- user.list 17 Nov 2021 20:32:34 - 1.392 +++ user.list 24 Jan 2022 10:25:51 - @@ -380,3 +380,4 @@ id usergroup port 869 _headscale _headscale net/headscale 870 _unit _unit www/unit 871 _gelatod _gelatodnet/gelatod +873 _alertmanager _alertmanager sysutils/alertmanager alertmanager-0.23.0.tgz Description: application/tar-gz
Re: ports-readmes-dancer and the "g++" subpackage don't get along
On Sun, Jan 23, 2022 at 07:32:16PM -0800, Andrew Hewus Fresh wrote: > I noticed this and while I hoped to find time to include a patch I > haven't yet and so I decided to report without. > > It appears that "g++" or maybe subdirectories confuse the > ports-readmes-dancer at openports.pl. > > For example, clicking either of the g++-11.2.0p0 or g++-8.4.0p9 links > from https://openports.pl/cat/lang 404: > > https://openports.pl/path/lang/gcc/11,-c++ > https://openports.pl/path/lang/gcc/8,-c++ > > I tried escaping the ++ with %2b%2b but it doesn't seem as simple as > those getting interpreted as spaces. I haven't looked past that. Ah, I found the issue... as usual it is deeply stupid ;)
Re: ports-readmes-dancer and the "g++" subpackage don't get along
On Sun, Jan 23, 2022 at 07:32:16PM -0800, Andrew Hewus Fresh wrote: > I noticed this and while I hoped to find time to include a patch I > haven't yet and so I decided to report without. > > It appears that "g++" or maybe subdirectories confuse the > ports-readmes-dancer at openports.pl. > > For example, clicking either of the g++-11.2.0p0 or g++-8.4.0p9 links > from https://openports.pl/cat/lang 404: > > https://openports.pl/path/lang/gcc/11,-c++ > https://openports.pl/path/lang/gcc/8,-c++ > > I tried escaping the ++ with %2b%2b but it doesn't seem as simple as > those getting interpreted as spaces. I haven't looked past that. > That's a bit surprising, since the Template engine has everything properly annotated for urls.
Re: [new] database/VictoriaMetrics v1.72.0
Le Mon, Jan 24, 2022 at 12:59:30AM +, Stuart Henderson a écrit :
> Why not just 'daemon_flags="-storageDataPath=${LOCALSTATEDIR}/db/vmetrics/"'?
>
You are right, I thought it would concatenate the "vmetrics_flags" from
rc.conf.local.
Thank you Stuart.
victoriametrics-v1.72.0.tgz
Description: application/tar-gz
Re: [NEW] sysutils/alertmanager v0.23.0
On 2022/01/22 17:52, Denis Fondras wrote: > The Alertmanager handles alerts sent by client applications such > as the Prometheus server. It takes care of deduplicating, grouping, > and routing them to the correct receiver integration such as email, > PagerDuty, or OpsGenie. It also takes care of silencing and inhibition > of alerts. > > https://prometheus.io/ > > OK ? please zap . at end of COMMENT. I haven't tested runtime but does it really need to share a uid with Prometheus?
Re: Fwd: [SECURITY] [UPDATE] lang/node to 16.13.2
On 2022/01/23 17:47, Aaron Bieber wrote: > > Volker Schlecht writes: > > > Bump... > > > > On 1/16/22 16:48, Volker Schlecht wrote: > >> Update after feedback from abieber@ > > I was able to build webstuffs for the latest navidrome without > issue. pldc complains about: > > Bogus WANTLIB: crypto.11 (/usr/local/bin/node) (NOT REACHABLE) > Bogus WANTLIB: ssl.11 (/usr/local/bin/node) (NOT REACHABLE) > > but I am not sure that that's accurate. check-lib-depends doesn't handle libraries in directories other than /usr/local/lib, I think the old version will have the same. > + return "/usr/local/bin/node"; > > ^ did we relax the LOCALBASE stuff? I assume portcheck would have your guess is as good as mine on that :) > complained about this if not. best not to assume too much about portcheck, it is not particularly smart. > Assuming the above are fine, OK abieber@. (I didn't do a node-bulk or > further testing beyond navidrome) >
Re: update: sysutils/ssh-copy-id
On 2022/01/24 09:20, Jan-Piet Mens wrote: > Hello! > > This is an update to ssh-copy-id, a script to copy one's SSH keys to remote > hosts, ensuring that ~/.ssh and authorized_keys are created with correct > permissions. Thanks, committed.
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: st...@cvs.openbsd.org 2022/01/24 02:19:39 Modified files: sysutils/ssh-copy-id: Makefile distinfo Log message: update to ssh-copy-id-8.8pl1, from Jan-Piet Mens
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: lan...@cvs.openbsd.org 2022/01/24 02:00:23 Modified files: sysutils/loki : Makefile distinfo sysutils/loki/patches: patch-cmd_loki_loki-local-config_yaml Log message: sysutils/loki: update to 2.4.2. see https://github.com/grafana/loki/releases/tag/v2.4.0, https://github.com/grafana/loki/releases/tag/v2.4.1, https://github.com/grafana/loki/releases/tag/v2.4.2 and https://github.com/grafana/loki/blob/main/docs/sources/upgrading/_index.md#240 from Clement Martin, thanks !
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: mar...@cvs.openbsd.org 2022/01/24 01:54:10 Modified files: math/py-cftime : Makefile distinfo Log message: Update py-cftime to 1.5.2.
update: sysutils/ssh-copy-id
Hello!
This is an update to ssh-copy-id, a script to copy one's SSH keys to remote
hosts, ensuring that ~/.ssh and authorized_keys are created with correct
permissions.
Regards,
-JP
diff --git a/sysutils/ssh-copy-id/Makefile b/sysutils/ssh-copy-id/Makefile
index a18dcadef51..3699cbf70e2 100644
--- a/sysutils/ssh-copy-id/Makefile
+++ b/sysutils/ssh-copy-id/Makefile
@@ -1,7 +1,7 @@
# $OpenBSD: Makefile,v 1.1.1.1 2020/02/06 14:10:05 kmos Exp $
COMMENT=script to copy one's SSH keys to remote hosts
-V= 8.1p1
+V= 8.8p1
DISTNAME= openssh-${V}
PKGNAME=ssh-copy-id-${V:S/p/pl/}
CATEGORIES= sysutils
diff --git a/sysutils/ssh-copy-id/distinfo b/sysutils/ssh-copy-id/distinfo
index 582eea0d833..31a6b55d99b 100644
--- a/sysutils/ssh-copy-id/distinfo
+++ b/sysutils/ssh-copy-id/distinfo
@@ -1,2 +1,2 @@
-SHA256 (openssh-8.1p1.tar.gz) = AvXb7zg10HU1VvlzzVe0wZtrH2zSTANEXiOsd8obk/8=
-SIZE (openssh-8.1p1.tar.gz) = 1625894
+SHA256 (openssh-8.8p1.tar.gz) = RZCJDqm7ms5Pca4zF4WjpYIyMkNRYZYO1fyGWI8zH+k=
+SIZE (openssh-8.8p1.tar.gz) = 1815060
sparc64 bulk build report
Bulk build on sparc64-0a.ports.openbsd.org Started : Fri Jan 21 01:37:14 MST 2022 Finished: Mon Jan 24 01:05:39 MST 2022 Duration: 2 Days 23 hours 28 minutes Built using OpenBSD 7.0-current (GENERIC.MP) #1159: Thu Jan 20 14:37:10 MST 2022 Built 9458 packages Number of packages built each day: Jan 21: 7926 Jan 22: 712 Jan 23: 819 Jan 24: 1 Critical path missing pkgs: http://build-failures.rhaalovely.net/sparc64/2022-01-21/summary.log Build failures: 43 http://build-failures.rhaalovely.net/sparc64/2022-01-21/archivers/fuse-zip.log http://build-failures.rhaalovely.net/sparc64/2022-01-21/cad/dxf2gcode.log http://build-failures.rhaalovely.net/sparc64/2022-01-21/databases/recoll.log http://build-failures.rhaalovely.net/sparc64/2022-01-21/databases/xapian-bindings,-main.log http://build-failures.rhaalovely.net/sparc64/2022-01-21/devel/avr/gcc.log http://build-failures.rhaalovely.net/sparc64/2022-01-21/devel/cbmc.log http://build-failures.rhaalovely.net/sparc64/2022-01-21/devel/ruby-nio4r,ruby27.log http://build-failures.rhaalovely.net/sparc64/2022-01-21/devel/xtensa-esp32-elf/binutils.log http://build-failures.rhaalovely.net/sparc64/2022-01-21/devel/xtensa-lx106-elf/binutils.log http://build-failures.rhaalovely.net/sparc64/2022-01-21/editors/calligra.log http://build-failures.rhaalovely.net/sparc64/2022-01-21/editors/scintilla.log http://build-failures.rhaalovely.net/sparc64/2022-01-21/emulators/openmsx.log http://build-failures.rhaalovely.net/sparc64/2022-01-21/games/egoboo.log http://build-failures.rhaalovely.net/sparc64/2022-01-21/games/frotz.log http://build-failures.rhaalovely.net/sparc64/2022-01-21/games/irrlamb.log http://build-failures.rhaalovely.net/sparc64/2022-01-21/games/stepmania.log http://build-failures.rhaalovely.net/sparc64/2022-01-21/games/vkquake.log http://build-failures.rhaalovely.net/sparc64/2022-01-21/games/witchblast.log http://build-failures.rhaalovely.net/sparc64/2022-01-21/graphics/birdfont.log http://build-failures.rhaalovely.net/sparc64/2022-01-21/graphics/libgphoto2.log http://build-failures.rhaalovely.net/sparc64/2022-01-21/graphics/makehuman.log http://build-failures.rhaalovely.net/sparc64/2022-01-21/lang/clazy.log http://build-failures.rhaalovely.net/sparc64/2022-01-21/math/coq.log http://build-failures.rhaalovely.net/sparc64/2022-01-21/multimedia/mkvtoolnix.log http://build-failures.rhaalovely.net/sparc64/2022-01-21/net/bro.log http://build-failures.rhaalovely.net/sparc64/2022-01-21/net/ntopng.log http://build-failures.rhaalovely.net/sparc64/2022-01-21/net/pmacct,mysql.log http://build-failures.rhaalovely.net/sparc64/2022-01-21/net/zabbix,sqlite3,-proxy.log http://build-failures.rhaalovely.net/sparc64/2022-01-21/news/nzbget.log http://build-failures.rhaalovely.net/sparc64/2022-01-21/productivity/gnucash.log http://build-failures.rhaalovely.net/sparc64/2022-01-21/security/arirang.log http://build-failures.rhaalovely.net/sparc64/2022-01-21/security/encfs.log http://build-failures.rhaalovely.net/sparc64/2022-01-21/security/veracrypt.log http://build-failures.rhaalovely.net/sparc64/2022-01-21/sysutils/libvirt.log http://build-failures.rhaalovely.net/sparc64/2022-01-21/textproc/docbook-utils.log http://build-failures.rhaalovely.net/sparc64/2022-01-21/textproc/link-grammar,-main.log http://build-failures.rhaalovely.net/sparc64/2022-01-21/www/nextcloud_notify_push.log http://build-failures.rhaalovely.net/sparc64/2022-01-21/www/unit/unit-php,php74.log http://build-failures.rhaalovely.net/sparc64/2022-01-21/www/unit/unit-ruby.log http://build-failures.rhaalovely.net/sparc64/2022-01-21/x11/gnome/gjs.log http://build-failures.rhaalovely.net/sparc64/2022-01-21/x11/kde-applications/kmix.log http://build-failures.rhaalovely.net/sparc64/2022-01-21/x11/kde-applications/libgravatar.log http://build-failures.rhaalovely.net/sparc64/2022-01-21/x11/zutty.log Recurrent failures: failures/archivers/fuse-zip.log failures/cad/dxf2gcode.log failures/databases/recoll.log failures/devel/avr/gcc.log failures/devel/cbmc.log failures/devel/xtensa-esp32-elf/binutils.log failures/devel/xtensa-lx106-elf/binutils.log failures/editors/scintilla.log failures/emulators/openmsx.log failures/games/egoboo.log failures/games/frotz.log failures/games/irrlamb.log failures/games/stepmania.log failures/games/vkquake.log failures/games/witchblast.log failures/graphics/birdfont.log failures/graphics/makehuman.log failures/lang/clazy.log failures/math/coq.log failures/multimedia/mkvtoolnix.log failures/net/bro.log failures/productivity/gnucash.log failures/security/arirang.log failures/security/encfs.log failures/security/veracrypt.log failures/textproc/docbook-utils.log failures/www/nextcloud_notify_push.log failures/www/unit/unit-php,php74.log failures/www/unit/unit-ruby.log failures/x11/gnome/gjs.log failures/x11/kde-applications/kmix.log failures/x11/zutty.log New failures: +failures/databases/xapian-bindings,-main.log +failures/devel/ruby-nio4r,ruby27.log
