Friday, November 30, 2018

Re: get production/tryton out of attic (aka reimporting it)

On Thu, Nov 29, 2018 at 12:59:59PM +0100, Antoine Jacoutot wrote:
> I think the best move is that I import your work and we will enable it as a
> second step when we are 100% certain everything is good.
> Sounds like a plan?

import the whole stuff and working in tree ? it could be possible. I
would just need to keep a production/tryton/5.0/Makefile clean enough to
ensure only finalized ports are linked in tree.

I will work on having my WIP tree on a clean state (like removing my
tryton/4.8 branch who were here only for testing @option branch stuff)
and I will come back for having formal OK for inclusion.

Thanks.
--
Sebastien Marie

> On Thu, Nov 29, 2018 at 11:22:11AM +0100, Sebastien Marie wrote:
> > Hi,
> >
> > I would like to get productivity/tryton out of Attic, and take the
> > maintainership of it. Disclamer: I am using it.
> >
> > It has been initially removed (on May 8 2017) when I discussed with
> > aja@ about updating the super-old-version we had, and he saw it was not
> > really useful to maintain it (and import several new python ports) if
> > nobody really uses it (at this time I was interested in looking at it
> > only).
> >
> > Mon May 8 17:01:14 2017 UTC
> >
> > Delete tryton; the version we have in ports is not really maintained. I started
> > to work on an diff to update everything to the latest release just to realise
> > that there wasn't a point in doing this it's essentially a matter of
> > ftp+tar xzf. Not worth maintaining 100+ packages.
> >
> > I disagree a bit about the "ftp+tar zxf" part of the comment. If
> > it could apply to some parts of Tryton, I think it doesn't for all
> > compoments.
> >
> >
> > For reimporting it, I would like to take a different approch.
> >
> > First it would be important to have the possibility to have multiple
> > versions in the tree. For now, I would like to import only the
> > latest stable version (5.0), which is LTS (support from 10/2018 to
> > 10/2023). And next, import versions when released (and remove them when
> > not supported any more).
> >
> > It is important as people using Tryton could want to stick on some LTS
> > version as long it is supported whereas some others will want to follow
> > latest stable version ("minor" releases are maintained for 1 year).
> >
> > So it means at anytime we shouldn't have more than 3-4 differentes
> > versions of tryton.
> >
> > I use branch option (to have multiple versions of tryton) and make the
> > versions mutually-exclusive (you couldn't install trytond-5.0 with some
> > modules for 5.1 for example).
> >
> >
> > Next, I plan to reimport in priority:
> > - trytond : the server
> > - tryton : gtk desktop client
> > - sao : web client
> > - proteus : library to access Tryton models like a client
> >
> > it is the important part to have as trytond has to be properly
> > integrated to the system (_trytond user, rc.d scripts, ...)
> >
> > and after that, if people agree, the official tryton modules (~ 130
> > differents modules). Technically, the modules could be installed from
> > outside the port tree. But it could be a good thing to have, at least,
> > some of them in order to make evident the use of some others python
> > modules.
> >
> > For example, we have the following ports in tree because of some tryton
> > modules: devel/py-simpleeval, textproc/py-ofxparse, devel/py-simplesoap
> > (proposed on ports@, but not imported for now). Having the related
> > tryton modules in ports tree too would make more evident the use of
> > these python ports.
> >
> > But as long I have the four main compoments, I could live without
> > the others tryton modules (which could enter in the "ftp+tar xzf"
> > previous description). In fact, for any production use of Tryton, the
> > user will have locally installed tryton modules (eventually home-made)
> > for customization. So the official tryton modules could be manually
> > installed too.
> >
> >
> > I could be noted that since the 5.0 version of Tryton, all compoments of tryton are
> > py3-only. So it simplify a bit the maintenance.
> >
> >
> > I am maintaining a WIP tree at
> > https://bitbucket.org/semarie/tryton-ports/src/ . Not all modules has been
> > included for now, as I am adding them when there are properly tested.
> >
> >
> > The following files are attached:
> > - devel/quirks change to remove the fact that 'tryton' and 'trytond' has
> > been removed.
> >
> > - infrastructure/db/user.list change to ressurect uid 675 (I changed the
> > name from _tryton to _trytond. is it a problem ?)
> >
> > - tarball for productivity/tryton with trytond, tryton, sao, and proteus
> > + 2 modules used for in the 'test' target of proteus
> >
> > I have a somehow long README in trytond (direct reading at
> > https://bitbucket.org/semarie/tryton-ports/src/default/5.0/trytond/pkg/README)
> > to document installation and configuration. I think it is self
> > explaining why I think this part is more than just "ftp+tar xzf".
> >
> > Comments or OK ?
> >
> > Thanks.
> > --
> > Sebastien Marie
>
> > Index: files/Quirks.pm
> > ===================================================================
> > RCS file: /cvs/ports/devel/quirks/files/Quirks.pm,v
> > retrieving revision 1.665
> > diff -u -p -r1.665 Quirks.pm
> > --- files/Quirks.pm 27 Nov 2018 15:24:15 -0000 1.665
> > +++ files/Quirks.pm 29 Nov 2018 08:24:00 -0000
> > @@ -830,8 +830,6 @@ my $obsolete_reason = {
> > 'xgrab' => 9,
> > 'quirc' => 3,
> > 'xspread' => 3,
> > - 'tryton' => 1,
> > - 'trytond' => 1,
> > 'sharity-light' => 6,
> > 'py-axiom' => 5,
> > 'py-epsilon' => 5,
>
> > Index: infrastructure/db/user.list
> > ===================================================================
> > RCS file: /cvs/ports/infrastructure/db/user.list,v
> > retrieving revision 1.330
> > diff -u -p -r1.330 user.list
> > --- infrastructure/db/user.list 29 Nov 2018 00:38:14 -0000 1.330
> > +++ infrastructure/db/user.list 29 Nov 2018 08:22:57 -0000
> > @@ -183,7 +183,7 @@ id user group port options
> > 672 _radicale _radicale productivity/radicale
> > 673 _buildbot _buildbot devel/py-buildbot
> > 674 _buildslave _buildslave devel/py-buildslave
> > -#675 _tryton _tryton productivity/tryton/trytond
> > +675 _trytond _trytond productivity/tryton
> > 676 _gdm _gdm x11/gnome/gdm
> > 677 _scamper _scamper net/scamper
> > 678 _owampd _owampd net/owamp
>

update: textproc/py-ofxparse

Hi,

Here a diff to update textproc/py-ofxparse from 0.19 to 0.20

Tested on amd64 on both py2 and py3.

> Ran 65 tests in 1.851s

The change on PLIST is due to some difference introduced by "make
update-plist" if the pkg/PLIST is absent (at initial import) or if
renewed (on update).

Comments or OK ?

Thanks.
--
Sebastien Marie


Index: Makefile
===================================================================
RCS file: /cvs/ports/textproc/py-ofxparse/Makefile,v
retrieving revision 1.1.1.1
diff -u -p -r1.1.1.1 Makefile
--- Makefile 23 Aug 2018 05:49:01 -0000 1.1.1.1
+++ Makefile 1 Dec 2018 07:38:48 -0000
@@ -2,7 +2,7 @@

COMMENT = parser for the Open Financial Exchange file format

-MODPY_EGG_VERSION = 0.19
+MODPY_EGG_VERSION = 0.20
DISTNAME = ofxparse-${MODPY_EGG_VERSION}
PKGNAME = py-${DISTNAME}

Index: distinfo
===================================================================
RCS file: /cvs/ports/textproc/py-ofxparse/distinfo,v
retrieving revision 1.1.1.1
diff -u -p -r1.1.1.1 distinfo
--- distinfo 23 Aug 2018 05:49:01 -0000 1.1.1.1
+++ distinfo 1 Dec 2018 07:38:53 -0000
@@ -1,2 +1,2 @@
-SHA256 (ofxparse-0.19.tar.gz) = 2Mgf1QiTMhBtoaLokZxBLHxnfwivBNVXynZ3AaBOCRg=
-SIZE (ofxparse-0.19.tar.gz) = 54140
+SHA256 (ofxparse-0.20.tar.gz) = 60XbWAKTisCrNmRBjKVkYZzJ5+xtMBwQY//Bblh+w34=
+SIZE (ofxparse-0.20.tar.gz) = 53178
Index: pkg/PLIST
===================================================================
RCS file: /cvs/ports/textproc/py-ofxparse/pkg/PLIST,v
retrieving revision 1.1.1.1
diff -u -p -r1.1.1.1 PLIST
--- pkg/PLIST 23 Aug 2018 05:49:01 -0000 1.1.1.1
+++ pkg/PLIST 1 Dec 2018 07:39:30 -0000
@@ -9,7 +9,7 @@ lib/python${MODPY_VERSION}/site-packages
lib/python${MODPY_VERSION}/site-packages/ofxparse-${MODPY_EGG_VERSION}-py${MODPY_VERSION}.egg-info/top_level.txt
lib/python${MODPY_VERSION}/site-packages/ofxparse-${MODPY_EGG_VERSION}-py${MODPY_VERSION}.egg-info/zip-safe
lib/python${MODPY_VERSION}/site-packages/ofxparse/__init__.py
-${MODPY_COMMENT}lib/python${MODPY_VERSION}/site-packages/ofxparse/${MODPY_PYCACHE}
+${MODPY_COMMENT}lib/python${MODPY_VERSION}/site-packages/ofxparse/${MODPY_PYCACHE}/
lib/python${MODPY_VERSION}/site-packages/ofxparse/${MODPY_PYCACHE}__init__.${MODPY_PYC_MAGIC_TAG}pyc
lib/python${MODPY_VERSION}/site-packages/ofxparse/${MODPY_PYCACHE}mcc.${MODPY_PYC_MAGIC_TAG}pyc
lib/python${MODPY_VERSION}/site-packages/ofxparse/${MODPY_PYCACHE}ofxparse.${MODPY_PYC_MAGIC_TAG}pyc

Re: openbsd 6.4 as guest VM on Xen cannot detect disk

OpenBSD 6.4 (GENERIC.MP) #364: Thu Oct 11 13:30:23 MDT 2018
deraadt@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 1056964608 (1008MB)
avail mem = 1015713792 (968MB)
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.4 @ 0xeb01f (12 entries)
bios0: vendor Xen version "4.4.4_34-61.32.1" date 08/17/2018
bios0: Xen HVM domU
acpi0 at bios0: rev 2
acpi0: sleep states S5
acpi0: tables DSDT FACP APIC WAET SSDT SSDT
acpi0: wakeup devices
acpitimer0 at acpi0: 3579545 Hz, 32 bits
acpimadt0 at acpi0 addr 0xfee00000: PC-AT compat
ioapic0 at mainbus0: apid 1 pa 0xfec00000, version 11, 48 pins, remapped
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: Intel(R) Xeon(R) CPU E5450 @ 3.00GHz, 2993.06 MHz, 06-17-06
cpu0: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,SSSE3,CX16,SSE4.1,x2APIC,DEADLINE,HV,NXE,LONG,LAHF,MELTDOWN
cpu0: 6MB 64b/line 16-way L2 cache
cpu0: smt 0, core 0, package 0
mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges
cpu0: apic clock running at 100MHz
cpu1 at mainbus0: apid 2 (application processor)
cpu1: Intel(R) Xeon(R) CPU E5450 @ 3.00GHz, 2992.68 MHz, 06-17-06
cpu1: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,SSSE3,CX16,SSE4.1,x2APIC,DEADLINE,HV,NXE,LONG,LAHF,MELTDOWN
cpu1: 6MB 64b/line 16-way L2 cache
cpu1: smt 0, core 2, package 0
acpiprt0 at acpi0: bus 0 (PCI0)
acpicpu0 at acpi0: C1(@1 halt!)
acpicpu1 at acpi0: C1(@1 halt!)
acpicmos0 at acpi0
"ACPI0007" at acpi0 not configured
"ACPI0007" at acpi0 not configured
pvbus0 at mainbus0: Xen 4.4
xen0 at pvbus0: features 0x705, 32 grant table frames, event channel 4
"vfb" at xen0: device/vfb/0 not configured
xbf0 at xen0 backend 0 channel 6: disk
scsibus1 at xbf0: 2 targets
sd0 at scsibus1 targ 0 lun 0: <Xen, phy hda 768, 0000> SCSI3 0/direct fixed
sd0: 4096MB, 512 bytes/sector, 8388608 sectors
xnf0 at xen0 backend 0 channel 7: address 00:16:3e:79:85:28
xnf1 at xen0 backend 0 channel 8: address 00:16:3e:46:21:98
"console" at xen0: device/console/0 not configured
pci0 at mainbus0 bus 0
pchb0 at pci0 dev 0 function 0 "Intel 82441FX" rev 0x02
pcib0 at pci0 dev 1 function 0 "Intel 82371SB ISA" rev 0x00
pciide0 at pci0 dev 1 function 1 "Intel 82371SB IDE" rev 0x00: DMA, channel 0 wired to compatibility, channel 1 wired to compatibility
pciide0: channel 0 disabled (no drives)
pciide0: channel 1 disabled (no drives)
piixpm0 at pci0 dev 1 function 3 "Intel 82371AB Power" rev 0x01: SMBus disabled
vga1 at pci0 dev 2 function 0 "Cirrus Logic CL-GD5446" rev 0x00
wsdisplay0 at vga1 mux 1: console (80x25, vt100 emulation)
wsdisplay0: screen 1-5 added (80x25, vt100 emulation)
xspd0 at pci0 dev 3 function 0 "XenSource Platform Device" rev 0x01
isa0 at pcib0
isadma0 at isa0
fdc0 at isa0 port 0x3f0/6 irq 6 drq 2
com0 at isa0 port 0x3f8/8 irq 4: ns16550a, 16 byte fifo
com0: console
pckbc0 at isa0 port 0x60/5 irq 1 irq 12
pckbd0 at pckbc0 (kbd slot)
wskbd0 at pckbd0: console keyboard, using wsdisplay0
pms0 at pckbc0 (aux slot)
wsmouse0 at pms0 mux 0
pcppi0 at isa0 port 0x61
spkr0 at pcppi0
lpt0 at isa0 port 0x378/4 irq 7
vscsi0 at root
scsibus2 at vscsi0: 256 targets
softraid0 at root
scsibus3 at softraid0: 256 targets
root on sd0a (70bae60fe9b7d0df.a) swap on sd0b dump on sd0b
fd0 at fdc0 drive 0: density unknown
fd1 at fdc0 drive 1: density unknown
I have no idea what is causing your backend timeout, but your VM
config would be useful information, and take a look at xend.log etc.
on the host for any related errors (if you have access to it). I'm
running OpenBSD 6.4 just fine under Xen; however my Dom0 is only 4.4.4
(dmesg attached).

Note that in your 6.0 dmesg, you have "wd0 at pciide0" vs. my "sd0 at
scsibus1" via "scsibus1 at xbf0"; the man page for xbf(4) indicates it
was added in 6.1, and that it takes over all virtual disks. As a
workaround, you might try boot -c and disable xbf, which would
presumably present your disk via the emulated IDE controller.

-Andrew

Re: [OT?] I have 4 IPs. How is outbound IP selected, say run lynx URL on server?

On 11/30/18 8:31 PM, Chris Bennett wrote:
> I'm just curious. Is there a default method to select on this? Random?
> Can I control this somehow?
> It's clear how everything else selects IP, but I just wanted to know in
> case that ever mattered, say one of my IPs were blocked.
> And I wanted to be sure which IP outbound is or is not used for running
> something like lynx, etc.
>
> Not terribly important, but at least interesting question for me.
>
> Thanks,
> Chris Bennett
>
>

If you say 'outbound IP' I am guessing you WAN facing public address.


There are several ways to do this....


The first would be to use a NAT Pool. This would effectively pop all
your public addresses a selectable group:


eg. { 1.1.1.1 , 2.2.2.2 , 3.3.3.3 , 4.4.4.4 }


Depending on the pool configuration ie. if there was any weighting put
on for IP selection or it would simply use a round-robbin type of selection.


https://www.openbsd.org/faq/pf/nat.html


https://www.openbsd.org/faq/pf/example1.html


Another method would be to setup a static route. So in the above example
with NAT pool you could simply say something like:


IP 172.16.40.52 -> 1.1.1.1


So your PF rule would then be something like:


match out on $ext_if from 172.16.40.52 to any nat-to {1.1.1.1}



The weighted option or a load balanced option would have something like
this:


https://www.openbsd.org/faq/pf/pools.html


Regards,


Kaya

Re: [OT?] I have 4 IPs. How is outbound IP selected, say run lynx URL on server?

On Fri, Nov 30, 2018 at 09:51:37PM +0100, Janne Johansson wrote:
> Den fre 30 nov. 2018 kl 21:32 skrev Chris Bennett
> <cpb_misc@bennettconstruction.us>:
> > I'm just curious. Is there a default method to select on this? Random?
> > Can I control this somehow?
> > It's clear how everything else selects IP, but I just wanted to know in
> > case that ever mattered, say one of my IPs were blocked.
> > And I wanted to be sure which IP outbound is or is not used for running
> > something like lynx, etc.
> >
> > Not terribly important, but at least interesting question for me.
>
> Normally, the IP on the interface which the route table says lead to the
> destination get chosen, unless the program deliberately chooses (or
> allows to choose) one of the other IPs you have.

When using the route you can specify which interface address to use (look
for -ifa in route(8)) else the kernel will use the IP address which gets
you to the gateway of that route.

--
:wq Claudio

Re: [OT?] I have 4 IPs. How is outbound IP selected, say run lynx URL on server?

Den fre 30 nov. 2018 kl 21:32 skrev Chris Bennett
<cpb_misc@bennettconstruction.us>:
> I'm just curious. Is there a default method to select on this? Random?
> Can I control this somehow?
> It's clear how everything else selects IP, but I just wanted to know in
> case that ever mattered, say one of my IPs were blocked.
> And I wanted to be sure which IP outbound is or is not used for running
> something like lynx, etc.
>
> Not terribly important, but at least interesting question for me.

Normally, the IP on the interface which the route table says lead to
the destination
get chosen, unless the program deliberately chooses (or allows to choose) one of
the other IPs you have.

--
May the most significant bit of your life be positive.

[OT?] I have 4 IPs. How is outbound IP selected, say run lynx URL on server?

I'm just curious. Is there a default method to select on this? Random?
Can I control this somehow?
It's clear how everything else selects IP, but I just wanted to know in
case that ever mattered, say one of my IPs were blocked.
And I wanted to be sure which IP outbound is or is not used for running
something like lynx, etc.

Not terribly important, but at least interesting question for me.

Thanks,
Chris Bennett

Re: OpenBGPD - Adding Diversity to the Route Server Landscape (ripe.net)

Mike Hammett [openbsd-misc@ics-il.net] wrote:
> Why worry about HTTPS? What's to gain?
>
> Job's Twitter is very promising.
>

Aside from getting exploited by the latest OpenSSL bug (ok, LibreSSL has
done a great job lowering this probability!), the other big benefit is
that crappy providers and Wi-Fi hotspots can't inject notifications and
advertising into HTTPS links, at least not the way things are setup today..

Re: harfbuzz forward dependencies don't match

On Thu, Nov 22, 2018 at 05:40:27PM GMT, Marc Espie wrote:
> On Thu, Nov 22, 2018 at 03:07:00PM +0000, Raf Czlonka wrote:
> > On Thu, Nov 22, 2018 at 02:07:24PM GMT, Antoine Jacoutot wrote:
> > > On Thu, Nov 22, 2018 at 02:03:38PM +0000, Raf Czlonka wrote:
> > >
> > > That's because the foo-bar depends on a specific version of foo, so they are
> > > both updated at the same time (hence "merging").
> > > $ cd /usr/ports/devel/harfbuzz/ && make show=LIB_DEPENDS-icu
> > > STEM-=2.1.1:devel/harfbuzz,-main textproc/icu4c
> > >
> > > You can see that -icu depends on the exact same version as -main.
> > >
> >
> > Right.
> >
> > It simply looked "out of place" amongst the plethora of other packages
> > being upgraded - well, it still does as I've never seen pkg_add
> > displaying this kind of output for any other package... oh well.
>
> You don't have that many things installed, probably. Happens all the time
> on gstreamer plugins, php plugins, texlive, cups, among others... ;)

It feels like I do - it seems to be taking ages ... especially on
machines with spinning disks ;^)

I do have both texlive and cups installed but haven't noticed
anything similar to the aforementioned message. Well, on occasion,
there are that ones coming from install-info :^P

Cheers,

Raf

Re: [NEW] net/p5-POE-Component-Resolver 0.921 (p5-POE* update 2/14)

On Tue, Oct 30, 2018 at 08:26:59PM +0100, Charlene Wendling wrote:

> I'm proposing here POE::Component::Resolver. It will be needed for
> updating net/p5-POE-Component-Client-HTTP.
>
> From DESCR:
>
> POE::Component::Resolver performs Socket::getaddrinfo() calls in
> subprocesses where they're permitted to block as long as necessary.
>
> WWW: https://metacpan.org/release/POE-Component-Resolver
>
> 'make test' runs fine.
>
> Any comment/feedback is welcome!

OK fcambus@ to import.

Re: [NEW] devel/p5-POE-Component-Syndicator 0.06 (p5-POE* update 5/14)

On Wed, Oct 31, 2018 at 02:07:23PM +0100, Charlene Wendling wrote:

> Here is a new port for POE::Component::Syndicator. It will be needed
> for updating net/p5-POE-Component-IRC.
>
> From DESCR:
>
> POE::Component::Syndicator is a base class for POE components which
> need to handle a persistent resource (e.g. a connection to an IRC
> server) for one or more sessions in an extendable way.
>
> WWW: https://metacpan.org/pod/POE::Component::Syndicator
>
> 'make test' passes.
>
> Any comments/feedback ?

OK fcambus@ to import.

Re: Key-based FDE /w UEFI fails

On Thursday 29 November 2018 20:38:23 Stefan Wollny wrote:
> Hi there!
>
> I need help / advice with a fresh install onto a Thinkpad T450s which I
> recently bought on eBay.
>
> The system starts with UEFI enabled and was running fine with a rather
> small SSD without FDE. dmesg from some recent posts may be found.
>
> I followed the steps as given in the FAQ
> (http://www.openbsd.org/faq/faq14.html#softraid) with a new, larger SSD
> and the key disk both initialized with
> 'fdisk -iy -g -b 960 sd0' (and '... sd2' for the key disk).
>
> On both disks I created a 'a'-partion with type RAID as zero'd the first
> blocks.
>
> softraid is activated with 'bioctl -c C -k sd2a -l sd0a softraid0'.
>
> The installation was without noticable deviation to a non-FDE installation.
>
> The layout is identical to an other FDE-secured laptop which starts with
> BIOS:
> sd0a /
> sd0b swap
> sd0d /tmp
> sd0e /var
> sd0f /usr
> sd0g /usr/local
> sd0h /home
> (As this is a 1TB-SSD each partition has lots of capacity...)
>
> Yet after rebooting the first time I get the following:
>
> probing: pc0 mem[352K 204K 3256M 4832M]
> disk: hd0 hd1 sr0*
>
> >> OpenBSD/amd64 BOOTS64 3.40
>
> open(hd0a:/etc/boot.con f): Invalid argument
> boot>
> cannot open hd0a:/etc/random.seed: Invalid argument
> booting hd0a:/bsd: open hd0a:/bsd: Invalid argument
> failed(22). will try /bsd
> boot>
> cannot open hd0a:/etc/random.seed: Invalid argument
> booting hd0a:/bsd: open hd0a:/bsd: Invalid argument
> failed(22). will try /bsd
> Turning timeout off.
> boot>
>
> At this point I am lost. Tried to google for any information that makes
> sense but only found very old posts (from 2011 and older) which didn't
> provide hints on how to proceed.
>
> Anybody with a clue?

The 'sr0*' in the above output shows that the boot loader found the softraid
volume and believes that it is bootable. What should have happened is that the
boot loader identified that the disk you booted from is part of the softraid
volume and switched to sr0 as the boot device - for some reason it did not and
continued to try to boot from hd0 instead.

You should be able to boot by manually specifying:

boot sr0a:/bsd

at the boot> prompt.

If that works we'll have to track down the reason why the automatic switching
of the boot device failed (line 146 of sys/arch/amd64/stand/libsa/dev_i386.c
and the code that leads up to it).

Re: burp (re-)installs /etc/burp/clientconfdir/testclient

On 2018/11/30 08:21, Florian Obser wrote:
> /etc/burp/clientconfdir/testclient contains a well known password
> (it's simmilar to the combination on my luggage).
>
> So on installation I remove that file.
> An upgrade puts it back. That seems... unwise.
>
> The way I understand things anyone who can connect to the burp server
> can request a cert with that password for CN testclient and then force
> a backup run.
>
> Can we maybe not do that?
>
> Thanks,
> Florian
>
> --
> I'm not entirely sure you are real.
>

Fixed that, here's an updated tgz for 2.2 with the same changes applied.

lang/gprolog and i386

Building on i386 -current (no diffs, using ld.bfd) I'm seeing various errors:

gplc -c -C '-O2 -pipe ' fd_values_fd.fd
Fatal Error: if_no_fd.c: FD Solver not linked

gplc -c --fast-math parse.pl
Fatal Error: Segmentation Violation (bad address: 0x18ed2a4)

gplc -c --fast-math parse.pl
gplc -c --fast-math compile.pl
Fatal Error: Segmentation Violation (bad address: 0xebf4a8)
compilation failed

I occasionally get a build to complete but something's unhappy.

Re: Why stacking softraid disciplines is not supported?

On Fri, Nov 30, 2018 at 04:21:51PM +0200, Justus Hämäläinen wrote:
> Would adding a new RAID 1 Crypto discipline be as 'simple' as creating a new
> softraid_raid1_crypto.c and adding the init function to the sr_discipline_init?
>
> Having each mode as a separate discipline has the advantage that the whole
> framework can be pretty simple. At least to my untrained eye softraid seem very
> uncomplicated functionality. Having separate disciplines could lead to duplication,
> but this can be battled by having common set of functions that can be shared.
>
> It seems that I found a project for the Christmas holidays :)
>
> - Justus
>

I did a very small start on RAID1C last year but don't have the diff
handy right now. It was very small anyway, I hadn't gotten anywhere
beyond very basic changes.

My goal back then was to have RAID1C be a proper discipline but implemented
mostly as glue code which calls into functions written for the CRYPTO and
RAID1 disciplines. But such functions could also be copied over to a RAID1C
discipline and modified until things work; and maybe refactored back later.

Let me know when you get started with this. I'd be interested in working on
RAID1C, but not all by myself. I could make use of RAID1C on my storage box.

Re: Intel Celeron SoC support

Hi Chris,

I decided to sell the board and get a different one..
But for others wanting to use this board in the future.

I tried both USB and PS2 Native (no adapter) keyboards. Neither work after
the installer starts.
Bearing in mind none of the SATA ports are detected either..

Cheers, Andy.

On Wed, Nov 21, 2018 at 3:42 AM Chris Cappuccio <chris@nmedia.net> wrote:

> Andrew Lemin [andrew.lemin@gmail.com] wrote:
> > Hi,
> >
> > I am running an ASRock J4105B-ITX board and wanting to run OpenBSD on
> this.
> > https://www.asrock.com/MB/Intel/J4105B-ITX/index.asp#BIOS
> >
> > It boots up, and at the 'boot>' prompt I can use the keyboard find.
> >
> > However after it boots up, the keyboard stops working, and no disks are
> > found by the installer (used auto_install to send test commands).
> > It appears that there is no chipset support, for the Intel Celeron J4105
> > CPU from what I can work out.
> >
> > To test that it was working fine and is just OpebBSD which is not
> working,
> > I installed Linux and have included the dmesg below (from Linux).
> > I cannot run a dmesg from the OpenBSD installer as I cannot use the
> > keyboard etc.
> >
>
> The ASRock J4205-ITX (Apollo Lake) works fine, so does the J3710-ITX
> (Braswell).
>
> I use them both headless, but they work fine when I plug in a USB keyboard.
>
> The J4105-ITX (Gemini Lake) is newer than either.
>
> What kind of keyboard are you using? If it's not USB, plug in a USB
> keyboard.
> Although it may not work at the boot> prompt, it will work once you are
> booted
> up.
>
> For fun, here are dmesg for the older versions of your board. They both
> work
> with USB input devices.
>
> Braswell
> --------
>
> OpenBSD 6.3-current (GENERIC.MP) #21: Fri Jun 29 17:32:47 PDT 2018
> chris@r8.nmedia.net:/usr/src/sys/arch/amd64/compile/GENERIC.MP
> real mem = 8023584768 (7651MB)
> avail mem = 7771283456 (7411MB)
> mpath0 at root
> scsibus0 at mpath0: 256 targets
> mainbus0 at root
> bios0 at mainbus0: SMBIOS rev. 2.8 @ 0xecec0 (18 entries)
> bios0: vendor American Megatrends Inc. version "P1.30" date 03/30/2016
> bios0: ASRock J3710-ITX
> acpi0 at bios0: rev 2
> acpi0: sleep states S0 S3 S4 S5
> acpi0: tables DSDT FACP APIC FPDT FIDT AAFT MCFG HPET SSDT SSDT SSDT UEFI
> LPIT CSRT
> acpi0: wakeup devices UAR1(S4) XHC1(S4) HDEF(S4) PXSX(S4) RP01(S4)
> PXSX(S4) RP02(S4) PXSX(S4) RP03(S4) PXSX(S4) RP04(S4) BRCM(S0) PWRB(S4)
> acpitimer0 at acpi0: 3579545 Hz, 24 bits
> acpimadt0 at acpi0 addr 0xfee00000: PC-AT compat
> cpu0 at mainbus0: apid 0 (boot processor)
> cpu0: Intel(R) Pentium(R) CPU J3710 @ 1.60GHz, 1600.37 MHz
> 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,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,SSE4.2,MOVBE,POPCNT,DEADLINE,AES,RDRAND,NXE,RDTSCP,LONG,LAHF,3DNOWP,PERF,ITSC,SMEP,ERMS,SENSOR,ARAT,MELTDOWN
> cpu0: 1MB 64b/line 16-way L2 cache
> cpu0: smt 0, core 0, package 0
> mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges
> cpu0: apic clock running at 79MHz
> cpu0: mwait min=64, max=64, C-substates=0.2.0.0.0.0.3.3, IBE
> cpu1 at mainbus0: apid 2 (application processor)
> cpu1: Intel(R) Pentium(R) CPU J3710 @ 1.60GHz, 1600.00 MHz
> 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,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,SSE4.2,MOVBE,POPCNT,DEADLINE,AES,RDRAND,NXE,RDTSCP,LONG,LAHF,3DNOWP,PERF,ITSC,SMEP,ERMS,SENSOR,ARAT,MELTDOWN
> cpu1: 1MB 64b/line 16-way L2 cache
> cpu1: smt 0, core 1, package 0
> cpu2 at mainbus0: apid 4 (application processor)
> cpu2: Intel(R) Pentium(R) CPU J3710 @ 1.60GHz, 1600.00 MHz
> 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,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,SSE4.2,MOVBE,POPCNT,DEADLINE,AES,RDRAND,NXE,RDTSCP,LONG,LAHF,3DNOWP,PERF,ITSC,SMEP,ERMS,SENSOR,ARAT,MELTDOWN
> cpu2: 1MB 64b/line 16-way L2 cache
> cpu2: smt 0, core 2, package 0
> cpu3 at mainbus0: apid 6 (application processor)
> cpu3: Intel(R) Pentium(R) CPU J3710 @ 1.60GHz, 1600.00 MHz
> 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,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,SSE4.2,MOVBE,POPCNT,DEADLINE,AES,RDRAND,NXE,RDTSCP,LONG,LAHF,3DNOWP,PERF,ITSC,SMEP,ERMS,SENSOR,ARAT,MELTDOWN
> cpu3: 1MB 64b/line 16-way L2 cache
> cpu3: smt 0, core 3, package 0
> ioapic0 at mainbus0: apid 1 pa 0xfec00000, version 20, 115 pins
> acpimcfg0 at acpi0 addr 0xe0000000, bus 0-255
> acpihpet0 at acpi0: 14318179 Hz
> acpiprt0 at acpi0: bus 0 (PCI0)
> acpiprt1 at acpi0: bus 1 (RP01)
> acpiprt2 at acpi0: bus 2 (RP02)
> acpiprt3 at acpi0: bus 3 (RP03)
> acpiprt4 at acpi0: bus 4 (RP04)
> acpiec0 at acpi0: not present
> acpicpu0 at acpi0: C3(10@1000 mwait.1@0x64), C2(10@500 mwait.1@0x58),
> C1(1000@1 mwait.1), PSS
> acpicpu1 at acpi0: C3(10@1000 mwait.1@0x64), C2(10@500 mwait.1@0x58),
> C1(1000@1 mwait.1), PSS
> acpicpu2 at acpi0: C3(10@1000 mwait.1@0x64), C2(10@500 mwait.1@0x58),
> C1(1000@1 mwait.1), PSS
> acpicpu3 at acpi0: C3(10@1000 mwait.1@0x64), C2(10@500 mwait.1@0x58),
> C1(1000@1 mwait.1), PSS
> acpipwrres0 at acpi0: CLK0, resource for CAMD
> acpipwrres1 at acpi0: CLK0, resource for CAM1
> acpipwrres2 at acpi0: CLK1, resource for CAM2, CAM3
> acpipwrres3 at acpi0: USBC, resource for XHC1
> acpicmos0 at acpi0
> "BCM43241" at acpi0 not configured
> "BCM2E64" at acpi0 not configured
> "BCM4752" at acpi0 not configured
> "SMO91D0" at acpi0 not configured
> "INT33F7" at acpi0 not configured
> "INT33BE" at acpi0 not configured
> "INTCF1C" at acpi0 not configured
> "MSFT0002" at acpi0 not configured
> acpibtn0 at acpi0: PWRB
> acpibtn1 at acpi0: SLPB
> acpivideo0 at acpi0: GFX0
> acpivout0 at acpivideo0: DD1F
> cpu0: Enhanced SpeedStep 1600 MHz: speeds: 1601, 1600, 1520, 1440, 1360,
> 1280, 1200, 1120, 1040, 960, 880, 800, 720, 640, 560, 480 MHz
> pci0 at mainbus0 bus 0
> pchb0 at pci0 dev 0 function 0 "Intel Braswell Host" rev 0x35
> inteldrm0 at pci0 dev 2 function 0 "Intel HD Graphics" rev 0x35
> drm0 at inteldrm0
> inteldrm0: msi
> inteldrm0: 1024x768, 32bpp
> wsdisplay0 at inteldrm0 mux 1: console (std, vt100 emulation)
> wsdisplay0: screen 1-5 added (std, vt100 emulation)
> ahci0 at pci0 dev 19 function 0 "Intel Braswell AHCI" rev 0x35: msi, AHCI
> 1.3.1
> ahci0: port 0: 6.0Gb/s
> ahci0: port 1: 6.0Gb/s
> scsibus1 at ahci0: 32 targets
> sd0 at scsibus1 targ 0 lun 0: <ATA, HFS250G32TND-N1A, 3000> SCSI3 0/direct
> fixed t10.ATA_HFS250G32TND-N1A2A_FS67N121611207N6G_
> sd0: 238475MB, 512 bytes/sector, 488397168 sectors, thin
> sd1 at scsibus1 targ 1 lun 0: <ATA, ST2000DM001-1CH1, CC27> SCSI3 0/direct
> fixed naa.5000c500653bc225
> sd1: 1907729MB, 512 bytes/sector, 3907029168 sectors
> xhci0 at pci0 dev 20 function 0 "Intel Braswell xHCI" rev 0x35: 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
> "Intel Braswell TXE" rev 0x35 at pci0 dev 26 function 0 not configured
> ppb0 at pci0 dev 28 function 0 "Intel Braswell PCIE" rev 0x35: msi
> pci1 at ppb0 bus 1
> ppb1 at pci0 dev 28 function 1 "Intel Braswell PCIE" rev 0x35: msi
> pci2 at ppb1 bus 2
> ppb2 at pci0 dev 28 function 2 "Intel Braswell PCIE" rev 0x35: msi
> pci3 at ppb2 bus 3
> re0 at pci3 dev 0 function 0 "Realtek 8168" rev 0x11: RTL8168G/8111G
> (0x4c00), msi, address 70:85:c2:05:57:e7
> rgephy0 at re0 phy 7: RTL8251 PHY, rev. 0
> ppb3 at pci0 dev 28 function 3 "Intel Braswell PCIE" rev 0x35: msi
> pci4 at ppb3 bus 4
> ahci1 at pci4 dev 0 function 0 "ASMedia ASM1061 AHCI" rev 0x02: msi, AHCI
> 1.2
> scsibus2 at ahci1: 32 targets
> pcib0 at pci0 dev 31 function 0 "Intel Braswell PCU LPC" rev 0x35
> ichiic0 at pci0 dev 31 function 3 "Intel Braswell SMBus" rev 0x35: apic 1
> int 18
> iic0 at ichiic0
> spdmem0 at iic0 addr 0x50: 4GB DDR3 SDRAM PC3-12800 SO-DIMM
> spdmem1 at iic0 addr 0x51: 4GB DDR3 SDRAM PC3-12800 SO-DIMM
> isa0 at pcib0
> isadma0 at isa0
> com0 at isa0 port 0x3f8/8 irq 4: ns16550a, 16 byte fifo
> pckbc0 at isa0 port 0x60/5 irq 1 irq 12
> pckbd0 at pckbc0 (kbd slot)
> wskbd0 at pckbd0: console keyboard, using wsdisplay0
> pcppi0 at isa0 port 0x61
> spkr0 at pcppi0
> wbsio0 at isa0 port 0x2e/2: NCT6776F rev 0x33
> lm1 at wbsio0 port 0x290/8: NCT6776F
> vmm0 at mainbus0: VMX/EPT
> uhub1 at uhub0 port 1 configuration 1 interface 0 "ASMedia AS2107" rev
> 2.10/0.01 addr 2
> uhub2 at uhub0 port 5 configuration 1 interface 0 "Genesys Logic USB2.0
> Hub" rev 2.00/88.31 addr 3
> uhub3 at uhub0 port 8 configuration 1 interface 0 "ASMedia AS2107" rev
> 3.00/0.01 addr 4
> vscsi0 at root
> scsibus3 at vscsi0: 256 targets
> softraid0 at root
> scsibus4 at softraid0: 256 targets
> root on sd0a (9c842068a9b98834.a) swap on sd0b dump on sd0b
>
>
> Apollo Lake
> -----------
>
> OpenBSD 6.4 (GENERIC.MP) #0: Sat Nov 17 22:15:46 CET 2018
> root@syspatch-64-amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/
> GENERIC.MP
> real mem = 8209932288 (7829MB)
> avail mem = 7951843328 (7583MB)
> mpath0 at root
> scsibus0 at mpath0: 256 targets
> mainbus0 at root
> bios0 at mainbus0: SMBIOS rev. 3.0 @ 0xed450 (18 entries)
> bios0: vendor American Megatrends Inc. version "P1.30" date 04/18/2017
> bios0: ASRock J4205-ITX
> acpi0 at bios0: rev 2
> acpi0: sleep states S0 S3 S4 S5
> acpi0: tables DSDT FACP FPDT FIDT MCFG DBG2 DBGP HPET LPIT APIC NPKT PRAM
> WSMT SSDT SSDT AAFT SSDT SSDT SSDT SSDT SSDT UEFI WDAT
> acpi0: wakeup devices SIO1(S3) UAR1(S4) HDAS(S3) XHC_(S4) XDCI(S4)
> BRCM(S0) PXSX(S4) RP01(S4) PXSX(S4) RP02(S4) PXSX(S4) RP03(S4) PXSX(S4)
> RP04(S4) PXSX(S4) RP05(S4) [...]
> acpitimer0 at acpi0: 3579545 Hz, 32 bits
> acpimcfg0 at acpi0
> acpimcfg0: addr 0xe0000000, bus 0-255
> acpihpet0 at acpi0: 19200000 Hz
> acpimadt0 at acpi0 addr 0xfee00000: PC-AT compat
> cpu0 at mainbus0: apid 0 (boot processor)
> cpu0: Intel(R) Pentium(R) CPU J4205 @ 1.50GHz, 1497.01 MHz, 06-5c-09
> 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,EST,TM2,SSSE3,SDBG,CX16,xTPR,PDCM,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,3DNOWP,PERF,ITSC,FSGSBASE,SMEP,ERMS,MPX,RDSEED,SMAP,CLFLUSHOPT,PT,SHA,IBRS,IBPB,STIBP,SENSOR,ARAT,XSAVEOPT,XSAVEC,XGETBV1,XSAVES,MELTDOWN
> cpu0: 1MB 64b/line 16-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 19MHz
> cpu0: mwait min=64, max=64, C-substates=0.2.0.2.4.2.1.1, IBE
> cpu1 at mainbus0: apid 2 (application processor)
> cpu1: Intel(R) Pentium(R) CPU J4205 @ 1.50GHz, 1496.56 MHz, 06-5c-09
> 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,EST,TM2,SSSE3,SDBG,CX16,xTPR,PDCM,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,3DNOWP,PERF,ITSC,FSGSBASE,SMEP,ERMS,MPX,RDSEED,SMAP,CLFLUSHOPT,PT,SHA,IBRS,IBPB,STIBP,SENSOR,ARAT,XSAVEOPT,XSAVEC,XGETBV1,XSAVES,MELTDOWN
> cpu1: 1MB 64b/line 16-way L2 cache
> cpu1: smt 0, core 1, package 0
> cpu2 at mainbus0: apid 4 (application processor)
> cpu2: Intel(R) Pentium(R) CPU J4205 @ 1.50GHz, 1496.56 MHz, 06-5c-09
> 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,EST,TM2,SSSE3,SDBG,CX16,xTPR,PDCM,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,3DNOWP,PERF,ITSC,FSGSBASE,SMEP,ERMS,MPX,RDSEED,SMAP,CLFLUSHOPT,PT,SHA,IBRS,IBPB,STIBP,SENSOR,ARAT,XSAVEOPT,XSAVEC,XGETBV1,XSAVES,MELTDOWN
> cpu2: 1MB 64b/line 16-way L2 cache
> cpu2: smt 0, core 2, package 0
> cpu3 at mainbus0: apid 6 (application processor)
> cpu3: Intel(R) Pentium(R) CPU J4205 @ 1.50GHz, 1496.56 MHz, 06-5c-09
> 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,EST,TM2,SSSE3,SDBG,CX16,xTPR,PDCM,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,3DNOWP,PERF,ITSC,FSGSBASE,SMEP,ERMS,MPX,RDSEED,SMAP,CLFLUSHOPT,PT,SHA,IBRS,IBPB,STIBP,SENSOR,ARAT,XSAVEOPT,XSAVEC,XGETBV1,XSAVES,MELTDOWN
> cpu3: 1MB 64b/line 16-way L2 cache
> cpu3: smt 0, core 3, package 0
> ioapic0 at mainbus0: apid 1 pa 0xfec00000, version 20, 120 pins
> acpiprt0 at acpi0: bus 0 (PCI0)
> acpiprt1 at acpi0: bus 1 (RP03)
> acpiprt2 at acpi0: bus 2 (RP04)
> acpiprt3 at acpi0: bus 3 (RP05)
> acpiprt4 at acpi0: bus 4 (RP06)
> acpiec0 at acpi0: not present
> acpicpu0 at acpi0: C3(10@150 mwait.1@0x60), C2(10@50 mwait.1@0x21),
> C1(1000@1 mwait.1@0x1), PSS
> acpicpu1 at acpi0: C3(10@150 mwait.1@0x60), C2(10@50 mwait.1@0x21),
> C1(1000@1 mwait.1@0x1), PSS
> acpicpu2 at acpi0: C3(10@150 mwait.1@0x60), C2(10@50 mwait.1@0x21),
> C1(1000@1 mwait.1@0x1), PSS
> acpicpu3 at acpi0: C3(10@150 mwait.1@0x60), C2(10@50 mwait.1@0x21),
> C1(1000@1 mwait.1@0x1), PSS
> acpipwrres0 at acpi0: FN00, resource for FAN0
> acpitz0 at acpi0: critical temperature is 100 degC
> acpicmos0 at acpi0
> acpibtn0 at acpi0: PWRB
> "INT3452" at acpi0 not configured
> "INT3452" at acpi0 not configured
> "INT3452" at acpi0 not configured
> "INT3452" at acpi0 not configured
> "INT33A1" at acpi0 not configured
> "PNP0C0B" at acpi0 not configured
> acpivideo0 at acpi0: GFX0
> acpivout0 at acpivideo0: DD1F
> cpu0: Enhanced SpeedStep 1497 MHz: speeds: 1501, 1500, 1400, 1300, 1200,
> 1100, 1000, 900, 800 MHz
> pci0 at mainbus0 bus 0
> pchb0 at pci0 dev 0 function 0 "Intel Apollo Lake Host" rev 0x0b
> inteldrm0 at pci0 dev 2 function 0 vendor "Intel", unknown product 0x5a84
> rev 0x0b
> drm0 at inteldrm0
> inteldrm0: msi
> error: [drm:pid0:i915_firmware_load_error_print] *ERROR* failed to load
> firmware i915/bxt_dmc_ver1.bin (-22)
> error: [drm:pid0:i915_gem_init_hw] *ERROR* Failed to initialize GuC, error
> -8 (ignored)
> inteldrm0: 1024x768, 32bpp
> Unclaimed register detected after writing to register 0x68970
> wsdisplay0 at inteldrm0 mux 1: console (std, vt100 emulation)
> wsdisplay0: screen 1-5 added (std, vt100 emulation)
> "Intel Apollo Lake TXE" rev 0x0b at pci0 dev 15 function 0 not configured
> ahci0 at pci0 dev 18 function 0 "Intel Apollo Lake AHCI" rev 0x0b: msi,
> AHCI 1.3.1
> ahci0: port 0: 6.0Gb/s
> ahci0: port 1: 6.0Gb/s
> scsibus1 at ahci0: 32 targets
> sd0 at scsibus1 targ 0 lun 0: <ATA, INTEL SSDSC2BB24, D201> SCSI3 0/direct
> fixed naa.55cd2e404c522549
> sd0: 228936MB, 512 bytes/sector, 468862128 sectors, thin
> sd1 at scsibus1 targ 1 lun 0: <ATA, INTEL SSDSC2BB24, D201> SCSI3 0/direct
> fixed naa.55cd2e404c521c42
> sd1: 228936MB, 512 bytes/sector, 468862128 sectors, thin
> ppb0 at pci0 dev 19 function 0 "Intel Apollo Lake PCIE" rev 0xfb: msi
> pci1 at ppb0 bus 1
> re0 at pci1 dev 0 function 0 "Realtek 8168" rev 0x11: RTL8168G/8111G
> (0x4c00), msi, address 70:85:c2:43:c0:f8
> rgephy0 at re0 phy 7: RTL8251 PHY, rev. 0
> ppb1 at pci0 dev 19 function 1 "Intel Apollo Lake PCIE" rev 0xfb: msi
> pci2 at ppb1 bus 2
> ppb2 at pci0 dev 19 function 2 "Intel Apollo Lake PCIE" rev 0xfb: msi
> pci3 at ppb2 bus 3
> ahci1 at pci3 dev 0 function 0 "ASMedia ASM1061 AHCI" rev 0x02: msi, AHCI
> 1.2
> ahci1: port 0: 6.0Gb/s
> ahci1: port 1: 6.0Gb/s
> scsibus2 at ahci1: 32 targets
> sd2 at scsibus2 targ 0 lun 0: <ATA, Crucial_CT480M50, MU05> SCSI3 0/direct
> fixed naa.500a07510c263e53
> sd2: 457862MB, 512 bytes/sector, 937703088 sectors, thin
> sd3 at scsibus2 targ 1 lun 0: <ATA, Crucial_CT480M50, MU05> SCSI3 0/direct
> fixed naa.500a07510c263e41
> sd3: 457862MB, 512 bytes/sector, 937703088 sectors, thin
> ppb3 at pci0 dev 19 function 3 vendor "Intel", unknown product 0x5adb rev
> 0xfb: msi
> pci4 at ppb3 bus 4
> xhci0 at pci0 dev 21 function 0 "Intel Apollo Lake xHCI" rev 0x0b: 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
> pcib0 at pci0 dev 31 function 0 "Intel Apollo Lake LPC" rev 0x0b
> ichiic0 at pci0 dev 31 function 1 "Intel Apollo Lake SMBus" rev 0x0b:
> polling
> iic0 at ichiic0
> spdmem0 at iic0 addr 0x50: 4GB DDR3 SDRAM PC3-12800 SO-DIMM
> spdmem1 at iic0 addr 0x52: 4GB DDR3 SDRAM PC3-12800 SO-DIMM
> isa0 at pcib0
> isadma0 at isa0
> com0 at isa0 port 0x3f8/8 irq 4: ns16550a, 16 byte fifo
> pckbc0 at isa0 port 0x60/5 irq 1 irq 12
> pckbd0 at pckbc0 (kbd slot)
> wskbd0 at pckbd0: console keyboard, using wsdisplay0
> pcppi0 at isa0 port 0x61
> spkr0 at pcppi0
> lpt0 at isa0 port 0x378/4 irq 7
> vmm0 at mainbus0: VMX/EPT
> vscsi0 at root
> scsibus3 at vscsi0: 256 targets
> softraid0 at root
> scsibus4 at softraid0: 256 targets
> sd4 at scsibus4 targ 1 lun 0: <OPENBSD, SR RAID 1, 006> SCSI2 0/direct
> fixed
> sd4: 228933MB, 512 bytes/sector, 468856433 sectors
> sd5 at scsibus4 targ 2 lun 0: <OPENBSD, SR RAID 1, 006> SCSI2 0/direct
> fixed
> sd5: 457860MB, 512 bytes/sector, 937697393 sectors
> root on sd4a (dd533a2b98d638c9.a) swap on sd4b dump on sd4b
>

Re: Why stacking softraid disciplines is not supported?

> On 29 Nov 2018, at 15.24, Joel Sing <joel@sing.id.au> wrote:
>
> On Thursday 29 November 2018 12:05:08 Justus Hämäläinen wrote:
>> Hi,
>>
>> I see that stacking softraid disciplines is not supported, but why I
>> wonder? I was thinking about running fulldisk encryption on softraid
>> RAID1.
>>
>> Is it unsupported because it hasn't been tested enough that it doesn't
>> explode? (Can do this myself)
>> Is it just unimportant enough that nobody has worked on this? (I can at
>> least waste my time on this)
>>
>> Or is it just plain stupid idea? If so why it shouldn't be done?
>
> It works and you can do it, but it is not officially supported - as in if it
> breaks you get to either keep both bit... or figure out how to fix it yourself
> (I have done it myself in the past, for example).
>
> There is no technical reason for it not to work, however there are several
> "gotchas" that you need to be aware of, along with several inefficiencies. The
> two main things are that boot and auto-assembly will not work - the boot
> loader will assemble the first softraid volume, but it will not find or assemble
> the stacked volume. Same goes with auto-assembly by the kernel at boot time
> (for a non-boot disk).
>
> The inefficiency comes from the fact that each discipline is attached and
> exposed as a separate sd(4) device, which means that reads/writes effectively
> get performed on one virtual device, before bouncing around and being
> performed on the second virtual device, before bouncing around and being
> performed on the actual underlying physical devices. Ideally this would be
> handled internally so that you handle the (for example) crypto transformation,
> then RAID 1 transformation, then write to the physical devices - this way you
> also only expose one sd(4) device for the volume (which also avoids things
> messing with the intermediate discipline). There are a few ways that this
> could be done - generically, or by implementing specific disciplines that would
> be commonly used (e.g. RAID 1C, RAID 10, RAID 10C, RAID 5C, etc...).
>
> Hope this helps.

Thanks! This helped a lot. In addition I did read the original paper
about softraid and looked around the code.

> generically, or by implementing specific disciplines that would
> be commonly used (e.g. RAID 1C, RAID 10, RAID 10C, RAID 5C, etc...).

Would adding a new RAID 1 Crypto discipline be as 'simple' as creating a new
softraid_raid1_crypto.c and adding the init function to the sr_discipline_init?

Having each mode as a separate discipline has the advantage that the whole
framework can be pretty simple. At least to my untrained eye softraid seem very
uncomplicated functionality. Having separate disciplines could lead to duplication,
but this can be battled by having common set of functions that can be shared.

It seems that I found a project for the Christmas holidays :)

- Justus

Re: snownews doesn't support https

On Fri, Nov 30, 2018 at 12:37:29PM +0100, Solene Rapenne wrote:
> snownews doesn't seem to work when using https url, the program returns an
> error. Adding the http url for the same xml file was producing expected result.
Snownews does not have TLS support. Can't find the old homepage any
longer but they used to recommend using `wget -O- https://url' through
their (filter?) mechanism.

Re: ikev2 and road warriors setup

Hello,

Thank all of you for your time and your help in this matter!
I think that the ISP of A.B.C.0/23 is filtering/blocking some certificates.
I have moved VPN server and clients out of A.B.C.0/23. They can connect pretty fine using CA now. Clients from A.B.C.0/23 still can NOT connect to VPN serv.
Site-to-Site VPN is doing its job.

The road_warriors(Windows) can ping GW88_LAN_machine (192.168.2.1) ONLY if "use default gateway on remote network" is set.
I need to make road_warriors:
- reaching GW88_LAN_machines 192.168.2.254/24
- reaching GW119_LAN_machines 172.16.X.X via GW88 - if it is possible
- force road_warriors to use its own gateway for the rest of traffic - unticked "use default gateway on remote network".

I was playing around with iked.conf and pf.conf but I did not find the way to make it work.
I will be grateful if anyone could help me with that.

My network diagram and configs of GW88:

GW88$ cat /etc/hostname.enc0
inet 10.0.1.254 255.255.255.0

GW88$ cat /etc/iked.conf
#
ikev2 "roadWarrior" passive esp \
from 192.168.2.0/24 to 10.0.1.0/24 \
local 4.5.6.88 peer any \
srcid 4.5.6.88 \
config address 10.0.1.0/24
#
#
remote_gw_GW119 = "1.2.3.119" # fw_GW119
remote_lan_GW119_1 = "172.16.1.0/24"
remote_lan_GW119_2 = "172.16.2.0/24"

local_gw_GW88_2 = "192.168.2.254"
local_lan_GW88_2 = "192.168.2.0/24"

ikev2 active esp from $local_gw_GW88_2 to $remote_gw_GW119 \
from $local_lan_GW88_2 to $remote_lan_GW119_1 peer $remote_gw_GW119 \
psk "pkspass"

ikev2 active esp from $local_gw_GW88_2 to $remote_gw_GW119 \
from $local_lan_GW88_2 to $remote_lan_GW119_2 peer $remote_gw_GW119 \
psk "pskpass"


GW88$ cat /etc/pf.conf
set skip on {lo, enc}

match in all scrub (no-df random-id)
match out all scrub (no-df random-id)

match out on egress from lan:network to any nat-to egress

block log all
pass in on egress proto udp from any to any port {isakmp,ipsec-nat-t}
pass in on egress proto {ah,esp}
pass out on egress
pass on lan

table <bruteforce> persist counters
pass in on egress proto tcp from { 1.2.3.119 A.B.C.0/23 } to port ssh flags S/SA \
set prio (6, 7) keep state \
(max-src-conn 15, max-src-conn-rate 2/10, overload <bruteforce> flush global)

icmp_types = "{ echoreq, unreach }"
pass inet proto icmp all icmp-type $icmp_types



+------------+
|road_warrior|
+---------+10.0.1.0/24 |
| +------------+
|
ikev2
|
|
v

4.5.6.88 1.2.3.119
+---------+ +----------+
| |
| GW88 | <--+site-to-site VPN+------> | GW119 |
+--+------+ +-------+--+
| |
+-----+192.168.1.254/24 |
| |
| 172.16.1.254/24---+
| |
+---+-+192.168.2.254/24 |
| | |
| | +-----------+ |
| +---+192.168.2.1| 172.16.2.254/24---|
| +------------+
|
|----+192.168.3.254/24

Thanks!

On Thu, 8 Nov 2018 14:04:23 +0100
Radek <aleecja@gmail.com> wrote:

> I've been playing around with netcat.
> I noticed that the netcat process on my VPN_server does not show any "X" on stdout for ports 4500 and 1701.
>
> May it be relevant to my VPN issue?
>
> VPN_serv is A.B.C.77/23 (it is not behind NAT):
>
> $ pfctl -s rules
> pass all flags S/SA
>
> $ nc -u -l 500
> XXXX
>
> X.Y.Z.11/29$ nc -vuz A.B.C.77 4500
> A.B.C.69/23$ nc -vuz A.B.C.77 4500
> $ nc -u -l 4500
> NOTHING IS HERE
>
> $ nc -u -l 4499
> XXXX
>
> $ nc -u -l 4501
> XXXX
>
> X.Y.Z.11/29$ nc -vuz A.B.C.77 1701
> A.B.C.69/23$ nc -vuz A.B.C.77 1701
> $ nc -u -l 1701
> NOTHING IS HERE
>
> $ nc -u -l 22
> XXXX
>
> $ nc -u -l 1234
> XXXX
>
> On Wed, 7 Nov 2018 12:17:09 +0100
> Radek <aleecja@gmail.com> wrote:
>
> > Yesterday I tried this scenario:
> >
> > Win7_warrior - 192.168.x.x, NAT, GW: 1.2.3.119
> > VPN_L2TP (Mikrotik) - A.B.C.75/23, not NATed
> > VPN_IKEv2 - A.B.C.77/23, not NATed
> >
> > I connected Win7_warrior to VPN_L2TP and then to VPN_IKEv2. I was having two active VPN conn in one time.
> > Next, I disconnected VPN_L2TP. VPN_IKEv2 was still active and was working fine.
> >
> > When I disconnected VPN_IKEv2 and was trying to connect VPN_IKEv2 omitting VPN_L2TP - I got 809.
> >
> > Removing home_router which is between Win7_warrior and 1.2.3.119 does not change anything.
> >
> > Another thing:
> > I install VPN_IKEv2 OS via PXEboot and get private IP from dhcp server. Then I move to public A.B.C.77/23 editing /etc/hostname, mygate, resolv.conf. Maybe I missed something in network conf that is important for OpenIKED?
> >
> > Any idea?
> >
> >
> > On Tue, 6 Nov 2018 11:21:52 +0100
> > Radek <aleecja@gmail.com> wrote:
> >
> > > Hello Kim,
> > >
> > > > My question was concerning the VPN_server, is the server NATed?
> > > A.B.C.0/23 is not NATed, it is a public pool. VPN_server is not NATed.
> > >
> > > > How is A.B.C.0/23 connected to the 'rest' of the world? Router/Firewall ...
> > > I only have switches in my building.
> > > All routers/firewalls of my network are in another building, I do not know the whole network structure, devices, security policies... but I have never noticed that any ports were blocked.
> > >
> > > I can setup a IKEV2 site-to-site VPN A.B.C.D/23 <--> !A.B.C.0/23 and it works like a charm.
> > > https://community.riocities.com/openike_openbsd.html
> > > But I can not setup a VPN_server for road warriors.
> > >
> > > I have just set up a VPN_L2TP_serv on Mikrotik (A.B.C.75/23). I can connect my Win7_warrior from !A.B.C.0/23 (currently testing on GSM network).
> > > L2TP and IKEV2 use 500, 4500 ports. If L2TP works fine so I conclude that it is not any Router/FW problem.
> > >
> > > On Tue, 6 Nov 2018 07:48:37 +0100
> > > Kim Zeitler <kim.zeitler@konzept-is.de> wrote:
> > >
> > > > Good morning Radek,
> > > >
> > > > I have a suspicion ...
> > > >
> > > > > For (1), (2) and (3) VPN is working just fine with Win7_warrior and puffy_warrior if they are connecting from A.B.C.0/23 (it does not matter if warrior has public IP or it is behind NAT). The rest of the world fails to connect the VPN_server.
> > > > My question was concerning the VPN_server, is the server NATed?
> > > > How is A.B.C.0/23 connected to the 'rest' of the world? Router/Firewall ...
> > > >
> > > > Cheers,
> > > > Kim
> > > >
> > > >
> > >
> > >
> > > --
> > > radek
> >
> >
> > --
> > radek
>
>
> --
> radek


--
radek

Re: boost diff

On 2018/11/30 13:53, Otto Moerbeek wrote:
> No luck on i386 so far. sp;arc64 ios also not going to work, since the
> boost context lib has no sparc64 support at al. In the meantime I'm
> building arm boost, but that takes ages, it;s now building the
> gcc-4.9.4 port needed by some boost dependency...
>
> Can the impact analysis be done on amd64?

It can, but not by me, the only bulk building environment I have is i386.
If there's someone who can do a test bulk build with the diff and run
this under script(1) and send me the output (there will be a lot as we
haven't done a WANTLIB sync for ages) I'll look over it ..

cd /usr/ports/packages/amd64/all
/usr/ports/infrastructure/bin/check-lib-depends -d . -q -x ./*

Re: boost diff

On Sun, Nov 25, 2018 at 08:44:17AM +0100, Otto Moerbeek wrote:

> On Sat, Nov 24, 2018 at 12:24:59PM +0000, Stuart Henderson wrote:
>
> > On 2018/11/24 13:20, Otto Moerbeek wrote:
> > > On Sat, Nov 24, 2018 at 12:01:48PM +0000, Stuart Henderson wrote:
> > >
> > > > On 2018/11/24 09:45, Landry Breuil wrote:
> > > > > On Sat, Nov 24, 2018 at 07:54:36AM +0100, Otto Moerbeek wrote:
> > > > > > On Wed, Nov 21, 2018 at 01:19:27PM +0100, Otto Moerbeek wrote:
> > > > > >
> > > > > > > Hi,
> > > > > > >
> > > > > > > I am playing with boost contexts which is configured out by the current port.
> > > > > > > I am able to make execution_context and fcontext work on amd64. The first
> > > > > > > using a simple test program and the second using a non-trival program.
> > > > > > >
> > > > > > > The only actual change in boost itself is to use a mmap(...
> > > > > > > MMAP_STACK ...) for stack allocation. So I like to enable the
> > > > > > > disabled parts. They are not extensivly tested and some other parts
> > > > > > > might need a patch too (there are several classes creating stacks).
> > > > > > >
> > > > > > > At the moment I just like to know if I am taking the right approach
> > > > > > > port-wise. So, any comments or advise?
> > > > > >
> > > > > > Total silence.... remember I'm a total ports newbie, I really could
> > > > > > use some guidance here. Is this the right approach for a port having
> > > > > > arch specific features and plist?
> > > > >
> > > > > That is the right approach in general, but for a leaf port. Here, lots
> > > > > of other ports depend on boost, and stuff might pick up those new libs
> > > > > on amd64 (or updates/new ports start relying on them), and then the same
> > > > > stuff start breaking in subtle ways on other archs (few ppl cares about).
> > > >
> > > > Yes exactly this... The approach would need to be :
> > > >
> > > > build dependent ports (130-odd, many large/slow)
> > > >
> > > > run "check-lib-depends" on the produced packages, see if the new libraries
> > > > are picked up
> > > >
> > > > if so, add arch-dependent bits to add the relevant libraries to WANTLIB
> > > >
> > > > (and as they're not extensively tested, alert people to the ports which
> > > > have picked this up and request further testing of these)
> > > >
> > > > Additionally we need to watch imports/updates of ports using boost in the
> > > > future to see if they start using these libraries otherwise builds will
> > > > break (it's not so bad if it's amd64-only, but if all the "fast" arches
> > > > gain support, we typically don't discover breakage in this form until
> > > > it's time for release builds when it's too late to fix).
> > > >
> > > > So the question is "is it worth it". Could be - this is a path to running
> > > > some software (pdns-recursor comes to mind) which otherwise won't run on
> > > > OpenBSD because we never got support for the ucontext.h functions ..
> > > >
> > >
> > > pdns-recursor is the cause I'm looking into this. ucontext is not only
> > > deprecated but actually removed by posix, I do not want to go that
> > > road. So boost's fcontext remains and it is working properly on amd64
> > > at least.
> > >
> > > I could maybe go a more conservative approach and only enable boosts's
> > > context lib. That's all I need, and the scope of potential breakage
> > > will be more limited.
> > >
> > > But first next step is building and basic tests on i386 and sparc64.
> >
> > If you get i386 working, once we're done with LLD test builds on
> > i386, I can help with bulk builds and WANTLIB checks there.
> >
>
> Hmm, i386 builds but my trivial test program core dumps in
> jump_fcontext(). It looks like the stack context created by
> make_fcontext() isn't right on OpenBSD (or handled incorrectly by
> jump_fcontext()). Pondering now wether to spend time on this. Both
> functions are written in assemby and I never learnt i386 assembly.
>
> -Otto
>
>

No luck on i386 so far. sp;arc64 ios also not going to work, since the
boost context lib has no sparc64 support at al. In the meantime I'm
building arm boost, but that takes ages, it;s now building the
gcc-4.9.4 port needed by some boost dependency...

Can the impact analysis be done on amd64? It looks like that's going
to be the only arch on which boost context is known to work for at
least a while.

-Otto

Re: update: py-ldap

On 2018/11/30 12:37, Martijn van Duren wrote:
> Here's the promised py-ldap diff. Since version 3.0.0 there's python3[0]
> support, so I've enabled it, since I use it for py3-graphite-web ldap
> login.
>
> martijn@
>
> [0] https://github.com/python-ldap/python-ldap/blob/master/CHANGES

This diff has a few problems which I avoided in my earlier one (bad
@pkgpath markers will cause problems for future updates, and include_dirs
has hardcoded paths rather than variables).

That was stalled due to breaking databases/luma but I've just figured
out how to fix that so I'll commit my version and the fix.

update: py-ldap

Here's the promised py-ldap diff. Since version 3.0.0 there's python3[0]
support, so I've enabled it, since I use it for py3-graphite-web ldap
login.

martijn@

[0] https://github.com/python-ldap/python-ldap/blob/master/CHANGES

Index: Makefile
===================================================================
RCS file: /cvs/ports/databases/py-ldap/Makefile,v
retrieving revision 1.45
diff -u -p -r1.45 Makefile
--- Makefile 23 Jul 2017 09:30:23 -0000 1.45
+++ Makefile 30 Nov 2018 11:36:53 -0000
@@ -3,7 +3,7 @@
COMMENT-main= LDAP client API for Python
COMMENT-examples= example programs for the LDAP client API for Python

-MODPY_EGG_VERSION = 2.4.41
+MODPY_EGG_VERSION = 3.1.0
DISTNAME= python-ldap-${MODPY_EGG_VERSION}
PKGNAME-main= py-ldap-${MODPY_EGG_VERSION}
PKGNAME-examples= py-ldap-examples-${MODPY_EGG_VERSION}
@@ -24,6 +24,16 @@ MODULES= lang/python
MODPY_PI= Yes
MODPY_SETUPTOOLS= Yes

+FLAVORS= python3
+FLAVOR?=
+
+.if ${FLAVOR:Mpython3}
+FULLPKGNAME-main?= ${PKGNAME-main:S/^py-/py3-/}${FLAVOR_EXT:S/-python3//}
+FULLPKGNAME-examples?= ${PKGNAME-examples:S/^py-/py3-/}${FLAVOR_EXT:S/-python3//}
+FULLPKGPATH-main?= databases/py-ldap,-main${MODPY_FLAVOR}
+FULLPKGPATH-examples?= databases/py-ldap,-examples${MODPY_FLAVOR}
+.endif
+
LIB_DEPENDS-main= ${MODPY_LIB_DEPENDS} \
databases/openldap

@@ -40,9 +50,9 @@ pre-configure:
${WRKSRC}/setup.cfg

post-install:
- ${INSTALL_DATA_DIR} ${PREFIX}/share/examples/py-ldap
+ ${INSTALL_DATA_DIR} ${PREFIX}/share/examples/${MODPY_PY_PREFIX}ldap
cd ${WRKSRC}; tar cf - Demo | tar xf - -C \
- ${PREFIX}/share/examples/py-ldap
+ ${PREFIX}/share/examples/${MODPY_PY_PREFIX}ldap
find ${PREFIX} -name '.cvsignore' -exec rm '{}' \+

.include <bsd.port.mk>
Index: distinfo
===================================================================
RCS file: /cvs/ports/databases/py-ldap/distinfo,v
retrieving revision 1.17
diff -u -p -r1.17 distinfo
--- distinfo 23 Jul 2017 09:30:23 -0000 1.17
+++ distinfo 30 Nov 2018 11:36:53 -0000
@@ -1,2 +1,2 @@
-SHA256 (python-ldap-2.4.41.tar.gz) = bUMOzwQPL8cE7jFtM5DLH1QZwZE3Hh4TG671Sg5CzvA=
-SIZE (python-ldap-2.4.41.tar.gz) = 298212
+SHA256 (python-ldap-3.1.0.tar.gz) = QZdeeUBlAsCScyxX7wwsLrMY2R6Odl+B9dSrbB23J8U=
+SIZE (python-ldap-3.1.0.tar.gz) = 366019
Index: patches/patch-setup_cfg
===================================================================
RCS file: patches/patch-setup_cfg
diff -N patches/patch-setup_cfg
--- /dev/null 1 Jan 1970 00:00:00 -0000
+++ patches/patch-setup_cfg 30 Nov 2018 11:36:53 -0000
@@ -0,0 +1,11 @@
+$OpenBSD$
+
+Index: setup.cfg
+--- setup.cfg.orig
++++ setup.cfg
+@@ -1,4 +1,5 @@
+ [_ldap]
++include_dirs = /usr/include /usr/local/include /usr/local/include/sasl
+ defines = HAVE_SASL HAVE_TLS HAVE_LIBLDAP_R
+ extra_compile_args =
+ extra_objects =
Index: pkg/PLIST-examples
===================================================================
RCS file: /cvs/ports/databases/py-ldap/pkg/PLIST-examples,v
retrieving revision 1.10
diff -u -p -r1.10 PLIST-examples
--- pkg/PLIST-examples 13 Nov 2015 08:44:53 -0000 1.10
+++ pkg/PLIST-examples 30 Nov 2018 11:36:53 -0000
@@ -1,5 +1,5 @@
@comment $OpenBSD: PLIST-examples,v 1.10 2015/11/13 08:44:53 ajacoutot Exp $
-@pkgpath databases/py-ldap,-examples[,python2.4][,python2.5][,python2.6][,python2.7]
+@pkgpath databases/${MODPY_PY_PREFIX}ldap,-examples[,python2.4][,python2.5][,python2.6][,python2.7][,python3.6]
share/examples/${MODPY_PY_PREFIX}ldap/
share/examples/${MODPY_PY_PREFIX}ldap/Demo/
share/examples/${MODPY_PY_PREFIX}ldap/Demo/Lib/
@@ -14,6 +14,7 @@ share/examples/${MODPY_PY_PREFIX}ldap/De
share/examples/${MODPY_PY_PREFIX}ldap/Demo/Lib/ldif/ldifcopy.py
share/examples/${MODPY_PY_PREFIX}ldap/Demo/initialize.py
share/examples/${MODPY_PY_PREFIX}ldap/Demo/ldapcontrols.py
+share/examples/${MODPY_PY_PREFIX}ldap/Demo/ldapurl_search.py
share/examples/${MODPY_PY_PREFIX}ldap/Demo/matchedvalues.py
share/examples/${MODPY_PY_PREFIX}ldap/Demo/ms_ad_bind.py
share/examples/${MODPY_PY_PREFIX}ldap/Demo/options.py
@@ -29,6 +30,7 @@ share/examples/${MODPY_PY_PREFIX}ldap/De
share/examples/${MODPY_PY_PREFIX}ldap/Demo/pyasn1/psearch.py
share/examples/${MODPY_PY_PREFIX}ldap/Demo/pyasn1/readentrycontrol.py
share/examples/${MODPY_PY_PREFIX}ldap/Demo/pyasn1/sessiontrack.py
+share/examples/${MODPY_PY_PREFIX}ldap/Demo/pyasn1/sss_highest_number.py
share/examples/${MODPY_PY_PREFIX}ldap/Demo/pyasn1/syncrepl.py
share/examples/${MODPY_PY_PREFIX}ldap/Demo/reconnect.py
share/examples/${MODPY_PY_PREFIX}ldap/Demo/rename.py
Index: pkg/PLIST-main
===================================================================
RCS file: /cvs/ports/databases/py-ldap/pkg/PLIST-main,v
retrieving revision 1.11
diff -u -p -r1.11 PLIST-main
--- pkg/PLIST-main 23 Jul 2017 09:30:23 -0000 1.11
+++ pkg/PLIST-main 30 Nov 2018 11:36:53 -0000
@@ -1,107 +1,126 @@
@comment $OpenBSD: PLIST-main,v 1.11 2017/07/23 09:30:23 ajacoutot Exp $
-@pkgpath databases/py-ldap
-@pkgpath databases/py-ldap,-main[,python2.4][,python2.5][,python2.6][,python2.7]
+@pkgpath databases/${MODPY_PY_PREFIX}ldap
+@pkgpath databases/${MODPY_PY_PREFIX}ldap,-main[,python2.4][,python2.5][,python2.6][,python2.7][,python3.6]
+lib/python${MODPY_VERSION}/site-packages/${MODPY_PYCACHE}ldapurl.${MODPY_PYC_MAGIC_TAG}${MODPY_PYOEXTENSION}
+lib/python${MODPY_VERSION}/site-packages/${MODPY_PYCACHE}ldapurl.${MODPY_PYC_MAGIC_TAG}pyc
+lib/python${MODPY_VERSION}/site-packages/${MODPY_PYCACHE}ldif.${MODPY_PYC_MAGIC_TAG}${MODPY_PYOEXTENSION}
+lib/python${MODPY_VERSION}/site-packages/${MODPY_PYCACHE}ldif.${MODPY_PYC_MAGIC_TAG}pyc
lib/python${MODPY_VERSION}/site-packages/_ldap.so
-lib/python${MODPY_VERSION}/site-packages/dsml.py
-lib/python${MODPY_VERSION}/site-packages/dsml.pyc
-lib/python${MODPY_VERSION}/site-packages/dsml.${MODPY_PYOEXTENSION}
lib/python${MODPY_VERSION}/site-packages/ldap/
lib/python${MODPY_VERSION}/site-packages/ldap/__init__.py
-lib/python${MODPY_VERSION}/site-packages/ldap/__init__.pyc
-lib/python${MODPY_VERSION}/site-packages/ldap/__init__.${MODPY_PYOEXTENSION}
+${MODPY_COMMENT}lib/python${MODPY_VERSION}/site-packages/ldap/${MODPY_PYCACHE}/
+lib/python${MODPY_VERSION}/site-packages/ldap/${MODPY_PYCACHE}__init__.${MODPY_PYC_MAGIC_TAG}${MODPY_PYOEXTENSION}
+lib/python${MODPY_VERSION}/site-packages/ldap/${MODPY_PYCACHE}__init__.${MODPY_PYC_MAGIC_TAG}pyc
+lib/python${MODPY_VERSION}/site-packages/ldap/${MODPY_PYCACHE}async.${MODPY_PYC_MAGIC_TAG}${MODPY_PYOEXTENSION}
+lib/python${MODPY_VERSION}/site-packages/ldap/${MODPY_PYCACHE}async.${MODPY_PYC_MAGIC_TAG}pyc
+lib/python${MODPY_VERSION}/site-packages/ldap/${MODPY_PYCACHE}asyncsearch.${MODPY_PYC_MAGIC_TAG}${MODPY_PYOEXTENSION}
+lib/python${MODPY_VERSION}/site-packages/ldap/${MODPY_PYCACHE}asyncsearch.${MODPY_PYC_MAGIC_TAG}pyc
+lib/python${MODPY_VERSION}/site-packages/ldap/${MODPY_PYCACHE}cidict.${MODPY_PYC_MAGIC_TAG}${MODPY_PYOEXTENSION}
+lib/python${MODPY_VERSION}/site-packages/ldap/${MODPY_PYCACHE}cidict.${MODPY_PYC_MAGIC_TAG}pyc
+lib/python${MODPY_VERSION}/site-packages/ldap/${MODPY_PYCACHE}compat.${MODPY_PYC_MAGIC_TAG}${MODPY_PYOEXTENSION}
+lib/python${MODPY_VERSION}/site-packages/ldap/${MODPY_PYCACHE}compat.${MODPY_PYC_MAGIC_TAG}pyc
+lib/python${MODPY_VERSION}/site-packages/ldap/${MODPY_PYCACHE}constants.${MODPY_PYC_MAGIC_TAG}${MODPY_PYOEXTENSION}
+lib/python${MODPY_VERSION}/site-packages/ldap/${MODPY_PYCACHE}constants.${MODPY_PYC_MAGIC_TAG}pyc
+lib/python${MODPY_VERSION}/site-packages/ldap/${MODPY_PYCACHE}dn.${MODPY_PYC_MAGIC_TAG}${MODPY_PYOEXTENSION}
+lib/python${MODPY_VERSION}/site-packages/ldap/${MODPY_PYCACHE}dn.${MODPY_PYC_MAGIC_TAG}pyc
+lib/python${MODPY_VERSION}/site-packages/ldap/${MODPY_PYCACHE}filter.${MODPY_PYC_MAGIC_TAG}${MODPY_PYOEXTENSION}
+lib/python${MODPY_VERSION}/site-packages/ldap/${MODPY_PYCACHE}filter.${MODPY_PYC_MAGIC_TAG}pyc
+lib/python${MODPY_VERSION}/site-packages/ldap/${MODPY_PYCACHE}functions.${MODPY_PYC_MAGIC_TAG}${MODPY_PYOEXTENSION}
+lib/python${MODPY_VERSION}/site-packages/ldap/${MODPY_PYCACHE}functions.${MODPY_PYC_MAGIC_TAG}pyc
+lib/python${MODPY_VERSION}/site-packages/ldap/${MODPY_PYCACHE}ldapobject.${MODPY_PYC_MAGIC_TAG}${MODPY_PYOEXTENSION}
+lib/python${MODPY_VERSION}/site-packages/ldap/${MODPY_PYCACHE}ldapobject.${MODPY_PYC_MAGIC_TAG}pyc
+lib/python${MODPY_VERSION}/site-packages/ldap/${MODPY_PYCACHE}logger.${MODPY_PYC_MAGIC_TAG}${MODPY_PYOEXTENSION}
+lib/python${MODPY_VERSION}/site-packages/ldap/${MODPY_PYCACHE}logger.${MODPY_PYC_MAGIC_TAG}pyc
+lib/python${MODPY_VERSION}/site-packages/ldap/${MODPY_PYCACHE}modlist.${MODPY_PYC_MAGIC_TAG}${MODPY_PYOEXTENSION}
+lib/python${MODPY_VERSION}/site-packages/ldap/${MODPY_PYCACHE}modlist.${MODPY_PYC_MAGIC_TAG}pyc
+lib/python${MODPY_VERSION}/site-packages/ldap/${MODPY_PYCACHE}pkginfo.${MODPY_PYC_MAGIC_TAG}${MODPY_PYOEXTENSION}
+lib/python${MODPY_VERSION}/site-packages/ldap/${MODPY_PYCACHE}pkginfo.${MODPY_PYC_MAGIC_TAG}pyc
+lib/python${MODPY_VERSION}/site-packages/ldap/${MODPY_PYCACHE}resiter.${MODPY_PYC_MAGIC_TAG}${MODPY_PYOEXTENSION}
+lib/python${MODPY_VERSION}/site-packages/ldap/${MODPY_PYCACHE}resiter.${MODPY_PYC_MAGIC_TAG}pyc
+lib/python${MODPY_VERSION}/site-packages/ldap/${MODPY_PYCACHE}sasl.${MODPY_PYC_MAGIC_TAG}${MODPY_PYOEXTENSION}
+lib/python${MODPY_VERSION}/site-packages/ldap/${MODPY_PYCACHE}sasl.${MODPY_PYC_MAGIC_TAG}pyc
+lib/python${MODPY_VERSION}/site-packages/ldap/${MODPY_PYCACHE}syncrepl.${MODPY_PYC_MAGIC_TAG}${MODPY_PYOEXTENSION}
+lib/python${MODPY_VERSION}/site-packages/ldap/${MODPY_PYCACHE}syncrepl.${MODPY_PYC_MAGIC_TAG}pyc
lib/python${MODPY_VERSION}/site-packages/ldap/async.py
-lib/python${MODPY_VERSION}/site-packages/ldap/async.pyc
-lib/python${MODPY_VERSION}/site-packages/ldap/async.${MODPY_PYOEXTENSION}
+lib/python${MODPY_VERSION}/site-packages/ldap/asyncsearch.py
lib/python${MODPY_VERSION}/site-packages/ldap/cidict.py
-lib/python${MODPY_VERSION}/site-packages/ldap/cidict.pyc
-lib/python${MODPY_VERSION}/site-packages/ldap/cidict.${MODPY_PYOEXTENSION}
+lib/python${MODPY_VERSION}/site-packages/ldap/compat.py
+lib/python${MODPY_VERSION}/site-packages/ldap/constants.py
lib/python${MODPY_VERSION}/site-packages/ldap/controls/
lib/python${MODPY_VERSION}/site-packages/ldap/controls/__init__.py
-lib/python${MODPY_VERSION}/site-packages/ldap/controls/__init__.pyc
-lib/python${MODPY_VERSION}/site-packages/ldap/controls/__init__.${MODPY_PYOEXTENSION}
+${MODPY_COMMENT}lib/python${MODPY_VERSION}/site-packages/ldap/controls/${MODPY_PYCACHE}/
+lib/python${MODPY_VERSION}/site-packages/ldap/controls/${MODPY_PYCACHE}__init__.${MODPY_PYC_MAGIC_TAG}${MODPY_PYOEXTENSION}
+lib/python${MODPY_VERSION}/site-packages/ldap/controls/${MODPY_PYCACHE}__init__.${MODPY_PYC_MAGIC_TAG}pyc
+lib/python${MODPY_VERSION}/site-packages/ldap/controls/${MODPY_PYCACHE}deref.${MODPY_PYC_MAGIC_TAG}${MODPY_PYOEXTENSION}
+lib/python${MODPY_VERSION}/site-packages/ldap/controls/${MODPY_PYCACHE}deref.${MODPY_PYC_MAGIC_TAG}pyc
+lib/python${MODPY_VERSION}/site-packages/ldap/controls/${MODPY_PYCACHE}libldap.${MODPY_PYC_MAGIC_TAG}${MODPY_PYOEXTENSION}
+lib/python${MODPY_VERSION}/site-packages/ldap/controls/${MODPY_PYCACHE}libldap.${MODPY_PYC_MAGIC_TAG}pyc
+lib/python${MODPY_VERSION}/site-packages/ldap/controls/${MODPY_PYCACHE}openldap.${MODPY_PYC_MAGIC_TAG}${MODPY_PYOEXTENSION}
+lib/python${MODPY_VERSION}/site-packages/ldap/controls/${MODPY_PYCACHE}openldap.${MODPY_PYC_MAGIC_TAG}pyc
+lib/python${MODPY_VERSION}/site-packages/ldap/controls/${MODPY_PYCACHE}pagedresults.${MODPY_PYC_MAGIC_TAG}${MODPY_PYOEXTENSION}
+lib/python${MODPY_VERSION}/site-packages/ldap/controls/${MODPY_PYCACHE}pagedresults.${MODPY_PYC_MAGIC_TAG}pyc
+lib/python${MODPY_VERSION}/site-packages/ldap/controls/${MODPY_PYCACHE}ppolicy.${MODPY_PYC_MAGIC_TAG}${MODPY_PYOEXTENSION}
+lib/python${MODPY_VERSION}/site-packages/ldap/controls/${MODPY_PYCACHE}ppolicy.${MODPY_PYC_MAGIC_TAG}pyc
+lib/python${MODPY_VERSION}/site-packages/ldap/controls/${MODPY_PYCACHE}psearch.${MODPY_PYC_MAGIC_TAG}${MODPY_PYOEXTENSION}
+lib/python${MODPY_VERSION}/site-packages/ldap/controls/${MODPY_PYCACHE}psearch.${MODPY_PYC_MAGIC_TAG}pyc
+lib/python${MODPY_VERSION}/site-packages/ldap/controls/${MODPY_PYCACHE}pwdpolicy.${MODPY_PYC_MAGIC_TAG}${MODPY_PYOEXTENSION}
+lib/python${MODPY_VERSION}/site-packages/ldap/controls/${MODPY_PYCACHE}pwdpolicy.${MODPY_PYC_MAGIC_TAG}pyc
+lib/python${MODPY_VERSION}/site-packages/ldap/controls/${MODPY_PYCACHE}readentry.${MODPY_PYC_MAGIC_TAG}${MODPY_PYOEXTENSION}
+lib/python${MODPY_VERSION}/site-packages/ldap/controls/${MODPY_PYCACHE}readentry.${MODPY_PYC_MAGIC_TAG}pyc
+lib/python${MODPY_VERSION}/site-packages/ldap/controls/${MODPY_PYCACHE}sessiontrack.${MODPY_PYC_MAGIC_TAG}${MODPY_PYOEXTENSION}
+lib/python${MODPY_VERSION}/site-packages/ldap/controls/${MODPY_PYCACHE}sessiontrack.${MODPY_PYC_MAGIC_TAG}pyc
+lib/python${MODPY_VERSION}/site-packages/ldap/controls/${MODPY_PYCACHE}simple.${MODPY_PYC_MAGIC_TAG}${MODPY_PYOEXTENSION}
+lib/python${MODPY_VERSION}/site-packages/ldap/controls/${MODPY_PYCACHE}simple.${MODPY_PYC_MAGIC_TAG}pyc
+lib/python${MODPY_VERSION}/site-packages/ldap/controls/${MODPY_PYCACHE}sss.${MODPY_PYC_MAGIC_TAG}${MODPY_PYOEXTENSION}
+lib/python${MODPY_VERSION}/site-packages/ldap/controls/${MODPY_PYCACHE}sss.${MODPY_PYC_MAGIC_TAG}pyc
+lib/python${MODPY_VERSION}/site-packages/ldap/controls/${MODPY_PYCACHE}vlv.${MODPY_PYC_MAGIC_TAG}${MODPY_PYOEXTENSION}
+lib/python${MODPY_VERSION}/site-packages/ldap/controls/${MODPY_PYCACHE}vlv.${MODPY_PYC_MAGIC_TAG}pyc
lib/python${MODPY_VERSION}/site-packages/ldap/controls/deref.py
-lib/python${MODPY_VERSION}/site-packages/ldap/controls/deref.pyc
-lib/python${MODPY_VERSION}/site-packages/ldap/controls/deref.${MODPY_PYOEXTENSION}
lib/python${MODPY_VERSION}/site-packages/ldap/controls/libldap.py
-lib/python${MODPY_VERSION}/site-packages/ldap/controls/libldap.pyc
-lib/python${MODPY_VERSION}/site-packages/ldap/controls/libldap.${MODPY_PYOEXTENSION}
lib/python${MODPY_VERSION}/site-packages/ldap/controls/openldap.py
-lib/python${MODPY_VERSION}/site-packages/ldap/controls/openldap.pyc
-lib/python${MODPY_VERSION}/site-packages/ldap/controls/openldap.${MODPY_PYOEXTENSION}
+lib/python${MODPY_VERSION}/site-packages/ldap/controls/pagedresults.py
lib/python${MODPY_VERSION}/site-packages/ldap/controls/ppolicy.py
-lib/python${MODPY_VERSION}/site-packages/ldap/controls/ppolicy.pyc
-lib/python${MODPY_VERSION}/site-packages/ldap/controls/ppolicy.${MODPY_PYOEXTENSION}
lib/python${MODPY_VERSION}/site-packages/ldap/controls/psearch.py
-lib/python${MODPY_VERSION}/site-packages/ldap/controls/psearch.pyc
-lib/python${MODPY_VERSION}/site-packages/ldap/controls/psearch.${MODPY_PYOEXTENSION}
lib/python${MODPY_VERSION}/site-packages/ldap/controls/pwdpolicy.py
-lib/python${MODPY_VERSION}/site-packages/ldap/controls/pwdpolicy.pyc
-lib/python${MODPY_VERSION}/site-packages/ldap/controls/pwdpolicy.${MODPY_PYOEXTENSION}
lib/python${MODPY_VERSION}/site-packages/ldap/controls/readentry.py
-lib/python${MODPY_VERSION}/site-packages/ldap/controls/readentry.pyc
-lib/python${MODPY_VERSION}/site-packages/ldap/controls/readentry.${MODPY_PYOEXTENSION}
lib/python${MODPY_VERSION}/site-packages/ldap/controls/sessiontrack.py
-lib/python${MODPY_VERSION}/site-packages/ldap/controls/sessiontrack.pyc
-lib/python${MODPY_VERSION}/site-packages/ldap/controls/sessiontrack.${MODPY_PYOEXTENSION}
lib/python${MODPY_VERSION}/site-packages/ldap/controls/simple.py
-lib/python${MODPY_VERSION}/site-packages/ldap/controls/simple.pyc
-lib/python${MODPY_VERSION}/site-packages/ldap/controls/simple.${MODPY_PYOEXTENSION}
lib/python${MODPY_VERSION}/site-packages/ldap/controls/sss.py
-lib/python${MODPY_VERSION}/site-packages/ldap/controls/sss.pyc
-lib/python${MODPY_VERSION}/site-packages/ldap/controls/sss.${MODPY_PYOEXTENSION}
+lib/python${MODPY_VERSION}/site-packages/ldap/controls/vlv.py
lib/python${MODPY_VERSION}/site-packages/ldap/dn.py
-lib/python${MODPY_VERSION}/site-packages/ldap/dn.pyc
-lib/python${MODPY_VERSION}/site-packages/ldap/dn.${MODPY_PYOEXTENSION}
lib/python${MODPY_VERSION}/site-packages/ldap/extop/
lib/python${MODPY_VERSION}/site-packages/ldap/extop/__init__.py
-lib/python${MODPY_VERSION}/site-packages/ldap/extop/__init__.pyc
-lib/python${MODPY_VERSION}/site-packages/ldap/extop/__init__.${MODPY_PYOEXTENSION}
+${MODPY_COMMENT}lib/python${MODPY_VERSION}/site-packages/ldap/extop/${MODPY_PYCACHE}/
+lib/python${MODPY_VERSION}/site-packages/ldap/extop/${MODPY_PYCACHE}__init__.${MODPY_PYC_MAGIC_TAG}${MODPY_PYOEXTENSION}
+lib/python${MODPY_VERSION}/site-packages/ldap/extop/${MODPY_PYCACHE}__init__.${MODPY_PYC_MAGIC_TAG}pyc
+lib/python${MODPY_VERSION}/site-packages/ldap/extop/${MODPY_PYCACHE}dds.${MODPY_PYC_MAGIC_TAG}${MODPY_PYOEXTENSION}
+lib/python${MODPY_VERSION}/site-packages/ldap/extop/${MODPY_PYCACHE}dds.${MODPY_PYC_MAGIC_TAG}pyc
lib/python${MODPY_VERSION}/site-packages/ldap/extop/dds.py
-lib/python${MODPY_VERSION}/site-packages/ldap/extop/dds.pyc
-lib/python${MODPY_VERSION}/site-packages/ldap/extop/dds.${MODPY_PYOEXTENSION}
lib/python${MODPY_VERSION}/site-packages/ldap/filter.py
-lib/python${MODPY_VERSION}/site-packages/ldap/filter.pyc
-lib/python${MODPY_VERSION}/site-packages/ldap/filter.${MODPY_PYOEXTENSION}
lib/python${MODPY_VERSION}/site-packages/ldap/functions.py
-lib/python${MODPY_VERSION}/site-packages/ldap/functions.pyc
-lib/python${MODPY_VERSION}/site-packages/ldap/functions.${MODPY_PYOEXTENSION}
lib/python${MODPY_VERSION}/site-packages/ldap/ldapobject.py
-lib/python${MODPY_VERSION}/site-packages/ldap/ldapobject.pyc
-lib/python${MODPY_VERSION}/site-packages/ldap/ldapobject.${MODPY_PYOEXTENSION}
lib/python${MODPY_VERSION}/site-packages/ldap/logger.py
-lib/python${MODPY_VERSION}/site-packages/ldap/logger.pyc
-lib/python${MODPY_VERSION}/site-packages/ldap/logger.${MODPY_PYOEXTENSION}
lib/python${MODPY_VERSION}/site-packages/ldap/modlist.py
-lib/python${MODPY_VERSION}/site-packages/ldap/modlist.pyc
-lib/python${MODPY_VERSION}/site-packages/ldap/modlist.${MODPY_PYOEXTENSION}
+lib/python${MODPY_VERSION}/site-packages/ldap/pkginfo.py
lib/python${MODPY_VERSION}/site-packages/ldap/resiter.py
-lib/python${MODPY_VERSION}/site-packages/ldap/resiter.pyc
-lib/python${MODPY_VERSION}/site-packages/ldap/resiter.${MODPY_PYOEXTENSION}
lib/python${MODPY_VERSION}/site-packages/ldap/sasl.py
-lib/python${MODPY_VERSION}/site-packages/ldap/sasl.pyc
-lib/python${MODPY_VERSION}/site-packages/ldap/sasl.${MODPY_PYOEXTENSION}
lib/python${MODPY_VERSION}/site-packages/ldap/schema/
lib/python${MODPY_VERSION}/site-packages/ldap/schema/__init__.py
-lib/python${MODPY_VERSION}/site-packages/ldap/schema/__init__.pyc
-lib/python${MODPY_VERSION}/site-packages/ldap/schema/__init__.${MODPY_PYOEXTENSION}
+${MODPY_COMMENT}lib/python${MODPY_VERSION}/site-packages/ldap/schema/${MODPY_PYCACHE}/
+lib/python${MODPY_VERSION}/site-packages/ldap/schema/${MODPY_PYCACHE}__init__.${MODPY_PYC_MAGIC_TAG}${MODPY_PYOEXTENSION}
+lib/python${MODPY_VERSION}/site-packages/ldap/schema/${MODPY_PYCACHE}__init__.${MODPY_PYC_MAGIC_TAG}pyc
+lib/python${MODPY_VERSION}/site-packages/ldap/schema/${MODPY_PYCACHE}models.${MODPY_PYC_MAGIC_TAG}${MODPY_PYOEXTENSION}
+lib/python${MODPY_VERSION}/site-packages/ldap/schema/${MODPY_PYCACHE}models.${MODPY_PYC_MAGIC_TAG}pyc
+lib/python${MODPY_VERSION}/site-packages/ldap/schema/${MODPY_PYCACHE}subentry.${MODPY_PYC_MAGIC_TAG}${MODPY_PYOEXTENSION}
+lib/python${MODPY_VERSION}/site-packages/ldap/schema/${MODPY_PYCACHE}subentry.${MODPY_PYC_MAGIC_TAG}pyc
+lib/python${MODPY_VERSION}/site-packages/ldap/schema/${MODPY_PYCACHE}tokenizer.${MODPY_PYC_MAGIC_TAG}${MODPY_PYOEXTENSION}
+lib/python${MODPY_VERSION}/site-packages/ldap/schema/${MODPY_PYCACHE}tokenizer.${MODPY_PYC_MAGIC_TAG}pyc
lib/python${MODPY_VERSION}/site-packages/ldap/schema/models.py
-lib/python${MODPY_VERSION}/site-packages/ldap/schema/models.pyc
-lib/python${MODPY_VERSION}/site-packages/ldap/schema/models.${MODPY_PYOEXTENSION}
lib/python${MODPY_VERSION}/site-packages/ldap/schema/subentry.py
-lib/python${MODPY_VERSION}/site-packages/ldap/schema/subentry.pyc
-lib/python${MODPY_VERSION}/site-packages/ldap/schema/subentry.${MODPY_PYOEXTENSION}
lib/python${MODPY_VERSION}/site-packages/ldap/schema/tokenizer.py
-lib/python${MODPY_VERSION}/site-packages/ldap/schema/tokenizer.pyc
-lib/python${MODPY_VERSION}/site-packages/ldap/schema/tokenizer.${MODPY_PYOEXTENSION}
lib/python${MODPY_VERSION}/site-packages/ldap/syncrepl.py
-lib/python${MODPY_VERSION}/site-packages/ldap/syncrepl.pyc
-lib/python${MODPY_VERSION}/site-packages/ldap/syncrepl.${MODPY_PYOEXTENSION}
lib/python${MODPY_VERSION}/site-packages/ldapurl.py
-lib/python${MODPY_VERSION}/site-packages/ldapurl.pyc
-lib/python${MODPY_VERSION}/site-packages/ldapurl.${MODPY_PYOEXTENSION}
lib/python${MODPY_VERSION}/site-packages/ldif.py
-lib/python${MODPY_VERSION}/site-packages/ldif.pyc
-lib/python${MODPY_VERSION}/site-packages/ldif.${MODPY_PYOEXTENSION}
lib/python${MODPY_VERSION}/site-packages/python_ldap-${MODPY_EGG_VERSION}-py${MODPY_VERSION}.egg-info/
lib/python${MODPY_VERSION}/site-packages/python_ldap-${MODPY_EGG_VERSION}-py${MODPY_VERSION}.egg-info/PKG-INFO
lib/python${MODPY_VERSION}/site-packages/python_ldap-${MODPY_EGG_VERSION}-py${MODPY_VERSION}.egg-info/SOURCES.txt
@@ -109,6 +128,23 @@ lib/python${MODPY_VERSION}/site-packages
lib/python${MODPY_VERSION}/site-packages/python_ldap-${MODPY_EGG_VERSION}-py${MODPY_VERSION}.egg-info/not-zip-safe
lib/python${MODPY_VERSION}/site-packages/python_ldap-${MODPY_EGG_VERSION}-py${MODPY_VERSION}.egg-info/requires.txt
lib/python${MODPY_VERSION}/site-packages/python_ldap-${MODPY_EGG_VERSION}-py${MODPY_VERSION}.egg-info/top_level.txt
-lib/python${MODPY_VERSION}/site-packages/slapdtest.py
-lib/python${MODPY_VERSION}/site-packages/slapdtest.pyc
-lib/python${MODPY_VERSION}/site-packages/slapdtest.${MODPY_PYOEXTENSION}
+lib/python${MODPY_VERSION}/site-packages/slapdtest/
+lib/python${MODPY_VERSION}/site-packages/slapdtest/__init__.py
+${MODPY_COMMENT}lib/python${MODPY_VERSION}/site-packages/slapdtest/${MODPY_PYCACHE}/
+lib/python${MODPY_VERSION}/site-packages/slapdtest/${MODPY_PYCACHE}__init__.${MODPY_PYC_MAGIC_TAG}${MODPY_PYOEXTENSION}
+lib/python${MODPY_VERSION}/site-packages/slapdtest/${MODPY_PYCACHE}__init__.${MODPY_PYC_MAGIC_TAG}pyc
+lib/python${MODPY_VERSION}/site-packages/slapdtest/${MODPY_PYCACHE}_slapdtest.${MODPY_PYC_MAGIC_TAG}${MODPY_PYOEXTENSION}
+lib/python${MODPY_VERSION}/site-packages/slapdtest/${MODPY_PYCACHE}_slapdtest.${MODPY_PYC_MAGIC_TAG}pyc
+lib/python${MODPY_VERSION}/site-packages/slapdtest/_slapdtest.py
+lib/python${MODPY_VERSION}/site-packages/slapdtest/certs/
+lib/python${MODPY_VERSION}/site-packages/slapdtest/certs/README
+lib/python${MODPY_VERSION}/site-packages/slapdtest/certs/ca.conf
+lib/python${MODPY_VERSION}/site-packages/slapdtest/certs/ca.pem
+lib/python${MODPY_VERSION}/site-packages/slapdtest/certs/client.conf
+lib/python${MODPY_VERSION}/site-packages/slapdtest/certs/client.key
+lib/python${MODPY_VERSION}/site-packages/slapdtest/certs/client.pem
+lib/python${MODPY_VERSION}/site-packages/slapdtest/certs/gencerts.sh
+lib/python${MODPY_VERSION}/site-packages/slapdtest/certs/gennssdb.sh
+lib/python${MODPY_VERSION}/site-packages/slapdtest/certs/server.conf
+lib/python${MODPY_VERSION}/site-packages/slapdtest/certs/server.key
+lib/python${MODPY_VERSION}/site-packages/slapdtest/certs/server.pem

snownews doesn't support https

snownews doesn't seem to work when using https url, the program returns an
error. Adding the http url for the same xml file was producing expected result.

I tried a few https url and none work, and no issues when using http.

Found in ~/.snonews/error.log:
Fri Nov 30 12:34:18 2018: (https://perso.pw/openbsd-current.xml) https://perso.pw/openbsd-current.xml: Error in server reply.

Re: NEW: py-graphite-web

On 2018/11/30 11:21, Martijn van Duren wrote:
> ldap backend support will depend on py3-ldap, which I'll submit in a
> moment

btw, I tried updating databases/py-ldap to 3.x to support python3 (diff
at https://marc.info/?l=openbsd-ports&m=153537676010498&w=2), but it
broke existing users.

Re: NEW: py-graphite-web

Here's an updated tarball, which enables LDAP support with py3-django.
Since version 2.1 of Django the authenticate method of the backend
must support the request argument[0].

Going back at the description I found that graphite-web officially
only supports Django<2.1,>=1.8, but I much rather have it use py3-django
rather than py3-django-lts, since that would mean also changing
py3-django-tagging, which I recently submitted and there might be other
conflicts hiding out there.

I did a grep of all the removed features through the code and I been
running it in my test-setup also hasn't shown any other issues, so I
don't think there's any other snakes in the grass. But I'm still quite
new to python, so I might be mistaken.

ldap backend support will depend on py3-ldap, which I'll submit in a
moment, but I don't want to add it as a hard dependency here, since I
don't think a lot of people will want to use it.

martijn@

On 11/29/18 2:38 PM, Martijn van Duren wrote:
> Here's the promised py-graphite-web package and frontend to py-carbon.
> It is an wsgi application, which I've tested via gunicorn-3.
>
> After some wrangling I reckon I managed to place all the pieces in the
> common directories, with the exception of local_settings.py[0], which
> remains in ${MODPY_SITEPKG}/graphite, since it's an @sample, which I
> couldn't figure out how to symlink into /etc/graphite/, which would be
> the first place I would look.
>
> I decided to install the webapp in ${MODPY_SITEPKG}, since that would
> make starting up graphite as easy as
> `doas -u _graphite gunicorn-3 graphite.wsgi`
> but being a python newbie I don't know if this is desired and what the
> appropriate place would be otherwise (/var/www/graphite/webapp?).
>
> This of course depends on all other graphite mails I send out the last
> couple of days.
>
> martijn
>
> [0] https://graphite.readthedocs.io/en/latest/config-local-settings.html
>
[0] https://docs.djangoproject.com/en/2.1/releases/2.1/

Re: Untable ssl connections over ikev2 VPN

Den fre 30 nov. 2018 kl 04:21 skrev Theodore Wynnychenko <tmw@uchicago.edu>:
>
> > -----Original Message-----
> > Hello
> >
> > I have been having trouble getting an openBSD laptop to connect to ssl
> > connections when communicating over ikev2.
> >

Check if the MTU is causing issues, sometimes VPNs (which lower the
MTU of the link)
cause the effect that pings and "small" traffic works, but when you do
SSH or SSL and
it sends large pubkeys or large lists of possible crypto algs, the
packets suddenly get
too large to work, and then it freezes.


--
May the most significant bit of your life be positive.

Re: (ports-)INDEX in man pages

On Fri, Nov 30, 2018 at 12:12:10AM -0500, Daniel Jakots wrote:
> On Thu, 29 Nov 2018 15:54:37 -0700 (MST), Alexander Bluhm
> <bluhm@openbsd.org> wrote:
>
> > CVSROOT: /cvs
> > Module name: src
> > Changes by: bluhm@cvs.openbsd.org 2018/11/29 15:54:37
> >
> > Modified files:
> > share/man/man1 : outdated-perl-ports.1
> >
> > Log message:
> > Mention dependency on portslist package for outdated-perl-ports(1).
> > requested by espie@
> >
>
> Out of curiosity I looked for (i.e. grep) other man pages mentioning
> INDEX. Here's a diff for the other one. I took the wording from
> bluhm@'s diff and added a tiny improvement to his change while there.
>
> Comments? OK?
>
> Cheers,
> Daniel
>
> Index: outdated-perl-ports.1
> ===================================================================
> RCS file: /cvs/src/share/man/man1/outdated-perl-ports.1,v
> retrieving revision 1.3
> diff -u -p -r1.3 outdated-perl-ports.1
> --- outdated-perl-ports.1 29 Nov 2018 22:54:37 -0000 1.3
> +++ outdated-perl-ports.1 30 Nov 2018 05:04:45 -0000
> @@ -28,7 +28,7 @@
> .Nm
> retrieves and compares the packages list provided by CPAN with the ports
> recorded in
> -.Pa /usr/local/share/ports-INDEX
> +.Pa ${LOCALBASE}/share/ports-INDEX
> and reports which ports have a newer version available upstream.
> Note that the portslist package must be installed.
> .Pp
> Index: port-search-helper.1
> ===================================================================
> RCS file: /cvs/src/share/man/man1/port-search-helper.1,v
> retrieving revision 1.1
> diff -u -p -r1.1 port-search-helper.1
> --- port-search-helper.1 9 Jul 2018 13:51:08 -0000 1.1
> +++ port-search-helper.1 30 Nov 2018 05:04:45 -0000
> @@ -41,8 +41,9 @@ is a helper script used by
> for searches.
> .Pp
> It relies on
> -.Pa ${PORTSDIR}/INDEX
> +.Pa ${LOCALBASE}/share/ports-INDEX"
> being accurate.
> +Note the portslist package must be installed.
> .Sh SEE ALSO
> .Xr perlre 1 ,
> .Xr ports 7
Okay