Bug#860879: closed by Holger Levsen (Bug#860879: fixed in munin 2.999.6-2)
Ouch, apparently I made a typo in the title of my bug report: the package name is libio-string-perl, not libo-string-perl This leads to this error when upgrading: munin : Depends: libo-string-perl but it is not installable My apologies for the confusion... -- Frederik Himpe Vrije Universiteit Brussel
Bug#860879: [Packaging] Bug#860879: munin-httpd needs libo-string-perl and libhttp-server-simple-cgi-prefork-perl
On Fri, 2017-04-21 at 11:05 +, Holger Levsen wrote: > control: severity -1 serious > > On Fri, Apr 21, 2017 at 11:19:28AM +0200, Frederik Himpe wrote: > > Munin from experimtal fails to start if > > libhttp-server-simple-cgi-prefork-perl and libio-string-perl is not > > installed. > The Munin cron job is also missing libparallel-forkmanager-perl as a dependency: Can't locate Parallel/ForkManager.pm in @INC (you may need to install the Parallel::ForkManager module) (@INC contains: /etc/perl /usr/local/lib/x86_64-linux-gnu/perl/5.24.1 /usr/local/share/perl/5.24.1 /usr/lib/x86_64-linux-gnu/perl5/5.24 /usr/share/perl5 /usr/lib/x86_64-linux-gnu/perl/5.24 /usr/share/perl/5.24 /usr/local/lib/site_perl /usr/lib/x86_64-linux-gnu/perl-base) at /usr/share/perl5/Munin/Master/Update.pm line 154. BEGIN failed--compilation aborted at /usr/share/perl5/Munin/Master/Update.pm line 154. Compilation failed in require at /usr/bin/munin-update line 12. BEGIN failed--compilation aborted at /usr/bin/munin-update line 12. After installing that package, the cron job still fails with a compilation error, but I'll open a separate bug report for that if I can find out what's wrong exactly. -- Frederik Himpe Vrije Universiteit Brussel
Bug#836611: chromium: crash after upgrade 52.0.2743.116-2 -> 53.0.2785.89-1
Could this be triggered by the switch to GCC 6? https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68853 https://bugs.chromium.org/p/v8/issues/detail?id=3782 -- Frederik Himpe
Bug#781888: [pkg-cinnamon] Bug#781888: cinnamon-session: session does not start
On 2015-05-16 15:16, Frederik Himpe wrote: I am experiencing this bug on two different systems now. I have opened an upstream bug: https://github.com/linuxmint/Cinnamon/issues/4156 # apt-get install -t experimental gir1.2-meta-muffin-0.0 fixed this problem. All muffin packages where still the 2.2 version. So this dependency seems to be missing. -- Frederik Himpe -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#781888: [pkg-cinnamon] Bug#781888: cinnamon-session: session does not start
I am experiencing this bug on two different systems now. I have opened an upstream bug: https://github.com/linuxmint/Cinnamon/issues/4156 -- Frederik Himpe -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#781888: [pkg-cinnamon] Bug#781888: cinnamon-session: session does not start
On Mon, 2015-05-04 at 12:35 +0200, Maximiliano Curia wrote: > Hi, > > On 02/05/15 17:25, Frederik Himpe wrote: > > I'm experiencing exactly the same problem on one of my systems: > > > ii libcinnamon-control-center1:amd64 2.2.11-4 amd64utilities to > > configure the Cinnamon desktop > > Oh, cinnamon-control-center is missing a version dependency of > libcinnamon-control-center1, added. > > > ii libcinnamon-menu-3-0 2.2.0-3 amd64Cinnamon > > implementation of the freedesktop menu specification > > Well, that's not updated, you are probably missing the updated: > gir1.2-cmenu-3.0 > > I'm adding those missing dependencies (that would be part of the next > release). Please let me know it that fixes the issue. No, it does not help. I have these versions installed on one system where Cinnamon is starting successfully: ii cinnamon 2.4.8-1 amd64Innovative and comfortable desktop ii cinnamon-common 2.4.8-1 all Innovative and comfortable desktop (Common data files) ii cinnamon-control-center 2.4.2-1 amd64utilities to configure the Cinnamon desktop ii cinnamon-control-center-data 2.4.2-1 all configuration applets for Cinnamon - data files ii cinnamon-core 2.2.4all Cinnamon desktop environment - essential components ii cinnamon-desktop-data 2.4.2-1 all Common files for Cinnamon desktop apps ii cinnamon-screensaver 2.4.2-1 amd64Cinnamon screen saver and locker ii cinnamon-session 2.4.3-1 amd64Cinnamon Session Manager - Minimal runtime ii cinnamon-session-common 2.4.3-1 all Cinnamon Session Manager - common files ii cinnamon-settings-daemon 2.4.3-1 amd64daemon handling the Cinnamon session settings ii cjs 2.4.2-1 amd64Mozilla-based javascript bindings for the GNOME platform ii gir1.2-cinnamondesktop-3.02.4.2-1 amd64Introspection data for CinnamonDesktop ii gir1.2-cmenu-3.0 2.2.0-3 amd64GObject introspection data for the Cinnamon menu library ii libcinnamon-control-center1:amd64 2.4.2-1 amd64utilities to configure the Cinnamon desktop ii libcinnamon-desktop4:amd642.4.2-1 amd64Cinnamon library for loading .desktop files ii libcinnamon-menu-3-0 2.2.0-3 amd64Cinnamon implementation of the freedesktop menu specification ii libcjs0:amd64 2.4.2-1 amd64Mozilla-based javascript bindings for the GNOME platform So it looks like these missing dependencies are unrelated to this problem. -- Frederik Himpe -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#781888: cinnamon-session: session does not start
I'm experiencing exactly the same problem on one of my systems: $ dpkg -l "*cinnamon*" "*cjs*" | grep ii ii cinnamon 2.4.8-1 amd64 Innovative and comfortable desktop ii cinnamon-common 2.4.8-1 all Innovative and comfortable desktop (Common data files) ii cinnamon-control-center 2.4.2-1 amd64 utilities to configure the Cinnamon desktop ii cinnamon-control-center-data 2.4.2-1 all configuration applets for Cinnamon - data files ii cinnamon-core 2.2.4all Cinnamon desktop environment - essential components ii cinnamon-desktop-data 2.4.2-1 all Common files for Cinnamon desktop apps ii cinnamon-desktop-environment 2.2.4all Cinnamon desktop environment - full desktop with extra components ii cinnamon-l10n 2.2.4-1 all Translation files for the Cinnamon desktop ii cinnamon-screensaver 2.4.2-1 amd64Cinnamon screen saver and locker ii cinnamon-session 2.4.3-1 amd64Cinnamon Session Manager - Minimal runtime ii cinnamon-session-common 2.2.2-5 all Cinnamon Session Manager - common files ii cinnamon-settings-daemon 2.4.3-1 amd64daemon handling the Cinnamon session settings ii cjs 2.4.2-1 amd64 Mozilla-based javascript bindings for the GNOME platform ii gir1.2-cinnamondesktop-3.02.4.2-1 amd64 Introspection data for CinnamonDesktop ii libcinnamon-control-center1:amd64 2.2.11-4 amd64 utilities to configure the Cinnamon desktop ii libcinnamon-desktop4:amd642.4.2-1 amd64Cinnamon library for loading .desktop files ii libcinnamon-menu-3-0 2.2.0-3 amd64Cinnamon implementation of the freedesktop menu specification ii libcjs0:amd64 2.4.2-1 amd64 Mozilla-based javascript bindings for the GNOME platform -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#755202:
On ma, 2015-03-02 at 22:14 +0100, Frederik Himpe wrote: > I removed the netconsole stuff, removed the eth0 network connection in > NM, and rebooted the system, and everything was OK again. I spoke too soon. Now I'm again experiencing this problem, even without netconsole. It looks like there is a race somewhere, causing the network interface to be brought up before Network Manager is started, and this prevents correct configuration by NM... -- Frederik Himpe -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#755202:
I discussed this problem on the upstream mailing list here: http://thread.gmane.org/gmane.linux.network.networkmanager.devel/25377 In my case, the problem was indeed that netconsole was loaded. Netconsole was loaded in the initrd, and brought the network interface up. As the network interface went up, the kernel would automatically configure an IPv6 address via SLAAC. Then when later network-manager starts up, it notices that the network interface is already brought up, and hence it decides not to touch it any more: instead of loading the default network configuration for that device, a (temporary) network connection with the name of the device and the configuration corresponding to the actual state (in my case: IPv6 activated but no IPv4) is created in NM. I removed the netconsole stuff, removed the eth0 network connection in NM, and rebooted the system, and everything was OK again. Apparently it's only safe to load netconsole after NM has started, otherwise you get hit by this problem. -- Frederik Himpe -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#770695: dovecot-core installation hanging with [dovecot-core.po]
I am experiencing exactly the same bug on an OpenVZ VPS. What was the cause for this problem and how did it get fixed? -- Frederik Himpe -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#755202: NetworkManager creates broken eth0 connection while booting
On za, 2014-10-11 at 09:41 +0200, Stefano Zacchiroli wrote: > On Sat, Oct 11, 2014 at 12:48:25AM +0200, Tobias Hansen wrote: > > Control: severity -1 serious > > > > I'm also having this problem and setting AVAHI_DAEMON_DETECT_LOCAL=0 > > didn't help in my case. I also have this eth0:avahi entry in ifconfig. > > Raising severity since we really don't want to have this bug in a release. > > Same here: it is indeed avahi related (I invariably get a 169.254.7.253 > address) but AVAHI_DAEMON_DETECT_LOCAL=0 doesn't help. On my system it is not avahi related: I do not have this eth0:avahi address. However, I do get an IPv6 address via SLAAC on the affected system. My guess is that the fact that the fact that there is already an IP assigned to eth0 at the networkmanager start up, provokes this bug. After system start up, I then have an IPv6 address but not an IPv4 address and I have to switch to "Auto Ethernet" network in networkmanager to get an IPv4 address via DHCP in order to have a fully working network configuration. -- Frederik Himpe -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#745441: totem-plugins-dvb-daemon: Failed activating DVB DBUS service
Package: totem-plugins-dvb-daemon Version: 1:0.2.10-1 Severity: grave Tags: upstream patch Justification: renders package unusable When activating the DVB Daemon plug-in in Totem, this error pops up: Failed activating DVB DBus service 'NoneType' object has no attribute 'set_image' Traceback (most recent call last): File "/usr/lib/totem/plugins/dvb-daemon/dvb-daemon.py", line 680, in _on_group_loaded self._configure_mode() File "/usr/lib/totem/plugins/dvb-daemon/dvb-daemon.py", line 481, in _configure_mode self.single_group = self.channels[group_iter][self.channels.COL_GROUP] File "/usr/lib/python2.7/dist-packages/gi/overrides/Gtk.py", line 788, in __getitem__ aiter = self._getiter(key) File "/usr/lib/python2.7/dist-packages/gi/overrides/Gtk.py", line 776, in _getiter aiter = self.get_iter(key) File "/usr/lib/python2.7/dist-packages/gi/overrides/Gtk.py", line 810, in get_iter path = self._coerce_path(path) File "/usr/lib/python2.7/dist-packages/gi/overrides/Gtk.py", line 785, in _coerce_path return TreePath(path) File "/usr/lib/python2.7/dist-packages/gi/overrides/Gtk.py", line 1135, in __new__ path = ":".join(str(val) for val in path) TypeError: 'NoneType' object is not iterable DVB functionality is not working in Totem after that. This is upstream bug https://bugzilla.gnome.org/show_bug.cgi?id=709483 , which has a patch. -- System Information: Debian Release: jessie/sid APT prefers testing APT policy: (300, 'testing'), (200, 'unstable'), (102, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.13-1-amd64 (SMP w/4 CPU cores) Locale: LANG=en_GB.utf8, LC_CTYPE=en_GB.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages totem-plugins-dvb-daemon depends on: ii gir1.2-gtk-3.03.12.0-4 ii gir1.2-peas-1.0 1.8.1-2 ii gir1.2-totem-1.0 3.8.2-4+b1 ii gnome-dvb-client 1:0.2.10-1 ii gnome-dvb-daemon 1:0.2.10-1 ii python2.7.5-5 ii python-gobject3.12.1-1 ii totem 3.8.2-4+b1 ii totem-plugins 3.8.2-4+b1 totem-plugins-dvb-daemon recommends no packages. totem-plugins-dvb-daemon suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#644094: [Openjdk] Bug#644094: icedtea-plugin: Fails to load any java applet due to AccessControlException
On Tue, 2011-10-04 at 22:20 +0200, Damien Raude-Morvan wrote: > Hi Frederik, > > Thanks for this report. > > Le dimanche 02 octobre 2011 19:54:02, Frederik Himpe a écrit : > > icedtea-plugin fails to load any applet in Iceweasel 7. For example, > > http://java.com/en/download/testjava.jsp > > > > The console contains these errors: > > > > java version "1.6.0_23" > > OpenJDK Runtime Environment (IcedTea6 1.11pre) (6b23~pre9-2) > > OpenJDK 64-Bit Server VM (build 20.0-b11, mixed mode) > [...] > > Caused by: java.security.AccessControlException: access denied > > (java.lang.RuntimePermission accessClassInPackage.sun.security.util) > > Root cause of this exception is not into icedtea-plugin but in openjdk-6 > package. It has been fixed in 6b23~pre10-1 upload. > > Could you please retest with this release ? I'm closing this issue now, but > feel free to reopen if you can reproduce it with openjdk-6-jre >= 6b23~pre10-1 Correct, the new openjdk-6 package fixes this particular problem. I think that I discovered another problem though: applets only work when openjdk-6-jdk is installed, openjdk-6-jre does not seem to be enough. I will probably have to open a new report for this. -- Frederik Himpe -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#643304: stat output
On Mon, 2011-10-03 at 20:29 +0200, Jakub Wilk wrote: > * Frederik Himpe , 2011-10-03, 18:56: > > File: `/usr/lib/python2.6/dist-packages/awn/extras' -> > >`/usr/share/pyshared/awn/extras' > This symlink would explain the failed upgrade. It definitely shouldn't > be there. However, I see no evidence that the package created this > symlink in the past. > > Did you create the symlink manually, perhaps following the "advice" from > <http://bugs.debian.org/634684#10>? Yes, I think I indeed used this work-around to get everything working correctly. Thanks for the help! -- Frederik Himpe -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#643304: stat output
This package entered testing and so now I hit the same problem too on upgrade. Here is the requested stat output: # stat /usr/lib{,/python2.*{,/dist-packages{,/awn{,/extras /usr/share{,/pyshared{,/awn{,/extras}}} File: `/usr/lib' Size: 69632 Blocks: 144IO Block: 4096 directory Device: fe00h/65024dInode: 131117 Links: 196 Access: (0755/drwxr-xr-x) Uid: (0/root) Gid: (0/root) Access: 2010-12-19 16:45:15.790998058 +0100 Modify: 2011-10-03 18:48:27.937799058 +0200 Change: 2011-10-03 18:48:27.937799058 +0200 File: `/usr/lib/python2.5' Size: 20480 Blocks: 40 IO Block: 4096 directory Device: fe00h/65024dInode: 131730 Links: 3 Access: (0755/drwxr-xr-x) Uid: (0/root) Gid: (0/root) Access: 2010-04-13 19:54:41.0 +0200 Modify: 2011-06-09 19:36:02.780284780 +0200 Change: 2011-06-09 19:36:02.780284780 +0200 File: `/usr/lib/python2.6' Size: 20480 Blocks: 40 IO Block: 4096 directory Device: fe00h/65024dInode: 131727 Links: 23 Access: (0755/drwxr-xr-x) Uid: (0/root) Gid: (0/root) Access: 2010-04-13 19:54:41.0 +0200 Modify: 2011-07-28 10:10:52.100666493 +0200 Change: 2011-07-28 10:10:52.100666493 +0200 File: `/usr/lib/python2.7' Size: 16384 Blocks: 32 IO Block: 4096 directory Device: fe00h/65024dInode: 394873 Links: 26 Access: (0755/drwxr-xr-x) Uid: (0/root) Gid: (0/root) Access: 2011-03-20 10:29:00.0 +0100 Modify: 2011-09-30 22:47:57.633093136 +0200 Change: 2011-09-30 22:47:57.633093136 +0200 File: `/usr/lib/python2.6/dist-packages' Size: 4096Blocks: 8 IO Block: 4096 directory Device: fe00h/65024dInode: 131728 Links: 55 Access: (0755/drwxr-xr-x) Uid: (0/root) Gid: (0/root) Access: 2010-12-19 16:38:02.771616058 +0100 Modify: 2011-09-27 19:14:09.829108911 +0200 Change: 2011-09-27 19:14:09.829108911 +0200 File: `/usr/lib/python2.7/dist-packages' Size: 4096Blocks: 8 IO Block: 4096 directory Device: fe00h/65024dInode: 393810 Links: 53 Access: (0755/drwxr-xr-x) Uid: (0/root) Gid: (0/root) Access: 2011-04-01 18:56:22.0 +0200 Modify: 2011-10-03 18:51:11.057371625 +0200 Change: 2011-10-03 18:51:11.057371625 +0200 File: `/usr/lib/python2.6/dist-packages/awn' Size: 4096Blocks: 8 IO Block: 4096 directory Device: fe00h/65024dInode: 535944 Links: 2 Access: (0755/drwxr-xr-x) Uid: (0/root) Gid: (0/root) Access: 2011-07-28 10:03:18.0 +0200 Modify: 2011-07-28 13:55:02.645772817 +0200 Change: 2011-07-28 13:55:02.645772817 +0200 File: `/usr/lib/python2.6/dist-packages/awn/extras' -> `/usr/share/pyshared/awn/extras' Size: 30 Blocks: 0 IO Block: 4096 symbolic link Device: fe00h/65024dInode: 525513 Links: 1 Access: (0777/lrwxrwxrwx) Uid: (0/root) Gid: (0/root) Access: 2011-07-28 13:55:02.645772817 +0200 Modify: 2011-07-28 13:55:02.645772817 +0200 Change: 2011-07-28 13:55:02.645772817 +0200 File: `/usr/share' Size: 12288 Blocks: 24 IO Block: 4096 directory Device: fe00h/65024dInode: 131075 Links: 290 Access: (0755/drwxr-xr-x) Uid: (0/root) Gid: (0/root) Access: 2009-12-28 20:10:01.0 +0100 Modify: 2011-09-28 21:04:30.504316371 +0200 Change: 2011-09-28 21:04:30.504316371 +0200 File: `/usr/share/pyshared' Size: 4096Blocks: 8 IO Block: 4096 directory Device: fe00h/65024dInode: 271692 Links: 84 Access: (0755/drwxr-xr-x) Uid: (0/root) Gid: (0/root) Access: 2010-06-29 22:18:04.0 +0200 Modify: 2011-09-25 12:28:24.215021990 +0200 Change: 2011-09-25 12:28:24.215021990 +0200 File: `/usr/share/pyshared/awn' Size: 4096Blocks: 8 IO Block: 4096 directory Device: fe00h/65024dInode: 404570 Links: 3 Access: (0755/drwxr-xr-x) Uid: (0/root) Gid: (0/root) Access: 2010-06-29 23:55:47.0 +0200 Modify: 2011-07-28 10:03:41.682532169 +0200 Change: 2011-07-28 10:03:41.682532169 +0200 File: `/usr/share/pyshared/awn/extras' Size: 4096Blocks: 8 IO Block: 4096 directory Device: fe00h/65024dInode: 524994 Links: 2 Access: (0755/drwxr-xr-x) Uid: (0/root) Gid: (0/root) Access: 2010-07-29 15:42:35.0 +0200 Modify: 2011-10-03 18:51:11.057371625 +0200 Change: 2011-10-03 18:51:11.057371625 +0200 -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#644094: icedtea-plugin: Fails to load any java applet due to AccessControlException
Package: icedtea-plugin Version: 1.1.3-1 Severity: grave Justification: renders package unusable icedtea-plugin fails to load any applet in Iceweasel 7. For example, http://java.com/en/download/testjava.jsp The console contains these errors: java version "1.6.0_23" OpenJDK Runtime Environment (IcedTea6 1.11pre) (6b23~pre9-2) OpenJDK 64-Bit Server VM (build 20.0-b11, mixed mode) Exception in thread "main" java.lang.ExceptionInInitializerError at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:57) at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) at java.lang.reflect.Constructor.newInstance(Constructor.java:532) at sun.security.jca.ProviderConfig$3.run(ProviderConfig.java:262) at sun.security.jca.ProviderConfig$3.run(ProviderConfig.java:244) at java.security.AccessController.doPrivileged(Native Method) at sun.security.jca.ProviderConfig.doLoadProvider(ProviderConfig.java:244) at sun.security.jca.ProviderConfig.getProvider(ProviderConfig.java:224) at sun.security.jca.ProviderList.getProvider(ProviderList.java:232) at sun.security.jca.ProviderList.getService(ProviderList.java:330) at sun.security.jca.GetInstance.getInstance(GetInstance.java:157) at java.security.Security.getImpl(Security.java:696) at java.security.AlgorithmParameters.getInstance(AlgorithmParameters.java:130) at sun.security.x509.AlgorithmId.decodeParams(AlgorithmId.java:121) at sun.security.x509.AlgorithmId.(AlgorithmId.java:114) at sun.security.x509.AlgorithmId.parse(AlgorithmId.java:381) at sun.security.x509.X509Key.parse(X509Key.java:168) at sun.security.x509.CertificateX509Key.(CertificateX509Key.java:75) at sun.security.x509.X509CertInfo.parse(X509CertInfo.java:705) at sun.security.x509.X509CertInfo.(X509CertInfo.java:169) at sun.security.x509.X509CertImpl.parse(X509CertImpl.java:1747) at sun.security.x509.X509CertImpl.(X509CertImpl.java:196) at sun.security.provider.X509Factory.engineGenerateCertificate(X509Factory.java:107) at java.security.cert.CertificateFactory.generateCertificate(CertificateFactory.java:322) at sun.security.provider.JavaKeyStore.engineLoad(JavaKeyStore.java:763) at sun.security.provider.JavaKeyStore$JKS.engineLoad(JavaKeyStore.java:55) at java.security.KeyStore.load(KeyStore.java:1201) at net.sourceforge.jnlp.security.KeyStores.createKeyStoreFromFile(KeyStores.java:369) at net.sourceforge.jnlp.security.KeyStores.getKeyStore(KeyStores.java:135) at net.sourceforge.jnlp.security.KeyStores.getKeyStore(KeyStores.java:114) at net.sourceforge.jnlp.security.KeyStores.getCAKeyStores(KeyStores.java:191) at net.sourceforge.jnlp.security.VariableX509TrustManager.(VariableX509TrustManager.java:118) at net.sourceforge.jnlp.security.VariableX509TrustManager.getInstance(VariableX509TrustManager.java:407) at net.sourceforge.jnlp.runtime.JNLPRuntime.initialize(JNLPRuntime.java:224) at sun.applet.PluginAppletSecurityContext.(PluginAppletSecurityContext.java:245) at sun.applet.PluginMain.main(PluginMain.java:109) Caused by: java.security.AccessControlException: access denied (java.lang.RuntimePermission accessClassInPackage.sun.security.util) at java.security.AccessControlContext.checkPermission(AccessControlContext.java:393) at java.security.AccessController.checkPermission(AccessController.java:553) at java.lang.SecurityManager.checkPermission(SecurityManager.java:549) at net.sourceforge.jnlp.runtime.JNLPSecurityManager.checkPermission(JNLPSecurityManager.java:285) at java.lang.SecurityManager.checkPackageAccess(SecurityManager.java:1529) at java.lang.ClassLoader$1.run(ClassLoader.java:345) at java.security.AccessController.doPrivileged(Native Method) at java.lang.ClassLoader.checkPackageAccess(ClassLoader.java:343) at sun.security.pkcs11.SunPKCS11.(SunPKCS11.java:63) ... 37 more -- System Information: Debian Release: wheezy/sid APT prefers testing APT policy: (300, 'testing'), (200, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 3.0.0-1-amd64 (SMP w/2 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages icedtea-plugin depends on: ii icedtea-netx1.1.3-1 ii libatk1.0-0 2.0.1-2 ii libc6 2.13-21 ii libcairo2 1.10.2-6.1 ii libfontconfig1 2.8.0-3 ii libfreetype62.4.6-2 ii libgcc1 1:4.6.1-4 ii libgdk-pixbuf2.0-0 2.24.0-1 ii libglib2.0-02.28.6-1 ii libgtk2.0-0 2.24.4-3
Bug#633789: Please remove notify-osd dependency again
Please remove the notify-osd dependency again. With a recent gnome-notification-daemon, this is working fine again now without having notify-osd installed. The bug was fixed in notification-daemon 0.7.1-4: * Install autostart file for desktop environments which don't provide their own notification system as notification-daemon is no longer started on demand via dbus activation. -- Frederik Himpe -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#603544:
I would agree if there was at least a way to disable that migration. to work-around this bug. That migration is actually not even needed at this moment, so IMO it should even be disabled by default as long as it is not working completely for everybody. I will have to put the slapd package on hold on all my systems before upgrading to squeeze because of this bug. On the systems where I upgraded the slapd already, I'm holding of installing or upgrading any package, because on every package update, my slapd servers breaks. That's definitely not a nice thing for a released product, even if it does not happen for everyone. -- Frederik Himpe Vrije Universiteit Brussel -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#603544: [Pkg-openldap-devel] Bug#603544: rc bug?
On Wed, 2011-01-12 at 08:35 +0100, Matthijs Mohlmann wrote: > About fixing this: > Change the accesslog directory in the configuration to: > directory /var/lib/ldap-accesslog > > Create that directory and rerun the upgrade procedure. > > Regards, Yes, but IMO that 's only a work-around: slapd scripts should not break my working configuration. After moving the accesslog to another directory, I hit another problem: the migration fails when the back-up directory already exists: Setting up slapd (2.4.23-7) ... Backing up /etc/ldap/slapd.conf in /var/backups/slapd-2.4.11-1 +lenny2... done. Moving old database directories to /var/backups: Backup path /var/backups/cn=accesslog-2.4.11-1+lenny2.ldapdb exists. Giving up... dpkg: error processing slapd (--configure): subprocess installed post-installation script returned error exit status 1 After removing the back-ups in /var/backups and retrying, I get: Setting up slapd (2.4.23-7) ... Backing up /etc/ldap/slapd.conf in /var/backups/slapd-2.4.11-1 +lenny2... done. Moving old database directories to /var/backups: - directory dc=ai,dc=vub,dc=ac,dc=be... done. Loading from /var/backups/slapd-2.4.11-1+lenny2: - directory cn=accesslog... failed. Loading the database from the LDIF dump failed with the following error while running slapadd: /var/backups/slapd-2.4.11-1+lenny2/cn=accesslog.ldif: No such file or directory There is only a slapd.conf in that directory. slapd 2.4.23 in itself is working fine actually, it's just that migration script which continues to fail on every package installation and which leaves my slapd stopped. -- Frederik Himpe Vrije Universiteit Brussel -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#603544: [Pkg-openldap-devel] Bug#603544: rc bug?
On Tue, 2011-01-11 at 20:34 +0100, Matthijs Mohlmann wrote: > Do you have some more information from that server too ? Configuration ? > Because I changed the slapd.conf to use the new schema files, moved the > backup out of the way and did the upgrade and all went ok. $ dpkg -l slapd gosa-schema Desired=Unknown/Install/Remove/Purge/Hold | Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend |/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad) ||/ Name VersionDescription +++-==-==- ii gosa-schema2.6.11-2 LDAP schema for GOsa iF slapd 2.4.23-6 OpenLDAP server (slapd) Hmm, I'm getting something different now on this system: Preparing to replace slapd 2.4.23-6 (using .../slapd_2.4.23-7_amd64.deb) ... Stopping OpenLDAP: slapd. Unpacking replacement slapd ... Preparing to replace libldap-2.4-2 2.4.23-6 (using .../libldap-2.4-2_2.4.23-7_amd64.deb) ... Unpacking replacement libldap-2.4-2 ... Processing triggers for man-db ... Setting up libldap-2.4-2 (2.4.23-7) ... Setting up ldap-utils (2.4.23-7) ... Setting up slapd (2.4.23-7) ... Backing up /etc/ldap/slapd.conf in /var/backups/slapd-2.4.11-1 +lenny2... done. Moving old database directories to /var/backups: - directory cn=accesslog... done. - directory dc=ai,dc=vub,dc=ac,dc=be... done. Loading from /var/backups/slapd-2.4.11-1+lenny2: - directory cn=accesslog... cp: cannot create regular file `/var/lib/ldap/accesslog/': Is a directory dpkg: error processing slapd (--configure): subprocess installed post-installation script returned error exit status 1 And now /var/lib/ldap is totally empty! include /etc/ldap/schema/core.schema include /etc/ldap/schema/cosine.schema include /etc/ldap/schema/nis.schema include /etc/ldap/schema/inetorgperson.schema include /etc/ldap/schema/gosa/samba3.schema include /etc/ldap/schema/gosa/gosystem.schema include /etc/ldap/schema/gosa/gofon.schema include /etc/ldap/schema/gosa/goto.schema include /etc/ldap/schema/gosa/gofax.schema include /etc/ldap/schema/gosa/goserver.schema include /etc/ldap/schema/gosa/gosa-samba3.schema pidfile /var/run/slapd/slapd.pid argsfile/var/run/slapd/slapd.args loglevel0 modulepath /usr/lib/ldap moduleload back_hdb moduleload accesslog moduleload syncprov tool-threads 1 backend hdb databasehdb suffix cn=accesslog directory /var/lib/ldap/accesslog rootdn cn=accesslog index default eq index entryCSN,objectClass,reqEnd,reqResult,reqStart limits dn.exact="cn=replicator,dc=ai,dc=vub,dc=ac,dc=be" time.soft=unlimited time.hard=unlimited size.soft=unlimited size.hard=unlimited overlay syncprov syncprov-nopresent TRUE syncprov-reloadhint TRUE databasehdb cachesize 2000 idlcachesize 6000 suffix "dc=ai,dc=vub,dc=ac,dc=be" rootdn "cn=admin,dc=ai,dc=vub,dc=ac,dc=be" rootpw "{SSHA}XXX" directory "/var/lib/ldap" TLSCertificateFile /etc/ldap/slapdcert.pem TLSCertificateKeyFile /etc/ldap/slapdkey.pem dbconfig set_cachesize 0 25165824 0 dbconfig set_lk_max_objects 1500 dbconfig set_lk_max_locks 1500 dbconfig set_lk_max_lockers 1500 index objectClass,uidNumber,gidNumber eq index cn,sn,uid,displayName pres,sub,eq index memberUid,mail,givennameeq,subinitial index sambaSID,sambaPrimaryGroupSID,sambaDomainName eq index gosaMailAlternateAddresseq index entryCSN eq index entryUUID eq overlay syncprov syncprov-nopresent TRUE syncprov-reloadhint TRUE syncprov-checkpoint 100 10 syncprov-sessionlog 100 limits dn.exact="cn=replicator,dc=ai,dc=vub,dc=ac,dc=be" time.soft=unlimited time.hard=unlimited size.soft=unlimited size.hard=unlimited overlay accesslog logdb cn=accesslog logops writes logsuccess TRUE logpurge 07+00:00 01+00:00 limits dn.exact="cn=replicator,dc=ai,dc=vub,dc=ac,dc=be" time.soft=unlimited time.hard=unlimited size.soft=unlimited size.hard=unlimited lastmod on checkpoint 512 30 access to * by dn.base="cn=replicator,dc=ai,dc=vub,dc=ac,dc=be" read by * break access to attrs=userPassword,shadowLastChange,sambaLMPassword,sambaNTPassword,goImapPassword by anonymous auth by self write by * none access to dn.base="" by * read access to * by * read -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#603544: [Pkg-openldap-devel] Bug#603544: rc bug?
On Tue, 2011-01-11 at 20:01 +0100, Matthijs Mohlmann wrote: > I already planned to work on this one this weekend, but I got sick. (bad > timing) > > I just checked your configuration file. Do you have the correct schema > files configured in /etc/ldap/slapd.conf ? > [...] > Notice the extra directory here, some left-over of the previous package? You are right. But it should not have any influence on this bug: on another server where I am using the schemas in /etc/ldap/schema/gosa/ provided by the gosa-schema package, the same bug happens. -- Frederik Himpe -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#609358: telepathy-butterfly: does not work with papyon 0.5.4
Package: telepathy-butterfly Version: 0.5.14-1 Severity: grave Justification: renders package unusable Since papyon in experimental was updated from 0.5.2 to 0.5.4, empathy 2.30 from Squeeze does not show my MSN contacts anymore. This bug can be found in empathy's debug logs: tp_contact_list_got_added_members_cb: Error: org.freedesktop.DBus.Python.AttributeError: Traceback (most recent call last): File "/usr/lib/pymodules/python2.6/dbus/service.py", line 702, in _message_cb retval = candidate_method(self, *args, **keywords) File "/usr/lib/python2.6/dist-packages/butterfly/contacts.py", line 98, in GetContactAttributes results = functions[interface](handles) File "/usr/lib/python2.6/dist-packages/butterfly/contacts.py", line 79, in lambda x: self.GetAliases(x).items(), File "/usr/lib/python2.6/dist-packages/butterfly/aliasing.py", line 57, in GetAliases result[contact] = self._get_alias(contact) File "/usr/lib/python2.6/dist-packages/butterfly/aliasing.py", line 133, in _get_alias alias = contact.infos.get(ContactGeneral.ANNOTATIONS, {}).\ AttributeError: 'Profile' object has no attribute 'infos' I guess butterfly needs to be updated to new version 0.5.15 to make it compatible with the new papyon. -- System Information: Debian Release: 6.0 APT prefers testing APT policy: (300, 'testing'), (200, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 2.6.37-rc7-amd64 (SMP w/2 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages telepathy-butterfly depends on: ii python2.6.6-3+squeeze4 interactive high-level object-orie ii python-central0.6.16+nmu1register and build utility for Pyt ii python-dbus 0.83.1-1 simple interprocess messaging syst ii python-gobject2.21.4+is.2.21.3-1 Python bindings for the GObject li ii python-papyon 0.5.4-1MSN client library written in Pyth ii python-telepathy 0.15.17-1 Python language bindings for telep Versions of packages telepathy-butterfly recommends: ii python-libproxy 0.3.1-2automatic proxy configuration mana telepathy-butterfly suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org