<?xml version="1.0" encoding="UTF-8"?>
<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns="http://purl.org/rss/1.0/" xmlns:taxo="http://purl.org/rss/1.0/modules/taxonomy/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:syn="http://purl.org/rss/1.0/modules/syndication/" xmlns:admin="http://webns.net/mvcb/">
  <channel rdf:about="http://permalink.gmane.org/gmane.os.openbsd.misc">
    <title>gmane.os.openbsd.misc</title>
    <link>http://permalink.gmane.org/gmane.os.openbsd.misc</link>
    <description/>
    <syn:updatePeriod>hourly</syn:updatePeriod>
    <syn:updateFrequency>1</syn:updateFrequency>
    <syn:updateBase>1901-01-01T00:00+00:00</syn:updateBase>
    <items>
      <rdf:Seq>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.os.openbsd.misc/204683"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.os.openbsd.misc/204682"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.os.openbsd.misc/204681"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.os.openbsd.misc/204680"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.os.openbsd.misc/204679"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.os.openbsd.misc/204678"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.os.openbsd.misc/204677"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.os.openbsd.misc/204676"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.os.openbsd.misc/204675"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.os.openbsd.misc/204674"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.os.openbsd.misc/204673"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.os.openbsd.misc/204672"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.os.openbsd.misc/204671"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.os.openbsd.misc/204670"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.os.openbsd.misc/204669"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.os.openbsd.misc/204668"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.os.openbsd.misc/204667"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.os.openbsd.misc/204666"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.os.openbsd.misc/204665"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.os.openbsd.misc/204664"/>
      </rdf:Seq>
    </items>
    <image rdf:resource="http://gmane.org/img/gmane-25t.png"/>
    <textinput rdf:resource=""/>
  </channel>
  <image rdf:about="http://gmane.org/img/gmane-25t.png">
    <title>Gmane</title>
    <url>http://gmane.org/img/gmane-25t.png</url>
    <link>http://gmane.org</link>
  </image>
  <item rdf:about="http://permalink.gmane.org/gmane.os.openbsd.misc/204683">
    <title>Re: Problem with a startup script</title>
    <link>http://permalink.gmane.org/gmane.os.openbsd.misc/204683</link>
    <description>&lt;pre&gt;
You mean check instead of status, right?


Running the rc script in debug mode may give you some clue (-d).
 

&lt;/pre&gt;</description>
    <dc:creator>Antoine Jacoutot</dc:creator>
    <dc:date>2013-05-22T06:50:23</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.os.openbsd.misc/204682">
    <title>Problem with a startup script</title>
    <link>http://permalink.gmane.org/gmane.os.openbsd.misc/204682</link>
    <description>&lt;pre&gt;Hi all,

 I have a problem with some tcl rc.d startup scripts. Start and status
works ok but stop and restart, doesn't.

 Script:

#!/bin/sh -x
#
# $OpenBSD: suricata_proxyin_agent,v 1.0

daemon="/usr/local/bin/suricata_proxyin_agent.tcl"
daemon_flags="-c /data/config/etc/sguil/suricata_proxyin_agent.conf -D"

. /etc/rc.d/rc.subr

pexp="/usr/local/bin/tclsh8.5 $daemon"

rc_cmd $1

I have tried several variants like to insert rc_stop specific option
or changing pexp to "/usr/local/bin/tclsh8.5 $daemon $daemon_args"
without luck.

Debugging script, acts as like the other system startup scripts:

.....

+ echo NO
+ : NO
+ [ XNO = XYES ]
+ echo NO
+ : NO
+ domainname
+ [ X != X -a -d /var/yp/binding ]
+ echo NO
+ : NO
+ : NO
+ [ -n /usr/local/bin/suricata_proxyin_agent.tcl ]
+ unset _RC_DEBUG _RC_FORCE
+ getopts df c
+ shift 0
+ basename ./suricata_proxyin_agent
+ _name=suricata_proxyin_agent
+ _RC_RUNDIR=/var/run/rc.d
+ _RC_RUNFILE=/var/run/rc.d/suricata_proxyin_agent
+ eval _rcflags=${suricata_proxyin_agent_fl&lt;/pre&gt;</description>
    <dc:creator>C. L. Martinez</dc:creator>
    <dc:date>2013-05-22T06:18:04</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.os.openbsd.misc/204681">
    <title>Re: OT: trying to install vortex-idx in OpenBSD 5.3</title>
    <link>http://permalink.gmane.org/gmane.os.openbsd.misc/204681</link>
    <description>&lt;pre&gt;
Uhmm I have tried, but same errors:

root&amp;lt; at &amp;gt;plzfnsm01:/tmp/1/vortex-dev-master# gcc -c vortex.c
-I/usr/local/include -I/data/soft/libpcap/include
vortex.c:44:24: error: sys/cpuset.h: No such file or directory
vortex.c:45: error: expected '=', ',', ';', 'asm' or '__attribute__'
before 'cpu_set_t'
vortex.c:47:1: warning: "SIZE_MAX" redefined
In file included from /usr/include/sys/limits.h:34,
                 from /usr/include/sys/param.h:92,
                 from vortex.c:43:
/usr/include/machine/limits.h:41:1: warning: this is the location of
the previous definition
vortex.c: In function 'errors_thread':
vortex.c:676: error: 'cpu_set_t' undeclared (first use in this function)
vortex.c:676: error: (Each undeclared identifier is reported only once
vortex.c:676: error: for each function it appears in.)
vortex.c:676: error: expected ';' before 'csmask'
vortex.c:677: error: 'csmask' undeclared (first use in this function)
vortex.c: In function 'stats_thread':
vortex.c:756: error: 'cpu_set_t' undeclared (first use &lt;/pre&gt;</description>
    <dc:creator>C. L. Martinez</dc:creator>
    <dc:date>2013-05-22T06:08:44</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.os.openbsd.misc/204680">
    <title>Re: Policy Based Routing/pfctl help</title>
    <link>http://permalink.gmane.org/gmane.os.openbsd.misc/204680</link>
    <description>&lt;pre&gt;
Thanks!  See, I'm confused by pfctl in more ways than one!  Haha.

This is a single set-it-up-and-forget, no script modifying it on the fly.  I expect to run this once per reboot or add it to /etc/pf.conf and be done.  

There will be packets arriving at this interface also, however, they aren't "returned" as such, just counted (except ping testing), so I should be good there.  So it sounds like what I need is, for example:

pass in from 10.1.1.0/24 route-to 10.1.1.1&amp;lt; at &amp;gt;vlan1

vlan1 being the correct outgoing interface which is configured with an address on the 10.1.1.0/24 network.  That's much simpler than I was imagining.  I have four of these, so my pf.conf file could look like:

pass in from 10.1.1.0/24 route-to 10.1.1.1&amp;lt; at &amp;gt;vlan1
pass in from 10.1.2.0/24 route-to 10.1.2.1&amp;lt; at &amp;gt;vlan2
pass in from 10.1.3.0/24 route-to 10.1.3.1&amp;lt; at &amp;gt;vlan3
pass in from 10.1.4.0/24 route-to 10.1.4.1&amp;lt; at &amp;gt;vlan4

If I needed inbound traffic returned (ping), I would add:

pass in on vlan1 reply-to 10.1.1.1&amp;lt; at &amp;gt;vlan1
pass in on vlan2 reply-to 10.1.2.1&amp;lt; at &amp;gt;v&lt;/pre&gt;</description>
    <dc:creator>Aaron Dewell</dc:creator>
    <dc:date>2013-05-21T23:09:14</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.os.openbsd.misc/204679">
    <title>Re: OT: trying to install vortex-idx in OpenBSD 5.3</title>
    <link>http://permalink.gmane.org/gmane.os.openbsd.misc/204679</link>
    <description>&lt;pre&gt;
This is trying to use non-portable Linux code (from the errors it
looks like it maybe for processor affinity).

The modified version you mention has some if defined(__FreeBSD__)
hacks, you may get it to compile if you change those lines to 
if defined(__FreeBSD__) || defined(__OpenBSD__).


&lt;/pre&gt;</description>
    <dc:creator>Stuart Henderson</dc:creator>
    <dc:date>2013-05-21T22:38:01</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.os.openbsd.misc/204678">
    <title>Re: Policy Based Routing/pfctl help</title>
    <link>http://permalink.gmane.org/gmane.os.openbsd.misc/204678</link>
    <description>&lt;pre&gt;
For states created by outgoing traffic, you're looking for "route-to".
You may also need "reply-to" if you have incoming traffic to that address
where replies should also be forced via that path.

e.g.

pass in from &amp;lt;network-X&amp;gt; route-to 10.1.1.1&amp;lt; at &amp;gt;vlan9

OpenBSD doesn't have the "pfctl -m" syntax you mention, but looking at
Apple's manpage I don't think it does what you expect. It looks like it
is meant for merging "set" options, but it doesn't say what effect
it has on the ruleset; for all I can tell it might well replace the
whole ruleset with the single rule you're piping to it. Probably
better to write the ruleset in a pf.conf file and load that.
Unlike ipfw, PF normally treats the whole ruleset as a unit and
switches to a new ruleset atomically, if you want something other
than this (e.g. on-the-fly replacing of certain rules under script
control) you would normally use an "anchor" so that other rules can
be left alone.


&lt;/pre&gt;</description>
    <dc:creator>Stuart Henderson</dc:creator>
    <dc:date>2013-05-21T22:31:46</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.os.openbsd.misc/204677">
    <title>Re: ospfd loopback advertisment failure (adjacency fail?)</title>
    <link>http://permalink.gmane.org/gmane.os.openbsd.misc/204677</link>
    <description>&lt;pre&gt;
I found some issues with the diff but I hope to be able to sit down
somewhen and fix those problems I identified. The cisco I tested against
seems to behave not like a rfc point-to-point interface (some messages I
expected to be sent to the multicast address where unicast, etc.)

I would be interested in some tcpdumps of extreme doing ospf to see if
they behave the same.
&lt;/pre&gt;</description>
    <dc:creator>Claudio Jeker</dc:creator>
    <dc:date>2013-05-21T21:23:55</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.os.openbsd.misc/204676">
    <title>Re: ospfd loopback advertisment failure (adjacency fail?)</title>
    <link>http://permalink.gmane.org/gmane.os.openbsd.misc/204676</link>
    <description>&lt;pre&gt;
Hi,

sorry for delay, we are in the middle of the network migration from
cisco to extreme and i thought when everything calms down to test it
with cisco and extreme equipment. I'm planning to test it next week.






&lt;/pre&gt;</description>
    <dc:creator>Hrvoje Popovski</dc:creator>
    <dc:date>2013-05-21T21:00:03</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.os.openbsd.misc/204675">
    <title>Re: a sftp user can enter into a directory which he does not have rights</title>
    <link>http://permalink.gmane.org/gmane.os.openbsd.misc/204675</link>
    <description>&lt;pre&gt;
Ah... this was forgotten for mpd, anyway this is not the case, see
with 700 mode. Is sftp just pretending to enter that directory?

sftp&amp;gt; cd /
sftp&amp;gt; ls -l
drwxr-xr-x    2 0        0             512 May 21 18:43 dev
drwx------   12 1000     1000          512 May 21 18:32 jirib
drwxr-xr-x   10 1000     1000          512 May 21 18:32 pub
sftp&amp;gt; cd jirib
sftp&amp;gt; ls -al
remote readdir("/jirib"): Permission denied

vs

$ id
uid=1000(jirib) gid=1000(jirib) groups=1000(jirib), 0(wheel), 5(operator), 9(wsrc)
$ cd /home/toruser
ksh: cd: /home/toruser - Permission denied
$ ls -ld /home/toruser
drwx------  18 toruser  toruser  1024 May 21 20:00 /home/toruser/

j.


&lt;/pre&gt;</description>
    <dc:creator>Jiri B</dc:creator>
    <dc:date>2013-05-21T20:23:00</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.os.openbsd.misc/204674">
    <title>Re: a sftp user can enter into a directory which he does not have rights</title>
    <link>http://permalink.gmane.org/gmane.os.openbsd.misc/204674</link>
    <description>&lt;pre&gt;
You should (re)read your unix manuals. Execution permission on a directory
means it can be traversed. What you observe is the correct behaviour for
any system with POSIX file permissions.

&lt;/pre&gt;</description>
    <dc:creator>Eugene Yunak</dc:creator>
    <dc:date>2013-05-21T20:09:42</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.os.openbsd.misc/204673">
    <title>Re: a sftp user can enter into a directory which he does not have rights</title>
    <link>http://permalink.gmane.org/gmane.os.openbsd.misc/204673</link>
    <description>&lt;pre&gt;
Reeeeeally.

$ ls -l
total 8
drwx-----x  2 2000      2000   512 May 21 12:57 foo
$ id
uid=1000(guenther) gid=1000(guenther) groups=1000(guenther), 0(wheel)
$ cd foo
$ ls -l
ls: .: Permission denied
$


Executable by processes that have neither uid 1000 or gid 1000.
What's the problem?


Philip Guenther


&lt;/pre&gt;</description>
    <dc:creator>Philip Guenther</dc:creator>
    <dc:date>2013-05-21T19:59:55</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.os.openbsd.misc/204672">
    <title>a sftp user can enter into a directory which he does not have rights</title>
    <link>http://permalink.gmane.org/gmane.os.openbsd.misc/204672</link>
    <description>&lt;pre&gt;I'm very surprised to see something like this. Comparing with
normal unix filesystem, 'sftpuser' would not even enter such
directory. Is this OK?

* sftpuser has only group 'sftpuser'

$ sftp sftpuser&amp;lt; at &amp;gt;localhost 
Connected to localhost.
sftp&amp;gt; cd /
sftp&amp;gt; ls -l
drwxr-xr-x    2 0        0             512 May 21 18:43 dev
drwx-----x   12 1000     1000          512 May 21 18:32 jirib
drwxr-xr-x   10 1000     1000          512 May 21 18:32 pub
sftp&amp;gt; cd jirib
sftp&amp;gt; pwd
Remote working directory: /jirib
sftp&amp;gt; ls -al
remote readdir("/jirib"): Permission denied

j.


&lt;/pre&gt;</description>
    <dc:creator>Jiri B</dc:creator>
    <dc:date>2013-05-21T19:52:49</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.os.openbsd.misc/204671">
    <title>Re: HD4000 problems</title>
    <link>http://permalink.gmane.org/gmane.os.openbsd.misc/204671</link>
    <description>&lt;pre&gt;Well sending an archive to misc is just silly... http://filebin.ca/htF9pCQ6fHD/yoga.tgz

Jean Lucas &amp;lt;horsefish&amp;lt; at &amp;gt;lavabit.com&amp;gt; wrote:



&lt;/pre&gt;</description>
    <dc:creator>Jean Lucas</dc:creator>
    <dc:date>2013-05-21T18:08:26</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.os.openbsd.misc/204670">
    <title>Policy Based Routing/pfctl help</title>
    <link>http://permalink.gmane.org/gmane.os.openbsd.misc/204670</link>
    <description>&lt;pre&gt;Hey all,

I know this is slightly off-topic on this list, I'm hoping the OpenBSD answer will be "close enough" to the MacOS X (10.8) answer that I'll get what I need done.  I have gotten zero replies from the Apple communities, so I'm asking here.  That said, here's what I'm trying to accomplish.

This server has 5 VLAN tagged interfaces (already set up and reachable).
First one holds the default route (used for administration).
Ostinato (traffic generator) is installed.
The other 4 VLAN interfaces are to be used for traffic generation/receiving.

What I want is for traffic sourced (via Ostinato) from a particular IP address to be sent via it's own VLAN interface to it's own router.  I have accomplished this on Linux (the far end of this test) using:

ip route add default via &amp;lt;gateway-X&amp;gt; dev ethX table X
ip rule add from &amp;lt;network-X&amp;gt; table X priority X

Research online suggests that this used to work before ipfw was deprecated:

ipfw add X fwd &amp;lt;gateway-X&amp;gt; ip from &amp;lt;IP-address-X&amp;gt; to any

(I did try this, and no&lt;/pre&gt;</description>
    <dc:creator>Aaron Dewell</dc:creator>
    <dc:date>2013-05-21T17:58:14</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.os.openbsd.misc/204669">
    <title>Re: how long should CD orders take?</title>
    <link>http://permalink.gmane.org/gmane.os.openbsd.misc/204669</link>
    <description>&lt;pre&gt;The OpenBSD project is severely under staffed in terms of shipping 
merchandise. You're not the only one waiting on purchased items. I 
humbly suggest being patient as the group is trying to address large 
quantities of orders and not enough help. The is the case at least with 
the Calgary, Canada location.

I'm waiting on an order to be filled also, from almost a month ago. So 
we have to be a little more patient than normal.


On 05/21/2013 01:34 PM, Peter J. Philipp wrote:




&lt;/pre&gt;</description>
    <dc:creator>Salim Shaw</dc:creator>
    <dc:date>2013-05-21T17:55:00</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.os.openbsd.misc/204668">
    <title>Re: how long should CD orders take?</title>
    <link>http://permalink.gmane.org/gmane.os.openbsd.misc/204668</link>
    <description>&lt;pre&gt;Try openbsdeurope.com next time. I already got mine. Last week.

//mxb

On 21 maj 2013, at 19:26, Peter J. Philipp &amp;lt;pjp&amp;lt; at &amp;gt;centroid.eu&amp;gt; wrote:



&lt;/pre&gt;</description>
    <dc:creator>mxb</dc:creator>
    <dc:date>2013-05-21T17:52:01</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.os.openbsd.misc/204667">
    <title>HD4000 problems</title>
    <link>http://permalink.gmane.org/gmane.os.openbsd.misc/204667</link>
    <description>&lt;pre&gt;I've an (Intel) HD4000 and from the point that inteldrm was added to current, X freezes on launch, and have to SSH in to reboot nicely. Read a post with a similar problem; reducing video memory to &amp;lt;128 MB was the trick to have X start on current.

I'm running yesterdays (20th May) -current, on a Lenovo Yoga 13, and there is no option for video memory in the BIOS. For 5.3 release however, X starts when I disable DPTF ( Intel dynamic platform &amp;amp; thermal framework). 5.2 release worked fine with this enabled.

Question: is there a kernel option to reduce video memory used by the OS to see if the workaround is valid?

Back to the point, X -configure returns a Segmentation fault 0x28, and when just running startx, Xorg.0.log reveals Output LVDS1 has no monitor section. (Note: 5.2 &amp;amp; 5.3 release returned same segfault, though X worked flawlessly with startx)

A few snapshots back, X would start after booting single-user and rebooting, though failure-success rate was around 4:1. When it would start, running xbacklight&lt;/pre&gt;</description>
    <dc:creator>Jean Lucas</dc:creator>
    <dc:date>2013-05-21T17:47:33</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.os.openbsd.misc/204666">
    <title>Re: how long should CD orders take?</title>
    <link>http://permalink.gmane.org/gmane.os.openbsd.misc/204666</link>
    <description>&lt;pre&gt;
I just mailed them before this.  Since it's 7:30PM I think they won't 
reply until tomorrow morning.

-peter


&lt;/pre&gt;</description>
    <dc:creator>Peter J. Philipp</dc:creator>
    <dc:date>2013-05-21T17:34:28</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.os.openbsd.misc/204665">
    <title>Re: how long should CD orders take?</title>
    <link>http://permalink.gmane.org/gmane.os.openbsd.misc/204665</link>
    <description>&lt;pre&gt;
What does the bookstore say the problem is?


&lt;/pre&gt;</description>
    <dc:creator>noah pugsley</dc:creator>
    <dc:date>2013-05-21T17:31:55</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.os.openbsd.misc/204664">
    <title>how long should CD orders take?</title>
    <link>http://permalink.gmane.org/gmane.os.openbsd.misc/204664</link>
    <description>&lt;pre&gt;I ordered my CD through a german bookstore that is listed at 
www.openbsd.org/orders.html.  Only it's now the 21st of May and my 
computers have all been upgraded via FTP around the 1st of May.  And I 
still have no CD (and no stickers).

Last year they were slow as well, which leads me to believe that the 
store is sloppy in its orders.  Can someone confirm that the CD's have 
all been sent out from Calgary?  It's really a shame that I must use 
resources of OpenBSD when not needed, my order went in around the end of 
March 2013 and there was lots of time to deliver this as a pre-order.

-peter


&lt;/pre&gt;</description>
    <dc:creator>Peter J. Philipp</dc:creator>
    <dc:date>2013-05-21T17:26:11</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.os.openbsd.misc/204663">
    <title>Re: smtpd setup</title>
    <link>http://permalink.gmane.org/gmane.os.openbsd.misc/204663</link>
    <description>&lt;pre&gt;Thanks for chiming in Gilles.

It's ironic that because of trying to minimize noise to the list, I create
more. The rest of the conf is at the beginning of the thread, but I'll be
sure to include entire outputs in the future; sorry.

Anyway, it wasn't my conf. Your comment about my MX question got me
searching, and I found that my secrets file wanted google's
application-specific password (your choice of wording is what triggered the
thought).

Thanks for the help.

-Scott

On May 21, 2013 12:30 AM, "Gilles Chehade" &amp;lt;gilles&amp;lt; at &amp;gt;poolp.org&amp;gt; wrote:
could be
I've
manpage


&lt;/pre&gt;</description>
    <dc:creator>Scott</dc:creator>
    <dc:date>2013-05-21T16:20:46</dc:date>
  </item>
  <textinput rdf:about="http://search.gmane.org/?group=$group=gmane.os.openbsd.misc">
    <title>Search Engine</title>
    <description>Search the mailing list at Gmane</description>
    <name>query</name>
    <link>http://search.gmane.org/?group=$group=gmane.os.openbsd.misc</link>
  </textinput>
</rdf:RDF>
