Bug#984814: fbless: search is broken
Package: fbless Version: 0.2.3-4 Severity: normal After upgrade of fbless from 0.2.3-3 to 0.2.3-4 search is no longer working. anything always ends with Traceback (most recent call last): File "/usr/bin/fbless", line 23, in MainWindow().main_loop() File "/usr/lib/python3/dist-packages/fbless_lib/main.py", line 747, in main_loop self.search() File "/usr/lib/python3/dist-packages/fbless_lib/main.py", line 409, in search s = str(s, default_charset, errors='ignore') TypeError: decoding str is not supported Additionally, when non-ascii letters are used they are displayed as if utf-8-encoded text was treated as latin1-encoded text and then recoded to utf-8. I.e., /фыва becomes Search pattern: Ñ Ñ Ð²Ð° Looks like curses module works differently with text encodings in python3.
Bug#968498: fbless cant open files
control: severity -1 important
control: tags -1 patch
On Sun, Aug 16, 2020 at 02:58:30PM +0300, Alexander Inyukhin wrote:
> Package: fbless
> Version: 0.2.3-4
> Severity: normal
>
> fbless failed to open files with exception
>
> Traceback (most recent call last):
> File "/usr/bin/fbless", line 23, in
> MainWindow().main_loop()
> File "/usr/lib/python3/dist-packages/fbless_lib/main.py", line 79, in
> __init__
> self.content = create_content(self.filename, curses.COLS)
> File "/usr/lib/python3/dist-packages/fbless_lib/main.py", line 1073, in
> create_content
> if data.startswith(' TypeError: startswith first arg must be bytes or a tuple of bytes, not str
This is because python3 patch is not complete. As a result, opening
of zip files (which seems to be the most common way fb2 files are
used) is broken. Fortunately the fix is trivial:
--- fbless-0.2.3.orig/fbless_lib/main.py
+++ fbless-0.2.3/fbless_lib/main.py
@@ -1070,7 +1070,7 @@ def create_content(filename, scr_cols):
zf = zipfile.ZipFile(filename)
for zip_filename in zf.namelist():
data = zf.read(zip_filename)
-if data.startswith('
Bug#882272: libc6:amd64: upgrade of libc6:amd64 + libc6:i386 + libc6-i686 breaks system
Package: libc6
Version: 2.24-11+deb9u1
Severity: critical
Justification: breaks the whole system
Upgrade of glibc packages from jessie to stretch versions failed
resulting in most programs (presumably all non-static 32-bit ones) to
segfault on start. I believe the following happend:
1. libc6:i386 and libc6:amd64 2.24-11+deb9u1 were unpacked,
/etc/ld.so.nohwcap was created by preinst scripts.
2. postinst of libc6:amd64 started running and removed
/etc/ld.so.nohwcap (as $hwcappkgs is empty for amd64).
3. As libc6-i686 2.19-18+deb8u10 was still installed most applications
started segfaulting (including most essential ones).
Unfortunately, I did not have any root shell open, and while
export LD_HWCAP_MASK=0
workaround worked on many applications, it had no effect on setuid
programs (like su and sudo). I had to resolve the problem by rebooting
system with break=init argument and running
touch /root/etc/ld.so.nohwcap
from initramfs shell (and later calling
dpkg --purge libc6-i686
before finishing upgrade of libc6:amd64).
This probably should be fixed by replacing
case ${DPKG_MAINTSCRIPT_ARCH} in
alpha)
hwcappkgs="libc6-alphaev67"
;;
i386)
hwcappkgs="libc6-i686 libc6-xen"
;;
kfreebsd-i386)
hwcappkgs="libc0.1-i686"
;;
esac
with something like
hwcappkgs="libc6-alphaev67 libc6-i686 libc6-xen libc0.1-i686"
or
hwcappkgs="libc6.1-alphaev67:alpha libc6-i686:i386 libc6-xen:i386
libc0.1-i686:kfreebsd-i386"
in debian/script.in/nohwcap.sh.
sghpc% sudo apt upgrade
Чтение списков пакетов… Готово
Построение дерева зависимостей
Чтение информации о состоянии… Готово
Расчёт обновлений…Следующие пакеты устанавливались автоматически и больше не
требуются:
aumix aumix-common bzip2-doc gdb-doc libc6-i686
linux-image-3.16.0-4-amd64:amd64 linux-image-4.9.0-3-amd64-dbg:amd64
python-networkx python-pygraphviz python-skimage python-skimage-lib
Для их удаления используйте «apt-get autoremove».
Готово
НОВЫЕ пакеты, которые будут установлены:
libc-l10n
Пакеты, которые будут оставлены в неизменном виде:
geeqie geeqie-common geeqie-dbg
Пакеты, которые будут обновлены:
glibc-doc libc-bin libc-dev-bin libc6 libc6:amd64 libc6-dbg libc6-dbg:amd64
libc6-dev libc6-i686 locales locales-all
multiarch-support
обновлено 12, установлено 1 новых пакетов, для удаления отмечено 0 пакетов, и 3
пакетов не обновлено.
Необходимо скачать 0 B/44,6 MB архивов.
После данной операции, объём занятого дискового пространства уменьшится на 9
642 kB.
Хотите продолжить? [Д/н]
Чтение журнала изменений... Выполнено
apt-listchanges: Хотите продолжить? [Y/n]
apt-listchanges: Отправка почты root: apt-listchanges: журнал изменений sghpc
apt-listchanges: Отправка почты root: apt-listchanges: новости о sghpc
Предварительная настройка пакетов ...
(Чтение базы данных … на данный момент установлено 803482 файла и каталога.)
Подготовка к распаковке …/locales_2.24-11+deb9u1_all.deb …
Распаковывается locales (2.24-11+deb9u1) на замену (2.19-18+deb8u10) …
Выбор ранее не выбранного пакета libc-l10n.
Подготовка к распаковке …/libc-l10n_2.24-11+deb9u1_all.deb …
Распаковывается libc-l10n (2.24-11+deb9u1) …
Подготовка к распаковке …/locales-all_2.24-11+deb9u1_i386.deb …
Распаковывается locales-all (2.24-11+deb9u1) на замену (2.19-18+deb8u10) …
Подготовка к распаковке …/libc6_2.24-11+deb9u1_i386.deb …
Деконфигурируется libc6:amd64 (2.19-18+deb8u10) …
Checking for services that may need to be restarted...
Checking init
scripts...##.]
Распаковывается libc6:i386 (2.24-11+deb9u1) на замену (2.19-18+deb8u10) …
Подготовка к распаковке …/libc6_2.24-11+deb9u1_amd64.deb
….]
Checking for services that may need to be
restarted]
Checking init scripts...
Распаковывается libc6:amd64 (2.24-11+deb9u1) на замену (2.19-18+deb8u10) …
Настраивается пакет libc6:amd64 (2.24-11+deb9u1)
….]
dpkg: ошибка при обработке пакета libc6:amd64
(--configure):...]
подпроцесс установлен сценарий post-installation уничтожен по сигналу (Ошибка
сегментирования)
Настраивается пакет libc6:i386 (2.24-11+deb9u1) …
Устанавливается новая версия файла настройки
/etc/ld.so.conf.d/i386-linux-gnu.conf …
dpkg: ошибка при обработке пакета libc6:i386
(--configure):]
подпроцесс установлен сценарий post-installation уничтожен по сигналу (Ошибка
сегментирования)
При обработке следующих пакетов произошли ошибки:
libc6:amd64
libc6:i386
E: Sub-process /usr/bin/dpkg returned an error code (1)
E: Problem executing scripts DPkg::Post-Invoke
Bug#844018: libcurl3: Building with OpenSSL 1.1 breaks packages using both OpenSSL 1.0 and curl
22.11.2016 в 22:57:30 +0200 Adrian Bunk написал: > 23:14 < bunk> Q_: If you come up with a better patch than mine in #844018, > please post to that bug. I know that my patch is not pretty, > but > I did not find any better short-term solution. Search for CURLOPT_SSL_CTX_FUNCTION on codesearch.debian.net produces the following list of potentially affected packages: cargo chromium-browser cmake criticalmass curl curlpp firefox firefox-esr fpc hhvm icedove lastpass-cli libapache2-mod-auth-cas libwww-curl-perl lua-curl netcdf netsurf openjfx r-cran-curl r-cran-rcurl ruby-curb slcurl sx tclcurl wpa xmltooling zurl So the the alternative to you patch looks like: fixing #828564 (fixed-upstream, new upstream version available), fixing #828608 or removing xmltooling out of testing, checking whether last apache2 upload fixed #844799, fixing or ignoring #828259 (not in testing, fixed upstream version available), fixing #828371 (untested patch available) or removing lastpass-cli, removing 3 characters from zurl's debian/control, binnmu-ing affected packages that still depend on libssl1.0.2, no need to ensure that applications (even if they are linked with libcurl3 indirectly) are linked with the same libssl as libcurl3 (unlike with the patch), more compatibility with applications from jessie than with the patch.
Bug#844018: libcurl3: Building with OpenSSL 1.1 breaks packages using both OpenSSL 1.0 and curl
20.11.2016 в 22:35:26 +0100 Jan Niehusmann написал:
> On Mon, Nov 21, 2016 at 01:03:19AM +0400, Stepan Golosunov wrote:
> > So far I do not know why using libssl1.1 together with a
> > libssl1.0.2-using Qt wouldn't work.
>
> Well I don't know enough about the dynamic linker and about the internals
> of openssl to know if (indirectly) linking to both libraries at the same
> time is fine.
Indirectly linking with both libraries is supposed to work due to
symbol versioning. If it wasn't than OpenSSL transition wouldn't have
started. And parts of Qt are already linked with libssl1.1 (via
libpq5). Problems could (and did in previous transition) arise if
code (Qt or application) is initializing one libssl while parts of
application are using another but this is supposed to be fixed for
libssl1.1.
And the problem with Qt is that it is not actually linked with OpenSSL
but uses it via dlopen. My reading of dlsym(3) suggests that it
should work but I could be misreading the documentation or it can be
incorrect.
> If it was, that would be great news. Many mails in the thread "OpenSSL
> 1.1.0" on debian-devel seem to be based on the assumption that such
> linking could cause bugs, and therefore packages can only transition in
> clusters of packages linking to the same version of openssl.
If application passes OpenSSL objects between the two libraries than
it won't work.
> Still, qt is only an example - the same holds true for other libraries
> linking to openssl1.0-dev. There may be cases where your 2nd case
> ('Application passes OpenSSL objects from libssl1.1 to ...') is more
> probable than with qt.
I expect that if libcurl3 is linked with libssl1.0.2 there would be more
problematic applications (as applications need to link with
libssl1.0.2 and run initialization in this case) than if curl is
linked with libssl1.1 (as applications not using
CURLOPT_SSL_CTX_FUNCTION-like functionality are free to link with
whatever libssl they want or not to link with it at all).
> The safest way to avoid hidden bugs would still be changing SONAME and
> package name, so package maintainers would be aware of the change and
> could check their packages for compatibility.
>
> But yes, it may be less work to somehow identify affected packages and
> handle them directly instead of forcing all packages depending on curl
> through a transition. Identifying those packages in a reliable way could
> be difficult, though.
If libcurl3 is linked with libssl1.1 then maintainer needs to
explicitly break his application (like happened with zurl 1.7.1-1).
The rest just need to be recompiled (and they need to be recompiled in
any case).
The part of the bug where dependencies are insufficiently tough and
libcurl does not change its SONAME exists independently of which
libssl it is linked to (as long as that libssl is different from the
one used in jessie).
Bug#844018: libcurl3: Building with OpenSSL 1.1 breaks packages using both OpenSSL 1.0 and curl
20.11.2016 в 21:29:35 +0100 Jan Niehusmann написал: > On Mon, Nov 21, 2016 at 12:02:45AM +0400, Stepan Golosunov wrote: > > It would be a grave bug in such application if it does not have a > > working version, yes. Whether or not it would be a serious bug in > > lubcurl3 depends on how many and how important such applications are. > > (And how difficult they are to fix.) > > As there are applications which depend on libcurl and qt, and it seems > like qt can't be ported to openssl 1.1 in time for stretch, fixing such > applications would mean uploading a version of curl linked to openssl > 1.0. This could be a new package, or a statically linked version etc. - > IMHO all worse than just linking the curl package with openssl 1.0 until > (close to) all packages are ready for a transition to openssl 1.1. So far I do not know why using libssl1.1 together with a libssl1.0.2-using Qt wouldn't work. So far I can imagine the following reasons: 1. Application relies on Qt initializing the library. That was the cause of breakage during libssl1.0.0 -> libssl1.0.2 transition, but is not applicable now as libssl1.1 does not require explicit initialization. 2. Application passes OpenSSL objects from libssl1.1 to Qt (or vice versa). Why one would do it? 3. dlsym(3) is used with RTLD_DEFAULT or RTLD_NEXT. Does not seem to be the case. 4. dlsym(3) finds wrong library. Manual page suggests that should not be the case. … Is any of the above applicable?
Bug#844018: libcurl3: Building with OpenSSL 1.1 breaks packages using both OpenSSL 1.0 and curl
20.11.2016 в 20:01:25 +0100 Jan Niehusmann написал: > On Sun, Nov 20, 2016 at 07:40:22PM +0400, Stepan Golosunov wrote: > > If SONAME change is needed it is needed when linking libcurl with > > libssl1.0.2 too. (But when linking libcurl with libssl1.0.2 more > > applications are affected due to the need of explicit initialization.) > > Upstream documentation suggests that this is not true: > > "Minor releases that change the last digit, e.g. 1.0.1 vs. 1.0.2, can > and are likely to contain new features, but in a way that does not break > binary compatibility. This means that an application compiled and > dynamically linked with 1.0.0 does not need to be recompiled when the > shared library is updated to 1.0.2." > (https://www.openssl.org/policies/releasestrat.html) > > But of course, in practice, there may have been unintended ABI changes > - so yes, may be a SONAME change is nessary for 1.0.2 as well. I just > don't know. SONAME for OpenSSL 1.0.2 in Debian was changed because it was recompiled with different options to remove some deprecated (but widely used) functions. And if application initializes libssl1.0.0 then libssl1.0.2 is left uninitialized and does not work correctly, while libssl1.1 does not need explicit initialization at all. OpenSSL libraries have lots of global state, so passing pointers created with libssl1.0.2 to libssl1.0.0 isn't safe. Different features and implementation details of the two libraries are likely to cause problems too in that case. > Still, for 1.1 the SONAME change is definitely necessary. Breaks: against applications using CURLOPT_SSL_CTX_FUNCTION and compiled with OpenSSL 1.0 will probably suffice in that case.
Bug#844018: libcurl3: Building with OpenSSL 1.1 breaks packages using both OpenSSL 1.0 and curl
20.11.2016 в 23:38:48 +0400 Stepan Golosunov написал: > 20.11.2016 в 20:01:25 +0100 Jan Niehusmann написал: > > Still, for 1.1 the SONAME change is definitely necessary. > > Breaks: against applications using CURLOPT_SSL_CTX_FUNCTION and > compiled with OpenSSL 1.0 will probably suffice in that case. No, that won't be sufficient. One must also ensure that applications compiled with libssl1.1-using libcurl3 also depend on such libcurl3 (both for the sake of applications using CURLOPT_SSL_CTX_FUNCTION and applications dropping OpenSSL initialization).
Bug#844018: libcurl3: Building with OpenSSL 1.1 breaks packages using both OpenSSL 1.0 and curl
20.11.2016 в 20:48:44 +0100 Jan Niehusmann написал: > On Sun, Nov 20, 2016 at 11:38:49PM +0400, Stepan Golosunov wrote: > > > Still, for 1.1 the SONAME change is definitely necessary. > > > > Breaks: against applications using CURLOPT_SSL_CTX_FUNCTION and > > compiled with OpenSSL 1.0 will probably suffice in that case. > > Wouldn't this still be a serious bug as it would - explicitly - break > those applications? It would be a grave bug in such application if it does not have a working version, yes. Whether or not it would be a serious bug in lubcurl3 depends on how many and how important such applications are. (And how difficult they are to fix.)
Bug#844018: libcurl3: Building with OpenSSL 1.1 breaks packages using both OpenSSL 1.0 and curl
11.11.2016 в 21:30:07 +0100 Jan Niehusmann написал: > the curl ABI contains structs inherited from OpenSSL, e.g. in calls > like: > > curl_easy_setopt(easy, CURLOPT_SSL_CTX_FUNCTION, _cb); > > Here, sslCtxFunction_cb is a function which takes an SSL_CTX * as a > parameter. > > (This is from zurl, one example of a package affected by this bug.) > > Since 7.51.0-1, curl links against OpenSSL 1.1 instead of OpenSSL 1.0 > (implicitly caused by an update of libssl-dev, not by a change to the > curl package). This changes the structure of SSL_CTX, which in turn > changes the above mentioned ABI and breaks zurl (and possibly other > packages). And libcurl3 in testing links with libssl1.0.2 while libcurl3 in jessie links with libssl1.0.0. And while structure of SSL_CTX is probably identical in this case, global state of libssl is different, as well as code and supported features are different. Also, when libcurl is linked with OpenSSL older then 1.1 many applications need to be linked with the same OpenSSL libraries as curl as they need to initialize libssl as described in https://lists.debian.org/debian-devel/2016/11/msg00718.html With OpenSSL 1.1 this requirement goes away, as newer OpenSSL initializes itself automatically (and if application initializes old version of OpenSSL no harm is done). > Such ABI changes require a SONAME change, according to policy 8.1, > exactly to avoid breaking other packages which use the library. > > Therefore, please consider changing the SONAME (and the name of the > binary package). Alternatively, build-depend on libssl1.0-dev, to link > against OpenSSL 1.0 and keep the old ABI. If SONAME change is needed it is needed when linking libcurl with libssl1.0.2 too. (But when linking libcurl with libssl1.0.2 more applications are affected due to the need of explicit initialization.)
Bug#844148: acl2: FTBFS: certification failed directory
14.11.2016 в 11:24:04 -0500 Camm Maguire написал(а): > Neither ACL2 nor underlying gcl makes any use of threads or locks, but Note that the failing memoize-tests.lisp creates some sort of threads and mentions lock contention in comments. > > **CERTIFICATION FAILED** for > > /<>/books/system/hons-check/memoize-tests.lisp > > > > /<>/books/build/make_cert:106: recipe for target > > 'system/hons-check/memoize-tests.cert' failed > > make[2]: *** [system/hons-check/memoize-tests.cert] Error 1
Bug#828240: asterisk: FTBFS with openssl 1.1.0
06.11.2016 в 23:39:41 +0100 Bernhard Schmidt написал(а): > On Sun, Nov 06, 2016 at 04:39:03PM +0400, Stepan Golosunov wrote: > > 06.11.2016 в 16:18:32 +0400 Stepan Golosunov написал: > > > #if defined(HAVE_OPENSSL) && OPENSSL_VERSION_NUMBER >= 0x1010L > > > /* No explicit initialization is needed with OpenSSL 1.1.0. > > >All the functions called or overridden in this file were removed. */ > > > #undef HAVE_OPENSSL > > > #endif > Thanks a lot, your suggestion together with > https://anonscm.debian.org/cgit/pkg-voip/asterisk.git/commit/?id=ec0143a92f4ced996be419bf49115be8f236e3ea > > leads to something that builds and runs. Yay! > > @Tzafrir: What do you think of this? Your patch is touching > main/libasteriskssl.c as well, but Stepan suggested to drop even more. Note that code in ast_ssl_init would still call functions from libssl1.0.2, even if compiled with OpenSSL 1.1.0 (but with the wrong value for CRYPTO_num_locks(), 1 instead of 41). Or return -1 if libssl.so.1.0.2 is not loaded. (Though not running that code can be problematic if libssl1.0.2 is not only loaded but actually used via some third library.) And I suspect that OPENSSL_API_COMPAT is wrong value for conditional compilation (it's not defined in OpenSSL 1.0.2 for example).
Bug#828240: asterisk: FTBFS with openssl 1.1.0
06.11.2016 в 16:18:32 +0400 Stepan Golosunov написал: > 03.11.2016 в 09:24:19 +0100 Bernhard Schmidt написал(а): > > - Asterisk is doing some weird stuff with macros in > > > > https://sources.debian.net/src/asterisk/1:13.11.2~dfsg-1/main/libasteriskssl.c/ > > that causes the build against 1.1.0 to fail. This is beyond my C > > knowledge. I will gladly test and accept any patch for that. > > I think that > > #if defined(HAVE_OPENSSL) && OPENSSL_VERSION_NUMBER >= 0x1010L > /* No explicit initialization is needed with OpenSSL 1.1.0. >All the functions called or overridden in this file were removed. */ > #undef HAVE_OPENSSL > #endif > > should be added after ASTERISK_FILE_VERSION in libasteriskssl.c. After or inside #ifdef HAVE_OPENSSL #include #include #endif seems more apropriate as #include is still needed to get OPENSSL_VERSION_NUMBER.
Bug#828240: asterisk: FTBFS with openssl 1.1.0
03.11.2016 в 09:24:19 +0100 Bernhard Schmidt написал(а): > - Asterisk is doing some weird stuff with macros in > > https://sources.debian.net/src/asterisk/1:13.11.2~dfsg-1/main/libasteriskssl.c/ > that causes the build against 1.1.0 to fail. This is beyond my C > knowledge. I will gladly test and accept any patch for that. I think that #if defined(HAVE_OPENSSL) && OPENSSL_VERSION_NUMBER >= 0x1010L /* No explicit initialization is needed with OpenSSL 1.1.0. All the functions called or overridden in this file were removed. */ #undef HAVE_OPENSSL #endif should be added after ASTERISK_FILE_VERSION in libasteriskssl.c. (The fact that the functions were removed also means that asterisk compiled with OpenSSL 1.0.2 probably won't break when both 1.0.2 and 1.1.0 are loaded. But probably will break if libssl1.0.0 from jessie is loaded.)
Bug#672275: libgtk2.0-0: unquoted *.so in postinst
Control: close -1 2.24.20-1 09.09.2016 в 23:09:49 +0200 Michael Biebl написал: > Version: 2.24.30-4 > > On Wed, 9 May 2012 19:47:08 +0400 Stepan Golosunov > <ste...@golosunov.pp.ru> wrote: > > Package: libgtk2.0-0 > > Version: 2.24.10-1 > > Severity: normal > > > > postinst script in libgtk2.0-0 contains two unquoted "*.so" > > strings. This will cause troubles if any .so file exists in current > > directory (which appears to be / normally). Especially if a file > > with the same name exists in $IMMODULES_DIR. > > Doesn't seem to be the case anymore in a recent version of libgtk2.0-0, > so closing this bug report. Yes, this looks fixed. Trying to actually close the bug.
Bug#814067: Buffer overflow in xdelta3
Package: xdelta3 Severity: grave Tags: security upstream fixed-upstream xdelta3 before 3.0.9 contains buffer overflow which allows arbitrary code execution from input files at least on some systems. 3.0.0.dfsg-1 and 3.0.8-dfsg-1 are definitly affected. 08.02.2016 в 06:57:12 +0100 Salvatore Bonaccorso написал: > On Sun, Feb 07, 2016 at 07:05:12PM +0400, Stepan Golosunov wrote: > > This appears to be fixed in xdelta3 3.0.9 and later via > > https://github.com/jmacd/xdelta-devel/commit/ef93ff74203e030073b898c05e8b4860b5d09ef2 > > but not in Debian. > > > > What should be done next? Should I open a bug? > > Yes, since the commit is in the public git repo I think it is best to > open a bug in the Debian BTS. > p.s.: Just noticed there seem to be two git repositories by jmacd, the > commit is as well in > > https://github.com/jmacd/xdelta/commit/969e65d3a5d70442f5bafd726bcef47a0b48edd8 README.md says that this repository contains old data from https://code.google.com/p/xdelta. Newer code and releases are currently only in xdelta-devel.
Bug#813631: libdatetime-timezone-perl: Chita is misspelled in the changelog
Package: libdatetime-timezone-perl Version: 1:1.95-1+2016a Severity: minor Chita is misspelled in the changelog: >* Import upstream version 1.95. > Based on version 2016a of the Olson database. This release includes > contemporary changes for the Cayman Islands, Iran, and Chrita, Russia. (Looks like 1:1.75-2+2016a is affected too.)
Bug#722880: /usr/bin/apt-get: Re: apt: Apt fails to solve some dependencies in a multiarch scenario.
30.01.2016 в 01:15:27 +0100 Michal Suchanek написал: > I still cannot install arch:i386 package that depends on arch:all > package because apt wrongly tries to search for the arch:all package as > arch:i386. > > # apt-get -m -d install libgtksourceview2.0-0:i386 > Reading package lists... Done > Building dependency tree > Reading state information... Done > Some packages could not be installed. This may mean that you have > requested an impossible situation or if you are using the unstable > distribution that some required packages have not yet been created > or been moved out of Incoming. > The following information may help to resolve the situation: > > The following packages have unmet dependencies: > libgtksourceview2.0-0:i386 : Depends: libgtksourceview2.0-common:i386 (>= > 2.10) but it is not installable > Depends: libgtksourceview2.0-common:i386 (< > 2.11) but it is not installable > E: Unable to correct problems, you have held broken packages. That's exactly the expected situation given that libgtksourceview2.0-common package forbids installation of foreign-arch reverse dependencies by not providing a "Multi-Arch: foreign" header. Lack of that header is probably a bug in libgtksourceview2.0-common. > Architecture: armhf (armv7l) > Foreign Architectures: i386
Bug#771153: init-system-helpers: Please do not depend on new perl
19.01.2016 в 00:38:19 +0100 Michael Biebl написал: > Am 27.11.2014 um 07:08 schrieb Stepan Golosunov: > > Package: init-system-helpers > > Version: 1.22 > > > > init-system-helpers 1.22 introduced a versioned Depends: on > > perl-base. This needlessly complicates upgrades and backports by > > forcing perl and its reverse dependencies to be upgraded when > > installing init-system-helpers and its reverse dependencies. > > > > > > Please change > > > > Depends: perl-base (>= 5.20.1-3) > > > > into > > > > Depends: perl-base (>= 5.20.1-3) | perl > > > > to allow this dependency to be satisfied by perl from wheezy. > > Jessie has been released for a while and we didn't receive any bug > reports related to upgrade problems. > > In you initial bug report you wrote that this would complicate upgrades. > Apparently this didn't really happen, so I guess this bug can be closed > now. Or do you still see value in keeping this bug report open (and if > so, why). It does complicate upgrades, but probably not too much. At this stage it's probably not worth fixing, so it probably can be closed.
Bug#722880: /usr/bin/apt-get: Re: apt: Apt fails to solve some dependencies in a multiarch scenario.
30.01.2016 в 22:50:52 +0100 Michal Suchanek написал: > On 30 January 2016 at 10:22, Stepan Golosunov <ste...@golosunov.pp.ru> wrote: > > 30.01.2016 в 01:15:27 +0100 Michal Suchanek написал: > >> I still cannot install arch:i386 package that depends on arch:all > >> package because apt wrongly tries to search for the arch:all package as > >> arch:i386. > >> > >> # apt-get -m -d install libgtksourceview2.0-0:i386 > >> Reading package lists... Done > >> Building dependency tree > >> Reading state information... Done > >> Some packages could not be installed. This may mean that you have > >> requested an impossible situation or if you are using the unstable > >> distribution that some required packages have not yet been created > >> or been moved out of Incoming. > >> The following information may help to resolve the situation: > >> > >> The following packages have unmet dependencies: > >> libgtksourceview2.0-0:i386 : Depends: libgtksourceview2.0-common:i386 (>= > >> 2.10) but it is not installable > >> Depends: libgtksourceview2.0-common:i386 (< > >> 2.11) but it is not installable > >> E: Unable to correct problems, you have held broken packages. > > > > That's exactly the expected situation given that > > libgtksourceview2.0-common package forbids installation of > > foreign-arch reverse dependencies by not providing a > > "Multi-Arch: foreign" header. > > > > Lack of that header is probably a bug in libgtksourceview2.0-common. > > Lack of multiarch headers is probably a bug in libgtksourceview2.0 all > right. That would prevent installing the library for two archs. I > install only Arch:i386 and Arch:all package so there should be nothing > preventing the installation. Arch:all is still Arch:all. Yes, lack of Multi-Arch header in libgtksourceview2.0 does prevent installation of the library for two archs. But I am talking about lack of Multi-Arch header in libgtksourceview2.0-common, not in libgtksourceview2.0. And that one forbids installation of foreign reverse dependencies of libgtksourceview2.0-common. And libgtksourceview2.0-0:i386 happens to be such a foreign reverse dependency on an armhf system. And no, Arch:all is Arch:armhf on an armhf system. And dpkg does not implement any mechanism to change that for one package.
Bug#798255: erlang-cl: installs non-free packages
Package: erlang-cl Version: 1.2.1-2 Severity: important Installation of erlang-cl pulls in non-free fglrx and nvidia packages: % apt -s install erlang-cl NOTE: This is only a simulation! apt-get needs root privileges for real execution. Keep also in mind that locking is deactivated, so don't depend on the relevance to the real current situation! Reading package lists... Done Building dependency tree Reading state information... Done The following extra packages will be installed: amd-libopencl1 erlang-base erlang-crypto erlang-syntax-tools glx-alternative-mesa glx-alternative-nvidia glx-diversions libnvidia-compiler libsctp1 lksctp-tools nvidia-alternative nvidia-installer-cleanup nvidia-modprobe nvidia-opencl-common nvidia-opencl-icd Suggested packages: erlang-tools erlang erlang-manpages erlang-doc libgl1-mesa-glx libgl1 nvidia-driver libcuda1 Recommended packages: amd-opencl-icd opencl-icd The following NEW packages will be installed: amd-libopencl1 erlang-base erlang-cl erlang-crypto erlang-syntax-tools glx-alternative-mesa glx-alternative-nvidia glx-diversions libnvidia-compiler libsctp1 lksctp-tools nvidia-alternative nvidia-installer-cleanup nvidia-modprobe nvidia-opencl-common nvidia-opencl-icd 0 upgraded, 16 newly installed, 0 to remove and 0 not upgraded. Even with --no-install-recommends it pulls amd-opencl-icd: % apt -s --no-install-recommends install erlang-cl NOTE: This is only a simulation! apt-get needs root privileges for real execution. Keep also in mind that locking is deactivated, so don't depend on the relevance to the real current situation! Reading package lists... Done Building dependency tree Reading state information... Done The following extra packages will be installed: amd-libopencl1 erlang-base Suggested packages: erlang-tools erlang erlang-manpages erlang-doc Recommended packages: amd-opencl-icd opencl-icd libsctp1 erlang-crypto erlang-syntax-tools The following NEW packages will be installed: amd-libopencl1 erlang-base erlang-cl 0 upgraded, 3 newly installed, 0 to remove and 0 not upgraded. Inst amd-libopencl1 (1:14.9+ga14.201-2 Debian:8.2/stable [i386]) Inst erlang-base (1:17.3-dfsg-4 Debian:8.2/stable [i386]) Inst erlang-cl (1.2.1-2 Debian:8.2/stable [i386]) Conf amd-libopencl1 (1:14.9+ga14.201-2 Debian:8.2/stable [i386]) Conf erlang-base (1:17.3-dfsg-4 Debian:8.2/stable [i386]) Conf erlang-cl (1.2.1-2 Debian:8.2/stable [i386]) Manual installation of ocl-icd-libopencl1 allows to avoid the issue: % apt -s install erlang-cl ocl-icd-libopencl1 NOTE: This is only a simulation! apt-get needs root privileges for real execution. Keep also in mind that locking is deactivated, so don't depend on the relevance to the real current situation! Reading package lists... Done Building dependency tree Reading state information... Done The following extra packages will be installed: erlang-base erlang-crypto erlang-syntax-tools libsctp1 lksctp-tools Suggested packages: erlang-tools erlang erlang-manpages erlang-doc opencl-icd The following NEW packages will be installed: erlang-base erlang-cl erlang-crypto erlang-syntax-tools libsctp1 lksctp-tools ocl-icd-libopencl1 0 upgraded, 7 newly installed, 0 to remove and 0 not upgraded. Probably ocl-icd-libopencl1 should be listed as a first alternative either in all libopencl* dependencies or in the first one. Currently it is listed only in the last one: % apt-cache show erlang-cl|grep ^Depends: Depends: erlang-base (>= 1:17.0-dfsg) | erlang-base-hipe (>= 1:17.0-dfsg), libc6 (>= 2.4), libopencl-1.1-1, libopencl-1.2-1, ocl-icd-libopencl1 (>= 1.0) | libopencl1 -- System Information: Debian Release: 8.2 APT prefers stable-updates APT policy: (900, 'stable-updates'), (900, 'stable') Architecture: i386 (i686) Kernel: Linux 3.16.0-4-686-pae (SMP w/1 CPU core) Locale: LANG=ru_RU.UTF-8, LC_CTYPE=ru_RU.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system)
Bug#798255: [Pkg-erlang-devel] Bug#798255: erlang-cl: installs non-free packages
Control: tags -1 - moreinfo
On Mon, Sep 07, 2015 at 03:19:27PM +0300, Sergei Golovan wrote:
> tags 798255 + moreinfo
> thanks
>
> Hi Stepan!
>
> On Mon, Sep 7, 2015 at 2:25 PM, Stepan Golosunov <ste...@golosunov.pp.ru>
> wrote:
> >
> > Installation of erlang-cl pulls in non-free fglrx and nvidia packages:
>
> Well, if you'll look into the erlang-cl dependencies in the source
> file, you'll find the following:
>
> Depends: ${erlang:Depends}, ${misc:Depends}, ${shlibs:Depends}
>
> This means that if this behavior is indeed a bug then it's likely not
> a bug in erlang-cl. It just
> takes the dependencies from shlibs.
Looks like this is caused by
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=739409
which is supposed to be fixed in ocl-icd-libopencl1 2.1.3-5
while erlang-cl 1.2.1-2 was build with 2.1.3-4.
> On the other hand, you have the non-free repository enables, so why do
> you expect APT
> not to install packages available from there? If you don't want them
> then switch off the repository.
Debian Social Contract says
"We will never make the system require the use of a non-free component."
And I asked apt to install a package from Debian, not non-free.
> Anyway, I don't think that it's a bug in erlang-cl.
erlang-cl still needs to be rebuilt (probably with bin-nmu in stable)
in order for this bug to be fixed.
Bug#798255: [Pkg-erlang-devel] Bug#798255: erlang-cl: installs non-free packages
07.09.2015 в 20:10:31 +0300 Sergei Golovan написал: > On Mon, Sep 7, 2015 at 6:12 PM, Stepan Golosunov <ste...@golosunov.pp.ru> > wrote: > >> On the other hand, you have the non-free repository enables, so why do > >> you expect APT > >> not to install packages available from there? If you don't want them > >> then switch off the repository. > > > > Debian Social Contract says > > "We will never make the system require the use of a non-free component." > > And I asked apt to install a package from Debian, not non-free. > > After you've added the non-free repository to your sources.list you > can't say that, sorry. Non-free repository is not a part of Debian, > but APT by default happily installs non-free packages. You can pin > different priorities to different components (main, contrib, non-free) > but I never tried that and can't say if it works. Presence of non-free component in sources.list does not void social contract. And any case when installation of a package from main results in installation of a package from non-free (or contrib) is definitly a bug. (And in many of these cases a release-critical bug.)
Bug#774075: libdvdnav4: breaks mplayer2 from wheezy
Package: libdvdnav4 Version: 5.0.1-1 mplayer2 2.0-554-gf63dbad-1+b1 no longer starts after upgrading libdvdnav4 from 4.2.0+20120524-2 to 5.0.1-1: % mplayer mplayer: error while loading shared libraries: libdvdnavmini.so.4: cannot open shared object file: No such file or directory -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#774091: mpv: insufficient dependency on libquvi7
Package: mpv Version: 0.6.2-2 Control: close -1 0.7.1-1 mpv from jessie fails to play anything which is not directly a file when libquvi7 0.4.1-1 (from wheezy) is installed: % mpv dvd:// Playing: dvd:// PANIC: unprotected error in call to Lua API (attempt to index a number value) zsh: abort mpv dvd:// This is probably because old libquvi7 uses different lua version then mpv. mpv in unstable is probably unaffected as it dropped libquvi support. -- System Information: Debian Release: 7.7 APT prefers stable APT policy: (900, 'stable') Architecture: i386 (x86_64) Foreign Architectures: amd64 Kernel: Linux 3.16.0-4-amd64 (SMP w/2 CPU cores) Locale: LANG=ru_RU.UTF-8, LC_CTYPE=ru_RU.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: sysvinit (via /sbin/init) Versions of packages mpv depends on: ii libasound2 1.0.28-1 ii libass5 0.10.2-3 ii libavcodec-extra-56 6:11-2 ii libavdevice55 6:11-2 ii libavfilter56:11-2 ii libavformat56 6:11-2 ii libavresample2 6:11-2 ii libavutil54 6:11-2 ii libbluray1 1:0.6.2-1 ii libbs2b03.1.0+dfsg-2.1 ii libc6 2.19-13 ii libcdio-cdda1 0.83-4.2 ii libcdio-paranoia1 0.83-4.2 ii libcdio13 0.83-4.2 ii libdvdnav4 5.0.1-1 ii libdvdread4 5.0.0-1 ii libegl1-mesa [libegl1-x11] 10.3.2-1 ii libenca01.16-1 ii libgl1-mesa-glx [libgl1]10.3.2-1 ii libguess1 1.2-1 ii libjack-jackd2-0 [libjack-0.116]1.9.10+20140719git3eb0ae6a~dfsg-2 ii libjpeg62-turbo 1:1.3.1-11 ii liblcms2-2 2.6-3+b3 ii liblircclient0 0.9.0~pre1-1.1 ii liblua5.2-0 5.2.3-1.1 ii libmpg123-0 1.20.1-2 ii libpulse0 5.0-13 ii libquvi70.4.1-1 ii libsdl2-2.0-0 2.0.2+dfsg1-6 ii libswscale3 6:11-2 ii libuuid12.25.2-4 ii libva-glx1 1.4.1-1 ii libva-x11-1 1.4.1-1 ii libva1 1.4.1-1 ii libvdpau1 0.8-3 ii libwayland-client0 1.6.0-2 ii libwayland-cursor0 1.6.0-2 ii libwayland-egl1-mesa [libwayland-egl1] 10.3.2-1 ii libx11-62:1.6.2-3 ii libxext62:1.3.3-1 ii libxinerama12:1.1.3-1+b1 ii libxkbcommon0 0.4.3-2 ii libxrandr2 2:1.4.2-1+b1 ii libxss1 1:1.2.2-1 ii libxv1 2:1.0.10-1+b1 ii zlib1g 1:1.2.8.dfsg-2+b1 mpv recommends no packages. mpv 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#357446: pinfo: UTF8 problems
27.12.2014 в 16:41:35 +0100 Bas Zoetekouw написал: Hi Stephan, Hi Pinfo still has problems displaying utf-8: - links are highlighted in the wrong place - з (CYRILLIC SMALL LETTER ZE) is replaced with o, usually with next character - it also results in misaligned right edge of text - searched strings are highlighted in wrong places I was looking into this bug, but it seems the gpg package no longer supplies the Russian info pages. Could you maybe point me to a location or a package where I can get them? It was man page, not info page. Anything in /usr/share/man/ru/man? should be enough. I can reproduce this bug with pinfo man. Nowadays first з on a line appears to be replaced by a space. Some of the colored words are misplaced (those that are located after з?). Highlighting of search results is misplaced if there are non-ascii characters before it. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#771153: init-system-helpers: Please do not depend on new perl
On Thu, Nov 27, 2014 at 10:26:04AM +0200, Niko Tyni wrote: On Thu, Nov 27, 2014 at 10:08:52AM +0400, Stepan Golosunov wrote: Package: init-system-helpers Version: 1.22 init-system-helpers 1.22 introduced a versioned Depends: on perl-base. This needlessly complicates upgrades and backports by forcing perl and its reverse dependencies to be upgraded when installing init-system-helpers and its reverse dependencies. Depends: perl-base (= 5.20.1-3) | perl I'm not an init-system-helpers maintainer, just noting that I suspect there's some risk of breakage with this during upgrades when perl is not in a configured state. I don't think this risk is any worse with the above alternative dependency than with init-system-helpers/1.21 which only depends on perl, but at least libvirt-daemon-system has recently started using deb-systemd-helper in a preinst script partly based on perceived robustness of the perl-base dependency. See #769551, particularly https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=769551#56 Is init-system-helpers supposed to be held to the essential standard by requiring it to be functional when it's unpacked but not configured (but was configured in the past)? If so it probably fails while being upgraded from an earlier version (the one in wheezy-backports, for example). And if not libvirt-daemon-system cannot expect working init-system-helpers in preinst at all. (And in any case it cannot expect it in 1.18~) -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#771153: init-system-helpers: Please do not depend on new perl
Package: init-system-helpers Version: 1.22 init-system-helpers 1.22 introduced a versioned Depends: on perl-base. This needlessly complicates upgrades and backports by forcing perl and its reverse dependencies to be upgraded when installing init-system-helpers and its reverse dependencies. Please change Depends: perl-base (= 5.20.1-3) into Depends: perl-base (= 5.20.1-3) | perl to allow this dependency to be satisfied by perl from wheezy. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#770883: mdadm: /dev/md/name symlinks disappear with udev 175-7.2
Package: mdadm Version: 3.3.2-2 On the next reboot after upgrading mdadm from 3.2.5-5 to 3.3.2-2 I was greeted with a fatal fsck error. Turned out symlinks like /dev/md/boot were missing. Manual creation of the necessary symlink allowed boot to continue. Then I upgraded udev from 175-7.2 to 215-5+b1. After reboot /dev/md/* symlinks were back. Probably mdadm needs a versioned Depends: on udev. I wouldn't want to run into this issue on some remote server. This is easily reproducible within qemu: Install Debian 7.7 with / on raid1. /dev/md/0 symlink exists. Add jessie to /etc/apt/sources.list. # apt-get update # apt-get install mdadm # reboot /dev/md is empty. # apt-get install udev # reboot /dev/md/0 is back. -- System Information: Debian Release: 7.7 APT prefers stable APT policy: (900, 'stable') Architecture: i386 (x86_64) Foreign Architectures: amd64 Kernel: Linux 3.16.0-4-amd64 (SMP w/2 CPU cores) Locale: LANG=ru_RU.UTF-8, LC_CTYPE=ru_RU.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages mdadm depends on: ii debconf [debconf-2.0] 1.5.49 ii initscripts2.88dsf-41+deb7u1 ii libc6 2.19-13 ii lsb-base 4.1+Debian8+deb7u1 ii udev 215-5+b1 Versions of packages mdadm recommends: ii exim4-daemon-light [mail-transport-agent] 4.80-7+deb7u1 ii kmod 18-3 ii module-init-tools 18-3 mdadm suggests no packages. -- debconf information: mdadm/autostart: true * mdadm/initrdstart: all * mdadm/initrdstart_notinconf: false mdadm/initrdstart_msg_errexist: mdadm/initrdstart_msg_intro: mdadm/initrdstart_msg_errblock: * mdadm/start_daemon: true * mdadm/mail_to: root mdadm/initrdstart_msg_errmd: mdadm/initrdstart_msg_errconf: * mdadm/autocheck: true -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#767020: openhackware: should be Multi-Arch: foreign
Package: openhackware Version: 0.4.1+git-20140423.c559da7c-2 User: multiarch-de...@lists.alioth.debian.org Usertags: multiarch openhackware is an Architecture: all package but isn't marked Multi-Arch: foreign. This renders qemu-system-ppc:amd64 not installable with dpkg:i386 (while all other qemu-system-*:amd64 in jessie are installable with dpkg:i386). -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#628079: php5-common: Wrong timezone selected
Control: found -1 5.4.4-14+deb7u4
Control: tags -1 - moreinfo
On Fri, May 27, 2011 at 09:05:24AM +1000, Craig Small wrote:
Package: php5-common
Version: 5.3.6-11
Severity: normal
Both the apache module and cli PHP show my timezone as
Antartica/Macquarie. I'm not a penguin and don't live there.
The rest of the system thinks my timezone is Australia/NSW which is
correct.
I cannot find anywhere where it is set as it is commented out in the
php.ini files. If I set the timezone in my php.ini file then everything
works correctly, but why can't php just use the system timezone like the
rest of the computer does ok?
I am seeing similar issue with Europe/Samara being confused with
Asia/Samarkand.
# cat /etc/timezone
Europe/Samara
# php -i|grep -i timezone
Olson Timezone Database Version = 0.system
Timezone Database = internal
Default timezone = Asia/Samarkand
date.timezone = no value = no value
# printf '?php\necho date(c), \\n;\n'|php
2013-08-28T17:38:31+05:00
# printf '?php\necho date(c), \\n;\n'|TZ=Europe/Samara php
2013-08-28T17:38:36+05:00
# printf '?php\necho date(c), \\n;\n'|TZ=Europe/Moscow php
2013-08-28T16:38:40+04:00
# date
Wed Aug 28 16:38:55 SAMT 2013
# printf '?php\necho date(c), \\n;\n'|php -d date.timezone=Europe/Samara
2013-08-28T16:39:45+04:00
The last 3 variants show correct time.
After looking into use_embedded_timezonedb.patch I think that
timelib_timezone_id_from_abbr is called with SAMT as the first agrument.
And according to tzdata sources SAMT was used by Asia/Samarkand in
the past. And it even was UTC+4 before 1930. And php's zone_search
picks the first entry from timezonemap.h:
$ grep 'samt.*1440*' php5-5.4.4/ext/date/lib/timezonemap.h
{ samt, 0, 14400, Asia/Samarkand},
{ samt, 0, 14400, Europe/Samara },
Australia/Sydney has the same problem with EST: it was used by
Antarctica/Macquarie:
$ grep 'est.*36000*' php5-5.4.4/ext/date/lib/timezonemap.h
{ est, 0, 36000, Antarctica/Macquarie },
{ est, 0, 36000, Australia/ACT },
{ est, 0, 36000, Australia/Brisbane},
{ est, 0, 36000, Australia/Canberra},
{ est, 0, 36000, Australia/Currie },
{ est, 0, 36000, Australia/Hobart },
{ est, 0, 36000, Australia/LHI },
{ est, 0, 36000, Australia/Lindeman},
{ est, 0, 36000, Australia/Lord_Howe },
{ est, 0, 36000, Australia/Melbourne },
{ est, 0, 36000, Australia/NSW },
{ est, 0, 36000, Australia/Queensland },
{ est, 0, 36000, Australia/Sydney },
{ est, 0, 36000, Australia/Tasmania},
{ est, 0, 36000, Australia/Victoria},
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#712586: supported_versions: WARNING: Unknown Debian release: 7.1
Package: postgresql-client-common Version: 134wheezy3 During installation of postgresql on a freshly installed wheezy system /usr/share/postgresql-common/supported-versions claims that current Debian stable is not a known release: Setting up postgresql-common (134wheezy3) ... supported_versions: WARNING: Unknown Debian release: 7.1 supported_versions should probably check for 7.*) instead of 7.0*). -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#710353: libraw: CVE-2013-2126 CVE-2013-2127
Control: found -1 0.14.6-2
Control: tags -1 patch
03.06.2013 в 19:34:15 +0400 Stepan Golosunov написал:
On Thu, May 30, 2013 at 09:22:27AM +0200, Moritz Muehlenhoff wrote:
Package: libraw
Severity: grave
Tags: security
Two security issues have been found in libraw. Please see this link for
more information and links to upstream commits:
http://www.openwall.com/lists/oss-security/2013/05/29/7
According to
http://blog.lexa.ru/2013/05/28/o_spiskakh_uyazvimostei_v_programmakh.html
the buggy code is present only in 0.15 branch.
Apparently (https://bugzilla.redhat.com/show_bug.cgi?id=968382#c5)
only CVE-2013-2127 is limited to 0.15 (and as a result is not present
in debian libraw packages). According to
https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2013-2126
CVE-2013-2126 affects 0.14 an 0.15 and patch for 0.14 is available at
https://github.com/LibRaw/LibRaw/commit/c14ae36d28e80139b2f31b5d9d7623db3b597a3a
--- a/src/libraw_cxx.cpp
+++ b/src/libraw_cxx.cpp
@@ -796,8 +796,8 @@ int LibRaw::unpack(void)
S.iheight= S.height;
IO.shrink = 0;
// allocate image as temporary buffer, size
-imgdata.rawdata.raw_alloc =
calloc(S.iwidth*S.iheight,sizeof(*imgdata.image));
-imgdata.image = (ushort (*)[4]) imgdata.rawdata.raw_alloc;
+imgdata.rawdata.raw_alloc = 0;
+imgdata.image = (ushort (*)[4])
calloc(S.iwidth*S.iheight,sizeof(*imgdata.image));
}
@@ -807,8 +807,8 @@ int LibRaw::unpack(void)
// recover saved
if( decoder_info.decoder_flags LIBRAW_DECODER_LEGACY)
{
-imgdata.image = 0;
-imgdata.rawdata.color_image = (ushort (*)[4])
imgdata.rawdata.raw_alloc;
+ imgdata.rawdata.raw_alloc = imgdata.rawdata.color_image =
imgdata.image;
+ imgdata.image = 0;
}
// calculate channel maximum
(Note that there are other packages that duplicate libraw sources.
Darktable, for example, includes libraw 0.14.7.)
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#710353: libraw: CVE-2013-2126 CVE-2013-2127
Control: found -1 0.15.1-1 On Thu, May 30, 2013 at 09:22:27AM +0200, Moritz Muehlenhoff wrote: Package: libraw Severity: grave Tags: security Two security issues have been found in libraw. Please see this link for more information and links to upstream commits: http://www.openwall.com/lists/oss-security/2013/05/29/7 According to http://blog.lexa.ru/2013/05/28/o_spiskakh_uyazvimostei_v_programmakh.html the buggy code is present only in 0.15 branch. Which means only experimental is affected, and only by CVE-2013-2126. (Note that there are other packages that duplicate libraw sources. Darktable, for example, includes libraw 0.14.7.) -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#704933: linux-image-3.2.0-4-amd64:amd64: system hangs when initializing primary video card (3.2.39-2 - 3.2.41-2 regression)
Control: tag -1 patch
07.04.2013 в 22:31:00 +0100 Ben Hutchings написал:
On Mon, 2013-04-08 at 00:37 +0400, Stepan Golosunov wrote:
After upgrading linux-image-3.2.0-4-amd64:amd64 to 3.2.41-2 system
hangs when initializing primary video card.
Normally during boot bios and later linux console messages are
printed on primary monitor (connected to 05:00.0 card), then the
second video card (04:00.0) is initialized, some console messages
are printed on the second monitor and the first monitor is blanked.
Then console messages are again printed on the primary monitor.
After upgrading to 3.2.41-2 system hangs (no disk activity, no visible
reaction to keyboard, though NumLock and Alt-SysRq-B work) with first
monitor blanked. Photo of the second monitor attached; note the
absence of the
[9.145482] fbcon: radeondrmfb (fb1) is primary device
[9.148103] fbcon: Remapping primary device, fb1, to tty 1-63
lines, which are present on the monitor when booting with 3.2.39-2.
[...]
There seems to be only one change that could have caused this,
The relevant changes in 3.2.40 (
fb: rework locking to fix lock ordering on takeover,
fb: Yet another band-aid for fixing lockdep mess;
described in
http://lists.freedesktop.org/archives/dri-devel/2013-January/033976.html)
appear to be missing from debian/changelog.
And the missing fix (fbcon: fix locking harder) was discussed in
http://lists.freedesktop.org/archives/dri-devel/2013-January/033980.html.
Any of the two attached patches makes 3.2.41-2 bootable here.
From 054430e773c9a1e26f38e30156eff02dedfffc17 Mon Sep 17 00:00:00 2001
From: Dave Airlie airl...@gmail.com
Date: Fri, 25 Jan 2013 01:38:56 +
Subject: fbcon: fix locking harder
Okay so Alan's patch handled the case where there was no registered fbcon,
however the other path entered in set_con2fb_map pit.
In there we called fbcon_takeover, but we also took the console lock in a couple
of places. So push the console lock out to the callers of set_con2fb_map,
this means fbmem and switcheroo needed to take the lock around the fb notifier
entry points that lead to this.
This should fix the efifb regression seen by Maarten.
Tested-by: Maarten Lankhorst maarten.lankho...@canonical.com
Tested-by: Lu Hua huax...@intel.com
Signed-off-by: Dave Airlie airl...@redhat.com
---
Index: linux-3.2.41/drivers/gpu/vga/vga_switcheroo.c
===
--- linux-3.2.41.orig/drivers/gpu/vga/vga_switcheroo.c 2013-03-20 19:03:42.0 +0400
+++ linux-3.2.41/drivers/gpu/vga/vga_switcheroo.c 2013-04-12 09:15:38.138119524 +0400
@@ -26,6 +26,7 @@
#include linux/fb.h
#include linux/pci.h
+#include linux/console.h
#include linux/vga_switcheroo.h
struct vga_switcheroo_client {
@@ -256,8 +257,10 @@
if (new_client-fb_info) {
struct fb_event event;
+ console_lock();
event.info = new_client-fb_info;
fb_notifier_call_chain(FB_EVENT_REMAP_ALL_CONSOLE, event);
+ console_unlock();
}
ret = vgasr_priv.handler-switchto(new_client-id);
Index: linux-3.2.41/drivers/video/console/fbcon.c
===
--- linux-3.2.41.orig/drivers/video/console/fbcon.c 2013-04-12 09:13:12.51883 +0400
+++ linux-3.2.41/drivers/video/console/fbcon.c 2013-04-12 09:15:38.142119486 +0400
@@ -843,6 +843,8 @@
*
* Maps a virtual console @unit to a frame buffer device
* @newidx.
+ *
+ * This should be called with the console lock held.
*/
static int set_con2fb_map(int unit, int newidx, int user)
{
@@ -860,7 +862,7 @@
if (!search_for_mapped_con() || !con_is_bound(fb_con)) {
info_idx = newidx;
- return fbcon_takeover(0);
+ return do_fbcon_takeover(0);
}
if (oldidx != -1)
@@ -868,7 +870,6 @@
found = search_fb_in_map(newidx);
- console_lock();
con2fb_map[unit] = newidx;
if (!err !found)
err = con2fb_acquire_newinfo(vc, info, unit, oldidx);
@@ -895,7 +896,6 @@
if (!search_fb_in_map(info_idx))
info_idx = newidx;
- console_unlock();
return err;
}
@@ -3026,6 +3026,7 @@
}
#endif /* CONFIG_VT_HW_CONSOLE_BINDING */
+/* called with console_lock held */
static int fbcon_fb_unbind(int idx)
{
int i, new_idx = -1, ret = 0;
@@ -3052,6 +3053,7 @@
return ret;
}
+/* called with console_lock held */
static int fbcon_fb_unregistered(struct fb_info *info)
{
int i, idx;
@@ -3089,6 +3091,7 @@
return 0;
}
+/* called with console_lock held */
static void fbcon_remap_all(int idx)
{
int i;
@@ -3133,6 +3136,7 @@
}
#endif /* CONFIG_FRAMEBUFFER_DETECT_PRIMARY */
+/* called with console_lock held */
static int fbcon_fb_registered(struct fb_info *info)
{
int ret = 0, i, idx;
@@ -3285,6 +3289,7 @@
ret = fbcon_fb_unregistered(info);
break;
case FB_EVENT_SET_CONSOLE_MAP:
+ /* called with console lock held */
con2fb = event-data;
ret = set_con2fb_map(con2fb-console - 1,
con2fb-framebuffer, 1);
Index: linux-3.2.41/drivers/video
Bug#704933: linux-image-3.2.0-4-amd64:amd64: system hangs when initializing primary video card (3.2.39-2 - 3.2.41-2 regression)
07.04.2013 в 22:31:00 +0100 Ben Hutchings написал: On Mon, 2013-04-08 at 00:37 +0400, Stepan Golosunov wrote: After upgrading linux-image-3.2.0-4-amd64:amd64 to 3.2.41-2 system hangs when initializing primary video card. Normally during boot bios and later linux console messages are printed on primary monitor (connected to 05:00.0 card), then the second video card (04:00.0) is initialized, some console messages are printed on the second monitor and the first monitor is blanked. Then console messages are again printed on the primary monitor. After upgrading to 3.2.41-2 system hangs (no disk activity, no visible reaction to keyboard, though NumLock and Alt-SysRq-B work) with first monitor blanked. Photo of the second monitor attached; note the absence of the [9.145482] fbcon: radeondrmfb (fb1) is primary device [9.148103] fbcon: Remapping primary device, fb1, to tty 1-63 lines, which are present on the monitor when booting with 3.2.39-2. [...] There seems to be only one change that could have caused this, but please can you check? The attached patch reverts the change to radeon between these versions, and you can test it by following the instructions at http://kernel-handbook.alioth.debian.org/ch-common-tasks.html#s-common-official. From: Ben Hutchings b...@decadent.org.uk Subject: [PATCH] Revert drm/radeon/dce6: fix display powergating Unfortunately, the problem is reproducible even with this patch. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#674532: libcairo2: characters disappear with libcairo2 1.12.2
On Sat, Jan 26, 2013 at 02:25:12PM +0100, Michael Biebl wrote: Hi Stepan, is this bug still reproducible with 1.12.2-2? If so, could you try the packages from [1], please, Dots are not displayed if I run gxmessage -fn 'DejaVu Sans Mono 100' 1.2.3.4.5 with LD_PRELOAD'ed libcairo.so.2 from libcairo2 1.12.2-2, 1.12.2-2.1, 1.12.10-1 or (locally compiled) 1.12.2-2.1+deb7u1. (I still have libcairo2 1.10.2-7 installed to avoid the bug.) [1] deb http://people.debian.org/~biebl/cairo/i386 ./ deb http://people.debian.org/~biebl/cairo/amd64 ./ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#685351: src:gnumed-client: Missing source code for *.js files
Package: src:gnumed-client Version: 1.1.17-1 Severity: serious Justification: Policy 2.1 gnumed-doc installs /usr/share/doc/gnumed/user-manual/rsrc/System/JSTreeContrib/jquery.jstree.js. However, the file is present in the source package without source code. Instructions on which tools were used to create it are also missing. And the lack of copyright notices probably renders the package non-distributable. All or most of these issues seem to apply to other javascript files in the package (like jquery.foswiki.js). -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#683247: Bug#683030: unblock: vlc/2.0.3-1
01.08.2012 в 09:45:12 +0100 Adam D. Barratt написал: On 01.08.2012 09:14, Fabian Greffrath wrote: So, will libav 6:0.8.3-5 get unblocked or should we request this separately? The libav discussion moved to (the cloned) #683247, where Reinhard said he was going to upload -6. That bug also contains some discussion which suggests the previous m-a:foreign changes were incorrect. In any case, let's move the discussion there, please. :-) These multi-arch changes were correct (the packages cannot be Multi-Arch: foreign because they provide architecture-specific interface) but not ideal (architecture-specific packages should not be Architecture: all). And problems created by this non-ideality are mitigated by general uselessness of the packages (they are intented to transition packages which were never in stable). Also, multi-arch changes were described correctly in the changelog before http://anonscm.debian.org/gitweb/?p=pkg-multimedia/libav.git;a=commitdiff;h=677532340a55be1e0974de241f06aa605e2be083 The architecture change of libav-extra-dbg (with libav-regular-dbg forgotten again) was in fact related to #680602, not #680613. And it also creates architecture-dependent Architecture: all package problems. Which are again mitigated by uselessness of the package (it is not only intended to transition from package not found in stable, but also does not have reverse dependencies). -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#682388: powertop: buffer overrun in process::process
Package: powertop Version: 2.0-0.2 Severity: important Tags: upstream powertop crashes at startup with *** stack smashing detected ***: powertop terminated The crash is not reproducible with powertop:amd64. After recompiling powertop to get debug symbols I got the following backtrace with gdb.: #0 0xf7fdf425 in __kernel_vsyscall () #1 0xf7ca1941 in *__GI_raise (sig=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:64 #2 0xf7ca4d72 in *__GI_abort () at abort.c:92 #3 0xf7cdb305 in __libc_message (do_abort=2, fmt=0xf7dae5c8 *** %s ***: %s terminated\n) at ../sysdeps/unix/sysv/linux/libc_fatal.c:189 #4 0xf7d5beb0 in *__GI___fortify_fail (msg=optimized out) at fortify_fail.c:32 #5 0xf7d5be5a in __stack_chk_fail () at stack_chk_fail.c:29 #6 0x08066f91 in process::process (this=0xdf00650, _comm=optimized out, _pid=7812, _tid=0) at process/process.cpp:140 #7 0x08067277 in find_create_process (comm=0xde7794c mplayer, pid=7812) at process/process.cpp:173 #8 0x0806a9b3 in perf_process_bundle::handle_trace_point (this=0xde4e080, trace=0xde7791c, cpu=0, time=1053728094267690) at process/do_process.cpp:264 #9 0x0806fd52 in perf_bundle::process (this=0xde4e080) at perf/perf_bundle.cpp:303 #10 0x0806b6c6 in process_process_data () at process/do_process.cpp:1131 #11 0x08089d0f in one_measurement (seconds=1) at main.cpp:193 #12 0x0804dd5a in main (argc=1, argv=0xdc94) at main.cpp:418 /proc/7812/cmdline contains exactly 4096 characters (though process::process appears to read only 4095 of them) and is not null-terminated. As a result, variable line does not contain sequence of two nulls and cmdline_to_string replaces nulls with spaces further into stack until it finds such sequence. As expected, powertop does not crash if there is no process with long command line. -- System Information: Debian Release: wheezy/sid APT prefers testing APT policy: (900, 'testing'), (400, 'stable') Architecture: i386 (x86_64) Foreign Architectures: amd64 Kernel: Linux 3.2.0-3-amd64 (SMP w/2 CPU cores) Locale: LANG=ru_RU.UTF-8, LC_CTYPE=ru_RU.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages powertop depends on: ii libc6 2.13-33 ii libgcc1 1:4.7.1-2 ii libncursesw5 5.9-10 ii libnl-3-200 3.2.7-4 ii libnl-genl-3-200 3.2.7-4 ii libpci3 1:3.1.9-5 ii libstdc++64.7.1-2 ii libtinfo5 5.9-10 ii zlib1g1:1.2.7.dfsg-13 powertop recommends no packages. Versions of packages powertop suggests: ii cpufrequtils 008-1 pn laptop-mode-tools none -- 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#680613: Change fixed up
10.07.2012 в 07:49:22 +0200 Reinhard Tartler написал: (please don't use 680613, as your won't show up on the pkg-multimedia archives and I cannot easily reply) 680613-quiet@ was a result of 680613-submitter@ without 680613@ in the recipients of original mail. -submitter@ is not only documented as not delivering mail to the maintainer but also adds -quiet@ to the Reply-To: header. There were no addresses which are delivered to pkg-multimedia-maintain...@lists.alioth.debian.org in the reply created by group-reply and I just assumed this was intentional. I've dropped the multi-arch headers now in this commit: http://anonscm.debian.org/gitweb/?p=pkg-multimedia/libav.git;a=commitdiff;h=a55d079b01da2c81de68af0ebdb86d07aec5f5c7 All recent patches appear to modify changelog for 6:0.8.3-4. However, 6:0.8.3-4 is already in testing. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#680602: libav-dbg: bogusly Depends: libavcodec53 (= ${binary:Version})
Package: libav-dbg
Version: 6:0.8.3-4
Severity: important
libav-dbg is not installable together with libavcodec-extra-53 due to
bogus dependency on libavcodec53 (introduced in 6:0.8.3-2):
# apt-get install libav-dbg libavcodec-extra-53
Reading package lists... Done
Building dependency tree
Reading state information... Done
libavcodec-extra-53 is already the newest version.
libavcodec-extra-53 set to manually installed.
Some packages could not be installed. This may mean that you have
requested an impossible situation or if you are using the unstable
distribution that some required packages have not yet been created
or been moved out of Incoming.
The following information may help to resolve the situation:
The following packages have unmet dependencies:
libav-dbg : Depends: libavcodec53 (= 6:0.8.3-4) but it is not going to be
installed
E: Unable to correct problems, you have held broken packages.
As libav-dbg does not provide debug data for libavcodec53, it should at
most depend on
libav-regular-dbg (= ${binary:Version}) | libav-extra-dbg (= ${binary:Version})
instead of
libavcodec53 (= ${binary:Version})
By the way, is there any need for separate libav-regular-dbg and
libav-extra-dbg to exist at all? Given that the packages use build IDs
now, all their contents could be placed into libav-dbg.
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#680613: libav: Multi-Arch: foreign libraries
Source: libav Version: 0.8.3-4 Severity: important User: multiarch-de...@lists.alioth.debian.org Usertags: multiarch libavutil-extra-51, libavdevice-extra-53, libavfilter-extra-2, libpostproc-extra-52, libavformat-extra-53 and libswscale-extra-2 are Multi-Arch: foreign transitional packages. This allows the packages to satisfy dependencies of foreign-architecture packages while providing only libraries for a native architecture, which is obviously incorrect. Transitional library packages should be Multi-Arch: same (but that would require making them Architecture: any). I guess these packages should just be removed, as the only non-transitional versions of the packages still existing in Debian are uninstallable 4:0.7.2.1~bpo60+1 packages in backports and obsolete 4:0.7.2.1+b1 armhf on debports. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#680602: libav-dbg: bogusly Depends: libavcodec53 (= ${binary:Version})
07.07.2012 ц≈ 12:01:45 +0200 Reinhard Tartler ц▌ц│ц░ц┴ц⌠ц│ц▄: On Sat, Jul 7, 2012 at 10:51 AM, Stepan Golosunov ste...@golosunov.pp.ru wrote: libav-dbg is not installable together with libavcodec-extra-53 due to bogus dependency on libavcodec53 (introduced in 6:0.8.3-2): AFAIUI this was deliberate because libav-dbg ships symbols for libavcodec53, which is not co-installable with libavcodec-extra-53. Except that symbols for libavcodec53 are currently shipped in libav-regular-dbg, not libav-dbg. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#680613: libav: Multi-Arch: foreign libraries
07.07.2012 ц≈ 11:57:47 +0200 Reinhard Tartler ц▌ц│ц░ц┴ц⌠ц│ц▄: On Sat, Jul 7, 2012 at 11:50 AM, Stepan Golosunov ste...@golosunov.pp.ru wrote: libavutil-extra-51, libavdevice-extra-53, libavfilter-extra-2, libpostproc-extra-52, libavformat-extra-53 and libswscale-extra-2 are Multi-Arch: foreign transitional packages. This allows the packages to satisfy dependencies of foreign-architecture packages while providing only libraries for a native architecture, which is obviously incorrect. Transitional library packages should be Multi-Arch: same (but that would require making them Architecture: any). I guess these packages should just be removed, as the only non-transitional versions of the packages still existing in Debian are uninstallable 4:0.7.2.1~bpo60+1 packages in backports and obsolete 4:0.7.2.1+b1 armhf on debports. Well, AFAIUI this is a good reason to defer this for after wheezy release. Is there anything we can do about this issue for wheezy? What's this? Existence of the packages in backports? They became uninstallable when libav 0.8 was uploaded to backports months ago. (In any case, libav-extra source package probably needs be removed from backports.) If the transitional packages are to stay, the correct way to proceed is either to change them to Multi-Arch: same, Architecture: any or to remove their Multi-Arch headers. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#680613: libav: Multi-Arch: foreign libraries
07.07.2012 ц≈ 18:30:49 +0200 Reinhard Tartler ц▌ц│ц░ц┴ц⌠ц│ц▄: On Sat, Jul 7, 2012 at 1:03 PM, Stepan Golosunov ste...@golosunov.pp.ru wrote: 07.07.2012 ц≈ 11:57:47 +0200 Reinhard Tartler ц▌ц│ц░ц┴ц⌠ц│ц▄: On Sat, Jul 7, 2012 at 11:50 AM, Stepan Golosunov ste...@golosunov.pp.ru wrote: libavutil-extra-51, libavdevice-extra-53, libavfilter-extra-2, libpostproc-extra-52, libavformat-extra-53 and libswscale-extra-2 are Multi-Arch: foreign transitional packages. This allows the packages to satisfy dependencies of foreign-architecture packages while providing only libraries for a native architecture, which is obviously incorrect. Transitional library packages should be Multi-Arch: same (but that would require making them Architecture: any). I guess these packages should just be removed, as the only non-transitional versions of the packages still existing in Debian are uninstallable 4:0.7.2.1~bpo60+1 packages in backports and obsolete 4:0.7.2.1+b1 armhf on debports. Well, AFAIUI this is a good reason to defer this for after wheezy release. Is there anything we can do about this issue for wheezy? What's this? Existence of the packages in backports? They became uninstallable when libav 0.8 was uploaded to backports months ago. (In any case, libav-extra source package probably needs be removed from backports.) Yes, AFAIUI such removals happen on a regular basis without needing to file a bug. But libav-extra still hasn't been removed despite being uninstallable for months. BTW, libavformat-extra-53 from bpo is perfectly installable for me. Can you elaborate why they are not for you? http://packages.debian.org/search?keywords=libavformat-extra-53 There are two versions of libavformat-extra-53 in backports. One from libav-extra and one from libav. The first one is uninstallable as there is only one version of libavcodec-extra-53. The second one is a transitional package. (The obsolete libavformat-extra-53 probably still exists because the transitional one is Architecture: all.) % zgrep -A10 'Package: libavformat-extra-53' Packages.gz Package: libavformat-extra-53 Priority: optional Section: libs Installed-Size: 2108 Maintainer: Debian multimedia packages maintainers pkg-multimedia-maintain...@lists.alioth.debian.org Architecture: i386 Source: libav-extra Version: 4:0.7.2.1~bpo60+1 Replaces: libavformat53 Depends: libavcodec-extra-53 (= 4:0.7.2.1~bpo60+1), libavcodec-extra-53 ( 4:0.7.2.1~bpo60+1-99), libavutil-extra-51 (= 4:0.7.2.1~bpo60+1), libavutil-extra-51 ( 4:0.7.2.1~bpo60+1-99), libbz2-1.0, libc6 (= 2.7), librtmp0 (= 2.3), zlib1g (= 1:1.1.4) Conflicts: libavformat53 -- Package: libavformat-extra-53 Priority: optional Section: libs Installed-Size: 68 Maintainer: Debian Multimedia Maintainers pkg-multimedia-maintain...@lists.alioth.debian.org Architecture: all Source: libav Version: 6:0.8.3-1~bpo60+1 Depends: libavformat53 Filename: pool/main/liba/libav/libavformat-extra-53_0.8.3-1~bpo60+1_all.deb Size: 40658 If the transitional packages are to stay, the correct way to proceed is either to change them to Multi-Arch: same, Architecture: any or to remove their Multi-Arch headers. Err, they (i.e., all but libavcodec-extra-53, and that's critical) are already Arch: all, with Multi-arch: foreign. Do I understand you correctly that they should rather by Multi-arch: same? Yes. Now in testing apt-get allows installing, for example, minidlna:amd64 on a system with i386 dpkg without installing libavformat53:amd64, as the Depends: libavformat53 (= 4:0.8-1~) | libavformat-extra-53 (= 4:0.8-1~) is satisfiable by libavformat-extra-53:all and libavformat53:i386 combination. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#680602: libav-dbg: bogusly Depends: libavcodec53 (= ${binary:Version})
07.07.2012 в 18:34:20 +0200 Reinhard Tartler напиÑал: On Sat, Jul 7, 2012 at 1:18 PM, Stepan Golosunov ste...@golosunov.pp.ru wrote: 07.07.2012 в 12:01:45 +0200 Reinhard Tartler напиÑал: On Sat, Jul 7, 2012 at 10:51 AM, Stepan Golosunov ste...@golosunov.pp.ru wrote: libav-dbg is not installable together with libavcodec-extra-53 due to bogus dependency on libavcodec53 (introduced in 6:0.8.3-2): AFAIUI this was deliberate because libav-dbg ships symbols for libavcodec53, which is not co-installable with libavcodec-extra-53. Except that symbols for libavcodec53 are currently shipped in libav-regular-dbg, not libav-dbg. That would be a bug with at least severity important, if not even RC. But what makes you think that would be the case? 1. The following code in debian/rules: LIB_PKGS2 := $(shell sed -nr 's/^Package:[[:space:]]*(libavcodec[0-9]+)[[:space:]]*$$/\1/p' debian/control) ⦠dh_strip $(addprefix -N,$(LIB_PKGS2)) -Nffmpeg --dbg-package=libav-dbg dh_strip $(addprefix -p,$(LIB_PKGS2)) --dbg-package=libav-regular-dbg 2. Output of apt-cache show libav-regular-dbg. 3. Contents of the packages: % dpkg -x libavcodec53_0.8.3-4_i386.deb libavcodec53 % dpkg -x libav-dbg_0.8.3-4_i386.deb libav-dbg % dpkg -x libav-regular-dbg_0.8.3-4_i386.deb libav-regular-dbg % file libavcodec53/usr/lib/i386-linux-gnu/libavcodec.so.53.35.0 libavcodec53/usr/lib/i386-linux-gnu/libavcodec.so.53.35.0: ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), dynamically linked, BuildID[sha1]=0xf46c1c7c0498551c5c87f10f9b5874537e17de73, stripped % file libav-dbg/usr/lib/debug/.build-id/*/*|grep f46c1c7c0498551c5c87f10f9b5874537e17de73 % file libav-regular-dbg/usr/lib/debug/.build-id/*/*|grep f46c1c7c0498551c5c87f10f9b5874537e17de73 libav-regular-dbg/usr/lib/debug/.build-id/7c/1c6cf41c5598040ff1875c5374589b73de177e.debug: ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), dynamically linked, BuildID[sha1]=0xf46c1c7c0498551c5c87f10f9b5874537e17de73, not stripped -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#680613: libav: Multi-Arch: foreign libraries
07.07.2012 ц≈ 19:54:24 +0200 Reinhard Tartler ц▌ц│ц░ц┴ц⌠ц│ц▄: On Sat, Jul 7, 2012 at 7:30 PM, Stepan Golosunov ste...@golosunov.pp.ru wrote: 07.07.2012 ц≈ 18:30:49 +0200 Reinhard Tartler ц▌ц│ц░ц┴ц⌠ц│ц▄: On Sat, Jul 7, 2012 at 1:03 PM, Stepan Golosunov ste...@golosunov.pp.ru wrote: 07.07.2012 ц≈ 11:57:47 +0200 Reinhard Tartler ц▌ц│ц░ц┴ц⌠ц│ц▄: On Sat, Jul 7, 2012 at 11:50 AM, Stepan Golosunov ste...@golosunov.pp.ru wrote: libavutil-extra-51, libavdevice-extra-53, libavfilter-extra-2, libpostproc-extra-52, libavformat-extra-53 and libswscale-extra-2 are Multi-Arch: foreign transitional packages. This allows the packages to satisfy dependencies of foreign-architecture packages while providing only libraries for a native architecture, which is obviously incorrect. Transitional library packages should be Multi-Arch: same (but that would require making them Architecture: any). I guess these packages should just be removed, as the only non-transitional versions of the packages still existing in Debian are uninstallable 4:0.7.2.1~bpo60+1 packages in backports and obsolete 4:0.7.2.1+b1 armhf on debports. err, the first one is superseeded by the one built from the source package 'libav'. It is uninstallable because the newer packages has a higher version number. Can you please explain the problem again? Package: libavformat-extra-53 Version: 4:0.7.2.1~bpo60+1 That's the superseeded one and should get removed. I only mentioned backports in the context of the remove buggy transitional packages solution. If there are no packages to transition from then there is no need for transitional packages to exist. And the only relevant untransitioned packages which can be found in Debian now are the superseded and uninstallable ones in backports. The installable versions are already transitioned. Meaning that the current packages in squeeze-backports and squeeze do not prevent removal of the buggy transitional packages. (Though the removal would still require checking that there are no versioned reverse dependencies without alternatives and probably preapproval from the release team.) If the transitional packages are to stay, the correct way to proceed is either to change them to Multi-Arch: same, Architecture: any or to remove their Multi-Arch headers. Err, they (i.e., all but libavcodec-extra-53, and that's critical) are already Arch: all, with Multi-arch: foreign. Do I understand you correctly that they should rather by Multi-arch: same? Yes. Now in testing apt-get allows installing, for example, minidlna:amd64 on a system with i386 dpkg without installing libavformat53:amd64, as the Depends: libavformat53 (= 4:0.8-1~) | libavformat-extra-53 (= 4:0.8-1~) is satisfiable by libavformat-extra-53:all and libavformat53:i386 combination. To recap, what's the problem now? The problem is that Multi-Arch: foreign header on transitional packages incorrectly allows installation of packages depending on libavformat53:amd64 without installation of libavformat53:amd64. There are at least three solutions: 1. Fix the header to be Multi-Arch: same. 2. Remove Multi-Arch: header from the transtional packages. 3. Remove buggy transitional packages. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#680041: apt-mark hold does not work on Architecture: all packages
Package: apt Version: 0.9.7.1 Severity: normal apt-mark hold and apt-mark unhold (as well as aptitude hold) do not work on Architecture: all packages: # apt-mark hold acpi-support-base acpi-support-base set on hold. # apt-mark showhold libcairo2 However, dpkg --set-selections does work: # printf acpi-support-base hold\n | dpkg --set-selections # apt-mark showhold acpi-support-base libcairo2 # apt-mark unhold acpi-support-base Canceled hold on acpi-support-base. # apt-mark showhold acpi-support-base libcairo2 # printf acpi-support-base install\n | dpkg --set-selections # apt-mark showhold libcairo2 # printf acpi-support-base:all hold\n | dpkg --set-selections # apt-mark showhold acpi-support-base libcairo2 (Tested with dpkg 1.16.4.3.) P.S. Shouldn't #483067 be closed? -- Package-specific info: -- apt-config dump -- APT ; APT::Architecture i386; APT::Build-Essential ; APT::Build-Essential:: build-essential; APT::Install-Recommends 1; APT::Install-Suggests 0; APT::NeverAutoRemove ; APT::NeverAutoRemove:: ^firmware-linux.*; APT::NeverAutoRemove:: ^linux-firmware$; APT::NeverAutoRemove:: ^linux-image.*; APT::NeverAutoRemove:: ^kfreebsd-image.*; APT::NeverAutoRemove:: ^linux-restricted-modules.*; APT::NeverAutoRemove:: ^linux-ubuntu-modules-.*; APT::NeverAutoRemove:: ^gnumach$; APT::NeverAutoRemove:: ^gnumach-image.*; APT::Never-MarkAuto-Sections ; APT::Never-MarkAuto-Sections:: metapackages; APT::Never-MarkAuto-Sections:: restricted/metapackages; APT::Never-MarkAuto-Sections:: universe/metapackages; APT::Never-MarkAuto-Sections:: multiverse/metapackages; APT::Never-MarkAuto-Sections:: oldlibs; APT::Never-MarkAuto-Sections:: restricted/oldlibs; APT::Never-MarkAuto-Sections:: universe/oldlibs; APT::Never-MarkAuto-Sections:: multiverse/oldlibs; APT::Cache-Limit 65536000; APT::Architectures ; APT::Architectures:: i386; APT::Architectures:: amd64; APT::Compressor ; APT::Compressor::. ; APT::Compressor::.::Name .; APT::Compressor::.::Extension ; APT::Compressor::.::Binary ; APT::Compressor::.::Cost 1; APT::Compressor::gzip ; APT::Compressor::gzip::Name gzip; APT::Compressor::gzip::Extension .gz; APT::Compressor::gzip::Binary gzip; APT::Compressor::gzip::Cost 2; APT::Compressor::gzip::CompressArg ; APT::Compressor::gzip::CompressArg:: -9n; APT::Compressor::gzip::UncompressArg ; APT::Compressor::gzip::UncompressArg:: -d; APT::Compressor::bzip2 ; APT::Compressor::bzip2::Name bzip2; APT::Compressor::bzip2::Extension .bz2; APT::Compressor::bzip2::Binary bzip2; APT::Compressor::bzip2::Cost 3; APT::Compressor::bzip2::CompressArg ; APT::Compressor::bzip2::CompressArg:: -9; APT::Compressor::bzip2::UncompressArg ; APT::Compressor::bzip2::UncompressArg:: -d; APT::Compressor::xz ; APT::Compressor::xz::Name xz; APT::Compressor::xz::Extension .xz; APT::Compressor::xz::Binary xz; APT::Compressor::xz::Cost 4; APT::Compressor::xz::CompressArg ; APT::Compressor::xz::CompressArg:: -6; APT::Compressor::xz::UncompressArg ; APT::Compressor::xz::UncompressArg:: -d; APT::Compressor::lzma ; APT::Compressor::lzma::Name lzma; APT::Compressor::lzma::Extension .lzma; APT::Compressor::lzma::Binary xz; APT::Compressor::lzma::Cost 5; APT::Compressor::lzma::CompressArg ; APT::Compressor::lzma::CompressArg:: --format=lzma; APT::Compressor::lzma::CompressArg:: -9; APT::Compressor::lzma::UncompressArg ; APT::Compressor::lzma::UncompressArg:: --format=lzma; APT::Compressor::lzma::UncompressArg:: -d; APT::CompressorName ; APT::CompressorExtension .; APT::CompressorBinary ; APT::CompressorCost 100; APT::CompressorCompressArg ; APT::CompressorCompressArg:: -9; APT::CompressorUncompressArg ; APT::CompressorUncompressArg:: -d; Dir /; Dir::State var/lib/apt/; Dir::State::lists lists/; Dir::State::cdroms cdroms.list; Dir::State::mirrors mirrors/; Dir::State::extended_states extended_states; Dir::State::status /var/lib/dpkg/status; Dir::Cache var/cache/apt/; Dir::Cache::archives archives/; Dir::Cache::srcpkgcache srcpkgcache.bin; Dir::Cache::pkgcache pkgcache.bin; Dir::Etc etc/apt/; Dir::Etc::sourcelist sources.list; Dir::Etc::sourceparts sources.list.d; Dir::Etc::vendorlist vendors.list; Dir::Etc::vendorparts vendors.list.d; Dir::Etc::main apt.conf; Dir::Etc::netrc auth.conf; Dir::Etc::parts apt.conf.d; Dir::Etc::preferences preferences; Dir::Etc::preferencesparts preferences.d; Dir::Etc::trusted trusted.gpg; Dir::Etc::trustedparts trusted.gpg.d; Dir::Bin ; Dir::Bin::methods /usr/lib/apt/methods; Dir::Bin::solvers ; Dir::Bin::solvers:: /usr/lib/apt/solvers; Dir::Bin::dpkg /usr/bin/dpkg; Dir::Bin::bzip2 /bin/bzip2; Dir::Bin::xz /usr/bin/xz; Dir::Media ; Dir::Media::MountPath /media/apt; Dir::Log var/log/apt; Dir::Log::Terminal term.log; Dir::Log::History history.log; Dir::Ignore-Files-Silently ; Dir::Ignore-Files-Silently:: ~$;
Bug#599913: rtorrent crashes with rtorrent: std::bad_allocate
01.07.2012 в 21:17:50 +0400 Stepan Golosunov напиÑал: 26.06.2012 в 00:59:50 +0200 Benoît Knecht напиÑал: rtorrent 0.9.2 and libtorrent 0.13.2 are now in testing, could you give them a try and report back here on the result? After running rtorrent under valgrind (log attached) with libtorrent recompiled with DEB_BUILD_OPTIONS=nostrip I believe that DhtServer::process_queue frees packet's transaction by calling failed_transaction on line 834 of dht_server.cc and after that writes to deleted transaction by calling set_packet on line 839. Attached patch is supposed to fix that. (Though I did not read the code deep enough to verify that the fix is correct, did not test it thoroughly and did not run it under valgrind yet. At least, rtorrent did not crash on the start like it did few minutes before without the patch.) The patch is indeed incorrect as rtorrent crashed the usual way some time later and valgrind's output is pretty much the same as without the patch. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#599913: rtorrent crashes with rtorrent: std::bad_allocate
26.06.2012 в 17:51:02 +0200 Benoît Knecht напиÑал: Stepan Golosunov wrote: rtorrent 0.9.2-1 crashed upon start several times when I tried it couple of weeks ago. (Today it did not crash yet, but this seems to be the usual behavior when I am trying to reproduce crash for the bug report.) Upon returning home I found rtorrent crashed. And upon restart it did crashed again immediately with Caught Segmentation fault, dumping stack: Stack dump not enabled. in the screen, but the process did not exit. gdb shown the following: 0xf77a2425 in __kernel_vsyscall () (gdb) bt #0 0xf77a2425 in __kernel_vsyscall () #1 0xf739a6c1 in __lll_lock_wait_private () at ../nptl/sysdeps/unix/sysv/linux/i386/i686/../i486/lowlevellock.S:95 #2 0xf73314d7 in _L_lock_9662 () from /lib/i386-linux-gnu/i686/cmov/libc.so.6 #3 0xf732fd06 in *__GI___libc_free (mem=0x9094098) at malloc.c:3736 #4 0xf74c426f in operator delete(void*) () from /usr/lib/i386-linux-gnu/libstdc++.so.6 #5 0xf7611ea9 in std::tr1::_Function_base::_Base_managerstd::tr1::_Bindstd::tr1::_Mem_fnvoid (torrent::log_buffer::*)(char const*, unsigned int, int) (torrent::log_buffer*, std::tr1::_Placeholder1, std::tr1::_Placeholder2, std::tr1::_Placeholder3) ::_M_manager(std::tr1::_Any_data, std::tr1::_Any_data const, std::tr1::_Manager_operation) () from /usr/lib/i386-linux-gnu/libtorrent.so.14 #6 0xf760e228 in torrent::log_cleanup() () from /usr/lib/i386-linux-gnu/libtorrent.so.14 #7 0x0805aade in ?? () #8 0x0809901d in ?? () #9 signal handler called #10 0xf732b73a in malloc_consolidate (av=optimized out) at malloc.c:5161 #11 0xf732cbd5 in _int_free (av=optimized out, p=0x98c3d58) at malloc.c:5034 #12 0xf732fd0d in *__GI___libc_free (mem=0x98c3d60) at malloc.c:3738 #13 0xf74c426f in operator delete(void*) () from /usr/lib/i386-linux-gnu/libstdc++.so.6 #14 0xf74c42bb in operator delete[](void*) () from /usr/lib/i386-linux-gnu/libstdc++.so.6 #15 0xf763ebd1 in ?? () from /usr/lib/i386-linux-gnu/libtorrent.so.14 #16 0xf763eeff in ?? () from /usr/lib/i386-linux-gnu/libtorrent.so.14 #17 0xf75e6b4e in torrent::PollEPoll::perform() () from /usr/lib/i386-linux-gnu/libtorrent.so.14 #18 0xf75e6beb in torrent::PollEPoll::do_poll(long long, int) () from /usr/lib/i386-linux-gnu/libtorrent.so.14 #19 0xf762293c in torrent::thread_base::event_loop(torrent::thread_base*) () from /usr/lib/i386-linux-gnu/libtorrent.so.14 #20 0x08059f24 in ?? () #21 0xf72d3e46 in __libc_start_main (main=0x8056830, argc=1, ubp_av=0xff936fb4, init=0x8155c20, fini=0x8155c10, rtld_fini=0xf77b1590, stack_end=0xff936fac) at libc-start.c:228 #22 0x0805a529 in ?? () I had to use kill -9 afterwards. There are usually several dozens of torrents from jamendo in the session directory. Thanks for the additional information. I'll try to reproduce this bug, but I'll have to get DHT working first. One more thing: Have you seen this bug happening if you only have a few active torrents? How many are several dozens? Are they all active? About 80, all active. I did not really try to run rtorrent with few torrents recently, but I think I was unable to reproduce it with 0.8.9-2 with only one torrent. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#679155: valgrind: vgdb does not work when $TMPDIR is set
Package: valgrind Version: 1:3.7.0-6 Severity: normal When running valgrind --log-file=valgrind.log --vgdb=full --vgdb-error=1 rtorrent I found ==27729== TO DEBUG THIS PROCESS USING GDB: start GDB like this ==27729== /path/to/gdb rtorrent ==27729== and then give GDB the following command ==27729== target remote | /usr/lib/valgrind/../../bin/vgdb --pid=27729 ==27729== --pid is optional if only one valgrind process is running in the valgrind.log. However, doing so resulted in % gdb rtorrent GNU gdb (GDB) 7.4.1-debian Copyright (C) 2012 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type show copying and show warranty for details. This GDB was configured as i486-linux-gnu. For bug reporting instructions, please see: http://www.gnu.org/software/gdb/bugs/... Reading symbols from /usr/bin/rtorrent...(no debugging symbols found)...done. (gdb) target remote | /usr/lib/valgrind/../../bin/vgdb --pid=27729 Remote debugging using | /usr/lib/valgrind/../../bin/vgdb --pid=27729 vgdb error: no FIFO found matching pid 27729 Remote communication error. Target disconnected.: Ресурс временно недоступен. Luckily I remebered that valgrind created some files in /tmp/ instead of $TMPDIR. So I was able to connect to valgrind using % env --unset=TMPDIR gdb rtorrent -- System Information: Debian Release: wheezy/sid APT prefers testing APT policy: (900, 'testing'), (400, 'stable') Architecture: i386 (x86_64) Foreign Architectures: amd64 Kernel: Linux 3.2.0-2-amd64 (SMP w/2 CPU cores) Locale: LANG=ru_RU.UTF-8, LC_CTYPE=ru_RU.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages valgrind depends on: ii libc6 2.13-33 ii libc6-dbg 2.13-33 Versions of packages valgrind recommends: ii gdb 7.4.1-1.1 ii valgrind-dbg 1:3.7.0-6 Versions of packages valgrind suggests: pn alleyoop none pn kcachegrind none pn valgrind-mpi none pn valkyrie none -- 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#679202: linux-doc-3.2: should be Multi-Arch: foreign
Package: linux-doc-3.2 Version: 3.2.21-2 Severity: normal User: multiarch-de...@lists.alioth.debian.org Usertags: multiarch apt-get suggests installation of linux-doc-3.2:amd64 when installing linux-image-3.2.0-3-amd64:amd64 on an i386 system: % LANG=C sudo apt-get -d install linux-image-3.2.0-3-amd64:amd64/unstable Reading package lists... Done Building dependency tree Reading state information... Done Selected version '3.2.21-2' (Debian:unstable [amd64]) for 'linux-image-3.2.0-3-amd64:amd64' Suggested packages: linux-doc-3.2:amd64 debian-kernel-handbook:amd64 The following NEW packages will be installed: linux-image-3.2.0-3-amd64:amd64 0 upgraded, 1 newly installed, 0 to remove and 1 not upgraded. Need to get 0 B/23.3 MB of archives. However, linux-doc-3.2:all is already installed. This should be fixed by marking linux-doc-3.2 Multi-Arch: foreign. -- System Information: Debian Release: wheezy/sid APT prefers testing APT policy: (900, 'testing'), (400, 'stable') Architecture: i386 (x86_64) Foreign Architectures: amd64 Kernel: Linux 3.2.0-2-amd64 (SMP w/2 CPU cores) Locale: LANG=ru_RU.UTF-8, LC_CTYPE=ru_RU.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -- 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#679202: linux-doc-3.2: should be Multi-Arch: foreign
clone 679202 -1 reassign -1 debian-kernel-handbook 1.0.13 retitle -1 debian-kernel-handbook: should be Multi-Arch: foreign user multiarch-de...@lists.alioth.debian.org usertags -1 multiarch thanks 27.06.2012 в 08:44:31 +0400 Stepan Golosunov напиÑал: apt-get suggests installation of linux-doc-3.2:amd64 when installing linux-image-3.2.0-3-amd64:amd64 on an i386 system: [â¦] However, linux-doc-3.2:all is already installed. This should be fixed by marking linux-doc-3.2 Multi-Arch: foreign. The same applies to debian-kernel-handbook. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#599913: rtorrent crashes with rtorrent: std::bad_allocate
26.06.2012 в 00:59:50 +0200 Benoît Knecht написал:
Benoît Knecht wrote:
Stepan Golosunov wrote:
rtorrent 0.8.6-1 used to be crashing every several weeks for
me. (Though I do not actually remember whether there were
std::bad_alloc messages. I thought so but several recent crashes in
squeeze had basic_string::resize messages.)
After upgrading to wheezy rtorrent started to crash much more
often. Either immediately after start or about half an hour later,
often with the messed up *** glibc detected *** rtorrent: corrupted
double-linked list: 0x094c7a18 *** messages, requiring reset in the
terminal to get readable output from any subsequent command.
Running rtorrent under valgrind appears to prevent crashes.
After recompiling libtorrent 0.12.9-3 with DEB_BUILD_OPTIONS=nostrip
I get the following:
[...]
I've been running rtorrent/libtorrent 0.8.9/0.12.9 for months without
such problems, but I don't use DHT and you apparently do. So just to see
what might be the differences, could you please post your rtorrent.rc?
If you have anything unusual in there, maybe you could try and see if
the crash happens with a minimal rtorrent.rc too.
rtorrent 0.9.2 and libtorrent 0.13.2 are now in testing, could you give
them a try and report back here on the result? Also consider what I
mentioned above about rtorrent.rc.
rtorrent 0.9.2-1 crashed upon start several times when I tried it
couple of weeks ago. (Today it did not crash yet, but this seems to be
the usual behavior when I am trying to reproduce crash for the bug
report.)
By the way, changes like this in libtorrent's configure look
suspicious:
int main() {
-struct kevent ev[2], ev_out[2];
+struct kevent ev2, ev_out2;
struct timespec ts = { 0, 0 };
-int pfd[2], pty[2], kfd, n;
-char buffer[9001];
+int pfd2, pty2, kfd, n;
+char buffer9001;
if (pipe(pfd) == -1) return 1;
-if (fcntl(pfd[1], F_SETFL, O_NONBLOCK) == -1) return 2;
-while ((n = write(pfd[1], buffer, sizeof(buffer))) ==
sizeof(buffer));
-if ((pty[0]=posix_openpt(O_RDWR | O_NOCTTY)) == -1) return 3;
-if ((pty[1]=grantpt(pty[0])) == -1) return 4;
-EV_SET(ev+0, pfd[1], EVFILT_WRITE, EV_ADD | EV_ENABLE, 0, 0,
NULL);
-EV_SET(ev+1, pty[1], EVFILT_READ, EV_ADD | EV_ENABLE, 0, 0,
NULL);
+if (fcntl(pfd1, F_SETFL, O_NONBLOCK) == -1) return 2;
+while ((n = write(pfd1, buffer, sizeof(buffer))) ==
sizeof(buffer));
+if ((pty0=posix_openpt(O_RDWR | O_NOCTTY)) == -1) return 3;
+if ((pty1=grantpt(pty0)) == -1) return 4;
+EV_SET(ev+0, pfd1, EVFILT_WRITE, EV_ADD | EV_ENABLE, 0, 0,
NULL);
+EV_SET(ev+1, pty1, EVFILT_READ, EV_ADD | EV_ENABLE, 0, 0,
NULL);
if ((kfd = kqueue()) == -1) return 5;
if ((n = kevent(kfd, ev, 2, NULL, 0, NULL)) == -1) return 6;
-if (ev_out[0].flags EV_ERROR) return 7;
-if (ev_out[1].flags EV_ERROR) return 8;
-read(pfd[0], buffer, sizeof(buffer));
+if (ev_out0.flags EV_ERROR) return 7;
+if (ev_out1.flags EV_ERROR) return 8;
+read(pfd0, buffer, sizeof(buffer));
+if ((n = kevent(kfd, NULL, 0, ev_out, 2, ts)) 1) return 9;
+return 0;
+ }
All brackets around array indexes are lost in c snippets.
My .rtorrent.rc contains this:
bind = …
port_range = …-…
#port_range = …-…
check_hash = yes
directory = …
http_proxy =
encoding_list = utf-8
encryption = allow_incoming,try_outgoing
peer_exchange = yes
session = …
dht = auto
dht_port = …
There are usually several dozens of torrents from jamendo in the session
directory.
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#677851: xfonts-base: should be Multi-Arch: foreign
Package: xfonts-base Version: 1:1.0.3 Severity: normal User: multiarch-de...@lists.alioth.debian.org Usertags: multiarch xfonts-base should be marked Multi-Arch: foreign (given that it is Architecture: all and depends only on a Multi-Arch: foreign package). Otherwise, foreign-architecture xorg won't be installable: % LANG=C sudo apt-get -d install xorg:amd64 xserver-xorg:amd64 xserver-xorg-core:amd64 libaudit0:amd64 libxfont1:amd64 xinit:amd64 xauth:amd64 x11-xkb-utils:amd64 Reading package lists... Done Building dependency tree Reading state information... Done Some packages could not be installed. This may mean that you have requested an impossible situation or if you are using the unstable distribution that some required packages have not yet been created or been moved out of Incoming. The following information may help to resolve the situation: The following packages have unmet dependencies: xorg:amd64 : Depends: xfonts-base:amd64 (= 1:1.0.0-1) but it is not installable Depends: xfonts-100dpi:amd64 (= 1:1.0.0-1) but it is not installable Depends: xfonts-75dpi:amd64 (= 1:1.0.0-1) but it is not installable Depends: xfonts-scalable:amd64 (= 1:1.0.0-1) but it is not installable Depends: x11-apps:amd64 but it is not going to be installed Depends: x11-session-utils:amd64 but it is not going to be installed Depends: x11-xserver-utils:amd64 but it is not going to be installed Depends: xfonts-utils:amd64 Depends: xkb-data:amd64 but it is not installable Depends: xorg-docs-core:amd64 but it is not installable xserver-xorg:amd64 : Depends: xkb-data:amd64 (= 1.4) but it is not installable xserver-xorg-core:amd64 : Depends: xserver-common:amd64 (= 2:1.12.1.902-1) but it is not installable Depends: keyboard-configuration:amd64 but it is not installable E: Unable to correct problems, you have held broken packages. -- System Information: Debian Release: wheezy/sid APT prefers testing APT policy: (900, 'testing'), (400, 'stable') Architecture: i386 (x86_64) Foreign Architectures: amd64 Kernel: Linux 3.2.0-2-amd64 (SMP w/2 CPU cores) Locale: LANG=ru_RU.UTF-8, LC_CTYPE=ru_RU.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages xfonts-base depends on: ii xfonts-utils 1:7.7~1 xfonts-base recommends no packages. Versions of packages xfonts-base suggests: ii xnest [xserver] 2:1.12.1.902-1 ii xserver-xephyr [xserver] 2:1.12.1.902-1 ii xserver-xorg [xserver]1:7.6+13 ii xvfb [xserver]2:1.12.1.902-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#677868: /usr/bin/dictl: incorrect handling of apostrophe
Package: dict Version: 1.12.0+dfsg-5 Severity: normal File: /usr/bin/dictl Tags: patch upstream dictl (unlike dict) does not handle apostrophe correctly: % dictl won't /usr/bin/dictl: 1: eval: Syntax error: Unterminated quoted string This means arbitrary code execution if dictl is used in a script accepting untrusted data (but dictl is not suitable for such scripts anyway due to lack of -- argument support): % dictl -- asdfasdf';echo qqq;beep;': No definitions found for asdfasdf qqq --- /usr/bin/dictl 2012-05-20 23:52:40.0 +0400 +++ ./dictl 2012-06-17 15:07:45.0 +0400 @@ -75,9 +75,9 @@ cmd='dict' while test $# -ne 0; do -cmd=$cmd '$1' +cmd=$cmd '`printf %s $1|sed s/'/'''/g`' shift done -cmd=$(echo $cmd | charset2charset $DICTL_CHARSET $DICTL_SERVER_CHARSET) +cmd=$(printf %s $cmd | charset2charset $DICTL_CHARSET $DICTL_SERVER_CHARSET) -eval $cmd -P - | charset2charset $DICTL_SERVER_CHARSET $DICTL_CHARSET +eval $cmd | charset2charset $DICTL_SERVER_CHARSET $DICTL_CHARSET -- System Information: Debian Release: wheezy/sid APT prefers testing APT policy: (900, 'testing'), (400, 'stable') Architecture: i386 (x86_64) Foreign Architectures: amd64 Kernel: Linux 3.2.0-2-amd64 (SMP w/2 CPU cores) Locale: LANG=ru_RU.UTF-8, LC_CTYPE=ru_RU.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages dict depends on: ii libc62.13-33 ii libmaa3 1.3.1-1 ii netbase 5.0 ii recode 3.6-20 Versions of packages dict recommends: ii gawk 1:4.0.1+dfsg-2 ii m41.4.16-3 Versions of packages dict suggests: ii dictd [dict-server] 1.12.0+dfsg-5 -- 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#677884: xkb-data: should be Multi-Arch: foreign
Package: xkb-data Version: 2.5.1-1 Severity: normal User: multiarch-de...@lists.alioth.debian.org Usertags: multiarch As xkb-data is an Architecture: all package with no dependencies or maintainer scripts, it should be marked Multi-Arch: foreign. Otherwise, foreign-architecture xserver-xorg won't be installable: % LANG=C sudo apt-get -d install xorg:amd64 xserver-xorg:amd64 xserver-xorg-core:amd64 libaudit0:amd64 libxfont1:amd64 xinit:amd64 xauth:amd64 x11-xkb-utils:amd64 Reading package lists... Done Building dependency tree Reading state information... Done Some packages could not be installed. This may mean that you have requested an impossible situation or if you are using the unstable distribution that some required packages have not yet been created or been moved out of Incoming. The following information may help to resolve the situation: The following packages have unmet dependencies: xorg:amd64 : Depends: xfonts-base:amd64 (= 1:1.0.0-1) but it is not installable Depends: xfonts-100dpi:amd64 (= 1:1.0.0-1) but it is not installable Depends: xfonts-75dpi:amd64 (= 1:1.0.0-1) but it is not installable Depends: xfonts-scalable:amd64 (= 1:1.0.0-1) but it is not installable Depends: x11-apps:amd64 but it is not going to be installed Depends: x11-session-utils:amd64 but it is not going to be installed Depends: x11-xserver-utils:amd64 but it is not going to be installed Depends: xfonts-utils:amd64 Depends: xkb-data:amd64 but it is not installable Depends: xorg-docs-core:amd64 but it is not installable xserver-xorg:amd64 : Depends: xkb-data:amd64 (= 1.4) but it is not installable xserver-xorg-core:amd64 : Depends: xserver-common:amd64 (= 2:1.12.1.902-1) but it is not installable Depends: keyboard-configuration:amd64 but it is not installable E: Unable to correct problems, you have held broken packages. -- System Information: Debian Release: wheezy/sid APT prefers testing APT policy: (900, 'testing'), (400, 'stable') Architecture: i386 (x86_64) Foreign Architectures: amd64 Kernel: Linux 3.2.0-2-amd64 (SMP w/2 CPU cores) Locale: LANG=ru_RU.UTF-8, LC_CTYPE=ru_RU.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -- 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#677884: xkb-data: should be Multi-Arch: foreign
17.06.2012 в 16:09:10 +0200 Cyril Brulebois напиÑал: Stepan Golosunov ste...@golosunov.pp.ru (17/06/2012): As xkb-data is an Architecture: all package with no dependencies or maintainer scripts, it should be marked Multi-Arch: foreign. Otherwise, foreign-architecture xserver-xorg won't be installable [â¦] Because of course you *need* a foreign X server? Because, for example, I might want to cross-grade the whole system without crossgrading dpkg and xorg at the same time. Or because I just want to check which version works better. Also, there are other packages depending on xkb-data. And some of them are already Multi-Arch: same. In any case, adding Multi-Arch: header to xkb-data is a trivial change. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#674645: glibc-doc: should be Multi-Arch: foreign
Package: glibc-doc Version: 2.13-32 Severity: normal When installing libc6:amd64 apt suggests installation of glibc-doc: % LANG=C sudo apt-get install libc6:amd64 Reading package lists... Done Building dependency tree Reading state information... Done The following extra packages will be installed: gcc-4.7-base:amd64 libgcc1:amd64 Suggested packages: glibc-doc:amd64 The following NEW packages will be installed: gcc-4.7-base:amd64 libc6:amd64 libgcc1:amd64 0 upgraded, 3 newly installed, 0 to remove and 1 not upgraded. However, glibc-doc:all is already installed. I think this noise should be fixed by marking glibc-doc Multi-Arch: foreign. -- System Information: Debian Release: wheezy/sid APT prefers testing APT policy: (900, 'testing'), (400, 'stable') Architecture: i386 (x86_64) Kernel: Linux 3.2.0-2-amd64 (SMP w/2 CPU cores) Locale: LANG=ru_RU.UTF-8, LC_CTYPE=ru_RU.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash glibc-doc depends on no packages. glibc-doc recommends no packages. Versions of packages glibc-doc suggests: ii glibc-doc-reference 2.13-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#674532: libcairo2: characters disappear with libcairo2 1.12.2
Package: libcairo2 Version: 1.12.2-1 Severity: important After upgrading libcairo2 to 1.12.2-1 characters started to disappear randomly in cairo-using applications, especially with bigger font sizes. With gxmessage -fn 'DejaVu Sans Mono 100' 1.2.3.4.5 this is reproducible with font sizes from 32 to 157. Downgrading libcairo2 to 1.10.2-7 fixes the problem (screenshots from gxmessage attached). Further investigation revealed that the bug appears to be no longer reproducible if I comment out the following fragment of my .fonts.conf: match target=font edit mode=assign name=antialias boolfalse/bool /edit /match The system is running with xserver-xorg-video-radeon 1:6.14.4-3, so this issue is probably unrelated to the Xorg bug. -- System Information: Debian Release: wheezy/sid APT prefers testing APT policy: (900, 'testing'), (400, 'stable') Architecture: i386 (x86_64) Kernel: Linux 3.2.0-2-amd64 (SMP w/2 CPU cores) Locale: LANG=ru_RU.UTF-8, LC_CTYPE=ru_RU.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages libcairo2 depends on: ii libc6 2.13-32 ii libfontconfig1 2.9.0-5 ii libfreetype6 2.4.9-1 ii libpixman-1-0 0.24.4-1 ii libpng12-0 1.2.49-1 ii libx11-6 2:1.4.99.901-2 ii libxcb-render0 1.8.1-1 ii libxcb-shm01.8.1-1 ii libxcb11.8.1-1 ii libxrender11:0.9.7-1 ii multiarch-support 2.13-32 ii zlib1g 1:1.2.7.dfsg-1 libcairo2 recommends no packages. libcairo2 suggests no packages. -- no debconf information -- debsums errors found: debsums: package libcairo2 is not installed attachment: libcairo2-1.12.2-1.pngattachment: libcairo2-1.10.2-7.png
Bug#674149: conkeror: content-policy does not work
Package: conkeror
Version: 1.0~~pre+git120102-1
Severity: normal
After upgrading the rest of the system to wheezy (xulrunner-1.9.1 was
replaced with xulrunner-10.0 during upgrade; conkeror itself was
installed from testing long before that) content-policy does not
work.
Not even
require('content-policy');
add_hook(content_policy_hook, function () { return content_policy_reject; });
M-x content-policy-enable produces the following error:
ReferenceError: content_policy_listener is not defined
Looks like /usr/share/conkeror/modules/content-policy.js is loaded but
/usr/share/conkeror/components/content-policy.js is not.
-- Package-specific info:
-- Extensions information
Name: HTTPS-Everywhere
Location:
/usr/share/mozilla/extensions/{a79fe89b-6662-4ff4-8e88-09950ad4dfde}/https-everywh...@eff.org
Package: xul-ext-https-everywhere
Status: enabled
-- Plugins information
Name: DjView-4.9
Location: /usr/lib/mozilla/plugins/nsdejavu.so
Package: djview-plugin
Status: enabled
Name: MozPlugger 1.14.3 handles QuickTime and Windows Media Player Plugin
(1.14.3)
Location: /usr/lib/mozilla/plugins/mozplugger.so
Package: mozplugger
Status: disabled
-- Addons package information
ii djview-plugin 4.9-1 Browser plugin for the DjVu image format
ii mozplugger 1.14.3-7 Plugin allowing external viewers to be launc
ii xul-ext-https- 2.0.3-1extension to force the use of HTTPS on many
-- System Information:
Debian Release: wheezy/sid
APT prefers testing
APT policy: (900, 'testing'), (400, 'stable')
Architecture: i386 (x86_64)
Kernel: Linux 3.2.0-2-amd64 (SMP w/2 CPU cores)
Locale: LANG=ru_RU.UTF-8, LC_CTYPE=ru_RU.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Versions of packages conkeror depends on:
ii xulrunner-10.0 10.0.4esr-2
Versions of packages conkeror recommends:
ii conkeror-spawn-process-helper 1.0~~pre+git120102-1
Versions of packages conkeror suggests:
ii emacs23-lucid [emacsen] 23.4+1-3
-- 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#674149: conkeror: content-policy does not work
23.05.2012 ц≈ 14:27:33 +0200 Axel Beckert ц▌ц│ц░ц┴ц⌠ц│ц▄: You can easily check if the issue is really gone by testing the packages available at http://noone.org/conkeror-nightly-debs/ -- newest packages at the bottom. I did not try to run anything, but the following change is going to break everything: http://repo.or.cz/w/conkeror.git/commitdiff/0458cb2d12ac2b32398978b457b812f5a56c9dab In ru_RU.UTF-8 locale (as well as in de_DE.UTF-8 but not in C or de_CH.UTF-8): % seq 5.0 13.0 5,0 6,0 7,0 8,0 9,0 10,0 11,0 12,0 13,0 Probably it's also a bug in seq that it accepts numbers in one format, but outputs in another (which it does not accept). -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#673268: libqtwebkit4: utterly incorrect debian/copyright
Package: libqtwebkit4 Version: 2.2.1-4+b1 Severity: serious Justification: Policy 12.5 /usr/share/doc/libqtwebkit4/copyright claims the library is distributed under BSD-style license. However, several thousands of files in the source package say they are distributed under LGPL. The list of copyright holders is also much more diverse than stated in debian/copyright. And BSD-licensed files came with many different variants of the license. -- System Information: Debian Release: wheezy/sid APT prefers testing APT policy: (900, 'testing'), (400, 'stable') Architecture: i386 (x86_64) Kernel: Linux 3.2.0-2-amd64 (SMP w/2 CPU cores) Locale: LANG=ru_RU.UTF-8, LC_CTYPE=ru_RU.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages libqtwebkit4 depends on: ii libc62.13-32 ii libgcc1 1:4.7.0-7 ii libglib2.0-0 2.32.2-1 ii libgstreamer-plugins-base0.10-0 0.10.36-1 ii libgstreamer0.10-0 0.10.36-1 ii libqt4-network 4:4.8.1-1 ii libqtcore4 4:4.8.1-1 ii libqtgui44:4.8.1-1 ii libsqlite3-0 3.7.11-3 ii libstdc++6 4.7.0-7 ii libx11-6 2:1.4.99.901-2 ii libxrender1 1:0.9.7-1 ii multiarch-support2.13-32 libqtwebkit4 recommends no packages. libqtwebkit4 suggests no packages. -- no debconf information -- debsums errors found: debsums: package libqtwebkit4 is not installed -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#673118: tagainijisho: should not check for new version by default
Package: tagainijisho Version: 0.9.2-3 Severity: normal The first thing tagainijisho from testing displays on the start is the offer to download new version from somewhere. This is rather pointless for Debian (especially if this package is going to be released with stable) as updates are supposed to be received via the Debian archive. Also, unsolicited report to some site of the fact that user is running the program is dubious from the privacy point of view. Network access itself can be expensive in some situations. I guess that changing default value of autoCheckUpdates to false in src/gui/MainWindow.cc should fix the problem. -- System Information: Debian Release: wheezy/sid APT prefers testing APT policy: (900, 'testing'), (400, 'stable') Architecture: i386 (x86_64) Kernel: Linux 3.2.0-2-amd64 (SMP w/2 CPU cores) Locale: LANG=ru_RU.UTF-8, LC_CTYPE=ru_RU.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages tagainijisho depends on: ii libc62.13-32 ii libgcc1 1:4.7.0-7 ii libqt4-network 4:4.8.1-1 ii libqtcore4 4:4.8.1-1 ii libqtgui44:4.8.1-1 ii libsqlite3-0 3.7.11-3 ii libstdc++6 4.7.0-7 ii tagainijisho-common 0.9.2-3 ii tagainijisho-dic-en 0.9.2-3 tagainijisho recommends no packages. tagainijisho 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#673128: /etc/init.d/openarena-server: init-script-disabled-by-upgrade does not work
Package: openarena-server Version: 0.8.8-3 Severity: normal Tags: patch File: /etc/init.d/openarena-server openarena-server was disabled by upgrade and yet it was running (at least, after reboot). % ps -AF|grep '[i]oq3' % sudo /etc/init.d/openarena-server start [ ok ] Starting OpenArena dedicated server: openarena-server (disabled during upgrade, not starting - see /usr/share/doc/openarena-server/NEWS.Debian.gz). % ps -AF|grep '[i]oq3' 106 26809 1 13 41069 10316 0 14:40 ?00:00:00 /usr/lib/ioquake3 ioq3ded +set com_basegame baseoa +set fs_basepath /usr/lib/openarena-server +set com_homepath .openarena +set com_legacyprotocol 71 +set com_protocol 71 +set sv_master1 dpmaster.deathmask.net +set cl_motd 0 +exec debian_server.cfg The relevant fragment of /etc/init.d/openarena-server is missing a return statement in this case: --- /etc/init.d/openarena-server.orig 2012-04-02 01:04:36.0 +0400 +++ /etc/init.d/openarena-server2012-05-16 14:55:49.688354738 +0400 @@ -32,10 +32,11 @@ return 2 fi if [ $START_DAEMON = unless-disabled-by-upgrade ]; then if [ -e /var/games/openarena-server/init-script-disabled-by-upgrade ]; then echo -n (disabled during upgrade, not starting - see /usr/share/doc/openarena-server/NEWS.Debian.gz) +return 0 fi elif [ $START_DAEMON != 1 ]; then echo -n (disabled in /etc/default/openarena-server - deprecated, see /usr/share/doc/openarena-server/README.Debian.gz) return 0 fi -- System Information: Debian Release: wheezy/sid APT prefers testing APT policy: (900, 'testing'), (400, 'stable') Architecture: i386 (x86_64) Kernel: Linux 3.2.0-2-amd64 (SMP w/2 CPU cores) Locale: LANG=ru_RU.UTF-8, LC_CTYPE=ru_RU.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages openarena-server depends on: ii adduser 3.113+nmu1 ii ioquake3-server 1.36+svn2224-3 ii libc6 2.13-32 ii openarena-081-maps0.8.5split-2 ii openarena-081-misc0.8.5split-2 ii openarena-081-players 0.8.5split-2 ii openarena-081-players-mature 0.8.5split-2 ii openarena-081-textures0.8.5split-2 ii openarena-085-data0.8.5split-2 ii openarena-088-data0.8.8-1 ii openarena-data0.8.5split-2 openarena-server recommends no packages. openarena-server 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#599913: rtorrent crashes with rtorrent: std::bad_allocate
Package: rtorrent
Version: 0.8.9-2
Followup-For: Bug #599913
rtorrent 0.8.6-1 used to be crashing every several weeks for
me. (Though I do not actually remember whether there were
std::bad_alloc messages. I thought so but several recent crashes in
squeeze had basic_string::resize messages.)
After upgrading to wheezy rtorrent started to crash much more
often. Either immediately after start or about half an hour later,
often with the messed up *** glibc detected *** rtorrent: corrupted
double-linked list: 0x094c7a18 *** messages, requiring reset in the
terminal to get readable output from any subsequent command.
Running rtorrent under valgrind appears to prevent crashes.
After recompiling libtorrent 0.12.9-3 with DEB_BUILD_OPTIONS=nostrip
I get the following:
valgrind:
==5193== Memcheck, a memory error detector
==5193== Copyright (C) 2002-2011, and GNU GPL'd, by Julian Seward et al.
==5193== Using Valgrind-3.7.0 and LibVEX; rerun with -h for copyright info
==5193== Command: rtorrent
==5193== Parent PID: 5237
==5193==
==5193== Invalid write of size 4
==5193==at 0x4BB56DB:
torrent::DhtServer::process_queue(std::dequetorrent::DhtTransactionPacket*,
std::allocatortorrent::DhtTransactionPacket* , unsigned int*)
(dht_transaction.h:308)
==5193==by 0x4BB5A7E: torrent::DhtServer::event_write() (dht_server.cc:868)
==5193==by 0xFE9ED2F7: ???
==5193== Address 0xbe3dd30 is 64 bytes inside a block of size 68 free'd
==5193==at 0x47B309C: operator delete(void*) (in
/usr/lib/valgrind/vgpreload_memcheck-x86-linux.so)
==5193==by 0x4BB7431: torrent::DhtTransactionPing::~DhtTransactionPing()
(dht_transaction.h:359)
==5193==by 0x980C2DB: ???
==5193==
==5193== Conditional jump or move depends on uninitialised value(s)
==5193==at 0x4BD363A: torrent::SocketFd::set_priority(unsigned char)
(socket_fd.cc:74)
==5193==by 0x4BDCF8E:
torrent::HandshakeManager::setup_socket(torrent::SocketFd)
(handshake_manager.cc:291)
==5193==by 0x4BDE335:
torrent::HandshakeManager::add_incoming(torrent::SocketFd, rak::socket_address
const) (handshake_manager.cc:112)
==5193==by 0x4BD2CE9: torrent::Listen::event_read() (functional.h:565)
==5193==by 0x8A135152: ???
==5193==
==5193==
==5193== HEAP SUMMARY:
==5193== in use at exit: 1,116,798 bytes in 378 blocks
==5193== total heap usage: 368,383 allocs, 368,005 frees, 27,458,737 bytes
allocated
==5193==
==5193== LEAK SUMMARY:
==5193==definitely lost: 222,079 bytes in 130 blocks
==5193==indirectly lost: 0 bytes in 0 blocks
==5193== possibly lost: 2,560 bytes in 6 blocks
==5193==still reachable: 892,159 bytes in 242 blocks
==5193== suppressed: 0 bytes in 0 blocks
==5193== Rerun with --leak-check=full to see details of leaked memory
==5193==
==5193== For counts of detected and suppressed errors, rerun with: -v
==5193== Use --track-origins=yes to see where uninitialised values come from
==5193== ERROR SUMMARY: 3 errors from 2 contexts (suppressed: 97 from 10)
crash:
Program terminated with signal 6, Aborted.
#0 0xf7787425 in __kernel_vsyscall ()
(gdb) bt full
#0 0xf7787425 in __kernel_vsyscall ()
No symbol table info available.
#1 0xf72f9941 in *__GI_raise (sig=6) at
../nptl/sysdeps/unix/sysv/linux/raise.c:64
resultvar = optimized out
pid = -146636812
selftid = 5249
#2 0xf72fcd72 in *__GI_abort () at abort.c:92
act = {__sigaction_handler = {sa_handler = 0xf77a44e4
_rtld_global+1220, sa_sigaction = 0xf77a44e4 _rtld_global+1220}, sa_mask =
{__val = {851968, 4149070080,
4148727728, 4292974972, 158281, 4292974940, 4148667552,
4148648944, 0, 63, 4292974784, 4147738760, 9, 4292974868, 4148330484, 5,
4292976328, 4292974988, 4147857284,
136, 4292974868, 9, 0, 4292974964, 0, 7, 4148187836, 4148187832,
4148183311, 4148183376, 37, 4292974868}}, sa_flags = -1992356, sa_restorer =
0xf7406696}
sigs = {__val = {32, 0 repeats 31 times}}
#3 0xf73332f5 in __libc_message (do_abort=2, fmt=0xf7408530 *** glibc
detected *** %s: %s: 0x%s ***\n) at ../sysdeps/unix/sysv/linux/libc_fatal.c:189
ap = optimized out
fd = -1991996
on_2 = optimized out
list = optimized out
nlist = optimized out
cp = optimized out
written = false
#4 0xf733d3e1 in malloc_printerr (action=optimized out, str=0x6 Address 0x6
out of bounds, ptr=0x94c7a18) at malloc.c:6283
buf = 094c7a18
cp = optimized out
#5 0xf733d81e in malloc_consolidate (av=optimized out) at malloc.c:5161
fb = 0xf74293d0
maxfb = 0xf74293ec
p = 0x94c7a18
nextp = 0x9547a98
unsorted_bin = 0xf74293f0
first_unsorted = optimized out
nextchunk = 0x94c7a38
size = optimized out
nextsize = 56
prevsize = optimized out
bck = optimized out
fwd = 0x9547a98
__func__ = malloc_consolidate
#6 0xf733f955 in _int_malloc (av=optimized out, bytes=optimized
Bug#672881: /usr/share/man/man1/alsa_in.1.gz: man: /usr/share/man/man1/alsa_in.1 is self referencing
Package: jackd2 Version: 1.9.8~dfsg.3+20120418gitf82ec715-6 Severity: normal File: /usr/share/man/man1/alsa_in.1.gz man alsa_in produces error messages instead of any useful information: man: /usr/share/man/man1/alsa_in.1 is self referencing man: /usr/share/man/man1/alsa_in.1.gz:1: .so requests nested too deeply or are recursive -- System Information: Debian Release: wheezy/sid APT prefers testing APT policy: (900, 'testing'), (400, 'stable') Architecture: i386 (x86_64) Kernel: Linux 3.2.0-2-amd64 (SMP w/2 CPU cores) Locale: LANG=ru_RU.UTF-8, LC_CTYPE=ru_RU.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages jackd2 depends on: ii coreutils 8.13-3.1 ii debconf [debconf-2.0] 1.5.42 ii libasound2 1.0.25-2 ii libc6 2.13-32 ii libcelt0-0 0.7.1-1 ii libdbus-1-31.5.12-1 ii libexpat1 2.1.0-1 ii libgcc11:4.7.0-7 ii libjack-jackd2-0 1.9.8~dfsg.3+20120418gitf82ec715-6 ii libsamplerate0 0.1.8-4 ii libsndfile11.0.25-4 ii libstdc++6 4.7.0-7 ii multiarch-support 2.13-32 ii python 2.7.2-10 ii python-dbus0.84.0-3 Versions of packages jackd2 recommends: ii jackd2-firewire none ii libpam-modules 1.1.3-7 ii qjackctl 0.3.8-1 Versions of packages jackd2 suggests: ii jack-tools 20101210-2 ii meterbridge 0.9.2-10 -- Configuration Files: /etc/security/limits.d/audio.conf [Errno 2] Нет такого файла или каталога: u'/etc/security/limits.d/audio.conf' -- debconf information: * jackd/tweak_rt_limits: false -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#587277: fsadm(8) not installed
tags 587277 patch thanks fsadm(8) is present in lvm2-2.02.95 sources but is not installed into the binary package. --- debian/lvm2.install.orig2010-03-16 23:58:19.0 +0400 +++ debian/lvm2.install 2012-05-10 22:51:26.574506351 +0400 @@ -4,6 +4,7 @@ sbin/lv* sbin/pv* sbin/vg* +usr/share/man/man8/fsadm.8 usr/share/man/man8/lv* usr/share/man/man8/pv* usr/share/man/man8/vg* -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#671055: manpages-ru: severely outdated
02.05.2012 ц≈ 19:53:43 +0400 Yuri Kozlov ц▌ц│ц░ц┴ц⌠ц│ц▄: In the mean time, man-pages-ru project provides up to date translations: http://sourceforge.net/projects/man-pages-ru/ 3.39 translation is provided (released on 23th april in english) Does someone on debian-l10n-russ...@lists.debian.org volunteer to update that package with man-pages-ru ? It's distributed under GNU FDL, AFAIK it's not compatible with DFSG. It was decided in 2006 that GFDL without invariant sections is compatible with DFSG but still not recommended. http://www.debian.org/vote/2006/vote_001#amendmenttexta (maintainer and translator of http://sourceforge.net/projects/man-pages-ru/ hat on) What license would be acceptable? Many pages translated in man-pages-ru state that they are distributed under GPL. That does not allow anything but GPL for their translations. I would recommend using the same licenses for translated pages as the original ones have. (And uploading to Debian would require tarball with sources. I found only generated files in http://sourceforge.net/projects/man-pages-ru/files/.) -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#672270: libgtk2.0-0: uim input method not available after squeeze-wheezy upgrade
Package: libgtk2.0-0 Version: 2.24.10-1 Severity: normal After squeeze to wheezy upgrade uim input method disappeared from GTK+ applications. While /usr/lib/gtk-2.0/2.10.0/immodules/im-uim.so was present on the system, it was not mentioned in /usr/lib/i386-linux-gnu/gtk-2.0/2.10.0/gtk.immodules. apt-get install --reinstall uim-gtk2.0 fixed the situation. Apparently libgtk2.0-0 was triggered when uim-gtk2.0 was unpacked but its dependency libuim7 was not and gtk-query-immodules-2.0 couldn't get anything useful out of im-uim.so while libuim.so.7 did not exist. % grep -E ' uim-gtk2\.0| libgtk2\.0-0| libuim7' /var/log/dpkg.log|grep -v ^2012-05-09 2012-05-01 10:39:52 upgrade uim-gtk2.0:i386 1:1.5.7-9.1 1:1.7.3-2 2012-05-01 10:39:52 status half-configured uim-gtk2.0:i386 1:1.5.7-9.1 2012-05-01 10:39:52 status unpacked uim-gtk2.0:i386 1:1.5.7-9.1 2012-05-01 10:39:52 status half-installed uim-gtk2.0:i386 1:1.5.7-9.1 2012-05-01 10:39:52 status triggers-pending libgtk2.0-0:i386 2.24.10-1 2012-05-01 10:39:52 status half-installed uim-gtk2.0:i386 1:1.5.7-9.1 2012-05-01 10:39:52 status half-installed uim-gtk2.0:i386 1:1.5.7-9.1 2012-05-01 10:39:53 status half-installed uim-gtk2.0:i386 1:1.5.7-9.1 2012-05-01 10:39:53 status half-installed uim-gtk2.0:i386 1:1.5.7-9.1 2012-05-01 10:39:54 status unpacked uim-gtk2.0:i386 1:1.7.3-2 2012-05-01 10:39:54 status unpacked uim-gtk2.0:i386 1:1.7.3-2 2012-05-01 10:40:00 trigproc libgtk2.0-0:i386 2.24.10-1 2.24.10-1 2012-05-01 10:40:00 status half-configured libgtk2.0-0:i386 2.24.10-1 2012-05-01 10:40:01 status installed libgtk2.0-0:i386 2.24.10-1 2012-05-01 10:40:11 install libuim7:i386 none 1:1.7.3-2 2012-05-01 10:40:12 status half-installed libuim7:i386 1:1.7.3-2 2012-05-01 10:40:13 status unpacked libuim7:i386 1:1.7.3-2 2012-05-01 10:40:13 status unpacked libuim7:i386 1:1.7.3-2 2012-05-01 10:44:34 configure libuim7:i386 1:1.7.3-2 none 2012-05-01 10:44:34 status unpacked libuim7:i386 1:1.7.3-2 2012-05-01 10:44:35 status half-configured libuim7:i386 1:1.7.3-2 2012-05-01 10:44:35 status installed libuim7:i386 1:1.7.3-2 2012-05-01 10:44:43 configure uim-gtk2.0:i386 1:1.7.3-2 none 2012-05-01 10:44:43 status unpacked uim-gtk2.0:i386 1:1.7.3-2 2012-05-01 10:44:43 status half-configured uim-gtk2.0:i386 1:1.7.3-2 2012-05-01 10:44:43 status installed uim-gtk2.0:i386 1:1.7.3-2 -- System Information: Debian Release: wheezy/sid APT prefers testing APT policy: (900, 'testing'), (900, 'stable') Architecture: i386 (x86_64) Kernel: Linux 3.2.0-2-amd64 (SMP w/2 CPU cores) Locale: LANG=ru_RU.UTF-8, LC_CTYPE=ru_RU.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages libgtk2.0-0:i386 depends on: ii libatk1.0-0 2.4.0-2 ii libc6 2.13-32 ii libcairo2 1.12.2-1 ii libcomerr2 1.42.2-2 ii libcups21.5.2-5 ii libfontconfig1 2.9.0-3 ii libfreetype62.4.9-1 ii libgcrypt11 1.5.0-3 ii libgdk-pixbuf2.0-0 2.26.1-1 ii libglib2.0-02.32.0-4 ii libgnutls26 2.12.18-1 ii libgssapi-krb5-21.10+dfsg~beta1-2 ii libgtk2.0-common2.24.10-1 ii libk5crypto31.10+dfsg~beta1-2 ii libkrb5-3 1.10+dfsg~beta1-2 ii libpango1.0-0 1.30.0-1 ii libx11-62:1.4.99.901-2 ii libxcomposite1 1:0.4.3-2 ii libxcursor1 1:1.1.13-1 ii libxdamage1 1:1.1.3-2 ii libxext62:1.3.1-2 ii libxfixes3 1:5.0-4 ii libxi6 2:1.6.0-1 ii libxinerama12:1.1.2-1 ii libxrandr2 2:1.3.2-2 ii libxrender1 1:0.9.7-1 ii multiarch-support 2.13-32 ii shared-mime-info0.90-1 ii zlib1g 1:1.2.6.dfsg-2 Versions of packages libgtk2.0-0:i386 recommends: ii hicolor-icon-theme 0.12-1 ii libgtk2.0-bin 2.24.10-1 Versions of packages libgtk2.0-0:i386 suggests: ii gvfs none ii librsvg2-common 2.36.1-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#672275: libgtk2.0-0: unquoted *.so in postinst
Package: libgtk2.0-0 Version: 2.24.10-1 Severity: normal postinst script in libgtk2.0-0 contains two unquoted *.so strings. This will cause troubles if any .so file exists in current directory (which appears to be / normally). Especially if a file with the same name exists in $IMMODULES_DIR. -- System Information: Debian Release: wheezy/sid APT prefers testing APT policy: (900, 'testing'), (900, 'stable') Architecture: i386 (x86_64) Kernel: Linux 3.2.0-2-amd64 (SMP w/2 CPU cores) Locale: LANG=ru_RU.UTF-8, LC_CTYPE=ru_RU.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages libgtk2.0-0 depends on: ii libatk1.0-0 2.4.0-2 ii libc6 2.13-32 ii libcairo2 1.12.2-1 ii libcomerr2 1.42.2-2 ii libcups21.5.2-5 ii libfontconfig1 2.9.0-3 ii libfreetype62.4.9-1 ii libgcrypt11 1.5.0-3 ii libgdk-pixbuf2.0-0 2.26.1-1 ii libglib2.0-02.32.0-4 ii libgnutls26 2.12.18-1 ii libgssapi-krb5-21.10+dfsg~beta1-2 ii libgtk2.0-common2.24.10-1 ii libk5crypto31.10+dfsg~beta1-2 ii libkrb5-3 1.10+dfsg~beta1-2 ii libpango1.0-0 1.30.0-1 ii libx11-62:1.4.99.901-2 ii libxcomposite1 1:0.4.3-2 ii libxcursor1 1:1.1.13-1 ii libxdamage1 1:1.1.3-2 ii libxext62:1.3.1-2 ii libxfixes3 1:5.0-4 ii libxi6 2:1.6.0-1 ii libxinerama12:1.1.2-1 ii libxrandr2 2:1.3.2-2 ii libxrender1 1:0.9.7-1 ii multiarch-support 2.13-32 ii shared-mime-info0.90-1 ii zlib1g 1:1.2.6.dfsg-2 Versions of packages libgtk2.0-0 recommends: ii hicolor-icon-theme 0.12-1 ii libgtk2.0-bin 2.24.10-1 Versions of packages libgtk2.0-0 suggests: ii gvfs none ii librsvg2-common 2.36.1-1 -- no debconf information -- debsums errors found: debsums: package libgtk2.0-0 is not installed -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#671818: uim-el: Installation of emacs-related packages leaves uim-helper-server running
Package: uim-el Version: 1:1.7.3-2 Severity: normal Installation of emacs-related packages leaves uim-helper-server running as root and creates files in /root/. Accessing anything in /root/ during packages installation is a bad idea. % ps -AF|grep '[r]oot.*uim';ls -lad /root/.uim.d ls: cannot access /root/.uim.d: No such file or directory % sudo apt-get install thailatex --reinstall Reading package lists... Done Building dependency tree Reading state information... Done 0 upgraded, 0 newly installed, 1 reinstalled, 0 to remove and 1 not upgraded. Need to get 0 B/246 kB of archives. After this operation, 0 B of additional disk space will be used. (Reading database ... 644368 files and directories currently installed.) Preparing to replace thailatex 0.4.7-3 (using .../thailatex_0.4.7-3_all.deb) ... Reverting babel.sty customization...done. remove/thailatex: purging byte-compiled files for emacs23 Unpacking replacement thailatex ... Processing triggers for doc-base ... Processing 1 changed doc-base file... Registering documents with dwww... Registering documents with scrollkeeper... Setting up thailatex (0.4.7-3) ... Customizing babel.sty...done. install/thailatex: Handling install for emacsen flavor emacs23 Loading 00debian-vars... Loading /etc/emacs/site-start.d/50a2ps.el (source)... Loading /etc/emacs/site-start.d/50anthy-el.el (source)... Loading /etc/emacs/site-start.d/50asymptote.el (source)... Loading /etc/emacs/site-start.d/50autoconf.el (source)... Loading /etc/emacs/site-start.d/50bbdb.el (source)... Loading /etc/emacs/site-start.d/50calc.el (source)... Loading /etc/emacs/site-start.d/50chess.el (source)... Loading /usr/share/emacs/site-lisp/chess/chess-auto.el (source)... Loading /etc/emacs/site-start.d/50css-mode.el (source)... Loading /etc/emacs/site-start.d/50dictionaries-common.el (source)... Loading debian-ispell... Loading /var/cache/dictionaries-common/emacsen-ispell-default.el (source)... Loading /var/cache/dictionaries-common/emacsen-ispell-dicts.el (source)... Loading /etc/emacs/site-start.d/50easypg.el (source)... Package easypg not available for this emacs flavour. Skipping. Loading /etc/emacs/site-start.d/50edict-el.el (source)... Loading /etc/emacs/site-start.d/50emacs-goodies-el.el (source)... Loading /etc/emacs/site-start.d/50emacs-intl-fonts.el (source)... Loading /etc/emacs/site-start.d/50erc.el (source)... Loading erc-auto... Loading /etc/emacs/site-start.d/50festival.el (source)... Loading /etc/emacs/site-start.d/50gettext.el (source)... Loading /etc/emacs/site-start.d/50gnugo.el (source)... Loading /etc/emacs/site-start.d/50gnus-bonus-el.el (source)... Loading /etc/emacs/site-start.d/50gri.el (source)... Loading /etc/emacs/site-start.d/50gtypist.el (source)... Loading /etc/emacs/site-start.d/50haskell-mode.el (source)... Loading /usr/share/emacs/site-lisp/haskell-mode/haskell-site-file.el (source)... Loading /etc/emacs/site-start.d/50html-helper-mode.el (source)... Loading /etc/emacs/site-start.d/50latex-cjk-common.el (source)... Loading cjk-enc... Loading /etc/emacs/site-start.d/50latex-cjk-thai.el (source)... Loading /etc/emacs/site-start.d/50lilypond.el (source)... Loading /etc/emacs/site-start.d/50maxima.el (source)... Loading /etc/emacs/site-start.d/50muse-el.el (source)... Loading /usr/share/emacs23/site-lisp/muse-el/muse-autoloads.el (source)... Loading /etc/emacs/site-start.d/50org-mode.el (source)... Loading /etc/emacs/site-start.d/50riece.el (source)... Loading /etc/emacs/site-start.d/50thailatex.el (source)... Loading /etc/emacs/site-start.d/50uim-el.el (source)... uim.el: starting uim-el-helper-agent... uim.el: starting uim-el-helper-agent... done uim.el: starting uim-el-agent... uim.el: starting uim-el-agent... done Loading /etc/emacs/site-start.d/50vm-bonus-el.el (source)... Loading /etc/emacs23/site-start.d/50vm-init.el (source)... Loading /etc/emacs/site-start.d/51planner-el.el (source)... Loading /usr/share/emacs23/site-lisp/planner-el/planner-autoloads.el (source)... Loading /etc/emacs/site-start.d/52remember-el.el (source)... Loading /usr/share/emacs/site-lisp/remember-el/remember-autoloads.el (source)... Wrote /usr/share/emacs23/site-lisp/thailatex/thai-latex-setup.elc Processing triggers for tex-common ... Running mktexlsr. This may take some time... done. Running mtxrun --generate. This may take some time... done. % ps -AF|grep '[r]oot.*uim';ls -lad /root/.uim.d root 29703 1 0 513 660 1 10:37 ?00:00:00 /usr/lib/uim/uim-helper-server drwx-- 3 root root 4096 May 7 10:37 /root/.uim.d -- System Information: Debian Release: wheezy/sid APT prefers testing APT policy: (900, 'testing'), (900, 'stable') Architecture: i386 (x86_64) Kernel: Linux 3.2.0-2-amd64 (SMP w/2 CPU cores) Locale: LANG=ru_RU.UTF-8, LC_CTYPE=ru_RU.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages uim-el depends on: ii emacs23-lucid [emacsen] 23.4+1-3 ii libc62.13-32 ii libgcroots0
Bug#671829: gnubik: ships /usr/share/icons/hicolor/icon-theme.cache
Package: gnubik Version: 2.4-2 Severity: normal File /usr/share/icons/hicolor/icon-theme.cache is included in gnubik but at the same time is managed automatically by hicolor-icon-theme. As a result installed file is different from the one included in the package (causing debsubs error) and will probably be removed upon removal of hicolor-icon-theme. And installation of the shipped file is probably going to break other packages' icons. -- System Information: Debian Release: wheezy/sid APT prefers testing APT policy: (900, 'testing'), (900, 'stable') Architecture: i386 (x86_64) Kernel: Linux 3.2.0-2-amd64 (SMP w/2 CPU cores) Locale: LANG=ru_RU.UTF-8, LC_CTYPE=ru_RU.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages gnubik depends on: ii dpkg 1.16.2 ii guile-1.8-libs1.8.8+1-8 ii install-info 4.13a.dfsg.1-10 ii libatk1.0-0 2.4.0-2 ii libc6 2.13-32 ii libcairo2 1.10.2-7 ii libfontconfig12.8.0-3.1 ii libfreetype6 2.4.9-1 ii libgdk-pixbuf2.0-02.26.1-1 ii libgl1-mesa-glx [libgl1] 7.11.2-1 ii libglib2.0-0 2.32.0-4 ii libglu1-mesa [libglu1]7.11.2-1 ii libgtk2.0-0 2.24.10-1 ii libgtkglext1 1.2.0-2 ii libice6 2:1.0.8-2 ii libpango1.0-0 1.29.4-3+b1 ii libsm62:1.2.1-2 ii libx11-6 2:1.4.4-4 ii libxmu6 2:1.1.1-1 ii libxt61:1.1.3-1 gnubik recommends no packages. gnubik suggests no packages. -- no debconf information -- debsums errors found: debsums: changed file /usr/share/icons/hicolor/icon-theme.cache (from gnubik package) -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#671053: lxc: Junk instead of Russian debconf translation
Package: lxc Version: 0.8.0~rc1-4 Severity: important Tags: patch l10n Dear Maintainer, «dpkg-reconfigure lxc» shows junk instead of questions in ru_RU.UTF-8 locale (screenshot attached). Spanish translation also seems to be affected. Looks like ru.po and es.po were misencoded during email transfer. The following commands should fix the situation: iconv -f utf-8 -t latin1 debian/po/ru.po debian/po/ru.po.tmp mv debian/po/ru.po.tmp debian/po/ru.po iconv -f utf-8 -t latin1 debian/po/es.po debian/po/es.po.tmp mv debian/po/es.po.tmp debian/po/es.po -- System Information: Debian Release: wheezy/sid APT prefers testing APT policy: (900, 'testing'), (900, 'stable') Architecture: i386 (x86_64) Kernel: Linux 2.6.32-5-amd64 (SMP w/2 CPU cores) Locale: LANG=ru_RU.UTF-8, LC_CTYPE=ru_RU.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages lxc depends on: ii debconf [debconf-2.0] 1.5.42 ii libc6 2.13-30 ii libcap21:2.22-1 ii multiarch-support 2.13-30 Versions of packages lxc recommends: ii debootstrap 1.0.39 ii libcap2-bin 1:2.22-1 Versions of packages lxc suggests: ii lxctl 0.3.1+debian-1 -- Configuration Files: /etc/default/lxc changed [not included] -- debconf information excluded inline: lxc.png
Bug#650037: fbreader: fails to open 2 GiB archives
Package: fbreader Version: 0.10.7dfsg-4 Severity: normal Tags: lfs fbreader silently refuses to open zip archives that are over 2 GiB in size. Such files appear to be ignored when found in the book path. -- System Information: Debian Release: 6.0.3 APT prefers stable APT policy: (900, 'stable') Architecture: i386 (x86_64) Kernel: Linux 2.6.32-5-amd64 (SMP w/2 CPU cores) Locale: LANG=ru_RU.UTF-8, LC_CTYPE=ru_RU.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages fbreader depends on: ii libc6 2.11.2-10Embedded GNU C Library: Shared lib ii libgcc1 1:4.4.5-8GCC support library ii libstdc++6 4.4.5-8 The GNU Standard C++ Library v3 ii libzlcore0.10 0.10.7dfsg-4 ZLibrary cross-platform developmen ii libzltext0.10 0.10.7dfsg-4 ZLibrary text model/viewer part (s ii libzlui-qt4 0.10.7dfsg-4 Qt4 interface module for ZLibrary fbreader recommends no packages. fbreader 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#649612: /usr/lib/zlibrary/ui/zlui-qt4.so: undefined symbol: _ZN9QListData6detachEi
Package: libzlui-qt4 Version: 0.12.10dfsg-5 Severity: serious File: /usr/lib/zlibrary/ui/zlui-qt4.so Justification: Policy 3.5 % fbreader loading /usr/lib/zlibrary/ui/zlui-qt4.so /usr/lib/zlibrary/ui/zlui-qt4.so: undefined symbol: _ZN9QListData6detachEi Looks like libzlui-qt4 fails to depend on correct version of libqtcore4 (_ZN9QListData6detachEi is available since 4:4.7.0~beta1, squeeze has 4:4.6.3-4+squeeze1). In fact, libzlui-qt4 does not list libqtcore4 as a dependency at all. Judging from the following warnings in build logs dpkg-shlibdeps: warning: debian/libzlui-qt4/usr/lib/zlibrary/ui/zlui-qt4.so contains an unresolvable reference to symbol _ZN7QString16codecForCStringsE: it's probably a plugin. dpkg-shlibdeps: warning: 35 other similar warnings have been skipped (use -v to see them all). I guess that zlui-qt4.so uses symbols from libQtCore.so but fails to link directly with it, preventing dpkg-shlibdeps from adding required dependency. -- System Information: Debian Release: 6.0.3 APT prefers stable APT policy: (900, 'stable') Architecture: i386 (x86_64) Kernel: Linux 2.6.32-5-amd64 (SMP w/2 CPU cores) Locale: LANG=ru_RU.UTF-8, LC_CTYPE=ru_RU.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages libzlui-qt4 depends on: ii libc6 2.11.2-10 Embedded GNU C Library: Shared lib ii libgcc1 1:4.4.5-8 GCC support library ii libqtgui4 4:4.6.3-4+squeeze1 Qt 4 GUI module ii libstdc++64.4.5-8The GNU Standard C++ Library v3 ii libzlcore0.12 0.12.10dfsg-5 ZLibrary cross-platform developmen libzlui-qt4 recommends no packages. libzlui-qt4 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#648921: catdoc 0.94.2-2 started to replace parts of rtf with junk
Package: catdoc Version: 0.94.2-2 Severity: important In addition to replacing letter я with BOM (#648726) catdoc 0.94.2-2 started to replace significant parts of the text with latin1 junk in rtf documents. Catdoc 0.94.2-1.1 appears to work correctly. (Sample document and outputs of both catdoc versions attached.) Also, catdoc 0.94.2-2 seems to print hexadecimal dumps (pictures?) in some rtfs, while catdoc 0.94.2-1.1 produces readable text. -- System Information: Debian Release: 6.0.3 APT prefers stable APT policy: (900, 'stable') Architecture: i386 (x86_64) Kernel: Linux 2.6.32-5-amd64 (SMP w/2 CPU cores) Locale: LANG=ru_RU.UTF-8, LC_CTYPE=ru_RU.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages catdoc depends on: ii libc6 2.11.2-10 Embedded GNU C Library: Shared lib catdoc recommends no packages. Versions of packages catdoc suggests: ii tk8.4 [wish] 8.4.19-4 Tk toolkit for Tcl and X11, v8.4 - ii tk8.5 [wish] 8.5.8-1Tk toolkit for Tcl and X11, v8.5 - -- no debconf information 25apr04.rtf Description: RTF file 1 Информационное письмо № 1 Самарский Государственный Университет 25 апрел 2004 г. проводит птый командный чемпионат Самарской области по программированию среди высших учебных заведений. Чемпионат проводитс с целью повышени профессиональной подготовки студентов Самарской области и как один из этапов подготовки к Чемпионату мира по программированию среди студентов. Чемпионат будет проходить в дисплейных классах Самарского Государственного Университета. В чемпионате могут принимать участие любые высшие учебные заведени г. Самара и Самарской области. Команды формируютс из 3-х основных участников и одного запасного. В состав каждой команды могут входить студенты с первого по четвертый курс включительно. В соревнованих смогут принть участие до трех команд от каждого вуза. Участники соревнований должны знать основы алгоритмизации и уметь программировать на одном из зыков программировани Pascal èëè C++ (ïî âûáîðó ó÷àñòíèêîâ). Êàæäîé êîìàíäå íà âðåì ïðîâåäåíè ñîðåâíîâàíèé áóäåò ïðåäîñòàâëåí îäèí IBM-ñîâìåñòèìûé êîìïüþòåð. ×åìïèîíàò áóäåò ïðîõîäèòü â ðåæèìå ðåàëüíîãî âðåìåíè, ò.å. òåêñòû èñõîäíûõ ïðîãðàìì, íàïèñàííûå íà çûêå Pascal èëè C++ (ïî âûáîðó êîìàíäû), áóäóò àâòîìàòèçèðîâàííî òåñòèðîâàòüñ ñ ïîìîùüþ ñïåöèàëüíîé ïðîãðàììû Æþðè ÷åìïèîíàòà. Ïðîãðàììà, óñïåøíî ïðîøåäøà ÂÑÅ èñïûòàòåëüíûå òåñòû, ñ÷èòàåòñ ïðèíòîé, à èñõîäíà çàäà÷à – ðåø¸ííîé. Çà êàæäóþ ïîïûòêó ñäà÷è ïðîãðàììû, íàïèñàííîé ñ îøèáêàìè, íà÷èñëþòñ øòðàôíûå áàëëû. Ïîáåäèòåëåì ÷åìïèîíàòà îáúâëåòñ êîìàíäà, ðåøèâøà íàèáîëüøåå ÷èñëî çàäà÷ èç âñåõ ïðåäëîæåííûõ è ñ íàèìåíüøèì ÷èñëîì øòðàôíûõ ìèíóò. Âñå çàäà÷è ôîðìàëüíî ñ÷èòàþòñ ðàâíîöåííûìè. Êîìàíäû - ïðèçåðû íàãðàæäàþòñ äèïëîìàìè è öåííûìè ïðèçàìè ÑàìÃÓ. Äë ó÷àñòè â ÷åìïèîíàòå ðåêòîðó âóçà íåîáõîäèìî ïðåäñòàâèòü çàâêó, êîòîðà çàïîëíåòñ ìàøèíîïèñíûì ñïîñîáîì èëè ïåðåñûëàåòñ â ýëåêòðîííîì ôîðìàòå ïî óêàçàííîìó íèæå ýëåêòðîííîìó àäðåñó. Çàâêà íà ó÷àñòèå äîëæíà áûòü ïðåäñòàâëåíà íå ïîçäíåå 20 àïðåë 2004 ãîäà. Регистраци участников будет проходить 25 апрел с 9 часов в фойе главного корпуса Самарского Государственного Университета по адресу: 443011, Самара, ул. академика Павлова, 1, Самарский Государственный Университет, механико-математический факультет. Проезд трамвами маршрутов 5, 20, 22 до остановки “Государственный университет”, автобусами маршрутов 25, 50, 50к, 61 до остановки “Государственный университет”. Начало чемпионата в 9-45. По всем вопросам проведени чемпионата обращатьс: СамГУ, к. 306 м/м, Ефимов Александр Евгеньевич, технический директор, E-Mail:a...@samara.net ; ÑàìÃÓ, êàôåäðà Èíôîðìàòèêè è Âû÷èñëèòåëüíîé Ìàòåìàòèêè, ê. 303 ì/ì, Ëóêàíîâ Àëåêñàíäð Ñåðãååâè÷, òåë. 34-79-92, E-Mail:l...@ssu.samara.ru Более подробную информацию Вы можете найти на сайте СамГУ по адресу: http://contest.samara.ru Ïî ýòîìó æå àäðåñó Âû ìîæåòå îôîðìèòü çàâêó íà ó÷àñòèå ÷åðåç Internet Организационный комитет чемпионата: Председатель: Яровой Геннадий Петрович, д.ф.-м.н, профессор, ректор СамГУ, Председатель комитета по Информатизации при Совете Ректоров ВУЗов Самарской области. Заместитель председател: Астафьев Владимир Иванович, д.ф.-м.н., профессор, декан механико-математического факультета СамГУ; Члены Оргкомитета: Радченко Владимир Павлович, д.ф.-м.н., профессор, СамГТУ. Степанов Анатолий Николаевич, д.ф.-м.н., профессор, зав. каф. ИиВМ СамГУ; Председатель Жюри Чемпионата: Луканов Александр Сергеевич, к.ф.-м.н., доцент каф. ИиВМ, СамГУ; Члены Жюри: Гутман Геннадий Натанович, к.т.н., доцент каф. ПМиИ, СГТУ; Лукиных Анатолий Валерьевич, к.т.н., доцент каф. ВМ, СГТУ; Пшеничников Виктор Владимирович, к.т.н., доцент каф. СИИТ, СГАУ; Рогачева Елена Валерьевна, к.ф.-м.н., доцент каф. ИиВМ, СамГУ;
Bug#645195: python2.6: Incorrect time.timezone after recent tzdata upgrades
Package: python2.6 Version: 2.6.6-8+b1 It was noticed that after upgrade of tzdata to 2011h-0squeeze1 (which changed local time from UTC+3+DST (effective UTC+4) to UTC+4) Date: header in mails from buildbot started to contain incorrect timezone offsets (while having correct local time value). (Timestamps in twistd.log remained correct even after reboot.) With tzdata 2011k-0squeeze1 and Europe/Samara as a timezone: % python -c 'import email.utils; print email.utils.formatdate(); print email.utils.formatdate(localtime=1)';date -R Thu, 13 Oct 2011 12:22:12 - Thu, 13 Oct 2011 16:22:12 +0300 Thu, 13 Oct 2011 16:22:12 +0400 The culprit seems to be time.timezone value which still indicates UTC+3, while time.localtime() returns correct local time. time.daylight and time.localtime().tm_isdst do not match. % python -c 'import time; print time.timezone; print time.daylight; print time.localtime().tm_isdst;' -10800 1 0 -- System Information: Debian Release: 6.0.3 APT prefers stable-updates APT policy: (900, 'stable-updates'), (900, 'stable') Architecture: i386 (i686) Kernel: Linux 2.6.32-5-686 (SMP w/1 CPU core) Locale: LANG=ru_RU.UTF-8, LC_CTYPE=ru_RU.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages python2.6 depends on: ii libbz2-1.01.0.5-6high-quality block-sorting file co ii libc6 2.11.2-10 Embedded GNU C Library: Shared lib ii libdb4.8 4.8.30-2 Berkeley v4.8 Database Libraries [ ii libexpat1 2.0.1-7XML parsing C library - runtime li ii libncursesw5 5.7+20100313-5 shared libraries for terminal hand ii libreadline6 6.1-3 GNU readline and history libraries ii libsqlite3-0 3.7.3-1SQLite 3 shared library ii mime-support 3.48-1 MIME files 'mime.types' 'mailcap ii python2.6-minimal 2.6.6-8+b1 A minimal subset of the Python lan python2.6 recommends no packages. Versions of packages python2.6 suggests: ii binutils 2.20.1-16 The GNU assembler, linker and bina pn python2.6-doc none (no description available) pn python2.6-profilernone (no description available) -- 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#602743: geeqie: invisible fullscreen window prevents screensaver from working
03.09.2011 в 19:48:53 +0100 Klaus Ethgen написал: Am So den 7. Nov 2010 um 19:01 schrieb Stepan Golosunov: geeqie attempts to prevents screensaver from working when it is opened in fullscreen mode, but is not visible (like when it's opened on another workspace or when screen is locked by xscreensaver). What do you expect geeqie should do? The method geeqie is using to prevent the screensaver from locking the screen is very basically as there is no method that works with all screensavers. However, the method used cannot difference between workspaces. So I see no way to do that for different workspaces independent. Isn't there a method to determine whether window is actually visible? (After a very shallow glance to documentation) Doesn't GtkWidget's visibility-notify-event signal do what's needed? -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#625539: /usr/bin/vlc: vlc --help ignores locale's charset
reopen 625539 thanks 12.08.2011 в 09:59:11 +0200 Rémi Denis-Courmont написал(а): close 625539 As can be seen from your bug report, the characters map is UTF-8: Locale: LANG=ru_RU.UTF-8, LC_CTYPE=ru_RU.UTF-8 (charmap=UTF-8) so it is normal behavior for VLC to output Russian (LANG) in UTF-8 (LC_CTYPE). As bug report says it is reproducible in ru_RU.KOI8-R (as well as in all other non-utf8 locales I tested), not in the locale used by reportbug. (I tested non utf-8 locales upon stumbling on utf8-specific bugs. And yes, I usually double check locale settings by running other programs like locale, date or locale --help in the same terminal.) If you wish to output with another character encoding, please configure LC_CTYPE correctly. (I did it before reporting the bug.) Not however that future VLC versions will drop support for non-UTF-8 on POSIX systems, so I'd advise against it. The bug is about this support already broken in VLC 1.1.3 and 1.1.9. (I did not test 1.1.11 yet.) -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#628394: ttf-oldstandard: new version available
Package: ttf-oldstandard Severity: wishlist Version 2.2 of the Old Standard fonts is available at http://www.thessalonica.org.ru/en/fonts-download.html (Debian's version 2.2-3 package actually contains version 2.0.2 of the fonts.) -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#625539: /usr/bin/vlc: vlc --help ignores locale's charset
Package: vlc-nox Version: 1.1.9-1 Severity: normal File: /usr/bin/vlc Tags: l10n vlc --help ignores current locale's charset and always outputs utf-8. This results in complete garbage in locales like ru_RU.KOI8-R. -- System Information: Debian Release: wheezy/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Kernel: Linux 2.6.38-2-686 (SMP w/1 CPU core) Locale: LANG=ru_RU.UTF-8, LC_CTYPE=ru_RU.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages vlc-nox depends on: ii liba52-0.7.40.7.4-15 library for decoding ATSC A/52 str ii libasound2 1.0.23-3 shared library for ALSA applicatio ii libass4 0.9.11-1 library for SSA/ASS subtitles rend ii libavahi-client30.6.30-3 Avahi client library ii libavahi-common30.6.30-3 Avahi common library ii libavc1394-00.5.3-1+b2 control IEEE 1394 audio/video devi ii libavcodec524:0.6.2-3Libav codec library ii libavformat52 4:0.6.2-3Libav file format library ii libavutil50 4:0.6.2-3Libav utility library ii libc6 2.13-2 Embedded GNU C Library: Shared lib ii libcaca00.99.beta17-1colour ASCII art library ii libcddb21.3.2-3 library to access CDDB data - runt ii libcdio10 0.81-4 library to read and control CD-ROM ii libdbus-1-3 1.4.8-3 simple interprocess messaging syst ii libdc1394-222.1.3-1 high level programming interface f ii libdca0 0.0.5-4 decoding library for DTS Coherent ii libdirac-encoder0 1.0.2-3 open and royalty free high quality ii libdvbpsi6 0.1.7-1 library for MPEG TS and DVB PSI ta ii libdvdnav4 4.1.3-7 DVD navigation library ii libdvdread4 4.1.3-10 library for reading DVDs ii libebml31.2.0-2 access library for the EBML format ii libfaad22.7-6freeware Advanced Audio Decoder - ii libflac81.2.1-3 Free Lossless Audio Codec - runtim ii libfontconfig1 2.8.0-2.2generic font configuration library ii libfreetype62.4.4-1 FreeType 2 font engine, shared lib ii libfribidi0 0.19.2-1 Free Implementation of the Unicode ii libgcc1 1:4.6.0-6GCC support library ii libgcrypt11 1.4.6-5 LGPL Crypto library - runtime libr ii libgnutls26 2.10.5-1+b1 the GNU TLS library - runtime libr ii libgpg-error0 1.10-0.3 library for common error values an ii libkate10.3.8-1 Kate is a codec for karaoke and te ii liblircclient0 0.9.0~pre1-1 infra-red remote control support - ii liblua5.1-0 5.1.4-5 Simple, extensible, embeddable pro ii libmad0 0.15.1b-6MPEG audio decoder library ii libmatroska31.1.0-2 extensible open standard audio/vid ii libmodplug1 1:0.8.8.2-3 shared libraries for mod music bas ii libmpcdec6 2:0.1~r459-1 MusePack decoder - library ii libmpeg2-4 0.4.1-3 MPEG1 and MPEG2 video decoder libr ii libmtp8 1.0.6-4 Media Transfer Protocol (MTP) libr ii libncursesw55.9-1shared libraries for terminal hand ii libogg0 1.2.0~dfsg-1 Ogg bitstream library ii libpng12-0 1.2.44-2 PNG library - runtime ii libpostproc51 4:0.6.2-3Libav video postprocessing library ii libproxy0 0.3.1-2 automatic proxy configuration mana ii libraw1394-11 2.0.7-1 library for direct access to IEEE ii libschroedinger-1.0-0 1.0.10-2 library for encoding/decoding of D ii libshout3 2.2.2-5+b1 MP3/Ogg Vorbis broadcast streaming ii libsmbclient2:3.5.8~dfsg-1 shared library for communication w ii libspeex1 1.2~rc1-1The Speex codec runtime library ii libstdc++6 4.6.0-6 The GNU Standard C++ Library v3 ii libswscale0 4:0.6.2-3Libav video scaling library ii libtag1c2a 1.7-1audio meta-data library ii libtheora0 1.1.1+dfsg.1-3 The Theora Video Compression Codec ii libtwolame0 0.3.12-1 MPEG Audio Layer 2 encoding librar ii libudev0168-1libudev shared library ii libupnp31:1.6.6-5Portable SDK for UPnP Devices, ver ii libv4l-00.8.3-2 Collection of video4linux support ii libvcdinfo0 0.7.23-4+b2 library to extract information fro ii libvlc5
Bug#625540: /usr/bin/vlc: vlc --help word wrapping splits letters into bytes
Package: vlc-nox Version: 1.1.9-1 Severity: normal File: /usr/bin/vlc Tags: upstream l10n In addition to the usual misalignment caused by counting bytes (and even not characters) instead of columns (I think wcswidth exists for that) vlc --help in ru_RU.UTF-8 locale now wraps words inside letters: --version, --no-versionпоказать информацию о версии (по умолчанию выключено) --config строкаиспользовать альтернатиD0 B2ный файл конфигурации -- System Information: Debian Release: wheezy/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Kernel: Linux 2.6.38-2-686 (SMP w/1 CPU core) Locale: LANG=ru_RU.UTF-8, LC_CTYPE=ru_RU.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages vlc-nox depends on: ii liba52-0.7.40.7.4-15 library for decoding ATSC A/52 str ii libasound2 1.0.23-3 shared library for ALSA applicatio ii libass4 0.9.11-1 library for SSA/ASS subtitles rend ii libavahi-client30.6.30-3 Avahi client library ii libavahi-common30.6.30-3 Avahi common library ii libavc1394-00.5.3-1+b2 control IEEE 1394 audio/video devi ii libavcodec524:0.6.2-3Libav codec library ii libavformat52 4:0.6.2-3Libav file format library ii libavutil50 4:0.6.2-3Libav utility library ii libc6 2.13-2 Embedded GNU C Library: Shared lib ii libcaca00.99.beta17-1colour ASCII art library ii libcddb21.3.2-3 library to access CDDB data - runt ii libcdio10 0.81-4 library to read and control CD-ROM ii libdbus-1-3 1.4.8-3 simple interprocess messaging syst ii libdc1394-222.1.3-1 high level programming interface f ii libdca0 0.0.5-4 decoding library for DTS Coherent ii libdirac-encoder0 1.0.2-3 open and royalty free high quality ii libdvbpsi6 0.1.7-1 library for MPEG TS and DVB PSI ta ii libdvdnav4 4.1.3-7 DVD navigation library ii libdvdread4 4.1.3-10 library for reading DVDs ii libebml31.2.0-2 access library for the EBML format ii libfaad22.7-6freeware Advanced Audio Decoder - ii libflac81.2.1-3 Free Lossless Audio Codec - runtim ii libfontconfig1 2.8.0-2.2generic font configuration library ii libfreetype62.4.4-1 FreeType 2 font engine, shared lib ii libfribidi0 0.19.2-1 Free Implementation of the Unicode ii libgcc1 1:4.6.0-6GCC support library ii libgcrypt11 1.4.6-5 LGPL Crypto library - runtime libr ii libgnutls26 2.10.5-1+b1 the GNU TLS library - runtime libr ii libgpg-error0 1.10-0.3 library for common error values an ii libkate10.3.8-1 Kate is a codec for karaoke and te ii liblircclient0 0.9.0~pre1-1 infra-red remote control support - ii liblua5.1-0 5.1.4-5 Simple, extensible, embeddable pro ii libmad0 0.15.1b-6MPEG audio decoder library ii libmatroska31.1.0-2 extensible open standard audio/vid ii libmodplug1 1:0.8.8.2-3 shared libraries for mod music bas ii libmpcdec6 2:0.1~r459-1 MusePack decoder - library ii libmpeg2-4 0.4.1-3 MPEG1 and MPEG2 video decoder libr ii libmtp8 1.0.6-4 Media Transfer Protocol (MTP) libr ii libncursesw55.9-1shared libraries for terminal hand ii libogg0 1.2.0~dfsg-1 Ogg bitstream library ii libpng12-0 1.2.44-2 PNG library - runtime ii libpostproc51 4:0.6.2-3Libav video postprocessing library ii libproxy0 0.3.1-2 automatic proxy configuration mana ii libraw1394-11 2.0.7-1 library for direct access to IEEE ii libschroedinger-1.0-0 1.0.10-2 library for encoding/decoding of D ii libshout3 2.2.2-5+b1 MP3/Ogg Vorbis broadcast streaming ii libsmbclient2:3.5.8~dfsg-1 shared library for communication w ii libspeex1 1.2~rc1-1The Speex codec runtime library ii libstdc++6 4.6.0-6 The GNU Standard C++ Library v3 ii libswscale0 4:0.6.2-3Libav video scaling library ii libtag1c2a 1.7-1audio meta-data library ii libtheora0 1.1.1+dfsg.1-3 The Theora Video Compression Codec ii libtwolame0 0.3.12-1 MPEG
Bug#610617: idn -u fails to convert domains starting with upper-case XN--
Package: idn Version: 1.15-2 Severity: important idn fails to convert domains from ACE when starting XN letters are not in lower case: % idn --quiet -u XN7SBAABF4DLDYSIEHP4NTB.XN--P1AI XN7SBAABF4DLDYSIEHP4NTB.XN--P1AI % idn --quiet -u xn7SBAABF4DLDYSIEHP4NTB.XN--P1AI самарская-область.XN--P1AI % idn --quiet -u xn7sbaabf4dldysiehp4ntb.xn--p1ai самарская-область.рф This is highly inconvenient, as many places like whois service present domains in upper case form. -- System Information: Debian Release: 6.0 APT prefers testing APT policy: (900, 'testing'), (300, 'stable') Architecture: i386 (x86_64) Kernel: Linux 2.6.32-5-amd64 (SMP w/2 CPU cores) Locale: LANG=ru_RU.UTF-8, LC_CTYPE=ru_RU.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages idn depends on: ii libc6 2.11.2-7 Embedded GNU C Library: Shared lib ii libidn11 1.15-2 GNU Libidn library, implementation idn recommends no packages. idn 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#608701: dictfmt: missing dependency on mawk
Package: dictfmt Version: 1.11.2+dfsg-2 Severity: serious Justification: Policy 3.5 dictfmt Depends: on gawk while scripts in the package hardcode mawk invocation: grep awk /usr/bin/dict* /usr/bin/dictfmt_index2suffix:mawk -v utf8_mode=$utf8_mode ' /usr/bin/dictfmt_index2word:awk ' /usr/bin/dictunformat:exec mawk ' Which results in % dictunformat --help exec: 248: mawk: not found -- System Information: Debian Release: squeeze/sid APT prefers testing APT policy: (900, 'testing'), (300, 'stable') Architecture: i386 (x86_64) Kernel: Linux 2.6.32-5-amd64 (SMP w/2 CPU cores) Locale: LANG=ru_RU.UTF-8, LC_CTYPE=ru_RU.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages dictfmt depends on: ii gawk 1:3.1.7.dfsg-5 GNU awk, a pattern scanning and pr ii libc6 2.11.2-7 Embedded GNU C Library: Shared lib ii libmaa2 1.2.0-1The maa programming library Versions of packages dictfmt recommends: ii dictzip1.11.2+dfsg-2 compression utility for dictionary dictfmt 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#602057: /usr/bin/cal: fails to display correctly first day of week
14.11.2010 в 15:56:57 +0100 Michael Meskes написал(а): On Fri, Nov 05, 2010 at 01:42:18AM +0400, Stepan Golosunov wrote: Frankly I don't see the bug here. cal is supposed to just start weeks with a Sunday and Nov 1st was a Monday, so what should it do? For at least two stable it started weeks on Monday. cal wasn't doing what it was supposed to do according to its own manpage. How so? I don't see anything related in the manpage. Therefore this got fixed. If you need the old output please use ncal -b instead. Does not work: % ncal -b ncal: неверный ключ -- «b» usage: cal [-hjy] [[month] year] cal [-hj] [-m month] [year] ncal [-hJjpwy3MS] [-s country_code] [[month] year] ncal [-hJeo] [year] -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#602743: geeqie: invisible fullscreen window prevents screensaver from working
Package: geeqie Version: 1:1.0-7 Severity: normal geeqie attempts to prevents screensaver from working when it is opened in fullscreen mode, but is not visible (like when it's opened on another workspace or when screen is locked by xscreensaver). -- System Information: Debian Release: squeeze/sid APT prefers testing APT policy: (900, 'testing'), (300, 'stable') Architecture: i386 (x86_64) Kernel: Linux 2.6.32-5-amd64 (SMP w/2 CPU cores) Locale: LANG=ru_RU.UTF-8, LC_CTYPE=ru_RU.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages geeqie depends on: ii geeqie-common 1:1.0-7 data files for Geeqie ii libc6 2.11.2-7 Embedded GNU C Library: Shared lib ii libexiv2-9 0.20-2 EXIF/IPTC metadata manipulation li ii libgcc1 1:4.4.5-4GCC support library ii libglib2.0-02.24.2-1 The GLib library of C routines ii libgtk2.0-0 2.20.1-2 The GTK+ graphical user interface ii liblcms11.18.dfsg-1.2+b3 Color management library ii liblircclient0 0.8.3-5 infra-red remote control support - ii libpango1.0-0 1.28.3-1 Layout and rendering of internatio ii libstdc++6 4.4.5-4 The GNU Standard C++ Library v3 Versions of packages geeqie recommends: pn exiftran none(no description available) ii exiv2 0.20-2EXIF/IPTC metadata manipulation to ii imagemagick8:6.6.0.4-2.2 image manipulation programs ii librsvg2-common2.26.3-1 SAX-based renderer library for SVG pn ufraw-batchnone(no description available) ii zenity 2.30.0-1 Display graphical dialog boxes fro Versions of packages geeqie suggests: ii geeqie-dbg1:1.0-7debug symbols for Geeqie ii gimp 2.6.10-1 The GNU Image Manipulation Program ii libjpeg-progs 8b-1 Programs for manipulating JPEG fil pn ufraw none (no description available) ii xpaint2.9.1.4-1 simple paint program for X -- 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#602744: geeqie: fails to prevent screen from blanking in fullscreen mode
Package: geeqie Version: 1:1.0-7 Severity: normal While geeqie successfully prevents automatic screen locking by xscreensaver when in fullscreen mode, it fails to prevent screen from beeing blanked. This is easily reproducible with xset dpms 1. -- System Information: Debian Release: squeeze/sid APT prefers testing APT policy: (900, 'testing'), (300, 'stable') Architecture: i386 (x86_64) Kernel: Linux 2.6.32-5-amd64 (SMP w/2 CPU cores) Locale: LANG=ru_RU.UTF-8, LC_CTYPE=ru_RU.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages geeqie depends on: ii geeqie-common 1:1.0-7 data files for Geeqie ii libc6 2.11.2-7 Embedded GNU C Library: Shared lib ii libexiv2-9 0.20-2 EXIF/IPTC metadata manipulation li ii libgcc1 1:4.4.5-4GCC support library ii libglib2.0-02.24.2-1 The GLib library of C routines ii libgtk2.0-0 2.20.1-2 The GTK+ graphical user interface ii liblcms11.18.dfsg-1.2+b3 Color management library ii liblircclient0 0.8.3-5 infra-red remote control support - ii libpango1.0-0 1.28.3-1 Layout and rendering of internatio ii libstdc++6 4.4.5-4 The GNU Standard C++ Library v3 Versions of packages geeqie recommends: pn exiftran none(no description available) ii exiv2 0.20-2EXIF/IPTC metadata manipulation to ii imagemagick8:6.6.0.4-2.2 image manipulation programs ii librsvg2-common2.26.3-1 SAX-based renderer library for SVG pn ufraw-batchnone(no description available) ii zenity 2.30.0-1 Display graphical dialog boxes fro Versions of packages geeqie suggests: ii geeqie-dbg1:1.0-7debug symbols for Geeqie ii gimp 2.6.10-1 The GNU Image Manipulation Program ii libjpeg-progs 8b-1 Programs for manipulating JPEG fil pn ufraw none (no description available) ii xpaint2.9.1.4-1 simple paint program for X -- 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#601858: libm17n-0: NULL pointer dereference in mlocale__init()
05.11.2010 в 23:10:10 +1100 Harshula написал(а): Hi Stepan, Would you be able to test this patch provided by upstream?: http://cvs.m17n.org/viewcvs/m17n/m17n-lib/src/locale.c?r1=1.12r2=1.13 With this patch vlc no longer crashes and is able to use m17n-ru-kbd input method via uim-qt when configured to do so. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#602057: /usr/bin/cal: fails to display correctly first day of week
04.11.2010 в 11:05:46 +0100 Michael Meskes написал(а): On Mon, Nov 01, 2010 at 09:25:35AM +0400, Stepan Golosunov wrote: cal fails to display first day of week correctly in ru_RU.UTF-8 locale: Ноябрь 2010 Вс Пн Вт Ср Чт Пт Сб 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 lenny and etch versions work fine: Ноябрь 2010 Пн Вт Ср Чт Пт Сб Вс 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 Does ncal work as you expect it? Yes. Frankly I don't see the bug here. cal is supposed to just start weeks with a Sunday and Nov 1st was a Monday, so what should it do? For at least two stable it started weeks on Monday. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#602057: /usr/bin/cal: fails to display correctly first day of week
Package: bsdmainutils Version: 8.0.13 Severity: important File: /usr/bin/cal cal fails to display first day of week correctly in ru_RU.UTF-8 locale: Ноябрь 2010 Вс Пн Вт Ср Чт Пт Сб 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 lenny and etch versions work fine: Ноябрь 2010 Пн Вт Ср Чт Пт Сб Вс 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 -- System Information: Debian Release: squeeze/sid APT prefers testing APT policy: (900, 'testing'), (300, 'stable') Architecture: i386 (x86_64) Kernel: Linux 2.6.32-5-amd64 (SMP w/2 CPU cores) Locale: LANG=ru_RU.UTF-8, LC_CTYPE=ru_RU.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages bsdmainutils depends on: ii bsdutils 1:2.17.2-3.3 Basic utilities from 4.4BSD-Lite ii debianutils3.4 Miscellaneous utilities specific t ii libc6 2.11.2-6+squeeze1 Embedded GNU C Library: Shared lib ii libncurses55.7+20100313-4shared libraries for terminal hand bsdmainutils recommends no packages. Versions of packages bsdmainutils suggests: ii cpp 4:4.4.5-1 The GNU C preprocessor (cpp) ii miscfiles [wordlist] 1.4.2.dfsg.1-9 Dictionaries and other interesting pn vacation none (no description available) ii wamerican [wordlist] 6-3American English dictionary words ii wbritish [wordlist] 6-3British English dictionary words f ii whois 5.0.8 an intelligent whois client ii wngerman [wordlist] 20091006-4.1 New German orthography wordlist -- debconf information: bsdmainutils/calendar_lib_is_not_empty: bsdmainutils/calendar_config_moved: -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#601858: libm17n-0: NULL pointer dereference in mlocale__init()
Package: libm17n-0 Version: 1.6.1-1 vlc 1.1.3-1 segfaults when it tries to display message saying that file supplied in command line does not exist. This happens when plugin from uim-qt 1:1.5.7-9+b1 tries to initialize m17nlib. mlocale_set() call returns NULL, while code in mlocale_init() doesn't expect it despite mlocale_set()'s documentation saying NULL can be returned. And mlocale_set() returns NULL because setlocale (LC_CTYPE, name) call in make_locale() returns NULL, probably because vlc is multithreaded. (Changing locale in one thread of a multithreaded application does not sound good.) % LANG=C gdb vlc GNU gdb (GDB) 7.0.1-debian Copyright (C) 2009 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type show copying and show warranty for details. This GDB was configured as i486-linux-gnu. For bug reporting instructions, please see: http://www.gnu.org/software/gdb/bugs/... Reading symbols from /usr/bin/vlc...(no debugging symbols found)...done. (gdb) run adsfasdfasdfasdf Starting program: /usr/bin/vlc adsfasdfasdfasdf [Thread debugging using libthread_db enabled] VLC media player 1.1.3 The Luggage (revision exported) Blocked: call to unsetenv(DBUS_ACTIVATION_ADDRESS) Blocked: call to unsetenv(DBUS_ACTIVATION_BUS_TYPE) Warning: call to signal(13, 0x1) [New Thread 0xf7bb1b70 (LWP 4191)] [New Thread 0xf79ffb70 (LWP 4192)] [Thread 0xf79ffb70 (LWP 4192) exited] [New Thread 0xf797eb70 (LWP 4194)] [0x804b0d4] main libvlc: Running vlc with the default interface. Use 'cvlc' to use vlc without interface. [New Thread 0xf79ffb70 (LWP 4195)] Blocked: call to setlocale(6, ) Blocked: call to sigaction(17, 0xf79ff0d4, 0xf79ff048) Blocked: call to setlocale(6, ) Warning: call to signal(13, 0x1) Warning: call to rand() Warning: call to rand() Warning: call to rand() [New Thread 0xf3cd7b70 (LWP 4196)] libdvdnav: Using dvdnav version 4.1.3 libdvdread: Using libdvdcss version 1.2.10 for DVD access libdvdread: Can't stat /home/stepan/adsfasdfasdfasdf No such file or directory libdvdnav: vm: failed to open/read the DVD [0x8335e2c] filesystem access error: cannot open file /home/stepan/adsfasdfasdfasdf (No such file or directory) [0xf7a00fbc] main input error: open of `file:///home/stepan/adsfasdfasdfasdf' failed: (null) [Thread 0xf3cd7b70 (LWP 4196) exited] Warning: call to rand() Warning: call to rand() Blocked: call to setlocale(6, ) Blocked: call to setlocale(0, C) Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 0xf79ffb70 (LWP 4195)] mlocale__init () at locale.c:283 283 locale.c: No such file or directory. in locale.c (gdb) bt #0 mlocale__init () at locale.c:283 #1 0xf387ef05 in m17n_init () at m17n.c:71 #2 0xf3d4c409 in init_m17nlib () at m17nlib.c:188 #3 0xf3c12ab3 in call (proc=value optimized out, args=30, eval_state=0xf79fc6b4, need_eval=SCM_VALTYPE_NEED_EVAL) at ../sigscheme/src/eval.c:413 #4 0xf3c12d69 in scm_eval (obj=value optimized out, env=value optimized out) at ../sigscheme/src/eval.c:499 #5 0xf3c1a6fd in scm_load_internal (filename=0x83b98b8 /usr/share/uim/m17nlib.scm) at ../sigscheme/src/load.c:216 #6 0xf39129bf in GCROOTS_call_with_gc_ready_stack () from /usr/lib/libgcroots.so.0 #7 0xf3c10fe7 in scm_call_with_gc_ready_stack (filename=138133844) at ../sigscheme/src/storage-gc.c:376 #8 scm_load (filename=138133844) at ../sigscheme/src/load.c:182 #9 scm_require_internal (filename=138133844) at ../sigscheme/src/module-sscm-ext.c:229 #10 scm_p_require (filename=138133844) at ../sigscheme/src/module-sscm-ext.c:245 #11 0xf3c12aa8 in call (proc=value optimized out, args=30, eval_state=0xf79fc914, need_eval=SCM_VALTYPE_AS_IS) at ../sigscheme/src/eval.c:415 #12 0xf3c12a63 in call (proc=value optimized out, args=30, eval_state=0xf79fc914, need_eval=SCM_VALTYPE_NEED_EVAL) at ../sigscheme/src/eval.c:424 #13 0xf3c12d69 in scm_eval (obj=value optimized out, env=value optimized out) at ../sigscheme/src/eval.c:499 #14 0xf3c150af in guard_body (eval_state=0xf79fca14) at ../sigscheme/src/module-srfi34.c:446 #15 0xf3c12aa8 in call (proc=value optimized out, args=30, eval_state=0xf79fca14, need_eval=SCM_VALTYPE_NEED_EVAL) at ../sigscheme/src/eval.c:415 #16 0xf3c12d69 in scm_eval (obj=value optimized out, env=value optimized out) at ../sigscheme/src/eval.c:499 #17 0xf3c13817 in scm_call (proc=value optimized out, args=value optimized out) at ../sigscheme/src/eval.c:94 #18 0xf3c1396f in scm_dynamic_wind (before=138133426, thunk=138133474, after=138133386) at ../sigscheme/src/continuation.c:215 #19 0xf3c12a98 in call (proc=value optimized out, args=30, eval_state=0xf79fcb34, need_eval=SCM_VALTYPE_NEED_EVAL) at ../sigscheme/src/eval.c:417 #20 0xf3c12d69 in scm_eval (obj=value optimized out, env=value optimized out) at ../sigscheme/src/eval.c:499
Bug#601866: uim-qt: includes qt4 input plugin
Package: uim-qt Version: 1:1.5.7-9+b1 Severity: normal Package description says: A input method module on Qt 4.x, which is newly implemented from immodule for Qt does not contain in this package for now. But, in fact, qt4 input plugin is included in the package (and triggers #601858). -- System Information: Debian Release: squeeze/sid APT prefers testing APT policy: (900, 'testing'), (300, 'stable') Architecture: i386 (x86_64) Kernel: Linux 2.6.32-5-amd64 (SMP w/2 CPU cores) Locale: LANG=ru_RU.UTF-8, LC_CTYPE=ru_RU.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages uim-qt depends on: ii libc6 2.11.2-6+squeeze1 Embedded GNU C Library: Shared lib ii libgcc11:4.4.5-4 GCC support library ii libqt4-qt3support 4:4.6.3-4 Qt 3 compatibility library for Qt ii libqtcore4 4:4.6.3-4 Qt 4 core module ii libqtgui4 4:4.6.3-4 Qt 4 GUI module ii libstdc++6 4.4.5-4 The GNU Standard C++ Library v3 ii libuim61:1.5.7-9+b1 Simple and flexible input method c ii uim-common 1:1.5.7-9 Common files for uim ii uim-utils 1:1.5.7-9+b1 Utilities for uim uim-qt recommends no packages. uim-qt 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#600489: bogofilter-bdb: overwrites files from bogofilter-common
Package: bogofilter-bdb Version: 1.2.2-1 After upgrade from lenny debsums complains: /usr/share/doc/bogofilter-common/NEWS.Debian.gz FAILED (or /usr/share/doc/bogofilter-bdb/NEWS.Debian.gz FAILED depending on package unpacking order) That's because /usr/share/doc/bogofilter-bdb is a symlink in lenny and bogofilter-bdb's maintainer scripts in squeeze do not handle changing it to a directory. (dpkg cannot do it on its own per policy 6.6 4.) As a result symlink is still there and both packages install files into /usr/share/doc/bogofilter-common: lrwxrwxrwx. 1 root root 17 Дек 17 2006 /usr/share/doc/bogofilter-bdb - bogofilter-common -- System Information: Debian Release: squeeze/sid APT prefers testing APT policy: (900, 'testing'), (300, 'stable') Architecture: i386 (x86_64) Kernel: Linux 2.6.32-5-amd64 (SMP w/2 CPU cores) Locale: LANG=ru_RU.UTF-8, LC_CTYPE=ru_RU.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages bogofilter-bdb depends on: ii bogofilter-common1.2.2-1 a fast Bayesian spam filter (commo ii libc62.11.2-6Embedded GNU C Library: Shared lib ii libdb4.8 4.8.30-2Berkeley v4.8 Database Libraries [ ii libgsl0ldbl 1.14+dfsg-1 GNU Scientific Library (GSL) -- li bogofilter-bdb recommends no packages. Versions of packages bogofilter-bdb suggests: pn db4.8-utilnone (no description available) -- no debconf information -- debsums errors found: debsums: changed file /usr/share/doc/bogofilter-bdb/NEWS.Debian.gz (from bogofilter-bdb package) -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#600489: bogofilter-bdb: overwrites files from bogofilter-common
17.10.2010 в 20:06:30 +0200 Serafeim Zanikolas написал(а): The problem you report was introduced in 1.2.0-3 and fixed in 1.2.1-1. Lenny has 1.1.7-1, so this issue has only affected testing for the time window between the above two versions. (Your report does indicate that you're running testing btw, not lenny) % dpkg -x bogofilter-bdb_1.1.7-1_i386.deb 1 % ls -la 1/usr/share/doc/bogofilter-bdb lrwxrwxrwx 1 stepan stepan 17 Окт 18 08:47 1/usr/share/doc/bogofilter-bdb - bogofilter-common % dpkg -x bogofilter-bdb_1.2.2-1_i386.deb 2 % ls -la 2/usr/share/doc/bogofilter-bdb итого 48 drwxr-xr-x 2 stepan stepan 120 Июл 10 00:32 . drwxr-xr-x 3 stepan stepan60 Июл 10 00:32 .. -rw-r--r-- 1 stepan stepan 9703 Июл 9 22:40 changelog.Debian.gz -rw-r--r-- 1 stepan stepan 1312 Июл 9 22:25 copyright -rw-r--r-- 1 stepan stepan 1399 Июл 9 22:25 NEWS.Debian.gz -rw-r--r-- 1 stepan stepan 26553 Апр 8 2010 README.db 1.2.0-3 shipped some symlinks and 1.2.1-1 replaced them with directories, as it should be in the first place -- nothing to do with maintainer scripts. No, the problem is in 1.1.7-1 - 1.2.2-1 upgrade: bogofilter-bdb 1.1.7-1 contains /usr/share/doc/bogofilter-bdb as a symlink to /usr/share/doc/bogofilter-common, while 1.2.2-1 contains /usr/share/doc/bogofilter-bdb as a directory and installs files into it. After 1.1.7-1 - 1.2.2-1 upgrade /usr/share/doc/bogofilter-bdb is still a symlink and files thus are installed into /usr/share/doc/bogofilter-common (some of them beeing different (NEWS.Debian.gz) and causing debsums failure). (Also, /usr/share/doc/bogofilter was an empty directory due to unhandled pre-lenny directory-symlink change.) I would guess that the debsums mismatch only appears if you upgrade -common and not -bdb (or the other way round). It shouldn't be an issue as soon as both are upgraded to the fixed version. No, both were upgraded to 1.2.2-1. And reinstalling one of them just moves debsums failure to another. (So rm -Rf /usr/share/doc/bogofilter* aptitude reinstall bogofilter bogofilter-common bogofilter-bdb was able to fix the breakage) -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#599588: openmovieeditor: double free in f0r_deinit () at filter/curves/curves.c:68
Package: openmovieeditor Version: 0.0.20080102-2.3+b2 Severity: normal openmovieeditor crashes on exit: *** glibc detected *** openmovieeditor: double free or corruption (out): 0x09b7e260 *** === Backtrace: = /lib/i686/cmov/libc.so.6(+0x6b281)[0xf636a281] /lib/i686/cmov/libc.so.6(+0x6cad8)[0xf636bad8] /lib/i686/cmov/libc.so.6(cfree+0x6d)[0xf636ebbd] /usr/lib/frei0r-1/curves.so(f0r_deinit+0x30)[0xf564b570] openmovieeditor[0x8090279] openmovieeditor[0x809302f] openmovieeditor[0x806c929] /lib/i686/cmov/libc.so.6(__libc_start_main+0xe6)[0xf6315c76] openmovieeditor[0x80537e1] f0r_deinit (as well as f0r_init) from /usr/lib/frei0r-1/curves.so is beeing called twice (from Frei0rFactory and from NodeFilterFrei0rFactory), but code there obviously does not support it and tries to free already freed memory. -- System Information: Debian Release: squeeze/sid APT prefers testing APT policy: (900, 'testing'), (300, 'stable') Architecture: i386 (x86_64) Kernel: Linux 2.6.32-5-amd64 (SMP w/2 CPU cores) Locale: LANG=ru_RU.UTF-8, LC_CTYPE=ru_RU.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages openmovieeditor depends on: ii libavcodec52 4:0.5.2-6 ffmpeg codec library ii libavformat52 4:0.5.2-6 ffmpeg file format library ii libavutil494:0.5.2-6 ffmpeg utility library ii libc6 2.11.2-6 Embedded GNU C Library: Shared lib ii libfltk1.1 1.1.10-2+b1 Fast Light Toolkit - shared librar ii libgavl1 1.1.2-3 low level audio and video library ii libgcc11:4.4.4-8 GCC support library ii libgl1-mesa-glx [libgl 7.7.1-4 A free implementation of the OpenG ii libjack0 [libjack-0.11 1:0.118+svn3796-7 JACK Audio Connection Kit (librari ii libmpeg3-1 1.5.4-5 MPEG streams decoding library ii libquicktime1 2:1.1.5-1+b1 library for reading and writing Qu ii libsamplerate0 0.1.7-3 Audio sample rate conversion libra ii libsndfile11.0.21-3 Library for reading/writing audio ii libstdc++6 4.4.4-8 The GNU Standard C++ Library v3 ii libswscale04:0.5.2-6 ffmpeg video scaling library ii libx11-6 2:1.3.3-3 X11 client-side library ii zlib1g 1:1.2.3.4.dfsg-3 compression library - runtime openmovieeditor recommends no packages. openmovieeditor 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#599597: gjiten: fails to remove /usr/share/gjiten/
Package: gjiten Version: 2.6-2.1 /usr/share/gjiten/ remains after gjiten was purged. % ls -laR /usr/share/gjiten/ /usr/share/gjiten/: итого 44 drwxr-xr-x. 3 root root 4096 Окт 9 16:30 . drwxr-xr-x. 514 root root 24576 Окт 9 16:36 .. drwxr-xr-x. 2 root root 4096 Сен 27 21:46 dics /usr/share/gjiten/dics: итого 43652 drwxr-xr-x. 2 root root 4096 Сен 27 21:46 . drwxr-xr-x. 3 root root 4096 Окт 9 16:30 .. -rw-r--r--. 1 root root 810760 Сен 27 21:46 compdic -rw-r--r--. 1 root root 11168333 Сен 27 21:46 edict -rw-r--r-- 1 root root 31519930 Сен 27 21:46 enamdict -rw-r--r--. 1 root root 1103446 Сен 27 21:46 kanjidic -- System Information: Debian Release: squeeze/sid APT prefers testing APT policy: (900, 'testing'), (300, 'stable') Architecture: i386 (x86_64) Kernel: Linux 2.6.32-5-amd64 (SMP w/2 CPU cores) Locale: LANG=ru_RU.UTF-8, LC_CTYPE=ru_RU.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages gjiten depends on: ii edict 2009.03.03-1 English / Japanese dictionary ii gconf2 2.28.1-4 GNOME configuration database syste ii kanjidic 2008.02.13-1 A Kanji Dictionary ii libart-2.0-2 2.3.21-1 Library of functions for 2D graphi ii libatk1.0-01.30.0-1 The ATK accessibility toolkit ii libbonobo2-0 2.24.3-1 Bonobo CORBA interfaces library pn libbonoboui2-0 none(no description available) ii libc6 2.11.2-6 Embedded GNU C Library: Shared lib ii libcairo2 1.8.10-6 The Cairo 2D vector graphics libra ii libfontconfig1 2.8.0-2.1 generic font configuration library ii libfreetype6 2.4.2-1 FreeType 2 font engine, shared lib ii libgconf2-42.28.1-4 GNOME configuration database syste ii libglade2-01:2.6.4-1 library to load .glade files at ru ii libglib2.0-0 2.24.2-1 The GLib library of C routines pn libgnome2-0none(no description available) ii libgnomecanvas2-0 2.30.1-1 A powerful object-oriented display pn libgnomeui-0 none(no description available) ii libgnomevfs2-0 1:2.24.3-1GNOME Virtual File System (runtime ii libgtk2.0-02.20.1-1+b1 The GTK+ graphical user interface ii libice62:1.0.6-1 X11 Inter-Client Exchange library ii liborbit2 1:2.14.18-0.1 libraries for ORBit2 - a CORBA ORB ii libpango1.0-0 1.28.1-1 Layout and rendering of internatio ii libpopt0 1.16-1lib for parsing cmdline parameters ii libsm6 2:1.1.1-1 X11 Session Management library ii libxml22.7.7.dfsg-4 GNOME XML library Versions of packages gjiten recommends: ii ttf-kochi-mincho 20030809-9 Kochi Subst Mincho Japanese TrueTy ii ttf-sazanami-mincho 20040629-8 Sazanami Mincho Japanese TrueType Versions of packages gjiten suggests: ii enamdict2009.03.03-1 Dictionary of Japanese proper name -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#524102: libsubtitleeditor0: missing Replaces: subtitleeditor
14.04.2009 в 22:57:58 +0300 George Kiagiadakis написал: During upgrade, dpkg complains about that: Selecting previously deselected package libsubtitleeditor0. Unpacking libsubtitleeditor0 (from .../libsubtitleeditor0_0.30.0-1_amd64.deb) ... dpkg: error processing /var/cache/apt/archives/libsubtitleeditor0_0.30.0-1_amd64.deb (--unpack): trying to overwrite `/usr/share/subtitleeditor/menubar.xml', which is also in package subtitleeditor dpkg-deb: subprocess paste killed by signal (Broken pipe) Trying to install libsubtitleeditor0 after that works correctly. This still happens on lenny - squeeze upgrade. So, the package is obviously missing a Replaces: subtitleeditor line in control. Actually, Replaces: subtitleeditor ( 0.30.0-1) and Breaks: subtitleeditor ( 0.30.0-1) are required. (See policy 7.6.1) -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#597377: libqalculate5: conflicts with lenny's qalc over /usr/share/qalculate/elements.xml
Package: libqalculate5 Version: 0.9.7-3 Severity: serious Lenny to squeeze upgrade of qalc fails due to file conflict between old qalc and libqalculate5. Looks like Breaks/Replaces specify wrong version number. Распаковывается пакет libqalculate5 (из файла .../libqalculate5_0.9.7-3_i386.deb)... dpkg: не удалось обработать параметр /var/cache/apt/archives/libqalculate5_0.9.7-3_i386.deb (--unpack): попытка перезаписать /usr/share/qalculate/elements.xml, который уже имеется в пакете qalc configured to not write apport reports dpkg-deb: подпроцесс paste убит по сигналу (Обрыв канала) Подготовка к замене пакета qalc 0.9.6-2 (используется файл .../archives/qalc_0.9.7-3_i386.deb)... Распаковывается замена для пакета qalc ... Обрабатываются триггеры для man-db ... При обработке следующих пакетов произошли ошибки: /var/cache/apt/archives/libqalculate5_0.9.7-3_i386.deb E: Sub-process /usr/bin/dpkg returned an error code (1) -- System Information: Debian Release: squeeze/sid APT prefers stable APT policy: (900, 'stable'), (300, 'testing') Architecture: i386 (x86_64) Kernel: Linux 2.6.32-5-amd64 (SMP w/2 CPU cores) Locale: LANG=ru_RU.UTF-8, LC_CTYPE=ru_RU.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages libqalculate5 depends on: ii libc6 2.11.2-5 Embedded GNU C Library: Shared lib ii libcln6 1.3.1-2 Class Library for Numbers (C++) ii libgcc1 1:4.4.4-8GCC support library ii libglib2.0-02.24.1-1 The GLib library of C routines ii libstdc++6 4.4.4-8 The GNU Standard C++ Library v3 ii libxml2 2.7.7.dfsg-4 GNOME XML library libqalculate5 recommends no packages. libqalculate5 suggests no packages. -- debconf-show failed -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
