Re: portgen does not handle go ports with capital letter in name

2021-08-22 Thread Aaron Bieber



On Sun, Aug 22, 2021, at 5:33 AM, Vladimir Nikishkin wrote:
> Dear all,
> 
> I tried to use portgen to semi-automatically generate a port for a go
> project with a capital letter in the name.
> 

Are you running an older version of OpenBSD? I fixed this back in January : 
https://github.com/openbsd/ports/commit/1018dcc9306aec55d1d77d7497e79dd23e6d2f17#diff-2773095265524b4baa05e35ffd3a1d634b0aadfe3cacf408cb00133bdf84d419


> It failed with a cryptic error. I commented out the code in Port.pm the
> place which retries to generate a name for everything other than Perl
> (p5), and it worked.
> 
> I thing Go.pm does not expect to be called the second time with a name.
> 
> Hope this helps.
> 
> -- 
> Your sincerely,
> Vladimir Nikishkin (MiEr, lockywolf)
> (Laptop)
> 
> 



Re: Workman keyboard layout

2021-07-03 Thread Aaron Bieber


koi...@tilde.club writes:

> Hello,
>
> How could I add the Workman keyboard layout so that it can be used as a 
> keyboard
> encoding with wsconsctl?
>
> Cheers,
> Gabriel

Hi! Easiest way is to create a wsconsctl.conf that sets each key to the
proper value.

Here is the colemak equiv from colemak.com:

#!/bin/sh
# Colemak layout script for OpenBSD console.
# 2006-01-01 Shai Coleman, http://colemak.com/ . Public domain.

wsconsctl keyboard.encoding=us  \
keyboard.map+="keycode  41 =  graveasciitilde   dead_tilde  
  asciitilde " \
keyboard.map+="keycode   2 =  1exclam   exclamdown  
 onesuperior " \
keyboard.map+="keycode   3 =  2atmasculine  
 twosuperior " \
keyboard.map+="keycode   4 =  3numbersign  ordfeminine  
   threesuperior " \
keyboard.map+="keycode   5 =  4dollar cent  
sterling " \
keyboard.map+="keycode   6 =  5   percent   asciitilde  
 yen " \
keyboard.map+="keycode   7 =  6   asciicircum   asciitilde  
  asciitilde " \
keyboard.map+="keycode   8 =  7 ampersand  eth  
 ETH " \
keyboard.map+="keycode   9 =  8  asteriskthorn  
   THORN " \
keyboard.map+="keycode  10 =  9 parenleft   asciitilde  
  asciitilde " \
keyboard.map+="keycode  11 =  0parenright   asciitilde  
  asciitilde " \
keyboard.map+="keycode  12 =  minusunderscore   asciitilde  
  asciitilde " \
keyboard.map+="keycode  13 =  equal  plus multiply  
division " \

   \
keyboard.map+="keycode  16 =  q Q   adiaeresis  
  Adiaeresis " \
keyboard.map+="keycode  17 =  w Waring  
   Aring " \
keyboard.map+="keycode  18 =  f F   atilde  
  Atilde " \
keyboard.map+="keycode  19 =  p P   oslash  
Ooblique " \
keyboard.map+="keycode  20 =  g G   asciitilde  
  asciitilde " \
keyboard.map+="keycode  21 =  j J   asciitilde  
  asciitilde " \
keyboard.map+="keycode  22 =  l L   asciitilde  
  asciitilde " \
keyboard.map+="keycode  23 =  u U   uacute  
  Uacute " \
keyboard.map+="keycode  24 =  y Y   udiaeresis  
  Udiaeresis " \

keyboard.map+="keycode  25 =  semicolon colon   odiaeresis  
  Odiaeresis " \

keyboard.map+="keycode  26 =bracketleft braceleftguillemotleft  
  asciitilde " \

keyboard.map+="keycode  27 =   bracketrightbraceright   guillemotright  
  asciitilde " \

keyboard.map+="keycode  43 =  backslash   bar   asciitilde  
  asciitilde " \


   \

keyboard.map+="keycode  30 =  a A   aacute  
  Aacute " \

keyboard.map+="keycode  31 =  r R   dead_grave  
  asciitilde " \

keyboard.map+="keycode  32 =  s S   ssharp  
  asciitilde " \

keyboard.map+="keycode  33 =  t T   dead_acute  
  asciitilde " \ 

Re: 9Front on VMM on Ryzen Hardware

2020-12-15 Thread Aaron Bieber


e...@disroot.org writes:

> Hello, I hope that this is the right mailing list to send this query to.
>
> First some background. It is possible to run 9front on OpenBSD using
> vmm, this is well documented and I have gotten it working before on a
> ThinkPad X220.
> Where I run into trouble is trying to install it on a T14 AMD, which
> uses an AMD processor. Essentially when you begin to run the live cd,
> the 9front kernel loads, and then immediately vmd restarts the virtual
> machine, presumably because it crashed somewhere in the boot process.
>
> Now to the question, how would I go about debugging this? I know that
> this install works on Intel, this is on OpenBSD -current.
>
> The 9front IRC told me that it was a vmm issue, as there are different
> implementations on AMD and Intel, is this true?
> If so, what debugging should I run to help the OpenBSD developers fix
> this issue?
>
> If it's a 9front issue, is there any way for me to be able to take some
> kind of memory dump so that the 9front developers can handle this?
>
> Hopefully this wasn't too off topic, I have read the relevant manual
> pages for vmm, but I couldn't work out what debugger to use, I'm not
> here to get others to debug it for me, only to work out where to start.
>
> Thank you

I have run into this as well.. There was a change in 9front some time
before the release of the amd64 ISOs that seems to have caused it.

I was able to boot the 386 ISO (9front-7408.1d345066125a.386.iso) and a
amd64 kernel built from the source contained within that ISO. There was
about a full year of development between that ISO and when I started
seeing the issue, so it's not a very useful data point :P.

cinap on #cat-v had some pointers for troubleshooting:

2020-05-29 07:19:47 cinap_lenrekso go to /sys/src/boot/pc
2020-05-29 07:19:55 cinap_lenrekin the mkfile, theres a test.iso target 
or something
2020-05-29 07:20:02 cinap_lenrekyou can adjust that
2020-05-29 07:20:07 qbitok
2020-05-29 07:20:24 cinap_lenrekbasically, you want a workflow where 
you just run a command to generate a new iso with the kernel
2020-05-29 07:20:28 cinap_lenreknothing else
2020-05-29 07:20:35 cinap_lenrekthats good enougth to troubleshoot this
2020-05-29 07:20:41 cinap_lenrekand then boot it from vmd

Sorry it isn't much help!

Cheers,
Aaron



Re: Kibana/Elasticsearch fail

2020-02-10 Thread Aaron Bieber
On Thu, 06 Feb 2020 at 23:31:01 -0600, Eric Zylstra wrote:
> I’ve installed the ELK packages (Elasticsearch, Logstash, Kibana) using 
> pkg_add.  Installs went fine.  I checked out the pkg documentation 
> (pkg_reames) and followed the steps for those that had documentation to 
> follow.
> 
> When I boot, Logstash and Kibana fail.  I can use rcctl to start Logstash 
> with no problem.  When I try to start Kibana, the following is what I see:
> 
> # rcctl -d start kibana
> doing _rc_parse_conf
> doing _rc_quirks
> kibana_flags empty, using default ><
> doing _rc_parse_conf /var/run/rc.d/kibana
> doing _rc_quirks
> doing rc_check
> kibana
> doing rc_start
> doing _rc_wait start
> doing rc_check
> No home directory /nonexistent!
> Logging in with home = "/".
> Kibana does not support the current Node.js version v10.16.3. Please use 
> Node.js v>=10.15.0 <10.16.
> doing _rc_rm_runfile
> (failed)
> 
> 
> I’m not sure what to do with this.  Why is Logstash not starting on reboot?  
> Why does Kibana fail?  I assume there is some config that need be done, 
> because that Node.js error wouldn’t have made it to distribution, right?

> that Node.js error wouldn’t have made it to distribution

It did, and it's entirely my fault.

Kibana is failing because it is very strict about the version of node it wants
to use (hence the "Kibana does not support.." message). 

Apparently the tests I had run to verify this update worked failed:
http://cvsweb.openbsd.org/cgi-bin/cvsweb/ports/www/kibana/patches/patch-package_json?rev=1.4=text/x-cvsweb-markup

Here is a diff that fixes it for 6.6 (you will have to build it from ports
until (if?) a proper fix is in place).

https://deftly.net/patches/kibana-6.6.1.diff

Index: Makefile
===
RCS file: /cvs/ports/www/kibana/Makefile,v
retrieving revision 1.32
diff -u -p -r1.32 Makefile
--- Makefile28 Sep 2019 09:37:54 -  1.32
+++ Makefile11 Feb 2020 04:13:52 -
@@ -3,7 +3,7 @@
 COMMENT=   browser based analytics/search interface to ElasticSearch
 
 V =6.6.1
-REVISION = 1
+REVISION = 2
 PKGNAME =  kibana-${V}
 DISTNAME = kibana-oss-${V}-darwin-x86_64
 
Index: patches/patch-package_json
===
RCS file: /cvs/ports/www/kibana/patches/patch-package_json,v
retrieving revision 1.4
diff -u -p -r1.4 patch-package_json
--- patches/patch-package_json  13 May 2019 22:08:11 -  1.4
+++ patches/patch-package_json  11 Feb 2020 04:13:52 -
@@ -8,7 +8,7 @@ Index: package.json
},
"engines": {
 -"node": "10.15.1"
-+"node": ">=10.15.0 <10.16"
++"node": "10.16.3"
}
 -}
 \ No newline at end of file

> 
> Thanks,
> 
> EZ

-- 
PGP: 0x1F81112D62A9ADCE / 3586 3350 BFEA C101 DB1A  4AF0 1F81 112D 62A9 ADCE



Re: Blind OpenBSD users

2019-05-17 Thread Aaron Bieber
On Fri, 17 May 2019 at 14:14:25 -0500, Tim Chase wrote:
> (sorry, out of thread; copying from the marc.info post so
> References/In-Reply-To aren't set)
> 
> > I am looking to understand / enhance the OpenBSD experience for
> > blind users.
> 
> While not blind, I occasionally attempt to do some screenless testing
> with accessibility-tech on OpenBSD, FreeBSD, and Linux.  I also hang
> out in the blinux mailing list for blind Linux users, so am
> interested in making the BSDs more accessible.
> 
> > Do we have any blind users reading misc that can offer any insight
> > into their usecases / pain points / work flows / wants?
> > I am sure OpenBSD is lacking on this front, so use cases in *nix
> > would also be helpful.
> 
> From some recent experiences:
> 
> - using a serial port or SSH has proven the best/most-reliable.  For
>   some the machine would be attached to an external serial-driven
>   synth or Braille device.  For others, it's a serial program on
>   another machine that is accessible, or accessing via SSH from that
>   other machine.  However, as powerful as the CLI is, it doesn't grant
>   access to GUI tools like a real browser.
> 
> - yasr isn't available as a package (it's my go-to console
>   screen-reader) but can be installed from source.  It does have a
>   sample config file but needs a bunch of work to get set up,
>   including getting speech-dispatcher to listen via an inet socket
>   rather than a unix socket, then pointing yasr at speech-dispatcher,
>   and making sure that it is configured properly. Also,
>   speech-dispatcher times out after 5-seconds with no connection, so
>   you have to know to start yasr within that window of time.
> 
> - attempting to `pip install fenrir-screenreader` fails because it
>   uses some linux-specific headers
> 
> Getting Orca set up is a bit of a bear.  Doable, but it already
> assumes you have access to the system.  But roughly involves
> installing Gnome (plus configuring GDM which is mostly following the
> docs, but it's certainly not out-of-the-box easy), Orca, eflite,
> etc.  While GDM comes up with options to turn on text-to-speech, you
> have to know the Alt+Super+S shortcut to enable, and you have to know
> how to *use* Orca to navigate it.  All of that   All of that is pretty
> difficult to do if you're blind and on your own.
> 
> Additionally, latency in Orca is pretty horrible on my test machine
> here, even under light usage (in this context, running Gnome and the
> Orca settings panel; no extra programs or non-default OBSD services
> running).  It's not a powerhouse machine (3GB of RAM, dual-core 2GHZ)
> but it's also not unreasonable specs for an older machine.
> 
> So in the end, using ssh/serial from a remote machine or using yasr +
> speech-dispatcher locally was the most usable solution I've been able
> to get working.  It would be nice to get Orca working usably so I
> could test with a GUI browser.
> 
> As for things that could be improved, a couple ideas:
> 
> - adding yasr to the package repos
> 
> - perhaps some meta-package or a tutorial on getting
>   speech-dispatcher + yasr + flite/festival/espeak/whatever working
>   together
> 
> - tweak Gnome or whatever launches Orca so that it comes up with a
>   tutorial mode and/or settings on first-run.
> 
> I'd be glad to test other configurations if needed.

This is great info! Thank you!

I have added a WIP port for yasr here:
  https://github.com/jasperla/openbsd-wip/tree/master/sysutils/yasr

Using this + speech-dispatcher + espeak + edbrowse (recently imported) I can
browse sites pretty well with no visual feedback!

I will look into the other projects you mentioned!

Thanks again!

> 
> -tkc
> (@gumnos)
> 
> 

-- 
PGP: 0x1F81112D62A9ADCE / 3586 3350 BFEA C101 DB1A  4AF0 1F81 112D 62A9 ADCE



Re: Blind OpenBSD users

2019-05-13 Thread Aaron Bieber
On Mon, 13 May 2019 at 11:24:57 +0300, Dumitru Moldovan wrote:
> On Fri, May 10, 2019 at 08:05:08AM -0600, Aaron Bieber wrote:
> > Hi misc@!
> > 
> > I am looking to understand / enhance the OpenBSD experience for blind users.
> > 
> > Do we have any blind users reading misc that can offer any insight into 
> > their
> > usecases / pain points / work flows / wants? I am sure OpenBSD is lacking on
> > this front, so use cases in *nix would also be helpful.
> 
> I've worked for the GNOME project as a translator some years ago.  I
> know from the strings I've translated that they worked hard on a11y
> (accessibility).  I don't use GNOME anymore (except through its most
> basic libs, such as GTK+), but I think it's usable under OpenBSD.
> 
> A couple of links to get you going:
>  * https://help.gnome.org/users/gnome-help/stable/a11y.html.en
>  * https://wiki.gnome.org/Accessibility
> 
> KDE has a similar a11y initiative, but it seems less entrenched than
> GNOME's one: https://userbase.kde.org/System_Settings/Accessibility.
> Even their tutorial suggests using the KDE apps under a GNOME desktop
> when using a screen reader:
> https://techbase.kde.org/Development/Tutorials/Accessibility/Screen_Reader_Setup#Screen_Readers
> 
> Another interesting link I've found, touching on both GNOME and KDE,
> but also listing alternatives to GNOME's Orca screen reader:
> https://www.freedesktop.org/wiki/Accessibility/.
> 
> Hope that helps!  Not a blind user here...  Also, was hoping someone
> more knowledgeable would step in to answer.  As far as I can tell,
> there is no a11y support in OpenBSD's native console, so it seems blind
> users can only use graphical applications under OpenBSD.

Thanks for the info!

> 

-- 
PGP: 0x1F81112D62A9ADCE / 3586 3350 BFEA C101 DB1A  4AF0 1F81 112D 62A9 ADCE



Blind OpenBSD users

2019-05-10 Thread Aaron Bieber
Hi misc@!

I am looking to understand / enhance the OpenBSD experience for blind users.

Do we have any blind users reading misc that can offer any insight into their
usecases / pain points / work flows / wants? I am sure OpenBSD is lacking on
this front, so use cases in *nix would also be helpful.

Cheers,
Aaron

-- 
PGP: 0x1F81112D62A9ADCE / 3586 3350 BFEA C101 DB1A  4AF0 1F81 112D 62A9 ADCE



Re: I can't open web.telegram.org in the Chromium

2019-03-08 Thread Aaron Bieber


Vitaly Kovalyshyn writes:

> Hi @misc !
>
> I need to use Telegram as my main messenger. I'm trying open 
> https://web.telegram.org in the Chromium (-current). But browser crashed. I 
> have installed firefox and surf - everything work fine. The site opens and 
> web version works fine.
>
> Can someone open https://web.telegram.org in the current version of the 
> Chromium? How to fix it? I don't want to use additional browser for Telegram 
> only...
>
> Thank You.

It works fine for me using iridium (with unveil and --site-per-process).

>
>
>
> OpenBSD 6.5-beta (GENERIC.MP) #776: Wed Mar  6 18:03:29 MST 2019
> dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
> real mem = 4175851520 (3982MB)
> avail mem = 4039340032 (3852MB)
>
> chromium-72.0.3626.121
>
>$ chrome web.telegram.org
>
> [63996:-1842259736:0308/173107.524633:ERROR:process_posix.cc(388)] Not 
> implemented reached in base::Time base::Process::CreationTime() const
>
> <--- Last few GCs --->
>
> [7985:0xb38758db000] 8635 ms: Mark-sweep 10.9 (14.8) -> 10.9 (14.3) MB, 
> 37.3 / 2.4 ms  (average mu = 0.028, current mu = 0.001) memory pressure GC in 
> old space requested
> [7985:0xb38758db000] 8675 ms: Mark-sweep 10.9 (14.3) -> 10.2 (14.3) MB, 
> 37.8 / 2.2 ms  (average mu = 0.041, current mu = 0.057) memory pressure GC in 
> old space requested
>
>
> <--- JS stacktrace --->
>
>  JS stack trace =
>
> 0: ExitFrame [pc: 0xb35afa2b46b]
> 1: StubFrame [pc: 0xb35af98210b]
> Security context: 0x0ea2acc4bc11 https://web.telegram.org>
> 2: p(aka p) [0x29b671e60b99] [https://web.telegram.org/js/app.js:20] 
> [bytecode=0x319520badc71 offset=209](this=0x084703f004d1 ,1048576)
> 3: new constructor(aka t) [0x1ececcb88219] 
> [https://web.telegram.org/js/app.js:20] [bytecode=0x319520bad711 
> offset=81](this=0x29b671e60851 
> [63996:-2147143104:0308/173116.931342:ERROR:object_proxy.cc(621)] Failed to 
> call method: org.freedesktop.DBus.Properties.Get: object_path= 
> /org/freedesktop/UPower: org.freedesktop.DBus.Error.ServiceUnknown: The name 
> org.freedesktop.UPower was not provided by any .service files
> [63996:-2147143104:0308/173116.934483:ERROR:object_proxy.cc(621)] Failed to 
> call method: org.freedesktop.UPower.GetDisplayDevice: object_path= 
> /org/freedesktop/UPower: org.freedesktop.DBus.Error.ServiceUnknown: The name 
> org.freedesktop.UPower was not provided by any .service files
> [63996:-2147143104:0308/173116.935940:ERROR:object_proxy.cc(621)] Failed to 
> call method: org.freedesktop.UPower.EnumerateDevices: object_path= 
> /org/freedesktop/UPower: org.freedesktop.DBus.Error.ServiceUnknown: The name 
> org.freedesktop.UPower was not provided by any .service files


-- 



Re: emmc support on Ubiquiti Networks UniFi Security Gateway PRO-4

2019-02-13 Thread Aaron Bieber


Diana Eichert writes:

> I've been running OpenBSD 6.4 on a USG PRO-4 using external SSD drive
> in USB enclosure.
>
> The platform page states "OpenBSD/octeon can be installed on all
> machines which have local Compact Flash or USB storage".
>
> The USG PRO-4 uses emmc storage.  According to commit 1.28 of RAMDISK config "
>
> Add a driver for OCTEON MMC host controller.
>
> Tested on EdgeRouter Pro, and Shasta."
>
> Therefore I should be able to install on the emmc, correct assumption?

Correct. I set this up a few days ago without issue. I still use an
external usb drive for building various ports I need, but OpenBSD is
installed on the mmc.

IIRC I did something like this in u-boot:

# setenv bootcmd 'fatload mmc 0 ${loadaddr} bsd;bootoctlinux rootdev=sd0'

>
> If so, is there a good way to dump existing factory firmware from emmc
> before I install OpenBSD?  At some point I may have to restore to
> factory.

Not sure on this bit :D

>
> thanks
>
> diana


-- 
PGP: 0x1F81112D62A9ADCE / 3586 3350 BFEA C101 DB1A  4AF0 1F81 112D 62A9 ADCE



Re: light browsers

2016-05-12 Thread Aaron Bieber
sogal writes:

> Le Wednesday 11 May 2016 à 10:26:03PM, 3sad68+aivzh013i5...@guerrillamail.com 
> a écrit :
>> Hi,
>> 
>> did anyone try Midori or other light browsers with good results ?
>
> You might want to give a try to xombrero.
> It's webkit based and was "Built with security in mind" [0]

Basically anything that is using webkit is going to have issues:
https://blogs.gnome.org/mcatanzaro/2016/02/01/on-webkit-security-updates/

This means, xombrero, luakit, probably all the others that aren't
firefox and chromium.

>
> When in "whitelist" mode, it provides a fine grained, per-domain control
> over cookies and JS activation and is highly configurable through a
> well documented conf file (sane vim-like keybindings and mouse control
> if needed).
>
> I use it everyday, it's ok for general purpose even though some fancy
> website design may appear broken from time to time.
>
> [0] https://opensource.conformal.com/wiki/xombrero



Re: Spotify client for OpenBSD

2015-11-16 Thread Aaron Bieber
On Mon, Nov 16, 2015, at 07:20 AM, Chris Mailer wrote:
> Is there any Spotify client for OpenBSD? I tried Spotify support in
> clementine, which doesnt seem to work since the spotify blob seems to
> rely on Linux libs. I even tried to get it work using compat_linux and
> installing the missing fc10 rpms, but without success.
> Thanks,
> Chris
> 

A long time ago this worked: https://github.com/eest/despotify-obsd



Re: Spotify client for OpenBSD

2015-11-16 Thread Aaron Bieber
On Mon, Nov 16, 2015, at 12:15 PM, Rick Hanson wrote:
> > A long time ago this worked: https://github.com/eest/despotify-obsd
> 
> Aaron, thanks for hosting the distro
> (http://qbit.devio.us/despotify-1.520.tar.gz).  The original (at
> http://despotify.se) seems to be long gone.
> 

NP - thanks to Devio.us! There is also a node client that worked, but
there wasn't a UI for it back then:

https://github.com/qbit/spot was my attempt at making one.



Re: KeePass 2.30- libpng and other errors

2015-08-21 Thread Aaron Bieber
Peter Van Eenoo writes:

 If you don't need the keepass 2x functionality, then the keepass 1x package
 is available and works great.
 On Aug 20, 2015 8:28 AM, Andrzej Drewnowski andrewdrewnow...@gmail.com
 wrote:

If you DO need keepass 2x functionality I have a WIP port that builds
the latest beta of keepassx: 
https://github.com/qbit/mystuff/tree/master/security/keepassx

It is buggy, but seems to work well enough.


 Hello!

 I am trying to run KeePass on OpenBSD (amd64)- current (but on 5.7 are the
 same errors). I installed Mono from packages and downloaded
 KeePass-2.30-portable. Unfortunately I can't start KeePass because of this
 errors:


 SendMessage (25165861, 0x112c, 0x4, 0x4)

 libpng error: invalid after png_start_read_image or png_read_update_info

 libpng error: invalid after png_start_read_image or png_read_update_info

 libpng error: invalid after png_start_read_image or png_read_update_info

 libpng error: invalid after png_start_read_image or png_read_update_info

 SendMessage (25165855, 0x101f, 0x0, 0x0)

 SendMessage (0, 0x1203, 0x0, 0x7f7ee970)

 SendMessage (0, 0x1204, 0x0, 0x7f7ee970)

 SendMessage (0, 0x1203, 0x1, 0x7f7ee970)

 SendMessage (0, 0x1204, 0x1, 0x7f7ee970)

 SendMessage (0, 0x1203, 0x2, 0x7f7ee970)

 SendMessage (0, 0x1204, 0x2, 0x7f7ee970)

 SendMessage (0, 0x1203, 0x3, 0x7f7ee970)

 SendMessage (0, 0x1204, 0x3, 0x7f7ee970)

 SendMessage (0, 0x1203, 0x4, 0x7f7ee970)

 SendMessage (0, 0x1204, 0x4, 0x7f7ee970)

 * Assertion at strenc.c:183, condition `utf8!=NULL' not met


 Stacktrace:


 at unknown 0x

 at (wrapper managed-to-native)
 KeePass.Native.NativeMethods.GetFileAttributes (string) 0x

 at KeePass.Native.NativeMethods.FileExists (string) 0x0002d

 at KeePass.Util.WinUtil.RemoveZoneIdentifier (string) 0x0006e

 at KeePass.Forms.MainForm.OnFormLoadParallelAsync (object) 0x00090

 at (wrapper runtime-invoke) Module.runtime_invoke_void__this___object
 (object,intptr,intptr,intptr) 0x


 =

 Got a SIGABRT while executing native code. This usually indicates

 a fatal error in the mono runtime or one of the native libraries

 used by your application.

 =


 Abort trap (core dumped)



 I would appreciate your help

 Regards

 Andrzej

-- 
Sent with my mu4e



Re: gr-osmosdr

2015-07-02 Thread Aaron Bieber
EdaSky writes:

 Greetings

 I would like to expand my Hamshack on SDR receiver via GQRX
 I would also like to analyze signals over gnuradio and build 
 port of gqrx and required dependency progs. 

 I bought

 http://dxpatrol.pt/
 ugen1 at uhub0 port 5 Realtek RTL2838UHIDIR rev 2.00 / 1.00 addr 2

 With ./comms/rtl-sdr works great on the FM Radio

 I built gnuradio from VIP Ports (thank you)
 Using RTL in gnuradio and buid Gqrx requires gnuradio-osmosdr

 It is possible to build gr-osmosdr?

 build prints lot of errors on


I believe I had it working at one point.. For sure I got SDR# going.

I will try and revive my stuff.. probably post it to wip if I get
anything going.

 OpenBSD 5.8-beta (GENERIC.MP) # 983: Fri Jun 26 10:19:43 MDT 2015
 dera...@i386.openbsd.org: /usr/src/sys/arch/i386/compile/GENERIC.MP


 git clone git://git.osmocom.org/gr-osmosdr
 cd gr-osmosdr/
 git checkout gr3.6
 mkdir build
 cd build/
 cmake ../
 make


 [  3%] Building CXX object 
 lib/CMakeFiles/gnuradio-osmosdr.dir/osmosdr_source_c_impl.cc.o
 In file included from 
 /usr/local/include/boost/thread/detail/platform.hpp:17,
  from /usr/local/include/boost/thread/thread.hpp:12,
  from /usr/local/include/gruel/thread.h:25,
  from /usr/local/include/gnuradio/gr_basic_block.h:36,
  from /usr/local/include/gnuradio/gr_hier_block2.h:26,
  from 
 /home/edasky/SRC/gr-osmosdr/include/osmosdr/osmosdr_source_c.h:25,
  from 
 /home/edasky/SRC/gr-osmosdr/lib/osmosdr_source_c_impl.h:23,
  from 
 /home/edasky/SRC/gr-osmosdr/lib/osmosdr_source_c_impl.cc:30:
 /usr/local/include/boost/config/requires_threads.hpp:47:5: error: #error 
 Compiler threading support is not turned on. Please set the correct 
 command line options for threading: -pthread (Linux), -pthreads (Solaris) 
 or -mthreads (Mingw32)
 In file included from /usr/local/include/boost/thread/thread.hpp:12,
  from /usr/local/include/gruel/thread.h:25,
  from /usr/local/include/gnuradio/gr_basic_block.h:36,
  from /usr/local/include/gnuradio/gr_hier_block2.h:26,
  from 
 /home/edasky/SRC/gr-osmosdr/include/osmosdr/osmosdr_source_c.h:25,
  from 
 /home/edasky/SRC/gr-osmosdr/lib/osmosdr_source_c_impl.h:23,
  from 
 /home/edasky/SRC/gr-osmosdr/lib/osmosdr_source_c_impl.cc:30:
 /usr/local/include/boost/thread/detail/platform.hpp:69:9: error: #error 
 Sorry, no boost threads are available for this platform.
 In file included from /usr/local/include/gruel/thread.h:25,
  from /usr/local/include/gnuradio/gr_basic_block.h:36,
  from /usr/local/include/gnuradio/gr_hier_block2.h:26,
  from 
 /home/edasky/SRC/gr-osmosdr/include/osmosdr/osmosdr_source_c.h:25,
  from 
 /home/edasky/SRC/gr-osmosdr/lib/osmosdr_source_c_impl.h:23,
  from 
 /home/edasky/SRC/gr-osmosdr/lib/osmosdr_source_c_impl.cc:30:
 /usr/local/include/boost/thread/thread.hpp:19:2: error: #error Boost 
 threads unavailable on this platform
 In file included from /usr/local/include/boost/thread/detail/thread.hpp:16,
  from /usr/local/include/boost/thread/thread.hpp:22,
  from /usr/local/include/gruel/thread.h:25,
  from /usr/local/include/gnuradio/gr_basic_block.h:36,
  from /usr/local/include/gnuradio/gr_hier_block2.h:26,
  from 
 /home/edasky/SRC/gr-osmosdr/include/osmosdr/osmosdr_source_c.h:25,
  from 
 /home/edasky/SRC/gr-osmosdr/lib/osmosdr_source_c_impl.h:23,
  from 
 /home/edasky/SRC/gr-osmosdr/lib/osmosdr_source_c_impl.cc:30:
 /usr/local/include/boost/thread/mutex.hpp:18:2: error: #error Boost 
 threads unavailable on this platform
 In file included from /usr/local/include/boost/thread/detail/thread.hpp:20,
  from /usr/local/include/boost/thread/thread.hpp:22,
  from /usr/local/include/gruel/thread.h:25,
  from /usr/local/include/gnuradio/gr_basic_block.h:36,
  from /usr/local/include/gnuradio/gr_hier_block2.h:26,
  from 
 /home/edasky/SRC/gr-osmosdr/include/osmosdr/osmosdr_source_c.h:25,
  from 
 /home/edasky/SRC/gr-osmosdr/lib/osmosdr_source_c_impl.h:23,
  from 
 /home/edasky/SRC/gr-osmosdr/lib/osmosdr_source_c_impl.cc:30:
 /usr/local/include/boost/thread/detail/thread_heap_alloc.hpp:19:2: error: 
 #error Boost threads unavailable on this platform
 In file included from 
 /usr/local/include/boost/thread/detail/thread_group.hpp:9,
  from /usr/local/include/boost/thread/thread.hpp:26,
  from /usr/local/include/gruel/thread.h:25,
  from /usr/local/include/gnuradio/gr_basic_block.h:36,
  from /usr/local/include/gnuradio/gr_hier_block2.h:26,
  

Re: Update OpenBSD Remotely

2015-05-18 Thread Aaron Bieber
On Sun, May 17, 2015, at 08:08 AM, Peter Leber wrote:
 I want to build a test system based on OpenBSD 5.7 which updates
 in an automated fashion.
 The goal is to have a remotely located machine which runs OpenBSD 5.7
 and is constantly updated. While restarting the machine remotely via SSH
 is perfectly fine to me, I do not want to access the machine locally in
 order to interrupt the automatic reboot in order to trigger the manual
 upgrading process. I'm fine with following -stable and -current alike.
 
 I recognize that there's m:tier's binary patching service 
 (https://stable.mtier.org), but the packages are signed
 by m:tier rather than the OpenBSD project. While following m:tier's
 binary patches is a good compromise to me, it's not a perfect solution.
 I'm perfectly fine with running the -current flavour of OpenBSD feature-
 and stability-wise, but I did not have the success of remotely triggering
 a script, rebooting the machine and have an up and running updated
 machine.
 While I did find the autoinstall(8) feature, which, since 5.7, should be
 able to trigger an automatic upgrade if the file /auto_upgrade.conf is
 present, I did not see an effect in the bootup messages on the virtual
 machine I'm using for testing things out.
 Furthermore, I did find a tool named snap, aiming at making running 
 -current more enjoyable (see https://github.com/qbit/snap), but it does
 also seem to be relying on the user to manually start the upgrading
 process on system reboot, if I got everything correctly.

Author of snap here. It depends, you can have it run things
automatically for you.. or it can just install the sets. By default it
will only install the sets.

It's specifically designed to run with no external dependencies (nothing
needs to be installed from ports) and can be run from cron. If you do
use it via cron don't forget to run sysmerge!

Let me know if you have any questions :D

 
 Is there someone aware of a procedure which could help me solving my
 problem?
 I thank you very much in advance.
 
 Peter



Re: urtwn device timeout

2014-12-17 Thread Aaron Bieber
Stefan Sperling writes:

 On Wed, Dec 17, 2014 at 12:39:15PM +0100, Marko Cupać wrote:
 Hi,
 
 I have occasional device timeout from urtwn on my ThinkPad T440 with usb
 wifi dongle.
 
 All I get in dmesg is:
 urtwn0: device timeout

 Yes, these devices tend to run hot and stop working. I have a
 urtwn(4) device that has the same problem. No fix is known.

 It's possible that powersaving is required for these devices to work
 reliably, which I don't think our urtwn(4) driver has support for.
 Someone with the necessary patience could try adding support for it.
 The Linux rtlwifi driver seems to support powersaving for this device.

If it's a heat thing, they sure seem to heat up faster with xhci
enabled.

I get an occasional timeout without xhci and about one every 5 to 10
minutes with it enabled. 

-- 



Re: one keydisk to access multiple encrypted systems

2012-08-25 Thread Aaron Bieber
On Sat, Aug 25, 2012 at 05:08:31PM +0200, Erling Westenvik wrote:
 On Sat, Aug 25, 2012 at 07:03:42AM -0600, Aaron wrote:
  
  It is possible if you use different partitions on the same drive, however,
  you would have to run -P twice ( once for each volume ).
  
 
 Sorry for not mentioning that I'm aware about the possibility of having
 several mini partitions on the key disk, one for each encrypted machine. 

k

 Also, the -P switch in bioctl(4) has nothing to do with the creation of
 a key disk since the passphrase is generated automatically when invoking

I never intended to imply that -P had anything to do with creation.  I
simply meant that you would have to run bioctl with the -P option twice,
once for each partition when changing your passphrase.
 
   # bioctl -C force -c C -l /dev/wd0d -k /dev/sd0d softraid0
 
 What I'm looking for is a way to have only one key disk partition for
 multiple machines. (Perhaps also a way to manually specify a passphrase
 in case of a lost/forgotten key disk, or a way to create a new key disk
 in case of a corrupted image. But I may be way out on this one..)
 

One key disk for multiple machines is impossible from what I
understand. Passphrase fallback is also currently impossible. 

Creating a backup key disk can be done with dd: 

  dd if=/dev/rsd1c of=keydisk.img bs=1m

Restore with:

  dd if=keydisk.img of=/dev/rsd1c bs=1m



Re: one keydisk to access multiple encrypted systems

2012-08-25 Thread Aaron Bieber
On Sat, Aug 25, 2012 at 06:21:58PM +0200, Erling Westenvik wrote:
 On Sat, Aug 25, 2012 at 09:54:25AM -0600, Aaron Bieber wrote:
  I never intended to imply that -P had anything to do with creation.  I
  simply meant that you would have to run bioctl with the -P option twice,
  once for each partition when changing your passphrase.
 
 Does that imply that one may change the passphrase to be the same on all
 machines? Hence solving my question?
 

Yes, you could use the same passphrase for different softraid volumes on
different machines.