Bug#704953: Crash recovery crashes everytime, cannot start anymore
Package: epiphany-browser-webkit2 Version: 3.7.91-1 Severity: serious After crashing with pages open, now trying to start crashes again everytime. Below is a backtrace after starting under gdb with debug symbols installed. Thread 10 (Thread 0x7fff933ec700 (LWP 2083)): #0 0x745f3165 in sqlite3BtreeSetCachedRowid (iRowid=0, pCur=optimized out) at sqlite3.c:53784 #1 sqlite3VdbeExec (p=p@entry=0x7fff7c013998) at sqlite3.c:4378 #2 0x745d8911 in sqlite3Step (p=0x7fff7c013998) at sqlite3.c:64047 #3 sqlite3_step (pStmt=0x7fff7c013998) at sqlite3.c:64120 #4 sqlite3_step (pStmt=0x7fff7c013998) at sqlite3.c:64108 #5 0x00491365 in ephy_sqlite_statement_step (self=self@entry=0x17de150, error=error@entry=0x7fff933ebb88) at /home/kov/debian/epiphany/build-area/epiphany-browser-3.7.91/./lib/ephy-sqlite-statement.c:177 #6 0x00485218 in ephy_history_service_find_url_rows (self=optimized out, query=optimized out) at /home/kov/debian/epiphany/build-area/epiphany-browser-3.7.91/./lib/history/ephy-history-service-urls-table.c:352 #7 0x00481409 in ephy_history_service_execute_query_urls (self=optimized out, query=optimized out, result=0x19d84c0) at /home/kov/debian/epiphany/build-area/epiphany-browser-3.7.91/./lib/history/ephy-history-service.c:740 #8 0x00481d1a in ephy_history_service_process_message (message=0x19d84a0, self=0x17ccc00) at /home/kov/debian/epiphany/build-area/epiphany-browser-3.7.91/./lib/history/ephy-history-service.c:1230 #9 run_history_service_thread (self=0x17ccc00) at /home/kov/debian/epiphany/build-area/epiphany-browser-3.7.91/./lib/history/ephy-history-service.c:469 #10 0x7256fa05 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0 #11 0x71cc1e0e in start_thread (arg=0x7fff933ec700) at pthread_create.c:311 #12 0x719f594d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:113 Thread 9 (Thread 0x7fff8b7fe700 (LWP 2082)): #0 pthread_cond_wait@@GLIBC_2.3.2 () at ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:185 #1 0x75d7dc0b in WebCore::IconDatabase::syncThreadMainLoop() () at ../Source/WebCore/loader/icon/IconDatabase.cpp:1463 #2 0x75d7de28 in WebCore::IconDatabase::iconDatabaseSyncThread() () at ../Source/WebCore/loader/icon/IconDatabase.cpp:1058 #3 0x7078f191 in WTF::wtfThreadEntryPoint(void*) () at ../Source/WTF/wtf/ThreadingPthreads.cpp:196 #4 0x71cc1e0e in start_thread (arg=0x7fff8b7fe700) at pthread_create.c:311 #5 0x719f594d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:113 Thread 8 (Thread 0x7fff8bfff700 (LWP 2081)): #0 pthread_cond_timedwait@@GLIBC_2.3.2 () at ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_timedwait.S:238 #1 0x7258b605 in g_cond_wait_until () from /lib/x86_64-linux-gnu/libglib-2.0.so.0 #2 0x725216f1 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0 #3 0x7257014a in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0 #4 0x7256fa05 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0 #5 0x71cc1e0e in start_thread (arg=0x7fff8bfff700) at pthread_create.c:311 #6 0x719f594d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:113 Thread 7 (Thread 0x7fff93bed700 (LWP 2079)): #0 0x719ea1ad in poll () at ../sysdeps/unix/syscall-template.S:81 #1 0x7254bdac in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0 #2 0x7254c28a in g_main_loop_run () from /lib/x86_64-linux-gnu/libglib-2.0.so.0 #3 0x7078f191 in WTF::wtfThreadEntryPoint(void*) () at ../Source/WTF/wtf/ThreadingPthreads.cpp:196 #4 0x71cc1e0e in start_thread (arg=0x7fff93bed700) at pthread_create.c:311 #5 0x719f594d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:113 Thread 6 (Thread 0x7fffe1371700 (LWP 2078)): #0 0x719ea1ad in poll () at ../sysdeps/unix/syscall-template.S:81 #1 0x7254bdac in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0 #2 0x7254c28a in g_main_loop_run () from /lib/x86_64-linux-gnu/libglib-2.0.so.0 #3 0x7078f191 in WTF::wtfThreadEntryPoint(void*) () at ../Source/WTF/wtf/ThreadingPthreads.cpp:196 #4 0x71cc1e0e in start_thread (arg=0x7fffe1371700) at pthread_create.c:311 #5 0x719f594d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:113 Thread 5 (Thread 0x7fffe1b72700 (LWP 2077)): #0 0x719ea1ad in poll () at ../sysdeps/unix/syscall-template.S:81 #1 0x7254bdac in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0 #2 0x7254c28a in g_main_loop_run () from /lib/x86_64-linux-gnu/libglib-2.0.so.0 #3 0x72b23d76 in ?? () from /usr/lib/x86_64-linux-gnu/libgio-2.0.so.0 #4 0x7256fa05 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0 #5 0x71cc1e0e in start_thread (arg=0x7fffe1b72700) at pthread_create.c:311 #6 0x719f594d in clone () at
Bug#388141: Handling the copyright mess of the website
David Prévot da...@tilapin.org writes: I don't know what would be the best approach for future contributors (i.e. I don't know if we'll need to ask them explicitly for their consent, or if a page on our website would be enough), but for current and past contributors, we need their consent. We could contact every current contributor, and ask them if they are OK to: - grant copyright of their future contributions to SPI; - grant copyright of their past contributions to SPI. I believe that copyright transfers are wrong path. Neither other contributions to Debian project require copyright assignments and also there does not seem to be consensus that copyright could be even transferred without paper as in dead trees involved. Also, discussions during many years in #388141 seems to indicate that not even all Debian developers would be willing to assign copyright. IMHO, your strategy works just fine if the request is instead only for a license change. It can be a generic statement from authors such as any future license change by Debian project leader decision or just giving list of licenses as options. Anyway this work can be started with by writing this wml::debian::copyright tag, and start filling pages with that information about authors. After there is list of authors, it is also easier to request permissions to either license change or copyright assignment. AFAIK, currently there isn't full list of all authors to website. Together with author information per page, I think we should add e.g. copyright.txt to CVS root directory which contains information per author, which relicensing are fine, or possible copyright transfer to SPI. -- Tommi Vainikainen -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#581202: libpcre3 8.02-1 change breaks O'Caml bindings
Hi,
I analyzed this bug a bit, and it seems clear where the bug is. However,
I don't know what is the best way to fix that.
In libpcre3 8.02 pcre_config option MATCH_LIMIT and
MATCH_LIMIT_RECURSION take a long integer pointer as where parameter,
but instead in older pcre those take a integer pointer. (see pcreapi.3
function pcre_config and parameter MATCH_LIMIT, and implementation in
pcre_config.c.)
In pcre-ocaml binding package there is following stub code:
/* Generic stub for getting integer results from pcre_config */
static inline int pcre_config_int(int what)
{
int ret;
pcre_config(what, (void *) ret);
return ret;
}
Obviously casting pointer to ret to (unsigned long int *), and writing
to that causes out of bounds write.
And this is fixed in pcre-ocaml package version 6 in testing and
unstable, and only causes problem with stable's pcre-ocaml version 5
packages.
--
Tommi Vainikainen
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#577465: gnus: please remove emacs22 from the package dependencies
severity 577465 minor thanks Rob Browning r...@defaultvalue.org writes: If so, please adjust the package so that it can build and operate correctly when emacs22 is not available. Alternately, please schedule this package for removal from unstable/testing. We are planning to remove emacs22 for the upcoming squeeze release. The gnus package can be used also with xemacs21, and the xemacs package contains actually older gnus version than in the gnus package making this useful for xemacs users. (This version of gnus is not useful for emacs23 users, therefore it does not list generic emacsen dependency, and also dependencies should not be just replaced with emacs23.) I've explicitly listed emacs22 (and it still has also emacs21...) as supported emacs versions together with xemacs21, but it does not prevent removing emacs22 from squeeze. (Assuming that xemacs21 stays in squeeze; it entered testing yesterday.) I'll remove those references after emacs22 has been removed from the archive. -- Tommi Vainikainen -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#532271: Cleanup code to rarian-compat's postinst
tags 532271 +patch thanks It was a bit unclear to me in what conditions scrollkeeper leaves this cruft as it sounds to be related to installation state of xml-core package also, so I was not able to re-produce this on live. However this patch adds to rarian-compat's postinst a code that removes scrollkeeper's registered XML catalog in those cases (as suggested by Josselin Mouette already on 15 June 2009). I've added version check against last configured rarian-compat so that this code is evaluated only once as that should be sufficient in all cases. This version check assumes next version as NMU (but I'm not, at least yet, DD, so I'm not able to upload this; I've just prepared NMU to my AM), but if not NMUed then rarian-compat.postinst version number should be adjusted based on real upload version number. diff -urN rarian-0.8.1.original//debian/changelog rarian-0.8.1/debian/changelog --- rarian-0.8.1.original//debian/changelog 2010-03-03 16:20:09.0 +0200 +++ rarian-0.8.1/debian/changelog 2010-03-03 15:30:39.0 +0200 @@ -1,3 +1,11 @@ +rarian (0.8.1-4.1) unstable; urgency=low + + * Non-maintainer upload. + * Clean-up old scrollkeeper's XML catalog so that rarian-compat can +register its own catalog. Closes: #532271. + + -- Tommi Vainikainen thv+deb...@iki.fi Wed, 03 Mar 2010 15:23:45 +0200 + rarian (0.8.1-4) unstable; urgency=low * Build a dummy scrollkeeper package to facilitate upgrades. diff -urN rarian-0.8.1.original//debian/rarian-compat.postinst rarian-0.8.1/debian/rarian-compat.postinst --- rarian-0.8.1.original//debian/rarian-compat.postinst 1970-01-01 02:00:00.0 +0200 +++ rarian-0.8.1/debian/rarian-compat.postinst 2010-03-03 15:34:20.0 +0200 @@ -0,0 +1,9 @@ +#!/bin/sh +set -e + +# In some cases old scrollkeeper left over its catalog. See #532271. +if [ $1 = configure ] dpkg --compare-versions $2 lt 0.8.1-4.1; then + update-xmlcatalog --del --type uri --id http://scrollkeeper.sourceforge.net/dtds/scrollkeeper-omf-1.0/; --package scrollkeeper /dev/null 2/dev/null || true +fi + +#DEBHELPER# -- Tommi Vainikainen
Bug#570504: Acknowledgement (ERROR: No module named configobj)
notfound 570504 2.3 thanks This issue seems to be already fixed in version 2.3 in experimental. -- Tommi Vainikainen -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#570504: ERROR: No module named configobj
Package: bzr-builddeb Version: 2.2 Severity: grave bzr builddeb fails with ERROR: No module named configobj and cannot do anything. dpkg --status shows that python-configobj is installed even if not listed as dependency. $ bzr builddeb bzr: ERROR: No module named configobj You may need to install this Python library separately. -- System Information: Debian Release: squeeze/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 2.6.31-1-amd64 (SMP w/2 CPU cores) Locale: LANG=fi_FI.UTF-8, LC_CTYPE=fi_FI.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages bzr-builddeb depends on: ii bzr 2.1.0-1 easy to use distributed version co ii bzrtools 2.1.0-2 Collection of tools for bzr ii devscripts 2.10.61 scripts to make the life of a Debi ii dpkg-dev 1.15.5.6Debian package development tools ii fakeroot 1.14.4-1Gives a fake root environment ii patchutils 0.3.1-2 Utilities to work with patches ii pristine-tar 1.01regenerate pristine tarballs ii python 2.5.4-9 An interactive high-level object-o ii python-apt 0.7.93.1Python interface to libapt-pkg ii python-central 0.6.14+nmu2 register and build utility for Pyt ii python-debian0.1.14 Python modules to work with Debian Versions of packages bzr-builddeb recommends: pn python-launchpadlib none (no description available) Versions of packages bzr-builddeb suggests: ii bzr-svn 1.0.2-2Bazaar plugin providing Subversion -- 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#552891: fakechroot: FTBFS: ../../src/libfakechroot.c:2622: error: conflicting types for 'scandir'
scandir (const char *dir, struct dirent ***namelist, SCANDIR_TYPE_ARG3, SCANDIR_TYPE_ARG4)
{
char *fakechroot_path, *fakechroot_ptr, fakechroot_buf[FAKECHROOT_MAXPATH];
expand_chroot_path(dir, fakechroot_path, fakechroot_ptr, fakechroot_buf);
@@ -2631,7 +2631,7 @@
#ifdef HAVE_SCANDIR64
/* #include dirent.h */
-int scandir64 (const char *dir, struct dirent64 ***namelist, int(*filter)(const struct dirent64 *), int(*compar)(const void *, const void *))
+int scandir64 (const char *dir, struct dirent64 ***namelist, int(*filter)(const struct dirent64 *), SCANDIR64_TYPE_ARG4)
{
char *fakechroot_path, *fakechroot_ptr, fakechroot_buf[FAKECHROOT_MAXPATH];
expand_chroot_path(dir, fakechroot_path, fakechroot_ptr, fakechroot_buf);
--
Tommi Vainikainen
Bug#332782: My contribution to release notes
I allow that my contribution to the Debian GNU/Linux release notes can be distributed under any DFSG-free license. -- Tommi Vainikainen pgpTXeunxMlMI.pgp Description: PGP signature
Bug#337607: initramfs-tools: Boot scripts tries to use evms_activate (and mdrun?), which isn't inside initrd.img
Package: initramfs-tools Version: 0.38 Severity: grave Inside generated initrd.img /scripts/local-top/evms script tries to execute /sbin/evms_activate. I don't use evms and I don't have evms files installed on my computer, and probably related to this fact, initrd.img does not contain /sbin/evms_activate and therefore booting fails. Same is true with /scripts/local-top/md. Maybe same is true with LVM, but vgchange gets installed to my initrd.img correctly because I've lvm tools installed. -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.12-1-amd64-k8 Locale: LANG=fi_FI.UTF-8, LC_CTYPE=fi_FI.UTF-8 (charmap=UTF-8) Versions of packages initramfs-tools depends on: ii busybox 1:1.01-3 Tiny utilities for small and embed ii cpio 2.6-9 GNU cpio -- a program to manage ar ii klibc-utils 1.1.1-2small statically-linked utilities ii mklibs-copy 0.1.18 Shared library reduction script ii udev 0.071-1/dev/ and hotplug management daemo initramfs-tools recommends no packages. -- no debconf information Added by hand: ii lvm2 2.01.14-3 The Linux Logical Volume Manager -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#238245: Debian website's copyright and license suggestions?
Hello members of debian-legal, It isn't currently well known that Debian website's license is Open Publication License, which has been judged to be non-free, and therefore needs to be changed. Currently web pages are Copyright © 1997-2005 SPI and license terms linking to Open Publication license are available at URL: http://www.de.debian.org/license . However SPI has not been collecting any paper work to transfer copyrights like FSF does, and probably many contributors do not even know about that their work is automatically copyrighted by SPI. So basically there is two questions: Does missing paperwork create a problem? And what would be good license for Debians web pages? (This is about content, the scripts used in generation are GNU GPL or otherwise freely licensed.) Because copyright is currently claimed by SPI Inc, and SPI's board meeting is coming rather soon, I brought this issue to SPI's secretarys attention, but SPI board would appreciate some suggestion what they should decide about license change. I've Cc'ed the bug report about the issue, but Mail-followups does not contain bug report. Add it if needed, please. -- Tommi Vainikainen
Bug#257531: Removing irssi-snapshot from Debian archives?
Hi David and others, currently irssi-snapshot package has version number 0.8.6+cvs.20031114-1. Debian archives also contain package irssi-text with version number 0.8.9(-3.1) which is clearly much newer than irssi-snapshot. Also a bug report about outdateness of irssi-snapshot have been open more than a year ago (reported Sun, 4 Jul 2004 03:40:21 +0200). So my suggestion would be to remove irssi-snapshot from archives, but I'd like to get some input about this issue from the maintainer -- that's you David Pashley. Could you please reassign this bug report to ftp.debian.org, so that ftp maintainers can remove this package? Or do you have some other plans to fix this bug, David? -- Tommi Vainikainen pgp1Nh7ggt20u.pgp Description: PGP signature
