Re: influxdb not starting after upgrade to 7.5

[Zé Loff]

On Tue, Apr 23, 2024 at 03:42:43PM +0200, Landry Breuil wrote:
> Le Tue, Apr 23, 2024 at 07:50:53AM +0100, Zé Loff a écrit :
> > On Mon, Apr 22, 2024 at 11:26:37PM +0100, Zé Loff wrote:
> > > 
> > > Hi all
> > > 
> > > After upgrading an amd64 machine to 7.5-stable, influxdb fails to start,
> > > saying:
> > > 
> > > 2024-04-22T22:07:42.599907Z infoWelcome to InfluxDB {"log_id": 
> > > "0oiySb1l000", "version": "2.7.3", "commit": "none", "build_date": 
> > > "2024-04-22T22:07:42Z", "log_level": "info"}
> > > 2024-04-22T22:07:42.601348Z error   Failed opening bolt {"log_id": 
> > > "0oiySb1l000", "error": "function not implemented"}
> > > 
> > > Starting with a clean /var/influxdb doesn't help, nor does doing it as
> > > root (which also starts with a clean slate, at /root/.influxdbv2).
> > > Removing and reinstalling the package didn't help either.
> > > 
> > > Has anyone else seen the same thing and/or has any advice?
> > > 
> > > Thanks in advance
> > > 
> > > -- 
> > >  
> > > 
> > 
> > Minor update: the same thing happens on -current.
> 
> with the attached diff, influxd starts on -current. That's all the testing 
> i've done :)
> 
> feedback from real world testing welcome !
> 

Built the port with this diff against 7.5-stable (minus the Makefile
changes, which are post-7.5), and everything appears to be running fine.

Admittedly, mine isn't the most complex setup in the world (single user,
a couple of datab... buckets, collecting data from a few different hosts
via telegraf, reporting via grafana), but FWIW, it seems to run OK.  I
can report again in a few days, just to be sure, but, again, this seems
to fix things.

Thanks again

-- 
 

Re: influxdb not starting after upgrade to 7.5

[Zé Loff]

On Tue, Apr 23, 2024 at 03:42:43PM +0200, Landry Breuil wrote:
> Le Tue, Apr 23, 2024 at 07:50:53AM +0100, Zé Loff a écrit :
> > On Mon, Apr 22, 2024 at 11:26:37PM +0100, Zé Loff wrote:
> > > 
> > > Hi all
> > > 
> > > After upgrading an amd64 machine to 7.5-stable, influxdb fails to start,
> > > saying:
> > > 
> > > 2024-04-22T22:07:42.599907Z infoWelcome to InfluxDB {"log_id": 
> > > "0oiySb1l000", "version": "2.7.3", "commit": "none", "build_date": 
> > > "2024-04-22T22:07:42Z", "log_level": "info"}
> > > 2024-04-22T22:07:42.601348Z error   Failed opening bolt {"log_id": 
> > > "0oiySb1l000", "error": "function not implemented"}
> > > 
> > > Starting with a clean /var/influxdb doesn't help, nor does doing it as
> > > root (which also starts with a clean slate, at /root/.influxdbv2).
> > > Removing and reinstalling the package didn't help either.
> > > 
> > > Has anyone else seen the same thing and/or has any advice?
> > > 
> > > Thanks in advance
> > > 
> > > -- 
> > >  
> > > 
> > 
> > Minor update: the same thing happens on -current.
> 
> with the attached diff, influxd starts on -current. That's all the testing 
> i've done :)
> 
> feedback from real world testing welcome !
> 

Brilliant, thanks!
I'll give this a go (pun not intended) and get back to you in a couple
of days.

Thanks again

> ? build.log
> ? buildpkgconfig.log
> ? crates.inc.2.7.0
> ? crates2.inc
> ? influxdb.diff
> ? modules.inc.2.7.0
> ? modules.inc.ok
> ? modules.inc1.9.5
> Index: Makefile
> ===
> RCS file: /cvs/ports/databases/influxdb/Makefile,v
> retrieving revision 1.33
> diff -u -r1.33 Makefile
> --- Makefile  23 Apr 2024 09:31:30 -  1.33
> +++ Makefile  23 Apr 2024 13:40:19 -
> @@ -1,9 +1,3 @@
> -# bbolt needs to be at least 1.3.8 to avoid syscall
> -# modernc.org/libc and modernc.org/sqlite might work in latest head versions 
> now but not in a release yet
> -# https://gitlab.com/cznic/libc/-/issues/29
> -# https://gitlab.com/cznic/libc/-/merge_requests/13
> -BROKEN = some modules used by influxdb require syscall() access which is 
> no longer available outside libc
> -
>  COMMENT =time-series datastore for metrics, events, and analytics
>  
>  MODUI_VERSION =  v2.7.1
> Index: distinfo
> ===
> RCS file: /cvs/ports/databases/influxdb/distinfo,v
> retrieving revision 1.8
> diff -u -r1.8 distinfo
> --- distinfo  14 Nov 2023 00:08:32 -  1.8
> +++ distinfo  23 Apr 2024 13:40:19 -
> @@ -1468,8 +1468,8 @@
>  SHA256 (go_modules/github.com/zeebo/xxh3/@v/v1.0.1.zip) = 
> ADQvDUPSdAVOzNxQ+6pBpQEBRuisgnc30hzhT2eJh0U=
>  SHA256 (go_modules/go.etcd.io/bbolt/@v/v1.3.2.mod) = 
> siQNmH3bNjz9n5PJ7VP5r19NefAOWRE8g3WvwbkcS28=
>  SHA256 (go_modules/go.etcd.io/bbolt/@v/v1.3.3.mod) = 
> siQNmH3bNjz9n5PJ7VP5r19NefAOWRE8g3WvwbkcS28=
> -SHA256 (go_modules/go.etcd.io/bbolt/@v/v1.3.6.mod) = 
> XDjGXmmRaJ8LnkB0KADeRlxstzrPjr0VRzDNxinKE2Q=
> -SHA256 (go_modules/go.etcd.io/bbolt/@v/v1.3.6.zip) = 
> o1f8zZPoZdzj04We2FfOgn96Ly3FuQz6qVIC9dduSsI=
> +SHA256 (go_modules/go.etcd.io/bbolt/@v/v1.3.8.mod) = 
> P9EfiW+DDmdLHgJxBOk0xfcQkdytIkHvnl/L5bKwPq8=
> +SHA256 (go_modules/go.etcd.io/bbolt/@v/v1.3.8.zip) = 
> GLq65n7M3SmCrQvUS7d6I46LbI2hkrWua9PA3UjVujE=
>  SHA256 
> (go_modules/go.etcd.io/etcd/@v/v0.0.0-20191023171146-3cf2f69b5738.mod) = 
> Aq68KyNI9Hgtq+/IP63YARn8NQNZRreMsAlkqJGeD74=
>  SHA256 
> (go_modules/go.etcd.io/etcd/@v/v0.0.0-20191023171146-3cf2f69b5738.zip) = 
> T6k0WCeXPTV73D0ZHzpS56EHQQEq6eXyJxLtQonpm0Q=
>  SHA256 
> (go_modules/go.mozilla.org/pkcs7/@v/v0.0.0-20200128120323-432b2356ecb1.mod) = 
> aKaMiAYDnR/VbMx/zzOQHyj4ZP5vPxuoQVx54HfhDlY=
> @@ -3620,8 +3620,8 @@
>  SIZE (go_modules/github.com/zeebo/xxh3/@v/v1.0.1.zip) = 269263
>  SIZE (go_modules/go.etcd.io/bbolt/@v/v1.3.2.mod) = 24
>  SIZE (go_modules/go.etcd.io/bbolt/@v/v1.3.3.mod) = 24
> -SIZE (go_modules/go.etcd.io/bbolt/@v/v1.3.6.mod) = 94
> -SIZE (go_modules/go.etcd.io/bbolt/@v/v1.3.6.zip) = 118439
> +SIZE (go_modules/go.etcd.io/bbolt/@v/v1.3.8.mod) = 280
> +SIZE (go_modules/go.etcd.io/bbolt/@v/v1.3.8.zip) = 144978
>  SIZE (go_modules/go.etcd.io/etcd/@v/v0.0.0-20191023171146-3cf2f69b5738.mod) 
> = 2182
>  SIZE (go_modules/go.etcd.io/etcd/@v/v0.0.0-20191023171146-3cf2f69b5738.

Re: influxdb not starting after upgrade to 7.5

[Zé Loff]

On Tue, Apr 23, 2024 at 09:42:26AM +0100, Stuart Henderson wrote:
> On 2024/04/22 23:26, Zé Loff wrote:
> > 
> > Hi all
> > 
> > After upgrading an amd64 machine to 7.5-stable, influxdb fails to start,
> > saying:
> > 
> > 2024-04-22T22:07:42.599907Z infoWelcome to InfluxDB {"log_id": 
> > "0oiySb1l000", "version": "2.7.3", "commit": "none", "build_date": 
> > "2024-04-22T22:07:42Z", "log_level": "info"}
> > 2024-04-22T22:07:42.601348Z error   Failed opening bolt {"log_id": 
> > "0oiySb1l000", "error": "function not implemented"}
> > 
> > Starting with a clean /var/influxdb doesn't help, nor does doing it as
> > root (which also starts with a clean slate, at /root/.influxdbv2).
> > Removing and reinstalling the package didn't help either.
> > 
> > Has anyone else seen the same thing and/or has any advice?
> > 
> > Thanks in advance
> > 
> > -- 
> >  
> > 
> 
> OpenBSD was changed so that syscalls can only be made by libc. However
> some software (especially software written in Go) still relies on being
> able to call syscalls directly from the main program and this will no
> longer run on OpenBSD.
> 
> One of the go modules used by influxdb is an old version of bbolt.
> This problem is fixed in an update to bbolt, but even the most recent
> influxdb release (2.7.6) still uses an old bbolt from before the fix.
> 
> Some other modules may have a problem too (influxdb uses
> modernc.org/sqlite which definitely used syscall in some use cases; I'm
> unsure if that got fixed or whether influxdb's use of it triggers those
> cases).
> 
> I'm not too familiar with influxdb but it seems bolt/bbolt is a required
> part of it, so I think we might as well mark it broken for now, it's not
> going to magically start working unless changes are made.
> 

Thanks Stuart, and everyone else who looked into it.  I thought it'd be
syscall-related.  I'll just throw it into a VM running 7.4 for the time
being.

-- 
 

Re: influxdb not starting after upgrade to 7.5

[Zé Loff]

On Mon, Apr 22, 2024 at 11:26:37PM +0100, Zé Loff wrote:
> 
> Hi all
> 
> After upgrading an amd64 machine to 7.5-stable, influxdb fails to start,
> saying:
> 
> 2024-04-22T22:07:42.599907Z infoWelcome to InfluxDB {"log_id": 
> "0oiySb1l000", "version": "2.7.3", "commit": "none", "build_date": 
> "2024-04-22T22:07:42Z", "log_level": "info"}
> 2024-04-22T22:07:42.601348Z error   Failed opening bolt {"log_id": 
> "0oiySb1l000", "error": "function not implemented"}
> 
> Starting with a clean /var/influxdb doesn't help, nor does doing it as
> root (which also starts with a clean slate, at /root/.influxdbv2).
> Removing and reinstalling the package didn't help either.
> 
> Has anyone else seen the same thing and/or has any advice?
> 
> Thanks in advance
> 
> -- 
>  
> 

Minor update: the same thing happens on -current.

-- 
 

influxdb not starting after upgrade to 7.5

[Zé Loff]

Hi all

After upgrading an amd64 machine to 7.5-stable, influxdb fails to start,
saying:

2024-04-22T22:07:42.599907Z infoWelcome to InfluxDB {"log_id": 
"0oiySb1l000", "version": "2.7.3", "commit": "none", "build_date": 
"2024-04-22T22:07:42Z", "log_level": "info"}
2024-04-22T22:07:42.601348Z error   Failed opening bolt {"log_id": 
"0oiySb1l000", "error": "function not implemented"}

Starting with a clean /var/influxdb doesn't help, nor does doing it as
root (which also starts with a clean slate, at /root/.influxdbv2).
Removing and reinstalling the package didn't help either.

Has anyone else seen the same thing and/or has any advice?

Thanks in advance

-- 
 

Re: zigbee2mqtt, anyone?

[Zé Loff]

On Wed, Dec 27, 2023 at 06:48:33PM +, Stuart Henderson wrote:
> On 2023/12/27 13:15, Zé Loff wrote:
> > On Wed, Dec 27, 2023 at 12:19:05PM +, Mikolaj Kucharski wrote:
> > > - Does anyone has work in progress zigbee2mqtt port?
> 
> I looked at it once, got as far as copying Makefile.template and
> realising that it uses node.js then stopped bothering.
> 
> It's possible to write ports for such software but it usually means
> fetching with npm and creating and uploading a tarball somewhere, then
> have the port fetch that tarball and extract/install to a sensible
> location. Ideally the npm/tarball stage should be in a Makefile target
> so it's easy for others to update it too.
> 
> > - change the ownership of /usr/local/opt/zigbee2mqtt/* to _zigbee2mqtt
> 
> It's a bad idea for the code to be writable by the uid running the
> service. Better if only the only writable files/dirs are those where
> data/logs/etc are stored.

Thanks for this, Stuart.  Like I said in my message, I didn't give the
whole thing too much thought, sadly.

For the record, only the "data" directory, and everything in it needs to
be owned by _zigbee2mqtt.

> > * Note that this suffers from the already described problem with node
> > ports, in that it won't start automatically on boot, but it will start
> > manually with "rcctl start".
> 
> Thanks to jca's knowledge of fiddly shell features, this should no
> longer be a problem in -current.


-- 
 

Re: zigbee2mqtt, anyone?

[Zé Loff]

On Wed, Dec 27, 2023 at 12:19:05PM +, Mikolaj Kucharski wrote:
> Hi.
> 
> - Does anyone has work in progress zigbee2mqtt port?

Not me.  I have no experience porting.

> - Does it make sense to try to use it on OpenBSD?

I do.  Whether it makes sense or not, is a different matter :)

> - Any hands on experience with zigbee2mqtt on OpenBSD?

Yes.  It works fine, AFAICT.  Here's what I did:

- pkg_add node

- added a _zigbee2mqtt user similar to other daemon users

- added this user to the 'dialer' group so that it can access the
  calling unit (e.g.  /dev/cuaU0). This can (and probably should, TBH)
  be avoided by changing the device's owner, either permanently or via
  hotplugd, but I didn't bother to.

- copied zigbee2mqtt into (a newly created) /usr/local/opt/zigbee2mqtt. 

- change the ownership of /usr/local/opt/zigbee2mqtt/* to _zigbee2mqtt

- created /etc/rc.d/zigbee2mqtt with the following contents:

#!/bin/ksh

daemon="/usr/local/bin/node"
daemon_flags="/usr/local/opt/zigbee2mqtt/index.js"
daemon_user=_zigbee2mqtt

. /etc/rc.d/rc.subr

pexp="$(eval echo ${daemon}${daemon_flags:+ ${daemon_flags}})"
rc_bg=YES
rc_reload=NO

rc_cmd $1

- rcctl enable zigbee2mqtt (* see note below)
- rcctl start  zigbee2mqtt

And that's it.

* Note that this suffers from the already described problem with node
ports, in that it won't start automatically on boot, but it will start
manually with "rcctl start".

> - If you are using it, are you happy, unhappy, gonna stick to it or not?

Have been using it for a while, and am happy with it.  Not so happy with
my setup, because it really should be properly installed/ported, but *I*
didn't bother to.  E.g. the 'data' directory is a mess, holding the
configuration files (should be in /etc), logs (/var/log), and the state
and database files (I'd put them somewhere in /var).

> I have zero experience with Zigbee or any home automation,
> that's why I am asking.
> 
> 
> -- 
> Regards,
>  Mikolaj
> 

-- 
 

Re: WXNEEDED flag stripped when installing

[Zé Loff]

On Wed, Sep 06, 2023 at 06:08:58PM +0100, Stuart Henderson wrote:
> On 2023/09/06 15:46, Zé Loff wrote:
> > On Wed, Sep 06, 2023 at 04:10:36PM +0200, Solène Rapenne wrote:
> > > > 
> > > > 
> > > > Forgot to add REVISION=0 to the Makefile. Facepalm.
> > > > I knew this _had_ to be my fault, just wasn't getting there, and was
> > > > too
> > > > trigger happy with the emails.  Sorry for the noise.
> > > > 
> > > 
> > > if you don't want to bother with REVISION when working on a port, you
> > > can use "make clean=all" that should clean pobj,plist,package (and not
> > > the distfiles IIRC) before trying again
> > 
> > Thanks, I didn't know about the "=all" part.
> > 
> > That wasn't the issue though. I manually erased /pboj and /package, and
> > even tested with a completely new ports tree.  The issue was that since
> > the version I had just compiled matched the one on the repository, make
> > install fetched it, instead of (locally) building a package from the
> > compiled code  I still find that surprising, TBH
> > 
> > -- 
> >  
> > 
> 
> sounds like you have set FETCH_PACKAGES somewhere (mk.conf probably),
> this is generally a bad idea if you're working on ports, IME it's usually
> better to type it on the command line when you want it
> 

Thanks Stuart, that's exactly right.  I had completely forgotten about
it.

-- 
 

Re: WXNEEDED flag stripped when installing

[Zé Loff]

On Wed, Sep 06, 2023 at 04:10:36PM +0200, Solène Rapenne wrote:
> > 
> > 
> > Forgot to add REVISION=0 to the Makefile. Facepalm.
> > I knew this _had_ to be my fault, just wasn't getting there, and was
> > too
> > trigger happy with the emails.  Sorry for the noise.
> > 
> 
> if you don't want to bother with REVISION when working on a port, you
> can use "make clean=all" that should clean pobj,plist,package (and not
> the distfiles IIRC) before trying again

Thanks, I didn't know about the "=all" part.

That wasn't the issue though. I manually erased /pboj and /package, and
even tested with a completely new ports tree.  The issue was that since
the version I had just compiled matched the one on the repository, make
install fetched it, instead of (locally) building a package from the
compiled code  I still find that surprising, TBH

-- 
 

Re: WXNEEDED flag stripped when installing

[Zé Loff]

On Wed, Sep 06, 2023 at 02:18:29PM +0100, Zé Loff wrote:
> On Wed, Sep 06, 2023 at 01:52:51PM +0100, Zé Loff wrote:
> > 
> > TL,DR: Something weird is happening: the WXNEEDED is being stripped from
> > R's binary when creating the package.
> > 
> > Long version:
> > I need math/R to be compiled with WXNEEDED, so I add USE_WXNEEDED=Yes to
> > the Makefile, and roll my own package, which I then install.  This has
> > been working fine for some time now.  I did this again, after Rafael
> > Sadowski updated the port, but this time it failed.
> > 
> > The R binary is built with the WXNEEDED flag on:
> > 
> > $ make
> > ...
> > $ objdump -x /usr/ports/pobj/R-4.2.3/build-amd64/bin/exec/R
> > ...
> > OPENBSD_RANDOMIZE off0x0e10 vaddr 0x2e10 
> > paddr 0x2e10 align 2**3
> >  filesz 0x0028 memsz 0x0028 flags rw-
> >STACK off0x vaddr 0x paddr 
> > 0x align 2**0
> >  filesz 0x memsz 0x flags rw-
> > OPENBSD_WXNEEDED off0x vaddr 0x 
> > paddr 0x align 2**0
> >  filesz 0x memsz 0x flags --x
> > NOTE off0x032c vaddr 0x032c paddr 
> > 0x032c align 2**2
> >  filesz 0x0018 memsz 0x0018 flags r--
> > ...
> > 
> > 
> > But the binary that gets installed is not:
> > 
> > $ make install
> > ...
> > $ objdump -x /usr/local/lib/R/bin/exec/R
> > ...
> > OPENBSD_RANDOMIZE off0x0dd0 vaddr 0x2dd0 
> > paddr 0x2dd0 align 2**3
> >  filesz 0x0028 memsz 0x0028 flags rw-
> >STACK off0x vaddr 0x paddr 
> > 0x align 2**0
> >  filesz 0x memsz 0x flags rw-
> > NOTE off0x02f4 vaddr 0x02f4 paddr 
> > 0x02f4 align 2**2
> >  filesz 0x0018 memsz 0x0018 flags r--
> > ...
> > 
> > 
> > Nor is the one that goes in the package:
> > 
> > $ find /usr/ports/packages -name R-4.2.3.tgz -delete
> > $ make package
> > ...
> > $ cd /tmp
> > $ tar xzf /usr/ports/packages/amd64/ftp/R-4.2.3.tgz lib/R/bin/exec/R
> > $ objdump -x lib/R/bin/exec/R
> > ...
> > OPENBSD_RANDOMIZE off0x0dd0 vaddr 0x2dd0 
> > paddr 0x2dd0 align 2**3
> >  filesz 0x0028 memsz 0x0028 flags rw-
> >STACK off0x vaddr 0x paddr 
> > 0x align 2**0
> >  filesz 0x memsz 0x flags rw-
> > NOTE off0x02f4 vaddr 0x02f4 paddr 
> > 0x02f4 align 2**2
> >  filesz 0x0018 memsz 0x0018 flags r--
> > ...
> > 
> > 
> > This is on amd64 -current (Sep 3), and a fresh ports tree, synced today
> > (Sep 6) from CVS.
> > 
> > Any clues as to what might be going on?
> > 
> > Thanks in advance
> > Zé
> > 
> > -- 
> >  
> > 
> 
> Bad choice of subject line.  It's obviously not being stripped.  The
> issue is that make package / make install go fetch the package from the
> repository instead of packaging the newly compiled code:
> 
> $ sha256 /usr/ports/packages/amd64/ftp/R-4.2.3.tgz
> SHA256 (/usr/ports/packages/amd64/ftp/R-4.2.3.tgz) = 
> f36b4b99633dd1ab666c0a6f4b5adcf45f0c0ddac32551177b6907b447e93519
> $ cd /tmp
> $ ftp 
> http://cdn.openbsd.org/pub/OpenBSD/snapshots/packages/amd64/R-4.2.3.tgz
> $ sha256 R-4.2.3.tgz
> SHA256 (R-4.2.3.tgz) = 
> f36b4b99633dd1ab666c0a6f4b5adcf45f0c0ddac32551177b6907b447e93519
> 
> -- 
>  
> 

Forgot to add REVISION=0 to the Makefile. Facepalm.
I knew this _had_ to be my fault, just wasn't getting there, and was too
trigger happy with the emails.  Sorry for the noise.

-- 
 

Re: WXNEEDED flag stripped when installing

[Zé Loff]

On Wed, Sep 06, 2023 at 01:52:51PM +0100, Zé Loff wrote:
> 
> TL,DR: Something weird is happening: the WXNEEDED is being stripped from
> R's binary when creating the package.
> 
> Long version:
> I need math/R to be compiled with WXNEEDED, so I add USE_WXNEEDED=Yes to
> the Makefile, and roll my own package, which I then install.  This has
> been working fine for some time now.  I did this again, after Rafael
> Sadowski updated the port, but this time it failed.
> 
> The R binary is built with the WXNEEDED flag on:
> 
> $ make
> ...
> $ objdump -x /usr/ports/pobj/R-4.2.3/build-amd64/bin/exec/R
> ...
> OPENBSD_RANDOMIZE off0x0e10 vaddr 0x2e10 
> paddr 0x2e10 align 2**3
>  filesz 0x0028 memsz 0x0028 flags rw-
>STACK off0x vaddr 0x paddr 
> 0x align 2**0
>  filesz 0x memsz 0x flags rw-
> OPENBSD_WXNEEDED off0x vaddr 0x paddr 
> 0x align 2**0
>  filesz 0x memsz 0x flags --x
> NOTE off0x032c vaddr 0x032c paddr 
> 0x032c align 2**2
>  filesz 0x0018 memsz 0x0018 flags r--
> ...
> 
> 
> But the binary that gets installed is not:
> 
> $ make install
> ...
> $ objdump -x /usr/local/lib/R/bin/exec/R
> ...
> OPENBSD_RANDOMIZE off0x0dd0 vaddr 0x2dd0 
> paddr 0x2dd0 align 2**3
>  filesz 0x0028 memsz 0x0028 flags rw-
>STACK off0x vaddr 0x paddr 
> 0x align 2**0
>  filesz 0x memsz 0x flags rw-
> NOTE off0x02f4 vaddr 0x02f4 paddr 
> 0x02f4 align 2**2
>  filesz 0x0018 memsz 0x0018 flags r--
> ...
> 
> 
> Nor is the one that goes in the package:
> 
> $ find /usr/ports/packages -name R-4.2.3.tgz -delete
> $ make package
> ...
> $ cd /tmp
> $ tar xzf /usr/ports/packages/amd64/ftp/R-4.2.3.tgz lib/R/bin/exec/R
> $ objdump -x lib/R/bin/exec/R
> ...
> OPENBSD_RANDOMIZE off0x0dd0 vaddr 0x2dd0 
> paddr 0x2dd0 align 2**3
>  filesz 0x0028 memsz 0x0028 flags rw-
>STACK off0x vaddr 0x paddr 
> 0x align 2**0
>  filesz 0x memsz 0x flags rw-
> NOTE off0x02f4 vaddr 0x02f4 paddr 
> 0x02f4 align 2**2
>  filesz 0x0018 memsz 0x0018 flags r--
> ...
> 
> 
> This is on amd64 -current (Sep 3), and a fresh ports tree, synced today
> (Sep 6) from CVS.
> 
> Any clues as to what might be going on?
> 
> Thanks in advance
> Zé
> 
> -- 
>  
> 

Bad choice of subject line.  It's obviously not being stripped.  The
issue is that make package / make install go fetch the package from the
repository instead of packaging the newly compiled code:

$ sha256 /usr/ports/packages/amd64/ftp/R-4.2.3.tgz
SHA256 (/usr/ports/packages/amd64/ftp/R-4.2.3.tgz) = 
f36b4b99633dd1ab666c0a6f4b5adcf45f0c0ddac32551177b6907b447e93519
$ cd /tmp
$ ftp 
http://cdn.openbsd.org/pub/OpenBSD/snapshots/packages/amd64/R-4.2.3.tgz
$ sha256 R-4.2.3.tgz
SHA256 (R-4.2.3.tgz) = 
f36b4b99633dd1ab666c0a6f4b5adcf45f0c0ddac32551177b6907b447e93519

-- 
 

WXNEEDED flag stripped when installing

[Zé Loff]

TL,DR: Something weird is happening: the WXNEEDED is being stripped from
R's binary when creating the package.

Long version:
I need math/R to be compiled with WXNEEDED, so I add USE_WXNEEDED=Yes to
the Makefile, and roll my own package, which I then install.  This has
been working fine for some time now.  I did this again, after Rafael
Sadowski updated the port, but this time it failed.

The R binary is built with the WXNEEDED flag on:

$ make
...
$ objdump -x /usr/ports/pobj/R-4.2.3/build-amd64/bin/exec/R
...
OPENBSD_RANDOMIZE off0x0e10 vaddr 0x2e10 paddr 
0x2e10 align 2**3
 filesz 0x0028 memsz 0x0028 flags rw-
   STACK off0x vaddr 0x paddr 
0x align 2**0
 filesz 0x memsz 0x flags rw-
OPENBSD_WXNEEDED off0x vaddr 0x paddr 
0x align 2**0
 filesz 0x memsz 0x flags --x
NOTE off0x032c vaddr 0x032c paddr 
0x032c align 2**2
 filesz 0x0018 memsz 0x0018 flags r--
...


But the binary that gets installed is not:

$ make install
...
$ objdump -x /usr/local/lib/R/bin/exec/R
...
OPENBSD_RANDOMIZE off0x0dd0 vaddr 0x2dd0 paddr 
0x2dd0 align 2**3
 filesz 0x0028 memsz 0x0028 flags rw-
   STACK off0x vaddr 0x paddr 
0x align 2**0
 filesz 0x memsz 0x flags rw-
NOTE off0x02f4 vaddr 0x02f4 paddr 
0x02f4 align 2**2
 filesz 0x0018 memsz 0x0018 flags r--
...


Nor is the one that goes in the package:

$ find /usr/ports/packages -name R-4.2.3.tgz -delete
$ make package
...
$ cd /tmp
$ tar xzf /usr/ports/packages/amd64/ftp/R-4.2.3.tgz lib/R/bin/exec/R
$ objdump -x lib/R/bin/exec/R
...
OPENBSD_RANDOMIZE off0x0dd0 vaddr 0x2dd0 paddr 
0x2dd0 align 2**3
 filesz 0x0028 memsz 0x0028 flags rw-
   STACK off0x vaddr 0x paddr 
0x align 2**0
 filesz 0x memsz 0x flags rw-
NOTE off0x02f4 vaddr 0x02f4 paddr 
0x02f4 align 2**2
 filesz 0x0018 memsz 0x0018 flags r--
...


This is on amd64 -current (Sep 3), and a fresh ports tree, synced today
(Sep 6) from CVS.

Any clues as to what might be going on?

Thanks in advance
Zé

-- 
 

Re: sogo does not log real ip of the client

[Zé Loff]

On Mon, Feb 06, 2023 at 02:07:25PM +0300, Maksim Rodin wrote:
> I added a space to that line, still no change in logs.
> The whole config looks now so:

Thanks.

Skimming through your config and the excerpt from the log, I'd say the
GET request should be matched by the (now corrected) location block.
If this is the case -- and you can easily check this by using a tester
like https://nginx.viraptor.info/ -- then the appropriate headers are
being added to the request, and the problem lies with how SOGo handles
and/or logs them.  You commented out nginx log-related directives, but
maybe those logs could provide some insight as well.

> 
> ```
> # Take note of http://wiki.nginx.org/Pitfalls
> 
> #user  www;
> worker_processes  1;
> 
> #load_module "modules/ngx_stream_module.so";
> 
> #error_log  logs/error.log;
> #error_log  logs/error.log  notice;
> #error_log  logs/error.log  info;
> #error_log  syslog:server=unix:/dev/log,severity=notice;
> 
> #pidlogs/nginx.pid;
> 
> worker_rlimit_nofile 1024;
> events {
> worker_connections  800;
> }
> 
> 
> http {
> client_max_body_size 50m;
> include   mime.types;
> default_type  application/octet-stream;
> index index.html index.htm;
> 
> #log_format  main  '$remote_addr - $remote_user [$time_local] "$request" '
> #  '$status $body_bytes_sent "$http_referer" '
> #  '"$http_user_agent" "$http_x_forwarded_for"';
> 
> #access_log  logs/access.log  main;
> #access_log  syslog:server=unix:/dev/log,severity=notice main;
> 
> #tcp_nopush on;
> 
> #keepalive_timeout  0;
> keepalive_timeout  65;
> 
> #gzip  on;
> 
> server_tokens off;
> 
> server {
>   listen 80;
>   server_name  mail.somedomain.org;
>   return 301 https://mail.somedomain.org$request_uri;
> 
> }
> 
> server {
> 
>   listen   443 ssl ;
>   server_name  mail.somedomain.org;
>   root /var/www/lib/sogo/www/;
>   proxy_http_version 1.1;
> 
>   ssl_certificate 
> /etc/letsencrypt/live/somedomain.org/fullchain.pem;
>   ssl_certificate_key  
> /etc/letsencrypt/live/somedomain.org/privkey.pem;
> 
>   ssl_session_timeout  5m;
>   ssl_session_cacheshared:SSL:1m;
> 
>   ssl_ciphers  HIGH:!aNULL:!MD5:!RC4;
>   ssl_prefer_server_ciphers   on;
> 
>   location = /
>   {
>   rewrite ^ http://$server_name/SOGo;
>   allow all;
>   }
> 
>   # For IOS 7
>   location = /principals/
>   {
>   rewrite ^ http://$server_name/SOGo/dav;
>   allow all;
>   }
> 
>   location = /.well-known/caldav/
>   {
>   rewrite ^ http://$server_name/SOGo/dav;
>   }
> 
>   location = /.well-known/carddav/
>   {
>   rewrite ^ http://$server_name/SOGo/dav;
>   allow all;
>   }
> 
>   location ^~ /SOGo
>   {
>   proxy_pass http://127.0.0.1:2;
>   proxy_redirect http://127.0.0.1:2 default;
>   # forward user's IP address
>   proxy_set_header X-Real-IP $remote_addr;
>   proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
>   proxy_set_header Host $host;
>   proxy_set_header x-webobjects-server-protocol HTTP/1.0;
>   proxy_set_header x-webobjects-remote-host 127.0.0.1;
>   proxy_set_header x-webobjects-server-name $server_name;
>   proxy_set_header x-webobjects-server-url $scheme://$host;
>   proxy_set_header x-webobjects-server-port $server_port;
>   proxy_connect_timeout 90;
>   proxy_send_timeout 90;
>   proxy_read_timeout 90;
>   proxy_buffer_size 256k;
>   proxy_buffers 4 512k;
>   proxy_busy_buffers_size 512k;
>   proxy_temp_file_write_size 512k;
>   client_max_body_size 50m;
>   client_body_buffer_size 128k;
>   break;
>   }
> 
>   location /SOGo.woa/WebServerResources/
>   {
>   alias /var/www/lib/sogo/www/;
>   allow all;
>   }
> 
>   location /SOGo/WebServerResources/
>   {
>   alias /var/www/lib/sogo/www/;
>   allow all;
>   }
> 
>   location ^/SOGo/so

Re: sogo does not log real ip of the client

[Zé Loff]

On Mon, Feb 06, 2023 at 11:32:47AM +0300, Maksim Rodin wrote:
> Hello,
> > This looks odd, and I can't check right now, but I don't think it
> > matches "/SOGo/..." URLs.  Shouldn't this be "location ~ ^/SOGo"?
> > 
> I just used the example nginx config from sogo's pkg-readme
> and only had to raise some proxy buffer settings because without these nginx 
> would
> return errors about too big response from the upstream.
> With this config Sogo webmail works.
> The only problem is its logs.

I found a couple of websites that have the same config as the
pkg-readme (and you), but I also found some that have an extra space
between "^~" and "/SOGo".  I am inclined to believe that the space
_should_ be there.

Without that space, nginx will only match that location block if
"^~/SOGo" (sic) is the beginning of the URI.  If you add a space then
"^~" becomes a modifier that means 'if the URI matches the following
regex, use this block and stop looking for other matches' and "/SOGo"
is the regex itself.

So, in summary, I _think_ that there's a space missing between "^~" and
"/SOGo" on the pkg-readme (and thus on your config), but I don't have a
SOGO instance on which to test.  Is it feasible for you to try adding
that space to see if it makes a difference?  Maybe someone else using it
can chime in. 

> On Mon Feb  6 07:56:40 2023, Zé Loff wrote:
> > On Mon, Feb 06, 2023 at 08:39:04AM +0300, Maksim Rodin wrote:
> > > Hello,
> > > After taking closer look at sogo I found out that it does not log real
> > > ip of the client.
> > > I set up the nginx just as it is it pkg-readme:
> > > ...
> > > location ^~/SOGo
> > 
> > This looks odd, and I can't check right now, but I don't think it
> > matches "/SOGo/..." URLs.  Shouldn't this be "location ~ ^/SOGo"?
> > 
> > > {
> > > proxy_pass http://127.0.0.1:2;
> > > proxy_redirect http://127.0.0.1:2 default;
> > > # forward user's IP address
> > > proxy_set_header X-Real-IP $remote_addr;
> > > proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
> > > proxy_set_header Host $host;
> > > proxy_set_header x-webobjects-server-protocol HTTP/1.0;
> > > proxy_set_header x-webobjects-remote-host 127.0.0.1;
> > > proxy_set_header x-webobjects-server-name $server_name;
> > > proxy_set_header x-webobjects-server-url $scheme://$host;
> > > proxy_set_header x-webobjects-server-port $server_port;
> > > ...
> > > 
> > > But the only ip I see in sogo.log is 127.0.0.1:
> > > ...
> > > Feb 06 08:18:52 sogod [5233]: <0x0x1314c787188[SOGoCache]> Cache cleanup 
> > > interval set every 300.00 seconds
> > > Feb 06 08:18:52 sogod [5233]: <0x0x1314c787188[SOGoCache]> Using host(s) 
> > > 'localhost' as server(s)
> > > Feb 06 08:18:52 sogod [5233]: [WARN] 
> > > <0x0x13205ef07e8[SOGoWebDAVAclManager]> entry '{DAV:}write' already 
> > > exists in DAV permissions table
> > > Feb 06 08:18:52 sogod [5233]: [WARN] 
> > > <0x0x13205ef07e8[SOGoWebDAVAclManager]> entry '{DAV:}write-properties' 
> > > already exists in DAV permissions table
> > > Feb 06 08:18:52 sogod [5233]: [WARN] 
> > > <0x0x13205ef07e8[SOGoWebDAVAclManager]> entry '{DAV:}write-content' 
> > > already exists in DAV permissions table
> > > Feb 06 08:18:52 sogod [5233]: 127.0.0.1 "GET 
> > > /SOGo/so/myu...@mydomain.ru/Calendar/alarmslist?browserTime=1675660780 
> > > HTTP/1.1" 200 63/0 0.721 - - -
> > > Feb 06 08:18:53 sogod [39052]: <0x0x1316e725408[NGImap4Client]> TLS 
> > > started successfully.
> > > Feb 06 08:18:53 sogod [39052]: 127.0.0.1 "POST 
> > > /SOGo/so/myu...@mydomain.ru/Mail/0/folderINBOX/changes HTTP/1.1" 200 
> > > 21/126 1.279 - - -
> > > Feb 06 08:19:07 sogod [39052]: 127.0.0.1 "GET 
> > > /SOGo/so/myu...@mydomain.ru/Contacts/view HTTP/1.1" 200 21189/0 0.346 
> > > 88239 75% -
> > > Feb 06 08:19:08 sogod [39052]: [WARN] 
> > > <0x0x131f5640948[SOGoWebDAVAclManager]> entry '{DAV:}write' already 
> > > exists in DAV permissions table
> > > Feb 06 08:19:08 sogod [39052]: [WARN] 
> > > <0x0x131f5640948[SOGoWebDAVAclManager]> entry '{DAV:}write-properties' 
> > > already exists in DAV permissions table
> > > Feb 06 08:19:08 sogod [39052]: [WARN] 
> > > <0x0x131f5640948[SOGoWebDAVAclManager]> entry '{DAV:}write-conten

Re: sogo does not log real ip of the client

[Zé Loff]

On Mon, Feb 06, 2023 at 08:39:04AM +0300, Maksim Rodin wrote:
> Hello,
> After taking closer look at sogo I found out that it does not log real
> ip of the client.
> I set up the nginx just as it is it pkg-readme:
> ...
> location ^~/SOGo

This looks odd, and I can't check right now, but I don't think it
matches "/SOGo/..." URLs.  Shouldn't this be "location ~ ^/SOGo"?

> {
> proxy_pass http://127.0.0.1:2;
> proxy_redirect http://127.0.0.1:2 default;
> # forward user's IP address
> proxy_set_header X-Real-IP $remote_addr;
> proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
> proxy_set_header Host $host;
> proxy_set_header x-webobjects-server-protocol HTTP/1.0;
> proxy_set_header x-webobjects-remote-host 127.0.0.1;
> proxy_set_header x-webobjects-server-name $server_name;
> proxy_set_header x-webobjects-server-url $scheme://$host;
> proxy_set_header x-webobjects-server-port $server_port;
> ...
> 
> But the only ip I see in sogo.log is 127.0.0.1:
> ...
> Feb 06 08:18:52 sogod [5233]: <0x0x1314c787188[SOGoCache]> Cache cleanup 
> interval set every 300.00 seconds
> Feb 06 08:18:52 sogod [5233]: <0x0x1314c787188[SOGoCache]> Using host(s) 
> 'localhost' as server(s)
> Feb 06 08:18:52 sogod [5233]: [WARN] <0x0x13205ef07e8[SOGoWebDAVAclManager]> 
> entry '{DAV:}write' already exists in DAV permissions table
> Feb 06 08:18:52 sogod [5233]: [WARN] <0x0x13205ef07e8[SOGoWebDAVAclManager]> 
> entry '{DAV:}write-properties' already exists in DAV permissions table
> Feb 06 08:18:52 sogod [5233]: [WARN] <0x0x13205ef07e8[SOGoWebDAVAclManager]> 
> entry '{DAV:}write-content' already exists in DAV permissions table
> Feb 06 08:18:52 sogod [5233]: 127.0.0.1 "GET 
> /SOGo/so/myu...@mydomain.ru/Calendar/alarmslist?browserTime=1675660780 
> HTTP/1.1" 200 63/0 0.721 - - -
> Feb 06 08:18:53 sogod [39052]: <0x0x1316e725408[NGImap4Client]> TLS started 
> successfully.
> Feb 06 08:18:53 sogod [39052]: 127.0.0.1 "POST 
> /SOGo/so/myu...@mydomain.ru/Mail/0/folderINBOX/changes HTTP/1.1" 200 21/126 
> 1.279 - - -
> Feb 06 08:19:07 sogod [39052]: 127.0.0.1 "GET 
> /SOGo/so/myu...@mydomain.ru/Contacts/view HTTP/1.1" 200 21189/0 0.346 88239 
> 75% -
> Feb 06 08:19:08 sogod [39052]: [WARN] <0x0x131f5640948[SOGoWebDAVAclManager]> 
> entry '{DAV:}write' already exists in DAV permissions table
> Feb 06 08:19:08 sogod [39052]: [WARN] <0x0x131f5640948[SOGoWebDAVAclManager]> 
> entry '{DAV:}write-properties' already exists in DAV permissions table
> Feb 06 08:19:08 sogod [39052]: [WARN] <0x0x131f5640948[SOGoWebDAVAclManager]> 
> entry '{DAV:}write-content' already exists in DAV permissions table
> Feb 06 08:19:08 sogod [39052]: 127.0.0.1 "GET 
> /SOGo/so/myu...@mydomain.ru/Calendar/alarmslist?browserTime=1675660796 
> HTTP/1.1" 200 63/0 0.022 - - -
> Feb 06 08:19:08 sogod [39052]: 127.0.0.1 "POST 
> /SOGo/so/myu...@mydomain.ru/Contacts/645D-63DD1280-5-5CF5F100/view HTTP/1.1" 
> 200 522/46 0.027 - - -
> Feb 06 08:19:08 sogod [5233]: <0x0x13173c7b808[NGImap4Client]> TLS started 
> successfully.
> Feb 06 08:19:08 sogod [39052]: 127.0.0.1 "GET 
> /SOGo/so/myu...@mydomain.ru/Contacts/645D-63DD1280-5-5CF5F100/645D-63DD1280-7-5CF5F100.vcf/view
>  HTTP/1.1" 200 167/0 0.030 - - -
> Feb 06 08:19:08 sogod [5233]: 127.0.0.1 "POST 
> /SOGo/so/myu...@mydomain.ru/Mail/0/folderINBOX/changes HTTP/1.1" 200 21/126 
> 0.342 - - -
> Feb 06 08:19:17 sogod [5233]: SOGoUserHomePage user 'myu...@mydomain.ru' 
> logged off
> Feb 06 08:19:17 sogod [5233]: 127.0.0.1 "GET 
> /SOGo/so/myu...@mydomain.ru/logoff HTTP/1.1" 302 0/0 0.060 - - -
> Feb 06 08:19:17 sogod [5233]: 127.0.0.1 "GET /SOGo/so/ HTTP/1.1" 200 12347/0 
> 0.114 45323 72% -
> ...
> 
> Is there something I forgot to set up?
> 
> -- 
> Maksim Rodin
> 

-- 
 

Re: [NEW/Update] net/nicotine-plus-3.2.2 port

[Zé Loff]

On Sun, Jul 24, 2022 at 05:13:43PM +0300, mdw wrote:
> Hi,
> 
> Nicotine+ is a graphical client for the Soulseek peer-to-peer network.
> https://github.com/nicotine-plus/nicotine-plus
> 
> Over a year ago v3.0.0 was submitted to ports@, but didn't get any response
> https://marc.info/?l=openbsd-ports=161310210623977=2
> 
> Here is an updated version 3.2.2, apologies if anything looks funny it is
> my first time working with ports.
> 
> I tested briefly search/chat rooms/transfers on my system running -current
> and it seems to work fine. All of the hard work was done with the original
> submission I just updated a few things.
> 
> Thanks,
> Matthew

Tested on amd64 (July 11th snapshot) and seems to be working fine.
Incidentally I've also been using the mentioned v3.0 port since it came
on the list, without issues.

I'm not experienced enough to formally check the port, so can't comment on
that.  It looks ok on a first look, although I think pkg/PLIST.orig is a
leftover and shouldn't be there.

Thanks for the port
Zé


-- 
 

Re: RStudio: keep in sync with R

[Zé Loff]

On Wed, Jul 13, 2022 at 09:03:32PM +0200, Rafael Sadowski wrote:
> On Tue Jul 12, 2022 at 04:23:22PM +0100, Zé Loff wrote:
> > 
> > Hi Brian
> > 
> > Due to R's bump of libR, RStudio's port needs tweaking.
> > Patch attached.
> > 
> > Thanks
> > Zé
> > 
> > -- 
> >  
> 
> > Index: patches/patch-src_cpp_core_r_util_REnvironmentPosix_cpp
> > ===
> > RCS file: 
> > /cvs/ports/math/rstudio/patches/patch-src_cpp_core_r_util_REnvironmentPosix_cpp,v
> > retrieving revision 1.2
> > diff -u -p -r1.2 patch-src_cpp_core_r_util_REnvironmentPosix_cpp
> > --- patches/patch-src_cpp_core_r_util_REnvironmentPosix_cpp 11 Mar 2022 
> > 19:36:31 -  1.2
> > +++ patches/patch-src_cpp_core_r_util_REnvironmentPosix_cpp 12 Jul 2022 
> > 13:04:35 -
> > @@ -8,7 +8,7 @@ Index: src/cpp/core/r_util/REnvironmentP
> >   #else
> >   
> >  -#define kLibRFileName"libR.so"
> > -+#define kLibRFileName"libR.so.37.0"
> > ++#define kLibRFileName"libR.so.38.0"
> >   #define kLibraryPathEnvVariable  "LD_LIBRARY_PATH"
> >   
> >   FilePath systemDefaultRScript(std::string* pErrMsg)
> 
> With a bump, OK rsadowski. Fun fact, there is a comment for this case in
> the Makefile :)
> 

Yeah, that's how I found out how to unbreak it :)
Silly to forget about the REVISION bump, though.  Thanks!

-- 
 

RStudio: keep in sync with R

[Zé Loff]

Hi Brian

Due to R's bump of libR, RStudio's port needs tweaking.
Patch attached.

Thanks
Zé

-- 
 
Index: patches/patch-src_cpp_core_r_util_REnvironmentPosix_cpp
===
RCS file: 
/cvs/ports/math/rstudio/patches/patch-src_cpp_core_r_util_REnvironmentPosix_cpp,v
retrieving revision 1.2
diff -u -p -r1.2 patch-src_cpp_core_r_util_REnvironmentPosix_cpp
--- patches/patch-src_cpp_core_r_util_REnvironmentPosix_cpp 11 Mar 2022 
19:36:31 -  1.2
+++ patches/patch-src_cpp_core_r_util_REnvironmentPosix_cpp 12 Jul 2022 
13:04:35 -
@@ -8,7 +8,7 @@ Index: src/cpp/core/r_util/REnvironmentP
  #else
  
 -#define kLibRFileName"libR.so"
-+#define kLibRFileName"libR.so.37.0"
++#define kLibRFileName"libR.so.38.0"
  #define kLibraryPathEnvVariable  "LD_LIBRARY_PATH"
  
  FilePath systemDefaultRScript(std::string* pErrMsg)

Re: [new] audio/shairport-sync an AirPlay audio player

[Zé Loff]

On Thu, Dec 09, 2021 at 07:41:29AM -0700, Aaron Bieber wrote:
> Hi,
> 
> Here is a port of shairport-sync. It lets one stream audio from iDevices
> to OpenBSD.
> 
> DESCR snip:
> 
>   Shairport Sync is an AirPlay audio player. It plays audio streamed from
> iTunes, iOS, Apple TV and macOS devices and AirPlay sources such as Quicktime
> Player and ForkedDaapd, among others.
> 
> HOME: https://github.com/mikebrady/shairport-sync
> 
> I have had this in WIP for some time and it has been working without a
> hitch.
> 
> Cluesticks? OK to import?
> 
> Here is the diff for the user db:
> 
> diff 43179bcb078bb95ad600e5d85321b77ec70deb07 /usr/ports
> blob - 17cb166abe6601b51e206bb97d1ce009a2729eac
> file + infrastructure/db/user.list
> --- infrastructure/db/user.list
> +++ infrastructure/db/user.list
> @@ -380,3 +380,4 @@ id  user  group   port
>  869 _headscale   _headscale  net/headscale
>  870 _unit_unit   www/unit
>  871 _gelatod _gelatodnet/gelatod
> +872 _shairport   _shairport  audio/shairport-sync
> 

Hi

Thanks for this.  I've done some basic testing on amd64 -current with
the sndio backend and it seems to work properly, but you already knew
that.

I'd patch the default config to change the default backend from 'alsa'
to 'sndio', but otherwise it looks good.

Cheers
Zé

-- 
 

Re: Please read. Another try at a complex new port. Problems I have and hope against.

[Zé Loff]

On Mon, Dec 13, 2021 at 07:45:26AM -0800, Chris Bennett wrote:
> On Mon, Dec 13, 2021 at 10:05:21AM +0100, Solene Rapenne wrote:
> > Sending new ports is really hazardous, even for people with commit
> > rights. Reviewing a port take time because the OpenBSD project has a
> > high quality standard and it's preferred to correctly work on the ports
> > before they get included.  This is sometimes discouraging, but there are
> > only volunteers here doing reviews on their free time and there are no
> > performance obligation. People review what they use or enjoy, we can't
> > force anyone to review something they don't like. This doesn't mean
> > we shouldn't send new ports, but sometimes, when we send a port, it's
> > either missed or the person who may have interest in it is busy and
> > will forget. That's why a ping can be very useful from time to time.
> > 
> > If you make a port, at least you can use it for yourself before it get
> > included, which is quite useful for keeping your system clean.
> > 
> 
> Except that others are requesting this be ported into OpenBSD for years.
> This is accounting software. It needs to be thoroughly tested or
> companies may fail. SMB stands for small to medium sized businesses.
> 
> As an interesting note. During the 1.2 and 1.3 stages, a long time ago,
> I almost got this into the tree. FreeBSD did. Then both here and at
> FreeBSD, the work was abandoned.
> 
> I see a ton of new ports and updates that never get reviewed. I see many
> posts to this list and other lists about these. They get
> mentioned, but the port is lost.
> I hate to see this work hopelessly lost. So much work for nothing. It
> hurts OpenBSD.
> 
> I have a big proposal. It would require some tough rules to avoid being
> a disaster tree. But it would leave these ports visible.
> 
> Something like this:
> 
> /usr/dirty_ports/ with a category tree in it that only has categories
> with ports inside of them.
> It could only be run by -current.
> The size of the tree would need some method of regulation to not grow
> hopelessly large.
> But the size would show how many ports need reviews and it would let
> someone review ports whenever they have some free time.
> 
> /usr/dirty_ports/devel/myport/review_problems/notes to tell what the
> problems are. Maybe just a ping, maybe what can't be figured out with
> that port or a dependency it needs.
> 
> pkg_add LedgerSMB
> This port is found under /usr/dirty_ports/.
> No packages are ever built for these ports.
> Please help the project and review these ports.
> These ports require running -current.
> You will need to build these ports yourself.
> No support will be provided for systems running these ports as they
> may cause stability and security problems.
> Please add USE_DIRTY_PORTS=Yes to /etc/mk.conf
> 
> This would be good enough for me and extremely satisfying that my work
> isn't lost for all time when I disappear, which also includes unpleasant
> things like death.
> It also means that some people won't wander off into using an OS that
> they don't really want to change to, but supports the software they
> need.
> After a certain time period, these ports could be removed if never
> approved.
> 
> -- 
> Maybe?
> Chris Bennett
> 

Are you aware of https://github.com/jasperla/openbsd-wip?

-- 
 

Re: UPDATE: FFmpeg 4.4.1

[Zé Loff]

On Sun, Oct 24, 2021 at 09:35:11PM -0400, Brad Smith wrote:
> Here is an update to FFmpeg 4.4.1.

Hi Brad

Did you get a chance to look at the patch I sent some days ago fixing
multicasts (attached again)?

Thanks

> 
> Index: Makefile
> ===
> RCS file: /home/cvs/ports/graphics/ffmpeg/Makefile,v
> retrieving revision 1.214
> diff -u -p -u -p -r1.214 Makefile
> --- Makefile  10 Sep 2021 21:47:55 -  1.214
> +++ Makefile  25 Oct 2021 01:17:10 -
> @@ -2,9 +2,8 @@
>  
>  COMMENT= audio/video converter and streamer
>  
> -V=   4.4
> +V=   4.4.1
>  DISTNAME=ffmpeg-${V}
> -REVISION=4
>  EPOCH=   1
>  CATEGORIES=  graphics multimedia
>  MASTER_SITES=https://ffmpeg.org/releases/
> Index: distinfo
> ===
> RCS file: /home/cvs/ports/graphics/ffmpeg/distinfo,v
> retrieving revision 1.62
> diff -u -p -u -p -r1.62 distinfo
> --- distinfo  29 Apr 2021 03:57:54 -  1.62
> +++ distinfo  25 Oct 2021 01:17:44 -
> @@ -1,2 +1,2 @@
> -SHA256 (ffmpeg-4.4.tar.xz) = BrEKGDzlNx+RXGuxW3sf/74EboJ1CZyWr/wp4XZF2Qk=
> -SIZE (ffmpeg-4.4.tar.xz) = 9557868
> +SHA256 (ffmpeg-4.4.1.tar.xz) = 6tutnpqzCyX1Ug+/3pn65KkqGuPAJXqNaFaaRlHjDgI=
> +SIZE (ffmpeg-4.4.1.tar.xz) = 9557516
> Index: patches/patch-configure
> ===
> RCS file: /home/cvs/ports/graphics/ffmpeg/patches/patch-configure,v
> retrieving revision 1.68
> diff -u -p -u -p -r1.68 patch-configure
> --- patches/patch-configure   10 Aug 2021 21:32:07 -  1.68
> +++ patches/patch-configure   25 Sep 2021 08:39:49 -
> @@ -20,7 +20,7 @@ Index: configure
>   fast_clz_if_any="aarch64 alpha avr32 mips ppc x86"
>   fast_unaligned_if_any="aarch64 ppc x86"
>   simd_align_16_if_any="altivec neon sse"
> -@@ -4914,6 +4915,9 @@ case "$arch" in
> +@@ -4915,6 +4916,9 @@ case "$arch" in
>   "Power Macintosh"|ppc*|powerpc*)
>   arch="ppc"
>   ;;
> @@ -30,7 +30,7 @@ Index: configure
>   s390|s390x)
>   arch="s390"
>   ;;
> -@@ -5305,6 +5309,10 @@ case "$arch" in
> +@@ -5306,6 +5310,10 @@ case "$arch" in
>   check_64bit ppc ppc64
>   enabled shared && enable_weak pic
>   ;;
> @@ -41,7 +41,7 @@ Index: configure
>   s390)
>   check_64bit s390 s390x
>   enabled shared && enable_weak pic
> -@@ -5377,7 +5385,6 @@ case $target_os in
> +@@ -5378,7 +5386,6 @@ case $target_os in
>   enable section_data_rel_ro
>   striptype=""
>   SHFLAGS='-shared'
> @@ -49,7 +49,7 @@ Index: configure
>   SLIB_INSTALL_LINKS=
>   oss_indev_extralibs="-lossaudio"
>   oss_outdev_extralibs="-lossaudio"
> -@@ -5733,7 +5740,7 @@ set_default libdir
> +@@ -5734,7 +5741,7 @@ set_default libdir
>   set_default $PATHS_LIST
>   set_default nm
>   
> @@ -58,7 +58,7 @@ Index: configure
>   
>   enable_weak_pic() {
>   disabled pic && return
> -@@ -6649,7 +6656,8 @@ enabled alsa && { check_pkg_config alsa alsa "alsa/aso
> +@@ -6650,7 +6657,8 @@ enabled alsa && { check_pkg_config alsa alsa "alsa/aso
>   enabled libjack &&
>   require_pkg_config libjack jack jack/jack.h jack_port_get_latency_range
>   
> Index: patches/patch-libavutil_cpu_c
> ===
> RCS file: patches/patch-libavutil_cpu_c
> diff -N patches/patch-libavutil_cpu_c
> --- patches/patch-libavutil_cpu_c 29 Apr 2021 03:57:55 -  1.2
> +++ /dev/null 1 Jan 1970 00:00:00 -
> @@ -1,18 +0,0 @@
> -$OpenBSD: patch-libavutil_cpu_c,v 1.2 2021/04/29 03:57:55 rsadowski Exp $
> -
> -Index: libavutil/cpu.c
>  libavutil/cpu.c.orig
> -+++ libavutil/cpu.c
> -@@ -291,6 +291,12 @@ int av_cpu_count(void)
> - DWORD_PTR proc_aff, sys_aff;
> - if (GetProcessAffinityMask(GetCurrentProcess(), _aff, _aff))
> - nb_cpus = av_popcount64(proc_aff);
> -+#elif HAVE_SYSCTL && defined(HW_NCPUONLINE)
> -+int mib[2] = { CTL_HW, HW_NCPUONLINE };
> -+size_t len = sizeof(nb_cpus);
> -+
> -+if (sysctl(mib, 2, _cpus, , NULL, 0) == -1)
> -+nb_cpus = 0;
> - #elif HAVE_SYSCTL && defined(HW_NCPU)
> - int mib[2] = { CTL_HW, HW_NCPU };
> - size_t len = sizeof(nb_cpus);
> 


-- 
 
$OpenBSD$

Index: libavformat/udp.c
--- libavformat/udp.c.orig
+++ libavformat/udp.c
@@ -161,9 +161,10 @@ static const AVClass udplite_context_class = {
 static int udp_set_multicast_ttl(int sockfd, int mcastTTL,
  struct sockaddr *addr)
 {
+  unsigned char mcastTTLc = mcastTTL;
 #ifdef IP_MULTICAST_TTL
 if (addr->sa_family == AF_INET) {
-if (setsockopt(sockfd, IPPROTO_IP, IP_MULTICAST_TTL, , 
sizeof(mcastTTL)) < 0) {
+if (setsockopt(sockfd, IPPROTO_IP, IP_MULTICAST_TTL, , 
sizeof(mcastTTLc)) < 0) {
 ff_log_net_error(NULL, AV_LOG_ERROR, 
"setsockopt(IP_MULTICAST_TTL)");
 

ffmpeg - fix multicast

[Zé Loff]

Hi

The TTL for a multicast data packet has to be an unsigned char, but
ffmpeg uses int:

$ ffmpeg -i https://ftp.openbsd.org/pub/OpenBSD/songs/song69.ogg \
> "udp://239.255.0.1:9000?ttl=10"
(...)
setsockopt(IP_MULTICAST_TTL): Invalid argument
udp://239.255.0.1:9000?ttl=10: Invalid argument

The attached patch fixes this by simply casting the int into a unsigned
char.  Note that I'm not at all a proficient C programmer, nor a porter,
so please take this as a proof of concept of sorts.  There probably is a
more elegant and/or correct solution for this, but hey "it works for
me".

My solution has the obvious issue of int's range being much larger than
u_char's.  ffmpeg blindly accepts values greater than 255 without
throwing an error or a warning, and leaves it to the OS to handle it as
it sees fit (I have no other OS readily available to see what happens
there).  With this patch, and from my limited testing, the value just
gets truncated and wraps around.

I'd argue that if you are trying to multicast with a TTL larger than
255, you are shooting yourself in the foot and probably should get a
better understanding of what you are doing.  Ideally the value would be
checked for correctness, but I think thats a job for someone upstream.

Anyway, here's the patch.  Like I said, I have no experience as a
(proper) porter, nor as a C developer, so I decided not to submit the
whole port, just the patch.

Cheers
Zé

-- 
 
$OpenBSD$

Index: libavformat/udp.c
--- libavformat/udp.c.orig
+++ libavformat/udp.c
@@ -161,9 +161,10 @@ static const AVClass udplite_context_class = {
 static int udp_set_multicast_ttl(int sockfd, int mcastTTL,
  struct sockaddr *addr)
 {
+  unsigned char mcastTTLc = mcastTTL;
 #ifdef IP_MULTICAST_TTL
 if (addr->sa_family == AF_INET) {
-if (setsockopt(sockfd, IPPROTO_IP, IP_MULTICAST_TTL, , 
sizeof(mcastTTL)) < 0) {
+if (setsockopt(sockfd, IPPROTO_IP, IP_MULTICAST_TTL, , 
sizeof(mcastTTLc)) < 0) {
 ff_log_net_error(NULL, AV_LOG_ERROR, 
"setsockopt(IP_MULTICAST_TTL)");
 return ff_neterrno();
 }
@@ -171,7 +172,7 @@ static int udp_set_multicast_ttl(int sockfd, int mcast
 #endif
 #if defined(IPPROTO_IPV6) && defined(IPV6_MULTICAST_HOPS)
 if (addr->sa_family == AF_INET6) {
-if (setsockopt(sockfd, IPPROTO_IPV6, IPV6_MULTICAST_HOPS, , 
sizeof(mcastTTL)) < 0) {
+if (setsockopt(sockfd, IPPROTO_IPV6, IPV6_MULTICAST_HOPS, , 
sizeof(mcastTTLc)) < 0) {
 ff_log_net_error(NULL, AV_LOG_ERROR, 
"setsockopt(IPV6_MULTICAST_HOPS)");
 return ff_neterrno();
 }

Re: to Pandoc or not

[Zé Loff]

On Wed, Jul 15, 2020 at 11:44:32AM +0200, Marc Espie wrote:
> On Wed, Jul 15 '20 at 05.50 NZST, Ingo Schwarze  
> wrote:
> > I never found pandoc useful for anything - so much so that i never
> > even felt a need to evalute its quality for real.  I dimly remember
> > that on rare occasions, i saw man(7) output generated by pandoc,
> > and if i remeber correctly, that was of poor quality - but i'm not
> > sure and it isn't terribly relevant because pandoc is used very
> > rarely in practice in the first place.
> > 
> > What do you want to do with it?
> 
> I have colleagues that use pandoc to produce docs, because it's simple
> and heck, they've normalized on it.
> 
> I myself prefer to generate documents straight from LaTeX, but it means
> I can't directly work with them.
> 
> That's most often the situation.
> 
> I would also like a pandoc port. There are about 80 haskell dependencies for
> it, none of it is in our ports tree yet.
> 

FWIW I've been using pandoc via cabal for quite a while now.  Sure, it's
a bit messy, and I've often ended up having to rm -rf ~/.cabal and
reinstalling everything from scratch, which takes a while, but hey, "it
works for me"(tm).

-- 
 

Re: to Pandoc or not

[Zé Loff]

On Wed, Jul 15, 2020 at 06:07:45PM +1200, Tom Wong-Cornall wrote:
> On Wed, Jul 15 '20 at 05.50 NZST, Ingo Schwarze  
> wrote:
> > I never found pandoc useful for anything - so much so that i never
> > even felt a need to evalute its quality for real.  I dimly remember
> > that on rare occasions, i saw man(7) output generated by pandoc,
> > and if i remeber correctly, that was of poor quality - but i'm not
> > sure and it isn't terribly relevant because pandoc is used very
> > rarely in practice in the first place.
> > 
> > What do you want to do with it?
> 
> As a mutt user, I find pandoc useful to generate HTML mail from a normal 
> plaintext email starting point. Markdown (a valid "from" format for 
> pandoc) is after all essentially just plaintext email "markup", so it's 
> fairly transparent.
> 
> Obviously this might be a rather inflammatory statement in itself, as 
> HTML email is its own special hell for many people, but it's hard to get 
> away from having to send the occasional piece when interacting with the 
> wider world that don't spend their lives like me in an rxvt window.
> 
> There's some nice examples (not mine) here: 
> https://nosubstance.me/post/mutt-secret-sauce/
> 

Would multimarkdown (in ports) be a viable alternative for this?

-- 
 

Re: NEW: math/rstudio

[Zé Loff]

On Sat, Jun 27, 2020 at 01:30:13AM +, Brian Callahan wrote:
> Hi ports --
> 
> Attached is a new port, math/rstudio. RStudio is the IDE for R.

First of all, kudos for the effort.  I tried and gave up quite a few
times before.

> ---
> pkg/DESCR:
> RStudio is an integrated development environment (IDE) for R.
> It includes a console, syntax-highlighting editor that supports direct
> code execution, as well as tools for plotting, history, debugging and
> workspace management.
> ---
> 
> This is a rather big port, and I am not certain that it is ready for
> import just yet. But it is clearly at the point where it needs to be
> shared. Looking for comments and suggestions.
> 
> Some notes/caveats:
> 1. The binary lives as /usr/local/lib/rstudio/bin/rstudio. A simple
> script exists to allow console users easy access.
> 
> 2. There are no precompiled packages other than what comes with the
> IDE. Trying to build some (igraph, notably) exposed some potential
> issues with R--like how R thinks the fortran compiler is named
> gfortran when it should be egfortran.

Enviroment variables for compiling packages can be setup (need to?) in 
~/.R/Makevars.  Maybe this can help with the gfortran issue.

I use clang for most of them, but I have one in my R library (apologies,
I can't remember which) that needs gcc.  This is my ~/.R/Makevars for
compiling with GCC:

# GCC
# Compilers
CC=/usr/local/bin/egcc
CXX=/usr/local/bin/eg++
CXX11=/usr/local/bin/eg++
# Compiler flags
CFLAGS=-Wall -pedantic -O2 -pipe -std=c99 -DHAVE_SYS_SELECT_H -fPIC
CXX11FLAGS=-Wall -pedantic -O2 -pipe -std=c++11 -DHAVE_SYS_SELECT_H -fPIC
CXXFLAGS=-Wall -O2 -pipe

LIB_DIR=/usr/local/lib

And this is for compiling with clang (my default).  A big note about
wxneeded in LDFLAGS: some packages need this during build, and only
during build -- IIRC due to some configure check, without it configure
complains that we're cross-compiling, never took the time to investigate
this properly -- not during runtime.  This means that while building
(which happens in /tmp, by R's default) /tmp must be mounted wxallowed.
Again this is just because of a couple of packages, YMMV and you'll
probably won't need it.  But I digress...  Again, here's ~/.R/Makevars
for clang:

# clang
CC=/usr/bin/clang
CXX=/usr/bin/clang
CXX11=/usr/bin/clang
# Compiler flags
CFLAGS=-Wall -pedantic -O2 -std=c99 -DHAVE_SYS_SELECT_H -fPIC
CXX11FLAGS=-Wall -pedantic -O2 -std=c++11 -DHAVE_SYS_SELECT_H -fPIC
CXXFLAGS=-Wall -pedantic -O2 -DHAVE_SYS_SELECT_H -fPIC

LIB_DIR=/usr/local/lib
LIBS=-lgfortran -lkvm
# Preprocessor flags (C and FORTRAN)
CPPFLAGS=-fPIC -I/usr/include -I/usr/local/include
# Linker flags
LDFLAGS=-L/usr/lib -L/usr/local/lib -lkvm -Wl,-R/usr/local/lib/R/lib,-z,wxneeded


> 3. Fonts don't render in the Plots window. Not sure why. Help
> appreciated.

pango/harfbuzz fallout, probably.  Pango stopped supporting Type 1
fonts.  I have the same issue with R itself.  My solution it to add

  options.X11(family = "DejaVu Sans")

or some other TrueType family.

> 4. I am only a Desktop user but I did provide the Server as well. If
> you use the server I'd be interested in knowing how it works.

The server is basically the same this but with the entire GUI served
over HTTP, and with session control.  When you login you get a new R
session, just like with the desktop, with the added bonus of being able
to leave it running, logout, and come back later to the same session.

I think this is a prime candidate for a -no_x11 flavor, since it would
probably be much lighter and perhaps easier to port, since it won't pull
GUI dependencies (I think), but hey, I'm happy enough with this being
ported as it is.

> 5. There are undoubtedly improvements to be made here, so I'm open to
> whatever comes down the pipeline.
> 
> OK?
> 
> ~Brian



-- 
 

Re: graphics/cairo + math/R font issues

[Zé Loff]

On Sun, Jan 05, 2020 at 10:22:58PM +, Stuart Henderson wrote:
> I can tell you why but not fully how to fix it.
> 
> Newer versions of Pango uses harfbuzz for text shaping, which doesn't
> support type 1 or pcf fonts.
> 
> For things using pcf fonts (this has come up with i3bar users and
> terminus) the fonts want converting to otb (this probably needs a newer
> version of fonttosfnt than we have in xenocara, some commits fixing
> things for this type of conversion were landed there recently,
> though it looks like there may also be a way to do this with
> fontforge).
> 
> In this case though it's type 1 fonts (.pfb files), it's fairly likely
> that you're actually using this font:
> 
> $ fc-match helvetica
> n019003l.pfb: "Nimbus Sans L" "Regular"

Yes, I purposely tested things on a "vanilla" -current VM with nothing
more than pkg_add R, to rule out interactions with other packages and/or
misconfigurations on my machine.

> This is from print/ghostscript/gnu-fonts which is in the dependency
> chain of R so you can't just pkg_delete it.
> 
> As a dirty workaround you can move the pfb files out of
> /usr/local/share/fonts/ghostscript and I expect that will get it working
> for you. Unsure about a better fix though, maybe a fontconfig wizard
> will read this and step in with some clues :-)

Thanks for the workaround.  Personally, I find it easier to change the
default font.  I posted the message as more of a 'heads up' that things
weren't working quite right out-of-the-box, and someone else might
stumble on this.

Although changing the default font can be easily done -- adding a
default site-wide configuration file could be a possible workaround to
make the port work properly again -- this appears not to be the case
with the math/greek symbols font, which seems to be harder to replace,
so just changing fonts isn't a proper fix.

However, all works properly if R is instructed to forget about cairo and
just use the "Xlib" device as a default (as is done on macOS, precisely
due to issues with pango).  Ingo: do you think we should patch the port
to do this, until the pango/type 1 issues are solvable?


(incidentally, fontforge also has the same problem, there is plenty of
UI text that doesn't render properly)


> On 2020/01/05 17:05, Zé Loff wrote:
> > 
> > Hi all
> > 
> > On -current (#562), R's X11cairo device doesn't render the default font
> > properly, I get the "hex number inside a square" characters, instead,
> > e.g.:
> > 
> >   > plot(density(rnorm(1000)))
> > 
> > According to X11.options(), the default fonts are -adobe-helvetica and
> > -adobe-symbol-medium:
> > 
> >   > X11.options()$fonts
> >   [1] "-adobe-helvetica-%s-%s-*-*-%d-*-*-*-*-*-*-*"
> >   [2] "-adobe-symbol-medium-r-*-*-%d-*-*-*-*-*-*-*"
> > 
> > which are properly rendered by xfontsel, so I think this is strictly
> > Cairo-related.
> >   
> > If the device is initialized with a different font, all text is properly
> > rendered:
> > 
> >   > dev.new(family = 'DejaVu Sans')
> >   > plot(density(rnorm(1000))
> > 
> > The pdf() device also seems to work properly (with its default font) i.e.
> > 
> >  > pdf()
> >  > plot(density(rnorm(1000))
> >  > dev.off()
> > 
> > produces a PDF which is rendered properly by mupdf on the same machine.
> > 
> > 
> > 
> > -- 
> >  
> > 
> 

-- 
 

graphics/cairo + math/R font issues

[Zé Loff]

Hi all

On -current (#562), R's X11cairo device doesn't render the default font
properly, I get the "hex number inside a square" characters, instead,
e.g.:

  > plot(density(rnorm(1000)))

According to X11.options(), the default fonts are -adobe-helvetica and
-adobe-symbol-medium:

  > X11.options()$fonts
  [1] "-adobe-helvetica-%s-%s-*-*-%d-*-*-*-*-*-*-*"
  [2] "-adobe-symbol-medium-r-*-*-%d-*-*-*-*-*-*-*"

which are properly rendered by xfontsel, so I think this is strictly
Cairo-related.
  
If the device is initialized with a different font, all text is properly
rendered:

  > dev.new(family = 'DejaVu Sans')
  > plot(density(rnorm(1000))

The pdf() device also seems to work properly (with its default font) i.e.

 > pdf()
 > plot(density(rnorm(1000))
 > dev.off()

produces a PDF which is rendered properly by mupdf on the same machine.



-- 
 

Re: UPDATE: TeX Live 2016

[Zé Loff]

> On 17/05/2017, at 11:41, Giovanni Bechis  wrote:
> 
>> On 05/17/17 12:16, Paul Irofti wrote:
>>> On Wed, May 17, 2017 at 10:26:19AM +0100, Edd Barrett wrote:
 On Wed, May 17, 2017 at 12:16:46PM +0300, Paul Irofti wrote:
 This seems to work as at least the gigantous distfile is downloading
 now :) Thanks!
>>> 
>>> Great. Thanks Stuart.
>>> 
>>> Let me know how you get on Paul. This really needs to go in soon.

FWIW I managed to build it yesterday (on amd64) and it all went fine. To be 
totally honest I didn't pay much attention to the logs, so I can't completely 
vouch for the correctness of the port, but again, all packages were built and 
I've been using them without issues.

>> Not good. It seems the transfer started but it stalled and got
>> disconnected later on. Will so how things turn out as it is trying the
>> next mirror now.
> try adding "https://paclan.it/distfiles/texlive-20160523b-texmf.tar.xz; as 
> [my] mirror.
> Cheers
>  Giovanni
> 

Re: UPDATE: math/R

[Zé Loff]

On Wed, Mar 08, 2017 at 04:34:47PM +0100, Ingo Feinerer wrote:
> Dear useRs,
> 
> update math/R 3.3.2 -> 3.3.3
> 
> - The zlib configure version test logic changed so adapt.
> - Several R packages (e.g. RCpp) profit from a C++11 compiler, so
>   mention CXX1X et al. in the README.
> - make package reports
>   LIB_DEPENDS devel/libidn not needed for math/R ?
>   I am not sure if this is true or not (or what triggered the change).
> 
> OK?
> 
> Best regards,
> Ingo

Hi Ingo (and list)

As I mentioned in our private conversation, I've been having some issues
with some R packages and W^X.  I've been meaning to look at it more
systematically and do a nice write-up for ports@ but haven't had the
time yet.  However, this seemed like a good time to bring the issue to
the list.

What I noticed so far is:

- Some packages need W^X (e.g. rJava and V8) to run.  If you end up
  needing those packages I *think* R needs to be flagged as WX_NEEDED,
  since they run "inside" R.  Not sure if its worth it to flag R only
  because of optional packages, though.

- If you install those packages on a user library instead of on the
  system-wide library, you'll need to mount /home (or wherever your
  library is) as wxallowed.

- At compile time, some packages run tests with W^X code in them.  This
  means "configure" will fail, since it detects that binaries can't be
  run (for instance it asks if we're cross-compiling).  Since packages
  are unpacked and compiled in /tmp, this means that at least during
  compilation /tmp also needs to be mounted as wxallowed.

As I told you before, I don't know what the correct approach here would
be, but I believe at least a pkg-readme or a install-message would help.

Let me know if I can help and sorry for the messy reporting.

Cheers
Zé


> Index: Makefile
> ===
> RCS file: /cvs/ports/math/R/Makefile,v
> retrieving revision 1.89
> diff -u -p -r1.89 Makefile
> --- Makefile  4 Nov 2016 11:35:19 -  1.89
> +++ Makefile  8 Mar 2017 15:28:29 -
> @@ -1,8 +1,7 @@
>  # $OpenBSD: Makefile,v 1.89 2016/11/04 11:35:19 sthen Exp $
>  
>  COMMENT=  powerful math/statistics/graphics language
> -DISTNAME=  R-3.3.2
> -REVISION=  0
> +DISTNAME=  R-3.3.3
>  
>  SO_VERSION=  32.0
>  .for _lib in R Rblas Rlapack
> Index: distinfo
> ===
> RCS file: /cvs/ports/math/R/distinfo,v
> retrieving revision 1.32
> diff -u -p -r1.32 distinfo
> --- distinfo  1 Nov 2016 16:55:13 -  1.32
> +++ distinfo  8 Mar 2017 15:28:29 -
> @@ -1,2 +1,2 @@
> -SHA256 (R-3.3.2.tar.gz) = 0pStIen1dPtIKOuzqUuMs09PMEpBaHqZS+AN1BpOUUw=
> -SIZE (R-3.3.2.tar.gz) = 29440670
> +SHA256 (R-3.3.3.tar.gz) = WrdoBTonUIRhj7ZptPuq3MORWJmKh+hGUyOClZC8/Gw=
> +SIZE (R-3.3.3.tar.gz) = 29804326
> Index: patches/patch-configure
> ===
> RCS file: /cvs/ports/math/R/patches/patch-configure,v
> retrieving revision 1.29
> diff -u -p -r1.29 patch-configure
> --- patches/patch-configure  1 Nov 2016 16:55:13 -  1.29
> +++ patches/patch-configure  8 Mar 2017 15:28:29 -
> @@ -1,7 +1,7 @@
>  $OpenBSD: patch-configure,v 1.29 2016/11/01 16:55:13 feinerer Exp $
>  
>  configure.orig  Mon Oct 24 13:34:26 2016
> -+++ configure  Tue Nov  1 09:06:08 2016
> +--- configure.orig  Tue Mar  7 13:02:27 2017
>  configure  Tue Mar  7 13:03:01 2017
>  @@ -35492,8 +35492,8 @@ fi
>   
>   fi
> @@ -13,12 +13,12 @@ $OpenBSD: patch-configure,v 1.29 2016/11
>   if ${r_cv_header_zlib_h+:} false; then :
> $as_echo_n "(cached) " >&6
>   else
> -@@ -35510,7 +35510,7 @@ int main() {
> - #ifdef ZLIB_VERSION
> - /* Work around Debian bug: it uses 1.2.3.4 even though there was no such
> -version on the master site zlib.net */
> --  exit(strncmp(ZLIB_VERSION, "1.2.5", 5) < 0);
> -+  exit(strncmp(ZLIB_VERSION, "1.2.3", 5) < 0);
> - #else
> -   exit(1);
> - #endif
> +@@ -35508,7 +35508,7 @@ else
> + #include 
> + int main() {
> + #ifdef ZLIB_VERNUM
> +-  if (ZLIB_VERNUM < 0x1250) {
> ++  if (ZLIB_VERNUM < 0x1230) {
> + exit(1);
> +   }
> +   exit(0);
> Index: pkg/PLIST
> ===
> RCS file: /cvs/ports/math/R/pkg/PLIST,v
> retrieving revision 1.32
> diff -u -p -r1.32 PLIST
> --- pkg/PLIST  1 Nov 2016 16:55:13 -  1.32
> +++ pkg/PLIST  8 Mar 2017 15:28:30 -
> @@ -1358,6 +1358,9 @@ lib/R/library/survival/doc/compete.R
>  lib/R/library/survival/doc/compete.Rnw
>  lib/R/library/survival/doc/compete.pdf
>  lib/R/library/survival/doc/index.html
> +lib/R/library/survival/doc/multi.R
> +lib/R/library/survival/doc/multi.Rnw
> +lib/R/library/survival/doc/multi.pdf
>  lib/R/library/survival/doc/splines.R
>  lib/R/library/survival/doc/splines.Rnw
>  lib/R/library/survival/doc/splines.pdf
> Index: pkg/README
> ===
> RCS file: /cvs/ports/math/R/pkg/README,v
> 

Re: Collision between libgfortran and gcc-libs

[Zé Loff]

On Wed, Jul 13, 2016 at 08:55:24PM +1200, m...@extensibl.com wrote:
> On Wed, 13 Jul 2016 08:59:49 +0100
> Zé Loff <zel...@zeloff.org> wrote:
> 
> > Not true, I just installed it without having lang/gfortran installed.
> 
> While spatstat does not depend directly on gfortran, its dependency,
> deldir, does. Did you compile deldir with g77? I think gfortran could
> be removed then.

Incidentally it was with g95 (I needed GCC 4.9 to compile some other
R packages) but yes, deldir was also installed as a dependency without
lang/gfortran.

Cheers
Zé

-- 

Re: Collision between libgfortran and gcc-libs

[Zé Loff]

On Wed, Jul 13, 2016 at 11:26:46AM +1200, m...@extensibl.com wrote:
> On Tue, Jul 12, 2016 at 07:37:52PM +0200, David Coppa wrote:
> > 
> > +1 for nuking it from me too.
> > 
> > Ciao!
> > David
> > 
> > 
> I believe that spatstat module in R requires lang/gfortran to compile. Some 
> other useful modules depend on spatstat, e.g. radiomics.
>
> Please do not delete lang/gfortran, I am interested to fix it, if possible.

Not true, I just installed it without having lang/gfortran installed.

> Thanks,
> Alex
> 

-- 

Re: UPDATE: math/R

[Zé Loff]

Hi all

First and foremost thanks and praises to Ingo for all the hard work
patching R and the guts for trying to push patches upstream (people who
complain about Theo's manners clearly never had to deal with Brian
Ripley).

On Tue, Apr 21, 2015 at 06:13:15PM +0200, Ingo Feinerer wrote:
 On Tue, Apr 21, 2015 at 08:12:56AM +0200, Rafael Sadowski wrote:
   - Add devel/libidn and net/curl in LIB_DEPENDS
 (based on make port-lib-depends-check)
 and adapt WANTLIB accordingly
  
  okay for curl, but it's not set as default option true.
 
 As far as I see there is no explicit configure option to enable/disable
 it. If curl is there, it picks it up. So I added it to WANTLIB and
 LIB_DEPENDS.

I don't think curl is a strict dependency, at least not at runtime. R
Installation and administration manual states that

  libcurl version 7.28.0 or later can be used to support curlGetHeaders
  and the libcurl methods of download.file and url.

but the help page for download.file says

   For methods ‘wget’, ‘curl’ and ‘lynx’ a system call is made
 to the tool given by ‘method’, and the respective program must be
 installed on your system and be in the search path for executables.
 They will block all other activity on the R process until they
 complete: this may make a GUI unresponsive.

and

Method ‘wget’ is mainly for historical compatibility, but it and
‘curl’ can be used for URLs (e.g., ‘https://’ URLs or those that use
cookies) which the internal method does not support.


So I'm guessing its something R likes to have around for the
aforementioned methods of download.file and url, but not exactly
essential...

 idn is needed by
 
 R-3.2.0(math/R):
 Missing: idn.17 from libidn-1.30 (/usr/local/lib/R/modules/internet.so)
 WANTLIB += idn
 
 so I added it as well.
 
   - Avoid setting ac_cv_path_TAR as it works without
  
  Are your sure, R pick up gtar?
 
 I am pretty confident. The configure script checks for ${TAR} gtar
 gnutar tar in that order. Since we do not set $TAR, gtar is found (as
 we have it in BUILD_DEPENDS) and used.
 
   Remarks:
   
   - I have
   
 LDFLAGS=-L/usr/local/lib
 CFLAGS=-I/usr/local/include
   
 in my .R/Makevars. This is very useful if you install packages which
 need to compile some C code at installation. Should this info be
 included in pkg/README?
  
  I think it's a good advice.
 
 I added a corresponding statement to pkg/README (based on
 http://cran.r-project.org/doc/manuals/r-devel/R-admin.html#Customizing-package-compilation)
 
   - Moreover, I am willing to take MAINTAINERship just in case Rafael
 Sadowski is no longer interested. I plan to provide updates in the
 future as well as I need a current R version for my work/research.
   
  
  I'm interested but I think you're the better men for this port. You're
  closer to the R community and (more or less) a daily R user on OpenBSD.
  I will not stand in the way.
 
 Thanks. On your approval I changed the MAINTAINER line as well. Future
 updates will be posted to ports@ anyway, so you will be kept up-to-date
 if something relevant happens.
 
 Now to Vadim's comments:
 
  I see SHARED_LIBS minor bumped twice: 3.0 = 3.2. This should be 3.1
  instead.
 
 Fixed. (The idea was to resemble that the R version is 3.2.)
 
  Given that there were problems in that area previously (PIC related),
  I think this update worths trying on i386 before going in. If noone
  could do that, I'll try do in the next few days.
 
  If build will go smoothly, I'll commit the update (with SHARED_LIBS
  tweak mentioned above).
 
 That would be great!
 
 Best regards,
 Ingo
 
 Index: Makefile
 ===
 RCS file: /cvs/ports/math/R/Makefile,v
 retrieving revision 1.68
 diff -u -p -u -p -r1.68 Makefile
 --- Makefile  13 Apr 2015 10:41:13 -  1.68
 +++ Makefile  21 Apr 2015 15:55:29 -
 @@ -3,42 +3,38 @@
  SHARED_ONLY= Yes
  
  COMMENT= powerful math/statistics/graphics language
 -DISTNAME=R-3.1.3
 -REVISION=1
 +DISTNAME=R-3.2.0
  
 -SHARED_LIBS= R   3.0
 +SHARED_LIBS= R   3.1
  SHARED_LIBS+=Rlapack 31.2# 31.2
  SHARED_LIBS+=Rblas   31.2# 31.2
  
  CATEGORIES=  math
  HOMEPAGE=http://www.r-project.org/
  
 -MAINTAINER=  Rafael Sadowski raf...@sizeofvoid.org
 +MAINTAINER=  Ingo Feinerer feine...@logic.at
  
  # GPL
  PERMIT_PACKAGE_CDROM=Yes
  
 -WANTLIB= ICE SM X11 Xext Xmu Xss Xt bz2 c cairo \
 - ereadline fontconfig freetype glib-2.0 \
 - gobject-2.0 icui18n icuuc jpeg lzma m \
 +WANTLIB= ICE SM X11 Xext Xmu Xss Xt bz2 c crypto curl \
 + cairo ereadline fontconfig freetype glib-2.0 \
 + gobject-2.0 icui18n icuuc idn jpeg lzma m \
   ncurses pango-1.0 pangocairo-1.0 \
 - pangoft2-1.0 pcre png pthread tiff z \
 + pangoft2-1.0 pcre png pthread ssl tiff z \

Re: Update: mail/isync

[Zé Loff]

On Wed, Apr 01, 2015 at 01:20:49PM -0300, Gleydson Soares wrote:
 could you try to reproduce again?
 isync doesn't segs here. (@amd64)

mbsync (not this version though, the one on amd64 -current) segfaults
every time it can't resolve the server name, and has been doing so for a
while now. I've been meaning to report it for a while now, but never
bothered / got the time to address it properly. Maybe that's what
Dmitrij is seeing.

 
 On Wed, Apr 1, 2015 at 12:59 PM, Edd Barrett vex...@gmail.com wrote:
  On Mon, Mar 30, 2015 at 12:55:33PM +0200, Dmitrij D. Czarkoff wrote:
  Any test reports?
 
  I've been using this for a while (mbsync at least).
 
  I notice that the isync command segs. Not looked into it, but I have no
  .isyncrc file (only a .mbsyncrc), so that may be why.
 
  --
  Best Regards
  Edd Barrett
 
  http://www.theunixzoo.co.uk
 
 
 
 
 -- 
 O ascii ribbon campaign - stop html mail - www.asciiribbon.org
 

-- 

Re: R and cran

[Zé Loff]

On Wed, Dec 24, 2014 at 12:37:08AM +0100, frantisek holop wrote:
 frantisek holop, 23 Dec 2014 23:55:
  ok, i have found
  
  $ R CMD INSTALL --help
 
 and there is also
 
 R CMD build
 and
 R CMD INSTALL
 
 i managed to install lpSolve:
 
 get the R package 'lpSolve_5.6.10.tar.gz', and extract.
 patch some files (remove sys/timeb.h)
 $ R CMD build lpSolve
 and install the resulting package
 R CMD INSTALL lpSolve_5.6.10.tar.gz
 
 hope this helps someone.
 
 -f
 -- 
 to my embarrassment, i was born in bed with a lady!
 

Hi frantisek

You solved it already, but just for the record, you can put a Makevars
file on your ~/.R folder to help with some of these kind of problems,
e.g.

$ cat .R/Makevars

CXXFLAGS=-Wall -pedantic
LDFLAGS=-L/usr/local/lib
CFLAGS=-I/usr/local/include

See
http://cran.r-project.org/doc/manuals/r-release/R-admin.html#Customizing-package-compilation

Cheers
Zé

-- 

Re: Reference / citation managers for OBSD?

[Zé Loff]

 On 06/08/2014, at 07:13, Michael L. Wilson michael.l.wil...@utu.fi wrote:
 
 Dear OpenBSD users,
 
 I've just acquired a Thinkpad x200 with the aim of transitioning into a 
 full-time OpenBSD user. The 5.5 release with the Xfce desktop works 
 flawlessly and I am very happy with this system.
 
 Nearly all of my software needs have been quite satisfactorily met using the 
 available packages. However, one minor niggle remains. I cannot seem to find 
 a suitable reference/citation manager for academic work.
 
 I am very fond of Zotero, but Firefox on OpenBSD seems to have issues with 
 the Zotero plugin. The browser will not relaunch after it has been installed. 
 Thus I am unable to use either Firefox or Zotero until the Zotero plugin is 
 removed. I cannot either compile FireFox from ports due to space limitations 
 on the current drive. Just for kicks I tried Zotero in a fresh install of 
 FreeBSD and it does not have this issue.
 
 I am aware that the problem appears to be more widespread: 
 forums.zotero.org/discussion/32183?page=1#Item_12
 
 None of the options listed on the Zotero forum worked for me. I even tried an 
 online hack to get the Zotero plugin working in Seamonkey without success.
 
 Jabref, the other alternative, is not available in the OpenBSD repository or 
 in ports.
 
 Ideally I would like a program that works well with LibreOffice. I have no 
 qualms about learning something completely new until the Zotero issue is 
 fixed. I am willing to wait patiently for a fix but in the meantime I need 
 something to use. I would even be willing to explore a proprietary option as 
 a last resort.
 
 Any tips or suggestions would be very appreciated! I am willing to put in the 
 time and effort to get this working so any suggestions will be taken very 
 seriously. 

I've been using JabRef for a couple of years (not with LibreOffice, though, 
just LaTeX). Just download the .jar file and run it with java -jar 

wxMaxima can't start maxima

[Zé Loff]

Hi

I was trying to use wxMaxima (-current, amd64) and it fails to start
(and connect to) maxima. Actually it fails to start it, as no 'maxima'
process is created. I also tried starting xmaxima (the only way I could
find to start maxima as a server) and then running wxMaxima listening on
the same port, but it also won't connect. maxima and xmaxima work
perfectly.

Is this a known problem? How can I help further (caveat: all I know
about lisp is that apparently it involves a lot of parenthesis)?

All the best
Zé

Anyone working on pandoc?

[Zé Loff]

Hi all

Has anyone tried / started to port pandoc, or knows of any good reason
not to? I'd like to give it a shot, but I don't want do duplicate
efforts...

Cheers
Zé

-- 

Re: Anyone working on pandoc?

[Zé Loff]

On Thu, Jun 19, 2014 at 10:22:17AM -0400, Ian Darwin wrote:
 On 2014-06-19, 9:42 AM, Zé Loff wrote:
 Hi all
 
 Has anyone tried / started to port pandoc, or knows of any good reason
 not to? I'd like to give it a shot, but I don't want do duplicate
 efforts...
 
 
 Yes, I have it mostly done (a dozen or so new dependencies, of course), but
 it's on hold waiting for the annual churnover of Haskell GHC port.

Nice, thanks. Let me know if I can help.

Cheers
Zé

-- 

elinks creates file whose name is the contents of elinks.conf

[Zé Loff]

I know, that subject's line is too long, but I didn't manage to phrase
that in a shorter form. On the upside, it pretty much tells the whole
story: elinks is creating a file on ~ whose name is the contents of
~/elinks/elinks.conf.

  $ cat .elinks/elinks.conf
  set document.colors.use_document_colors = 1
  set terminal.xterm-256color.colors = 1
  set terminal.xterm-256color.transparency = 1
  set terminal.xterm-256color.underline = 1
  set terminal.xterm-256color.utf_8_io = 1

  $ ls ~/set*
  ls: /home/zeloff/set*: No such file or directory

  $ elinks -dump 1 /dev/null
  ELinks: Unknown file type

  $ ls ~/set*
  /home/zeloff/set document.colors.use_document_colors = 1?set
  terminal.xterm-256color.colors = 1?set
  terminal.xterm-256color.transparency = 1?set
  terminal.xterm-256color.underline = 1?set
  terminal.xterm-256color.utf_8_io = 1?H
  
  $ elinks --version
  ELinks 0.11.7 (built on May 14 2014 14:33:00)
  
  Features:
Standard, No Backtrace, IPv6, gzip, bzip2, Periodic Saving, Timer,
Cascading Style Sheets, Protocol (File, FTP, Gopher, HTTP, URI
rewrite, User protocols), SSL (OpenSSL), MIME (Option system, Mailcap,
Mimetypes files), LED indicators, Bookmarks, Cookies, Form History,
Global History, Goto URL History, Search History

  $ uname -mrsv
OpenBSD 5.5 GENERIC.MP#138 amd64

-- 

Re: UPDATE: math/R 3.0.3 - 3.1.0

[Zé Loff]

On Thu, May 15, 2014 at 06:41:56PM +0200, Rafael Sadowski wrote:
 On Sun May 04, 2014 at 01:40:22PM +0200, Rafael Sadowski wrote:
  On Fri May 02, 2014 at 11:03:29PM +0200, Rafael Sadowski wrote:
   Hi @ports and R-users,
   
   attached is an maintainer-update for mathe/R. All test pass @amd64.
   
   - Update  3.0.3 = 3.1.0
   - SHARED_LIBS-syntax, okay?
   
   Comments? OKs? 
   
   cheers, Rafael
   
   
@exec %D/bin/mktexlsr  /dev/null 21
   -@unexec-delete %D/bin/mktexlsr  /dev/null 21
   +@unexec-delete %D/bin/mktexlsr  /dev/null 2
   
   ups, this is wrong.
 
 okay, heads up, correct and 100% working (all tests pass) R ports
 update.
 
 comments? okays? commit it, please!

Sorry for coming late to the show, but I just realised that the X11cairo
plotting device is not working properly on R 3.0.3, running on amd64
-current. To be more specific, parts of the plot aren't immediately
drawn when the device comes up or when resizing the plot's window.

Can anyone reproduce this?

Cheers
Zé

-- 

Re: Coddling bloated web browsers, etc (or how far does kern.shminfo.shmall= usefully go?)

[Zé Loff]

On Mon, Mar 10, 2014 at 09:26:46PM +0100, Peter N. M. Hansteen wrote:
 On my laptop (a 2009-vintage Thinkpad SL500), I'd been noticing that
 some applications have been steadily gaining weight, such as popular
 web browsers (chome, firefox) but also (x)emacs with largish maildirs
 in gnus have become ever more sluggish.
 
 So after I finally sent off enough material to have a bit of time to
 investigate not directly network-related stuff, I found some old notes
 which I think is from the chromium pkg-message:
 
 --- 
 You may need to crank shared memory limits for chromium to work
 properly under load:
 
 # sysctl kern.shminfo.shmall=32768
 
 Your default datasize might not be enough for v8 so make sure it
 is more than 512M, so try to set it to 715M by doing:
 
 $ ulimit -d 716800
 
 or modify /etc/login.conf.
 ---
 
 I already had kern.shminfo.shmall=32768 set in my sysctl.conf, so at
 first I did a bit of web searching, and came up with this stanza in
 login.conf that appeared to help matters a bit:
 
 staff:\
 :datasize-cur=infinity:\
 :datasize-max=infinity:\
 :datasize=infinity:\
 :openfiles-cur=1024:\
 :stacksize-cur=16M:\
 :maxproc-max=512:\
 :maxproc-cur=512:\
 :ignorenologin:\
 :requirehome@:\
 :tc=default:
 
 (the infinity values came from a google site, I forget which but I can
 probably find it again).

Caveat emptor: I got badly burned once setting datasize-max to
infinity... Once one process required more memory than what was
physically available swapping kicked in and the whole system started
crawling to the point of dropping network connections and taking a few
minutes to switch virtual consoles[1].

[1] http://marc.info/?t=13869384211

Cheers
Zé

-- 

Re: csplain expects UTF8 now

[Zé Loff]

On Mon, Feb 03, 2014 at 11:46:53AM +0100, Jan Stary wrote:
 After an upgrade of TexLive to 
 
 texlive_base-2013p0 base binaries for TeXLive typesetting distribution
 texlive_texmf-buildset-2013p1 smallest texlive texmf for building ports
 texlive_texmf-minimal-2013p0 texlive texmf for basic functionality
 
 I can no longer compile my TeX files written in Czech using Latin2:
 
 $ pdfcsplain test1a.tex
 This is pdfTeX, Version 3.1415926-2.5-1.40.14 (TeX Live 2013-OpenBSD_Ports)
  restricted \write18 enabled.
 entering extended mode
  encTeX v. Jun. 2004, reencoding enabled.
 (./test1a.tex The format: csplain Jan. 2013.
 The cs-fonts are preloaded and A4 size implicitly defined.
 The utf8-iso8859-2 re-encoding of Czech+Slovak alphabet activated by encTeX
 ! UTF-8 INPUT IS CORRUPTED !  May be you are using another input encoding.
 \badutfinput ... are using another input encoding}
 
 \warnthreebytes ...se \ifnum `#2128 \badutfinput
 \else \missingutfchar {\ex...
 l.14 Popite podrobn v
   echny sv kroky a vahy.
 ? ^D
 ! Emergency stop.
 \badutfinput ... are using another input encoding}
 
 \warnthreebytes ...se \ifnum `#2128 \badutfinput
 \else \missingutfchar {\ex...
 l.14 Popite podrobn v
   echny sv kroky a vahy.
 !  == Fatal error occurred, no output PDF file produced!
 Transcript written on test1a.log.
 
 
 What is a good way to tell TexLive to expecct Latin2 as before?
 Or do I need to say that in every file?
 Or do I need to have my files in UTF?
 
   Jan
 

I think you really should be asking this elsewhere. This very much looks
like some tex package or compiler changed its behaviour and you'll need
to take some extra steps to make it work. I think in a project the size
of TeXLive its unrealistic to expect the port maintainer to do more than
make sure things get properly unpacked and installed, but I'll leave
that for the maintainer to clarify. In the meantime you might check the
docs on CTAN or tex.stackexchange.com, maybe something will turn up...

That being said, in the past I've had to get some packages directly from
CTAN and install them on my local ~/texmf, since the version packed in
TeXLive had some bugs that had been corrected in the meantime.

Answering more directly to your question, the only way I know of
specifying encodings on TeX is using the 'inputenc' packages (e.g.
\usepackage[latin2]{inputenc} on the document's preamble). And you can
always use iconv to convert the tex files (e.g. iconv -f latin2 -t UTF-8
 test1a.tex  test1a_utf8.tex). Personally, I just switched to xelatex,
started using UTF-8 for everything and never looked back.

Cheers
Zé

Re: sysutils/collectd update request

[Zé Loff]

On Fri, Jul 26, 2013 at 11:32:12AM -0700, Zach Leslie wrote:
 Why does the ports tree get locked, and is there an expected time frame
 around the unlock?

http://openbsd.org/papers/asiabsdcon2009-release_engineering/

-- 

Re: x11/dwm cursor patch

[Zé Loff]

On Sun, Jun 09, 2013 at 03:44:13PM +0200, Joerg Jung wrote:
 Hi,
 
 please find below a simple diff to add cursors keys to x11/dwm.
 Objections? OKs?
 
 Regards,
 Joerg

Since this isn't on the upstream code, and since dwm is meant to be
configured/customized by editing config.def.h (and built/installed from
source, instead of installed as a binary), I'd say this falls into the
'customisation' category, and shouldn't be here.

 Index: Makefile
 ===
 RCS file: /cvs/ports/x11/dwm/Makefile,v
 retrieving revision 1.24
 diff -u -p -r1.24 Makefile
 --- Makefile  11 Mar 2013 11:46:09 -  1.24
 +++ Makefile  9 Jun 2013 13:35:54 -
 @@ -3,6 +3,7 @@
  COMMENT= dynamic window manager
  
  DISTNAME=dwm-6.0
 +REVISION=0
  
  CATEGORIES=  x11
  
 Index: patches/patch-config_def_h
 ===
 RCS file: /cvs/ports/x11/dwm/patches/patch-config_def_h,v
 retrieving revision 1.9
 diff -u -p -r1.9 patch-config_def_h
 --- patches/patch-config_def_h9 Jul 2012 16:33:40 -   1.9
 +++ patches/patch-config_def_h9 Jun 2013 13:35:54 -
 @@ -1,6 +1,6 @@
  $OpenBSD: patch-config_def_h,v 1.9 2012/07/09 16:33:40 zinke Exp $
  --- config.def.h.origMon Dec 19 16:02:46 2011
 -+++ config.def.h Sat Jul  7 22:28:18 2012
  config.def.h Sun Jun  2 13:03:39 2013
  @@ -1,13 +1,13 @@
   /* See LICENSE file for copyright and license details. */
   
 @@ -40,3 +40,19 @@ $OpenBSD: patch-config_def_h,v 1.9 2012/
   
   static Key keys[] = {
   /* modifier keyfunctionargument */
 +@@ -55,11 +57,15 @@ static Key keys[] = {
 + { MODKEY|ShiftMask, XK_Return, spawn,  {.v = 
 termcmd } },
 + { MODKEY,   XK_b,  togglebar,  {0} },
 + { MODKEY,   XK_j,  focusstack, {.i = +1 } },
 ++{ MODKEY,   XK_Down,   focusstack, {.i = +1 } },
 + { MODKEY,   XK_k,  focusstack, {.i = -1 } },
 ++{ MODKEY,   XK_Up, focusstack, {.i = -1 } },
 + { MODKEY,   XK_i,  incnmaster, {.i = +1 } },
 + { MODKEY,   XK_d,  incnmaster, {.i = -1 } },
 + { MODKEY,   XK_h,  setmfact,   {.f = -0.05} 
 },
 ++{ MODKEY,   XK_Left,   setmfact,   {.f = -0.05} 
 },
 + { MODKEY,   XK_l,  setmfact,   {.f = +0.05} 
 },
 ++{ MODKEY,   XK_Right,  setmfact,   {.f = +0.05} 
 },
 + { MODKEY,   XK_Return, zoom,   {0} },
 + { MODKEY,   XK_Tab,view,   {0} },
 + { MODKEY|ShiftMask, XK_c,  killclient, {0} },
 

-- 

Re: x11/dwm cursor patch

[Zé Loff]

On 09/06/2013, at 18:34, Joerg Jung m...@umaxx.net wrote:

 Den 9. juni 2013 kl. 17:07 skrev Zé Loff zel...@zeloff.org:
 
 please find below a simple diff to add cursors keys to x11/dwm.
 Objections? OKs?
 
 Since this isn't on the upstream code,
 
 ... and probably never will be.
 
 and since dwm is meant to be
 configured/customized by editing config.def.h
 
 This is what the patch does.
 
 (and built/installed from
 source,
 
 This is what the port does.
 
 instead of installed as a binary),
 
 So, you want to drop the package,
 because everyone is supposed
 to compile dwm on their own?

No. I'm saying that packages/ports should follow upstream code as much as 
possible, and the reasons for that should be pretty obvious.

I also think dwm is a bit atypical in its lack of post-compilation 
configuration, so maybe distributing it as a binary doesn't make much sense (I 
use dwm, but I'll never use the package for that very same reason). What really 
doesn't make sense is customizing the binary for your personal convenience.

 I'd say this falls into the
 'customisation' category, and shouldn't be here.
 
 We already have several of such 
 'customizations' in various ports.
 Sometimes upstream defaults 
 are not very useful.

IMHO patches on ports should be used to ensure that code compiles/runs/hasn't 
security issues, not to add (personal) convenience functions.
If that is the case, I made a bunch of additions to config.def.h that I'd like 
to add too. And I bet a lot of dwm users will say the same.