Re: NEW: htop 2.0.0

[Juan Francisco Cantero Hurtado]

On Mon, Feb 15, 2016 at 09:47:54PM +, Pedro de Oliveira wrote:
> Hi again,
> 
> Here is an updated version, with two patches from github, it now also
> passes portcheck.
> I believe that in the next version both patches will already be in upstream.
> 
> https://github.com/hishamhm/htop/pull/398
> https://github.com/hishamhm/htop/pull/376

I've attached an updated version of your port. You forgot to
double-check some parts :)

> 
> On Sun, Feb 14, 2016 at 10:08 PM, Juan Francisco Cantero Hurtado
>  wrote:
> > On Thu, Feb 11, 2016 at 08:53:42PM -0500, Michael McConville wrote:
> >> Pedro de Oliveira wrote:
> >> > Hi,
> >> >
> >> > Attached is a new port for sysutils/htop.The new 2.0.0 release now
> >> > supports OpenBSD.
> >> > It's my first port, so be easy!
> >> >
> >> > Any comments? OK to import?
> >> >
> >> > Regards,
> >> > Pedro de Oliveira
> >>
> >> Hi, Pedro.
> >>
> >> I wrote the OpenBSD-specific htop code. I was planning on making a
> >> proper port ASAP; thanks for beating me to it!  :-)  I'll try to review
> >> it this weekend.
> >>
> >> It's too late to get it into 5.9, sadly. This gives us more time to
> >> improve the OS-specific code, though.
> >>
> >> If you want to help with that, you could review and test this patch by
> >> juanfra@:
> >>
> >> https://github.com/hishamhm/htop/pull/376
> >
> > I've seeing a bunch of double-free and use-after-free in htop. Please,
> > run your tests with "MALLOC_OPTIONS=CFGJU htop" and fix the code
> > yourself in the upstream github repo if you can.


-- 
Juan Francisco Cantero Hurtado http://juanfra.info


htop.tgz
Description: GNU Unix tar archive

Re: prosody with mysql clarification

[Henrik Friedrichsen]

There is definitely a bug here, but I don't think it is a prosody
problem.

I did some digging:

lua51 -e 'for _,v in ipairs(require"DBI".Drivers()) do print(v) end'

Should list the MySQL driver when installed, but only lists SQLite3 on
my CURRENT machine.

As you can see below loading the dbdmysql library un an interactive Lua prompt
with linker debugging set results in an error when trying to load
libmysqlclient.so.27.0 which loads lpthread. This is a little odd, because it
loads fine in ldd.. Stuart, any ideas what could cause this?

> require('dbdmysql')
dlopen: loading: /usr/local/lib/lua/5.1/dbdmysql.so
 flags /usr/local/lib/lua/5.1/dbdmysql.so = 0x0
head /usr/local/lib/lua/5.1/dbdmysql.so
obj /usr/local/lib/lua/5.1/dbdmysql.so has /usr/local/lib/lua/5.1/dbdmysql.so 
as head
linking /usr/local/lib/lua/5.1/dbdmysql.so as dlopen()ed
head [/usr/local/lib/lua/5.1/dbdmysql.so]
examining: '/usr/local/lib/lua/5.1/dbdmysql.so'
loading: libmysqlclient.so.27.0 required by /usr/local/lib/lua/5.1/dbdmysql.so
 flags /usr/local/lib/libmysqlclient.so.27.0 = 0x0
obj /usr/local/lib/libmysqlclient.so.27.0 has 
/usr/local/lib/lua/5.1/dbdmysql.so as head
linking dep /usr/local/lib/libmysqlclient.so.27.0 as child of 
/usr/local/lib/lua/5.1/dbdmysql.so
examining: '/usr/local/lib/libmysqlclient.so.27.0'
loading: libstdc++.so.57.0 required by /usr/local/lib/libmysqlclient.so.27.0
 flags /usr/lib/libstdc++.so.57.0 = 0x0
obj /usr/lib/libstdc++.so.57.0 has /usr/local/lib/lua/5.1/dbdmysql.so as head
loading: libssl.so.38.0 required by /usr/local/lib/libmysqlclient.so.27.0
 flags /usr/lib/libssl.so.38.0 = 0x0
obj /usr/lib/libssl.so.38.0 has /usr/local/lib/lua/5.1/dbdmysql.so as head
loading: libz.so.5.0 required by /usr/local/lib/libmysqlclient.so.27.0
 flags /usr/lib/libz.so.5.0 = 0x0
obj /usr/lib/libz.so.5.0 has /usr/local/lib/lua/5.1/dbdmysql.so as head
loading: libm.so.9.0 required by /usr/local/lib/libmysqlclient.so.27.0
loading: libpthread.so.20.1 required by /usr/local/lib/libmysqlclient.so.27.0
 flags /usr/lib/libpthread.so.20.1 = 0x68
dlopen: failed to open libpthread.so.20.1
unload_shlib called on /usr/local/lib/lua/5.1/dbdmysql.so
unload_shlib called on /usr/local/lib/libmysqlclient.so.27.0
unload_shlib unloading on /usr/local/lib/libmysqlclient.so.27.0
unload_shlib unloading on /usr/local/lib/lua/5.1/dbdmysql.so
dlopen: /usr/local/lib/lua/5.1/dbdmysql.so: done (failed).
error loading module 'dbdmysql' from file '/usr/local/lib/lua/5.1/dbdmysql.so':
Cannot load specified object
stack traceback:
[C]: ?
[C]: in function 'require'
stdin:1: in main chunk
[C]: ?

Re: fix: devel/boost

[Tobias Ulmer]

On Mon, Feb 15, 2016 at 08:51:34PM +, Christian Weisgerber wrote:
> On 2016-02-15, Tobias Ulmer  wrote:
> 
> > +padding for 32bit strict alignment archs
> > +
> > +--- tools/build/src/engine/hash.c.orig Mon Feb 15 20:11:07 2016
> >  tools/build/src/engine/hash.c  Mon Feb 15 20:22:03 2016
> > +@@ -33,6 +33,7 @@ typedef struct item ITEM;
> > + struct item
> > + {
> > + ITEM * next;
> > ++char padding[sizeof(long long)-sizeof(ITEM *)];
> > + };
> 
> Urgh.  sparc, as a 32-bit arch, enforces 64-bit alignment for 64-bit
> data types?

Yes, LDD and STD 'trap if the address is not doubleword-aligned' to
quote the SPARCv8 manual.

> 
> -- 
> Christian "naddy" Weisgerber  na...@mips.inka.de
> 

Re: NEW: htop 2.0.0

[Pedro de Oliveira]

Hi again,

Here is an updated version, with two patches from github, it now also
passes portcheck.
I believe that in the next version both patches will already be in upstream.

https://github.com/hishamhm/htop/pull/398
https://github.com/hishamhm/htop/pull/376

On Sun, Feb 14, 2016 at 10:08 PM, Juan Francisco Cantero Hurtado
 wrote:
> On Thu, Feb 11, 2016 at 08:53:42PM -0500, Michael McConville wrote:
>> Pedro de Oliveira wrote:
>> > Hi,
>> >
>> > Attached is a new port for sysutils/htop.The new 2.0.0 release now
>> > supports OpenBSD.
>> > It's my first port, so be easy!
>> >
>> > Any comments? OK to import?
>> >
>> > Regards,
>> > Pedro de Oliveira
>>
>> Hi, Pedro.
>>
>> I wrote the OpenBSD-specific htop code. I was planning on making a
>> proper port ASAP; thanks for beating me to it!  :-)  I'll try to review
>> it this weekend.
>>
>> It's too late to get it into 5.9, sadly. This gives us more time to
>> improve the OS-specific code, though.
>>
>> If you want to help with that, you could review and test this patch by
>> juanfra@:
>>
>> https://github.com/hishamhm/htop/pull/376
>
> I've seeing a bunch of double-free and use-after-free in htop. Please,
> run your tests with "MALLOC_OPTIONS=CFGJU htop" and fix the code
> yourself in the upstream github repo if you can.
>
> --
> Juan Francisco Cantero Hurtado http://juanfra.info
>


htop.tgz
Description: GNU Zip compressed data

Re: [PATCH] duplicity restore pexpect as default ssh backend

[trondd]

On Mon, February 15, 2016 7:17 am, Jérémie Courrèges-Anglas wrote:
>
> We should fix the current situation one way of the other.  duplicity
> users on OpenBSD should speak up.  Does the default ssh backend,
> paramiko, prevent you from easily using duplicity on OpenBSD-current?
> Looks like paramiko can now use the default sshd config.
>

I don't know what used to be broken with paramiko.  I ran through basic
usage with the paramiko backend.  I can do full and incremental backups,
restore files, get the file list, collection status, and verify
collections.  The only thing it can't do is use ed25519 keys[0].  RSA
works fine.

Tim.

[0] https://github.com/paramiko/paramiko/issues/325

Re: fix: devel/boost

[Christian Weisgerber]

On 2016-02-15, Tobias Ulmer  wrote:

> +padding for 32bit strict alignment archs
> +
> +--- tools/build/src/engine/hash.c.orig   Mon Feb 15 20:11:07 2016
>  tools/build/src/engine/hash.cMon Feb 15 20:22:03 2016
> +@@ -33,6 +33,7 @@ typedef struct item ITEM;
> + struct item
> + {
> + ITEM * next;
> ++char padding[sizeof(long long)-sizeof(ITEM *)];
> + };

Urgh.  sparc, as a 32-bit arch, enforces 64-bit alignment for 64-bit
data types?

-- 
Christian "naddy" Weisgerber  na...@mips.inka.de

Re: NEW: www/tbb - Tor Browser Bundle

[Landry Breuil]

On Mon, Feb 15, 2016 at 10:54:26AM -0600, attila wrote:
>  
> Landry Breuil  writes:
> 
> > On Mon, Feb 08, 2016 at 02:53:16PM -0600, attila wrote:
> >> 
> >> Landry Breuil  writes:
> >
> > 
> >
> >> > Have you tried leaving the .xpi files compressed in their respective
> >> > dirs at runtime (eventually unzipping/patching/rezipping) as you comment
> >> > in Makefile.inc line 68 ? Iirc this should also work and is 'nicer' to
> >> > the filesystem..
> >> 
> >> I finally just grokked in fullness what you were saying here (sorry, a
> >> bit slow).  Given that I already have a start-tor-browser shell script
> >> in place to set things up we could instead switch to having .xpi files
> >> in distribution/extensions (or wherever) and unpack them when
> >> ~/.tor-browser is populated.  I'm sorry I didn't get to it before now,
> >> maybe the rest of what I've done can be critiqued and I'll make this
> >> change and test it when I get my buildbox back.
> >
> > Fwiw, in TB 45 (and, i suppose, FX 45 but ours doesnt ship default
> > extensions) the bundled xpi's stay installed as xpi, and that works just
> > fine. There should be no need to unpack them in /usr/local, nor in the
> > user profile - if i got it right, you copy those extensions to the user
> > profile ? why ?
> >
> 
> I'm sorry for not responding sooner.  The short summary of what we've
> found from testing/debugging over the last few days (on amd64 only
> sadly):
> 
> 1. extension-overrides.js only works if you drop it into the user's
>profiledir (~/.tor-browser/profile.default/preferences).  I belive
>this has to do with the order in which things happen at startup;
> 2. The four addons in www/tbb must be in the user's profiledir or they
>won't be loaded (~/.tor-browser/profile.default/extensions).  It
>just doesn't work from anywhere under /usr/local/lib/tor-browser-5.5
>that I could find;
> 3. I was confused and not naming the .xpi files with the appid, e.g.
>https-everywhere-...@eff.org.xpi.  This is why I was convinced that
>.xpi files weren't working - they do indeed work as you said once
>you name them properly, but only in the user's profdir.
> 
> Attached are updated ports that rework the way the extensions are
> packaged.  They now drop .xpi files into
> /usr/local/tor-browser-5.5/distribution/extensions, as you asked.  The
> start-tor-browser script copies them as before, but just .xpi files
> not whole directory trees.  I've also ditched the idea of bothering to
> build the https-everywhere .xpi and am grabbing the official one like
> I do for noscript.  All of a sudden this is a lot easier to maintain.
> Don't know what I was thinking.

You shouldnt need to copy the xpi's to the user profile, there are ways
via tweaks to make it work.

I did the experiment with firefox 45 beta, with a profile named 'Empty'
i keep around :

sudo mkdir -p /usr/local/lib/firefox-45.0/distribution/extensions
ftp  https://www.eff.org/files/https-everywhere-5.1.0.xpi
sudo mv https-everywhere-5.1.0.xpi 
/usr/local/lib/firefox-45.0/distribution/extensions/https-everywhere-...@eff.org.xpi
firefox -P empty
-> i get the httpse banner, and the xpi was copied by firefox itself
into the profile:

8964577 -rw-r--r--  1 landry  landry  2524860 Feb 15 20:55 
/home/landry/.mozilla/firefox/3dz8yo5i.Empty/extensions/https-everywhere-...@eff.org.xpi
2443106 -rw-r--r--  1 landry  wheel   2524860 Feb 15 20:54 
/usr/local/lib/firefox-45.0/distribution/extensions/https-everywhere-...@eff.org.xpi

In thunderbird, it looks a bit different, since you can ship systemwide
addons that are not copied into the user profile (that's how lightning
works), you just have them under
/usr/local/lib/thunderbird-45.0/extensions/. Lightning is a bit special
since it has a library (.so file) so it cant stay packed as an xpi
otherwise it would fail at runtime, but other than that other addons
just work, and they're *not* copied to the user's profile, which just
gets the ones installed by the user from the UI.

I tried the same thing in firefox (ie putting
https-everywhere-...@eff.org.xpi in
/usr/local/lib/firefox-45.0/extensions/) but it failed, originally i
thought just because extensions.autoDisableScopes is at its default
(15). Tried setting it to 3 (like it's done for thunderbird via a
systemwide pref file, see
/usr/ports/mail/mozilla-thunderbird/files/all-openbsd.js) but it still
failed. Pretty sure there's a way to do it, or this has been hardened to
avoid malware tampering with firefox installs..

Of course, all this is documented in
https://developer.mozilla.org/en-US/Add-ons/Installing_extensions and
explained in
https://mike.kaply.com/2012/02/21/understanding-add-on-scopes/

Landry

fix: devel/boost

[Tobias Ulmer]

Fix 'jam' so it doesn't crash immediately on sparc.

While debugging I found file_query wasn't declared, which is nice since
it returns a pointer. Surprised this works at all on 64 bit machines,
I'm guessing it's because of -O0.

More sparc fixes may be coming, or I may mark the thing as BROKEN, we
shall see. I'm just putting it out there so you can see what's cooking.

diff --git a/devel/boost/Makefile b/devel/boost/Makefile
index 5f69adb..6f04d78 100644
--- a/devel/boost/Makefile
+++ b/devel/boost/Makefile
@@ -5,7 +5,7 @@ ONLY_FOR_ARCHS= ${GCC4_ARCHS}
 COMMENT=   free peer-reviewed portable C++ source libraries
 
 VERSION=   1.58.0
-REVISION=  0
+REVISION=  1
 DISTNAME=  boost_${VERSION:S/./_/g}
 PKGNAME=   boost-${VERSION}
 CATEGORIES=devel
diff --git a/devel/boost/patches/patch-tools_build_src_engine_hash_c 
b/devel/boost/patches/patch-tools_build_src_engine_hash_c
new file mode 100644
index 000..ea923e1
--- /dev/null
+++ b/devel/boost/patches/patch-tools_build_src_engine_hash_c
@@ -0,0 +1,14 @@
+$OpenBSD$
+
+padding for 32bit strict alignment archs
+
+--- tools/build/src/engine/hash.c.orig Mon Feb 15 20:11:07 2016
 tools/build/src/engine/hash.c  Mon Feb 15 20:22:03 2016
+@@ -33,6 +33,7 @@ typedef struct item ITEM;
+ struct item
+ {
+ ITEM * next;
++char padding[sizeof(long long)-sizeof(ITEM *)];
+ };
+ 
+ #define MAX_LISTS 32
diff --git a/devel/boost/patches/patch-tools_build_src_engine_modules_path_c 
b/devel/boost/patches/patch-tools_build_src_engine_modules_path_c
new file mode 100644
index 000..4a9a952
--- /dev/null
+++ b/devel/boost/patches/patch-tools_build_src_engine_modules_path_c
@@ -0,0 +1,14 @@
+$OpenBSD$
+
+fix implicit declaration of function 'file_query' for LP64 archs
+
+--- tools/build/src/engine/modules/path.c.orig Mon Feb 15 19:25:09 2016
 tools/build/src/engine/modules/path.c  Mon Feb 15 19:25:34 2016
+@@ -6,6 +6,7 @@
+ 
+ #include "../constants.h"
+ #include "../frames.h"
++#include "../filesys.h"
+ #include "../lists.h"
+ #include "../native.h"
+ #include "../timestamp.h"

CVS: cvs.openbsd.org: ports

[Robert Nagy]

CVSROOT:/cvs
Module name:ports
Changes by: rob...@cvs.openbsd.org  2016/02/15 11:09:04

Modified files:
www/iridium: Makefile 

Log message:
oops i accidentally disabled the pre-build targets, let's re-enable them

CVS: cvs.openbsd.org: ports

[Robert Nagy]

CVSROOT:/cvs
Module name:ports
Changes by: rob...@cvs.openbsd.org  2016/02/15 11:07:53

Modified files:
www/iridium: Makefile distinfo 
www/iridium/patches: patch-base_base_gypi 
 patch-base_debug_stack_trace_posix_cc 
 patch-base_process_memory_cc 
 patch-base_process_process_metrics_h 
 patch-base_process_process_posix_cc 
 patch-base_strings_safe_sprintf_cc 
 patch-build_all_gyp patch-build_common_gypi 
 patch-chrome_app_chrome_main_cc 
 patch-chrome_app_chrome_main_delegate_cc 
 patch-chrome_app_chromium_strings_grd 
 patch-chrome_app_google_chrome_strings_grd 
 patch-chrome_app_theme_theme_resources_grd 
 patch-chrome_browser_about_flags_cc 
 patch-chrome_browser_browser_resources_grd 
 patch-chrome_browser_chrome_browser_main_cc 
 patch-chrome_browser_chrome_browser_main_linux_cc 
 
patch-chrome_browser_chrome_content_browser_client_cc 
 
patch-chrome_browser_chrome_content_browser_client_h 
 
patch-chrome_browser_download_chrome_download_manager_delegate_cc 
 
patch-chrome_browser_extensions_bookmark_app_helper_cc 
 
patch-chrome_browser_first_run_first_run_internal_posix_cc 
 patch-chrome_browser_memory_details_cc 
 
patch-chrome_browser_notifications_message_center_notification_manager_cc 
 patch-chrome_browser_renderer_preferences_util_cc 
 
patch-chrome_browser_resources_plugin_metadata_plugins_linux_json 
 
patch-chrome_browser_safe_browsing_incident_reporting_incident_reporting_service_cc
 
 
patch-chrome_browser_ssl_bad_clock_blocking_page_cc 
 
patch-chrome_browser_sync_profile_sync_components_factory_impl_cc 
 patch-chrome_browser_task_manager_task_manager_cc 
 
patch-chrome_browser_ui_aura_chrome_browser_main_extra_parts_aura_cc 
 
patch-chrome_browser_ui_browser_command_controller_cc 
 
patch-chrome_browser_ui_startup_bad_flags_prompt_cc 
 patch-chrome_browser_ui_views_accelerator_table_cc 
 
patch-chrome_browser_ui_views_exclusive_access_bubble_views_cc 
 patch-chrome_browser_ui_views_first_run_dialog_cc 
 
patch-chrome_browser_ui_views_frame_opaque_browser_frame_view_cc 
 
patch-chrome_browser_ui_views_frame_system_menu_model_builder_cc 
 
patch-chrome_browser_ui_views_tabs_tab_drag_controller_cc 
 patch-chrome_browser_ui_views_tabs_tab_strip_cc 
 
patch-chrome_browser_ui_webui_chrome_web_ui_controller_factory_cc 
 
patch-chrome_browser_ui_webui_options_browser_options_handler_cc 
 
patch-chrome_browser_ui_webui_options_browser_options_handler_h 
 patch-chrome_browser_web_applications_web_app_cc 
 patch-chrome_chrome_browser_extensions_gypi 
 patch-chrome_chrome_browser_gypi 
 patch-chrome_chrome_browser_ui_gypi 
 patch-chrome_chrome_common_gypi 
 patch-chrome_chrome_exe_gypi 
 patch-chrome_common_chrome_paths_h 
 patch-chrome_common_chrome_switches_cc 
 patch-chrome_common_chrome_switches_h 
 patch-chrome_common_extensions_api_schemas_gypi 
 patch-chrome_common_pref_names_cc 
 patch-chrome_common_pref_names_h 
 patch-chrome_common_url_constants_cc 
 patch-chrome_common_url_constants_h 
 patch-chrome_renderer_resources_neterror_js 
 
patch-components_policy_resources_policy_templates_json 
 
patch-components_policy_tools_generate_policy_source_py 
 patch-content_app_content_main_runner_cc 
 
patch-content_browser_accessibility_browser_accessibility_h 
 

Re: emacs-25.0.91 (pretest)

[Jérémie Courrèges-Anglas]

Stuart Henderson  writes:

> On 2016/02/15 13:05, Jérémie Courrèges-Anglas wrote:
>> If someone knows what the hell the alien C syntax in
>> patches/patch-src_fns_c is about, cluebat welcome.
>
> it's C99:
>
> https://en.wikipedia.org/wiki/Restrict

I've heard about restrict, but I had indeed never seen it used within
the brackets of array parameters.  emacs is built with -std=gnu99:

cc -std=gnu99 -c -I/usr/local/include -Demacs  -I. -I. -I../lib -I../lib
 -I/usr/local/include/libxml2 -I/usr/local/include
 -MMD -MF deps/fns.d -MP -I/usr/local/include -I/usr/local/include/p11-kit-1
 -I/usr/include -O2 -pipe -fno-pie  fns.c
fns.c:36: error: static or type qualifiers in abstract declarator
fns.c:36: error: static or type qualifiers in abstract declarator
fns.c: In function 'sort_vector':
[...]

Sadly:
-> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=14050
 -> https://gcc.gnu.org/viewcvs/gcc?view=revision=130362
  -> GPLv3

*shrug*

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

Re: NEW: www/tbb - Tor Browser Bundle

[attila]

 
Landry Breuil  writes:

> On Mon, Feb 08, 2016 at 02:53:16PM -0600, attila wrote:
>> 
>> Landry Breuil  writes:
>
> 
>
>> > Have you tried leaving the .xpi files compressed in their respective
>> > dirs at runtime (eventually unzipping/patching/rezipping) as you comment
>> > in Makefile.inc line 68 ? Iirc this should also work and is 'nicer' to
>> > the filesystem..
>> 
>> I finally just grokked in fullness what you were saying here (sorry, a
>> bit slow).  Given that I already have a start-tor-browser shell script
>> in place to set things up we could instead switch to having .xpi files
>> in distribution/extensions (or wherever) and unpack them when
>> ~/.tor-browser is populated.  I'm sorry I didn't get to it before now,
>> maybe the rest of what I've done can be critiqued and I'll make this
>> change and test it when I get my buildbox back.
>
> Fwiw, in TB 45 (and, i suppose, FX 45 but ours doesnt ship default
> extensions) the bundled xpi's stay installed as xpi, and that works just
> fine. There should be no need to unpack them in /usr/local, nor in the
> user profile - if i got it right, you copy those extensions to the user
> profile ? why ?
>

I'm sorry for not responding sooner.  The short summary of what we've
found from testing/debugging over the last few days (on amd64 only
sadly):

1. extension-overrides.js only works if you drop it into the user's
   profiledir (~/.tor-browser/profile.default/preferences).  I belive
   this has to do with the order in which things happen at startup;
2. The four addons in www/tbb must be in the user's profiledir or they
   won't be loaded (~/.tor-browser/profile.default/extensions).  It
   just doesn't work from anywhere under /usr/local/lib/tor-browser-5.5
   that I could find;
3. I was confused and not naming the .xpi files with the appid, e.g.
   https-everywhere-...@eff.org.xpi.  This is why I was convinced that
   .xpi files weren't working - they do indeed work as you said once
   you name them properly, but only in the user's profdir.

Attached are updated ports that rework the way the extensions are
packaged.  They now drop .xpi files into
/usr/local/tor-browser-5.5/distribution/extensions, as you asked.  The
start-tor-browser script copies them as before, but just .xpi files
not whole directory trees.  I've also ditched the idea of bothering to
build the https-everywhere .xpi and am grabbing the official one like
I do for noscript.  All of a sudden this is a lot easier to maintain.
Don't know what I was thinking.

I realize ports lock is in effect so this can't make it in but I
wanted to respond to get some closure on what we have so far.  The
packages we put up for testing have been updated:

http://mirrors.nycbug.org/pub/snapshots/packages/amd64/README-55.txt

We'll keep them up to date until we (hopefully) don't have to :-)
I'm now moving on to 5.5.2, which includes a major security update
(update to latest ESR to pick up Graphite fix).

Thanks for your help and patience.

> Landry

Pax, -A
--
http://haqistan.net/~attila | att...@stalphonsos.com | 0xE6CC1EDB


tbb-resub2.tgz
Description: updated submission: tor browser ports

Re: pytidylib

[Jiri B]

And now with attachment :)

On Mon, Feb 15, 2016 at 10:44:57AM -0500, Jiri B wrote:
> A python wrapper against libtidy(p).
> 
> Maybe to useful to reconsider after ports unlock.
> 
> $ env LD_DEBUG=1 python2.7 -c "import tidylib" 2>&1 | grep tidy
> dlopen: loading: libtidyp.so
>  flags /usr/local/lib/libtidyp.so.0.0 = 0x0
> head /usr/local/lib/libtidyp.so.0.0
> obj /usr/local/lib/libtidyp.so.0.0 has /usr/local/lib/libtidyp.so.0.0 as head
> linking /usr/local/lib/libtidyp.so.0.0 as dlopen()ed
> head [/usr/local/lib/libtidyp.so.0.0]
> examining: '/usr/local/lib/libtidyp.so.0.0'
> tail /usr/local/lib/libtidyp.so.0.0
> doing ctors obj 0x1e8a91b3ac00 @0x1e8aa134c380: 
> [/usr/local/lib/libtidyp.so.0.0]
> dlopen: libtidyp.so: done (success).
> dlsym: tidyCreate in /usr/local/lib/libtidyp.so.0.0: 0x1e8aa1372360
> doing dtors obj 0x1e8a91b3ac00 @0x1e8aa1372570: 
> [/usr/local/lib/libtidyp.so.0.0]
> 
> And little test (from official doc):
> 
> $ python2.7 -c "from tidylib import tidy_document; doc, errors = 
> tidy_document('''fo ''', 
> options={'numeric-entities':1}); print(doc); print(errors)"
> 
> 
>   
> 
>   
>   
> 
>   fo 
> 
>   
> 
> 
> line 1 column 1 - Warning: missing  declaration
> line 1 column 1 - Warning: inserting implicit 
> line 1 column 1 - Warning: inserting missing 'title' element
> line 1 column 15 - Warning:  lacks "alt" attribute
> 
> j.
> 


pytidylib.tar.gz
Description: application/tar-gz

Re: alpha-1.ports.openbsd.org bulk build report

[Christian Weisgerber]

On 2016-02-14, Matthieu Herrb  wrote:

> I've taken the list of individual optimisation from gcc(1) for both -O1
> and -O2 and replaced -O2 by this in CFLAGS.

gcc-local(1) is also worth a look...

> +O2= ${O1} -fthread-jumps -fcrossjumping \
> + -foptimize-sibling-calls -fcse-follow-jumps -fcse-skip-blocks \
> + -fgcse  -fgcse-lm -fexpensive-optimizations -frerun-cse-after-loop \
> + -fcaller-saves -fpeephole2 -fschedule-insns -fschedule-insns2 \
> + -fsched-interblock  -fsched-spec -fregmove -fstrict-aliasing \
> + -fstrict-overflow -fdelete-null-pointer-checks -freorder-blocks \
> + -freorder-functions -falign-functions -falign-jumps -falign-loops \
> + -falign-labels -ftree-vrp -ftree-pre

Our -O2 does not include -fstrict-aliasing, -fstrict-overflow,
-ftree-vrp.

-- 
Christian "naddy" Weisgerber  na...@mips.inka.de

pytidylib

[Jiri B]

A python wrapper against libtidy(p).

Maybe to useful to reconsider after ports unlock.

$ env LD_DEBUG=1 python2.7 -c "import tidylib" 2>&1 | grep tidy
dlopen: loading: libtidyp.so
 flags /usr/local/lib/libtidyp.so.0.0 = 0x0
head /usr/local/lib/libtidyp.so.0.0
obj /usr/local/lib/libtidyp.so.0.0 has /usr/local/lib/libtidyp.so.0.0 as head
linking /usr/local/lib/libtidyp.so.0.0 as dlopen()ed
head [/usr/local/lib/libtidyp.so.0.0]
examining: '/usr/local/lib/libtidyp.so.0.0'
tail /usr/local/lib/libtidyp.so.0.0
doing ctors obj 0x1e8a91b3ac00 @0x1e8aa134c380: [/usr/local/lib/libtidyp.so.0.0]
dlopen: libtidyp.so: done (success).
dlsym: tidyCreate in /usr/local/lib/libtidyp.so.0.0: 0x1e8aa1372360
doing dtors obj 0x1e8a91b3ac00 @0x1e8aa1372570: [/usr/local/lib/libtidyp.so.0.0]

And little test (from official doc):

$ python2.7 -c "from tidylib import tidy_document; doc, errors = 
tidy_document('''fo ''', 
options={'numeric-entities':1}); print(doc); print(errors)"


  

  
  

  fo 

  


line 1 column 1 - Warning: missing  declaration
line 1 column 1 - Warning: inserting implicit 
line 1 column 1 - Warning: inserting missing 'title' element
line 1 column 15 - Warning:  lacks "alt" attribute

j.

Re: emacs-25.0.91 (pretest)

[Stuart Henderson]

On 2016/02/15 13:05, Jérémie Courrèges-Anglas wrote:
> If someone knows what the hell the alien C syntax in
> patches/patch-src_fns_c is about, cluebat welcome.

it's C99:

https://en.wikipedia.org/wiki/Restrict

Re: [PATCH] duplicity restore pexpect as default ssh backend

[Jérémie Courrèges-Anglas]

"trondd"  writes:

> Bump to get this in for 5.9 so users aren't confused by the changed
> default and the resulting incorrect manpage.
>
> If no one thinks it should go in for 5.9, I'll wait for unlock to poke again.

Thanks for caring about this, Tim.

We should fix the current situation one way of the other.  duplicity
users on OpenBSD should speak up.  Does the default ssh backend,
paramiko, prevent you from easily using duplicity on OpenBSD-current?
Looks like paramiko can now use the default sshd config.

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

CVS: cvs.openbsd.org: ports

[Tobias Ulmer]

CVSROOT:/cvs
Module name:ports
Changes by: tobi...@cvs.openbsd.org 2016/02/15 05:20:33

Modified files:
shells/bash: Makefile 

Log message:
mark broken on sparc, bash segfaults on any non-trivial shellscript and has
done so since at least one release if not more.

Instead of littering the ports the with BROKEN-sparc markers, take out the
real perpetrator.

If someone is looking to improve sparc, debugging this would make all the
difference. textproc/xmlto can serve as a testcase.

CVS: cvs.openbsd.org: ports

[Tobias Ulmer]

CVSROOT:/cvs
Module name:ports
Changes by: tobi...@cvs.openbsd.org 2016/02/15 05:09:03

Modified files:
lang/ruby/2.3  : Makefile 

Log message:
mark broken on sparc, needs more memory to compile than we currently allow

emacs-25.0.91 (pretest)

[Jérémie Courrèges-Anglas]

Hi,

emacs-25.1 will probably be out before the ports will be unlocked.
While we should focus on the current ports tree, I already experiment
breakage in my Gnus setup and I'd prefer to keep the number of new
issues low...

So here's a diff to update to last friday's pretest tarball.  Test
reports welcome, especially with the gtk3 flavor and on !(x86) archs.
Please send the reports in private to keep the noise on ports@ low.

If someone knows what the hell the alien C syntax in
patches/patch-src_fns_c is about, cluebat welcome.

Index: Makefile
===
RCS file: /cvs/ports/editors/emacs/Makefile,v
retrieving revision 1.58
diff -u -p -r1.58 Makefile
--- Makefile6 Nov 2015 20:37:34 -   1.58
+++ Makefile15 Feb 2016 11:51:23 -
@@ -2,8 +2,7 @@
 
 COMMENT=   GNU editor: extensible, customizable, self-documenting
 
-VERSION=   24.5
-REVISION=  2
+VERSION=   25.0.91
 DISTNAME=  emacs-${VERSION}
 
 CATEGORIES=editors
@@ -17,7 +16,8 @@ PERMIT_PACKAGE_CDROM= Yes
 
 WANTLIB=   c m ncurses pthread gnutls xml2 z
 
-MASTER_SITES=  ${MASTER_SITE_GNU:=emacs/}
+MASTER_SITES=  ftp://alpha.gnu.org/gnu/emacs/pretest/
+EXTRACT_SUFX=  .tar.xz
 
 USE_GMAKE= Yes
 
@@ -50,7 +50,7 @@ CONFIGURE_ARGS+=  --without-x \
--without-dbus \
--without-gconf \
--without-gsettings \
-   --without-file-notification
+   --without-jpeg
 .else
 LIB_DEPENDS+=  x11/dbus \
x11/gnome/librsvg \
@@ -66,27 +66,28 @@ RUN_DEPENDS+=   devel/desktop-file-utils 
 . if ${FLAVOR} == "athena"
 CONFIGURE_ARGS+=   --with-x-toolkit=athena
 LIB_DEPENDS+=  x11/Xaw3d
-WANTLIB += ICE MagickCore-6.Q16 MagickWand-6.Q16 SM X11 Xaw3d Xext Xft Xinerama
-WANTLIB += Xmu Xpm Xrandr Xrender Xt cairo dbus-1 fontconfig freetype
-WANTLIB += gconf-2 gdk_pixbuf-2.0 gif gio-2.0 glib-2.0 gobject-2.0
-WANTLIB += jpeg png rsvg-2 tiff
+WANTLIB += ICE MagickCore-6.Q16 MagickWand-6.Q16 SM X11 X11-xcb
+WANTLIB += Xaw3d Xext Xfixes Xft Xinerama Xmu Xpm Xrandr Xrender
+WANTLIB += Xt cairo dbus-1 fontconfig freetype gconf-2 gdk_pixbuf-2.0
+WANTLIB += gif gio-2.0 glib-2.0 gobject-2.0 jpeg png rsvg-2 tiff
+WANTLIB += xcb
 . elif ${FLAVOR} == "gtk2"
 CONFIGURE_ARGS+=   --with-x-toolkit=gtk2
 LIB_DEPENDS+=  x11/gtk+2
-WANTLIB += ICE MagickCore-6.Q16 MagickWand-6.Q16 SM X11 Xcomposite Xcursor
-WANTLIB += Xdamage Xext Xfixes Xft Xi Xinerama Xpm Xrandr Xrender
-WANTLIB += atk-1.0 cairo dbus-1 fontconfig freetype gconf-2 gdk-x11-2.0
-WANTLIB += gdk_pixbuf-2.0 gif gio-2.0 glib-2.0 gobject-2.0 gtk-x11-2.0
-WANTLIB += jpeg pango-1.0 pangocairo-1.0 pangoft2-1.0 png rsvg-2
-WANTLIB += tiff
+WANTLIB += ICE MagickCore-6.Q16 MagickWand-6.Q16 SM X11 X11-xcb
+WANTLIB += Xcomposite Xcursor Xdamage Xext Xfixes Xft Xi Xinerama
+WANTLIB += Xpm Xrandr Xrender atk-1.0 cairo dbus-1 fontconfig
+WANTLIB += freetype gconf-2 gdk-x11-2.0 gdk_pixbuf-2.0 gif gio-2.0
+WANTLIB += glib-2.0 gobject-2.0 gtk-x11-2.0 jpeg pango-1.0 pangocairo-1.0
+WANTLIB += pangoft2-1.0 png rsvg-2 tiff xcb
 . elif ${FLAVOR} == "gtk3"
 CONFIGURE_ARGS+=   --with-x-toolkit=gtk3
 LIB_DEPENDS+=  x11/gtk+3
-WANTLIB += ICE MagickCore-6.Q16 MagickWand-6.Q16 SM X11 Xft Xinerama Xpm Xrandr
-WANTLIB += Xrender atk-1.0 cairo cairo-gobject dbus-1 fontconfig
-WANTLIB += freetype gconf-2 gdk-3 gdk_pixbuf-2.0 gif gio-2.0 glib-2.0
-WANTLIB += gobject-2.0 gtk-3 jpeg pango-1.0 pangocairo-1.0 pangoft2-1.0
-WANTLIB += png rsvg-2 tiff
+WANTLIB += ICE MagickCore-6.Q16 MagickWand-6.Q16 SM X11 X11-xcb
+WANTLIB += Xfixes Xft Xinerama Xpm Xrandr Xrender atk-1.0 cairo
+WANTLIB += cairo-gobject dbus-1 fontconfig freetype gconf-2 gdk-3
+WANTLIB += gdk_pixbuf-2.0 gif gio-2.0 glib-2.0 gobject-2.0 gtk-3
+WANTLIB += jpeg pango-1.0 pangocairo-1.0 png rsvg-2 tiff xcb
 . else
 ERRORS+=   "Fatal: Conflicting flavor: ${FLAVOR}"
 . endif
Index: distinfo
===
RCS file: /cvs/ports/editors/emacs/distinfo,v
retrieving revision 1.7
diff -u -p -r1.7 distinfo
--- distinfo15 Apr 2015 11:35:06 -  1.7
+++ distinfo15 Feb 2016 11:51:23 -
@@ -1,2 +1,2 @@
-SHA256 (emacs-24.5.tar.gz) = JzemYi+y2ZgunEf7by+yl72kJnTgnbQPybzA20KXw7Y=
-SIZE (emacs-24.5.tar.gz) = 59216034
+SHA256 (emacs-25.0.91.tar.xz) = 1369MQ3YyXjhXymvMxhmRpiVNK5IOqisr+aWMkSTAZM=
+SIZE (emacs-25.0.91.tar.xz) = 42253076
Index: patches/patch-Makefile_in
===
RCS file: /cvs/ports/editors/emacs/patches/patch-Makefile_in,v
retrieving revision 1.2
diff -u -p -r1.2 patch-Makefile_in
--- patches/patch-Makefile_in   15 Apr 2015 11:35:06 -  1.2
+++ patches/patch-Makefile_in   15 Feb 2016 11:51:23 

CVS: cvs.openbsd.org: ports

[Tobias Ulmer]

CVSROOT:/cvs
Module name:ports
Changes by: tobi...@cvs.openbsd.org 2016/02/15 05:00:30

Modified files:
audio/openal   : Makefile 

Log message:
mark broken on sparc, missing sync builtins

CVS: cvs.openbsd.org: ports

[Jasper Lievisse Adriaanse]

CVSROOT:/cvs
Module name:ports
Changes by: jas...@cvs.openbsd.org  2016/02/15 04:06:13

Modified files:
emulators/qemu : Tag: OPENBSD_5_8 Makefile 
emulators/qemu/patches: Tag: OPENBSD_5_8 patch-hw_usb_hcd-ehci_c 

Log message:
Security fix for CVE-2016-2198

CVS: cvs.openbsd.org: ports

[Jasper Lievisse Adriaanse]

CVSROOT:/cvs
Module name:ports
Changes by: jas...@cvs.openbsd.org  2016/02/15 03:51:09

Modified files:
www/firefox-esr-i18n: Tag: OPENBSD_5_8 Makefile.inc distinfo 

Log message:
sync for firefox-esr-38.6.1

CVS: cvs.openbsd.org: ports

[Jasper Lievisse Adriaanse]

CVSROOT:/cvs
Module name:ports
Changes by: jas...@cvs.openbsd.org  2016/02/15 03:50:54

Modified files:
www/firefox-esr: Tag: OPENBSD_5_8 Makefile distinfo 

Log message:
- update to firefox-esr-38.6.1
https://www.mozilla.org/en-US/firefox/38.6.1/releasenotes/

CVS: cvs.openbsd.org: ports

[Jasper Lievisse Adriaanse]

CVSROOT:/cvs
Module name:ports
Changes by: jas...@cvs.openbsd.org  2016/02/15 02:03:12

Modified files:
x11/gnome/eog  : Makefile distinfo 

Log message:
security update to eog-3.18.2 addressing CVE-2013-7447

CVS: cvs.openbsd.org: ports

[Jasper Lievisse Adriaanse]

CVSROOT:/cvs
Module name:ports
Changes by: jas...@cvs.openbsd.org  2016/02/15 01:40:37

Modified files:
x11/gnome/eog  : Tag: OPENBSD_5_8 Makefile 
Added files:
x11/gnome/eog/patches: Tag: OPENBSD_5_8 
   patch-src_eog-print-preview_c 

Log message:
Security fix for CVE-2013-7447