CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: lan...@cvs.openbsd.org 2014/05/18 03:11:57 ports/geo/mapserver/files Update of /cvs/ports/geo/mapserver/files In directory cvs.openbsd.org:/tmp/cvs-serv6135/files Log Message: Directory /cvs/ports/geo/mapserver/files added to the repository
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: lan...@cvs.openbsd.org 2014/05/18 03:29:50 Modified files: geo/mapserver : Makefile distinfo geo/mapserver/patches: patch-CMakeLists_txt geo/mapserver/pkg: PLIST-main README-main README-php Added files: geo/mapserver/pkg: mapserv.rc Log message: Bugfix update to mapserver 6.4.1. Adapt README's for nginx, and provide an rc script using spawn-fcgi.
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: s...@cvs.openbsd.org2014/05/18 05:22:01 Modified files: meta/xfce : Makefile meta/xfce/pkg : README-main Log message: Make xfce depend on gtk3-xfce-engine since gtk3 applications look horrid without it. While here, recommend sysutils/toad instead of hotplugd(8) for auto-mount in xfce's README. toad just works, without additional scripting. ok landry
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: ajacou...@cvs.openbsd.org 2014/05/18 09:33:01 Modified files: textproc/meld : Makefile distinfo Log message: Update to meld-1.8.5.
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: pas...@cvs.openbsd.org 2014/05/18 09:33:16 Modified files: net/tor: Makefile distinfo Log message: Update to tor 0.2.4.22.
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: jer...@cvs.openbsd.org 2014/05/18 09:43:54 Modified files: lang/jruby : Makefile distinfo lang/jruby/pkg : PLIST Log message: Update to JRuby 1.7.12.
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: jer...@cvs.openbsd.org 2014/05/18 09:49:46 Modified files: lang/rubinius : Makefile distinfo lang/rubinius/pkg: PLIST Removed files: lang/rubinius/patches: fileutils.diff Log message: Update to rubinius 2.2.6. No longer have a BDEP on llvm unless llvm is used. Remove the FileUtils.mkdir_p patch, as it doesn't work correctly in this version.
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: bl...@cvs.openbsd.org 2014/05/18 15:25:15 Modified files: net/p5-Event-RPC: Makefile distinfo net/p5-Event-RPC/pkg: PLIST Log message: - update p5-Event-RPC to 1.05 - no USE_GROFF OK gsoares@
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: bl...@cvs.openbsd.org 2014/05/18 17:01:59 Modified files: security/p5-IO-Socket-SSL: Makefile distinfo Log message: update p5-IO-Socket-SSL to 1.988
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: bcal...@cvs.openbsd.org 2014/05/18 17:31:14 Modified files: lang/seed7 : Makefile distinfo Log message: Update to 20140518.
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: z...@cvs.openbsd.org2014/05/18 18:57:54 Modified files: infrastructure/bin: portcheck Log message: Check for leading articles in COMMENT lines. Suggested by sebastia@.
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: z...@cvs.openbsd.org2014/05/18 18:58:53 Log message: Import tests for leading articles in the COMMENT lines. Status: Vendor Tag: zhuk Release Tags: zhuk_20140519 N ports/tests/portcheck/t13/Makefile N ports/tests/portcheck/t13/pkg/PLIST-a N ports/tests/portcheck/t13/pkg/PLIST-an N ports/tests/portcheck/t13/pkg/PLIST-athe N ports/tests/portcheck/t13/pkg/PLIST-main N ports/tests/portcheck/t13/pkg/PLIST-the No conflicts created by this import
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: z...@cvs.openbsd.org2014/05/18 18:59:30 Modified files: tests/portcheck: Makefile Added files: tests/portcheck: t13.sample Log message: Hook up new tests.
Re: opendnssec and softhsm revisited
On Wed, May 07, 2014 at 10:57:50PM +0200, Patrik Lundin wrote: The opendnssec port is a work in progress. The most annoying thing while building currently is the warnings regarding comma at end of enumerator list which seems to be the result of inconsistent use of -std=c99 which i am not sure how to solve properly. Trying to figure out what is the best course of action to remove these warnings I am first of all trying to figure out why they are thrown on OpenBSD but not on a Ubuntu 14.04 system that I use for comparision. It seems to me it comes down to some sort of special handling of included headers on the Ubuntu box that I do not see on OpenBSD. Basically i see this: On OpenBSD using the system include syntax: # echo '#include ldns/error.h' test.c # cc -I/usr/local/include -pedantic -Wall -Wextra -c test.c In file included from test.c:1: /usr/local/include/ldns/error.h:130: warning: comma at end of enumerator list On OpenBSD including the file directly: # echo '#include /usr/local/include/ldns/error.h' test.c # cc -I/usr/local/include -pedantic -Wall -Wextra -c test.c In file included from test.c:1: /usr/local/include/ldns/error.h:130: warning: comma at end of enumerator list These are consistent. However, when looking at what happens on Ubuntu: ... Using system include syntax makes it quiet: # echo '#include ldns/error.h' test.c # cc -pedantic -Wall -Wextra -c test.c ... while including the file directly causes a warning: # echo '#include /usr/include/ldns/error.h' test.c # cc -pedantic -Wall -Wextra -c test.c In file included from test.c:1:0: /usr/include/ldns/error.h:129:28: warning: comma at end of enumerator list [-Wpedantic] LDNS_STATUS_RDATA_OVERFLOW, ^ I'm guessing this is the reason it is not spotted as easily on Linux. What I wonder is if anyone here has struggled with a similar problem and if there is a good solution for it. Regards, Patrik Lundin
Re: opendnssec and softhsm revisited
This is due to differences between C compilers. gcc 4.8 and clang don't warn for this with -pedantic, gcc 4.2.1 does. I think -pedantic is fairly pointless in ports and should be removed, but I would also report it to nlnetlabs as an ldns bug, I think the best approach would be to remove the surplus , for better compiler compatibility (and their other enums don't have a trailing ,). https://www.nlnetlabs.nl/bugs-script/buglist.cgi?product=ldnsbug_status=NEWbug_status=ASSIGNEDbug_status=REOPENEDcmdtype=doit $ for i in clang egcc cc; do echo = $i; $i --version | head -1; $i -I /usr/local/include -pedantic -Wall -Wextra -c test = clang clang version 3.5 (trunk) = egcc egcc (GCC) 4.8.2 = cc cc (GCC) 4.2.1 20070719 In file included from test.c:1: /usr/local/include/ldns/error.h:130: warning: comma at end of enumerator list On 2014/05/18 11:43, Patrik Lundin wrote: On Wed, May 07, 2014 at 10:57:50PM +0200, Patrik Lundin wrote: The opendnssec port is a work in progress. The most annoying thing while building currently is the warnings regarding comma at end of enumerator list which seems to be the result of inconsistent use of -std=c99 which i am not sure how to solve properly. Trying to figure out what is the best course of action to remove these warnings I am first of all trying to figure out why they are thrown on OpenBSD but not on a Ubuntu 14.04 system that I use for comparision. It seems to me it comes down to some sort of special handling of included headers on the Ubuntu box that I do not see on OpenBSD. Basically i see this: On OpenBSD using the system include syntax: # echo '#include ldns/error.h' test.c # cc -I/usr/local/include -pedantic -Wall -Wextra -c test.c In file included from test.c:1: /usr/local/include/ldns/error.h:130: warning: comma at end of enumerator list On OpenBSD including the file directly: # echo '#include /usr/local/include/ldns/error.h' test.c # cc -I/usr/local/include -pedantic -Wall -Wextra -c test.c In file included from test.c:1: /usr/local/include/ldns/error.h:130: warning: comma at end of enumerator list These are consistent. However, when looking at what happens on Ubuntu: ... Using system include syntax makes it quiet: # echo '#include ldns/error.h' test.c # cc -pedantic -Wall -Wextra -c test.c ... while including the file directly causes a warning: # echo '#include /usr/include/ldns/error.h' test.c # cc -pedantic -Wall -Wextra -c test.c In file included from test.c:1:0: /usr/include/ldns/error.h:129:28: warning: comma at end of enumerator list [-Wpedantic] LDNS_STATUS_RDATA_OVERFLOW, ^ I'm guessing this is the reason it is not spotted as easily on Linux. What I wonder is if anyone here has struggled with a similar problem and if there is a good solution for it. Regards, Patrik Lundin
PATCH: sysutils/upower - expose capacity and energy-full-design properties
Hi,
the patch below will expose two more properties through upower.
The porperties are EnergyFullDesign and Capacity
From Upower Documentation:
'EnergyFullDesign' read 'd'
Amount of energy (measured in Wh) the power source is
designed to hold when it's considered full. This property is
only valid if the property type has the value battery.
'Capacity' read 'd'
The capacity of the power source expressed as a percentage
between 0 and 100. The capacity of the battery will reduce with
age. A capacity value less than 75% is usually a sign that you
should renew your battery. Typically this value is the same
as (full-design / full) * 100. However, some primitive power
sources are not capable reporting capacity and in this
case the capacity property will be unset.
This property is only valid if the property type has the value battery.
With capacity exposed through upower, it will silence a wrong notification
about a broken battery KDE4. KDE4 sees a capacity of 0 which is probably a
bug in KDE4 but i would prefer enhancing our UPower Backend instead of
patching KDE4.
Vadim added a note in this commit about the problem.
http://marc.info/?l=openbsd-ports-cvsm=139885033417756w=2
Note: You must apply the acpibat patch from here before this one.
http://marc.info/?l=openbsd-techm=140034438528555w=2
Regards,
Fabian
$ upower -d
Device: /org/freedesktop/UPower/devices/line_power_ac
native-path: /ac
power supply: yes
updated: Sun May 18 12:41:38 2014 (1199 seconds ago)
has history: no
has statistics: no
line-power
warning-level: unknown
online: yes
icon-name: 'ac-adapter-symbolic'
Device: /org/freedesktop/UPower/devices/battery_batt
native-path: /batt
power supply: yes
updated: Sun May 18 12:41:38 2014 (1199 seconds ago)
has history: yes
has statistics: no
battery
present: yes
rechargeable:yes
state: fully-charged
warning-level: none
energy: 47.36 Wh
energy-empty:1.669 Wh
energy-full: 47.78 Wh
energy-full-design: 62.16 Wh -- NEW
energy-rate: 0 W
voltage: 12.75 V
percentage: 99%
capacity:76.8662% -- NEW
icon-name: 'battery-full-charged-symbolic'
Device: /org/freedesktop/UPower/devices/DisplayDevice
power supply: yes
updated: Thu Jan 1 01:00:00 1970 (1400410897 seconds ago)
has history: no
has statistics: no
battery
present: yes
state: fully-charged
warning-level: none
energy: 47.36 Wh
energy-full: 47.78 Wh
energy-rate: 0 W
percentage: 99%
icon-name: 'battery-full-charged-symbolic'
Daemon:
daemon-version: 0.99.0
on-battery: no
lid-is-closed: no
lid-is-present: yes
is-docked: no
critical-action: PowerOff
Index: Makefile
===
RCS file: /cvs/ports/sysutils/upower/Makefile,v
retrieving revision 1.36
diff -u -p -r1.36 Makefile
--- Makefile20 Apr 2014 18:03:23 - 1.36
+++ Makefile17 May 2014 16:00:12 -
@@ -5,7 +5,7 @@ ONLY_FOR_ARCHS =${APM_ARCHS}
COMMENT = userland power management interface
DISTNAME = upower-0.99.0
-REVISION = 0
+REVISION = 1
EXTRACT_SUFX = .tar.xz
CATEGORIES = sysutils
SHARED_LIBS += upower-glib 1.0 # 2.0
Index: patches/patch-src_openbsd_up-backend_c
===
RCS file: /cvs/ports/sysutils/upower/patches/patch-src_openbsd_up-backend_c,v
retrieving revision 1.16
diff -u -p -r1.16 patch-src_openbsd_up-backend_c
--- patches/patch-src_openbsd_up-backend_c 23 Apr 2014 09:55:18 -
1.16
+++ patches/patch-src_openbsd_up-backend_c 17 May 2014 16:00:12 -
@@ -7,7 +7,7 @@ Subject: Update lid status when updating
https://bugs.freedesktop.org/show_bug.cgi?id=77692
--- src/openbsd/up-backend.c.orig Tue Oct 29 11:37:08 2013
-+++ src/openbsd/up-backend.c Sun Apr 20 18:54:05 2014
src/openbsd/up-backend.c Sat May 17 17:55:23 2014
@@ -34,6 +34,7 @@ static void up_backend_finalize (GObject
*object);
static gboolean up_backend_apm_get_power_info(struct apm_power_info*);
UpDeviceState up_backend_apm_get_battery_state_value(u_char battery_state);
@@ -37,7 +37,60 @@ Subject: Update lid status when updating
ret = up_backend_apm_get_power_info(a);
if (!ret)
return ret;
-@@ -405,6 +407,70 @@ up_apm_device_refresh(UpDevice* device)
+@@ -319,8 +321,8 @@ up_backend_update_acpibat_state(UpDevice* device, stru
+ {
+ enum sensor_type type;
+ int numt;
+-
Re: opendnssec and softhsm revisited
On Sun, May 18, 2014 at 11:04:19AM +0100, Stuart Henderson wrote: This is due to differences between C compilers. gcc 4.8 and clang don't warn for this with -pedantic, gcc 4.2.1 does. I think -pedantic is fairly pointless in ports and should be removed, but I would also report it to nlnetlabs as an ldns bug, I think the best approach would be to remove the surplus , for better compiler compatibility (and their other enums don't have a trailing ,). Thank you for the input, this has been reported here: https://www.nlnetlabs.nl/bugs-script/show_bug.cgi?id=579 I guess I will have to look into how to disabled -pedantic in the build then. Regards, Patrik Lundin
Re: [UPDATE] Mercurial 3.0
I tried hgview and py-hg-git they seem ok. I'm not exactly sure how to test py-hgtools (make install works). TortoiseHG will need an update to 3.0. I will send a patch for TortoiseHG shortly.
[UPDATE] TortoiseHg 3.0
This updates TortoiseHg from 2.10.2 to 3.0.
This requires my previous patch that updates to Mercurial 3.0.
Index: Makefile
===
RCS file: /cvs/ports/devel/tortoisehg/Makefile,v
retrieving revision 1.15
diff -u -p -r1.15 Makefile
--- Makefile19 Jan 2014 17:53:40 -1.15
+++ Makefile18 May 2014 13:31:06 -
@@ -2,7 +2,7 @@
COMMENT =series of applications for Mercurial
-MODPY_EGG_VERSION =2.10.2
+MODPY_EGG_VERSION =3.0
DISTNAME =tortoisehg-${MODPY_EGG_VERSION}
CATEGORIES =devel
@@ -23,7 +23,7 @@ BUILD_DEPENDS =x11/py-qt4 \
RUN_DEPENDS =${BUILD_DEPENDS} \
editors/py-qscintilla \
-devel/mercurial=2.8.2 \
+devel/mercurial=3.0 \
devel/py-iniparse
NO_TEST =Yes
Index: distinfo
===
RCS file: /cvs/ports/devel/tortoisehg/distinfo,v
retrieving revision 1.12
diff -u -p -r1.12 distinfo
--- distinfo19 Jan 2014 17:53:40 -1.12
+++ distinfo18 May 2014 13:31:06 -
@@ -1,2 +1,2 @@
-SHA256 (tortoisehg-2.10.2.tar.gz) =
7M7T+oa+mc4UJP4w7+wexYPyIne10wrCZlaHXhDNgu8=
-SIZE (tortoisehg-2.10.2.tar.gz) = 8623834
+SHA256 (tortoisehg-3.0.tar.gz) =
ylNx0NcgsPViEBNhLlReo4b+krXfSpxpa3LbvnFupKc=
+SIZE (tortoisehg-3.0.tar.gz) = 8237239
Index: pkg/PLIST
===
RCS file: /cvs/ports/devel/tortoisehg/pkg/PLIST,v
retrieving revision 1.9
diff -u -p -r1.9 PLIST
--- pkg/PLIST8 Nov 2013 11:45:26 -1.9
+++ pkg/PLIST18 May 2014 13:31:06 -
@@ -1,8 +1,8 @@
@comment $OpenBSD: PLIST,v 1.9 2013/11/08 11:45:26 rpointel Exp $
bin/thg
lib/nautilus/
-lib/nautilus/extensions-3.0/
-lib/nautilus/extensions-3.0/nautilus-thg.py
+lib/nautilus/extensions-${MODPY_EGG_VERSION}/
+lib/nautilus/extensions-${MODPY_EGG_VERSION}/nautilus-thg.py
lib/python${MODPY_VERSION}/site-packages/tortoisehg/
lib/python${MODPY_VERSION}/site-packages/tortoisehg-${MODPY_EGG_VERSION}-py${MODPY_VERSION}.egg-info
lib/python${MODPY_VERSION}/site-packages/tortoisehg/__init__.py
@@ -44,8 +44,6 @@ lib/python${MODPY_VERSION}/site-packages
lib/python${MODPY_VERSION}/site-packages/tortoisehg/hgqt/cslist.pyc
lib/python${MODPY_VERSION}/site-packages/tortoisehg/hgqt/customtools.py
lib/python${MODPY_VERSION}/site-packages/tortoisehg/hgqt/customtools.pyc
-lib/python${MODPY_VERSION}/site-packages/tortoisehg/hgqt/decorators.py
-lib/python${MODPY_VERSION}/site-packages/tortoisehg/hgqt/decorators.pyc
lib/python${MODPY_VERSION}/site-packages/tortoisehg/hgqt/docklog.py
lib/python${MODPY_VERSION}/site-packages/tortoisehg/hgqt/docklog.pyc
lib/python${MODPY_VERSION}/site-packages/tortoisehg/hgqt/filectxactions.py
@@ -54,12 +52,10 @@ lib/python${MODPY_VERSION}/site-packages
lib/python${MODPY_VERSION}/site-packages/tortoisehg/hgqt/filedata.pyc
lib/python${MODPY_VERSION}/site-packages/tortoisehg/hgqt/filedialogs.py
lib/python${MODPY_VERSION}/site-packages/tortoisehg/hgqt/filedialogs.pyc
-lib/python${MODPY_VERSION}/site-packages/tortoisehg/hgqt/filelistmodel.py
-lib/python${MODPY_VERSION}/site-packages/tortoisehg/hgqt/filelistmodel.pyc
+lib/python${MODPY_VERSION}/site-packages/tortoisehg/hgqt/fileencoding.py
+lib/python${MODPY_VERSION}/site-packages/tortoisehg/hgqt/fileencoding.pyc
lib/python${MODPY_VERSION}/site-packages/tortoisehg/hgqt/filelistview.py
lib/python${MODPY_VERSION}/site-packages/tortoisehg/hgqt/filelistview.pyc
-lib/python${MODPY_VERSION}/site-packages/tortoisehg/hgqt/filerevmodel.py
-lib/python${MODPY_VERSION}/site-packages/tortoisehg/hgqt/filerevmodel.pyc
lib/python${MODPY_VERSION}/site-packages/tortoisehg/hgqt/fileview.py
lib/python${MODPY_VERSION}/site-packages/tortoisehg/hgqt/fileview.pyc
lib/python${MODPY_VERSION}/site-packages/tortoisehg/hgqt/graft.py
@@ -94,10 +90,6 @@ lib/python${MODPY_VERSION}/site-packages
lib/python${MODPY_VERSION}/site-packages/tortoisehg/hgqt/lfprompt.pyc
lib/python${MODPY_VERSION}/site-packages/tortoisehg/hgqt/license.py
lib/python${MODPY_VERSION}/site-packages/tortoisehg/hgqt/license.pyc
-lib/python${MODPY_VERSION}/site-packages/tortoisehg/hgqt/logcolumns.py
-lib/python${MODPY_VERSION}/site-packages/tortoisehg/hgqt/logcolumns.pyc
-lib/python${MODPY_VERSION}/site-packages/tortoisehg/hgqt/manifestdialog.py
-lib/python${MODPY_VERSION}/site-packages/tortoisehg/hgqt/manifestdialog.pyc
lib/python${MODPY_VERSION}/site-packages/tortoisehg/hgqt/manifestmodel.py
lib/python${MODPY_VERSION}/site-packages/tortoisehg/hgqt/manifestmodel.pyc
lib/python${MODPY_VERSION}/site-packages/tortoisehg/hgqt/matching.py
@@ -114,10 +106,6 @@ lib/python${MODPY_VERSION}/site-packages
lib/python${MODPY_VERSION}/site-packages/tortoisehg/hgqt/mqutil.pyc
lib/python${MODPY_VERSION}/site-packages/tortoisehg/hgqt/p4pending.py
lib/python${MODPY_VERSION}/site-packages/tortoisehg/hgqt/p4pending.pyc
new: textproc/gpresent
Inspired by schwarze@'s slides for BSDCan, here's a port of the gpresent
macros. The macros themselves are installed into
${PREFIX}/share/groff/site-tmac for simplicity's sake; it also doesn't
really make sense to put them into the versioned directory
share/groff/1.22.2/...
ok?
gpresent.tgz
Description: gpresent.tgz
Re: [UPDATE] py-pip-1.5.6
Hi Seth,
On Sat, May 17, 2014 at 05:15:24PM -0400, Seth Jackson wrote:
This updates pip from 1.1 to 1.5.6.
This looks good, I was able to install packages with --user into ~/.local in
both Python2.7 and Python3.3.
However there is one thing that should be discussed:
-${PREFIX}/bin/pip-${MODPY_VERSION}.
+${PREFIX}/bin/pip${MODPY_VERSION}.
Personally I welcome that change, as the naming convention matches
MODPY_BIN. CCing a couple of people that may have an opinion.
--
Best Regards
Edd Barrett
http://www.theunixzoo.co.uk
Re: [UPDATE] py-pip-1.5.6
This looks good, I was able to install packages with --user into ~/.local in both Python2.7 and Python3.3. I've also tried installing global site packages with 2.7 and 3.3 at it seems to work ok. Further I did a quick check of binary packages (Pillow) and that works too. Personally I welcome that change, as the naming convention matches MODPY_BIN. I agree.
Re: opendnssec and softhsm revisited
On Sun, May 18, 2014 at 01:24:11PM +0200, Patrik Lundin wrote: I guess I will have to look into how to disabled -pedantic in the build then. Disabling -pedantic was easy to do at configure time, using --disable-pedantic. Now I have started looking at the remaining warnings. I am constantly debating with myself which group I should talk to first regarding the following questions, but since these are not thrown on the comparision Linux box I'll start in this end: First up is this one: === pin.c: In function 'hsm_shm_open': pin.c:209: warning: comparison between signed and unsigned === This is caused by comparing a size_t variable to shm_segsz which according to shmctl(2) on OpenBSD is an int. Reading the same man page on the Ubuntu box shows that shm_segsz is considerd to be type size_t there. I guess I can fix this by casting shm_segsz to an unsigned int, does that sound reasonable? Next we have this one: === hsmspeed.c:38:1: warning: PTHREAD_THREADS_MAX redefined In file included from hsmspeed.c:33: /usr/include/pthread.h:55:1: warning: this is the location of the previous definition === It seems the Linux box just has this to say: /* We have no predefined limit on the number of threads. */ #undef PTHREAD_THREADS_MAX While OpenBSD sets it to a very big value: #define PTHREAD_THREADS_MAX ULONG_MAX The code itself sets it to 2048, way less than the default. I guess having a more conservative setting is not a problem. Maby I should just leave this warning as is? Third and final (for now): === hsmspeed.c: In function 'sign': hsmspeed.c:120: warning: control reaches end of non-void function === This warning bothers me somewhat, the function is declared in the following way: void * sign (void *arg) It is passed to pthread_create() which is probably why it is a pointer function. I am not sure why the Linux box does not say anything about this. My current idea is that the function should just have a dummy return NULL; after the call to pthread_exit(). Any ideas? Regards, Patrik Lundin
Re: [UPDATE] py-pip-1.5.6
On Sun, 18 May 2014 17:36:34 +0100
Edd Barrett vex...@gmail.com wrote:
Hi Seth,
On Sat, May 17, 2014 at 05:15:24PM -0400, Seth Jackson wrote:
This updates pip from 1.1 to 1.5.6.
This looks good, I was able to install packages with --user into ~/.local in
both Python2.7 and Python3.3.
However there is one thing that should be discussed:
-${PREFIX}/bin/pip-${MODPY_VERSION}.
+${PREFIX}/bin/pip${MODPY_VERSION}.
Personally I welcome that change, as the naming convention matches
MODPY_BIN. CCing a couple of people that may have an opinion.
I'm ok with this (not tested the update but just for the thing you precised).
Cheers,
Remi.
xpdf slow opening postgresql-9.3-US.pdf
Hi, I noticed with PostgreSQL 9.2.x releases that their documentation file in PDF (US) format took a considerable time longer to open using xpdf compared with the 9.1, and earlier PDF files I had. With Pg 9.3.x I see the same, so I started to wonder and noticed that the currently available 9.1 PDF on their site[1] advertises a much smaller file than what I have on my local drive: 6.0 MB vs 8.7M respectively. I grabbed the smaller 9.1 document, and it too takes a long time to open: Opening the (smaller) 6M postgresql-9.1-US.pdf (version 9.1.13) takes 49.54s.[2] Opening the (larger) 8.7M postgresql-9.1-US.pdf (version 9.1.3) takes 1.95s.[2] On a MacBook Pro all documents open so quickly it is difficult to time them. I am not sure if this is due to some sinister caching OS X uses or simply a better document parsing in Preview (and of course, a faster CPU). Does anyone (with PDF knowledge) know if this is due to some compression being used in generating these documents? Obvious guess due to size shrink. Last update to xpdf was in August 2011, so I'm not sure if author would be interested in this report, I will forward a copy of this message to them anyway. --patrick [1] http://www.postgresql.org/docs/manuals/ [2] cpu0: AMD E-350 Processor, 1597.54 MHz
Re: [UPDATE] Mercurial 3.0
On Sat, May 17, 2014 at 05:35:24PM -0400, Seth Jackson wrote: This updates Mercurial from 2.8.2 to 3.0. Note that your mailer (gmail) mangles diffs and makes them unapplyable without hand-editing... Landry
Re: [UPDATE] TortoiseHg 3.0
On Sun, May 18, 2014 at 10:10:20AM -0400, Seth Jackson wrote:
This updates TortoiseHg from 2.10.2 to 3.0.
This requires my previous patch that updates to Mercurial 3.0.
RCS file: /cvs/ports/devel/tortoisehg/pkg/PLIST,v
retrieving revision 1.9
diff -u -p -r1.9 PLIST
--- pkg/PLIST8 Nov 2013 11:45:26 -1.9
+++ pkg/PLIST18 May 2014 13:31:06 -
@@ -1,8 +1,8 @@
@comment $OpenBSD: PLIST,v 1.9 2013/11/08 11:45:26 rpointel Exp $
bin/thg
lib/nautilus/
-lib/nautilus/extensions-3.0/
-lib/nautilus/extensions-3.0/nautilus-thg.py
+lib/nautilus/extensions-${MODPY_EGG_VERSION}/
+lib/nautilus/extensions-${MODPY_EGG_VERSION}/nautilus-thg.py
That changes doesnt really make sense since 3.0 is nautilus api version,
and i dont think it matches the thg version. Better keep 3.0 here imo.
testing this and hg update on amd64.
i've attached the applying diff for both, from devel subdir.
Remi, can you have a look at it too ?
Landry
Index: mercurial/Makefile
===
RCS file: /cvs/ports/devel/mercurial/Makefile,v
retrieving revision 1.59
diff -u -r1.59 Makefile
--- mercurial/Makefile 19 Jan 2014 17:52:47 - 1.59
+++ mercurial/Makefile 18 May 2014 20:59:25 -
@@ -3,7 +3,7 @@
COMMENT-main = fast, lightweight source control management
COMMENT-x11 = graphical tooling for mercurial
-MODPY_EGG_VERSION =2.8.2
+MODPY_EGG_VERSION =3.0
DISTNAME = mercurial-${MODPY_EGG_VERSION}
CATEGORIES = devel
Index: mercurial/distinfo
===
RCS file: /cvs/ports/devel/mercurial/distinfo,v
retrieving revision 1.41
diff -u -r1.41 distinfo
--- mercurial/distinfo 19 Jan 2014 17:52:47 - 1.41
+++ mercurial/distinfo 18 May 2014 20:59:25 -
@@ -1,2 +1,2 @@
-SHA256 (mercurial-2.8.2.tar.gz) = yKW6ohFAxs1nScO1K15eShS2uO58UY2dneCbGVLvvm8=
-SIZE (mercurial-2.8.2.tar.gz) = 3839304
+SHA256 (mercurial-3.0.tar.gz) = ZAyWVWpFJN8hacZwak9omXxb9YYrWXGzwu4T7Uw0nPs=
+SIZE (mercurial-3.0.tar.gz) = 3903047
Index: mercurial/pkg/PLIST-main
===
RCS file: /cvs/ports/devel/mercurial/pkg/PLIST-main,v
retrieving revision 1.2
diff -u -r1.2 PLIST-main
--- mercurial/pkg/PLIST-main8 Nov 2013 11:45:03 - 1.2
+++ mercurial/pkg/PLIST-main18 May 2014 20:59:25 -
@@ -68,8 +68,6 @@
lib/python${MODPY_VERSION}/site-packages/hgext/highlight/highlight.pyc
lib/python${MODPY_VERSION}/site-packages/hgext/histedit.py
lib/python${MODPY_VERSION}/site-packages/hgext/histedit.pyc
-lib/python${MODPY_VERSION}/site-packages/hgext/interhg.py
-lib/python${MODPY_VERSION}/site-packages/hgext/interhg.pyc
lib/python${MODPY_VERSION}/site-packages/hgext/keyword.py
lib/python${MODPY_VERSION}/site-packages/hgext/keyword.pyc
lib/python${MODPY_VERSION}/site-packages/hgext/largefiles/
@@ -148,6 +146,8 @@
lib/python${MODPY_VERSION}/site-packages/mercurial/bookmarks.pyc
lib/python${MODPY_VERSION}/site-packages/mercurial/branchmap.py
lib/python${MODPY_VERSION}/site-packages/mercurial/branchmap.pyc
+lib/python${MODPY_VERSION}/site-packages/mercurial/bundle2.py
+lib/python${MODPY_VERSION}/site-packages/mercurial/bundle2.pyc
lib/python${MODPY_VERSION}/site-packages/mercurial/bundlerepo.py
lib/python${MODPY_VERSION}/site-packages/mercurial/bundlerepo.pyc
lib/python${MODPY_VERSION}/site-packages/mercurial/byterange.py
@@ -187,6 +187,8 @@
lib/python${MODPY_VERSION}/site-packages/mercurial/encoding.pyc
lib/python${MODPY_VERSION}/site-packages/mercurial/error.py
lib/python${MODPY_VERSION}/site-packages/mercurial/error.pyc
+lib/python${MODPY_VERSION}/site-packages/mercurial/exchange.py
+lib/python${MODPY_VERSION}/site-packages/mercurial/exchange.pyc
lib/python${MODPY_VERSION}/site-packages/mercurial/extensions.py
lib/python${MODPY_VERSION}/site-packages/mercurial/extensions.pyc
lib/python${MODPY_VERSION}/site-packages/mercurial/fancyopts.py
@@ -338,6 +340,8 @@
lib/python${MODPY_VERSION}/site-packages/mercurial/parsers.so
lib/python${MODPY_VERSION}/site-packages/mercurial/patch.py
lib/python${MODPY_VERSION}/site-packages/mercurial/patch.pyc
+lib/python${MODPY_VERSION}/site-packages/mercurial/pathutil.py
+lib/python${MODPY_VERSION}/site-packages/mercurial/pathutil.pyc
lib/python${MODPY_VERSION}/site-packages/mercurial/peer.py
lib/python${MODPY_VERSION}/site-packages/mercurial/peer.pyc
lib/python${MODPY_VERSION}/site-packages/mercurial/phases.py
Index: tortoisehg/Makefile
===
RCS file: /cvs/ports/devel/tortoisehg/Makefile,v
retrieving revision 1.15
diff -u -r1.15 Makefile
--- tortoisehg/Makefile 19 Jan 2014 17:53:40 - 1.15
+++ tortoisehg/Makefile 18 May 2014 20:59:25 -
@@ -2,7 +2,7 @@
COMMENT = series of applications for Mercurial
-MODPY_EGG_VERSION =2.10.2
+MODPY_EGG_VERSION =3.0
DISTNAME =
Re: xpdf slow opening postgresql-9.3-US.pdf
On 2014/05/18 13:41, patrick keshishian wrote: Hi, I noticed with PostgreSQL 9.2.x releases that their documentation file in PDF (US) format took a considerable time longer to open using xpdf compared with the 9.1, and earlier PDF files I had. With Pg 9.3.x I see the same, so I started to wonder and noticed that the currently available 9.1 PDF on their site[1] advertises a much smaller file than what I have on my local drive: 6.0 MB vs 8.7M respectively. I grabbed the smaller 9.1 document, and it too takes a long time to open: Opening the (smaller) 6M postgresql-9.1-US.pdf (version 9.1.13) takes 49.54s.[2] Opening the (larger) 8.7M postgresql-9.1-US.pdf (version 9.1.3) takes 1.95s.[2] On a MacBook Pro all documents open so quickly it is difficult to time them. I am not sure if this is due to some sinister caching OS X uses or simply a better document parsing in Preview (and of course, a faster CPU). Does anyone (with PDF knowledge) know if this is due to some compression being used in generating these documents? Obvious guess due to size shrink. Last update to xpdf was in August 2011, so I'm not sure if author would be interested in this report, I will forward a copy of this message to them anyway. --patrick [1] http://www.postgresql.org/docs/manuals/ [2] cpu0: AMD E-350 Processor, 1597.54 MHz Slow with xpdf for me too. mupdf opens them quickly though. Perhaps they are created with a different version of TeXLive or post-processed with a different iTEXT, either of which could do something differently that xpdf doesn't like? Current ones (according to 'pdftk postgresql-9.3-A4.pdf dumpdata') are: InfoValue: This is pdfTeX, Version 3.1415926-2.4-1.40.13 (TeX Live 2012/Debian) kpathsea version 6.1.0 InfoValue: pdfTeX-1.40.13; modified using iText#174; 5.1.3 #169;2000-2011 1T3XT BVBA
Re: Quick fix of x11/kde4/libs build
2014-05-16 21:44 GMT+04:00 David Coppa dco...@openbsd.org:
On Fri, May 16, 2014 at 08:38:50PM +0400, Vadim Zhukov wrote:
This patch makes x11/kde4/libs build reliably again. The probably is
likely deep inside our compiler but I'm not the one who'll be able
to fix this bug. And we need to have reliable builds of kdelibs
anyway, it's too critical to wait until it gets fixed.
This could probably fix the build/package bug in x11/kde4/l10n/pt, too.
But since I still can't reproduce it, I'm not sure.
Asking for bulk build tests.
--
WBR,
Vadim Zhukov
Index: Makefile
===
RCS file: /cvs/ports/devel/cmake/Makefile,v
retrieving revision 1.101
diff -u -p -r1.101 Makefile
--- Makefile 13 May 2014 05:55:30 - 1.101
+++ Makefile 16 May 2014 16:33:07 -
@@ -2,16 +2,19 @@
DPB_PROPERTIES =parallel
-# avoid segfaults from binaries compiled and then used during the build
.if ${MACHINE_ARCH} == arm
+# avoid segfaults from binaries compiled and then used during the build
CFLAGS +=-O1 -fno-stack-protector
+.else
+# -O2 breaks at least x11/kde4/libs
+CFLAGS +=-O1
.endif
HOMEPAGE = http://www.cmake.org/
CATEGORIES = devel
COMMENT =portable build system
DISTNAME = cmake-2.8.12.2
-REVISION = 3
+REVISION = 4
MASTER_SITES = ${HOMEPAGE}files/v2.8/
MAINTAINER = David Coppa dco...@openbsd.org
As an ad interim fix, I'd say put it in and we'll see...
Please disregard this diff. While it fixed kdelibs-4.11.5, I got
same crash with kdepimlibs-4.13.1.
Given that we have heavily patched cmTarget.cxx file, dragons probably
are there... I'm building -O0 -ggdb version of CMake now, trying to
debug issue further.
--
WBR,
Vadim Zhukov
Re: xpdf slow opening postgresql-9.3-US.pdf
previously on this list Stuart Henderson contributed: Slow with xpdf for me too. mupdf opens them quickly though. There were some arguments on the debian list about removing xpdf as it was no longer developed upstream and they had long standing bugs open against it. Not sure if that is relevant at all. -- ___ 'Write programs that do one thing and do it well. Write programs to work together. Write programs to handle text streams, because that is a universal interface' (Doug McIlroy) In Other Words - Don't design like polkit or systemd ___
Re: Quick fix of x11/kde4/libs build
While I see the kde4/l10n/pt failure repeatably now (but not any other l10n
ports), I haven't hit the kdelibs one again.. From the timescale (and having
already tried reverting malloc changes), I'd have thought that the recent
compiler changes would be the most likely trigger.. Planning to try a test
build with those pulled out (I would have already started one but there was a
fontconfig bump so my build machines are busy again..)
On 18 May 2014 23:06:11 BST, Vadim Zhukov persg...@gmail.com wrote:
2014-05-16 21:44 GMT+04:00 David Coppa dco...@openbsd.org:
On Fri, May 16, 2014 at 08:38:50PM +0400, Vadim Zhukov wrote:
This patch makes x11/kde4/libs build reliably again. The probably is
likely deep inside our compiler but I'm not the one who'll be able
to fix this bug. And we need to have reliable builds of kdelibs
anyway, it's too critical to wait until it gets fixed.
This could probably fix the build/package bug in x11/kde4/l10n/pt,
too.
But since I still can't reproduce it, I'm not sure.
Asking for bulk build tests.
--
WBR,
Vadim Zhukov
Index: Makefile
===
RCS file: /cvs/ports/devel/cmake/Makefile,v
retrieving revision 1.101
diff -u -p -r1.101 Makefile
--- Makefile 13 May 2014 05:55:30 - 1.101
+++ Makefile 16 May 2014 16:33:07 -
@@ -2,16 +2,19 @@
DPB_PROPERTIES =parallel
-# avoid segfaults from binaries compiled and then used during the
build
.if ${MACHINE_ARCH} == arm
+# avoid segfaults from binaries compiled and then used during the
build
CFLAGS +=-O1 -fno-stack-protector
+.else
+# -O2 breaks at least x11/kde4/libs
+CFLAGS +=-O1
.endif
HOMEPAGE = http://www.cmake.org/
CATEGORIES = devel
COMMENT =portable build system
DISTNAME = cmake-2.8.12.2
-REVISION = 3
+REVISION = 4
MASTER_SITES = ${HOMEPAGE}files/v2.8/
MAINTAINER = David Coppa dco...@openbsd.org
As an ad interim fix, I'd say put it in and we'll see...
Please disregard this diff. While it fixed kdelibs-4.11.5, I got
same crash with kdepimlibs-4.13.1.
Given that we have heavily patched cmTarget.cxx file, dragons probably
are there... I'm building -O0 -ggdb version of CMake now, trying to
debug issue further.
--
WBR,
Vadim Zhukov
Re: UPDATE: Icecast-2.4.0
anyone? On Tue, May 13, 2014 at 09:33:11AM -0300, Gonzalo L. Rodriguez wrote: ; Hi, ; ; Update for Icecast to 2.4.0: ; ; http://svn.xiph.org/icecast/tags/icecast-2.4.0/ChangeLog ; ; Comments? Ok? ; ; ; Cheers.- ; ; -- ; Sending from my toaster. ; Index: Makefile ; === ; RCS file: /cvs/ports/net/icecast/Makefile,v ; retrieving revision 1.52 ; diff -u -p -r1.52 Makefile ; --- Makefile 21 Mar 2013 08:46:34 - 1.52 ; +++ Makefile 13 May 2014 12:31:30 - ; @@ -2,7 +2,7 @@ ; ; COMMENT= server for streaming various media formats ; ; -DISTNAME=icecast-2.3.3 ; +DISTNAME=icecast-2.4.0 ; CATEGORIES= net audio ; ; HOMEPAGE=http://www.icecast.org/ ; Index: distinfo ; === ; RCS file: /cvs/ports/net/icecast/distinfo,v ; retrieving revision 1.12 ; diff -u -p -r1.12 distinfo ; --- distinfo 1 Sep 2012 17:35:54 - 1.12 ; +++ distinfo 13 May 2014 12:31:30 - ; @@ -1,2 +1,2 @@ ; -SHA256 (icecast-2.3.3.tar.gz) = Gx0G9fg8mpg80ozHiqkOQDj5M1EbPSDX/Sz8EWZFw20= ; -SIZE (icecast-2.3.3.tar.gz) = 1161774 ; +SHA256 (icecast-2.4.0.tar.gz) = F7fpV+Gxaldu+qvWnBUSboTOmNN5HM7kVGtywMZGDzI= ; +SIZE (icecast-2.4.0.tar.gz) = 1087795 ; Index: patches/patch-Makefile_in ; === ; RCS file: /cvs/ports/net/icecast/patches/patch-Makefile_in,v ; retrieving revision 1.5 ; diff -u -p -r1.5 patch-Makefile_in ; --- patches/patch-Makefile_in 1 Sep 2012 17:35:54 - 1.5 ; +++ patches/patch-Makefile_in 13 May 2014 12:31:30 - ; @@ -1,7 +1,7 @@ ; $OpenBSD: patch-Makefile_in,v 1.5 2012/09/01 17:35:54 gonzalo Exp $ ; Makefile.in.orig Mon Jun 11 14:03:15 2012 ; -+++ Makefile.in Mon Aug 13 13:31:38 2012 ; -@@ -324,7 +324,7 @@ EXTRA_DIST = HACKING m4/acx_pthread.m4 m4/ogg.m4 \ ; +--- Makefile.in.orig Tue May 6 01:55:10 2014 ; Makefile.in Tue May 13 08:42:27 2014 ; +@@ -392,7 +392,7 @@ EXTRA_DIST = HACKING m4/acx_pthread.m4 m4/ogg.m4 \ ; m4/xiph_compiler.m4 m4/xiph_curl.m4 m4/xiph_net.m4 \ ; m4/xiph_types.m4 m4/xiph_xml2.m4 icecast.spec ; ; Index: patches/patch-admin_Makefile_in ; === ; RCS file: /cvs/ports/net/icecast/patches/patch-admin_Makefile_in,v ; retrieving revision 1.3 ; diff -u -p -r1.3 patch-admin_Makefile_in ; --- patches/patch-admin_Makefile_in 1 Sep 2012 17:35:54 - 1.3 ; +++ patches/patch-admin_Makefile_in 13 May 2014 12:31:30 - ; @@ -1,10 +1,10 @@ ; $OpenBSD: patch-admin_Makefile_in,v 1.3 2012/09/01 17:35:54 gonzalo Exp $ ; admin/Makefile.in.orig Mon Jun 11 14:03:11 2012 ; -+++ admin/Makefile.inMon Aug 13 13:34:51 2012 ; -@@ -33,7 +33,7 @@ am__make_dryrun = \ ; - esac; \ ; - test $$am__dry = yes; \ ; - } ; +--- admin/Makefile.in.orig Tue May 13 08:42:41 2014 ; admin/Makefile.inTue May 13 08:47:16 2014 ; +@@ -60,7 +60,7 @@ am__make_running_with_option = \ ; + test $$has_opt = yes ; + am__make_dryrun = (target_option=n; $(am__make_running_with_option)) ; + am__make_keepgoing = (target_option=k; $(am__make_running_with_option)) ; -pkgdatadir = $(datadir)/@PACKAGE@ ; +pkgdatadir = $(datadir)/examples/@PACKAGE@ ; pkgincludedir = $(includedir)/@PACKAGE@ ; Index: patches/patch-conf_Makefile_in ; === ; RCS file: /cvs/ports/net/icecast/patches/patch-conf_Makefile_in,v ; retrieving revision 1.5 ; diff -u -p -r1.5 patch-conf_Makefile_in ; --- patches/patch-conf_Makefile_in1 Sep 2012 17:35:54 - 1.5 ; +++ patches/patch-conf_Makefile_in13 May 2014 12:31:30 - ; @@ -1,7 +1,7 @@ ; $OpenBSD: patch-conf_Makefile_in,v 1.5 2012/09/01 17:35:54 gonzalo Exp $ ; conf/Makefile.in.origMon Jun 11 14:03:11 2012 ; -+++ conf/Makefile.in Mon Aug 13 13:31:38 2012 ; -@@ -226,7 +226,7 @@ build_vendor = @build_vendor@ ; +--- conf/Makefile.in.origTue May 6 01:55:10 2014 ; conf/Makefile.in Tue May 13 08:42:27 2014 ; +@@ -269,7 +269,7 @@ build_vendor = @build_vendor@ ; builddir = @builddir@ ; datadir = @datadir@ ; datarootdir = @datarootdir@ ; Index: patches/patch-conf_icecast_xml_in ; === ; RCS file: /cvs/ports/net/icecast/patches/patch-conf_icecast_xml_in,v ; retrieving revision 1.6 ; diff -u -p -r1.6 patch-conf_icecast_xml_in ; --- patches/patch-conf_icecast_xml_in 1 Sep 2012 17:35:54 - 1.6 ; +++ patches/patch-conf_icecast_xml_in 13 May 2014 12:31:30 - ; @@ -1,7 +1,7 @@ ; $OpenBSD: patch-conf_icecast_xml_in,v 1.6 2012/09/01 17:35:54 gonzalo Exp $ ; conf/icecast.xml.in.orig Mon Jun 11 13:45:19 2012 ; -+++ conf/icecast.xml.in Mon Aug 13 13:31:38 2012 ; -@@ -131,14 +131,14 @@ ; +--- conf/icecast.xml.in.orig Sun Jan 6 07:28:44 2013 ; conf/icecast.xml.in Tue
Re: new: textproc/gpresent
Hi Pascal,
Pascal Stumpf wrote on Sun, May 18, 2014 at 04:39:06PM +0200:
Inspired by schwarze@'s slides for BSDCan, here's a port of the
gpresent macros.
Ouch, i have been stupid. I thought i had committed my port,
but apparently, i forgot to do so.
The macros themselves are installed into
${PREFIX}/share/groff/site-tmac for simplicity's sake; it also
doesn't really make sense to put them into the versioned directory
share/groff/1.22.2/...
Indeed, that's where i think they belong.
In any case, please put this port in. Don't wait for my OK,
i may not be around.
Here are a few things i did differently, take whatever you want.
Apart from that, my port was identical.
* I set COMMENT to make presentations with groff and PDF
for additional clarity.
* I used
TMACDIR = ${PREFIX}/share/groff/site-tmac
EXDIR = ${PREFIX}/share/examples/gpresent
for brevity and used that in do-install
* I used the following DESCR:
The gpresent and piclink groff macros and the presentps PostScript
postprocessor support the creation of PDF presentations. Without
using the PAUSE macro, the macros can also be used to make slides.
gpresent is a package is redundant
with acroread is very misleading, you don't need acroread at all
* I have this in PLIST in addition to what you have:
share/examples/gpresent/
share/examples/gpresent/demo.pdf
share/examples/gpresent/demo.rof
share/examples/gpresent/piclink.pdf
share/examples/gpresent/piclink.rof
share/examples/gpresent/sidebar.pdf
share/examples/gpresent/sidebar.rof
I used these extensively when preparing my slides.
They are a very valuable addition to the documentation.
Thanks for picking this up,
Ingo
xmonad problem (libHSffi missing from GHC)
Hi Matthias, Thanks for keeping Haskell going on OpenBSD! I installed xmonad package on 5.5/amd64 and tried to start with the most trivial config: % xmonad --recompile Error detected while loading xmonad configuration file: /home/greg/.xmonad/xmonad.hs /usr/bin/ld: cannot find -lHSffi collect2: ld returned 1 exit status % cat ~/.xmonad/xmonad.hs import XMonad main = xmonad defaultConfig libHSffi is indeed nowhere to be found: % pkg_info -L ghc-7.6.3p1 | grep HSffi % Is anybody successfully running xmonad on 5.5? Where do you get libHSffi from? Thanks Greg -- nest.cx is Gmail hosted, use PGP for anything private. Key: http://goo.gl/6dMsr Fingerprint: 5E2B 2D0E 1E03 2046 BEC3 4D50 0B15 42BD 8DF5 A1B0
