Re: Emacs 24.2
On Fri, Oct 26, 2012 at 03:59:24PM +0200, Jérémie Courrèges-Anglas wrote: > Whether you use explicitely use dbus or not (as in, linking in > src/dbusbind.c) doesn't matter if you want to use a graphical flavor > (such as gtk3). Even without GSettings or Gconf. For example, with > > ./configure --with-x-toolkit=gtk3 --without-dbus --without-gsettings > --without-gconf > > Emacs will still be linked to libdbus and try to start a dbus > instance. Ok, then forget about my earlier comment on disabling dbus. -- Matthieu Herrb
Re: Emacs 24.2
Matthieu Herrb writes: > On Thu, Oct 25, 2012 at 12:55:26PM +0100, Stuart Henderson wrote: >> On 2012/10/25 11:03, Jérémie Courrèges-Anglas wrote: >> > > Hi porters, >> > > >> > > what about getting this in? >> > >> > ping >> > >> > I can take over maintainership if that's a problem. >> >> Well, the dbus problem mikeb@ ran into needs to be handled in some >> way, it ought to degrade gracefully if a dbus session isn't available, >> hanging at exit in 50% of cases isn't very nice. > > If you have a user dbus daemon running, emacs is happy. > > With the new code that starts dbus in users sessions automatically, > there is no problem. Only users with heavily customized X sessions > will suffer. > > I don't consider this as a show stopper. Indeed, I think the modifications you made (xinitrc/xsession starting dbus if available) should be enough. This could also be documented in a pkg/README file. > OTOH, disabling dbus support in emacs 24 completely is also a > solution. Afaict it's not used for anything critical. Whether you use explicitely use dbus or not (as in, linking in src/dbusbind.c) doesn't matter if you want to use a graphical flavor (such as gtk3). Even without GSettings or Gconf. For example, with ./configure --with-x-toolkit=gtk3 --without-dbus --without-gsettings --without-gconf Emacs will still be linked to libdbus and try to start a dbus instance. (FYI gtk3 should be the default toolkit used by upstream 24.3) >> Also we need to do something about the proliferation of emacs versions >> in the ports tree. It's not *huge* but it's not like it's a small >> fast-building port. There are special reasons for keeping 21 and IIRC >> also 22, does this also apply to 23 or can 24 just go into editors/emacs >> to replace emacs23? (I probably asked this before and it might even >> have been answered but I can't find it in my local list archives at >> the moment ;) >> > > As far as I'm concerned emacs 24 can replace emacs 23. And I'm not > sure what's the reason to keep 22 around. For me it can go too. I do agree with Manuel and you on this: http://marc.info/?l=openbsd-ports&m=133941886303968&w=2 > (there are issues with zenicb and recent emacsen, but we should be > able to fix them. zenicb.el is not that complicated). Good to know. -- Jérémie Courrèges-Anglas GPG fingerprint: 61DB D9A0 00A4 67CF 2A90 8961 6191 8FBF 06A1 1494
Re: Emacs 24.2
On Thu, Oct 25, 2012 at 02:06:04PM +0200, Matthieu Herrb wrote: > On Thu, Oct 25, 2012 at 12:55:26PM +0100, Stuart Henderson wrote: > > On 2012/10/25 11:03, J?r?mie Courr?ges-Anglas wrote: > > > > Hi porters, > > > > > > > > what about getting this in? > > > > > > ping > > > > > > I can take over maintainership if that's a problem. > > > > Well, the dbus problem mikeb@ ran into needs to be handled in some > > way, it ought to degrade gracefully if a dbus session isn't available, > > hanging at exit in 50% of cases isn't very nice. > > If you have a user dbus daemon running, emacs is happy. > > With the new code that starts dbus in users sessions automatically, > there is no problem. Only users with heavily customized X sessions > will suffer. > > I don't consider this as a show stopper. > > OTOH, disabling dbus support in emacs 24 completely is also a > solution. Afaict it's not used for anything critical. I'd opt for this. In my case I am SSH'ing to my OpenBSD boxes with X-forwarding and don't run a complete desktop. Less dependencies are always good. /jl -- ASCII ribbon campaign ( ) Powered by Lemote Fuloong against HTML e-mail X Loongson MIPS and OpenBSD and proprietary/ \http://www.mutt.org attachmentsCode Blue or Go Home!
Re: Emacs 24.2
On Thu, Oct 25, 2012 at 12:55:26PM +0100, Stuart Henderson wrote: > On 2012/10/25 11:03, Jérémie Courrèges-Anglas wrote: > > > Hi porters, > > > > > > what about getting this in? > > > > ping > > > > I can take over maintainership if that's a problem. > > Well, the dbus problem mikeb@ ran into needs to be handled in some > way, it ought to degrade gracefully if a dbus session isn't available, > hanging at exit in 50% of cases isn't very nice. If you have a user dbus daemon running, emacs is happy. With the new code that starts dbus in users sessions automatically, there is no problem. Only users with heavily customized X sessions will suffer. I don't consider this as a show stopper. OTOH, disabling dbus support in emacs 24 completely is also a solution. Afaict it's not used for anything critical. > > Also we need to do something about the proliferation of emacs versions > in the ports tree. It's not *huge* but it's not like it's a small > fast-building port. There are special reasons for keeping 21 and IIRC > also 22, does this also apply to 23 or can 24 just go into editors/emacs > to replace emacs23? (I probably asked this before and it might even > have been answered but I can't find it in my local list archives at > the moment ;) > As far as I'm concerned emacs 24 can replace emacs 23. And I'm not sure what's the reason to keep 22 around. For me it can go too. (there are issues with zenicb and recent emacsen, but we should be able to fix them. zenicb.el is not that complicated). -- Matthieu Herrb
Re: Emacs 24.2
On 2012/10/25 11:03, Jérémie Courrèges-Anglas wrote: > > Hi porters, > > > > what about getting this in? > > ping > > I can take over maintainership if that's a problem. Well, the dbus problem mikeb@ ran into needs to be handled in some way, it ought to degrade gracefully if a dbus session isn't available, hanging at exit in 50% of cases isn't very nice. Also we need to do something about the proliferation of emacs versions in the ports tree. It's not *huge* but it's not like it's a small fast-building port. There are special reasons for keeping 21 and IIRC also 22, does this also apply to 23 or can 24 just go into editors/emacs to replace emacs23? (I probably asked this before and it might even have been answered but I can't find it in my local list archives at the moment ;)
Re: Emacs 24.2
> Hi porters, > > what about getting this in? ping I can take over maintainership if that's a problem. Regards, -- Jérémie Courrèges-Anglas GPG fingerprint: 61DB D9A0 00A4 67CF 2A90 8961 6191 8FBF 06A1 1494 pgpa7vTxRmnta.pgp Description: PGP signature
Re: Emacs 24.2
Hi porters, what about getting this in? -- Jérémie Courrèges-Anglas GPG fingerprint: 61DB D9A0 00A4 67CF 2A90 8961 6191 8FBF 06A1 1494 pgpfKyBEcMdLL.pgp Description: PGP signature
Re: Emacs 24.2
On Mon, Oct 1, 2012 at 4:05 PM, Mike Belopuhov wrote: > On Mon, Oct 1, 2012 at 3:20 PM, Mike Belopuhov wrote: >> On Mon, Oct 1, 2012 at 12:19 PM, Mike Belopuhov wrote: >>> On Tue, Sep 4, 2012 at 2:56 PM, Manuel Giraud wrote: 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 >>> >>> unfortunately I had to roll back to 23. emacs gtk2 flavor hangs >>> on exit in approx. 50% of cases. if you start it from an xterm, >>> the control is returned to the terminal, but the window doesn't >>> get destroyed. >>> >>> it might be a problem with our rthreads or the snapshot I'm >>> running here (sep 11), but unfortunately i don't have time to >>> look closer at this right now. the only thing is that i've been >>> running 24.0 (or 24.1) w/o this problems for months so it >>> might be a regression in 24.2. don't quote me on that though. >>> >>> cheers, >>> mike >> >> adding --without-{dbus,gconf,gsettings} fixes the issue... >> dbus is running and was started via rc.d. > > hmm, adding dbus to my .xsession instead and doing a full > relogin solved the problem... > > if [ -x /usr/local/bin/dbus-launch -a \ > -z "${DBUS_SESSION_BUS_ADDRESS}" ]; then > eval `dbus-launch --sh-syntax --exit-with-session` > fi > > apparently the dbus from /etc/rc.d is for different purposes. thanks to ajacoutot for hints.
Re: Emacs 24.2
On Mon, Oct 1, 2012 at 3:20 PM, Mike Belopuhov wrote: > On Mon, Oct 1, 2012 at 12:19 PM, Mike Belopuhov wrote: >> On Tue, Sep 4, 2012 at 2:56 PM, Manuel Giraud wrote: >>> 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 >>> >> >> unfortunately I had to roll back to 23. emacs gtk2 flavor hangs >> on exit in approx. 50% of cases. if you start it from an xterm, >> the control is returned to the terminal, but the window doesn't >> get destroyed. >> >> it might be a problem with our rthreads or the snapshot I'm >> running here (sep 11), but unfortunately i don't have time to >> look closer at this right now. the only thing is that i've been >> running 24.0 (or 24.1) w/o this problems for months so it >> might be a regression in 24.2. don't quote me on that though. >> >> cheers, >> mike > > adding --without-{dbus,gconf,gsettings} fixes the issue... > dbus is running and was started via rc.d. hmm, adding dbus to my .xsession instead and doing a full relogin solved the problem... if [ -x /usr/local/bin/dbus-launch -a \ -z "${DBUS_SESSION_BUS_ADDRESS}" ]; then eval `dbus-launch --sh-syntax --exit-with-session` fi apparently the dbus from /etc/rc.d is for different purposes.
Re: Emacs 24.2
On Mon, Oct 1, 2012 at 12:19 PM, Mike Belopuhov wrote: > On Tue, Sep 4, 2012 at 2:56 PM, Manuel Giraud wrote: >> 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 >> > > unfortunately I had to roll back to 23. emacs gtk2 flavor hangs > on exit in approx. 50% of cases. if you start it from an xterm, > the control is returned to the terminal, but the window doesn't > get destroyed. > > it might be a problem with our rthreads or the snapshot I'm > running here (sep 11), but unfortunately i don't have time to > look closer at this right now. the only thing is that i've been > running 24.0 (or 24.1) w/o this problems for months so it > might be a regression in 24.2. don't quote me on that though. > > cheers, > mike adding --without-{dbus,gconf,gsettings} fixes the issue... dbus is running and was started via rc.d.
Re: Emacs 24.2
On Mon, Oct 1, 2012 at 12:19 PM, Mike Belopuhov wrote: > On Tue, Sep 4, 2012 at 2:56 PM, Manuel Giraud wrote: >> 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 >> > > unfortunately I had to roll back to 23. emacs gtk2 flavor hangs > on exit in approx. 50% of cases. if you start it from an xterm, > the control is returned to the terminal, but the window doesn't > get destroyed. > > it might be a problem with our rthreads or the snapshot I'm > running here (sep 11), but unfortunately i don't have time to > look closer at this right now. the only thing is that i've been > running 24.0 (or 24.1) w/o this problems for months so it > might be a regression in 24.2. don't quote me on that though. > > cheers, > mike this is a trace from a hanging (spinning in this case) thread: (gdb) where #0 0x00020720528a in sched_yield () at :2 #1 0x000207ac247b in _spinlock (lock=0xe427c0) at /usr/src/lib/librthread/rthread.c:85 #2 0x000207ac48f5 in pthread_mutex_unlock (mutexp=Variable "mutexp" is not available. ) at /usr/src/lib/librthread/rthread_sync.c:225 #3 0x000207ac3e1b in fork () at /usr/src/lib/librthread/rthread_fork.c:151 #4 0x0002085faa9d in g_spawn_error_quark () from /usr/local/lib/libglib-2.0.so.3400.0 #5 0x0002085fb85d in g_spawn_sync () from /usr/local/lib/libglib-2.0.so.3400.0 #6 0x0002085fbd08 in g_spawn_command_line_sync () from /usr/local/lib/libglib-2.0.so.3400.0 #7 0x000211bfcd94 in g_dbus_is_name () from /usr/local/lib/libgio-2.0.so.3400.0 #8 0x000211bfd1aa in g_dbus_address_get_for_bus_sync () from /usr/local/lib/libgio-2.0.so.3400.0 #9 0x000211c06a64 in g_dbus_connection_get_type () from /usr/local/lib/libgio-2.0.so.3400.0 #10 0x000211c06c31 in g_bus_get_sync () from /usr/local/lib/libgio-2.0.so.3400.0 #11 0x0002197f7c9c in g_io_module_load () from /usr/local/lib/gio/modules/libdconfsettings.so #12 0x0002197f7ecd in g_io_module_load () from /usr/local/lib/gio/modules/libdconfsettings.so #13 0x0002085ba10a in g_main_context_dispatch () from /usr/local/lib/libglib-2.0.so.3400.0 #14 0x0002085bbaf5 in g_main_context_acquire () from /usr/local/lib/libglib-2.0.so.3400.0 #15 0x00020857 in g_main_context_iteration () from /usr/local/lib/libglib-2.0.so.3400.0 #16 0x0002197f7c1d in g_io_module_load () from /usr/local/lib/gio/modules/libdconfsettings.so #17 0x0002085de8f5 in g_thread_proxy () from /usr/local/lib/libglib-2.0.so.3400.0 #18 0x000207ac311e in _rthread_start (v=Variable "v" is not available. ) at /usr/src/lib/librthread/rthread.c:122 #19 0x0002071edf9b in __tfork_thread () at /usr/src/lib/libc/arch/amd64/sys/tfork_thread.S:75 Cannot access memory at address 0x20dc7 (gdb) info threads * 1 thread 1031823 0x00020720528a in sched_yield () at :2
Re: Emacs 24.2
On Tue, Sep 4, 2012 at 2:56 PM, Manuel Giraud wrote: > 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 > unfortunately I had to roll back to 23. emacs gtk2 flavor hangs on exit in approx. 50% of cases. if you start it from an xterm, the control is returned to the terminal, but the window doesn't get destroyed. it might be a problem with our rthreads or the snapshot I'm running here (sep 11), but unfortunately i don't have time to look closer at this right now. the only thing is that i've been running 24.0 (or 24.1) w/o this problems for months so it might be a regression in 24.2. don't quote me on that though. cheers, mike
Re: Emacs 24.2
Hi ports@, Stuart Henderson writes: [...] > If emacs runs without imagemagick being installed, then don't list as > a RUN_DEPENDS, people can add it manually if they need it. > > If the functionality is totally disabled if imagemagick is not present > at *build* time then either patch this check away and always build the > IM support, or just make it BUILD_DEPENDS. Thanks for your insight. By default, Emacs itself is linked to Image Magick; so it's clearly not a RUN_DEPENDS / BUILD_DEPENDS. src/image.c conditionally #include's Image Magick headers and uses functions defined there, according to the result of the configure script. I won't be the one to bother looking at how much of Image-Magick-related features would be disabled by --without-image-magick or a patched port. Here's a new version of the (MULTI_PACKAGES-free) port: - fix PLIST as @info markers got stripped in the previous version (*sigh*) - sync WANTLIB: - for all graphical flavors, strip gmodule-2.0 and gthread-2.0 - for gtk3, remove X-related libraries and add missing cairo-gobject - make sure we disable *all* D-Bus support, following the method described in the bzr repository. Regards, -- Jérémie Courrèges-Anglas GPG fingerprint: 61DB D9A0 00A4 67CF 2A90 8961 6191 8FBF 06A1 1494 emacs24.tgz Description: Emacs 24.2 port pgpTpxndJ92xJ.pgp Description: PGP signature
Re: Emacs 24.2
On 2012/09/18 10:31, Manuel Giraud wrote: > 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 > If emacs runs without imagemagick being installed, then don't list as a RUN_DEPENDS, people can add it manually if they need it. If the functionality is totally disabled if imagemagick is not present at *build* time then either patch this check away and always build the IM support, or just make it BUILD_DEPENDS.
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: Emacs 24.2
Mike Belopuhov writes: [...] > Hi, Hi. > 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!"). > Also, I'm not sure sound/liboss should be enabled. Was it tested? As I said, I've tested it lightly. I can't test for every wav file, flavor or sound card out there, sorry: that's the reason why I hope people using Emacs here won't stay silent if things break. If there are bugs, perhaps it would be better to get them fixed. > Cheers, > Mike Regards, [1] http://www.emacswiki.org/emacs/ImageMagick -- Jérémie Courrèges-Anglas GPG fingerprint: 61DB D9A0 00A4 67CF 2A90 8961 6191 8FBF 06A1 1494 pgp9yaOHcgRmz.pgp Description: PGP signature
Re: Emacs 24.2
On Wed, Sep 12, 2012 at 6:51 PM, Jérémie Courrèges-Anglas wrote: > Manuel Giraud writes: >> 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/ > > Thanks a lot, Manuel. > > Here's another version that removes the -main/-el split that some seem > to have requested. > -- > Jérémie Courrèges-Anglas > GPG fingerprint: 61DB D9A0 00A4 67CF 2A90 8961 6191 8FBF 06A1 1494 Hi, 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? Also, I'm not sure sound/liboss should be enabled. Was it tested? Cheers, Mike
Re: Emacs 24.2
Manuel Giraud writes: > 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/ Thanks a lot, Manuel. Here's another version that removes the -main/-el split that some seem to have requested. -- Jérémie Courrèges-Anglas GPG fingerprint: 61DB D9A0 00A4 67CF 2A90 8961 6191 8FBF 06A1 1494 emacs24.tgz Description: Emacs 24.2 port w/o MULTI_PACKAGES pgpndKx71fzN1.pgp Description: PGP signature
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
Here's a new version, with the following changes: * use CONFIGURE_ARGS = --build=${GCCARCH}. Hopefully this will fix the packaging failure seen on amd64 (again, I have no amd64 box to test on). * use -fno-pie / -nopie as almost all arches have switched to PIE (sucks to be on i386...) * disable D-Bus support for the no_x11 flavor, as dbus requires X. Upstream seems to be moving to a gio-based D-Bus support. * sound support forcing -DHAVE_SOUND; .wav playback works fine here, and can be useful for people who want sound notifications. Of course it would be cleaner to use an sndio backend, but ENOTIME. If someone on amd64 could just confirm that --build=${GCCARCH} does the right thing, that would be cool. Forcing --with-system-malloc, one can see that using 29 bits to store addresses (on i386) doesn't work that well... --with-wide-int does not seem to help. I did not address the /var/games/emacs/ problem, since: - no one seems to complain - I can't get ''make update-plist'' to regen the PLIST with the appropriate @mode and @group for update-game-score (which needs to be setgid games). -- Jérémie Courrèges-Anglas GPG fingerprint: 61DB D9A0 00A4 67CF 2A90 8961 6191 8FBF 06A1 1494 emacs24.tgz Description: Emacs 24.2 port
Re: Emacs 24.2
On 2012/09/06 20:51, Jérémie Courrèges-Anglas wrote: > > Rowdy OpenBSD writes: > > > >> As with the emacs23 port, the no_x11 flavour of your port requires > >> dbus, which requires X. To fix this, add "--without-dbus > >> --without-gconf" to CONFIGURE_ARGS for the no_x11 flavour and update > >> WANTLIB and LIB_DEPENDS appropriately. > > > > I didn't know libdbus was bringing in X11, where should I look for this > > kind of information...? Anyway, running emacs-24.2-no_x11 in a console > > works fine, even with no access to /usr/X11R6. > (Works fine also with no dbus session active) > > If you want this port not to depend on dbus just because you want to > build it on a machine with no X libraries, just say so. But please > don't let me find it the hard way. Build, no. It is expected that you have *all* the sets installed if you're building from ports. But a no_x11 flavour shouldn't depend on something that requires X in order to install and run.
Re: Emacs 24.2
> Rowdy OpenBSD writes: > >> As with the emacs23 port, the no_x11 flavour of your port requires >> dbus, which requires X. To fix this, add "--without-dbus >> --without-gconf" to CONFIGURE_ARGS for the no_x11 flavour and update >> WANTLIB and LIB_DEPENDS appropriately. > > I didn't know libdbus was bringing in X11, where should I look for this > kind of information...? Anyway, running emacs-24.2-no_x11 in a console > works fine, even with no access to /usr/X11R6. (Works fine also with no dbus session active) If you want this port not to depend on dbus just because you want to build it on a machine with no X libraries, just say so. But please don't let me find it the hard way. I don't give a damn about dbus and I'm not saying that I am knowledgeable about porters practices, but: - people should install base (including xenocara which uses 200MB) sets - people should use packages, not ports - people might want dbus support in their no_x11-flavored Emacs If some are not OK with that, I think they should have better arguments than "but I need X libraries to build D-Bus to build Emacs". Others can add --without-dbus to their own mystuff/editors/emacs24/Makefile, imho. Of course if there is a proof that emacs-24.2-no_x11 can't run without a live X session, then there is a real problem. But you seem to know better than I do. -- Jérémie Courrèges-Anglas GPG fingerprint: 61DB D9A0 00A4 67CF 2A90 8961 6191 8FBF 06A1 1494 pgpaCWJw7fx1r.pgp Description: PGP signature
Re: Emacs 24.2
Hi. Matthieu Herrb writes: > On Wed, Aug 29, 2012 at 06:58:35PM +0200, Jérémie Courrèges-Anglas wrote: >> Hi. >> >> After the work made by Manuel Giraud (thanks!) on a port for Emacs 24.1, >> here's an update for the 24.2 version (bugfix release). > > Doesn't package on amd64. (error caused by GCCARCH expanding to "amd64" > in PLIST while the port actually installs stuff in > /usr/local/libexec/emacs/24.2/x86_64-unknown-openbsd5.2 Damn... just out of curiosity, are there other architectures where this kind of mismatch happen? > you need to keep CONFIGURE_ARGS = ${GCCARCH} from emacs 23 port to fix > that. I was wondering whether --build=${GCCARCH} would be equivalent (PLIST-wise), but I don't have any amd64 machine to test on right now. > With that + nopie flags, it works so far. (default flavour) Thanks a lot for your feedback. (Keeping my previous questions below) >> Here are the modifications I have made so far: >> - remove "CONFIGURE_ARGS = ${GCCARCH} --localstatedir=/var" >> Using raw "${GCCARCH}" instead of, for example, "--build=${GCCARCH}" >> is deprecated and spits out a warning. But the configure script can >> already find the appropriate value; yet I keep GCCARCH in SUBST_VARS >> since it is used to build the plist. "--localstatedir=/var" is >> already passed by gnu.port.mk >> - remove "AUTOCONF_VERSION = 2.68" >> since we don't have to re-run autoconf. >> - use "MODGNU_CONFIG_GUESS_DIRS = ${WRKSRC}/build-aux" since the >> upstream uses AC_CONFIG_AUX_DIR(build-aux). >> >> I have a couple of questions, though: >> - why remove the dependency on ossaudio using --without-sound? I can't >> see how it is used by Emacs right now, but it doesn't seem harmful / >> expensive since libossaudio is in base. >> - I see that the emacs23 port has been patched to >> use --with-system-malloc and -fnopie. The Emacs 24 configure script >> doesn't have --with-system-malloc anymore. What should we do? I was >> thinking about asking upstream to make this available again, but >> forcing the use of the system malloc resulted in a build failure, in >> my previous tests... >> - make update-plist spits those warnings: >> make-plist: Bogus element outside of every prefix: /var/games/emacs >> make-plist: Bogus element outside of every prefix: >> /var/games/emacs/snake-scores >> make-plist: Bogus element outside of every prefix: >> /var/games/emacs/tetris-scores >> I wonder what to do about those files... touch them in post-install? >> >> 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. >> >> Regards, -- Jérémie Courrèges-Anglas GPG fingerprint: 61DB D9A0 00A4 67CF 2A90 8961 6191 8FBF 06A1 1494 pgpIPfSbAPkU7.pgp Description: PGP signature
Re: Emacs 24.2
Rowdy OpenBSD writes: > As with the emacs23 port, the no_x11 flavour of your port requires > dbus, which requires X. To fix this, add "--without-dbus > --without-gconf" to CONFIGURE_ARGS for the no_x11 flavour and update > WANTLIB and LIB_DEPENDS appropriately. I didn't know libdbus was bringing in X11, where should I look for this kind of information...? Anyway, running emacs-24.2-no_x11 in a console works fine, even with no access to /usr/X11R6. -- Jérémie Courrèges-Anglas GPG fingerprint: 61DB D9A0 00A4 67CF 2A90 8961 6191 8FBF 06A1 1494 pgpSxiPvZcBRT.pgp Description: PGP signature
Re: Emacs 24.2
As with the emacs23 port, the no_x11 flavour of your port requires dbus, which requires X. To fix this, add "--without-dbus --without-gconf" to CONFIGURE_ARGS for the no_x11 flavour and update WANTLIB and LIB_DEPENDS appropriately.
Re: Emacs 24.2
On Wed, Aug 29, 2012 at 06:58:35PM +0200, Jérémie Courrèges-Anglas wrote: > Hi. > > After the work made by Manuel Giraud (thanks!) on a port for Emacs 24.1, > here's an update for the 24.2 version (bugfix release). Doesn't package on amd64. (error caused by GCCARCH expanding to "amd64" in PLIST while the port actually installs stuff in /usr/local/libexec/emacs/24.2/x86_64-unknown-openbsd5.2 you need to keep CONFIGURE_ARGS = ${GCCARCH} from emacs 23 port to fix that. With that + nopie flags, it works so far. (default flavour) > > Here are the modifications I have made so far: > - remove "CONFIGURE_ARGS = ${GCCARCH} --localstatedir=/var" > Using raw "${GCCARCH}" instead of, for example, "--build=${GCCARCH}" > is deprecated and spits out a warning. But the configure script can > already find the appropriate value; yet I keep GCCARCH in SUBST_VARS > since it is used to build the plist. "--localstatedir=/var" is > already passed by gnu.port.mk > - remove "AUTOCONF_VERSION = 2.68" > since we don't have to re-run autoconf. > - use "MODGNU_CONFIG_GUESS_DIRS = ${WRKSRC}/build-aux" since the > upstream uses AC_CONFIG_AUX_DIR(build-aux). > > I have a couple of questions, though: > - why remove the dependency on ossaudio using --without-sound? I can't > see how it is used by Emacs right now, but it doesn't seem harmful / > expensive since libossaudio is in base. > - I see that the emacs23 port has been patched to > use --with-system-malloc and -fnopie. The Emacs 24 configure script > doesn't have --with-system-malloc anymore. What should we do? I was > thinking about asking upstream to make this available again, but > forcing the use of the system malloc resulted in a build failure, in > my previous tests... > - make update-plist spits those warnings: > make-plist: Bogus element outside of every prefix: /var/games/emacs > make-plist: Bogus element outside of every prefix: > /var/games/emacs/snake-scores > make-plist: Bogus element outside of every prefix: > /var/games/emacs/tetris-scores > I wonder what to do about those files... touch them in post-install? > > 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. > > Regards, > -- > Jérémie Courrèges-Anglas > GPG fingerprint: 61DB D9A0 00A4 67CF 2A90 8961 6191 8FBF 06A1 1494 -- Matthieu Herrb
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