[Bug 1597933] Re: Atomicparsley package completely broken
Is there any specific reason for which this has not been marked invalid and closed? -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1597933 Title: Atomicparsley package completely broken To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/atomicparsley/+bug/1597933/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1741128] Re: libmagic1 in 16.04 reports XLS files as application/CDFV2-unknown
This bug was fixed upstream almost a year ago. It would be nice to see this addressed in Ubuntu 16.04 LTS, which is still on libmagic1 version 5.25. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1741128 Title: libmagic1 in 16.04 reports XLS files as application/CDFV2-unknown To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/file/+bug/1741128/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1365375] Re: package libc6-dev-i386 (not installed) failed to install/upgrade: trying to overwrite '/usr/include/gnu', which is also in package libc6-dev-amd64 2.19-0ubuntu6.3
The fact that this was reported on 2014-09-04 and *still* has not been fixed is unbelievable. It seems related to (or the same as) https://bugs.launchpad.net/ubuntu/+source/zlib/+bug/1512992 , which was opened on 2015-11-04 and has not been fixed yet either. Only ten days ago was a fix proposed, which, by the way, doesn't seem to resolve the problem. That is to say nothing of the obsoleted instructions at https://wiki.ubuntu.com/Testing/EnableProposed , which still mention the "aptitude" executable, which doesn't even exist in Ubuntu 16. Pretty disappointing, all around. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1365375 Title: package libc6-dev-i386 (not installed) failed to install/upgrade: trying to overwrite '/usr/include/gnu', which is also in package libc6 -dev-amd64 2.19-0ubuntu6.3 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/eglibc/+bug/1365375/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1644057] [NEW] Excessive Disconnect unmatched entries from sshd
Public bug reported: # lsb_release -rd Description:Ubuntu 16.04.1 LTS Release:16.04 # apt-cache policy logwatch logwatch: Installed: 7.4.2-1ubuntu1 Candidate: 7.4.2-1ubuntu1 Version table: *** 7.4.2-1ubuntu1 500 500 http://mirrors.digitalocean.com/ubuntu xenial/main amd64 Packages 500 http://mirrors.digitalocean.com/ubuntu xenial/main i386 Packages 100 /var/lib/dpkg/status The issue seems to be exactly as described here: https://bugzilla.redhat.com/show_bug.cgi?id=1317620 In synopsis, Logwatch's "SSHD" output contains excessive "Unmatched Entries" regarding SSH disconnections. They look like this: Received disconnect from 123.123.123.123 port 6887:11: disconnected by user : 1 time(s) Received disconnect from 123.123.123.123 port 8310:11: disconnected by user : 1 time(s) Disconnected from 123.123.123.123 port 1306 : 1 time(s) Received disconnect from 123.123.123.123 port 3720:11: disconnected by user : 1 time(s) Received disconnect from 123.123.123.123 port 3001:11: disconnected by user : 1 time(s) Disconnected from 123.123.123.123 port 1054 : 1 time(s) Received disconnect from 123.123.123.123 port 9741:11: disconnected by user : 1 time(s) Received disconnect from 123.123.123.123 port 3261:11: disconnected by user : 1 time(s) Received disconnect from 123.123.123.123 port 4650:11: disconnected by user : 1 time(s) Received disconnect from 123.123.123.123 port 13235:11: disconnected by user : 1 time(s) Received disconnect from 123.123.123.123 port 1065:11: disconnected by user : 1 time(s) Received disconnect from 123.123.123.123 port 13868:11: disconnected by user : 1 time(s) Disconnected from 123.123.123.123 port 8542 : 1 time(s) I should mention that these connections are from me, and are legitimate; they are not from "bots" or other types of probes/scans that are, for example, check for the availability of vulnerable ciphers. The key finding from the above report seems to be: "I don't know why there are two different format disconnect messages, but the bit that seems to confuse logwatch was adding the port number to the message." There seem to be several (3-5) such messages that result from a normal connect/disconnect cycle. ** Affects: logwatch (Ubuntu) Importance: Undecided Status: New -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1644057 Title: Excessive Disconnect unmatched entries from sshd To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/logwatch/+bug/1644057/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1548432] Re: rhkunter interprets mixed-case directive incorrectly in configuration file(s)
Thank you, François, I really appreciate it! John Horne with the rkhunter project replied, and his suggestion does indeed solve the problem for me, so we can go ahead and close this. For some reason, I thought that rkhunter's ALLOW_SSH_ROOT_USER directive wanted "PermitRootLogin", instead of PermitRootLogin's *value* in /etc/ssh/sshd_config! This was operator error on my part. Rather, rkhunter's ALLOW_SSH_ROOT_USER directive wants the same *value* that is assigned to PermitRootLogin in /etc/ssh/sshd_config. Changing rkhunter's config to ALLOW_SSH_ROOT_USER=yes fixes the issue. My bad! Nothing to see here, folks! ** Changed in: rkhunter (Ubuntu) Status: New => Invalid -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1548432 Title: rhkunter interprets mixed-case directive incorrectly in configuration file(s) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/rkhunter/+bug/1548432/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1548432] Re: rhkunter interprets mixed-case directive incorrectly in configuration file(s)
I forgot to mention the most annoying aspect of the bug, which is that there is no workaround. If I change rkhunter's configuration file to use "permitrootlogin" (all lower-case), somewhat unsurprisingly, the problem still occurs. [09:34:26] Info: Found SSH /etc/ssh/sshd_config configuration file: [09:34:26] Info: Rkhunter option ALLOW_SSH_ROOT_USER set to 'permitrootlogin'. [09:34:26] Info: Rkhunter option ALLOW_SSH_PROT_V1 set to '0'. [09:34:26] Checking if SSH root access is allowed [ Warning ] [09:34:26] Warning: The SSH and rkhunter configuration options should be the same: [09:34:26] SSH configuration option 'PermitRootLogin': yes [09:34:26] Rkhunter configuration option 'ALLOW_SSH_ROOT_USER': permitrootlogin But, surely, if we change the directive in the SSH configuration file, and even restart the SSH daemon, the problem will be solved! Nope, wrong. [09:39:11] Info: Found SSH /etc/ssh/sshd_config configuration file: [09:39:11] Info: Rkhunter option ALLOW_SSH_ROOT_USER set to 'permitrootlogin'. [09:39:11] Info: Rkhunter option ALLOW_SSH_PROT_V1 set to '0'. [09:39:11] Checking if SSH root access is allowed [ Warning ] [09:39:11] Warning: The SSH and rkhunter configuration options should be the same: [09:39:11] SSH configuration option 'PermitRootLogin': yes # <--- This is wrong! The sshd_config file contains "permitrootlogin"! [09:39:11] Rkhunter configuration option 'ALLOW_SSH_ROOT_USER': permitrootlogin So, we're stuck with a warning on every run, with no means by which to suppress it effectively. This renders the tool useless. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1548432 Title: rhkunter interprets mixed-case directive incorrectly in configuration file(s) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/rkhunter/+bug/1548432/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1548432] [NEW] rhkunter interprets mixed-case directive incorrectly in configuration file(s)
Public bug reported: # lsb_release -a No LSB modules are available. Distributor ID: Ubuntu Description:Ubuntu 14.04.4 LTS Release:14.04 Codename: trusty # apt-cache policy rkhunter rkhunter: Installed: 1.4.0-3 Candidate: 1.4.0-3 Version table: *** 1.4.0-3 0 500 http://us.archive.ubuntu.com/ubuntu/ trusty/universe amd64 Packages 100 /var/lib/dpkg/status rkhunter seems to be misinterpreting the case of the ALLOW_SSH_ROOT_USER directive in the effective configuration file. (I don't know whether the same problem applies to other directives.) Given a stock rkhunter installation, I created the file /etc/rkhunter.conf.local and added to it the following line (among a few others, though I doubt the other lines are relevant): ALLOW_SSH_ROOT_USER=PermitRootLogin Yet, when I execute "rkhunter --check", I receive the following warning: [12:21:34] Checking if SSH root access is allowed [ Warning ] [12:21:34] Warning: The SSH and rkhunter configuration options should be the same: [12:21:34] SSH configuration option 'PermitRootLogin': yes [12:21:34] Rkhunter configuration option 'ALLOW_SSH_ROOT_USER': permitrootlogin Clearly, rkhunter is casting the string in its own configuration file, "PermitRootLogin", to all-lowercase, yielding "permitrootlogin", thus triggering this erroneous warning. ** Affects: rkhunter (Ubuntu) Importance: Undecided Status: New -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1548432 Title: rhkunter interprets mixed-case directive incorrectly in configuration file(s) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/rkhunter/+bug/1548432/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1365375] Re: package libc6-dev-i386 (not installed) failed to install/upgrade: trying to overwrite '/usr/include/gnu', which is also in package libc6-dev-amd64 2.19-0ubuntu6.3
This bit me yet again, and this time, I had to add one more package to the list (lib64z1-dev, which is simply the x64 equivalent of lib32z1-dev, which we already knew to be problematic). The complete list of packages to force-remove to resolve this is now: sudo dpkg --purge --force-depends gcc-multilib sudo dpkg --purge --force-depends libc6-dev-x32 sudo dpkg --purge --force-depends lib32z1-dev sudo dpkg --purge --force-depends lib64z1-dev This package deadlock becomes a problem for anyone who attempts to compile software that includes gzip (e.g., nginx, opentracker). Given gzip's relative popularity, this should really be fixed. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1365375 Title: package libc6-dev-i386 (not installed) failed to install/upgrade: trying to overwrite '/usr/include/gnu', which is also in package libc6 -dev-amd64 2.19-0ubuntu6.3 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/eglibc/+bug/1365375/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1312917] Re: package libc6-dev-i386 (not installed) failed to install/upgrade: trying to overwrite '/usr/include/sys/timerfd.h', which is also in package libc6-dev-amd64 2.19-0ubuntu6, ncurse
This issue may be the same as or related to https://bugs.launchpad.net/ubuntu/+source/eglibc/+bug/1365375 . -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1312917 Title: package libc6-dev-i386 (not installed) failed to install/upgrade: trying to overwrite '/usr/include/sys/timerfd.h', which is also in package libc6-dev-amd64 2.19-0ubuntu6, ncurse To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/eglibc/+bug/1312917/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1365375] Re: package libc6-dev-i386 (not installed) failed to install/upgrade: trying to overwrite '/usr/include/gnu', which is also in package libc6-dev-amd64 2.19-0ubuntu6.3
@Karthik I agree; this is a particularly severe bug because it renders the entire apt-get facility useless. For what it's worth, even though the last command is the command that fixes the issue, I believe it to be desirable to execute the previous two commands, too, because those packages are part of the problematic dependency-chain. In other words, even though it may be possible to remove only the libc6-dev-x32 package and fix the problem, that approach seems more likely to introduce problems in the future (i.e., once Canonical fixes this package). -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1365375 Title: package libc6-dev-i386 (not installed) failed to install/upgrade: trying to overwrite '/usr/include/gnu', which is also in package libc6 -dev-amd64 2.19-0ubuntu6.3 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/eglibc/+bug/1365375/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1365375] Re: package libc6-dev-i386 (not installed) failed to install/upgrade: trying to overwrite '/usr/include/gnu', which is also in package libc6-dev-amd64 2.19-0ubuntu6.3
To follow-up on my previous comment, I was able to work around this broken state in aptitude by purging the offending packages with --force-depends: dpkg --purge --force-depends gcc-multilib dpkg --purge --force-depends lib32z1-dev dpkg --purge --force-depends libc6-dev-x32 Now, I'm able to use apt-get as normal. Hopefully, this workaround won't cause problems in the future. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1365375 Title: package libc6-dev-i386 (not installed) failed to install/upgrade: trying to overwrite '/usr/include/gnu', which is also in package libc6 -dev-amd64 2.19-0ubuntu6.3 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/eglibc/+bug/1365375/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1365375] Re: package libc6-dev-i386 (not installed) failed to install/upgrade: trying to overwrite '/usr/include/gnu', which is also in package libc6-dev-amd64 2.19-0ubuntu6.3
Thanks for taking the time to report this, richud, and especially for providing the attachments. This bug bit me today, too. Were you able to implement any sort of a workaround? This seems like a significant problem to go unfixed since September, 2014. Here's what happened, in my particular case (impetus was to compile NGINX): # apt-get install libpcre3-dev zlib1g-dev libssl-dev Reading package lists... Done Building dependency tree Reading state information... Done zlib1g-dev is already the newest version. zlib1g-dev set to manually installed. You might want to run 'apt-get -f install' to correct these: The following packages have unmet dependencies: gcc-4.8-multilib : Depends: libc6-dev-i386 (= 2.11) but it is not going to be installed lib32z1-dev : Depends: lib32c-dev libc6-dev-x32 : Depends: libc6-dev-i386 (= 2.19-0ubuntu6.5) but it is not going to be installed libpcre3-dev : Depends: libpcrecpp0 (= 1:8.31-2ubuntu2) but it is not going to be installed E: Unmet dependencies. Try 'apt-get -f install' with no packages (or specify a solution). Okay, so I try apt-get install -f... # apt-get -f install Reading package lists... Done Building dependency tree Reading state information... Done Correcting dependencies... Done The following extra packages will be installed: libc6-dev-i386 The following NEW packages will be installed: libc6-dev-i386 0 upgraded, 1 newly installed, 0 to remove and 15 not upgraded. 22 not fully installed or removed. Need to get 0 B/1,151 kB of archives. After this operation, 6,337 kB of additional disk space will be used. Do you want to continue? [Y/n] (Reading database ... 137387 files and directories currently installed.) Preparing to unpack .../libc6-dev-i386_2.19-0ubuntu6.5_amd64.deb ... Unpacking libc6-dev-i386 (2.19-0ubuntu6.5) ... dpkg: error processing archive /var/cache/apt/archives/libc6-dev-i386_2.19-0ubuntu6.5_amd64.deb (--unpack): trying to overwrite '/usr/include/gnu', which is also in package libc6-dev-amd64 2.19-0ubuntu6.5 Errors were encountered while processing: /var/cache/apt/archives/libc6-dev-i386_2.19-0ubuntu6.5_amd64.deb E: Sub-process /usr/bin/dpkg returned an error code (1) It's a bit difficult to compile anything on this system, without access to these crucial libraries. Worse, aptitude is now stuck in this state, and complains any time I try to modify a package (even unrelated packages). Here's an example: # apt-get autoremove Reading package lists... Done Building dependency tree Reading state information... Done You might want to run 'apt-get -f install' to correct these. The following packages have unmet dependencies: gcc-4.8-multilib : Depends: libc6-dev-i386 (= 2.11) but it is not installed lib32z1-dev : Depends: lib32c-dev libc6-dev-x32 : Depends: libc6-dev-i386 (= 2.19-0ubuntu6.5) but it is not installed E: Unmet dependencies. Try using -f. Of course, apt-get install -f just vomits the same error that I pasted above. So, I'm stuck in a loop with no way out. Suggestions, anyone? -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1365375 Title: package libc6-dev-i386 (not installed) failed to install/upgrade: trying to overwrite '/usr/include/gnu', which is also in package libc6 -dev-amd64 2.19-0ubuntu6.3 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/eglibc/+bug/1365375/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1378446] Re: dovecot-lda crashes (exits with status code 134) when message is passed to pipe backend
** Package changed: ubuntu = dovecot (Ubuntu) -- You received this bug notification because you are a member of Ubuntu Server Team, which is subscribed to dovecot in Ubuntu. https://bugs.launchpad.net/bugs/1378446 Title: dovecot-lda crashes (exits with status code 134) when message is passed to pipe backend To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/dovecot/+bug/1378446/+subscriptions -- Ubuntu-server-bugs mailing list Ubuntu-server-bugs@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs
[Bug 1378446] Re: dovecot-lda crashes (exits with status code 134) when message is passed to pipe backend
** Package changed: ubuntu = dovecot (Ubuntu) -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1378446 Title: dovecot-lda crashes (exits with status code 134) when message is passed to pipe backend To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/dovecot/+bug/1378446/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1378446] [NEW] dovecot-lda crashes (exits with status code 134) when message is passed to pipe backend
Public bug reported:
I first reported this issue on the Dovecot mailing list, but nobody
there was able to help me identify the source of the problem (no less
how to fix it). And that's a pretty sharp group! Here's the full thread:
http://www.mail-archive.com/dovecot@dovecot.org/msg58938.html
I will preface this by saying that this bug could very well be with
dovecot-deliver and not the antispam plugin, specifically. I'm still
trying to make that determination, definitively. Any assistance in that
regard is much appreciated.
One aspect that I would like to point-out immediately is that the
dovecot deliver manual at http://wiki2.dovecot.org/LDA#logging states
very clearly, If dovecot-lda fails to write to log files it exits with
temporary failure. That's a curious note, because I believe that a
temporary failure exit code is precisely what we're dealing with here.
Anyhow, without further ado...
On Ubuntu 12.04, I used this plug-in with great success, so when I
upgraded to 14.04 (using dist-upgrade), I had hoped to be able to
continue using it in exactly the same way.
I consulted the manpages for Ubuntu 12.04 LTS and 14.04 LTS and they are
identical -- verbatim, right down to the last letter. As such, I assumed
that my antispam-related configuration directives would not need to be
changed.
However, on Ubuntu 14.04, when the pipe script that the antispam
plugin calls executes dovecot-deliver (this is how I pass the ham or
spam message to a dedicated training mailbox), dovecot-deliver exits
with status code 134, every time. Dovecot seems not to log anything with
regard to the segfault in its logs, despite my efforts to configure
deliver to log any issues:
protocol lda {
..
# remember to give proper permissions for these files as well
log_path = /var/log/dovecot-lda-errors.log
info_log_path = /var/log/dovecot-lda.log
}
These are the permissions I assigned to those two log files:
# ls -lah /var/log | grep dovecot
-rw-r--r-- 1 vmail vmail 0 Sep 19 14:21 dovecot-lda-errors.log
-rw-r--r-- 1 vmail vmail 0 Sep 19 14:21 dovecot-lda.log
When I restart dovecot with these LDA logging efforts in-place, I still
don't see the log file sizes grow beyond zero bytes.
The exit code, 134, isn't mentioned at all in the documentation at
http://wiki2.dovecot.org/LDA , either.
By adding the following to the top of my pipe script (thank you to
Steffen Kaiser on the mailing list for the suggestion)
exec /tmp/trace 21
set -vx
I've been able to capture the following output when the pipe script is
called (pardon the wrapping); this is just the most relevant bit:
+ /usr/lib/dovecot/deliver -d sa-train...@localhost.com -m Training.SPAM
^A^H22212 prefix=lda:
^A^F22212 io_add(0x1) called twice fd=7, callback=0x7f020f5486f0 -
0x7f020f4f7530
^A^D22212 Raw backtrace: /usr/lib/dovecot/libdovecot.so.0(+0x5e271)
[0x7f020f536271] - /usr/lib/dovecot/libdovecot.so.0(+0x5e34e) [0x7f020f53634e]
- /usr/lib/dovecot/libdovecot.so.0(i_fatal+0) [0x7f020f4f1a9e] -
/usr/lib/dovecot/libdovecot.so.0(ioloop_iolist_add+0x83) [0x7f020f546533] -
/usr/lib/dovecot/libdovecot.so.0(io_loop_handle_add+0x3b) [0x7f020f546cbb] -
/usr/lib/dovecot/libdovecot.so.0(io_add+0x9b) [0x7f020f5459fb] -
/usr/lib/dovecot/libdovecot.so.0(master_service_io_listeners_add+0x69)
[0x7f020f4f6e49] -
/usr/lib/dovecot/libdovecot.so.0(master_service_init_finish+0xb0)
[0x7f020f4f6f90] - /usr/lib/dovecot/deliver(main+0x1cb) [0x7f020feea69b] -
/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf5) [0x7f020f131ec5] -
/usr/lib/dovecot/deliver(+0x31de) [0x7f020feeb1de]
/usr/local/bin/sa-learn-pipe.sh: line 52: 22212 Aborted (core
dumped) /usr/lib/dovecot/deliver -d sa-train...@localhost.com -m
Training.$mode
+ echo 'Exit status was 134'
The steps I took to obtain a core-dump are as follows:
# ulimit -c unlimited
# ulimit -c
unlimited
# vim /etc/sysctl.d/20-coredump.conf
(added the following contents to the above new file and saved the file)
kernel.core_uses_pid = 1
kernel.core_pattern = /tmp/core-%e-%s-%u-%g-%p-%t
fs.suid_dumpable = 2
# sysctl -p
# service dovecot stop
# /usr/sbin/dovecot -F -c /etc/dovecot/dovecot.conf
[1] 28150
At this point, when I drag a message from Inbox to Junk, a core-dump is
created in /tmp. Here is the gdb output for the core-dump:
# gdb /usr/lib/dovecot/deliver /tmp/core-deliver-6-5000-5000-29807-141115
GNU gdb (Ubuntu 7.7-0ubuntu3.1) 7.7
Copyright (C) 2014 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type show copying
and show warranty for details.
This GDB was configured as x86_64-linux-gnu.
Type show configuration for configuration details.
For bug reporting instructions, please see:
http://www.gnu.org/software/gdb/bugs/.
Find the GDB manual and other documentation resources online at:
[Bug 1303564] Re: Please update rkhunter to 1.4.2
I can only imagine how annoying this must be for admins who run a scan more than once per day. This is an LTS release, folks. This is supposed to be an enterprise-grade OS. Being warned about a root-kit, falsely, on every scan is not something to be taken lightly. Many of us have wasted lots of time trying to get to the bottom of these messages, only to find that an outdated update URL is at fault, is frustrating. Am I way off base here, or is this just a matter of updating the package to reflect updated source? -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1303564 Title: Please update rkhunter to 1.4.2 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/rkhunter/+bug/1303564/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1303564] Re: Please update rkhunter to 1.4.2
I don't know how more people aren't complaining about this. I receive a disconcerting email message every single day because of this bug. The average user will have no idea what's causing this warning, either; one has to dig into the detailed log file to find that this message results from a failed network update and not an actual root-kit on the system. Please fix this ASAP. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1303564 Title: Please update rkhunter to 1.4.2 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/rkhunter/+bug/1303564/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1002513] Re: Files cannot be downloaded over SSL in IE 6/7/8 on Windows XP
Thank you for the suggestion, cebe. I tried removing the Pragma header just before sending the file to the user-agent, but this measure does not correct the problem for me. I confirmed that the Pragma header is indeed gone from the response (using Firebug), but I still receive the error dialogs in IE. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1002513 Title: Files cannot be downloaded over SSL in IE 6/7/8 on Windows XP To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/libapache2-mod-xsendfile/+bug/1002513/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1002513] [NEW] Files cannot be downloaded over SSL in IE 6/7/8 on Windows XP
Public bug reported: # lsb_release -rd Description:Ubuntu 10.04.4 LTS Release:10.04 # apt-cache policy libapache2-mod-xsendfile libapache2-mod-xsendfile: Installed: 0.9-2 Candidate: 0.9-2 Version table: *** 0.9-2 0 500 http://us.archive.ubuntu.com/ubuntu/ lucid/universe Packages 100 /var/lib/dpkg/status When I attempt to download a file over SSL, using Internet Explorer (version 6, 7, or 8) on Windows XP, I receive an error dialog in IE: Internet Explorer cannot download file.ext from domain.tld. Internet explorer was not able to open this Internet site. The requested site is either unavailable or cannot be found. Please try again later. The error does not not happen over a plaintext connection, nor does it happen in IE = 9. I should add that when I do not use mod_xsendfile to serve the file to the user-agent, the issue does not occur, either. In other words, if I use pure PHP to send the data, the user-agent receives the file, as expected. While I realize that the problem may very well be with IE, and not mod_xsendfile, the chances of Microsoft patching its older browsers are close to zero, while the chances of the package author adding agent- specific conditional logic (if possible) to address the issue are certainly better. It would be a shame not to be able to use mod_xsendfile for anything mission-critical due to this one limitation. ** Affects: libapache2-mod-xsendfile (Ubuntu) Importance: Undecided Status: New ** Description changed: # lsb_release -rd Description:Ubuntu 10.04.4 LTS Release:10.04 # apt-cache policy libapache2-mod-xsendfile libapache2-mod-xsendfile: - Installed: 0.9-2 - Candidate: 0.9-2 - Version table: - *** 0.9-2 0 - 500 http://us.archive.ubuntu.com/ubuntu/ lucid/universe Packages - 100 /var/lib/dpkg/status + Installed: 0.9-2 + Candidate: 0.9-2 + Version table: + *** 0.9-2 0 + 500 http://us.archive.ubuntu.com/ubuntu/ lucid/universe Packages + 100 /var/lib/dpkg/status - - When I attempt to download a file over SSL, using Internet Explorer (version 6, 7, or 8) on Windows XP, I receive an error dialog in IE: + When I attempt to download a file over SSL, using Internet Explorer + (version 6, 7, or 8) on Windows XP, I receive an error dialog in IE: Internet Explorer cannot download file.ext from domain.tld. Internet explorer was not able to open this Internet site. The requested site is either unavailable or cannot be found. Please try again later. The error does not not happen over a plaintext connection, nor does it happen in IE = 9. + + I should add that when I do not use mod_xsendfile to serve the file to + the user-agent, the issue does not occur, either. In other words, if I + use pure PHP to send the data, the user-agent receives the file, as + expected. + + While I realize that the problem may very well be with IE, and not + mod_xsendfile, the chances of Microsoft patching its older browsers are + close to zero, while the chances of the package author adding agent- + specific conditional logic (if possible) to address the issue are + certainly better. + + It would be a shame not to be able to use mod_xsendfile for anything + mission-critical due to this one limitation. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1002513 Title: Files cannot be downloaded over SSL in IE 6/7/8 on Windows XP To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/libapache2-mod-xsendfile/+bug/1002513/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 904410] Re: Mailman configuration script causes syntax error in /var/lib/mailman/Mailman/mm_cfg.py, line 76
@Jeff: The workaround is contained at the bottom of the initial report: The only means by which I was able to remove the package was to fix problem by editing /var/lib/mailman/Mailman/mm_cfg.py directly and changing the line in question to: DEFAULT_SERVER_LANGUAGE = 'en' -- You received this bug notification because you are a member of Ubuntu Server Team, which is subscribed to mailman in Ubuntu. https://bugs.launchpad.net/bugs/904410 Title: Mailman configuration script causes syntax error in /var/lib/mailman/Mailman/mm_cfg.py, line 76 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/mailman/+bug/904410/+subscriptions -- Ubuntu-server-bugs mailing list Ubuntu-server-bugs@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs
[Bug 904410] Re: Mailman configuration script causes syntax error in /var/lib/mailman/Mailman/mm_cfg.py, line 76
@Jeff: The workaround is contained at the bottom of the initial report: The only means by which I was able to remove the package was to fix problem by editing /var/lib/mailman/Mailman/mm_cfg.py directly and changing the line in question to: DEFAULT_SERVER_LANGUAGE = 'en' -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/904410 Title: Mailman configuration script causes syntax error in /var/lib/mailman/Mailman/mm_cfg.py, line 76 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/mailman/+bug/904410/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 969426] Re: Apache fails to shutdown cleanly during update and removes libapache2-mod-php5 in the process, causing service restart to fail due to syntax errors in configuration
I have scoured the 'apt-get' documentation and am left to assume that Ubuntu's Update Manager uses its own logic to allow for upgrading packages selectively. This passage from apt-get's man-pages spells it out clearly: This is also the target to use if you want to upgrade one or more already-installed packages without upgrading every package you have on your system. Unlike the upgrade target, which installs the newest version of all currently installed packages, install will install the newest version of only the package(s) specified. Simply provide the name of the package(s) you wish to upgrade, and if a newer version is available, it (and its dependencies, as described above) will be downloaded and installed. So, even the apt-get manual states that 'apt-get install package-name' should be used to upgrade packages selectively. This is exactly the approach that Webmin has taken, and is exactly the reason that Apache with Mod-PHP is mucked-up every time it's upgraded. Am I asking the wrong questions? Or am I in the wrong place? Thanks again. -- You received this bug notification because you are a member of Ubuntu Server Team, which is subscribed to apache2 in Ubuntu. https://bugs.launchpad.net/bugs/969426 Title: Apache fails to shutdown cleanly during update and removes libapache2 -mod-php5 in the process, causing service restart to fail due to syntax errors in configuration To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/apache2/+bug/969426/+subscriptions -- Ubuntu-server-bugs mailing list Ubuntu-server-bugs@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs
[Bug 969426] Re: Apache fails to shutdown cleanly during update and removes libapache2-mod-php5 in the process, causing service restart to fail due to syntax errors in configuration
I have scoured the 'apt-get' documentation and am left to assume that Ubuntu's Update Manager uses its own logic to allow for upgrading packages selectively. This passage from apt-get's man-pages spells it out clearly: This is also the target to use if you want to upgrade one or more already-installed packages without upgrading every package you have on your system. Unlike the upgrade target, which installs the newest version of all currently installed packages, install will install the newest version of only the package(s) specified. Simply provide the name of the package(s) you wish to upgrade, and if a newer version is available, it (and its dependencies, as described above) will be downloaded and installed. So, even the apt-get manual states that 'apt-get install package-name' should be used to upgrade packages selectively. This is exactly the approach that Webmin has taken, and is exactly the reason that Apache with Mod-PHP is mucked-up every time it's upgraded. Am I asking the wrong questions? Or am I in the wrong place? Thanks again. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/969426 Title: Apache fails to shutdown cleanly during update and removes libapache2 -mod-php5 in the process, causing service restart to fail due to syntax errors in configuration To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/apache2/+bug/969426/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 969426] Re: Apache fails to shutdown cleanly during update and removes libapache2-mod-php5 in the process, causing service restart to fail due to syntax errors in configuration
Thank you for the reply, James; it clarifies the issue. Using 'apt-get upgrade' applied the package upgrades without causing Apache to shutdown uncleanly, and the libapache2-mod-php5 package was unaffected, so Apache restarted without issue. All is well. Perhaps this is a question is more appropriate for another venue, but is there any means by which to execute 'apt-get dist-upgrade' or 'apt-get upgrade', on the command-line, without updating every package on the system (excepting those that have been kept-back, of course). (I ask because when I reported this issue, I was using Webmin to apply the package upgrades. It seems that the problem is with Webmin's package upgrade implementation, so any insight offered here may be useful to the Webmin developer[s].) It appears that the Ubuntu Update Manager supports this behavior; it enables the user to un-check the boxes next to individual updates. At the same time, those selections do not persist once the Update Manager has been closed (which is the desired behavior). So, how does the Update Manager achieve this? Does it temporarily keep-back the unchecked packages, until the application is closed, and then remove the temporary holds? Or is there some lesser-known argument to 'apt-get' that allows one to specify the packages to be upgraded, explicitly? Thanks again. -- You received this bug notification because you are a member of Ubuntu Server Team, which is subscribed to apache2 in Ubuntu. https://bugs.launchpad.net/bugs/969426 Title: Apache fails to shutdown cleanly during update and removes libapache2 -mod-php5 in the process, causing service restart to fail due to syntax errors in configuration To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/apache2/+bug/969426/+subscriptions -- Ubuntu-server-bugs mailing list Ubuntu-server-bugs@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs
[Bug 969426] Re: Apache fails to shutdown cleanly during update and removes libapache2-mod-php5 in the process, causing service restart to fail due to syntax errors in configuration
Thank you for the reply, James; it clarifies the issue. Using 'apt-get upgrade' applied the package upgrades without causing Apache to shutdown uncleanly, and the libapache2-mod-php5 package was unaffected, so Apache restarted without issue. All is well. Perhaps this is a question is more appropriate for another venue, but is there any means by which to execute 'apt-get dist-upgrade' or 'apt-get upgrade', on the command-line, without updating every package on the system (excepting those that have been kept-back, of course). (I ask because when I reported this issue, I was using Webmin to apply the package upgrades. It seems that the problem is with Webmin's package upgrade implementation, so any insight offered here may be useful to the Webmin developer[s].) It appears that the Ubuntu Update Manager supports this behavior; it enables the user to un-check the boxes next to individual updates. At the same time, those selections do not persist once the Update Manager has been closed (which is the desired behavior). So, how does the Update Manager achieve this? Does it temporarily keep-back the unchecked packages, until the application is closed, and then remove the temporary holds? Or is there some lesser-known argument to 'apt-get' that allows one to specify the packages to be upgraded, explicitly? Thanks again. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/969426 Title: Apache fails to shutdown cleanly during update and removes libapache2 -mod-php5 in the process, causing service restart to fail due to syntax errors in configuration To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/apache2/+bug/969426/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 969426] [NEW] Apache fails to shutdown cleanly during update and removes libapache2-mod-php5 in the process, causing service restart to fail due to syntax errors in configuration
Public bug reported: # lsb_release -rd Description:Ubuntu 10.04.4 LTS Release:10.04 # apt-cache policy apache2 apache2: Installed: 2.2.14-5ubuntu8.9 Candidate: 2.2.14-5ubuntu8.9 Version table: *** 2.2.14-5ubuntu8.9 0 500 http://us.archive.ubuntu.com/ubuntu/ lucid-updates/main Packages 100 /var/lib/dpkg/status 2.2.14-5ubuntu8.8 0 500 http://us.archive.ubuntu.com/ubuntu/ lucid-security/main Packages 2.2.14-5ubuntu8 0 500 http://us.archive.ubuntu.com/ubuntu/ lucid/main Packages # apt-cache policy libapache2-mod-php5 libapache2-mod-php5: Installed: 5.3.2-1ubuntu4.14 Candidate: 5.3.2-1ubuntu4.14 Version table: *** 5.3.2-1ubuntu4.14 0 500 http://us.archive.ubuntu.com/ubuntu/ lucid-updates/main Packages 500 http://us.archive.ubuntu.com/ubuntu/ lucid-security/main Packages 100 /var/lib/dpkg/status 5.3.2-1ubuntu4 0 500 http://us.archive.ubuntu.com/ubuntu/ lucid/main Packages -- I have observed this behavior several times over the course of a few months now. It seems that any time I update apache2 and related packages, a) Apache cannot be shutdown cleanly, so all running processes are killed, and b) libapache2-mod-php5 is removed and never reinstalled. The fact that libapache2-mod-php5 is never reinstalled causes Apache to fail to start after the update, due to syntax errors (unrecognized directives) in the Apache configuration. The apt-get log transcript follows: -- Now updating apache2 .. Installing package(s) with command apt-get -y install apache2 .. Reading package lists... Building dependency tree... Reading state information... The following extra packages will be installed: apache2-mpm-worker apache2-threaded-dev apache2.2-bin apache2.2-common Suggested packages: ufw The following packages will be REMOVED: apache2-mpm-prefork libapache2-mod-php5 The following NEW packages will be installed: apache2-mpm-worker The following packages will be upgraded: apache2 apache2-threaded-dev apache2.2-bin apache2.2-common 4 upgraded, 1 newly installed, 2 to remove and 18 not upgraded. Need to get 3172kB of archives. After this operation, 8487kB disk space will be freed. Get:1 http://us.archive.ubuntu.com/ubuntu/ lucid-updates/main apache2-threaded-dev 2.2.14-5ubuntu8.9 [137kB] Get:2 http://us.archive.ubuntu.com/ubuntu/ lucid-updates/main apache2 2.2.14-5ubuntu8.9 [1488B] Get:3 http://us.archive.ubuntu.com/ubuntu/ lucid-updates/main apache2.2-common 2.2.14-5ubuntu8.9 [291kB] Get:4 http://us.archive.ubuntu.com/ubuntu/ lucid-updates/main apache2.2-bin 2.2.14-5ubuntu8.9 [2740kB] Get:5 http://us.archive.ubuntu.com/ubuntu/ lucid-updates/main apache2-mpm-worker 2.2.14-5ubuntu8.9 [2366B] Reading changelogs... apache2 (2.2.15-1) unstable; urgency=low * This release adds and enables mod_reqtimeout, which limits the time Apache waits for a client to send a complete request. This helps to mitigate against certain denial of service attacks. In case of problems with slow clients, the timeout values can be adjusted in /etc/apache2/mods-available/reqtimeout.conf , or the module can be disabled with a2dismod reqtimeout. -- Chuck Short zul...@ubuntu.com Tue, 13 Apr 2010 09:09:34 -0400 apt-listchanges: Mailing root: apt-listchanges: news for example.com Fetched 3172kB in 1s (1958kB/s) (Reading database ... 68899 files and directories currently installed.) Preparing to replace apache2-threaded-dev 2.2.14-5ubuntu8.8 (using .../apache2-threaded-dev_2.2.14-5ubuntu8.9_amd64.deb) ... Unpacking replacement apache2-threaded-dev ... Preparing to replace apache2 2.2.14-5ubuntu8.8 (using .../apache2_2.2.14-5ubuntu8.9_amd64.deb) ... Unpacking replacement apache2 ... (Reading database ... 68891 files and directories currently installed.) Removing libapache2-mod-php5 ... Module php5 disabled. Run '/etc/init.d/apache2 restart' to activate new configuration! dpkg: apache2-mpm-prefork: dependency problems, but removing anyway as you requested: roundcube-core depends on apache2 | lighttpd | httpd; however: Package apache2 is not configured yet. Package apache2-mpm-prefork which provides apache2 is to be removed. Package lighttpd is not installed. Package httpd is not installed. Package apache2-mpm-prefork which provides httpd is to be removed. mailman depends on apache2 | httpd; however: Package apache2 is not configured yet. Package apache2-mpm-prefork which provides apache2 is to be removed. Package httpd is not installed. Package apache2-mpm-prefork which provides httpd is to be removed. mediawiki depends on apache2 | httpd; however: Package apache2 is not configured yet.
[Bug 969426] [NEW] Apache fails to shutdown cleanly during update and removes libapache2-mod-php5 in the process, causing service restart to fail due to syntax errors in configuration
Public bug reported: # lsb_release -rd Description:Ubuntu 10.04.4 LTS Release:10.04 # apt-cache policy apache2 apache2: Installed: 2.2.14-5ubuntu8.9 Candidate: 2.2.14-5ubuntu8.9 Version table: *** 2.2.14-5ubuntu8.9 0 500 http://us.archive.ubuntu.com/ubuntu/ lucid-updates/main Packages 100 /var/lib/dpkg/status 2.2.14-5ubuntu8.8 0 500 http://us.archive.ubuntu.com/ubuntu/ lucid-security/main Packages 2.2.14-5ubuntu8 0 500 http://us.archive.ubuntu.com/ubuntu/ lucid/main Packages # apt-cache policy libapache2-mod-php5 libapache2-mod-php5: Installed: 5.3.2-1ubuntu4.14 Candidate: 5.3.2-1ubuntu4.14 Version table: *** 5.3.2-1ubuntu4.14 0 500 http://us.archive.ubuntu.com/ubuntu/ lucid-updates/main Packages 500 http://us.archive.ubuntu.com/ubuntu/ lucid-security/main Packages 100 /var/lib/dpkg/status 5.3.2-1ubuntu4 0 500 http://us.archive.ubuntu.com/ubuntu/ lucid/main Packages -- I have observed this behavior several times over the course of a few months now. It seems that any time I update apache2 and related packages, a) Apache cannot be shutdown cleanly, so all running processes are killed, and b) libapache2-mod-php5 is removed and never reinstalled. The fact that libapache2-mod-php5 is never reinstalled causes Apache to fail to start after the update, due to syntax errors (unrecognized directives) in the Apache configuration. The apt-get log transcript follows: -- Now updating apache2 .. Installing package(s) with command apt-get -y install apache2 .. Reading package lists... Building dependency tree... Reading state information... The following extra packages will be installed: apache2-mpm-worker apache2-threaded-dev apache2.2-bin apache2.2-common Suggested packages: ufw The following packages will be REMOVED: apache2-mpm-prefork libapache2-mod-php5 The following NEW packages will be installed: apache2-mpm-worker The following packages will be upgraded: apache2 apache2-threaded-dev apache2.2-bin apache2.2-common 4 upgraded, 1 newly installed, 2 to remove and 18 not upgraded. Need to get 3172kB of archives. After this operation, 8487kB disk space will be freed. Get:1 http://us.archive.ubuntu.com/ubuntu/ lucid-updates/main apache2-threaded-dev 2.2.14-5ubuntu8.9 [137kB] Get:2 http://us.archive.ubuntu.com/ubuntu/ lucid-updates/main apache2 2.2.14-5ubuntu8.9 [1488B] Get:3 http://us.archive.ubuntu.com/ubuntu/ lucid-updates/main apache2.2-common 2.2.14-5ubuntu8.9 [291kB] Get:4 http://us.archive.ubuntu.com/ubuntu/ lucid-updates/main apache2.2-bin 2.2.14-5ubuntu8.9 [2740kB] Get:5 http://us.archive.ubuntu.com/ubuntu/ lucid-updates/main apache2-mpm-worker 2.2.14-5ubuntu8.9 [2366B] Reading changelogs... apache2 (2.2.15-1) unstable; urgency=low * This release adds and enables mod_reqtimeout, which limits the time Apache waits for a client to send a complete request. This helps to mitigate against certain denial of service attacks. In case of problems with slow clients, the timeout values can be adjusted in /etc/apache2/mods-available/reqtimeout.conf , or the module can be disabled with a2dismod reqtimeout. -- Chuck Short zul...@ubuntu.com Tue, 13 Apr 2010 09:09:34 -0400 apt-listchanges: Mailing root: apt-listchanges: news for example.com Fetched 3172kB in 1s (1958kB/s) (Reading database ... 68899 files and directories currently installed.) Preparing to replace apache2-threaded-dev 2.2.14-5ubuntu8.8 (using .../apache2-threaded-dev_2.2.14-5ubuntu8.9_amd64.deb) ... Unpacking replacement apache2-threaded-dev ... Preparing to replace apache2 2.2.14-5ubuntu8.8 (using .../apache2_2.2.14-5ubuntu8.9_amd64.deb) ... Unpacking replacement apache2 ... (Reading database ... 68891 files and directories currently installed.) Removing libapache2-mod-php5 ... Module php5 disabled. Run '/etc/init.d/apache2 restart' to activate new configuration! dpkg: apache2-mpm-prefork: dependency problems, but removing anyway as you requested: roundcube-core depends on apache2 | lighttpd | httpd; however: Package apache2 is not configured yet. Package apache2-mpm-prefork which provides apache2 is to be removed. Package lighttpd is not installed. Package httpd is not installed. Package apache2-mpm-prefork which provides httpd is to be removed. mailman depends on apache2 | httpd; however: Package apache2 is not configured yet. Package apache2-mpm-prefork which provides apache2 is to be removed. Package httpd is not installed. Package apache2-mpm-prefork which provides httpd is to be removed. mediawiki depends on apache2 | httpd; however: Package apache2 is not configured yet.
[Bug 904410] Re: Mailman configuration script causes syntax error in /var/lib/mailman/Mailman/mm_cfg.py, line 76
Robie, if you will, what is the output of apt-cache policy mailman on your system? -- You received this bug notification because you are a member of Ubuntu Server Team, which is subscribed to mailman in Ubuntu. https://bugs.launchpad.net/bugs/904410 Title: Mailman configuration script causes syntax error in /var/lib/mailman/Mailman/mm_cfg.py, line 76 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/mailman/+bug/904410/+subscriptions -- Ubuntu-server-bugs mailing list Ubuntu-server-bugs@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs
[Bug 904410] Re: Mailman configuration script causes syntax error in /var/lib/mailman/Mailman/mm_cfg.py, line 76
Thanks, Robie. Given that your package version is identical to that contained in the initial report, further research seems warranted. Perhaps the package installation script attempts to obtain locale information from the operating system in order to populate the DEFAULT_SERVER_LANGUAGE value in the configuration file, which may explain why this problem affects some people and not others. -- You received this bug notification because you are a member of Ubuntu Server Team, which is subscribed to mailman in Ubuntu. https://bugs.launchpad.net/bugs/904410 Title: Mailman configuration script causes syntax error in /var/lib/mailman/Mailman/mm_cfg.py, line 76 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/mailman/+bug/904410/+subscriptions -- Ubuntu-server-bugs mailing list Ubuntu-server-bugs@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs
[Bug 904410] Re: Mailman configuration script causes syntax error in /var/lib/mailman/Mailman/mm_cfg.py, line 76
Robie, if you will, what is the output of apt-cache policy mailman on your system? -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/904410 Title: Mailman configuration script causes syntax error in /var/lib/mailman/Mailman/mm_cfg.py, line 76 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/mailman/+bug/904410/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 904410] Re: Mailman configuration script causes syntax error in /var/lib/mailman/Mailman/mm_cfg.py, line 76
Thanks, Robie. Given that your package version is identical to that contained in the initial report, further research seems warranted. Perhaps the package installation script attempts to obtain locale information from the operating system in order to populate the DEFAULT_SERVER_LANGUAGE value in the configuration file, which may explain why this problem affects some people and not others. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/904410 Title: Mailman configuration script causes syntax error in /var/lib/mailman/Mailman/mm_cfg.py, line 76 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/mailman/+bug/904410/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 677820] Re: php output is empty (rrdtool.so)
The attached patch file resolves the issues described in this report. ** Patch added: Patch to resolve critical PHP errors in amavis-stats https://bugs.launchpad.net/ubuntu/+source/amavis-stats/+bug/677820/+attachment/2923186/+files/677820.diff -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/677820 Title: php output is empty (rrdtool.so) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/amavis-stats/+bug/677820/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 677820] Re: php output is empty (rrdtool.so)
Slight correction to previously-attached patch file. ** Patch removed: Patch to resolve critical PHP errors in amavis-stats https://bugs.launchpad.net/ubuntu/+source/amavis-stats/+bug/677820/+attachment/2923186/+files/677820.diff ** Patch added: Patch to resolve critical PHP errors in amavis-stats https://bugs.launchpad.net/ubuntu/+source/amavis-stats/+bug/677820/+attachment/2923264/+files/677820.diff -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/677820 Title: php output is empty (rrdtool.so) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/amavis-stats/+bug/677820/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 963254] Re: PHP code throws warnings unnecessarily in several places
This patch resolves the issues identified in this report. ** Patch added: Patch to resolve PHP warnings in amavis-stats https://bugs.launchpad.net/ubuntu/+source/amavis-stats/+bug/963254/+attachment/2923455/+files/963254.diff -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/963254 Title: PHP code throws warnings unnecessarily in several places To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/amavis-stats/+bug/963254/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 963254] [NEW] PHP code throws warnings unnecessarily in several places
Public bug reported:
Summary of changes:
The code to which this comment refers causes numerous PHP warnings to be issued
each time the script is executed on systems on which PHP open_basedir
restrictions are in effect. If the location of the rrdtool executable were
defined as a configuration directive, a) the warnings would disappear and b)
the application would perform more efficiently (the filesystem is not queried
for directories that will not exist).
--
105c105,109
---
# XXX TODO
# This path should be defined as a configuration directive, so that
# open_basedir warnings are not thrown when the paths don't exist.
--
Wrapping this block in conditional logic prevents code from being executed when
its expected inputs are not set (i.e., when an rrdtool graph is not generated
for some reason).
--
130,143c134,149
if (preg_match(/(\d+)x(\d+)/, $output[0], $matches)) {
$retval[xsize] = $matches[1];
$retval[ysize] = $matches[2];
} else {
$rrd_error_val = $output[0];
return false;
}
array_shift($output);
$retval[calcpr] = array();
foreach ($output as $index = $value) {
$retval[calcpr][$index] = $value;
---
if (is_array($output) !empty($output)) {
if (preg_match(/(\d+)x(\d+)/, $output[0], $matches)) {
$retval[xsize] = $matches[1];
$retval[ysize] = $matches[2];
} else {
$rrd_error_val = $output[0];
return false;
}
array_shift($output);
$retval[calcpr] = array();
foreach ($output as $index = $value) {
$retval[calcpr][$index] = $value;
}
--
Suppressing warnings and errors in this way is discouraged, as it makes
debugging the application extremely difficult. There are other instances of
this approach elsewhere within the code, but they are less problematic because
application-specific errors are still triggered.
--
292c299
$readfile = @file($seenfile);
---
$readfile = file($seenfile);
--
This change addresses the mysterious output just below the Generated by
amavis-stats... line:
amavis-stats::error: rrd_graph():
This output is caused in /usr/share/amavis-
stats/templates/standard/overall_footer.tpl, line 10:
td align=left{OUT_MSG}/td
If we trace this variable back to its origin, we find that it is set in
/usr/share/amavis-stats/includes/page_tail.php, line 35:
'OUT_MSG' = $out_msg ? $out_msg : NULL)
Now we must hunt-down $out_msg, which turns-out to be set in /usr/share
/amavis-stats/index.php, line 250:
function asErr($txt = ) {
global $as_pkg, $out_msg;
$out_msg .= $as_pkg::error: $txtbr\n;
}
After some addition running-around, we find that the true origin of this
message is in index.php, line 893:
$ret = pre_graph($img, $opts, count($opts));
$infected = 0;
if (!is_array($ret)) {
$msg = rrd_error();
asErr(rrd_graph(): $msg);
return false;
}
We can see that the author's pre_graph() function is returning something
other than an array: boolean false. Reading the relevant comments within
the source code reveals that this message is likely the result of there
being no virus data to graph (which is why the function returns false).
This theory coincides with a message that is output just below the graph
image: NO VIRUS DATA TO GRAPH.
In summary, this is more of a warning than an error. The code should be
modified such that the warning is printed only when rrdtool actually returns an
error, in which case calling PHP's rrd_error function yields something other
than null:
--
899c906,908
asErr(rrd_graph(): $msg);
---
if (!empty($msg)) {
asErr(rrd_graph(): $msg);
}
--
This change addresses the fact that the original code does not exclude the '..'
directory operator that PHP's readdir() function returns, which is problematic
in this context.
--
1053c1062
if ($file != . is_dir($libdir/$file)) {
---
if ($file != . $file != '..' is_dir($libdir/$file)) {
1069c1078
if ($file != . is_dir($libdir/$file)) {
---
if ($file != . $file != '..' is_dir($libdir/$file)) {
--
This addresses an unset variable warning.
--
1091a1101,1103
}
else {
$legend_msg = '';
--
-- SYSTEM INFORMATION --
# lsb_release -rd
[Bug 677820] Re: php output is empty (rrdtool.so)
Frantisek, the reason that amavis-stats stopped functioning correctly
after applying package updates is that your PHP version was upgraded.
amavis-stats relies on PHP's dl() function, which was removed from some
SAPIs in PHP 5.3 (see: http://www.php.net/manual/en/function.dl.php ).
The workaround that you outlined (commenting-out one of the control
structures) will have undesirable effects and cause the script to
malfunction for embedded PHP configurations (because the $rrd variable
will always be set to command-line).
Instead, the calls to the dl() function should be replaced with calls to
the extension_loaded() function, as such:
[...]
if (function_exists('rrd_graph') !extension_loaded('rrdtool.so')) {
$rrd = PHP embedded;
}
if (!function_exists('rrd_graph') !extension_loaded('rrdtool.so')) {
[...]
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/677820
Title:
php output is empty (rrdtool.so)
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/amavis-stats/+bug/677820/+subscriptions
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 962589] [NEW] amavis-stats package is completely unusable
Public bug reported: This package could not possibly have been tested before inclusion in Ubuntu; nearly every aspect of the package is incorrect. Summary of issues: 1.) amavis-stats is started with a Cron job, which, as described at https://bugs.launchpad.net/ubuntu/+source/amavis-stats/+bug/477510 , is incorrect; amavis-stats should be started as a daemon. 2.) The amavis-stats daemon does not start because its configuration file does not exist at the expected location. 3.) The amavis-stats daemon cannot be stopped because its process ID (PID) file does not exist at the expected location. 4.) When the daemon is started, it is unable to write to the required directory, /var/lib/amavis-stats, because the permissions on this directory are incorrect. 5.) The log file from which amavis-stats should read, as defined in the amavis-stats configuration file, is incorrect (defined as /var/log/amavis.log, but should be /var/log/mail.log). 6.) The user:group under which the amavis-stats daemon runs lacks read access to required log file, /var/log/mail.log. 7.) Apache configuration file is not copied into place, so location alias /amavis-stats is not accessible via HTTP(S), rendering the amavis- stats interface unreachable. 8.) The PHP script, index.php, is riddled with problems, some of which prevent even basic operation (fatal errors occur) with PHP = 5.3. Issue details: 1.) The Cron job should be removed and an up-start script to start the daemon (/usr/sbin/amavis-stats) should be added instead. The fact that amavis-stats should be started as a daemon is evident from Ubuntu's own manpage for this package: http://manpages.ubuntu.com/manpages/lucid/man1 /amavis-stats.1.html For demonstration purposes, the daemon is started as such (the start argument is omitted): # /usr/sbin/amavis-stats 2.) Either the configuration file's actual location should be changed, or a symbolic link should be created to that effect: # ln /etc/amavis-stats/amavis-stats.conf /etc/ -s Thanks to rat-venus for the suggestion ( https://bugs.launchpad.net/ubuntu/+source/amavis- stats/+bug/477510/comments/3 ). 3.) Attempting to stop the daemon fails: # /usr/sbin/amavis-stats stop No PID file /var/lib/amavis-stats/amavis-stats.pid, can't stop the process The same type of error occurs with the reload argument. As such, it is necessary to kill the process directly, e.g., with SIGTERM -- less than ideal. The relevant lines in amavis-stats.conf seem to be accurate, so the precise nature of the issue is not immediately clear: (20) # $MYHOME = '/var/lib/amavis-stats'; # (default is '/var/lib/amavis-stats') (35) $pid_file = $MYHOME/amavis-stats.pid; # (default is $MYHOME/amavis-stats.pid) This bug was added to the Debian tracker on 2009.05.13, but was expunged during automated maintenance before a solution was found. See: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=528589#17 . 4.) Upon starting the service, the following errors are logged to /var/log/syslog: Mar 7 12:45:01 dev Amavis-Stats[20295]: Starting - localhost Mar 7 12:45:01 dev Amavis-Stats[20295]: ERROR : /var/lib/amavis-stats does not exist or cannot be written to. This makes perfect sense, as amavis-stats, by default, runs as the www- data user, who, of course, lacks access to /var/lib/amavis-stats (as amavis-stats:adm are the user:group on the directory). By default, the permissions on the application directory deny the required level of access: # ls -lah /var/lib/amavis-stats total 8.0K drwxr-xr-x 2 amavis-stats adm 4.0K May 14 2009 . drwxr-xr-x 49 root root 4.0K Mar 22 13:32 .. The user:group combination under which the amavis-stats service is run must: a.) Have read/write access to /var/lib/amavis-stats (whose ownership is amavis-stats:adm, by default) b.) Have read access to /var/log/mail.log (whose ownership is syslog:adm, by default) And the Apache user (www-data, by default) must: a.) Have write access to /var/lib/amavis-stats The only way (of which I am aware) to satisfy all of these requirements is to # chown -R www-data:adm /var/lib/amavis-stats and change the user:group under which the amavis-stats daemon is started to www-data:adm ~ line 25 of amavis-stats.conf: # Set the user and group to which the daemon will change if started as root # (otherwise just keeps the UID unchanged, and these settings have no effect): $daemon_user= 'www-data'; # (no default; customary: www-data) $daemon_group = 'adm'; # (no default; customary: www-data) Perhaps there is a better solution that makes use of the amavis-stats group that is created upon installation, the process of which, by the way, throws the following warning: Setting up amavis-stats (0.1.22-1) ... adduser: Warning: The home directory `/var/lib/amavis-stats' does not belong to the user you are currently creating. 5.) Around line 38 of amavis-stats.conf, the $scan_logfile value must be changed to the following: # What
[Bug 942255] [NEW] Ability to save or export results
Public bug reported: It would be nice if Baobab had the ability to save or export disk usage analysis results. ** Affects: baobab (Ubuntu) Importance: Undecided Status: New -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/942255 Title: Ability to save or export results To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/baobab/+bug/942255/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 155794] Re: pam_env can't open /etc/default/locale
Again, same here on Ubuntu Server 10.04. Like the others, fixed by executing the update-locale command, which creates the file /etc/default/locale. This file appears not to exist out-of-the-box. The contents of this file are: # File generated by update-locale -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/155794 Title: pam_env can't open /etc/default/locale To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/pam/+bug/155794/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 904410] [NEW] Mailman configuration script causes syntax error in /var/lib/mailman/Mailman/mm_cfg.py, line 76
Public bug reported: # lsb_release -rd Description:Ubuntu 10.04.2 LTS Release:10.04 # apt-cache policy mailman mailman: Installed: 1:2.1.13-1ubuntu0.2 Candidate: 1:2.1.13-1ubuntu0.2 Version table: *** 1:2.1.13-1ubuntu0.2 0 500 http://us.archive.ubuntu.com/ubuntu/ lucid-updates/main Packages 500 http://us.archive.ubuntu.com/ubuntu/ lucid-security/main Packages 100 /var/lib/dpkg/status 1:2.1.13-1 0 500 http://us.archive.ubuntu.com/ubuntu/ lucid/main Packages The problem is that the Mailman configuration script that is included with the package fails to insert the default Mailman language string into /var/lib/mailman/Mailman/mm_cfg.py, line 76, which causes a syntax error. This syntax error makes it impossible to work with the package (reinstall, remove, etc.), because every attempted operation chokes. Here is the full log of the terminal output: - # apt-get install mailman Reading package lists... Done Building dependency tree Reading state information... Done The following packages were automatically installed and are no longer required: wwwconfig-common javascript-common libjs-mootools Use 'apt-get autoremove' to remove them. Suggested packages: listadmin The following NEW packages will be installed: mailman 0 upgraded, 1 newly installed, 0 to remove and 14 not upgraded. Need to get 9677kB of archives. After this operation, 44.9MB of additional disk space will be used. Get:1 http://us.archive.ubuntu.com/ubuntu/ lucid-updates/main mailman 1:2.1.13-1ubuntu0.2 [9677kB] Fetched 9677kB in 1s (5759kB/s) Preconfiguring packages ... Selecting previously deselected package mailman. (Reading database ... 59028 files and directories currently installed.) Unpacking mailman (from .../mailman_1%3a2.1.13-1ubuntu0.2_amd64.deb) ... Setting up mailman (1:2.1.13-1ubuntu0.2) ... Looking for enabled languages (this may take some time) ... done. Traceback (most recent call last): File /var/lib/mailman/bin/list_lists, line 46, in module from Mailman import mm_cfg File /var/lib/mailman/Mailman/mm_cfg.py, line 76 DEFAULT_SERVER_LANGUAGE = ^ SyntaxError: invalid syntax Installing site language en done. Traceback (most recent call last): File /usr/lib/mailman/bin/update, line 49, in module from Mailman import mm_cfg File /var/lib/mailman/Mailman/mm_cfg.py, line 76 DEFAULT_SERVER_LANGUAGE = ^ SyntaxError: invalid syntax dpkg: error processing mailman (--configure): subprocess installed post-installation script returned error exit status 1 Errors were encountered while processing: mailman E: Sub-process /usr/bin/dpkg returned an error code (1) - If I examine the file and line cited in the error message, there is no value for DEFAULT_SERVER_LANGUAGE: #- # The default language for this server. DEFAULT_SERVER_LANGUAGE = This is despite the fact that I chose a valid language (English) from the list that is presented during installation by highlighting said language and pressing the spacebar. (The selection is evidenced by the * character next to the English option.) The only means by which I was able to remove the package was to fix problem by editing /var/lib/mailman/Mailman/mm_cfg.py directly and changing the line in question to: DEFAULT_SERVER_LANGUAGE = 'en' ** Affects: mailman (Ubuntu) Importance: Undecided Status: New -- You received this bug notification because you are a member of Ubuntu Server Team, which is subscribed to mailman in Ubuntu. https://bugs.launchpad.net/bugs/904410 Title: Mailman configuration script causes syntax error in /var/lib/mailman/Mailman/mm_cfg.py, line 76 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/mailman/+bug/904410/+subscriptions -- Ubuntu-server-bugs mailing list Ubuntu-server-bugs@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs
[Bug 904410] [NEW] Mailman configuration script causes syntax error in /var/lib/mailman/Mailman/mm_cfg.py, line 76
Public bug reported: # lsb_release -rd Description:Ubuntu 10.04.2 LTS Release:10.04 # apt-cache policy mailman mailman: Installed: 1:2.1.13-1ubuntu0.2 Candidate: 1:2.1.13-1ubuntu0.2 Version table: *** 1:2.1.13-1ubuntu0.2 0 500 http://us.archive.ubuntu.com/ubuntu/ lucid-updates/main Packages 500 http://us.archive.ubuntu.com/ubuntu/ lucid-security/main Packages 100 /var/lib/dpkg/status 1:2.1.13-1 0 500 http://us.archive.ubuntu.com/ubuntu/ lucid/main Packages The problem is that the Mailman configuration script that is included with the package fails to insert the default Mailman language string into /var/lib/mailman/Mailman/mm_cfg.py, line 76, which causes a syntax error. This syntax error makes it impossible to work with the package (reinstall, remove, etc.), because every attempted operation chokes. Here is the full log of the terminal output: - # apt-get install mailman Reading package lists... Done Building dependency tree Reading state information... Done The following packages were automatically installed and are no longer required: wwwconfig-common javascript-common libjs-mootools Use 'apt-get autoremove' to remove them. Suggested packages: listadmin The following NEW packages will be installed: mailman 0 upgraded, 1 newly installed, 0 to remove and 14 not upgraded. Need to get 9677kB of archives. After this operation, 44.9MB of additional disk space will be used. Get:1 http://us.archive.ubuntu.com/ubuntu/ lucid-updates/main mailman 1:2.1.13-1ubuntu0.2 [9677kB] Fetched 9677kB in 1s (5759kB/s) Preconfiguring packages ... Selecting previously deselected package mailman. (Reading database ... 59028 files and directories currently installed.) Unpacking mailman (from .../mailman_1%3a2.1.13-1ubuntu0.2_amd64.deb) ... Setting up mailman (1:2.1.13-1ubuntu0.2) ... Looking for enabled languages (this may take some time) ... done. Traceback (most recent call last): File /var/lib/mailman/bin/list_lists, line 46, in module from Mailman import mm_cfg File /var/lib/mailman/Mailman/mm_cfg.py, line 76 DEFAULT_SERVER_LANGUAGE = ^ SyntaxError: invalid syntax Installing site language en done. Traceback (most recent call last): File /usr/lib/mailman/bin/update, line 49, in module from Mailman import mm_cfg File /var/lib/mailman/Mailman/mm_cfg.py, line 76 DEFAULT_SERVER_LANGUAGE = ^ SyntaxError: invalid syntax dpkg: error processing mailman (--configure): subprocess installed post-installation script returned error exit status 1 Errors were encountered while processing: mailman E: Sub-process /usr/bin/dpkg returned an error code (1) - If I examine the file and line cited in the error message, there is no value for DEFAULT_SERVER_LANGUAGE: #- # The default language for this server. DEFAULT_SERVER_LANGUAGE = This is despite the fact that I chose a valid language (English) from the list that is presented during installation by highlighting said language and pressing the spacebar. (The selection is evidenced by the * character next to the English option.) The only means by which I was able to remove the package was to fix problem by editing /var/lib/mailman/Mailman/mm_cfg.py directly and changing the line in question to: DEFAULT_SERVER_LANGUAGE = 'en' ** Affects: mailman (Ubuntu) Importance: Undecided Status: New -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/904410 Title: Mailman configuration script causes syntax error in /var/lib/mailman/Mailman/mm_cfg.py, line 76 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/mailman/+bug/904410/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 614895] Re: audex crashes when setting up new encoding profile
This is fixed in version 0.73b1 on the author's site: http://kde.maniatek.com/audex/download -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/614895 Title: audex crashes when setting up new encoding profile -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 614895] Re: audex crashes when setting up new encoding profile
Audex was Segmentation Faulting for me when saving profiles or doing a Codec Scan from the profile configuration window. After getting all the encoders that Audex looks for installed and removing ~/.kde/share/config/audexrc, it no longer Seg Faulted. The encoders I needed to install are lame, flac, oggenc, faac, and wavpack. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/614895 Title: audex crashes when setting up new encoding profile -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 283658] Re: grip buffer overflow in intrepid
If you are using LAME as the encoder, a good work around is tagging files with lame instead instead of letting Grip do it. 1. on the Config / ID3 Screen, turn off all ID3 tags 2. on the Config / Encode / Encoder screen, set Encoder: lame Encoder executable: /usr/bin/lame Encoder command line: -h -b %b --add-id3v2 --tt %n --ta %a --tl %d --ty %y --tc Grip 3.3.1 / Lame 3.98 --tn %t/%N --tg %G %w %m.%x Encode file extension: mp3 Encode file format: /mp3riptmp/%A - %d/%a - %n -- grip buffer overflow in intrepid https://bugs.launchpad.net/bugs/283658 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 79636] Re: Banshee crashes if you try to delete a song that doesn't exist
** Changed in: banshee (Ubuntu) Status: Unconfirmed = Confirmed -- Banshee crashes if you try to delete a song that doesn't exist https://bugs.launchpad.net/bugs/79636 You received this bug notification because you are a member of Ubuntu Bugs, which is the bug contact for Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 79636] Banshee crashes if you try to delete a song that doesn't exist
Public bug reported: Binary package hint: banshee If a song is missing from your hard drive and you try to delete it instead of merely removing it, Banshee crashes. ** Affects: banshee (Ubuntu) Importance: Undecided Status: Unconfirmed -- Banshee crashes if you try to delete a song that doesn't exist https://launchpad.net/bugs/79636 -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
