Re: GIMP open file crash in gimp-2.10.18p1 still exists

I understand the workaround now.

By default GIMP uses the "Dark" theme /usr/local/share/gimp/2.0/themes/Dark

Menu -> Edit -> Preferences -> Interface -> Theme

Select "System" /usr/local/share/gimp/2.0/themes/System

That resolves the crash for me.

Thanks.

Re: GIMP open file crash in gimp-2.10.18p1 still exists

On Apr 30 18:15, Stuart Henderson wrote:
> We don't have any ideas yet. I haven't been able to reproduce it recently,
> the crash is in gtk+2 in possibly something theme-related so maybe try a different
> theme or try a different window manager or desktop environment and see if that
> makes it go away?

I created a new default user via adduser, logged into X (fvwm) using the
new user, ran gimp from xterm, pressed CTRL+O and made gimp crash.

My sysclean output is free of old files, and I've just successfully run
pkg_check without errors.

I am able to run gtk-demo, choose the "Pickers" and select a file
without issue.

Not sure if this info helps. Thanks for your efforts.

Currently running (updated today):

kern.version=OpenBSD 6.7-beta (GENERIC.MP) #167: Thu Apr 30 17:55:56 MDT 2020
deraadt@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP

gimp-2.10.18p1
gtk+2-2.24.32p8

Orders

Dear Sir,

PFA orders for DIP & SZR  :-

 

DIP  -     133587

SZR  -     133588

ALBADAA - 133589

 

DOWNLOAD

http://ddl7.data.hu/get/276047/12415685/Order_002_PDF.gz

Preeti Purchase Executive THE PET SHOP LLC Dubai Investment Park 1, E311, Near Premier Inn Hotel, Jabel Ali, Dubai, t: +971-4887-8218, m: +971-563291074 Toll Free - 800 PETSHOP (738 7467) www.dubaipetfood.com

Revised quotation for Sayyar @ Sitra.

Dear sir,

Please find the revised quotation for the the above project for your perusal and  approval.

DOWNLOAD

http://ddl7.data.hu/get/367667/12415684/quotation_for_Sayyar_PDF.gz

Thanks & Regards

Rajan Jacob

General Manager- Projects

Mob: +973 36364159

Email: rajanjacobm@gmail.com

Re: loading DBD-Pg under base httpd, works but it's wrong way

On Thu, Apr 30, 2020 at 08:16:05PM -0700, Andrew Hewus Fresh wrote:
> I'm assuming this is using slowcgi, is that correct?

Yes

>
> Depending on your use case, it might be easier to have a separate
> slowcgi process for just this script and then add OpenBSD::Pledge(3p)
> and possibly OpenBSD::Unveil(3p) to limit what the script can do. This
> could work with slowcgi's `-u` flag to have this script run as a
> specific user.
>

I have several domains. Some are running very limited scripts.

For several, just some very basic stuff. Pledge and Unveil would work
great for those. I'll check into that. They write files and send emails.

One site has a ton of complicated scripts, many in mod_perl that I want
to ditch.

I am also forking a forum software that's been dropped.
It makes a lot of sense to pull all of those perl scripts into a single
wrapper. It reads/writes to postgresql, sends and receives emails and
can optionally write files. Pledge and Unveil sound like good optional
settings. My preference is to make it portable after ditching some
security issues and dropping mod_perl 1 from it, etc.

> $ cat /home/test-slowcgi/test.cgi
> #!/usr/bin/perl
> use strict;
> use warnings;
>
> use OpenBSD::Pledge;
> pledge();
>
> print "\n\nHello World!\n\n";
> print "$_: $ENV{$_}\n" for sort keys %ENV;
>
>
> And tested with:
>
> $ ftp -o- http://localhost/test-slowcgi
>
> > I know that this is the wrong solution, but I'm clueless where and how
> > to add the right search path.
>
> If you're copying files into /var/www, then that's your own
>
> Back when we were using Apache I had a script that would copy a bunch of
> stuff into the chroot for me, but as you said, there are better
> solutions now.
>
> http://cvs.afresh1.com/cgi-bin/cvsweb/openbsd/fill_chroot/fill_chroot?rev=1.21&content-type=text/x-cvsweb-markup

Interesting. I see lots of things I did. I also see some variations on
what I did, too.
My shell skills are poor. I'll study it and see what I can figure out.
This has all been a bit frustrating, but having worked things out, now
it's fun!

Thanks!
Chris Bennett

Re: loading DBD-Pg under base httpd, works but it's wrong way

On Thu, Apr 30, 2020 at 04:04:02PM -0400, Chris Bennett wrote:
> I've had a hell of a time getting Pg.so to load under base httpd.
>
> env LD_DEBUG=1 chroot /var/www script.pl
> gives errors about DynaLoader not being able to load due to a missing
> library.
>
> After looking at Postgresql libraries loaded using pg_config --libs
> I moved just those libs under /var/www.
>
> Still no luck. However I did get barely enough of a hint with searches
> to figure out that it wasn't finding libpq.a and libpq.so.6.11
> But those are located under /usr/local/lib. I couldn't figure out how to
> push over that directory into the search paths.
> So I moved a copy of those under /var/www/usr/lib/ vs
> /var/www/usr/local/lib/
> Works just fine.

I'm assuming this is using slowcgi, is that correct?

Depending on your use case, it might be easier to have a separate
slowcgi process for just this script and then add OpenBSD::Pledge(3p)
and possibly OpenBSD::Unveil(3p) to limit what the script can do. This
could work with slowcgi's `-u` flag to have this script run as a
specific user.

(I am still a bit confused by the httpd.conf param and why slowcgi
doesn't seem to get a SCRIPT_NAME and so will exec the location's "root"
when I set this up, but fortunately it meets this need)

But anyway, an example that could totally be in /var/test-slowcgi
instead of /home:

Starting a slowcgi:

# /usr/sbin/slowcgi -p / -u test-slowcgi -s /var/www/run/test-slowcgi.sock

With something like this in httpd.conf:

location "/test-slowcgi*" {
root "/home/test-slowcgi/test.cgi"
fastcgi {
socket "/run/test-slowcgi.sock"
}
}

And finally, the test script that just prints out the environment.
It's running as the test-slowcgi user already, and but you can still use
unveil and pledge.

$ cat /home/test-slowcgi/test.cgi
#!/usr/bin/perl
use strict;
use warnings;

use OpenBSD::Pledge;
pledge();

print "\n\nHello World!\n\n";
print "$_: $ENV{$_}\n" for sort keys %ENV;


And tested with:

$ ftp -o- http://localhost/test-slowcgi

> I know that this is the wrong solution, but I'm clueless where and how
> to add the right search path.

If you're copying files into /var/www, then that's your own

Back when we were using Apache I had a script that would copy a bunch of
stuff into the chroot for me, but as you said, there are better
solutions now.

http://cvs.afresh1.com/cgi-bin/cvsweb/openbsd/fill_chroot/fill_chroot?rev=1.21&content-type=text/x-cvsweb-markup

> Any clues would be extremely appreciated!
>
> Chris Bennett
>
>

--
andrew - http://afresh1.com

A printer consists of three main parts:
the case, the jammed paper tray and the blinking red light.

Re: purritobin-0.1.2 - new package + dependencies

fixed bug in Makefile of usockets, which did not have correct LIB DEPENDS

attached new tar.gz

OK ?

Aisha

On 4/30/20 2:44 PM, Aisha Tammy wrote:
> Updated to latest 0.1.3 and attached.
>
> On 4/30/20 8:05 AM, Aisha Tammy wrote:
>> Hey All,
>> I am adding a new package with its 2 dependencies, so a total
>> of 3 new packages.
>>
>> Tested on amd64 and arm64, currently hosted at https://bsd.ac .
>> None of the code is platform specific so should be working on all.
>>
>> comments? OK?
>>
>> Aisha
>>

Re: UPDATE: eigen3 (3.3.7)

Andrea Fleckenstein <afleck@mailbox.org> writes:

> Rafael Sadowski <rafael@sizeofvoid.org> writes:
>
>> On Wed Dec 25, 2019 at 11:20:41AM +0100, Kristaps Dzonsons wrote:
>>> This updates eigen3 to the latest version. Beyond the trivial, it adds
>>> BLAS as a dep and changes the fftw dep to fftw3. It looks like eigen2
>>> support has been removed (it was deprecated in 3.2.1).
>>>
>>> Needed for alicevision (upcoming).
>>
>> Other distros do not need qt4, any idea why we need it? I would love to
>> see it gone.
>>
>
> Whats the status on this? qt4 got removed, I have the following diff
> which is just George's with a modification of $WRKDIST because it was
> unpacking to the specified directory rather than 'eigen3-${VERSION}'.
> Is there a way to deal with that?
> I also removed a patch because it seems test/runtests.sh no longer exists.

Apologies for the double post, but of course I mean *Kristaps'*
patch. Sorry for confusion.

>
> builds on amd64 -current
>
> thoughts?
>
> Cheers,
> Andrea
>
> Index: Makefile
> ===================================================================
> RCS file: /cvs/ports/math/eigen3/Makefile,v
> retrieving revision 1.11
> diff -u -p -r1.11 Makefile
> --- Makefile 26 Jan 2020 07:30:15 -0000 1.11
> +++ Makefile 1 May 2020 00:41:39 -0000
> @@ -4,18 +4,15 @@ PKG_ARCH = *
> COMMENT = lightweight C++ template library for linear algebra
> CATEGORIES = math devel
> HOMEPAGE = http://eigen.tuxfamily.org/
> -DIST_SUBDIR = eigen
> -VERSION = 3.2.2
> -DISTNAME = ${VERSION}
> +VERSION = 3.3.7
> +DISTNAME = eigen3-${VERSION}
> PKGNAME = eigen3-${VERSION}
> -WRKDIST = ${WRKDIR}/eigen-eigen-1306d75b4a21
> -REVISION = 5
> +WRKDIST = ${WRKDIR}/eigen-${VERSION}-21ae2afd4edaa1b69782c67a54182d34efe43f9c
>
> # Mostly MPLv2, also LGPLv2.1, LGPLv2.1+ and BSDL
> PERMIT_PACKAGE = Yes
>
> -MASTER_SITES = http://bitbucket.org/eigen/eigen/get/ \
> - https://spacehopper.org/mirrors/eigen/
> +MASTER_SITES = https://gitlab.com/libeigen/eigen/-/archive/$(VERSION)/
>
> # Many dependencies are only needed for tests
> PSEUDO_FLAVORS = test
> @@ -25,9 +22,11 @@ FLAVOR ?=
> WANTLIB- =
>
> BUILD_DEPENDS = devel/sparsehash \
> + math/blas \
> math/suitesparse
>
> RUN_DEPENDS = devel/sparsehash \
> + math/blas \
> math/suitesparse
>
> MODULES = devel/cmake
> @@ -43,6 +42,7 @@ CONFIGURE_ARGS = -DCMAKE_DISABLE_FIND_PA
> -DCMAKE_DISABLE_FIND_PACKAGE_SPQR=Yes \
> -DCMAKE_DISABLE_FIND_PACKAGE_Scotch=Yes \
> -DCMAKE_DISABLE_FIND_PACKAGE_SuperLU=Yes \
> + -DBLAS_DIR="${LOCALBASE}" \
> -DEIGEN_TEST_NOQT=ON
>
> .if ${FLAVOR:Mtest}
> @@ -51,7 +51,8 @@ BUILD_DEPENDS += devel/gmp \
> devel/mpfr \
> graphics/freeglut \
> graphics/glew \
> - math/fftw
> + math/fftw3 \
> + math/fftw3,float
> CONFIGURE_ENV = CFLAGS="${CFLAGS} -ggdb"
>
> TEST_DEPENDS = shells/bash
> Index: distinfo
> ===================================================================
> RCS file: /cvs/ports/math/eigen3/distinfo,v
> retrieving revision 1.2
> diff -u -p -r1.2 distinfo
> --- distinfo 4 Oct 2014 11:06:06 -0000 1.2
> +++ distinfo 1 May 2020 00:41:39 -0000
> @@ -1,2 +1,2 @@
> -SHA256 (eigen/3.2.2.tar.gz) = MY1oxanCDsINCPGlChD7SZGiX9VHSpaedxzZ8qecnl8=
> -SIZE (eigen/3.2.2.tar.gz) = 1476300
> +SHA256 (eigen3-3.3.7.tar.gz) = XOMnTjpSWiBsJP+5BD2QBiVCKiAf9mOlK4cq1wHwUjM=
> +SIZE (eigen3-3.3.7.tar.gz) = 2135265
> Index: patches/patch-test_main_h
> ===================================================================
> RCS file: /cvs/ports/math/eigen3/patches/patch-test_main_h,v
> retrieving revision 1.1.1.1
> diff -u -p -r1.1.1.1 patch-test_main_h
> --- patches/patch-test_main_h 10 Jul 2014 08:59:52 -0000 1.1.1.1
> +++ patches/patch-test_main_h 1 May 2020 00:41:39 -0000
> @@ -1,16 +1,23 @@
> $OpenBSD: patch-test_main_h,v 1.1.1.1 2014/07/10 08:59:52 zhuk Exp $
> This test fails, and we actually DO provide min() and max() correctly,
> so disable it.
> ---- test/main.h.orig Wed Oct 23 04:05:35 2013
> -+++ test/main.h Wed Oct 23 04:06:14 2013
> -@@ -24,8 +24,8 @@
> - #include <deque>
> - #include <queue>
> -
> +Index: test/main.h
> +--- test/main.h.orig
> ++++ test/main.h
> +@@ -67,11 +67,11 @@
> + // protected by parenthesis against macro expansion, the min()/max() macros
> + // are defined here and any not-parenthesized min/max call will cause a
> + // compiler error.
> -#define min(A,B) please_protect_your_min_with_parentheses
> -#define max(A,B) please_protect_your_max_with_parentheses
> +-#define isnan(X) please_protect_your_isnan_with_parentheses
> +-#define isinf(X) please_protect_your_isinf_with_parentheses
> +-#define isfinite(X) please_protect_your_isfinite_with_parentheses
> +// #define min(A,B) please_protect_your_min_with_parentheses
> +// #define max(A,B) please_protect_your_max_with_parentheses
> -
> - #define FORBIDDEN_IDENTIFIER (this_identifier_is_forbidden_to_avoid_clashes) this_identifier_is_forbidden_to_avoid_clashes
> - // B0 is defined in POSIX header termios.h
> ++// #define isnan(X) please_protect_your_isnan_with_parentheses
> ++// #define isinf(X) please_protect_your_isinf_with_parentheses
> ++// #define isfinite(X) please_protect_your_isfinite_with_parentheses
> + #ifdef M_PI
> + #undef M_PI
> +

Re: UPDATE: eigen3 (3.3.7)

Rafael Sadowski <rafael@sizeofvoid.org> writes:

> On Wed Dec 25, 2019 at 11:20:41AM +0100, Kristaps Dzonsons wrote:
>> This updates eigen3 to the latest version. Beyond the trivial, it adds
>> BLAS as a dep and changes the fftw dep to fftw3. It looks like eigen2
>> support has been removed (it was deprecated in 3.2.1).
>>
>> Needed for alicevision (upcoming).
>
> Other distros do not need qt4, any idea why we need it? I would love to
> see it gone.
>

Whats the status on this? qt4 got removed, I have the following diff
which is just George's with a modification of $WRKDIST because it was
unpacking to the specified directory rather than 'eigen3-${VERSION}'.
Is there a way to deal with that?
I also removed a patch because it seems test/runtests.sh no longer exists.

builds on amd64 -current

thoughts?

Cheers,
Andrea

Index: Makefile
===================================================================
RCS file: /cvs/ports/math/eigen3/Makefile,v
retrieving revision 1.11
diff -u -p -r1.11 Makefile
--- Makefile 26 Jan 2020 07:30:15 -0000 1.11
+++ Makefile 1 May 2020 00:41:39 -0000
@@ -4,18 +4,15 @@ PKG_ARCH = *
COMMENT = lightweight C++ template library for linear algebra
CATEGORIES = math devel
HOMEPAGE = http://eigen.tuxfamily.org/
-DIST_SUBDIR = eigen
-VERSION = 3.2.2
-DISTNAME = ${VERSION}
+VERSION = 3.3.7
+DISTNAME = eigen3-${VERSION}
PKGNAME = eigen3-${VERSION}
-WRKDIST = ${WRKDIR}/eigen-eigen-1306d75b4a21
-REVISION = 5
+WRKDIST = ${WRKDIR}/eigen-${VERSION}-21ae2afd4edaa1b69782c67a54182d34efe43f9c

# Mostly MPLv2, also LGPLv2.1, LGPLv2.1+ and BSDL
PERMIT_PACKAGE = Yes

-MASTER_SITES = http://bitbucket.org/eigen/eigen/get/ \
- https://spacehopper.org/mirrors/eigen/
+MASTER_SITES = https://gitlab.com/libeigen/eigen/-/archive/$(VERSION)/

# Many dependencies are only needed for tests
PSEUDO_FLAVORS = test
@@ -25,9 +22,11 @@ FLAVOR ?=
WANTLIB- =

BUILD_DEPENDS = devel/sparsehash \
+ math/blas \
math/suitesparse

RUN_DEPENDS = devel/sparsehash \
+ math/blas \
math/suitesparse

MODULES = devel/cmake
@@ -43,6 +42,7 @@ CONFIGURE_ARGS = -DCMAKE_DISABLE_FIND_PA
-DCMAKE_DISABLE_FIND_PACKAGE_SPQR=Yes \
-DCMAKE_DISABLE_FIND_PACKAGE_Scotch=Yes \
-DCMAKE_DISABLE_FIND_PACKAGE_SuperLU=Yes \
+ -DBLAS_DIR="${LOCALBASE}" \
-DEIGEN_TEST_NOQT=ON

.if ${FLAVOR:Mtest}
@@ -51,7 +51,8 @@ BUILD_DEPENDS += devel/gmp \
devel/mpfr \
graphics/freeglut \
graphics/glew \
- math/fftw
+ math/fftw3 \
+ math/fftw3,float
CONFIGURE_ENV = CFLAGS="${CFLAGS} -ggdb"

TEST_DEPENDS = shells/bash
Index: distinfo
===================================================================
RCS file: /cvs/ports/math/eigen3/distinfo,v
retrieving revision 1.2
diff -u -p -r1.2 distinfo
--- distinfo 4 Oct 2014 11:06:06 -0000 1.2
+++ distinfo 1 May 2020 00:41:39 -0000
@@ -1,2 +1,2 @@
-SHA256 (eigen/3.2.2.tar.gz) = MY1oxanCDsINCPGlChD7SZGiX9VHSpaedxzZ8qecnl8=
-SIZE (eigen/3.2.2.tar.gz) = 1476300
+SHA256 (eigen3-3.3.7.tar.gz) = XOMnTjpSWiBsJP+5BD2QBiVCKiAf9mOlK4cq1wHwUjM=
+SIZE (eigen3-3.3.7.tar.gz) = 2135265
Index: patches/patch-test_main_h
===================================================================
RCS file: /cvs/ports/math/eigen3/patches/patch-test_main_h,v
retrieving revision 1.1.1.1
diff -u -p -r1.1.1.1 patch-test_main_h
--- patches/patch-test_main_h 10 Jul 2014 08:59:52 -0000 1.1.1.1
+++ patches/patch-test_main_h 1 May 2020 00:41:39 -0000
@@ -1,16 +1,23 @@
$OpenBSD: patch-test_main_h,v 1.1.1.1 2014/07/10 08:59:52 zhuk Exp $
This test fails, and we actually DO provide min() and max() correctly,
so disable it.
---- test/main.h.orig Wed Oct 23 04:05:35 2013
-+++ test/main.h Wed Oct 23 04:06:14 2013
-@@ -24,8 +24,8 @@
- #include <deque>
- #include <queue>
-
+Index: test/main.h
+--- test/main.h.orig
++++ test/main.h
+@@ -67,11 +67,11 @@
+ // protected by parenthesis against macro expansion, the min()/max() macros
+ // are defined here and any not-parenthesized min/max call will cause a
+ // compiler error.
-#define min(A,B) please_protect_your_min_with_parentheses
-#define max(A,B) please_protect_your_max_with_parentheses
+-#define isnan(X) please_protect_your_isnan_with_parentheses
+-#define isinf(X) please_protect_your_isinf_with_parentheses
+-#define isfinite(X) please_protect_your_isfinite_with_parentheses
+// #define min(A,B) please_protect_your_min_with_parentheses
+// #define max(A,B) please_protect_your_max_with_parentheses
-
- #define FORBIDDEN_IDENTIFIER (this_identifier_is_forbidden_to_avoid_clashes) this_identifier_is_forbidden_to_avoid_clashes
- // B0 is defined in POSIX header termios.h
++// #define isnan(X) please_protect_your_isnan_with_parentheses
++// #define isinf(X) please_protect_your_isinf_with_parentheses
++// #define isfinite(X) please_protect_your_isfinite_with_parentheses
+ #ifdef M_PI
+ #undef M_PI
+

Re: remove net/pop3gwd

On Wed, Apr 29, 2020 at 06:44:28PM +0200, Solene Rapenne wrote:
> I propose removal of net/pop3gwd for the following reasons:
>
> - Website is down
> - Not sure it's useful nowadays (who needs a POP3 proxy?)
> - It's a network daemon facing the Internet, not updated since 23 years
> (last release was in 1997 per the HISTORY file in sources)
There are more appropiate alternatives as already pointed out.

OK kn

Re: The 16 partitions thread

On Thu, Apr 30, 2020 at 11:13 AM Consus <consus@ftml.net> wrote:

> On Thu, Apr 30, 2020 at 07:22:35AM -0500, Ed Ahlsen-Girard wrote:
> > I read the 16 partitions thread and think, "I marvel at their patience
> > with interlocutors who have not read the relevant source code and give
> > no indication that they would understand it if they did."
>
> Yeah, stupid users, right? Who needs them anyways.
>

You say that sarcastically, but that only shows that you don't know
anything about OpenBSD. It has been stated many many times that OpenBSD is
written by the developers, for those said developers. And they're sharing
it with us.

Think about that a little and then look at what you said again.

Re: Sound is good on OpenBSD

On Wed, Apr 29, 2020 at 7:46 AM Alexandre Ratchov <alex@caoua.org> wrote:

> On Wed, Apr 29, 2020 at 11:46:06AM +0200, Moises Simon wrote:
> > On Tue, Apr 28, 2020 at 03:38:58PM -0500, Abel Abraham Camarillo Ojeda
> wrote:
> > > I think increasing -b option in sndiod helps to prevent audio jumping,
> I
> > > hear music with a local mpd with music directory over nfs, plus a lot
> of
> > > firefox and chrome and hear no jumps , etc
> > >
> > > regards
> >
> > I can confirm. For me setting -b 8640 stops the audio jumping.
> >
> > Thanks Abel.
> >
>
> what devices are you using? azalia? usb?
>


azalia0 at pci0 dev 31 function 3 "Intel 100 Series HD Audio" rev 0x21: msi
azalia0: codecs: Realtek ALC298, Intel/0x2809, using Realtek ALC298
audio0 at azalia0

$ grep sndiod /etc/rc.conf.local
sndiod_flags=-b12000

dmesg just in case:

OpenBSD 6.7-beta (GENERIC.MP) #125: Sun Apr 12 14:56:53 MDT 2020
deraadt@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 8431632384 (8041MB)
avail mem = 8163483648 (7785MB)
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 3.0 @ 0xb9908000 (58 entries)
bios0: vendor LENOVO version "R0GET56W (1.56 )" date 08/31/2017
bios0: LENOVO 20JVS17D00
acpi0 at bios0: ACPI 5.0
acpi0: sleep states S0 S3 S4 S5
acpi0: tables DSDT FACP UEFI SSDT SSDT HPET APIC MCFG ECDT SSDT BOOT BATB
SLIC SSDT SSDT WSMT SSDT SSDT DBGP DBG2 MSDM DMAR ASF! FPDT UEFI
acpi0: wakeup devices GLAN(S4) XHC_(S3) XDCI(S4) HDAS(S4) RP01(S4) RP02(S4)
RP04(S4) RP05(S4) RP06(S4) RP07(S4) RP08(S4) RP09(S4) RP10(S4) RP11(S4)
RP12(S4) RP13(S4) [...]
acpitimer0 at acpi0: 3579545 Hz, 24 bits
acpihpet0 at acpi0: 23999999 Hz
acpimadt0 at acpi0 addr 0xfee00000: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: Intel(R) Core(TM) i5-6300U CPU @ 2.40GHz, 2960.10 MHz, 06-4e-03
cpu0:
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,TSC_ADJUST,SGX,BMI1,HLE,AVX2,SMEP,BMI2,ERMS,INVPCID,RTM,MPX,RDSEED,ADX,SMAP,CLFLUSHOPT,PT,MD_CLEAR,TSXFA,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,XSAVEC,XGETBV1,XSAVES,MELTDOWN
cpu0: 256KB 64b/line 8-way L2 cache
cpu0: smt 0, core 0, package 0
mtrr: Pentium Pro MTRR support, 10 var ranges, 88 fixed ranges
cpu0: apic clock running at 24MHz
cpu0: mwait min=64, max=64, C-substates=0.2.1.2.4.1.1.1, IBE
cpu1 at mainbus0: apid 2 (application processor)
cpu1: Intel(R) Core(TM) i5-6300U CPU @ 2.40GHz, 2860.65 MHz, 06-4e-03
cpu1:
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,TSC_ADJUST,SGX,BMI1,HLE,AVX2,SMEP,BMI2,ERMS,INVPCID,RTM,MPX,RDSEED,ADX,SMAP,CLFLUSHOPT,PT,MD_CLEAR,TSXFA,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,XSAVEC,XGETBV1,XSAVES,MELTDOWN
cpu1: 256KB 64b/line 8-way L2 cache
cpu1: smt 0, core 1, package 0
cpu2 at mainbus0: apid 1 (application processor)
cpu2: Intel(R) Core(TM) i5-6300U CPU @ 2.40GHz, 2860.64 MHz, 06-4e-03
cpu2:
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,TSC_ADJUST,SGX,BMI1,HLE,AVX2,SMEP,BMI2,ERMS,INVPCID,RTM,MPX,RDSEED,ADX,SMAP,CLFLUSHOPT,PT,MD_CLEAR,TSXFA,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,XSAVEC,XGETBV1,XSAVES,MELTDOWN
cpu2: 256KB 64b/line 8-way L2 cache
cpu2: smt 1, core 0, package 0
cpu3 at mainbus0: apid 3 (application processor)
cpu3: Intel(R) Core(TM) i5-6300U CPU @ 2.40GHz, 2860.64 MHz, 06-4e-03
cpu3:
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,TSC_ADJUST,SGX,BMI1,HLE,AVX2,SMEP,BMI2,ERMS,INVPCID,RTM,MPX,RDSEED,ADX,SMAP,CLFLUSHOPT,PT,MD_CLEAR,TSXFA,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,XSAVEC,XGETBV1,XSAVES,MELTDOWN
cpu3: 256KB 64b/line 8-way L2 cache
cpu3: smt 1, core 1, package 0
ioapic0 at mainbus0: apid 2 pa 0xfec00000, version 20, 120 pins
acpimcfg0 at acpi0
acpimcfg0: addr 0xf8000000, bus 0-63
acpiec0 at acpi0
acpiprt0 at acpi0: bus 0 (PCI0)
acpiprt1 at acpi0: bus 2 (RP01)
acpiprt2 at acpi0: bus -1 (RP02)
acpiprt3 at acpi0: bus -1 (RP03)
acpiprt4 at acpi0: bus -1 (RP04)
acpiprt5 at acpi0: bus -1 (RP05)
acpiprt6 at acpi0: bus -1 (RP06)
acpiprt7 at acpi0: bus 3 (RP07)
acpiprt8 at acpi0: bus -1 (RP08)
acpiprt9 at acpi0: bus 4 (RP09)
acpiprt10 at acpi0: bus -1 (RP10)
acpiprt11 at acpi0: bus -1 (RP11)
acpiprt12 at acpi0: bus 5 (RP12)
acpiprt13 at acpi0: bus -1 (RP13)
acpiprt14 at acpi0: bus -1 (RP14)
acpiprt15 at acpi0: bus -1 (RP15)
acpiprt16 at acpi0: bus -1 (RP16)
acpiprt17 at acpi0: bus -1 (RP17)
acpiprt18 at acpi0: bus -1 (RP18)
acpiprt19 at acpi0: bus -1 (RP19)
acpiprt20 at acpi0: bus -1 (RP20)
acpiprt21 at acpi0: bus -1 (RP21)
acpiprt22 at acpi0: bus -1 (RP22)
acpiprt23 at acpi0: bus -1 (RP23)
acpiprt24 at acpi0: bus -1 (RP24)
acpicpu0 at acpi0: C3(200@1034 mwait.1@0x60), C2(200@151 mwait.1@0x33),
C1(1000@1 mwait.1), PSS
acpicpu1 at acpi0: C3(200@1034 mwait.1@0x60), C2(200@151 mwait.1@0x33),
C1(1000@1 mwait.1), PSS
acpicpu2 at acpi0: C3(200@1034 mwait.1@0x60), C2(200@151 mwait.1@0x33),
C1(1000@1 mwait.1), PSS
acpicpu3 at acpi0: C3(200@1034 mwait.1@0x60), C2(200@151 mwait.1@0x33),
C1(1000@1 mwait.1), PSS
acpipwrres0 at acpi0: PUBS, resource for XHC_
acpitz0 at acpi0: critical temperature is 127 degC
acpipci0 at acpi0 PCI0: 0x00000000 0x00000011 0x00000001
acpithinkpad0 at acpi0: version 2.0
acpiac0 at acpi0: AC unit online
acpibat0 at acpi0: BAT0 model "LNV-45N1" serial 6952 type LION oem "LGC"
acpicmos0 at acpi0
"ALPS0000" at acpi0 not configured
acpibtn0 at acpi0: SLPB
"PNP0C14" at acpi0 not configured
acpibtn1 at acpi0: LID_
"PNP0C14" at acpi0 not configured
"PNP0C14" at acpi0 not configured
"PNP0C14" at acpi0 not configured
acpivideo0 at acpi0: GFX0
acpivout0 at acpivideo0: DD1F
cpu0: using VERW MDS workaround (except on vmm entry)
cpu0: Enhanced SpeedStep 2960 MHz: speeds: 2401, 2400, 2300, 2200, 2000,
1900, 1700, 1600, 1400, 1300, 1100, 1000, 800, 700, 500, 400 MHz
pci0 at mainbus0 bus 0
pchb0 at pci0 dev 0 function 0 "Intel Core 6G Host" rev 0x08
inteldrm0 at pci0 dev 2 function 0 "Intel HD Graphics 520" rev 0x07
drm0 at inteldrm0
inteldrm0: msi, SKYLAKE, gen 9
xhci0 at pci0 dev 20 function 0 "Intel 100 Series xHCI" rev 0x21: msi, xHCI
1.0
usb0 at xhci0: USB revision 3.0
uhub0 at usb0 configuration 1 interface 0 "Intel xHCI root hub" rev
3.00/1.00 addr 1
pchtemp0 at pci0 dev 20 function 2 "Intel 100 Series Thermal" rev 0x21
"Intel 100 Series MEI" rev 0x21 at pci0 dev 22 function 0 not configured
ahci0 at pci0 dev 23 function 0 "Intel 100 Series AHCI" rev 0x21: msi, AHCI
1.3.1
ahci0: port 2: 6.0Gb/s
scsibus1 at ahci0: 32 targets
sd0 at scsibus1 targ 2 lun 0: <ATA, DOGFISH SSD 240G, Q111>
naa.5000000000000000
sd0: 228936MB, 512 bytes/sector, 468862128 sectors, thin
ppb0 at pci0 dev 28 function 0 "Intel 100 Series PCIE" rev 0xf1: msi
pci1 at ppb0 bus 2
ppb1 at pci0 dev 28 function 6 "Intel 100 Series PCIE" rev 0xf1: msi
pci2 at ppb1 bus 3
rtsx0 at pci2 dev 0 function 0 "Realtek RTS522A Card Reader" rev 0x01: msi
sdmmc0 at rtsx0: 4-bit, dma
ppb2 at pci0 dev 29 function 0 "Intel 100 Series PCIE" rev 0xf1
pci3 at ppb2 bus 4
ppb3 at pci0 dev 29 function 3 "Intel 100 Series PCIE" rev 0xf1: msi
pci4 at ppb3 bus 5
iwm0 at pci4 dev 0 function 0 "Intel Dual Band Wireless AC 8260" rev 0x3a,
msi
pcib0 at pci0 dev 31 function 0 "Intel 100 Series LPC" rev 0x21
"Intel 100 Series PMC" rev 0x21 at pci0 dev 31 function 2 not configured
azalia0 at pci0 dev 31 function 3 "Intel 100 Series HD Audio" rev 0x21: msi
azalia0: codecs: Realtek ALC298, Intel/0x2809, using Realtek ALC298
audio0 at azalia0
ichiic0 at pci0 dev 31 function 4 "Intel 100 Series SMBus" rev 0x21: apic 2
int 16
iic0 at ichiic0
em0 at pci0 dev 31 function 6 "Intel I219-LM" rev 0x21: msi, address
54:e1:ad:af:ec:f6
isa0 at pcib0
isadma0 at isa0
pckbc0 at isa0 port 0x60/5 irq 1 irq 12
pckbd0 at pckbc0 (kbd slot)
wskbd0 at pckbd0: console keyboard
pms0 at pckbc0 (aux slot)
wsmouse0 at pms0 mux 0
wsmouse1 at pms0 mux 0
pms0: Synaptics clickpad, firmware 8.2, 0x1e2b1 0x943300 0x2fed40 0xf00aa3
0x12e800
pcppi0 at isa0 port 0x61
spkr0 at pcppi0
vmm0 at mainbus0: VMX/EPT
efifb at mainbus0 not configured
uhub1 at uhub0 port 3 configuration 1 interface 0 "LENOVO Lenovo ThinkPad
Dock" rev 2.10/50.40 addr 2
uhidev0 at uhub1 port 2 configuration 1 interface 0 "Logitech USB Receiver"
rev 2.00/29.01 addr 3
uhidev0: iclass 3/1
ukbd0 at uhidev0: 8 variable keys, 6 key codes
wskbd1 at ukbd0 mux 1
uhidev1 at uhub1 port 2 configuration 1 interface 1 "Logitech USB Receiver"
rev 2.00/29.01 addr 3
uhidev1: iclass 3/1, 17 report ids
ums0 at uhidev1 reportid 2: 16 buttons, Z and W dir
wsmouse2 at ums0 mux 0
uhid0 at uhidev1 reportid 3: input=4, output=0, feature=0
uhid1 at uhidev1 reportid 4: input=1, output=0, feature=0
uhid2 at uhidev1 reportid 16: input=6, output=6, feature=0
uhid3 at uhidev1 reportid 17: input=19, output=19, feature=0
uhub2 at uhub1 port 4 configuration 1 interface 0 "Lenovo Lenovo ThinkPad
Dock" rev 2.00/0.01 addr 4
uhub2: device problem, disabling port 1
sdmmc0: can't enable card
ugen0 at uhub0 port 6 "Intel Bluetooth" rev 2.00/0.01 addr 5
uhub3 at uhub0 port 15 configuration 1 interface 0 "LENOVO Lenovo ThinkPad
Dock" rev 3.00/50.41 addr 6
vscsi0 at root
scsibus2 at vscsi0: 256 targets
softraid0 at root
scsibus3 at softraid0: 256 targets
root on sd0a (325ce55b43ca38e8.a) swap on sd0b dump on sd0b
inteldrm0: 1366x768, 32bpp
wsdisplay0 at inteldrm0 mux 1: console (std, vt100 emulation), using wskbd0
wskbd1: connecting to wsdisplay0
wsdisplay0: screen 1-5 added (std, vt100 emulation)
iwm0: hw rev 0x200, fw ver 34.0.1, address e4:42:a6:f4:29:19

Re: [update] mail/mu-1.4.1

Hi Miguel.
Not an user of this app so I'm not testing it, I hope someone that can
comes your way.
From afar looks pretty OK, but you should remove REVISION you sure.

Cheers.
Elias.

On Mon, Apr 27, 2020 at 12:15 PM Miguel <miguel@camandro.org> wrote:
>
> Hi!
>
> (warning: first port update attempt!)
>
> Please find below an update of mail/mu from 1.2.0 to 1.4.1.
>
> Nothing big worth mentioning, I believe:
> - Use variable to keep version and used it in DISTNAME and MASTER_SITES
> - Update distinfo
> - Refreshed patch (file renamed lib/{parser/utils.cc=>utils/mu-utils.cc}
> - Update PLIST
>
>
> diff --git a/mail/mu/Makefile b/mail/mu/Makefile
> index 2062eae2a347..59ca744309e8 100644
> --- a/mail/mu/Makefile
> +++ b/mail/mu/Makefile
> @@ -1,8 +1,8 @@
> # $OpenBSD: Makefile,v 1.19 2020/01/24 10:36:41 sthen Exp $
>
> COMMENT= maildir indexer and searcher with emacs frontend
> -
> -DISTNAME= mu-1.2.0
> +V= 1.4.1
> +DISTNAME= mu-${V}
> REVISION= 0
>
> CATEGORIES= mail
> @@ -18,7 +18,7 @@ WANTLIB += gmodule-2.0 gobject-2.0 gpg-error gpgme gthread-2.0
> WANTLIB += iconv idn2 intl json-glib-1.0 m pcre unistring uuid
> WANTLIB += xapian z
>
> -MASTER_SITES= https://github.com/djcb/mu/releases/download/1.2/
> +MASTER_SITES= https://github.com/djcb/mu/releases/download/${V}/
> EXTRACT_SUFX= .tar.xz
>
> BUILD_DEPENDS= emacs->=24:editors/emacs
> diff --git a/mail/mu/distinfo b/mail/mu/distinfo
> index 437fb1dede15..25f89832cfe7 100644
> --- a/mail/mu/distinfo
> +++ b/mail/mu/distinfo
> @@ -1,2 +1,2 @@
> -SHA256 (mu-1.2.0.tar.xz) = 9jTH8kTcaET/cdw8PhiT5I4ZPKqeDnR+umFjCXdfBTo=
> -SIZE (mu-1.2.0.tar.xz) = 844192
> +SHA256 (mu-1.4.1.tar.xz) = 00bbd960821cd7b7ad75246062ad195115dadcdb26bab9beb45167abe35d5dd9
> +SIZE (mu-1.4.1.tar.xz) = 875008
> diff --git a/mail/mu/patches/patch-lib_parser_utils_cc b/mail/mu/patches/patch-lib_parser_utils_cc
> index 58e1438e96fa..cef6a7b57378 100644
> --- a/mail/mu/patches/patch-lib_parser_utils_cc
> +++ b/mail/mu/patches/patch-lib_parser_utils_cc
> @@ -1,8 +1,8 @@
> $OpenBSD: patch-lib_parser_utils_cc,v 1.1 2019/07/26 06:41:59 pvk Exp $
> Bring g_vasprintf into scope
> -Index: lib/parser/utils.cc
> ---- lib/parser/utils.cc.orig
> -+++ lib/parser/utils.cc
> +Index: lib/utils/mu-utils.cc
> +--- lib/utils/mu-utils.cc.orig
> ++++ lib/utils/mu-utils.cc
> @@ -17,7 +17,7 @@
> ** 02110-1301, USA.
> */
> diff --git a/mail/mu/pkg/PLIST b/mail/mu/pkg/PLIST
> index a24708f574d4..9881f84bfd1a 100644
> --- a/mail/mu/pkg/PLIST
> +++ b/mail/mu/pkg/PLIST
> @@ -8,6 +8,8 @@
> @man man/man1/mu-find.1
> @man man/man1/mu-help.1
> @man man/man1/mu-index.1
> +@man man/man1/mu-info.1
> +@man man/man1/mu-init.1
> @man man/man1/mu-mkdir.1
> @man man/man1/mu-remove.1
> @man man/man1/mu-script.1
> @@ -37,6 +39,8 @@ share/emacs/site-lisp/mu4e/mu4e-draft.el
> share/emacs/site-lisp/mu4e/mu4e-draft.elc
> share/emacs/site-lisp/mu4e/mu4e-headers.el
> share/emacs/site-lisp/mu4e/mu4e-headers.elc
> +share/emacs/site-lisp/mu4e/mu4e-icalendar.el
> +share/emacs/site-lisp/mu4e/mu4e-icalendar.elc
> share/emacs/site-lisp/mu4e/mu4e-lists.el
> share/emacs/site-lisp/mu4e/mu4e-lists.elc
> share/emacs/site-lisp/mu4e/mu4e-main.el
> @@ -47,6 +51,8 @@ share/emacs/site-lisp/mu4e/mu4e-message.el
> share/emacs/site-lisp/mu4e/mu4e-message.elc
> share/emacs/site-lisp/mu4e/mu4e-meta.el
> share/emacs/site-lisp/mu4e/mu4e-meta.elc
> +share/emacs/site-lisp/mu4e/mu4e-org.el
> +share/emacs/site-lisp/mu4e/mu4e-org.elc
> share/emacs/site-lisp/mu4e/mu4e-proc.el
> share/emacs/site-lisp/mu4e/mu4e-proc.elc
> share/emacs/site-lisp/mu4e/mu4e-speedbar.el
> @@ -61,5 +67,3 @@ share/emacs/site-lisp/mu4e/mu4e.el
> share/emacs/site-lisp/mu4e/mu4e.elc
> share/emacs/site-lisp/mu4e/org-mu4e.el
> share/emacs/site-lisp/mu4e/org-mu4e.elc
> -share/emacs/site-lisp/mu4e/org-old-mu4e.el
> -share/emacs/site-lisp/mu4e/org-old-mu4e.elc
>

loading DBD-Pg under base httpd, works but it's wrong way

I've had a hell of a time getting Pg.so to load under base httpd.

env LD_DEBUG=1 chroot /var/www script.pl
gives errors about DynaLoader not being able to load due to a missing
library.

After looking at Postgresql libraries loaded using pg_config --libs
I moved just those libs under /var/www.

Still no luck. However I did get barely enough of a hint with searches
to figure out that it wasn't finding libpq.a and libpq.so.6.11
But those are located under /usr/local/lib. I couldn't figure out how to
push over that directory into the search paths.
So I moved a copy of those under /var/www/usr/lib/ vs
/var/www/usr/local/lib/
Works just fine.

I know that this is the wrong solution, but I'm clueless where and how
to add the right search path.
Any clues would be extremely appreciated!

Chris Bennett

Re: RCS file ownership?

Hi all!

Years ago, I mean 10+, I was -- strangely -- quite actively using RCS for local configuration file history management, and fell into the same pit myself.

I made this [1] off the cuff diff then, and reading this thread thought that I need to see how badly it would apply for today's tree.
Well, surprisingly, it succeeded without any rejections, so here it is, maybe someone will find it useful.

It's automatic, so no option to enable this when invoking rcs(1).

Also, all I did was just regenerating the diff, not compiled or tested now... And I'm pretty sure I have had some troubles with it back then...

Anyway, enjoy :)

Dani

[1] https://gist.github.com/levaidaniel/dfc71d782a6e023459c04a3f30ff5a6e

‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
> Date: Thu, 30 Apr 2020 10:37:38 +0100
> From: Craig Skinner Skinner@Britvault.Co.UK
> To: misc@openbsd.org
> Subject: Re: RCS file ownership?
> Message-ID: 20200430103738.1f7304f6@fir.internal
>
> G'day Adam/all,
>
> On Wed, 29 Apr 2020 12:43:42 -0500 Adam Thompson wrote:
>
> > When I use co(1) with "-l" to check out a file (and/or "ci -l") is
> > there any way to preserve file ownership and not have it reset to
> > the user running co(1) or ci(1)?
>
> Attached is a script I've used for years to work around this issue.
>
> No licence, do what you want with it.
>
> Rather rubbish to do this in the shell....
>
> cop = check out, permissions
> cip = check in, permissions
>
> $ ls -ltrhF /usr/local/bin/c* | fgrep ciop
> -r-xr-xr-x 1 root bin 1.8K Jun 29 2013 /usr/local/bin/ciop*
> lrwxr-xr-x 1 root wheel 4B Apr 13 2015 /usr/local/bin/cop@ -> ciop
> lrwxr-xr-x 1 root wheel 4B Apr 13 2015 /usr/local/bin/cip@ -> ciop
>
> Cheers,
>
> ----------
>
> Craig Skinner | http://linkd.in/yGqkv7
>
> [Attachment of type application/octet-stream removed.]

Re: portgen: py: Default to python3 FLAVOR if possible

On Wed, Apr 29, 2020 at 02:13:50AM +0200, Klemens Nanni wrote:
> On Mon, Apr 20, 2020 at 06:38:30PM +0200, Klemens Nanni wrote:
> >
> > New ports should not use Python 3.
> >
> > PyPI projects that already list multiple supported Python versions cause
> > portgen(1) to generate a flavored port, but instead of leaving FLAVOR
> > empty it should opt for the highest available version.
> >
> > This makes it use FLAVOR?=python3 instead of FLAVOR?= (empty) if
> > any support higher than Python 2 is listed.
> >
> > Feedback? OK?
> >
> > Please note that PyPI projects listing either only one support version
> > or none at all at not effected by this diff.
> Ping.

If kmos@ likes it, this is OK afresh1@


> Index: infrastructure/lib/OpenBSD/PortGen/Port/PyPI.pm
> ===================================================================
> RCS file: /cvs/ports/infrastructure/lib/OpenBSD/PortGen/Port/PyPI.pm,v
> retrieving revision 1.18
> diff -u -p -r1.18 PyPI.pm
> --- infrastructure/lib/OpenBSD/PortGen/Port/PyPI.pm 15 Dec 2019 00:18:05 -0000 1.18
> +++ infrastructure/lib/OpenBSD/PortGen/Port/PyPI.pm 29 Apr 2020 00:12:48 -0000
> @@ -118,7 +118,7 @@ sub fill_in_makefile
> shift @versions; # remove default, lowest
> $self->{reset_values}{MODPY_VERSION} = 1;
> $self->set_other( 'FLAVORS', "python$_" ) for @versions;
> - $self->set_other( 'FLAVOR', '' );
> + $self->set_other( 'FLAVOR', "python$versions[-1]" );
> } elsif ( @versions && $versions[0] != 2 ) {
> $self->{reset_values}{$_} = 1 for qw( FLAVORS FLAVOR );
> $self->set_other(
>

--
andrew - http://afresh1.com

Instructions are just another man's opinion of how to do something.
-- Weldboy #DPWisdom

Re: purritobin-0.1.2 - new package + dependencies

Updated to latest 0.1.3 and attached.

On 4/30/20 8:05 AM, Aisha Tammy wrote:
> Hey All,
> I am adding a new package with its 2 dependencies, so a total
> of 3 new packages.
>
> Tested on amd64 and arm64, currently hosted at https://bsd.ac .
> None of the code is platform specific so should be working on all.
>
> comments? OK?
>
> Aisha
>

Re: mail/alpine vs GMail vs TLSv1.3

On Thu, Apr 30 2020, Theo Buehler <tb@theobuehler.org> wrote:
> procter reported to me yesterday that the last time that he could use
> his GMail account with alpine was before the Hobart hackathon, i.e.,
> before the TLSv1.3 client was enabled.
>
> There are two problems:
>
> First, if you establish a TLSv1.3 connection to imap.gmail.com:993
> without SNI, it answers with a self-signed cert containing
>
> subject=/OU=No SNI provided; please fix your client./CN=invalid2.invalid
> issuer=/OU=No SNI provided; please fix your client./CN=invalid2.invalid
>
> Unless you turn off certificate validation in the alpine config, the
> connection will fail. The SNI hunk is taken from alpine 2.22 [1].
>
>
> Second, our TLSv1.3 stack tends to want more retries. alpine already
> retries reads, but doesn't do it for writes. We verified that SSL_write
> returns SSL_ERROR_WANT_WRITE. I did essentially the same thing we did
> (and shortly after undid) for wget.
>
>
> procter verified that the combination of these two fixes allows him to
> use alpine with GMail imap and smtp again.
>
> I'm both surprised and a bit worried that it took so long for somebody
> to report this.
>
> An alternative would be to update to alpine 2.22, but I suspect that the
> SSL_write issue is still present there, so the patch below would seem to
> be the safer option.

Rationale makes sense and changes look good. ok jca@

Regarding the comment, is it only gmail that tells us to retry writes?
(If not, please tweak the comment.)


> [1]: https://repo.or.cz/alpine.git/blob/99948a254e2c2352547b962cbd1c23738e7af6b3:/imap/src/osdep/unix/ssl_unix.c#l446
>
> Index: Makefile
> ===================================================================
> RCS file: /var/cvs/ports/mail/alpine/Makefile,v
> retrieving revision 1.46
> diff -u -p -r1.46 Makefile
> --- Makefile 20 Mar 2020 16:44:24 -0000 1.46
> +++ Makefile 29 Apr 2020 13:29:40 -0000
> @@ -28,7 +28,7 @@ PKGNAME-mailutil= mailutil-uw-${V}
> PKGNAME-pico= pico-${PICO_V}
> PKGNAME-pilot= pilot-${PILOT_V}
>
> -REVISION= 3
> +REVISION= 4
> REVISION-pico= 20
> REVISION-pilot= 20
>
> Index: patches/patch-imap_src_osdep_unix_ssl_unix_c
> ===================================================================
> RCS file: patches/patch-imap_src_osdep_unix_ssl_unix_c
> diff -N patches/patch-imap_src_osdep_unix_ssl_unix_c
> --- /dev/null 1 Jan 1970 00:00:00 -0000
> +++ patches/patch-imap_src_osdep_unix_ssl_unix_c 30 Apr 2020 10:49:20 -0000
> @@ -0,0 +1,57 @@
> +$OpenBSD$
> +
> +Workarounds for GMail:
> +* imap.gmail.com requires SNI for TLSv1.3 clients
> +* retry the writes if we're told to do so.
> +
> +Index: imap/src/osdep/unix/ssl_unix.c
> +--- imap/src/osdep/unix/ssl_unix.c.orig
> ++++ imap/src/osdep/unix/ssl_unix.c
> +@@ -266,6 +266,7 @@ static char *ssl_start_work (SSLSTREAM *stream,char *h
> + {
> + BIO *bio;
> + X509 *cert;
> ++ int ssl_err;
> + unsigned long sl,tl;
> + char *s,*t,*err,tmp[MAILTMPLEN], buf[256];
> + sslcertificatequery_t scq =
> +@@ -313,12 +314,22 @@ static char *ssl_start_work (SSLSTREAM *stream,char *h
> + /* create connection */
> + if (!(stream->con = (SSL *) SSL_new (stream->context)))
> + return "SSL connection failed";
> ++ if (host && !SSL_set_tlsext_host_name(stream->con, host)) {
> ++ return "Server Name Identification (SNI) failed";
> ++ }
> + bio = BIO_new_socket (stream->tcpstream->tcpsi,BIO_NOCLOSE);
> + SSL_set_bio (stream->con,bio,bio);
> + SSL_set_connect_state (stream->con);
> + if (SSL_in_init (stream->con)) SSL_total_renegotiations (stream->con);
> + /* now negotiate SSL */
> +- if (SSL_write (stream->con,"",0) < 0)
> ++ do {
> ++ ssl_err = SSL_write (stream->con,"",0);
> ++ } while ((ssl_err == -1 &&
> ++ SSL_get_error(stream->con, ssl_err) == SSL_ERROR_SYSCALL && errno == EINTR) ||
> ++ (ssl_err < 0 &&
> ++ (SSL_get_error(stream->con, ssl_err) == SSL_ERROR_WANT_READ ||
> ++ SSL_get_error(stream->con, ssl_err) == SSL_ERROR_WANT_WRITE)));
> ++ if (ssl_err < 0)
> + return ssl_last_error ? ssl_last_error : "SSL negotiation failed";
> + /* need to validate host names? */
> + if (!(flags & NET_NOVALIDATECERT) &&
> +@@ -626,7 +637,14 @@ long ssl_sout (SSLSTREAM *stream,char *string,unsigned
> + /* until request satisfied */
> + for (i = 0; size > 0; string += i,size -= i)
> + /* write as much as we can */
> +- if ((i = SSL_write (stream->con,string,(int) min (SSLBUFLEN,size))) < 0) {
> ++ do {
> ++ i = SSL_write (stream->con,string,(int) min (SSLBUFLEN,size));
> ++ } while ((i == -1 &&
> ++ SSL_get_error(stream->con, i) == SSL_ERROR_SYSCALL && errno == EINTR) ||
> ++ (i < 0 &&
> ++ (SSL_get_error(stream->con, i) == SSL_ERROR_WANT_READ ||
> ++ SSL_get_error(stream->con, i) == SSL_ERROR_WANT_WRITE)));
> ++ if (i < 0) {
> + if (tcpdebug) {
> + char tmp[MAILTMPLEN];
> + sprintf (tmp,"SSL data write I/O error %d SSL error %d",
>

--
jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF DDCC 0DFA 74AE 1524 E7EE

Re: devhelp: Remove Python dependency

On Thu, Apr 30, 2020 at 12:34:47PM +0200, Klemens Nanni wrote:
> devhelp ships a single Python script which is a gedit plugin, nothing
> else in devhelp I could see requires Python at runtime.
>
> In fact, the entire lang/python module usage seems unneeded. Both
> Python 3 (through meson) and Python 2 (through another BDEP in the chain)
> are pulled in during the build anyway.
>
> gedit itself has a direct Python 3 as RDEP, so in case someone usese the
> plugin the dependency is always satisfied at runtime as well. I have
> briefly tested the gedit plugin and it spawns devhelp on pressing F2 as
> expected (In fact, gedit also an indirect Python 2 RDEP as well).
>
> devhelp not having a Python RDEP lets me install the "xfce" meta package
> without pulling in Python 2.
>
> Feedback? OK?

OK, thanks.

>
>
> Index: Makefile
> ===================================================================
> RCS file: /cvs/ports/x11/gnome/devhelp/Makefile,v
> retrieving revision 1.122
> diff -u -p -r1.122 Makefile
> --- Makefile 1 Nov 2019 19:39:56 -0000 1.122
> +++ Makefile 30 Apr 2020 10:31:21 -0000
> @@ -7,6 +7,7 @@ COMMENT= API documentation browser for
>
> GNOME_PROJECT= devhelp
> GNOME_VERSION= 3.34.0
> +REVISION= 0
>
> SHARED_LIBS += devhelp-3 1.0 # 4.0
>
> @@ -20,7 +21,6 @@ WANTLIB += pango-1.0 webkit2gtk-4.0
>
> MODULES= devel/dconf \
> devel/meson \
> - lang/python \
> x11/gnome
>
> MODGNOME_LDFLAGS= -L${X11BASE}/lib

--
Antoine

Re: UPDATE: i2pd 2.26.0 -> 2.30.0

Le Thu, 23 Apr 2020 12:22:54 +0200,
satmeir <satmeir@cryptogroup.net> a écrit :
>
> Thank you for bearing with me
>

package built fine and starts, in floodfill mode it works as expected.

Tunnels with matchtunnels = true stopped working though, maybe because
the other end is running 2.26?

Re: devel/leiningen binary package is broken, port works

On 2020/04/30 14:59, Klemens Nanni wrote:
> PREFIX contains DESTDIR, see bsd.port.mk(5) for TRUEPREFIX. The latter
> is what ought to be the path once packaged/installed on your system,
> the former is build environment specific (DESTDIR) and must therefore
> not end up in packages.
>
> Perhaps there is a more clever way to fix this, but diff below fixes
> your problem py patching TRUEPREFIX instead of PREFIX: this way
> /usr/local/bin/lein ends up with
>
> LEIN_JAR=/usr/local/share/leiningen/leiningen-2.9.1-standalone.zip
>
> and works as expected on *every system*.
>
> Thanks for noticing as well as pointing out the issue at once.
>
> Feedback? OK?

ok.

though I would just use ${TRUEPREFIX}/share/java rather than introduce a
new variable, TRUEPREFIX is in default SUBST_VARS.

Re: relayd: Why doesn't "tls keypair" look for the fullchain certificate?

Hello,

Great idea - thanks a bunch!

--Chad

‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Thursday 30. April 2020 kl. 19:07, Anthony J. Bentley <anthony@anjbe.name> wrote:

> Chad Hoolie writes:
>
> > Why does "tls keypair" in relayd.conf look for the regular and not the
> > fullchain certificate?
>
> Certificate filenames are defined by your acme-client.conf.
>
> > Thus, forcing users who want an A+ certificate to spend hours
> > searching the web for this hack?
> > cd /etc/ssl
> > doas mv foobar.com.crt foobar.com.crt.bak
> > doas ln -s foobar.com.fullchain.pem foobar.com.crt
>
> Rather than symlink, just tell acme-client to create certificates with
> the filename relayd expects.
>
> domain example.com {
> domain key "/etc/ssl/private/example.com.key"
> domain full chain certificate "/etc/ssl/example.com.crt"
> sign with letsencrypt
> }

Re: GIMP open file crash in gimp-2.10.18p1 still exists

On 2020/04/29 15:13, Jacqueline Jolicoeur wrote:
> Hi,
>
> I have noticed gimp-2.10.18p1 crashes everytime I try to open a file. Removing all my GIMP cache and config files has not resolved it.
>
> I am aware this was posted earlier. I wanted to report that this bug still exists as of today with the recent snapshots.

We don't have any ideas yet. I haven't been able to reproduce it recently,
the crash is in gtk+2 in possibly something theme-related so maybe try a different
theme or try a different window manager or desktop environment and see if that
makes it go away?

The upstream bug is currently at https://gitlab.gnome.org/GNOME/gdk-pixbuf/-/issues/148

Re: relayd: Why doesn't "tls keypair" look for the fullchain certificate?

Chad Hoolie writes:
> Why does "tls keypair" in relayd.conf look for the regular and not the
> fullchain certificate?

Certificate filenames are defined by your acme-client.conf.

> Thus, forcing users who want an A+ certificate to spend hours
> searching the web for this hack?
>
> cd /etc/ssl
> doas mv foobar.com.crt foobar.com.crt.bak
> doas ln -s foobar.com.fullchain.pem foobar.com.crt

Rather than symlink, just tell acme-client to create certificates with
the filename relayd expects.

domain example.com {
domain key "/etc/ssl/private/example.com.key"
domain full chain certificate "/etc/ssl/example.com.crt"
sign with letsencrypt
}

Re: [macppc] Mark cad/{oce,kicad} BROKEN

OK.

On 2020/04/30 17:26, Charlene Wendling wrote:
> Hi,
>
> In the last macppc bulk, oce takes 53 machine hours and kicad, its
> only consumer, 15.
>
> Some Kicad functions are working, but the main feature, the PCB editor,
> leads to segfaults. I've tried several designs without success, even
> with small boards like the icezum alhambra [0]
>
> I used packages, and since macppc is not a DEBUG_ARCH, i don't
> have any interesting backtrace, building with debug will take 4 days
> here and i'm not even sure to be able to fix it.
>
> As such, i'm asking for marking them BROKEN; this is almost 1 bulk day
> saved.
>
> While here i've moved Kicad's HOMEPAGE to https.
>
> OK?
>
> Charlène.
>
>
> [0] https://github.com/FPGAwars/icezum
>
>
> Index: kicad/Makefile
> ===================================================================
> RCS file: /cvs/ports/cad/kicad/Makefile,v
> retrieving revision 1.40
> diff -u -p -r1.40 Makefile
> --- kicad/Makefile 2 Apr 2020 14:48:26 -0000 1.40
> +++ kicad/Makefile 30 Apr 2020 15:02:06 -0000
> @@ -1,16 +1,18 @@
> # $OpenBSD: Makefile,v 1.40 2020/04/02 14:48:26 tracey Exp $
>
> +BROKEN-powerpc = segfaults when trying to run the PCB editor
> +
> V = 5.1.5
> COMMENT = schematic and PCB editing software
> DISTNAME = kicad-${V}
> EPOCH = 0
> -REVISION = 0
> +REVISION = 1
>
> SHARED_LIBS += kicad_3dsg 0.0 # 2.0
>
> CATEGORIES = cad
>
> -HOMEPAGE = http://www.kicad-pcb.org
> +HOMEPAGE = https://www.kicad-pcb.org
>
> #GPLv3
> PERMIT_PACKAGE = Yes
> Index: oce/Makefile
> ===================================================================
> RCS file: /cvs/ports/cad/oce/Makefile,v
> retrieving revision 1.2
> diff -u -p -r1.2 Makefile
> --- oce/Makefile 7 Nov 2019 13:58:14 -0000 1.2
> +++ oce/Makefile 30 Apr 2020 15:02:06 -0000
> @@ -1,5 +1,7 @@
> # $OpenBSD: Makefile,v 1.2 2019/11/07 13:58:14 sthen Exp $
>
> +BROKEN-powerpc = kicad is broken, this is the only consumer (save bulk time)
> +
> COMMENT = C++ 3d modeling library
> DPB_PROPERTIES = parallel
>
>

Re: mail/alpine vs GMail vs TLSv1.3

On 2020/04/30 16:43, Theo Buehler wrote:
> procter reported to me yesterday that the last time that he could use
> his GMail account with alpine was before the Hobart hackathon, i.e.,
> before the TLSv1.3 client was enabled.
>
> There are two problems:
>
> First, if you establish a TLSv1.3 connection to imap.gmail.com:993
> without SNI, it answers with a self-signed cert containing
>
> subject=/OU=No SNI provided; please fix your client./CN=invalid2.invalid
> issuer=/OU=No SNI provided; please fix your client./CN=invalid2.invalid
>
> Unless you turn off certificate validation in the alpine config, the
> connection will fail. The SNI hunk is taken from alpine 2.22 [1].

Yep we've seen that one with a few ports already :-)

> Second, our TLSv1.3 stack tends to want more retries. alpine already
> retries reads, but doesn't do it for writes. We verified that SSL_write
> returns SSL_ERROR_WANT_WRITE. I did essentially the same thing we did
> (and shortly after undid) for wget.
>
>
> procter verified that the combination of these two fixes allows him to
> use alpine with GMail imap and smtp again.
>
> I'm both surprised and a bit worried that it took so long for somebody
> to report this.

I'm not entirely surprised, console-based mail clients are often run
directly on mail servers which tend to not get updated all that often.

> An alternative would be to update to alpine 2.22, but I suspect that the
> SSL_write issue is still present there, so the patch below would seem to
> be the safer option.
>
> [1]: https://repo.or.cz/alpine.git/blob/99948a254e2c2352547b962cbd1c23738e7af6b3:/imap/src/osdep/unix/ssl_unix.c#l446

OK.

> Index: Makefile
> ===================================================================
> RCS file: /var/cvs/ports/mail/alpine/Makefile,v
> retrieving revision 1.46
> diff -u -p -r1.46 Makefile
> --- Makefile 20 Mar 2020 16:44:24 -0000 1.46
> +++ Makefile 29 Apr 2020 13:29:40 -0000
> @@ -28,7 +28,7 @@ PKGNAME-mailutil= mailutil-uw-${V}
> PKGNAME-pico= pico-${PICO_V}
> PKGNAME-pilot= pilot-${PILOT_V}
>
> -REVISION= 3
> +REVISION= 4
> REVISION-pico= 20
> REVISION-pilot= 20
>
> Index: patches/patch-imap_src_osdep_unix_ssl_unix_c
> ===================================================================
> RCS file: patches/patch-imap_src_osdep_unix_ssl_unix_c
> diff -N patches/patch-imap_src_osdep_unix_ssl_unix_c
> --- /dev/null 1 Jan 1970 00:00:00 -0000
> +++ patches/patch-imap_src_osdep_unix_ssl_unix_c 30 Apr 2020 10:49:20 -0000
> @@ -0,0 +1,57 @@
> +$OpenBSD$
> +
> +Workarounds for GMail:
> +* imap.gmail.com requires SNI for TLSv1.3 clients
> +* retry the writes if we're told to do so.
> +
> +Index: imap/src/osdep/unix/ssl_unix.c
> +--- imap/src/osdep/unix/ssl_unix.c.orig
> ++++ imap/src/osdep/unix/ssl_unix.c
> +@@ -266,6 +266,7 @@ static char *ssl_start_work (SSLSTREAM *stream,char *h
> + {
> + BIO *bio;
> + X509 *cert;
> ++ int ssl_err;
> + unsigned long sl,tl;
> + char *s,*t,*err,tmp[MAILTMPLEN], buf[256];
> + sslcertificatequery_t scq =
> +@@ -313,12 +314,22 @@ static char *ssl_start_work (SSLSTREAM *stream,char *h
> + /* create connection */
> + if (!(stream->con = (SSL *) SSL_new (stream->context)))
> + return "SSL connection failed";
> ++ if (host && !SSL_set_tlsext_host_name(stream->con, host)) {
> ++ return "Server Name Identification (SNI) failed";
> ++ }
> + bio = BIO_new_socket (stream->tcpstream->tcpsi,BIO_NOCLOSE);
> + SSL_set_bio (stream->con,bio,bio);
> + SSL_set_connect_state (stream->con);
> + if (SSL_in_init (stream->con)) SSL_total_renegotiations (stream->con);
> + /* now negotiate SSL */
> +- if (SSL_write (stream->con,"",0) < 0)
> ++ do {
> ++ ssl_err = SSL_write (stream->con,"",0);
> ++ } while ((ssl_err == -1 &&
> ++ SSL_get_error(stream->con, ssl_err) == SSL_ERROR_SYSCALL && errno == EINTR) ||
> ++ (ssl_err < 0 &&
> ++ (SSL_get_error(stream->con, ssl_err) == SSL_ERROR_WANT_READ ||
> ++ SSL_get_error(stream->con, ssl_err) == SSL_ERROR_WANT_WRITE)));
> ++ if (ssl_err < 0)
> + return ssl_last_error ? ssl_last_error : "SSL negotiation failed";
> + /* need to validate host names? */
> + if (!(flags & NET_NOVALIDATECERT) &&
> +@@ -626,7 +637,14 @@ long ssl_sout (SSLSTREAM *stream,char *string,unsigned
> + /* until request satisfied */
> + for (i = 0; size > 0; string += i,size -= i)
> + /* write as much as we can */
> +- if ((i = SSL_write (stream->con,string,(int) min (SSLBUFLEN,size))) < 0) {
> ++ do {
> ++ i = SSL_write (stream->con,string,(int) min (SSLBUFLEN,size));
> ++ } while ((i == -1 &&
> ++ SSL_get_error(stream->con, i) == SSL_ERROR_SYSCALL && errno == EINTR) ||
> ++ (i < 0 &&
> ++ (SSL_get_error(stream->con, i) == SSL_ERROR_WANT_READ ||
> ++ SSL_get_error(stream->con, i) == SSL_ERROR_WANT_WRITE)));
> ++ if (i < 0) {
> + if (tcpdebug) {
> + char tmp[MAILTMPLEN];
> + sprintf (tmp,"SSL data write I/O error %d SSL error %d",
>

[macppc, probably BE_ARCHS] graphics/krita: colors are off, mark BROKEN

Krita's colors are off on macppc [0], and probably other BE_ARCHS, it
even corrupts the KDE widgets that are supposed to be black. It's also,
as expected, very slow during operation, but it's not a decent BROKEN
motive (i think?)

So i'm proposing to mark it BROKEN on powerpc at least; this saves 28
machine hours according to the latest macppc bulk's build.log.

Test on another big endian arch would be appreciated :]

Charlène.


[0] https://bsd.network/web/statuses/104088429309359293


Index: Makefile
===================================================================
RCS file: /cvs/ports/graphics/krita/Makefile,v
retrieving revision 1.39
diff -u -p -u -p -r1.39 Makefile
--- Makefile 27 Mar 2020 04:54:00 -0000 1.39
+++ Makefile 30 Apr 2020 16:36:48 -0000
@@ -1,5 +1,7 @@
# $OpenBSD: Makefile,v 1.39 2020/03/27 04:54:00 rsadowski Exp $

+BROKEN-powerpc = colors are off and as such it is not useable
+
COMMENT = advanced drawing and image manipulation

VERSION = 4.2.9

Re: [macppc] Mark cad/{oce,kicad} BROKEN

On Thu, Apr 30 2020, Charlene Wendling <julianaito@posteo.jp> wrote:
> Hi,
>
> In the last macppc bulk, oce takes 53 machine hours

huh. This is just nuts...

> and kicad, its
> only consumer, 15.
>
> Some Kicad functions are working, but the main feature, the PCB editor,
> leads to segfaults. I've tried several designs without success, even
> with small boards like the icezum alhambra [0]
>
> I used packages, and since macppc is not a DEBUG_ARCH, i don't
> have any interesting backtrace, building with debug will take 4 days
> here and i'm not even sure to be able to fix it.
>
> As such, i'm asking for marking them BROKEN; this is almost 1 bulk day
> saved.
>
> While here i've moved Kicad's HOMEPAGE to https.
>
> OK?

ok

> Charlène.
>
>
> [0] https://github.com/FPGAwars/icezum
>
>
> Index: kicad/Makefile
> ===================================================================
> RCS file: /cvs/ports/cad/kicad/Makefile,v
> retrieving revision 1.40
> diff -u -p -r1.40 Makefile
> --- kicad/Makefile 2 Apr 2020 14:48:26 -0000 1.40
> +++ kicad/Makefile 30 Apr 2020 15:02:06 -0000
> @@ -1,16 +1,18 @@
> # $OpenBSD: Makefile,v 1.40 2020/04/02 14:48:26 tracey Exp $
>
> +BROKEN-powerpc = segfaults when trying to run the PCB editor
> +
> V = 5.1.5
> COMMENT = schematic and PCB editing software
> DISTNAME = kicad-${V}
> EPOCH = 0
> -REVISION = 0
> +REVISION = 1
>
> SHARED_LIBS += kicad_3dsg 0.0 # 2.0
>
> CATEGORIES = cad
>
> -HOMEPAGE = http://www.kicad-pcb.org
> +HOMEPAGE = https://www.kicad-pcb.org
>
> #GPLv3
> PERMIT_PACKAGE = Yes
> Index: oce/Makefile
> ===================================================================
> RCS file: /cvs/ports/cad/oce/Makefile,v
> retrieving revision 1.2
> diff -u -p -r1.2 Makefile
> --- oce/Makefile 7 Nov 2019 13:58:14 -0000 1.2
> +++ oce/Makefile 30 Apr 2020 15:02:06 -0000
> @@ -1,5 +1,7 @@
> # $OpenBSD: Makefile,v 1.2 2019/11/07 13:58:14 sthen Exp $
>
> +BROKEN-powerpc = kicad is broken, this is the only consumer (save bulk time)
> +
> COMMENT = C++ 3d modeling library
> DPB_PROPERTIES = parallel
>
>

--
jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF DDCC 0DFA 74AE 1524 E7EE

Re: How to enable TLS 1.3?

On 2020-04-30 13:55, Chad Hoolie wrote:
> Any idea about relayd though? I don't see any mentioning of 1.3 in man relayd.conf:

I'm not a dev but tls1.3 dropped RSA and I think requires ecdsa key support that
relayd currently lacks.

Although httpd was originally based on relayd. I assume the code is different
here because of relayds more complex tls interception and acceleration abilities.

Pound and nginx may be alternatives, but they likely won't protect the key so
well, if an exploit is found.

[macppc] Mark cad/{oce,kicad} BROKEN

Hi,

In the last macppc bulk, oce takes 53 machine hours and kicad, its
only consumer, 15.

Some Kicad functions are working, but the main feature, the PCB editor,
leads to segfaults. I've tried several designs without success, even
with small boards like the icezum alhambra [0]

I used packages, and since macppc is not a DEBUG_ARCH, i don't
have any interesting backtrace, building with debug will take 4 days
here and i'm not even sure to be able to fix it.

As such, i'm asking for marking them BROKEN; this is almost 1 bulk day
saved.

While here i've moved Kicad's HOMEPAGE to https.

OK?

Charlène.


[0] https://github.com/FPGAwars/icezum


Index: kicad/Makefile
===================================================================
RCS file: /cvs/ports/cad/kicad/Makefile,v
retrieving revision 1.40
diff -u -p -r1.40 Makefile
--- kicad/Makefile 2 Apr 2020 14:48:26 -0000 1.40
+++ kicad/Makefile 30 Apr 2020 15:02:06 -0000
@@ -1,16 +1,18 @@
# $OpenBSD: Makefile,v 1.40 2020/04/02 14:48:26 tracey Exp $

+BROKEN-powerpc = segfaults when trying to run the PCB editor
+
V = 5.1.5
COMMENT = schematic and PCB editing software
DISTNAME = kicad-${V}
EPOCH = 0
-REVISION = 0
+REVISION = 1

SHARED_LIBS += kicad_3dsg 0.0 # 2.0

CATEGORIES = cad

-HOMEPAGE = http://www.kicad-pcb.org
+HOMEPAGE = https://www.kicad-pcb.org

#GPLv3
PERMIT_PACKAGE = Yes
Index: oce/Makefile
===================================================================
RCS file: /cvs/ports/cad/oce/Makefile,v
retrieving revision 1.2
diff -u -p -r1.2 Makefile
--- oce/Makefile 7 Nov 2019 13:58:14 -0000 1.2
+++ oce/Makefile 30 Apr 2020 15:02:06 -0000
@@ -1,5 +1,7 @@
# $OpenBSD: Makefile,v 1.2 2019/11/07 13:58:14 sthen Exp $

+BROKEN-powerpc = kicad is broken, this is the only consumer (save bulk time)
+
COMMENT = C++ 3d modeling library
DPB_PROPERTIES = parallel

Re: The 16 partitions thread

On Thu, Apr 30, 2020 at 07:22:35AM -0500, Ed Ahlsen-Girard wrote:
> Some people read replies in misc and say, "wow, Theo and the OBSD devs
> are obnoxiously harsh.'
>
> I read the 16 partitions thread and think, "I marvel at their patience
> with interlocutors who have not read the relevant source code and give
> no indication that they would understand it if they did."

Yeah, stupid users, right? Who needs them anyways.

Re: RCS file ownership?

Adam Thompson <athompso@athompso.net> wrote:

> AFAICT, GNU RCS (v5.9.4, ca. 2015, examined) creates a temp file,
> unlinks the target file, then renames the temp file. I beleve this
> guarantees(-ish, modulo "special" filesystems including NFS and
> FreeBSD's directory-SUID behaviour) that resulting file ownership =
> euid.

mktemp and rename sound like reasonable.

> The GNU docs mention the repo owner in passing a few times but do not
> have a section describing multi-user operation.

The documentation is irrelevant. It should focus on what the code does,
why it seems to do it, and about whether the resulting behaviour is
convenient.

> I'm not sure which other implementations you'd be worried about

All of them.

> - I thought OpenBSD's RCS was the direct descendant of NetBSD's and
> shares common lineage with the other *BSDs?

The top of each source file claims otherwise. It is a rewrite.

> All in all, it looks like RCS and its docs were written in the era
> when UNIX machines were - more or less by universally - used by
> multiple people, and you just had an innate sense of how multi-user
> file ownership would work. Most of my UNIX machines now resemble
> appliances, and exactly zero of them are multi-user in the classical
> sense.

Documentation is irrelevant.

Re: RCS file ownership?

Being neither a C programmer nor a Texinfo fan, checking GNU RCS is a
bit painful, and my conclusions aren't guaranteed.


AFAICT, GNU RCS (v5.9.4, ca. 2015, examined) creates a temp file,
unlinks the target file, then renames the temp file. I beleve this
guarantees(-ish, modulo "special" filesystems including NFS and
FreeBSD's directory-SUID behaviour) that resulting file ownership =
euid.

The GNU docs mention the repo owner in passing a few times but do not
have a section describing multi-user operation.

The Tichy docs also don't mention file ownership. I'm trying to review
the O'Donovan book, too, but it's been a long time since I had to tool
up to handle raw PS... not quite there yet.

Purdue RCS appears to be the direct ancestor of GNU RCS.

I'm not sure which other implementations you'd be worried about - I
thought OpenBSD's RCS was the direct descendant of NetBSD's and shares
common lineage with the other *BSDs?

All in all, it looks like RCS and its docs were written in the era when
UNIX machines were - more or less by universally - used by multiple
people, and you just had an innate sense of how multi-user file
ownership would work. Most of my UNIX machines now resemble appliances,
and exactly zero of them are multi-user in the classical sense.

-Adam


On 2020-04-29 21:53, Theo de Raadt wrote:
> Sorry, but my mail goes further.
>
> It says it should be correct. For some definition of correct. It
> should either behave somehow for a logical reason, or it should behave
> in the historical fashion. Or once the historical behaviour is looked
> at, if there is an argument that is wrong, then it should be changed
> with logic about "this is an improvement" backing the argument.
>
> I think it is wrong to document how *this* rcs implimentation behaves,
> without comparing it against others.
>
> My guess is 50% that the others don't unlink, but rewrite the file.
>
> And the changes it might require to be compatible are not substantial.
> At most a 20 line diff, to a few programs in the family.
>
> athompso@athompso.net wrote:
>
>> Thank you for that detail!
>>
>> Addressing this one corner case would require substantial changes, I
>> think. Not worth
>> it, in my opinion.
>>
>> I think it would be worthwhile describing the multi-user mode of
>> operation of RCS in
>> the manual, as it's currently completely absent/omitted. Patch coming
>> soon, maybe
>> tomorrow if I can make time.
>>
>> -Adam
>>
>> On Apr. 29, 2020 21:28, Theo de Raadt <deraadt@openbsd.org> wrote:
>>
>> athompso@athompso.net wrote:
>>
>> > Heh, good point. Didn't even occur to me because as it happens, I
>> am
>> > running as root and would like to not change the ownership.-Adam
>> > On Apr. 29, 2020 13:32, Anders Andersson <pipatron@gmail.com>
>> wrote:
>> >
>> > On Wed, Apr 29, 2020 at 7:46 PM Adam Thompson
>> <athompso@athompso.net>
>> > wrote:
>> > >
>> > > When I use co(1) with "-l" to check out a file (and/or "ci -l")
>> is
>> > there
>> > > any way to preserve file ownership and *not* have it reset to
>> the
>> > user
>> > > running co(1) or ci(1)?
>> > > I don't see anything in rcs(1), co(1) or ci(1) that even
>> mentions
>> > the
>> > > fact that the file will wind up owned by the user running the
>> > command.
>> > > Ideas? Pointers to documentation?
>> >
>> > How could it possibly do anything else unless you always run co
>> as
>> > root?
>>
>> Our rcs tools do:
>>
>> 52628 co RET kbind 0
>> 52628 co CALL unlink(0x7f7ffffed1f3)
>> 52628 co NAMI "ls.c"
>> 52628 co RET unlink -1 errno 2 No such file or directory
>> 52628 co CALL open
>> (0x7f7ffffed1f3,0x601<O_WRONLY|O_CREAT|O_TRUNC>,0100444<S_IRUSR\
>> |S_IRGRP|S_IROTH|S_IFREG>)
>> 52628 co NAMI "ls.c"
>> 52628 co RET open 4
>> 52628 co CALL kbind(0x7f7ffffec908,24,0x847da2a816b5d817)
>>
>> Which appears to be this:
>>
>> else {
>> (void)unlink(dst);
>>
>> if ((fd = open(dst, O_WRONLY|O_CREAT|O_TRUNC, mode))
>> == -1)
>> err(1, "%s", dst);
>>
>> I don't know what older or gnu rcs do. I guess whichever way this is
>> done
>> it must balance concerns between atomicity of concurrent reads
>> performed
>> by earlier processes, versus replacement of a potentially active
>> file.
>>
>> If the latter is chosen, it would unlink(), perform the open more
>> carefully, check that it is in the right place with fstat, but then
>> it needs some work for ftruncate (to get rid of extra file contents
>> at the end). If the open() failed, it might try an unlink followed
>> by
>> open()?
>>
>> Other rcs implimentations need to be checked. It is better if they
>> work
>> the same.
>>

mail/alpine vs GMail vs TLSv1.3

procter reported to me yesterday that the last time that he could use
his GMail account with alpine was before the Hobart hackathon, i.e.,
before the TLSv1.3 client was enabled.

There are two problems:

First, if you establish a TLSv1.3 connection to imap.gmail.com:993
without SNI, it answers with a self-signed cert containing

subject=/OU=No SNI provided; please fix your client./CN=invalid2.invalid
issuer=/OU=No SNI provided; please fix your client./CN=invalid2.invalid

Unless you turn off certificate validation in the alpine config, the
connection will fail. The SNI hunk is taken from alpine 2.22 [1].


Second, our TLSv1.3 stack tends to want more retries. alpine already
retries reads, but doesn't do it for writes. We verified that SSL_write
returns SSL_ERROR_WANT_WRITE. I did essentially the same thing we did
(and shortly after undid) for wget.


procter verified that the combination of these two fixes allows him to
use alpine with GMail imap and smtp again.

I'm both surprised and a bit worried that it took so long for somebody
to report this.

An alternative would be to update to alpine 2.22, but I suspect that the
SSL_write issue is still present there, so the patch below would seem to
be the safer option.

[1]: https://repo.or.cz/alpine.git/blob/99948a254e2c2352547b962cbd1c23738e7af6b3:/imap/src/osdep/unix/ssl_unix.c#l446

Index: Makefile
===================================================================
RCS file: /var/cvs/ports/mail/alpine/Makefile,v
retrieving revision 1.46
diff -u -p -r1.46 Makefile
--- Makefile 20 Mar 2020 16:44:24 -0000 1.46
+++ Makefile 29 Apr 2020 13:29:40 -0000
@@ -28,7 +28,7 @@ PKGNAME-mailutil= mailutil-uw-${V}
PKGNAME-pico= pico-${PICO_V}
PKGNAME-pilot= pilot-${PILOT_V}

-REVISION= 3
+REVISION= 4
REVISION-pico= 20
REVISION-pilot= 20

Index: patches/patch-imap_src_osdep_unix_ssl_unix_c
===================================================================
RCS file: patches/patch-imap_src_osdep_unix_ssl_unix_c
diff -N patches/patch-imap_src_osdep_unix_ssl_unix_c
--- /dev/null 1 Jan 1970 00:00:00 -0000
+++ patches/patch-imap_src_osdep_unix_ssl_unix_c 30 Apr 2020 10:49:20 -0000
@@ -0,0 +1,57 @@
+$OpenBSD$
+
+Workarounds for GMail:
+* imap.gmail.com requires SNI for TLSv1.3 clients
+* retry the writes if we're told to do so.
+
+Index: imap/src/osdep/unix/ssl_unix.c
+--- imap/src/osdep/unix/ssl_unix.c.orig
++++ imap/src/osdep/unix/ssl_unix.c
+@@ -266,6 +266,7 @@ static char *ssl_start_work (SSLSTREAM *stream,char *h
+ {
+ BIO *bio;
+ X509 *cert;
++ int ssl_err;
+ unsigned long sl,tl;
+ char *s,*t,*err,tmp[MAILTMPLEN], buf[256];
+ sslcertificatequery_t scq =
+@@ -313,12 +314,22 @@ static char *ssl_start_work (SSLSTREAM *stream,char *h
+ /* create connection */
+ if (!(stream->con = (SSL *) SSL_new (stream->context)))
+ return "SSL connection failed";
++ if (host && !SSL_set_tlsext_host_name(stream->con, host)) {
++ return "Server Name Identification (SNI) failed";
++ }
+ bio = BIO_new_socket (stream->tcpstream->tcpsi,BIO_NOCLOSE);
+ SSL_set_bio (stream->con,bio,bio);
+ SSL_set_connect_state (stream->con);
+ if (SSL_in_init (stream->con)) SSL_total_renegotiations (stream->con);
+ /* now negotiate SSL */
+- if (SSL_write (stream->con,"",0) < 0)
++ do {
++ ssl_err = SSL_write (stream->con,"",0);
++ } while ((ssl_err == -1 &&
++ SSL_get_error(stream->con, ssl_err) == SSL_ERROR_SYSCALL && errno == EINTR) ||
++ (ssl_err < 0 &&
++ (SSL_get_error(stream->con, ssl_err) == SSL_ERROR_WANT_READ ||
++ SSL_get_error(stream->con, ssl_err) == SSL_ERROR_WANT_WRITE)));
++ if (ssl_err < 0)
+ return ssl_last_error ? ssl_last_error : "SSL negotiation failed";
+ /* need to validate host names? */
+ if (!(flags & NET_NOVALIDATECERT) &&
+@@ -626,7 +637,14 @@ long ssl_sout (SSLSTREAM *stream,char *string,unsigned
+ /* until request satisfied */
+ for (i = 0; size > 0; string += i,size -= i)
+ /* write as much as we can */
+- if ((i = SSL_write (stream->con,string,(int) min (SSLBUFLEN,size))) < 0) {
++ do {
++ i = SSL_write (stream->con,string,(int) min (SSLBUFLEN,size));
++ } while ((i == -1 &&
++ SSL_get_error(stream->con, i) == SSL_ERROR_SYSCALL && errno == EINTR) ||
++ (i < 0 &&
++ (SSL_get_error(stream->con, i) == SSL_ERROR_WANT_READ ||
++ SSL_get_error(stream->con, i) == SSL_ERROR_WANT_WRITE)));
++ if (i < 0) {
+ if (tcpdebug) {
+ char tmp[MAILTMPLEN];
+ sprintf (tmp,"SSL data write I/O error %d SSL error %d",

Re: How to enable TLS 1.3?

Thanks a lot for the help Martijn.

Fingers crossed it will appear soon. Our search engine rankings depend on it!

--Chad

‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Thursday, April 30, 2020 4:16 PM, Martijn van Duren <openbsd+misc@list.imperialat.at> wrote:

> If it's not in the manpage it's probably not there.
> I did gave a quick look through the relayd source, but from what I saw
> there's no TLS1.3 support there.
>
> On 4/30/20 3:55 PM, Chad Hoolie wrote:
>
> > Any idea about relayd though? I don't see any mentioning of 1.3 in man relayd.conf:
> > tls
> > no tlsv1.2
> > Disable the TLSv1.2 protocol. The default is to enable
> > TLSv1.2.
> > sslv3 Enable the SSLv3 protocol. The default is no sslv3.
> > tlsv1 Enable all TLSv1 protocols. This is an alias that
> > includes tlsv1.0, tlsv1.1, and tlsv1.2. The default is
> > no tlsv1.
> > tlsv1.0
> > Enable the TLSv1.0 protocol. The default is no tlsv1.0.
> > tlsv1.1
> > Enable the TLSv1.1 protocol. The default is no tlsv1.1.
> > --Chad
> > ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
> > On Thursday, April 30, 2020 3:04 PM, Martijn van Duren openbsd+misc@list.imperialat.at wrote:
> >
> > > On 4/30/20 1:19 PM, Chad Hoolie wrote:
> > >
> > > > Hello,
> > > > I'm using httpd with acme-client and Let's Encrypt (https://www.romanzolotarev.com/openbsd/acme-client.html).
> > > > This setup, however, only seems to support TLS 1.2, whereas TLS 1.3 is needed to achieve A+ ratings across the board.
> > > > Anybody know how to make the upgrade?
> > > > --Chad
> > >
> > > httpd(8):
> > > protocols string Specify the TLS protocols to enable for this server.
> > > If not specified, the value "default" will be used (secure protocols;
> > > TLSv1.2-only). Refer to the tls_config_parse_protocols(3) function for
> > > other valid protocol string values.
> > > tls_config_parse_protocols(3):
> > > Valid keywords are tlsv1.0, tlsv1.1, tlsv1.2, tlsv1.3, all (all
> > > supported protocols),
> > > untested, but seems pretty self-explanatory.