Bug#972946: ftp.debian.org: sections.822: inconsistencies
Package: ftp.debian.org Severity: minor Patch: yes Thanks for providing this. I noticed the long description wasn't entirely consistent. This adds a full stop where missing. /* era */ --- sections.822~ 2020-10-26 11:16:59.0 +0200 +++ sections.8222020-10-26 11:19:53.0 +0200 @@ -48,7 +48,7 @@ Section: contrib/education Description: Education -Longdesc: Software for learning and teaching +Longdesc: Software for learning and teaching. Section: contrib/electronics Description: Electronics @@ -200,7 +200,7 @@ Section: contrib/science Description: Science -Longdesc: Basic tools for scientific work +Longdesc: Basic tools for scientific work. Section: contrib/shells Description: Shells @@ -276,7 +276,7 @@ Section: education Description: Education -Longdesc: Software for learning and teaching +Longdesc: Software for learning and teaching. Section: electronics Description: Electronics @@ -428,7 +428,7 @@ Section: non-free/education Description: Education -Longdesc: Software for learning and teaching +Longdesc: Software for learning and teaching. Section: non-free/electronics Description: Electronics @@ -580,7 +580,7 @@ Section: non-free/science Description: Science -Longdesc: Basic tools for scientific work +Longdesc: Basic tools for scientific work. Section: non-free/shells Description: Shells @@ -668,7 +668,7 @@ Section: science Description: Science -Longdesc: Basic tools for scientific work +Longdesc: Basic tools for scientific work. Section: shells Description: Shells -- 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#865401: base-passwd: erratic punctuation spacing in English debconf questions
Package: base-passwd Version: 3.5.39 Severity: minor X-Debbugs-Cc: era+deb...@iki.fi I was playing around with debconf-get-selections, and noticed this: root# debconf-get-selections | grep -A 1 ' ?' | > sed -n $'/^[^-#]/s/\t.*//p' | uniq -c 12 base-passwd In English (unlike e.g. in French) orthography, question marks (and exclamation marks) are typed adjacent to the preceding word, with no space between. root# debconf-get-selections | grep ' ?' # Do you want to add the group ? # Do you want to move the user ? # Do you want to change the GID of user ? # Do you want to remove the group ? # Do you want to change the UID of user ? # Do you want to remove the user ? # Do you want to change the GID of group ? # Do you want to change the shell of user ? # Do you want to change the GECOS of user ? # Do you want to move the group ? # Do you want to change the home directory of user ? # Do you want to add the user ? On a fairly spare system (Docker image with just debconf-utils installed in addition to the base system), this is the only package with this problem. There are strings with question marks which are correctly formatted in libc6, dash, adduser, and libpam-runtime. (This was actually an Ubuntu image, for what it's worth; but the package version indicates that base-passwd package was copied verbatim from Debian.) For consistency, please adjust these strings to fix the formatting. sed 's/ ?/?/g' I realize this will trigger a pesky review of the translations of these strings. Maybe somehow the translator teams need to be included for coordination. Incidentally, I notice the same problem in ucf, but I don't have the time to go through every package, nor to coordinate mass bug filing at this point. /* era */ -- If this were a real .signature, it would suck less. Well, maybe not.
Bug#841038: Odd formatting in PHP license position statement
Package: ftp.debian.org Version: 20161017 Severity: minor X-Debbugs-Cc: era+deb...@iki.fi There is a Debian position statement regarding the PHP license at https://ftp-master.debian.org/php-license.html This was recently highligthed on DDA [1] and thus brought to my attention. The blockquote formatting on this page seems wrong. I guess the following pseudo-diff against the page HTML should be applied (which also includes a simple typo fix near the beginning): Debian packages include PHP and PHP add-ons but we don't - attempt to, nor can we, resolve the impossible quandry +attempt to, nor can we, resolve the impossible quandary that the language of the PHP 3.01 license creates. It is a free software license and we modify the software and correctly designate the source of its origin by calling it PHP or X for PHP. The license requires us to make a statement: "This product includes PHP software, freely available from - http://www.php.net/software/;, the veracity of which cannot be +http://www.php.net/software/; +the veracity of which cannot be verified by us, nor can we be held responsible for the maintenance of the link. - Even with these changes, it is not clear (at least to me) which part(s) of the position statement needs to be included in PHP packages. Perhaps the page could be reorganized to contain a specific copy/pastable snippet for easy reuse? I hope reporting the problems via a bug report against ftp.debian.org is acceptable procedure. If not, please help me understand how to bring this up properly. Thanks in advance, /* era */ [1] https://lists.debian.org/debian-devel-announce/2016/10/msg4.html -- If this were a real .signature, it would suck less. Well, maybe not.
Bug#803767: debian-changelog-mode: don't rely on external date (LP#1197870)
Package: dpkg-dev-el Version: 35.12 Tags: patch X-Debbugs-Cc: era+deb...@iki.fi The current debian-changelog-mode shells out to coreutils' date. To increase portability (some developers work on packages from other architectures), it would be nice to see this clean up get integrated: https://github.com/pcarrier/debian-changelog-mode/commits/master --- Belatedly forwarding upstream this bug from the Ubuntu Launchpad. https://bugs.launchpad.net/ubuntu/+source/emacs-goodies-el/+bug/1197870 The original submitter was Pierre Carrier; please make sure to credit him properly if/when you merge this. -- If this were my real .signature, it would suck much less. Well, maybe.
Bug#798320: aptitude: returns 0 (success) exit code when no packages found
Package: aptitude Version: 0.6.11-1+b1 X-Debbugs-Cc: era+deb...@iki.fi I bumped into another case where a zero (success) exit code was produced when the requested action could not be taken. I'm submitting this as a separate bug report even though it has similarities with e.g. #590686 and #592818 and should hopefully be possible to fix with similar means. The scenario has to do with installing i386 packages on an x86_64 system. I can successfully "dpkg --add-architecture i386" but the partial mirror in the test network we have at work doesn't carry any i386 packages, so they cannot be installed. dpkg --add-architecture i386 && aptitude update && aptitude install -y libc6:i386 || echo failed appears to succeed in this scenario; whereas with apt-get instead of aptitude, I get the desired and expected behavior. The output from aptitude is: jessie$ sudo aptitude install -y libc6:i386 Couldn't find any package whose name or description matched "libc6:i386" Couldn't find any package whose name or description matched "libc6:i386" No packages will be installed, upgraded, or removed. 0 packages upgraded, 0 newly installed, 0 to remove and 1 not upgraded. Need to get 0 B of archives. After unpacking 0 B will be used. jessie$ echo $? 0 Note that this also masks the error when you did dpkg --add-architecture but forgot to do apt-get update to download new package indices for the architecture you added. (Also notice the unattractive but harmless duplicated message.) /* era */ -- If this were a real .signature, it would suck less. Well, maybe not.
Bug#588961: Close as unreproducible
tag 588961 +unreproducible +wontfix close 588961 thanks Submitter: This bug report does not contain sufficient information to diagnose the problem. It looks like a communications error with gksu. If you are able to diagnose the problem, please feel free to reopen and perhaps reassign to gksu, or whichever component originally misconfigured things on your system. /* era */ -- If this were a real .signature, it would suck less. Well, maybe not. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#663424: sources.debian.net to the rescue
As a partial remedy, sources.debian.net now exposes the sources for browsing, though it's not quite the same as having them on Github. https://sources.debian.net/src/equivs/ /* era */ -- If this were a real .signature, it would suck less. Well, maybe not. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#774768: See also #775974
Tangentially, see also #775974 -- If this were a real .signature, it would suck less. Well, maybe not. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#775974: lists.debian.org: Disable AHBL in SpamAssassin
Package: lists.debian.org X-Debbugs-Cc: era+deb...@iki.fi Apparently, all messages now get the AHBL hit, which increases the likelyhood of spam false positives. Spot checks reveal this problem at least on debian-user-spanish, debian-russian, and debian-l10n-french, but apparently, all lists are affected. For example, a recent message to debian.user-spanish [1] has the following SpamAssassin headers: X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on bendel.debian.org X-Spam-Level: X-Spam-Status: No, score=-9.4 required=4.0 tests=DNS_FROM_AHBL_RHSBL, LDOSUBSCRIBER,LDO_WHITELIST,RDNS_NONE autolearn=unavailable version=3.3.2 While the total score is fine, the AHBL hit is spurious, and the rule should be disabled. The service was decommissioned on Jan 1, 2015, and is now returning a blocked status for all queries; here is the DNSBL maintainer's announcement: http://www.ahbl.org/content/changes-ahbl Tangentially, see also http://article.gmane.org/gmane.discuss/16570 [1] https://lists.debian.org/debian-user-spanish/2015/01/msg00195.html but this view does not include full headers. You could also access it over NNTP from Gmane.org for full headers -- I think a useful URL could be news://news.gmane.org/gmane.linux.debian.user.spanish:197903 but I don't have a tool I can check this with (maybe change news: to nntp: IIRC?) -- If this were a real .signature, it would suck less. Well, maybe not. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#566943: Repro attempt
I tried to send email to 566943-h...@bugs.debian.org as suggested in the feedback from the (then?) list maintainer, and got nothing back. I sent another bug report in the meantime and that registered properly, and I got the expected reply, so my mail does seem to be going through, both ways. -- If this were a real .signature, it would suck less. Well, maybe not. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#772952: 7z: Error messages go to stdout
Package: p7zip-full Version: 9.04~dfsg.1-1 Severity: minor X-Debbugs-Cc: era+deb...@iki.fi 7z prints error messages to standard output. This makes it impossible to keep apart regular output and error messages, and violates user expectations, if not applicable standards. When you are running 7z as a subprocess, the intuition is to display standard error (but not necessarily standard output) in case of an error. But this displays nothing at all, and loses the error message for the user. (The following demo case depends on what I believe is undocumented behavior: passwords with newlines in them are rejected with -tzip.) debian$ 7z a -p'4$$w0rD ' -tzip /tmp/archive.zip /etc/motd /dev/null debian$ echo $? 2 debian$ ls -l /tmp/archive.zip ls: cannot access /tmp/archive.zip: No such file or directory debian$ 7z a -p'4$$w0rD ' -tzip /tmp/archive.zip /etc/motd 2/dev/null 7-Zip 9.04 beta Copyright (c) 1999-2009 Igor Pavlov 2009-05-30 p7zip Version 9.04 (locale=en_US.UTF-8,Utf16=on,HugeFiles=on,1 CPU) Scanning Creating archive /tmp/archive.zip System error: E_INVALIDARG This is tangentially related to #528200 -- whoever tackles one should probably tackle the other at the same time. -- If this were a real .signature, it would suck less. Well, maybe not. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#346463: Bug#772952: 7z: Error messages go to stdout
package p7zip p7zip-full forcemerge 346463 772952 thanks Sorry, I foolishly only consulted the p7zip-full bug listing, and thus missed the duplicate. On Fri, Dec 12, 2014, at 14:46, era eriksson wrote: Package: p7zip-full Version: 9.04~dfsg.1-1 Severity: minor X-Debbugs-Cc: era+deb...@iki.fi 7z prints error messages to standard output. This makes it impossible to keep apart regular output and error messages, and violates user expectations, if not applicable standards. When you are running 7z as a subprocess, the intuition is to display standard error (but not necessarily standard output) in case of an error. But this displays nothing at all, and loses the error message for the user. ... -- If this were a real .signature, it would suck less. Well, maybe not. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#761621: bash: cannot echo $'\x00'
Package: bash Version: 4.1-3 Severity: wishlist X-Debbugs-Cc: era+debb...@iki.fi I was somewhat surprised and miffed to find that this does not work. I found old correspondence about this issue on the bash-bugs mailing list [1] but it was hardly an exhaustive discussion. [1]: http://lists.gnu.org/archive/html/bug-bash/2006-03/msg00063.html To my mind, in particular the non-POSIX $'\x00' syntax could impossibly be used in scripts which do not run Bash. It's not entirely clear to me what the logic should be here; if the builtin echo really cannot support this, then perhaps a warning message would be appropriate. As noted in the 2006 discussion, a (portable!) workaround is to use printf instead. -- If this were a real .signature, it would suck less. Well, maybe not. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#758192: unzip: prints to terminal, even with -qq
Package: unzip Version: 6.0-4 Severity: minor X-Debbugs-Cc: era+debb...@iki.fi The unzip utility has odd, non-Unixy output handling. There are messages which are almost impossible to (guess how to) redirect or squelch. This includes (but may not be limited to) error output from the unzip -t command. squeeze$ unzip -t -qq LATAM43.zip /dev/null ... produces a lot of output ... squeeze$ unzip -t -qq LATAM43.zip 2/dev/null ... still produces a lot of output ... squeeze$ unzip -t -qq LATAM43.zip file 21 squeeze$ # oddly, only one copy of the output in file! squeeze$ unzip -t -qq LATAM43.zip | less ... still messes up my screen ... squeeze$ unqip -t -qq LATAM43.zip 21 | less squeeze$ # again, works, but not what you would expect Unfortunately, the file in question contains material I cannot share, but it should not be hard to come by broken ZIP archives. As a rough approximation, you can observe the same behavior (but very different error output) with just squeeze$ echo moomoo.zip squeeze$ unzip -t -qq moo.zip 2/dev/null /* era */ -- If this were a real .signature, it would suck less. Well, maybe not. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#734712: jack3rc configuration file format undocumented
Package: jack Version: 3.1.1+cvs20050801-26 X-Debbugs-Cc: era+deb...@iki.fi Forwarding my own Ubuntu bug report to the Debian upstream maintainer. https://bugs.launchpad.net/ubuntu/+source/jack/+bug/960970 The manual page says that the --save option will write out your selected options to the file ~/.jack3rc but not all options are written there, and some configuration directives are not available as options. For example, when I ran jack, it complained that the base_dir variable was not set, and I noticed that the value of the -Q option does not get written to the generated .jack3rc. For what it's worth, here is what I ended up with. The file /usr/share/pyshared/jack_config.py shows what options are available and their internal names. # jackrc-version:31 encoder:flac # Undocumented, gleaned from error message base_dir:flac # Undocumented, will not be written here by --save; gleaned from source query_on_start:1 -- If this were a real .signature, it would suck less. Well, maybe not. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#734718: jack -x option not understandable
Package: jack Version: X-Debbugs-Cc: era+deb...@iki.fi Forwarding my Ubuntu bug report to the Debian upstream maintainer. https://bugs.launchpad.net/ubuntu/+source/jack/+bug/961019 The manual states that the -x option causes jack to run a predefined command when it finishes, but it is not stated how this command is defined or where and how it can be set. Running jack -x eject causes an error message to be displayed. Running jack -x=exec_rip_done does nothing after finishing. From reading the sources, it appears in /usr/share/pyshared/jack_main_loop.py that the value of the configuration variable exec_rip_done is passed to os.system() when -x is present. Thus, in my case, simply jack -x did do what I want, and what it does can be changed by setting exec_rip_done in your ~/.jack3rc. -- If this were a real .signature, it would suck less. Well, maybe not. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
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-dist-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-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#714131: bugs.debian.org: inline attachment view; full text isn't
Package: bugs.debian.org Severity: minor X-Debbugs-Cc: era+debb...@iki.fi When looking at a bug via the web interface, it would be useful to be able to browse patches without downloading them. Frequently, this is not possible, because the patches are served with a content-disposition: attachment which cause most browsers to display a download dialog. If I'm just browsing, and just want to take an informal look at the proposed patch, it would be much more useful to have it served as Content-type: text/plain; Content-disposition: inline and thus rendered in the browser just like any other textual content. (Granted, some patches are base64 encoded and/or compressed.) The BTS web interface offers full text and mbox links for each message on a web page. I don't know what problems they are intended to solve and for whom, but it would be a nice first approximation if the full text link would actually display the full MIME source, rather than just render the (full) headers. Alternatively, perhaps each attachment could be made available via a separate inline link as well -- by the looks of the href, the back end already has the file as a separate object. If the browser cannot render it, too bad. /* era */ -- If this were a real .signature, it would suck less. Well, maybe not. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#409058: Fixed?
package readpst notfound 409058 0.6.54-0ubuntu1 thanks This is not reproducible on Ubuntu Precise. Because the Ubuntu diffs show no indication that there is any Ubuntu-specific fix for this, I speculate that it is fixed (or for all I know wfm), /* era */ -- If this were a real .signature, it would suck less. Well, maybe not. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#520947: Repro instructions
I have had SpamAssassin eating a lot of memory. In order to limit the damage, I set it up with fairly aggressive ulimits. Unfortunately, that means I am now also getting this error message. I don't see crashes, though. Here is a pared-down version of the script I use to start up spamd: #!/bin/sh ulimit -v 204800 ulimit -m 204800 ulimit -n 256 # This is the beef. Try even lower numbers. # I could not start it at all with ulimit -u 110 ulimit -u 150 perl -T -I lib -w spamd \ --configpath myrules \ --siteconfigpath mapsd.cf \ --helper-home-dir . \ --nouser-config \ --syslog stderr \ --min-children 2 \ --max-spare 5 \ --max-children 40 \ $@ The ulmit values are otherwise out of contrib/run-masses but I could not run spamd at all with the ulimit -u 30 they have. @Christian: If you signed up for Debian bug reports, only you can unsubscribe. You should see in the headers with what ID you have subscribed; I believe you should also see an unsubscribe link there. /* era */ -- If this were a real .signature, it would suck less. Well, maybe not. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#685933: No, don't close
I don't think these bugs should be closed until there is a useful diagnostic instead of an error message most users won't know how to interpret. /* era */ -- If this were a real .signature, it would suck less. Well, maybe not. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#691345: emacs24: org-export fails without emacs24-el
Package: emacs24 Version: 24.1+1-2 X-Debbugs-Cc: era+deb...@iki.fi Forwarding an emacs24 bug report from an Ubuntu user; https://bugs.launchpad.net/ubuntu/+source/emacs24/+bug/1064024 submitted by Fredrik Nyqvist on 2012-10-08: When I am trying to export my .org document to another format by using the command C-c C-e I get the response Can't find library org. 1) Ubuntu 12.10 Beta 2 2) emacs24 24.1+1-2ubuntu3 3) I want to export my .org file to pdf or other format using Emacs. 4) I get the response Can't find library org. Here is the resulting Lisp backtrace: Debugger entered--Lisp error: (error Can't find library org) signal(error (Can't find library org)) error(Can't find library %s org) find-library-name(org) (file-name-directory (find-library-name org)) (expand-file-name ../contrib (file-name-directory (find-library-name org))) (file-name-as-directory (expand-file-name ../contrib (file-name-directory (find-library-name org (expand-file-name scripts (file-name-as-directory (expand-file-name ../contrib (file-name-directory (find-library-name org) (file-name-as-directory (expand-file-name scripts (file-name-as-directory (expand-file-name ../contrib (file-name-directory (find-library-name org)) (expand-file-name ditaa.jar (file-name-as-directory (expand-file-name scripts (file-name-as-directory (expand-file-name ../contrib (file-name-directory (find-library-name org))) eval((expand-file-name ditaa.jar (file-name-as-directory (expand-file-name scripts (file-name-as-directory (expand-file-name ../contrib (file-name-directory (find-library-name org custom-initialize-reset(org-ditaa-jar-path (expand-file-name ditaa.jar (file-name-as-directory (expand-file-name scripts (file-name-as-directory (expand-file-name ../contrib (file-name-directory (find-library-name org custom-declare-variable(org-ditaa-jar-path (expand-file-name ditaa.jar (file-name-as-directory (expand-file-name scripts (file-name-as-directory (expand-file-name ../contrib (file-name-directory (find-library-name org))) (/usr/share/emacs/24.1/lisp/org/org-exp-blocks.elc . 6155) :group org-babel :type string) require(org-exp-blocks) byte-code(\300\301!\210\300\302!\210\300\303!\210\300\304!\210\300\305!\210\300\306!\207 [require org org-macs org-agenda org-exp-blocks ob-exp org-src] 2) -- If this were a real .signature, it would suck less. Well, maybe not. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#594514: Belatedly tagging
tags 594514 + wontfix thanks As per Rob's latest comment (only from 2010 ...) I am tagging this as wontfix. /* era */ -- If this were a real .signature, it would suck less. Well, maybe not. -- To UNSUBSCRIBE, email to debian-bugs-dist-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-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#663424: (no subject)
Severity normal? Really? Anyway, I'm not really interested. Color me dismayed. This would be for the benefit of your users, not primarily for you. In fact, I'm certain that you already have access to your VCS. For the record, I too would like to see this happen. /* era */ -- If this were a real .signature, it would suck less. Well, maybe not. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#679101: equivs: equivs-build: no quoting of $builddir
Package: equivs Version: 2.0.9 X-Debbugs-Cc: era+deb...@iki.fi I am hereby forwarding Ubuntu bug #1016402 to the upstream maintainer of equivs from the Ubuntu bug tracking system. https://bugs.launchpad.net/ubuntu/+source/equivs/+bug/1016402 --- cut --- 8 --- Steps to reproduce: 1. mkdir -p '/tmp/a/abc' 2. put some code and debian packaging into this dir 3. run mk-build-deps/equivs-build Result: mmrazik@fry:/tmp/a/abc/autopilot$ equivs-build debian/control sh: 1: b: not found Error on copy of the template files: exit status 127 Expected result: it works. Patch attached. --- 8 --- tuc --- For your convenience, I am inlining the patch, since it is completely trivial. Perhaps there are other spots in the code which should be audited for proper quoting, though. --- equivs-build2012-06-22 09:27:18.0 +0200 +++ equivs-build.new2012-06-22 09:27:06.0 +0200 @@ -46,7 +46,7 @@ usage(); } -system(cp -R /usr/share/equivs/template/* $builddir) == 0 or +system(cp -R /usr/share/equivs/template/* \$builddir\) == 0 or die Error on copy of the template files: exit status . ($?8) . \n; # Parse the equivs control file If you accept the patch, please note that the original author is Martin Mrazik, not me. Thanks. /* era */ -- If this were a real .signature, it would suck less. Well, maybe not. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#543564: lintian check against info/dir(.gz)?
On Tue, 14 Feb 2012 10:42:47 +, Richard Kettlewell r...@greenend.org.uk wrote: Perhaps there should be some systematic approach to preventing packages shipping such toxic files? There is; bug #535566. (Omitting cc: 659...@bugs.debian.org as it's already fixed in cvs.) /* era */ -- If this were a real .signature, it would suck less. Well, maybe not. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#667451: haskell-mode: fails to support emacs-snapshot et al.
Package: haskell-mode
Version: 2.7.0-2.1
Severity: wishlist
X-Debbugs-Cc: era+deb...@iki.fi
Tags: patch
The patch for #568579 would appear to also drop support for e.g.
emacs-snapshot. I use neither emacs-snapshot nor haskell-mode, so I'm
not going to push this any further, but if you publish another update at
some point, you might want to change the logic to explicitly ignore
xemacs21 and support everything else, instead of the other way around.
The patch also changes the behavior for the case when ${FLAVOR} is just 'emacs'
-- I'm not intimately familiar with this part of the Debian emacsen
infrastructure, but you might want to reinstate the quiet behavior that existed
before the NMU.
For context, here is the patch from that bug report:
-if [ ${FLAVOR} = emacs ]; then exit 0; fi
+case ${FLAVOR} in
+emacs2[2-9]*)
+ echo install/${PACKAGE}: Handling install for emacsen flavor ${FLAVOR}
+ ;;
+*)
+ echo install/${PACKAGE}: Ignoring emacsen flavor ${FLAVOR}
-echo install/${PACKAGE}: Handling install for emacsen flavor ${FLAVOR}
+ exit 0
+ ;;
+esac
Here is my proposal for a revised patch:
-if [ ${FLAVOR} = emacs ]; then exit 0; fi
+case ${FLAVOR} in
+emacs)
+ exit 0
+ ;;
+xemacs21)
+ echo install/${PACKAGE}: Ignoring emacsen flavor ${FLAVOR}
+ exit 0
+ ;;
+*)
+ echo install/${PACKAGE}: Handling install for emacsen flavor ${FLAVOR}
+ ;;
+esac
Finally, shouldn't Depends: whatever | xemacs21 be dropped from
debian/control?
/* era */
--
If this were a real .signature, it would suck less. Well, maybe not.
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#655971: tags 655971 +patch
tags 655971 +patch thanks The linked CVE report has a forward link to a git repo with patches for Debian et al. /* era */ -- If this were a real .signature, it would suck less. Well, maybe not. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#653279: (no subject)
As you can tell by the diagnostic output, you cannot use a regex anchor to signal beginning of file in this context. Did you get the impression from the documentation that this ought to be possible? An easy patch would be to convert any initial '^' anchor in the search expression to the separator used in /var/lib/dlocate/dlocatedb before running the grep command (that is, convert it to ': ') but then the -S regex template has to be tweaked slightly to accommodate this change. /* era */ -- If this were a real .signature, it would suck less. Well, maybe not. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#312829: reassign to anthy-el?
Shouldn't you instead reassign this to anthy-el? anthy-el Requires: emacsen but should probably also Conflicts: xemacs21-nomule if the analysis earlier in this bug report is correct. /* era */ -- If this were a real .signature, it would suck less. Well, maybe not. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#628790: auctex: TeX-next-error broken for error messages without line number
Package: auctex
Version: 11.85-1
X-Debbugs-Cc: era+deb...@iki.fi
I am forwarding the following bug report from Ubuntu:
https://bugs.launchpad.net/ubuntu/+source/auctex/+bug/790212
The actual package version in Ubuntu is 11.85.1ubuntu1.
Test case (see original description below for repro steps); save as
test.tex:
\documentclass{article}
\begin{document}
\emph{
\end{document}
When you hit C-c C-c LaTeX RET, emacs says LaTeX errors in `*~/test
output'. Use C-c ` to display.
Then I hit C-c ` and I expect one buffer called *TeX Help* to be created
containing the Missing } inserted error, alongside the original
test.tex buffer.
But this doesn't happen: instead, two buffers are created: one called
*TeX Help*, and a read-only buffer called Debian. Both are empty, and
the minibuffer says: Search failed: ^l\\. These two buffers replace
the test.tex buffer.
The problem seems to be that TeX-next-error expects every error in the
log file to have a line number attached to it. But the error here is
! File ended while scanning use of \emph .
which doesn't generate a line number.
--- Original bug report ---
If I run emacs -q and load the following file, ~/test.tex:
\documentclass{beamer}
\begin{document}
\begin{frame}
$a_{b$
\end{frame}
\end{document}
and hit C-c C-c LaTeX RET, emacs says LaTeX errors in `*~/test output'.
Use C-c ` to display.
Then I hit C-c ` and I expect one buffer called *TeX Help* to be created
containing the Missing } inserted error, alongside the original
test.tex buffer.
But this doesn't happen: instead, two buffers are created: one called
*TeX Help*, and a read-only buffer called Debian. Both are empty, and
the minibuffer says: Search failed: ^l\\. These two buffers replace
the test.tex buffer.
Incidentally, if I go to the new Debian buffer and hit C-x C-w, the
minibuffer says Write file: ~/TeX Live 2009/, which I find rather
curious.
If I comment out the \begin{frame} and \end{frame} lines in test.tex,
then I do get the expected behaviour.
/* era */
--
If this were a real .signature, it would suck less. Well, maybe not.
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#624399: libtextcat: CVS directories in source
Package: libtextcat Version: 2.2-2 Severity: minor X-Debbugs-Cc: era+deb...@iki.fi lucid$ apt-get source libtextcat ... output as expected, getting version 2.2 ... lucid$ cd libtextcat-2.2 lucud$ find . -name CVS -ls 29246614 drwxr-xr-x 2 era era 4096 May 19 2003 ./langclass/ShortTexts/CVS 29245804 drwxr-xr-x 2 era era 4096 May 22 2003 ./langclass/LM/CVS 29245744 drwxr-xr-x 2 era era 4096 May 19 2003 ./langclass/CVS /* era */ -- If this were a real .signature, it would suck less. Well, maybe not. /* era */ -- If this were a real .signature, it would suck less. Well, maybe not. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#611396: emacs: Can't handle utf8 encoded filenames in locale 'de_DE.utf8'
So Sven, do you think this should be considered an upstream bug, a configuration problem, or something else? I'm not Sven, but I could imagine all of these to be feasible steps forward: 1. Perhaps German should be updated to behave according to modern expectations, as vaguely suggested by Sven above 2. Perhaps German needs to be renamed to German (legacy ISO-8859-1) and a new German (UTF8) created to replace it in modern installations instead, if backwards-compatibility is considered paramount 3. Perhaps there really is a file name handling bug in German, irrespective of the other two options above All in all, my instinct would be to chicken out, and forward this upstream for further discussion and improved visibility. /* era */ -- If this were a real .signature, it would suck less. Well, maybe not. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#574947: Licence changed
tags 574947 +patch thanks Also note that debian/copyright should be updated. Global is now licensed under GPLv3. /* era */ -- If this were a real .signature, it would suck less. Well, maybe not. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#600712: Debugging hints
On Thu, 23 Dec 2010 09:19 +0100, Sven Joachim svenj...@gmx.de wrote: It is not very likely that the submitter will reply, since he will most probably not have seen your message. You need to CC him. That seems backwards, but I have forwarded my message to him under separate cover. Thanks for the heads-up. /* era */ -- If this were a real .signature, it would suck less. Well, maybe not. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#600712: Debugging hints
1. Do you get a backtrace in Emacs if you seet (setq debug-on-error t)? (unlikely) 2. If you turn up gnus-verbose and gnus-verbose-backends, do you get useful information? 3. Can you build Emacs with debugging symbols and obtain a stack trace? /* era */ -- If this were a real .signature, it would suck less. Well, maybe not. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#601358: wontfix
Calling /etc/init.d/thttpd displays nothing insteading [of] displaying how to use it. That's not how other init.d scripts work either; the purpose of scripts in /etc/init.d is first and foremost to run automatically. I leave it up to a DD to actually decide on this, but I think I would expect a tags +wontfix on this one. /* era */ -- If this were a real .signature, it would suck less. Well, maybe not. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#599922: dictionaries-common: merge upstream changes to .el files
Package: dictionaries-common Version: 1.5.11 Severity: normal X-Debbugs-Cc: era+deb...@iki.fi Running a diff against ispell.el from emacs23 reveals some upstream changes which should probably be incorporated into the version in dictionaries-common. There are also differences in flyspell.el but they seem by quick glance to be fixes which should perhaps be merged by upstream instead of the other way around. repro$ apt-get install emacs23-el repro$ zcat /usr/share/emacs/23.1/lisp/textmodes/flyspell.el.gz | diff -u - /usr/share/emacs/site-lisp/dictionaries-common/flyspell.el | less repro$ zcat /usr/share/emacs/23.1/lisp/textmodes/ispell.el.gz | diff -u - /usr/share/emacs/site-lisp/dictionaries-common/ispell.el | less I assume that having these files in dictionaries-common is a conscious decision, although having the same files as shipped by Emacs etc seems somewhat confusing and potentially risky. (Witness also https://bugs.launchpad.net/ubuntu/+source/dictionaries-common/+bug/619015 -- a change in emacs23 causes dictionaries-common's flyspell to break. Because of that, I hesitantly set the bug severity to Normal rather than Minor or Wishlist.) /* era */ -- If this were a real .signature, it would suck less. Well, maybe not. -- To UNSUBSCRIBE, email to debian-bugs-dist-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-dist-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-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#598716: psvn.el: Cannot commit changes over Tramp; temp file is local
Package: subversion Version: 1.5.1dfsg1-4 Severity: normal Forwarding an Ubuntu bug to the upstream Debian subversion maintainers: https://bugs.launchpad.net/ubuntu/+source/subversion/+bug/651850 When editing files in a remote SVN work directory, you cannot perform a commit from within Emacs, because one of the temporary files used in the commit is apparently created locally, not on the remote host where the SVN commit command is run. Steps to repro: 1. Edit a file in a remote SVN work directory, e.g. C-x C-f /m...@remote:/tmp/testcheckout/file.txt 2. Make some local changes 3. Run M-x svn-status 4. Mark file.txt to be committed with *; press c to actually commit. Write a short log message in the *svn-log-edit* buffer 5. Attempt to commit with C-c C-c Actual results: The following message is displayed in the minibuffer: svn failed: Can't open file '/tmp/svn.arg.2331QTe': No such file or directory^M Expected results: Committed revision 12345 For debugging, (setq debug-on-error t) doesn't help in this situation, because the SVN error is not an Emacs error; Emacs simply displays the error message from the back end. The function which removes temporary files used by psvn.el is called svn-status-remove-temp-file-maybe; I guess it might be useful to instrument, replace, or advice this function to see what is being removed when. (From comment #2 in the Launchpad bug report, slightly revised): The newest upstream[1] upstream[2] upstream[3] version at http://www.xsteve.at/prg/emacs/psvn.el appears to have fixes related to this in the function svn-log-edit-done I can't seem to access the upstream[3] repo at http://svn.collab.net/repos/svn/trunk/contrib/client-side/emacs -- I get a 403 error. $Id: psvn.el 40299 2009-10-29 19:38:54Z xsteve $ [1] Debian is Ubuntu's upstream for [subversion] [2] [Apache Subversion] is Debian's upstream for [subversion] [3] xsteve.at is [Subversion]'s upstream (From comment #4 in the Launchpad bug report): The latest debian subversion package seems to lack this fix. They mangle the $Id$ tag so it's not clear which upstream version they are shipping. I am the author of the Launchpad bug report, too. /* era */ -- If this were a real .signature, it would suck less. Well, maybe not. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#598716: Forward upstream?
Subversion's contrib/emacs directory also contains an older version. Perhaps this should be forwarded to them. http://svn.apache.org/viewvc/subversion/trunk/contrib/client-side/emacs/psvn.el?view=markuppathrev=915036 /* era */ -- If this were a real .signature, it would suck less. Well, maybe not. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#530961: patch
tags 530961 +patch thanks Attached please find a patch against 1.4.19. I also took the liberty to fix a spelling error in the docstring. The error message is misleading; I wonder why that is. The changed line is 121, not 131. I'm inlining as well as attaching, for your convenience. The patch is quite small, obviously. /* era */ --- emacsen-common-1.4.19/debian-startup.el~2009-05-17 22:38:21.0 + +++ emacsen-common-1.4.19/debian-startup.el 2010-09-14 09:48:58.766324218 + @@ -80,7 +80,7 @@ of the dirs, where XX must be a number. The files will be run in alphabetical order. If a file appears in more than one of the dirs, then the earlier dir takes precedence, and a .elc file always -supercedes a .el file of the same name. +supersedes a .el file of the same name. (let* ((paths dirs) ;; Get a list of all the files in all the specified @@ -118,7 +118,7 @@ ;; Now load the files. load will make sure we get the byte ;; compiled one first, if any, and will respect load-path's ;; ordering. - (mapcar + (mapc (lambda (file) (condition-case err (load file nil) -- If this were a real .signature, it would suck less. Well, maybe not. --- emacsen-common-1.4.19/debian-startup.el~ 2009-05-17 22:38:21.0 + +++ emacsen-common-1.4.19/debian-startup.el 2010-09-14 09:48:58.766324218 + @@ -80,7 +80,7 @@ of the dirs, where XX must be a number. The files will be run in alphabetical order. If a file appears in more than one of the dirs, then the earlier dir takes precedence, and a .elc file always -supercedes a .el file of the same name. +supersedes a .el file of the same name. (let* ((paths dirs) ;; Get a list of all the files in all the specified @@ -118,7 +118,7 @@ ;; Now load the files. load will make sure we get the byte ;; compiled one first, if any, and will respect load-path's ;; ordering. - (mapcar + (mapc (lambda (file) (condition-case err (load file nil)
Bug#595783: debian-installer: en_DK locale missing
Package: debian-installer Severity: normal I have customarily been using en_DK as my default locale because I want my system to speak English to me but units, dates etc to be sane for mainland Europe. Now when I tried to install Debian Testing, I noticed that en_DK is not available as an option during installation. While I fully agree that en_DK is technically whimsical, it has been a good locale to have; none of the en_XX options available in the installer seem to offer the same features (A4 paper size, year-month-date date format, metric units, etc) which are useful for a large part of Europe in multinational organizations which use English as their main language. I installed using the netinst squeeze image from http://www.debian.org/devel/debian-installer/ -rw-r--r-- 1 era era 168742912 2010-02-18 00:19 debian-testing-i386-netinst.iso Once the system was properly installed, the locales package (2.11.2-2) did include en_DK, but it was not available during installation. /* era */ -- If this were a real .signature, it would suck less. Well, maybe not. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#588527: Also found in emacs23
reassign 588527 emacs23 23.1+1-4 thanks Reassigning to emacs23 as emacs-snapshot is not in Debian (any more). /* era */ -- If this were a real .signature, it would suck less. Well, maybe not. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#594514: signature separation anxiety --
On Thu, 26 Aug 2010 20:26 +0100, Barak A. Pearlmutter ba...@cs.nuim.ie wrote: It is also a long-outstanding Usenet convention and documented in RFC 3676, thus not just a matter of taste. It is an abomination. Apparently this 30-year-old convention is news to you, but a Debian Emacs bug report is probably not the right forum for advocacy. If you can convince the upstream Emacs maintainers to change this (I'm sure they would consider a well-written and well-argued patch), you stand a better chance for seeing this fixed. I'm sorry, but I don't imagine Debian would be willing to take a patch for this sort of esoteric preference. For what it's worth, I think I used to be able to work around this at least in Gnus. The hint in the documentation for mail-signature points to writing a simple function to insert your .signature file without the sigdashes. If you would like a copy for your personal needs, I'll see if I can find it. /* era */ -- If this were a real .signature, it would suck less. Well, maybe not. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#581648: (no subject)
after uninstalling all cedet package a long time ago thoses files are still present in the emacs23 site-package They prevent the cedet included in emacs23 to work properly. Looks like cedet-common was still installed. Can you uninstall that if it's still on your system? /* era */ -- If this were a real .signature, it would suck less. Well, maybe not. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#591925: emacs23: Enabling Flyspell mode gave an error
On 2010-08-12 01:25, alexander.savche...@gmail.com wrote: Same problem I am also able to reproduce this on a fresh install. The definition of (define-minor-mode flyspell-mode ...) emits this message in the minibuffer when (flyspell-mode-on) returns a nil result; this is inside a (condition-case ...) so no backtrace or other diagnostics are available. Running M-: (flyspell-mode-on) directly produces the following backtrace: Debugger entered--Lisp error: (error ispell exited with code 255) signal(error (ispell exited with code 255)) error(%s exited with %s %s ispell code 255) ispell-check-version() ispell-init-process() ispell-buffer-local-words() ispell-accept-buffer-local-defs() flyspell-accept-buffer-local-defs(force) flyspell-mode-on() eval((flyspell-mode-on)) eval-expression((flyspell-mode-on) nil) call-interactively(eval-expression nil nil) I am running Ubuntu 10.04 but the Emacs package is essentially the same as in Debian. On the command line, /usr/bin/ispell -v returns a valid string on my system. But ispell -vv -- which is what `ispell.el' uses unless `ispell-program-name' is aspell -- returns an empty string (just a newline) and an invalid exit code; hence, ispell-check-version fails. vnix$ /usr/bin/ispell -v @(#) International Ispell Version 3.1.20 compatible tmispell-voikko 0.7.1 vnix$ echo $? 0 vnix$ ispell -vv vnix$ echo $? 255 (Voikko is a spelling checker for the Finnish language. It seems it was installed system-wide when I installed a Finnish locale, although my system locale is en_DK.utf8 and I don't override it for my personal login.) Reporter and me-toos: what does ispell -vv return on your systems, and which version of ispell is that? (Hint: dpkg -S /usr/bin/ispell.) vnix$ dpkg -S /usr/bin/ispell diversion by tmispell-voikko from: /usr/bin/ispell diversion by tmispell-voikko to: /usr/bin/ispell.real tmispell-voikko: /usr/bin/ispell My suggestion would be for tmispell-voikko to accept -vv but also for ispell.el to be robust with the apparently several different ispell variants which do not support -vv. /* era */ -- If this were my real .signature, it would suck less. Well, maybe not. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#591925: Info received (emacs23: Enabling Flyspell mode gave an error)
On 2010-08-12 12:02, Ryo Furue wrote: Hi, era eriksson said: Reporter and me-toos: what does ispell -vv return on your systems, and which version of ispell is that? (Hint: dpkg -S /usr/bin/ispell.) I don't have ispell installed: $ dpkg -S /usr/bin/ispell dpkg: /usr/bin/ispell not found. $ Flyspell had been working without ispell a short while before (before the update of some packages). I think it was using aspell. I'm not sure if this matters, but I have (setq-default ispell-program-name aspell) in my .emacs . Currently, flyspell doesn't work even with this $ /usr/bin/emacs23 -q \ --eval '(setq-default ispell-program-name aspell)' \ anything.txt The code in ispell.el is special-cased to run aspell -v instead of ispell -vv if your `ispell-program-name' is aspell. So the question in this case is, which aspell do you have (so dpkg -S /usr/bin/aspell and then dpkg -l aspell or replace aspell with whichever package provides it -- dpkg -l packagename) and what does it produce (output and exit code) when you run aspell -v? /* era */ -- If this were my real .signature, it would suck less. Well, maybe not. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#498898: mk-build-deps is in devscripts, not in equivs
reassign 498898 devscripts thanks mk-build-deps is a devscripts script, not part of equivs. /* era */ -- If this were a real .signature, it would suck less. Well, maybe not. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#583106: tags 583106 +patch
tags 583106 +patch thanks The Fedora ticket has a nice set of patches. /* era */ -- If this were a real .signature, it would suck less. Well, maybe not. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#580198: Segfault on opening an Org file
On Tue, 04 May 2010 10:18 +0200, Julien Danjou a...@debian.org wrote: My emacs segfault badly when opening an Org file. Note that it works fine with -Q option, so there's something it does not like in my configuration, I guess. Could you attach your .emacs file, and/or isolate what in your configuration it is that Emacs doesn't like? Ubuntu has a vaguely similar bug which is related to linum.el and fonts: https://bugs.launchpad.net/ubuntu/+source/emacs-snapshot/+bug/207560 /* era */ -- If this were a real .signature, it would suck less. Well, maybe not. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#561181: Raise severity
severity 561181 important thanks It seems that this bug is preventing a dist-upgrade of emacs. I'm taking the liberty to raise the severity to important. Please see further Ubuntu bug https://bugs.launchpad.net/ubuntu/+source/sepia/+bug/560428 and also the proposed patch in https://bugs.launchpad.net/ubuntu/+source/sepia/+bug/254757 /* era */ -- If this were a real .signature, it would suck less. Well, maybe not. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#571638: Patch against 2.0.8
tags 571638 patch thanks Here's a patch against 2.0.8. I noticed that Conflicts is missing from template.ctl so I added that too. /* era */ -- If this were a real .signature, it would suck less. Well, maybe not. diff -urNad equivs-2.0.8.orig/usr/bin/equivs-build equivs-2.0.8/usr/bin/equivs-build --- equivs-2.0.8.orig/usr/bin/equivs-build 2010-01-20 06:24:03.0 +0200 +++ equivs-2.0.8/usr/bin/equivs-build 2010-03-17 15:02:42.0 +0200 @@ -305,6 +305,7 @@ Recommends, Suggests, Conflicts, + Breaks, Provides, Replaces, Description); @@ -351,6 +352,7 @@ Recommends, Suggests, Conflicts, + Breaks, Provides, Replaces); $deps ||= ; diff -urNad equivs-2.0.8.orig/usr/share/equivs/template.ctl equivs-2.0.8/usr/share/equivs/template.ctl --- equivs-2.0.8.orig/usr/share/equivs/template.ctl 2010-01-20 03:48:32.0 +0200 +++ equivs-2.0.8/usr/share/equivs/template.ctl 2010-03-17 15:02:42.0 +0200 @@ -14,6 +14,8 @@ # Suggests: comma-separated list of packages # Provides: comma-separated list of packages # Replaces: comma-separated list of packages +# Conflicts: comma-separated list of packages +# Breaks: comma-separated list of packages # Architecture: all # Copyright: copyright file; defaults to GPL2 # Changelog: changelog file; defaults to a generic changelog
Bug#119888: Sources....
On Thu, 11 Mar 2010 21:42:31 +0100, Xan wrote: In official changelog http://www.acme.com/software/thttpd/#releasenotes there is no notice about it. Where is the source of this change? The patch you yourself supplied is included in the Debian source package as debian/patches/10-x-forwarded-for-header.dpatch (with very minor modifications; and alas, with no description. It should probably be fixed to indicate the origins of the patch and a pointer to this bug). It is unclear to me how this is supposed to fix the problem which this bug report was originally about, though. How does this help POST content get through? (Please be gentle; I might be ignorant of something obvious.) The Changelog says X-Forwarded-Via while the patch has X-Forwarded-For: -- I presume the latter is correct, also as per http://en.wikipedia.org/wiki/X-Forwarded-For, and that the Changelog should be corrected. But again, it seems doubtful to me how this helps solve bug #119888 which is about correctly receiving POST content. (The comment by Nikita Borisov from 2003 alleges that this POST problem was fixed in 2.22 although there is no explicit mention of this in the upstream changelog, either.) /* era */ -- If this were a real .signature, it would suck less. Well, maybe not. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#557804: vm: does not conform to RFC 822 skipping
Bug reassigned from package 'vm' to 'emacs23'. The request in the bug report to supply a sample with which this can be reproduced is still topical. Apparently a file error.txt was communicated in private (?) but it is not attached to the bug report. Manoj or Brian, could you please attach it there? Also, minimal repro steps would be appreciated. Thanks in advance! /* era */ -- If this were a real .signature, it would suck less. Well, maybe not. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#126608: state of #126608
On Thu, 22 Oct 2009 18:20 +0300, Eugene V. Lyubimkin jackyf.de...@gmail.com wrote: Hello era, I agree with explanation given by Kalle that the current situation is not a bug, so I'm about to close it. Do you have objections? I like Kalle's suggestion that local $1 should happen automatically, and would prefer if that could be added as an upstream RFE or whatever they call it. I don't feel qualified to argue with upstream about this so would appreciate if Kalle or yourself could volunteer to bring this suggestion upstream. Whether this Debian bug is closed or not is more or less immaterial but I would not like to lose Kalle's suggestion. /* era */ -- If this were a real .signature, it would suck less. Well, maybe not. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#541348: cweb.el: deliberately breaks Emacs
tag 541348 +patch thanks On Fri, 04 Sep 2009 09:25 -0400, Peter S Galbraith p...@debian.org wrote: era eriksson e...@iki.fi wrote: On Wed, 02 Sep 2009 17:01 -0400, Peter S Galbraith p...@debian.org wrote: The autogenerated file emacs-goodies-loaddefs.el has not contained autoloads for cwebm for many versions of emacs-goodies-el now. My bad, seems Ubuntu still has version 29.4 which is arguably not entirely fresh. However, the only mention of cwebm I see in the Changelog is when you initially zapped it in version 28. Do you think the Changelog should mention when the problem was fixed? I don't really know when it was fixed, but it could be figured out from CVS checkins. I guess I had forgotten to generate a new autoloads file when I stripped out the cwebm.el file. https://alioth.debian.org/scm/viewvc.php/emacs-goodies-el/elisp/emacs-goodies-el/emacs-goodies-loaddefs.el?root=pkg-goodies-elr1=1.37r2=1.38 shows that the autoloads were regenerated to remove cwebm.el (and a swath of other stuff as well) ostensibly to fix just bug #509486 (integration of quack.el) which was closed in 30.0-1. Attached please find a patch against the current CVS HEAD (sorry if it's clumsy, hadn't used CVS for several years). /* era */ -- If this were a real .signature, it would suck less. Well, maybe not. Index: debian/changelog === RCS file: /cvsroot/pkg-goodies-el/emacs-goodies-el/debian/changelog,v retrieving revision 1.435 diff -u -r1.435 changelog --- debian/changelog 4 Sep 2009 02:46:35 - 1.435 +++ debian/changelog 5 Sep 2009 21:22:26 - @@ -1,6 +1,7 @@ emacs-goodies-el (30.6-1) UNRELEASED; urgency=low * emacs-goodies-el: + - cwebm.el: Stub file removed (was replaced with stub in 28.0-1) - dirvars.el: Updated to 1.3 (by Benjamin Rutt) - folding.el: Updated to 2009.0220.1404 - highlight-completion.el: Updated to 0.08 @@ -98,6 +99,7 @@ * emacs-goodies-el: - pod-mode.el: updated to V0.502, thanks to Kevin Ryde (Closes: #499473). +- emacs-goodies-loaddefs.el: rebuilt to remove old cruft New file: - quack.el: Added file (version 0.34), integration contributed by Daniel Moerner dmoer...@gmail.com, (Closes: #509486) Index: debian/control === RCS file: /cvsroot/pkg-goodies-el/emacs-goodies-el/debian/control,v retrieving revision 1.81 diff -u -r1.81 control --- debian/control 2 Sep 2009 20:56:27 - 1.81 +++ debian/control 5 Sep 2009 21:22:26 - @@ -32,7 +32,6 @@ ctypes - enhanced Font lock support for custom defined types; cua - emulate CUA key bindings (C-z undo, C-x cut, C-c copy, C-v paste); cyclebuffer - select buffer by cycling through; - cwebm - a modified CWEB/WEB modified mode; dedicated - make a window dedicated to a single buffer; df - display in the mode line space left on devices; dict - wrapper around the 'dict' command. (Depends on bash and dict) Index: elisp/emacs-goodies-el/cwebm.el === RCS file: /cvsroot/pkg-goodies-el/emacs-goodies-el/elisp/emacs-goodies-el/cwebm.el,v retrieving revision 1.5 diff -u -r1.5 cwebm.el --- elisp/emacs-goodies-el/cwebm.el 25 Sep 2007 00:02:52 - 1.5 +++ elisp/emacs-goodies-el/cwebm.el 5 Sep 2009 21:22:26 - @@ -1,33 +0,0 @@ -;;; cwebm.el --- CWEB/WEB modified mode -;; -;; This file is replacement for the cweb.el from the Levi' CWEB. -;; -;; Copyright (C) 1987,1990,1993,2000 Silvio Levy and Donald E. Knuth -;; Copyright (c) 2002,2003,2004,2005 Max Vasin -;; -;; Permission is granted to make and distribute verbatim copies of -;; this document provided that the copyright notice and this -;; permission notice are preserved on all copies. -;; -;; Permission is granted to copy and distribute modified versions of -;; this document under the conditions for verbatim copying, provided -;; that the entire resulting derived work is given a different name -;; and distributed under the terms of a permission notice identical to -;; this one. - -;;- -;; Important note: -;; -;; I have removed the contents of this file at the request of the FSF -;; while the FSF try to get it licensed compatibly with Emacs, which the -;; FSF believes it modifies. If it doesn't get sorted out, I will remove -;; the file completely. If it does get sorted out, I'll replace this with -;; the new version. -;; -;; Peter S Galbraith p...@debian.org -;; 2007-09-24 -;;- - -(provide 'cwebm) - -;;; cwebm.el ends here
Bug#541348: cweb.el: deliberately breaks Emacs
reopen 541348 retitle 541348 cwebm still included in package description thanks On Wed, 02 Sep 2009 17:01 -0400, Peter S Galbraith p...@debian.org wrote: The autogenerated file emacs-goodies-loaddefs.el has not contained autoloads for cwebm for many versions of emacs-goodies-el now. My bad, seems Ubuntu still has version 29.4 which is arguably not entirely fresh. However, the only mention of cwebm I see in the Changelog is when you initially zapped it in version 28. Do you think the Changelog should mention when the problem was fixed? Also, the package description still lists cwebm as an add-on included in this package. If it's not actually included, perhaps it should not be in the package description (whether you actually remove the stub file or not)? (Now I finally notice that it says modified twice, but if you remove the description, you'll fix that too :-) /* era */ -- If this were a real .signature, it would suck less. Well, maybe not. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#476109: Not really an Emacs issue
This is not really appropriate for Emacs. Installing Emacs should not force users of other editors to receive a system-wide policy to use Emacs for editing these types of files (however sympathetic I am to evangelizing those poor heathens. :-) The idea as such has some merit. Debian already provides a facility for generic redirection to the user's preferred editor, so this suggestion could be implemented with /usr/bin/editor instead of emacsclient (this also solves the issue of allowing users to prefer emacs over emacsclient). However, it is unobvious to me which package to reassign this bug to. mime-support contains the tool for updating /etc/mailcap so that's what I would suggest, but I leave it to more competent people to possibly find a better route to take this. /* era */ -- If this were a real .signature, it would suck less. Well, maybe not. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#476109: Not really an Emacs issue
On Wed, 02 Sep 2009 09:35 +0200, Sven Joachim svenj...@gmx.de wrote: On 2009-09-02 08:36 +0200, era eriksson wrote: The idea as such has some merit. Debian already provides a facility for generic redirection to the user's preferred editor, so this suggestion could be implemented with /usr/bin/editor instead of emacsclient (this also solves the issue of allowing users to prefer emacs over emacsclient). With /usr/bin/sensible-editor rather than /usr/bin/editor, so that users get their preferred editor instead of the system one. Yes, sorry, that's of course the one I meant. Shrug. The big problem is that the editor may need a terminal to work, and if it gets invoked by a GUI program, nothing happens, aside from a complaint by the editor in ~/.xsession-errors that is invisible to the user. Should there be a sensible-gui-editor as well? Perhaps a wrapper which starts the sensible-editor in an xterm if it's not graphical in its own right? /* era */ -- If this were a real .signature, it would suck less. Well, maybe not. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#541344: Attribution for #476624
Package: cryptsetup Version: 2:1.0.7-1 Severity: wishlist X-Debbugs-Cc: era+deb...@iki.fi I'm wondering if it would be out of the question to credit me in the changelog for the typo fixes in #476624 -- my bug report https://bugs.launchpad.net/bugs/164181 enumerated the typos and proposed fixes. I guess Bruno forgot to include information about the Ubuntu bug when he forwarded the patch to Debian. /* era */ -- If this were a real .signature, it would suck less. Well, maybe not. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#541348: cweb.el: deliberately breaks Emacs
Package: emacs-goodies-el Version: 29.4-1 X-Debbugs-Cc: era+deb...@iki.fi This report is essentially a forward of Ubuntu bug #381188 https://bugs.launchpad.net/bugs/391188 cwebm-mode is not functional in emacs-goodies-el, and should be disabled or excluded. Attempts to edit files with a .w extension result in File mode specification error. The entire contents of the file /usr/share/emacs22/site-lisp/emacs-goodies-el/cwebm.el is a long comment, with the following highlight: ;; Important note: ;; ;; I have removed the contents of this file at the request of the FSF ;; while the FSF try to get it licensed compatibly with Emacs, which the ;; FSF believes it modifies. If it doesn't get sorted out, I will remove ;; the file completely. If it does get sorted out, I'll replace this with ;; the new version. https://alioth.debian.org/scm/viewvc.php/emacs-goodies-el/elisp/emacs-goodies-el/cwebm.el?view=markuprevision=HEADroot=pkg-goodies-el The generated file emacs-goodies-loaddefs.el should not contain the autoloads for cwebm until this is fixed (or perhaps cwebm should simply be removed from the package). /* era */ -- If this were a real .signature, it would suck less. Well, maybe not. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#448524: reopen, fix too broad
reopen 448524
tags 448524 +patch
thanks
The fix in 2.25b-5 is unfortunately too broad.
As pointed out in the follow-up from Patricio Silva, the fix fails to
anchor the regular expression properly (and besides, the Useless Use of
grep | grep is convoluted).
PID=`cat $PIDFILE`
if ps ax | awk '{print $1}' | grep -q ^${PID}$; then
This can be simplified as follows:
if ps ax | grep -q ^ *$(cat $PIDFILE) ; then
As a further comment on style, awk | grep can almost always be massaged
into a single awk invocation (but I don't think awk is necessary here,
and so the details are left as an exercise for the interested reader).
patch
Description: Binary data
Bug#448524: Sorry, bad patch
Ouch, I was too quick -- apologies. The patch I attached to the previous message did not properly implement the fix I described. Here's another attempt. patch Description: Binary data
Bug#540621: Fwd: thttpd override disparity
Package: thttpd Version: 2.25b-7 Severity: minor X-Debbugs-Cc: era+debb...@iki.fi See forwarded message from archive administrator. thttpd_2.25b-7_i386.deb: package says section is web, override says httpd. ---BeginMessage--- There are disparities between your recently accepted upload and the override file for the following file(s): thttpd_2.25b-7_i386.deb: package says section is web, override says httpd. Please note that a list of new sections were recently added to the archive: cli-mono, database, debug, fonts, gnu-r, gnustep, haskell, httpd, java, kernel, lisp, localization, ocaml, php, ruby, vcs, video, xfce, zope. At this time a script was used to reclassify packages into these sections. If this is the case, please only reply to this email if the new section is inappropriate, otherwise please update your package at the next upload. Either the package or the override file is incorrect. If you think the override is correct and the package wrong please fix the package so that this disparity is fixed in the next upload. If you feel the override is incorrect then please file a bug against ftp.debian.org and explain why. Please INCLUDE the list of packages as seen above, or we won't be able to deal with your request due to missing information. Please make sure that the subject of the bug you file follows the following format: Subject: override: BINARY1:section/priority, [...], BINARYX:section/priority Include the justification for the change in the body of the mail please. [NB: this is an automatically generated mail; if you already filed a bug and have not received a response yet, please ignore this mail. Your bug needs to be processed by a human and will be in due course, but until then the installer will send these automated mails; sorry.] -- Debian distribution maintenance software (This message was generated automatically; if you believe that there is a problem with it please contact the archive administrators by mailing ftpmas...@debian.org) ---End Message---
Bug#494673: clarification of proposed dlocate README?
On Sun, 24 May 2009 16:14 +0200, Tomas Pospisek tpo_...@sourcepole.ch wrote: Could this later point be made clear in the README? i really don't know how it could be said any clearer. I suggest actually putting that information somewhere into the package as for example into the README.Debian. And could the README be included in the dlocate package please? I'm thinking it could spare the world a few dozen kilo joule of electricity over all? what README? There is a README.Debian in the dlocate package. I'm guessing maybe Craig is missing the fact that this is a follow-up to a bug report of mine which suggests to add a README about this issue http://bugs.debian.org/494673 I have absolutely no objection to folding this information into README.Debian if you prefer; I was thinking a specific README with a name alluding to mlocate and slocate would be easier to find (harder to ignore :-) than the generic README.Debian but that's Craig's call, obviously. dlocate will install locate by dependency and locate will by default start automatically trashing the disk each day. Thus in my opinion dlocate should warn the user of this. I'd suggest putting a line into dlocate's manpage referring to the README.Debian and explain things there. Additionally I'd suggest to test in the dlocate.postinst whether either two of locate and mlocate or slocate are installed and tell the user that he probably wants to disable the locate updatedb run through the /etc/updatedb.findutils.cron.local mechanism. In my opinion this is slightly problematic -- dlocate's install script cannot know whether locate was installed explicitly by the user (well, I suppose this information is available if you use aptitude, but not on a plain apt-get/dpkg base system) or pulled in as a dependency. The proper solution I guess would be for locate to be split into a locate-common package containing the tools, keeping only the configuration data in locate proper, but that sounds like severe overkill. Many people do complain about unwanted locate runs so perhaps there should be a bug about this against locate (sorry, too much in the middle of something else to check right away whether there is one already). /* era */ -- If this were a real .signature, it would suck less. Well, maybe not. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#494673: clarification of proposed dlocate README?
On Tue, 26 May 2009 22:10 +0300, era eriksson e...@iki.fi wrote: In my opinion this is slightly problematic -- dlocate's install script cannot know whether locate was installed explicitly by the user (well, I suppose this information is available if you use aptitude, but not on a plain apt-get/dpkg base system) or pulled in as a dependency. The proper solution I guess would be for locate to be split into a locate-common package containing the tools, keeping only the configuration data in locate proper, but that sounds like severe overkill. Many people do complain about unwanted locate runs so perhaps there should be a bug about this against locate (sorry, too much in the middle of something else to check right away whether there is one already). Incidentally, note also that slocate is no longer available (bug #457565). I suppose mlocate could check upon install whether locate is installed, and offer to disable or override its cron job (unsure whether it does this at the mo?) but that doesn't help in the scenario when mlocate is already installed and locate is pulled in as a dependency of dlocate. This is another scenario where a modular locate package could help. Then mlocate could Conflicts: locate and dlocate could Depends: locate-common without pulling in the potentially obnoxious cron job. Anyhow, this discussion is IMHO outside the scope of any bug of dlocate's. There is a bug #522143 against locate which is vaguely tangential to this discussion. Perhaps we should propose the break-up into locate-common and locate as a separate bug report? /* era */ -- If this were a real .signature, it would suck less. Well, maybe not. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#521859: python-kerberos: please include kerberos.py
Package: python-kerberos Version: 1.1-3 Severity: minor Tags: patch X-Debbugs-Cc: era+deb...@iki.fi The README says: === Python APIs === See kerberos.py. However, kerberos.py is not included in the package. If you don't want to include it in the package, perhaps the README could say that you need to download the pykerberos source package. /* era */ -- If this were a real .signature, it would suck less. Well, maybe not. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#520276: Fwd: python-kerberos: typo in package description
On Wed, 18 Mar 2009 16:47 +0200, era eriksson e...@iki.fi wrote: Package: python-kerberos Version: 1.1-3 Severity: minor Tags: patch X-Debbugs-Cc: era+...@iki.fi s/Appache/Apache Also what's with the dot between Kerberos and framework? The same typos are also in the README file. Perhaps that should be edited as well (and rewrapped for good measure). /* era */ -- If this were a real .signature, it would suck less. Well, maybe not. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#520276: Fwd: python-kerberos: typo in package description
On Mon, 23 Mar 2009 08:25:42 +0100, Guido Günther a...@sigxcpu.org said: Also what's with the dot between Kerberos and framework? The whole kerberos framework refers to the complete API (see e.g. man krb5). Just to make sure we communicate properly: I understand what the phrase Kerberos framework means, I was wondering if the very similar phrase Kerberos.framework in the package description (with a dot instead of a space between the words) is a spelling mistake or if it is intentional, and perhaps refers to something else. If you already caught this, excellent. Just want to make sure we are on the same page. /* era */ -- If this were a real .signature, it would suck less. Well, maybe not. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#520276: Fwd: python-kerberos: typo in package description
Package: python-kerberos Version: 1.1-3 Severity: minor Tags: patch X-Debbugs-Cc: era+...@iki.fi s/Appache/Apache Also what's with the dot between Kerberos and framework? -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#513470: dlocate: fix lintian warnings [patch]
Package: dlocate
Version: 0.96.1
Tags: patch
X-Debbugs-Cc: era+deb...@iki.fi
Please find attached a patch which attempts to fix the errors and
warnings generated by lintian, as available e.g. here:
http://lintian.debian.org/maintainer/c...@taz.net.au.html#dlocate
I have not tried to fix the Debian-Policy version warning, although that
too should hopefully be trivial.
There is one actual lintian error (should not declare a dependency on
awk after all) and about half a dozen warnings.
/* era */
--
If this were a real .signature, it would suck less. Well, maybe not.
diff -burNad dlocate-upstream-0.96.1/debian/changelog dlocate-lintian-0.96.1/debian/changelog
--- dlocate-upstream-0.96.1/debian/changelog 2009-01-27 09:19:49.0 +0200
+++ dlocate-lintian-0.96.1/debian/changelog 2009-01-29 11:50:04.0 +0200
@@ -1,6 +1,20 @@
+dlocate (0.96.1-0.1) unstable; urgency=low
+
+ * debian/control: revert dependency on awk; as per Lintian error,
+it is in practice essential, and should not be declared
+ * debian/copyright: add copyright year; disambiguate license as GPL v2
+(fix lintian warning)
+ * debian/rules: move binary-arch commands to binary-indep; do not ignore
+errors from make clean (fix lintian warnings)
+ * debian/changelog: fix typo in 0.96.1 s/dancy/dency/ (fix lintian warning)
+ * debian/postinst: don't use explicit path for /usr/sbin (fix lintian warning)
+ * debian/postrm: add -e flag (fix lintian warning)
+
+ -- era eriksson era+deb...@iki.fi Mon, 26 Jan 2009 19:58:57 +0200
+
dlocate (0.96.1) unstable; urgency=low
- * version 0.95 introduced a dependancy on awk, which is an optional
+ * version 0.95 introduced a dependency on awk, which is an optional
package. the simple awk script has only been tested on my system
with gawk, but it doesn't do anything gawkish so should work with
mawk or original-awk. fixed Depends line.
diff -burNad dlocate-upstream-0.96.1/debian/control dlocate-lintian-0.96.1/debian/control
--- dlocate-upstream-0.96.1/debian/control 2009-01-27 09:19:49.0 +0200
+++ dlocate-lintian-0.96.1/debian/control 2009-01-29 11:50:04.0 +0200
@@ -7,7 +7,7 @@
Package: dlocate
Architecture: all
-Depends: awk, dctrl-tools | grep-dctrl (= 0.11), dpkg (= 1.8.0), locate | findutils ( 4.2.31-2), ${perl:Depends}
+Depends: dctrl-tools | grep-dctrl (= 0.11), dpkg (= 1.8.0), locate | findutils ( 4.2.31-2), ${perl:Depends}
Description: fast alternative to dpkg -L and dpkg -S
Uses GNU locate to greatly speed up finding out which package a file
belongs to (i.e. a very fast dpkg -S). Many other uses, including
diff -burNad dlocate-upstream-0.96.1/debian/copyright dlocate-lintian-0.96.1/debian/copyright
--- dlocate-upstream-0.96.1/debian/copyright 2009-01-27 09:19:49.0 +0200
+++ dlocate-lintian-0.96.1/debian/copyright 2009-01-29 11:50:04.0 +0200
@@ -12,7 +12,10 @@
Copyright:
+Copyright (C) 1999 Jim Pick j...@jimpick.com, Craig Sanders c...@taz.net.au
+Copyright (C) 2007, 2008 Craig Sanders c...@taz.net.au
+
original script by Jim Pick j...@jimpick.com, GPL'd of course
-see /usr/share/common-licenses/GPL for details
+see /usr/share/common-licenses/GPL-2 for details
diff -burNad dlocate-upstream-0.96.1/debian/postinst dlocate-lintian-0.96.1/debian/postinst
--- dlocate-upstream-0.96.1/debian/postinst 2009-01-27 09:19:49.0 +0200
+++ dlocate-lintian-0.96.1/debian/postinst 2009-01-29 11:50:04.0 +0200
@@ -25,7 +25,7 @@
case $1 in
configure)
# generate initial dlocate database
- /usr/sbin/update-dlocatedb /dev/null 21
+ update-dlocatedb /dev/null 21
# generate initial 'dpkg -l' file
dpkg -l * | sed -e '1,5d' -e 's/ */ /g' -e 's/ /\t/' -e 's/ /\t/' -e 's/ /\t/' /var/lib/dlocate/dpkg-list
diff -burNad dlocate-upstream-0.96.1/debian/postrm dlocate-lintian-0.96.1/debian/postrm
--- dlocate-upstream-0.96.1/debian/postrm 2009-01-27 09:19:49.0 +0200
+++ dlocate-lintian-0.96.1/debian/postrm 2009-01-29 11:50:04.0 +0200
@@ -1,4 +1,4 @@
-#!/bin/sh
+#!/bin/sh -e
if [ $1 = purge ]; then
rm -f /var/lib/dlocate/*
rmdir /var/lib/dlocate/
diff -burNad dlocate-upstream-0.96.1/debian/rules dlocate-lintian-0.96.1/debian/rules
--- dlocate-upstream-0.96.1/debian/rules 2009-01-27 09:19:49.0 +0200
+++ dlocate-lintian-0.96.1/debian/rules 2009-01-29 11:50:04.0 +0200
@@ -13,7 +13,7 @@
dh_testdir
dh_testroot
rm -f build-stamp install-stamp
- -$(MAKE) clean
+ $(MAKE) clean
dh_clean
install: install-stamp
@@ -27,10 +27,6 @@
# Build architecture-independent files here.
binary-indep: build install
-# We have nothing to do by default.
-
-# Build architecture-dependent files here.
-binary-arch: build install
dh_testdir
dh_testroot
# dh_installdebconf
@@ -59,6 +55,10 @@
dh_md5sums
dh_builddeb
+# Build architecture-dependent files here.
+binary-arch: build install
+# We have nothing to do by definition (arch is indep
Bug#466662: Revised patch
Actually the wording which leads in to the example would need to be
changed too. Please find inline an ad-hoc updated patch.
Internally this uses egrep on a file containing the reformatted
-output of #8216;dpkg -l#8217; (four fields separated by one
space-character:
-status, package-name, installed version, description) so it
-will return packages whose tag-line matches, too.
+output of 'dpkg -l' (four fields separated by tabs;
+status, package-name, installed version, short description) so it
+will return packages whose version or short description matches, too.
Extended regular expression are allowed. For example,
-dlocate -l #8217;^.. libc5#8217;
+ht=`echo -e '\011'` # codify horizontal tab
+dlocate -l ^..${ht}libc5
will list all the package names starting with #8216;libc5#8217;.
(Sorry for not downloading the latest sources and creating a proper
patch.)
/* era */
--
If this were a real .signature, it would suck less. Well, maybe not.
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#153824: Should this bug be closed?
If I interpret the final comments correctly, this should be closed as invalid, but I hesitate to do so without checking. Any comments? Submitter, are you still around? /* era */ -- If this were a real .signature, it would suck less. Well, maybe not. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#443930: auctex: Help links to elisp source don't work
LaTeX-mode-hook is a variable defined in `/usr/share/emacs22/site- lisp/auctex/latex.elc'. and if I try to follow the link it doesn't work. Not a surprise, since you need to drop the 22 to get it to work. What I don't understand is why the link is wrong in the first place. Notice the .elc. The byte-compiled files are in a different directory than the source .el files. I'm guessing you don't have the source directory in you `load-path' (but this is a shot from the hip; haven't tested whether this would in fact cause this, or solve it). /* era */ -- If this were a real .signature, it would suck less. Well, maybe not. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#381737: update-grub: Does not like my custom built kernel
retitle 381737 update-grub: incorrect regex discards some kernels thanks for kern in $(/bin/ls -1vr /boot | grep -v dpkg-* | grep -v xen | grep ^vmlinuz-) ; do The quoted shell script snippet is actually incorrect for the dpkg- case, too. I assume what is meant is simply dpkg- but the asterisk will discard any line containing dpkg, without the dash too (in regular expression syntax, the asterisk means zero or more occurrences of the previous regular expression). As a matter of fact, I would suggest to refactor the code into for kern in $(/bin/ls -1vr /boot); do case $kern in *.dpkg-*|*-xen-*) continue;; vmlinuz-*) ;; *) continue ;; esac The *-xen-* wildcard seems to match the file names given to Xen kernels, although I could be mistaken on that. (Unlike grep, the case statement uses shell wildcards, not true regular expressions. The continue statement causes the loop to skip to the next iteration.) /* era */ -- If this were a real .signature, it would suck less. Well, maybe not. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#505997: dlocate: dependencies are too rigid; mlocate should satisfy them
On Mon, 17 Nov 2008 11:37:32 -0500, Norman Ramsey [EMAIL PROTECTED] said: It should be possible for dlocate to depend on mlocate, not just slocate or locate. Or otherwise a bug report should be filed against mlocate. Feel free to submit a bug against mlocate then. As far as dlocate is concerned, see bug #494673. I'll leave it up to the dlocate maintainer to decide whether to close or WONTFIX or simply leave this open as wishlist (suggest the latter, as it might become feasible if and when mlocate starts to provide the necessary infrastructure). /* 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#494651: dlocate: add README about mlocate/slocate compatibility options
Package: dlocate Version: 0.96.1 Severity: wishlist Tags: patch X-Debbugs-Cc: [EMAIL PROTECTED] Following the apparent deluge of bugs against dlocate asking for interoperability with slocate and/or dlocate (#101426, #453952, #454471, #456249, #489262), I would like to second the suggestion in #489262 to add a README to dlocate to explain the issue. Below please find an ad-hoc suggestion for /usr/share/doc/dlocate/README.slocate.mlocate.txt Using dlocate with slocate or mlocate = slocate and mlocate do not provide the frecode tool, which is required by dlocate. Therefore, you cannot use these as a drop-in replacement for the parts of locate which dlocate requires. You can, however, install slocate or mlocate alongside with the original locate, and disable the cron job in locate if you do not want to run it. For more information, please see Debian bug report #454106 /* 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#247974: fix bug description
retitle 247974 unintuitive error message for free-form text input thanks As shown below, the error message is even marginally less useful now, because the input file and line number are no longer indicated. Error handling aside, maybe the instructions in template.ctl could be even more explicit about the required format for continued text fields. Possibly a crude syntax checker for the control file could be devised; that should certainly handle all of #219188, #251673, and #247974. vnix$ cat 247974 Package: libpng Provides: stuff Description: test case for #247974 libpng is a library implementing an interface for reading and writing vnix$ equivs-build 247974.ctl syntax error in control file: libpng is a library implementing an interface for reading and writing -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#251673: fix bug description
retitle 251673 parsechangelog fails if Maintainer: formatted wrong thanks The problem is IMHO real, but it's not necessarily equivs which should be fixed. Perhaps a better solution would be for dpkg-parsechangelog to issue a more candid error message about the nature of the error. /usr/lib/dpkg/parsechangelog/debian line 146 has the regex /^ \-\- (.*) (.*) ((\w+\,\s*)?\...((:datestamp:))/ which seems to imply that /(.*) (.*)/ would be a suitable regex for checking Maintainer: -- but again, proper encapsulation would dictate that this information should not be duplicated in the equivs code. Error handling aside, maybe the instructions in template.ctl could be even more explicit about the required format for this field. Possibly a crude syntax checker for the control file could be devised; that should certainly handle all of #219188, #251673, and #247974. vnix$ cat 251673.changelog j2re1.4 (1.4) unstable; urgency=low * Test case for #251673 -- [EMAIL PROTECTED] Sun, 30 May 2004 08:58:58 +0200 vnix$ dpkg-parsechangelog -l251673.changelog parsechangelog/debian: error: badly formatted trailer line, at file 251673.changelog line 11 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#219188: fix bug description
retitle 219188 unintuitive handling of syntax error in Provides thanks The error message from the back end is now fairly explicit about the nature of the parsing problem, and the build fails; furthermore, the comments in template.ctl now mention that the dependency fields need to be comma-separated. I'm feeling that this is enough to close this bug. I'm leaving the final decision to the package maintainer, though. Possibly a crude syntax checker for the control file could be devised; that should certainly handle all of #219188, #251673, and #247974. vnix$ fgrep comma /usr/share/equivs/template.ctl # Pre-Depends: comma-separated list of packages # Depends: comma-separated list of packages # Recommends: comma-separated list of packages # Suggests: comma-separated list of packages # Provides: comma-separated list of packages # Replaces: comma-separated list of packages # Extra-Files: comma-separated list of additional files for the doc directory vnix$ equivs-build 219188.ctl dh_testdir dh_testroot dh_clean -k dh_testdir dh_testroot dh_installdocs dh_installchangelogs dh_compress dh_fixperms dh_installdeb dh_gencontrol dpkg-gencontrol: warning: can't parse dependency python2.2-twisted python-twisted python2.3-twisted dpkg-gencontrol: error: error occurred while parsing Provides dh_gencontrol: command returned error code 65280 make: *** [binary-arch] Error 1 Error in the build process: exit status 2 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#323648: Attaching equivs-build-multi script
Below please find the `equivs-build-multi' script I use to implement this. It simply parses a control file into individual temporary equivs control files, and invokes equivs-build on each in turn. Note, however, that the license of the attached script is not GPL. I'll be happy to discuss licensing options (dual-licensed BSD/GPL if at all possible, or even changing the license to GPL if that will help get the script included in the equivs package proper) -- but at this point, I'm making the script available under the BSD license so as to save others from reinventing the wheel. Ideally, maybe the current equivs-build could be made into a library and the below script refactored and adopted as the main entry point to the current equivs-build functionality. Having a single script to build equivs files with one or multiple package definitions in them would seem like the best option from a usability point of view. #!/usr/bin/perl # # equivs-build-multi: build multiple packages from a single equivs control file # era Fri Jan 26 23:07:01 2007 # # Depends: # equivs # perl-base (perl, Getopt::Long) # perl-modules (File::Temp) TODO: i18n =head1 NAME equivs-build-multi - build multiple packages from one equivs file =head1 SYNOPSIS Bequivs-build-multi Icontrolfile =head1 DESCRIPTION Bequivs-build-multi is a wrapper for Lequivs-build(1) to build multiple packages from a single input file of package descriptions. The input file is similar to the basic Bequivs file format, with the differences described below. =over 2 =item * The file may contain multiple sections. Empty lines (one or more) are section dividers. =item * The first of these sections is the global section, which defines defaults which will apply to all subsequent sections. It may not contain a BPackage field, nor BDescription; it must contain a BSource field; and it will usually define BStandards-Version, BSection, and BPriority for all packages defined in the file in the subsequent sections. BMaintainer, BArchitecture, BCopyright and BChangelog are also usually global, if they are specified, but Bequivs-build will fill in the required fields with its own defaults if they are missing (do check, though, whether those defaults make sense for you), and optional fields are, well, optional. =item * Each subsequent section is a package section. It is required to have at least the BPackage and BDescription fields, and in practice, it should contain dependencies, too, (BDepends, BSuggests, BRecommends, and/or the BPre- and BBuild- variants of these) in order to be at all meaningful. =back Each package section is merged with the global section into a separate control file for Bequivs-build, as described in more detail in the next paragraph, and Bequivs-build is invoked on that file to actually build that package. The temporary Bequivs-build control file is removed after the build, regardless of whether the build was successful. =for a bit later TODO: make global and package dependency fields additive? The merge algorithm for global and package-specific fields is straightforward: if there is a conflict, the package-specific value wins. In other words, a package section is allowed to override values specified in the global section. However, a warning is generated whenever a global field value is overridden. From a readability and maintainability perspective, it is probably better to avoid overrides, and instead specify the field's value in each package section individually. Each package section results in a temporary control file which is passed to Bequivs-build and then removed after Bequivs-build finishes building it. =head1 OPTIONS Bequivs-build-multi offers the following options: =over 4 =item --quiet | -q Quiet mode. Currently merely disables warnings whenever package sections override global field values. =item --keep | -k Keep the generated Bequivs-build input files. Normally they are removed after they are used. The names of the generated files are printed; they are automatically generated in order to be unique and never overwrite an existing file. =item --generate-only | -g Only generate the Bequivs-build file(s) and exit. Implies the B--keep option. =item --help | -h Print a brief help message and exit. =item --version | -v Print the version number of Bequivs-build-multi and exit. =back =head1 EXAMPLE The following Bequivs-build-multi file will result in two runs of Bequivs-build on two different files. Both will contain the global values, and then one each of the package sections. Source: example-local-equivs Section: misc Priority: optional Standards-Version: 3.5.10 Changelog: changelog Version: 0.01 Architecture: all Maintainer: era eriksson [EMAIL PROTECTED] Copyright: /usr/share/common-licenses/BSD Package: first-example Depends: deborphan, debconf-utils Description: An example which doesn't do anything very useful Well, it pulls in deborphan
Bug#493861: Please remove the mguesser binary from the othar packages instead
The mnogosearch-* packages provide this binary: http://packages.debian.org/search?searchon=contentskeywords=mguessermode=exactfilenamesuite=unstablearch=any Craig, what about putting the binary into one binary debian package instead of three? I would much prefer if that one package were the existing mguesser package, as it's a useful utility in its own right, and I have no desire to install all of mnogosearch just for this functionality. In my experience, out of the language-identification tools available for Debian, mguesser has the best accuracy, by far. If the mnogosearch-* packages require mguesser, make them Depends: mguesser. In actual fact, though, I imagine they will work just fine if you simply change the build script to not build and include mguesser in those packages. Thanks /* 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#219188: Downgrade bogus bug
retitle 219188 equivs: confusing message for syntax error in control file severity 219188 wishlist merge 219188 247974 thanks Because 247974 is IMHO essentially about the same issue, I'm taking the liberty of merging these two. I think it's a fair point that the error message is confusing, if not outright misleading, and I'd even consider raising the severity at least to minor, if not normal. 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#364620: Stopped being a FTBFS
tags 364620 +patch thanks I used to get FTBFS for this bug too, but it appears that it is indeed fixed in recent versions of Perl. Specifically, according to http://www.eyrie.org/~eagle/software/podlators/changes.html, the --release= option is permitted to be empty starting with a version which was created on 2004-05-07. When this was merged into the Perl distribution I don't know, but presumably it happened in 2004 or 2005; in no event later than early 2006. The patch suggested by Davor Ocelic should of course still be applied. -$(date +$$(date ... or near-equivalently +$(shell date /* 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#474730: www.debian.org: cannot link to DSA without knowing year
Package: www.debian.org Version: 20080407 Severity: minor There appears to be no way to link to a DSA page without knowing in which year the DSA was published. Could you please set up a rewrite rule such that http://security.debian.org/dsa/1234-1 links to the right place? This is valuable for people who want to create bookmarklets or wiki links to DSA notices. I would tag this as Severity: wishlist if it wasn't security-related; the usability and convenience standards should be higher for security facilities, and thus I feel a Severity: minor (or higher) is warranted. Thanks for caring. /* 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#474730: www.debian.org: cannot link to DSA without knowing year
On Mon, 7 Apr 2008 15:45:01 +0200, Nico Golde [EMAIL PROTECTED] said: Hi era, * era eriksson [EMAIL PROTECTED] [2008-04-07 15:24]: There appears to be no way to link to a DSA page without knowing in which year the DSA was published. Could you please set up a rewrite rule such that http://security.debian.org/dsa/1234-1 links to the right place? This is valuable for people who want to create bookmarklets or wiki links to DSA notices. I meant to say that I obviously can't dictate how this should be implemented (rewrite rule is just one possibility) or what exactly the yearless URL should be (/dsa/id would seem natural, but maybe you want something else), but I wanted to suggest something concrete just to make the bug report clear. I agree that this would be nice, as a workaround you could use: http://security-tracker.debian.net/tracker/DSA-number until this is fixed. Thanks for this tip! I tried to google a bit but couldn't come up with a good set of search terms. /* 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#471373: mguesser: new upstream version 0.4
Package: mguesser Version: 0.2-5.1 X-Debbugs-Cc: [EMAIL PROTECTED] A new version of mguesser is available at http://www.mnogosearch.org/guesser/ Also perhaps you want to update the upstream maintainer's email address; I have been corresponding with him at bar at (the domain above sans www.); this is also visible in the README file of the latest version. Thanks! /* 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#400462: New version fixes 400462
On Mon, 17 Mar 2008 21:50:55 +0200, I submitted bug #471373: A new version of mguesser is available Incidentally, the new version contains the patch for #400462 in a slightly improved and overhauled form, so closes that bug as well. /* 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#221790: perl: please kick out that annoying locale warning
On Sun, 9 Mar 2008 18:05:42 +1100, Brendan O'Dea [EMAIL PROTECTED] said: On Thu, Mar 06, 2008 at 10:54:55PM +0200, era eriksson wrote: How about adding something like this to /etc/skel/.bash_profile instead of fixing a warning in Perl which is, per se, correct and warranted? case `perl -e 1 21` in *'perl: warning: Setting locale failed'*) echo .bash_profile: unsupported locale\; reverting to LC_ALL=C 2 LC_ALL=C ;; esac Interesting idea, although I wouldn't want to have perl invoked for every shell. Perhaps there could be a separate binary command in the locale package then, or an extension to the locale command (locale -q maybe?) and/or you could simply grep for stuff in /usr/share/i18n/SUPPORTED /* 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#469941: #469941 Swedish localisation has a typo
In http://bugs.debian.org/469941, Holger Levsen [EMAIL PROTECTED] wrote: Puh, because I should have let the bugreporter, who speaks swedish, decide. What I've heard is, that alfabet == alphabet, alfabetet == *the* alphabet and I've decided to go for alfabet, as it's shorter and unspecific. Actually my patch contained the opposite solution, for largely orthogonal reasons. The context is a menu where you can rehearse typing the alphabet or select some other game mode (short or longer words). /* 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#343099: #343099 Example code in Heap::Elem documentation is not valid perl5
In http://bugs.debian.org/343099, Anthony DeRobertis
[EMAIL PROTECTED] wrote:
File: /usr/share/perl5/Heap/Elem.pm
The documentation reads, in part:
sub new {
my $self = shift;
my $class = ref($self) #9474;#9474; $self;
my $self = SUPER::new($class);
# set $self-{key} = $value;
}
But, as explicitly documented in perlobj, that syntax does not work:
Additionally, you are declaring my $self twice, which doesn't work
either. I would also value a bit more verbosity in the description of
how to access an element's value, from the Heap's perspective, and from
the user (or Heap::Elem subclass implementor's) perspective.
Furthermore, on Sat, 16 Dec 2006 11:41:12 -0500, John Macdonald
[EMAIL PROTECTED] wrote:
Thank you for sending this on to me. I'm away from home right
now, it'll be a week or so before I will have the opportunity
to investigate.
Any news on this, or did the week turn out to be an unusually longish
one ...? (-:
/* 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#466452: (no subject)
I'd just like to chime in here. vnix$ darcs pull --dry Enter passphrase for key '/h/c/ling/reriksso/.ssh/id_dsa': ^C Error in subprocess: Interrupt Error in subprocess: Interrupt withSignalsHandled: Interrupted! Exception thrown by an atexit registered action: exception :: SignalHandler.SignalException Exception thrown by an atexit registered action: exception :: SignalHandler.SignalException vnix$ strace darcs pull --dry 2/tmp/darcs.strace Enter passphrase for key '/h/c/ling/reriksso/.ssh/id_dsa': Enter passphrase for key '/h/c/ling/reriksso/.ssh/id_dsa': Enter passphrase for key '/h/c/ling/reriksso/.ssh/id_dsa': Enter passphrase for key '/h/c/ling/reriksso/.ssh/id_dsa': Enter passphrase for key '/h/c/ling/reriksso/.ssh/id_dsa': Enter passphrase for key '/h/c/ling/reriksso/.ssh/id_dsa': Enter passphrase for key '/h/c/ling/reriksso/.ssh/id_dsa': Enter passphrase for key '/h/c/ling/reriksso/.ssh/id_dsa': Enter passphrase for key '/h/c/ling/reriksso/.ssh/id_dsa': Enter passphrase for key '/h/c/ling/reriksso/.ssh/id_dsa': Pulling from [EMAIL PROTECTED]:repo/darcs/whatever... Enter passphrase for key '/h/c/ling/reriksso/.ssh/id_dsa': Enter passphrase for key '/h/c/ling/reriksso/.ssh/id_dsa': Enter passphrase for key '/h/c/ling/reriksso/.ssh/id_dsa': Enter passphrase for key '/h/c/ling/reriksso/.ssh/id_dsa': No remote changes to pull in! vnix$ darcs --version 1.0.9rc1 (release candidate 1) vnix$ uname -a Linux angarak 2.6.18-5-686 #1 SMP Mon Dec 24 16:41:07 UTC 2007 i686 GNU/Linux vnix$ cat /etc/debian_version 4.0 Inspection of the strace file reveals that darcs spawns a good number of ssh and scp processes in order to get the list of available patches and then copy them. The first few invocations are apparently even just to figure out which version of SSH is in use. It would definitely be nice if it could open a single remote shell and then chat with that as long as it wants to, but I don't know how hard that would be to implement. The workaround, of course, for ssh, is to use ssh-add: vnix$ ssh-add Could not open a connection to your authentication agent. vnix$ eval `ssh-agent` Agent pid 28621 vnix$ ssh-add Enter passphrase for /h/c/ling/reriksso/.ssh/id_dsa: Identity added: /h/c/ling/reriksso/.ssh/id_dsa (/h/c/ling/reriksso/.ssh/id_dsa) vnix$ darcs pull --dry Pulling from [EMAIL PROTECTED]:repo/darcs/whatever... No remote changes to pull in! I think this properly belongs upstream, as it is clearly a fairly intimate detail of darcs, and not a packaging problem in Debian. (Perhaps some sort of wrapper could be put in place by Debian as a quick remedy, but the real problem is upstream.) /* 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#221790: perl: please kick out that annoying locale warning
perl: warning: Setting locale failed. perl: warning: Please check that your locale settings: LANGUAGE = (unset), LC_ALL = (unset), LANG = [EMAIL PROTECTED] are supported and installed on your system. How about adding something like this to /etc/skel/.bash_profile instead of fixing a warning in Perl which is, per se, correct and warranted? case `perl -e 1 21` in *'perl: warning: Setting locale failed'*) echo .bash_profile: unsupported locale\; reverting to LC_ALL=C 2 LC_ALL=C ;; esac /* 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#218000: Retitle 218000: Missing dependency between perl and libperl
retitle 218000 Missing dependency between perl and libperl thanks Is this still topical? It looks to me like the dependencies would be correct now, but I don't know since when, and/or what things looked like when this bug was submitted. /* 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]
