Bug#704280: Fails to import photos from Galaxy Nexus
Package: gphoto2 Version: 2.4.14-1 Severity: normal Tags: upstream shotwell, importing pictures from a Galaxy Nexus via gphoto2, is super slow and fails to import some pictures properly with messages like this: (tracker-miner-fs:4042): Tracker-WARNING **: Got extraction DBus error on 'file:///home/daniel/Pictures/2012/08/18/IMG_20120818_193354_3.jpg': GDBus.Error:org.freedesktop.DBus.Error.NoReply: Message did not receive a reply (timeout by message bus) (tracker-miner-fs:4042): Tracker-WARNING **: Got second extraction DBus error on 'file:///home/daniel/Pictures/2012/08/18/IMG_20120818_193354_3.jpg'. Adding only non-embedded metadata to the SparQL, the error was: GDBus.Error:org.gtk.GDBus.UnmappedGError.Quark._TrackerDBus.Code0: Could not get any metadata for uri:'file:///home/daniel/Pictures/2012/08/18/IMG_20120818_193354_3.jpg' and mime:'image/jpeg' According to other bugs filed on this issue, the problem is in upstream gphoto2 and has been fixed in release 2.5. For instance, see: http://redmine.yorba.org/issues/5566 (upstream) https://bugs.launchpad.net/ubuntu/+source/shotwell/+bug/1025598 (ubuntu) Thanks, Daniel -- System Information: Debian Release: 7.0 APT prefers testing-updates APT policy: (500, 'testing-updates'), (500, 'testing'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.2.0-4-amd64 (SMP w/8 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages gphoto2 depends on: ii libc6 2.13-38 ii libcdk5 5.0.20060507-4 ii libexif12 0.6.20-3 ii libgphoto2-2 2.4.14-2 ii libgphoto2-port0 2.4.14-2 ii libncurses5 5.9-10 ii libpopt0 1.16-7 ii libreadline6 6.2+dfsg-0.1 gphoto2 recommends no packages. Versions of packages gphoto2 suggests: pn gthumb none ii gtkam 0.1.18-1 -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#631676: Incompatible with libgtest-dev = 1.6.0; fixed in new upstream
Package: google-mock Version: 1.5.0-2 Severity: serious Tags: unstable google-mock version 1.5 is incompatible with libgtest-dev version 1.6 (currently in Debian): attempting to compile the attached program (which does nothing but include mock.h) results in screenfuls of errors along the lines of /usr/include/gmock/internal/gmock-port.h:133:8: error: redefinition of ‘struct testing::internal::CompileAssertanonymous ’ /usr/include/gtest/internal/gtest-port.h:696:8: error: previous definition of ‘struct testing::internal::CompileAssertanonymous ’ I think the best option is to upgrade to gmock 1.6. If this is typical of gmock's policy on compatibility, maybe it would also be good to tighten the versioned dependency on gtest? Daniel -- System Information: Debian Release: wheezy/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 2.6.39-2-amd64 (SMP w/8 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages google-mock depends on: ii libc6 2.13-7 Embedded GNU C Library: Shared lib ii libgcc1 1:4.6.0-14 GCC support library ii libgtest-dev 1.6.0-1Google's framework for writing C++ ii libgtest0 1.5.0-3Google's framework for writing C++ ii libstdc++64.6.0-14 GNU Standard C++ Library v3 ii python2.6.6-14 interactive high-level object-orie google-mock recommends no packages. google-mock suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#622715: aptitude does not give any idea which package is responsible for a library removal
On Thu, Apr 14, 2011 at 11:40:22AM +0530, shirish शिरीष shirisha...@gmail.com was heard to say: *** Please type your report below this line *** I have seen this many a time and more so now when I am trying to upgrade from stable to testing. What happens is many a time there is a library which is being removed and there is no hint as to which package is the one responsible for the library being removed. Sometimes you do get hints when the package names are similar, but many a times not. Also sometimes the package names may be similar but they may be a part of a series of packages and its hard to figure out which is the one responsible. I do not claim to know the answer but one way perhaps could be say if library 'stable' is being removed due to changes in package 'sid' it could show as library 'stable being removed:'sid' This would atleast indicate which package is the one responsible and then one can download the changelog and see what changes have made library 'stable' reduntant. Maybe fixed upstream, or merged within package 'sid' or no longer needed whatever the reason, atleast I know this is due to package 'sid' . Assuming you're working at the command-line, does it help if you pass -W? Daniel -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#622719: aptitude forgets automatically installed state on package upgrade selection
On Thu, Apr 14, 2011 at 08:18:49AM +0100, Gabor Nagy linu...@freemail.hu was heard to say: When in the list of upgradable packages I select a package or a package group for upgrade, aptitude forgets that the package (or all automatically installed packages in the group) was automatically installed I preferred the old behaviour when the package was upgraded, and aptitude kept the automatically installed flag. Odd, nothing changed on my end. Probably the apt guys changed their behavior in some incompatible way. Daniel -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#623609: aptitude: Aptitude crashes with SIGSEGV on start
On Thu, Apr 21, 2011 at 02:22:11PM -0500, Nik Johnson nikjohnso...@gmail.com was heard to say: After installing lbzip2 aptitude crashed with SIGSEGV when returning to the menu. SIGSEGV's at start now. GDB reports it at: pkgDepCache::Update(OpProgress*) () from /usr/lib/libapt-pkg.so.4.10A Could you install aptitude-dbg and get another backtrace with gdb? Thanks, Daniel -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#622719: aptitude forgets automatically installed state on package upgrade selection
This changed in revision 2085.1.1 of apt. rantFer crying out loud, if I had the time I'd just ditch their handling of the auto flag and do it myself/rant. What's especially frustrating is that they tried to accommodate aptitude, but they didn't understand what they were doing. Guess it's really my fault for not keeping up on this stuff. I guess that as a workaround (ew) I can save the auto flag before I call MarkInstall and restore it afterwards. Daniel -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#588089: Workaround
So, there are two bugs here: (1) aptitude crashes if you input a ?term pattern and apt-xapian-index isn't installed. (2) aptitude treats the string ~ as ?term(~), even though all other bare strings are treated as ?name patterns. The first one is a little subtle to fix, because I need to decide what the right behavior is. Should ?term degenerate to ?name+?description without Xapian installed? Should it match nothing? Should it throw a search error? If I try (again) to make bare strings equivalent to ?term, how does that impact this decision? The second issue, on the other hand, is not subtle at all to fix, and will solve the major problem. A patch will be in git shortly. Furthermore, this implies a very simple workaround: when typing search queries in aptitude, use the long form of patterns (~n = ?name, etc). Daniel -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#620556: fo output is incorrect for segmented lists with more than one segtitle
Package: docbook-xsl
Version: 1.75.2+dfsg-5
Severity: normal
Tags: patch
Docbook segmented lists are lists in which each element has one or
more segments. For instance, a synopsis of commands might look like
this:
Name: ls
Usage: ls [options] PATH ...
Description: List directory contents or file information
The FO output template for docbook appears to generate tabular output
in this case, with one column per segment. However, it is hardcoded to
generate two fo:table-column definitions regardless of the number of
segments. This results in errors when the resulting .fo file is
processed with fop.
The attached patch to fo/lists.xsl fixes this for me.
Daniel
-- System Information:
Debian Release: wheezy/sid
APT prefers unstable
APT policy: (500, 'unstable'), (500, 'testing')
Architecture: amd64 (x86_64)
Kernel: Linux 2.6.38-2-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Versions of packages docbook-xsl depends on:
ii xml-core 0.13 XML infrastructure and XML catalog
Versions of packages docbook-xsl recommends:
ii docbook-xml 4.5-7 standard XML documentation system
ii docbook-xsl-doc-html [docbook 1.75.2-1 stylesheets for processing DocBook
Versions of packages docbook-xsl suggests:
pn dbtoepub none (no description available)
pn docbook-xsl-saxon none (no description available)
ii fop 1:0.95.dfsg-11 XML to PDF Translator
ii libsaxon-java 1:6.5.5-7 Saxon XSLT Processor
ii libxalan2-java2.7.1-5XSL Transformations (XSLT) process
pn xalan none (no description available)
-- no debconf information
--- lists.xsl.orig 2011-04-02 10:37:12.497221731 -0700
+++ lists.xsl 2011-04-02 10:46:08.050175221 -0700
@@ -1195,8 +1195,9 @@
xsl:template match=segmentedlist mode=seglist-table
xsl:apply-templates select=title mode=list.title.mode /
fo:table
-fo:table-column column-number=1
column-width=proportional-column-width(1)/
-fo:table-column column-number=2
column-width=proportional-column-width(1)/
+xsl:call-template name=segmentedlist.table.columns
+ xsl:with-param name=cols select=count(segtitle)/
+/xsl:call-template
fo:table-header start-indent=0pt end-indent=0pt
fo:table-row
xsl:apply-templates select=segtitle mode=seglist-table/
@@ -1208,6 +1209,20 @@
/fo:table
/xsl:template
+xsl:template name=segmentedlist.table.columns
+ xsl:param name=cols select=1/
+ xsl:param name=curcol select=1/
+
+ fo:table-column column-number={$curcol}
+ column-width=proportional-column-width(1)/
+ xsl:if test=$curcol lt; $cols
+xsl:call-template name=segmentedlist.table.columns
+ xsl:with-param name=cols select=$cols/
+ xsl:with-param name=curcol select=$curcol+1/
+/xsl:call-template
+ /xsl:if
+/xsl:template
+
xsl:template match=segtitle mode=seglist-table
fo:table-cell
fo:block font-weight=bold
Bug#612034: vulnerability: rewrite arbitrary user file
The immediate problem should be fixed with 4a021fb5d4963d4e0756fcc182223b05939062d6. Unfortunately, I'm not sure that I can cut a security release before the weekend (it'll take some time and I'm still decobwebbing my dev box). Anyone who wants to cut a security NMU that cherry-picks the above SHA, please feel free to do so. Still to do: audit the hierarchy editor for other bugs (I wrote this ages ago when I was much stupider :) ) and sanity-check other users of get_homedir and other parts of the hierarchy code. (alternatively to the last, rip the hierarchy code out by its roots) Daniel -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#612034: vulnerability: rewrite arbitrary user file
On Fri, Feb 04, 2011 at 04:53:54PM -0800, Kees Cook k...@debian.org was heard
to say:
Package: aptitude
Version: 0.6.3-3.2ubuntu1
Severity: grave
Tags: security
Justification: user security hole
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu natty
This bug report was also filed in Ubuntu and can be found at
http://launchpad.net/bugs/607264
The description, from segooon, follows:
Binary package hint: aptitude
Hi, I've just discovered that aptitude is vulnerable to rewriting any user
(maybe root) file:
bool hier_editor::handle_key(const cw::config::key k)
if(homedir.empty())
{
cfgfile = /tmp/function_pkgs;
}
save_hier(cfgfile);
Here attacker can create link to any file in the system that user may write
to. If process has no $HOME set, this file would be overwritten.
It is rare that $HOME is null, but it such rare case it is vulnerable.
Ew. That seems like something we should not do. (at least it tells
you that it just clobbered something random :-/ ) Should be an easy
fix. Actually, I'm tempted to just nuke this from orbit -- does anyone
actually use the hierarchy editor? It seemed like a good idea when I
was a lot younger and more optimistic than I am now...
Daniel
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#588691: aptitude: Aptitude has shortened output in recent versions
On Sun, Jul 11, 2010 at 10:56:34AM +0200, Nico Haase deb...@nicohaase.de was heard to say: In Version 0.6.1.5-3 (which was the latest I ran from unstable before 0.6.3-2), all of the progress aptitude did was shown. Now, this output is shown for little time and disappears. I will provide the output in a response to this report soon. This was a deliberate change; aptitude was always outputting the same lines of text at the top and the bottom of the display, and it made it difficult to read the important messages. You can get the old behavior back by setting Aptitude::Cmdline::Progress::Retain-Completed to true, and you can get the old formatting back by setting Aptitude::Cmdline::Progress::Percent-On-Right to true. I also preserved the old output format when output is sent to a pipe, in case people were parsing the output from scripts. Does the new progress bar fail to work for you in some way? This seems to be the improvement wished in #569516, which now is the default state. Ah, I forgot there was a request for this filed. I'll go close it. Daniel -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#407524: aptitude: Unmanaged exception while proceeding for install or upgrade
On Tue, Jun 29, 2010 at 12:56:06AM +0200, Daniele Giglio gigli...@gmail.com was heard to say: When proceeding in the install/upgrade procedure (press the 'G' key) aptitude crashes whit the following message: Uncaught exception: ui.cc:1389: void auto_fix_broken(): Assertion resman-resolver_exists() failed. Is this reproducible, or did it just happen to you one time? Daniel -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#531315: aptitude seems to use hidden processes, rendering HIDS systems like unhide nearly useless
On Thu, Jul 01, 2010 at 12:07:41AM +0200, Christoph Anton Mitterer christoph.anton.mitte...@physik.uni-muenchen.de was heard to say: Years later ^^ (forgot that issue sorry). Me too. I'll reassign this to unhide -- I think it's agreed that it belongs over there and not in aptitude? Daniel -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#588608: aptitude (priority important) depends on libboost-iostreams (priority optional)
On Sat, Jul 10, 2010 at 05:06:54PM +0930, Ron r...@debian.org was heard to say: Serious as per policy 2.5 Guess we'd better increase the priority of iostreams, then. Daniel -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#587339: Add -2 option to copy usernames and/or passwords to the clipboard twice.
On Sun, Jun 27, 2010 at 07:29:50PM -0400, Benj. Mako Hill m...@atdot.cc was
heard to say:
quote who=Daniel Burrows date=Sun, Jun 27, 2010 at 08:52:16AM -0700
The Chrome browser appears to read the X clipboard twice when you
paste a value, throwing away the first value it read. This makes it
difficult to use pwsafe with it. Obviously a fix in the browser is
ideal, but it would be nice in the meantime if pwsafe could get a -2
option that would copy each value to the clipboard twice (and I suspect
this patch is a lot easier to write and get applied than a patch for
Chrome).
I have a patch for this worked up, but I'll need to clear it with my
employer before I can send it to you.
Wonderful! Thanks I'll hold off on forwarding this upstream until I hear back
about the patch.
OK, I've got a go-ahead; here's the patch.
Daniel
--- pwsafe.1.in.orig 2010-06-27 08:47:04.553650031 -0700
+++ pwsafe.1.in 2010-06-27 08:47:36.207490149 -0700
@@ -97,6 +97,9 @@
.B \-x, \-\-xclip
Force copying of username and password to X clipboard. This is selected by default if $DISPLAY is set.
.TP
+.B \-2, \-\-twice
+If the X clipboard is used, copy each element twice. This is useful to work against some clients (such as Google Chrome) which read from the clipboard twice.
+.TP
.B \-d, \-\-display=XDISPLAY
Override $DISPLAY. Implies \-\-xclip.
.TP
--- pwsafe.cpp.orig 2010-06-27 08:47:00.273928161 -0700
+++ pwsafe.cpp 2010-06-27 08:47:28.870872943 -0700
@@ -398,6 +398,7 @@
bool arg_username = false;
bool arg_password = false;
bool arg_details = false;
+bool twice = false;
int arg_verbose = 0;
int arg_debug = 0;
#ifndef X_DISPLAY_MISSING
@@ -440,6 +441,7 @@
{display, required_argument, 0,'d'},
{selection, required_argument, 0,'s'},
{ignore, required_argument, 0,'G'},
+ {twice, no_argument, 0, '2'},
#endif
// standard stuff
{quiet, no_argument, 0, 'q'},
@@ -1159,6 +1161,7 @@
int c;
while ((c = getopt_long (argc, argv,
+ 2 // post username/password to the clipboard twice
l // long listing
a // add
e // edit
@@ -1308,6 +1311,9 @@
case 'h':
usage(false);
throw ExitEx(0);
+ case '2':
+twice = true;
+break;
case ':':
case '?':
// the message getopt() printed out is good enough
@@ -1343,6 +1349,7 @@
-d, --display=XDISPLAY override $DISPLAY (implies -x)\n
-s, --selection={Primary,Secondary,Clipboard,Both} select the X selection effected (implies -x)\n
-G, --ignore=n...@host add n...@host to set of windows that don't receive the selection. Either NAME or @HOST can be omitted. (default is xclipboard, wmcliphist and klipper)\n
+ -2, --twicecopy each value to the X selection twice\n
#endif
-q, --quietprint no extra information\n
-v, --verbose print more information (can be repeated)\n
@@ -2655,9 +2662,13 @@
// this way if the notes contain a URL, the user can cut/paste that too
emit_notes(e.notes);
+const int times = (!arg_echo twice) ? 2 : 1;
+
if (username)
- ::emit(e.groupname(), username, e.default_login?e.the_default_login:e.login);
+ for(int i = 0; i times; ++i)
+::emit(e.groupname(), username, e.default_login?e.the_default_login:e.login);
if (password)
+ for(int i = 0; i times; ++i)
::emit(e.groupname(), password, e.password);
if (arg_echo arg_details)
Bug#587339: Add -2 option to copy usernames and/or passwords to the clipboard twice.
Package: pwsafe Version: 0.2.0-3.0~dburrows Severity: wishlist The Chrome browser appears to read the X clipboard twice when you paste a value, throwing away the first value it read. This makes it difficult to use pwsafe with it. Obviously a fix in the browser is ideal, but it would be nice in the meantime if pwsafe could get a -2 option that would copy each value to the clipboard twice (and I suspect this patch is a lot easier to write and get applied than a patch for Chrome). I have a patch for this worked up, but I'll need to clear it with my employer before I can send it to you. Daniel -- System Information: Debian Release: squeeze/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 2.6.32-3-amd64 (SMP w/8 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages pwsafe depends on: ii libc6 2.11.2-2 Embedded GNU C Library: Shared lib ii libgcc1 1:4.4.4-6 GCC support library ii libice6 2:1.0.6-1 X11 Inter-Client Exchange library ii libncurses5 5.7+20100313-2 shared libraries for terminal hand ii libreadline6 6.1-3 GNU readline and history libraries ii libsm62:1.1.1-1 X11 Session Management library ii libssl0.9.8 0.9.8o-1 SSL shared libraries ii libstdc++64.4.4-6The GNU Standard C++ Library v3 ii libx11-6 2:1.3.3-3 X11 client-side library ii libxmu6 2:1.0.5-1 X11 miscellaneous utility library pwsafe recommends no packages. pwsafe suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#587087: aptitude: Internal error: found 2 (choice - promotion) mappings for a single choice.
On Thu, Jun 24, 2010 at 11:35:15PM -0700, Josh Triplett j...@joshtriplett.org was heard to say: I ran aptitude, and saw a handful of packages to upgrade, including glibc packages. I hit + on libc-bin, and several copies of the message Internal error: found 2 (choice - promotion) mappings for a single choice. appeared near the cursor (ignoring the curses display). More appeared if I marked/unmarked libc packages for upgrade. I've saved a state bundle (46MB bzipped). Let me know if part or all of that would help. Yeah, send it along and I'll see what I can do. Daniel -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#586622: E: Opening configuration file /usr/share/aptitude/aptitude-defaults.pt_BR
Version: 0.6.3-2 On Mon, Jun 21, 2010 at 12:35:37AM -0300, Nelson A. de Oliveira nao...@debian.org was heard to say: With the last version of aptitude and using pt_BR.UTF-8 as my locale, I see this for everything that I do with aptitude: # aptitude update E: Abrindo arquivo de configuração /usr/share/aptitude/aptitude-defaults.pt_BR - ifstream::ifstream (2: Arquivo ou diretório não encontrado) (...) Translation is something like: E: Opening configuration file /usr/share/aptitude/aptitude-defaults.pt_BR - ifstream::ifstream (2: File or directory not found) Should be fixed in 0.6.3-2. Daniel -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#576635: Acknowledgement (Unable to access an encrypted root partition after a failed resume)
I finally got around to looking at the image I took. The encryption seems to be perfectly fine: there's a LUKS header in the block device, and I can open it up using cryptsetup. The trouble seems to be that it's not recognized as a physical LVM volume. Comparing it to a working physical volume, I notice that the working volume starts off with 0x200 NULs, then LABELONE followed by LVM2 001, 32 random alphanumeric characters, and then some binary data, followed by lots of NULs. At 0x1004, the working volume contains the string LVM2 x[5A%r0N* followed by a bit more binary data; at 0x1200, there's what appears to be a volume group configuration. On the broken volume, LABELONE and the first occurrence of LVM2 001 are missing. However, I do see LVM2 x[5A%r0N* at 0x1004 and what appears to be volume group configuration at 0x1200. My hunch is that the physical volume's information is still present, but the magic strings that LVM uses to recognize it as a physical volume have gone missing. It almost looks like the first 4096 (0x1000) bytes of the partition were overwritten with garbage. I might be able to recover everything if I can just create a correct PV header at the front of the device. Is there any documentation on what the format of a PV header is? I couldn't find anything online. Also, any suggestions about how to identify the culprit that was responsible for the overwrite? The first few lines of the hexdump are: ff ff ff ff ff ff ff ff 00 00 00 00 00 00 00 00 || * 0020 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 || * 0040 08 00 00 00 04 00 00 00 e1 7a 54 3f f6 28 5c 3f |.zT?.(\?| 0050 80 30 4f f5 ae 7f 00 00 10 00 00 00 04 00 00 00 |.0O.| 0060 9a 99 59 3f ae 47 61 3f 80 30 4f f5 ae 7f 00 00 |..Y?.Ga?.0O.| 0070 20 00 00 00 04 00 00 00 c1 ca 61 3f c3 f5 68 3f | .a?..h?| 0080 80 30 4f f5 ae 7f 00 00 30 00 00 00 08 00 00 00 |.0O.0...| 0090 b8 1e 65 3f 83 c0 6a 3f 90 30 4f f5 ae 7f 00 00 |..e?..j?.0O.| 00a0 40 00 00 00 08 00 00 00 a8 c6 6b 3f d7 a3 70 3f |@.k?..p?| It repeats like that for several pages. I did find some references to the --restorefile option to pvcreate; it sounds like I could maybe recover the physical volume using that option, assuming that the metadata I extracted from the volume is correct. I've saved the first megabyte of the unencrypted device in its broken state for future reference, in case it's useful for diagnosing what happened. Daniel -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#586511: Bug#586508: Error on startup: missing /usr/share/aptitude/aptitude-defaults.?? files
It looks like the problem is that I switched to using separated build directories in the Debian packaging (so that parallel builds work), but some of the Makefiles pick up their data relative to . instead of $(srcdir). Easy to fix. Daniel -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#581706: boost/lambda/construct.hpp is missing a #include of boost/type_traits.hpp
Package: libboost1.42-dev Version: 1.42.0-3 Severity: normal This file doesn't compile with g++ -c: --- cut here --- #include boost/lambda/construct.hpp --- cut here --- I get these errors: /usr/include/boost/lambda/construct.hpp: In static member function ‘static void boost::lambda::detail::destructor_helperIsPointer::exec(A1)’: /usr/include/boost/lambda/construct.hpp:98: error: ‘remove_cv’ in namespace ‘boost’ does not name a type /usr/include/boost/lambda/construct.hpp:98: error: expected unqualified-id before ‘’ token /usr/include/boost/lambda/construct.hpp: In static member function ‘static void boost::lambda::detail::destructor_helpertrue::exec(A1*)’: /usr/include/boost/lambda/construct.hpp:108: error: ‘remove_cv’ in namespace ‘boost’ does not name a type /usr/include/boost/lambda/construct.hpp:108: error: expected unqualified-id before ‘’ token /usr/include/boost/lambda/construct.hpp: In member function ‘void boost::lambda::destructor::operator()(A1) const’: /usr/include/boost/lambda/construct.hpp:122: error: ‘remove_cv’ in namespace ‘boost’ does not name a type /usr/include/boost/lambda/construct.hpp:122: error: expected unqualified-id before ‘’ token /usr/include/boost/lambda/construct.hpp:123: error: ‘is_pointer’ is not a member of ‘boost’ /usr/include/boost/lambda/construct.hpp:123: error: ‘is_pointer’ is not a member of ‘boost’ /usr/include/boost/lambda/construct.hpp:123: error: ‘plainA1’ was not declared in this scope /usr/include/boost/lambda/construct.hpp:123: error: template argument 1 is invalid /usr/include/boost/lambda/construct.hpp:123: error: expected initializer before ‘’ token Note the references to an undefined name boost::remove_cv. This is defined over in the type traits stuff, so I tried this and it worked: --- cut here --- #include boost/type_traits.hpp #include boost/lambda/construct.hpp --- cut here --- Probably the #include should be added to construct.hpp. Daniel -- System Information: Debian Release: squeeze/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 2.6.32-3-amd64 (SMP w/8 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages libboost1.42-dev depends on: ii libc6 2.10.2-7 Embedded GNU C Library: Shared lib ii libgcc1 1:4.4.4-1 GCC support library ii libicu42 4.2.1-3International Components for Unico ii libstdc++64.4.4-1The GNU Standard C++ Library v3 ii libstdc++6-4.4-dev [libstdc++ 4.4.4-1The GNU Standard C++ Library v3 (d libboost1.42-dev recommends no packages. Versions of packages libboost1.42-dev suggests: pn default-jdknone(no description available) ii docbook-xml4.5-7 standard XML documentation system ii docbook-xsl1.75.2+dfsg-5 stylesheets for processing DocBook pn doxygennone(no description available) pn fopnone(no description available) pn libboost-date-time1.42-dev none(no description available) pn libboost-filesystem1.42-de none(no description available) pn libboost-graph-parallel1.4 none(no description available) pn libboost-graph1.42-dev none(no description available) ii libboost-iostreams1.42-dev 1.42.0-3 Boost.Iostreams Library developmen pn libboost-math1.42-dev none(no description available) pn libboost-mpi1.42-dev none(no description available) pn libboost-program-options1. none(no description available) ii libboost-python1.42-dev1.42.0-3 Boost.Python Library development f ii libboost-regex1.42-dev 1.42.0-3 regular expression library for C++ ii libboost-serialization1.42 1.42.0-3 serialization library for C++ pn libboost-signals1.42-dev none(no description available) pn libboost-system1.42-devnone(no description available) ii libboost-test1.42-dev 1.42.0-3 components for writing and executi pn libboost-thread1.42-devnone(no description available) pn libboost-wave1.42-dev none(no description available) ii libboost1.42-doc 1.42.0-3 Boost.org libraries documentation ii xsltproc 1.1.26-3 XSLT command line processor -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#578930: aptitude: Aptitude looks awful if LANG=en_US.UTF-8
On Fri, Apr 23, 2010 at 01:55:21PM -0400, Nathanael Nerode nero...@gcc.gnu.org was heard to say: Aptitude appears to have some hardcoded dependencies on the locale. Given this, it really needs to force the locale before starting. I have to start it up with LANG=C aptitude in order to keep the screen readable; otherwise I get lots of nonsense characters. In the long run, it should probably be properly UNICODE-ized. So, do you have any more information about this? What's actually happening, what locale the terminal was running in, which terminal you were using, etc... Thanks, Daniel -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#580085: aptitude: FTBFS on s390 (test failures)
I looked into this a bit today and I don't see how it can be happening.
The code in question is basically doing this, if you rip out some STL
and de-factor it:
int where = idx;
try
{
if(isspace(s[idx]))
++idx;
else
throw ParseException();
}
catch(ParseException )
{
if(where != idx)
throw;
}
Is there an s390 machine I could run a debugger on? If not, I'll
probably have to do an upload that annotates this code with obnoxious
amounts of logging :(
Daniel
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#579756: In the resolver command-line help, warn the user that installing and upgrading will toast their resolver session.
Package: aptitude Version: 0.6.2-1 Severity: minor For technical reasons, installing or removing packages while solving dependencies will reset the resolver, returning to its first solution and discarding the user's carefully chosen rejects and approvals. aptitude offers the ability to do this from the command-line resolver prompt as a convenience, but the on-line help (? at the prompt) should warn them what the consequences are. Daniel -- Package-specific info: aptitude 0.6.2 compiled at Apr 18 2010 17:06:25 Compiler: g++ 4.4.3 Compiled against: apt version 4.8.0 NCurses version 5.7 libsigc++ version: 2.2.4.2 Ept support enabled. Gtk+ version 2.20.0 Gtk-- version 2.20.2 Current library versions: NCurses version: ncurses 5.7.20100313 cwidget version: 0.5.16 Apt version: 4.8.0 linux-gate.so.1 = (0xb78ce000) libapt-pkg-libc6.9-6.so.4.8 = /usr/lib/libapt-pkg-libc6.9-6.so.4.8 (0xb77ea000) libncursesw.so.5 = /lib/libncursesw.so.5 (0xb77a4000) liblog4cxx.so.10 = /usr/lib/liblog4cxx.so.10 (0xb75fd000) libsigc-2.0.so.0 = /usr/lib/libsigc-2.0.so.0 (0xb75f7000) libcwidget.so.3 = /usr/lib/libcwidget.so.3 (0xb7537000) libept.so.0 = /usr/lib/libept.so.0 (0xb74c4000) libxapian.so.15 = /usr/lib/libxapian.so.15 (0xb7376000) libz.so.1 = /usr/lib/libz.so.1 (0xb7362000) libsqlite3.so.0 = /usr/lib/libsqlite3.so.0 (0xb72dd000) libboost_iostreams.so.1.40.0 = /usr/lib/libboost_iostreams.so.1.40.0 (0xb72d2000) libglibmm-2.4.so.1 = /usr/lib/libglibmm-2.4.so.1 (0xb727a000) libgobject-2.0.so.0 = /usr/lib/libgobject-2.0.so.0 (0xb723c000) libgthread-2.0.so.0 = /usr/lib/libgthread-2.0.so.0 (0xb7237000) librt.so.1 = /lib/i686/cmov/librt.so.1 (0xb722d000) libglib-2.0.so.0 = /lib/libglib-2.0.so.0 (0xb7164000) libgtkmm-2.4.so.1 = /usr/lib/libgtkmm-2.4.so.1 (0xb6e0a000) libatkmm-1.6.so.1 = /usr/lib/libatkmm-1.6.so.1 (0xb6dc5000) libgdkmm-2.4.so.1 = /usr/lib/libgdkmm-2.4.so.1 (0xb6d7c000) libgiomm-2.4.so.1 = /usr/lib/libgiomm-2.4.so.1 (0xb6cd9000) libpangomm-1.4.so.1 = /usr/lib/libpangomm-1.4.so.1 (0xb6cab000) libgtk-x11-2.0.so.0 = /usr/lib/libgtk-x11-2.0.so.0 (0xb68d8000) libcairomm-1.0.so.1 = /usr/lib/libcairomm-1.0.so.1 (0xb68b8000) libgdk-x11-2.0.so.0 = /usr/lib/libgdk-x11-2.0.so.0 (0xb6822000) libatk-1.0.so.0 = /usr/lib/libatk-1.0.so.0 (0xb6806000) libpangoft2-1.0.so.0 = /usr/lib/libpangoft2-1.0.so.0 (0xb67e) libgdk_pixbuf-2.0.so.0 = /usr/lib/libgdk_pixbuf-2.0.so.0 (0xb67c7000) libpangocairo-1.0.so.0 = /usr/lib/libpangocairo-1.0.so.0 (0xb67bc000) libcairo.so.2 = /usr/lib/libcairo.so.2 (0xb6744000) libgio-2.0.so.0 = /usr/lib/libgio-2.0.so.0 (0xb66a8000) libpango-1.0.so.0 = /usr/lib/libpango-1.0.so.0 (0xb6663000) libfreetype.so.6 = /usr/lib/libfreetype.so.6 (0xb65ec000) libfontconfig.so.1 = /usr/lib/libfontconfig.so.1 (0xb65bd000) libgmodule-2.0.so.0 = /usr/lib/libgmodule-2.0.so.0 (0xb65b9000) libglademm-2.4.so.1 = /usr/lib/libglademm-2.4.so.1 (0xb65af000) libglade-2.0.so.0 = /usr/lib/libglade-2.0.so.0 (0xb6597000) libxml2.so.2 = /usr/lib/libxml2.so.2 (0xb646e000) libm.so.6 = /lib/i686/cmov/libm.so.6 (0xb6448000) libvte.so.9 = /usr/lib/libvte.so.9 (0xb63ba000) libpthread.so.0 = /lib/i686/cmov/libpthread.so.0 (0xb63a1000) libstdc++.so.6 = /usr/lib/libstdc++.so.6 (0xb62ac000) libgcc_s.so.1 = /lib/libgcc_s.so.1 (0xb628e000) libc.so.6 = /lib/i686/cmov/libc.so.6 (0xb6147000) libutil.so.1 = /lib/i686/cmov/libutil.so.1 (0xb6143000) libdl.so.2 = /lib/i686/cmov/libdl.so.2 (0xb613f000) libaprutil-1.so.0 = /usr/lib/libaprutil-1.so.0 (0xb611f000) libdb-4.8.so = /usr/lib/libdb-4.8.so (0xb5fb8000) libapr-1.so.0 = /usr/lib/libapr-1.so.0 (0xb5f8a000) libbz2.so.1.0 = /lib/libbz2.so.1.0 (0xb5f79000) libpcre.so.3 = /lib/libpcre.so.3 (0xb5f49000) /lib/ld-linux.so.2 (0xb78cf000) libpng12.so.0 = /lib/libpng12.so.0 (0xb5f24000) libXrender.so.1 = /usr/lib/libXrender.so.1 (0xb5f1b000) libX11.so.6 = /usr/lib/libX11.so.6 (0xb5dfe000) libXcomposite.so.1 = /usr/lib/libXcomposite.so.1 (0xb5dfb000) libXdamage.so.1 = /usr/lib/libXdamage.so.1 (0xb5df7000) libXfixes.so.3 = /usr/lib/libXfixes.so.3 (0xb5df2000) libXext.so.6 = /usr/lib/libXext.so.6 (0xb5de3000) libXinerama.so.1 = /usr/lib/libXinerama.so.1 (0xb5de) libXi.so.6 = /usr/lib/libXi.so.6 (0xb5dd3000) libXrandr.so.2 = /usr/lib/libXrandr.so.2 (0xb5dcb000) libXcursor.so.1 = /usr/lib/libXcursor.so.1 (0xb5dc2000) libpixman-1.so.0 = /usr/lib/libpixman-1.so.0 (0xb5d69000) libdirectfb-1.2.so.0 = /usr/lib/libdirectfb-1.2.so.0 (0xb5cf4000) libfusion-1.2.so.0 =
Bug#579384: Acknowledgement (How to trick my Debian in thinking that a package is not installed)
So, it turns out this is surprisingly tricky. The problem is that the aptitude initialization process runs a mark-and-sweep before the whole package system is ready. That seems very dicey to me, but the comments seem to indicate that it's necessary to force apt to behave properly with auto flags when aptitude loads its sticky settings. But until the sticky settings are loaded, I don't know what's held on the system. This whole bit of the code needs to be examined, I think. Which means this is a deeper change than it should be. :( Daniel -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#574956: same problem on another machine
On Wed, Apr 28, 2010 at 11:34:49PM -0400, Celejar cele...@gmail.com was heard to say: FWIW, I just installed the package on another Sid machine, and the problem appears there, too. OK, I looked through the logs for this bug, and it sounds like an apt problem (since apt-get does the same thing). I'll reassign it over there. Daniel -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#579603: aptitude: ?archive(now) matches all installed or removed (not purged) packages
On Thu, Apr 29, 2010 at 12:49:03AM +0100, Stuart Prescott stuart+deb...@nanonanonano.net was heard to say: aptitude search '?archive(now)' matches all packages that are in installed or removed (not purged) states. Naturally, aptitude search '?archive(foobar)' matches 0 packages and aptitude search '?archive(stable)' matches (most) of the packages on this machine (not backports.org etc). So it seems that now is a special, undocumented value for the archive match. I can't see that now would have any use and (as below) it makes life a little harder than it should be to do things. The string now actually comes directly from apt. I could filter it in search patterns (it's already filtered in various parts of the UI), but I know that people use the aptitude command-line in scripts, and making now no longer match anything would be a backwards-incompatible change. So, +wontfix on that. I'm not sure if that means this needs the wontfix flag -- it sounds like you'd be happy to have some other way of doing the same thing. (you might ask who would use this feature, but I've been amazed at some of the other stuff people depended on) As for the rest of your report, I think that you want a ?downloadable pattern that would apply on a per-version basis, right? I don't think there's really a way to get at that information via the current set of patterns, so a new one would make sense. (it's similar to making ?obsolete check per version, but doesn't break backwards compatibility) Another option would be to implement an idea I've had for a while, to more fully support more types in the search language. So you'd have something like: ?has-version(?has-archive(?not(?archive(now Daniel -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#525508: closed by Eckhart Wörner ewoer...@kde.org ()
Sorry, I lost a few emails four weeks ago. Anyway, I'm assuming you wanted me to check if this still happens? I don't see it in konsole any more. I do actually see the bug with my test program in gnome-terminal...go figure. Daniel -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#579384: How to trick my Debian in thinking that a package is not installed
Package: aptitude Version: 0.6.2.1-2 aptitude's resolver will *still* upgrade held packages, due to an interaction between the dependency solver and unused package removal. Unused packages are removed before dependencies get solved, and sometimes the dependency solver has to put a package back at a newer version. Removing a package clears its hold flag, so when it comes back it doesn't have one. Specifically, this seems to happen with exact versioned dependencies. For instance, mono-runtime depends on mono-gac (= $BINARY_VERSION). So upgrading mono-runtime without mono-gac will cause mono-gac to be removed, then dependency resolution kicks in and realizes that we need mono-gac in order to keep mono-runtime. A temporary solution for you is to cancel the auto flag on any package you hold. Long-term solutions in the code could include postponing dependency resolution until after the resolver finishes (which could have wide-ranging implications), refusing to remove unused held packages, and somehow remembering the held flag on packages that were removed because they were unused. Of these three solutions, I prefer the second one, refusing to remove unused held packages. It fits in with the intuitive meaning of hold, it's easy to implement, and it doesn't have a high risk of surprising side-effects, since it only affects a fairly precisely defined set of packages. Essentially, it causes held packages to be added to the root set (and that's the best implementation, I think: modify aptitude's custom root set function to include held packages). Daniel -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#579073: add an option that tells aptitude to never _clear_ the A (automatically installed) flag
On Sun, Apr 25, 2010 at 02:53:06AM +0200, Christoph Anton Mitterer cales...@scientia.net was heard to say: It would be really nice to have a config option which tells aptitude to never _clear_ the A flag of packages. I mean even if there are no packages which depend/recommend/suggest/etc. the respective package. It may of course _set_ the flag. The reason is that it's often handy to manually mark packages with the A flag which are not depended/recommended/suggested/etc. but still should have the A flag. I really don't understand what you're asking for. The A flag says remove this package when nothing uses it. You want to have packages that aren't installed and that nothing depends on, but are still automatically installed? (automatically installed for what?) Or are you just looking for a way to put Aptitude::DeleteUnused=false in /etc/apt/apt.conf or ~/.aptitude? (hint: use a text editor ;-) ) Puzzled, Daniel -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#579071: aptitude: Recommends-Important and Suggests-Important do not work
On Sun, Apr 25, 2010 at 02:45:52AM +0200, Christoph Anton Mitterer cales...@scientia.net was heard to say: It seems that Apt::AutoRemove::Recommends-Important and Apt::AutoRemove::Suggests-Important do not work. I've observed many many different cases, where aptitude _clears_ the A flag (and wants to remove the respective packages, if that is configured) even though there are still non-A-packages which suggest or recommend the respective packages. Could you provide a concrete example? It might help if you added --log-level=aptitude.apt.cache:debug --log-file=aptitude.log to the command-line and attached aptitude.log to your report, although I'm not sure this particular problem will show up in the debug log. Thanks, Daniel -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#579337: Please expand the documentation of custom Deciders.
Package: scons Version: 1.2.0.d20100117-1 Severity: wishlist Tags: upstream The documentation of Custom deciders gives as an example a situation where you want to check only part of a file (e.g., to ignore a date stamp). Unfortunately, *how* to do this is not documented anywhere. The example that purports to document this is: def decide_if_changed(dependency, target, prev_ni): if self.get_timestamp() != prev_ni.timestamp: dep = str(dependency) tgt = str(target) if specific_part_of_file_has_changed(dep, tgt): return True return False The problem is that it's unclear how to implement specific_part_of_file_has_changed. I don't have access to the old file any more (obviously), and there isn't any (documented) way to, e.g., store an md5sum of just part of the file. So it seems to me that specific_part_of_file_has_changed must be relying on some functionality in SCons that isn't documented anywhere. Daniel -- System Information: Debian Release: squeeze/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: i386 (i686) Kernel: Linux 2.6.32-2-686 (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages scons depends on: ii python2.5.4-9An interactive high-level object-o ii python-support1.0.6.1automated rebuilding support for P scons recommends no packages. scons suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#578930: aptitude: Aptitude looks awful if LANG=en_US.UTF-8
On Fri, Apr 23, 2010 at 01:55:21PM -0400, Nathanael Nerode nero...@gcc.gnu.org was heard to say: Aptitude appears to have some hardcoded dependencies on the locale. Given this, it really needs to force the locale before starting. I have to start it up with LANG=C aptitude in order to keep the screen readable; otherwise I get lots of nonsense characters. In the long run, it should probably be properly UNICODE-ized. Like Jens said, we really need more explanation. Doubly so since aptitude uses wide characters internally and converts to/from the system locale when reading input and displaying text, and has done so for nearly five years. Which terminal are you using? If you start a new instance of your terminal from your terminal prompt, does it have the same problem? Be aware that with gnome-terminal, you need to pass --disable-factory for this to work. If I start a gnome-terminal in the C locale: $ LANG=C gnome-terminal --disable-factory then I get the attached output from aptitude (which thinks it's running in a UTF-8 locale). Please note the difference between the locale in which *the terminal* runs and the locale in which *the program inside the terminal* runs: some combinations of login scripts can conspire to cause your terminals to be started in a different locales from the shells inside those terminals. The easiest way to fix this is to export your locale settings in .xsession before you start up the session. Daniel attachment: aptitude-bad-unicode.png
Bug#576278: Not as silly as it looks
moo should never crash; it just prints a bunch of stuff and exits. It really shouldn't crash sporadically. And in fact it doesn't. Based on core dumps, the crash is clearly happening due to something in log4cxx. Here thread 2 is the one that actually crashed. Thread 2 (Thread 13246): #0 0xb75f21ca in ?? () from /usr/lib/libsigc-2.0.so.0 #1 0xb75f2827 in sigc::signal_base::~signal_base() () from /usr/lib/libsigc-2.0.so.0 #2 0xb616f828 in __cxa_finalize (d=0xb75ef644) at cxa_finalize.c:56 #3 0xb75586a4 in __do_global_dtors_aux () from /usr/lib/libcwidget.so.3 #4 0xb75cfbe0 in _fini () from /usr/lib/libcwidget.so.3 #5 0xb78d6bab in _dl_fini () at dl-fini.c:248 #6 0xb616f481 in __run_exit_handlers (status=0, listp=0xb6283324, run_list_atexit=true) at exit.c:78 #7 0xb616f4df in *__GI_exit (status=0) at exit.c:100 #8 0xb6156b5d in __libc_start_main (main=0x8073bd0 main, argc=3, ubp_av=0xbf894824, init=0x8365920 __libc_csu_init, fini=0x8365910 __libc_csu_fini, rtld_fini=0xb78d69b0 _dl_fini, stack_end=0xbf89481c) at libc-start.c:254 #9 0x080729d1 in _start () Thread 1 (Thread 13247): #0 0xb5f9b092 in ?? () from /usr/lib/libapr-1.so.0 #1 0xb5f9ba90 in apr_pool_create_ex () from /usr/lib/libapr-1.so.0 #2 0xb77088a8 in log4cxx::helpers::Pool::Pool() () from /usr/lib/liblog4cxx.so.10 #3 0xb7732652 in log4cxx::helpers::ThreadLocal::ThreadLocal() () from /usr/lib/liblog4cxx.so.10 #4 0xb7731e22 in log4cxx::helpers::Thread::getThreadLocal() () from /usr/lib/liblog4cxx.so.10 #5 0xb7732072 in log4cxx::helpers::Thread::launcher(apr_thread_t*, void*) () from /usr/lib/liblog4cxx.so.10 #6 0xb5fa9985 in ?? () from /usr/lib/libapr-1.so.0 #7 0xb63a0585 in start_thread (arg=0xb58e8b70) at pthread_create.c:300 #8 0xb620f29e in clone () at ../sysdeps/unix/sysv/linux/i386/clone.S:130 My guess is that log4cxx isn't destroying its background threads early enough. The -vvv probably has some effect on timing, and I bet the i386/amd64 difference is also a timing thing. Since this is a bug that could affect other parts of the program, I'm promoting it to normal priority. Daniel -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#578412: aptitude: [Display customization] %t escape not complying with the formatting rule
I think the problem is that while there's a syntax to turn autoexpansion of a column *on*, there isn't a syntax to turn it *off*. %t is autoexpanded by default, so no matter what you do, it will eat all the available space. You can see that aptitude is at least reading the width information by combining %t with some other autoexpanding column (like %p, for instance). Daniel -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#578504: aptitude update mentions rred in its progess information. Shouldn't that be read?
On Tue, Apr 20, 2010 at 02:13:44PM +0200, Regid Ichira gl2n30y06a...@hotmail.com was heard to say: aptitude update prints progress information to the screen. Within that information, it mention rred. Shouldn't that meant to be read? I *think* you're saying that you think that it should print read and not rred? In that case: no, it prints rred because it's running rred to patch Package files. I'm not sure I understand your bug report, though, so please confirm that this is what you meant before I close it. Thanks, Daniel -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#578344: Segmentation fault with aptitude full-upgrade
I'm preparing an upload for this now. Daniel -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#576318: aptitude segfaults on invoking changelog under certain circumstanses
Version: 0.6.2-1 This should have been closed by 0.6.2-1, but I typed the wrong bug number. :( Daniel -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#576634: live-helper: Try to guess the user's preferred mirror from sources.list.
Package: live-helper
Version: 2.0~a9-1
Severity: normal
Tags: patch
I noticed that live-helper defaults to using a mirror in Germany. It seems
like
it would be better to use the same mirror that the user's system is taking its
packages from. Obviously we can't know that in general (well, except for
copying
sources.list, but that has its own issues), but in the common case, Debian
systems
get their apt sources from a mirror that looks like this:
deb http://http.XX.debian.org/debian(... more stuff)
I suggest just taking the first such line from sources.list and using it to
determine the mirror, and I've attached a patch (admittedly a bit ugly, but it
should illustrate what I mean) that uses grep and sed to acheive this goal.
Daniel
-- Package-specific info:
-- System Information:
Debian Release: squeeze/sid
APT prefers unstable
APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)
Kernel: Linux 2.6.32-3-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Versions of packages live-helper depends on:
ii debootstrap 1.0.22 Bootstrap a basic Debian system
Versions of packages live-helper recommends:
ii cpio 2.11-1 GNU cpio -- a program to manage ar
ii gettext-base 0.17-10GNU Internationalization utilities
Versions of packages live-helper suggests:
ii dosfstools 3.0.9-1 utilities for making and checking
ii fakeroot 1.14.4-1 Gives a fake root environment
ii genisoimage9:1.1.10-1Creates ISO-9660 CD-ROM filesystem
pn memtest86+ | memtest86 none(no description available)
ii mtools 4.0.12-1 Tools for manipulating MSDOS files
ii parted 2.2-3 The GNU Parted disk partition resi
pn squashfs-tools | genext2fs none(no description available)
ii sudo 1.7.2p5-1 Provide limited super user privile
ii syslinux 2:3.86+dfsg-1 utilities for the syslinux bootloa
pn uuid-runtime none(no description available)
pn win32-loader none(no description available)
-- no debconf information
--- defaults.sh.orig 2010-03-12 07:19:52.0 -0800
+++ defaults.sh 2010-04-05 20:19:43.325448780 -0700
@@ -7,6 +7,18 @@
# This is free software, and you are welcome to redistribute it
# under certain conditions; see COPYING for details.
+# Read /etc/apt/sources.list and grab the first line of the form
+#
+# deb http://http.XX.debian.org/debian/
+#
+# to guess what the user's preferred Debian mirror is.
+infer_main_mirror_from_apt_sources()
+{
+(egrep -m1 '^\s*deb\s*(http|ftp)://(http|ftp)\.[a-zA-Z_]+\.debian\.org/debian' /etc/apt/sources.list
+ echo http://http.de.debian.org/debian) |
+sed 's%^\s*deb\s*\(http\|ftp\)://\(http\|ftp\)\.\([a-zA-Z_]\+\)\..*$%http://ftp.\3.debian.org/debian/%'
+}
+
Set_defaults ()
{
## config/common
@@ -284,7 +296,7 @@
then
case ${LH_MODE} in
debian|debian-release)
-LH_MIRROR_BOOTSTRAP=http://ftp.de.debian.org/debian/;
+LH_MIRROR_BOOTSTRAP=$(infer_main_mirror_from_apt_sources)
;;
emdebian)
Bug#576635: Unable to access an encrypted root partition after a failed resume
Package: linux-image-2.6.32-3-amd64 Version: 2.6.32-9 Severity: important I set up unstable on a new laptop last week, using the same configuration that I had on my last laptop: a single LVM physical volume, encrypted (with the configuration created by the installer), divided into two logical volumes, one for swap and one for the root partition. /boot, obviously, isn't on that partition. This morning, I tried to unhibernate the laptop for the second or third time ever. I entered my password and the screen blanked, but this time I was unlucky and it didn't come back (I was starting to hope hibernate would actually work ... oh well). So after giving it a good five minutes to do something, I finally just killed the power and rebooted. After the reboot, the initrd wouldn't accept my encryption passphrase. More specifically: it would unlock the partition, then announce that it couldn't find a filesystem on the device. I've booted the Squeeze live CD on the laptop, and it appears that the initrd was correct. I can unlock the partition by hand, but pvdisplay insists that the unencrypted device is not an LVM physical volume. Nor does it appear to be a filesystem of any normal sort. I'm not sure what sort of horrible thing happened to it at this point. I'm currently trying to hook the laptop in question up to the network so I can grab an image of the block device for analysis, in the hope that I can eventually figure out how to get my data off it (I'd like to get a working system on the laptop soon so I can use it one the bus). Obviously, I'd appreciate any suggestions you can give me with regard to tracking down what happened and/or repairing the system. Daniel -- System Information: Debian Release: squeeze/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: i386 (i686) Kernel: Linux 2.6.32-2-686 (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#575137: /usr/bin/aptitude missing
On Sat, Apr 03, 2010 at 04:52:56PM +0200, Benjamin Cama ben...@free.fr was heard to say: Le samedi 03 avril 2010 à 08:54 +0200, Sven Joachim a écrit : - The submitter of #575137 uses btrfs which reportedly may cause severe corruption of dpkg's database and other data: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=575891 http://kitenet.net/~joey/blog/entry/aloha_btrfs/ This may indeed be that kind of problem. But to confirm this bug, I first would like to try reproducing it, but I can't find 0.4.11.11-1+b2 anywhere. Do you have an idea where I can find it ? I can't find it anywhere on the Web. But since it's just a bin-NMU of the lenny aptitude, you can reproduce it by downloading that aptitude's source and building it. Another question: does /var/lib/dpkg/alternatives/aptitude exist, and what's in it? On my system it contains: auto /usr/bin/aptitude /usr/bin/aptitude-curses 30 /usr/bin/aptitude-gtk 60 I'd also be curious if any of those orphaned files look like that, obviously. Daniel -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#575137: /usr/bin/aptitude missing
On Sat, Apr 03, 2010 at 06:02:40PM +0200, Sven Joachim svenj...@gmx.de was heard to say: On 2010-04-03 17:53 +0200, Benjamin Cama wrote: Le samedi 03 avril 2010 à 08:13 -0700, Daniel Burrows a écrit : I can't find it anywhere on the Web. But since it's just a bin-NMU of the lenny aptitude, you can reproduce it by downloading that aptitude's source and building it. Well, I happen not to find any source for it too ... The hg repository doesn't have such a tag too. Any pointers ? I think you can use the version in lenny: http://packages.debian.org/source/lenny/aptitude Yeah, that's what I meant. Use dpkg-buildpackage -rfakeroot to get a .deb, then install the .deb. Daniel -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#575137: /usr/bin/aptitude missing
So, I haven't had time to do actual work on this bug yet, but I've mulled it over a bit. Here's what I think we know for sure: 1) On some people's systems, /usr/bin/aptitude isn't being restored after the upgrade. 2) On other people's systems, it is. 3) I don't know why. 4) Even if it's available under different names, /usr/bin/aptitude disappearing is a very unfriendly user experience. 5) The problem seems to be related to my attempt to use alternatives to manage /usr/bin/aptitude. I liked the idea of using the alternatives system, but it seems too fragile to be used for aptitude. Rather than trying to put a lot of effort into tracking down just what's happening, I think it's better to just back out of using alternatives entirely in favor of something more robust. A quick review of what I want: 1) All users of an aptitude package should have a working /usr/bin/aptitude. 2) If aptitude-curses is the only aptitude installed, aptitude should invoke the curses frontend. 3) If aptitude-gtk is installed, aptitude should invoke the GTK+ frontend (in the default configuration). 4) It should be possible for users to configure which binary gets invoked at the system level. If I want to be more robust by avoiding alternatives, the two obvious choices I see are dpkg-divert or simply writing a small shell script that reads /etc/default/aptitude and dispatches using the information there combined with which packages are currently installed. I prefer the shell script option for several reasons: 1) It doesn't rely on a slightly obscure part of the packaging system in its implementation (fewer moving parts = more reliability). 2) It doesn't require me to choose a dummy name to divert /usr/bin/aptitude to. 3) I can easily make aptitude-gtk and aptitude-curses binaries available, so tab-completion will show an obvious way to get a particular frontend. 4) There is no point 4. 5) It's dead simple to implement; the hardest part will be backing out the alternatives, and it's IMO not a disaster if I that's not perfect, since only interim unstable/testing users will see this switchover. (corollary: the time to do this is ASAP) The only real downside I see is that to attach a debugger to the system aptitude, you'll need to provide a full path to aptitude-curses or aptitude-gtk. I can live with that. Daniel -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#575137: /usr/bin/aptitude missing
On Tue, Mar 23, 2010 at 07:33:53PM +0100, Benjamin Cama ben...@free.fr was heard to say: I just updated from aptitude 0.4.11.11-1+b2 to version 0.6.1.5-3 and lost the 'aptitude' command. It is no more listed in 'dpkg -L aptitude' too. Have you ever had aptitude version 0.5+ installed on this system before? There were some bugs earlier with downgrading, particularly from some of the first versions that used alternatives. Daniel -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#573626: Terrible Interactive Search Performance
On Fri, Mar 12, 2010 at 04:33:39PM -0800, Elliott Mitchell e...@m5p.com was heard to say: Updating the display of packages behind the search box while typing characters is nice, it is also rather sluggish. Worse, it appears that aptitude updates its display after each character pressed, not accounting for someone having typed faster and being several characters ahead of the update. This is sufficiently bad such that doing searches on an ARM machine is *painful*. #317841 also hits this machine hard. What is happening, doing a linear search of every single package name??? Actually, it's a linear search over the displayed list of packages, which is similar but not identical. This used to work fine; over time the package list has expanded and people have started trying to run aptitude on wristwatch architectures. The solution is probably a combination of optimizing search (i.e., using indexes more aggressively), changing the curses UI so it actually benefits from the optimizations, and running searches in a background thread the way the GTK+ UI does. Not very high on my priority list, though: on the slowest machine I own (an early Asus EEE netbook), I can fully load the processor with compile jobs *and* have aptitude itself resolving dependencies in a background thread, and the lag is only noticable the first time I type a character that forces it to scan the whole list. And for that one that I only counted about two seconds at most. Earlier characters were fine, later characters were fine; it was just the one that caused my match to fail that was slow. It's a problem, just not one that seems to impact most modern machines much. By the way, a good workaround is to just use l for most searching tasks, particularly on large lists. Daniel -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#574593: Please don't make a device without playback capability the default.
Package: alsa-base Version: 1.0.21+dfsg-2 Severity: normal I have a USB webcam plugged into my computer that I use occasionally. It's a USB audio device, but as alsaconf succinctly puts it: This sound device does not have any playback controls. Sometimes (presumably depending on the timing of module loads) alsa decides to make this my first sound card. Unfortunately, most programs seem to assume that the first sound card is where their sound should go. You could argue that these programs are broken, but it seems to be a widespread problem and it would be nice if alsa avoided this configuration. A simple heuristic to avoid this problem would be to say that only devices with playback capability can become the default device (unless of course nothing has playback capability, I suppose). (yes, I have tracked down how to force the USB device to not be the default; however, it would be nice to not force every user who owns a consumer webcam to go through this process) Daniel -- Package-specific info: --- Begin additional package status --- Desired=Unknown/Install/Remove/Purge/Hold | Status=Not/Inst/Cfg-files/Unpacked/Failed-cfg/Half-inst/trig-aWait/Trig-pend |/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad) ||/ Name VersionDescription +++-==-==- ii libasound2 1.0.22-2 shared library for ALSA applications --- End additional package status --- --- Begin /proc/asound/version --- Advanced Linux Sound Architecture Driver Version 1.0.21. --- End /proc/asound/version --- --- Begin /proc/asound/cards --- 0 [VT82xx ]: HDA-Intel - HDA VIA VT82xx HDA VIA VT82xx at 0xbfffc000 irq 17 --- End /proc/asound/cards --- --- Begin /dev/snd/ listing --- total 0 drwxr-xr-x 2 root root 60 Mar 18 21:07 by-path crw-rw 1 root audio 116, 8 Mar 18 21:07 controlC0 crw-rw 1 root audio 116, 7 Mar 18 21:07 hwC0D0 crw-rw 1 root audio 116, 6 Mar 18 21:07 pcmC0D0c crw-rw 1 root audio 116, 5 Mar 18 21:07 pcmC0D0p crw-rw 1 root audio 116, 4 Mar 18 21:07 pcmC0D1p crw-rw 1 root audio 116, 3 Mar 18 21:07 seq crw-rw 1 root audio 116, 2 Mar 18 21:07 timer --- End /dev/snd/ listing --- -- System Information: Debian Release: squeeze/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: i386 (i686) Kernel: Linux 2.6.32-2-686 (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages alsa-base depends on: ii linux-sound-base 1.0.21+dfsg-2 base package for ALSA and OSS soun ii lsof 4.81.dfsg.1-1 List open files ii module-init-tools 3.12~pre1-1 tools for managing Linux kernel mo ii udev 151-2 /dev/ and hotplug management daemo Versions of packages alsa-base recommends: ii alsa-utils1.0.22-1 Utilities for configuring and usin Versions of packages alsa-base suggests: pn alsa-oss none (no description available) pn apmd none (no description available) ii oss-compat0.0.4+nmu3 OSS compatibility package Versions of packages libasound2 depends on: ii libc6 2.10.2-6 Embedded GNU C Library: Shared lib -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#574670: libboost-doc: Please document that the MPL - Fusion adapter also works the other way.
Package: libboost-doc Version: 1.40.0.1 Severity: minor In the section mpl sequence, the Fusion documentation states that: Including the module header makes all MPL sequences fully conforming fusion sequences. In fact, it works the other way around as well, turning Fusion sequences into MPL sequences. Even something as simple as adding ... and all fusion sequences fully conforming MPL sequences would have saved me some effort trying to find out how to do this. Daniel -- System Information: Debian Release: squeeze/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: i386 (i686) Kernel: Linux 2.6.32-2-686 (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages libboost-doc depends on: ii libboost1.40-doc 1.40.0-6 Boost.org libraries documentation libboost-doc recommends no packages. libboost-doc suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#501832: Still a bug?
If I run aptitude search as nobody, I get an error about not being able to create .aptitude, but the search goes ahead anyway. Does that fix this bug for you? I don't know if I want to suppress that error, since it indicates a real problem most of the time. Daniel -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#571939: Acknowledgement ([sparc] segfault when quitting aptitude)
On Fri, Mar 12, 2010 at 10:40:40PM +0100, Frans Pop elen...@planet.nl was heard to say: On Friday 12 March 2010, Daniel Burrows wrote: I think a backtrace with -dbg packages would be useful. So would a backtrace of all threads (thread apply all backtrace); I'd like to see what the main thread is up to. As I cannot copy and paste because the mouse is not functional, they are in the form of screenshots. Hm, the threadall backtraces look identical. Is there another page? BTW, if you're talking about the mouse having problems because of the terminal state: usually holding down Shift bypasses mouse capture by the program running in the terminal and lets you select as usual. I know this works in xterm and gnome-terminal, anyway; I don't have Konsole handy right now to test in. Daniel -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#571939: aptitude: Same problem on squeeze
On Tue, Mar 09, 2010 at 02:14:54PM +0800, Paolo Scarabelli pa...@msw.it was heard to say: Aptitude always segfaults everytime I quit, with one exception: if I open it and close it without updating (or doing anything else) it exits just fine. I wonder if valgrind would show anything useful. Install valgrind and run: valgrind --log-file=aptitude.grind aptitude and get it to crash. Daniel -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#571939: [sparc] segfault when quitting aptitude
On Sun, Feb 28, 2010 at 01:54:31PM +0100, Frans Pop f...@debian.org was heard to say: aptitude runs fine on my sparc64 box for upgrading and installing packages, but segfaults always when I quit the application. Does this happen just with the 0.6 series of aptitude, or did you see this in past versions too? Daniel -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#568733: aptitude: New full-upgrade behavior breaks pkgsync
On Sun, Feb 07, 2010 at 12:43:23PM +0100, Steinar H. Gunderson sgunder...@bigfoot.com was heard to say: It seems that recently, aptitude changed behavior such that a command-line such as aptitude full-upgrade ed+ will only upgrade ed -- earlier, it would install ed and then full a normal full-upgrade. (The changelog mentions a NEWS entry that's supposed to document this, but I'm unable to find the NEWS entry in question.) It's documented in NEWS.Debian. It looks like I somehow forgot to write an entry in the aptitude NEWS file, sorry about that. This breaks pkgsync, which no longer is able to keep systems up-to-date; it relies on the previous behavior. Furthermore, there seems to no longer be a usable way to get the old behavior back; pkgsync relies heavily on it to be able to do everything in one aptitude invocation (which is essential to make --simulate work). Could we please get a way to get the old behavior back, possibly as an option? Can't you just add ?upgradable as the first argument following full-upgrade? It seems to me like that should give you the old behavior back while being backwards-compatible (and if I'm wrong, I need to fix NEWS.Debian, since that's what it tells people to do). Daniel -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#571939: Acknowledgement ([sparc] segfault when quitting aptitude)
On Sun, Feb 28, 2010 at 02:09:09PM +0100, Frans Pop elen...@planet.nl was heard to say: The problem is only reproducible after e.g. installing a package; just starting aptitude and quitting straight away does not reproduce it. A backtrace for this issue looks as follows: Just from looking at the backtrace, it looks like the cwidget signal-processing thread is being canceled when you quit, but crashing in the process. But the thread should be stopped cleanly before the program quits. Unless, maybe, the program is crashing for some other reason (e.g., due to an uncaught exception or another signal). This was without debugging symbols installed. If you'd like a backtrace with -dbg packages installed or additional info, please let me know. I think a backtrace with -dbg packages would be useful. So would a backtrace of all threads (thread apply all backtrace); I'd like to see what the main thread is up to. Daniel -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#568302: prompt [Y/n/q/1/2/3/4/5/6...] if necessary
On Thu, Feb 04, 2010 at 02:40:25AM +0800, jida...@jidanni.org was heard to say: 1) gimp 2) gnome-user-guide 3) libgstreamer-plugins-base0.10-0 4) libwebkit-1.0-2 5) midori 6) yelp Tier: Safe actions, Remove packages (1) Accept this solution? [Y/n/q/?] 3 Action 3: Removing libgstreamer-plugins-base0.10-0 Aggg... you prompted for [Y/n/q/] but instead I typed 3... and you accepted it... anyway, the prompt should be [Y/n/q/1/2/3/4/5/6] then. This is a deliberate decision. If I listed every option that the prompt accepted (even leaving aside the numbers listed next to choices) then the prompt would be something like [Y/n/q/a/r/,/./e/x/+/+M/-/_/=/:/M/m/?] which I don't think is actually useful since you need to press ? to find out what any of those extra options mean anyway. The main preview prompt would be even worse. The one thing that might make sense would be to add an ellipsis, [Y/n/q/?/...] assuming that users would actually read that as there are more options, press '?' to view them and not enter three periods to do something. Maybe I could help with that by omitting the last slash: [Y/n/q/? ...] or even [Y/n/q/... (?)] But I think all of those options are pushing it as far as concisely conveying the message press ? to see more options. As far as the numbers go, I would certainly list them as 1-6 and not list every number individually (hint: some solutions have a few dozen choices). Daniel -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#567662: error.h includes a non-existant system.h, breaking builds
Package: libapt-pkg-dev Version: 0.7.25.2 Severity: serious Since the latest apt upload, no source file that includes apt-pkg/error.h will compile: In file included from temp.cc:30: /usr/include/apt-pkg/error.h:56:20: error: system.h: No such file or directory In file included from temp.cc:30: /usr/include/apt-pkg/error.h:76: error: expected ‘;’ before ‘__cold’ /usr/include/apt-pkg/error.h:77: error: expected ‘;’ before ‘__cold’ /usr/include/apt-pkg/error.h:81: error: expected ‘;’ before ‘__cold’ /usr/include/apt-pkg/error.h:82: error: expected ‘;’ before ‘__cold’ It looks like a new header (system.h) was introduced into the apt source package, but it wasn't added to the list of files to install in /usr/include. Daniel -- System Information: Debian Release: squeeze/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: i386 (i686) Kernel: Linux 2.6.32-trunk-686 (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages libapt-pkg-dev depends on: ii apt [libapt-pkg-libc6.9-6-4.8 0.7.25.2 Advanced front-end for dpkg ii apt-utils 0.7.25.2 APT utility programs libapt-pkg-dev recommends no packages. libapt-pkg-dev suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#567662: Acknowledgement (error.h includes a non-existant system.h, breaking builds)
The attached patch should fix this problem. In addition to installing
system.h in apt-pkg, it's necessary to update all the #includes to refer
to it as apt-pkg/system.h instead of just system.h.
Daniel
diff -Nru --exclude configure --exclude changelog --exclude '*.pot' --exclude '*.po' apt-0.7.25.2/apt-inst/contrib/extracttar.cc apt-0.7.25.3~local1/apt-inst/contrib/extracttar.cc
--- apt-0.7.25.2/apt-inst/contrib/extracttar.cc 2010-01-27 12:49:24.0 -0800
+++ apt-0.7.25.3~local1/apt-inst/contrib/extracttar.cc 2010-01-30 08:12:57.0 -0800
@@ -21,7 +21,7 @@
#include apt-pkg/error.h
#include apt-pkg/strutl.h
#include apt-pkg/configuration.h
-#include system.h
+#include apt-pkg/system.h
#include stdlib.h
#include unistd.h
diff -Nru --exclude configure --exclude changelog --exclude '*.pot' --exclude '*.po' apt-0.7.25.2/apt-pkg/contrib/error.h apt-0.7.25.3~local1/apt-pkg/contrib/error.h
--- apt-0.7.25.2/apt-pkg/contrib/error.h 2010-01-27 12:49:24.0 -0800
+++ apt-0.7.25.3~local1/apt-pkg/contrib/error.h 2010-01-30 08:05:45.0 -0800
@@ -53,7 +53,7 @@
#include string
-#include system.h
+#include apt-pkg/system.h
using std::string;
diff -Nru --exclude configure --exclude changelog --exclude '*.pot' --exclude '*.po' apt-0.7.25.2/apt-pkg/contrib/hashes.cc apt-0.7.25.3~local1/apt-pkg/contrib/hashes.cc
--- apt-0.7.25.2/apt-pkg/contrib/hashes.cc 2010-01-27 12:49:24.0 -0800
+++ apt-0.7.25.3~local1/apt-pkg/contrib/hashes.cc 2010-01-30 08:08:34.0 -0800
@@ -14,9 +14,9 @@
#include apt-pkg/hashes.h
#include apt-pkg/fileutl.h
#include apt-pkg/configuration.h
+#include apt-pkg/system.h
#include unistd.h
-#include system.h
#include string
#include iostream
/*}}}*/
diff -Nru --exclude configure --exclude changelog --exclude '*.pot' --exclude '*.po' apt-0.7.25.2/apt-pkg/contrib/md5.cc apt-0.7.25.3~local1/apt-pkg/contrib/md5.cc
--- apt-0.7.25.2/apt-pkg/contrib/md5.cc 2010-01-27 12:49:24.0 -0800
+++ apt-0.7.25.3~local1/apt-pkg/contrib/md5.cc 2010-01-30 08:06:44.0 -0800
@@ -37,13 +37,13 @@
// Include Files /*{{{*/
#include apt-pkg/md5.h
#include apt-pkg/strutl.h
+#include apt-pkg/system.h
#include string.h
#include unistd.h
#include netinet/in.h // For htonl
#include inttypes.h
#include config.h
-#include system.h
/*}}}*/
diff -Nru --exclude configure --exclude changelog --exclude '*.pot' --exclude '*.po' apt-0.7.25.2/apt-pkg/contrib/sha1.cc apt-0.7.25.3~local1/apt-pkg/contrib/sha1.cc
--- apt-0.7.25.2/apt-pkg/contrib/sha1.cc 2010-01-27 12:49:24.0 -0800
+++ apt-0.7.25.3~local1/apt-pkg/contrib/sha1.cc 2010-01-30 08:08:05.0 -0800
@@ -31,13 +31,12 @@
// Include Files/*{{{*/
#include apt-pkg/sha1.h
#include apt-pkg/strutl.h
+#include apt-pkg/system.h
#include string.h
#include unistd.h
#include inttypes.h
#include config.h
-#include system.h
- /*}}}*/
// SHA1Transform - Alters an existing SHA-1 hash /*{{{*/
// -
diff -Nru --exclude configure --exclude changelog --exclude '*.pot' --exclude '*.po' apt-0.7.25.2/apt-pkg/deb/deblistparser.cc apt-0.7.25.3~local1/apt-pkg/deb/deblistparser.cc
--- apt-0.7.25.2/apt-pkg/deb/deblistparser.cc 2010-01-27 12:49:24.0 -0800
+++ apt-0.7.25.3~local1/apt-pkg/deb/deblistparser.cc 2010-01-30 08:11:09.0 -0800
@@ -16,11 +16,9 @@
#include apt-pkg/strutl.h
#include apt-pkg/crc-16.h
#include apt-pkg/md5.h
-
-#include ctype.h
-
-#include system.h
+#include apt-pkg/system.h
/*}}}*/
+#include ctype.h
static debListParser::WordList PrioList[] = {{important,pkgCache::State::Important},
{required,pkgCache::State::Required},
diff -Nru --exclude configure --exclude changelog --exclude '*.pot' --exclude '*.po' apt-0.7.25.2/apt-pkg/makefile apt-0.7.25.3~local1/apt-pkg/makefile
--- apt-0.7.25.2/apt-pkg/makefile 2010-01-27 12:49:24.0 -0800
+++ apt-0.7.25.3~local1/apt-pkg/makefile 2010-01-30 08:04:21.0 -0800
@@ -24,7 +24,8 @@
contrib/cdromutl.cc contrib/crc-16.cc contrib/netrc.cc \
contrib/fileutl.cc
HEADERS = mmap.h error.h configuration.h fileutl.h cmndline.h netrc.h\
- md5.h crc-16.h cdromutl.h strutl.h sptr.h sha1.h sha256.h hashes.h
+ md5.h crc-16.h cdromutl.h strutl.h sptr.h sha1.h sha256.h hashes.h \
+ system.h
# Source code for the core main library
SOURCE+= pkgcache.cc version.cc depcache.cc \
diff -Nru --exclude configure --exclude changelog --exclude '*.pot' --exclude '*.po' apt-0.7.25.2/apt-pkg/pkgcache.cc apt-0.7.25.3~local1/apt-pkg/pkgcache.cc
--- apt-0.7.25.2/apt-pkg/pkgcache.cc 2010-01-27 12:49:24.0 -0800
+++ apt-0.7.25.3~local1/apt-pkg/pkgcache.cc 2010-01-30 08:09:04.0 -0800
@@ -27,6 +27,7 @@
#include apt-pkg/error.h
#include apt-pkg/strutl.h
#include
Bug#567242: Upload is pending on an apt upload.
I have an upload prepared to fix these bugs, but I can't upload it because the apt includes are broken (just filed a bug about it). Daniel -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#567242: aptitude full-upgrade segfaults on PowerPC when rejecting removal of gnome
On Thu, Jan 28, 2010 at 12:08:14AM -0500, Rick Thomas rbtho...@dillserver.rcthomas.org was heard to say: Remove the following packages: 1) fast-user-switch-applet 2) gedit 3) gedit-plugins 4) gnome [snip] Accept this solution? [Y/n/q/?] r gnome UNINST Whoops, I forgot to check that this codepath still worked. For the time being, you can work around it by using the number next to an entry to select it (e.g., r 4 in this case). Daniel -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#566343: aptitude constantly switches between console-setup and console-setup-mini
On Tue, Jan 26, 2010 at 01:11:19PM -0800, Russ Allbery r...@debian.org was heard to say: The mechanism exists to do a non-mutative upgrade calculation, I just hadn't hooked it up to the command-line. That could solve half the problem. I'd also like to see why the resolver isn't just canceling the automatic removal -- that ought to be preferred to installing a new package. Thank you for the update! The explanation makes a lot of sense. I tracked down one bug that was part of this: aptitude was incorrectly treating the automatic removal as a manual action, so it was penalizing solutions that restore the package. However, in at least one of the two cases that's involved, it still tries to switch to the other console-setup package, because it solves more outstanding dependencies than the alternative, so it looks like a locally better solution. Probably an argument for tracking down those algorithms to split a constraint graph and work on it piecewise... I might wait a bit on rewiring the upgrade commands. It'll require a bunch of coding, and I suspect that it won't actually fix all the problems (there are probably cases where aptitude would get confused and start fixing dependencies of stuff that was going to be removed anyway). The real fix here is to integrate autoremoval into the dependency solver, so it knows exactly what the outcomes of its actions are. Daniel -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#566343: aptitude constantly switches between console-setup and console-setup-mini
Hi there. I figured the cause out a few days ago, then had an attack of family... Anyway, this is a side-effect of aptitude calculating upgrades mutatively -- that is, it sets its internal state to where the upgrade would go (which causes unused packages to be removed, including the old console-setup one), then computes a resolver solution. The resolver solution requires satisfying a dependency on the two console-setup packages, and for some reason (which will be easy to find once I sit down and investigate this) it decides to install the one that's not installed. This happens on a laptop where I haven't held anything back. The mechanism exists to do a non-mutative upgrade calculation, I just hadn't hooked it up to the command-line. That could solve half the problem. I'd also like to see why the resolver isn't just canceling the automatic removal -- that ought to be preferred to installing a new package. Daniel -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#566171: dist-upgrade: conflict between udev and linux kernel - upgrade crash
On Thu, Jan 21, 2010 at 07:22:35PM +0100, Martin martin.m...@desineo.com was heard to say: I wanted tu upgrade Debian Lenny stable to Squeeze testing. The system was fairly new, there were packages almost from stable (without hplip and virtualbox (VB was from another repository)). So, I did aptitude update, aptitude upgrade, I changed lenny repository to squeeze in sources.list and then aptitude dist-upgrade All was OK to this moment. udev wanted to upgrade, but it couldn't, it wrote that I need newer kernel to upgrade udev. The upgrade stopped and it turned me tu shell. I tried to install newer kernel, but I couldn't because aptitude wanted upgrade udev first... So I couldn't upgrade kernel and also udev. My best guess is that this is because of udev's requirements on upgrade. I'll reassign your bug over there. I'd ask you to confirm this, but: I think that aptitude in stable shouldn't do this thing. I reinstalled the complete system. Now I'm writing from new installation, so THE SYSTEM INFORMATION DOES NOT MATCH WITH SYSTEM, WHERE THE BUG WAS. Daniel -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#566343: aptitude constantly switches between console-setup and console-setup-mini
Could you run aptitude -s --show-resolver-actions safe-upgrade and paste the output? Thanks, Daniel -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#566108: aptitude: changelog on the Web (http://packages.debian.org/) packages outdated
Unfortunately, packages.debian.org lags behind the archive a bit, usually by a couple days or so. I can download the new changelog from the appropriate place, but it doesn't look like packages.d.o/aptitude links to it yet. The lag at the moment is at least four days now, though, which seems a little excessive. I'll reassign this bug to www.debian.org. Daniel -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#565955: More details for Bug#565955: aptitude: downloading and displaying changelogs no more working
Are you 100% sure that the changelog is never displayed? In my tests, it looks like the bug is actually not that the changelog isn't downloaded, but that the progress bar isn't shown (so it *looks* like nothing is happening until the changelog appears). Daniel -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#566003: [doc] aptitude search error in man page
On Wed, Jan 20, 2010 at 04:05:52PM +0100, r.ductor r.duc...@gmail.com was heard to say: search Searches for packages matching one of the patterns supplied on the command line. All packages which match any of the given patterns will be displayed; for instance, “aptitude search ´~N´ edit” will list all “new” packages and all packages whose name contains “edit”. For more information on search patterns, see the section “Search Patterns” in the aptitude reference manual. The above command-line searches for two patterns: ~N and edit. Long form Short form Description ?and(term1, term2)term1 term2 Select any package that matches both term1 and term2. This would be one pattern: ~N edit. Daniel -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#565736: aptitude: FTBFS on kfreebsd-i386: testsuite failure
On Tue, Jan 19, 2010 at 10:44:08AM +0100, Cyril Brulebois k...@debian.org was heard to say: Daniel Burrows dburr...@debian.org (18/01/2010): It looks like the build succeeded on all the release architectures, so I think I might downgrade this so that aptitude can get into testing. (the version currently there is ancient and I don't really want it to be held up even further by problems on one of the experimental archs now that it seems to work everywhere else) No, it didn't. kfreebsd-* are release architectures… *boggle* All righty then. In that case, I'm going to disable the test cases on kfreebsd. It looks pretty clear to me from the transcript that the test case actually succeeded before crashing, which makes me suspect that it's the Boost test framework itself that's crashing, not aptitude code. This would not be the first time (Google for boost unit test double free); I'm beginning to think that this piece of Boost is not up to their usual quality, and I should consider dropping it and going back to cppunit, or just rolling my own :-/. (The waitpid() issue still has to be investigated. But I see it also happens on other architectures, like amd64.) The waitpid() thing turned out to be mostly spurious; I've fixed it in head. I can't see how it would have caused a double-free, though. I didn't say it would have, my point was just about making sure it wasn't unnoticed. No problem. Daniel -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#565867: aptitude: dist-upgrade does not replace old with new Provides package [texlive-binaries]
In the 0.6 series, the aptitude resolver is a lot more conservative than it used to be, due to repeated complaints by users that it was removing too many packages in the first solution that was presented. It looks like maybe I overcompensated, though (this is not the first report along these lines). The main difficulty in cases like this is getting the algorithm to properly balance removals with upgrades. However, it looks like the old scoring system works just fine here. This command line: aptitude -o 'aptitude::problemresolver::remove-tier=1' -s dist-upgrade tells aptitude that it shouldn't force removals to appear after keeps. The resulting solution looks mostly reasonable: Remove the following packages: 1) debian-keyring 2) flightgear 3) java-gcj-compat 4) java-gcj-compat-headless 5) libghc6-parsec-dev 6) libghc6-parsec-prof 7) supertuxkart 8) texlive-base-bin Keep the following packages at their current version: 9) libplib1 [Not Installed] 10) simgear1.9.1 [Not Installed] Leave the following dependencies unresolved: 11) devscripts recommends debian-keyring It still isn't perfect, but that seems mostly due to problems with the flightgear package and its dependencies. I have some ideas on how to use the tier mechanism in a more flexible way to balance keeps with removals, but I don't know if I'll get to implement them before Squeeze (after all, the freeze is next month). It might be simpler to just change the defaults to the settings I gave above, so that upgrading to Squeeze works as expected. Daniel -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#565760: aptitude: wants to remove packages recommended by a package marked as hold
If you have a machine where aptitude is doing this, it would be helpful if you could run aptitude-create-state-bundle and send me the resulting file. Thanks, Daniel -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#565736: aptitude: FTBFS on kfreebsd-i386: testsuite failure
Weird thing is: I get the same failure, but it doesn't kill the build. It should. So by my count that's two bugs here :-/. Daniel -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#565736: aptitude: FTBFS on kfreebsd-i386: testsuite failure
Ah, I got fooled by some garbage printed by the cppunit test. The actual problem is the double-free in the Boost tester. D'oh. Daniel -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#565736: aptitude: FTBFS on kfreebsd-i386: testsuite failure
OK, I can't see any sign of a double-free in either valgrind or libefence, which are usually pretty good about catching this sort of thing. Can you run something similar on FreeBSD and see what it says? Thanks, Daniel -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#565736: aptitude: FTBFS on kfreebsd-i386: testsuite failure
On Tue, Jan 19, 2010 at 03:32:36AM +0100, Cyril Brulebois k...@debian.org was heard to say: Only keeping the #include line is sufficient, I can't reproduce this issue double free issue. Weird. It looks like the build succeeded on all the release architectures, so I think I might downgrade this so that aptitude can get into testing. (the version currently there is ancient and I don't really want it to be held up even further by problems on one of the experimental archs now that it seems to work everywhere else) (The waitpid() issue still has to be investigated. But I see it also happens on other architectures, like amd64.) The waitpid() thing turned out to be mostly spurious; I've fixed it in head. I can't see how it would have caused a double-free, though. One of the tests is supposed to fork a child and check that its temporary files get deleted when it calls exit() (testing an atexit handler). I forgot to write explicit code for the child process in the switch, so it tried to wait on PID 0, then continued running tests -- that's what the failure message is from. The parent's test succeeded, although it wasn't really testing the behavior it was supposed to test. Daniel -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#565692: Please allow the package to be upgraded even when OpenOffice is running.
Package: openoffice.org Version: 1:3.1.1-14 Severity: normal It's really annoying to start an upgrade of 300 packages, then discover that it failed because OpenOffice was one of the 300 and it detected a running session. This results in a dialog box telling me that I need to stop the session and one button, Ok, which causes the entire install to blow up. I'm assuming you must have had extremely good reasons for coding up this behavior, so I won't ask you to remove the dialog. However, it would be nice if there was a way to avoid having the install be aborted. For instance, you could give this dialog a Continue button and an Abort button that do what they say. I would be OK with continue looping back if OpenOffice is still running; the main thing is that I want to be able to kill the active session and continue the upgrade afterwards. Even if you keep the current scheme unchanged, it would be really nice if you could at least change the text to Abort or Abort Install so that it's clear that the install is aborting -- the first few times I hit this message I skimmed the text and didn't realize that it was actually fatal. (I don't know if debconf lets you do that, though) It would also be nice if you could display the ps lines for the offending process -- not everyone can remember that the OpenOffice process is actually named soffice. (oh, and there's one other nasty side-effect of this dialog: if the user has configured debconf to be noninteractive, they get a silent failure with no explanation of what happened. I suggest emitting some sort of error message explaining why the postinst is failing) Daniel -- System Information: Debian Release: squeeze/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: i386 (i686) Kernel: Linux 2.6.32-trunk-686 (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages openoffice.org depends on: ii liblucene2-java 2.9.1+ds1-2 Full-text search engine library fo ii openoffice.org-base 1:3.1.1-14 full-featured office productivity ii openoffice.org-calc 1:3.1.1-14 full-featured office productivity ii openoffice.org-core 1:3.1.1-14 full-featured office productivity ii openoffice.org-draw 1:3.1.1-14 full-featured office productivity ii openoffice.org-filter-mobile 1:3.1.1-14 full-featured office productivity ii openoffice.org-impress 1:3.1.1-14 full-featured office productivity ii openoffice.org-java-common 1:3.1.1-14 full-featured office productivity ii openoffice.org-math 1:3.1.1-14 full-featured office productivity ii openoffice.org-officebean1:3.1.1-14 full-featured office productivity ii openoffice.org-report-builde 1:3.1.1-14 OpenOffice.org extension for build ii openoffice.org-writer1:3.1.1-14 full-featured office productivity ii ttf-dejavu 2.30-2 Metapackage to pull in ttf-dejavu- Versions of packages openoffice.org recommends: ii openoffice.org-filter- 1:3.1.1-14full-featured office productivity ii ttf-liberation 1.05.2.20091019-4 Fonts with the same metrics as Tim ii ttf-mscorefonts-instal 3.0 Installer for Microsoft TrueType c Versions of packages openoffice.org suggests: ii cups-bsd 1.4.2-6 Common UNIX Printing System(tm) - ii gcj-4.4-jre [java5-runtime 4.4.2-9 Java runtime environment using GIJ ii gcj-jre [java5-runtime]4:4.3.4-1 Java runtime environment using GIJ ii gstreamer0.10-ffmpeg 0.10.9-3 FFmpeg plugin for GStreamer ii gstreamer0.10-plugins-bad 0.10.17-2 GStreamer plugins from the bad s ii gstreamer0.10-plugins-base 0.10.25-7 GStreamer plugins from the base ii gstreamer0.10-plugins-good 0.10.17-1 GStreamer plugins from the good ii gstreamer0.10-plugins-ugly 0.10.13-2 GStreamer plugins from the ugly pn hunspell-dictionarynone(no description available) ii iceape-browser 2.0.1-1 Iceape Navigator (Internet browser ii iceweasel 3.5.6-1 lightweight web browser based on M ii imagemagick7:6.5.8.3-1 image manipulation programs ii java-gcj-compat [java5-run 1.0.80-5.1Java runtime environment using GIJ ii libgl1-mesa-glx [libgl1] 7.6.1-1 A free implementation of the OpenG ii libpaper-utils 1.1.23+nmu1 library for handling paper charact ii libsane1.0.20-13 API library for scanners ii libxrender11:0.9.5-1 X Rendering Extension client libra ii menu 2.1.42generates programs menu for all me ii myspell-en-us [myspell-dic 1:3.2.0~rc2-1 English_american dictionary for my pn openclipart-openoffice.org none(no description available) ii openjdk-6-jre [java5-runti 6b17~pre3-1 OpenJDK Java
Bug#561157: libcwidget3: FTBFS: error: dereferencing pointer 'anonymous' does break strict-aliasing rules
On Tue, Dec 15, 2009 at 07:56:01PM +, peter green plugw...@p10link.net was heard to say: The attatched patch resolves the FTBFS by taking the simple approach of building with -fno-strict-aliasing . That obviously avoids this, but I'd rather fix the bug directly (besides, doesn't disabling strict aliasing lose a lot of optimizations?). Does anyone understand what the code is doing wrong here? I've been through that sigc++ code and the cwidget code that the error claims is invoking it, plus all the stuff that should be in between, and I can't see any sketchy aliasing. Everything is properly typed -- with one cast to a base class, but that obviously ought to be fine as long as we don't cast back down to an unrelated type. Daniel -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#526674: No longer present?
I can't reproduce this with the latest cwidget and g++ versions (0.5.16 and 4.4.2 respectively). Can anyone else? Daniel -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#559195: Cannot build the source package in clean chroot, unable to pdebbuild the package.
On Thu, Dec 03, 2009 at 11:15:29PM +0100, Artur R. Czechowski artu...@hell.pl was heard to say: On Wed, Dec 02, 2009 at 01:17:27PM -0800, Daniel Burrows wrote: Debian policy section 7.7 clearly states that Build-Depends must be satisfied before clean is invoked. [cut] It might be enough to remove that line and instead write [ ! -f doc/Makefile ] || $(MAKE) -C doc distclean after we invoke $(MAKE) distclean. I suspect it would also be a good idea to explicitly clean in src/gtk, since that can also be disabled. Well, under mentioned circumstances it is obviously my fault, because I am using tools in a not intended way. Of course, it would be nice to have a possibility of download this or that package and recompile it without cluttering the filesystem with normaly unneeded development packages. I think you can just close the bug. Or, if you are able to fulfill my wish - toggle it to wishlist. Just FYI, I did check some changes into the Debian packaging which should allow clean to run with only debhelper. Daniel -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#555120: aptitude-gtk doesn't start (GThread-ERROR **: GThread system may only be initialized once. aborting...)
On Sat, Dec 05, 2009 at 10:46:16PM +0200, George Danchev danc...@spnet.net was heard to say: Hi, the following patch fixes that crash on amd64. --- src/gtk/gui.cc.orig 2009-12-05 22:43:21.0 +0200 +++ src/gtk/gui.cc 2009-12-05 22:43:40.0 +0200 @@ -1769,7 +1769,7 @@ if(!gtk_init_check(argc, argv)) return false; -Glib::init(); +//Glib::init(); Odd, so Glib::init invokes thread_init, but only on amd64? The docs don't suggest this at all. thread_init's documentation shows how to check whether it's already been called, though, so maybe I can just do that. Daniel -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#452589: aptitude: holding packages in curses interface still doesn't work as expected
On Fri, Dec 04, 2009 at 12:27:18AM +0100, Thomas Frauendorfer fraue...@in.tum.de was heard to say: When using the curses interface, pressing + on a section still marks all packages for update, even those that are held. Hi, Thomas. When you press + on a section, aptitude treats it as pressing + on each package within the section (as with every other command you can invoke on a section), so it does indeed break holds. This bug is about a different problem, where some automatic processes were breaking holds even though the user didn't ask aptitude to do so. Daniel -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#559926: Not an aptitude bug.
I'm 99.99% sure this has nothing to do with aptitude. aptitude doesn't do any of the actual mechanical installation of packages; it just asks libapt to invoke dpkg with appropriate command line arguments. One thing that could cause this problem would be if that directory already existed on the system with those permissions. For instance, firefox seems to create and populate it if run as root. I'll reassign it there (and bump the severity to serious for this FHS violation: /usr must be sharable and must not be writen to). Actually, I guess iceweasel is the right place these days? There, then. Daniel -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#559980: aptitude: Totally broken on GNU/kFreeBSD
On Wed, Dec 09, 2009 at 01:36:19PM +0100, Petr Salinger petr.salin...@seznam.cz was heard to say: IMHO, yet better would be patch below, some library might use some other signal internally, you really want to only block SIGWINCH. Sounds good to me. Daniel -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#542767: apt: autoremove removes needed packages
This is a bug about apt-get (and, IMO, specifically its delayed handling of autoremove -- it looks like the reporter got a lot of cruft on his system without noticing until he ran autoremove). It's true that aptitude won't let you remove a package without also removing packages that depend on it, aka obeying the package dependencies. This isn't a bug at all, doesn't have anything to do with autoremoval, and anyway it doesn't make this bug a bug in aptitude. Reassigning back to apt. Daniel -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#559195: Cannot build the source package in clean chroot, unable to pdebbuild the package.
On Wed, Dec 02, 2009 at 06:07:33PM +0100, Artur R. Czechowski artu...@hell.pl was heard to say: clean target of debian/rules runs ./configure script, which fails if there are no development libraries installed. That means it is unable to build source package, which result with failing the pdebuild command. Debian policy section 7.7 clearly states that Build-Depends must be satisfied before clean is invoked. I see that it could be convenient to invoke clean with a small subset of the build-deps installed, but this is at most a wishlist bug in aptitude IMO. (if pdebuild isn't checking build-deps, it might be a bug in pdebuild) According to the comments in debian/rules, configure is invoked to ensure that the documentation is enabled. It might be enough to remove that line and instead write [ ! -f doc/Makefile ] || $(MAKE) -C doc distclean after we invoke $(MAKE) distclean. I suspect it would also be a good idea to explicitly clean in src/gtk, since that can also be disabled. Daniel -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#557982: Should be fixed now.
On Mon, Nov 30, 2009 at 10:58:02PM +0100, Julien Cristau jcris...@debian.org was heard to say: reopen 557982 kthxbye On Mon, Nov 30, 2009 at 12:28:31 -0800, Daniel Burrows wrote: With any luck, this is fixed in 0.5.16-1 in unstable. I addressed the problem by having the tests query for the system limit on the number of threads they could create, then stop at that many. Hopefully that should get them to pass on hppa, but obviously I can't test that myself, so please let me know if it fails again. Looks like it failed again. https://buildd.debian.org/fetch.cgi?pkg=cwidget;ver=0.5.16-1;arch=hppa;stamp=1259584731 debian-hppa, any clue why cwidget would get an error when trying to create 50 threads, and how to fix this? According to the build logs for 0.5.16-2, it successfully creates 37 new threads, failing on the 38th. More annoyingly, it looks like sysconf is not reporting the existence of a limit on the number of threads the test can create; both tests are trying to create their default number of threads (the number of threads to create would have been lowered to the limit had sysconf indicated that there was a limit -- I thought maybe I had an off-by-one error in how I was computing the limit, but apparently that's not the case). Anyway, the build looks like it succeeded now that the failed pthread_create is ignored. Daniel -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#557982: Should be fixed now.
On Mon, Nov 30, 2009 at 10:58:02PM +0100, Julien Cristau jcris...@debian.org was heard to say: On Mon, Nov 30, 2009 at 12:28:31 -0800, Daniel Burrows wrote: With any luck, this is fixed in 0.5.16-1 in unstable. I addressed the problem by having the tests query for the system limit on the number of threads they could create, then stop at that many. Hopefully that should get them to pass on hppa, but obviously I can't test that myself, so please let me know if it fails again. Looks like it failed again. https://buildd.debian.org/fetch.cgi?pkg=cwidget;ver=0.5.16-1;arch=hppa;stamp=1259584731 debian-hppa, any clue why cwidget would get an error when trying to create 50 threads, and how to fix this? OK, I'm preparing an upload that just ignores EAGAIN with a warning message for the time being. Daniel -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#554640: aptitude: please allow resumption of incomplete downloads
OK, well, I'll reassign this to apt in any event since it's really in that package that this happens. Daniel -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#557982: FTBFS on hppa
Since basically nothing changed between the last version and this one, that's (more than) a little weird, particularly since this built and passed its unit tests on every other architecture. In particular, none of the code invoked by testBox has changed at all since 0.5.13. Daniel -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#526030: Upstream bug link
Apparently an upstream bug has been created for this: https://bugzilla.gnome.org/show_bug.cgi?id=587256 No indication on that bug when it will be fixed, but a user posted a workaround on the bug (a script that edits your Glade file so Glade can understand it). I had to add GtkVPaned to the list of classes modified, since that's apparently also affected. Daniel -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#557982: FTBFS on hppa
On Sun, Nov 29, 2009 at 04:28:10PM +0100, Julien Cristau jcris...@debian.org was heard to say: On Sun, Nov 29, 2009 at 16:21:08 +0100, Julien Cristau wrote: See e.g. bug#554218, which also corresponds to EAGAIN returned by pthread_create. So apparently hppa has trouble running thread stress tests, even for as few as 1,000 threads? And the only thing the Perl team could do was work around it by ignoring the failing pthread_create()? I'll need to actually pass the errno value out of the thread create routine, but I can have that test stop trying to create threads if it gets EAGAIN. Daniel -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#557982: FTBFS on hppa
On Sun, Nov 29, 2009 at 10:45:26AM -0800, Daniel Burrows dburr...@debian.org was heard to say: On Sun, Nov 29, 2009 at 04:28:10PM +0100, Julien Cristau jcris...@debian.org was heard to say: On Sun, Nov 29, 2009 at 16:21:08 +0100, Julien Cristau wrote: See e.g. bug#554218, which also corresponds to EAGAIN returned by pthread_create. So apparently hppa has trouble running thread stress tests, even for as few as 1,000 threads? And the only thing the Perl team could do was For 1,000, substitute 50 -- I swapped the constants when I was reading them. There are 50 threads that each count to 1,000. That's a little worrying; it's low enough that real code could conceivably bump its head on the limit (especially if the real limit is more like 30 or 40). I'll implement the workaround anyway, though. Daniel -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#554640: aptitude: please allow resumption of incomplete downloads
On Tue, Nov 10, 2009 at 02:27:19PM -0500, Celejar cele...@gmail.com was heard to say: On Tue, 10 Nov 2009 08:30:44 -0800 Daniel Burrows dburr...@debian.org wrote: I can look into this, but AFAIK apt has supported resumes since more or less forever, and I can't find notes about disabling it in the changelog. Even if this was a problem, it's in apt's court, not aptitude's, since I still use the apt download queue. Both I and another poster in the d-u thread report this behavior: a progress bar shows that the downloading is in progress, aptitude then reports that it has stalled, and eventually the progress bar resets and the download seems to restart. This can happen repeatedly under poor network conditions. I just tested (by ^C-ing aptitude in the middle of downloading a large package) and resume seemed to work fine. Maybe you're downloading from a mirror that doesn't support resume for some reason? Daniel -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#557580: aptitude accepts /etc/apt/preferences but ignores /etc/apt/preferences.d/*
aptitude has its own replacement for pkgCacheFile that it uses to initialize itself. Arguably this is bad; on the other hand, it seems to be the only way to create a subclass of pkgDepCache during startup instead of creating a straight pkgDepCache. Anyway, it looks like the code to read the policy pin directory was placed into pkgCacheFile. I guess this is now part of the official startup ritual for apt. I still don't see a good way to use pkgCacheFile, unless I'm willing to create a junk pkgDepCache and throw it away (very expensive). I can't even change to using a proxy for the real DepCache, because I need to subclass it in order to configure its behavior. :-( So, I guess I'll just update the cutpaste job. Yuck. Daniel -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#557381: Crashes on exit if a changelog download is still being set up.
Package: aptitude Version: 0.6.1.3-3 Severity: normal aptitude will crash on exit if the background thread that checks for changelogs on the system is still running. The problem is that this thread accesses global apt structures, which are destroyed during shutdown. That thread should be redesigned so it's based on the generic job queue thread class; that way it can easily be shut down when the program exits. Daniel -- Package-specific info: aptitude 0.6.0.1 compiled at Oct 25 2009 19:17:26 Compiler: g++ 4.3.4 Compiled against: apt version 4.8.1 NCurses version 5.7 libsigc++ version: 2.0.18 Ept support enabled. Gtk+ version 2.18.3 Gtk-- version 2.18.2 Current library versions: NCurses version: ncurses 5.7.20090803 cwidget version: 0.5.13 Apt version: 4.8.1 linux-gate.so.1 = (0xb7f39000) libapt-pkg-libc6.9-6.so.4.8 = /usr/lib/libapt-pkg-libc6.9-6.so.4.8 (0xb7e5b000) libncursesw.so.5 = /lib/libncursesw.so.5 (0xb7e17000) liblog4cxx.so.10 = /usr/lib/liblog4cxx.so.10 (0xb7c6d000) libsigc-2.0.so.0 = /usr/lib/libsigc-2.0.so.0 (0xb7c67000) libcwidget.so.3 = /usr/lib/libcwidget.so.3 (0xb7ba4000) libept.so.0 = /usr/lib/libept.so.0 (0xb7b29000) libxapian.so.15 = /usr/lib/libxapian.so.15 (0xb79d9000) libz.so.1 = /usr/lib/libz.so.1 (0xb79c4000) libsqlite3.so.0 = /usr/lib/libsqlite3.so.0 (0xb794) libboost_iostreams.so.1.40.0 = /usr/lib/libboost_iostreams.so.1.40.0 (0xb7935000) libglibmm-2.4.so.1 = /usr/lib/libglibmm-2.4.so.1 (0xb78dc000) libgobject-2.0.so.0 = /usr/lib/libgobject-2.0.so.0 (0xb789f000) libglib-2.0.so.0 = /lib/libglib-2.0.so.0 (0xb77e8000) libgthread-2.0.so.0 = /usr/lib/libgthread-2.0.so.0 (0xb77e2000) librt.so.1 = /lib/i686/cmov/librt.so.1 (0xb77d9000) libgtkmm-2.4.so.1 = /usr/lib/libgtkmm-2.4.so.1 (0xb7492000) libatkmm-1.6.so.1 = /usr/lib/libatkmm-1.6.so.1 (0xb744d000) libgdkmm-2.4.so.1 = /usr/lib/libgdkmm-2.4.so.1 (0xb7404000) libgiomm-2.4.so.1 = /usr/lib/libgiomm-2.4.so.1 (0xb738d000) libpangomm-1.4.so.1 = /usr/lib/libpangomm-1.4.so.1 (0xb735f000) libgtk-x11-2.0.so.0 = /usr/lib/libgtk-x11-2.0.so.0 (0xb6f9c000) libcairomm-1.0.so.1 = /usr/lib/libcairomm-1.0.so.1 (0xb6f7c000) libgdk-x11-2.0.so.0 = /usr/lib/libgdk-x11-2.0.so.0 (0xb6ee7000) libatk-1.0.so.0 = /usr/lib/libatk-1.0.so.0 (0xb6ecb000) libpangoft2-1.0.so.0 = /usr/lib/libpangoft2-1.0.so.0 (0xb6ea5000) libgdk_pixbuf-2.0.so.0 = /usr/lib/libgdk_pixbuf-2.0.so.0 (0xb6e8c000) libpangocairo-1.0.so.0 = /usr/lib/libpangocairo-1.0.so.0 (0xb6e81000) libgio-2.0.so.0 = /usr/lib/libgio-2.0.so.0 (0xb6dec000) libcairo.so.2 = /usr/lib/libcairo.so.2 (0xb6d74000) libpango-1.0.so.0 = /usr/lib/libpango-1.0.so.0 (0xb6d3) libfreetype.so.6 = /usr/lib/libfreetype.so.6 (0xb6cb9000) libfontconfig.so.1 = /usr/lib/libfontconfig.so.1 (0xb6c8e000) libgmodule-2.0.so.0 = /usr/lib/libgmodule-2.0.so.0 (0xb6c8a000) libglademm-2.4.so.1 = /usr/lib/libglademm-2.4.so.1 (0xb6c7f000) libglade-2.0.so.0 = /usr/lib/libglade-2.0.so.0 (0xb6c68000) libxml2.so.2 = /usr/lib/libxml2.so.2 (0xb6b2f000) libm.so.6 = /lib/i686/cmov/libm.so.6 (0xb6b09000) libvte.so.9 = /usr/lib/libvte.so.9 (0xb6a7a000) libpthread.so.0 = /lib/i686/cmov/libpthread.so.0 (0xb6a61000) libstdc++.so.6 = /usr/lib/libstdc++.so.6 (0xb696e000) libgcc_s.so.1 = /lib/libgcc_s.so.1 (0xb6951000) libc.so.6 = /lib/i686/cmov/libc.so.6 (0xb680d000) libutil.so.1 = /lib/i686/cmov/libutil.so.1 (0xb6809000) libdl.so.2 = /lib/i686/cmov/libdl.so.2 (0xb6805000) libaprutil-1.so.0 = /usr/lib/libaprutil-1.so.0 (0xb67e4000) libapr-1.so.0 = /usr/lib/libapr-1.so.0 (0xb67b7000) libuuid.so.1 = /lib/libuuid.so.1 (0xb67b3000) libcrypt.so.1 = /lib/i686/cmov/libcrypt.so.1 (0xb6781000) libbz2.so.1.0 = /lib/libbz2.so.1.0 (0xb6771000) libpcre.so.3 = /lib/libpcre.so.3 (0xb674) /lib/ld-linux.so.2 (0xb7f3a000) libpng12.so.0 = /usr/lib/libpng12.so.0 (0xb671c000) libXrender.so.1 = /usr/lib/libXrender.so.1 (0xb6713000) libX11.so.6 = /usr/lib/libX11.so.6 (0xb65f7000) libXcomposite.so.1 = /usr/lib/libXcomposite.so.1 (0xb65f3000) libXdamage.so.1 = /usr/lib/libXdamage.so.1 (0xb65f) libXfixes.so.3 = /usr/lib/libXfixes.so.3 (0xb65eb000) libXext.so.6 = /usr/lib/libXext.so.6 (0xb65dd000) libXinerama.so.1 = /usr/lib/libXinerama.so.1 (0xb65da000) libXi.so.6 = /usr/lib/libXi.so.6 (0xb65d) libXrandr.so.2 = /usr/lib/libXrandr.so.2 (0xb65c9000) libXcursor.so.1 = /usr/lib/libXcursor.so.1 (0xb65c) libresolv.so.2 = /lib/i686/cmov/libresolv.so.2 (0xb65ac000) libselinux.so.1 = /lib/libselinux.so.1 (0xb6592000)
Bug#557183: More information
On Fri, Nov 20, 2009 at 07:39:11PM +0100, Sven Joachim svenj...@gmx.de was heard to say: On 2009-11-20 06:51 +0100, brian m. carlson wrote: Okay, here's some more information that I think might be useful. I marked packages for upgrade, and libsnmp-base and libsnmp15 are marked for upgrade. libsnmp-base depends on gawk. However, libsnmp-base conflicts with libsmi2-common, and so the dependency resolver got invoked. I chose, using the dependency resolver, not to upgrade either package. However, gawk still gets marked as piA; that is, to-be-installed and automatically so. This sounds very much like #556042 to me, which is fixed in aptitude 0.6.1.3. Alas, that version FTBFS on 64-bit archs. It could also be that the first-pass resolver is selecting that package, and it doesn't get dropped later because it isn't unused. If so, -o Aptitude::Auto-Install=false would probably work around this, at the cost of a lot more explicit dependency resolution. Daniel -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#557150: log4cxx: Please initialize the log4cxx system properly.
Here's the patch. Daniel changeset: 3453:9e92aa37631a tag: tip user:Daniel Burrows dburr...@debian.org date:Thu Nov 19 15:33:11 2009 -0800 summary: Initialize the temporary file module *after* logging so its startup messages don't cause a spurious error (Closes: #557150). diff -r 31be843001d2 -r 9e92aa37631a src/main.cc --- a/src/main.cc Thu Nov 19 09:40:38 2009 -0800 +++ b/src/main.cc Thu Nov 19 15:33:11 2009 -0800 @@ -540,8 +540,6 @@ srandom(time(0)); - temp::initialize(aptitude); - using namespace log4cxx; // See earlier note @@ -943,6 +941,8 @@ log_file)); } + temp::initialize(aptitude); + const bool debug_search = aptcfg-FindB(PACKAGE ::CmdLine::Debug-Search, false); int curr_quiet = aptcfg-FindI(quiet, 0);
Bug#557150: log4cxx: Please initialize the log4cxx system properly.
On Thu, Nov 19, 2009 at 08:32:28PM -0200, Nelson A. de Oliveira nao...@debian.org was heard to say: With the new aptitude version, I am getting this on any action that I call (clean, full-upgrade, etc) # aptitude update log4cxx: No appender could be found for logger (aptitude.temp). log4cxx: Please initialize the log4cxx system properly. (...) Oh, fer crying out loud. How did I do that without noticing? Thanks for pointing this out, should be fixed when I get time to build a new version. Daniel -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#552525: broken alternatives for aptitude
On Wed, Nov 18, 2009 at 08:54:32AM +0100, Ivan Sergio Borgonovo ivan@gmail.com was heard to say: On Tue, 17 Nov 2009 16:45:26 -0800 Daniel Burrows dburr...@debian.org wrote: update-alternatives runs in the postinst of aptitude 0.6.0.1-1. That package doesn't provide /usr/bin/aptitude (previous versions did), so I wonder how it was still on the system when the postinst ran? Does dpkg -S /usr/bin/aptitude show anything? diversion by ia32-apt-get from: /usr/bin/aptitude diversion by ia32-apt-get to: /usr/bin/aptitude.real ia32-apt-get: /usr/bin/aptitude Ah, well, there's the problem. Now I just need to figure out what to do with it. Daniel -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#552525: broken alternatives for aptitude
On Wed, Nov 18, 2009 at 08:54:32AM +0100, Ivan Sergio Borgonovo ivan@gmail.com was heard to say: On Tue, 17 Nov 2009 16:45:26 -0800 Daniel Burrows dburr...@debian.org wrote: update-alternatives runs in the postinst of aptitude 0.6.0.1-1. That package doesn't provide /usr/bin/aptitude (previous versions did), so I wonder how it was still on the system when the postinst ran? Does dpkg -S /usr/bin/aptitude show anything? diversion by ia32-apt-get from: /usr/bin/aptitude diversion by ia32-apt-get to: /usr/bin/aptitude.real ia32-apt-get: /usr/bin/aptitude According to packages.debian.org, ia32-apt-get doesn't exist. I guess this is some local package you built? Daniel -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#552525: broken alternatives for aptitude
On Wed, Nov 18, 2009 at 12:55:28PM +0100, Sven Joachim svenj...@gmx.de was heard to say: On 2009-11-18 12:25 +0100, Daniel Burrows wrote: According to packages.debian.org, ia32-apt-get doesn't exist. I guess this is some local package you built? No, ia32-apt-get had been in unstable for some time as a replacement for ia32-libs, but it has been removed because many people (including, most relevant, the FTP masters) considered it to be too buggy. You can read the discussion in the threads starting at http://lists.debian.org/debian-devel/2009/06/msg00902.html and http://lists.debian.org/debian-devel/2009/06/msg00955.html. Since ia32-apt-get does not exist anymore and thus cannot be fixed to stop shipping this diverted /usr/bin/aptitude, the only option is to declare a conflict with it in the aptitude package, AFAICS. Yeah, I think that's exactly the right solution. Thanks for the info (probably I should learn to use Google before I talk :P ). Daniel -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#556879: aptitude: segfaults on a why-not call under a situation with conflicts and holds
Can you reproduce this crash with aptitude 0.6.0 from unstable? Thanks, Daniel -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#556881: Is it that obvious?
Personally, I think that assuming that bar should be installed without any more hints from the user is a bit of a stretch; they asked to install foo, not bar, and it can't be installed. I don't know that aptitude should be trying to second-guess its command line here. I do think that it would make sense for aptitude to print out a list of packages that C/P/R foo. Daniel -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
