Bug#986553: Acknowledgement (emacs: make-closure is undefined)
On Wed, Apr 7, 2021, at 14:05, Philip Kaludercic wrote: > I apologize for the empty form, this was the first time I used > reportbug. I hope it is ok if I answer the question in this message. That's fine, but please still fill us in on what exactly failed. If you get a *Backtrace* buffer, please save it into a text file and send the file as an attachment to the bug report's address (the address in the Cc: header of this message). If this is related to something in your personal configuration, please also send relevant configuration file(s). Ideally, trim the file down to a minimal example which reliably reproduces the problem every time, and doesn't contain any unrelated configuration details. If you can't do that, please at least tell us whether the problem goes away with emacs -Q If this is specific to a configuration detail which isn't part of the default configuration, I would expect the priority of this bug to be reduced to regular or minor. I'll leave that to the package maintainer to decide, though. -- (Just an innocent bystander doing bug triage.)
Bug#924762: further information
On Sun, Mar 17, 2019, at 04:51, zieg...@uni-freiburg.de wrote: > The problem occurs also with the current kernel > linux-image-4.19.0-4-amd64. Could you please share your `locale' settings? Does a file with this name exist in the current directory? Is it possible to create a file with this name? (I'm guessing you have everything configured for UTF-8 and thus a lone 0xE4 is an incomplete multibyte sequence.) -- If this were a real .signature, it would suck less. Well, maybe not.
Bug#886024: split off anything-el related part
On Wed, Jan 3, 2018, at 03:45, H.-Dirk Schmitt wrote: > On Mi, 2018-01-03 at 02:06 +0200, era eriksson wrote: > > Code outline for an emacs batch wrapper > > I do not insist on bash – you are free to fix it in any programming > language ;-) A fair amont of work has gone into making the core system work without Bash. If you want this proposal to succeed, it woud seem important to demonstrate a good understanding of the surrounding system and the needs of our users. I'll be happy to try to convert this script into POSIX sh or at least Dash-compatible code if the maintainers agree that this is a good way forward, but so far, my impression is that they are unconvinced, or perhaps just waiting to see if this evolves into a serious proposal. The compilation bug you originally reported does not seem to affect other users, and at least I am still wondering if there is a way to trigger it which is likely to happen again. However, I think it would be useful to improve package compilation, with an eye towards making bug reporting easier and eventually somewhat more scriptable, perhaps with some way for Ubuntu's Apport system and eventually even some Debian-native replacement to hook in and fetch logs etc. I'm just thinking out loud here; sorry if this comes across as a rant. /* era */ -- If this were a real .signature, it would suck less. Well, maybe not.
Bug#886024: split off anything-el related part
Your emacs-batch script seems to have some issues. I have not reviewed
it properly, but e.g. your prevalent use of the declare keyword is
definitely a bashism.
More generally, making Emacs package compilation more robust is
absolutely not a bad idea; but introducing new requirements should also
be reflected in the Emacs policy (though honestly not sure what its
current status is?)
On Tue, Jan 2, 2018, at 22:34, H.-Dirk Schmitt wrote:
> Here a simple wrapper script would help to :
> - avoid copy and paste errors
> - simplify the fix of this bug
> - simple reuse
>
>
> Code outline for an emacs batch wrapper
>
>
> Assume a bash script *emacs_batch* replacing the `-q --batch` options.> It
> should take as 1st option the emacs flavour (e.g. emacs25) and pass> trough
> all other options except `-q`,
> `--no-init-file` (alias to `-q`) and `--batch`.
>
> The emacs call could be implemented in this way:
>
> ```
> declare -r catchFile=$(mktemp) # create temporary
> file> for output
Exit on failure; $(mktemp) || exit
> trap rm --force ${catchFile}# and ensure cleanup
The trap declaration seems to be wrong (the trap code needs to be a
single string and you need to specify which signals and conditions
to trap on).
> ${FLAVOUR} --batch "${cmdlineOptions[@]}" &>"${catchFile}" & #
> fork> declare -i emacsPid=$! # and remember
> sleep ${emacsTimeOut} & # fork timeout watch
> declare -i sleepPid=$! # and remember
> wait -n ${emacsPid} ${sleepPid} # -n → wait for the
> next ending job
> declare -r rc=$?# don't forget the
> exit> code
> if ! $(kill ${sleepPid})
The command substitution is fishy too.I guess you mean simply
if ! kill $sleepPid
or do you actually expect kill to print something?
> then# oops run in timeout>
> … add error handling here
> else# emacs terminates
> without timeout
>cat ${catchFile} # forward console
>output>exit ${rc} # rc is
> originating
>from> emacs
> fi
> ```
>
>
/* era */
--
If this were a real .signature, it would suck less. Well, maybe not.
Bug#866727: Also affects Ubuntu
This also affects Ubuntu and has been reported in the wild by users upgrading from earlier versions of the distro. https://bugs.launchpad.net/debian/+source/oneliner-el/+bug/1586145 (Notice also the recent duplicate if you have trouble with the error messages being in German.) The problem might be with the apel package, which is what provides poe but I have been unable to spot anything obvious like a particular version in which poe was added (it's been there like forever; the changelog mentions it in 2009). -- If this were a real .signature, it would suck less. Well, maybe not.
Bug#686113: Coordinate with similar Ubuntu bugs
The following two Ubuntu bugs have similar symptoms: * https://bugs.launchpad.net/ubuntu/+source/maildir-utils/+bug/1150593 * https://bugs.launchpad.net/ubuntu/+source/maildir-utils/+bug/1199553 The former reports that replacing an elpa install of org-mode with the Ubuntu-packaged org mode fixed things for him. (If the elisp sources are required, I would sort of expect it to be the other way around? Or does elpa also only install elc files?) /* era */ -- If this were a real .signature, it would suck less. Well, maybe not. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#686113: Workaround: Temporarily uninstall mu4e
We now have a report that uninstalling mu4e allows the emacs24 install to finish, whereby mu4e can be installed successfully as well. To follow up on my earlier note, I'm beginning to think that the elpa diagnostic was wrong, and that the real issue is the sequence in which you install emacs24 and mu4e. Maybe emacs24-el just happened to set things up to happen in the proper order as well, and is not a true requirement? Sorry for talking to myself here ... /* era */ -- If this were a real .signature, it would suck less. Well, maybe not. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#677191: Add watch: LP#789706
Just a quick note that Ubuntu Launchpad has a largish number of recent duplicates for this bug. https://bugs.launchpad.net/ubuntu/+source/xemacs21/+bug/789706 xemacs21 has been stable (as in basically unmaintained in Ubuntu) for a long time, across several Ubuntu releases. This points to emacsen-common as the likely source for whatever exposes this, although it may well be that the root cause for the bug is in the xemacs21 packaging. #313511 looks similar, maybe the changes discussed there are actually relevant for this case? /* era */ -- If this were a real .signature, it would suck less. Well, maybe not. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#597530: emacs23: My outgoing mail is lost
merge 597530 397757 thanks On Mon, 20 Sep 2010 23:49 +0200, Stefan Monnier monn...@iro.umontreal.ca wrote: See #397757 why this would be correct. Agreed. I guess this can be merged with #397757. Hence. /* era */ -- If this were a real .signature, it would suck less. Well, maybe not. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#597530: Processed: Re: Processed: One more time fer paw
On Tue, 05 Oct 2010 10:51 +, Debian Bug Tracking System ow...@bugs.debian.org wrote: reassign 597530 emacs23 Thanks. I was wondering how I should cope with this. /* era */ -- If this were a real .signature, it would suck less. Well, maybe not. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#444982: Secure coding guidelines
On Fri, 26 Oct 2007 14:28:28 +0200, Nico Golde [EMAIL PROTECTED] wrote: Does the (testing) security team have a comprehensive page with security best and worst practices? To be able to point people at it, so one [doesn't] have to point at random wikipedia pages or google hits? No, but I can recommend [http://tinyurl.com/2sennu] for some secure coding notes regarding the c language. ... which is huge and complex, and still not by any measure comprehensive. This should tell you something about the reason security problems aren't all that rare, and give you some idea why the idea of a simple checklist usually cannot replace the one cure security researchers have tried unsuccessfully now for many years: proper education (while the other approach, architectures and designs which leave less room for error, is in principle good, but very slow to pick up steam, for somewhat obvious reasons). Having said that, if you want checklist-type stuff, Lincoln D. Stein's Web Security FAQ http://www.w3.org/Security/Faq/ certainly ought to be on the required reading list. More generally, google for secure CGI and don't stop reading. There should be about 9,830,000 documents in the result set. Hope this helps (-: /* era */ -- If this were a real .signature, it would suck less. Well, maybe not. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#444982: (no subject)
On Sun, 21 Oct 2007 19:48:23 +1000, Sven Dowideit [EMAIL PROTECTED] wrote: 777 is on the working/tmp dir only, which is not used for any web content. Also, as the twiki cgi scripts are callable from the command line by any user, requiring the working/tmp dir to be writable by any user, I can't think of any way that this is fixable? Longer term, how about improving the architecture by adding an API to twiki itself? As a twiki user, I have been longing desperately for something like that for a long time, and that would help solve this problem, too. TWiki does have a very painful set of assumptions, which don't map easily to debian To some extent, it would fix this as well, I guess. /* era */ PS. Some more secure CGI links for you: http://tinyurl.com/37tbz5 (brian d foy's CGI Meta FAQ) and from there in particular Simson Garfinkel's http://thinkunix.net/web/cgi-rules.txt checklist. -- If this were a real .signature, it would suck less. Well, maybe not. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#415362: Security fix included in GNU file 4.20
Package: file Version: 4.19-1 Severity: grave Tags: security X-Debbugs-Cc: [EMAIL PROTECTED] According to the changelog included in the GNU file 4.20 tarball at ftp://ftp.gw.com/mirrors/pub/unix/file/, this version includes a security fix: 2007-02-08 17:30 Christos Zoulas [EMAIL PROTECTED] * fix integer underflow in file_printf which can lead to to exploitable heap overflow (Jean-Sebastien Guay-Lero) I have not seen this receive any publicity. A quick Google seems to confirm this. The release announcement with pertinent ChangeLog is also at http://mx.gw.com/pipermail/file/2007/000161.html if you don't want to grab the full tarball. Sorry if I have assigned an inflated severity; I suppose it's better at this point to exaggerate than to downplay. The instructions at http://www.debian.org/Bugs/Developer#severities suggest grave for a bug which introduces a security hole allowing access to the accounts of users who use the package. I'm not sure about introduces (it likely existed before?) and without an isolated patch, it's hard to assess the exact scope of the vulnerability, even for someone more skilled than myself. /piglet panics /* era */ -- If this were a real .signature, it would suck less. Well, maybe not. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
