<ajacoutot@cvs.openbsd.org> wrote:
> CVSROOT: /cvs
> Module name: ports
> Changes by: ajacoutot@cvs.openbsd.org 2014/08/23 01:33:11
>
> Modified files:
> sysutils/salt/pkg: PLIST
>
> Log message:
> install_egg_info() behaves differently on some machines; fix the egg-info
> file to match the most successful ones (I will have a look at the
> underlying issue).

Did you have a chance to look at this yet? This currently fails to
package on my machine, does package with this change reverted (so
having 2014.1.10 in the PLIST, not 2014.1.0)
--
viq

Module name: src
Changes by: bluhm@cvs.openbsd.org 2014/08/31 16:11:43

Modified files:
usr.sbin/syslogd: syslogd.c

Log message:
The reapchild() signal handler collects all children. This can be
done easier by ignoring SIGCHLD.
OK guenther@

http://undeadly.org/cgi?action=article&sid=20140904174329

Contributed by [jj](http://www.inet6.se) on Thu Sep 4 08:00:26 2014 (GMT)
from the frankensteins terminal dept.

Nagy Gábor writes in with a tip:
Tmux is great, except when you have to restart the computer. You lose all the running programs, working directories, pane layouts etc. There are helpful management tools out there, but they require initial configuration and continuous updates as your workflow evolves or you start new projects.


[tmux-resurrect](https://github.com/tmux-plugins/tmux-resurrect) saves all the little details from your tmux environment so it can be completely restored after a system restart (or when you feel like it).
No configuration is required, you should feel like you never quit tmux. It even (optionally) restores vim sessions!
Here's what's been taken care of:


* all sessions, windows, panes and their order
* current working directory for each pane
* exact pane layouts within windows
* active and alternative session
* active and alternative window for each session
* windows with focus
* active pane for each window
* programs running within a pane!
* restoring vim sessions (optional).

http://undeadly.org/cgi?action=article&sid=20140905084104

Contributed by [jj](http://www.inet6.se) on Fri Sep 5 08:31:57 2014 (GMT)
from the when will bsdnow serve episodes using http(8) dept.

On the 1 year anniversary [episode](http://www.bsdnow.tv/episodes/2014_09_03-its_hammer_time) of [BSDNow](http://www.bsdnow.tv/), Kris and Allan interview OpenBSD's Reyk Flöter (reyk@) about the new [httpd(8)](http://www.openbsd.org/cgi-bin/man.cgi/OpenBSD-current/man8/httpd.8), in addition to the week's odds and ends in the world of BSD.

**[** [Video](http://www.podtrac.com/pts/redirect.mp4/201406.jb-dl.cdn.scaleengine.net/bsdnow/2014/bsd-0053-432p.mp4) **|** [HD Video](http://www.podtrac.com/pts/redirect.mp4/201406.jb-dl.cdn.scaleengine.net/bsdnow/2014/bsd-0053.mp4) **|** [MP3 Audio](http://www.podtrac.com/pts/redirect.mp3/traffic.libsyn.com/jnite/bsd-0053.mp3) **|** [OGG Audio](http://www.podtrac.com/pts/redirect.ogg/traffic.libsyn.com/jnite/bsd-0053.ogg) **|** [Torrent](http://bitlove.org/jupiterbroadcasting/bsdnowhd) **]**

http://undeadly.org/cgi?action=article&sid=20140908113732

Contributed by tbert on Fri Sep 5 04:39:36 2014 (GMT)
from the i will always 2q dept.

Ted Unangst (tedu@) wrote a [blog post]() about his replacement of the simple LRU buffer cache algorithm with a 2Q-ish one:

> Since the dawn of time, the OpenBSD buffer cache replacement algorithm has been LRU. It’s not always ideal, but it often comes close enough and it’s simple enough to implement that it’s remained the tried and true classic for a long time. [I just changed the algorithm](http://marc.info/?l=openbsd-cvs&m=140951935412282&w=2) to one modelled somewhat after the [2Q algorithm by Johnson and Shasha](http://dl.acm.org/citation.cfm?id=672996). ([PDF](http://www.vldb.org/conf/1994/P439.PDF))

> **LRU**
>
> LRU is simple enough it doesn’t require much explanation. Keep a list of all buffers. Whenever you use one, put it on the front of the list. Whenever you need a new (recycled) buffer, take it from the end of the list. Those are the oldest, least recently used buffers. In high level terms, the current working set is at the front of the list and the previous working set is fading away off the end. It’s responsive to changes in the working set, very quickly replacing old unused buffers with the latest. In other words, it has a short history; it’s not “sticky”.
>
> This strength is also a weakness. LRU is particularly vulnerable to erroneous replacement during scanning; i.e. it’s not scan resistant. After weeks of uptime, your system is running great and everything you need from disk is in cache. Then you download a few Linux ISOs to see what the fuss is about. Suddenly, even simple commands like ps need to be read in from disk. Seek, seek, thrash, seek, grind. Should have bought an SSD. What happened? Those ISOs were so large that they pushed everything out of the disk cache. (The obvious optimization, to only cache reads and not writes, doesn’t help here because you’re equally obviously going to run sha256 and checksum those ISOs, leading to the same result.)
>
> This problem has been known for long time, but thanks again to the short history rarely causes permanent damage. And caches with history are often harder to implement due to the additional state tracking required, and they can even suffer from too much history. After weeks of uptime, the exec pages for a command like ls are going to be pegged in memory. What if you catch color fever and switch to using colorls? Sorry, those plain ls buffers aren’t going to be recycled. Eldritch buffers are eldritch.
>
> At the hackathon I decided to look into the problem of scan resistance a little more. A hundred CS papers have proposed better algorithms; I settled on 2Q. Or at least something inspired by it, as the final result is more or less different depending on your squint.
>
> **2Q**
>
> Reading the paper is the best way to understand exactly what they’re doing. I’ll just summarize the highlights that I thought were applicable. The main insight is that in addition to LRU’s current working set and previous working set, there’s a third working set: the long term working set. We start by assuming that a buffer is in the current working set, then quickly move it to the previous working set (or sets; they keep quite a long history). If we need that buffer again, that’s a hint that it’s really in the long term working set. To conserve memory, 2Q doesn’t actually keep the previous working set data cached in memory. Only the addresses are retained which is enough to determine when a cache miss is new data vs previously seen data.
>
> The 2Q algorithm is scan resistant. The memory reserved for current working set is kept quite small; most of it is dedicated to long term. This keeps transient data out. At the same time, the long term list is itself managed as LRU, so it’s responsive to changes. All good.
>
> **bufcache**
>
> Earlier, I refactored the buffer cache interface so that the line between the buf cache and buf midlayer was better defined. The bufcache family of functions does all the work now, allowing us to make algorithm changes in one place. At the time I was experimenting with a different LFU style algorithm, but it was sufficient to prove the interface would work. 2Q represents the first real world test.
>
> **not quite 2Q**
>
> The code in OpenBSD resembles 2Q, but contains some significant differences as well. In large part, this is because I had another priority: ease of implementation. 2Q keeps a history of past buffer addresses to know when a miss was previously in the cache; bufcache doesn’t provide that capability in its current form. There were some other obstacles as well. The result is that I tried to implement the simplest variation I could, while also considering future plans. There are comments in the code as well, but I repeat the explanation here.
>
> We retain the key three working set distinction. In the OpenBSD code, they are named hot, cold, and warm, and each is an LRU queue. New buffers start hot. They stay that way as long as they remain on the hot queue. Eventually, a buffer will slip from the end of the hot queue onto the front of the cold queue. (We preserve the data, not just the address.) When a new buffer is needed, we recycle one from the tail of the cold queue. The oldest and coldest. If, on the other hand, we have a cache hit on a cold buffer, it turns into a warm buffer and goes to the front of the warm queue. Then as the warm queue lengthens, buffers start slipping from the end onto the cold queue. Both the hot and warm queues are capped at one third of memory each to ensure balance.
>
> Scan resistance is achieved by means of the warm queue. Transient data will pass from hot queue to cold queue and be recycled. Responsiveness is maintained by making the warm queue LRU so that expired long term set buffers fade away.
>
> **results**
>
> In some ad hoc md5 some large files testing, I confirmed the contents of the bin directory remained in cache when they otherwise would not. Other interactive responsiveness testing went well, too. The primary goal had been to achieve some degree of scan resistance: mission accomplished.
>
> The 2Q paper results are based on replaying traces in a simulator, which is the kind of thing you have to do to get papers published, but which also means they didn’t have to integrate with an existing system which anybody used. I’m not trying to publish a paper, so my results are lacking, but I did have to weld this thing into the existing kernel’s buf layer, which is why it didn’t come out quite the same. I’m all about rigor, as long somebody else does the work.
>
> **future**
>
> The numbers and ratios for the various queue lengths may need tuning. The current design and numbers were selected in part to minimize regressions, not maximize performance. One hopeful change is to finally add support for highmem on amd64 systems. The same algorithm that works to balance between hot and warm queues will work to balance between low and high mem. Now at least we have a launch point for future efforts to build upon.
>
> A name? TU-Q?

http://undeadly.org/cgi?action=article&sid=20140912072316

Contributed by [jj](http://www.inet6.se) on Fri Sep 12 07:22:07 2014 (GMT)
from the kiss-blowfish-get-free-lip-piercing dept.

Solar Designer posted on the openwall announce list about the recent status on using FPGAs to crack bcrypt passwords.


> From: Solar Designer <solar [a/t] openwall.com>
Subject: Energy-efficient bcrypt cracking (Passwords^14, Skytalks, WOOT '14 slides and paper); crypt_blowfish 1.3


> Katja Malvoni has given 3 talks at conferences in the US earlier in August at PasswordsCon Las Vegas, Skytalks, and USENIX WOOT '14. We've also submitted an academic paper to WOOT.
All of these reflect progress we made at the "Energy-efficient bcrypt cracking" project since last year. Here are the new slides, download links, and YouTube video link:

<http://www.openwall.com/presentations/Passwords14-Energy-Efficient-Cracking/>

The talk video includes a live demo of bcrypt hash cracking with modified John the Ripper on several of the energy-efficient boards. For reference, here's last year's announcement:

<http://www.openwall.com/lists/announce/2013/12/03/1>

New since last year are much improved results for FPGAs, in particular for Xilinx Zynq 7020 and 7045. The latter achieves what's probably the highest bcrypt cracking speed per chip that has been actually demonstrated so far (for any kind of chip, including CPUs and GPUs), as well as the highest energy-efficiency, although indeed even higher speeds are currently possible (e.g. on FPGAs that are bigger yet).

In particular, for bcrypt cost 5 the speed on Zynq 7045 is 20538 c/s, and for cost 12 it is 226 c/s (higher efficiency than for cost 5). Similarly expensive Xeon E5-2670 is 2.4x to 3.3x slower than Zynq 7045 on this test, yet consumes ~20x more power; GPUs are way behind.

The inexpensive Zynq 7020 now achieves speeds that are on par with CPUs and GPUs, but at much greater energy efficiency. We're going to continue the project, targeting other FPGAs and multi-FPGA boards.

We continue to recommend use of bcrypt for now. The crypt cracking speedups and energy efficiency improvements achieved so far are very important, but are not fatal to its continued use for a while longer. This is a short-term recommendation.

2\. I released crypt_blowfish 1.3 back in July:
<http://www.openwall.com/crypt/>

Version 1.3 adds support for the $2b$ prefix introduced in OpenBSD 5.5+, which behaves exactly the same as crypt_blowfish's $2y$ did and still does. This way, full compatibility with OpenBSD's bcrypt is achieved at the new $2b$ prefix. crypt_blowfish 1.3 is already included in Owl-current builds (including the ISO images) made in July.

I'd like to thank the OpenBSD project for providing this avenue for us to achieve full compatibility between the implementations despite of the mistakes made previously. To be more confident there is indeed full compatibility, I wrote and ran a test suite cross-testing the two implementations, including on weird and invalid inputs. For the curious, it can now be found as bcrypt-tester-1.0.tar.gz under:

<http://download.openwall.net/pub/projects/crypt/>

although there should be no need to run it (again).
As usual, any feedback is welcome.

http://undeadly.org/cgi?action=article&sid=20140912111017

Contributed by tbert on Fri Sep 12 10:58:07 2014 (GMT)
from the better than incendiary dept.

In [this week's episode](http://www.bsdnow.tv/episodes/2014_09_10-luminary_environment), the [BSDNow](http://www.bsdnow.tv/) crew discusses the week's dealings in the world of BSD, with a decent focus on OpenBSD's systemd-shim GSoC project, OpenBSD's versioning schemes, and the OpenBSD port of portscout.

**[** [Video](http://www.podtrac.com/pts/redirect.mp4/201406.jb-dl.cdn.scaleengine.net/bsdnow/2014/bsd-0054-432p.mp4) **|** [HD Video](http://www.podtrac.com/pts/redirect.mp4/201406.jb-dl.cdn.scaleengine.net/bsdnow/2014/bsd-0054.mp4) **|** [MP3 Audio](http://www.podtrac.com/pts/redirect.mp3/traffic.libsyn.com/jnite/bsd-0054.mp3) **|** [OGG Audio](http://www.podtrac.com/pts/redirect.ogg/traffic.libsyn.com/jnite/bsd-0054.ogg) **|** [Torrent](http://bitlove.org/jupiterbroadcasting/bsdnowhd) **]**

http://undeadly.org/cgi?action=article&sid=20140915064856

Contributed by [jj](http://www.inet6.se) on Fri Sep 12 07:06:45 2014 (GMT)
from the all your system is belong to us dept.

Ian Kremlin wrote in with this report on the GSoC he was involved in:


> This summer I, along with my mentors Landry Breuil and Antoine Jacoutot, worked on systemd shim-like replacements for four D-Bus daemons systemd provides, namely hostnamed, localed, timedated, and logind.


> Now let's clear some things up:

The purpose of this GSoC was (is) not to port systemd to *BSD in way, shape or form. Nor is it to replace the existing init(8), boot(8) or rc(8) programs. Systemd and *BSD differ fundamentally in terms of philosophy and development practices and special care was taken to only wrap the functionality of the aforementioned daemons and not create any new systemd-like functionality.

You can find the repository [here](https://uglyman.kremlin.cc/gitweb/gitweb.cgi?p=systembsd.git;a=summary)
.
Upon completion and review, my code will most likely end up as a port to be installed along with the GNOME suite, or any other ports that depend on systemd (upstream) and need a compatibility layer to work properly on non-systemd operating systems. It goes without saying that none of my code will end up (or belongs) in the base system.

Hostnamed (formally systemd-hostnamed) is a D-Bus daemon that handles setting system hostnames (in our case, that's through the sethostname(3) call and the /etc/myname file) as well as provides system information mostly found through uname(1). Hostnamed also handles determining the system's chassis type, whether it be a server, desktop, laptop, handheld, VM, etc. and providing a proper icon from that information.

Localed and timedated are more straightforward daemons that allow setting system/xorg locales/keymaps and times/dates/timezones/NTP settings respectively.

Logind (currently unfinished) is a rather large daemon that encompasses many aspects of a user's login session. This includes everything from getting current users and any PIDs under them, as well as system suspension and shutdown/reboot preparation. We are still researching a proper way to implement this as native systemd uses PAM for authentication, something we do not want to do on OpenBSD.

Overall, it was an excellent summer. I took this project because I was fed up with what systemd was doing to my then-main computer running Arch Linux. I figured this would be a great way to make the move to OpenBSD and I couldn't be happier. I dearly hope you'll be seeing more of me in the future ;)

As a fun aside, me and some friends all turned 21 around the beginning of August (the tail end of GSoC) and decided to pool our pennies together to take a road trip together to Colorado. This led to some [interesting circumstances](https://kremlin.cc/9workethic.jpg). All I can say is that there is stable LTE service between Texas and Colorado that work at speed in excess of eighty-eight miles per hour and that one can do a lot with a macbook charger, a working alternator, a bit of cabling and entry-level electrical engineering knowledge.



Thanks for the report, and hope you didn't get too tainted with systemd.

http://undeadly.org/cgi?action=article&sid=20140916084251

Contributed by tbert on Tue Sep 16 07:02:42 2014 (GMT)
from the day of the living tedu dept.

In the [first](http://marc.info/?l=openbsd-cvs&m=141081997917153&w=2) of several commits, Matthieu Herrb (matthieu@) has removed sendmail from the release:

>
>
> CVSROOT: /cvs
> Module name: src
> Changes by: matthieu@cvs.openbsd.org 2014/09/15 16:25:57
>
> Modified files:
> gnu/usr.sbin : Makefile
>
> Log message:
> Unlink sendmail from the build. ok krw@ ajacoutot@
>

Users of OpenSMTPd can rejoice in having no work to do; others will have to install sendmail from packages.

Module name: src
Changes by: reyk@cvs.openbsd.org 2014/09/15 02:00:27

Modified files:
usr.sbin/httpd : server_http.c

Log message:
Make the HTTP version mandatory and abort if it is missing in the request.

Module name: src
Changes by: reyk@cvs.openbsd.org 2014/09/15 02:06:11

Modified files:
usr.sbin/relayd: relay_http.c

Log message:
Make the HTTP version mandatory and abort if it is missing in the request.

Module name: src
Changes by: kettenis@cvs.openbsd.org 2014/09/15 02:16:21

Modified files:
sys/arch/sparc64/dev: vdsk.c vnet.c

Log message:
Call ldc_send_unreliable() insteaf of duplicating the code to send an ldc
packet. Rename vio_sendmsg() to vnet_sendmsg().

&gt; Chris Cappuccio &lt;chris@nmedia.net&gt; writes:
&gt; &gt; Stuart Henderson [sthen@openbsd.org] wrote:
&gt; &gt;&gt;
&gt; &gt;&gt; I don't think the driver manuals can sensibly go into enough detail
&gt; &gt;&gt; in many cases, with some NICs there are differences between revisions,
&gt; &gt;&gt; some drivers cover a huge range of adapters, etc.
&gt; &gt;
&gt; &gt; It might be nice to get maximum MTUs for various chip revisions stated
&gt; &gt; in their respective man pages.
&gt;
&gt; Yes but this needs work - even more work if an audit of all drivers
&gt; "gets" done to make all manpages accurate. I'll shut up about this
&gt; since it looks like a big task in my eyes.

A too big task when you add the maintainance.

We've tried this before in other occasions, we cannot document
hardware quirks/features reasonably in our documentation for
widespread, pretty generic hardware - we just have no chance to keep
it in sync with reality.

jca/chris, if you're so much after it, I propose you start a webpage
somewhere collecting and maintaining that information. If it is still
accurate in a couple of years we can have this duscussion again :)

--
Henning Brauer, hb@bsws.de, henning@openbsd.org
BS Web Services GmbH, <a href="http://bsws.de" rel="nofollow">http://bsws.de</a>, Full-Service ISP
Secure Hosting, Mail and DNS. Virtual &amp; Dedicated Servers, Root to Fully Managed
Henning Brauer Consulting, <a href="http://henningbrauer.com/" rel="nofollow">http://henningbrauer.com/</a>

Module name: src
Changes by: dlg@cvs.openbsd.org 2014/09/15 06:00:04

Modified files:
sys/dev/ic : mpi.c
sys/dev/pci : mpi_pci.c

Log message:
mark the interrupt handler mpsafe, and drop the kernel lock in the scs_cmd
paths. take it again when going back to other parts of the kernel.

tested by and ok kettenis@

Module name: xenocara
Changes by: okan@cvs.openbsd.org 2014/09/15 07:00:49

Modified files:
app/cwm : client.c search.c xevents.c xutil.c

Log message:
use similiar style for client flags

Module name: src
Changes by: kettenis@cvs.openbsd.org 2014/09/15 08:22:07

Modified files:
sys/dev/pci : ppb.c ppbreg.h

Log message:
Add generic support for bridges that support subtractive decoding.
Fixes issues with pcmcia behind a ATI SB400 PCI bridge reported by Thierry
Deval.

ok mpi@

Module name: www
Changes by: bcallah@cvs.openbsd.org 2014/09/15 08:38:49

Modified files:
. : events.html

Log message:
Was invited to give a talk at my university next month.

Module name: src
Changes by: miod@cvs.openbsd.org 2014/09/15 13:08:22

Modified files:
libexec/rpc.rstatd: rstat_proc.c
sbin/sysctl : sysctl.c
sys/arch/hppa/hppa: autoconf.c
sys/arch/hppa64/hppa64: autoconf.c
sys/kern : kern_clock.c kern_sysctl.c tty.c
sys/net : if_sl.c ppp_tty.c
sys/sys : tty.h
usr.bin/systat : cpu.c iostat.c pigs.c vmstat.c
usr.bin/top : machine.c
usr.bin/vmstat : dkstats.c vmstat.c
usr.sbin/apmd : apmd.c
usr.sbin/iostat: iostat.c
Removed files:
sys/sys : dkstat.h

Log message:
Remove non-standard &lt;sys/dkstat.h&gt; header. It has not contained anything
related to disk stastics for almost 17 years, and the remaining
userland-visible defines duplicate those found in &lt;sys/sched.h&gt;.

Move the remaining _KERNEL defines to &lt;sys/tty.h&gt; where they belong, and
update all users to cope with this.

ok kettenis@

Module name: src
Changes by: brad@cvs.openbsd.org 2014/09/15 13:36:43

Modified files:
usr.sbin/bind : Makefile.in
Removed files:
usr.sbin/bind : CHANGES COPYRIGHT FAQ FAQ.xml README
README.OpenBSD
usr.sbin/bind/docutil: HTML_COPYRIGHT MAN_COPYRIGHT

Log message:
Garbage collecting some further bits that are not necessary
within the BIND directory and for Makefile.in removing some
files that no longer exist for the distclean target.

ok sthen@

Module name: src
Changes by: rpe@cvs.openbsd.org 2014/09/15 14:26:32

Modified files:
etc : Makefile

Log message:
Ensure proper group ID for chio.conf example.

Noted by and OK ajacoutot@
Positive feedback halex@

Module name: src
Changes by: kettenis@cvs.openbsd.org 2014/09/15 14:34:15

Modified files:
sys/arch/sparc64/dev: vdsk.c

Log message:
Fix logic error; we're out of IOs if we're not connected to the virtual disk
server *or* if we've filled all the entries on the ring.

Module name: src
Changes by: todd@cvs.openbsd.org 2014/09/15 15:17:07

Modified files:
distrib/sets/lists/comp: mi

Log message:
sync

Module name: src
Changes by: tedu@cvs.openbsd.org 2014/09/15 16:00:24

Modified files:
sys/dev : rnd.c

Log message:
update comments to reflect chacha20. from Max Fillinger

Module name: src
Changes by: matthieu@cvs.openbsd.org 2014/09/15 16:25:57

Modified files:
gnu/usr.sbin : Makefile

Log message:
Unlink sendmail from the build. ok krw@ ajacoutot@

Module name: src
Changes by: matthieu@cvs.openbsd.org 2014/09/15 16:28:58

Modified files:
etc : Makefile changelist crontab master.passwd rc
rc.conf
etc/mail : Makefile
etc/mtree : 4.4BSD.dist

Log message:
Remove sendmail tentacles. ok krw@ ajacoutot@

Module name: src
Changes by: matthieu@cvs.openbsd.org 2014/09/15 16:29:54

Modified files:
distrib/sets/lists/base: md.alpha md.amd64 md.armish md.armv7
md.aviion md.hppa md.hppa64 md.i386
md.landisk md.loongson md.luna88k
md.macppc md.octeon md.sgi md.socppc
md.sparc md.sparc64 md.vax md.zaurus mi
distrib/sets/lists/comp: mi
distrib/sets/lists/etc: mi
distrib/sets/lists/man: mi

Log message:
sync

Module name: src
Changes by: matthieu@cvs.openbsd.org 2014/09/15 16:31:08

Modified files:
usr.sbin/smtpd/smtpd: Makefile

Log message:
install sendmail.8 from smtpd now that sendmail is gone.

Module name: src
Changes by: matthieu@cvs.openbsd.org 2014/09/15 16:34:32

Removed files:
etc/mail : README access genericstable local-host-names
relay-domains trusted-users virtusertable

Log message:
Remove sendmail specific files.

Module name: src
Changes by: matthieu@cvs.openbsd.org 2014/09/15 16:35:25

Removed files:
etc/mail : mailertable

Log message:
Remove sendmail specific files.

Module name: www
Changes by: matthieu@cvs.openbsd.org 2014/09/15 16:51:00

Modified files:
faq : current.html

Log message:
Sendmail removed

Module name: src
Changes by: matthieu@cvs.openbsd.org 2014/09/15 18:05:41

Modified files:
distrib/sets/lists/base: mi

Log message:
sync

Module name: src
Changes by: matthieu@cvs.openbsd.org 2014/09/15 18:19:31

Modified files:
include : Makefile

Log message:
Missed this sendmail reference in the sendmail removal

Module name: www
Changes by: nick@cvs.openbsd.org 2014/09/15 20:28:35

Modified files:
faq : faq6.html

Log message:
+ 6.2.9 - Adding and Replacing NICs. Inspired by how easy this is on
OpenBSD and what a nightmare it is on many other OSs.

Module name: src
Changes by: dlg@cvs.openbsd.org 2014/09/15 21:26:08

Modified files:
sys/sys : pool.h
sys/kern : subr_pool.c

Log message:
deprecate PR_DEBUG and MALLOC_DEBUG in pools.

poked by kspillner@
ok miod@

Module name: src
Changes by: dlg@cvs.openbsd.org 2014/09/15 23:12:04

Modified files:
sys/dev/pci : mpii.c

Log message:
mark the mpii interrupt handler as mpsafe, and drop the kernel lock
in the scsi_cmd path and iopool backend.

modelled on mfi and mpi.

Module name: src
Changes by: matthieu@cvs.openbsd.org 2014/09/15 23:26:06

Modified files:
distrib/sets/lists/man: mi

Log message:
sync

Module name: src
Changes by: espie@cvs.openbsd.org 2014/09/16 02:50:26

Modified files:
usr.sbin/pkg_add/OpenBSD: PkgCreate.pm

Log message:
store explicit timestamps in generated plists.
this prevents updates from fucking up mtime of new file, thus the
"python exception" no longer prevents python files from being reordered.

Note that this requires newish scaffolding in pkg_add proper. That
scaffolding was committed prior to 5.6, in preparation for this change.

Module name: src
Changes by: espie@cvs.openbsd.org 2014/09/16 02:51:38

Modified files:
usr.sbin/pkg_add/OpenBSD: ArcCheck.pm

Log message:
if a @ts annotation is detected, wipe tarball timestamp. Archives will
look as if all files were born in 1970. The useful side-effect is that
meta-data for content-identical files WILL be identical as well.

Module name: src
Changes by: espie@cvs.openbsd.org 2014/09/16 04:01:51

Modified files:
usr.sbin/pkg_add/OpenBSD: PkgCreate.pm

Log message:
fix display of comments to use "say" properly.
Prepare scaffolding to be able to chunk archives

&gt; Log message:
&gt; Update py-paramiko to 1.14.1

how about the failing tests?
is it a well known issue?

ERROR: test_1_client (tests.test_client.SSHClientTest)
ERROR: test_4_auto_add_policy (tests.test_client.SSHClientTest)
ERROR: test_6_cleanup (tests.test_client.SSHClientTest)

-f
--
smile, its the second best thing you can do with your lips.

Module name: ports
Changes by: landry@cvs.openbsd.org 2014/09/15 09:11:35

Modified files:
math/pari : Makefile distinfo
math/pari/patches: patch-Configure
math/pari/pkg : PLIST
Added files:
math/pari/patches: patch-src_test_dotest

Log message:
Update to pari 2.1.7, from Sebastien Marie (thanks!)

Fixes readline support, correct tests target, and dont pickup emacs if
installed. All tests pass and also Math::Pari tests.

We cant update to 2.3 branch for obscure breakage with other things
depending on it.

Module name: ports
Changes by: naddy@cvs.openbsd.org 2014/09/15 09:18:16

Modified files:
mail/courier-authlib: Makefile

Log message:
missing bump after switch to MariaDB

Module name: ports
Changes by: robert@cvs.openbsd.org 2014/09/15 09:40:13

Modified files:
mail/zarafa/zarafa: Makefile distinfo

Log message:
fix distfile checksum

Module name: ports
Changes by: robert@cvs.openbsd.org 2014/09/15 09:55:22

Modified files:
lang/php/5.5 : Tag: OPENBSD_5_6 Makefile distinfo

Log message:
security update to 5.5.16; ok jasper@

Module name: ports
Changes by: robert@cvs.openbsd.org 2014/09/15 09:55:45

Modified files:
lang/php/5.4 : Tag: OPENBSD_5_6 Makefile distinfo

Log message:
security update to 5.4.32; ok jasper@

Module name: ports
Changes by: robert@cvs.openbsd.org 2014/09/15 10:00:25

Modified files:
lang/php/5.4 : Tag: OPENBSD_5_5 Makefile distinfo

Log message:
security update to 5.4.30; ok jasper@

On (2014-09-15 10:00), Robert Nagy wrote:
&gt; CVSROOT: /cvs
&gt; Module name: ports
&gt; Changes by: robert@cvs.openbsd.org 2014/09/15 10:00:25
&gt;
&gt; Modified files:
&gt; lang/php/5.4 : Tag: OPENBSD_5_5 Makefile distinfo
&gt;
&gt; Log message:
&gt; security update to 5.4.30; ok jasper@

Module name: ports
Changes by: brad@cvs.openbsd.org 2014/09/15 11:10:45

Modified files:
databases/mydumper: Makefile
databases/mydumper/patches: patch-CMakeLists_txt
patch-mydumper_c
Added files:
databases/mydumper/patches: patch-config_h_in

Log message:
mydumper is tocuhing internal MySQL API it should not be. upstream has disabled
the binlog support until something can be done to fix it properly.

"The real problem here is that no application should ever include sql_common.h
or try to execute, the internal to libmysql functions, simple_command() or
advanced_command() directly.

The primary reason for this is that these functions are not safe for internal
API or structure changes and may cause applications crashes between even minor
versions of libmysql.a"

<a href="https://bugs.launchpad.net/mydumper/+bug/1316001" rel="nofollow">https://bugs.launchpad.net/mydumper/+bug/1316001</a>

ok giovanni@

Module name: ports
Changes by: ajacoutot@cvs.openbsd.org 2014/09/15 11:15:13

Modified files:
devel/libsigc++-2: Makefile distinfo
devel/libsigc++-2/pkg: PLIST

Log message:
Update to libsigc++-2.4.0.

Module name: ports
Changes by: brad@cvs.openbsd.org 2014/09/15 13:24:16

Modified files:
devel/llvm : Makefile
devel/llvm/patches: patch-lib_Target_X86_X86ISelLowering_cpp

Log message:
r217410
Set trunc store action to Expand for all X86 targets.

When compiling without SSE2, isTruncStoreLegal(F64, F32) would return Legal, whereas
with SSE2 it would return Expand. And since the Target doesn't seem to actually
handle a truncstore for double -&gt; float, it would just output a store of a full
double in the space for a float hence overwriting other bits on the stack.