Port removals
I would like to remove the following ports because they are either no longer maintained upstream or are no longer required by any other ports Any objections? oks? editors/se lang/mlite mail/lumail net/clamz net/p5-Net-Abuse-Utils-Spamhaus I maintain/ported all the above. I would also like to drop maintainership on the following if anyone would like to take over: mail/mimetic mail/trojita sysutils/sslmate -- James Turner
UPDATE: WIP vim with gtk3
here is an update to the vim port.
- some patches were merged upstream
- converted gvim.desktop to patch
- updated descriptions
- added a WIP gtk3 flavor. it builds, but PFRAG
is over my head... if a guru could finish the
plumbing i think it could work. if not, i can
just resend the diff without the gtk3 bits.
please test and commit.
-f
--
he's teflon brain (nothing sticks).
Index: Makefile
===
RCS file: /cvs/ports/editors/vim/Makefile,v
retrieving revision 1.149
diff -u -p -r1.149 Makefile
--- Makefile29 May 2016 12:26:23 - 1.149
+++ Makefile8 Aug 2016 00:57:56 -
@@ -3,12 +3,11 @@
COMMENT-main= vi clone, many additional features
COMMENT-lang= vi clone, NLS subpackage
-V= 7.4.1467
+V= 7.4.2181
DISTNAME= vim-$V
DISTFILES= vim-$V{v$V}.tar.gz
PKGNAME-main= vim-$V
PKGNAME-lang= vim-lang-$V
-REVISION-main= 1
P= vim${V:R:S/.//}
CATEGORIES=editors
MASTER_SITES= https://github.com/vim/vim/archive/
@@ -25,7 +24,7 @@ MULTI_PACKAGES= -main -lang
FULLPKGNAME-lang= vim-lang-$V
FULLPKGPATH-lang= ${PKGPATH},-lang
-FLAVORS= huge gtk2 athena motif no_x11 lua perl python python3 ruby
+FLAVORS= huge gtk2 gtk3 athena motif no_x11 lua perl python python3 ruby
FLAVOR?= gtk2
.include
@@ -134,8 +133,24 @@ WANTLIB += Xi Xinerama Xpm Xrandr Xrende
WANTLIB += fontconfig freetype gdk-x11-2.0 gdk_pixbuf-2.0 gio-2.0
WANTLIB += glib-2.0 gobject-2.0 gtk-x11-2.0 m pango-1.0 pangocairo-1.0
WANTLIB += pangoft2-1.0 pthread z
+.elif ${FLAVOR:Mgtk3} && \
+ !${FLAVOR:Mgtk2} && !${FLAVOR:Mmotif} && !${FLAVOR:Mno_x11} &&
!${FLAVOR:Mathena}
+MAKE_FLAGS+= 'LDFLAGS=-pthread'
+MAKE_FLAGS+= 'CFLAGS=-pthread'
+LIB_DEPENDS+= x11/gtk+3
+CONFIGURE_ARGS+= --enable-gui="gtk3" \
+ --disable-gtk-check \
+ --disable-gtk2-check \
+ --enable-fontset \
+ --enable-xim \
+ --with-x
+WANTLIB += ICE SM X11 Xcomposite Xcursor Xdamage Xdmcp Xext Xfixes
+WANTLIB += Xi Xinerama Xpm Xrandr Xrender Xt atk-1.0 cairo
+WANTLIB += fontconfig freetype gdk-3 gdk_pixbuf-2.0 gio-2.0
+WANTLIB += glib-2.0 gobject-2.0 gtk-3 m pango-1.0 pangocairo-1.0
+WANTLIB += pangoft2-1.0 pthread z
.else
-ERRORS="Fatal: You must select one GUI interface: no_x11,
gtk2, athena or motif"
+ERRORS="Fatal: You must select one GUI interface: no_x11,
gtk2, gtk3, athena or motif"
.endif
RUN_DEPENDS-lang= editors/vim,-main
@@ -157,11 +172,11 @@ post-configure:
post-install:
${INSTALL_DATA_DIR} ${PREFIX}/share/vim/vimfiles/{doc,syntax}
${INSTALL_DATA} ${FILESDIR}/openbsd.vim \
- ${PREFIX}/share/vim/vimfiles/syntax/
+ ${PREFIX}/share/vim/vimfiles/syntax/
.if ! ${FLAVOR:Mno_x11}
${INSTALL_DATA_DIR} ${PREFIX}/share/applications
- ${SUBST_DATA} ${FILESDIR}/gvim.desktop \
+ ${SUBST_DATA} ${WRKDIST}/runtime/gvim.desktop \
${PREFIX}/share/applications/gvim.desktop
${INSTALL_DATA_DIR} ${PREFIX}/share/pixmaps
${INSTALL_DATA} ${WRKDIST}/runtime/vim48x48.png
${PREFIX}/share/pixmaps/vim.png
Index: distinfo
===
RCS file: /cvs/ports/editors/vim/distinfo,v
retrieving revision 1.47
diff -u -p -r1.47 distinfo
--- distinfo2 Mar 2016 11:54:28 - 1.47
+++ distinfo8 Aug 2016 00:57:56 -
@@ -1,2 +1,2 @@
-SHA256 (vim-7.4.1467.tar.gz) = d2HUWbUlc7JT0+lEb3L2H7LgAAuZMoAzL6DS6kKRlq0=
-SIZE (vim-7.4.1467.tar.gz) = 12532588
+SHA256 (vim-7.4.2181.tar.gz) = cT2WPgz34CwxNfK531Urmvh+tyFXavtXmx4QoS2ZFlg=
+SIZE (vim-7.4.2181.tar.gz) = 12854298
Index: files/gvim.desktop
===
RCS file: files/gvim.desktop
diff -N files/gvim.desktop
--- files/gvim.desktop 16 Dec 2013 10:19:34 - 1.1
+++ /dev/null 1 Jan 1970 00:00:00 -
@@ -1,80 +0,0 @@
-[Desktop Entry]
-Name=GVim
-GenericName=Text Editor
-GenericName[de]=Texteditor
-Comment=Edit text files
-Comment[af]=Redigeer tekslêers
-Comment[am]=የጽሑፍ ፋይሎች ያስተካክሉ
-Comment[ar]=حرّر ملفات نصية
-Comment[az]=Mətn fayllarını redaktə edin
-Comment[be]=Рэдагаваньне тэкставых файлаў
-Comment[bg]=Редактиране на текстови файлове
-Comment[bn]=টেক্স্ট ফাইল এডিট করুন
-Comment[bs]=Izmijeni tekstualne datoteke
-Comment[ca]=Edita fitxers de text
-Comment[cs]=Úprava textových souborů
-Comment[cy]=Golygu ffeiliau testun
-Comment[da]=Redigér tekstfiler
-Comment[de]=Textdateien bearbeiten
-Comment[el]=Επεξεργασία αρχείων κειμένου
-Comment[en_CA]=Edit text files
-Comment[en_GB]=Edit text files
-Comment[es]=Edita archivos de texto
-Comment[et]=Redigeeri tekstifaile
-Comment[eu]=Editatu testu-fitxategiak
-Comment[fa]=ویرایش پروندههای متنی
-Comment[fi]=Muokkaa tekstitiedostoja
-Comment[fr]=Édite des fichiers texte
-Comment[ga]=Eagar comhad Téacs
-Commen
Re: The W^X situation: we need wxneeded
> What should be done for ports like (just for example) calibre? > It uses python, and uses PyQtWebkit to pull in Qt5Webkit which maps WX > for its jit. Python itself doesn't need wxneeded but for calibre (and > possibly other ports) to work it will. The enforcement mechanism follows programs -- not libraries. If a program does the violation, mark it.
Re: The W^X situation: we need wxneeded
On Sun, Aug 07, 2016 at 10:20:50PM +0200, Christian Weisgerber wrote: > OpenBSD is increasingly mandating W^X. What does that mean? Memory > can either be mapped writable, or it can be executable, but not > both (Write xor eXecute). This is a security concern. Without > W^X, an attacker can load their own code into memory and then execute > it. W^X protects against this. > > Unfortunately there is important third-party code, such as just-in-time > compilers, that still uses mmap(2) to make memory both writable and > executable, so for the time being, we have to arrange ourselves > with it. > > For a binary to be allowed to violate W^X, it must > (1) reside on a filesystem that is mounted with the "wxallowed" > flag (the installer enables this for /usr/local); > (2) be annotated with PT_OPENBSD_WXNEEDED at the ELF level. > > So far, only (1) is strictly enforced and any program in violation > is terminated at once. > > For (2), the W^X violation is logged (dmesg, syslog). In recent > snapshots, the offending mmap() call has also begun to return an > error. Alas, many programs don't handle this failure gracefully > and crash. > > Now, obviously getting rid of W^X violations has to be the end goal, > but that will take time and effort. In the meantime, offenders > *MUST* be marked wxneeded. This is done by linking the executable > with "ld -z wxneeded". When linking is performed through cc, which > is the usual case, you add "-Wl,-z,wxneeded" to the linking command > line. That's it. > > Currently only four affected ports are marked wxneeded. More will > need this. Please, when you see a port throwing "foo(4711): W^X > violation" log messages, look into adding wxneeded. > > We can draw up a list of affected ports, but it isn't exactly hard > to notice. Some ports already need wxneeded to build. Presumably > there are a few others where it will only show up at run time. > > This is important. The W^X hammer is coming down and without > wxneeded annotations you will find that a number of your favorite > programs (e.g. everything Mozilla) will no longer run. > What should be done for ports like (just for example) calibre? It uses python, and uses PyQtWebkit to pull in Qt5Webkit which maps WX for its jit. Python itself doesn't need wxneeded but for calibre (and possibly other ports) to work it will. -- Carlin
Re: The W^X situation: we need wxneeded
On Sun, Aug 07, 2016 at 10:20:50PM +0200, Christian Weisgerber wrote: > OpenBSD is increasingly mandating W^X. What does that mean? Memory > can either be mapped writable, or it can be executable, but not > both (Write xor eXecute). This is a security concern. Without > W^X, an attacker can load their own code into memory and then execute > it. W^X protects against this. > > Unfortunately there is important third-party code, such as just-in-time > compilers, that still uses mmap(2) to make memory both writable and > executable, so for the time being, we have to arrange ourselves > with it. > > For a binary to be allowed to violate W^X, it must > (1) reside on a filesystem that is mounted with the "wxallowed" > flag (the installer enables this for /usr/local); > (2) be annotated with PT_OPENBSD_WXNEEDED at the ELF level. > > So far, only (1) is strictly enforced and any program in violation > is terminated at once. > > For (2), the W^X violation is logged (dmesg, syslog). In recent > snapshots, the offending mmap() call has also begun to return an > error. Alas, many programs don't handle this failure gracefully > and crash. > > Now, obviously getting rid of W^X violations has to be the end goal, > but that will take time and effort. In the meantime, offenders > *MUST* be marked wxneeded. This is done by linking the executable > with "ld -z wxneeded". When linking is performed through cc, which > is the usual case, you add "-Wl,-z,wxneeded" to the linking command > line. That's it. > > Currently only four affected ports are marked wxneeded. More will > need this. Please, when you see a port throwing "foo(4711): W^X > violation" log messages, look into adding wxneeded. > > We can draw up a list of affected ports, but it isn't exactly hard > to notice. Some ports already need wxneeded to build. Presumably > there are a few others where it will only show up at run time. > > This is important. The W^X hammer is coming down and without > wxneeded annotations you will find that a number of your favorite > programs (e.g. everything Mozilla) will no longer run. Free ok coupons to whoever wants to fix 'everything Mozilla' by applying the necessary knob/bandaid like a sir. I wont have time nor interest to look into this before g2k16. Landry
The W^X situation: we need wxneeded
OpenBSD is increasingly mandating W^X. What does that mean? Memory can either be mapped writable, or it can be executable, but not both (Write xor eXecute). This is a security concern. Without W^X, an attacker can load their own code into memory and then execute it. W^X protects against this. Unfortunately there is important third-party code, such as just-in-time compilers, that still uses mmap(2) to make memory both writable and executable, so for the time being, we have to arrange ourselves with it. For a binary to be allowed to violate W^X, it must (1) reside on a filesystem that is mounted with the "wxallowed" flag (the installer enables this for /usr/local); (2) be annotated with PT_OPENBSD_WXNEEDED at the ELF level. So far, only (1) is strictly enforced and any program in violation is terminated at once. For (2), the W^X violation is logged (dmesg, syslog). In recent snapshots, the offending mmap() call has also begun to return an error. Alas, many programs don't handle this failure gracefully and crash. Now, obviously getting rid of W^X violations has to be the end goal, but that will take time and effort. In the meantime, offenders *MUST* be marked wxneeded. This is done by linking the executable with "ld -z wxneeded". When linking is performed through cc, which is the usual case, you add "-Wl,-z,wxneeded" to the linking command line. That's it. Currently only four affected ports are marked wxneeded. More will need this. Please, when you see a port throwing "foo(4711): W^X violation" log messages, look into adding wxneeded. We can draw up a list of affected ports, but it isn't exactly hard to notice. Some ports already need wxneeded to build. Presumably there are a few others where it will only show up at run time. This is important. The W^X hammer is coming down and without wxneeded annotations you will find that a number of your favorite programs (e.g. everything Mozilla) will no longer run. -- Christian "naddy" Weisgerber na...@mips.inka.de
Re: Chromium browser package doesn't exist
On 2016-08-06, Lampshade wrote: > I have upgraded my system (amd64) from snapshot today and it seems > that chromium browser package is not available. pkg_add -u said: > Couldn't find updates for chromium-51.0.2704.106 > > However http://openports.se/www/chromium tells that port still exists. Yes, it didn't build. The chromium build is very fragile and keeps breaking. -- Christian "naddy" Weisgerber na...@mips.inka.de
Re: thunderbird segfault: mmap W^X violation
On Sun, Aug 07, 2016 at 03:10:48PM +0200, Martin Natano wrote: > On Sun, Aug 07, 2016 at 01:43:08PM +0200, Peter N. M. Hansteen wrote: > > > > /var/log/messages reports > > > > Aug 7 13:34:27 elke /bsd: thunderbird(10425): mmap W^X violation > > You will need the wxallowed mount option on /usr/local as long as you > use ports that map w|x pages. See > http://www.openbsd.org/faq/upgrade60.html. I have that already, so I was a bit surprised that thunderbird stopped working yet again: [Sun Aug 07 13:41:09] peter@elke:~$ mount /dev/sd1a on / type ffs (local) /dev/sd1d on /tmp type ffs (local, nodev, nosuid) /dev/sd1f on /usr type ffs (local, nodev) /dev/sd1g on /usr/X11R6 type ffs (local, nodev) /dev/sd1h on /usr/local type ffs (local, nodev, wxallowed) /dev/sd1j on /usr/obj type ffs (local, nodev, nosuid) /dev/sd1i on /usr/src type ffs (local, nodev, nosuid) /dev/sd1e on /var type ffs (local, nodev, nosuid) /dev/sd0d on /home type ffs (local, nodev, nosuid) Well, I guess mutt will do for now ;) - Peter -- Peter N. M. Hansteen, member of the first RFC 1149 implementation team http://bsdly.blogspot.com/ http://www.bsdly.net/ http://www.nuug.no/ "Remember to set the evil bit on all malicious network traffic" delilah spamd[29949]: 85.152.224.147: disconnected after 42673 seconds.
Re: thunderbird segfault: mmap W^X violation
> Date: Sun, 7 Aug 2016 15:10:48 +0200 > From: Martin Natano > > On Sun, Aug 07, 2016 at 01:43:08PM +0200, Peter N. M. Hansteen wrote: > > > > /var/log/messages reports > > > > Aug 7 13:34:27 elke /bsd: thunderbird(10425): mmap W^X violation > > You will need the wxallowed mount option on /usr/local as long as you > use ports that map w|x pages. See > http://www.openbsd.org/faq/upgrade60.html. And help with getting this fixed. That may very well be in the form of some writeup to shame upstream developers into fixing this ;).
Re: thunderbird segfault: mmap W^X violation
On Sun, Aug 07, 2016 at 01:43:08PM +0200, Peter N. M. Hansteen wrote: > > /var/log/messages reports > > Aug 7 13:34:27 elke /bsd: thunderbird(10425): mmap W^X violation You will need the wxallowed mount option on /usr/local as long as you use ports that map w|x pages. See http://www.openbsd.org/faq/upgrade60.html. natano
amd64 bulk build failures 2016-08-06
The latest amd64 bulk build tested a number of things and suffered quite a bit of fallout: (1) update to CMake-3.6.1 (2) mmap returning ENOTSUP for W^X mappings (3) printf %s NULL no longer being valid databases/hs-postgresql-simple ghc mmap W^X violation devel/darcs ghc mmap W^X violation devel/hs-fglghc mmap W^X violation mail/mozilla-thunderbirdxpcshell mmap W^X violation devel/jdk/1.7 java mprotect W^X violation devel/libdwarf ? devel/libtalloc printf %s NULL devel/xulrunner/24 xpcshell mmap W^X violation graphics/ctlcmake? alloca.h: No such file or directory lang/libv8 ? segfault lang/mono mono-boehm mmap W^X violation databases/tdb printf %s NULL lang/node ? segfault lang/pypy pypy mmap W^X violation lang/rakudo ? segfault lang/sbcl sbcl mmap W^X violation net/gupnp/av? segfault net/libaccounts-glibxsltproc.core www/chromiumdisplay_source.h file not found www/seamonkey xpcshell mmap W^X violation x11/freerdp ? segfault Notes: * libaccounts-glib has sporadically shown this failure for some time. * mono doesn't build on a loaded machine anyway, the W^X violation is probably just incidental. * The dmesgs of the build machines show some further W^X violations that apparently didn't cause any build errors. Recommendably, pypy doesn't just die randomly but catches the error and provides an explicit error message: Got an unexpected error trying to allocate some memory for the JIT (tried to do mmap() with PROT_EXEC|PROT_READ|PROT_WRITE). This can be caused by a system policy like PAX. You need to find how to work around the policy on your system. Abort trap (core dumped) -- Christian "naddy" Weisgerber na...@mips.inka.de
