>> Some do stand out quite harshly. Consider #651748 [1] where the UI >> is trashed by multi-arch related error messages from the resolver. >> This is non-fatal but still a serious blocker. > > Is this multiarch specific? > > IIRC I got this noise way before multiarch, there was just way less > noise before there were packages aptitude does not understand. >
Indeed. Before m-a the messages were very infrequent, one could consider this a less than serious issue. After m-a such messages are now frequently encountered when performing any non-trivial action. Getting noticeably more garbage on the screen is a problem. > Now that aptitude understands multiarch packages you should not get > bazillions of errors. > Have you been using the in-development version and noticed less errors, or is this just speculation? If you have been using that version, then this is useful information. Obviously I can know what is happening on my system which is only a small m-a chroot for the moment--not the most extensive test setup. > Sure, it's still potential problem that there is no rate limit on > these messages or anything but it's no longer likely that you will not > see any UI at all due to messages rolling all over your screens > constantly. > [The standard C-l works in aptitude to refresh the screen.] The underlying problem is that these internal debug messages should not be dumped to stdout while using the curses interface. They should either direct to a file by default or be captured using apt-pkg/contrib/error.h like other error messages. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/831768 Title: aptitude cannot handle conflicts with multiarch enabled To manage notifications about this bug go to: https://bugs.launchpad.net/aptitude/+bug/831768/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
