Bug#684788: emacs24-lucid: segfaults on startup
I suspect this may have to do with -Wl,-znocombreloc. If I change the debian/rules to LDFLAGS = $(shell dpkg-buildflags --get LDFLAGS) -Wl,-znocombreloc then the emacs24-lucid package works. The emacs configure checks for and adds -Wl,-znocombreloc to LDFLAGS. But the way the "build_cmd" forces $(MAKE) LDFLAGS=... loses that configure -Wl from the actual compile. Perhaps either build_cmd could not force the flags on the make, but only on the configure invocation, or else ensure -Wl,-znocombreloc is included in the overridden flags. It seems configure uses -Wl,-znocombreloc whenever it works, which for debian would mean always I expect. Dunno what -Wl,-znocombreloc actually does. Something hairy affecting unexec I suppose. Dunno why it only affects the athena build. The relocations which are broken without it are related to structs copied from the shared library into the program data area. Perhaps the gtk build doesn't have any of those. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#684788: emacs24-lucid: segfaults on startup
This bug happens for me too with 24.3+1-1. (Though emacs23-lucid is ok.) gdb suggests that the "superclass" field in emacsFrameClassRec is some wild pointer value, not the intended "&widgetClassRec", causing XtInitializeWidgetClass() to crash when it follows to the superclass. The superclass field in xlwMenuClassRec seems to be the same wild value, though when run it doesn't reach the stage of making menus. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#676424: Bug#454778: emacsen-common: load-path order vs debian-run-directories
Rob Browning writes: > > # The version-specific site-lisp dir, say emacs/21.1/site-lisp, needs > # to be in share/FLAVOR so that as we upgrade from 21.1 to 21.2, > # etc., add-on package bits don't get left behind. Hmm. I suppose if an add-on is removed by a flavour upgrade and that remove fails for some reason then bits are left behind in what's now an old directory. > The symlink was added originally b/c without it, we ended up with a lot > of dangling X.Y directories. Are the X.Y bits all unused by debian add-ons now? Or at least are supposed to be unused. If so then I suppose it wouldn't matter what the X.Y/site-lisp is or is not! :-) -- if that made an empty directory there tempting. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#676424: Bug#454778: emacsen-common: load-path order vs debian-run-directories
Rob Browning writes: > > investigate our load-path handling more carefully, perhaps even more so, > given that Emacs has changed its behavior over the past couple of major > releases -- but I also think that it's probably not something that we > should attempt right now, this close to a release. Ok. If took away the 24.2/site-lisp symlink as thought in the policy then I suppose the load-path would be cleaned up. Or if it was an actual directory instead of a symlink -- if that wasn't yet more confusing. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#676424: Bug#454778: emacsen-common: load-path order vs debian-run-directories
Rob Browning writes: > > It's not the list spine I'm trying to copy, but the string objects Ah, I see. Yes that might be prudent, though the "flavor-dir" one coming in is a fresh concat. > I suppose one argument for keeping the symlink is the possibility that > Emacs or add-on packages may look for that particular directory by name > (which sounds plausible to me). Sounds likely ... change the policy to match the practice :-). > If we're only going to have one of them load-path, the > directory would be the more stable choice -- right now, though, I can't > see how it's being added in the first place. Offhand, I don't see code > for that in either emacsen-common or in emacs24, but perhaps I've missed > it. Hmm. Does "emacs -Q" own startup put all subdirs like /usr/share/emacs/24.2/site-lisp/emacs-goodies-el, then debian adds /usr/share/emacs24/site-lisp/emacs-goodies-el/ You'd be tempted to prune out the /24.2/ ones if they're merely symlinks to the debian ones. It looks like all the 24.2 is at the same place in the load-path order. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#676424: Bug#454778: emacsen-common: load-path order vs debian-run-directories
Rob Browning writes: > >(let* ((paths (mapcar copy-sequence dirs)) ; Ensure we have unique objects. In debian-run-directories? I suspect its &rest makes "dirs" a fresh list anyway. Incidentally, one thing I never understood was why load-path has entries for both "/usr/share/emacs24/site-lisp/emacs-goodies-el" and "/usr/share/emacs/24.2/site-lisp/emacs-goodies-el" I see /usr/share/emacs/24.2/site-lisp is a symlink to /usr/share/emacs24/site-lisp, so I imagine the second doesn't add anything ... if that's true for all flavours etc etc. -- The sigfile covers series: "I drank a slab and the slab won." (to the tune of "I Fought the Law") -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#676424: emacsen-common: debian-startup puts items before /usr/local directories in load-path, violating policy
Hendrik Tews writes: > > (Yes, Coq and Proof General should not use the same Emacs feature > name for different packages. Oh, I see they're not really different, just the coq one is smaller and maybe older. For the debian packages I'd suggest proofgeneral could supercede the coq one, either forcibly move it downward in the load-path, or perhaps the order would be right anyway if the coq package uses debian-pkg-add-load-path-item -- which it ought to do anyway. > http://lists.inf.ed.ac.uk/pipermail/proofgeneral-devel/2012/000241.html) The mixture of debian proofgeneral and manually installed coq or vice-versa which you mention is probably best left to the sysadmin. I'd think anything in /usr/local ought to have precedence. If the sysadmin has put something which doesn't work then it's not a debian package fault :-). -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#676424: emacsen-common: debian-startup puts items before /usr/local directories in load-path, violating policy
Hendrik Tews writes: > > (setq load-path (append add-on-package-paths old-load-path)) This was recently (recently!) noted in bug 117564. I made a report a time after too, missing the earlier one, as bug 454778. > This makes the requirement in the Debian Emacs policy > an absurdity. Yes as it stands but a bug of the implementation. I think the concept of keeping the /usr/local sysadmin's things ahead of packages is sound. > Kevin, you filed quite a lot reports about > debian-pkg-add-load-path-item. Would you add a note to all of > them, telling the maintainers that their package may break when > they switch to debian-pkg-add-load-path-item? I expect the problem is what you note having two coq.el. Emacs behaves very badly when there's two .el of the same name. Code expecting one bombs on the other or vice versa. M-x list-load-path-shadows can help find names which overlap. Occasionally a package intentionally supplies a newer version of something which comes with emacs itself. Otherwise name clashes might be unnoticed until something breaks, probably breaks badly :-(. As an idea for lisp sub-parts you might have seen cedet and semantic do things like (require 'semantic/foo) to get at a component file in a subdir, instead of extending the load path. I don't know how well it works in practice. Plain style semantic-foo.el would no doubt be more traditional. I have an idea update-file-autoloads is wrong from such sub-parts, but apart from that it presumably goes well enough to have been used in cedet. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#582410: (Fwd) Bug#582410: libgtk2-perl: FTBFS on mips: Failed test 'callbacks encountered'
muppet writes: > > This behavior implies that there are cases in which the cell renderer > is never being asked to draw itself. In some of my own tests I wait for map-event before checking certain callbacks and settings, because a window manager can delay map and expose for an arbitrary time (usually small of course) after a program asks to realize a toplevel (other than 'temp' types). Dunno if that happens in this case, but it could be worth waiting for expose-event before saying the render callbacks should have occurred ... with a timeout in case it's wedged, or if some silly wm starts it iconified or something so it's never drawn at all. (This sort of time thing tends to show up on a slow or heavily loaded machine, and not at all when you stick it under the debugger :-) -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#300146: guile-1.6: FTBFS (amd64/gcc-4.0): array type has incomplete element type
Andreas Jochens <[EMAIL PROTECTED]> writes: > > - extern const scm_lt_dlsymlist lt_preloaded_symbols[]; > + extern const scm_lt_dlsymlist *lt_preloaded_symbols; As noted under bug 326527, this is incorrect. It happens to work because the first entry in the array is NULL, but the thing to do to satisfy gcc 4 is make the structure definition available. The 1.6 branch of the guile cvs has such a change. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
