Re: Hellos from the Lands of ..Arkanaias

[Ian Sutton]

please do not use this list to test markov bots, it is for
miscellaneous openbsd discussion, thanks

Re: OpenBSD SPARC T4-1 softraid boot issues

[Jordan]

Thanks Edgar for catching that typo, step 3 should indeed read:

3) I zeroed the first 10MB of the RAID volume with # dd if=/dev/zero
of=/dev/rsd2c bs=1m count=1

That is the command I used on the T4, I accidental wrote urandom rather than 
zero when I was typing the email.


On 12/26/17 13:52, Edgar Pettijohn wrote:

On Tue, Dec 26, 2017 at 12:56:53PM -0800, Jordan wrote:

Hi everyone, long time lurker, first time poster. I've been around since the
5.* days, so I would consider myself fairly seasoned in the ways of OpenBSD.
I've obviously done the RTFM dance, done it once, done it twice, been doing
it all week long now-- this problem really has me banging my head against a
wall.

I'm cross posting this to both the misc and sparc64 mailing lists in the
hopes that I can entice both the softraid and sparc connoisseurs.

I've recently gotten my hands on a couple shiny new SPARC T4-1 and T3-1
servers and I was looking to install OpenBSD with a softraid mirror on them
for production use. The problem is, is that I end up with this upon
following the install instructions and rebooting:

Boot device: /pci@400/pci@1/pci@0/pci@4/scsi@0/disk@p0 File and
args: sr0a:/bsd OpenBSD IEEE 1275 Bootblock 1.4

OpenBSD BOOT 1.9 Error: /iscsi-hba: no
iscsi-network-bootpath property Unknown device: sr0 Cannot
boot from softraid: Unknown error: code 19 Program terminated

The only other information I can find online involving a softraid error code
19 was the following: 
http://openbsd-archive.7691.n7.nabble.com/5-8-sparc64-boot-from-softraid-4-fails-td284700.html


Considering he was running 5.8 and I am on 6.2 and the fix for his issue has
already been committed, I???m left scratching my head as to what the problem
here could be.

The install procedure I followed on the T4 was:

1) Boot install kernel and drop to shell and provision RAID partitions on
both disks using the letter ???a??? via disklabel(8)

2) Assemble RAID volume with # bioctl -c 1 -l /dev/sd0a,/dev/sd1a softraid0

3) I zeroed the first 10MB of the RAID volume with # dd if=/dev/urandom
of=/dev/rsd2c bs=1m

shouldn't that have been
# dd if=/dev/zero of=/dev/rsd2c bs=1m count=1

4) I finished off the install as usual by typing ???install??? into command
line and proceeded normally

5) I then rebooted and set the boot parameters at the ok prompt as per
boot_sparc(8)

Aside from the sparc64 specific stuff, these same steps (plus x86 specific
fdisk stuff) get me a working, bootable softraid mirror on my i386/amd64
test boxes.


It appears the issue I linked to in the OpenBSD archive, was that the
bootloader couldn't probe beyond 4 levels deep in the device tree. According
to Stefan Sperling he committed a patch to allow it to probe to (an
arbitrarily set) 10 levels deep in the device tree. According to my devalias
output, my disk0 appears to be 6 levels deep in the tree if I am reading it
correctly.

I did manage to get the T4 booting from softraid using this guide:
http://brycv.com/blog/2012/openbsd-sparc64-and-root-on-softraid/

That guide however does seem to contravene the guidelines set forth in
softraid(4): ???On sparc64, bootable chunks must be RAID partitions using
the letter ???a??? .???

With the above guide from brycv.com we end up with 3 separate partitions on
our disks. This doesn't seem right as on amd64/i386 you would only have a
single raid partition per disk, not a separate root and swap partition in
addition to the RAID partitions. It would also seem that a rebuild would
involve significantly more manual intervention to maintain drive bootability
in the event of one of the drives in the mirror going down ie: One wouldn't
just be able to run bioctl -R /dev/rsd1a sd2 and have the array be golden
again, they would instead also need to mount and copy over the contents of
the other non RAID partitions on the disk.

In short, on sparc64, is softraid boot like that of i386/amd64 where
everything including root is stored within the RAID volume, or does sparc64
require me to have a small partition at the beginning of my physical disks
containing the kernel and ofwboot? One fellow on reddit said he had a T1000
booting softraid crypto no problem so I am wondering if this is a T4
specific issue.

Sorry for the wall of text, I really appreciate any help you guys can offer.
Let me know if you need any other information and I???ll be happy to provide
it. Does anyone else here have any experience with sparc64 softraid booting
or with OpenBSD on a T3 or T4? Please let me know, and Merry Christmas to
all!

Obligatory dmesg:

T4 -1 Output
# dmesg
console is /virtual-devices@100/console@1
Copyright (c) 1982, 1986, 1989, 1991, 1993
 The Regents of the University of California.  All rights reserved.
Copyright (c) 1995-2017 OpenBSD. All rights reserved.
https://www.OpenBSD.org
OpenBSD 6.2 (RAMDISK) #282: Tue Oct  3 23:21:19 MDT 2017
dera...@sparc64.openbsd.org:/usr/src/sys/arch/sparc64/compile/RAMDISK
real mem = 

Re: OpenBSD SPARC T4-1 softraid boot issues

[Edgar Pettijohn]

On Tue, Dec 26, 2017 at 12:56:53PM -0800, Jordan wrote:
> Hi everyone, long time lurker, first time poster. I've been around since the
> 5.* days, so I would consider myself fairly seasoned in the ways of OpenBSD.
> I've obviously done the RTFM dance, done it once, done it twice, been doing
> it all week long now-- this problem really has me banging my head against a
> wall.
> 
> I'm cross posting this to both the misc and sparc64 mailing lists in the
> hopes that I can entice both the softraid and sparc connoisseurs.
> 
> I've recently gotten my hands on a couple shiny new SPARC T4-1 and T3-1
> servers and I was looking to install OpenBSD with a softraid mirror on them
> for production use. The problem is, is that I end up with this upon
> following the install instructions and rebooting:
> 
>Boot device: /pci@400/pci@1/pci@0/pci@4/scsi@0/disk@p0 File and
>args: sr0a:/bsd OpenBSD IEEE 1275 Bootblock 1.4
> 
>OpenBSD BOOT 1.9 Error: /iscsi-hba: no
>iscsi-network-bootpath property Unknown device: sr0 Cannot
>boot from softraid: Unknown error: code 19 Program terminated
> 
> The only other information I can find online involving a softraid error code
> 19 was the following: 
> http://openbsd-archive.7691.n7.nabble.com/5-8-sparc64-boot-from-softraid-4-fails-td284700.html
> 
> 
> Considering he was running 5.8 and I am on 6.2 and the fix for his issue has
> already been committed, I???m left scratching my head as to what the problem
> here could be.
> 
> The install procedure I followed on the T4 was:
> 
> 1) Boot install kernel and drop to shell and provision RAID partitions on
> both disks using the letter ???a??? via disklabel(8)
> 
> 2) Assemble RAID volume with # bioctl -c 1 -l /dev/sd0a,/dev/sd1a softraid0
> 
> 3) I zeroed the first 10MB of the RAID volume with # dd if=/dev/urandom
> of=/dev/rsd2c bs=1m

shouldn't that have been
# dd if=/dev/zero of=/dev/rsd2c bs=1m count=1
> 
> 4) I finished off the install as usual by typing ???install??? into command
> line and proceeded normally
> 
> 5) I then rebooted and set the boot parameters at the ok prompt as per
> boot_sparc(8)
> 
> Aside from the sparc64 specific stuff, these same steps (plus x86 specific
> fdisk stuff) get me a working, bootable softraid mirror on my i386/amd64
> test boxes.
> 
> 
> It appears the issue I linked to in the OpenBSD archive, was that the
> bootloader couldn't probe beyond 4 levels deep in the device tree. According
> to Stefan Sperling he committed a patch to allow it to probe to (an
> arbitrarily set) 10 levels deep in the device tree. According to my devalias
> output, my disk0 appears to be 6 levels deep in the tree if I am reading it
> correctly.
> 
> I did manage to get the T4 booting from softraid using this guide:
> http://brycv.com/blog/2012/openbsd-sparc64-and-root-on-softraid/
> 
> That guide however does seem to contravene the guidelines set forth in
> softraid(4): ???On sparc64, bootable chunks must be RAID partitions using
> the letter ???a??? .???
> 
> With the above guide from brycv.com we end up with 3 separate partitions on
> our disks. This doesn't seem right as on amd64/i386 you would only have a
> single raid partition per disk, not a separate root and swap partition in
> addition to the RAID partitions. It would also seem that a rebuild would
> involve significantly more manual intervention to maintain drive bootability
> in the event of one of the drives in the mirror going down ie: One wouldn't
> just be able to run bioctl -R /dev/rsd1a sd2 and have the array be golden
> again, they would instead also need to mount and copy over the contents of
> the other non RAID partitions on the disk.
> 
> In short, on sparc64, is softraid boot like that of i386/amd64 where
> everything including root is stored within the RAID volume, or does sparc64
> require me to have a small partition at the beginning of my physical disks
> containing the kernel and ofwboot? One fellow on reddit said he had a T1000
> booting softraid crypto no problem so I am wondering if this is a T4
> specific issue.
> 
> Sorry for the wall of text, I really appreciate any help you guys can offer.
> Let me know if you need any other information and I???ll be happy to provide
> it. Does anyone else here have any experience with sparc64 softraid booting
> or with OpenBSD on a T3 or T4? Please let me know, and Merry Christmas to
> all!
> 
> Obligatory dmesg:
> 
> T4 -1 Output
> # dmesg
> console is /virtual-devices@100/console@1
> Copyright (c) 1982, 1986, 1989, 1991, 1993
> The Regents of the University of California.  All rights reserved.
> Copyright (c) 1995-2017 OpenBSD. All rights reserved.
> https://www.OpenBSD.org
> OpenBSD 6.2 (RAMDISK) #282: Tue Oct  3 23:21:19 MDT 2017
> dera...@sparc64.openbsd.org:/usr/src/sys/arch/sparc64/compile/RAMDISK
> real mem = 136902082560 (130560MB)
> avail mem = 13451208 (128280MB)
> mainbus0 at root: SPARC T4-1
> cpu0 at mainbus0: SPARC-T4 (rev 0.0) @ 

OpenBSD SPARC T4-1 softraid boot issues

[Jordan]

Hi everyone, long time lurker, first time poster. I've been around since 
the 5.* days, so I would consider myself fairly seasoned in the ways of 
OpenBSD. I've obviously done the RTFM dance, done it once, done it 
twice, been doing it all week long now-- this problem really has me 
banging my head against a wall.


I'm cross posting this to both the misc and sparc64 mailing lists in the 
hopes that I can entice both the softraid and sparc connoisseurs.


I've recently gotten my hands on a couple shiny new SPARC T4-1 and T3-1 
servers and I was looking to install OpenBSD with a softraid mirror on 
them for production use. The problem is, is that I end up with this upon 
following the install instructions and rebooting:


   Boot device: /pci@400/pci@1/pci@0/pci@4/scsi@0/disk@p0 File and
   args: sr0a:/bsd OpenBSD IEEE 1275 Bootblock 1.4

   OpenBSD BOOT 1.9 Error: /iscsi-hba: no
   iscsi-network-bootpath property Unknown device: sr0 Cannot
   boot from softraid: Unknown error: code 19 Program terminated

The only other information I can find online involving a softraid error 
code 19 was the following: 
http://openbsd-archive.7691.n7.nabble.com/5-8-sparc64-boot-from-softraid-4-fails-td284700.html 



Considering he was running 5.8 and I am on 6.2 and the fix for his issue 
has already been committed, I’m left scratching my head as to what the 
problem here could be.


The install procedure I followed on the T4 was:

1) Boot install kernel and drop to shell and provision RAID partitions 
on both disks using the letter “a” via disklabel(8)


2) Assemble RAID volume with # bioctl -c 1 -l /dev/sd0a,/dev/sd1a softraid0

3) I zeroed the first 10MB of the RAID volume with # dd if=/dev/urandom 
of=/dev/rsd2c bs=1m


4) I finished off the install as usual by typing ”install” into command 
line and proceeded normally


5) I then rebooted and set the boot parameters at the ok prompt as per 
boot_sparc(8)


Aside from the sparc64 specific stuff, these same steps (plus x86 
specific fdisk stuff) get me a working, bootable softraid mirror on my 
i386/amd64 test boxes.



It appears the issue I linked to in the OpenBSD archive, was that the 
bootloader couldn't probe beyond 4 levels deep in the device tree. 
According to Stefan Sperling he committed a patch to allow it to probe 
to (an arbitrarily set) 10 levels deep in the device tree. According to 
my devalias output, my disk0 appears to be 6 levels deep in the tree if 
I am reading it correctly.


I did manage to get the T4 booting from softraid using this guide: 
http://brycv.com/blog/2012/openbsd-sparc64-and-root-on-softraid/


That guide however does seem to contravene the guidelines set forth in 
softraid(4): “On sparc64, bootable chunks must be RAID partitions using 
the letter ‘a’ .”


With the above guide from brycv.com we end up with 3 separate partitions 
on our disks. This doesn't seem right as on amd64/i386 you would only 
have a single raid partition per disk, not a separate root and swap 
partition in addition to the RAID partitions. It would also seem that a 
rebuild would involve significantly more manual intervention to maintain 
drive bootability in the event of one of the drives in the mirror going 
down ie: One wouldn't just be able to run bioctl -R /dev/rsd1a sd2 and 
have the array be golden again, they would instead also need to mount 
and copy over the contents of the other non RAID partitions on the disk.


In short, on sparc64, is softraid boot like that of i386/amd64 where 
everything including root is stored within the RAID volume, or does 
sparc64 require me to have a small partition at the beginning of my 
physical disks containing the kernel and ofwboot? One fellow on reddit 
said he had a T1000 booting softraid crypto no problem so I am wondering 
if this is a T4 specific issue.


Sorry for the wall of text, I really appreciate any help you guys can 
offer. Let me know if you need any other information and I’ll be happy 
to provide it. Does anyone else here have any experience with sparc64 
softraid booting or with OpenBSD on a T3 or T4? Please let me know, and 
Merry Christmas to all!


Obligatory dmesg:

T4 -1 Output
# dmesg
console is /virtual-devices@100/console@1
Copyright (c) 1982, 1986, 1989, 1991, 1993
The Regents of the University of California.  All rights reserved.
Copyright (c) 1995-2017 OpenBSD. All rights reserved. 
 https://www.OpenBSD.org

OpenBSD 6.2 (RAMDISK) #282: Tue Oct  3 23:21:19 MDT 2017
dera...@sparc64.openbsd.org:/usr/src/sys/arch/sparc64/compile/RAMDISK
real mem = 136902082560 (130560MB)
avail mem = 13451208 (128280MB)
mainbus0 at root: SPARC T4-1
cpu0 at mainbus0: SPARC-T4 (rev 0.0) @ 2847.862 MHz
"SPARC-T4" at mainbus0 not configured
"SPARC-T4" at mainbus0 not configured
"SPARC-T4" at mainbus0 not configured
"SPARC-T4" at mainbus0 not configured
"SPARC-T4" at mainbus0 not configured
"SPARC-T4" at mainbus0 not configured
"SPARC-T4" at mainbus0 not configured
"SPARC-T4" at 

Re: bug tracking system for OpenBSD

[Stuart Henderson]

On 2017-12-26,   wrote:
> If I were to set such a thing up, I wouldn't even bother pulling stuff
> from tech@ and bugs@ at all. Too much work, no real benefit.

"too much work". I think you misunderstand bug trackers. They aren't some
magic thing that automatically turns a submission into a usable bug report.
Whether reports are coming from list posts or ticket submissions, the
triage and information gathering still needs to be done.

> The project seems to do well even without one, and maybe the devs are
> satisfied with bugs@ and tech@ already. What issues/problems in
> workflow will a bug tracker resolve that cannot be covered by bugs@ and
> tech@ lists?

bugs/tech@ are better than the sort of tracker you'll get from someone
who thinks it's enough to just set it up, let people post bugs to it,
and lets devs deal with the rest. But they definitely have problems.

- Forgotten unfixed bugs.

- Forgotten *fixed* bugs (i.e. where the fix hasn't been committed).

- Crappy bug reports where developers have to drag the information out
of the reporter and it gets fragmented across a dozen posts, some
on list, some in private mail.

In short: if someone wants to do the work to fix this, that's great
and I'm trying to make sure anyone thinking about this has an idea of
the work involved. It would be a useful way someone with good general
knowledge of the OS but maybe not so much in the way of coding skills
could help. But at the same I'm trying to make sure people know that
simply setting up ticketing software then walking away is not going
to be helpful.

Re: New default setup for touchpads in X

[Ulf Brosziewski]

Hi Matthias,

it's true that the new input driver has a comparatively high
threshold before it starts scrolling.  I think it's necessary.
With synaptics it may happen too easily that two-finger contacts
trigger scroll events accidentally.  A somewhat sloppily performed
two-finger tap may have that effect, for example.

It's possible change the scroll speed, wsconsctl can access low-level
parameters of the driver.  However, be aware that I consider those
parameters as internal.  I won't change them without reasons, but
if any of them turn out to be in the way of making improvements and
cannot be kept stable without efforts, they may change or disappear.
You shouldn't use them if you don't want to live with that.

The command for reading such a parameter is
# wsconsctl mouse.tp.param=INDEX
and for writing, it's
# wsconsctl mouse.tp.param=INDEX:VALUE
You can list up to 4 indices or index/value pairs, separated by
commas.  Indices and values are integers.  The parameters 134 and 133
determine the speed of vertical and horizontal scrolling, so
# wsconsctl mouse.tp.param=134,133
will read them and
# wsconsctl mouse.tp.param=134:...,133:...
will change them.  You have to reduce the values - which represent
distances in device units - in order to increase the scroll speed
(the relation is inversely proportional).  And BTW, such a change
would also reduce the threshold - in the current implementation, at
least ;-)

Regards,
Ulf


On 12/23/2017 08:12 PM, Matthias Schmidt wrote:
> Hi Ulf,
> 
> * Ulf Brosziewski wrote:
>> If you're following -current, or if you upgrade your system with the
>> next or a future snapshot, please note that the default setup for
>> touchpads in X will change.
> 
> Finally, I found the time to switch from Synaptics to the ws driver.
> Running current from Dec 23 here.
> 
> mouse.type=synaptics
> mouse.rawmode=0
> mouse.scale=1266,5676,1096,4758,0,45,68
> mouse.tp.tapping=0
> mouse.tp.scaling=0.160
> mouse.tp.swapsides=0
> mouse.tp.disable=0
> mouse1.type=ps2
> 
> Using a Thinkpad T450s here.  So far, I tested two-finger scrolling and
> the usual touchpad actions.  I noticed two things:
> 
> 1. The pointer speed seems a bit slow for me.  Can I somehow
> increase the speed?
> 2. Two-finger scrolling takes more 'activation energy' compared to the
> Synaptic driver.  With the latter I only needed to lightly scroll over
> the touchpad to trigger scrolling.  With ws I need to push the fingers
> harder on the trackpad.  Example: With ws I need 7 scroll actions to
> scroll down the entire "Install FAQ" article.  With synaptics I only
> need 4 scroll actions.
> 
> Cheers
> 
>   Matthias
> 
> 

Re: Hellos from the Lands of ..Arkanaias

[Üven Cærlyen]

Ok peeps, I think my specification is nearing completion.

https://www.youtube.com/watch?v=x8HzSVdBHZU

Racoh Box!

"The OS also is I/O via abstracted inferfaces, signal routing 
(scheduling etc) and usually a graphical user interface. Peak jitter 
below 200us = optimal."


The whole streaming paradigm could be implemented in a new web standard 
aswell,  where instead of HTML commands, binary values for speed, and 
with all digital goods marked with author, and automatically allotted 
bitcoin values for its use. Code components for os, also being digital 
goods etc."


Peaceful Salutations.

Mount AFP (Apple Filing Protocol) share on OpenBSD ?

[Christoph R. Murauer]

Hello !

Is there a way to mount a AFP (AirPort Extreme with a external USB HD
in a LAN) share from OpenBSD ? Or, is the only way to use NFS (or the
netatalk package) and copy the files from a macOS machine to the AFP
share ?

Thanks for answers

Christoph

Re: mpv zombie process, lock sound device upon suspending process

[x9p]

On Tue, December 26, 2017 11:44 am, Klemens Nanni wrote:
> On Tue, Dec 26, 2017 at 08:56:12AM -0200, x9p wrote:
>> If someone can give it a try, I had found no solution to free the sound 
>> device or to kill a
>> mpv zpmbie process.
>>
>> Inside a tmux panel, while playing any audio/video, hit CTRL+Z . Then you 
>> will not be able
>> to
>> resume the process with fg, neither kill it, and it will lock the sound 
>> device until next
>> reboot.
> After suspending it, the mpv process will be stopped, indicated by
> ps(1) with the T state.
>
> Sending a SIGCONT signal continues the mpv process which will eventually
> exit.
>
>

You are right, I was able to continue it. Thank you.

I cannot reproduce the problem anymore. In the past the state was "pk", if I 
remember well
not "T".

cheers.

--
x9p | PGP : 0x03B50AF5EA4C8D80 / 5135 92C1 AD36 5293 2BDF  DDCC 0DFA 74AE 1524 
E7EE

Re: bug tracking system for OpenBSD

[Christoph R. Murauer]

>From the original question of the OP

> ... and (very important) some reliable response time and ...

> Currently I have the impression that you have to be very lucky
to be recognized on b...@openbsd.org. This is highly frustrating
and discouraging.

OpenBSD is developed entirely by volunteers. IMHO And, developers do
that in there spare time, they also have a family and a social life.
Even there is a bug tracker, if the OP can't be patient the answer
will always be like, shutup and hack yourself or, hire someone from
the list of commercial service.

Re: mpv zombie process, lock sound device upon suspending process

[Klemens Nanni]

On Tue, Dec 26, 2017 at 08:56:12AM -0200, x9p wrote:
> If someone can give it a try, I had found no solution to free the sound 
> device or to kill a
> mpv zpmbie process.
> 
> Inside a tmux panel, while playing any audio/video, hit CTRL+Z . Then you 
> will not be able to
> resume the process with fg, neither kill it, and it will lock the sound 
> device until next
> reboot.
After suspending it, the mpv process will be stopped, indicated by
ps(1) with the T state.

Sending a SIGCONT signal continues the mpv process which will eventually
exit.

Re: bug tracking system for OpenBSD

[bytevolcano]

If I were to set such a thing up, I wouldn't even bother pulling stuff
from tech@ and bugs@ at all. Too much work, no real benefit. I would
simply have the bug tracker to all new bugs, and maybe keep the bugs@
list open concurrently with the tracker for a period to allow older bugs
to be resolved.

Before all that, I would ask if OpenBSD really needs a bug tracker.
The project seems to do well even without one, and maybe the devs are
satisfied with bugs@ and tech@ already. What issues/problems in
workflow will a bug tracker resolve that cannot be covered by bugs@ and
tech@ lists?

On Mon, 25 Dec 2017 14:46:25 -0800
Kai Wetlesen  wrote:

> Agreed, partially, with both of you. It may be possible to automatically 
> filter 
> some of the chaff (user errors and support requests in disguise) 
> in one large batch so to pressed the DB but forwarding mailing list touches 
> to the bug tracker would make things ugly fast.
> 
> What would be involved to pull the current state of bugs@ and tech@?

Re: bug tracking system for OpenBSD

[Ali Farzanrad]

On Sat, Dec 23, 2017 at 10:24:25AM +, Stuart Henderson wrote:
> The idea of a bug tracking system is to spread the work and help
> people remember things. It should *reduce* work done by devs because
> they no longer have to drag even the most basic information out
> of a reporter and figure out whether it's a bug or user error
> or a support request in disguise.
> 
> If it means *extra* work for devs, it's not going to work.
> 

I think that a simple directory in CVS repository could do that.  Also
it can be updated simply using `cvs commit'.  The directory sould have
plain text files for each unsolved issue.

mpv zombie process, lock sound device upon suspending process

[x9p]

Hi,

If someone can give it a try, I had found no solution to free the sound device 
or to kill a
mpv zpmbie process.

Inside a tmux panel, while playing any audio/video, hit CTRL+Z . Then you will 
not be able to
resume the process with fg, neither kill it, and it will lock the sound device 
until next
reboot.


cheers.

--
x9p | PGP : 0x03B50AF5EA4C8D80 / 5135 92C1 AD36 5293 2BDF  DDCC 0DFA 74AE 1524 
E7EE

Re: Picking the nearest (not necessarily fastest) anoncvs server

[Stuart Henderson]

On 2017-12-24, Dinesh Thirumurthy  wrote:
> After some text processing of traceroute outputs, we get ...
>
> (server, rtt in ms, path info from geoip)

You can't identify the path from the server to you, only from you to the
server. They're often different. And they can change at any time.

Here's a good presentation about traceroute:

http://youtu.be/WL0ZTcfSvB4
http://www.nanog.org/sites/default/files/tuesday_steenbergen_troublshootingtraceroute_62.49.pdf

Re: bug tracking system for OpenBSD

[Stuart Henderson]

On 2017-12-25, Kai Wetlesen  wrote:
> Agreed, partially, with both of you. It may be possible to automatically 
> filter 
> some of the chaff (user errors and support requests in disguise) 
> in one large batch so to pressed the DB but forwarding mailing list touches 
> to the bug tracker would make things ugly fast.
>
> What would be involved to pull the current state of bugs@ and tech@?

Somebody reading the posts, asking the right questions where information
is missing, and writing up the problems.

This is not something that can be automated.