XScreenSaver and bsdauth
Hi, I'm trying to make a patch to XScreenSaver to support bsdauth (hopefully to have it upstream). So far so good but at one point I'm calling auth_userokay(3) and I always get the following error: xscreensaver-auth: /usr/libexec/auth/login_passwd: Permission denied AFAIU, this call to auth_userokay(3) is done from the 'xscreensaver-auth' executable which was forked from the 'xscreensaver' executable. I have tried many combination of ownership and setuid bit on both 'xscreensaver' and 'xscreensaver-auth' but I always end up with this same error message. Do you have any idea? -- Manuel Giraud
Re: XScreenSaver and bsdauth
Stuart Henderson writes: > I believe it should be setgid auth (mode 2755 or 2555). I have the same error message with the following settings: $ ls -l /tmp/xscreensaver/bin/xscreensaver -r-xr-sr-x 1 root auth 150616 Jul 8 11:16 /tmp/xscreensaver/bin/xscreensaver* $ ls -l /tmp/xscreensaver/libexec/xscreensaver/xscreensaver-auth -r-xr-sr-x 1 root auth 522400 Jul 8 11:16 /tmp/xscreensaver/libexec/xscreensaver/xscreensaver-auth* -- Manuel Giraud
Re: XScreenSaver and bsdauth
Stuart Henderson writes: > On 2024/07/08 14:29, Manuel Giraud wrote: >> Stuart Henderson writes: >> >> > I believe it should be setgid auth (mode 2755 or 2555). >> >> I have the same error message with the following settings: >> >> $ ls -l /tmp/xscreensaver/bin/xscreensaver >> -r-xr-sr-x 1 root auth 150616 Jul 8 11:16 >> /tmp/xscreensaver/bin/xscreensaver* >> $ ls -l /tmp/xscreensaver/libexec/xscreensaver/xscreensaver-auth >> -r-xr-sr-x 1 root auth 522400 Jul 8 11:16 >> /tmp/xscreensaver/libexec/xscreensaver/xscreensaver-auth* >> -- >> Manuel Giraud >> > > oh you're running it from /tmp? i bet that is nosuid. Thanks that was the case 😅… but now I have some work left to do because 'xscreensaver-auth' quickly calls a 'disavow_privileges' function that reverts to run as user/user. -- Manuel Giraud
Re: XScreenSaver and bsdauth
Landry Breuil writes: > Le Mon, Jul 08, 2024 at 11:43:25AM +0200, Manuel Giraud a écrit : >> Hi, >> >> I'm trying to make a patch to XScreenSaver to support bsdauth (hopefully >> to have it upstream). > > you might want to have a look at Thanks! AFAIU, xscreensaver drops its privileges rather quickly and we cannot use 'auth_userokay' after a certain point. I'd like to keep this philosophy as far as possible and maybe, as a last resort, do not drop privileges as slock seems to be doing. -- Manuel Giraud
Re: XScreenSaver and bsdauth
Antoine Jacoutot writes: > On Mon, Jul 08, 2024 at 11:43:25AM +0200, Manuel Giraud wrote: >> Hi, >> >> I'm trying to make a patch to XScreenSaver to support bsdauth (hopefully >> to have it upstream). >> >> So far so good but at one point I'm calling auth_userokay(3) and I >> always get the following error: >> >> xscreensaver-auth: /usr/libexec/auth/login_passwd: Permission denied >> >> AFAIU, this call to auth_userokay(3) is done from the >> 'xscreensaver-auth' executable which was forked from the 'xscreensaver' >> executable. I have tried many combination of ownership and setuid bit >> on both 'xscreensaver' and 'xscreensaver-auth' but I always end up with >> this same error message. Do you have any idea? > > I implemented it then removed it ~15 years ago. > It looks like it wasn't finished but it might be a start. Thanks… and 15 years later, I'm at the same point as you were 😅. Some things have changed in xscreensaver in the meantime but I might reuse the part where you force the GID to 11 (auth). -- Manuel Giraud
NEW: math/liblas
Hi, Here is a port of libLAS (www.liblas.org), a library (and basic tools) to manipulate LAS format Lidar files. liblas.tgz Description: Unix tar archive -- Manuel Giraud
Re: NEW: math/liblas
Landry Breuil writes: > On Fri, Jul 03, 2015 at 04:07:45PM +0200, Manuel Giraud wrote: >> Hi, >> >> Here is a port of libLAS (www.liblas.org), a library (and basic tools) >> to manipulate LAS format Lidar files. > > Nice! I had a port of lastools a while ago since i use them at work but > never got to the point where i tried to import it.. might be lying in > the ports@ archives. Not yet (for this port)... as Benoit Lecocq pointed me, make test gives a segfault. -- Manuel Giraud
UPDATE: sbcl 1.1.14 -> 1.2.13
patch-src_runtime_GNUmakefile --- patches/patch-src_runtime_GNUmakefile 11 Aug 2012 23:02:23 - 1.5 +++ /dev/null 1 Jan 1970 00:00:00 - @@ -1,23 +0,0 @@ -$OpenBSD: patch-src_runtime_GNUmakefile,v 1.5 2012/08/11 23:02:23 pascal Exp $ - -Don't override external CFLAGS and LINKFLAGS. - src/runtime/GNUmakefile.orig Mon Dec 5 00:09:01 2011 -+++ src/runtime/GNUmakefileSat Aug 11 17:05:14 2012 -@@ -18,14 +18,14 @@ TARGET=sbcl - # Config file. Most of them are same on most systems right now. - # If you need to override one of these, do it in Config. - LD = ld --LINKFLAGS = -g -+LINKFLAGS += -g - NM = nm -gp - DEPEND_FLAGS = -MM - GREP = grep - - include ../../output/prefix.def - --CFLAGS = -g -Wall -Wsign-compare -O3 -+CFLAGS += -Wall -Wsign-compare - ASFLAGS = $(CFLAGS) - CPPFLAGS = -I. -DSBCL_PREFIX=\"$(SBCL_PREFIX)\" - Index: pkg/PLIST === RCS file: /cvs/ports/lang/sbcl/pkg/PLIST,v retrieving revision 1.8 diff -u -p -r1.8 PLIST --- pkg/PLIST 10 Dec 2013 17:37:54 - 1.8 +++ pkg/PLIST 22 Jul 2015 08:07:17 - @@ -25,6 +25,8 @@ lib/sbcl/contrib/sb-introspect.asd lib/sbcl/contrib/sb-introspect.fasl lib/sbcl/contrib/sb-md5.asd lib/sbcl/contrib/sb-md5.fasl +lib/sbcl/contrib/sb-mpfr.asd +lib/sbcl/contrib/sb-mpfr.fasl lib/sbcl/contrib/sb-posix.asd lib/sbcl/contrib/sb-posix.fasl lib/sbcl/contrib/sb-queue.asd @@ -37,6 +39,7 @@ lib/sbcl/contrib/sb-simple-streams.asd lib/sbcl/contrib/sb-simple-streams.fasl lib/sbcl/contrib/sb-sprof.asd lib/sbcl/contrib/sb-sprof.fasl +lib/sbcl/contrib/uiop.fasl lib/sbcl/sbcl.core lib/sbcl/site-systems/ @man man/man1/sbcl.1 @@ -45,6 +48,3 @@ share/doc/sbcl/BUGS share/doc/sbcl/COPYING share/doc/sbcl/CREDITS share/doc/sbcl/NEWS -share/doc/sbcl/asdf.html -share/doc/sbcl/html/ -share/doc/sbcl/sbcl.html -- Manuel Giraud
[update] sbcl 1.2.15
Hi,
Here is an update to sbcl-1.2.15 tested on amd64
Index: Makefile
===
RCS file: /cvs/ports/lang/sbcl/Makefile,v
retrieving revision 1.24
diff -u -p -u -r1.24 Makefile
--- Makefile31 Aug 2015 18:37:30 - 1.24
+++ Makefile18 Sep 2015 15:03:46 -
@@ -5,7 +5,7 @@ ONLY_FOR_ARCHS =amd64 i386 powerpc
COMMENT= compiler and runtime system for ANSI Common Lisp
-V =1.2.14
+V =1.2.15
DISTNAME= sbcl-${V}-source
PKGNAME= sbcl-${V}
WRKDIST= ${WRKDIR}/sbcl-${V}
Index: distinfo
===
RCS file: /cvs/ports/lang/sbcl/distinfo,v
retrieving revision 1.12
diff -u -p -u -r1.12 distinfo
--- distinfo11 Aug 2015 21:41:04 - 1.12
+++ distinfo18 Sep 2015 15:03:46 -
@@ -1,2 +1,2 @@
-SHA256 (sbcl-1.2.14-source.tar.bz2) =
uRRt1kYMBbylCPbdqDADWAkRgz7t1R28CdjsqAsPXAY=
-SIZE (sbcl-1.2.14-source.tar.bz2) = 5565538
+SHA256 (sbcl-1.2.15-source.tar.bz2) =
2Vpuiktlj5lzgl+NRNYZWmRbDWoz2GUyTAxli4vLFlE=
+SIZE (sbcl-1.2.15-source.tar.bz2) = 5585753
--
Manuel Giraud
Re: Emacs patch, tests welcome
Hi all, So here is what I did (on a quite fresh snapshot amd64): - comment the "Emacs.selectionTimeout: 10" line in my .Xresources - build the default gtk3 flavor with this patch - M-x org-capture => asks for input instantly - Evaluate the following bug report recipe which returns nil immediately: (let ((value 'SECONDARY) (x-selection-timeout 2000)) ;;; from org-get-x-clipboard in lisp/org-compat.el (gui-get-selection value 'UTF8_STRING) (gui-get-selection value 'COMPOUND_TEXT) (gui-get-selection value 'STRING) (gui-get-selection value 'TEXT)) For quite some time now, I'm also using bleeding edge emacs as is on openbsd and the following patch also solve this issue here: diff --git a/configure.ac b/configure.ac index c924634d5b..740f6d79a1 100644 --- a/configure.ac +++ b/configure.ac @@ -4884,7 +4884,7 @@ AC_DEFUN case $opsys in dnl SIGIO exists, but the feature doesn't work in the way Emacs needs. - hpux* | nacl | openbsd | solaris | unixware ) + hpux* | nacl | solaris | unixware ) emacs_broken_SIGIO=yes ;; So great job Gregoire and Jeremie! -- Manuel Giraud
Re: Emacs patch, tests welcome
FWIW, it seems that this patch also solves an issue I had: M-x list-packages used to fail at contacting elpa.gnu.org. -- Manuel Giraud
Re: Emacs patch, tests welcome
Jeremie Courreges-Anglas writes: > On Thu, Jul 15 2021, Manuel Giraud wrote: >> FWIW, it seems that this patch also solves an issue I had: >> M-x list-packages used to fail at contacting elpa.gnu.org. > > Ouch I think I spotted this one earlier but couldn't pinpoint it. And > indeed I can't reproduce with CVS head. Do you mean in emacs CVS head? I could test again but what I saw was that, with current emacs head, M-x list-packages usually failed to contact elpa.gnu.org but, with current emacs + this patch, M-x list-packages does not fail anymore. So do you think we'd have to wait or we could start to push this patch upstream? -- Manuel Giraud
Re: fonts/iosevka-fonts: fix packaging of slab variant
Yes, thanks for working on this. -- Manuel Giraud
error on quirks
Hi,
For the first time, I have to touch devel/quirks after a port
modification. But when I try to update the patched devel/quirks from
port I get the following error:
$ cd /usr/ports/devel/quirks
$ make package
===> Faking installation for quirks-6.197
/usr/ports/pobj/quirks-6.197/bin/install -d -m 755
/usr/ports/pobj/quirks-6.197/fake-amd64/usr/local/libdata/perl5/site_perl/OpenBSD/Quirks
/usr/ports/pobj/quirks-6.197/bin/install -c -m 644
/usr/ports/devel/quirks/files/Quirks.pm
/usr/ports/pobj/quirks-6.197/fake-amd64/usr/local/libdata/perl5/site_perl/OpenBSD/Quirks.pm
/usr/libexec/locate.mklocatedb /usr/ports/pobj/quirks-6.197/fake-amd64/usr/local/share/update.db
locate.code: bigram array too small to build db, index more files
*** Error 1 in . (Makefile:29 'do-install')
*** Error 2 in . (/usr/ports/infrastructure/mk/bsd.port.mk:3139
'/usr/ports/pobj/quirks-6.197/fake-amd64/.fake_done': @cd /usr/ports/devel/q...)
*** Error 2 in . (/usr/ports/infrastructure/mk/bsd.port.mk:2233
'/usr/ports/packages/amd64/no-arch/quirks-6.197.tgz': @cd /usr/ports/devel/q...)
*** Error 2 in . (/usr/ports/infrastructure/mk/bsd.port.mk:2723
'_internal-package': @case X${_DEPENDS_CACHE} in X) _DEPENDS_CACHE=$( mktem...)
*** Error 2 in /usr/ports/devel/quirks
(/usr/ports/infrastructure/mk/bsd.port.mk:2702 'package': @lock=quirks-6.197;
export _LOCKS_HELD=" q...)
BTW, I'm running -current. What might cause this error? Thanks.
--
Manuel Giraud
Re: error on quirks
Solène Rapenne writes: [...] > What did you change in quirks? It's certainly a syntax error Ok, so I've lied a bit 😅. I was working with edd@ on a iosevka update and we had to modify quirks for it. But I was never able to build quirks. This patch is already in the tree and I'm still getting this error on a fresh cvs update. BTW, I never had to build quirks from port so maybe I have this error since forever. -- Manuel Giraud
Re: error on quirks
Stuart Henderson writes:
[...]
> As part of the "quirks" package build, the update.db cache is built
> which provides information used by pkg_add -u to speed up updates.
> In a bulk build DPB takes care to build this at the end of the
> run, so that it has information about all packages available.
>
> This is based on the packages in the local build dir (e.g.
> /usr/ports/packages/$ARCH/all by default).
>
> To avoid the failure you need to build some other packages first
> (it doesn't matter which. math/moo is a good quick-to-build simple
> package if you need one).
Hi and thanks,
I don't understand what is going on here but here is what I've just did:
$ cd /usr/ports/
$ rm -rf packages
$ cd math/moo
$ make package
===> Building from scratch moo-1.5p0
install: /usr/ports/pobj: Operation not permitted
===> Checking files for moo-1.5p0
`/usr/ports/distfiles/moo-1.5.tar.gz' is up to date.
>> (SHA256) moo-1.5.tar.gz: OK
===> Verifying specs: c
===> found c.97.1
===> Extracting for moo-1.5p0
===> Patching for moo-1.5p0
===> Applying OpenBSD patch patch-Makefile
Hmm... Looks like a unified diff to me...
The text leading up to this was:
--
|Index: Makefile
|--- Makefile.orig
|+++ Makefile
--
Patching file Makefile using Plan A...
Hunk #1 succeeded at 1.
done
===> Applying OpenBSD patch patch-scan_l
Hmm... Looks like a unified diff to me...
The text leading up to this was:
--
|Index: scan.l
|--- scan.l.orig
|+++ scan.l
--
Patching file scan.l using Plan A...
Hunk #1 succeeded at 8.
done
===> Compiler link: clang -> /usr/bin/clang
===> Compiler link: clang++ -> /usr/bin/clang++
===> Compiler link: cc -> /usr/bin/cc
===> Compiler link: c++ -> /usr/bin/c++
===> Generating configure for moo-1.5p0
===> Configuring for moo-1.5p0
===> Building for moo-1.5p0
yacc -d -o moo.c moo.y
lex -o scan.c scan.l
cc -O2 -pipe -Wall -W -Wno-unused -Wshadow -pedantic -std=c99 -MD -MP
-I/usr/ports/pobj/moo-1.5/moo-1.5 -nostdinc -idirafter /usr/include -c moo.c
cc -O2 -pipe -Wall -W -Wno-unused -Wshadow -pedantic -std=c99 -MD -MP
-I/usr/ports/pobj/moo-1.5/moo-1.5 -nostdinc -idirafter /usr/include -c scan.c
cc -o moo moo.o scan.o
===> Faking installation for moo-1.5p0
install -c -s -o root -g bin -m 755 moo
/usr/ports/pobj/moo-1.5/fake-amd64/usr/local/bin/moo
install -c -o root -g bin -m 644 moo.1
/usr/ports/pobj/moo-1.5/fake-amd64/usr/local/man/man1/moo.1
===> Building package for moo-1.5p0
Create /usr/ports/packages/amd64/all/moo-1.5p0.tgz
Creating package moo-1.5p0
Link to /usr/ports/packages/amd64/ftp/moo-1.5p0.tgz
$ cd /usr/ports/devel/quirks/
$ make package
===> Building from scratch quirks-6.198
install: /usr/ports/pobj: Operation not permitted
===> Checking files for quirks-6.198
>> No DISTFILES nor PATCHFILES.
===> Extracting for quirks-6.198
===> Patching for quirks-6.198
===> Compiler link: clang -> /usr/bin/clang
===> Compiler link: clang++ -> /usr/bin/clang++
===> Compiler link: cc -> /usr/bin/cc
===> Compiler link: c++ -> /usr/bin/c++
===> Generating configure for quirks-6.198
===> Configuring for quirks-6.198
===> Building for quirks-6.198
perl -Mlib=/usr/ports/devel/quirks/files /usr/ports/devel/quirks/files/t
>/usr/ports/pobj/quirks-6.198/result
cmp /usr/ports/pobj/quirks-6.198/result /usr/ports/devel/quirks/files/reference
perl /usr/ports/devel/quirks/files/list_update_info -o
/usr/ports/pobj/quirks-6.198/update.list /usr/ports/packages/amd64/all
Scanning: ok
===> Faking installation for quirks-6.198
/usr/ports/pobj/quirks-6.198/bin/install -d -m 755
/usr/ports/pobj/quirks-6.198/fake-amd64/usr/local/libdata/perl5/site_perl/OpenBSD/Quirks
/usr/ports/pobj/quirks-6.198/bin/install -c -m 644
/usr/ports/devel/quirks/files/Quirks.pm
/usr/ports/pobj/quirks-6.198/fake-amd64/usr/local/libdata/perl5/site_perl/OpenBSD/Quirks.pm
/usr/libexec/locate.mklocatedb /usr/ports/pobj/quirks-6.198/fake-amd64/usr/local/share/update.db
locate.code: bigram array too small to build db, index more files
*** Error 1 in . (Makefile:29 'do-install')
*** Error 2 in . (/usr/ports/infrastructure/mk/bsd.port.mk:3139
'/usr/ports/pobj/quirks-6.198/fake-amd64/.fake_done': @cd /usr/ports/devel/q...)
*** Error 2 in . (/usr/ports/infrastructure/mk/bsd.port.mk:2233
'/usr/ports/packages/amd64/no-arch/quirks-6.198.tgz': @cd /usr/ports/devel/q...)
*** Error 2 in . (/usr/ports/infrastructure/mk/bsd.port.mk:2723
'_internal-package': @case X${_DEPENDS_CACHE} in X) _DEPENDS_CACHE=$( mktem...)
*** Error 2 in /usr/ports/devel/quirks
(/usr/ports/infrastructure/mk/bsd.port.mk:2702 'package': @lock=quirks-6.198;
export _LOCKS_HELD=" q...)
--
Manuel Giraud
Re: error on quirks
Stuart Henderson writes: [...] >> Hi and thanks, >> >> I don't understand what is going on here but here is what I've just did: > > You probably need to build a few more packages then. Not sure how > many you'll need but here are a few other small/quick-to-build ones: > > math/moo > sysutils/colorls > sysutils/colortree > sysutils/entr > sysutils/cpuid > converters/mpack > games/wtf > sysutils/obsdfreqd Thanks. But it seems I need even more :) I'll report when I found out how much. -- Manuel Giraud
Re: error on quirks
Hi, I forgot to do a "make clean" into /usr/ports/devel/quirks after each new package built. Finally, quirks build correctly with the following update.list: moo-1.5p0:@name moo-1.5p0 moo-1.5p0:@version 10 moo-1.5p0:@comment pkgpath=math/moo ftp=yes moo-1.5p0:@arch amd64 moo-1.5p0:@wantlib c.97.1 colorls-7.4:@name colorls-7.4 colorls-7.4:@version 10 colorls-7.4:@comment pkgpath=sysutils/colorls ftp=yes colorls-7.4:@arch amd64 colorls-7.4:@wantlib c.97.1 colorls-7.4:@wantlib curses.15.0 colorls-7.4:@wantlib util.17.0 colortree-1.8.0:@name colortree-1.8.0 colortree-1.8.0:@version 10 colortree-1.8.0:@comment pkgpath=sysutils/colortree ftp=yes colortree-1.8.0:@arch amd64 colortree-1.8.0:@wantlib c.97.1 entr-5.5:@name entr-5.5 entr-5.5:@version 10 entr-5.5:@comment pkgpath=sysutils/entr ftp=yes entr-5.5:@arch amd64 entr-5.5:@wantlib c.97.1 cpuid-20231115:@name cpuid-20231115 cpuid-20231115:@version 10 cpuid-20231115:@comment pkgpath=sysutils/cpuid ftp=yes cpuid-20231115:@arch amd64 cpuid-20231115:@wantlib c.97.1 mpack-1.6p3:@name mpack-1.6p3 mpack-1.6p3:@version 10 mpack-1.6p3:@comment pkgpath=converters/mpack ftp=yes mpack-1.6p3:@arch amd64 mpack-1.6p3:@wantlib c.97.1 wtf-20230906:@name wtf-20230906 wtf-20230906:@comment pkgpath=games/wtf ftp=yes wtf-20230906:@arch * obsdfreqd-1.2.1:@name obsdfreqd-1.2.1 obsdfreqd-1.2.1:@version 10 obsdfreqd-1.2.1:@comment pkgpath=sysutils/obsdfreqd ftp=yes obsdfreqd-1.2.1:@arch amd64 obsdfreqd-1.2.1:@wantlib c.97.1 obsdfreqd-1.2.1:@wantlib m.10.1 crashme-2.4p1:@name crashme-2.4p1 crashme-2.4p1:@version 10 crashme-2.4p1:@comment pkgpath=sysutils/crashme ftp=yes crashme-2.4p1:@arch amd64 crashme-2.4p1:@wantlib c.97.1 -- Manuel Giraud
[update] Iosevka font
Hi,
Here is a trivial patch to update Iosevka font.
Index: Makefile.inc
===
RCS file: /cvs/ports/fonts/iosevka-fonts/Makefile.inc,v
retrieving revision 1.4
diff -u -p -r1.4 Makefile.inc
--- Makefile.inc11 Mar 2022 19:00:20 - 1.4
+++ Makefile.inc24 Feb 2023 14:31:45 -
@@ -1,12 +1,12 @@
-V =11.3.0
+V =19.0.1
CATEGORIES = fonts x11
-HOMEPAGE = https://github.com/be5invis/iosevka
+HOMEPAGE = https://github.com/be5invis/Iosevka
MAINTAINER = Edd Barrett
# SIL OFL 1.1
PERMIT_PACKAGE =Yes
-MASTER_SITES = https://github.com/be5invis/iosevka/releases/download/v${V}/
+MASTER_SITES = https://github.com/be5invis/Iosevka/releases/download/v${V}/
EXTRACT_SUFX = .zip
NO_BUILD = Yes
Index: default/distinfo
===
RCS file: /cvs/ports/fonts/iosevka-fonts/default/distinfo,v
retrieving revision 1.3
diff -u -p -r1.3 distinfo
--- default/distinfo9 Feb 2022 21:05:13 - 1.3
+++ default/distinfo24 Feb 2023 14:31:45 -
@@ -1,2 +1,2 @@
-SHA256 (ttc-iosevka-11.3.0.zip) = z9a9+jHHr0DAcjf/rXbU8DQfYmcat1Ar3lViGmpHnDE=
-SIZE (ttc-iosevka-11.3.0.zip) = 70445215
+SHA256 (ttc-iosevka-19.0.1.zip) = dQ2QR33PZ/PBZ7Eu/7YApnCPA+LmJMw4Z00MyeIb5kA=
+SIZE (ttc-iosevka-19.0.1.zip) = 75570917
--
Manuel Giraud
Re: error on quirks
Marc Espie writes: > On Mon, Nov 20, 2023 at 01:56:54PM +0100, Manuel Giraud wrote: >> Hi, >> >> For the first time, I have to touch devel/quirks after a port >> modification. But when I try to update the patched devel/quirks from >> port I get the following error: > > Follow-up: I finally committed all the pieces, so now the updatedb > proper is in a separate package that requires a full snapshot, whereas > quirks can be rebuilt 100% independently. Thanks Marc. I'll try to re-test this then. -- Manuel Giraud
[UPDATE] iosevka-fonts
Hi, Here is a trivial patch to Iosevka fonts. Index: Makefile.inc === RCS file: /cvs/ports/fonts/iosevka-fonts/Makefile.inc,v diff -u -p -r1.10 Makefile.inc --- Makefile.inc3 Apr 2024 15:44:40 - 1.10 +++ Makefile.inc8 Aug 2024 08:29:09 - @@ -1,4 +1,4 @@ -V =29.0.5 +V =31.1.0 CATEGORIES = fonts x11 HOMEPAGE = https://github.com/be5invis/Iosevka MAINTAINER = Edd Barrett Index: aile/distinfo === RCS file: /cvs/ports/fonts/iosevka-fonts/aile/distinfo,v diff -u -p -r1.3 distinfo --- aile/distinfo 3 Apr 2024 15:44:40 - 1.3 +++ aile/distinfo 8 Aug 2024 08:29:09 - @@ -1,2 +1,2 @@ -SHA256 (PkgTTC-IosevkaAile-29.0.5.zip) = wfIP8S37VygBFy4L3xw/AIF9d4KXekKA6397BjiRjtM= -SIZE (PkgTTC-IosevkaAile-29.0.5.zip) = 66247933 +SHA256 (PkgTTC-IosevkaAile-31.1.0.zip) = 3yNjJUSNBk5MM+RvQVpYLIx//f/SvSb2NE57tArSpXU= +SIZE (PkgTTC-IosevkaAile-31.1.0.zip) = 52894700 Index: default/distinfo === RCS file: /cvs/ports/fonts/iosevka-fonts/default/distinfo,v diff -u -p -r1.7 distinfo --- default/distinfo3 Apr 2024 15:44:40 - 1.7 +++ default/distinfo8 Aug 2024 08:29:09 - @@ -1,2 +1,2 @@ -SHA256 (PkgTTC-Iosevka-29.0.5.zip) = IRR5i6PrieU9m/EE6mi/fvzmTt5E/WwcsBXIpParb28= -SIZE (PkgTTC-Iosevka-29.0.5.zip) = 106482895 +SHA256 (PkgTTC-Iosevka-31.1.0.zip) = 3IplIdAcJY41IEZHAdBareUthOP4NS2LESj5RfnJSLA= +SIZE (PkgTTC-Iosevka-31.1.0.zip) = 109830249 Index: etoile/distinfo === RCS file: /cvs/ports/fonts/iosevka-fonts/etoile/distinfo,v diff -u -p -r1.3 distinfo --- etoile/distinfo 3 Apr 2024 15:44:40 - 1.3 +++ etoile/distinfo 8 Aug 2024 08:29:09 - @@ -1,2 +1,2 @@ -SHA256 (PkgTTC-IosevkaEtoile-29.0.5.zip) = EWj/owXb150TrE+l3sdNQlNzUPyUPKlXcGqTvOutUX8= -SIZE (PkgTTC-IosevkaEtoile-29.0.5.zip) = 72073448 +SHA256 (PkgTTC-IosevkaEtoile-31.1.0.zip) = +CNCbjI9kiYC5X4DRJF42ReG0+yktHXThk4ojCrxti4= +SIZE (PkgTTC-IosevkaEtoile-31.1.0.zip) = 56779640 Index: slab/distinfo === RCS file: /cvs/ports/fonts/iosevka-fonts/slab/distinfo,v diff -u -p -r1.3 distinfo --- slab/distinfo 3 Apr 2024 15:44:40 - 1.3 +++ slab/distinfo 8 Aug 2024 08:29:09 - @@ -1,2 +1,2 @@ -SHA256 (PkgTTC-IosevkaSlab-29.0.5.zip) = z1YwqL5Sybz4zLamfs2tCYk52/zM4ThxicmmhHAF3hk= -SIZE (PkgTTC-IosevkaSlab-29.0.5.zip) = 112791752 +SHA256 (PkgTTC-IosevkaSlab-31.1.0.zip) = MvzOL6OVpuTEQt6SRZhuziynw62w2yQPELXr+i5axLc= +SIZE (PkgTTC-IosevkaSlab-31.1.0.zip) = 116056364 -- Manuel Giraud
Re: OpenBSD 7.3, roundcubemail & php 8.0 vs php 8.1
"Steve Williams (Contractor)" writes: [...] > I can move the php/php_fpm configs to php-8.1.18 and then pkg_delete > the php-8.0.28p1 associated packages, but I wanted to make sure this > was the correct approach. I think the correct approach is to test whether your not packaged application happens to be working with PHP 8.1. For this you could, as you said, move your 8.0 config to 8.1 (you may have to install needed php 8.1 modules too) and do: $ rcctl stop php80_fpm $ rcctl disable php80_fpm $ rcctl enable php81_fpm $ rcctl start php81_fpm If this does not work, I think you could have both php80_fpm and php81_fpm but you'd have to set their flags into rc.conf.local to use their particular config (or by default both would use /etc/php-fpm.conf which would lead to errors) -- Manuel Giraud
Re: [PATCH] lang/sbcl - wxneeded working + version bump
Jeremie Courreges-Anglas writes: >>> +-LINKFLAGS = -g >>> ++LINKFLAGS = -g -Wl,-z,wxneeded >> >> It's a mystery to me why this should be needed. If the build calls >> cc(1) to perform the linking, why isn't the USE_WXNEEDED wrapper >> picked up? > > Correct, this is not needed. Just disabling the failing test was enough > to fix packaging. I have committed that part. sbcl then works and can > be used with the usual CL software out there. Oups, I made a patch for it upstream. But I don't think it matters since it permits to build on OpenBSD outside the ports infrastructure. No? And thanks for the fork(2) issue fix. -- Manuel Giraud
Re: emacs-25.1
Jeremie Courreges-Anglas writes:
> j...@wxcvbn.org (Jeremie Courreges-Anglas) writes:
>
>> Announce: http://lists.gnu.org/archive/html/emacs-devel/2016-09/msg00451.html
>> NEWS file: https://www.gnu.org/software/emacs/news/NEWS.25.1
>> There is now support for filesystem notifications support via kqueue.
>
> I forgot to mention that this update fixes the freezes with the gtk3
> flavor. :)
FWIW, build and test ok on {ALL_FLAVORS}/amd64.
Thanks.
--
Manuel Giraud
Re: Emacs 24.1
Antoine Jacoutot writes: > So obviously OK for me but I don't think my vote counts. I like that too because if one has dbus installed via a dependency it seems reasonable to start it in the xsession as an application might need it later (it is obviously the case for emacs). The ones with stripped-down configuration won't have a dbus dependency in the first place. (next time I need an issue to be fixed I'll say that gnome sucks on a public mailing list :-) -- Manuel Giraud
[Update] sbcl 1.0.57
Hi,
Here's an update of sbcl. Tested on i386.
cvs server: Diffing .
Index: Makefile
===
RCS file: /cvs/ports/lang/sbcl/Makefile,v
retrieving revision 1.12
diff -u -p -u -r1.12 Makefile
--- Makefile3 Jan 2012 02:01:25 - 1.12
+++ Makefile9 Jul 2012 16:00:31 -
@@ -5,7 +5,7 @@ ONLY_FOR_ARCHS =amd64 i386 powerpc
COMMENT= compiler and runtime system for ANSI Common Lisp
-V =1.0.54
+V =1.0.57
DISTNAME= sbcl-${V}-source
PKGNAME= sbcl-${V}
WRKDIST= ${WRKDIR}/sbcl-${V}
@@ -72,7 +72,7 @@ do-build:
cd ${WRKSRC} && ${SETENV} ${MAKE_ENV} /bin/sh make.sh \
--prefix=${PREFIX} --xc-host="${BOOTSTRAP_CMD}"
cd ${WRKSRC}/doc/manual && touch sbcl.texinfo && \
- ${SETENV} ${MAKE_ENV} ${GMAKE} asdf.info sbcl.info
+ ${SETENV} ${MAKE_ENV} ${GMAKE} asdf.info sbcl.info html
do-install:
cd ${WRKSRC} && ${SETENV} ${MAKE_ENV} /bin/sh install.sh
Index: distinfo
===
RCS file: /cvs/ports/lang/sbcl/distinfo,v
retrieving revision 1.6
diff -u -p -u -r1.6 distinfo
--- distinfo3 Jan 2012 02:01:25 - 1.6
+++ distinfo9 Jul 2012 16:00:31 -
@@ -1,10 +1,10 @@
-MD5 (sbcl-1.0.54-documentation-html.tar.bz2) = n6d+Z515ktGfmakY7Wb0zQ==
-MD5 (sbcl-1.0.54-source.tar.bz2) = t+lWpx1gO7cU9xwvfvNQ9g==
-RMD160 (sbcl-1.0.54-documentation-html.tar.bz2) = novMWQoZepH9xNdQ/E5MkaRmBds=
-RMD160 (sbcl-1.0.54-source.tar.bz2) = t21gm9udqgC7kJW9AdqL+k2lbEw=
-SHA1 (sbcl-1.0.54-documentation-html.tar.bz2) = 4CV3r+HwZG25wBJbUc5xgQysxzg=
-SHA1 (sbcl-1.0.54-source.tar.bz2) = b6GY2zwHGOIUyoz8pNcapeSVocI=
-SHA256 (sbcl-1.0.54-documentation-html.tar.bz2) =
XO35qJM8K6UXh7DH36CfhGIcoYJ/gKWeorT/oHJT9nE=
-SHA256 (sbcl-1.0.54-source.tar.bz2) =
jYUNlPj2+43MbctE/MDsB+l+lQN9eGT8HtrrXz4c4cY=
-SIZE (sbcl-1.0.54-documentation-html.tar.bz2) = 165801
-SIZE (sbcl-1.0.54-source.tar.bz2) = 3600921
+MD5 (sbcl-1.0.57-documentation-html.tar.bz2) = zDqdYyLQzg5CvEeF+numUQ==
+MD5 (sbcl-1.0.57-source.tar.bz2) = uw5PXC2tNJGAIZdSUoP2sA==
+RMD160 (sbcl-1.0.57-documentation-html.tar.bz2) = XYnugbr/OQaTpQ/TPkpTOKoaZSA=
+RMD160 (sbcl-1.0.57-source.tar.bz2) = xSvOxNQ6jg1qs4XXzHuhK4J/GpE=
+SHA1 (sbcl-1.0.57-documentation-html.tar.bz2) = ExQFo37lhOVdAi9PP4JcOkv/sIs=
+SHA1 (sbcl-1.0.57-source.tar.bz2) = U8+0SzUiiNrhDpv3X8RnaJ5GyBw=
+SHA256 (sbcl-1.0.57-documentation-html.tar.bz2) =
ZbLK1qhBicO2+Um/8dDBZJJdvreklNhcNM2Oi6g50hw=
+SHA256 (sbcl-1.0.57-source.tar.bz2) =
oUCGIBS9zdc4IaigU0/2iw7InrZTms/NNf0qCrB3ce8=
+SIZE (sbcl-1.0.57-documentation-html.tar.bz2) = 174146
+SIZE (sbcl-1.0.57-source.tar.bz2) = 3611050
cvs server: Diffing patches
cvs server: patches/patch-src_runtime_Config_x86-openbsd was removed, no
comparison available
cvs server: Diffing pkg
--
Manuel Giraud
sbcl 1.0.54 -> 1.0.58
Here is an update for sbcl. Tested on i386. 'make regress' passes now.
Index: Makefile
===
RCS file: /cvs/ports/lang/sbcl/Makefile,v
retrieving revision 1.12
diff -u -p -u -r1.12 Makefile
--- Makefile 3 Jan 2012 02:01:25 - 1.12
+++ Makefile 13 Aug 2012 08:38:02 -
@@ -5,7 +5,7 @@ ONLY_FOR_ARCHS = amd64 i386 powerpc
COMMENT= compiler and runtime system for ANSI Common Lisp
-V = 1.0.54
+V = 1.0.58
DISTNAME= sbcl-${V}-source
PKGNAME= sbcl-${V}
WRKDIST= ${WRKDIR}/sbcl-${V}
@@ -24,8 +24,7 @@ PERMIT_DISTFILES_FTP= Yes
WANTLIB= c m util
MASTER_SITES= ${MASTER_SITE_SOURCEFORGE:=sbcl/}
-DISTFILES = ${DISTNAME}${EXTRACT_SUFX} \
- sbcl-${V}-documentation-html${EXTRACT_SUFX}
+DISTFILES = ${DISTNAME}${EXTRACT_SUFX}
PSEUDO_FLAVORS= native_bootstrap
FLAVOR?=
@@ -72,7 +71,7 @@ do-build:
cd ${WRKSRC} && ${SETENV} ${MAKE_ENV} /bin/sh make.sh \
--prefix=${PREFIX} --xc-host="${BOOTSTRAP_CMD}"
cd ${WRKSRC}/doc/manual && touch sbcl.texinfo && \
- ${SETENV} ${MAKE_ENV} ${GMAKE} asdf.info sbcl.info
+ ${SETENV} ${MAKE_ENV} ${GMAKE} asdf.info sbcl.info html
do-install:
cd ${WRKSRC} && ${SETENV} ${MAKE_ENV} /bin/sh install.sh
Index: distinfo
===
RCS file: /cvs/ports/lang/sbcl/distinfo,v
retrieving revision 1.6
diff -u -p -u -r1.6 distinfo
--- distinfo 3 Jan 2012 02:01:25 - 1.6
+++ distinfo 13 Aug 2012 08:38:02 -
@@ -1,10 +1,2 @@
-MD5 (sbcl-1.0.54-documentation-html.tar.bz2) = n6d+Z515ktGfmakY7Wb0zQ==
-MD5 (sbcl-1.0.54-source.tar.bz2) = t+lWpx1gO7cU9xwvfvNQ9g==
-RMD160 (sbcl-1.0.54-documentation-html.tar.bz2) = novMWQoZepH9xNdQ/E5MkaRmBds=
-RMD160 (sbcl-1.0.54-source.tar.bz2) = t21gm9udqgC7kJW9AdqL+k2lbEw=
-SHA1 (sbcl-1.0.54-documentation-html.tar.bz2) = 4CV3r+HwZG25wBJbUc5xgQysxzg=
-SHA1 (sbcl-1.0.54-source.tar.bz2) = b6GY2zwHGOIUyoz8pNcapeSVocI=
-SHA256 (sbcl-1.0.54-documentation-html.tar.bz2) = XO35qJM8K6UXh7DH36CfhGIcoYJ/gKWeorT/oHJT9nE=
-SHA256 (sbcl-1.0.54-source.tar.bz2) = jYUNlPj2+43MbctE/MDsB+l+lQN9eGT8HtrrXz4c4cY=
-SIZE (sbcl-1.0.54-documentation-html.tar.bz2) = 165801
-SIZE (sbcl-1.0.54-source.tar.bz2) = 3600921
+SHA256 (sbcl-1.0.58-source.tar.bz2) = gXly0/C+LDfvKanqSFjmdyzM+Hz8xbNjYaWr4qFJ2UU=
+SIZE (sbcl-1.0.58-source.tar.bz2) = 3618349
Index: patches/patch-src_runtime_Config_x86-openbsd
===
RCS file: patches/patch-src_runtime_Config_x86-openbsd
diff -N patches/patch-src_runtime_Config_x86-openbsd
--- patches/patch-src_runtime_Config_x86-openbsd 3 Jan 2012 02:01:25 - 1.2
+++ /dev/null 1 Jan 1970 00:00:00 -
@@ -1,9 +0,0 @@
-$OpenBSD: patch-src_runtime_Config_x86-openbsd,v 1.2 2012/01/03 02:01:25 krw Exp $
src/runtime/Config.x86-openbsd.orig Mon May 9 04:49:39 2011
-+++ src/runtime/Config.x86-openbsd Fri Jul 8 13:39:44 2011
-@@ -24,5 +24,3 @@ OS_LIBS += -lutil
-
- LINKFLAGS += -export-dynamic
- LDFLAGS += -export-dynamic
--
--CFLAGS = -g -Wall -O2 -fno-omit-frame-pointer
--
Manuel Giraud
Re: sbcl 1.0.54 -> 1.0.58
Josh Elsasser writes:
> On Mon, Aug 13, 2012 at 10:54:26AM +0200, Manuel Giraud wrote:
>> Here is an update for sbcl. Tested on i386. 'make regress' passes now.
>>
>
> Looks good, however one nit is that the DISTFILES line is no longer
> needed at all, you're simply setting it to the default value.
Ok, here's the updated version. And thanks, for testing.
Index: Makefile
===
RCS file: /cvs/ports/lang/sbcl/Makefile,v
retrieving revision 1.12
diff -u -p -u -r1.12 Makefile
--- Makefile 3 Jan 2012 02:01:25 - 1.12
+++ Makefile 14 Aug 2012 09:00:05 -
@@ -5,7 +5,7 @@ ONLY_FOR_ARCHS = amd64 i386 powerpc
COMMENT= compiler and runtime system for ANSI Common Lisp
-V = 1.0.54
+V = 1.0.58
DISTNAME= sbcl-${V}-source
PKGNAME= sbcl-${V}
WRKDIST= ${WRKDIR}/sbcl-${V}
@@ -24,8 +24,6 @@ PERMIT_DISTFILES_FTP= Yes
WANTLIB= c m util
MASTER_SITES= ${MASTER_SITE_SOURCEFORGE:=sbcl/}
-DISTFILES = ${DISTNAME}${EXTRACT_SUFX} \
- sbcl-${V}-documentation-html${EXTRACT_SUFX}
PSEUDO_FLAVORS= native_bootstrap
FLAVOR?=
@@ -72,7 +70,7 @@ do-build:
cd ${WRKSRC} && ${SETENV} ${MAKE_ENV} /bin/sh make.sh \
--prefix=${PREFIX} --xc-host="${BOOTSTRAP_CMD}"
cd ${WRKSRC}/doc/manual && touch sbcl.texinfo && \
- ${SETENV} ${MAKE_ENV} ${GMAKE} asdf.info sbcl.info
+ ${SETENV} ${MAKE_ENV} ${GMAKE} asdf.info sbcl.info html
do-install:
cd ${WRKSRC} && ${SETENV} ${MAKE_ENV} /bin/sh install.sh
Index: distinfo
===
RCS file: /cvs/ports/lang/sbcl/distinfo,v
retrieving revision 1.6
diff -u -p -u -r1.6 distinfo
--- distinfo 3 Jan 2012 02:01:25 - 1.6
+++ distinfo 14 Aug 2012 09:00:05 -
@@ -1,10 +1,2 @@
-MD5 (sbcl-1.0.54-documentation-html.tar.bz2) = n6d+Z515ktGfmakY7Wb0zQ==
-MD5 (sbcl-1.0.54-source.tar.bz2) = t+lWpx1gO7cU9xwvfvNQ9g==
-RMD160 (sbcl-1.0.54-documentation-html.tar.bz2) = novMWQoZepH9xNdQ/E5MkaRmBds=
-RMD160 (sbcl-1.0.54-source.tar.bz2) = t21gm9udqgC7kJW9AdqL+k2lbEw=
-SHA1 (sbcl-1.0.54-documentation-html.tar.bz2) = 4CV3r+HwZG25wBJbUc5xgQysxzg=
-SHA1 (sbcl-1.0.54-source.tar.bz2) = b6GY2zwHGOIUyoz8pNcapeSVocI=
-SHA256 (sbcl-1.0.54-documentation-html.tar.bz2) = XO35qJM8K6UXh7DH36CfhGIcoYJ/gKWeorT/oHJT9nE=
-SHA256 (sbcl-1.0.54-source.tar.bz2) = jYUNlPj2+43MbctE/MDsB+l+lQN9eGT8HtrrXz4c4cY=
-SIZE (sbcl-1.0.54-documentation-html.tar.bz2) = 165801
-SIZE (sbcl-1.0.54-source.tar.bz2) = 3600921
+SHA256 (sbcl-1.0.58-source.tar.bz2) = gXly0/C+LDfvKanqSFjmdyzM+Hz8xbNjYaWr4qFJ2UU=
+SIZE (sbcl-1.0.58-source.tar.bz2) = 3618349
Index: patches/patch-src_runtime_Config_x86-openbsd
===
RCS file: patches/patch-src_runtime_Config_x86-openbsd
diff -N patches/patch-src_runtime_Config_x86-openbsd
--- patches/patch-src_runtime_Config_x86-openbsd 3 Jan 2012 02:01:25 - 1.2
+++ /dev/null 1 Jan 1970 00:00:00 -
@@ -1,9 +0,0 @@
-$OpenBSD: patch-src_runtime_Config_x86-openbsd,v 1.2 2012/01/03 02:01:25 krw Exp $
src/runtime/Config.x86-openbsd.orig Mon May 9 04:49:39 2011
-+++ src/runtime/Config.x86-openbsd Fri Jul 8 13:39:44 2011
-@@ -24,5 +24,3 @@ OS_LIBS += -lutil
-
- LINKFLAGS += -export-dynamic
- LDFLAGS += -export-dynamic
--
--CFLAGS = -g -Wall -O2 -fno-omit-frame-pointer
--
Manuel Giraud
Re: Emacs 24.2
jca+o...@wxcvbn.org (Jérémie Courrèges-Anglas) writes: > I'm running the no_x11 flavor on i386 since a few hours, without > a problem. The gtk3 and (default) gtk2 flavors are building fine, > athena is on the way, but please do test them, as I don't use those > flavors. Can't really comment on the port changes but I'm using the default gtk2 flavor for 3 days now without issue. -- Manuel Giraud
Re: Emacs 24.2
jca+o...@wxcvbn.org (Jérémie Courrèges-Anglas) writes:
> If someone on amd64 could just confirm that --build=${GCCARCH} does the
> right thing, that would be cool.
I just did a quick test on a -current amd64 install with FLAVOR=no_x11
(not enough time to build gtk). Everything install and deinstall
correctly. Machine dependent stuff is installed in
${PREFIX}/libexec/emacs/24.2/amd64-unknown-openbsd5.2/
--
Manuel Giraud
Re: Emacs 24.2
jca+o...@wxcvbn.org (Jérémie Courrèges-Anglas) writes: > Mike Belopuhov writes: >> gtk2 flavor builds and runs fine on amd64. But I don't get why did you bring >> new dependencies. e.g. why do we suddenly depend on ImageMagik? > > Well, Emacs 24 came with new features that made it depend on additional > packages, for example Image Magick[1]. Isn't it ok to try to provide > full-featured packages, as long as it doesn't create a problem? Even if > I don't use thumbs-mode or tumme, I'm not sure I should decide for other > users (later they may come here and say "hey, wth did you disable > ? I'd love to use it!"). I'm ok with this *but* image-dired.el was already in emacs 22 and I remember using it with the emacs 23 port that doesn't depend on ImageMagick (not even as RUN_DEPENDS). ImageMagick was installed by me or by another package dependency. Plus image-dired is tweakable so someone could make it use netpbm converters instead of ImageMagick convert. So I guess it doesn't make sense to bring this new dependency as it doesn't prevent users from using it. -- Manuel Giraud
Re: [PATCH] lang/sbcl - wxneeded working + version bump
Solène Rapenne writes: > Hello, > > with the following patch, sbcl build and don't die because of W^X > violation > > Version is also bumped from 1.2.14 to 1.3.8 Great! As you are here maybe you can try to build with "--fancy": I've used it for months on amd64 without issue but haven't tested it on any other arch. -- Manuel Giraud
Re: [NEW] uw-ttyp0 font
Manuel Giraud writes: > Hi, > > Maybe the ports tree is unlocked now so I'm reposting this nice font: > https://people.mpi-inf.mpg.de/~uwe/misc/uw-ttyp0/ Ping? Anyone for yet another font? -- Manuel Giraud
UPDATE klavaro 1.50 -> 3.00
1,103 @@ share/klavaro/ru.words share/klavaro/sv.paragraphs share/klavaro/sv.words share/klavaro/top10.png +share/klavaro/uk.paragraphs +share/klavaro/uk.words share/klavaro/ur.paragraphs share/klavaro/ur.words share/klavaro/vi.paragraphs share/klavaro/vi.words +share/klavaro/workman_us.kbd +share/locale/ share/locale/ar/ share/locale/ar/LC_MESSAGES/ share/locale/ar/LC_MESSAGES/klavaro.mo +share/locale/bg/ +share/locale/bg/LC_MESSAGES/ +share/locale/bg/LC_MESSAGES/klavaro.mo share/locale/bn/ share/locale/bn/LC_MESSAGES/ share/locale/bn/LC_MESSAGES/klavaro.mo +share/locale/cs/ +share/locale/cs/LC_MESSAGES/ share/locale/cs/LC_MESSAGES/klavaro.mo +share/locale/da/ +share/locale/da/LC_MESSAGES/ share/locale/da/LC_MESSAGES/klavaro.mo +share/locale/de/ +share/locale/de/LC_MESSAGES/ share/locale/de/LC_MESSAGES/klavaro.mo +share/locale/el/ +share/locale/el/LC_MESSAGES/ +share/locale/el/LC_MESSAGES/klavaro.mo share/locale/en_GB/ share/locale/en_GB/LC_MESSAGES/ share/locale/en_GB/LC_MESSAGES/klavaro.mo +share/locale/eo/ +share/locale/eo/LC_MESSAGES/ share/locale/eo/LC_MESSAGES/klavaro.mo +share/locale/es/ +share/locale/es/LC_MESSAGES/ share/locale/es/LC_MESSAGES/klavaro.mo +share/locale/eu/ +share/locale/eu/LC_MESSAGES/ +share/locale/eu/LC_MESSAGES/klavaro.mo +share/locale/fi/ +share/locale/fi/LC_MESSAGES/ +share/locale/fi/LC_MESSAGES/klavaro.mo +share/locale/fr/ +share/locale/fr/LC_MESSAGES/ share/locale/fr/LC_MESSAGES/klavaro.mo +share/locale/gl/ +share/locale/gl/LC_MESSAGES/ share/locale/gl/LC_MESSAGES/klavaro.mo +share/locale/hu/ +share/locale/hu/LC_MESSAGES/ share/locale/hu/LC_MESSAGES/klavaro.mo +share/locale/it/ +share/locale/it/LC_MESSAGES/ +share/locale/it/LC_MESSAGES/klavaro.mo +share/locale/kk/ +share/locale/kk/LC_MESSAGES/ +share/locale/kk/LC_MESSAGES/klavaro.mo +share/locale/ky/ +share/locale/ky/LC_MESSAGES/ +share/locale/ky/LC_MESSAGES/klavaro.mo +share/locale/nb/ +share/locale/nb/LC_MESSAGES/ share/locale/nb/LC_MESSAGES/klavaro.mo +share/locale/nl/ +share/locale/nl/LC_MESSAGES/ share/locale/nl/LC_MESSAGES/klavaro.mo +share/locale/pl/ +share/locale/pl/LC_MESSAGES/ share/locale/pl/LC_MESSAGES/klavaro.mo +share/locale/pt_BR/ +share/locale/pt_BR/LC_MESSAGES/ share/locale/pt_BR/LC_MESSAGES/klavaro.mo +share/locale/ru/ +share/locale/ru/LC_MESSAGES/ share/locale/ru/LC_MESSAGES/klavaro.mo +share/locale/sv/ +share/locale/sv/LC_MESSAGES/ share/locale/sv/LC_MESSAGES/klavaro.mo +share/locale/te/ +share/locale/te/LC_MESSAGES/ +share/locale/te/LC_MESSAGES/klavaro.mo +share/locale/uk/ +share/locale/uk/LC_MESSAGES/ +share/locale/uk/LC_MESSAGES/klavaro.mo share/locale/ur/ share/locale/ur/LC_MESSAGES/ share/locale/ur/LC_MESSAGES/klavaro.mo +share/locale/vi/ +share/locale/vi/LC_MESSAGES/ share/locale/vi/LC_MESSAGES/klavaro.mo +share/locale/wo/ +share/locale/wo/LC_MESSAGES/ +share/locale/wo/LC_MESSAGES/klavaro.mo +share/locale/zh_CN/ +share/locale/zh_CN/LC_MESSAGES/ +share/locale/zh_CN/LC_MESSAGES/klavaro.mo @exec %D/bin/gtk-update-icon-cache -q -t %D/share/icons/hicolor @unexec-delete %D/bin/gtk-update-icon-cache -q -t %D/share/icons/hicolor -- Manuel Giraud
Re: UPDATE emacs
j...@wxcvbn.org (Jérémie Courrèges-Anglas) writes: >> Lightly tested on amd64 all flavors. One can now M-x eww and profit. > > Used daily on i386 and amd64 for one month. Lightly tested on > sparc64. Ok, I should have asked first. > [...] > I could use test reports on !(i386|amd64|sparc64). Sorry but I cannot help here (but I'm just going to use your version). -- Manuel Giraud
Re: UPDATE emacs
timo.my...@iki.fi (Timo Myyrä) writes:
> I've noticed regression after updating emacs. In Gnus I browse through my
> mails with 'n'
> (gnus-summary-next-unread-article). When changing to next group using the 'n'
> and first mail of next group is not selected. So if I keep hitting 'n', every
> new groups first message will stay unread.
> I can manually read them but this is irritating behaviour.
> I'm using 24.4 on my CentOS7 laptop and there the Gnus is behaving as
> expected.
I'm using the patch from jca which is slightly different
(http://marc.info/?l=openbsd-ports&m=141709505507388)
but I cannot reproduce this ('n' works as usual). Could you try gnus
with "emacs -Q"?
--
Manuel Giraud
Re: UPDATE emacs
Manuel Giraud writes: > Sorry but I cannot help here (but I'm just going to use your version). Hi, It seems that we should have this patch too: https://lists.gnu.org/archive/html/bug-gnu-emacs/2014-10/msg01232.html because we are affected and it is annoying. -- Manuel Giraud
Re: UPDATE emacs
j...@wxcvbn.org (Jérémie Courrèges-Anglas) writes: > Indeed this problem makes tramp unusable. Updated diff. Thanks. I'm using it and it works here FWIW. -- Manuel Giraud
FIX: geo/gpsbabel
A bug fix to gpsbabel related to this:
https://bugzilla.redhat.com/show_bug.cgi?id=989851
Tested on 5.6 amd64.
Index: Makefile
===
RCS file: /cvs/ports/geo/gpsbabel/Makefile,v
retrieving revision 1.26
diff -u -p -r1.26 Makefile
--- Makefile10 Oct 2013 02:08:22 - 1.26
+++ Makefile10 Feb 2015 09:18:42 -
@@ -11,9 +11,9 @@ PKGNAME-tk= gpsbabel-tk-${VERSION}
PKGNAME-qt=gpsbabel-qt-${VERSION}
CATEGORIES=geo
-REVISION-main= 0
-REVISION-tk= 0
-REVISION-qt= 0
+REVISION-main= 1
+REVISION-tk= 1
+REVISION-qt= 1
HOMEPAGE= http://www.gpsbabel.org/
Index: patches/patch-garmin_fit_c
===
RCS file: patches/patch-garmin_fit_c
diff -N patches/patch-garmin_fit_c
--- /dev/null 1 Jan 1970 00:00:00 -
+++ patches/patch-garmin_fit_c 10 Feb 2015 09:18:42 -
@@ -0,0 +1,20 @@
+$OpenBSD$
+
+- fix a bug in garmin_fit parsing
+ https://bugzilla.redhat.com/show_bug.cgi?id=989851
+
+--- garmin_fit.c.orig Tue Feb 10 09:40:34 2015
garmin_fit.c Tue Feb 10 09:46:30 2015
+@@ -113,6 +113,12 @@ fit_parse_header(void)
+ debug_print(1,"%s: profile version=%d\n", MYNAME, ver);
+ debug_print(1,"%s: fit_data.len=%d\n", MYNAME, fit_data.len);
+ }
++
++ if (len > 12) {
++is_fatal(len != 14, MYNAME ": .FIT header with unrecognized size\n");
++// Unused according to Ingo Arndt
++gbfgetuint16(fin);
++ }
+ }
+
+ static gbuint8
--
Manuel Giraud
UPDATE: geo/gpx-viewer
Here's a simple update to 0.4.0 tested on 5.6 amd64.
Index: Makefile
===
RCS file: /cvs/ports/geo/gpx-viewer/Makefile,v
retrieving revision 1.29
diff -u -p -r1.29 Makefile
--- Makefile2 Jul 2014 09:25:44 - 1.29
+++ Makefile10 Feb 2015 09:40:13 -
@@ -2,9 +2,10 @@
COMMENT = gpx file viewer
-VERSION = 0.3.0
+VERSION = 0.4.0
DISTNAME = gpx-viewer-${VERSION}
-REVISION = 4
+REVISION =
+
CATEGORIES = geo x11
@@ -14,7 +15,7 @@ MAINTAINER = Landry Breuil http://edge.launchpad.net/gpx-viewer/trunk/0.2.0/+download/
+MASTER_SITES = http://edge.launchpad.net/gpx-viewer/trunk/0.4.0/+download/
CONFIGURE_STYLE = gnu
CONFIGURE_ENV =CPPFLAGS="-I${LOCALBASE}/include" \
Index: distinfo
===
RCS file: /cvs/ports/geo/gpx-viewer/distinfo,v
retrieving revision 1.5
diff -u -p -r1.5 distinfo
--- distinfo7 Aug 2012 13:14:45 - 1.5
+++ distinfo10 Feb 2015 09:40:13 -
@@ -1,2 +1,2 @@
-SHA256 (gpx-viewer-0.3.0.tar.gz) = TFSJxWYilFQM1mOiacIM8ob8DAdVXlpeBrFFM/Y+Vcw=
-SIZE (gpx-viewer-0.3.0.tar.gz) = 483607
+SHA256 (gpx-viewer-0.4.0.tar.gz) = lWrPr4cKxDYwDNmVPezmMN9/19/45K4ld6YAKIRGb4A=
+SIZE (gpx-viewer-0.4.0.tar.gz) = 534735
--
Manuel Giraud
Re: FIX: geo/gpsbabel
Ping. Or maybe someone is porting 1.5.2 version?
Manuel Giraud writes:
> A bug fix to gpsbabel related to this:
> https://bugzilla.redhat.com/show_bug.cgi?id=989851
> Tested on 5.6 amd64.
>
> Index: Makefile
> ===
> RCS file: /cvs/ports/geo/gpsbabel/Makefile,v
> retrieving revision 1.26
> diff -u -p -r1.26 Makefile
> --- Makefile 10 Oct 2013 02:08:22 - 1.26
> +++ Makefile 10 Feb 2015 09:18:42 -
> @@ -11,9 +11,9 @@ PKGNAME-tk= gpsbabel-tk-${VERSION}
> PKGNAME-qt= gpsbabel-qt-${VERSION}
> CATEGORIES= geo
>
> -REVISION-main= 0
> -REVISION-tk= 0
> -REVISION-qt= 0
> +REVISION-main= 1
> +REVISION-tk= 1
> +REVISION-qt= 1
>
> HOMEPAGE=http://www.gpsbabel.org/
>
> Index: patches/patch-garmin_fit_c
> ===
> RCS file: patches/patch-garmin_fit_c
> diff -N patches/patch-garmin_fit_c
> --- /dev/null 1 Jan 1970 00:00:00 -
> +++ patches/patch-garmin_fit_c10 Feb 2015 09:18:42 -
> @@ -0,0 +1,20 @@
> +$OpenBSD$
> +
> +- fix a bug in garmin_fit parsing
> + https://bugzilla.redhat.com/show_bug.cgi?id=989851
> +
> +--- garmin_fit.c.origTue Feb 10 09:40:34 2015
> garmin_fit.c Tue Feb 10 09:46:30 2015
> +@@ -113,6 +113,12 @@ fit_parse_header(void)
> + debug_print(1,"%s: profile version=%d\n", MYNAME, ver);
> + debug_print(1,"%s: fit_data.len=%d\n", MYNAME, fit_data.len);
> + }
> ++
> ++ if (len > 12) {
> ++is_fatal(len != 14, MYNAME ": .FIT header with unrecognized size\n");
> ++// Unused according to Ingo Arndt
> ++gbfgetuint16(fin);
> ++ }
> + }
> +
> + static gbuint8
--
Manuel Giraud
[new/wip] cloudcompare
Here's an attempt to port cloudcompare a 3D point cloud processing software. cloudcompare-2.6.1.tar.gz Description: Unix tar archive -- Manuel Giraud
Re: [rc] emacs-25.2-rc1
Jeremie Courreges-Anglas writes:
> Hi,
>
> here's a update to the first 25.2 RC. no_x11 works fine for me on
> amd64 and arm. As usual, this is an RC so it is not intended for
> commit, but early tests are welcome.
amd64/{gtk3|athena} builds, installs and runs fine here.
--
Manuel Giraud
Re: Firefox 4.0 on 4.8-stable
Puffy BSD writes: > The diffs I had for a couple of ports have now been deleted. Wow, this one was fun. I too had a couple of diffs that can make OpenBSD the best OS one can dream of but just deleted them. -- Manuel Giraud
Re: Update lang/sbcl to 1.0.48
Josh Elsasser writes: > The following patch updates SBCL from 1.0.41 to 10.48. In the months > since 1.0.41 there have been the usual pile of bug fixes, > optimizations, and even new features. See > /usr/local/share/doc/sbcl/NEWS or http://www.sbcl.org/all-news.html > for details. > > This update also does something I've been meaning to do for a while, > it switches to the prebuilt doc tarball and drops the texlive > dependency. For this particular release that means HTML docs only, no > texinfo or PDF. If this greatly distresses you then speak up now or > forever hold your peace. > > Comments, ok? Many thanks for this update. Regarding the doc, I don't care about the PDF but isn't it possible to keep building the info files without relying on the texlive dependency? I find the info handy to browse within emacs. -- Manuel Giraud
emacs 24
Hi, I've talked to upstream to include some patches from our emacs 23 port in their trunk for the next release. So far so good, but their is some questions wrt the mips patches (see http://permalink.gmane.org/gmane.emacs.devel/142154) I can't test on mips (or even answer those questions). Could someone jump in (or help me) on this? -- Manuel Giraud
astro/cspice
Hello ports@, I'd like to port the cspice toolkit (http://naif.jpl.nasa.gov/naif/) in order to link it with xplanet and celestia. But I have some questions: 1- There is one source tree for each architecture (i.e. one for Linux-32bits, one for SUN-64bits, etc.) so the port should be arch specific. Is there an example of this in the ports tree? 2- The maintainer of the toolkit says that it is not allowed to redistribute a standalone toolkit but it is ok to redistribute something that is linked with it (like celestia for example). So I think it means that PERMIT_* should all be set to NO. And there will be no package of cspice? 3- Knowing 2, don't you think it might be better to patch xplanet and celestia ports to build cspice and link to it? -- Manuel Giraud
NEW: astro/cspice
Hello ports@, This port provides a library for dealing NASA/NAIF spice kernels. It can later be link with astro/celestia or x11/xplanet. Here's my first attempt for this port. (note: at first, VERSION was "N0063" instead of "0063" but pkg_add cannot resolve the package name (I'm using stable)). -- Manuel Giraud cspice.tar.gz Description: application/gzip
Re: emacs 23.2
Matthieu Herrb writes: > I've updated his port to track some of the changes (cairo update). It's > attached below. Unfortunatly, this one seem to hang quite often on startup. > This looks like a gtk/gnome problem but I don't have time to > investigate. Same problem here. I've just tested on -current and the default gtk flavor hangs at startup. The athena flavor doesn't have this problem. On 4.8, everything works fine. > Any help to make that progress is welcome. :-) that did't really help to make progress but I don't know what to do from here. -- Manuel Giraud
Re: emacs 23.2
The quest for emacs 23 on openbsd is not dead yet. I've updated the ports to support latest LIB_DEPENDS standard. On a fresh i386 -current build, I've built this port : the startup lock is still here. I've killed the process and here's the backtrace: --8<---cut here---start->8--- (gdb) bt #0 0x53699119 in read () from /usr/lib/libc.so.58.0 #1 0x53dc63a0 in read (fd=5, buf=0x887b018, nbytes=4096) at /usr/src/lib/libpthread/uthread/uthread_read.c:72 #2 0x52a0eac3 in _xcb_in_read (c=0x887b000) at /usr/xenocara/lib/libxcb/libxcb/../../../dist/libxcb/src/xcb_in.c:666 #3 0x52a0f354 in xcb_poll_for_event (c=0x887b000) at /usr/xenocara/lib/libxcb/libxcb/../../../dist/libxcb/src/xcb_in.c:551 #4 0x4a125694 in poll_for_event () from /usr/X11R6/lib/libX11.so.14.0 #5 0x4a125f24 in _XReply () from /usr/X11R6/lib/libX11.so.14.0 #6 0x4a1199aa in XSync () from /usr/X11R6/lib/libX11.so.14.0 #7 0x080e7d7b in x_sync (f=0x8539600) at xfns.c:4265 #8 0x080e07f5 in x_make_frame_visible (f=0x8539600) at xterm.c:9346 #9 0x080623f4 in Fmake_frame_visible (frame=139695621) at frame.c:1848 #10 0x0817b6a5 in Ffuncall (nargs=2, args=0xcfbbfff0) at eval.c:3024 #11 0x081b1a7a in Fbyte_code (bytestr=136536569, vector=136536589, maxdepth=Variable "maxdepth" is not available. ) at bytecode.c:680 #12 0x0817afc4 in funcall_lambda (fun=136536525, nargs=1, arg_vector=0xcfbc0134) at eval.c:3211 #13 0x0817b40b in Ffuncall (nargs=2, args=0xcfbc0130) at eval.c:3081 #14 0x081b1a7a in Fbyte_code (bytestr=136983993, vector=136984013, maxdepth=Variable "maxdepth" is not available. ) at bytecode.c:680 #15 0x0817afc4 in funcall_lambda (fun=136983949, nargs=1, arg_vector=0xcfbc0274) at eval.c:3211 #16 0x0817b40b in Ffuncall (nargs=2, args=0xcfbc0270) at eval.c:3081 #17 0x081b1a7a in Fbyte_code (bytestr=136981257, vector=136981277, maxdepth=Variable "maxdepth" is not available. ) at bytecode.c:680 #18 0x0817afc4 in funcall_lambda (fun=136981229, nargs=0, arg_vector=0xcfbc03b4) at eval.c:3211 #19 0x0817b40b in Ffuncall (nargs=1, args=0xcfbc03b0) at eval.c:3081 #20 0x081b1a7a in Fbyte_code (bytestr=136584897, vector=136584917, maxdepth=Variable "maxdepth" is not available. ) at bytecode.c:680 #21 0x0817afc4 in funcall_lambda (fun=136584877, nargs=0, arg_vector=0xcfbc04f4) at eval.c:3211 #22 0x0817b40b in Ffuncall (nargs=1, args=0xcfbc04f0) at eval.c:3081 #23 0x081b1a7a in Fbyte_code (bytestr=136581841, vector=136581861, maxdepth=Variable "maxdepth" is not available. ) at bytecode.c:680 #24 0x0817afc4 in funcall_lambda (fun=136581821, nargs=0, arg_vector=0xcfbc05c0) at eval.c:3211 #25 0x0817b1da in apply_lambda (fun=136581821, args=138212354, eval_flag=1) at eval.c:3135 #26 0x0817a872 in Feval (form=138744462) at eval.c:2406 #27 0x08115813 in top_level_2 () at keyboard.c:1369 #28 0x08179eab in internal_condition_case (bfun=0x8115800 , handlers=138485930, hfun=0x8119a10 ) at eval.c:1490 #29 0x081197a0 in top_level_1 () at keyboard.c:1377 #30 0x08179f65 in internal_catch (tag=138481026, func=0x8119770 , arg=138212354) at eval.c:1226 #31 0x08119849 in command_loop () at keyboard.c:1332 #32 0x08119beb in recursive_edit_1 () at keyboard.c:954 #33 0x08119d21 in Frecursive_edit () at keyboard.c:1016 #34 0x0810efac in main (argc=1, argv=0xcfbc08c8) at emacs.c:1833 Lisp Backtrace: "make-frame-visible" (0xcfbbfff4) "x-create-frame-with-faces" (0xcfbc0134) "make-frame" (0xcfbc0274) "frame-initialize" (0xcfbc03b4) "command-line" (0xcfbc04f4) "normal-top-level" (0xcfbc05c0) (gdb) --8<---cut here---end--->8--- Also a fstat -s on this process shows that it never stops reading on fd=5. Is there any other tests I could do to resolve this issue? emacs.tgz Description: Unix tar archive -- Manuel Giraud
binary newsreader
Hi, Is porting this nzb grabber (http://sabnzbd.org) worth it? Or hellanzb (maybe slrn) is good enough? -- Manuel Giraud
emacs 23.2 (the return)
Hi, Now that port is unlocked i've retested this port against a yesterday's current (GENERIC i386) and all seems to run fine now (no more startup freeze anymore). Anyone to test on other archs (and eventually, we'll have more recent emacs in OpenBSD 5.0) ? emacs.tgz Description: Unix tar archive -- Manuel Giraud
Re: emacs 23.2 (the return)
Matthias Guedemann writes: > On GENERIC i386, emacs (GTK) hangs when starting the ediff mode. Oh my... I'll try it. > What was the culprit when emacs started? Perhaps it is similar here. When emacs was started, sometimes (not always) it was completely unresponsive. Some test (but no real explanation) here: http://thread.gmane.org/gmane.os.openbsd.ports/44648/ -- Manuel Giraud
Re: emacs 23.2 (the return)
Manuel Giraud writes: > Matthias Guedemann writes: > >> On GENERIC i386, emacs (GTK) hangs when starting the ediff mode. > > Oh my... I'll try it. I've just tested M-x ediff a couple of time without issue. Could you retry it with emacs -Q ? -- Manuel Giraud
Re: emacs 23.2 (the return)
"Christiano F. Haesbaert" writes: > Attached is dmesg and pkg_info output. > > OpenBSD 4.9-beta (GENERIC.MP) #778: Sun Feb 13 17:39:24 MST 2011 > t...@i386.openbsd.org:/usr/src/sys/arch/i386/compile/GENERIC.MP Ok. I run the port against GENERIC.MP this time and the startup lock is still here (there were no trouble on GENERIC). I remade a gdb backtrace after killing -ABRT the process: --8<---cut here---start->8--- (gdb) backtrace #0 0x567283a9 in poll () from /usr/lib/libc.so.58.0 #1 0x52547898 in select (numfds=6, readfds=0xcfbf56ac, writefds=0xcfbf562c, exceptfds=0x0, timeout=0x0) at /usr/src/lib/libpthread/uthread/uthread_select.c:166 #2 0x48e08c74 in _xcb_conn_wait (c=0x8926000, cond=0xcfbf57a0, vector=0x0, count=0x0) at /usr/xenocara/lib/libxcb/libxcb/../../../dist/libxcb/src/xcb_conn.c:327 #3 0x48e0794a in xcb_wait_for_reply (c=0x8926000, request=178681, e=0xcfbf57f8) at /usr/xenocara/lib/libxcb/libxcb/../../../dist/libxcb/src/xcb_in.c:378 #4 0x4c980e63 in _XReply () from /usr/X11R6/lib/libX11.so.14.0 #5 0x4c9749aa in XSync () from /usr/X11R6/lib/libX11.so.14.0 #6 0x0812371a in x_sync (f=0x88d6600) at xfns.c:4265 #7 0x08119931 in x_make_frame_visible (f=0x88d6600) at xterm.c:9346 #8 0x08065110 in Fmake_frame_visible (frame=143484421) at frame.c:1848 #9 0x081faba1 in Ffuncall (nargs=2, args=0xcfbf59b0) at eval.c:3024 #10 0x082455d6 in Fbyte_code (bytestr=137221513, vector=137221533, maxdepth=20) at bytecode.c:680 #11 0x081fb3bc in funcall_lambda (fun=137221469, nargs=1, arg_vector=0xcfbf5d04) at eval.c:3211 #12 0x081fae30 in Ffuncall (nargs=2, args=0xcfbf5d00) at eval.c:3070 #13 0x082455d6 in Fbyte_code (bytestr=137668905, vector=137668925, maxdepth=24) at bytecode.c:680 #14 0x081fb3bc in funcall_lambda (fun=137668861, nargs=1, arg_vector=0xcfbf6054) at eval.c:3211 #15 0x081fae30 in Ffuncall (nargs=2, args=0xcfbf6050) at eval.c:3070 #16 0x082455d6 in Fbyte_code (bytestr=137666169, vector=137666189, maxdepth=24) at bytecode.c:680 #17 0x081fb3bc in funcall_lambda (fun=137666141, nargs=0, arg_vector=0xcfbf63a4) at eval.c:3211 #18 0x081fae30 in Ffuncall (nargs=1, args=0xcfbf63a0) at eval.c:3070 #19 0x082455d6 in Fbyte_code (bytestr=137269841, vector=137269861, maxdepth=28) at bytecode.c:680 #20 0x081fb3bc in funcall_lambda (fun=137269821, nargs=0, arg_vector=0xcfbf66f4) at eval.c:3211 #21 0x081fae30 in Ffuncall (nargs=1, args=0xcfbf66f0) at eval.c:3070 #22 0x082455d6 in Fbyte_code (bytestr=137266785, vector=137266805, maxdepth=24) at bytecode.c:680 #23 0x081fb3bc in funcall_lambda (fun=137266765, nargs=0, arg_vector=0xcfbf6990) at eval.c:3211 #24 0x081fb06e in apply_lambda (fun=137266765, args=138896386, eval_flag=1) at eval.c:3135 #25 0x081f9ead in Feval (form=139427358) at eval.c:2388 #26 0x0816c737 in top_level_2 () at keyboard.c:1369 #27 0x081f862c in internal_condition_case (bfun=0x816c724 , handlers=139169986, hfun=0x816c36d ) at eval.c:1490 #28 0x0816c76b in top_level_1 () at keyboard.c:1377 #29 0x081f8172 in internal_catch (tag=139165082, func=0x816c739 , arg=138896386) at eval.c:1226 #30 0x0816c6a9 in command_loop () at keyboard.c:1332 #31 0x0816bf7a in recursive_edit_1 () at keyboard.c:954 #32 0x0816c0e8 in Frecursive_edit () at keyboard.c:1016 #33 0x0816a8ff in main (argc=1, argv=0xcfbf6dc4) at emacs.c:1833 --8<---cut here---end--->8--- I need some insights to go further. -- Manuel Giraud
Re: emacs 23.2 (the return)
Matthew Dempsky writes:
> On Wed, Mar 9, 2011 at 5:07 AM, Manuel Giraud
> wrote:
>> Anyone to test on other archs (and eventually, we'll have more recent
>> emacs in OpenBSD 5.0) ?
>
> Seems to work on amd64.
>
> I noticed that "make port-lib-depends-check" says that the X11-xcb
> WANTLIB is extraneous.
I have now removed it.
> Also, is it correct that bin/emacs and bin/emacs-${VERSION} aren't
> marked as @bin in pkg/PLIST-main? It seems to be because the
> executables are installed with the sticky bit.
I've just used "make update-plist". It might be related to the sticky
bit but I don't if it is important or not.
--
Manuel Giraud
Re: emacs 23.2 (the return)
Stuart Henderson writes: >> I've just used "make update-plist". It might be related to the sticky >> bit but I don't if it is important or not. > > This will be related to the sticky bit; update-plist uses file to > identify file types and the bit will have changed the output. > > If you read sticky(8) you'll see there's no point in having > the sticky bit set... It is an obsolete feature but it seems to be caused by the emacs install process. Don't know if it worth the effort to fight for it upstream. -- Manuel Giraud
Re: re emacs23 update
Mike Belopuhov writes: > re, > > it turns out that SIGIO handling in emacs incorporates too many > workarounds, especially when running under X and at this point > it's impossible (at least for me) to grasp through the code and > find why it fails to work with xcb or X in general. > > but fortunately there's a tweak (DISABLE_SIGIO) that makes it > use poll exclusively and fixes everything! > > and also, there's an emacs 23.3 released already. > > cheers. Thank you. I'll update the port with 23.3, your patch and others' comments and repost ASAP. Just out of curiousity, how did you trace such bug? I ended up lost in uthread lib. -- Manuel Giraud
Re: re emacs23 update
Here's the new version of emacs 23 port. Tested and ok on i386 GENERIC.MP emacs.tgz Description: Unix tar archive -- Manuel Giraud
Re: re emacs23 update
Another round. Tested on i386 GENERIC.MP and "emacs --batch -f byte-compile-file": ok. emacs.tgz Description: Unix tar archive -- Manuel Giraud
Re: re emacs23 update
David Coppa writes: > On Wed, Mar 16, 2011 at 1:21 PM, Manuel Giraud > wrote: >> >> Another round. Tested on i386 GENERIC.MP and "emacs --batch -f >> byte-compile-file": ok. > > What's about this? Can it be committed? I didn't have report on other arch of this last version with Mike Belopuhov patch. -- Manuel Giraud
emacs
Hi, I just saw that you've commited editors/emacs23 why didn't you make it editors/emacs and get rid of old emacs21 and emacs22 version? It seems extra work to maintain these old versions, no? -- Manuel Giraud
[NEW] emacs 23.2
Hi, Here's an attempt of an emacs 23.2 port. Notes: - gtk is the default toolkit (athena is now a flavor) - the port is named "emacs" and not "emacs23" - I didn't add the patches from "emacs22" (AFAICT hppa issue is fixed by default and there is no trace of "mips64-*-openbsd*" in the new configure.in). emacs23.2.tar.gz Description: Binary data -- Manuel Giraud
Re: [NEW] emacs 23.2
"Christiano F. Haesbaert" writes: > I found some issues: > 1 - I can't see the character where the pointer is (it fades in and > out). Blinking cursor is on by default (for quite some time now): "Options/Blinking Cursor" if you have the menubar or "M-x customize-apropos / blink" > 2 - I can see a significant slow down comparing to emacs 22, don't > know if it's just the version bump. Slowdown maybe. Significant not here. > My completion window buffers now split vertically not horizontally, I > don't remember it changing on emacs 23 as I use it everyday in a linux > box, but I'm sure this isn't port related. Look at the "Changes affecting display-buffer" entry here: http://web.cvs.savannah.gnu.org/viewvc/emacs/NEWS.23.1?revision=1.1&root=emacs&view=markup It might be related to your display resolution on linux. > I remember something about emacs having to be patched when propolice > was added, I think it was on a Theo presentation, can't remember > though, but it might be related. There still is a "-fno-stack-protector" for powerpc architecture in this port but I don't know (and cannot test) if it is still revelant. I'd like to have opinions or tests regarding the mips64 patches. -- Manuel Giraud
Re: [NEW] emacs 23.2
New version with correct WANTLIB and LIB_DEPENDS usage and a "wishful thinking" remove of the propolice workaround for powerpc. emacs23.2.tar.gz Description: Binary data -- Manuel Giraud
PATCH: celestia + cspice
Hi,
Here is a patch for the current celestia ports that add a spice flavor
(see previous message about astro/cspice).
I haven't emailed the patch to the celestia author because this part seems
(from subversion repo) to have been completely rewritten for the next
celestia release.
? patches/patch-src_celengine_spiceorbit_cpp
? patches/patch-src_celengine_spicerotation_cpp
Index: Makefile
===
RCS file: /cvs/ports/astro/celestia/Makefile,v
retrieving revision 1.14
diff -u -p -r1.14 Makefile
--- Makefile17 Nov 2009 23:12:16 - 1.14
+++ Makefile18 Nov 2009 14:04:10 -
@@ -10,6 +10,9 @@ HOMEPAGE= http://www.shatters.net/celest
MAINTAINER=Antoine Jacoutot
+FLAVORS= spice
+FLAVOR?=
+
# GPLv2
PERMIT_PACKAGE_CDROM= Yes
PERMIT_PACKAGE_FTP=Yes
@@ -45,6 +48,12 @@ CONFIGURE_ARGS= ${CONFIGURE_SHARED} \
--with-lua \
--enable-cairo \
--enable-theora
+
+.if ${FLAVOR:L:Mspice}
+BUILD_DEPENDS+=::astro/cspice
+
+CONFIGURE_ARGS+= --with-cspice-dir=${PREFIX}
+.endif
pre-configure:
${SUBST_CMD} ${WRKSRC}/src/celestia/celestiacore.cpp
--
Manuel Giraud
patch-src_celengine_spiceorbit_cpp
Description: Binary data
patch-src_celengine_spicerotation_cpp
Description: Binary data
PATCH: celestia + cspice (fix)
Hi,
Here's some fix from Stuart comments:
Index: Makefile
===
RCS file: /cvs/ports/astro/celestia/Makefile,v
retrieving revision 1.14
diff -u -p -r1.14 Makefile
--- Makefile17 Nov 2009 23:12:16 - 1.14
+++ Makefile19 Nov 2009 12:17:42 -
@@ -10,6 +10,9 @@ HOMEPAGE= http://www.shatters.net/celest
MAINTAINER=Antoine Jacoutot
+FLAVORS= spice
+FLAVOR?=
+
# GPLv2
PERMIT_PACKAGE_CDROM= Yes
PERMIT_PACKAGE_FTP=Yes
@@ -45,6 +48,18 @@ CONFIGURE_ARGS= ${CONFIGURE_SHARED} \
--with-lua \
--enable-cairo \
--enable-theora
+
+.if ${FLAVOR:L:Mspice}
+
+# Can be bundled according to
+PERMIT_PACKAGE_CDROM= Yes
+PERMIT_PACKAGE_FTP=Yes
+
+BUILD_DEPENDS+=::astro/cspice
+
+CONFIGURE_ARGS+= --with-cspice-dir=${PREFIX}
+
+.endif
pre-configure:
${SUBST_CMD} ${WRKSRC}/src/celestia/celestiacore.cpp
Index: patches/patch-src_celengine_spiceorbit_cpp
===
RCS file: patches/patch-src_celengine_spiceorbit_cpp
diff -N patches/patch-src_celengine_spiceorbit_cpp
--- /dev/null 1 Jan 1970 00:00:00 -
+++ patches/patch-src_celengine_spiceorbit_cpp 19 Nov 2009 12:17:42 -
@@ -0,0 +1,12 @@
+$OpenBSD$
+--- src/celengine/spiceorbit.cpp.orig Mon Jun 22 17:44:08 2009
src/celengine/spiceorbit.cpp Wed Nov 18 10:46:18 2009
+@@ -128,7 +128,7 @@ SpiceOrbit::init(const string& path,
+ ktotal_c("spk", &spkCount);
+
+ // Get coverage window for target and origin object
+- const int MaxIntervals = 10;
++ const int MaxIntervals = 1000;
+ SPICEDOUBLE_CELL ( targetCoverage, MaxIntervals * 2 );
+
+ // Clear the coverage window.
Index: patches/patch-src_celengine_spicerotation_cpp
===
RCS file: patches/patch-src_celengine_spicerotation_cpp
diff -N patches/patch-src_celengine_spicerotation_cpp
--- /dev/null 1 Jan 1970 00:00:00 -
+++ patches/patch-src_celengine_spicerotation_cpp 19 Nov 2009 12:17:42
-
@@ -0,0 +1,25 @@
+$OpenBSD$
+--- src/celengine/spicerotation.cpp.orig Mon Jun 22 17:44:08 2009
src/celengine/spicerotation.cppWed Nov 18 10:50:50 2009
+@@ -170,9 +170,18 @@ SpiceRotation::computeSpin(double jd) const
+ }
+
+ #if 1
+-Mat3d m(Vec3d(xform[0][0], xform[0][1], xform[0][2]),
+-Vec3d(xform[1][0], xform[1][1], xform[1][2]),
+-Vec3d(xform[2][0], xform[2][1], xform[2][2]));
++double a00, a01, a02;
++double a10, a11, a12;
++double a20, a21, a22;
++
++a00 = xform[0][0]; a01 = xform[0][1]; a02 = xform[0][2];
++a10 = xform[1][0]; a11 = xform[1][1]; a12 = xform[1][2];
++a20 = xform[2][0]; a21 = xform[2][1]; a22 = xform[2][2];
++
++Mat3d m(Vec3d(a00, a01, a02),
++Vec3d(a10, a11, a12),
++Vec3d(a20, a21, a22));
++
+ #else
+ Mat3d m(Vec3d(xform[0][0], xform[1][0], xform[2][0]),
+ Vec3d(xform[0][1], xform[1][1], xform[2][1]),
--
Manuel Giraud
Re: PATCH: celestia + cspice (fix)
> On 2009/11/19 13:23, Manuel GIRAUD wrote: >> +# Can be bundled according to > > I don't think some private notification by email is enough here. > There's nothing in cspice's tar file with information about copyright > holders, permission to copy etc. so I think we would need to disable > distributing packages of the cspice flavour (certainly for CDROM, > probably also FTP). Alright, so be it. Should i resend the patch? -- Manuel Giraud
celestia + cspice
Here's a port of cspice and a patch for celestia to support it. Tested
on i386 and amd64.
Index: Makefile
===
RCS file: /cvs/ports/astro/celestia/Makefile,v
retrieving revision 1.14
diff -u -p -r1.14 Makefile
--- Makefile 17 Nov 2009 23:12:16 - 1.14
+++ Makefile 30 Nov 2009 16:50:45 -
@@ -10,6 +10,9 @@ HOMEPAGE= http://www.shatters.net/celest
MAINTAINER= Antoine Jacoutot
+FLAVORS= spice
+FLAVOR?=
+
# GPLv2
PERMIT_PACKAGE_CDROM= Yes
PERMIT_PACKAGE_FTP= Yes
@@ -45,6 +48,19 @@ CONFIGURE_ARGS= ${CONFIGURE_SHARED} \
--with-lua \
--enable-cairo \
--enable-theora
+
+.if ${FLAVOR:L:Mspice}
+
+# Might bundled according to
+PERMIT_PACKAGE_CDROM= No
+PERMIT_PACKAGE_FTP= No
+
+BUILD_DEPENDS+= ::astro/cspice
+
+CONFIGURE_ARGS+= --with-cspice-dir=${PREFIX}
+MESSAGE= ${PKGDIR}/MESSAGE-spice
+
+.endif
pre-configure:
${SUBST_CMD} ${WRKSRC}/src/celestia/celestiacore.cpp
Index: patches/patch-src_celengine_spiceorbit_cpp
===
RCS file: patches/patch-src_celengine_spiceorbit_cpp
diff -N patches/patch-src_celengine_spiceorbit_cpp
--- /dev/null 1 Jan 1970 00:00:00 -
+++ patches/patch-src_celengine_spiceorbit_cpp 30 Nov 2009 16:50:45 -
@@ -0,0 +1,12 @@
+$OpenBSD$
+--- src/celengine/spiceorbit.cpp.orig Mon Jun 22 17:44:08 2009
src/celengine/spiceorbit.cpp Wed Nov 18 10:46:18 2009
+@@ -128,7 +128,7 @@ SpiceOrbit::init(const string& path,
+ ktotal_c("spk", &spkCount);
+
+ // Get coverage window for target and origin object
+- const int MaxIntervals = 10;
++ const int MaxIntervals = 1000;
+ SPICEDOUBLE_CELL ( targetCoverage, MaxIntervals * 2 );
+
+ // Clear the coverage window.
Index: patches/patch-src_celengine_spicerotation_cpp
===
RCS file: patches/patch-src_celengine_spicerotation_cpp
diff -N patches/patch-src_celengine_spicerotation_cpp
--- /dev/null 1 Jan 1970 00:00:00 -
+++ patches/patch-src_celengine_spicerotation_cpp 30 Nov 2009 16:50:45 -
@@ -0,0 +1,25 @@
+$OpenBSD$
+--- src/celengine/spicerotation.cpp.orig Mon Jun 22 17:44:08 2009
src/celengine/spicerotation.cpp Wed Nov 18 10:50:50 2009
+@@ -170,9 +170,18 @@ SpiceRotation::computeSpin(double jd) const
+ }
+
+ #if 1
+-Mat3d m(Vec3d(xform[0][0], xform[0][1], xform[0][2]),
+-Vec3d(xform[1][0], xform[1][1], xform[1][2]),
+-Vec3d(xform[2][0], xform[2][1], xform[2][2]));
++double a00, a01, a02;
++double a10, a11, a12;
++double a20, a21, a22;
++
++a00 = xform[0][0]; a01 = xform[0][1]; a02 = xform[0][2];
++a10 = xform[1][0]; a11 = xform[1][1]; a12 = xform[1][2];
++a20 = xform[2][0]; a21 = xform[2][1]; a22 = xform[2][2];
++
++Mat3d m(Vec3d(a00, a01, a02),
++Vec3d(a10, a11, a12),
++Vec3d(a20, a21, a22));
++
+ #else
+ Mat3d m(Vec3d(xform[0][0], xform[1][0], xform[2][0]),
+ Vec3d(xform[0][1], xform[1][1], xform[2][1]),
Index: pkg/MESSAGE-spice
===
RCS file: pkg/MESSAGE-spice
diff -N pkg/MESSAGE-spice
--- /dev/null 1 Jan 1970 00:00:00 -
+++ pkg/MESSAGE-spice 30 Nov 2009 16:50:45 -
@@ -0,0 +1,2 @@
+Now, you can load NAIF spice kernels into celestia. See,
+http://en.wikibooks.org/wiki/Celestia/SPICE for an example.
cspice.tar.gz
Description: Binary data
--
Manuel Giraud
[error] libgphoto2
Hi, I'm trying to build emulators/wine from ports but end up with the following error in the graphics/libgphoto2 build: --8<- checking for ltdl.h... yes checking for lt_dlinit in -lltdl... no configure: error: libgphoto2 requires the ltdl library, included with libtool Please make sure that the proper development package is installed (libltdl-dev, libtool-ltdl-devel, etc.) *** Error code 1 Stop in /usr/ports/graphics/libgphoto2 (line 2168 of /usr/ports/infrastructure/mk/bsd.port.mk). --8<- I don't know how to fix this. I'm in i386-current from yesterday with a sync ports tree and up to date packages (w/ libltdl-1.5.26p0 and libtool-1.5.26p2). Side question: How to find out if a port will have an ftp package pre-built? (e.g. wine don't have one) -- Manuel Giraud
Re: [error] libgphoto2
Stuart Henderson writes: > It's unfinished work, it's currently no use unless you're hacking on > it. Actually not. I'll wait. > config.log might have some clues. Maybe. I could also have used the prebuilt package. While I'm here : why the ports framework doesn't try to fetch prebuilt package first? Is that on purpose? Useless? Not easy? Not convenient? > If it's not listed in Makefile in the parent directory, it won't > be built. If it's marked PERMIT_FTP_PACKAGE= > packages won't show up on ftp. And of course if it fails in the bulk > build it will also not show up. Ok, thank you I can look up in the Makefiles (still the quickest answer will be a "Not found" from pkg_add). -- Manuel Giraud
Re: [error] libgphoto2
Stuart Henderson writes: > On 2010/01/13 15:04, Manuel Giraud wrote: > >> configure:16406: cc -o conftest -O2 -pipe -Wall -Wmissing-declarations >> -Wmissing-prototypes -I/usr/local/include -I$(top_srcdir) -I$(top_builddir) >> -I$(top_srcdir)/libgphoto2_port -I$(top_srcdir)/libgphoto2 >> -I$(top_builddir)/libgphoto2 -I/usr/local/include -Wall -g >> -D_GPHOTO2_INTERNAL_CODE -L/usr/local/lib conftest.c -lltdl >&5 >> /usr/local/lib/libltdl.so.4.5: file not recognized: File format not >> recognized > > Please try pkg_create -n -f /var/db/pkg/libltdl-*/+CONTENTS > and look for any "checksum inconsistency" in the output. Everything seems ok: $ pkg_create -n -f /var/db/pkg/libltdl-1.5.26p0/+CONTENTS Adding +CONTENTS Adding +DESC Cwd: /usr/local Adding include/ltdl.h Adding lib/libltdl.a Adding lib/libltdl.la Adding share/aclocal/ltdl.m4 Adding share/libtool/libltdl/COPYING.LIB Adding share/libtool/libltdl/Makefile.am Adding share/libtool/libltdl/Makefile.in Adding share/libtool/libltdl/README Adding share/libtool/libltdl/acinclude.m4 Adding share/libtool/libltdl/aclocal.m4 Adding share/libtool/libltdl/config-h.in Adding share/libtool/libltdl/config.guess Adding share/libtool/libltdl/config.sub Adding share/libtool/libltdl/configure Adding share/libtool/libltdl/configure.ac Adding share/libtool/libltdl/install-sh Adding share/libtool/libltdl/ltdl.c Adding share/libtool/libltdl/ltdl.h Adding share/libtool/libltdl/ltmain.sh Adding share/libtool/libltdl/missing Adding lib/libltdl.so.4.5 -- Manuel Giraud
Re: [NEW] vimprobable-20100105
nealHogan writes: > It should work now. I was about to tried, but now: $ tar ztvf /usr/ports/distfiles/vimprobable-20100105.tar.gz drwxrwxr-x 2 root wsrc 0 Jan 13 00:36 www/vimprobable -rwxrwxr-x 1 root wsrc 893 Jan 13 00:27 www/vimprobable/Makefile -rw-r--r-- 1 manuel wsrc 322 Jan 12 05:06 www/vimprobable/distinfo drwxrwxr-x 2 root wsrc 0 Jan 13 00:25 www/vimprobable/patches -rw-r--r-- 1 root wsrc 820 Jan 13 00:18 www/vimprobable/patches/patch-Makefile -rw-r--r-- 1 manuel wsrc 679 Jan 12 23:54 www/vimprobable/patches/patch-config_h drwxrwxr-x 2 root wsrc 0 Jan 5 22:10 www/vimprobable/pkg -rwxrwxr-x 1 root wsrc 100 Jan 5 22:08 www/vimprobable/pkg/PLIST -rwxrwxr-x 1 root wsrc 248 Jan 5 22:10 www/vimprobable/pkg/DESCR Don't look like a distfile. -- Manuel Giraud
emacs23
Hi, Has anybody worked on an emacs23 ports? If not I'd like to try. -- Manuel Giraud
tree-sitter grammars
Hi, AFAIU, tree-sitter needs grammar "libraries" to support some programming language. Emacs will have tree-sitter support in the next version (29.1) but won't distribute such libraries. In our tree, I can see that neovim is also using tree-sitter but I don't know how those language libraries are handled here. Do we have a tree-sitter-grammars package? If not, do we need one? Should it be a bundle of grammars or should we have one package per language? Emacs provides this script: https://git.savannah.gnu.org/cgit/emacs.git/tree/admin/notes/tree-sitter/build-module/build.sh that could be a starting point for one (or some) ports. Thanks, -- Manuel Giraud
[old NEW] ttyp0 font
Hi, Here is a nice monospace bitmap font I'm using that is in my mystuff's port for quite some time now. Maybe this could go in if someone is interested. uw-ttyp0.tar.gz Description: Unix tar archive -- Manuel Giraud
Re: NEW: fonts/ttyp0-font
Stuart Henderson writes: > let's go for chrisz's version of this, the flavour handling is easier > to deal with, and he has already got it converting to otb (pcf bitmap > fonts are no longer widely supported). I don't know much about font file format. But neat! (i think) > - don't set nbs flavour by default, i'd also be sort-of ok without this > but it's not very intuitive to run "FLAVOR= make" if you want the default > version I too am ok to keep the defaults as default. -- Manuel Giraud
Re: NEW: fonts/ttyp0-font
Stuart Henderson writes: > at least all of the single flavours: > > SUBDIR += ttyp0-font,sq > SUBDIR += ttyp0-font,ct > SUBDIR += ttyp0-font,nbd > SUBDIR += ttyp0-font,sz > > others by request I guess? maybe nbs,sz too (as terminus as already a slashed zero). -- Manuel Giraud
[Update] devel/avr/gcc: 5.4.0 -> 8.4.0
/include/tree-pre
lib/gcc/avr/${V}/plugin/include/tree-scalar-evolution.h
lib/gcc/avr/${V}/plugin/include/tree-ssa-address.h
lib/gcc/avr/${V}/plugin/include/tree-ssa-alias.h
+lib/gcc/avr/${V}/plugin/include/tree-ssa-ccp.h
lib/gcc/avr/${V}/plugin/include/tree-ssa-coalesce.h
+lib/gcc/avr/${V}/plugin/include/tree-ssa-dce.h
lib/gcc/avr/${V}/plugin/include/tree-ssa-dom.h
lib/gcc/avr/${V}/plugin/include/tree-ssa-live.h
lib/gcc/avr/${V}/plugin/include/tree-ssa-loop-ivopts.h
@@ -691,6 +785,8 @@ lib/gcc/avr/${V}/plugin/include/tree-ssa
lib/gcc/avr/${V}/plugin/include/tree-ssa-operands.h
lib/gcc/avr/${V}/plugin/include/tree-ssa-propagate.h
lib/gcc/avr/${V}/plugin/include/tree-ssa-sccvn.h
+lib/gcc/avr/${V}/plugin/include/tree-ssa-scopedtables.h
+lib/gcc/avr/${V}/plugin/include/tree-ssa-strlen.h
lib/gcc/avr/${V}/plugin/include/tree-ssa-ter.h
lib/gcc/avr/${V}/plugin/include/tree-ssa-threadedge.h
lib/gcc/avr/${V}/plugin/include/tree-ssa-threadupdate.h
@@ -698,7 +794,9 @@ lib/gcc/avr/${V}/plugin/include/tree-ssa
lib/gcc/avr/${V}/plugin/include/tree-ssanames.h
lib/gcc/avr/${V}/plugin/include/tree-stdarg.h
lib/gcc/avr/${V}/plugin/include/tree-streamer.h
+lib/gcc/avr/${V}/plugin/include/tree-vector-builder.h
lib/gcc/avr/${V}/plugin/include/tree-vectorizer.h
+lib/gcc/avr/${V}/plugin/include/tree-vrp.h
lib/gcc/avr/${V}/plugin/include/tree.def
lib/gcc/avr/${V}/plugin/include/tree.h
lib/gcc/avr/${V}/plugin/include/treestruct.def
@@ -710,17 +808,21 @@ lib/gcc/avr/${V}/plugin/include/ubsan.h
lib/gcc/avr/${V}/plugin/include/valtrack.h
lib/gcc/avr/${V}/plugin/include/value-prof.h
lib/gcc/avr/${V}/plugin/include/varasm.h
+lib/gcc/avr/${V}/plugin/include/vec-perm-indices.h
lib/gcc/avr/${V}/plugin/include/vec.h
+lib/gcc/avr/${V}/plugin/include/vector-builder.h
lib/gcc/avr/${V}/plugin/include/version.h
lib/gcc/avr/${V}/plugin/include/vmsdbg.h
+lib/gcc/avr/${V}/plugin/include/vr-values.h
lib/gcc/avr/${V}/plugin/include/vtable-verify.h
+lib/gcc/avr/${V}/plugin/include/wide-int-bitmask.h
lib/gcc/avr/${V}/plugin/include/wide-int-print.h
lib/gcc/avr/${V}/plugin/include/wide-int.h
lib/gcc/avr/${V}/plugin/include/xcoff.h
lib/gcc/avr/${V}/plugin/include/xcoffout.h
lib/gcc/avr/${V}/tiny-stack/
-lib/gcc/avr/${V}/tiny-stack/libgcc.a
-lib/gcc/avr/${V}/tiny-stack/libgcov.a
+@static-lib lib/gcc/avr/${V}/tiny-stack/libgcc.a
+@static-lib lib/gcc/avr/${V}/tiny-stack/libgcov.a
libexec/gcc/
libexec/gcc/avr/
libexec/gcc/avr/${V}/
@@ -733,7 +835,7 @@ libexec/gcc/avr/${V}/install-tools/fixin
libexec/gcc/avr/${V}/install-tools/mkheaders
libexec/gcc/avr/${V}/install-tools/mkinstalldirs
libexec/gcc/avr/${V}/liblto_plugin.la
-libexec/gcc/avr/${V}/liblto_plugin.so
+@so libexec/gcc/avr/${V}/liblto_plugin.so
@bin libexec/gcc/avr/${V}/lto-wrapper
@bin libexec/gcc/avr/${V}/lto1
libexec/gcc/avr/${V}/plugin/
@@ -741,6 +843,8 @@ libexec/gcc/avr/${V}/plugin/
@man man/man1/avr-cpp.1
@man man/man1/avr-g++.1
@man man/man1/avr-gcc.1
+@man man/man1/avr-gcov-dump.1
+@man man/man1/avr-gcov-tool.1
@man man/man1/avr-gcov.1
@comment @man man/man7/fsf-funding.7
@comment @man man/man7/gfdl.7
--
Manuel Giraud
[New] uw-ttyp0 font
Hi, Here is a port of yet another monospace font. (preview here: https://people.mpi-inf.mpg.de/~uwe/misc/uw-ttyp0/sample-8x16.html) uw-ttyp0.tar.gz Description: Unix tar archive -- Manuel Giraud
Re: [New] uw-ttyp0 font
Stuart Henderson writes: > On 2017/09/25 08:30, Manuel Giraud wrote: >> Hi, >> >> Here is a port of yet another monospace font. >> (preview here: >> https://people.mpi-inf.mpg.de/~uwe/misc/uw-ttyp0/sample-8x16.html) >> > > After unlock, please re-submit with these changes: > > - rename centeredtilde to centered_tilde, so it matches the existing > terminus-font flavour name. also needs to be added to FLAVORS. Ok. (same for zeroslashed to zero_slashed?) > - flavours should be mentioned in pkg/DESCR Ok. > - don't generate fonts.alias/fonts.dir yourself, it should use > @fontdir in PLIST instead This one, I didn't understand. Do you mean that the ports infrastructure will take care of generating/installing those files just by declaring them @fontdir in PLIST ? -- Manuel Giraud
Re: [New] uw-ttyp0 font
Manuel Giraud writes: > This one, I didn't understand. Do you mean that the ports infrastructure > will take care of generating/installing those files just by declaring > them @fontdir in PLIST ? Ok, I've just tested and declaring @fontdir is enough to generate fonts.dir, fonts.alias ans fonts.scale: cool! BTW, terminus-font still generate them. -- Manuel Giraud
[NEW] uw-ttyp0 font
Hi, Maybe the ports tree is unlocked now so I'm reposting this nice font: https://people.mpi-inf.mpg.de/~uwe/misc/uw-ttyp0/ uw-ttyp0.tar.gz Description: Unix tar archive -- Manuel Giraud
Re: [pretest] emacs-26.0.90
Jeremie Courreges-Anglas writes: > Here's a diff for the first pretest in the emacs-26 release cycle. > Among other things, emacs now uses system malloc(3) at runtime (gmalloc > is still used at build/unexec time). > > As usual build & test reports are welcome, especially if you use an arch > different from amd64 / arm, or if you use one of the graphical > flavors. Using amd64/athena since two days now without issue. -- Manuel Giraud
emacs 24 pretest
Hi, Here's a port of the pretest version of emacs 24. I'm using it right now on -current i386. It is intended to people willing to test it on other arch. The "real" port will have to wait the 24.1 release. emacs24.tgz Description: Unix tar archive -- Manuel Giraud
Re: UPDATE: maxima-5.26.0
Edd Barrett writes: > Hi, > > Update to maxima-5.26.0. All regression tests passing on amd64. > > OK? Compiles and works on i386. Only one failed test in make regress: Running tests in rtest8: ** Problem 104 *** Input: ev(e5, au = 0, omega = 2) Result: - u quad_qawf(%e , u, 0, 2, sin, epsabs = 1.e-10, limit = 32, maxp1 = 100, limlst = 10 ) This differed from the expected result: [.4001, 2.216570948815925e-11, 175, 0] 161/162 tests passed The following 1 problem failed: (104) -- Manuel Giraud
Re: UPDATE: maxima-5.26.0
Edd Barrett writes: > Did this fail before? Yes exact same failure with previous version. -- Manuel Giraud
emacs 23.3b -> 23.4
Hi,
Here's an update to emacs23 fixing a security issue described here:
http://lists.gnu.org/archive/html/emacs-devel/2012-01/msg00387.html
Index: Makefile
===
RCS file: /cvs/ports/editors/emacs23/Makefile,v
retrieving revision 1.13
diff -u -r1.13 Makefile
--- Makefile21 Jan 2012 23:10:18 - 1.13
+++ Makefile30 Jan 2012 13:29:26 -
@@ -3,11 +3,11 @@
COMMENT-main = GNU editor: extensible, customizable, self-documenting
COMMENT-el = elisp sources for those who want to read/modify them
-VERSION = 23.3
-WRKDIST = ${WRKDIR}/emacs-23.3
-DISTNAME = emacs-${VERSION}b
-PKGNAME-main = emacs-${VERSION}b
-FULLPKGNAME-el = emacs-el-${VERSION}b
+VERSION = 23.4
+WRKDIST = ${WRKDIR}/emacs-23.4
+DISTNAME = emacs-${VERSION}
+PKGNAME-main = emacs-${VERSION}
+FULLPKGNAME-el = emacs-el-${VERSION}
FULLPKGPATH-el = editors/emacs23,-el
CATEGORIES = editors
@@ -79,7 +79,7 @@
xcb-render xcb-shm ${MODGETTEXT_WANTLIB}
.endif
-RUN_DEPENDS-el = emacs-${VERSION}b:${PKGPATH}
+RUN_DEPENDS-el = emacs-${VERSION}:${PKGPATH}
PKG_ARCH-el = *
post-install:
Index: distinfo
===
RCS file: /cvs/ports/editors/emacs23/distinfo,v
retrieving revision 1.2
diff -u -r1.2 distinfo
--- distinfo21 Jan 2012 13:54:51 - 1.2
+++ distinfo30 Jan 2012 13:29:26 -
@@ -1,5 +1,5 @@
-MD5 (emacs-23.3b.tar.gz) = 8r/Y6rfjs0oPfwmswGZ+cQ==
-RMD160 (emacs-23.3b.tar.gz) = 0lOHTs71wJ01V2z1CHJ/WGPICDQ=
-SHA1 (emacs-23.3b.tar.gz) = VlA0cumbx8h17DcN7HtAd0z6gto=
-SHA256 (emacs-23.3b.tar.gz) = Vstttxep65Z54SRmVZg3xAR6F1yJ2MxNidTDeFYjIPk=
-SIZE (emacs-23.3b.tar.gz) = 47930061
+MD5 (emacs-23.4.tar.gz) = NEBRZfzZePvIswTL2ZzPTw==
+RMD160 (emacs-23.4.tar.gz) = X7fkzUJwpSS4cjrYahRaDkcza/c=
+SHA1 (emacs-23.4.tar.gz) = CnhGb/9S0fQ8DbDqZmUaCxO35HM=
+SHA256 (emacs-23.4.tar.gz) = uaK4Q0BSdx95fSAydy66hi/5qhQwKe/HIpUXBgconBg=
+SIZE (emacs-23.4.tar.gz) = 47721193
--
Manuel Giraud
Re: emacs 23.3b -> 23.4
Stuart Henderson writes: > Does this issue affect previous emacs branches or is it just 23.x? It is affecting CEDET (http://cedet.sourceforge.net). I've just checked that emacs 22.3 doesn't even have a lisp/cedet/ directory so I guess the answer is "only 23.x" -- Manuel Giraud
Re: Racket port for testing
Lars Engblom writes: > Hello, > > Here comes a port of Racket for testing. > > I have been testing it on a clean install of -current on amd64 and it > is working. > > I have not got it to build on i386 (I get segfault). The question is, > is it possible to crank up some sysctl values for i386 build to > succeed or will this be an amd64-only port? This is why i have those > comments still left in the Makefile. I was able to compile on this: OpenBSD 5.1-current (GENERIC.MP) #202: Thu Mar 15 18:33:09 MDT 2012 dera...@i386.openbsd.org:/usr/src/sys/arch/i386/compile/GENERIC.MP I have run drracket and test some examples (including a "web server" and graphical one) from their website. Thanks for this port. -- Manuel Giraud
Re: Racket port for testing
hci1: USB revision 2.0 uhub1 at usb1 "Intel EHCI root hub" rev 2.00/1.00 addr 1 ppb3 at pci0 dev 30 function 0 "Intel 82801BA Hub-to-PCI" rev 0xa2 pci4 at ppb3 bus 4 pcib0 at pci0 dev 31 function 0 "Intel 82801JDO LPC" rev 0x02 pciide1 at pci0 dev 31 function 2 "Intel 82801JD SATA" rev 0x02: DMA, channel 0 configured to native-PCI, channel 1 configured to native-PCI pciide1: using apic 8 int 18 for native-PCI interrupt wd0 at pciide1 channel 0 drive 0: wd0: 16-sector PIO, LBA48, 152587MB, 31250 sectors wd0(pciide1:0:0): using PIO mode 4, Ultra-DMA mode 6 atapiscsi0 at pciide1 channel 1 drive 0 scsibus0 at atapiscsi0: 2 targets cd0 at scsibus0 targ 0 lun 0: ATAPI 5/cdrom removable cd0(pciide1:1:0): using PIO mode 4, Ultra-DMA mode 5 ichiic0 at pci0 dev 31 function 3 "Intel 82801JD SMBus" rev 0x02: apic 8 int 18 iic0 at ichiic0 spdmem0 at iic0 addr 0x50: 2GB DDR2 SDRAM non-parity PC2-6400CL5 spdmem1 at iic0 addr 0x52: 2GB DDR2 SDRAM non-parity PC2-6400CL5 pciide2 at pci0 dev 31 function 5 "Intel 82801JD SATA" rev 0x02: DMA, channel 0 wired to native-PCI, channel 1 wired to native-PCI pciide2: using apic 8 int 18 for native-PCI interrupt usb2 at uhci0: USB revision 1.0 uhub2 at usb2 "Intel UHCI root hub" rev 1.00/1.00 addr 1 usb3 at uhci1: USB revision 1.0 uhub3 at usb3 "Intel UHCI root hub" rev 1.00/1.00 addr 1 usb4 at uhci2: USB revision 1.0 uhub4 at usb4 "Intel UHCI root hub" rev 1.00/1.00 addr 1 usb5 at uhci3: USB revision 1.0 uhub5 at usb5 "Intel UHCI root hub" rev 1.00/1.00 addr 1 usb6 at uhci4: USB revision 1.0 uhub6 at usb6 "Intel UHCI root hub" rev 1.00/1.00 addr 1 usb7 at uhci5: USB revision 1.0 uhub7 at usb7 "Intel UHCI root hub" rev 1.00/1.00 addr 1 isa0 at pcib0 isadma0 at isa0 com0 at isa0 port 0x3f8/8 irq 4: ns16550a, 16 byte fifo pckbc0 at isa0 port 0x60/5 pckbd0 at pckbc0 (kbd slot) pckbc0: using irq 1 for kbd slot wskbd0 at pckbd0: console keyboard, using wsdisplay0 pcppi0 at isa0 port 0x61 spkr0 at pcppi0 lpt0 at isa0 port 0x378/4 irq 7 npx0 at isa0 port 0xf0/16: reported by CPUID; using exception 16 mtrr: Pentium Pro MTRR support umass0 at uhub0 port 1 configuration 1 interface 0 "Silicon-Power Luxmini-920" rev 2.00/1.00 addr 2 umass0: using SCSI over Bulk-Only scsibus1 at umass0: 2 targets, initiator 0 sd0 at scsibus1 targ 1 lun 0: SCSI2 0/direct removable serial.048d116805800019 sd0: 61888MB, 512 bytes/sector, 126746624 sectors uhidev0 at uhub4 port 1 configuration 1 interface 0 "TypeMatrix.com USB Keyboard" rev 1.10/1.30 addr 2 uhidev0: iclass 3/1 ukbd0 at uhidev0: 8 modifier keys, 6 key codes wskbd1 at ukbd0 mux 1 wskbd1: connecting to wsdisplay0 uhidev1 at uhub4 port 1 configuration 1 interface 1 "TypeMatrix.com USB Keyboard" rev 1.10/1.30 addr 2 uhidev1: iclass 3/1, 3 report ids uhid0 at uhidev1 reportid 1: input=1, output=0, feature=0 uhid1 at uhidev1 reportid 2: input=2, output=0, feature=0 uhid2 at uhidev1 reportid 3: input=2, output=1, feature=0 uhidev2 at uhub4 port 2 configuration 1 interface 0 "Dell Dell USB Optical Mouse" rev 2.00/43.01 addr 3 uhidev2: iclass 3/1 ums0 at uhidev2: 3 buttons, Z dir wsmouse0 at ums0 mux 0 vscsi0 at root scsibus2 at vscsi0: 256 targets softraid0 at root scsibus3 at softraid0: 256 targets root on sd0a (52f5d73a8c873468.a) swap on sd0b dump on sd0b sd1 at scsibus3 targ 1 lun 0: SCSI2 0/direct fixed sd1: 50908MB, 512 bytes/sector, 104261322 sectors -- Manuel Giraud
Emacs 24.1
Hi, Here's a port of the new version of emacs. Currently testing on i386. FWIW, I'm all for killing the emacs 23 port in the process. emacs24.tgz Description: Unix tar archive -- Manuel Giraud
Re: Emacs 24.1
Stuart Henderson writes:
> On 2012/06/11 10:22, Manuel Giraud wrote:
>> Hi,
>>
>> Here's a port of the new version of emacs. Currently testing on
>> i386.
>
> A couple of things I noticed reading the port,
>
> - missing desktop/icon-cache dependencies and @exec/unexec lines
What is this? I've done a make lib-depends-check and it seems happy.
> - mandoc isn't expected to handle gzipped manpages; /etc/man.conf does have
> settings to handle compressed manpages which work OK, but in general we don't
> use gzipped manpages in OpenBSD.
So you mean that this port's manpages should stay gzipped or is it ok to
gunzip them? By the way, I think it ought to be "gunzip
{realnames}.1.gz" instead of "gunzip *.1.gz", no?
> - minor but we don't generally start a new version with anything in
> REVISION-xx
Ok.
> - is there anything to indicate that the amd64/mips64 "gzip tsang-b5.el" parts
> are no longer needed?
It seems that all .el files are gzipped upon installation so I've just
removed this part.
>> FWIW, I'm all for killing the emacs 23 port in the process.
>
> Is there a reason to have more than "a current version" and 21.x anyway?
> i.e. would it make sense to just have editors/emacs21 and
> editors/emacs?
I follow you on this. The point to have emacs23 not replacing emacs22 is
that it seems to be a PITA to upgrade .emacs file from 22 to 23. I don't
know if the point still stands from 23 to 24 (in fact, it worked
gracefully for me).
--
Manuel Giraud
Re: Emacs 24.1
Hi, Here is another try, with: - a gtk3 flavor - xdg-utils run dependency (not for no_x11) - no more liboss - more correct PLIST I've spotted an issue: M-x report-emacs-bug doesn't work if the "-el" subpackage is not installed (don't know why maybe it's a bug to be reported). Do you think "-main" and "-el" subpackages could be merged into one big jumbo pack? emacs24.tgz Description: Unix tar archive -- Manuel Giraud
Re: Emacs 24.1
Juan Francisco Cantero Hurtado writes: > OK, I was wrong. Ctrl-x Ctrl-c doesn't close the emacs window (gtk3 > flavor). The same behavior with File->Quit. It works with the CLI > version of emacs (emacs -nw). Ouch, you're right. I seems to work ok for the athena flavor. I'll look into it but I think it is a tough one for me. -- Manuel Giraud
