Re: Emacs 24.1
On Sun, Jun 24, 2012 at 04:58:22AM +0200, Juan Francisco Cantero Hurtado wrote: > I've wasted one hour installing gnome and updating the other > packages. I've compiled the original port without my one-line change, > i.e. with gsettings enabled. I've open/close (exactly) 50 times emacs > with C-x C-c. I'm writing this mail with emacs on gnome. *All works > OK*. > > Also, it's not my port. The author is Manuel. I don't know if the port > is right or if is broken. I don't care. I can't judge the quality of > this port because I haven't read the ports documentation (but is in my > todo). Sometimes, I test some ports of this list because I think that > the tests are very important, but I never talk about quality of the > ports. I've been fighting (as a user) with compilations and > dependencies for almost 13 years, so I think that I can be a good > tester for the ports. > > I just wanted give a advice to other developers based on my > experience. The first was a bad advice, the later is correct in my > opinion. The developers are free of to listen my advice or not. I'll > not change my opinion about gsetting/gnome-setting-daemon for a long > time (despite of my very good experience with gnome on openbsd). > > Again, emacs and other gtk3 applications are broken but the fix is > very simple. I never said that gnome or gsettings are a bad thing. I > said that gsettings is the usual culprit because a lot of applications > have a broken implementation of gsettings. Also, usually gsettings is > not essential for the applications. > > Despite of the possible interpretations of my mail, I'm not upset or > something similar. Just this type of threads are very frustrating for > me. I waste a lots of time on tests for demostrating something obvious > for me and also is very exhausting for me to discuss in English. Look I am not saying you were upset or anything. But for some reason you do not want to trust me. I just tried emacs with gtk3 in fvwm and it works fine. The reason it probably does not work for you is that you don't have a dbus user session started up (gnome does this for you automatically). So, open a terminal then: $ eval `dbus-launch --auto-syntax` $ emacs ... C-x C-c And I will repeat again that your issue has _nothing_ to do with gnome nor gnome-settings-daemon whatsoever. Gsettings writes its stuffs in dconf; dconf is automatically started by dbus. I am not saying that is clever nor convenient but this is how it works. So don't blame gsettings itself if you do not fulfill its requirements. It would be like saying that mail/roundcube does not work because you didn't start a web server. That said, I have nothing against disabling gsettings in Emacs, I just wanted to explain how things worked. Cheers! -- Antoine
Re: Emacs 24.1
On Sun, Jun 24, 2012 at 10:13:33AM +0200, Antoine Jacoutot wrote: > On Sun, Jun 24, 2012 at 04:58:22AM +0200, Juan Francisco Cantero Hurtado > wrote: > > I've wasted one hour installing gnome and updating the other > > packages. I've compiled the original port without my one-line change, > > i.e. with gsettings enabled. I've open/close (exactly) 50 times emacs > > with C-x C-c. I'm writing this mail with emacs on gnome. *All works > > OK*. > > > > Also, it's not my port. The author is Manuel. I don't know if the port > > is right or if is broken. I don't care. I can't judge the quality of > > this port because I haven't read the ports documentation (but is in my > > todo). Sometimes, I test some ports of this list because I think that > > the tests are very important, but I never talk about quality of the > > ports. I've been fighting (as a user) with compilations and > > dependencies for almost 13 years, so I think that I can be a good > > tester for the ports. > > > > I just wanted give a advice to other developers based on my > > experience. The first was a bad advice, the later is correct in my > > opinion. The developers are free of to listen my advice or not. I'll > > not change my opinion about gsetting/gnome-setting-daemon for a long > > time (despite of my very good experience with gnome on openbsd). > > > > Again, emacs and other gtk3 applications are broken but the fix is > > very simple. I never said that gnome or gsettings are a bad thing. I > > said that gsettings is the usual culprit because a lot of applications > > have a broken implementation of gsettings. Also, usually gsettings is > > not essential for the applications. > > > > Despite of the possible interpretations of my mail, I'm not upset or > > something similar. Just this type of threads are very frustrating for > > me. I waste a lots of time on tests for demostrating something obvious > > for me and also is very exhausting for me to discuss in English. > > Look I am not saying you were upset or anything. It was just a comment because sometimes my mails seem a little upset. > But for some reason you do not want to trust me. I trust you. > I just tried emacs with gtk3 in fvwm and it works fine. The reason > it probably does not work for you is that you don't have a dbus user > session started up (gnome does this for you automatically). So, > open a terminal then: $ eval `dbus-launch --auto-syntax` $ emacs ... > C-x C-c I have "dbus_daemon" running but not a user session. With your suggestion, emacs works OK. > > And I will repeat again that your issue has _nothing_ to do with > gnome nor gnome-settings-daemon whatsoever. I resolved other issues running gnome-settings-daemon (the dbus user session was not the issue). I just blamed (wrongly) to the usual suspect. > Gsettings writes its stuffs in dconf; dconf is automatically started > by dbus. I am not saying that is clever nor convenient but this is > how it works. So don't blame gsettings itself if you do not fulfill > its requirements. It would be like saying that mail/roundcube does > not work because you didn't start a web server. You're right. > > That said, I have nothing against disabling gsettings in Emacs, I > just wanted to explain how things worked. Thanks for the explanation. If emacs works without problems, I'm not against of the gsetting support. > Cheers! If all the applications with gsettings support require a dbus user session, the FAQ should mention this, right?. It's better than my advice to other maintainers for to try the packages outside of gnome. If all people know this requirement, the extra tests are unnecessary. Cheers. -- Juan Francisco Cantero Hurtado http://juanfra.info
Re: Emacs 24.1
On Sun, Jun 24, 2012 at 10:13:33AM +0200, Antoine Jacoutot wrote: > So, open a terminal then: > $ eval `dbus-launch --auto-syntax` > $ emacs > ... Maybe it's time to add something like that in the default session scripts (untested): Index: app/xinit/xinitrc.cpp === RCS file: /cvs/OpenBSD/xenocara/app/xinit/xinitrc.cpp,v retrieving revision 1.6 diff -u -r1.6 xinitrc.cpp --- app/xinit/xinitrc.cpp 19 Mar 2011 15:40:02 - 1.6 +++ app/xinit/xinitrc.cpp 24 Jun 2012 12:23:20 - @@ -51,6 +51,11 @@ ssh-add < /dev/null fi +if test -x /usr/local/bin/dbus-launch -a -z "$DBUS_SESSION_BUS_ADDRESS" ; then + ## if not found, launch a new one +eval `dbus-launch --sh-syntax --exit-with-session` +fi + XCOMM start some nice programs XCLOCK -geometry 50x50-1+1 & Index: app/xdm/config/Xsession.cpp === RCS file: /cvs/OpenBSD/xenocara/app/xdm/config/Xsession.cpp,v retrieving revision 1.9 diff -u -r1.9 Xsession.cpp --- app/xdm/config/Xsession.cpp 3 Dec 2011 13:46:00 - 1.9 +++ app/xdm/config/Xsession.cpp 24 Jun 2012 12:23:20 - @@ -101,6 +101,9 @@ exec `eval $XDESKTOP` } #endif + if [ -x /usr/local/bin/dbus-launch ]; then + eval `dbus-launch --sh-syntax --exit-with-session` + fi BINDIR/xterm & BINDIR/fvwm fi -- Matthieu Herrb
Re: Emacs 24.1
On Sun, Jun 24, 2012 at 02:24:18PM +0200, Matthieu Herrb wrote: > On Sun, Jun 24, 2012 at 10:13:33AM +0200, Antoine Jacoutot wrote: > > So, open a terminal then: > > $ eval `dbus-launch --auto-syntax` > > $ emacs > > ... > > Maybe it's time to add something like that in the default session > scripts (untested): That's exactly what I documented under ports/x11/dbus/pkg/README so I cannot say I am not all for it ;-) That said, I didn't want to be the one pushing it because people would have yelled that I am trying to enforce stuffs on everyone because of gnome (of course nothing to do with gnome but people tend to blame gnome each time they have an issue with a gtk app). So obviously OK for me but I don't think my vote counts. > Index: app/xinit/xinitrc.cpp > === > RCS file: /cvs/OpenBSD/xenocara/app/xinit/xinitrc.cpp,v > retrieving revision 1.6 > diff -u -r1.6 xinitrc.cpp > --- app/xinit/xinitrc.cpp 19 Mar 2011 15:40:02 - 1.6 > +++ app/xinit/xinitrc.cpp 24 Jun 2012 12:23:20 - > @@ -51,6 +51,11 @@ > ssh-add < /dev/null > fi > > +if test -x /usr/local/bin/dbus-launch -a -z "$DBUS_SESSION_BUS_ADDRESS" ; > then > + ## if not found, launch a new one > +eval `dbus-launch --sh-syntax --exit-with-session` > +fi > + > XCOMM start some nice programs > > XCLOCK -geometry 50x50-1+1 & > Index: app/xdm/config/Xsession.cpp > === > RCS file: /cvs/OpenBSD/xenocara/app/xdm/config/Xsession.cpp,v > retrieving revision 1.9 > diff -u -r1.9 Xsession.cpp > --- app/xdm/config/Xsession.cpp 3 Dec 2011 13:46:00 - 1.9 > +++ app/xdm/config/Xsession.cpp 24 Jun 2012 12:23:20 - > @@ -101,6 +101,9 @@ > exec `eval $XDESKTOP` > } > #endif > + if [ -x /usr/local/bin/dbus-launch ]; then > + eval `dbus-launch --sh-syntax --exit-with-session` > + fi > BINDIR/xterm & > BINDIR/fvwm > fi > > -- > Matthieu Herrb -- Antoine
Re: Emacs 24.1
On Sun, Jun 24, 2012 at 02:29:48PM +0200, Antoine Jacoutot wrote: > On Sun, Jun 24, 2012 at 02:24:18PM +0200, Matthieu Herrb wrote: > > On Sun, Jun 24, 2012 at 10:13:33AM +0200, Antoine Jacoutot wrote: > > > So, open a terminal then: > > > $ eval `dbus-launch --auto-syntax` > > > $ emacs > > > ... > > > > Maybe it's time to add something like that in the default session > > scripts (untested): Thanks Matthieu. > > That's exactly what I documented under ports/x11/dbus/pkg/README so "pkg-readmes" is better for this info. Yesterday, after of install gnome, I was seeing the files on "pkg-readmes" for to prevent that I was skipping something. I think that only the developers read "pkg/". > I cannot say I am not all for it ;-) That said, I didn't want to be > the one pushing it because people would have yelled that I am trying > to enforce stuffs on everyone because of gnome (of course nothing to > do with gnome but people tend to blame gnome each time they have an > issue with a gtk app). > > So obviously OK for me but I don't think my vote counts. > -- Juan Francisco Cantero Hurtado http://juanfra.info
Re: Emacs 24.1
On Sun, Jun 24, 2012 at 03:40:42PM +0200, Juan Francisco Cantero Hurtado wrote: > On Sun, Jun 24, 2012 at 02:29:48PM +0200, Antoine Jacoutot wrote: > > On Sun, Jun 24, 2012 at 02:24:18PM +0200, Matthieu Herrb wrote: > > > On Sun, Jun 24, 2012 at 10:13:33AM +0200, Antoine Jacoutot wrote: > > > > So, open a terminal then: > > > > $ eval `dbus-launch --auto-syntax` > > > > $ emacs > > > > ... > > > > > > Maybe it's time to add something like that in the default session > > > scripts (untested): > > Thanks Matthieu. > > > > > That's exactly what I documented under ports/x11/dbus/pkg/README so > > "pkg-readmes" is better for this info. Yesterday, after of install gnome, > I was seeing the files on "pkg-readmes" for to prevent that I was skipping > something. I think that only the developers read "pkg/". You are confused again... ports/x11/dbus/pkg/README gets installed as /usr/local/share/doc/pkg-readmes/dbus-1.4.20v0 -- Antoine
Re: Emacs 24.1
On Sun, Jun 24, 2012 at 03:57:30PM +0200, Antoine Jacoutot wrote: > On Sun, Jun 24, 2012 at 03:40:42PM +0200, Juan Francisco Cantero Hurtado > wrote: > > On Sun, Jun 24, 2012 at 02:29:48PM +0200, Antoine Jacoutot wrote: > > > On Sun, Jun 24, 2012 at 02:24:18PM +0200, Matthieu Herrb wrote: > > > > On Sun, Jun 24, 2012 at 10:13:33AM +0200, Antoine Jacoutot wrote: > > > > > So, open a terminal then: > > > > > $ eval `dbus-launch --auto-syntax` > > > > > $ emacs > > > > > ... > > > > > > > > Maybe it's time to add something like that in the default session > > > > scripts (untested): > > > > Thanks Matthieu. > > > > > > > > That's exactly what I documented under ports/x11/dbus/pkg/README so > > > > "pkg-readmes" is better for this info. Yesterday, after of install gnome, > > I was seeing the files on "pkg-readmes" for to prevent that I was skipping > > something. I think that only the developers read "pkg/". > > You are confused again... > ports/x11/dbus/pkg/README gets installed as > /usr/local/share/doc/pkg-readmes/dbus-1.4.20v0 > OK. I need sleep. -- Juan Francisco Cantero Hurtado http://juanfra.info
Re: Emacs 24.1
On Sun, Jun 24, 2012 at 03:40:42PM +0200, Juan Francisco Cantero Hurtado wrote: > On Sun, Jun 24, 2012 at 02:29:48PM +0200, Antoine Jacoutot wrote: > > On Sun, Jun 24, 2012 at 02:24:18PM +0200, Matthieu Herrb wrote: > > > On Sun, Jun 24, 2012 at 10:13:33AM +0200, Antoine Jacoutot wrote: > > > > So, open a terminal then: > > > > $ eval `dbus-launch --auto-syntax` > > > > $ emacs > > > > ... > > > > > > Maybe it's time to add something like that in the default session > > > scripts (untested): > > Thanks Matthieu. > > > > > That's exactly what I documented under ports/x11/dbus/pkg/README so > > "pkg-readmes" is better for this info. Yesterday, after of install gnome, > I was seeing the files on "pkg-readmes" for to prevent that I was skipping > something. I think that only the developers read "pkg/". And where do you think pkg/README is installed when installing a package ? Landry
remove useless (and harmul) patches from automake 1.11
Hi,
Automake 1.10 used to call various shell scripts (mostly the infamous
install-sh one) without an explicit /bin/sh in front of them, which
caused Xenocara builds to fail, since no shell script in /usr/xenocara
is supposed to have the 'x' bit set (since OpenBSD doesn't want files
with the 'x' bit set in the CVS repository for various reasons).
This has been fixed somewhere in the automake 1.11 release, so now if
I regenerate autotools-produced files in Xenocara with automake 1.11,
I see failures like
/bin/sh /bin/sh /usr/xenocara/lib/fontconfig/install -d /etc/fonts
/var/cache/fontconfig
/bin/sh[1]: syntax error: `(' unexpected
No ${install_sh} is defined as ${SHELL} /path/to/install-sh
So remove the now useless patches. ok ?
Index: Makefile
===
RCS file: /cvs/OpenBSD/ports/devel/automake/1.11/Makefile,v
retrieving revision 1.8
diff -u -p -u -r1.8 Makefile
--- Makefile23 Apr 2012 08:01:14 - 1.8
+++ Makefile24 Jun 2012 14:09:42 -
@@ -5,6 +5,7 @@ COMMENT=GNU standards-compliant Makefil
VERSION= 1.11
DISTNAME= automake-${VERSION}.5
PKGSPEC= automake->=${VERSION},<1.12
+REVISION= 0
CATEGORIES=devel
MASTER_SITES= ${MASTER_SITE_GNU:=automake/}
Index: patches/patch-automake_in
===
RCS file: /cvs/OpenBSD/ports/devel/automake/1.11/patches/patch-automake_in,v
retrieving revision 1.2
diff -u -p -u -r1.2 patch-automake_in
--- patches/patch-automake_in 22 Feb 2012 07:14:20 - 1.2
+++ patches/patch-automake_in 24 Jun 2012 14:08:33 -
@@ -1,15 +1,6 @@
$OpenBSD: patch-automake_in,v 1.2 2012/02/22 07:14:20 ajacoutot Exp $
--- automake.in.orig Wed Feb 1 05:31:13 2012
+++ automake.inThu Feb 16 22:24:10 2012
-@@ -4384,7 +4384,7 @@ sub handle_configure ($$$@)
- # Use $(install_sh), not $(MKDIR_P) because the latter requires
- # at least one argument, and $(mkinstalldirs) used to work
- # even without arguments (e.g. $(mkinstalldirs) $(conditional_dir)).
-- define_variable ('mkinstalldirs', '$(install_sh) -d', INTERNAL);
-+ define_variable ('mkinstalldirs', '$(SHELL) $(install_sh) -d',
INTERNAL);
- }
-
- reject_var ('CONFIG_HEADER',
@@ -5337,6 +5337,7 @@ sub scan_autoconf_traces ($)
_LT_AC_TAGCONFIG => 0,
m4_include => 1,
Index: patches/patch-lib_am_header-vars_am
===
RCS file: patches/patch-lib_am_header-vars_am
diff -N patches/patch-lib_am_header-vars_am
--- patches/patch-lib_am_header-vars_am 8 Apr 2012 07:12:56 - 1.2
+++ /dev/null 1 Jan 1970 00:00:00 -
@@ -1,16 +0,0 @@
-$OpenBSD: patch-lib_am_header-vars_am,v 1.2 2012/04/08 07:12:56 ajacoutot Exp $
lib/am/header-vars.am.orig Mon Apr 2 06:09:39 2012
-+++ lib/am/header-vars.am Sat Apr 7 22:15:00 2012
-@@ -63,9 +63,9 @@ pkglibdir = $(libdir)/@PACKAGE@
- pkglibexecdir = $(libexecdir)/@PACKAGE@
-
- am__cd = CDPATH="$${ZSH_VERSION+.}$(PATH_SEPARATOR)" && cd
--install_sh_DATA = $(install_sh) -c -m 644
--install_sh_PROGRAM = $(install_sh) -c
--install_sh_SCRIPT = $(install_sh) -c
-+install_sh_DATA = ${SHELL} $(install_sh) -c -m 644
-+install_sh_PROGRAM = ${SHELL} $(install_sh) -c
-+install_sh_SCRIPT = ${SHELL} $(install_sh) -c
- INSTALL_HEADER = $(INSTALL_DATA)
- transform = $(program_transform_name)
-
--
Matthieu Herrb
Re: NEW: news/sabnzbd
On Sun, Jun 24, 2012 at 8:30 AM, Marcus Glocker wrote: > retrieve and process nzb-files via web interface. > > OK? > > -- > [ Marcus Glocker, mar...@nazgul.ch, mgloc...@openbsd.org ] Are you sure you want to list py-notify as a dependency? Reason for me asking is that py-notify depends on x11/gtk+2. In my opinion this is a bit much for a headless NZB-download-solution. Is it an idea to make a flavor out of it? Included a port which I made a while ago and has been updated to sabnzbd 0.7.0. Maybe we can combine our efforts? What say thou? -- Björn Ketelaars GPG key: 0xE2B1C430 sabnzbd.tar.gz Description: GNU Zip compressed data
Re: NEW: devel/p5-MooseX-Param
Revised Makefile
Re: NEW: devel/p5-MooseX-FollowPBP
Revised Makefile
# $OpenBSD: Makefile.template,v 1.60 2010/10/24 20:41:23 ajacoutot Exp $
COMMENT=name accessors get_foo(), set_foo()
MODULES=cpan
DISTNAME= MooseX-FollowPBP-0.05
CATEGORIES= devel
# Perl
PERMIT_PACKAGE_CDROM= Yes
PERMIT_PACKAGE_FTP= Yes
PERMIT_DISTFILES_CDROM= Yes
PERMIT_DISTFILES_FTP= Yes
RUN_DEPENDS=devel/p5-Moose
BUILD_DEPENDS= ${RUN_DEPENDS}
.include
Re: NEW: textproc/p5-*LaTeX*
On Sat, Jun 23, 2012 at 03:26:46PM -0500, Chris Bennett wrote: > LaTeX::Driver On Sat, Jun 23, 2012 at 03:28:12PM -0500, Chris Bennett wrote: > LaTeX::Encode On Sat, Jun 23, 2012 at 03:29:18PM -0500, Chris Bennett wrote: > LaTeX::Table On Sat, Jun 23, 2012 at 03:30:40PM -0500, Chris Bennett wrote: > Template::Plugin::Latex I had ports of all of these in the OpenBSD-wip tree, and actually use them all. I rebuilt with these versions and they seem to work well, they were not significantly different from my versions (mostly REGRESS_DEPENDS and the right license comment). They all look good to me and seem to work in my application. l8rZ, -- andrew - http://afresh1.com Hey! It compiles! Ship it!
Re: remove useless (and harmul) patches from automake 1.11
On Sun, Jun 24, 2012 at 05:27:18PM +0200, Matthieu Herrb wrote:
> Hi,
>
> Automake 1.10 used to call various shell scripts (mostly the infamous
> install-sh one) without an explicit /bin/sh in front of them, which
> caused Xenocara builds to fail, since no shell script in /usr/xenocara
> is supposed to have the 'x' bit set (since OpenBSD doesn't want files
> with the 'x' bit set in the CVS repository for various reasons).
>
> This has been fixed somewhere in the automake 1.11 release, so now if
> I regenerate autotools-produced files in Xenocara with automake 1.11,
> I see failures like
>
> /bin/sh /bin/sh /usr/xenocara/lib/fontconfig/install -d /etc/fonts
> /var/cache/fontconfig
> /bin/sh[1]: syntax error: `(' unexpected
>
> No ${install_sh} is defined as ${SHELL} /path/to/install-sh
>
> So remove the now useless patches. ok ?
These patches also need to be removed for automake 1.10 and 1.12.
> Index: Makefile
> ===
> RCS file: /cvs/OpenBSD/ports/devel/automake/1.11/Makefile,v
> retrieving revision 1.8
> diff -u -p -u -r1.8 Makefile
> --- Makefile 23 Apr 2012 08:01:14 - 1.8
> +++ Makefile 24 Jun 2012 14:09:42 -
> @@ -5,6 +5,7 @@ COMMENT= GNU standards-compliant Makefil
> VERSION= 1.11
> DISTNAME=automake-${VERSION}.5
> PKGSPEC= automake->=${VERSION},<1.12
> +REVISION=0
>
> CATEGORIES= devel
> MASTER_SITES=${MASTER_SITE_GNU:=automake/}
> Index: patches/patch-automake_in
> ===
> RCS file: /cvs/OpenBSD/ports/devel/automake/1.11/patches/patch-automake_in,v
> retrieving revision 1.2
> diff -u -p -u -r1.2 patch-automake_in
> --- patches/patch-automake_in 22 Feb 2012 07:14:20 - 1.2
> +++ patches/patch-automake_in 24 Jun 2012 14:08:33 -
> @@ -1,15 +1,6 @@
> $OpenBSD: patch-automake_in,v 1.2 2012/02/22 07:14:20 ajacoutot Exp $
> --- automake.in.orig Wed Feb 1 05:31:13 2012
> +++ automake.in Thu Feb 16 22:24:10 2012
> -@@ -4384,7 +4384,7 @@ sub handle_configure ($$$@)
> - # Use $(install_sh), not $(MKDIR_P) because the latter requires
> - # at least one argument, and $(mkinstalldirs) used to work
> - # even without arguments (e.g. $(mkinstalldirs) $(conditional_dir)).
> -- define_variable ('mkinstalldirs', '$(install_sh) -d', INTERNAL);
> -+ define_variable ('mkinstalldirs', '$(SHELL) $(install_sh) -d',
> INTERNAL);
> - }
> -
> - reject_var ('CONFIG_HEADER',
> @@ -5337,6 +5337,7 @@ sub scan_autoconf_traces ($)
> _LT_AC_TAGCONFIG => 0,
> m4_include => 1,
> Index: patches/patch-lib_am_header-vars_am
> ===
> RCS file: patches/patch-lib_am_header-vars_am
> diff -N patches/patch-lib_am_header-vars_am
> --- patches/patch-lib_am_header-vars_am 8 Apr 2012 07:12:56 -
> 1.2
> +++ /dev/null 1 Jan 1970 00:00:00 -
> @@ -1,16 +0,0 @@
> -$OpenBSD: patch-lib_am_header-vars_am,v 1.2 2012/04/08 07:12:56 ajacoutot
> Exp $
> lib/am/header-vars.am.orig Mon Apr 2 06:09:39 2012
> -+++ lib/am/header-vars.amSat Apr 7 22:15:00 2012
> -@@ -63,9 +63,9 @@ pkglibdir = $(libdir)/@PACKAGE@
> - pkglibexecdir = $(libexecdir)/@PACKAGE@
> -
> - am__cd = CDPATH="$${ZSH_VERSION+.}$(PATH_SEPARATOR)" && cd
> --install_sh_DATA = $(install_sh) -c -m 644
> --install_sh_PROGRAM = $(install_sh) -c
> --install_sh_SCRIPT = $(install_sh) -c
> -+install_sh_DATA = ${SHELL} $(install_sh) -c -m 644
> -+install_sh_PROGRAM = ${SHELL} $(install_sh) -c
> -+install_sh_SCRIPT = ${SHELL} $(install_sh) -c
> - INSTALL_HEADER = $(INSTALL_DATA)
> - transform = $(program_transform_name)
> -
>
>
> --
> Matthieu Herrb
>
>
> --
> This message has been scanned for viruses and
> dangerous content by MailScanner, and is
> believed to be clean.
>
--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
Re: UPDATE math/R 2.8.1 -> 2.15.0
On Thu Jun 21, 2012 at 07:52:02PM +0200, Rafael Sadowski wrote: > On Thu Jun 21, 2012 at 12:09:30PM +0200, Rafael Sadowski wrote: > > Hey @ports, > > > > here is my R[1] update from 2.8.1 to 2.15.0. After long time and many > > fixes and tests R works with x11/kde4/contor[2] and it pass regress > > test. All demo() calls works fine. > > > > Big step between this two versions, see: > > http://cran.r-project.org/src/base/NEWS > > > > comments? OK? commit? > > > > Thanks David Coppa! > > Cheers, Rafael > > > > [1]: https://github.com/jasperla/openbsd-wip/tree/master/math/R > > [2]: https://github.com/jasperla/openbsd-wip/tree/master/x11/kde4/cantor > > > > After tango dance with `cvs rm/mv` here is the final patch. It hope it > works. Thanks Amit ... > > I need one advice. The port built good without modify `ulimit -d` but `make > regress` crashed, if we don't set ulimit -d value upper. So, should I set > VMEM_WARNING=Yes? > No comments? I want to push it to cvs! Cheers, Rafael
Re: remove useless (and harmul) patches from automake 1.11
On Sun, Jun 24, 2012 at 06:06:30PM -0400, Brad Smith wrote:
> On Sun, Jun 24, 2012 at 05:27:18PM +0200, Matthieu Herrb wrote:
> > Hi,
> >
> > Automake 1.10 used to call various shell scripts (mostly the infamous
> > install-sh one) without an explicit /bin/sh in front of them, which
> > caused Xenocara builds to fail, since no shell script in /usr/xenocara
> > is supposed to have the 'x' bit set (since OpenBSD doesn't want files
> > with the 'x' bit set in the CVS repository for various reasons).
> >
> > This has been fixed somewhere in the automake 1.11 release, so now if
> > I regenerate autotools-produced files in Xenocara with automake 1.11,
> > I see failures like
> >
> > /bin/sh /bin/sh /usr/xenocara/lib/fontconfig/install -d /etc/fonts
> > /var/cache/fontconfig
> > /bin/sh[1]: syntax error: `(' unexpected
> >
> > No ${install_sh} is defined as ${SHELL} /path/to/install-sh
> >
> > So remove the now useless patches. ok ?
>
> These patches also need to be removed for automake 1.10 and 1.12.
Here is an updated diff covering all the appropriate versions.
Index: 1.10/Makefile
===
RCS file: /home/cvs/ports/devel/automake/1.10/Makefile,v
retrieving revision 1.12
diff -u -p -r1.12 Makefile
--- 1.10/Makefile 22 Feb 2012 07:43:58 - 1.12
+++ 1.10/Makefile 25 Jun 2012 04:16:14 -
@@ -4,7 +4,7 @@ COMMENT=GNU standards-compliant Makefil
VERSION= 1.10
DISTNAME= automake-${VERSION}.3
-REVISION= 3
+REVISION= 4
PKGSPEC= automake->=${VERSION},<1.11
CATEGORIES=devel
Index: 1.10/patches/patch-automake_in
===
RCS file: /home/cvs/ports/devel/automake/1.10/patches/patch-automake_in,v
retrieving revision 1.1.1.1
diff -u -p -r1.1.1.1 patch-automake_in
--- 1.10/patches/patch-automake_in 22 Jul 2010 19:12:22 - 1.1.1.1
+++ 1.10/patches/patch-automake_in 25 Jun 2012 04:19:31 -
@@ -1,15 +1,6 @@
$OpenBSD: patch-automake_in,v 1.1.1.1 2010/07/22 19:12:22 ajacoutot Exp $
automake.in.orig Tue Dec 8 20:36:30 2009
-+++ automake.inThu Jul 22 06:54:11 2010
-@@ -4055,7 +4055,7 @@ sub handle_configure ($$$@)
- # Use $(install_sh), not $(MKDIR_P) because the latter requires
- # at least one argument, and $(mkinstalldirs) used to work
- # even without arguments (e.g. $(mkinstalldirs) $(conditional_dir)).
-- define_variable ('mkinstalldirs', '$(install_sh) -d', INTERNAL);
-+ define_variable ('mkinstalldirs', '$(SHELL) $(install_sh) -d',
INTERNAL);
- }
-
- reject_var ('CONFIG_HEADER',
+--- automake.in.orig Tue Dec 8 14:36:30 2009
automake.inMon Jun 25 00:19:06 2012
@@ -4815,6 +4815,7 @@ sub scan_autoconf_traces ($)
_LT_AC_TAGCONFIG => 0,
m4_include => 1,
Index: 1.10/patches/patch-lib_am_header-vars_am
===
RCS file: 1.10/patches/patch-lib_am_header-vars_am
diff -N 1.10/patches/patch-lib_am_header-vars_am
--- 1.10/patches/patch-lib_am_header-vars_am18 May 2011 19:38:15 -
1.1
+++ /dev/null 1 Jan 1970 00:00:00 -
@@ -1,16 +0,0 @@
-$OpenBSD: patch-lib_am_header-vars_am,v 1.1 2011/05/18 19:38:15 matthieu Exp $
lib/am/header-vars.am.orig Tue Dec 8 20:35:33 2009
-+++ lib/am/header-vars.am Mon May 16 08:16:06 2011
-@@ -35,9 +35,9 @@ pkglibdir = $(libdir)/@PACKAGE@
- pkgincludedir = $(includedir)/@PACKAGE@
-
- am__cd = CDPATH="$${ZSH_VERSION+.}$(PATH_SEPARATOR)" && cd
--install_sh_DATA = $(install_sh) -c -m 644
--install_sh_PROGRAM = $(install_sh) -c
--install_sh_SCRIPT = $(install_sh) -c
-+install_sh_DATA = ${SHELL} $(install_sh) -c -m 644
-+install_sh_PROGRAM = ${SHELL} $(install_sh) -c
-+install_sh_SCRIPT = ${SHELL} $(install_sh) -c
- INSTALL_HEADER = $(INSTALL_DATA)
- transform = $(program_transform_name)
-
Index: 1.11/Makefile
===
RCS file: /home/cvs/ports/devel/automake/1.11/Makefile,v
retrieving revision 1.8
diff -u -p -r1.8 Makefile
--- 1.11/Makefile 23 Apr 2012 08:01:14 - 1.8
+++ 1.11/Makefile 25 Jun 2012 04:17:21 -
@@ -4,6 +4,7 @@ COMMENT=GNU standards-compliant Makefil
VERSION= 1.11
DISTNAME= automake-${VERSION}.5
+REVISION= 0
PKGSPEC= automake->=${VERSION},<1.12
CATEGORIES=devel
Index: 1.11/patches/patch-automake_in
===
RCS file: /home/cvs/ports/devel/automake/1.11/patches/patch-automake_in,v
retrieving revision 1.2
diff -u -p -r1.2 patch-automake_in
--- 1.11/patches/patch-automake_in 22 Feb 2012 07:14:20 - 1.2
+++ 1.11/patches/patch-automake_in 25 Jun 2012 04:19:58 -
@@ -1,15 +1,6 @@
$OpenBSD: patch-automake_in,v 1.2 2012/02/22 07:14:20 ajacoutot Exp $
automake.in.orig Wed Feb 1 05:31:13 2012
-+
