Re: Chromium with kerberos
Hi
The OpenBSD chromium port is built without kerberos support.
On (2017-04-18 07:37), Jiri B wrote:
> Hi,
>
> does OpenBSD chromium work with heimdal in ports?
>
> I found following part in Chromium code
> https://github.com/adobe/chromium/blob/master/net/net.gyp#L800
> which makes me doubtful.
>
> ...
> ['use_kerberos==1', {
> 'defines': [
> 'USE_KERBEROS',
> ],
> 'conditions': [
> ['OS=="openbsd"', {
> 'include_dirs': [
> '/usr/include/kerberosV'
> ],
> }],
> ...
>
> And if it does work, do I have to put '--auth-server-whitelist=.example.com'
> as cmd option?
>
> j.
>
Re: Remove japanese/jvim and japanese/less
On Tue, 18 Apr 2017 19:22:29 -0600
"Anthony J. Bentley" wrote:
>> +COMMENT=Enhanced less with iso-2022-jp and UTF-8 encodings support
>
> "Enhanced" should be lowercase.
I see. Fixed it.
>> -# BSD
>> +# GPLv2
>
> Looks like it's dual-licensed, GPLv2+ and BSD?
This was come from my misunderstanding. I'm sorry. Actually it's
still dual license, so we can/should keep BSD.
ok?
diff --git a/japanese/less/Makefile b/japanese/less/Makefile
index 6bdcee0bff8..ecc1698ba60 100644
--- a/japanese/less/Makefile
+++ b/japanese/less/Makefile
@@ -1,30 +1,33 @@
# $OpenBSD: Makefile,v 1.25 2014/11/27 12:26:49 naddy Exp $
-COMMENT= less + zcat + ISO-2022 - a pager similar to more and pg
+COMMENT= enhanced less with iso-2022-jp and UTF-8 encodings support
-DISTNAME= less-332
-PKGNAME= ja-less-3.32pl2.48
-REVISION= 0
-CATEGORIES=japanese
-MASTER_SITES= ${MASTER_SITE_GNU:=less/}
-HOMEPAGE= http://www.pobox.com/~jam/less/
+V= 382.262.03.01
-MASTER_SITES0= ftp://ftp.big.or.jp/pub/usr2/jam/less/
-PATCHFILES=less-332-iso242.patch.gz:0 \
- less-332-iso242-243.patch.gz:0 \
- less-332-iso243-244.patch.gz:0 \
- less-332-iso244-245.patch.gz:0 \
- less-332-iso245-247.patch.gz:0 \
- less-332-iso247-248.patch.gz:0
+GH_ACCOUNT=hrs-allbsd
+GH_PROJECT=less
+GH_TAGNAME=v${V}
-PATCH_DIST_STRIP= -p1
+PKGNAME= ja-less-${V}
+CATEGORIES=japanese
+HOMEPAGE=
http://web.archive.org/web/20070220213232/http://www25.big.or.jp/~jam/less
-MAINTAINER=Marc Espie
+MAINTAINER = YASUOKA Masahiko
# BSD
PERMIT_PACKAGE_CDROM= Yes
WANTLIB= c ncurses
CONFIGURE_STYLE= gnu dest
+CONFIGURE_ARGS=--with-cs-regex
+
+DOCS= README.iso README.iso.jp README.lesw.euc README.regex \
+ README.regex.jp README.ext.jp
+
+post-install:
+ ${INSTALL_DATA_DIR} ${PREFIX}/share/doc/ja-less
+.for _f in ${DOCS}
+ ${INSTALL_DATA} ${WRKSRC}/${_f} ${PREFIX}/share/doc/ja-less
+.endfor
.include
diff --git a/japanese/less/distinfo b/japanese/less/distinfo
index 854ad683b7e..6554f7b66d4 100644
--- a/japanese/less/distinfo
+++ b/japanese/less/distinfo
@@ -1,14 +1,2 @@
-SHA256 (less-332-iso242-243.patch.gz) =
BqUDmpt62faVbPStHXTYus2mPwHflvClS/DeZPlQsvo=
-SHA256 (less-332-iso242.patch.gz) =
GfQ3nZ6DlSMn5UTDqN2C3DMHrxptIoMzEbl8u228x9M=
-SHA256 (less-332-iso243-244.patch.gz) =
d7nga8cvfVBb+IuXkEe5Jo3NGmECIq5R7MfpvO0Ga1s=
-SHA256 (less-332-iso244-245.patch.gz) =
8TCGC0JYfIXBZcC/BC1JESrj7dWWoEvbMmy7FrP6scQ=
-SHA256 (less-332-iso245-247.patch.gz) =
B9oLi4VaBp34weAa3QR0YJcYuntd2Uq/4/v10yMnKhI=
-SHA256 (less-332-iso247-248.patch.gz) =
4JYiP5vI/Bh+s8XtrT19pZdIcDEKzdur/nrR+lkPYpM=
-SHA256 (less-332.tar.gz) = xrPeY8Ku1E4OTUD8tG3PaBL17PNOOGTr9PetB3xMooA=
-SIZE (less-332-iso242-243.patch.gz) = 10128
-SIZE (less-332-iso242.patch.gz) = 61306
-SIZE (less-332-iso243-244.patch.gz) = 3212
-SIZE (less-332-iso244-245.patch.gz) = 490
-SIZE (less-332-iso245-247.patch.gz) = 4597
-SIZE (less-332-iso247-248.patch.gz) = 3806
-SIZE (less-332.tar.gz) = 204926
+SHA256 (less-382.262.03.01.tar.gz) =
sZxWL8QyfP54O+B0zKAwJS3THsIsKYKaq8EDhJtqyko=
+SIZE (less-382.262.03.01.tar.gz) = 471513
diff --git a/japanese/less/patches/patch-Makefile_in
b/japanese/less/patches/patch-Makefile_in
deleted file mode 100644
index 9f2cf56861b..000
--- a/japanese/less/patches/patch-Makefile_in
+++ /dev/null
@@ -1,17 +0,0 @@
-$OpenBSD: patch-Makefile_in,v 1.1 2007/10/26 21:42:18 ajacoutot Exp $
Makefile.in.orig Fri Oct 26 23:39:07 2007
-+++ Makefile.inFri Oct 26 23:39:08 2007
-@@ -22,11 +22,11 @@ exec_prefix = @exec_prefix@
-
- # Where the installed binary goes.
- bindir = ${exec_prefix}/bin
--binprefix =
-+binprefix = j
-
- mandir = ${prefix}/man/man${manext}
- manext = 1
--manprefix =
-+manprefix = j
-
- End of system configuration section.
-
diff --git a/japanese/less/pkg/DESCR b/japanese/less/pkg/DESCR
index 7b0a8856edd..152f11ecff0 100644
--- a/japanese/less/pkg/DESCR
+++ b/japanese/less/pkg/DESCR
@@ -1,9 +1,9 @@
- Less is a program similar to more (1), but which allows
- backward movement in the file as well as forward movement.
- Also, less does not have to read the entire input file
- before starting, so with large input files it starts up
- faster than text editors like vi (1).
+Less is a program similar to more(1), but which allows backward
+movement in the file as well as forward movement. Also, less does not
+have to read the entire input file before starting, so with large
+input files it starts up faster than text editors like vi(1).
This enhanced less supports ISO 2022 code extension techniques and
Japanese codes(EUC Japanese, SJIS) and compressed(or gzipped) file
-viewing. The author of this patch is j...@pobox.com.
+viewing. The author of this p
Re: Remove japanese/jvim and japanese/less
> On Tue, 18 Apr 2017 19:39:15 -0600 > "Anthony J. Bentley" wrote: > > Theo de Raadt writes: > >> May I ask what fucking asshole in Japan decided he should override the > >> license of a 20 year old piece of permissively licensed software because > >> his idiology was more important than the heritage he built on?? > > I misunderstood that less v382 maintained by GNU with GPL. Actually > it is still dual license. I'm sorry about this. > > Also the ja-less distribution itself is keeping the dual license. OK, so it remains 2-term BSD. I think the original has this weird ineffective dual license because someone with a beard cried a lot and made threats. I've seen lots of these kinds of emails. When a 2nd license has restrictions, why would anyone choose it. Like, WTF. Why would they. It is a joke upon choice. If the author actually believed this should be GPL, he would have removed the 2-term BSD, but his software probably would have been replaced by someone else in the community in short order, so he didn't have the balls to do what, and why should he have the balls to do that... instead, he can add GPL to a file and privately laugh at the bearded guy In all cases, I think software should be registered everywhere only as the least restrictive license. (As long as between the two licenses we don't encounter one having a restriction which isn't in the other) 2-term BSD is very permissive. I'm astounded by this situation. Why would anyone choose shackles? The only guy who chooses such shackles is the bearded guy convincing everyone to add this to files he didn't create, and sometimes sign them over to his organization. Obviously that is a scam. The bearded guy is very rich. I invite people to run the numbers.
Re: Remove japanese/jvim and japanese/less
On Tue, 18 Apr 2017 19:39:15 -0600 "Anthony J. Bentley" wrote: > Theo de Raadt writes: >> May I ask what fucking asshole in Japan decided he should override the >> license of a 20 year old piece of permissively licensed software because >> his idiology was more important than the heritage he built on?? I misunderstood that less v382 maintained by GNU with GPL. Actually it is still dual license. I'm sorry about this. Also the ja-less distribution itself is keeping the dual license. --yasuoka
Re: Remove japanese/jvim and japanese/less
> Theo de Raadt writes: > > May I ask what fucking asshole in Japan decided he should override the > > license of a 20 year old piece of permissively licensed software because > > his idiology was more important than the heritage he built on?? > > > > Yes, I said asshole. Let me say it again. SOME ASSHOLE. > > > > To me, anyone who thinks they should be able to do minor changes which > > change a license should have history forget about them. > > > > So I am suggesting this port be removed. > > It is the same license that has been in src/usr.bin/less for at least > 14 years: > > /* > * Copyright (C) 1984-2002 Mark Nudelman > * > * You may distribute under the terms of either the GNU General Public > * License or the Less License, as specified in the README file. > * > * For more information about less, or for information on how to > * contact the author, see the README file. > */ Then the author screwed by by leaving a LICENSE file which has no comment on the GPL In any case, everyone always accepts the least restrictive terms. Maybe we should release OpenSSH or OpenBSD under multiple terms, where the 2nd has such evil terms noone will accept it. Why would anyone ever accept horrible terms? Note that the GPL has no bearing when found next to a ISC or 2 term license. None at all. The GPL restrictions do not apply. They don't apply to anyone. Someone weak willed added that to satisfy some bearded crybaby, and noone got what they wanted.
Re: Remove japanese/jvim and japanese/less
Theo de Raadt writes: > May I ask what fucking asshole in Japan decided he should override the > license of a 20 year old piece of permissively licensed software because > his idiology was more important than the heritage he built on?? > > Yes, I said asshole. Let me say it again. SOME ASSHOLE. > > To me, anyone who thinks they should be able to do minor changes which > change a license should have history forget about them. > > So I am suggesting this port be removed. It is the same license that has been in src/usr.bin/less for at least 14 years: /* * Copyright (C) 1984-2002 Mark Nudelman * * You may distribute under the terms of either the GNU General Public * License or the Less License, as specified in the README file. * * For more information about less, or for information on how to * contact the author, see the README file. */
Re: Remove japanese/jvim and japanese/less
> YASUOKA Masahiko writes: > > For ja-less I'd like to update ja-less to the version maintained by > > Hiroki Sato. I suppose ja-less is relatively popular in japanese > > category. > > > > He created a repo on github and maintaining the version which has all > > related patches for the FreeBSD ports. So I suppose we can maintain > > it by this repo easier than before. > > My big problem with the Japanese ports is that they're old and > effectively unmaintained. So if this one has an upstream, I'm okay > with that. Would be nice if upstream were using a newer version of less, > though... > > Some nits: > > > +COMMENT= Enhanced less with iso-2022-jp and UTF-8 encodings support > > "Enhanced" should be lowercase. > > > -# BSD > > +# GPLv2 > > Looks like it's dual-licensed, GPLv2+ and BSD? May I ask what fucking asshole in Japan decided he should override the license of a 20 year old piece of permissively licensed software because his idiology was more important than the heritage he built on?? Yes, I said asshole. Let me say it again. SOME ASSHOLE. To me, anyone who thinks they should be able to do minor changes which change a license should have history forget about them. So I am suggesting this port be removed.
Re: Remove japanese/jvim and japanese/less
Hi, YASUOKA Masahiko writes: > For ja-less I'd like to update ja-less to the version maintained by > Hiroki Sato. I suppose ja-less is relatively popular in japanese > category. > > He created a repo on github and maintaining the version which has all > related patches for the FreeBSD ports. So I suppose we can maintain > it by this repo easier than before. My big problem with the Japanese ports is that they're old and effectively unmaintained. So if this one has an upstream, I'm okay with that. Would be nice if upstream were using a newer version of less, though... Some nits: > +COMMENT= Enhanced less with iso-2022-jp and UTF-8 encodings support "Enhanced" should be lowercase. > -#BSD > +#GPLv2 Looks like it's dual-licensed, GPLv2+ and BSD? -- Anthony J. Bentley
Re: devel/boost vs. clang
On Tue, Apr 18, 2017 at 08:24:55PM +0200, Christian Weisgerber wrote: > I tried to get boost to build with clang, but failed pretty miserably > because I don't know what I'm doing. > > If anybody wants to look into this, here's what I got: > * Configure with --with-toolset=clang > * Fix boost_has_nl_types_h.ipp, from upstream. > * Some haphazard changes to clang-linux.jam, patterned after those > to gcc.jam. Likely incomplete. > > I got stumped at the first non-trivial problem: > > ./boost/type_traits/is_convertible.hpp:86:63: error: too many arguments > provided to function-like macro invocation > static decltype(test_aux(boost::declval()), one()) > test(int); > ^ > /usr/include/c++/v1/__config:673:11: note: macro 'decltype' defined here > # define decltype(__x) __decltype(__x) > ^ > > As far as I can google, decltype(a, b) is valid, but it fails due > to our macro. FreeBSD somehow doesn't run into this, but I don't > know why. decltype is a built-in starting in C++11. What you have here is compatibility glue happening before C++11.
editors/ht: add openbsd specific elf header types
Add openbsd elf program header types to hte(1).
Patch already accepted upstream.
Mon Apr 17 14:30:33 CEST 2017
/usr/ports/editors/ht
Index: Makefile
===
RCS file: /cvs/ports/editors/ht/Makefile,v
retrieving revision 1.25
diff -u -p -r1.25 Makefile
--- Makefile10 Apr 2017 11:45:27 - 1.25
+++ Makefile17 Apr 2017 12:29:32 -
@@ -3,6 +3,7 @@
COMMENT = file editor/viewer/analyzer for executables
DISTNAME = ht-2.1.0
+REVISION= 0
CATEGORIES = editors
HOMEPAGE = http://hte.sourceforge.net/
Index: patches/patch-elfstruc_h
===
RCS file: patches/patch-elfstruc_h
diff -N patches/patch-elfstruc_h
--- /dev/null 1 Jan 1970 00:00:00 -
+++ patches/patch-elfstruc_h17 Apr 2017 12:17:54 -
@@ -0,0 +1,13 @@
+$OpenBSD$
+--- elfstruc.h.origSun Sep 14 17:55:26 2014
elfstruc.h Mon Apr 17 14:17:39 2017
+@@ -374,6 +374,9 @@ struct ELF_SECTION_HEADER64 {
+ #define ELF_PT_GNU_STACK 0x6474e551 /* Indicates stack executability */
+ #define ELF_PT_GNU_RELRO 0x6474e552 /* Read-only after relocation*/
+ #define ELF_PT_PAX_FLAGS 0x65041580 /* Indicates PaX flag markings */
++#define ELF_PT_OPENBSD_RANDOMIZE 0x65a3dbe6 /* Fill with random data. */
++#define ELF_PT_OPENBSD_WXNEEDED 0x65a3dbe7 /* Program does W^X
violations */
++#define ELF_PT_OPENBSD_BOOTDATA 0x65a41be6 /* Section for boot
arguments */
+
+ struct ELF_PROGRAM_HEADER32 {
+ elf32_word p_type;
Index: patches/patch-htelfphs_cc
===
RCS file: patches/patch-htelfphs_cc
diff -N patches/patch-htelfphs_cc
--- /dev/null 1 Jan 1970 00:00:00 -
+++ patches/patch-htelfphs_cc 17 Apr 2017 12:18:21 -
@@ -0,0 +1,13 @@
+$OpenBSD$
+--- htelfphs.cc.orig Sun Sep 14 17:55:26 2014
htelfphs.ccMon Apr 17 14:17:39 2017
+@@ -67,6 +67,9 @@ static int_hash elf_ph_type[] =
+ {ELF_PT_GNU_STACK, "gnu stack"},
+ {ELF_PT_GNU_RELRO, "gnu relro"},
+ {ELF_PT_PAX_FLAGS, "pax flags"},
++ {ELF_PT_OPENBSD_RANDOMIZE, "openbsd randomize"},
++ {ELF_PT_OPENBSD_WXNEEDED, "openbsd wxneeded"},
++ {ELF_PT_OPENBSD_BOOTDATA, "openbsd bootdata"},
+ {0, 0}
+ };
+
devel/boost vs. clang
I tried to get boost to build with clang, but failed pretty miserably
because I don't know what I'm doing.
If anybody wants to look into this, here's what I got:
* Configure with --with-toolset=clang
* Fix boost_has_nl_types_h.ipp, from upstream.
* Some haphazard changes to clang-linux.jam, patterned after those
to gcc.jam. Likely incomplete.
I got stumped at the first non-trivial problem:
./boost/type_traits/is_convertible.hpp:86:63: error: too many arguments
provided to function-like macro invocation
static decltype(test_aux(boost::declval()), one()) test(int);
^
/usr/include/c++/v1/__config:673:11: note: macro 'decltype' defined here
# define decltype(__x) __decltype(__x)
^
As far as I can google, decltype(a, b) is valid, but it fails due
to our macro. FreeBSD somehow doesn't run into this, but I don't
know why.
Index: Makefile
===
RCS file: /cvs/ports/devel/boost/Makefile,v
retrieving revision 1.61
diff -u -p -r1.61 Makefile
--- Makefile10 Apr 2017 11:45:25 - 1.61
+++ Makefile18 Apr 2017 18:11:22 -
@@ -1,6 +1,8 @@
# $OpenBSD: Makefile,v 1.61 2017/04/10 11:45:25 sthen Exp $
-ONLY_FOR_ARCHS=${GCC4_ARCHS}
+ONLY_FOR_ARCHS=${CLANG_ARCHS} ${GCC4_ARCHS}
+
+DPB_PROPERTIES= parallel
COMMENT= free peer-reviewed portable C++ source libraries
@@ -84,7 +86,7 @@ BOOTSTRAP=--with-bjam=${WRKSRC}/bjam \
--with-python=${MODPY_BIN} \
--with-python-root=${LOCALBASE} \
--with-python-version=${MODPY_VERSION} \
- --with-toolset=gcc \
+ --with-toolset=${TOOLSET} \
--without-icu \
--without-libraries=context,coroutine
@@ -93,8 +95,6 @@ CONFIGURE_STYLE= none
CONFIGURE_ENV= BJAM_CONFIG="${BJAM_CONFIG}" \
CXX="${CXX}" CXXFLAGS="${CXXFLAGS}"
-DPB_PROPERTIES= parallel
-
NO_TEST= Yes
SUBST_VARS+= SO_VERSION
@@ -124,5 +124,14 @@ do-install:
find boost -type d -exec ${INSTALL_DATA_DIR} ${PREFIX}/include/{} \;
@cd ${WRKSRC} && \
find boost ! -name \*.orig -type f -exec ${INSTALL_DATA} {}
${PREFIX}/include/{} \;
+
+.include
+
+# assumes that CC/CXX is not overridden with a different compiler
+.if ${PROPERTIES:Mclang}
+TOOLSET= clang
+.elif ${PROPERTIES:Mgcc4}
+TOOLSET= gcc
+.endif
.include
Index: patches/patch-libs_config_test_boost_has_nl_types_h_ipp
===
RCS file: patches/patch-libs_config_test_boost_has_nl_types_h_ipp
diff -N patches/patch-libs_config_test_boost_has_nl_types_h_ipp
--- /dev/null 1 Jan 1970 00:00:00 -
+++ patches/patch-libs_config_test_boost_has_nl_types_h_ipp 18 Apr 2017
18:11:22 -
@@ -0,0 +1,12 @@
+$OpenBSD$
+--- libs/config/test/boost_has_nl_types_h.ipp.orig Tue Mar 24 19:27:48 2015
libs/config/test/boost_has_nl_types_h.ipp Tue Apr 18 16:02:33 2017
+@@ -17,7 +17,7 @@ namespace boost_has_nl_types_h{
+ int test()
+ {
+nl_catd cat = catopen("foo", 0);
+- if(cat >= 0) catclose(cat);
++ if(cat != (nl_catd)-1) catclose(cat);
+return 0;
+ }
+
Index: patches/patch-tools_build_src_tools_clang-linux_jam
===
RCS file: patches/patch-tools_build_src_tools_clang-linux_jam
diff -N patches/patch-tools_build_src_tools_clang-linux_jam
--- /dev/null 1 Jan 1970 00:00:00 -
+++ patches/patch-tools_build_src_tools_clang-linux_jam 18 Apr 2017 18:11:22
-
@@ -0,0 +1,31 @@
+$OpenBSD$
+--- tools/build/src/tools/clang-linux.jam.orig Sat Apr 4 19:25:07 2015
tools/build/src/tools/clang-linux.jam Tue Apr 18 16:29:59 2017
+@@ -70,7 +70,7 @@ toolset.flags clang-linux.compile OPTIONS ;
+ toolset.flags clang-linux.compile.c++ OPTIONS ;
+
+ toolset.flags clang-linux.compile OPTIONS off : ;
+-toolset.flags clang-linux.compile OPTIONS speed : -O3 ;
++toolset.flags clang-linux.compile OPTIONS speed : ;
+ toolset.flags clang-linux.compile OPTIONS space : -Os ;
+
+ # note: clang silently ignores some of these inlining options
+@@ -180,6 +180,7 @@ rule link ( targets * : sources * : properties * ) {
+ }
+
+ actions link bind LIBRARIES {
++echo "$(CONFIG_COMMAND)" -L"$(LINKPATH)" -Wl,-R$(SPACE)-Wl,"$(RPATH)"
-Wl,-rpath-link$(SPACE)-Wl,"$(RPATH_LINK)" -o "$(<)" $(START-GROUP) "$(>)"
"$(LIBRARIES)" $(FINDLIBS-ST-PFX) -l$(FINDLIBS-ST) $(FINDLIBS-SA-PFX)
-l$(FINDLIBS-SA) $(END-GROUP) $(OPTIONS) $(USER_OPTIONS)
+ "$(CONFIG_COMMAND)" -L"$(LINKPATH)" -Wl,-R$(SPACE)-Wl,"$(RPATH)"
-Wl,-rpath-link$(SPACE)-Wl,"$(RPATH_LINK)" -o "$(<)" $(START-GROUP) "$(>)"
"$(LIBRARIES)" $(FINDLIBS-ST-PFX) -l$(FINDLIBS-ST) $(FINDLIBS-SA-PFX)
-l$(FINDLIBS-SA) $(END-GROUP) $(OPTIONS) $(USER_OPTIONS)
+ }
+
+@@ -207,8 +208,8 @@ rule setup-threading ( targets * : sources * : propert
+ }
+
Re: [UPDATE] korean/libhangul 0.1.0
Jeremie Courreges-Anglas writes: > Nils Reuße writes: > >> On 04/13/2017 08:28 PM, Jeremie Courreges-Anglas wrote: >>> Nils Reuße writes: >>> In an attempt to write some hangul on OpenBSD, i updated some ports ;) Here is an update for libhangul. Included is an upstream patch [1], which i found while checking the freebsd port. Alongside goes a new port ibus-hangul (please see my other mail). I bumped the major lib version to 1, because that's what ibus-hangul expects. Any comments? >>> >>> Your diff was mangled (tab->spaces + some line wraps); don't copy/paste >>> diffs, better "include" them if your MUA supports that, or send them as >>> attachments. >>> >>> Note that the shared lib version should be have a major bump because >>> several symbols have been removed, not because that's what ibus-hangul >>> expects. See >>> >>> https://www.openbsd.org/faq/ports/specialtopics.html#SharedLibs >>> >>> Here's a reworked diff with the following changes: >>> - work around the tarball naming using DISTFILES >>> - don't use the gettext module (which should probably be marked as >>> deprecated) >>> >>> >> >> Hi Jeremie, >> >> thanks for looking into it! I had never heard of DISTFILES before, the >> Makefile looks much better now ;) And thanks for your explanations, >> they're much appreciated. > > Sure. Looks like scim-hangul is still happy at build time with the > updated libhangul; and looks like scim-hangul works fine says ktrace(1), > I guess this libhangul update could go in. If someone that uses scim > could confirm that scim-hangul still works, that would be great. :) No report, but I've committed this anyway. Thanks! -- jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF DDCC 0DFA 74AE 1524 E7EE
Re: amd64-clang port build failures
The amd64 and i386 base snapshots now include clang. You don't need to worry how to install clang, just install a snapshot! -- Christian "naddy" Weisgerber na...@mips.inka.de
Chromium with kerberos
Hi,
does OpenBSD chromium work with heimdal in ports?
I found following part in Chromium code
https://github.com/adobe/chromium/blob/master/net/net.gyp#L800
which makes me doubtful.
...
['use_kerberos==1', {
'defines': [
'USE_KERBEROS',
],
'conditions': [
['OS=="openbsd"', {
'include_dirs': [
'/usr/include/kerberosV'
],
}],
...
And if it does work, do I have to put '--auth-server-whitelist=.example.com'
as cmd option?
j.
Re: UPDATE: graphics/nomacs
On 2017/04/18 12:41, Rafael Sadowski wrote: > Hi All, > > here is an update for nomacs. Tested @amd64. Shared lib major needs a bump. Otherwise OK. Funny looking at the first line of pkg/DESCR and the SIZE line in distinfo though!
Re: UPDATE: graphics/slop
On 2017/04/18 12:36, Rafael Sadowski wrote:
> On Fri Apr 14, 2017 at 09:48:55AM +0100, Stuart Henderson wrote:
> > Iirc our cmake creates files with .so and no version if you don't specify
> > SHARED_LIBS. Try setting that for the shared libraries name (version 0.0)
> > and rebuild/regen plist.
> > >
> > > Is this a module, or a shared library? The cmake config seems to
> > > specify a library, but doesn't specify a version.
> > >
> > > If it should be installed, it should have a version. Something like:
> > >
> > > SHARED_LIBS = slopy 0.0 # ?
> > >
> > > > +@man man/man1/slop.1
> > >
>
> Sorry, totally overlooked. New diff should be fine. Please, also look at
> the maim diff too.
Same comment as for maim with DISTNAME / V / GH_TAGNAME. Otherwise ok.
> ===
> RCS file: /cvs/ports/graphics/slop/Makefile,v
> retrieving revision 1.10
> diff -u -p -u -p -r1.10 Makefile
> --- Makefile 10 Apr 2017 11:46:21 - 1.10
> +++ Makefile 18 Apr 2017 10:06:01 -
> @@ -1,21 +1,33 @@
> # $OpenBSD: Makefile,v 1.10 2017/04/10 11:46:21 sthen Exp $
>
> -V = 4.1.16
> +V = 5.3.37
> COMMENT =query for a selection and print to stdout (select operation)
> DISTNAME = slop-${V}
> CATEGORIES = graphics x11
> -REVISION = 0
>
> GH_ACCOUNT = naelstrof
> GH_PROJECT = slop
> GH_TAGNAME = v${V}
>
> +SHARED_LIBS = slopy 0.0 # 0.0
> +
> +MAINTAINER = Rafael Sadowski
> +
> # GPLv3+
> PERMIT_PACKAGE_CDROM = Yes
>
> -WANTLIB += ICE SM X11 Xext c m ${LIBCXX}
> +WANTLIB += GL GLU ICE SM X11 Xext Xrender c m pthread ${LIBCXX}
> +
> +MODULES =devel/cmake \
> + gcc4
> +
> +MODGCC4_LANGS = c++
> +MODGCC4_ARCHS = ${GCC3_ARCHS} ${GCC4_ARCHS}
> +
> +BUILD_DEPENDS += graphics/glm
>
> -MODULES =devel/cmake
> +CONFIGURE_ARGS +=-DCMAKE_INSTALL_MANDIR="${LOCALBASE}/man" \
> + -DCMAKE_COMPRESS_MAN:BOOL=Off
>
> NO_TEST =Yes
>
> Index: distinfo
> ===
> RCS file: /cvs/ports/graphics/slop/distinfo,v
> retrieving revision 1.5
> diff -u -p -u -p -r1.5 distinfo
> --- distinfo 21 Apr 2015 02:07:38 - 1.5
> +++ distinfo 18 Apr 2017 10:06:01 -
> @@ -1,2 +1,2 @@
> -SHA256 (slop-4.1.16.tar.gz) = wp8MzbKLxYfJFOmfo/qgmyE129UZp1thSP2kLEFX6Rg=
> -SIZE (slop-4.1.16.tar.gz) = 35997
> +SHA256 (slop-5.3.37.tar.gz) = OhZW+MzFOrWixv/glYk7Bc9Qo7pdM4V+z0jOP0SAUdw=
> +SIZE (slop-5.3.37.tar.gz) = 68182
> Index: pkg/PLIST
> ===
> RCS file: /cvs/ports/graphics/slop/pkg/PLIST,v
> retrieving revision 1.1.1.1
> diff -u -p -u -p -r1.1.1.1 PLIST
> --- pkg/PLIST 16 Nov 2014 16:48:56 - 1.1.1.1
> +++ pkg/PLIST 18 Apr 2017 10:06:01 -
> @@ -1,2 +1,5 @@
> @comment $OpenBSD: PLIST,v 1.1.1.1 2014/11/16 16:48:56 bcallah Exp $
> @bin bin/slop
> +include/slop.hpp
> +@lib lib/libslopy.so.${LIBslopy_VERSION}
> +@man man/man1/slop.1
>
Re: UPDATE: graphics/maim
On 2017/04/18 12:38, Rafael Sadowski wrote:
> RCS file: /cvs/ports/graphics/maim/Makefile,v
> retrieving revision 1.13
> diff -u -p -u -p -r1.13 Makefile
> --- Makefile 10 Apr 2017 11:46:21 - 1.13
> +++ Makefile 18 Apr 2017 10:37:32 -
> @@ -1,25 +1,31 @@
> # $OpenBSD: Makefile,v 1.13 2017/04/10 11:46:21 sthen Exp $
>
> -V = 3.4.43
> +V = 4.4.62
> COMMENT =desktop screenshot utility (make image)
> DISTNAME = maim-${V}
> CATEGORIES = graphics x11
> -REVISION = 0
>
> GH_ACCOUNT = naelstrof
> GH_PROJECT = maim
> GH_TAGNAME = v${V}
DISTNAME and V aren't needed; just use GH_TAGNAME=v4.4.62
Rest looks OK.
UPDATE: graphics/nomacs
Hi All, here is an update for nomacs. Tested @amd64. Best regards, Rafael Sadowski Index: Makefile === RCS file: /cvs/ports/graphics/nomacs/Makefile,v retrieving revision 1.6 diff -u -p -u -p -r1.6 Makefile --- Makefile25 Mar 2017 08:39:51 - 1.6 +++ Makefile18 Apr 2017 10:38:59 - @@ -4,13 +4,13 @@ COMMENT = small and fast Qt image viewe GH_ACCOUNT = nomacs GH_PROJECT = nomacs -GH_TAGNAME = 3.6.0 +GH_TAGNAME = 3.6.1 CATEGORIES = graphics HOMEPAGE = http://www.nomacs.org -MAINTAINER = Rafael Sadowski +MAINTAINER = Rafael Sadowski SHARED_LIBS += nomacsCore1.0 # 3.3 Index: distinfo === RCS file: /cvs/ports/graphics/nomacs/distinfo,v retrieving revision 1.4 diff -u -p -u -p -r1.4 distinfo --- distinfo25 Mar 2017 08:39:51 - 1.4 +++ distinfo18 Apr 2017 10:38:59 - @@ -1,2 +1,2 @@ -SHA256 (nomacs-3.6.0.tar.gz) = bViYtR1iDA3keQ6bB4vSxSfGIBLRAMqEmjfOdO+ivVQ= -SIZE (nomacs-3.6.0.tar.gz) = 29493578 +SHA256 (nomacs-3.6.1.tar.gz) = CbKJysUaX9zMAqpKYEBbu9S1v9trKlLKWwyzsPeocGg= +SIZE (nomacs-3.6.1.tar.gz) = 28604636
Re: UPDATE: graphics/maim
On Thu Apr 13, 2017 at 06:58:48PM +0200, Rafael Sadowski wrote:
> On Wed Apr 05, 2017 at 10:30:13PM +0200, Rafael Sadowski wrote:
> > *ping*
> >
> > On Sat Feb 25, 2017 at 10:17:07AM +0100, Rafael Sadowski wrote:
> > > Hi All,
> > >
> > > straightforward patch to 4.4.47. maim drops imlib2 dependence and switch
> > > to C++11. Tested on and64.
> > >
> > > Regards,
> > >
> > > Rafael Sadowski
> > >
>
> Please find a new diff blow to update maim. Changes to previous diff:
>
> - update to 4.4.62
> - take MAINTAINER
> - add slop as BUILD_DEPENDS
>
> OK? Comments?
>
New diff below.
Best regards,
Rafael
Index: Makefile
===
RCS file: /cvs/ports/graphics/maim/Makefile,v
retrieving revision 1.13
diff -u -p -u -p -r1.13 Makefile
--- Makefile10 Apr 2017 11:46:21 - 1.13
+++ Makefile18 Apr 2017 10:37:32 -
@@ -1,25 +1,31 @@
# $OpenBSD: Makefile,v 1.13 2017/04/10 11:46:21 sthen Exp $
-V =3.4.43
+V =4.4.62
COMMENT = desktop screenshot utility (make image)
DISTNAME = maim-${V}
CATEGORIES = graphics x11
-REVISION = 0
GH_ACCOUNT = naelstrof
GH_PROJECT = maim
GH_TAGNAME = v${V}
+MAINTAINER = Rafael Sadowski
+
# GPLv3+
PERMIT_PACKAGE_CDROM = Yes
-WANTLIB += ICE Imlib2 SM X11 Xext Xfixes Xrandr c m ${LIBCXX}
+WANTLIB += GL ICE SM X11 Xext Xfixes Xrandr c jpeg m png pthread
+WANTLIB += slopy z ${LIBCXX}
-MODULES = devel/cmake
+MODULES = devel/cmake \
+ gcc4
-LIB_DEPENDS = graphics/imlib2
+MODGCC4_LANGS =c++
+MODGCC4_ARCHS =${GCC3_ARCHS} ${GCC4_ARCHS}
-RUN_DEPENDS = graphics/slop
+LIB_DEPENDS += graphics/jpeg \
+ graphics/png \
+ graphics/slop
CONFIGURE_ARGS = -DCMAKE_INSTALL_MANDIR="${LOCALBASE}/man" \
-DCMAKE_COMPRESS_MAN=False
Index: distinfo
===
RCS file: /cvs/ports/graphics/maim/distinfo,v
retrieving revision 1.8
diff -u -p -u -p -r1.8 distinfo
--- distinfo23 Jun 2015 01:45:34 - 1.8
+++ distinfo18 Apr 2017 10:37:32 -
@@ -1,2 +1,2 @@
-SHA256 (maim-3.4.43.tar.gz) = 6i8st7Sqjw6cdG9OFCNjzq9olqoDaPMbrM/w9lpbW2s=
-SIZE (maim-3.4.43.tar.gz) = 43670
+SHA256 (maim-4.4.62.tar.gz) = Ie+E/hwc3vgtycwfc0Ym+Dnwwo/X6JjDjJiqmKheliI=
+SIZE (maim-4.4.62.tar.gz) = 36391
Re: UPDATE: graphics/slop
On Fri Apr 14, 2017 at 09:48:55AM +0100, Stuart Henderson wrote:
> Iirc our cmake creates files with .so and no version if you don't specify
> SHARED_LIBS. Try setting that for the shared libraries name (version 0.0)
> and rebuild/regen plist.
> >
> > Is this a module, or a shared library? The cmake config seems to
> > specify a library, but doesn't specify a version.
> >
> > If it should be installed, it should have a version. Something like:
> >
> > SHARED_LIBS = slopy 0.0 # ?
> >
> > > +@man man/man1/slop.1
> >
Sorry, totally overlooked. New diff should be fine. Please, also look at
the maim diff too.
Best regards,
Rafael
Index: Makefile
===
RCS file: /cvs/ports/graphics/slop/Makefile,v
retrieving revision 1.10
diff -u -p -u -p -r1.10 Makefile
--- Makefile10 Apr 2017 11:46:21 - 1.10
+++ Makefile18 Apr 2017 10:06:01 -
@@ -1,21 +1,33 @@
# $OpenBSD: Makefile,v 1.10 2017/04/10 11:46:21 sthen Exp $
-V =4.1.16
+V =5.3.37
COMMENT = query for a selection and print to stdout (select operation)
DISTNAME = slop-${V}
CATEGORIES = graphics x11
-REVISION = 0
GH_ACCOUNT = naelstrof
GH_PROJECT = slop
GH_TAGNAME = v${V}
+SHARED_LIBS = slopy 0.0 # 0.0
+
+MAINTAINER = Rafael Sadowski
+
# GPLv3+
PERMIT_PACKAGE_CDROM = Yes
-WANTLIB += ICE SM X11 Xext c m ${LIBCXX}
+WANTLIB += GL GLU ICE SM X11 Xext Xrender c m pthread ${LIBCXX}
+
+MODULES = devel/cmake \
+ gcc4
+
+MODGCC4_LANGS =c++
+MODGCC4_ARCHS =${GCC3_ARCHS} ${GCC4_ARCHS}
+
+BUILD_DEPENDS += graphics/glm
-MODULES = devel/cmake
+CONFIGURE_ARGS += -DCMAKE_INSTALL_MANDIR="${LOCALBASE}/man" \
+ -DCMAKE_COMPRESS_MAN:BOOL=Off
NO_TEST = Yes
Index: distinfo
===
RCS file: /cvs/ports/graphics/slop/distinfo,v
retrieving revision 1.5
diff -u -p -u -p -r1.5 distinfo
--- distinfo21 Apr 2015 02:07:38 - 1.5
+++ distinfo18 Apr 2017 10:06:01 -
@@ -1,2 +1,2 @@
-SHA256 (slop-4.1.16.tar.gz) = wp8MzbKLxYfJFOmfo/qgmyE129UZp1thSP2kLEFX6Rg=
-SIZE (slop-4.1.16.tar.gz) = 35997
+SHA256 (slop-5.3.37.tar.gz) = OhZW+MzFOrWixv/glYk7Bc9Qo7pdM4V+z0jOP0SAUdw=
+SIZE (slop-5.3.37.tar.gz) = 68182
Index: pkg/PLIST
===
RCS file: /cvs/ports/graphics/slop/pkg/PLIST,v
retrieving revision 1.1.1.1
diff -u -p -u -p -r1.1.1.1 PLIST
--- pkg/PLIST 16 Nov 2014 16:48:56 - 1.1.1.1
+++ pkg/PLIST 18 Apr 2017 10:06:01 -
@@ -1,2 +1,5 @@
@comment $OpenBSD: PLIST,v 1.1.1.1 2014/11/16 16:48:56 bcallah Exp $
@bin bin/slop
+include/slop.hpp
+@lib lib/libslopy.so.${LIBslopy_VERSION}
+@man man/man1/slop.1
Re: dpb runs three parallel processes on 2 CPUs
On Mon, Apr 17, 2017 at 08:04:51PM +, Christian Weisgerber wrote: > On 2017-04-13, Andreas Kusalananda Kähäri wrote: > > > I have 2 CPUs, and dpb usually builds two ports at a time (or one port > > in parallel). However, while rebuilding llvm and ghc I observed that > > ghc was being built as one job while llvm clearly used a parallel build > > with two jobs at the same time. > > Yes, that can happen. > > > If dpb is allowed to do a parallel build of a package, does that mean > > that it'll do that regardless of whether another build is running? > > Yes. The assumption is that the other build will finish soon, and > that usually happens when building the full ports tree and on > machines with four or more cores. Ah. > > > How should I interpret the '1*'? > > The number of build slots occupied. > Your machine has 2 build slots, occupied by ghc and 1*llvm. If ghc > finished ahead of llvm, you will see 2*llvm: llvm occupies both slots > and no new jobs are started until it has finished. > > Here's a snapshot from a setup of three machines times four cores: > > 17 Apr 14:02:29 [93925] running for 00:26:31 > 2*lang/gcc/4.9(build) [9292] on amd64-1 17% > 2*devel/boost(build) [71601] 33% > 2*devel/cmake(build) [96529] 27% > 2*graphics/cairo(build) [27962] on amd64-1 66% > lang/vala(build) [90156] on amd64-2 41% > www/libcroco(build) [26311] on amd64-2 39% > misc/gpsd(build) [14547] on amd64-2 21% > ~productivity/tryton/timesheet_cost(package) [5212] on amd64-2 27% > Hosts: amd64-1 [63886] amd64-2 [16323] localhost > I=636 B=194 Q=3986 T=5425 F=0 !=93 I was thinking dpb kept track of number of cores used in the build, but it uses job slots, and some of the jobs may be parallel. Ok. > > > This might have been the result of unlucky scheduling on dpb's part as > > both ports take a really long time to build... > > Exactly. > > -- > Christian "naddy" Weisgerber na...@mips.inka.de > > Thanks for the explanation! Regards, Kusalananda
