-----BEGIN PGP SIGNATURE-----
iQIzBAEBCAAdFiEEiKQfd6o81mjI+LWALell7WOCXJMFAl3jFBEACgkQLell7WOC
XJNMZA//QyuHoDB/7lU//eMGNO4XsTmPKipBOhGkcQeA+Wy4Y9TC+PcCKpnLqFgw
z7zqP2IkKhHhhzJ0MR/LsVu61WWDM9zZbHIXN24Oy44wEZp3jIquF435JMx/F2eX
Hh7shcFm0yZjDxq5QcZlAlnkknFS4QXXkDyqkL+BlkivmgvUOdhIxqcbD5krY8z+
FzVQYrIDsLlT1nF5eW/tweoSrHyHebfSpwSkrMt9YksZPHErDaWbitvnN84BwV+c
oS1syiyt+4JQGT6+zNMmsbJ5h0V+ac0YXw+uV06OV8r/YP50OvpkokPGFHRwaQk9
4P1yuloGODEUFC4jEIDfTuXN1gy5lhXBZrEuEAa/Gn7Jl1OSRX7U3KTYSZH5HVyo
Rq6jAehICVjATnUczoKPhI7CtT8ji2ajTTLFLYfs+23vSXQVcQUMHlIsKIEqabmh
0nIA7XWvzXFKOFkyzHk6EgRFp7fq9txZyiVHXssCvE66HzbciW8n+W2BCk08XkmA
m/kSlZ2dIoszx3nzXWNl0TTc83ZpY49Qr8RRlX1xgUOyUuGfP9MRZVPdCl8Dy8Ut
E/XMuqvMFTXnL+nbq2UtCZTCl+MVkGqYPSXPoqBvB3xfm39ClHqBM/wJYAlQ0Y6z
Ax62nYWGK35/t9AEOy8j/ovkt5O/Y4TA934luAqFOtI/MZCVvts=
=NFbV
-----END PGP SIGNATURE-----
On 11/30/19 1:26 PM, George Koehler wrote:
> On Sat, 30 Nov 2019 01:10:56 -0800
> manphiz@gmail.com wrote:
>
>> Hi OpenBSD ports maintainers,
>>
>> I'm having trouble building security/libnettle on mips64el/loongson
>> which is caused by missing symbol of "__builtin_bswap64" when linking.
>> It looks like this symbol is introduced since GCC 4.3[1], while mips64el
>> ships with GCC 4.2.1. It's interesting because I can compile with the
>> symbol but cannot link. Would like to hear from the ports maintainers'
>> opinion on how to solve this issue?
>
> Bad luck! libnettle uses __builtin_bswap64 only on little-endian
> platforms. My big-endian powerpc/macppc also uses base-gcc 4.2.1 but
> can use the powerpc snapshot package of libnettle.
>
> The configure test for __builtin_bswap64 is wrong. It is a compile
> test, but you got a link error, not a compile error. Here is a diff
> to do a link test. On my powerpc with base-gcc, the compile test
> passed but the link test fails. The regression tests look good:
> "make test" reports "All 98 tests passed", "All 3 tests passed".
>
> For big endian, the test for __builtin_bswap64 should have no effect.
> For little endian, the failing test should disable a special case for
> block_size == 16 in WRKSRC/ctr.c ctr_crypt().
>
> Does this diff fix the problem on mips64el/longsoon?
>
> Index: Makefile
> ===================================================================
> RCS file: /cvs/ports/security/libnettle/Makefile,v
> retrieving revision 1.24
> diff -u -p -r1.24 Makefile
> --- Makefile 29 Jun 2019 22:26:25 -0000 1.24
> +++ Makefile 30 Nov 2019 20:38:46 -0000
> @@ -4,6 +4,7 @@ COMMENT= cryptographic library
>
> DISTNAME= nettle-3.5.1
> PKGNAME= lib${DISTNAME}
> +REVISION= 0
>
> SHARED_LIBS += hogweed 3.0 # 6.5
> SHARED_LIBS += nettle 5.0 # 4.5
> Index: patches/patch-configure
> ===================================================================
> RCS file: /cvs/ports/security/libnettle/patches/patch-configure,v
> retrieving revision 1.8
> diff -u -p -r1.8 patch-configure
> --- patches/patch-configure 29 Jun 2019 22:26:25 -0000 1.8
> +++ patches/patch-configure 30 Nov 2019 20:38:46 -0000
> @@ -1,5 +1,8 @@
> $OpenBSD: patch-configure,v 1.8 2019/06/29 22:26:25 ajacoutot Exp $
>
> +The test for __builtin_bswap64 must fail if the linker can't find the
> +symbol. We need this for base-gcc on little endian, like mips64el.
> +
> Fix relocation errors on (at least) sparc64.
>
> We don't want extra debug flags in regular builds.
> @@ -7,6 +10,15 @@ We don't want extra debug flags in regul
> Index: configure
> --- configure.orig
> +++ configure
> +@@ -6062,7 +6062,7 @@ uint64_t y = __builtin_bswap64(x);
> + return 0;
> + }
> + _ACEOF
> +-if ac_fn_c_try_compile "$LINENO"; then :
> ++if ac_fn_c_try_link "$LINENO"; then :
> + nettle_cv_c_builtin_bswap64=yes
> + else
> + nettle_cv_c_builtin_bswap64=no
> @@ -6720,6 +6720,7 @@ else
> bsdi4.*) CCPIC="-fPIC" ;;
> bsdi*) CCPIC="" ;;
>
Thanks George! This patch works just fine!
BTW, I still wonder why GCC 4.2.1 on OpenBSD has the symbol but cannot
link it? It's more curious as this builtin should not be available till
GCC 4.3. Maybe the compiler needs to be fixed to avoid other configure
falsely detect it all together?
Saturday, November 30, 2019
Remove net/py-oauth2?
net/py-oauth2 is python2-only and has no consumers.
Shall we remove it?
--Kurt
Shall we remove it?
--Kurt
Re: portgen: use sqlports cache table
On Sat, Nov 23, 2019 at 01:48:16PM -0800, Andrew Hewus Fresh wrote:
> On Sat, Nov 23, 2019 at 01:25:16PM +0100, Marc Espie wrote:
> > Woah. That code is horrible. It also spends a lot of time
> > connecting/disconnecting.
> >
> > - The database connection should be a singleton
> > - sqlports should always be opened ReadOnly
> > - The query should be prepared.
> >
> > Apart from that, PortsQ will help, but the basic code should be taken out
> > and shot.
I think this is a slight improvement, building on the changes sthen@
made. The benefit here is that the query to the sqlports database
should be able to figure out if what we're looking for exists without
looping over a bunch of possibilities.
I think there is still room for future improvement, for example, being
able to find "perltidy" from "p5-Perl-Tidy" by looking without the
prefix, removing any non-alphanumeric and continuing to convert to
lowercase. But, that could make it find things that aren't actually
what we're looking for.
I'm a bit worried about python3 only ports, so if someone can make sure
things work the way they expect with those, I'd appreciate it.
Comments? OK?
Index: infrastructure/lib/OpenBSD/PortGen/Utils.pm
===================================================================
RCS file: /cvs/ports/infrastructure/lib/OpenBSD/PortGen/Utils.pm,v
retrieving revision 1.5
diff -u -p -r1.5 Utils.pm
--- infrastructure/lib/OpenBSD/PortGen/Utils.pm 23 Nov 2019 14:59:39 -0000 1.5
+++ infrastructure/lib/OpenBSD/PortGen/Utils.pm 30 Nov 2019 22:56:23 -0000
@@ -18,6 +18,7 @@ package OpenBSD::PortGen::Utils;
use 5.012;
use warnings;
+use feature qw( state );
use parent qw( Exporter );
@@ -47,12 +48,8 @@ sub ports_dir { $ENV{PORTSDIR} || '/usr/
sub base_dir { ports_dir() . '/mystuff' }
-sub module_in_ports
+sub _module_sth
{
- my ( $module, $prefix ) = @_;
-
- return unless $module and $prefix;
-
my $dbfile = '/usr/local/share/sqlports';
die "install databases/sqlports and databases/p5-DBD-SQLite\n"
unless -e $dbfile;
@@ -64,22 +61,34 @@ sub module_in_ports
RaiseError => 1,
} ) or die "failed to connect to database: $DBI::errstr";
- my @results = @{ $dbh->selectcol_arrayref(
- "SELECT _paths.fullpkgpath FROM _paths JOIN _paths p1 ON p1.pkgpath=_paths.id
- JOIN _ports ON _ports.fullpkgpath=p1.id WHERE _ports.distname LIKE ?",
- {}, "$module%"
- ) };
-
- $dbh->disconnect();
-
- # just returning the shortest one that's a module of the same ecosystem
- # this should be improved
- @results = sort { length $a <=> length $b } @results;
-
- # this works well enough in practice, but can't rely on it
- # see devel/perltidy
- for (@results) {
- return $_ if /\/$prefix/;
+ return $dbh->prepare(q{
+ SELECT _Paths.FullPkgPath FROM _Paths
+ JOIN _Ports ON _Paths.PkgPath = _Ports.FullPkgPath
+ WHERE PKGSTEM = ?
+ AND _Paths.Id = _Paths.PkgPath
+ ORDER BY LENGTH(_Paths.FullPkgPath)
+ });
+}
+
+sub module_in_ports
+{
+ my ( $module, $prefix ) = @_;
+ return unless $module and $prefix;
+
+ state $sth = _module_sth();
+ END { undef $sth }; # Bus error if destroyed during global destruction
+
+ my @stems = ( $prefix . $module );
+
+ # We commonly convert the port to lowercase
+ push @stems, $prefix . lc($module) if $module =~ /\p{Upper}/;
+
+ foreach my $stem (@stems) {
+ $sth->execute($stem);
+ my ($path, @extra) = map {@$_} @{ $sth->fetchall_arrayref };
+ warn "Found paths other than $path: @extra\n"
+ if @extra;
+ return $path if $path;
}
# Many ports, in particular python ports, start with $prefix,
Index: infrastructure/lib/OpenBSD/PortGen/Port/PyPI.pm
===================================================================
RCS file: /cvs/ports/infrastructure/lib/OpenBSD/PortGen/Port/PyPI.pm,v
retrieving revision 1.17
diff -u -p -r1.17 PyPI.pm
--- infrastructure/lib/OpenBSD/PortGen/Port/PyPI.pm 15 Jul 2019 13:35:35 -0000 1.17
+++ infrastructure/lib/OpenBSD/PortGen/Port/PyPI.pm 30 Nov 2019 22:56:23 -0000
@@ -54,11 +54,20 @@ sub name_new_port
{
my ( $self, $di ) = @_;
- my $name = ref $di ? $di->{info}{name} : $di;
- $name =~ s/^python-/py-/;
+ my $module = ref $di ? $di->{info}{name} : $di;
+ $module =~ s/^python-/py-/;
- $name = $self->SUPER::name_new_port($name);
- $name = "pypi/$name" unless $name =~ m{/};
+ my $name = $self->SUPER::name_new_port($module);
+
+ # Try for a py3 only version if we didn't find something ported
+ unless ( $name =~ m{/} ) {
+ if ( my $p = module_in_ports( $name, 'py3-' ) ) {
+ $name = $p;
+ }
+ else {
+ $name = "pypi/$name"
+ }
+ }
return $name;
}
@@ -171,7 +180,8 @@ sub get_deps
next if @plat and join( " ", @plat ) !~ /OpenBSD/i;
- my $port = module_in_ports( $name, 'py-' );
+ my $port = module_in_ports( $name, 'py-' )
+ || module_in_ports( $name, 'py3-' );
my $dep_dir;
if ($port) {
> On Sat, Nov 23, 2019 at 01:25:16PM +0100, Marc Espie wrote:
> > Woah. That code is horrible. It also spends a lot of time
> > connecting/disconnecting.
> >
> > - The database connection should be a singleton
> > - sqlports should always be opened ReadOnly
> > - The query should be prepared.
> >
> > Apart from that, PortsQ will help, but the basic code should be taken out
> > and shot.
I think this is a slight improvement, building on the changes sthen@
made. The benefit here is that the query to the sqlports database
should be able to figure out if what we're looking for exists without
looping over a bunch of possibilities.
I think there is still room for future improvement, for example, being
able to find "perltidy" from "p5-Perl-Tidy" by looking without the
prefix, removing any non-alphanumeric and continuing to convert to
lowercase. But, that could make it find things that aren't actually
what we're looking for.
I'm a bit worried about python3 only ports, so if someone can make sure
things work the way they expect with those, I'd appreciate it.
Comments? OK?
Index: infrastructure/lib/OpenBSD/PortGen/Utils.pm
===================================================================
RCS file: /cvs/ports/infrastructure/lib/OpenBSD/PortGen/Utils.pm,v
retrieving revision 1.5
diff -u -p -r1.5 Utils.pm
--- infrastructure/lib/OpenBSD/PortGen/Utils.pm 23 Nov 2019 14:59:39 -0000 1.5
+++ infrastructure/lib/OpenBSD/PortGen/Utils.pm 30 Nov 2019 22:56:23 -0000
@@ -18,6 +18,7 @@ package OpenBSD::PortGen::Utils;
use 5.012;
use warnings;
+use feature qw( state );
use parent qw( Exporter );
@@ -47,12 +48,8 @@ sub ports_dir { $ENV{PORTSDIR} || '/usr/
sub base_dir { ports_dir() . '/mystuff' }
-sub module_in_ports
+sub _module_sth
{
- my ( $module, $prefix ) = @_;
-
- return unless $module and $prefix;
-
my $dbfile = '/usr/local/share/sqlports';
die "install databases/sqlports and databases/p5-DBD-SQLite\n"
unless -e $dbfile;
@@ -64,22 +61,34 @@ sub module_in_ports
RaiseError => 1,
} ) or die "failed to connect to database: $DBI::errstr";
- my @results = @{ $dbh->selectcol_arrayref(
- "SELECT _paths.fullpkgpath FROM _paths JOIN _paths p1 ON p1.pkgpath=_paths.id
- JOIN _ports ON _ports.fullpkgpath=p1.id WHERE _ports.distname LIKE ?",
- {}, "$module%"
- ) };
-
- $dbh->disconnect();
-
- # just returning the shortest one that's a module of the same ecosystem
- # this should be improved
- @results = sort { length $a <=> length $b } @results;
-
- # this works well enough in practice, but can't rely on it
- # see devel/perltidy
- for (@results) {
- return $_ if /\/$prefix/;
+ return $dbh->prepare(q{
+ SELECT _Paths.FullPkgPath FROM _Paths
+ JOIN _Ports ON _Paths.PkgPath = _Ports.FullPkgPath
+ WHERE PKGSTEM = ?
+ AND _Paths.Id = _Paths.PkgPath
+ ORDER BY LENGTH(_Paths.FullPkgPath)
+ });
+}
+
+sub module_in_ports
+{
+ my ( $module, $prefix ) = @_;
+ return unless $module and $prefix;
+
+ state $sth = _module_sth();
+ END { undef $sth }; # Bus error if destroyed during global destruction
+
+ my @stems = ( $prefix . $module );
+
+ # We commonly convert the port to lowercase
+ push @stems, $prefix . lc($module) if $module =~ /\p{Upper}/;
+
+ foreach my $stem (@stems) {
+ $sth->execute($stem);
+ my ($path, @extra) = map {@$_} @{ $sth->fetchall_arrayref };
+ warn "Found paths other than $path: @extra\n"
+ if @extra;
+ return $path if $path;
}
# Many ports, in particular python ports, start with $prefix,
Index: infrastructure/lib/OpenBSD/PortGen/Port/PyPI.pm
===================================================================
RCS file: /cvs/ports/infrastructure/lib/OpenBSD/PortGen/Port/PyPI.pm,v
retrieving revision 1.17
diff -u -p -r1.17 PyPI.pm
--- infrastructure/lib/OpenBSD/PortGen/Port/PyPI.pm 15 Jul 2019 13:35:35 -0000 1.17
+++ infrastructure/lib/OpenBSD/PortGen/Port/PyPI.pm 30 Nov 2019 22:56:23 -0000
@@ -54,11 +54,20 @@ sub name_new_port
{
my ( $self, $di ) = @_;
- my $name = ref $di ? $di->{info}{name} : $di;
- $name =~ s/^python-/py-/;
+ my $module = ref $di ? $di->{info}{name} : $di;
+ $module =~ s/^python-/py-/;
- $name = $self->SUPER::name_new_port($name);
- $name = "pypi/$name" unless $name =~ m{/};
+ my $name = $self->SUPER::name_new_port($module);
+
+ # Try for a py3 only version if we didn't find something ported
+ unless ( $name =~ m{/} ) {
+ if ( my $p = module_in_ports( $name, 'py3-' ) ) {
+ $name = $p;
+ }
+ else {
+ $name = "pypi/$name"
+ }
+ }
return $name;
}
@@ -171,7 +180,8 @@ sub get_deps
next if @plat and join( " ", @plat ) !~ /OpenBSD/i;
- my $port = module_in_ports( $name, 'py-' );
+ my $port = module_in_ports( $name, 'py-' )
+ || module_in_ports( $name, 'py3-' );
my $dep_dir;
if ($port) {
Re: Softdep and noatime
On Sat, Nov 30, 2019 at 09:20:37PM +0100, Xianwen Chen (้่ดคๆ) wrote:
> Dear Mr. Rola,
>
> > I wonder what other will say about this, but I mount everything as
> > noatime, since more than a decade, spinning or not. I assume this may
>
> Do you mount swap as noatime too, I'm curious?
>
> Yours sincerely,
> Xianwen
Hello,
Frankly, I have never considered atime or noatime option for swap. I
think there is not much use for atime in swap anyway. Access time for
memory pages, this is another story. I guess some optimisation
algorithms make use of this information.
Ok, so not "everything", I only mount filesystems as noatime. :-)
--
Regards,
Tomasz Rola
--
** A C programmer asked whether computer had Buddha's nature. **
** As the answer, master did "rm -rif" on the programmer's home **
** directory. And then the C programmer became enlightened... **
** **
** Tomasz Rola mailto:tomasz_rola@bigfoot.com **
> Dear Mr. Rola,
>
> > I wonder what other will say about this, but I mount everything as
> > noatime, since more than a decade, spinning or not. I assume this may
>
> Do you mount swap as noatime too, I'm curious?
>
> Yours sincerely,
> Xianwen
Hello,
Frankly, I have never considered atime or noatime option for swap. I
think there is not much use for atime in swap anyway. Access time for
memory pages, this is another story. I guess some optimisation
algorithms make use of this information.
Ok, so not "everything", I only mount filesystems as noatime. :-)
--
Regards,
Tomasz Rola
--
** A C programmer asked whether computer had Buddha's nature. **
** As the answer, master did "rm -rif" on the programmer's home **
** directory. And then the C programmer became enlightened... **
** **
** Tomasz Rola mailto:tomasz_rola@bigfoot.com **
Re: "undefined reference to `__builtin_bswap64'" on mips64el/loongson
On Sat, 30 Nov 2019 01:10:56 -0800
manphiz@gmail.com wrote:
> Hi OpenBSD ports maintainers,
>
> I'm having trouble building security/libnettle on mips64el/loongson
> which is caused by missing symbol of "__builtin_bswap64" when linking.
> It looks like this symbol is introduced since GCC 4.3[1], while mips64el
> ships with GCC 4.2.1. It's interesting because I can compile with the
> symbol but cannot link. Would like to hear from the ports maintainers'
> opinion on how to solve this issue?
Bad luck! libnettle uses __builtin_bswap64 only on little-endian
platforms. My big-endian powerpc/macppc also uses base-gcc 4.2.1 but
can use the powerpc snapshot package of libnettle.
The configure test for __builtin_bswap64 is wrong. It is a compile
test, but you got a link error, not a compile error. Here is a diff
to do a link test. On my powerpc with base-gcc, the compile test
passed but the link test fails. The regression tests look good:
"make test" reports "All 98 tests passed", "All 3 tests passed".
For big endian, the test for __builtin_bswap64 should have no effect.
For little endian, the failing test should disable a special case for
block_size == 16 in WRKSRC/ctr.c ctr_crypt().
Does this diff fix the problem on mips64el/longsoon?
Index: Makefile
===================================================================
RCS file: /cvs/ports/security/libnettle/Makefile,v
retrieving revision 1.24
diff -u -p -r1.24 Makefile
--- Makefile 29 Jun 2019 22:26:25 -0000 1.24
+++ Makefile 30 Nov 2019 20:38:46 -0000
@@ -4,6 +4,7 @@ COMMENT= cryptographic library
DISTNAME= nettle-3.5.1
PKGNAME= lib${DISTNAME}
+REVISION= 0
SHARED_LIBS += hogweed 3.0 # 6.5
SHARED_LIBS += nettle 5.0 # 4.5
Index: patches/patch-configure
===================================================================
RCS file: /cvs/ports/security/libnettle/patches/patch-configure,v
retrieving revision 1.8
diff -u -p -r1.8 patch-configure
--- patches/patch-configure 29 Jun 2019 22:26:25 -0000 1.8
+++ patches/patch-configure 30 Nov 2019 20:38:46 -0000
@@ -1,5 +1,8 @@
$OpenBSD: patch-configure,v 1.8 2019/06/29 22:26:25 ajacoutot Exp $
+The test for __builtin_bswap64 must fail if the linker can't find the
+symbol. We need this for base-gcc on little endian, like mips64el.
+
Fix relocation errors on (at least) sparc64.
We don't want extra debug flags in regular builds.
@@ -7,6 +10,15 @@ We don't want extra debug flags in regul
Index: configure
--- configure.orig
+++ configure
+@@ -6062,7 +6062,7 @@ uint64_t y = __builtin_bswap64(x);
+ return 0;
+ }
+ _ACEOF
+-if ac_fn_c_try_compile "$LINENO"; then :
++if ac_fn_c_try_link "$LINENO"; then :
+ nettle_cv_c_builtin_bswap64=yes
+ else
+ nettle_cv_c_builtin_bswap64=no
@@ -6720,6 +6720,7 @@ else
bsdi4.*) CCPIC="-fPIC" ;;
bsdi*) CCPIC="" ;;
manphiz@gmail.com wrote:
> Hi OpenBSD ports maintainers,
>
> I'm having trouble building security/libnettle on mips64el/loongson
> which is caused by missing symbol of "__builtin_bswap64" when linking.
> It looks like this symbol is introduced since GCC 4.3[1], while mips64el
> ships with GCC 4.2.1. It's interesting because I can compile with the
> symbol but cannot link. Would like to hear from the ports maintainers'
> opinion on how to solve this issue?
Bad luck! libnettle uses __builtin_bswap64 only on little-endian
platforms. My big-endian powerpc/macppc also uses base-gcc 4.2.1 but
can use the powerpc snapshot package of libnettle.
The configure test for __builtin_bswap64 is wrong. It is a compile
test, but you got a link error, not a compile error. Here is a diff
to do a link test. On my powerpc with base-gcc, the compile test
passed but the link test fails. The regression tests look good:
"make test" reports "All 98 tests passed", "All 3 tests passed".
For big endian, the test for __builtin_bswap64 should have no effect.
For little endian, the failing test should disable a special case for
block_size == 16 in WRKSRC/ctr.c ctr_crypt().
Does this diff fix the problem on mips64el/longsoon?
Index: Makefile
===================================================================
RCS file: /cvs/ports/security/libnettle/Makefile,v
retrieving revision 1.24
diff -u -p -r1.24 Makefile
--- Makefile 29 Jun 2019 22:26:25 -0000 1.24
+++ Makefile 30 Nov 2019 20:38:46 -0000
@@ -4,6 +4,7 @@ COMMENT= cryptographic library
DISTNAME= nettle-3.5.1
PKGNAME= lib${DISTNAME}
+REVISION= 0
SHARED_LIBS += hogweed 3.0 # 6.5
SHARED_LIBS += nettle 5.0 # 4.5
Index: patches/patch-configure
===================================================================
RCS file: /cvs/ports/security/libnettle/patches/patch-configure,v
retrieving revision 1.8
diff -u -p -r1.8 patch-configure
--- patches/patch-configure 29 Jun 2019 22:26:25 -0000 1.8
+++ patches/patch-configure 30 Nov 2019 20:38:46 -0000
@@ -1,5 +1,8 @@
$OpenBSD: patch-configure,v 1.8 2019/06/29 22:26:25 ajacoutot Exp $
+The test for __builtin_bswap64 must fail if the linker can't find the
+symbol. We need this for base-gcc on little endian, like mips64el.
+
Fix relocation errors on (at least) sparc64.
We don't want extra debug flags in regular builds.
@@ -7,6 +10,15 @@ We don't want extra debug flags in regul
Index: configure
--- configure.orig
+++ configure
+@@ -6062,7 +6062,7 @@ uint64_t y = __builtin_bswap64(x);
+ return 0;
+ }
+ _ACEOF
+-if ac_fn_c_try_compile "$LINENO"; then :
++if ac_fn_c_try_link "$LINENO"; then :
+ nettle_cv_c_builtin_bswap64=yes
+ else
+ nettle_cv_c_builtin_bswap64=no
@@ -6720,6 +6720,7 @@ else
bsdi4.*) CCPIC="-fPIC" ;;
bsdi*) CCPIC="" ;;
Re: Softdep and noatime
On 30.11.2019 14:12, Raymond, David wrote:
> I am switching to OpenBSD from Linux and I have questions about the
> use of softdep and noatime in mounting disks. I have a variety of
> systems with a mix of SSDs and rotating disks.
>
> Softdep seems to have some advantages in speeding file access, but it
> is not the default. Are there any downsides in using softdep?
https://www.openbsd.org/faq/faq14.html#SoftUpdates
plus 'man mount' option softdep:
(FFS only) Mount the file system using soft dependencies. Instead of
metadata being written immediately, it is written in an ordered fashion
to keep the on-disk state of the file system consistent. This results in
significant speedups for file create/delete operations. This option is
ignored when using the -u flag and a file system is already mounted
read/write.
The options async and softdep are mutually exclusive.
>
> On SSDs in particular, is it worth setting noatime to reduce the
> number of disk writes?
>
Why would you want to do that? Are you using it in other OS?
Then why and where did you get that idea?
> Dave Raymond
> I am switching to OpenBSD from Linux and I have questions about the
> use of softdep and noatime in mounting disks. I have a variety of
> systems with a mix of SSDs and rotating disks.
>
> Softdep seems to have some advantages in speeding file access, but it
> is not the default. Are there any downsides in using softdep?
https://www.openbsd.org/faq/faq14.html#SoftUpdates
plus 'man mount' option softdep:
(FFS only) Mount the file system using soft dependencies. Instead of
metadata being written immediately, it is written in an ordered fashion
to keep the on-disk state of the file system consistent. This results in
significant speedups for file create/delete operations. This option is
ignored when using the -u flag and a file system is already mounted
read/write.
The options async and softdep are mutually exclusive.
>
> On SSDs in particular, is it worth setting noatime to reduce the
> number of disk writes?
>
Why would you want to do that? Are you using it in other OS?
Then why and where did you get that idea?
> Dave Raymond
Re: Deleting softraid Devices Fujitsu Sparc
On 2019-11-28 20:09, Kihaguru Gathura wrote:
> www# bioctl sd2 displays the raid but www# bioctl -d sd2 does not delete
> the raid.
Not sure what exactly do you expect from "delete", but -d option for
softraid is more like detach than delete. Although man page is a bit
confusing since first -d is described as delete and then in examples as
detach. So well, what do you expect from it exactly?
> www# bioctl sd2 displays the raid but www# bioctl -d sd2 does not delete
> the raid.
Not sure what exactly do you expect from "delete", but -d option for
softraid is more like detach than delete. Although man page is a bit
confusing since first -d is described as delete and then in examples as
detach. So well, what do you expect from it exactly?
Re: Softdep and noatime
Dear Mr. Rola,
> I wonder what other will say about this, but I mount everything as
> noatime, since more than a decade, spinning or not. I assume this may
Do you mount swap as noatime too, I'm curious?
Yours sincerely,
Xianwen
> I wonder what other will say about this, but I mount everything as
> noatime, since more than a decade, spinning or not. I assume this may
Do you mount swap as noatime too, I'm curious?
Yours sincerely,
Xianwen
Re: Softdep and noatime
On Nov 30 06:12:42, david.raymond@nmt.edu wrote:
> On SSDs in particular, is it worth setting noatime to reduce the
> number of disk writes?
noatime is worth setting on filesystems where you don't care
about atime (a mail client might care about the atime of your
/var/mail/mbox, for instance).
SSD has nothing to do with it.
Treat it as a disk, which it is.
> On SSDs in particular, is it worth setting noatime to reduce the
> number of disk writes?
noatime is worth setting on filesystems where you don't care
about atime (a mail client might care about the atime of your
/var/mail/mbox, for instance).
SSD has nothing to do with it.
Treat it as a disk, which it is.
Re: Softdep and noatime
Hello,
david.raymond@nmt.edu (Raymond, David), 2019.11.30 (Sat) 14:12 (CET):
> I am switching to OpenBSD from Linux and I have questions about the
> use of softdep and noatime in mounting disks. I have a variety of
> systems with a mix of SSDs and rotating disks.
>
> Softdep seems to have some advantages in speeding file access, but it
> is not the default. Are there any downsides in using softdep?
>
> On SSDs in particular, is it worth setting noatime to reduce the
> number of disk writes?
The most recent thread on that topic that I could find:
https://marc.info/?t=151811826800005
Marcus
david.raymond@nmt.edu (Raymond, David), 2019.11.30 (Sat) 14:12 (CET):
> I am switching to OpenBSD from Linux and I have questions about the
> use of softdep and noatime in mounting disks. I have a variety of
> systems with a mix of SSDs and rotating disks.
>
> Softdep seems to have some advantages in speeding file access, but it
> is not the default. Are there any downsides in using softdep?
>
> On SSDs in particular, is it worth setting noatime to reduce the
> number of disk writes?
The most recent thread on that topic that I could find:
https://marc.info/?t=151811826800005
Marcus
UPDATE: mail/rss2email 3.10 -> 3.11
Hi
This is a minor update, there's a new config key user-agent so you can
change the user agent mail is sent with (maybe useful if you want to
filter mail based on this).
diff --git mail/rss2email/Makefile mail/rss2email/Makefile
index 23f7f8100c3..854523ee9e8 100644
--- mail/rss2email/Makefile
+++ mail/rss2email/Makefile
@@ -2,7 +2,7 @@
COMMENT = convert RSS/Atom newsfeeds to email
-MODPY_EGG_VERSION = 3.10
+MODPY_EGG_VERSION = 3.11
DISTNAME = rss2email-${MODPY_EGG_VERSION}
CATEGORIES = mail www
diff --git mail/rss2email/distinfo mail/rss2email/distinfo
index af444691c2c..36054400daa 100644
--- mail/rss2email/distinfo
+++ mail/rss2email/distinfo
@@ -1,2 +1,2 @@
-SHA256 (rss2email-3.10.tar.gz) = AcZbUrEO+E/2ZJLU5157uJ4p1qfEmsm5v1XKhO9bT/o=
-SIZE (rss2email-3.10.tar.gz) = 65388
+SHA256 (rss2email-3.11.tar.gz) = NsO9snnMqKtkxk5BrwJdApY/sJ/4RTAkDqzCKi7VZe4=
+SIZE (rss2email-3.11.tar.gz) = 68020
This is a minor update, there's a new config key user-agent so you can
change the user agent mail is sent with (maybe useful if you want to
filter mail based on this).
diff --git mail/rss2email/Makefile mail/rss2email/Makefile
index 23f7f8100c3..854523ee9e8 100644
--- mail/rss2email/Makefile
+++ mail/rss2email/Makefile
@@ -2,7 +2,7 @@
COMMENT = convert RSS/Atom newsfeeds to email
-MODPY_EGG_VERSION = 3.10
+MODPY_EGG_VERSION = 3.11
DISTNAME = rss2email-${MODPY_EGG_VERSION}
CATEGORIES = mail www
diff --git mail/rss2email/distinfo mail/rss2email/distinfo
index af444691c2c..36054400daa 100644
--- mail/rss2email/distinfo
+++ mail/rss2email/distinfo
@@ -1,2 +1,2 @@
-SHA256 (rss2email-3.10.tar.gz) = AcZbUrEO+E/2ZJLU5157uJ4p1qfEmsm5v1XKhO9bT/o=
-SIZE (rss2email-3.10.tar.gz) = 65388
+SHA256 (rss2email-3.11.tar.gz) = NsO9snnMqKtkxk5BrwJdApY/sJ/4RTAkDqzCKi7VZe4=
+SIZE (rss2email-3.11.tar.gz) = 68020
Re: Softdep and noatime
On Sat, Nov 30, 2019 at 06:12:42AM -0700, Raymond, David wrote:
[...]
> On SSDs in particular, is it worth setting noatime to reduce the
> number of disk writes?
[...]
I wonder what other will say about this, but I mount everything as
noatime, since more than a decade, spinning or not. I assume this may
make lifetime a bit longer and decided it is better to be on safe(r)
side.
--
Regards,
Tomasz Rola
--
** A C programmer asked whether computer had Buddha's nature. **
** As the answer, master did "rm -rif" on the programmer's home **
** directory. And then the C programmer became enlightened... **
** **
** Tomasz Rola mailto:tomasz_rola@bigfoot.com **
[...]
> On SSDs in particular, is it worth setting noatime to reduce the
> number of disk writes?
[...]
I wonder what other will say about this, but I mount everything as
noatime, since more than a decade, spinning or not. I assume this may
make lifetime a bit longer and decided it is better to be on safe(r)
side.
--
Regards,
Tomasz Rola
--
** A C programmer asked whether computer had Buddha's nature. **
** As the answer, master did "rm -rif" on the programmer's home **
** directory. And then the C programmer became enlightened... **
** **
** Tomasz Rola mailto:tomasz_rola@bigfoot.com **
Re: gettext-tools poisoning; allow LIB_DEPENDS
On 2019-11-29, Stuart Henderson <stu@spacehopper.org> wrote:
> Currently we require BUILD_DEPENDS to avoid tripping the (very useful)
> poisoning that we have to detect ports with a missing dependency on
> gettext-tools. This used to be fine, but now gettext-tools includes
> libraries, a port may have LIB_DEPENDS instead of BUILD_DEPENDS.
Very few ports are affected by this. libgettextlib and libgettextsrc
are for internal use by the gettext-tools programs; only libgettextpo
is an external interface. Currently we have four ports that depend
on this library, and two of them need the redundant BUILD_DEPENDS.
> We could just require that those ports list a redundant BUILD_DEPENDS
> as well as the LIB_DEPENDS, but it's easy enough to handle the simple
> (i.e. not multi-packages) case.
>
> OK or is there a better idea?
The internal variable _BUILDLIB_DEPENDS is always defined, set
early, and collects all the LIB_DEPENDS* from multi-packages, so
you can just check !${_BUILDLIB_DEPENDS:Mdevel/gettext,-tools}.
--
Christian "naddy" Weisgerber naddy@mips.inka.de
> Currently we require BUILD_DEPENDS to avoid tripping the (very useful)
> poisoning that we have to detect ports with a missing dependency on
> gettext-tools. This used to be fine, but now gettext-tools includes
> libraries, a port may have LIB_DEPENDS instead of BUILD_DEPENDS.
Very few ports are affected by this. libgettextlib and libgettextsrc
are for internal use by the gettext-tools programs; only libgettextpo
is an external interface. Currently we have four ports that depend
on this library, and two of them need the redundant BUILD_DEPENDS.
> We could just require that those ports list a redundant BUILD_DEPENDS
> as well as the LIB_DEPENDS, but it's easy enough to handle the simple
> (i.e. not multi-packages) case.
>
> OK or is there a better idea?
The internal variable _BUILDLIB_DEPENDS is always defined, set
early, and collects all the LIB_DEPENDS* from multi-packages, so
you can just check !${_BUILDLIB_DEPENDS:Mdevel/gettext,-tools}.
--
Christian "naddy" Weisgerber naddy@mips.inka.de
Re: Add MODPY_TEST (should be MODPY_PYTEST) as poisoned entry
On Fri, 29 Nov 2019, Kurt Mosiejczuk wrote:
> I'd like to add MODPY_TEST as a poisoned entry to mk.conf.template. I
> used to make this typo a lot. Things look like they work right, but
> pytest isn't getting used at that point, just the usual setuptools
> testing mechanism.
>
> ok?
For what is worth, it seems I tend to make this mistake a lot too. A
big error in my face would help.
Cheers,
--
Paco Esteban.
5818130B8A6DBC03
> I'd like to add MODPY_TEST as a poisoned entry to mk.conf.template. I
> used to make this typo a lot. Things look like they work right, but
> pytest isn't getting used at that point, just the usual setuptools
> testing mechanism.
>
> ok?
For what is worth, it seems I tend to make this mistake a lot too. A
big error in my face would help.
Cheers,
--
Paco Esteban.
5818130B8A6DBC03
Re: new: net/py-transmissionrpc-ng
On Sat, 30 Nov 2019, Kurt Mosiejczuk wrote:
> First, you've got spaces for indentiation rather than tabs, that needs to
> be fixed.
That happens when one sends things without engaging one's brain ...
Find attached the updated version.
> The tests all pass on amd64 and sparc64 for me, so make those changes
> and ok kmos
Thank you Kurt.
--
Paco Esteban.
5818130B8A6DBC03
> First, you've got spaces for indentiation rather than tabs, that needs to
> be fixed.
That happens when one sends things without engaging one's brain ...
Find attached the updated version.
> The tests all pass on amd64 and sparc64 for me, so make those changes
> and ok kmos
Thank you Kurt.
--
Paco Esteban.
5818130B8A6DBC03
Re: gettext-tools poisoning; allow LIB_DEPENDS
On Sat, Nov 30, 2019 at 11:18:51AM +0100, Jeremie Courreges-Anglas wrote:
> On Fri, Nov 29 2019, Stuart Henderson <stu@spacehopper.org> wrote:
> > Currently we require BUILD_DEPENDS to avoid tripping the (very useful)
> > poisoning that we have to detect ports with a missing dependency on
> > gettext-tools. This used to be fine, but now gettext-tools includes
> > libraries, a port may have LIB_DEPENDS instead of BUILD_DEPENDS.
> >
> > We could just require that those ports list a redundant BUILD_DEPENDS
> > as well as the LIB_DEPENDS, but it's easy enough to handle the simple
> > (i.e. not multi-packages) case.
> >
> > OK or is there a better idea?
>
> I like the "required in BUILD_DEPENDS" approach, it's a simple rule that
> doesn't introduce another subtle difference between multi-packages and
> non-multi-packages ports. Maybe making the error message more explicit
> would be enough?
>
> (Suggestion below, feel free to find a better wording.)
>
>
> Index: bsd.port.mk
> ===================================================================
> RCS file: /cvs/ports/infrastructure/mk/bsd.port.mk,v
> retrieving revision 1.1505
> diff -u -p -r1.1505 bsd.port.mk
> --- bsd.port.mk 26 Nov 2019 11:49:02 -0000 1.1505
> +++ bsd.port.mk 30 Nov 2019 10:14:44 -0000
> @@ -2608,7 +2608,7 @@ ${_WRKDIR_COOKIE}:
> .if !defined(BUILD_DEPENDS) || !${BUILD_DEPENDS:Mdevel/gettext,-tools} && \
> !${BUILD_DEPENDS:M*textproc/intltool}
> @printf '#!/bin/sh\n\
> - echo "*** $$0 was called without gettext-tools dependency ***" >&2\n\
> + echo "*** $$0 was called without gettext-tools dependency in BUILD_DEPENDS ***" >&2\n\
> exit 1\n' ${_PREDIR} ${WRKDIR}/bin/msgfmt
> @${_PBUILD} chmod 555 ${WRKDIR}/bin/msgfmt
> . for name in msgcat msginit autopoint xgettext gettextize
>
Or, since you're inside bsd.port.mk, you can use internals.
Specifically, what you're looking for is _BUILDLIB_DEPENDS
> On Fri, Nov 29 2019, Stuart Henderson <stu@spacehopper.org> wrote:
> > Currently we require BUILD_DEPENDS to avoid tripping the (very useful)
> > poisoning that we have to detect ports with a missing dependency on
> > gettext-tools. This used to be fine, but now gettext-tools includes
> > libraries, a port may have LIB_DEPENDS instead of BUILD_DEPENDS.
> >
> > We could just require that those ports list a redundant BUILD_DEPENDS
> > as well as the LIB_DEPENDS, but it's easy enough to handle the simple
> > (i.e. not multi-packages) case.
> >
> > OK or is there a better idea?
>
> I like the "required in BUILD_DEPENDS" approach, it's a simple rule that
> doesn't introduce another subtle difference between multi-packages and
> non-multi-packages ports. Maybe making the error message more explicit
> would be enough?
>
> (Suggestion below, feel free to find a better wording.)
>
>
> Index: bsd.port.mk
> ===================================================================
> RCS file: /cvs/ports/infrastructure/mk/bsd.port.mk,v
> retrieving revision 1.1505
> diff -u -p -r1.1505 bsd.port.mk
> --- bsd.port.mk 26 Nov 2019 11:49:02 -0000 1.1505
> +++ bsd.port.mk 30 Nov 2019 10:14:44 -0000
> @@ -2608,7 +2608,7 @@ ${_WRKDIR_COOKIE}:
> .if !defined(BUILD_DEPENDS) || !${BUILD_DEPENDS:Mdevel/gettext,-tools} && \
> !${BUILD_DEPENDS:M*textproc/intltool}
> @printf '#!/bin/sh\n\
> - echo "*** $$0 was called without gettext-tools dependency ***" >&2\n\
> + echo "*** $$0 was called without gettext-tools dependency in BUILD_DEPENDS ***" >&2\n\
> exit 1\n' ${_PREDIR} ${WRKDIR}/bin/msgfmt
> @${_PBUILD} chmod 555 ${WRKDIR}/bin/msgfmt
> . for name in msgcat msginit autopoint xgettext gettextize
>
Or, since you're inside bsd.port.mk, you can use internals.
Specifically, what you're looking for is _BUILDLIB_DEPENDS
Softdep and noatime
I am switching to OpenBSD from Linux and I have questions about the
use of softdep and noatime in mounting disks. I have a variety of
systems with a mix of SSDs and rotating disks.
Softdep seems to have some advantages in speeding file access, but it
is not the default. Are there any downsides in using softdep?
On SSDs in particular, is it worth setting noatime to reduce the
number of disk writes?
Dave Raymond
--
David J. Raymond
David.Raymond@nmt.edu
http://physics.nmt.edu/~raymond
use of softdep and noatime in mounting disks. I have a variety of
systems with a mix of SSDs and rotating disks.
Softdep seems to have some advantages in speeding file access, but it
is not the default. Are there any downsides in using softdep?
On SSDs in particular, is it worth setting noatime to reduce the
number of disk writes?
Dave Raymond
--
David J. Raymond
David.Raymond@nmt.edu
http://physics.nmt.edu/~raymond
Re: packer-vmm - how to retrieve go dependencies?
That's neat. We should add something like this directly in the go MODULE.
—
Antoine
> On 30 Nov 2019, at 11:49, Stuart Henderson <stu@spacehopper.org> wrote:
>
> On 2019/11/30 11:16, Philipp Buehler wrote:
>> Hi porters,
>>
>> it's time to make a port out of my packer-vmm plugin.
>> https://github.com/double-p/packer-builder-openbsd-vmm
>>
>> As this is my first ports try at all, I am missing something blatantly
>> obvious.
>>
>> The Makefile is in 'examples/Makefile.ports' and trying a
>> 'make fake' per Porters Guide, this fails like so:
>> ===
>> ==> Building for packer-builder-openbsd-vmm-0.9.0
>> cd /usr/ports/pobj/packer-builder-openbsd-vmm-0.9.0/go/src/github.com/double-p/packer-builder-openbsd-vmm
>> && GOMAXPROCS=1
>> GOCACHE=/usr/ports/pobj/packer-builder-openbsd-vmm-0.9.0/go-cache
>> GOPATH=/usr/ports/pobj/packer-builder-openbsd-vmm-0.9.0/go make
>> builder/openbsd-vmm/builder.go:9:2: cannot find package
>> "github.com/hashicorp/packer/common" in any of:
>> /usr/local/go/src/github.com/hashicorp/packer/common (from $GOROOT)
>> /usr/ports/pobj/packer-builder-openbsd-vmm-0.9.0/go/src/github.com/hashicorp/packer/common
>> (from $GOPATH)
>> ===
>> ..and more of the same.
>>
>> Clearly I need to (let) fetch the required (sub)packages - but how? List all
>> subs in go.mod?
>> I was looking into several lang/go ports, but cant say I am getting the
>> magic sauce :)
>>
>> TIA,
>> --
>> pb
>>
>
> Here's one way to do it.
>
> <Makefile>
—
Antoine
> On 30 Nov 2019, at 11:49, Stuart Henderson <stu@spacehopper.org> wrote:
>
> On 2019/11/30 11:16, Philipp Buehler wrote:
>> Hi porters,
>>
>> it's time to make a port out of my packer-vmm plugin.
>> https://github.com/double-p/packer-builder-openbsd-vmm
>>
>> As this is my first ports try at all, I am missing something blatantly
>> obvious.
>>
>> The Makefile is in 'examples/Makefile.ports' and trying a
>> 'make fake' per Porters Guide, this fails like so:
>> ===
>> ==> Building for packer-builder-openbsd-vmm-0.9.0
>> cd /usr/ports/pobj/packer-builder-openbsd-vmm-0.9.0/go/src/github.com/double-p/packer-builder-openbsd-vmm
>> && GOMAXPROCS=1
>> GOCACHE=/usr/ports/pobj/packer-builder-openbsd-vmm-0.9.0/go-cache
>> GOPATH=/usr/ports/pobj/packer-builder-openbsd-vmm-0.9.0/go make
>> builder/openbsd-vmm/builder.go:9:2: cannot find package
>> "github.com/hashicorp/packer/common" in any of:
>> /usr/local/go/src/github.com/hashicorp/packer/common (from $GOROOT)
>> /usr/ports/pobj/packer-builder-openbsd-vmm-0.9.0/go/src/github.com/hashicorp/packer/common
>> (from $GOPATH)
>> ===
>> ..and more of the same.
>>
>> Clearly I need to (let) fetch the required (sub)packages - but how? List all
>> subs in go.mod?
>> I was looking into several lang/go ports, but cant say I am getting the
>> magic sauce :)
>>
>> TIA,
>> --
>> pb
>>
>
> Here's one way to do it.
>
> <Makefile>
Re: packer-vmm - how to retrieve go dependencies?
# $OpenBSD$
COMMENT= packer-builder-openbsd-vmm
GH_ACCOUNT= double-p
GH_PROJECT= packer-builder-openbsd-vmm
GH_COMMIT= 04f261659d2583393835fd904383dde6b134f049
DISTNAME= packer-builder-openbsd-vmm-0.0.20191130
MODGO_GHMOD= hashicorp packer v1.4.0 \
mitchellh go-homedir v1.0.0 \
pkg errors v0.8.1
DISTFILES= packer-builder-openbsd-vmm-{}${GH_COMMIT}.tar.gz
.for _a _p _c in ${MODGO_GHMOD}
DISTFILES+= ${_p}-{${_a}/${_p}/archive/}${_c}.tar.gz:0
.endfor
CATEGORIES= sysutils
# BSD
PERMIT_PACKAGE= Yes
WANTLIB= c pthread
MASTER_SITES0= https://github.com/
MODULES= lang/go
MODGO_TYPE= bin
NO_TEST= Yes
post-extract:
.for _a _p _c in ${MODGO_GHMOD}
mkdir -p ${WRKDIR}/go/src/github.com/${_a}
mv ${WRKDIR}/${_p}-${_c:S/v//} ${WRKDIR}/go/src/github.com/${_a}/${_p}
.endfor
.include <bsd.port.mk>
On 2019/11/30 11:16, Philipp Buehler wrote:
> Hi porters,
>
> it's time to make a port out of my packer-vmm plugin.
> https://github.com/double-p/packer-builder-openbsd-vmm
>
> As this is my first ports try at all, I am missing something blatantly
> obvious.
>
> The Makefile is in 'examples/Makefile.ports' and trying a
> 'make fake' per Porters Guide, this fails like so:
> ===
> ==> Building for packer-builder-openbsd-vmm-0.9.0
> cd /usr/ports/pobj/packer-builder-openbsd-vmm-0.9.0/go/src/github.com/double-p/packer-builder-openbsd-vmm
> && GOMAXPROCS=1
> GOCACHE=/usr/ports/pobj/packer-builder-openbsd-vmm-0.9.0/go-cache
> GOPATH=/usr/ports/pobj/packer-builder-openbsd-vmm-0.9.0/go make
> builder/openbsd-vmm/builder.go:9:2: cannot find package
> "github.com/hashicorp/packer/common" in any of:
> /usr/local/go/src/github.com/hashicorp/packer/common (from $GOROOT)
> /usr/ports/pobj/packer-builder-openbsd-vmm-0.9.0/go/src/github.com/hashicorp/packer/common
> (from $GOPATH)
> ===
> ..and more of the same.
>
> Clearly I need to (let) fetch the required (sub)packages - but how? List all
> subs in go.mod?
> I was looking into several lang/go ports, but cant say I am getting the
> magic sauce :)
>
> TIA,
> --
> pb
>
Here's one way to do it.
COMMENT= packer-builder-openbsd-vmm
GH_ACCOUNT= double-p
GH_PROJECT= packer-builder-openbsd-vmm
GH_COMMIT= 04f261659d2583393835fd904383dde6b134f049
DISTNAME= packer-builder-openbsd-vmm-0.0.20191130
MODGO_GHMOD= hashicorp packer v1.4.0 \
mitchellh go-homedir v1.0.0 \
pkg errors v0.8.1
DISTFILES= packer-builder-openbsd-vmm-{}${GH_COMMIT}.tar.gz
.for _a _p _c in ${MODGO_GHMOD}
DISTFILES+= ${_p}-{${_a}/${_p}/archive/}${_c}.tar.gz:0
.endfor
CATEGORIES= sysutils
# BSD
PERMIT_PACKAGE= Yes
WANTLIB= c pthread
MASTER_SITES0= https://github.com/
MODULES= lang/go
MODGO_TYPE= bin
NO_TEST= Yes
post-extract:
.for _a _p _c in ${MODGO_GHMOD}
mkdir -p ${WRKDIR}/go/src/github.com/${_a}
mv ${WRKDIR}/${_p}-${_c:S/v//} ${WRKDIR}/go/src/github.com/${_a}/${_p}
.endfor
.include <bsd.port.mk>
On 2019/11/30 11:16, Philipp Buehler wrote:
> Hi porters,
>
> it's time to make a port out of my packer-vmm plugin.
> https://github.com/double-p/packer-builder-openbsd-vmm
>
> As this is my first ports try at all, I am missing something blatantly
> obvious.
>
> The Makefile is in 'examples/Makefile.ports' and trying a
> 'make fake' per Porters Guide, this fails like so:
> ===
> ==> Building for packer-builder-openbsd-vmm-0.9.0
> cd /usr/ports/pobj/packer-builder-openbsd-vmm-0.9.0/go/src/github.com/double-p/packer-builder-openbsd-vmm
> && GOMAXPROCS=1
> GOCACHE=/usr/ports/pobj/packer-builder-openbsd-vmm-0.9.0/go-cache
> GOPATH=/usr/ports/pobj/packer-builder-openbsd-vmm-0.9.0/go make
> builder/openbsd-vmm/builder.go:9:2: cannot find package
> "github.com/hashicorp/packer/common" in any of:
> /usr/local/go/src/github.com/hashicorp/packer/common (from $GOROOT)
> /usr/ports/pobj/packer-builder-openbsd-vmm-0.9.0/go/src/github.com/hashicorp/packer/common
> (from $GOPATH)
> ===
> ..and more of the same.
>
> Clearly I need to (let) fetch the required (sub)packages - but how? List all
> subs in go.mod?
> I was looking into several lang/go ports, but cant say I am getting the
> magic sauce :)
>
> TIA,
> --
> pb
>
Here's one way to do it.
Re: packer-vmm - how to retrieve go dependencies?
On Sat, Nov 30, 2019 at 11:16:39AM +0100, Philipp Buehler wrote:
> Hi porters,
>
> it's time to make a port out of my packer-vmm plugin.
> https://github.com/double-p/packer-builder-openbsd-vmm
>
> As this is my first ports try at all, I am missing something blatantly
> obvious.
>
> The Makefile is in 'examples/Makefile.ports' and trying a
> 'make fake' per Porters Guide, this fails like so:
> ===
> ==> Building for packer-builder-openbsd-vmm-0.9.0
> cd /usr/ports/pobj/packer-builder-openbsd-vmm-0.9.0/go/src/github.com/double-p/packer-builder-openbsd-vmm
> && GOMAXPROCS=1
> GOCACHE=/usr/ports/pobj/packer-builder-openbsd-vmm-0.9.0/go-cache
> GOPATH=/usr/ports/pobj/packer-builder-openbsd-vmm-0.9.0/go make
> builder/openbsd-vmm/builder.go:9:2: cannot find package
> "github.com/hashicorp/packer/common" in any of:
> /usr/local/go/src/github.com/hashicorp/packer/common (from $GOROOT)
> /usr/ports/pobj/packer-builder-openbsd-vmm-0.9.0/go/src/github.com/hashicorp/packer/common
> (from $GOPATH)
> ===
> ..and more of the same.
>
> Clearly I need to (let) fetch the required (sub)packages - but how? List all
> subs in go.mod?
> I was looking into several lang/go ports, but cant say I am getting the
> magic sauce :)
Use go vendoring :-)
So that the dependent code is part of your repo/tarball.
Usually it's a matter of "dep ensure -vendor-only" if you have the correct
plumbing.
--
Antoine
> Hi porters,
>
> it's time to make a port out of my packer-vmm plugin.
> https://github.com/double-p/packer-builder-openbsd-vmm
>
> As this is my first ports try at all, I am missing something blatantly
> obvious.
>
> The Makefile is in 'examples/Makefile.ports' and trying a
> 'make fake' per Porters Guide, this fails like so:
> ===
> ==> Building for packer-builder-openbsd-vmm-0.9.0
> cd /usr/ports/pobj/packer-builder-openbsd-vmm-0.9.0/go/src/github.com/double-p/packer-builder-openbsd-vmm
> && GOMAXPROCS=1
> GOCACHE=/usr/ports/pobj/packer-builder-openbsd-vmm-0.9.0/go-cache
> GOPATH=/usr/ports/pobj/packer-builder-openbsd-vmm-0.9.0/go make
> builder/openbsd-vmm/builder.go:9:2: cannot find package
> "github.com/hashicorp/packer/common" in any of:
> /usr/local/go/src/github.com/hashicorp/packer/common (from $GOROOT)
> /usr/ports/pobj/packer-builder-openbsd-vmm-0.9.0/go/src/github.com/hashicorp/packer/common
> (from $GOPATH)
> ===
> ..and more of the same.
>
> Clearly I need to (let) fetch the required (sub)packages - but how? List all
> subs in go.mod?
> I was looking into several lang/go ports, but cant say I am getting the
> magic sauce :)
Use go vendoring :-)
So that the dependent code is part of your repo/tarball.
Usually it's a matter of "dep ensure -vendor-only" if you have the correct
plumbing.
--
Antoine
Re: gettext-tools poisoning; allow LIB_DEPENDS
On Fri, Nov 29 2019, Stuart Henderson <stu@spacehopper.org> wrote:
> Currently we require BUILD_DEPENDS to avoid tripping the (very useful)
> poisoning that we have to detect ports with a missing dependency on
> gettext-tools. This used to be fine, but now gettext-tools includes
> libraries, a port may have LIB_DEPENDS instead of BUILD_DEPENDS.
>
> We could just require that those ports list a redundant BUILD_DEPENDS
> as well as the LIB_DEPENDS, but it's easy enough to handle the simple
> (i.e. not multi-packages) case.
>
> OK or is there a better idea?
I like the "required in BUILD_DEPENDS" approach, it's a simple rule that
doesn't introduce another subtle difference between multi-packages and
non-multi-packages ports. Maybe making the error message more explicit
would be enough?
(Suggestion below, feel free to find a better wording.)
Index: bsd.port.mk
===================================================================
RCS file: /cvs/ports/infrastructure/mk/bsd.port.mk,v
retrieving revision 1.1505
diff -u -p -r1.1505 bsd.port.mk
--- bsd.port.mk 26 Nov 2019 11:49:02 -0000 1.1505
+++ bsd.port.mk 30 Nov 2019 10:14:44 -0000
@@ -2608,7 +2608,7 @@ ${_WRKDIR_COOKIE}:
.if !defined(BUILD_DEPENDS) || !${BUILD_DEPENDS:Mdevel/gettext,-tools} && \
!${BUILD_DEPENDS:M*textproc/intltool}
@printf '#!/bin/sh\n\
- echo "*** $$0 was called without gettext-tools dependency ***" >&2\n\
+ echo "*** $$0 was called without gettext-tools dependency in BUILD_DEPENDS ***" >&2\n\
exit 1\n' ${_PREDIR} ${WRKDIR}/bin/msgfmt
@${_PBUILD} chmod 555 ${WRKDIR}/bin/msgfmt
. for name in msgcat msginit autopoint xgettext gettextize
--
jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF DDCC 0DFA 74AE 1524 E7EE
> Currently we require BUILD_DEPENDS to avoid tripping the (very useful)
> poisoning that we have to detect ports with a missing dependency on
> gettext-tools. This used to be fine, but now gettext-tools includes
> libraries, a port may have LIB_DEPENDS instead of BUILD_DEPENDS.
>
> We could just require that those ports list a redundant BUILD_DEPENDS
> as well as the LIB_DEPENDS, but it's easy enough to handle the simple
> (i.e. not multi-packages) case.
>
> OK or is there a better idea?
I like the "required in BUILD_DEPENDS" approach, it's a simple rule that
doesn't introduce another subtle difference between multi-packages and
non-multi-packages ports. Maybe making the error message more explicit
would be enough?
(Suggestion below, feel free to find a better wording.)
Index: bsd.port.mk
===================================================================
RCS file: /cvs/ports/infrastructure/mk/bsd.port.mk,v
retrieving revision 1.1505
diff -u -p -r1.1505 bsd.port.mk
--- bsd.port.mk 26 Nov 2019 11:49:02 -0000 1.1505
+++ bsd.port.mk 30 Nov 2019 10:14:44 -0000
@@ -2608,7 +2608,7 @@ ${_WRKDIR_COOKIE}:
.if !defined(BUILD_DEPENDS) || !${BUILD_DEPENDS:Mdevel/gettext,-tools} && \
!${BUILD_DEPENDS:M*textproc/intltool}
@printf '#!/bin/sh\n\
- echo "*** $$0 was called without gettext-tools dependency ***" >&2\n\
+ echo "*** $$0 was called without gettext-tools dependency in BUILD_DEPENDS ***" >&2\n\
exit 1\n' ${_PREDIR} ${WRKDIR}/bin/msgfmt
@${_PBUILD} chmod 555 ${WRKDIR}/bin/msgfmt
. for name in msgcat msginit autopoint xgettext gettextize
--
jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF DDCC 0DFA 74AE 1524 E7EE
packer-vmm - how to retrieve go dependencies?
Hi porters,
it's time to make a port out of my packer-vmm plugin.
https://github.com/double-p/packer-builder-openbsd-vmm
As this is my first ports try at all, I am missing something blatantly
obvious.
The Makefile is in 'examples/Makefile.ports' and trying a
'make fake' per Porters Guide, this fails like so:
===
==> Building for packer-builder-openbsd-vmm-0.9.0
cd
/usr/ports/pobj/packer-builder-openbsd-vmm-0.9.0/go/src/github.com/double-p/packer-builder-openbsd-vmm
&& GOMAXPROCS=1
GOCACHE=/usr/ports/pobj/packer-builder-openbsd-vmm-0.9.0/go-cache
GOPATH=/usr/ports/pobj/packer-builder-openbsd-vmm-0.9.0/go make
builder/openbsd-vmm/builder.go:9:2: cannot find package
"github.com/hashicorp/packer/common" in any of:
/usr/local/go/src/github.com/hashicorp/packer/common (from $GOROOT)
/usr/ports/pobj/packer-builder-openbsd-vmm-0.9.0/go/src/github.com/hashicorp/packer/common
(from $GOPATH)
===
..and more of the same.
Clearly I need to (let) fetch the required (sub)packages - but how? List
all subs in go.mod?
I was looking into several lang/go ports, but cant say I am getting the
magic sauce :)
TIA,
--
pb
it's time to make a port out of my packer-vmm plugin.
https://github.com/double-p/packer-builder-openbsd-vmm
As this is my first ports try at all, I am missing something blatantly
obvious.
The Makefile is in 'examples/Makefile.ports' and trying a
'make fake' per Porters Guide, this fails like so:
===
==> Building for packer-builder-openbsd-vmm-0.9.0
cd
/usr/ports/pobj/packer-builder-openbsd-vmm-0.9.0/go/src/github.com/double-p/packer-builder-openbsd-vmm
&& GOMAXPROCS=1
GOCACHE=/usr/ports/pobj/packer-builder-openbsd-vmm-0.9.0/go-cache
GOPATH=/usr/ports/pobj/packer-builder-openbsd-vmm-0.9.0/go make
builder/openbsd-vmm/builder.go:9:2: cannot find package
"github.com/hashicorp/packer/common" in any of:
/usr/local/go/src/github.com/hashicorp/packer/common (from $GOROOT)
/usr/ports/pobj/packer-builder-openbsd-vmm-0.9.0/go/src/github.com/hashicorp/packer/common
(from $GOPATH)
===
..and more of the same.
Clearly I need to (let) fetch the required (sub)packages - but how? List
all subs in go.mod?
I was looking into several lang/go ports, but cant say I am getting the
magic sauce :)
TIA,
--
pb
Re: Add MODPY_TEST (should be MODPY_PYTEST) as poisoned entry
On Fri, Nov 29 2019, Kurt Mosiejczuk <kurt@cranky.work> wrote:
> I'd like to add MODPY_TEST as a poisoned entry to mk.conf.template. I
> used to make this typo a lot. Things look like they work right, but
> pytest isn't getting used at that point, just the usual setuptools
> testing mechanism.
>
> ok?
I did the same error in a wip port. ok jca@ but please don't forget to
fix devel/angr/py-pyvex *first*:
--8<--
*** Parse error in /usr/ports/devel/angr/py-pyvex: Poisoned variable MODPY_TEST is already set
(/usr/ports/infrastructure/templates/mk.conf.template:53)
-->8--
> --Kurt
>
> Index: mk.conf.template
> ===================================================================
> RCS file: /cvs/ports/infrastructure/templates/mk.conf.template,v
> retrieving revision 1.27
> diff -u -p -r1.27 mk.conf.template
> --- mk.conf.template 6 Nov 2017 20:43:22 -0000 1.27
> +++ mk.conf.template 30 Nov 2019 00:37:52 -0000
> @@ -50,6 +50,7 @@
> .poison WKRDIST
> .poison WKRINST
> .poison WKRSRC
> +.poison MODPY_TEST
>
> # not a misspelling, but wrong, BUILD_DEPENDS isn't subpackaged
> .poison BUILD_DEPENDS-main
>
--
jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF DDCC 0DFA 74AE 1524 E7EE
> I'd like to add MODPY_TEST as a poisoned entry to mk.conf.template. I
> used to make this typo a lot. Things look like they work right, but
> pytest isn't getting used at that point, just the usual setuptools
> testing mechanism.
>
> ok?
I did the same error in a wip port. ok jca@ but please don't forget to
fix devel/angr/py-pyvex *first*:
--8<--
*** Parse error in /usr/ports/devel/angr/py-pyvex: Poisoned variable MODPY_TEST is already set
(/usr/ports/infrastructure/templates/mk.conf.template:53)
-->8--
> --Kurt
>
> Index: mk.conf.template
> ===================================================================
> RCS file: /cvs/ports/infrastructure/templates/mk.conf.template,v
> retrieving revision 1.27
> diff -u -p -r1.27 mk.conf.template
> --- mk.conf.template 6 Nov 2017 20:43:22 -0000 1.27
> +++ mk.conf.template 30 Nov 2019 00:37:52 -0000
> @@ -50,6 +50,7 @@
> .poison WKRDIST
> .poison WKRINST
> .poison WKRSRC
> +.poison MODPY_TEST
>
> # not a misspelling, but wrong, BUILD_DEPENDS isn't subpackaged
> .poison BUILD_DEPENDS-main
>
--
jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF DDCC 0DFA 74AE 1524 E7EE
Re: Packages for 6.6
-----BEGIN PGP SIGNATURE-----
iQIzBAEBCAAdFiEEiKQfd6o81mjI+LWALell7WOCXJMFAl3iP8YACgkQLell7WOC
XJM/Pg//SheJl5mBRsxoG+mbx+/Sivx7ybEYn5amVTFDKMWl1IPR9qOKwMwbZypG
wi7CWW6ZAQkCUzO1ob2Nd2y8fAnjAlKHa54zg4JkvpwTk7idwMw84u/6mFy26DWc
Fr8W8NGAL3nSy6UwSStjDFb1xdijNFAAwG0G7NUaF/Zs5+0nigs4sy3DqcEWTeZm
NfdyOfTg2ql5B7cNYsXEfTD2HLmZvS/iUDywZqZGLJbTuDz6Bf3JCIB1IWhJCN3G
h76juFM+n58CSS/VfDjFkPcCkfSSYF0LAuLcKPE3N+/ePqbWBuYl/lplcfvtGfRU
zqGF6YX1RlqZ2YP5tvjcQdKqKrs1bTpvs1DiLMAjaWLbR2/QyV3iZ4eM1SVkp2iI
H13cdf4DDsZfdAlQK/o0HWKUO3pY6O39oVcrH32LY3aMaFCSbGO45wX2ZDpJp01H
wbUVufhcWFoWarKGVUov37eS3apGThbzZTUA9jm+A5QJmMV9d95uHMHkisIDYfVH
Xyloh+dpguiQaE0inbllKMvXY80z9PJJNd9F3WU3usG1Qq7qzD3eX8uGaBMpho82
23tCZuQ1UBF/0BH0rZo8WHFHokZEWskvB1EzxIjA4Kn88xCC+W9Gzx99Lm2rP0ak
9TEmZJzhqp2YTfaS0HT6pImEt+NlqK4JwP9O3kTp0n7TWmaFcvo=
=bh0e
-----END PGP SIGNATURE-----
Thanks Stuart! Looking forward to it!
On 11/30/19 1:25 AM, Stuart Henderson wrote:
> Yes, probably in a couple of days. For now, use pkg_add -Dsnap.
>
> --
> Sent from a phone, apologies for poor formatting.
>
> On 30 November 2019 08:55:47 manphiz@gmail.com wrote:
>
>> Hi OpenBSD ports maintainers,
>>
>> It seems that mips64el packages for 6.6 are available according to the
>> OpenBSD 6.6 release page[1] and are available in snapshots tree[2].
>> Will they be copied into the 6.6 packages directories so that we can use
>> it directly? Thanks!
>>
>>
>> [1] https://www.openbsd.org/66.html
>> [2] https://ftp.openbsd.org/pub/OpenBSD/snapshots/packages/mips64el/
>
>
>
iQIzBAEBCAAdFiEEiKQfd6o81mjI+LWALell7WOCXJMFAl3iP8YACgkQLell7WOC
XJM/Pg//SheJl5mBRsxoG+mbx+/Sivx7ybEYn5amVTFDKMWl1IPR9qOKwMwbZypG
wi7CWW6ZAQkCUzO1ob2Nd2y8fAnjAlKHa54zg4JkvpwTk7idwMw84u/6mFy26DWc
Fr8W8NGAL3nSy6UwSStjDFb1xdijNFAAwG0G7NUaF/Zs5+0nigs4sy3DqcEWTeZm
NfdyOfTg2ql5B7cNYsXEfTD2HLmZvS/iUDywZqZGLJbTuDz6Bf3JCIB1IWhJCN3G
h76juFM+n58CSS/VfDjFkPcCkfSSYF0LAuLcKPE3N+/ePqbWBuYl/lplcfvtGfRU
zqGF6YX1RlqZ2YP5tvjcQdKqKrs1bTpvs1DiLMAjaWLbR2/QyV3iZ4eM1SVkp2iI
H13cdf4DDsZfdAlQK/o0HWKUO3pY6O39oVcrH32LY3aMaFCSbGO45wX2ZDpJp01H
wbUVufhcWFoWarKGVUov37eS3apGThbzZTUA9jm+A5QJmMV9d95uHMHkisIDYfVH
Xyloh+dpguiQaE0inbllKMvXY80z9PJJNd9F3WU3usG1Qq7qzD3eX8uGaBMpho82
23tCZuQ1UBF/0BH0rZo8WHFHokZEWskvB1EzxIjA4Kn88xCC+W9Gzx99Lm2rP0ak
9TEmZJzhqp2YTfaS0HT6pImEt+NlqK4JwP9O3kTp0n7TWmaFcvo=
=bh0e
-----END PGP SIGNATURE-----
Thanks Stuart! Looking forward to it!
On 11/30/19 1:25 AM, Stuart Henderson wrote:
> Yes, probably in a couple of days. For now, use pkg_add -Dsnap.
>
> --
> Sent from a phone, apologies for poor formatting.
>
> On 30 November 2019 08:55:47 manphiz@gmail.com wrote:
>
>> Hi OpenBSD ports maintainers,
>>
>> It seems that mips64el packages for 6.6 are available according to the
>> OpenBSD 6.6 release page[1] and are available in snapshots tree[2].
>> Will they be copied into the 6.6 packages directories so that we can use
>> it directly? Thanks!
>>
>>
>> [1] https://www.openbsd.org/66.html
>> [2] https://ftp.openbsd.org/pub/OpenBSD/snapshots/packages/mips64el/
>
>
>
Re: Packages for 6.6
Yes, probably in a couple of days. For now, use pkg_add -Dsnap.
--
Sent from a phone, apologies for poor formatting.
On 30 November 2019 08:55:47 manphiz@gmail.com wrote:
> Hi OpenBSD ports maintainers,
>
> It seems that mips64el packages for 6.6 are available according to the
> OpenBSD 6.6 release page[1] and are available in snapshots tree[2].
> Will they be copied into the 6.6 packages directories so that we can use
> it directly? Thanks!
>
>
> [1] https://www.openbsd.org/66.html
> [2] https://ftp.openbsd.org/pub/OpenBSD/snapshots/packages/mips64el/
--
Sent from a phone, apologies for poor formatting.
On 30 November 2019 08:55:47 manphiz@gmail.com wrote:
> Hi OpenBSD ports maintainers,
>
> It seems that mips64el packages for 6.6 are available according to the
> OpenBSD 6.6 release page[1] and are available in snapshots tree[2].
> Will they be copied into the 6.6 packages directories so that we can use
> it directly? Thanks!
>
>
> [1] https://www.openbsd.org/66.html
> [2] https://ftp.openbsd.org/pub/OpenBSD/snapshots/packages/mips64el/
"undefined reference to `__builtin_bswap64'" on mips64el/loongson
-----BEGIN PGP SIGNATURE-----
iQIzBAEBCAAdFiEEiKQfd6o81mjI+LWALell7WOCXJMFAl3iMiAACgkQLell7WOC
XJNPmg/+MDVZV/IBBDNZ6neCTsmchgBKE+NwiKjuZiq3QlPjRrpMdmZddFwptGJ4
3qfnClg8aI2iredI90g+QVV6+x17VWiP08fQYV9gv47iIug9sDZO/KeBLzgkB9Vw
GmRzIsRUKK6+8HajZmJwZciqbMKTvbiYch004ckJ6iVc5OZtX2cErk/xUZrSymQn
YtliiSoq2aDVKtkiROXOugY7bYZ9Q2VmeSk8iuD/PeEObt8vgzIlRHCNBqArBp01
6jFQUU7byBdry10ifILabEfTsQL11QiDu3RYy4kp8f/RmFtiGRtSIR8/GdFY1gru
au/UBeOq+7z1DY9JYD9stD9GMMR5xnuma9U9btRYStYrlI8qIB3OUC5f7GnAVtQi
W7xX6tgkRSIZiqhUxHUESHSIkcrZfYob1kQ5O8GtjJTUhphHNrsD8dsw2SJ8vgyZ
ZdjFVW51TmQt2SmM9l5vsPyDOupJkiVfdRVV3hI9ZlPu1w6VrO06fp50fKqDk/sq
masBRDY+5wth+pyfS9vocR7o+wy5TLOtOtkgA9iT5ivWGJF3mUdoqf2V+LTvnavg
TPJ2K1A8Xhok53Oy/asZzqPWX2fT6tRFRmOMNdpi3qGZmuDZ2txhjU7o9QRGFaRN
b+2QiZhO4NJpMDSKgJ8ZbpEjYxcRMvWAK8a1opTLSDyHongF8fQ=
=K+Yk
-----END PGP SIGNATURE-----
Hi OpenBSD ports maintainers,
I'm having trouble building security/libnettle on mips64el/loongson
which is caused by missing symbol of "__builtin_bswap64" when linking.
It looks like this symbol is introduced since GCC 4.3[1], while mips64el
ships with GCC 4.2.1. It's interesting because I can compile with the
symbol but cannot link. Would like to hear from the ports maintainers'
opinion on how to solve this issue?
Here are some tests for showing the problem (please let me know if you
need more information):
$ uname -a
OpenBSD yeeloong.lan 6.6 GENERIC#18 loongson
$ gcc -v
Reading specs from /usr/lib/gcc-lib/mips64el-unknown-openbsd6.6/4.2.1/specs
Target: mips64el-unknown-openbsd6.6
Configured with: OpenBSD/mips64el system compiler
Thread model: posix
gcc version 4.2.1 20070719
$ cat test.c
#include <stdint.h>
int
main ()
{
uint64_t x = 17;
uint64_t y = __builtin_bswap64(x);
;
return 0;
}
$ gcc -c test.c
$ gcc test.c
/tmp//ccw1b7KO.o: In function `main':
test.c:(.text+0x2c): undefined reference to `__builtin_bswap64'
test.c:(.text+0x30): undefined reference to `__builtin_bswap64'
collect2: ld returned 1 exit status
[1] http://gcc.gnu.org/onlinedocs/gcc-4.3.0/gcc/Other-Builtins.html
iQIzBAEBCAAdFiEEiKQfd6o81mjI+LWALell7WOCXJMFAl3iMiAACgkQLell7WOC
XJNPmg/+MDVZV/IBBDNZ6neCTsmchgBKE+NwiKjuZiq3QlPjRrpMdmZddFwptGJ4
3qfnClg8aI2iredI90g+QVV6+x17VWiP08fQYV9gv47iIug9sDZO/KeBLzgkB9Vw
GmRzIsRUKK6+8HajZmJwZciqbMKTvbiYch004ckJ6iVc5OZtX2cErk/xUZrSymQn
YtliiSoq2aDVKtkiROXOugY7bYZ9Q2VmeSk8iuD/PeEObt8vgzIlRHCNBqArBp01
6jFQUU7byBdry10ifILabEfTsQL11QiDu3RYy4kp8f/RmFtiGRtSIR8/GdFY1gru
au/UBeOq+7z1DY9JYD9stD9GMMR5xnuma9U9btRYStYrlI8qIB3OUC5f7GnAVtQi
W7xX6tgkRSIZiqhUxHUESHSIkcrZfYob1kQ5O8GtjJTUhphHNrsD8dsw2SJ8vgyZ
ZdjFVW51TmQt2SmM9l5vsPyDOupJkiVfdRVV3hI9ZlPu1w6VrO06fp50fKqDk/sq
masBRDY+5wth+pyfS9vocR7o+wy5TLOtOtkgA9iT5ivWGJF3mUdoqf2V+LTvnavg
TPJ2K1A8Xhok53Oy/asZzqPWX2fT6tRFRmOMNdpi3qGZmuDZ2txhjU7o9QRGFaRN
b+2QiZhO4NJpMDSKgJ8ZbpEjYxcRMvWAK8a1opTLSDyHongF8fQ=
=K+Yk
-----END PGP SIGNATURE-----
Hi OpenBSD ports maintainers,
I'm having trouble building security/libnettle on mips64el/loongson
which is caused by missing symbol of "__builtin_bswap64" when linking.
It looks like this symbol is introduced since GCC 4.3[1], while mips64el
ships with GCC 4.2.1. It's interesting because I can compile with the
symbol but cannot link. Would like to hear from the ports maintainers'
opinion on how to solve this issue?
Here are some tests for showing the problem (please let me know if you
need more information):
$ uname -a
OpenBSD yeeloong.lan 6.6 GENERIC#18 loongson
$ gcc -v
Reading specs from /usr/lib/gcc-lib/mips64el-unknown-openbsd6.6/4.2.1/specs
Target: mips64el-unknown-openbsd6.6
Configured with: OpenBSD/mips64el system compiler
Thread model: posix
gcc version 4.2.1 20070719
$ cat test.c
#include <stdint.h>
int
main ()
{
uint64_t x = 17;
uint64_t y = __builtin_bswap64(x);
;
return 0;
}
$ gcc -c test.c
$ gcc test.c
/tmp//ccw1b7KO.o: In function `main':
test.c:(.text+0x2c): undefined reference to `__builtin_bswap64'
test.c:(.text+0x30): undefined reference to `__builtin_bswap64'
collect2: ld returned 1 exit status
[1] http://gcc.gnu.org/onlinedocs/gcc-4.3.0/gcc/Other-Builtins.html
Packages for 6.6
-----BEGIN PGP SIGNATURE-----
iQIzBAEBCAAdFiEEiKQfd6o81mjI+LWALell7WOCXJMFAl3iLsAACgkQLell7WOC
XJMJsBAAn8kQAVC+z8U3a+DCphe9WheUeIQ0nQVIvmRbccsYxZtq1I0s2WWWsLYp
tLltfhEEjyFNLtPyIITgucL6gdN3xSMSODfwZrxXH6jVqJmIwexMXE2MTqayVGti
gQxD0gMSIpDgRU6U7hr6UhIilu9SNHlPlEdstVbvaKVSWT1rCdUKNp3S7dC4xblJ
hI+BK+ALlZzO2spaTbze7qmJCgOLjnQT0tnHJkjfu8eAiRwkSfuk8J5rw0g8adFh
+OS461gAr33oMrmcfNRdKlov3bCtnenPeR1GWpk33xswKiAspuw2gSc7miKpk+7i
DC7xEhlqjTLwj/qtN1ez4pa74tHn/SpDJZjbc8969JKyS6QUU8BDt7zSPVtlenYn
11TjLbR6vDoiYF7iOYWPzgUu34+6er0BzstdYcGjelsIpjGTuGA4V1fMAF/et1Wj
x/3tgbYiruZ5NxLSBnxwPW/ypaRyXh4U1IIfbFhsuIcn2YwFyf5D1g9VWS1zv+Ey
4BX2CcgLh84FKAQ8KQeh1+rL07cA200FzmzRBmUlt8BcntcvvI3W7aErIZicTqPO
dbj3OaX7b7vvd2PvR0PpNeVpR3jPxi2xTgOEXswv7O8oYRNDqkTiP+KwhsZDr417
59J+lrO26Pmk32Nv1dcllQ5G7G8Ezvo2BYg6q62Ou4bshPdOLLQ=
=DZE5
-----END PGP SIGNATURE-----
Hi OpenBSD ports maintainers,
It seems that mips64el packages for 6.6 are available according to the
OpenBSD 6.6 release page[1] and are available in snapshots tree[2].
Will they be copied into the 6.6 packages directories so that we can use
it directly? Thanks!
[1] https://www.openbsd.org/66.html
[2] https://ftp.openbsd.org/pub/OpenBSD/snapshots/packages/mips64el/
iQIzBAEBCAAdFiEEiKQfd6o81mjI+LWALell7WOCXJMFAl3iLsAACgkQLell7WOC
XJMJsBAAn8kQAVC+z8U3a+DCphe9WheUeIQ0nQVIvmRbccsYxZtq1I0s2WWWsLYp
tLltfhEEjyFNLtPyIITgucL6gdN3xSMSODfwZrxXH6jVqJmIwexMXE2MTqayVGti
gQxD0gMSIpDgRU6U7hr6UhIilu9SNHlPlEdstVbvaKVSWT1rCdUKNp3S7dC4xblJ
hI+BK+ALlZzO2spaTbze7qmJCgOLjnQT0tnHJkjfu8eAiRwkSfuk8J5rw0g8adFh
+OS461gAr33oMrmcfNRdKlov3bCtnenPeR1GWpk33xswKiAspuw2gSc7miKpk+7i
DC7xEhlqjTLwj/qtN1ez4pa74tHn/SpDJZjbc8969JKyS6QUU8BDt7zSPVtlenYn
11TjLbR6vDoiYF7iOYWPzgUu34+6er0BzstdYcGjelsIpjGTuGA4V1fMAF/et1Wj
x/3tgbYiruZ5NxLSBnxwPW/ypaRyXh4U1IIfbFhsuIcn2YwFyf5D1g9VWS1zv+Ey
4BX2CcgLh84FKAQ8KQeh1+rL07cA200FzmzRBmUlt8BcntcvvI3W7aErIZicTqPO
dbj3OaX7b7vvd2PvR0PpNeVpR3jPxi2xTgOEXswv7O8oYRNDqkTiP+KwhsZDr417
59J+lrO26Pmk32Nv1dcllQ5G7G8Ezvo2BYg6q62Ou4bshPdOLLQ=
=DZE5
-----END PGP SIGNATURE-----
Hi OpenBSD ports maintainers,
It seems that mips64el packages for 6.6 are available according to the
OpenBSD 6.6 release page[1] and are available in snapshots tree[2].
Will they be copied into the 6.6 packages directories so that we can use
it directly? Thanks!
[1] https://www.openbsd.org/66.html
[2] https://ftp.openbsd.org/pub/OpenBSD/snapshots/packages/mips64el/
Friday, November 29, 2019
Re: new: net/py-transmissionrpc-ng
On Thu, Nov 28, 2019 at 06:31:41PM +0100, Paco Esteban wrote:
> Here's a new port for transmissionrpc python module.
> This is a simple one, it only depends on py-curl.
> All tests pass and works fine for me on amd64.
A few minor things.
First, you've got spaces for indentiation rather than tabs, that needs to
be fixed.
Second, a mistake I've made in the past, you have "MODPY_TEST" and not
"MODPY_PYTEST". That needs to be corrected and then add a line
"MODPY_PYTEST_ARGS = test/*.py"
The tests all pass on amd64 and sparc64 for me, so make those changes
and ok kmos
--Kurt
> Here's a new port for transmissionrpc python module.
> This is a simple one, it only depends on py-curl.
> All tests pass and works fine for me on amd64.
A few minor things.
First, you've got spaces for indentiation rather than tabs, that needs to
be fixed.
Second, a mistake I've made in the past, you have "MODPY_TEST" and not
"MODPY_PYTEST". That needs to be corrected and then add a line
"MODPY_PYTEST_ARGS = test/*.py"
The tests all pass on amd64 and sparc64 for me, so make those changes
and ok kmos
--Kurt
Add MODPY_TEST (should be MODPY_PYTEST) as poisoned entry
I'd like to add MODPY_TEST as a poisoned entry to mk.conf.template. I
used to make this typo a lot. Things look like they work right, but
pytest isn't getting used at that point, just the usual setuptools
testing mechanism.
ok?
--Kurt
Index: mk.conf.template
===================================================================
RCS file: /cvs/ports/infrastructure/templates/mk.conf.template,v
retrieving revision 1.27
diff -u -p -r1.27 mk.conf.template
--- mk.conf.template 6 Nov 2017 20:43:22 -0000 1.27
+++ mk.conf.template 30 Nov 2019 00:37:52 -0000
@@ -50,6 +50,7 @@
.poison WKRDIST
.poison WKRINST
.poison WKRSRC
+.poison MODPY_TEST
# not a misspelling, but wrong, BUILD_DEPENDS isn't subpackaged
.poison BUILD_DEPENDS-main
used to make this typo a lot. Things look like they work right, but
pytest isn't getting used at that point, just the usual setuptools
testing mechanism.
ok?
--Kurt
Index: mk.conf.template
===================================================================
RCS file: /cvs/ports/infrastructure/templates/mk.conf.template,v
retrieving revision 1.27
diff -u -p -r1.27 mk.conf.template
--- mk.conf.template 6 Nov 2017 20:43:22 -0000 1.27
+++ mk.conf.template 30 Nov 2019 00:37:52 -0000
@@ -50,6 +50,7 @@
.poison WKRDIST
.poison WKRINST
.poison WKRSRC
+.poison MODPY_TEST
# not a misspelling, but wrong, BUILD_DEPENDS isn't subpackaged
.poison BUILD_DEPENDS-main
Re: Update: cad/kicad 5.1.4 >> 5.1.5
On Fri, 22 Nov 2019, Tracey Emery wrote:
> On Fri, Nov 22, 2019 at 01:49:57PM -0500, James Turner wrote:
> >
> > Once EPOCH has been added to a port, you can't remove it.
>
> The universe is once again, back in order. Epoch restored.
Tested on amd64. Builds, installs and runs ok for me (cad/kicad-share
too).
Thanks for the update !
--
Paco Esteban.
5818130B8A6DBC03
> On Fri, Nov 22, 2019 at 01:49:57PM -0500, James Turner wrote:
> >
> > Once EPOCH has been added to a port, you can't remove it.
>
> The universe is once again, back in order. Epoch restored.
Tested on amd64. Builds, installs and runs ok for me (cad/kicad-share
too).
Thanks for the update !
--
Paco Esteban.
5818130B8A6DBC03
Re: Installing OpenBSD -current snapshots
On Fri, 29 Nov 2019, Clay Daniels wrote:
> Date: Fri, 29 Nov 2019 12:55:43 -0600
> From: Clay Daniels <clay.daniels.jr@gmail.com>
> To: "misc@openbsd.org" <misc@openbsd.org>
> Subject: Re: Installing OpenBSD -current snapshots
>
> Thanks to everyone who responded. If I knew all the answers I would not
> have asked. And I should have read deeper into the documentation before
> asking, and am in the process of doing so now.
>
> What I decided was to stick with the release install66.fs boot image. It
> works to completely install everything without floundering around to find
> the file sets. I really have no need to run current OpenBSD. Maybe after a
> few months of study I will think about it again.
>
> Also I'm going to unsubscribe with this email account, and re-subscribe
> with my account with sdf.org where I will not be stuck with google's
> "top-posting". I don't like it either, same as everyone else.
Ok, this is my real unix email, run on netbsd. I use it via ssh in
good old alpine. No more top-posting for me!
> Date: Fri, 29 Nov 2019 12:55:43 -0600
> From: Clay Daniels <clay.daniels.jr@gmail.com>
> To: "misc@openbsd.org" <misc@openbsd.org>
> Subject: Re: Installing OpenBSD -current snapshots
>
> Thanks to everyone who responded. If I knew all the answers I would not
> have asked. And I should have read deeper into the documentation before
> asking, and am in the process of doing so now.
>
> What I decided was to stick with the release install66.fs boot image. It
> works to completely install everything without floundering around to find
> the file sets. I really have no need to run current OpenBSD. Maybe after a
> few months of study I will think about it again.
>
> Also I'm going to unsubscribe with this email account, and re-subscribe
> with my account with sdf.org where I will not be stuck with google's
> "top-posting". I don't like it either, same as everyone else.
Ok, this is my real unix email, run on netbsd. I use it via ssh in
good old alpine. No more top-posting for me!
Re: SIGBUS on octeon for my program
Be warned that __packed doesn't do quite what you think it does.
void func(int *p) {
*p = 0;
}
If you pass an unaligned pointer into this function on a strict-alignment
platform, your program will likely crash. I am unaware of any attribute
that can inform the compiler that 'p' may be misaligned.
--david
On Fri, Nov 29, 2019 at 2:54 AM Peter J. Philipp <pjp@centroid.eu> wrote:
> On Thu, Nov 28, 2019 at 11:44:07PM -0700, Theo de Raadt wrote:
> > Half the cpu platforms fault on unaligned access.
> >
> > There are strategies for handling this. Your code must use them.
> >
> > It is kind of boring, actually.
>
> I took a look at how libasr does it, and I have similar code ie. pack8(),
> pack16(), pack32(), I will just change all my functions, as unalignment
> flags passed per -m aren't standard on every arch. I did use __packed on
> structs already but the way libasr does is a great example I think.
>
> It's a bit of work but the fact that this could work on architectures like
> octeon make it worth it for me.
>
> Thanks a lot!
> -peter
>
>
void func(int *p) {
*p = 0;
}
If you pass an unaligned pointer into this function on a strict-alignment
platform, your program will likely crash. I am unaware of any attribute
that can inform the compiler that 'p' may be misaligned.
--david
On Fri, Nov 29, 2019 at 2:54 AM Peter J. Philipp <pjp@centroid.eu> wrote:
> On Thu, Nov 28, 2019 at 11:44:07PM -0700, Theo de Raadt wrote:
> > Half the cpu platforms fault on unaligned access.
> >
> > There are strategies for handling this. Your code must use them.
> >
> > It is kind of boring, actually.
>
> I took a look at how libasr does it, and I have similar code ie. pack8(),
> pack16(), pack32(), I will just change all my functions, as unalignment
> flags passed per -m aren't standard on every arch. I did use __packed on
> structs already but the way libasr does is a great example I think.
>
> It's a bit of work but the fact that this could work on architectures like
> octeon make it worth it for me.
>
> Thanks a lot!
> -peter
>
>
Re: Installing OpenBSD -current snapshots
Thanks to everyone who responded. If I knew all the answers I would not
have asked. And I should have read deeper into the documentation before
asking, and am in the process of doing so now.
What I decided was to stick with the release install66.fs boot image. It
works to completely install everything without floundering around to find
the file sets. I really have no need to run current OpenBSD. Maybe after a
few months of study I will think about it again.
Also I'm going to unsubscribe with this email account, and re-subscribe
with my account with sdf.org where I will not be stuck with google's
"top-posting". I don't like it either, same as everyone else.
Clay
have asked. And I should have read deeper into the documentation before
asking, and am in the process of doing so now.
What I decided was to stick with the release install66.fs boot image. It
works to completely install everything without floundering around to find
the file sets. I really have no need to run current OpenBSD. Maybe after a
few months of study I will think about it again.
Also I'm going to unsubscribe with this email account, and re-subscribe
with my account with sdf.org where I will not be stuck with google's
"top-posting". I don't like it either, same as everyone else.
Clay
Re: UPDATE: sysutils/cloud-agent
On Fri, Nov 29, 2019 at 05:59:50PM +0000, Reyk Floeter wrote:
> we have CMS (again), so there's no need to compile the built-in cms
> binary in cloud-agent anymore. Yay! The USE_LIBRESSL_CMS make flag is
> only needed as long as opensslv.h reports <=3.0.2 as the version
> number.
OK kn
> we have CMS (again), so there's no need to compile the built-in cms
> binary in cloud-agent anymore. Yay! The USE_LIBRESSL_CMS make flag is
> only needed as long as opensslv.h reports <=3.0.2 as the version
> number.
OK kn
UPDATE: sysutils/cloud-agent
Hi,
we have CMS (again), so there's no need to compile the built-in cms
binary in cloud-agent anymore. Yay! The USE_LIBRESSL_CMS make flag is
only needed as long as opensslv.h reports <=3.0.2 as the version
number.
## v1.1 (2019-11-29)
* Append `/etc/resolv.conf.tail` to `/etc/resolv.conf` if it exists.
* Use `openssl cms` in LibreSSL >3.0.2 (starting with OpenBSD 6.6-current).
OK?
Reyk
Index: sysutils/cloud-agent/Makefile
===================================================================
RCS file: /cvs/ports/sysutils/cloud-agent/Makefile,v
retrieving revision 1.5
diff -u -p -u -p -r1.5 Makefile
--- sysutils/cloud-agent/Makefile 12 Jul 2019 20:49:40 -0000 1.5
+++ sysutils/cloud-agent/Makefile 29 Nov 2019 17:56:46 -0000
@@ -2,7 +2,7 @@
COMMENT= cloud provisioning for OpenBSD VMs
-V= 0.9
+V= 1.1
DISTNAME= cloud-agent-$V
CATEGORIES= sysutils
HOMEPAGE= https://github.com/reyk/cloud-agent/
@@ -15,5 +15,8 @@ PERMIT_PACKAGE= Yes
MASTER_SITES= ${HOMEPAGE}releases/download/v${V}/
WANTLIB= c crypto expat ssl tls util
+
+# This can be removed after LibreSSL >3.0.2 is released
+MAKE_FLAGS= USE_LIBRESSL_CMS=1
.include <bsd.port.mk>
Index: sysutils/cloud-agent/distinfo
===================================================================
RCS file: /cvs/ports/sysutils/cloud-agent/distinfo,v
retrieving revision 1.3
diff -u -p -u -p -r1.3 distinfo
--- sysutils/cloud-agent/distinfo 26 Jun 2019 14:02:36 -0000 1.3
+++ sysutils/cloud-agent/distinfo 29 Nov 2019 17:56:46 -0000
@@ -1,2 +1,2 @@
-SHA256 (cloud-agent-0.9.tar.gz) = wLO7B/lbf0UniI7lexIpIWjUwg+/5GNaZCUjjiEKsqo=
-SIZE (cloud-agent-0.9.tar.gz) = 137118
+SHA256 (cloud-agent-1.1.tar.gz) = mDvjUjeNkd/WWUZgOjt8DBIYyR7Gq/5jjFrSw3n69fg=
+SIZE (cloud-agent-1.1.tar.gz) = 136965
Index: sysutils/cloud-agent/pkg/PLIST
===================================================================
RCS file: /cvs/ports/sysutils/cloud-agent/pkg/PLIST,v
retrieving revision 1.1.1.1
diff -u -p -u -p -r1.1.1.1 PLIST
--- sysutils/cloud-agent/pkg/PLIST 16 May 2018 11:58:32 -0000 1.1.1.1
+++ sysutils/cloud-agent/pkg/PLIST 29 Nov 2019 17:56:46 -0000
@@ -1,4 +1,3 @@
@comment $OpenBSD: PLIST,v 1.1.1.1 2018/05/16 11:58:32 reyk Exp $
-@bin bin/cms
@bin libexec/cloud-agent
@man man/man8/cloud-agent.8
we have CMS (again), so there's no need to compile the built-in cms
binary in cloud-agent anymore. Yay! The USE_LIBRESSL_CMS make flag is
only needed as long as opensslv.h reports <=3.0.2 as the version
number.
## v1.1 (2019-11-29)
* Append `/etc/resolv.conf.tail` to `/etc/resolv.conf` if it exists.
* Use `openssl cms` in LibreSSL >3.0.2 (starting with OpenBSD 6.6-current).
OK?
Reyk
Index: sysutils/cloud-agent/Makefile
===================================================================
RCS file: /cvs/ports/sysutils/cloud-agent/Makefile,v
retrieving revision 1.5
diff -u -p -u -p -r1.5 Makefile
--- sysutils/cloud-agent/Makefile 12 Jul 2019 20:49:40 -0000 1.5
+++ sysutils/cloud-agent/Makefile 29 Nov 2019 17:56:46 -0000
@@ -2,7 +2,7 @@
COMMENT= cloud provisioning for OpenBSD VMs
-V= 0.9
+V= 1.1
DISTNAME= cloud-agent-$V
CATEGORIES= sysutils
HOMEPAGE= https://github.com/reyk/cloud-agent/
@@ -15,5 +15,8 @@ PERMIT_PACKAGE= Yes
MASTER_SITES= ${HOMEPAGE}releases/download/v${V}/
WANTLIB= c crypto expat ssl tls util
+
+# This can be removed after LibreSSL >3.0.2 is released
+MAKE_FLAGS= USE_LIBRESSL_CMS=1
.include <bsd.port.mk>
Index: sysutils/cloud-agent/distinfo
===================================================================
RCS file: /cvs/ports/sysutils/cloud-agent/distinfo,v
retrieving revision 1.3
diff -u -p -u -p -r1.3 distinfo
--- sysutils/cloud-agent/distinfo 26 Jun 2019 14:02:36 -0000 1.3
+++ sysutils/cloud-agent/distinfo 29 Nov 2019 17:56:46 -0000
@@ -1,2 +1,2 @@
-SHA256 (cloud-agent-0.9.tar.gz) = wLO7B/lbf0UniI7lexIpIWjUwg+/5GNaZCUjjiEKsqo=
-SIZE (cloud-agent-0.9.tar.gz) = 137118
+SHA256 (cloud-agent-1.1.tar.gz) = mDvjUjeNkd/WWUZgOjt8DBIYyR7Gq/5jjFrSw3n69fg=
+SIZE (cloud-agent-1.1.tar.gz) = 136965
Index: sysutils/cloud-agent/pkg/PLIST
===================================================================
RCS file: /cvs/ports/sysutils/cloud-agent/pkg/PLIST,v
retrieving revision 1.1.1.1
diff -u -p -u -p -r1.1.1.1 PLIST
--- sysutils/cloud-agent/pkg/PLIST 16 May 2018 11:58:32 -0000 1.1.1.1
+++ sysutils/cloud-agent/pkg/PLIST 29 Nov 2019 17:56:46 -0000
@@ -1,4 +1,3 @@
@comment $OpenBSD: PLIST,v 1.1.1.1 2018/05/16 11:58:32 reyk Exp $
-@bin bin/cms
@bin libexec/cloud-agent
@man man/man8/cloud-agent.8
Re: UPDATE: VLC 3.0.8
On Sun, 24 Nov 2019 20:12:33 -0500
Brad Smith <brad@comstyle.com> wrote:
> Here is an update to VLC 3.0.8.
>
> Please test.
>
> Also needs build testing with ports-gcc.
>
I built it on macppc (with ports-gcc 8.3.0).
The build of vlc 3.0.8 succeeded.
I tried to play a DVD (using the DVD drive in my PowerBook G4). The
cpu at apm -L (666 MHz) was too slow; apm -A (up to 1333 MHz) was
better. Also, the default video output was broken; it showed a black
screen (except for the highlighted "Play All" menu item). I used
Tools -> Preferences -> Video to change the output from Automatic to
XVideo (XCB); this fixed my video. The problem with the default video
might be in Xorg or Mesa; I don't know if OpenGL video ever worked on
this PowerBook5,4 (radeondrm; ATI Radeon Mobility M10; ATI RV350).
I didn't try older version of vlc.
--George
Brad Smith <brad@comstyle.com> wrote:
> Here is an update to VLC 3.0.8.
>
> Please test.
>
> Also needs build testing with ports-gcc.
>
I built it on macppc (with ports-gcc 8.3.0).
The build of vlc 3.0.8 succeeded.
I tried to play a DVD (using the DVD drive in my PowerBook G4). The
cpu at apm -L (666 MHz) was too slow; apm -A (up to 1333 MHz) was
better. Also, the default video output was broken; it showed a black
screen (except for the highlighted "Play All" menu item). I used
Tools -> Preferences -> Video to change the output from Automatic to
XVideo (XCB); this fixed my video. The problem with the default video
might be in Xorg or Mesa; I don't know if OpenGL video ever worked on
this PowerBook5,4 (radeondrm; ATI Radeon Mobility M10; ATI RV350).
I didn't try older version of vlc.
--George
Re: Update net/py-websocket-client to 0.56.0
? diff_py-websocket-client-0.56.0
Index: Makefile
===================================================================
RCS file: /cvs/ports/net/py-websocket-client/Makefile,v
retrieving revision 1.8
diff -u -r1.8 Makefile
--- Makefile 12 Jul 2019 20:48:46 -0000 1.8
+++ Makefile 29 Nov 2019 16:09:56 -0000
@@ -2,16 +2,17 @@
COMMENT = WebSocket client for Python
-MODPY_EGG_VERSION = 0.37.0
+MODPY_EGG_VERSION = 0.56.0
DISTNAME = websocket_client-${MODPY_EGG_VERSION}
PKGNAME = py-websocket-client-${MODPY_EGG_VERSION}
-REVISION = 2
CATEGORIES = net
-HOMEPAGE = https://github.com/liris/websocket-client
+HOMEPAGE = https://github.com/websocket-client/websocket-client
-# LGPLv2.1+
+MAINTAINER = Clem Atis <clematis@insiberia.net>
+
+# BSD 3-Clause
PERMIT_PACKAGE = Yes
MODPY_PI = Yes
Index: distinfo
===================================================================
RCS file: /cvs/ports/net/py-websocket-client/distinfo,v
retrieving revision 1.3
diff -u -r1.3 distinfo
--- distinfo 3 Nov 2016 10:12:49 -0000 1.3
+++ distinfo 29 Nov 2019 16:09:56 -0000
@@ -1,2 +1,2 @@
-SHA256 (websocket_client-0.37.0.tar.gz) = Z4skbYFrlAGK9Sl+cpFRYOL+sELgzeGpOX9QKsOlL0E=
-SIZE (websocket_client-0.37.0.tar.gz) = 194246
+SHA256 (websocket_client-0.56.0.tar.gz) = H9VSCHi2i4S1dIuzDlkrENCpFSnVOD909JZOcrKX/To=
+SIZE (websocket_client-0.56.0.tar.gz) = 36951
Index: pkg/PLIST
===================================================================
RCS file: /cvs/ports/net/py-websocket-client/pkg/PLIST,v
retrieving revision 1.2
diff -u -r1.2 PLIST
--- pkg/PLIST 7 Dec 2015 21:16:25 -0000 1.2
+++ pkg/PLIST 29 Nov 2019 16:09:56 -0000
@@ -6,6 +6,7 @@
lib/python${MODPY_VERSION}/site-packages/websocket/${MODPY_PYCACHE}__init__.${MODPY_PYC_MAGIC_TAG}pyc
lib/python${MODPY_VERSION}/site-packages/websocket/${MODPY_PYCACHE}_abnf.${MODPY_PYC_MAGIC_TAG}pyc
lib/python${MODPY_VERSION}/site-packages/websocket/${MODPY_PYCACHE}_app.${MODPY_PYC_MAGIC_TAG}pyc
+lib/python${MODPY_VERSION}/site-packages/websocket/${MODPY_PYCACHE}_cookiejar.${MODPY_PYC_MAGIC_TAG}pyc
lib/python${MODPY_VERSION}/site-packages/websocket/${MODPY_PYCACHE}_core.${MODPY_PYC_MAGIC_TAG}pyc
lib/python${MODPY_VERSION}/site-packages/websocket/${MODPY_PYCACHE}_exceptions.${MODPY_PYC_MAGIC_TAG}pyc
lib/python${MODPY_VERSION}/site-packages/websocket/${MODPY_PYCACHE}_handshake.${MODPY_PYC_MAGIC_TAG}pyc
@@ -17,6 +18,7 @@
lib/python${MODPY_VERSION}/site-packages/websocket/${MODPY_PYCACHE}_utils.${MODPY_PYC_MAGIC_TAG}pyc
lib/python${MODPY_VERSION}/site-packages/websocket/_abnf.py
lib/python${MODPY_VERSION}/site-packages/websocket/_app.py
+lib/python${MODPY_VERSION}/site-packages/websocket/_cookiejar.py
lib/python${MODPY_VERSION}/site-packages/websocket/_core.py
lib/python${MODPY_VERSION}/site-packages/websocket/_exceptions.py
lib/python${MODPY_VERSION}/site-packages/websocket/_handshake.py
@@ -26,15 +28,16 @@
lib/python${MODPY_VERSION}/site-packages/websocket/_ssl_compat.py
lib/python${MODPY_VERSION}/site-packages/websocket/_url.py
lib/python${MODPY_VERSION}/site-packages/websocket/_utils.py
-lib/python${MODPY_VERSION}/site-packages/websocket/cacert.pem
lib/python${MODPY_VERSION}/site-packages/websocket/tests/
lib/python${MODPY_VERSION}/site-packages/websocket/tests/__init__.py
${MODPY_COMMENT}lib/python${MODPY_VERSION}/site-packages/websocket/tests/${MODPY_PYCACHE}/
lib/python${MODPY_VERSION}/site-packages/websocket/tests/${MODPY_PYCACHE}__init__.${MODPY_PYC_MAGIC_TAG}pyc
+lib/python${MODPY_VERSION}/site-packages/websocket/tests/${MODPY_PYCACHE}test_cookiejar.${MODPY_PYC_MAGIC_TAG}pyc
lib/python${MODPY_VERSION}/site-packages/websocket/tests/${MODPY_PYCACHE}test_websocket.${MODPY_PYC_MAGIC_TAG}pyc
lib/python${MODPY_VERSION}/site-packages/websocket/tests/data/
lib/python${MODPY_VERSION}/site-packages/websocket/tests/data/header01.txt
lib/python${MODPY_VERSION}/site-packages/websocket/tests/data/header02.txt
+lib/python${MODPY_VERSION}/site-packages/websocket/tests/test_cookiejar.py
lib/python${MODPY_VERSION}/site-packages/websocket/tests/test_websocket.py
lib/python${MODPY_VERSION}/site-packages/websocket_client-${MODPY_EGG_VERSION}-py${MODPY_VERSION}.egg-info/
lib/python${MODPY_VERSION}/site-packages/websocket_client-${MODPY_EGG_VERSION}-py${MODPY_VERSION}.egg-info/PKG-INFO
On Fri, Nov 29, 2019 at 04:26:38PM +0100, clematis wrote:
> On Thu, Nov 28, 2019 at 12:20:33PM -0500, Kurt Mosiejczuk wrote:
> > On Thu, Nov 28, 2019 at 12:55:17PM +0100, clematis wrote:
> > You just changed the PKGNAME with that change. You need the old PKGNAME
> > line back in there.
>
> Oops you're right - I've missed that, wanted to simplify PKGNAME but
> missed the underscore change.
>
> > According to the setup.py, the package requires py-six. Why are you
> > dropping it?
>
> I need to go back to what I've done back in September.
>
> I am traveling with limited access to this. I will reply to this thread
> once I get this clarified.
>
> Thanks for checking and for your feedback.
> Cheers,
Ok, here's a new diff not altering the pkgname. py-six is back as per
setup.py and doc. (I don't have time right now but will be worth
checking why this didn't show up as a problem earlier).
Since I was at it I've also tested a dep:
multimedia/streamlink:
test: Ran 867 tests OK
run: OK
Cheers,
--
clematis (0x7e96fd2400fe7b59)
Index: Makefile
===================================================================
RCS file: /cvs/ports/net/py-websocket-client/Makefile,v
retrieving revision 1.8
diff -u -r1.8 Makefile
--- Makefile 12 Jul 2019 20:48:46 -0000 1.8
+++ Makefile 29 Nov 2019 16:09:56 -0000
@@ -2,16 +2,17 @@
COMMENT = WebSocket client for Python
-MODPY_EGG_VERSION = 0.37.0
+MODPY_EGG_VERSION = 0.56.0
DISTNAME = websocket_client-${MODPY_EGG_VERSION}
PKGNAME = py-websocket-client-${MODPY_EGG_VERSION}
-REVISION = 2
CATEGORIES = net
-HOMEPAGE = https://github.com/liris/websocket-client
+HOMEPAGE = https://github.com/websocket-client/websocket-client
-# LGPLv2.1+
+MAINTAINER = Clem Atis <clematis@insiberia.net>
+
+# BSD 3-Clause
PERMIT_PACKAGE = Yes
MODPY_PI = Yes
Index: distinfo
===================================================================
RCS file: /cvs/ports/net/py-websocket-client/distinfo,v
retrieving revision 1.3
diff -u -r1.3 distinfo
--- distinfo 3 Nov 2016 10:12:49 -0000 1.3
+++ distinfo 29 Nov 2019 16:09:56 -0000
@@ -1,2 +1,2 @@
-SHA256 (websocket_client-0.37.0.tar.gz) = Z4skbYFrlAGK9Sl+cpFRYOL+sELgzeGpOX9QKsOlL0E=
-SIZE (websocket_client-0.37.0.tar.gz) = 194246
+SHA256 (websocket_client-0.56.0.tar.gz) = H9VSCHi2i4S1dIuzDlkrENCpFSnVOD909JZOcrKX/To=
+SIZE (websocket_client-0.56.0.tar.gz) = 36951
Index: pkg/PLIST
===================================================================
RCS file: /cvs/ports/net/py-websocket-client/pkg/PLIST,v
retrieving revision 1.2
diff -u -r1.2 PLIST
--- pkg/PLIST 7 Dec 2015 21:16:25 -0000 1.2
+++ pkg/PLIST 29 Nov 2019 16:09:56 -0000
@@ -6,6 +6,7 @@
lib/python${MODPY_VERSION}/site-packages/websocket/${MODPY_PYCACHE}__init__.${MODPY_PYC_MAGIC_TAG}pyc
lib/python${MODPY_VERSION}/site-packages/websocket/${MODPY_PYCACHE}_abnf.${MODPY_PYC_MAGIC_TAG}pyc
lib/python${MODPY_VERSION}/site-packages/websocket/${MODPY_PYCACHE}_app.${MODPY_PYC_MAGIC_TAG}pyc
+lib/python${MODPY_VERSION}/site-packages/websocket/${MODPY_PYCACHE}_cookiejar.${MODPY_PYC_MAGIC_TAG}pyc
lib/python${MODPY_VERSION}/site-packages/websocket/${MODPY_PYCACHE}_core.${MODPY_PYC_MAGIC_TAG}pyc
lib/python${MODPY_VERSION}/site-packages/websocket/${MODPY_PYCACHE}_exceptions.${MODPY_PYC_MAGIC_TAG}pyc
lib/python${MODPY_VERSION}/site-packages/websocket/${MODPY_PYCACHE}_handshake.${MODPY_PYC_MAGIC_TAG}pyc
@@ -17,6 +18,7 @@
lib/python${MODPY_VERSION}/site-packages/websocket/${MODPY_PYCACHE}_utils.${MODPY_PYC_MAGIC_TAG}pyc
lib/python${MODPY_VERSION}/site-packages/websocket/_abnf.py
lib/python${MODPY_VERSION}/site-packages/websocket/_app.py
+lib/python${MODPY_VERSION}/site-packages/websocket/_cookiejar.py
lib/python${MODPY_VERSION}/site-packages/websocket/_core.py
lib/python${MODPY_VERSION}/site-packages/websocket/_exceptions.py
lib/python${MODPY_VERSION}/site-packages/websocket/_handshake.py
@@ -26,15 +28,16 @@
lib/python${MODPY_VERSION}/site-packages/websocket/_ssl_compat.py
lib/python${MODPY_VERSION}/site-packages/websocket/_url.py
lib/python${MODPY_VERSION}/site-packages/websocket/_utils.py
-lib/python${MODPY_VERSION}/site-packages/websocket/cacert.pem
lib/python${MODPY_VERSION}/site-packages/websocket/tests/
lib/python${MODPY_VERSION}/site-packages/websocket/tests/__init__.py
${MODPY_COMMENT}lib/python${MODPY_VERSION}/site-packages/websocket/tests/${MODPY_PYCACHE}/
lib/python${MODPY_VERSION}/site-packages/websocket/tests/${MODPY_PYCACHE}__init__.${MODPY_PYC_MAGIC_TAG}pyc
+lib/python${MODPY_VERSION}/site-packages/websocket/tests/${MODPY_PYCACHE}test_cookiejar.${MODPY_PYC_MAGIC_TAG}pyc
lib/python${MODPY_VERSION}/site-packages/websocket/tests/${MODPY_PYCACHE}test_websocket.${MODPY_PYC_MAGIC_TAG}pyc
lib/python${MODPY_VERSION}/site-packages/websocket/tests/data/
lib/python${MODPY_VERSION}/site-packages/websocket/tests/data/header01.txt
lib/python${MODPY_VERSION}/site-packages/websocket/tests/data/header02.txt
+lib/python${MODPY_VERSION}/site-packages/websocket/tests/test_cookiejar.py
lib/python${MODPY_VERSION}/site-packages/websocket/tests/test_websocket.py
lib/python${MODPY_VERSION}/site-packages/websocket_client-${MODPY_EGG_VERSION}-py${MODPY_VERSION}.egg-info/
lib/python${MODPY_VERSION}/site-packages/websocket_client-${MODPY_EGG_VERSION}-py${MODPY_VERSION}.egg-info/PKG-INFO
On Fri, Nov 29, 2019 at 04:26:38PM +0100, clematis wrote:
> On Thu, Nov 28, 2019 at 12:20:33PM -0500, Kurt Mosiejczuk wrote:
> > On Thu, Nov 28, 2019 at 12:55:17PM +0100, clematis wrote:
> > You just changed the PKGNAME with that change. You need the old PKGNAME
> > line back in there.
>
> Oops you're right - I've missed that, wanted to simplify PKGNAME but
> missed the underscore change.
>
> > According to the setup.py, the package requires py-six. Why are you
> > dropping it?
>
> I need to go back to what I've done back in September.
>
> I am traveling with limited access to this. I will reply to this thread
> once I get this clarified.
>
> Thanks for checking and for your feedback.
> Cheers,
Ok, here's a new diff not altering the pkgname. py-six is back as per
setup.py and doc. (I don't have time right now but will be worth
checking why this didn't show up as a problem earlier).
Since I was at it I've also tested a dep:
multimedia/streamlink:
test: Ran 867 tests OK
run: OK
Cheers,
--
clematis (0x7e96fd2400fe7b59)
Re: Update net/py-websocket-client to 0.56.0
On Thu, Nov 28, 2019 at 12:20:33PM -0500, Kurt Mosiejczuk wrote:
> On Thu, Nov 28, 2019 at 12:55:17PM +0100, clematis wrote:
> You just changed the PKGNAME with that change. You need the old PKGNAME
> line back in there.
Oops you're right - I've missed that, wanted to simplify PKGNAME but
missed the underscore change.
> According to the setup.py, the package requires py-six. Why are you
> dropping it?
I need to go back to what I've done back in September.
I am traveling with limited access to this. I will reply to this thread
once I get this clarified.
Thanks for checking and for your feedback.
Cheers,
--
clematis (0x7e96fd2400fe7b59)
> On Thu, Nov 28, 2019 at 12:55:17PM +0100, clematis wrote:
> You just changed the PKGNAME with that change. You need the old PKGNAME
> line back in there.
Oops you're right - I've missed that, wanted to simplify PKGNAME but
missed the underscore change.
> According to the setup.py, the package requires py-six. Why are you
> dropping it?
I need to go back to what I've done back in September.
I am traveling with limited access to this. I will reply to this thread
once I get this clarified.
Thanks for checking and for your feedback.
Cheers,
--
clematis (0x7e96fd2400fe7b59)
Re: Update graphics/geeqie to 1.5.1
On Fri, Nov 29, 2019 at 02:19:06PM +0300, Kirill Bychkov wrote:
> Hi!
> Tweaked diff attached with pdf disabled. djvu and lua are already disabled.
> Can't find any knobs about webp and openjp2.
> Works fine for me on amd64.
Hi Kirill,
Thanks for that - I didn't have a chance to look at this earlier.
Just tested your patch and everything worked as expected.
Thank you.
--
clematis (0x7e96fd2400fe7b59)
> Hi!
> Tweaked diff attached with pdf disabled. djvu and lua are already disabled.
> Can't find any knobs about webp and openjp2.
> Works fine for me on amd64.
Hi Kirill,
Thanks for that - I didn't have a chance to look at this earlier.
Just tested your patch and everything worked as expected.
Thank you.
--
clematis (0x7e96fd2400fe7b59)
Re: Installing OpenBSD -current snapshots
On 2019-11-29 02:26, Clay Daniels wrote:
> Nick, thanks for straightening me out about what is actually going on here
> with the install. I see that there is now a fresh snapshot with today's
> date, not the one I downloaded and ran yesterday. This might tend to keep
> one busy. I'm not sure I would not be better off doing what Bruno & Marc
> suggested and run sysupgrade. Thanks to them for the advice.
sysupgrade does upgrades of existing systems. Very slick. However, it
isn't for fresh installs, and if you have convenient console access, it's
not the preferred way of doing it. And based on the questions here,
NO WAY. You need to understand what's going on before you start doing
unattended upgrades.
It also (by default) assumes network upgrades, and if you are wanting
everything on local media, there are existing better solutions.
And yes, following current is a never-ending quest. However, problems
are relatively rare and usually not a big deal, and generally fixed on
the next snapshot.
> If I do decide to put the filesets on the the install thumbdrive, I see a
> total of 26 files in the directory. Obviously some are not necessary like
> the floppy or both the .fs & .iso (just one needed), nor the test
> instructions, etc.
> So which files do I REALLY need on my usb thumbdrive to get a complete
> install, x included?
STOP STOP STOP STOP.
You need to re-read what I wrote and the install part of the FAQ some
more times.
The install66.fs file is an image with the *entire install set included*.
You do not want to add things. You COULD do some voodoo to add stuff to
the miniroot66.fs, but PLEASE DON'T...you would just be re-inventing the
install66.fs, poorly and with more difficulty.
>
> Please excuse the "top-posting". That's the only way my darn google mail
> does reply's. Kind of irritating, to me and the reader too.
Bottom posting was invented for those who can't write in complete thoughts
with context. You know, like most of the computer world. :-/
Nick.
> Clay
>
>
>
>
> On Thu, Nov 28, 2019 at 12:34 PM Nick Holland <nick@holland-consulting.net>
> wrote:
>
>> On 2019-11-27 21:29, Edgar Pettijohn wrote:
>> > On Wed, Nov 27, 2019 at 08:05:30PM -0600, Clay Daniels wrote:
>> >> I have successfully installed OpenBSD 6.6 release and would like to give
>> >> the Current Snapshots a try. I went to a mirror, and to:
>> >>
>> >> Index of /pub/OpenBSD/snapshots/amd64/
>> >>
>> >> I saw install66.fs (probably for usb memstick) and install66.iso (surely
>> >> for a cd/dvd) at ~450Mb. I picked the install66.fs, wrote it to a usb
>> >> thumbdrive, and it starts the install. When i get into the install it
>> asks
>> >> where are the file sets? Humm, maybe it gets these online and it tries
>> to
>> >> do this but no luck. It was late last night, and I checked to see if it
>> had
>> >> written anything to my disk, which it had not, and went to bed. This
>> >> evening I'm looking a bit deeper at the snapshot directory and I
>> suspect I
>> >> need to provide the install with base66.tzg at ~239Mb.
>>
>> NO!
>>
>> [snip misleading stuff]
>> > I noticed this also, but hadn't had time to figure out if I had messed
>> up or
>> > the installer had. As a general rule I assume its me that messed up. Its
>> odd
>> > if you mount the install66.fs you can see the pub/amd64 directory, but
>> during
>> > installation it can't seem to find the directory regardless of what I
>> have
>> > tried.
>> >
>> > Edgar
>>
>> First of all...nothing at all to do about snapshots -- the OpenBSD
>> installation process has remained amazingly stable over the last 20
>> years.
>> New options here and there, but overall, very similar. Unless something
>> changed in the last few days, installing a snapshot is identical to
>> installing 6.6.
>>
>> The installXX.iso and installXX.fs are complete, stand-alone installation
>> kits. Everything you need is on them. You can boot from them, and all
>> the installation files are right there. Look Ma! No network needed!
>> ...well...unfortunately there is the issue of firmware files, which are
>> legally not feasible to put on the install media, so you will need network
>> for most machines eventually. But let's ignore that for now. :)
>>
>> Once the system has booted on the install kernel, you have three devices
>> you are working with:
>> 1) the install kernel's internal "RAM disk" that is part of bsd.rd which
>> you booted from,
>> 2) your target disk
>> 3) the USB drive with the install files on it.
>>
>> The reason you can't see the install files on the USB stick from the
>> install kernel is they aren't mounted. You didn't boot from the entire
>> USB stick, you booted from ONE TINY LITTLE bsd.rd file, that just happened
>> to be sitting on the big USB stick...but as far as bsd.rd is concerned,
>> the USB stick isn't part of the booted environment (yet).
>>
>> You aren't booting from a "Live Media". You are booting from a tiny kernel
>> with a built in file system that's sitting on the same inert file system as
>> the install files.
>>
>> Read that over and over until you understand what I'm saying, not what you
>> are assuming is going on. It's really important to understand. It's very
>> different from many Linux installation processes -- you are running off a
>> file only 10MB in size which is now completely in RAM. That file JUST
>> HAPPENED to come from a USB stick that's much bigger.
>>
>> So, when it comes to answering where your install files are, they are on
>> a disk, but it's NOT a mounted disk. It's on your USB drive that's not
>> mounted now, and won't be after installation, but could be useful shortly.
>>
>> Your next problem is...WHICH disk? On a minimal system, it would be the
>> next sd device after your install disk -- assuming you are installing to
>> sd0, your USB stick might be sd1. HOWEVER, if you have a flash media
>> reader
>> on your system, who knows where it is. One trick would be to unplug your
>> USB drive and plug it back in and look at the white-on-blue console message
>> that come up at you. Yes, you are unpluging your boot device, sounds bad,
>> but read what I wrote earlier, it's no longer using that -- the boot has
>> completed, and it's running from RAM now, it's completely ignoring that
>> USB drive. So let's say you do this and you see it's sd4. Tell the
>> installer the files are coming from a file system not currently mounted
>> and when it asks, tell it "sd4"
>>
>> Nick.
>>
>>
>
> Nick, thanks for straightening me out about what is actually going on here
> with the install. I see that there is now a fresh snapshot with today's
> date, not the one I downloaded and ran yesterday. This might tend to keep
> one busy. I'm not sure I would not be better off doing what Bruno & Marc
> suggested and run sysupgrade. Thanks to them for the advice.
sysupgrade does upgrades of existing systems. Very slick. However, it
isn't for fresh installs, and if you have convenient console access, it's
not the preferred way of doing it. And based on the questions here,
NO WAY. You need to understand what's going on before you start doing
unattended upgrades.
It also (by default) assumes network upgrades, and if you are wanting
everything on local media, there are existing better solutions.
And yes, following current is a never-ending quest. However, problems
are relatively rare and usually not a big deal, and generally fixed on
the next snapshot.
> If I do decide to put the filesets on the the install thumbdrive, I see a
> total of 26 files in the directory. Obviously some are not necessary like
> the floppy or both the .fs & .iso (just one needed), nor the test
> instructions, etc.
> So which files do I REALLY need on my usb thumbdrive to get a complete
> install, x included?
STOP STOP STOP STOP.
You need to re-read what I wrote and the install part of the FAQ some
more times.
The install66.fs file is an image with the *entire install set included*.
You do not want to add things. You COULD do some voodoo to add stuff to
the miniroot66.fs, but PLEASE DON'T...you would just be re-inventing the
install66.fs, poorly and with more difficulty.
>
> Please excuse the "top-posting". That's the only way my darn google mail
> does reply's. Kind of irritating, to me and the reader too.
Bottom posting was invented for those who can't write in complete thoughts
with context. You know, like most of the computer world. :-/
Nick.
> Clay
>
>
>
>
> On Thu, Nov 28, 2019 at 12:34 PM Nick Holland <nick@holland-consulting.net>
> wrote:
>
>> On 2019-11-27 21:29, Edgar Pettijohn wrote:
>> > On Wed, Nov 27, 2019 at 08:05:30PM -0600, Clay Daniels wrote:
>> >> I have successfully installed OpenBSD 6.6 release and would like to give
>> >> the Current Snapshots a try. I went to a mirror, and to:
>> >>
>> >> Index of /pub/OpenBSD/snapshots/amd64/
>> >>
>> >> I saw install66.fs (probably for usb memstick) and install66.iso (surely
>> >> for a cd/dvd) at ~450Mb. I picked the install66.fs, wrote it to a usb
>> >> thumbdrive, and it starts the install. When i get into the install it
>> asks
>> >> where are the file sets? Humm, maybe it gets these online and it tries
>> to
>> >> do this but no luck. It was late last night, and I checked to see if it
>> had
>> >> written anything to my disk, which it had not, and went to bed. This
>> >> evening I'm looking a bit deeper at the snapshot directory and I
>> suspect I
>> >> need to provide the install with base66.tzg at ~239Mb.
>>
>> NO!
>>
>> [snip misleading stuff]
>> > I noticed this also, but hadn't had time to figure out if I had messed
>> up or
>> > the installer had. As a general rule I assume its me that messed up. Its
>> odd
>> > if you mount the install66.fs you can see the pub/amd64 directory, but
>> during
>> > installation it can't seem to find the directory regardless of what I
>> have
>> > tried.
>> >
>> > Edgar
>>
>> First of all...nothing at all to do about snapshots -- the OpenBSD
>> installation process has remained amazingly stable over the last 20
>> years.
>> New options here and there, but overall, very similar. Unless something
>> changed in the last few days, installing a snapshot is identical to
>> installing 6.6.
>>
>> The installXX.iso and installXX.fs are complete, stand-alone installation
>> kits. Everything you need is on them. You can boot from them, and all
>> the installation files are right there. Look Ma! No network needed!
>> ...well...unfortunately there is the issue of firmware files, which are
>> legally not feasible to put on the install media, so you will need network
>> for most machines eventually. But let's ignore that for now. :)
>>
>> Once the system has booted on the install kernel, you have three devices
>> you are working with:
>> 1) the install kernel's internal "RAM disk" that is part of bsd.rd which
>> you booted from,
>> 2) your target disk
>> 3) the USB drive with the install files on it.
>>
>> The reason you can't see the install files on the USB stick from the
>> install kernel is they aren't mounted. You didn't boot from the entire
>> USB stick, you booted from ONE TINY LITTLE bsd.rd file, that just happened
>> to be sitting on the big USB stick...but as far as bsd.rd is concerned,
>> the USB stick isn't part of the booted environment (yet).
>>
>> You aren't booting from a "Live Media". You are booting from a tiny kernel
>> with a built in file system that's sitting on the same inert file system as
>> the install files.
>>
>> Read that over and over until you understand what I'm saying, not what you
>> are assuming is going on. It's really important to understand. It's very
>> different from many Linux installation processes -- you are running off a
>> file only 10MB in size which is now completely in RAM. That file JUST
>> HAPPENED to come from a USB stick that's much bigger.
>>
>> So, when it comes to answering where your install files are, they are on
>> a disk, but it's NOT a mounted disk. It's on your USB drive that's not
>> mounted now, and won't be after installation, but could be useful shortly.
>>
>> Your next problem is...WHICH disk? On a minimal system, it would be the
>> next sd device after your install disk -- assuming you are installing to
>> sd0, your USB stick might be sd1. HOWEVER, if you have a flash media
>> reader
>> on your system, who knows where it is. One trick would be to unplug your
>> USB drive and plug it back in and look at the white-on-blue console message
>> that come up at you. Yes, you are unpluging your boot device, sounds bad,
>> but read what I wrote earlier, it's no longer using that -- the boot has
>> completed, and it's running from RAM now, it's completely ignoring that
>> USB drive. So let's say you do this and you see it's sd4. Tell the
>> installer the files are coming from a file system not currently mounted
>> and when it asks, tell it "sd4"
>>
>> Nick.
>>
>>
>
Re: Installing OpenBSD -current snapshots
> BTW, why do you want to run -current?
> There are only 2 real reasons to do that
> [ ... ]
Total nonsense ...
> There are only 2 real reasons to do that
> [ ... ]
Total nonsense ...
Re: [update] sysutils/fzf to 0.19.0
On Thu, 28 Nov 2019, Aaron Bieber wrote:
> Hi,
>
> Here is an update of fzf.
>
> Port changes:
> - Include shell completion / key-bindings.
> - Update pledge to the "newer" PLedgePromises call.
>
> FZF changes:
> - https://github.com/junegunn/fzf/blob/master/CHANGELOG.md#0190
>
> OK?
builds and works fine for me on amd64. I've tried a couple of the new
functionalities just for fun (I do not need them) and they work ok.
It's really nice to have the completion and key bindings on /usr/local
now.
Cheers,
--
Paco Esteban.
5818130B8A6DBC03
> Hi,
>
> Here is an update of fzf.
>
> Port changes:
> - Include shell completion / key-bindings.
> - Update pledge to the "newer" PLedgePromises call.
>
> FZF changes:
> - https://github.com/junegunn/fzf/blob/master/CHANGELOG.md#0190
>
> OK?
builds and works fine for me on amd64. I've tried a couple of the new
functionalities just for fun (I do not need them) and they work ok.
It's really nice to have the completion and key bindings on /usr/local
now.
Cheers,
--
Paco Esteban.
5818130B8A6DBC03
Re: Update graphics/geeqie to 1.5.1
On Fri, Nov 29, 2019 at 02:19:06PM +0300, Kirill Bychkov wrote:
> On Thu, November 28, 2019 18:56, Landry Breuil wrote:
> > On Thu, Nov 28, 2019 at 04:10:11PM +0100, clematis wrote:
> >> On Thu, Nov 28, 2019 at 03:38:23PM +0100, Landry Breuil wrote:
> >> > Feels wrong here, if you want to remove patches you should cvs rm them
> >> > so that they show up as removed in your cvs diff. Right now, the patches
> >> > arent removed, so make patch fails.
> >> >
> >> > I see that patch-src_window_c & patch-src_layout_util_c apply fine and
> >> > patch-Makefile_am fails on a chunk. Were you planning to remove those
> >> > patches ? Why ? Are they not useful anymore (unsure for the src/window.c
> >> > one..) ?
> >>
> >> Argh, sorry I might have generate the previous diff from a working dir
> >> or don't know how I skipped diffing patches/
> >>
> >> Here's a new one attached which I double checked so that should be the
> >> last one ! Sorry about that.
> >
> > I have it building here, but it seems configure checks for poppler-glib
> > and links with it if found, thus port-lib-depends-check complains about
> > it:
> >
> > geeqie-1.5.1v0(graphics/geeqie):
> > Missing lib: poppler-glib.19 (/usr/local/bin/geeqie) (NOT REACHABLE)
> >
> > looking at upstream repository on
> > http://geeqie.org/cgi-bin/gitweb.cgi?p=geeqie.git;a=history;f=configure.ac
> > it looks like they added support for webp, pdf, lua, djvu, openjp2, etc - you
> > might want to add those are dependencies, or explicitely disable them.
> >
> > Landry
> >
> >
>
> Hi!
> Tweaked diff attached with pdf disabled. djvu and lua are already disabled.
> Can't find any knobs about webp and openjp2.
Right, those were added post-1.5.1, so something to keep in mind for
future releases.
> Works fine for me on amd64.
ok with me; thanks !
> On Thu, November 28, 2019 18:56, Landry Breuil wrote:
> > On Thu, Nov 28, 2019 at 04:10:11PM +0100, clematis wrote:
> >> On Thu, Nov 28, 2019 at 03:38:23PM +0100, Landry Breuil wrote:
> >> > Feels wrong here, if you want to remove patches you should cvs rm them
> >> > so that they show up as removed in your cvs diff. Right now, the patches
> >> > arent removed, so make patch fails.
> >> >
> >> > I see that patch-src_window_c & patch-src_layout_util_c apply fine and
> >> > patch-Makefile_am fails on a chunk. Were you planning to remove those
> >> > patches ? Why ? Are they not useful anymore (unsure for the src/window.c
> >> > one..) ?
> >>
> >> Argh, sorry I might have generate the previous diff from a working dir
> >> or don't know how I skipped diffing patches/
> >>
> >> Here's a new one attached which I double checked so that should be the
> >> last one ! Sorry about that.
> >
> > I have it building here, but it seems configure checks for poppler-glib
> > and links with it if found, thus port-lib-depends-check complains about
> > it:
> >
> > geeqie-1.5.1v0(graphics/geeqie):
> > Missing lib: poppler-glib.19 (/usr/local/bin/geeqie) (NOT REACHABLE)
> >
> > looking at upstream repository on
> > http://geeqie.org/cgi-bin/gitweb.cgi?p=geeqie.git;a=history;f=configure.ac
> > it looks like they added support for webp, pdf, lua, djvu, openjp2, etc - you
> > might want to add those are dependencies, or explicitely disable them.
> >
> > Landry
> >
> >
>
> Hi!
> Tweaked diff attached with pdf disabled. djvu and lua are already disabled.
> Can't find any knobs about webp and openjp2.
Right, those were added post-1.5.1, so something to keep in mind for
future releases.
> Works fine for me on amd64.
ok with me; thanks !
Re: WIP UPDATE: graphics/gimp
On 11/27/19 1:26 PM, Stuart Henderson wrote:
> On 2018/09/10 12:06, Giovanni Bechis wrote:
>> Hi,
>> update to latest version, it's working fine but I have not tested any of the additional plugins yet.
>> Few time to hack atm, so do not hold your breath.
>
> Here's an updated version of this. I saw a segfault once but it hasn't
> occurred again and I haven't been able to track it down further.
>
> (I know there's a newer one, but that requires dep updates which it would
> be simpler not to deal with at the same time, and this is enough to stop
> confusing me when I move between OpenBSD and other machines :-)
>
I was working on 2.10.14 but I stopped when I found some dep that needs to be updated,
it is better to go on this road.
> deskew and lqr plugins still seem to work.
>
ok giovanni@
> On 2018/09/10 12:06, Giovanni Bechis wrote:
>> Hi,
>> update to latest version, it's working fine but I have not tested any of the additional plugins yet.
>> Few time to hack atm, so do not hold your breath.
>
> Here's an updated version of this. I saw a segfault once but it hasn't
> occurred again and I haven't been able to track it down further.
>
> (I know there's a newer one, but that requires dep updates which it would
> be simpler not to deal with at the same time, and this is enough to stop
> confusing me when I move between OpenBSD and other machines :-)
>
I was working on 2.10.14 but I stopped when I found some dep that needs to be updated,
it is better to go on this road.
> deskew and lqr plugins still seem to work.
>
ok giovanni@
Re: Installing OpenBSD -current snapshots
On Fri, Nov 29, 2019, at 2:26 AM, Clay Daniels wrote:
> Nick, thanks for straightening me out about what is actually going on here
> with the install. I see that there is now a fresh snapshot with today's
> date, not the one I downloaded and ran yesterday. This might tend to keep
> one busy. I'm not sure I would not be better off doing what Bruno & Marc
> suggested and run sysupgrade. Thanks to them for the advice.
BTW, why do you want to run -current?
There are only 2 real reasons to do that
1: You HAVE to (for various reasons)
2: You want to help with development and test things. This is a great reason, but
you better be prepared for a lot of work. Know what you are doing and file bug reports.
Else you won't be a whole lot of actual help.
If these don't apply then you might be better off just running Release.
Not trying to be an A hole here. Just giving you heads up of what is expected of
you if you run -current.
Good luck
> Nick, thanks for straightening me out about what is actually going on here
> with the install. I see that there is now a fresh snapshot with today's
> date, not the one I downloaded and ran yesterday. This might tend to keep
> one busy. I'm not sure I would not be better off doing what Bruno & Marc
> suggested and run sysupgrade. Thanks to them for the advice.
BTW, why do you want to run -current?
There are only 2 real reasons to do that
1: You HAVE to (for various reasons)
2: You want to help with development and test things. This is a great reason, but
you better be prepared for a lot of work. Know what you are doing and file bug reports.
Else you won't be a whole lot of actual help.
If these don't apply then you might be better off just running Release.
Not trying to be an A hole here. Just giving you heads up of what is expected of
you if you run -current.
Good luck
Re: Update graphics/geeqie to 1.5.1
Index: Makefile
===================================================================
RCS file: /cvs/ports/graphics/geeqie/Makefile,v
retrieving revision 1.22
diff -u -p -u -p -r1.22 Makefile
--- Makefile 12 Jul 2019 20:46:59 -0000 1.22
+++ Makefile 29 Nov 2019 11:12:16 -0000
@@ -2,11 +2,10 @@
COMMENT= lightweight Gtk+3 based image viewer
-DISTNAME= geeqie-1.4
+DISTNAME= geeqie-1.5.1
EXTRACT_SUFX= .tar.xz
CATEGORIES= graphics
EPOCH= 0
-REVISION= 1
HOMEPAGE= http://geeqie.org/
@@ -45,6 +44,7 @@ CONFIGURE_ARGS= --disable-doxygen-doc \
--disable-lua \
--disable-ffmpegthumbnailer \
--disable-gpu-accel \
+ --disable-pdf \
--enable-gtk3 \
--with-htmldir=${PREFIX}/share/doc/geeqie \
--with-readmedir=${PREFIX}/share/doc/geeqie
Index: distinfo
===================================================================
RCS file: /cvs/ports/graphics/geeqie/distinfo,v
retrieving revision 1.6
diff -u -p -u -p -r1.6 distinfo
--- distinfo 22 Jan 2018 07:45:37 -0000 1.6
+++ distinfo 29 Nov 2019 11:12:16 -0000
@@ -1,2 +1,2 @@
-SHA256 (geeqie-1.4.tar.xz) = XFg6FlVz7DeHTCePncV+c981azDgmpzKwxed1dl+PjI=
-SIZE (geeqie-1.4.tar.xz) = 35881152
+SHA256 (geeqie-1.5.1.tar.xz) = SFTV0yPDH49AaP1zqyxFT/kegmxMpNN7IsJGrRTeoQo=
+SIZE (geeqie-1.5.1.tar.xz) = 1587116
Index: patches/patch-Makefile_am
===================================================================
RCS file: /cvs/ports/graphics/geeqie/patches/patch-Makefile_am,v
retrieving revision 1.1
diff -u -p -u -p -r1.1 patch-Makefile_am
--- patches/patch-Makefile_am 22 Jan 2018 07:45:37 -0000 1.1
+++ patches/patch-Makefile_am 29 Nov 2019 11:12:16 -0000
@@ -16,9 +16,9 @@ Index: Makefile.am
desktopdir = $(datadir)/applications
@@ -36,10 +36,6 @@ dist-hook: geeqie.spec
- cp $(top_builddir)/geeqie.spec $(distdir)
DISTCLEANFILES = config.report
+ CLEANFILES = $(desktop_DATA) ChangeLog.html
-
-.PHONY: ChangeLog
-ChangeLog.html:
Index: patches/patch-src_window_c
===================================================================
RCS file: /cvs/ports/graphics/geeqie/patches/patch-src_window_c,v
retrieving revision 1.2
diff -u -p -u -p -r1.2 patch-src_window_c
--- patches/patch-src_window_c 28 May 2016 13:59:51 -0000 1.2
+++ patches/patch-src_window_c 29 Nov 2019 11:12:16 -0000
@@ -1,7 +1,8 @@
$OpenBSD: patch-src_window_c,v 1.2 2016/05/28 13:59:51 sthen Exp $
---- src/window.c.orig Fri May 27 10:37:56 2016
-+++ src/window.c Sat May 28 14:55:27 2016
-@@ -171,19 +171,11 @@ static gchar *html_browsers[] =
+Index: src/window.c
+--- src/window.c.orig
++++ src/window.c
+@@ -173,19 +173,11 @@ static gchar *html_browsers[] =
{
/* Our specific script */
GQ_APPNAME_LC "_html_browser", NULL,
Index: pkg/PLIST
===================================================================
RCS file: /cvs/ports/graphics/geeqie/pkg/PLIST,v
retrieving revision 1.8
diff -u -p -u -p -r1.8 PLIST
--- pkg/PLIST 27 Jun 2018 21:03:53 -0000 1.8
+++ pkg/PLIST 29 Nov 2019 11:12:16 -0000
@@ -3,9 +3,15 @@
@pkgpath graphics/gqview
@bin bin/geeqie
lib/geeqie/
-lib/geeqie/geeqie-import
+lib/geeqie/geeqie-camera-import
+lib/geeqie/geeqie-camera-import-hook-script
+lib/geeqie/geeqie-export-jpeg
+lib/geeqie/geeqie-image-crop
+lib/geeqie/geeqie-random-image
lib/geeqie/geeqie-rotate
lib/geeqie/geeqie-symlink
+lib/geeqie/geeqie-tethered-photography
+lib/geeqie/geeqie-tethered-photography-hook-script
@comment lib/geeqie/geeqie-ufraw
lib/geeqie/geocode-parameters.awk
@man man/man1/geeqie.1
@@ -33,6 +39,7 @@ share/doc/geeqie/GuideImagePresentation.
share/doc/geeqie/GuideImagePresentationFullscreen.html
share/doc/geeqie/GuideImagePresentationSlideshow.html
share/doc/geeqie/GuideImageSearch.html
+share/doc/geeqie/GuideImageSearchCache.html
share/doc/geeqie/GuideImageSearchFindingDuplicates.html
share/doc/geeqie/GuideImageSearchSearch.html
share/doc/geeqie/GuideIndex-info.html
@@ -55,9 +62,11 @@ share/doc/geeqie/GuideOptionsGeneral.htm
share/doc/geeqie/GuideOptionsHidden.html
share/doc/geeqie/GuideOptionsImage.html
share/doc/geeqie/GuideOptionsKeyboard.html
+share/doc/geeqie/GuideOptionsKeywords.html
share/doc/geeqie/GuideOptionsLayout.html
share/doc/geeqie/GuideOptionsMain.html
share/doc/geeqie/GuideOptionsMetadata.html
+share/doc/geeqie/GuideOptionsOSD.html
share/doc/geeqie/GuideOptionsStereo.html
share/doc/geeqie/GuideOptionsToolbar.html
share/doc/geeqie/GuideOptionsWindow.html
@@ -76,10 +85,13 @@ share/doc/geeqie/GuideReferenceLIRC.html
share/doc/geeqie/GuideReferenceLua.html
share/doc/geeqie/GuideReferenceManagement.html
share/doc/geeqie/GuideReferenceMetadata.html
+share/doc/geeqie/GuideReferencePCRE.html
share/doc/geeqie/GuideReferencePixbufLoaders.html
+share/doc/geeqie/GuideReferenceStandardPlugins.html
share/doc/geeqie/GuideReferenceStandards.html
share/doc/geeqie/GuideReferenceSupportedFormats.html
share/doc/geeqie/GuideReferenceThumbnails.html
+share/doc/geeqie/GuideReferenceUTC.html
share/doc/geeqie/GuideReferenceXmpExif.html
share/doc/geeqie/GuideSidebars.html
share/doc/geeqie/GuideSidebarsInfo.html
@@ -129,13 +141,16 @@ share/doc/geeqie/zoom-original.png
share/doc/geeqie/zoom-out.png
share/geeqie/
share/geeqie/applications/
-share/geeqie/applications/geeqie-import-geeqie.desktop
-share/geeqie/applications/geeqie-import-gqview.desktop
+share/geeqie/applications/camera-import.desktop
+share/geeqie/applications/export-jpeg.desktop
share/geeqie/applications/geeqie-ufraw-id.desktop
@comment share/geeqie/applications/geeqie-ufraw-recursive.desktop
@comment share/geeqie/applications/geeqie-ufraw.desktop
+share/geeqie/applications/image-crop.desktop
+share/geeqie/applications/random-image.desktop
share/geeqie/applications/rotate.desktop
share/geeqie/applications/symlink.desktop
+share/geeqie/applications/tethered-photography.desktop
share/geeqie/template.desktop
share/locale/ar/LC_MESSAGES/geeqie.mo
share/locale/be/LC_MESSAGES/geeqie.mo
@@ -145,6 +160,7 @@ share/locale/cs/LC_MESSAGES/geeqie.mo
share/locale/da/LC_MESSAGES/geeqie.mo
share/locale/de/LC_MESSAGES/geeqie.mo
share/locale/el/LC_MESSAGES/geeqie.mo
+share/locale/en_GB/LC_MESSAGES/geeqie.mo
share/locale/eo/LC_MESSAGES/geeqie.mo
share/locale/es/LC_MESSAGES/geeqie.mo
share/locale/et/LC_MESSAGES/geeqie.moOn Thu, November 28, 2019 18:56, Landry Breuil wrote:
> On Thu, Nov 28, 2019 at 04:10:11PM +0100, clematis wrote:
>> On Thu, Nov 28, 2019 at 03:38:23PM +0100, Landry Breuil wrote:
>> > Feels wrong here, if you want to remove patches you should cvs rm them
>> > so that they show up as removed in your cvs diff. Right now, the patches
>> > arent removed, so make patch fails.
>> >
>> > I see that patch-src_window_c & patch-src_layout_util_c apply fine and
>> > patch-Makefile_am fails on a chunk. Were you planning to remove those
>> > patches ? Why ? Are they not useful anymore (unsure for the src/window.c
>> > one..) ?
>>
>> Argh, sorry I might have generate the previous diff from a working dir
>> or don't know how I skipped diffing patches/
>>
>> Here's a new one attached which I double checked so that should be the
>> last one ! Sorry about that.
>
> I have it building here, but it seems configure checks for poppler-glib
> and links with it if found, thus port-lib-depends-check complains about
> it:
>
> geeqie-1.5.1v0(graphics/geeqie):
> Missing lib: poppler-glib.19 (/usr/local/bin/geeqie) (NOT REACHABLE)
>
> looking at upstream repository on
> http://geeqie.org/cgi-bin/gitweb.cgi?p=geeqie.git;a=history;f=configure.ac
> it looks like they added support for webp, pdf, lua, djvu, openjp2, etc - you
> might want to add those are dependencies, or explicitely disable them.
>
> Landry
>
>
Hi!
Tweaked diff attached with pdf disabled. djvu and lua are already disabled.
Can't find any knobs about webp and openjp2.
Works fine for me on amd64.
===================================================================
RCS file: /cvs/ports/graphics/geeqie/Makefile,v
retrieving revision 1.22
diff -u -p -u -p -r1.22 Makefile
--- Makefile 12 Jul 2019 20:46:59 -0000 1.22
+++ Makefile 29 Nov 2019 11:12:16 -0000
@@ -2,11 +2,10 @@
COMMENT= lightweight Gtk+3 based image viewer
-DISTNAME= geeqie-1.4
+DISTNAME= geeqie-1.5.1
EXTRACT_SUFX= .tar.xz
CATEGORIES= graphics
EPOCH= 0
-REVISION= 1
HOMEPAGE= http://geeqie.org/
@@ -45,6 +44,7 @@ CONFIGURE_ARGS= --disable-doxygen-doc \
--disable-lua \
--disable-ffmpegthumbnailer \
--disable-gpu-accel \
+ --disable-pdf \
--enable-gtk3 \
--with-htmldir=${PREFIX}/share/doc/geeqie \
--with-readmedir=${PREFIX}/share/doc/geeqie
Index: distinfo
===================================================================
RCS file: /cvs/ports/graphics/geeqie/distinfo,v
retrieving revision 1.6
diff -u -p -u -p -r1.6 distinfo
--- distinfo 22 Jan 2018 07:45:37 -0000 1.6
+++ distinfo 29 Nov 2019 11:12:16 -0000
@@ -1,2 +1,2 @@
-SHA256 (geeqie-1.4.tar.xz) = XFg6FlVz7DeHTCePncV+c981azDgmpzKwxed1dl+PjI=
-SIZE (geeqie-1.4.tar.xz) = 35881152
+SHA256 (geeqie-1.5.1.tar.xz) = SFTV0yPDH49AaP1zqyxFT/kegmxMpNN7IsJGrRTeoQo=
+SIZE (geeqie-1.5.1.tar.xz) = 1587116
Index: patches/patch-Makefile_am
===================================================================
RCS file: /cvs/ports/graphics/geeqie/patches/patch-Makefile_am,v
retrieving revision 1.1
diff -u -p -u -p -r1.1 patch-Makefile_am
--- patches/patch-Makefile_am 22 Jan 2018 07:45:37 -0000 1.1
+++ patches/patch-Makefile_am 29 Nov 2019 11:12:16 -0000
@@ -16,9 +16,9 @@ Index: Makefile.am
desktopdir = $(datadir)/applications
@@ -36,10 +36,6 @@ dist-hook: geeqie.spec
- cp $(top_builddir)/geeqie.spec $(distdir)
DISTCLEANFILES = config.report
+ CLEANFILES = $(desktop_DATA) ChangeLog.html
-
-.PHONY: ChangeLog
-ChangeLog.html:
Index: patches/patch-src_window_c
===================================================================
RCS file: /cvs/ports/graphics/geeqie/patches/patch-src_window_c,v
retrieving revision 1.2
diff -u -p -u -p -r1.2 patch-src_window_c
--- patches/patch-src_window_c 28 May 2016 13:59:51 -0000 1.2
+++ patches/patch-src_window_c 29 Nov 2019 11:12:16 -0000
@@ -1,7 +1,8 @@
$OpenBSD: patch-src_window_c,v 1.2 2016/05/28 13:59:51 sthen Exp $
---- src/window.c.orig Fri May 27 10:37:56 2016
-+++ src/window.c Sat May 28 14:55:27 2016
-@@ -171,19 +171,11 @@ static gchar *html_browsers[] =
+Index: src/window.c
+--- src/window.c.orig
++++ src/window.c
+@@ -173,19 +173,11 @@ static gchar *html_browsers[] =
{
/* Our specific script */
GQ_APPNAME_LC "_html_browser", NULL,
Index: pkg/PLIST
===================================================================
RCS file: /cvs/ports/graphics/geeqie/pkg/PLIST,v
retrieving revision 1.8
diff -u -p -u -p -r1.8 PLIST
--- pkg/PLIST 27 Jun 2018 21:03:53 -0000 1.8
+++ pkg/PLIST 29 Nov 2019 11:12:16 -0000
@@ -3,9 +3,15 @@
@pkgpath graphics/gqview
@bin bin/geeqie
lib/geeqie/
-lib/geeqie/geeqie-import
+lib/geeqie/geeqie-camera-import
+lib/geeqie/geeqie-camera-import-hook-script
+lib/geeqie/geeqie-export-jpeg
+lib/geeqie/geeqie-image-crop
+lib/geeqie/geeqie-random-image
lib/geeqie/geeqie-rotate
lib/geeqie/geeqie-symlink
+lib/geeqie/geeqie-tethered-photography
+lib/geeqie/geeqie-tethered-photography-hook-script
@comment lib/geeqie/geeqie-ufraw
lib/geeqie/geocode-parameters.awk
@man man/man1/geeqie.1
@@ -33,6 +39,7 @@ share/doc/geeqie/GuideImagePresentation.
share/doc/geeqie/GuideImagePresentationFullscreen.html
share/doc/geeqie/GuideImagePresentationSlideshow.html
share/doc/geeqie/GuideImageSearch.html
+share/doc/geeqie/GuideImageSearchCache.html
share/doc/geeqie/GuideImageSearchFindingDuplicates.html
share/doc/geeqie/GuideImageSearchSearch.html
share/doc/geeqie/GuideIndex-info.html
@@ -55,9 +62,11 @@ share/doc/geeqie/GuideOptionsGeneral.htm
share/doc/geeqie/GuideOptionsHidden.html
share/doc/geeqie/GuideOptionsImage.html
share/doc/geeqie/GuideOptionsKeyboard.html
+share/doc/geeqie/GuideOptionsKeywords.html
share/doc/geeqie/GuideOptionsLayout.html
share/doc/geeqie/GuideOptionsMain.html
share/doc/geeqie/GuideOptionsMetadata.html
+share/doc/geeqie/GuideOptionsOSD.html
share/doc/geeqie/GuideOptionsStereo.html
share/doc/geeqie/GuideOptionsToolbar.html
share/doc/geeqie/GuideOptionsWindow.html
@@ -76,10 +85,13 @@ share/doc/geeqie/GuideReferenceLIRC.html
share/doc/geeqie/GuideReferenceLua.html
share/doc/geeqie/GuideReferenceManagement.html
share/doc/geeqie/GuideReferenceMetadata.html
+share/doc/geeqie/GuideReferencePCRE.html
share/doc/geeqie/GuideReferencePixbufLoaders.html
+share/doc/geeqie/GuideReferenceStandardPlugins.html
share/doc/geeqie/GuideReferenceStandards.html
share/doc/geeqie/GuideReferenceSupportedFormats.html
share/doc/geeqie/GuideReferenceThumbnails.html
+share/doc/geeqie/GuideReferenceUTC.html
share/doc/geeqie/GuideReferenceXmpExif.html
share/doc/geeqie/GuideSidebars.html
share/doc/geeqie/GuideSidebarsInfo.html
@@ -129,13 +141,16 @@ share/doc/geeqie/zoom-original.png
share/doc/geeqie/zoom-out.png
share/geeqie/
share/geeqie/applications/
-share/geeqie/applications/geeqie-import-geeqie.desktop
-share/geeqie/applications/geeqie-import-gqview.desktop
+share/geeqie/applications/camera-import.desktop
+share/geeqie/applications/export-jpeg.desktop
share/geeqie/applications/geeqie-ufraw-id.desktop
@comment share/geeqie/applications/geeqie-ufraw-recursive.desktop
@comment share/geeqie/applications/geeqie-ufraw.desktop
+share/geeqie/applications/image-crop.desktop
+share/geeqie/applications/random-image.desktop
share/geeqie/applications/rotate.desktop
share/geeqie/applications/symlink.desktop
+share/geeqie/applications/tethered-photography.desktop
share/geeqie/template.desktop
share/locale/ar/LC_MESSAGES/geeqie.mo
share/locale/be/LC_MESSAGES/geeqie.mo
@@ -145,6 +160,7 @@ share/locale/cs/LC_MESSAGES/geeqie.mo
share/locale/da/LC_MESSAGES/geeqie.mo
share/locale/de/LC_MESSAGES/geeqie.mo
share/locale/el/LC_MESSAGES/geeqie.mo
+share/locale/en_GB/LC_MESSAGES/geeqie.mo
share/locale/eo/LC_MESSAGES/geeqie.mo
share/locale/es/LC_MESSAGES/geeqie.mo
share/locale/et/LC_MESSAGES/geeqie.moOn Thu, November 28, 2019 18:56, Landry Breuil wrote:
> On Thu, Nov 28, 2019 at 04:10:11PM +0100, clematis wrote:
>> On Thu, Nov 28, 2019 at 03:38:23PM +0100, Landry Breuil wrote:
>> > Feels wrong here, if you want to remove patches you should cvs rm them
>> > so that they show up as removed in your cvs diff. Right now, the patches
>> > arent removed, so make patch fails.
>> >
>> > I see that patch-src_window_c & patch-src_layout_util_c apply fine and
>> > patch-Makefile_am fails on a chunk. Were you planning to remove those
>> > patches ? Why ? Are they not useful anymore (unsure for the src/window.c
>> > one..) ?
>>
>> Argh, sorry I might have generate the previous diff from a working dir
>> or don't know how I skipped diffing patches/
>>
>> Here's a new one attached which I double checked so that should be the
>> last one ! Sorry about that.
>
> I have it building here, but it seems configure checks for poppler-glib
> and links with it if found, thus port-lib-depends-check complains about
> it:
>
> geeqie-1.5.1v0(graphics/geeqie):
> Missing lib: poppler-glib.19 (/usr/local/bin/geeqie) (NOT REACHABLE)
>
> looking at upstream repository on
> http://geeqie.org/cgi-bin/gitweb.cgi?p=geeqie.git;a=history;f=configure.ac
> it looks like they added support for webp, pdf, lua, djvu, openjp2, etc - you
> might want to add those are dependencies, or explicitely disable them.
>
> Landry
>
>
Hi!
Tweaked diff attached with pdf disabled. djvu and lua are already disabled.
Can't find any knobs about webp and openjp2.
Works fine for me on amd64.
Re: Installing OpenBSD -current snapshots
On 29.11.2019 08:45, Clay Daniels wrote:
> Another question. I know I need to write the boot file to the usb drive
> thus:
> # dd if=install66.fs of=/dev/da0 bs=1M conv=sync
> But can I just use plain old "cp base66.tgz /mnt" etc for the other
> files?
>
Sounds like you are rushing too quickly and too much being used to
wrong approach learned on Linux.........
How about to start here first:
https://www.openbsd.org/faq/faq4.html
then:
https://www.openbsd.org/faq/faq1.html#ManPages
https://www.openbsd.org/faq/faq10.html
followed by anything more you will need.
Trust me, you will be surprised how many questions will not need to be
asked at all in future ;-)
> On Fri, Nov 29, 2019 at 1:26 AM Clay Daniels
> <clay.daniels.jr@gmail.com>
> wrote:
>
>> Nick, thanks for straightening me out about what is actually going on
>> here
>> with the install. I see that there is now a fresh snapshot with
>> today's
>> date, not the one I downloaded and ran yesterday. This might tend to
>> keep
>> one busy. I'm not sure I would not be better off doing what Bruno &
>> Marc
>> suggested and run sysupgrade. Thanks to them for the advice.
>>
>> If I do decide to put the filesets on the the install thumbdrive, I
>> see a
>> total of 26 files in the directory. Obviously some are not necessary
>> like
>> the floppy or both the .fs & .iso (just one needed), nor the test
>> instructions, etc.
>> So which files do I REALLY need on my usb thumbdrive to get a complete
>> install, x included?
>>
>> Please excuse the "top-posting". That's the only way my darn google
>> mail
>> does reply's. Kind of irritating, to me and the reader too.
>>
>> Clay
>>
>>
>>
>>
>> On Thu, Nov 28, 2019 at 12:34 PM Nick Holland
>> <nick@holland-consulting.net>
>> wrote:
>>
>>> On 2019-11-27 21:29, Edgar Pettijohn wrote:
>>> > On Wed, Nov 27, 2019 at 08:05:30PM -0600, Clay Daniels wrote:
>>> >> I have successfully installed OpenBSD 6.6 release and would like to
>>> give
>>> >> the Current Snapshots a try. I went to a mirror, and to:
>>> >>
>>> >> Index of /pub/OpenBSD/snapshots/amd64/
>>> >>
>>> >> I saw install66.fs (probably for usb memstick) and install66.iso
>>> (surely
>>> >> for a cd/dvd) at ~450Mb. I picked the install66.fs, wrote it to a usb
>>> >> thumbdrive, and it starts the install. When i get into the install it
>>> asks
>>> >> where are the file sets? Humm, maybe it gets these online and it tries
>>> to
>>> >> do this but no luck. It was late last night, and I checked to see if
>>> it had
>>> >> written anything to my disk, which it had not, and went to bed. This
>>> >> evening I'm looking a bit deeper at the snapshot directory and I
>>> suspect I
>>> >> need to provide the install with base66.tzg at ~239Mb.
>>>
>>> NO!
>>>
>>> [snip misleading stuff]
>>> > I noticed this also, but hadn't had time to figure out if I had messed
>>> up or
>>> > the installer had. As a general rule I assume its me that messed up.
>>> Its odd
>>> > if you mount the install66.fs you can see the pub/amd64 directory, but
>>> during
>>> > installation it can't seem to find the directory regardless of what I
>>> have
>>> > tried.
>>> >
>>> > Edgar
>>>
>>> First of all...nothing at all to do about snapshots -- the OpenBSD
>>> installation process has remained amazingly stable over the last 20
>>> years.
>>> New options here and there, but overall, very similar. Unless
>>> something
>>> changed in the last few days, installing a snapshot is identical to
>>> installing 6.6.
>>>
>>> The installXX.iso and installXX.fs are complete, stand-alone
>>> installation
>>> kits. Everything you need is on them. You can boot from them, and
>>> all
>>> the installation files are right there. Look Ma! No network needed!
>>> ...well...unfortunately there is the issue of firmware files, which
>>> are
>>> legally not feasible to put on the install media, so you will need
>>> network
>>> for most machines eventually. But let's ignore that for now. :)
>>>
>>> Once the system has booted on the install kernel, you have three
>>> devices
>>> you are working with:
>>> 1) the install kernel's internal "RAM disk" that is part of bsd.rd
>>> which
>>> you booted from,
>>> 2) your target disk
>>> 3) the USB drive with the install files on it.
>>>
>>> The reason you can't see the install files on the USB stick from the
>>> install kernel is they aren't mounted. You didn't boot from the
>>> entire
>>> USB stick, you booted from ONE TINY LITTLE bsd.rd file, that just
>>> happened
>>> to be sitting on the big USB stick...but as far as bsd.rd is
>>> concerned,
>>> the USB stick isn't part of the booted environment (yet).
>>>
>>> You aren't booting from a "Live Media". You are booting from a tiny
>>> kernel
>>> with a built in file system that's sitting on the same inert file
>>> system
>>> as
>>> the install files.
>>>
>>> Read that over and over until you understand what I'm saying, not
>>> what you
>>> are assuming is going on. It's really important to understand. It's
>>> very
>>> different from many Linux installation processes -- you are running
>>> off a
>>> file only 10MB in size which is now completely in RAM. That file
>>> JUST
>>> HAPPENED to come from a USB stick that's much bigger.
>>>
>>> So, when it comes to answering where your install files are, they are
>>> on
>>> a disk, but it's NOT a mounted disk. It's on your USB drive that's
>>> not
>>> mounted now, and won't be after installation, but could be useful
>>> shortly.
>>>
>>> Your next problem is...WHICH disk? On a minimal system, it would be
>>> the
>>> next sd device after your install disk -- assuming you are installing
>>> to
>>> sd0, your USB stick might be sd1. HOWEVER, if you have a flash media
>>> reader
>>> on your system, who knows where it is. One trick would be to unplug
>>> your
>>> USB drive and plug it back in and look at the white-on-blue console
>>> message
>>> that come up at you. Yes, you are unpluging your boot device, sounds
>>> bad,
>>> but read what I wrote earlier, it's no longer using that -- the boot
>>> has
>>> completed, and it's running from RAM now, it's completely ignoring
>>> that
>>> USB drive. So let's say you do this and you see it's sd4. Tell the
>>> installer the files are coming from a file system not currently
>>> mounted
>>> and when it asks, tell it "sd4"
>>>
>>> Nick.
>>>
>>>
> Another question. I know I need to write the boot file to the usb drive
> thus:
> # dd if=install66.fs of=/dev/da0 bs=1M conv=sync
> But can I just use plain old "cp base66.tgz /mnt" etc for the other
> files?
>
Sounds like you are rushing too quickly and too much being used to
wrong approach learned on Linux.........
How about to start here first:
https://www.openbsd.org/faq/faq4.html
then:
https://www.openbsd.org/faq/faq1.html#ManPages
https://www.openbsd.org/faq/faq10.html
followed by anything more you will need.
Trust me, you will be surprised how many questions will not need to be
asked at all in future ;-)
> On Fri, Nov 29, 2019 at 1:26 AM Clay Daniels
> <clay.daniels.jr@gmail.com>
> wrote:
>
>> Nick, thanks for straightening me out about what is actually going on
>> here
>> with the install. I see that there is now a fresh snapshot with
>> today's
>> date, not the one I downloaded and ran yesterday. This might tend to
>> keep
>> one busy. I'm not sure I would not be better off doing what Bruno &
>> Marc
>> suggested and run sysupgrade. Thanks to them for the advice.
>>
>> If I do decide to put the filesets on the the install thumbdrive, I
>> see a
>> total of 26 files in the directory. Obviously some are not necessary
>> like
>> the floppy or both the .fs & .iso (just one needed), nor the test
>> instructions, etc.
>> So which files do I REALLY need on my usb thumbdrive to get a complete
>> install, x included?
>>
>> Please excuse the "top-posting". That's the only way my darn google
>> does reply's. Kind of irritating, to me and the reader too.
>>
>> Clay
>>
>>
>>
>>
>> On Thu, Nov 28, 2019 at 12:34 PM Nick Holland
>> <nick@holland-consulting.net>
>> wrote:
>>
>>> On 2019-11-27 21:29, Edgar Pettijohn wrote:
>>> > On Wed, Nov 27, 2019 at 08:05:30PM -0600, Clay Daniels wrote:
>>> >> I have successfully installed OpenBSD 6.6 release and would like to
>>> give
>>> >> the Current Snapshots a try. I went to a mirror, and to:
>>> >>
>>> >> Index of /pub/OpenBSD/snapshots/amd64/
>>> >>
>>> >> I saw install66.fs (probably for usb memstick) and install66.iso
>>> (surely
>>> >> for a cd/dvd) at ~450Mb. I picked the install66.fs, wrote it to a usb
>>> >> thumbdrive, and it starts the install. When i get into the install it
>>> asks
>>> >> where are the file sets? Humm, maybe it gets these online and it tries
>>> to
>>> >> do this but no luck. It was late last night, and I checked to see if
>>> it had
>>> >> written anything to my disk, which it had not, and went to bed. This
>>> >> evening I'm looking a bit deeper at the snapshot directory and I
>>> suspect I
>>> >> need to provide the install with base66.tzg at ~239Mb.
>>>
>>> NO!
>>>
>>> [snip misleading stuff]
>>> > I noticed this also, but hadn't had time to figure out if I had messed
>>> up or
>>> > the installer had. As a general rule I assume its me that messed up.
>>> Its odd
>>> > if you mount the install66.fs you can see the pub/amd64 directory, but
>>> during
>>> > installation it can't seem to find the directory regardless of what I
>>> have
>>> > tried.
>>> >
>>> > Edgar
>>>
>>> First of all...nothing at all to do about snapshots -- the OpenBSD
>>> installation process has remained amazingly stable over the last 20
>>> years.
>>> New options here and there, but overall, very similar. Unless
>>> something
>>> changed in the last few days, installing a snapshot is identical to
>>> installing 6.6.
>>>
>>> The installXX.iso and installXX.fs are complete, stand-alone
>>> installation
>>> kits. Everything you need is on them. You can boot from them, and
>>> all
>>> the installation files are right there. Look Ma! No network needed!
>>> ...well...unfortunately there is the issue of firmware files, which
>>> are
>>> legally not feasible to put on the install media, so you will need
>>> network
>>> for most machines eventually. But let's ignore that for now. :)
>>>
>>> Once the system has booted on the install kernel, you have three
>>> devices
>>> you are working with:
>>> 1) the install kernel's internal "RAM disk" that is part of bsd.rd
>>> which
>>> you booted from,
>>> 2) your target disk
>>> 3) the USB drive with the install files on it.
>>>
>>> The reason you can't see the install files on the USB stick from the
>>> install kernel is they aren't mounted. You didn't boot from the
>>> entire
>>> USB stick, you booted from ONE TINY LITTLE bsd.rd file, that just
>>> happened
>>> to be sitting on the big USB stick...but as far as bsd.rd is
>>> concerned,
>>> the USB stick isn't part of the booted environment (yet).
>>>
>>> You aren't booting from a "Live Media". You are booting from a tiny
>>> kernel
>>> with a built in file system that's sitting on the same inert file
>>> system
>>> as
>>> the install files.
>>>
>>> Read that over and over until you understand what I'm saying, not
>>> what you
>>> are assuming is going on. It's really important to understand. It's
>>> very
>>> different from many Linux installation processes -- you are running
>>> off a
>>> file only 10MB in size which is now completely in RAM. That file
>>> JUST
>>> HAPPENED to come from a USB stick that's much bigger.
>>>
>>> So, when it comes to answering where your install files are, they are
>>> on
>>> a disk, but it's NOT a mounted disk. It's on your USB drive that's
>>> not
>>> mounted now, and won't be after installation, but could be useful
>>> shortly.
>>>
>>> Your next problem is...WHICH disk? On a minimal system, it would be
>>> the
>>> next sd device after your install disk -- assuming you are installing
>>> to
>>> sd0, your USB stick might be sd1. HOWEVER, if you have a flash media
>>> reader
>>> on your system, who knows where it is. One trick would be to unplug
>>> your
>>> USB drive and plug it back in and look at the white-on-blue console
>>> message
>>> that come up at you. Yes, you are unpluging your boot device, sounds
>>> bad,
>>> but read what I wrote earlier, it's no longer using that -- the boot
>>> has
>>> completed, and it's running from RAM now, it's completely ignoring
>>> that
>>> USB drive. So let's say you do this and you see it's sd4. Tell the
>>> installer the files are coming from a file system not currently
>>> mounted
>>> and when it asks, tell it "sd4"
>>>
>>> Nick.
>>>
>>>
[update] abcl-1.6.0
Hi,
Heres first attempt to update abcl to latest version.
This adds support for newer java versions.
Patching the port a bit to avoid fetching JUnit jar file in order to run tests.
Instead fetch it as part of distfiles and tweak the build file to include it.
Timo
Index: Makefile
===================================================================
RCS file: /cvs/ports/lang/abcl/Makefile,v
retrieving revision 1.16
diff -u -p -u -p -r1.16 Makefile
--- Makefile 22 Sep 2019 15:46:37 -0000 1.16
+++ Makefile 29 Nov 2019 07:53:37 -0000
@@ -1,15 +1,15 @@
# $OpenBSD: Makefile,v 1.16 2019/09/22 15:46:37 kurt Exp $
COMMENT = Common Lisp dialect for the Java Virtual Machine
-V = 1.5.0
+V = 1.6.0
+JUNIT_V = 4.12
DISTNAME = abcl-src-${V}
-REVISION = 3
PKGNAME = abcl-${V}
PKG_ARCH = *
CATEGORIES = lang
-HOMEPAGE = http://common-lisp.net/project/armedbear/
+HOMEPAGE = https://abcl.org/
MAINTAINER = Timo Myyra <timo.myyra@bittivirhe.fi>
@@ -17,9 +17,15 @@ MAINTAINER = Timo Myyra <timo.myyra@bit
PERMIT_PACKAGE = Yes
MASTER_SITES = ${HOMEPAGE}/releases/$V/
+MASTER_SITES0 = https://github.com/junit-team/junit4/releases/download/r${JUNIT_V}/
+
+DISTFILES = ${DISTNAME}${EXTRACT_SUFX} \
+ junit-${JUNIT_V}.jar:0
+
+EXTRACT_ONLY = ${DISTNAME}${EXTRACT_SUFX}
MODULES = java
-MODJAVA_VER = 1.8
+MODJAVA_VER = 1.8+
MODJAVA_BUILD = ant
MODJAVA_BUILD_TARGET_NAME = abcl.jar
@@ -40,7 +46,9 @@ do-install:
${INSTALL_DATA} ${FILESDIR}/abcl_completions ${ABCL_HOME}
do-test:
- cd ${WRKSRC} && ${SETENV} ${MAKE_ENV} ${LOCALBASE}/bin/ant ${TEST_TARGET}
+ cp -v ${FULLDISTDIR}/junit-${JUNIT_V}.jar ${WRKDIR}
+ cd ${WRKSRC} && ${SETENV} ${MAKE_ENV} ${LOCALBASE}/bin/ant \
+ -Djunit.path=${WRKDIR}/junit-${JUNIT_V}.jar ${TEST_TARGET}
# maintainer target to generate completions file
completions: install
Index: distinfo
===================================================================
RCS file: /cvs/ports/lang/abcl/distinfo,v
retrieving revision 1.6
diff -u -p -u -p -r1.6 distinfo
--- distinfo 31 Aug 2017 06:32:13 -0000 1.6
+++ distinfo 29 Nov 2019 07:53:37 -0000
@@ -1,2 +1,4 @@
-SHA256 (abcl-src-1.5.0.tar.gz) = kg7n1jSn9M7KCkadQx02EaMhxWaBTV3bktdZUMBjG8I=
-SIZE (abcl-src-1.5.0.tar.gz) = 1187678
+SHA256 (abcl-src-1.6.0.tar.gz) = iT/OgV0/yaOqJQx4/4TtLlG3AvccsR4b78Ki7Jxma0M=
+SHA256 (junit-4.12.jar) = WXIfCAXiI9hLkGd4h9n/Vn3FNNfFAsqQPAwrF/BcEWo=
+SIZE (abcl-src-1.6.0.tar.gz) = 2509074
+SIZE (junit-4.12.jar) = 314932
Index: files/abcl_completions
===================================================================
RCS file: /cvs/ports/lang/abcl/files/abcl_completions,v
retrieving revision 1.4
diff -u -p -u -p -r1.4 abcl_completions
--- files/abcl_completions 31 Aug 2017 06:32:13 -0000 1.4
+++ files/abcl_completions 29 Nov 2019 07:53:37 -0000
@@ -653,6 +653,7 @@ jvm:%make-protected-node
jvm:%make-synchronized-node
jvm:%make-tagbody-node
jvm:%make-unwind-protect-node
+jvm:%print-jvm-class-name
jvm:%with-compilation-unit
jvm:abcl-class-file-p
jvm:accumulate-operand
@@ -740,6 +741,7 @@ jvm:constant-float/int-p
jvm:constant-member-ref-p
jvm:constant-name/type-p
jvm:constant-p
+jvm:constant-pool-index
jvm:constant-string-p
jvm:constant-utf8-p
jvm:constant-value-attribute-p
@@ -2364,6 +2366,7 @@ system:backtrace
system:backtrace-as-list
system:base-classname
system:bit-array-same-dimensions-p
+system:bogus-sublist-error
system:boot-classloader
system:built-in-function-p
system:cache-emf
@@ -2509,6 +2512,7 @@ system:dump-vector
system:empty-environment-p
system:ensure-available-symbols
system:ensure-input-stream
+system:enumerate-resource-directories
system:environment-add-function-definition
system:environment-add-macro-definition
system:environment-add-symbol-binding
@@ -2558,6 +2562,7 @@ system:find-system
system:find-system-jar
system:fixnum-constant-value
system:fixnum-type-p
+system:flatten
system:float-denormalized-p
system:float-infinity-p
system:float-nan-p
@@ -2631,9 +2636,11 @@ system:internal-debug
system:invoke-debugger-report-condition
system:istep
system:java-long-type-p
+system:java.class.path
system:keyword-supplied-p
system:keywordify
system:known-type-p
+system:lambda-list-broken-key-list-error
system:lambda-name
system:last-cons-of
system:layout-class
@@ -2954,6 +2961,7 @@ system:svset
system:swap-slots
system:symbol-macro-p
system:symbolicate
+system:system-artifacts-are-jars-p
system:system-jar-p
system:system-stream-p
system:to-file
Index: patches/patch-build_xml
===================================================================
RCS file: patches/patch-build_xml
diff -N patches/patch-build_xml
--- /dev/null 1 Jan 1970 00:00:00 -0000
+++ patches/patch-build_xml 29 Nov 2019 07:53:37 -0000
@@ -0,0 +1,22 @@
+$OpenBSD$
+
+allows skipping junit fetch during test phase.
+
+Index: build.xml
+--- build.xml.orig
++++ build.xml
+@@ -1014,11 +1014,9 @@ ${basedir}/../cl-bench
+ <get
+ src="http://cloud.github.com/downloads/KentBeck/junit/junit-4.8.1.jar"
+ usetimestamp="true"
+- dest="${junit.path}"/>
+- <get
+- src="${maven.dist.uri}"
+- usetimestamp="true"
+- dest="${maven.local.path}"/>
++ dest="${junit.path}"
++ skipexisting="true">
++ </get>
+ </target>
+
+ <target name="abcl.ext.maven" depends="abcl.ext">
Index: pkg/PLIST
===================================================================
RCS file: /cvs/ports/lang/abcl/pkg/PLIST,v
retrieving revision 1.4
diff -u -p -u -p -r1.4 PLIST
--- pkg/PLIST 31 Aug 2017 06:32:13 -0000 1.4
+++ pkg/PLIST 29 Nov 2019 07:53:37 -0000
@@ -476,3 +476,4 @@ abcl/src/org/armedbear/lisp/with-standar
abcl/src/org/armedbear/lisp/write-sequence.lisp
abcl/src/org/armedbear/lisp/zip.java
bin/abcl
+share/doc/pkg-readmes/${PKGSTEM}
Index: pkg/README
===================================================================
RCS file: pkg/README
diff -N pkg/README
--- /dev/null 1 Jan 1970 00:00:00 -0000
+++ pkg/README 29 Nov 2019 07:53:37 -0000
@@ -0,0 +1,2 @@
+In order to use CFFI to access foreign libraries the jna package needs
+to be installed.
Heres first attempt to update abcl to latest version.
This adds support for newer java versions.
Patching the port a bit to avoid fetching JUnit jar file in order to run tests.
Instead fetch it as part of distfiles and tweak the build file to include it.
Timo
Index: Makefile
===================================================================
RCS file: /cvs/ports/lang/abcl/Makefile,v
retrieving revision 1.16
diff -u -p -u -p -r1.16 Makefile
--- Makefile 22 Sep 2019 15:46:37 -0000 1.16
+++ Makefile 29 Nov 2019 07:53:37 -0000
@@ -1,15 +1,15 @@
# $OpenBSD: Makefile,v 1.16 2019/09/22 15:46:37 kurt Exp $
COMMENT = Common Lisp dialect for the Java Virtual Machine
-V = 1.5.0
+V = 1.6.0
+JUNIT_V = 4.12
DISTNAME = abcl-src-${V}
-REVISION = 3
PKGNAME = abcl-${V}
PKG_ARCH = *
CATEGORIES = lang
-HOMEPAGE = http://common-lisp.net/project/armedbear/
+HOMEPAGE = https://abcl.org/
MAINTAINER = Timo Myyra <timo.myyra@bittivirhe.fi>
@@ -17,9 +17,15 @@ MAINTAINER = Timo Myyra <timo.myyra@bit
PERMIT_PACKAGE = Yes
MASTER_SITES = ${HOMEPAGE}/releases/$V/
+MASTER_SITES0 = https://github.com/junit-team/junit4/releases/download/r${JUNIT_V}/
+
+DISTFILES = ${DISTNAME}${EXTRACT_SUFX} \
+ junit-${JUNIT_V}.jar:0
+
+EXTRACT_ONLY = ${DISTNAME}${EXTRACT_SUFX}
MODULES = java
-MODJAVA_VER = 1.8
+MODJAVA_VER = 1.8+
MODJAVA_BUILD = ant
MODJAVA_BUILD_TARGET_NAME = abcl.jar
@@ -40,7 +46,9 @@ do-install:
${INSTALL_DATA} ${FILESDIR}/abcl_completions ${ABCL_HOME}
do-test:
- cd ${WRKSRC} && ${SETENV} ${MAKE_ENV} ${LOCALBASE}/bin/ant ${TEST_TARGET}
+ cp -v ${FULLDISTDIR}/junit-${JUNIT_V}.jar ${WRKDIR}
+ cd ${WRKSRC} && ${SETENV} ${MAKE_ENV} ${LOCALBASE}/bin/ant \
+ -Djunit.path=${WRKDIR}/junit-${JUNIT_V}.jar ${TEST_TARGET}
# maintainer target to generate completions file
completions: install
Index: distinfo
===================================================================
RCS file: /cvs/ports/lang/abcl/distinfo,v
retrieving revision 1.6
diff -u -p -u -p -r1.6 distinfo
--- distinfo 31 Aug 2017 06:32:13 -0000 1.6
+++ distinfo 29 Nov 2019 07:53:37 -0000
@@ -1,2 +1,4 @@
-SHA256 (abcl-src-1.5.0.tar.gz) = kg7n1jSn9M7KCkadQx02EaMhxWaBTV3bktdZUMBjG8I=
-SIZE (abcl-src-1.5.0.tar.gz) = 1187678
+SHA256 (abcl-src-1.6.0.tar.gz) = iT/OgV0/yaOqJQx4/4TtLlG3AvccsR4b78Ki7Jxma0M=
+SHA256 (junit-4.12.jar) = WXIfCAXiI9hLkGd4h9n/Vn3FNNfFAsqQPAwrF/BcEWo=
+SIZE (abcl-src-1.6.0.tar.gz) = 2509074
+SIZE (junit-4.12.jar) = 314932
Index: files/abcl_completions
===================================================================
RCS file: /cvs/ports/lang/abcl/files/abcl_completions,v
retrieving revision 1.4
diff -u -p -u -p -r1.4 abcl_completions
--- files/abcl_completions 31 Aug 2017 06:32:13 -0000 1.4
+++ files/abcl_completions 29 Nov 2019 07:53:37 -0000
@@ -653,6 +653,7 @@ jvm:%make-protected-node
jvm:%make-synchronized-node
jvm:%make-tagbody-node
jvm:%make-unwind-protect-node
+jvm:%print-jvm-class-name
jvm:%with-compilation-unit
jvm:abcl-class-file-p
jvm:accumulate-operand
@@ -740,6 +741,7 @@ jvm:constant-float/int-p
jvm:constant-member-ref-p
jvm:constant-name/type-p
jvm:constant-p
+jvm:constant-pool-index
jvm:constant-string-p
jvm:constant-utf8-p
jvm:constant-value-attribute-p
@@ -2364,6 +2366,7 @@ system:backtrace
system:backtrace-as-list
system:base-classname
system:bit-array-same-dimensions-p
+system:bogus-sublist-error
system:boot-classloader
system:built-in-function-p
system:cache-emf
@@ -2509,6 +2512,7 @@ system:dump-vector
system:empty-environment-p
system:ensure-available-symbols
system:ensure-input-stream
+system:enumerate-resource-directories
system:environment-add-function-definition
system:environment-add-macro-definition
system:environment-add-symbol-binding
@@ -2558,6 +2562,7 @@ system:find-system
system:find-system-jar
system:fixnum-constant-value
system:fixnum-type-p
+system:flatten
system:float-denormalized-p
system:float-infinity-p
system:float-nan-p
@@ -2631,9 +2636,11 @@ system:internal-debug
system:invoke-debugger-report-condition
system:istep
system:java-long-type-p
+system:java.class.path
system:keyword-supplied-p
system:keywordify
system:known-type-p
+system:lambda-list-broken-key-list-error
system:lambda-name
system:last-cons-of
system:layout-class
@@ -2954,6 +2961,7 @@ system:svset
system:swap-slots
system:symbol-macro-p
system:symbolicate
+system:system-artifacts-are-jars-p
system:system-jar-p
system:system-stream-p
system:to-file
Index: patches/patch-build_xml
===================================================================
RCS file: patches/patch-build_xml
diff -N patches/patch-build_xml
--- /dev/null 1 Jan 1970 00:00:00 -0000
+++ patches/patch-build_xml 29 Nov 2019 07:53:37 -0000
@@ -0,0 +1,22 @@
+$OpenBSD$
+
+allows skipping junit fetch during test phase.
+
+Index: build.xml
+--- build.xml.orig
++++ build.xml
+@@ -1014,11 +1014,9 @@ ${basedir}/../cl-bench
+ <get
+ src="http://cloud.github.com/downloads/KentBeck/junit/junit-4.8.1.jar"
+ usetimestamp="true"
+- dest="${junit.path}"/>
+- <get
+- src="${maven.dist.uri}"
+- usetimestamp="true"
+- dest="${maven.local.path}"/>
++ dest="${junit.path}"
++ skipexisting="true">
++ </get>
+ </target>
+
+ <target name="abcl.ext.maven" depends="abcl.ext">
Index: pkg/PLIST
===================================================================
RCS file: /cvs/ports/lang/abcl/pkg/PLIST,v
retrieving revision 1.4
diff -u -p -u -p -r1.4 PLIST
--- pkg/PLIST 31 Aug 2017 06:32:13 -0000 1.4
+++ pkg/PLIST 29 Nov 2019 07:53:37 -0000
@@ -476,3 +476,4 @@ abcl/src/org/armedbear/lisp/with-standar
abcl/src/org/armedbear/lisp/write-sequence.lisp
abcl/src/org/armedbear/lisp/zip.java
bin/abcl
+share/doc/pkg-readmes/${PKGSTEM}
Index: pkg/README
===================================================================
RCS file: pkg/README
diff -N pkg/README
--- /dev/null 1 Jan 1970 00:00:00 -0000
+++ pkg/README 29 Nov 2019 07:53:37 -0000
@@ -0,0 +1,2 @@
+In order to use CFFI to access foreign libraries the jna package needs
+to be installed.
Subscribe to:
Posts (Atom)