* Emacs 23.1.90 pretest
@ 2009-12-09 2:54 Chong Yidong
2009-12-09 4:39 ` Juanma Barranquero
` (6 more replies)
0 siblings, 7 replies; 63+ messages in thread
From: Chong Yidong @ 2009-12-09 2:54 UTC (permalink / raw
To: emacs-devel
Emacs pretest 23.1.90 is now available for download via FTP, at the
following location:
ftp://alpha.gnu.org/gnu/emacs/pretest/emacs-23.1.90.tar.gz
The xdelta against Emacs 23.1 is here:
ftp://alpha.gnu.org/gnu/emacs/pretest/emacs-23.1-23.1.90.xdelta
This is the first pretest for what will be the Emacs 23.2 release.
Pretesters: please send me an email reporting success or failure on your
build platform. Report bugs via M-x report-emacs-bugs, or email
emacs-pretest-bug@gnu.org. For questions, email emacs-devel@gnu.org.
Note that the default for `mail-user-agent' has been changed from Mail
mode to Message mode; if you have Mail mode-specific customizations,
please check them.
There are quite a number of changes relative to Emacs 23.1, including
several new packages, notably the CEDET package of development tools.
See etc/NEWS for details.
Emacs developers: please note that the tree is now frozen. No new
features are allowed, unless agreed to by Stefan or myself. Changes
that are bug fixes or improvements to documentations may still be
committed directly; when in doubt, send email to emacs-devel@gnu.org. I
think we will probably begin Emacs 24 development soon-ish, once we make
the switch from CVS to BZR (we can discuss this further on emacs-devel).
Thanks.
^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: Emacs 23.1.90 pretest
2009-12-09 2:54 Emacs 23.1.90 pretest Chong Yidong
@ 2009-12-09 4:39 ` Juanma Barranquero
2009-12-09 11:33 ` Eli Zaretskii
2009-12-09 9:14 ` Giovanni Lanzani
` (5 subsequent siblings)
6 siblings, 1 reply; 63+ messages in thread
From: Juanma Barranquero @ 2009-12-09 4:39 UTC (permalink / raw
To: Chong Yidong; +Cc: emacs-devel
On Wed, Dec 9, 2009 at 03:54, Chong Yidong <cyd@stupidchicken.com> wrote:
> ftp://alpha.gnu.org/gnu/emacs/pretest/emacs-23.1.90.tar.gz
> Pretesters: please send me an email reporting success or failure on your
> build platform.
I've tried both building and bootstrapping the tar.gz file on
Windows 7 Home Edition (build 7600)
compiling with
gcc.exe (TDM-2 mingw32) 4.4.1-dw2
Building works fine.
Bootstrapping does not compile the *.el files in the subdirs under
lisp/cedet/semantic/; a subsequent "make cvs-update install" fixes it.
Juanma
^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: Emacs 23.1.90 pretest
2009-12-09 2:54 Emacs 23.1.90 pretest Chong Yidong
2009-12-09 4:39 ` Juanma Barranquero
@ 2009-12-09 9:14 ` Giovanni Lanzani
2009-12-09 17:14 ` Jan Djärv
2009-12-09 12:11 ` Andreas Schwab
` (4 subsequent siblings)
6 siblings, 1 reply; 63+ messages in thread
From: Giovanni Lanzani @ 2009-12-09 9:14 UTC (permalink / raw
To: emacs-devel; +Cc: ulissesroc
Chong Yidong <cyd@stupidchicken.com> writes:
> Emacs pretest 23.1.90 is now available for download via FTP, at the
> following location:
>
> ftp://alpha.gnu.org/gnu/emacs/pretest/emacs-23.1.90.tar.gz
>
> The xdelta against Emacs 23.1 is here:
>
> ftp://alpha.gnu.org/gnu/emacs/pretest/emacs-23.1-23.1.90.xdelta
>
> This is the first pretest for what will be the Emacs 23.2 release.
>
> Pretesters: please send me an email reporting success or failure on your
> build platform. Report bugs via M-x report-emacs-bugs, or email
> emacs-pretest-bug@gnu.org. For questions, email emacs-devel@gnu.org.
>
> Note that the default for `mail-user-agent' has been changed from Mail
> mode to Message mode; if you have Mail mode-specific customizations,
> please check them.
>
> There are quite a number of changes relative to Emacs 23.1, including
> several new packages, notably the CEDET package of development tools.
> See etc/NEWS for details.
>
I tried to build the extracted tar.gz, on Snow Leopard, 64bit, with the
following
./configure --with-ns
make install
But it ends with the error
Undefined symbols:
"_xg_select", referenced from:
_wait_reading_process_output in process.o
ld: symbol(s) not found
collect2: ld returned 1 exit status
make[1]: *** [temacs] Error 1
make: *** [src] Error 2
Cheers
Giovanni
^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: Emacs 23.1.90 pretest
2009-12-09 4:39 ` Juanma Barranquero
@ 2009-12-09 11:33 ` Eli Zaretskii
2009-12-09 12:46 ` Juanma Barranquero
0 siblings, 1 reply; 63+ messages in thread
From: Eli Zaretskii @ 2009-12-09 11:33 UTC (permalink / raw
To: Juanma Barranquero; +Cc: cyd, emacs-devel
> From: Juanma Barranquero <lekktu@gmail.com>
> Date: Wed, 9 Dec 2009 05:39:02 +0100
> Cc: emacs-devel@gnu.org
>
> Bootstrapping does not compile the *.el files in the subdirs under
> lisp/cedet/semantic/; a subsequent "make cvs-update install" fixes it.
Doesn't compile because the *.elc files are already there and
"bootstrap-clean" does not remove them, or doesn't compile because it
wasn't told to do so, even if *.elc supplied with the tarball are
removed?
^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: Emacs 23.1.90 pretest
2009-12-09 2:54 Emacs 23.1.90 pretest Chong Yidong
2009-12-09 4:39 ` Juanma Barranquero
2009-12-09 9:14 ` Giovanni Lanzani
@ 2009-12-09 12:11 ` Andreas Schwab
2009-12-09 14:35 ` Chong Yidong
2009-12-09 18:39 ` Steven Knight
` (3 subsequent siblings)
6 siblings, 1 reply; 63+ messages in thread
From: Andreas Schwab @ 2009-12-09 12:11 UTC (permalink / raw
To: Chong Yidong; +Cc: emacs-devel
Please make sure loaddefs.el (and ldefs-boot.el) is up-to-date. The
included loaddefs.el lacks all autoloads from tool-bar.el, for example.
Also, please update your tree before tagging the it, the
EMACS_PRETEST_23_1_90 tag lacks the last change from Stefan before your
checkin.
Andreas.
--
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: Emacs 23.1.90 pretest
2009-12-09 11:33 ` Eli Zaretskii
@ 2009-12-09 12:46 ` Juanma Barranquero
2009-12-09 20:46 ` Chong Yidong
0 siblings, 1 reply; 63+ messages in thread
From: Juanma Barranquero @ 2009-12-09 12:46 UTC (permalink / raw
To: Eli Zaretskii; +Cc: cyd, emacs-devel
On Wed, Dec 9, 2009 at 12:33, Eli Zaretskii <eliz@gnu.org> wrote:
> Doesn't compile because the *.elc files are already there and
> "bootstrap-clean" does not remove them, or doesn't compile because it
> wasn't told to do so, even if *.elc supplied with the tarball are
> removed?
Sorry, I didn't really made myself clear here.
The *.elc for lisp/cedet/semantic/*/*.el files are in the tarball.
The .BAT script that I use to bootstrap Emacs starts by cleaning the
source dir, removing *.elc, *.o, etc. I'm using the realclean target
etc., though after the switch I'll use "bzr clean-tree --unknown
--ignored --detritus"; the intent is having a clean checkout.
After that,
cd nt
configure
make bootstrap
make install
does not compile the semantic/*/*.el files.
Juanma
^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: Emacs 23.1.90 pretest
2009-12-09 12:11 ` Andreas Schwab
@ 2009-12-09 14:35 ` Chong Yidong
2009-12-09 15:48 ` Andreas Schwab
0 siblings, 1 reply; 63+ messages in thread
From: Chong Yidong @ 2009-12-09 14:35 UTC (permalink / raw
To: Andreas Schwab; +Cc: emacs-devel
Andreas Schwab <schwab@linux-m68k.org> writes:
> Please make sure loaddefs.el (and ldefs-boot.el) is up-to-date. The
> included loaddefs.el lacks all autoloads from tool-bar.el, for example.
That's odd. A `make autoloads' does not regenerate the autoloads from
tool-bar.el, either.
> Also, please update your tree before tagging the it, the
> EMACS_PRETEST_23_1_90 tag lacks the last change from Stefan before your
> checkin.
Unfortunately, this kind of thing tends to happen in first pretests when
people try to squeeze stuff in at the last minute as I'm rolling the
tarball.
^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: Emacs 23.1.90 pretest
2009-12-09 14:35 ` Chong Yidong
@ 2009-12-09 15:48 ` Andreas Schwab
2009-12-09 18:52 ` Stefan Monnier
0 siblings, 1 reply; 63+ messages in thread
From: Andreas Schwab @ 2009-12-09 15:48 UTC (permalink / raw
To: Chong Yidong; +Cc: emacs-devel
Chong Yidong <cyd@stupidchicken.com> writes:
> Unfortunately, this kind of thing tends to happen in first pretests when
> people try to squeeze stuff in at the last minute as I'm rolling the
> tarball.
You can avoid that if you use cvs rtag.
Andreas.
--
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: Emacs 23.1.90 pretest
2009-12-09 9:14 ` Giovanni Lanzani
@ 2009-12-09 17:14 ` Jan Djärv
[not found] ` <95bd41770912090936x26bdf529n4f54ce42729c8876@mail.gmail.com>
0 siblings, 1 reply; 63+ messages in thread
From: Jan Djärv @ 2009-12-09 17:14 UTC (permalink / raw
To: Giovanni Lanzani; +Cc: emacs-devel
Can you send us config.log? In the meantime, try adding --without-dbus (just
a guess).
Jan D.
Giovanni Lanzani skrev 2009-12-09 10.14:
> Chong Yidong<cyd@stupidchicken.com> writes:
>
>> Emacs pretest 23.1.90 is now available for download via FTP, at the
>> following location:
>>
>> ftp://alpha.gnu.org/gnu/emacs/pretest/emacs-23.1.90.tar.gz
>>
>> The xdelta against Emacs 23.1 is here:
>>
>> ftp://alpha.gnu.org/gnu/emacs/pretest/emacs-23.1-23.1.90.xdelta
>>
>> This is the first pretest for what will be the Emacs 23.2 release.
>>
>> Pretesters: please send me an email reporting success or failure on your
>> build platform. Report bugs via M-x report-emacs-bugs, or email
>> emacs-pretest-bug@gnu.org. For questions, email emacs-devel@gnu.org.
>>
>> Note that the default for `mail-user-agent' has been changed from Mail
>> mode to Message mode; if you have Mail mode-specific customizations,
>> please check them.
>>
>> There are quite a number of changes relative to Emacs 23.1, including
>> several new packages, notably the CEDET package of development tools.
>> See etc/NEWS for details.
>>
>
> I tried to build the extracted tar.gz, on Snow Leopard, 64bit, with the
> following
>
> ./configure --with-ns
> make install
>
> But it ends with the error
>
> Undefined symbols:
> "_xg_select", referenced from:
> _wait_reading_process_output in process.o
> ld: symbol(s) not found
> collect2: ld returned 1 exit status
> make[1]: *** [temacs] Error 1
> make: *** [src] Error 2
>
>
> Cheers
>
> Giovanni
>
>
^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: Emacs 23.1.90 pretest
[not found] ` <95bd41770912090936x26bdf529n4f54ce42729c8876@mail.gmail.com>
@ 2009-12-09 18:20 ` Jan Djärv
2009-12-09 18:35 ` Giovanni Lanzani
0 siblings, 1 reply; 63+ messages in thread
From: Jan Djärv @ 2009-12-09 18:20 UTC (permalink / raw
To: Giovanni; +Cc: emacs-devel
Giovanni skrev:
> On Wed, Dec 9, 2009 at 6:14 PM, Jan Djärv <jan.h.d@swipnet.se> wrote:
>> Can you send us config.log? In the meantime, try adding --without-dbus
>> (just a guess).
>>
>> Jan D.
>
> --without-dbus doens't help.
>
> See the attached file for config.log
Thanks. --without-rsvg should get you a build until this is fixed. Maybe
throw in a --without-gconf to be on the safe side. It seems you have librsvg
for X11 so configure picks that up.
Jan D.
>
>
> Giovanni
>
>
>> Giovanni Lanzani skrev 2009-12-09 10.14:
>>> Chong Yidong<cyd@stupidchicken.com> writes:
>>>
>>>> Emacs pretest 23.1.90 is now available for download via FTP, at the
>>>> following location:
>>>>
>>>> ftp://alpha.gnu.org/gnu/emacs/pretest/emacs-23.1.90.tar.gz
>>>>
>>>> The xdelta against Emacs 23.1 is here:
>>>>
>>>> ftp://alpha.gnu.org/gnu/emacs/pretest/emacs-23.1-23.1.90.xdelta
>>>>
>>>> This is the first pretest for what will be the Emacs 23.2 release.
>>>>
>>>> Pretesters: please send me an email reporting success or failure on your
>>>> build platform. Report bugs via M-x report-emacs-bugs, or email
>>>> emacs-pretest-bug@gnu.org. For questions, email emacs-devel@gnu.org.
>>>>
>>>> Note that the default for `mail-user-agent' has been changed from Mail
>>>> mode to Message mode; if you have Mail mode-specific customizations,
>>>> please check them.
>>>>
>>>> There are quite a number of changes relative to Emacs 23.1, including
>>>> several new packages, notably the CEDET package of development tools.
>>>> See etc/NEWS for details.
>>>>
>>> I tried to build the extracted tar.gz, on Snow Leopard, 64bit, with the
>>> following
>>>
>>> ./configure --with-ns
>>> make install
>>>
>>> But it ends with the error
>>>
>>> Undefined symbols:
>>> "_xg_select", referenced from:
>>> _wait_reading_process_output in process.o
>>> ld: symbol(s) not found
>>> collect2: ld returned 1 exit status
>>> make[1]: *** [temacs] Error 1
>>> make: *** [src] Error 2
>>>
>>>
>>> Cheers
>>>
>>> Giovanni
>>>
>>>
^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: Emacs 23.1.90 pretest
2009-12-09 18:20 ` Jan Djärv
@ 2009-12-09 18:35 ` Giovanni Lanzani
2009-12-09 18:47 ` Jan Djärv
0 siblings, 1 reply; 63+ messages in thread
From: Giovanni Lanzani @ 2009-12-09 18:35 UTC (permalink / raw
To: emacs-devel; +Cc: ulissesroc
Jan Djärv <jan.h.d@swipnet.se> writes:
> Giovanni skrev:
>> On Wed, Dec 9, 2009 at 6:14 PM, Jan Djärv <jan.h.d@swipnet.se> wrote:
>>> Can you send us config.log? In the meantime, try adding --without-dbus
>>> (just a guess).
>>>
>>> Jan D.
>>
>> --without-dbus doens't help.
>>
>> See the attached file for config.log
>
> Thanks. --without-rsvg should get you a build until this is
> fixed. Maybe throw in a --without-gconf to be on the safe
> side. It seems you have librsvg for X11 so configure picks
> that up.
>
> Jan D.
Thanks Jan, with the option --without-gconf it builds (altough it
doesn't with the option --without-rsvg).
Giovanni
^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: Emacs 23.1.90 pretest
2009-12-09 2:54 Emacs 23.1.90 pretest Chong Yidong
` (2 preceding siblings ...)
2009-12-09 12:11 ` Andreas Schwab
@ 2009-12-09 18:39 ` Steven Knight
2009-12-09 18:56 ` Jan Djärv
2009-12-09 19:01 ` David Robinow
` (2 subsequent siblings)
6 siblings, 1 reply; 63+ messages in thread
From: Steven Knight @ 2009-12-09 18:39 UTC (permalink / raw
To: emacs-devel
On Wed Dec 09 2009 11:31:58 GMT-0500 (EST), Dave Donelan wrote:
> Emacs pretest 23.1.90 is now available for download via FTP, at the
> following location:
>
> ftp://alpha.gnu.org/gnu/emacs/pretest/emacs-23.1.90.tar.gz
>
> The xdelta against Emacs 23.1 is here:
>
> ftp://alpha.gnu.org/gnu/emacs/pretest/emacs-23.1-23.1.90.xdelta
>
> This is the first pretest for what will be the Emacs 23.2 release.
>
> Pretesters: please send me an email reporting success or failure on your
> build platform. Report bugs via M-x report-emacs-bugs, or email
> emacs-pretest-bug@gnu.org. For questions, email emacs-devel@gnu.org.
>
> Note that the default for `mail-user-agent' has been changed from Mail
> mode to Message mode; if you have Mail mode-specific customizations,
> please check them.
>
> There are quite a number of changes relative to Emacs 23.1, including
> several new packages, notably the CEDET package of development tools.
> See etc/NEWS for details.
>
>
> Emacs developers: please note that the tree is now frozen. No new
> features are allowed, unless agreed to by Stefan or myself. Changes
> that are bug fixes or improvements to documentations may still be
> committed directly; when in doubt, send email to emacs-devel@gnu.org. I
> think we will probably begin Emacs 24 development soon-ish, once we make
> the switch from CVS to BZR (we can discuss this further on emacs-devel).
>
> Thanks.
>
>
>
Hi,
I built and installed Emacs on Fedora 11; I did not encounter any errors
when building.
When starting up Emacs, I get the following:
$ emacs -Q
(emacs:31419): Gtk-CRITICAL **: gtk_window_resize: assertion `width > 0'
failed
and the computer emits a beep.
When doing this:
$ emacs -Q -nw
Emacs starts-ups fine.
Please let me know if I should be posting this somewhere else or if you
need more information.
Thanks,
--
Steven Knight
steven.knight@unh.edu
^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: Emacs 23.1.90 pretest
2009-12-09 18:35 ` Giovanni Lanzani
@ 2009-12-09 18:47 ` Jan Djärv
2009-12-10 7:49 ` Yavor Doganov
2009-12-11 17:19 ` Chong Yidong
0 siblings, 2 replies; 63+ messages in thread
From: Jan Djärv @ 2009-12-09 18:47 UTC (permalink / raw
To: Giovanni Lanzani; +Cc: emacs-devel
Giovanni Lanzani skrev:
> Jan Djärv <jan.h.d@swipnet.se> writes:
>
>> Giovanni skrev:
>>> On Wed, Dec 9, 2009 at 6:14 PM, Jan Djärv <jan.h.d@swipnet.se> wrote:
>>>> Can you send us config.log? In the meantime, try adding --without-dbus
>>>> (just a guess).
>>>>
>>>> Jan D.
>>> --without-dbus doens't help.
>>>
>>> See the attached file for config.log
>> Thanks. --without-rsvg should get you a build until this is
>> fixed. Maybe throw in a --without-gconf to be on the safe
>> side. It seems you have librsvg for X11 so configure picks
>> that up.
>>
>> Jan D.
>
> Thanks Jan, with the option --without-gconf it builds (altough it
> doesn't with the option --without-rsvg).
>
This is fixed now.
Thanks for testing.
Jan D.
^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: Emacs 23.1.90 pretest
2009-12-09 15:48 ` Andreas Schwab
@ 2009-12-09 18:52 ` Stefan Monnier
2009-12-09 20:07 ` Andreas Schwab
0 siblings, 1 reply; 63+ messages in thread
From: Stefan Monnier @ 2009-12-09 18:52 UTC (permalink / raw
To: Andreas Schwab; +Cc: Chong Yidong, emacs-devel
>> Unfortunately, this kind of thing tends to happen in first pretests when
>> people try to squeeze stuff in at the last minute as I'm rolling the
>> tarball.
> You can avoid that if you use cvs rtag.
I thought rtag was the problematic one. I always use `tag' instead, so
I know it tags exactly the files I'm seeing at the moment. Then you can
use that tag to export those exact same files to build a tarball, no
matter what else happens on the trunk in the mean time.
Stefan
^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: Emacs 23.1.90 pretest
2009-12-09 18:39 ` Steven Knight
@ 2009-12-09 18:56 ` Jan Djärv
2009-12-09 19:21 ` Steven Knight
0 siblings, 1 reply; 63+ messages in thread
From: Jan Djärv @ 2009-12-09 18:56 UTC (permalink / raw
To: steven.knight; +Cc: emacs-devel
Steven Knight skrev:
> On Wed Dec 09 2009 11:31:58 GMT-0500 (EST), Dave Donelan wrote:
>> Emacs pretest 23.1.90 is now available for download via FTP, at the
>> following location:
>>
>> ftp://alpha.gnu.org/gnu/emacs/pretest/emacs-23.1.90.tar.gz
>>
>> The xdelta against Emacs 23.1 is here:
>>
>> ftp://alpha.gnu.org/gnu/emacs/pretest/emacs-23.1-23.1.90.xdelta
>>
>> This is the first pretest for what will be the Emacs 23.2 release.
>>
>> Pretesters: please send me an email reporting success or failure on your
>> build platform. Report bugs via M-x report-emacs-bugs, or email
>> emacs-pretest-bug@gnu.org. For questions, email emacs-devel@gnu.org.
>>
>> Note that the default for `mail-user-agent' has been changed from Mail
>> mode to Message mode; if you have Mail mode-specific customizations,
>> please check them.
>>
>> There are quite a number of changes relative to Emacs 23.1, including
>> several new packages, notably the CEDET package of development tools.
>> See etc/NEWS for details.
>>
>>
>> Emacs developers: please note that the tree is now frozen. No new
>> features are allowed, unless agreed to by Stefan or myself. Changes
>> that are bug fixes or improvements to documentations may still be
>> committed directly; when in doubt, send email to emacs-devel@gnu.org. I
>> think we will probably begin Emacs 24 development soon-ish, once we make
>> the switch from CVS to BZR (we can discuss this further on emacs-devel).
>>
>> Thanks.
>>
>>
>>
> Hi,
>
> I built and installed Emacs on Fedora 11; I did not encounter any errors
> when building.
>
> When starting up Emacs, I get the following:
>
> $ emacs -Q
>
> (emacs:31419): Gtk-CRITICAL **: gtk_window_resize: assertion `width > 0'
> failed
>
> and the computer emits a beep.
>
> When doing this:
>
> $ emacs -Q -nw
>
> Emacs starts-ups fine.
>
> Please let me know if I should be posting this somewhere else or if you
> need more information.
>
What happens if you do
% emacs -Q -fn fixed
or if that fails
% emacs -Q -fn fixed -g 80x24
Jan D.
^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: Emacs 23.1.90 pretest
2009-12-09 2:54 Emacs 23.1.90 pretest Chong Yidong
` (3 preceding siblings ...)
2009-12-09 18:39 ` Steven Knight
@ 2009-12-09 19:01 ` David Robinow
2009-12-09 20:17 ` Chong Yidong
2009-12-14 4:59 ` Juanma Barranquero
2009-12-18 5:27 ` Drew Adams
6 siblings, 1 reply; 63+ messages in thread
From: David Robinow @ 2009-12-09 19:01 UTC (permalink / raw
To: Chong Yidong; +Cc: emacs-devel
[-- Attachment #1: Type: text/plain, Size: 392 bytes --]
On Tue, Dec 8, 2009 at 9:54 PM, Chong Yidong <cyd@stupidchicken.com> wrote:
> This is the first pretest for what will be the Emacs 23.2 release.
>
> Pretesters: please send me an email reporting success or failure on your
> build platform.
nmake (VS2003) does not like {...} in makefile macros.
A few pairs seem to have crept in.
It builds fine on Windows XP Home with the attached patch.
[-- Attachment #2: makefile.w32.patches --]
[-- Type: application/octet-stream, Size: 1480 bytes --]
*** lib-src/makefile.w32-in.orig 2009-12-08 20:41:30.000000000 -0500
--- lib-src/makefile.w32-in 2009-12-09 09:56:23.375000000 -0500
***************
*** 191,202 ****
OTHER_PLATFORM_SUPPORT = \
$(lispsource)dos-fns.elc \
$(lispsource)dos-vars.elc \
! ${lispsource}term/internal.elc \
! ${lispsource}term/pc-win.elc \
$(lispsource)x-dnd.elc \
$(lispsource)term/x-win.elc \
! ${lispsource}emacs-lisp/easymenu.elc \
! ${lispsource}term/ns-win.elc
lisp1= \
--- 191,202 ----
OTHER_PLATFORM_SUPPORT = \
$(lispsource)dos-fns.elc \
$(lispsource)dos-vars.elc \
! $(lispsource)term/internal.elc \
! $(lispsource)term/pc-win.elc \
$(lispsource)x-dnd.elc \
$(lispsource)term/x-win.elc \
! $(lispsource)emacs-lisp/easymenu.elc \
! $(lispsource)term/ns-win.elc
lisp1= \
*** doc/lispintro/makefile.w32-in.orig 2009-10-28 10:20:50.000000000 -0400
--- doc/lispintro/makefile.w32-in 2009-12-09 09:53:25.453125000 -0500
***************
*** 54,60 ****
emacs-lisp-intro.dvi: $(INFO_SOURCES)
$(ENVADD) $(TEXI2DVI) $(srcdir)/emacs-lisp-intro.texi
! emacs-lisp-intro.pdf: ${INFO_SOURCES}
$(ENVADD) $(TEXI2PDF) $(srcdir)/emacs-lisp-intro.texi
emacs-lisp-intro.html: $(INFO_SOURCES)
--- 54,60 ----
emacs-lisp-intro.dvi: $(INFO_SOURCES)
$(ENVADD) $(TEXI2DVI) $(srcdir)/emacs-lisp-intro.texi
! emacs-lisp-intro.pdf: $(INFO_SOURCES)
$(ENVADD) $(TEXI2PDF) $(srcdir)/emacs-lisp-intro.texi
emacs-lisp-intro.html: $(INFO_SOURCES)
^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: Emacs 23.1.90 pretest
2009-12-09 18:56 ` Jan Djärv
@ 2009-12-09 19:21 ` Steven Knight
2009-12-09 20:44 ` Jan Djärv
0 siblings, 1 reply; 63+ messages in thread
From: Steven Knight @ 2009-12-09 19:21 UTC (permalink / raw
To: emacs-devel
On Wed Dec 09 2009 11:31:58 GMT-0500 (EST), Dave Donelan wrote:
> Steven Knight skrev:
>> On Wed Dec 09 2009 11:31:58 GMT-0500 (EST), Dave Donelan wrote:
>>> Emacs pretest 23.1.90 is now available for download via FTP, at the
>>> following location:
>>>
>>> ftp://alpha.gnu.org/gnu/emacs/pretest/emacs-23.1.90.tar.gz
>>>
>>> The xdelta against Emacs 23.1 is here:
>>>
>>> ftp://alpha.gnu.org/gnu/emacs/pretest/emacs-23.1-23.1.90.xdelta
>>>
>>> This is the first pretest for what will be the Emacs 23.2 release.
>>>
>>> Pretesters: please send me an email reporting success or failure on
>>> your
>>> build platform. Report bugs via M-x report-emacs-bugs, or email
>>> emacs-pretest-bug@gnu.org. For questions, email emacs-devel@gnu.org.
>>>
>>> Note that the default for `mail-user-agent' has been changed from Mail
>>> mode to Message mode; if you have Mail mode-specific customizations,
>>> please check them.
>>>
>>> There are quite a number of changes relative to Emacs 23.1, including
>>> several new packages, notably the CEDET package of development tools.
>>> See etc/NEWS for details.
>>>
>>>
>>> Emacs developers: please note that the tree is now frozen. No new
>>> features are allowed, unless agreed to by Stefan or myself. Changes
>>> that are bug fixes or improvements to documentations may still be
>>> committed directly; when in doubt, send email to
>>> emacs-devel@gnu.org. I
>>> think we will probably begin Emacs 24 development soon-ish, once we
>>> make
>>> the switch from CVS to BZR (we can discuss this further on
>>> emacs-devel).
>>>
>>> Thanks.
>>>
>>>
>> Hi,
>>
>> I built and installed Emacs on Fedora 11; I did not encounter any
>> errors when building.
>>
>> When starting up Emacs, I get the following:
>>
>> $ emacs -Q
>>
>> (emacs:31419): Gtk-CRITICAL **: gtk_window_resize: assertion `width >
>> 0' failed
>>
>> and the computer emits a beep.
>>
>> When doing this:
>>
>> $ emacs -Q -nw
>>
>> Emacs starts-ups fine.
>>
>> Please let me know if I should be posting this somewhere else or if
>> you need more information.
>>
>
> What happens if you do
> % emacs -Q -fn fixed
> or if that fails
> % emacs -Q -fn fixed -g 80x24
>
> Jan D.
>
>
>
Hi,
Using either of the above commands starts emacs without issue. How do I
resolve my issue without using the font fixed? Also I should have
mentioned that using emacs 23.1 I was to build and start emacs without
issue.
Thanks,
--
Steven Knight
steven.knight@unh.edu
^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: Emacs 23.1.90 pretest
2009-12-09 18:52 ` Stefan Monnier
@ 2009-12-09 20:07 ` Andreas Schwab
2009-12-09 21:18 ` Stefan Monnier
0 siblings, 1 reply; 63+ messages in thread
From: Andreas Schwab @ 2009-12-09 20:07 UTC (permalink / raw
To: Stefan Monnier; +Cc: Chong Yidong, emacs-devel
Stefan Monnier <monnier@iro.umontreal.ca> writes:
>>> Unfortunately, this kind of thing tends to happen in first pretests when
>>> people try to squeeze stuff in at the last minute as I'm rolling the
>>> tarball.
>
>> You can avoid that if you use cvs rtag.
>
> I thought rtag was the problematic one. I always use `tag' instead, so
> I know it tags exactly the files I'm seeing at the moment.
The right way is to use rtag, then do a fresh checkout of that tag.
That's the only way to guarantee a consistent tag.
> Then you can use that tag to export those exact same files to build a
> tarball, no matter what else happens on the trunk in the mean time.
As you can see with the EMACS_PRETEST_23_1_90 tag, this can result in
the wrong revisions to be tagged. As a result the git tree is unable to
accurately represent that tag.
Andreas.
--
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: Emacs 23.1.90 pretest
2009-12-09 19:01 ` David Robinow
@ 2009-12-09 20:17 ` Chong Yidong
0 siblings, 0 replies; 63+ messages in thread
From: Chong Yidong @ 2009-12-09 20:17 UTC (permalink / raw
To: David Robinow; +Cc: emacs-devel
David Robinow <drobinow@gmail.com> writes:
> On Tue, Dec 8, 2009 at 9:54 PM, Chong Yidong <cyd@stupidchicken.com> wrote:
>
>> This is the first pretest for what will be the Emacs 23.2 release.
>>
>> Pretesters: please send me an email reporting success or failure on your
>> build platform.
>
> nmake (VS2003) does not like {...} in makefile macros.
> A few pairs seem to have crept in.
>
> It builds fine on Windows XP Home with the attached patch.
Thanks; applied.
^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: Emacs 23.1.90 pretest
2009-12-09 19:21 ` Steven Knight
@ 2009-12-09 20:44 ` Jan Djärv
2009-12-09 21:20 ` Steven Knight
0 siblings, 1 reply; 63+ messages in thread
From: Jan Djärv @ 2009-12-09 20:44 UTC (permalink / raw
To: steven.knight; +Cc: emacs-devel
Steven Knight skrev 2009-12-09 20.21:
>> What happens if you do
>> % emacs -Q -fn fixed
>> or if that fails
>> % emacs -Q -fn fixed -g 80x24
>>
>> Jan D.
>>
>>
>>
> Hi,
>
> Using either of the above commands starts emacs without issue. How do I
> resolve my issue without using the font fixed? Also I should have
> mentioned that using emacs 23.1 I was to build and start emacs without
> issue.
>
First we need to find out what font you are trying to use. Can you start 23.1
that works and in *scratch* evaluate
(frame-parameter nil 'font)
and see what it returns?
Jan D.
^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: Emacs 23.1.90 pretest
2009-12-09 12:46 ` Juanma Barranquero
@ 2009-12-09 20:46 ` Chong Yidong
2009-12-09 20:50 ` Juanma Barranquero
0 siblings, 1 reply; 63+ messages in thread
From: Chong Yidong @ 2009-12-09 20:46 UTC (permalink / raw
To: Juanma Barranquero; +Cc: Eli Zaretskii, emacs-devel
Juanma Barranquero <lekktu@gmail.com> writes:
> Sorry, I didn't really made myself clear here.
>
> The *.elc for lisp/cedet/semantic/*/*.el files are in the tarball.
>
> The .BAT script that I use to bootstrap Emacs starts by cleaning the
> source dir, removing *.elc, *.o, etc. I'm using the realclean target
> etc., though after the switch I'll use "bzr clean-tree --unknown
> --ignored --detritus"; the intent is having a clean checkout.
>
> After that,
>
> cd nt
> configure
> make bootstrap
> make install
>
> does not compile the semantic/*/*.el files.
One possibility is that the Makefile in the tarball doesn't compile the
semantic/*/*.elc files, but the change to Makefile.in, done by Stefan
after the tarball was made, fixes this. Dunno why the problem doesn't
show up on GNU/Linux, though.
^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: Emacs 23.1.90 pretest
2009-12-09 20:46 ` Chong Yidong
@ 2009-12-09 20:50 ` Juanma Barranquero
2009-12-09 21:00 ` Chong Yidong
0 siblings, 1 reply; 63+ messages in thread
From: Juanma Barranquero @ 2009-12-09 20:50 UTC (permalink / raw
To: Chong Yidong; +Cc: Eli Zaretskii, emacs-devel
On Wed, Dec 9, 2009 at 21:46, Chong Yidong <cyd@stupidchicken.com> wrote:
> One possibility is that the Makefile in the tarball doesn't compile the
> semantic/*/*.elc files, but the change to Makefile.in, done by Stefan
> after the tarball was made, fixes this. Dunno why the problem doesn't
> show up on GNU/Linux, though.
I don't think Makefile.in is involved in this; likely a problem with
the Windows-specific makefile.w32-in.
The problem, BTW, has surely been happening for a while on the trunk;
we just didn't notice until now.
Juanma
^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: Emacs 23.1.90 pretest
2009-12-09 20:50 ` Juanma Barranquero
@ 2009-12-09 21:00 ` Chong Yidong
2009-12-09 21:08 ` Glenn Morris
0 siblings, 1 reply; 63+ messages in thread
From: Chong Yidong @ 2009-12-09 21:00 UTC (permalink / raw
To: Juanma Barranquero; +Cc: Eli Zaretskii, emacs-devel
Juanma Barranquero <lekktu@gmail.com> writes:
> On Wed, Dec 9, 2009 at 21:46, Chong Yidong <cyd@stupidchicken.com> wrote:
>
>> One possibility is that the Makefile in the tarball doesn't compile the
>> semantic/*/*.elc files, but the change to Makefile.in, done by Stefan
>> after the tarball was made, fixes this. Dunno why the problem doesn't
>> show up on GNU/Linux, though.
>
> I don't think Makefile.in is involved in this; likely a problem with
> the Windows-specific makefile.w32-in.
>
> The problem, BTW, has surely been happening for a while on the trunk;
> we just didn't notice until now.
Then I am confused as to why "make cvs-update install" would fix the
problem.
^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: Emacs 23.1.90 pretest
2009-12-09 21:00 ` Chong Yidong
@ 2009-12-09 21:08 ` Glenn Morris
2009-12-09 21:45 ` Chong Yidong
0 siblings, 1 reply; 63+ messages in thread
From: Glenn Morris @ 2009-12-09 21:08 UTC (permalink / raw
To: Chong Yidong; +Cc: Juanma Barranquero, Eli Zaretskii, emacs-devel
Chong Yidong wrote:
> Then I am confused as to why "make cvs-update install" would fix the
> problem.
I think WINS_CEDET_SUBDIRS is missing from the list of directories to
compile (WINS_ALMOST) in lisp/makefile.w32-in.
cvs-update runs recompile which uses batch-byte-recompile-directory,
so compiling the files in a different way.
^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: Emacs 23.1.90 pretest
2009-12-09 20:07 ` Andreas Schwab
@ 2009-12-09 21:18 ` Stefan Monnier
2009-12-09 21:45 ` Andreas Schwab
0 siblings, 1 reply; 63+ messages in thread
From: Stefan Monnier @ 2009-12-09 21:18 UTC (permalink / raw
To: Andreas Schwab; +Cc: Chong Yidong, emacs-devel
>>>> Unfortunately, this kind of thing tends to happen in first pretests when
>>>> people try to squeeze stuff in at the last minute as I'm rolling the
>>>> tarball.
>>> You can avoid that if you use cvs rtag.
>> I thought rtag was the problematic one. I always use `tag' instead, so
>> I know it tags exactly the files I'm seeing at the moment.
> The right way is to use rtag, then do a fresh checkout of that tag.
> That's the only way to guarantee a consistent tag.
"consistent" in which sense?
>> Then you can use that tag to export those exact same files to build a
>> tarball, no matter what else happens on the trunk in the mean time.
> As you can see with the EMACS_PRETEST_23_1_90 tag, this can result in
> the wrong revisions to be tagged.
I really can't imagine why "tag" would be a problem. "tag" is suppose
to tag exactly the revisions of the files you have currently checked
out, so if those files are fine, so is your tag.
Luckily, I soon won't have to worry about such CVS idiosyncrasies
any more.
> As a result the git tree is unable to accurately represent that tag.
I can definitely imagine lots of cases where it might be very difficult
to represent tags properly when translating from CVS to something else,
regardless of how the tag was applied.
Stefan
^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: Emacs 23.1.90 pretest
2009-12-09 20:44 ` Jan Djärv
@ 2009-12-09 21:20 ` Steven Knight
2009-12-11 7:47 ` Jan D.
0 siblings, 1 reply; 63+ messages in thread
From: Steven Knight @ 2009-12-09 21:20 UTC (permalink / raw
To: Jan Djärv; +Cc: emacs-devel
On Wed Dec 09 2009 15:44:06 GMT-0500 (EST), Jan Djärv wrote:
> First we need to find out what font you are trying to use. Can you
> start 23.1 that works and in *scratch* evaluate
>
> (frame-parameter nil 'font)
>
> and see what it returns?
>
> Jan D.
>
>
Hi,
You bet. I started emacs (using emacs -Q) and evaluated the above code.
Here is the result:
-unknown-DejaVu Sans Mono-normal-normal-normal-*-16-*-*-*-m-0-iso10646-1
Thanks,
--
Steven Knight
steven.knight@unh.edu
^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: Emacs 23.1.90 pretest
2009-12-09 21:08 ` Glenn Morris
@ 2009-12-09 21:45 ` Chong Yidong
2009-12-10 0:45 ` Juanma Barranquero
0 siblings, 1 reply; 63+ messages in thread
From: Chong Yidong @ 2009-12-09 21:45 UTC (permalink / raw
To: Glenn Morris; +Cc: Juanma Barranquero, Eli Zaretskii, emacs-devel
Glenn Morris <rgm@gnu.org> writes:
> Chong Yidong wrote:
>
>> Then I am confused as to why "make cvs-update install" would fix the
>> problem.
>
> I think WINS_CEDET_SUBDIRS is missing from the list of directories to
> compile (WINS_ALMOST) in lisp/makefile.w32-in.
>
> cvs-update runs recompile which uses batch-byte-recompile-directory,
> so compiling the files in a different way.
You're right, of course. Juanma, could you test this change and see if
it does the right thing?
*** emacs/lisp/makefile.w32-in.~1.101.~ 2009-11-20 09:20:56.000000000 -0500
--- emacs/lisp/makefile.w32-in 2009-12-09 16:44:40.000000000 -0500
***************
*** 89,97 ****
cedet \
cedet/ede \
cedet/semantic \
! cedet/srecode
!
! WINS_CEDET_SUBDIRS=\
cedet/semantic/analyze \
cedet/semantic/bovine \
cedet/semantic/decorate \
--- 89,95 ----
cedet \
cedet/ede \
cedet/semantic \
! cedet/srecode \
cedet/semantic/analyze \
cedet/semantic/bovine \
cedet/semantic/decorate \
***************
*** 118,137 ****
textmodes \
url
! # Directories with lisp files to compile
! WINS_ALMOST=$(WINS_BASIC) \
$(WINS_CEDET)
- # Directories to extract data from (customs, autoloads, etc.)
- WINS_UPDATES=$(WINS_ALMOST) \
- $(WINS_CEDET_SUBDIRS)
-
# Directories to add to subdirs.el
WINS_SUBDIR=$(WINS_BASIC) \
obsolete
! # All directories, except CEDET subdirs
! WINS= $(WINS_ALMOST) \
term \
obsolete
--- 116,132 ----
textmodes \
url
! # Directories with lisp files to compile, and to extract data from
! # (customs, autoloads, etc.)
! WINS_UPDATES=$(WINS_BASIC) \
$(WINS_CEDET)
# Directories to add to subdirs.el
WINS_SUBDIR=$(WINS_BASIC) \
obsolete
! # All directories
! WINS= $(WINS_UPDATES) \
term \
obsolete
^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: Emacs 23.1.90 pretest
2009-12-09 21:18 ` Stefan Monnier
@ 2009-12-09 21:45 ` Andreas Schwab
2009-12-09 21:56 ` Stefan Monnier
0 siblings, 1 reply; 63+ messages in thread
From: Andreas Schwab @ 2009-12-09 21:45 UTC (permalink / raw
To: Stefan Monnier; +Cc: Chong Yidong, emacs-devel
Stefan Monnier <monnier@iro.umontreal.ca> writes:
> "consistent" in which sense?
Consistent in time.
> I really can't imagine why "tag" would be a problem. "tag" is suppose
> to tag exactly the revisions of the files you have currently checked
> out, so if those files are fine, so is your tag.
That's exactly the problem. Your checked out files may be out of date
wrt. the repository.
> I can definitely imagine lots of cases where it might be very difficult
> to represent tags properly when translating from CVS to something else,
> regardless of how the tag was applied.
If you tag consistently there won't be any problem.
Andreas.
--
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: Emacs 23.1.90 pretest
2009-12-09 21:45 ` Andreas Schwab
@ 2009-12-09 21:56 ` Stefan Monnier
2009-12-09 23:14 ` Andreas Schwab
0 siblings, 1 reply; 63+ messages in thread
From: Stefan Monnier @ 2009-12-09 21:56 UTC (permalink / raw
To: Andreas Schwab; +Cc: Chong Yidong, emacs-devel
>> I really can't imagine why "tag" would be a problem. "tag" is suppose
>> to tag exactly the revisions of the files you have currently checked
>> out, so if those files are fine, so is your tag.
> That's exactly the problem. Your checked out files may be out of date
> wrt. the repository.
"Out of date" in which sense? You mean, there might have been some
commits performed since? Of course, that's true, but it doesn't matter
because "tag" will use the revisions in your tree, which should all be
self-consistent. So it will be the same result as if "tag" was
performed (onsistently) when your file have been checked out
(i.e. before the checkins that may have happened in the mean time).
You can checkout, wait for a year, and then perform "tag", and it will
still be consistent.
Stefan
^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: Emacs 23.1.90 pretest
2009-12-09 21:56 ` Stefan Monnier
@ 2009-12-09 23:14 ` Andreas Schwab
2009-12-10 0:39 ` Stefan Monnier
0 siblings, 1 reply; 63+ messages in thread
From: Andreas Schwab @ 2009-12-09 23:14 UTC (permalink / raw
To: Stefan Monnier; +Cc: Chong Yidong, emacs-devel
Stefan Monnier <monnier@iro.umontreal.ca> writes:
>>> I really can't imagine why "tag" would be a problem. "tag" is suppose
>>> to tag exactly the revisions of the files you have currently checked
>>> out, so if those files are fine, so is your tag.
>> That's exactly the problem. Your checked out files may be out of date
>> wrt. the repository.
>
> "Out of date" in which sense? You mean, there might have been some
> commits performed since?
No, there were some commits performed before!
> Of course, that's true, but it doesn't matter because "tag" will use
> the revisions in your tree, which should all be self-consistent.
But it is inconsistent with the One True Repository.
> You can checkout, wait for a year, and then perform "tag", and it will
> still be consistent.
But not consistent with a checkout by date.
Andreas.
--
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: Emacs 23.1.90 pretest
2009-12-09 23:14 ` Andreas Schwab
@ 2009-12-10 0:39 ` Stefan Monnier
2009-12-10 0:45 ` Andreas Schwab
2009-12-10 2:33 ` Stephen J. Turnbull
0 siblings, 2 replies; 63+ messages in thread
From: Stefan Monnier @ 2009-12-10 0:39 UTC (permalink / raw
To: Andreas Schwab; +Cc: Chong Yidong, emacs-devel
>>>> I really can't imagine why "tag" would be a problem. "tag" is suppose
>>>> to tag exactly the revisions of the files you have currently checked
>>>> out, so if those files are fine, so is your tag.
>>> That's exactly the problem. Your checked out files may be out of date
>>> wrt. the repository.
>>
>> "Out of date" in which sense? You mean, there might have been some
>> commits performed since?
> No, there were some commits performed before!
Before what?
Here's how the scenario I have in mind:
cvs update
...blabla build, glance at it, try it out, maybe make a tarball of it...
cvs tag
In what way can this be inconsistent with "the One True Repository"?
In what way is this going to be inconsistent with a checkout by date?
In what way could commits performed "before" affect the consistency?
Is this yet another CVS breakage of which I'm not aware?
Stefan
^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: Emacs 23.1.90 pretest
2009-12-09 21:45 ` Chong Yidong
@ 2009-12-10 0:45 ` Juanma Barranquero
2009-12-11 16:48 ` Chong Yidong
0 siblings, 1 reply; 63+ messages in thread
From: Juanma Barranquero @ 2009-12-10 0:45 UTC (permalink / raw
To: Chong Yidong; +Cc: Eli Zaretskii, emacs-devel
On Wed, Dec 9, 2009 at 22:45, Chong Yidong <cyd@stupidchicken.com> wrote:
> You're right, of course. Juanma, could you test this change and see if
> it does the right thing?
Yes, apparently so, though you'll have to remove also the references
to WINS_CEDET_SUBDIRS in targets bootstrap-clean-CMD and
boostrap-clean-SH.
Juanma
^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: Emacs 23.1.90 pretest
2009-12-10 0:39 ` Stefan Monnier
@ 2009-12-10 0:45 ` Andreas Schwab
2009-12-10 2:33 ` Stephen J. Turnbull
1 sibling, 0 replies; 63+ messages in thread
From: Andreas Schwab @ 2009-12-10 0:45 UTC (permalink / raw
To: Stefan Monnier; +Cc: Chong Yidong, emacs-devel
Stefan Monnier <monnier@iro.umontreal.ca> writes:
> In what way is this going to be inconsistent with a checkout by date?
Compare EMACS_PRETEST_23_1_90 in CVS with EMACS_PRETEST_23_1_90 in git.
> Is this yet another CVS breakage of which I'm not aware?
It is improper use of CVS in a changeset oriented world of VCS.
Andreas.
--
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: Emacs 23.1.90 pretest
2009-12-10 0:39 ` Stefan Monnier
2009-12-10 0:45 ` Andreas Schwab
@ 2009-12-10 2:33 ` Stephen J. Turnbull
2009-12-10 9:41 ` David Kastrup
1 sibling, 1 reply; 63+ messages in thread
From: Stephen J. Turnbull @ 2009-12-10 2:33 UTC (permalink / raw
To: Stefan Monnier; +Cc: Chong Yidong, Andreas Schwab, emacs-devel
Stefan Monnier writes:
> Here's how the scenario I have in mind:
>
> cvs update
> ...blabla build, glance at it, try it out, maybe make a tarball of it...
> cvs tag
>
> In what way can this be inconsistent with "the One True Repository"?
As you know, CVS commits are not atomic. You are both wrong when you
write of "One True Repository." In CVS you simply cannot have a True
Repository in the sense of "true to the Emacs we want to build for
ourselves and distribute to others" without restricting commits to one
developer at a time.
> In what way is this going to be inconsistent with a checkout by date?
I don't know about your release process, but mine involves testing,
then bumping the version number in configure.ac and version.sh.in, and
putting a release herald in the ChangeLogs, then tagging. If this
happens:
cvs update
... I build build, test, bump
... concurrently, Stefan commits
cvs commit <exactly the version bump changes, assume no conflicts>
cvs tag
then the tag spans in time, but does not include, your commit, and in
that sense is inconsistent with checkout by date.
Andreas's procedure using rtag is prohibitively inconvenient, IMO,
because it involves either tagging an untested version or analysis of
changes by others *and* a full test run *after* the tag is created.
If using tag is "inconsistent with a dVCS world", well, what else is
new?
The right way to handle this in CVS IMO is to use "tag", accept the
date/tag inconsistencies for prereleases, and to prohibit commits by
anyone but the release engineer from "cvs update" to "cvs tag" for
public releases. In that case cvs tag is almost equivalent to cvs
rtag (at least in some versions of CVS there were anomolies having to
do with files that don't exist on the branch being tagged).
Again IMO CVS checkouts by date are only useful for bisection, usually
result in identifying a unique commit, and even if the best you can do
is isolate to a period of say 1 hour with a half-dozen commits, that's
not going to be any worse than (say) bisecting and coming up with the
multi-tty merge as the culprit. You take a diff and start bisecting
by hunks rather than by time.
^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: Emacs 23.1.90 pretest
2009-12-09 18:47 ` Jan Djärv
@ 2009-12-10 7:49 ` Yavor Doganov
2009-12-10 19:28 ` Jan Djärv
2009-12-11 17:19 ` Chong Yidong
1 sibling, 1 reply; 63+ messages in thread
From: Yavor Doganov @ 2009-12-10 7:49 UTC (permalink / raw
To: emacs-devel
Jan Djärv wrote:
> > Thanks Jan, with the option --without-gconf it builds (altough it
> > doesn't with the option --without-rsvg).
>
> This is fixed now.
Your change:
-if test "${HAVE_X11}" = "yes" || test "${HAVE_NS}" = "yes"; then
+if test "${HAVE_X11}" = "yes"; then
removes SVG support for the GNUstep port, which was working just fine
for me on GNU/Linux.
^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: Emacs 23.1.90 pretest
2009-12-10 2:33 ` Stephen J. Turnbull
@ 2009-12-10 9:41 ` David Kastrup
2009-12-10 12:32 ` Stephen J. Turnbull
0 siblings, 1 reply; 63+ messages in thread
From: David Kastrup @ 2009-12-10 9:41 UTC (permalink / raw
To: emacs-devel
"Stephen J. Turnbull" <turnbull@sk.tsukuba.ac.jp> writes:
> Stefan Monnier writes:
>
> > Here's how the scenario I have in mind:
> >
> > cvs update
> > ...blabla build, glance at it, try it out, maybe make a tarball of it...
> > cvs tag
> >
> > In what way can this be inconsistent with "the One True Repository"?
>
> As you know, CVS commits are not atomic. You are both wrong when you
> write of "One True Repository." In CVS you simply cannot have a True
> Repository in the sense of "true to the Emacs we want to build for
> ourselves and distribute to others" without restricting commits to one
> developer at a time.
>
> > In what way is this going to be inconsistent with a checkout by
> > date?
>
> I don't know about your release process, but mine involves testing,
> then bumping the version number in configure.ac and version.sh.in, and
> putting a release herald in the ChangeLogs, then tagging. If this
> happens:
>
> cvs update
> ... I build build, test, bump
> ... concurrently, Stefan commits
> cvs commit <exactly the version bump changes, assume no conflicts>
> cvs tag
>
> then the tag spans in time, but does not include, your commit, and in
> that sense is inconsistent with checkout by date.
Which is utterly uninteresting in every respect. The important thing is
that the version is tagged that has been tested and which is intended to
be released. Whether or not that tag can be represented as "state of
repository at a certain point of time" is not only irrelevant, but the
point is _exactly_ that one does not want to have some state of the
repository tagged, but the state that has been tested and approved as
_release_.
> Andreas's procedure using rtag is prohibitively inconvenient, IMO,
> because it involves either tagging an untested version or analysis of
> changes by others *and* a full test run *after* the tag is created.
> If using tag is "inconsistent with a dVCS world", well, what else is
> new?
Of course "inconsistent with a dVCS world" is completely nonsense. The
whole point of dVCS is that you tag what constitutes a version at _your_
local site. This tag does _not_ apply to anything in a central
repository that is not identical to the version at your local site.
> The right way to handle this in CVS IMO is to use "tag", accept the
> date/tag inconsistencies for prereleases, and to prohibit commits by
> anyone but the release engineer from "cvs update" to "cvs tag" for
> public releases.
I don't see why "state of the repository at time point x" is relevant
for anything.
--
David Kastrup
^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: Emacs 23.1.90 pretest
2009-12-10 9:41 ` David Kastrup
@ 2009-12-10 12:32 ` Stephen J. Turnbull
0 siblings, 0 replies; 63+ messages in thread
From: Stephen J. Turnbull @ 2009-12-10 12:32 UTC (permalink / raw
To: David Kastrup; +Cc: emacs-devel
David Kastrup writes:
> I don't see why "state of the repository at time point x" is relevant
> for anything.
*shrug* Stefan asked about "consistency", I explained. The remarks
labelled "IMO" should be construed to mean I agree with you about
relevance.
^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: Emacs 23.1.90 pretest
2009-12-10 7:49 ` Yavor Doganov
@ 2009-12-10 19:28 ` Jan Djärv
2009-12-10 19:50 ` Yavor Doganov
0 siblings, 1 reply; 63+ messages in thread
From: Jan Djärv @ 2009-12-10 19:28 UTC (permalink / raw
To: Yavor Doganov; +Cc: emacs-devel
Yavor Doganov skrev:
> Jan Djärv wrote:
>>> Thanks Jan, with the option --without-gconf it builds (altough it
>>> doesn't with the option --without-rsvg).
>> This is fixed now.
>
> Your change:
>
> -if test "${HAVE_X11}" = "yes" || test "${HAVE_NS}" = "yes"; then
> +if test "${HAVE_X11}" = "yes"; then
>
> removes SVG support for the GNUstep port, which was working just fine
> for me on GNU/Linux.
Testing for NS was totally wrong. I added a test for GNUStep now.
Jan D.
^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: Emacs 23.1.90 pretest
2009-12-10 19:28 ` Jan Djärv
@ 2009-12-10 19:50 ` Yavor Doganov
2009-12-10 21:40 ` Jan Djärv
0 siblings, 1 reply; 63+ messages in thread
From: Yavor Doganov @ 2009-12-10 19:50 UTC (permalink / raw
To: Jan Djärv; +Cc: Yavor Doganov, emacs-devel
Jan Djärv wrote:
> Testing for NS was totally wrong.
I'm puzzled.
Adrian added the SVG support for the NS port (my initial patch was
broken), so presumably he tested it on MacOS. I have no way to know
for certain, but until now I thought that Emacs.app supports SVG on
MacOS via librsvg, the same way it does on GNUstep platforms.
Perhaps the OP's librsvg installation was broken/incomplete or
something else... Anyway, personally I only care that it keeps
working on GNUstep.
^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: Emacs 23.1.90 pretest
2009-12-10 19:50 ` Yavor Doganov
@ 2009-12-10 21:40 ` Jan Djärv
2009-12-10 23:02 ` Yavor Doganov
0 siblings, 1 reply; 63+ messages in thread
From: Jan Djärv @ 2009-12-10 21:40 UTC (permalink / raw
To: Yavor Doganov; +Cc: Yavor Doganov, emacs-devel@gnu.org
10 dec 2009 kl. 20.50 skrev Yavor Doganov <yavor@gnu.org>:
> Jan Djärv wrote:
>> Testing for NS was totally wrong.
>
> I'm puzzled.
>
> Adrian added the SVG support for the NS port (my initial patch was
> broken), so presumably he tested it on MacOS. I have no way to know
> for certain, but until now I thought that Emacs.app supports SVG on
> MacOS via librsvg, the same way it does on GNUstep platforms.
>
> Perhaps the OP's librsvg installation was broken/incomplete or
> something else... Anyway, personally I only care that it keeps
> working on GNUstep.
>
Librsvg can not work on OSX except with X11. Librsvg is totally
dependent on X11.
Jan D.
^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: Emacs 23.1.90 pretest
2009-12-10 21:40 ` Jan Djärv
@ 2009-12-10 23:02 ` Yavor Doganov
2009-12-11 17:15 ` Chong Yidong
0 siblings, 1 reply; 63+ messages in thread
From: Yavor Doganov @ 2009-12-10 23:02 UTC (permalink / raw
To: Jan Djärv; +Cc: Yavor Doganov, emacs-devel@gnu.org
Jan Djärv wrote:
> Librsvg can not work on OSX except with X11. Librsvg is totally
> dependent on X11.
Ah. Forgive my ignorance, but my impression was that X11 is usually
installed on that platform and in any case, no harm could be done if
librsvg is not found.
I configure Emacs.app --with-ns --without-x; here are all the
libraries linked:
-lgnustep-gui -lgnustep-base -lobjc -lpthread -lasound -lrsvg-2
-lgdk_pixbuf-2.0 -lm -lcairo -lgobject-2.0 -lgmodule-2.0 -ldl
-lglib-2.0 -ldbus-1 -lgpm -lncurses -lm
As you observe, the GLib/GDK stuff comes from `pkg-config --libs
librsvg-2.0', a fair price to pay given the fact that librsvg is
already present on a typical GNUstep workstation as a dependency of
the LaTeX service, a popular package. Of course, the Emacs executable
indirectly links with X libs in my case, which sort of explains my
initial bewilderment.
^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: Emacs 23.1.90 pretest
2009-12-09 21:20 ` Steven Knight
@ 2009-12-11 7:47 ` Jan D.
2009-12-11 14:50 ` Steven Knight
0 siblings, 1 reply; 63+ messages in thread
From: Jan D. @ 2009-12-11 7:47 UTC (permalink / raw
To: steven.knight; +Cc: emacs-devel
On 2009-12-09 22:20, Steven Knight wrote:
> On Wed Dec 09 2009 15:44:06 GMT-0500 (EST), Jan Djärv wrote:
>> First we need to find out what font you are trying to use. Can you
>> start 23.1 that works and in *scratch* evaluate
>>
>> (frame-parameter nil 'font)
>>
>> and see what it returns?
>>
>> Jan D.
>>
>>
>
> Hi,
>
> You bet. I started emacs (using emacs -Q) and evaluated the above code.
> Here is the result:
>
> -unknown-DejaVu Sans Mono-normal-normal-normal-*-16-*-*-*-m-0-iso10646-1
>
Hmm. I think you must debug this, I'm trying to figure out where.
Does starting with -fn Monospace-12 work?
Can you start gdb on emacs and set a breakpoint in
x_default_font_parameter? A session would look something like:
(gdb) b x_default_font_parameter
(gdb) r -Q
break in x_default_font_parameter
And then type n to step through and print out variables as they are
assigned:
(gdb) p font
(gdb) pr
and
(gdb) p system_font
I hope we find something here.
Jan D.
^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: Emacs 23.1.90 pretest
2009-12-11 7:47 ` Jan D.
@ 2009-12-11 14:50 ` Steven Knight
2009-12-11 15:03 ` Jan D.
2009-12-12 16:20 ` Jan Djärv
0 siblings, 2 replies; 63+ messages in thread
From: Steven Knight @ 2009-12-11 14:50 UTC (permalink / raw
To: Jan D.; +Cc: emacs-devel
[-- Attachment #1: Type: text/plain, Size: 1359 bytes --]
On Fri Dec 11 2009 02:47:26 GMT-0500 (EST), Jan D. wrote:
> On 2009-12-09 22:20, Steven Knight wrote:
>> On Wed Dec 09 2009 15:44:06 GMT-0500 (EST), Jan Djärv wrote:
>>> First we need to find out what font you are trying to use. Can you
>>> start 23.1 that works and in *scratch* evaluate
>>>
>>> (frame-parameter nil 'font)
>>>
>>> and see what it returns?
>>>
>>> Jan D.
>>>
>>>
>>
>> Hi,
>>
>> You bet. I started emacs (using emacs -Q) and evaluated the above code.
>> Here is the result:
>>
>> -unknown-DejaVu Sans Mono-normal-normal-normal-*-16-*-*-*-m-0-iso10646-1
>>
>
> Hmm. I think you must debug this, I'm trying to figure out where.
> Does starting with -fn Monospace-12 work?
$ emacs -Q -fn Monospace-12
Arithmetic error
>
> Can you start gdb on emacs and set a breakpoint in
> x_default_font_parameter? A session would look something like:
> (gdb) b x_default_font_parameter
> (gdb) r -Q
> break in x_default_font_parameter
>
> And then type n to step through and print out variables as they are
> assigned:
> (gdb) p font
> (gdb) pr
>
> and
> (gdb) p system_font
>
I will do this and let you know.
I've attached a copy of my config.log file (bzipped). I am running
emacs-23.1.90 on a Fedora 11 system under KDE 4.3.3.
Thanks for all the help,
--
Steven Knight
steven.knight@unh.edu
[-- Attachment #2: config.log.bz2 --]
[-- Type: application/octet-stream, Size: 17158 bytes --]
^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: Emacs 23.1.90 pretest
2009-12-11 14:50 ` Steven Knight
@ 2009-12-11 15:03 ` Jan D.
2009-12-12 16:20 ` Jan Djärv
1 sibling, 0 replies; 63+ messages in thread
From: Jan D. @ 2009-12-11 15:03 UTC (permalink / raw
To: steven.knight; +Cc: emacs-devel
On 2009-12-11 15:50, Steven Knight wrote:
> On Fri Dec 11 2009 02:47:26 GMT-0500 (EST), Jan D. wrote:
>> On 2009-12-09 22:20, Steven Knight wrote:
>>> On Wed Dec 09 2009 15:44:06 GMT-0500 (EST), Jan Djärv wrote:
>>>> First we need to find out what font you are trying to use. Can you
>>>> start 23.1 that works and in *scratch* evaluate
>>>>
>>>> (frame-parameter nil 'font)
>>>>
>>>> and see what it returns?
>>>>
>>>> Jan D.
>>>>
>>>>
>>>
>>> Hi,
>>>
>>> You bet. I started emacs (using emacs -Q) and evaluated the above code.
>>> Here is the result:
>>>
>>> -unknown-DejaVu Sans Mono-normal-normal-normal-*-16-*-*-*-m-0-iso10646-1
>>>
>>
>> Hmm. I think you must debug this, I'm trying to figure out where.
>> Does starting with -fn Monospace-12 work?
> $ emacs -Q -fn Monospace-12
> Arithmetic error
Wow, that was unexpected. I think I have to install Fedora 11 and KDE.
Jan D.
^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: Emacs 23.1.90 pretest
2009-12-10 0:45 ` Juanma Barranquero
@ 2009-12-11 16:48 ` Chong Yidong
2009-12-11 16:58 ` Juanma Barranquero
0 siblings, 1 reply; 63+ messages in thread
From: Chong Yidong @ 2009-12-11 16:48 UTC (permalink / raw
To: Juanma Barranquero; +Cc: Eli Zaretskii, emacs-devel
Juanma Barranquero <lekktu@gmail.com> writes:
> On Wed, Dec 9, 2009 at 22:45, Chong Yidong <cyd@stupidchicken.com> wrote:
>
>> You're right, of course. Juanma, could you test this change and see
>> if it does the right thing?
>
> Yes, apparently so, though you'll have to remove also the references
> to WINS_CEDET_SUBDIRS in targets bootstrap-clean-CMD and
> boostrap-clean-SH.
OK, I've checked the corrected fix into CVS. Could you check if it
works?
^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: Emacs 23.1.90 pretest
2009-12-11 16:48 ` Chong Yidong
@ 2009-12-11 16:58 ` Juanma Barranquero
0 siblings, 0 replies; 63+ messages in thread
From: Juanma Barranquero @ 2009-12-11 16:58 UTC (permalink / raw
To: Chong Yidong; +Cc: Eli Zaretskii, emacs-devel
On Fri, Dec 11, 2009 at 17:48, Chong Yidong <cyd@stupidchicken.com> wrote:
> OK, I've checked the corrected fix into CVS. Could you check if it
> works?
The change you've committed is the one I already tested (including the
missing fixes in the bootstrap-clean-* targets). Also, I bootstrap
quite often, so any trouble should be evident before the next pretest
release.
Juanma
^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: Emacs 23.1.90 pretest
2009-12-10 23:02 ` Yavor Doganov
@ 2009-12-11 17:15 ` Chong Yidong
2009-12-11 20:07 ` Jan Djärv
2009-12-12 0:00 ` David Reitter
0 siblings, 2 replies; 63+ messages in thread
From: Chong Yidong @ 2009-12-11 17:15 UTC (permalink / raw
To: Adrian Robert; +Cc: Yavor Doganov, Jan Djärv, emacs-devel@gnu.org
Yavor Doganov <yavor@gnu.org> writes:
> Jan Djärv wrote:
>> Librsvg can not work on OSX except with X11. Librsvg is totally
>> dependent on X11.
>
> Ah. Forgive my ignorance, but my impression was that X11 is usually
> installed on that platform and in any case, no harm could be done if
> librsvg is not found.
Adrian (or any OS X user), could you comment?
^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: Emacs 23.1.90 pretest
2009-12-09 18:47 ` Jan Djärv
2009-12-10 7:49 ` Yavor Doganov
@ 2009-12-11 17:19 ` Chong Yidong
2009-12-11 20:05 ` Jan Djärv
1 sibling, 1 reply; 63+ messages in thread
From: Chong Yidong @ 2009-12-11 17:19 UTC (permalink / raw
To: Jan Djärv; +Cc: Giovanni Lanzani, emacs-devel
Jan Djärv <jan.h.d@swipnet.se> writes:
>> Thanks Jan, with the option --without-gconf it builds (altough it
>> doesn't with the option --without-rsvg).
>>
> This is fixed now.
>
> Thanks for testing.
Why did the bug arise in the first place? In the configure test,
PKG_CHECK_MODULES(GCONF, gconf-2.0 >= 2.13, HAVE_GCONF=yes, HAVE_GCONF=no)
should have returned HAVE_GCONF=no on OS X (I assume the Gconf libraries
wouldn't be present). So HAVE_GCONF should not have been defined.
^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: Emacs 23.1.90 pretest
2009-12-11 17:19 ` Chong Yidong
@ 2009-12-11 20:05 ` Jan Djärv
2009-12-12 8:10 ` Jan Djärv
0 siblings, 1 reply; 63+ messages in thread
From: Jan Djärv @ 2009-12-11 20:05 UTC (permalink / raw
To: Chong Yidong; +Cc: Giovanni Lanzani, emacs-devel@gnu.org
11 dec 2009 kl. 18.19 skrev Chong Yidong <cyd@stupidchicken.com>:
> Jan Djärv <jan.h.d@swipnet.se> writes:
>
>>> Thanks Jan, with the option --without-gconf it builds (altough it
>>> doesn't with the option --without-rsvg).
>>>
>> This is fixed now.
>>
>> Thanks for testing.
>
> Why did the bug arise in the first place? In the configure test,
>
> PKG_CHECK_MODULES(GCONF, gconf-2.0 >= 2.13, HAVE_GCONF=yes,
> HAVE_GCONF=no)
>
> should have returned HAVE_GCONF=no on OS X (I assume the Gconf
> libraries
> wouldn't be present). So HAVE_GCONF should not have been defined.
Gconf libraries and the rest of Gnome are present if you install Fink
on OSX as the reporters seem to have done.
Jan D.
^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: Emacs 23.1.90 pretest
2009-12-11 17:15 ` Chong Yidong
@ 2009-12-11 20:07 ` Jan Djärv
2009-12-11 21:36 ` Yavor Doganov
2009-12-12 0:00 ` David Reitter
1 sibling, 1 reply; 63+ messages in thread
From: Jan Djärv @ 2009-12-11 20:07 UTC (permalink / raw
To: Chong Yidong; +Cc: Yavor Doganov, Adrian Robert, emacs-devel@gnu.org
11 dec 2009 kl. 18.15 skrev Chong Yidong <cyd@stupidchicken.com>:
> Yavor Doganov <yavor@gnu.org> writes:
>
>> Jan Djärv wrote:
>>> Librsvg can not work on OSX except with X11. Librsvg is totally
>>> dependent on X11.
>>
>> Ah. Forgive my ignorance, but my impression was that X11 is usually
>> installed on that platform and in any case, no harm could be done if
>> librsvg is not found.
>
> Adrian (or any OS X user), could you comment?
I am an OSX user...
Jan D.
^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: Emacs 23.1.90 pretest
2009-12-11 20:07 ` Jan Djärv
@ 2009-12-11 21:36 ` Yavor Doganov
2009-12-11 21:56 ` chad
2009-12-11 22:04 ` Jan Djärv
0 siblings, 2 replies; 63+ messages in thread
From: Yavor Doganov @ 2009-12-11 21:36 UTC (permalink / raw
To: Jan Djärv
Cc: Chong Yidong, Adrian Robert, Yavor Doganov, emacs-devel@gnu.org
Jan Djärv wrote:
> >>> Librsvg can not work on OSX except with X11. Librsvg is totally
> >>> dependent on X11.
> >>
> >> Ah. Forgive my ignorance, but my impression was that X11 is usually
> >> installed on that platform and in any case, no harm could be done if
> >> librsvg is not found.
> >
> > Adrian (or any OS X user), could you comment?
>
> I am an OSX user...
Your last change seems good enough for me (it reinstates SVG support
on GNUstep), but AFAICS there's still something fishy here.
If the initial test for
HAVE_X11 || HAVE_NS
caused configure to find librsvg for the OP, and librsvg depends on
X11, and he had a build failure during compilation because of
unresolved X symbols (IIRC), isn't this an indication that his
installation is somewhat broken? (I still can't explain myself why
the test was wrong in the first place as you say.)
^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: Emacs 23.1.90 pretest
2009-12-11 21:36 ` Yavor Doganov
@ 2009-12-11 21:56 ` chad
2009-12-11 22:04 ` Jan Djärv
1 sibling, 0 replies; 63+ messages in thread
From: chad @ 2009-12-11 21:56 UTC (permalink / raw
To: Yavor Doganov; +Cc: emacs-devel
[-- Attachment #1: Type: text/plain, Size: 1383 bytes --]
On Dec 11, 2009, at 1:36 PM, Yavor Doganov wrote:
> Jan Djärv wrote:
>>
>> Librsvg can not work on OSX except with X11. Librsvg is totally
>> dependent on X11.
> [...]
> Your last change seems good enough for me (it reinstates SVG support
> on GNUstep), but AFAICS there's still something fishy here.
>
> If the initial test for
>
> HAVE_X11 || HAVE_NS
>
> caused configure to find librsvg for the OP, and librsvg depends on
> X11, and he had a build failure during compilation because of
> unresolved X symbols (IIRC), isn't this an indication that his
> installation is somewhat broken? (I still can't explain myself why
> the test was wrong in the first place as you say.)
OS X comes with a full X11 setup that it can run as a sort of `hosted' window system, distinct from the native system used by --with-ns. I would expect it to be fairly common to see developers on macosx with X11, Gnome, GTK, and perhaps even librsvg installed. Neither emacs not any other application of which I am aware *under macosx* can deal with both X11 and Carbon/Cocoa/Quartz at the same time, so simply finding the libraries installed is not sufficient to tell you (or configure) if the library should be used. It is possible that GNUStep systems can use both, since they implement one in terms of the other -- I'm unfamiliar with GNUStep these days.
*Chad
[-- Attachment #2: Type: text/html, Size: 2205 bytes --]
^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: Emacs 23.1.90 pretest
2009-12-11 21:36 ` Yavor Doganov
2009-12-11 21:56 ` chad
@ 2009-12-11 22:04 ` Jan Djärv
2009-12-11 23:27 ` Yavor Doganov
1 sibling, 1 reply; 63+ messages in thread
From: Jan Djärv @ 2009-12-11 22:04 UTC (permalink / raw
To: Chong Yidong, Adrian Robert, emacs-devel@gnu.org, Yavor Doganov
Yavor Doganov skrev 2009-12-11 22.36:
> Jan Djärv wrote:
>>>>> Librsvg can not work on OSX except with X11. Librsvg is totally
>>>>> dependent on X11.
>>>>
>>>> Ah. Forgive my ignorance, but my impression was that X11 is usually
>>>> installed on that platform and in any case, no harm could be done if
>>>> librsvg is not found.
>>>
>>> Adrian (or any OS X user), could you comment?
>>
>> I am an OSX user...
>
> Your last change seems good enough for me (it reinstates SVG support
> on GNUstep), but AFAICS there's still something fishy here.
>
> If the initial test for
>
> HAVE_X11 || HAVE_NS
>
> caused configure to find librsvg for the OP, and librsvg depends on
> X11, and he had a build failure during compilation because of
> unresolved X symbols (IIRC), isn't this an indication that his
> installation is somewhat broken? (I still can't explain myself why
> the test was wrong in the first place as you say.)
>
GNUStep runs on top of X11. OSX normal GUI is a totally different beast
(Cocoa on display PDF). Both use the NS API. Emacs can not mix two different
GUIs. Just because the libs are there doesn't mean it doesn't hurt to link in
them. The event handling, window handling, and all other stuff are compleatly
different. You don't expect X11 libs to work on W32 by just linking them in
to the executble do you?
The libs are there, but shall not be linked in unless GNUStep, and thereby
X11, is used.
Jan D.
^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: Emacs 23.1.90 pretest
2009-12-11 22:04 ` Jan Djärv
@ 2009-12-11 23:27 ` Yavor Doganov
0 siblings, 0 replies; 63+ messages in thread
From: Yavor Doganov @ 2009-12-11 23:27 UTC (permalink / raw
To: Jan Djärv
Cc: Chong Yidong, Adrian Robert, Yavor Doganov, emacs-devel@gnu.org
Jan Djärv wrote:
> The libs are there, but shall not be linked in unless GNUStep, and
> thereby X11, is used.
Thanks for the explanation. This means that SVG support is not
available for MacOS users, unless they configure for a GTK+/Lucid
build, which is of course a different thing.
It's a relief to find at least one advantage of the GNUstep port on
top of the many regressions.
^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: Emacs 23.1.90 pretest
2009-12-11 17:15 ` Chong Yidong
2009-12-11 20:07 ` Jan Djärv
@ 2009-12-12 0:00 ` David Reitter
2009-12-12 2:32 ` Chming
1 sibling, 1 reply; 63+ messages in thread
From: David Reitter @ 2009-12-12 0:00 UTC (permalink / raw
To: Chong Yidong
Cc: Yavor Doganov, Adrian Robert, Jan Djärv, emacs-devel@gnu.org
[-- Attachment #1: Type: text/plain, Size: 442 bytes --]
On Dec 11, 2009, at 12:15 PM, Chong Yidong wrote:
>>> Librsvg can not work on OSX except with X11. Librsvg is totally
>>> dependent on X11.
>>
>> Ah. Forgive my ignorance, but my impression was that X11 is usually
>> installed on that platform and in any case, no harm could be done if
>> librsvg is not found.
>
> Adrian (or any OS X user), could you comment?
No, X11 is not installed on OS X by default. It is a separate install.
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 203 bytes --]
^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: Emacs 23.1.90 pretest
2009-12-12 0:00 ` David Reitter
@ 2009-12-12 2:32 ` Chming
0 siblings, 0 replies; 63+ messages in thread
From: Chming @ 2009-12-12 2:32 UTC (permalink / raw
Cc: Chong Yidong, Adrian Robert, Yavor Doganov, Jan Djärv,
emacs-devel@gnu.org
1) the indent function seems broken.
like this:
#ifdef MACRO
void foo(int i,
int j,
int k);
#endif
i, j and k will not aligned correctly.
2) C-M-a does not work correctly sometimes. It will jump to the last {
or somewhere else instead of the beginning of func, esp. if there are
some #ifdef macros around.
Thanks,
Ming
^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: Emacs 23.1.90 pretest
2009-12-11 20:05 ` Jan Djärv
@ 2009-12-12 8:10 ` Jan Djärv
0 siblings, 0 replies; 63+ messages in thread
From: Jan Djärv @ 2009-12-12 8:10 UTC (permalink / raw
To: Chong Yidong; +Cc: Giovanni Lanzani, emacs-devel@gnu.org
Jan Djärv skrev 2009-12-11 21.05:
>
>
> Gconf libraries and the rest of Gnome are present if you install Fink on
> OSX as the reporters seem to have done.
Fink or MacPorts
Jan D.
^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: Emacs 23.1.90 pretest
2009-12-11 14:50 ` Steven Knight
2009-12-11 15:03 ` Jan D.
@ 2009-12-12 16:20 ` Jan Djärv
2009-12-14 23:48 ` Steven Knight
1 sibling, 1 reply; 63+ messages in thread
From: Jan Djärv @ 2009-12-12 16:20 UTC (permalink / raw
To: steven.knight; +Cc: emacs-devel
Steven Knight skrev 2009-12-11 15.50:
> On Fri Dec 11 2009 02:47:26 GMT-0500 (EST), Jan D. wrote:
>> On 2009-12-09 22:20, Steven Knight wrote:
>>> On Wed Dec 09 2009 15:44:06 GMT-0500 (EST), Jan Djärv wrote:
>>>> First we need to find out what font you are trying to use. Can you
>>>> start 23.1 that works and in *scratch* evaluate
>>>>
>>>> (frame-parameter nil 'font)
>>>>
>>>> and see what it returns?
>>>>
>>>> Jan D.
>>>>
>>>>
>>>
>>> Hi,
>>>
>>> You bet. I started emacs (using emacs -Q) and evaluated the above code.
>>> Here is the result:
>>>
>>> -unknown-DejaVu Sans Mono-normal-normal-normal-*-16-*-*-*-m-0-iso10646-1
>>>
>>
>> Hmm. I think you must debug this, I'm trying to figure out where.
>> Does starting with -fn Monospace-12 work?
> $ emacs -Q -fn Monospace-12
> Arithmetic error
>>
>> Can you start gdb on emacs and set a breakpoint in
>> x_default_font_parameter? A session would look something like:
>> (gdb) b x_default_font_parameter
>> (gdb) r -Q
>> break in x_default_font_parameter
>>
>> And then type n to step through and print out variables as they are
>> assigned:
>> (gdb) p font
>> (gdb) pr
>>
>> and
>> (gdb) p system_font
>>
> I will do this and let you know.
No need now.
>
> I've attached a copy of my config.log file (bzipped). I am running
> emacs-23.1.90 on a Fedora 11 system under KDE 4.3.3.
>
Thanks, I found the problem after installing Fedora 11 with KDE. Please test
again with an updated Emacs.
Jan D.
^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: Emacs 23.1.90 pretest
2009-12-09 2:54 Emacs 23.1.90 pretest Chong Yidong
` (4 preceding siblings ...)
2009-12-09 19:01 ` David Robinow
@ 2009-12-14 4:59 ` Juanma Barranquero
2009-12-14 16:03 ` Chong Yidong
2009-12-18 5:27 ` Drew Adams
6 siblings, 1 reply; 63+ messages in thread
From: Juanma Barranquero @ 2009-12-14 4:59 UTC (permalink / raw
To: Chong Yidong; +Cc: emacs-devel
Non-obsolete python.el requires obsolete sym-comp.el, which produces a
warning "Package sym-comp is obsolete!" while loading python.el[c].
^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: Emacs 23.1.90 pretest
2009-12-14 4:59 ` Juanma Barranquero
@ 2009-12-14 16:03 ` Chong Yidong
2009-12-14 16:20 ` Chong Yidong
0 siblings, 1 reply; 63+ messages in thread
From: Chong Yidong @ 2009-12-14 16:03 UTC (permalink / raw
To: Stefan Monnier; +Cc: Juanma Barranquero, emacs-devel
Juanma Barranquero <lekktu@gmail.com> writes:
> Non-obsolete python.el requires obsolete sym-comp.el, which produces a
> warning "Package sym-comp is obsolete!" while loading python.el[c].
Stefan removed sym-comp usage from Python just before the pretest, but
left the (require 'sym-comp) statement in. Removing it fixes this.
But the new completion-at-point for Python is completely broken.
Consider the following recipe:
1. C-x C-f foo.py
2. i M-TAB
=> Emacs loops while completion-at-point is working, apparently without
any exit (I tried waiting for about a minute).
^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: Emacs 23.1.90 pretest
2009-12-14 16:03 ` Chong Yidong
@ 2009-12-14 16:20 ` Chong Yidong
0 siblings, 0 replies; 63+ messages in thread
From: Chong Yidong @ 2009-12-14 16:20 UTC (permalink / raw
To: Stefan Monnier; +Cc: Juanma Barranquero, emacs-devel
Chong Yidong <cyd@stupidchicken.com> writes:
> Juanma Barranquero <lekktu@gmail.com> writes:
>
>> Non-obsolete python.el requires obsolete sym-comp.el, which produces a
>> warning "Package sym-comp is obsolete!" while loading python.el[c].
>
> Stefan removed sym-comp usage from Python just before the pretest, but
> left the (require 'sym-comp) statement in. Removing it fixes this.
>
> But the new completion-at-point for Python is completely broken.
> Consider the following recipe:
>
> 1. C-x C-f foo.py
> 2. i M-TAB
>
> => Emacs loops while completion-at-point is working, apparently without
> any exit (I tried waiting for about a minute).
I found the problem: the code in Python was passing a string with text
property notation to the Python interpreter, confusing it. Should be
fixed in the repository now.
^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: Emacs 23.1.90 pretest
2009-12-12 16:20 ` Jan Djärv
@ 2009-12-14 23:48 ` Steven Knight
0 siblings, 0 replies; 63+ messages in thread
From: Steven Knight @ 2009-12-14 23:48 UTC (permalink / raw
To: Jan Djärv; +Cc: emacs-devel
On 12/12/2009 11:20 AM Jan Djärv wrote:
>
> Thanks, I found the problem after installing Fedora 11 with KDE. Please
> test again with an updated Emacs.
>
> Jan D.
>
>
Hi,
I checkout emacs from cvs and built it; and it works! Thank you so much
for your help.
Thanks,
--
--------------------------------------------------------------------------------
Steven Knight steven.knight@unh.edu
-------------------------------------------------------------------------------
^ permalink raw reply [flat|nested] 63+ messages in thread
* RE: Emacs 23.1.90 pretest
2009-12-09 2:54 Emacs 23.1.90 pretest Chong Yidong
` (5 preceding siblings ...)
2009-12-14 4:59 ` Juanma Barranquero
@ 2009-12-18 5:27 ` Drew Adams
6 siblings, 0 replies; 63+ messages in thread
From: Drew Adams @ 2009-12-18 5:27 UTC (permalink / raw
To: 'Chong Yidong', emacs-devel
Will a Windows binary be posted for the pretest?
Or has it been posted already?
I looked here, but don't see one:
http://alpha.gnu.org/gnu/emacs/pretest/windows/
^ permalink raw reply [flat|nested] 63+ messages in thread
end of thread, other threads:[~2009-12-18 5:27 UTC | newest]
Thread overview: 63+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2009-12-09 2:54 Emacs 23.1.90 pretest Chong Yidong
2009-12-09 4:39 ` Juanma Barranquero
2009-12-09 11:33 ` Eli Zaretskii
2009-12-09 12:46 ` Juanma Barranquero
2009-12-09 20:46 ` Chong Yidong
2009-12-09 20:50 ` Juanma Barranquero
2009-12-09 21:00 ` Chong Yidong
2009-12-09 21:08 ` Glenn Morris
2009-12-09 21:45 ` Chong Yidong
2009-12-10 0:45 ` Juanma Barranquero
2009-12-11 16:48 ` Chong Yidong
2009-12-11 16:58 ` Juanma Barranquero
2009-12-09 9:14 ` Giovanni Lanzani
2009-12-09 17:14 ` Jan Djärv
[not found] ` <95bd41770912090936x26bdf529n4f54ce42729c8876@mail.gmail.com>
2009-12-09 18:20 ` Jan Djärv
2009-12-09 18:35 ` Giovanni Lanzani
2009-12-09 18:47 ` Jan Djärv
2009-12-10 7:49 ` Yavor Doganov
2009-12-10 19:28 ` Jan Djärv
2009-12-10 19:50 ` Yavor Doganov
2009-12-10 21:40 ` Jan Djärv
2009-12-10 23:02 ` Yavor Doganov
2009-12-11 17:15 ` Chong Yidong
2009-12-11 20:07 ` Jan Djärv
2009-12-11 21:36 ` Yavor Doganov
2009-12-11 21:56 ` chad
2009-12-11 22:04 ` Jan Djärv
2009-12-11 23:27 ` Yavor Doganov
2009-12-12 0:00 ` David Reitter
2009-12-12 2:32 ` Chming
2009-12-11 17:19 ` Chong Yidong
2009-12-11 20:05 ` Jan Djärv
2009-12-12 8:10 ` Jan Djärv
2009-12-09 12:11 ` Andreas Schwab
2009-12-09 14:35 ` Chong Yidong
2009-12-09 15:48 ` Andreas Schwab
2009-12-09 18:52 ` Stefan Monnier
2009-12-09 20:07 ` Andreas Schwab
2009-12-09 21:18 ` Stefan Monnier
2009-12-09 21:45 ` Andreas Schwab
2009-12-09 21:56 ` Stefan Monnier
2009-12-09 23:14 ` Andreas Schwab
2009-12-10 0:39 ` Stefan Monnier
2009-12-10 0:45 ` Andreas Schwab
2009-12-10 2:33 ` Stephen J. Turnbull
2009-12-10 9:41 ` David Kastrup
2009-12-10 12:32 ` Stephen J. Turnbull
2009-12-09 18:39 ` Steven Knight
2009-12-09 18:56 ` Jan Djärv
2009-12-09 19:21 ` Steven Knight
2009-12-09 20:44 ` Jan Djärv
2009-12-09 21:20 ` Steven Knight
2009-12-11 7:47 ` Jan D.
2009-12-11 14:50 ` Steven Knight
2009-12-11 15:03 ` Jan D.
2009-12-12 16:20 ` Jan Djärv
2009-12-14 23:48 ` Steven Knight
2009-12-09 19:01 ` David Robinow
2009-12-09 20:17 ` Chong Yidong
2009-12-14 4:59 ` Juanma Barranquero
2009-12-14 16:03 ` Chong Yidong
2009-12-14 16:20 ` Chong Yidong
2009-12-18 5:27 ` Drew Adams
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.