Re: colortail crash and fix

[Ted Unangst]

Robert Nagy wrote:
> Hey,
> 
> Can you guys try this diff?

oh, fun, upstream fixed it a different way. i don't have a full ports tree on
this laptop, but the new code looks like it could work.


 // set filename in options class
string str = filename.str();
 char* cs = new char[str.length()+1];
std::strcpy(cs, str.c_str());

o->cfg_filenames[o->nr_cfg_files] = cs;

 // set filename in options class
string str = filename.str();
 char* cs = new char[str.length()+1];
 std::strcpy(cs, str.c_str());

 o->cfg_filenames[o->nr_cfg_files] = cs;

colortail crash and fix

[Ted Unangst]

Today's selected c++ reading:
Before any call to str() that uses the result as a C string,
the buffer must be null-terminated, typically with std::ends.

Found by mlarkin using MALLOC_OPTIONS=SU.

I leave it to the ports wizards to incorporate the patch.


--- OptionsParser.cc.orig   Wed Aug  4 19:23:39 1999
+++ OptionsParser.ccWed Jan 22 20:32:29 2020
@@ -17,8 +17,8 @@
 Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307  USA
 */
 
-#include 
-#include 
+#include 
+#include 
 #include 
 #include 
 #include 
@@ -27,6 +27,8 @@
 #include "Info.h"
 #include "Usage.h"
 
+using namespace std;
+
 // methods for class Options
 
 Options::Options()
@@ -138,6 +140,7 @@
  {
 // found seperator
 // set filename in options class
+filename << std::ends;
 o->cfg_filenames[o->nr_cfg_files] = filename.str();
 
 // increase the nr_cfg_files counter
@@ -154,6 +157,7 @@
  {
 // found end of string
 // set filename in options class
+filename << std::ends;
 o->cfg_filenames[o->nr_cfg_files] = filename.str();
 
 // increase the nr_cfg_files counter

Re: UPDATE security/scrypt

[Ted Unangst]

Björn Ketelaars wrote:
> On Thu 02/01/2020 06:27, Björn Ketelaars wrote:
> > On Wed 01/01/2020 23:03, Ted Unangst wrote:
> > > Björn Ketelaars wrote:
> > > > - When estimating the amount of available RAM, scrypt ignores
> > > >   RLIMIT_DATA on systems which have mmap.
> > > 
> > > This is wrong on OpenBSD. I sent an email to Colin, but the update should
> > > patch this out in the meantime.
> > 
> > Although I'm not doubting that you are right, I fail to understand why
> > ignoring RLIMIT_DATA on OpenBSD is bad. Could you explain why?
> > 
> > I prepared a patch, which:
> > - addresses ignoring RLIMIT DATA, reverting
> >   
> > https://github.com/Tarsnap/scrypt/commit/2b478e7ce590a6564d89417ddad4f3dd4bbdcaf6
> > - fixes compiling on base-gcc archs (found by kmos@)
> > 
> > OK?
> 
> Ping...
> 
> Diff below for your convenience.

oh, patch looks good to me, fwiw.

Re: enable column metadata in databases/sqlite3

[Ted Unangst]

Rafael Sadowski wrote:

>  # update p5-DBD-SQLite's Makefile.PL if enabling 
> -DSQLITE_ENABLE_COLUMN_METADATA

and...? :)

Re: vim colors

[Ted Unangst]

Theo de Raadt wrote:
> >The latest vim update appears to have changed the default colorscheme to
> >reallyfreakingawful. The previous default seems to be called peachpuff. hth.
> 
> does mailing ports@ help?
> 
> much more likely, did upstream not make the decision? why not engage
> them and express your outrage?

I'm not expecting openbsd to do anything about it, but I figured this would be
a good place to notify people of the change in case they had similar problems. 

vim colors

[Ted Unangst]

The latest vim update appears to have changed the default colorscheme to
reallyfreakingawful. The previous default seems to be called peachpuff. hth.

Re: UPDATE security/scrypt

[Ted Unangst]

Björn Ketelaars wrote:
> - When estimating the amount of available RAM, scrypt ignores
>   RLIMIT_DATA on systems which have mmap.

This is wrong on OpenBSD. I sent an email to Colin, but the update should
patch this out in the meantime.

go gc performance

[Ted Unangst]

So I've noticed that sometimes go programs run very slowly on OpenBSD. This
relates to garbage collection being exceptionally slow. The odd part is that
the CPU is idle. The problem isn't too many threads spinning around, but
rather all the threads sleeping.

If I'm not mistaken, the root cause is the loop in runtime/proc.go:sysmon().
It starts off with a short delay of 20us, slowly working up to a max of 10ms.
Alas, our kernel generally tends to give up a minimum of 20ms. Mind the us and
ms.

The effect is definitely most noticeable during garbage collection, but I
imagine there can be other circumstances in which it happens.

Some workarounds:

Reduce collections with the ballast approach.
https://blog.twitch.tv/en/2019/04/10/go-memory-ballast-how-i-learnt-to-stop-worrying-and-love-the-heap-26c2462549a2/

Either env GOMAXPROCS=1 or runtime.GOMAXPROCS(1) will eliminate the sleeps as
well, at the cost of parallelism. (The normal goroutine i/o multiplexer still
works as normal, so this may not even be noticeable.)

Running a kernel with HZ=1000 substantially reduces the length of extra
sleeps, but doesn't eliminate them entirely.

Fixes:

Somebody could rework the go scheduler to not use a wait loop. I'm not sure
why the sysmon thread doesn't or can't use normal wakeup techniques.

Somebody could rework the nanosleep syscall to permit sub tick precision.

(I'm sending this email mostly just to inform people of the workarounds. I've
looked into this issue before, thought it was specific to one situation, but I
think it's more common than that. But you may not notice, especially since it
doesn't present as 100% CPU load.)

Re: Illegal instruction (core dumped) with go/restic on Soekris i386

[Ted Unangst]

Stuart Henderson wrote:
> This runs OK on an i386 with more CPU features; most likely it wants
> SSE or similar which the Geode LX in your net5501 doesn't have. (Go has
> runtime cpuid checks for most of the SSE variants but I think not for
> the original SSE which it probably just assumes is available).
> One clue would be if the disassembly has instructions referencing
> registers X0..X15 which are just used for SSE.

go will autodetect 387 or sse2 based on the host.

https://golang.org/doc/install/source#environment

chromium and hw.ncpu

[Ted Unangst]

I was looking at the chrome profiler the other day and noticed it seems to
start more threads than I have CPUs online (since hw.smt is disabled). This is
not great for performance.

Fortunately, I did not have to download and read the chromium source, because
I found this snippet in the patches directory. :)

 int SysInfo::NumberOfProcessors() {
int mib[] = {CTL_HW, HW_NCPU};

As with other programs using this systl, this will overcount CPUs and create
too many threads. It should be HW_NCPUONLINE.

Re: Installing a tree of files

[Ted Unangst]

Stuart Henderson wrote:
> On 2019/08/11 13:33, Brian Callahan wrote:
> > 
> > Sure, but do you mind sweeping the tree for this do-install idiom? It's
> > probably not in too many places these days, but it's certainly in more
> > than just this one port.
> 
> If other ports are being touched can we have something that avoids a
> fork for every file please? Some of these have tens of thousands of
> files.
> 
> Since ownership isn't important any more (now we build ports as
> non-root) it might be simplest just to cp nowadays.

Inconveniently, find -exec {} + requires that {} go last, not followed by
destination. Maybe some way to sh around that.

Re: [NEW PORT]: rr

[Ted Unangst]

Marc Espie wrote:
> I've been playing a bit with new C++, and  to host stuff on github.
> 
> As a result, I've written a new (smallish) command called rr:

isn't rr the name of the mozilla reverse debugger? If I saw a pkg called rr,
that's what I would be expecting to get.

https://github.com/mozilla/rr

Re: misc/mc doesn't start if a route is set but not working

[Ted Unangst]

Solene Rapenne wrote:
> > The asr resolver in libc defaults to "lookup bind file" so DNS is hit
> > before /etc/hosts.  I have "lookup file bind" in resolv.conf{,.tail}.
> > 
> 
> Interesting, I would have think the default order to be "file bind"

The installer will create resolv.conf.tail for you if you select dhcp, so many
people probably get the setting that way.

Re: gmaps vs Firefox

[Ted Unangst]

Solene Rapenne wrote:
> Did you set MOZ_WEBRENDER=1 as stated in the pkg-readme file which comes
> with firefox?

Semi regular reminder that pkg_info doesn't print this info or indicate it
exists, nor does it appear to be mentioned in any man page of any tool that
I've ever used.

Re: no focus borders in dwm 6.2

[Ted Unangst]

Stuart Henderson wrote:
> 
> Have you considered i3 instead? It doesn't change much, and has a config file!

But then I might be tempted to change it!

Re: no focus borders in dwm 6.2

[Ted Unangst]

Klemens Nanni wrote:
> That works, but I also prefer dropping our local patches and stick with
> upstream defaults; same thing with x11/dmenu.
> 
> If users want to change a bit, they have to recompile themselves anyway,
> so that won't bite those who care (and customize by now already).

I think I said about the same in previous email, but to repeat, I don't
really care what dwm looks like, as long as it doesn't change too much.
Every time I run pkg_add -u my computer looks different. This is mostly a
browser problem (why do we need to change how tabs look every damn week???) so
I've appreciated that dwm is the one thing that hasn't changed for a while.

Re: no focus borders in dwm 6.2

[Ted Unangst]

Joerg Jung wrote:
> In the past the argument for keeping the customized grayish color scheme 
> was to provide a unified experience across the suckless tools dwm, dmenu,
> st, and tabbed in OpenBSD. They all use the same hex codes providing a
> similar look

The reason I use the package is because it offered a degree of isolation and
separation from the whims of upstream. I don't like change. e.g., I want
shift-alt-enter to run xterm because it used to run xterm, not st. FYI.

no focus borders in dwm 6.2

[Ted Unangst]

After updating to dwm 6.2, it appears that the blue border around the focused
window is gone. There's no way indication which window is focused, which is
kinda annoying. Was this an intentional change?

Re: install(1) broken

[Ted Unangst]

Marc Espie wrote:
> Something similar to this  perhaps ?
> Not fully tested yet, but it should avoid the race of trying to 
> unlink tempfile several times, and also fix the file name in error messages.

That's probably better.

Re: install(1) broken

[Ted Unangst]

Marc Espie wrote:
> hey, your commit to install(1) broke something.
> 
> Specifically lang/go-boostrap now produces a broken package which can't
> be used to build go.
> 
> All the go/bootstrap/pkg/tool/openbsd_amd64/*
> have lost their x bit
> 
> Relevant fake install information, it definitely looks like the last line
> is now a no-op.

> # These get installed via `find' however we need them to be executable
> /pobj/go-bootstrap-1.4.20171003/bin/install -d -m 755 
> /pobj/go-bootstrap-1.4.20171003/fake-amd64/usr/local/go/bootstrap/pkg/tool//openbsd_amd64
> /pobj/go-bootstrap-1.4.20171003/bin/install -c  -m 755 -p 
> /pobj/go-bootstrap-1.4.20171003/go/pkg/tool//openbsd_amd64/* 
> /pobj/go-bootstrap-1.4.20171003/fake-amd64/usr/local/go/bootstrap/pkg/tool//openbsd_amd64

Yes. This is a weird way to invoke chmod, but that's what it wants.

I think this was a long standing bug in install? If the files match, we need
to continue on with to_fd == existing file so that metadata updates work.


Index: xinstall.c
===
RCS file: /cvs/src/usr.bin/xinstall/xinstall.c,v
retrieving revision 1.68
diff -u -p -r1.68 xinstall.c
--- xinstall.c  8 Feb 2019 12:53:44 -   1.68
+++ xinstall.c  9 Feb 2019 22:21:03 -
@@ -313,8 +313,12 @@ install(char *from_name, char *to_name, 
(void)unlink(tempfile);
}
}
-   (void)close(to_fd);
-   to_fd = temp_fd;
+   if (!files_match) {
+   (void)close(to_fd);
+   to_fd = temp_fd;
+   } else {
+   close(temp_fd);
+   }
}
 
/*

go uses too many CPUs

[Ted Unangst]

Go tries to use NCPU cpus. Unfortunately, half of them are turned off because
hw.smt=0 by default, and then go spends a lot of time fighting against itself.

The diff below, against go/src/runtime, changes to use the number of CPUs
online. It's possible for this number to change, and thus become stale, but
that's unlikely, and not the default.

(This sysctl was added in 6.4.)

--- os_openbsd.go.orig  Fri Feb  8 00:02:27 2019
+++ os_openbsd.go   Fri Feb  8 00:06:21 2019
@@ -85,8 +85,8 @@
_KERN_OSREV = 3
 
_CTL_HW  = 6
-   _HW_NCPU = 3
_HW_PAGESIZE = 7
+   _HW_NCPUONLINE = 25
 )
 
 func sysctlInt(mib []uint32) (int32, bool) {
@@ -101,7 +101,7 @@
 
 func getncpu() int32 {
// Fetch hw.ncpu via sysctl.
-   if ncpu, ok := sysctlInt([]uint32{_CTL_HW, _HW_NCPU}); ok {
+   if ncpu, ok := sysctlInt([]uint32{_CTL_HW, _HW_NCPUONLINE}); ok {
return int32(ncpu)
}
return 1

Re: Chromium first start only libgl error

[Ted Unangst]

Mihai Popescu wrote:
> Hello,
> 
> I am getting this error when I start chromium for the first time on a
> fresh X session. If i close it and start chromium again, over and
> over, this error is gone. It appears again when X is restarted.
> 
> Is someone else getting it? Is it normal? Does it mean that
> acceleration is not available whenever I get this? I am running the
> last snapshot/amd64, starting X with xenodm.
> 
> libGL error: failed to open drm device: No such file or directory
> libGL error: failed to load driver: r600

No, this seems to happen to everyone. But it also seems meaningless? I
certainly don't see any actual difference in behavior between the first and
later runs. I asked a few other developers and the answer is.. chrome is
complicated.

dwm and chromium

[Ted Unangst]

It annoys me that chrome doesn't start on screen 9 like firefox does.
(Especially since it takes a few seconds to start, so I'm always surprised
when the window finally appears and disrupts my current screen.)
Easily fixed.


Index: Makefile
===
RCS file: /cvs/ports/x11/dwm/Makefile,v
retrieving revision 1.30
diff -u -p -r1.30 Makefile
--- Makefile3 Jun 2018 16:57:11 -   1.30
+++ Makefile30 Jan 2019 03:43:52 -
@@ -4,7 +4,7 @@ COMMENT=dynamic window manager
 
 V= 6.1
 DISTNAME=  dwm-${V}
-REVISION=  2
+REVISION=  3
 
 CATEGORIES=x11
 
Index: patches/patch-config_def_h
===
RCS file: /cvs/ports/x11/dwm/patches/patch-config_def_h,v
retrieving revision 1.12
diff -u -p -r1.12 patch-config_def_h
--- patches/patch-config_def_h  24 Oct 2016 22:46:54 -  1.12
+++ patches/patch-config_def_h  30 Jan 2019 03:43:52 -
@@ -25,10 +25,11 @@ $OpenBSD: patch-config_def_h,v 1.12 2016
  static const unsigned int borderpx  = 1;/* border pixel of windows */
  static const unsigned int snap  = 32;   /* snap pixel */
  static const int showbar= 1;/* 0 means no bar */
-@@ -27,6 +27,8 @@ static const Rule rules[] = {
+@@ -27,6 +27,9 @@ static const Rule rules[] = {
/* class  instancetitle   tags mask isfloating   
monitor */
{ "Gimp", NULL,   NULL,   0,1,   -1 },
{ "Firefox",  NULL,   NULL,   1 << 8,   0,   -1 },
++  { "Chromium", NULL,   NULL,   1 << 8,   0,   -1 },
 +  { "Xonix",NULL,   NULL,   0,1,   -1 },
 +  { NULL,   NULL,   "glxgears", 0,1,   -1 },
  };

Re: Work-around for not-shown JPEG images in www/links+

[Ted Unangst]

Hannes Wenzel wrote:
> I don't see whether upstream deliberately or accidentally does
> #cmakedefine HAVE_LOCAL_H
> instead of
> #cmakedefine HAVE_LOCAL_H 1
> and I, honestly, don't care. Just want to get this off my mind.

fyi, the port was updated after 6.4 to fix this.

http://cvsweb.openbsd.org/cgi-bin/cvsweb/ports/graphics/jpeg/Makefile

Re: tiny bsd.pork.mk error?

[Ted Unangst]

Marc Espie wrote:
> On Sun, Dec 09, 2018 at 09:34:56PM -0500, Ted Unangst wrote:
> > having updated ports tree to rebuild mercurial, i noticed this error.
> > 
> > ===>  Looking for mercurial-x11-4.5.3p3.tgz in $PKG_PATH - not found
> >  
> > *** Error 1 in . (/home/tedu/ports/infrastructure/mk/bsd.port.mk:1992
> > '/home/tedu/ports/packages/sparc64/c
> > ache/mercurial-x11-4.5.3p3.tgz': @...)
> > 
> > Everything built and installed correctly, otherwise. Perhaps operator 
> > error, I
> > am not sure if the command actually failed, FETCH_PACKAGES=Yes seemed to 
> > work
> > for other packages. This is 6.4. Looking at line 1992 didn't reveal much.
> 
> Are you on the 6.4 branch or the -current branch ?
> 
> Semantics of FETCH_PACKAGES changed  from "Yes/No" to "Options for pkg_add/No"
> right after 6.4

6.4 branch. I have it set to Yes. (I noticed the change, but I'm before that.)
It's not a big deal, especially since maybe things changed.

tiny bsd.pork.mk error?

[Ted Unangst]

having updated ports tree to rebuild mercurial, i noticed this error.

===>  Looking for mercurial-x11-4.5.3p3.tgz in $PKG_PATH - not found
 
*** Error 1 in . (/home/tedu/ports/infrastructure/mk/bsd.port.mk:1992
'/home/tedu/ports/packages/sparc64/c
ache/mercurial-x11-4.5.3p3.tgz': @...)

Everything built and installed correctly, otherwise. Perhaps operator error, I
am not sure if the command actually failed, FETCH_PACKAGES=Yes seemed to work
for other packages. This is 6.4. Looking at line 1992 didn't reveal much.

Re: hg on sparc64

[Ted Unangst]

Jeremie Courreges-Anglas wrote:
> On Thu, Dec 06 2018, "Ted Unangst"  wrote:
> > running hg on sparc64 complains of missing symbols.
> >
> > t5120$ hg version
> > python2.7:/usr/local/lib/python2.7/site-packages/mercurial/zstd.so: 
> > undefined
> > symbol '__builtin_bswap32'
> > python2.7:/usr/local/lib/python2.7/site-packages/mercurial/zstd.so: 
> > undefined
> > symbol '__builtin_bswap64'
> > Mercurial Distributed SCM (version 4.5.3)
> 
> Should be fixed on -current...

sorry, to be clear, the update to 4.8.1? some patch? i didn't see anything.

hg on sparc64

[Ted Unangst]

running hg on sparc64 complains of missing symbols.

t5120$ hg version
python2.7:/usr/local/lib/python2.7/site-packages/mercurial/zstd.so: undefined
symbol '__builtin_bswap32'
python2.7:/usr/local/lib/python2.7/site-packages/mercurial/zstd.so: undefined
symbol '__builtin_bswap64'
Mercurial Distributed SCM (version 4.5.3)

Re: net/glib2-networking: Remove systemd service

[Ted Unangst]

Klemens Nanni wrote:
> It's just your argument I don't get/agree with: Instead of starting to
> clean things up you're not doing anything at all because there's more
> to clean anyway?
> 
> Of course getting rid of every misplaced/unsupported/whatever bit seems
> utopian but not doing it where easily possible seems illogical to me.

One reason is that such cleanups tend to get lost in updates. So now every
update to a port comes with a systemd removal diff a week later. That seems
like a lot of noise and extra effort.

The problem isn't simply that it's one time work, in which case I'd agree that
there's no harm to starting small. But you're also creating ongoing work to
maintain this cleanup. A cleanup should reduce maintenance, not increase it.

Re: salt threads? Re: CVS: cvs.openbsd.org: src

[Ted Unangst]

viq wrote:
> > > anybody know what's going on?
> > 
> > From my running salt with trace logs, it seems that salt initialises
> > everything, opens it's IPC sockets, initiates it's AES auth/handshake
> > with master, and that's when things die.
> 
> Would output of ktrace/kdump be useful here? FWIW it's 24MB, 240k lines,
> 4.2MB compressed

not especially. i already know *what* it does. somebody has to read the code
to figure out why.

anyway, i turned the check off for now. it's good to know it triggers, but
with clang and other changes now isn't the best time.

salt threads? Re: CVS: cvs.openbsd.org: src

[Ted Unangst]

moving to ports

viq wrote:
> On 17-07-27 10:35:08, Ted Unangst wrote:
> > CVSROOT:/cvs
> > Module name:src
> > Changes by: t...@cvs.openbsd.org2017/07/27 10:35:08
> > 
> > Modified files:
> > lib/librthread : rthread.c rthread_fork.c 
> > 
> > Log message:
> > bad things can (and will) happen if a threaded program calls fork() and
> > then strays off the path to exec(). one common manifestation of this
> > problem occurs in pthread_join(), so we can add a little check there.
> > first person to hit this in real life gets to change the error message.
> 
> So, uh, would that be me?
> $ doas salt-minion  
> great scott! serious repercussions on future events!
> $ echo $?
> 250
> $ sysctl kern.version
> kern.version=OpenBSD 6.1-current (GENERIC) #13: Thu Jul 27 19:51:38 MDT 2017
> dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC

i'm not sure what salt is doing (or even what it is), but this is probably not
good. calling pthread_join() in the child after fork() is not something you're
supposed to do.

anybody know what's going on?

quiet install-info warnings

[Ted Unangst]

install-info: warning: no entries found for `/usr/local/info/gpgrt.info'; 
nothing deleted
install-info: menu item `libgpg-error' already exists, for file `gnupg'
system(/usr/bin/install-info, --info-dir=/usr/local/info, --, 
/usr/local/info/gpgrt.info) failed: exit(1)
chromium-59.0.3071.109p0:libgpg-error-1.27->1.27: ok

would adding --quiet to install-info make this go away? i guess it's not
harmful, but i have to study the message for some time to figure that out.

clang luajit unwinding

[Ted Unangst]

a little late to the party, but luajit is broken with clang because it needs
special libunwind support or something. that's the story so far.

anyway, looking closer at luajit I notice that "external" unwinding is only
the default on amd64. i386 and others use internal unwinding. one can also
disable unwinding by defining LJ_NO_UNWIND.

anyway, that's what I did, and things seem to work fine. there's a long
comment in src/lj_err.c that lays out the pros and cons of each approach,
mostly less c++ compat. i personally don't much care, and if it only works on
one architecture, I'd say it's questionable to rely on this feature.

maybe we can live without unwind in luajit? 

Re: firefox 52 - crashes at startup or later due to oom

[Ted Unangst]

Sebastien Marie wrote:
> Alternatively, having a small datastack-cur and a bigger datastack-max
> is a possibility, and setting datastack-cur to datastack-max before
> running firefox (ulimit -d `ulimit -dH`).

indeed. for some years now, i usually start firefox from a shell.

first ulimit -d 4123123, then firefox. as a bonus, you get to see all sorts of
interesting messages.

Re: luajit,lua52 uses the wrong lua abi

[Ted Unangst]

Aaron Bieber wrote:
> > On the other hand:
> > - other OSes don't seem to enable it (granted, I only checked Debian and
> >   FreeBSD)
> > - I didn't hear anyone step up to keep LUAJIT_ENABLE_LUA52COMPAT. :)
> > 
> > I'd just kill it, unless you or abieber@ see value in keeping it.
> 
> IIRC tedu@ wanted it for something - I will ping him to see if he has
> any uses.

i don't think so. i only use the 5.1 flavor.

Re: FIXES: rspamd

[Ted Unangst]

Edd Barrett wrote:
> I notice that performance of learning spam with the sqlite backend is
> pretty poor (can take over a minute to learn a message if you leave it
> learning a corpus long enough -- during which the hard disk LED is
> pegged on). Upstream speculates that fsync() may be expensive on
> OpenBSD, which sqlite apparently uses liberally(?) Anyone know anything
> about that?

Well, it does one or two fsync per transaction. if you're doing a thousand
auto-commit updates, it's gonna be slow.

Re: remove gtk1/glib1 (and xmms)

[Ted Unangst]

Jasper Lievisse Adriaanse wrote:
> OK to take glib/gtk/xmms to the slaughterhouse? These are ports that haven't
> been updated in nearly a decade (xmms) or even longer (> 15 years for 
> glib/gtk).
> It's about time we trim this dead wood.

they served their purpose as far as i'm concerned.

Re: PATCH: mail/trojita wxneeded

[Ted Unangst]

Caspar Schutijser wrote:
> Hi,
> 
> trojita violates W^X at runtime. USE_WXNEEDED=Yes does not work in this
> case so I patched CMakeLists.txt.

webkit related? we should probably be annotating these.

Re: Webkit and W^X?

[Ted Unangst]

Christian Weisgerber wrote:
> What's up with Webkit and W^X?
> 
> The www/webkit and www/webkitgtk4 builds show W^X violations, but
> they don't crash.  Does webkit handle the mmap() error correctly
> and fall back to something else?  Or are the produced packages
> garbage?

likely falls back to the interpreter.

Re: i3 crashing

[Ted Unangst]

David Coppa wrote:
> >About once a day i3 crashes with the following on the console:
> >
> >   drm:pid42188:radeon_fence_wait_empty_lock *ERROR* error waiting for
> >   ring[3] to become idle (-2614464)
> >   i3(44795): syscall 97 "inet"
> >
> >Any suggestions what is wrong?
> >
> 
> It's not i3 crashing, it's the Xorg server, because of a bug in the radeon 
> drm driver.

This is true-ish, but i3 is definitely hitting an issue with pledge as well.

Re: [update] chicken-4.11.0p0

[Ted Unangst]

TimoMyyrä wrote:
> Index: core/patches/patch-posixunix_scm
> ===
> RCS file: core/patches/patch-posixunix_scm
> diff -N core/patches/patch-posixunix_scm
> --- /dev/null 1 Jan 1970 00:00:00 -
> +++ core/patches/patch-posixunix_scm  17 Jul 2016 12:13:17 -
> @@ -0,0 +1,18 @@
> +$OpenBSD$
> +Use _shadow versions to expose password info.
> +--- posixunix.scm.orig   Sun Jul 17 14:54:07 2016
>  posixunix.scmSun Jul 17 14:55:19 2016
> +@@ -177,8 +177,13 @@ static C_TLS struct stat C_statbuf;
> + #define C_getpgid(x)C_fix(getpgid(C_unfix(x)))
> + #define C_symlink(o, n) C_fix(symlink(C_data_pointer(o), 
> C_data_pointer(n)))
> + #define C_do_readlink(f, b)C_fix(readlink(C_data_pointer(f), 
> C_data_pointer(b), FILENAME_MAX))
> ++#if defined(__OpenBSD__)
> ++#define C_getpwnam(n)   C_mk_bool((C_user = getpwnam_shadow((char 
> *)C_data_pointer(n))) != NULL)
> ++#define C_getpwuid(u)   C_mk_bool((C_user = 
> getpwuid_shadow(C_unfix(u))) != NULL)
> ++#else
> + #define C_getpwnam(n)   C_mk_bool((C_user = getpwnam((char 
> *)C_data_pointer(n))) != NULL)
> + #define C_getpwuid(u)   C_mk_bool((C_user = getpwuid(C_unfix(u))) != 
> NULL)
> ++#endif
> + #if !defined(__ANDROID__) && defined(HAVE_GRP_H)
> + #define C_getgrnam(n)   C_mk_bool((C_group = getgrnam((char 
> *)C_data_pointer(n))) != NULL)
> + #define C_getgrgid(u)   C_mk_bool((C_group = getgrgid(C_unfix(u))) != 
> NULL)

Is this necessary? Is the code using getspnam on other platforms?

Re: Gauche threads stuck on OpenBSD

[Ted Unangst]

TimoMyyrä wrote:
> I'm trying to make Gauche Scheme work on OpenBSD but I'm hitting a wall
> debugging it. The problem is that thread tests get stuck.
> Debugging the issue would indicate that the thread test causes threads to
> suspend and sem_wait blocks forever.

Can you make a testcase in plain C? I don't want to debug seven layers of
abstraction.

youtube-dl update?

[Ted Unangst]

The current ports version of youtube-dl cannot handle vine anymore.
Downloading a new version, 2016.07.09.2, works fine manually. However,
when I update the port to use this version, it fails.

  File "/usr/local/lib/python2.7/site-packages/youtube_dl/extractor/cliprs.py", 
line 4, in 
from .onet import OnetBaseIE
ImportError: No module named onet

Don't know how to proceed.

Re: go seems to use sys_o58_kill

[Ted Unangst]

Ted Unangst wrote:
> Ray Lai wrote:
> > On Sun, 05 Jun 2016 22:57:36 -0400
> > "Ted Unangst" <t...@tedunangst.com> wrote:
> > 
> > > sys_o58_kill was removed from the kernel on may 31. Even recently built go
> > > binaries continue to use it. I guess the runtime wasn't updated to use 
> > > the new
> > > call?
> > > 
> > 
> > This should fix it.

I also see this in platform code:

218 // call sigreturn
219 MOVLcontext+8(FP), AX
220 MOVL$0, 0(SP)   // syscall gap
221 MOVLAX, 4(SP)   // arg 1 - sigcontext
222 MOVL$103, AX// sys_sigreturn
223 INT $0x80
224 MOVL$0xf1, 0xf1 // crash
225 RET

I'm not sure if that requires rework now too with the sigreturn hardening.

Re: go seems to use sys_o58_kill

[Ted Unangst]

Ray Lai wrote:
> On Sun, 05 Jun 2016 22:57:36 -0400
> "Ted Unangst" <t...@tedunangst.com> wrote:
> 
> > sys_o58_kill was removed from the kernel on may 31. Even recently built go
> > binaries continue to use it. I guess the runtime wasn't updated to use the 
> > new
> > call?
> > 
> 
> This should fix it.

> Index: patches/patch-src_runtime_sys_openbsd_386_s
> ===
> RCS file: 
> /home/cvs/ports/lang/go/patches/patch-src_runtime_sys_openbsd_386_s,v
> retrieving revision 1.1
> diff -u -p -r1.1 patch-src_runtime_sys_openbsd_386_s
> --- patches/patch-src_runtime_sys_openbsd_386_s   13 May 2016 13:49:26 
> -  1.1
> +++ patches/patch-src_runtime_sys_openbsd_386_s   6 Jun 2016 06:10:53 
> -
> @@ -1,6 +1,24 @@
>  $OpenBSD: patch-src_runtime_sys_openbsd_386_s,v 1.1 2016/05/13 13:49:26 
> jsing Exp $
>  src/runtime/sys_openbsd_386.s.orig   Thu May  5 01:27:04 2016
> -+++ src/runtime/sys_openbsd_386.sThu May  5 01:27:41 2016
> +--- src/runtime/sys_openbsd_386.s.orig   Wed Apr 20 07:50:09 2016
>  src/runtime/sys_openbsd_386.sMon Jun  6 14:01:31 2016
> +@@ -86,7 +86,7 @@ TEXT runtime·raise(SB),NOSPLIT,$12
> + MOVLAX, 4(SP)   // arg 1 - pid
> + MOVLsig+0(FP), AX
> + MOVLAX, 8(SP)   // arg 2 - signum
> +-MOVL$37, AX // sys_kill
> ++MOVL$122, AX// sys_kill
> + INT $0x80
> + RET
> + 
> +@@ -97,7 +97,7 @@ TEXT runtime·raiseproc(SB),NOSPLIT,$12
> + MOVLAX, 4(SP)   // arg 1 - pid
> + MOVLsig+0(FP), AX
> + MOVLAX, 8(SP)   // arg 2 - signum
> +-MOVL$37, AX // sys_kill
> ++MOVL$122, AX// sys_kill
> + INT $0x80
> + RET
> + 

I think the first of each of these should be thrkill instead.

go seems to use sys_o58_kill

[Ted Unangst]

sys_o58_kill was removed from the kernel on may 31. Even recently built go
binaries continue to use it. I guess the runtime wasn't updated to use the new
call?

Re: go missing cgo?

[Ted Unangst]

Joel Sing wrote:
> On Thursday 02 June 2016 21:02:58 Ted Unangst wrote:
> > Trying to build anything with go 1.6 results in an error.
> > 
> > Seven flavors of stackoverflow questions provide seven different answers,
> > but none of them seem particularly relevant.
> 
> Works fine for me:
> 
> The libtls/gotls regress also runs/passes (which uses cgo) and make regress 
> passed on both i386 and amd64 when I did the update to 1.6.2.
> 
> I suspect a local environment issue - what does `go env` say?
> 
> Have you got a GOROOT or GOARCH/GOHOSTARCH exported?
> 
> The list of C files is also curious - those look like parts of the old Go 
> runtime (Go 1.4 and earlier), which it should not be trying to build (or even 
> know anything about). Actually, this looks like you're invoking the go 1.6.2 
> binary with a GOROOT pointing at the go-bootstrap environment...

ok, the internet was pointing in that direction, but I didn't believe it.
Deleted /usr/local/go entirely (there were some files there not in the
package) and now it works.

go missing cgo?

[Ted Unangst]

Trying to build anything with go 1.6 results in an error.

$ go build hello.go
package main
imports runtime: C source files not allowed when not using cgo or
SWIG: atomic_amd64x.c defs.c float.c heapdump.c lfstack.c malloc.c
mcache.c mcentral.c mem_openbsd.c mfixalloc.c mgc0.c mheap.c msize.c
os_openbsd.c panic.c parfor.c proc.c runtime.c signal.c
signal_amd64x.c signal_unix.c stack.c string.c sys_x86.c
$ go version
go version go1.6.2 openbsd/amd64

Seven flavors of stackoverflow questions provide seven different answers, but
none of them seem particularly relevant.

Re: OpenBSD 6.0-beta spop3d: auth: no shadow password handling compiled in server

[Ted Unangst]

Peter N. M. Hansteen wrote:
> Hi,
> 
> After upgrading a mail server to the latest 6.0-beta snapshot and the 
> requisite
> pkg_add -u, when users try to retrieve mail, authentication fails:
> 
> spop3d[14311]: auth: no shadow password handling compiled in server
> 
> I assume this would be a matter of a configure option?

just needs a little diff like the one for apop3d.

unfriendly pkg_info signify errors

[Ted Unangst]

Some tests. I do not have the colors package installed, so I'm fetching it via
http. The good news pkg_info checks the signature. The bad news is the
messages are confusing and user hostile.

First, what happens when the key is missing?

$ pkg_info colorls 
Can't find key /etc/signify/openbsd-59-pkg.pub for signer
/etc/signify/openbsd-59-pkg.pub
Fatal error: colorls-5.9 is corrupted
 at /usr/libdata/perl5/OpenBSD/PkgInfo.pm line 387.

The first error makes sense, the second does not. The package is not
corrupted. This error may also appear if I'm trying to install a package from
a third party.

Next, I restored the pubkey, but modified it so the signature wouldn't match.

$ pkg_info colorls 
signify: signature verification failed
system(/usr/bin/signify, -V, -q, -p, /etc/signify/openbsd-59-pkg.pub, -e, -x,
-, -m, /dev/null) failed: exit(1)
Can't locate object method "log" via package "OpenBSD::PkgInfo::State" at
/usr/libdata/perl5/OpenBSD/signify.pm line 109.

The stderr message from signify is helpful, but unintentional I think, but
then come the perl messages that aren't helpful.

Re: xscreensaver: enable shadow only pwd

[Ted Unangst]

Gregor Best wrote:
> Hi people,
> 
> On Fri, May 06, 2016 at 03:03:52PM +0100, Stuart Henderson wrote:
> > [...]
> > Feel free to investigate the ports I mentioned then. Diffs to
> > ports@ please - you can test that they work using tedu's diff
> > that will avoid filling in pw_passwd in the struct, it's usually
> > just a case of s/(getpwuid|getpwnam)/\1_shadow/.
> > [...]
> 
> The attached patch fixes x11/xscreensaver to work with the new
> shadow-only pwd. I think the patch is straightforward, but given the
> sensitive nature of xscreensaver, it'd probably be good if more than one
> other person could test this before it gets applied.

looks about right. as sthen says, these should be pretty easy.

and when in doubt, adding the shadow extension is safe-ish. at worst,
unnecessary use of shadow will result in the same behavior as 5.9. you're
unlikely to actually introduce a vulnerability.

no man page for pnmtopng

[Ted Unangst]

carbolite:~> pnmtopng -?
pnmtopng: Use 'man pnmtopng' for help.
carbolite:~> man pnmtopng
man: No entry for pnmtopng in the manual.

This feel vaguely familiar, but I can't remember why it is so.

Re: multibyte character issues in ports

[Ted Unangst]

Alexey Suslikov wrote:
> Ingo Schwarze  usta.de> writes:
> 
> > If anybody is aware of any annoying multibyte character issues in
> > ports land, feel free to tell me...  Obviously, i don't promise to
> > fix it, but at least i'll have a look and try if i can come up
> > with a reasonable idea.
> 
> (in)famous netbeans "output window garbage" bug?

Java has its own unicode support. There is nothing here for us to fix.

Re: [bug] gzip archives created with pkg_create have wrong data sizes

[Ted Unangst]

Marc Espie wrote:
> On Sun, Apr 24, 2016 at 12:57:46PM +0200, Marc Espie wrote:
> > On Sun, Apr 24, 2016 at 01:47:24AM -0400, dan mclaughlin wrote:
> > > the sizes of the compressed/uncompressed data are wrong. i have tested 
> > > gzip
> > > and 'tar zcf' and the values are right, but using pkg_create fails.
> > 
> > gzip -l will just give you the first chunk, that's a limitation of the gzip
> > tool itself.
> 
> I've had a slightly closer look at gzip...
> 
> making gzip -l able to recognize multiple chunks archive should be doable,
> but it would require a lot of code churn.

Or we rename the files .pkg and nobody pokes them with the wrong tool. :)

Re: quake2 update

[Ted Unangst]

Brandon Mercer wrote:
> Inspired by the recent dhewm3 work, I decided to try quake2 again only
> to find that it does not work. There was some dialogue by folks earlier
> to get the existing port, that has been broken for the better part of
> two years, replaced with yquake2. Because yquake2 is different than
> quake2, I propose we import this new, working version and then delete
> the existing port. This diff was sent out by jsg@ some time ago before a
> fun bikeshedding session. Looking for OK's to import this: 

I'm not sure who to blame, but trying to run full screen in dwm results in a
640x480 window *and* dwm scrunching all of its windows into that space too.
Everything was jammed into a tiny corner. Like a clown car of xterms.

Re: quake2 update

[Ted Unangst]

Brandon Mercer wrote:
> Inspired by the recent dhewm3 work, I decided to try quake2 again only
> to find that it does not work. There was some dialogue by folks earlier
> to get the existing port, that has been broken for the better part of
> two years, replaced with yquake2. Because yquake2 is different than
> quake2, I propose we import this new, working version and then delete
> the existing port. This diff was sent out by jsg@ some time ago before a
> fun bikeshedding session. Looking for OK's to import this: 

missing openal dependency?

Re: Firefox PDF rendering

[Ted Unangst]

Stuart Henderson wrote:
> On 2015/12/26 19:11, Michael McConville wrote:
> > Is there a reason why Firefox often has ugly typography in PDFs
> > generated by LaTeX and the like? Most specifically, the t's are often
> > very fat.
> > 
> > Here's an example:
> > 
> > http://www.sccs.swarthmore.edu/~mmcconv1/dump/firefox-pdf.png
> > 
> > IIRC, it's this way on some Linux distros too, so maybe it's
> > unavoidable. Is there any way around it?
> > 
> 
> I think this may happen if you have ghostscript-fonts installed.

http://marc.info/?l=openbsd-ports=144585828632578=2

Solution: cd /usr/local/share ; mv fonts/ghostscript fonts-ghostscript

Re: mysqld spinning on -current

[Ted Unangst]

joshua stein wrote:
> Is anyone else seeing mysqld using 100% CPU on -current (amd64)
> while doing nothing?  There are no connections to it and it seems to
> go into this mode on its own right after startup.
> 
> USER   PID %CPU %MEM   VSZ   RSS TT  STAT  STARTED   TIME COMMAND
> _mysql   15013 99.1  0.5 176252 40988 p3- R  2:47PM  119:22.66 
> /usr/local/libexec/mysqld --basedir=/usr/local --datadir=/var/mysql 
> --plugin-dir=/usr/local/lib/mysql/plugin --user=_mysql [...]
> 
> ktrace shows it calling gettimeofday() over and over.

same thing that firefox tends to do. but i don't see any gettimeofday() calls
in librthread. coincidence? at least mysql is small enough to debug. can you
find the loop that calls gettimeofday?

Re: xsnow license

[Ted Unangst]

mi...@dataswamp.org wrote:
> Hi there,
> 
> I asked this question in #openbsd and they sent me here.
> 
> the xsnow Makefile says:
> PERMIT_PACKAGE_CDROM=   vague license
> PERMIT_PACKAGE_FTP= vague license
> 
> However the xsnow website says very clearly that distribution as 
> (binary) package is permitted. I guess distribution via ftp should 
> therefore be alright. 
> See http://dropmix.xs4all.nl/rick/Xsnow/ .
> 
> Could somebody verify and change that?

I can verify the text on the web site is vague. Pick a real license.

Re: graphics/cfdg, flex fallout?

[Ted Unangst]

David Coppa wrote:
> On Sat, 21 Nov 2015, Antoine Jacoutot wrote:
> 
> > cc -O2 -pipe -O2 -pipe   -I/usr/local/include -Isrc-common -Isrc-unix 
> > -Iobjs -Isrc-agg/include -Isrc-common/agg-extras  -c -o objs/lex.yy.o 
> > objs/lex.yy.c
> > Makefile:115: recipe for target 'objs/lex.yy.o' failed
> > ===> Exiting graphics/cfdg with an error
> > :868: error: conflicting types for 'yyget_leng'
> > src-common/yglue.h:54: error: previous declaration of 'yyget_leng' was here
> > :2301: error: conflicting types for 'yyget_leng'
> > src-common/yglue.h:54: error: previous declaration of 'yyget_leng' was here
> > gmake: *** [objs/lex.yy.o] Error 1
> > *** Error 2 in graphics/cfdg 
> > (/exopi-cvs/ports/infrastructure/mk/bsd.port.mk:2770 
> > '/exopi-obj/pobj/cfdg-2.2.2/.build_done')
> > *** Error 1 in graphics/cfdg 
> > (/exopi-cvs/ports/infrastructure/mk/bsd.port.mk:2491 'build')
> > *** Error 1 in /exopi-cvs/ports (infrastructure/mk/bsd.port.subdir.mk:147 
> > 'build')
> > Error: job failed 256
> 
> This port could use an update... In the meantime, here's the (simple) fix:

This may not be the end of the story. Old flex typedef yy_size_t as unsigned
int, new flex uses size_t (as it should), but there are bootstrapped lexers
prebuilt with the old flex, and at various times people have added their own
typedefs and prototypes.

I have reverted flex to using int in base because we have lexers that are
still using int. I need a little time to evaluate, but then we will hopefully
go back to size_t.

The nature of the difference means that compilation issues aside, runtime
issues are likely only on 64-bit big endian systems. The extent that 64BE code
is tested in the larger ecosystem outside openbsd is... haha.

Don't rush to make too many changes until base settles down (though I think
this diff should be safe either way). Also, keep an extra eye open for
failures on sparc64.

go 1.5.1 update draft

[Ted Unangst]

Update to go 1.5.1. There are some oddities because of bootstrapping, but it
generally seems to work ok. Needs some polish, but it's a start.

The bootstrap requires an existing go install, but the file layout we use
for the package doesn't seem to work. So it bootstraps from an existing
*build* of 1.4.2 in the ports directory. Maybe this can be fixed up somehow.
Certainly, bootstrapping 1.5 to 1.5 won't work this way, but I'm not sure what
to do here.

(Also, delete all the patches in the patches dir.)


? oldpatches
? patches
Index: Makefile
===
RCS file: /cvs/ports/lang/go/Makefile,v
retrieving revision 1.26
diff -u -p -r1.26 Makefile
--- Makefile19 Aug 2015 06:57:20 -  1.26
+++ Makefile12 Nov 2015 20:44:19 -
@@ -4,8 +4,8 @@ ONLY_FOR_ARCHS =${GO_ARCHS}
 
 COMMENT =  Go programming language
 
-VERSION =  1.4.2
-REVISION = 0
+VERSION =  1.5.1
+#REVISION =0
 EXTRACT_SUFX = .src.tar.gz
 DISTNAME = go${VERSION}
 PKGNAME =  go-${VERSION}
@@ -64,6 +64,7 @@ do-build:
CC="${CC}" \
CXX="${CXX}" \
GOROOT=${WRKDIST} \
+   GOROOT_BOOTSTRAP=${WRKDIST}/../../go-1.4.2/go \
GOBIN=${WRKDIST}/bin \
GOROOT_FINAL=${GOROOT} ./make.bash --no-banner
 
@@ -82,7 +83,7 @@ do-install:
-exec ${INSTALL_DATA} -p {} \
${GOROOT} \;
 
-.  for dir in doc include lib misc src pkg
+.  for dir in doc lib misc src pkg
@cd ${WRKDIST} && \
find ${dir} -type d \
-exec ${INSTALL_DATA_DIR} \
Index: distinfo
===
RCS file: /cvs/ports/lang/go/distinfo,v
retrieving revision 1.13
diff -u -p -r1.13 distinfo
--- distinfo6 May 2015 08:28:26 -   1.13
+++ distinfo12 Nov 2015 20:44:19 -
@@ -1,2 +1,2 @@
-SHA256 (go1.4.2.src.tar.gz) = KZpv2Pit/c4VvAa96SbnslKujiTdWxa32Hke1557Xps=
-SIZE (go1.4.2.src.tar.gz) = 10921896
+SHA256 (go1.5.1.src.tar.gz) = qImHPpjZpyrjlqm33Vl8KdzXCcr6kJfZxLoEz/DsQ2s=
+SIZE (go1.5.1.src.tar.gz) = 12049701
Index: pkg/PFRAG.amd64
===
RCS file: /cvs/ports/lang/go/pkg/PFRAG.amd64,v
retrieving revision 1.5
diff -u -p -r1.5 PFRAG.amd64
--- pkg/PFRAG.amd64 23 Dec 2014 12:21:37 -  1.5
+++ pkg/PFRAG.amd64 12 Nov 2015 20:44:20 -
@@ -1,5 +1,2 @@
 @comment $OpenBSD: PFRAG.amd64,v 1.5 2014/12/23 12:21:37 jsing Exp $
-go/src/runtime/zasm_openbsd_amd64.h
-go/src/runtime/zgoarch_amd64.go
-go/src/runtime/zruntime_defs_openbsd_amd64.go
-go/src/runtime/zsys_openbsd_amd64.s
+go/src/runtime/zgoarch_${MACHINE_ARCH}.go
Index: pkg/PFRAG.i386
===
RCS file: /cvs/ports/lang/go/pkg/PFRAG.i386,v
retrieving revision 1.5
diff -u -p -r1.5 PFRAG.i386
--- pkg/PFRAG.i386  23 Dec 2014 12:21:37 -  1.5
+++ pkg/PFRAG.i386  12 Nov 2015 20:44:20 -
@@ -1,5 +1,2 @@
 @comment $OpenBSD: PFRAG.i386,v 1.5 2014/12/23 12:21:37 jsing Exp $
-go/src/runtime/zasm_openbsd_386.h
 go/src/runtime/zgoarch_386.go
-go/src/runtime/zruntime_defs_openbsd_386.go
-go/src/runtime/zsys_openbsd_386.s
Index: pkg/PLIST
===
RCS file: /cvs/ports/lang/go/pkg/PLIST,v
retrieving revision 1.12
diff -u -p -r1.12 PLIST
--- pkg/PLIST   23 Dec 2014 12:21:37 -  1.12
+++ pkg/PLIST   12 Nov 2015 20:44:21 -
@@ -5,10 +5,11 @@
 @bin bin/gofmt
 go/
 go/AUTHORS
+go/CONTRIBUTING.md
 go/CONTRIBUTORS
 go/LICENSE
 go/PATENTS
-go/README
+go/README.md
 go/VERSION
 go/doc/
 go/doc/articles/
@@ -21,6 +22,7 @@ go/doc/articles/wiki/final-noclosure.go
 go/doc/articles/wiki/final-noerror.go
 go/doc/articles/wiki/final-parsetemplate.go
 go/doc/articles/wiki/final-template.go
+go/doc/articles/wiki/final-test.patch
 go/doc/articles/wiki/final.go
 go/doc/articles/wiki/get.go
 go/doc/articles/wiki/http-sample.go
@@ -55,6 +57,7 @@ go/doc/contrib.html
 go/doc/contribute.html
 go/doc/debugging_with_gdb.html
 go/doc/devel/
+go/doc/devel/pre_go1.html
 go/doc/devel/release.html
 go/doc/devel/weekly.html
 go/doc/docs.html
@@ -68,6 +71,7 @@ go/doc/go1.1.html
 go/doc/go1.2.html
 go/doc/go1.3.html
 go/doc/go1.4.html
+go/doc/go1.5.html
 go/doc/go1.html
 go/doc/go1compat.html
 go/doc/go_faq.html
@@ -107,7 +111,6 @@ go/doc/help.html
 go/doc/ie.css
 go/doc/install-source.html
 go/doc/install.html
-go/doc/logo-153x55.png
 go/doc/play/
 go/doc/play/fib.go
 go/doc/play/hello.go
@@ -123,14 +126,10 @@ go/doc/progs/cgo2.go
 go/doc/progs/cgo3.go
 go/doc/progs/cgo4.go
 go/doc/progs/defer.go
-go/doc/progs/defer.out
 go/doc/progs/defer2.go
-go/doc/progs/defer2.out
 go/doc/progs/eff_bytesize.go
-go/doc/progs/eff_bytesize.out
 

Re: [UPDATE] x11/dwm

[Ted Unangst]

Joerg Jung wrote:
> 
> > On 09 Nov 2015, at 22:07, Ted Unangst <t...@tedunangst.com> wrote:
> > Joerg Jung wrote:
> >> 
> >> please find below an update for x11/dwm to 6.1.  This release contains
> >> various fixes and improvements, see announcement [1] for more details.
> >> 
> >> OK?
> > 
> > so now that we finally changed the default xterm back to uxterm, they 
> > changed
> > it to st. needs another man page patch. :)
> 
> I wonder what dwm users think about the following proposal:
> 
> Remove the uxterm patch and keep st as the default terminal.
> If you are a dwm/dmenu suckless user on your desktop you are 
> probably also fine with using st. 
> 
> st has become rather stable and usable. A lot of issues are 
> fixed and most terminal applications seem to work just fine.
> 
> Other “desktop environments” also all start their own terminals 
> (e.g. gnome, kde, xfce, …).
> 
> Or does this go one step too far?!  What do you think?

I've never liked st. I don't love xterm, per se, but despite the mind numbing
code it mostly seems to work. In particular, I like scrollback and I don't
want to run 32 different tmux sessions to get the same effect. Maybe they're
fixed, but I also had some screen drawing glitches in st a year or so ago.

Now I'm also old and cranky and I think gterm, kterm, eterm, etc. are all
stupid ideas too, but I'm not using dwm because I want to buy into the
suckless desktop environment. I just want a window manager.

(All that said, since I had to build 6.1 by myself to test, I also changed the
font to ubuntu mono to match my xterms, so maybe I will just keep building it
myself the way I like, so my opinion doesn't count.)

Re: [UPDATE] x11/dwm

[Ted Unangst]

Joerg Jung wrote:
> So this is not only needed by dwm but all suckless ports and leads to a
> suckless bsd.port.mk module.

Now we're going a bit far afield. For today, I'm ok with the update as is,
with the man page bits.

I do like the consistency our port offers, vs reflecting whatever the whim of
the day is for upstream. If anything, having a patch in patches made it easier
for me to change the font, since I can just edit the patch instead of trying
to generate a new one.

I'll note that anybody who does wish to override the terminal can easily put a
symlink in ~/bin/uxterm that points anywhere they like.

Re: [UPDATE] x11/dwm

[Ted Unangst]

Joerg Jung wrote:
> Hi,
> 
> please find below an update for x11/dwm to 6.1.  This release contains
> various fixes and improvements, see announcement [1] for more details.
> 
> OK?

so now that we finally changed the default xterm back to uxterm, they changed
it to st. needs another man page patch. :)

quake2 crashes

[Ted Unangst]

quake2 on amd64 current.

This problem was also reported two years ago, but the "fix" was apparently to
use a different port which wasn't committed?

http://marc.info/?l=openbsd-ports=137740862509593=2

--- sound initialization ---
/usr/local/bin/quake2:/usr/local/lib/quake2/snd_sndio.so:
/usr/local/bin/quake2 : WARNING: symbol(si) size mismatch, relink your program
loading sndio sound output driver, ok

Program received signal SIGSEGV, Segmentation fault.
0x084704f301e6 in SNDDMA_Init (s=Variable "s" is not available.
) at /usr/obj/ports/quake2-0.3/quake2-0.3/src/snd_sndio.c:66
66  /usr/obj/ports/quake2-0.3/quake2-0.3/src/snd_sndio.c: No such file or
directory.
in /usr/obj/ports/quake2-0.3/quake2-0.3/src/snd_sndio.c

Re: Firefox 41.0.2 with W^X

[Ted Unangst]

David Coppa wrote:
> On Fri, Oct 23, 2015 at 2:01 PM, Martin Pieuchot  wrote:
> > On 22/10/15(Thu) 21:40, Amit Kulkarni wrote:
> >> On Thu, Oct 22, 2015 at 12:26 PM, David Coppa  wrote:
> >>
> >> > On Thu, Oct 22, 2015 at 3:45 PM, Ed Ahlsen-Girard 
> >> > wrote:
> >> > > I have noticed a performance hit since the switch was flipped. Firefox
> >> > > stays at the top of top most of the time, and its CPU percentages have
> >> > > spiked to 175% if multiple tabs were being opened. dmesg below the sig.
> >> >
> >> > Can you try if the attached patch is an improvement?
> >> >
> >>
> >> Hi,
> >>
> >> This CPU spike is present with October 11 packages (Firefox 41.0.1) on
> >> amd64, so it will be difficult to isolate the performance impact of the W
> >> ^X vs the existing situation.
> >
> > FWIW I found that firefox is (ab)using pthread_mutex_trylock(3) a lot
> > resulting in a storm of sched_yield(2) triggering a lot (dozen to
> > hundreds of thousands) of IPIs on my x220.
> >
> > I tried to look at the source code but couldn't figure out where the
> > call of pthread_mutex_trylock(3) are coming from.  Firefox is just a
> > monster.
> >
> > I'm sorry but I agree that if nobody is taking care of this regression
> > it will be really hard to measure the impact of the W^X change.
> >
> 
> Martin,
> 
> Has this problem manifested itself with firefox-41 or was it already
> present with 40.x ?

ktrace is pretty, uh, "enlightening"... This is a firefox process that's idle,
and not even displayed on screen.

Calling gettimeofday in a busy loop is probably not the most efficient means
of implementing a timeout, or whatever it's up to.

 26660 firefox  1446492775.550222 RET   gettimeofday 0
 26660 firefox  1446492775.550258 CALL  gettimeofday(0x4210c4ef548,0)
 26660 firefox  1446492775.550264 RET   gettimeofday 0
 26660 firefox  1446492775.550268 CALL  gettimeofday(0x4210c4ef538,0)
 26660 firefox  1446492775.550273 RET   gettimeofday 0
 26660 firefox  1446492775.550276 CALL  gettimeofday(0x4210c4ef538,0)
 26660 firefox  1446492775.550280 RET   gettimeofday 0
 26660 firefox  1446492775.550284 CALL  gettimeofday(0x4210c4ef548,0)
 26660 firefox  1446492775.550289 RET   gettimeofday 0
 26660 firefox  1446492775.550292 CALL  gettimeofday(0x4210c4ef548,0)
 26660 firefox  1446492775.550297 RET   gettimeofday 0
 26660 firefox  1446492775.550300 CALL  gettimeofday(0x4210c4ef538,0)
 26660 firefox  1446492775.550304 RET   gettimeofday 0
 26660 firefox  1446492775.550308 CALL  gettimeofday(0x4210c4ef548,0)
 26660 firefox  1446492775.550312 RET   gettimeofday 0
 26660 firefox  1446492775.550318 CALL  gettimeofday(0x4210c4ef528,0)
 26660 firefox  1446492775.550322 RET   gettimeofday 0
 26660 firefox  1446492775.550325 CALL  gettimeofday(0x4210c4ef548,0)
 26660 firefox  1446492775.550330 RET   gettimeofday 0
 26660 firefox  1446492775.550333 CALL  gettimeofday(0x4210c4ef538,0)
 26660 firefox  1446492775.550337 RET   gettimeofday 0
 26660 firefox  1446492775.550342 CALL  gettimeofday(0x4210c4ef548,0)
 26660 firefox  1446492775.550346 RET   gettimeofday 0
 26660 firefox  1446492775.550350 CALL  gettimeofday(0x4210c4ef538,0)
 26660 firefox  1446492775.550354 RET   gettimeofday 0
 26660 firefox  1446492775.550358 CALL  gettimeofday(0x4210c4ef538,0)
 26660 firefox  1446492775.550362 RET   gettimeofday 0
 26660 firefox  1446492775.550365 CALL  gettimeofday(0x4210c4ef568,0)
 26660 firefox  1446492775.550370 RET   gettimeofday 0
 26660 firefox  1446492775.550373 CALL  gettimeofday(0x4210c4ef538,0)
 26660 firefox  1446492775.550378 RET   gettimeofday 0
 26660 firefox  1446492775.550381 CALL  gettimeofday(0x4210c4ef538,0)
 26660 firefox  1446492775.550386 RET   gettimeofday 0
 26660 firefox  1446492775.550389 CALL  gettimeofday(0x4210c4ef538,0)
 26660 firefox  1446492775.550393 RET   gettimeofday 0
 26660 firefox  1446492775.550397 CALL  gettimeofday(0x4210c4ef538,0)
 26660 firefox  1446492775.550401 RET   gettimeofday 0
 26660 firefox  1446492775.550404 CALL  gettimeofday(0x4210c4ef538,0)
 26660 firefox  1446492775.550409 RET   gettimeofday 0
 26660 firefox  1446492775.550412 CALL  gettimeofday(0x4210c4ef538,0)
 26660 firefox  1446492775.550416 RET   gettimeofday 0
 26660 firefox  1446492775.550420 CALL  gettimeofday(0x4210c4ef538,0)
 26660 firefox  1446492775.550424 RET   gettimeofday 0
 26660 firefox  1446492775.550428 CALL  gettimeofday(0x4210c4ef528,0)
 26660 firefox  1446492775.550432 RET   gettimeofday 0
 26660 firefox  1446492775.550435 CALL  gettimeofday(0x4210c4ef548,0)
 26660 firefox  1446492775.550440 RET   gettimeofday 0
 26660 firefox  1446492775.550443 CALL  gettimeofday(0x4210c4ef568,0)
 26660 firefox  1446492775.550447 RET   gettimeofday 0
 26660 firefox  1446492775.550451 CALL  gettimeofday(0x4210c4ef498,0)
 26660 firefox  1446492775.550455 RET   gettimeofday 0
 26660 firefox  1446492775.550459 CALL  gettimeofday(0x4210c4ef4a8,0)
 26660 firefox  1446492775.550463 RET   

stop firefox using ghostscript-fonts

[Ted Unangst]

I needed to convert an image file the other day, so I installed ImageMagick
which somewhere along the way requires ghostscript-fonts to be installed as
well.

Now Firefox has also decided it should use these fonts to render webpages,
much to my disappointment. The letters have a very uneven baseline on many
sites.

Besides removing the fonts/ghostscript directory (which I have done short
term), how do I prevent Firefox from picking a new font of the day every time
I install some new packages?

dwm runs xterm

[Ted Unangst]

We have a local patch to dwm so that it runs xterm instead of uxterm. That's
fine, but the man page isn't patched, which is confusing.

Re: dwm runs xterm

[Ted Unangst]

Matthieu Herrb wrote:
> On Thu, Oct 08, 2015 at 12:58:42PM -0300, Gleydson Soares wrote:
> > On Thu, Oct 08, 2015 at 08:39:13AM -0400, Ted Unangst wrote:
> > > We have a local patch to dwm so that it runs xterm instead of uxterm. 
> > > That's
> > > fine, but the man page isn't patched, which is confusing.
> > 
> > yes, 
> > here is a diff to fix that.
> 
> Given that we want to support more of UTF-8, this patch seems
> conterproductive to me.  uxterm is in /usr/X11R6/bin for quite a long
> time now.
> 
> What was the reason for that ?

I think some people don't want to use utf-8 yet? (although we are moving that
way...)

But I've had no trouble using xterm with "XTerm*locale:true" in .Xdefaults and
setting CTYPE.

Forcing people to use uxterm seems meaner than letting them configure xterm
how they like. Also, it's confusing (imo) that all the resources are named
UXTerm, since nearly every web page about xterm you'll find online talks about
XTerm. Seems like just one more gotcha.

Re: dwm runs xterm

[Ted Unangst]

Joerg Jung wrote:
> On Thu, Oct 08, 2015 at 07:05:34PM +0200, Matthieu Herrb wrote:
> > On Thu, Oct 08, 2015 at 12:58:42PM -0300, Gleydson Soares wrote:
> > > On Thu, Oct 08, 2015 at 08:39:13AM -0400, Ted Unangst wrote:
> > > > We have a local patch to dwm so that it runs xterm instead of uxterm. 
> > > > That's
> > > > fine, but the man page isn't patched, which is confusing.
> > > 
> > > yes, 
> > > here is a diff to fix that.
> > 
> > Given that we want to support more of UTF-8, this patch seems
> > conterproductive to me.  uxterm is in /usr/X11R6/bin for quite a long
> > time now.
> 
> Sure, let's drop the patch, diff below.

ok, i guess. this will annoy me because now I have to stick a dozen Us in
Xdefaults after some random pkg_add, but less divergence from upstream seems
like a good thing.

Re: Remove security/cfs

[Ted Unangst]

Jérémie Courrèges-Anglas wrote:
 
 cfs may have been a fine piece of software years ago, it's looking
 pretty bad right now.  DES crypto over NFSv2 on localhost, really?  Also
 not 64 bits safe and full of scary warnings at compile time.  I think
 that softraid CRYPTO, vnconfig(8) and security/encfs shoud be enough.
 
 ok to remove it?

agreed.

Re: Go-1.4.1 on OpenBSD 5.7 i386 fails with SIGILL: illegal instruction

[Ted Unangst]

Stuart Henderson wrote:
 
 I don't think a flavour is warranted, i386 packages are meant to run
 on all supported CPUs so if the runtime detection is insufficient
 we should just always set this variable.

talk to upstream? this sounds like a bug if the runtime detection is
insufficient. unconditionally disabling sse would be a pessimization for most
users.

Re: Remove x11/wterm?

[Ted Unangst]

Christian Weisgerber wrote:
 I would like to remove x11/wterm.  It's another one of the many
 rxvt forks that were popular once upon a time.  This one was intended
 to go along with Windowmaker.
 
 It's the last remaining entry on my list of programs whose tty
 handling needs to be fixed with openpty()/posix_openpt().  I fixed
 all others a few years ago.
 
 wterm is abandoned, the release is from 2001, and it includes two
 different configure scripts (one generated with autoconf 2.12(!))
 and it's unclear which one if any corresponds to configure.in.  I've
 just found a rare Windomaker user (sashan@) and he doesn't use wterm
 either.

even when i used windowmaker, i never used wterm.

Re: Get Ruby 2.2 test suite passing

[Ted Unangst]

Jeremy Evans wrote:
 As an aside, crypt(passwd, $2) returns : instead of NULL.  I'm not
 sure if that's a security issue, but I think it is and we should fix it.
 I'll see if I can get a patch for that and send it to tech@.

This is a weird edge case where niels decided to make bcrypt() work
differently than crypt(). i don't really know why. I think null is the safer
return, and we should probably switch. we don't have code that looks for :
(and certainly no third party code ever does), but there is code that checks
for null.

Re: implicit type coercion in dynamic shared library calls?

[Ted Unangst]

Raul Miller wrote:
 J uses a hack where doubles are passed as long. This works on other
 OSes but not on openbsd.

This seems suspect. There's no guarantee double and long are the same size.

 I was under the impression that gcc passes all values on the stack,
 not in floating point registers or anything like that?

This depends a lot on the CPU, but gcc on openbsd generally behaves the same
as on any other OS with the same CPU.

 I also wind up spending a fair amount of time in ld.so -- maybe I'll
 be able to find my way through all the detail, but mostly I'm just as
 lost using gdb as with any other approach.

I doubt ld.so really has much to do with it.

 Basically, though, I don't know what I am looking for, so I don't know
 how to tell when I am getting close to it.
 
 Does anyone know how I should approach this issue? (Is there anything
 specific to OpenBSD which should be relevant here, or should I
 strictly focus on gcc issues?)

Looking at the disassembly for the stub code may help.

It sounds like you may be missing a prototype somewhere and are getting
implicit conversions.

firefox w^x

[Ted Unangst]

So I was supposed to be working on making the JIT engine conform to W^X a few
months ago. It took a bit longer than expected, but I had a mostly working
patch. Then I disappeared from OpenBSD for a bit and took my patch with me.
Last week I was just starting to feed that patch upstream to firefox, when I
found out about another developer who had already done similar work. Sigh.

The official firefox patch seems likely to ship in some future version, which
is good news for everyone. It's quite similar to the patch I had (though more
polished). To make it available sooner for OpenBSD, here's a backport to the
Firefox in ports.

I haven't been able to test this very much, as I'm still at BSDCan, but when I
get back next week I hope to be able to devote more time to finalizing this
patch. Posting now to let people know it's coming and to give a preview if
you're interested.


--- /dev/null   Sat Jun 13 16:06:25 2015
+++ patches/patch-js_src_irregexp_NativeRegExpMacroAssembler_cppSat Jun 
13 14:16:15 2015
@@ -0,0 +1,12 @@
+$OpenBSD$
+--- js/src/irregexp/NativeRegExpMacroAssembler.cpp.origSat Jun 13 
13:54:41 2015
 js/src/irregexp/NativeRegExpMacroAssembler.cpp Sat Jun 13 13:55:10 2015
+@@ -450,6 +450,8 @@ NativeRegExpMacroAssembler::GenerateCode(JSContext* cx
+ writePerfSpewerJitCodeProfile(code, RegExp);
+ #endif
+ 
++AutoWritableJitCode awjc(code);
++
+ for (size_t i = 0; i  labelPatches.length(); i++) {
+ LabelPatch v = labelPatches[i];
+ MOZ_ASSERT(!v.label);
--- /dev/null   Sat Jun 13 16:06:25 2015
+++ patches/patch-js_src_jit_BaselineCompiler_cpp   Sat Jun 13 14:16:15 2015
@@ -0,0 +1,39 @@
+$OpenBSD$
+--- js/src/jit/BaselineCompiler.cpp.orig   Sat Jun 13 13:55:40 2015
 js/src/jit/BaselineCompiler.cppSat Jun 13 13:57:13 2015
+@@ -226,7 +226,13 @@ BaselineCompiler::compile()
+ // Adopt fallback stubs from the compiler into the baseline script.
+ baselineScript-adoptFallbackStubs(stubSpace_);
+ 
+-// Patch IC loads using IC entries
++// All barriers are emitted off-by-default, toggle them on if needed.
++if (cx-zone()-needsIncrementalBarrier())
++baselineScript-toggleBarriers(true);
++if 
(cx-runtime()-jitRuntime()-isProfilerInstrumentationEnabled(cx-runtime()))
++  baselineScript-toggleProfilerInstrumentation(true);
++AutoWritableJitCode awjc(code);
++
+ for (size_t i = 0; i  icLoadLabels_.length(); i++) {
+ CodeOffsetLabel label = icLoadLabels_[i].label;
+ label.fixup(masm);
+@@ -240,9 +246,6 @@ BaselineCompiler::compile()
+ if (modifiesArguments_)
+ baselineScript-setModifiesArguments();
+ 
+-// All barriers are emitted off-by-default, toggle them on if needed.
+-if (cx-zone()-needsIncrementalBarrier())
+-baselineScript-toggleBarriers(true);
+ 
+ #ifdef JS_TRACE_LOGGING
+ // Initialize the tracelogger instrumentation.
+@@ -260,10 +263,6 @@ BaselineCompiler::compile()
+ 
+ if (compileDebugInstrumentation_)
+ baselineScript-setHasDebugInstrumentation();
+-
+-// If profiler instrumentation is enabled, toggle instrumentation on.
+-if 
(cx-runtime()-jitRuntime()-isProfilerInstrumentationEnabled(cx-runtime()))
+-baselineScript-toggleProfilerInstrumentation(true);
+ 
+ // Always register a native = bytecode mapping entry, since profiler can 
be
+ // turned on with baseline jitcode on stack, and baseline jitcode cannot 
be invalidated.
--- /dev/null   Sat Jun 13 16:06:25 2015
+++ patches/patch-js_src_jit_BaselineJIT_cppSat Jun 13 14:16:15 2015
@@ -0,0 +1,38 @@
+$OpenBSD$
+--- js/src/jit/BaselineJIT.cpp.origSat Jun 13 13:57:28 2015
 js/src/jit/BaselineJIT.cpp Sat Jun 13 13:59:10 2015
+@@ -841,6 +841,8 @@ BaselineScript::toggleDebugTraps(JSScript* script, jsb
+ 
+ SrcNoteLineScanner scanner(script-notes(), script-lineno());
+ 
++AutoWritableJitCode awjc(method());
++
+ for (uint32_t i = 0; i  numPCMappingIndexEntries(); i++) {
+ PCMappingIndexEntry entry = pcMappingIndexEntry(i);
+ 
+@@ -887,6 +889,7 @@ BaselineScript::initTraceLogger(JSRuntime* runtime, JS
+ traceLoggerScriptEvent_ = TraceLoggerEvent(logger, 
TraceLogger_Scripts);
+ 
+ if (TraceLogTextIdEnabled(TraceLogger_Engine) || 
TraceLogTextIdEnabled(TraceLogger_Scripts)) {
++  AutoWritableJitCode awjc(method_);
+ CodeLocationLabel enter(method_, 
CodeOffsetLabel(traceLoggerEnterToggleOffset_));
+ CodeLocationLabel exit(method_, 
CodeOffsetLabel(traceLoggerExitToggleOffset_));
+ Assembler::ToggleToCmp(enter);
+@@ -910,6 +913,8 @@ BaselineScript::toggleTraceLoggerScripts(JSRuntime* ru
+ else
+ traceLoggerScriptEvent_ = TraceLoggerEvent(logger, 
TraceLogger_Scripts);
+ 
++AutoWritableJitCode awjc(method());
++
+ // Enable/Disable the traceLogger prologue and epilogue.
+ CodeLocationLabel enter(method_, 
CodeOffsetLabel(traceLoggerEnterToggleOffset_));
+ 

entire pkg not signed/verified

[Ted Unangst]

I mentioned this before release, when there probably wasn't time to address
it, but it's something I think should be fixed.

Not all of the files installed by pkg_add are verified. For instance, DESC can
be replaced by a forgery and neither pkg_info nor pkg_add will notice. pkg_add
will happily install the bogus DESC file in /var/db/pkg.

A forged DESC may seem harmless, (after all, it's only metadata), but I
believe this is nevertheless a violation of policy and user expectation.

Re: CoreCLR and OpenBSD

[Ted Unangst]

sven falempin wrote:
 On Thu, Mar 19, 2015 at 7:07 PM, Aaron Bieber aa...@bolddaemon.com wrote:
  Should have mentioned what the current hurdles are.  So far the build
  dies because of a few lacking items:
 
  1) libunwind (needed for the GC, also I am told this is not a hard
  requirement)
 
 libunwind depends on a libc extension called Setcontext, which i quote
 wikipedia is somewhat cumbersome to use effectively, this libc
 extension is present on NETBSD and FREEBSD but having this entering
 into openBSD libc may take a long time, even bikeshed are taking time
 here.

setcontext was in posix, then they deleted it. we're unlikely to add very many
obsolete, already deleted functions to libc.

Re: lang/tcl/8.5 or lang/expect backwards memcpy

[Ted Unangst]

Ryan Freeman wrote:
 On Mon, Mar 16, 2015 at 08:00:37PM -0600, Theo de Raadt wrote:
  If you find the right memcpy, it simply needs to be changed to memmove.
  Then try to justify it a bit, and pass it to upstream.
 
 Thanks Theo,
 
 After eyeballing the trace again, i noticed it mentioned the exact
 expect function where the failure was, and grep was helpful to
 narrow it down to a single .c file in expect that has that function.
 
 By process of elimination I ended up with ALL the memcpy-memmove
 so now I am going to work backwards to find the exact one that causes
 the abort trap.  The good news is it stopped crashing!  But not sure
 which one really needed it.
 
 Will work with upstream on getting it integrated, patch is below
 if anyone doesn't mind telling me 'hey that shouldn't be memmove'.
 
 So /before/ i try and narrow it down to just one, is there a chance
 this is a case where they should just all be memmove?
 
 
 $OpenBSD$
 --- exp_inter.c.orig  Mon Mar 16 20:27:50 2015
 +++ exp_inter.c   Mon Mar 16 20:53:51 2015
 @@ -474,7 +474,7 @@ intRead(
  }
  
  if (cc  0) {
 -memcpy (esPtr-input.buffer + esPtr-input.use,
 +memmove (esPtr-input.buffer + esPtr-input.use,
   Tcl_GetUnicodeFromObj (esPtr-input.newchars, NULL),
   cc * sizeof (Tcl_UniChar));

I don't know exactly what that function does, it's possible memcpy is safe
here. But there is nothing wrong with memmove if you're not sure.

The ones below obviously require memmove. the source and destination have the
same base (ustring or u-buffer).

   esPtr-input.use += cc;
 @@ -1564,7 +1564,7 @@ Exp_InteractObjCmd(
   ustring = u-input.buffer;
   if (skip) {
   size -= skip;
 - memcpy(ustring, ustring + skip, size * sizeof(Tcl_UniChar));
 + memmove(ustring, ustring + skip, size * sizeof(Tcl_UniChar));
   }
   }
   u-input.use = size;
 @@ -1824,12 +1824,12 @@ got_action:
   skip += matchLen;
   size -= skip;
   if (size) {
 - memcpy(u-buffer, u-buffer + skip, size);
 + memmove(u-buffer, u-buffer + skip, size);
   }
   } else {
   if (skip) {
   size -= skip;
 - memcpy(u-buffer, u-buffer + skip, size);
 + memmove(u-buffer, u-buffer + skip, size);
   }
   }
   Tcl_SetObjLength(size);
 @@ -2070,12 +2070,12 @@ got_action:
   skip += matchLen;
   size -= skip;
   if (size) {
 - memcpy(u-buffer, u-buffer + skip, size);
 + memmove(u-buffer, u-buffer + skip, size);
   }
   } else {
   if (skip) {
   size -= skip;
 - memcpy(u-buffer, u-buffer + skip, size);
 + memmove(u-buffer, u-buffer + skip, size);
   }
   }
   Tcl_SetObjLength(size);
 

node 12 patches

[Ted Unangst]

for safe keeping, i needed this patch to build stock node 0.12 (from scratch,
without any of the existing port stuff).



diff -ru orig/node-v0.12.0/deps/v8/src/base/macros.h 
node-v0.12.0/deps/v8/src/base/macros.h
--- orig/node-v0.12.0/deps/v8/src/base/macros.h Fri Feb  6 15:04:23 2015
+++ node-v0.12.0/deps/v8/src/base/macros.h  Tue Mar  3 15:53:49 2015
@@ -146,8 +146,8 @@
 #  define V8_UINT64_C(x)   (x ## ULL)
 #  define V8_INT64_C(x)(x ## LL)
 # else
-#  define V8_UINT64_C(x)   (x ## UL)
-#  define V8_INT64_C(x)(x ## L)
+#  define V8_UINT64_C(x)   (x ## ULL)
+#  define V8_INT64_C(x)(x ## LL)
 # endif
 # define V8_INTPTR_C(x)   (x ## L)
 # define V8_PTR_PREFIXl
diff -ru orig/node-v0.12.0/deps/v8/src/base/platform/platform-posix.cc 
node-v0.12.0/deps/v8/src/base/platform/platform-posix.cc
--- orig/node-v0.12.0/deps/v8/src/base/platform/platform-posix.cc   Fri Feb 
 6 15:04:23 2015
+++ node-v0.12.0/deps/v8/src/base/platform/platform-posix.ccTue Mar  3 
16:07:05 2015
@@ -328,7 +328,8 @@
 #elif V8_OS_ANDROID
   return static_castint(gettid());
 #else
-  return static_castint(pthread_self());
+  return static_castint(getthrid());
+  //return static_castint(pthread_self());
 #endif
 }
 
Only in node-v0.12.0/deps/v8/tools: jsmin.pyc
Only in node-v0.12.0: fib.js
Only in node-v0.12.0: icu_config.gypi
Only in node-v0.12.0: node
Only in node-v0.12.0: out
diff -ru orig/node-v0.12.0/src/cares_wrap.cc node-v0.12.0/src/cares_wrap.cc
--- orig/node-v0.12.0/src/cares_wrap.cc Fri Feb  6 15:04:23 2015
+++ node-v0.12.0/src/cares_wrap.cc  Tue Mar  3 16:08:30 2015
@@ -1301,8 +1301,10 @@
   Integer::New(env-isolate(), AF_UNSPEC));
   target-Set(FIXED_ONE_BYTE_STRING(env-isolate(), AI_ADDRCONFIG),
   Integer::New(env-isolate(), AI_ADDRCONFIG));
+#ifdef AI_V4MAPPED
   target-Set(FIXED_ONE_BYTE_STRING(env-isolate(), AI_V4MAPPED),
   Integer::New(env-isolate(), AI_V4MAPPED));
+#endif
 
   LocalFunctionTemplate aiw =
   FunctionTemplate::New(env-isolate(), NewGetAddrInfoReqWrap);

Re: Strange problem with Asterisk 11 on 5.7

[Ted Unangst]

Philip Guenther wrote:
 On Mon, 23 Feb 2015, Alexey Suslikov wrote:
 ...
   12995 asterisk RET   fork 0
   12995 asterisk CALL  
  sigprocmask(SIG_SETMASK,0x8005003SIGHUP|SIGINT|SIGPIPE|SIGTERM|SIGWINCH)
   12995 asterisk RET   sigprocmask ~0x10100SIGKILL|SIGSTOP
   12995 asterisk CALL  getthrid()
   12995 asterisk RET   getthrid 1012995/0xf7503
   12995 asterisk PSIG  SIGSEGV SIG_DFL code SEGV_MAPERR1 
  addr=0x181489355e40 trapno=6
 
 So it's not even getting to ast_set_priority() or ast_close_fds_above_n().
 
 pause
 
 Ooog, this is probably caused by a pthread_atfork() handler from a shared 
 object.
 
 The easiest way to test this hypothesis is to change this code:
   #ifdef HAVE_WORKING_FORK
   pid = fork();
   #else
   pid = vfork();
   #endif
 
 to just
 pid = vfork();
 
 
 and see if the problem goes away...

I don't know what's going on here, but I'll note that rthread_atfork.c hasn't
changed since before 5.5.

Re: Strange problem with Asterisk 11 on 5.7

[Ted Unangst]

Stuart Henderson wrote:
 On 2015/02/24 10:48, Ted Unangst wrote:
  
  I don't know what's going on here, but I'll note that rthread_atfork.c 
  hasn't
  changed since before 5.5.
 
 What changed is p11-kit's atfork handler. Reverting this commit
 fixes AGI in asterisk. (URL here, their diff inline below).


 --- a/common/library.c
 +++ b/common/library.c
 @@ -111,6 +120,8 @@ p11_library_init_impl (void)
   p11_mutex_init (p11_library_mutex);
   pthread_key_create (thread_local, free);
   p11_message_storage = thread_local_message;
 +
 + pthread_atfork (NULL, NULL, count_forks);

 --- a/p11-kit/modules.c
 +++ b/p11-kit/modules.c
 @@ -719,9 +695,6 @@ init_globals_unlocked (void)
   if (once)
   return CKR_OK;
  
 -#ifdef OS_UNIX
 - pthread_atfork (NULL, NULL, reinitialize_after_fork);
 -#endif

Reading the tea leaves, I'm guessing the first function, where pthread_atfork
lives now, is called immediately after dlopen(), whereas the second function
was only called if you actually used the library.

Moving the call back to where it used to be may work, but I'm not especially
experienced with interpreting these particular leaves.

Re: Checking package signatures?

[Ted Unangst]

Christian Weisgerber wrote:
 What's the best way to check the signatures and integrity of a bunch
 of OpenBSD packages?  pkg_add -n or -s do this, but they produce
 too much unrelated spew.  pkg_info does not check the signature.
 
 The CDs and FTP mirrors tend to have SHA256.sig files at the directory
 level, but shouldn't there be an easy way to use the embedded
 signatures for this?

If I'm not mistaken, pkg* will use the index.txt file to find matches, which
is how pkg_add vim knows which vims to ask me about. Maybe it should use the
SHA256.sig file instead? It contains all the necessary information (filenames)
and is hardly any bigger.

-rw-r--r--  1 tedu  tedu  697874 Feb 17 16:39 SHA256.sig
-rw-r--r--  1 tedu  tedu  662931 Feb 17 16:39 index.txt

I'm not sure what you're after, though. Do you want to check a mirror is good
before downloading? Even the embedded signature requires downloading the full
package to verify the contents are good. Checking SHA256.sig will be a little
faster since it doesn't require unpacking and file by file comparison.

An option to only check the signature on the plist would be interesting,
though I'd be a little concerned that it may return success even though the
package contents are wrong.

BTW, I found a bug. Even pkg_add doens't check the +DESC file. I modified the
DESC for colorls, and now I have this:

 pkg_info colorls
Information for inst:colorls-5.6p0

Comment:
ls that can use color to display file attributes

Description:
It's a trap!!!

I don't pkg_add should have installed that package. It's obvously a trap. :)

pkg_info and pkg_add should always be checking +DESC.

luasocket smtp broken

[Ted Unangst]

The luasocket pkg does not include the headers.lua file.

/usr/local/share/lua/5.1/socket/headers.lua

Lua 5.1.5  Copyright (C) 1994-2012 Lua.org, PUC-Rio
 require socket.smtp
/usr/local/share/lua/5.1/socket/smtp.lua:18: module 'socket.headers' not found:

w^x patch for luajit

[Ted Unangst]

On i386, it's better for a jit to ask for exec memory upfront, so uvm
knows to place it in the exec segment. Otherwise, if you mmap non-exec
and mprotect it, you wind up with a high mapping and the segment must
be enlarged to cover the whole process.

I sent Mike a slightly different diff; this is what he ended up
committing to git. I think we should add it to the port.

diff --git a/src/lj_mcode.c b/src/lj_mcode.c
index f8f8406..d95ebeb 100644
--- a/src/lj_mcode.c
+++ b/src/lj_mcode.c
@@ -145,7 +145,7 @@ static void mcode_free(jit_State *J, void *p, size_t sz)
 
 /* -- MCode area protection --- */
 
-/* Define this ONLY if the page protection twiddling becomes a bottleneck. */
+/* Define this ONLY if page protection twiddling becomes a bottleneck. */
 #ifdef LUAJIT_UNPROTECT_MCODE
 
 /* It's generally considered to be a potential security risk to have
@@ -252,7 +252,20 @@ static void *mcode_alloc(jit_State *J, size_t sz)
 #else
 
 /* All memory addresses are reachable by relative jumps. */
-#define mcode_alloc(J, sz) mcode_alloc_at((J), 0, (sz), MCPROT_GEN)
+static void *mcode_alloc(jit_State *J, size_t sz)
+{
+#ifdef __OpenBSD__
+  /* Allow better executable memory allocation for OpenBSD W^X mode. */
+  void *p = mcode_alloc_at(J, 0, sz, MCPROT_RUN);
+  if (p  mcode_setprot(p, sz, MCPROT_GEN)) {
+mcode_free(J, p, sz);
+return NULL;
+  }
+  return p;
+#else
+  return mcode_alloc_at(J, 0, sz, MCPROT_GEN);
+#endif
+}
 
 #endif
 

Re: java coders are complete morons

[Ted Unangst]

On Wed, Dec 31, 2014 at 02:23, Stuart Henderson wrote:
 On 2014/12/31 00:13, Marc Espie wrote:
 well, jdk 1.7 just stopped building. because one file is 10 years old and
 there is an explicit check for that in the build process.

 Just think about it.
 
 Can't go perpetuating 10-year-old currencies, that would be terrible!
 
 This should be reasonable until openjdk catches up with the newer files
 from java 8.
 +-if (Math.abs(time - System.currentTimeMillis())  ((long)
 10) * 365 * 24 * 60 * 60 * 1000) {
 +-throw new RuntimeException(time is more than 10 years
 from present:  + time);
 +-}

Maybe we should only change it to eleven years? Kind of like how
the government does emergency budget extensions? /ducks and runs...

Re: please remove the procmail port

[Ted Unangst]

On Sun, Dec 28, 2014 at 22:18, Antoine Jacoutot wrote:
 On Sun, Dec 28, 2014 at 02:09:24PM +0100, Stefan Sperling wrote:
 On Tue, Nov 18, 2014 at 12:42:37PM -0800, Philip Guenther wrote:
 
  Executive summary: delete the procmail port; the code is not safe and
  should not be used as a basis for any further work.

 It's still in ports. Has it not been deleted for a particular reason?
 
 What's the rush to remove it? What Philip said? Well in this case you can
 remove 75% of the ports tree.
 Not that I care, I'm just saying... because we're not talking about some
 obscure thing no one uses.
 Also, IIRC some other ports depend on it.

I think the concern is indeed, that people do use it. We have a lot of
crap ports that people don't use, but that's fine. They're not used.

For certain packages that are popular and dangerous, I think it makes
sense to remove them. People will ask where it went, and then we guide
them to better alternatives. We deleted the ethereal port, for example.

Re: lsof in 5.6

[Ted Unangst]

On Thu, Dec 18, 2014 at 02:26, Alan Corey wrote:
 This was from the 5.6 release from a mirror site
 ftp://filedump.se.rit.edu/pub/OpenBSD/5.6/ports.tar.gz somewhere
 around November 10
 
 If you look at /usr/ports/sysutils/lsof/patches/patch-dialects_n+obsd_dlsof_h
 is there mention of adding support for tmpfs?  Apparently something
 there wasn't finished.  I have no tmpfs.h

Like I said, the port adds an include path to the kernel source, so
that it does have tmpfs. You're not supposed to have tmpfs in
/usr/include. The port is supposed to add -I/usr/src/sys. It does.

Re: lsof in 5.6

[Ted Unangst]

On Tue, Dec 16, 2014 at 22:11, Alan Corey wrote:
 It seems to be trying to reference tmpfs/tmpfs.h and of course there
 isn't one.  It's the same distfile that was used in 5.2 and that's OK
 so maybe it's something in the patches that are done?
 
 Maybe this has already been reported, I didn't check.
 
 cc  -DOPENBSDV=5000 -DN_UNIXV=/dev/ksyms -DHASNFSPROTO -DHASIPv6
 -DHASI_E2FS_PTR -DHASEXT2FS=2 -DHASEFFNLINK=i_effnlink -DHAS_DINODE_U
 - -DHASI_FFS1 -DHAS_UM_UFS -DHASNCVPID -DUVM -DHAS_UVM_INCL -DHAS_SYS_P
 IPEH
 - - -DHASKVMGETPROC2 -DHASKVMGETPROCS -DHAS_STRFTIME -DLSOF_VSTR=5.6
 -O2
 - - - -pipe   -c dvch.c

Your compile line appears broken. It should have -I/usr/src/sys or
something like that.

Re: analog: backwards memcpy

[Ted Unangst]

On Fri, Dec 05, 2014 at 07:02, Otto Moerbeek wrote:
 On sparc64:
 
 (gdb) bt
 #0  abort () at /usr/src/lib/libc/stdlib/abort.c:59
 #1  0x0010438f1ba8 in memcpy (dst0=0x101096600a, src0=0x64, length=15)

Something went wrong here. Those aren't overlapping addresses. :)

The abort triggered, though, so I suspect the stack trace is wrong, at
least about the src argument.

ssl handshake errors with python

[Ted Unangst]

I see errors trying to download some https URLs using python, but the
base ftp client isn't affected. 5.6 release and current. One example is 
https://www.duosecurity.com/feed.

athens:/tmp python2.7
Python 2.7.8 (default, Oct  6 2014, 13:51:42) 
[GCC 4.2.1 20070719 ] on openbsd5
Type help, copyright, credits or license for more information.
 import urllib
 urllib.urlopen('https://www.duosecurity.com/feed')
Traceback (most recent call last):
  File stdin, line 1, in module
  File /usr/local/lib/python2.7/urllib.py, line 87, in urlopen
return opener.open(url)
  File /usr/local/lib/python2.7/urllib.py, line 208, in open
return getattr(self, name)(url)
  File /usr/local/lib/python2.7/urllib.py, line 437, in open_https
h.endheaders(data)
  File /usr/local/lib/python2.7/httplib.py, line 991, in endheaders
self._send_output(message_body)
  File /usr/local/lib/python2.7/httplib.py, line 844, in _send_output
self.send(msg)
  File /usr/local/lib/python2.7/httplib.py, line 806, in send
self.connect()
  File /usr/local/lib/python2.7/httplib.py, line 1198, in connect
self.sock = ssl.wrap_socket(sock, self.key_file, self.cert_file)
  File /usr/local/lib/python2.7/ssl.py, line 392, in wrap_socket
ciphers=ciphers)
  File /usr/local/lib/python2.7/ssl.py, line 148, in __init__
self.do_handshake()
  File /usr/local/lib/python2.7/ssl.py, line 310, in do_handshake
self._sslobj.do_handshake()
IOError: [Errno socket error] [Errno 1] _ssl.c:510: error:14077410:SSL 
routines:SSL23_GET_SERVER_HELLO:sslv3 alert handshake failure
 

athens:/tmp ftp https://www.duosecurity.com/feed
Trying 54.192.22.134...
Requesting https://www.duosecurity.com/feed
118278 bytes received in 0.17 seconds (673.14 KB/s)

Re: update: libqrencode-3.4.3

[Ted Unangst]

On Sun, Feb 02, 2014 at 15:51, James Turner wrote:
 Attached is an update to libqrencode that brings it all the way up to
 3.4.3. I needed an updated version that included the -t option.
 
 It looks like graphics/prison and productivity/glabels are the only
 consumers. Any users of either of those willing to test?
 
 I've tested libqrencode on amd64. Thanks.
 

Good grief, I find myself in the sad position of asking for an update
to libqrencode. I note that one more dot release is out and the
current version is 3.4.4 now.

Re: OpenBSD MinGW Error: windows.h: No such file or directory

[Ted Unangst]

On Sat, Nov 01, 2014 at 15:09, Jorge Castillo wrote:

Best asked on the ports@ list.

 The following applies to OpenBSD 5.5  5.6, I didn't tried this with any
 previous release. I am runnig OpenBSD in VirtualBox.
 
 This:
 /usr/local/share/doc/pkg-readmes/mingw-1.0.1p3
 
 Says that all you have to do to compile an exe is:
 
 $ export PATH=/usr/local/mingw32/bin:${PATH}
 $ g++ CreateFile.cpp -o CreateFile.exe
 
 But I get a bunch of errors. After googling and trying a few things,
 I got this to work by doing it this way:
 
 $ g++ -I/usr/local/mingw32/include CreateFile.cpp -o CreateFile.exe
 
 I tested this solution with the provided test code in the pkg-readme 
 a very small non GUI program I did for a school assignment. The exes
 worked fine in a Windows7 x64 virtual machine.
 
 Is this the obvious solution to the error or am I doing something wrong?

There could be a doc bug, but it seems like that path should be a
default include path for a mingw compiler.

Re: firefox cursors are all different

[Ted Unangst]

On Thu, Oct 09, 2014 at 18:17, Enric Morales wrote:

 I think the new cursors come from a GTK-related package. The issue
 with
 the poop-looking icon appears in gtk-demo and gimp. I started having
 this issue after a full update a couple days ago.
 
 The solution is really simple:
 
 # rm -rf /usr/local/share/icons/Adwaita/cursors/

Problem solved! Thank you.

Next question: Why in the world is firefox loading something called
Adwaita by default?

firefox cursors are all different

[Ted Unangst]

I upgraded to a new snapshot and ran pkg_add -u. gio-querymodules shit
its pants a few times, but otherwise seemed succesful.

.libs-firefox-26.0p1+.libs-firefox-29.0.1+firefox-32.0-firefox-32.0: ok

However, now the new firefox has these great big honking stupid
cursors instead of the nice cursors it used to have. The arrow is too
big, the I text cursor has an ugly outline, and the hand looks more
like the poop emoji than a hand. How do I get the good cursors back?

Re: Postgres cannot load plpython

[Ted Unangst]

On Tue, Sep 23, 2014 at 22:57, Nick Guenther wrote:
 
 
 On September 23, 2014 8:12:36 PM EDT, Stuart Henderson st...@openbsd.org
 wrote:
On 2014/09/23 17:27, Nick Guenther wrote:
 LD_PRELOAD,
/usr/local/share/doc/pkg-readmes/postgresql-plv8-* explains this too.

 But I do not understand why libpthread.so refuses to load if the
system
 knows it needs it.

libpthread is special
 
 Sorry for the noise and thank you for taking the time to answer me anyway.
 I guess linux is less restrictive about dlopen(), then?

This is a somewhat artificial limitation of the way libc and
libpthread interact. We don't support becoming threaded after
programs have already started, but long (long long) term, moving
better thread support into libc will eliminate the restriction.

Re: mail/dovecot: fix after COMP removal and LibreSSL version crank

[Ted Unangst]

On Sat, Jul 12, 2014 at 18:27, Pascal Stumpf wrote:
 There are two distinct problems here:
 
 * configure tests for SSL compression by checking for the presence of
 SSL_get_current_compression().  That blows up with LibreSSL.  I think we
 could convince upstream to skip the configure test and simply use
 OPENSSL_NO_COMP.

This is interesting. I initially deleted this function, but then jsing
added it back. Would things work better if the function were
completely gone?

Re: New pkg tool: pkg_readme

[Ted Unangst]

On Tue, Jul 08, 2014 at 18:54, Vadim Zhukov wrote:
 Hoping that /usr/sbin isn't full yet... This makes easier to get to
 package readme files:
 
 - Now you'll have exact command to view all added/changed readme
 files printed right after pkg_add(1) run;
 
 - You can simply type pkg_readme mysql if you're not sure what
 and where in MySQL you need to tweak, and still get there.
 
 kirby@ already liked it. Any more thoughts?

As I recall from the discussion when the readme files were
semi-standardized, you're supposed to just cat the files. They're in a
known location, the user can find them without too much trouble.

firefox eats my mouse cursor

[Ted Unangst]

Whenever firefox displays some overlay dialog, the mouse cursor
disappears. It is super annoying when it happens for a save password
dialog, because I can't see what I'm about to click, so I have to just
press esc.

Easy repro: go to the google box on top right, and type app then
pause. When the suggestions show up, the mouse is gone.

I'm using dwm on amd64.

Re: firefox eats my mouse cursor

[Ted Unangst]

On Wed, Jun 18, 2014 at 14:49, Ted Unangst wrote:
 Whenever firefox displays some overlay dialog, the mouse cursor
 disappears. It is super annoying when it happens for a save password
 dialog, because I can't see what I'm about to click, so I have to just
 press esc.
 
 Easy repro: go to the google box on top right, and type app then
 pause. When the suggestions show up, the mouse is gone.
 
 I'm using dwm on amd64.

And a minute later figured it out. I'm also using xbanish. I suppose
xbanish hides the mouse, but then it never comes back as long as
firefox has an overlay on the screen.