Bug#823655: mutt-patched: IMAP folders displayed in the wrong location with sidebar
Package: mutt-patched Version: 1.6.0-1 Severity: important * What led up to the situation? Using the attached example .muttrc (sanitized) reproduces the problem. Opening the example.org mailbox will display the list of subscribed folders below the last mailbox in the sidebar, instead of example.org. The IMAP server used on the remote end is: ii dovecot-imapd 1:2.2.13-12~deb8u1 amd64 Marked important due to: Given there are several folders with the same name in my various accounts, this can lead to a confusion related to which account mails came in for, or lead to mail for urgent accounts being missed. * What exactly did you do (or not do) that was effective (or ineffective)? Tried tweaking the various sidebar options, ran into other already reported bugs (823454, 823142). Tweaking the order of the accounts in the "mailboxes" line appears to make the folders appear in different locations, sometimes in the correct location for a few accounts, but not others. * What was the outcome of this action? No difference. * What outcome did you expect instead? Didn't expect a difference, as those options are unrelated, just tried them to be thorough. -- System Information: Debian Release: stretch/sid APT prefers testing APT policy: (990, 'testing'), (500, 'stable'), (500, 'oldstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.5.3+ (SMP w/4 CPU cores; PREEMPT) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: sysvinit (via /sbin/init) Versions of packages mutt-patched depends on: ii libassuan02.4.2-3 ii libc6 2.22-7 ii libcomerr21.43~WIP.2016.03.15-2 ii libgnutls30 3.4.11-4 ii libgpg-error0 1.22-1 ii libgpgme111.6.0-3 ii libgssapi-krb5-2 1.13.2+dfsg-5 ii libidn11 1.32-3 ii libk5crypto3 1.13.2+dfsg-5 ii libkrb5-3 1.13.2+dfsg-5 ii libncursesw5 6.0+20160319-1 ii libsasl2-22.1.26.dfsg1-15 ii libtinfo5 6.0+20160319-1 ii libtokyocabinet9 1.4.48-10 ii mutt 1.6.0-1 mutt-patched recommends no packages. mutt-patched suggests no packages. -- no debconf information #bind index \Cn next-unread #bind index \Cg pipe egrep '^Subject: ' #set index_format = "%6l %s" set postponed = ~/postponed set folder=~/Maildir set mbox=~/Maildir set mbox_type=Maildir set spoolfile=~/Maildir #set trash=~/Maildir/trash fcc-hook $ +sent set mail_check=60 set timeout=180 set imap_check_subscribed=yes # # == Global -- unchanged across all accounts by default # set abort_nosubject = no set abort_unmodified = no set askbcc = yes set askcc = yes set auto_tag = yes set confirmappend = no set confirmcreate = no set copy = yes set delete_untag = no set dsn_notify = never set edit_headers = yes set editor = /usr/bin/vi set fcc_attach = yes set forward_quote = yes set header = yes set hidden_host = yes set implicit_autoview = no set mark_old = no set move = no set pager = "/usr/bin/less -X" set prompt_after = no set sendmail = "/usr/sbin/sendmail -oem -oi" set strict_threads = yes set tmpdir = ~/.tmp set use_from = yes set user_agent = no # # == Sidebar # set sidebar_width=52 set sidebar_visible=yes set sidebar_delim='|' #set sidebar_indentstr=" " #set sidebar_shortpath=yes #set sidebar_format="%B %* %N" #set sidebar_folderindent=yes #set sidebar_sort=yes #set sidebar_delim_chars = / # Mailboxes listed in sidebar mailboxes "~/Maildir" imaps://us...@imap.gmail.com imaps://us...@imap.gmail.com imaps://example.org imaps://us...@imap.gmail.com imaps://us...@example.com@imap.gmail.com # Sidebar navitation bind index \CP sidebar-prev bind index \CN sidebar-next bind index \CO sidebar-open bind index \CB sidebar-scroll-up bind index \CF sidebar-scroll-down # # == SSL # set ssl_use_sslv3 = no set ssl_use_tlsv1 = yes set ssl_use_tlsv1_1 = yes set ssl_use_tlsv1_2 = yes set ssl_force_tls = yes # == PGP # Legacy format stuff. Don't enable unless absolutely needed. folder-hook . 'set pgp_auto_decode = no' folder-hook . 'set pgp_autoinline = no' # Sort by addx -- trust will be managed externally folder-hook . 'set pgp_sort_keys = address' # # == IMAP stuff # # NOTE # Password chars that need to be escaped: $\;`"# # Password char that can't be escaped and has to be avoided: ' # -- Local system # Always have account hooks for these! account-hook . 'unset imap_user' account-hook . 'unset imap_pass' account-hook . 'unset smtp_pass' account-hook . 'unset smtp_authenticators' account-hook . 'unset ssl_client_cert' # PGP -- This changes per-account (with a folder hook) folder-hook . 'unset pgp_sign_as' folder-hook . 'set from = "foo "' folder-hook . 'set smtp_url=smtp://localhost:587' folder-hook . 'set folder=~/Maildir' folder-hook . 'set postponed=~/Maildir/postponed' folder-hook . 'set record=~/Maildir/r
Bug#460399: similar error in password-gorilla
I also get a similar error, with a backtrace that looks like it's in the same area of code: Error: unmatched open quote in list unmatched open quote in list unmatched open quote in list while executing "lappend ::gorilla::collectedTicks [clock clicks]" (procedure "::gorilla::CollectTicks" line 2) invoked from within "::gorilla::CollectTicks" (command bound to event) I'm not sure how to trigger it, but if I repeatedly launch, unlock the database, and quit, the bug will trigger about once in every 5~6 times. I'm seeing it in 1.4-4.1. If there's any additional information that can help with tracking it down, let me know. -- DN Daniel -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#578038: ircd-ircu fails to start, MAXCONNECTIONS too large
Package: ircd-ircu
Version: 2.10.12.10.dfsg1-1
ircd-ircu in the apt repository appears to have been compiled with a value
for MAXCONNECTIONS that's larger than what the default Debian configuration
will allow:
Processing triggers for man-db ...
Setting up ircd-ircu (2.10.12.10.dfsg1-1) ...
Starting irc server daemon: ircd-ircuircd fd table too big
Hard Limit: 1024 IRC max: 1048572
set MAXCONNECTIONS to a smaller value.
It looks like MAXCONNECTIONS can only be set during compile-time.
>From irc/s_bsd.c:
int init_connection_limits(void)
{
int limit = os_set_fdlimit(MAXCONNECTIONS);
if (0 == limit)
return 1;
if (limit < 0) {
fprintf(stderr, "error setting max fd's to %d\n", limit);
}
else if (limit > 0) {
fprintf(stderr, "ircd fd table too big\nHard Limit: %d IRC max: %d\n",
limit, MAXCONNECTIONS);
fprintf(stderr, "set MAXCONNECTIONS to a smaller value");
}
return 0;
}
Then from ircd/os_generic.c:
int os_set_fdlimit(unsigned int max_descriptors)
{
#if defined(HAVE_SETRLIMIT) && defined(RLIMIT_FD_MAX)
struct rlimit limit;
if (!getrlimit(RLIMIT_FD_MAX, &limit)) {
if (limit.rlim_max < max_descriptors)
return limit.rlim_max;
limit.rlim_cur = limit.rlim_max;/* make soft limit the max */
return setrlimit(RLIMIT_FD_MAX, &limit);
}
#endif /* defined(HAVE_SETRLIMIT) && defined(RLIMIT_FD_MAX) */
return 0;
}
When rebuilding from source via debuild, the value for MAXCONNECTIONS gets
set to 1020 on all systems I have access to.
Also tried setting the ulimit to 1048572 in the init script via:
ulimit -H -n 1048572
However that causes the system to lag horribly while ircd starts up, apparetly
eating a ton of memory, then it exits. The tail end of the 74MiB output from
strace -f /etc/init.d/ircd-ircu start is:
bind(6, {sa_family=AF_INET, sin_port=htons(6667),
sin_addr=inet_addr("0.0.0.0")}, 16) = 0
listen(6, 128) = 0
bind(8, {sa_family=AF_INET6, sin6_port=htons(7007), inet_pton(AF_INET6, "::",
&sin6_addr), sin6_flowinfo=0, sin6_scope_id=0}, 28) = 0
epoll_ctl(0, EPOLL_CTL_ADD, 8, {EPOLLIN, {u32=8199648, u64=8199648}}) = 0
write(2, "MAXCLIENTS (or MAXCONNECTIONS) is"..., 92) = 92
exit_group(-1) = ?
Process 12438 detached
So it appears to start up, starts listening to the network, then exits.
The system is Debian/lenny on amd64.
-- DN
Daniel
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#533386: new evolution-data-server packages
Hi, > So I had another look at the issue. Indeed, set_nss_error was undefined, so I > used a different function. Also, I think there was another regression with > displaying signed and encrypted S/MIME messages. Could you please test these > updated packages[0] in your environments and tell me, whether they fix the > regressions you encountered? I just installed it on the affected system, and I can fire up Evolution and view S/MIME encrypted messages without crashing now. I did a few other tests to make sure the tasks I regularly perform still work -- and they do. These packages solve the issue for me. > Sorry for all the delay with this, I was waiting for a reply from another > user, but never got it and then this issue kind of slipped through. :( No worries, thank-you for getting the bug fixed. Anything to keep me from having to use Outlook. :-) Cheers, -- DN Daniel -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#533386: Unable to find set_nss_error symbol
Package: libcamel1.2-11 Version: 2.22.3-1.1+lenny1 Severity: grave -- System Information: Debian Release: 5.0.1 APT prefers stable APT policy: (990, 'stable'), (500, 'oldstable') Architecture: i386 (i686) Kernel: Linux 2.6.29.4 (SMP w/2 CPU cores; PREEMPT) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=ANSI_X3.4-1968) (ignored: LC_ALL set to C) Shell: /bin/sh linked to /bin/dash Versions of packages libcamel1.2-11 depends on: ii libc6 2.7-18 GNU C Library: Shared libraries ii libcomerr2 1.41.3-1 common error description library ii libedataserver1 2.22.3-1.1+lenny1Utility library for evolution data ii libgconf2-4 2.22.0-1 GNOME configuration database syste ii libglib2.0-02.16.6-1+lenny1 The GLib library of C routines ii libgnomevfs2-0 1:2.22.0-5 GNOME Virtual File System (runtime ii libkrb531.6.dfsg.4~beta1-5lenny1 MIT Kerberos runtime libraries ii libnspr4-0d 4.7.1-4 NetScape Portable Runtime Library ii libnss3-1d 3.12.0-5 Network Security Service libraries ii zlib1g 1:1.2.3.3.dfsg-12compression library - runtime libcamel1.2-11 recommends no packages. libcamel1.2-11 suggests no packages. -- no debconf information With the new version of libcamel1.2-11 (2.22.3-1.1+lenny1), any message that are encrypted with an S/MIME certificate will cause Evolution to crash after it prompts for the user's passphrase to decrypt it. S/MIME-signed/encrypted messages can be sent -- but attempting to preview or open such messages causes it to crash with a terse: evolution: symbol lookup error: /usr/lib/libcamel-provider-1.2.so.11: undefined symbol: set_nss_error This issue is also in Gentoo's bug tracker as: http://bugs.gentoo.org/show_bug.cgi?id=258867 Downgrading to the previous version of the package "fixes" this, but this reverts the security fixes in the new version. -- DN Daniel -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#516679: gophermap h links misinterpreted
Package: pygopherd Version: 2.0.17 h links in the gophermap file works correctly at the top-level gophermap, but not in a subdirectory. When using a gophermap at the subdirectory as follows: ramune/nietzsche:ramune: cat -A gophermap 1Entries from 2009^I2009^Ipsychosnugglebunnies.net^I70$ hATOM feed^IURL:http://psychosnugglebunnies.net/~ramune/phlog/tubers.xml^Ipsychosnugglebunnies.net^I80$ This is the link the browsers get: gopher://psychosnugglebunnies.net:80/h/ramune/URL:http://psychosnugglebunnies.net/~ramune/phlog/tubers.xml Firefox with Overbite using view source: gopher://psychosnugglebunnies.net:80/h/ramune/URL:http://psychosnugglebunnies.net/~ramune/phlog/tubers.xml";> And the gopher client from Debian with '=': Type=h Name=ATOM feed Path=/ramune/URL:http://psychosnugglebunnies.net/~ramune/phlog/tubers.xml Host=psychosnugglebunnies.net Port=80 gopher://psychosnugglebunnies.net:80/h/ramune/URL%3ahttp%3a//psychosnuggleb unnies.net/%7eramune/phlog/tubers.xml> Gophermap was removed from the system to prevent confusion for clients. If the directory contents are needed for analysis, I'd be happy to provide them. System is Debian/etch on x86-64. -- DN Daniel -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#474646: smime_keys doesn't handle mutt -Q tmpdir with ~
Package: mutt-patched Version: 1.5.17+20080114-1~bpo40+1 Not sure if this should be in mutt or mutt-patched, so sending it here for now. My .muttrc has: set tmpdir = /home/ramune/.tmp Due to this, mutt_Q in /usr/bin/smime_keys returns ~/.tmp for the tmpdir variable (and a few others, such as the S/MIME store, etc). As mutt translates the path to ~ instead of sending exactly what was in the .muttrc, smime_keys fails to create the temporary PEM file as it tries to open() the literal path ~/.tmp/smime/hash.0 instead of substituting /home/ramune for ~. I changed the muttrc to remove tildes after having problems with smime_keys, but it appears mutt still does substitutions. Having mutt print exactly what the user put into the ~/.muttrc would work as a work-around, but the smime_keys script should probably do tilde expansion as well. Debian/etch, i386 with mutt-patched from backports. If any additional information's needed, please let me know. Thanks, -- DN Daniel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#466604: [Pkg-aide-maintainers] Bug#466604: Aide floods "open_dir():Not a directory" in logs
I've reinstalled and re-run aideinit, and it seems to have gone away, so not sure what happened before on the upgrade. As I can't repo on demand, you can close this one out. If I get more information on how it got triggered, I'll reopen with more information. -- DN Daniel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#455773: Release file not being downloaded
> I'll be able to try the backports version in a day or so -- it's a production > server, so changing that has to go a bit slowly. I'll update the bug after > a volatile update happens again. I just checked, and it looks like backports.org only has an i386 version of approx. I tried to debuild it, but it has some dependencies on the build tools that ends up wanting to pull in changes to libc, amongst other things. Is there an x86_64 version somewhere I can test? -- DN Daniel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#455773: Release file not being downloaded
> Thanks for the details. Would you be able to try a newer version of > approx? I use the volatile repository myself, and don't see this > problem with the current version. > > There's an etch backport of approx at > http://packages.debian.org/etch-backports/approx, and there's version > 3.1.0~rc1 in experimental (for a lenny or sid system). I'll be able to try the backports version in a day or so -- it's a production server, so changing that has to go a bit slowly. I'll update the bug after a volatile update happens again. -- DN Daniel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#455773: Release file not being downloaded
> Can you send me the approx.conf entry corresponding to the volatile > repository, and the sources.list entry on the client that sees the > failure? Thanks. Sure. Note, the internal hostname.domain was changed to approx.example.com in the snippets below: On the server: # apt-show-versions |egrep approx approx/etch uptodate 2.8.0 # uname -m x86_64 # egrep -v '^(#.*)?$' < /etc/approx/approx.conf debian http://ftp.us.debian.org/debian securityhttp://security.debian.org volatilehttp://volatile.debian.net/debian-volatile etch-backports http://www.backports.org/debian On the i686 client: # uname -m i686 # egrep volatile /etc/apt/sources.list deb http://approx.example.com:/volatile etch/volatile main contrib non-free deb-src http://approx.example.com:/volatile etch/volatile main contrib non-free On one of the x86_64 clients: # uname -m x86_64 # egrep volatile /etc/apt/sources.list deb http://approx.example.com:/volatile etch/volatile main contrib non-free deb-src http://approx.example.com:/volatile etch/volatile main contrib non-free -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#455773: Release file not being downloaded
quit I'm also seeing this, only with the volatile archive. It happens for both i386 and amd64 archives on the system here. Removing the files under the archive "fixes" it for a short while, but inevitabily, when there is another change in the upstream files, the same error occurs again. tcpdump'ing the connection when the client was pulling directly from the remote repositories showed it requesting the Release.gpg and Release file on every invocation. However, with approx, neither of those files were requested then they were already on the filesystem. -- DN Daniel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#466604: Aide floods "open_dir():Not a directory" in logs
Package: aide Version: 0.13.1-2 Recently, I uninstalled (dpkg --purge) and re-installed Aide. All previous configuration files and databases were removed. I added the following to /etc/aide/aide.conf: !/dev !/home !/mnt !/proc !/root !/var !/selinux !/sys !/debug !/lib/init/rw !/tmp !/config Except I get a flood of these messages, still: open_dir():Not a directory: /var/log/aide/aide.log open_dir():Not a directory: /var/log/aide/aide.log.3.gz The flood of these messages in the logs is making looking at the daily reports rather difficult. Aide was working before the latest Etch update, when the cron job started giving me errors (bug 438429), hence the reinstall. Has anything changed recently that would affect Aide? /bin/sh is linked to bash, Etch on x86_64. What additional information is needed to track down the cause of this? -- DN Daniel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#438429: (no subject)
quit A server I maintain started getting this after the latest update to etch. Aide was running normally pre-upgrade, and the only things that were changed on the system were libc6 and cpio -- but the update was the only thing that changed before I started getting these messages. Checking manually, the /var/lib/aide/aide.db file existed, so I'm not sure what was going on. I uninstalled and re-installed Aide, and the onexit error messages went away. Just another data point. -- DN Daniel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#454902: /usr/bin/groffer doesn't work with dash
Package: groff
Version: 1.18.1.1-12
Severity: minor
The /usr/bin/groffer script in groff appears to have problems with dash:
ramune/lycaeum:~: sed -n '1p' /usr/bin/groffer
#!/bin/sh
ramune/lycaeum:~: /bin/sh -n /usr/bin/groffer
/usr/bin/groffer: 925: Syntax error: Bad function name
ramune/lycaeum:~: sed -n '920,937p' /usr/bin/groffer
# Test of `true'.
#
if true >/dev/null 2>&1; then
true;
else
true()
{
return "${_GOOD}";
}
false()
{
return "${_BAD}";
}
fi;
The script appears to work fine with bash, though.
The system is an x86_64/etch system.
-- DN
Daniel
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#454901: cm2rem doesn't work with dash
Package: remind
Version: 03.00.24-4
The cm2rem script in remind specifies #!/bin/sh, but doesn't appear to
work with dash:
ramune/lycaeum:~: sed -n '1p' /usr/bin/cm2rem
#!/bin/sh
ramune/lycaeum:~: /bin/sh -n /usr/bin/cm2rem
/usr/bin/cm2rem: 25: Syntax error: "(" unexpected
ramune/lycaeum:~: sed -n '25p' /usr/bin/cm2rem
set MonthNum($month) $i
System is on x86_64/etch.
-- DN
Daniel
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#448984: php5-sybase doesn't provide MS SQL support
Package: php5-sybase Version: 5.2.0-8+etch7 The php5-sybase module is built without --with-mssql, so many of the mssql_* functions are non-functional -- this point isn't made clear during the installation of the packages and there are no Debian-specific documentation that's easily found noting this. As the package description says it's for both Sybase and MS SQL Server, --with-mssql should be added to the extension's build. Grabbing the PHP source and building just the mssql module had problems as it conflicted with the sybase module. Removing the sybase module allowed the MS SQL functions to work. Noticed this when mssql_fetch_batch() failed to work, claiming the function was not defined -- even though it's in the documentation distributed with Debian and there's no notes saying it's non-functional. System is Debian/etch on i386. -- DN Daniel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#447677: s/mime plugin appears to be non-functional
Package: sylpheed-claws-gtk2-smime-plugin Version: 2.6.0-1 After installing the plugin, configuring gpg-agent, pinentry, dirmngr, importing the secret key and certificate into gpgsm, making sure the GPG_TTY and GPG_AGENT_INFO variables were exported correctly, etc., I find I am unable to sign messages. When sending a mail, a Window pops up with the following text: Could not queue message for sending: Signature failed: Secret key not found (End of file) However, gpgsm --list-keys and gpgsm --list-secret-keys shows the correct certificate and keys, gpgsm --list-chain shows the certificate chain installed. Maybe I missed the usage instructions hidden somewhere, but as far as I can tell, the only way to get the plugin to work is to have gpgsm pick the key automagically -- and the version of gnupg/gpgsm in etch doesn't have the default-key option enabled. What additional information is needed? I'd be happy to provide extra data (short of the secret key itself :-). Debian/etch on i386. -- DN Daniel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#442398: RT has non-functional link in user front page
Package: request-tracker3.6
Version: 3.6.1-4
The /etc/request-tracker3.6/initialdata file has the following toward the
bottom of the file, in the "Predefined searches" section:
@Attributes = (
{ Name => 'Search - My Tickets',
Description => '[_1] highest priority tickets I own', # loc
Content =>
{ Format => "'__id__/TITLE:#', '__Subject__/TITLE:Subject',
Priority, QueueName, Extende
dStatus",
Query => " Owner = '__CurrentUser__' AND ( Status = 'new' OR Status =
'open')",
OrderBy => 'Priority',
Order => 'DESC' },
},
The "$RT::WebPath" should be "__WebPath__". Due to that bug, the list of
tickets users get when they log in has a broken URL for the ticket subjects
of the form:
http://ticket/Display.html?id=1
instead of:
http://rt.example.com/Ticket/Display.html?id=1
Also noted on the rt-users mailing list:
http://lists.bestpractical.com/pipermail/rt-users/2007-March/044798.html
Changing the $RT::WebPath to __WebPath__ and running:
rt-setup-database --action insert --datafile /path/to/fixed/file
made it work for me, though I don't know if that was the "correct" fix.
System is Debian/etch on x86_64 with the volatile archives.
-- DN
Daniel
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#441568: (no subject)
Package: dovecot-common Version: 1.0.rc15-2etch1 The version of Dovecot included in Debian does not present the list of valid CAs for peer certificates. Clients such as Thunderbird/Icedove do not send over the client certificate, causing the connection to hang until the MUA decides to kill the connection. This bug was fixed upstream in: changeset: 5528:bad62bc7bafc user:Timo Sirainen <[EMAIL PROTECTED]> date:Fri Apr 06 12:30:03 2007 +0300 summary: Send list of CA names to client when using ssl_verify_client_cert=yes. The first upstream release with this fix was 1.0.rc30. Would backporting this fix into stable be a viable option? If not, stunnel can be used as a workaround, so it's not too big a deal, but it does make client certificate usage non-functional for applications that expect a list of valid CAs. System is Debian/etch on x86_64 with the volatile archives added. -- DN Daniel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#440794: man -d displays man pages
Package: man-db Version: 2.4.3-6 Severity: normal According to the man pages: -d, --debug Don't actually display any manual pages, but do print lots of debugging information. However, running "man -d " shows the manual page. Dependencies: ii bsdmainutils 6.1.6 ii debconf 1.5.11 ii dpkg 1.13.25 ii groff-base1.18.1.1-12 ii libgdbm3 1.8.3-3 ii libc6 2.3.6.ds1-13etch2 System is Debian/etch on i386, including the volatile respository. -- DN Daniel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#356406: Crash issue found
Okay, found the issue with the crash (I think). It looks like: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=8049 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=10395 The relevant instructions, when single-stepping through sprintf(), are: 0x2b008c63555f :mov%rsp,%rdx 0x2b008c635562 :jmpq *%r8d <> 0x2b008c635581 : movaps %xmm0,0xff81(%rcx) As any/all floating point values are handled in *printf() with xmm registers, the first movaps instruction causes it to spit out a segfault. I'm a bit fuzzy on the full implications, but if I'm reading it right (and eyeballing the disassembly right), it needs glibc rebuilt, too. Looks like gprolog on amd64 can't be built as a native binary until glibc is rebuilt and a backport for gcc 3.4.x is done, or gprolog gets ported to gcc 4.x. Argh. :( Or I could be completely and totally wrong. -- DN Daniel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#356406: gprolog segfault on division with amd64
On Tue, Mar 14, 2006 at 11:26:34AM +, Salvador Abreu wrote: > 1.2.18-12 is old already and there are problems compiling 1.2.18-16 > on amd64 machines (gcc 3.3.5 gets "internal errors"). > > Can you make do with the x86 binaries, while I look into finding an > amd64 machine to try things on? Sure. As an added data point, I just tried building 1.2.19 from upstream with gcc 3.4.3-13 -- gplc segfaults during build, just like gcc 3.3.5-13. -- DN Daniel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#356406: gprolog segfault on division with amd64
Package: gprolog Version: 1.2.18-12 Any time a division is done in gprolog, I get a segfault with sprintf() at the top of the backtrace, and what looks like tons of NULLs in the stacktrace. To repro: cat > a.pl < a.pl< foo(X) :- X is 10 / 3. > EOF barbeque/zarathustra:games: gdb gprolog GNU gdb 6.3-debian Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "x86_64-linux"...(no debugging symbols found) Using host libthread_db library "/lib/libthread_db.so.1". (gdb) r Starting program: /usr/bin/gprolog (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) GNU Prolog 1.2.18 By Daniel Diaz Copyright (C) 1999-2004 Daniel Diaz | ?- consult(a). compiling /public/src/mine/games/a.pl for byte code... /public/src/mine/games/a.pl compiled, 1 lines read - 347 bytes written, 6 ms yes | ?- foo(X). Program received signal SIGSEGV, Segmentation fault. 0x2b76d8c5e581 in sprintf () from /lib/libc.so.6 (gdb) bt #0 0x2b76d8c5e581 in sprintf () from /lib/libc.so.6 #1 0x0048b218 in ?? () #2 0x0048c5e6 in ?? () #3 0x0044cea1 in ?? () #4 0x38cb in ?? () #5 0x in ?? () <> #701 0x in ?? () #702 0x7fbce186 in ?? () #703 0x2b76d8e2f000 in stderr () from /lib/libc.so.6 #704 0x0001 in ?? () #705 0x7fbcdef0 in ?? () #706 0x0014 in ?? () #707 0x7fbcdef0 in ?? () #708 0x2b76d8c8089f in _IO_default_xsputn () from /lib/libc.so.6 #709 0x2b76d8c5792b in vfprintf () from /lib/libc.so.6 #710 0x2b76d8c77105 in vsprintf () from /lib/libc.so.6 #711 0x2b76d89770fa in _dl_lookup_versioned_symbol_skip () from /lib64/ld-linux-x86-64.so.2 #712 0x2b76d8976074 in _dl_lookup_versioned_symbol () from /lib64/ld-linux-x86-64.so.2 #713 0x2b76d8979718 in _dl_map_object_deps () from /lib64/ld-linux-x86-64.so.2 Previous frame inner to this frame (corrupt stack?) (gdb) info reg rax0x1 1 rbx0x2b76dc64f360 47789503738720 rcx0x7fbcc257 140737483948631 rdx0x7fbcc188 140737483948424 rsi0x4a1bf8 4856824 rdi0x687200 6844928 rbp0x7fbce2a0 0x7fbce2a0 rsp0x7fbcc188 0x7fbcc188 r8 0x2b76d8c5e581 47789442983297 r9 0x4 4 r100x1 1 r110x0 0 r120x2b76da64e000 47789470179328 r130x2b76d8e4c060 47789445005408 r140x2b76dc64f2b8 47789503738552 r150x2b76da64e9d8 47789470181848 rip0x2b76d8c5e581 0x2b76d8c5e581 eflags 0x10206 66054 cs 0x33 51 ss 0x2b 43 ds 0x0 0 es 0x0 0 fs 0x0 0 gs 0x0 0 (gdb) The program is running. Exit anyway? (y or n) y barbeque/zarathustra:games: uname -a Linux zarathustra 2.6.16-rc5-g292b976d #1 PREEMPT Mon Mar 6 23:39:23 PST 2006 x86_64 GNU/Linux barbeque/zarathustra:games: cat /proc/cpuinfo processor : 0 vendor_id : AuthenticAMD cpu family : 15 model : 7 model name : AMD Athlon(tm) 64 Processor 4000+ stepping: 10 cpu MHz : 2400.000 cache size : 1024 KB fpu : yes fpu_exception : yes cpuid level : 1 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 syscall nx mmxext lm 3dnowext 3dnow bogomips: 4813.12 TLB size: 1024 4K pages clflush size: 64 cache_alignment : 64 address sizes : 40 bits physical, 48 bits virtual power management: ts fid vid ttp barbeque/zarathustra:games: Script done on Sat Mar 11 13:11:32 2006 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#352761: /usr/bin/cflow ignores $TMPDIR
Package: cflow
Version: 2.0-17.1
A hard-coded dependency on /tmp is in the /usr/bin/cflow script.
Changing:
exclude_directory=/tmp/cflow.excludes
To:
exclude_directory=${TMPDIR:-/tmp/cflow.excludes}
Fixes it for me. /tmp is a rather small tmpfs partition on my box and
cflow fills it up pretty quick even on small projects I work on.
Debian/sarge, amd64 via amd64.debian.net packages.
-- DN
Daniel
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
