Re: [security update]databases/p5-DBI: Update to 1.644
On Sun, Aug 25, 2024 at 02:46:32AM +, wen heping wrote: > Hi, > >Here is a patch for databases/p5-DBI to update to 1.644. >Upstream changelog say "Fix CVE-2014-10401 and CVE-2014-10402". >It build well and pass the test on amd64-current system. > > > Best Regards, > wen I was a bit surprised to see such old CVEs only fixed now, then I looked them all, they're very specific, and if you're not using f_dir in incorrect ways, you're fine. They mostly fix broken config with f_dir. (of course this needs to be fixed anyhow)
Re: Haskell ports without using Hackage
On Sat, Aug 17, 2024 at 07:03:48AM +0200, David Uhden Collado wrote: > Hello, > > I have recently started working on a port for the SimpleX Chat CLI client > [1] and encountered an issue. The software is not available in the Haskell > package repository [2], which poses a significant challenge since the > cabal-module(5) used for Haskell ports relies on Hackage. > > My question is: Is there a way to create a port for software written in > Haskell that is not available in the Haskell package repository? > > Thank you for your assistance. > > Best regards, > David. > > 1. > https://github.com/simplex-chat/simplex-chat/blob/stable/docs/CLI.md#in-any-os > 2. https://hackage.haskell.org/packages/search?terms=simplex-chat > 3. https://man.openbsd.org/cabal-module.5 > > This mostly means you have to do things manually, like a lot of ports do. Don't use the cabal module, just BUILD_DEPENDS on ghc, and set variables according to what you need.
Re: roadmap for more privsep in pkgland
On Fri, Aug 16, 2024 at 11:16:51AM +0100, Stuart Henderson wrote: > On 2024/08/15 18:33, Marc Espie wrote: > > Enter @extraglob > > > > > > basically: stuff like @extraglob /var/tomcat/conf/ > > will remove the tomcat dir with everything inside it > > > > or stuff like > > @extraglob /var/db/gconf/gconf.xml.defaults/ > > It would be really nice to have a way to do this / @extra without > triggering "you should also remove X" during (some?) package updates. > > I stopped using @extra and friends in most of my ports becausesometimes > people (understandably) believe that they should follow those messages > and end up removing important files. Easy to add keywords, actually. I got "always" to have extra and extraglob actually remove the files/directories in every case. Just as easily, I can add a "silent" keyword that would suppress the logged message ;)
Re: roadmap for more privsep in pkgland
Here's the basic pkg_add change, very lightly tested for now.
Not that many lines, considering :)
Index: pkg_create.1
===
RCS file: /build/data/openbsd/cvs/src/usr.sbin/pkg_add/pkg_create.1,v
diff -u -p -r1.131 pkg_create.1
--- pkg_create.15 Jul 2023 01:21:51 - 1.131
+++ pkg_create.116 Aug 2024 10:13:43 -
@@ -434,13 +434,19 @@ If
does not begin with an @, same as
.Dl name/
.Pp
-.It Cm @define-tag Ar tag mode params
+.It Cm @define-tag Oo owner Ns = Ns Ar o Oc Oo group Ns = Ns Ar g Oc Ar tag
mode params
Define a tag of name
.Ar tag .
Tags define actions to be performed at specific time during
.Xr pkg_add 1
and
-.Xr pkg_delete 1 .
+.Xr pkg_delete 1 ,
+after changing identity to owner
+.Ar o
+and/or
+group
+.Ar g
+if specified.
A given tag may be defined several times with additional properties.
Currently, the following modes are defined:
.Bl -tag -width abc -compact
@@ -498,11 +504,15 @@ only rebuilds the local texmf directory
so if both tags are seen, only the global command will be run.
.El
.Pp
-.It Cm @exec Ar command
+.It Cm @exec Oo owner Ns = Ns Ar o Oc Oo group Ns = Ns Ar g Oc Ar command
Execute
.Ar command
during
-.Xr pkg_add 1 .
+.Xr pkg_add 1 ,
+after optionally changing identity to user
+.Ar o
+and/or group
+.Ar g .
Note that
.Cm @exec
commands are executed relative to their location in the packing-list,
@@ -562,36 +572,51 @@ in the example case,
.Pa emacs .
.El
.Pp
-.It Cm @exec-always Ar command
+.It Cm @exec-always Oo owner Ns = Ns Ar o Oc Oo group Ns = Ns Ar g Oc Ar
command
Synonym of
.Cm @exec .
.Pp
-.It Cm @exec-add Ar command
+.It Cm @exec-add Oo owner Ns = Ns Ar o Oc Oo group Ns = Ns Ar g Oc Ar command
Similar to
.Cm @exec ,
except it only gets executed during new installations,
and not during updates.
.Pp
-.It Cm @exec-update Ar command
+.It Cm @exec-update Oo owner Ns = Ns Ar o Oc Oo group Ns = Ns Ar g Oc Ar
command
Similar to
.Cm @exec ,
except it only gets executed during updates,
and not during new installations.
.Pp
-.It Cm @extra Ar filename
+.It Cm @extra Oo owner Ns = Ns Ar o Oc Oo group Ns = Ns Ar g Oc Oo always Oc
Ar filename
Declare extra file
.Ar filename
to be deleted at deinstall time, if user sets the
.Fl c
-option.
+option or if the optional parameter
+.Ar always
+is used.
Those files are extra configuration files that are normally not deleted.
+Allows file ownership to be declared as well.
.Ar filename
can be an absolute path.
If
.Ar filename
ends with a slash, it is a directory.
.Pp
-.It Cm @extraunexec Ar command
+.It Cm @extraglob Oo owner Ns = Ns Ar o Oc Oo group Ns = Ns Ar g Oc Oo always
Oc Ar glob
+Declare extra files matching the shell globbing pattern
+.Ar glob
+to be deleted at deinstall time, if user sets the
+.Fl c
+option or if the optional parameter
+.Ar always
+is used.
+Allows file ownership to be declared as well.
+If
+.Ar glob
+ends with a slash, it is a directory, which will be wiped recursively.
+.It Cm @extraunexec Oo owner Ns = Ns Ar o Oc Oo group Ns = Ns Ar g Oc Ar
command
Extra
.Ar command
to execute when removing extra files.
@@ -862,7 +887,7 @@ Describe the file as a
.Ox
static library.
.Pp
-.It Cm @unexec Ar command
+.It Cm @unexec Oo owner Ns = Ns Ar o Oc Oo group Ns = Ns Ar g Oc Ar command
Execute
.Ar command
during
@@ -892,17 +917,17 @@ definition must be accessible through th
is amenable to the same substitutions as
.Cm @exec .
.Pp
-.It Cm @unexec-always Ar command
+.It Cm @unexec-always Oo owner Ns = Ns Ar o Oc Oo group Ns = Ns Ar g Oc Ar
command
Synonym of
.Cm @unexec .
.Pp
-.It Cm @unexec-delete Ar command
+.It Cm @unexec-delete Oo owner Ns = Ns Ar o Oc Oo group Ns = Ns Ar g Oc Ar
command
Similar to
.Cm @unexec ,
except it only gets executed during true deletions
and not while removing an old package during updates.
.Pp
-.It Cm @unexec-update Ar command
+.It Cm @unexec-update Oo owner Ns = Ns Ar o Oc Oo group Ns = Ns Ar g Oc Ar
command
Similar to
.Cm @unexec ,
except it only gets executed while removing an old package during updates,
Index: OpenBSD/Add.pm
===
RCS file: /build/data/openbsd/cvs/src/usr.sbin/pkg_add/OpenBSD/Add.pm,v
diff -u -p -r1.196 Add.pm
--- OpenBSD/Add.pm 11 Oct 2023 13:54:43 - 1.196
+++ OpenBSD/Add.pm 16 Aug 2024 10:04:50 -
@@ -257,8 +257,6 @@ sub tag_user_packages(@p)
package OpenBSD::PackingElement;
use OpenBSD::Error;
-# used by newuser/newgroup to deal with options.
-my ($uidcache, $gidcache);
# $self->prepare_for_addition($state, $pkgname, $set)
sub prepare_for_addition($, $, $, $)
@@ -297,19 +295,7 @@ sub copy_info($, $, $)
sub set_modes($self, $state, $name)
{
if (defined $self->{owner} || defined $self->{group}) {
- require OpenBSD::IdCache;
-
- if (!defined $uidcache) {
- $uidcache = Ope
roadmap for more privsep in pkgland
(original idea courtesy of bentley@) Okay, so we should probably be running @tags as an under-privileged user. There's a chicken-and-egg issue, namely, that the tag-generated files usually belong to root. They ARE the ugly duckling, and they've been a plague, since forever (for pkg_check, and for semarie's work: they are the files that are unaccounted for). Enter: @extraglob it's an annotation I added ages ago to handle these. Simply put: we got ~200 @exec/@unexec left in the ports tree a lot of these (most of the @unexec) are removing those files that got generated somehow. The idea was always to NOT use @unexec, but have a higher level primitive to remove them. Enter @extraglob basically: stuff like @extraglob /var/tomcat/conf/ will remove the tomcat dir with everything inside it or stuff like @extraglob /var/db/gconf/gconf.xml.defaults/ Enter ownership --- The idea is to be able to annotate @extraglob, @tag, @exec*, @unexec* with owner=... group=... annotations (optional and prepended) For any keyword that runs anything, that keyword would be run as the user/group indicated (note that by this point, all @owner/@group annotations have been handled, so the users do exist) AND for @extraglob stuff, the ownership would have been adjusted so say you have a tag that generates @extraglob somefile.tag with those annotations, on installation/update, the tag is given the right ownership, and when @tag * at-end triggers, the command is run with the right owner -> correct privsep. Plan for deployment: - @extraglob is already recognized and won't cause any issue - pkg_add changes first, so that rm -> extraglob can happen later in packages - extraglob in packages... if the tools are not there yet, you may end with remnant files on your installation after deleting stuff - ownership for remaining tags/exec/unexec/extraglobs - assessing the few @exec/@unexec that remain. I've been scolded by various people for not discussing my plans in enough details. I hope this is enough for you. If not, PLEASE FUCKING ASK QUESTIONS!!!
bsd.port.mk.5 tweak
Realized that DWZ is not documented, at all.
Also, mandoc -Wall found some shenannigans in USE_LLD.
Please commit that.
Index: bsd.port.mk.5
===
RCS file: /build/data/openbsd/cvs/src/share/man/man5/bsd.port.mk.5,v
diff -u -p -r1.644 bsd.port.mk.5
--- bsd.port.mk.5 11 Nov 2023 10:46:37 - 1.644
+++ bsd.port.mk.5 15 Aug 2024 09:08:19 -
@@ -1843,6 +1843,20 @@ package and
to perform introspection and obtain
.Nm Ns 's
default values for variables without needing to access any specific port.
+.It Ev DWZ
+Command line invocation of
+.Xr dwz 1
+to shrink debug information while building debug packages.
+Defaults to
+.Sq dwz -L 1
+Can be set to
+.Sq \&:
+to not run
+.Xr dwz 1
+at all.
+See
+.Sx THE DEBUG_PACKAGES INFRASTRUCTURE
+for details.
.It Ev ECHO_MSG
User settings.
Used to display
@@ -3671,10 +3685,9 @@ bfd's
.Xr ld 1
.Pc .
.Sq ports
-force the use of
+forces the use of
.Xr ld.lld 1
from lang/clang module.
-.Pc
Defaults to the appropriate value for the current architecture
.Po
see
@@ -3961,7 +3974,7 @@ target ,
.Xr build-debug-info 1
will be invoked to deduce debug packing-lists from the normal packing-lists,
and some extra makefile rules will be invoked to set aside the debug
-information.
+information, and shrink it by processing it through ${DWZ}.
.Pp
Then each normal package will have a "shadow" debug-* package built alongside
it, with the exact same package signature, except it will also be tied closely
changes to signal handling with respect to ksh ?
I've got several scripts that use mpv to display pictures. It used to be that I could ^Z and fg on those scripts without any issues. For a few weeks/months now, it seems to be broken. I have zero idea if this is an issue with mpv, ksh, or signal handling. I think mpv gets into another process group for whatever reason ? It still gets suspended, but TCONT doesn't do a thing. Rings a bell ?
Re: Add BULK_COOKIES_DIR to proot(1)
On Sat, Aug 03, 2024 at 11:53:28AM +0200, Denis Bodor wrote:
> Hi,
>
> I ran into a permission problem when using proot(1). The ${PORTSDIR}/bulk
> directory cannot be created when you decide to place the other directories
> outside the ports tree.
>
> Here's my configuration:
>
> $ cat proot.cfg
> chroot=/prootports2
> PORT_USER=denis
> extra=/etc/doas.conf
> /etc/installurl
> WRKOBJDIR=/bportbuild/pobj
> PLIST_REPOSITORY=/bportbuild/plist
> DISTDIR=/bportbuild/distfiles
> PACKAGE_REPOSITORY=/bportbuild/packages
> LOGDIR=/bportbuild/logs
> actions=unpopulate_light
> copy_ports
> mkconf_tail=proot_mkadd.cfg
>
> $ cat proot_mkadd.cfg
> PARALLEL_MAKE_JOBS=yes
> MAKE_JOBS=10
> #BULK=No
>
> If the BULK line is commented out as here, "BULK=Auto" is used and the
> permission problem is encountered:
>
> $ doas /usr/ports/infrastructure/bin/proot -c proot.cfg
> $ doas chroot -u denis /prootports2
>
> $ cd /usr/port/sysutils/flashrom
> $ make fake
> [...]
> ===> Building package for dwz-0.15
> Create /bportbuild/packages/amd64/all/dwz-0.15.tgz
> Creating package dwz-0.15
> Creating package debug-dwz-0.15
> Link to /bportbuild/packages/amd64/ftp/dwz-0.15.tgz
> Link to /bportbuild/packages/amd64/ftp/debug-dwz-0.15.tgz
> mkdir: /usr/ports/bulk: Permission denied
>
> Of course, with "BULK=No", everything works straight away.
>
> I've modified proot(1) to include BULK_COOKIES_DIR in the configuration
> file in the same way as DISTDIR, WRKOBJDIR, PLIST_REPOSITORY, and so on.
>
> A patch for proot(1) is attached here. Not sure this is the right approach.
>
> --
> Denis
> Index: infrastructure/bin/proot
> ===
> RCS file: /cvs/ports/infrastructure/bin/proot,v
> diff -u -p -u -r1.74 proot
> --- infrastructure/bin/proot 6 May 2023 05:21:15 - 1.74
> +++ infrastructure/bin/proot 3 Aug 2024 09:05:53 -
> @@ -151,12 +151,16 @@ sub do_parm($state, $k, $v)
> $state->{PACKAGE_REPOSITORY} = File::Spec->canonpath($v);
> }, PLIST_REPOSITORY => sub() {
> $state->{PLIST_REPOSITORY} = File::Spec->canonpath($v);
> + }, BULK_COOKIES_DIR => sub() {
> + $state->{BULK_COOKIES_DIR} = File::Spec->canonpath($v);
> }, NFSDIR => sub() {
> $state->{DISTDIR} = File::Spec->canonpath("$v/distfiles");
> $state->{PACKAGE_REPOSITORY} =
> File::Spec->canonpath("$v/packages");
> $state->{PLIST_REPOSITORY} =
> File::Spec->canonpath("$v/plist");
> + $state->{BULK_COOKIES_DIR} =
> + File::Spec->canonpath("$v/bulk");
> }, LOCALDIR => sub() {
> $state->{WRKOBJDIR} = File::Spec->canonpath("$v/pobj");
> $state->{LOCKDIR} = File::Spec->canonpath("$v/locks");
> @@ -325,7 +329,7 @@ sub handle_options($state)
> if ($< != 0) {
> $state->fatal("Must be root");
> }
> - for my $i (qw(PORTSDIR DISTDIR WRKOBJDIR PACKAGE_REPOSITORY
> PLIST_REPOSITORY LOCKDIR LOGDIR FETCH_USER BUILD_USER)) {
> + for my $i (qw(PORTSDIR DISTDIR WRKOBJDIR PACKAGE_REPOSITORY
> PLIST_REPOSITORY BULK_COOKIES_DIR LOCKDIR LOGDIR FETCH_USER BUILD_USER)) {
> if (defined $state->{$i}) {
> $state->{write}{$i} = 1;
> }
> @@ -340,8 +344,9 @@ sub handle_options($state)
> $state->{loguser} //= $state->{builduser};
> $state->{PACKAGE_REPOSITORY} //= join('/', $state->{PORTSDIR},
> 'packages');
> $state->{PLIST_REPOSITORY} //= join('/', $state->{PORTSDIR}, 'plist');
> + $state->{BULK_COOKIES_DIR} //= join('/', $state->{PORTSDIR}, 'bulk');
> $state->{sysdir} //= '/usr/src/sys';
> - for my $dir (qw(DISTDIR WRKOBJDIR LOGDIR PACKAGE_REPOSITORY
> PLIST_REPOSITORY LOCKDIR)) {
> + for my $dir (qw(DISTDIR WRKOBJDIR LOGDIR PACKAGE_REPOSITORY
> PLIST_REPOSITORY BULK_COOKIES_DIR LOCKDIR)) {
> $state->{$dir} = $state->canonical_dir($state->{$dir});
> $state->add_preserved($state->{$dir});
> }
> @@ -357,7 +362,7 @@ sub handle_options($state)
> }
> for my $i (qw(chroot srcroot
> PORTSDIR DISTDIR WRKOBJDIR LOCKDIR LOGDIR
> - PACKAGE_REPOSITORY PLIST_REPOSITORY)) {
> + PACKAGE_REPOSITORY PLIST_REPOSITORY BULK_COOKIES_DIR)) {
> if (defined $state->{$i}) {
> $state->say("#1=#2", $i, $state->{$i});
> }
> @@ -689,6 +694,9 @@ sub best_user($state, $path)
> if (m/^\Q$state->{PLIST_REPOSITORY}\E/) {
> return $state->{builduser};
> }
> + if (m/^\Q$state->{BULK_COOKIES_DIR}\E/) {
> + return $state->{builduser};
> + }
> if (m/^\Q$state->{PACKAGE_REPOSITORY}\E/) {
> return $state->{builduser};
> }
> @@ -1062,6 +1070,7 @@ sub make_ports_subdirs($state)
>
Re: new (wip-ish): sysutils/plocate
On Fri, Aug 02, 2024 at 06:14:47PM +0100, Stuart Henderson wrote:
> Biggest yucky bit with the port if used as a "standard" locate tool is
> that the code to check filesystem types is Linux-only and I haven't
> added an OpenBSD implementation, so you can't easily disable (e.g.)
> "all NFS partitions", you've got to specify paths to skip.
I've looked at the FreeBSD port, puked in my mouth a bit
(I assume they already got that horrible compat code from somewhere else)
and wrote a quickie using statfs
Should work.
New port attached. I also took the liberty of silencing
some crazy warning from modern clang.
(no idea if it's possible to do that directly on the
meson command line)
Index: updatedb.cpp
--- updatedb.cpp.orig
+++ updatedb.cpp
@@ -43,7 +43,12 @@ any later version.
#include
#include
#include
+#ifdef __OpenBSD__
+#include
+#include
+#else
#include
+#endif
#include
#include
#include
@@ -58,6 +63,8 @@ any later version.
#include
#include
+char *program_invocation_name;
+
using namespace std;
using namespace std::chrono;
@@ -164,6 +171,20 @@ bool filesystem_is_excluded(const string &path)
if (conf_debug_pruning) {
fprintf(stderr, "Checking whether filesystem `%s' is
excluded:\n", path.c_str());
}
+#ifdef __OpenBSD__
+ struct statfs buf;
+ if (statfs(path.c_str(), &buf) == -1)
+ perror("statfs failed");
+ string type(buf.f_fstypename);
+ for (char &p : type) {
+ p = toupper(p);
+ }
+ bool exclude = (find(conf_prunefs.begin(), conf_prunefs.end(), type) !=
conf_prunefs.end());
+ if (exclude && conf_debug_pruning) {
+ fprintf(stderr, " => excluded due to filesystem type\n");
+ }
+ return exclude;
+#else
FILE *f = setmntent("/proc/mounts", "r");
if (f == nullptr) {
return false;
@@ -192,6 +213,7 @@ bool filesystem_is_excluded(const string &path)
fprintf(stderr, "...not found in mount list\n");
}
endmntent(f);
+#endif
return false;
}
@@ -780,6 +802,7 @@ int main(int argc, char **argv)
rlim.rlim_cur = std::min(wanted, rlim.rlim_max);
setrlimit(RLIMIT_NOFILE, &rlim); // Ignore errors.
}
+ program_invocation_name = argv[0];
conf_prepare(argc, argv);
if (conf_prune_bind_mounts) {
plocate.tgz
Description: application/tar-gz
Re: db/config.site cache for ac_cv_header_netinet_tcp_var_h
On Mon, Jul 29, 2024 at 04:54:34PM +0100, Stuart Henderson wrote:
> db/config.site has this:
>
> 1.6 (espie24-Feb-05):
> ac_cv_header_netinet_tcp_timer_h=${ac_cv_header_netinet_tcp_timer_h=yes}
>
> turns out this is a bit problematic, because on OpenBSD you need to
> pull in tcp_timer.h before you can use tcp_var.h ("use of undeclared
> identifier 'TCPT_NTIMERS'").
>
> I wonder if we should remove this - at least one port (net/scamper)
> has a patch to disable use of tcp_var.h because of this. (This was
> figured out by scamper's developer who was wondering why I needed
> to patch it).
>
Removing one line is not a big issue, especially if it breaks something
The whole premise behind ac_cache is broken, specifically because of
those crazy dependencies.
(oh and I would feel so much more implicated and entitled to say okay if
you guys grouped up and got my account back)
infrastructure patch: validate ONLY_FOR_ARCHS/NOT_FOR_ARCHS
Currently, there is nothing that prevents ONLY_FOR_ARCHS/NOT_FOR_ARCHS
from holding garbage.
The following patch adds a check, and promptly fixes an issue, namely
that ALL_ARCHES should also reference powerpc.
Index: arch-defines.mk
===
RCS file: /build/data/openbsd/cvs/ports/infrastructure/mk/arch-defines.mk,v
diff -u -p -r1.107 arch-defines.mk
--- arch-defines.mk 25 Jun 2024 13:48:24 - 1.107
+++ arch-defines.mk 26 Jul 2024 10:34:49 -
@@ -12,7 +12,7 @@
ARCH ?!= uname -m
ALL_ARCHS = aarch64 alpha amd64 arm arm64 armv7 hppa i386 landisk loongson \
- luna88k m88k macppc mips64 mips64el octeon powerpc64 riscv64 sgi \
+ luna88k m88k macppc mips64 mips64el octeon powerpc powerpc64 riscv64
sgi \
sh sparc64
# normally only list MACHINE_ARCH (uname -p) names in these variables,
# but not all powerpc have apm(4), hence the use of macppc
Index: bsd.port.arch.mk
===
RCS file: /build/data/openbsd/cvs/ports/infrastructure/mk/bsd.port.arch.mk,v
diff -u -p -r1.14 bsd.port.arch.mk
--- bsd.port.arch.mk16 Apr 2020 19:33:29 - 1.14
+++ bsd.port.arch.mk26 Jul 2024 10:35:24 -
@@ -53,6 +53,11 @@ FLAVOR := ${FLAVOR:N$f}
# build the actual list of subpackages we want
BUILD_PACKAGES =
+# compute pattern for identifying bad variables
+.for A in ${ALL_ARCHS}
+_arch_check := ${_arch_check}:N${A}
+.endfor
+
.for _s in ${MULTI_PACKAGES}
# ONLY_FOR_ARCHS/NOT_FOR_ARCHS are special:
@@ -72,8 +77,13 @@ IGNORE${_s} += "Ignored as FLAVOR contai
.endif
. endfor
-# compute _ARCH_OK for ignore
. if defined(ONLY_FOR_ARCHS${_s})
+# validate against full architecture list
+.for _m in ${_arch_check}
+. if !empty(ONLY_FOR_ARCHS${_m})
+ERRORS += "Fatal: unrecognized architecture ${ONLY_FOR_ARCHS${_m}} in
ONLY_FOR_ARCHS${_s}"
+. endif
+.endfor
.for A B in ${MACHINE_ARCH} ${ARCH}
. if empty(ONLY_FOR_ARCHS${_s}:M$A) && empty(ONLY_FOR_ARCHS${_s}:M$B)
.if ${MACHINE_ARCH} == "${ARCH}"
@@ -85,6 +95,12 @@ IGNORE${_s} += "is only for ${ONLY_FOR_A
.endfor
. endif
. if defined(NOT_FOR_ARCHS${_s})
+# validate against full architecture list
+.for _m in ${_arch_check}
+. if !empty(NOT_FOR_ARCHS${_m})
+ERRORS += "Fatal: unrecognized architecture ${NOT_FOR_ARCHS${_m}} in
NOT_FOR_ARCHS${_s}"
+. endif
+.endfor
.for A B in ${MACHINE_ARCH} ${ARCH}
. if !empty(NOT_FOR_ARCHS${_s}:M$A) || !empty(NOT_FOR_ARCHS${_s}:M$B)
IGNORE${_s} += "is not for ${NOT_FOR_ARCHS${_s}}"
Re: 回复: shall we create new port lang/cython3 ?
mlpack is something of a bitch. Some of the tests don't pass all the time because there are some "random algorithms" in there. If it doesn't break a thing consistently, it's good to go. (think about talking to t and getting my account back eventually, I will care more about those thankless painful thingies)
Re: pkg_info: fold Comment newline
On Sat, Mar 02, 2024 at 05:39:10PM +, Klemens Nanni wrote:
> As per Makefile.template and portcheck(1) COMMENT is <=60 chars, so it'd
> fit on the same Comment: line in pkg_info(1) output -- less scrolling!
>
> It just stands out, imho, compared to Maintainer: and WWW: where there's
> no such seemingly superfluous line break.
>
> Thoughts?
>
> Information for inst:quirks-7.11
>
> -Comment:
> -exceptions to pkg_add rules
> +Comment: exceptions to pkg_add rules
>
> Description:
> The quirks package allows unpredicted changes to the package system.
> For instance, package name changes, or stuff incorporated into base.
>
> pkg_add(1) always installs and updates it automatically.
>
> Maintainer: Marc Espie
>
> Index: OpenBSD/PkgInfo.pm
> ===
> RCS file: /cvs/src/usr.sbin/pkg_add/OpenBSD/PkgInfo.pm,v
> diff -u -p -r1.54 PkgInfo.pm
> --- OpenBSD/PkgInfo.pm25 Nov 2023 11:02:23 - 1.54
> +++ OpenBSD/PkgInfo.pm22 Feb 2024 14:16:18 -
> @@ -384,8 +384,7 @@ sub print_info($self, $state, $pkg, $han
> } else {
> if ($state->opt('c')) {
> $state->header($handle);
> - $state->banner("Comment:");
> - $state->say("#1\n", get_comment($handle->info));
> + $state->say("Comment: #1\n",
> get_comment($handle->info));
> }
> if ($state->opt('R') && -f $handle->info.REQUIRED_BY) {
> $state->header($handle);
>
Make sure nobody uses it.
Probably after the release
definitely okay
Re: retire some python 2 ports
On Wed, Feb 21, 2024 at 06:38:35PM +, Stuart Henderson wrote: > > - a few pygame games I happen to like and have been slowly porting to > > python3 > > btw fretsonfire (py2) doesn't seem to work at all. that's the only user > of py2 graphics/py-opengl and py2-Pillow. I don't think fretsonfire matter. I tried it once. It's so awful compared to actual guitarhero, I fail to see how anybody would actually play it. (on the other hand, stepmania is a decent clone of DDR, but it sorely needs a direct interface to sndio... pulseaudio delay is horrrible)
Re: retire some python 2 ports
On Sat, Feb 17, 2024 at 04:37:26PM -0500, Daniel Dickman wrote:
>
>
> On Sat, 17 Feb 2024, Matthieu Herrb wrote:
>
> > On Sat, Feb 17, 2024 at 11:51:05AM -0500, Daniel Dickman wrote:
> >
> > for cooledit, it's a python flavor. You could remove only the -python
> > flavor.
> >
> > Not that I would miss cooledit a lot. but I used to like (and use) it
> > some decades ago.
> > --
> > Matthieu Herrb
> >
>
> That works too. here's a diff for that. I was still able to launch
> cooledit.
>
>
> Index: Makefile
> ===
> RCS file: /cvs/ports/editors/cooledit/Makefile,v
> diff -u -p -u -r1.51 Makefile
> --- Makefile 21 Sep 2023 12:22:32 - 1.51
> +++ Makefile 17 Feb 2024 21:32:53 -
> @@ -1,7 +1,7 @@
> COMMENT =easy to use, graphical editor
>
> DISTNAME = cooledit-3.17.17
> -REVISION = 5
> +REVISION = 6
>
> CATEGORIES = editors
>
> @@ -11,22 +11,12 @@ SHARED_LIBS = Cw 1.0
>
> MAINTAINER = Marc Espie
>
> -FLAVORS =python
> -FLAVOR ?=
> -
> WANTLIB =X11 c iconv intl util xcb
>
> SITES = http://fossies.org/linux/misc/
>
> -.if ${FLAVOR:Mpython}
> -MODULES += lang/python
> -MODPY_VERSION = ${MODPY_DEFAULT_VERSION_2}
> -LIB_DEPENDS += ${MODPY_LIB_DEPENDS}
> -CONFIGURE_ENV += PYTHON_VER=${MODPY_VERSION} LOCALBASE=${LOCALBASE}
> -WANTLIB += pthread m ${MODPY_WANTLIB}
> -.else
> +# not compatible with Python 3
> CONFIGURE_ENV +=NOPYTHON=Yes
> -.endif
>
> BUILD_DEPENDS += devel/gettext,-tools
> LIB_DEPENDS += devel/gettext,-runtime
> Index: pkg/DESCR
> ===
> RCS file: /cvs/ports/editors/cooledit/pkg/DESCR,v
> diff -u -p -u -r1.5 DESCR
> --- pkg/DESCR 16 May 2005 20:26:51 - 1.5
> +++ pkg/DESCR 17 Feb 2024 21:32:53 -
> @@ -1,8 +1,5 @@
> Cooledit is a suite of programs consisting of the following:
> - cooledit - a GUI based editor which allows you to call external programs
> (for instance LaTeX on a LaTeX file)
> - - smalledit - a stripped down version of cooledit
> + - smalledit - a stripped down version of cooledit
> - coolman - a man page browser
> -
> -FLAVOR=python
> - turns it into a programmable editor, must have Python 2.
> Index: pkg/PLIST
> ===
> RCS file: /cvs/ports/editors/cooledit/pkg/PLIST,v
> diff -u -p -u -r1.9 PLIST
> --- pkg/PLIST 11 Mar 2022 18:58:28 - 1.9
> +++ pkg/PLIST 17 Feb 2024 21:32:53 -
> @@ -3,7 +3,7 @@ bin/cooledit-gdb
> @bin bin/coolman
> bin/coolproject
> @bin bin/smalledit
> -lib/libCw.a
> +@static-lib lib/libCw.a
> lib/libCw.la
> @lib lib/libCw.so.${LIBCw_VERSION}
> @man man/man1/cooledit.1
>
As far as I'm concerned, the only port where python2 support still matters
is gimp, until they release -stable with gtk+3 and the most important plugins
are ported (resynthesizer and friends)
Re: retire some python 2 ports
On Sat, Feb 17, 2024 at 04:37:26PM -0500, Daniel Dickman wrote:
>
>
> On Sat, 17 Feb 2024, Matthieu Herrb wrote:
>
> > On Sat, Feb 17, 2024 at 11:51:05AM -0500, Daniel Dickman wrote:
> >
> > for cooledit, it's a python flavor. You could remove only the -python
> > flavor.
> >
> > Not that I would miss cooledit a lot. but I used to like (and use) it
> > some decades ago.
> > --
> > Matthieu Herrb
> >
>
> That works too. here's a diff for that. I was still able to launch
> cooledit.
>
>
> Index: Makefile
> ===
> RCS file: /cvs/ports/editors/cooledit/Makefile,v
> diff -u -p -u -r1.51 Makefile
> --- Makefile 21 Sep 2023 12:22:32 - 1.51
> +++ Makefile 17 Feb 2024 21:32:53 -
> @@ -1,7 +1,7 @@
> COMMENT =easy to use, graphical editor
>
> DISTNAME = cooledit-3.17.17
> -REVISION = 5
> +REVISION = 6
>
> CATEGORIES = editors
>
> @@ -11,22 +11,12 @@ SHARED_LIBS = Cw 1.0
>
> MAINTAINER = Marc Espie
>
> -FLAVORS =python
> -FLAVOR ?=
> -
> WANTLIB =X11 c iconv intl util xcb
>
> SITES = http://fossies.org/linux/misc/
>
> -.if ${FLAVOR:Mpython}
> -MODULES += lang/python
> -MODPY_VERSION = ${MODPY_DEFAULT_VERSION_2}
> -LIB_DEPENDS += ${MODPY_LIB_DEPENDS}
> -CONFIGURE_ENV += PYTHON_VER=${MODPY_VERSION} LOCALBASE=${LOCALBASE}
> -WANTLIB += pthread m ${MODPY_WANTLIB}
> -.else
> +# not compatible with Python 3
> CONFIGURE_ENV +=NOPYTHON=Yes
> -.endif
>
> BUILD_DEPENDS += devel/gettext,-tools
> LIB_DEPENDS += devel/gettext,-runtime
> Index: pkg/DESCR
> ===
> RCS file: /cvs/ports/editors/cooledit/pkg/DESCR,v
> diff -u -p -u -r1.5 DESCR
> --- pkg/DESCR 16 May 2005 20:26:51 - 1.5
> +++ pkg/DESCR 17 Feb 2024 21:32:53 -
> @@ -1,8 +1,5 @@
> Cooledit is a suite of programs consisting of the following:
> - cooledit - a GUI based editor which allows you to call external programs
> (for instance LaTeX on a LaTeX file)
> - - smalledit - a stripped down version of cooledit
> + - smalledit - a stripped down version of cooledit
> - coolman - a man page browser
> -
> -FLAVOR=python
> - turns it into a programmable editor, must have Python 2.
> Index: pkg/PLIST
> ===
> RCS file: /cvs/ports/editors/cooledit/pkg/PLIST,v
> diff -u -p -u -r1.9 PLIST
> --- pkg/PLIST 11 Mar 2022 18:58:28 - 1.9
> +++ pkg/PLIST 17 Feb 2024 21:32:53 -
> @@ -3,7 +3,7 @@ bin/cooledit-gdb
> @bin bin/coolman
> bin/coolproject
> @bin bin/smalledit
> -lib/libCw.a
> +@static-lib lib/libCw.a
> lib/libCw.la
> @lib lib/libCw.so.${LIBCw_VERSION}
> @man man/man1/cooledit.1
>
Definitely not a problem.
Re: error on quirks
On Mon, Nov 20, 2023 at 01:56:54PM +0100, Manuel Giraud wrote: > Hi, > > For the first time, I have to touch devel/quirks after a port > modification. But when I try to update the patched devel/quirks from > port I get the following error: Follow-up: I finally committed all the pieces, so now the updatedb proper is in a separate package that requires a full snapshot, whereas quirks can be rebuilt 100% independently.
Re: use subdirs to group FNA ports to streamline updates
On Tue, Jan 09, 2024 at 09:51:09PM -0500, Thomas Frohwein wrote:
> Hi,
>
> The FNA project consists of 3 ports, currently in games/fna (.NET
> library), audio/faudio (audio backend), and graphics/fna3d (graphics
> backend). They have been separate because they were released at
> different times and because it wasn't clear if other non-FNA port
> projects would start to rely on faudio or fna3d.
>
> After a few years of experience, it's become clear that the 3 ports
> have strong ties for updates and no OpenBSD-relevant use with any other
> projects. Updates for all 3 ports are published with a strict monthly
> schedule and the same YY.MM version number. For this reason, it would be
> useful to restructure the ports so that they can be updated together.
>
> Attached is my proposal to do this by moving all 3 under games/fna
> (without any PKGNAME changes):
>
> audio/faudio -> games/fna/faudio
> games/fna -> games/fna/fna
> graphics/fna3d-> games/fna/fna3d
>
> This way, many updates for all 3 ports would be as simple as updating
> ${V} in Makefile.inc and regenerating distinfo with make makesum.
> Attached as tarball, as the directory changes don't lend themselves for
> a diff.
>
> ok? Or alternative suggestions?
Not okay.
All the PLIST need @pkgpath annotation for updates to work.
See the details of pkg_add -u as documented in pkg_add(1)
HEADS-UP: quirks + cache
I've committed code to dissociate quirks from the pkg update-cache. It is actually fairly transparent: it just handles quirks like other packages (it can have dependencies!) If you don't update, quirks may not install properly, along with the future updatedb. If you're running snapshots, hopefully this will trickle down on all architectures SOON (within a week or two). I do intend to commit the actual split in a week or so. Technically, this makes it much easier for people to test quirks changes WITHOUT having to rebuild a full ports tree and create the updatedb, since it's going to be a separate package (and quirks depends on it). Also technically: I added an @option updatedb to tag the actual package that contains the updatedb near the end of 2023. I've waited a few weeks before actually adding @option updatedb to quirks (this is current, right, so you're supposed to update). The actual split is going to be way more silent: if your base snapshot is not uptodate, all that's gonna happen is that you're going to lose quirks+updatedb for a few updates... It's not a big change, so I'm taking my time, but it's definitely helpful for developers who want to test things. Kudoes to the guy (sorry, didn't note down your name) who brought that specific issue to my attention. Very soon, your problem will be solved !
Re: lang/rust: roadmap for using SYSTEM_VERSION
On Sun, Dec 31, 2023 at 12:26:28PM +0100, Sebastien Marie wrote:
> Theo Buehler writes:
>
> > On Sat, Dec 30, 2023 at 07:32:18PM +0100, Sebastien Marie wrote:
> >
> > The outlined procedure makes sense to me and I like the approach, but I
> > am a bit worried that it makes it harder for people to write Rust ports
> > using the devel/cargo module, which is already tricky.
> >
> > Porters will now need to be able to grasp the separation of concerns to
> > understand the distinction between the devel/cargo and lang/rust
> > modules. They must now deal with two sets of variables: MODCARGO_* and
> > MODRUST_*. The latter only has two user-visible bits for now, so maybe
> > it's not that bad.
>
> initially, I tried to hide the "lang/rust" module under "devel/cargo"
> module (and have devel/cargo to sets MODULES+=lang/rust), but
> arch-defines.mk is included before MODULES processing, which means that
> the test ${MODULES:Mlang/rust} to check if lang/rust module is here or
> not isn't trigger as the module comes too late in the variable.
Wrong assumption. You assume you need to do a test in arch-defines.mk
but variables are lazy.
Just do
_MAYADD_RUST_VERSION ?=
_PKG_ARGS_VERSION += ${_MAYADD_RUST_VERSION}
in arch-defines.mk
and then, all you need to do is make sure that
_MAYADD_RUST_VERSION actually gets defined as
_MAYADD_RUST_VERSION = -V ${MODRUST_SYSTEM_VERSION}
in either the cargo or the rust module, whatever needs inclusion.
Re: DIST_TUPLE: another go at setting WRKDIST
On Thu, Dec 28, 2023 at 06:48:59PM -0500, Thomas Frohwein wrote:
> Hi,
>
> This is an attempt at fixing what didn't work with the first go at
> setting WRKDIST for DIST_TUPLE [1] (see [2]). Basically sets a new
> internal variable _DT_WRKDIST in dist-tuple.port.mk which is picked up
> in bsd.port.mk only if no GH_* or DISTNAME are set.
>
> I tested this with games/fheroes2 (straightforward DIST_TUPLE port) and
> archivers/snappy (mix of GH_* and DIST_TUPLE) without issues. Another
> set of eyes on this would be great; potentially also wider testing and
> checking if it helps with ports like tg_owt that have been waiting for
> a DIST_TUPLE handling of WRKDIST (see commit comment [3]).
>
> [1] https://marc.info/?l=openbsd-ports-cvs&m=169584616831183&w=2
> [2] https://marc.info/?l=openbsd-ports-cvs&m=169588080613965&w=2
> [3] https://marc.info/?l=openbsd-ports-cvs&m=169902481810921&w=2
>
> Index: bsd.port.mk
> ===
> RCS file: /cvs/ports/infrastructure/mk/bsd.port.mk,v
> retrieving revision 1.1636
> diff -u -p -r1.1636 bsd.port.mk
> --- bsd.port.mk 11 Nov 2023 11:53:38 - 1.1636
> +++ bsd.port.mk 28 Dec 2023 23:36:39 -
> @@ -894,10 +894,12 @@ _WRKDIRS += ${WRKOBJDIR_MFS}/${_WRKDIR_S
> WRKDIST ?= ${WRKDIR}/${GH_PROJECT}-${GH_TAGNAME:C/^[vV]([0-9])/\1/}
> .elif !empty(GH_COMMIT)
> WRKDIST ?= ${WRKDIR}/${GH_PROJECT}-${GH_COMMIT}
> -.elif !defined(DISTNAME)
> -WRKDIST ?= ${WRKDIR}
> -.else
> +.elif defined(DISTNAME)
> WRKDIST ?= ${WRKDIR}/${DISTNAME}
> +.elif !empty(_DT_WRKDIST)
> +WRKDIST ?= ${_DT_WRKDIST}
> +.else
> +WRKDIST ?= ${WRKDIR}
> .endif
>
> WRKSRC ?= ${WRKDIST}
> Index: dist-tuple.port.mk
> ===
> RCS file: /cvs/ports/infrastructure/mk/dist-tuple.port.mk,v
> retrieving revision 1.15
> diff -u -p -r1.15 dist-tuple.port.mk
> --- dist-tuple.port.mk6 Nov 2023 07:02:08 - 1.15
> +++ dist-tuple.port.mk28 Dec 2023 23:36:39 -
> @@ -29,9 +29,9 @@ _subdir =
> # set DISTNAME if not done by the port and add refs/tags/ subdir
> DISTNAME ?=
> ${_project}-${_id:C/^(v|V|ver|[Rr]el|[Rr]elease)[-._]?([0-9])/\2/}
> _subdir =refs/tags/
> -#WRKDIST ?=
> ${WRKDIR}/${_project}-${_id:C/^(v|V|ver|[Rr]el|[Rr]elease)[-._]?([0-9])/\2/}
> +_DT_WRKDIST ?=
> ${WRKDIR}/${_project}-${_id:C/^(v|V|ver|[Rr]el|[Rr]elease)[-._]?([0-9])/\2/}
> .else
> -#WRKDIST ?= ${WRKDIR}/${_project}-${_id}
> +_DT_WRKDIST ?= ${WRKDIR}/${_project}-${_id}
> .endif
>
> .for _subst in
> S,,${_account},g:S,,${_project},g:S,,${_id},g:S,,${_subdir},g:S,,${SITES.${_template}},g
>
This is the kind of patch that really requires a full bulk, unfortunately.
gtk+2 fix for file requesters
With glib-2.78, gimp has become more or less unusable in large directories.
The culprit is gtk+2 which is end of life.
I found a backport from gtk+3 that fixes the issue.
See comments in patches.
okay ?
Index: Makefile
===
RCS file: /cvs/ports/x11/gtk+2/Makefile,v
diff -u -p -r1.248 Makefile
--- Makefile24 Apr 2023 11:45:24 - 1.248
+++ Makefile6 Dec 2023 17:59:50 -
@@ -9,7 +9,7 @@ GNOME_PROJECT= gtk+
PKGNAME-main= gtk+2-${GNOME_VERSION}
PKGNAME-cups= gtk+2-cups-${GNOME_VERSION}
-REVISION-main= 5
+REVISION-main= 6
REVISION-cups= 4
CATEGORIES=x11 devel
Index: patches/patch-gtk_gtkfilechooserdefault_c
===
RCS file: patches/patch-gtk_gtkfilechooserdefault_c
diff -N patches/patch-gtk_gtkfilechooserdefault_c
--- /dev/null 1 Jan 1970 00:00:00 -
+++ patches/patch-gtk_gtkfilechooserdefault_c 6 Dec 2023 17:59:50 -
@@ -0,0 +1,20 @@
+See https://gitlab.gnome.org/GNOME/gimp/-/issues/9994
+and
https://gitlab.gnome.org/GNOME/gtk/-/commit/c1fa916e88de20fc61dc06d3ff9f26722effa0df#note_1852594
+Index: gtk/gtkfilechooserdefault.c
+--- gtk/gtkfilechooserdefault.c.orig
gtk/gtkfilechooserdefault.c
+@@ -6378,10 +6378,12 @@ show_and_select_files (GtkFileChooserDefault *impl,
+ if (!_gtk_file_system_model_iter_is_visible (fsmodel, &iter))
+ {
+ GFileInfo *info = _gtk_file_system_model_get_info (fsmodel, &iter);
++ gboolean has_is_hidden = g_file_info_has_attribute (info,
"standard::is-hidden");
++ gboolean has_is_backup = g_file_info_has_attribute (info,
"standard::is-backup");
+
+ if (!enabled_hidden &&
+- (g_file_info_get_is_hidden (info) ||
+- g_file_info_get_is_backup (info)))
++ ((has_is_hidden && g_file_info_get_is_hidden (info)) ||
++ (has_is_backup && g_file_info_get_is_backup (info
+ {
+ g_object_set (impl, "show-hidden", TRUE, NULL);
+ enabled_hidden = TRUE;
Index: patches/patch-gtk_gtkfilesystemmodel_c
===
RCS file: patches/patch-gtk_gtkfilesystemmodel_c
diff -N patches/patch-gtk_gtkfilesystemmodel_c
--- /dev/null 1 Jan 1970 00:00:00 -
+++ patches/patch-gtk_gtkfilesystemmodel_c 6 Dec 2023 17:59:50 -
@@ -0,0 +1,25 @@
+See https://gitlab.gnome.org/GNOME/gimp/-/issues/9994
+and
https://gitlab.gnome.org/GNOME/gtk/-/commit/c1fa916e88de20fc61dc06d3ff9f26722effa0df#note_1852594
+Index: gtk/gtkfilesystemmodel.c
+--- gtk/gtkfilesystemmodel.c.orig
gtk/gtkfilesystemmodel.c
+@@ -444,13 +444,18 @@ static gboolean
+ node_should_be_visible (GtkFileSystemModel *model, guint id, gboolean
filtered_out)
+ {
+ FileModelNode *node = get_node (model, id);
++ gboolean has_is_hidden, has_is_backup;
+ gboolean result;
+
+ if (node->info == NULL)
+ return FALSE;
++
++ has_is_hidden = g_file_info_has_attribute (node->info,
"standard::is-hidden");
++ has_is_backup = g_file_info_has_attribute (node->info,
"standard::is-backup");
+
+ if (!model->show_hidden &&
+- (g_file_info_get_is_hidden (node->info) || g_file_info_get_is_backup
(node->info)))
++ ((has_is_hidden && g_file_info_get_is_hidden (node->info)) ||
++ (has_is_backup && g_file_info_get_is_backup (node->info
+ return FALSE;
+
+ if (_gtk_file_info_consider_as_directory (node->info))
Index: patches/patch-gtk_gtkpathbar_c
===
RCS file: patches/patch-gtk_gtkpathbar_c
diff -N patches/patch-gtk_gtkpathbar_c
--- /dev/null 1 Jan 1970 00:00:00 -
+++ patches/patch-gtk_gtkpathbar_c 6 Dec 2023 17:59:50 -
@@ -0,0 +1,15 @@
+See https://gitlab.gnome.org/GNOME/gimp/-/issues/9994
+and
https://gitlab.gnome.org/GNOME/gtk/-/commit/c1fa916e88de20fc61dc06d3ff9f26722effa0df#note_1852594
+Index: gtk/gtkpathbar.c
+--- gtk/gtkpathbar.c.orig
gtk/gtkpathbar.c
+@@ -1659,7 +1659,8 @@ gtk_path_bar_get_info_callback (GCancellable *cancella
+ }
+
+ display_name = g_file_info_get_display_name (info);
+- is_hidden = g_file_info_get_is_hidden (info) || g_file_info_get_is_backup
(info);
++ is_hidden = g_file_info_get_attribute_boolean (info, "standard::is-hidden")
||
++ g_file_info_get_attribute_boolean (info, "standard::is-backup");
+
+ gtk_widget_push_composite_child ();
+ button_data = make_directory_button (file_info->path_bar, display_name,
HEADS-UP: ports current follows source current
I did some small changes to pkg_add to detect the "updatedb" (cache for package updates) in a way that's independent from quirks. Soon, quirks will gain an @option updatedb entry. If you have old pkg_add (e.g., you don't update to a snapshot of base before a package snapshot) this will break as a syntax error. Soon afterwards, you will lose caching entirely... Please update. (the idea is to move the updatedb to a separate package, so "being quirks" is not enough to identify the db, and it's cleaner to do it as a unique-option. I'm committing this in stages, so people who follow the rules should not be impacted at all... :-> )
Re: error on quirks
On Tue, Nov 21, 2023 at 09:27:52AM +0100, Manuel Giraud wrote: > Hi, > > I forgot to do a "make clean" into /usr/ports/devel/quirks after each > new package built. Finally, quirks build correctly with the following > update.list: It's probably going to get "fixed" before 7.5, namely I think I can have quirks be independent and RUN_DEPENDS on the updatedb. Of course there's this small issue of figuring out where the updatedb comes from, and hence what pkg repository to cache... working on it.
splitting up the updatedb
Since quirks is handled as an updateset, having a runtime dependency shouldn't be much of an issue. Here is a separate updatedb port, to be activated when quirks is bumped to 7.0. There is also a small change to do in pkg_add: knowing the set is quirks isn't 100% enough, we also need to tie to the handle with the actual db (which means that quirks could be local for testing and we would still get the cache to a distant location) updatedb-0.tgz Description: updatedb-0.tgz
Re: error on quirks
On Mon, Nov 20, 2023 at 03:16:29PM +, Stuart Henderson wrote: > On 2023/11/20 13:56, Manuel Giraud wrote: > > Hi, > > > > For the first time, I have to touch devel/quirks after a port > > modification. But when I try to update the patched devel/quirks from > > port I get the following error: > > > > $ cd /usr/ports/devel/quirks > > $ make package > > ===> Faking installation for quirks-6.197 > > /usr/ports/pobj/quirks-6.197/bin/install -d -m 755 > > /usr/ports/pobj/quirks-6.197/fake-amd64/usr/local/libdata/perl5/site_perl/OpenBSD/Quirks > > /usr/ports/pobj/quirks-6.197/bin/install -c -m 644 > > /usr/ports/devel/quirks/files/Quirks.pm > > /usr/ports/pobj/quirks-6.197/fake-amd64/usr/local/libdata/perl5/site_perl/OpenBSD/Quirks.pm > > /usr/libexec/locate.mklocatedb > >/usr/ports/pobj/quirks-6.197/fake-amd64/usr/local/share/update.db > > locate.code: bigram array too small to build db, index more files > > As part of the "quirks" package build, the update.db cache is built > which provides information used by pkg_add -u to speed up updates. > In a bulk build DPB takes care to build this at the end of the > run, so that it has information about all packages available. > > This is based on the packages in the local build dir (e.g. > /usr/ports/packages/$ARCH/all by default). > > To avoid the failure you need to build some other packages first > (it doesn't matter which. math/moo is a good quick-to-build simple > package if you need one). > > Also note that pkg_add -u will be slow after updating to a locally-built > quirks package, until you get back to using a quirks package generated > in a bulk build. Hum... maybe I should provide a kind of work-around for people who want to test local quirks, namely just repackage the already installed updatedb in case we don't have any packages built, as a kind of "weird pseudo-flavor".
Re: godlberg_emulator build fix
On Sat, Nov 18, 2023 at 09:11:41PM +0100, Theo Buehler wrote:
> I'm not sure this fix is correct (since I'm not entirely sure why C++17
> is needed, but maybe abseil/protobuf default to C++17 nowadays).
>
> If this works for you, feel free to commit, otherwise it might provide a
> starting point for a better fix.
>
> Index: Makefile
> ===
> RCS file: /cvs/ports/games/goldberg_emulator/Makefile,v
> diff -u -p -r1.7 Makefile
> --- Makefile 26 Sep 2023 09:41:36 - 1.7
> +++ Makefile 18 Nov 2023 01:40:21 -
> @@ -22,8 +22,9 @@ FIX_CRLF_FILES =sdk_includes/isteamuser
> sdk_includes/steamclientpublic.h \
> sdk_includes/steam_gameserver.h
>
> -# C++14
> +# C++17 (abseil)
> COMPILER = base-clang ports-gcc
> +CXXFLAGS += -std=c++17
>
> LIB_DEPENDS =devel/protobuf
> USE_GMAKE = Yes
> Index: patches/patch-Makefile
> ===
> RCS file: /cvs/ports/games/goldberg_emulator/patches/patch-Makefile,v
> diff -u -p -r1.4 patch-Makefile
> --- patches/patch-Makefile11 Mar 2022 19:04:30 - 1.4
> +++ patches/patch-Makefile18 Nov 2023 01:23:41 -
> @@ -14,7 +14,7 @@ Index: Makefile
> -CXX_FLAGS += -fPIC -std=c++14
> -LD_FLAGS += -shared -lprotobuf-lite -ldl -Wl,--no-undefined
> +CXX=c++
> -+CXX_FLAGS += ${CXXFLAGS} -fPIC -std=c++14 -I${LOCALBASE}/include
> ++CXX_FLAGS += ${CXXFLAGS} -fPIC -I${LOCALBASE}/include
> +LD_FLAGS += -shared -L${LOCALBASE}/lib -lprotobuf-lite
> LIBRARY_NAME=libsteam_api.so
> RM = rm -f
>
>
https://en.cppreference.com/w/cpp/utility/in_place
They're C++17, and obviously abseil defaults to that mode now.
Re: amd64: llvm 16 fallout (2023-11-14)
On Thu, Nov 16, 2023 at 04:54:47PM +0100, Christian Weisgerber wrote:
> games/goldberg_emulator C++ no member in namespace 'std'
The abseil absl::in_place_t were just drop-ins for the (at the time future)
std::in_place_t from C++ 17.
Generic "fix" would be as simple as
namespace absl {
using std::in_place_t;
}
(or s/absl/std/ everywhere)
Re: amd64: llvm 16 fallout (2023-11-14)
On Thu, Nov 16, 2023 at 08:28:52PM +0100, Christian Weisgerber wrote: > Here are the build failures from my amd64 bulk build started on > 2023-11-14, including the subsequent build fixes up to > security/web-eid-app. > > http://build-failures.rhaalovely.net/amd64/2023-11-14/ > > cad/prusaslicer C++ ambiguous function call That one is not an llvm16 issue, I already saw it before I switched.
Re: Add DIST_TUPLE to Makefile.template
Forget was actually obvious to me, and I liked the tribute to the grandfather of them all, sourceforge, but I won't argue over that.
Re: Add DIST_TUPLE to Makefile.template
On Mon, Nov 13, 2023 at 02:08:32PM +0100, Omar Polo wrote: > On 2023/11/13 13:49:03 +0100, Stefan Hagen > wrote: > > Hi, > > > > DIST_TUPLE did not yet make it into the Makefile.template. > > > > OK to add it under the GH_ parts? > > why not replacing GH_* completely with this in the template? There is > still stuff that explicitly depends on GH_*? (except go.port.mk) There are cases where the conversion from GH_* to DIST_TUPLE is non trivial for various reasons.
explaining UNLINKED and why it's useful
Up until now, we would have a few (roughly 100) ports in the tree which were not linked to the build. I've added a new mechanism that allows them to get "linked" for meta-info collection purpose. Basically, UNLINKED=tag will add an IGNORE entry to the port, so if you add its SUBDIR to the category Makefile, it will still be ignored in default builds. People who want to build the port manually will just have to set BUILD_UNLINKED=tag somewhere (like in /etc/mk.conf) to wave the IGNORE'd line. So, nothing changes as far a builds are concerned. HOWEVER, those ports will now show up in sqlports *AND* pkglocatedb. which means they need to be squeaky-clean with respect to that (in particular, no missing dependency). But on the plus side, they are visible in sqlports, so that sweeps of the tree for tweaking infrastructure will see them, show-reverse-deps will see them, and portroach will index them. What tag to use: most port will just have their name as a tag. If it's a set of related port (say wayland stuff), we'll use a common tag for them (say wayland). >From now on, if you import a new port, it should also be added to the category Makefile (so please verify that sqlports/pkglocatedb will be happy: full meta-information, existing dependencies, packing-list). If it's not to be in the default build, set UNLINKED. (Also note that UNLINKED will show up in sqlports, so this will help avoiding things falling through the cracks and staying in limbo for years... like libindicator/libappindicator, which were removed from the default build THREE YEARS AGO because "some stuff may pick them up"... No obvious progress on that since then!)
Re: failed install databases/pkglocatedb
On Thu, Nov 09, 2023 at 10:03:24AM +, Stuart Henderson wrote: > On 2023/11/09 09:08, wen heping wrote: > > Hi, ports@: > > > > I updated my portstree just now but failed install > > databases/pkglocatedb, > > maybe it is caused by: > > ... > > piewm-1.04p3:x11/piewm: > > pmenu-3.1.1:x11/pmenu: > > >> Broken dependency: x11/polkit-qt5 non existent > > podbrowser-0.12p12:x11/podbrowser: > > polybar-3.6.3p0:x11/polybar: > > pwm-20070720:x11/pwm: > > py-gtk2-2.24.0p13:x11/py-gtk2: > > ... > > > >Any suggestion to fix it ? > >Thanks at advance ! > > > > wen > > If your tree is already fully up to date, look for old files in any dir > in PORTSDIR_PATH. > > Normally, the default build of sqlports only looks in the ports tree proper (that's what the default strict flavor does, see -s)
framework to allow linking everything
Patch is rather small, introduces two new variables:
UNLINKED: keyword(s) why not linked, to add to the port
BUILD_UNLINKED: simple way to override, as a configuration variable
with this, you could for instance link the wayland ports, annotate
them with UNLINKED = wayland.
Then they *will* participate in meta information for sqlports and friends
but be marked as
IGNORE = Not built because wayland
When someone wants to batch test those ports, all they need to do is
set BUILD_UNLINKED += wayland
Index: bsd.port.mk
===
RCS file: /cvs/ports/infrastructure/mk/bsd.port.mk,v
diff -u -p -r1.1630 bsd.port.mk
--- bsd.port.mk 26 Oct 2023 19:26:56 - 1.1630
+++ bsd.port.mk 9 Nov 2023 09:43:08 -
@@ -70,6 +70,9 @@ _MAKEFILE_INC_DONE ?= Yes
ECHO_MSG ?=:
.endif
+UNLINKED ?=
+BUILD_UNLINKED ?=
+
# include guard so that other parts don't include this twice
_BSD_PORT_MK = Done
@@ -797,6 +800,17 @@ _NONDEFAULT_LD ?= No
.if ${_NONDEFAULT_LD:L} == "yes"
. if !exists(${_LD_PROGRAM})
IGNORE = "requires ${_LD_PROGRAM}"
+. endif
+.endif
+_f =
+.if !empty(UNLINKED)
+. for _e in ${BUILD_UNLINKED}
+.if !empty(UNLINKED:M${_e})
+_f = build
+.endif
+. endfor
+. if empty(_f)
+IGNORE += "Not built because ${UNLINKED}"
. endif
.endif
Re: add commented out wayland related ports to their categories makefiles
If it takes a lot of time before they get linked, I would prefer everything to be linked in somehow, so that at least sqlports gets the information, and they don't get passed up in sweeps to change basic ports elements. We just need to have them IGNOREd by bulk so they don't get built by default. I was thinking of explicit IGNORE lines, but it's probably better to have a variable that says "these are not yet to be built in bulks", with a keyword or something, so that they can be easily included without having to do lots of churn. I'll give you a bsd.port.mk proposition this week-end.
patch: allow shortened commits in dist-tuple
I don't think we need to go the full 40 chars.
It is highly unlikely people are going to use 10 hex chars
as a tag (and if they do, it's likely it's just a copy of the
commit hash)
10 seems like a good number. tb@ mentionned that 8 is too short
(we already ran into collision with 8).
So 10 ? or 12 ?
Opinions ?
Index: dist-tuple.port.mk
===
RCS file: /cvs/ports/infrastructure/mk/dist-tuple.port.mk,v
diff -u -p -r1.14 dist-tuple.port.mk
--- dist-tuple.port.mk 28 Sep 2023 06:02:43 - 1.14
+++ dist-tuple.port.mk 5 Nov 2023 19:06:56 -
@@ -25,7 +25,7 @@ ERRORS += "Fatal: invalid choice for DIS
.endif
_subdir =
-.if "${_id}" == "HASH" || "${_id:C/^[0-9a-f]{40}$/HASH/}" != "HASH"
+.if "${_id}" == "HASH" || "${_id:C/^[0-9a-f]{10,40}$/HASH/}" != "HASH"
# set DISTNAME if not done by the port and add refs/tags/ subdir
DISTNAME ?= ${_project}-${_id:C/^(v|V|ver|[Rr]el|[Rr]elease)[-._]?([0-9])/\2/}
_subdir = refs/tags/
Re: kde support for DIST_TUPLES
On Sat, Oct 21, 2023 at 06:32:04AM -0400, Thomas Frohwein wrote: > On Sat, Oct 21, 2023 at 12:06:04PM +0200, Rafael Sadowski wrote: > > Straightforwardly, this adds support for KDE so that it can be used in > > DIST_TUPLES. > > > > With help from Thomas successfully tested with: > > DIST_TUPLE = kde qt qt/qtbase ea7a183732c17005f08ca14fd70cdd305c90396d . > > > > OK? > > Is or can this be used as the SITES for more kde ports? I only see it > showing up in HOMEPAGE for e.g. graphics/kquickimageeditor It seems quite a few kde projects are hosted there, including major stuff like krita and digikam, so I'm okay with this, even if it's not majorly used yet.
patch: fix audacity mp3 export on startup
On first run, audacity will look for "libmp3lame.so.0" which doesn't
exist on OpenBSD, then prompting the user to find the library.
This is doubly absurd, because it doesn't match our naming
scheme, and also because we run depend on lame.
This patch appears to do the trick: we can load a library
without looking at the major number, especially when
it doesn't match what the program expects.
I assume the rest would help the file requester as well.
(note that in order to test, you need to move
~/.config/audacity out of the way)
Okay ?
Index: Makefile
===
RCS file: /cvs/ports/audio/audacity/Makefile,v
retrieving revision 1.92
diff -u -p -r1.92 Makefile
--- Makefile10 Sep 2023 21:12:43 - 1.92
+++ Makefile18 Oct 2023 13:52:34 -
@@ -6,7 +6,7 @@ GH_ACCOUNT= audacity
GH_PROJECT=audacity
GH_TAGNAME=Audacity-3.3.3
DISTNAME= ${GH_TAGNAME:L}
-REVISION= 0
+REVISION= 1
CATEGORIES=audio
Index: patches/patch-src_export_ExportMP3_cpp
===
RCS file: patches/patch-src_export_ExportMP3_cpp
diff -N patches/patch-src_export_ExportMP3_cpp
--- /dev/null 1 Jan 1970 00:00:00 -
+++ patches/patch-src_export_ExportMP3_cpp 18 Oct 2023 13:52:34 -
@@ -0,0 +1,19 @@
+Index: src/export/ExportMP3.cpp
+--- src/export/ExportMP3.cpp.orig
src/export/ExportMP3.cpp
+@@ -1582,13 +1582,13 @@ wxString MP3Exporter::GetLibraryPath()
+
+ wxString MP3Exporter::GetLibraryName()
+ {
+- return wxT("libmp3lame.so.0");
++ return wxT("libmp3lame.so");
+ }
+
+ FileNames::FileTypes MP3Exporter::GetLibraryTypes()
+ {
+return {
+- { XO("Only libmp3lame.so.0"), { wxT("libmp3lame.so.0") } },
++ { XO("Only libmp3lame.so"), { wxT("libmp3lame.so*") } },
+ { XO("Primary shared object files"), { wxT("so") }, true },
+ { XO("Extended libraries"), { wxT("so*") }, true },
+ FileNames::AllFiles
hidden dependency in gnustep/base
Currently testing
Index: Makefile
===
RCS file: /cvs/ports/x11/gnustep/base/Makefile,v
retrieving revision 1.89
diff -u -p -r1.89 Makefile
--- Makefile27 Sep 2023 20:37:07 - 1.89
+++ Makefile16 Oct 2023 23:22:12 -
@@ -46,7 +46,8 @@ CONFIGURE_STYLE=gnu
CONFIGURE_ENV= ac_cv_header_execinfo_h=false
CONFIGURE_ARGS += --enable-libdispatch \
--disable-procfs \
- --disable-procfs-psinfo
+ --disable-procfs-psinfo \
+ --disable-bfd
MAKE_FLAGS +=
libgnustep-base_INTERFACE_VERSION=${LIBgnustep-base_VERSION}
.include
because of a bulk error:
to be committed if it builds unless there are objections...
>>> Building on localhost under x11/gnustep/base
BDEPENDS =
[devel/libffi;x11/gnustep/make;converters/libiconv;textproc/libxslt;devel/gmp;x11/gnustep/libobjc2;security/gnutls;net/curl;textproc/icu4c;net/avahi,-libs;devel/gmake;devel/libdispatch]
DIST = [x11/gnustep/base:gnustep/gnustep-base-1.29.0.tar.gz]
FULLPKGNAME = gnustep-base-1.29.0p0
RDEPENDS =
[textproc/libxslt;converters/libiconv;x11/gnustep/make;devel/libffi;x11/gnustep/libobjc2;devel/gmp;textproc/icu4c;net/curl;security/gnutls;devel/libdispatch;net/avahi,-libs]
(Junk lock obtained for localhost at 1697475058.94)
>>> Running depends in x11/gnustep/base at 1697475058.96
last junk was in cad/tkgate
/usr/sbin/pkg_add -aI -Drepair avahi-libs-0.8p3 gnustep-libobjc2-1.8.1p6
gnustep-make-2.9.1 gnutls-3.8.1 libdispatch-5.5 libiconv-1.17
was: /usr/sbin/pkg_add -aI -Drepair avahi-libs-0.8p3 curl-8.4.0 gmake-4.4.1
gmp-6.3.0 gnustep-libobjc2-1.8.1p6 gnustep-make-2.9.1 gnutls-3.8.1
icu4c-73.2p0v0 libdispatch-5.5 libffi-3.4.4 libiconv-1.17 libxslt-1.1.38
/usr/sbin/pkg_add -aI -Drepair avahi-libs-0.8p3 gnustep-libobjc2-1.8.1p6
gnustep-make-2.9.1 gnutls-3.8.1 libdispatch-5.5 libiconv-1.17
>>> Running show-prepare-results in x11/gnustep/base at 1697475069.66
===> x11/gnustep/base
===> Building from scratch gnustep-base-1.29.0p0
===> gnustep-base-1.29.0p0 depends on: gnustep-make-* -> gnustep-make-2.9.1
===> gnustep-base-1.29.0p0 depends on: gmake-* -> gmake-4.4.1
===> gnustep-base-1.29.0p0 depends on: libiconv-* -> libiconv-1.17
===> gnustep-base-1.29.0p0 depends on: libdispatch-* -> libdispatch-5.5
===> gnustep-base-1.29.0p0 depends on: libffi-* -> libffi-3.4.4
===> gnustep-base-1.29.0p0 depends on: gmp-* -> gmp-6.3.0
===> gnustep-base-1.29.0p0 depends on: libxslt-* -> libxslt-1.1.38
===> gnustep-base-1.29.0p0 depends on: gnutls-* -> gnutls-3.8.1
===> gnustep-base-1.29.0p0 depends on: icu4c-* -> icu4c-73.2p0v0
===> gnustep-base-1.29.0p0 depends on: avahi-libs-* -> avahi-libs-0.8p3
===> gnustep-base-1.29.0p0 depends on: curl-* -> curl-8.4.0
===> gnustep-base-1.29.0p0 depends on: gnustep-libobjc2-* ->
gnustep-libobjc2-1.8.1p6
===> Verifying specs: avahi-client avahi-common c ffi gmp gnutls iberty iconv
icudata curl icui18n icuuc m objc2 pthread xml2 xslt z dispatch c++ c++abi
pthread
===> found avahi-client.0.2 avahi-common.0.2 c.97.1 ffi.2.0 gmp.11.1
gnutls.47.7 iberty.12.0 iconv.7.1 icudata.22.1 curl.26.23 icui18n.22.1
icuuc.22.1 m.10.1 objc2.1.1 pthread.27.1 xml2.19.0 xslt.4.1 z.7.0 dispatch.0.0
c++.9.0 c++abi.6.0
avahi-libs-0.8p3
curl-8.4.0
gmake-4.4.1
gmp-6.3.0
gnustep-libobjc2-1.8.1p6
gnustep-make-2.9.1
gnutls-3.8.1
icu4c-73.2p0v0
libdispatch-5.5
libffi-3.4.4
libiconv-1.17
libxslt-1.1.38
[...]
===> Compiler link: clang -> /usr/bin/clang
===> Compiler link: clang++ -> /usr/bin/clang++
===> Compiler link: cc -> /usr/bin/cc
===> Compiler link: c++ -> /usr/bin/c++
>>> Running configure in x11/gnustep/base at 1697475088.51
===> x11/gnustep/base
===> Generating configure for gnustep-base-1.29.0p0
===> Configuring for gnustep-base-1.29.0p0
Using /pobj/gnustep-base-1.29.0/config.site (generated)
configure: WARNING: unrecognized options: --disable-debug, --enable-strip,
--disable-silent-rules, --disable-gtk-doc
configure: loading site script /pobj/gnustep-base-1.29.0/config.site
checking build system type... x86_64-unknown-openbsd7.4
checking host system type... x86_64-unknown-openbsd7.4
checking target system type... x86_64-unknown-openbsd7.4
checking for GNUstep configuration file to use at runtime... /etc/GNUstep.conf
checking whether the GNUstep.conf file path can be set in the environment... yes
checking if we should import an existing configuration file now... yes
checking for default GNUstep configuration file to use... /etc/GNUstep.conf
trying to import "/etc/GNUstep.conf"
configure: If this fails, please run configure again with the
--disable-importing-config-file option or specifying an alternative file using
the --with-default-config= option
checking for GNUstep-base installation domain... LOCAL
checking if we are hardcoding any relative paths in gnustep-base... no
configure: We store the following filesystem layout
Re: new port: benchmarks/hpl
For now, that's definitely not the problem. There are so many other issues that actually need solving FIRST.
Re: codeberg support for DIST_TUPLES
On Fri, Oct 13, 2023 at 11:40:59AM +0200, Omar Polo wrote:
> Straightforwardly, this adds support for codeberg so that it can be
> used in DIST_TUPLES. Unfortunately, it breaks the alignment in
> SITES.* :/
>
> The first two ports that could use this that comes to mind are
> graphics/nsxiv and devel/leiningen that both moved to codeberg
> (althought they both have a github mirror still.)
>
> Thoughts/ok?
>
> Index: dist-tuple.pattern
> ===
> RCS file: /home/cvs/ports/infrastructure/db/dist-tuple.pattern,v
> retrieving revision 1.6
> diff -u -p -r1.6 dist-tuple.pattern
> --- dist-tuple.pattern27 Sep 2023 21:41:16 - 1.6
> +++ dist-tuple.pattern13 Oct 2023 09:35:57 -
> @@ -1,4 +1,5 @@
> # known SITES.x
> +SITES.codeberg ?= https://codeberg.org/
> SITES.github ?= https://github.com/
> SITES.gitlab ?= https://gitlab.com/
> SITES.srht ?=https://git.sr.ht/
> @@ -11,6 +12,9 @@ TEMPLATE_EXTRACT_SUFX ?=.tar.gz
> # -
> # -
> # - - used automatically if is in tag format
> +TEMPLATE_DISTFILES.codeberg ?= \
> +
> --{//archive/}${EXTRACT_SUFX.codeberg}
> +
> TEMPLATE_DISTFILES.github ?= \
>
> --{//archive/}${EXTRACT_SUFX.github}
>
>
>
Looks good to me. Just wait for thfr@'s reply as he may already have diffs
in progress wrt that
Re: new port: benchmarks/hpl
On Thu, Oct 12, 2023 at 10:01:00AM -0600, j...@bitminer.ca wrote: > > > > Not really sure how to test it. If I try running it with no HPL.dat > > file present I get a segfault: > > There is some detailed guidance at > > https://www.pugetsystems.com/labs/hpc/how-to-run-an-optimized-hpl-linpack-benchmark-on-amd-ryzen-threadripper-2990wx-32-core-performance-1291/ > > the gist of which is: you need a lot of care in selecting all the > relevant software that goes with it, such as Blas, OpenBLAS or the Intel > or AMD equivalent substitutes. Right now, we don't have anything besides blas. > Since a port would have no choices in any of these, esp since > there is no port of the AMD Blis library, I wonder at the utility > of this. > > I suggest this would provide an opening for critics that "OpenBSD is > slow and here is the proof." It's not a relevant complaint but > it is a source of noise. With this kind of mentality, we're never going anywhere. Benchmarks can be used to figure out where the bottlenecks are, possibly motivate people to port more stuff to make it go faster. It's also possible to do "fair" comparisons, run it with similar parameters and identical libraries to figure out what makes us slow (or fast). As far as this specific benchmark is concerned, upstream is positively ancient, poorly taken care of, and they clearly do not even care about fixing obvious bad patterns or providing a consistent tarball with correct documentation. Hence the initial patches, and more to come.
new port: benchmarks/hpl
A colleague is having fun measuring the performance of various BSDs with this benchmark. As usual with such software, the build instructions are atrocious. The code is also a bit shabby, with potential for buffer overflows. When contacted about this, upstream clearly doesn't care about the quality of their code. Hence the various patches to avoid building error strings without any error checks... Its only saving graces is that this is well known as a benchmark in the High Performance Computing community, and that apparently, one of its original author was a recipient for the Turing award recently. DESCR: HPL is a software package that solves a (random) dense linear system in double precision (64 bits) arithmetic on distributed-memory computers. It can thus be regarded as a portable as well as freely available implementation of the High Performance Computing Linpack Benchmark. Okay to import ? hpl-2.3.tgz Description: hpl-2.3.tgz
Re: Something's up with pkg-config and dcmtk (Re: [maintainer update] pandoc 3.1.8)
Fight or flight. There is a point where you still need to enforce some basic semantics and refuse files that don't conform. I would question leading white space in .pc files even though pkgconf would be happy with them.
OS version in packages
Every release, it's the same dance: a few packages want version bumps because the OS version changed. This means a bit of work for naddy, and noise for most of us: I tend to have a bulk in-progress while this is going on, so my plist get bumped, and then later I get to the new version, and I get a bunch of trivial errors thanks to plist changes for packages that already got bumped (gratuitously) for me. But basically, this is useless: due to the way we do releases, OS version doesn't mean ANYTHING with respect to those pieces of software. I propose that, after 7.4, we get rid of those pesky version numbers that are useless for us. We did that in base for perl (did we do it for base gcc as well, I don't remember) and that infestation of locusts that was promised still hasn't come. I don't think software like octave or xemacs deserve special treatement. Do they ?
HEADS-UP: distfiles have been cleansed
If you work on -current, please make sure you have the current infrastructure and to read bsd.port.mk(5) and friends. Specifically: MASTER_SITES0..9 is dead prefer DISTFILES.sufx to refer to SITES.sufx Also: MASTER_SITES* is dead. We decided to replace it with the much shorter (with no loss of meaning) SITES* The tree has been entirely converted, and the compatibility glue has been removed: new stuff must use the new mechanisms.
Re: new bootstrap for lang/ghc
On Tue, Sep 26, 2023 at 10:29:57PM +0200, Matthias Kilian wrote: > Hi, > > Greg asked me to provide a new ghc boostrap. Here it is; i could built > lang/ghc and all ports depending on it with it. > > If it's ok to put it in before release, could someone else please > commit it? My internet connection is currently almost completely > broken. > > Ciao, > Kili Just noticed this bootstrap thingy by accident (grep is a good thing) and fixed the MASTER_SITES0 to the new style. Could we NOT do things this way ? not sure if we have another bootstrap Makefile for another language in the tree, but I'd rather there be marked as IGNORE = reason and hooked up to the tree. Building is easy, just need to set NO_IGNORE on the command line.
Re: games/godot: use a (pseudo?) flavor to handle mono
I said it privately, and I will say it publically so that people do not get the wrong idea. THIS IS NOT A PSEUDO_FLAVOR. Pseudo flavors are used *exclusively* to disable some subpackages. The particularity of pseudo-flavors is that it does NOT change anything about the stuff that is actually built, it only changes what is actually built. This is documented again and again in bsd.port.mk(5), in the porters handbook, in bsd.port.arch.mk(5). Please spend the time to understand what you're talking about, instead of spewing out complete nonsense that doesn't match our terminology.
HEADS-UP: MASTER_SITES0...9 going away
I'm currently running a patch that converts the last few ports with MASTER_SITES0...9 to the new style of SITES.sufx. Accordingly, once the bulk finishes (succesfully) I will also remove the support in bsd.port.mk. In the meantime, if you commit stuff that reintroduces MASTER_SITES0..9, well, it will break.
Re: cad/kicad status
On Tue, Sep 19, 2023 at 04:58:31PM +0200, Marc Espie wrote: > I don't know who's interested in that port, but the main archive from > the site doesn't match at all what we have in the backups. For starters, > our archive is 45MB long, whereas the main site retrieves a file that's 322MB > long (!) > > This does take more or less forever to fetch to fall on its nose, basically, > and should most probably get looked at! (I should also mention we're off by 7 months and a major release, 6.0.11 to 7.0.7)
cad/kicad status
I don't know who's interested in that port, but the main archive from the site doesn't match at all what we have in the backups. For starters, our archive is 45MB long, whereas the main site retrieves a file that's 322MB long (!) This does take more or less forever to fetch to fall on its nose, basically, and should most probably get looked at!
Re: check-lib-depends and modules' *_WANTLIB
On Thu, Sep 14, 2023 at 03:09:00PM +0200, Omar Polo wrote:
> friendly ping, reattaching the two patches.
>
> Index: infrastructure/mk/bsd.port.mk
> ===
> RCS file: /home/cvs/ports/infrastructure/mk/bsd.port.mk,v
> retrieving revision 1.1621
> diff -u -p -r1.1621 bsd.port.mk
> --- infrastructure/mk/bsd.port.mk 13 Sep 2023 07:47:11 - 1.1621
> +++ infrastructure/mk/bsd.port.mk 14 Sep 2023 13:05:28 -
> @@ -280,6 +280,8 @@ NO_TEST ?= No
> INSTALL_TARGET ?= install
> USE_GROFF ?= No
>
> +CHECK_LIB_DEPENDS_ARGS =
> +
> .if !defined(_ARCH_DEFINES_INCLUDED)
> _ARCH_DEFINES_INCLUDED = Done
> . include "${PORTSDIR}/infrastructure/mk/arch-defines.mk"
> @@ -1981,12 +1983,13 @@ _check_lib_depends = ${_CHECK_LIB_DEPEND
> _check_lib_depends =:
> .endif
>
> +CHECK_LIB_DEPENDS_ARGS += -S COMPILER_LIBCXX="${COMPILER_LIBCXX}"
> +CHECK_LIB_DEPENDS_ARGS += -S LIBECXX="${LIBECXX}"
> +CHECK_LIB_DEPENDS_ARGS += -S LIBCXX="${LIBCXX}"
> +CHECK_LIB_DEPENDS_ARGS += -F pthread
> +
> _CHECK_LIB_DEPENDS = PORTSDIR=${PORTSDIR} ${_PERLSCRIPT}/check-lib-depends
> -_CHECK_LIB_DEPENDS += -d ${_PKG_REPO} -B ${WRKINST}
> -_CHECK_LIB_DEPENDS += -S COMPILER_LIBCXX="${COMPILER_LIBCXX}"
> -_CHECK_LIB_DEPENDS += -S LIBECXX="${LIBECXX}"
> -_CHECK_LIB_DEPENDS += -S LIBCXX="${LIBCXX}"
> -_CHECK_LIB_DEPENDS += -F pthread
> +_CHECK_LIB_DEPENDS += -d ${_PKG_REPO} -B ${WRKINST} ${CHECK_LIB_DEPENDS_ARGS}
>
> .for _s in ${MULTI_PACKAGES}
> . if ${STATIC_PLIST${_s}:L} == "no"
> Index: devel/cargo/cargo.port.mk
> ===
> RCS file: /home/cvs/ports/devel/cargo/cargo.port.mk,v
> retrieving revision 1.38
> diff -u -p -r1.38 cargo.port.mk
> --- devel/cargo/cargo.port.mk 2 Sep 2023 17:26:36 - 1.38
> +++ devel/cargo/cargo.port.mk 14 Sep 2023 13:06:02 -
> @@ -36,6 +36,9 @@ MODCARGO_WANTLIB += c++abi
> MODCARGO_WANTLIB +=
> .endif
>
> +CHECK_LIB_DEPENDS_ARGS += -S MODCARGO_WANTLIB="${MODCARGO_WANTLIB}"
> +CHECK_LIB_DEPENDS_ARGS += -F c++abi
> +
> # Define MASTER_SITES_CRATESIO for crates.io
> MASTER_SITES.cargo = https://crates.io/api/v1/crates/
>
> Index: lang/lua/lua.port.mk
> ===
> RCS file: /home/cvs/ports/lang/lua/lua.port.mk,v
> retrieving revision 1.37
> diff -u -p -r1.37 lua.port.mk
> --- lang/lua/lua.port.mk 25 Dec 2022 13:40:19 - 1.37
> +++ lang/lua/lua.port.mk 14 Sep 2023 13:05:28 -
> @@ -58,6 +58,8 @@ MODLUA_DEP =lua${MODLUA_DEP_VERSION}
> MODLUA_WANTLIB = lua${MODLUA_VERSION}
> MODLUA_LIB = -l${MODLUA_WANTLIB}
>
> +CHECK_LIB_DEPENDS_ARGS += -S MODLUA_WANTLIB="${MODLUA_WANTLIB}"
> +
> _MODLUA_RUN_DEPENDS =lang/lua/${MODLUA_VERSION}
>
> MODLUA_LIB_DEPENDS = ${_MODLUA_RUN_DEPENDS}
> ---
> commit beb07533b4020698cd5686ed67fe6afb888e62ce
> from: Omar Polo
> date: Thu Sep 14 12:58:27 2023 UTC
>
> pending espie@
>
> diff 817f9e342421490cb07dac6595511380a144bd02
> beb07533b4020698cd5686ed67fe6afb888e62ce
> commit - 817f9e342421490cb07dac6595511380a144bd02
> commit + beb07533b4020698cd5686ed67fe6afb888e62ce
> blob - 00ec6c3f81fcf03ea69eabe8de1741a6e562
> blob + e9c20a2308892dd1059acfe8b546cc135e8c4e8f
> --- share/man/man5/bsd.port.mk.5
> +++ share/man/man5/bsd.port.mk.5
> @@ -1339,6 +1339,13 @@ as this can be a big performance hit, and also because
> .Ev lib-depends-check
> doesn't know about library subdirectories or dynamic loading through
> .Xr dlopen 3 .
> +.It Ev CHECK_LIB_DEPENDS_ARGS
> +List of arguments for
> +.Xr check-lib-depends 1 .
> +Useful for
> +.Xr port-modules 5
> +to substitute list of libraries with a variable in
> +.Ev WANTLIB .
> .It Ev CHECKSUMFILES
> List of all files that need to be retrieved by
> .Cm fetch ,
>
Oh yes, I was okay with the source part.
Note sure mentioning port-modules is useful.
It should read "List of *extra* arguments" (emphasis mine)
because there are already mandatory arguments that you don't control
as you well know :)
Re: DIST_TUPLE: add codeberg support, and permit some customization on extracted directory
On Thu, Sep 14, 2023 at 12:31:34PM +0200, Sebastien Marie wrote:
> Hi,
>
> When trying to add codeberg to DIST_TUPLE stuff, I had a problem with the
> name
> used to extract the downloaded tarball.
>
> codeberg.org is using the following scheme:
> the downloaded file is at:
> https://codeberg.org///archive/.tar.gz
> the tarball extracts at ${WRKDIR}// (and not
> ${WRKDIR}/-/ as expected by DIST_TUPLE)
>
> So I customized a bit dist-tuple.port.mk to be able to use a template for
> this name.
>
> The variable is named TEMPLATE_WRKSRC.x (using WRKSRC for the similarity with
> a
> port with only one distfile). But I am unsure about the name.
>
> The following patch adds the machinery (and the doc) for using
> TEMPLATE_WRKSRC.,
> and adds also codeberg in templates.
>
> I tested several github ports which differents schemes, but more testing will
> be
> appreciate.
>
> Thanks.
> --
> Sebastien Marie
>
> diff /home/semarie/repos/openbsd/ports
> commit - d3b35887e0ba204a5916da1942dd81f98bfc2148
> path + /home/semarie/repos/openbsd/ports
> blob - b4bf842539bf825f55e78520f17b026f654419bb
> file + infrastructure/mk/dist-tuple.port.mk
> --- infrastructure/mk/dist-tuple.port.mk
> +++ infrastructure/mk/dist-tuple.port.mk
> @@ -38,9 +38,10 @@ HOMEPAGE ?=
> ${TEMPLATE_HOMEPAGE.${_template}:S/
> .if "${_targetdir}" != "."
> MODDIST-TUPLE_post-extract += \
> +
> s=${TEMPLATE_WRKSRC.${_template}:S//${_account}/g:S//${_project}/g:S//${_id:S/refs\/tags\///:S/^v//}/g:S//${_subdir}/g};
> \
> t=${WRKDIST}/${_targetdir}; [[ -d $$t ]] && rmdir $$t \
> || mkdir -p `dirname $$t` ; \
> - mv ${WRKDIR}/${_project}-${_id:S/refs\/tags\///:S/^v//} $$t;
> + mv ${WRKDIR}/$$s $$t;
> .endif
>
> . endfor
> diff /home/semarie/repos/openbsd/ports
> commit - d3b35887e0ba204a5916da1942dd81f98bfc2148
> path + /home/semarie/repos/openbsd/ports
> blob - 3b11da9f1f4ef0be05caace3865d55f51d70d92c
> file + infrastructure/db/dist-tuple.pattern
> --- infrastructure/db/dist-tuple.pattern
> +++ infrastructure/db/dist-tuple.pattern
> @@ -1,9 +1,11 @@
> # known MASTER_SITES.x
> +MASTER_SITES.codeberg ?= https://codeberg.org/
> MASTER_SITES.github ?= https://github.com/
> MASTER_SITES.gitlab ?= https://gitlab.com/
> MASTER_SITES.srht ?= https://git.sr.ht/
>
> # EXTRACT_SUFX.x for each site
> +EXTRACT_SUFX.codeberg ?= .tar.gz
> EXTRACT_SUFX.github ?= .tar.gz
> EXTRACT_SUFX.gitlab ?= .tar.gz
> EXTRACT_SUFX.srht ?= .tar.gz
> @@ -13,6 +15,9 @@ EXTRACT_SUFX.srht ?=.tar.gz
> # -
> # -
> # - - used automatically if is in tag format
> +TEMPLATE_DISTFILES.codeberg ?= \
> +
> --{//archive/}${EXTRACT_SUFX.codeberg}
> +
> TEMPLATE_DISTFILES.github ?= \
>
> --{//archive/}${EXTRACT_SUFX.github}
>
> @@ -23,6 +28,13 @@ TEMPLATE_DISTFILES.srht ?= \
>
> --{~//archive/}${EXTRACT_SUFX.srht}
>
> # templates for HOMEPAGE; same substitutions as for DISTFILES.x
> +TEMPLATE_HOMEPAGE.codeberg ?=https://codeberg.org//
> TEMPLATE_HOMEPAGE.github ?= https://github.com//
> TEMPLATE_HOMEPAGE.gitlab ?= https://gitlab.com//
> TEMPLATE_HOMEPAGE.srht ?=https://git.sr.ht/~/
> +
> +# templates for extraction; same substitutions as for DISTFILES.x
> +TEMPLATE_WRKSRC.codeberg ?=
> +TEMPLATE_WRKSRC.github ?=-
> +TEMPLATE_WRKSRC.gitlab ?=-
> +TEMPLATE_WRKSRC.srht ?= -
> diff /home/semarie/repos/openbsd/src
> commit - 5f7ea7bc25406ceab417284d038129723f0423a2
> path + /home/semarie/repos/openbsd/src
> blob - 099febdff4c5d7dba8b8aff137831c91abb57364
> file + share/man/man5/bsd.port.mk.5
> --- share/man/man5/bsd.port.mk.5
> +++ share/man/man5/bsd.port.mk.5
> @@ -1648,6 +1648,7 @@ List of distfile templates to use, each consisting of
> The template
> .Ar name
> should be one of
> +.Sq codeberg ,
> .Sq github ,
> .Sq gitlab ,
> or
> @@ -1656,7 +1657,8 @@ at the moment
> .Po see
> .Pa ${PORTSDIR}/db/dist-tuple.pattern ,
> additional
> -.Ev TEMPLATE_DISTFILES.
> +.Ev TEMPLATE_DISTFILES. ,
> +.Ev TEMPLATE_WRKSRC.
> and
> .Ev TEMPLATE_HOMEPAGE.
> entries can be added as needed
> @@ -3452,6 +3454,12 @@ when using
> .Ev DIST_TUPLE .
> Very similar to
> .Ev TEMPLATE_DISTFILES. .
> +.It Ev TEMPLATE_WRKSRC.
> +Template for automatically generated the name of the source
> +directory extracted when using
> +.Ev DIST_TUPLE .
> +Very similar to
> +.Ev TEMPLATE_DISTFILES. .
> .It Ev TEST_DEPENDS
> See
> .Ev BUILD_DEPENDS
>
We should also stop defining TEMPLATE_WRKSRC.sufx and EXTRACT_SUFX.sufx
individually.
Setting it in the loop as
EXTRACT_SUFX.${_template} ?= ${EXTRACT_SUF}
and
TEMPLATE_WRKSRC.${_template} ?= ${TEMPLATE_WRKSRC}
makes things more regular
(along with setting
TEMPLATE_WRKSRC = ${WRKDIR}/-
TEMPLATE_WRKSRC.codeberg = ${WRKDIR}/
)
Re: DIST_TUPLE: add codeberg support, and permit some customization on extracted directory
Completely orthogonal patch.
Using the same substitution twice is already cause for errors.
Using it 3 times is a sin.
Let's save that somewhere.
Index: dist-tuple.port.mk
===
RCS file: /cvs/ports/infrastructure/mk/dist-tuple.port.mk,v
retrieving revision 1.8
diff -u -p -r1.8 dist-tuple.port.mk
--- dist-tuple.port.mk 4 Sep 2023 15:29:46 - 1.8
+++ dist-tuple.port.mk 14 Sep 2023 12:16:00 -
@@ -31,17 +31,19 @@ DISTNAME ?= ${_project}-${_id:S/^v//}
_subdir = refs/tags/
.endif
-DISTFILES.${_template} +=
${TEMPLATE_DISTFILES.${_template}:S//${_account}/g:S//${_project}/g:S//${_id}/g:S//${_subdir}/g}
-.if !empty(TEMPLATE_HOMEPAGE.${_template})
-HOMEPAGE ?=
${TEMPLATE_HOMEPAGE.${_template}:S//${_account}/g:S//${_project}/g}
-.endif
+.for _subst in
S//${_account}/g:S//${_project}/g:S//${_id}/g:S//${_subdir}/g
+DISTFILES.${_template} += ${TEMPLATE_DISTFILES.${_template}:${_subst}}
+. if !empty(TEMPLATE_HOMEPAGE.${_template})
+HOMEPAGE ?=${TEMPLATE_HOMEPAGE.${_template}:${_subst}}
+. endif
-.if "${_targetdir}" != "."
+. if "${_targetdir}" != "."
MODDIST-TUPLE_post-extract += \
t=${WRKDIST}/${_targetdir}; [[ -d $$t ]] && rmdir $$t \
|| mkdir -p `dirname $$t` ; \
mv ${WRKDIR}/${_project}-${_id:S/refs\/tags\///:S/^v//} $$t;
-.endif
+. endif
+.endfor
. endfor
.endif
Re: DIST_TUPLE: add codeberg support, and permit some customization
on extracted directory
Reply-To:
In-Reply-To:
On Thu, Sep 14, 2023 at 12:31:34PM +0200, Sebastien Marie wrote:
> Hi,
>
> When trying to add codeberg to DIST_TUPLE stuff, I had a problem with the
> name
> used to extract the downloaded tarball.
>
> codeberg.org is using the following scheme:
> the downloaded file is at:
> https://codeberg.org///archive/.tar.gz
> the tarball extracts at ${WRKDIR}// (and not
> ${WRKDIR}/-/ as expected by DIST_TUPLE)
>
> So I customized a bit dist-tuple.port.mk to be able to use a template for
> this name.
>
> The variable is named TEMPLATE_WRKSRC.x (using WRKSRC for the similarity with
> a
> port with only one distfile). But I am unsure about the name.
>
> The following patch adds the machinery (and the doc) for using
> TEMPLATE_WRKSRC.,
> and adds also codeberg in templates.
>
> I tested several github ports which differents schemes, but more testing will
> be
> appreciate.
>
> Thanks.
> --
> Sebastien Marie
>
> diff /home/semarie/repos/openbsd/ports
> commit - d3b35887e0ba204a5916da1942dd81f98bfc2148
> path + /home/semarie/repos/openbsd/ports
> blob - b4bf842539bf825f55e78520f17b026f654419bb
> file + infrastructure/mk/dist-tuple.port.mk
> --- infrastructure/mk/dist-tuple.port.mk
> +++ infrastructure/mk/dist-tuple.port.mk
> @@ -38,9 +38,10 @@ HOMEPAGE ?=
> ${TEMPLATE_HOMEPAGE.${_template}:S/
> .if "${_targetdir}" != "."
> MODDIST-TUPLE_post-extract += \
> +
> s=${TEMPLATE_WRKSRC.${_template}:S//${_account}/g:S//${_project}/g:S//${_id:S/refs\/tags\///:S/^v//}/g:S//${_subdir}/g};
> \
> t=${WRKDIST}/${_targetdir}; [[ -d $$t ]] && rmdir $$t \
> || mkdir -p `dirname $$t` ; \
> - mv ${WRKDIR}/${_project}-${_id:S/refs\/tags\///:S/^v//} $$t;
> + mv ${WRKDIR}/$$s $$t;
> .endif
>
> . endfor
> diff /home/semarie/repos/openbsd/ports
> commit - d3b35887e0ba204a5916da1942dd81f98bfc2148
> path + /home/semarie/repos/openbsd/ports
> blob - 3b11da9f1f4ef0be05caace3865d55f51d70d92c
> file + infrastructure/db/dist-tuple.pattern
> --- infrastructure/db/dist-tuple.pattern
> +++ infrastructure/db/dist-tuple.pattern
> @@ -1,9 +1,11 @@
> # known MASTER_SITES.x
> +MASTER_SITES.codeberg ?= https://codeberg.org/
> MASTER_SITES.github ?= https://github.com/
> MASTER_SITES.gitlab ?= https://gitlab.com/
> MASTER_SITES.srht ?= https://git.sr.ht/
>
> # EXTRACT_SUFX.x for each site
> +EXTRACT_SUFX.codeberg ?= .tar.gz
> EXTRACT_SUFX.github ?= .tar.gz
> EXTRACT_SUFX.gitlab ?= .tar.gz
> EXTRACT_SUFX.srht ?= .tar.gz
> @@ -13,6 +15,9 @@ EXTRACT_SUFX.srht ?=.tar.gz
> # -
> # -
> # - - used automatically if is in tag format
> +TEMPLATE_DISTFILES.codeberg ?= \
> +
> --{//archive/}${EXTRACT_SUFX.codeberg}
> +
> TEMPLATE_DISTFILES.github ?= \
>
> --{//archive/}${EXTRACT_SUFX.github}
>
> @@ -23,6 +28,13 @@ TEMPLATE_DISTFILES.srht ?= \
>
> --{~//archive/}${EXTRACT_SUFX.srht}
>
> # templates for HOMEPAGE; same substitutions as for DISTFILES.x
> +TEMPLATE_HOMEPAGE.codeberg ?=https://codeberg.org//
> TEMPLATE_HOMEPAGE.github ?= https://github.com//
> TEMPLATE_HOMEPAGE.gitlab ?= https://gitlab.com//
> TEMPLATE_HOMEPAGE.srht ?=https://git.sr.ht/~/
> +
> +# templates for extraction; same substitutions as for DISTFILES.x
> +TEMPLATE_WRKSRC.codeberg ?=
> +TEMPLATE_WRKSRC.github ?=-
> +TEMPLATE_WRKSRC.gitlab ?=-
> +TEMPLATE_WRKSRC.srht ?= -
> diff /home/semarie/repos/openbsd/src
> commit - 5f7ea7bc25406ceab417284d038129723f0423a2
> path + /home/semarie/repos/openbsd/src
> blob - 099febdff4c5d7dba8b8aff137831c91abb57364
> file + share/man/man5/bsd.port.mk.5
> --- share/man/man5/bsd.port.mk.5
> +++ share/man/man5/bsd.port.mk.5
> @@ -1648,6 +1648,7 @@ List of distfile templates to use, each consisting of
> The template
> .Ar name
> should be one of
> +.Sq codeberg ,
> .Sq github ,
> .Sq gitlab ,
> or
> @@ -1656,7 +1657,8 @@ at the moment
> .Po see
> .Pa ${PORTSDIR}/db/dist-tuple.pattern ,
> additional
> -.Ev TEMPLATE_DISTFILES.
> +.Ev TEMPLATE_DISTFILES. ,
> +.Ev TEMPLATE_WRKSRC.
> and
> .Ev TEMPLATE_HOMEPAGE.
> entries can be added as needed
> @@ -3452,6 +3454,12 @@ when using
> .Ev DIST_TUPLE .
> Very similar to
> .Ev TEMPLATE_DISTFILES. .
> +.It Ev TEMPLATE_WRKSRC.
> +Template for automatically generated the name of the source
> +directory extracted when using
> +.Ev DIST_TUPLE .
> +Very similar to
> +.Ev TEMPLATE_DISTFILES. .
> .It Ev TEST_DEPENDS
> See
> .Ev BUILD_DEPENDS
>
the only reason I use t in the fragment is because it's used twice, and
hence shorter in the result produced.
You got to realize that fragments get potentially very long.
Now, s only makes things longer.
I'm also not a fan of the name "WRKSRC" for the value you propose.
It would be way more consistent to start with
+TEMPLATE_WRKSRC.codeberg ?=${WRKDIR}/
instead, just so that people get lost a bit less.
(eithe that, or use
TEMPLAT
patch: have portroach notice us of new auto*
Very straightforward.
Okay ?
Index: autoconf/Makefile.inc
===
RCS file: /cvs/ports/devel/autoconf/Makefile.inc,v
retrieving revision 1.8
diff -u -p -r1.8 Makefile.inc
--- autoconf/Makefile.inc 11 Mar 2022 18:49:37 - 1.8
+++ autoconf/Makefile.inc 9 Sep 2023 12:03:05 -
@@ -26,4 +26,4 @@ CONFIGURE_ARGS += --program-suffix=${SU
MAKE_FLAGS += pkgdatadir=${PREFIX}/share/autoconf${SUFFIX}
FAKE_FLAGS += lispdir=
-PORTROACH =limit:^${VERSION}
+PORTROACH ?= limit:^${VERSION}
Index: autoconf/2.71/Makefile
===
RCS file: /cvs/ports/devel/autoconf/2.71/Makefile,v
retrieving revision 1.2
diff -u -p -r1.2 Makefile
--- autoconf/2.71/Makefile 11 Mar 2022 18:49:40 - 1.2
+++ autoconf/2.71/Makefile 9 Sep 2023 12:03:05 -
@@ -10,5 +10,6 @@ MAKE_FLAGS = EMACS=no
FAKE_FLAGS = EMACS=no
TEST_DEPENDS = devel/automake/1.16
TEST_FLAGS += AUTOMAKE_VERSION=1.16
+PORTROACH =
.include
Index: automake/Makefile.inc
===
RCS file: /cvs/ports/devel/automake/Makefile.inc,v
retrieving revision 1.8
diff -u -p -r1.8 Makefile.inc
--- automake/Makefile.inc 6 Dec 2022 15:34:34 - 1.8
+++ automake/Makefile.inc 9 Sep 2023 12:03:05 -
@@ -13,7 +13,7 @@ PERMIT_PACKAGE ?= Yes
# we're not a python port, don't subst py- prefix
UPDATE_PLIST_ARGS += -i MODPY_PY_PREFIX
-PORTROACH =limit:^${VERSION}
+PORTROACH ?= limit:^${VERSION}
BUILD_DEPENDS += ${RUN_DEPENDS}
CONFIGURE_ARGS += --infodir=${PREFIX}/info
Index: automake/1.16/Makefile
===
RCS file: /cvs/ports/devel/automake/1.16/Makefile,v
retrieving revision 1.8
diff -u -p -r1.8 Makefile
--- automake/1.16/Makefile 9 Dec 2022 11:15:02 - 1.8
+++ automake/1.16/Makefile 9 Sep 2023 12:03:05 -
@@ -2,6 +2,7 @@ VERSION=1.16
DISTNAME= automake-${VERSION}.5
PKGSPEC= automake->=${VERSION},<1.17
EXTRACT_SUFX= .tar.xz
+PORTROACH =
AUTOCONF_VERSION= 2.69
Re: spring clean-up
On Thu, Sep 07, 2023 at 08:12:32PM -0400, Thomas Frohwein wrote: > On Thu, Sep 07, 2023 at 07:06:31PM +0200, Marc Espie wrote: > > Does anyone actually use the "checkpatch" target ? > > > > I didn't know it exists. Reading the documentation in bsd.port.mk(5), > I'm not sure I see a case for me to use it as `make clean patch` is very > fast here. Might be of interest for large ports handled on slow (HDD?) > drives... > I'm not looking for a case to use it, I'm pretty sure it should be GC'd. I'm giving the opportunity for people (possibly non existent) who still use it to chime up before it hits the Attic!
sqlports
Wondering whether I should make an outside facing view/cached table containing values in a somewhat non changing way, even though they no longer reflect our actual naming policies.
spring clean-up
Does anyone actually use the "checkpatch" target ?
results logs: problematic fetching
I've attached the first run of dpb -F8 with the new more descriptive options. It shows every location it tried to fetch that didn't work. "FIRST" means it's the first entry in SITES* "BACKUP" means it's actually failed to fetch from the SITES* list and had to switch to SITES_OPENBSD (it's offset by one: the LAST entry that's a regular site will show BACKUP). "BACKUPONLY" means there's no official site and it's going straight to the backups. (I just decorated the old bad.log and added some more info to it) keep in mind that some of these might be transient failures. bad.log.gz Description: bad.log.gz
Re: portroach tweaks
On Thu, Sep 07, 2023 at 12:24:59PM +0200, Marc Espie wrote:
> I've been perusing the results of the build, they aren't good, then
> again portroach isn't quite grabbing the right stuff.
>
> - tweak the meter to use shorter x/x so that it fits again on the
> line.
>
> - use fullpkgname instead of distname because that one is *always* defined.
> (and strip v/p accordingly)
>
> - switch to roach_url/roach_sites
>
> - use the portsq cached table instead of the view (this goes MUCH faster
> not surprisingly)
>
> this does require an up-to-date sqlports.
>
> Long term, it would be appropriate to create a temp view based on portsq
> that contains all required fields with sensible names, so that it's
> less painful to rename stuff in every individual query.
And here's the updated patch which does create the temp view.
Index: Makefile
===
RCS file: /cvs/ports/misc/portroach/Makefile,v
retrieving revision 1.37
diff -u -p -r1.37 Makefile
--- Makefile21 Jul 2023 10:57:10 - 1.37
+++ Makefile7 Sep 2023 13:31:42 -
@@ -3,7 +3,7 @@ COMMENT=OpenBSD ports distfile version
GH_ACCOUNT=jasperla
GH_PROJECT=portroach
GH_TAGNAME=2.0.11
-REVISION= 4
+REVISION= 5
CATEGORIES=misc
Index: patches/patch-Portroach_DataSrc_Ports_pm
===
RCS file: patches/patch-Portroach_DataSrc_Ports_pm
diff -N patches/patch-Portroach_DataSrc_Ports_pm
--- /dev/null 1 Jan 1970 00:00:00 -
+++ patches/patch-Portroach_DataSrc_Ports_pm7 Sep 2023 13:31:42 -
@@ -0,0 +1,40 @@
+Index: Portroach/DataSrc/Ports.pm
+--- Portroach/DataSrc/Ports.pm.orig
Portroach/DataSrc/Ports.pm
+@@ -114,6 +114,8 @@ sub BuildDB
+
+ $dbh = connect_db();
+
++ prepare_sql($sdbh, \%ssths, qw(create_view));
++ $ssths{create_view}->execute or die DBI->errstr;
+ prepare_sql($sdbh, \%ssths, qw(sqlports_count_ports
sqlports_fullpkgpaths_by_maintainer));
+
+ if ($settings{restrict_maintainer}) {
+@@ -131,6 +133,7 @@ sub BuildDB
+ # Query SQLports for all the information we need. We don't care about
+ # restrictions for now as this step basically copies sqlports. Check()
+ # will handle any restrictions instead.
++
+ $ssths{sqlports_count_ports}->execute or die DBI->errstr;
+ $num_ports = $ssths{sqlports_count_ports}->fetchrow_array();
+
+@@ -217,6 +220,10 @@ sub BuildPort
+ $name = fullpkgpathtoport($fullpkgpath);
+
+ $distname = $ports[2];
++ # get rid of version/epoch markers
++ $distname =~ s/v[0-9]+$//;
++ $distname =~ s/p[0-9]+$//;
++
+ foreach my $file (split /\s+/, $ports[3]) {
+ $file =~ s/:[A-Za-z0-9][A-Za-z0-9\,]*$//g;
+ push @distfiles, $file;
+@@ -305,7 +312,7 @@ sub BuildPort
+ }
+ }
+
+- info(1, $fullpkgpath, "($n_port out of $total_ports)");
++ info(1, $fullpkgpath, "($n_port/$total_ports)");
+
+ $ps->AddPort({
+ 'name'=> $name,
Index: patches/patch-Portroach_SQL_pm
===
RCS file: /cvs/ports/misc/portroach/patches/patch-Portroach_SQL_pm,v
retrieving revision 1.4
diff -u -p -r1.4 patch-Portroach_SQL_pm
--- patches/patch-Portroach_SQL_pm 11 Mar 2022 19:38:17 - 1.4
+++ patches/patch-Portroach_SQL_pm 7 Sep 2023 13:31:42 -
@@ -1,7 +1,93 @@
Index: Portroach/SQL.pm
--- Portroach/SQL.pm.orig
+++ Portroach/SQL.pm
-@@ -311,7 +311,7 @@ $sql{portdata_fullpkgpaths} =
+@@ -71,51 +71,62 @@ $sql{portdata_update} =
+fullpkgpath = ?
+ WHERE basepkgpath = ?);
+
++
+ # Port.pm:BuildPort()
++
++$sql{create_view} =
++ q(CREATE TEMP VIEW RoachData AS
++SELECT fullpkgpath, categories, fullpkgname as distname,
++ roach_url as distfiles,
++ roach_sites as master_sites,
++ maintainer, comment, portroach,
++ portroach_comment, homepage
++FROM portsq);
++
+ $sql{ports_select} =
+ q(SELECT fullpkgpath, categories, distname, distfiles,
+ master_sites, maintainer, comment, portroach,
+portroach_comment, homepage
+-FROM ports);
++FROM RoachData);
+
+ $sql{ports_select_count} =
+ q(SELECT COUNT(fullpkgpath)
+-FROM ports);
++FROM RoachData);
+
+ $sql{ports_restrict_maintainer} =
+ q(SELECT fullpkgpath, categories, distname, distfiles,
+ master_sites, maintainer, comment, portroach,
+ portroach_comment, homepage
+-FROM ports
++FROM RoachData
+WHERE maintainer like ?);
+
+ $sql{ports_restrict_maintainer_count} =
+ q(SELECT COUNT(
Re: devel/gmake default CXX=g++ should be c++ ?
On Thu, Sep 07, 2023 at 11:23:14AM +0100, Julian Smith wrote: > devel/gmake defaults to CC=cc but CXX=g++. > > It doesn't seem to make sense to mix `cc`, the system C compiler > (typically clang-based) with `g++`, the non-system GNU C++ compiler. > > I've been routinely running gmake with a `CXX=c++` prefix in order to > build various C/C++ projects. > > Here's a new patch file that fixes the port for me: > > /usr/ports/devel/gmake/patches/patch-src_default_c > > Index src/default.c > --- src/default.c.orig > +++ src/default.c > @@ -530,7 +530,7 @@ > "OBJC", "gcc", > #else > "CC", "cc", > -"CXX", "g++", > +"CXX", "c++", > "OBJC", "cc", > #endif > > > > - Jules > > -- > http://op59.net > > This is definitely the kind of change that, unfortunately, requires a full bulk build to be sure. Let's hope somebody will try it out, though we're rather busy with llvm16 at the moment.
portroach tweaks
I've been perusing the results of the build, they aren't good, then
again portroach isn't quite grabbing the right stuff.
- tweak the meter to use shorter x/x so that it fits again on the
line.
- use fullpkgname instead of distname because that one is *always* defined.
(and strip v/p accordingly)
- switch to roach_url/roach_sites
- use the portsq cached table instead of the view (this goes MUCH faster
not surprisingly)
this does require an up-to-date sqlports.
Long term, it would be appropriate to create a temp view based on portsq
that contains all required fields with sensible names, so that it's
less painful to rename stuff in every individual query.
I haven't run the check, since this probably requires setting up PgSql
for maximum efficiency.
Index: Makefile
===
RCS file: /cvs/ports/misc/portroach/Makefile,v
retrieving revision 1.37
diff -u -p -r1.37 Makefile
--- Makefile21 Jul 2023 10:57:10 - 1.37
+++ Makefile7 Sep 2023 10:19:41 -
@@ -3,7 +3,7 @@ COMMENT=OpenBSD ports distfile version
GH_ACCOUNT=jasperla
GH_PROJECT=portroach
GH_TAGNAME=2.0.11
-REVISION= 4
+REVISION= 5
CATEGORIES=misc
Index: patches/patch-Portroach_DataSrc_Ports_pm
===
RCS file: patches/patch-Portroach_DataSrc_Ports_pm
diff -N patches/patch-Portroach_DataSrc_Ports_pm
--- /dev/null 1 Jan 1970 00:00:00 -
+++ patches/patch-Portroach_DataSrc_Ports_pm7 Sep 2023 10:19:41 -
@@ -0,0 +1,23 @@
+Index: Portroach/DataSrc/Ports.pm
+--- Portroach/DataSrc/Ports.pm.orig
Portroach/DataSrc/Ports.pm
+@@ -217,6 +217,10 @@ sub BuildPort
+ $name = fullpkgpathtoport($fullpkgpath);
+
+ $distname = $ports[2];
++ # get rid of version/epoch markers
++ $distname =~ s/v[0-9]+$//;
++ $distname =~ s/p[0-9]+$//;
++
+ foreach my $file (split /\s+/, $ports[3]) {
+ $file =~ s/:[A-Za-z0-9][A-Za-z0-9\,]*$//g;
+ push @distfiles, $file;
+@@ -305,7 +309,7 @@ sub BuildPort
+ }
+ }
+
+- info(1, $fullpkgpath, "($n_port out of $total_ports)");
++ info(1, $fullpkgpath, "($n_port/$total_ports)");
+
+ $ps->AddPort({
+ 'name'=> $name,
Index: patches/patch-Portroach_SQL_pm
===
RCS file: /cvs/ports/misc/portroach/patches/patch-Portroach_SQL_pm,v
retrieving revision 1.4
diff -u -p -r1.4 patch-Portroach_SQL_pm
--- patches/patch-Portroach_SQL_pm 11 Mar 2022 19:38:17 - 1.4
+++ patches/patch-Portroach_SQL_pm 7 Sep 2023 10:19:41 -
@@ -1,6 +1,81 @@
Index: Portroach/SQL.pm
--- Portroach/SQL.pm.orig
+++ Portroach/SQL.pm
+@@ -73,49 +73,49 @@ $sql{portdata_update} =
+
+ # Port.pm:BuildPort()
+ $sql{ports_select} =
+-q(SELECT fullpkgpath, categories, distname, distfiles,
+- master_sites, maintainer, comment, portroach,
++q(SELECT fullpkgpath, categories, fullpkgname, roach_url,
++ roach_sites, maintainer, comment, portroach,
+portroach_comment, homepage
+-FROM ports);
++FROM portsq);
+
+ $sql{ports_select_count} =
+ q(SELECT COUNT(fullpkgpath)
+-FROM ports);
++FROM portsq);
+
+ $sql{ports_restrict_maintainer} =
+-q(SELECT fullpkgpath, categories, distname, distfiles,
+- master_sites, maintainer, comment, portroach,
++q(SELECT fullpkgpath, categories, fullpkgname, roach_url,
++ roach_sites, maintainer, comment, portroach,
+ portroach_comment, homepage
+-FROM ports
++FROM portsq
+WHERE maintainer like ?);
+
+ $sql{ports_restrict_maintainer_count} =
+ q(SELECT COUNT(fullpkgpath)
+-FROM ports
++FROM portsq
+WHERE maintainer like ?);
+
+ $sql{ports_restrict_category} =
+-q(SELECT fullpkgpath, categories, distname, distfiles,
+- master_sites, maintainer, comment, portroach,
++q(SELECT fullpkgpath, categories, fullpkgname, roach_url,
++ roach_sites, maintainer, comment, portroach,
+ portroach_comment, homepage
+-FROM ports
++FROM portsq
+WHERE categories like ?);
+
+ $sql{ports_restrict_category_count} =
+ q(SELECT COUNT(fullpkgpath)
+-FROM ports
++FROM portsq
+WHERE categories like ?);
+
+ $sql{ports_restrict_port} =
+-q(SELECT fullpkgpath, categories, distname, distfiles,
+- master_sites, maintainer, comment, portroach,
++q(SELECT fullpkgpath, categories, fullpkgname, roach_url,
++ roach_sites, maintainer, comment, portroach,
+ portroach_comment, homepage
+-FROM ports
++FROM portsq
+WHERE fullpkgpath like ?);
+
+ $sql{ports_restrict_port_count} =
+ q(SELECT COUNT(fullpkgpath)
spring clean-up
Speaking of stuff that's been there forever, I've been converting some MASTER_SITES to SITES, and while checking, I've noticed a very large number of ports without valid SITES. I mean, having them hosted on the ftp.openbsd.org mirror is not a big issue, but when people try to fetch manually, it's going to error the hell out of normal sites. Some of the old sites are entirely dead, some don't have the files anymore. Worse: some have the files, but with a different checksum. So I guess one of the next features of dpb is going to be more log files: - record distfiles that only fetched from the backup site - record distfiles that didn't fetch from the first site - record distfiles that fetched with the wrong size from the first site. Those are all interesting errors with various useful actions.
helping portroach along
So with the new DIST stuff, portroach is going to be even more lost than
usual.
I propose we try something like the following patch.
What this does:
if ROACH_URL isn't manually defined, bsd.port.mk will try its best to give it
a default value.
Namely:
- grab the first DISTFILES
- if there is none grab the first DISTFILES*
(note that if several DISTFILES.* variables are defined, this could take
any one of them, to hilariously bad result)
- use the same conversion rules as the rest of bsd.port.mk to deduce the
correct url and put it into ROACH_URL
Afterwards, while looking through DISTFILES*, set up ROACH_SITES when
we find our url.
(and finally, yield a fatal error if we didn't find our url)
Index: bsd.port.mk
===
RCS file: /cvs/ports/infrastructure/mk/bsd.port.mk,v
retrieving revision 1.1615
diff -u -p -r1.1615 bsd.port.mk
--- bsd.port.mk 6 Sep 2023 15:01:45 - 1.1615
+++ bsd.port.mk 6 Sep 2023 15:42:09 -
@@ -1349,6 +1349,24 @@ _CACHE_VARIABLES += DISTFILES
. endif
.endif
+.if !defined(ROACH_URL)
+. for d in ${DISTFILES}
+_ROACH_DISTFILE ?= $d
+. endfor
+.endif
+.if !defined(ROACH_URL)
+. for w in ${_CACHE_VARIABLES:MDISTFILES*}
+.for d in ${$w}
+_ROACH_DISTFILE ?= $d
+.endfor
+. endfor
+.endif
+
+.if defined(_ROACH_DISTFILE)
+. for u in ${_ROACH_DISTFILE:C/:[0-9]$//:C/^.*\{(.*)\}(.*)$/\1\2/}
+ROACH_URL = $u
+. endfor
+.endif
_ALL_DISTFILES_VARIABLES =
@@ -1380,6 +1398,9 @@ _warn_distfiles += ${e:M*\:[0-9]}
.if !defined($m)
ERRORS += "Fatal: $m is not defined but referenced by $e in $v"
.endif
+.if "${u}" == "${ROACH_URL}"
+ROACH_SITES = ${$m}
+.endif
.if empty(_FILES:M$f)
_FILES += $f
. if empty(DIST_SUBDIR)
@@ -1416,6 +1437,9 @@ EXTRACT_ONLY = ${ALL_DISTFILES}
ERRORS += "Fatal: EXTRACT_ONLY file $f not part of DISTFILES*"
.endif
. endfor
+.endif
+.if defined(ROACH_URL) && !defined(ROACH_SITES)
+ERRORS += "Fatal: where should portroach look for ${ROACH_URL}"
.endif
PATCH_CASES ?=
further changes to MASTER_SITES
After discussion, we think we can safely shorten the variables.
Not to be confused with a woke move, but frankly, SITES is long enough.
I'm test driving a patch that makes this mostly transparent.
It should hit the ports tree in a few hours.
(After this, just use SITES* wherever you used to use MASTER_SITES,
the conversion will happen behind the scene. The only tricky part is
that we need to convert all ports first, THEN we can convert base
stuff that we derive from like network.conf)
Before:
MASTER_SITES= ${MASTER_SITE_SOURCEFORGE:=arc/}
After:
SITES= ${SITE_SOURCEFORGE:=arc/}
Re: Switch from MASTER_SITES to MASTER_SITES.hs in Haskell ports
On Mon, Sep 04, 2023 at 12:45:05PM -0700, Greg Steuck wrote:
> Looks like we no longer have to manage a namespace of just 10 entries
> globally in the ports tree :)
>
> OK?
>
> >From 9f430fa6addbc4b89e260d5d7aa5cb43b8943b9b Mon Sep 17 00:00:00 2001
> From: Greg Steuck
> Date: Mon, 4 Sep 2023 12:41:33 -0700
> Subject: [PATCH] Switch from MASTER_SITES to MASTER_SITES.hs in Haskell ports
>
> ---
> devel/cabal-install/Makefile | 6 +++---
> devel/cabal/cabal.port.mk| 15 ++-
> 2 files changed, 9 insertions(+), 12 deletions(-)
>
> diff --git a/devel/cabal-install/Makefile b/devel/cabal-install/Makefile
> index 26b784af857..607e49060f7 100644
> --- a/devel/cabal-install/Makefile
> +++ b/devel/cabal-install/Makefile
> @@ -27,7 +27,7 @@ RUN_DEPENDS = lang/ghc
> EXTRACT_ONLY = ${DISTNAME}.tar.gz
> DISTFILES = ${EXTRACT_ONLY}
> DIST_SUBDIR =hackage
> -MASTER_SITES0 = https://hackage.haskell.org/package/
> +MASTER_SITES.hs =https://hackage.haskell.org/package/
>
> # Produced by manually copying values out of files/openbsd.json.
> _MANIFEST = \
> @@ -64,8 +64,8 @@ _MANIFEST = \
> zlib0.6.3.0 1
>
> .for _package _version _revision in ${_MANIFEST}
> -DISTFILES += {${_package}-${_version}/}${_package}-${_version}.tar.gz:0
> -DISTFILES +=
> ${_package}-${_version}_${_revision}{${_package}-${_version}/revision/${_revision}}.cabal:0
> +DISTFILES.hs += {${_package}-${_version}/}${_package}-${_version}.tar.gz
> +DISTFILES.hs +=
> ${_package}-${_version}_${_revision}{${_package}-${_version}/revision/${_revision}}.cabal
> .endfor
>
> BUILD_DEPENDS += lang/ghc>=8.10.6
> diff --git a/devel/cabal/cabal.port.mk b/devel/cabal/cabal.port.mk
> index ac8a419315f..539f0473c5a 100644
> --- a/devel/cabal/cabal.port.mk
> +++ b/devel/cabal/cabal.port.mk
> @@ -35,10 +35,7 @@ ONLY_FOR_ARCHS ?= i386 amd64
> BUILD_DEPENDS += devel/cabal-install>=3.4.0.0 \
> lang/ghc>=8.6.4
>
> -# Takes over :9 site for hackage. The day when we have a port using
> -# both Go/Rust and Hackage we'll have to resolve their common
> -# insistance on grabbing :9.
> -MASTER_SITES9 = https://hackage.haskell.org/package/
> +MASTER_SITES.hs =https://hackage.haskell.org/package/
>
> DIST_SUBDIR ?= hackage
>
> @@ -47,8 +44,8 @@ DIST_SUBDIR ?= hackage
> EXTRACT_CASES += *.cabal) ;;
>
> DISTNAME ?= ${MODCABAL_STEM}-${MODCABAL_VERSION}
> -HOMEPAGE ?= ${MASTER_SITES9}${MODCABAL_STEM}
> -MASTER_SITES ?= ${MASTER_SITES9}${DISTNAME}/
> +HOMEPAGE ?= ${MASTER_SITES.hs}${MODCABAL_STEM}
> +MASTER_SITES ?= ${MASTER_SITES.hs}${DISTNAME}/
> DISTFILES ?= ${DISTNAME}.tar.gz
> SUBST_VARS +=MODCABAL_STEM MODCABAL_VERSION PKGNAME
>
> @@ -63,7 +60,7 @@ MODCABAL_post-extract = \
> # Some packages need an updated .cabal file from hackage to overwrite
> # the one in the tar ball.
> .if defined(MODCABAL_REVISION)
> -DISTFILES +=
> ${DISTNAME}_${MODCABAL_REVISION}{revision/${MODCABAL_REVISION}}.cabal
> +DISTFILES.hs +=
> ${DISTNAME}_${MODCABAL_REVISION}{revision/${MODCABAL_REVISION}}.cabal
> MODCABAL_post-extract += \
> && cp ${FULLDISTDIR}/${DISTNAME}_${MODCABAL_REVISION}.cabal \
> ${WRKSRC}/${MODCABAL_STEM}.cabal
> @@ -71,9 +68,9 @@ MODCABAL_post-extract += \
>
> # The dependent sources get downloaded from hackage.
> .for _package _version _revision in ${MODCABAL_MANIFEST}
> -DISTFILES += {${_package}-${_version}/}${_package}-${_version}.tar.gz:9
> +DISTFILES.hs += {${_package}-${_version}/}${_package}-${_version}.tar.gz
> . if ${_revision} > 0
> -DISTFILES +=
> ${_package}-${_version}_${_revision}{${_package}-${_version}/revision/${_revision}}.cabal:9
> +DISTFILES.hs +=
> ${_package}-${_version}_${_revision}{${_package}-${_version}/revision/${_revision}}.cabal
> . endif
> .endfor # MODCABAL_MANIFEST
>
> --
> 2.41.0
>
>
Seems straightforward. Bye bye cumbersomeness, hello awesome new syntax
(yeah, you had to choose a name, which is the most difficult part about
the new syntax !)
DISTFILES.sufx and tweaks
The new DIST_TUPLE syntax is still undergoing some minor/major
tweaks (stay tuned).
As for retiring the old MASTER_SITES syntax, I acknowledge that having
all the stuff in DISTFILES was handy for EXTRACT_ONLY= ports.
But the rewriting stuff as in dest{url}sufx already made that cumbersome.
So I exposed some more internals:
ALL_DISTFILES contains the list of all distfiles destinations (as cobbled
from DISTFILES* after url -> dest substitutions.
likewise for ALL_PATCHFILES.
I could also expose ALL_SUPDISTFILES, but I expect the 3rd one to be
thoroughly unneeded by anyone.
(note: this doesn't cost anything, portswise, as these variables were
already computed as _LIST_DISTFILES/_LIST_PATCHFILES, and adding a new
name for them doesn't trigger a value copy until the variable gets
actually used)
Re: UPDATE: x11/fvwm3 to 1.0.7
On Mon, Sep 04, 2023 at 02:42:05AM +0200, Ingo Schwarze wrote: > However, nobody told me so far that they like the idea of showing this > information, but one developer told me privately that they are not a fan. Let me guess. I know one guy who makes it known when he doesn't like something, but almost always in private. :) > That looks neat for the FVWM case - however, i fear some people might > like exactly the same feature less in this case: > >$ man ls > Showing: /usr/share/man/man1/ls.1 > See also: /usr/local/man/man1/gls.1 > > LS(1) General Commands Manual LS(1) > > NAME > ls - list directory contents > [...] > Actually, I would argue it's even more useful in that case: it makes it obvious the manpage SHOULD be patched to have the installed command have the right name. And in case we have the same command name in several places, it's fairly easy to get confused and run the wrong one. Case in point: cups. Where all the commands are name exactly the same as stuff in base, but nothing behaves identically. It's fairly easy to get confused and lose a bit of time reading the wrong manpage. Having any kind of small indication that there are several of them could be a life-saver for lots of people. As for section stuff and things: we all got bitten years ago looking for printf and checking the section at top to figure out it was a shell command. That case is fairly obvious because the syntax is entirely different. But those things, imo, are fairly non-intuitive, and if we can help people avoid looking up the wrong information, that would be cool. Possibly in a much shrinked manner so it takes as little screen space as possible. But just because we got used to it by making the same mistake until we learnt doesn't mean Unix has to be unfriendly for newcomers.
Re: UPDATE: x11/fvwm3 to 1.0.7
On Sun, Sep 03, 2023 at 08:54:55PM +0200, Ingo Schwarze wrote: > In addition to that, showing the complete list from man -w would > force man(1) to do additional work, slowing down display of the > manual page. When any of the -w, -a, or -k options is given, man(1) > always searches through the whole MANPATH. By contrast, in standard > mode, i.e. without any of these three options, it ends the search > after the first database that returns a match and displays that > match right away. For example, if you type "man printf", only the > base system manual page database is inspected and you do not have to How much work is that actually ? I mean with the current database system if you just say "man something" it ought to be fairly quick, no ? (especially with just 3 databases)
automatic inclusion of dist-tuples
Tricky part was to figure out where to put it. I won't change the
old CONFIGURE_STYLE stuff because it's unlikely to be needed anymore,
but putting the check inside modules.port.mk means that other modules
can just define GH_TUPLE* and everything should work like a charm
Okay ?
Index: modules.port.mk
===
RCS file: /cvs/ports/infrastructure/mk/modules.port.mk,v
retrieving revision 1.14
diff -u -p -r1.14 modules.port.mk
--- modules.port.mk 22 Aug 2017 10:27:33 - 1.14
+++ modules.port.mk 2 Sep 2023 17:57:19 -
@@ -37,6 +37,10 @@ COMPILER_LANGS ?= c c++
_COMPILER=compiler
.endif
+.if defined(DIST_TUPLE) || defined(DIST_TUPLE_MV) && empty(MODULES:Mdist-tuple)
+MODULES += dist-tuple
+.endif
+
.for _m in ${_COMPILER} ${MODULES:L}
. if "${_m:M*/*}" != ""
.for _d in ${PORTSDIR_PATH:S/:/ /g}
Re: UPDATE: x11/fvwm3 to 1.0.7
On Thu, Aug 31, 2023 at 11:20:17PM +0200, Ingo Schwarze wrote: > Hi Stefan, > > Stefan Hagen wrote on Wed, Aug 30, 2023 at 09:41:20AM +0200: > > > There's no good way to handle a conflict that's introduced with an > > update. So what we would do is to move the manpages into the install > > directory. (thanks to espie@ for the suggestion) > > Actually, i regard that as bad advice, espie@ shouldn't say such things. I don't know. The ability of install versioned manpages for the same software doesn't seem to be a bad idea to me. And /etc/man.conf does feature new default paths, so why not ? If adding new directories isn't the right level, maybe new sections ? or explicit versionned stuff. Yeah, we've installed several versions of tcl for a long time. Oh, and man has a "-a" option to display ALL manual pages. We have currently ZERO mechanism to desambiguate anything outside of sections... if you say, man foo, it will give you the first foo, not even hinting there might be a second food behind it. Yeah, we can rename stuff so that man doesn't get confused, but why does man get confused in the first place ?
Re: zap unused _MODQT*_PKGMATCH to fix make show=... error
On Fri, Sep 01, 2023 at 07:05:35PM +, Klemens Nanni wrote: > On Fri, Sep 01, 2023 at 04:40:24PM +, Klemens Nanni wrote: > > $ make show=PKGNAME > > : not found > > *** Warning in /p/net/tdesktop: "" returned non-zero status > > (/usr/ports/x11/qt6/qt6.port.mk:60) > > tdesktop-4.9.4 > > > > Same error for any other qt6 port, qt6 only differs in file:line. > > > > First time I see those errors, so I suspect a recent change unearthed > > them, but I couldn't find anything in the logs. > > > > != expands and passes the output (empty string) to sh(1), which makes no > > sense to me; nothing I can see uses theses variables, so remove them. > > > > Am I missing something? > > OK? > > espie's recent change to make(1) causes this, which seems like an > improvement. > Indeeed. Lol
Re: UPDATE: x11/fvwm3 to 1.0.7
I wanted to say, no support in pkg_add for suddenly conflicting packages after an update is by design: there is no way this can't be seen as anything but a regression. Imagine: you install packages A and B, you go to update them, and suddenly the new versions conflict. The supported cases are classic cases of upstream fiddling with their bits, like for instance the new B is a merge of the old A and B. But anything else will require manual intervention: if the conflict is genuine, the user will have to make a choice. There are several cases where maintainers should be able to do something smart: - the conflict is accidental. Some peripheral files have the same names, which is usually fixed by either renaming/removing the extra files. - the conflicting files are the exact same thing in both packages... which means there is a common small package to build containing the files in question, and making both new packages depending on those common files will be enough. - one of the new packages suddenly provides the services of the other package "on the side", in a slightly different way. That's a perfect scenario for MULTI_PACKAGES obviously. In the case at hand, fvwm2 vs fvwm3, there are genuine use cases for wanting both: fvwm2 and fvwm3 are slightly tricky beasts, and I have BOTH installed on my machines at the same time, because I run into regression once in a blue moon. The main files do not conflict. Versioning the manpages will work. Note that we routinely do much much worse in order to be able to install, say, 10 versions of autoconf at the same time. Tl;dr: there is no tooling solution because it's not a tooling problem. There is some genuine human thought required to give us something that's not a crazy design.
MODULES: some documentation is needed!
According to port-modules, variables starting with MOD* are public, so
should get documented, SOONER RATHER THAN LATER.
With the recent make's .VARIABLES addition, bsd.port.mk's dump-vars has
gained some introspection capabilities. -current sqlports contains a
list of all public module variable values (which is a bit large, and that
I'm trying to shrink)
So far, the only "big" variables are:
MODGO_pre-configure
MODGO_SETUP_WORKSPACE
MODCARGO_post-extract
MODCARGO_post-patch
MODCABAL_post-extract
MODGO_MODULES
MODGO_MODFILES
as reported by
select distinct(VarName) from ModulesVar where length(value)>5;
we do know that the manifest for go modules is crazy, and bleeds into
MODGO_SETUP_WORKSPACE
the cargo stuff seems to come from the loops on MODCARGO_CRATES.
It can probably be shortened by building a single list of
${_cratename}-${_cratever} and using that in the various targets.
Likewise, MODCABAL_post-extract can be halved fairly easily (haven't addressed
that yet)
Those are valuable changes. Even though make(1) is fairly efficient,
building variables thru .for loops happen for *every invocation* of make.
You don't get any lazyness points for that... and the manifests for those
languages tend to be fairly daunting !
[specifically, using one single .for loop to build one single variable,
and then deriving other variables from that will be more efficient: keep in
mind that basic variable assignment is lazy and won't be evaluated until the
actual target is run, as opposed to basic stuff like "make clean" which has
to evaluate ALL FOR LOOPS each and every time]
The list of all public variable names follows.
Anything NOT documented should be.
MODCABAL_BUILD_ARGS
MODCABAL_BUILD_TARGET
MODCABAL_BUILT_EXECUTABLE_alex
MODCABAL_BUILT_EXECUTABLE_cabal-bundler
MODCABAL_BUILT_EXECUTABLE_cpphs
MODCABAL_BUILT_EXECUTABLE_darcs
MODCABAL_BUILT_EXECUTABLE_git-annex
MODCABAL_BUILT_EXECUTABLE_happy
MODCABAL_BUILT_EXECUTABLE_hasktags
MODCABAL_BUILT_EXECUTABLE_hledger
MODCABAL_BUILT_EXECUTABLE_pandoc
MODCABAL_BUILT_EXECUTABLE_shellcheck
MODCABAL_BUILT_EXECUTABLE_xmobar
MODCABAL_BUILT_EXECUTABLE_xmonad
MODCABAL_DATA_DIR
MODCABAL_EXECUTABLES
MODCABAL_FLAGS
MODCABAL_INSTALL_TARGET
MODCABAL_MANIFEST
MODCABAL_REVISION
MODCABAL_STEM
MODCABAL_VERSION
MODCABAL_post-extract
MODCARGO_BUILD
MODCARGO_BUILDDEP
MODCARGO_BUILD_ARGS
MODCARGO_BUILD_DEPENDS
MODCARGO_BUILD_TARGET
MODCARGO_CARGOTOML
MODCARGO_CARGO_BIN
MODCARGO_CARGO_RUN
MODCARGO_CARGO_UPDATE
MODCARGO_CRATES
MODCARGO_CRATES_BUILDDEP
MODCARGO_CRATES_KEEP
MODCARGO_CRATES_UPDATE
MODCARGO_DIST_SUBDIR
MODCARGO_ENV
MODCARGO_FEATURES
MODCARGO_INSTALL
MODCARGO_INSTALL_ARGS
MODCARGO_INSTALL_TARGET
MODCARGO_INSTALL_TARGET_PATH
MODCARGO_MASTER_SITESN
MODCARGO_NO_DEFAULT_FEATURES
MODCARGO_RUSTFLAGS
MODCARGO_TARGET_DIR
MODCARGO_TEST
MODCARGO_TEST_ARGS
MODCARGO_TEST_TARGET
MODCARGO_VENDOR_DIR
MODCARGO_WANTLIB
MODCARGO_configure
MODCARGO_post-extract
MODCARGO_post-patch
MODCLANG_ARCHS
MODCLANG_CPPWANTLIB
MODCLANG_LANGS
MODCLANG_VERSION
MODCMAKE_BUILD_SUFFIX
MODCMAKE_BUILD_TARGET
MODCMAKE_DEBUG
MODCMAKE_INSTALL_TARGET
MODCMAKE_LDFLAGS
MODCMAKE_TEST_TARGET
MODCMAKE_USE_SHARED_LIBS
MODCMAKE_VERBOSE
MODCMAKE_WANTCOLOR
MODCMAKE_configure
MODCPAN_EG_DIR
MODCPAN_EXAMPLES
MODCPAN_EXAMPLES_DIR
MODCPAN_EXAMPLES_DIST
MODCPAN_POST_INSTALL
MODDCONF_BUILD_DEPENDS
MODDCONF_RUN_DEPENDS
MODERLANG_post-extract
MODERLANG_post-patch
MODFONT_do-install
MODFORTRAN_BUILD_DEPENDS
MODFORTRAN_COMPILER
MODFORTRAN_LIB_DEPENDS
MODFORTRAN_WANTLIB
MODGCC4STDCPP
MODGCC4_ARCHS
MODGCC4_ATOMICWANTLIB
MODGCC4_CPPDEP
MODGCC4_CPPLIBDEP
MODGCC4_CPPWANTLIB
MODGCC4_FORTRANDEP
MODGCC4_FORTRANLIBDEP
MODGCC4_FORTRANWANTLIB
MODGCC4_LANGS
MODGCC4_VERSION
MODGCONF2_BUILD_DEPENDS
MODGCONF2_LIBDEP
MODGCONF2_LIB_DEPENDS
MODGCONF2_RUN_DEPENDS
MODGCONF2_SCHEMAS_DIR
MODGCONF2_WANTLIB
MODGCONF2_post-patch
MODGNOME_BUILD_DEPENDS
MODGNOME_CONFIGURE_ARGS_gi
MODGNOME_CONFIGURE_ARGS_vala
MODGNOME_CPPFLAGS
MODGNOME_LDFLAGS
MODGNOME_RUN_DEPENDS
MODGNOME_TOOLS
MODGNOME_pre-configure
MODGNUSTEP_IS_FRAMEWORK
MODGNUSTEP_LIB_DEPENDS
MODGNUSTEP_NEEDS_BACK
MODGNUSTEP_NEEDS_BASE
MODGNUSTEP_NEEDS_C
MODGNUSTEP_NEEDS_GUI
MODGNUSTEP_RUN_DEPENDS
MODGNUSTEP_WANTLIB
MODGNU_AUTOCONF_DEPENDS
MODGNU_AUTOMAKE_DEPENDS
MODGNU_CONFIG_GUESS_DIRS
MODGNU_SAVE_CACHE
MODGNU_SAVE_CACHE_LOCATION
MODGNU_SHARED_LIBS
MODGNU_configure
MODGNU_gen
MODGO_BINDIR
MODGO_BUILDDEP
MODGO_BUILD_CMD
MODGO_BUILD_DEPENDS
MODGO_BUILD_TARGET
MODGO_CMD
MODGO_DIST_SUBDIR
MODGO_FLAGS
MODGO_GO111MODULE
MODGO_GOCACHE
MODGO_GOPATH
MODGO_INSTALL_TARGET
MODGO_LDFLAGS
MODGO_LIST_CMD
MODGO_MODFILES
MODGO_MODNAME
MODGO_MODNAME_ESC
MODGO_MODULES
MODGO_PACKAGES
MODGO_PACKAGE_PATH
MODGO_RUN_DEPENDS
MODGO_SETUP_WORKSPACE
MODGO_SOURCES
MODGO_SUBDIR
MODGO_TEST_CMD
MODGO_TEST_FLAGS
MODGO_TEST_TARGET
MODGO_TOOLS
MODGO_TYPE
MODGO_VERSION
MODGO_WORKSPACE
MODGO_pre-configure
MODHEIMDAL_LIB_DEPENDS
MODHEIMDAL_WANTLIB
MODHEIMDAL_post-patch
MODIMAKE_DEPENDS
MODIMAKE_configure
MODINTLTOOL_OVERRIDE
MODJAVA_
PATCH: go.port.mk
This switches stuff over to DISTFILES.go
Also, factorize files in a slightly more efficient way, this makes
MODGO_SETUP_WORKSPACE significantly smaller (by about 30% or so)
Index: go.port.mk
===
RCS file: /cvs/ports/lang/go/go.port.mk,v
retrieving revision 1.58
diff -u -p -r1.58 go.port.mk
--- go.port.mk 11 Aug 2023 15:23:44 - 1.58
+++ go.port.mk 23 Aug 2023 10:20:05 -
@@ -10,8 +10,7 @@ MODGO_DIST_SUBDIR ?= go_modules
MASTER_SITE_ATHENS = https://proxy.golang.org/
-MODGO_MASTER_SITESN = 9
-MASTER_SITES${MODGO_MASTER_SITESN} ?= ${MASTER_SITE_ATHENS}
+MASTER_SITES.go ?= ${MASTER_SITE_ATHENS}
MODGO_RUN_DEPENDS =lang/go
MODGO_BUILD_DEPENDS = lang/go
@@ -79,13 +78,15 @@ DISTFILES +=${DISTNAME_ESC}{${MODGO_VE
EXTRACT_ONLY +=${DISTNAME_ESC}${EXTRACT_SUFX}
MASTER_SITES ?=${MASTER_SITE_ATHENS}${MODGO_MODNAME_ESC}/@v/
. for _modpath _modver in ${MODGO_MODULES}
-DISTFILES +=
${MODGO_DIST_SUBDIR}/{}${_modpath}/@v/${_modver}.zip:${MODGO_MASTER_SITESN}
-_MODGO_SETUP_ZIP +=${_modpath}/@v/${_modver}
+DISTFILES.go +=${MODGO_DIST_SUBDIR}/{}${_modpath}/@v/${_modver}.zip
+DISTFILES.go +=${MODGO_DIST_SUBDIR}/{}${_modpath}/@v/${_modver}.mod
+_MODGO_SETUP +=${_modpath}/@v/${_modver}.{zip,mod}
. endfor
-. for _modpath _modver in ${MODGO_MODFILES} ${MODGO_MODULES}
-DISTFILES +=
${MODGO_DIST_SUBDIR}/{}${_modpath}/@v/${_modver}.mod:${MODGO_MASTER_SITESN}
-_MODGO_SETUP_MOD +=${_modpath}/@v/${_modver}
+. for _modpath _modver in ${MODGO_MODFILES}
+DISTFILES.go +=${MODGO_DIST_SUBDIR}/{}${_modpath}/@v/${_modver}.mod
+_MODGO_SETUP += ${_modpath}/@v/${_modver}.mod
. endfor
+
MAKE_ENV +=GOPROXY=file://${WRKDIR}/go_modules
MODGO_GO111MODULE ?= on
MAKE_ENV +=GO111MODULE=${MODGO_GO111MODULE}
GOPATH="${MODGO_GOPATH}"
@@ -123,11 +124,9 @@ MODGO_SETUP_WORKSPACE =mkdir -p ${WRKSR
.else
WRKSRC ?= ${WRKDIR}/${MODGO_MODNAME}@${MODGO_VERSION}
MODGO_SETUP_WORKSPACE =ln -sf ${WRKSRC} ${WRKDIR}/${MODGO_MODNAME}; \
- for m in ${_MODGO_SETUP_ZIP}; do \
- ${INSTALL} -D ${DISTDIR}/${MODGO_DIST_SUBDIR}/$$m.zip
${WRKDIR}/${MODGO_DIST_SUBDIR}/$$m.zip; \
- done; \
- for m in ${_MODGO_SETUP_MOD}; do \
- ${INSTALL} -D ${DISTDIR}/${MODGO_DIST_SUBDIR}/$$m.mod
${WRKDIR}/${MODGO_DIST_SUBDIR}/$$m.mod; \
+ cd ${DISTDIR}/${MODGO_DIST_SUBDIR}; \
+ for m in ${_MODGO_SETUP}; do \
+ ${INSTALL} -D $$m ${WRKDIR}/${MODGO_DIST_SUBDIR}/$$m; \
done
.endif
go modules questions
I'm trying to figure out ways to make things shorter, as even the variable names get insanely long. In particular, do we really need long names like go_modules/golang.org/x/tools/@v/v0.0.0-20190907020128-2ca718005c18.mod ? It seems to me that go/golang.org/x/tools/0.0.0-20190907020128-2ca718005c18.mod would be just as descriptive and not lose any information. Any part of the go tooling that actually wants the full name for a distfile ? That little noise doesn't seem like much, but it quickly adds up.
Re: sysutils/seatd doesn't build because of wrong distinfo
On Tue, Aug 22, 2023 at 06:51:12PM +0200, Lorenz (xha) wrote: > hi, > > when trying to build sysutils/seatd, i am getting this error: > > > lorenz@/usr/ports/sysutils/seatd % doas make build > ===> Building from scratch seatd-20230813p0 > > [...] > > ===> Checking files for seatd-20230813p0 > >> No size recorded for seatd-openbsd-20230813.tar.gz > > > this is probably because of a wrong/old distinfo? i ran `make makesum` and > included the patch below, but i am not quite sure if this is correct. it > fixed the problem for me. > > Index: distinfo > === > RCS file: /cvs/ports/sysutils/seatd/distinfo,v > retrieving revision 1.1.1.1 > diff -u -p -r1.1.1.1 distinfo > --- distinfo 13 Aug 2023 08:36:22 - 1.1.1.1 > +++ distinfo 22 Aug 2023 16:17:27 - > @@ -1,2 +1,2 @@ > -SHA256 (seatd-obsd.tar.gz) = ZkPab8XOEjTkLaDjaJB5MUa7ybsLGVvfu0w2NCZX+98= > -SIZE (seatd-obsd.tar.gz) = 39441 > +SHA256 (seatd-openbsd-20230813.tar.gz) = > mw/4GTTgnfi7E5yMIDxH6KqWeYsX+K3VsFxvftDW+9U= > +SIZE (seatd-openbsd-20230813.tar.gz) = 39459 > > That's correct, but you mispelled matthieu. Not sure he's subscribed to ports :)
Re: Ports tree is dead
On Sat, Aug 19, 2023 at 12:23:03PM +0900, lain. wrote: > I just updated my ports tree with "cvs -q up -Pd -A", the usual stuff, > and tried to install net/weechat from the ports, because the one in the > repository is too outdated. > This is the problem: > > ``` > # make install > Fatal: requires make(1) with .VARIABLES support (in net/weechat) > *** Error 1 in /usr/ports/net/weechat > (/usr/ports/infrastructure/mk/bsd.port.mk:3808 '.BEGIN': @exit 1) > ``` Be happy that I added an explicit check to bsd.port.mk itself! Instead of a fairly explicit error message, you would have gotten some really weird errors sooner or later (well sooner rather than later)
Re: Document MODCARGO_WANTLIB
Every public variable should be documented, sooner rather than later. There's often a bit of a delay when fiddling with semantics, but that's no reason for dropping the ball. At most a few weeks, no more.
new DISTFILES* stuff
All the parts have now been committed. Thfr@ will probably finalize his patch for "nicer" github/gitlab/whatever during our next hackathon. As far as things go: bsd.port.mk(5) explains what's going on. If DISTFILES.sufx is set, then MASTER_SITES.sufx will be used. Compared to the "fixed" list of MASTER_SITES0...9, this is indefinite and possibly self-documenting (I've switched go and cargo on my machines, without any issue). The .VARIABLES construct opens a few similar issues. There's no actual hurry, but I hope to deprecate MASTER_SITES0/9 eventually: the new construct is cleaner and the relevant code is way simpler (have a look at the definition of _FULL_FETCH_LIST in bsd.port.mk)
Re: HEADS-UP: DISTFILES changes
On Mon, Aug 14, 2023 at 08:33:19PM +0200, Marc Espie wrote: > DISTFILES.sufx = somefile > which will match with MASTER_SITES.sufx IMPORTANT: use simple suffixes, like DISTFILES.go with an actual dot and a combination of letters/digits (without an other dot afterwards) The idea is to have a syntax that's visually very distinct from PKGNAME-sub and also, both dpb and sqlports will not like variables that do not match that pattern.
HEADS-UP: DISTFILES changes
After much discussion with fellow porters, we changes the way DISTFILES + MASTER_SITES work the old way (DISTFILES = somefile:0 to match with MASTER_SITES0) still works but the new way is to write DISTFILES.sufx = somefile which will match with MASTER_SITES.sufx this works identically with SUPDISTFILES/PATCHFILES. In order to work, this requires a recent make(1). bsd.port.mk will error out with a decent error message in this case. dpb(1) and sqlports are aware of the new method. The idea was that MASTER_SITESn was getting cramped and hardcoded for stuff like go, or github. This will allow "arbitrary" allocation of names in order to use several modules concurrently. Basically, a port that uses several files from different locations will no longer require people to provide a local mirror of some of the files because the framework is inflexible. As of now, I would say to not QUITE use it, but keep testing and checking that things didn't break (I did a full bulk with the initial bsd.port.mk change) sqlports is slightly affected: since there are umpteen DISTFILES* SUPDISTFILES* PATCHFILES* MASTER_SITES* variables, they no longer live in the main ports view, but instead in the various _Distfiles, _fetchfiles tables or the corresponding views (I've kept the main DISTFILES without a sufx variables inside the main view... that's still 99% of the ports) Eventually, if things work as planned, I hope to kill MASTER_SITES0-9 entirely. The new way is actually less boilerplace code !
Re: bsd.port.mk: check wxallowed after extract not patch
On Sun, Aug 06, 2023 at 12:06:22PM +, Klemens Nanni wrote: > On Tue, Aug 01, 2023 at 11:17:48AM +0200, Sebastien Marie wrote: > > On Mon, Jul 31, 2023 at 10:17:05PM +, Klemens Nanni wrote: > > > 'make patch' on a WXNEEDED=Yes port without wxallowed fails after > > > patching and before creating the patch cookie, so subsequent setting > > > of the option and rerunning the target will try to patch again. > > > > > > If the check is done right after extract, rerunning that target usually > > > has higher chances of just working. > > > > > > Is there a reason I'm not aware of that this is done after patch? > > > > > > > > > I just forgot to set wxallowed on /usr/ports/pobj when building > > > ungoogled-chromium where 'make clean && mount ... && make patch' takes > > > considerably longer than 'mount ... && make extract' to recover from > > > forgetting to set wxallowed. > > > > Personally, having it in extract step might be not convenient as extracting > > will > > require 'wxallowed', even if I just want to extract to look at source code. > > Good point. > > > Ideally, I would put such control code at start of 'configure' step. > > Doesn't "gen" also run GNU auto* which potentially needs wxallowed? > That's why I have moved it there now. > > Either way, making the check the first step of a target instead needs > its own target so that PORTS_PRIVSEP=Yes stays in effect. > > post-* or *-finalize where the first diff put it do not need that, as > they're already run as _pbuild. > > Does that still work for everyone's favourite USE_WXNEEDED=Yes workflow > without breaking other stuff, when you forget to set wxallowed? If I recall correctly, adding USE_WXNEEDED predates the gen step by some time, so it might be good there days.
Re: web-eid-app-chrome: support iridium
On Fri, Jul 28, 2023 at 03:16:53PM +, Klemens Nanni wrote: > On Fri, Jul 28, 2023 at 12:18:16PM +, Klemens Nanni wrote: > > On Tue, Jul 25, 2023 at 05:06:35PM +, Klemens Nanni wrote: > > > On Tue, Jul 25, 2023 at 04:42:10PM +, Klemens Nanni wrote: > > > > After one of the recent www/iridum updates, the extension/native host > > > > now > > > > works there just like it does with www/chromium. > > > > > > > > Is this the right way to depend on either chromium or iridium? > > > > The way I understand this: use either iridium-* or chromium-* if > > > > installed, > > > > otherwise install www/chromium to satisfy the runtime dependency. > > espie explained to me that this is how it is intended to work, but... > > > > > > Not in practise, as I can't uninstall chromium when iridium is > > > installed: > > we have no code yet for these uninstall/replace paths, so using variant > dependencies, does not seem useful to me until these bits are implemented. To be fair, most alternates dependencies do conflict, and the bits involved work just fine with pkg_add -r. The *idea* of differing runtime dependencies is actually fairly rare.
Re: pkg_create: Can't call method "p" on an undefined value
On Thu, Jul 20, 2023 at 05:49:19PM +0200, Matthias Schmidt wrote: > Hi, > > * Stuart Henderson wrote: > > You're missing the version number in DISTNAME. > > Thanks, that ideed did the trick. Nevertheless, the error message is > not very informative and I couldn't have solved that on my own. > > Cheers > > Matthias > > There are so many failure cases, sometimes some fall through the crack. (the uninformative error message is obviously NOT intentional)
Re: lang/gambit build parallel
Actually, I should have documented the current reality ages ago. (Or replace "jobs" with "direct children" ?) The reference pointing to recursive behavior should be there regardless. Index: make.1 === RCS file: /cvs/src/usr.bin/make/make.1,v retrieving revision 1.139 diff -u -p -r1.139 make.1 --- make.1 17 Jan 2023 13:03:22 - 1.139 +++ make.1 8 Jul 2023 13:34:35 - @@ -44,7 +44,7 @@ .Op Fl d Ar flags .Op Fl f Ar mk .Op Fl I Ar directory -.Op Fl j Ar max_processes +.Op Fl j Ar max_jobs .Op Fl m Ar directory .Op Fl V Ar variable .Op Ar NAME Ns = Ns Ar value ... @@ -154,7 +154,7 @@ Extended options are as follows: Try to be backwards compatible by executing the commands to make the prerequisites in a target rule in sequence. This is the default, in the absence of -.Fl j Ar max_processes . +.Fl j Ar max_jobs . .It Fl C Ar directory Enter .Ar directory @@ -241,10 +241,12 @@ Multiple directories can be added to for Furthermore, the system include path (see the .Fl m option) will be used after this search path. -.It Fl j Ar max_processes -Specify the maximum number of processes that +.It Fl j Ar max_jobs +Specify the maximum number of jobs that .Nm may have running at any one time. +See the discussion about recursive invocations under +.Sx BUGS . .It Fl m Ar directory Specify a directory in which to search for system include files: .Pa sys.mk
dpb: draft idea for later
So I have a few options that take pkgpath lists in dpb. There might be reasons to have more or... maybe just have a list "on the side" of supplementary information to add to the ports tree proper. Like "don't clean this pkgpath, I want to look at the wrkdir anyway" or "don't build that path even if I do a full bulk, it takes too long". or "don't try building that specific flavor, it's broken and will hold the rest" Yeah, we can tweak the ports tree proper, BUT it's usually inconvenient, especially as diffs to maintain, What do people think ? If I do this, it would be some kind of "adjunct" list with properties. Does it seem to be "good enough" to work with ?
Re: distfiles signature checking
On Fri, Jul 07, 2023 at 04:07:31PM +0200, Jeremie Courreges-Anglas wrote: > I'm not completely sold on zapping CHECK_PGPSIG, and using a specific > make target, instead of handling this in make checksum. Using the > checksum target would be more strict I guess. Depends who you're targetting. Assuming the guy updating the port is doing the check, and thus making it easy in "make makesum" would have some kind of purpose. I'm pretty sure wacky shitz like signing something that's not the actual tgz deserves special treatment. If anything, talk to upstream so that they have somewhat standard behavior. There's some kind of chicken-and-egg: anything that gets (normally) downloaded is in distfile/supdistfiles. If you're checking signatures on a dpb capable box, how do you make sure the asc files don't get removed ? they have to be in history (like SUPDISTFILES). So, figure out the best workflow... checksum or makesum ? sha256 for .asc files as well ? put them in SUPDISTFILES ?
Re: distfiles signature checking (was: Re: new benchmarks/splicebench)
On Thu, Jul 06, 2023 at 05:49:04PM +0200, Jeremie Courreges-Anglas wrote: > On Thu, Jul 06 2023, Stuart Henderson wrote: > > On 2023/07/05 21:21, Jeremie Courreges-Anglas wrote: > >> On Wed, Jul 05 2023, Alexander Bluhm wrote: > >> > On Wed, Jul 05, 2023 at 05:35:01PM +0200, Jeremie Courreges-Anglas wrote: > >> >> On Tue, Jul 04 2023, Alexander Bluhm wrote: > >> >> > Hi, > >> >> > > >> >> > ok to import splicebench-1.02 ? > >> >> > >> >> At first I got puzzled by SUPDISTFILES but gofor it if you find it > >> >> useful. > >> > > >> > If upstream provides a gpg signature, I download it and check it. > >> > Although it is not perfect to prevent backdoors, I would feel very > >> > bad, if I would commit a tampered port that could be detected by a > >> > signature. > >> > > >> > Downloading the detached signature as SUPDISTFILES makes it easy > >> > to verify manually. > >> > > >> > Any better idea to prevent supply chain attacks? > >> > >> I'm not objecting to the rationale, I also check signatures whenever > >> I can. This reminds me of a proposal from Stuart which I liked a lot > >> but I haven't pushed for... until now: > >> > >> https://marc.info/?l=openbsd-ports&m=157687699320320&w=2 > > > > I lost interest when it turned into a load mkre complication and a new > > tool to verify pgp signatures that would only run on certain archs > > and reverted to my previous method, "stick a shell script in the port > > directory that will download and check the signature when run by hand". > > Your original approach looked good to me. Was the additional > complexity warranted by security or usability concerns? > > You mention a "new tool", I would prefer if we kept using security/gnupg > instead of some go/rust program, precisely for portability reasons. > > -- > jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF DDCC 0DFA 74AE 1524 E7EE > > Looking at sthen's patch. How verbose is gnu-gpg ? Specifically, is the "signature failed message" enough to identify which file failed. I'm not too sure about the BUILD_DEPENDS: gnupg has got a lot of dependencies. I see the distinct possibility of build loops if CHECK_PGPSIG was set indiscriminately in mk.conf. Is there any kind of minimal build of gnupg that could be useful without the gazillion dependencies ?
dpb: fix % in case of "clean builds"
Following some remark from matthieu, since we now can distinguish
clean builds from unclean builds, we can reset the pos marker in such
a case.
Of course, since this happens at the end of a task, this only changes
the display *after* the first step, but this is what matters, really,
since we don't really care about the % display for quick building ports.
(and of course, we lose all benefits if it breaks and we restart again
without cleaning anything, but we're one step away from a demogorgon at
this point)
Thoroughly untested, waiting for my bulk to finish.
Index: Clock.pm
===
RCS file: /cvs/ports/infrastructure/lib/DPB/Clock.pm,v
retrieving revision 1.20
diff -u -p -r1.20 Clock.pm
--- Clock.pm6 Jun 2023 08:09:13 - 1.20
+++ Clock.pm7 Jul 2023 08:50:36 -
@@ -166,6 +166,11 @@ sub reset_offset($self)
}
}
+sub set_offset($self, $pos)
+{
+ $self->{offset} = $pos;
+}
+
sub stopped_clock($self, $gap, $)
{
$self->{time} += $gap if defined $self->{time};
Index: Job/Port.pm
===
RCS file: /cvs/ports/infrastructure/lib/DPB/Job/Port.pm,v
retrieving revision 1.212
diff -u -p -r1.212 Port.pm
--- Job/Port.pm 21 Jun 2023 08:56:17 - 1.212
+++ Job/Port.pm 7 Jul 2023 08:50:36 -
@@ -62,6 +62,10 @@ sub finalize($self, $core)
last if !defined $l;
if ($l =~ m/^\=\=\=\>\s+Building from scratch/)
{
$job->{fromscratch} = $i;
+ if (defined $job->{watched}) {
+ $job->{watched}->set_offset(
+ $job->{pos});
+ }
last;
}
}
Re: [update] graphics/krita-gmic-plugin 3.1.6.1 to 3.2.1.1
On Wed, Jul 05, 2023 at 08:27:50AM +0200, Stefan Hagen wrote: > *ping* > > Stefan Hagen wrote (2023-05-07 16:42 CEST): > > Hi, > > > > this is an update to the krita gmic plugin for the gmic version 3.2.1. > > > > There's no changelog for the plugin itself. But this repo is used to > > develop the plugin: > > https://github.com/amyspark/gmic/compare/v3.1.6.1...v3.2.1.1 > > > > I added post-configure bits to build the translation files. Otherwise the > > build fails. > > > > Comments / OKs? > > > > Best Regards, > > Stefan > > Same diff again for convenience I'm really annoyed at gmic changing their build system to some arcane gnu make stupidity. I would really love for someone to tackle that.
Re: cmake musing
Oh actually we don't even need that... :ON/:OFF are implied, I think,
looking at various cmake parts.
On Thu, Jul 6, 2023 at 11:11 AM Marc Espie wrote:
>
> Thanks to ian for prodding.
>
> What do people think of automatically adding BOOL where needed in
> CMAKE_ARGS, something along the lines of the following construct:
>
> ARGS=-DFLAG1=ON -DFLAG2:BOOL=ON -DFLAG3=ON -DFLAG4=OFF
>
> test:
> echo ${ARGS:S/=ON/:BOOL=ON/g:S/=OFF/:BOOL=OFF/g:S/:BOOL:BOOL/:BOOL/g}
>
>
cmake musing
Thanks to ian for prodding.
What do people think of automatically adding BOOL where needed in
CMAKE_ARGS, something along the lines of the following construct:
ARGS=-DFLAG1=ON -DFLAG2:BOOL=ON -DFLAG3=ON -DFLAG4=OFF
test:
echo ${ARGS:S/=ON/:BOOL=ON/g:S/=OFF/:BOOL=OFF/g:S/:BOOL:BOOL/:BOOL/g}
Re: math/mlpack build parallel
On Thu, Jul 06, 2023 at 10:12:56AM +0200, Peter Hessler wrote: > Hi, > > This package takes quite a while to build, so I marked it as parallel to > use more CPUs. > > I've been running this on the arm64 bulk build cluster for about a month > now. > > OK? > > > Index: math/mlpack/Makefile > === > RCS file: /cvs/ports/math/mlpack/Makefile,v > retrieving revision 1.25 > diff -u -p -u -p -r1.25 Makefile > --- math/mlpack/Makefile 13 Nov 2022 15:28:44 - 1.25 > +++ math/mlpack/Makefile 9 Jun 2023 15:14:11 - > @@ -4,6 +4,7 @@ BROKEN-sparc64 = Exhausts virtual memory > > COMMENT-main =C++ machine learning library > COMMENT-python = python bindings to C++ machine learning library > +DPB_PROPERTIES = parallel > > V = 3.4.2 > > > -peter > > > -- > Schlattwhapper, n.: > The window shade that allows itself to be pulled down, > hesitates for a second, then snaps up in your face. > -- Rich Hall, "Sniglets" > Okay
BROKEN: archivers/libzim hidden dependency
Will happily pick up gtest if available, and crash if it gets junked during the build >>> Building on verycloudy2 under archivers/libzim BDEPENDS = [archivers/xz;databases/xapian-core;devel/meson;archivers/zstd;textproc/icu4c] DIST = [archivers/libzim:libzim-8.1.1.tar.xz] FULLPKGNAME = libzim-8.1.1 RDEPENDS = [archivers/zstd;databases/xapian-core;archivers/xz;textproc/icu4c] Woken up graphics/p5-Imager (Junk lock failure for verycloudy2 at 1688623917.80251) Received IO (Junk lock obtained for verycloudy2 at 1688623947.69) Woken up archivers/libzim Short-cut: depends already handled by graphics/p5-Imager >>> Running show-prepare-results in archivers/libzim at 1688623948.49 ===> archivers/libzim ===> Building from scratch libzim-8.1.1 ===> libzim-8.1.1 depends on: meson->=1.1.1v0 -> meson-1.1.1v0 ===> libzim-8.1.1 depends on: xz->=5.4.0 -> xz-5.4.3 ===> libzim-8.1.1 depends on: xz-* -> xz-5.4.3 ===> libzim-8.1.1 depends on: zstd-* -> zstd-1.5.5 ===> libzim-8.1.1 depends on: xapian-core-* -> xapian-core-1.4.22 ===> libzim-8.1.1 depends on: icu4c-* -> icu4c-73.2v0 ===> Verifying specs: c++ c++abi pthread icui18n icuuc lzma xapian zstd ===> found c++.9.0 c++abi.6.0 pthread.27.0 icui18n.22.1 icuuc.22.1 lzma.2.2 xapian.5.2 zstd.6.3 icu4c-73.2v0 meson-1.1.1v0 xapian-core-1.4.22 xz-5.4.3 zstd-1.5.5 (Junk lock released for verycloudy2 at 1688623950.66) Woken up multimedia/svt-av1 distfiles size=192712 >>> Running extract in archivers/libzim at 1688623950.68 ===> archivers/libzim ===> Checking files for libzim-8.1.1 `/usr/ports/distfiles/libzim-8.1.1.tar.xz' is up to date. ===> Extracting for libzim-8.1.1 >>> Running patch in archivers/libzim at 1688623951.21 ===> archivers/libzim ===> Patching for libzim-8.1.1 ===> Compiler link: clang -> /usr/bin/clang ===> Compiler link: clang++ -> /usr/bin/clang++ ===> Compiler link: cc -> /usr/bin/cc ===> Compiler link: c++ -> /usr/bin/c++ >>> Running configure in archivers/libzim at 1688623951.54 ===> archivers/libzim ===> Generating configure for libzim-8.1.1 ===> Configuring for libzim-8.1.1 The Meson build system Version: 1.1.1 Source dir: /pobj/libzim-8.1.1/libzim-8.1.1 Build dir: /pobj/libzim-8.1.1/build-amd64 Build type: native build Project name: libzim Project version: 8.1.1 C compiler for the host machine: cc (clang 13.0.0 "OpenBSD clang version 13.0.0") C linker for the host machine: cc ld.lld 13.0.0 C++ compiler for the host machine: c++ (clang 13.0.0 "OpenBSD clang version 13.0.0") C++ linker for the host machine: c++ ld.lld 13.0.0 Host machine cpu family: x86_64 Host machine cpu: x86_64 Checking for size of "off_t" : 8 Checking for size of "size_t" : 8 Found pkg-config: /usr/bin/pkg-config (0.29.2) Run-time dependency liblzma found: YES 5.4.3 Run-time dependency libzstd found: YES 1.5.5 Run-time dependency xapian-core found: YES 1.4.22 Run-time dependency icu-i18n found: YES 73.2 Run-time dependency GTest found: YES 1.11.0 Configuring zim_config.h using configuration Program libzim-compile-resources found: YES (/pobj/libzim-8.1.1/libzim-8.1.1/scripts/libzim-compile-resources) Program download_test_data.py found: YES (/pobj/libzim-8.1.1/libzim-8.1.1/scripts/download_test_data.py) Configuring config.h using configuration Build targets in project: 33 libzim 8.1.1 User defined options auto_features : enabled buildtype : plain localstatedir : /var mandir: /usr/local/man prefix: /usr/local sharedstatedir: /var/db strip : True sysconfdir: /etc wrap_mode : nodownload Found ninja-1.11.1 at /usr/local/bin/ninja >>> Running build in archivers/libzim at 1688623964.71 ===> archivers/libzim ===> Building for libzim-8.1.1 exec /usr/bin/env -i LC_CTYPE="en_US.UTF-8" PORTSDIR="/usr/ports" LIBTOOL="/usr/bin/libtool" LIBzim_LTVERSION='-version-info 0:0:0' libzim_ltversion=0.0 PATH='/pobj/libzim-8.1.1/bin:/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin:/usr/X11R6/bin' PREFIX='/usr/local' LOCALBASE='/usr/local' X11BASE='/usr/X11R6' CFLAGS='-O2 -pipe' TRUEPREFIX='/usr/local' DESTDIR='' HOME='/libzim-8.1.1_writes_to_HOME' PICFLAG="-fpic" BINGRP=bin BINOWN=root BINMODE=755 NONBINMODE=644 DIRMODE=755 INSTALL_COPY=-c INSTALL_STRIP=-s MANGRP=bin MANOWN=root MANMODE=644 BSD_INSTALL_PROGRAM="/pobj/libzim-8.1.1/bin/install -c -s -m 755" BSD_INSTALL_SCRIPT="/pobj/libzim-8.1.1/bin/install -c -m 755" BSD_INSTALL_DATA="/pobj/libzim-8.1.1/bin/install -c -m 644" BSD_INSTALL_MAN="/pobj/libzim-8.1.1/bin/install -c -m 644" BSD_INSTALL_PROGRAM_DIR="/pobj/libzim-8.1.1/bin/install -d -m 755" BSD_INSTALL_SCRIPT_DIR="/pobj/libzim-8.1.1/bin/install -d -m 755" BSD_INSTALL_DATA_DIR="/pobj/libzim-8.1.1/bin/install -d -m 755" BSD_INSTALL_MAN_DIR="/pobj/libzim-8.1.1/bin/install -d -m 755" /usr/local/bin/meson compile -C /pobj/libzim-8.1.1/build-amd64 -v -j 1 ninja: Entering directory `/pobj/libzim-8.1.1/build-amd64' [1/133] /pobj/libzim-8.1.1/libzim-8
Re: NEW: devel/cereal serialization header library
On Tue, Jul 04, 2023 at 03:20:41AM -0400, Ian Darwin wrote: > Descr: > Cereal is a header-only C++11 serialization library. It takes > arbitrary data types and reversibly turns them into different > representations, such as compact binary encodings, XML, or JSON. > Cereal was designed to be fast, light-weight, and easy to extend - > it has no external dependencies and can be easily bundled with > other code or used standalone. Note that perl has support for cereal, used by Devel::Cover among other things. So you can probably test a bit of interoperability with it.
Re: lang/* BTI breakage
On Mon, Jul 03, 2023 at 12:11:09AM +0200, Christian Weisgerber wrote: > lang/ocaml > > I guess for ocaml the big hammer would be to disable native code > compilation altogether and fall back to bytecode. How far behind are we on ocaml code releases ? Considering the people writing the language, I'm a bit surprised bti isn't on their list to support natively.
Re: make lib-depends-check failure on x11/xscope
On Sun, Jun 18, 2023 at 10:44:42AM +0200, Matthieu Herrb wrote:
> Hi,
>
> Looks like something broken with recent perl use 2.36 code :
>
>
> cd /usr/ports/x11/xscope
> make package
> make lib-depends-check
> Scanning|*|100%Can't
> call forget on OpenBSD::PackingList at
> /usr/libdata/perl5/OpenBSD/PackingList.pm line 90.
> *** Error 1 in /share/OpenBSD/ports/x11/xscope
> (/share/OpenBSD/ports/infrastructure/mk/bsd.port.mk:2454 'lib-depends-check':
> @case X${_DEPEN...)
> Exit 2
Fixed
Re: remove diffpp from enscript
On Sat, Jun 17, 2023 at 10:42:39AM +0200, Jan Stary wrote:
> $ diffpp /tmp/foo
> Assigning non-zero to $[ is no longer possible at /usr/local/bin/diffpp line
> 72.
>
> Apparently, the diffpp(1) of print/enscript
> has been broken for years and nobody noticed.
> Is anyone using that?
>
> Jan
Alternately, you could fix it.
There are exactly 4 array dereferences that follow $[
Mechanically substracting 1 in each location does the trick
Index: Makefile
===
RCS file: /cvs/ports/print/enscript/Makefile,v
retrieving revision 1.38
diff -u -p -r1.38 Makefile
--- Makefile11 Mar 2022 19:50:59 - 1.38
+++ Makefile17 Jun 2023 21:30:21 -
@@ -2,7 +2,7 @@ COMMENT=convert ASCII files to PostScr
DISTNAME= enscript-1.6.6
CATEGORIES=print
-REVISION= 2
+REVISION= 3
HOMEPAGE= https://www.gnu.org/software/enscript/
Index: patches/patch-scripts_diffpp_in
===
RCS file: patches/patch-scripts_diffpp_in
diff -N patches/patch-scripts_diffpp_in
--- /dev/null 1 Jan 1970 00:00:00 -
+++ patches/patch-scripts_diffpp_in 17 Jun 2023 21:30:21 -
@@ -0,0 +1,47 @@
+Index: scripts/diffpp.in
+--- scripts/diffpp.in.orig
scripts/diffpp.in
+@@ -69,7 +69,6 @@ if ($file eq "--version") {
+ open(FP, $file) || die "$program: couldn't open file `$file' for input: $!\n";
+ @orig_file = ;
+ close(FP);
+-$[ = 1;
+ $orig_line_num = 1;
+ $orig_num_lines = @orig_file;
+
+@@ -79,7 +78,7 @@ $diff_line_num = 1;
+ $diff_num_lines = @diffs;
+
+ while ($diff_line_num <= $diff_num_lines) {
+-$_ = $diffs[$diff_line_num];
++$_ = $diffs[$diff_line_num-1];
+ if (/a/) {
+ do_add($_);
+ } elsif (/d/) {
+@@ -90,7 +89,7 @@ while ($diff_line_num <= $diff_num_lines) {
+ }
+
+ while ($orig_line_num <= $orig_num_lines) {
+-print $orig_file[$orig_line_num++];
++print $orig_file[$orig_line_num++-1];
+ }
+
+ # Handle new/added lines
+@@ -175,7 +174,7 @@ sub skip_to_line {
+ ($line) = @_;
+
+ while ($orig_line_num <= $line) {
+- print $orig_file[$orig_line_num];
++ print $orig_file[$orig_line_num-1];
+ $orig_line_num++;
+ }
+ }
+@@ -185,7 +184,7 @@ sub mark_to_line {
+
+ $diff_line_num++; # skip over diff command
+ while ($num_lines > 0) {
+- $diff_line = substr($diffs[$diff_line_num++],3);
++ $diff_line = substr($diffs[$diff_line_num++-1],3);
+ print "\000ps{gsave -5 0 rmoveto ($marker) show grestore}";
+ print $diff_line;
+ $num_lines--;
